[PATCH] of: Export of_irq_count for using in modules

Michal Simek monstr at monstr.eu
Fri Jun 7 03:16:09 EST 2013


2013/6/6 Jean-Christophe PLAGNIOL-VILLARD <plagnioj at jcrosoft.com>

> On 10:39 Thu 06 Jun     , Michal Simek wrote:
> > On 06/06/2013 10:29 AM, Jean-Christophe PLAGNIOL-VILLARD wrote:
> > > On 18:45 Fri 31 May     , Michal Simek wrote:
> > >> On 05/31/2013 05:16 PM, Jean-Christophe PLAGNIOL-VILLARD wrote:
> > >>> On 15:57 Fri 31 May     , Michal Simek wrote:
> > >>>> On 05/31/2013 01:00 PM, Jean-Christophe PLAGNIOL-VILLARD wrote:
> > >>>>> On 10:14 Fri 31 May     , Michal Simek wrote:
> > >>>>>> Hi Jean-Christophe,
> > >>>>>>
> > >>>>>> On 05/30/2013 10:17 PM, Jean-Christophe PLAGNIOL-VILLARD wrote:
> > >>>>>>> On 15:49 Thu 30 May     , Michal Simek wrote:
> > >>>>>>>> Export of_irq_count for modules.
> > >>>>>>>
> > >>>>>>> can you explain why do you need to call of_irq_count
> > >>>>>>
> > >>>>>> I need to count number of irq written in the DTS node.
> > >>>>>> It is not fixed size that's why I need to proper way how to
> > >>>>>> find it out.
> > >>>>>>
> > >>>>>> I am using this loop.
> > >>>>>>        count = of_irq_count(pdev->dev.of_node);
> > >>>>>>        /* Alloc IRQ based on DTS to be sure that no other driver
> will use it */
> > >>>>>>        while (count--) {
> > >>>>>>                tmp->irq = irq_of_parse_and_map(pdev->dev.of_node,
> count);
> > >>>>>>                dev_info(&pdev->dev, "%d: Alloc irq: %d\n", count,
> tmp->irq);
> > >>>>>>                ret = request_irq(tmp->irq,
> zynq_remoteproc_interrupt, 0,
> > >>>>>>                                        dev_name(&pdev->dev),
> &pdev->dev);
> > >>>>>>                if (ret) {
> > >>>>>>                        ...
> > >>>>>>                }
> > >>>>>>        }
> > >>>>>>
> > >>>>>> But of course if you think that this is incorrect to export it
> > >>>>>> I can use what it is in of_irq_count body
> > >>>>>> 368 int of_irq_count(struct device_node *dev)
> > >>>>>> 369 {
> > >>>>>> 370         int nr = 0;
> > >>>>>> 371
> > >>>>>> 372         while (of_irq_to_resource(dev, nr, NULL))
> > >>>>>> 373                 nr++;
> > >>>>>> 374
> > >>>>>> 375         return nr;
> > >>>>>> 376 }
> > >>>>>>
> > >>>>>> Because of_irq_to_resource is exported for modules.
> > >>>>>> Or is there any better way how to loop over all interrupts in DT
> node?
> > >>>>>
> > >>>>> can just explain me why you need to call irq_of_parse_and_map in
> your driver?
> > >>>>>
> > >>>>> as the irq will be provided in the resources normally
> > >>>>
> > >>>> It is quite a long time I have written this driver on v3.1 or 3.3.
> > >>>> But is this better?
> > >>>>
> > >>>>  struct resource *res;
> > >>>>  int i = 0;
> > >>>>  do {
> > >>>>          res = platform_get_resource(pdev, IORESOURCE_IRQ, i++);
> > >>>>          if (res)
> > >>>>                  do something
> > >>>>  } while(res);
> > >>>>
> > >>>> Also what about of_irq_to_resource()? Is it deprecated and all
> drivers
> > >>>> shouldn't use it?
> > >>>>
> > >>>> I have no problem to rewrite the driver to use
> platform_get_resource.
> > >>> yeah it's better but be aware there is a but in DT that I'm working
> on to fix
> > >>> if you use irq that are registered by a pdev this will not work
> > >>>
> > >>> I hope to fix it for 3.11
> > >>> and already send an RFC that fix it
> > >>
> > >> ok. good to know. Btw: Let's return to my origin point why not to
> > >> export of_irq_count for modules?
> > >> Or opposite question if platform_get_resource is correct way
> > >> why to export of_irq_to_resource for modules?
> > >
> > > for old ppc drivers that are not converted yet to pdev
> > >
> > > if you can do so just use pdev resource I should have fix the pb or
> irq_domain
> > > hopefully for 3.11
> >
> > ok. It means it is currently deprecated.
> > I just wanted to be sure that I understand it correctly.
> >
> > I have changed my drivers not to use this function and using resources as
> > we discussed.
> >
> > btw: I have sent one email to device-tree ML about describing missing
> > connection between cpu and the first interrupt controller.
> > Can you please look at it and comment it?
> >
> https://lists.ozlabs.org/pipermail/devicetree-discuss/2013-May/033955.html
>
> for the record as discussed with Grant I'm preparing to add a new property
> to handle interrupts so you will never have to use "interrupt-parent" any
> more
> and just do this
>
> interrupt-lines = <&aic 5 0 &pioA 4>
>
> it will be more like gpio and will allow to have irq from different
> interrupt-parent in the same node
>
> but wait a few I'll be really back next week as I'm half off this week
>


Good. I am definitely interested in this topic because we can connect
and test this pretty easily.
Also I hope there will be also description between interrupt controller
and cpu.
Anyway I will wait till you are back.

thanks,
Michal


-- 
Michal Simek, Ing. (M.Eng), OpenPGP -> KeyID: FE3D1F91
w: www.monstr.eu p: +42-0-721842854
Maintainer of Linux kernel - Microblaze cpu - http://www.monstr.eu/fdt/
Maintainer of Linux kernel - Xilinx Zynq ARM architecture
Microblaze U-BOOT custodian and responsible for u-boot arm zynq platform
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ozlabs.org/pipermail/devicetree-discuss/attachments/20130606/baebe4f8/attachment.html>


More information about the devicetree-discuss mailing list