On Wed, Jun 10, 2015 at 10:28 AM, Alexander Holler wrote:
> Am 10.06.2015 um 09:30 schrieb Linus Walleij:
>> i2c host comes out, probes the regulator driver, regulator driver
>> probes and then the regulator_get() call returns.
>>
>> This requires instrumentation on anything providing a resource
On Wed, Jun 10, 2015 at 12:19 PM, Tomeu Vizoso
wrote:
> On 10 June 2015 at 09:30, Linus Walleij wrote:
>> regulator_get(...) -> not available, so:
>> - identify target regulator provider - this will need instrumentation
>> - probe it
>>
>> It then turns out the regulator driver is on the i2c bus
ChangeLog
v1:
This patch fixes somes code checker warnings reported by Wolfram Sang:
drivers/i2c/busses/i2c-at91.c:213: style: Checking if unsigned variable
'buf_len' is less than zero.
drivers/i2c/busses/i2c-at91.c:254: style: Checking if unsigned variable
'buf_len' is less than zero.
drivers/
buf_len is a size_t, so unsigned but was tested with '<= 0'.
Signed-off-by: Cyrille Pitchen
---
drivers/i2c/busses/i2c-at91.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/i2c/busses/i2c-at91.c b/drivers/i2c/busses/i2c-at91.c
index 0d2dc7d..967c0cb 100644
---
Hi all,
this patch was made after applying the previous series
"[PATCH v6 0/6] i2c: at91: add support to FIFOs and alternative command",
which was already accepted.
Best Regards,
Cyrille
Le 11/06/2015 11:16, Cyrille Pitchen a écrit :
> ChangeLog
>
> v1:
> This patch fixes somes code checker wa
On Thu, Jun 11, 2015 at 7:20 AM, Gao Pan wrote:
> In our former i2c driver, i2c clk is enabled and disabled in
> xfer function, which contributes to power saving. However,
> the clk enable process brings a busy wait delay until the core
> is stable. As a result, the performance is sacrificed.
>
>
There are several cases where current clock configuration algorithm produces
not optimal results:
- truncation in "clk" calculation leads to the fact that actual BUS frequency
will be always higher than spec except two exact module frequences 8MHz and
12MHz in the whole 7-12MHz range of permitt
On Wed, Jun 10, 2015 at 05:05:16PM +0200, christian.rupp...@alitech.com wrote:
>We should understand why the controller was disabled after successful
>transfers in the first place, however. Maybe some quirk with older
>versions of the hardware? Mika, do you have any memories about this?
From: Shubhrajyoti Datta Sent: Thursday, June 11,
2015 5:29 PM
> To: Gao Pan-B54642
> Cc: Wolfram Sang; Linux-I2C; Li Frank-B20596; Duan Fugang-B38611
> Subject: Re: [Patch v1] i2c: imx: add runtime pm support to improve the
> performance
>
> On Thu, Jun 11, 2015 at 7:20 AM, Gao Pan wrote:
> >
>> > static irqreturn_t i2c_imx_isr(int irq, void *dev_id) @@ -583,6
>> > +582,9 @@ static irqreturn_t i2c_imx_isr(int irq, void *dev_id)
>> > struct imx_i2c_struct *i2c_imx = dev_id;
>> > unsigned int temp;
>> >
>> > + if (pm_runtime_suspended(i2c_imx->adapter.dev.parent))
Am 11.06.2015 um 10:12 schrieb Linus Walleij:
On Wed, Jun 10, 2015 at 10:28 AM, Alexander Holler wrote:
Am 10.06.2015 um 09:30 schrieb Linus Walleij:
i2c host comes out, probes the regulator driver, regulator driver
probes and then the regulator_get() call returns.
This requires instrumenta
From: Shubhrajyoti Datta Sent: Thursday, June 11,
2015 6:11 PM
> To: Duan Fugang-B38611
> Cc: Gao Pan-B54642; Wolfram Sang; Linux-I2C; Li Frank-B20596
> Subject: Re: [Patch v1] i2c: imx: add runtime pm support to improve the
> performance
>
>
> >> > static irqreturn_t i2c_imx_isr(int irq, void
Am 11.06.2015 um 12:17 schrieb Alexander Holler:
Am 11.06.2015 um 10:12 schrieb Linus Walleij:
On Wed, Jun 10, 2015 at 10:28 AM, Alexander Holler
wrote:
Am 10.06.2015 um 09:30 schrieb Linus Walleij:
i2c host comes out, probes the regulator driver, regulator driver
probes and then the regula
Am 11.06.2015 um 13:24 schrieb Alexander Holler:
> Am 11.06.2015 um 12:17 schrieb Alexander Holler:
>> Am 11.06.2015 um 10:12 schrieb Linus Walleij:
>>> On Wed, Jun 10, 2015 at 10:28 AM, Alexander Holler
>>> wrote:
Am 10.06.2015 um 09:30 schrieb Linus Walleij:
>>>
> i2c host comes out, pr
On Thu, Jun 11, 2015 at 11:16:32AM +0200, Cyrille Pitchen wrote:
> buf_len is a size_t, so unsigned but was tested with '<= 0'.
>
> Signed-off-by: Cyrille Pitchen
Acked-by: Ludovic Desroches
Thanks
> ---
> drivers/i2c/busses/i2c-at91.c | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletio
The KERNCZ is new AMD SB/FCH generation name, like HUDSON2.
We will adopt 0x790b as device ID since from this gereration.
Signed-off-by: Wan ZongShun
---
include/linux/pci_ids.h | 1 +
1 file changed, 1 insertion(+)
diff --git a/include/linux/pci_ids.h b/include/linux/pci_ids.h
index 2f7b9a4..c
Change this quirk to apply to AMD Carrizo platform.
Signed-off-by: Wan ZongShun
Tested-by: Nath, Arindam
Tested-by: Ramesh, Ramya
---
drivers/mmc/host/sdhci-pci.c | 25 -
1 file changed, 24 insertions(+), 1 deletion(-)
diff --git a/drivers/mmc/host/sdhci-pci.c b/drive
On Thu, Jun 11, 2015 at 12:17 PM, Alexander Holler wrote:
> Am 11.06.2015 um 10:12 schrieb Linus Walleij:
>> On Wed, Jun 10, 2015 at 10:28 AM, Alexander Holler
>> wrote:
>>> You would end up with the same problem of deadlocks as currently, and you
>>> would still need something ugly like the def
Change AMD CZ SMBUS device ID from 0x790b to
use Macro definition
Signed-off-by: Wan ZongShun
---
drivers/i2c/busses/i2c-piix4.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/i2c/busses/i2c-piix4.c b/drivers/i2c/busses/i2c-piix4.c
index 67cbec6..630bce6 100644
-
On Thu, Jun 11, 2015 at 08:11:46PM +0800, Wan ZongShun wrote:
> Change AMD CZ SMBUS device ID from 0x790b to
> use Macro definition
>
> Signed-off-by: Wan ZongShun
I think it makes sense that this patch goes in via MMC. This I2C change
is trivial, but for MMC there is more to handle. I don't exp
On 06/11/2015 12:17 PM, Alexander Holler wrote:
> Am 11.06.2015 um 10:12 schrieb Linus Walleij:
>> On Wed, Jun 10, 2015 at 10:28 AM, Alexander Holler
>> wrote:
>>> Am 10.06.2015 um 09:30 schrieb Linus Walleij:
>>
i2c host comes out, probes the regulator driver, regulator driver
probes a
On Thu, Jun 11, 2015 at 11:16:32AM +0200, Cyrille Pitchen wrote:
> buf_len is a size_t, so unsigned but was tested with '<= 0'.
>
> Signed-off-by: Cyrille Pitchen
Applied to for-next, thanks!
signature.asc
Description: Digital signature
he task state to TASK_UNINTERRUPTIBLE.
Someone that knows the details of this driver needs to confirm this though.
Patch was compile tested with cavium_octeon_defconfig
(implies CONFIG_I2C_OCTEON=y)
Patch is against 4.1-rc7 (localversion-next is -next-20150611)
drivers/i2c/busses/i2c-octeon.c |
On Thu, Jun 11, 2015 at 03:23:52PM +0200, Nicholas Mc Guire wrote:
> Change wait_event_timeout() to wait_event_interruptible_timeout() allowing
> signals to be received while waiting on event (task state set to
> TASK_INTERRUPTIBLE) as the dev_dbg() string indicates that signals
> are expected to
On Thu, 11 Jun 2015, Wolfram Sang wrote:
> On Thu, Jun 11, 2015 at 03:23:52PM +0200, Nicholas Mc Guire wrote:
> > Change wait_event_timeout() to wait_event_interruptible_timeout() allowing
> > signals to be received while waiting on event (task state set to
> > TASK_INTERRUPTIBLE) as the dev_dbg(
ium_octeon_defconfig
(implies CONFIG_I2C_OCTEON=y)
Patch is against 4.1-rc7 (localversion-next is -next-20150611)
drivers/i2c/busses/i2c-octeon.c |7 ++-
1 file changed, 2 insertions(+), 5 deletions(-)
diff --git a/drivers/i2c/busses/i2c-octeon.c b/drivers/i2c/busses/i2c-octeon.c
in
Hi,
On 06/10, christian.rupp...@alitech.com wrote:
> Mika Westerberg wrote on 10.06.2015
> 09:07:22:
> > My concern is that this patch might break some non-Intel platform. It
> > would be nice if someone (Christian?) could try this out.
>
> Ouch, this one brings back painful memories. Take a lo
c7 (localversion-next is -next-20150611)
drivers/i2c/busses/i2c-mv64xxx.c | 15 +++
1 file changed, 3 insertions(+), 12 deletions(-)
diff --git a/drivers/i2c/busses/i2c-mv64xxx.c b/drivers/i2c/busses/i2c-mv64xxx.c
index 30059c1..a4f8ece 100644
--- a/drivers/i2c/busses/i2c-mv64xxx.
Am 11.06.2015 um 14:30 schrieb Linus Walleij:
On Thu, Jun 11, 2015 at 12:17 PM, Alexander Holler wrote:
Am 11.06.2015 um 10:12 schrieb Linus Walleij:
On Wed, Jun 10, 2015 at 10:28 AM, Alexander Holler
wrote:
You would end up with the same problem of deadlocks as currently, and you
would st
On Thursday 28 May 2015 07:25 PM, Vaibhav Hiremath wrote:
On Monday 25 May 2015 03:17 PM, Vaibhav Hiremath wrote:
Hi,
This is rather an old issue, for which I have also done custom & hacky
solution in the past.
Please let me know if there is already an some other method or accepted
workar
From: Sascha Hauer
The Congatec CGEB is a BIOS interface found on some Congatec x86
modules. It provides access to on board peripherals like I2C busses
and watchdogs. This driver contains the basic support for accessing
the CGEB interface and registers the child devices.
Signed-off-by: Sascha Ha
This driver provides support for the CGEB backlight found on some
Congatec x86 modules.
Signed-off-by: Christian Gmeiner
---
drivers/video/backlight/Kconfig| 7 ++
drivers/video/backlight/Makefile | 1 +
drivers/video/backlight/congatec-cgeb_bl.c | 125 +
From: Sascha Hauer
This driver provides support for the CGEB watchdog found on some
Congatec x86 modules.
Signed-off-by: Sascha Hauer
Signed-off-by: Christian Gmeiner
---
drivers/watchdog/Kconfig | 10 ++
drivers/watchdog/Makefile | 3 +
drivers/watchdog/co
From: Sascha Hauer
This driver provides a I2C bus driver for the CGEB interface
found on some Congatec x86 modules. No devices are registered
on the bus, the user has to do this via the i2c device /sys
interface.
Signed-off-by: Sascha Hauer
Signed-off-by: Christian Gmeiner
---
drivers/i2c/bus
The following series adds support for the Congatec CGEB interface
found on some Congatec x86 boards. The CGEB interface is a BIOS
interface which provides access to onboard peripherals like I2C
busses and watchdogs. It works by mapping BIOS code and searching
for magic values which specify the entr
On 06/11/2015 01:48 PM, Christian Gmeiner wrote:
From: Sascha Hauer
This driver provides support for the CGEB watchdog found on some
Congatec x86 modules.
Signed-off-by: Sascha Hauer
Signed-off-by: Christian Gmeiner
Hi Christian,
comments inline.
Thanks,
Guenter
---
drivers/watchdog/
> Current implementation:
>
>
> Everyone probably does have their own custom implementation for this.
> Or some other mechanism to achieve this (may be hardware support).
Do you have examples? It is easier to look at code.
> /* We can also check i2c_check_functionality(adap,
37 matches
Mail list logo
