Re: [RESEND PATCH 0/9] eeprom: at24: at24cs series serial number read

2015-10-21 16:23 GMT+02:00 Peter Korsgaard : >> "Bartosz" == Bartosz Golaszewski writes: > > >> As the serial number is available on a separate i2c address, wouldn't > >> it be simpler to handle these as special (read only) device variants and

[PATCH v2 2/2] i2c: at91: manage unexpected RXRDY flag when starting a transfer

In some cases, we could start a new i2c transfer with the RXRDY flag set. It is not a clean state and it leads to print annoying error messages even if there no real issue. The cause is only having garbage data in the Receive Holding Register because of a weird behavior of the RXRDY flag.

[PATCH v2 1/2] i2c: at91: fix write transfers by clearing pending interrupt first

From: Cyrille Pitchen In some cases a NACK interrupt may be pending in the Status Register (SR) as a result of a previous transfer. However at91_do_twi_transfer() did not read the SR to clear pending interruptions before starting a new transfer. Hence a NACK interrupt

Re: [RESEND PATCH 0/9] eeprom: at24: at24cs series serial number read

> "Bartosz" == Bartosz Golaszewski writes: Hi, >> > I wanted to respond that this way we would not be protected from >> > concurrent accesses, but then I saw I didn't actually include any >> > locks in the serial read function - my bad. It needs to be fixed as

Re: [PATCH v2 6/6] i2c: designware: Move common probe code into i2c_dw_probe()

Hi On 10/20/2015 07:32 PM, Wolfram Sang wrote: There was a merge conflict with a bugfix from i2c/for-current. I think it is okay, but you may want to double check my i2c/for-next. Looks like pm_runtime_disable() got dropped from your 36d48fb5766a ("i2c: designware-platdrv: enable RuntimePM

Re: [RESEND PATCH 0/9] eeprom: at24: at24cs series serial number read

> "Bartosz" == Bartosz Golaszewski writes: >> As the serial number is available on a separate i2c address, wouldn't >> it be simpler to handle these as special (read only) device variants and >> instantiate E.G. a 24c64 (for the normal data) and a 24cs64 (for

[PATCH] i2c: designware: Disable runtime PM in case i2c_dw_probe() fails

Call to pm_runtime_disable() got dropped while handling the merge conflict between commit 36d48fb5766a ("i2c: designware-platdrv: enable RuntimePM before registering to the core") and commit d80d134182ba ("i2c: designware: Move common probe code into i2c_dw_probe()"). Signed-off-by: Jarkko Nikula

Re: [PATCH v3 0/6] enable I2C devices behind I2C bus on Gen2

On Wed, 2015-10-07 at 13:18 +0300, Andy Shevchenko wrote: > There is a board in the wild, i.e. Intel Galileo Gen2, that has ACPI > enumerated > devices behind I2C bus. Lee, since Wolfram is going to apply patches 1 and 5, how could we proceed with the rest? Patches are indeed build independent,

Re: linux-next: Tree for Oct 21 (drivers/i2c/busses/i2c-designware-platdrv.c)

Hi On 10/21/2015 11:28 PM, Randy Dunlap wrote: On 10/20/15 23:16, Stephen Rothwell wrote: Hi all, There will be no linux-next releases after tomorrow until Nov 2 (kernel summit). Changes since 20151020: on i386 or x86_64: when CONFIG_PM_SLEEP is not enabled:

Re: [GIT PULL] On-demand device probing

On 10/19/2015 5:34 AM, Tomeu Vizoso wrote: > On 18 October 2015 at 21:53, Mark Brown wrote: >> On Sun, Oct 18, 2015 at 12:37:57PM -0700, Greg Kroah-Hartman wrote: >>> On Sun, Oct 18, 2015 at 08:29:31PM +0100, Mark Brown wrote: On Fri, Oct 16, 2015 at 11:57:50PM -0700,

Re: [GIT PULL] On-demand device probing

On Wed, Oct 21, 2015 at 08:59:51AM -0700, Frank Rowand wrote: > On 10/19/2015 5:34 AM, Tomeu Vizoso wrote: > > To be clear, I was saying that this series should NOT affect total > > boot times much. > I'm confused. If I understood correctly, improving boot time was > the key justification for

Re: [PATCH v2] dts: keystone: Use new "ti,keystone-i2c" compatible

On 10/21/15 3:38 AM, Grygorii Strashko wrote: On 09/14/2015 12:07 PM, Alexander Sverdlin wrote: Now as "i2c-davinci" driver has special handling for Keystone it's time to switch the device tree to use new "compatible" property. Old one is left for backwards- compatibility. Signed-off-by:

Re: Alternative approach to solve the deferred probe

On 10/21/2015 1:18 AM, Russell King - ARM Linux wrote: > On Tue, Oct 20, 2015 at 08:58:19PM -0700, Frank Rowand wrote: >> On 10/20/2015 8:46 AM, Russell King - ARM Linux wrote: < snip > >>> + >>> static bool driver_deferred_probe_enable = false; >>> + >>> /** >>> *

Re: Alternative approach to solve the deferred probe

On 10/21/2015 06:36 PM, Frank Rowand wrote: > On 10/21/2015 1:18 AM, Russell King - ARM Linux wrote: >> On Tue, Oct 20, 2015 at 08:58:19PM -0700, Frank Rowand wrote: >>> On 10/20/2015 8:46 AM, Russell King - ARM Linux wrote: > > < snip > > + static bool driver_deferred_probe_enable =

Re: [RESEND PATCH 0/9] eeprom: at24: at24cs series serial number read

2015-10-21 13:03 GMT+02:00 Peter Korsgaard : >> "Bartosz" == Bartosz Golaszewski writes: > > > Chips from the at24cs EEPROM series have an additional read-only memory > area > > containing a factory pre-programmed serial number. In order to

Re: Alternative approach to solve the deferred probe

On Wed, Oct 21, 2015 at 07:55:29PM +0300, Grygorii Strashko wrote: > On 10/21/2015 06:36 PM, Frank Rowand wrote: > > The above is currently the last point for probe to succeed or defer > > (until possibly, as you mentioned, module loading resolves the defer). > > If a probe defers above, it will

Re: Alternative approach to solve the deferred probe

On 10/21/2015 9:55 AM, Grygorii Strashko wrote: > On 10/21/2015 06:36 PM, Frank Rowand wrote: >> On 10/21/2015 1:18 AM, Russell King - ARM Linux wrote: >>> On Tue, Oct 20, 2015 at 08:58:19PM -0700, Frank Rowand wrote: On 10/20/2015 8:46 AM, Russell King - ARM Linux wrote: >> >> < snip > >>

Re: [GIT PULL] On-demand device probing

On 10/21/2015 9:27 AM, Mark Brown wrote: > On Wed, Oct 21, 2015 at 08:59:51AM -0700, Frank Rowand wrote: >> On 10/19/2015 5:34 AM, Tomeu Vizoso wrote: > >>> To be clear, I was saying that this series should NOT affect total >>> boot times much. > >> I'm confused. If I understood correctly,

Re: Alternative approach to solve the deferred probe

On Wed, Oct 21, 2015 at 09:13:48PM +0300, Grygorii Strashko wrote: > But I worry a bit (and that my main point) about these few additional > rounds of deferred device probing which I have right now and which allows > some of drivers to finish, finally, their probes successfully. > With proposed

Re: Alternative approach to solve the deferred probe

On 10/21/2015 09:02 PM, Frank Rowand wrote: > On 10/21/2015 9:55 AM, Grygorii Strashko wrote: >> On 10/21/2015 06:36 PM, Frank Rowand wrote: >>> On 10/21/2015 1:18 AM, Russell King - ARM Linux wrote: On Tue, Oct 20, 2015 at 08:58:19PM -0700, Frank Rowand wrote: > On 10/20/2015 8:46 AM,

Re: linux-next: Tree for Oct 21 (drivers/i2c/busses/i2c-designware-platdrv.c)

On 10/20/15 23:16, Stephen Rothwell wrote: > Hi all, > > There will be no linux-next releases after tomorrow until Nov 2 (kernel > summit). > > Changes since 20151020: > on i386 or x86_64: when CONFIG_PM_SLEEP is not enabled: ../drivers/i2c/busses/i2c-designware-platdrv.c:340:13: error:

[MinnowBoard] Linux x86 I2C device probing with ACPI

From: Christophe Ricard Hi, I am trying to probe slave i2c devices with ACPI running Ubuntu 15.04 and kernel 4.3 without success so far. I've followed guidance here: http://elinux.org/Minnowboard:MinnowMaxLinuxKernel

Re: [GIT PULL] On-demand device probing

On Wed, Oct 21, 2015 at 11:18:08AM -0700, Frank Rowand wrote: > On 10/21/2015 9:27 AM, Mark Brown wrote: > > Overall boot time and time to get some individual built in component up > > and running aren't the same thing - what this'll do is get things up > > more in the link order of the leaf

Re: Alternative approach to solve the deferred probe

On Wed, Oct 21, 2015 at 08:36:23AM -0700, Frank Rowand wrote: > On 10/21/2015 1:18 AM, Russell King - ARM Linux wrote: > > On Tue, Oct 20, 2015 at 08:58:19PM -0700, Frank Rowand wrote: > >> On 10/20/2015 8:46 AM, Russell King - ARM Linux wrote: > > < snip > > > >>> + > >>> static bool

Re: [GIT PULL] On-demand device probing

On Wed, Oct 21, 2015 at 1:18 PM, Frank Rowand wrote: > On 10/21/2015 9:27 AM, Mark Brown wrote: >> On Wed, Oct 21, 2015 at 08:59:51AM -0700, Frank Rowand wrote: >>> On 10/19/2015 5:34 AM, Tomeu Vizoso wrote: >> To be clear, I was saying that this series should NOT

Re: [GIT PULL] On-demand device probing

On 10/21/2015 2:12 PM, Rob Herring wrote: > On Wed, Oct 21, 2015 at 1:18 PM, Frank Rowand wrote: >> On 10/21/2015 9:27 AM, Mark Brown wrote: >>> On Wed, Oct 21, 2015 at 08:59:51AM -0700, Frank Rowand wrote: On 10/19/2015 5:34 AM, Tomeu Vizoso wrote: >>> > To be

Re: [PATCH v3 1/1] i2c: add ACPI support for I2C mux ports

Hi, On Wed, Oct 21, 2015 at 11:25 AM, Dustin Byford wrote: > On Wed Oct 21 12:08, Mika Westerberg wrote: >> I don't really have strong feelings whether it should be the I2C core or >> individual drivers setting the ACPI companion. However, it would be nice >> to match

Re: [PATCH 5/9] i2c: rcar: init new messages in irq

Hi Wolfram, On Thursday 03 September 2015 22:20:09 Wolfram Sang wrote: > From: Wolfram Sang > > Setting up new messages was done in process context while handling a > message was in interrupt context. Because of the HW design, this IP core > is sensitive to

Re: [GIT PULL] On-demand device probing

On Wednesday, October 21, 2015 10:55:14 AM Geert Uytterhoeven wrote: > Hi Rafael, > > On Wed, Oct 21, 2015 at 1:34 AM, Rafael J. Wysocki wrote: > > On Tuesday, October 20, 2015 09:15:01 AM Rob Herring wrote: > >> On Tue, Oct 20, 2015 at 2:56 AM, Rafael J. Wysocki

Re: [PATCH 2/2] i2c: designware: enable High-speed mode for pcidrv

2015-10-15 17:40 GMT+08:00 Andy Shevchenko : > On Thu, 2015-10-15 at 11:32 +0300, Jarkko Nikula wrote: >> On 10/15/2015 08:46 AM, Xiang Wang wrote: >> > >> > In conclusion, we have 2 solutions to set the i2c controller speed >> > mode (pci driver): >> > 1) use

Re: [PATCH 2/9] i2c: brcmstb: fix typo in i2c-brcmstb

Le 20/10/2015 19:36, Jaedon Shin a écrit : > Fixes the "definitions" where it is spelled "defintions". > > Signed-off-by: Jaedon Shin Acked-by: Florian Fainelli > --- > drivers/i2c/busses/i2c-brcmstb.c | 2 +- > 1 file changed, 1 insertion(+), 1

Re: [PATCH 1/9] i2c: brcmstb: make the driver buildable on BMIPS_GENERIC

Le 20/10/2015 19:36, Jaedon Shin a écrit : > The BCM7xxx ARM and MIPS platforms share a similar hardware block for > I2C. > > Signed-off-by: Jaedon Shin Acked-by: Florian Fainelli > --- > drivers/i2c/busses/Kconfig | 2 +- > 1 file changed, 1

Re: [PATCH 3/9] i2c: brcmstb: add missing parenthesis

Le 20/10/2015 19:36, Jaedon Shin a écrit : > Add the necessary parenthesis for NOACK condition. > > Signed-off-by: Jaedon Shin Acked-by: Florian Fainelli > --- > drivers/i2c/busses/i2c-brcmstb.c | 2 +- > 1 file changed, 1 insertion(+), 1

Re: [PATCH 8/9] MIPS: BMIPS: brcmstb: add I2C node for bcm7360

Le 20/10/2015 19:37, Jaedon Shin a écrit : > Add I2C device nodes to BMIPS based BCM7360 platform. > > Signed-off-by: Jaedon Shin Acked-by: Florian Fainelli > --- > arch/mips/boot/dts/brcm/bcm7360.dtsi | 62 > ++--

Re: [PATCH 6/9] MIPS: BMIPS: brcmstb: add I2C node for bcm7346

Le 20/10/2015 19:36, Jaedon Shin a écrit : > Add I2C device nodes to BMIPS based BCM7346 platform. > > Signed-off-by: Jaedon Shin Acked-by: Florian Fainelli -- Florian -- To unsubscribe from this list: send the line "unsubscribe linux-i2c" in the

Re: [PATCH 9/9] MIPS: BMIPS: brcmstb: add I2C node for bcm7362

Le 20/10/2015 19:37, Jaedon Shin a écrit : > Add I2C device nodes to BMIPS based BCM7362 platform. > > Signed-off-by: Jaedon Shin Acked-by: Florian Fainelli > --- > arch/mips/boot/dts/brcm/bcm7362.dtsi | 52 > ++--

Re: [PATCH 7/9] MIPS: BMIPS: brcmstb: add I2C node for bcm7358

Le 20/10/2015 19:36, Jaedon Shin a écrit : > Add I2C device nodes to BMIPS based BCM7358 platform. > > Signed-off-by: Jaedon Shin Acked-by: Florian Fainelli > --- > arch/mips/boot/dts/brcm/bcm7358.dtsi | 62 > ++--

Re: Alternative approach to solve the deferred probe

Hi Russell, On 10/21/2015 08:20 PM, Russell King - ARM Linux wrote: > On Wed, Oct 21, 2015 at 07:55:29PM +0300, Grygorii Strashko wrote: >> On 10/21/2015 06:36 PM, Frank Rowand wrote: >>> The above is currently the last point for probe to succeed or defer >>> (until possibly, as you mentioned,

Re: Alternative approach to solve the deferred probe

On 10/21/2015 1:35 PM, Russell King - ARM Linux wrote: > On Wed, Oct 21, 2015 at 08:36:23AM -0700, Frank Rowand wrote: >> On 10/21/2015 1:18 AM, Russell King - ARM Linux wrote: >>> On Tue, Oct 20, 2015 at 08:58:19PM -0700, Frank Rowand wrote: On 10/20/2015 8:46 AM, Russell King - ARM Linux

Re: [GIT PULL] On-demand device probing

On Tuesday, October 20, 2015 06:21:55 PM Tomeu Vizoso wrote: > On 20 October 2015 at 18:04, Alan Stern wrote: > > On Tue, 20 Oct 2015, Mark Brown wrote: > > > >> On Tue, Oct 20, 2015 at 10:40:03AM -0400, Alan Stern wrote: > >> > >> > Furthermore, that applies only to

[PATCH] i2c: designware: Fix build error when !CONFIG_PM_SLEEP

Commit 6ad6fde3970c ("i2c: designware: Rename platform driver probe and PM functions") introduced "'dw_i2c_plat_prepare' undeclared here" and "'dw_i2c_plat_complete' undeclared here" build errors when CONFIG_PM_SLEEP is not set. Fix this by renaming NULL defined dw_i2c_prepare and dw_i2c_complete

Re: [PATCH] i2c: at91: fix write transfers by clearing pending interrupt first

On 2015-10-20 15:27, Ludovic Desroches wrote: > On Mon, Oct 19, 2015 at 12:49:03PM +0200, Peter Rosin wrote: >> On 2015-10-19 10:51, Ludovic Desroches wrote: >>> Hi Peter, >>> >>> On Fri, Oct 16, 2015 at 11:08:42AM +0200, Peter Rosin wrote: On 2015-10-16 01:47, Peter Rosin wrote: > On

Re: [PATCH 1/2] i2c: designware: register clkdev during acpi device configuration

On Wed, Oct 21, 2015 at 05:50:02PM +0800, Ken Xue wrote: > After apd was accept in kernel V4.1, there is no issue. But between 3.18 > and V4.1, there will be a problem. We care about that because? -- To unsubscribe from this list: send the line "unsubscribe linux-i2c" in the body of a message to

Re: [PATCH v3 1/1] i2c: add ACPI support for I2C mux ports

On Wed, Oct 21, 2015 at 01:52:41AM -0700, Dustin Byford wrote: > On Wed Oct 21 11:34, Mika Westerberg wrote: > > On Wed, Oct 21, 2015 at 01:21:16AM -0700, Dustin Byford wrote: > > > On Wed Oct 21 11:12, Mika Westerberg wrote: > > > > On Tue, Oct 20, 2015 at 10:49:59AM -0700, Dustin Byford wrote: >

[PATCH] i2c: designware: fix platform driver probe rename

A function rename was incomplete and missed the !CONFIG_PM case: i2c-designware-platdrv.c:340:13: error: 'dw_i2c_plat_prepare' undeclared here (not in a function) i2c-designware-platdrv.c:341:14: error: 'dw_i2c_plat_complete' undeclared here (not in a function) This renames the macros

Re: [PATCH 1/2] i2c: designware: register clkdev during acpi device configuration

On Wed, Oct 21, 2015 at 04:42:23PM +0800, Ken Xue wrote: > On Wed, 2015-10-21 at 10:28 +0300, Mika Westerberg wrote: > > On Wed, Oct 21, 2015 at 09:11:33AM +0800, Ken Xue wrote: > > > On Tue, 2015-10-20 at 14:17 +0300, Mika Westerberg wrote: > > > > On Tue, Oct 20, 2015 at 02:38:01PM +0800, Ken

Re: [PATCH 1/2] i2c: designware: register clkdev during acpi device configuration

On Wed, 2015-10-21 at 12:25 +0300, Mika Westerberg wrote: > On Wed, Oct 21, 2015 at 04:42:23PM +0800, Ken Xue wrote: > > On Wed, 2015-10-21 at 10:28 +0300, Mika Westerberg wrote: > > > On Wed, Oct 21, 2015 at 09:11:33AM +0800, Ken Xue wrote: > > > > On Tue, 2015-10-20 at 14:17 +0300, Mika

Re: [PATCH 1/2] i2c: designware: register clkdev during acpi device configuration

On Wed, Oct 21, 2015 at 05:37:53PM +0800, Ken Xue wrote: > On Wed, 2015-10-21 at 12:25 +0300, Mika Westerberg wrote: > > On Wed, Oct 21, 2015 at 04:42:23PM +0800, Ken Xue wrote: > > > On Wed, 2015-10-21 at 10:28 +0300, Mika Westerberg wrote: > > > > On Wed, Oct 21, 2015 at 09:11:33AM +0800, Ken

Re: [PATCH 1/2] i2c: designware: register clkdev during acpi device configuration

On Wed, 2015-10-21 at 12:49 +0300, Mika Westerberg wrote: > On Wed, Oct 21, 2015 at 05:37:53PM +0800, Ken Xue wrote: > > On Wed, 2015-10-21 at 12:25 +0300, Mika Westerberg wrote: > > > On Wed, Oct 21, 2015 at 04:42:23PM +0800, Ken Xue wrote: > > > > On Wed, 2015-10-21 at 10:28 +0300, Mika

Re: [PATCH v2] dts: keystone: Use new "ti,keystone-i2c" compatible

On Tuesday 20 October 2015 09:40 PM, Grygorii Strashko wrote: > On 10/20/2015 06:06 PM, Wolfram Sang wrote: >> On Mon, Sep 14, 2015 at 11:07:02AM +0200, Alexander Sverdlin wrote: >>> Now as "i2c-davinci" driver has special handling for Keystone it's >>> time to switch >>> the device tree to use

Re: [PATCH 1/2] i2c: designware: register clkdev during acpi device configuration

On Wed, 2015-10-21 at 10:28 +0300, Mika Westerberg wrote: > On Wed, Oct 21, 2015 at 09:11:33AM +0800, Ken Xue wrote: > > On Tue, 2015-10-20 at 14:17 +0300, Mika Westerberg wrote: > > > On Tue, Oct 20, 2015 at 02:38:01PM +0800, Ken Xue wrote: > > > > DW I2C driver tries to register a clk from

Re: [PATCH 1/2] i2c: designware: register clkdev during acpi device configuration

On Wed, Oct 21, 2015 at 05:50:02PM +0800, Ken Xue wrote: > On Wed, 2015-10-21 at 12:49 +0300, Mika Westerberg wrote: > > On Wed, Oct 21, 2015 at 05:37:53PM +0800, Ken Xue wrote: > > > On Wed, 2015-10-21 at 12:25 +0300, Mika Westerberg wrote: > > > > On Wed, Oct 21, 2015 at 04:42:23PM +0800, Ken

Re: [PATCH v3 1/1] i2c: add ACPI support for I2C mux ports

On Wed Oct 21 12:08, Mika Westerberg wrote: > I don't really have strong feelings whether it should be the I2C core or > individual drivers setting the ACPI companion. However, it would be nice > to match DT here and they assign their of_node per driver. OK with me, if we can convince Rafael this

Re: [PATCH] i2c: designware: fix platform driver probe rename

On Wed, 2015-10-21 at 11:16 +0200, Arnd Bergmann wrote: > A function rename was incomplete and missed the !CONFIG_PM > case: > > i2c-designware-platdrv.c:340:13: error: 'dw_i2c_plat_prepare' > undeclared here (not in a function) > i2c-designware-platdrv.c:341:14: error: 'dw_i2c_plat_complete' >

Re: [PATCH v2] dts: keystone: Use new "ti,keystone-i2c" compatible

On 09/14/2015 12:07 PM, Alexander Sverdlin wrote: Now as "i2c-davinci" driver has special handling for Keystone it's time to switch the device tree to use new "compatible" property. Old one is left for backwards- compatibility. Signed-off-by: Alexander Sverdlin

Re: [RESEND PATCH 0/9] eeprom: at24: at24cs series serial number read

> "Bartosz" == Bartosz Golaszewski writes: > Chips from the at24cs EEPROM series have an additional read-only memory area > containing a factory pre-programmed serial number. In order to access it, a > dummy write must be executed before reading the serial

Re: [PATCH] i2c: at91: fix write transfers by clearing pending interrupt first

On Wed, Oct 21, 2015 at 09:42:40AM +0200, Peter Rosin wrote: > On 2015-10-21 09:21, Peter Rosin wrote: > > On 2015-10-20 15:27, Ludovic Desroches wrote: > >> On Mon, Oct 19, 2015 at 12:49:03PM +0200, Peter Rosin wrote: > >>> On 2015-10-19 10:51, Ludovic Desroches wrote: > Hi Peter, > >

Re: [PATCH v2] dts: keystone: Use new "ti,keystone-i2c" compatible

Hi! On 21/10/15 12:13, EXT Sekhar Nori wrote: Now as "i2c-davinci" driver has special handling for Keystone it's >>> time to switch >>> the device tree to use new "compatible" property. Old one is left for >>> backwards- >>> compatibility. >>> >>> Signed-off-by:

Re: [GIT PULL] On-demand device probing

Sorry to enter this thread a bit late. About the number of probe deferred messages, I proposed a simple patch to reduce them: https://lkml.org/lkml/2013/8/20/218 I was wondering how many messages this patch could save... -- Ken ar c'hentañ | ** Breizh ha Linux atav! ** Jef

Re: [PATCH] i2c: mv64xxx: really allow I2C offloading

> Wolfram, do you want me to send a v2 with Hezi's full name or will you > fix that up when applying the patch ? I'll fix. signature.asc Description: Digital signature

Re: [PATCH v3 1/1] i2c: add ACPI support for I2C mux ports

On Wed, Oct 21, 2015 at 01:12:01AM +0200, Rafael J. Wysocki wrote: > Well, we already have that in the MFD case, but in principle it may be > problematic for things like power management (say you want to put a > child device into D3, so you use _PS3 on its ACPI companion and then > the parent is

Re: [PATCH v3 1/1] i2c: add ACPI support for I2C mux ports

On Tue, Oct 20, 2015 at 10:49:59AM -0700, Dustin Byford wrote: > I considered it, but I thought a default that fairly closely matches the > old behavior was more convenient. > > On the other hand, leaving it up to the controllers makes it all very > explicit and perhaps simpler to reason about. >

Re: Alternative approach to solve the deferred probe

On Tue, Oct 20, 2015 at 08:58:19PM -0700, Frank Rowand wrote: > On 10/20/2015 8:46 AM, Russell King - ARM Linux wrote: > > On Mon, Oct 19, 2015 at 06:21:40PM +0200, Geert Uytterhoeven wrote: > >> Hi Russell, > >> > >> On Mon, Oct 19, 2015 at 5:35 PM, Russell King - ARM Linux > >>

Re: [PATCH v3 1/1] i2c: add ACPI support for I2C mux ports

On Wed, Oct 21, 2015 at 01:21:16AM -0700, Dustin Byford wrote: > On Wed Oct 21 11:12, Mika Westerberg wrote: > > On Tue, Oct 20, 2015 at 10:49:59AM -0700, Dustin Byford wrote: > > > I considered it, but I thought a default that fairly closely matches the > > > old behavior was more convenient. > >

Re: [PATCH 1/2] i2c: designware: register clkdev during acpi device configuration

On Wed, Oct 21, 2015 at 09:11:33AM +0800, Ken Xue wrote: > On Tue, 2015-10-20 at 14:17 +0300, Mika Westerberg wrote: > > On Tue, Oct 20, 2015 at 02:38:01PM +0800, Ken Xue wrote: > > > DW I2C driver tries to register a clk from id->driver_data as an > > > alternative way besides intel lpss. But

Re: [PATCH] i2c: at91: fix write transfers by clearing pending interrupt first

On 2015-10-21 09:21, Peter Rosin wrote: > On 2015-10-20 15:27, Ludovic Desroches wrote: >> On Mon, Oct 19, 2015 at 12:49:03PM +0200, Peter Rosin wrote: >>> On 2015-10-19 10:51, Ludovic Desroches wrote: Hi Peter, On Fri, Oct 16, 2015 at 11:08:42AM +0200, Peter Rosin wrote: > On

Re: [PATCH v3 1/1] i2c: add ACPI support for I2C mux ports

On Wed Oct 21 11:12, Mika Westerberg wrote: > On Tue, Oct 20, 2015 at 10:49:59AM -0700, Dustin Byford wrote: > > I considered it, but I thought a default that fairly closely matches the > > old behavior was more convenient. > > > > On the other hand, leaving it up to the controllers makes it all

Re: [PATCH v3 1/1] i2c: add ACPI support for I2C mux ports

On Wed Oct 21 11:34, Mika Westerberg wrote: > On Wed, Oct 21, 2015 at 01:21:16AM -0700, Dustin Byford wrote: > > On Wed Oct 21 11:12, Mika Westerberg wrote: > > > On Tue, Oct 20, 2015 at 10:49:59AM -0700, Dustin Byford wrote: > > > > I considered it, but I thought a default that fairly closely

Re: [GIT PULL] On-demand device probing

Hi Rafael, On Wed, Oct 21, 2015 at 1:34 AM, Rafael J. Wysocki wrote: > On Tuesday, October 20, 2015 09:15:01 AM Rob Herring wrote: >> On Tue, Oct 20, 2015 at 2:56 AM, Rafael J. Wysocki >> wrote: >> > ACPI uses platform devices too. In fact, ACPI device