Re: [OpenWrt-Devel] lantiq: Initial linux 4.4 support (with SPI problems)

2016-01-17 Thread Martin Blumenstingl 
On Sat, Jan 16, 2016 at 10:48 PM, Daniel Schwierzeck
 wrote:
> Am Samstag, den 16.01.2016, 21:17 +0100 schrieb Martin Blumenstingl:
>
>> So compared to your patch the final list of changes is:
>> - INIT_COMPLETION -> reinit_completion
>> - use clk_get_fpi()
>> - of_device_id for "lantiq,spi-xrx100"
>>
>> I only have three small questions left:
>> - The "spi_frm" interrupt is currently unused - is that on purpose?
>
> yes, this interrupt is only needed for DMA transfers.
ok, thanks!

>> - I went ahead and added multiple "compatible" strings to the
>> soc.dtsi, for example: compatible = "lantiq,spi-ase",
>> "lantiq,spi-xway"; - do you see any problems with that?
>
> there should be only one compatible string in the DTS. For backward
> compatibility the driver could support old and new strings.
I have fixed this, see below

>> Please let me know if you have more feedback - otherwise I'll do the
>> final round of tests and send the patches later.
>
> AFAIK the upstream preference is to have "lantiq,-spi". I forgot
> to fix that in the driver. Could you change that? Thanks.
The new of_device_id table is now:
 { .compatible = "lantiq,spi-xway", .data = _xway, }, /* DEPRECATED */
 { .compatible = "lantiq,ase-spi", .data = _xway, },
 { .compatible = "lantiq,xrx100-spi", .data = _xrx, },
 { .compatible = "lantiq,xrx200-spi", .data = _xrx, },
 { .compatible = "lantiq,xrx330-spi", .data = _xrx, },

This way we are still backwards compatible but have dedicated entries per SoC.
I could not find a danube device with SPI so I skipped that property for now.

While testing the changes I found that PCIe (and thus wifi) stopped
working on my TD-W8970. This was due to the backported pinctrl patches
which only add 50 pins for XRX200 instead of 56 (as before). That
changed the kernel-internal GPIO numbering, the first GPIO now starts
at 462. And since the PCIe driver used hardcoded GPIO numbers it broke
(because it failed to reset the PCIe device).
To make a long story short: I wrote a patch which fixes this - I'll
send the whole series in a few minutes.


Martin
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] lantiq: Initial linux 4.4 support (with SPI problems)

2016-01-16 Thread Martin Blumenstingl 
Hi Daniel,

On Sat, Jan 16, 2016 at 1:06 AM, Martin Blumenstingl
 wrote:
>> It is a complete rewrite with DT support and runs against the UGW-6.1.1
>> kernel. Unfortunately I hadn't time yet to adapt and test it with
>> OpenWRT. Maybe you want to volunteer for that ;)
> Thanks for this update! I am going to test it on kernel 4.1 in the
> next days and let you know about the results.
I had to make 3 adjustments to get it working on OpenWrt:
- 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)

After that everything is working nicely on linux 4.1 (on my TD-W8970):
[0.926597] spi-lantiq 1e100800.spi: using internal chipselect 3
[0.931499] spi-lantiq 1e100800.spi: spi_clk 12500,
max_speed_hz 3325, brt 2
[0.939351] m25p80 spi0.3: s25fl064k (8192 Kbytes)
[0.943763] 4 ofpart partitions found on MTD device spi0.3
[0.949192] Creating 4 MTD partitions on "spi0.3":
[0.953984] 0x-0x0002 : "u-boot"
[0.960136] 0x0002-0x007c : "firmware"
[0.966720] 0x001cf40c-0x007c : "rootfs"
[0.971380] mtd: device 2 (rootfs) set to be root filesystem
[0.976814] 1 squashfs-split partitions found on MTD device rootfs
[0.982126] 0x0046-0x007c : "rootfs_data"
[1.030051] 0x007c-0x007d : "config"
[1.034667] 0x007d-0x0080 : "boardconfig"
[1.040154] spi-lantiq 1e100800.spi: Lantiq SPI controller (TXFS 8,
RXFS 8, DMA 32)

I have pushed my changes to the OpenWrt tree here: [0]
My plan is to finish them soon (I want to do a little more testing,
and I need to verify that my other dts changes are correct).

Thank you for your help!


Regards,
Martin

[0] https://github.com/xdarklight/openwrt/commits/lantiq-spi-driver-daniel-v2
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] lantiq: Initial linux 4.4 support (with SPI problems)

2016-01-16 Thread Martin Blumenstingl 
On Sat, Jan 16, 2016 at 4:34 PM, Daniel Schwierzeck
 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.

> 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.
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.


Martin

[0] https://www.kernel.org/doc/Documentation/devicetree/bindings/spi/spi-bus.txt
[1] https://github.com/xdarklight/openwrt/commits/lantiq-spi-driver-daniel-v3
[2] https://dev.openwrt.org/browser/trunk/target/linux/lantiq/dts/DGN3500.dtsi
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] lantiq: Initial linux 4.4 support (with SPI problems)

2016-01-16 Thread Daniel Schwierzeck 
Am Samstag, den 16.01.2016, 18:03 +0100 schrieb Martin Blumenstingl:
> On Sat, Jan 16, 2016 at 4:34 PM, Daniel Schwierzeck
>  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-nor@4 {
#address-cells = <1>;
#size-cells = <1>;
compatible = "jedec,spi-nor";
reg = <4>;
spi-max-frequency = <2500>;
};
};

If you use GPIO CS, you can ignore the native CS numbering and choose
your own and you can also start with 0:

 {
...
cs-gpios = < 10 1>;

spi-nor@0 {
#address-cells = <1>;
#size-cells = <1>;
compatible = "jedec,spi-nor";
reg = <0>;
spi-max-frequency = <2500>;
};
};

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

Re: [OpenWrt-Devel] lantiq: Initial linux 4.4 support (with SPI problems)

2016-01-16 Thread Daniel Schwierzeck 
Am Samstag, den 16.01.2016, 15:39 +0100 schrieb Martin Blumenstingl:
> Hi Daniel,
> 
> On Sat, Jan 16, 2016 at 1:06 AM, Martin Blumenstingl
>  wrote:
> > > It is a complete rewrite with DT support and runs against the UGW
> > > -6.1.1
> > > kernel. Unfortunately I hadn't time yet to adapt and test it with
> > > OpenWRT. Maybe you want to volunteer for that ;)
> > Thanks for this update! I am going to test it on kernel 4.1 in the
> > next days and let you know about the results.
> I had to make 3 adjustments to get it working on OpenWrt:

nice, thanks for testing :)

> - 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.

> 
> After that everything is working nicely on linux 4.1 (on my TD
> -W8970):
> [0.926597] spi-lantiq 1e100800.spi: using internal chipselect 3
> [0.931499] spi-lantiq 1e100800.spi: spi_clk 12500,
> max_speed_hz 3325, brt 2
> [0.939351] m25p80 spi0.3: s25fl064k (8192 Kbytes)
> [0.943763] 4 ofpart partitions found on MTD device spi0.3
> [0.949192] Creating 4 MTD partitions on "spi0.3":
> [0.953984] 0x-0x0002 : "u-boot"
> [0.960136] 0x0002-0x007c : "firmware"
> [0.966720] 0x001cf40c-0x007c : "rootfs"
> [0.971380] mtd: device 2 (rootfs) set to be root filesystem
> [0.976814] 1 squashfs-split partitions found on MTD device rootfs
> [0.982126] 0x0046-0x007c : "rootfs_data"
> [1.030051] 0x007c-0x007d : "config"
> [1.034667] 0x007d-0x0080 : "boardconfig"
> [1.040154] spi-lantiq 1e100800.spi: Lantiq SPI controller (TXFS
> 8,
> RXFS 8, DMA 32)
> 
> I have pushed my changes to the OpenWrt tree here: [0]
> My plan is to finish them soon (I want to do a little more testing,
> and I need to verify that my other dts changes are correct).

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.

> 
> Thank you for your help!
> 
> 
> Regards,
> Martin
> 
> [0] https://github.com/xdarklight/openwrt/commits/lantiq-spi-driver-d
> aniel-v2
-- 
- Daniel
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] lantiq: Initial linux 4.4 support (with SPI problems)

2016-01-16 Thread Daniel Schwierzeck 
Am Samstag, den 16.01.2016, 21:17 +0100 schrieb Martin Blumenstingl:

> So compared to your patch the final list of changes is:
> - INIT_COMPLETION -> reinit_completion
> - use clk_get_fpi()
> - of_device_id for "lantiq,spi-xrx100"
> 
> I only have three small questions left:
> - The "spi_frm" interrupt is currently unused - is that on purpose?

yes, this interrupt is only needed for DMA transfers.

> - I went ahead and added multiple "compatible" strings to the
> soc.dtsi, for example: compatible = "lantiq,spi-ase",
> "lantiq,spi-xway"; - do you see any problems with that?

there should be only one compatible string in the DTS. For backward
compatibility the driver could support old and new strings.

> 
> Please let me know if you have more feedback - otherwise I'll do the
> final round of tests and send the patches later.

AFAIK the upstream preference is to have "lantiq,-spi". I forgot
to fix that in the driver. Could you change that? Thanks.

-- 
- Daniel
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] lantiq: Initial linux 4.4 support (with SPI problems)

2016-01-16 Thread Martin Blumenstingl 
On Sat, Jan 16, 2016 at 7:07 PM, Daniel Schwierzeck
 wrote:
> If you use native CS, you should use the same numbering as in the
> datasheet:
>
>  {
> ...
> spi-nor@4 {
> #address-cells = <1>;
> #size-cells = <1>;
> compatible = "jedec,spi-nor";
> reg = <4>;
> spi-max-frequency = <2500>;
> };
> };
>
> If you use GPIO CS, you can ignore the native CS numbering and choose
> your own and you can also start with 0:
>
>  {
> ...
> cs-gpios = < 10 1>;
>
> spi-nor@0 {
> #address-cells = <1>;
> #size-cells = <1>;
> compatible = "jedec,spi-nor";
> reg = <0>;
> spi-max-frequency = <2500>;
> };
> };
>
> 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.
Thanks for the explanation.
I think what confused me is that I thought of mixing GPIO-based CS and
HW CS. But as far as I can see that is not supported: either use GPIOs
or HW for CS.
Thus I went ahead and updated the board .dts to be +1 compared to
their old value and reverted my changes to your patch.

>> 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.
I added an of_device_id for "lantiq,spi-xrx100". Unfortunately I also
don't have xRX100 hardware which uses any SPI device, thus I can only
compile-test it.

So compared to your patch the final list of changes is:
- INIT_COMPLETION -> reinit_completion
- use clk_get_fpi()
- of_device_id for "lantiq,spi-xrx100"

I only have three small questions left:
- The "spi_frm" interrupt is currently unused - is that on purpose?
- I went ahead and added multiple "compatible" strings to the
soc.dtsi, for example: compatible = "lantiq,spi-ase",
"lantiq,spi-xway"; - do you see any problems with that?

Please let me know if you have more feedback - otherwise I'll do the
final round of tests and send the patches later.

PS: My git tree is contains the latest set of changes: [0]


Martin

[0] https://github.com/xdarklight/openwrt/commits/lantiq-spi-driver-daniel-v3
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] lantiq: Initial linux 4.4 support (with SPI problems)

2016-01-15 Thread Martin Blumenstingl 
Hi Daniel,

On Wed, Jan 13, 2016 at 9:05 PM, Daniel Schwierzeck
 wrote:
> could you retry with the attached driver?
>
> It is a complete rewrite with DT support and runs against the UGW-6.1.1
> kernel. Unfortunately I hadn't time yet to adapt and test it with
> OpenWRT. Maybe you want to volunteer for that ;)
Thanks for this update! I am going to test it on kernel 4.1 in the
next days and let you know about the results.

Do you have any plans for upstreaming this patch (assuming it works on 4.1/4.4)?
Do you also have any other patches prepared in your tree which we
should look into?


Martin
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] lantiq: Initial linux 4.4 support (with SPI problems)

2016-01-13 Thread Martin Blumenstingl 
Hi John,

On Mon, Jan 11, 2016 at 3:25 PM, Martin Blumenstingl
 wrote:
> Here's the kernel log from the TD-W8970: https://paste.kde.org/pia7p73i9
> I have debugged it and split_tplink_kernel gets 0x2 as offset and
> 0x7A as size (which looks correct). However, when mtd_read tries to
> read the magic bytes it only gets 0x.
I found out that reverting this upstream commit makes SPI work again: [0]

Then I had a deeper look at our SPI driver - that's where I need some
help from you.
Before the mentioned commit the call-graph for each spi_transfer
looked like this:
1) ltq_spi_setup_transfer(spi, transfer)
2) ltq_spi_chipselect(spi, BITBANG_CS_ACTIVE)
3) ndelay(100)
4) ltq_spi_txrx_bufs(spi, transfer)
5) ndelay(100)
6) ltq_spi_chipselect(spi, BITBANG_CS_INACTIVE)
7) ndelay(100)

After the mentioned commit the call-graph looks like this:
1) ltq_spi_chipselect(spi, BITBANG_CS_ACTIVE)
2) ltq_spi_setup_transfer(spi, transfer)
3) ltq_spi_txrx_bufs(spi, transfer)
4) ndelay(100)
5) ltq_spi_chipselect(spi, BITBANG_CS_INACTIVE)
6) ndelay(100)
7) ...more unrelated delays...
8) ndelay(100)
9) ltq_spi_chipselect(spi, BITBANG_CS_ACTIVE)
10) ndelay(100)

Currently ltq_spi_chipselect contains the code to leave configuration
mode and to set up the "per transfer" settings (like speed and "bits
per word") whenever it's called with BITBANG_CS_ACTIVE.
Once it's called with BITBANG_CS_INACTIVE it enters configuration mode again.
I first thought that I could simply solve this by moving the "per
transfer setup" from ltq_spi_chipselect to ltq_spi_setup_transfer (you
can find the patch here: [1]), but that resulted in broken SPI (even
with the the above commit reverted):
[0.930215] m25p80 spi32766.3: unrecognized JEDEC id bytes: ff, ff, ff

Do you still remember if there is anything special that has to be
taken care of when modifying the
bits_per_word/clockmode/speed/chipselect registers?
I compared our SPI driver to the SSC (Synchronous Serial Controller)
driver from UGW 5.4 (I don't have anything newer) but I could not find
anything related.


Martin


[0] 
https://github.com/torvalds/linux/commit/0037686596832572bbca05ab168d9884d7d704c1
[1] https://paste.kde.org/pbmykthnc
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] lantiq: Initial linux 4.4 support (with SPI problems)

2016-01-13 Thread Daniel Schwierzeck 
Hi Martin,

Am Mittwoch, den 13.01.2016, 20:23 +0100 schrieb Martin Blumenstingl:
> Hi John,
> 
> On Mon, Jan 11, 2016 at 3:25 PM, Martin Blumenstingl
>  wrote:
> > Here's the kernel log from the TD-W8970: 
> > https://paste.kde.org/pia7p73i9
> > I have debugged it and split_tplink_kernel gets 0x2 as offset
> > and
> > 0x7A as size (which looks correct). However, when mtd_read
> > tries to
> > read the magic bytes it only gets 0x.
> I found out that reverting this upstream commit makes SPI work again:
> [0]
> 
> Then I had a deeper look at our SPI driver - that's where I need some
> help from you.

could you retry with the attached driver? 

It is a complete rewrite with DT support and runs against the UGW-6.1.1
kernel. Unfortunately I hadn't time yet to adapt and test it with
OpenWRT. Maybe you want to volunteer for that ;)

The driver works on xRX200 with following DT bindings:

xrx200.dtsi:
fpi {
...
spi: spi@e100800 {
#address-cells = <1>;
#size-cells = <0>;
compatible = "lantiq,xrx200-spi";
reg = <0xe100800 0x100>;
interrupt-parent = <>;
interrupts = <22 23 24 25>;
interrupt-names = "spi_rx", "spi_tx", "spi_err",
"spi_frm";

status = "disabled";
};
...
};


board.dts:

 {
...
pins_spi_default: pins_spi_default {
spi_in {
lantiq,groups = "spi_din";
lantiq,function = "spi";
};
spi_out {
lantiq,groups = "spi_dout", "spi_clk",
"spi_cs4";
lantiq,function = "spi";
lantiq,output = <1>;
};
};
...
};

 {
pinctrl-names = "default";
pinctrl-0 = <_spi_default>;

status = "ok";

m25p80@4 {
#address-cells = <1>;
#size-cells = <1>;
compatible = "spansion,m25p80";
reg = <4>;
spi-max-frequency = <2500>;
};
};

-- 
- Daniel
>From 0175fc559debc22fe8d17e9b8ffd1452e0a4667d Mon Sep 17 00:00:00 2001
From: Daniel Schwierzeck 
Date: Tue, 16 Dec 2014 15:40:32 +0100
Subject: [PATCH 1/2] spi: add support for Lantiq SPI controller

Signed-off-by: Daniel Schwierzeck 
---
 drivers/spi/Kconfig  |7 +
 drivers/spi/Makefile |1 +
 drivers/spi/spi-lantiq.c | 1089 ++
 3 files changed, 1097 insertions(+)
 create mode 100644 drivers/spi/spi-lantiq.c

diff --git a/drivers/spi/Kconfig b/drivers/spi/Kconfig
index bc36db5..af8aaf1 100755
--- a/drivers/spi/Kconfig
+++ b/drivers/spi/Kconfig
@@ -266,6 +266,13 @@ config SPI_FSL_ESPI
 	  From MPC8536, 85xx platform uses the controller, and all P10xx,
 	  P20xx, P30xx,P40xx, P50xx uses this controller.
 
+config SPI_LANTIQ
+	tristate "Lantiq SPI controller"
+	depends on LANTIQ && (SOC_TYPE_XWAY || SOC_FALCON)
+	help
+	  This driver supports the Lantiq SPI controller in master
+	  mode.
+
 config SPI_OC_TINY
 	tristate "OpenCores tiny SPI"
 	depends on GPIOLIB
diff --git a/drivers/spi/Makefile b/drivers/spi/Makefile
index 658f181..f981db9 100755
--- a/drivers/spi/Makefile
+++ b/drivers/spi/Makefile
@@ -36,6 +36,7 @@ obj-$(CONFIG_SPI_FSL_SPI)		+= spi-fsl-spi.o
 obj-$(CONFIG_SPI_GPIO)			+= spi-gpio.o
 obj-$(CONFIG_SPI_GPIO_OLD)		+= spi_gpio_old.o
 obj-$(CONFIG_SPI_IMX)			+= spi-imx.o
+obj-$(CONFIG_SPI_LANTIQ)		+= spi-lantiq.o
 obj-$(CONFIG_SPI_LM70_LLP)		+= spi-lm70llp.o
 obj-$(CONFIG_SPI_MPC512x_PSC)		+= spi-mpc512x-psc.o
 obj-$(CONFIG_SPI_MPC52xx_PSC)		+= spi-mpc52xx-psc.o
diff --git a/drivers/spi/spi-lantiq.c b/drivers/spi/spi-lantiq.c
new file mode 100644
index 000..03c730d
--- /dev/null
+++ b/drivers/spi/spi-lantiq.c
@@ -0,0 +1,1089 @@
+/*
+ * Copyright (C) 2011-2015 Daniel Schwierzeck 
+ *
+ * This program is free software; you can distribute it and/or modify it
+ * under the terms of the GNU General Public License (Version 2) as
+ * published by the Free Software Foundation.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+
+#define SPI_RX_IRQ_NAME		"spi_rx"
+#define SPI_TX_IRQ_NAME		"spi_tx"
+#define SPI_ERR_IRQ_NAME	"spi_err"
+#define SPI_FRM_IRQ_NAME	"spi_frm"
+
+#define SPI_CLC			0x00
+#define SPI_PISEL		0x04
+#define SPI_ID			0x08
+#define SPI_CON			0x10
+#define SPI_STAT		0x14
+#define SPI_WHBSTATE		0x18
+#define SPI_TB			0x20
+#define SPI_RB			0x24
+#define SPI_RXFCON		0x30
+#define SPI_TXFCON		0x34
+#define SPI_FSTAT		0x38
+#define SPI_BRT			0x40
+#define SPI_BRSTAT		0x44
+#define SPI_SFCON		0x60
+#define SPI_SFSTAT		0x64
+#define

[OpenWrt-Devel] lantiq: Initial linux 4.4 support (with SPI problems)

2016-01-11 Thread Martin Blumenstingl 
Hello,

this series adds linux 4.4 support to the lantiq target.
It depends on the linux/generic 4.4.0 update because -rc8 contains a
build-fix for MIPS devices.

I have tested it on two (VRX200) devices:
- VGV7510KW22 (seems to work fine)
- TD-W8970 (the mtd_reads in mtd_split seem to only return 0x)

Here's the kernel log from the TD-W8970: https://paste.kde.org/pia7p73i9
I have debugged it and split_tplink_kernel gets 0x2 as offset and
0x7A as size (which looks correct). However, when mtd_read tries to
read the magic bytes it only gets 0x.

I'm happy for any suggestions what could be wrong here.


Regards,
Martin
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel