Re: [BUG] Kernel panic when try s3c-hsotg.c with kernel 3.5
Dear Peiyong Feng, Please enable the debug at s3c-hsotg.c driver and then paste the dmesg/debug output. I have defined DEGUG in s3c-hsotg.c Thank you for 2.6.36 log. I'd also need the log from 3.6-rc1 kernel with DEBUG enabled. -- Best regards, Lukasz Majewski Samsung Poland RD Center | Linux Platform Group -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH v2] usb:musb:musb_host: Handle highmem in PIO mode
-Original Message-
From: Alan Stern [mailto:st...@rowland.harvard.edu]
Sent: Tuesday, August 07, 2012 11:17 PM
To: Virupax SADASHIVPETIMATH
Cc: ba...@ti.com; gre...@linuxfoundation.org; linux-usb@vger.kernel.org;
linux-
ker...@vger.kernel.org; linus.wall...@linaro.org; Praveena NADAHALLY; Rajaram
REGUPATHY; Vikrant BAPAT
Subject: Re: [PATCH v2] usb:musb:musb_host: Handle highmem in PIO mode
+*/
+ if (!urb-transfer_buffer)
+ use_sg = true;
Here you test urb-transfer_buffer.
I will make the test as
if (!use_sg !urb-transfer_buffer)
use_sg = true;
+ if (use_sg) {
+ /* sg_miter_start is already done in musb_ep_program */
+ if (!sg_miter_next(qh-sg_miter)) {
+ dev_err(musb-controller, error: sg list empty\n);
+ sg_miter_stop(qh-sg_miter);
+ status = -EINVAL;
+ goto done;
+ }
+ urb-transfer_buffer = qh-sg_miter.addr;
And here you set it. As a result, on the next iteration of this
routine the test above won't work right. (This function gets invoked
once for each entry in the sg list, right?)
Is there any reason to set urb-transfer_buffer here? You could just
use qh-sg_miter.addr directly in the musb_write_fifo() call two lines
below.
I will change it.
Thanks
Virupax S
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3] usb:musb:musb_host: Handle highmem in PIO mode
In case of USB bulk transfer, when himem page
is received, the usb_sg_init function sets the
urb transfer buffer to NULL. When such URB
transfer is handled, kernel crashes in PIO mode.
Handle this by mapping the highmem buffer in PIO mode.
Signed-off-by: Virupax Sadashivpetimath
virupax.sadashivpetim...@stericsson.com
Signed-off-by: Praveena NADAHALLY praveen.nadaha...@stericsson.com
Acked-by: Linus Walleij linus.wall...@linaro.org
---
drivers/usb/musb/musb_host.c | 97 +++--
drivers/usb/musb/musb_host.h |3 +
2 files changed, 95 insertions(+), 5 deletions(-)
diff --git a/drivers/usb/musb/musb_host.c b/drivers/usb/musb/musb_host.c
index 4bb717d..3ba9a4b 100644
--- a/drivers/usb/musb/musb_host.c
+++ b/drivers/usb/musb/musb_host.c
@@ -813,9 +813,28 @@ static void musb_ep_program(struct musb *musb, u8 epnum,
if (load_count) {
/* PIO to load FIFO */
qh-segsize = load_count;
- musb_write_fifo(hw_ep, load_count, buf);
+ if (!buf) {
+ sg_miter_start(qh-sg_miter, urb-sg, 1,
+ SG_MITER_ATOMIC
+ | SG_MITER_FROM_SG);
+ if (!sg_miter_next(qh-sg_miter)) {
+ dev_err(musb-controller,
+ error: sg
+ list empty\n);
+ sg_miter_stop(qh-sg_miter);
+ goto finish;
+ }
+ buf = qh-sg_miter.addr + urb-sg-offset +
+ urb-actual_length;
+ load_count = min_t(u32, load_count,
+ qh-sg_miter.length);
+ musb_write_fifo(hw_ep, load_count, buf);
+ qh-sg_miter.consumed = load_count;
+ sg_miter_stop(qh-sg_miter);
+ } else
+ musb_write_fifo(hw_ep, load_count, buf);
}
-
+finish:
/* re-enable interrupt */
musb_writew(mbase, MUSB_INTRTXE, int_txe);
@@ -1116,6 +1135,7 @@ void musb_host_tx(struct musb *musb, u8 epnum)
void __iomem*mbase = musb-mregs;
struct dma_channel *dma;
booltransfer_pending = false;
+ static bool use_sg;
musb_ep_select(mbase, epnum);
tx_csr = musb_readw(epio, MUSB_TXCSR);
@@ -1163,6 +1183,7 @@ void musb_host_tx(struct musb *musb, u8 epnum)
return;
}
+done:
if (status) {
if (dma_channel_status(dma) == MUSB_DMA_STATUS_BUSY) {
dma-status = MUSB_DMA_STATUS_CORE_ABORT;
@@ -1332,9 +1353,37 @@ void musb_host_tx(struct musb *musb, u8 epnum)
length = qh-maxpacket;
/* Unmap the buffer so that CPU can use it */
usb_hcd_unmap_urb_for_dma(musb_to_hcd(musb), urb);
- musb_write_fifo(hw_ep, length, urb-transfer_buffer + offset);
+
+ /*
+* We need to map sg if the transfer_buffer is
+* NULL.
+*/
+ if (!use_sg !urb-transfer_buffer)
+ use_sg = true;
+
+ if (use_sg) {
+ /* sg_miter_start is already done in musb_ep_program */
+ if (!sg_miter_next(qh-sg_miter)) {
+ dev_err(musb-controller, error: sg list empty\n);
+ sg_miter_stop(qh-sg_miter);
+ status = -EINVAL;
+ goto done;
+ }
+ length = min_t(u32, length, qh-sg_miter.length);
+ musb_write_fifo(hw_ep, length, qh-sg_miter.addr);
+ qh-sg_miter.consumed = length;
+ sg_miter_stop(qh-sg_miter);
+ } else {
+ musb_write_fifo(hw_ep, length, urb-transfer_buffer + offset);
+ }
+
qh-segsize = length;
+ if (use_sg) {
+ if (offset + length = urb-transfer_buffer_length)
+ use_sg = false;
+ }
+
musb_ep_select(mbase, epnum);
musb_writew(epio, MUSB_TXCSR,
MUSB_TXCSR_H_WZC_BITS | MUSB_TXCSR_TXPKTRDY);
@@ -1442,6 +1491,8 @@ void musb_host_rx(struct musb *musb, u8 epnum)
booldone = false;
u32 status;
struct dma_channel *dma;
+ static bool use_sg;
+ unsigned int sg_flags = SG_MITER_ATOMIC | SG_MITER_TO_SG;
musb_ep_select(mbase, epnum);
@@ -1756,10 +1807,43 @@ void musb_host_rx(struct musb *musb, u8 epnum)
#endif /* Mentor DMA */
if (!dma) {
+ unsigned int
Re: [BUG] Kernel panic when try s3c-hsotg.c with kernel 3.5
2012/8/8 Lukasz Majewski l.majew...@samsung.com: Dear Peiyong Feng, Please enable the debug at s3c-hsotg.c driver and then paste the dmesg/debug output. I have defined DEGUG in s3c-hsotg.c Thank you for 2.6.36 log. I'd also need the log from 3.6-rc1 kernel with DEBUG enabled. I have made a define like: #define DEBUG in s3c-hsotg.c of 3.6-rc1 kernel and the patch: == diff --git a/drivers/usb/gadget/s3c-hsotg.c b/drivers/usb/gadget/s3c-hsotg.c index b13e0bb..b35d275 100644 --- a/drivers/usb/gadget/s3c-hsotg.c +++ b/drivers/usb/gadget/s3c-hsotg.c @@ -36,6 +36,7 @@ #include mach/map.h +#define DEBUG #include s3c-hsotg.h #define DMA_ADDR_INVALID (~((dma_addr_t)0)) =- And the output is just the same as I have posted. If that is not the way you want, please let me know. -- Best regards, Lukasz Majewski Samsung Poland RD Center | Linux Platform Group -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3 3/5] ARM: S3C64XX: Removing old phy setup code
This patch removes old phy code from platform side. 'setup-usb-phy.c'
will be used for providing transceiver platform data in next
patch. Not all of the platform data code is removed as there are others
making use of platform_data defined for hsotg. That can be removed once
all the SoCs start using the new transceiver for usb phy setup.
Signed-off-by: Praveen Paneri p.pan...@samsung.com
---
arch/arm/mach-s3c64xx/mach-crag6410.c |3 -
arch/arm/mach-s3c64xx/mach-smartq.c |3 -
arch/arm/mach-s3c64xx/mach-smdk6410.c |3 -
arch/arm/mach-s3c64xx/setup-usb-phy.c | 79 -
4 files changed, 0 insertions(+), 88 deletions(-)
diff --git a/arch/arm/mach-s3c64xx/mach-crag6410.c
b/arch/arm/mach-s3c64xx/mach-crag6410.c
index 09cd812..b0f5baf 100644
--- a/arch/arm/mach-s3c64xx/mach-crag6410.c
+++ b/arch/arm/mach-s3c64xx/mach-crag6410.c
@@ -31,7 +31,6 @@
#include linux/spi/spi.h
#include linux/i2c/pca953x.h
-#include linux/platform_data/s3c-hsotg.h
#include video/platform_lcd.h
@@ -766,7 +765,6 @@ static const struct gpio_led_platform_data gpio_leds_pdata
= {
.num_leds = ARRAY_SIZE(gpio_leds),
};
-static struct s3c_hsotg_plat crag6410_hsotg_pdata;
static void __init crag6410_machine_init(void)
{
@@ -792,7 +790,6 @@ static void __init crag6410_machine_init(void)
s3c_i2c0_set_platdata(i2c0_pdata);
s3c_i2c1_set_platdata(i2c1_pdata);
s3c_fb_set_platdata(crag6410_lcd_pdata);
- s3c_hsotg_set_platdata(crag6410_hsotg_pdata);
i2c_register_board_info(0, i2c_devs0, ARRAY_SIZE(i2c_devs0));
i2c_register_board_info(1, i2c_devs1, ARRAY_SIZE(i2c_devs1));
diff --git a/arch/arm/mach-s3c64xx/mach-smartq.c
b/arch/arm/mach-s3c64xx/mach-smartq.c
index ceeb1de..7400da1 100644
--- a/arch/arm/mach-s3c64xx/mach-smartq.c
+++ b/arch/arm/mach-s3c64xx/mach-smartq.c
@@ -18,7 +18,6 @@
#include linux/serial_core.h
#include linux/spi/spi_gpio.h
#include linux/usb/gpio_vbus.h
-#include linux/platform_data/s3c-hsotg.h
#include asm/mach-types.h
#include asm/mach/map.h
@@ -187,7 +186,6 @@ static struct s3c_hwmon_pdata smartq_hwmon_pdata __initdata
= {
},
};
-static struct s3c_hsotg_plat smartq_hsotg_pdata;
static int __init smartq_lcd_setup_gpio(void)
{
@@ -385,7 +383,6 @@ void __init smartq_map_io(void)
void __init smartq_machine_init(void)
{
s3c_i2c0_set_platdata(NULL);
- s3c_hsotg_set_platdata(smartq_hsotg_pdata);
s3c_hwmon_set_platdata(smartq_hwmon_pdata);
s3c_sdhci1_set_platdata(smartq_internal_hsmmc_pdata);
s3c_sdhci2_set_platdata(smartq_internal_hsmmc_pdata);
diff --git a/arch/arm/mach-s3c64xx/mach-smdk6410.c
b/arch/arm/mach-s3c64xx/mach-smdk6410.c
index 0fe4f15..cbdc91b 100644
--- a/arch/arm/mach-s3c64xx/mach-smdk6410.c
+++ b/arch/arm/mach-s3c64xx/mach-smdk6410.c
@@ -30,7 +30,6 @@
#include linux/regulator/fixed.h
#include linux/regulator/machine.h
#include linux/pwm_backlight.h
-#include linux/platform_data/s3c-hsotg.h
#ifdef CONFIG_SMDK6410_WM1190_EV1
#include linux/mfd/wm8350/core.h
@@ -627,7 +626,6 @@ static struct platform_pwm_backlight_data smdk6410_bl_data
= {
.pwm_id = 1,
};
-static struct s3c_hsotg_plat smdk6410_hsotg_pdata;
static void __init smdk6410_map_io(void)
{
@@ -657,7 +655,6 @@ static void __init smdk6410_machine_init(void)
s3c_i2c0_set_platdata(NULL);
s3c_i2c1_set_platdata(NULL);
s3c_fb_set_platdata(smdk6410_lcd_pdata);
- s3c_hsotg_set_platdata(smdk6410_hsotg_pdata);
samsung_keypad_set_platdata(smdk6410_keypad_data);
diff --git a/arch/arm/mach-s3c64xx/setup-usb-phy.c
b/arch/arm/mach-s3c64xx/setup-usb-phy.c
index f6757e0..7a09553 100644
--- a/arch/arm/mach-s3c64xx/setup-usb-phy.c
+++ b/arch/arm/mach-s3c64xx/setup-usb-phy.c
@@ -9,82 +9,3 @@
*
*/
-#include linux/clk.h
-#include linux/delay.h
-#include linux/err.h
-#include linux/io.h
-#include linux/platform_device.h
-#include mach/map.h
-#include mach/regs-sys.h
-#include plat/cpu.h
-#include plat/regs-usb-hsotg-phy.h
-#include plat/usb-phy.h
-
-static int s3c_usb_otgphy_init(struct platform_device *pdev)
-{
- struct clk *xusbxti;
- u32 phyclk;
-
- writel(readl(S3C64XX_OTHERS) | S3C64XX_OTHERS_USBMASK, S3C64XX_OTHERS);
-
- /* set clock frequency for PLL */
- phyclk = readl(S3C_PHYCLK) ~S3C_PHYCLK_CLKSEL_MASK;
-
- xusbxti = clk_get(pdev-dev, xusbxti);
- if (xusbxti !IS_ERR(xusbxti)) {
- switch (clk_get_rate(xusbxti)) {
- case 12 * MHZ:
- phyclk |= S3C_PHYCLK_CLKSEL_12M;
- break;
- case 24 * MHZ:
- phyclk |= S3C_PHYCLK_CLKSEL_24M;
- break;
- default:
- case 48 * MHZ:
- /* default reference clock */
- break;
- }
- clk_put(xusbxti);
- }
-
- /* TODO:
[PATCH v3 4/5] ARM: S3C64XX: Enabling samsung-usbphy driver
Adding platform device for samsung-usbphy driver. Enabling it for
s3c64xx based machines using s3c-hsotg.
Signed-off-by: Praveen Paneri p.pan...@samsung.com
---
arch/arm/mach-s3c64xx/include/mach/map.h |2 +
arch/arm/mach-s3c64xx/mach-crag6410.c|4 +++
arch/arm/mach-s3c64xx/mach-smartq.c |5
arch/arm/mach-s3c64xx/mach-smdk6410.c|4 +++
arch/arm/mach-s3c64xx/setup-usb-phy.c| 14 +++
arch/arm/plat-samsung/devs.c | 33 ++
arch/arm/plat-samsung/include/plat/devs.h|1 +
arch/arm/plat-samsung/include/plat/usb-phy.h |1 +
8 files changed, 64 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-s3c64xx/include/mach/map.h
b/arch/arm/mach-s3c64xx/include/mach/map.h
index 8e2097b..dc482bb 100644
--- a/arch/arm/mach-s3c64xx/include/mach/map.h
+++ b/arch/arm/mach-s3c64xx/include/mach/map.h
@@ -65,6 +65,7 @@
#define S3C64XX_PA_NAND(0x7020)
#define S3C64XX_PA_FB (0x7710)
+#define S3C64XX_PA_USB_HSPHY (0x7C10)
#define S3C64XX_PA_USB_HSOTG (0x7C00)
#define S3C64XX_PA_WATCHDOG(0x7E004000)
#define S3C64XX_PA_RTC (0x7E005000)
@@ -113,6 +114,7 @@
#define S3C_PA_FB S3C64XX_PA_FB
#define S3C_PA_USBHOST S3C64XX_PA_USBHOST
#define S3C_PA_USB_HSOTG S3C64XX_PA_USB_HSOTG
+#define S3C_PA_USB_PHY S3C64XX_PA_USB_HSPHY
#define S3C_PA_RTC S3C64XX_PA_RTC
#define S3C_PA_WDT S3C64XX_PA_WATCHDOG
#define S3C_PA_SPI0S3C64XX_PA_SPI0
diff --git a/arch/arm/mach-s3c64xx/mach-crag6410.c
b/arch/arm/mach-s3c64xx/mach-crag6410.c
index b0f5baf..fa02e2f 100644
--- a/arch/arm/mach-s3c64xx/mach-crag6410.c
+++ b/arch/arm/mach-s3c64xx/mach-crag6410.c
@@ -31,6 +31,7 @@
#include linux/spi/spi.h
#include linux/i2c/pca953x.h
+#include linux/platform_data/samsung-usbphy.h
#include video/platform_lcd.h
@@ -336,6 +337,7 @@ static struct platform_device wallvdd_device = {
};
static struct platform_device *crag6410_devices[] __initdata = {
+ samsung_device_usbphy,
s3c_device_hsmmc0,
s3c_device_hsmmc2,
s3c_device_i2c0,
@@ -765,6 +767,7 @@ static const struct gpio_led_platform_data gpio_leds_pdata
= {
.num_leds = ARRAY_SIZE(gpio_leds),
};
+static struct samsung_usbphy_data crag6410_usbphy_pdata;
static void __init crag6410_machine_init(void)
{
@@ -790,6 +793,7 @@ static void __init crag6410_machine_init(void)
s3c_i2c0_set_platdata(i2c0_pdata);
s3c_i2c1_set_platdata(i2c1_pdata);
s3c_fb_set_platdata(crag6410_lcd_pdata);
+ samsung_usbphy_set_pdata(crag6410_usbphy_pdata);
i2c_register_board_info(0, i2c_devs0, ARRAY_SIZE(i2c_devs0));
i2c_register_board_info(1, i2c_devs1, ARRAY_SIZE(i2c_devs1));
diff --git a/arch/arm/mach-s3c64xx/mach-smartq.c
b/arch/arm/mach-s3c64xx/mach-smartq.c
index 7400da1..e0c4df8 100644
--- a/arch/arm/mach-s3c64xx/mach-smartq.c
+++ b/arch/arm/mach-s3c64xx/mach-smartq.c
@@ -18,6 +18,7 @@
#include linux/serial_core.h
#include linux/spi/spi_gpio.h
#include linux/usb/gpio_vbus.h
+#include linux/platform_data/samsung-usbphy.h
#include asm/mach-types.h
#include asm/mach/map.h
@@ -234,6 +235,7 @@ static struct i2c_board_info smartq_i2c_devs[] __initdata =
{
};
static struct platform_device *smartq_devices[] __initdata = {
+ samsung_device_usbphy,
s3c_device_hsmmc1, /* Init iNAND first, ... */
s3c_device_hsmmc0, /* ... then the external SD card */
s3c_device_hsmmc2,
@@ -380,9 +382,12 @@ void __init smartq_map_io(void)
smartq_lcd_mode_set();
}
+static struct samsung_usbphy_data smartq_usbphy_pdata;
+
void __init smartq_machine_init(void)
{
s3c_i2c0_set_platdata(NULL);
+ samsung_usbphy_set_pdata(smartq_usbphy_pdata);
s3c_hwmon_set_platdata(smartq_hwmon_pdata);
s3c_sdhci1_set_platdata(smartq_internal_hsmmc_pdata);
s3c_sdhci2_set_platdata(smartq_internal_hsmmc_pdata);
diff --git a/arch/arm/mach-s3c64xx/mach-smdk6410.c
b/arch/arm/mach-s3c64xx/mach-smdk6410.c
index cbdc91b..8d40511 100644
--- a/arch/arm/mach-s3c64xx/mach-smdk6410.c
+++ b/arch/arm/mach-s3c64xx/mach-smdk6410.c
@@ -30,6 +30,7 @@
#include linux/regulator/fixed.h
#include linux/regulator/machine.h
#include linux/pwm_backlight.h
+#include linux/platform_data/samsung-usbphy.h
#ifdef CONFIG_SMDK6410_WM1190_EV1
#include linux/mfd/wm8350/core.h
@@ -263,6 +264,7 @@ static struct samsung_keypad_platdata smdk6410_keypad_data
__initdata = {
static struct map_desc smdk6410_iodesc[] = {};
static struct platform_device *smdk6410_devices[] __initdata = {
+ samsung_device_usbphy,
#ifdef CONFIG_SMDK6410_SD_CH0
s3c_device_hsmmc0,
#endif
@@ -626,6 +628,7 @@ static struct platform_pwm_backlight_data smdk6410_bl_data
= {
.pwm_id = 1,
};
+static struct samsung_usbphy_data smdk6410_usbphy_pdata;
static void
[PATCH v3 5/5] ARM: Exynos4210: Enabling samsung-usbphy driver
Adding usbphy node for Exynos4210 along with the platform data.
Signed-off-by: Praveen Paneri p.pan...@samsung.com
---
arch/arm/boot/dts/exynos4210.dtsi |5 +
arch/arm/mach-exynos/include/mach/map.h |1 +
arch/arm/mach-exynos/mach-exynos4-dt.c |8
arch/arm/mach-exynos/setup-usb-phy.c| 13 +
4 files changed, 27 insertions(+), 0 deletions(-)
diff --git a/arch/arm/boot/dts/exynos4210.dtsi
b/arch/arm/boot/dts/exynos4210.dtsi
index 02891fe..e28cf10 100644
--- a/arch/arm/boot/dts/exynos4210.dtsi
+++ b/arch/arm/boot/dts/exynos4210.dtsi
@@ -62,6 +62,11 @@
interrupts = 0 44 0, 0 45 0;
};
+ usbphy@125B {
+ compatible = samsung,exynos4210-usbphy;
+ reg = 0x125B 0x100;
+ };
+
keypad@100A {
compatible = samsung,s5pv210-keypad;
reg = 0x100A 0x100;
diff --git a/arch/arm/mach-exynos/include/mach/map.h
b/arch/arm/mach-exynos/include/mach/map.h
index c72b675..0625c0a 100644
--- a/arch/arm/mach-exynos/include/mach/map.h
+++ b/arch/arm/mach-exynos/include/mach/map.h
@@ -234,6 +234,7 @@
#define S3C_PA_SPI1EXYNOS4_PA_SPI1
#define S3C_PA_SPI2EXYNOS4_PA_SPI2
#define S3C_PA_USB_HSOTG EXYNOS4_PA_HSOTG
+#define S3C_PA_USB_PHY EXYNOS4_PA_HSPHY
#define S5P_PA_EHCIEXYNOS4_PA_EHCI
#define S5P_PA_FIMC0 EXYNOS4_PA_FIMC0
diff --git a/arch/arm/mach-exynos/mach-exynos4-dt.c
b/arch/arm/mach-exynos/mach-exynos4-dt.c
index b2b5d5f..a652db0 100644
--- a/arch/arm/mach-exynos/mach-exynos4-dt.c
+++ b/arch/arm/mach-exynos/mach-exynos4-dt.c
@@ -13,6 +13,7 @@
#include linux/of_platform.h
#include linux/serial_core.h
+#include linux/platform_data/samsung-usbphy.h
#include asm/mach/arch.h
#include asm/hardware/gic.h
@@ -20,9 +21,14 @@
#include plat/cpu.h
#include plat/regs-serial.h
+#include plat/usb-phy.h
#include common.h
+static struct samsung_usbphy_data exynos4_usbphy_pdata = {
+ .pmu_isolation = s5p_usb_phy_pmu_isolation,
+};
+
/*
* The following lookup table is used to override device names when devices
* are registered from device tree. This is temporarily added to enable
@@ -63,6 +69,8 @@ static const struct of_dev_auxdata
exynos4210_auxdata_lookup[] __initconst = {
exynos4210-spi.2, NULL),
OF_DEV_AUXDATA(arm,pl330, EXYNOS4_PA_PDMA0, dma-pl330.0, NULL),
OF_DEV_AUXDATA(arm,pl330, EXYNOS4_PA_PDMA1, dma-pl330.1, NULL),
+ OF_DEV_AUXDATA(samsung,exynos4210-usbphy, EXYNOS4_PA_HSPHY,
+ s3c-usbphy, exynos4_usbphy_pdata),
{},
};
diff --git a/arch/arm/mach-exynos/setup-usb-phy.c
b/arch/arm/mach-exynos/setup-usb-phy.c
index b81cc56..1c62d20 100644
--- a/arch/arm/mach-exynos/setup-usb-phy.c
+++ b/arch/arm/mach-exynos/setup-usb-phy.c
@@ -221,3 +221,16 @@ int s5p_usb_phy_exit(struct platform_device *pdev, int
type)
return -EINVAL;
}
+
+void s5p_usb_phy_pmu_isolation(int on)
+{
+ if (on) {
+ writel(readl(S5P_USBDEVICE_PHY_CONTROL)
+~S5P_USBDEVICE_PHY_ENABLE,
+ S5P_USBDEVICE_PHY_CONTROL);
+ } else {
+ writel(readl(S5P_USBDEVICE_PHY_CONTROL)
+ | S5P_USBDEVICE_PHY_ENABLE,
+ S5P_USBDEVICE_PHY_CONTROL);
+ }
+}
--
1.7.1
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2] can: kvaser_usb: Add support for Kvaser CAN/USB devices
Hi Oliver,
On 08/08/2012 08:14 AM, Olivier Sobrie wrote:
Hi Wolfgang,
On Tue, Aug 07, 2012 at 08:26:38AM +0200, Wolfgang Grandegger wrote:
On 08/06/2012 07:21 AM, Olivier Sobrie wrote:
This driver provides support for several Kvaser CAN/USB devices.
Such kind of devices supports up to three can network interfaces.
s/can/CAN/
It has been tested with a Kvaser USB Leaf Light (one network interface)
connected to a pch_can interface.
The firmware version of the Kvaser device was 2.5.205.
List of Kvaser devices supported by the driver:
- Kvaser Leaf prototype (P010v2 and v3)
- Kvaser Leaf Light (P010v3)
- Kvaser Leaf Professional HS
- Kvaser Leaf SemiPro HS
- Kvaser Leaf Professional LS
- Kvaser Leaf Professional SWC
- Kvaser Leaf Professional LIN
- Kvaser Leaf SemiPro LS
- Kvaser Leaf SemiPro SWC
- Kvaser Memorator II, Prototype
- Kvaser Memorator II HS/HS
- Kvaser USBcan Professional HS/HS
- Kvaser Leaf Light GI
- Kvaser Leaf Professional HS (OBD-II connector)
- Kvaser Memorator Professional HS/LS
- Kvaser Leaf Light China
- Kvaser BlackBird SemiPro
- Kvaser OEM Mercury
- Kvaser OEM Leaf
- Kvaser USBcan R
Impressive list! What CAN controllers are used inside the devices? SJA1000?
I took this list from the Kvaser driver. However I only have a Kvaser
Leaf Light device thus I'm not sure it will work with other ones.
If you prefer I can only let Kvaser Leaf Light instead of the full list.
In my device it looks to be a Renesas M16C controller.
OK. Checking the manual, if available, could help to understand how the
firmware handles bus errors and state changes.
Signed-off-by: Olivier Sobrie oliv...@sobrie.be
---
Changes since v1:
- added copyrights
- kvaser_usb.h merged into kvaser.c
- added kvaser_usb_get_endpoints to find eindpoints instead of
hardcoding their address
- some cleanup and comestic changes
- fixed issues with errors handling
- fixed restart-ms == 0 case
- removed do_get_berr_counter method since the hardware doens't return
good values for txerr and rxerr.
If someone in the linux-usb mailing can review it, it would be nice.
Concerning the errors, it behaves like that now:
1) Short-circuit CAN-H and CAN-L and restart-ms = 0
t0: short-circuit + 'cansend can1 123#112233'
can1 208C [8] 00 0C 90 00 00 00 00 00 ERRORFRAME
controller-problem{rx-error-warning,tx-error-warning}
protocol-violation{{tx-recessive-bit-error,error-on-tx}{}}
bus-error
can1 208C [8] 00 30 90 00 00 00 00 00 ERRORFRAME
controller-problem{rx-error-passive,tx-error-passive}
protocol-violation{{tx-recessive-bit-error,error-on-tx}{}}
bus-error
can1 20C8 [8] 00 00 90 00 00 00 00 00 ERRORFRAME
protocol-violation{{tx-recessive-bit-error,error-on-tx}{}}
bus-off
bus-error
t1: remove short-circuit + 'ip link set can1 type can restart'
can1 2100 [8] 00 00 00 00 00 00 00 00 ERRORFRAME
restarted-after-bus-off
can1 2004 [8] 00 0C 00 00 00 00 00 00 ERRORFRAME
controller-problem{rx-error-warning,tx-error-warning}
Why do we get the last error message? Maybe the firmware does it that
way (going down passive-warning-active).
It goes in that order: warning - passive - bus off - warning
- passive - ...
Just for curiosity? You don't see back to error active?
2) Short-circuit CAN-H and CAN-L and restart-ms = 100
t0: short-circuit + cansend can1 123#112233
can1 208C [8] 00 0C 90 00 00 00 00 00 ERRORFRAME
controller-problem{rx-error-warning,tx-error-warning}
protocol-violation{{tx-recessive-bit-error,error-on-tx}{}}
bus-error
can1 208C [8] 00 30 90 00 00 00 00 00 ERRORFRAME
controller-problem{rx-error-passive,tx-error-passive}
protocol-violation{{tx-recessive-bit-error,error-on-tx}{}}
bus-error
can1 20C8 [8] 00 00 90 00 00 00 00 00 ERRORFRAME
protocol-violation{{tx-recessive-bit-error,error-on-tx}{}}
bus-off
bus-error
can1 218C [8] 00 0C 90 00 00 00 00 00 ERRORFRAME
controller-problem{rx-error-warning,tx-error-warning}
protocol-violation{{tx-recessive-bit-error,error-on-tx}{}}
bus-error
restarted-after-bus-off
can1 208C [8] 00 0C 90 00 00 00 00 00 ERRORFRAME
controller-problem{rx-error-warning,tx-error-warning}
protocol-violation{{tx-recessive-bit-error,error-on-tx}{}}
bus-error
can1 208C [8] 00 30 90 00 00 00 00 00 ERRORFRAME
controller-problem{rx-error-passive,tx-error-passive}
protocol-violation{{tx-recessive-bit-error,error-on-tx}{}}
bus-error
can1 20C8 [8] 00 00 90 00 00 00 00 00 ERRORFRAME
protocol-violation{{tx-recessive-bit-error,error-on-tx}{}}
bus-off
bus-error
...
can1 218C [8] 00 0C 90 00 00 00 00 00 ERRORFRAME
controller-problem{rx-error-warning,tx-error-warning}
[PATCH 2/2] usb_gadget: Use GFP_ATOMIC in dma_pool_alloc().
Calling memory allocation function from the context of interrupt: request_irq(udc-irq, mv_udc_irq, IRQF_SHARED, driver_name, udc); Function mv_udc_irq(..) calls: irq_process_tr_complete(..) that calls: handle_setup_packet(..) that calls: ch9setaddress(..) that calls: udc_prime_status(..) that calls: req_to_dtd(..) that calls: build_dtd(..) that calls: dma_pool_alloc(udc-dtd_pool, GFP_KERNEL, dma). In the case of GFP_KERNEL flag, function execution can be preempted, because a greater number of operations to find and allocate memory blocks is executed. The patch change GFP_KERNEL flag to GFP_ATOMIC. Found by Linux Driver Verification project (linuxtesting.org). Signed-off-by: Vladimir Gratinskiy gratins...@ispras.ru --- drivers/usb/gadget/mv_udc_core.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/usb/gadget/mv_udc_core.c b/drivers/usb/gadget/mv_udc_core.c index 75db2c3..ba91f7c 100644 --- a/drivers/usb/gadget/mv_udc_core.c +++ b/drivers/usb/gadget/mv_udc_core.c @@ -375,7 +375,7 @@ static struct mv_dtd *build_dtd(struct mv_req *req, unsigned *length, * Be careful that no _GFP_HIGHMEM is set, * or we can not use dma_to_virt */ - dtd = dma_pool_alloc(udc-dtd_pool, GFP_KERNEL, dma); + dtd = dma_pool_alloc(udc-dtd_pool, GFP_ATOMIC, dma); if (dtd == NULL) return dtd; -- 1.7.9.5 -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [rtc-linux] [PATCH 8/8] ARM: vt8500: gpio: Devicetree support for arch-vt8500
On Wed, Aug 8, 2012 at 3:39 AM, Tony Prisk li...@prisktech.co.nz wrote:
Converted the existing arch-vt8500 gpio to a platform_device.
Added support for WM8505 and WM8650 GPIO controllers.
(...)
+++ b/drivers/gpio/gpio-vt8500.c
This driver looks very one-bit-per-gpio typed. Are you sure you cannot
just reuse drivers/gpio/gpio-generic.c? Make a compelling case please...
+struct vt8500_gpio_bank_regs {
+ int en;
+ int dir;
+ int data_out;
+ int data_in;
Why are all these members int? They should be u8 from reading your code.
+ int ngpio;
+};
+static struct vt8500_gpio_data vt8500_data = {
+ .num_banks = 7,
+ .banks = {
+ VT8500_BANK(0x00, 0x20, 0x40, 0x60, 26),
+ VT8500_BANK(0x04, 0x24, 0x44, 0x64, 28),
+ VT8500_BANK(0x08, 0x28, 0x48, 0x68, 31),
+ VT8500_BANK(0x0C, 0x2C, 0x4C, 0x6C, 19),
+ VT8500_BANK(0x10, 0x30, 0x50, 0x70, 19),
+ VT8500_BANK(0x14, 0x34, 0x54, 0x74, 23),
+ VT8500_BANK(-1, 0x3C, 0x5C, 0x7C, 9),/* external gpio */
What on earth are all those magic numbers?
I *guess* they're enabling some default GPIO settings etc.
But it really needs better structure, #defines for each one or
atleast include linux/bitops.h and say:
= BIT(4) | /* Enable GPIO pin 5 on this bank */
BIT(5); /* Enable GPIO pin 6 on this bank */
However I suspect this is board specific and should
be taken from device tree. Please elaborate on this...
Ditto for the different instances.
(...)
+ unsigned val;
Looks like all of these should be u8.
+ val = readl(vt8500_chip-base + vt8500_chip-regs-en +
+ vt8500_chip-regoff);
val = (u8) readl(...);
usw
+ val |= (1 offset);
Use linux/bitops.h
val |= BIT(offset);
Apart from these remarks it's looking good...
Yours,
Linus Walleij
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [rtc-linux] [PATCH 8/8] ARM: vt8500: gpio: Devicetree support for arch-vt8500
On Wednesday 08 August 2012, Linus Walleij wrote:
On Wed, Aug 8, 2012 at 3:39 AM, Tony Prisk li...@prisktech.co.nz wrote:
Converted the existing arch-vt8500 gpio to a platform_device.
Added support for WM8505 and WM8650 GPIO controllers.
(...)
+++ b/drivers/gpio/gpio-vt8500.c
This driver looks very one-bit-per-gpio typed. Are you sure you cannot
just reuse drivers/gpio/gpio-generic.c? Make a compelling case please...
+struct vt8500_gpio_bank_regs {
+ int en;
+ int dir;
+ int data_out;
+ int data_in;
Why are all these members int? They should be u8 from reading your code.
+ int ngpio;
+};
Not necessarily 8 bit, but definitely unsigned.
+static struct vt8500_gpio_data vt8500_data = {
+ .num_banks = 7,
+ .banks = {
+ VT8500_BANK(0x00, 0x20, 0x40, 0x60, 26),
+ VT8500_BANK(0x04, 0x24, 0x44, 0x64, 28),
+ VT8500_BANK(0x08, 0x28, 0x48, 0x68, 31),
+ VT8500_BANK(0x0C, 0x2C, 0x4C, 0x6C, 19),
+ VT8500_BANK(0x10, 0x30, 0x50, 0x70, 19),
+ VT8500_BANK(0x14, 0x34, 0x54, 0x74, 23),
+ VT8500_BANK(-1, 0x3C, 0x5C, 0x7C, 9),/* external gpio */
What on earth are all those magic numbers?
I *guess* they're enabling some default GPIO settings etc.
No, they are the register offsets you quoted above, per bank. There
is no easy way to abstract these, and I suggested putting the
values into the source code rather than describing each bank
separately in the .dtsi file.
My feeling however is that the vt8500_chip-regoff is wrong, which
would mean only the first bank works. The code adds the same offsets
per bank once more that it sets in this bank table.
Arnd
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/1] USB:support the new interfaces of Huawei Data Card devices in option driver
From: fangxiaozhi huana...@huawei.com 1. This patch is based on the kernel of 3.6-rc1 2. In this patch, we add new declarations into option.c to support the new interfaces of Huawei Data Card devices. And at the same time, remove the redundant declarations from option.c. Signed-off-by: fangxiaozhi huana...@huawei.com --- --- linux-3.6-rc1/drivers/usb/serial/option.c 2012-08-03 07:38:10.0 +0800 +++ test/linux-3.6-rc1/drivers/usb/serial/option.c 2012-08-08 11:32:15.0 +0800 @@ -80,85 +80,9 @@ #define OPTION_PRODUCT_GTM380_MODEM0x7201 #define HUAWEI_VENDOR_ID 0x12D1 -#define HUAWEI_PRODUCT_E6000x1001 -#define HUAWEI_PRODUCT_E2200x1003 -#define HUAWEI_PRODUCT_E220BIS 0x1004 -#define HUAWEI_PRODUCT_E1401 0x1401 -#define HUAWEI_PRODUCT_E1402 0x1402 -#define HUAWEI_PRODUCT_E1403 0x1403 -#define HUAWEI_PRODUCT_E1404 0x1404 -#define HUAWEI_PRODUCT_E1405 0x1405 -#define HUAWEI_PRODUCT_E1406 0x1406 -#define HUAWEI_PRODUCT_E1407 0x1407 -#define HUAWEI_PRODUCT_E1408 0x1408 -#define HUAWEI_PRODUCT_E1409 0x1409 -#define HUAWEI_PRODUCT_E140A 0x140A -#define HUAWEI_PRODUCT_E140B 0x140B -#define HUAWEI_PRODUCT_E140C 0x140C -#define HUAWEI_PRODUCT_E140D 0x140D -#define HUAWEI_PRODUCT_E140E 0x140E -#define HUAWEI_PRODUCT_E140F 0x140F -#define HUAWEI_PRODUCT_E1410 0x1410 -#define HUAWEI_PRODUCT_E1411 0x1411 -#define HUAWEI_PRODUCT_E1412 0x1412 -#define HUAWEI_PRODUCT_E1413 0x1413 -#define HUAWEI_PRODUCT_E1414 0x1414 -#define HUAWEI_PRODUCT_E1415 0x1415 -#define HUAWEI_PRODUCT_E1416 0x1416 -#define HUAWEI_PRODUCT_E1417 0x1417 -#define HUAWEI_PRODUCT_E1418 0x1418 -#define HUAWEI_PRODUCT_E1419 0x1419 -#define HUAWEI_PRODUCT_E141A 0x141A -#define HUAWEI_PRODUCT_E141B 0x141B -#define HUAWEI_PRODUCT_E141C 0x141C -#define HUAWEI_PRODUCT_E141D 0x141D -#define HUAWEI_PRODUCT_E141E 0x141E -#define HUAWEI_PRODUCT_E141F 0x141F -#define HUAWEI_PRODUCT_E1420 0x1420 -#define HUAWEI_PRODUCT_E1421 0x1421 -#define HUAWEI_PRODUCT_E1422 0x1422 -#define HUAWEI_PRODUCT_E1423 0x1423 -#define HUAWEI_PRODUCT_E1424 0x1424 -#define HUAWEI_PRODUCT_E1425 0x1425 -#define HUAWEI_PRODUCT_E1426 0x1426 -#define HUAWEI_PRODUCT_E1427 0x1427 -#define HUAWEI_PRODUCT_E1428 0x1428 -#define HUAWEI_PRODUCT_E1429 0x1429 -#define HUAWEI_PRODUCT_E142A 0x142A -#define HUAWEI_PRODUCT_E142B 0x142B -#define HUAWEI_PRODUCT_E142C 0x142C -#define HUAWEI_PRODUCT_E142D 0x142D -#define HUAWEI_PRODUCT_E142E 0x142E -#define HUAWEI_PRODUCT_E142F 0x142F -#define HUAWEI_PRODUCT_E1430 0x1430 -#define HUAWEI_PRODUCT_E1431 0x1431 -#define HUAWEI_PRODUCT_E1432 0x1432 -#define HUAWEI_PRODUCT_E1433 0x1433 -#define HUAWEI_PRODUCT_E1434 0x1434 -#define HUAWEI_PRODUCT_E1435 0x1435 -#define HUAWEI_PRODUCT_E1436 0x1436 -#define HUAWEI_PRODUCT_E1437 0x1437 -#define HUAWEI_PRODUCT_E1438 0x1438 -#define HUAWEI_PRODUCT_E1439 0x1439 -#define HUAWEI_PRODUCT_E143A 0x143A -#define HUAWEI_PRODUCT_E143B 0x143B -#define HUAWEI_PRODUCT_E143C 0x143C -#define HUAWEI_PRODUCT_E143D 0x143D -#define HUAWEI_PRODUCT_E143E 0x143E -#define HUAWEI_PRODUCT_E143F 0x143F #define HUAWEI_PRODUCT_K4505 0x1464 #define HUAWEI_PRODUCT_K3765 0x1465 -#define HUAWEI_PRODUCT_E14AC 0x14AC -#define HUAWEI_PRODUCT_K3806 0x14AE #define HUAWEI_PRODUCT_K4605 0x14C6 -#define HUAWEI_PRODUCT_K5005 0x14C8 -#define HUAWEI_PRODUCT_K3770 0x14C9 -#define HUAWEI_PRODUCT_K3771 0x14CA -#define HUAWEI_PRODUCT_K4510 0x14CB -#define HUAWEI_PRODUCT_K4511 0x14CC -#define HUAWEI_PRODUCT_ETS1220 0x1803 -#define HUAWEI_PRODUCT_E3530x1506 -#define HUAWEI_PRODUCT_E173S
[PATCH] usb: gadget: u_ether: fix kworker 100% CPU issue with still used interfaces in eth_stop
From: Michael Grzeschik m.grzesc...@pengutronix.de
This patch fixes an issue introduced by patch:
72c973d usb: gadget: add usb_endpoint_descriptor to struct usb_ep
Without this patch we see a kworker taking 100% CPU, after this sequence:
- Connect gadget to a windows host
- load g_ether
- ifconfig up ip; ifconfig down; ifconfig up
- ping windows host
The ifconfig down results in calling eth_stop(), which will call
usb_ep_disable() and, if the carrier is still ok, usb_ep_enable():
usb_ep_disable(link-in_ep);
usb_ep_disable(link-out_ep);
if (netif_carrier_ok(net)) {
usb_ep_enable(link-in_ep);
usb_ep_enable(link-out_ep);
}
The ep should stay enabled, but will not, as ep_disable set the desc
pointer to NULL, therefore the subsequent ep_enable will fail. This leads
to permanent rescheduling of the eth_work() worker as usb_ep_queue()
(called by the worker) will fail due to the unconfigured endpoint.
We fix this issue by saving the ep descriptors and re-assign them before
usb_ep_enable().
Cc: Tatyana Brokhman tlin...@codeaurora.org
Signed-off-by: Michael Grzeschik m.grzesc...@pengutronix.de
Signed-off-by: Marc Kleine-Budde m...@pengutronix.de
---
Hello,
this patch applies to v3.6-rc1, would be nice if this goes into v3.6,
probably a stable candidate, too.
regards, Marc
drivers/usb/gadget/u_ether.c |6 ++
1 file changed, 6 insertions(+)
diff --git a/drivers/usb/gadget/u_ether.c b/drivers/usb/gadget/u_ether.c
index 90e82e2..0e52309 100644
--- a/drivers/usb/gadget/u_ether.c
+++ b/drivers/usb/gadget/u_ether.c
@@ -669,6 +669,8 @@ static int eth_stop(struct net_device *net)
spin_lock_irqsave(dev-lock, flags);
if (dev-port_usb) {
struct gether *link = dev-port_usb;
+ const struct usb_endpoint_descriptor *in;
+ const struct usb_endpoint_descriptor *out;
if (link-close)
link-close(link);
@@ -682,10 +684,14 @@ static int eth_stop(struct net_device *net)
* their own pace; the network stack can handle old packets.
* For the moment we leave this here, since it works.
*/
+ in = link-in_ep-desc;
+ out = link-out_ep-desc;
usb_ep_disable(link-in_ep);
usb_ep_disable(link-out_ep);
if (netif_carrier_ok(net)) {
DBG(dev, host still using in/out endpoints\n);
+ link-in_ep-desc = in;
+ link-out_ep-desc = out;
usb_ep_enable(link-in_ep);
usb_ep_enable(link-out_ep);
}
--
1.7.10.4
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH V2 1/2] usb: gadget/uvc: Port UVC webcam gadget to use videobuf2 framework
Hi Bhupesh,
On Tuesday 07 August 2012 23:07:56 Bhupesh SHARMA wrote:
On Tuesday, August 07, 2012 8:23 PM Laurent Pinchart wrote:
On Tuesday 31 July 2012 06:24:51 Bhupesh Sharma wrote:
This patch reworks the videobuffer management logic present in the
UVC webcam gadget and ports it to use the more apt videobuf2 framework
for video buffer management.
To support routing video data captured from a real V4L2 video capture
device with a zero copy operation on videobuffers (as they pass
from the V4L2 domain to UVC domain via a user-space application), we
need to support USER_PTR IO method at the UVC gadget side.
So the V4L2 capture device driver can still continue to use MMAP IO
method and now the user-space application can just pass a pointer to
the video buffers being dequeued from the V4L2 device side while
queueing them at the UVC gadget end. This ensures that we have a zero-
copy design as the videobuffers pass from the V4L2 capture device to
the UVC gadget.
Note that there will still be a need to apply UVC specific payload
headers on top of each UVC payload data, which will still require a
copy operation to be performed in the 'encode' routines of the UVC
gadget.
This patch also addresses two issues found out while porting the UVC
gadget to videobuf2 framework:
- In case the usb requests queued by the gadget get completed
with a status of -ESHUTDOWN (disconnected from host), the
queue of videobuf2 should be cancelled to ensure that the
application space daemon is not left in a state waiting for
a vb2 to be successfully absorbed at the USB side.
- In case the underlying UDC has already returned -ESHUTDOWN
as status of a queued request, it means that the video
streaming endpoint is going to be disabled and hence the
underlying UDC will giveback all queued requests with a status
of -ESHUTDOWN. In such a case, the requests are not longer
queued at the UDC end and it doesn't make sense to dequeue
them again in uvc_video_enable(0).
[snip]
diff --git a/drivers/usb/gadget/uvc_queue.c
b/drivers/usb/gadget/uvc_queue.c
index 104ae9c..bf6621b 100644
--- a/drivers/usb/gadget/uvc_queue.c
+++ b/drivers/usb/gadget/uvc_queue.c
[snip]
@@ -516,26 +276,34 @@ static void uvc_queue_cancel(struct
uvc_video_queue *queue, int disconnect) */
static int uvc_queue_enable(struct uvc_video_queue *queue, int
enable)
{
- unsigned int i;
+ unsigned long flags;
int ret = 0;
mutex_lock(queue-mutex);
if (enable) {
- if (uvc_queue_streaming(queue)) {
- ret = -EBUSY;
+ ret = vb2_streamon(queue-queue, queue-queue.type);
+ if (ret 0)
goto done;
- }
- queue-sequence = 0;
- queue-flags |= UVC_QUEUE_STREAMING;
+
queue-buf_used = 0;
} else {
- uvc_queue_cancel(queue, 0);
- INIT_LIST_HEAD(queue-mainqueue);
+ ret = vb2_streamoff(queue-queue, queue-queue.type);
+ if (ret 0)
+ goto done;
+
+ spin_lock_irqsave(queue-irqlock, flags);
+
+ INIT_LIST_HEAD(queue-irqqueue);
- for (i = 0; i queue-count; ++i)
- queue-buffer[i].state = UVC_BUF_STATE_IDLE;
+ /*
+ * as the uvc queue is being disabled, clear any
+ * DISCONNECTED flag which was set earlier, so that the
+ * next qbuf from userspace does not fail with ENODEV.
+ */
Please start the comment with a capital letter, spell UVC in capital,
and fill the space up to 80 columns.
Sure.
+ if (queue-flags UVC_QUEUE_DISCONNECTED)
+ queue-flags = ~UVC_QUEUE_DISCONNECTED;
You can clear the flag unconditionally. What about moving this to the
enable branch of the if ?
Ok for the first sentence of the comment.
For the 2nd part, we have to do it here itself as if the application
accessing this UVC webcam is closed and then started again (sending a
set-alt(0) and set-alt(1)), we will not be able to queue any buffers on the
UVC gadget in the 2nd run.
This is because we had set the UVC_QUEUE_DISCONNECTED, when the underlying
UDC had returned a USB request with completion status -104 (ESHUTDOWN).
Any attempt to queue the buffers without clearing this flag will return
-ENODEV error. And as uvc_queue_enable(1) is called when we STREAMON ioctl
is called by the user-space, any qbuf calls before that will fail.
Right, I understand the problem, but I've got one issue with this.
The purpose of the UVC_QUEUE_DISCONNECTED flag is to prevent buffers from
being queued when the device has been disconnected, as those buffers would
never be marked as complete (no URB in flight, so no URB complete callback)
and would
[PATCH] wusb: Fix potential memory leak in wusb_dev_sec_add()
Do not leak memory by updating pointer with potentially NULL realloc return
value.
Found by Linux Driver Verification project (linuxtesting.org).
Signed-off-by: Alexey Khoroshilov khoroshi...@ispras.ru
---
drivers/usb/wusbcore/security.c |7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/drivers/usb/wusbcore/security.c b/drivers/usb/wusbcore/security.c
index fa810a8..dd88441 100644
--- a/drivers/usb/wusbcore/security.c
+++ b/drivers/usb/wusbcore/security.c
@@ -202,7 +202,7 @@ int wusb_dev_sec_add(struct wusbhc *wusbhc,
{
int result, bytes, secd_size;
struct device *dev = usb_dev-dev;
- struct usb_security_descriptor *secd;
+ struct usb_security_descriptor *secd, *new_secd;
const struct usb_encryption_descriptor *etd, *ccm1_etd = NULL;
const void *itr, *top;
char buf[64];
@@ -221,11 +221,12 @@ int wusb_dev_sec_add(struct wusbhc *wusbhc,
goto out;
}
secd_size = le16_to_cpu(secd-wTotalLength);
- secd = krealloc(secd, secd_size, GFP_KERNEL);
- if (secd == NULL) {
+ new_secd = krealloc(secd, secd_size, GFP_KERNEL);
+ if (new_secd == NULL) {
dev_err(dev, Can't allocate space for security descriptors\n);
goto out;
}
+ secd = new_secd;
result = usb_get_descriptor(usb_dev, USB_DT_SECURITY,
0, secd, secd_size);
if (result secd_size) {
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
xhci inc_deq question
hi all:
when I study inc_deq in xhci-ring.c, why we need to announce and
assigned value to addr
it seems useless.
static void inc_deq(struct xhci_hcd *xhci, struct xhci_ring *ring)
{
unsigned long long addr;
..
..
addr = (unsigned long long) xhci_trb_virt_to_dma(ring-deq_seg,
ring-dequeue);
}
--
Regards,
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2] can: kvaser_usb: Add support for Kvaser CAN/USB devices
On Wed, Aug 08, 2012 at 10:25:35AM +0200, Wolfgang Grandegger wrote:
Hi Oliver,
On 08/08/2012 08:14 AM, Olivier Sobrie wrote:
Hi Wolfgang,
On Tue, Aug 07, 2012 at 08:26:38AM +0200, Wolfgang Grandegger wrote:
On 08/06/2012 07:21 AM, Olivier Sobrie wrote:
This driver provides support for several Kvaser CAN/USB devices.
Such kind of devices supports up to three can network interfaces.
s/can/CAN/
It has been tested with a Kvaser USB Leaf Light (one network interface)
connected to a pch_can interface.
The firmware version of the Kvaser device was 2.5.205.
List of Kvaser devices supported by the driver:
- Kvaser Leaf prototype (P010v2 and v3)
- Kvaser Leaf Light (P010v3)
- Kvaser Leaf Professional HS
- Kvaser Leaf SemiPro HS
- Kvaser Leaf Professional LS
- Kvaser Leaf Professional SWC
- Kvaser Leaf Professional LIN
- Kvaser Leaf SemiPro LS
- Kvaser Leaf SemiPro SWC
- Kvaser Memorator II, Prototype
- Kvaser Memorator II HS/HS
- Kvaser USBcan Professional HS/HS
- Kvaser Leaf Light GI
- Kvaser Leaf Professional HS (OBD-II connector)
- Kvaser Memorator Professional HS/LS
- Kvaser Leaf Light China
- Kvaser BlackBird SemiPro
- Kvaser OEM Mercury
- Kvaser OEM Leaf
- Kvaser USBcan R
Impressive list! What CAN controllers are used inside the devices? SJA1000?
I took this list from the Kvaser driver. However I only have a Kvaser
Leaf Light device thus I'm not sure it will work with other ones.
If you prefer I can only let Kvaser Leaf Light instead of the full list.
In my device it looks to be a Renesas M16C controller.
OK. Checking the manual, if available, could help to understand how the
firmware handles bus errors and state changes.
Ok I'll try to find it.
Signed-off-by: Olivier Sobrie oliv...@sobrie.be
---
Changes since v1:
- added copyrights
- kvaser_usb.h merged into kvaser.c
- added kvaser_usb_get_endpoints to find eindpoints instead of
hardcoding their address
- some cleanup and comestic changes
- fixed issues with errors handling
- fixed restart-ms == 0 case
- removed do_get_berr_counter method since the hardware doens't return
good values for txerr and rxerr.
If someone in the linux-usb mailing can review it, it would be nice.
Concerning the errors, it behaves like that now:
1) Short-circuit CAN-H and CAN-L and restart-ms = 0
t0: short-circuit + 'cansend can1 123#112233'
can1 208C [8] 00 0C 90 00 00 00 00 00 ERRORFRAME
controller-problem{rx-error-warning,tx-error-warning}
protocol-violation{{tx-recessive-bit-error,error-on-tx}{}}
bus-error
can1 208C [8] 00 30 90 00 00 00 00 00 ERRORFRAME
controller-problem{rx-error-passive,tx-error-passive}
protocol-violation{{tx-recessive-bit-error,error-on-tx}{}}
bus-error
can1 20C8 [8] 00 00 90 00 00 00 00 00 ERRORFRAME
protocol-violation{{tx-recessive-bit-error,error-on-tx}{}}
bus-off
bus-error
t1: remove short-circuit + 'ip link set can1 type can restart'
can1 2100 [8] 00 00 00 00 00 00 00 00 ERRORFRAME
restarted-after-bus-off
can1 2004 [8] 00 0C 00 00 00 00 00 00 ERRORFRAME
controller-problem{rx-error-warning,tx-error-warning}
Why do we get the last error message? Maybe the firmware does it that
way (going down passive-warning-active).
It goes in that order: warning - passive - bus off - warning
- passive - ...
Just for curiosity? You don't see back to error active?
No but that's maybe because of my misunderstanding of the
M16C_STATE_BUS_ERROR flag.
What I see is:
t1: M16C_STATE_BUS_ERROR
t2: M16C_STATE_BUS_ERROR | M16C_STATE_BUS_PASSIVE
t3: M16C_STATE_BUS_ERROR | M16C_STATE_BUS_OFF
and then again
t4: M16C_STATE_BUS_ERROR
t2: M16C_STATE_BUS_ERROR | M16C_STATE_BUS_PASSIVE
t3: M16C_STATE_BUS_ERROR | M16C_STATE_BUS_OFF
Thus as you suggested below, the flag M16C_STATE_BUS_ERROR might not mean
CAN_STATE_ERROR_WARNING...
2) Short-circuit CAN-H and CAN-L and restart-ms = 100
t0: short-circuit + cansend can1 123#112233
can1 208C [8] 00 0C 90 00 00 00 00 00 ERRORFRAME
controller-problem{rx-error-warning,tx-error-warning}
protocol-violation{{tx-recessive-bit-error,error-on-tx}{}}
bus-error
can1 208C [8] 00 30 90 00 00 00 00 00 ERRORFRAME
controller-problem{rx-error-passive,tx-error-passive}
protocol-violation{{tx-recessive-bit-error,error-on-tx}{}}
bus-error
can1 20C8 [8] 00 00 90 00 00 00 00 00 ERRORFRAME
protocol-violation{{tx-recessive-bit-error,error-on-tx}{}}
bus-off
bus-error
can1 218C [8] 00 0C 90 00 00 00 00 00 ERRORFRAME
controller-problem{rx-error-warning,tx-error-warning}
protocol-violation{{tx-recessive-bit-error,error-on-tx}{}}
bus-error
restarted-after-bus-off
can1 208C [8] 00 0C 90 00 00 00 00 00 ERRORFRAME
Remote wakeup functionality using gadgetfs.
Hi, I am trying enable remote wakeup functionality using gadgetfs. But initialization fails with invalid argument. I have read from one of the threads in this forum that confirms this behavior. Now, my doubt is how to achieve remote wakeup using gadgetfs? Is there any work around for this? .bmAttributes = USB_CONFIG_ATT_ONE| USB_CONFIG_ATT_WAKEUP| USB_CONFIG_ATT_SELFPOWER, Thanks for your reply in advance. Best regards, Dineshkumar M. -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Remote wakeup functionality using gadgetfs.
On Wed, 8 Aug 2012, Dineshkumar wrote: Hi, I am trying enable remote wakeup functionality using gadgetfs. But initialization fails with invalid argument. I have read from one of the threads in this forum that confirms this behavior. Now, my doubt is how to achieve remote wakeup using gadgetfs? Is there any work around for this? .bmAttributes = USB_CONFIG_ATT_ONE| USB_CONFIG_ATT_WAKEUP| USB_CONFIG_ATT_SELFPOWER, Thanks for your reply in advance. Currently gadgetfs does not support remote wakeup. Maybe you can figure out a way to add support. Alan Stern -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Remote wakeup functionality using gadgetfs.
Thanks for the confirmation. I will try and update you. Dineshkumar -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2] can: kvaser_usb: Add support for Kvaser CAN/USB devices
On 08/08/2012 03:30 PM, Olivier Sobrie wrote:
On Wed, Aug 08, 2012 at 10:25:35AM +0200, Wolfgang Grandegger wrote:
Hi Oliver,
On 08/08/2012 08:14 AM, Olivier Sobrie wrote:
Hi Wolfgang,
On Tue, Aug 07, 2012 at 08:26:38AM +0200, Wolfgang Grandegger wrote:
On 08/06/2012 07:21 AM, Olivier Sobrie wrote:
This driver provides support for several Kvaser CAN/USB devices.
Such kind of devices supports up to three can network interfaces.
s/can/CAN/
It has been tested with a Kvaser USB Leaf Light (one network interface)
connected to a pch_can interface.
The firmware version of the Kvaser device was 2.5.205.
List of Kvaser devices supported by the driver:
- Kvaser Leaf prototype (P010v2 and v3)
- Kvaser Leaf Light (P010v3)
- Kvaser Leaf Professional HS
- Kvaser Leaf SemiPro HS
- Kvaser Leaf Professional LS
- Kvaser Leaf Professional SWC
- Kvaser Leaf Professional LIN
- Kvaser Leaf SemiPro LS
- Kvaser Leaf SemiPro SWC
- Kvaser Memorator II, Prototype
- Kvaser Memorator II HS/HS
- Kvaser USBcan Professional HS/HS
- Kvaser Leaf Light GI
- Kvaser Leaf Professional HS (OBD-II connector)
- Kvaser Memorator Professional HS/LS
- Kvaser Leaf Light China
- Kvaser BlackBird SemiPro
- Kvaser OEM Mercury
- Kvaser OEM Leaf
- Kvaser USBcan R
Impressive list! What CAN controllers are used inside the devices? SJA1000?
I took this list from the Kvaser driver. However I only have a Kvaser
Leaf Light device thus I'm not sure it will work with other ones.
If you prefer I can only let Kvaser Leaf Light instead of the full list.
In my device it looks to be a Renesas M16C controller.
OK. Checking the manual, if available, could help to understand how the
firmware handles bus errors and state changes.
Ok I'll try to find it.
Signed-off-by: Olivier Sobrie oliv...@sobrie.be
---
Changes since v1:
- added copyrights
- kvaser_usb.h merged into kvaser.c
- added kvaser_usb_get_endpoints to find eindpoints instead of
hardcoding their address
- some cleanup and comestic changes
- fixed issues with errors handling
- fixed restart-ms == 0 case
- removed do_get_berr_counter method since the hardware doens't return
good values for txerr and rxerr.
If someone in the linux-usb mailing can review it, it would be nice.
Concerning the errors, it behaves like that now:
1) Short-circuit CAN-H and CAN-L and restart-ms = 0
t0: short-circuit + 'cansend can1 123#112233'
can1 208C [8] 00 0C 90 00 00 00 00 00 ERRORFRAME
controller-problem{rx-error-warning,tx-error-warning}
protocol-violation{{tx-recessive-bit-error,error-on-tx}{}}
bus-error
can1 208C [8] 00 30 90 00 00 00 00 00 ERRORFRAME
controller-problem{rx-error-passive,tx-error-passive}
protocol-violation{{tx-recessive-bit-error,error-on-tx}{}}
bus-error
can1 20C8 [8] 00 00 90 00 00 00 00 00 ERRORFRAME
protocol-violation{{tx-recessive-bit-error,error-on-tx}{}}
bus-off
bus-error
t1: remove short-circuit + 'ip link set can1 type can restart'
can1 2100 [8] 00 00 00 00 00 00 00 00 ERRORFRAME
restarted-after-bus-off
can1 2004 [8] 00 0C 00 00 00 00 00 00 ERRORFRAME
controller-problem{rx-error-warning,tx-error-warning}
Why do we get the last error message? Maybe the firmware does it that
way (going down passive-warning-active).
It goes in that order: warning - passive - bus off - warning
- passive - ...
Just for curiosity? You don't see back to error active?
No but that's maybe because of my misunderstanding of the
M16C_STATE_BUS_ERROR flag.
What I see is:
t1: M16C_STATE_BUS_ERROR
t2: M16C_STATE_BUS_ERROR | M16C_STATE_BUS_PASSIVE
t3: M16C_STATE_BUS_ERROR | M16C_STATE_BUS_OFF
and then again
t4: M16C_STATE_BUS_ERROR
t2: M16C_STATE_BUS_ERROR | M16C_STATE_BUS_PASSIVE
t3: M16C_STATE_BUS_ERROR | M16C_STATE_BUS_OFF
Thus as you suggested below, the flag M16C_STATE_BUS_ERROR might not mean
CAN_STATE_ERROR_WARNING...
Do you see bus error bits set? If not, I could mean error active,
otherwise error warning. Meaning the device sends such messages
containing bus error information plus the current state.
2) Short-circuit CAN-H and CAN-L and restart-ms = 100
t0: short-circuit + cansend can1 123#112233
can1 208C [8] 00 0C 90 00 00 00 00 00 ERRORFRAME
controller-problem{rx-error-warning,tx-error-warning}
protocol-violation{{tx-recessive-bit-error,error-on-tx}{}}
bus-error
can1 208C [8] 00 30 90 00 00 00 00 00 ERRORFRAME
controller-problem{rx-error-passive,tx-error-passive}
protocol-violation{{tx-recessive-bit-error,error-on-tx}{}}
bus-error
can1 20C8 [8] 00 00 90 00 00 00 00 00 ERRORFRAME
protocol-violation{{tx-recessive-bit-error,error-on-tx}{}}
bus-off
bus-error
can1 218C [8] 00 0C 90 00 00 00 00 00 ERRORFRAME
controller-problem{rx-error-warning,tx-error-warning}
Re: Continuous stream of small bulk transfers hangs on OHCI-based system
On Tue, 7 Aug 2012, Tomas Sokorai wrote: On Tue, Aug 7, 2012 at 3:42 PM, Alan Stern st...@rowland.harvard.edu wrote: I don't have time today to look further into this, but I'll get back to you later. No hurries, in fact I was gathering a bit more info about this behavior. I dumped the ed_rm_list when it is hung, and we have only one element that's unkillable: [ 1108.841482] ohci_hcd :00:04.0: ed_rm_list, ed 8800c781f140 state 0x1 type bulk; next ed [ 1108.841489] ohci_hcd :00:04.0: info 08405103 MAX=64 DQ SKIP EP=2-IN DEV=3 [ 1108.841494] ohci_hcd :00:04.0: tds: head c78261e0 DATA0 tail c78261e0 (not listing) Yep; that's undoubtedly the one your program is trying to kill. Also, there's only one non-empty ed_rm_list pass after the finish_unlinks between SR intr disables, when not hung. As it should be. So the next step is to see what's happening inside finish_unlinks(). The function is a big loop over the entries in the ed_rm_list, but we're considered just with the first part of the loop. last is initially set to ohci-ed_rm_list, and about line 945 we have: *last = ed-ed_next; If everything were working right, ed-ed_next would be NULL (no other ED's on the list). So either ed-ed_next points back to ed itself or else this line doesn't get executed at all. The only way for it not be executed is if the skip_ed case occurs. Therefore your next task is to determine what's going on. Does the tick_before() test succeed? Does we follow the goto skip_ed? Or is the list pointer messed up? Alan Stern -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH V2 1/2] usb: gadget/uvc: Port UVC webcam gadget to use videobuf2 framework
Hi Laurent,
-Original Message-
From: Laurent Pinchart [mailto:laurent.pinch...@ideasonboard.com]
Sent: Wednesday, August 08, 2012 5:32 PM
To: Bhupesh SHARMA
Cc: linux-usb@vger.kernel.org; ba...@ti.com
Subject: Re: [PATCH V2 1/2] usb: gadget/uvc: Port UVC webcam gadget to
use videobuf2 framework
Hi Bhupesh,
On Tuesday 07 August 2012 23:07:56 Bhupesh SHARMA wrote:
On Tuesday, August 07, 2012 8:23 PM Laurent Pinchart wrote:
On Tuesday 31 July 2012 06:24:51 Bhupesh Sharma wrote:
This patch reworks the videobuffer management logic present in
the
UVC webcam gadget and ports it to use the more apt videobuf2
framework
for video buffer management.
To support routing video data captured from a real V4L2 video
capture
device with a zero copy operation on videobuffers (as they pass
from the V4L2 domain to UVC domain via a user-space application),
we
need to support USER_PTR IO method at the UVC gadget side.
So the V4L2 capture device driver can still continue to use MMAP
IO
method and now the user-space application can just pass a pointer
to
the video buffers being dequeued from the V4L2 device side while
queueing them at the UVC gadget end. This ensures that we have a
zero-
copy design as the videobuffers pass from the V4L2 capture
device to
the UVC gadget.
Note that there will still be a need to apply UVC specific
payload
headers on top of each UVC payload data, which will still require
a
copy operation to be performed in the 'encode' routines of the
UVC
gadget.
This patch also addresses two issues found out while porting the
UVC
gadget to videobuf2 framework:
- In case the usb requests queued by the gadget get
completed
with a status of -ESHUTDOWN (disconnected from host), the
queue of videobuf2 should be cancelled to ensure that the
application space daemon is not left in a state waiting
for
a vb2 to be successfully absorbed at the USB side.
- In case the underlying UDC has already returned -
ESHUTDOWN
as status of a queued request, it means that the video
streaming endpoint is going to be disabled and hence the
underlying UDC will giveback all queued requests with a
status
of -ESHUTDOWN. In such a case, the requests are not
longer
queued at the UDC end and it doesn't make sense to
dequeue
them again in uvc_video_enable(0).
[snip]
diff --git a/drivers/usb/gadget/uvc_queue.c
b/drivers/usb/gadget/uvc_queue.c
index 104ae9c..bf6621b 100644
--- a/drivers/usb/gadget/uvc_queue.c
+++ b/drivers/usb/gadget/uvc_queue.c
[snip]
@@ -516,26 +276,34 @@ static void uvc_queue_cancel(struct
uvc_video_queue *queue, int disconnect) */
static int uvc_queue_enable(struct uvc_video_queue *queue, int
enable)
{
- unsigned int i;
+ unsigned long flags;
int ret = 0;
mutex_lock(queue-mutex);
if (enable) {
- if (uvc_queue_streaming(queue)) {
- ret = -EBUSY;
+ ret = vb2_streamon(queue-queue, queue-queue.type);
+ if (ret 0)
goto done;
- }
- queue-sequence = 0;
- queue-flags |= UVC_QUEUE_STREAMING;
+
queue-buf_used = 0;
} else {
- uvc_queue_cancel(queue, 0);
- INIT_LIST_HEAD(queue-mainqueue);
+ ret = vb2_streamoff(queue-queue, queue-
queue.type);
+ if (ret 0)
+ goto done;
+
+ spin_lock_irqsave(queue-irqlock, flags);
+
+ INIT_LIST_HEAD(queue-irqqueue);
- for (i = 0; i queue-count; ++i)
- queue-buffer[i].state = UVC_BUF_STATE_IDLE;
+ /*
+* as the uvc queue is being disabled, clear any
+* DISCONNECTED flag which was set earlier, so that
the
+* next qbuf from userspace does not fail with
ENODEV.
+*/
Please start the comment with a capital letter, spell UVC in
capital,
and fill the space up to 80 columns.
Sure.
+ if (queue-flags UVC_QUEUE_DISCONNECTED)
+ queue-flags = ~UVC_QUEUE_DISCONNECTED;
You can clear the flag unconditionally. What about moving this to
the
enable branch of the if ?
Ok for the first sentence of the comment.
For the 2nd part, we have to do it here itself as if the application
accessing this UVC webcam is closed and then started again (sending a
set-alt(0) and set-alt(1)), we will not be able to queue any buffers
on the
UVC gadget in the
Re: [PATCH 8/8] ARM: vt8500: gpio: Devicetree support for arch-vt8500
On 08/07/2012 07:39 PM, Tony Prisk wrote:
Converted the existing arch-vt8500 gpio to a platform_device.
Added support for WM8505 and WM8650 GPIO controllers.
diff --git a/drivers/gpio/gpio-vt8500.c b/drivers/gpio/gpio-vt8500.c
+static struct of_device_id vt8500_gpio_dt_ids[] = {
+ { .compatible = via,vt8500-gpio, .data = vt8500_data, },
+ { .compatible = wm,wm8505-gpio, .data = wm8505_data, },
+ { .compatible = wm,wm8650-gpio, .data = wm8650_data, },
+ { /* Sentinel */ },
+};
+
+static int __devinit vt8500_gpio_probe(struct platform_device *pdev)
+{
+ void __iomem *gpio_base;
+ struct device_node *np;
+ const struct of_device_id *of_id =
+ of_match_device(vt8500_gpio_dt_ids, pdev-dev);
+
+ if (!of_id) {
+ dev_err(pdev-dev, Failed to find gpio controller\n);
+ return -ENODEV;
+ }
+
+ np = of_find_matching_node(NULL, vt8500_gpio_dt_ids);
Can't you use pdev-dev.of_node instead of searching for it again?
...
+ of_node_put(np);
If so, you could also remove that.
+static int __init vt8500_gpio_init(void)
+{
+ return platform_driver_probe(vt8500_gpio_driver, vt8500_gpio_probe);
+}
+
+static void __exit vt8500_gpio_exit(void)
+{
+ return platform_driver_unregister(vt8500_gpio_driver);
+}
+
+module_init(vt8500_gpio_init);
+module_exit(vt8500_gpio_exit);
I think that's all just:
module_platform_driver(vt8500_gpio_driver);
(except that _init uses platform_driver_probe() rather than
platform_driver_register(), which seems unusual. I guess that explains
the of_find_matching_node() above too.)
+MODULE_LICENSE(GPL);
That should be GPL v2 given the license header.
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Kernel oops on usbhid_submit_report
Hello, I am getting the following kernel oops (http://paste.debian.net/182812/) sporadically. Kernel version is 3.2.14. Code basically does the following: ioctl(fd,HIDIOCSUSAGES, ref_multi_u); ioctl(fd,HIDIOCSREPORT, rep_info_u); Here are some notes: 1. Happens in implement() function called by hid_output_report. 2. Did an ftrace and found the HIDIOCSREPORT call takes 5.3ms to complete. Is it suppose to take this long? 3. Very hard to reproduce. Seems to me like a race condition? Thanks, Amit -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/8] arm: vt8500: Add device tree files for VIA/Wondermedia SoC's
On 08/07/2012 07:39 PM, Tony Prisk wrote:
Add device tree files for VT8500, WM8505 and WM8650 SoC's and
reference boards.
diff --git a/arch/arm/boot/dts/vt8500_ref.dts
b/arch/arm/boot/dts/vt8500_ref.dts
It appears more typical to use - rather than _ in the filename to
join SoC and board names.
I guess _ref means reference. Is that how the boards are commonly
known? Are you sure there will never be another reference board for
these SoCs? Given the model values in the file, something more like
vt8500-bv07.dts might be more appropriate?
+ /*
+ * Display node is based on Sascha Hauer's patch on dri-devel.
+ * Added a bpp property to calculate the size of the framebuffer
+ * until the binding is formalized.
+ */
+ display {
Maybe it's better to just hold off on adding this node, to wait until
the binding is complete so this file doesn't churn? Certainly it sounded
like Sascha was going to change the binding a little in response to
comments it received.
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 5/8] video: vt8500: Add devicetree support for vt8500-fb and wm8505-fb
On 08/07/2012 07:39 PM, Tony Prisk wrote:
Update vt8500-fb, wm8505-fb and wmt-ge-rops to support device
tree bindings.
Small change in wm8505-fb.c to support WM8650 framebuffer color
format.
That might warrant a separate patch?
diff --git a/drivers/video/vt8500lcdfb.c b/drivers/video/vt8500lcdfb.c
+ np = of_find_node_by_name(NULL, display);
+ if (!np) {
+ pr_err(%s: No display description in Device Tree\n, __func__);
+ ret = -EINVAL;
+ goto failed_free_res;
+ }
I believe that using hard-coded node names is frowned upon. Better would
be to put a phandle into the display controller's node that points at
the node representing the display, e.g.:
fb@d800e400 {
compatible = via,vt8500-fb;
reg = 0xd800e400 0x400;
interrupts = 12;
via,display = display;
};
display: display {
...
};
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 6/8] arm: vt8500: Update arch-vt8500 to devicetree support.
On 08/07/2012 07:39 PM, Tony Prisk wrote:
Merged existing board files to a single dt-capable file.
Converted irq and timer code to devicetree.
Removed existing device files that are no longer required with
devicetree support.
All existing platform devices are converted to devicetree nodes
except GPIO and PWM.
Perhaps that also explains what I was commenting on in the GPIO driver
patch. Why not convert GPIO too?
diff --git a/arch/arm/mach-vt8500/irq.c b/arch/arm/mach-vt8500/irq.c
/*
- * arch/arm/mach-vt8500/irq.c
+ * arch/arm/mach-vt8500/irq_dt.c
This file didn't get renamed?
diff --git a/arch/arm/mach-vt8500/vt8500.c b/arch/arm/mach-vt8500/vt8500.c
+void __init vt8500_init(void)
+{
+ struct device_node *np, *fb;
+ void __iomem *gpio_base;
+
+#ifdef CONFIG_FB_VT8500
+ fb = of_find_compatible_node(NULL, NULL, via,vt8500-fb);
+ if (fb) {
+ np = of_find_compatible_node(NULL, NULL, via,vt8500-gpio);
+ if (np) {
+ gpio_base = of_iomap(np, 0);
+
+ if (!gpio_base)
+ pr_err(%s:of_iomap(gpio_mux) failed\n,
__func__);
+
+ of_node_put(np);
+ } else {
+ gpio_base = ioremap(LEGACY_GPIO_BASE, 0x1000);
+ if (!gpio_base)
+ pr_err(%s:ioremap(legacy_gpio_mux) failed\n,
__func__);
+ }
+ if (gpio_base) {
+ writel(readl(gpio_base + VT8500_GPIO_MUX_REG) | 1,
+ gpio_base + VT8500_GPIO_MUX_REG);
+ iounmap(gpio_base);
+ } else
+ pr_err(%s: Could not remap GPIO mux\n, __func__);
+
+ of_node_put(fb);
+ }
+#endif
That looks quite suspicious. What's it doing? Is this something that
should be part of a pinctrl driver, or the GPIO driver?
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 8/8] ARM: vt8500: gpio: Devicetree support for arch-vt8500
On Wednesday 08 August 2012, Stephen Warren wrote: I think that's all just: module_platform_driver(vt8500_gpio_driver); (except that _init uses platform_driver_probe() rather than platform_driver_register(), which seems unusual. I guess that explains the of_find_matching_node() above too.) Ah, I totally missed both of these. Using platform_driver_register is definitely preferred over platform_driver_probe in cases like this, so using module_platform_driver is the right simplification. Arnd -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Query: Reset string id during rndis unbind
Kernel Newbie kernelfana...@gmail.com writes:
In the 3.4 kernel, we have observed that the RNDIS function driver clears
the string id reference to 0 during unbind. And, during bind, we see that
the rndis_init() itself is initiated only when the RNDIS string id reference
is 0. Is this ok?
The issue behind this query is:
As rndis is requesting a new string id during every bind, during dynamic
function switches (e.g. enable tethering/disable tethering) RNDIS gets a
new string id for its descriptor from the composite framework. When connecting
to a Windows host, due to the string id changes, the device manager treats
this as a new instance of the device and requests for driver installation
during every connect.
If you reconfigure the whole composite gadget, what guarantee do you
have that those ID's will be available? They could be assigned to
completely unrelated strings.
When I did the below changes, the above issue is not seen anymore. Can
you provide
your views on this?
--Change--
diff --git a/drivers/usb/gadget/f_rndis.c b/drivers/usb/gadget/f_rndis.c
index 6cfbb5b..3c12c42 100644
--- a/drivers/usb/gadget/f_rndis.c
+++ b/drivers/usb/gadget/f_rndis.c
@@ -820,7 +820,7 @@ rndis_unbind(struct usb_configuration *c, struct
usb_function *f)
rndis_deregister(rndis-config);
rndis_exit();
- rndis_string_defs[0].id = 0;
if (gadget_is_superspeed(c-cdev-gadget))
usb_free_descriptors(f-ss_descriptors);
@@ -869,14 +869,13 @@ rndis_bind_config_vendor(struct
usb_configuration *c, u8 ethaddr[ETH_ALEN],
if (!can_support_rndis(c) || !ethaddr)
return -EINVAL;
+ /* ... and setup RNDIS itself */
+ status = rndis_init();
+ if (status 0)
+ return status;
+
/* maybe allocate device-global string IDs */
if (rndis_string_defs[0].id == 0) {
-
- /* ... and setup RNDIS itself */
- status = rndis_init();
- if (status 0)
- return status;
-
/* control interface label */
status = usb_string_id(c-cdev);
if (status 0)
--End--
Thanks,
Balakumar R
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
Best regards, _ _
.o. | Liege of Serenely Enlightened Majesty of o' \,=./ `o
..o | Computer Science, Michał “mina86” Nazarewicz(o o)
ooo +email/xmpp: m...@google.com--ooO--(_)--Ooo--
pgpOsMWv9VEdM.pgp
Description: PGP signature
[Pull Request] xHCI bug fixes for 3.6
The following changes since commit 0d7614f09c1ebdbaa1599a5aba7593f147bf96ee: Linux 3.6-rc1 (2012-08-02 16:38:10 -0700) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/sarah/xhci.git for-usb-linus-2012-08-08 for you to fetch changes up to 50d0206fcaea3e736f912fd5b00ec6233fb4ce44: xhci: Fix bug after deq ptr set to link TRB. (2012-08-08 12:17:38 -0700) xHCI bug fixes and host quirks. Hi Greg, Here's four patches for 3.6. Most are marked for stable as well. The first one makes the xHCI driver load properly on newer Rensas hosts. The next two fix issues with the Etron host incorrectly marking short transfers as successful, and avoiding log warning spam for hosts that make the same mistake. The last patch fixes a really nasty xHCI driver bug that could cause general protection faults when devices stall transfers. Sarah Sharp Sarah Sharp (4): xhci: Increase reset timeout for Renesas 720201 host. xhci: Add Etron XHCI_TRUST_TX_LENGTH quirk. xhci: Rate-limit XHCI_TRUST_TX_LENGTH quirk warning. xhci: Fix bug after deq ptr set to link TRB. drivers/usb/host/xhci-pci.c |1 + drivers/usb/host/xhci-ring.c | 40 drivers/usb/host/xhci.c |5 +++-- drivers/usb/host/xhci.h |2 ++ 4 files changed, 30 insertions(+), 18 deletions(-) -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 4/4] xhci: Fix bug after deq ptr set to link TRB.
This patch fixes a particularly nasty bug that was revealed by the ring
expansion patches. The bug has been present since the very beginning of
the xHCI driver history, and could have caused general protection faults
from bad memory accesses.
The first thing to note is that a Set TR Dequeue Pointer command can
move the dequeue pointer to a link TRB, if the canceled or stalled
transfer TD ended just before a link TRB. The function to increment the
dequeue pointer, inc_deq, was written before cancellation and stall
support was added. It assumed that the dequeue pointer could never
point to a link TRB. It would unconditionally increment the dequeue
pointer at the start of the function, check if the pointer was now on a
link TRB, and move it to the top of the next segment if so.
This means that if a Set TR Dequeue Point command moved the dequeue
pointer to a link TRB, a subsequent call to inc_deq() would move the
pointer off the segment and into la-la-land. It would then read from
that memory to determine if it was a link TRB. Other functions would
often call inc_deq() until the dequeue pointer matched some other
pointer, which means this function would quite happily read all of
system memory before wrapping around to the right pointer value.
Often, there would be another endpoint segment from a different ring
allocated from the same DMA pool, which would be contiguous to the
segment inc_deq just stepped off of. inc_deq would eventually find the
link TRB in that segment, and blindly move the dequeue pointer back to
the top of the correct ring segment.
The only reason the original code worked at all is because there was
only one ring segment. With the ring expansion patches, the dequeue
pointer would eventually wrap into place, but the dequeue segment would
be out-of-sync. On the second TD after the dequeue pointer was moved to
a link TRB, trb_in_td() would fail (because the dequeue pointer and
dequeue segment were out-of-sync), and this message would appear:
ERROR Transfer event TRB DMA ptr not part of current TD
This fixes bugzilla entry 4333 (option-based modem unhappy on USB 3.0
port: Transfer event TRB DMA ptr not part of current TD, rejecting
I/O to offline device),
https://bugzilla.kernel.org/show_bug.cgi?id=4
and possibly other general protection fault bugs as well.
This patch should be backported to kernels as old as 2.6.31. A separate
patch will be created for kernels older than 3.4, since inc_deq was
modified in 3.4 and this patch will not apply.
Signed-off-by: Sarah Sharp sarah.a.sh...@linux.intel.com
Tested-by: James Ettle theholyet...@googlemail.com
Tested-by: Matthew Hall mh...@mhcomputing.net
Cc: sta...@vger.kernel.org
---
drivers/usb/host/xhci-ring.c | 36 ++--
1 files changed, 22 insertions(+), 14 deletions(-)
diff --git a/drivers/usb/host/xhci-ring.c b/drivers/usb/host/xhci-ring.c
index 0c93f5d..643c2f3 100644
--- a/drivers/usb/host/xhci-ring.c
+++ b/drivers/usb/host/xhci-ring.c
@@ -145,29 +145,37 @@ static void next_trb(struct xhci_hcd *xhci,
*/
static void inc_deq(struct xhci_hcd *xhci, struct xhci_ring *ring)
{
- union xhci_trb *next;
unsigned long long addr;
ring-deq_updates++;
- /* If this is not event ring, there is one more usable TRB */
+ /*
+* If this is not event ring, and the dequeue pointer
+* is not on a link TRB, there is one more usable TRB
+*/
if (ring-type != TYPE_EVENT
!last_trb(xhci, ring, ring-deq_seg, ring-dequeue))
ring-num_trbs_free++;
- next = ++(ring-dequeue);
- /* Update the dequeue pointer further if that was a link TRB or we're at
-* the end of an event ring segment (which doesn't have link TRBS)
-*/
- while (last_trb(xhci, ring, ring-deq_seg, next)) {
- if (ring-type == TYPE_EVENT last_trb_on_last_seg(xhci,
- ring, ring-deq_seg, next)) {
- ring-cycle_state = (ring-cycle_state ? 0 : 1);
+ do {
+ /*
+* Update the dequeue pointer further if that was a link TRB or
+* we're at the end of an event ring segment (which doesn't have
+* link TRBS)
+*/
+ if (last_trb(xhci, ring, ring-deq_seg, ring-dequeue)) {
+ if (ring-type == TYPE_EVENT
+ last_trb_on_last_seg(xhci, ring,
+ ring-deq_seg, ring-dequeue)) {
+ ring-cycle_state = (ring-cycle_state ? 0 : 1);
+ }
+ ring-deq_seg = ring-deq_seg-next;
+ ring-dequeue = ring-deq_seg-trbs;
+ } else {
+ ring-dequeue++;
}
- ring-deq_seg = ring-deq_seg-next;
- ring-dequeue =
[PATCH 2/4] xhci: Add Etron XHCI_TRUST_TX_LENGTH quirk.
Gary reports that with recent kernels, he notices more xHCI driver
warnings:
xhci_hcd :03:00.0: WARN Successful completion on short TX: needs
XHCI_TRUST_TX_LENGTH quirk?
We think his Etron xHCI host controller may have the same buggy behavior
as the Fresco Logic xHCI host. When a short transfer is received, the
host will mark the transfer as successfully completed when it should be
marking it with a short completion.
Fix this by turning on the XHCI_TRUST_TX_LENGTH quirk when the Etron
host is discovered. Note that Gary has revision 1, but if Etron fixes
this bug in future revisions, the quirk will have no effect.
This patch should be backported to kernels as old as 2.6.36, that
contain a backported version of commit
1530bbc6272d9da1e39ef8e06190d42c13a02733 xhci: Add new short TX quirk
for Fresco Logic host.
Signed-off-by: Sarah Sharp sarah.a.sh...@linux.intel.com
Reported-by: Gary E. Miller g...@rellim.com
Cc: sta...@vger.kernel.org
---
drivers/usb/host/xhci-pci.c |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/drivers/usb/host/xhci-pci.c b/drivers/usb/host/xhci-pci.c
index 18b231b..92eaff6 100644
--- a/drivers/usb/host/xhci-pci.c
+++ b/drivers/usb/host/xhci-pci.c
@@ -99,6 +99,7 @@ static void xhci_pci_quirks(struct device *dev, struct
xhci_hcd *xhci)
pdev-device == PCI_DEVICE_ID_ASROCK_P67) {
xhci-quirks |= XHCI_RESET_ON_RESUME;
xhci_dbg(xhci, QUIRK: Resetting on resume\n);
+ xhci-quirks |= XHCI_TRUST_TX_LENGTH;
}
if (pdev-vendor == PCI_VENDOR_ID_VIA)
xhci-quirks |= XHCI_RESET_ON_RESUME;
--
1.7.9
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 3/4] xhci: Rate-limit XHCI_TRUST_TX_LENGTH quirk warning.
When we encounter an xHCI host that needs the XHCI_TRUST_TX_LENGTH quirk, the xHCI driver ends up spewing messages about the quirk into dmesg every time a short packet occurs. Change the xHCI driver to rate-limit such warnings. Signed-off-by: Sarah Sharp sarah.a.sh...@linux.intel.com Reported-by: Matthew Hall mh...@mhcomputing.net Reported-by: Gary E. Miller g...@rellim.com --- drivers/usb/host/xhci-ring.c |4 ++-- drivers/usb/host/xhci.h |2 ++ 2 files changed, 4 insertions(+), 2 deletions(-) diff --git a/drivers/usb/host/xhci-ring.c b/drivers/usb/host/xhci-ring.c index 8275645..0c93f5d 100644 --- a/drivers/usb/host/xhci-ring.c +++ b/drivers/usb/host/xhci-ring.c @@ -2073,8 +2073,8 @@ static int handle_tx_event(struct xhci_hcd *xhci, if (xhci-quirks XHCI_TRUST_TX_LENGTH) trb_comp_code = COMP_SHORT_TX; else - xhci_warn(xhci, WARN Successful completion on short TX: - needs XHCI_TRUST_TX_LENGTH quirk?\n); + xhci_warn_ratelimited(xhci, + WARN Successful completion on short TX: needs XHCI_TRUST_TX_LENGTH quirk?\n); case COMP_SHORT_TX: break; case COMP_STOP: diff --git a/drivers/usb/host/xhci.h b/drivers/usb/host/xhci.h index 55c0785..96f49db 100644 --- a/drivers/usb/host/xhci.h +++ b/drivers/usb/host/xhci.h @@ -1537,6 +1537,8 @@ static inline struct usb_hcd *xhci_to_hcd(struct xhci_hcd *xhci) dev_err(xhci_to_hcd(xhci)-self.controller , fmt , ## args) #define xhci_warn(xhci, fmt, args...) \ dev_warn(xhci_to_hcd(xhci)-self.controller , fmt , ## args) +#define xhci_warn_ratelimited(xhci, fmt, args...) \ + dev_warn_ratelimited(xhci_to_hcd(xhci)-self.controller , fmt , ## args) /* TODO: copied from ehci.h - can be refactored? */ /* xHCI spec says all registers are little endian */ -- 1.7.9 -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/4] xhci: Add Etron XHCI_TRUST_TX_LENGTH quirk.
Hi Sarah,
If I am reading right, this patch is not any different from the one we were
trying to get my card reader to work on USB 3.0.
I did some further testing last with the same card, reader, and exfat driver
on a USB 2.0 port on the same machine and everything worked with no errors in
dmesg, when I cped 17GB of MTS film data off the card.
This makes me think there must be some additional problem with the controller
which needs to get worked around or resolved before this controller is really
going to work.
Regards,
Matthew.
On Wed, Aug 08, 2012 at 12:36:17PM -0700, Sarah Sharp wrote:
Gary reports that with recent kernels, he notices more xHCI driver
warnings:
xhci_hcd :03:00.0: WARN Successful completion on short TX: needs
XHCI_TRUST_TX_LENGTH quirk?
We think his Etron xHCI host controller may have the same buggy behavior
as the Fresco Logic xHCI host. When a short transfer is received, the
host will mark the transfer as successfully completed when it should be
marking it with a short completion.
Fix this by turning on the XHCI_TRUST_TX_LENGTH quirk when the Etron
host is discovered. Note that Gary has revision 1, but if Etron fixes
this bug in future revisions, the quirk will have no effect.
This patch should be backported to kernels as old as 2.6.36, that
contain a backported version of commit
1530bbc6272d9da1e39ef8e06190d42c13a02733 xhci: Add new short TX quirk
for Fresco Logic host.
Signed-off-by: Sarah Sharp sarah.a.sh...@linux.intel.com
Reported-by: Gary E. Miller g...@rellim.com
Cc: sta...@vger.kernel.org
---
drivers/usb/host/xhci-pci.c |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/drivers/usb/host/xhci-pci.c b/drivers/usb/host/xhci-pci.c
index 18b231b..92eaff6 100644
--- a/drivers/usb/host/xhci-pci.c
+++ b/drivers/usb/host/xhci-pci.c
@@ -99,6 +99,7 @@ static void xhci_pci_quirks(struct device *dev, struct
xhci_hcd *xhci)
pdev-device == PCI_DEVICE_ID_ASROCK_P67) {
xhci-quirks |= XHCI_RESET_ON_RESUME;
xhci_dbg(xhci, QUIRK: Resetting on resume\n);
+ xhci-quirks |= XHCI_TRUST_TX_LENGTH;
}
if (pdev-vendor == PCI_VENDOR_ID_VIA)
xhci-quirks |= XHCI_RESET_ON_RESUME;
--
1.7.9
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/4] xhci: Add Etron XHCI_TRUST_TX_LENGTH quirk.
Hi Matthew,
This patch does fix the error that Gary reported. And even though it
doesn't completely fix your issue, it did make the same error messages
Gary was seeing go away.
I'll still be looking at your logs, but I'm leaving on vacation this
Friday, so I'm not sure if we'll have time to solve your issue before I
leave. I'll be back Sept 4th.
Sarah Sharp
On Wed, Aug 08, 2012 at 12:44:39PM -0700, Matthew Hall wrote:
Hi Sarah,
If I am reading right, this patch is not any different from the one we were
trying to get my card reader to work on USB 3.0.
I did some further testing last with the same card, reader, and exfat driver
on a USB 2.0 port on the same machine and everything worked with no errors in
dmesg, when I cped 17GB of MTS film data off the card.
This makes me think there must be some additional problem with the controller
which needs to get worked around or resolved before this controller is really
going to work.
Regards,
Matthew.
On Wed, Aug 08, 2012 at 12:36:17PM -0700, Sarah Sharp wrote:
Gary reports that with recent kernels, he notices more xHCI driver
warnings:
xhci_hcd :03:00.0: WARN Successful completion on short TX: needs
XHCI_TRUST_TX_LENGTH quirk?
We think his Etron xHCI host controller may have the same buggy behavior
as the Fresco Logic xHCI host. When a short transfer is received, the
host will mark the transfer as successfully completed when it should be
marking it with a short completion.
Fix this by turning on the XHCI_TRUST_TX_LENGTH quirk when the Etron
host is discovered. Note that Gary has revision 1, but if Etron fixes
this bug in future revisions, the quirk will have no effect.
This patch should be backported to kernels as old as 2.6.36, that
contain a backported version of commit
1530bbc6272d9da1e39ef8e06190d42c13a02733 xhci: Add new short TX quirk
for Fresco Logic host.
Signed-off-by: Sarah Sharp sarah.a.sh...@linux.intel.com
Reported-by: Gary E. Miller g...@rellim.com
Cc: sta...@vger.kernel.org
---
drivers/usb/host/xhci-pci.c |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/drivers/usb/host/xhci-pci.c b/drivers/usb/host/xhci-pci.c
index 18b231b..92eaff6 100644
--- a/drivers/usb/host/xhci-pci.c
+++ b/drivers/usb/host/xhci-pci.c
@@ -99,6 +99,7 @@ static void xhci_pci_quirks(struct device *dev, struct
xhci_hcd *xhci)
pdev-device == PCI_DEVICE_ID_ASROCK_P67) {
xhci-quirks |= XHCI_RESET_ON_RESUME;
xhci_dbg(xhci, QUIRK: Resetting on resume\n);
+ xhci-quirks |= XHCI_TRUST_TX_LENGTH;
}
if (pdev-vendor == PCI_VENDOR_ID_VIA)
xhci-quirks |= XHCI_RESET_ON_RESUME;
--
1.7.9
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Port power off: ACPI _PLD and other ideas
Hi Tianyu,
I was talking to Alan Cox about the port power off mechanism, and he
suggested it might be good to expose the power resource information to
userspace via sysfs. Then the user could figure out which of their
devices are connected to which power resources. For example, users
could move devices that we can't safely power off to the same power
resource, instead of connecting them to several power resources.
Alan also suggested that the default for unconnectable USB ports should
be the auto setting instead of the on setting. His point was that
it's hard to add more aggressive power savings later on, and we should
just turn on the power savings and see if anyone complains. Then we'll
get more real user testing with systems that have ACPI tables from other
BIOS vendors, and we can see if the ACPI tables are sane.
Also, Bob Moore pointed out that we could use the _PLD ACPI method to
give users a better idea of the physical location of ports associated
with a power resource. I note that this patch adds support for the
physical device location data. Is that exposed to userspace via sysfs?
If not, maybe we should expose the _PLD values along with the User
Visiable and Port is Connectable ACPI values in the new port
directory.
Sarah Sharp
On Fri, May 04, 2012 at 11:06:37AM +0800, Lan Tianyu wrote:
From: Matthew Garrett m...@redhat.com
Add a simple helper function to allow drivers to obtain the physical
device location data.
Signed-off-by: Matthew Garrett m...@redhat.com
---
drivers/acpi/utils.c| 29 +
include/acpi/acpi_bus.h | 31 +++
2 files changed, 60 insertions(+), 0 deletions(-)
diff --git a/drivers/acpi/utils.c b/drivers/acpi/utils.c
index b002a47..5c320a0 100644
--- a/drivers/acpi/utils.c
+++ b/drivers/acpi/utils.c
@@ -382,3 +382,32 @@ acpi_evaluate_reference(acpi_handle handle,
}
EXPORT_SYMBOL(acpi_evaluate_reference);
+
+acpi_status
+acpi_get_physical_device_location(acpi_handle handle, struct acpi_pld *pld)
+{
+ acpi_status status;
+ struct acpi_buffer buffer = { ACPI_ALLOCATE_BUFFER, NULL };
+ union acpi_object *output;
+
+ status = acpi_evaluate_object(handle, _PLD, NULL, buffer);
+
+ if (ACPI_FAILURE(status))
+ return status;
+
+ output = buffer.pointer;
+
+ if (!output || output-type != ACPI_TYPE_PACKAGE
+ || !output-package.count
+ || output-package.elements[0].type != ACPI_TYPE_BUFFER
+ || output-package.elements[0].buffer.length sizeof(*pld)) {
+ status = AE_TYPE;
+ goto out;
+ }
+
+ memcpy(pld, output-package.elements[0].buffer.pointer,
+output-package.elements[0].buffer.length);
+out:
+ kfree(buffer.pointer);
+ return status;
+}
diff --git a/include/acpi/acpi_bus.h b/include/acpi/acpi_bus.h
index f1c8ca6..2642744 100644
--- a/include/acpi/acpi_bus.h
+++ b/include/acpi/acpi_bus.h
@@ -51,6 +51,37 @@ acpi_evaluate_reference(acpi_handle handle,
struct acpi_object_list *arguments,
struct acpi_handle_list *list);
+struct acpi_pld {
+ unsigned int revision:7; /* 0 */
+ unsigned int ignore_colour:1; /* 7 */
+ unsigned int colour:24; /* 8 */
+ unsigned int width:16; /* 32 */
+ unsigned int height:16; /* 48 */
+ unsigned int user_visible:1; /* 64 */
+ unsigned int dock:1; /* 65 */
+ unsigned int lid:1; /* 66 */
+ unsigned int panel:3; /* 67 */
+ unsigned int vertical_pos:2; /* 70 */
+ unsigned int horizontal_pos:2; /* 72 */
+ unsigned int shape:4; /* 74 */
+ unsigned int group_orientation:1; /* 78 */
+ unsigned int group_token:8; /* 79 */
+ unsigned int group_position:8; /* 87 */
+ unsigned int bay:1; /* 95 */
+ unsigned int ejectable:1; /* 96 */
+ unsigned int ospm_eject_required:1; /* 97 */
+ unsigned int cabinet_number:8; /* 98 */
+ unsigned int card_cage_number:8; /* 106 */
+ unsigned int reference:1; /* 114 */
+ unsigned int rotation:4; /* 115 */
+ unsigned int order:5; /* 119 */
+ unsigned int reserved:4; /* 124 */
+ unsigned int vertical_offset:16; /* 128 */
+ unsigned int horizontal_offset:16; /* 144 */
+};
+
+acpi_status
+acpi_get_physical_device_location(acpi_handle handle, struct acpi_pld *pld);
#ifdef CONFIG_ACPI
#include linux/proc_fs.h
--
1.7.6.rc2.8.g28eb
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: Port power off: ACPI _PLD and other ideas
I have a comment about the existing _PLD support in Linux.
It uses bitfields, and these are known to not be reliable when using them to
extract bits from a predefined bit-packed data structure. (different compilers
implement bitfields differently, and there are also endian considerations.)
We are working on a patch to remove these bitfield definitions and also create
a function that returns a useable struct from _PLD.
Bob
+struct acpi_pld {
+ unsigned int revision:7; /* 0 */
+ unsigned int ignore_colour:1; /* 7 */
+ unsigned int colour:24; /* 8 */
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/4] xhci: Add Etron XHCI_TRUST_TX_LENGTH quirk.
I understand if it takes a while as it's a complex one off problem. I just wanted to be sure we were on the same page and that I was being clear about what worked and what didn't. Regards, Matthew. On Wed, Aug 08, 2012 at 02:03:14PM -0700, Sarah Sharp wrote: Hi Matthew, This patch does fix the error that Gary reported. And even though it doesn't completely fix your issue, it did make the same error messages Gary was seeing go away. I'll still be looking at your logs, but I'm leaving on vacation this Friday, so I'm not sure if we'll have time to solve your issue before I leave. I'll be back Sept 4th. Sarah Sharp On Wed, Aug 08, 2012 at 12:44:39PM -0700, Matthew Hall wrote: Hi Sarah, If I am reading right, this patch is not any different from the one we were trying to get my card reader to work on USB 3.0. I did some further testing last with the same card, reader, and exfat driver on a USB 2.0 port on the same machine and everything worked with no errors in dmesg, when I cped 17GB of MTS film data off the card. This makes me think there must be some additional problem with the controller which needs to get worked around or resolved before this controller is really going to work. Regards, Matthew. -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH V2 1/2] usb: gadget/uvc: Port UVC webcam gadget to use videobuf2 framework
Hi Bhupesh,
On Thursday 09 August 2012 01:19:49 Bhupesh SHARMA wrote:
On Wednesday, August 08, 2012 5:32 PM Laurent Pinchart wrote:
On Tuesday 07 August 2012 23:07:56 Bhupesh SHARMA wrote:
On Tuesday, August 07, 2012 8:23 PM Laurent Pinchart wrote:
On Tuesday 31 July 2012 06:24:51 Bhupesh Sharma wrote:
[snip]
@@ -340,8 +344,13 @@ uvc_video_enable(struct uvc_video *video, int
enable)
}
if (!enable) {
- for (i = 0; i UVC_NUM_REQUESTS; ++i)
- usb_ep_dequeue(video-ep, video-req[i]);
+ /*
+ * dequeue requests on underlying UDC only if
+ * -ESHUTDOWN was not asserted by UDC earlier
+ */
+ if (!(queue-flags UVC_QUEUE_DISCONNECTED))
+ for (i = 0; i UVC_NUM_REQUESTS; ++i)
+ usb_ep_dequeue(video-ep,
video-req[i]);
What happens if you omit this check ?
Actually the underlying UDCs clean-up their respective request list when
they see a disconnect event from the Host.
This makes them giveback all USB requests queued by an gadget with a
status of ESHUTDOWN, so if we try to dequeue the 'already' dequeued
requests from the UDC, it throws warning/errors that it doesn't have
these requests queued any longer with it.
OK. In that case, I'd like to fix the problem globally. When we run out of
V4L2 buffers the requests will end up being stored in the req_free list by
uvc_video_complete(). Those requests are not queued, and should thus not
be dequeued.
Could you please split this change to another patch, and only dequeue
requests that are not queued ? This would require proper locking.
Ok, but I have noticed that the underlying UDC will usually return all USB
requests queued by the gadget when DISCONNECT happens.
This means that no USB requests will be queued at UDC end when
uvc_video_enable(0) is called. So if UDC saw a DISCONNECT from the Host,
all the USB requests defined by the macro UVC_NUM_REQUESTS will become
members of req_free list.
So, in reality we don't have to dequeue any USB request on the UDC end, when
uvc_video_enable(0) is called during DISCONNECT case (this is different from
the case where user-space application itself working at the UVC gadget side
is closed, in which case these requests will still be either queued to UDC
or will be members of req_free list).
In DISCONNECT from host, USB requests out of the UVC_NUM_REQUESTS count that
were not already queued to the UDC are anyways not required to be dequeued
and the rest have already been dequeued by the UDC itself. So, no USB
requests need to be dequeued in this case.
I agree with you about the disconnection case. My point was that the UVC
gadget driver tries to dequeue all requests unconditionally (or, with your
patch, in the non-disconnection case only). In the normal, non-disconnection
case, some requests can be in a non-queued state when uvc_video_enable(0) is
called, so we would run into the same problem as in the disconnection case
(trying to dequeue a non-queued request). I'd like both issues to be fixed by
a single patch, split from this one.
This is exactly what my patch does.
Or am I missing something here?
Another option would be to turn the warning/error messages into debug
messages (some drivers - namely MUSB - already outputs a debug message in
the usb_ep_dequeue handler if the request is not queued). I wonder whether
that wouldn't be a better solution.
Yes, but that isn't a very neat solution. We are trying to dequeue USB
requests from UDC when there are none queued there (not sure many UDC
maintainers will agree to this). As the gadget saw the USB requests
completed with ESHUTDOWN status, it has the sufficient information to make a
correct decision on which requests to dequeue now.
But, please feel free to let me know your ideas on the same :)
I guess it depends on the usb_ep_dequeue() API. The function documentation
doesn't clearly state whether calling it with an already dequeuing request is
valid (in which case it should return an error, possibly print a debug
message, but not a warning/error message) or not (in which case it can be very
vocal about it, and even WARN_ON()).
--
Regards,
Laurent Pinchart
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Do we need asynchronous pm_runtime_get()? (was: Re: bisected regression ...)
On Wednesday, August 08, 2012, Ming Lei wrote: On Wed, Aug 8, 2012 at 4:45 AM, Rafael J. Wysocki r...@sisk.pl wrote: On Tuesday, August 07, 2012, Ming Lei wrote: On Tue, Aug 7, 2012 at 7:23 PM, Rafael J. Wysocki r...@sisk.pl wrote: [...] and you want to move something out of previous .runtime_resume No, I don't. Where did you get that idea from? If so, I am wondering why the 'func' can't be called in .runtime_resume directly, and follow the below inside caller at the same time? if (device is active or disabled) call func(device). This was covered in my last reply to Alan. and do it in another new callback to speedup resume, No, not to speed up resume. The idea is to allow drivers to run something when the resume is complete, so that they don't have to implement a resume detection logic or use .runtime_resume() to run things that don't belong there. Looks it was said by you, :-) Unless your _driver_ callback is actually executed from within a PM domain callback, for example, and something else may be waiting for it to complete, so your data processing is adding latencies to some other threads. I'm not making that up, by the way, that really can happen. See http://marc.info/?l=linux-pmm=134394271517527w=2 We were discussing specific pseudo-code in the documentation and you conveniently took the above out of context. Never mind. :-) I was trying to illustrate my point with a convincing example and I admit I could do better. Anyway the point was that the purpose of .runtime_resume() was not to process random I/O. Its purpose is to _resume_ a suspended device, no less, no more. Which the so that they don't have to [...] use .runtime_resume() to run things that don't belong there. sentence above is about. So I've been saying the same thing all the time and it's never been specifically about speedup (or rather about latencies added by random I/O processing in drivers' runtime resume callbacks). Alan also said Okay, those are valid reasons for the idea. Except for this one, I don't see other obvious advantages about the patch. so it should be reasonable to introduce the .runtime_post_resume callback in logic. No. This doesn't have anything to do with callbacks! If you want a new callback, you should specify what the role of this callback is, otherwise it is not well defined. I this case, though, what the role of func() is depends on the caller and most likely every driver would use it for something different. So no, I don't see how it can be a callback. Also, the 'func' should be per driver, not per device since only one 'func' is enough for all same kind of devices driven by one same driver. It isn't per device! It is per _caller_. The fact that the pointer is stored _temporarily_ in struct device doesn't mean that it is per device and that it is a callback. From the struct device point of view it is _data_, not a member function. The fact is that it will become per-device one you store it in 'struct device'. Suppose one driver may drive 1 same devices, Do you have any specific example of that? If not, then please don't make up arguments. the same data will be stored inside all the 1 device instances, it is a good way to do it? Not mention 90% devices mayn't use the _temporarily_ data at all. It may be unused just as well as an additional callback pointer in a driver object. [...] So now please count how many struct dev_pm_ops objects there are on that system and compute the differece. And please note that drivers that don't use struct dev_pm_ops for power management will do that in the future. Most of dev_pm_ops stays inside module image, and not in ram. Care to explain? I'm not sure I understand the above correctly. It is a bit difficult to get the count of all dev_pm_ops objects in ram since it is defined statically. Still, they are occupying memory, aren't they? So you really can't tell the difference between storing pointers in device driver objects and struct device objects. For example, in USB subsystem, there are only 2 dev_pm_ops objects in RAM for a normal system, but there may have hundreds of usb devices in the system(usb_device, usb_interface, ep_device, ...). Yes, USB is kind of exceptional, but also this means that your let's put that pointer into struct dev_pm_ops idea won't work for USB drivers, precisely because they don't use struct dev_pm_ops objects. Thanks, Rafael -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] cdc-phonet: Don't leak in usbpn_open
From: Rémi Denis-Courmont r...@remlab.net Date: Wed, 8 Aug 2012 10:12:06 +0300 Le mercredi 8 août 2012 00:56:26 Jesper Juhl, vous avez écrit : We allocate memory for 'req' with usb_alloc_urb() and then test 'if (!req || rx_submit(pnd, req, GFP_KERNEL | __GFP_COLD))'. If we enter that branch due to '!req' then there is no problem. But if we enter the branch due to 'req' being != 0 and the 'rx_submit()' call being false, then we'll leak the memory we allocated. Deal with the leak by always calling 'usb_free_urb(req)' when entering the branch. If 'req' happens to be 0 then the call is harmless, if it is not 0 then we free the memory we allocated but don't need. Signed-off-by: Jesper Juhl j...@chaosbits.net Acked-by: Rémi Denis-Courmont r...@remlab.net Applied. -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH V2 1/2] usb: gadget/uvc: Port UVC webcam gadget to use videobuf2 framework
On Wed, 8 Aug 2012, Laurent Pinchart wrote: I guess it depends on the usb_ep_dequeue() API. The function documentation doesn't clearly state whether calling it with an already dequeuing request is valid (in which case it should return an error, possibly print a debug message, but not a warning/error message) or not (in which case it can be very vocal about it, and even WARN_ON()). It is valid. It pretty much has to be, because we need to handle the possibility that two threads might try to cancel the same request at the same time. Alan Stern -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH V2 1/2] usb: gadget/uvc: Port UVC webcam gadget to use videobuf2 framework
Hi Alan, On Wednesday 08 August 2012 21:31:12 Alan Stern wrote: On Wed, 8 Aug 2012, Laurent Pinchart wrote: I guess it depends on the usb_ep_dequeue() API. The function documentation doesn't clearly state whether calling it with an already dequeuing request is valid (in which case it should return an error, possibly print a debug message, but not a warning/error message) or not (in which case it can be very vocal about it, and even WARN_ON()). It is valid. It pretty much has to be, because we need to handle the possibility that two threads might try to cancel the same request at the same time. In that case we should fix the UDC drivers to be less vocal when usb_ep_dequeue() is called for a non-queued request. Bhupesh, would you like to send patches for that ? -- Regards, Laurent Pinchart -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH V2 1/2] usb: gadget/uvc: Port UVC webcam gadget to use videobuf2 framework
On Thu, 9 Aug 2012, Laurent Pinchart wrote: Hi Alan, On Wednesday 08 August 2012 21:31:12 Alan Stern wrote: On Wed, 8 Aug 2012, Laurent Pinchart wrote: I guess it depends on the usb_ep_dequeue() API. The function documentation doesn't clearly state whether calling it with an already dequeuing request is valid (in which case it should return an error, possibly print a debug message, but not a warning/error message) or not (in which case it can be very vocal about it, and even WARN_ON()). It is valid. It pretty much has to be, because we need to handle the possibility that two threads might try to cancel the same request at the same time. In that case we should fix the UDC drivers to be less vocal when usb_ep_dequeue() is called for a non-queued request. Bhupesh, would you like to send patches for that ? That's right. Trying to dequeue a non-queued request should return -EINVAL or something similar, but it shouldn't produce any log messages. Alan Stern -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCHv2 7/8] arm: vt8500: doc: Add device tree bindings for arch-vt8500 devices
Bindings for gpio, interrupt controller, power management controller,
timer, realtime clock, serial uart, ehci and uhci controllers and
framebuffer controllers used on the arch-vt8500 platform.
Framebuffer binding also specifies a 'display' node which is required
for determining the lcd panel data.
Signed-off-by: Tony Prisk li...@prisktech.co.nz
---
Documentation/devicetree/bindings/arm/vt8500.txt | 15 +++
.../bindings/arm/vt8500/via,vt8500-intc.txt| 16 +++
.../bindings/arm/vt8500/via,vt8500-pmc.txt | 13 ++
.../bindings/arm/vt8500/via,vt8500-timer.txt | 15 +++
.../devicetree/bindings/gpio/gpio_vt8500.txt | 24 ++
.../devicetree/bindings/rtc/via,vt8500-rtc.txt | 15 +++
.../bindings/tty/serial/via,vt8500-uart.txt| 15 +++
.../devicetree/bindings/usb/platform-uhci.txt | 15 +++
.../devicetree/bindings/usb/via,vt8500-ehci.txt| 15 +++
.../devicetree/bindings/vendor-prefixes.txt|2 +
.../devicetree/bindings/video/via,vt8500-fb.txt| 46
.../devicetree/bindings/video/wm,prizm-ge-rops.txt | 13 ++
.../devicetree/bindings/video/wm,wm8505-fb.txt | 20 +
13 files changed, 224 insertions(+)
create mode 100644 Documentation/devicetree/bindings/arm/vt8500.txt
create mode 100644
Documentation/devicetree/bindings/arm/vt8500/via,vt8500-intc.txt
create mode 100644
Documentation/devicetree/bindings/arm/vt8500/via,vt8500-pmc.txt
create mode 100644
Documentation/devicetree/bindings/arm/vt8500/via,vt8500-timer.txt
create mode 100644 Documentation/devicetree/bindings/gpio/gpio_vt8500.txt
create mode 100644 Documentation/devicetree/bindings/rtc/via,vt8500-rtc.txt
create mode 100644
Documentation/devicetree/bindings/tty/serial/via,vt8500-uart.txt
create mode 100644 Documentation/devicetree/bindings/usb/platform-uhci.txt
create mode 100644 Documentation/devicetree/bindings/usb/via,vt8500-ehci.txt
create mode 100644 Documentation/devicetree/bindings/video/via,vt8500-fb.txt
create mode 100644 Documentation/devicetree/bindings/video/wm,prizm-ge-rops.txt
create mode 100644 Documentation/devicetree/bindings/video/wm,wm8505-fb.txt
diff --git a/Documentation/devicetree/bindings/arm/vt8500.txt
b/Documentation/devicetree/bindings/arm/vt8500.txt
new file mode 100644
index 000..1b3b187
--- /dev/null
+++ b/Documentation/devicetree/bindings/arm/vt8500.txt
@@ -0,0 +1,15 @@
+VIA/Wondermedia VT8500 Platforms Device Tree Bindings
+---
+
+Boards with the VIA VT8500 SoC shall have the following properties:
+Required root node property:
+compatible = via,vt8500;
+
+Boards with the Wondermedia WM8505 SoC shall have the following properties:
+Required root node property:
+compatible = wm,wm8505;
+
+Boards with the Wondermedia WM8650 SoC shall have the following properties:
+Required root node property:
+compatible = wm,wm8650;
+
diff --git a/Documentation/devicetree/bindings/arm/vt8500/via,vt8500-intc.txt
b/Documentation/devicetree/bindings/arm/vt8500/via,vt8500-intc.txt
new file mode 100644
index 000..0a4ce10
--- /dev/null
+++ b/Documentation/devicetree/bindings/arm/vt8500/via,vt8500-intc.txt
@@ -0,0 +1,16 @@
+VIA/Wondermedia VT8500 Interrupt Controller
+-
+
+Required properties:
+- compatible : via,vt8500-intc
+- reg : Should contain 1 register ranges(address and length)
+- #interrupt-cells : should be 1
+
+Example:
+
+ intc: interrupt-controller@d814 {
+ compatible = via,vt8500-intc;
+ interrupt-controller;
+ reg = 0xd814 0x1;
+ #interrupt-cells = 1;
+ };
diff --git a/Documentation/devicetree/bindings/arm/vt8500/via,vt8500-pmc.txt
b/Documentation/devicetree/bindings/arm/vt8500/via,vt8500-pmc.txt
new file mode 100644
index 000..521b9c7
--- /dev/null
+++ b/Documentation/devicetree/bindings/arm/vt8500/via,vt8500-pmc.txt
@@ -0,0 +1,13 @@
+VIA/Wondermedia VT8500 Power Management Controller
+-
+
+Required properties:
+- compatible : via,vt8500-pmc
+- reg : Should contain 1 register ranges(address and length)
+
+Example:
+
+ pmc@d813 {
+ compatible = via,vt8500-pmc;
+ reg = 0xd813 0x1000;
+ };
diff --git a/Documentation/devicetree/bindings/arm/vt8500/via,vt8500-timer.txt
b/Documentation/devicetree/bindings/arm/vt8500/via,vt8500-timer.txt
new file mode 100644
index 000..901c73f
--- /dev/null
+++ b/Documentation/devicetree/bindings/arm/vt8500/via,vt8500-timer.txt
@@ -0,0 +1,15 @@
+VIA/Wondermedia VT8500 Timer
+-
+
+Required properties:
+- compatible : via,vt8500-timer
+- reg : Should contain 1 register ranges(address and length)
+- interrupts : interrupt for the timer
+
+Example:
+
+ timer@d8130100 {
+ compatible =
[PATCHv2 8/8] arm: vt8500: gpio: Devicetree support for arch-vt8500
Converted the existing arch-vt8500 gpio to a platform_device.
Added support for WM8505 and WM8650 GPIO controllers.
Signed-off-by: Tony Prisk li...@prisktech.co.nz
---
drivers/gpio/Kconfig |6 +
drivers/gpio/Makefile |1 +
drivers/gpio/gpio-vt8500.c | 313
3 files changed, 320 insertions(+)
create mode 100644 drivers/gpio/gpio-vt8500.c
diff --git a/drivers/gpio/Kconfig b/drivers/gpio/Kconfig
index 542f0c0..3c8897a 100644
--- a/drivers/gpio/Kconfig
+++ b/drivers/gpio/Kconfig
@@ -183,6 +183,12 @@ config GPIO_STA2X11
Say yes here to support the STA2x11/ConneXt GPIO device.
The GPIO module has 128 GPIO pins with alternate functions.
+config GPIO_VT8500
+ bool VIA/Wondermedia SoC GPIO Support
+ depends on ARCH_VT8500
+ help
+ Say yes here to support the VT8500/WM8505/WM8650 GPIO controller.
+
config GPIO_XILINX
bool Xilinx GPIO support
depends on PPC_OF || MICROBLAZE
diff --git a/drivers/gpio/Makefile b/drivers/gpio/Makefile
index 0f55662..2c014b9 100644
--- a/drivers/gpio/Makefile
+++ b/drivers/gpio/Makefile
@@ -66,6 +66,7 @@ obj-$(CONFIG_GPIO_TPS65912) += gpio-tps65912.o
obj-$(CONFIG_GPIO_TWL4030) += gpio-twl4030.o
obj-$(CONFIG_GPIO_UCB1400) += gpio-ucb1400.o
obj-$(CONFIG_GPIO_VR41XX) += gpio-vr41xx.o
+obj-$(CONFIG_GPIO_VT8500) += gpio-vt8500.o
obj-$(CONFIG_GPIO_VX855) += gpio-vx855.o
obj-$(CONFIG_GPIO_WM831X) += gpio-wm831x.o
obj-$(CONFIG_GPIO_WM8350) += gpio-wm8350.o
diff --git a/drivers/gpio/gpio-vt8500.c b/drivers/gpio/gpio-vt8500.c
new file mode 100644
index 000..19b12d9
--- /dev/null
+++ b/drivers/gpio/gpio-vt8500.c
@@ -0,0 +1,313 @@
+/* linux/arch/arm/mach-vt8500/gpio.c
+ *
+ * Copyright (C) 2012 Tony Prisk li...@prisktech.co.nz
+ * Based on gpio.c:
+ * - Copyright (C) 2010 Alexey Charkov alch...@gmail.com
+ *
+ * This software is licensed under the terms of the GNU General Public
+ * License version 2, as published by the Free Software Foundation, and
+ * may be copied, distributed, and modified under those terms.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ */
+
+#include linux/module.h
+#include linux/err.h
+#include linux/io.h
+#include linux/gpio.h
+#include linux/platform_device.h
+#include linux/bitops.h
+#include linux/of.h
+#include linux/of_address.h
+#include linux/of_irq.h
+#include linux/of_device.h
+
+/*
+ We handle GPIOs by bank, each bank containing up to 32 GPIOs covered
+ by one set of registers (although not all may be valid).
+
+ Because different SoC's have different register offsets, we pass the
+ register offsets as data in vt8500_gpio_dt_ids[].
+
+ A value of NO_REG is used to indicate that this register is not
+ supported. Only used for -en at the moment.
+*/
+
+#define NO_REG 0x
+
+/*
+ * struct vt8500_gpio_bank_regoffsets
+ * @en: offset to enable register of the bank
+ * @dir: offset to direction register of the bank
+ * @data_out: offset to the data out register of the bank
+ * @data_in: offset to the data in register of the bank
+ * @ngpio: highest valid pin in this bank
+ */
+
+struct vt8500_gpio_bank_regoffsets {
+ unsigned inten;
+ unsigned intdir;
+ unsigned intdata_out;
+ unsigned intdata_in;
+ unsigned char ngpio;
+};
+
+struct vt8500_gpio_data {
+ unsigned intnum_banks;
+ struct vt8500_gpio_bank_regoffsets banks[];
+};
+
+#define VT8500_BANK(__en, __dir, __out, __in, __ngpio) \
+{ \
+ .en = __en, \
+ .dir = __dir, \
+ .data_out = __out, \
+ .data_in = __in,\
+ .ngpio = __ngpio, \
+}
+
+static struct vt8500_gpio_data vt8500_data = {
+ .num_banks = 7,
+ .banks = {
+ VT8500_BANK(0x00, 0x20, 0x40, 0x60, 26),
+ VT8500_BANK(0x04, 0x24, 0x44, 0x64, 28),
+ VT8500_BANK(0x08, 0x28, 0x48, 0x68, 31),
+ VT8500_BANK(0x0C, 0x2C, 0x4C, 0x6C, 19),
+ VT8500_BANK(0x10, 0x30, 0x50, 0x70, 19),
+ VT8500_BANK(0x14, 0x34, 0x54, 0x74, 23),
+ VT8500_BANK(NO_REG, 0x3C, 0x5C, 0x7C, 9),
+ },
+};
+
+static struct vt8500_gpio_data wm8505_data = {
+ .num_banks = 10,
+ .banks = {
+ VT8500_BANK(0x40, 0x68, 0x90, 0xB8, 8),
+ VT8500_BANK(0x44, 0x6C, 0x94, 0xBC, 32),
+ VT8500_BANK(0x48, 0x70, 0x98, 0xC0, 6),
+
[PATCHv2 4/8] usb: vt8500: Add devicetree support for vt8500-ehci and -uhci.
Add devicetree support for vt8500-ehci.
Convert vt8500-uhci to a generic non-pci platform-uhci with
device tree support.
Signed-off-by: Tony Prisk li...@prisktech.co.nz
---
drivers/usb/host/Kconfig |4 +-
drivers/usb/host/ehci-vt8500.c | 25 --
drivers/usb/host/uhci-hcd.c |5 ++
drivers/usb/host/uhci-platform.c | 169 ++
4 files changed, 195 insertions(+), 8 deletions(-)
create mode 100644 drivers/usb/host/uhci-platform.c
diff --git a/drivers/usb/host/Kconfig b/drivers/usb/host/Kconfig
index dcfaaa9..d7a6b10 100644
--- a/drivers/usb/host/Kconfig
+++ b/drivers/usb/host/Kconfig
@@ -450,7 +450,7 @@ config USB_OHCI_LITTLE_ENDIAN
config USB_UHCI_HCD
tristate UHCI HCD (most Intel and VIA) support
- depends on USB (PCI || SPARC_LEON)
+ depends on USB (PCI || SPARC_LEON || ARCH_VT8500)
---help---
The Universal Host Controller Interface is a standard by Intel for
accessing the USB hardware in the PC (which is also called the USB
@@ -468,7 +468,7 @@ config USB_UHCI_HCD
config USB_UHCI_SUPPORT_NON_PCI_HC
bool
depends on USB_UHCI_HCD
- default y if SPARC_LEON
+ default y if (SPARC_LEON || ARCH_VT8500)
config USB_UHCI_BIG_ENDIAN_MMIO
bool
diff --git a/drivers/usb/host/ehci-vt8500.c b/drivers/usb/host/ehci-vt8500.c
index c1eda73..0e1637b 100644
--- a/drivers/usb/host/ehci-vt8500.c
+++ b/drivers/usb/host/ehci-vt8500.c
@@ -16,6 +16,7 @@
*
*/
+#include linux/of.h
#include linux/platform_device.h
static int ehci_update_device(struct usb_hcd *hcd, struct usb_device *udev)
@@ -84,20 +85,23 @@ static const struct hc_driver vt8500_ehci_hc_driver = {
.clear_tt_buffer_complete = ehci_clear_tt_buffer_complete,
};
+static u64 wmt_ehci_dma_mask = DMA_BIT_MASK(32);
+
static int vt8500_ehci_drv_probe(struct platform_device *pdev)
{
struct usb_hcd *hcd;
struct ehci_hcd *ehci;
struct resource *res;
+ int irq;
int ret;
if (usb_disabled())
return -ENODEV;
- if (pdev-resource[1].flags != IORESOURCE_IRQ) {
- pr_debug(resource[1] is not IORESOURCE_IRQ);
- return -ENOMEM;
- }
+ /* devicetree created devices don't specify a dma mask */
+ if (!pdev-dev.dma_mask)
+ pdev-dev.dma_mask = wmt_ehci_dma_mask;
+
hcd = usb_create_hcd(vt8500_ehci_hc_driver, pdev-dev, VT8500);
if (!hcd)
return -ENOMEM;
@@ -134,8 +138,9 @@ static int vt8500_ehci_drv_probe(struct platform_device
*pdev)
ehci_reset(ehci);
- ret = usb_add_hcd(hcd, pdev-resource[1].start,
- IRQF_SHARED);
+ irq = platform_get_irq(pdev, 0);
+
+ ret = usb_add_hcd(hcd, irq, IRQF_SHARED);
if (ret == 0) {
platform_set_drvdata(pdev, hcd);
return ret;
@@ -162,6 +167,11 @@ static int vt8500_ehci_drv_remove(struct platform_device
*pdev)
return 0;
}
+static const struct of_device_id vt8500_ehci_ids[] = {
+ { .compatible = via,vt8500-ehci, },
+ {}
+};
+
static struct platform_driver vt8500_ehci_driver = {
.probe = vt8500_ehci_drv_probe,
.remove = vt8500_ehci_drv_remove,
@@ -169,7 +179,10 @@ static struct platform_driver vt8500_ehci_driver = {
.driver = {
.name = vt8500-ehci,
.owner = THIS_MODULE,
+ .of_match_table = of_match_ptr(vt8500_ehci_ids),
}
};
MODULE_ALIAS(platform:vt8500-ehci);
+MODULE_LICENSE(GPL v2);
+MODULE_DEVICE_TABLE(of, vt8500_ehci_ids);
diff --git a/drivers/usb/host/uhci-hcd.c b/drivers/usb/host/uhci-hcd.c
index e4db350..5da5c99 100644
--- a/drivers/usb/host/uhci-hcd.c
+++ b/drivers/usb/host/uhci-hcd.c
@@ -846,6 +846,11 @@ static const char hcd_name[] = uhci_hcd;
#define PLATFORM_DRIVERuhci_grlib_driver
#endif
+#ifdef CONFIG_ARCH_VT8500
+#include uhci-platform.c
+#define PLATFORM_DRIVERuhci_platform_driver
+#endif
+
#if !defined(PCI_DRIVER) !defined(PLATFORM_DRIVER)
#error missing bus glue for uhci-hcd
#endif
diff --git a/drivers/usb/host/uhci-platform.c b/drivers/usb/host/uhci-platform.c
new file mode 100644
index 000..35ca094
--- /dev/null
+++ b/drivers/usb/host/uhci-platform.c
@@ -0,0 +1,169 @@
+/*
+ * Generic UHCI HCD (Host Controller Driver) for Platform Devices
+ *
+ * Copyright (c) 2011 Tony Prisk li...@prisktech.co.nz
+ *
+ * This file is based on uhci-grlib.c
+ * (C) Copyright 2004-2007 Alan Stern, st...@rowland.harvard.edu
+ */
+
+#include linux/of.h
+#include linux/platform_device.h
+
+static int uhci_platform_init(struct usb_hcd *hcd)
+{
+ struct uhci_hcd *uhci = hcd_to_uhci(hcd);
+
+ uhci-rh_numports = uhci_count_ports(hcd);
+
+ /* Set up pointers to to generic functions */
+ uhci-reset_hc = uhci_generic_reset_hc;
+
[PATCHv2 3/8] serial: vt8500: Add devicetree support for vt8500-serial
Signed-off-by: Tony Prisk li...@prisktech.co.nz
---
drivers/tty/serial/vt8500_serial.c |9 -
1 file changed, 8 insertions(+), 1 deletion(-)
diff --git a/drivers/tty/serial/vt8500_serial.c
b/drivers/tty/serial/vt8500_serial.c
index 2be006f..dee6715 100644
--- a/drivers/tty/serial/vt8500_serial.c
+++ b/drivers/tty/serial/vt8500_serial.c
@@ -34,6 +34,7 @@
#include linux/slab.h
#include linux/clk.h
#include linux/platform_device.h
+#include linux/of.h
/*
* UART Register offsets
@@ -603,12 +604,18 @@ static int __devexit vt8500_serial_remove(struct
platform_device *pdev)
return 0;
}
+static const struct of_device_id wmt_dt_ids[] = {
+ { .compatible = via,vt8500-uart, },
+ {}
+};
+
static struct platform_driver vt8500_platform_driver = {
.probe = vt8500_serial_probe,
.remove = __devexit_p(vt8500_serial_remove),
.driver = {
.name = vt8500_serial,
.owner = THIS_MODULE,
+ .of_match_table = of_match_ptr(wmt_dt_ids),
},
};
@@ -642,4 +649,4 @@ module_exit(vt8500_serial_exit);
MODULE_AUTHOR(Alexey Charkov alch...@gmail.com);
MODULE_DESCRIPTION(Driver for vt8500 serial device);
-MODULE_LICENSE(GPL);
+MODULE_LICENSE(GPL v2);
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCHv2 5/8] video: vt8500: Add devicetree support for vt8500-fb and wm8505-fb
Update vt8500-fb, wm8505-fb and wmt-ge-rops to support device
tree bindings.
Small change in wm8505-fb.c to support WM8650 framebuffer color
format.
Signed-off-by: Tony Prisk li...@prisktech.co.nz
---
drivers/video/Kconfig |6 +--
drivers/video/vt8500lcdfb.c | 79 ++-
drivers/video/wm8505fb.c| 97 ---
drivers/video/wmt_ge_rops.c |9 +++-
4 files changed, 161 insertions(+), 30 deletions(-)
diff --git a/drivers/video/Kconfig b/drivers/video/Kconfig
index 0217f74..b66d951 100644
--- a/drivers/video/Kconfig
+++ b/drivers/video/Kconfig
@@ -1788,7 +1788,7 @@ config FB_AU1200
config FB_VT8500
bool VT8500 LCD Driver
- depends on (FB = y) ARM ARCH_VT8500 VTWM_VERSION_VT8500
+ depends on (FB = y) ARM ARCH_VT8500
select FB_WMT_GE_ROPS
select FB_SYS_IMAGEBLIT
help
@@ -1797,11 +1797,11 @@ config FB_VT8500
config FB_WM8505
bool WM8505 frame buffer support
- depends on (FB = y) ARM ARCH_VT8500 VTWM_VERSION_WM8505
+ depends on (FB = y) ARM ARCH_VT8500
select FB_WMT_GE_ROPS
select FB_SYS_IMAGEBLIT
help
- This is the framebuffer driver for WonderMedia WM8505
+ This is the framebuffer driver for WonderMedia WM8505/WM8650
integrated LCD controller.
source drivers/video/geode/Kconfig
diff --git a/drivers/video/vt8500lcdfb.c b/drivers/video/vt8500lcdfb.c
index 2a5fe6e..d62234e 100644
--- a/drivers/video/vt8500lcdfb.c
+++ b/drivers/video/vt8500lcdfb.c
@@ -35,6 +35,13 @@
#include vt8500lcdfb.h
#include wmt_ge_rops.h
+#ifdef CONFIG_OF
+#include linux/of.h
+#include linux/of_fdt.h
+#include linux/memblock.h
+#endif
+
+
#define to_vt8500lcd_info(__info) container_of(__info, \
struct vt8500lcd_info, fb)
@@ -270,15 +277,21 @@ static int __devinit vt8500lcd_probe(struct
platform_device *pdev)
{
struct vt8500lcd_info *fbi;
struct resource *res;
- struct vt8500fb_platform_data *pdata = pdev-dev.platform_data;
void *addr;
int irq, ret;
+ struct fb_videomode of_mode;
+ struct device_node *np;
+ u32 bpp;
+ dma_addr_t fb_mem_phys;
+ unsigned long fb_mem_len;
+ void *fb_mem_virt;
+
ret = -ENOMEM;
fbi = NULL;
- fbi = kzalloc(sizeof(struct vt8500lcd_info) + sizeof(u32) * 16,
- GFP_KERNEL);
+ fbi = devm_kzalloc(pdev-dev, sizeof(struct vt8500lcd_info)
+ + sizeof(u32) * 16, GFP_KERNEL);
if (!fbi) {
dev_err(pdev-dev, Failed to initialize framebuffer
device\n);
ret = -ENOMEM;
@@ -333,9 +346,45 @@ static int __devinit vt8500lcd_probe(struct
platform_device *pdev)
goto failed_free_res;
}
- fbi-fb.fix.smem_start = pdata-video_mem_phys;
- fbi-fb.fix.smem_len= pdata-video_mem_len;
- fbi-fb.screen_base = pdata-video_mem_virt;
+ np = of_find_node_by_name(NULL, display);
+ if (!np) {
+ pr_err(%s: No display description in Device Tree\n, __func__);
+ ret = -EINVAL;
+ goto failed_free_res;
+ }
+
+ /*
+* This code is copied from Sascha Hauer's of_videomode helper
+* and can be replaced with a call to the helper once mainlined
+*/
+ ret = 0;
+ ret |= of_property_read_u32(np, xres, of_mode.xres);
+ ret |= of_property_read_u32(np, yres, of_mode.yres);
+ ret |= of_property_read_u32(np, left-margin, of_mode.left_margin);
+ ret |= of_property_read_u32(np, right-margin, of_mode.right_margin);
+ ret |= of_property_read_u32(np, hsync-len, of_mode.hsync_len);
+ ret |= of_property_read_u32(np, upper-margin, of_mode.upper_margin);
+ ret |= of_property_read_u32(np, lower-margin, of_mode.lower_margin);
+ ret |= of_property_read_u32(np, vsync-len, of_mode.vsync_len);
+ ret |= of_property_read_u32(np, bpp, bpp);
+ if (ret) {
+ pr_err(%s: Unable to read display properties\n, __func__);
+ goto failed_free_res;
+ }
+ of_mode.vmode = FB_VMODE_NONINTERLACED;
+
+ /* try allocating the framebuffer */
+ fb_mem_len = of_mode.xres * of_mode.yres * 2 * (bpp / 8);
+ fb_mem_virt = dma_alloc_coherent(pdev-dev, fb_mem_len, fb_mem_phys,
+ GFP_KERNEL);
+ if (!fb_mem_virt) {
+ pr_err(%s: Failed to allocate framebuffer\n, __func__);
+ return -ENOMEM;
+ };
+
+ fbi-fb.fix.smem_start = fb_mem_phys;
+ fbi-fb.fix.smem_len= fb_mem_len;
+ fbi-fb.screen_base = fb_mem_virt;
fbi-palette_size = PAGE_ALIGN(512);
fbi-palette_cpu= dma_alloc_coherent(pdev-dev,
@@ -370,10 +419,11 @@ static
[PATCHv2 2/8] rtc: vt8500: Add devicetree support for vt8500-rtc
Signed-off-by: Tony Prisk li...@prisktech.co.nz
---
drivers/rtc/rtc-vt8500.c |9 -
1 file changed, 8 insertions(+), 1 deletion(-)
diff --git a/drivers/rtc/rtc-vt8500.c b/drivers/rtc/rtc-vt8500.c
index 9e94fb1..07bf193 100644
--- a/drivers/rtc/rtc-vt8500.c
+++ b/drivers/rtc/rtc-vt8500.c
@@ -23,6 +23,7 @@
#include linux/bcd.h
#include linux/platform_device.h
#include linux/slab.h
+#include linux/of.h
/*
* Register definitions
@@ -302,12 +303,18 @@ static int __devexit vt8500_rtc_remove(struct
platform_device *pdev)
return 0;
}
+static const struct of_device_id wmt_dt_ids[] = {
+ { .compatible = via,vt8500-rtc, },
+ {}
+};
+
static struct platform_driver vt8500_rtc_driver = {
.probe = vt8500_rtc_probe,
.remove = __devexit_p(vt8500_rtc_remove),
.driver = {
.name = vt8500-rtc,
.owner = THIS_MODULE,
+ .of_match_table = of_match_ptr(wmt_dt_ids),
},
};
@@ -315,5 +322,5 @@ module_platform_driver(vt8500_rtc_driver);
MODULE_AUTHOR(Alexey Charkov alch...@gmail.com);
MODULE_DESCRIPTION(VIA VT8500 SoC Realtime Clock Driver (RTC));
-MODULE_LICENSE(GPL);
+MODULE_LICENSE(GPL v2);
MODULE_ALIAS(platform:vt8500-rtc);
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCHv2 1/8] arm: vt8500: Add device tree files for VIA/Wondermedia SoC's
Add device tree files for VT8500, WM8505 and WM8650 SoC's and
reference boards.
Signed-off-by: Tony Prisk li...@prisktech.co.nz
---
arch/arm/boot/dts/vt8500-bv07.dts | 31 +
arch/arm/boot/dts/vt8500.dtsi | 99 +
arch/arm/boot/dts/wm8505-ref.dts | 31 +
arch/arm/boot/dts/wm8505.dtsi | 125 +
arch/arm/boot/dts/wm8650-mid.dts | 31 +
arch/arm/boot/dts/wm8650.dtsi | 95
6 files changed, 412 insertions(+)
create mode 100644 arch/arm/boot/dts/vt8500-bv07.dts
create mode 100644 arch/arm/boot/dts/vt8500.dtsi
create mode 100644 arch/arm/boot/dts/wm8505-ref.dts
create mode 100644 arch/arm/boot/dts/wm8505.dtsi
create mode 100644 arch/arm/boot/dts/wm8650-mid.dts
create mode 100644 arch/arm/boot/dts/wm8650.dtsi
diff --git a/arch/arm/boot/dts/vt8500-bv07.dts
b/arch/arm/boot/dts/vt8500-bv07.dts
new file mode 100644
index 000..20dda12
--- /dev/null
+++ b/arch/arm/boot/dts/vt8500-bv07.dts
@@ -0,0 +1,31 @@
+/*
+ * vt8500-bv07.dts - Device tree file for Benign BV07 Netbook
+ *
+ * Copyright (C) 2012 Tony Prisk li...@prisktech.co.nz
+ *
+ * Licensed under GPLv2 or later
+ */
+
+/dts-v1/;
+/include/ vt8500.dtsi
+
+/ {
+ model = Benign BV07 Netbook;
+
+ /*
+* Display node is based on Sascha Hauer's patch on dri-devel.
+* Added a bpp property to calculate the size of the framebuffer
+* until the binding is formalized.
+*/
+ display {
+ xres = 800;
+ yres = 480;
+ left-margin = 88;
+ right-margin = 40;
+ hsync-len = 0;
+ upper-margin = 32;
+ lower-margin = 11;
+ vsync-len = 1;
+ bpp = 16;
+ };
+};
diff --git a/arch/arm/boot/dts/vt8500.dtsi b/arch/arm/boot/dts/vt8500.dtsi
new file mode 100644
index 000..7a2fe0e
--- /dev/null
+++ b/arch/arm/boot/dts/vt8500.dtsi
@@ -0,0 +1,99 @@
+/*
+ * vt8500.dtsi - Device tree file for VIA VT8500 SoC
+ *
+ * Copyright (C) 2012 Tony Prisk li...@prisktech.co.nz
+ *
+ * Licensed under GPLv2 or later
+ */
+
+/include/ skeleton.dtsi
+
+/ {
+ compatible = via,vt8500;
+
+ soc {
+ #address-cells = 1;
+ #size-cells = 1;
+ compatible = simple-bus;
+ ranges;
+ interrupt-parent = intc;
+
+ intc: interrupt-controller@d814 {
+ compatible = via,vt8500-intc;
+ interrupt-controller;
+ reg = 0xd814 0x1;
+ #interrupt-cells = 1;
+ };
+
+ gpio: gpio-controller@d811 {
+ compatible = via,vt8500-gpio;
+ gpio-controller;
+ reg = 0xd811 0x1;
+ #gpio-cells = 3;
+ };
+
+ pmc@d813 {
+ compatible = via,vt8500-pmc;
+ reg = 0xd813 0x1000;
+ };
+
+ timer@d8130100 {
+ compatible = via,vt8500-timer;
+ reg = 0xd8130100 0x28;
+ interrupts = 36;
+ };
+
+ ehci@d8007900 {
+ compatible = via,vt8500-ehci;
+ reg = 0xd8007900 0x200;
+ interrupts = 43;
+ };
+
+ uhci@d8007b00 {
+ compatible = platform-uhci;
+ reg = 0xd8007b00 0x200;
+ interrupts = 43;
+ };
+
+ fb@d800e400 {
+ compatible = via,vt8500-fb;
+ reg = 0xd800e400 0x400;
+ interrupts = 12;
+ };
+
+ ge_rops@d8050400 {
+ compatible = wm,prizm-ge-rops;
+ reg = 0xd8050400 0x100;
+ };
+
+ uart@d820 {
+ compatible = via,vt8500-uart;
+ reg = 0xd820 0x1040;
+ interrupts = 32;
+ };
+
+ uart@d82b {
+ compatible = via,vt8500-uart;
+ reg = 0xd82b 0x1040;
+ interrupts = 33;
+ };
+
+ uart@d821 {
+ compatible = via,vt8500-uart;
+ reg = 0xd821 0x1040;
+ interrupts = 47;
+ };
+
+ uart@d82c {
+ compatible = via,vt8500-uart;
+ reg = 0xd82c 0x1040;
+ interrupts = 50;
+ };
+
+ rtc@d810 {
+ compatible = via,vt8500-rtc;
+ reg = 0xd810 0x1;
+
Re: Port power off: ACPI _PLD and other ideas
On 2012/8/9 5:22, Sarah Sharp wrote:
Hi Tianyu,
I was talking to Alan Cox about the port power off mechanism, and he
suggested it might be good to expose the power resource information to
userspace via sysfs. Then the user could figure out which of their
devices are connected to which power resources. For example, users
could move devices that we can't safely power off to the same power
resource, instead of connecting them to several power resources.
Ok. But the name of power resource is defined by the bios randomly,
usr space app should do something to identify, categorize and show
this to user. Current the power resource is acpi specific. Is there
a generic way to present it or we should add power resource architecture
in the usb core?
Alan also suggested that the default for unconnectable USB ports should
be the auto setting instead of the on setting. His point was that
it's hard to add more aggressive power savings later on, and we should
just turn on the power savings and see if anyone complains. Then we'll
get more real user testing with systems that have ACPI tables from other
BIOS vendors, and we can see if the ACPI tables are sane.
I think we needs others' opinions.
hi Grep,Alan,Oliver:
Do you have some comments?
Also, Bob Moore pointed out that we could use the _PLD ACPI method to
give users a better idea of the physical location of ports associated
with a power resource. I note that this patch adds support for the
physical device location data. Is that exposed to userspace via sysfs?
No. This is only used to identify whether the device is removable and
export to user space visa attribute removable and no other information
(e.g visible and connectable)
If not, maybe we should expose the _PLD values along with the User
Visiable and Port is Connectable ACPI values in the new port
directory.
Yeah. I agree.
Sarah Sharp
On Fri, May 04, 2012 at 11:06:37AM +0800, Lan Tianyu wrote:
From: Matthew Garrett m...@redhat.com
Add a simple helper function to allow drivers to obtain the physical
device location data.
Signed-off-by: Matthew Garrett m...@redhat.com
---
drivers/acpi/utils.c| 29 +
include/acpi/acpi_bus.h | 31 +++
2 files changed, 60 insertions(+), 0 deletions(-)
diff --git a/drivers/acpi/utils.c b/drivers/acpi/utils.c
index b002a47..5c320a0 100644
--- a/drivers/acpi/utils.c
+++ b/drivers/acpi/utils.c
@@ -382,3 +382,32 @@ acpi_evaluate_reference(acpi_handle handle,
}
EXPORT_SYMBOL(acpi_evaluate_reference);
+
+acpi_status
+acpi_get_physical_device_location(acpi_handle handle, struct acpi_pld *pld)
+{
+ acpi_status status;
+ struct acpi_buffer buffer = { ACPI_ALLOCATE_BUFFER, NULL };
+ union acpi_object *output;
+
+ status = acpi_evaluate_object(handle, _PLD, NULL, buffer);
+
+ if (ACPI_FAILURE(status))
+ return status;
+
+ output = buffer.pointer;
+
+ if (!output || output-type != ACPI_TYPE_PACKAGE
+ || !output-package.count
+ || output-package.elements[0].type != ACPI_TYPE_BUFFER
+ || output-package.elements[0].buffer.length sizeof(*pld)) {
+ status = AE_TYPE;
+ goto out;
+ }
+
+ memcpy(pld, output-package.elements[0].buffer.pointer,
+ output-package.elements[0].buffer.length);
+out:
+ kfree(buffer.pointer);
+ return status;
+}
diff --git a/include/acpi/acpi_bus.h b/include/acpi/acpi_bus.h
index f1c8ca6..2642744 100644
--- a/include/acpi/acpi_bus.h
+++ b/include/acpi/acpi_bus.h
@@ -51,6 +51,37 @@ acpi_evaluate_reference(acpi_handle handle,
struct acpi_object_list *arguments,
struct acpi_handle_list *list);
+struct acpi_pld {
+ unsigned int revision:7; /* 0 */
+ unsigned int ignore_colour:1; /* 7 */
+ unsigned int colour:24; /* 8 */
+ unsigned int width:16; /* 32 */
+ unsigned int height:16; /* 48 */
+ unsigned int user_visible:1; /* 64 */
+ unsigned int dock:1; /* 65 */
+ unsigned int lid:1; /* 66 */
+ unsigned int panel:3; /* 67 */
+ unsigned int vertical_pos:2; /* 70 */
+ unsigned int horizontal_pos:2; /* 72 */
+ unsigned int shape:4; /* 74 */
+ unsigned int group_orientation:1; /* 78 */
+ unsigned int group_token:8; /* 79 */
+ unsigned int group_position:8; /* 87 */
+ unsigned int bay:1; /* 95 */
+ unsigned int ejectable:1; /* 96 */
+ unsigned int ospm_eject_required:1; /* 97 */
+ unsigned int cabinet_number:8; /* 98 */
+ unsigned int card_cage_number:8; /* 106 */
+ unsigned int reference:1; /* 114 */
+ unsigned int rotation:4; /* 115 */
+ unsigned int order:5; /* 119 */
+ unsigned int reserved:4; /* 124 */
+ unsigned int vertical_offset:16; /* 128 */
+ unsigned int horizontal_offset:16; /* 144 */
+};
+
+acpi_status
Re: Port power off: ACPI _PLD and other ideas
On 2012/8/9 5:30, Moore, Robert wrote:
I have a comment about the existing _PLD support in Linux.
It uses bitfields, and these are known to not be reliable when using them to
extract bits from a predefined bit-packed data structure. (different compilers
implement bitfields differently, and there are also endian considerations.)
We are working on a patch to remove these bitfield definitions and also create
a function that returns a useable struct from _PLD.
OK. So our work should base on your new patchs.
Bob
+struct acpi_pld {
+ unsigned int revision:7; /* 0 */
+ unsigned int ignore_colour:1; /* 7 */
+ unsigned int colour:24; /* 8 */
--
Best Regards
Tianyu Lan
linux kernel enabling team
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH V2 1/2] usb: gadget/uvc: Port UVC webcam gadget to use videobuf2 framework
Hi Alan and Laurent, -Original Message- From: Alan Stern [mailto:st...@rowland.harvard.edu] Sent: Thursday, August 09, 2012 7:20 AM To: Laurent Pinchart Cc: Bhupesh SHARMA; linux-usb@vger.kernel.org; ba...@ti.com Subject: Re: [PATCH V2 1/2] usb: gadget/uvc: Port UVC webcam gadget to use videobuf2 framework On Thu, 9 Aug 2012, Laurent Pinchart wrote: Hi Alan, On Wednesday 08 August 2012 21:31:12 Alan Stern wrote: On Wed, 8 Aug 2012, Laurent Pinchart wrote: I guess it depends on the usb_ep_dequeue() API. The function documentation doesn't clearly state whether calling it with an already dequeuing request is valid (in which case it should return an error, possibly print a debug message, but not a warning/error message) or not (in which case it can be very vocal about it, and even WARN_ON()). It is valid. It pretty much has to be, because we need to handle the possibility that two threads might try to cancel the same request at the same time. In that case we should fix the UDC drivers to be less vocal when usb_ep_dequeue() is called for a non-queued request. Bhupesh, would you like to send patches for that ? That's right. Trying to dequeue a non-queued request should return -EINVAL or something similar, but it shouldn't produce any log messages. Got your point. I will try to send patches for UDC drivers to return -EINVAL instead of outputting msgs using WARN_ON, dev_warn, dev_err like constructs in this case. Regards, Bhupesh -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH V2 1/2] usb: gadget/uvc: Port UVC webcam gadget to use videobuf2 framework
Hi Laurent,
-Original Message-
From: Laurent Pinchart [mailto:laurent.pinch...@ideasonboard.com]
Sent: Thursday, August 09, 2012 3:12 AM
To: Bhupesh SHARMA
Cc: linux-usb@vger.kernel.org; ba...@ti.com
Subject: Re: [PATCH V2 1/2] usb: gadget/uvc: Port UVC webcam gadget to
use videobuf2 framework
Hi Bhupesh,
On Thursday 09 August 2012 01:19:49 Bhupesh SHARMA wrote:
On Wednesday, August 08, 2012 5:32 PM Laurent Pinchart wrote:
On Tuesday 07 August 2012 23:07:56 Bhupesh SHARMA wrote:
On Tuesday, August 07, 2012 8:23 PM Laurent Pinchart wrote:
On Tuesday 31 July 2012 06:24:51 Bhupesh Sharma wrote:
[snip]
@@ -340,8 +344,13 @@ uvc_video_enable(struct uvc_video
*video, int
enable)
}
if (!enable) {
- for (i = 0; i UVC_NUM_REQUESTS; ++i)
- usb_ep_dequeue(video-ep, video-req[i]);
+ /*
+* dequeue requests on underlying UDC only if
+* -ESHUTDOWN was not asserted by UDC earlier
+*/
+ if (!(queue-flags UVC_QUEUE_DISCONNECTED))
+ for (i = 0; i UVC_NUM_REQUESTS; ++i)
+ usb_ep_dequeue(video-ep,
video-req[i]);
What happens if you omit this check ?
Actually the underlying UDCs clean-up their respective request
list when
they see a disconnect event from the Host.
This makes them giveback all USB requests queued by an gadget
with a
status of ESHUTDOWN, so if we try to dequeue the 'already'
dequeued
requests from the UDC, it throws warning/errors that it doesn't
have
these requests queued any longer with it.
OK. In that case, I'd like to fix the problem globally. When we run
out of
V4L2 buffers the requests will end up being stored in the req_free
list by
uvc_video_complete(). Those requests are not queued, and should
thus not
be dequeued.
Could you please split this change to another patch, and only
dequeue
requests that are not queued ? This would require proper locking.
Ok, but I have noticed that the underlying UDC will usually return
all USB
requests queued by the gadget when DISCONNECT happens.
This means that no USB requests will be queued at UDC end when
uvc_video_enable(0) is called. So if UDC saw a DISCONNECT from the
Host,
all the USB requests defined by the macro UVC_NUM_REQUESTS will
become
members of req_free list.
So, in reality we don't have to dequeue any USB request on the UDC
end, when
uvc_video_enable(0) is called during DISCONNECT case (this is
different from
the case where user-space application itself working at the UVC
gadget side
is closed, in which case these requests will still be either queued
to UDC
or will be members of req_free list).
In DISCONNECT from host, USB requests out of the UVC_NUM_REQUESTS
count that
were not already queued to the UDC are anyways not required to be
dequeued
and the rest have already been dequeued by the UDC itself. So, no USB
requests need to be dequeued in this case.
I agree with you about the disconnection case. My point was that the
UVC
gadget driver tries to dequeue all requests unconditionally (or, with
your
patch, in the non-disconnection case only). In the normal, non-
disconnection
case, some requests can be in a non-queued state when
uvc_video_enable(0) is
called, so we would run into the same problem as in the disconnection
case
(trying to dequeue a non-queued request). I'd like both issues to be
fixed by
a single patch, split from this one.
Ok, now I got your point. You are talking about the non-disconnect case
(disconnect initiated
by the user-space application using the UVC gadget).
I will send a separate patch to handle these cases, as suggested then.
Regards,
Bhupesh
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Query: Reset string id during rndis unbind
Hello Michal,
On Thu, Aug 9, 2012 at 12:55 AM, Michal Nazarewicz min...@mina86.com wrote:
Kernel Newbie kernelfana...@gmail.com writes:
In the 3.4 kernel, we have observed that the RNDIS function driver clears
the string id reference to 0 during unbind. And, during bind, we see that
the rndis_init() itself is initiated only when the RNDIS string id reference
is 0. Is this ok?
The issue behind this query is:
As rndis is requesting a new string id during every bind, during dynamic
function switches (e.g. enable tethering/disable tethering) RNDIS gets a
new string id for its descriptor from the composite framework. When
connecting
to a Windows host, due to the string id changes, the device manager treats
this as a new instance of the device and requests for driver installation
during every connect.
If you reconfigure the whole composite gadget, what guarantee do you
have that those ID's will be available? They could be assigned to
completely unrelated strings.
Ok. In that case, the other gadget drivers follow the same behavior
during unbind right? e.g. f_acm or f_ecm drivers should also reset
their id's to 0 during unbind? Please correct me if my understanding
is wrong.
Thanks,
Balakumar R
When I did the below changes, the above issue is not seen anymore. Can
you provide
your views on this?
--Change--
diff --git a/drivers/usb/gadget/f_rndis.c b/drivers/usb/gadget/f_rndis.c
index 6cfbb5b..3c12c42 100644
--- a/drivers/usb/gadget/f_rndis.c
+++ b/drivers/usb/gadget/f_rndis.c
@@ -820,7 +820,7 @@ rndis_unbind(struct usb_configuration *c, struct
usb_function *f)
rndis_deregister(rndis-config);
rndis_exit();
- rndis_string_defs[0].id = 0;
if (gadget_is_superspeed(c-cdev-gadget))
usb_free_descriptors(f-ss_descriptors);
@@ -869,14 +869,13 @@ rndis_bind_config_vendor(struct
usb_configuration *c, u8 ethaddr[ETH_ALEN],
if (!can_support_rndis(c) || !ethaddr)
return -EINVAL;
+ /* ... and setup RNDIS itself */
+ status = rndis_init();
+ if (status 0)
+ return status;
+
/* maybe allocate device-global string IDs */
if (rndis_string_defs[0].id == 0) {
-
- /* ... and setup RNDIS itself */
- status = rndis_init();
- if (status 0)
- return status;
-
/* control interface label */
status = usb_string_id(c-cdev);
if (status 0)
--End--
Thanks,
Balakumar R
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
Best regards, _ _
.o. | Liege of Serenely Enlightened Majesty of o' \,=./ `o
..o | Computer Science, Michał “mina86” Nazarewicz(o o)
ooo +email/xmpp: m...@google.com--ooO--(_)--Ooo--
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Do we need asynchronous pm_runtime_get()? (was: Re: bisected regression ...)
On Thu, Aug 9, 2012 at 4:16 AM, Rafael J. Wysocki r...@sisk.pl wrote: On Wednesday, August 08, 2012, Alan Stern wrote: To be honest, I agree on the idea: The runtime-resume method does nothing but bring the device back to full power; it doesn't do any other processing, which should be done in 'func' or some kind of callback. I just think it is not good to introduce one extra field of 'func' in dev_pm_info which is embedded into struct device in the patch, see the reasons in the last part of the reply. That was my original suggestion. Rafael pointed out that having a single function call to do this would make it easier for driver writers to get it right. Not only would it be easier to get it right, in my opinion, but also in the example above func() may be called in some places where the driver may not want it to be called and which are very difficult to detect (like a resume from __device_suspend() during system suspend). Moreover, if the driver IMO, func() does some driver specific things, which PM core shouldn't pay special attention to in theory. callback is not executed directly by the PM core, but instead it is executed by a subsystem or PM domain callback, there's no guarantee that the device _can_ be used for processing regular I/O before the driver callback returns (the subsystem callback may still need to do something _after_ that happens). driver-runtime_resume should be allowed to do I/O things after the device has been woken up inside driver callback, shouldn't it? If it isn't allowed, something wrong should have be reported before. So, this appears to be a matter of correctness too. If you've got a system with 1 device instances, you can probably spare the memory needed to store these function pointers. But you're right that this is a disadvantage. Yes, it is in grand general, but that also is a matter of alignment and of the way the slab allocator works. For example, if every struct device object were stored at the beginning of a new memory page, then its size wouldn't matter a lot as long as it were smaller than PAGE_SIZE. I haven't checked the details, but I'm pretty sure that focusing on the size alone doesn't give us the whole picture here. The allocation by kmalloc is not page aligned, and it is 2-power aligned, for example 16, 32, 64,..., also it is at least hardware L1 cache size aligned. Firstly, introduce one extra pointer in device may increase memory consume for device allocation, also it reflects one design drawback in the patch, see below. More importantly, the implementation violates some software design principle in object oriented design. The driver core takes much object oriented idea in its design and implementation, and introduces device / driver / bus class. One class is an abstraction of one kind of objects or instances with same attributes, so one class may include many objects, for example, usb_device(class) is abstraction for all usb devices, and there may have many many usb devices in a system, but only one usb_device structure defined. One specific driver class is a special class since it may only have one driver object , which is basically read only. In OO world, it might be called static class. Generally, one driver object serves one specific device class, instead of one device object. For example, usb_storage_driver is a driver object, which serves all usb mass storage devices which all belongs to usb mass storage class). The 'func' to be introduced is a function pointer, which should be driver related thing and should serve one specific device class in theory, and it shouldn't serve only one concrete device object, so it is not good to include it into 'struct device'. The only function pointer in struct device: void(*release)(struct device *dev) should be removed. All its users should convert to use device_type to define release handler for its 'device class', instead of device object. So suggest to improve it. Thanks, -- Ming Lei -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
