All of lore.kernel.org
 help / color / mirror / Atom feed
From: nicolas.ferre@atmel.com (Nicolas Ferre)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH 1/3] ARM: at91/aic: add device tree support for AIC
Date: Tue, 29 Nov 2011 14:04:24 +0100	[thread overview]
Message-ID: <4ED4D858.40506@atmel.com> (raw)
In-Reply-To: <20111125152817.GA8866@totoro>

On 11/25/2011 04:28 PM, Jamie Iles :
> On Fri, Nov 25, 2011 at 02:51:06PM +0100, Jean-Christophe PLAGNIOL-VILLARD wrote:
>> On 22:26 Thu 24 Nov     , Jamie Iles wrote:
>>> Hi Nicolas,
>>> On Thu, Nov 24, 2011 at 10:56:27PM +0100, Nicolas Ferre wrote:
> [...]
>>>> +#if defined(CONFIG_OF)
>>>> +static struct of_device_id aic_ids[]  = {
>>>> +	{ .compatible = "atmel,at91rm9200-aic" },
>>>> +	{ /*sentinel*/ }
>>>> +};
>>>> +
>>>> +static int __init at91_aic_of_init(void)
>>>> +{
>>>> +	struct device_node *np;
>>>> +
>>>> +	np = of_find_matching_node(NULL, aic_ids);
>>>> +	if (np == NULL)
>>>> +		return -ENODEV;
>>>> +
>>>> +	at91_aic_base = of_iomap(np, 0);
>>>> +	at91_aic_domain.of_node = np;
>>>
>>> I think this needs to be:
>>>
>>> 	at91_aic_domain.of_node = of_node_get(np);
>>>
>>> to keep the reference count.

Well, in fact the of_find_matching_node() function already indent the 
ref. count...

>>>> +	/* Keep refcount of the node */

... That is why I added this comment ^^

But maybe for sake of clarity, I may have used what you propose anyway. 
What it your opinion?

>>>> +
>>>> +	return 0;
>>>> +}
>>>> +#else
>>>> +static int __init at91_aic_of_init(void)
>>>> +{
>>>> +	return -ENOSYS;
>>>> +}
>>>> +#endif
>>>
>>> I think it's preferred if you use of_irq_init() here as it can handle
>>> the ordering of IRQ controllers.  There are GIC and VIC bindings in
>>> -next that use this and provide a way for non-DT platforms to still use
>>> the drivers.
>> which is the case here as if the of_init fail we failback to the non-dt init
>>
>> and this IP is AT91 only
>
> Right, but it's not using the of_irq_init() interface which is the
> standard way of registering interrupt controllers and will correctly
> dependencies for you.
>
> So if you could have something like:
>
> void __init __at91_aic_init(unsigned int priority[NR_AIC_IRQS],
> 			    void __iomem *regs,
> 			    struct device_node *np)
> {
> 	/*
> 	 * Do all of the writes to the AIC itself and configure
> 	 * the IRQ domain.
> 	 */
> }
>
> void __init at91_aic_init(unsigned int priority[NR_AIC_IRQS])
> {
> 	void __iomem *base = ioremap(AT91_AIC, 512);
>
> 	__at91_aic_init(priority, base, NULL);
> }
>
> int __init at91_aic_of_init(struct device_node *node,
> 			    struct device_node *parent)
> {
> 	void __iomem *regs = of_iomap(node, 0);
>
> 	/*
> 	 * Get priorities from the DT.  If this was an array of cells
> 	 * then that should be okay.
> 	 */
> 	__at91_aic_init(dt_priorities, regs, node);
> }
>
> Then the DT based board initialisation can do:
>
> static const struct of_device_id at91_irq_of_match[] __initconst = {
> 	{ .compatible = "atmel,at91-aic", .data = at91_aic_of_init },
> 	{}
> };
>
> static void __init at91_of_irq_init(void)
> {
> 	of_irq_init(at91_of_irq_init);
> }

That looks nice. I will try to implement this. I will try to figure out 
when of_irq_init() is called compared to the other init_IRQ() function.

> Which is consistent with other platforms.  However this does require
> that the priorities are encoded in the device-tree, but I guess that's a
> good thing anyway isn't it?

That is a annoying point: I do not want to add all this "default" 
priority stuff in the DT. It is kind of useless until we use the 
threaded interrupts everywhere and may bloat the DT...

I will try to find a way to pass the default priority table to the DT 
called function.

Thanks for your review,
-- 
Nicolas Ferre

WARNING: multiple messages have this Message-ID (diff)
From: Nicolas Ferre <nicolas.ferre-AIFe0yeh4nAAvxtiuMwx3w@public.gmane.org>
To: Jamie Iles <jamie-wmLquQDDieKakBO8gow8eQ@public.gmane.org>
Cc: devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ@public.gmane.org,
	linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
	linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org
Subject: Re: [PATCH 1/3] ARM: at91/aic: add device tree support for AIC
Date: Tue, 29 Nov 2011 14:04:24 +0100	[thread overview]
Message-ID: <4ED4D858.40506@atmel.com> (raw)
In-Reply-To: <20111125152817.GA8866@totoro>

On 11/25/2011 04:28 PM, Jamie Iles :
> On Fri, Nov 25, 2011 at 02:51:06PM +0100, Jean-Christophe PLAGNIOL-VILLARD wrote:
>> On 22:26 Thu 24 Nov     , Jamie Iles wrote:
>>> Hi Nicolas,
>>> On Thu, Nov 24, 2011 at 10:56:27PM +0100, Nicolas Ferre wrote:
> [...]
>>>> +#if defined(CONFIG_OF)
>>>> +static struct of_device_id aic_ids[]  = {
>>>> +	{ .compatible = "atmel,at91rm9200-aic" },
>>>> +	{ /*sentinel*/ }
>>>> +};
>>>> +
>>>> +static int __init at91_aic_of_init(void)
>>>> +{
>>>> +	struct device_node *np;
>>>> +
>>>> +	np = of_find_matching_node(NULL, aic_ids);
>>>> +	if (np == NULL)
>>>> +		return -ENODEV;
>>>> +
>>>> +	at91_aic_base = of_iomap(np, 0);
>>>> +	at91_aic_domain.of_node = np;
>>>
>>> I think this needs to be:
>>>
>>> 	at91_aic_domain.of_node = of_node_get(np);
>>>
>>> to keep the reference count.

Well, in fact the of_find_matching_node() function already indent the 
ref. count...

>>>> +	/* Keep refcount of the node */

... That is why I added this comment ^^

But maybe for sake of clarity, I may have used what you propose anyway. 
What it your opinion?

>>>> +
>>>> +	return 0;
>>>> +}
>>>> +#else
>>>> +static int __init at91_aic_of_init(void)
>>>> +{
>>>> +	return -ENOSYS;
>>>> +}
>>>> +#endif
>>>
>>> I think it's preferred if you use of_irq_init() here as it can handle
>>> the ordering of IRQ controllers.  There are GIC and VIC bindings in
>>> -next that use this and provide a way for non-DT platforms to still use
>>> the drivers.
>> which is the case here as if the of_init fail we failback to the non-dt init
>>
>> and this IP is AT91 only
>
> Right, but it's not using the of_irq_init() interface which is the
> standard way of registering interrupt controllers and will correctly
> dependencies for you.
>
> So if you could have something like:
>
> void __init __at91_aic_init(unsigned int priority[NR_AIC_IRQS],
> 			    void __iomem *regs,
> 			    struct device_node *np)
> {
> 	/*
> 	 * Do all of the writes to the AIC itself and configure
> 	 * the IRQ domain.
> 	 */
> }
>
> void __init at91_aic_init(unsigned int priority[NR_AIC_IRQS])
> {
> 	void __iomem *base = ioremap(AT91_AIC, 512);
>
> 	__at91_aic_init(priority, base, NULL);
> }
>
> int __init at91_aic_of_init(struct device_node *node,
> 			    struct device_node *parent)
> {
> 	void __iomem *regs = of_iomap(node, 0);
>
> 	/*
> 	 * Get priorities from the DT.  If this was an array of cells
> 	 * then that should be okay.
> 	 */
> 	__at91_aic_init(dt_priorities, regs, node);
> }
>
> Then the DT based board initialisation can do:
>
> static const struct of_device_id at91_irq_of_match[] __initconst = {
> 	{ .compatible = "atmel,at91-aic", .data = at91_aic_of_init },
> 	{}
> };
>
> static void __init at91_of_irq_init(void)
> {
> 	of_irq_init(at91_of_irq_init);
> }

That looks nice. I will try to implement this. I will try to figure out 
when of_irq_init() is called compared to the other init_IRQ() function.

> Which is consistent with other platforms.  However this does require
> that the priorities are encoded in the device-tree, but I guess that's a
> good thing anyway isn't it?

That is a annoying point: I do not want to add all this "default" 
priority stuff in the DT. It is kind of useless until we use the 
threaded interrupts everywhere and may bloat the DT...

I will try to find a way to pass the default priority table to the DT 
called function.

Thanks for your review,
-- 
Nicolas Ferre

WARNING: multiple messages have this Message-ID (diff)
From: Nicolas Ferre <nicolas.ferre@atmel.com>
To: Jamie Iles <jamie@jamieiles.com>
Cc: Jean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com>,
	devicetree-discuss@lists.ozlabs.org,
	linux-kernel@vger.kernel.org,
	linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH 1/3] ARM: at91/aic: add device tree support for AIC
Date: Tue, 29 Nov 2011 14:04:24 +0100	[thread overview]
Message-ID: <4ED4D858.40506@atmel.com> (raw)
In-Reply-To: <20111125152817.GA8866@totoro>

On 11/25/2011 04:28 PM, Jamie Iles :
> On Fri, Nov 25, 2011 at 02:51:06PM +0100, Jean-Christophe PLAGNIOL-VILLARD wrote:
>> On 22:26 Thu 24 Nov     , Jamie Iles wrote:
>>> Hi Nicolas,
>>> On Thu, Nov 24, 2011 at 10:56:27PM +0100, Nicolas Ferre wrote:
> [...]
>>>> +#if defined(CONFIG_OF)
>>>> +static struct of_device_id aic_ids[]  = {
>>>> +	{ .compatible = "atmel,at91rm9200-aic" },
>>>> +	{ /*sentinel*/ }
>>>> +};
>>>> +
>>>> +static int __init at91_aic_of_init(void)
>>>> +{
>>>> +	struct device_node *np;
>>>> +
>>>> +	np = of_find_matching_node(NULL, aic_ids);
>>>> +	if (np == NULL)
>>>> +		return -ENODEV;
>>>> +
>>>> +	at91_aic_base = of_iomap(np, 0);
>>>> +	at91_aic_domain.of_node = np;
>>>
>>> I think this needs to be:
>>>
>>> 	at91_aic_domain.of_node = of_node_get(np);
>>>
>>> to keep the reference count.

Well, in fact the of_find_matching_node() function already indent the 
ref. count...

>>>> +	/* Keep refcount of the node */

... That is why I added this comment ^^

But maybe for sake of clarity, I may have used what you propose anyway. 
What it your opinion?

>>>> +
>>>> +	return 0;
>>>> +}
>>>> +#else
>>>> +static int __init at91_aic_of_init(void)
>>>> +{
>>>> +	return -ENOSYS;
>>>> +}
>>>> +#endif
>>>
>>> I think it's preferred if you use of_irq_init() here as it can handle
>>> the ordering of IRQ controllers.  There are GIC and VIC bindings in
>>> -next that use this and provide a way for non-DT platforms to still use
>>> the drivers.
>> which is the case here as if the of_init fail we failback to the non-dt init
>>
>> and this IP is AT91 only
>
> Right, but it's not using the of_irq_init() interface which is the
> standard way of registering interrupt controllers and will correctly
> dependencies for you.
>
> So if you could have something like:
>
> void __init __at91_aic_init(unsigned int priority[NR_AIC_IRQS],
> 			    void __iomem *regs,
> 			    struct device_node *np)
> {
> 	/*
> 	 * Do all of the writes to the AIC itself and configure
> 	 * the IRQ domain.
> 	 */
> }
>
> void __init at91_aic_init(unsigned int priority[NR_AIC_IRQS])
> {
> 	void __iomem *base = ioremap(AT91_AIC, 512);
>
> 	__at91_aic_init(priority, base, NULL);
> }
>
> int __init at91_aic_of_init(struct device_node *node,
> 			    struct device_node *parent)
> {
> 	void __iomem *regs = of_iomap(node, 0);
>
> 	/*
> 	 * Get priorities from the DT.  If this was an array of cells
> 	 * then that should be okay.
> 	 */
> 	__at91_aic_init(dt_priorities, regs, node);
> }
>
> Then the DT based board initialisation can do:
>
> static const struct of_device_id at91_irq_of_match[] __initconst = {
> 	{ .compatible = "atmel,at91-aic", .data = at91_aic_of_init },
> 	{}
> };
>
> static void __init at91_of_irq_init(void)
> {
> 	of_irq_init(at91_of_irq_init);
> }

That looks nice. I will try to implement this. I will try to figure out 
when of_irq_init() is called compared to the other init_IRQ() function.

> Which is consistent with other platforms.  However this does require
> that the priorities are encoded in the device-tree, but I guess that's a
> good thing anyway isn't it?

That is a annoying point: I do not want to add all this "default" 
priority stuff in the DT. It is kind of useless until we use the 
threaded interrupts everywhere and may bloat the DT...

I will try to find a way to pass the default priority table to the DT 
called function.

Thanks for your review,
-- 
Nicolas Ferre

  reply	other threads:[~2011-11-29 13:04 UTC|newest]

Thread overview: 32+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-11-24 21:56 [PATCH 1/3] ARM: at91/aic: add device tree support for AIC Nicolas Ferre
2011-11-24 21:56 ` Nicolas Ferre
2011-11-24 21:56 ` Nicolas Ferre
2011-11-24 21:56 ` [PATCH 2/3] ARM: at91/gpio: add irqdomain to gpio interrupts Nicolas Ferre
2011-11-24 21:56   ` Nicolas Ferre
2011-11-24 21:56   ` Nicolas Ferre
2011-11-25 15:36   ` Rob Herring
2011-11-25 15:36     ` Rob Herring
2011-11-25 15:36     ` Rob Herring
2011-11-24 21:56 ` [PATCH 3/3] ARM: at91/board-dt: remove AIC irq domain from board file Nicolas Ferre
2011-11-24 21:56   ` Nicolas Ferre
2011-11-24 21:56   ` Nicolas Ferre
2011-11-24 22:26 ` [PATCH 1/3] ARM: at91/aic: add device tree support for AIC Jamie Iles
2011-11-24 22:26   ` Jamie Iles
2011-11-25 13:51   ` Jean-Christophe PLAGNIOL-VILLARD
2011-11-25 13:51     ` Jean-Christophe PLAGNIOL-VILLARD
2011-11-25 13:51     ` Jean-Christophe PLAGNIOL-VILLARD
2011-11-25 15:28     ` Jamie Iles
2011-11-25 15:28       ` Jamie Iles
2011-11-29 13:04       ` Nicolas Ferre [this message]
2011-11-29 13:04         ` Nicolas Ferre
2011-11-29 13:04         ` Nicolas Ferre
2011-11-29 13:56         ` Nicolas Ferre
2011-11-29 13:56           ` Nicolas Ferre
2011-11-29 13:56           ` Nicolas Ferre
2011-11-29 18:07 ` [PATCH v2 " Nicolas Ferre
2011-11-29 18:07   ` Nicolas Ferre
2011-12-01 15:42   ` [PATCH v3 1/3] ARM: at91/aic: add irq domain and device tree support Nicolas Ferre
2011-12-01 15:42     ` Nicolas Ferre
2011-12-01 15:42     ` Nicolas Ferre
2011-12-06  6:34     ` Jean-Christophe PLAGNIOL-VILLARD
2011-12-06  6:34       ` Jean-Christophe PLAGNIOL-VILLARD

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4ED4D858.40506@atmel.com \
    --to=nicolas.ferre@atmel.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.