[V1, 1/2] i2c: brcmstb: Adding support for CM and DSL SoCs

Broadcoms DSL, CM (cable modem)and STB I2C core implementation have 8 data in/out registers that can transfer 8 bytes or 32 bytes max. Cable and DSL "Peripheral" i2c cores use single byte per data register and the STB can use 4 byte per data register transfer. Adding support to take care of this

Re: linux-next: Tree for Dec 16 (i2c/busses/i2c-emev2)

On Wed, Dec 16, 2015 at 01:05:20PM -0800, Randy Dunlap wrote: > On 12/15/15 21:43, Stephen Rothwell wrote: > > Hi all, > > > > Changes since 20151215: > > > > The drm-misc tree gained a conflict against Linus' tree. > > > > The i2c tree gained a build failure for which I applied a patch. > > >

[V1, 2/2] dt-bindings: i2c: Update i2c-brcmstb compatible string

Adding compatibility with the DSL and CM SoCs that use the "Peripheral" i2c hardware. "brcm,brcmper-i2c" is also an allowed string. Signed-off-by: Kamal Dasu --- Documentation/devicetree/bindings/i2c/i2c-brcmstb.txt | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)

Re: linux-next: Tree for Dec 16 (i2c/busses/i2c-emev2)

On 12/15/15 21:43, Stephen Rothwell wrote: > Hi all, > > Changes since 20151215: > > The drm-misc tree gained a conflict against Linus' tree. > > The i2c tree gained a build failure for which I applied a patch. > > The gpio tree gained a build failure so I used the version from >

[RFC 0/3] i2c: rcar: adapt PM usage to multi master case

If we are in a multi-master scenario, we need to block runtime PM so the arbitration circuit stays awake. So, we define a new binding and adapt the i2c-rcar driver to have an example implementation. This series is RFC because I want to do some more regression testing. The actual functionality

[RFC 2/3] i2c: rcar: remove macros dealing with flags

From: Wolfram Sang These macros don't really hide complexity, but C idioms. Removing them makes the code easier to read IMO and make a planned extension easier. Signed-off-by: Wolfram Sang --- drivers/i2c/busses/i2c-rcar.c |

[RFC 3/3] i2c: rcar: disable PM in multi-master mode

From: Wolfram Sang In multi master mode, the IP core needs to be always active for arbitration reasons. Get the config from DT and set up PM depending on the config. Signed-off-by: Wolfram Sang ---

[RFC 1/3] i2c: document binding for multi-master case

From: Wolfram Sang We need this binding because some I2C master drivers will need to adapt their PM settings for the arbitration circuitry. I skipped the "i2c-" prefix because I can imagine to be useful outside of i2c. Signed-off-by: Wolfram Sang

[PATCH v2] i2c: rcar: disable runtime PM correctly in slave mode

From: Wolfram Sang When we also are I2C slave, we need to disable runtime PM because the address detection mechanism needs to be active all the time. However, we can reenable runtime PM once the slave instance was unregistered. So, use pm_runtime_get_sync/put to

Re: [RFC 3/3] i2c: rcar: disable PM in multi-master mode

Hello. On 12/16/2015 09:44 PM, Wolfram Sang wrote: From: Wolfram Sang In multi master mode, the IP core needs to be always active for arbitration reasons. Get the config from DT and set up PM depending on the config. Signed-off-by: Wolfram Sang

Re: [RFC 0/3] i2c: rcar: adapt PM usage to multi master case

Hi Wolfram, On Wed, Dec 16, 2015 at 7:44 PM, Wolfram Sang wrote: > If we are in a multi-master scenario, we need to block runtime PM so the > arbitration circuit stays awake. > > So, we define a new binding and adapt the i2c-rcar driver to have an example > implementation. >

Re: [PATCH v2] 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 > to

Re: [PATCH] i2c: designware: Add support for AMD Seattle I2C

Mika, On 12/16/2015 8:54 AM, Mika Westerberg wrote: On Wed, Dec 16, 2015 at 08:29:38AM -0600, Suravee Suthikulpanit wrote: > > >On 12/16/2015 03:16 AM, Mika Westerberg wrote: > >On Tue, Dec 15, 2015 at 08:14:34PM -0600, Suravee Suthikulpanit wrote: > >>Hi Mika, > >> > >>On 12/15/15 15:55,

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

On 12/16/2015 8:56 PM, Loc Ho wrote: 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

Re: [PATCH] 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 > to

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

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 to directly

Re: [PATCH] i2c: s3c2410: remove superfluous runtime PM calls

On 15/12/15 19:14, Wolfram Sang wrote: > Since commit 6ada5c1e1b077a ("i2c: Mark adapter devices with > pm_runtime_no_callbacks"), runtime PM on adapters turned into a no-op. > So, we can remove these calls. Won't this break i2c client devices that use runtime PM? Not sure if any cases of such

[PATCH] i2c: rcar: disable runtime PM correctly in slave mode

From: Wolfram Sang When we also are I2C slave, we need to disable runtime PM because the address detection mechanism needs to be active all the time. However, we can reenable runtime PM once the slave instance was unregistered. So, use pm_runtime_disable/enable

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

Hi Mika, On 12/16/2015 03:42 AM, Mika Westerberg wrote: +Jarkko and Andy On Tue, Dec 15, 2015 at 04:38:58PM -0600, Suravee Suthikulpanit wrote: The current driver uses input clock source frequency to calculate values for [SS|FS]_[HC|LC] registers. However, when booting ACPI, we do not

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

On Wed, Dec 16, 2015 at 08:44:34AM -0600, Suravee Suthikulpanit wrote: > I am trying to avoid having to hard-coded clock frequency value in the > driver. Would it be alright to not return w/ error, and just do the > following? > > dev->clk = devm_clk_get(>dev, NULL); > if

Re: [PATCH] i2c: designware: Add support for AMD Seattle I2C

On 12/16/2015 03:16 AM, Mika Westerberg wrote: On Tue, Dec 15, 2015 at 08:14:34PM -0600, Suravee Suthikulpanit wrote: Hi Mika, On 12/15/15 15:55, Suravee Suthikulpanit wrote: Add device HID AMDI0510 to match the I2C controlers on AMD Seattle platform Signed-off-by: Suravee Suthikulpanit

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

On Wed, Dec 16, 2015 at 08:11:12AM -0600, Suravee Suthikulpanit wrote: > >The clk framework should work fine if the returned clock is NULL (which > >I think is your case). > > > >The driver gates clocks when the device is suspended and on Intel LPSS > >there actually is a clock that gets gated. >

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

On 12/16/2015 08:28 AM, Mika Westerberg wrote: On Wed, Dec 16, 2015 at 08:11:12AM -0600, Suravee Suthikulpanit wrote: The clk framework should work fine if the returned clock is NULL (which I think is your case). The driver gates clocks when the device is suspended and on Intel LPSS there

Re: [PATCH] i2c: designware: Add support for AMD Seattle I2C

On Wed, Dec 16, 2015 at 08:29:38AM -0600, Suravee Suthikulpanit wrote: > > > On 12/16/2015 03:16 AM, Mika Westerberg wrote: > >On Tue, Dec 15, 2015 at 08:14:34PM -0600, Suravee Suthikulpanit wrote: > >>Hi Mika, > >> > >>On 12/15/15 15:55, Suravee Suthikulpanit wrote: > >>>Add device HID AMDI0510

Re: [PATCH v2 1/2] i2c: xlr: fix extra read/write at end of rx transfer

On Tue, Dec 15, 2015 at 11:15:05PM +, Mans Rullgard wrote: > The BYTECNT register holds the transfer size minus one. Setting it to > the correct value removes the need for a dummy read/write at the end of > each transfer. As zero-length transfers are not supported, do not > advertise

Re: [PATCH v2 0/2] i2c:dw: Add APM X-Gene ACPI I2C device support

On 12/16/2015 11:04 AM, Mika Westerberg wrote: On Tue, Dec 15, 2015 at 11:20:03AM -0800, Loc Ho wrote: Can we not just add an AML method that will return the operation clock frequency that the I2C driver can use? If the method doesn't existed, we will just bail and do nothing or assume what

Re: [PATCH] i2c: rcar: disable runtime PM correctly in slave mode

Hi Wolfram, On Wed, Dec 16, 2015 at 4:43 PM, Wolfram Sang wrote: > I have another case, may I ask your advice about this, too? When an I2C > bus is marked in DT as multi-master, then RuntimePM also needs to be > disabled, because arbitration detection needs to stay awake. I

Re: [PATCH] i2c: rcar: disable runtime PM correctly in slave mode

Hi Wolfram, On Wed, Dec 16, 2015 at 5:06 PM, Wolfram Sang wrote: > On Wed, Dec 16, 2015 at 04:55:28PM +0100, Geert Uytterhoeven wrote: >> On Wed, Dec 16, 2015 at 4:43 PM, Wolfram Sang wrote: >> > I have another case, may I ask your advice about this, too?

Re: [PATCH] i2c: rcar: disable runtime PM correctly in slave mode

On Wed, Dec 16, 2015 at 04:55:28PM +0100, Geert Uytterhoeven wrote: > Hi Wolfram, > > On Wed, Dec 16, 2015 at 4:43 PM, Wolfram Sang wrote: > > I have another case, may I ask your advice about this, too? When an I2C > > bus is marked in DT as multi-master, then RuntimePM also

Re: [PATCH] i2c: rcar: disable runtime PM correctly in slave mode

Alan, > > When we also are I2C slave, we need to disable runtime PM because the > > address detection mechanism needs to be active all the time. However, we > > can reenable runtime PM once the slave instance was unregistered. So, > > use pm_runtime_disable/enable to achieve this, since it has

randconfig build error with next-20151216, in drivers/i2c/busses

Building with the attached random configuration file, ERROR: "i2c_parse_fw_timings" [drivers/i2c/busses/i2c-rcar.ko] undefined! -- Jim # # Automatically generated file; DO NOT EDIT. # Linux/x86 4.4.0-rc5 Kernel Configuration # CONFIG_64BIT=y CONFIG_X86_64=y CONFIG_X86=y

Re: [PATCH] i2c: designware: Add support for AMD Seattle I2C

On Tue, Dec 15, 2015 at 08:14:34PM -0600, Suravee Suthikulpanit wrote: > Hi Mika, > > On 12/15/15 15:55, Suravee Suthikulpanit wrote: > >Add device HID AMDI0510 to match the I2C controlers on AMD Seattle platform > > > >Signed-off-by: Suravee Suthikulpanit > >--- >

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

+Jarkko and Andy On Tue, Dec 15, 2015 at 04:38:58PM -0600, Suravee Suthikulpanit wrote: > 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

Re: [PATCH v2 0/2] i2c:dw: Add APM X-Gene ACPI I2C device support

On Tue, Dec 15, 2015 at 11:20:03AM -0800, Loc Ho wrote: > Can we not just add an AML method that will return the operation clock > frequency that the I2C driver can use? If the method doesn't existed, > we will just bail and do nothing or assume what ever default behavior? Why would you add yet