Uwe Kleine-König <u.kleine-koenig@xxxxxxxxxxxxxx> writes: > Hello, > > On Fri, May 31, 2019 at 06:23:48PM +0300, Sergey Organov wrote: >> Uwe Kleine-König <u.kleine-koenig@xxxxxxxxxxxxxx> writes: >> >> > Hello Sergey, >> > >> > On Fri, May 31, 2019 at 09:17:02AM +0300, Sergey Organov wrote: >> >> Uwe Kleine-König <u.kleine-koenig@xxxxxxxxxxxxxx> writes: >> >> >> >> > On Fri, May 31, 2019 at 07:52:51AM +0300, Sergey Organov wrote: >> >> >> My best reasoning was that DSR/ DTR is likely implemented the same as >> >> >> CTS/ RTS in the metal, and I found other drivers where both RTS and DSR >> >> >> are inverted, so I guessed it could be a remnant of old copy-paste. >> >> > >> >> > This is not a good enough reason to "fix" that. >> >> >> >> Yeah, I agree. I rather mostly kept it in the series not to forget about >> >> the issue. I should have said that in the comments, sorry. >> > >> > Then also sort this to the end of the series to allow clean application >> > of the patches you are sure about and mark the questionable patches as >> > RFC or RFT. >> >> I'm not sure we shouldn't actually fix it. Can we get help from NXP for >> clarification on the issue? I'm still 90% sure it's a bug. > > When the DTR bit is set the (TTL) output is one as the following command > sequence on an i.MX25 proves: > > # set SION bit for MX25_PAD_KPP_ROW0 and mux to UART1_DTR > bootloader: mw 0x43fac1a8 0x00000014 > > # configure GPIO2.29 as input > bootloader: gpio_direction_input 61 > > bootloader: md 0x43f90088+4 > 43f90088: 00000784 .... > > # DTR is set ... > > bootloader: gpio_get_value 61; echo $? > 1 > > # and the output is high > > # after unsetting DTR ... > bootloader: mw 0x43f90088 0x384 > bootloader: gpio_get_value 61; echo $? > 0 > > # ... the output is low. > > Together with TTL-level 0 meaning "active" the driver is right as is. > (Well, I'm not entirely sure about 0 == "active", so this is the point > you should target when continuing to argue :-) Nice, thanks a lot for checking! Is RTS "active" has the same TTL-level 0 for you? If (likely) so, it's not only the manual that is inconsistent, but the hardware as well, and then the patch rather should add bold comment to this piece of code, to document this consistent inconsistency ;-) -- Sergey
