[PATCH tty-next v2 0/4] Device Tree probing for bcm63xx_uart

[PATCH tty-next v2 0/4] Device Tree probing for bcm63xx_uart

[Florian Fainelli]

Hi Greg,

This patchset make the bcm63xx_uart architecture agnostic such that it can be
built on something else than MIPS now. Finally it adds support for Device Tree
probing to the driver along with a DT binding documentation.

I would appreciate if this could go via your tree for consistency.

Thanks!

Florian Fainelli (4):
  tty: serial: bcm63xx_uart: include linux/io.h
  tty: serial: bcm63xx_uart: define UART_REG_SIZE constant
  tty: serial: bcm63xx_uart: add support for DT probing
  Documentation: devicetree: add bindings documentation for bcm63xx-uart

 .../devicetree/bindings/serial/bcm63xx-uart.txt    | 27 ++++++++++++++++++++++
 drivers/tty/serial/bcm63xx_uart.c                  | 16 +++++++++++--
 include/linux/serial_bcm63xx.h                     |  2 ++
 3 files changed, 43 insertions(+), 2 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/serial/bcm63xx-uart.txt

-- 
1.8.3.2

[PATCH tty-next v2 1/4] tty: serial: bcm63xx_uart: include linux/io.h

[Florian Fainelli]

Include linux/io.h which provides the definition for
__raw_{readl,writel}, this is not necessary on MIPS since there is an
implicit inclusion, but it is on ARM for instance.

Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
---
Changes in v2:
- respin

 drivers/tty/serial/bcm63xx_uart.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/tty/serial/bcm63xx_uart.c b/drivers/tty/serial/bcm63xx_uart.c
index 78e82b0..d71143e 100644
--- a/drivers/tty/serial/bcm63xx_uart.c
+++ b/drivers/tty/serial/bcm63xx_uart.c
@@ -30,6 +30,7 @@
 #include <linux/serial.h>
 #include <linux/serial_core.h>
 #include <linux/serial_bcm63xx.h>
+#include <linux/io.h>
 
 #define BCM63XX_NR_UARTS	2
 
-- 
1.8.3.2

[PATCH tty-next v2 2/4] tty: serial: bcm63xx_uart: define UART_REG_SIZE constant

[Florian Fainelli]

The bcm63xx_uart driver uses RSET_UART_SIZE which is a constant defined
for MIPS-based BCM63xx platforms, pull this constant value from the
MIPS-specific header and put it in include/linux/serial_bcm63xx.h to
make the driver platform agnostic.

Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
---
Changes in v2:
- respin

 drivers/tty/serial/bcm63xx_uart.c | 4 ++--
 include/linux/serial_bcm63xx.h    | 2 ++
 2 files changed, 4 insertions(+), 2 deletions(-)

diff --git a/drivers/tty/serial/bcm63xx_uart.c b/drivers/tty/serial/bcm63xx_uart.c
index d71143e..37e7e33 100644
--- a/drivers/tty/serial/bcm63xx_uart.c
+++ b/drivers/tty/serial/bcm63xx_uart.c
@@ -589,7 +589,7 @@ static int bcm_uart_request_port(struct uart_port *port)
 {
 	unsigned int size;
 
-	size = RSET_UART_SIZE;
+	size = UART_REG_SIZE;
 	if (!request_mem_region(port->mapbase, size, "bcm63xx")) {
 		dev_err(port->dev, "Memory region busy\n");
 		return -EBUSY;
@@ -609,7 +609,7 @@ static int bcm_uart_request_port(struct uart_port *port)
  */
 static void bcm_uart_release_port(struct uart_port *port)
 {
-	release_mem_region(port->mapbase, RSET_UART_SIZE);
+	release_mem_region(port->mapbase, UART_REG_SIZE);
 	iounmap(port->membase);
 }
 
diff --git a/include/linux/serial_bcm63xx.h b/include/linux/serial_bcm63xx.h
index 570e964..a80aa1a 100644
--- a/include/linux/serial_bcm63xx.h
+++ b/include/linux/serial_bcm63xx.h
@@ -116,4 +116,6 @@
 					UART_FIFO_PARERR_MASK |		\
 					UART_FIFO_BRKDET_MASK)
 
+#define UART_REG_SIZE			24
+
 #endif /* _LINUX_SERIAL_BCM63XX_H */
-- 
1.8.3.2

[PATCH tty-next v2 3/4] tty: serial: bcm63xx_uart: add support for DT probing

[Florian Fainelli]

Add a matching table for the the bcm63xx_uart driver on the compatible
string "brcm,bcm6345-uart" which covers all BCM63xx implementations and
reflects the fact that this block was first introduced with the BCM6345
SoC.  Also make sure that we convert the id based on the uart aliases
provided by the relevant Device Tree.

Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
---
Changes in v2:
- match on the compatible property "brcm,bcm6345-uart" as suggested

 drivers/tty/serial/bcm63xx_uart.c | 11 +++++++++++
 1 file changed, 11 insertions(+)

diff --git a/drivers/tty/serial/bcm63xx_uart.c b/drivers/tty/serial/bcm63xx_uart.c
index 37e7e33..a47421e 100644
--- a/drivers/tty/serial/bcm63xx_uart.c
+++ b/drivers/tty/serial/bcm63xx_uart.c
@@ -31,6 +31,7 @@
 #include <linux/serial_core.h>
 #include <linux/serial_bcm63xx.h>
 #include <linux/io.h>
+#include <linux/of.h>
 
 #define BCM63XX_NR_UARTS	2
 
@@ -806,6 +807,9 @@ static int bcm_uart_probe(struct platform_device *pdev)
 	struct clk *clk;
 	int ret;
 
+	if (pdev->dev.of_node)
+		pdev->id = of_alias_get_id(pdev->dev.of_node, "uart");
+
 	if (pdev->id < 0 || pdev->id >= BCM63XX_NR_UARTS)
 		return -EINVAL;
 
@@ -857,6 +861,12 @@ static int bcm_uart_remove(struct platform_device *pdev)
 	return 0;
 }
 
+static const struct of_device_id bcm63xx_of_match[] = {
+	{ .compatible = "brcm,bcm6345-uart" },
+	{ /* sentinel */ }
+};
+MODULE_DEVICE_TABLE(of, bcm63xx_of_match);
+
 /*
  * platform driver stuff
  */
@@ -866,6 +876,7 @@ static struct platform_driver bcm_uart_platform_driver = {
 	.driver	= {
 		.owner = THIS_MODULE,
 		.name  = "bcm63xx_uart",
+		.of_match_table = bcm63xx_of_match,
 	},
 };
 
-- 
1.8.3.2

[PATCH tty-next v2 4/4] Documentation: devicetree: add bindings documentation for bcm63xx-uart

[Florian Fainelli]

Add the Device Tree binding documentation for the non-standard BCM63xx
UART hardware block found in the BCM63xx DSL SoCs.

Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
---
Changes in v2:
- update the compatible property to be "brcm,bcm6345-uart" as suggested
- reword the clocks and clock-names properties based on feedback from Mark

 .../devicetree/bindings/serial/bcm63xx-uart.txt    | 27 ++++++++++++++++++++++
 1 file changed, 27 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/serial/bcm63xx-uart.txt

diff --git a/Documentation/devicetree/bindings/serial/bcm63xx-uart.txt b/Documentation/devicetree/bindings/serial/bcm63xx-uart.txt
new file mode 100644
index 0000000..f288232
--- /dev/null
+++ b/Documentation/devicetree/bindings/serial/bcm63xx-uart.txt
@@ -0,0 +1,27 @@
+Broadcom BCM63xx UART: Non standard UART used in the Broadcom BCM63xx DSL SoCs
+
+Required properties:
+- compatible: must be "brcm,bcm6345-uart"
+- reg: offset and length of the register set for the device
+- interrupts: device interrupt
+- clocks: a list of phandles and clock-specifiers, one for each entry
+  in clock-names
+- clock-names: should contain "periph" for the functional clock
+
+Example:
+
+serial0: uart@600 {
+	compatible = "brcm,bcm6345-uart";
+	reg = <0x600 0x1b>;
+	interrupts = <GIC_SPI 32 0>;
+	clocks = <&periph_clk>;
+	clock-names = "periph";
+};
+
+Note: each UART port must have an alias correctly numbered in the "aliases"
+node, e.g:
+
+aliases {
+	uart0 = &serial0;
+	uart1 = &serial1;
+};
-- 
1.8.3.2

Re: [PATCH tty-next v2 4/4] Documentation: devicetree: add bindings documentation for bcm63xx-uart

[Mark Rutland]

On Thu, Feb 20, 2014 at 06:15:54PM +0000, Florian Fainelli wrote:
> Add the Device Tree binding documentation for the non-standard BCM63xx
> UART hardware block found in the BCM63xx DSL SoCs.
> 
> Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>

This looks fine to me.

Acked-by: Mark Rutland <mark.rutland@arm.com>

> ---
> Changes in v2:
> - update the compatible property to be "brcm,bcm6345-uart" as suggested
> - reword the clocks and clock-names properties based on feedback from Mark
> 
>  .../devicetree/bindings/serial/bcm63xx-uart.txt    | 27 ++++++++++++++++++++++
>  1 file changed, 27 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/serial/bcm63xx-uart.txt
> 
> diff --git a/Documentation/devicetree/bindings/serial/bcm63xx-uart.txt b/Documentation/devicetree/bindings/serial/bcm63xx-uart.txt
> new file mode 100644
> index 0000000..f288232
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/serial/bcm63xx-uart.txt
> @@ -0,0 +1,27 @@
> +Broadcom BCM63xx UART: Non standard UART used in the Broadcom BCM63xx DSL SoCs
> +
> +Required properties:
> +- compatible: must be "brcm,bcm6345-uart"
> +- reg: offset and length of the register set for the device
> +- interrupts: device interrupt
> +- clocks: a list of phandles and clock-specifiers, one for each entry
> +  in clock-names
> +- clock-names: should contain "periph" for the functional clock
> +
> +Example:
> +
> +serial0: uart@600 {
> +	compatible = "brcm,bcm6345-uart";
> +	reg = <0x600 0x1b>;
> +	interrupts = <GIC_SPI 32 0>;
> +	clocks = <&periph_clk>;
> +	clock-names = "periph";
> +};
> +
> +Note: each UART port must have an alias correctly numbered in the "aliases"
> +node, e.g:
> +
> +aliases {
> +	uart0 = &serial0;
> +	uart1 = &serial1;
> +};
> -- 
> 1.8.3.2
> 
> 

Re: [PATCH tty-next v2 4/4] Documentation: devicetree: add bindings documentation for bcm63xx-uart

[Arnd Bergmann]

Two more comments:

On Thursday 20 February 2014 10:15:54 Florian Fainelli wrote:
> +- clock-names: should contain "periph" for the functional clock

I think we should really start standardizing on the clock names more.
We don't have any uart that calls its functional clock "periph" so
far.

How about naming it "fclk" or "uart"?

I'd actually prefer making it an anonymous clock, but I know that
will just trigger comments about what might happen if it turns
out we need more than one clock for a future version of this device.

> +Example:
> +
> +serial0: uart@600 {
> +       compatible = "brcm,bcm6345-uart";
> +       reg = <0x600 0x1b>;
> +       interrupts = <GIC_SPI 32 0>;
> +       clocks = <&periph_clk>;
> +       clock-names = "periph";
> +};

The device name for a uart is "serial" by convention, not "uart",
so better make this serial@600.

	Arnd

Re: [PATCH tty-next v2 4/4] Documentation: devicetree: add bindings documentation for bcm63xx-uart

[Mark Rutland]

On Fri, Feb 21, 2014 at 12:49:05PM +0000, Arnd Bergmann wrote:
> Two more comments:
> 
> On Thursday 20 February 2014 10:15:54 Florian Fainelli wrote:
> > +- clock-names: should contain "periph" for the functional clock
> 
> I think we should really start standardizing on the clock names more.
> We don't have any uart that calls its functional clock "periph" so
> far.
> 
> How about naming it "fclk" or "uart"?
> 
> I'd actually prefer making it an anonymous clock, but I know that
> will just trigger comments about what might happen if it turns
> out we need more than one clock for a future version of this device.

Yup ;)

I'm happy as long as we have a well-defined name for each clock input,
regardless of what those particular names might be.

Mark.

Re: [PATCH tty-next v2 4/4] Documentation: devicetree: add bindings documentation for bcm63xx-uart

[Jonas Gorski]

On Fri, Feb 21, 2014 at 2:49 PM, Mark Rutland <mark.rutland@arm.com> wrote:
> On Fri, Feb 21, 2014 at 12:49:05PM +0000, Arnd Bergmann wrote:
>> Two more comments:
>>
>> On Thursday 20 February 2014 10:15:54 Florian Fainelli wrote:
>> > +- clock-names: should contain "periph" for the functional clock
>>
>> I think we should really start standardizing on the clock names more.
>> We don't have any uart that calls its functional clock "periph" so
>> far.
>>
>> How about naming it "fclk" or "uart"?
>>
>> I'd actually prefer making it an anonymous clock, but I know that
>> will just trigger comments about what might happen if it turns
>> out we need more than one clock for a future version of this device.
>
> Yup ;)
>
> I'm happy as long as we have a well-defined name for each clock input,
> regardless of what those particular names might be.

There already is a (non-OF) user for this driver that exports a
"periph" clock, which is where the name comes from. It currently does
all clock lookups purely based on the clock name, not the device name
itself. Of course we can just make it get a different named clock when
of_node is present; that should satisfy both.

Technically on BCM6345 there are actually two clocks (more or less),
the "periph" for the reference clock rate, and a clock bit in the
clock controller register for the uart block. All later chips do not
expose a uart clock bit anymore, and the bootloader is expected to
enable it on systems with the clock, so we can probably pretend that
it does not exist. Also it's quite unlikely that BCM6345 will ever
receive proper OF support, and if it does, we can add the second
optional clock then if we find devices that need it.



Regards
Jonas

Re: [PATCH tty-next v2 4/4] Documentation: devicetree: add bindings documentation for bcm63xx-uart

[Arnd Bergmann]

On Friday 21 February 2014 15:48:04 Jonas Gorski wrote:
> 
> There already is a (non-OF) user for this driver that exports a
> "periph" clock, which is where the name comes from. It currently does
> all clock lookups purely based on the clock name, not the device name
> itself. Of course we can just make it get a different named clock when
> of_node is present; that should satisfy both.

I think you are referring to arch/mips/bcm63xx/clk.c, but that doesn't
actually use clkdev at all and instead expects device drivers to know
the name of *output* of the clock controllers. You can't use that
name in the binding for a device, which needs to know the name of
the *input* from the clock consumer point of view.

An easy solution would be to register a clkdev lookup table in
the above clock driver.

> Technically on BCM6345 there are actually two clocks (more or less),
> the "periph" for the reference clock rate, and a clock bit in the
> clock controller register for the uart block. All later chips do not
> expose a uart clock bit anymore, and the bootloader is expected to
> enable it on systems with the clock, so we can probably pretend that
> it does not exist. Also it's quite unlikely that BCM6345 will ever
> receive proper OF support, and if it does, we can add the second
> optional clock then if we find devices that need it.

That seems fine, but it does mean things would get tricky we use
an anonymous clock and then later need to add the second clock
after all, e.g. if the uart gets reused in a new product that
requires you to program both clocks.

	Arnd

Re: [PATCH tty-next v2 4/4] Documentation: devicetree: add bindings documentation for bcm63xx-uart

[Jonas Gorski]

On Fri, Feb 21, 2014 at 3:59 PM, Arnd Bergmann <arnd@arndb.de> wrote:
> On Friday 21 February 2014 15:48:04 Jonas Gorski wrote:
>>
>> There already is a (non-OF) user for this driver that exports a
>> "periph" clock, which is where the name comes from. It currently does
>> all clock lookups purely based on the clock name, not the device name
>> itself. Of course we can just make it get a different named clock when
>> of_node is present; that should satisfy both.
>
> I think you are referring to arch/mips/bcm63xx/clk.c, but that doesn't
> actually use clkdev at all and instead expects device drivers to know
> the name of *output* of the clock controllers. You can't use that
> name in the binding for a device, which needs to know the name of
> the *input* from the clock consumer point of view.

That's why I was suggesting making the driver do a lookup on the input
name in case of probing through OF (having an of_node), and using
the "legacy" output name else. That way the binding is not limited to
the output name of bcm63xx/mips anymore.

> An easy solution would be to register a clkdev lookup table in
> the above clock driver.

Requiring bcm63xx/mips to implement clkdev would be IMHO an
unnecessary burden just so bcm63xx/arm using OF can reuse this driver.
Letting bcm63xx use a clkdev lookup table (or rather tables, as each
chip is different) is good mid or long term goal, but it should not
block other users.

>> Technically on BCM6345 there are actually two clocks (more or less),
>> the "periph" for the reference clock rate, and a clock bit in the
>> clock controller register for the uart block. All later chips do not
>> expose a uart clock bit anymore, and the bootloader is expected to
>> enable it on systems with the clock, so we can probably pretend that
>> it does not exist. Also it's quite unlikely that BCM6345 will ever
>> receive proper OF support, and if it does, we can add the second
>> optional clock then if we find devices that need it.
>
> That seems fine, but it does mean things would get tricky we use
> an anonymous clock and then later need to add the second clock
> after all, e.g. if the uart gets reused in a new product that
> requires you to program both clocks.

Right, so let's just not use an anonymous clock to begin with.


Regards
Jonas

Re: [PATCH tty-next v2 4/4] Documentation: devicetree: add bindings documentation for bcm63xx-uart

[Arnd Bergmann]

On Friday 21 February 2014 16:18:54 Jonas Gorski wrote:
> On Fri, Feb 21, 2014 at 3:59 PM, Arnd Bergmann <arnd@arndb.de> wrote:
> > On Friday 21 February 2014 15:48:04 Jonas Gorski wrote:
> >>
> >> There already is a (non-OF) user for this driver that exports a
> >> "periph" clock, which is where the name comes from. It currently does
> >> all clock lookups purely based on the clock name, not the device name
> >> itself. Of course we can just make it get a different named clock when
> >> of_node is present; that should satisfy both.
> >
> > I think you are referring to arch/mips/bcm63xx/clk.c, but that doesn't
> > actually use clkdev at all and instead expects device drivers to know
> > the name of *output* of the clock controllers. You can't use that
> > name in the binding for a device, which needs to know the name of
> > the *input* from the clock consumer point of view.
> 
> That's why I was suggesting making the driver do a lookup on the input
> name in case of probing through OF (having an of_node), and using
> the "legacy" output name else. That way the binding is not limited to
> the output name of bcm63xx/mips anymore.

Ok, fair enough.

> > An easy solution would be to register a clkdev lookup table in
> > the above clock driver.
> 
> Requiring bcm63xx/mips to implement clkdev would be IMHO an
> unnecessary burden just so bcm63xx/arm using OF can reuse this driver.
> Letting bcm63xx use a clkdev lookup table (or rather tables, as each
> chip is different) is good mid or long term goal, but it should not
> block other users.

Ah, that's probably right. I was assuming you'd only need to
add a single function call to register a table, but I see now
that using clkdev would impact the entire clk implementation
on bcm63xx.

	Arnd