Hi,
On 18-11-15 11:38, Philipp Zabel wrote:
Am Mittwoch, den 18.11.2015, 21:20 +1100 schrieb Julian Calaby:
Hi All,
On Wed, Nov 18, 2015 at 9:18 PM, Maxime Ripard
<maxime.ripard@xxxxxxxxxxxxxxxxxx> wrote:
On Wed, Nov 18, 2015 at 10:46:52AM +0100, Philipp Zabel wrote:
Hi Hans,
Am Montag, den 16.11.2015, 18:13 +0100 schrieb Hans de Goede:
On 16-11-15 18:01, Philipp Zabel wrote:
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 ?
I don't quite understand what counting will help with, then. The first
driver to call reset_control_deassert will deassert the reset, whether
you count or not.
But if the two drivers have deasserted an initially asserted reset, a
reset_control_assert for one of them will silently fail.
Then maybe we can just make it return an error when someone calls
_assert or _reset on a reset line that has more than one user?
Just to set another cat amongst the pigeons: What if a driver needs to
toggle the shared reset line of some IP block to get it out of some
broken state?
We'd need driver support for that. Possibly using notifications?
In the hypothetical case of two GPUs sharing the same reset line, one
currently currently busy processing a command stream, and the other one
stuck, the driver for the stuck one would request a reset, the framework
would have to give notice to the other driver, allow it to veto or block
the reset until it has parked the hardware and stored state.
Right, see the proposal I've just sent which introduces a (light-weight)
concept of shared reset lines, and forbids calling reset_control_reset on
reset lines marked shared. This does not solve this case, but it makes
it clear this will not work. Then we can cross this theoretical bridge
if it ever becomes non theoretical.
Regards,
Hans
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
