Re: [Resend Patch 0/9] I2C ACPI operation region handler support
On Tue, 2014-04-22 at 14:24 +0800, Lan Tianyu wrote: > ACPI 5.0 spec(5.5.2.4.5) defines GenericSerialBus(i2c, spi, uart) operation > region. It allows ACPI aml code able to access such kind of devices to > implement some ACPI standard method. > > On the Asus T100TA, Bios use GenericSerialBus operation region to access > i2c device to get battery info. So battery function depends on the I2C > operation region support. Here is the bug link. > https://bugzilla.kernel.org/show_bug.cgi?id=69011 > > This patchset is to add I2C ACPI operation region handler support. For what it's worth, I've tested this patchset with the exception of patch 9/9 - which I leave out because it would require annoying fiddling with my kernel builds - and it gives apparently-accurate battery/AC information on my Venue 8 Pro. It doesn't *obviously* cause any other problems, though there are a few other issues I'm dealing with ATM. If any of them turn out to be related to this patch set, I'll send a follow-up. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net -- 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 0/7] Add cros_ec changes for newer boards
On 04/23/2014 06:32 AM, Lee Jones wrote: > On Tue, 22 Apr 2014, Doug Anderson wrote: > >> This series adds the most critical cros_ec changes for newer boards >> using cros_ec. Specifically: >> * Fixes timing/locking issues with the previously upstreamed (but >> never used upstream) cros_ec_spi driver. >> * Updates the cros_ec header file to the latest version which allows >> us to use newer EC features like i2c tunneling. >> * Adds an i2c tunnel driver to allow communication to the EC's i2c >> devices. >> >> This _doesn't_ get the EC driver fully up to speed with what's in the >> current Chromium OS trees. There are a whole slew of cleanup patches >> there, an addition of an LPC transport mode, and exports of functions >> to userspace. Once these patches land and we have functionality we >> can continue to pick more cleanup patches. ... > Need to wait for the ARM, DT and I2C guys to review, at which point > I'll be happy to take in and supply a branch for them to pull from if > required. If there are no _true_ dependencies and the MFD changes can > be added independently without fear of build breakages, let me know > and I'll apply them separately. I believe there aren't direct dependencies between the patches. So, the MFD patches can be applied to the MFD tree and the DT patch applied to the Tegra tree. I'm simply waiting for the MFD patches to be applied before applying the DT patch so that I know the DT binding definition is fully accepted before applying a patch that uses it. -- 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 6/7] i2c: ChromeOS EC tunnel driver
On Tue, 22 Apr 2014, Doug Anderson wrote: > On ARM Chromebooks we have a few devices that are accessed by both the > AP (the main "Application Processor") and the EC (the Embedded > Controller). These are: > * The battery (sbs-battery). > * The power management unit tps65090. > > On the original Samsung ARM Chromebook these devices were on an I2C > bus that was shared between the AP and the EC and arbitrated using > some extranal GPIOs (see i2c-arb-gpio-challenge). > > The original arbitration scheme worked well enough but had some > downsides: > * It was nonstandard (not using standard I2C multimaster) > * It only worked if the EC-AP communication was I2C > * It was relatively hard to debug problems (hard to tell if i2c issues > were caused by the EC, the AP, or some device on the bus). > > On the HP Chromebook 11 the design was changed to: > * The AP/EC comms were still i2c, but the battery/tps65090 were no > longer on the bus used for AP/EC communication. The battery was > exposed to the AP through a limited i2c tunnel and tps65090 was > exposed to the AP through a custom Linux driver. > > On the Samsung ARM Chromebook 2 the scheme is changed yet again, now: > * The AP/EC comms are now using SPI for faster speeds. > * The EC's i2c bus is exposed to the AP through a full i2c tunnel. > > The upstream "tegra124-venice2" uses the same scheme as the Samsung > ARM Chromebook 2, though it has a different set of components on the > other side of the bus. > > This driver supports the scheme used by the Samsung ARM Chromebook 2. > Future patches to this driver could add support for the battery tunnel > on the HP Chromebook 11 (and perhaps could even be used to access > tps65090 on the HP Chromebook 11 instead of using a special driver, > but I haven't researched that enough). > > Signed-off-by: Vincent Palatin > Signed-off-by: Simon Glass > Signed-off-by: Doug Anderson > Tested-by: Andrew Bresticker > Tested-by: Stephen Warren > --- > Changes in v2: > - Update tunnel binding as per swarren > > .../devicetree/bindings/i2c/i2c-cros-ec-tunnel.txt | 39 +++ > drivers/i2c/busses/Kconfig | 9 + > drivers/i2c/busses/Makefile| 1 + > drivers/i2c/busses/i2c-cros-ec-tunnel.c| 304 > + > drivers/mfd/cros_ec.c | 5 + For the MFD changes: Acked-by: Lee Jones -- 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-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 0/7] Add cros_ec changes for newer boards
On Tue, 22 Apr 2014, Doug Anderson wrote: > This series adds the most critical cros_ec changes for newer boards > using cros_ec. Specifically: > * Fixes timing/locking issues with the previously upstreamed (but > never used upstream) cros_ec_spi driver. > * Updates the cros_ec header file to the latest version which allows > us to use newer EC features like i2c tunneling. > * Adds an i2c tunnel driver to allow communication to the EC's i2c > devices. > > This _doesn't_ get the EC driver fully up to speed with what's in the > current Chromium OS trees. There are a whole slew of cleanup patches > there, an addition of an LPC transport mode, and exports of functions > to userspace. Once these patches land and we have functionality we > can continue to pick more cleanup patches. > > Changes in v2: > - Update tunnel binding as per swarren > - Removed i2c20 alias for i2c tunnel > > Bill Richardson (1): > mfd: cros_ec: Sync to the latest cros_ec_commands.h from EC sources > > David Hendricks (1): > mfd: cros_ec: spi: calculate delay between transfers correctly > > Doug Anderson (5): > mfd: cros_ec: spi: Add mutex to cros_ec_spi > mfd: cros_ec: spi: Make the cros_ec_spi timeout more reliable > mfd: cros_ec: spi: Increase cros_ec_spi deadline from 5ms to 100ms > i2c: ChromeOS EC tunnel driver > ARM: tegra: Add the EC i2c tunnel to tegra124-venice2 > > .../devicetree/bindings/i2c/i2c-cros-ec-tunnel.txt | 39 + > arch/arm/boot/dts/tegra124-venice2.dts | 26 + > drivers/i2c/busses/Kconfig |9 + > drivers/i2c/busses/Makefile|1 + > drivers/i2c/busses/i2c-cros-ec-tunnel.c| 304 ++ > drivers/mfd/cros_ec.c |7 +- > drivers/mfd/cros_ec_spi.c | 67 +- > include/linux/mfd/cros_ec.h|4 +- > include/linux/mfd/cros_ec_commands.h | 1128 > ++-- > 9 files changed, 1493 insertions(+), 92 deletions(-) > create mode 100644 > Documentation/devicetree/bindings/i2c/i2c-cros-ec-tunnel.txt > create mode 100644 drivers/i2c/busses/i2c-cros-ec-tunnel.c Need to wait for the ARM, DT and I2C guys to review, at which point I'll be happy to take in and supply a branch for them to pull from if required. If there are no _true_ dependencies and the MFD changes can be added independently without fear of build breakages, let me know and I'll apply them separately. -- 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-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] i2c: s3c2410: resume race fix
Doug Anderson wrote: > > From: Olof Johansson > > Don't unmark the device as suspended until after it's been re-setup. > > The main race would be w.r.t. an i2c driver that gets resumed at the same > time (asyncronously), that is allowed to do a transfer since suspended > is set to 0 before reinit, but really should have seen the -EIO return > instead. > > Signed-off-by: Olof Johansson > Signed-off-by: Doug Anderson Acked-by: Kukjin Kim Thanks, Kukjin > --- > drivers/i2c/busses/i2c-s3c2410.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/i2c/busses/i2c-s3c2410.c b/drivers/i2c/busses/i2c- > s3c2410.c > index ae44910..bb3a996 100644 > --- a/drivers/i2c/busses/i2c-s3c2410.c > +++ b/drivers/i2c/busses/i2c-s3c2410.c > @@ -1276,10 +1276,10 @@ static int s3c24xx_i2c_resume(struct device *dev) > struct platform_device *pdev = to_platform_device(dev); > struct s3c24xx_i2c *i2c = platform_get_drvdata(pdev); > > - i2c->suspended = 0; > clk_prepare_enable(i2c->clk); > s3c24xx_i2c_init(i2c); > clk_disable_unprepare(i2c->clk); > + i2c->suspended = 0; > > return 0; > } > -- > 1.9.1.423.g4596e3a -- 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: [Resend Patch 9/9] I2C/ACPI: Add CONFIG_I2C_ACPI config
On Wed, Apr 23, 2014 at 06:47:05AM +, Zheng, Lv wrote: > Hi, Tianyu > > > From: Lan, Tianyu > > Sent: Wednesday, April 23, 2014 1:40 PM > > > > On 2014年04月22日 19:45, Mika Westerberg wrote: > > > On Tue, Apr 22, 2014 at 02:24:15PM +0800, Lan Tianyu wrote: > > >> This patch is to add CONFIG_I2C_ACPI. Current there is a race between > > >> removing I2C ACPI operation region and ACPI AML code accessing. > > >> So make i2c core built-in if CONFIG_I2C_ACPI is set. > > >> > > >> Signed-off-by: Lan Tianyu > > >> --- > > >> drivers/i2c/Kconfig | 17 - > > >> drivers/i2c/Makefile | 2 +- > > >> include/linux/i2c.h | 2 +- > > >> 3 files changed, 18 insertions(+), 3 deletions(-) > > >> > > >> diff --git a/drivers/i2c/Kconfig b/drivers/i2c/Kconfig > > >> index 7b7ea32..c670d49 100644 > > >> --- a/drivers/i2c/Kconfig > > >> +++ b/drivers/i2c/Kconfig > > >> @@ -2,7 +2,9 @@ > > >> # I2C subsystem configuration > > >> # > > >> > > >> -menuconfig I2C > > >> +menu "I2C support" > > >> + > > >> +config I2C > > >> tristate "I2C support" > > >> select RT_MUTEXES > > >> ---help--- > > >> @@ -21,6 +23,17 @@ menuconfig I2C > > >>This I2C support can also be built as a module. If so, the > > >> module > > >>will be called i2c-core. > > >> > > >> +config I2C_ACPI > > >> +bool "I2C ACPI support" > > >> +select I2C > > >> +depends on ACPI > > >> +default y > > >> +help > > >> + Say Y here if you want to enable I2C ACPI function. ACPI table > > >> + provides I2C slave devices' information to enumerate these > > >> devices. > > >> + This option also allows ACPI AML code to access I2C slave > > >> devices > > >> + via I2C ACPI operation region to fulfill ACPI method. > > >> + > > > > > > I'm wondering, can we provide some sort of wrapper function from ACPI core > > > that is guaranteed to be built in to the kernel image and use it instead > > > of > > > adding new Kconfig options? > > > > > Cc: LV > > > > LV tried to fix the issue via wrapper solution in the ACPI code before. > > https://lkml.org/lkml/2013/7/23/87 > > > > He has a plan to resolve the issue in ACPICA later. > > > > Other choice is to increase the i2c-core module count to prevent it > > being unloaded when i2c operation region handler is installed. Remove > > the code When LV finish his job. > > You may see it implemented in ACPICA after several release. > If you need a fix for now, you can use the patch pointed to by the link > you've provided, > Or you could find an updated one here: > acpi-ipmi13.patch archived in > (https://bugzilla.kernel.org/attachment.cgi?id=112611) > > I think the solution you've provided in this patch is also reasonable for now. > IPMI also uses a similar solution to solve this issue. > Please refer to the CONFIG_ACPI_IPMI. > > The story can be found at: > http://www.spinics.net/lists/linux-acpi/msg49044.html > And the similar solution can be found at: > http://www.spinics.net/lists/linux-acpi/msg49184.html Thanks for the pointers. Given that the IPMI problem was solved like this I guess I2C operation regions can follow the same pattern if there is no better solution available. Out of curiousity: how did you plan to fix this in ACPICA? -- 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: [Resend Patch 7/9] I2C/ACPI: Add i2c ACPI operation region support
On 2014年04月23日 15:28, Mika Westerberg wrote: > On Wed, Apr 23, 2014 at 09:53:21AM +0800, Lan Tianyu wrote: >> Hi Mika: >> Thanks a lot for your review. >> >> On 2014年04月22日 19:36, Mika Westerberg wrote: > + > + client.adapter = adapter; > + client.addr = sb->slave_address; > + client.flags = 0; >>> I'm not sure if this is the correct way to use struct i2c_client >>> (allocating it from stack and passing forward to functions that might >>> expect a real i2c_client structure). It has ->dev and all. >> >> I check all i2c_smbus_xxx helper functions and they are simple wrappers >> of i2c_smbus_xfer(). Only adapter, addr and flags of struct client are >> used in these functions. > > In that case I suppose it is OK to (ab)use the client structure like this. > > I think you still want to initialize the whole structure (unused fields > with zero) before passing it to the wrappers. > Ok. I will do that. -- Best regards Tianyu Lan -- 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 22/33] ARM: shmobile: Use r8a7740 suffix for i2c, mmcif, fsi2 compat strings
Hi Wolfram,
On Wed, Apr 23, 2014 at 9:18 AM, Wolfram Sang wrote:
>> > - compatible = "renesas,rmobile-iic";
>> > + compatible = "renesas,iic-r8a7740", "renesas,rmobile-iic";
>>
>> I see an opportunity for improvement here: this driver doesn't seem to have
>> any bindings documented under Documentation/devicetree/bindings/?
>
> I am brushing up this driver currently, so consider it done. Just
That's great to hear, thanks!
> waiting for a minor email issue to be solved before I can send out
> patches.
Good luck!
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
--
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: [Resend Patch 7/9] I2C/ACPI: Add i2c ACPI operation region support
On Wed, Apr 23, 2014 at 09:53:21AM +0800, Lan Tianyu wrote: > Hi Mika: > Thanks a lot for your review. > > On 2014年04月22日 19:36, Mika Westerberg wrote: > >> > + > >> > +client.adapter = adapter; > >> > +client.addr = sb->slave_address; > >> > +client.flags = 0; > > I'm not sure if this is the correct way to use struct i2c_client > > (allocating it from stack and passing forward to functions that might > > expect a real i2c_client structure). It has ->dev and all. > > I check all i2c_smbus_xxx helper functions and they are simple wrappers > of i2c_smbus_xfer(). Only adapter, addr and flags of struct client are > used in these functions. In that case I suppose it is OK to (ab)use the client structure like this. I think you still want to initialize the whole structure (unused fields with zero) before passing it to the wrappers. -- 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 22/33] ARM: shmobile: Use r8a7740 suffix for i2c, mmcif, fsi2 compat strings
On Wed, Apr 23, 2014 at 09:09:49AM +0200, Geert Uytterhoeven wrote: > On Wed, Apr 23, 2014 at 3:25 AM, Simon Horman > wrote: > > From: Ulrich Hecht > > > > Add "renesas,*-r8a7740" to the compatible strings for consistency with other > > devices. > > > diff --git a/arch/arm/boot/dts/r8a7740.dtsi b/arch/arm/boot/dts/r8a7740.dtsi > > index 8280884..9f65986 100644 > > --- a/arch/arm/boot/dts/r8a7740.dtsi > > +++ b/arch/arm/boot/dts/r8a7740.dtsi > > @@ -126,7 +126,7 @@ > > > - compatible = "renesas,rmobile-iic"; > > + compatible = "renesas,iic-r8a7740", "renesas,rmobile-iic"; > > I see an opportunity for improvement here: this driver doesn't seem to have > any bindings documented under Documentation/devicetree/bindings/? I am brushing up this driver currently, so consider it done. Just waiting for a minor email issue to be solved before I can send out patches. signature.asc Description: Digital signature
Re: [PATCH 22/33] ARM: shmobile: Use r8a7740 suffix for i2c, mmcif, fsi2 compat strings
On Wed, Apr 23, 2014 at 3:25 AM, Simon Horman
wrote:
> From: Ulrich Hecht
>
> Add "renesas,*-r8a7740" to the compatible strings for consistency with other
> devices.
> diff --git a/arch/arm/boot/dts/r8a7740.dtsi b/arch/arm/boot/dts/r8a7740.dtsi
> index 8280884..9f65986 100644
> --- a/arch/arm/boot/dts/r8a7740.dtsi
> +++ b/arch/arm/boot/dts/r8a7740.dtsi
> @@ -126,7 +126,7 @@
> - compatible = "renesas,rmobile-iic";
> + compatible = "renesas,iic-r8a7740", "renesas,rmobile-iic";
I see an opportunity for improvement here: this driver doesn't seem to have
any bindings documented under Documentation/devicetree/bindings/?
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
--
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
