On 11/08/2014 10:51 PM, Wolfram Sang wrote:
On Sun, Jun 01, 2014 at 10:11:34PM +0200, Wolfram Sang wrote:
Feel free to adap my patch or comments and commit. Or wait a few weeks for
when I have a sponsor to split and update the patch.
OK, I'll hope you can make it for 3.17. Thanks!
I now p
On Sun, Jun 01, 2014 at 10:11:34PM +0200, Wolfram Sang wrote:
>
> > Feel free to adap my patch or comments and commit. Or wait a few weeks for
> > when I have a sponsor to split and update the patch.
>
> OK, I'll hope you can make it for 3.17. Thanks!
I now picked the part removing the interrupt
> Feel free to adap my patch or comments and commit. Or wait a few weeks for
> when I have a sponsor to split and update the patch.
OK, I'll hope you can make it for 3.17. Thanks!
signature.asc
Description: Digital signature
On 05/21/2014 10:17 AM, Wolfram Sang wrote:
dev_err(dev->dev, "controller timed out\n");
davinci_i2c_recover_bus(dev);
i2c_davinci_init(dev);
@@ -384,7 +384,6 @@ i2c_davinci_xfer_msg(struct i2c_adapter *adap, struct
i2c_msg *msg, int stop)
> > dev_err(dev->dev, "controller timed out\n");
> > davinci_i2c_recover_bus(dev);
> > i2c_davinci_init(dev);
> > @@ -384,7 +384,6 @@ i2c_davinci_xfer_msg(struct i2c_adapter *adap, struct
> > i2c_msg *msg, int stop)
> > if (dev->buf_len) {
> > /
> diff --git a/drivers/i2c/busses/i2c-davinci.c
> b/drivers/i2c/busses/i2c-davinci.c
> index af0b583..254d897 100644
> --- a/drivers/i2c/busses/i2c-davinci.c
> +++ b/drivers/i2c/busses/i2c-davinci.c
> @@ -372,9 +372,9 @@ i2c_davinci_xfer_msg(struct i2c_adapter *adap, struct
> i2c_msg *msg, int s
On 03/10/2014 04:24 PM, Wolfram Sang wrote:
Even more, you should complete the whole transfer. There are devices
where things can really go wrong if you send a half-complete command and
then start with the next one. So, not checking signals at all is the way
to go for I2C drivers. There is som
When a signal is caught while the i2c-davinci bus driver is transferring,
the drive just "abandons" the transfer and leaves the controller to fend
for itself. The next I2C transaction will find the controller in an
undefined state and often results in a stream of "initiating i2c bus recovery"
messa
> > >Even more, you should complete the whole transfer. There are devices
> > >where things can really go wrong if you send a half-complete command and
> > >then start with the next one. So, not checking signals at all is the way
> > >to go for I2C drivers. There is some cruft left, so I am happy
> >Even more, you should complete the whole transfer. There are devices
> >where things can really go wrong if you send a half-complete command and
> >then start with the next one. So, not checking signals at all is the way
> >to go for I2C drivers. There is some cruft left, so I am happy about
>
On 03/09/2014 09:21 PM, Wolfram Sang wrote:
On Thu, Jan 09, 2014 at 12:11:25PM +0100, Mike Looijmans wrote:
When a signal is caught while the i2c-davinci bus driver is transferring,
the drive just "abandons" the transfer and leaves the controller to fend
for itself. The next I2C transaction wil
On Thu, Jan 09, 2014 at 12:11:25PM +0100, Mike Looijmans wrote:
> When a signal is caught while the i2c-davinci bus driver is transferring,
> the drive just "abandons" the transfer and leaves the controller to fend
> for itself. The next I2C transaction will find the controller in an
> undefined st
When a signal is caught while the i2c-davinci bus driver is transferring,
the drive just "abandons" the transfer and leaves the controller to fend
for itself. The next I2C transaction will find the controller in an
undefined state and often results in a stream of "initiating i2c bus recovery"
messa
13 matches
Mail list logo
