Re: I2C PM overhaul needed? (Re: [PATCH 1/2] i2c: sprd: Prevent i2c accesses after suspend is called)

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

Re: I2C PM overhaul needed? (Re: [PATCH 1/2] i2c: sprd: Prevent i2c accesses after suspend is called)

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

Re: I2C PM overhaul needed? (Re: [PATCH 1/2] i2c: sprd: Prevent i2c accesses after suspend is called)

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

Re: I2C PM overhaul needed? (Re: [PATCH 1/2] i2c: sprd: Prevent i2c accesses after suspend is called)

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

Re: I2C PM overhaul needed? (Re: [PATCH 1/2] i2c: sprd: Prevent i2c accesses after suspend is called)

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

Re: I2C PM overhaul needed? (Re: [PATCH 1/2] i2c: sprd: Prevent i2c accesses after suspend is called)

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

Re: I2C PM overhaul needed? (Re: [PATCH 1/2] i2c: sprd: Prevent i2c accesses after suspend is called)

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

Re: I2C PM overhaul needed? (Re: [PATCH 1/2] i2c: sprd: Prevent i2c accesses after suspend is called)

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

Re: I2C PM overhaul needed? (Re: [PATCH 1/2] i2c: sprd: Prevent i2c accesses after suspend is called)

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

Re: I2C PM overhaul needed? (Re: [PATCH 1/2] i2c: sprd: Prevent i2c accesses after suspend is called)

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

Re: I2C PM overhaul needed? (Re: [PATCH 1/2] i2c: sprd: Prevent i2c accesses after suspend is called)

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

Re: I2C PM overhaul needed? (Re: [PATCH 1/2] i2c: sprd: Prevent i2c accesses after suspend is called)

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

Re: I2C PM overhaul needed? (Re: [PATCH 1/2] i2c: sprd: Prevent i2c accesses after suspend is called)

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

Re: I2C PM overhaul needed? (Re: [PATCH 1/2] i2c: sprd: Prevent i2c accesses after suspend is called)

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

I2C PM overhaul needed? (Re: [PATCH 1/2] i2c: sprd: Prevent i2c accesses after suspend is called)

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 >

I2C PM overhaul needed? (Re: [PATCH 1/2] i2c: sprd: Prevent i2c accesses after suspend is called)

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 >

Re: [PATCH 1/2] i2c: sprd: Prevent i2c accesses after suspend is called

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

Re: [PATCH 1/2] i2c: sprd: Prevent i2c accesses after suspend is called

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

Re: [PATCH 1/2] i2c: sprd: Prevent i2c accesses after suspend is called

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

Re: [PATCH 1/2] i2c: sprd: Prevent i2c accesses after suspend is called

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

Re: [PATCH 1/2] i2c: sprd: Prevent i2c accesses after suspend is called

> > 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?

Re: [PATCH 1/2] i2c: sprd: Prevent i2c accesses after suspend is called

> > 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?

Re: [PATCH 1/2] i2c: sprd: Prevent i2c accesses after suspend is called

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

Re: [PATCH 1/2] i2c: sprd: Prevent i2c accesses after suspend is called

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.

Re: [PATCH 1/2] i2c: sprd: Prevent i2c accesses after suspend is called

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

Re: [PATCH 1/2] i2c: sprd: Prevent i2c accesses after suspend is called

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!

Re: [PATCH 1/2] i2c: sprd: Prevent i2c accesses after suspend is called

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

Re: [PATCH 1/2] i2c: sprd: Prevent i2c accesses after suspend is called

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

Re: [PATCH 1/2] i2c: sprd: Prevent i2c accesses after suspend is called

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

Re: [PATCH 1/2] i2c: sprd: Prevent i2c accesses after suspend is called

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