On 11/18/2015 02:49 PM, Matwey V. Kornilov wrote: > 2015-11-18 22:39 GMT+03:00 Matwey V. Kornilov <matwey@xxxxxxxxxx>: >> 2015-11-18 21:33 GMT+03:00 Peter Hurley <peter@xxxxxxxxxxxxxxxxxx>: >>> On 11/17/2015 03:20 AM, Matwey V. Kornilov wrote: >>>> 2015-11-16 22:18 GMT+03:00 Peter Hurley <peter@xxxxxxxxxxxxxxxxxx>: >>>>> On 11/14/2015 10:25 AM, One Thousand Gnomes wrote: [...] >>>>>> It's also not "easy to drop". If it ever goes in we are stuck with a >>>>>> pointless impossible to correctly set flag for all eternity. >>>>>> >>>>>> Please explain the correct setting for this flag when a device driver >>>>>> uses hardware or software or a mix according to what the silicon is >>>>>> capable of and what values are requested ? How will an application use the >>>>>> flag meaningfully. Please explain what will happen if someone discovers a >>>>>> silicon bug and in a future 4.x release turns an implementation from >>>>>> hardware to software - will they have to lie about the flag to avoid >>>>>> breaking their application code - that strikes me as a bad thing. >>>>> >>>>> The existing driver behavior is already significantly variant and needs >>>>> to be converged, which shouldn't be too difficult. Here's a quick summary: >>>>> >>>>> mcfuart ignores delay values, delays unsupported >>>>> imx clamps delay values to 0, delays unsupported >>>>> atmel only delay_rts_after_send used; delay_rts_before_send does nothing >>>>> 8250_fintek clamps delay values to 1, unclear if h/w delay is msecs >>>>> omap-serial* software emulation (but tx empty polling not reqd) >>>>> lpc18xx-uart clamps delay_rts_before_send to 0, unsupported >>>>> clamps delay_rts_after_send to max h/w value >>>>> max310x returns -ERANGE if either delay value > h/w support (15 msecs) >>>>> sc16is7xx* returns -EINVAL if delay_rts_after_send is set >>>>> crisv10* clamps delay_rts_before_send to 1000 msecs >>>>> ignores delays_rts_after_send (after dma is delayed by 2 * chars) >>>>> * implements delay(s) in software >>>>> >>>>> The omap-serial emulation should not have been merged in its current form. >>>>> >>>>> IMO the proper driver behavior should be clamp to h/w limit so an application >>>>> can determine the maximum delay supported. If a delay is unsupported, it should >>>>> be clamped to 0. The application should check the RS485 settings returned by >>>>> TIOCSRS485 to determine how the driver set them. >>>>> [ Documentation/serial/serial-rs485.txt should suggest/model this action ] >>>> >>>> But the similar could be true for minimal supported delay. If user >>>> requires delay which is less than lower bound, the delay is raised to >>>> the lower bound. If user requires delay which is greater than upper >>>> bound, the delay is set to the upper bound. Then software >>>> implementation could use (tx fifo size / baudrate) as lower bound for >>>> delay_after_send. >>> >>> From the application point-of-view (really the only relevant semantics), >>> delay_dts_after_send refers to the number of milliseconds to delay the >>> toggle of RTS after the last bit has been _transmitted_. Is there consensus then about what the semantics of unsupported RS485 delay values are? I (or someone else) can trivially add the documentation and fixes to the existing in-tree drivers. >>> A couple of possibilities for improving the emulation are: >>> 1) Optionally using an HR timer for sub-jiffy turnaround. >>> 2) Only supporting 8250-based hardware that can be set to interrupt when >>> both tx fifo and transmitter shift register are empty. >> >> This is to support the RS485 API with already exists in omap_serrial, >> but not in 8250_omap. And OMAP does not support tx line interrupt in >> UART mode. So the latter is not an option. > > Oh, I am sorry, it does support. There is "Supplementary Control > Register" described in 19.5.1.39 For the moment then, can we add a UART_CAP_SW485 (not exposed to userspace) that enables this algorithm only for h/w that supports a both-empty interrupt mode. The probe or driver (ala 8250_omap) would opt-in and configure the h/w much like the omap-serial driver does now (with the SCR register). Does that seem like an acceptable compromise? Regards, Peter Hurley PS - I still need to review this series for how the timer logic works esp. wrt teardown. -- To unsubscribe from this list: send the line "unsubscribe linux-serial" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
