Re: [PATCH] DT: i2c: Update vendor prefix for 24c00

On Mon, Jan 04, 2016 at 08:22:33PM +0200, Andy Shevchenko wrote: > On Sat, Jan 2, 2016 at 11:21 PM, Wolfram Sang wrote: > > On Sun, Dec 27, 2015 at 04:57:48PM +0200, Andy Shevchenko wrote: > >> On Wed, Dec 23, 2015 at 9:18 PM, Akshay Bhat > >> wrote:

[RFC v2 4/4] ARM: shmobile: r8a7790: rework dts to use i2c demuxer

From: Wolfram Sang Create a seperate bus for HDMI related I2C slaves and assign it to a i2c-gpio master. It can be switched to the i2c-rcar or i2c-sh_mobile core at runtime. Signed-off-by: Wolfram Sang ---

Re: [RFC v2 2/4] dt-bindings: i2c: mux: demux-pinctrl: add bindings

Hi Wolfram, On Wed, Jan 6, 2016 at 2:51 PM, Wolfram Sang wrote: > These bindings allow an I2C bus to switch between multiple masters. This > is not hot-swichting because connected I2C slaves will be > re-instantiated. It is meant to select the best I2C core at runtime once >

[RFC v2 1/4] of: make of_mutex public

From: Wolfram Sang If we want to use OF_DYNAMIC features outside the of framework, we need to access this lock. Signed-off-by: Wolfram Sang --- drivers/of/of_private.h | 1 - include/linux/of.h | 2 ++ 2 files changed, 2

[RFC v2 0/4] i2c/of: switch I2C IP cores at runtime via OF_DYNAMIC

I know this is gonna be a controversial series, but we have a usecase for this :) This series allows an I2C bus to switch between multiple masters, i.e. a n-to-1-demuxer. This is not hot-switching because connected I2C slaves will be re-instantiated. It is meant to select the best I2C core at

[RFC v2 3/4] i2c: mux: demux-pinctrl: add driver

From: Wolfram Sang This driver allows an I2C bus to switch between multiple masters. This is not hot-swichting because connected I2C slaves will be re-instantiated. It is meant to select the best I2C core at runtime once the task is known. Example: Prefer

Re: [RFC v2 3/4] i2c: mux: demux-pinctrl: add driver

Hi Wolfram, On Wed, Jan 6, 2016 at 2:51 PM, Wolfram Sang wrote: > From: Wolfram Sang > > This driver allows an I2C bus to switch between multiple masters. This > is not hot-swichting because connected I2C slaves will be switching >

Re: [PATCH v2 0/8] i2c mux cleanup and locking update

Hi Wolfram and Peter, I will give my opinion about the path chosen although it should be taken lightly. I can see that hardware guys missed the software guys again on the development path, but since this happens more often than not, I would say it seems OK to have support for this as long as it

[RFC v2 2/4] dt-bindings: i2c: mux: demux-pinctrl: add bindings

From: Wolfram Sang These bindings allow an I2C bus to switch between multiple masters. This is not hot-swichting because connected I2C slaves will be re-instantiated. It is meant to select the best I2C core at runtime once the task is known. Example: Prefer

Re: [RFC v2 1/4] of: make of_mutex public

Hi Wolfram, On Wed, Jan 6, 2016 at 2:51 PM, Wolfram Sang wrote: > From: Wolfram Sang > > If we want to use OF_DYNAMIC features outside the of framework, we need > to access this lock. As I2C_DEMUX_PINCTRL is tristate, you want to add an

Re: [PATCH v2 00/16] intel-lpss: support non-ACPI platforms

On 01/05/2016 03:59 PM, Rafael J. Wysocki wrote: On Tuesday, January 05, 2016 09:57:35 AM Laura Abbott wrote: On 12/06/2015 05:44 PM, Rafael J. Wysocki wrote: On Monday, November 30, 2015 05:11:28 PM Andy Shevchenko wrote: This series includes few logical sets that bring a support of non-ACPI

Re: [PATCH v2 8/8] i2c-mux: relax locking of the top i2c adapter during i2c controlled muxing

On Tue, Jan 05, 2016 at 04:57:18PM +0100, Peter Rosin wrote: > From: Peter Rosin > > With a i2c topology like the following > >GPIO ---| -- BAT1 > | v / >I2C -+--+ MUX > |

Re: [PATCH v2 0/8] i2c mux cleanup and locking update

On 01/05/2016 05:57 PM, Peter Rosin wrote: From: Peter Rosin Hi! I have a pair of boards with this i2c topology: GPIO ---| -- BAT1 | v / I2C -+--B---+ MUX | \

Re: [RFC v2 3/4] i2c: mux: demux-pinctrl: add driver

On Wed, Jan 6, 2016 at 7:51 AM, Wolfram Sang wrote: > From: Wolfram Sang > > This driver allows an I2C bus to switch between multiple masters. This > is not hot-swichting because connected I2C slaves will be > re-instantiated. It is meant to

Re: [PATCH v4] i2c: designware: Do not require clock when SSCN and FFCN are provided

Hi All, >> The current driver uses input clock source frequency to calculate >> values for [SS|FS]_[HC|LC] registers. However, when booting ACPI, we do not >> currently have a good way to provide the frequency information. >> Instead, we can leverage the SSCN and FFCN ACPI methods, which can be

Re: [PATCH v4] i2c: designware: Do not require clock when SSCN and FFCN are provided

Hi, On 01/06/2016 06:31 PM, Loc Ho wrote: Hi All, The current driver uses input clock source frequency to calculate values for [SS|FS]_[HC|LC] registers. However, when booting ACPI, we do not currently have a good way to provide the frequency information. Instead, we can leverage the SSCN and