Re: [PATCH] i2c: rk3x: init module as subsys call

Hi Tao, Am Dienstag, 5. Januar 2016, 15:42:32 schrieb Huang, Tao: > On 2016年01月05日 15:02, Heiko Stuebner wrote: > > Hi Jianqun, > > > > Am Dienstag, 5. Januar 2016, 11:02:18 schrieb jianqun.xu: > >> From: Xu Jianqun > >> > >> There is a requirement from pmic device,

Re: [PATCH] i2c: rk3x: init module as subsys call

> > Tomeu from Collabora is working on some better scheme to optimize device > > probing order but it looks like this may be a bit off still. ... > I don't just talk about touch screen driver, most i2c device driver such > as input sensor/camera/rtc/battery will suffer. So people will see

Re: [PATCH] i2c/designware: enable i2c controller to suspend/resume asynchronously

Hi On 12/24/2015 04:30 PM, Fu, Zhonghui wrote: Now, PM core supports asynchronous suspend/resume mode for devices during system suspend/resume, and the power state transition of one device may be completed in separate kernel thread. PM core ensures all power state transition dependency between

Re: [PATCH 01/10] i2c-mux: add common core data for every mux instance

Hi Guenter, On 2016-01-04 16:37, Guenter Roeck wrote: > On 01/04/2016 07:10 AM, Peter Rosin wrote: >> From: Peter Rosin >> >> The initial core mux structure starts off small with only the parent >> adapter pointer, which all muxes have, and a priv pointer for mux >> driver

Re: [PATCH] i2c: rk3x: init module as subsys call

Hi, Heiko: On 2016年01月05日 16:00, Heiko Stuebner wrote: > Hi Tao, > > Am Dienstag, 5. Januar 2016, 15:42:32 schrieb Huang, Tao: >> I don't think this is a good idea. This will trigger a lots of init call >> failed. Before pmic init, all i2c device driver transmit will failed, >> and because i2c

[PATCH v2 1/8] i2c-mux: add common core data for every mux instance

From: Peter Rosin The initial core mux structure starts off small with only the parent adapter pointer, which all muxes have, and a priv pointer for mux driver private data. Add i2c_mux_alloc function to unify the creation of a mux. Where appropriate, pass around the mux core

[PATCH v2 2/8] i2c-mux: move select and deselect ops to i2c_mux_core

From: Peter Rosin The mux select and deselect ops are common to the mux most of the time, so store the ops in the mux core. Change the select and deselect op to work in terms of the mux core instead of the child adapter. No driver uses the child adapter anyway, and if it is

[PATCH v2 4/8] i2c-mux: remove the mux dev pointer from the mux per channel data

From: Peter Rosin The dev pointer is readily available in the mux core struct, no point in keeping multiple copies around. The patch also fixes a bug in rtl2832, which attached its mux slave adapter to the device owning the mux parent adapter instead of attaching it to its own

[PATCH v2 3/8] i2c-mux: move the slave side adapter management to i2c_mux_core

From: Peter Rosin All muxes have slave side adapters, many have some arbitrary number of them. Handle this in the mux core, so that drivers are simplified. Add i2c_mux_reserve_adapter that can be used when it is known in advance how many child adapters that is to be added. This

Re: [PATCH v2 3/8] i2c-mux: move the slave side adapter management to i2c_mux_core

Hi Peter, [auto build test ERROR on wsa/i2c/for-next] [also build test ERROR on v4.4-rc8 next-20160105] [if your patch is applied to the wrong git tree, please drop us a note to help improving the system] url: https://github.com/0day-ci/linux/commits/Peter-Rosin/i2c-mux-cleanup-and-locking

[PATCH v2 6/8] i2c: allow adapter drivers to override the adapter locking

From: Peter Rosin Add i2c_lock_bus() and i2c_unlock_bus(), which call the new lock_bus and unlock_bus ops in the adapter. These funcs/ops take an additional flags argument that indicates for what purpose the adapter is locked. There are two flags, I2C_LOCK_ADAPTER and

[PATCH v2 7/8] i2c: muxes always lock the parent adapter

From: Peter Rosin Instead of checking for i2c parent adapters for every lock/unlock, simply override the locking for muxes to always lock/unlock the parent adapter directly. Signed-off-by: Peter Rosin --- drivers/i2c/i2c-core.c | 21 +++--

Re: [PATCH v2 1/8] i2c-mux: add common core data for every mux instance

On 01/05/2016 07:57 AM, Peter Rosin wrote: From: Peter Rosin The initial core mux structure starts off small with only the parent adapter pointer, which all muxes have, and a priv pointer for mux driver private data. Add i2c_mux_alloc function to unify the creation of a mux.

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

From: Peter Rosin With a i2c topology like the following GPIO ---| -- BAT1 | v / I2C -+--+ MUX | \ EEPROM -- BAT2 there is a locking

[PATCH v2 5/8] i2c-mux: pinctrl: get rid of the driver private struct device pointer

From: Peter Rosin There is a copy of the device pointer in the mux core. Signed-off-by: Peter Rosin --- drivers/i2c/muxes/i2c-mux-pinctrl.c | 23 --- 1 file changed, 8 insertions(+), 15 deletions(-) diff --git

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

From: Peter Rosin Hi! I have a pair of boards with this i2c topology: GPIO ---| -- BAT1 | v / I2C -+--B---+ MUX | \ EEPROM -- BAT2 (B

Re: [PATCH v2 1/8] i2c-mux: add common core data for every mux instance

Hi Guenter, [BTW, if anyone feels spammed by this series, please drop me a note] On 2016-01-05 17:42, Guenter Roeck wrote: > On 01/05/2016 07:57 AM, Peter Rosin wrote: >> From: Peter Rosin >> >> The initial core mux structure starts off small with only the parent >> adapter

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

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 platforms for Intel Skylake. First part is a refactoring of built-in device properties support: - keep single

Re: [PATCH v2 3/8] i2c-mux: move the slave side adapter management to i2c_mux_core

-05 17:49, kbuild test robot wrote: > Hi Peter, > > [auto build test ERROR on wsa/i2c/for-next] > [also build test ERROR on v4.4-rc8 next-20160105] > [if your patch is applied to the wrong git tree, please drop us a note to > help improving the system] > > url: > https

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

Peter, > PS. needs a bunch of testing, I do not have access to all the involved hw First of all, thanks for diving into this topic and the huge effort you apparently have put into it. It is obviously a quite intrusive series, so it needs careful review. TBH, I can't really tell when I have the

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

On Mon, Jan 04, 2016 at 03:01:54PM +0100, Bartosz Golaszewski wrote: > 2016-01-02 21:50 GMT+01:00 Wolfram Sang : > > On Fri, Dec 11, 2015 at 02:55:10PM +0100, Bartosz Golaszewski wrote: > >> 2015-12-11 13:08 GMT+01:00 Wolfram Sang : > >> > On Wed, Dec 02,

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

Hi Wolfram, On 2016-01-05 19:48, Wolfram Sang wrote: > Peter, > >> PS. needs a bunch of testing, I do not have access to all the involved hw > > First of all, thanks for diving into this topic and the huge effort you > apparently have put into it. Yeah, I started with dipping just the toes,

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

Hi, >> 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 used

Re: [PATCH] i2c: designware: retry transfer on transient failure

Hi Andy, On Tue, Jan 05, 2016 at 02:22:28PM +0200, Andy Shevchenko wrote: > On Mon, 2016-01-04 at 20:49 +0100, Wolfram Sang wrote: > > I'm okay with the original patch putting some "sane" initial value. > > It can be modified at runtime via a i2c-dev ioctl if needed. > > Ah, good. So, I'm fine

Re: ismt-bus completion wait timed out issue

Puneet Shenoy writes: > > Hey Bill, > > I see that you are the author of the i2c-ismt driver so thought will check with you on a issue that I have been > seeing on my setup. > > My setup has an Intel Atom S1220 Processor which has a PMBUS device on its SMBUS 2.0 controller

Re: [PATCH v2 3/8] i2c-mux: move the slave side adapter management to i2c_mux_core

Ouch, this got lost in the shuffle, don't bother testing without it. It will be included in v3. [the reason is that my test hw relies on vendor patches, and I have to rebase before sending. I.e., I can only compile-test the stuff I'm actually sending out. Inconvenient.] diff --git

Re: [PATCH 2/2] i2c: designware: Allow build Baytrail semaphore support when IOSF_MBI=m

Hi Sorry I missed this discussion. I believe the following code in i2c_dw_eval_lock_support() should make it so that it doesn't matter how IOSF_MBI is built: if (!iosf_mbi_available()) return -EPROBE_DEFER; I added this to address i2c_designware probing before iosf_mbi. It worked

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

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 > >> platforms for Intel Skylake. > >> >

Re: [PATCH] i2c: designware: retry transfer on transient failure

On Mon, 2016-01-04 at 20:49 +0100, Wolfram Sang wrote: > > After that, introduce a new property 'linux,i2c-retry-count' to be > > used > > as retries field in struct i2c_adapter. > > Hmm, to be honest, I always have difficulties with this "retries" > parameter; to me "try x milliseconds" makes

Re: [PATCH] i2c/designware: enable i2c controller to suspend/resume asynchronously

On Tue, 2016-01-05 at 10:53 +0200, Jarkko Nikula wrote: > Hi > > On 12/24/2015 04:30 PM, Fu, Zhonghui wrote: > > Now, PM core supports asynchronous suspend/resume mode for devices > > during system suspend/resume, and the power state transition of one > > device may be completed in separate