* PLEASE VIEW THE ATTACHED FILE AND CONTACT ME.
From: Dr. Felix Collins @ 2016-11-14 7:43 UTC (permalink / raw)
In-Reply-To: <1666584935.3489547.1479109399212.ref@mail.yahoo.com>
[-- Attachment #1: Type: text/plain, Size: 1 bytes --]
[-- Attachment #2: FROM FIRST NATIONAL BANK OF SOUTH AFRICA (F.N.B)..rtf --]
[-- Type: application/msword, Size: 3007 bytes --]
^ permalink raw reply
* 42805 linux-ide
From: lucia.germino @ 2016-11-12 14:28 UTC (permalink / raw)
To: linux-ide
[-- Attachment #1: MESSAGE_47440230_linux-ide.zip --]
[-- Type: application/zip, Size: 3845 bytes --]
^ permalink raw reply
* Re: [PATCH] ata: xgene: Enable NCQ support for APM X-Gene SATA controller hardware v1.1
From: Rameshwar Sahu @ 2016-11-11 8:06 UTC (permalink / raw)
To: Tejun Heo
Cc: Olof Johansson, linux-scsi-u79uwXL29TY76Z2rM5mHXA,
linux-ide-u79uwXL29TY76Z2rM5mHXA, Devicetree List, linux-arm,
Don Dutile, Jon Masters, patches
In-Reply-To: <20161109164531.GA14630-piEFEHQLUPpN0TnZuCh8vA@public.gmane.org>
Hi Tejun,
On Wed, Nov 9, 2016 at 10:15 PM, Tejun Heo <tj-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org> wrote:
> Hello,
>
> On Wed, Sep 14, 2016 at 04:15:00PM +0530, Rameshwar Sahu wrote:
>> > @@ -821,8 +823,6 @@ static int xgene_ahci_probe(struct platform_device
>> > *pdev)
>> > dev_warn(&pdev->dev, "%s: Error reading
>> > device info. Assume version1\n",
>> > __func__);
>> > version = XGENE_AHCI_V1;
>> > - } else if (info->valid & ACPI_VALID_CID) {
>> > - version = XGENE_AHCI_V2;
>
> Can you please explain this part a bit? Everything else looks good to
> me.
Here we should not assume XGENE_AHCI_V2 always in case of having valid
_CID in ACPI table.
I need to remove this assumption because V1_1 has also valid _CID for
backward compatibly with v1.
>
> Thanks.
>
> --
> tejun
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH 3/4] pata: imx: add support of setting timings for PIO modes
From: Tejun Heo @ 2016-11-10 16:10 UTC (permalink / raw)
To: Vladimir Zapolskiy; +Cc: Sergei Shtylyov, Bartlomiej Zolnierkiewicz, linux-ide
In-Reply-To: <ed9bacd7-b6f4-811b-c082-ae4235a747c6@mleia.com>
Hello, Vladimir, Sergei.
On Thu, Nov 10, 2016 at 03:33:22AM +0200, Vladimir Zapolskiy wrote:
> thank you for review, I see that Tejun has applied the changes,
> anyway I'll answer your questions.
Oh, please submit incremental patches as necessary.
> > > @@ -31,6 +40,10 @@
> > > #define PATA_IMX_DRIVE_DATA 0xA0
> > > #define PATA_IMX_DRIVE_CONTROL 0xD8
> > >
> > > +static u32 pio_t4[] = { 30, 20, 15, 10, 10 };
> > > +static u32 pio_t9[] = { 20, 15, 10, 10, 10 };
> > > +static u32 pio_tA[] = { 35, 35, 35, 35, 35 };
> >
> > Perhaps it makes sense to extend the 'struct ata_timing'...
> >
> > [...]
>
> As you guess the numbers are taken right from the ATAPI spec,
> however I haven't found the second ATA controller driver sumbitted
> upstream, which reuses these timings, so probably generalization
> is not needed here. Anyway I would prefer if maintainers do it,
> if they think that it makes sense.
Given that its usage isn't likely to be further expanded, I don't
think it matters that much either way, but it does make sense to put
them in ata_timing. I'd be happy to apply such a patch.
> > What do those registers mean?
>
> You may find a better description from i.MX27 or i.MX31 Reference Manual
> than my retelling, the docs are open.
>
> toff/ton timings are used to avoid bus contention when switching
> BUFFER_EN signal and data writing period. AFAIK these timings are
> specific to the controller only.
>
> > > + writeb(timing.setup, priv->host_regs + PATA_IMX_ATA_TIME_1);
> > > + writeb(timing.act8b, priv->host_regs + PATA_IMX_ATA_TIME_2W);
> > > + writeb(timing.act8b, priv->host_regs + PATA_IMX_ATA_TIME_2R);
> > > + writeb(1, priv->host_regs + PATA_IMX_ATA_TIME_PIO_RDX);
> >
> > And this one?
>
> This is trd timing from the ATA/ATAPI spec, "Read Data Valid to IORDY
> active", its minimal value is defined as 0.
Add comments for these explanations maybe?
> > > +
> > > + writeb(pio_t4[mode] / T + 1, priv->host_regs + PATA_IMX_ATA_TIME_4);
> > > + writeb(pio_t9[mode] / T + 1, priv->host_regs + PATA_IMX_ATA_TIME_9);
> > > + writeb(pio_tA[mode] / T + 1, priv->host_regs +
> > > PATA_IMX_ATA_TIME_AX);
> >
> > DIV_ROUND_UP(x, T)?
>
> Yes, it is reasonable.
And also for this cleanup?
Thanks.
--
tejun
^ permalink raw reply
* Re: [PATCH 3/4] pata: imx: add support of setting timings for PIO modes
From: Vladimir Zapolskiy @ 2016-11-10 1:33 UTC (permalink / raw)
To: Sergei Shtylyov; +Cc: Tejun Heo, Bartlomiej Zolnierkiewicz, linux-ide
In-Reply-To: <23fb0678-db2a-a0ff-65a3-3174720b0ee8@cogentembedded.com>
Hi Sergei,
thank you for review, I see that Tejun has applied the changes,
anyway I'll answer your questions.
On 11/09/2016 11:39 AM, Sergei Shtylyov wrote:
> Hello.
>
> On 11/9/2016 3:56 AM, Vladimir Zapolskiy wrote:
>
>> The controller is capable to operate in up to PIO4 mode, however
>> before the change the driver relies on timing settings done by
>> a bootloader for PIO0 mode only. The change adds more flexibility
>> in PIO mode selection at runtime and makes the driver to work even if
> ^^ not needed
>
>> bootloader does not preset ATA timings.
>>
>> Signed-off-by: Vladimir Zapolskiy <vz@mleia.com>
>> ---
>> drivers/ata/pata_imx.c | 47
>> ++++++++++++++++++++++++++++++++++++++++++++++-
>> 1 file changed, 46 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/ata/pata_imx.c b/drivers/ata/pata_imx.c
>> index 00df18b..8f13c9f 100644
>> --- a/drivers/ata/pata_imx.c
>> +++ b/drivers/ata/pata_imx.c
> [...]
>> @@ -31,6 +40,10 @@
>> #define PATA_IMX_DRIVE_DATA 0xA0
>> #define PATA_IMX_DRIVE_CONTROL 0xD8
>>
>> +static u32 pio_t4[] = { 30, 20, 15, 10, 10 };
>> +static u32 pio_t9[] = { 20, 15, 10, 10, 10 };
>> +static u32 pio_tA[] = { 35, 35, 35, 35, 35 };
>
> Perhaps it makes sense to extend the 'struct ata_timing'...
>
> [...]
As you guess the numbers are taken right from the ATAPI spec,
however I haven't found the second ATA controller driver sumbitted
upstream, which reuses these timings, so probably generalization
is not needed here. Anyway I would prefer if maintainers do it,
if they think that it makes sense.
>> @@ -38,11 +51,43 @@ struct pata_imx_priv {
>> u32 ata_ctl;
>> };
>>
>> +static void pata_imx_set_timing(struct ata_device *adev,
>> + struct pata_imx_priv *priv)
>> +{
>> + struct ata_timing timing;
>> + unsigned long clkrate;
>> + u32 T, mode;
>> +
>> + clkrate = clk_get_rate(priv->clk);
>> +
>> + if (adev->pio_mode < XFER_PIO_0 || adev->pio_mode > XFER_PIO_4 ||
>> + !clkrate)
>> + return;
>> +
>> + T = 1000000000 / clkrate;
>> + ata_timing_compute(adev, adev->pio_mode, &timing, T * 1000, 0);
>> +
>> + mode = adev->pio_mode - XFER_PIO_0;
>> +
>> + writeb(3, priv->host_regs + PATA_IMX_ATA_TIME_OFF);
>> + writeb(3, priv->host_regs + PATA_IMX_ATA_TIME_ON);
>
> What do those registers mean?
You may find a better description from i.MX27 or i.MX31 Reference Manual
than my retelling, the docs are open.
toff/ton timings are used to avoid bus contention when switching
BUFFER_EN signal and data writing period. AFAIK these timings are
specific to the controller only.
>> + writeb(timing.setup, priv->host_regs + PATA_IMX_ATA_TIME_1);
>> + writeb(timing.act8b, priv->host_regs + PATA_IMX_ATA_TIME_2W);
>> + writeb(timing.act8b, priv->host_regs + PATA_IMX_ATA_TIME_2R);
>> + writeb(1, priv->host_regs + PATA_IMX_ATA_TIME_PIO_RDX);
>
> And this one?
This is trd timing from the ATA/ATAPI spec, "Read Data Valid to IORDY
active", its minimal value is defined as 0.
>> +
>> + writeb(pio_t4[mode] / T + 1, priv->host_regs + PATA_IMX_ATA_TIME_4);
>> + writeb(pio_t9[mode] / T + 1, priv->host_regs + PATA_IMX_ATA_TIME_9);
>> + writeb(pio_tA[mode] / T + 1, priv->host_regs +
>> PATA_IMX_ATA_TIME_AX);
>
> DIV_ROUND_UP(x, T)?
Yes, it is reasonable.
--
With best wishes,
Vladimir
^ permalink raw reply
* Re: [PATCH 0/4] pata: imx: set timings for PIO modes up to PIO4
From: Tejun Heo @ 2016-11-09 16:49 UTC (permalink / raw)
To: Vladimir Zapolskiy; +Cc: Bartlomiej Zolnierkiewicz, linux-ide
In-Reply-To: <20161109005638.17691-1-vz@mleia.com>
On Wed, Nov 09, 2016 at 02:56:34AM +0200, Vladimir Zapolskiy wrote:
> The changeset adds support of PIO modes up to PIO4 by setting
> necessary timings in the driver, before the change it is assumed
> that the timings are always set by a bootloader once and thus
> only one possible PIO mode has been supported (PIO0). With
> this change the driver can be used on boards without ATA controller
> configuration done by a bootloader.
>
> The change is tested on a legacy i.MX31 board with an HDD connected
> by a 40-pin flat cable.
Applied to libata/for-4.10.
Thanks.
--
tejun
^ permalink raw reply
* Re: [PATCH] ata: xgene: Enable NCQ support for APM X-Gene SATA controller hardware v1.1
From: Tejun Heo @ 2016-11-09 16:45 UTC (permalink / raw)
To: Rameshwar Sahu
Cc: Olof Johansson, linux-scsi, linux-ide, Devicetree List, linux-arm,
ddutile, Jon Masters, patches
In-Reply-To: <CAFd313x-mXpy0N3aKx2rfoag1FNOrN-LzKb5UHkY2L+GGc0B-A@mail.gmail.com>
Hello,
On Wed, Sep 14, 2016 at 04:15:00PM +0530, Rameshwar Sahu wrote:
> > @@ -821,8 +823,6 @@ static int xgene_ahci_probe(struct platform_device
> > *pdev)
> > dev_warn(&pdev->dev, "%s: Error reading
> > device info. Assume version1\n",
> > __func__);
> > version = XGENE_AHCI_V1;
> > - } else if (info->valid & ACPI_VALID_CID) {
> > - version = XGENE_AHCI_V2;
Can you please explain this part a bit? Everything else looks good to
me.
Thanks.
--
tejun
^ permalink raw reply
* Re: [PATCH] ata: xgene: Enable NCQ support for APM X-Gene SATA controller hardware v1.1
From: Rameshwar Sahu @ 2016-11-09 11:39 UTC (permalink / raw)
To: Olof Johansson, tj, Arnd Bergmann
Cc: Devicetree List, mlangsdo, linux-scsi, Jon Masters,
Rameshwar Prasad Sahu, patches, linux-ide, linux-arm
In-Reply-To: <1476962064-8775-1-git-send-email-rsahu@apm.com>
Hi Olof/Tejun,
On Thu, Oct 20, 2016 at 4:44 PM, Rameshwar Prasad Sahu <rsahu@apm.com> wrote:
>
> This patch enables NCQ support for APM X-Gene SATA controller
> hardware v1.1 that was broken with hardware v1.0.
>
> Signed-off-by: Rameshwar Prasad Sahu <rsahu@apm.com>
> ---
> drivers/ata/ahci_xgene.c | 14 ++++++++------
> 1 files changed, 8 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/ata/ahci_xgene.c b/drivers/ata/ahci_xgene.c
> index 73b19b2..8b88be9 100644
> --- a/drivers/ata/ahci_xgene.c
> +++ b/drivers/ata/ahci_xgene.c
> @@ -87,6 +87,7 @@
>
> enum xgene_ahci_version {
> XGENE_AHCI_V1 = 1,
> + XGENE_AHCI_V1_1,
> XGENE_AHCI_V2,
> };
>
> @@ -734,6 +735,7 @@ static struct scsi_host_template ahci_platform_sht = {
> #ifdef CONFIG_ACPI
> static const struct acpi_device_id xgene_ahci_acpi_match[] = {
> { "APMC0D0D", XGENE_AHCI_V1},
> + { "APMC0D67", XGENE_AHCI_V1_1},
> { "APMC0D32", XGENE_AHCI_V2},
> {},
> };
> @@ -742,6 +744,7 @@ MODULE_DEVICE_TABLE(acpi, xgene_ahci_acpi_match);
>
> static const struct of_device_id xgene_ahci_of_match[] = {
> {.compatible = "apm,xgene-ahci", .data = (void *) XGENE_AHCI_V1},
> + {.compatible = "apm,xgene-ahci-v1-1", .data = (void *) XGENE_AHCI_V1_1},
> {.compatible = "apm,xgene-ahci-v2", .data = (void *) XGENE_AHCI_V2},
> {},
> };
> @@ -755,8 +758,7 @@ static int xgene_ahci_probe(struct platform_device *pdev)
> struct resource *res;
> const struct of_device_id *of_devid;
> enum xgene_ahci_version version = XGENE_AHCI_V1;
> - const struct ata_port_info *ppi[] = { &xgene_ahci_v1_port_info,
> - &xgene_ahci_v2_port_info };
> + const struct ata_port_info *ppi;
> int rc;
>
> hpriv = ahci_platform_get_resources(pdev);
> @@ -821,8 +823,6 @@ static int xgene_ahci_probe(struct platform_device *pdev)
> dev_warn(&pdev->dev, "%s: Error reading device info. Assume version1\n",
> __func__);
> version = XGENE_AHCI_V1;
> - } else if (info->valid & ACPI_VALID_CID) {
> - version = XGENE_AHCI_V2;
> }
> }
> }
> @@ -858,18 +858,20 @@ skip_clk_phy:
>
> switch (version) {
> case XGENE_AHCI_V1:
> + ppi = &xgene_ahci_v1_port_info;
> hpriv->flags = AHCI_HFLAG_NO_NCQ;
> break;
> case XGENE_AHCI_V2:
> + ppi = &xgene_ahci_v2_port_info;
> hpriv->flags |= AHCI_HFLAG_YES_FBS;
> hpriv->irq_handler = xgene_ahci_irq_intr;
> break;
> default:
> + ppi = &xgene_ahci_v1_port_info;
> break;
> }
>
> - rc = ahci_platform_init_host(pdev, hpriv, ppi[version - 1],
> - &ahci_platform_sht);
> + rc = ahci_platform_init_host(pdev, hpriv, ppi, &ahci_platform_sht);
> if (rc)
> goto disable_resources;
>
> --
> 1.7.1
Any comment on above patch ??
^ permalink raw reply
* 64002 linux-ide
From: lucia.germino @ 2016-11-09 9:40 UTC (permalink / raw)
To: linux-ide
[-- Attachment #1: MESSAGE_509122388_linux-ide.zip --]
[-- Type: application/zip, Size: 3258 bytes --]
^ permalink raw reply
* Re: [PATCH 3/4] pata: imx: add support of setting timings for PIO modes
From: Sergei Shtylyov @ 2016-11-09 9:39 UTC (permalink / raw)
To: Vladimir Zapolskiy, Tejun Heo, Bartlomiej Zolnierkiewicz; +Cc: linux-ide
In-Reply-To: <20161109005638.17691-4-vz@mleia.com>
Hello.
On 11/9/2016 3:56 AM, Vladimir Zapolskiy wrote:
> The controller is capable to operate in up to PIO4 mode, however
> before the change the driver relies on timing settings done by
> a bootloader for PIO0 mode only. The change adds more flexibility
> in PIO mode selection at runtime and makes the driver to work even if
^^ not needed
> bootloader does not preset ATA timings.
>
> Signed-off-by: Vladimir Zapolskiy <vz@mleia.com>
> ---
> drivers/ata/pata_imx.c | 47 ++++++++++++++++++++++++++++++++++++++++++++++-
> 1 file changed, 46 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/ata/pata_imx.c b/drivers/ata/pata_imx.c
> index 00df18b..8f13c9f 100644
> --- a/drivers/ata/pata_imx.c
> +++ b/drivers/ata/pata_imx.c
[...]
> @@ -31,6 +40,10 @@
> #define PATA_IMX_DRIVE_DATA 0xA0
> #define PATA_IMX_DRIVE_CONTROL 0xD8
>
> +static u32 pio_t4[] = { 30, 20, 15, 10, 10 };
> +static u32 pio_t9[] = { 20, 15, 10, 10, 10 };
> +static u32 pio_tA[] = { 35, 35, 35, 35, 35 };
Perhaps it makes sense to extend the 'struct ata_timing'...
[...]
> @@ -38,11 +51,43 @@ struct pata_imx_priv {
> u32 ata_ctl;
> };
>
> +static void pata_imx_set_timing(struct ata_device *adev,
> + struct pata_imx_priv *priv)
> +{
> + struct ata_timing timing;
> + unsigned long clkrate;
> + u32 T, mode;
> +
> + clkrate = clk_get_rate(priv->clk);
> +
> + if (adev->pio_mode < XFER_PIO_0 || adev->pio_mode > XFER_PIO_4 ||
> + !clkrate)
> + return;
> +
> + T = 1000000000 / clkrate;
> + ata_timing_compute(adev, adev->pio_mode, &timing, T * 1000, 0);
> +
> + mode = adev->pio_mode - XFER_PIO_0;
> +
> + writeb(3, priv->host_regs + PATA_IMX_ATA_TIME_OFF);
> + writeb(3, priv->host_regs + PATA_IMX_ATA_TIME_ON);
What do those registers mean?
> + writeb(timing.setup, priv->host_regs + PATA_IMX_ATA_TIME_1);
> + writeb(timing.act8b, priv->host_regs + PATA_IMX_ATA_TIME_2W);
> + writeb(timing.act8b, priv->host_regs + PATA_IMX_ATA_TIME_2R);
> + writeb(1, priv->host_regs + PATA_IMX_ATA_TIME_PIO_RDX);
And this one?
> +
> + writeb(pio_t4[mode] / T + 1, priv->host_regs + PATA_IMX_ATA_TIME_4);
> + writeb(pio_t9[mode] / T + 1, priv->host_regs + PATA_IMX_ATA_TIME_9);
> + writeb(pio_tA[mode] / T + 1, priv->host_regs + PATA_IMX_ATA_TIME_AX);
DIV_ROUND_UP(x, T)?
[...]
MBR, Sergei
^ permalink raw reply
* 30577 linux-ide
From: beautyink @ 2016-11-09 3:00 UTC (permalink / raw)
To: linux-ide
[-- Attachment #1: MESSAGE_599190573_linux-ide.zip --]
[-- Type: application/zip, Size: 3124 bytes --]
^ permalink raw reply
* [PATCH 4/4] pata: imx: support controller modes up to PIO4
From: Vladimir Zapolskiy @ 2016-11-09 0:56 UTC (permalink / raw)
To: Tejun Heo, Bartlomiej Zolnierkiewicz; +Cc: linux-ide
In-Reply-To: <20161109005638.17691-1-vz@mleia.com>
Having timing settings for all supported by the controller PIO modes
now it is possible to expand its PIO mask.
Signed-off-by: Vladimir Zapolskiy <vz@mleia.com>
---
drivers/ata/pata_imx.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/ata/pata_imx.c b/drivers/ata/pata_imx.c
index 8f13c9f..d4caa23 100644
--- a/drivers/ata/pata_imx.c
+++ b/drivers/ata/pata_imx.c
@@ -160,7 +160,7 @@ static int pata_imx_probe(struct platform_device *pdev)
ap = host->ports[0];
ap->ops = &pata_imx_port_ops;
- ap->pio_mask = ATA_PIO0;
+ ap->pio_mask = ATA_PIO4;
ap->flags |= ATA_FLAG_SLAVE_POSS;
io_res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
--
2.10.2
^ permalink raw reply related
* [PATCH 2/4] pata: imx: set controller PIO mode with .set_piomode callback
From: Vladimir Zapolskiy @ 2016-11-09 0:56 UTC (permalink / raw)
To: Tejun Heo, Bartlomiej Zolnierkiewicz; +Cc: linux-ide
In-Reply-To: <20161109005638.17691-1-vz@mleia.com>
Convert .set_mode callback function to more specific .set_piomode,
the driver does not have support of DMA modes, thus a simpler version
of the callback is preferred.
Signed-off-by: Vladimir Zapolskiy <vz@mleia.com>
---
drivers/ata/pata_imx.c | 27 ++++++++-------------------
1 file changed, 8 insertions(+), 19 deletions(-)
diff --git a/drivers/ata/pata_imx.c b/drivers/ata/pata_imx.c
index 203e309..00df18b 100644
--- a/drivers/ata/pata_imx.c
+++ b/drivers/ata/pata_imx.c
@@ -38,28 +38,17 @@ struct pata_imx_priv {
u32 ata_ctl;
};
-static int pata_imx_set_mode(struct ata_link *link, struct ata_device **unused)
+static void pata_imx_set_piomode(struct ata_port *ap, struct ata_device *adev)
{
- struct ata_device *dev;
- struct ata_port *ap = link->ap;
struct pata_imx_priv *priv = ap->host->private_data;
u32 val;
- ata_for_each_dev(dev, link, ENABLED) {
- dev->pio_mode = dev->xfer_mode = XFER_PIO_0;
- dev->xfer_shift = ATA_SHIFT_PIO;
- dev->flags |= ATA_DFLAG_PIO;
-
- val = __raw_readl(priv->host_regs + PATA_IMX_ATA_CONTROL);
- if (ata_pio_need_iordy(dev))
- val |= PATA_IMX_ATA_CTRL_IORDY_EN;
- else
- val &= ~PATA_IMX_ATA_CTRL_IORDY_EN;
- __raw_writel(val, priv->host_regs + PATA_IMX_ATA_CONTROL);
-
- ata_dev_info(dev, "configured for PIO\n");
- }
- return 0;
+ val = __raw_readl(priv->host_regs + PATA_IMX_ATA_CONTROL);
+ if (ata_pio_need_iordy(adev))
+ val |= PATA_IMX_ATA_CTRL_IORDY_EN;
+ else
+ val &= ~PATA_IMX_ATA_CTRL_IORDY_EN;
+ __raw_writel(val, priv->host_regs + PATA_IMX_ATA_CONTROL);
}
static struct scsi_host_template pata_imx_sht = {
@@ -70,7 +59,7 @@ static struct ata_port_operations pata_imx_port_ops = {
.inherits = &ata_sff_port_ops,
.sff_data_xfer = ata_sff_data_xfer_noirq,
.cable_detect = ata_cable_unknown,
- .set_mode = pata_imx_set_mode,
+ .set_piomode = pata_imx_set_piomode,
};
static void pata_imx_setup_port(struct ata_ioports *ioaddr)
--
2.10.2
^ permalink raw reply related
* [PATCH 3/4] pata: imx: add support of setting timings for PIO modes
From: Vladimir Zapolskiy @ 2016-11-09 0:56 UTC (permalink / raw)
To: Tejun Heo, Bartlomiej Zolnierkiewicz; +Cc: linux-ide
In-Reply-To: <20161109005638.17691-1-vz@mleia.com>
The controller is capable to operate in up to PIO4 mode, however
before the change the driver relies on timing settings done by
a bootloader for PIO0 mode only. The change adds more flexibility
in PIO mode selection at runtime and makes the driver to work even if
bootloader does not preset ATA timings.
Signed-off-by: Vladimir Zapolskiy <vz@mleia.com>
---
drivers/ata/pata_imx.c | 47 ++++++++++++++++++++++++++++++++++++++++++++++-
1 file changed, 46 insertions(+), 1 deletion(-)
diff --git a/drivers/ata/pata_imx.c b/drivers/ata/pata_imx.c
index 00df18b..8f13c9f 100644
--- a/drivers/ata/pata_imx.c
+++ b/drivers/ata/pata_imx.c
@@ -11,7 +11,6 @@
*
* TODO:
* - dmaengine support
- * - check if timing stuff needed
*/
#include <linux/ata.h>
@@ -22,6 +21,16 @@
#define DRV_NAME "pata_imx"
+#define PATA_IMX_ATA_TIME_OFF 0x00
+#define PATA_IMX_ATA_TIME_ON 0x01
+#define PATA_IMX_ATA_TIME_1 0x02
+#define PATA_IMX_ATA_TIME_2W 0x03
+#define PATA_IMX_ATA_TIME_2R 0x04
+#define PATA_IMX_ATA_TIME_AX 0x05
+#define PATA_IMX_ATA_TIME_PIO_RDX 0x06
+#define PATA_IMX_ATA_TIME_4 0x07
+#define PATA_IMX_ATA_TIME_9 0x08
+
#define PATA_IMX_ATA_CONTROL 0x24
#define PATA_IMX_ATA_CTRL_FIFO_RST_B (1<<7)
#define PATA_IMX_ATA_CTRL_ATA_RST_B (1<<6)
@@ -31,6 +40,10 @@
#define PATA_IMX_DRIVE_DATA 0xA0
#define PATA_IMX_DRIVE_CONTROL 0xD8
+static u32 pio_t4[] = { 30, 20, 15, 10, 10 };
+static u32 pio_t9[] = { 20, 15, 10, 10, 10 };
+static u32 pio_tA[] = { 35, 35, 35, 35, 35 };
+
struct pata_imx_priv {
struct clk *clk;
/* timings/interrupt/control regs */
@@ -38,11 +51,43 @@ struct pata_imx_priv {
u32 ata_ctl;
};
+static void pata_imx_set_timing(struct ata_device *adev,
+ struct pata_imx_priv *priv)
+{
+ struct ata_timing timing;
+ unsigned long clkrate;
+ u32 T, mode;
+
+ clkrate = clk_get_rate(priv->clk);
+
+ if (adev->pio_mode < XFER_PIO_0 || adev->pio_mode > XFER_PIO_4 ||
+ !clkrate)
+ return;
+
+ T = 1000000000 / clkrate;
+ ata_timing_compute(adev, adev->pio_mode, &timing, T * 1000, 0);
+
+ mode = adev->pio_mode - XFER_PIO_0;
+
+ writeb(3, priv->host_regs + PATA_IMX_ATA_TIME_OFF);
+ writeb(3, priv->host_regs + PATA_IMX_ATA_TIME_ON);
+ writeb(timing.setup, priv->host_regs + PATA_IMX_ATA_TIME_1);
+ writeb(timing.act8b, priv->host_regs + PATA_IMX_ATA_TIME_2W);
+ writeb(timing.act8b, priv->host_regs + PATA_IMX_ATA_TIME_2R);
+ writeb(1, priv->host_regs + PATA_IMX_ATA_TIME_PIO_RDX);
+
+ writeb(pio_t4[mode] / T + 1, priv->host_regs + PATA_IMX_ATA_TIME_4);
+ writeb(pio_t9[mode] / T + 1, priv->host_regs + PATA_IMX_ATA_TIME_9);
+ writeb(pio_tA[mode] / T + 1, priv->host_regs + PATA_IMX_ATA_TIME_AX);
+}
+
static void pata_imx_set_piomode(struct ata_port *ap, struct ata_device *adev)
{
struct pata_imx_priv *priv = ap->host->private_data;
u32 val;
+ pata_imx_set_timing(adev, priv);
+
val = __raw_readl(priv->host_regs + PATA_IMX_ATA_CONTROL);
if (ata_pio_need_iordy(adev))
val |= PATA_IMX_ATA_CTRL_IORDY_EN;
--
2.10.2
^ permalink raw reply related
* [PATCH 1/4] pata: imx: sort headers out
From: Vladimir Zapolskiy @ 2016-11-09 0:56 UTC (permalink / raw)
To: Tejun Heo, Bartlomiej Zolnierkiewicz; +Cc: linux-ide
In-Reply-To: <20161109005638.17691-1-vz@mleia.com>
Put headers in alphabetic order and remove redundant ones.
Signed-off-by: Vladimir Zapolskiy <vz@mleia.com>
---
drivers/ata/pata_imx.c | 8 +++-----
1 file changed, 3 insertions(+), 5 deletions(-)
diff --git a/drivers/ata/pata_imx.c b/drivers/ata/pata_imx.c
index 139d207..203e309 100644
--- a/drivers/ata/pata_imx.c
+++ b/drivers/ata/pata_imx.c
@@ -13,14 +13,12 @@
* - dmaengine support
* - check if timing stuff needed
*/
-#include <linux/kernel.h>
-#include <linux/module.h>
-#include <linux/blkdev.h>
-#include <scsi/scsi_host.h>
+
#include <linux/ata.h>
+#include <linux/clk.h>
#include <linux/libata.h>
+#include <linux/module.h>
#include <linux/platform_device.h>
-#include <linux/clk.h>
#define DRV_NAME "pata_imx"
--
2.10.2
^ permalink raw reply related
* [PATCH 0/4] pata: imx: set timings for PIO modes up to PIO4
From: Vladimir Zapolskiy @ 2016-11-09 0:56 UTC (permalink / raw)
To: Tejun Heo, Bartlomiej Zolnierkiewicz; +Cc: linux-ide
The changeset adds support of PIO modes up to PIO4 by setting
necessary timings in the driver, before the change it is assumed
that the timings are always set by a bootloader once and thus
only one possible PIO mode has been supported (PIO0). With
this change the driver can be used on boards without ATA controller
configuration done by a bootloader.
The change is tested on a legacy i.MX31 board with an HDD connected
by a 40-pin flat cable.
Vladimir Zapolskiy (4):
pata: imx: sort headers out
pata: imx: set controller PIO mode with .set_piomode callback
pata: imx: add support of setting timings for PIO modes
pata: imx: support controller modes up to PIO4
drivers/ata/pata_imx.c | 82 +++++++++++++++++++++++++++++++++++---------------
1 file changed, 57 insertions(+), 25 deletions(-)
--
2.10.2
^ permalink raw reply
* Re: [RFC PATCH v3 1/2] Add support for eXclusive Page Frame Ownership (XPFO)
From: Christoph Hellwig @ 2016-11-04 14:50 UTC (permalink / raw)
To: Juerg Haefliger
Cc: linux-kernel, linux-mm, kernel-hardening, linux-x86_64, vpk,
Tejun Heo, linux-ide
In-Reply-To: <20161104144534.14790-2-juerg.haefliger@hpe.com>
The libata parts here really need to be split out and the proper list
and maintainer need to be Cc'ed.
> diff --git a/drivers/ata/libata-sff.c b/drivers/ata/libata-sff.c
> index 051b6158d1b7..58af734be25d 100644
> --- a/drivers/ata/libata-sff.c
> +++ b/drivers/ata/libata-sff.c
> @@ -715,7 +715,7 @@ 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)) {
> + if (PageHighMem(page) || xpfo_page_is_unmapped(page)) {
> unsigned long flags;
>
> /* FIXME: use a bounce buffer */
> @@ -860,7 +860,7 @@ 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)) {
> + if (PageHighMem(page) || xpfo_page_is_unmapped(page)) {
> unsigned long flags;
>
> /* FIXME: use bounce buffer */
> diff --git a/include/linux/highmem.h b/include/linux/highmem.h
This is just piling one nasty hack on top of another. libata should
just use the highmem case unconditionally, as it is the correct thing
to do for all cases.
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply
* Re: Write performance 50% compared to Windows
From: Bram Matthys @ 2016-11-03 14:43 UTC (permalink / raw)
To: linux-ide
In-Reply-To: <0852f6ee-0535-aebe-c326-fb33edb42a13@vulnscan.org>
Bram Matthys schreef op 2016-11-03 08:46:
> Shaun Tancheff wrote on 2-11-2016 18:50:
>> On Tue, Nov 1, 2016 at 5:37 AM, Bram Matthys <syzop@vulnscan.org
>> <mailto:syzop@vulnscan.org>> wrote:
>>
>> Hi,
>>
>> I have a Samsung SSD 850 EVO 4TB and under Linux I'm only
>> getting ~240MB/s
>> write speed. On Windows it's 490MB/s (yes, without cache).
>> The read speed is the same on both Linux and Windows, though.
>> Both are
>> 512MB/s.
>>
>> Any ideas what this could be? It can't be a slow SATA link as
>> read speed
>> are fine. And since write performance is fine on Windows so I'm
>> kinda
>> stunned. Not sure how to proceed / debug this any further.
>>
>> I'm testing with dd if=/dev/zero of=/dev/sdX bs=1M count=65536
>> conv=fdatasync. Results are similar without the conv=fdatasync.
>> On Windows
>> I test with AS SSD.
>> Prior to testing I do a ATA security erase to make sure the SSD
>> isn't
>> clearing any cells during the benchmark. (Previously I used
>> blkdiscard but
>> then realized this would only 'mark' the cells as unused so it
>> might do
>> the actual erasing in the background)
>> I tested this both with a 4.4.0 and 4.8.4 Linux kernel. Another
>> machines
>> (different hardware) has the same results. All have a SATA III
>> interface.
>>
>>
>> May I suggest that dd is unlikely to give you an accurate
>> measurement of
>> throughput.
>> I would suggest using something like 'fio' instead.
>>
>> sudo fio --ioengine=sync --direct=1 --iodepth=32 --numjobs=1
>> --rw=write \
>> --bsrange=1M-1M --filename=/dev/sdb --runtime=1000 --name=fio
>>
>> I routinely see 500+MB/s with the 2TB SSD I have here ...
>
> Thanks Shaun for your suggestion. I tried this and unfortunately the
> results are not much better with fio:
>
> To summarize, on Linux (4.8.5):
> * fio sync:
> * READ: 478MB/s
> * WRITE: 118MB/s
> * fio libaio:
> * READ: 511MB/s
> * WRITE: 163MB/s
> * dd:
> * READ: 526MB/s
> * WRITE: 235MB/s
I just installed FreeBSD on the system for testing purposes and I'm
getting 444MB/s write speed. That's almost double of Linux.
root@fbsd:/dev # time dd if=/dev/zero of=/dev/ada1 bs=1M count=131072
conv=sync
131072+0 records in
131072+0 records out
137438953472 bytes transferred in 308.931389 secs (444885041 bytes/sec)
12.941u 27.742s 5:08.93 12.1% 29+169k 0+1048576io 0pf+0w
Sorry didn't have fio on the system, but in in any case the 444MB/s is
a minimum.
Read speed is 500MB/s by the way.
So this slow write performance issue seems Linux-specific.
Any (other) tips to get write speeds at the same level as FreeBSD or
Windows would be highly appreciated.
Regards,
Bram
>
> On Windows (7):
> * AS SSD http://imgur.com/ygCINXF :
> * READ: 512MB/s
> * WRITE: 493MB/s
> * ATTO SSD (32GB data 1M/2M/4M bsize) http://imgur.com/46cbogr :
> * READ: 560MB/s
> * WRITE: 533MB/s
> (And a quick ATTO block size test http://imgur.com/MhuLjno )
>
> Output of the fio and dd commands are below.
>
> # fio --ioengine=sync --direct=1 --iodepth=32 --numjobs=1 --rw=read
> --bsrange=1M-1M --runtime=1000 --name=fio --filename=/dev/sda
> fio: (g=0): rw=read, bs=1M-1M/1M-1M/1M-1M, ioengine=sync, iodepth=32
> fio-2.2.10
> Starting 1 process
> Jobs: 1 (f=1): [R(1)] [100.0% done] [472.0MB/0KB/0KB /s] [472/0/0
> iops] [eta 00m:00s]
> fio: (groupid=0, jobs=1): err= 0: pid=14727: Thu Nov 3 07:40:58 2016
> read : io=467388MB, bw=478604KB/s, iops=467, runt=1000002msec
> clat (usec): min=1901, max=10352, avg=2136.75, stdev=147.57
> lat (usec): min=1901, max=10353, avg=2137.03, stdev=147.59
> clat percentiles (usec):
> | 1.00th=[ 2024], 5.00th=[ 2064], 10.00th=[ 2064], 20.00th=[
> 2096],
> | 30.00th=[ 2128], 40.00th=[ 2128], 50.00th=[ 2128], 60.00th=[
> 2128],
> | 70.00th=[ 2160], 80.00th=[ 2160], 90.00th=[ 2192], 95.00th=[
> 2192],
> | 99.00th=[ 2320], 99.50th=[ 2352], 99.90th=[ 3568], 99.95th=[
> 6624],
> | 99.99th=[ 7776]
> bw (KB /s): min=286147, max=495616, per=100.00%, avg=479047.45,
> stdev=11395.42
> lat (msec) : 2=0.23%, 4=99.68%, 10=0.09%, 20=0.01%
> cpu : usr=0.21%, sys=5.20%, ctx=467427, majf=0, minf=265
> IO depths : 1=100.0%, 2=0.0%, 4=0.0%, 8=0.0%, 16=0.0%, 32=0.0%,
> >=64=0.0%
> submit : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%,
> >=64=0.0%
> complete : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%,
> >=64=0.0%
> issued : total=r=467388/w=0/d=0, short=r=0/w=0/d=0,
> drop=r=0/w=0/d=0
> latency : target=0, window=0, percentile=100.00%, depth=32
>
> Run status group 0 (all jobs):
> READ: io=467388MB, aggrb=478604KB/s, minb=478604KB/s,
> maxb=478604KB/s, mint=1000002msec, maxt=1000002msec
>
> Disk stats (read/write):
> sda: ios=934688/0, merge=0/0, ticks=1594452/0, in_queue=1594292,
> util=95.27%
>
> # fio --ioengine=libaio --direct=1 --iodepth=32 --numjobs=1 --rw=read
> --bsrange=1M-1M --runtime=1000 --name=fio --filename=/dev/sda
> fio: (g=0): rw=read, bs=1M-1M/1M-1M/1M-1M, ioengine=libaio,
> iodepth=32
> fio-2.2.10
> Starting 1 process
> Jobs: 1 (f=1): [R(1)] [100.0% done] [507.0MB/0KB/0KB /s] [507/0/0
> iops] [eta 00m:00s]
> fio: (groupid=0, jobs=1): err= 0: pid=14761: Thu Nov 3 07:58:01 2016
> read : io=499290MB, bw=511241KB/s, iops=499, runt=1000062msec
> slat (usec): min=29, max=606, avg=56.90, stdev=21.02
> clat (msec): min=5, max=148, avg=64.03, stdev= 1.71
> lat (msec): min=5, max=148, avg=64.09, stdev= 1.71
> clat percentiles (msec):
> | 1.00th=[ 63], 5.00th=[ 63], 10.00th=[ 63], 20.00th=[
> 64],
> | 30.00th=[ 64], 40.00th=[ 64], 50.00th=[ 64], 60.00th=[
> 64],
> | 70.00th=[ 66], 80.00th=[ 67], 90.00th=[ 67], 95.00th=[
> 67],
> | 99.00th=[ 67], 99.50th=[ 67], 99.90th=[ 76], 99.95th=[
> 78],
> | 99.99th=[ 123]
> bw (KB /s): min=406738, max=521197, per=100.00%, avg=511739.76,
> stdev=11240.18
> lat (msec) : 10=0.01%, 20=0.01%, 50=0.01%, 100=99.97%, 250=0.03%
> cpu : usr=0.60%, sys=3.67%, ctx=499374, majf=0, minf=538
> IO depths : 1=0.1%, 2=0.1%, 4=0.1%, 8=0.1%, 16=0.1%, 32=100.0%,
> >=64=0.0%
> submit : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%,
> >=64=0.0%
> complete : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.1%, 64=0.0%,
> >=64=0.0%
> issued : total=r=499290/w=0/d=0, short=r=0/w=0/d=0,
> drop=r=0/w=0/d=0
> latency : target=0, window=0, percentile=100.00%, depth=32
>
> Run status group 0 (all jobs):
> READ: io=499290MB, aggrb=511241KB/s, minb=511241KB/s,
> maxb=511241KB/s, mint=1000062msec, maxt=1000062msec
>
> Disk stats (read/write):
> sda: ios=514818/0, merge=0/0, ticks=32910900/0, in_queue=32911656,
> util=100.00%
>
> # time fio --ioengine=sync --direct=1 --iodepth=32 --numjobs=1
> --rw=write --bsrange=1M-1M --runtime=1000 --name=fio
> --filename=/dev/sda
> fio: (g=0): rw=write, bs=1M-1M/1M-1M/1M-1M, ioengine=sync, iodepth=32
> fio-2.2.10
> Starting 1 process
> Jobs: 1 (f=1): [W(1)] [100.0% done] [0KB/101.0MB/0KB /s] [0/101/0
> iops] [eta 00m:00s]
> fio: (groupid=0, jobs=1): err= 0: pid=14207: Wed Nov 2 20:48:09 2016
> write: io=116047MB, bw=118831KB/s, iops=116, runt=1000006msec
> clat (msec): min=4, max=24, avg= 8.58, stdev= 2.26
> lat (msec): min=4, max=24, avg= 8.61, stdev= 2.26
> clat percentiles (usec):
> | 1.00th=[ 5024], 5.00th=[ 5152], 10.00th=[ 5280], 20.00th=[
> 5664],
> | 30.00th=[ 6944], 40.00th=[ 9152], 50.00th=[ 9280], 60.00th=[
> 9536],
> | 70.00th=[ 9792], 80.00th=[10048], 90.00th=[10560],
> 95.00th=[11328],
> | 99.00th=[14400], 99.50th=[17280], 99.90th=[19328],
> 99.95th=[20352],
> | 99.99th=[21120]
> bw (KB /s): min=91610, max=202752, per=100.00%, avg=119006.32,
> stdev=31198.56
> lat (msec) : 10=79.69%, 20=20.24%, 50=0.06%
> cpu : usr=0.43%, sys=0.73%, ctx=116061, majf=0, minf=11
> IO depths : 1=100.0%, 2=0.0%, 4=0.0%, 8=0.0%, 16=0.0%, 32=0.0%,
> >=64=0.0%
> submit : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%,
> >=64=0.0%
> complete : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%,
> >=64=0.0%
> issued : total=r=0/w=116047/d=0, short=r=0/w=0/d=0,
> drop=r=0/w=0/d=0
> latency : target=0, window=0, percentile=100.00%, depth=32
>
> Run status group 0 (all jobs):
> WRITE: io=116047MB, aggrb=118831KB/s, minb=118831KB/s,
> maxb=118831KB/s, mint=1000006msec, maxt=1000006msec
>
> Disk stats (read/write):
> sda: ios=0/116037, merge=0/0, ticks=0/985368, in_queue=985316,
> util=98.61%
>
> real 16m40.461s
> user 0m5.472s
> sys 0m8.992s
>
> # time fio --ioengine=libaio --direct=1 --iodepth=32 --numjobs=1
> --rw=write --bsrange=1M-1M --runtime=1000 --name=fio
> --filename=/dev/sda
> fio: (g=0): rw=write, bs=1M-1M/1M-1M/1M-1M, ioengine=libaio,
> iodepth=32
> fio-2.2.10
> Starting 1 process
> Jobs: 1 (f=1): [W(1)] [100.0% done] [0KB/141.0MB/0KB /s] [0/141/0
> iops] [eta 00m:00s]
> fio: (groupid=0, jobs=1): err= 0: pid=14469: Wed Nov 2 21:22:17 2016
> write: io=159168MB, bw=162952KB/s, iops=159, runt=1000219msec
> slat (usec): min=34, max=621, avg=109.71, stdev=23.32
> clat (msec): min=78, max=539, avg=200.98, stdev=86.51
> lat (msec): min=78, max=539, avg=201.09, stdev=86.51
> clat percentiles (msec):
> | 1.00th=[ 83], 5.00th=[ 86], 10.00th=[ 89], 20.00th=[
> 105],
> | 30.00th=[ 176], 40.00th=[ 188], 50.00th=[ 200], 60.00th=[
> 212],
> | 70.00th=[ 227], 80.00th=[ 237], 90.00th=[ 255], 95.00th=[
> 408],
> | 99.00th=[ 469], 99.50th=[ 482], 99.90th=[ 498], 99.95th=[
> 502],
> | 99.99th=[ 519]
> bw (KB /s): min=104160, max=389120, per=100.00%, avg=166894.31,
> stdev=63045.67
> lat (msec) : 100=19.30%, 250=69.43%, 500=11.20%, 750=0.08%
> cpu : usr=0.97%, sys=0.83%, ctx=5748, majf=0, minf=11
> IO depths : 1=0.1%, 2=0.1%, 4=0.1%, 8=0.1%, 16=0.1%, 32=100.0%,
> >=64=0.0%
> submit : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%,
> >=64=0.0%
> complete : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.1%, 64=0.0%,
> >=64=0.0%
> issued : total=r=0/w=159168/d=0, short=r=0/w=0/d=0,
> drop=r=0/w=0/d=0
> latency : target=0, window=0, percentile=100.00%, depth=32
>
> Run status group 0 (all jobs):
> WRITE: io=159168MB, aggrb=162952KB/s, minb=162952KB/s,
> maxb=162952KB/s, mint=1000219msec, maxt=1000219msec
>
> Disk stats (read/write):
> sda: ios=0/159136, merge=0/0, ticks=0/31683824, in_queue=31685776,
> util=100.00%
>
> real 16m40.684s
> user 0m10.840s
> sys 0m9.996s
>
> # time dd if=/dev/zero of=/dev/sda bs=1M count=65536 conv=fdatasync
> 65536+0 records in
> 65536+0 records out
> 68719476736 bytes (69 GB, 64 GiB) copied, 292.338 s, 235 MB/s
>
> real 4m52.342s
> user 0m0.024s
> sys 0m38.048s
>
> # echo 3 >/proc/sys/vm/drop_caches
>
> # time dd if=/dev/sda of=/dev/null bs=1M count=65536
> 65536+0 records in
> 65536+0 records out
> 68719476736 bytes (69 GB, 64 GiB) copied, 130.537 s, 526 MB/s
>
> real 2m10.543s
> user 0m0.028s
> sys 0m28.604s
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-ide"
> in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: Write performance 50% compared to Windows
From: Bram Matthys @ 2016-11-03 7:46 UTC (permalink / raw)
To: linux-ide
In-Reply-To: <CAJVOszDeJSXgdMuA-f6=JDSL78SBSz+-uDNp2PX=VTjeNyz4Bg@mail.gmail.com>
Shaun Tancheff wrote on 2-11-2016 18:50:
> On Tue, Nov 1, 2016 at 5:37 AM, Bram Matthys <syzop@vulnscan.org
> <mailto:syzop@vulnscan.org>> wrote:
>
> Hi,
>
> I have a Samsung SSD 850 EVO 4TB and under Linux I'm only getting ~240MB/s
> write speed. On Windows it's 490MB/s (yes, without cache).
> The read speed is the same on both Linux and Windows, though. Both are
> 512MB/s.
>
> Any ideas what this could be? It can't be a slow SATA link as read speed
> are fine. And since write performance is fine on Windows so I'm kinda
> stunned. Not sure how to proceed / debug this any further.
>
> I'm testing with dd if=/dev/zero of=/dev/sdX bs=1M count=65536
> conv=fdatasync. Results are similar without the conv=fdatasync. On Windows
> I test with AS SSD.
> Prior to testing I do a ATA security erase to make sure the SSD isn't
> clearing any cells during the benchmark. (Previously I used blkdiscard but
> then realized this would only 'mark' the cells as unused so it might do
> the actual erasing in the background)
> I tested this both with a 4.4.0 and 4.8.4 Linux kernel. Another machines
> (different hardware) has the same results. All have a SATA III interface.
>
>
> May I suggest that dd is unlikely to give you an accurate measurement of
> throughput.
> I would suggest using something like 'fio' instead.
>
> sudo fio --ioengine=sync --direct=1 --iodepth=32 --numjobs=1 --rw=write \
> --bsrange=1M-1M --filename=/dev/sdb --runtime=1000 --name=fio
>
> I routinely see 500+MB/s with the 2TB SSD I have here ...
Thanks Shaun for your suggestion. I tried this and unfortunately the results
are not much better with fio:
To summarize, on Linux (4.8.5):
* fio sync:
* READ: 478MB/s
* WRITE: 118MB/s
* fio libaio:
* READ: 511MB/s
* WRITE: 163MB/s
* dd:
* READ: 526MB/s
* WRITE: 235MB/s
On Windows (7):
* AS SSD http://imgur.com/ygCINXF :
* READ: 512MB/s
* WRITE: 493MB/s
* ATTO SSD (32GB data 1M/2M/4M bsize) http://imgur.com/46cbogr :
* READ: 560MB/s
* WRITE: 533MB/s
(And a quick ATTO block size test http://imgur.com/MhuLjno )
Output of the fio and dd commands are below.
# fio --ioengine=sync --direct=1 --iodepth=32 --numjobs=1 --rw=read
--bsrange=1M-1M --runtime=1000 --name=fio --filename=/dev/sda
fio: (g=0): rw=read, bs=1M-1M/1M-1M/1M-1M, ioengine=sync, iodepth=32
fio-2.2.10
Starting 1 process
Jobs: 1 (f=1): [R(1)] [100.0% done] [472.0MB/0KB/0KB /s] [472/0/0 iops] [eta
00m:00s]
fio: (groupid=0, jobs=1): err= 0: pid=14727: Thu Nov 3 07:40:58 2016
read : io=467388MB, bw=478604KB/s, iops=467, runt=1000002msec
clat (usec): min=1901, max=10352, avg=2136.75, stdev=147.57
lat (usec): min=1901, max=10353, avg=2137.03, stdev=147.59
clat percentiles (usec):
| 1.00th=[ 2024], 5.00th=[ 2064], 10.00th=[ 2064], 20.00th=[ 2096],
| 30.00th=[ 2128], 40.00th=[ 2128], 50.00th=[ 2128], 60.00th=[ 2128],
| 70.00th=[ 2160], 80.00th=[ 2160], 90.00th=[ 2192], 95.00th=[ 2192],
| 99.00th=[ 2320], 99.50th=[ 2352], 99.90th=[ 3568], 99.95th=[ 6624],
| 99.99th=[ 7776]
bw (KB /s): min=286147, max=495616, per=100.00%, avg=479047.45,
stdev=11395.42
lat (msec) : 2=0.23%, 4=99.68%, 10=0.09%, 20=0.01%
cpu : usr=0.21%, sys=5.20%, ctx=467427, majf=0, minf=265
IO depths : 1=100.0%, 2=0.0%, 4=0.0%, 8=0.0%, 16=0.0%, 32=0.0%, >=64=0.0%
submit : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, >=64=0.0%
complete : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, >=64=0.0%
issued : total=r=467388/w=0/d=0, short=r=0/w=0/d=0, drop=r=0/w=0/d=0
latency : target=0, window=0, percentile=100.00%, depth=32
Run status group 0 (all jobs):
READ: io=467388MB, aggrb=478604KB/s, minb=478604KB/s, maxb=478604KB/s,
mint=1000002msec, maxt=1000002msec
Disk stats (read/write):
sda: ios=934688/0, merge=0/0, ticks=1594452/0, in_queue=1594292, util=95.27%
# fio --ioengine=libaio --direct=1 --iodepth=32 --numjobs=1 --rw=read
--bsrange=1M-1M --runtime=1000 --name=fio --filename=/dev/sda
fio: (g=0): rw=read, bs=1M-1M/1M-1M/1M-1M, ioengine=libaio, iodepth=32
fio-2.2.10
Starting 1 process
Jobs: 1 (f=1): [R(1)] [100.0% done] [507.0MB/0KB/0KB /s] [507/0/0 iops] [eta
00m:00s]
fio: (groupid=0, jobs=1): err= 0: pid=14761: Thu Nov 3 07:58:01 2016
read : io=499290MB, bw=511241KB/s, iops=499, runt=1000062msec
slat (usec): min=29, max=606, avg=56.90, stdev=21.02
clat (msec): min=5, max=148, avg=64.03, stdev= 1.71
lat (msec): min=5, max=148, avg=64.09, stdev= 1.71
clat percentiles (msec):
| 1.00th=[ 63], 5.00th=[ 63], 10.00th=[ 63], 20.00th=[ 64],
| 30.00th=[ 64], 40.00th=[ 64], 50.00th=[ 64], 60.00th=[ 64],
| 70.00th=[ 66], 80.00th=[ 67], 90.00th=[ 67], 95.00th=[ 67],
| 99.00th=[ 67], 99.50th=[ 67], 99.90th=[ 76], 99.95th=[ 78],
| 99.99th=[ 123]
bw (KB /s): min=406738, max=521197, per=100.00%, avg=511739.76,
stdev=11240.18
lat (msec) : 10=0.01%, 20=0.01%, 50=0.01%, 100=99.97%, 250=0.03%
cpu : usr=0.60%, sys=3.67%, ctx=499374, majf=0, minf=538
IO depths : 1=0.1%, 2=0.1%, 4=0.1%, 8=0.1%, 16=0.1%, 32=100.0%, >=64=0.0%
submit : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, >=64=0.0%
complete : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.1%, 64=0.0%, >=64=0.0%
issued : total=r=499290/w=0/d=0, short=r=0/w=0/d=0, drop=r=0/w=0/d=0
latency : target=0, window=0, percentile=100.00%, depth=32
Run status group 0 (all jobs):
READ: io=499290MB, aggrb=511241KB/s, minb=511241KB/s, maxb=511241KB/s,
mint=1000062msec, maxt=1000062msec
Disk stats (read/write):
sda: ios=514818/0, merge=0/0, ticks=32910900/0, in_queue=32911656, util=100.00%
# time fio --ioengine=sync --direct=1 --iodepth=32 --numjobs=1 --rw=write
--bsrange=1M-1M --runtime=1000 --name=fio --filename=/dev/sda
fio: (g=0): rw=write, bs=1M-1M/1M-1M/1M-1M, ioengine=sync, iodepth=32
fio-2.2.10
Starting 1 process
Jobs: 1 (f=1): [W(1)] [100.0% done] [0KB/101.0MB/0KB /s] [0/101/0 iops] [eta
00m:00s]
fio: (groupid=0, jobs=1): err= 0: pid=14207: Wed Nov 2 20:48:09 2016
write: io=116047MB, bw=118831KB/s, iops=116, runt=1000006msec
clat (msec): min=4, max=24, avg= 8.58, stdev= 2.26
lat (msec): min=4, max=24, avg= 8.61, stdev= 2.26
clat percentiles (usec):
| 1.00th=[ 5024], 5.00th=[ 5152], 10.00th=[ 5280], 20.00th=[ 5664],
| 30.00th=[ 6944], 40.00th=[ 9152], 50.00th=[ 9280], 60.00th=[ 9536],
| 70.00th=[ 9792], 80.00th=[10048], 90.00th=[10560], 95.00th=[11328],
| 99.00th=[14400], 99.50th=[17280], 99.90th=[19328], 99.95th=[20352],
| 99.99th=[21120]
bw (KB /s): min=91610, max=202752, per=100.00%, avg=119006.32,
stdev=31198.56
lat (msec) : 10=79.69%, 20=20.24%, 50=0.06%
cpu : usr=0.43%, sys=0.73%, ctx=116061, majf=0, minf=11
IO depths : 1=100.0%, 2=0.0%, 4=0.0%, 8=0.0%, 16=0.0%, 32=0.0%, >=64=0.0%
submit : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, >=64=0.0%
complete : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, >=64=0.0%
issued : total=r=0/w=116047/d=0, short=r=0/w=0/d=0, drop=r=0/w=0/d=0
latency : target=0, window=0, percentile=100.00%, depth=32
Run status group 0 (all jobs):
WRITE: io=116047MB, aggrb=118831KB/s, minb=118831KB/s, maxb=118831KB/s,
mint=1000006msec, maxt=1000006msec
Disk stats (read/write):
sda: ios=0/116037, merge=0/0, ticks=0/985368, in_queue=985316, util=98.61%
real 16m40.461s
user 0m5.472s
sys 0m8.992s
# time fio --ioengine=libaio --direct=1 --iodepth=32 --numjobs=1 --rw=write
--bsrange=1M-1M --runtime=1000 --name=fio --filename=/dev/sda
fio: (g=0): rw=write, bs=1M-1M/1M-1M/1M-1M, ioengine=libaio, iodepth=32
fio-2.2.10
Starting 1 process
Jobs: 1 (f=1): [W(1)] [100.0% done] [0KB/141.0MB/0KB /s] [0/141/0 iops] [eta
00m:00s]
fio: (groupid=0, jobs=1): err= 0: pid=14469: Wed Nov 2 21:22:17 2016
write: io=159168MB, bw=162952KB/s, iops=159, runt=1000219msec
slat (usec): min=34, max=621, avg=109.71, stdev=23.32
clat (msec): min=78, max=539, avg=200.98, stdev=86.51
lat (msec): min=78, max=539, avg=201.09, stdev=86.51
clat percentiles (msec):
| 1.00th=[ 83], 5.00th=[ 86], 10.00th=[ 89], 20.00th=[ 105],
| 30.00th=[ 176], 40.00th=[ 188], 50.00th=[ 200], 60.00th=[ 212],
| 70.00th=[ 227], 80.00th=[ 237], 90.00th=[ 255], 95.00th=[ 408],
| 99.00th=[ 469], 99.50th=[ 482], 99.90th=[ 498], 99.95th=[ 502],
| 99.99th=[ 519]
bw (KB /s): min=104160, max=389120, per=100.00%, avg=166894.31,
stdev=63045.67
lat (msec) : 100=19.30%, 250=69.43%, 500=11.20%, 750=0.08%
cpu : usr=0.97%, sys=0.83%, ctx=5748, majf=0, minf=11
IO depths : 1=0.1%, 2=0.1%, 4=0.1%, 8=0.1%, 16=0.1%, 32=100.0%, >=64=0.0%
submit : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, >=64=0.0%
complete : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.1%, 64=0.0%, >=64=0.0%
issued : total=r=0/w=159168/d=0, short=r=0/w=0/d=0, drop=r=0/w=0/d=0
latency : target=0, window=0, percentile=100.00%, depth=32
Run status group 0 (all jobs):
WRITE: io=159168MB, aggrb=162952KB/s, minb=162952KB/s, maxb=162952KB/s,
mint=1000219msec, maxt=1000219msec
Disk stats (read/write):
sda: ios=0/159136, merge=0/0, ticks=0/31683824, in_queue=31685776, util=100.00%
real 16m40.684s
user 0m10.840s
sys 0m9.996s
# time dd if=/dev/zero of=/dev/sda bs=1M count=65536 conv=fdatasync
65536+0 records in
65536+0 records out
68719476736 bytes (69 GB, 64 GiB) copied, 292.338 s, 235 MB/s
real 4m52.342s
user 0m0.024s
sys 0m38.048s
# echo 3 >/proc/sys/vm/drop_caches
# time dd if=/dev/sda of=/dev/null bs=1M count=65536
65536+0 records in
65536+0 records out
68719476736 bytes (69 GB, 64 GiB) copied, 130.537 s, 526 MB/s
real 2m10.543s
user 0m0.028s
sys 0m28.604s
^ permalink raw reply
* Re: Write performance 50% compared to Windows
From: Bram Matthys @ 2016-11-02 15:07 UTC (permalink / raw)
To: linux-ide
In-Reply-To: <adf65b5b8edfe0c1c99bc55a2827a68d@mail.vulnscan.org>
Bram Matthys wrote on 1-11-2016 11:37:
> I have a Samsung SSD 850 EVO 4TB and under Linux I'm only getting ~240MB/s
> write speed. On Windows it's 490MB/s (yes, without cache).
> The read speed is the same on both Linux and Windows, though. Both are 512MB/s.
>
> Any ideas what this could be? It can't be a slow SATA link as read speed are
> fine. And since write performance is fine on Windows so I'm kinda stunned. Not
> sure how to proceed / debug this any further.
> [..]
I received the following reply from Samsung:
"Unfortunately, there is not much we can assist you with as Samsung does not
provide support for Linux operating systems."
So that isn't helping much :/
Regards,
Bram
^ permalink raw reply
* Re: [PATCH v2 34/37] docs: fix locations of several documents that got moved
From: Prarit Bhargava @ 2016-11-02 10:08 UTC (permalink / raw)
To: Pavel Machek, Mauro Carvalho Chehab
Cc: Linux Doc Mailing List, Mauro Carvalho Chehab, Jonathan Corbet,
Rafael J. Wysocki, Len Brown, Jens Axboe, Alessandro Zummo,
Alexandre Belloni, Rob Herring, Mark Rutland, Jean Delvare,
Guenter Roeck, Karsten Keil, Mauro Carvalho Chehab,
Steffen Klassert, Greg Kroah-Hartman, Johannes Berg,
Jaroslav Kysela, Takashi Iwai, Paolo Bonzini <pbon>
In-Reply-To: <20161102093154.GC23350@amd>
On 11/02/2016 05:31 AM, Pavel Machek wrote:
> Hi!
>
>>> Dunno, but kernel-parameters.txt was already quite long... for a file
>>> that is referenced quite often. Adding admin-guide/ into the path does
>>> not really help.
>>
>> The big string name starts with Documentation/ :) There are some discussions
>> about changing it to doc/ (or docs/). Also, as you said, kernel-parameters
>> is already a big name. Perhaps we could use, instead,
>>> "kernel-parms".
>
> cmdline?
You would not believe the number of users I've dealt with that have confused
"cmdline/command line" (aka prompt) with "kernel parameter". I go back and edit
customer debug requests to make sure there's no use of cmdline in place of
kernel parameter.
For the love of every customer facing engineer out there, please stop using
cmdline ;).
P.
>
>> If we rename kernel-parameters.rst to kernel-parms.rst, plus the doc/ rename,
>> then the string size will actually reduce:
>>
>> - (see Documentation/kernel-parameters.txt), the minimum possible
>> + (see doc/admin-guide/kernel-parms.rst), the minimum possible
>>
>>> Maybe admin-guide should go directly into Documentation/ , as that's
>>> what our users are interested in?
>>
>> There are several problems if we keep them at Documentation/ dir:
>>
>> - We'll end by mixing documents already converted to ReST with documents
>> not converted yet;
>>
>> - A rename is needed anyway, as Sphinx only accepts ReST files that end
>> with the extension(s) defined at Documentation/conf.py (currently,
>> .rst);
>>
>> - A partial documentation build is made by sub-directory. If we put
>> files under /Documentation, there's no way to build just one
>> book.
>
> Well, documentation is primarily for users. I'm sure tools can adapt...
>
>>> Plus, I'm not sure how many developers will figure out that process/
>>> is what describes kernel patch submission process. We have processes
>>> in the kernel, after all...
>>
>> Do you have a better idea?
>
> development/ ?
>
> Best regards,
> Pavel
>
--
You received this message because you are subscribed to "rtc-linux".
Membership options at http://groups.google.com/group/rtc-linux .
Please read http://groups.google.com/group/rtc-linux/web/checklist
before submitting a driver.
---
You received this message because you are subscribed to the Google Groups "rtc-linux" group.
To unsubscribe from this group and stop receiving emails from it, send an email to rtc-linux+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
For more options, visit https://groups.google.com/d/optout.
^ permalink raw reply
* Re: [PATCH v2 34/37] docs: fix locations of several documents that got moved
From: Pavel Machek @ 2016-11-02 9:31 UTC (permalink / raw)
To: Mauro Carvalho Chehab
Cc: Nicolas Pitre, Linus Walleij, Jaroslav Kysela, Chris Metcalf,
Peter Loeffler, Finn Thain, Yaowei Bai, Jakub Wilk, linux-acpi,
Geert Uytterhoeven, Guenter Roeck, Petr Mladek, Jean Delvare,
linux-pm, Alexander Viro, Andy Lutomirski, Thomas Gleixner,
Karsten Keil, Jiri Kosina, seokhoon.yoon, Li Zefan, Ryan Swan,
Joe Perches, Andrew Morton, Mark
In-Reply-To: <20161019115918.1162d16e@vento.lan>
[-- Attachment #1.1: Type: text/plain, Size: 1794 bytes --]
Hi!
> > Dunno, but kernel-parameters.txt was already quite long... for a file
> > that is referenced quite often. Adding admin-guide/ into the path does
> > not really help.
>
> The big string name starts with Documentation/ :) There are some discussions
> about changing it to doc/ (or docs/). Also, as you said, kernel-parameters
> is already a big name. Perhaps we could use, instead,
> > "kernel-parms".
cmdline?
> If we rename kernel-parameters.rst to kernel-parms.rst, plus the doc/ rename,
> then the string size will actually reduce:
>
> - (see Documentation/kernel-parameters.txt), the minimum possible
> + (see doc/admin-guide/kernel-parms.rst), the minimum possible
>
> > Maybe admin-guide should go directly into Documentation/ , as that's
> > what our users are interested in?
>
> There are several problems if we keep them at Documentation/ dir:
>
> - We'll end by mixing documents already converted to ReST with documents
> not converted yet;
>
> - A rename is needed anyway, as Sphinx only accepts ReST files that end
> with the extension(s) defined at Documentation/conf.py (currently,
> .rst);
>
> - A partial documentation build is made by sub-directory. If we put
> files under /Documentation, there's no way to build just one
> book.
Well, documentation is primarily for users. I'm sure tools can adapt...
> > Plus, I'm not sure how many developers will figure out that process/
> > is what describes kernel patch submission process. We have processes
> > in the kernel, after all...
>
> Do you have a better idea?
development/ ?
Best regards,
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
[-- Attachment #1.2: Digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]
[-- Attachment #2: Type: text/plain, Size: 183 bytes --]
_______________________________________________
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
^ permalink raw reply
* Re: [PATCH] libata-scsi: Fixup ata_gen_passthru_sense()
From: Tejun Heo @ 2016-11-01 17:33 UTC (permalink / raw)
To: Hannes Reinecke; +Cc: Charles Machalow, linux-ide, Hannes Reinecke
In-Reply-To: <1477944418-110380-1-git-send-email-hare@suse.de>
On Mon, Oct 31, 2016 at 09:06:58PM +0100, Hannes Reinecke wrote:
> There's a typo in ata_gen_passthru_sense(), where the first byte
> would be overwritten incorrectly later on.
>
> Reported-by: Charles Machalow <csm10495@gmail.com>
> Signed-off-by: Hannes Reinecke <hare@suse.com>
Applied to libata/for-4.9-fixes with stable cc'd.
Thanks.
--
tejun
^ permalink raw reply
* Re: Write performance 50% compared to Windows
From: Bram Matthys @ 2016-11-01 13:55 UTC (permalink / raw)
To: linux-ide
Hi Daniel,
Daniel Fraga schreef op 2016-11-01 14:03:
> On Tue, 01 Nov 2016 11:37:42 +0100
> Bram Matthys <syzop@vulnscan.org> wrote:
>
>> I have a Samsung SSD 850 EVO 4TB and under Linux I'm only getting
>> ~240MB/s write speed. On Windows it's 490MB/s (yes, without cache).
>> The read speed is the same on both Linux and Windows, though. Both
>> are
>> 512MB/s.
>
> Just curious: are you using the "deadline" scheduler? What file
> system? Ext4?
Yes, the deadline scheduler.
On Linux I'm writing directly to /dev/sda, no file system.
Regards,
Bram
^ permalink raw reply
* Re: Write performance 50% compared to Windows
From: Dâniel Fraga @ 2016-11-01 13:03 UTC (permalink / raw)
To: linux-ide
In-Reply-To: <adf65b5b8edfe0c1c99bc55a2827a68d@mail.vulnscan.org>
On Tue, 01 Nov 2016 11:37:42 +0100
Bram Matthys <syzop@vulnscan.org> wrote:
> I have a Samsung SSD 850 EVO 4TB and under Linux I'm only getting
> ~240MB/s write speed. On Windows it's 490MB/s (yes, without cache).
> The read speed is the same on both Linux and Windows, though. Both are
> 512MB/s.
Just curious: are you using the "deadline" scheduler? What file
system? Ext4?
--
https://exchangewar.info
^ 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