lkml.org 
[lkml]   [2013]   [Jul]   [18]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH] of: Export of_irq_count for using in modules
On 06/06/2013 04:49 PM, Jean-Christophe PLAGNIOL-VILLARD wrote:
> 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

Any update on this?

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


[unhandled content-type:application/pgp-signature]
\
 
 \ /
  Last update: 2013-07-18 09:41    [W:0.073 / U:0.804 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site