Re: [PATCH v2 16/16] i2c: designware: Convert to use unified device property API

2015-12-02 Thread Wolfram Sang
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 



signature.asc
Description: Digital signature


Re: [PATCH v2 16/16] i2c: designware: Convert to use unified device property API

2015-12-02 Thread Mika Westerberg
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 majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH v2 16/16] i2c: designware: Convert to use unified device property API

2015-12-02 Thread Andy Shevchenko
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.

-- 
Andy Shevchenko 
Intel Finland Oy

--
To unsubscribe from this list: send the line "unsubscribe linux-i2c" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH v2 16/16] i2c: designware: Convert to use unified device property API

2015-12-01 Thread Rafael J. Wysocki
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 
> > > 
> > > 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 
> > > Signed-off-by: Andy Shevchenko 
> > > Acked-by: Jarkko Nikula 
> > 
> > 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 majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH v2 16/16] i2c: designware: Convert to use unified device property API

2015-12-01 Thread Andy Shevchenko
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 
> > 
> > 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 
> > Signed-off-by: Andy Shevchenko 
> > Acked-by: Jarkko Nikula 
> 
> 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.

-- 
Andy Shevchenko 
Intel Finland Oy

--
To unsubscribe from this list: send the line "unsubscribe linux-i2c" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH v2 16/16] i2c: designware: Convert to use unified device property API

2015-12-01 Thread Mika Westerberg
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 
> > 
> > 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 
> > Signed-off-by: Andy Shevchenko 
> > Acked-by: Jarkko Nikula 
> 
> 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 majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH v2 16/16] i2c: designware: Convert to use unified device property API

2015-11-30 Thread Wolfram Sang
On Mon, Nov 30, 2015 at 05:11:44PM +0200, Andy Shevchenko wrote:
> From: Mika Westerberg 
> 
> 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 
> Signed-off-by: Andy Shevchenko 
> Acked-by: Jarkko Nikula 

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 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -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 = 40;
>  
> - 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 != 10 && clk_freq != 40) {
> - 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 != 10 && clk_freq != 40) {
> + dev_err(&pdev->dev, "Only 100kHz and 400kHz supported");
> + return -EINVAL;
>   }
>  
>   r = i2c_dw_eval_lock_support(dev);
> -- 
> 2.6.2
> 


signature.asc
Description: Digital signature