Hello,
After testing the patch v8, I found two more glitches, which happen at
least in 4.1 kernel (I applied the changes to 8250_core.c, since
8250_port.c isn't made separate in 4.1):
1) When serial8250_em485_init is called from omap_8250_rs485_config,
there is a lockdep warning, and according to
Also, forgot to mention that if serial8250_em485_init is called not
upon uart startup but elsewhere (upon port register for example), and
em485 is set, serial8250_do_startup should call
serial8250_em485_rts_after_send, or else RTS might be in wrong state
whenever the port device is opened, making i
2016-02-18 10:18 GMT+03:00 Ильяс Гасанов :
> Also, forgot to mention that if serial8250_em485_init is called not
> upon uart startup but elsewhere (upon port register for example), and
> em485 is set, serial8250_do_startup should call
> serial8250_em485_rts_after_send, or else RTS
Hello,
2016-02-18 19:50 GMT+03:00 Peter Hurley :
> No, that's not the way.
>
> First, there's plenty of driver hooks to properly manage the RTS level
> for rs485.
For now I'm considering to add the check to uart_dtr_rts in
serial_core.c. However, given the access to struct
tty_port_operations, I
Hello,
2016-02-18 23:29 GMT+03:00 Matwey V. Kornilov :
> I am afraid non-ASCII will break something eventually. I think it
> would be better to ask Ilias to put his name in proper latin
> transcription here.
The most proper transcription I think is Ilyas Gasanov.
Regards,
Ilyas G.
Hello,
2016-01-16 2:55 GMT+03:00 Peter Hurley :
> Please use the helpers in serial_mctrl_gpio.c if you try this.
>
> And please build on top of Matwey's patches, as those will likely be
> the rs485 implementation for the 8250_omap driver soon.
As far as I understand, since em485 callbacks are inv
Hello,
2016-02-01 21:09 GMT+03:00 "Matwey V. Kornilov" :
> +static int omap_8250_rs485_config(struct uart_port *port,
> + struct serial_rs485 *rs485)
> +{
> + struct uart_8250_port *up = up_to_u8250p(port);
> +
> + /* Clamp the delays to [0, 100ms] */
>
2016-02-11 22:08 GMT+03:00 Matwey V. Kornilov :
> Thanks for pointing out. serial8250_unregister_port should set
> serial8250_ports[line].em485 to NULL in order to prevent unneeded
> activation when this struct is reused.
Then the allocated/initialized resources should be freed/released as well.
2016-02-12 10:57 GMT+03:00 Matwey V. Kornilov :
> up->em485 is always pointer, however you are right, that
> serial8250_em485_init stores pointer to up when the timers are inited.
> More complex issue here that serial8250_em485_init need to set RTS to
> proper state and probably can't do that befor
Hello.
We are upgrading to the 4.1.x kernel for our smart metering appliance
project, which is based on TI's Sitara hardware (AM335x SoC), and I
decided to switch from omap-serial legacy driver to the newer
8250-based one. It marginally increases throughput efficiency, CPU
cycle wise, among other
Hi Matwey,
2015-12-27 16:14 GMT+03:00 Matwey V. Kornilov :
> The half of what is described here are implemented in my patches.
> But I cannot understand the other half. Each of six AM335x UARTs has
> RTS/CTS pins which are controlled by pinmux in device tree, no magic
> required here.
The problem
11 matches
Mail list logo
