| Message ID | 1464380097-25125-3-git-send-email-kdasu.kdev@gmail.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
Hi Kamal, Comment inline. On 16-05-27 01:14 PM, Kamal Dasu wrote: > Adding qspi node compatible with the new spi-bcm-qspi > driver for the broadcom's northstar SoCwq. > > Signed-off-by: Kamal Dasu <kdasu.kdev@gmail.com> > Signed-off-by: Yendapally Reddy Dhananjaya Reddy <yendapally.reddy@broadcom.com> > --- > V2 no change > --- > arch/arm/boot/dts/bcm-nsp.dtsi | 29 +++++++++++++++++++++++++++++ > arch/arm/boot/dts/bcm958625k.dts | 34 ++++++++++++++++++++++++++++++++++ > 2 files changed, 63 insertions(+) > > diff --git a/arch/arm/boot/dts/bcm-nsp.dtsi b/arch/arm/boot/dts/bcm-nsp.dtsi > index def9e78..b3082b9 100644 > --- a/arch/arm/boot/dts/bcm-nsp.dtsi > +++ b/arch/arm/boot/dts/bcm-nsp.dtsi > @@ -206,6 +206,35 @@ > brcm,nand-has-wp; > }; > > + qspi: qspi@27200 { > + compatible = "brcm,spi-bcm-qspi"; > + reg = <0x027200 0x184>, > + <0x027000 0x124>, > + <0x11c408 0x004>, > + <0x0273a0 0x01c>; > + reg-names = "mspi", "bspi", "intr_regs", "intr_status_reg"; > + interrupts = <GIC_SPI 72 IRQ_TYPE_LEVEL_HIGH>, > + <GIC_SPI 73 IRQ_TYPE_LEVEL_HIGH>, > + <GIC_SPI 74 IRQ_TYPE_LEVEL_HIGH>, > + <GIC_SPI 75 IRQ_TYPE_LEVEL_HIGH>, > + <GIC_SPI 76 IRQ_TYPE_LEVEL_HIGH>, > + <GIC_SPI 77 IRQ_TYPE_LEVEL_HIGH>, > + <GIC_SPI 78 IRQ_TYPE_LEVEL_HIGH>; > + interrupt-names = "spi_lr_fullness_reached", > + "spi_lr_session_aborted", > + "spi_lr_impatient", > + "spi_lr_session_done", > + "spi_lr_overhead", > + "mspi_done", > + "mspi_halted"; > + clocks = <&iprocmed>; > + clock-names = "iprocmed"; > + clock-frequency = <12500000>; > + num-cs = <2>; > + #address-cells = <1>; > + #size-cells = <0>; > + }; > + > ccbtimer0: timer@34000 { > compatible = "arm,sp804"; > reg = <0x34000 0x1000>; > diff --git a/arch/arm/boot/dts/bcm958625k.dts b/arch/arm/boot/dts/bcm958625k.dts > index e298450..5aea779 100644 > --- a/arch/arm/boot/dts/bcm958625k.dts > +++ b/arch/arm/boot/dts/bcm958625k.dts > @@ -114,3 +114,37 @@ > groups = "nand_grp"; > }; > }; > + > +&qspi { > + bspi-sel = <0>; > + flash: m25p80@0 { > + #address-cells = <1>; > + #size-cells = <1>; > + compatible = "m25p80"; > + reg = <0x0>; > + spi-max-frequency = <12500000>; > + m25p,fast-read; > + spi-cpol; > + spi-cpha; > + > + partition@0 { > + label = "boot"; > + reg = <0x00000000 0x000a0000>; > + }; > + > + partition@1 { > + label = "env"; > + reg = <0x000a0000 0x00060000>; > + }; > + > + partition@2 { > + label = "system"; > + reg = <0x00100000 0x00600000>; > + }; > + > + partition@3 { > + label = "rootfs"; > + reg = <0x00700000 0x01900000>; > + }; The partitions are applications specific so should be passed on the boot command line rather than embedded in the dts file. > + }; > +}; > Regards, Scott -- To unsubscribe from this list: send the line "unsubscribe linux-spi" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Hi Florian, (HTML mail. What is this??) On Fri, May 27, 2016 at 01:33:20PM -0700, Florian Fainelli wrote: > On May 27, 2016 1:28 PM, "Scott Branden" > <[1]scott.branden@broadcom.com> wrote: > > >> +&qspi { > >> + bspi-sel = <0>; > >> + flash: m25p80@0 { > >> + #address-cells = <1>; > >> + #size-cells = <1>; > >> + compatible = "m25p80"; > >> + reg = <0x0>; > >> + spi-max-frequency = <12500000>; > >> + m25p,fast-read; > >> + spi-cpol; > >> + spi-cpha; > >> + > >> + partition@0 { > >> + label = "boot"; > >> + reg = <0x00000000 0x000a0000>; > >> + }; > >> + > >> + partition@1 { > >> + label = "env"; > >> + reg = <0x000a0000 0x00060000>; > >> + }; > >> + > >> + partition@2 { > >> + label = "system"; > >> + reg = <0x00100000 0x00600000>; > >> + }; > >> + > >> + partition@3 { > >> + label = "rootfs"; > >> + reg = <0x00700000 0x01900000>; > >> + }; > > > > > > The partitions are applications specific so should be passed on the > boot command line rather than embedded in the dts file. Scott kinda has a point; they can be application specific, and so in some cases, you might want to avoid putting this description in DT, at least if there are good alternatives. The command line may or may not be a good alternative (I don't think it's a very good one). > Partitions are typically part of the platform definition and are > suitable for being in Device Tree. AFAICT there is not a good way to > supply partitions in an OF configuration other than putting them in DT > at the moment. There is also a lot of platform inconsistency whether > the command line is appended, extended or overrides the command line in > the Device Tree, so I would not really consider this an issue here. My intention is to allow cmdline to take priority, so you could have application-specific overrides. If that doesn't work correctly, then I'd consider it a bug. I know that has irked some people (e.g., OpenWRT?), where they deal with products where they may not control the command line. But that's a separate issue IMO. You might want to take a look at supporting a partition parser, if this really is so application-specific. I had all the pieces working late last year: https://lkml.org/lkml/2015/12/5/9 but I unfortunately got distracted once the conversation on bindings derailed: https://lkml.org/lkml/2015/12/12/31 I should probably revive that... Anyway, if you utilize that, then you can specify which parser(s) are valid for your platform, rather than specifying the exact partition layout. Brian -- To unsubscribe from this list: send the line "unsubscribe linux-spi" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On 05/27/2016 01:47 PM, Brian Norris wrote: > Hi Florian, > > (HTML mail. What is this??) Made the mistake to reply with the Gmail application on my cellphone, does not look like they addressed my feature request ;) >> > The partitions are applications specific so should be passed on the >> boot command line rather than embedded in the dts file. > > Scott kinda has a point; they can be application specific, and so in > some cases, you might want to avoid putting this description in DT, at > least if there are good alternatives. The command line may or may not be > a good alternative (I don't think it's a very good one). Fair enough > >> Partitions are typically part of the platform definition and are >> suitable for being in Device Tree. AFAICT there is not a good way to >> supply partitions in an OF configuration other than putting them in DT >> at the moment. There is also a lot of platform inconsistency whether >> the command line is appended, extended or overrides the command line in >> the Device Tree, so I would not really consider this an issue here. > > My intention is to allow cmdline to take priority, so you could have > application-specific overrides. If that doesn't work correctly, then > I'd consider it a bug. I know that has irked some people (e.g., > OpenWRT?), where they deal with products where they may not control the > command line. But that's a separate issue IMO. I think this behavior makes sense, my problem is more with the fact that different architecture behave differently with respect to providing the command line to the kernel, some support taking the bootloader argument and merging it with the built-in/Device Tree bootargs command line, some do not, it's not always obvious. > > You might want to take a look at supporting a partition parser, if this > really is so application-specific. I had all the pieces working late > last year: > > https://lkml.org/lkml/2015/12/5/9 > > but I unfortunately got distracted once the conversation on bindings > derailed: > > https://lkml.org/lkml/2015/12/12/31 > > I should probably revive that... > > Anyway, if you utilize that, then you can specify which parser(s) are > valid for your platform, rather than specifying the exact partition > layout. /me goes reading, thanks!
diff --git a/arch/arm/boot/dts/bcm-nsp.dtsi b/arch/arm/boot/dts/bcm-nsp.dtsi index def9e78..b3082b9 100644 --- a/arch/arm/boot/dts/bcm-nsp.dtsi +++ b/arch/arm/boot/dts/bcm-nsp.dtsi @@ -206,6 +206,35 @@ brcm,nand-has-wp; }; + qspi: qspi@27200 { + compatible = "brcm,spi-bcm-qspi"; + reg = <0x027200 0x184>, + <0x027000 0x124>, + <0x11c408 0x004>, + <0x0273a0 0x01c>; + reg-names = "mspi", "bspi", "intr_regs", "intr_status_reg"; + interrupts = <GIC_SPI 72 IRQ_TYPE_LEVEL_HIGH>, + <GIC_SPI 73 IRQ_TYPE_LEVEL_HIGH>, + <GIC_SPI 74 IRQ_TYPE_LEVEL_HIGH>, + <GIC_SPI 75 IRQ_TYPE_LEVEL_HIGH>, + <GIC_SPI 76 IRQ_TYPE_LEVEL_HIGH>, + <GIC_SPI 77 IRQ_TYPE_LEVEL_HIGH>, + <GIC_SPI 78 IRQ_TYPE_LEVEL_HIGH>; + interrupt-names = "spi_lr_fullness_reached", + "spi_lr_session_aborted", + "spi_lr_impatient", + "spi_lr_session_done", + "spi_lr_overhead", + "mspi_done", + "mspi_halted"; + clocks = <&iprocmed>; + clock-names = "iprocmed"; + clock-frequency = <12500000>; + num-cs = <2>; + #address-cells = <1>; + #size-cells = <0>; + }; + ccbtimer0: timer@34000 { compatible = "arm,sp804"; reg = <0x34000 0x1000>; diff --git a/arch/arm/boot/dts/bcm958625k.dts b/arch/arm/boot/dts/bcm958625k.dts index e298450..5aea779 100644 --- a/arch/arm/boot/dts/bcm958625k.dts +++ b/arch/arm/boot/dts/bcm958625k.dts @@ -114,3 +114,37 @@ groups = "nand_grp"; }; }; + +&qspi { + bspi-sel = <0>; + flash: m25p80@0 { + #address-cells = <1>; + #size-cells = <1>; + compatible = "m25p80"; + reg = <0x0>; + spi-max-frequency = <12500000>; + m25p,fast-read; + spi-cpol; + spi-cpha; + + partition@0 { + label = "boot"; + reg = <0x00000000 0x000a0000>; + }; + + partition@1 { + label = "env"; + reg = <0x000a0000 0x00060000>; + }; + + partition@2 { + label = "system"; + reg = <0x00100000 0x00600000>; + }; + + partition@3 { + label = "rootfs"; + reg = <0x00700000 0x01900000>; + }; + }; +};