On Tue, Oct 13, 2015 at 03:43:20PM -0700, Ray Jui wrote:
>
>
> On 10/13/2015 2:38 PM, Jon Mason wrote:
> > On Sat, Oct 10, 2015 at 04:39:00PM +0200, Hauke Mehrtens wrote:
> >> On 10/03/2015 12:22 AM, Jon Mason wrote:
> >>> Add device tree files for Broadcom Northstar based SVKs. Since the
> >>> bcm5301x.dtsi already exists, all that is necessary is the dts files to
> >>> enable the UARTs (and specify the RAM size for the 4708/9). With these
> >>> files, the SVKs are able to boot to shell.
> >>>
> >>> Signed-off-by: Jon Mason <jonmason@xxxxxxxxxxxx>
> >>> ---
> >>> arch/arm/boot/dts/Makefile | 5 +++-
> >>> arch/arm/boot/dts/bcm94708.dts | 52 +++++++++++++++++++++++++++++++++++
> >>> arch/arm/boot/dts/bcm94709.dts | 52 +++++++++++++++++++++++++++++++++++
> >>> arch/arm/boot/dts/bcm953012k.dts | 59 ++++++++++++++++++++++++++++++++++++++++
> >>> 4 files changed, 167 insertions(+), 1 deletion(-)
> >>> create mode 100644 arch/arm/boot/dts/bcm94708.dts
> >>> create mode 100644 arch/arm/boot/dts/bcm94709.dts
> >>> create mode 100644 arch/arm/boot/dts/bcm953012k.dts
> >>>
>
> >>> +&uart0 {
> >>> + clock-frequency = <62499840>;
> >>
> >> Just out of curiosity on what does this clock frequency depend? I saw
> >> your patch adding a real clock driver which should make this obsolete.
> >
> > Better to add this now, as the device tree part might be out of sync
> > for a time.
>
> Sure, this can potentially be a reason to not using the real clock node
> and just use a hardcoded clock frequency for now, until the other clock
> change is merged, then you can submit another patch to use it.
>
> Also, is it not better to make the UARTs a static clock
> > and not dependent on the clk driver?
> >
>
> I disagree. You should always use the real clock driver for querying the
> clock frequency, in the case when the clock driver is available.
>
> Today one can change the core clock for UART in the bootloader for
> various reasons (and we saw that happening a lot in the past), which in
> this case will make your kernel not seeing any console output.
>
> By always querying the clock rate based on real registers instead of a
> hardcoded value, you don't have that issue and your kernel is less
> dependent on any changes in the bootloader.
Fair enough. This is moot until the clk driver changes get pulled in.
This file can be changed at that time :)
Thanks,
Jon
>
> > Thanks,
> > Jon
> >
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
