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

[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

[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

[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

[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

[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(>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(>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", );
> -
> - of_property_read_u32(pdev->dev.of_node,
> -  "i2c-sda-falling-time-ns",
> -  >sda_falling_time);
> - of_property_read_u32(pdev->dev.of_node,
> -  "i2c-scl-falling-time-ns",
> -  >scl_falling_time);
> -
> - of_property_read_u32(pdev->dev.of_node, "clock-frequency",
> -  _freq);
> -
> - /* Only standard mode at 100kHz and fast mode at 400kHz
> -  * are supported.
> -  */
> - if (clk_freq != 10 && clk_freq != 40) {
> - dev_err(>dev, "Only 100kHz and 400kHz supported");
> - return -EINVAL;
> - }
> + if (pdata) {
> + clk_freq = pdata->i2c_scl_freq;
>   } else {
> - pdata = dev_get_platdata(>dev);
> - if (pdata)
> - clk_freq = pdata->i2c_scl_freq;
> + device_property_read_u32(>dev, "i2c-sda-hold-time-ns",
> +  );
> + device_property_read_u32(>dev, "i2c-sda-falling-time-ns",
> +  >sda_falling_time);
> + device_property_read_u32(>dev, "i2c-scl-falling-time-ns",
> +  >scl_falling_time);
> + device_property_read_u32(>dev, "clock-frequency",
> +  _freq);
> + }
> +
> + if (has_acpi_companion(>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(>dev, "Only 100kHz and 400kHz supported");
> + return -EINVAL;
>   }
>  
>   r = i2c_dw_eval_lock_support(dev);
> -- 
> 2.6.2
> 


signature.asc
Description: Digital signature