Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1280237 > unrolled thread

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

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: [PATCH v2 16/16] i2c: designware: Convert to use unified device  property API Wolfram Sang <wsa@the-dreams.de> - 2015-11-30 21:00 +0100
    Re: [PATCH v2 16/16] i2c: designware: Convert to use unified device  property API Mika Westerberg <mika.westerberg@linux.intel.com> - 2015-12-01 10:10 +0100
    Re: [PATCH v2 16/16] i2c: designware: Convert to use unified device  property API Andy Shevchenko <andriy.shevchenko@linux.intel.com> - 2015-12-01 11:40 +0100
      Re: [PATCH v2 16/16] i2c: designware: Convert to use unified device property API "Rafael J. Wysocki" <rjw@rjwysocki.net> - 2015-12-02 02:00 +0100
        Re: [PATCH v2 16/16] i2c: designware: Convert to use unified device  property API Andy Shevchenko <andriy.shevchenko@linux.intel.com> - 2015-12-02 10:30 +0100
          Re: [PATCH v2 16/16] i2c: designware: Convert to use unified device  property API Mika Westerberg <mika.westerberg@linux.intel.com> - 2015-12-02 10:40 +0100
            Re: [PATCH v2 16/16] i2c: designware: Convert to use unified device  property API Wolfram Sang <wsa@the-dreams.de> - 2015-12-02 11:00 +0100

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

[Multipart message — attachments visible in raw view] — view raw

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
> 

[toc] | [next] | [standalone]

#1280660

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-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1280738

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.

-- 
Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Intel Finland Oy

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

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

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-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1281545

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 <andriy.shevchenko@linux.intel.com>
Intel Finland Oy

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1281561

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-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1281570

[Multipart message — attachments visible in raw view] — view raw

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>

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web