Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1506151 > unrolled thread

Re: Reset implementation for Zynq

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: Reset implementation for Zynq Moritz Fischer <moritz.fischer@ettus.com> - 2016-10-21 19:10 +0200
    Re: Reset implementation for Zynq Philipp Zabel <p.zabel@pengutronix.de> - 2016-10-24 11:10 +0200
      Re: Reset implementation for Zynq Moritz Fischer <moritz.fischer@ettus.com> - 2016-10-24 19:10 +0200

#1506151 — Re: Reset implementation for Zynq

Iztok,

On Fri, Oct 21, 2016 at 03:08:47AM -0700, iztok.jeras@redpitaya.com wrote:
> Hi Moritz,
>  
> I was looking at your reset implementation for Zynq:
> https://github.com/Xilinx/linux-xlnx/blob/629041605b93343ad2e8971ceaac3edcef0b043b/drivers/reset/reset-zynq.c
> I went through related mailing list posts (including earlier versions of the patch) so I kind of understand what to change in the device tree.

Please look at the upstream kernel sources and use the mailing list
(lkml) if you want to report bugs. Xilinx' vendor tree might or might
not be up to date.

> I would like to use this driver to reset the Zynq I2C controller, since we have trouble with it getting into a lock up state.
> I plan to use function device_reset_optional() from:
> https://github.com/Xilinx/linux-xlnx/blob/629041605b93343ad2e8971ceaac3edcef0b043b/include/linux/reset.h
>  
> But this function is calling the reset function pointer from the reset_control_ops structure.
> For the zynq driver this function pointer is not defined, only assert, deassert and status are.
>  
> Is this a missing implementation, or is there a default implementation (I did not find one) which which performs an assert+deassert,
> or is there another set of reset APIs I should use inside the kernel.

You could just call reset_control_assert() and reset_control_deassert().
You're right there is currently no implementation for the 'reset' function for
zynq (and most of the other SoCs). I'll need to see if it makes sense at
all.

Please note that you'd probably have to modify the i2c driver to
integrate reset functionality cleanly.

Thanks,

Moritz

[toc] | [next] | [standalone]

#1507012

Hi Iztok, Moritz,

Am Freitag, den 21.10.2016, 10:04 -0700 schrieb Moritz Fischer:
> Iztok,
> 
> On Fri, Oct 21, 2016 at 03:08:47AM -0700, iztok.jeras@redpitaya.com wrote:
> > Hi Moritz,
> >  
> > I was looking at your reset implementation for Zynq:
> > https://github.com/Xilinx/linux-xlnx/blob/629041605b93343ad2e8971ceaac3edcef0b043b/drivers/reset/reset-zynq.c
> > I went through related mailing list posts (including earlier versions of the patch) so I kind of understand what to change in the device tree.
> 
> Please look at the upstream kernel sources and use the mailing list
> (lkml) if you want to report bugs. Xilinx' vendor tree might or might
> not be up to date.
> 
> > I would like to use this driver to reset the Zynq I2C controller, since we have trouble with it getting into a lock up state.
> > I plan to use function device_reset_optional() from:
> > https://github.com/Xilinx/linux-xlnx/blob/629041605b93343ad2e8971ceaac3edcef0b043b/include/linux/reset.h
> >  
> > But this function is calling the reset function pointer from the reset_control_ops structure.
> > For the zynq driver this function pointer is not defined, only assert, deassert and status are.
> >  
> > Is this a missing implementation, or is there a default implementation (I did not find one) which which performs an assert+deassert,
> > or is there another set of reset APIs I should use inside the kernel.
> 
> You could just call reset_control_assert() and reset_control_deassert().
> You're right there is currently no implementation for the 'reset' function for
> zynq (and most of the other SoCs). I'll need to see if it makes sense at
> all.

The implementation of reset_control_reset in software really only makes
sense if the reset provider driver knows about the necessary delays for
all reset consumers.

> Please note that you'd probably have to modify the i2c driver to
> integrate reset functionality cleanly.
> 
> Thanks,
> 
> Moritz

regards
Philipp

[toc] | [prev] | [next] | [standalone]

#1507470

Philip,

On Mon, Oct 24, 2016 at 11:00:05AM +0200, Philipp Zabel wrote:
> Hi Iztok, Moritz,
> 
> Am Freitag, den 21.10.2016, 10:04 -0700 schrieb Moritz Fischer:
> > Iztok,
> > 
> > On Fri, Oct 21, 2016 at 03:08:47AM -0700, iztok.jeras@redpitaya.com wrote:
> > > Hi Moritz,
> > >  
> > > I was looking at your reset implementation for Zynq:
> > > https://github.com/Xilinx/linux-xlnx/blob/629041605b93343ad2e8971ceaac3edcef0b043b/drivers/reset/reset-zynq.c
> > > I went through related mailing list posts (including earlier versions of the patch) so I kind of understand what to change in the device tree.
> > 
> > Please look at the upstream kernel sources and use the mailing list
> > (lkml) if you want to report bugs. Xilinx' vendor tree might or might
> > not be up to date.
> > 
> > > I would like to use this driver to reset the Zynq I2C controller, since we have trouble with it getting into a lock up state.
> > > I plan to use function device_reset_optional() from:
> > > https://github.com/Xilinx/linux-xlnx/blob/629041605b93343ad2e8971ceaac3edcef0b043b/include/linux/reset.h
> > >  
> > > But this function is calling the reset function pointer from the reset_control_ops structure.
> > > For the zynq driver this function pointer is not defined, only assert, deassert and status are.
> > >  
> > > Is this a missing implementation, or is there a default implementation (I did not find one) which which performs an assert+deassert,
> > > or is there another set of reset APIs I should use inside the kernel.
> > 
> > You could just call reset_control_assert() and reset_control_deassert().
> > You're right there is currently no implementation for the 'reset' function for
> > zynq (and most of the other SoCs). I'll need to see if it makes sense at
> > all.
> 
> The implementation of reset_control_reset in software really only makes
> sense if the reset provider driver knows about the necessary delays for
> all reset consumers.

That's what I meant by needing to see if it makes sense at all; it makes
no sense to have a 'reset' if you don't know how long it needs to be
asserted for, since that's obviously a consumer property.

Thanks for clarifying,

Moritz

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web