[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-ID: <20161021170438.GA4307@live.com>
Date: Fri, 21 Oct 2016 10:04:38 -0700
From: Moritz Fischer <moritz.fischer@...us.com>
To: iztok.jeras@...pitaya.com
Cc: p.zabel@...gutronix.de, linux-kernel@...r.kernel.org
Subject: Re: Reset implementation for Zynq
Iztok,
On Fri, Oct 21, 2016 at 03:08:47AM -0700, iztok.jeras@...pitaya.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
Powered by blists - more mailing lists