On Mon, 23 Mar 2015 18:17:36 -0400 (EDT), Jon Ringle wrote: > On Thu, 19 Mar 2015, Jon Ringle wrote: > > On Wed, 18 Mar 2015, Jakub Kicinski wrote: > > > > > From: Jakub Kicinski <kubakici@xxxxx> > > > > > > Users of RS-485 can request via ioctl that RTS signals should > > > be activated selected number of milliseconds before the actual > > > data transmission or stay active after the transmission is > > > finished. In sc16is7xx, however, RTS signalling is handled by > > > the hardware and driver has no way of providing this feature. > > > > > > Note: this change will make the driver return -EINVAL when the > > > feature is requested (.delay_rts_*_send are set). > > > > Makes sense. I removed the use of .delay_rts_before_send that my user app > > was setting and tested it and you are correct it. > > I am going to have to retract this. We have some modbus peripherals that > communicate poorly if data is sent from the controller (this driver) to > quickly after the RTS line switches states. Putting in a delay via > .delay_rts_befor_send helps these peripherals communicate much much better > reliability. Do you have an oscilloscope and care to debug this issue a bit further? I would love to do it myself by my electronics lab is very limited :( The point of this patch is that we cannot influence the RTS timing of sc16is7xx. That is to say: the delay introduced by the driver before this patch is purely blocking CPU and the chip from doing anything useful but does *not* make the RTS line stay high/low longer than without the delay. Unfortunately without a scope I cannot prove this or show you a signal trace. Now, the delay which I remove might be useful for your application but it should be equivalent to just putting delays inside the app itself. The way I understand .delay_rts_before_send API is that it's supposed to keep RTS high/low longer in case there are some delays in the hardware RX/TX path, while we can only achieve force the chip to be idle. My reading of the API may be wrong though, let's try to CC Claudio... IMHO if we implement in the driver what is basically an arbitrary delay it will confuse people who really need the *RTS line* to stay high/low as specified by the API. Moreover the mdelay inside a driver may work better but it's a sledgehammer approach. It is a terrible thing indeed considering that it blocks the entire system for milliseconds while holding spinlocks with irqs disabled! -- 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
