| Message ID | 20170506121053.11554-1-linus.walleij@linaro.org |
|---|---|
| State | Superseded |
| Headers | show |
| Series | [1/4] ata: Add DT bindings for Faraday Technology FTIDE010 | expand |
Hi Linus On Sat, 6 May 2017, Linus Walleij wrote: > This adds device tree bindings for the Faraday Technology > FTIDE010 found in the Storlink/Storm/Cortina Systems Gemini SoC. > > I am not 100% sure that this part if from Faraday Technology but > a lot points in that direction: > > - A later IDE interface called FTIDE020 exist and share some > properties. > > - The SATA bridge has the same Built In Self Test (BIST) that the > Faraday FTSATA100 seems to have, and it has version number 0100 > in the device ID register, so this is very likely a FTSATA100 > bundled with the FTIDE010. > > Cc: devicetree@vger.kernel.org > Cc: John Feng-Hsin Chiang <john453@faraday-tech.com> > Cc: Greentime Hu <green.hu@gmail.com> > Signed-off-by: Linus Walleij <linus.walleij@linaro.org> nice work ! you can add my Acked-by: Hans Ulli Kroll <ulli.kroll@googlemail.com> on the whole patch set. -- 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
Hi, On Saturday, May 06, 2017 02:10:50 PM Linus Walleij wrote: > This adds device tree bindings for the Faraday Technology > FTIDE010 found in the Storlink/Storm/Cortina Systems Gemini SoC. > > I am not 100% sure that this part if from Faraday Technology but > a lot points in that direction: > > - A later IDE interface called FTIDE020 exist and share some > properties. > > - The SATA bridge has the same Built In Self Test (BIST) that the > Faraday FTSATA100 seems to have, and it has version number 0100 > in the device ID register, so this is very likely a FTSATA100 > bundled with the FTIDE010. > > Cc: devicetree@vger.kernel.org > Cc: John Feng-Hsin Chiang <john453@faraday-tech.com> > Cc: Greentime Hu <green.hu@gmail.com> > Signed-off-by: Linus Walleij <linus.walleij@linaro.org> > --- > Greentime: I think this may be interesting to you since the > FTIDE020 will need the same bindings so we can probably > just reuse them and maybe make the parser a library if you > want to upstream the FTIDE020. > > Faraday people: I do not have it from a source that this > hardware is really FTIDE010 but I would be VERY surprised > if it is not. U-Boot has an FTIDE020 IDE controller > synthesized in the Andestech platform, and it has a similar > yet different register layout, featuring similar timing > set-ups: > http://git.denx.de/?p=u-boot.git;a=blob;f=drivers/block/ftide020.h > http://git.denx.de/?p=u-boot.git;a=blob;f=drivers/block/ftide020.c > --- > .../devicetree/bindings/ata/faraday,ftide010.txt | 63 ++++++++++++++++++++++ > 1 file changed, 63 insertions(+) > create mode 100644 Documentation/devicetree/bindings/ata/faraday,ftide010.txt > > diff --git a/Documentation/devicetree/bindings/ata/faraday,ftide010.txt b/Documentation/devicetree/bindings/ata/faraday,ftide010.txt > new file mode 100644 > index 000000000000..5048408c07c5 > --- /dev/null > +++ b/Documentation/devicetree/bindings/ata/faraday,ftide010.txt > @@ -0,0 +1,63 @@ > +* Faraday Technology FTIDE010 PATA controller > + > +This controller is the first Faraday IDE interface block, used in the > +StorLink SL2312 and SL3516, later known as the Cortina Systems Gemini > +platform. The controller can do PIO modes 0 through 4, Multi-word DMA > +(MWDM)modes 0 through 2 and Ultra DMA modes 0 through 6. > + > +On the Gemini platform, this PATA block is accompanied by a PATA to > +SATA bridge in order to support SATA. This is why a phandle to that > +controller is compulsory on that platform. > + > +The timing properties are unique per-SoC, not per-board. > + > +Required properties: > +- compatible: should be one of > + "cortina,gemini-pata", "faraday,ftide010" > + "faraday,ftide010" > +- interrupts: interrupt for the block > +- reg: registers and size for the block > + > + The unit of the below required timings is two clock periods of the ATA > + reference clock which is 30 nanoseconds per unit at 66MHz and 20 nanoseconds > + per unit at 50 MHz. > + > +- faraday,pio-active-time: array of 5 elements for T2 timing for Mode 0, > + 1, 2, 3 and 4. Range 0..15. > +- faraday,pio-recovery-time: array of 5 elements for T2l timing for Mode 0, > + 1, 2, 3 and 4. Range 0..15. > +- faraday,mdma-50-active-time: array of 4 elements for Td timing for multi > + word DMA, Mode 0, 1, and 2 at 50 MHz. Range 0..15. > +- faraday,mdma-50-recovery-time: array of 4 elements for Tk timing for > + multi word DMA, Mode 0, 1 and 2 at 50 MHz. Range 0..15. > +- faraday,mdma-66-active-time: array of 4 elements for Td timing for multi > + word DMA, Mode 0, 1 and 2 at 50 MHz. Range 0..15. at 66 MHZ? > +- faraday,mdma-66-recovery-time: array of 4 elements for Tk timing for at 66 MHZ? > + multi word DMA, Mode 0, 1 and 2 at 50 MHz. Range 0..15. > +- faraday,udma-50-setup-time: array of 4 elements for Tvds timing for ultra > + DMA, Mode 0, 1, 2, 3, 4 and 5 at 50 MHz. Range 0..7. > +- faraday,udma-50-hold-time: array of 4 elements for Tdvh timing for > + multi word DMA, Mode 0, 1, 2, 3, 4 and 5 at 50 MHz, Range 0..7. > +- faraday,udma-66-setup-time: array of 4 elements for Tvds timing for multi > + word DMA, Mode 0, 1, 2, 3, 4, 5 and 6 at 50 MHz. Range 0..7. at 66 MHZ? > +- faraday,udma-66-hold-time: array of 4 elements for Tdvh timing for > + multi word DMA, Mode 0, 1, 2, 3, 4, 5 and 6 at 50 MHz. Range 0..7. at 66 MHZ? Also for all current drivers we just put timing values (or a logic to calculate them from the standard ATA timings) into the driver itself and not device tree (as they are based on values are dictated by ATA standard and should not change for a given controller type). > +Optional properties: > +- clocks: a SoC clock running the peripheral. > +- clock-names: should be set to "PCLK" for the peripheral clock. > + > +Required properties for "cortina,gemini-pata" compatible: > +- sata: a phande to the Gemini PATA to SATA bridge, see > + cortina,gemini-sata-bridge.txt for details. > + > +Example: > + > +ata@63000000 { > + compatible = "cortina,gemini-pata", "faraday,ftide010"; > + reg = <0x63000000 0x100>; > + interrupts = <4 IRQ_TYPE_EDGE_RISING>; > + clocks = <&gcc GEMINI_CLK_GATE_IDE>; > + clock-names = "PCLK"; > + sata = <&sata>; > +}; Best regards, -- Bartlomiej Zolnierkiewicz Samsung R&D Institute Poland Samsung Electronics -- 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 Mon, May 8, 2017 at 12:47 PM, Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com> wrote: > Also for all current drivers we just put timing values (or a logic > to calculate them from the standard ATA timings) into the driver > itself and not device tree (as they are based on values are dictated > by ATA standard and should not change for a given controller type). I had it like that at first (and I can of course switch it back). But I came to think this is better. I was looking at these values from the point that it depends a bit on the silicon where it is synthesized. So the vendor tree has things like this: #ifndef SL2312_FPGA_IDE static unsigned char PIO_TIMING[5] = { 0xaa, 0xa3, 0xa1, 0x33, 0x31 }; static unsigned char TIMING_MDMA_50M[3] = { 0x66, 0x22, 0x21 }; static unsigned char TIMING_MDMA_66M[3] = { 0x88, 0x32, 0x31 }; static unsigned char TIMING_UDMA_50M[6] = { 0x33, 0x31, 0x21, 0x21, 0x11, 0x91 }; static unsigned char TIMING_UDMA_66M[7] = { 0x44, 0x42, 0x31, 0x21, 0x11, 0x91, 0x91}; #else static unsigned char PIO_TIMING[5] = { 0x88, 0x82, 0x81, 0x32, 0x21 }; static unsigned char TIMING_MDMA_50M[3] = { 0x33, 0x11, 0x11 }; static unsigned char TIMING_MDMA_66M[3] = { 0x33, 0x11, 0x11 }; static unsigned char TIMING_UDMA_50M[6] = { 0x22, 0x11, 0x11, 0x11 }; static unsigned char TIMING_UDMA_66M[7] = { 0x22, 0x11, 0x11, 0x11 }; #endif (From D-Link DIR-685 source release from Storlink/Cortina board support.) So depending on whether they use an FPGA or an ASIC the values are different, no matter what frequency (50 or 66 MHz) is used. So it is not derived from frequency. So I think it makes most sense to have it in the device tree as we don't know what designs are out there. Yours, Linus Walleij -- 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 Monday, May 08, 2017 10:26:49 PM Linus Walleij wrote: > On Mon, May 8, 2017 at 12:47 PM, Bartlomiej Zolnierkiewicz > <b.zolnierkie@samsung.com> wrote: > > > Also for all current drivers we just put timing values (or a logic > > to calculate them from the standard ATA timings) into the driver > > itself and not device tree (as they are based on values are dictated > > by ATA standard and should not change for a given controller type). > > I had it like that at first (and I can of course switch it back). But I > came to think this is better. > > I was looking at these values from the point that it depends a bit > on the silicon where it is synthesized. So the vendor tree has > things like this: > > #ifndef SL2312_FPGA_IDE > static unsigned char PIO_TIMING[5] = { 0xaa, 0xa3, 0xa1, 0x33, 0x31 }; > static unsigned char TIMING_MDMA_50M[3] = { 0x66, 0x22, 0x21 }; > static unsigned char TIMING_MDMA_66M[3] = { 0x88, 0x32, 0x31 }; > static unsigned char TIMING_UDMA_50M[6] = { 0x33, 0x31, 0x21, 0x21, > 0x11, 0x91 }; > static unsigned char TIMING_UDMA_66M[7] = { 0x44, 0x42, 0x31, 0x21, > 0x11, 0x91, 0x91}; > #else > static unsigned char PIO_TIMING[5] = { 0x88, 0x82, 0x81, 0x32, 0x21 }; > static unsigned char TIMING_MDMA_50M[3] = { 0x33, 0x11, 0x11 }; > static unsigned char TIMING_MDMA_66M[3] = { 0x33, 0x11, 0x11 }; > static unsigned char TIMING_UDMA_50M[6] = { 0x22, 0x11, 0x11, 0x11 }; > static unsigned char TIMING_UDMA_66M[7] = { 0x22, 0x11, 0x11, 0x11 }; > #endif > > (From D-Link DIR-685 source release from Storlink/Cortina board support.) > > So depending on whether they use an FPGA or an ASIC the values are > different, no matter what frequency (50 or 66 MHz) is used. So it is not > derived from frequency. > > So I think it makes most sense to have it in the device tree as we don't > know what designs are out there. I still would prefer to keep timing values private to the driver and just select the controller type (FPGA/ASIC) using the device tree. Best regards, -- Bartlomiej Zolnierkiewicz Samsung R&D Institute Poland Samsung Electronics -- 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 Wed, May 10, 2017 at 3:59 PM, Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com> wrote: > On Monday, May 08, 2017 10:26:49 PM Linus Walleij wrote: >> On Mon, May 8, 2017 at 12:47 PM, Bartlomiej Zolnierkiewicz >> <b.zolnierkie@samsung.com> wrote: >> So depending on whether they use an FPGA or an ASIC the values are >> different, no matter what frequency (50 or 66 MHz) is used. So it is not >> derived from frequency. >> >> So I think it makes most sense to have it in the device tree as we don't >> know what designs are out there. > > I still would prefer to keep timing values private to the driver and just > select the controller type (FPGA/ASIC) using the device tree. OK I'll revert to static timings in the driver, no problem. Yours, Linus Walleij -- 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 Sat, May 06, 2017 at 02:10:50PM +0200, Linus Walleij wrote: > This adds device tree bindings for the Faraday Technology > FTIDE010 found in the Storlink/Storm/Cortina Systems Gemini SoC. > > I am not 100% sure that this part if from Faraday Technology but s/if/is/ > a lot points in that direction: > > - A later IDE interface called FTIDE020 exist and share some > properties. > > - The SATA bridge has the same Built In Self Test (BIST) that the > Faraday FTSATA100 seems to have, and it has version number 0100 > in the device ID register, so this is very likely a FTSATA100 > bundled with the FTIDE010. > > Cc: devicetree@vger.kernel.org > Cc: John Feng-Hsin Chiang <john453@faraday-tech.com> > Cc: Greentime Hu <green.hu@gmail.com> > Signed-off-by: Linus Walleij <linus.walleij@linaro.org> > --- > Greentime: I think this may be interesting to you since the > FTIDE020 will need the same bindings so we can probably > just reuse them and maybe make the parser a library if you > want to upstream the FTIDE020. > > Faraday people: I do not have it from a source that this > hardware is really FTIDE010 but I would be VERY surprised > if it is not. U-Boot has an FTIDE020 IDE controller > synthesized in the Andestech platform, and it has a similar > yet different register layout, featuring similar timing > set-ups: > http://git.denx.de/?p=u-boot.git;a=blob;f=drivers/block/ftide020.h > http://git.denx.de/?p=u-boot.git;a=blob;f=drivers/block/ftide020.c > --- > .../devicetree/bindings/ata/faraday,ftide010.txt | 63 ++++++++++++++++++++++ > 1 file changed, 63 insertions(+) > create mode 100644 Documentation/devicetree/bindings/ata/faraday,ftide010.txt Acked-by: Rob Herring <robh@kernel.org> -- 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/ata/faraday,ftide010.txt b/Documentation/devicetree/bindings/ata/faraday,ftide010.txt new file mode 100644 index 000000000000..5048408c07c5 --- /dev/null +++ b/Documentation/devicetree/bindings/ata/faraday,ftide010.txt @@ -0,0 +1,63 @@ +* Faraday Technology FTIDE010 PATA controller + +This controller is the first Faraday IDE interface block, used in the +StorLink SL2312 and SL3516, later known as the Cortina Systems Gemini +platform. The controller can do PIO modes 0 through 4, Multi-word DMA +(MWDM)modes 0 through 2 and Ultra DMA modes 0 through 6. + +On the Gemini platform, this PATA block is accompanied by a PATA to +SATA bridge in order to support SATA. This is why a phandle to that +controller is compulsory on that platform. + +The timing properties are unique per-SoC, not per-board. + +Required properties: +- compatible: should be one of + "cortina,gemini-pata", "faraday,ftide010" + "faraday,ftide010" +- interrupts: interrupt for the block +- reg: registers and size for the block + + The unit of the below required timings is two clock periods of the ATA + reference clock which is 30 nanoseconds per unit at 66MHz and 20 nanoseconds + per unit at 50 MHz. + +- faraday,pio-active-time: array of 5 elements for T2 timing for Mode 0, + 1, 2, 3 and 4. Range 0..15. +- faraday,pio-recovery-time: array of 5 elements for T2l timing for Mode 0, + 1, 2, 3 and 4. Range 0..15. +- faraday,mdma-50-active-time: array of 4 elements for Td timing for multi + word DMA, Mode 0, 1, and 2 at 50 MHz. Range 0..15. +- faraday,mdma-50-recovery-time: array of 4 elements for Tk timing for + multi word DMA, Mode 0, 1 and 2 at 50 MHz. Range 0..15. +- faraday,mdma-66-active-time: array of 4 elements for Td timing for multi + word DMA, Mode 0, 1 and 2 at 50 MHz. Range 0..15. +- faraday,mdma-66-recovery-time: array of 4 elements for Tk timing for + multi word DMA, Mode 0, 1 and 2 at 50 MHz. Range 0..15. +- faraday,udma-50-setup-time: array of 4 elements for Tvds timing for ultra + DMA, Mode 0, 1, 2, 3, 4 and 5 at 50 MHz. Range 0..7. +- faraday,udma-50-hold-time: array of 4 elements for Tdvh timing for + multi word DMA, Mode 0, 1, 2, 3, 4 and 5 at 50 MHz, Range 0..7. +- faraday,udma-66-setup-time: array of 4 elements for Tvds timing for multi + word DMA, Mode 0, 1, 2, 3, 4, 5 and 6 at 50 MHz. Range 0..7. +- faraday,udma-66-hold-time: array of 4 elements for Tdvh timing for + multi word DMA, Mode 0, 1, 2, 3, 4, 5 and 6 at 50 MHz. Range 0..7. + +Optional properties: +- clocks: a SoC clock running the peripheral. +- clock-names: should be set to "PCLK" for the peripheral clock. + +Required properties for "cortina,gemini-pata" compatible: +- sata: a phande to the Gemini PATA to SATA bridge, see + cortina,gemini-sata-bridge.txt for details. + +Example: + +ata@63000000 { + compatible = "cortina,gemini-pata", "faraday,ftide010"; + reg = <0x63000000 0x100>; + interrupts = <4 IRQ_TYPE_EDGE_RISING>; + clocks = <&gcc GEMINI_CLK_GATE_IDE>; + clock-names = "PCLK"; + sata = <&sata>; +};
This adds device tree bindings for the Faraday Technology FTIDE010 found in the Storlink/Storm/Cortina Systems Gemini SoC. I am not 100% sure that this part if from Faraday Technology but a lot points in that direction: - A later IDE interface called FTIDE020 exist and share some properties. - The SATA bridge has the same Built In Self Test (BIST) that the Faraday FTSATA100 seems to have, and it has version number 0100 in the device ID register, so this is very likely a FTSATA100 bundled with the FTIDE010. Cc: devicetree@vger.kernel.org Cc: John Feng-Hsin Chiang <john453@faraday-tech.com> Cc: Greentime Hu <green.hu@gmail.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org> --- Greentime: I think this may be interesting to you since the FTIDE020 will need the same bindings so we can probably just reuse them and maybe make the parser a library if you want to upstream the FTIDE020. Faraday people: I do not have it from a source that this hardware is really FTIDE010 but I would be VERY surprised if it is not. U-Boot has an FTIDE020 IDE controller synthesized in the Andestech platform, and it has a similar yet different register layout, featuring similar timing set-ups: http://git.denx.de/?p=u-boot.git;a=blob;f=drivers/block/ftide020.h http://git.denx.de/?p=u-boot.git;a=blob;f=drivers/block/ftide020.c --- .../devicetree/bindings/ata/faraday,ftide010.txt | 63 ++++++++++++++++++++++ 1 file changed, 63 insertions(+) create mode 100644 Documentation/devicetree/bindings/ata/faraday,ftide010.txt -- 2.9.3 -- 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