Patchwork [GIT,PULL] ARM: OMAP: I2C: prepare to use hwmod reset in driver

login
register
mail settings
Submitter Paul Walmsley
Date Dec. 16, 2011, 9:55 a.m.
Message ID <alpine.DEB.2.00.1112160254320.12660@utopia.booyaka.com>
Download mbox
Permalink /patch/131798/
State New
Headers show

Pull-request

git://git.pwsan.com/linux-2.6 i2c_reset_devel_3.3

Comments

Paul Walmsley - Dec. 16, 2011, 9:55 a.m.
Hi Tony

The following changes since commit dc47ce90c3a822cd7c9e9339fe4d5f61dcb26b50:

  Linux 3.2-rc5 (2011-12-09 15:09:32 -0800)

are available in the git repository at:
  git://git.pwsan.com/linux-2.6 i2c_reset_devel_3.3

Shubhrajyoti D (2):
      ARM: OMAP: omap_device: add omap_device_reset to reset all the hwmods in the device
      ARM: OMAP: I2C: Reset support

 arch/arm/plat-omap/i2c.c                      |    2 ++
 arch/arm/plat-omap/include/plat/omap_device.h |    1 +
 arch/arm/plat-omap/omap_device.c              |   22 ++++++++++++++++++++++
 include/linux/i2c-omap.h                      |    1 +
 4 files changed, 26 insertions(+), 0 deletions(-)
Tony Lindgren - Dec. 16, 2011, 7:50 p.m.
Hi,

* Paul Walmsley <paul@pwsan.com> [111216 01:24]:
> Hi Tony
> 
> The following changes since commit dc47ce90c3a822cd7c9e9339fe4d5f61dcb26b50:
> 
>   Linux 3.2-rc5 (2011-12-09 15:09:32 -0800)
> 
> are available in the git repository at:
>   git://git.pwsan.com/linux-2.6 i2c_reset_devel_3.3
> 
> Shubhrajyoti D (2):
>       ARM: OMAP: omap_device: add omap_device_reset to reset all the hwmods in the device
>       ARM: OMAP: I2C: Reset support
> 
>  arch/arm/plat-omap/i2c.c                      |    2 ++
>  arch/arm/plat-omap/include/plat/omap_device.h |    1 +
>  arch/arm/plat-omap/omap_device.c              |   22 ++++++++++++++++++++++
>  include/linux/i2c-omap.h                      |    1 +
>  4 files changed, 26 insertions(+), 0 deletions(-)

Can you please update shi to leave out the extra callback
function int (*device_reset) (struct device *dev) as I'd
rather see that happen with pm_runtime calls?

Regards,

Tony
Paul Walmsley - Dec. 16, 2011, 8:17 p.m.
Hi

On Fri, 16 Dec 2011, Tony Lindgren wrote:

> * Paul Walmsley <paul@pwsan.com> [111216 01:24]:
> > The following changes since commit dc47ce90c3a822cd7c9e9339fe4d5f61dcb26b50:
> > 
> >   Linux 3.2-rc5 (2011-12-09 15:09:32 -0800)
> > 
> > are available in the git repository at:
> >   git://git.pwsan.com/linux-2.6 i2c_reset_devel_3.3
> > 
> > Shubhrajyoti D (2):
> >       ARM: OMAP: omap_device: add omap_device_reset to reset all the hwmods in the device
> >       ARM: OMAP: I2C: Reset support
> > 
> >  arch/arm/plat-omap/i2c.c                      |    2 ++
> >  arch/arm/plat-omap/include/plat/omap_device.h |    1 +
> >  arch/arm/plat-omap/omap_device.c              |   22 ++++++++++++++++++++++
> >  include/linux/i2c-omap.h                      |    1 +
> >  4 files changed, 26 insertions(+), 0 deletions(-)
> 
> Can you please update shi to leave out the extra callback
> function int (*device_reset) (struct device *dev) as I'd
> rather see that happen with pm_runtime calls?

What PM runtime call is used to reset a device?


- Paul
Tony Lindgren - Dec. 16, 2011, 8:41 p.m.
* Paul Walmsley <paul@pwsan.com> [111216 11:45]:
> Hi
> 
> On Fri, 16 Dec 2011, Tony Lindgren wrote:
> 
> > * Paul Walmsley <paul@pwsan.com> [111216 01:24]:
> > > The following changes since commit dc47ce90c3a822cd7c9e9339fe4d5f61dcb26b50:
> > > 
> > >   Linux 3.2-rc5 (2011-12-09 15:09:32 -0800)
> > > 
> > > are available in the git repository at:
> > >   git://git.pwsan.com/linux-2.6 i2c_reset_devel_3.3
> > > 
> > > Shubhrajyoti D (2):
> > >       ARM: OMAP: omap_device: add omap_device_reset to reset all the hwmods in the device
> > >       ARM: OMAP: I2C: Reset support
> > > 
> > >  arch/arm/plat-omap/i2c.c                      |    2 ++
> > >  arch/arm/plat-omap/include/plat/omap_device.h |    1 +
> > >  arch/arm/plat-omap/omap_device.c              |   22 ++++++++++++++++++++++
> > >  include/linux/i2c-omap.h                      |    1 +
> > >  4 files changed, 26 insertions(+), 0 deletions(-)
> > 
> > Can you please update shi to leave out the extra callback
> > function int (*device_reset) (struct device *dev) as I'd
> > rather see that happen with pm_runtime calls?
> 
> What PM runtime call is used to reset a device?

Hmm how about pm_runtime_disable? Or do we need a new
call for reset?

Tony
Paul Walmsley - Dec. 16, 2011, 8:59 p.m.
Hi

On Fri, 16 Dec 2011, Tony Lindgren wrote:

> * Paul Walmsley <paul@pwsan.com> [111216 11:45]:
> > On Fri, 16 Dec 2011, Tony Lindgren wrote:
> > 
> > > * Paul Walmsley <paul@pwsan.com> [111216 01:24]:
> > >
> > > > Shubhrajyoti D (2):
> > > >       ARM: OMAP: omap_device: add omap_device_reset to reset all the hwmods in the device
> > > >       ARM: OMAP: I2C: Reset support
> > > > 
> > > Can you please update shi to leave out the extra callback
> > > function int (*device_reset) (struct device *dev) as I'd
> > > rather see that happen with pm_runtime calls?
> > 
> > What PM runtime call is used to reset a device?
> 
> Hmm how about pm_runtime_disable? Or do we need a new
> call for reset?

Looking at the last few hunks of:

http://marc.info/?l=linux-omap&m=132377389204328&w=2

it appears to me that the driver needs to reset the device while it's 
still active & powered on, etc.

Shubhrajyoti, care to comment further?


- Paul
Tony Lindgren - Dec. 17, 2011, 12:24 a.m.
* Paul Walmsley <paul@pwsan.com> [111216 12:27]:
> Hi
> 
> On Fri, 16 Dec 2011, Tony Lindgren wrote:
> 
> > * Paul Walmsley <paul@pwsan.com> [111216 11:45]:
> > > On Fri, 16 Dec 2011, Tony Lindgren wrote:
> > > 
> > > > * Paul Walmsley <paul@pwsan.com> [111216 01:24]:
> > > >
> > > > > Shubhrajyoti D (2):
> > > > >       ARM: OMAP: omap_device: add omap_device_reset to reset all the hwmods in the device
> > > > >       ARM: OMAP: I2C: Reset support
> > > > > 
> > > > Can you please update shi to leave out the extra callback
> > > > function int (*device_reset) (struct device *dev) as I'd
> > > > rather see that happen with pm_runtime calls?
> > > 
> > > What PM runtime call is used to reset a device?
> > 
> > Hmm how about pm_runtime_disable? Or do we need a new
> > call for reset?

Meanwhile as Paul pointed out, we still need the device_reset
pointer, so pulling in this series into i2c branch.
 
> Looking at the last few hunks of:
> 
> http://marc.info/?l=linux-omap&m=132377389204328&w=2
> 
> it appears to me that the driver needs to reset the device while it's 
> still active & powered on, etc.
> 
> Shubhrajyoti, care to comment further?
> 
> 
> - Paul
Datta, Shubhrajyoti - Dec. 18, 2011, 8:01 a.m.
On Saturday 17 December 2011 05:54 AM, Tony Lindgren wrote:
> * Paul Walmsley <paul@pwsan.com> [111216 12:27]:
>> Hi
>>
>> On Fri, 16 Dec 2011, Tony Lindgren wrote:
>>
>>> * Paul Walmsley <paul@pwsan.com> [111216 11:45]:
>>>> On Fri, 16 Dec 2011, Tony Lindgren wrote:
>>>>
>>>>> * Paul Walmsley <paul@pwsan.com> [111216 01:24]:
>>>>>
>>>>>> Shubhrajyoti D (2):
>>>>>>       ARM: OMAP: omap_device: add omap_device_reset to reset all the hwmods in the device
>>>>>>       ARM: OMAP: I2C: Reset support
>>>>>>
>>>>> Can you please update shi to leave out the extra callback
>>>>> function int (*device_reset) (struct device *dev) as I'd
>>>>> rather see that happen with pm_runtime calls?
>>>> What PM runtime call is used to reset a device?
>>> Hmm how about pm_runtime_disable? Or do we need a new
>>> call for reset?
> Meanwhile as Paul pointed out, we still need the device_reset
> pointer, so pulling in this series into i2c branch.
>  
>> Looking at the last few hunks of:
>>
>> http://marc.info/?l=linux-omap&m=132377389204328&w=2
>>
>> it appears to me that the driver needs to reset the device while it's 
>> still active & powered on, etc.
>>
>> Shubhrajyoti, care to comment further?
The driver does a reset in the error path.
Since we are not supposed to access the sysc reg the function is needed.
>>
>> - Paul
Cousson, Benoit - Dec. 19, 2011, 4:32 p.m.
Hi Shubhro,

On 12/18/2011 9:01 AM, Shubhrajyoti wrote:

[...]

> The driver does a reset in the error path.
> Since we are not supposed to access the sysc reg the function is needed.

I'm just wondering what will happen to the driver if this callback is 
not provided during the device creation? This is what will happen during 
DT boot for example?

Is it a mandatory function?

Thanks,
Benoit
Datta, Shubhrajyoti - Dec. 19, 2011, 5:37 p.m.
On Monday 19 December 2011 10:02 PM, Cousson, Benoit wrote:
> Hi Shubhro,
>
> On 12/18/2011 9:01 AM, Shubhrajyoti wrote:
>
> [...]
>
>> The driver does a reset in the error path.
>> Since we are not supposed to access the sysc reg the function is needed.
>
> I'm just wondering what will happen to the driver if this callback is
> not provided during the device creation? This is what will happen
> during DT boot for example?
>
> Is it a mandatory function?
This is used in the recovery mechanism in case of errors like some one
holding the bus and not releasing it etc.

>
> Thanks,
> Benoit