| Message ID | 1448896304-87928-17-git-send-email-andriy.shevchenko@linux.intel.com |
|---|---|
| State | Awaiting Upstream |
| Headers | show |
On Mon, Nov 30, 2015 at 05:11:44PM +0200, Andy Shevchenko wrote: > From: Mika Westerberg <mika.westerberg@linux.intel.com> > > With ACPI _DSD (introduced in ACPI v5.1) it is now possible to pass device > configuration information from ACPI in addition to DT. In order to support > this, convert the driver to use the unified device property accessors > instead of DT specific. > > Change to ordering a bit so that we first try platform data and if that's > not available look from device properties. ACPI *CNT methods are then used > as last resort to override everything else. > > Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com> > Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> > Acked-by: Jarkko Nikula <jarkko.nikula@linux.intel.com> What is the bug fix here described in the cover letter? And shall this go via I2C or via the rest of the series? > --- > drivers/i2c/busses/i2c-designware-platdrv.c | 50 +++++++++++++---------------- > 1 file changed, 23 insertions(+), 27 deletions(-) > > diff --git a/drivers/i2c/busses/i2c-designware-platdrv.c b/drivers/i2c/busses/i2c-designware-platdrv.c > index 809579e..06061b5 100644 > --- a/drivers/i2c/busses/i2c-designware-platdrv.c > +++ b/drivers/i2c/busses/i2c-designware-platdrv.c > @@ -36,6 +36,7 @@ > #include <linux/platform_device.h> > #include <linux/pm.h> > #include <linux/pm_runtime.h> > +#include <linux/property.h> > #include <linux/io.h> > #include <linux/slab.h> > #include <linux/acpi.h> > @@ -129,10 +130,10 @@ static inline int dw_i2c_acpi_configure(struct platform_device *pdev) > > static int dw_i2c_plat_probe(struct platform_device *pdev) > { > + struct dw_i2c_platform_data *pdata = dev_get_platdata(&pdev->dev); > struct dw_i2c_dev *dev; > struct i2c_adapter *adap; > struct resource *mem; > - struct dw_i2c_platform_data *pdata; > int irq, r; > u32 clk_freq, ht = 0; > > @@ -156,33 +157,28 @@ static int dw_i2c_plat_probe(struct platform_device *pdev) > /* fast mode by default because of legacy reasons */ > clk_freq = 400000; > > - if (has_acpi_companion(&pdev->dev)) { > - dw_i2c_acpi_configure(pdev); > - } else if (pdev->dev.of_node) { > - of_property_read_u32(pdev->dev.of_node, > - "i2c-sda-hold-time-ns", &ht); > - > - of_property_read_u32(pdev->dev.of_node, > - "i2c-sda-falling-time-ns", > - &dev->sda_falling_time); > - of_property_read_u32(pdev->dev.of_node, > - "i2c-scl-falling-time-ns", > - &dev->scl_falling_time); > - > - of_property_read_u32(pdev->dev.of_node, "clock-frequency", > - &clk_freq); > - > - /* Only standard mode at 100kHz and fast mode at 400kHz > - * are supported. > - */ > - if (clk_freq != 100000 && clk_freq != 400000) { > - dev_err(&pdev->dev, "Only 100kHz and 400kHz supported"); > - return -EINVAL; > - } > + if (pdata) { > + clk_freq = pdata->i2c_scl_freq; > } else { > - pdata = dev_get_platdata(&pdev->dev); > - if (pdata) > - clk_freq = pdata->i2c_scl_freq; > + device_property_read_u32(&pdev->dev, "i2c-sda-hold-time-ns", > + &ht); > + device_property_read_u32(&pdev->dev, "i2c-sda-falling-time-ns", > + &dev->sda_falling_time); > + device_property_read_u32(&pdev->dev, "i2c-scl-falling-time-ns", > + &dev->scl_falling_time); > + device_property_read_u32(&pdev->dev, "clock-frequency", > + &clk_freq); > + } > + > + if (has_acpi_companion(&pdev->dev)) > + dw_i2c_acpi_configure(pdev); > + > + /* > + * Only standard mode at 100kHz and fast mode at 400kHz are supported. > + */ > + if (clk_freq != 100000 && clk_freq != 400000) { > + dev_err(&pdev->dev, "Only 100kHz and 400kHz supported"); > + return -EINVAL; > } > > r = i2c_dw_eval_lock_support(dev); > -- > 2.6.2 >
On Mon, Nov 30, 2015 at 08:58:58PM +0100, Wolfram Sang wrote: > On Mon, Nov 30, 2015 at 05:11:44PM +0200, Andy Shevchenko wrote: > > From: Mika Westerberg <mika.westerberg@linux.intel.com> > > > > With ACPI _DSD (introduced in ACPI v5.1) it is now possible to pass device > > configuration information from ACPI in addition to DT. In order to support > > this, convert the driver to use the unified device property accessors > > instead of DT specific. > > > > Change to ordering a bit so that we first try platform data and if that's > > not available look from device properties. ACPI *CNT methods are then used > > as last resort to override everything else. > > > > Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com> > > Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> > > Acked-by: Jarkko Nikula <jarkko.nikula@linux.intel.com> > > What is the bug fix here described in the cover letter? The bug fix is actually in patch [14/16] "mfd: intel-lpss: Pass SDA hold time to I2C host controller driver". > And shall this go via I2C or via the rest of the series? Either way works. This should compile and work fine without the rest but of course fix for the issue with Lenovo Yoga 900 toucpad still requires all the patches. -- To unsubscribe from this list: send the line "unsubscribe linux-i2c" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Mon, 2015-11-30 at 20:58 +0100, Wolfram Sang wrote: > On Mon, Nov 30, 2015 at 05:11:44PM +0200, Andy Shevchenko wrote: > > From: Mika Westerberg <mika.westerberg@linux.intel.com> > > > > With ACPI _DSD (introduced in ACPI v5.1) it is now possible to pass > > device > > configuration information from ACPI in addition to DT. In order to > > support > > this, convert the driver to use the unified device property > > accessors > > instead of DT specific. > > > > Change to ordering a bit so that we first try platform data and if > > that's > > not available look from device properties. ACPI *CNT methods are > > then used > > as last resort to override everything else. > > > > Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com> > > Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> > > Acked-by: Jarkko Nikula <jarkko.nikula@linux.intel.com> > > What is the bug fix here described in the cover letter? The cover letter mentioned 'last part' which I refer to as patches 14, 15 (though this is for UART), and 16.
On Tuesday, December 01, 2015 12:33:51 PM Andy Shevchenko wrote: > On Mon, 2015-11-30 at 20:58 +0100, Wolfram Sang wrote: > > On Mon, Nov 30, 2015 at 05:11:44PM +0200, Andy Shevchenko wrote: > > > From: Mika Westerberg <mika.westerberg@linux.intel.com> > > > > > > With ACPI _DSD (introduced in ACPI v5.1) it is now possible to pass > > > device > > > configuration information from ACPI in addition to DT. In order to > > > support > > > this, convert the driver to use the unified device property > > > accessors > > > instead of DT specific. > > > > > > Change to ordering a bit so that we first try platform data and if > > > that's > > > not available look from device properties. ACPI *CNT methods are > > > then used > > > as last resort to override everything else. > > > > > > Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com> > > > Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> > > > Acked-by: Jarkko Nikula <jarkko.nikula@linux.intel.com> > > > > What is the bug fix here described in the cover letter? > > The cover letter mentioned 'last part' which I refer to as patches 14, > 15 (though this is for UART), and 16. Hmm. So may I assume that patches [1-13/16] are for me and the rest is to be applied by the other respective maintainers? That should be easiest logistically IMHO. Thanks, Rafael -- To unsubscribe from this list: send the line "unsubscribe linux-i2c" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Wed, 2015-12-02 at 02:28 +0100, Rafael J. Wysocki wrote: > On Tuesday, December 01, 2015 12:33:51 PM Andy Shevchenko wrote: > > On Mon, 2015-11-30 at 20:58 +0100, Wolfram Sang wrote: > > > On Mon, Nov 30, 2015 at 05:11:44PM +0200, Andy Shevchenko wrote: > > > What is the bug fix here described in the cover letter? > > > > The cover letter mentioned 'last part' which I refer to as patches > > 14, > > 15 (though this is for UART), and 16. > > Hmm. > > So may I assume that patches [1-13/16] are for me and the rest is to > be applied > by the other respective maintainers? > > That should be easiest logistically IMHO. Have no objections.
On Wed, Dec 02, 2015 at 11:23:40AM +0200, Andy Shevchenko wrote: > On Wed, 2015-12-02 at 02:28 +0100, Rafael J. Wysocki wrote: > > On Tuesday, December 01, 2015 12:33:51 PM Andy Shevchenko wrote: > > > On Mon, 2015-11-30 at 20:58 +0100, Wolfram Sang wrote: > > > > On Mon, Nov 30, 2015 at 05:11:44PM +0200, Andy Shevchenko wrote: > > > > > > > What is the bug fix here described in the cover letter? > > > > > > The cover letter mentioned 'last part' which I refer to as patches > > > 14, > > > 15 (though this is for UART), and 16. > > > > Hmm. > > > > So may I assume that patches [1-13/16] are for me and the rest is to > > be applied > > by the other respective maintainers? > > > > That should be easiest logistically IMHO. > > Have no objections. Unfortunately the patches (except this one) depend on each other so they cannot be applied separately. -- To unsubscribe from this list: send the line "unsubscribe linux-i2c" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Wed, Dec 02, 2015 at 11:33:41AM +0200, Mika Westerberg wrote: > On Wed, Dec 02, 2015 at 11:23:40AM +0200, Andy Shevchenko wrote: > > On Wed, 2015-12-02 at 02:28 +0100, Rafael J. Wysocki wrote: > > > On Tuesday, December 01, 2015 12:33:51 PM Andy Shevchenko wrote: > > > > On Mon, 2015-11-30 at 20:58 +0100, Wolfram Sang wrote: > > > > > On Mon, Nov 30, 2015 at 05:11:44PM +0200, Andy Shevchenko wrote: > > > > > > > > > > > What is the bug fix here described in the cover letter? > > > > > > > > The cover letter mentioned 'last part' which I refer to as patches > > > > 14, > > > > 15 (though this is for UART), and 16. > > > > > > Hmm. > > > > > > So may I assume that patches [1-13/16] are for me and the rest is to > > > be applied > > > by the other respective maintainers? > > > > > > That should be easiest logistically IMHO. > > > > Have no objections. > > Unfortunately the patches (except this one) depend on each other so they > cannot be applied separately. So, why not let all of them go in in one go? For this patch: Acked-by: Wolfram Sang <wsa@the-dreams.de>
diff --git a/drivers/i2c/busses/i2c-designware-platdrv.c b/drivers/i2c/busses/i2c-designware-platdrv.c index 809579e..06061b5 100644 --- a/drivers/i2c/busses/i2c-designware-platdrv.c +++ b/drivers/i2c/busses/i2c-designware-platdrv.c @@ -36,6 +36,7 @@ #include <linux/platform_device.h> #include <linux/pm.h> #include <linux/pm_runtime.h> +#include <linux/property.h> #include <linux/io.h> #include <linux/slab.h> #include <linux/acpi.h> @@ -129,10 +130,10 @@ static inline int dw_i2c_acpi_configure(struct platform_device *pdev) static int dw_i2c_plat_probe(struct platform_device *pdev) { + struct dw_i2c_platform_data *pdata = dev_get_platdata(&pdev->dev); struct dw_i2c_dev *dev; struct i2c_adapter *adap; struct resource *mem; - struct dw_i2c_platform_data *pdata; int irq, r; u32 clk_freq, ht = 0; @@ -156,33 +157,28 @@ static int dw_i2c_plat_probe(struct platform_device *pdev) /* fast mode by default because of legacy reasons */ clk_freq = 400000; - if (has_acpi_companion(&pdev->dev)) { - dw_i2c_acpi_configure(pdev); - } else if (pdev->dev.of_node) { - of_property_read_u32(pdev->dev.of_node, - "i2c-sda-hold-time-ns", &ht); - - of_property_read_u32(pdev->dev.of_node, - "i2c-sda-falling-time-ns", - &dev->sda_falling_time); - of_property_read_u32(pdev->dev.of_node, - "i2c-scl-falling-time-ns", - &dev->scl_falling_time); - - of_property_read_u32(pdev->dev.of_node, "clock-frequency", - &clk_freq); - - /* Only standard mode at 100kHz and fast mode at 400kHz - * are supported. - */ - if (clk_freq != 100000 && clk_freq != 400000) { - dev_err(&pdev->dev, "Only 100kHz and 400kHz supported"); - return -EINVAL; - } + if (pdata) { + clk_freq = pdata->i2c_scl_freq; } else { - pdata = dev_get_platdata(&pdev->dev); - if (pdata) - clk_freq = pdata->i2c_scl_freq; + device_property_read_u32(&pdev->dev, "i2c-sda-hold-time-ns", + &ht); + device_property_read_u32(&pdev->dev, "i2c-sda-falling-time-ns", + &dev->sda_falling_time); + device_property_read_u32(&pdev->dev, "i2c-scl-falling-time-ns", + &dev->scl_falling_time); + device_property_read_u32(&pdev->dev, "clock-frequency", + &clk_freq); + } + + if (has_acpi_companion(&pdev->dev)) + dw_i2c_acpi_configure(pdev); + + /* + * Only standard mode at 100kHz and fast mode at 400kHz are supported. + */ + if (clk_freq != 100000 && clk_freq != 400000) { + dev_err(&pdev->dev, "Only 100kHz and 400kHz supported"); + return -EINVAL; } r = i2c_dw_eval_lock_support(dev);