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 an
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
> >---
> > drivers/i2c/busses/i2c-desig
+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 information
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 I2C_FUNC
On Tue, Dec 15, 2015 at 11:15:06PM +, Mans Rullgard wrote:
> The Sigma Designs variant of this controller has the ability to generate
> interrupts. This is controlled using two additional registers, oddly
> enough overlapping with the defined but unused HDSTATIM.
>
> This patch adds support f
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 to achieve this, since it has prope
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 ever
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 cli
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
currentl
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.
> >
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
--
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 act
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
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(&pdev->dev, NULL);
> if (!IS_ER
On Wed, 16 Dec 2015, Wolfram Sang wrote:
> 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_runt
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 pro
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 am
> currently impleme
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? When an I2C
>> > bus is marked in DT as
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 needs to be
> > disab
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
CONFIG_INSTRUCTION_DECODE
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 wor
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 | 22 +-
1 file changed, 9 insertions(+), 13 deleti
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
---
drivers/i2c/busses/i2c-rcar.c | 17 ++---
1 file changed, 14 insertions(+), 3 deleti
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
Cc: devicet...@vger.kernel.org
---
Documentatio
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
---
drivers/i2c/busses/i2c-rcar.c | 17 +
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 achieve this, since it has proper
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 di
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(-)
diff --git a/Documentatio
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
> next-20151215.
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.
> >
>
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.
>
> This series is RFC
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, Sur
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
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 provid
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
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
36 matches
Mail list logo
