Re: [MinnowBoard] Linux x86 I2C device probing with ACPI

On Wed, Oct 21, 2015 at 09:19:24PM +0200, Christophe Ricard wrote: > 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: >

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

On Wed, Oct 21, 2015 at 05:21:46PM +0300, Jarkko Nikula wrote: > 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

Re: [PATCH 0/4] Support multiplexed main SMBus interface on SB800

On Tue, Oct 20, 2015 at 05:19:35PM +0200, Wolfram Sang wrote: > On Tue, Aug 25, 2015 at 01:05:01PM +0200, Christian Fetzer wrote: > > This is an attempt to upstream the patches created by Thomas Brandon and > > Eddi De Pieri to support the multiplexed main SMBus interface on the SB800 > > chipset.

ACPI I2C device-driver matching issue

Hi all, I have a custom Baytrail board with a M24C02 EEPROM attached to I2C bus 3. I am using coreboot/SeaBIOS, so I have complete control over the ACPI tables. I am using Linux 4.2.3. I have defined a EEPROM device on I2C3 using I2cSerialBus() and it shows up as expected. Scope

Re: [GIT PULL] On-demand device probing

On 10/22/2015 7:44 AM, Greg Kroah-Hartman wrote: > > > On Thu, Oct 22, 2015 at 11:05:11AM +0200, Tomeu Vizoso wrote: >> But that's moot currently because Greg believes that the time spent >> probing devices at boot time could be reduced enough so that the order >> in

Re: [GIT PULL] On-demand device probing

On Thu, Oct 22, 2015 at 11:53:31AM -0700, Frank Rowand wrote: > On 10/22/2015 7:44 AM, Greg Kroah-Hartman wrote: > > > > > > On Thu, Oct 22, 2015 at 11:05:11AM +0200, Tomeu Vizoso wrote: > >> But that's moot currently because Greg believes that the time spent > >>

Re: [GIT PULL] On-demand device probing

On 22 October 2015 at 02:54, Rafael J. Wysocki wrote: > 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

[PATCH v4 1/2] acpi: add acpi_preset_companion() stub

Add a stub for acpi_preset_companion(). Fixes build failures when acpi_preset_companion() is used and CONFIG_ACPI is not set. Signed-off-by: Dustin Byford --- include/linux/acpi.h | 6 ++ 1 file changed, 6 insertions(+) diff --git a/include/linux/acpi.h

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

Hi Wolfram, On Thursday 22 October 2015 13:05:05 Wolfram Sang wrote: > On Thu, Oct 22, 2015 at 02:10:52AM +0300, Laurent Pinchart wrote: > > On Thursday 03 September 2015 22:20:09 Wolfram Sang wrote: > > > From: Wolfram Sang > > > > > > Setting up new messages

Re: [PATCH 0/4] Support multiplexed main SMBus interface on SB800

On Thu, Oct 22, 2015 at 01:03:25PM +0200, Wolfram Sang wrote: > > > > > Please review and let me know required changes in order to get this > > > > upstream > > > > finally. > > > > > > > > Eddi, Thomas, it would be great if you could verify the changes on your > > > > machines. > > > > > >

Re: [PATCH 0/4] Support multiplexed main SMBus interface on SB800

> > > Please review and let me know required changes in order to get this > > > upstream > > > finally. > > > > > > Eddi, Thomas, it would be great if you could verify the changes on your > > > machines. > > > > Yes, additional tests are always good for a patch series > > > > Asking the Intel

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

On Thu, Oct 22, 2015 at 02:10:52AM +0300, Laurent Pinchart wrote: > 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

Re: [PATCH v2 1/1] i2c: core: fix a code to suppress a warning

On Fri, 2015-09-18 at 14:06 +0300, Andy Shevchenko wrote: > There is a warning when compiling i2c-core.c > drivers/i2c/i2c-core.c:2561:36: warning: dubious: x | !y > > Fix it by using a plain bitwise AND since I2C_M_RD is a bit 0 and > thus we are > on the safe side. Wolfram, as of today I

Re: [PATCH 1/3] i2c: uniphier: add UniPhier FIFO-less I2C driver

On Thu, Jul 30, 2015 at 05:12:20PM +0900, Masahiro Yamada wrote: > Add support for on-chip I2C controller used on old UniPhier SoCs > such as PH1-LD4, PH1-sLD8, etc.. This adapter is so simple that > it has no FIFO in it. > > Signed-off-by: Masahiro Yamada

Re: [PATCH 2/3] i2c: uniphier_f: add UniPhier FIFO-builtin I2C driver

On Thu, Jul 30, 2015 at 05:12:21PM +0900, Masahiro Yamada wrote: > Add support for on-chip I2C controller used on newer UniPhier SoCs > such as PH1-Pro4, PH1-Pro5, etc. This adapter is equipped with > 8-depth TX/RX FIFOs. > > Signed-off-by: Masahiro Yamada Same

Re: [PATCH 3/3] i2c: uniphier: add bindings for UniPhier I2C controllers

On Thu, Jul 30, 2015 at 05:12:22PM +0900, Masahiro Yamada wrote: > Device Tree bindings for two I2C controllers embedded in > UniPhier SoCs. > > Signed-off-by: Masahiro Yamada Please split this into two files with filenames matching those of the drivers. I know

Re: [GIT PULL] On-demand device probing

On Thu, Oct 22, 2015 at 04:02:13PM +0100, Russell King - ARM Linux wrote: > If it was such a problem, then in the _eight_ days that this has been > discussed so far, _someone_ would have sent some data showing the > problem. I think the fact is, there is no data. > Someone prove me wrong.

Re: Alternative approach to solve the deferred probe (was: [GIT PULL] On-demand device probing)

On Tue, Oct 20, 2015 at 04:46:56PM +0100, Russell King - ARM Linux wrote: > Something like this. I haven't put a lot of effort into it to change all > the places which return an -EPROBE_DEFER, and it also looks like we need > some helpers to report when we have only an device_node (or should

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

On Thu Oct 22 00:39, Rafael J. Wysocki wrote: > 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

Re: [GIT PULL] On-demand device probing

On 21 October 2015 at 23:50, Frank Rowand wrote: > 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

[PATCH v4 0/2] i2c: acpi: scan ACPI enumerated I2C mux channels

The following series adds support for describing ACPI enumerated I2C mux ports like this (added as Documentation/acpi/i2c-muxes.txt): +--+ +--+ | SMB1 |-->| MUX0 |--CH00--> i2c client A (0x50) | | | 0x70 |--CH01--> i2c client B (0x50) +--+ +--+ Device (SMB1) { Name

[PATCH v4 2/2] i2c: add ACPI support for I2C mux ports

Although I2C mux devices are easily enumerated using ACPI (_HID/_CID or device property compatible string match), enumerating I2C client devices connected through an I2C mux needs a little extra work. This change implements a method for describing an I2C device hierarchy that includes mux devices

[PATCH] i2c: i801: Add support for Intel Broxton

This patch adds the SMBUS PCI ID of Intel Broxton. Signed-off-by: Jarkko Nikula --- This goes on top of Mika's "[PATCH] i2c: i801: Add support for Intel DNV": http://marc.info/?l=linux-i2c=14447401042=2 --- drivers/i2c/busses/i2c-i801.c | 3 +++ 1 file

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

On Wed, Oct 21, 2015 at 03:44:04PM +0200, Ludovic Desroches wrote: > 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

Re: [GIT PULL] On-demand device probing

On Thu, Oct 22, 2015 at 11:05:11AM +0200, Tomeu Vizoso wrote: > On 21 October 2015 at 23:50, Frank Rowand wrote: > > 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

Re: [GIT PULL] On-demand device probing

On Thu, Oct 22, 2015 at 11:05:11AM +0200, Tomeu Vizoso wrote: > But that's moot currently because Greg believes that the time spent > probing devices at boot time could be reduced enough so that the order > in which devices are probed becomes irrelevant. IME that would

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

On Wed, Oct 21, 2015 at 03:44:03PM +0200, Ludovic Desroches wrote: > 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

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

On Wed, Oct 21, 2015 at 10:09:17AM +0300, Jarkko Nikula wrote: > 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

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

On Wed, Oct 21, 2015 at 05:21:46PM +0300, Jarkko Nikula wrote: > 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

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

On Tue, Oct 20, 2015 at 04:32:24PM +0200, Thomas Petazzoni wrote: > From: Hezi > > Commit 00d8689b85a7 ("i2c: mv64xxx: rework offload support to fix > several problems") completely reworked the offload support, but > stupidly left a debugging-related "return false" at the

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

On Wed, 2015-10-21 at 13:46 +0300, Mika Westerberg wrote: > You are saying that the original commit a445900c906092 ("i2c: > designware: Add support for AMD I2C controller") actually never worked > because it failed to register the clock with clkdev? In that case it is > not even a regression ;-)

[PATCH 1/1] i2c: designware: reverts "i2c: designware: Add support for AMD I2C controller"

The patch reverts commit a445900c9060 (i2c: designware: Add support for AMD I2C controller) Since kernel starts to support APD(drivers/acpi/acpi_apd.c), there is no need to get freq from id->driver_data for AMD0010. clkdev is supposed to be already registered in APD. So, revert old design and

Re: [GIT PULL] On-demand device probing

On Thu, Oct 22, 2015 at 07:44:05AM -0700, Greg Kroah-Hartman wrote: > > > On Thu, Oct 22, 2015 at 11:05:11AM +0200, Tomeu Vizoso wrote: > > Given that downstreams are already carrying as many hacks as they > > could think of to speed total boot up, I think this is

Re: Alternative approach to solve the deferred probe

Hi Russell, On 10/21/2015 09:28 PM, Russell King - ARM Linux wrote: > 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

[PATCH] i2c: i2c-imx: Use -ENXIO as error in the NACK case

According to Documentation/i2c/fault-codes the response to a bus NACK should be -ENXIO, so fix the error code. This change is similar to commit 6ff4b1051632 ("i2c: rcar: fix NACK error code"). Signed-off-by: Fabio Estevam --- drivers/i2c/busses/i2c-imx.c | 2 +- 1