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

Groups > linux.kernel > #1237292 > unrolled thread

[PATCH v2 0/8] enable I2C devices behind I2C bus on Gen2

Started byAndy Shevchenko <andriy.shevchenko@linux.intel.com>
First post2015-10-01 13:30 +0200
Last post2015-10-05 09:40 +0200
Articles 6 — 3 participants

Back to article view | Back to linux.kernel

Contents

  [PATCH v2 0/8] enable I2C devices behind I2C bus on Gen2 Andy Shevchenko <andriy.shevchenko@linux.intel.com> - 2015-10-01 13:30 +0200
    [PATCH v2 3/8] mfd: intel_quark_i2c_gpio: load gpio driver first Andy Shevchenko <andriy.shevchenko@linux.intel.com> - 2015-10-01 13:30 +0200
      Re: [PATCH v2 3/8] mfd: intel_quark_i2c_gpio: load gpio driver first Lee Jones <lee.jones@linaro.org> - 2015-10-01 17:00 +0200
        Re: [PATCH v2 3/8] mfd: intel_quark_i2c_gpio: load gpio driver first Andy Shevchenko <andriy.shevchenko@linux.intel.com> - 2015-10-02 14:20 +0200
    Re: [PATCH v2 0/8] enable I2C devices behind I2C bus on Gen2 Linus Walleij <linus.walleij@linaro.org> - 2015-10-05 09:30 +0200
      Re: [PATCH v2 0/8] enable I2C devices behind I2C bus on Gen2 Andy Shevchenko <andriy.shevchenko@linux.intel.com> - 2015-10-05 09:40 +0200

#1237292 — [PATCH v2 0/8] enable I2C devices behind I2C bus on Gen2

FromAndy Shevchenko <andriy.shevchenko@linux.intel.com>
Date2015-10-01 13:30 +0200
Subject[PATCH v2 0/8] enable I2C devices behind I2C bus on Gen2
Message-ID<qeKdH-2A1-3@gated-at.bofh.it>
There is a board in the wild, i.e. Intel Galileo Gen2, that has ACPI enumerated
devices behind I2C bus.

This patch series dedicated to enable those devices. Meanwhile it also changes
I2C core to cope with ACPI 6.0 specification (patch 1/8).

The MFD framework is also updated to cope with interesting implementation of
the cell descriptions under ACPI MFD (patch 2/8).

The patches 7 and 8 are pretty independent, though they don't make much sense
without previous ones applied.

Srinivas, it would be nice to see your tag (ideally Tested-by) to be sure we
don't break ISH stuff.

Rafael, can you Ack / comment on patch 2 (and maybe 1)?

Since it touches multiple subsystems someone needs to create an immutable
branch. I don't actually know whose subsystem better here. Lee, Wolfram?

Apparently we would like to get ACKs / comments from the rest.

Tested on the actual Intel Galileo Gen2 by Ismo (gpio expanders) and me (at24).

Changelog v2:
- append tags
- re-make patch 3 (suggested by Lee)
- improve patch 8 (suggested by Thierry)

Andy Shevchenko (7):
  mfd: core: redo ACPI matching of the children devices
  mfd: intel_quark_i2c_gpio: load gpio driver first
  mfd: intel_quark_i2c_gpio: support devices behind i2c bus
  gpio: pca953x: store driver_data for future use
  gpio: pca953x: support ACPI devices found on Galileo Gen2
  at24: enable ACPI device found on Galileo Gen2
  pwm-pca9685: enable ACPI device found on Galileo Gen2

Mika Westerberg (1):
  i2c / ACPI: Rework I2C device scanning

 Documentation/acpi/enumeration.txt | 11 +++--
 drivers/gpio/gpio-pca953x.c        | 36 +++++++++++++----
 drivers/i2c/i2c-core.c             | 82 +++++++++++++++++++++++++++-----------
 drivers/mfd/intel_quark_i2c_gpio.c | 33 ++++++++++-----
 drivers/mfd/mfd-core.c             | 52 ++++++++++++++++--------
 drivers/misc/eeprom/at24.c         | 22 ++++++++--
 drivers/pwm/Kconfig                |  2 +-
 drivers/pwm/pwm-pca9685.c          | 20 ++++++++--
 include/linux/mfd/core.h           | 10 ++++-
 9 files changed, 199 insertions(+), 69 deletions(-)

-- 
2.5.1

--
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] | [next] | [standalone]

#1237293 — [PATCH v2 3/8] mfd: intel_quark_i2c_gpio: load gpio driver first

FromAndy Shevchenko <andriy.shevchenko@linux.intel.com>
Date2015-10-01 13:30 +0200
Subject[PATCH v2 3/8] mfd: intel_quark_i2c_gpio: load gpio driver first
Message-ID<qeKdJ-2A1-41@gated-at.bofh.it>
In reply to#1237292
On Intel Galileo boards the GPIO expander is connected to i2c bus. Moreover it
is able to generate interrupt, but interrupt line is connected to GPIO. That's
why we have to have GPIO driver in place when we will probe i2c host with
device connected to it.

Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
---
 drivers/mfd/intel_quark_i2c_gpio.c | 19 +++++++++----------
 1 file changed, 9 insertions(+), 10 deletions(-)

diff --git a/drivers/mfd/intel_quark_i2c_gpio.c b/drivers/mfd/intel_quark_i2c_gpio.c
index 1ce1603..958c134 100644
--- a/drivers/mfd/intel_quark_i2c_gpio.c
+++ b/drivers/mfd/intel_quark_i2c_gpio.c
@@ -90,19 +90,19 @@ static struct resource intel_quark_gpio_res[] = {
 
 static struct mfd_cell intel_quark_mfd_cells[] = {
 	{
-		.id = MFD_I2C_BAR,
-		.name = "i2c_designware",
-		.num_resources = ARRAY_SIZE(intel_quark_i2c_res),
-		.resources = intel_quark_i2c_res,
-		.ignore_resource_conflicts = true,
-	},
-	{
 		.id = MFD_GPIO_BAR,
 		.name = "gpio-dwapb",
 		.num_resources = ARRAY_SIZE(intel_quark_gpio_res),
 		.resources = intel_quark_gpio_res,
 		.ignore_resource_conflicts = true,
 	},
+	{
+		.id = MFD_I2C_BAR,
+		.name = "i2c_designware",
+		.num_resources = ARRAY_SIZE(intel_quark_i2c_res),
+		.resources = intel_quark_i2c_res,
+		.ignore_resource_conflicts = true,
+	},
 };
 
 static const struct pci_device_id intel_quark_mfd_ids[] = {
@@ -248,12 +248,11 @@ static int intel_quark_mfd_probe(struct pci_dev *pdev,
 
 	dev_set_drvdata(&pdev->dev, quark_mfd);
 
-	ret = intel_quark_i2c_setup(pdev, &intel_quark_mfd_cells[MFD_I2C_BAR]);
+	ret = intel_quark_i2c_setup(pdev, &intel_quark_mfd_cells[1]);
 	if (ret)
 		return ret;
 
-	ret = intel_quark_gpio_setup(pdev,
-				     &intel_quark_mfd_cells[MFD_GPIO_BAR]);
+	ret = intel_quark_gpio_setup(pdev, &intel_quark_mfd_cells[0]);
 	if (ret)
 		return ret;
 
-- 
2.5.1

--
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]

#1237485 — Re: [PATCH v2 3/8] mfd: intel_quark_i2c_gpio: load gpio driver first

FromLee Jones <lee.jones@linaro.org>
Date2015-10-01 17:00 +0200
SubjectRe: [PATCH v2 3/8] mfd: intel_quark_i2c_gpio: load gpio driver first
Message-ID<qeNuX-7IQ-29@gated-at.bofh.it>
In reply to#1237293
On Thu, 01 Oct 2015, Andy Shevchenko wrote:

> On Intel Galileo boards the GPIO expander is connected to i2c bus. Moreover it
> is able to generate interrupt, but interrupt line is connected to GPIO. That's
> why we have to have GPIO driver in place when we will probe i2c host with
> device connected to it.
> 
> Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
> ---
>  drivers/mfd/intel_quark_i2c_gpio.c | 19 +++++++++----------
>  1 file changed, 9 insertions(+), 10 deletions(-)

Acked-by: Lee Jones <lee.jones@linaro.org>

Are there build dependancies in this set?  Or can all patches filter
through their own subsystems?

> diff --git a/drivers/mfd/intel_quark_i2c_gpio.c b/drivers/mfd/intel_quark_i2c_gpio.c
> index 1ce1603..958c134 100644
> --- a/drivers/mfd/intel_quark_i2c_gpio.c
> +++ b/drivers/mfd/intel_quark_i2c_gpio.c
> @@ -90,19 +90,19 @@ static struct resource intel_quark_gpio_res[] = {
>  
>  static struct mfd_cell intel_quark_mfd_cells[] = {
>  	{
> -		.id = MFD_I2C_BAR,
> -		.name = "i2c_designware",
> -		.num_resources = ARRAY_SIZE(intel_quark_i2c_res),
> -		.resources = intel_quark_i2c_res,
> -		.ignore_resource_conflicts = true,
> -	},
> -	{
>  		.id = MFD_GPIO_BAR,
>  		.name = "gpio-dwapb",
>  		.num_resources = ARRAY_SIZE(intel_quark_gpio_res),
>  		.resources = intel_quark_gpio_res,
>  		.ignore_resource_conflicts = true,
>  	},
> +	{
> +		.id = MFD_I2C_BAR,
> +		.name = "i2c_designware",
> +		.num_resources = ARRAY_SIZE(intel_quark_i2c_res),
> +		.resources = intel_quark_i2c_res,
> +		.ignore_resource_conflicts = true,
> +	},
>  };
>  
>  static const struct pci_device_id intel_quark_mfd_ids[] = {
> @@ -248,12 +248,11 @@ static int intel_quark_mfd_probe(struct pci_dev *pdev,
>  
>  	dev_set_drvdata(&pdev->dev, quark_mfd);
>  
> -	ret = intel_quark_i2c_setup(pdev, &intel_quark_mfd_cells[MFD_I2C_BAR]);
> +	ret = intel_quark_i2c_setup(pdev, &intel_quark_mfd_cells[1]);
>  	if (ret)
>  		return ret;
>  
> -	ret = intel_quark_gpio_setup(pdev,
> -				     &intel_quark_mfd_cells[MFD_GPIO_BAR]);
> +	ret = intel_quark_gpio_setup(pdev, &intel_quark_mfd_cells[0]);
>  	if (ret)
>  		return ret;
>  

-- 
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
--
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]

#1238154 — Re: [PATCH v2 3/8] mfd: intel_quark_i2c_gpio: load gpio driver first

FromAndy Shevchenko <andriy.shevchenko@linux.intel.com>
Date2015-10-02 14:20 +0200
SubjectRe: [PATCH v2 3/8] mfd: intel_quark_i2c_gpio: load gpio driver first
Message-ID<qf7tE-351-13@gated-at.bofh.it>
In reply to#1237485
On Thu, 2015-10-01 at 15:54 +0100, Lee Jones wrote:
> On Thu, 01 Oct 2015, Andy Shevchenko wrote:
> 
> > On Intel Galileo boards the GPIO expander is connected to i2c bus. 
> > Moreover it
> > is able to generate interrupt, but interrupt line is connected to 
> > GPIO. That's
> > why we have to have GPIO driver in place when we will probe i2c 
> > host with
> > device connected to it.
> > 
> > Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
> > ---
> >  drivers/mfd/intel_quark_i2c_gpio.c | 19 +++++++++----------
> >  1 file changed, 9 insertions(+), 10 deletions(-)
> 
> Acked-by: Lee Jones <lee.jones@linaro.org>
> 
> Are there build dependancies in this set?  Or can all patches filter
> through their own subsystems?

Practically patches 4-8 can go by their own, though it makes not much
sense since it doesn't add a value (they will be not enumerated until
patches 1-4 made an upstream).

> 
> > diff --git a/drivers/mfd/intel_quark_i2c_gpio.c 
> > b/drivers/mfd/intel_quark_i2c_gpio.c
> > index 1ce1603..958c134 100644
> > --- a/drivers/mfd/intel_quark_i2c_gpio.c
> > +++ b/drivers/mfd/intel_quark_i2c_gpio.c
> > @@ -90,19 +90,19 @@ static struct resource intel_quark_gpio_res[] = 
> > {
> >  
> >  static struct mfd_cell intel_quark_mfd_cells[] = {
> >  	{
> > -		.id = MFD_I2C_BAR,
> > -		.name = "i2c_designware",
> > -		.num_resources = ARRAY_SIZE(intel_quark_i2c_res),
> > -		.resources = intel_quark_i2c_res,
> > -		.ignore_resource_conflicts = true,
> > -	},
> > -	{
> >  		.id = MFD_GPIO_BAR,
> >  		.name = "gpio-dwapb",
> >  		.num_resources = ARRAY_SIZE(intel_quark_gpio_res),
> >  		.resources = intel_quark_gpio_res,
> >  		.ignore_resource_conflicts = true,
> >  	},
> > +	{
> > +		.id = MFD_I2C_BAR,
> > +		.name = "i2c_designware",
> > +		.num_resources = ARRAY_SIZE(intel_quark_i2c_res),
> > +		.resources = intel_quark_i2c_res,
> > +		.ignore_resource_conflicts = true,
> > +	},
> >  };
> >  
> >  static const struct pci_device_id intel_quark_mfd_ids[] = {
> > @@ -248,12 +248,11 @@ static int intel_quark_mfd_probe(struct 
> > pci_dev *pdev,
> >  
> >  	dev_set_drvdata(&pdev->dev, quark_mfd);
> >  
> > -	ret = intel_quark_i2c_setup(pdev, 
> > &intel_quark_mfd_cells[MFD_I2C_BAR]);
> > +	ret = intel_quark_i2c_setup(pdev, 
> > &intel_quark_mfd_cells[1]);
> >  	if (ret)
> >  		return ret;
> >  
> > -	ret = intel_quark_gpio_setup(pdev,
> > -				    
> >  &intel_quark_mfd_cells[MFD_GPIO_BAR]);
> > +	ret = intel_quark_gpio_setup(pdev, 
> > &intel_quark_mfd_cells[0]);
> >  	if (ret)
> >  		return ret;
> >  
> 

-- 
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]

#1239319

FromLinus Walleij <linus.walleij@linaro.org>
Date2015-10-05 09:30 +0200
Message-ID<qg8nD-wz-13@gated-at.bofh.it>
In reply to#1237292
On Thu, Oct 1, 2015 at 1:20 PM, Andy Shevchenko
<andriy.shevchenko@linux.intel.com> wrote:

> The patches 7 and 8 are pretty independent, though they don't make much sense
> without previous ones applied.

To me it seems patches 5 & 6 (GPIO patches) can be applied as-is
to my GPIO tree without any bad side effects. Is this correct?

In that case I will apply them.

Yours,
Linus Walleij
--
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]

#1239324

FromAndy Shevchenko <andriy.shevchenko@linux.intel.com>
Date2015-10-05 09:40 +0200
Message-ID<qg8xk-HJ-11@gated-at.bofh.it>
In reply to#1239319
On Mon, 2015-10-05 at 09:20 +0200, Linus Walleij wrote:
> On Thu, Oct 1, 2015 at 1:20 PM, Andy Shevchenko
> <andriy.shevchenko@linux.intel.com> wrote:
> 
> > The patches 7 and 8 are pretty independent, though they don't make 
> > much sense
> > without previous ones applied.
> 
> To me it seems patches 5 & 6 (GPIO patches) can be applied as-is
> to my GPIO tree without any bad side effects. Is this correct?

Yes, that's correct.

> 
> In that case I will apply them.
> 
> Yours,
> Linus Walleij

-- 
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] | [standalone]

Back to top | Article view | linux.kernel

csiph-web