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
i2c_transfer(
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 something
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 betwe
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 wh
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 mo
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 cou
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
> kthread/work
On 05/02/2018 12:48 AM, Baolin Wang wrote:
> On 2 May 2018 at 13:23, Wolfram Sang wrote:
>>
We should maybe handle this in the core somewhen, though. Or?
>>>
>>> Thanks. Yes, It will more helpful if we can handle this in the i2c core.
>>
>> To understand the issue better: which kind of devi
On 2 May 2018 at 13:23, Wolfram Sang wrote:
>
>> > We should maybe handle this in the core somewhen, though. Or?
>>
>> Thanks. Yes, It will more helpful if we can handle this in the i2c core.
>
> To understand the issue better: which kind of devices in your system
> still send I2C transfers when t
> > We should maybe handle this in the core somewhen, though. Or?
>
> Thanks. Yes, It will more helpful if we can handle this in the i2c core.
To understand the issue better: which kind of devices in your system
still send I2C transfers when the system is going to suspend? Do you
know?
signat
Hi Wolfram,
On 27 April 2018 at 20:14, Wolfram Sang wrote:
> On Mon, Apr 09, 2018 at 02:40:54PM +0800, Baolin Wang wrote:
>> Add one flag to indicate if the i2c controller has been in suspend state,
>> which can prevent i2c accesses after i2c controller is suspended following
>> system suspend.
>
On Mon, Apr 09, 2018 at 02:40:54PM +0800, Baolin Wang wrote:
> Add one flag to indicate if the i2c controller has been in suspend state,
> which can prevent i2c accesses after i2c controller is suspended following
> system suspend.
>
> Signed-off-by: Baolin Wang
Applied to for-current, thanks!
Hi Grygorii,
On 10 April 2018 at 04:56, Grygorii Strashko wrote:
>
>
> On 04/09/2018 01:40 AM, Baolin Wang wrote:
>> Add one flag to indicate if the i2c controller has been in suspend state,
>> which can prevent i2c accesses after i2c controller is suspended following
>> system suspend.
>
> This
On 04/09/2018 01:40 AM, Baolin Wang wrote:
> Add one flag to indicate if the i2c controller has been in suspend state,
> which can prevent i2c accesses after i2c controller is suspended following
> system suspend.
This usually indicates some bigger problem - there should be no i2c access to
the
Add one flag to indicate if the i2c controller has been in suspend state,
which can prevent i2c accesses after i2c controller is suspended following
system suspend.
Signed-off-by: Baolin Wang
---
drivers/i2c/busses/i2c-sprd.c | 16
1 file changed, 16 insertions(+)
diff --git
16 matches
Mail list logo