Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751305Ab3FFOxg (ORCPT ); Thu, 6 Jun 2013 10:53:36 -0400 Received: from 9.mo5.mail-out.ovh.net ([178.32.96.204]:54515 "EHLO mo5.mail-out.ovh.net" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1750868Ab3FFOxf (ORCPT ); Thu, 6 Jun 2013 10:53:35 -0400 Date: Thu, 6 Jun 2013 16:49:29 +0200 From: Jean-Christophe PLAGNIOL-VILLARD To: Michal Simek Cc: Michal Simek , Grant Likely , devicetree-discuss@lists.ozlabs.org, linux-kernel@vger.kernel.org, Rob Herring X-Ovh-Mailout: 178.32.228.5 (mo5.mail-out.ovh.net) Subject: Re: [PATCH] of: Export of_irq_count for using in modules Message-ID: <20130606144929.GI19834@game.jcrosoft.org> References: <6aa29b1d109a46278a7f37b598defe07d6edfe60.1369921774.git.michal.simek@xilinx.com> <20130530201714.GE19834@game.jcrosoft.org> <51A85BEE.4000009@monstr.eu> <20130531110045.GF19834@game.jcrosoft.org> <51A8AC4B.906@monstr.eu> <20130531151601.GG19834@game.jcrosoft.org> <51A8D3A3.5030200@monstr.eu> <20130606082941.GH19834@game.jcrosoft.org> <51B04AA9.4070803@monstr.eu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <51B04AA9.4070803@monstr.eu> X-PGP-Key: http://uboot.jcrosoft.org/plagnioj.asc X-PGP-key-fingerprint: 6309 2BBA 16C8 3A07 1772 CC24 DEFC FFA3 279C CE7C User-Agent: Mutt/1.5.20 (2009-06-14) X-Ovh-Tracer-Id: 11703448058623667151 X-Ovh-Remote: 213.251.161.87 (ns32433.ovh.net) X-Ovh-Local: 213.186.33.20 (ns0.ovh.net) X-OVH-SPAMSTATE: OK X-OVH-SPAMSCORE: -100 X-OVH-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrfeeiiedrfeejucetufdoteggodetrfcurfhrohhfihhlvgemucfqggfjnecuuegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmd X-Spam-Check: DONE|U 0.5/N X-VR-SPAMSTATE: OK X-VR-SPAMSCORE: -100 X-VR-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrfeeiiedrfeejucetufdoteggodetrfcurfhrohhfihhlvgemucfqggfjnecuuegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmd Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 4689 Lines: 125 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@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/