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-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
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
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
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
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
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.
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] */
>
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
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
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
11 matches
Mail list logo
