All of lore.kernel.org
 help / color / mirror / Atom feed
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.

  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.