Hi, On Wed, Mar 19, 2014 at 05:02:56PM +0000, Mark Jackson wrote: > >> Okay ... it comes back to me now. > >> > >> When using RS485 drivers, we're not actually using RTS as a "Ready > >> To Send", we're really using it as an "enable RS485 driver". > >> > >> I just used the "RTS" mnemonic as "we're now wanting to send some > >> data so please now enable the RS485 driver", rather than the normal > >> "I'm ready for your to send me some data". > >> > >> So it's the opposite function. > >> > >> Maybe it was a poor choice of abbreviation ? > >> > >> As I said before, RS485 drivers might have active or active low > >> enables, so we might need to invert the "RTS" polarity. This is > >> not handled by the hardware RTS signal. > >> > >> Is that a good enough explanation ? > > > > fair, but considering you can toggle RTS by hand with writes to MCR > > register, I still don't see the need for remuxing the lines as GPIOs. > > > > Just don't use auto-RTS and toggle the line by hand with MCR, no ? > > TBH I hadn't realised you could do that, so I guess you could. > > But my solution seems more flexible as it would allow you to add an RTS > signal to UART0 and UART5 which don't have any hardware handshaking lines. fair, but at least turn into helper functions part of serial core so that other serial drivers have a chance of reusing this. IMHO, it's a pretty ugly hack, but then again, a bunch of current in-kernel GPIO usage is, anyway. -- balbi
Attachment:
signature.asc
Description: Digital signature