| Message ID | 20170506121053.11554-2-linus.walleij@linaro.org |
|---|---|
| State | Not Applicable |
| Delegated to: | John Crispin |
| Headers | show |
On Mon, May 8, 2017 at 12:49 PM, Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com> wrote: > On Saturday, May 06, 2017 02:10:51 PM Linus Walleij wrote: >> + Mode 3: ata0 master <-> sata0 >> + ata1 slave <-> sata1 > > ata0 slave? > >> + ata1 master and slave interfaces brought out >> + on IDE pads Of course. Thanks for reading close, much appreciated! Yours, Linus Walleij
Is it ever going to be added so this endless spam can end? On 8 May 2017 at 22:33, Linus Walleij <linus.walleij@linaro.org> wrote: > On Mon, May 8, 2017 at 12:49 PM, Bartlomiej Zolnierkiewicz > <b.zolnierkie@samsung.com> wrote: > > On Saturday, May 06, 2017 02:10:51 PM Linus Walleij wrote: > > >> + Mode 3: ata0 master <-> sata0 > >> + ata1 slave <-> sata1 > > > > ata0 slave? > > > >> + ata1 master and slave interfaces brought out > >> + on IDE pads > > Of course. Thanks for reading close, much appreciated! > > Yours, > Linus Walleij > _______________________________________________ > openwrt-devel mailing list > openwrt-devel@lists.openwrt.org > https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel >
On 05/08/2017 02:16 PM, Tom Psyborg wrote: > Is it ever going to be added so this endless spam can end? It's the first iteration of the (S)ATA patchset, and if you are not interested, just ignore the thread. Linus is doing everyone a great favor here by making sure that this platform gets properly supported upstream such that the cost of maintaining in OpenWrt/LEDE/anywhere else comes down to almost zero. Almost forgot: please don't top post. > > > On 8 May 2017 at 22:33, Linus Walleij <linus.walleij@linaro.org > <mailto:linus.walleij@linaro.org>> wrote: > > On Mon, May 8, 2017 at 12:49 PM, Bartlomiej Zolnierkiewicz > <b.zolnierkie@samsung.com <mailto:b.zolnierkie@samsung.com>> wrote: > > On Saturday, May 06, 2017 02:10:51 PM Linus Walleij wrote: > > >> + Mode 3: ata0 master <-> sata0 > >> + ata1 slave <-> sata1 > > > > ata0 slave? > > > >> + ata1 master and slave interfaces brought out > >> + on IDE pads > > Of course. Thanks for reading close, much appreciated! > > Yours, > Linus Walleij > _______________________________________________ > openwrt-devel mailing list > openwrt-devel@lists.openwrt.org <mailto:openwrt-devel@lists.openwrt.org> > https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel > <https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel> > > > > > _______________________________________________ > openwrt-devel mailing list > openwrt-devel@lists.openwrt.org > https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel >
On Tue, May 9, 2017 at 12:52 AM, Florian Fainelli <f.fainelli@gmail.com> wrote: > On 05/08/2017 02:16 PM, Tom Psyborg wrote: >> Is it ever going to be added so this endless spam can end? > > It's the first iteration of the (S)ATA patchset, and if you are not > interested, just ignore the thread. I mailed with Tom and it turns out he thinks openwrt-devel is getting spammed with these submissions. It's true in a sense: the patches are targeted for upstream and not for the openwrt repo. It's no big deal, I don't want to unnecessarily increase traffic on openwrt-devel if it is annoying to some. > Linus is doing everyone a great favor here by making sure that this > platform gets properly supported upstream such that the cost of > maintaining in OpenWrt/LEDE/anywhere else comes down to almost zero. I am porting to D-Link DIR-685 and DNS-313 as part of the process, so we have two new high-volume routers/NAS boxes as part of the process. I don't know how to fix the OpenWRT install and builds for these in the end though. It is actually probably an even bigger win though. We have learnt that Faraday Technology is sprinkling silicon blocks all over any silicon foundries close to Taiwan. Their stuff appear to be in a lot of cheap routers, NAS etc. They use the number of successful deployments of the IP block as a selling point. I guess these guys are commonly called in to consult when kickstarting silicon design, simply. It turns out that this and other silicon vendors such as Grain Media, Andestech, Moschip etc are using the same silicon blocks, so a bunch of out-of-tree code is actually just duplicate implementations of Faraday drivers... we already merged Gemini and MoxaArt in the upstream kernel so we have a common interrupt chip, timer, PCI driver, and now this IDE/ATA driver (not the FTIDE200 yet though). So there is maybe not as much unique silicon in the world as we have come to think, we need to pay attention to how register maps look on different things. Yours, Linus Walleij
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; +};
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