On Sat, Dec 12, 2015 at 06:13:55PM +0100, Wolfram Sang wrote:
>
> > Frankly speaking I do not know where the fix should actually be. I2C IMX
> > driver somehow taking care of this or the users of I2C, touchscreen drivers
> > in this case. In my opinion, the fix should be with the touchscreen
This patch removes the use of i2c_msg locally inside the function.
Without this, having i2c_msg locally allocated on stack, being used
by i2c_transfer on a platform where the I2C driver uses DMA, results
in the debug stack trace being reported during kernel boot in case
CONFIG_DMA_API_DEBUG is
On Thu, Dec 10, 2015 at 01:48:43PM +0200, Jarkko Nikula wrote:
> On an hardware shared I2C bus (certain Intel Baytrail SoC platforms) the
> runtime PM disable depth keeps increasing over repeated modprobe/rmmod
> cycle because pm_runtime_disable() is called without checking should it
> be disabled
On Fri, Dec 11, 2015 at 08:02:53PM +0800, Xiangliang Yu wrote:
> Because of some hardware limitation, AMD I2C controller can't
> trigger pending interrupt if interrupt status has been changed
> after clearing interrupt status bits. Then, I2C will lost
> interrupt and IO timeout.
>
> According to
> Frankly speaking I do not know where the fix should actually be. I2C IMX
> driver somehow taking care of this or the users of I2C, touchscreen drivers
> in this case. In my opinion, the fix should be with the touchscreen driver
> however I did like to have feedback or hear opinions on what is
On Saturday 12 December 2015 17:20:57 Wolfram Sang wrote:
> Hi Arnd,
>
> thanks for looking into this, but I don't get your point yet.
>
> > The slave_cb callback function is supposed to set the 'value'
> > here,
>
> Only if a master wants to READ from us.
Right, and can this never fail?
> >
