From: "Janusz Użycki" <j.uzycki@elproma.com.pl>
To: Richard Genoud <richard.genoud@gmail.com>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
linux-serial@vger.kernel.org, devicetree@vger.kernel.org,
linux-arm-kernel@lists.infradead.org,
Fabio Estevam <festevam@gmail.com>
Subject: Re: [PATCH 1/4] serial: mxs-auart: use mctrl_gpio helpers for handling modem signals (v2.2c)
Date: Fri, 26 Sep 2014 14:59:18 +0200 [thread overview]
Message-ID: <54256326.3080202@elproma.com.pl> (raw)
In-Reply-To: <1411150399-30902-1-git-send-email-j.uzycki@elproma.com.pl>
W dniu 2014-09-25 17:29, Richard Genoud pisze:
> 2014-09-20 10:08 GMT+02:00 Janusz Użycki <j.uzycki@elproma.com.pl>:
> Hi,
Hi Richard,
first, thanks for the very useful answers.
>> Could you look on my patch series [1...4]
>> serial: mxs-auart:
>> use mctrl_gpio helpers for handling modem signals (v2.2c)
>> at http://news.gmane.org/gmane.linux.serial ?
> If you resend them, put me in the CC list.
> That will be easier for me to have a look at them.
sure
>> I added some comments in patch's code.
>> In atmel_serial mctrl_gpio_free() is ommited,
>> is it useless?
> If you take a look at mctrl_gpio_init(), you'll see that all the
> allocations are done with devm_* functions.
> So that they are automatically deallocated when the module unloads.
> I still wrote mctrl_gpio_free() for some cases where we want to free
> memory without unloading the module.
>
> So you don't have to call mctrl_gpio_free() at the end of
> mxs_auart_probe() and mxs_auart_remove()
> (cf Documentation/serial/driver )
It is clear now, thanks.
>> Atmel_serial also does not parse modem
>> line status in mxs_auart_get_mctrl(),
>> 8250 driver does it. Which solution is ok?
> Well, in atmel_get_mctrl(), we have to retrieve the line status from
> the uart controller :
> that's done with :
> status = UART_GET_CSR(port);
> Then, for the lines controlled via GPIO, we are calling
> mctrl_gpio_get() that updates the mctrl flags with gpios states.
>
> It doesn't seems different from 8250.
But serial8250_get_mctrl() in 8250_core.c calls serial8250_modem_status()
which calls eg. uart_handle_cts_change() even if enable_ms() wasn't called.
This is the difference.
The serial8250_modem_status() is also called in the interrupt
and, what I don't understand, in serial8250_console_write().
>> Do you happen to know if tty layer
>> modifies mctrl between mxs_auart_get_mctrl(),
>> mxs_auart_set_mctrl() and mxs_auart_get_mctrl() again?
> I don't quite understand what you mean.
> The only way for the kernel to get line status (DCD, CTS,DSR,RI) is
> via get_mctrl.
> And the only way for the kernel to set line status
> (RTS,DTR,out1,out2,loop) is via set_mctrl.
Yes, but:
* mxs_auart_set_mctrl() in the mxs-auart stores the lastest mctrl
in private ctrl field
* the stored value is used to supply initial returned value
by mxs_auart_get_mctrl()
* uart_update_mctrl() in serial_core.c modifies only selected bits
in port->mctrl field - OK, input bits stay untouched
* uart_port_startup() in serial_code.c sets RTS and DTR
and zeroes others (also input bits)
* uart_set_termios() in serial_core.c modifies the bits too
* uart_suspend_port() in serial_core.c sets all mctrl bits to 0
It looks that mxs_auart_set_mctrl() doesn't have to store mctrl at all
because uart_tiocmget() in serial_core.c restores the output bits
from port->mctrl field. So the code is duplicated.
Do you agree?
P.S. It was even implemented in serial_core.c in 2.6.12.
best regards
Janusz
> best regards,
> Richard.
--
To unsubscribe from this list: send the line "unsubscribe linux-serial" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
WARNING: multiple messages have this Message-ID (diff)
From: j.uzycki@elproma.com.pl (Janusz Użycki)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH 1/4] serial: mxs-auart: use mctrl_gpio helpers for handling modem signals (v2.2c)
Date: Fri, 26 Sep 2014 14:59:18 +0200 [thread overview]
Message-ID: <54256326.3080202@elproma.com.pl> (raw)
In-Reply-To: <1411150399-30902-1-git-send-email-j.uzycki@elproma.com.pl>
W dniu 2014-09-25 17:29, Richard Genoud pisze:
> 2014-09-20 10:08 GMT+02:00 Janusz U?ycki <j.uzycki@elproma.com.pl>:
> Hi,
Hi Richard,
first, thanks for the very useful answers.
>> Could you look on my patch series [1...4]
>> serial: mxs-auart:
>> use mctrl_gpio helpers for handling modem signals (v2.2c)
>> at http://news.gmane.org/gmane.linux.serial ?
> If you resend them, put me in the CC list.
> That will be easier for me to have a look at them.
sure
>> I added some comments in patch's code.
>> In atmel_serial mctrl_gpio_free() is ommited,
>> is it useless?
> If you take a look at mctrl_gpio_init(), you'll see that all the
> allocations are done with devm_* functions.
> So that they are automatically deallocated when the module unloads.
> I still wrote mctrl_gpio_free() for some cases where we want to free
> memory without unloading the module.
>
> So you don't have to call mctrl_gpio_free() at the end of
> mxs_auart_probe() and mxs_auart_remove()
> (cf Documentation/serial/driver )
It is clear now, thanks.
>> Atmel_serial also does not parse modem
>> line status in mxs_auart_get_mctrl(),
>> 8250 driver does it. Which solution is ok?
> Well, in atmel_get_mctrl(), we have to retrieve the line status from
> the uart controller :
> that's done with :
> status = UART_GET_CSR(port);
> Then, for the lines controlled via GPIO, we are calling
> mctrl_gpio_get() that updates the mctrl flags with gpios states.
>
> It doesn't seems different from 8250.
But serial8250_get_mctrl() in 8250_core.c calls serial8250_modem_status()
which calls eg. uart_handle_cts_change() even if enable_ms() wasn't called.
This is the difference.
The serial8250_modem_status() is also called in the interrupt
and, what I don't understand, in serial8250_console_write().
>> Do you happen to know if tty layer
>> modifies mctrl between mxs_auart_get_mctrl(),
>> mxs_auart_set_mctrl() and mxs_auart_get_mctrl() again?
> I don't quite understand what you mean.
> The only way for the kernel to get line status (DCD, CTS,DSR,RI) is
> via get_mctrl.
> And the only way for the kernel to set line status
> (RTS,DTR,out1,out2,loop) is via set_mctrl.
Yes, but:
* mxs_auart_set_mctrl() in the mxs-auart stores the lastest mctrl
in private ctrl field
* the stored value is used to supply initial returned value
by mxs_auart_get_mctrl()
* uart_update_mctrl() in serial_core.c modifies only selected bits
in port->mctrl field - OK, input bits stay untouched
* uart_port_startup() in serial_code.c sets RTS and DTR
and zeroes others (also input bits)
* uart_set_termios() in serial_core.c modifies the bits too
* uart_suspend_port() in serial_core.c sets all mctrl bits to 0
It looks that mxs_auart_set_mctrl() doesn't have to store mctrl at all
because uart_tiocmget() in serial_core.c restores the output bits
from port->mctrl field. So the code is duplicated.
Do you agree?
P.S. It was even implemented in serial_core.c in 2.6.12.
best regards
Janusz
> best regards,
> Richard.
next prev parent reply other threads:[~2014-09-26 12:59 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-09-19 18:13 [PATCH 1/4] serial: mxs-auart: use mctrl_gpio helpers for handling modem signals (v2.2c) Janusz Uzycki
2014-09-19 18:13 ` Janusz Uzycki
2014-09-19 18:13 ` [PATCH 2/4] serial: mxs-auart: add interrupts for modem control lines Janusz Uzycki
2014-09-19 18:13 ` Janusz Uzycki
[not found] ` <1411150399-30902-1-git-send-email-j.uzycki-9tnw74Q4ehaHKKo6LODCOg@public.gmane.org>
2014-09-19 18:13 ` [PATCH 3/4] serial: mxs-auart: enable PPS support Janusz Uzycki
2014-09-19 18:13 ` Janusz Uzycki
2014-09-19 18:13 ` [PATCH 4/4] serial: mxs-auart: add sysrq support Janusz Uzycki
2014-09-19 18:13 ` Janusz Uzycki
2014-09-23 16:18 ` [PATCH 1/4] serial: mxs-auart: use mctrl_gpio helpers for handling modem signals (v2.2c) Janusz Użycki
2014-09-23 16:18 ` Janusz Użycki
2014-09-26 12:59 ` Janusz Użycki [this message]
2014-09-26 12:59 ` Janusz Użycki
2014-09-26 13:11 ` Russell King - ARM Linux
2014-09-26 13:11 ` Russell King - ARM Linux
2014-09-26 13:23 ` Janusz Użycki
2014-09-26 13:23 ` Janusz Użycki
-- strict thread matches above, loose matches on Subject: below --
2014-09-19 18:08 Janusz Uzycki
2014-09-19 18:13 ` Janusz Użycki
2014-09-19 18:06 Janusz Uzycki
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=54256326.3080202@elproma.com.pl \
--to=j.uzycki@elproma.com.pl \
--cc=devicetree@vger.kernel.org \
--cc=festevam@gmail.com \
--cc=gregkh@linuxfoundation.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-serial@vger.kernel.org \
--cc=richard.genoud@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.