* Re: Race to power off harming SATA SSDs
From: Boris Brezillon @ 2017-05-08 11:55 UTC (permalink / raw)
To: Richard Weinberger
Cc: Pavel Machek, David Woodhouse, linux-scsi@vger.kernel.org,
Hans de Goede, LKML, linux-ide, linux-mtd@lists.infradead.org,
Henrique de Moraes Holschuh, Tejun Heo
In-Reply-To: <20170508134807.498b3ee7@bbrezillon>
On Mon, 8 May 2017 13:48:07 +0200
Boris Brezillon <boris.brezillon@free-electrons.com> wrote:
> On Mon, 8 May 2017 13:06:17 +0200
> Richard Weinberger <richard.weinberger@gmail.com> wrote:
>
> > On Mon, May 8, 2017 at 12:49 PM, Pavel Machek <pavel@ucw.cz> wrote:
> > > Aha, nice, so it looks like ubifs is a step back here.
> > >
> > > 'clean marker' is a good idea... empty pages have plenty of space.
> >
> > If UBI (not UBIFS) faces an empty block, it also re-erases it.
>
> Unfortunately, that's not the case, though UBI can easily be patched
> to do that (see below).
Sorry for the noise, I was wrong, UBI already re-erases empty blocks
[1].
[1]http://elixir.free-electrons.com/linux/latest/source/drivers/mtd/ubi/attach.c#L983
^ permalink raw reply
* Re: Race to power off harming SATA SSDs
From: Boris Brezillon @ 2017-05-08 11:50 UTC (permalink / raw)
To: David Woodhouse
Cc: Hans de Goede, Ricard Wanderlof, Pavel Machek, Tejun Heo,
linux-scsi, linux-kernel, linux-ide, linux-mtd,
Henrique de Moraes Holschuh
In-Reply-To: <1494238390.6528.42.camel@infradead.org>
On Mon, 08 May 2017 11:13:10 +0100
David Woodhouse <dwmw2@infradead.org> wrote:
> On Mon, 2017-05-08 at 11:09 +0200, Hans de Goede wrote:
> > You're forgetting that the SSD itself (this thread is about SSDs) also has
> > a major software component which is doing housekeeping all the time, so even
> > if the main CPU gets reset the SSD's controller may still happily be erasing
> > blocks.
>
> We're not really talking about SSDs at all any more; we're talking
> about real flash with real maintainable software.
It's probably a good sign that this new discussion should take place in
a different thread :-).
^ permalink raw reply
* Re: Race to power off harming SATA SSDs
From: Boris Brezillon @ 2017-05-08 11:48 UTC (permalink / raw)
To: Richard Weinberger
Cc: Pavel Machek, David Woodhouse, linux-scsi@vger.kernel.org,
Hans de Goede, LKML, linux-ide, linux-mtd@lists.infradead.org,
Henrique de Moraes Holschuh, Tejun Heo
In-Reply-To: <CAFLxGvzAmURHU_6K3gmBfOqHKgvQOkkO_+qgMKsmzhWZwwGnqw@mail.gmail.com>
On Mon, 8 May 2017 13:06:17 +0200
Richard Weinberger <richard.weinberger@gmail.com> wrote:
> On Mon, May 8, 2017 at 12:49 PM, Pavel Machek <pavel@ucw.cz> wrote:
> > Aha, nice, so it looks like ubifs is a step back here.
> >
> > 'clean marker' is a good idea... empty pages have plenty of space.
>
> If UBI (not UBIFS) faces an empty block, it also re-erases it.
Unfortunately, that's not the case, though UBI can easily be patched
to do that (see below).
> The EC header is uses as clean marker.
That is true. If the EC header has been written to a block, that means
this block has been correctly erased.
>
> > How do you handle the issue during regular write? Always ignore last
> > successfully written block?
I guess UBIFS can know what was written last, because of the log-based
approach + the seqnum stored along with FS nodes, but I'm pretty sure
UBIFS does not re-write the last written block in case of an unclean
mount. Richard, am I wrong?
>
> The last page of a block is inspected and allowed to be corrupted.
Actually, it's not really about corrupted pages, it's about pages that
might become unreadable after a few reads.
>
> > Do you handle "paired pages" problem on MLC?
>
> Nope, no MLC support in mainline so far.
Richard and I have put a lot of effort to reliably support MLC NANDs in
mainline, unfortunately this projects has been paused. You can access
the last version of our work here [1] if you're interested (it's
clearly not in a shippable state ;-)).
[1]https://github.com/bbrezillon/linux-sunxi/commits/bb/4.7/ubi-mlc
--->8---
diff --git a/drivers/mtd/ubi/attach.c b/drivers/mtd/ubi/attach.c
index 93ceea4f27d5..3d76941c9570 100644
--- a/drivers/mtd/ubi/attach.c
+++ b/drivers/mtd/ubi/attach.c
@@ -1121,21 +1121,20 @@ static int scan_peb(struct ubi_device *ubi, struct ubi_attach_info *ai,
return err;
goto adjust_mean_ec;
case UBI_IO_FF_BITFLIPS:
+ case UBI_IO_FF:
+ /*
+ * Always erase the block if the EC header is empty, even if
+ * no bitflips were reported because otherwise we might
+ * expose ourselves to the 'unstable bits' issue described
+ * here:
+ *
+ * http://www.linux-mtd.infradead.org/doc/ubifs.html#L_unstable_bits
+ */
err = add_to_list(ai, pnum, UBI_UNKNOWN, UBI_UNKNOWN,
ec, 1, &ai->erase);
if (err)
return err;
goto adjust_mean_ec;
- case UBI_IO_FF:
- if (ec_err || bitflips)
- err = add_to_list(ai, pnum, UBI_UNKNOWN,
- UBI_UNKNOWN, ec, 1, &ai->erase);
- else
- err = add_to_list(ai, pnum, UBI_UNKNOWN,
- UBI_UNKNOWN, ec, 0, &ai->free);
- if (err)
- return err;
- goto adjust_mean_ec;
default:
ubi_err(ubi, "'ubi_io_read_vid_hdr()' returned unknown code %d",
err);
^ permalink raw reply related
* Re: Race to power off harming SATA SSDs
From: David Woodhouse @ 2017-05-08 11:09 UTC (permalink / raw)
To: Pavel Machek
Cc: Tejun Heo, Henrique de Moraes Holschuh, linux-kernel, linux-scsi,
linux-ide, Hans de Goede, boris.brezillon, linux-mtd
In-Reply-To: <20170508104953.GA17773@amd>
[-- Attachment #1: Type: text/plain, Size: 2072 bytes --]
On Mon, 2017-05-08 at 12:49 +0200, Pavel Machek wrote:
> On Mon 2017-05-08 10:34:08, David Woodhouse wrote:
> >
> > On Mon, 2017-05-08 at 11:28 +0200, Pavel Machek wrote:
> > >
> > >
> > > Are you sure you have it right in JFFS2? Do you journal block erases?
> > > Apparently, that was pretty much non-issue on older flashes.
> > It isn't necessary in JFFS2. It is a *purely* log-structured file
> > system (which is why it doesn't scale well past the 1GiB or so that we
> > made it handle for OLPC).
> >
> > So we don't erase a block until all its contents are obsolete. And if
> > we fail to complete the erase... well the contents are either going to
> > fail a CRC check, or... still be obsoleted by later entries elsewhere.
> >
> > And even if it *looks* like an erase has completed and the block is all
> > 0xFF, we erase it again and write a 'clean marker' to it to indicate
> > that the erase was completed successfully. Because otherwise it can't
> > be trusted.
> Aha, nice, so it looks like ubifs is a step back here.
>
> 'clean marker' is a good idea... empty pages have plenty of space.
Well... you lose that space permanently. Although I suppose you could
do things differently and erase a block immediately prior to using it.
But in that case why ever write the cleanmarker? Just maintain a set of
blocks that you *will* erase and re-use.
> How do you handle the issue during regular write? Always ignore last
> successfully written block?
Log nodes have a CRC. If you get interrupted during a write, that CRC
should fail.
> Do you handle "paired pages" problem on MLC?
No. It would theoretically be possible, by not considering a write to
the first page "committed" until the second page of the pair is also
written. Essentially, it's not far off expanding the existing 'wbuf'
which we use to gather writes into full pages for NAND, to cover the
*whole* of the set of pages which are affected by MLC.
But we mostly consider JFFS2 to be obsolete these days, in favour of
UBI/UBIFS or other approaches.
[-- Attachment #2: smime.p7s --]
[-- Type: application/x-pkcs7-signature, Size: 4938 bytes --]
^ permalink raw reply
* Re: Race to power off harming SATA SSDs
From: Richard Weinberger @ 2017-05-08 11:06 UTC (permalink / raw)
To: Pavel Machek
Cc: David Woodhouse, Boris Brezillon, linux-scsi@vger.kernel.org,
Hans de Goede, LKML, linux-ide, linux-mtd@lists.infradead.org,
Henrique de Moraes Holschuh, Tejun Heo
In-Reply-To: <20170508104953.GA17773@amd>
On Mon, May 8, 2017 at 12:49 PM, Pavel Machek <pavel@ucw.cz> wrote:
> Aha, nice, so it looks like ubifs is a step back here.
>
> 'clean marker' is a good idea... empty pages have plenty of space.
If UBI (not UBIFS) faces an empty block, it also re-erases it.
The EC header is uses as clean marker.
> How do you handle the issue during regular write? Always ignore last
> successfully written block?
The last page of a block is inspected and allowed to be corrupted.
> Do you handle "paired pages" problem on MLC?
Nope, no MLC support in mainline so far.
--
Thanks,
//richard
^ permalink raw reply
* Re: Race to power off harming SATA SSDs
From: Pavel Machek @ 2017-05-08 10:49 UTC (permalink / raw)
To: David Woodhouse
Cc: Tejun Heo, Henrique de Moraes Holschuh, linux-kernel, linux-scsi,
linux-ide, Hans de Goede, boris.brezillon, linux-mtd
In-Reply-To: <1494236048.6528.32.camel@infradead.org>
On Mon 2017-05-08 10:34:08, David Woodhouse wrote:
> On Mon, 2017-05-08 at 11:28 +0200, Pavel Machek wrote:
> >
> > Are you sure you have it right in JFFS2? Do you journal block erases?
> > Apparently, that was pretty much non-issue on older flashes.
>
> It isn't necessary in JFFS2. It is a *purely* log-structured file
> system (which is why it doesn't scale well past the 1GiB or so that we
> made it handle for OLPC).
>
> So we don't erase a block until all its contents are obsolete. And if
> we fail to complete the erase... well the contents are either going to
> fail a CRC check, or... still be obsoleted by later entries elsewhere.
>
> And even if it *looks* like an erase has completed and the block is all
> 0xFF, we erase it again and write a 'clean marker' to it to indicate
> that the erase was completed successfully. Because otherwise it can't
> be trusted.
Aha, nice, so it looks like ubifs is a step back here.
'clean marker' is a good idea... empty pages have plenty of space.
How do you handle the issue during regular write? Always ignore last
successfully written block?
Do you handle "paired pages" problem on MLC?
Best regards,
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
^ permalink raw reply
* Re: [PATCH 2/4] ata: Add DT bindings for the Gemini SATA bridge
From: Bartlomiej Zolnierkiewicz @ 2017-05-08 10:49 UTC (permalink / raw)
To: Linus Walleij
Cc: Tejun Heo, linux-ide, Janos Laube, Paulius Zaleckas,
openwrt-devel, linux-arm-kernel, Hans Ulli Kroll,
Florian Fainelli, devicetree, John Feng-Hsin Chiang, Greentime Hu
In-Reply-To: <20170506121053.11554-2-linus.walleij@linaro.org>
On Saturday, May 06, 2017 02:10:51 PM Linus Walleij wrote:
> This adds device tree bindings for the Cortina Systems Gemini
> PATA to SATA bridge.
>
> 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>
> ---
> .../bindings/ata/cortina,gemini-sata-bridge.txt | 55 ++++++++++++++++++++++
> 1 file changed, 55 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/ata/cortina,gemini-sata-bridge.txt
>
> diff --git a/Documentation/devicetree/bindings/ata/cortina,gemini-sata-bridge.txt b/Documentation/devicetree/bindings/ata/cortina,gemini-sata-bridge.txt
> new file mode 100644
> index 000000000000..9fe92818b2fb
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/ata/cortina,gemini-sata-bridge.txt
> @@ -0,0 +1,55 @@
> +* Cortina Systems Gemini SATA Bridge
> +
> +The Gemini SATA bridge in a SoC-internal PATA to SATA bridge that
> +takes two Faraday Technology FTIDE010 PATA controllers and bridges
> +them in different configurations to two SATA ports.
> +
> +Required properties:
> +- compatible: should be
> + "cortina,gemini-sata-bridge"
> +- reg: registers and size for the block
> +- resets: phandles to the reset lines for both SATA bridges
> +- reset-names: must be "sata0", "sata1"
> +- clocks: phandles to the compulsory peripheral clocks
> +- clock-names: must be "SATA0_PCLK", "SATA1_PCLK"
> +- syscon: a phandle to the global Gemini system controller
> +- cortina,gemini-ata-muxmode: tell the desired multiplexing mode for
> + the ATA controller and SATA bridges. Values 0..3:
> + Mode 0: ata0 master <-> sata0
> + ata1 master <-> sata1
> + ata0 slave interface brought out on IDE pads
> + Mode 1: ata0 master <-> sata0
> + ata1 master <-> sata1
> + ata1 slave interface brought out on IDE pads
> + Mode 2: ata1 master <-> sata1
> + ata1 slave <-> sata0
> + ata0 master and slave interfaces brought out
> + on IDE pads
> + Mode 3: ata0 master <-> sata0
> + ata1 slave <-> sata1
ata0 slave?
> + ata1 master and slave interfaces brought out
> + on IDE pads
> +
> +Optional boolean properties:
> +- cortina,gemini-enable-ide-pins: enables the PATA to IDE connection.
> + The muxmode setting decides whether ATA0 or ATA1 is brought out,
> + and whether master, slave or both interfaces get brought out.
> +- cortina,gemini-enable-sata-bridge: enables the PATA to SATA bridge
> + inside the Gemnini SoC. The Muxmode decides what PATA blocks will
> + be muxed out and how.
> +
> +Example:
> +
> +sata: sata@46000000 {
> + compatible = "cortina,gemini-sata-bridge";
> + reg = <0x46000000 0x100>;
> + resets = <&rcon 26>, <&rcon 27>;
> + reset-names = "sata0", "sata1";
> + clocks = <&gcc GEMINI_CLK_GATE_SATA0>,
> + <&gcc GEMINI_CLK_GATE_SATA1>;
> + clock-names = "SATA0_PCLK", "SATA1_PCLK";
> + syscon = <&syscon>;
> + cortina,gemini-ata-muxmode = <3>;
> + cortina,gemini-enable-ide-pins;
> + cortina,gemini-enable-sata-bridge;
> +};
Best regards,
--
Bartlomiej Zolnierkiewicz
Samsung R&D Institute Poland
Samsung Electronics
^ permalink raw reply
* Re: [PATCH 1/4] ata: Add DT bindings for Faraday Technology FTIDE010
From: Bartlomiej Zolnierkiewicz @ 2017-05-08 10:47 UTC (permalink / raw)
To: Linus Walleij
Cc: Tejun Heo, linux-ide, Janos Laube, Paulius Zaleckas,
openwrt-devel, linux-arm-kernel, Hans Ulli Kroll,
Florian Fainelli, devicetree, John Feng-Hsin Chiang, Greentime Hu
In-Reply-To: <20170506121053.11554-1-linus.walleij@linaro.org>
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
^ permalink raw reply
* Re: Race to power off harming SATA SSDs
From: David Woodhouse @ 2017-05-08 10:13 UTC (permalink / raw)
To: Hans de Goede, Ricard Wanderlof
Cc: Pavel Machek, Tejun Heo, boris.brezillon, linux-scsi,
linux-kernel, linux-ide, linux-mtd, Henrique de Moraes Holschuh
In-Reply-To: <7ee84982-cfad-94d7-4e22-4edbeb852b32@redhat.com>
[-- Attachment #1: Type: text/plain, Size: 425 bytes --]
On Mon, 2017-05-08 at 11:09 +0200, Hans de Goede wrote:
> You're forgetting that the SSD itself (this thread is about SSDs) also has
> a major software component which is doing housekeeping all the time, so even
> if the main CPU gets reset the SSD's controller may still happily be erasing
> blocks.
We're not really talking about SSDs at all any more; we're talking
about real flash with real maintainable software.
[-- Attachment #2: smime.p7s --]
[-- Type: application/x-pkcs7-signature, Size: 4938 bytes --]
^ permalink raw reply
* Re: Race to power off harming SATA SSDs
From: David Woodhouse @ 2017-05-08 10:12 UTC (permalink / raw)
To: Ricard Wanderlof
Cc: boris.brezillon, Henrique de Moraes Holschuh, linux-scsi,
linux-ide, linux-kernel, Hans de Goede, linux-mtd, Pavel Machek,
Tejun Heo
In-Reply-To: <alpine.DEB.2.11.1705081059580.6882@lnxricardw1>
[-- Attachment #1.1: Type: text/plain, Size: 1046 bytes --]
On Mon, 2017-05-08 at 11:06 +0200, Ricard Wanderlof wrote:
>
> My point is really that say that the problem is in fact not that the erase
> is cut short due to the power fail, but that the software issues a second
> command before the first erase command has completed, for instance, or
> some other situation. Then we'd have a concrete situation which we can
> resolve (i.e., fix the bug), rather than assuming that it's the hardware's
> fault and implement various software workarounds.
On NOR flash we have *definitely* seen it during powerfail testing.
A block looks like it's all 0xFF when you read it back on mount, but if
you read it repeatedly, you may see bit flips because it wasn't
completely erased. And even if you read it ten times and 'trust' that
it's properly erased, it could start to show those bit flips when you
start to program it.
It was very repeatable, and that's when we implemented the 'clean
markers' written after a successful erase, rather than trusting a block
that "looks empty".
[-- Attachment #1.2: smime.p7s --]
[-- Type: application/x-pkcs7-signature, Size: 4938 bytes --]
[-- Attachment #2: Type: text/plain, Size: 144 bytes --]
______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/
^ permalink raw reply
* Re: Race to power off harming SATA SSDs
From: Richard Weinberger @ 2017-05-08 9:51 UTC (permalink / raw)
To: Pavel Machek
Cc: David Woodhouse, Tejun Heo, Henrique de Moraes Holschuh, LKML,
linux-scsi@vger.kernel.org, linux-ide, Hans de Goede,
Boris Brezillon, linux-mtd@lists.infradead.org
In-Reply-To: <20170508092846.GA11029@amd>
Pavel,
On Mon, May 8, 2017 at 11:28 AM, Pavel Machek <pavel@ucw.cz> wrote:
> Are you sure you have it right in JFFS2? Do you journal block erases?
> Apparently, that was pretty much non-issue on older flashes.
This is what the website says, yes. Do you have hardware where you can
trigger it?
If so, I'd love to get access to it.
So far I never saw the issue, sometimes people claim to suffer from it
but when I
inspect the problems in detail it is always something else.
--
Thanks,
//richard
^ permalink raw reply
* Re: Race to power off harming SATA SSDs
From: David Woodhouse @ 2017-05-08 9:34 UTC (permalink / raw)
To: Pavel Machek
Cc: Tejun Heo, Henrique de Moraes Holschuh, linux-kernel, linux-scsi,
linux-ide, Hans de Goede, boris.brezillon, linux-mtd
In-Reply-To: <20170508092846.GA11029@amd>
[-- Attachment #1: Type: text/plain, Size: 809 bytes --]
On Mon, 2017-05-08 at 11:28 +0200, Pavel Machek wrote:
>
> Are you sure you have it right in JFFS2? Do you journal block erases?
> Apparently, that was pretty much non-issue on older flashes.
It isn't necessary in JFFS2. It is a *purely* log-structured file
system (which is why it doesn't scale well past the 1GiB or so that we
made it handle for OLPC).
So we don't erase a block until all its contents are obsolete. And if
we fail to complete the erase... well the contents are either going to
fail a CRC check, or... still be obsoleted by later entries elsewhere.
And even if it *looks* like an erase has completed and the block is all
0xFF, we erase it again and write a 'clean marker' to it to indicate
that the erase was completed successfully. Because otherwise it can't
be trusted.
[-- Attachment #2: smime.p7s --]
[-- Type: application/x-pkcs7-signature, Size: 4938 bytes --]
^ permalink raw reply
* Re: Race to power off harming SATA SSDs
From: Pavel Machek @ 2017-05-08 9:28 UTC (permalink / raw)
To: David Woodhouse
Cc: Tejun Heo, Henrique de Moraes Holschuh, linux-kernel, linux-scsi,
linux-ide, Hans de Goede, boris.brezillon, linux-mtd
In-Reply-To: <1494228094.6528.14.camel@infradead.org>
On Mon 2017-05-08 08:21:34, David Woodhouse wrote:
> On Sun, 2017-05-07 at 22:40 +0200, Pavel Machek wrote:
> > > > NOTE: unclean SSD power-offs are dangerous and may brick the device in
> > > > the worst case, or otherwise harm it (reduce longevity, damage flash
> > > > blocks). It is also not impossible to get data corruption.
> >
> > > I get that the incrementing counters might not be pretty but I'm a bit
> > > skeptical about this being an actual issue. Because if that were
> > > true, the device would be bricking itself from any sort of power
> > > losses be that an actual power loss, battery rundown or hard power off
> > > after crash.
> >
> > And that's exactly what users see. If you do enough power fails on a
> > SSD, you usually brick it, some die sooner than others. There was some
> > test results published, some are here
> > http://lkcl.net/reports/ssd_analysis.html, I believe I seen some
> > others too.
> >
> > It is very hard for a NAND to work reliably in face of power
> > failures. In fact, not even Linux MTD + UBIFS works well in that
> > regards. See
> > http://www.linux-mtd.infradead.org/faq/ubi.html. (Unfortunately, its
> > down now?!). If we can't get it right, do you believe SSD manufactures
> > do?
> >
> > [Issue is, if you powerdown during erase, you get "weakly erased"
> > page, which will contain expected 0xff's, but you'll get bitflips
> > there quickly. Similar issue exists for writes. It is solveable in
> > software, just hard and slow... and we don't do it.]
>
> It's not that hard. We certainly do it in JFFS2. I was fairly sure that
> it was also part of the design considerations for UBI — it really ought
> to be right there too. I'm less sure about UBIFS but I would have
> expected it to be OK.
Are you sure you have it right in JFFS2? Do you journal block erases?
Apparently, that was pretty much non-issue on older flashes.
https://web-beta.archive.org/web/20160923094716/http://www.linux-mtd.infradead.org:80/doc/ubifs.html#L_unstable_bits
> SSDs however are often crap; power fail those at your peril. And of
> course there's nothing you can do when they do fail, whereas we accept
> patches for things which are implemented in Linux.
Agreed. If the SSD indiciates unexpected powerdown, it is a problem
and we need to fix it.
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
^ permalink raw reply
* Re: Race to power off harming SATA SSDs
From: Hans de Goede @ 2017-05-08 9:09 UTC (permalink / raw)
To: Ricard Wanderlof, David Woodhouse
Cc: Pavel Machek, Tejun Heo, boris.brezillon, linux-scsi,
linux-kernel, linux-ide, linux-mtd, Henrique de Moraes Holschuh
In-Reply-To: <alpine.DEB.2.11.1705081059580.6882@lnxricardw1>
Hi,
On 08-05-17 11:06, Ricard Wanderlof wrote:
>
> On Mon, 8 May 2017, David Woodhouse wrote:
>
>>> On Mon, 8 May 2017, David Woodhouse wrote:
>>>> Our empirical testing trumps your "can never happen" theory :)
>>>
>>> I'm sure it does. But what is the explanation then? Has anyone analyzed
>>> what is going on using an oscilloscope to verify relationship between
>>> erase command and supply voltage drop?
>>
>> Not that I'm aware of. Once we have reached the "it does happen and we
>> have to cope" there was not a lot of point in working out *why* it
>> happened.
>>
>> In fact, the only examples I *personally* remember were on NOR flash,
>> which takes longer to erase. So it's vaguely possible that it doesn't
>> happen on NAND. But really, it's not something we should be depending
>> on and the software mechanisms have to remain in place.
>
> My point is really that say that the problem is in fact not that the erase
> is cut short due to the power fail, but that the software issues a second
> command before the first erase command has completed, for instance, or
> some other situation. Then we'd have a concrete situation which we can
> resolve (i.e., fix the bug), rather than assuming that it's the hardware's
> fault and implement various software workarounds.
You're forgetting that the SSD itself (this thread is about SSDs) also has
a major software component which is doing housekeeping all the time, so even
if the main CPU gets reset the SSD's controller may still happily be erasing
blocks.
Regards,
Hans
^ permalink raw reply
* Re: Race to power off harming SATA SSDs
From: Ricard Wanderlof @ 2017-05-08 9:06 UTC (permalink / raw)
To: David Woodhouse
Cc: Pavel Machek, Tejun Heo, boris.brezillon, linux-scsi,
Hans de Goede, linux-kernel, linux-ide, linux-mtd,
Henrique de Moraes Holschuh
In-Reply-To: <1494233673.6528.28.camel@infradead.org>
On Mon, 8 May 2017, David Woodhouse wrote:
> > On Mon, 8 May 2017, David Woodhouse wrote:
> > > Our empirical testing trumps your "can never happen" theory :)
> >
> > I'm sure it does. But what is the explanation then? Has anyone analyzed
> > what is going on using an oscilloscope to verify relationship between
> > erase command and supply voltage drop?
>
> Not that I'm aware of. Once we have reached the "it does happen and we
> have to cope" there was not a lot of point in working out *why* it
> happened.
>
> In fact, the only examples I *personally* remember were on NOR flash,
> which takes longer to erase. So it's vaguely possible that it doesn't
> happen on NAND. But really, it's not something we should be depending
> on and the software mechanisms have to remain in place.
My point is really that say that the problem is in fact not that the erase
is cut short due to the power fail, but that the software issues a second
command before the first erase command has completed, for instance, or
some other situation. Then we'd have a concrete situation which we can
resolve (i.e., fix the bug), rather than assuming that it's the hardware's
fault and implement various software workarounds.
On the other hand, making the software resilient to erase problems
essentially makes the system more robust in any case, so it's not a bad
thing of course.
It's just that I've seen this "we're software guys, and it must be the
hardware's fault" (and vice versa) enough times to cause a small warning
bell to off here.
/Ricard
--
Ricard Wolf Wanderlöf ricardw(at)axis.com
Axis Communications AB, Lund, Sweden www.axis.com
Phone +46 46 272 2016 Fax +46 46 13 61 30
^ permalink raw reply
* Re: Race to power off harming SATA SSDs
From: David Woodhouse @ 2017-05-08 8:54 UTC (permalink / raw)
To: Ricard Wanderlof
Cc: Pavel Machek, Tejun Heo, boris.brezillon, linux-scsi,
Hans de Goede, linux-kernel, linux-ide, linux-mtd,
Henrique de Moraes Holschuh
In-Reply-To: <alpine.DEB.2.11.1705081034420.6882@lnxricardw1>
[-- Attachment #1: Type: text/plain, Size: 794 bytes --]
On Mon, 2017-05-08 at 10:36 +0200, Ricard Wanderlof wrote:
> On Mon, 8 May 2017, David Woodhouse wrote:
> > Our empirical testing trumps your "can never happen" theory :)
>
> I'm sure it does. But what is the explanation then? Has anyone analyzed
> what is going on using an oscilloscope to verify relationship between
> erase command and supply voltage drop?
Not that I'm aware of. Once we have reached the "it does happen and we
have to cope" there was not a lot of point in working out *why* it
happened.
In fact, the only examples I *personally* remember were on NOR flash,
which takes longer to erase. So it's vaguely possible that it doesn't
happen on NAND. But really, it's not something we should be depending
on and the software mechanisms have to remain in place.
[-- Attachment #2: smime.p7s --]
[-- Type: application/x-pkcs7-signature, Size: 4938 bytes --]
^ permalink raw reply
* Re: Race to power off harming SATA SSDs
From: Ricard Wanderlof @ 2017-05-08 8:36 UTC (permalink / raw)
To: David Woodhouse
Cc: Pavel Machek, Tejun Heo, boris.brezillon, linux-scsi,
Hans de Goede, linux-kernel, linux-ide, linux-mtd,
Henrique de Moraes Holschuh
In-Reply-To: <1494231215.6528.22.camel@infradead.org>
On Mon, 8 May 2017, David Woodhouse wrote:
> > I've got a problem with the underlying mechanism. How long does it take to
> > erase a NAND block? A couple of milliseconds. That means that for an erase
> > to be "weak" du to a power fail, the host CPU must issue an erase command,
> > and then the power to the NAND must drop within those milliseconds.
> > However, in most systems there will be a power monitor which will
> > essentially reset the CPU as soon as the power starts dropping. So in
> > practice, by the time the voltage is too low to successfully supply the
> > NAND chip, the CPU has already been reset, hence, no reset command will
> > have been given by the time NAND runs out of steam.
> >
> > Sure, with switchmode power supplies, we don't have those large capacitors
> > in the power supply which can keep the power going for a second or more,
> > but still, I would think that the power wouldn't die fast enough for this
> > to be an issue.
> >
> Our empirical testing trumps your "can never happen" theory :)
I'm sure it does. But what is the explanation then? Has anyone analyzed
what is going on using an oscilloscope to verify relationship between
erase command and supply voltage drop?
/Ricard
--
Ricard Wolf Wanderlöf ricardw(at)axis.com
Axis Communications AB, Lund, Sweden www.axis.com
Phone +46 46 272 2016 Fax +46 46 13 61 30
^ permalink raw reply
* Re: Race to power off harming SATA SSDs
From: David Woodhouse @ 2017-05-08 8:13 UTC (permalink / raw)
To: Ricard Wanderlof
Cc: Pavel Machek, Tejun Heo, boris.brezillon, linux-scsi,
Hans de Goede, linux-kernel, linux-ide, linux-mtd,
Henrique de Moraes Holschuh
In-Reply-To: <alpine.DEB.2.11.1705080930150.6882@lnxricardw1>
[-- Attachment #1: Type: text/plain, Size: 1823 bytes --]
On Mon, 2017-05-08 at 09:38 +0200, Ricard Wanderlof wrote:
> On Mon, 8 May 2017, David Woodhouse wrote:
>
> >
> > >
> > > [Issue is, if you powerdown during erase, you get "weakly erased"
> > > page, which will contain expected 0xff's, but you'll get bitflips
> > > there quickly. Similar issue exists for writes. It is solveable in
> > > software, just hard and slow... and we don't do it.]
> > It's not that hard. We certainly do it in JFFS2. I was fairly sure that
> > it was also part of the design considerations for UBI ? it really ought
> > to be right there too. I'm less sure about UBIFS but I would have
> > expected it to be OK.
> I've got a problem with the underlying mechanism. How long does it take to
> erase a NAND block? A couple of milliseconds. That means that for an erase
> to be "weak" du to a power fail, the host CPU must issue an erase command,
> and then the power to the NAND must drop within those milliseconds.
> However, in most systems there will be a power monitor which will
> essentially reset the CPU as soon as the power starts dropping. So in
> practice, by the time the voltage is too low to successfully supply the
> NAND chip, the CPU has already been reset, hence, no reset command will
> have been given by the time NAND runs out of steam.
>
> Sure, with switchmode power supplies, we don't have those large capacitors
> in the power supply which can keep the power going for a second or more,
> but still, I would think that the power wouldn't die fast enough for this
> to be an issue.
>
> But I could very well be wrong and I haven't had experience with that many
> NAND flash systems. But then please tell me where the above reasoning is
> flawed.
Our empirical testing trumps your "can never happen" theory :)
[-- Attachment #2: smime.p7s --]
[-- Type: application/x-pkcs7-signature, Size: 4938 bytes --]
^ permalink raw reply
* Re: Race to power off harming SATA SSDs
From: Ricard Wanderlof @ 2017-05-08 7:38 UTC (permalink / raw)
To: David Woodhouse
Cc: Pavel Machek, Tejun Heo, boris.brezillon, linux-scsi,
Hans de Goede, linux-kernel, linux-ide, linux-mtd,
Henrique de Moraes Holschuh
In-Reply-To: <1494228094.6528.14.camel@infradead.org>
On Mon, 8 May 2017, David Woodhouse wrote:
> > [Issue is, if you powerdown during erase, you get "weakly erased"
> > page, which will contain expected 0xff's, but you'll get bitflips
> > there quickly. Similar issue exists for writes. It is solveable in
> > software, just hard and slow... and we don't do it.]
>
> It's not that hard. We certainly do it in JFFS2. I was fairly sure that
> it was also part of the design considerations for UBI ? it really ought
> to be right there too. I'm less sure about UBIFS but I would have
> expected it to be OK.
I've got a problem with the underlying mechanism. How long does it take to
erase a NAND block? A couple of milliseconds. That means that for an erase
to be "weak" du to a power fail, the host CPU must issue an erase command,
and then the power to the NAND must drop within those milliseconds.
However, in most systems there will be a power monitor which will
essentially reset the CPU as soon as the power starts dropping. So in
practice, by the time the voltage is too low to successfully supply the
NAND chip, the CPU has already been reset, hence, no reset command will
have been given by the time NAND runs out of steam.
Sure, with switchmode power supplies, we don't have those large capacitors
in the power supply which can keep the power going for a second or more,
but still, I would think that the power wouldn't die fast enough for this
to be an issue.
But I could very well be wrong and I haven't had experience with that many
NAND flash systems. But then please tell me where the above reasoning is
flawed.
/Ricard
--
Ricard Wolf Wanderlöf ricardw(at)axis.com
Axis Communications AB, Lund, Sweden www.axis.com
Phone +46 46 272 2016 Fax +46 46 13 61 30
^ permalink raw reply
* Re: Race to power off harming SATA SSDs
From: David Woodhouse @ 2017-05-08 7:21 UTC (permalink / raw)
To: Pavel Machek, Tejun Heo
Cc: Henrique de Moraes Holschuh, linux-kernel, linux-scsi, linux-ide,
Hans de Goede, boris.brezillon, linux-mtd
In-Reply-To: <20170507204007.GA25628@atrey.karlin.mff.cuni.cz>
[-- Attachment #1: Type: text/plain, Size: 1874 bytes --]
On Sun, 2017-05-07 at 22:40 +0200, Pavel Machek wrote:
> > > NOTE: unclean SSD power-offs are dangerous and may brick the device in
> > > the worst case, or otherwise harm it (reduce longevity, damage flash
> > > blocks). It is also not impossible to get data corruption.
>
> > I get that the incrementing counters might not be pretty but I'm a bit
> > skeptical about this being an actual issue. Because if that were
> > true, the device would be bricking itself from any sort of power
> > losses be that an actual power loss, battery rundown or hard power off
> > after crash.
>
> And that's exactly what users see. If you do enough power fails on a
> SSD, you usually brick it, some die sooner than others. There was some
> test results published, some are here
> http://lkcl.net/reports/ssd_analysis.html, I believe I seen some
> others too.
>
> It is very hard for a NAND to work reliably in face of power
> failures. In fact, not even Linux MTD + UBIFS works well in that
> regards. See
> http://www.linux-mtd.infradead.org/faq/ubi.html. (Unfortunately, its
> down now?!). If we can't get it right, do you believe SSD manufactures
> do?
>
> [Issue is, if you powerdown during erase, you get "weakly erased"
> page, which will contain expected 0xff's, but you'll get bitflips
> there quickly. Similar issue exists for writes. It is solveable in
> software, just hard and slow... and we don't do it.]
It's not that hard. We certainly do it in JFFS2. I was fairly sure that
it was also part of the design considerations for UBI — it really ought
to be right there too. I'm less sure about UBIFS but I would have
expected it to be OK.
SSDs however are often crap; power fail those at your peril. And of
course there's nothing you can do when they do fail, whereas we accept
patches for things which are implemented in Linux.
[-- Attachment #2: smime.p7s --]
[-- Type: application/x-pkcs7-signature, Size: 4938 bytes --]
^ permalink raw reply
* Re: Race to power off harming SATA SSDs
From: Pavel Machek @ 2017-05-07 20:40 UTC (permalink / raw)
To: Tejun Heo
Cc: boris.brezillon, linux-scsi, Hans de Goede, linux-kernel,
linux-ide, linux-mtd, Henrique de Moraes Holschuh, dwmw2
In-Reply-To: <20170410235206.GA28603@wtj.duckdns.org>
Hi!
> > However, *IN PRACTICE*, SATA STANDBY IMMEDIATE command completion
> > [often?] only indicates that the device is now switching to the target
> > power management state, not that it has reached the target state. Any
> > further device status inquires would return that it is in STANDBY mode,
> > even if it is still entering that state.
> >
> > The kernel then continues the shutdown path while the SSD is still
> > preparing itself to be powered off, and it becomes a race. When the
> > kernel + firmware wins, platform power is cut before the SSD has
> > finished (i.e. the SSD is subject to an unclean power-off).
>
> At that point, the device is fully flushed and in terms of data
> integrity should be fine with losing power at any point anyway.
Actually, no, that is not how it works.
"Fully flushed" is one thing, surviving power loss is
different. Explanation below.
> > NOTE: unclean SSD power-offs are dangerous and may brick the device in
> > the worst case, or otherwise harm it (reduce longevity, damage flash
> > blocks). It is also not impossible to get data corruption.
>
> I get that the incrementing counters might not be pretty but I'm a bit
> skeptical about this being an actual issue. Because if that were
> true, the device would be bricking itself from any sort of power
> losses be that an actual power loss, battery rundown or hard power off
> after crash.
And that's exactly what users see. If you do enough power fails on a
SSD, you usually brick it, some die sooner than others. There was some
test results published, some are here
http://lkcl.net/reports/ssd_analysis.html, I believe I seen some
others too.
It is very hard for a NAND to work reliably in face of power
failures. In fact, not even Linux MTD + UBIFS works well in that
regards. See
http://www.linux-mtd.infradead.org/faq/ubi.html. (Unfortunately, its
down now?!). If we can't get it right, do you believe SSD manufactures
do?
[Issue is, if you powerdown during erase, you get "weakly erased"
page, which will contain expected 0xff's, but you'll get bitflips
there quickly. Similar issue exists for writes. It is solveable in
software, just hard and slow... and we don't do it.]
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/
^ permalink raw reply
* Re: [PATCH 1/4] ata: Add DT bindings for Faraday Technology FTIDE010
From: Hans Ulli Kroll @ 2017-05-07 16:39 UTC (permalink / raw)
To: Linus Walleij
Cc: openwrt-devel, devicetree, John Feng-Hsin Chiang,
Paulius Zaleckas, Bartlomiej Zolnierkiewicz, linux-ide,
Greentime Hu, Tejun Heo, Janos Laube, linux-arm-kernel
In-Reply-To: <20170506121053.11554-1-linus.walleij@linaro.org>
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.
_______________________________________________
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
^ permalink raw reply
* [PATCH 4/4] ARM: dts: add Gemini PATA/SATA support
From: Linus Walleij @ 2017-05-06 12:10 UTC (permalink / raw)
To: Tejun Heo, Bartlomiej Zolnierkiewicz, linux-ide
Cc: Janos Laube, Paulius Zaleckas, openwrt-devel, linux-arm-kernel,
Hans Ulli Kroll, Florian Fainelli, Linus Walleij,
John Feng-Hsin Chiang, Greentime Hu
In-Reply-To: <20170506121053.11554-1-linus.walleij@linaro.org>
The NAS4229B and SQ201 Gemini systems have a PATA controller
which is linked to a SATA bridge in the SoC. Enable both
platforms to use the PATA/SATA devices.
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>
---
PATA maintainers: this file will be applied by me through the ARM
SoC git tree. It is provided for reference only so you see how
it will be used.
---
arch/arm/boot/dts/gemini-nas4220b.dts | 10 +++++++
arch/arm/boot/dts/gemini-sq201.dts | 10 +++++++
arch/arm/boot/dts/gemini.dtsi | 56 +++++++++++++++++++++++++++++++++++
3 files changed, 76 insertions(+)
diff --git a/arch/arm/boot/dts/gemini-nas4220b.dts b/arch/arm/boot/dts/gemini-nas4220b.dts
index 7668ba52158e..55f6a4f1f801 100644
--- a/arch/arm/boot/dts/gemini-nas4220b.dts
+++ b/arch/arm/boot/dts/gemini-nas4220b.dts
@@ -98,5 +98,15 @@
read-only;
};
};
+
+ sata: sata@46000000 {
+ cortina,gemini-ata-muxmode = <0>;
+ cortina,gemini-enable-sata-bridge;
+ status = "okay";
+ };
+
+ ata@63000000 {
+ status = "okay";
+ };
};
};
diff --git a/arch/arm/boot/dts/gemini-sq201.dts b/arch/arm/boot/dts/gemini-sq201.dts
index 46309e79cc7b..4d200f0bcd45 100644
--- a/arch/arm/boot/dts/gemini-sq201.dts
+++ b/arch/arm/boot/dts/gemini-sq201.dts
@@ -93,6 +93,12 @@
};
};
+ sata: sata@46000000 {
+ cortina,gemini-ata-muxmode = <0>;
+ cortina,gemini-enable-sata-bridge;
+ status = "okay";
+ };
+
pci@50000000 {
status = "okay";
interrupt-map-mask = <0xf800 0 0 7>;
@@ -114,5 +120,9 @@
<0x6000 0 0 3 &pci_intc 1>,
<0x6000 0 0 4 &pci_intc 2>;
};
+
+ ata@63000000 {
+ status = "okay";
+ };
};
};
diff --git a/arch/arm/boot/dts/gemini.dtsi b/arch/arm/boot/dts/gemini.dtsi
index 6fe678a68e31..a50ad49d38f5 100644
--- a/arch/arm/boot/dts/gemini.dtsi
+++ b/arch/arm/boot/dts/gemini.dtsi
@@ -89,6 +89,18 @@
clock-names = "PCLK", "EXTCLK";
};
+ sata: sata@46000000 {
+ compatible = "cortina,gemini-sata-bridge";
+ reg = <0x46000000 0x100>;
+ resets = <&rcon 26>, <&rcon 27>;
+ reset-names = "sata0", "sata1";
+ clocks = <&gcc GEMINI_CLK_GATE_SATA0>,
+ <&gcc GEMINI_CLK_GATE_SATA1>;
+ clock-names = "SATA0_PCLK", "SATA1_PCLK";
+ syscon = <&syscon>;
+ status = "disabled";
+ };
+
intcon: interrupt-controller@48000000 {
compatible = "faraday,ftintc010";
reg = <0x48000000 0x1000>;
@@ -183,5 +195,49 @@
#interrupt-cells = <1>;
};
};
+
+ ata@63000000 {
+ compatible = "cortina,gemini-pata", "faraday,ftide010";
+ reg = <0x63000000 0x1000>;
+ interrupts = <4 IRQ_TYPE_EDGE_RISING>;
+ resets = <&rcon 2>;
+ clocks = <&gcc GEMINI_CLK_GATE_IDE>;
+ clock-names = "PCLK";
+ sata = <&sata>;
+ status = "disabled";
+ /* PIO timings assume 33 MHz bus speed */
+ faraday,pio-active-time = <10>, <10>, <10>, <3>, <3>;
+ faraday,pio-recovery-time = <10>, <3>, <1>, <3>, <1>;
+ faraday,mdma-50-active-time = <6>, <2>, <2>;
+ faraday,mdma-50-recovery-time = <6>, <2>, <1>;
+ faraday,mdma-66-active-time = <8>, <3>, <3>;
+ faraday,mdma-66-recovery-time = <8>, <2>, <1>;
+ faraday,udma-50-setup-time = <3>, <3>, <2>, <2>, <1>, <1>;
+ faraday,udma-50-hold-time = <3>, <1>, <1>, <1>, <1>, <1>;
+ faraday,udma-66-setup-time = <4>, <4>, <3>, <2>, <1>, <1>, <1>;
+ faraday,udma-66-hold-time = <4>, <2>, <1>, <1>, <1>, <1>, <1>;
+ };
+
+ ata@63400000 {
+ compatible = "cortina,gemini-pata", "faraday,ftide010";
+ reg = <0x63400000 0x1000>;
+ interrupts = <5 IRQ_TYPE_EDGE_RISING>;
+ resets = <&rcon 2>;
+ clocks = <&gcc GEMINI_CLK_GATE_IDE>;
+ clock-names = "PCLK";
+ sata = <&sata>;
+ status = "disabled";
+ /* PIO timings assume 33 MHz bus speed */
+ faraday,pio-active-time = <10>, <10>, <10>, <3>, <3>;
+ faraday,pio-recovery-time = <10>, <3>, <1>, <3>, <1>;
+ faraday,mdma-50-active-time = <6>, <2>, <2>;
+ faraday,mdma-50-recovery-time = <6>, <2>, <1>;
+ faraday,mdma-66-active-time = <8>, <3>, <3>;
+ faraday,mdma-66-recovery-time = <8>, <2>, <1>;
+ faraday,udma-50-setup-time = <3>, <3>, <2>, <2>, <1>, <1>;
+ faraday,udma-50-hold-time = <3>, <1>, <1>, <1>, <1>, <1>;
+ faraday,udma-66-setup-time = <4>, <4>, <3>, <2>, <1>, <1>, <1>;
+ faraday,udma-66-hold-time = <4>, <2>, <1>, <1>, <1>, <1>, <1>;
+ };
};
};
--
2.9.3
^ permalink raw reply related
* [PATCH 3/4] ata: Add driver for Faraday Technology FTIDE010
From: Linus Walleij @ 2017-05-06 12:10 UTC (permalink / raw)
To: Tejun Heo, Bartlomiej Zolnierkiewicz, linux-ide
Cc: Janos Laube, Paulius Zaleckas, openwrt-devel, linux-arm-kernel,
Hans Ulli Kroll, Florian Fainelli, Linus Walleij,
John Feng-Hsin Chiang, Greentime Hu
In-Reply-To: <20170506121053.11554-1-linus.walleij@linaro.org>
This adds a driver for the Faraday Technology FTIDE010
PATA IP block.
When used with the Storlink/Storm/Cortina Systems Gemini
SoC, the PATA interface is accompanied by a PATA<->SATA
bridge, so while the device appear as a PATA controller,
it attaches physically to SATA disks, and also has a
designated memory area with registers to set up the bridge.
The Gemini SATA bridge is separated into its own driver
file to make things modular and make it possible to reuse
the PATA driver as stand-alone on other systems than the
Gemini.
dmesg excerpt from the D-Link DIR-685 storage router:
gemini-sata-bridge 46000000.sata: SATA ID 00000e00, PHY ID: 01000100
gemini-sata-bridge 46000000.sata: set up the Gemini IDE/SATA nexus
ftide010 63000000.ata: set up Gemini PATA0
ftide010 63000000.ata: device ID 00000500, irq 26, io base 0x63000000
ftide010 63000000.ata: SATA0 (master) start
gemini-sata-bridge 46000000.sata: SATA0 PHY ready
scsi host0: pata-ftide010
ata1: PATA max UDMA/133 irq 26
ata1.00: ATA-8: INTEL SSDSA2CW120G3, 4PC10302, max UDMA/133
ata1.00: 234441648 sectors, multi 1: LBA48 NCQ (depth 0/32)
ata1.00: configured for UDMA/133
scsi 0:0:0:0: Direct-Access ATA INTEL SSDSA2CW12 0302 PQ: 0 ANSI: 5
ata1.00: Enabling discard_zeroes_data
sd 0:0:0:0: [sda] 234441648 512-byte logical blocks: (120 GB/112 GiB)
sd 0:0:0:0: [sda] Write Protect is off
sd 0:0:0:0: [sda] Write cache: enabled, read cache:
enabled, doesn't support DPO or FUA
ata1.00: Enabling discard_zeroes_data
ata1.00: Enabling discard_zeroes_data
sd 0:0:0:0: [sda] Attached SCSI disk
After this I can flawlessly mount and read/write copy etc files
from /dev/sda[n].
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>
---
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
---
MAINTAINERS | 9 +
drivers/ata/Kconfig | 21 ++
drivers/ata/Makefile | 2 +
drivers/ata/pata_ftide010.c | 609 ++++++++++++++++++++++++++++++++++++++++++++
drivers/ata/sata_gemini.c | 402 +++++++++++++++++++++++++++++
drivers/ata/sata_gemini.h | 20 ++
6 files changed, 1063 insertions(+)
create mode 100644 drivers/ata/pata_ftide010.c
create mode 100644 drivers/ata/sata_gemini.c
create mode 100644 drivers/ata/sata_gemini.h
diff --git a/MAINTAINERS b/MAINTAINERS
index c265a5fe4848..95d1897683a0 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -7405,6 +7405,15 @@ S: Maintained
F: drivers/ata/pata_*.c
F: drivers/ata/ata_generic.c
+LIBATA PATA FARADAY FTIDE010 AND GEMINI SATA BRIDGE DRIVERS
+M: Linus Walleij <linus.walleij@linaro.org>
+L: linux-ide@vger.kernel.org
+T: git git://git.kernel.org/pub/scm/linux/kernel/git/tj/libata.git
+S: Maintained
+F: drivers/ata/pata_ftide010.c
+F: drivers/ata/sata_gemini.c
+F: drivers/ata/sata_gemini.h
+
LIBATA SATA AHCI PLATFORM devices support
M: Hans de Goede <hdegoede@redhat.com>
M: Tejun Heo <tj@kernel.org>
diff --git a/drivers/ata/Kconfig b/drivers/ata/Kconfig
index 70b57d2229d6..a8cd25b43502 100644
--- a/drivers/ata/Kconfig
+++ b/drivers/ata/Kconfig
@@ -205,6 +205,16 @@ config SATA_FSL
If unsure, say N.
+config SATA_GEMINI
+ tristate "Gemini SATA bridge support"
+ depends on PATA_FTIDE010
+ default ARCH_GEMINI
+ help
+ This enabled support for the FTIDE010 to SATA bridge
+ found in Cortina Systems Gemini platform.
+
+ If unsure, say N.
+
config SATA_AHCI_SEATTLE
tristate "AMD Seattle 6.0Gbps AHCI SATA host controller support"
depends on ARCH_SEATTLE
@@ -582,6 +592,17 @@ config PATA_EP93XX
If unsure, say N.
+config PATA_FTIDE010
+ tristate "Faraday Technology FTIDE010 PATA support"
+ depends on OF
+ depends on ARM
+ default ARCH_GEMINI
+ help
+ This option enables support for the Faraday FTIDE010
+ PATA controller found in the Cortina Gemini SoCs.
+
+ If unsure, say N.
+
config PATA_HPT366
tristate "HPT 366/368 PATA support"
depends on PCI
diff --git a/drivers/ata/Makefile b/drivers/ata/Makefile
index 89a0a1915d36..85116267e487 100644
--- a/drivers/ata/Makefile
+++ b/drivers/ata/Makefile
@@ -7,6 +7,7 @@ obj-$(CONFIG_SATA_ACARD_AHCI) += acard-ahci.o libahci.o
obj-$(CONFIG_SATA_AHCI_SEATTLE) += ahci_seattle.o libahci.o libahci_platform.o
obj-$(CONFIG_SATA_AHCI_PLATFORM) += ahci_platform.o libahci.o libahci_platform.o
obj-$(CONFIG_SATA_FSL) += sata_fsl.o
+obj-$(CONFIG_SATA_GEMINI) += sata_gemini.o
obj-$(CONFIG_SATA_INIC162X) += sata_inic162x.o
obj-$(CONFIG_SATA_SIL24) += sata_sil24.o
obj-$(CONFIG_SATA_DWC) += sata_dwc_460ex.o
@@ -58,6 +59,7 @@ obj-$(CONFIG_PATA_CS5536) += pata_cs5536.o
obj-$(CONFIG_PATA_CYPRESS) += pata_cypress.o
obj-$(CONFIG_PATA_EFAR) += pata_efar.o
obj-$(CONFIG_PATA_EP93XX) += pata_ep93xx.o
+obj-$(CONFIG_PATA_FTIDE010) += pata_ftide010.o
obj-$(CONFIG_PATA_HPT366) += pata_hpt366.o
obj-$(CONFIG_PATA_HPT37X) += pata_hpt37x.o
obj-$(CONFIG_PATA_HPT3X2N) += pata_hpt3x2n.o
diff --git a/drivers/ata/pata_ftide010.c b/drivers/ata/pata_ftide010.c
new file mode 100644
index 000000000000..76ac2877b92d
--- /dev/null
+++ b/drivers/ata/pata_ftide010.c
@@ -0,0 +1,609 @@
+/*
+ * Faraday Technology FTIDE010 driver
+ * Copyright (C) 2017 Linus Walleij <linus.walleij@linaro.org>
+ *
+ * Includes portions of the SL2312/SL3516/Gemini PATA driver
+ * Copyright (C) 2003 StorLine, Inc <jason@storlink.com.tw>
+ * Copyright (C) 2009 Janos Laube <janos.dev@gmail.com>
+ * Copyright (C) 2010 Frederic Pecourt <opengemini@free.fr>
+ * Copyright (C) 2011 Tobias Waldvogel <tobias.waldvogel@gmail.com>
+ */
+
+#include <linux/platform_device.h>
+#include <linux/module.h>
+#include <linux/libata.h>
+#include <linux/bitops.h>
+#include <linux/of_address.h>
+#include <linux/of_device.h>
+#include <linux/clk.h>
+#include "sata_gemini.h"
+
+/**
+ * struct ftide010 - state container for the Faraday FTIDE010
+ * @dev: pointer back to the device representing this controller
+ * @base: remapped I/O space address
+ * @pclk: peripheral clock for the IDE block
+ * @host: pointer to the ATA host for this device
+ * @pio_timings: combined active/recovery values to be written to
+ * the PIO timing register for modes 0, 1, 2, 3 and 4.
+ * @mwdma_50_timings: combined active/recovery values to be written
+ * to the multiword DMA mode timing register for modes 0, 1 and 2
+ * at 50MHz speed
+ * @mwdma_66_timings: same as @mwdma_50_timings but for 66MHz
+ * @udma_50_timings: combined setup/hold values to be written
+ * to the ultra DMA mode timing register for modes 0-5 at 50MHz
+ * speed
+ * @udma_66_timings: combined setup/hold values to be written
+ * to the ultra DMA mode timing register for modes 0-6 at 66MHz
+ * speed
+ * @master_cbl: master cable type
+ * @slave_cbl: slave cable type
+ * @sg: Gemini SATA bridge pointer, if running on the Gemini
+ */
+struct ftide010 {
+ struct device *dev;
+ void __iomem *base;
+ struct clk *pclk;
+ struct ata_host *host;
+ u8 pio_timings[5];
+ u8 mwdma_50_timings[3];
+ u8 mwdma_66_timings[3];
+ u8 udma_50_timings[6];
+ u8 udma_66_timings[7];
+ unsigned int master_cbl;
+ unsigned int slave_cbl;
+ /* Gemini-specific properties */
+ struct sata_gemini *sg;
+ bool master_to_sata0;
+ bool slave_to_sata0;
+ bool master_to_sata1;
+ bool slave_to_sata1;
+};
+
+#define DMA_REG 0x00
+#define DMA_STATUS 0x02
+#define IDE_BMDTPR 0x04
+#define IDE_DEVICE_ID 0x08
+#define PIO_TIMING_REG 0x10
+#define MWDMA_TIMING_REG 0x11
+#define UDMA_TIMING0_REG 0x12 /* Master */
+#define UDMA_TIMING1_REG 0x13 /* Slave */
+#define CLK_MOD_REG 0x14
+/* These registers are mapped directly to the IDE registers */
+#define CMD_DATA_REG 0x20
+#define ERROR_FEATURES_REG 0x21
+#define NSECT_REG 0x22
+#define LBAL_REG 0x23
+#define LBAM_REG 0x24
+#define LBAH_REG 0x25
+#define DEVICE_REG 0x26
+#define STATUS_COMMAND_REG 0x27
+#define ALTSTAT_CTRL_REG 0x36
+
+/* Set this bit for UDMA mode 5 and 6 */
+#define UDMA_TIMING_MODE_56 BIT(7)
+
+/* 0 = 50 MHz, 1 = 66 MHz */
+#define CLK_MOD_DEV0_CLK_SEL BIT(0)
+#define CLK_MOD_DEV1_CLK_SEL BIT(1)
+/* Enable UDMA on a device */
+#define CLK_MOD_DEV0_UDMA_EN BIT(4)
+#define CLK_MOD_DEV1_UDMA_EN BIT(5)
+
+static struct scsi_host_template pata_ftide010_sht = {
+ ATA_BMDMA_SHT("pata-ftide010"),
+};
+
+/*
+ * We set 66 MHz for all MWDMA modes
+ */
+static const bool set_mdma_66_mhz[] = { true, true, true, true };
+
+/*
+ * We set 66 MHz for UDMA modes 3, 4 and 6 and no others
+ */
+static const bool set_udma_66_mhz[] = { false, false, false, true, true, false, true };
+
+static void ftide010_set_dmamode(struct ata_port *ap, struct ata_device *adev)
+{
+ struct ftide010 *ftide = ap->host->private_data;
+ unsigned short speed = adev->dma_mode;
+ u8 devno = adev->devno & 1;
+ u8 udma_en_mask;
+ u8 f66m_en_mask;
+ u8 clkreg;
+ u8 timreg;
+ unsigned int i;
+
+ /* Target device 0 (master) or 1 (slave) */
+ if (!devno) {
+ udma_en_mask = CLK_MOD_DEV0_UDMA_EN;
+ f66m_en_mask = CLK_MOD_DEV0_CLK_SEL;
+ } else {
+ udma_en_mask = CLK_MOD_DEV1_UDMA_EN;
+ f66m_en_mask = CLK_MOD_DEV1_CLK_SEL;
+ }
+
+ clkreg = ioread8(ftide->base + CLK_MOD_REG);
+ clkreg &= ~udma_en_mask;
+ clkreg &= ~f66m_en_mask;
+
+ if (speed & XFER_UDMA_0) {
+ i = speed & ~XFER_UDMA_0;
+ dev_dbg(ftide->dev, "set UDMA mode %02x, index %d\n",
+ speed, i);
+
+ clkreg |= udma_en_mask;
+ if (set_udma_66_mhz[i]) {
+ clkreg |= f66m_en_mask;
+ timreg = ftide->udma_66_timings[i];
+ } else {
+ timreg = ftide->udma_50_timings[i];
+ }
+
+ /* A special bit needs to be set for modes 5 and 6 */
+ if (i >= 5)
+ timreg |= UDMA_TIMING_MODE_56;
+
+ dev_dbg(ftide->dev, "UDMA write clkreg = %02x, timreg = %02x\n",
+ clkreg, timreg);
+
+ writeb(clkreg, ftide->base + CLK_MOD_REG);
+ writeb(timreg, ftide->base + UDMA_TIMING0_REG + devno);
+ } else {
+ i = speed & ~XFER_MW_DMA_0;
+ dev_dbg(ftide->dev, "set MWDMA mode %02x, index %d\n",
+ speed, i);
+
+ if (set_mdma_66_mhz[i]) {
+ clkreg |= f66m_en_mask;
+ timreg = ftide->mwdma_66_timings[i];
+ } else {
+ timreg = ftide->mwdma_50_timings[i];
+ }
+ dev_dbg(ftide->dev,
+ "MWDMA write clkreg = %02x, timreg = %02x\n",
+ clkreg, timreg);
+ /* This will affect all devices */
+ writeb(clkreg, ftide->base + CLK_MOD_REG);
+ writeb(timreg, ftide->base + MWDMA_TIMING_REG);
+ }
+
+ return;
+}
+
+static void ftide010_set_piomode(struct ata_port *ap, struct ata_device *adev)
+{
+ struct ftide010 *ftide = ap->host->private_data;
+ unsigned int pio = adev->pio_mode - XFER_PIO_0;
+
+ dev_dbg(ftide->dev, "set PIO mode %02x, index %d\n",
+ adev->pio_mode, pio);
+ writeb(ftide->pio_timings[pio], ftide->base + PIO_TIMING_REG);
+}
+
+static struct ata_port_operations pata_ftide010_port_ops = {
+ .inherits = &ata_bmdma_port_ops,
+ .set_dmamode = ftide010_set_dmamode,
+ .set_piomode = ftide010_set_piomode,
+};
+
+static struct ata_port_info ftide010_port_info[] = {
+ {
+ .flags = ATA_FLAG_SLAVE_POSS,
+ .mwdma_mask = ATA_MWDMA2,
+ .udma_mask = ATA_UDMA6,
+ .pio_mask = ATA_PIO4,
+ .port_ops = &pata_ftide010_port_ops,
+ },
+};
+
+static int pata_ftide010_parse_timing_item(struct ftide010 *ftide,
+ const char *activeprop,
+ const char *recoveryprop,
+ int index, u32 maxval,
+ u8 *timing)
+{
+ struct device_node *np = ftide->dev->of_node;
+ u8 timing_ret;
+ int ret;
+ u32 val;
+
+ ret = of_property_read_u32_index(np, activeprop, index, &val);
+ if (ret) {
+ dev_err(ftide->dev, "error reading element %d of %s\n",
+ index, activeprop);
+ return ret;
+ }
+ if (val > maxval) {
+ dev_err(ftide->dev,
+ "element %d of %s is out of range (max 15)\n",
+ index, activeprop);
+ return -EINVAL;
+ }
+ timing_ret = (u8)(val << 4);
+
+ ret = of_property_read_u32_index(np, recoveryprop, index, &val);
+ if (ret) {
+ dev_err(ftide->dev, "error reading element %d of %s\n",
+ index, recoveryprop);
+ return ret;
+ }
+ if (val > maxval) {
+ dev_err(ftide->dev,
+ "element %d of %s is out of range (max 15)\n",
+ index, recoveryprop);
+ return -EINVAL;
+ }
+ timing_ret |= (u8)val;
+
+ *timing = timing_ret;
+ return 0;
+}
+
+static int pata_ftide010_parse_of_timings(struct ftide010 *ftide)
+{
+ int i;
+ u8 timing;
+ int ret;
+
+ for (i = 0; i < sizeof(ftide->pio_timings); i++) {
+ ret = pata_ftide010_parse_timing_item(ftide,
+ "faraday,pio-active-time",
+ "faraday,pio-recovery-time",
+ i, 15,
+ &timing);
+ if (ret)
+ return ret;
+ ftide->pio_timings[i] = timing;
+ dev_dbg(ftide->dev, "PIO time [%d] = %02x\n", i, timing);
+ }
+
+ for (i = 0; i < sizeof(ftide->mwdma_50_timings); i++) {
+ ret = pata_ftide010_parse_timing_item(ftide,
+ "faraday,mdma-50-active-time",
+ "faraday,mdma-50-recovery-time",
+ i, 15,
+ &timing);
+ if (ret)
+ return ret;
+ ftide->mwdma_50_timings[i] = timing;
+ dev_dbg(ftide->dev, "MWDMA 50 time [%d] = %02x\n", i, timing);
+ }
+
+ for (i = 0; i < sizeof(ftide->mwdma_66_timings); i++) {
+ ret = pata_ftide010_parse_timing_item(ftide,
+ "faraday,mdma-66-active-time",
+ "faraday,mdma-66-recovery-time",
+ i, 15,
+ &timing);
+ if (ret)
+ return ret;
+ ftide->mwdma_66_timings[i] = timing;
+ dev_dbg(ftide->dev, "MWDMA 66 time [%d] = %02x\n", i, timing);
+ }
+
+ for (i = 0; i < sizeof(ftide->udma_50_timings); i++) {
+ ret = pata_ftide010_parse_timing_item(ftide,
+ "faraday,udma-50-setup-time",
+ "faraday,udma-50-hold-time",
+ i, 7,
+ &timing);
+ if (ret)
+ return ret;
+ ftide->udma_50_timings[i] = timing;
+ dev_dbg(ftide->dev, "UDMA 50 time [%d] = %02x\n", i, timing);
+ }
+
+ for (i = 0; i < sizeof(ftide->udma_66_timings); i++) {
+ ret = pata_ftide010_parse_timing_item(ftide,
+ "faraday,udma-66-setup-time",
+ "faraday,udma-66-hold-time",
+ i, 7,
+ &timing);
+ if (ret)
+ return ret;
+ ftide->udma_66_timings[i] = timing;
+ dev_dbg(ftide->dev, "UMDMA 66 time [%d] = %02x\n", i, timing);
+ }
+
+ return 0;
+}
+
+#if IS_ENABLED(CONFIG_SATA_GEMINI)
+
+static int pata_ftide010_gemini_port_start(struct ata_port *ap)
+{
+ struct ftide010 *ftide = ap->host->private_data;
+ struct device *dev = ftide->dev;
+ struct sata_gemini *sg = ftide->sg;
+ int ret;
+
+ ret = ata_bmdma_port_start(ap);
+ if (ret)
+ return ret;
+
+ if (ftide->master_to_sata0) {
+ dev_info(dev, "SATA0 (master) start\n");
+ ret = gemini_sata_start_bridge(sg, 0);
+ if (ret)
+ return ret;
+ }
+ if (ftide->master_to_sata1) {
+ dev_info(dev, "SATA1 (master) start\n");
+ ret = gemini_sata_start_bridge(sg, 1);
+ if (ret)
+ return ret;
+ }
+ /* Avoid double-starting */
+ if (ftide->slave_to_sata0 && !ftide->master_to_sata0) {
+ dev_info(dev, "SATA0 (slave) start\n");
+ ret = gemini_sata_start_bridge(sg, 0);
+ if (ret)
+ return ret;
+ }
+ /* Avoid double-starting */
+ if (ftide->slave_to_sata1 && !ftide->master_to_sata1) {
+ dev_info(dev, "SATA1 (slave) start\n");
+ ret = gemini_sata_start_bridge(sg, 1);
+ if (ret)
+ return ret;
+ }
+
+ return 0;
+}
+
+static void pata_ftide010_gemini_port_stop(struct ata_port *ap)
+{
+ struct ftide010 *ftide = ap->host->private_data;
+ struct device *dev = ftide->dev;
+ struct sata_gemini *sg = ftide->sg;
+
+ if (ftide->master_to_sata0) {
+ dev_info(dev, "SATA0 (master) stop\n");
+ gemini_sata_stop_bridge(sg, 0);
+ }
+ if (ftide->master_to_sata1) {
+ dev_info(dev, "SATA1 (master) stop\n");
+ gemini_sata_stop_bridge(sg, 1);
+ }
+ /* Avoid double-stopping */
+ if (ftide->slave_to_sata0 && !ftide->master_to_sata0) {
+ dev_info(dev, "SATA0 (slave) stop\n");
+ gemini_sata_stop_bridge(sg, 0);
+ }
+ /* Avoid double-stopping */
+ if (ftide->slave_to_sata1 && !ftide->master_to_sata1) {
+ dev_info(dev, "SATA1 (slave) stop\n");
+ gemini_sata_stop_bridge(sg, 1);
+ }
+}
+
+static int pata_ftide010_gemini_cable_detect(struct ata_port *ap)
+{
+ struct ftide010 *ftide = ap->host->private_data;
+
+ /*
+ * Return the master cable, I have no clue how to return a different
+ * cable for the slave than for the master.
+ */
+ return ftide->master_cbl;
+}
+
+static int pata_ftide010_gemini_init(struct ftide010 *ftide,
+ bool is_ata1)
+{
+ struct device *dev = ftide->dev;
+ struct sata_gemini *sg;
+ enum gemini_muxmode muxmode;
+
+ /* Look up SATA bridge */
+ sg = gemini_sata_bridge_get();
+ if (IS_ERR(sg))
+ return PTR_ERR(sg);
+ ftide->sg = sg;
+
+ muxmode = gemini_sata_get_muxmode(sg);
+
+ /* Special ops */
+ pata_ftide010_port_ops.port_start =
+ pata_ftide010_gemini_port_start;
+ pata_ftide010_port_ops.port_stop =
+ pata_ftide010_gemini_port_stop;
+ pata_ftide010_port_ops.cable_detect =
+ pata_ftide010_gemini_cable_detect;
+
+ /* Flag port as SATA-capable */
+ if (gemini_sata_bridge_enabled(sg, is_ata1))
+ ftide010_port_info[0].flags |= ATA_FLAG_SATA;
+
+ if (!is_ata1) {
+ switch (muxmode) {
+ case GEMINI_MUXMODE_0:
+ ftide->master_cbl = ATA_CBL_SATA;
+ ftide->slave_cbl = ATA_CBL_PATA40;
+ ftide->master_to_sata0 = true;
+ break;
+ case GEMINI_MUXMODE_1:
+ ftide->master_cbl = ATA_CBL_SATA;
+ ftide->slave_cbl = ATA_CBL_NONE;
+ ftide->master_to_sata0 = true;
+ break;
+ case GEMINI_MUXMODE_2:
+ ftide->master_cbl = ATA_CBL_PATA40;
+ ftide->slave_cbl = ATA_CBL_PATA40;
+ break;
+ case GEMINI_MUXMODE_3:
+ ftide->master_cbl = ATA_CBL_SATA;
+ ftide->slave_cbl = ATA_CBL_SATA;
+ ftide->master_to_sata0 = true;
+ ftide->slave_to_sata1 = true;
+ break;
+ }
+ } else {
+ switch (muxmode) {
+ case GEMINI_MUXMODE_0:
+ ftide->master_cbl = ATA_CBL_SATA;
+ ftide->slave_cbl = ATA_CBL_NONE;
+ ftide->master_to_sata1 = true;
+ break;
+ case GEMINI_MUXMODE_1:
+ ftide->master_cbl = ATA_CBL_SATA;
+ ftide->slave_cbl = ATA_CBL_PATA40;
+ ftide->master_to_sata1 = true;
+ break;
+ case GEMINI_MUXMODE_2:
+ ftide->master_cbl = ATA_CBL_SATA;
+ ftide->slave_cbl = ATA_CBL_SATA;
+ ftide->slave_to_sata0 = true;
+ ftide->master_to_sata1 = true;
+ break;
+ case GEMINI_MUXMODE_3:
+ ftide->master_cbl = ATA_CBL_PATA40;
+ ftide->slave_cbl = ATA_CBL_PATA40;
+ break;
+ }
+ }
+ dev_info(dev, "set up Gemini PATA%d\n", is_ata1);
+
+ return 0;
+}
+#else
+static int pata_ftide010_gemini_init(struct ftide010 *ftide,
+ bool is_ata1)
+{
+ return -ENOTSUPP;
+}
+#endif
+
+static int pata_ftide010_probe(struct platform_device *pdev)
+{
+ struct device *dev = &pdev->dev;
+ struct device_node *np = dev->of_node;
+ const struct ata_port_info pi = ftide010_port_info[0];
+ const struct ata_port_info *ppi[] = { &pi, NULL };
+ struct ftide010 *ftide;
+ struct resource *res;
+ int irq;
+ int ret;
+ int i;
+
+ ftide = devm_kzalloc(dev, sizeof(*ftide), GFP_KERNEL);
+ if (!ftide)
+ return -ENOMEM;
+ ftide->dev = dev;
+
+ irq = platform_get_irq(pdev, 0);
+ if (irq < 0)
+ return irq;
+
+ res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+ if (!res)
+ return -ENODEV;
+
+ ftide->base = devm_ioremap_resource(dev, res);
+ if (IS_ERR(ftide->base))
+ return PTR_ERR(ftide->base);
+
+ ftide->pclk = devm_clk_get(dev, "PCLK");
+ if (!IS_ERR(ftide->pclk)) {
+ ret = clk_prepare_enable(ftide->pclk);
+ if (ret) {
+ dev_err(dev, "failed to enable PCLK\n");
+ return ret;
+ }
+ }
+
+ /* Read out timings from the device tree */
+ ret = pata_ftide010_parse_of_timings(ftide);
+ if (ret)
+ goto err_dis_clk;
+
+ /* Some special Cortina Gemini init, if needed */
+ if (of_device_is_compatible(np, "cortina,gemini-pata")) {
+ /*
+ * We need to know which instance is probing (the
+ * Gemini has two instances of FTIDE010) and we do
+ * this simply by looking at the physical base
+ * address, which is 0x63400000 for ATA1, else we
+ * are ATA0. This will also set up the cable types.
+ */
+ ret = pata_ftide010_gemini_init(ftide,
+ (res->start == 0x63400000));
+ if (ret)
+ goto err_dis_clk;
+ } else {
+ /* Else assume we are connected using PATA40 */
+ ftide->master_cbl = ATA_CBL_PATA40;
+ ftide->slave_cbl = ATA_CBL_PATA40;
+ }
+
+ ftide->host = ata_host_alloc_pinfo(dev, ppi, 1);
+ if (!ftide->host) {
+ ret = -ENOMEM;
+ goto err_dis_clk;
+ }
+ ftide->host->private_data = ftide;
+
+ for (i = 0; i < ftide->host->n_ports; i++) {
+ struct ata_port *ap = ftide->host->ports[i];
+ struct ata_ioports *ioaddr = &ap->ioaddr;
+
+ ioaddr->bmdma_addr = ftide->base + DMA_REG;
+ ioaddr->cmd_addr = ftide->base + CMD_DATA_REG;
+ ioaddr->ctl_addr = ftide->base + ALTSTAT_CTRL_REG;
+ ioaddr->altstatus_addr = ftide->base + ALTSTAT_CTRL_REG;
+ ata_sff_std_ports(ioaddr);
+ }
+
+ platform_set_drvdata(pdev, ftide);
+ dev_info(dev, "device ID %08x, irq %d, io base 0x%08x\n",
+ readl(ftide->base + IDE_DEVICE_ID), irq, res->start);
+
+ ret = ata_host_activate(ftide->host, irq, ata_bmdma_interrupt,
+ 0, &pata_ftide010_sht);
+ if (ret)
+ goto err_remove_host;
+
+
+ return 0;
+
+err_remove_host:
+ ata_host_detach(ftide->host);
+err_dis_clk:
+ if (!IS_ERR(ftide->pclk))
+ clk_disable_unprepare(ftide->pclk);
+ return ret;
+}
+
+static int pata_ftide010_remove(struct platform_device *pdev)
+{
+ struct ftide010 *ftide = platform_get_drvdata(pdev);
+
+ ata_host_detach(ftide->host);
+ if (!IS_ERR(ftide->pclk))
+ clk_disable_unprepare(ftide->pclk);
+
+ return 0;
+}
+
+static const struct of_device_id pata_ftide010_of_match[] = {
+ {
+ .compatible = "faraday,ftide010",
+ },
+ {},
+};
+
+static struct platform_driver pata_ftide010_driver = {
+ .driver = {
+ .name = "ftide010",
+ .of_match_table = of_match_ptr(pata_ftide010_of_match),
+ },
+ .probe = pata_ftide010_probe,
+ .remove = pata_ftide010_remove,
+};
+module_platform_driver(pata_ftide010_driver);
+
+MODULE_AUTHOR("Linus Walleij <linus.walleij@linaro.org>");
+MODULE_LICENSE("GPL");
+MODULE_ALIAS("platform:pata-ftide010");
diff --git a/drivers/ata/sata_gemini.c b/drivers/ata/sata_gemini.c
new file mode 100644
index 000000000000..04491675f540
--- /dev/null
+++ b/drivers/ata/sata_gemini.c
@@ -0,0 +1,402 @@
+/*
+ * Cortina Systems Gemini SATA bridge add-on to Faraday FTIDE010
+ * Copyright (C) 2017 Linus Walleij <linus.walleij@linaro.org>
+ */
+
+#include <linux/init.h>
+#include <linux/module.h>
+#include <linux/platform_device.h>
+#include <linux/bitops.h>
+#include <linux/mfd/syscon.h>
+#include <linux/regmap.h>
+#include <linux/delay.h>
+#include <linux/reset.h>
+#include <linux/of_address.h>
+#include <linux/of_device.h>
+#include <linux/clk.h>
+#include <linux/io.h>
+#include "sata_gemini.h"
+
+/**
+ * struct sata_gemini - a state container for a Gemini SATA bridge
+ * @dev: the containing device
+ * @base: remapped I/O memory base
+ * @muxmode: the current muxing mode
+ * @ide_pins: if the device is using the plain IDE interface pins
+ * @sata_bridge: if the device enables the SATA bridge
+ * @sata0_reset: SATA0 reset handler
+ * @sata1_reset: SATA1 reset handler
+ */
+struct sata_gemini {
+ struct device *dev;
+ void __iomem *base;
+ enum gemini_muxmode muxmode;
+ bool ide_pins;
+ bool sata_bridge;
+ struct reset_control *sata0_reset;
+ struct reset_control *sata1_reset;
+ struct clk *sata0_pclk;
+ struct clk *sata1_pclk;
+};
+
+/* Global IDE PAD Skew Control Register */
+#define GLOBAL_IDE_SKEW_CTRL 0x18
+#define IDE1_HOST_STROBE_DELAY_SHIFT 28
+#define IDE1_DEVICE_STROBE_DELAY_SHIFT 24
+#define IDE1_OUTPUT_IO_SKEW_SHIFT 20
+#define IDE1_INPUT_IO_SKEW_SHIFT 16
+#define IDE0_HOST_STROBE_DELAY_SHIFT 12
+#define IDE0_DEVICE_STROBE_DELAY_SHIFT 8
+#define IDE0_OUTPUT_IO_SKEW_SHIFT 4
+#define IDE0_INPUT_IO_SKEW_SHIFT 0
+
+/* Miscellaneous Control Register */
+#define GLOBAL_MISC_CTRL 0x30
+/*
+ * Values of IDE IOMUX bits in the misc control register
+ *
+ * Bits 26:24 are "IDE IO Select", which decides what SATA
+ * adapters are connected to which of the two IDE/ATA
+ * controllers in the Gemini. We can connect the two IDE blocks
+ * to one SATA adapter each, both acting as master, or one IDE
+ * blocks to two SATA adapters so the IDE block can act in a
+ * master/slave configuration.
+ *
+ * We also bring out different blocks on the actual IDE
+ * pins (not SATA pins) if (and only if) these are muxed in.
+ *
+ * 111-100 - Reserved
+ * Mode 0: 000 - ata0 master <-> sata0
+ * ata1 master <-> sata1
+ * ata0 slave interface brought out on IDE pads
+ * Mode 1: 001 - ata0 master <-> sata0
+ * ata1 master <-> sata1
+ * ata1 slave interface brought out on IDE pads
+ * Mode 2: 010 - ata1 master <-> sata1
+ * ata1 slave <-> sata0
+ * ata0 master and slave interfaces brought out
+ * on IDE pads
+ * Mode 3: 011 - ata0 master <-> sata0
+ * ata1 slave <-> sata1
+ * ata1 master and slave interfaces brought out
+ * on IDE pads
+ */
+#define IDE_IOMUX_MASK (7 << 24)
+#define IDE_IOMUX_MODE0 (0 << 24)
+#define IDE_IOMUX_MODE1 (1 << 24)
+#define IDE_IOMUX_MODE2 (2 << 24)
+#define IDE_IOMUX_MODE3 (3 << 24)
+#define IDE_IOMUX_SHIFT (24)
+#define IDE_PADS_ENABLE BIT(4)
+#define PFLASH_PADS_DISABLE BIT(1)
+
+/*
+ * Registers directly controlling the PATA<->SATA adapters
+ */
+#define SATA_ID 0x00
+#define SATA_PHY_ID 0x04
+#define SATA0_STATUS 0x08
+#define SATA1_STATUS 0x0c
+#define SATA0_CTRL 0x18
+#define SATA1_CTRL 0x1c
+
+#define SATA_STATUS_BIST_DONE BIT(5)
+#define SATA_STATUS_BIST_OK BIT(4)
+#define SATA_STATUS_PHY_READY BIT(0)
+
+#define SATA_CTRL_PHY_BIST_EN BIT(14)
+#define SATA_CTRL_PHY_FORCE_IDLE BIT(13)
+#define SATA_CTRL_PHY_FORCE_READY BIT(12)
+#define SATA_CTRL_PHY_AFE_LOOP_EN BIT(10)
+#define SATA_CTRL_PHY_DIG_LOOP_EN BIT(9)
+#define SATA_CTRL_HOTPLUG_DETECT_EN BIT(4)
+#define SATA_CTRL_ATAPI_EN BIT(3)
+#define SATA_CTRL_BUS_WITH_20 BIT(2)
+#define SATA_CTRL_SLAVE_EN BIT(1)
+#define SATA_CTRL_EN BIT(0)
+
+/*
+ * There is only ever one instance of this bridge on a system,
+ * so create a singleton so that the FTIDE010 instances can grab
+ * a reference to it.
+ */
+static struct sata_gemini *sg_singleton;
+
+struct sata_gemini *gemini_sata_bridge_get(void)
+{
+ if (sg_singleton)
+ return sg_singleton;
+ return ERR_PTR(-EPROBE_DEFER);
+}
+EXPORT_SYMBOL(gemini_sata_bridge_get);
+
+bool gemini_sata_bridge_enabled(struct sata_gemini *sg, bool is_ata1)
+{
+ if (!sg->sata_bridge)
+ return false;
+ /*
+ * In muxmode 2 and 3 one of the ATA controllers is
+ * actually not connected to any SATA bridge.
+ */
+ if ((sg->muxmode == GEMINI_MUXMODE_2) &&
+ !is_ata1)
+ return false;
+ if ((sg->muxmode == GEMINI_MUXMODE_3) &&
+ is_ata1)
+ return false;
+ return true;
+}
+EXPORT_SYMBOL(gemini_sata_bridge_enabled);
+
+enum gemini_muxmode gemini_sata_get_muxmode(struct sata_gemini *sg)
+{
+ return sg->muxmode;
+}
+EXPORT_SYMBOL(gemini_sata_get_muxmode);
+
+static int gemini_sata_setup_bridge(struct sata_gemini *sg,
+ unsigned int bridge)
+{
+ unsigned long timeout = jiffies + (HZ * 1);
+ u32 val;
+
+ if (bridge == 0) {
+ val = SATA_CTRL_HOTPLUG_DETECT_EN | SATA_CTRL_EN;
+ /* SATA0 slave mode is only used in muxmode 2 */
+ if (sg->muxmode == GEMINI_MUXMODE_2)
+ val |= SATA_CTRL_SLAVE_EN;
+ writel(val, sg->base + SATA0_CTRL);
+ } else {
+ val = SATA_CTRL_HOTPLUG_DETECT_EN | SATA_CTRL_EN;
+ /* SATA1 slave mode is only used in muxmode 3 */
+ if (sg->muxmode == GEMINI_MUXMODE_3)
+ val |= SATA_CTRL_SLAVE_EN;
+ writel(val, sg->base + SATA1_CTRL);
+ }
+
+ /* Vendor code waits 10 ms here */
+ msleep(10);
+
+ /* Wait for PHY to become ready */
+ do {
+ msleep(100);
+
+ if (bridge == 0)
+ val = readl(sg->base + SATA0_STATUS);
+ else
+ val = readl(sg->base + SATA1_STATUS);
+ if (val & SATA_STATUS_PHY_READY)
+ break;
+ } while (time_before(jiffies, timeout));
+
+ dev_info(sg->dev, "SATA%d PHY %s\n", bridge,
+ (val & SATA_STATUS_PHY_READY) ? "ready" : "not ready");
+ return 0;
+}
+
+int gemini_sata_start_bridge(struct sata_gemini *sg, unsigned int bridge)
+{
+ if (bridge == 0)
+ clk_enable(sg->sata0_pclk);
+ else
+ clk_enable(sg->sata1_pclk);
+ msleep(10);
+ return gemini_sata_setup_bridge(sg, bridge);
+}
+EXPORT_SYMBOL(gemini_sata_start_bridge);
+
+void gemini_sata_stop_bridge(struct sata_gemini *sg, unsigned int bridge)
+{
+ if (bridge == 0)
+ clk_disable(sg->sata0_pclk);
+ else
+ clk_disable(sg->sata1_pclk);
+}
+EXPORT_SYMBOL(gemini_sata_stop_bridge);
+
+int gemini_sata_reset_bridge(struct sata_gemini *sg,
+ unsigned int bridge)
+{
+ if (bridge == 0)
+ reset_control_reset(sg->sata0_reset);
+ else
+ reset_control_reset(sg->sata1_reset);
+ msleep(10);
+ return gemini_sata_setup_bridge(sg, bridge);
+}
+EXPORT_SYMBOL(gemini_sata_reset_bridge);
+
+static int gemini_sata_bridge_init(struct sata_gemini *sg)
+{
+ struct device *dev = sg->dev;
+ u32 sata_id, sata_phy_id;
+ int ret;
+
+ sg->sata0_pclk = devm_clk_get(dev, "SATA0_PCLK");
+ if (IS_ERR(sg->sata0_pclk)) {
+ dev_err(dev, "no SATA0 PCLK");
+ return -ENODEV;
+ }
+ sg->sata1_pclk = devm_clk_get(dev, "SATA1_PCLK");
+ if (IS_ERR(sg->sata1_pclk)) {
+ dev_err(dev, "no SATA1 PCLK");
+ return -ENODEV;
+ }
+
+ ret = clk_prepare_enable(sg->sata0_pclk);
+ if (ret) {
+ pr_err("failed to enable SATA0 PCLK\n");
+ return ret;
+ }
+ ret = clk_prepare_enable(sg->sata1_pclk);
+ if (ret) {
+ pr_err("failed to enable SATA1 PCLK\n");
+ return ret;
+ }
+
+ sg->sata0_reset = devm_reset_control_get(dev, "sata0");
+ if (IS_ERR(sg->sata0_reset)) {
+ dev_err(dev, "no SATA0 reset controller\n");
+ return PTR_ERR(sg->sata0_reset);
+ }
+ sg->sata1_reset = devm_reset_control_get(dev, "sata1");
+ if (IS_ERR(sg->sata1_reset)) {
+ dev_err(dev, "no SATA1 reset controller\n");
+ return PTR_ERR(sg->sata1_reset);
+ }
+
+ sata_id = readl(sg->base + SATA_ID);
+ sata_phy_id = readl(sg->base + SATA_PHY_ID);
+ sg->sata_bridge = true;
+ clk_disable(sg->sata0_pclk);
+ clk_disable(sg->sata1_pclk);
+
+ dev_info(dev, "SATA ID %08x, PHY ID: %08x\n", sata_id, sata_phy_id);
+
+ return 0;
+}
+
+static int gemini_sata_probe(struct platform_device *pdev)
+{
+ struct device *dev = &pdev->dev;
+ struct device_node *np = dev->of_node;
+ struct sata_gemini *sg;
+ static struct regmap *map;
+ struct resource *res;
+ enum gemini_muxmode muxmode;
+ u32 gmode;
+ u32 gmask;
+ u32 val;
+ int ret;
+
+ sg = devm_kzalloc(dev, sizeof(*sg), GFP_KERNEL);
+ if (!sg)
+ return -ENOMEM;
+ sg->dev = dev;
+
+ res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+ if (!res)
+ return -ENODEV;
+
+ sg->base = devm_ioremap_resource(dev, res);
+ if (IS_ERR(sg->base))
+ return PTR_ERR(sg->base);
+
+ map = syscon_regmap_lookup_by_phandle(np, "syscon");
+ if (IS_ERR(map)) {
+ dev_err(dev, "no global syscon\n");
+ return PTR_ERR(map);
+ }
+
+ /* Set up the SATA bridge if need be */
+ if (of_property_read_bool(np, "cortina,gemini-enable-sata-bridge")) {
+ ret = gemini_sata_bridge_init(sg);
+ if (ret)
+ return ret;
+ }
+
+ if (of_property_read_bool(np, "cortina,gemini-enable-ide-pins"))
+ sg->ide_pins = true;
+
+ if (!sg->sata_bridge && !sg->ide_pins) {
+ dev_err(dev, "neither SATA bridge or IDE output enabled\n");
+ return -EINVAL;
+ }
+
+ ret = of_property_read_u32(np, "cortina,gemini-ata-muxmode", &muxmode);
+ if (ret) {
+ dev_err(dev, "could not parse ATA muxmode\n");
+ return ret;
+ }
+ if (muxmode > GEMINI_MUXMODE_3) {
+ dev_err(dev, "illegal muxmode %d\n", muxmode);
+ return -EINVAL;
+ }
+ sg->muxmode = muxmode;
+ gmask = IDE_IOMUX_MASK;
+ gmode = (muxmode << IDE_IOMUX_SHIFT);
+
+ /*
+ * If we mux out the IDE, parallel flash must be disabled.
+ * SATA0 and SATA1 have dedicated pins and may coexist with
+ * parallel flash.
+ */
+ if (sg->ide_pins)
+ gmode |= IDE_PADS_ENABLE | PFLASH_PADS_DISABLE;
+ else
+ gmask |= IDE_PADS_ENABLE;
+
+ ret = regmap_update_bits(map, GLOBAL_MISC_CTRL, gmask, gmode);
+ if (ret) {
+ dev_err(dev, "unable to set up IDE muxing\n");
+ return -ENODEV;
+ }
+
+ /* FIXME: add more elaborate IDE skew control handling */
+ if (sg->ide_pins) {
+ ret = regmap_read(map, GLOBAL_IDE_SKEW_CTRL, &val);
+ if (ret) {
+ dev_err(dev, "cannot read IDE skew control register\n");
+ return ret;
+ }
+ dev_info(dev, "IDE skew control: %08x\n", val);
+ }
+
+ dev_info(dev, "set up the Gemini IDE/SATA nexus\n");
+ platform_set_drvdata(pdev, sg);
+ sg_singleton = sg;
+
+ return 0;
+}
+
+static int gemini_sata_remove(struct platform_device *pdev)
+{
+ struct sata_gemini *sg = platform_get_drvdata(pdev);
+
+ clk_unprepare(sg->sata0_pclk);
+ clk_unprepare(sg->sata1_pclk);
+ sg_singleton = NULL;
+
+ return 0;
+}
+
+static const struct of_device_id gemini_sata_of_match[] = {
+ {
+ .compatible = "cortina,gemini-sata-bridge",
+ },
+ {},
+};
+
+static struct platform_driver gemini_sata_driver = {
+ .driver = {
+ .name = "gemini-sata-bridge",
+ .of_match_table = of_match_ptr(gemini_sata_of_match),
+ },
+ .probe = gemini_sata_probe,
+ .remove = gemini_sata_remove,
+};
+module_platform_driver(gemini_sata_driver);
+
+MODULE_AUTHOR("Linus Walleij <linus.walleij@linaro.org>");
+MODULE_LICENSE("GPL");
+MODULE_ALIAS("platform:gemini-sata-bridge");
diff --git a/drivers/ata/sata_gemini.h b/drivers/ata/sata_gemini.h
new file mode 100644
index 000000000000..519c119ec71c
--- /dev/null
+++ b/drivers/ata/sata_gemini.h
@@ -0,0 +1,20 @@
+/* Header for the Gemini SATA bridge */
+#ifdef CONFIG_SATA_GEMINI
+
+struct sata_gemini;
+
+enum gemini_muxmode {
+ GEMINI_MUXMODE_0 = 0,
+ GEMINI_MUXMODE_1,
+ GEMINI_MUXMODE_2,
+ GEMINI_MUXMODE_3,
+};
+
+struct sata_gemini *gemini_sata_bridge_get(void);
+bool gemini_sata_bridge_enabled(struct sata_gemini *sg, bool is_ata1);
+enum gemini_muxmode gemini_sata_get_muxmode(struct sata_gemini *sg);
+int gemini_sata_start_bridge(struct sata_gemini *sg, unsigned int bridge);
+void gemini_sata_stop_bridge(struct sata_gemini *sg, unsigned int bridge);
+int gemini_sata_reset_bridge(struct sata_gemini *sg, unsigned int bridge);
+
+#endif
--
2.9.3
^ permalink raw reply related
* [PATCH 2/4] ata: Add DT bindings for the Gemini SATA bridge
From: Linus Walleij @ 2017-05-06 12:10 UTC (permalink / raw)
To: Tejun Heo, Bartlomiej Zolnierkiewicz, linux-ide
Cc: Janos Laube, Paulius Zaleckas, openwrt-devel, linux-arm-kernel,
Hans Ulli Kroll, Florian Fainelli, Linus Walleij, devicetree,
John Feng-Hsin Chiang, Greentime Hu
In-Reply-To: <20170506121053.11554-1-linus.walleij@linaro.org>
This adds device tree bindings for the Cortina Systems Gemini
PATA to SATA bridge.
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>
---
.../bindings/ata/cortina,gemini-sata-bridge.txt | 55 ++++++++++++++++++++++
1 file changed, 55 insertions(+)
create mode 100644 Documentation/devicetree/bindings/ata/cortina,gemini-sata-bridge.txt
diff --git a/Documentation/devicetree/bindings/ata/cortina,gemini-sata-bridge.txt b/Documentation/devicetree/bindings/ata/cortina,gemini-sata-bridge.txt
new file mode 100644
index 000000000000..9fe92818b2fb
--- /dev/null
+++ b/Documentation/devicetree/bindings/ata/cortina,gemini-sata-bridge.txt
@@ -0,0 +1,55 @@
+* Cortina Systems Gemini SATA Bridge
+
+The Gemini SATA bridge in a SoC-internal PATA to SATA bridge that
+takes two Faraday Technology FTIDE010 PATA controllers and bridges
+them in different configurations to two SATA ports.
+
+Required properties:
+- compatible: should be
+ "cortina,gemini-sata-bridge"
+- reg: registers and size for the block
+- resets: phandles to the reset lines for both SATA bridges
+- reset-names: must be "sata0", "sata1"
+- clocks: phandles to the compulsory peripheral clocks
+- clock-names: must be "SATA0_PCLK", "SATA1_PCLK"
+- syscon: a phandle to the global Gemini system controller
+- cortina,gemini-ata-muxmode: tell the desired multiplexing mode for
+ the ATA controller and SATA bridges. Values 0..3:
+ Mode 0: ata0 master <-> sata0
+ ata1 master <-> sata1
+ ata0 slave interface brought out on IDE pads
+ Mode 1: ata0 master <-> sata0
+ ata1 master <-> sata1
+ ata1 slave interface brought out on IDE pads
+ Mode 2: ata1 master <-> sata1
+ ata1 slave <-> sata0
+ ata0 master and slave interfaces brought out
+ on IDE pads
+ Mode 3: ata0 master <-> sata0
+ ata1 slave <-> sata1
+ ata1 master and slave interfaces brought out
+ on IDE pads
+
+Optional boolean properties:
+- cortina,gemini-enable-ide-pins: enables the PATA to IDE connection.
+ The muxmode setting decides whether ATA0 or ATA1 is brought out,
+ and whether master, slave or both interfaces get brought out.
+- cortina,gemini-enable-sata-bridge: enables the PATA to SATA bridge
+ inside the Gemnini SoC. The Muxmode decides what PATA blocks will
+ be muxed out and how.
+
+Example:
+
+sata: sata@46000000 {
+ compatible = "cortina,gemini-sata-bridge";
+ reg = <0x46000000 0x100>;
+ resets = <&rcon 26>, <&rcon 27>;
+ reset-names = "sata0", "sata1";
+ clocks = <&gcc GEMINI_CLK_GATE_SATA0>,
+ <&gcc GEMINI_CLK_GATE_SATA1>;
+ clock-names = "SATA0_PCLK", "SATA1_PCLK";
+ syscon = <&syscon>;
+ cortina,gemini-ata-muxmode = <3>;
+ cortina,gemini-enable-ide-pins;
+ cortina,gemini-enable-sata-bridge;
+};
--
2.9.3
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox