Re: [PATCH] of: Export of_irq_count for using in modules

[Jean-Christophe PLAGNIOL-VILLARD]

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

Best Regards,
J.
> 
> 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
> 
> 


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/