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. regards Philipp -- 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
