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 ;-) Oh
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 mak
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 that
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. Someo
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 comments as for the other driver.
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 they will be very similar but I'd
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
Finally! Mostly looking good.
> +stat
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
> >> probing devices at boot time cou
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 which devices are probed beco
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 (\_SB.PCI0.I2C3)
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 file changed, 1 insertion(+),
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
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 effectively
> > telling them to
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 have to
> be under 200ms so
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 AM, Mark Brown wrote:
> On Wed, Oct 21, 2015
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&m=14447401042&w=2
---
drivers/i2c/busses/i2c-i801.c | 3 +++
1 file changed, 3 insertions(+)
diff --gi
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 Receiv
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 pending interruptions before
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 beginning of
> the mv64x
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
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 set.
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 didn't
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.
> > >
> > > Yes
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 was done in process context while h
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 interrupt context. Because of the
> > > 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
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
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 setting the ACPI companion. Howeve
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 b/include/linux/acpi.h
index 51a96a8
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
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 10:40:03AM -0400, Alan Stern wrote:
>> >>
>> >> > F
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 Rowand wrote:
> On 10/19/2015 5:34 AM, Tomeu V
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.
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:
> http://elinux.org/Minnowboard:MinnowMaxLi
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
35 matches
Mail list logo