| Message ID | 93377b77b9493d79de48741b030fa1b03f80094f.1492210847.git.sathyanarayanan.kuppuswamy@linux.intel.com |
|---|---|
| State | New |
| Headers | show |
On Fri, Apr 14, 2017 at 04:26:00PM -0700, sathyanarayanan.kuppuswamy@linux.intel.com wrote: > From: Kuppuswamy Sathyanarayanan <sathyanarayanan.kuppuswamy@linux.intel.com> > > Currently in WCOVE PMIC mfd driver, all second level irq chips By currently I believe you mean after the earlier patch in this series is applied, correct? This one is dependent on the previous one? > are chained to the respective first level irqs. So there is no > need for explicitly unmasking the first level irq in this > driver. This patches removes this level 1 irq unmask support. > > Signed-off-by: Kuppuswamy Sathyanarayanan <sathyanarayanan.kuppuswamy@linux.intel.com> For platform drivers x86: Reviewed-by: Darren Hart (VMware) <dvhart@infradead.org> Are you working with a specific maintainers to pull this in as a series? With so many subsystems, we need to coordinate to make sure we don't make a mess for Linus. Given the interdependencies, I'd recommend someone pull the series in as a whole - maybe into MFD? Lee, do you have a preference?
Hi Darren, Thanks for the review. On 04/21/2017 03:00 PM, Darren Hart wrote: > On Fri, Apr 14, 2017 at 04:26:00PM -0700, sathyanarayanan.kuppuswamy@linux.intel.com wrote: >> From: Kuppuswamy Sathyanarayanan <sathyanarayanan.kuppuswamy@linux.intel.com> >> >> Currently in WCOVE PMIC mfd driver, all second level irq chips > By currently I believe you mean after the earlier patch in this series is > applied, correct? Yes. > This one is dependent on the previous one? Yes, one of my previous patch in this series fixes this problem in MFD driver. > >> are chained to the respective first level irqs. So there is no >> need for explicitly unmasking the first level irq in this >> driver. This patches removes this level 1 irq unmask support. >> >> Signed-off-by: Kuppuswamy Sathyanarayanan <sathyanarayanan.kuppuswamy@linux.intel.com> > For platform drivers x86: > > Reviewed-by: Darren Hart (VMware) <dvhart@infradead.org> > > Are you working with a specific maintainers to pull this in as a series? Thanks for brining it up. I was planning to ask either Andy or Lee regarding this issue after all patches in the series are reviewed. > With so > many subsystems, we need to coordinate to make sure we don't make a mess for > Linus. Given the interdependencies, I'd recommend someone pull the series in as > a whole - maybe into MFD? Lee, do you have a preference? >
On Sat, Apr 22, 2017 at 1:34 AM, sathyanarayanan kuppuswamy <sathyanarayanan.kuppuswamy@linux.intel.com> wrote: > Thanks for brining it up. I was planning to ask either Andy or Lee regarding > this issue after all patches in the series are reviewed. Darren, I'm planning to review this soon. P.S. We have few series flying around regarding to Intel PMIC(s): my for Kconfig naming, Hans' for Crystal Cove (touches Kconfig as well), and Sathya's series. I hope Lee can collect them in proper order.
On Sat, 22 Apr 2017, Andy Shevchenko wrote: > On Sat, Apr 22, 2017 at 1:34 AM, sathyanarayanan kuppuswamy > <sathyanarayanan.kuppuswamy@linux.intel.com> wrote: > > > Thanks for brining it up. I was planning to ask either Andy or Lee regarding > > this issue after all patches in the series are reviewed. > > Darren, I'm planning to review this soon. > > P.S. We have few series flying around regarding to Intel PMIC(s): my > for Kconfig naming, Hans' for Crystal Cove (touches Kconfig as well), > and Sathya's series. I hope Lee can collect them in proper order. That could be easier said than done.
On Fri, 21 Apr 2017, Darren Hart wrote: > On Fri, Apr 14, 2017 at 04:26:00PM -0700, sathyanarayanan.kuppuswamy@linux.intel.com wrote: > > From: Kuppuswamy Sathyanarayanan <sathyanarayanan.kuppuswamy@linux.intel.com> > > > > Currently in WCOVE PMIC mfd driver, all second level irq chips > > By currently I believe you mean after the earlier patch in this series is > applied, correct? This one is dependent on the previous one? > > > are chained to the respective first level irqs. So there is no > > need for explicitly unmasking the first level irq in this > > driver. This patches removes this level 1 irq unmask support. > > > > Signed-off-by: Kuppuswamy Sathyanarayanan <sathyanarayanan.kuppuswamy@linux.intel.com> > > For platform drivers x86: > > Reviewed-by: Darren Hart (VMware) <dvhart@infradead.org> > > Are you working with a specific maintainers to pull this in as a series? With so > many subsystems, we need to coordinate to make sure we don't make a mess for > Linus. Given the interdependencies, I'd recommend someone pull the series in as > a whole - maybe into MFD? Lee, do you have a preference? I am happy to take the set, however I think v4.12 is an unlikely candidate, since there still have quite a few patches which are yet to receive review and the merge-window opens in 6 days. Once we have all the required Acks, I'll push the set into -next where it can sit for a good soak test until v4.13.
On Mon, Apr 24, 2017 at 12:24 PM, Lee Jones <lee.jones@linaro.org> wrote: > On Sat, 22 Apr 2017, Andy Shevchenko wrote: > >> On Sat, Apr 22, 2017 at 1:34 AM, sathyanarayanan kuppuswamy >> <sathyanarayanan.kuppuswamy@linux.intel.com> wrote: >> >> > Thanks for brining it up. I was planning to ask either Andy or Lee regarding >> > this issue after all patches in the series are reviewed. >> >> Darren, I'm planning to review this soon. >> >> P.S. We have few series flying around regarding to Intel PMIC(s): my >> for Kconfig naming, Hans' for Crystal Cove (touches Kconfig as well), >> and Sathya's series. I hope Lee can collect them in proper order. > > That could be easier said than done. Some of them are already in your tree, then apply - my Kconfig patch which makes Broxton Whiskey Cove to be built independently of Crystal Cove (I didn't notice that patch in your tree, though some of your mail told it had been applied) - Hans' series regarding CherryTrail Whiskey Cove support (if it has all ACKs) - this series after my review. Does it sound doable?
On Mon, 24 Apr 2017, Andy Shevchenko wrote: > On Mon, Apr 24, 2017 at 12:24 PM, Lee Jones <lee.jones@linaro.org> wrote: > > On Sat, 22 Apr 2017, Andy Shevchenko wrote: > > > >> On Sat, Apr 22, 2017 at 1:34 AM, sathyanarayanan kuppuswamy > >> <sathyanarayanan.kuppuswamy@linux.intel.com> wrote: > >> > >> > Thanks for brining it up. I was planning to ask either Andy or Lee regarding > >> > this issue after all patches in the series are reviewed. > >> > >> Darren, I'm planning to review this soon. > >> > >> P.S. We have few series flying around regarding to Intel PMIC(s): my > >> for Kconfig naming, Hans' for Crystal Cove (touches Kconfig as well), > >> and Sathya's series. I hope Lee can collect them in proper order. > > > > That could be easier said than done. > > Some of them are already in your tree, then apply > - my Kconfig patch which makes Broxton Whiskey Cove to be built > independently of Crystal Cove (I didn't notice that patch in your > tree, though some of your mail told it had been applied) > - Hans' series regarding CherryTrail Whiskey Cove support (if it has all ACKs) > - this series after my review. > > Does it sound doable? My Inbox is now empty, so all patches are now either applied or waiting further Acks/Actions. I'm pretty certain that this set is not going in before v4.13.
On Mon, Apr 24, 2017 at 3:24 PM, Lee Jones <lee.jones@linaro.org> wrote: > On Mon, 24 Apr 2017, Andy Shevchenko wrote: > >> On Mon, Apr 24, 2017 at 12:24 PM, Lee Jones <lee.jones@linaro.org> wrote: >> > On Sat, 22 Apr 2017, Andy Shevchenko wrote: >> > >> >> On Sat, Apr 22, 2017 at 1:34 AM, sathyanarayanan kuppuswamy >> >> <sathyanarayanan.kuppuswamy@linux.intel.com> wrote: >> >> >> >> > Thanks for brining it up. I was planning to ask either Andy or Lee regarding >> >> > this issue after all patches in the series are reviewed. >> >> >> >> Darren, I'm planning to review this soon. >> >> >> >> P.S. We have few series flying around regarding to Intel PMIC(s): my >> >> for Kconfig naming, Hans' for Crystal Cove (touches Kconfig as well), >> >> and Sathya's series. I hope Lee can collect them in proper order. >> > >> > That could be easier said than done. >> >> Some of them are already in your tree, then apply >> - my Kconfig patch which makes Broxton Whiskey Cove to be built >> independently of Crystal Cove (I didn't notice that patch in your >> tree, though some of your mail told it had been applied) >> - Hans' series regarding CherryTrail Whiskey Cove support (if it has all ACKs) >> - this series after my review. >> >> Does it sound doable? > > My Inbox is now empty, so all patches are now either applied or > waiting further Acks/Actions. I reviewed the series and found it suitable to apply. The GPIO Whiskey Cove patch will do a conflict (in GPIO tree is another patch that adds GPIO IRQ masks in a way by using GENMASK(), so, we might avoid this doing the same in patch 5 here). Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com> for entire series. > I'm pretty certain that this set is not going in before v4.13. It is now on your side :-)
diff --git a/drivers/platform/x86/intel_bxtwc_tmu.c b/drivers/platform/x86/intel_bxtwc_tmu.c index e202abd..ea865d4 100644 --- a/drivers/platform/x86/intel_bxtwc_tmu.c +++ b/drivers/platform/x86/intel_bxtwc_tmu.c @@ -92,10 +92,6 @@ static int bxt_wcove_tmu_probe(struct platform_device *pdev) } wctmu->irq = virq; - /* Enable TMU interrupts */ - regmap_update_bits(wctmu->regmap, BXTWC_MIRQLVL1, - BXTWC_MIRQLVL1_MTMU, 0); - /* Unmask TMU second level Wake & System alarm */ regmap_update_bits(wctmu->regmap, BXTWC_MTMUIRQ_REG, BXTWC_TMU_ALRM_MASK, 0);