RE: [PATCH v3] ata: Disable AHCI ALPM feature for Ampere Computing eMAG SATA
Hi Jens With regards, Suman >-Original Message- >From: Jens Axboe >Sent: Friday, September 7, 2018 7:26 AM >To: Suman Tripathi ; Hans de Goede >; t...@kernel.org; linux-...@vger.kernel.org; linux- >arm-ker...@lists.infradead.org; linux-kernel@vger.kernel.org; >j...@perches.com; a...@arndb.de; gre...@linuxfoundation.org >Cc: Open Source Submission ; Rameshwar >Sahu >Subject: Re: [PATCH v3] ata: Disable AHCI ALPM feature for Ampere Computing >eMAG SATA > >[NOTICE: This email originated from an external sender. Please be mindful of >safe email handling and proprietary information protection practices.] >_ >_______ > >On 9/6/18 2:08 PM, Suman Tripathi wrote: >>> Sorry, but the patch is still coming through mangled. Did you use git >>> send-email ? >> >> [Suman Tripathi] yes. I rechecked before sending twice. Sorry for the >> inconvenience. Will figure the issue out > >I can apply it manually while you work out the kinks in your email setup. It >might >even be your company MTA mangling it, I've seen all sorts of crazy like that. Thanks for the support. We are working with IT to fix this issue. > >-- >Jens Axboe
RE: [PATCH v3] ata: Disable AHCI ALPM feature for Ampere Computing eMAG SATA
Hi Jens With regards, Suman >-Original Message- >From: Jens Axboe >Sent: Friday, September 7, 2018 7:26 AM >To: Suman Tripathi ; Hans de Goede >; t...@kernel.org; linux-...@vger.kernel.org; linux- >arm-ker...@lists.infradead.org; linux-kernel@vger.kernel.org; >j...@perches.com; a...@arndb.de; gre...@linuxfoundation.org >Cc: Open Source Submission ; Rameshwar >Sahu >Subject: Re: [PATCH v3] ata: Disable AHCI ALPM feature for Ampere Computing >eMAG SATA > >[NOTICE: This email originated from an external sender. Please be mindful of >safe email handling and proprietary information protection practices.] >_ >_______ > >On 9/6/18 2:08 PM, Suman Tripathi wrote: >>> Sorry, but the patch is still coming through mangled. Did you use git >>> send-email ? >> >> [Suman Tripathi] yes. I rechecked before sending twice. Sorry for the >> inconvenience. Will figure the issue out > >I can apply it manually while you work out the kinks in your email setup. It >might >even be your company MTA mangling it, I've seen all sorts of crazy like that. Thanks for the support. We are working with IT to fix this issue. > >-- >Jens Axboe
RE: [PATCH v3] ata: Disable AHCI ALPM feature for Ampere Computing eMAG SATA
Hi Hans,
With regards,
Suman
-Original Message-
From: Hans de Goede
Sent: Thursday, September 6, 2018 1:06 PM
To: Suman Tripathi ; ax...@kernel.dk;
t...@kernel.org; linux-...@vger.kernel.org;
linux-arm-ker...@lists.infradead.org; linux-kernel@vger.kernel.org;
j...@perches.com; a...@arndb.de; gre...@linuxfoundation.org
Cc: Open Source Submission ; Rameshwar Sahu
Subject: Re: [PATCH v3] ata: Disable AHCI ALPM feature for Ampere Computing
eMAG SATA
[NOTICE: This email originated from an external sender. Please be mindful of
safe email handling and proprietary information protection practices.]
Hi,
On 06-09-18 20:05, Suman Tripathi wrote:
> Due to hardware errata, Ampere Computing eMAG SATA can't support AHCI
> ALPM feature. This patch disables the AHCI ALPM feature for eMAG SATA.
>
> Signed-off-by: Suman Trpathi
> Signed-off-by: Rameshwar Prasad Sahu
>
Sorry, but the patch is still coming through mangled. Did you use git
send-email ?
[Suman Tripathi] yes. I rechecked before sending twice. Sorry for the
inconvenience. Will figure the issue out
Regards,
Hans
>
> ---
> Changes for v3:
>
> * Fix the indentation and whitespace warnings.
>
> Changes for v2:
>
> * Introduce the new ata_port_info object which includes ATA_FLAG_NO_LPM.
> * Include this object for eMAG SATA inside the acpi match table.
> * Retrieve the ata_port_info from the acpi match table.
>
> ---
> drivers/ata/ahci_platform.c | 15 ++-
> 1 file changed, 14 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/ata/ahci_platform.c b/drivers/ata/ahci_platform.c
> index 99f9a89..9ba283f 100644
> --- a/drivers/ata/ahci_platform.c
> +++ b/drivers/ata/ahci_platform.c
> @@ -33,6 +33,13 @@ static const struct ata_port_info ahci_port_info = {
> .port_ops = _platform_ops,
> };
>
> +static const struct ata_port_info ahci_port_info_nolpm = {
> + .flags = AHCI_FLAG_COMMON | ATA_FLAG_NO_LPM,
> + .pio_mask = ATA_PIO4,
> + .udma_mask = ATA_UDMA6,
> + .port_ops = _platform_ops,
> +};
> +
> static struct scsi_host_template ahci_platform_sht = {
> AHCI_SHT(DRV_NAME),
> };
> @@ -41,6 +48,7 @@ static int ahci_probe(struct platform_device *pdev)
> {
> struct device *dev = >dev;
> struct ahci_host_priv *hpriv;
> + const struct ata_port_info *port;
> int rc;
>
> hpriv = ahci_platform_get_resources(pdev);
> @@ -57,7 +65,11 @@ static int ahci_probe(struct platform_device *pdev)
> if (of_device_is_compatible(dev->of_node, "hisilicon,hisi-ahci"))
> hpriv->flags |= AHCI_HFLAG_NO_FBS | AHCI_HFLAG_NO_NCQ;
>
> - rc = ahci_platform_init_host(pdev, hpriv, _port_info,
> + port = acpi_device_get_match_data(dev);
> + if (!port)
> + port = _port_info;
> +
> + rc = ahci_platform_init_host(pdev, hpriv, port,
>_platform_sht);
> if (rc)
> goto disable_resources;
> @@ -85,6 +97,7 @@ static const struct of_device_id ahci_of_match[] = {
> MODULE_DEVICE_TABLE(of, ahci_of_match);
>
> static const struct acpi_device_id ahci_acpi_match[] = {
> + { "APMC0D33", (unsigned long)_port_info_nolpm },
> { ACPI_DEVICE_CLASS(PCI_CLASS_STORAGE_SATA_AHCI, 0xff) },
> {},
> };
> --
> 2.7.4
>
RE: [PATCH v3] ata: Disable AHCI ALPM feature for Ampere Computing eMAG SATA
Hi Hans,
With regards,
Suman
-Original Message-
From: Hans de Goede
Sent: Thursday, September 6, 2018 1:06 PM
To: Suman Tripathi ; ax...@kernel.dk;
t...@kernel.org; linux-...@vger.kernel.org;
linux-arm-ker...@lists.infradead.org; linux-kernel@vger.kernel.org;
j...@perches.com; a...@arndb.de; gre...@linuxfoundation.org
Cc: Open Source Submission ; Rameshwar Sahu
Subject: Re: [PATCH v3] ata: Disable AHCI ALPM feature for Ampere Computing
eMAG SATA
[NOTICE: This email originated from an external sender. Please be mindful of
safe email handling and proprietary information protection practices.]
Hi,
On 06-09-18 20:05, Suman Tripathi wrote:
> Due to hardware errata, Ampere Computing eMAG SATA can't support AHCI
> ALPM feature. This patch disables the AHCI ALPM feature for eMAG SATA.
>
> Signed-off-by: Suman Trpathi
> Signed-off-by: Rameshwar Prasad Sahu
>
Sorry, but the patch is still coming through mangled. Did you use git
send-email ?
[Suman Tripathi] yes. I rechecked before sending twice. Sorry for the
inconvenience. Will figure the issue out
Regards,
Hans
>
> ---
> Changes for v3:
>
> * Fix the indentation and whitespace warnings.
>
> Changes for v2:
>
> * Introduce the new ata_port_info object which includes ATA_FLAG_NO_LPM.
> * Include this object for eMAG SATA inside the acpi match table.
> * Retrieve the ata_port_info from the acpi match table.
>
> ---
> drivers/ata/ahci_platform.c | 15 ++-
> 1 file changed, 14 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/ata/ahci_platform.c b/drivers/ata/ahci_platform.c
> index 99f9a89..9ba283f 100644
> --- a/drivers/ata/ahci_platform.c
> +++ b/drivers/ata/ahci_platform.c
> @@ -33,6 +33,13 @@ static const struct ata_port_info ahci_port_info = {
> .port_ops = _platform_ops,
> };
>
> +static const struct ata_port_info ahci_port_info_nolpm = {
> + .flags = AHCI_FLAG_COMMON | ATA_FLAG_NO_LPM,
> + .pio_mask = ATA_PIO4,
> + .udma_mask = ATA_UDMA6,
> + .port_ops = _platform_ops,
> +};
> +
> static struct scsi_host_template ahci_platform_sht = {
> AHCI_SHT(DRV_NAME),
> };
> @@ -41,6 +48,7 @@ static int ahci_probe(struct platform_device *pdev)
> {
> struct device *dev = >dev;
> struct ahci_host_priv *hpriv;
> + const struct ata_port_info *port;
> int rc;
>
> hpriv = ahci_platform_get_resources(pdev);
> @@ -57,7 +65,11 @@ static int ahci_probe(struct platform_device *pdev)
> if (of_device_is_compatible(dev->of_node, "hisilicon,hisi-ahci"))
> hpriv->flags |= AHCI_HFLAG_NO_FBS | AHCI_HFLAG_NO_NCQ;
>
> - rc = ahci_platform_init_host(pdev, hpriv, _port_info,
> + port = acpi_device_get_match_data(dev);
> + if (!port)
> + port = _port_info;
> +
> + rc = ahci_platform_init_host(pdev, hpriv, port,
>_platform_sht);
> if (rc)
> goto disable_resources;
> @@ -85,6 +97,7 @@ static const struct of_device_id ahci_of_match[] = {
> MODULE_DEVICE_TABLE(of, ahci_of_match);
>
> static const struct acpi_device_id ahci_acpi_match[] = {
> + { "APMC0D33", (unsigned long)_port_info_nolpm },
> { ACPI_DEVICE_CLASS(PCI_CLASS_STORAGE_SATA_AHCI, 0xff) },
> {},
> };
> --
> 2.7.4
>
[PATCH v3] ata: Disable AHCI ALPM feature for Ampere Computing eMAG SATA
Due to hardware errata, Ampere Computing eMAG SATA can't support
AHCI ALPM feature. This patch disables the AHCI ALPM feature for
eMAG SATA.
Signed-off-by: Suman Trpathi
Signed-off-by: Rameshwar Prasad Sahu
---
Changes for v3:
* Fix the indentation and whitespace warnings.
Changes for v2:
* Introduce the new ata_port_info object which includes ATA_FLAG_NO_LPM.
* Include this object for eMAG SATA inside the acpi match table.
* Retrieve the ata_port_info from the acpi match table.
---
drivers/ata/ahci_platform.c | 15 ++-
1 file changed, 14 insertions(+), 1 deletion(-)
diff --git a/drivers/ata/ahci_platform.c b/drivers/ata/ahci_platform.c
index 99f9a89..9ba283f 100644
--- a/drivers/ata/ahci_platform.c
+++ b/drivers/ata/ahci_platform.c
@@ -33,6 +33,13 @@ static const struct ata_port_info ahci_port_info = {
.port_ops = _platform_ops,
};
+static const struct ata_port_info ahci_port_info_nolpm = {
+ .flags = AHCI_FLAG_COMMON | ATA_FLAG_NO_LPM,
+ .pio_mask = ATA_PIO4,
+ .udma_mask = ATA_UDMA6,
+ .port_ops = _platform_ops,
+};
+
static struct scsi_host_template ahci_platform_sht = {
AHCI_SHT(DRV_NAME),
};
@@ -41,6 +48,7 @@ static int ahci_probe(struct platform_device *pdev)
{
struct device *dev = >dev;
struct ahci_host_priv *hpriv;
+ const struct ata_port_info *port;
int rc;
hpriv = ahci_platform_get_resources(pdev);
@@ -57,7 +65,11 @@ static int ahci_probe(struct platform_device *pdev)
if (of_device_is_compatible(dev->of_node, "hisilicon,hisi-ahci"))
hpriv->flags |= AHCI_HFLAG_NO_FBS | AHCI_HFLAG_NO_NCQ;
- rc = ahci_platform_init_host(pdev, hpriv, _port_info,
+ port = acpi_device_get_match_data(dev);
+ if (!port)
+ port = _port_info;
+
+ rc = ahci_platform_init_host(pdev, hpriv, port,
_platform_sht);
if (rc)
goto disable_resources;
@@ -85,6 +97,7 @@ static const struct of_device_id ahci_of_match[] = {
MODULE_DEVICE_TABLE(of, ahci_of_match);
static const struct acpi_device_id ahci_acpi_match[] = {
+ { "APMC0D33", (unsigned long)_port_info_nolpm },
{ ACPI_DEVICE_CLASS(PCI_CLASS_STORAGE_SATA_AHCI, 0xff) },
{},
};
--
2.7.4
[PATCH v3] ata: Disable AHCI ALPM feature for Ampere Computing eMAG SATA
Due to hardware errata, Ampere Computing eMAG SATA can't support
AHCI ALPM feature. This patch disables the AHCI ALPM feature for
eMAG SATA.
Signed-off-by: Suman Trpathi
Signed-off-by: Rameshwar Prasad Sahu
---
Changes for v3:
* Fix the indentation and whitespace warnings.
Changes for v2:
* Introduce the new ata_port_info object which includes ATA_FLAG_NO_LPM.
* Include this object for eMAG SATA inside the acpi match table.
* Retrieve the ata_port_info from the acpi match table.
---
drivers/ata/ahci_platform.c | 15 ++-
1 file changed, 14 insertions(+), 1 deletion(-)
diff --git a/drivers/ata/ahci_platform.c b/drivers/ata/ahci_platform.c
index 99f9a89..9ba283f 100644
--- a/drivers/ata/ahci_platform.c
+++ b/drivers/ata/ahci_platform.c
@@ -33,6 +33,13 @@ static const struct ata_port_info ahci_port_info = {
.port_ops = _platform_ops,
};
+static const struct ata_port_info ahci_port_info_nolpm = {
+ .flags = AHCI_FLAG_COMMON | ATA_FLAG_NO_LPM,
+ .pio_mask = ATA_PIO4,
+ .udma_mask = ATA_UDMA6,
+ .port_ops = _platform_ops,
+};
+
static struct scsi_host_template ahci_platform_sht = {
AHCI_SHT(DRV_NAME),
};
@@ -41,6 +48,7 @@ static int ahci_probe(struct platform_device *pdev)
{
struct device *dev = >dev;
struct ahci_host_priv *hpriv;
+ const struct ata_port_info *port;
int rc;
hpriv = ahci_platform_get_resources(pdev);
@@ -57,7 +65,11 @@ static int ahci_probe(struct platform_device *pdev)
if (of_device_is_compatible(dev->of_node, "hisilicon,hisi-ahci"))
hpriv->flags |= AHCI_HFLAG_NO_FBS | AHCI_HFLAG_NO_NCQ;
- rc = ahci_platform_init_host(pdev, hpriv, _port_info,
+ port = acpi_device_get_match_data(dev);
+ if (!port)
+ port = _port_info;
+
+ rc = ahci_platform_init_host(pdev, hpriv, port,
_platform_sht);
if (rc)
goto disable_resources;
@@ -85,6 +97,7 @@ static const struct of_device_id ahci_of_match[] = {
MODULE_DEVICE_TABLE(of, ahci_of_match);
static const struct acpi_device_id ahci_acpi_match[] = {
+ { "APMC0D33", (unsigned long)_port_info_nolpm },
{ ACPI_DEVICE_CLASS(PCI_CLASS_STORAGE_SATA_AHCI, 0xff) },
{},
};
--
2.7.4
RE: [PATCH v3] ata: Disable AHCI ALPM feature for Ampere Computing eMAG SATA
Hi Hans,
I ran checkpatch and see no error. I will check my git-send-email
scripts/checkpatch.pl
0001-ata-Disable-AHCI-ALPM-feature-for-Ampere-Computing-e.patch total: 0
errors, 0 warnings, 39 lines checked
0001-ata-Disable-AHCI-ALPM-feature-for-Ampere-Computing-e.patch has no obvious
style problems and is ready for submission.
With regards,
Suman
-Original Message-
From: Hans de Goede
Sent: Thursday, September 6, 2018 12:32 AM
To: Suman Tripathi ; ax...@kernel.dk;
t...@kernel.org; linux-...@vger.kernel.org;
linux-arm-ker...@lists.infradead.org; linux-kernel@vger.kernel.org;
j...@perches.com; a...@arndb.de; gre...@linuxfoundation.org
Cc: Open Source Submission ; Rameshwar Sahu
Subject: Re: [PATCH v3] ata: Disable AHCI ALPM feature for Ampere Computing
eMAG SATA
[NOTICE: This email originated from an external sender. Please be mindful of
safe email handling and proprietary information protection practices.]
Hi,
On 06-09-18 06:33, Suman Tripathi wrote:
> Due to hardware errata, Ampere Computing eMAG SATA can't support AHCI
> ALPM feature. This patch disables the AHCI ALPM feature for eMAG SATA.
>
> Changes for v2:
>
> * Introduce the new ata_port_info object which includes ATA_FLAG_NO_LPM.
> * Include this object for eMAG SATA inside the acpi match table.
> * Retrieve the ata_port_info from the acpi match table.
>
> Changes for v3:
>
> * Fix the indentation and whitespace warnings.
>
> Signed-off-by: Suman Trpathi
> Signed-off-by: Rameshwar Prasad Sahu
>
Small remark, normally the changelog is put after the Signed-off-by messages
like
this:
"""
Signed-off-by: Suman Trpathi
Signed-off-by: Rameshwar Prasad Sahu
---
Changes for v3:
* Fix the indentation and whitespace warnings.
Changes for v2:
* Introduce the new ata_port_info object which includes ATA_FLAG_NO_LPM.
* Include this object for eMAG SATA inside the acpi match table.
* Retrieve the ata_port_info from the acpi match table.
"""
This will cause git am to remove it, so that the git history just has your
original commit message.
By itself this would not be a reason to request a new version, but it seems
you've copy and pasted the patch from "git format-patch" output into you mail
client. I tried to run checkpatch myself to make sure you caught all whitespace
issues and I got this:
[hans@shalem linux]$ scripts/checkpatch.pl ~/\[PATCH\ v3\]\ ata\:\ Disable\
AHCI\ ALPM\ feature\ for\ Ampere\ Computing\ eMAG\ SATA.eml
ERROR: patch seems to be corrupt (line wrapped?)
#177: FILE: drivers/ata/ahci_platform.c:34:
ERROR: DOS line endings
#178: FILE: drivers/ata/ahci_platform.c:35:
+static const struct ata_port_info ahci_port_info_nolpm = {^M$
ERROR: DOS line endings
#179: FILE: drivers/ata/ahci_platform.c:36:
+^I.flags^I^I= AHCI_FLAG_COMMON | ATA_FLAG_NO_LPM,^M$
ERROR: DOS line endings
#180: FILE: drivers/ata/ahci_platform.c:37:
+^I.pio_mask^I= ATA_PIO4,^M$
ERROR: DOS line endings
#181: FILE: drivers/ata/ahci_platform.c:38:
+^I.udma_mask^I= ATA_UDMA6,^M$
Followed by lots more errors, line 177 of the email is empty, while it should
contain a single space. This stripping of whitespace typically is the result of
copy pasting or some other processing of the patch.
Please try to re-send v3 using the "git send-email" command, so that we get a
patch which we can actually apply.
Regards,
Hans
> ---
> drivers/ata/ahci_platform.c | 15 ++-
> 1 file changed, 14 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/ata/ahci_platform.c b/drivers/ata/ahci_platform.c
> index 99f9a89..9ba283f 100644
> --- a/drivers/ata/ahci_platform.c
> +++ b/drivers/ata/ahci_platform.c
> @@ -33,6 +33,13 @@ static const struct ata_port_info ahci_port_info = {
> .port_ops = _platform_ops,
> };
>
> +static const struct ata_port_info ahci_port_info_nolpm = {
> + .flags = AHCI_FLAG_COMMON | ATA_FLAG_NO_LPM,
> + .pio_mask = ATA_PIO4,
> + .udma_mask = ATA_UDMA6,
> + .port_ops = _platform_ops,
> +};
> +
> static struct scsi_host_template ahci_platform_sht = {
> AHCI_SHT(DRV_NAME),
> };
> @@ -41,6 +48,7 @@ static int ahci_probe(struct platform_device *pdev)
> {
> struct device *dev = >dev;
> struct ahci_host_priv *hpriv;
> + const struct ata_port_info *port;
> int rc;
>
> hpriv = ahci_platform_get_resources(pdev);
> @@ -57,7 +65,11 @@ static int ahci_probe(struct platform_device *pdev)
> if (of_device_is_compatible(dev->of_node, "hisilicon,hisi-ahci"))
> hpriv->flags |= AHCI_HFLAG_NO_FBS | AHCI_HFLAG_NO_NCQ;
>
> - rc = ahci_platform_init_host(pdev, hpriv, _p
RE: [PATCH v3] ata: Disable AHCI ALPM feature for Ampere Computing eMAG SATA
Hi Hans,
I ran checkpatch and see no error. I will check my git-send-email
scripts/checkpatch.pl
0001-ata-Disable-AHCI-ALPM-feature-for-Ampere-Computing-e.patch total: 0
errors, 0 warnings, 39 lines checked
0001-ata-Disable-AHCI-ALPM-feature-for-Ampere-Computing-e.patch has no obvious
style problems and is ready for submission.
With regards,
Suman
-Original Message-
From: Hans de Goede
Sent: Thursday, September 6, 2018 12:32 AM
To: Suman Tripathi ; ax...@kernel.dk;
t...@kernel.org; linux-...@vger.kernel.org;
linux-arm-ker...@lists.infradead.org; linux-kernel@vger.kernel.org;
j...@perches.com; a...@arndb.de; gre...@linuxfoundation.org
Cc: Open Source Submission ; Rameshwar Sahu
Subject: Re: [PATCH v3] ata: Disable AHCI ALPM feature for Ampere Computing
eMAG SATA
[NOTICE: This email originated from an external sender. Please be mindful of
safe email handling and proprietary information protection practices.]
Hi,
On 06-09-18 06:33, Suman Tripathi wrote:
> Due to hardware errata, Ampere Computing eMAG SATA can't support AHCI
> ALPM feature. This patch disables the AHCI ALPM feature for eMAG SATA.
>
> Changes for v2:
>
> * Introduce the new ata_port_info object which includes ATA_FLAG_NO_LPM.
> * Include this object for eMAG SATA inside the acpi match table.
> * Retrieve the ata_port_info from the acpi match table.
>
> Changes for v3:
>
> * Fix the indentation and whitespace warnings.
>
> Signed-off-by: Suman Trpathi
> Signed-off-by: Rameshwar Prasad Sahu
>
Small remark, normally the changelog is put after the Signed-off-by messages
like
this:
"""
Signed-off-by: Suman Trpathi
Signed-off-by: Rameshwar Prasad Sahu
---
Changes for v3:
* Fix the indentation and whitespace warnings.
Changes for v2:
* Introduce the new ata_port_info object which includes ATA_FLAG_NO_LPM.
* Include this object for eMAG SATA inside the acpi match table.
* Retrieve the ata_port_info from the acpi match table.
"""
This will cause git am to remove it, so that the git history just has your
original commit message.
By itself this would not be a reason to request a new version, but it seems
you've copy and pasted the patch from "git format-patch" output into you mail
client. I tried to run checkpatch myself to make sure you caught all whitespace
issues and I got this:
[hans@shalem linux]$ scripts/checkpatch.pl ~/\[PATCH\ v3\]\ ata\:\ Disable\
AHCI\ ALPM\ feature\ for\ Ampere\ Computing\ eMAG\ SATA.eml
ERROR: patch seems to be corrupt (line wrapped?)
#177: FILE: drivers/ata/ahci_platform.c:34:
ERROR: DOS line endings
#178: FILE: drivers/ata/ahci_platform.c:35:
+static const struct ata_port_info ahci_port_info_nolpm = {^M$
ERROR: DOS line endings
#179: FILE: drivers/ata/ahci_platform.c:36:
+^I.flags^I^I= AHCI_FLAG_COMMON | ATA_FLAG_NO_LPM,^M$
ERROR: DOS line endings
#180: FILE: drivers/ata/ahci_platform.c:37:
+^I.pio_mask^I= ATA_PIO4,^M$
ERROR: DOS line endings
#181: FILE: drivers/ata/ahci_platform.c:38:
+^I.udma_mask^I= ATA_UDMA6,^M$
Followed by lots more errors, line 177 of the email is empty, while it should
contain a single space. This stripping of whitespace typically is the result of
copy pasting or some other processing of the patch.
Please try to re-send v3 using the "git send-email" command, so that we get a
patch which we can actually apply.
Regards,
Hans
> ---
> drivers/ata/ahci_platform.c | 15 ++-
> 1 file changed, 14 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/ata/ahci_platform.c b/drivers/ata/ahci_platform.c
> index 99f9a89..9ba283f 100644
> --- a/drivers/ata/ahci_platform.c
> +++ b/drivers/ata/ahci_platform.c
> @@ -33,6 +33,13 @@ static const struct ata_port_info ahci_port_info = {
> .port_ops = _platform_ops,
> };
>
> +static const struct ata_port_info ahci_port_info_nolpm = {
> + .flags = AHCI_FLAG_COMMON | ATA_FLAG_NO_LPM,
> + .pio_mask = ATA_PIO4,
> + .udma_mask = ATA_UDMA6,
> + .port_ops = _platform_ops,
> +};
> +
> static struct scsi_host_template ahci_platform_sht = {
> AHCI_SHT(DRV_NAME),
> };
> @@ -41,6 +48,7 @@ static int ahci_probe(struct platform_device *pdev)
> {
> struct device *dev = >dev;
> struct ahci_host_priv *hpriv;
> + const struct ata_port_info *port;
> int rc;
>
> hpriv = ahci_platform_get_resources(pdev);
> @@ -57,7 +65,11 @@ static int ahci_probe(struct platform_device *pdev)
> if (of_device_is_compatible(dev->of_node, "hisilicon,hisi-ahci"))
> hpriv->flags |= AHCI_HFLAG_NO_FBS | AHCI_HFLAG_NO_NCQ;
>
> - rc = ahci_platform_init_host(pdev, hpriv, _p
[PATCH v3] ata: Disable AHCI ALPM feature for Ampere Computing eMAG SATA
Due to hardware errata, Ampere Computing eMAG SATA can't support
AHCI ALPM feature. This patch disables the AHCI ALPM feature for
eMAG SATA.
Changes for v2:
* Introduce the new ata_port_info object which includes ATA_FLAG_NO_LPM.
* Include this object for eMAG SATA inside the acpi match table.
* Retrieve the ata_port_info from the acpi match table.
Changes for v3:
* Fix the indentation and whitespace warnings.
Signed-off-by: Suman Trpathi
Signed-off-by: Rameshwar Prasad Sahu
---
drivers/ata/ahci_platform.c | 15 ++-
1 file changed, 14 insertions(+), 1 deletion(-)
diff --git a/drivers/ata/ahci_platform.c b/drivers/ata/ahci_platform.c
index 99f9a89..9ba283f 100644
--- a/drivers/ata/ahci_platform.c
+++ b/drivers/ata/ahci_platform.c
@@ -33,6 +33,13 @@ static const struct ata_port_info ahci_port_info = {
.port_ops = _platform_ops,
};
+static const struct ata_port_info ahci_port_info_nolpm = {
+ .flags = AHCI_FLAG_COMMON | ATA_FLAG_NO_LPM,
+ .pio_mask = ATA_PIO4,
+ .udma_mask = ATA_UDMA6,
+ .port_ops = _platform_ops,
+};
+
static struct scsi_host_template ahci_platform_sht = {
AHCI_SHT(DRV_NAME),
};
@@ -41,6 +48,7 @@ static int ahci_probe(struct platform_device *pdev)
{
struct device *dev = >dev;
struct ahci_host_priv *hpriv;
+ const struct ata_port_info *port;
int rc;
hpriv = ahci_platform_get_resources(pdev);
@@ -57,7 +65,11 @@ static int ahci_probe(struct platform_device *pdev)
if (of_device_is_compatible(dev->of_node, "hisilicon,hisi-ahci"))
hpriv->flags |= AHCI_HFLAG_NO_FBS | AHCI_HFLAG_NO_NCQ;
- rc = ahci_platform_init_host(pdev, hpriv, _port_info,
+ port = acpi_device_get_match_data(dev);
+ if (!port)
+ port = _port_info;
+
+ rc = ahci_platform_init_host(pdev, hpriv, port,
_platform_sht);
if (rc)
goto disable_resources;
@@ -85,6 +97,7 @@ static const struct of_device_id ahci_of_match[] = {
MODULE_DEVICE_TABLE(of, ahci_of_match);
static const struct acpi_device_id ahci_acpi_match[] = {
+ { "APMC0D33", (unsigned long)_port_info_nolpm },
{ ACPI_DEVICE_CLASS(PCI_CLASS_STORAGE_SATA_AHCI, 0xff) },
{},
};
--
2.7.4
[PATCH v3] ata: Disable AHCI ALPM feature for Ampere Computing eMAG SATA
Due to hardware errata, Ampere Computing eMAG SATA can't support
AHCI ALPM feature. This patch disables the AHCI ALPM feature for
eMAG SATA.
Changes for v2:
* Introduce the new ata_port_info object which includes ATA_FLAG_NO_LPM.
* Include this object for eMAG SATA inside the acpi match table.
* Retrieve the ata_port_info from the acpi match table.
Changes for v3:
* Fix the indentation and whitespace warnings.
Signed-off-by: Suman Trpathi
Signed-off-by: Rameshwar Prasad Sahu
---
drivers/ata/ahci_platform.c | 15 ++-
1 file changed, 14 insertions(+), 1 deletion(-)
diff --git a/drivers/ata/ahci_platform.c b/drivers/ata/ahci_platform.c
index 99f9a89..9ba283f 100644
--- a/drivers/ata/ahci_platform.c
+++ b/drivers/ata/ahci_platform.c
@@ -33,6 +33,13 @@ static const struct ata_port_info ahci_port_info = {
.port_ops = _platform_ops,
};
+static const struct ata_port_info ahci_port_info_nolpm = {
+ .flags = AHCI_FLAG_COMMON | ATA_FLAG_NO_LPM,
+ .pio_mask = ATA_PIO4,
+ .udma_mask = ATA_UDMA6,
+ .port_ops = _platform_ops,
+};
+
static struct scsi_host_template ahci_platform_sht = {
AHCI_SHT(DRV_NAME),
};
@@ -41,6 +48,7 @@ static int ahci_probe(struct platform_device *pdev)
{
struct device *dev = >dev;
struct ahci_host_priv *hpriv;
+ const struct ata_port_info *port;
int rc;
hpriv = ahci_platform_get_resources(pdev);
@@ -57,7 +65,11 @@ static int ahci_probe(struct platform_device *pdev)
if (of_device_is_compatible(dev->of_node, "hisilicon,hisi-ahci"))
hpriv->flags |= AHCI_HFLAG_NO_FBS | AHCI_HFLAG_NO_NCQ;
- rc = ahci_platform_init_host(pdev, hpriv, _port_info,
+ port = acpi_device_get_match_data(dev);
+ if (!port)
+ port = _port_info;
+
+ rc = ahci_platform_init_host(pdev, hpriv, port,
_platform_sht);
if (rc)
goto disable_resources;
@@ -85,6 +97,7 @@ static const struct of_device_id ahci_of_match[] = {
MODULE_DEVICE_TABLE(of, ahci_of_match);
static const struct acpi_device_id ahci_acpi_match[] = {
+ { "APMC0D33", (unsigned long)_port_info_nolpm },
{ ACPI_DEVICE_CLASS(PCI_CLASS_STORAGE_SATA_AHCI, 0xff) },
{},
};
--
2.7.4
RE: [PATCH v2] ata: Disable AHCI ALPM feature for Ampere Computing eMAG SATA
Hi Hans
Thanks for your quick review !!
With regards,
Suman
-Original Message-
From: Hans de Goede
Sent: Wednesday, September 5, 2018 1:16 PM
To: Suman Tripathi ; ax...@kernel.dk;
t...@kernel.org; linux-...@vger.kernel.org;
linux-arm-ker...@lists.infradead.org; linux-kernel@vger.kernel.org;
j...@perches.com; a...@arndb.de; gre...@linuxfoundation.org
Cc: Open Source Submission ; Rameshwar Sahu
Subject: Re: [PATCH v2] ata: Disable AHCI ALPM feature for Ampere Computing
eMAG SATA
[NOTICE: This email originated from an external sender. Please be mindful of
safe email handling and proprietary information protection practices.]
Hi,
On 05-09-18 22:12, Suman Tripathi wrote:
> Due to hardware errata, Ampere Computing eMAG SATA can't support AHCI
> ALPM feature. This patch disables the AHCI ALPM feature for eMAG SATA.
>
> Changes for v2:
>
> * Introduce the new ata_port_info object which includes ATA_FLAG_NO_LPM.
> * Include this object for eMAG SATA inside the acpi match table.
> * Retrieve the ata_port_info from the acpi match table.
>
> Signed-off-by: Suman Trpathi
> Signed-off-by: Rameshwar Prasad Sahu
>
> ---
> drivers/ata/ahci_platform.c | 17 +++--
> 1 file changed, 15 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/ata/ahci_platform.c b/drivers/ata/ahci_platform.c
> index 99f9a89..c3043f6 100644
> --- a/drivers/ata/ahci_platform.c
> +++ b/drivers/ata/ahci_platform.c
> @@ -33,6 +33,13 @@
> .port_ops = _platform_ops,
> };
>
> +static const struct ata_port_info ahci_port_info_nolpm = {
> + .flags = AHCI_FLAG_COMMON | ATA_FLAG_NO_LPM,
> + .pio_mask = ATA_PIO4,
> + .udma_mask = ATA_UDMA6,
> + .port_ops = _platform_ops,
> +};
> +
> static struct scsi_host_template ahci_platform_sht = {
> AHCI_SHT(DRV_NAME),
> };
> @@ -41,7 +48,8 @@ static int ahci_probe(struct platform_device *pdev)
> {
> struct device *dev = >dev;
> struct ahci_host_priv *hpriv;
> - int rc;
> + const struct ata_port_info *port;
> +int rc;
You are accidentally changing the indentation of rc here.
[Suman Tripathi] yes will fix in v3
Please fix this and run scripts/checkpatch.pl on the patch before submitting
v3. Otherwise v2 looks good.
Regards,
Hans
>
> hpriv = ahci_platform_get_resources(pdev);
> if (IS_ERR(hpriv))
> @@ -57,7 +65,11 @@ static int ahci_probe(struct platform_device *pdev)
> if (of_device_is_compatible(dev->of_node, "hisilicon,hisi-ahci"))
> hpriv->flags |= AHCI_HFLAG_NO_FBS | AHCI_HFLAG_NO_NCQ;
>
> - rc = ahci_platform_init_host(pdev, hpriv, _port_info,
> + port = acpi_device_get_match_data(dev);
> + if (!port)
> + port = _port_info;
> +
> + rc = ahci_platform_init_host(pdev, hpriv, port,
>_platform_sht);
> if (rc)
> goto disable_resources;
> @@ -85,6 +97,7 @@ static SIMPLE_DEV_PM_OPS(ahci_pm_ops, ahci_platform_suspend,
> MODULE_DEVICE_TABLE(of, ahci_of_match);
>
> static const struct acpi_device_id ahci_acpi_match[] = {
> + { "APMC0D33", (unsigned long)_port_info_nolpm },
> { ACPI_DEVICE_CLASS(PCI_CLASS_STORAGE_SATA_AHCI, 0xff) },
> {},
> };
>
RE: [PATCH v2] ata: Disable AHCI ALPM feature for Ampere Computing eMAG SATA
Hi Hans
Thanks for your quick review !!
With regards,
Suman
-Original Message-
From: Hans de Goede
Sent: Wednesday, September 5, 2018 1:16 PM
To: Suman Tripathi ; ax...@kernel.dk;
t...@kernel.org; linux-...@vger.kernel.org;
linux-arm-ker...@lists.infradead.org; linux-kernel@vger.kernel.org;
j...@perches.com; a...@arndb.de; gre...@linuxfoundation.org
Cc: Open Source Submission ; Rameshwar Sahu
Subject: Re: [PATCH v2] ata: Disable AHCI ALPM feature for Ampere Computing
eMAG SATA
[NOTICE: This email originated from an external sender. Please be mindful of
safe email handling and proprietary information protection practices.]
Hi,
On 05-09-18 22:12, Suman Tripathi wrote:
> Due to hardware errata, Ampere Computing eMAG SATA can't support AHCI
> ALPM feature. This patch disables the AHCI ALPM feature for eMAG SATA.
>
> Changes for v2:
>
> * Introduce the new ata_port_info object which includes ATA_FLAG_NO_LPM.
> * Include this object for eMAG SATA inside the acpi match table.
> * Retrieve the ata_port_info from the acpi match table.
>
> Signed-off-by: Suman Trpathi
> Signed-off-by: Rameshwar Prasad Sahu
>
> ---
> drivers/ata/ahci_platform.c | 17 +++--
> 1 file changed, 15 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/ata/ahci_platform.c b/drivers/ata/ahci_platform.c
> index 99f9a89..c3043f6 100644
> --- a/drivers/ata/ahci_platform.c
> +++ b/drivers/ata/ahci_platform.c
> @@ -33,6 +33,13 @@
> .port_ops = _platform_ops,
> };
>
> +static const struct ata_port_info ahci_port_info_nolpm = {
> + .flags = AHCI_FLAG_COMMON | ATA_FLAG_NO_LPM,
> + .pio_mask = ATA_PIO4,
> + .udma_mask = ATA_UDMA6,
> + .port_ops = _platform_ops,
> +};
> +
> static struct scsi_host_template ahci_platform_sht = {
> AHCI_SHT(DRV_NAME),
> };
> @@ -41,7 +48,8 @@ static int ahci_probe(struct platform_device *pdev)
> {
> struct device *dev = >dev;
> struct ahci_host_priv *hpriv;
> - int rc;
> + const struct ata_port_info *port;
> +int rc;
You are accidentally changing the indentation of rc here.
[Suman Tripathi] yes will fix in v3
Please fix this and run scripts/checkpatch.pl on the patch before submitting
v3. Otherwise v2 looks good.
Regards,
Hans
>
> hpriv = ahci_platform_get_resources(pdev);
> if (IS_ERR(hpriv))
> @@ -57,7 +65,11 @@ static int ahci_probe(struct platform_device *pdev)
> if (of_device_is_compatible(dev->of_node, "hisilicon,hisi-ahci"))
> hpriv->flags |= AHCI_HFLAG_NO_FBS | AHCI_HFLAG_NO_NCQ;
>
> - rc = ahci_platform_init_host(pdev, hpriv, _port_info,
> + port = acpi_device_get_match_data(dev);
> + if (!port)
> + port = _port_info;
> +
> + rc = ahci_platform_init_host(pdev, hpriv, port,
>_platform_sht);
> if (rc)
> goto disable_resources;
> @@ -85,6 +97,7 @@ static SIMPLE_DEV_PM_OPS(ahci_pm_ops, ahci_platform_suspend,
> MODULE_DEVICE_TABLE(of, ahci_of_match);
>
> static const struct acpi_device_id ahci_acpi_match[] = {
> + { "APMC0D33", (unsigned long)_port_info_nolpm },
> { ACPI_DEVICE_CLASS(PCI_CLASS_STORAGE_SATA_AHCI, 0xff) },
> {},
> };
>
[PATCH v2] ata: Disable AHCI ALPM feature for Ampere Computing eMAG SATA
Due to hardware errata, Ampere Computing eMAG SATA can't support
AHCI ALPM feature. This patch disables the AHCI ALPM feature for
eMAG SATA.
Changes for v2:
* Introduce the new ata_port_info object which includes ATA_FLAG_NO_LPM.
* Include this object for eMAG SATA inside the acpi match table.
* Retrieve the ata_port_info from the acpi match table.
Signed-off-by: Suman Trpathi
Signed-off-by: Rameshwar Prasad Sahu
---
drivers/ata/ahci_platform.c | 17 +++--
1 file changed, 15 insertions(+), 2 deletions(-)
diff --git a/drivers/ata/ahci_platform.c b/drivers/ata/ahci_platform.c
index 99f9a89..c3043f6 100644
--- a/drivers/ata/ahci_platform.c
+++ b/drivers/ata/ahci_platform.c
@@ -33,6 +33,13 @@
.port_ops = _platform_ops,
};
+static const struct ata_port_info ahci_port_info_nolpm = {
+ .flags = AHCI_FLAG_COMMON | ATA_FLAG_NO_LPM,
+ .pio_mask = ATA_PIO4,
+ .udma_mask = ATA_UDMA6,
+ .port_ops = _platform_ops,
+};
+
static struct scsi_host_template ahci_platform_sht = {
AHCI_SHT(DRV_NAME),
};
@@ -41,7 +48,8 @@ static int ahci_probe(struct platform_device *pdev)
{
struct device *dev = >dev;
struct ahci_host_priv *hpriv;
- int rc;
+ const struct ata_port_info *port;
+int rc;
hpriv = ahci_platform_get_resources(pdev);
if (IS_ERR(hpriv))
@@ -57,7 +65,11 @@ static int ahci_probe(struct platform_device *pdev)
if (of_device_is_compatible(dev->of_node, "hisilicon,hisi-ahci"))
hpriv->flags |= AHCI_HFLAG_NO_FBS | AHCI_HFLAG_NO_NCQ;
- rc = ahci_platform_init_host(pdev, hpriv, _port_info,
+ port = acpi_device_get_match_data(dev);
+ if (!port)
+ port = _port_info;
+
+ rc = ahci_platform_init_host(pdev, hpriv, port,
_platform_sht);
if (rc)
goto disable_resources;
@@ -85,6 +97,7 @@ static SIMPLE_DEV_PM_OPS(ahci_pm_ops, ahci_platform_suspend,
MODULE_DEVICE_TABLE(of, ahci_of_match);
static const struct acpi_device_id ahci_acpi_match[] = {
+ { "APMC0D33", (unsigned long)_port_info_nolpm },
{ ACPI_DEVICE_CLASS(PCI_CLASS_STORAGE_SATA_AHCI, 0xff) },
{},
};
--
1.8.3.1
[PATCH v2] ata: Disable AHCI ALPM feature for Ampere Computing eMAG SATA
Due to hardware errata, Ampere Computing eMAG SATA can't support
AHCI ALPM feature. This patch disables the AHCI ALPM feature for
eMAG SATA.
Changes for v2:
* Introduce the new ata_port_info object which includes ATA_FLAG_NO_LPM.
* Include this object for eMAG SATA inside the acpi match table.
* Retrieve the ata_port_info from the acpi match table.
Signed-off-by: Suman Trpathi
Signed-off-by: Rameshwar Prasad Sahu
---
drivers/ata/ahci_platform.c | 17 +++--
1 file changed, 15 insertions(+), 2 deletions(-)
diff --git a/drivers/ata/ahci_platform.c b/drivers/ata/ahci_platform.c
index 99f9a89..c3043f6 100644
--- a/drivers/ata/ahci_platform.c
+++ b/drivers/ata/ahci_platform.c
@@ -33,6 +33,13 @@
.port_ops = _platform_ops,
};
+static const struct ata_port_info ahci_port_info_nolpm = {
+ .flags = AHCI_FLAG_COMMON | ATA_FLAG_NO_LPM,
+ .pio_mask = ATA_PIO4,
+ .udma_mask = ATA_UDMA6,
+ .port_ops = _platform_ops,
+};
+
static struct scsi_host_template ahci_platform_sht = {
AHCI_SHT(DRV_NAME),
};
@@ -41,7 +48,8 @@ static int ahci_probe(struct platform_device *pdev)
{
struct device *dev = >dev;
struct ahci_host_priv *hpriv;
- int rc;
+ const struct ata_port_info *port;
+int rc;
hpriv = ahci_platform_get_resources(pdev);
if (IS_ERR(hpriv))
@@ -57,7 +65,11 @@ static int ahci_probe(struct platform_device *pdev)
if (of_device_is_compatible(dev->of_node, "hisilicon,hisi-ahci"))
hpriv->flags |= AHCI_HFLAG_NO_FBS | AHCI_HFLAG_NO_NCQ;
- rc = ahci_platform_init_host(pdev, hpriv, _port_info,
+ port = acpi_device_get_match_data(dev);
+ if (!port)
+ port = _port_info;
+
+ rc = ahci_platform_init_host(pdev, hpriv, port,
_platform_sht);
if (rc)
goto disable_resources;
@@ -85,6 +97,7 @@ static SIMPLE_DEV_PM_OPS(ahci_pm_ops, ahci_platform_suspend,
MODULE_DEVICE_TABLE(of, ahci_of_match);
static const struct acpi_device_id ahci_acpi_match[] = {
+ { "APMC0D33", (unsigned long)_port_info_nolpm },
{ ACPI_DEVICE_CLASS(PCI_CLASS_STORAGE_SATA_AHCI, 0xff) },
{},
};
--
1.8.3.1
RE: [PATCH] ata: Disable AHCI ALPM feature for Ampere Computing eMAG SATA
Hi Hans
Thanks for your fast response.
With regards,
Suman
Please note my new email address → stripa...@amperecomputing.com
-Original Message-
From: Hans de Goede
Sent: Monday, August 27, 2018 12:09 PM
To: Suman Tripathi ; t...@kernel.org;
linux-...@vger.kernel.org; linux-arm-ker...@lists.infradead.org;
linux-kernel@vger.kernel.org; j...@perches.com; a...@arndb.de;
gre...@linuxfoundation.org
Cc: Open Source Submission ; Rameshwar P Sahu
; Jens Axboe
Subject: Re: [PATCH] ata: Disable AHCI ALPM feature for Ampere Computing eMAG
SATA
[NOTICE: This email originated from an external sender. Please be mindful of
safe email handling and proprietary information protection practices.]
Hi,
On 27-08-18 20:47, Suman Tripathi wrote:
> Due to hardware errata, Ampere Computing eMAG SATA can't support AHCI
> ALPM feature. This patch disables the AHCI ALPM feature for eMAG SATA.
>
> Signed-off-by: Suman Tripathi
> Signed-off-by: Rameshwar Prasad Sahu
>
Thank you for the patch. 2 remarks:
1) The ata code is maintained by Jens Axboe (added to the Cc) now, this is a
very recent change, which still has to hit MAINTAINERS
[Suman Tripathi] Didn't still see him for libata subsystem. Surely will fix the
comments cc him for the next version. I see him in the scsi subsystem.
2) See below
> ---
> drivers/ata/ahci_platform.c | 13 -
> 1 file changed, 12 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/ata/ahci_platform.c b/drivers/ata/ahci_platform.c
> index 99f9a89..0d0233e 100644
> --- a/drivers/ata/ahci_platform.c
> +++ b/drivers/ata/ahci_platform.c
> @@ -26,7 +26,7 @@
>
> #define DRV_NAME "ahci"
>
> -static const struct ata_port_info ahci_port_info = {
> +static struct ata_port_info ahci_port_info = {
> .flags = AHCI_FLAG_COMMON,
> .pio_mask = ATA_PIO4,
> .udma_mask = ATA_UDMA6,
Please do not remove const here, if you need to make a shared info struct like
this non const you are usually doing something wrong (see below).
> @@ -41,6 +41,8 @@ static int ahci_probe(struct platform_device *pdev)
> {
> struct device *dev = >dev;
> struct ahci_host_priv *hpriv;
> + struct acpi_device_info *info;
> + acpi_status status;
> int rc;
>
> hpriv = ahci_platform_get_resources(pdev);
> @@ -57,6 +59,15 @@ static int ahci_probe(struct platform_device *pdev)
> if (of_device_is_compatible(dev->of_node, "hisilicon,hisi-ahci"))
> hpriv->flags |= AHCI_HFLAG_NO_FBS | AHCI_HFLAG_NO_NCQ;
>
> + status = acpi_get_object_info(ACPI_HANDLE(dev), );
> + if (ACPI_SUCCESS(status)) {
> + if (info->valid & ACPI_VALID_HID) {
> + if (!strcmp("APMC0D33", info->hardware_id.string))
> + ahci_port_info.flags |= ATA_FLAG_NO_LPM;
> + }
> + ACPI_FREE(info);
> + }
> +
> rc = ahci_platform_init_host(pdev, hpriv, _port_info,
>_platform_sht);
> if (rc)
The normal way to get specific behavior for a specific ACPI HID is to put the
HID in the ahci_acpi_match table and use the acpi_device_id field to pass some
flags (or a pointer).
[Suman Tripathi] Agree on this.
So the proper way to fix this is to do something like this:
1) Add:
static const struct ata_port_info ahci_port_info_nolpm = {
.flags = AHCI_FLAG_COMMON | ATA_FLAG_NO_LPM,
.pio_mask = ATA_PIO4,
.udma_mask = ATA_UDMA6,
.port_ops = _platform_ops,
};
2) Modify ahci_acpi_match table to:
static const struct acpi_device_id ahci_acpi_match[] = {
{ "APMC0D33", (unsigned long)_port_info_nolpm },
{ ACPI_DEVICE_CLASS(PCI_CLASS_STORAGE_SATA_AHCI, 0xff) },
{},
};
3) In ahci_probe() do:
const struct ata_port_info *port;
...
port = acpi_device_get_match_data(dev);
if (!port)
port = _port_info;
rc = ahci_platform_init_host(pdev, hpriv, port, _platform_sht);
Regards,
Hans
RE: [PATCH] ata: Disable AHCI ALPM feature for Ampere Computing eMAG SATA
Hi Hans
Thanks for your fast response.
With regards,
Suman
Please note my new email address → stripa...@amperecomputing.com
-Original Message-
From: Hans de Goede
Sent: Monday, August 27, 2018 12:09 PM
To: Suman Tripathi ; t...@kernel.org;
linux-...@vger.kernel.org; linux-arm-ker...@lists.infradead.org;
linux-kernel@vger.kernel.org; j...@perches.com; a...@arndb.de;
gre...@linuxfoundation.org
Cc: Open Source Submission ; Rameshwar P Sahu
; Jens Axboe
Subject: Re: [PATCH] ata: Disable AHCI ALPM feature for Ampere Computing eMAG
SATA
[NOTICE: This email originated from an external sender. Please be mindful of
safe email handling and proprietary information protection practices.]
Hi,
On 27-08-18 20:47, Suman Tripathi wrote:
> Due to hardware errata, Ampere Computing eMAG SATA can't support AHCI
> ALPM feature. This patch disables the AHCI ALPM feature for eMAG SATA.
>
> Signed-off-by: Suman Tripathi
> Signed-off-by: Rameshwar Prasad Sahu
>
Thank you for the patch. 2 remarks:
1) The ata code is maintained by Jens Axboe (added to the Cc) now, this is a
very recent change, which still has to hit MAINTAINERS
[Suman Tripathi] Didn't still see him for libata subsystem. Surely will fix the
comments cc him for the next version. I see him in the scsi subsystem.
2) See below
> ---
> drivers/ata/ahci_platform.c | 13 -
> 1 file changed, 12 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/ata/ahci_platform.c b/drivers/ata/ahci_platform.c
> index 99f9a89..0d0233e 100644
> --- a/drivers/ata/ahci_platform.c
> +++ b/drivers/ata/ahci_platform.c
> @@ -26,7 +26,7 @@
>
> #define DRV_NAME "ahci"
>
> -static const struct ata_port_info ahci_port_info = {
> +static struct ata_port_info ahci_port_info = {
> .flags = AHCI_FLAG_COMMON,
> .pio_mask = ATA_PIO4,
> .udma_mask = ATA_UDMA6,
Please do not remove const here, if you need to make a shared info struct like
this non const you are usually doing something wrong (see below).
> @@ -41,6 +41,8 @@ static int ahci_probe(struct platform_device *pdev)
> {
> struct device *dev = >dev;
> struct ahci_host_priv *hpriv;
> + struct acpi_device_info *info;
> + acpi_status status;
> int rc;
>
> hpriv = ahci_platform_get_resources(pdev);
> @@ -57,6 +59,15 @@ static int ahci_probe(struct platform_device *pdev)
> if (of_device_is_compatible(dev->of_node, "hisilicon,hisi-ahci"))
> hpriv->flags |= AHCI_HFLAG_NO_FBS | AHCI_HFLAG_NO_NCQ;
>
> + status = acpi_get_object_info(ACPI_HANDLE(dev), );
> + if (ACPI_SUCCESS(status)) {
> + if (info->valid & ACPI_VALID_HID) {
> + if (!strcmp("APMC0D33", info->hardware_id.string))
> + ahci_port_info.flags |= ATA_FLAG_NO_LPM;
> + }
> + ACPI_FREE(info);
> + }
> +
> rc = ahci_platform_init_host(pdev, hpriv, _port_info,
>_platform_sht);
> if (rc)
The normal way to get specific behavior for a specific ACPI HID is to put the
HID in the ahci_acpi_match table and use the acpi_device_id field to pass some
flags (or a pointer).
[Suman Tripathi] Agree on this.
So the proper way to fix this is to do something like this:
1) Add:
static const struct ata_port_info ahci_port_info_nolpm = {
.flags = AHCI_FLAG_COMMON | ATA_FLAG_NO_LPM,
.pio_mask = ATA_PIO4,
.udma_mask = ATA_UDMA6,
.port_ops = _platform_ops,
};
2) Modify ahci_acpi_match table to:
static const struct acpi_device_id ahci_acpi_match[] = {
{ "APMC0D33", (unsigned long)_port_info_nolpm },
{ ACPI_DEVICE_CLASS(PCI_CLASS_STORAGE_SATA_AHCI, 0xff) },
{},
};
3) In ahci_probe() do:
const struct ata_port_info *port;
...
port = acpi_device_get_match_data(dev);
if (!port)
port = _port_info;
rc = ahci_platform_init_host(pdev, hpriv, port, _platform_sht);
Regards,
Hans
[PATCH] ata: Disable AHCI ALPM feature for Ampere Computing eMAG SATA
Due to hardware errata, Ampere Computing eMAG SATA can't support
AHCI ALPM feature. This patch disables the AHCI ALPM feature for
eMAG SATA.
Signed-off-by: Suman Tripathi
Signed-off-by: Rameshwar Prasad Sahu
---
drivers/ata/ahci_platform.c | 13 -
1 file changed, 12 insertions(+), 1 deletion(-)
diff --git a/drivers/ata/ahci_platform.c b/drivers/ata/ahci_platform.c
index 99f9a89..0d0233e 100644
--- a/drivers/ata/ahci_platform.c
+++ b/drivers/ata/ahci_platform.c
@@ -26,7 +26,7 @@
#define DRV_NAME "ahci"
-static const struct ata_port_info ahci_port_info = {
+static struct ata_port_info ahci_port_info = {
.flags = AHCI_FLAG_COMMON,
.pio_mask = ATA_PIO4,
.udma_mask = ATA_UDMA6,
@@ -41,6 +41,8 @@ static int ahci_probe(struct platform_device *pdev)
{
struct device *dev = >dev;
struct ahci_host_priv *hpriv;
+ struct acpi_device_info *info;
+ acpi_status status;
int rc;
hpriv = ahci_platform_get_resources(pdev);
@@ -57,6 +59,15 @@ static int ahci_probe(struct platform_device *pdev)
if (of_device_is_compatible(dev->of_node, "hisilicon,hisi-ahci"))
hpriv->flags |= AHCI_HFLAG_NO_FBS | AHCI_HFLAG_NO_NCQ;
+ status = acpi_get_object_info(ACPI_HANDLE(dev), );
+ if (ACPI_SUCCESS(status)) {
+ if (info->valid & ACPI_VALID_HID) {
+ if (!strcmp("APMC0D33", info->hardware_id.string))
+ ahci_port_info.flags |= ATA_FLAG_NO_LPM;
+ }
+ ACPI_FREE(info);
+ }
+
rc = ahci_platform_init_host(pdev, hpriv, _port_info,
_platform_sht);
if (rc)
--
1.8.3.1
[PATCH] ata: Disable AHCI ALPM feature for Ampere Computing eMAG SATA
Due to hardware errata, Ampere Computing eMAG SATA can't support
AHCI ALPM feature. This patch disables the AHCI ALPM feature for
eMAG SATA.
Signed-off-by: Suman Tripathi
Signed-off-by: Rameshwar Prasad Sahu
---
drivers/ata/ahci_platform.c | 13 -
1 file changed, 12 insertions(+), 1 deletion(-)
diff --git a/drivers/ata/ahci_platform.c b/drivers/ata/ahci_platform.c
index 99f9a89..0d0233e 100644
--- a/drivers/ata/ahci_platform.c
+++ b/drivers/ata/ahci_platform.c
@@ -26,7 +26,7 @@
#define DRV_NAME "ahci"
-static const struct ata_port_info ahci_port_info = {
+static struct ata_port_info ahci_port_info = {
.flags = AHCI_FLAG_COMMON,
.pio_mask = ATA_PIO4,
.udma_mask = ATA_UDMA6,
@@ -41,6 +41,8 @@ static int ahci_probe(struct platform_device *pdev)
{
struct device *dev = >dev;
struct ahci_host_priv *hpriv;
+ struct acpi_device_info *info;
+ acpi_status status;
int rc;
hpriv = ahci_platform_get_resources(pdev);
@@ -57,6 +59,15 @@ static int ahci_probe(struct platform_device *pdev)
if (of_device_is_compatible(dev->of_node, "hisilicon,hisi-ahci"))
hpriv->flags |= AHCI_HFLAG_NO_FBS | AHCI_HFLAG_NO_NCQ;
+ status = acpi_get_object_info(ACPI_HANDLE(dev), );
+ if (ACPI_SUCCESS(status)) {
+ if (info->valid & ACPI_VALID_HID) {
+ if (!strcmp("APMC0D33", info->hardware_id.string))
+ ahci_port_info.flags |= ATA_FLAG_NO_LPM;
+ }
+ ACPI_FREE(info);
+ }
+
rc = ahci_platform_init_host(pdev, hpriv, _port_info,
_platform_sht);
if (rc)
--
1.8.3.1
[PATCH] ata: Disable AHCI ALPM feature for Ampere Computing eMAG SATA
Due to hardware errata, Ampere Computing eMAG SATA can't support
AHCI ALPM feature. This patch disables the AHCI ALPM feature for
eMAG SATA.
Signed-off-by: Suman Tripathi
Signed-off-by: Rameshwar Prasad Sahu
---
drivers/ata/ahci_platform.c | 13 -
1 file changed, 12 insertions(+), 1 deletion(-)
diff --git a/drivers/ata/ahci_platform.c b/drivers/ata/ahci_platform.c
index 99f9a89..0d0233e 100644
--- a/drivers/ata/ahci_platform.c
+++ b/drivers/ata/ahci_platform.c
@@ -26,7 +26,7 @@
#define DRV_NAME "ahci"
-static const struct ata_port_info ahci_port_info = {
+static struct ata_port_info ahci_port_info = {
.flags = AHCI_FLAG_COMMON,
.pio_mask = ATA_PIO4,
.udma_mask = ATA_UDMA6,
@@ -41,6 +41,8 @@ static int ahci_probe(struct platform_device *pdev)
{
struct device *dev = >dev;
struct ahci_host_priv *hpriv;
+ struct acpi_device_info *info;
+ acpi_status status;
int rc;
hpriv = ahci_platform_get_resources(pdev);
@@ -57,6 +59,15 @@ static int ahci_probe(struct platform_device *pdev)
if (of_device_is_compatible(dev->of_node, "hisilicon,hisi-ahci"))
hpriv->flags |= AHCI_HFLAG_NO_FBS | AHCI_HFLAG_NO_NCQ;
+ status = acpi_get_object_info(ACPI_HANDLE(dev), );
+ if (ACPI_SUCCESS(status)) {
+ if (info->valid & ACPI_VALID_HID) {
+ if (!strcmp("APMC0D33", info->hardware_id.string))
+ ahci_port_info.flags |= ATA_FLAG_NO_LPM;
+ }
+ ACPI_FREE(info);
+ }
+
rc = ahci_platform_init_host(pdev, hpriv, _port_info,
_platform_sht);
if (rc)
--
1.8.3.1
[PATCH] ata: Disable AHCI ALPM feature for Ampere Computing eMAG SATA
Due to hardware errata, Ampere Computing eMAG SATA can't support
AHCI ALPM feature. This patch disables the AHCI ALPM feature for
eMAG SATA.
Signed-off-by: Suman Tripathi
Signed-off-by: Rameshwar Prasad Sahu
---
drivers/ata/ahci_platform.c | 13 -
1 file changed, 12 insertions(+), 1 deletion(-)
diff --git a/drivers/ata/ahci_platform.c b/drivers/ata/ahci_platform.c
index 99f9a89..0d0233e 100644
--- a/drivers/ata/ahci_platform.c
+++ b/drivers/ata/ahci_platform.c
@@ -26,7 +26,7 @@
#define DRV_NAME "ahci"
-static const struct ata_port_info ahci_port_info = {
+static struct ata_port_info ahci_port_info = {
.flags = AHCI_FLAG_COMMON,
.pio_mask = ATA_PIO4,
.udma_mask = ATA_UDMA6,
@@ -41,6 +41,8 @@ static int ahci_probe(struct platform_device *pdev)
{
struct device *dev = >dev;
struct ahci_host_priv *hpriv;
+ struct acpi_device_info *info;
+ acpi_status status;
int rc;
hpriv = ahci_platform_get_resources(pdev);
@@ -57,6 +59,15 @@ static int ahci_probe(struct platform_device *pdev)
if (of_device_is_compatible(dev->of_node, "hisilicon,hisi-ahci"))
hpriv->flags |= AHCI_HFLAG_NO_FBS | AHCI_HFLAG_NO_NCQ;
+ status = acpi_get_object_info(ACPI_HANDLE(dev), );
+ if (ACPI_SUCCESS(status)) {
+ if (info->valid & ACPI_VALID_HID) {
+ if (!strcmp("APMC0D33", info->hardware_id.string))
+ ahci_port_info.flags |= ATA_FLAG_NO_LPM;
+ }
+ ACPI_FREE(info);
+ }
+
rc = ahci_platform_init_host(pdev, hpriv, _port_info,
_platform_sht);
if (rc)
--
1.8.3.1
Re: [PATCH] dmaengine: xgene-dma: Fix double IRQ issue by setting IRQ_DISABLE_UNLAZY flag
On Wed, Jan 6, 2016 at 3:40 PM, Suman Tripathi wrote:
>
>
> On Wed, Jan 6, 2016 at 3:35 PM, Thomas Gleixner wrote:
>>
>> On Wed, 6 Jan 2016, Vinod Koul wrote:
>> > On Wed, Jan 06, 2016 at 02:51:07PM +0530, Rameshwar Sahu wrote:
>> > > >> @@ -1610,6 +1611,7 @@ static int xgene_dma_request_irqs(struct
>> > > >> xgene_dma *pdma)
>> > > >> /* Register DMA channel rx irq */
>> > > >> for (i = 0; i < XGENE_DMA_MAX_CHANNEL; i++) {
>> > > >> chan = >chan[i];
>> > > >> + irq_set_status_flags(chan->rx_irq,
>> > > >> IRQ_DISABLE_UNLAZY);
>> > > >
>> > > > Why not use irq_settings_disable_unlazy(), at least read the
>> > > > reference you
>> > > > pointed out!
>> > >
>> > > irq_settings_disable_unlazy() is helper function to test
>> > > IRQ_DISABLE_UNLAZY flag is set or not, it's not for setting this flag.
>> > > FYI...
>> > > +static inline bool irq_settings_disable_unlazy(struct irq_desc *desc)
>> > > +{
>> > > + return desc->status_use_accessors & _IRQ_DISABLE_UNLAZY;
>> > > +}
>> >
>> > Ah yes, I saw clear API and assumed there would be set. Then I think we
>> > should add a set helper as well as the usage is intended for drivers to
>> > set this flag
>> >
>> > Thomas,
>> >
>> > Any reason why you didn't add a set helper, only test and clear?
>>
>> Why would I? Those helpers are core internal and not usable in random
>> drivers.
>
>
> i think the problem is the name of the function. It should be something
>
> irq_check_settings_disable_unlazy
resending in plain text mode. Sorry for this.
I think the problem is the name of the function. It should be something
irq_check_settings_disable_unlazy
>>
>>
>> Drivers have irq_set_status_flags()/irq_clear_status_flags() ...
>>
>> Thanks,
>>
>> tglx
>>
>> ___
>> linux-arm-kernel mailing list
>> linux-arm-ker...@lists.infradead.org
>> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
>
>
>
>
> --
> Thanks,
> with regards,
> Suman Tripathi
--
Thanks,
with regards,
Suman Tripathi
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] dmaengine: xgene-dma: Fix double IRQ issue by setting IRQ_DISABLE_UNLAZY flag
On Wed, Jan 6, 2016 at 3:40 PM, Suman Tripathi <stripa...@apm.com> wrote:
>
>
> On Wed, Jan 6, 2016 at 3:35 PM, Thomas Gleixner <t...@linutronix.de> wrote:
>>
>> On Wed, 6 Jan 2016, Vinod Koul wrote:
>> > On Wed, Jan 06, 2016 at 02:51:07PM +0530, Rameshwar Sahu wrote:
>> > > >> @@ -1610,6 +1611,7 @@ static int xgene_dma_request_irqs(struct
>> > > >> xgene_dma *pdma)
>> > > >> /* Register DMA channel rx irq */
>> > > >> for (i = 0; i < XGENE_DMA_MAX_CHANNEL; i++) {
>> > > >> chan = >chan[i];
>> > > >> + irq_set_status_flags(chan->rx_irq,
>> > > >> IRQ_DISABLE_UNLAZY);
>> > > >
>> > > > Why not use irq_settings_disable_unlazy(), at least read the
>> > > > reference you
>> > > > pointed out!
>> > >
>> > > irq_settings_disable_unlazy() is helper function to test
>> > > IRQ_DISABLE_UNLAZY flag is set or not, it's not for setting this flag.
>> > > FYI...
>> > > +static inline bool irq_settings_disable_unlazy(struct irq_desc *desc)
>> > > +{
>> > > + return desc->status_use_accessors & _IRQ_DISABLE_UNLAZY;
>> > > +}
>> >
>> > Ah yes, I saw clear API and assumed there would be set. Then I think we
>> > should add a set helper as well as the usage is intended for drivers to
>> > set this flag
>> >
>> > Thomas,
>> >
>> > Any reason why you didn't add a set helper, only test and clear?
>>
>> Why would I? Those helpers are core internal and not usable in random
>> drivers.
>
>
> i think the problem is the name of the function. It should be something
>
> irq_check_settings_disable_unlazy
resending in plain text mode. Sorry for this.
I think the problem is the name of the function. It should be something
irq_check_settings_disable_unlazy
>>
>>
>> Drivers have irq_set_status_flags()/irq_clear_status_flags() ...
>>
>> Thanks,
>>
>> tglx
>>
>> ___
>> linux-arm-kernel mailing list
>> linux-arm-ker...@lists.infradead.org
>> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
>
>
>
>
> --
> Thanks,
> with regards,
> Suman Tripathi
--
Thanks,
with regards,
Suman Tripathi
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: 4.2-rc3: APM xgene2: ethernet doesn't work
Hi Ming, On Thu, Jul 23, 2015 at 2:37 PM, Ming Lei wrote: > Hi Guys, > > When booting from UEFI/ACPI, sometimes there is a crash[1] > from rx path, sometimes there isn't any rx packets comming. > > Firmware version: 2.02.10 > > Thanks, > > [1], crash log > Call trace: > skbuff: skb_over_panic: text:ffc00048094c len:85 put:60 > head: data: (null) tail:0x3c end:0x0 > dev: > Kernel panic - not syncing: BUG! > CPU: 0 PID: 0 Comm: swapper/0 Tainted: GW 4.2.0-rc3+ #76 > Hardware name: AppliedMicro Mustang/Mustang, BIOS 2.0.0 Jun 9 2015 > Call trace: > [] dump_backtrace+0x0/0x12c > [] show_stack+0x10/0x1c > [] dump_stack+0x8c/0xdc > [] panic+0xe4/0x220 > [] skb_panic+0x74/0x78 > [] skb_put+0x88/0x8c > [] xgene_enet_process_ring+0xcc/0x394 > [] xgene_enet_napi+0x1c/0x54 > [] net_rx_action+0x124/0x2c0 > [] __do_softirq+0x110/0x238 > [] irq_exit+0x88/0xf0 > [] __handle_domain_irq+0x68/0xb4 > [] gic_handle_irq+0x30/0x7c > Exception stack(0xffc000877dc0 to 0xffc000877ee0) > 7dc0: 00874000 ffc0 0087a648 ffc0 00877f00 ffc0 000869e0 ffc0 > 7de0: 00877f10 ffc0 fffbcb38 ffc7 fffbcb44 ffc7 > 7e00: 0100 da24b9c8 ffc7 fffbe0d9 ffc7 fffbe0d8 ffc7 > 7e20: 008813a0 ffc0 9429 0750 008c93a9 ffc0 > 7e40: 007a1b38 ffc0 007a1b20 ffc0 df5d7500 ffbe > 7e60: 98ab6000 007f 98a9d440 007f 00874000 ffc0 > 7e80: 0087a648 ffc0 00867b00 ffc0 0001 00877f20 ffc0 > 7ea0: 00614500 ffc0 00785000 ffc0 008c9000 ffc0 0087a6cc ffc0 > 7ec0: ffa01348 0047 00877f00 ffc0 000869dc ffc0 00877f00 ffc0 > [] el1_irq+0x64/0xd8 > [] default_idle_call+0x18/0x2c > [] cpu_startup_entry+0xfc/0x180 > [] rest_init+0x80/0x8c > [] start_kernel+0x3c0/0x3d8 > Rebooting in 1 seconds..[DRAM: PHY calibrating ...ignored] > ECC init *ignored] It will be fixed in next release as it is a fix in firmware. -- Thanks, with regards, Suman Tripathi -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 4.2-rc3: APM xgene2: ethernet doesn't work
Hi Ming, On Thu, Jul 23, 2015 at 2:37 PM, Ming Lei ming@canonical.com wrote: Hi Guys, When booting from UEFI/ACPI, sometimes there is a crash[1] from rx path, sometimes there isn't any rx packets comming. Firmware version: 2.02.10 Thanks, [1], crash log Call trace: skbuff: skb_over_panic: text:ffc00048094c len:85 put:60 head: data: (null) tail:0x3c end:0x0 dev:NULL Kernel panic - not syncing: BUG! CPU: 0 PID: 0 Comm: swapper/0 Tainted: GW 4.2.0-rc3+ #76 Hardware name: AppliedMicro Mustang/Mustang, BIOS 2.0.0 Jun 9 2015 Call trace: [ffc89b94] dump_backtrace+0x0/0x12c [ffc89cd0] show_stack+0x10/0x1c [ffc0005fbe48] dump_stack+0x8c/0xdc [ffc0005f8448] panic+0xe4/0x220 [ffc0005fcfa4] skb_panic+0x74/0x78 [ffc000526e88] skb_put+0x88/0x8c [ffc000480948] xgene_enet_process_ring+0xcc/0x394 [ffc000480edc] xgene_enet_napi+0x1c/0x54 [ffc000537fbc] net_rx_action+0x124/0x2c0 [ffcb0070] __do_softirq+0x110/0x238 [ffcb0400] irq_exit+0x88/0xf0 [ffce98b8] __handle_domain_irq+0x68/0xb4 [ffc824a0] gic_handle_irq+0x30/0x7c Exception stack(0xffc000877dc0 to 0xffc000877ee0) 7dc0: 00874000 ffc0 0087a648 ffc0 00877f00 ffc0 000869e0 ffc0 7de0: 00877f10 ffc0 fffbcb38 ffc7 fffbcb44 ffc7 7e00: 0100 da24b9c8 ffc7 fffbe0d9 ffc7 fffbe0d8 ffc7 7e20: 008813a0 ffc0 9429 0750 008c93a9 ffc0 7e40: 007a1b38 ffc0 007a1b20 ffc0 df5d7500 ffbe 7e60: 98ab6000 007f 98a9d440 007f 00874000 ffc0 7e80: 0087a648 ffc0 00867b00 ffc0 0001 00877f20 ffc0 7ea0: 00614500 ffc0 00785000 ffc0 008c9000 ffc0 0087a6cc ffc0 7ec0: ffa01348 0047 00877f00 ffc0 000869dc ffc0 00877f00 ffc0 [ffc855a4] el1_irq+0x64/0xd8 [ffce03fc] default_idle_call+0x18/0x2c [ffce050c] cpu_startup_entry+0xfc/0x180 [ffc0005f5f64] rest_init+0x80/0x8c [ffc0008269b8] start_kernel+0x3c0/0x3d8 Rebooting in 1 seconds..[DRAM: PHY calibrating ...ignored] ECC init *ignored] It will be fixed in next release as it is a fix in firmware. -- Thanks, with regards, Suman Tripathi -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: ACPI: regression: Failed to initialize GIC IRQ controller
On Fri, Jul 10, 2015 at 1:53 PM, Marc Zyngier wrote: > On 10/07/15 09:17, Suman Tripathi wrote: >> On Fri, Jul 10, 2015 at 1:28 PM, Marc Zyngier wrote: >>> >>> On 10/07/15 08:45, Ming Lei wrote: >>>> Hi, >>>> >>>> Commit 0cff8dc0099f6d4f(ACPICA: ACPI 6.0: Add changes for MADT table.) >>>> causes the following failure on APM mustang board(arm64) when >>>> booting via UEFI and ACPI: >>>> >>>> No valid GICC entries exist >>>> ACPI: Failed to initialize GIC IRQ controller >>>> Kernel panic - not syncing: No interrupt controller found. >>>> CPU: 0 PID: 0 Comm: swapper/0 Not tainted 4.2.0-rc1+ #45 >>>> Hardware name: APM X-Gene Mustang board (DT) >>>> Call trace: >>>> [] dump_backtrace+0x0/0x12c >>>> [] show_stack+0x10/0x1c >>>> [] dump_stack+0x8c/0xdc >>>> [] panic+0xe4/0x220 >>>> [] init_IRQ+0x24/0x30 >>>> [] start_kernel+0x274/0x3d8 >>>> ---[ end Kernel panic - not syncing: No interrupt controller found. >>> >>> Isn't that addressed by [1] which Catalin has queued for -rc2? >> >> >> I am also seeing the same . But it fixes after I apply the parking >> protocol patch but that is not upstreamed. > > I'm more interested to find out if the patch I mentioned in my original > email fixes it or not. An additional dependency on something that is not > aimed for mainline yet doesn't really help. Yes the patch mentioned by you fixes the issue. [1] https://lkml.org/lkml/2015/7/6/876 > > Thanks, > > M. > -- > Jazz is not dead. It just smells funny... -- Thanks, with regards, Suman Tripathi -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: ACPI: regression: Failed to initialize GIC IRQ controller
On Fri, Jul 10, 2015 at 1:28 PM, Marc Zyngier wrote: > > On 10/07/15 08:45, Ming Lei wrote: > > Hi, > > > > Commit 0cff8dc0099f6d4f(ACPICA: ACPI 6.0: Add changes for MADT table.) > > causes the following failure on APM mustang board(arm64) when > > booting via UEFI and ACPI: > > > > No valid GICC entries exist > > ACPI: Failed to initialize GIC IRQ controller > > Kernel panic - not syncing: No interrupt controller found. > > CPU: 0 PID: 0 Comm: swapper/0 Not tainted 4.2.0-rc1+ #45 > > Hardware name: APM X-Gene Mustang board (DT) > > Call trace: > > [] dump_backtrace+0x0/0x12c > > [] show_stack+0x10/0x1c > > [] dump_stack+0x8c/0xdc > > [] panic+0xe4/0x220 > > [] init_IRQ+0x24/0x30 > > [] start_kernel+0x274/0x3d8 > > ---[ end Kernel panic - not syncing: No interrupt controller found. > > Isn't that addressed by [1] which Catalin has queued for -rc2? I am also seeing the same . But it fixes after I apply the parking protocol patch but that is not upstreamed. > > > Thanks, > > M. > > [1] https://lkml.org/lkml/2015/7/6/876 > > -- > Jazz is not dead. It just smells funny... > > ___ > linux-arm-kernel mailing list > linux-arm-ker...@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/linux-arm-kernel -- Thanks, with regards, Suman Tripathi -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: ACPI: regression: Failed to initialize GIC IRQ controller
On Fri, Jul 10, 2015 at 1:28 PM, Marc Zyngier marc.zyng...@arm.com wrote: On 10/07/15 08:45, Ming Lei wrote: Hi, Commit 0cff8dc0099f6d4f(ACPICA: ACPI 6.0: Add changes for MADT table.) causes the following failure on APM mustang board(arm64) when booting via UEFI and ACPI: No valid GICC entries exist ACPI: Failed to initialize GIC IRQ controller Kernel panic - not syncing: No interrupt controller found. CPU: 0 PID: 0 Comm: swapper/0 Not tainted 4.2.0-rc1+ #45 Hardware name: APM X-Gene Mustang board (DT) Call trace: [ffc89b94] dump_backtrace+0x0/0x12c [ffc89cd0] show_stack+0x10/0x1c [ffc0005fac18] dump_stack+0x8c/0xdc [ffc0005f7218] panic+0xe4/0x220 [ffc00082631c] init_IRQ+0x24/0x30 [ffc00082486c] start_kernel+0x274/0x3d8 ---[ end Kernel panic - not syncing: No interrupt controller found. Isn't that addressed by [1] which Catalin has queued for -rc2? I am also seeing the same . But it fixes after I apply the parking protocol patch but that is not upstreamed. Thanks, M. [1] https://lkml.org/lkml/2015/7/6/876 -- Jazz is not dead. It just smells funny... ___ linux-arm-kernel mailing list linux-arm-ker...@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel -- Thanks, with regards, Suman Tripathi -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: ACPI: regression: Failed to initialize GIC IRQ controller
On Fri, Jul 10, 2015 at 1:53 PM, Marc Zyngier marc.zyng...@arm.com wrote: On 10/07/15 09:17, Suman Tripathi wrote: On Fri, Jul 10, 2015 at 1:28 PM, Marc Zyngier marc.zyng...@arm.com wrote: On 10/07/15 08:45, Ming Lei wrote: Hi, Commit 0cff8dc0099f6d4f(ACPICA: ACPI 6.0: Add changes for MADT table.) causes the following failure on APM mustang board(arm64) when booting via UEFI and ACPI: No valid GICC entries exist ACPI: Failed to initialize GIC IRQ controller Kernel panic - not syncing: No interrupt controller found. CPU: 0 PID: 0 Comm: swapper/0 Not tainted 4.2.0-rc1+ #45 Hardware name: APM X-Gene Mustang board (DT) Call trace: [ffc89b94] dump_backtrace+0x0/0x12c [ffc89cd0] show_stack+0x10/0x1c [ffc0005fac18] dump_stack+0x8c/0xdc [ffc0005f7218] panic+0xe4/0x220 [ffc00082631c] init_IRQ+0x24/0x30 [ffc00082486c] start_kernel+0x274/0x3d8 ---[ end Kernel panic - not syncing: No interrupt controller found. Isn't that addressed by [1] which Catalin has queued for -rc2? I am also seeing the same . But it fixes after I apply the parking protocol patch but that is not upstreamed. I'm more interested to find out if the patch I mentioned in my original email fixes it or not. An additional dependency on something that is not aimed for mainline yet doesn't really help. Yes the patch mentioned by you fixes the issue. [1] https://lkml.org/lkml/2015/7/6/876 Thanks, M. -- Jazz is not dead. It just smells funny... -- Thanks, with regards, Suman Tripathi -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Error: DMA: Out of SW-IOMMU space [was: External USB drives become unresponsive after few hours.]
[11315.681874] ehci-pci :00:1d.0: swiotlb buffer is full (sz: 32768 >> bytes) >> [11315.681876] DMA: Out of SW-IOMMU space for 32768 bytes at device >> :00:1d.0 >> [11315.682171] ehci-pci :00:1d.0: swiotlb buffer is full (sz: 32768 >> bytes) >> [11315.682174] DMA: Out of SW-IOMMU space for 32768 bytes at device >> :00:1d.0 >> [...and so on...] > > This appears to be a problem with the IOMMU or SWIOTLB subsystems, not > the USB subsystem. I have CC'ed the appropriate mailing lists. > > Alan Stern > > ___ > iommu mailing list > io...@lists.linux-foundation.org > https://lists.linuxfoundation.org/mailman/listinfo/iommu -- Thanks, with regards, Suman Tripathi -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Error: DMA: Out of SW-IOMMU space [was: External USB drives become unresponsive after few hours.]
___ iommu mailing list io...@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu -- Thanks, with regards, Suman Tripathi -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: sequential I/O on SSD disk varies from 20 to 300 MBytes/s every week
Hi, I have an extremely odd situation when the I/O speed changes for both SATA and SSD disks every few days or weeks with no apparent reason. The servers have clean base install with nothing but SSH running and the test I am doing is the following: # dd if=/dev/zero of=/dev/sda4 bs=1M count=10240 conv=fsync And the results are: 1) 3.5Mbytes/s - 120Mbytes/s for SATA disks 2) 20Mbytes/s - 300Mbytes/s for SSD disks The previous reply failed to deliver as plaintext mode was not. Please check whether write cache is enabled in the drive . This can be checked from the logs during bootup and also check whether NCQ is enabled or not. you can enable write cache by : hdparm -W 1 /dev/ On Mon, Feb 2, 2015 at 6:37 PM, Siim Vahtre wrote: > Hello, > > I have an extremely odd situation when the I/O speed changes for both SATA > and SSD disks every few days or weeks with no apparent reason. > > The servers have clean base install with nothing but SSH running and the > test I am doing is the following: > > # dd if=/dev/zero of=/dev/sda4 bs=1M count=10240 conv=fsync > > And the results are: > 1) 3.5Mbytes/s - 120Mbytes/s for SATA disks > 2) 20Mbytes/s - 300Mbytes/s for SSD disks > > > Note that: > > 1) for every disk, the speed (either slow or fast) is usually consistent > 2-14 days, and then it randomly changes. > > 2) One disk speed does not correlate with the speeds of other disks in the > same server - one can be 100Mbyte/s while other is 10Mbytes/s) and month > later it might be vice-versa. > > 3) I have not yet discovered anything that triggers the change of speed. > Seemingly it is just random: on week 1 the speed is ~70-80Mbytes/s, and then > on week two it goes to 20Mbytes/s, and then few days later goes to > 90Mbyte/s. But the speed (slow or fast) is consistent for a longer period of > time - it does not usually change in matter of hours. > > 4) Speed is slow for reads as well, but the difference is a bit less > dramatic. (eg. 400Mbytes/s vs 500Mbytes/s). > > 5) The random I/O speed also changes, but as it is easier to test. > > > During the testing period of about 5 months I have concluded: > > 1) There are 3 identical Fujitsu RX200 S6 test servers which all show the > same problem, but I also reproduced it on some Sun Fire and Dell server. > > 2) The problem happens with both HW RAID (MegaRAID SAS 2108) and when disks > were directly on integrated SATA card. > > 3) The problem happens with different Kernel versions (tried 3.14, 3.16, > 3.18) > > 4) The problem happens with newest FW/BIOS versions and on older version > > 5) I have checked/replaced the cabling. > > 6) It is not a caching issue (controller/disk caches were off during > testing, but even putting them on had minor impact on the results) > > 7) The problem happens with both 2.5" SATA (12 x HGST Travelstar 1TB, 3 x WD > Black 750G), and SSD disks (3 x Samsung Pro 840) > > 8) I have NOT been able to reproduce it on Windows - the speeds have been > good for all disks at all times. > > 9) Changing the disks (eg. taking currently slow disk and putting it to > another server) has mixed results - it usually triggers some change of speed > (slow becomes fast or vice-versa) but not always. > > > The only thing that somewhat correlates with the change of speed is the > environment: the IO speed of disks is generally better when testing in the > office vs if that exact same server is in the server room. It might just > been luck, however. > > I did not find correlation with the uptime, restarts, change of temperature, > etc, so I assumed it might be the vibrations/rotations for SATA disks, but > now that I have reproduced it with expensive SSD disks as well, I am out of > ideas. > > Only 20Mbytes/s on SSD must be wrong, right? (Especially if week earlier or > week later it is ~300MBytes/s). > > Any comments would be highly appreciated. > > -- > Siim Vahtre > -- > To unsubscribe from this list: send the line "unsubscribe linux-scsi" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html -- Thanks, with regards, Suman Tripathi -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: sequential I/O on SSD disk varies from 20 to 300 MBytes/s every week
Hi, I have an extremely odd situation when the I/O speed changes for both SATA and SSD disks every few days or weeks with no apparent reason. The servers have clean base install with nothing but SSH running and the test I am doing is the following: # dd if=/dev/zero of=/dev/sda4 bs=1M count=10240 conv=fsync And the results are: 1) 3.5Mbytes/s - 120Mbytes/s for SATA disks 2) 20Mbytes/s - 300Mbytes/s for SSD disks The previous reply failed to deliver as plaintext mode was not. Please check whether write cache is enabled in the drive . This can be checked from the logs during bootup and also check whether NCQ is enabled or not. you can enable write cache by : hdparm -W 1 /dev/sdX On Mon, Feb 2, 2015 at 6:37 PM, Siim Vahtre s...@xf.ee wrote: Hello, I have an extremely odd situation when the I/O speed changes for both SATA and SSD disks every few days or weeks with no apparent reason. The servers have clean base install with nothing but SSH running and the test I am doing is the following: # dd if=/dev/zero of=/dev/sda4 bs=1M count=10240 conv=fsync And the results are: 1) 3.5Mbytes/s - 120Mbytes/s for SATA disks 2) 20Mbytes/s - 300Mbytes/s for SSD disks Note that: 1) for every disk, the speed (either slow or fast) is usually consistent 2-14 days, and then it randomly changes. 2) One disk speed does not correlate with the speeds of other disks in the same server - one can be 100Mbyte/s while other is 10Mbytes/s) and month later it might be vice-versa. 3) I have not yet discovered anything that triggers the change of speed. Seemingly it is just random: on week 1 the speed is ~70-80Mbytes/s, and then on week two it goes to 20Mbytes/s, and then few days later goes to 90Mbyte/s. But the speed (slow or fast) is consistent for a longer period of time - it does not usually change in matter of hours. 4) Speed is slow for reads as well, but the difference is a bit less dramatic. (eg. 400Mbytes/s vs 500Mbytes/s). 5) The random I/O speed also changes, but as it is easier to test. During the testing period of about 5 months I have concluded: 1) There are 3 identical Fujitsu RX200 S6 test servers which all show the same problem, but I also reproduced it on some Sun Fire and Dell server. 2) The problem happens with both HW RAID (MegaRAID SAS 2108) and when disks were directly on integrated SATA card. 3) The problem happens with different Kernel versions (tried 3.14, 3.16, 3.18) 4) The problem happens with newest FW/BIOS versions and on older version 5) I have checked/replaced the cabling. 6) It is not a caching issue (controller/disk caches were off during testing, but even putting them on had minor impact on the results) 7) The problem happens with both 2.5 SATA (12 x HGST Travelstar 1TB, 3 x WD Black 750G), and SSD disks (3 x Samsung Pro 840) 8) I have NOT been able to reproduce it on Windows - the speeds have been good for all disks at all times. 9) Changing the disks (eg. taking currently slow disk and putting it to another server) has mixed results - it usually triggers some change of speed (slow becomes fast or vice-versa) but not always. The only thing that somewhat correlates with the change of speed is the environment: the IO speed of disks is generally better when testing in the office vs if that exact same server is in the server room. It might just been luck, however. I did not find correlation with the uptime, restarts, change of temperature, etc, so I assumed it might be the vibrations/rotations for SATA disks, but now that I have reproduced it with expensive SSD disks as well, I am out of ideas. Only 20Mbytes/s on SSD must be wrong, right? (Especially if week earlier or week later it is ~300MBytes/s). Any comments would be highly appreciated. -- Siim Vahtre -- To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- Thanks, with regards, Suman Tripathi -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: SATA link power management issues
Can you dump the ata_id parameters(LPM section) from the drive and we
can check the related LPM parameters of the drive ?
On Mon, Jan 12, 2015 at 10:42 PM, Suman Tripathi wrote:
> Hi,
>
> I'm having some problems with the link_power_management_policy on my
> Dell XPS13 9333.
> Changing policy from min_power or medium_power to max_performance
> causes the following errors:
>
> [ 3955.667086] ahci :00:1f.2: port does not support device sleep
> [ 3958.257106] ata3.00: exception Emask 0x10 SAct 0x40 SErr 0x5 action
> 0xe frozen
> [ 3958.257110] ata3.00: irq_stat 0x0040, PHY RDY changed
> [ 3958.257113] ata3: SError: { PHYRdyChg CommWake }
> [ 3958.257116] ata3.00: failed command: READ FPDMA QUEUED
> [ 3958.257120] ata3.00: cmd 60/00:30:c8:60:10/01:00:1d:00:00/40 tag 6 ncq
> 131072 in
> res 40/00:34:c8:60:10/00:00:1d:00:00/40 Emask 0x10 (ATA bus error)
> [ 3958.257122] ata3.00: status: { DRDY }
> [ 3958.257126] ata3: hard resetting link
> [ 3958.981727] ata3: SATA link up 6.0 Gbps (SStatus 133 SControl 300)
> [ 3958.984994] ata3.00: configured for UDMA/133
> [ 3958.997686] ahci :00:1f.2: port does not support device sleep
> [ 3958.997698] ata3: EH complete
>
> Sometimes I get "failed command: WRITE FPDMA QUEUED" multiple times.
>
> As far as I know, this had always happened and it was confirmed
> by another user. I've also come across some logs of the same system
> and saw the same errors here and there, so it shouldn't be a problem
> of my laptop in particular.
>
> What I find interesting is that transitions from min_power to
> medium_power and vice versa do not cause these errors. There are only
> problem switching from min_power and medium_power to max_performance.
> Doing the opposite, i.e. from max_performance to min_power or
> medium_power, seems to work fine.
>
> As a consequence of these continuous errors, the speed is reduced
> from 6.0 Gbps to 1.5 Gbps.
>
> I'd prefer not to disable LPM as it saves a considerable amount of
> power when I'm using the battery. For this reason I'm currently using
> medium_power and min_power only to prevent errors.
>
> Is it normal that these errors appears only when I switch to
> max_performance? Was something similar observed on other systems?
> Can you dump the ata_id parameters(LPM section) from the drive and we can
> check the related LPM parameters of the drive ?
>
> Thanks,
> Gabriele
> --
> To unsubscribe from this list: send the line "unsubscribe linux-ide" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
> On Fri, Jan 9, 2015 at 1:07 AM, Gabriele Mazzotta
> wrote:
>>
>> Hi,
>>
>> I'm having some problems with the link_power_management_policy on my
>> Dell XPS13 9333.
>> Changing policy from min_power or medium_power to max_performance
>> causes the following errors:
>>
>> [ 3955.667086] ahci :00:1f.2: port does not support device sleep
>> [ 3958.257106] ata3.00: exception Emask 0x10 SAct 0x40 SErr 0x5 action
>> 0xe frozen
>> [ 3958.257110] ata3.00: irq_stat 0x0040, PHY RDY changed
>> [ 3958.257113] ata3: SError: { PHYRdyChg CommWake }
>> [ 3958.257116] ata3.00: failed command: READ FPDMA QUEUED
>> [ 3958.257120] ata3.00: cmd 60/00:30:c8:60:10/01:00:1d:00:00/40 tag 6 ncq
>> 131072 in
>> res 40/00:34:c8:60:10/00:00:1d:00:00/40 Emask 0x10 (ATA bus
>> error)
>> [ 3958.257122] ata3.00: status: { DRDY }
>> [ 3958.257126] ata3: hard resetting link
>> [ 3958.981727] ata3: SATA link up 6.0 Gbps (SStatus 133 SControl 300)
>> [ 3958.984994] ata3.00: configured for UDMA/133
>> [ 3958.997686] ahci :00:1f.2: port does not support device sleep
>> [ 3958.997698] ata3: EH complete
>>
>> Sometimes I get "failed command: WRITE FPDMA QUEUED" multiple times.
>>
>> As far as I know, this had always happened and it was confirmed
>> by another user. I've also come across some logs of the same system
>> and saw the same errors here and there, so it shouldn't be a problem
>> of my laptop in particular.
>>
>> What I find interesting is that transitions from min_power to
>> medium_power and vice versa do not cause these errors. There are only
>> problem switching from min_power and medium_power to max_performance.
>> Doing the opposite, i.e. from max_performance to min_power or
>> medium_power, seems to work fine.
>>
>> As a consequence of these continuous errors, the speed is reduced
>> from 6.0 Gbps to 1.5 Gbps.
>>
>> I'd prefer not to disable LPM as it saves a considerable amount of
>> power when
Re: SATA link power management issues
Can you dump the ata_id parameters(LPM section) from the drive and we
can check the related LPM parameters of the drive ?
On Mon, Jan 12, 2015 at 10:42 PM, Suman Tripathi stripa...@apm.com wrote:
Hi,
I'm having some problems with the link_power_management_policy on my
Dell XPS13 9333.
Changing policy from min_power or medium_power to max_performance
causes the following errors:
[ 3955.667086] ahci :00:1f.2: port does not support device sleep
[ 3958.257106] ata3.00: exception Emask 0x10 SAct 0x40 SErr 0x5 action
0xe frozen
[ 3958.257110] ata3.00: irq_stat 0x0040, PHY RDY changed
[ 3958.257113] ata3: SError: { PHYRdyChg CommWake }
[ 3958.257116] ata3.00: failed command: READ FPDMA QUEUED
[ 3958.257120] ata3.00: cmd 60/00:30:c8:60:10/01:00:1d:00:00/40 tag 6 ncq
131072 in
res 40/00:34:c8:60:10/00:00:1d:00:00/40 Emask 0x10 (ATA bus error)
[ 3958.257122] ata3.00: status: { DRDY }
[ 3958.257126] ata3: hard resetting link
[ 3958.981727] ata3: SATA link up 6.0 Gbps (SStatus 133 SControl 300)
[ 3958.984994] ata3.00: configured for UDMA/133
[ 3958.997686] ahci :00:1f.2: port does not support device sleep
[ 3958.997698] ata3: EH complete
Sometimes I get failed command: WRITE FPDMA QUEUED multiple times.
As far as I know, this had always happened and it was confirmed
by another user. I've also come across some logs of the same system
and saw the same errors here and there, so it shouldn't be a problem
of my laptop in particular.
What I find interesting is that transitions from min_power to
medium_power and vice versa do not cause these errors. There are only
problem switching from min_power and medium_power to max_performance.
Doing the opposite, i.e. from max_performance to min_power or
medium_power, seems to work fine.
As a consequence of these continuous errors, the speed is reduced
from 6.0 Gbps to 1.5 Gbps.
I'd prefer not to disable LPM as it saves a considerable amount of
power when I'm using the battery. For this reason I'm currently using
medium_power and min_power only to prevent errors.
Is it normal that these errors appears only when I switch to
max_performance? Was something similar observed on other systems?
Can you dump the ata_id parameters(LPM section) from the drive and we can
check the related LPM parameters of the drive ?
Thanks,
Gabriele
--
To unsubscribe from this list: send the line unsubscribe linux-ide in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
On Fri, Jan 9, 2015 at 1:07 AM, Gabriele Mazzotta gabriele@gmail.com
wrote:
Hi,
I'm having some problems with the link_power_management_policy on my
Dell XPS13 9333.
Changing policy from min_power or medium_power to max_performance
causes the following errors:
[ 3955.667086] ahci :00:1f.2: port does not support device sleep
[ 3958.257106] ata3.00: exception Emask 0x10 SAct 0x40 SErr 0x5 action
0xe frozen
[ 3958.257110] ata3.00: irq_stat 0x0040, PHY RDY changed
[ 3958.257113] ata3: SError: { PHYRdyChg CommWake }
[ 3958.257116] ata3.00: failed command: READ FPDMA QUEUED
[ 3958.257120] ata3.00: cmd 60/00:30:c8:60:10/01:00:1d:00:00/40 tag 6 ncq
131072 in
res 40/00:34:c8:60:10/00:00:1d:00:00/40 Emask 0x10 (ATA bus
error)
[ 3958.257122] ata3.00: status: { DRDY }
[ 3958.257126] ata3: hard resetting link
[ 3958.981727] ata3: SATA link up 6.0 Gbps (SStatus 133 SControl 300)
[ 3958.984994] ata3.00: configured for UDMA/133
[ 3958.997686] ahci :00:1f.2: port does not support device sleep
[ 3958.997698] ata3: EH complete
Sometimes I get failed command: WRITE FPDMA QUEUED multiple times.
As far as I know, this had always happened and it was confirmed
by another user. I've also come across some logs of the same system
and saw the same errors here and there, so it shouldn't be a problem
of my laptop in particular.
What I find interesting is that transitions from min_power to
medium_power and vice versa do not cause these errors. There are only
problem switching from min_power and medium_power to max_performance.
Doing the opposite, i.e. from max_performance to min_power or
medium_power, seems to work fine.
As a consequence of these continuous errors, the speed is reduced
from 6.0 Gbps to 1.5 Gbps.
I'd prefer not to disable LPM as it saves a considerable amount of
power when I'm using the battery. For this reason I'm currently using
medium_power and min_power only to prevent errors.
Is it normal that these errors appears only when I switch to
max_performance? Was something similar observed on other systems?
Thanks,
Gabriele
--
To unsubscribe from this list: send the line unsubscribe linux-ide in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
Thanks,
with regards,
Suman Tripathi
--
Thanks,
with regards,
Suman Tripathi
--
To unsubscribe from
[PATCH 1/2] PHY: Add function set_rate to generic PHY framework
This patch adds function set_rate to the generic PHY framework operation
structure. This function can be called to instruct the PHY underlying
layer at specified lane to configure for specified rate.
Signed-off-by: Loc Ho
Signed-off-by: Suman Tripathi
---
drivers/phy/phy-core.c | 27 +++
include/linux/phy/phy.h | 8
2 files changed, 35 insertions(+)
diff --git a/drivers/phy/phy-core.c b/drivers/phy/phy-core.c
index 645c867..51f82e0 100644
--- a/drivers/phy/phy-core.c
+++ b/drivers/phy/phy-core.c
@@ -258,6 +258,33 @@ int phy_power_off(struct phy *phy)
EXPORT_SYMBOL_GPL(phy_power_off);
/**
+ * phy_set_rate - set an specified lane at an specified rate
+ * @phy: phy instance to be set
+ * @lane: zero-based lane index
+ * @rate: operating rate in bps (bits per second)
+ *
+ * Returns 0 if successful, -ENOTSUPP if not supported
+ * -EINVAL if parameter out of range.
+ */
+int phy_set_rate(struct phy *phy, int lane, u64 rate)
+{
+ int ret = 0;
+
+ mutex_lock(>mutex);
+ if (phy->ops->set_rate) {
+ ret = phy->ops->set_rate(phy, lane, rate);
+ if (ret < 0) {
+ dev_err(>dev, "phy set rate failed --> %d\n",
+ ret);
+ }
+ }
+ mutex_unlock(>mutex);
+
+ return ret;
+}
+EXPORT_SYMBOL_GPL(phy_set_rate);
+
+/**
* of_phy_get() - lookup and obtain a reference to a phy by phandle
* @dev: device that requests this phy
* @index: the index of the phy
diff --git a/include/linux/phy/phy.h b/include/linux/phy/phy.h
index e273e5a..2dfcb34 100644
--- a/include/linux/phy/phy.h
+++ b/include/linux/phy/phy.h
@@ -27,6 +27,7 @@ struct phy;
* @exit: operation to be performed while exiting
* @power_on: powering on the phy
* @power_off: powering off the phy
+ * @set_rate: set the rate
* @owner: the module owner containing the ops
*/
struct phy_ops {
@@ -34,6 +35,7 @@ struct phy_ops {
int (*exit)(struct phy *phy);
int (*power_on)(struct phy *phy);
int (*power_off)(struct phy *phy);
+ int (*set_rate)(struct phy *phy, int lane, u64 rate);
struct module *owner;
};
@@ -137,6 +139,7 @@ int phy_init(struct phy *phy);
int phy_exit(struct phy *phy);
int phy_power_on(struct phy *phy);
int phy_power_off(struct phy *phy);
+int phy_set_rate(struct phy *phy, int lane, u64 rate);
static inline int phy_get_bus_width(struct phy *phy)
{
return phy->attrs.bus_width;
@@ -217,6 +220,11 @@ static inline int phy_power_off(struct phy *phy)
return -ENOSYS;
}
+static inline int phy_set_rate(struct phy *phy, int lane, u64 rate)
+{
+ return -ENOSYS;
+}
+
static inline int phy_get_bus_width(struct phy *phy)
{
return -ENOSYS;
--
1.8.2.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/2] PHY: Add function set_rate to generic PHY framework
This patch adds function set_rate to the generic PHY framework operation
structure. This function can be called to instruct the PHY underlying
layer at specified lane to configure for specified rate.
Signed-off-by: Loc Ho
Signed-off-by: Suman Tripathi
---
drivers/phy/phy-core.c | 27 +++
include/linux/phy/phy.h | 8
2 files changed, 35 insertions(+)
diff --git a/drivers/phy/phy-core.c b/drivers/phy/phy-core.c
index 645c867..51f82e0 100644
--- a/drivers/phy/phy-core.c
+++ b/drivers/phy/phy-core.c
@@ -258,6 +258,33 @@ int phy_power_off(struct phy *phy)
EXPORT_SYMBOL_GPL(phy_power_off);
/**
+ * phy_set_rate - set an specified lane at an specified rate
+ * @phy: phy instance to be set
+ * @lane: zero-based lane index
+ * @rate: operating rate in bps (bits per second)
+ *
+ * Returns 0 if successful, -ENOTSUPP if not supported
+ * -EINVAL if parameter out of range.
+ */
+int phy_set_rate(struct phy *phy, int lane, u64 rate)
+{
+ int ret = 0;
+
+ mutex_lock(>mutex);
+ if (phy->ops->set_rate) {
+ ret = phy->ops->set_rate(phy, lane, rate);
+ if (ret < 0) {
+ dev_err(>dev, "phy set rate failed --> %d\n",
+ ret);
+ }
+ }
+ mutex_unlock(>mutex);
+
+ return ret;
+}
+EXPORT_SYMBOL_GPL(phy_set_rate);
+
+/**
* of_phy_get() - lookup and obtain a reference to a phy by phandle
* @dev: device that requests this phy
* @index: the index of the phy
diff --git a/include/linux/phy/phy.h b/include/linux/phy/phy.h
index e273e5a..2dfcb34 100644
--- a/include/linux/phy/phy.h
+++ b/include/linux/phy/phy.h
@@ -27,6 +27,7 @@ struct phy;
* @exit: operation to be performed while exiting
* @power_on: powering on the phy
* @power_off: powering off the phy
+ * @set_rate: set the rate
* @owner: the module owner containing the ops
*/
struct phy_ops {
@@ -34,6 +35,7 @@ struct phy_ops {
int (*exit)(struct phy *phy);
int (*power_on)(struct phy *phy);
int (*power_off)(struct phy *phy);
+ int (*set_rate)(struct phy *phy, int lane, u64 rate);
struct module *owner;
};
@@ -137,6 +139,7 @@ int phy_init(struct phy *phy);
int phy_exit(struct phy *phy);
int phy_power_on(struct phy *phy);
int phy_power_off(struct phy *phy);
+int phy_set_rate(struct phy *phy, int lane, u64 rate);
static inline int phy_get_bus_width(struct phy *phy)
{
return phy->attrs.bus_width;
@@ -217,6 +220,11 @@ static inline int phy_power_off(struct phy *phy)
return -ENOSYS;
}
+static inline int phy_set_rate(struct phy *phy, int lane, u64 rate)
+{
+ return -ENOSYS;
+}
+
static inline int phy_get_bus_width(struct phy *phy)
{
return -ENOSYS;
--
1.8.2.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2/2] PHY: Add Gen1/Gen2 support for the APM SoC X-Gene SATA PHY driver
This patch adds the necessary PHY code to support SATA Gen1/Gen2 for
the APM X-Gene SoC PHY driver.
Signed-off-by: Loc Ho
Signed-off-by: Suman Tripathi
---
drivers/phy/phy-xgene.c | 90 ++---
1 file changed, 77 insertions(+), 13 deletions(-)
diff --git a/drivers/phy/phy-xgene.c b/drivers/phy/phy-xgene.c
index 4aa1ccd..36e1d99 100644
--- a/drivers/phy/phy-xgene.c
+++ b/drivers/phy/phy-xgene.c
@@ -48,7 +48,7 @@
* at 0x1f23a000 (SATA Port 4/5). For such PHY, another resource is required
* to located the SDS/Ref PLL CMU module and its clock for that IP enabled.
*
- * Currently, this driver only supports Gen3 SATA mode with external clock.
+ * This driver supports Gen3/Gen2/Gen1 SATA mode with external clock.
*/
#include
#include
@@ -76,10 +76,6 @@
#define DEFAULT_SATA_TXCN2 { 0x0, 0x0, 0x0 }
#define DEFAULT_SATA_TXCP1 { 0xa, 0xa, 0xa }
-#define SATA_SPD_SEL_GEN3 0x7
-#define SATA_SPD_SEL_GEN2 0x3
-#define SATA_SPD_SEL_GEN1 0x1
-
#define SSC_DISABLE0
#define SSC_ENABLE 1
@@ -331,6 +327,14 @@
(((dst) & ~0x0040) | (((u32) (src) << 6) & 0x0040))
#define RXTX_REG7_RX_WORD_MODE_SET(dst, src) \
(((dst) & ~0x3800) | (((u32) (src) << 11) & 0x3800))
+#define RXTX_REG7_RX_DATA_RATE_RD(src)((0x0600 & (u32) (src)) >>
9)
+#define RXTX_REG7_RESETB_RXD_SET(dst, src) \
+ (((dst) & ~0x0100) | (((u32) (src) << 8) & 0x0100))
+#define RXTX_REG7_RESETB_RXA_SET(dst, src) \
+ (((dst) & ~0x0080) | (((u32) (src) << 7) & 0x0080))
+#define RXTX_REG7_LOOP_BACK_ENA_CTLE_MASK 0x4000
+#define RXTX_REG7_LOOP_BACK_ENA_CTLE_SET(dst, src) \
+ (((dst) & ~0x4000) | (((u32) (src) << 14) & 0x4000))
#define RXTX_REG8 0x010
#define RXTX_REG8_CDR_LOOP_ENA_SET(dst, src) \
(((dst) & ~0x4000) | (((u32) (src) << 14) & 0x4000))
@@ -342,14 +346,6 @@
(((dst) & ~0x00f0) | (((u32) (src) << 4) & 0x00f0))
#define RXTX_REG8_SD_DISABLE_SET(dst, src) \
(((dst) & ~0x0100) | (((u32) (src) << 8) & 0x0100))
-#define RXTX_REG7 0x00e
-#define RXTX_REG7_RESETB_RXD_SET(dst, src) \
- (((dst) & ~0x0100) | (((u32) (src) << 8) & 0x0100))
-#define RXTX_REG7_RESETB_RXA_SET(dst, src) \
- (((dst) & ~0x0080) | (((u32) (src) << 7) & 0x0080))
-#define RXTX_REG7_LOOP_BACK_ENA_CTLE_MASK 0x4000
-#define RXTX_REG7_LOOP_BACK_ENA_CTLE_SET(dst, src) \
- (((dst) & ~0x4000) | (((u32) (src) << 14) & 0x4000))
#define RXTX_REG11 0x016
#define RXTX_REG11_PHASE_ADJUST_LIMIT_SET(dst, src) \
(((dst) & ~0xf800) | (((u32) (src) << 11) & 0xf800))
@@ -1615,8 +1611,76 @@ static int xgene_phy_hw_init(struct phy *phy)
return 0;
}
+static void xgene_phy_sata_force_gen(struct xgene_phy_ctx *ctx,
+int lane, bool is_gen3)
+{
+ u32 val;
+
+ serdes_rd(ctx, lane, RXTX_REG38, );
+ val = RXTX_REG38_CUSTOMER_PINMODE_INV_SET(val, is_gen3 ? 0x0 : 0x400);
+ serdes_wr(ctx, lane, RXTX_REG38, val);
+
+ /* Set boost control value */
+ serdes_rd(ctx, lane, RXTX_REG1, );
+ val = RXTX_REG1_RXACVCM_SET(val, 0x7);
+ val = RXTX_REG1_CTLE_EQ_SET(val,
+ ctx->sata_param.txboostgain[lane * 3 +
+ ctx->sata_param.speed[lane]]);
+ serdes_wr(ctx, lane, RXTX_REG1, val);
+
+ serdes_rd(ctx, lane, RXTX_REG125, );
+ val = RXTX_REG125_PQ_REG_SET(val,
+ctx->sata_param.txeyetuning[lane * 3 +
+ctx->sata_param.speed[lane]]);
+ serdes_wr(ctx, lane, RXTX_REG125, val);
+
+ serdes_rd(ctx, lane, RXTX_REG61, );
+ val = RXTX_REG61_SPD_SEL_CDR_SET(val,
+ ctx->sata_param.txspeed[ctx->sata_param.speed[lane]]);
+ serdes_wr(ctx, lane, RXTX_REG61, val);
+}
+
+static int xgene_phy_set_rate(struct phy *phy, int lane, u64 rate)
+{
+ struct xgene_phy_ctx *ctx = phy_get_drvdata(phy);
+ u32 val;
+
+ if (lane >= MAX_LANE)
+ return -EINVAL;
+
+ if (ctx->mode == MODE_SATA) {
+ /*
+* Check if the previous rate is same
+* as the current link up rate. If so
+* skip the operation.
+*/
+ serdes_rd(ctx, lane, RXTX_REG7, );
+ if (2 - (RXTX_REG7_RX_DATA_RATE_RD(val)) ==
+
[PATCH 0/2] PHY: Add SATA Gen1/Gen2 support to the APM X-Gene SoC 15Gbps PHY driver
This patch adds the necessary code to support SATA Gen1/Gen2 for the APM X-Gene SoC 15Gbps Multi-purpose PHY driver. Suman Tripathi (2): PHY: Add function set_rate to generic PHY framework PHY: Add Gen1/Gen2 support for the APM SoC X-Gene SATA PHY driver drivers/phy/phy-core.c | 29 ++ drivers/phy/phy-xgene.c | 64 + include/linux/phy/phy.h | 8 +++ 3 files changed, 101 insertions(+) -- 1.8.2.1 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2/2] PHY: Add Gen1/Gen2 support for the APM SoC X-Gene SATA PHY driver
This patch adds the necessary PHY code to support SATA Gen1/Gen2 for
the APM X-Gene SoC PHY driver.
Signed-off-by: Loc Ho l...@apm.com
Signed-off-by: Suman Tripathi stripa...@apm.com
---
drivers/phy/phy-xgene.c | 90 ++---
1 file changed, 77 insertions(+), 13 deletions(-)
diff --git a/drivers/phy/phy-xgene.c b/drivers/phy/phy-xgene.c
index 4aa1ccd..36e1d99 100644
--- a/drivers/phy/phy-xgene.c
+++ b/drivers/phy/phy-xgene.c
@@ -48,7 +48,7 @@
* at 0x1f23a000 (SATA Port 4/5). For such PHY, another resource is required
* to located the SDS/Ref PLL CMU module and its clock for that IP enabled.
*
- * Currently, this driver only supports Gen3 SATA mode with external clock.
+ * This driver supports Gen3/Gen2/Gen1 SATA mode with external clock.
*/
#include linux/module.h
#include linux/platform_device.h
@@ -76,10 +76,6 @@
#define DEFAULT_SATA_TXCN2 { 0x0, 0x0, 0x0 }
#define DEFAULT_SATA_TXCP1 { 0xa, 0xa, 0xa }
-#define SATA_SPD_SEL_GEN3 0x7
-#define SATA_SPD_SEL_GEN2 0x3
-#define SATA_SPD_SEL_GEN1 0x1
-
#define SSC_DISABLE0
#define SSC_ENABLE 1
@@ -331,6 +327,14 @@
(((dst) ~0x0040) | (((u32) (src) 6) 0x0040))
#define RXTX_REG7_RX_WORD_MODE_SET(dst, src) \
(((dst) ~0x3800) | (((u32) (src) 11) 0x3800))
+#define RXTX_REG7_RX_DATA_RATE_RD(src)((0x0600 (u32) (src))
9)
+#define RXTX_REG7_RESETB_RXD_SET(dst, src) \
+ (((dst) ~0x0100) | (((u32) (src) 8) 0x0100))
+#define RXTX_REG7_RESETB_RXA_SET(dst, src) \
+ (((dst) ~0x0080) | (((u32) (src) 7) 0x0080))
+#define RXTX_REG7_LOOP_BACK_ENA_CTLE_MASK 0x4000
+#define RXTX_REG7_LOOP_BACK_ENA_CTLE_SET(dst, src) \
+ (((dst) ~0x4000) | (((u32) (src) 14) 0x4000))
#define RXTX_REG8 0x010
#define RXTX_REG8_CDR_LOOP_ENA_SET(dst, src) \
(((dst) ~0x4000) | (((u32) (src) 14) 0x4000))
@@ -342,14 +346,6 @@
(((dst) ~0x00f0) | (((u32) (src) 4) 0x00f0))
#define RXTX_REG8_SD_DISABLE_SET(dst, src) \
(((dst) ~0x0100) | (((u32) (src) 8) 0x0100))
-#define RXTX_REG7 0x00e
-#define RXTX_REG7_RESETB_RXD_SET(dst, src) \
- (((dst) ~0x0100) | (((u32) (src) 8) 0x0100))
-#define RXTX_REG7_RESETB_RXA_SET(dst, src) \
- (((dst) ~0x0080) | (((u32) (src) 7) 0x0080))
-#define RXTX_REG7_LOOP_BACK_ENA_CTLE_MASK 0x4000
-#define RXTX_REG7_LOOP_BACK_ENA_CTLE_SET(dst, src) \
- (((dst) ~0x4000) | (((u32) (src) 14) 0x4000))
#define RXTX_REG11 0x016
#define RXTX_REG11_PHASE_ADJUST_LIMIT_SET(dst, src) \
(((dst) ~0xf800) | (((u32) (src) 11) 0xf800))
@@ -1615,8 +1611,76 @@ static int xgene_phy_hw_init(struct phy *phy)
return 0;
}
+static void xgene_phy_sata_force_gen(struct xgene_phy_ctx *ctx,
+int lane, bool is_gen3)
+{
+ u32 val;
+
+ serdes_rd(ctx, lane, RXTX_REG38, val);
+ val = RXTX_REG38_CUSTOMER_PINMODE_INV_SET(val, is_gen3 ? 0x0 : 0x400);
+ serdes_wr(ctx, lane, RXTX_REG38, val);
+
+ /* Set boost control value */
+ serdes_rd(ctx, lane, RXTX_REG1, val);
+ val = RXTX_REG1_RXACVCM_SET(val, 0x7);
+ val = RXTX_REG1_CTLE_EQ_SET(val,
+ ctx-sata_param.txboostgain[lane * 3 +
+ ctx-sata_param.speed[lane]]);
+ serdes_wr(ctx, lane, RXTX_REG1, val);
+
+ serdes_rd(ctx, lane, RXTX_REG125, val);
+ val = RXTX_REG125_PQ_REG_SET(val,
+ctx-sata_param.txeyetuning[lane * 3 +
+ctx-sata_param.speed[lane]]);
+ serdes_wr(ctx, lane, RXTX_REG125, val);
+
+ serdes_rd(ctx, lane, RXTX_REG61, val);
+ val = RXTX_REG61_SPD_SEL_CDR_SET(val,
+ ctx-sata_param.txspeed[ctx-sata_param.speed[lane]]);
+ serdes_wr(ctx, lane, RXTX_REG61, val);
+}
+
+static int xgene_phy_set_rate(struct phy *phy, int lane, u64 rate)
+{
+ struct xgene_phy_ctx *ctx = phy_get_drvdata(phy);
+ u32 val;
+
+ if (lane = MAX_LANE)
+ return -EINVAL;
+
+ if (ctx-mode == MODE_SATA) {
+ /*
+* Check if the previous rate is same
+* as the current link up rate. If so
+* skip the operation.
+*/
+ serdes_rd(ctx, lane, RXTX_REG7, val);
+ if (2 - (RXTX_REG7_RX_DATA_RATE_RD(val)) ==
+ ctx-sata_param.speed[lane])
+ return 1;
+
+ switch (rate) {
+ case 15ULL:
+ ctx-sata_param.speed[lane] = 0
[PATCH 0/2] PHY: Add SATA Gen1/Gen2 support to the APM X-Gene SoC 15Gbps PHY driver
This patch adds the necessary code to support SATA Gen1/Gen2 for the APM X-Gene SoC 15Gbps Multi-purpose PHY driver. Suman Tripathi (2): PHY: Add function set_rate to generic PHY framework PHY: Add Gen1/Gen2 support for the APM SoC X-Gene SATA PHY driver drivers/phy/phy-core.c | 29 ++ drivers/phy/phy-xgene.c | 64 + include/linux/phy/phy.h | 8 +++ 3 files changed, 101 insertions(+) -- 1.8.2.1 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/2] PHY: Add function set_rate to generic PHY framework
This patch adds function set_rate to the generic PHY framework operation
structure. This function can be called to instruct the PHY underlying
layer at specified lane to configure for specified rate.
Signed-off-by: Loc Ho l...@apm.com
Signed-off-by: Suman Tripathi stripa...@apm.com
---
drivers/phy/phy-core.c | 27 +++
include/linux/phy/phy.h | 8
2 files changed, 35 insertions(+)
diff --git a/drivers/phy/phy-core.c b/drivers/phy/phy-core.c
index 645c867..51f82e0 100644
--- a/drivers/phy/phy-core.c
+++ b/drivers/phy/phy-core.c
@@ -258,6 +258,33 @@ int phy_power_off(struct phy *phy)
EXPORT_SYMBOL_GPL(phy_power_off);
/**
+ * phy_set_rate - set an specified lane at an specified rate
+ * @phy: phy instance to be set
+ * @lane: zero-based lane index
+ * @rate: operating rate in bps (bits per second)
+ *
+ * Returns 0 if successful, -ENOTSUPP if not supported
+ * -EINVAL if parameter out of range.
+ */
+int phy_set_rate(struct phy *phy, int lane, u64 rate)
+{
+ int ret = 0;
+
+ mutex_lock(phy-mutex);
+ if (phy-ops-set_rate) {
+ ret = phy-ops-set_rate(phy, lane, rate);
+ if (ret 0) {
+ dev_err(phy-dev, phy set rate failed -- %d\n,
+ ret);
+ }
+ }
+ mutex_unlock(phy-mutex);
+
+ return ret;
+}
+EXPORT_SYMBOL_GPL(phy_set_rate);
+
+/**
* of_phy_get() - lookup and obtain a reference to a phy by phandle
* @dev: device that requests this phy
* @index: the index of the phy
diff --git a/include/linux/phy/phy.h b/include/linux/phy/phy.h
index e273e5a..2dfcb34 100644
--- a/include/linux/phy/phy.h
+++ b/include/linux/phy/phy.h
@@ -27,6 +27,7 @@ struct phy;
* @exit: operation to be performed while exiting
* @power_on: powering on the phy
* @power_off: powering off the phy
+ * @set_rate: set the rate
* @owner: the module owner containing the ops
*/
struct phy_ops {
@@ -34,6 +35,7 @@ struct phy_ops {
int (*exit)(struct phy *phy);
int (*power_on)(struct phy *phy);
int (*power_off)(struct phy *phy);
+ int (*set_rate)(struct phy *phy, int lane, u64 rate);
struct module *owner;
};
@@ -137,6 +139,7 @@ int phy_init(struct phy *phy);
int phy_exit(struct phy *phy);
int phy_power_on(struct phy *phy);
int phy_power_off(struct phy *phy);
+int phy_set_rate(struct phy *phy, int lane, u64 rate);
static inline int phy_get_bus_width(struct phy *phy)
{
return phy-attrs.bus_width;
@@ -217,6 +220,11 @@ static inline int phy_power_off(struct phy *phy)
return -ENOSYS;
}
+static inline int phy_set_rate(struct phy *phy, int lane, u64 rate)
+{
+ return -ENOSYS;
+}
+
static inline int phy_get_bus_width(struct phy *phy)
{
return -ENOSYS;
--
1.8.2.1
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/2] PHY: Add function set_rate to generic PHY framework
This patch adds function set_rate to the generic PHY framework operation
structure. This function can be called to instruct the PHY underlying
layer at specified lane to configure for specified rate.
Signed-off-by: Loc Ho l...@apm.com
Signed-off-by: Suman Tripathi stripa...@apm.com
---
drivers/phy/phy-core.c | 27 +++
include/linux/phy/phy.h | 8
2 files changed, 35 insertions(+)
diff --git a/drivers/phy/phy-core.c b/drivers/phy/phy-core.c
index 645c867..51f82e0 100644
--- a/drivers/phy/phy-core.c
+++ b/drivers/phy/phy-core.c
@@ -258,6 +258,33 @@ int phy_power_off(struct phy *phy)
EXPORT_SYMBOL_GPL(phy_power_off);
/**
+ * phy_set_rate - set an specified lane at an specified rate
+ * @phy: phy instance to be set
+ * @lane: zero-based lane index
+ * @rate: operating rate in bps (bits per second)
+ *
+ * Returns 0 if successful, -ENOTSUPP if not supported
+ * -EINVAL if parameter out of range.
+ */
+int phy_set_rate(struct phy *phy, int lane, u64 rate)
+{
+ int ret = 0;
+
+ mutex_lock(phy-mutex);
+ if (phy-ops-set_rate) {
+ ret = phy-ops-set_rate(phy, lane, rate);
+ if (ret 0) {
+ dev_err(phy-dev, phy set rate failed -- %d\n,
+ ret);
+ }
+ }
+ mutex_unlock(phy-mutex);
+
+ return ret;
+}
+EXPORT_SYMBOL_GPL(phy_set_rate);
+
+/**
* of_phy_get() - lookup and obtain a reference to a phy by phandle
* @dev: device that requests this phy
* @index: the index of the phy
diff --git a/include/linux/phy/phy.h b/include/linux/phy/phy.h
index e273e5a..2dfcb34 100644
--- a/include/linux/phy/phy.h
+++ b/include/linux/phy/phy.h
@@ -27,6 +27,7 @@ struct phy;
* @exit: operation to be performed while exiting
* @power_on: powering on the phy
* @power_off: powering off the phy
+ * @set_rate: set the rate
* @owner: the module owner containing the ops
*/
struct phy_ops {
@@ -34,6 +35,7 @@ struct phy_ops {
int (*exit)(struct phy *phy);
int (*power_on)(struct phy *phy);
int (*power_off)(struct phy *phy);
+ int (*set_rate)(struct phy *phy, int lane, u64 rate);
struct module *owner;
};
@@ -137,6 +139,7 @@ int phy_init(struct phy *phy);
int phy_exit(struct phy *phy);
int phy_power_on(struct phy *phy);
int phy_power_off(struct phy *phy);
+int phy_set_rate(struct phy *phy, int lane, u64 rate);
static inline int phy_get_bus_width(struct phy *phy)
{
return phy-attrs.bus_width;
@@ -217,6 +220,11 @@ static inline int phy_power_off(struct phy *phy)
return -ENOSYS;
}
+static inline int phy_set_rate(struct phy *phy, int lane, u64 rate)
+{
+ return -ENOSYS;
+}
+
static inline int phy_get_bus_width(struct phy *phy)
{
return -ENOSYS;
--
1.8.2.1
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
