On 05/08/2018 11:32 AM, Wolfram Sang wrote:
Grygorii,
thanks a lot for your input. Much appreciated!
That would be great, but note:
1) only i2c_transfer() operations are locked, so if driver is doing
i2c_transfer(1)
i2c_transfer(2) <- suspend in the middle
<- suspend in between
On 05/08/2018 11:32 AM, Wolfram Sang wrote:
Grygorii,
thanks a lot for your input. Much appreciated!
That would be great, but note:
1) only i2c_transfer() operations are locked, so if driver is doing
i2c_transfer(1)
i2c_transfer(2) <- suspend in the middle
<- suspend in between
On Sat, May 05, 2018 at 10:32:55AM +0200, Wolfram Sang wrote:
> > OTOH it does mean we might not notice things happening later than they
> > should so it's not 100% clear...
> What do you mean here?
If someone is doing I/O later than they should currently we'll notice as
they try to do
On Sat, May 05, 2018 at 10:32:55AM +0200, Wolfram Sang wrote:
> > OTOH it does mean we might not notice things happening later than they
> > should so it's not 100% clear...
> What do you mean here?
If someone is doing I/O later than they should currently we'll notice as
they try to do
On 2018-05-08 18:32, Wolfram Sang wrote:
> Grygorii,
>
> thanks a lot for your input. Much appreciated!
>
>> That would be great, but note:
>> 1) only i2c_transfer() operations are locked, so if driver is doing
>> i2c_transfer(1)
>> i2c_transfer(2) <- suspend in the middle
>> <- suspend in
On 2018-05-08 18:32, Wolfram Sang wrote:
> Grygorii,
>
> thanks a lot for your input. Much appreciated!
>
>> That would be great, but note:
>> 1) only i2c_transfer() operations are locked, so if driver is doing
>> i2c_transfer(1)
>> i2c_transfer(2) <- suspend in the middle
>> <- suspend in
Grygorii,
thanks a lot for your input. Much appreciated!
> That would be great, but note:
> 1) only i2c_transfer() operations are locked, so if driver is doing
> i2c_transfer(1)
> i2c_transfer(2) <- suspend in the middle
> <- suspend in between
> i2c_transfer(3)
> It will not help.
Will it not
Grygorii,
thanks a lot for your input. Much appreciated!
> That would be great, but note:
> 1) only i2c_transfer() operations are locked, so if driver is doing
> i2c_transfer(1)
> i2c_transfer(2) <- suspend in the middle
> <- suspend in between
> i2c_transfer(3)
> It will not help.
Will it not
On 05/04/2018 07:24 AM, Wolfram Sang wrote:
> Hi Grygorii,
>
> thanks for stepping in. I kept thinking about better I2C core support
> for such situations and the more input the better.
>
>> And you have to fix it (touch screen) - not your i2c driver. Otherwise, you
>> can get
>> situation
On 05/04/2018 07:24 AM, Wolfram Sang wrote:
> Hi Grygorii,
>
> thanks for stepping in. I kept thinking about better I2C core support
> for such situations and the more input the better.
>
>> And you have to fix it (touch screen) - not your i2c driver. Otherwise, you
>> can get
>> situation
Hi Mark,
> > And maybe this could be used here, too? Introduce this flag for very
> > late/early messages. If they have it, messages are even sent in
> > suspend_noirq() phase with the master_xfer_irqless() callback, otherwise
> > we will have the WARNing printed out.
>
> It feels like it'd be
Hi Mark,
> > And maybe this could be used here, too? Introduce this flag for very
> > late/early messages. If they have it, messages are even sent in
> > suspend_noirq() phase with the master_xfer_irqless() callback, otherwise
> > we will have the WARNing printed out.
>
> It feels like it'd be
On Fri, May 04, 2018 at 02:24:47PM +0200, Wolfram Sang wrote:
> To handle that, I imagined an additional adapter callback like
> 'master_xfer_irqless' to be used for such special I2C messages. These
> kind of special messages could be tagged with a new I2C_M_something
> flag.
> And maybe this
On Fri, May 04, 2018 at 02:24:47PM +0200, Wolfram Sang wrote:
> To handle that, I imagined an additional adapter callback like
> 'master_xfer_irqless' to be used for such special I2C messages. These
> kind of special messages could be tagged with a new I2C_M_something
> flag.
> And maybe this
Hi Grygorii,
thanks for stepping in. I kept thinking about better I2C core support
for such situations and the more input the better.
> And you have to fix it (touch screen) - not your i2c driver. Otherwise, you
> can get
> situation when set of I2C transfers (executed from some
>
Hi Grygorii,
thanks for stepping in. I kept thinking about better I2C core support
for such situations and the more input the better.
> And you have to fix it (touch screen) - not your i2c driver. Otherwise, you
> can get
> situation when set of I2C transfers (executed from some
>
16 matches
Mail list logo
