Hi,
On 16-11-15 18:01, Philipp Zabel wrote:
Am Montag, den 16.11.2015, 17:49 +0100 schrieb Hans de Goede:
Hi,
On 16-11-15 17:04, Chen-Yu Tsai wrote:
On Mon, Nov 16, 2015 at 11:42 PM, Alan Stern <st...@rowland.harvard.edu> wrote:
On Sun, 15 Nov 2015, Hans de Goede wrote:
From: Reinder de Haan <patches...@mveas.com>
At least the EHCI found on the Allwinnner H3 SoC needs multiple reset
lines, the controller will not initialize while the reset for its
companion OHCI is still asserted, which means we need to de-assert
2 reset-controllers for this EHCI controller to work.
I assume that reset_control_deassert() is smart enough to maintain a
count of de-assertions, and it doesn't actually turn on the reset line
until the count drops to 0. Right?
No it doesn't. That might be a problem when 2 devices (such as EHCI / OHCI
pairs) share a reset line, one probes successfully while the other doesn't.
Hans?
Ugh, good catch Alan, so I think the best way to solve this is to
actually make reset_control do a deassert / (re)assert count like
is done already for clocks, there is bound to be more hardware out there
which shares a reset line between 2 related blocks.
I'll whip up a patch for this, submit it and then we'll see.
If there are two devices sharing the same reset line that is initially
held asserted, do the two drivers somehow have to synchronize before
releasing the reset together?
Not to my knowledge, I suggest that we simply treat this same as
regulators / clocks where the first one to enable it actually gets
it enabled (de-asserted in case of a reset), and the last one
to disable (assert) it (so dropping the usage counter back to 0) leads
to it being asserted again.
This seems to work well enough for clocks / regulators and phys, and
at least for my use-case it should work fine for the shared reset too
(I will test to make sure of course).
So from my pov a simple counter should suffice, does that work for you ?
Regards,
Hans
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
