Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1567745 > unrolled thread

[PATCH 0/4] GPCv2 power domain support

Back to article view | Back to linux.kernel

Contents

  [PATCH 0/4] GPCv2 power domain support Andrey Smirnov <andrew.smirnov@gmail.com> - 2017-01-26 23:00 +0100
    Re: [PATCH 2/4] irqchip: Add IRQCHIP_DECLARE_DRIVER macro Andrey Smirnov <andrew.smirnov@gmail.com> - 2017-01-27 19:20 +0100
      Re: [PATCH 2/4] irqchip: Add IRQCHIP_DECLARE_DRIVER macro Marc Zyngier <marc.zyngier@arm.com> - 2017-01-30 12:30 +0100

#1567745 — [PATCH 0/4] GPCv2 power domain support

Hi everyone,

This patchset adds code for basic power domain subsystem integration
of GPCv2 IP block (found on i.MX7) as well as a couple of small
related changes.

This code is developed as a part of ongoing effort to upstream i.MX7
PCIe support, full source code of which is avalible here:

https://github.com/ndreys/linux/tree/imx7d/pcie-support-v2

I am not sure if including patch 3/4 in this series was a right
decision(it seems to belong more to i.MX tree), but, at the same time,
I was not sure how to proceed any other way given it's dependency on
patch 2/4. If there's any better way to handle the situation, please
let me know and I'd be more than happy to accomodate.

Thanks,
Andrey Smirnov

Andrey Smirnov (4):
  drivers/irqchip: Enable IMX_GPCV2 on i.MX7 by default
  irqchip: Add IRQCHIP_DECLARE_DRIVER macro
  i.MX: GPC: Use IRQCHIP_DECLARE_DRIVER
  irqchip/imx-gpcv2: Add power domain support

 .../devicetree/bindings/power/fsl,imx-gpcv2.txt    |  63 ++++++
 arch/arm/mach-imx/gpc.c                            |   2 +-
 drivers/irqchip/Kconfig                            |   2 +-
 drivers/irqchip/irq-imx-gpcv2.c                    | 239 ++++++++++++++++++++-
 include/dt-bindings/power/imx7-power.h             |  18 ++
 include/linux/irqchip.h                            |  16 ++
 6 files changed, 337 insertions(+), 3 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/power/fsl,imx-gpcv2.txt
 create mode 100644 include/dt-bindings/power/imx7-power.h

-- 
2.9.3

[toc] | [next] | [standalone]

#1568593 — Re: [PATCH 2/4] irqchip: Add IRQCHIP_DECLARE_DRIVER macro

+Cc linux-kernel@vger.kernel.org since I messed up original distribution list

On Fri, Jan 27, 2017 at 12:51 AM, Marc Zyngier <marc.zyngier@arm.com> wrote:
> On 26/01/17 21:56, Andrey Smirnov wrote:
>> Add IRQCHIP_DECLARE_DRIVER macro to allow having driver code that both
>> registers irqchip and a platform driver. Based on analogous code of
>> CLK_OF_DECLARE_DRIVER.
>>
>> Cc: yurovsky@gmail.com
>> Cc: Shawn Guo <shawnguo@kernel.org>
>> Cc: Thomas Gleixner <tglx@linutronix.de>
>> Cc: Jason Cooper <jason@lakedaemon.net>
>> Cc: Marc Zyngier <marc.zyngier@arm.com>
>> Signed-off-by: Andrey Smirnov <andrew.smirnov@gmail.com>
>> ---
>>  include/linux/irqchip.h | 16 ++++++++++++++++
>>  1 file changed, 16 insertions(+)
>>
>> diff --git a/include/linux/irqchip.h b/include/linux/irqchip.h
>> index 89c34b2..611e8cc 100644
>> --- a/include/linux/irqchip.h
>> +++ b/include/linux/irqchip.h
>> @@ -27,6 +27,22 @@
>>  #define IRQCHIP_DECLARE(name, compat, fn) OF_DECLARE_2(irqchip, name, compat, fn)
>>
>>  /*
>> + * Use this macro when you have a driver that requires two
>> + * initialization routines, one at IRQCHIP_DECLARE, and one at
>> + * platform device probe
>> + */
>> +#define IRQCHIP_DECLARE_DRIVER(name, compat, fn)                     \
>> +     static int __init                                               \
>> +     name##_of_irqchip_init_driver(struct device_node *np,           \
>> +                                   struct device_node *parent)       \
>> +     {                                                               \
>> +             of_node_clear_flag(np, OF_POPULATED);                   \
>> +             return fn(np, parent);                                  \
>> +     }                                                               \
>> +     OF_DECLARE_2(irqchip, name, compat, name##_of_irqchip_init_driver)
>> +
>> +
>> +/*
>>   * This macro must be used by the different irqchip drivers to declare
>>   * the association between their version and their initialization function.
>>   *
>>
>
> Why do we need this new macro? What problem does it solve that would not
> be solved by having proper dependency tracking?

The problem that I was trying to solve was trying to associate a
platform device with a DT-node that had a IRQCHIP_DECLARE declared for
it. After a bit of digging around the codebase I found
CLK_OF_DECLARE_DRIVER which seemed to exist to solve exactly the same
kind of problem I was having so I took it as "inspiration" and created
IRQCHIP_DECLARE_DRIVER.

I am not sure what you mean by "proper dependency tracking"(most
likely due to my ignorance), can you point me to a concrete example or
explain what you mean a bit more?

I'll be more happy to change the code and drop this macro if there's a
better way to solve my original problem.

Thanks you,
Andrey Smirnov

[toc] | [prev] | [next] | [standalone]

#1569619 — Re: [PATCH 2/4] irqchip: Add IRQCHIP_DECLARE_DRIVER macro

On 27/01/17 18:13, Andrey Smirnov wrote:
> +Cc linux-kernel@vger.kernel.org since I messed up original distribution list
> 
> On Fri, Jan 27, 2017 at 12:51 AM, Marc Zyngier <marc.zyngier@arm.com> wrote:
>> On 26/01/17 21:56, Andrey Smirnov wrote:
>>> Add IRQCHIP_DECLARE_DRIVER macro to allow having driver code that both
>>> registers irqchip and a platform driver. Based on analogous code of
>>> CLK_OF_DECLARE_DRIVER.
>>>
>>> Cc: yurovsky@gmail.com
>>> Cc: Shawn Guo <shawnguo@kernel.org>
>>> Cc: Thomas Gleixner <tglx@linutronix.de>
>>> Cc: Jason Cooper <jason@lakedaemon.net>
>>> Cc: Marc Zyngier <marc.zyngier@arm.com>
>>> Signed-off-by: Andrey Smirnov <andrew.smirnov@gmail.com>
>>> ---
>>>  include/linux/irqchip.h | 16 ++++++++++++++++
>>>  1 file changed, 16 insertions(+)
>>>
>>> diff --git a/include/linux/irqchip.h b/include/linux/irqchip.h
>>> index 89c34b2..611e8cc 100644
>>> --- a/include/linux/irqchip.h
>>> +++ b/include/linux/irqchip.h
>>> @@ -27,6 +27,22 @@
>>>  #define IRQCHIP_DECLARE(name, compat, fn) OF_DECLARE_2(irqchip, name, compat, fn)
>>>
>>>  /*
>>> + * Use this macro when you have a driver that requires two
>>> + * initialization routines, one at IRQCHIP_DECLARE, and one at
>>> + * platform device probe
>>> + */
>>> +#define IRQCHIP_DECLARE_DRIVER(name, compat, fn)                     \
>>> +     static int __init                                               \
>>> +     name##_of_irqchip_init_driver(struct device_node *np,           \
>>> +                                   struct device_node *parent)       \
>>> +     {                                                               \
>>> +             of_node_clear_flag(np, OF_POPULATED);                   \
>>> +             return fn(np, parent);                                  \
>>> +     }                                                               \
>>> +     OF_DECLARE_2(irqchip, name, compat, name##_of_irqchip_init_driver)
>>> +
>>> +
>>> +/*
>>>   * This macro must be used by the different irqchip drivers to declare
>>>   * the association between their version and their initialization function.
>>>   *
>>>
>>
>> Why do we need this new macro? What problem does it solve that would not
>> be solved by having proper dependency tracking?
> 
> The problem that I was trying to solve was trying to associate a
> platform device with a DT-node that had a IRQCHIP_DECLARE declared for
> it. After a bit of digging around the codebase I found
> CLK_OF_DECLARE_DRIVER which seemed to exist to solve exactly the same
> kind of problem I was having so I took it as "inspiration" and created
> IRQCHIP_DECLARE_DRIVER.

Irk. I see.

> I am not sure what you mean by "proper dependency tracking"(most
> likely due to my ignorance), can you point me to a concrete example or
> explain what you mean a bit more?

Well, what I was angling at is that this whole mess is actually created
by a number of "things" (clocks, timers and interrupt controllers) not
being represented as first class devices. That's mostly because they are
probed before the device model is up and running.

Now, you (and apparently many others before you) are playing tricks on
the OF layer to allow things to be probed as a device on top of using
the pre-device match.

While I really dislike it, I wouldn't object if this was universally
applicable to all firmware interfaces. But that's the point where things
break. This is completely tied to the device-tree (I have no particular
sympathies for ACPI, but I do have to deal with it).

I'd rather work on untangling the early boot so that we can have devices
be probed as early as we need, and get rid of the current hacks.

Thanks,

	M.
-- 
Jazz is not dead. It just smells funny...

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web