* Re: three little req->errors follow ups
From: Jens Axboe @ 2017-04-26 13:54 UTC (permalink / raw)
To: Christoph Hellwig; +Cc: linux-ide, linux-scsi, linux-block
In-Reply-To: <20170426073422.14511-1-hch@lst.de>
On 04/26/2017 12:34 AM, Christoph Hellwig wrote:
> While moving forward with the block error work I noticed three more
> places that pass non-errno values to the end_request variants, and
> never actually check those return values. This little series fixes
> those up to always pass 0.
Applied, thanks.
--
Jens Axboe
^ permalink raw reply
* Re: [PATCH 2/3] ide-pm: always pass 0 error to __blk_end_request_all
From: David Miller @ 2017-04-26 14:39 UTC (permalink / raw)
To: hch; +Cc: axboe, linux-ide, linux-scsi, linux-block
In-Reply-To: <20170426073422.14511-3-hch@lst.de>
From: Christoph Hellwig <hch@lst.de>
Date: Wed, 26 Apr 2017 09:34:21 +0200
> ide_pm_execute_rq exectures a PM request synchronously, and in the failure
> case where it calls __blk_end_request_all it never checks the error field
> passed to the end_io callback, so don't bother setting it.
>
> Signed-off-by: Christoph Hellwig <hch@lst.de>
Acked-by: David S. Miller <davem@davemloft.net>
^ permalink raw reply
* Re: [PATCH 3/3] ide-pm: always pass 0 error to ide_complete_rq in ide_do_devset
From: David Miller @ 2017-04-26 14:39 UTC (permalink / raw)
To: hch; +Cc: axboe, linux-ide, linux-scsi, linux-block
In-Reply-To: <20170426073422.14511-4-hch@lst.de>
From: Christoph Hellwig <hch@lst.de>
Date: Wed, 26 Apr 2017 09:34:22 +0200
> The caller only looks at the scsi_request result field anyway.
>
> Signed-off-by: Christoph Hellwig <hch@lst.de>
Acked-by: David S. Miller <davem@davemloft.net>
^ permalink raw reply
* 14306 linux-ide
From: obsexitos @ 2017-04-28 6:17 UTC (permalink / raw)
To: linux-ide
[-- Attachment #1: 6.zip --]
[-- Type: application/zip, Size: 2805 bytes --]
^ permalink raw reply
* 56151 linux-ide
From: mitch_128 @ 2017-04-28 10:09 UTC (permalink / raw)
To: linux-ide
[-- Attachment #1: 29159603466.zip --]
[-- Type: application/zip, Size: 2876 bytes --]
^ permalink raw reply
* Re: PROBLEM: sil24: transfer errors causing data corruption or very low performance
From: Tejun Heo @ 2017-04-28 21:36 UTC (permalink / raw)
To: mtths; +Cc: linux-ide
In-Reply-To: <1605874.IPVSbxyx3P@c21>
Hello,
On Sat, Apr 22, 2017 at 05:33:56PM +0200, mtths@nurfuerspam.de wrote:
> A SATA PCI-controller card using the kernel module sata_sil24 has problems
> transferring big files.
>
>
> First of all a description of the situation:
>
> -- Hardware:
> - mainboard Gigabyte GA-MA69GM-S2H; chipset AMD 690G / SB600; 2 PCI slots
> (32 bit); 1 PCIe 4x slot; 1 PCIe 16 x slot; 8 GiB RAM; AMD Phenom(tm) II X4
> 955 Processor
> - SATA controller card Dawicontrol DC-3410 RAID, 32 bit PCI; chipset
> SiI3124ACBHU; BIOS message: running at 32 bit / 33 MHz
> - with hard disks: HDS721616PLA380 (twice), ST3000DM001-9YN166 (temporary)
> - q.v. attachment lspci; (dmidecode (v 3.0) finds no SMBIOS nor DMI entry
> point)
...
> 1st test setting:
> Reading from the disks to /dev/null with
> dd if=/dev/sde of=/dev/null bs=4k count=2304k
> one after the other. (Disk ST3000DM001 was temporarily directly connected to
> the card's external SATA port.)
> Result: After some MB, but before 470 MiB errors occurred:
> failed command: READ FPDMA QUEUED
> [cf. attachment dmesg]
> failed command: READ DMA
> [cf. attachment dmesg_tmpHD]
> The errors were reproducible - however, they started after different amounts
> of data.
>
> 2nd test setting:
> Using Debian's kernel and patching the driver to not use 64 bit DMA [cf.
> attachment sata_sil24.c.diff].
> Doing the same tests as above.
> Result: Repeatedly no errors occurred.
>
>
> N.B.: 1) There is a Windows Vista (32 bit) installation that uses two of the
> ports of the controller card as a fake RAID 1: There are no problems with the
> internal directly connected drives nor with an external drive.
> 2) Prior to this controller card there was a PCI Express card using SiI 3132,
> that - if I remember rightly - also had such problems, but they started after
> a greater amount of data. (At that time a Windows XP x64 installation had no
> problems, too.)
That's interesting, so you're seeing similar host bus errors whether
the controller is attached to PCI or PCIe.
The controller itself is known to be okay with 64bit addressing and
restricting it to 32bit addressing means that you'd be bouncing pages
(DMA to low pages and then copy using CPU), which slows down things a
bit. It could be that the slowing down in timing is what's helping,
not necessarily forcing 32bit DMA.
I don't know. Host bus errors are rarely reported and the controller
is definitely known to be okay with 64bit DMAs. Given this didn't get
reported at all in the haydays of SB600, it could actually be faulty
hardware.
I'm not sure what we can do at the moment.
Thanks.
--
tejun
^ permalink raw reply
* Re: [PATCH 0/3] SATA: Fine-tuning for two function implementations
From: Tejun Heo @ 2017-04-28 21:53 UTC (permalink / raw)
To: SF Markus Elfring; +Cc: linux-ide, Hans de Goede, LKML, kernel-janitors
In-Reply-To: <df754c7a-2100-7169-0d40-b981ccd952a1@users.sourceforge.net>
Hello,
On Tue, Apr 18, 2017 at 10:00:37PM +0200, SF Markus Elfring wrote:
> From: Markus Elfring <elfring@users.sourceforge.net>
> Date: Tue, 18 Apr 2017 21:54:32 +0200
>
> A few update suggestions were taken into account
> from static source code analysis.
Hmmm, allocs -> callocs. Are these actually beneficial? If so, why?
Because one multiplication is rolled into the call?
Thanks.
--
tejun
^ permalink raw reply
* Re: [PATCH] libata: reject passthrough WRITE SAME requests
From: Tejun Heo @ 2017-04-28 22:09 UTC (permalink / raw)
To: Christoph Hellwig; +Cc: linux-ide, stable
In-Reply-To: <20170425113954.23121-1-hch@lst.de>
On Tue, Apr 25, 2017 at 01:39:54PM +0200, Christoph Hellwig wrote:
> The WRITE SAME to TRIM translation rewrites the DATA OUT buffer. While
> the SCSI code accomodates for this by passing a read-writable buffer
> userspace applications don't cater for this behavior. In fact it can
> be used to rewrite e.g. a readonly file through mmap and should be
> considered as a security fix.
>
> Signed-off-by: Christoph Hellwig <hch@lst.de>
> Cc: stable@vger.kernel.org
Applied to libata/for-4.12, assuming we aren't doing rc9.
Thanks.
--
tejun
^ permalink raw reply
* Re: [PATCH] libata: remove SCT WRITE SAME support
From: Tejun Heo @ 2017-04-28 22:10 UTC (permalink / raw)
To: Christoph Hellwig; +Cc: linux-ide
In-Reply-To: <20170425122652.31763-1-hch@lst.de>
On Tue, Apr 25, 2017 at 02:26:52PM +0200, Christoph Hellwig wrote:
> This was already disabled a while ago because it caused I/O errors,
> and it's severly getting into the way of the discard / write zeroes
> rework.
>
> Signed-off-by: Christoph Hellwig <hch@lst.de>
Applied to libata/for-4.12.
Thanks.
--
tejun
^ permalink raw reply
* Re: SATA: Fine-tuning for two function implementations
From: SF Markus Elfring @ 2017-04-29 8:30 UTC (permalink / raw)
To: Tejun Heo; +Cc: linux-ide, Hans de Goede, LKML, kernel-janitors
In-Reply-To: <20170428215334.GH22354@htj.duckdns.org>
> Hmmm, allocs -> callocs. Are these actually beneficial? If so, why?
> Because one multiplication is rolled into the call?
Did the previous size calculations contain the general possibility for
integer overflows?
https://cwe.mitre.org/data/definitions/190.html
* Will the computed values usually stay within the limits of the used
data types so far?
* How much do you care for corresponding checks and source code annotations
by functions like “devm_kcalloc”?
Regards,
Markus
^ permalink raw reply
* [GIT PULL] libata changes for v4.12-rc1
From: Tejun Heo @ 2017-05-01 19:50 UTC (permalink / raw)
To: Linus Torvalds; +Cc: linux-kernel, linux-ide, Bartlomiej Zolnierkiewicz
Hello, Linus.
The biggest core change is removal of SCT WRITE SAME support, which
never worked properly. Other than that, trivial updates in core code
and specific embedded driver updates.
Thanks.
The following changes since commit c1ae3cfa0e89fa1a7ecc4c99031f5e9ae99d9201:
Linux 4.11-rc1 (2017-03-05 12:59:56 -0800)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/tj/libata.git for-4.12
for you to fetch changes up to 63ccc191649eb0f14a761074291551d0d2f85389:
libata: remove SCT WRITE SAME support (2017-04-28 18:09:59 -0400)
----------------------------------------------------------------
Bartlomiej Zolnierkiewicz (1):
ata: allow subsystem to be used on m32r and s390 archs
Bartosz Golaszewski (2):
ata: ahci: add support for DaVinci DM816 SATA controller
dt-bindings: ata: add DT bindings for ahci-dm816 SATA controller
Belen Sarabia (1):
Delete redundant return value check of platform_get_resource()
Bhumika Goyal (1):
ata: constify of_device_id structures
Boris Brezillon (1):
pata: remove the at91 driver
Christoph Hellwig (2):
libata: reject passthrough WRITE SAME requests
libata: remove SCT WRITE SAME support
Geliang Tang (1):
libata: use setup_deferrable_timer
Jason Yan (1):
libata: make ata_sg_clean static over again
.../devicetree/bindings/ata/ahci-dm816.txt | 21 +
drivers/ata/Kconfig | 18 +-
drivers/ata/Makefile | 2 +-
drivers/ata/ahci_dm816.c | 200 ++++++++
drivers/ata/ahci_octeon.c | 5 -
drivers/ata/libata-core.c | 8 +-
drivers/ata/libata-scsi.c | 140 ++----
drivers/ata/pata_at91.c | 503 ---------------------
drivers/ata/pata_macio.c | 2 +-
drivers/ata/pata_mpc52xx.c | 2 +-
drivers/ata/pata_of_platform.c | 2 +-
drivers/ata/sata_fsl.c | 2 +-
drivers/ata/sata_mv.c | 2 +-
include/linux/ata.h | 5 -
14 files changed, 277 insertions(+), 635 deletions(-)
create mode 100644 Documentation/devicetree/bindings/ata/ahci-dm816.txt
create mode 100644 drivers/ata/ahci_dm816.c
delete mode 100644 drivers/ata/pata_at91.c
--
tejun
^ permalink raw reply
* [PATCH] ata-sff: always map page before data transfer
From: Tycho Andersen @ 2017-05-02 16:29 UTC (permalink / raw)
To: Tejun Heo, Juerg Haefliger
Cc: linux-ide, linux-kernel, kernel-hardening, Tycho Andersen
The XPFO [1] patchset may unmap pages from physmap if they happened to be
destined for userspace. If such a page is unmapped, it needs to be
remapped. Rather than test if a page is in the highmem/xpfo unmapped state,
Christoph suggested [2] that we simply always map the page.
Suggested-by: Christoph Hellwig <hch@infradead.org>
Signed-off-by: Tycho Andersen <tycho@docker.com>
CC: Juerg Haefliger <juerg.haefliger@hpe.com>
CC: Tejun Heo <tj@kernel.org>
[1]: https://lkml.org/lkml/2016/11/4/245
[2]: https://lkml.org/lkml/2016/11/4/253
---
I don't understand all the factors at play here, so thoughts are definitely
welcome.
---
drivers/ata/libata-sff.c | 50 +++++++++++++++++-------------------------------
1 file changed, 18 insertions(+), 32 deletions(-)
diff --git a/drivers/ata/libata-sff.c b/drivers/ata/libata-sff.c
index 2bd92dc..8da2572 100644
--- a/drivers/ata/libata-sff.c
+++ b/drivers/ata/libata-sff.c
@@ -703,6 +703,7 @@ static void ata_pio_sector(struct ata_queued_cmd *qc)
struct page *page;
unsigned int offset;
unsigned char *buf;
+ unsigned long flags;
if (qc->curbytes == qc->nbytes - qc->sect_size)
ap->hsm_task_state = HSM_ST_LAST;
@@ -716,24 +717,16 @@ static void ata_pio_sector(struct ata_queued_cmd *qc)
DPRINTK("data %s\n", qc->tf.flags & ATA_TFLAG_WRITE ? "write" : "read");
- if (PageHighMem(page)) {
- unsigned long flags;
-
- /* FIXME: use a bounce buffer */
- local_irq_save(flags);
- buf = kmap_atomic(page);
+ /* FIXME: use a bounce buffer */
+ local_irq_save(flags);
+ buf = kmap_atomic(page);
- /* do the actual data transfer */
- ap->ops->sff_data_xfer(qc, buf + offset, qc->sect_size,
- do_write);
+ /* do the actual data transfer */
+ ap->ops->sff_data_xfer(qc, buf + offset, qc->sect_size,
+ do_write);
- kunmap_atomic(buf);
- local_irq_restore(flags);
- } else {
- buf = page_address(page);
- ap->ops->sff_data_xfer(qc, buf + offset, qc->sect_size,
- do_write);
- }
+ kunmap_atomic(buf);
+ local_irq_restore(flags);
if (!do_write && !PageSlab(page))
flush_dcache_page(page);
@@ -836,6 +829,7 @@ static int __atapi_pio_bytes(struct ata_queued_cmd *qc, unsigned int bytes)
struct page *page;
unsigned char *buf;
unsigned int offset, count, consumed;
+ unsigned long flags;
next_sg:
sg = qc->cursg;
@@ -861,24 +855,16 @@ static int __atapi_pio_bytes(struct ata_queued_cmd *qc, unsigned int bytes)
DPRINTK("data %s\n", qc->tf.flags & ATA_TFLAG_WRITE ? "write" : "read");
- if (PageHighMem(page)) {
- unsigned long flags;
-
- /* FIXME: use bounce buffer */
- local_irq_save(flags);
- buf = kmap_atomic(page);
+ /* FIXME: use bounce buffer */
+ local_irq_save(flags);
+ buf = kmap_atomic(page);
- /* do the actual data transfer */
- consumed = ap->ops->sff_data_xfer(qc, buf + offset,
- count, rw);
+ /* do the actual data transfer */
+ consumed = ap->ops->sff_data_xfer(qc, buf + offset,
+ count, rw);
- kunmap_atomic(buf);
- local_irq_restore(flags);
- } else {
- buf = page_address(page);
- consumed = ap->ops->sff_data_xfer(qc, buf + offset,
- count, rw);
- }
+ kunmap_atomic(buf);
+ local_irq_restore(flags);
bytes -= min(bytes, consumed);
qc->curbytes += count;
--
2.9.3
^ permalink raw reply related
* Re:
From: H.A @ 2017-05-03 6:23 UTC (permalink / raw)
To: Recipients
With profound love in my heart, I Kindly Oblige your interest to very important proposal.. It is Truly Divine and require your utmost attention..........
S hlubokou láskou v mém srdci, Laskave jsem prinutit svuj zájem k návrhu .. Je velmi duležité, skutecne Divine a vyžadují vaši nejvyšší pozornost.
Kontaktujte me prímo pres: helenaroberts99@gmail.com pro úplné podrobnosti.complete.
HELINA .A ROBERTS
---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus
^ permalink raw reply
* Re: [PATCH] ata-sff: always map page before data transfer
From: Christoph Hellwig @ 2017-05-04 9:51 UTC (permalink / raw)
To: Tycho Andersen
Cc: Tejun Heo, Juerg Haefliger, linux-ide, linux-kernel,
kernel-hardening
In-Reply-To: <20170502162932.12578-1-tycho@docker.com>
> I don't understand all the factors at play here, so thoughts are definitely
> welcome.
I don't fully understand the old code either. One thing that is weird
is the "use a bounce buffer comment" which doesn't make any sense.
The other is the local_irq_save, which isn't really needed for
kmap_atomic to start with, but maybe that's the reason why the original
author didn't want to do it unconditionally?
So based on that:
> + /* FIXME: use a bounce buffer */
drop this comment..
> + local_irq_save(flags);
.. remove the local_irq_save/local_irq_restore ..
> + /* do the actual data transfer */
> + ap->ops->sff_data_xfer(qc, buf + offset, qc->sect_size,
> + do_write);
.. and a nice alittle cleanup move the do_write onto the previous line.
> + /* FIXME: use bounce buffer */
> + local_irq_save(flags);
> + buf = kmap_atomic(page);
>
> + /* do the actual data transfer */
> + consumed = ap->ops->sff_data_xfer(qc, buf + offset,
> + count, rw);
And same here.
And we should be fine.
^ permalink raw reply
* RE: Donation Award
From: Mayrhofer Family @ 2017-05-04 11:16 UTC (permalink / raw)
To: Recipients
Good Day,
My wife and I have awarded you with a donation of $ 1,000,000.00 Dollars from part of our Jackpot Lottery of 50 Million Dollars, respond with your details for claims.
We await your earliest response and God Bless you.
Friedrich And Annand Mayrhofer.
---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus
^ permalink raw reply
* [PATCH v2] ata-sff: always map page before data transfer
From: Tycho Andersen @ 2017-05-04 22:15 UTC (permalink / raw)
To: Tejun Heo, Juerg Haefliger
Cc: Christoph Hellwig, linux-ide, linux-kernel, kernel-hardening,
Tycho Andersen
The XPFO [1] patchset may unmap pages from physmap if they happened to be
destined for userspace. If such a page is unmapped, it needs to be
remapped. Rather than test if a page is in the highmem/xpfo unmapped state,
Christoph suggested [2] that we simply always map the page.
v2: * drop comment about bounce buffer
* don't save IRQs before kmap/unmap
* formatting
Suggested-by: Christoph Hellwig <hch@infradead.org>
Signed-off-by: Tycho Andersen <tycho@docker.com>
CC: Juerg Haefliger <juerg.haefliger@hpe.com>
CC: Tejun Heo <tj@kernel.org>
[1]: https://lkml.org/lkml/2016/11/4/245
[2]: https://lkml.org/lkml/2016/11/4/253
---
v1: https://lkml.org/lkml/2017/5/2/404
---
drivers/ata/libata-sff.c | 44 ++++++++------------------------------------
1 file changed, 8 insertions(+), 36 deletions(-)
diff --git a/drivers/ata/libata-sff.c b/drivers/ata/libata-sff.c
index 2bd92dca3e62..01cf07c919bc 100644
--- a/drivers/ata/libata-sff.c
+++ b/drivers/ata/libata-sff.c
@@ -716,24 +716,10 @@ static void ata_pio_sector(struct ata_queued_cmd *qc)
DPRINTK("data %s\n", qc->tf.flags & ATA_TFLAG_WRITE ? "write" : "read");
- if (PageHighMem(page)) {
- unsigned long flags;
-
- /* FIXME: use a bounce buffer */
- local_irq_save(flags);
- buf = kmap_atomic(page);
-
- /* do the actual data transfer */
- ap->ops->sff_data_xfer(qc, buf + offset, qc->sect_size,
- do_write);
-
- kunmap_atomic(buf);
- local_irq_restore(flags);
- } else {
- buf = page_address(page);
- ap->ops->sff_data_xfer(qc, buf + offset, qc->sect_size,
- do_write);
- }
+ /* do the actual data transfer */
+ buf = kmap_atomic(page);
+ ap->ops->sff_data_xfer(qc, buf + offset, qc->sect_size, do_write);
+ kunmap_atomic(buf);
if (!do_write && !PageSlab(page))
flush_dcache_page(page);
@@ -861,24 +847,10 @@ static int __atapi_pio_bytes(struct ata_queued_cmd *qc, unsigned int bytes)
DPRINTK("data %s\n", qc->tf.flags & ATA_TFLAG_WRITE ? "write" : "read");
- if (PageHighMem(page)) {
- unsigned long flags;
-
- /* FIXME: use bounce buffer */
- local_irq_save(flags);
- buf = kmap_atomic(page);
-
- /* do the actual data transfer */
- consumed = ap->ops->sff_data_xfer(qc, buf + offset,
- count, rw);
-
- kunmap_atomic(buf);
- local_irq_restore(flags);
- } else {
- buf = page_address(page);
- consumed = ap->ops->sff_data_xfer(qc, buf + offset,
- count, rw);
- }
+ /* do the actual data transfer */
+ buf = kmap_atomic(page);
+ consumed = ap->ops->sff_data_xfer(qc, buf + offset, count, rw);
+ kunmap_atomic(buf);
bytes -= min(bytes, consumed);
qc->curbytes += count;
--
2.11.0
^ permalink raw reply related
* Re: [PATCH] ata-sff: always map page before data transfer
From: Tycho Andersen @ 2017-05-04 22:18 UTC (permalink / raw)
To: Christoph Hellwig
Cc: Tejun Heo, Juerg Haefliger, linux-ide, linux-kernel,
kernel-hardening
In-Reply-To: <20170504095134.GA14372@infradead.org>
On Thu, May 04, 2017 at 02:51:34AM -0700, Christoph Hellwig wrote:
> And we should be fine.
Great, I just sent a v2. Thanks!
Tycho
^ permalink raw reply
* Re: [PATCH v2] ata-sff: always map page before data transfer
From: Christoph Hellwig @ 2017-05-05 6:31 UTC (permalink / raw)
To: Tycho Andersen
Cc: Tejun Heo, Juerg Haefliger, Christoph Hellwig, linux-ide,
linux-kernel, kernel-hardening
In-Reply-To: <20170504221551.6458-1-tycho@docker.com>
Looks good,
Reviewed-by: Christoph Hellwig <hch@lst.de>
^ permalink raw reply
* Re: [PATCH v2] ata-sff: always map page before data transfer
From: Tejun Heo @ 2017-05-05 16:16 UTC (permalink / raw)
To: Tycho Andersen
Cc: Juerg Haefliger, Christoph Hellwig, linux-ide, linux-kernel,
kernel-hardening
In-Reply-To: <20170504221551.6458-1-tycho@docker.com>
On Thu, May 04, 2017 at 04:15:51PM -0600, Tycho Andersen wrote:
> The XPFO [1] patchset may unmap pages from physmap if they happened to be
> destined for userspace. If such a page is unmapped, it needs to be
> remapped. Rather than test if a page is in the highmem/xpfo unmapped state,
> Christoph suggested [2] that we simply always map the page.
>
> v2: * drop comment about bounce buffer
> * don't save IRQs before kmap/unmap
> * formatting
>
> Suggested-by: Christoph Hellwig <hch@infradead.org>
> Signed-off-by: Tycho Andersen <tycho@docker.com>
> CC: Juerg Haefliger <juerg.haefliger@hpe.com>
> CC: Tejun Heo <tj@kernel.org>
>
> [1]: https://lkml.org/lkml/2016/11/4/245
> [2]: https://lkml.org/lkml/2016/11/4/253
Yeah, it's a nice cleanup.
Applied to libata/for-4.13.
Thanks.
--
tejun
^ permalink raw reply
* [PATCH 1/4] ata: Add DT bindings for Faraday Technology FTIDE010
From: Linus Walleij @ 2017-05-06 12:10 UTC (permalink / raw)
To: Tejun Heo, Bartlomiej Zolnierkiewicz, linux-ide
Cc: openwrt-devel, devicetree, John Feng-Hsin Chiang,
Paulius Zaleckas, Greentime Hu, Janos Laube, linux-arm-kernel
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.
+- faraday,mdma-66-recovery-time: array of 4 elements for Tk timing for
+ multi word DMA, Mode 0, 1 and 2 at 50 MHz. Range 0..15.
+- faraday,udma-50-setup-time: array of 4 elements for Tvds timing for ultra
+ DMA, Mode 0, 1, 2, 3, 4 and 5 at 50 MHz. Range 0..7.
+- faraday,udma-50-hold-time: array of 4 elements for Tdvh timing for
+ multi word DMA, Mode 0, 1, 2, 3, 4 and 5 at 50 MHz, Range 0..7.
+- faraday,udma-66-setup-time: array of 4 elements for Tvds timing for multi
+ word DMA, Mode 0, 1, 2, 3, 4, 5 and 6 at 50 MHz. Range 0..7.
+- faraday,udma-66-hold-time: array of 4 elements for Tdvh timing for
+ multi word DMA, Mode 0, 1, 2, 3, 4, 5 and 6 at 50 MHz. Range 0..7.
+
+Optional properties:
+- clocks: a SoC clock running the peripheral.
+- clock-names: should be set to "PCLK" for the peripheral clock.
+
+Required properties for "cortina,gemini-pata" compatible:
+- sata: a phande to the Gemini PATA to SATA bridge, see
+ cortina,gemini-sata-bridge.txt for details.
+
+Example:
+
+ata@63000000 {
+ compatible = "cortina,gemini-pata", "faraday,ftide010";
+ reg = <0x63000000 0x100>;
+ interrupts = <4 IRQ_TYPE_EDGE_RISING>;
+ clocks = <&gcc GEMINI_CLK_GATE_IDE>;
+ clock-names = "PCLK";
+ sata = <&sata>;
+};
--
2.9.3
_______________________________________________
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
^ 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
* [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 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
* 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
* 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
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