| Message ID | 1392920154-3642-5-git-send-email-f.fainelli@gmail.com |
|---|---|
| State | Superseded, archived |
| Headers | show |
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 > > -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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 -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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. -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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 -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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 -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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 -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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 -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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; +};
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