Hi Mario,
On 4 May 2018 at 01:01, Mario Six mario.six@gdsys.cc wrote:
Hi Neil,
On Fri, Apr 27, 2018 at 3:01 PM, Neil Armstrong narmstrong@baylibre.com
wrote:
Hi,
On 27/04/2018 14:53, Mario Six wrote:
Some reset lines are implemented by toggling the line via a GPIO.
Add a driver to properly drive such reset lines.
You are defining a "gpio-reset" binding which has always been rejected under Linux, so I'm not sure it's a good idea to add it in U-Boot only...
I see what you mean. I do think that the reasoning from the Linux debates
(e.g.
[1]) applies only partially to U-Boot, mostly because in U-Boot there is
no
good way to "have a separate device in the Linux driver model to abstract this". If it's not described in the DT, you have to manually create
devices,
which is probably not what we want here.
This driver was inspired by the also generic reset driver in [2] (which
was
never applied, it seems?) which is equally as "abstract" as this one.
At the end of the day, I'm fine with having a gpio-reset property in the
device
in question and then manually reset them, but I think we can do without
the
code duplication everywhere (plus, lots of boards already have U-Boot
specific
device tree include files, so adding the reset device is not a big deal).
Is "u-boot,gpio-reset" good as an alternative compat string?
I suppose so, but we should think about the implications. Presumably the controlling device would reference a particular reset line, and would control enabling/disabling reset, and thus the length of the reset pulse?
How much code do we actually save by doing this? Would another option be to have some helper functions in the reset uclass?
[1] http://comments.gmane.org/gmane.linux.drivers.devicetree/41596 [2] https://lists.denx.de/pipermail/u-boot/2017-November/313135.html
Neil
Regards, Simon