diff mbox series

[1/4] ata: Add DT bindings for Faraday Technology FTIDE010

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

Commit Message

Linus Walleij May 6, 2017, 12:10 p.m. UTC
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

Comments

Hans Ulli Kroll May 7, 2017, 4:39 p.m. UTC | #1
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
Bartlomiej Zolnierkiewicz May 8, 2017, 10:47 a.m. UTC | #2
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
Linus Walleij May 8, 2017, 8:26 p.m. UTC | #3
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
Bartlomiej Zolnierkiewicz May 10, 2017, 1:59 p.m. UTC | #4
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
Linus Walleij May 10, 2017, 3:48 p.m. UTC | #5
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
Rob Herring (Arm) May 12, 2017, 3:24 p.m. UTC | #6
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 mbox series

Patch

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>;
+};