Hello Mark,
On 21/08/15 20:25, ext Mark Rutland wrote:
>> Now as "i2c-davinci" driver has special handling for Keystone it's time to
>> switch
>> > the device tree to use new "compatible" property.
>> >
>> > Signed-off-by: Alexander Sverdlin
>> > ---
>> > arch/arm/boot/dts/keystone.dtsi |6
Commit 70762abb9f89 ("i2c: Use stable dev_name for ACPI enumerated I2C
slaves") broke the lm-sensors which relies on I2C hwmon slave devices under
/sys/bus/i2c/devices/ to be named as "x-00yz". However if those hwmon
devices are ACPI 5 enumerated their name became "i2c-INTABCD:ij" and sysfs
code in
> Do we want to insist on a much larger change (conversion to regmap)
> when if this in place, a simple single functional call change will do the
> job?
I'd assume that regmap conversion will happen later quite likely anyhow.
Most of those devices will have I2C/SPI dual interfaces; or people will
> > Just by chance I stumbled across this driver and the recently added
> > runtime PM code.
> > Two things in i2c_imx_probe look suspicious to me:
> >
> > - You activate the I2C clock and then initialize runtime PM with
> >
> > pm_runtime_enable(&pdev->dev);
> > pm_runtime_set_autosuspe
On Wed, Aug 19, 2015 at 01:19:57PM +0200, Javier Martinez Canillas wrote:
> The ChromeOS EC tunnel I2C bus driver depend on CROS_EC_PROTO but
> MFD_CROS_EC select CROS_EC_PROTO instead. Mixing select and depends
> on is bad practice as it may lead to circular Kconfig dependencies.
>
> Since the pl
On Tue, Aug 18, 2015 at 12:12:19PM +0300, Dan Carpenter wrote:
> The dma_mapping_error() function returns true if there is an error, it
> doesn't return an error code. We should return -ENOMEM.
>
> Signed-off-by: Dan Carpenter
Applied to for-next, thanks!
signature.asc
Description: Digital s
> > When reviewing V2, I wasn't comfortable with just guessing what the old
> > code means. So, I did some digging and found:
> >
> > https://lkml.org/lkml/2008/8/10/204
> >
> > Quoting the interesting paragraph from David Brownell:
> >
> > ===
> >
> > Better would be to preserve any existing sett
On Mon, Aug 17, 2015 at 11:52:51PM -0700, Dmitry Torokhov wrote:
> Instead of having each i2c driver individually parse device tree data in
> case it or platform supports separate wakeup interrupt, and handle
> enabling and disabling wakeup interrupts in their power management
> routines, let's hav
On Mon, Aug 24, 2015 at 01:52:02PM +0300, Jarkko Nikula wrote:
> Commit 70762abb9f89 ("i2c: Use stable dev_name for ACPI enumerated I2C
> slaves") broke the lm-sensors which relies on I2C hwmon slave devices under
> /sys/bus/i2c/devices/ to be named as "x-00yz". However if those hwmon
> devices are
Hi,
Any comments are welcome.
Thanks,
Zhonghui
On 2015/8/18 0:07, Fu, Zhonghui wrote:
> Enable i2c device to suspend/resume asynchronously. This can improve
> system suspend/resume speed.
>
> Signed-off-by: Zhonghui Fu
> ---
> drivers/i2c/i2c-core.c |1 +
> 1 files changed, 1 insertions
Hi,
Any comments are welcome.
Thanks,
Zhonghui
On 2015/8/18 0:17, Fu, Zhonghui wrote:
> Enable i2c adapter to suspend/resume asynchronously. This can improve
> system suspend/resume speed.
>
> Signed-off-by: Zhonghui Fu
> ---
> drivers/i2c/i2c-core.c |2 ++
> 1 files changed, 2 insertio
Hi,
Any comments are welcome.
Thanks,
Zhonghui
On 2015/8/18 0:36, Fu, Zhonghui wrote:
> Enable i2c controller to suspend/resume asynchronously. This can improve
> system suspend/resume speed.
>
> Signed-off-by: Zhonghui Fu
> ---
> drivers/i2c/busses/i2c-designware-platdrv.c |1 +
> 1 fi
On Monday, August 24, 2015 03:26:13 PM Wolfram Sang wrote:
> On Mon, Aug 24, 2015 at 01:52:02PM +0300, Jarkko Nikula wrote:
> > Commit 70762abb9f89 ("i2c: Use stable dev_name for ACPI enumerated I2C
> > slaves") broke the lm-sensors which relies on I2C hwmon slave devices under
> > /sys/bus/i2c/dev
In our former i2c driver, i2c clk is enabled and disabled in
xfer function, which contributes to power saving. However,
the clk enable process brings a busy wait delay until the core
is stable. As a result, the performance is sacrificed.
To weigh the power consumption and i2c bus performance, runt
On Mon Aug 24 13:52, Jarkko Nikula wrote:
> I don't know how common ACPI enumerated I2C hwmon devices are but I guess
> they exists since Dustin notices this issue and wrote "With that change,
> /sys/bus/i2c/devices/i2c-0-004a, for example, became
> /sys/bus/i2c/devices/i2c-PNP:xx".
I wouldn'
On Mon Aug 17 11:00, Jarkko Nikula wrote:
> If I remember correctly ACPI ID should not ever change and instance id :xy
> after INTABCD:xy should also be visible and keep the order even if device is
> disabled or not plugged. But I'm not absolute sure about this.
>
> At least on a test platform th
On Mon, Aug 24, 2015 at 01:52:02PM +0300, Jarkko Nikula wrote:
> Commit 70762abb9f89 ("i2c: Use stable dev_name for ACPI enumerated I2C
> slaves") broke the lm-sensors which relies on I2C hwmon slave devices under
> /sys/bus/i2c/devices/ to be named as "x-00yz". However if those hwmon
> devices are
Hello,
This is a resend of the patches that were not picked from the series
"[PATCH 00/27] Export I2C and OF module aliases in missing drivers" [0]
posted about a month ago.
The patches have no dependencies and can be picked individually by the
relevant maintainer.
I preferred to resend instead
The I2C core always reports the MODALIAS uevent as "i2c:"
regardless of the mechanism that was used to register the device
(i.e: OF or board code) and the table that is used later to match
the driver with the device (i.e: I2C id table or OF match table).
So drivers needs to export the I2C id table
Am 25.08.2015 um 04:20 schrieb Gao Pan:
> In our former i2c driver, i2c clk is enabled and disabled in
> xfer function, which contributes to power saving. However,
> the clk enable process brings a busy wait delay until the core
> is stable. As a result, the performance is sacrificed.
>
> To weigh
20 matches
Mail list logo
