From: Lee Jones <lee.jones@linaro.org> To: Stephen Boyd <sboyd@codeaurora.org> Cc: Samuel Ortiz <sameo@linux.intel.com>, linux-kernel@vger.kernel.org, linux-arm-msm@vger.kernel.org, linux-arm-kernel@lists.infradead.org Subject: Re: [PATCH v2 3/7] mfd: pm8921: Migrate to irqdomains Date: Tue, 7 Jan 2014 08:22:33 +0000 [thread overview] Message-ID: <20140107082233.GB3182@lee--X1> (raw) In-Reply-To: <52CB1323.6080200@codeaurora.org> > >> unsigned int num_irqs; > >> unsigned int num_blocks; > >> unsigned int num_masters; > >> @@ -138,7 +137,7 @@ static int pm8xxx_irq_block_handler(struct pm_irq_chip *chip, int block) > >> for (i = 0; i < 8; i++) { > >> if (bits & (1 << i)) { > >> pmirq = block * 8 + i; > >> - irq = pmirq + chip->irq_base; > >> + irq = irq_find_mapping(chip->domain, pmirq); > > Going by this patch only, it appears you're calling irq_find_mapping() > > before you've called irq_create_mapping(). This won't work, so unless > > you've called the latter in a previous patch, you should ensure that > > you do so. > > > > Interrupts seem to work. I think that's because the mapping is created > when the consumer drivers call request_irq(). > > From what I can tell, if we call irq_find_mapping() and there is no > mapping associated with it then we have a spurious irq. If that happens > we'll call handle_generic_irq() with 0 and that will cause > handle_bad_irq() to be called and a debug message to be logged. That > seems like a good outcome. I would try to adhere to the documentation in case we are missing something or some of the semantics change. Please read: Documentation/IRQ-domain.txt. Specifically, "=== irq_domain usage ===" from line 39, which says to call irq_create_mapping() to indeed, create the mapping. > > What does the sizeof(u8) add here? > > > > This was just keeping the same code that was already there. I will do > sizeof(chip->config[0]) instead which is more future proof if that array > changes type later on. Ah, now I see what it's doing. Perhaps brackets would be of use to ensure readers aren't confused. I also think the sizeof() would be helpful too, so: chip = devm_kzalloc(&pdev->dev, sizeof(*chip) + (sizeof(chip->config[0]) * nirqs), GFP_KERNEL); > >> + return of_platform_populate(pdev->dev.of_node, NULL, NULL, &pdev->dev); > >> +} > > Can't you use the MFD core instead? > > > > Are you suggesting using mfd_add_devices()? At first glance it looks > like that would require an array of mfd_cell structures that do nothing > besides match compatible strings in the DT. Using of_platform_populate() > achieves the same goal and doesn't require an array of mfd_cell > structures for each different pm8xxx chip that comes along, meaning > simpler code. I'm inclined to agree, but playing Devil's advocate here, as a device using the MFD subsystem it's often clearer to readers and other people looking for examples if the MFD core functionality is used. For instance, I now have no idea what devices the PM8xxx encompasses without looking at the DTS file. A small cell structure is a small price to pay for code clarity IMHO. -- Lee Jones Linaro STMicroelectronics Landing Team Lead Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog
WARNING: multiple messages have this Message-ID (diff)
From: lee.jones@linaro.org (Lee Jones) To: linux-arm-kernel@lists.infradead.org Subject: [PATCH v2 3/7] mfd: pm8921: Migrate to irqdomains Date: Tue, 7 Jan 2014 08:22:33 +0000 [thread overview] Message-ID: <20140107082233.GB3182@lee--X1> (raw) In-Reply-To: <52CB1323.6080200@codeaurora.org> > >> unsigned int num_irqs; > >> unsigned int num_blocks; > >> unsigned int num_masters; > >> @@ -138,7 +137,7 @@ static int pm8xxx_irq_block_handler(struct pm_irq_chip *chip, int block) > >> for (i = 0; i < 8; i++) { > >> if (bits & (1 << i)) { > >> pmirq = block * 8 + i; > >> - irq = pmirq + chip->irq_base; > >> + irq = irq_find_mapping(chip->domain, pmirq); > > Going by this patch only, it appears you're calling irq_find_mapping() > > before you've called irq_create_mapping(). This won't work, so unless > > you've called the latter in a previous patch, you should ensure that > > you do so. > > > > Interrupts seem to work. I think that's because the mapping is created > when the consumer drivers call request_irq(). > > From what I can tell, if we call irq_find_mapping() and there is no > mapping associated with it then we have a spurious irq. If that happens > we'll call handle_generic_irq() with 0 and that will cause > handle_bad_irq() to be called and a debug message to be logged. That > seems like a good outcome. I would try to adhere to the documentation in case we are missing something or some of the semantics change. Please read: Documentation/IRQ-domain.txt. Specifically, "=== irq_domain usage ===" from line 39, which says to call irq_create_mapping() to indeed, create the mapping. > > What does the sizeof(u8) add here? > > > > This was just keeping the same code that was already there. I will do > sizeof(chip->config[0]) instead which is more future proof if that array > changes type later on. Ah, now I see what it's doing. Perhaps brackets would be of use to ensure readers aren't confused. I also think the sizeof() would be helpful too, so: chip = devm_kzalloc(&pdev->dev, sizeof(*chip) + (sizeof(chip->config[0]) * nirqs), GFP_KERNEL); > >> + return of_platform_populate(pdev->dev.of_node, NULL, NULL, &pdev->dev); > >> +} > > Can't you use the MFD core instead? > > > > Are you suggesting using mfd_add_devices()? At first glance it looks > like that would require an array of mfd_cell structures that do nothing > besides match compatible strings in the DT. Using of_platform_populate() > achieves the same goal and doesn't require an array of mfd_cell > structures for each different pm8xxx chip that comes along, meaning > simpler code. I'm inclined to agree, but playing Devil's advocate here, as a device using the MFD subsystem it's often clearer to readers and other people looking for examples if the MFD core functionality is used. For instance, I now have no idea what devices the PM8xxx encompasses without looking at the DTS file. A small cell structure is a small price to pay for code clarity IMHO. -- Lee Jones Linaro STMicroelectronics Landing Team Lead Linaro.org ? Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog
next prev parent reply other threads:[~2014-01-07 8:22 UTC|newest] Thread overview: 49+ messages / expand[flat|nested] mbox.gz Atom feed top 2013-12-23 20:45 [PATCH v2 0/7] Modernize pm8921 with irqdomains, regmap, DT Stephen Boyd 2013-12-23 20:45 ` Stephen Boyd 2013-12-23 20:45 ` Stephen Boyd 2013-12-23 20:45 ` [PATCH v2 1/7] mfd: Move pm8xxx-irq.c contents into only driver that uses it Stephen Boyd 2013-12-23 20:45 ` Stephen Boyd 2014-01-06 14:47 ` Lee Jones 2014-01-06 14:47 ` Lee Jones 2013-12-23 20:45 ` [PATCH v2 2/7] mfd: pm8921: Update for genirq changes Stephen Boyd 2013-12-23 20:45 ` Stephen Boyd 2013-12-23 20:45 ` [PATCH v2 3/7] mfd: pm8921: Migrate to irqdomains Stephen Boyd 2013-12-23 20:45 ` Stephen Boyd 2014-01-06 15:53 ` Lee Jones 2014-01-06 15:53 ` Lee Jones 2014-01-06 20:33 ` Stephen Boyd 2014-01-06 20:33 ` Stephen Boyd 2014-01-07 8:22 ` Lee Jones [this message] 2014-01-07 8:22 ` Lee Jones 2014-01-07 19:54 ` Stephen Boyd 2014-01-07 19:54 ` Stephen Boyd 2014-01-08 8:14 ` Lee Jones 2014-01-08 8:14 ` Lee Jones 2013-12-23 20:46 ` [PATCH v2 4/7] mfd: ssbi: Add regmap read/write helpers Stephen Boyd 2013-12-23 20:46 ` Stephen Boyd 2013-12-24 12:54 ` Mark Brown 2013-12-24 12:54 ` Mark Brown 2013-12-26 19:41 ` Stephen Boyd 2013-12-26 19:41 ` Stephen Boyd 2013-12-28 14:52 ` Mark Brown 2013-12-28 14:52 ` Mark Brown 2013-12-28 14:52 ` Mark Brown 2014-01-06 11:50 ` Lee Jones 2014-01-06 11:50 ` Lee Jones 2014-01-06 22:26 ` Stephen Boyd 2014-01-06 22:26 ` Stephen Boyd 2013-12-23 20:46 ` [PATCH v2 5/7] mfd: pm8921: Use ssbi regmap Stephen Boyd 2013-12-23 20:46 ` Stephen Boyd 2013-12-30 12:34 ` Mark Brown 2013-12-30 12:34 ` Mark Brown 2013-12-23 20:46 ` [PATCH v2 6/7] mfd: pm8921: Add DT match table Stephen Boyd 2013-12-23 20:46 ` Stephen Boyd 2014-01-06 11:52 ` Lee Jones 2014-01-06 11:52 ` Lee Jones 2014-01-06 18:03 ` Stephen Boyd 2014-01-06 18:03 ` Stephen Boyd [not found] ` <1387831563-13535-1-git-send-email-sboyd-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org> 2013-12-23 20:46 ` [PATCH v2 7/7] devicetree: bindings: Document PM8921/8058 PMICs Stephen Boyd 2013-12-23 20:46 ` Stephen Boyd 2013-12-23 20:46 ` Stephen Boyd 2014-01-06 11:53 ` Lee Jones 2014-01-06 11:53 ` Lee Jones
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=20140107082233.GB3182@lee--X1 \ --to=lee.jones@linaro.org \ --cc=linux-arm-kernel@lists.infradead.org \ --cc=linux-arm-msm@vger.kernel.org \ --cc=linux-kernel@vger.kernel.org \ --cc=sameo@linux.intel.com \ --cc=sboyd@codeaurora.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: linkBe 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.