* [PATCH 1/2] AM35xx-Craneboard: USB EHCI: Fix USB ECHI PHY reset
[not found] <[PATCH]>
@ 2011-04-29 11:41 ` srinath at mistralsolutions.com
2011-04-29 11:41 ` srinath at mistralsolutions.com
` (3 subsequent siblings)
4 siblings, 0 replies; 17+ messages in thread
From: srinath @ 2011-04-29 11:41 UTC (permalink / raw)
To: linux-omap
Cc: jdk, tony, linux-kernel, linux, linux-arm-kernel, khilman, nm,
nagendra, umeshk, Srinath
From: Srinath <srinath@mistralsolutions.com>
This patch fixes the EHCI PHY reset issue found on CraneBoard.
Signed-off-by: Srinath <srinath@mistralsolutions.com>
---
arch/arm/mach-omap2/board-am3517crane.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-omap2/board-am3517crane.c b/arch/arm/mach-omap2/board-am3517crane.c
index a890d24..05867b5 100644
--- a/arch/arm/mach-omap2/board-am3517crane.c
+++ b/arch/arm/mach-omap2/board-am3517crane.c
@@ -60,7 +60,7 @@ static struct usbhs_omap_board_data usbhs_bdata __initdata = {
.port_mode[1] = OMAP_USBHS_PORT_MODE_UNUSED,
.port_mode[2] = OMAP_USBHS_PORT_MODE_UNUSED,
- .phy_reset = true,
+ .phy_reset = false,
.reset_gpio_port[0] = GPIO_USB_NRESET,
.reset_gpio_port[1] = -EINVAL,
.reset_gpio_port[2] = -EINVAL
--
1.7.1.226.g770c5
^ permalink raw reply related [flat|nested] 17+ messages in thread* [PATCH 1/2] AM35xx-Craneboard: USB EHCI: Fix USB ECHI PHY reset
@ 2011-04-29 11:41 ` srinath at mistralsolutions.com
0 siblings, 0 replies; 17+ messages in thread
From: srinath at mistralsolutions.com @ 2011-04-29 11:41 UTC (permalink / raw)
To: linux-arm-kernel
From: Srinath <srinath@mistralsolutions.com>
This patch fixes the EHCI PHY reset issue found on CraneBoard.
Signed-off-by: Srinath <srinath@mistralsolutions.com>
---
arch/arm/mach-omap2/board-am3517crane.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-omap2/board-am3517crane.c b/arch/arm/mach-omap2/board-am3517crane.c
index a890d24..05867b5 100644
--- a/arch/arm/mach-omap2/board-am3517crane.c
+++ b/arch/arm/mach-omap2/board-am3517crane.c
@@ -60,7 +60,7 @@ static struct usbhs_omap_board_data usbhs_bdata __initdata = {
.port_mode[1] = OMAP_USBHS_PORT_MODE_UNUSED,
.port_mode[2] = OMAP_USBHS_PORT_MODE_UNUSED,
- .phy_reset = true,
+ .phy_reset = false,
.reset_gpio_port[0] = GPIO_USB_NRESET,
.reset_gpio_port[1] = -EINVAL,
.reset_gpio_port[2] = -EINVAL
--
1.7.1.226.g770c5
^ permalink raw reply related [flat|nested] 17+ messages in thread* Re: [PATCH 1/2] AM35xx-Craneboard: USB EHCI: Fix USB ECHI PHY reset
2011-04-29 11:41 ` srinath at mistralsolutions.com
@ 2011-04-29 12:39 ` Sergei Shtylyov
-1 siblings, 0 replies; 17+ messages in thread
From: Sergei Shtylyov @ 2011-04-29 12:39 UTC (permalink / raw)
To: srinath
Cc: linux-omap, nm, linux, umeshk, tony, nagendra, linux-kernel,
khilman, jdk, linux-arm-kernel
Hello.
On 29-04-2011 15:41, srinath@mistralsolutions.com wrote:
> From: Srinath <srinath@mistralsolutions.com>
> This patch fixes the EHCI PHY reset issue found on CraneBoard.
> Signed-off-by: Srinath <srinath@mistralsolutions.com>
AFAIK full name required in signoff.
WBR, Sergei
^ permalink raw reply [flat|nested] 17+ messages in thread
* [PATCH 2/2] AM35xx-Craneboard:Display: Add DVI and TV Support
[not found] <[PATCH]>
[not found] ` <ata:>
@ 2011-04-29 11:41 ` srinath at mistralsolutions.com
2011-04-29 11:41 ` srinath at mistralsolutions.com
` (2 subsequent siblings)
4 siblings, 0 replies; 17+ messages in thread
From: srinath @ 2011-04-29 11:41 UTC (permalink / raw)
To: linux-omap
Cc: nm, linux, umeshk, tony, nagendra, Srinath, linux-kernel, khilman,
jdk, linux-arm-kernel
From: Srinath <srinath@mistralsolutions.com>
Added Display (DVI and TV) support for CraneBoard.
Signed-off-by: Srinath <srinath@mistralsolutions.com>
---
arch/arm/mach-omap2/board-am3517crane.c | 78 +++++++++++++++++++++++++++++++
1 files changed, 78 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/board-am3517crane.c b/arch/arm/mach-omap2/board-am3517crane.c
index 05867b5..83fe85b 100644
--- a/arch/arm/mach-omap2/board-am3517crane.c
+++ b/arch/arm/mach-omap2/board-am3517crane.c
@@ -29,12 +29,15 @@
#include <plat/board.h>
#include <plat/common.h>
#include <plat/usb.h>
+#include <plat/display.h>
+#include <plat/panel-generic-dpi.h>
#include "mux.h"
#include "control.h"
#define GPIO_USB_POWER 35
#define GPIO_USB_NRESET 38
+#define GPIO_DVI_ENABLE 52
/* Board initialization */
@@ -66,11 +69,83 @@ static struct usbhs_omap_board_data usbhs_bdata __initdata = {
.reset_gpio_port[2] = -EINVAL
};
+static void __init am3517_crane_display_init(void)
+{
+ int ret;
+
+ ret = omap_mux_init_gpio(GPIO_DVI_ENABLE, OMAP_PIN_OUTPUT);
+ if (ret < 0) {
+ pr_err("Can not configure mux for GPIO_DVI_ENABLE %d\n",
+ GPIO_DVI_ENABLE);
+ return;
+ }
+
+ ret = gpio_request(GPIO_DVI_ENABLE, "dvi_enable");
+ if (ret < 0) {
+ pr_err("Can not request GPIO %d\n", GPIO_DVI_ENABLE);
+ return;
+ }
+
+ ret = gpio_direction_output(GPIO_DVI_ENABLE, 1);
+ if (ret < 0) {
+ gpio_free(GPIO_DVI_ENABLE);
+ pr_err("Unable to enable DVI\n");
+ return;
+ }
+}
+
+static struct omap_dss_device am3517_crane_tv_device = {
+ .type = OMAP_DISPLAY_TYPE_VENC,
+ .name = "tv",
+ .driver_name = "venc",
+ .phy.venc.type = OMAP_DSS_VENC_TYPE_COMPOSITE,
+ .platform_enable = NULL,
+ .platform_disable = NULL,
+};
+
+static int am3517_crane_panel_enable_dvi(struct omap_dss_device *dssdev)
+{
+ gpio_set_value(GPIO_DVI_ENABLE, 1);
+ return 0;
+}
+
+static void am3517_crane_panel_disable_dvi(struct omap_dss_device *dssdev)
+{
+ gpio_set_value(GPIO_DVI_ENABLE, 0);
+}
+
+
+static struct panel_generic_dpi_data dvi_panel = {
+ .name = "generic",
+ .platform_enable = am3517_crane_panel_enable_dvi,
+ .platform_disable = am3517_crane_panel_disable_dvi,
+};
+
+static struct omap_dss_device am3517_crane_dvi_device = {
+ .type = OMAP_DISPLAY_TYPE_DPI,
+ .name = "dvi",
+ .driver_name = "generic_dpi_panel",
+ .data = &dvi_panel,
+ .phy.dpi.data_lines = 24,
+};
+
+static struct omap_dss_device *am3517_crane_dss_devices[] = {
+ &am3517_crane_tv_device,
+ &am3517_crane_dvi_device,
+};
+
+static struct omap_dss_board_info am3517_crane_dss_data = {
+ .num_devices = ARRAY_SIZE(am3517_crane_dss_devices),
+ .devices = am3517_crane_dss_devices,
+ .default_device = &am3517_crane_dvi_device,
+};
+
static void __init am3517_crane_init(void)
{
int ret;
omap3_mux_init(board_mux, OMAP_PACKAGE_CBB);
+ omap_display_init(&am3517_crane_dss_data);
omap_serial_init();
omap_board_config = am3517_crane_config;
@@ -103,6 +178,9 @@ static void __init am3517_crane_init(void)
}
usbhs_init(&usbhs_bdata);
+
+ /* DSS */
+ am3517_crane_display_init();
}
MACHINE_START(CRANEBOARD, "AM3517/05 CRANEBOARD")
--
1.7.1.226.g770c5
^ permalink raw reply related [flat|nested] 17+ messages in thread* [PATCH 2/2] AM35xx-Craneboard:Display: Add DVI and TV Support
@ 2011-04-29 11:41 ` srinath at mistralsolutions.com
0 siblings, 0 replies; 17+ messages in thread
From: srinath @ 2011-04-29 11:41 UTC (permalink / raw)
To: linux-omap
Cc: jdk, tony, linux-kernel, linux, linux-arm-kernel, khilman, nm,
nagendra, umeshk, Srinath
From: Srinath <srinath@mistralsolutions.com>
Added Display (DVI and TV) support for CraneBoard.
Signed-off-by: Srinath <srinath@mistralsolutions.com>
---
arch/arm/mach-omap2/board-am3517crane.c | 78 +++++++++++++++++++++++++++++++
1 files changed, 78 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/board-am3517crane.c b/arch/arm/mach-omap2/board-am3517crane.c
index 05867b5..83fe85b 100644
--- a/arch/arm/mach-omap2/board-am3517crane.c
+++ b/arch/arm/mach-omap2/board-am3517crane.c
@@ -29,12 +29,15 @@
#include <plat/board.h>
#include <plat/common.h>
#include <plat/usb.h>
+#include <plat/display.h>
+#include <plat/panel-generic-dpi.h>
#include "mux.h"
#include "control.h"
#define GPIO_USB_POWER 35
#define GPIO_USB_NRESET 38
+#define GPIO_DVI_ENABLE 52
/* Board initialization */
@@ -66,11 +69,83 @@ static struct usbhs_omap_board_data usbhs_bdata __initdata = {
.reset_gpio_port[2] = -EINVAL
};
+static void __init am3517_crane_display_init(void)
+{
+ int ret;
+
+ ret = omap_mux_init_gpio(GPIO_DVI_ENABLE, OMAP_PIN_OUTPUT);
+ if (ret < 0) {
+ pr_err("Can not configure mux for GPIO_DVI_ENABLE %d\n",
+ GPIO_DVI_ENABLE);
+ return;
+ }
+
+ ret = gpio_request(GPIO_DVI_ENABLE, "dvi_enable");
+ if (ret < 0) {
+ pr_err("Can not request GPIO %d\n", GPIO_DVI_ENABLE);
+ return;
+ }
+
+ ret = gpio_direction_output(GPIO_DVI_ENABLE, 1);
+ if (ret < 0) {
+ gpio_free(GPIO_DVI_ENABLE);
+ pr_err("Unable to enable DVI\n");
+ return;
+ }
+}
+
+static struct omap_dss_device am3517_crane_tv_device = {
+ .type = OMAP_DISPLAY_TYPE_VENC,
+ .name = "tv",
+ .driver_name = "venc",
+ .phy.venc.type = OMAP_DSS_VENC_TYPE_COMPOSITE,
+ .platform_enable = NULL,
+ .platform_disable = NULL,
+};
+
+static int am3517_crane_panel_enable_dvi(struct omap_dss_device *dssdev)
+{
+ gpio_set_value(GPIO_DVI_ENABLE, 1);
+ return 0;
+}
+
+static void am3517_crane_panel_disable_dvi(struct omap_dss_device *dssdev)
+{
+ gpio_set_value(GPIO_DVI_ENABLE, 0);
+}
+
+
+static struct panel_generic_dpi_data dvi_panel = {
+ .name = "generic",
+ .platform_enable = am3517_crane_panel_enable_dvi,
+ .platform_disable = am3517_crane_panel_disable_dvi,
+};
+
+static struct omap_dss_device am3517_crane_dvi_device = {
+ .type = OMAP_DISPLAY_TYPE_DPI,
+ .name = "dvi",
+ .driver_name = "generic_dpi_panel",
+ .data = &dvi_panel,
+ .phy.dpi.data_lines = 24,
+};
+
+static struct omap_dss_device *am3517_crane_dss_devices[] = {
+ &am3517_crane_tv_device,
+ &am3517_crane_dvi_device,
+};
+
+static struct omap_dss_board_info am3517_crane_dss_data = {
+ .num_devices = ARRAY_SIZE(am3517_crane_dss_devices),
+ .devices = am3517_crane_dss_devices,
+ .default_device = &am3517_crane_dvi_device,
+};
+
static void __init am3517_crane_init(void)
{
int ret;
omap3_mux_init(board_mux, OMAP_PACKAGE_CBB);
+ omap_display_init(&am3517_crane_dss_data);
omap_serial_init();
omap_board_config = am3517_crane_config;
@@ -103,6 +178,9 @@ static void __init am3517_crane_init(void)
}
usbhs_init(&usbhs_bdata);
+
+ /* DSS */
+ am3517_crane_display_init();
}
MACHINE_START(CRANEBOARD, "AM3517/05 CRANEBOARD")
--
1.7.1.226.g770c5
^ permalink raw reply related [flat|nested] 17+ messages in thread* [PATCH 2/2] AM35xx-Craneboard:Display: Add DVI and TV Support
@ 2011-04-29 11:41 ` srinath at mistralsolutions.com
0 siblings, 0 replies; 17+ messages in thread
From: srinath at mistralsolutions.com @ 2011-04-29 11:41 UTC (permalink / raw)
To: linux-arm-kernel
From: Srinath <srinath@mistralsolutions.com>
Added Display (DVI and TV) support for CraneBoard.
Signed-off-by: Srinath <srinath@mistralsolutions.com>
---
arch/arm/mach-omap2/board-am3517crane.c | 78 +++++++++++++++++++++++++++++++
1 files changed, 78 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/board-am3517crane.c b/arch/arm/mach-omap2/board-am3517crane.c
index 05867b5..83fe85b 100644
--- a/arch/arm/mach-omap2/board-am3517crane.c
+++ b/arch/arm/mach-omap2/board-am3517crane.c
@@ -29,12 +29,15 @@
#include <plat/board.h>
#include <plat/common.h>
#include <plat/usb.h>
+#include <plat/display.h>
+#include <plat/panel-generic-dpi.h>
#include "mux.h"
#include "control.h"
#define GPIO_USB_POWER 35
#define GPIO_USB_NRESET 38
+#define GPIO_DVI_ENABLE 52
/* Board initialization */
@@ -66,11 +69,83 @@ static struct usbhs_omap_board_data usbhs_bdata __initdata = {
.reset_gpio_port[2] = -EINVAL
};
+static void __init am3517_crane_display_init(void)
+{
+ int ret;
+
+ ret = omap_mux_init_gpio(GPIO_DVI_ENABLE, OMAP_PIN_OUTPUT);
+ if (ret < 0) {
+ pr_err("Can not configure mux for GPIO_DVI_ENABLE %d\n",
+ GPIO_DVI_ENABLE);
+ return;
+ }
+
+ ret = gpio_request(GPIO_DVI_ENABLE, "dvi_enable");
+ if (ret < 0) {
+ pr_err("Can not request GPIO %d\n", GPIO_DVI_ENABLE);
+ return;
+ }
+
+ ret = gpio_direction_output(GPIO_DVI_ENABLE, 1);
+ if (ret < 0) {
+ gpio_free(GPIO_DVI_ENABLE);
+ pr_err("Unable to enable DVI\n");
+ return;
+ }
+}
+
+static struct omap_dss_device am3517_crane_tv_device = {
+ .type = OMAP_DISPLAY_TYPE_VENC,
+ .name = "tv",
+ .driver_name = "venc",
+ .phy.venc.type = OMAP_DSS_VENC_TYPE_COMPOSITE,
+ .platform_enable = NULL,
+ .platform_disable = NULL,
+};
+
+static int am3517_crane_panel_enable_dvi(struct omap_dss_device *dssdev)
+{
+ gpio_set_value(GPIO_DVI_ENABLE, 1);
+ return 0;
+}
+
+static void am3517_crane_panel_disable_dvi(struct omap_dss_device *dssdev)
+{
+ gpio_set_value(GPIO_DVI_ENABLE, 0);
+}
+
+
+static struct panel_generic_dpi_data dvi_panel = {
+ .name = "generic",
+ .platform_enable = am3517_crane_panel_enable_dvi,
+ .platform_disable = am3517_crane_panel_disable_dvi,
+};
+
+static struct omap_dss_device am3517_crane_dvi_device = {
+ .type = OMAP_DISPLAY_TYPE_DPI,
+ .name = "dvi",
+ .driver_name = "generic_dpi_panel",
+ .data = &dvi_panel,
+ .phy.dpi.data_lines = 24,
+};
+
+static struct omap_dss_device *am3517_crane_dss_devices[] = {
+ &am3517_crane_tv_device,
+ &am3517_crane_dvi_device,
+};
+
+static struct omap_dss_board_info am3517_crane_dss_data = {
+ .num_devices = ARRAY_SIZE(am3517_crane_dss_devices),
+ .devices = am3517_crane_dss_devices,
+ .default_device = &am3517_crane_dvi_device,
+};
+
static void __init am3517_crane_init(void)
{
int ret;
omap3_mux_init(board_mux, OMAP_PACKAGE_CBB);
+ omap_display_init(&am3517_crane_dss_data);
omap_serial_init();
omap_board_config = am3517_crane_config;
@@ -103,6 +178,9 @@ static void __init am3517_crane_init(void)
}
usbhs_init(&usbhs_bdata);
+
+ /* DSS */
+ am3517_crane_display_init();
}
MACHINE_START(CRANEBOARD, "AM3517/05 CRANEBOARD")
--
1.7.1.226.g770c5
^ permalink raw reply related [flat|nested] 17+ messages in thread* Re: [PATCH 2/2] AM35xx-Craneboard:Display: Add DVI and TV Support
2011-04-29 11:41 ` srinath at mistralsolutions.com
@ 2011-04-29 12:44 ` Sergei Shtylyov
-1 siblings, 0 replies; 17+ messages in thread
From: Sergei Shtylyov @ 2011-04-29 12:44 UTC (permalink / raw)
To: srinath
Cc: linux-omap, nm, linux, umeshk, tony, nagendra, linux-kernel,
khilman, jdk, linux-arm-kernel
Hello.
On 29-04-2011 15:41, srinath@mistralsolutions.com wrote:
> From: Srinath <srinath@mistralsolutions.com>
> Added Display (DVI and TV) support for CraneBoard.
> Signed-off-by: Srinath <srinath@mistralsolutions.com>
[...]
> diff --git a/arch/arm/mach-omap2/board-am3517crane.c b/arch/arm/mach-omap2/board-am3517crane.c
> index 05867b5..83fe85b 100644
> --- a/arch/arm/mach-omap2/board-am3517crane.c
> +++ b/arch/arm/mach-omap2/board-am3517crane.c
[...]
> @@ -66,11 +69,83 @@ static struct usbhs_omap_board_data usbhs_bdata __initdata = {
> .reset_gpio_port[2] = -EINVAL
> };
>
> +static void __init am3517_crane_display_init(void)
> +{
> + int ret;
> +
> + ret = omap_mux_init_gpio(GPIO_DVI_ENABLE, OMAP_PIN_OUTPUT);
> + if (ret< 0) {
> + pr_err("Can not configure mux for GPIO_DVI_ENABLE %d\n",
> + GPIO_DVI_ENABLE);
> + return;
> + }
> +
> + ret = gpio_request(GPIO_DVI_ENABLE, "dvi_enable");
> + if (ret< 0) {
> + pr_err("Can not request GPIO %d\n", GPIO_DVI_ENABLE);
> + return;
> + }
> +
> + ret = gpio_direction_output(GPIO_DVI_ENABLE, 1);
> + if (ret< 0) {
> + gpio_free(GPIO_DVI_ENABLE);
> + pr_err("Unable to enable DVI\n");
> + return;
> + }
You can use gpio_request_one() ISO gpio_request()/gpio_direction_output().
WBR, Sergei
^ permalink raw reply [flat|nested] 17+ messages in thread* [PATCH 2/2] AM35xx-Craneboard:Display: Add DVI and TV Support
@ 2011-04-29 12:44 ` Sergei Shtylyov
0 siblings, 0 replies; 17+ messages in thread
From: Sergei Shtylyov @ 2011-04-29 12:44 UTC (permalink / raw)
To: linux-arm-kernel
Hello.
On 29-04-2011 15:41, srinath at mistralsolutions.com wrote:
> From: Srinath <srinath@mistralsolutions.com>
> Added Display (DVI and TV) support for CraneBoard.
> Signed-off-by: Srinath <srinath@mistralsolutions.com>
[...]
> diff --git a/arch/arm/mach-omap2/board-am3517crane.c b/arch/arm/mach-omap2/board-am3517crane.c
> index 05867b5..83fe85b 100644
> --- a/arch/arm/mach-omap2/board-am3517crane.c
> +++ b/arch/arm/mach-omap2/board-am3517crane.c
[...]
> @@ -66,11 +69,83 @@ static struct usbhs_omap_board_data usbhs_bdata __initdata = {
> .reset_gpio_port[2] = -EINVAL
> };
>
> +static void __init am3517_crane_display_init(void)
> +{
> + int ret;
> +
> + ret = omap_mux_init_gpio(GPIO_DVI_ENABLE, OMAP_PIN_OUTPUT);
> + if (ret< 0) {
> + pr_err("Can not configure mux for GPIO_DVI_ENABLE %d\n",
> + GPIO_DVI_ENABLE);
> + return;
> + }
> +
> + ret = gpio_request(GPIO_DVI_ENABLE, "dvi_enable");
> + if (ret< 0) {
> + pr_err("Can not request GPIO %d\n", GPIO_DVI_ENABLE);
> + return;
> + }
> +
> + ret = gpio_direction_output(GPIO_DVI_ENABLE, 1);
> + if (ret< 0) {
> + gpio_free(GPIO_DVI_ENABLE);
> + pr_err("Unable to enable DVI\n");
> + return;
> + }
You can use gpio_request_one() ISO gpio_request()/gpio_direction_output().
WBR, Sergei
^ permalink raw reply [flat|nested] 17+ messages in thread
* [Patch v2] AM35xx-Craneboard: USB EHCI: Fix USB ECHI PHY reset
[not found] <[PATCH]>
@ 2011-05-02 13:40 ` srinath at mistralsolutions.com
2011-04-29 11:41 ` srinath at mistralsolutions.com
` (3 subsequent siblings)
4 siblings, 0 replies; 17+ messages in thread
From: srinath @ 2011-05-02 13:40 UTC (permalink / raw)
To: linux-omap
Cc: jdk, tony, linux-kernel, linux, linux-arm-kernel, khilman, nm,
nagendra, umeshk, Srinath.R
From: Srinath.R <srinath@mistralsolutions.com>
This patch fixes the EHCI PHY reset issue found on CraneBoard.
History:
https://patchwork.kernel.org/patch/740741/
Signed-off-by: Srinath.R <srinath@mistralsolutions.com>
---
arch/arm/mach-omap2/board-am3517crane.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-omap2/board-am3517crane.c b/arch/arm/mach-omap2/board-am3517crane.c
index a890d24..05867b5 100644
--- a/arch/arm/mach-omap2/board-am3517crane.c
+++ b/arch/arm/mach-omap2/board-am3517crane.c
@@ -60,7 +60,7 @@ static struct usbhs_omap_board_data usbhs_bdata __initdata = {
.port_mode[1] = OMAP_USBHS_PORT_MODE_UNUSED,
.port_mode[2] = OMAP_USBHS_PORT_MODE_UNUSED,
- .phy_reset = true,
+ .phy_reset = false,
.reset_gpio_port[0] = GPIO_USB_NRESET,
.reset_gpio_port[1] = -EINVAL,
.reset_gpio_port[2] = -EINVAL
--
1.5.3.4
^ permalink raw reply related [flat|nested] 17+ messages in thread* [Patch v2] AM35xx-Craneboard: USB EHCI: Fix USB ECHI PHY reset
@ 2011-05-02 13:40 ` srinath at mistralsolutions.com
0 siblings, 0 replies; 17+ messages in thread
From: srinath at mistralsolutions.com @ 2011-05-02 13:40 UTC (permalink / raw)
To: linux-arm-kernel
From: Srinath.R <srinath@mistralsolutions.com>
This patch fixes the EHCI PHY reset issue found on CraneBoard.
History:
https://patchwork.kernel.org/patch/740741/
Signed-off-by: Srinath.R <srinath@mistralsolutions.com>
---
arch/arm/mach-omap2/board-am3517crane.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-omap2/board-am3517crane.c b/arch/arm/mach-omap2/board-am3517crane.c
index a890d24..05867b5 100644
--- a/arch/arm/mach-omap2/board-am3517crane.c
+++ b/arch/arm/mach-omap2/board-am3517crane.c
@@ -60,7 +60,7 @@ static struct usbhs_omap_board_data usbhs_bdata __initdata = {
.port_mode[1] = OMAP_USBHS_PORT_MODE_UNUSED,
.port_mode[2] = OMAP_USBHS_PORT_MODE_UNUSED,
- .phy_reset = true,
+ .phy_reset = false,
.reset_gpio_port[0] = GPIO_USB_NRESET,
.reset_gpio_port[1] = -EINVAL,
.reset_gpio_port[2] = -EINVAL
--
1.5.3.4
^ permalink raw reply related [flat|nested] 17+ messages in thread
* [Patch v2] AM35xx-Craneboard:Display: Add DVI and TV Support
[not found] <[PATCH]>
@ 2011-05-02 13:40 ` srinath at mistralsolutions.com
2011-04-29 11:41 ` srinath at mistralsolutions.com
` (3 subsequent siblings)
4 siblings, 0 replies; 17+ messages in thread
From: srinath @ 2011-05-02 13:40 UTC (permalink / raw)
To: linux-omap
Cc: jdk, tony, linux-kernel, linux, linux-arm-kernel, khilman, nm,
nagendra, umeshk, Srinath.R
From: Srinath.R <srinath@mistralsolutions.com>
Added Display (DVI and TV) support for CraneBoard.
History:
https://patchwork.kernel.org/patch/740761/
Signed-off-by: Srinath.R <srinath@mistralsolutions.com>
---
arch/arm/mach-omap2/board-am3517crane.c | 73 +++++++++++++++++++++++++++++++
1 files changed, 73 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/board-am3517crane.c b/arch/arm/mach-omap2/board-am3517crane.c
index 05867b5..26fa565 100644
--- a/arch/arm/mach-omap2/board-am3517crane.c
+++ b/arch/arm/mach-omap2/board-am3517crane.c
@@ -29,12 +29,15 @@
#include <plat/board.h>
#include <plat/common.h>
#include <plat/usb.h>
+#include <plat/display.h>
+#include <plat/panel-generic-dpi.h>
#include "mux.h"
#include "control.h"
#define GPIO_USB_POWER 35
#define GPIO_USB_NRESET 38
+#define GPIO_DVI_ENABLE 52
/* Board initialization */
@@ -66,11 +69,78 @@ static struct usbhs_omap_board_data usbhs_bdata __initdata = {
.reset_gpio_port[2] = -EINVAL
};
+static void __init am3517_crane_display_init(void)
+{
+ int ret;
+
+ ret = omap_mux_init_gpio(GPIO_DVI_ENABLE, OMAP_PIN_OUTPUT);
+ if (ret < 0) {
+ pr_err("Can not configure mux for GPIO_DVI_ENABLE %d\n",
+ GPIO_DVI_ENABLE);
+ return;
+ }
+
+ ret = gpio_request_one(GPIO_DVI_ENABLE, GPIOF_OUT_INIT_HIGH,
+ "dvi_enable");
+ if (ret < 0) {
+ pr_err("Can not request GPIO %d\n", GPIO_DVI_ENABLE);
+ return;
+ }
+
+}
+
+static struct omap_dss_device am3517_crane_tv_device = {
+ .type = OMAP_DISPLAY_TYPE_VENC,
+ .name = "tv",
+ .driver_name = "venc",
+ .phy.venc.type = OMAP_DSS_VENC_TYPE_COMPOSITE,
+ .platform_enable = NULL,
+ .platform_disable = NULL,
+};
+
+static int am3517_crane_panel_enable_dvi(struct omap_dss_device *dssdev)
+{
+ gpio_set_value(GPIO_DVI_ENABLE, 1);
+ return 0;
+}
+
+static void am3517_crane_panel_disable_dvi(struct omap_dss_device *dssdev)
+{
+ gpio_set_value(GPIO_DVI_ENABLE, 0);
+}
+
+
+static struct panel_generic_dpi_data dvi_panel = {
+ .name = "generic",
+ .platform_enable = am3517_crane_panel_enable_dvi,
+ .platform_disable = am3517_crane_panel_disable_dvi,
+};
+
+static struct omap_dss_device am3517_crane_dvi_device = {
+ .type = OMAP_DISPLAY_TYPE_DPI,
+ .name = "dvi",
+ .driver_name = "generic_dpi_panel",
+ .data = &dvi_panel,
+ .phy.dpi.data_lines = 24,
+};
+
+static struct omap_dss_device *am3517_crane_dss_devices[] = {
+ &am3517_crane_tv_device,
+ &am3517_crane_dvi_device,
+};
+
+static struct omap_dss_board_info am3517_crane_dss_data = {
+ .num_devices = ARRAY_SIZE(am3517_crane_dss_devices),
+ .devices = am3517_crane_dss_devices,
+ .default_device = &am3517_crane_dvi_device,
+};
+
static void __init am3517_crane_init(void)
{
int ret;
omap3_mux_init(board_mux, OMAP_PACKAGE_CBB);
+ omap_display_init(&am3517_crane_dss_data);
omap_serial_init();
omap_board_config = am3517_crane_config;
@@ -103,6 +173,9 @@ static void __init am3517_crane_init(void)
}
usbhs_init(&usbhs_bdata);
+
+ /* DSS */
+ am3517_crane_display_init();
}
MACHINE_START(CRANEBOARD, "AM3517/05 CRANEBOARD")
--
1.5.3.4
^ permalink raw reply related [flat|nested] 17+ messages in thread* [Patch v2] AM35xx-Craneboard:Display: Add DVI and TV Support
@ 2011-05-02 13:40 ` srinath at mistralsolutions.com
0 siblings, 0 replies; 17+ messages in thread
From: srinath at mistralsolutions.com @ 2011-05-02 13:40 UTC (permalink / raw)
To: linux-arm-kernel
From: Srinath.R <srinath@mistralsolutions.com>
Added Display (DVI and TV) support for CraneBoard.
History:
https://patchwork.kernel.org/patch/740761/
Signed-off-by: Srinath.R <srinath@mistralsolutions.com>
---
arch/arm/mach-omap2/board-am3517crane.c | 73 +++++++++++++++++++++++++++++++
1 files changed, 73 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/board-am3517crane.c b/arch/arm/mach-omap2/board-am3517crane.c
index 05867b5..26fa565 100644
--- a/arch/arm/mach-omap2/board-am3517crane.c
+++ b/arch/arm/mach-omap2/board-am3517crane.c
@@ -29,12 +29,15 @@
#include <plat/board.h>
#include <plat/common.h>
#include <plat/usb.h>
+#include <plat/display.h>
+#include <plat/panel-generic-dpi.h>
#include "mux.h"
#include "control.h"
#define GPIO_USB_POWER 35
#define GPIO_USB_NRESET 38
+#define GPIO_DVI_ENABLE 52
/* Board initialization */
@@ -66,11 +69,78 @@ static struct usbhs_omap_board_data usbhs_bdata __initdata = {
.reset_gpio_port[2] = -EINVAL
};
+static void __init am3517_crane_display_init(void)
+{
+ int ret;
+
+ ret = omap_mux_init_gpio(GPIO_DVI_ENABLE, OMAP_PIN_OUTPUT);
+ if (ret < 0) {
+ pr_err("Can not configure mux for GPIO_DVI_ENABLE %d\n",
+ GPIO_DVI_ENABLE);
+ return;
+ }
+
+ ret = gpio_request_one(GPIO_DVI_ENABLE, GPIOF_OUT_INIT_HIGH,
+ "dvi_enable");
+ if (ret < 0) {
+ pr_err("Can not request GPIO %d\n", GPIO_DVI_ENABLE);
+ return;
+ }
+
+}
+
+static struct omap_dss_device am3517_crane_tv_device = {
+ .type = OMAP_DISPLAY_TYPE_VENC,
+ .name = "tv",
+ .driver_name = "venc",
+ .phy.venc.type = OMAP_DSS_VENC_TYPE_COMPOSITE,
+ .platform_enable = NULL,
+ .platform_disable = NULL,
+};
+
+static int am3517_crane_panel_enable_dvi(struct omap_dss_device *dssdev)
+{
+ gpio_set_value(GPIO_DVI_ENABLE, 1);
+ return 0;
+}
+
+static void am3517_crane_panel_disable_dvi(struct omap_dss_device *dssdev)
+{
+ gpio_set_value(GPIO_DVI_ENABLE, 0);
+}
+
+
+static struct panel_generic_dpi_data dvi_panel = {
+ .name = "generic",
+ .platform_enable = am3517_crane_panel_enable_dvi,
+ .platform_disable = am3517_crane_panel_disable_dvi,
+};
+
+static struct omap_dss_device am3517_crane_dvi_device = {
+ .type = OMAP_DISPLAY_TYPE_DPI,
+ .name = "dvi",
+ .driver_name = "generic_dpi_panel",
+ .data = &dvi_panel,
+ .phy.dpi.data_lines = 24,
+};
+
+static struct omap_dss_device *am3517_crane_dss_devices[] = {
+ &am3517_crane_tv_device,
+ &am3517_crane_dvi_device,
+};
+
+static struct omap_dss_board_info am3517_crane_dss_data = {
+ .num_devices = ARRAY_SIZE(am3517_crane_dss_devices),
+ .devices = am3517_crane_dss_devices,
+ .default_device = &am3517_crane_dvi_device,
+};
+
static void __init am3517_crane_init(void)
{
int ret;
omap3_mux_init(board_mux, OMAP_PACKAGE_CBB);
+ omap_display_init(&am3517_crane_dss_data);
omap_serial_init();
omap_board_config = am3517_crane_config;
@@ -103,6 +173,9 @@ static void __init am3517_crane_init(void)
}
usbhs_init(&usbhs_bdata);
+
+ /* DSS */
+ am3517_crane_display_init();
}
MACHINE_START(CRANEBOARD, "AM3517/05 CRANEBOARD")
--
1.5.3.4
^ permalink raw reply related [flat|nested] 17+ messages in thread
* [PATCH] ata: libata-core: Add NOLPM quirk for PNY 1TB SATA SSD
[not found] <[PATCH] ata: libata-core: Add quirks for PNY 1TB SATA SSD 916a>
@ 2026-10-28 12:42 ` Thierry Vignaud
2026-10-28 12:54 ` sashiko-bot
2026-10-28 14:54 ` [PATCH] ata: libata-core: Add NOLPM/NONCQ/1.5Gbps " Thierry Vignaud
1 sibling, 1 reply; 17+ messages in thread
From: Thierry Vignaud @ 2026-10-28 12:42 UTC (permalink / raw)
To: linux-ide; +Cc: Thierry Vignaud
Without that, I get the errors below.
For a year, I workaround it by disabling NCQ & reducing the speed by
booting with "libata.force=0:3.0Gbps,0:noncq".
It turns out disabling LPM fixes it without the huge performance hit.
Related: bko#222187
v2:
- remove firmware revision
- drop speed to 1.5Gbs
- disable NCQ altogether (else we still see the errors from times to
times)
Example of errors last year:
[999662.257282] ata3.00: exception Emask 0x0 SAct 0x2000 SErr 0x0 action 0x6 frozen
[999662.257298] ata3.00: failed command: READ FPDMA QUEUED
[999662.257302] ata3.00: cmd 60/20:68:40:7c:fb/00:00:d0:01:00/40 tag 13 ncq dma 16384 in
res 40/00:ff:00:f6:00/00:00:00:00:00/00 Emask 0x4 (timeout)
[999662.257317] ata3.00: status: { DRDY }
[999662.257325] ata3: hard resetting link
Example of errors this year:
kernel: sd 0:0:0:0: [sda] tag#2 FAILED Result: hostbyte=DID_TIME_OUT driverbyte=DRIVER_OK cmd_age=44s
kernel: sd 0:0:0:0: [sda] tag#2 CDB: Write(10) 2a 00 64 10 48 70 00 20 00 00
kernel: I/O error, dev sda, sector 1678788720 op 0x1:(WRITE) flags 0x0 phys_seg 87 prio class 2
kernel: EXT4-fs warning (device sda1): ext4_end_bio:360: I/O error 10 writing to inode 36831430 starting block 209848590)
kernel: sd 0:0:0:0: [sda] tag#3 FAILED Result: hostbyte=DID_TIME_OUT driverbyte=DRIVER_OK cmd_age=44s
kernel: sd 0:0:0:0: [sda] tag#3 CDB: Write(10) 2a 00 64 10 2e 28 00 03 08 00
kernel: I/O error, dev sda, sector 1678781992 op 0x1:(WRITE) flags 0x0 phys_seg 88 prio class 2
kernel: EXT4-fs warning (device sda1): ext4_end_bio:360: I/O error 10 writing to inode 36831430 starting block 209847749)
kernel: sd 0:0:0:0: [sda] tag#4 FAILED Result: hostbyte=DID_TIME_OUT driverbyte=DRIVER_OK cmd_age=44s
kernel: sd 0:0:0:0: [sda] tag#4 CDB: Write(10) 2a 00 64 10 31 30 00 05 90 00
kernel: I/O error, dev sda, sector 1678782768 op 0x1:(WRITE) flags 0x4000 phys_seg 168 prio class 2
kernel: sd 0:0:0:0: [sda] tag#5 FAILED Result: hostbyte=DID_TIME_OUT driverbyte=DRIVER_OK cmd_age=44s
kernel: sd 0:0:0:0: [sda] tag#5 CDB: Write(10) 2a 00 64 10 36 c0 00 02 f0 00
kernel: I/O error, dev sda, sector 1678784192 op 0x1:(WRITE) flags 0x0 phys_seg 88 prio class 2
kernel: EXT4-fs warning (device sda1): ext4_end_bio:360: I/O error 10 writing to inode 36831430 starting block 209848024)
kernel: sd 0:0:0:0: [sda] tag#6 FAILED Result: hostbyte=DID_TIME_OUT driverbyte=DRIVER_OK cmd_age=44s
kernel: sd 0:0:0:0: [sda] tag#6 CDB: Write(10) 2a 00 64 10 39 b0 00 05 70 00
kernel: I/O error, dev sda, sector 1678784944 op 0x1:(WRITE) flags 0x4000 phys_seg 168 prio class 2
kernel: EXT4-fs warning (device sda1): ext4_end_bio:360: I/O error 10 writing to inode 36831430 starting block 209848292)
kernel: sd 0:0:0:0: [sda] tag#7 FAILED Result: hostbyte=DID_TIME_OUT driverbyte=DRIVER_OK cmd_age=44s
kernel: sd 0:0:0:0: [sda] tag#7 CDB: Write(10) 2a 00 64 10 88 70 00 20 00 00
kernel: I/O error, dev sda, sector 1678805104 op 0x1:(WRITE) flags 0x0 phys_seg 65 prio class 2
kernel: EXT4-fs warning (device sda1): ext4_end_bio:360: I/O error 10 writing to inode 36831430 starting block 209850638)
kernel: sd 0:0:0:0: [sda] tag#8 FAILED Result: hostbyte=DID_TIME_OUT driverbyte=DRIVER_OK cmd_age=44s
kernel: sd 0:0:0:0: [sda] tag#8 CDB: Write(10) 2a 00 64 10 a8 70 00 0e c0 00
kernel: I/O error, dev sda, sector 1678813296 op 0x1:(WRITE) flags 0x4000 phys_seg 168 prio class 2
kernel: sd 0:0:0:0: [sda] tag#9 FAILED Result: hostbyte=DID_TIME_OUT driverbyte=DRIVER_OK cmd_age=39s
kernel: sd 0:0:0:0: [sda] tag#9 CDB: Write(10) 2a 00 64 10 b7 30 00 11 40 00
kernel: I/O error, dev sda, sector 1678817072 op 0x1:(WRITE) flags 0x4000 phys_seg 87 prio class 2
kernel: EXT4-fs warning (device sda1): ext4_end_bio:360: I/O error 10 writing to inode 36831430 starting block 209852134)
kernel: EXT4-fs warning (device sda1): ext4_end_bio:360: I/O error 10 writing to inode 36831430 starting block 209852672)
kernel: EXT4-fs (sda1): failed to convert unwritten extents to written extents -- potential data loss! (inode 36831430, error -5)
kernel: Buffer I/O error on device sda1, logical block 209848334
kernel: Buffer I/O error on device sda1, logical block 209848335
kernel: Buffer I/O error on device sda1, logical block 209848336
---
drivers/ata/libata-core.c | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/drivers/ata/libata-core.c b/drivers/ata/libata-core.c
index dadcaf9ff462..cf36f2638fab 100644
--- a/drivers/ata/libata-core.c
+++ b/drivers/ata/libata-core.c
@@ -4398,6 +4398,11 @@ static const struct ata_dev_quirks_entry __ata_dev_quirks[] = {
/* PNY CS900 (Phison PS3111-S11, DRAM-less) drops the link on DIPM */
{ "PNY CS900 1TB SSD", NULL, ATA_QUIRK_NOLPM },
+ /* PNY CS900 (variant) drops the link on DIPM and NCQ */
+ { "PNY 1TB SATA SSD", NULL, ATA_QUIRK_NOLPM |
+ ATA_QUIRK_1_5_GBPS |
+ ATA_QUIRK_NONCQ },
+
/* Silicon Motion models with LPM issues */
{ "MD619HXCLDE3TC", "TCVAID", ATA_QUIRK_NOLPM },
{ "MD619GXCLDE3TC", "TCV35D", ATA_QUIRK_NOLPM },
--
2.56.0
^ permalink raw reply related [flat|nested] 17+ messages in thread* Re: [PATCH] ata: libata-core: Add NOLPM quirk for PNY 1TB SATA SSD
2026-10-28 12:42 ` [PATCH] ata: libata-core: Add NOLPM quirk for PNY 1TB SATA SSD Thierry Vignaud
@ 2026-10-28 12:54 ` sashiko-bot
2026-10-28 13:25 ` Thierry Vignaud
0 siblings, 1 reply; 17+ messages in thread
From: sashiko-bot @ 2026-10-28 12:54 UTC (permalink / raw)
To: Thierry Vignaud, linux-ide; +Cc: dlemoal, cassel
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] ata: libata-core: overly broad 1.5Gbps and NONCQ quirks for PNY 1TB SATA SSD
--
commit 0d9a8ef67d5864f02d54ceedd7d99487c051f554
Author: Thierry Vignaud <tvignaud@redhat.com>
ata: libata-core: Add NOLPM quirk for PNY 1TB SATA SSD
This commit adds an entry to __ata_dev_quirks[] for the "PNY 1TB SATA SSD"
drive with ATA_QUIRK_NOLPM, ATA_QUIRK_1_5_GBPS, and ATA_QUIRK_NONCQ across
all firmware revisions.
> diff --git a/drivers/ata/libata-core.c b/drivers/ata/libata-core.c
> index dadcaf9ff4622..cf36f2638fab3 100644
> --- a/drivers/ata/libata-core.c
> +++ b/drivers/ata/libata-core.c
> @@ -4398,6 +4398,11 @@ static const struct ata_dev_quirks_entry __ata_dev_quirks[] = {
> /* PNY CS900 (Phison PS3111-S11, DRAM-less) drops the link on DIPM */
> { "PNY CS900 1TB SSD", NULL, ATA_QUIRK_NOLPM },
>
> + /* PNY CS900 (variant) drops the link on DIPM and NCQ */
> + { "PNY 1TB SATA SSD", NULL, ATA_QUIRK_NOLPM |
> + ATA_QUIRK_1_5_GBPS |
> + ATA_QUIRK_NONCQ },
[Severity: High]
Could applying ATA_QUIRK_1_5_GBPS and ATA_QUIRK_NONCQ across all firmware
revisions (NULL) of "PNY 1TB SATA SSD" cause a severe performance regression
for other users of this drive?
During ata_dev_configure() -> ata_dev_quirks(), every "PNY 1TB SATA SSD" will
match this entry regardless of firmware revision. In ata_do_link_spd_quirk(),
ATA_QUIRK_1_5_GBPS clamps the physical SATA link speed limit to 1.5 Gbps:
drivers/ata/libata-core.c:ata_do_link_spd_quirk() {
if (dev->quirks & ATA_QUIRK_1_5_GBPS)
target = 1;
else
return 0;
target_limit = (1 << target) - 1;
/* if already on stricter limit, no need to push further */
if (plink->sata_spd_limit <= target_limit)
return 0;
plink->sata_spd_limit = target_limit;
}
Unlike ATA_QUIRK_NOLPM and ATA_QUIRK_NONCQ, force_tbl[] has no on/off entry
for ATA_QUIRK_1_5_GBPS, so users with working drives cannot override this
1.5 Gbps cap via libata.force. Meanwhile, ata_dev_config_ncq() also disables
NCQ completely when ATA_QUIRK_NONCQ is set.
Additionally, the commit title and opening description state:
For a year, I workaround it by disabling NCQ & reducing the speed by
booting with "libata.force=0:3.0Gbps,0:noncq".
It turns out disabling LPM fixes it without the huge performance hit.
while the embedded "v2:" changelog notes and the code itself instead drop the
speed to 1.5 Gbps, disable NCQ, and remove the firmware revision filter, and
the code comment above the entry does not mention the 1.5 Gbps limit.
Note also that in ata_port_alloc(), port IDs (ap->print_id) are allocated
starting at 1:
drivers/ata/libata-core.c:ata_port_alloc() {
id = ida_alloc_min(&ata_ida, 1, GFP_KERNEL);
if (id < 0) {
kfree(ap);
return NULL;
}
ap->print_id = id;
}
Because port numbering starts at 1, "libata.force=0:3.0Gbps,0:noncq" never
matched any port in ata_force_link_limits() or ata_force_quirks(), which matches
the commit message logs on sda still showing queued commands (tag#2 through
tag#9).
If a specific drive requires 1.5 Gbps, no NCQ, and no LPM simultaneously to
avoid link timeouts, could that indicate a local cable, controller, or hardware
unit issue rather than a quirk that should be applied unconditionally to all
"PNY 1TB SATA SSD" drives and firmware revisions?
--
Sashiko AI review · https://sashiko.dev/#/patchset/20261028124328.597603-1-tvignaud@redhat.com?part=1
^ permalink raw reply [flat|nested] 17+ messages in thread* Re: [PATCH] ata: libata-core: Add NOLPM quirk for PNY 1TB SATA SSD
2026-10-28 12:54 ` sashiko-bot
@ 2026-10-28 13:25 ` Thierry Vignaud
0 siblings, 0 replies; 17+ messages in thread
From: Thierry Vignaud @ 2026-10-28 13:25 UTC (permalink / raw)
To: sashiko-reviews; +Cc: linux-ide, dlemoal, cassel
On Wed, Oct 28, 2026 at 1:59 PM <sashiko-bot@kernel.org> wrote:
>
> Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
> - [High] ata: libata-core: overly broad 1.5Gbps and NONCQ quirks for PNY 1TB SATA SSD
> --
>
> commit 0d9a8ef67d5864f02d54ceedd7d99487c051f554
> Author: Thierry Vignaud <tvignaud@redhat.com>
>
> ata: libata-core: Add NOLPM quirk for PNY 1TB SATA SSD
>
> This commit adds an entry to __ata_dev_quirks[] for the "PNY 1TB SATA SSD"
> drive with ATA_QUIRK_NOLPM, ATA_QUIRK_1_5_GBPS, and ATA_QUIRK_NONCQ across
> all firmware revisions.
>
> > diff --git a/drivers/ata/libata-core.c b/drivers/ata/libata-core.c
> > index dadcaf9ff4622..cf36f2638fab3 100644
> > --- a/drivers/ata/libata-core.c
> > +++ b/drivers/ata/libata-core.c
> > @@ -4398,6 +4398,11 @@ static const struct ata_dev_quirks_entry __ata_dev_quirks[] = {
> > /* PNY CS900 (Phison PS3111-S11, DRAM-less) drops the link on DIPM */
> > { "PNY CS900 1TB SSD", NULL, ATA_QUIRK_NOLPM },
> >
> > + /* PNY CS900 (variant) drops the link on DIPM and NCQ */
> > + { "PNY 1TB SATA SSD", NULL, ATA_QUIRK_NOLPM |
> > + ATA_QUIRK_1_5_GBPS |
> > + ATA_QUIRK_NONCQ },
>
> [Severity: High]
> Could applying ATA_QUIRK_1_5_GBPS and ATA_QUIRK_NONCQ across all firmware
> revisions (NULL) of "PNY 1TB SATA SSD" cause a severe performance regression
> for other users of this drive?
>
> During ata_dev_configure() -> ata_dev_quirks(), every "PNY 1TB SATA SSD" will
> match this entry regardless of firmware revision. In ata_do_link_spd_quirk(),
> ATA_QUIRK_1_5_GBPS clamps the physical SATA link speed limit to 1.5 Gbps:
>
> drivers/ata/libata-core.c:ata_do_link_spd_quirk() {
> if (dev->quirks & ATA_QUIRK_1_5_GBPS)
> target = 1;
> else
> return 0;
>
> target_limit = (1 << target) - 1;
>
> /* if already on stricter limit, no need to push further */
> if (plink->sata_spd_limit <= target_limit)
> return 0;
>
> plink->sata_spd_limit = target_limit;
> }
>
> Unlike ATA_QUIRK_NOLPM and ATA_QUIRK_NONCQ, force_tbl[] has no on/off entry
> for ATA_QUIRK_1_5_GBPS, so users with working drives cannot override this
> 1.5 Gbps cap via libata.force. Meanwhile, ata_dev_config_ncq() also disables
> NCQ completely when ATA_QUIRK_NONCQ is set.
>
> Additionally, the commit title and opening description state:
>
> For a year, I workaround it by disabling NCQ & reducing the speed by
> booting with "libata.force=0:3.0Gbps,0:noncq".
> It turns out disabling LPM fixes it without the huge performance hit.
>
> while the embedded "v2:" changelog notes and the code itself instead drop the
> speed to 1.5 Gbps, disable NCQ, and remove the firmware revision filter, and
> the code comment above the entry does not mention the 1.5 Gbps limit.
>
> Note also that in ata_port_alloc(), port IDs (ap->print_id) are allocated
> starting at 1:
>
> drivers/ata/libata-core.c:ata_port_alloc() {
> id = ida_alloc_min(&ata_ida, 1, GFP_KERNEL);
> if (id < 0) {
> kfree(ap);
> return NULL;
> }
> ap->print_id = id;
> }
>
> Because port numbering starts at 1, "libata.force=0:3.0Gbps,0:noncq" never
> matched any port in ata_force_link_limits() or ata_force_quirks(), which matches
> the commit message logs on sda still showing queued commands (tag#2 through
> tag#9).
I actually used the prefix "1:" eg :
août 01 09:17:31 localhost kernel: Command line:
BOOT_IMAGE=/boot/vmlinuz-7.0.1-desktop-1.mainline.mga10
root=UUID=95a19996-436f-4ce1-9779-26b13c319972 ro splash quiet noiswmd
resume=UUID=18acfa47-8d6c-46f4-9700-5c9506931817 audit=0
libata.force=1:3.0Gbps,1:noncq
I mistakely changed it to ":0" a cople weeks ago, which showed again
the issues, which is why I worked on this patch:
oct. 23 10:05:59 localhost kernel: Command line:
BOOT_IMAGE=/boot/vmlinuz-7.3.0-desktop-1.mainline.mga11
root=UUID=95a19996-436f-4ce1-9779-26b13c319972 ro splash quiet noiswmd
resume=UUID=18acfa47-8d6c-46f4-9700-5c9506931817 audit=0
libata.force=0:3.0Gbps,0:noncq,0:nolpm
I used the 1.5Gbps quirk in the patch b/c there's no 3.0Gbps in drivers/ata
I could add such a quirk now that there's 64 bits for quirks but
honestly that shouldn't impact much this low end SSD.
> If a specific drive requires 1.5 Gbps, no NCQ, and no LPM simultaneously to
> avoid link timeouts, could that indicate a local cable, controller, or hardware
> unit issue rather than a quirk that should be applied unconditionally to all
> "PNY 1TB SATA SSD" drives and firmware revisions?
I'm not the first one to reports issues with that SSD, see eg:
https://forums.linuxmint.com/viewtopic.php?t=424548
https://www.truenas.com/community/threads/help-zfs-continue-failing-with-pool-i-o-failures.110424/
=> https://web.archive.org/web/20260319124414/https://www.truenas.com/community/threads/help-zfs-continue-failing-with-pool-i-o-failures.110424/
So PNY CS900 looks buggy across all sizes, at least under Linux.
So actually my patch won't cover all affected CS900 b/c it only covers
the "1Gb" model.
I can add the firmware revision to the quirk if you insist though.
^ permalink raw reply [flat|nested] 17+ messages in thread
* [PATCH] ata: libata-core: Add NOLPM/NONCQ/1.5Gbps quirk for PNY 1TB SATA SSD
[not found] <[PATCH] ata: libata-core: Add quirks for PNY 1TB SATA SSD 916a>
2026-10-28 12:42 ` [PATCH] ata: libata-core: Add NOLPM quirk for PNY 1TB SATA SSD Thierry Vignaud
@ 2026-10-28 14:54 ` Thierry Vignaud
1 sibling, 0 replies; 17+ messages in thread
From: Thierry Vignaud @ 2026-10-28 14:54 UTC (permalink / raw)
To: linux-ide; +Cc: Thierry Vignaud
Without that, I get the errors below.
For a year, I workaround it by disabling NCQ & reducing the speed by
booting with "libata.force=1:3.0Gbps,1:noncq".
It tried out disabling LPM only but I was still able to see errors.
Related: bko#222187
v3:
- add firmware revision check
v2:
- remove firmware revision from SSD name
- drop speed to 1.5Gbs (as there's no 3.0Gbps quirk)
- disable NCQ altogether (else we still see the errors from times to
times)
Example of errors:
ata1.00: exception Emask 0x0 SAct 0x1c SErr 0x0 action 0x6 frozen
ata1.00: failed command: WRITE FPDMA QUEUED
ata1.00: cmd 61/00:10:00:a8:a9/20:00:6f:00:00/40 tag 2 ncq dma 4194304 ou
res 40/00:ff:00:00:00/00:00:00:00:00/00 Emask 0x4 (timeout)
ata1.00: status: { DRDY }
ata1.00: failed command: WRITE FPDMA QUEUED
ata1.00: cmd 61/40:18:30:ce:51/05:00:39:00:00/40 tag 3 ncq dma 688128 out
res 40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x4 (timeout)
ata1.00: status: { DRDY }
ata1.00: failed command: WRITE FPDMA QUEUED
ata1.00: cmd 61/50:20:70:d3:51/02:00:39:00:00/40 tag 4 ncq dma 303104 out
res 40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x4 (timeout)
ata1.00: status: { DRDY }
ata1: hard resetting link
ata1: SATA link up 1.5 Gbps (SStatus 113 SControl 310)
ata1.00: configured for UDMA/133
ata1: EH complete
sd 0:0:0:0: [sda] tag#10 FAILED Result: hostbyte=DID_TIME_OUT driverbyte=DRIVER_OK cmd_age=43s
sd 0:0:0:0: [sda] tag#10 CDB: Write(10) 2a 00 6e e6 88 00 00 10 00 00
I/O error, dev sda, sector 1860601856 op 0x1:(WRITE) flags 0x4000 phys_seg 32 prio class 2
EXT4-fs warning (device sda1): ext4_end_bio:360: I/O error 10 writing to inode 33841832 starting block 232575232)
sd 0:0:0:0: [sda] tag#11 FAILED Result: hostbyte=DID_TIME_OUT driverbyte=DRIVER_OK cmd_age=43s
sd 0:0:0:0: [sda] tag#11 CDB: Write(10) 2a 00 6e e6 98 00 00 20 00 00
I/O error, dev sda, sector 1860605952 op 0x1:(WRITE) flags 0x4000 phys_seg 64 prio class 2
(…)
EXT4-fs warning (device sda1): ext4_end_bio:360: I/O error 10 writing to inode 33841806 starting block 232583424)
EXT4-fs (sda1): failed to convert unwritten extents to written extents -- potential data loss! (inode 36499395, error -5)
Buffer I/O error on device sda1, logical block 155756907
Buffer I/O error on device sda1, logical block 155756908
Buffer I/O error on device sda1, logical block 155756909
Buffer I/O error on device sda1, logical block 155756910
Buffer I/O error on device sda1, logical block 155756911
Buffer I/O error on device sda1, logical block 155756912
Buffer I/O error on device sda1, logical block 155756913
Buffer I/O error on device sda1, logical block 155756914
Buffer I/O error on device sda1, logical block 155756915
Buffer I/O error on device sda1, logical block 155756916
EXT4-fs (sda1): failed to convert unwritten extents to written extents -- potential data loss! (inode 36499424, error -5)
---
drivers/ata/libata-core.c | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/drivers/ata/libata-core.c b/drivers/ata/libata-core.c
index dadcaf9ff462..cde9d367c20f 100644
--- a/drivers/ata/libata-core.c
+++ b/drivers/ata/libata-core.c
@@ -4398,6 +4398,13 @@ static const struct ata_dev_quirks_entry __ata_dev_quirks[] = {
/* PNY CS900 (Phison PS3111-S11, DRAM-less) drops the link on DIPM */
{ "PNY CS900 1TB SSD", NULL, ATA_QUIRK_NOLPM },
+ /* PNY CS900 (variant) drops the link on DIPM and NCQ
+ * This covers only the 1TB variant but other sizes are affected
+ * according to forum posts */
+ { "PNY 1TB SATA SSD", "H220916a", ATA_QUIRK_NOLPM |
+ ATA_QUIRK_1_5_GBPS |
+ ATA_QUIRK_NONCQ },
+
/* Silicon Motion models with LPM issues */
{ "MD619HXCLDE3TC", "TCVAID", ATA_QUIRK_NOLPM },
{ "MD619GXCLDE3TC", "TCV35D", ATA_QUIRK_NOLPM },
--
2.56.0
^ permalink raw reply related [flat|nested] 17+ messages in thread