Re: [PATCH v4 0/22] On-demand device probing

On 09/08/2015 02:30 AM, Tomeu Vizoso wrote: > On 7 September 2015 at 22:50, Rob Herring wrote: >> On Mon, Sep 7, 2015 at 7:23 AM, Tomeu Vizoso >> wrote: >>> Hello, >>> >>> I have a problem with the panel on my Tegra Chromebook taking longer >>> than expected to be ready during boot (Stéphane Mar

Re: [PATCH 0/9] i2c: rcar: tackle race conditions in the driver

Hi Wolfram, On Tue, Sep 8, 2015 at 7:53 PM, Wolfram Sang wrote: > >> Yes, now a HD-ready TV is hooked up. It should give you something over >> EDID. Let me know when you're done and I'll move things back. > > 'No EDID data' says bootlog. Also, all 0 when reading that i2c client > address afterwar

[Patch V7] i2c: imx: add runtime pm support to improve the performance

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

RE: [Patch V7] i2c: imx: add runtime pm support to improve the performance

From: linux-i2c-ow...@vger.kernel.org On Behalf Of Uwe Kleine-K?nig Sent: Tuesday, September 08, 2015 5:18 AM > To: Gao Pan-B54642 > Cc: w...@the-dreams.de; linux-i2c@vger.kernel.org; Li Frank-B20596; Duan > Fugang-B38611; ker...@pengutronix.de; hkallwe...@

Re: [PATCH v3 2/2] drm: bridge/dw_hdmi: add dw hdmi i2c bus adapter support

> Wolfram, do you know of any cases where adapter->dev.of_node would not > be the same as adapter->dev.parent->of_node? i2c-muxes, I'd say. dev.parent is the device of the parent I2C adapter, while the devices get populated from the of_node of the muxing device. signature.asc Description: Digi

Re: [Patch v2] i2c: imx: implement bus recovery

Hello, On Tue, Sep 08, 2015 at 04:18:41PM +0200, Linus Walleij wrote: > On Mon, Sep 7, 2015 at 10:00 AM, Uwe Kleine-König > wrote: > > [Me] > > >> If the use case is around the i2c traffic, it is a mode related to I2C, > >> and if this mode is called "GPIO mode" in the data sheet > >> is irrelev

Re: [Patch v2] i2c: imx: implement bus recovery

On Mon, Sep 7, 2015 at 10:00 AM, Uwe Kleine-König wrote: > [Me] >> If the use case is around the i2c traffic, it is a mode related to I2C, >> and if this mode is called "GPIO mode" in the data sheet >> is irrelevant, because it is obviously not used for the generic >> input/output but the specifi

Re: [PATCH v3 1/4] i2c: tegra: implement slave mode

Wolfram, thanks! On 08.09.2015 14:46, Wolfram Sang wrote: Sorry for the long delay. I tried to analyze the issue. Attached patch works on AC100 (Misha Komarovsky helped me with testing). Wolfram could you please try the patch with your environment? No change, sadly. I don't get slave interr

Re: [PATCH v3 1/4] i2c: tegra: implement slave mode

> Sorry for the long delay. I tried to analyze the issue. Attached patch works > on AC100 (Misha Komarovsky helped me with testing). > > Wolfram could you please try the patch with your environment? No change, sadly. I don't get slave interrupts. > Init function is called multuple times. If I2C

Re: [PATCH 0/9] i2c: rcar: tackle race conditions in the driver

> Yes, now a HD-ready TV is hooked up. It should give you something over > EDID. Let me know when you're done and I'll move things back. 'No EDID data' says bootlog. Also, all 0 when reading that i2c client address afterwards. I don't see or sense anything suspicious with the I2C transfers itself

[PATCH] i2c-dev: Fix typo in ioctl name reference

The ioctl is named I2C_RDWR for "I2C read/write". But references to it were misspelled "rdrw". Fix them. Signed-off-by: Jean Delvare Cc: Wolfram Sang --- drivers/i2c/i2c-dev.c|6 +++--- fs/compat_ioctl.c|2 +- include/uapi/linux/i2c-dev.h |4 +++- 3 files changed

Re: [PATCH v4 0/22] On-demand device probing

On 7 September 2015 at 22:50, Rob Herring wrote: > On Mon, Sep 7, 2015 at 7:23 AM, Tomeu Vizoso > wrote: >> Hello, >> >> I have a problem with the panel on my Tegra Chromebook taking longer >> than expected to be ready during boot (Stéphane Marchesin reported what >> is basically the same issue