Hi Cyrille,
Could you split the patch about the new alternative command mode?
Reading some comments in your code, you also fixes bad management of the
interrupt flags. It would be great if we can send this as fixes for previous
kernels.
Thanks
Ludovic
On Mon, Jun 01, 2015 at 05:49:10PM +0200,
On Mon, May 25, 2015 at 4:53 PM, Tomeu Vizoso
wrote:
> have looked into ordered probing as a
> better way of solving this than moving nodes around in the DT or playing with
> initcall levels.
>
> While reading the thread [1] that Alexander Holler started with his series to
> make probing order de
On 2 June 2015 at 10:48, Linus Walleij wrote:
> On Mon, May 25, 2015 at 4:53 PM, Tomeu Vizoso
> wrote:
>
>> have looked into ordered probing as a
>> better way of solving this than moving nodes around in the DT or playing with
>> initcall levels.
>>
>> While reading the thread [1] that Alexander
On Thu, May 28, 2015 at 3:03 PM, Vaibhav Hiremath
wrote:
> From: Rob Herring
>
> Since there is some problematic i2c slave devices on some
> platforms such as dkb (sometimes), it will drop down sda
> and make i2c bus hang, at that time, it need to config
> scl/sda into gpio to simulate "stop" se
ChangeLog
v3:
- fix braces {} coding style issue
- split the alternative command patch into 2 patches: the first one fixes
a race condition whereas the second one is the actual alternative command
patch
v2:
- fix typo in comment for AT91_TWI_SVEN.
- document new device tree bindings like "atm
This patch just fixes typo before applying later patches which will use
register bits with index above 16.
Signed-off-by: Cyrille Pitchen
---
drivers/i2c/busses/i2c-at91.c | 29 +++--
1 file changed, 15 insertions(+), 14 deletions(-)
diff --git a/drivers/i2c/busses/i2c-a
The probe() function now prints the hardware version of the I2C
controller.
Signed-off-by: Cyrille Pitchen
---
drivers/i2c/busses/i2c-at91.c | 4
1 file changed, 4 insertions(+)
diff --git a/drivers/i2c/busses/i2c-at91.c b/drivers/i2c/busses/i2c-at91.c
index 67b4f15..340ce2e 100644
--- a/d
When FIFOs are available and enabled, the driver now configures the Atmel
eXtended DMA Controller to perform word accesses instead of byte accesses
when possible.
The actual access width depends on the size of the buffer to transmit.
To enable FIFO support the "atmel,fifo-size" property must be se
The alternative command mode was introduced to simplify the transmission
of STOP conditions and to solve timing and latency issues around them.
This mode relies on a new register, the Alternative Command Register,
which must be set at the same time as the Master Mode Register. This new
register wa
For TX transactions, the TXCOMP bit in the Status Register is cleared
when the first data is written into the Transmit Holding Register.
In the lines from at91_do_twi_transfer():
at91_twi_write_data_dma(dev);
at91_twi_write(dev, AT91_TWI_IER, AT91_TWI_TXCOMP);
the TXCOMP interrupt may be enabled
add a new value "atmel,at91sama5d2-i2c" for the "compatible" property.
add a new optional property "atmel,fifo-size" to enable FIFO support when
available.
add missing optional properties "dmas" and "dma-names".
Signed-off-by: Cyrille Pitchen
---
Documentation/devicetree/bindings/i2c/i2c-at91.tx
Hello.
On 6/2/2015 4:18 PM, Cyrille Pitchen wrote:
The probe() function now prints the hardware version of the I2C
controller.
Signed-off-by: Cyrille Pitchen
---
drivers/i2c/busses/i2c-at91.c | 4
1 file changed, 4 insertions(+)
diff --git a/drivers/i2c/busses/i2c-at91.c b/driver
Hi Cyrille,
For the whole serie:
Acked-by: Ludovic Desroches
If you send a new version, could you add stable in Cc to patch 3/6:
Cc: sta...@vger.kernel.org #3.10 and later
If not, Wolfram could you do it please?
Thanks
Ludovic
On Tue, Jun 02, 2015 at 03:18:30PM +0200, Cyrille Pitchen wrote:
>
On Wed, May 20, 2015 at 04:36:52PM +0300, Jarkko Nikula wrote:
> sizeof(struct i2c_client) is 1088 bytes on a CONFIG_X86_64=y build and
> produces following warning when CONFIG_FRAME_WARN is set to 1024:
>
> drivers/i2c/i2c-core.c: In function ‘acpi_i2c_space_handler’:
> drivers/i2c/i2c-core.c:367
> If you send a new version, could you add stable in Cc to patch 3/6:
No need to send a new version just because of an additional ack. I can
apply that. However...
> Cc: sta...@vger.kernel.org #3.10 and later
> If not, Wolfram could you do it please?
The problem with 3/6 is that it seems to dep
On Wed, May 13, 2015 at 11:03:42AM +0200, Alexander Sverdlin wrote:
> Use recovery framework and implement bus recovery using "Bus Monitor"
> register.
> Tests show that shortening SDA to GND results in "completion" timeout with
> "BUSY" bit still set, so initiate recovery in this case.
>
> Signe
On Mon, Jun 01, 2015 at 11:07:07AM -0700, Eric Anholt wrote:
> Silvan Wicki writes:
>
> > Adds: make sure bits 16-31 of DIV register are always 0
> > Adds: assume minimal divider of 2 if divider resulted in 0
> > (bcm2835 sets divider to 32768 if cdiv is set to 0)
> >
> > See page 33/34 of
On Wed, May 13, 2015 at 03:02:50PM +0200, Alexander Sverdlin wrote:
> Sending a message to own address locks the controller up in very bizarre
> state,
> it behaves as slave even if MDR register clearly states master. The controller
Eeks...
>
> + if (msg->addr == DAVINCI_I2C_OWN_ADDRESS)
>
On Wed, Jun 03, 2015 at 12:36:28AM +0900, Wolfram Sang wrote:
>
> > If you send a new version, could you add stable in Cc to patch 3/6:
>
> No need to send a new version just because of an additional ack. I can
> apply that. However...
>
> > Cc: sta...@vger.kernel.org #3.10 and later
> > If not,
On Wed, May 13, 2015 at 03:03:28PM +0200, Alexander Sverdlin wrote:
> There are several problems in the function:
> - "to_cnt" variable does nothing
> - schedule_timeout() call without setting current state does nothing
> - "allow_sleep" parameter is not really used
>
> Refactor the function so th
> I was thinking the same so I have tried to cherry-pick the patch on a 3.10.79
> and it didn't cause any conflicts so I thought it could be sent to stable as
> is.
OK, so reducing context seems to help. Thanks for checking!
signature.asc
Description: Digital signature
> +#ifdef CONFIG_ACPI
> +static void acpi_i2c_mux_register_devices(struct i2c_adapter *adap,
> + struct device *mux_dev)
> +{
> + acpi_handle handle;
> + acpi_status status;
> +
> + handle = ACPI_HANDLE(mux_dev);
> + if (!handle)
> +
On Tuesday 02 June 2015 06:42 PM, Linus Walleij wrote:
On Thu, May 28, 2015 at 3:03 PM, Vaibhav Hiremath
wrote:
From: Rob Herring
Since there is some problematic i2c slave devices on some
platforms such as dkb (sometimes), it will drop down sda
and make i2c bus hang, at that time, it need
On Thursday 28 May 2015 06:53 PM, Russell King - ARM Linux wrote:
On Thu, May 28, 2015 at 06:33:44PM +0530, Vaibhav Hiremath wrote:
From: Yi Zhang
Enable i2c module/unit before transmission and disable when it finishes.
why?
It's because the i2c bus may be distrubed if the slave device,
typ
On Tuesday 02 June 2015 10:22 PM, Vaibhav Hiremath wrote:
On Thursday 28 May 2015 06:53 PM, Russell King - ARM Linux wrote:
On Thu, May 28, 2015 at 06:33:44PM +0530, Vaibhav Hiremath wrote:
From: Yi Zhang
Enable i2c module/unit before transmission and disable when it finishes.
why?
It's
> Since there is some problematic i2c slave devices on some
> platforms such as dkb (sometimes), it will drop down sda
> and make i2c bus hang, at that time, it need to config
> scl/sda into gpio to simulate "stop" sequence to recover
> i2c bus, so add this interface.
Please note that the i2c cor
On Tuesday 02 June 2015 11:03 PM, Wolfram Sang wrote:
Since there is some problematic i2c slave devices on some
platforms such as dkb (sometimes), it will drop down sda
and make i2c bus hang, at that time, it need to config
scl/sda into gpio to simulate "stop" sequence to recover
i2c bus, so
On Mon, Apr 06, 2015 at 07:40:28PM -0700, Kuppuswamy Sathyanarayanan wrote:
> If the device configuration is updated by firmware and
> the information is not passed to driver via firmware
> interfaces like ACPI or DT parameters, then that information
> will be lost once the device either resets or
> I assume you are referring to "i2c_generic_gpio_recovery", right?
>
> Rob had suggested this, and will be using it in my next version.
Great, thanks!
signature.asc
Description: Digital signature
On Wed, May 20, 2015 at 10:33:13PM +0800, Jisheng Zhang wrote:
> Commit 1fc2fe204cb9 ("i2c: designware: Add runtime PM hooks") adds
> runtime pm support using the same ops for system pm and runtime pm.
> When suspend to ram, the i2c host may have been runtime suspended, thus
> i2c_dw_disable() hang
On Tuesday 02 June 2015 11:18 PM, Wolfram Sang wrote:
I assume you are referring to "i2c_generic_gpio_recovery", right?
Rob had suggested this, and will be using it in my next version.
Great, thanks!
can you please also review the RFC which I submitted few days back?
http://www.spinics.
> can you please also review the RFC which I submitted few days back?
They are added to the queue and will be reviewed when the time comes. I
won't make any promises.
signature.asc
Description: Digital signature
On Thu, May 14, 2015 at 03:36:04PM -0700, Ray Jui wrote:
> Add suspend/resume support to the Broadcom iProc I2C driver
>
> Signed-off-by: Ray Jui
> Reviewed-by: Scott Branden
Applied to for-next, thanks!
signature.asc
Description: Digital signature
On Tuesday 02 June 2015 11:32 PM, Wolfram Sang wrote:
can you please also review the RFC which I submitted few days back?
They are added to the queue and will be reviewed when the time comes. I
won't make any promises.
Ok, take your time.
Just wanted to make sure that they don't get bur
On Thu, Apr 23, 2015 at 10:27:50PM +0200, Svenning Sørensen wrote:
> According to I2C spec, max SCL rate is 100 kHz, but SCx200/CS5536
> controller is currently driving it at 214 kHz according to my math.
>
> SCL is derived from an input clock of 48 MHz, which must be divided
> by 480 (240 cycles
Can you resend the hwlock patches? I use patchwork for tracking and
those were sent when the server had a little downtime. Thanks!
signature.asc
Description: Digital signature
To justify the need for hardware lock, lets take a real usecase scenario -
In case of Marvell SoC, PXA910 silicon, both AP and CP are present and
these two ARM cores are sharing one pair of I2C pins.
In order to keep I2C transaction operated with atomic, hardware lock
(RIPC) is required.
To justify the need for hardware lock, lets take a real usecase scenario -
In case of Marvell SoC, PXA910 silicon, both AP and CP are present and
these two ARM cores are sharing one pair of I2C pins.
In order to keep I2C transaction operated with atomic, hardware lock
(RIPC) is required.
This p
In case of PXA910 silicon, both AP and CP are present and
these two ARM cores are sharing one pair of I2C pins.
In order to keep I2C transaction operated with atomic, hardware lock
(RIPC) is required.
This patch extends support for atomic operation by adding hardware lock.
Signed-off-by: Haojian
On Tuesday 02 June 2015 11:54 PM, Wolfram Sang wrote:
Can you resend the hwlock patches? I use patchwork for tracking and
those were sent when the server had a little downtime. Thanks!
Just resent it. please check.
Thanks,
Vaibhav
--
To unsubscribe from this list: send the line "unsubscrib
PMIC TWSI pins configuration for AP and CP is different on
eden, it need to be set to function 0 when AP get RIPC lock.
When AP release RIPC lock, it also need configure twsi pins
to other state, otherwise pinctrl will assume pins configration
is not changed even if it is changed by CP, so it will
Fix section mismatch error during kernel build for xgene_slimpro_i2c_probe
function. It was incorrectly defined with __init declaration.
Signed-off-by: Feng Kan
---
drivers/i2c/busses/i2c-xgene-slimpro.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/i2c/busses/i2c-x
Hi Sang
Thanks for your comments. Please find my reply inline.
On 06/02/2015 09:19 AM, Wolfram Sang wrote:
+#ifdef CONFIG_ACPI
+static void acpi_i2c_mux_register_devices(struct i2c_adapter *adap,
+ struct device *mux_dev)
+{
+ acpi_handle handle;
+
On 06/02/2015 10:46 AM, Wolfram Sang wrote:
On Mon, Apr 06, 2015 at 07:40:28PM -0700, Kuppuswamy Sathyanarayanan wrote:
If the device configuration is updated by firmware and
the information is not passed to driver via firmware
interfaces like ACPI or DT parameters, then that information
will
On Tue, Jun 02, 2015 at 05:38:20PM -0700, sathyanarayanan kuppuswamy wrote:
> Hi Sang
>
> Thanks for your comments. Please find my reply inline.
>
> On 06/02/2015 09:19 AM, Wolfram Sang wrote:
> >>+#ifdef CONFIG_ACPI
> >>+static void acpi_i2c_mux_register_devices(struct i2c_adapter *adap,
> >>+
45 matches
Mail list logo
