Am Samstag, den 16.01.2016, 18:03 +0100 schrieb Martin Blumenstingl:
> On Sat, Jan 16, 2016 at 4:34 PM, Daniel Schwierzeck
> <daniel.schwierz...@gmail.com> wrote:
> > nice, thanks for testing :)
> Thanks for writing nice patches ;-)
>
> > > - replace INIT_COMPLECTION with reinit_completion (this is due
> > > the
> > > newer kernel version in OpenWrt)
> > > - use clk_get_fpi() to obtain the FPI clock (horrible, I am
> > > currently
> > > porting the lantiq clock code to the common clk framework, then
> > > we
> > > can
> > > pass this in correctly)
> > > - remove the " - 1" in "cs - 1" (it seems that your chipselect
> > > indexing in the .dts begins at 1, whereas the previous driver
> > > started
> > > at 0)
> >
> > I fixed that because datasheets and pin descriptions in schematics
> > use
> > CS1..CS6. I think DT should be in sync to the datasheets.
> I am not sure if this would work with GPIO chipselects then, see [0].
> If I understand it correctly then you would have to change the "reg"
> property of each device to "0" if you would use GPIO CS0 and then
> back
> to "1" if you want to use hardware CS0.
> Let me know if we should still go with chipselects starting at 1,
> then
> I will simply adjust them in the commit which switches to your new
> SPI
> driver.
If you use native CS, you should use the same numbering as in the
datasheet:
&spi {
...
spi-nor@4 {
#address-cells = <1>;
#size-cells = <1>;
compatible = "jedec,spi-nor";
reg = <4>;
spi-max-frequency = <25000000>;
};
};
If you use GPIO CS, you can ignore the native CS numbering and choose
your own and you can also start with 0:
&spi {
...
cs-gpios = <&gpio 10 1>;
spi-nor@0 {
#address-cells = <1>;
#size-cells = <1>;
compatible = "jedec,spi-nor";
reg = <0>;
spi-max-frequency = <25000000>;
};
};
If you use native CS 4, you have to manipulate bits 3 and 11 in the
GPOCON and FGPO registers. Thus you have to keep the (cs - 1)
translation.
>
> > linux-4.4 finally has the patch [1] I was referring to. Maybe we
> > should
> > also add it to 4.1. It is important to be able to setup each SPI
> > pin
> > separately. You always should explicitely setup spi_clk and spi_do
> > to
> > "lantiq,output = <1>" and spi_di to "lantiq,input". Depending on
> > the
> > board, you optionally have to enable internal pull-up's, if there
> > are
> > no external ones. The current DT pinmux setup with only one spi pin
> > group relies on the bootloader setup. This only works if the board
> > boots from SPI and the bootloader have to setup the SPI pins. With
> > other boot variants the SPI pins are likely not setup.
> I am assuming that you are speaking of upstream commit
> be14811c03cf20c793fd176a347625335110b0e6.
yes, sorry
> I went ahead and also backported that to 4.1, you can find the
> updated
> patchset here: [1]
>
> While reviewing my changes I may have found a small problem with your
> driver:
> You don't have a separate "lantiq,spi-xrx100" OF-match. I think you
> should add one with the same settings as for the other xrx-SoCs.
> If you look at DGN3500.dtsi [2] you'll see that it's an ARX100 board
> using spi_cs4.
that's because I couldn't test it. But according to the datasheet,
xRX100 also supports six native CS lines.
>
>
> Martin
>
> [0] https://www.kernel.org/doc/Documentation/devicetree/bindings/spi/
> spi-bus.txt
> [1] https://github.com/xdarklight/openwrt/commits/lantiq-spi-driver-d
> aniel-v3
> [2] https://dev.openwrt.org/browser/trunk/target/linux/lantiq/dts/DGN
> 3500.dtsi
--
- Daniel
_______________________________________________
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
