On Wed, Aug 19, 2009 at 09:30:20AM -0400, Michael Barkowski wrote: > Anton Vorontsov wrote: > > On Tue, Aug 18, 2009 at 05:33:00PM -0500, Timur Tabi wrote: > >> Anton Vorontsov wrote: > >>> On Tue, Aug 18, 2009 at 05:20:44PM -0400, Michael Barkowski wrote: > >>>> This avoids having a short glitch if the desired initial value is not > >>>> the same as what was previously in the data register. > >>>> > >>>> Signed-off-by: Michael Barkowski <michaelbarkow...@ruggedcom.com> > >>> Acked-by: Anton Vorontsov <avoront...@ru.mvista.com> > >> I don't have the time to test this patch, so I abstain from acking. :-) > >> If Anton likes it, that's good enough for me. > > > > You made me doubt for a moment. :-) Thanks for the suspiciousness. > > > > What happens if a pin was previously configured as input? Does our > > write to the data register survive? For MPC8xxx GPIO controllers > > it does. And randomly taken QE spec says: > > > > A write to CPDAT is latched, and if the corresponding CPDIR > > bits have configured the port pin as an output, the latched > > value is driven onto the respective pin. However, if the > > corresponding CPDIR bits have configured the port pin as an > > input, the latched value is prevented from reaching the pin. > > > > I guess we're safe, but Michael, could you actually test it > > (if not already)? > > > > I had tested it before with the pin initially configured as "disabled". > > I have now also tested it with the pin initially configured as "input". > > The value written to CPDAT seems to survive and is driven onto the pin > once CPDIR is changed to 1, just as noted in the spec. > > Tested on 8360, by probing with a logic analyzer.
Great, thanks a lot! I think the patch is perfect. -- Anton Vorontsov email: cbouatmai...@gmail.com irc://irc.freenode.net/bd2 _______________________________________________ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
