All of lore.kernel.org
 help / color / mirror / Atom feed
From: Arnd Bergmann <arnd@arndb.de>
To: "Uwe Kleine-König" <u.kleine-koenig@pengutronix.de>
Cc: linux-kernel@vger.kernel.org, Alan Cox <alan@linux.intel.com>,
	devicetree-discuss@lists.ozlabs.org,
	Greg Kroah-Hartman <gregkh@suse.de>,
	kernel@pengutronix.de, linux-serial@vger.kernel.org
Subject: Re: [PATCH] serial/efm32: add new driver
Date: Wed, 25 Jan 2012 16:56:55 +0000	[thread overview]
Message-ID: <201201251656.55514.arnd@arndb.de> (raw)
In-Reply-To: <20120109103458.GD14252@pengutronix.de>

On Monday 09 January 2012, Uwe Kleine-König wrote:
> On Fri, Dec 23, 2011 at 09:44:28PM +0100, Uwe Kleine-König wrote:
>  
> > > I would suggest that you also support the "clock-frequency" and/or
> > > "current-speed" properties that are defined for serial ports, see the
> > > of_serial driver.
> > I will have a look to find out what they mean and update the patch
> > accordingly.
> I took that look and I don't understand what they are good for in my
> case.
> clock-frequency is used to initialize port->uartclk (and helps setting
> up port->custom_divisor if current-speed is given). The driver I posted
> uses the clk API to determine the clock frequency. So shouldn't the frequency
> better be specified in the clk part of the dt? (I don't know yet how a
> dt binding for clks should/can look like, so this is a bit speculative,
> but I'd expect to have nothing more clk related in a device
> specification but a reference to a clk definition.)

The binding for 8250 serial ports is documented at
http://www.openfirmware.org/1275/bindings/devices/html/serial.html

If you can always use the clk API to find out the base clock rate,
that's probably fine, I was mostly trying to make sure we don't
introduce another duplicate API for this.

The "current-speed" property is used to describe the baud rate that
should be used by the kernel for this port in order to talk to
devices connected to the port. This is very useful if you need to
connect the boot console to a fixed-rate device, and would get
used instead of the 115200 default you have when nothing else
is configured on the command line. I don't really know why
there is no respective option to set parity or flow control

> Independant of my driver I wonder if defining current-speed should also
> result in
> 
> 	port->flags |= UPF_SPD_CUST;
> 
> (in of_platform_serial_setup()).

I believe that is not needed because you don't call uart_get_divisor,
which would be the only place that looks at this flag.

> Having said that and taking into account that my driver doesn't use
> port->custom_divisor, do you keep suggesting that I should use
> "clock-frequency" and/or "current-speed"?

clock-frequency seems to be unnecessary, but current-speed would
still make sense. custom_divisor is simply the method that of_serial
uses to communicate the bit rate to the 8250 base driver, but you
could set the divisor directly.

	Arnd
--
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: Arnd Bergmann <arnd@arndb.de>
To: "Uwe Kleine-König" <u.kleine-koenig@pengutronix.de>
Cc: linux-kernel@vger.kernel.org, Alan Cox <alan@linux.intel.com>,
	devicetree-discuss@lists.ozlabs.org,
	"Greg Kroah-Hartman" <gregkh@suse.de>,
	kernel@pengutronix.de, linux-serial@vger.kernel.org
Subject: Re: [PATCH] serial/efm32: add new driver
Date: Wed, 25 Jan 2012 16:56:55 +0000	[thread overview]
Message-ID: <201201251656.55514.arnd@arndb.de> (raw)
In-Reply-To: <20120109103458.GD14252@pengutronix.de>

On Monday 09 January 2012, Uwe Kleine-König wrote:
> On Fri, Dec 23, 2011 at 09:44:28PM +0100, Uwe Kleine-König wrote:
>  
> > > I would suggest that you also support the "clock-frequency" and/or
> > > "current-speed" properties that are defined for serial ports, see the
> > > of_serial driver.
> > I will have a look to find out what they mean and update the patch
> > accordingly.
> I took that look and I don't understand what they are good for in my
> case.
> clock-frequency is used to initialize port->uartclk (and helps setting
> up port->custom_divisor if current-speed is given). The driver I posted
> uses the clk API to determine the clock frequency. So shouldn't the frequency
> better be specified in the clk part of the dt? (I don't know yet how a
> dt binding for clks should/can look like, so this is a bit speculative,
> but I'd expect to have nothing more clk related in a device
> specification but a reference to a clk definition.)

The binding for 8250 serial ports is documented at
http://www.openfirmware.org/1275/bindings/devices/html/serial.html

If you can always use the clk API to find out the base clock rate,
that's probably fine, I was mostly trying to make sure we don't
introduce another duplicate API for this.

The "current-speed" property is used to describe the baud rate that
should be used by the kernel for this port in order to talk to
devices connected to the port. This is very useful if you need to
connect the boot console to a fixed-rate device, and would get
used instead of the 115200 default you have when nothing else
is configured on the command line. I don't really know why
there is no respective option to set parity or flow control

> Independant of my driver I wonder if defining current-speed should also
> result in
> 
> 	port->flags |= UPF_SPD_CUST;
> 
> (in of_platform_serial_setup()).

I believe that is not needed because you don't call uart_get_divisor,
which would be the only place that looks at this flag.

> Having said that and taking into account that my driver doesn't use
> port->custom_divisor, do you keep suggesting that I should use
> "clock-frequency" and/or "current-speed"?

clock-frequency seems to be unnecessary, but current-speed would
still make sense. custom_divisor is simply the method that of_serial
uses to communicate the bit rate to the 8250 base driver, but you
could set the divisor directly.

	Arnd

  reply	other threads:[~2012-01-25 16:57 UTC|newest]

Thread overview: 29+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-12-21 15:05 [PATCH] serial/efm32: add new driver Uwe Kleine-König
2011-12-21 15:05 ` Uwe Kleine-König
2011-12-21 20:28 ` Alan Cox
2011-12-21 20:28   ` Alan Cox
2011-12-22  8:57   ` Uwe Kleine-König
     [not found]   ` <20111221202847.4ffeba10-Z/y2cZnRghHXmaaqVzeoHQ@public.gmane.org>
2011-12-22 13:38     ` Uwe Kleine-König
2011-12-22 13:38       ` Uwe Kleine-König
2011-12-23 10:35       ` Arnd Bergmann
2011-12-23 10:35         ` Arnd Bergmann
2011-12-23 20:44         ` Uwe Kleine-König
     [not found]           ` <20111223204428.GI24496-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org>
2012-01-09  9:59             ` Kconfig option for compile time build coverage (Was: Re: [PATCH] serial/efm32: add new driver) Uwe Kleine-König
2012-01-09  9:59               ` Uwe Kleine-König
2012-01-25 16:16               ` Arnd Bergmann
2012-01-25 16:16                 ` Arnd Bergmann
2012-01-09 10:34           ` [PATCH] serial/efm32: add new driver Uwe Kleine-König
2012-01-25 16:56             ` Arnd Bergmann [this message]
2012-01-25 16:56               ` Arnd Bergmann
     [not found]       ` <1324561092-1945-1-git-send-email-u.kleine-koenig-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org>
2012-01-09 16:44         ` [PATCH v3] " Uwe Kleine-König
2012-01-09 16:44           ` Uwe Kleine-König
2012-01-24 22:05           ` Greg KH
2012-01-24 22:05             ` Greg KH
2012-01-25  8:05             ` [PATCH v4] " Uwe Kleine-König
2012-01-25  8:05               ` Uwe Kleine-König
2012-01-25  8:25               ` Joe Perches
2012-01-25  8:25                 ` Joe Perches
2012-01-25  8:41                 ` Uwe Kleine-König
2012-01-25 15:52               ` Greg KH
2012-01-25 18:36                 ` Uwe Kleine-König
2012-01-25 18:36                   ` Uwe Kleine-König

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=201201251656.55514.arnd@arndb.de \
    --to=arnd@arndb.de \
    --cc=alan@linux.intel.com \
    --cc=devicetree-discuss@lists.ozlabs.org \
    --cc=gregkh@suse.de \
    --cc=kernel@pengutronix.de \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-serial@vger.kernel.org \
    --cc=u.kleine-koenig@pengutronix.de \
    /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.