[U-Boot] [PATCH v2 1/3] USB: make usb_kbd obey USB DMA alignment requirements
Change usb_kbd driver to obey alignment requirements for USB DMA on the buffer used for data transfer. This is necessary for architectures that enable dcache and enable USB DMA.
Signed-off-by: Allen Martin amartin@nvidia.com --- common/usb_kbd.c | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/common/usb_kbd.c b/common/usb_kbd.c index 19f01db..57928d9 100644 --- a/common/usb_kbd.c +++ b/common/usb_kbd.c @@ -106,15 +106,15 @@ static const unsigned char usb_kbd_num_keypad[] = { (USB_KBD_NUMLOCK | USB_KBD_CAPSLOCK | USB_KBD_SCROLLLOCK)
struct usb_kbd_pdata { + uint8_t new[8]; + uint8_t old[8]; + uint32_t repeat_delay;
uint32_t usb_in_pointer; uint32_t usb_out_pointer; uint8_t usb_kbd_buffer[USB_KBD_BUFFER_LEN];
- uint8_t new[8]; - uint8_t old[8]; - uint8_t flags; };
@@ -426,7 +426,7 @@ static int usb_kbd_probe(struct usb_device *dev, unsigned int ifnum)
USB_KBD_PRINTF("USB KBD: found set protocol...\n");
- data = malloc(sizeof(struct usb_kbd_pdata)); + data = memalign(USB_DMA_MINALIGN, sizeof(struct usb_kbd_pdata)); if (!data) { printf("USB KBD: Error allocating private data\n"); return 0;
Move environment settings for stdin/stdout/stderr to tegra-common-post.h and generate them automaticaly based on input device selection.
Signed-off-by: Allen Martin amartin@nvidia.com --- include/configs/seaboard.h | 5 ----- include/configs/tegra-common-post.h | 19 +++++++++++++++++++ include/configs/tegra20-common.h | 4 ---- 3 files changed, 19 insertions(+), 9 deletions(-)
diff --git a/include/configs/seaboard.h b/include/configs/seaboard.h index 0727a4c..2cb3ac9 100644 --- a/include/configs/seaboard.h +++ b/include/configs/seaboard.h @@ -98,11 +98,6 @@ #define CONFIG_TEGRA_KEYBOARD #define CONFIG_KEYBOARD
-#undef TEGRA_DEVICE_SETTINGS -#define TEGRA_DEVICE_SETTINGS "stdin=serial,tegra-kbc\0" \ - "stdout=serial\0" \ - "stderr=serial\0" - #include "tegra-common-post.h"
/* NAND support */ diff --git a/include/configs/tegra-common-post.h b/include/configs/tegra-common-post.h index 9698c23..8d21d9c 100644 --- a/include/configs/tegra-common-post.h +++ b/include/configs/tegra-common-post.h @@ -140,6 +140,25 @@
#endif
+#ifdef CONFIG_TEGRA_KEYBOARD +#define STDIN_KBD_KBC ",tegra-kbc" +#else +#define STDIN_KBD_KBC "" +#endif + +#ifdef CONFIG_USB_KEYBOARD +#define STDIN_KBD_USB ",usbkbd" +#define CONFIG_SYS_USB_EVENT_POLL +#define CONFIG_PREBOOT "usb start" +#else +#define STDIN_KBD_USB "" +#endif + +#define TEGRA_DEVICE_SETTINGS \ + "stdin=serial" STDIN_KBD_KBC STDIN_KBD_USB "\0" \ + "stdout=serial\0" \ + "stderr=serial\0" \ + #define CONFIG_EXTRA_ENV_SETTINGS \ TEGRA_DEVICE_SETTINGS \ "fdt_load=0x01000000\0" \ diff --git a/include/configs/tegra20-common.h b/include/configs/tegra20-common.h index dc7444d..ea89d76 100644 --- a/include/configs/tegra20-common.h +++ b/include/configs/tegra20-common.h @@ -125,12 +125,8 @@
#define CONFIG_SYS_NO_FLASH
-/* Environment information, boards can override if required */ #define CONFIG_CONSOLE_MUX #define CONFIG_SYS_CONSOLE_IS_IN_ENV -#define TEGRA_DEVICE_SETTINGS "stdin=serial\0" \ - "stdout=serial\0" \ - "stderr=serial\0"
#define CONFIG_LOADADDR 0x408000 /* def. location for kernel */ #define CONFIG_BOOTDELAY 2 /* -1 to disable auto boot */
Dear Allen Martin,
Move environment settings for stdin/stdout/stderr to tegra-common-post.h and generate them automaticaly based on input device selection.
Signed-off-by: Allen Martin amartin@nvidia.com
2/3 and 3/3 should go through tegra, thanks
include/configs/seaboard.h | 5 ----- include/configs/tegra-common-post.h | 19 +++++++++++++++++++ include/configs/tegra20-common.h | 4 ---- 3 files changed, 19 insertions(+), 9 deletions(-)
diff --git a/include/configs/seaboard.h b/include/configs/seaboard.h index 0727a4c..2cb3ac9 100644 --- a/include/configs/seaboard.h +++ b/include/configs/seaboard.h @@ -98,11 +98,6 @@ #define CONFIG_TEGRA_KEYBOARD #define CONFIG_KEYBOARD
-#undef TEGRA_DEVICE_SETTINGS -#define TEGRA_DEVICE_SETTINGS "stdin=serial,tegra-kbc\0" \
"stdout=serial\0" \"stderr=serial\0"#include "tegra-common-post.h"
/* NAND support */ diff --git a/include/configs/tegra-common-post.h b/include/configs/tegra-common-post.h index 9698c23..8d21d9c 100644 --- a/include/configs/tegra-common-post.h +++ b/include/configs/tegra-common-post.h @@ -140,6 +140,25 @@
#endif
+#ifdef CONFIG_TEGRA_KEYBOARD +#define STDIN_KBD_KBC ",tegra-kbc" +#else +#define STDIN_KBD_KBC "" +#endif
+#ifdef CONFIG_USB_KEYBOARD +#define STDIN_KBD_USB ",usbkbd" +#define CONFIG_SYS_USB_EVENT_POLL +#define CONFIG_PREBOOT "usb start" +#else +#define STDIN_KBD_USB "" +#endif
+#define TEGRA_DEVICE_SETTINGS \
- "stdin=serial" STDIN_KBD_KBC STDIN_KBD_USB "\0" \
- "stdout=serial\0" \
- "stderr=serial\0" \
#define CONFIG_EXTRA_ENV_SETTINGS \ TEGRA_DEVICE_SETTINGS \ "fdt_load=0x01000000\0" \ diff --git a/include/configs/tegra20-common.h b/include/configs/tegra20-common.h index dc7444d..ea89d76 100644 --- a/include/configs/tegra20-common.h +++ b/include/configs/tegra20-common.h @@ -125,12 +125,8 @@
#define CONFIG_SYS_NO_FLASH
-/* Environment information, boards can override if required */ #define CONFIG_CONSOLE_MUX #define CONFIG_SYS_CONSOLE_IS_IN_ENV -#define TEGRA_DEVICE_SETTINGS "stdin=serial\0" \
"stdout=serial\0" \"stderr=serial\0"#define CONFIG_LOADADDR 0x408000 /* def. location for
kernel */
#define CONFIG_BOOTDELAY 2 /* -1 to disable auto boot */
Best regards, Marek Vasut
On 10/23/2012 01:27 AM, Marek Vasut wrote:
Dear Allen Martin,
Move environment settings for stdin/stdout/stderr to tegra-common-post.h and generate them automaticaly based on input device selection.
Signed-off-by: Allen Martin amartin@nvidia.com
2/3 and 3/3 should go through tegra, thanks
Although of course patches 2 & 3 depend on patch 1. So, the process would have to be:
1) Apply patch 1 to USB tree. 2) Send pull request for USB to main U-Boot repo. 3) Pull request actioned. 4) Wait until latest u-boot/master is picked in u-boot/arm and hence u-boot/tegra. 5) Apply patches 2 & 3 to the Tegra tree.
That's quite a long round-trip. What's the typical delay between (1) and (2) or (3) and (4)?
In the Linux kernel, this would be handled by putting patch (1) into a topic branch on its own, which can then be merged into both the USB branch and immediately into Tegra's branch. Of course, that all relies on never rebasing during pull requests (otherwise, the branch with patch 1 might end up being applied as two different commits when merging into u-boot/master); something which apparently isn't acceptable for U-Boot:-(
Dear Stephen Warren,
On 10/23/2012 01:27 AM, Marek Vasut wrote:
Dear Allen Martin,
Move environment settings for stdin/stdout/stderr to tegra-common-post.h and generate them automaticaly based on input device selection.
Signed-off-by: Allen Martin amartin@nvidia.com
2/3 and 3/3 should go through tegra, thanks
Although of course patches 2 & 3 depend on patch 1. So, the process would have to be:
- Apply patch 1 to USB tree.
- Send pull request for USB to main U-Boot repo.
- Pull request actioned.
- Wait until latest u-boot/master is picked in u-boot/arm and hence
u-boot/tegra. 5) Apply patches 2 & 3 to the Tegra tree.
That's quite a long round-trip. What's the typical delay between (1) and (2) or (3) and (4)?
In the Linux kernel, this would be handled by putting patch (1) into a topic branch on its own, which can then be merged into both the USB branch and immediately into Tegra's branch. Of course, that all relies on never rebasing during pull requests (otherwise, the branch with patch 1 might end up being applied as two different commits when merging into u-boot/master); something which apparently isn't acceptable for U-Boot:-(
Fine, then if you agree, I'll pull them all through usb tree ?
Best regards, Marek Vasut
On 10/23/2012 04:01 PM, Marek Vasut wrote:
Dear Stephen Warren,
On 10/23/2012 01:27 AM, Marek Vasut wrote:
Dear Allen Martin,
Move environment settings for stdin/stdout/stderr to tegra-common-post.h and generate them automaticaly based on input device selection.
Signed-off-by: Allen Martin amartin@nvidia.com
2/3 and 3/3 should go through tegra, thanks
Although of course patches 2 & 3 depend on patch 1. So, the process would have to be:
- Apply patch 1 to USB tree.
- Send pull request for USB to main U-Boot repo.
- Pull request actioned.
- Wait until latest u-boot/master is picked in u-boot/arm and hence
u-boot/tegra. 5) Apply patches 2 & 3 to the Tegra tree.
That's quite a long round-trip. What's the typical delay between (1) and (2) or (3) and (4)?
In the Linux kernel, this would be handled by putting patch (1) into a topic branch on its own, which can then be merged into both the USB branch and immediately into Tegra's branch. Of course, that all relies on never rebasing during pull requests (otherwise, the branch with patch 1 might end up being applied as two different commits when merging into u-boot/master); something which apparently isn't acceptable for U-Boot:-(
Fine, then if you agree, I'll pull them all through usb tree ?
That's up to Tom Warren; he gets back from vacation in a couple days. Taking it all through the USB tree might not be best either, since there are merge conflicts with some Tegra patches that are already queued up, but I'll let Tom comment on what he wants to do.
On Tue, Oct 23, 2012 at 03:01:21PM -0700, Marek Vasut wrote:
Dear Stephen Warren,
On 10/23/2012 01:27 AM, Marek Vasut wrote:
Dear Allen Martin,
Move environment settings for stdin/stdout/stderr to tegra-common-post.h and generate them automaticaly based on input device selection.
Signed-off-by: Allen Martin amartin@nvidia.com
2/3 and 3/3 should go through tegra, thanks
Although of course patches 2 & 3 depend on patch 1. So, the process would have to be:
- Apply patch 1 to USB tree.
- Send pull request for USB to main U-Boot repo.
- Pull request actioned.
- Wait until latest u-boot/master is picked in u-boot/arm and hence
u-boot/tegra. 5) Apply patches 2 & 3 to the Tegra tree.
That's quite a long round-trip. What's the typical delay between (1) and (2) or (3) and (4)?
In the Linux kernel, this would be handled by putting patch (1) into a topic branch on its own, which can then be merged into both the USB branch and immediately into Tegra's branch. Of course, that all relies on never rebasing during pull requests (otherwise, the branch with patch 1 might end up being applied as two different commits when merging into u-boot/master); something which apparently isn't acceptable for U-Boot:-(
Fine, then if you agree, I'll pull them all through usb tree ?
That's fine by me. Tom is out on vacation right now anyway, so he wouldn't be able to pull them into the tegra tree until next week at the earliest anyway.
Best regards, Marek Vasut
-Allen
On Tue, Oct 23, 2012 at 03:01:21PM -0700, Marek Vasut wrote:
Dear Stephen Warren,
On 10/23/2012 01:27 AM, Marek Vasut wrote:
Dear Allen Martin,
Move environment settings for stdin/stdout/stderr to tegra-common-post.h and generate them automaticaly based on input device selection.
Signed-off-by: Allen Martin amartin@nvidia.com
2/3 and 3/3 should go through tegra, thanks
Although of course patches 2 & 3 depend on patch 1. So, the process would have to be:
- Apply patch 1 to USB tree.
- Send pull request for USB to main U-Boot repo.
- Pull request actioned.
- Wait until latest u-boot/master is picked in u-boot/arm and hence
u-boot/tegra. 5) Apply patches 2 & 3 to the Tegra tree.
That's quite a long round-trip. What's the typical delay between (1) and (2) or (3) and (4)?
In the Linux kernel, this would be handled by putting patch (1) into a topic branch on its own, which can then be merged into both the USB branch and immediately into Tegra's branch. Of course, that all relies on never rebasing during pull requests (otherwise, the branch with patch 1 might end up being applied as two different commits when merging into u-boot/master); something which apparently isn't acceptable for U-Boot:-(
Fine, then if you agree, I'll pull them all through usb tree ?
Hi Marek, I just wanted to check on that status of this series. Were you going to apply them to u-boot-usb ?
Thanks, -Allen
Dear Allen Martin,
On Tue, Oct 23, 2012 at 03:01:21PM -0700, Marek Vasut wrote:
Dear Stephen Warren,
On 10/23/2012 01:27 AM, Marek Vasut wrote:
Dear Allen Martin,
Move environment settings for stdin/stdout/stderr to tegra-common-post.h and generate them automaticaly based on input device selection.
Signed-off-by: Allen Martin amartin@nvidia.com
2/3 and 3/3 should go through tegra, thanks
Although of course patches 2 & 3 depend on patch 1. So, the process would have to be:
- Apply patch 1 to USB tree.
- Send pull request for USB to main U-Boot repo.
- Pull request actioned.
- Wait until latest u-boot/master is picked in u-boot/arm and hence
u-boot/tegra. 5) Apply patches 2 & 3 to the Tegra tree.
That's quite a long round-trip. What's the typical delay between (1) and (2) or (3) and (4)?
In the Linux kernel, this would be handled by putting patch (1) into a topic branch on its own, which can then be merged into both the USB branch and immediately into Tegra's branch. Of course, that all relies on never rebasing during pull requests (otherwise, the branch with patch 1 might end up being applied as two different commits when merging into u-boot/master); something which apparently isn't acceptable for U-Boot:-(
Fine, then if you agree, I'll pull them all through usb tree ?
Hi Marek, I just wanted to check on that status of this series. Were you going to apply them to u-boot-usb ?
Damn, I'll apply them ;-)
Best regards, Marek Vasut
On 10/22/2012 11:47 PM, Allen Martin wrote:
Move environment settings for stdin/stdout/stderr to tegra-common-post.h and generate them automaticaly based on input device selection.
Patches 2 and 3, Acked-by: Stephen Warren swarren@nvidia.com
Enable USB keyboard for seaboard and ventana
Signed-off-by: Allen Martin amartin@nvidia.com --- include/configs/seaboard.h | 3 +++ include/configs/ventana.h | 3 +++ 2 files changed, 6 insertions(+)
diff --git a/include/configs/seaboard.h b/include/configs/seaboard.h index 2cb3ac9..332970c 100644 --- a/include/configs/seaboard.h +++ b/include/configs/seaboard.h @@ -98,6 +98,9 @@ #define CONFIG_TEGRA_KEYBOARD #define CONFIG_KEYBOARD
+/* USB keyboard */ +#define CONFIG_USB_KEYBOARD + #include "tegra-common-post.h"
/* NAND support */ diff --git a/include/configs/ventana.h b/include/configs/ventana.h index b751d58..4c9b31c 100644 --- a/include/configs/ventana.h +++ b/include/configs/ventana.h @@ -75,6 +75,9 @@ #define CONFIG_CMD_NET #define CONFIG_CMD_DHCP
+/* USB keyboard */ +#define CONFIG_USB_KEYBOARD + #include "tegra-common-post.h"
#endif /* __CONFIG_H */
Dear Allen Martin,
Change usb_kbd driver to obey alignment requirements for USB DMA on the buffer used for data transfer. This is necessary for architectures that enable dcache and enable USB DMA.
Signed-off-by: Allen Martin amartin@nvidia.com
common/usb_kbd.c | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/common/usb_kbd.c b/common/usb_kbd.c index 19f01db..57928d9 100644 --- a/common/usb_kbd.c +++ b/common/usb_kbd.c @@ -106,15 +106,15 @@ static const unsigned char usb_kbd_num_keypad[] = { (USB_KBD_NUMLOCK | USB_KBD_CAPSLOCK | USB_KBD_SCROLLLOCK)
struct usb_kbd_pdata {
- uint8_t new[8];
- uint8_t old[8];
Some comment about the alignment won't hurt.
uint32_t repeat_delay;
uint32_t usb_in_pointer; uint32_t usb_out_pointer; uint8_t usb_kbd_buffer[USB_KBD_BUFFER_LEN];
- uint8_t new[8];
- uint8_t old[8];
- uint8_t flags;
};
@@ -426,7 +426,7 @@ static int usb_kbd_probe(struct usb_device *dev, unsigned int ifnum)
USB_KBD_PRINTF("USB KBD: found set protocol...\n");
- data = malloc(sizeof(struct usb_kbd_pdata));
- data = memalign(USB_DMA_MINALIGN, sizeof(struct usb_kbd_pdata));
Don't we have ALLOC_CACHE_ALIGN_BUFFER and such stuff in include/common.h for this purpose ?
if (!data) { printf("USB KBD: Error allocating private data\n"); return 0;
Best regards, Marek Vasut
On 10/23/2012 01:26 AM, Marek Vasut wrote:
Dear Allen Martin,
Change usb_kbd driver to obey alignment requirements for USB DMA on the buffer used for data transfer. This is necessary for architectures that enable dcache and enable USB DMA.
@@ -426,7 +426,7 @@ static int usb_kbd_probe(struct usb_device *dev, unsigned int ifnum)
USB_KBD_PRINTF("USB KBD: found set protocol...\n");
- data = malloc(sizeof(struct usb_kbd_pdata));
- data = memalign(USB_DMA_MINALIGN, sizeof(struct usb_kbd_pdata));
Don't we have ALLOC_CACHE_ALIGN_BUFFER and such stuff in include/common.h for this purpose ?
That's for stack-based data structures, whereas this data structure sticks around for more than the duration of this function.
On Tue, Oct 23, 2012 at 12:26:31AM -0700, Marek Vasut wrote:
Dear Allen Martin,
Change usb_kbd driver to obey alignment requirements for USB DMA on the buffer used for data transfer. This is necessary for architectures that enable dcache and enable USB DMA.
Signed-off-by: Allen Martin amartin@nvidia.com
common/usb_kbd.c | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/common/usb_kbd.c b/common/usb_kbd.c index 19f01db..57928d9 100644 --- a/common/usb_kbd.c +++ b/common/usb_kbd.c @@ -106,15 +106,15 @@ static const unsigned char usb_kbd_num_keypad[] = { (USB_KBD_NUMLOCK | USB_KBD_CAPSLOCK | USB_KBD_SCROLLLOCK)
struct usb_kbd_pdata {
- uint8_t new[8];
- uint8_t old[8];
Some comment about the alignment won't hurt.
Good idea.
uint32_t repeat_delay;
uint32_t usb_in_pointer; uint32_t usb_out_pointer; uint8_t usb_kbd_buffer[USB_KBD_BUFFER_LEN];
- uint8_t new[8];
- uint8_t old[8];
- uint8_t flags;
};
@@ -426,7 +426,7 @@ static int usb_kbd_probe(struct usb_device *dev, unsigned int ifnum)
USB_KBD_PRINTF("USB KBD: found set protocol...\n");
- data = malloc(sizeof(struct usb_kbd_pdata));
- data = memalign(USB_DMA_MINALIGN, sizeof(struct usb_kbd_pdata));
Don't we have ALLOC_CACHE_ALIGN_BUFFER and such stuff in include/common.h for this purpose ?
There seems to be some discrepency here, because ehci-hcd.c uses USB_DMA_MINALIGN for all cache operations, which may or may not be the same as ARCH_DMA_MINALIGN, see usb.h:
/* * The EHCI spec says that we must align to at least 32 bytes. However, * some platforms require larger alignment. */ #if ARCH_DMA_MINALIGN > 32 #define USB_DMA_MINALIGN ARCH_DMA_MINALIGN #else #define USB_DMA_MINALIGN 32 #endif
For tegra this is fine, because ARCH_DMA_MINALIGN > 32, but grepping through header files, I see a few:
#define ARCH_DMA_MINALIGN 16
which will definately break. It looks like all other usb class drivers use ALLOC_CACHE_ALIGN_BUFFER() though, so for consistency the usb keyboard driver probably should too, but it seems like a potential problem.
if (!data) { printf("USB KBD: Error allocating private data\n"); return 0;
Best regards, Marek Vasut
-Allen
Dear Allen Martin,
On Tue, Oct 23, 2012 at 12:26:31AM -0700, Marek Vasut wrote:
Dear Allen Martin,
Change usb_kbd driver to obey alignment requirements for USB DMA on the buffer used for data transfer. This is necessary for architectures that enable dcache and enable USB DMA.
Signed-off-by: Allen Martin amartin@nvidia.com
common/usb_kbd.c | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/common/usb_kbd.c b/common/usb_kbd.c index 19f01db..57928d9 100644 --- a/common/usb_kbd.c +++ b/common/usb_kbd.c @@ -106,15 +106,15 @@ static const unsigned char usb_kbd_num_keypad[] = {
(USB_KBD_NUMLOCK | USB_KBD_CAPSLOCK | USB_KBD_SCROLLLOCK)
struct usb_kbd_pdata {
- uint8_t new[8];
- uint8_t old[8];
Some comment about the alignment won't hurt.
Good idea.
uint32_t repeat_delay;
uint32_t usb_in_pointer; uint32_t usb_out_pointer; uint8_t usb_kbd_buffer[USB_KBD_BUFFER_LEN];
uint8_t new[8];
uint8_t old[8];
uint8_t flags;
};
@@ -426,7 +426,7 @@ static int usb_kbd_probe(struct usb_device *dev, unsigned int ifnum)
USB_KBD_PRINTF("USB KBD: found set protocol...\n");
- data = malloc(sizeof(struct usb_kbd_pdata));
- data = memalign(USB_DMA_MINALIGN, sizeof(struct usb_kbd_pdata));
Don't we have ALLOC_CACHE_ALIGN_BUFFER and such stuff in include/common.h for this purpose ?
There seems to be some discrepency here, because ehci-hcd.c uses USB_DMA_MINALIGN for all cache operations, which may or may not be the same as ARCH_DMA_MINALIGN, see usb.h:
/*
- The EHCI spec says that we must align to at least 32 bytes.
However,
- some platforms require larger alignment.
*/ #if ARCH_DMA_MINALIGN > 32 #define USB_DMA_MINALIGN ARCH_DMA_MINALIGN #else #define USB_DMA_MINALIGN 32 #endif
For tegra this is fine, because ARCH_DMA_MINALIGN > 32, but grepping through header files, I see a few:
#define ARCH_DMA_MINALIGN 16
which will definately break. It looks like all other usb class drivers use ALLOC_CACHE_ALIGN_BUFFER() though, so for consistency the usb keyboard driver probably should too, but it seems like a potential problem.
ALLOC_CACHE_ALIGN_BUFFER is what I had in mind, I think the EHCI driver already uses this.
if (!data) {
printf("USB KBD: Error allocating private data\n"); return 0;Best regards, Marek Vasut
-Allen
Best regards, Marek Vasut
On 10/22/2012 11:47 PM, Allen Martin wrote:
Change usb_kbd driver to obey alignment requirements for USB DMA on the buffer used for data transfer. This is necessary for architectures that enable dcache and enable USB DMA.
The series, Tested-by: Stephen Warren swarren@nvidia.com
BTW, I tested tegra-kbc too, and that does indeed currently work (at least in my local dev branch based on u-boot/master).
Note that patch 2 has a merge conflict with the following patch in u-boot-tegra/next, since I assume your series is based on u-boot/master not u-boot-tegra/next:
799f182 ARM: tegra: use standard variables to define load addresses
It's pretty simple to resolve though.
On Tue, Oct 23, 2012 at 09:51:06AM -0700, Stephen Warren wrote:
On 10/22/2012 11:47 PM, Allen Martin wrote:
Change usb_kbd driver to obey alignment requirements for USB DMA on the buffer used for data transfer. This is necessary for architectures that enable dcache and enable USB DMA.
The series, Tested-by: Stephen Warren swarren@nvidia.com
BTW, I tested tegra-kbc too, and that does indeed currently work (at least in my local dev branch based on u-boot/master).
Yes, I also tried on a seaboard with internal keyboard and it works, although once the USB keyboard driver loads the internal keyboard stops working. I haven't tracked down why, but it seems like a bug I can live with for now as seaboards with internal keyboards are pretty rare these days, and how many keyboards do you need in u-boot anyway? :^)
Note that patch 2 has a merge conflict with the following patch in u-boot-tegra/next, since I assume your series is based on u-boot/master not u-boot-tegra/next:
799f182 ARM: tegra: use standard variables to define load addresses
It's pretty simple to resolve though.
Yes, I based it on u-boot/master, once we figure out what trees each patch is destined for I'll rebase appropriately.
-Allen
Dear Allen Martin,
On Tue, Oct 23, 2012 at 09:51:06AM -0700, Stephen Warren wrote:
On 10/22/2012 11:47 PM, Allen Martin wrote:
Change usb_kbd driver to obey alignment requirements for USB DMA on the buffer used for data transfer. This is necessary for architectures that enable dcache and enable USB DMA.
The series, Tested-by: Stephen Warren swarren@nvidia.com
BTW, I tested tegra-kbc too, and that does indeed currently work (at least in my local dev branch based on u-boot/master).
Yes, I also tried on a seaboard with internal keyboard and it works, although once the USB keyboard driver loads the internal keyboard stops working. I haven't tracked down why, but it seems like a bug I can live with for now as seaboards with internal keyboards are pretty rare these days, and how many keyboards do you need in u-boot anyway?
Good thing you pointed it out. Please let's not ignore a bug. How come it happens? What happens if you have two usb keyboards connected?
:^) :
Note that patch 2 has a merge conflict with the following patch in u-boot-tegra/next, since I assume your series is based on u-boot/master not u-boot-tegra/next:
799f182 ARM: tegra: use standard variables to define load addresses
It's pretty simple to resolve though.
Yes, I based it on u-boot/master, once we figure out what trees each patch is destined for I'll rebase appropriately.
I pushed u-boot-usb/master today, can you check if it still applies ?
Best regards, Marek Vasut
On Tue, Oct 23, 2012 at 03:03:34PM -0700, Marek Vasut wrote:
Dear Allen Martin,
On Tue, Oct 23, 2012 at 09:51:06AM -0700, Stephen Warren wrote:
On 10/22/2012 11:47 PM, Allen Martin wrote:
Change usb_kbd driver to obey alignment requirements for USB DMA on the buffer used for data transfer. This is necessary for architectures that enable dcache and enable USB DMA.
The series, Tested-by: Stephen Warren swarren@nvidia.com
BTW, I tested tegra-kbc too, and that does indeed currently work (at least in my local dev branch based on u-boot/master).
Yes, I also tried on a seaboard with internal keyboard and it works, although once the USB keyboard driver loads the internal keyboard stops working. I haven't tracked down why, but it seems like a bug I can live with for now as seaboards with internal keyboards are pretty rare these days, and how many keyboards do you need in u-boot anyway?
Good thing you pointed it out. Please let's not ignore a bug. How come it happens? What happens if you have two usb keyboards connected?
I'm pretty sure the USB keyboard driver doesn't support multiple devices, I see this in drv_usb_kbd_init():
/* We found a keyboard, check if it is already registered. */ USB_KBD_PRINTF("USB KBD: found set up device.\n"); old_dev = stdio_get_by_name(DEVNAME); if (old_dev) { /* Already registered, just return ok. */ USB_KBD_PRINTF("USB KBD: is already registered.\n"); return 1; }
The bug is almost certainly inside the tegra kbd driver, which is why I'm not terribly concerned about it. The only boards that use that driver are inside NVIDIA, and even those are rare.
:^) :
Note that patch 2 has a merge conflict with the following patch in u-boot-tegra/next, since I assume your series is based on u-boot/master not u-boot-tegra/next:
799f182 ARM: tegra: use standard variables to define load addresses
It's pretty simple to resolve though.
Yes, I based it on u-boot/master, once we figure out what trees each patch is destined for I'll rebase appropriately.
I pushed u-boot-usb/master today, can you check if it still applies ?
Yes, it still applies cleanly to u-boot-usb/master
Best regards, Marek Vasut
-Allen
On Tue, Oct 23, 2012 at 05:39:50PM -0700, Allen Martin wrote:
On Tue, Oct 23, 2012 at 03:03:34PM -0700, Marek Vasut wrote:
Dear Allen Martin,
On Tue, Oct 23, 2012 at 09:51:06AM -0700, Stephen Warren wrote:
On 10/22/2012 11:47 PM, Allen Martin wrote:
Change usb_kbd driver to obey alignment requirements for USB DMA on the buffer used for data transfer. This is necessary for architectures that enable dcache and enable USB DMA.
The series, Tested-by: Stephen Warren swarren@nvidia.com
BTW, I tested tegra-kbc too, and that does indeed currently work (at least in my local dev branch based on u-boot/master).
Yes, I also tried on a seaboard with internal keyboard and it works, although once the USB keyboard driver loads the internal keyboard stops working. I haven't tracked down why, but it seems like a bug I can live with for now as seaboards with internal keyboards are pretty rare these days, and how many keyboards do you need in u-boot anyway?
Good thing you pointed it out. Please let's not ignore a bug. How come it happens? What happens if you have two usb keyboards connected?
I'm pretty sure the USB keyboard driver doesn't support multiple devices, I see this in drv_usb_kbd_init():
/* We found a keyboard, check if it is already registered. */ USB_KBD_PRINTF("USB KBD: found set up device.\n"); old_dev = stdio_get_by_name(DEVNAME); if (old_dev) { /* Already registered, just return ok. */ USB_KBD_PRINTF("USB KBD: is already registered.\n"); return 1; }The bug is almost certainly inside the tegra kbd driver, which is why I'm not terribly concerned about it. The only boards that use that driver are inside NVIDIA, and even those are rare.
Ok, I dug into the driver code a little. It's because the tegra keyboard driver doesn't support CONSOLE_MUX, so when the USB keyboard calls into iomux it takes away stdin from the tegra kbd driver, and it has no way of ever getting it back. Definately a bug, but unrelated to this change.
-Allen
Dear Allen Martin,
On Tue, Oct 23, 2012 at 03:03:34PM -0700, Marek Vasut wrote:
Dear Allen Martin,
On Tue, Oct 23, 2012 at 09:51:06AM -0700, Stephen Warren wrote:
On 10/22/2012 11:47 PM, Allen Martin wrote:
Change usb_kbd driver to obey alignment requirements for USB DMA on the buffer used for data transfer. This is necessary for architectures that enable dcache and enable USB DMA.
The series, Tested-by: Stephen Warren swarren@nvidia.com
BTW, I tested tegra-kbc too, and that does indeed currently work (at least in my local dev branch based on u-boot/master).
Yes, I also tried on a seaboard with internal keyboard and it works, although once the USB keyboard driver loads the internal keyboard stops working. I haven't tracked down why, but it seems like a bug I can live with for now as seaboards with internal keyboards are pretty rare these days, and how many keyboards do you need in u-boot anyway?
Good thing you pointed it out. Please let's not ignore a bug. How come it happens? What happens if you have two usb keyboards connected?
I'm pretty sure the USB keyboard driver doesn't support multiple devices, I see this in drv_usb_kbd_init():
/* We found a keyboard, check if it is already registered. */ USB_KBD_PRINTF("USB KBD: found set up device.\n"); old_dev = stdio_get_by_name(DEVNAME); if (old_dev) { /* Already registered, just return ok. */ USB_KBD_PRINTF("USB KBD: is already registered.\n"); return 1; }The bug is almost certainly inside the tegra kbd driver, which is why I'm not terribly concerned about it. The only boards that use that driver are inside NVIDIA, and even those are rare.
[...]
Good, now please fix the bug. I'm terribly unhappy seeing there is a bug that is about to go unfixed.
Best regards, Marek Vasut
On Wed, Oct 24, 2012 at 12:31:40AM -0700, Marek Vasut wrote:
Dear Allen Martin,
On Tue, Oct 23, 2012 at 03:03:34PM -0700, Marek Vasut wrote:
Dear Allen Martin,
On Tue, Oct 23, 2012 at 09:51:06AM -0700, Stephen Warren wrote:
On 10/22/2012 11:47 PM, Allen Martin wrote:
Change usb_kbd driver to obey alignment requirements for USB DMA on the buffer used for data transfer. This is necessary for architectures that enable dcache and enable USB DMA.
The series, Tested-by: Stephen Warren swarren@nvidia.com
BTW, I tested tegra-kbc too, and that does indeed currently work (at least in my local dev branch based on u-boot/master).
Yes, I also tried on a seaboard with internal keyboard and it works, although once the USB keyboard driver loads the internal keyboard stops working. I haven't tracked down why, but it seems like a bug I can live with for now as seaboards with internal keyboards are pretty rare these days, and how many keyboards do you need in u-boot anyway?
Good thing you pointed it out. Please let's not ignore a bug. How come it happens? What happens if you have two usb keyboards connected?
I'm pretty sure the USB keyboard driver doesn't support multiple devices, I see this in drv_usb_kbd_init():
/* We found a keyboard, check if it is already registered. */ USB_KBD_PRINTF("USB KBD: found set up device.\n"); old_dev = stdio_get_by_name(DEVNAME); if (old_dev) { /* Already registered, just return ok. */ USB_KBD_PRINTF("USB KBD: is already registered.\n"); return 1; }The bug is almost certainly inside the tegra kbd driver, which is why I'm not terribly concerned about it. The only boards that use that driver are inside NVIDIA, and even those are rare.
[...]
Good, now please fix the bug. I'm terribly unhappy seeing there is a bug that is about to go unfixed.
I didn't say the bug will go unfixed, I've opened an issue in our internal bug tracker so it doesn't go forgotten. It's just a matter of prioritization. It's just not important to fix a corner case bug in a driver that noone outside of NVIDIA can actually use when there are major functionality holes and regressions (like your change to serial_assign() that broke serial output on tegra). I only work on u-boot on the side, so I have to pick my battles carefully.
-Allen
Dear Allen Martin,
[...]
[...]
Good, now please fix the bug. I'm terribly unhappy seeing there is a bug that is about to go unfixed.
I didn't say the bug will go unfixed, I've opened an issue in our internal bug tracker so it doesn't go forgotten. It's just a matter of prioritization.
Yes, the bug is really simple to fix, so instead of arguing, please get to work. It could have been fixed already!
It's just not important to fix a corner case bug
I'm sorry, I really need to be careful with wording here. I'm always baffled how an engineer can ignore a bug.
in a driver that noone outside of NVIDIA can actually use when there are major functionality holes and regressions (like your change to serial_assign() that broke serial output on tegra).
Stop being personal, this hurts and doesn't help. Care to send a patch for this? I don't have a working tegra setup (yet), but you can test this. I already outlined the fix, so it's just a matter to implement it.
I only work on u-boot on the side, so I have to pick my battles carefully.
I'm glad for any contribution from your end, don't be mistaken. I really appreciate it, sorry if my working is sometimes way too blunt or heartless.
-Allen
Best regards, Marek Vasut
On 10/24/2012 02:17 PM, Marek Vasut wrote:
Dear Allen Martin,
[...]
[...]
Good, now please fix the bug. I'm terribly unhappy seeing there is a bug that is about to go unfixed.
I didn't say the bug will go unfixed, I've opened an issue in our internal bug tracker so it doesn't go forgotten. It's just a matter of prioritization.
Yes, the bug is really simple to fix, so instead of arguing, please get to work. It could have been fixed already!
I'm sorry, but that's not a constructive response. If you want it fixed so badly, I'm sure we'd gratefully receive a patch from you for it.
As Allen pointed out, there are currently more important issues to concentrate on, such as Tegra not booting at all. I'm sure that once we've made the system work at all, then we can concentrate on the minor use-cases that simply aren't causing anyone any problems right now.
participants (3)
-
Allen Martin -
Marek Vasut -
Stephen Warren