subject:"\[linux\-usb\-devel\] \[RFC\]\[PATCH 0\/2\] x86

Re: [LinuxBIOS] [linux-usb-devel] [RFC][PATCH 0/2] x86_64 Early usb debug port support.

2006-12-13 Thread Yinghai Lu


wakeup_level4_pgt need to be updated in addtion to boot_level4_pgt?

also comment could be updated for good unstanding too.

YH
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [LinuxBIOS] [linux-usb-devel] [RFC][PATCH 0/2] x86_64 Early usb debug port support.

2006-12-13 Thread Yinghai Lu


On 12/12/06, Eric W. Biederman <[EMAIL PROTECTED]> wrote:

diff --git a/arch/x86_64/kernel/head.S b/arch/x86_64/kernel/head.S
index 1e6f808..2f65469 100644
--- a/arch/x86_64/kernel/head.S
+++ b/arch/x86_64/kernel/head.S
@@ -328,9 +328,9 @@ ENTRY(wakeup_level4_pgt)
.align PAGE_SIZE
 ENTRY(boot_level4_pgt)
.quad   phys_level3_ident_pgt | 0x007
-   .fill   255,8,0
+   .fill   257,8,0
.quad   phys_level3_physmem_pgt | 0x007
-   .fill   254,8,0
+   .fill   252,8,0
/* (2^48-(2*1024*1024*1024))/(2^39) = 511 */
.quad   phys_level3_kernel_pgt | 0x007



Good, it seems __PAGE_OFFSET used to be 0xfff8000
and then 1<<40, and then 0xfff8100

YH
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [LinuxBIOS] [linux-usb-devel] [RFC][PATCH 0/2] x86_64 Early usb debug port support.

2006-12-13 Thread Yinghai Lu


On 12/12/06, Eric W. Biederman [EMAIL PROTECTED] wrote:

diff --git a/arch/x86_64/kernel/head.S b/arch/x86_64/kernel/head.S
index 1e6f808..2f65469 100644
--- a/arch/x86_64/kernel/head.S
+++ b/arch/x86_64/kernel/head.S
@@ -328,9 +328,9 @@ ENTRY(wakeup_level4_pgt)
.align PAGE_SIZE
 ENTRY(boot_level4_pgt)
.quad   phys_level3_ident_pgt | 0x007
-   .fill   255,8,0
+   .fill   257,8,0
.quad   phys_level3_physmem_pgt | 0x007
-   .fill   254,8,0
+   .fill   252,8,0
/* (2^48-(2*1024*1024*1024))/(2^39) = 511 */
.quad   phys_level3_kernel_pgt | 0x007



Good, it seems __PAGE_OFFSET used to be 0xfff8000
and then 140, and then 0xfff8100

YH
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [LinuxBIOS] [linux-usb-devel] [RFC][PATCH 0/2] x86_64 Early usb debug port support.

2006-12-13 Thread Yinghai Lu


wakeup_level4_pgt need to be updated in addtion to boot_level4_pgt?

also comment could be updated for good unstanding too.

YH
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [LinuxBIOS] [linux-usb-devel] [RFC][PATCH 0/2] x86_64 Early usb debug port support.

2006-12-12 Thread Eric W. Biederman

"Yinghai Lu" <[EMAIL PROTECTED]> writes:

> On 12/8/06, Eric W. Biederman <[EMAIL PROTECTED]> wrote:
>>
>> Your or I missed a bug fix/enhancement in there somewhere.
>>
>
> I found the problem. the __set_fixmap need to __va, so the entries
> will be referred from PAGE_OFFSET.
>
> solution will be
> 1. move enable_dbgp_console from setup_early_printk, and call it from
> setup_arch after init_memory_mapping.
> 2. or make __set_fixmap can use __pa or pa()+__START_KERNEL_map in
> addtion to _va.

3.  Make __va always work.  I had this in my tree and I guess it didn't get
   into my big rollup patch.

Eric


x86_64: Fix the memory mapping in the early page table

diff --git a/arch/x86_64/kernel/head.S b/arch/x86_64/kernel/head.S
index 1e6f808..2f65469 100644
--- a/arch/x86_64/kernel/head.S
+++ b/arch/x86_64/kernel/head.S
@@ -328,9 +328,9 @@ ENTRY(wakeup_level4_pgt)
.align PAGE_SIZE
 ENTRY(boot_level4_pgt)
.quad   phys_level3_ident_pgt | 0x007
-   .fill   255,8,0
+   .fill   257,8,0
.quad   phys_level3_physmem_pgt | 0x007
-   .fill   254,8,0
+   .fill   252,8,0
/* (2^48-(2*1024*1024*1024))/(2^39) = 511 */
.quad   phys_level3_kernel_pgt | 0x007
 


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [LinuxBIOS] [linux-usb-devel] [RFC][PATCH 0/2] x86_64 Early usb debug port support.

2006-12-12 Thread Yinghai Lu


On 12/8/06, Eric W. Biederman <[EMAIL PROTECTED]> wrote:


Your or I missed a bug fix/enhancement in there somewhere.



I found the problem. the __set_fixmap need to __va, so the entries
will be referred from PAGE_OFFSET.

solution will be
1. move enable_dbgp_console from setup_early_printk, and call it from
setup_arch after init_memory_mapping.
2. or make __set_fixmap can use __pa or pa()+__START_KERNEL_map in
addtion to _va.

please check attached updated patch that is your patch plus 1.

YH
diff --git a/arch/i386/kernel/head.S b/arch/i386/kernel/head.S
index edef508..c8b1ec9 100644
--- a/arch/i386/kernel/head.S
+++ b/arch/i386/kernel/head.S
@@ -141,6 +141,12 @@ page_pde_offset = (__PAGE_OFFSET >> 20);
 	jb 10b
 	movl %edi,(init_pg_tables_end - __PAGE_OFFSET)
 
+	/* Do an early initialization of the fixmap area */
+	movl $(swapper_pg_dir - __PAGE_OFFSET), %edx
+	movl $(swapper_pg_pmd - __PAGE_OFFSET), %eax
+	addl $0x007, %eax			/* 0x007 = PRESENT+RW+USER */
+	movl %eax, 4092(%edx)
+
 #ifdef CONFIG_SMP
 	xorl %ebx,%ebx/* This is the boot CPU (BSP) */
 	jmp 3f
@@ -531,6 +537,8 @@ ENTRY(_stext)
 .section ".bss.page_aligned","w"
 ENTRY(swapper_pg_dir)
 	.fill 1024,4,0
+ENTRY(swapper_pg_pmd)
+	.fill 1024,4,0	
 ENTRY(empty_zero_page)
 	.fill 4096,1,0
 
diff --git a/arch/x86_64/kernel/early_printk.c b/arch/x86_64/kernel/early_printk.c
index 47b6d90..8b4c6f4 100644
--- a/arch/x86_64/kernel/early_printk.c
+++ b/arch/x86_64/kernel/early_printk.c
@@ -3,9 +3,19 @@
 #include 
 #include 
 #include 
+#include 
+#include 
+#include 
+#include 
 #include 
 #include 
 #include 
+#include 
+#include 
+#include 
+#define EARLY_PRINTK
+#include "../../../drivers/usb/host/ehci.h"
+
 
 /* Simple VGA output */
 
@@ -156,6 +166,562 @@ static struct console early_serial_console = {
 	.index =	-1,
 };
 
+
+static struct ehci_caps __iomem *ehci_caps;
+static struct ehci_regs __iomem *ehci_regs;
+static struct ehci_dbg_port __iomem *ehci_debug;
+static unsigned dbgp_endpoint_out;
+
+#define USB_DEBUG_DEVNUM 127
+
+#define DBGP_DATA_TOGGLE	0x8800
+#define DBGP_PID_UPDATE(x, tok) \
+	x) ^ DBGP_DATA_TOGGLE) & 0x00) | ((tok) & 0xff))
+
+#define DBGP_LEN_UPDATE(x, len) (((x) & ~0x0f) | ((len) & 0x0f))
+/*
+ * USB Packet IDs (PIDs)
+ */
+
+/* token */
+#define USB_PID_OUT		0xe1
+#define USB_PID_IN		0x69
+#define USB_PID_SOF		0xa5
+#define USB_PID_SETUP		0x2d
+/* handshake */
+#define USB_PID_ACK		0xd2
+#define USB_PID_NAK		0x5a
+#define USB_PID_STALL		0x1e
+#define USB_PID_NYET		0x96
+/* data */
+#define USB_PID_DATA0		0xc3
+#define USB_PID_DATA1		0x4b
+#define USB_PID_DATA2		0x87
+#define USB_PID_MDATA		0x0f
+/* Special */
+#define USB_PID_PREAMBLE	0x3c
+#define USB_PID_ERR		0x3c
+#define USB_PID_SPLIT		0x78
+#define USB_PID_PING		0xb4
+#define USB_PID_UNDEF_0		0xf0
+
+#define USB_PID_DATA_TOGGLE	0x88
+#define DBGP_CLAIM (DBGP_OWNER | DBGP_ENABLED | DBGP_INUSE)
+
+#define PCI_CAP_ID_EHCI_DEBUG	0xa
+
+#define HUB_ROOT_RESET_TIME	50	/* times are in msec */
+#define HUB_SHORT_RESET_TIME	10
+#define HUB_LONG_RESET_TIME	200
+#define HUB_RESET_TIMEOUT	500
+
+#define DBGP_MAX_PACKET		8
+
+static int dbgp_wait_until_complete(void)
+{
+	unsigned ctrl;
+	for (;;) {
+		ctrl = readl(_debug->control);
+		/* Stop when the transaction is finished */
+		if (ctrl & DBGP_DONE)
+			break;
+	}
+	/* Now that we have observed the completed transaction,
+	 * clear the done bit.
+	 */
+	writel(ctrl | DBGP_DONE, _debug->control);
+	return (ctrl & DBGP_ERROR) ? -DBGP_ERRCODE(ctrl) : DBGP_LEN(ctrl);
+}
+
+static void dbgp_mdelay(int ms)
+{
+	int i;
+	while (ms--) {
+		for (i = 0; i < 1000; i++)
+			outb(0x1, 0x80);
+	}
+}
+
+static void dbgp_breath(void)
+{
+	/* Sleep to give the debug port a chance to breathe */
+}
+
+static int dbgp_wait_until_done(unsigned ctrl)
+{
+	unsigned pids, lpid;
+	int ret;
+
+retry:
+	writel(ctrl | DBGP_GO, _debug->control);
+	ret = dbgp_wait_until_complete();
+	pids = readl(_debug->pids);
+	lpid = DBGP_PID_GET(pids);
+
+	if (ret < 0)
+		return ret;
+
+	/* If the port is getting full or it has dropped data
+	 * start pacing ourselves, not necessary but it's friendly.
+	 */
+	if ((lpid == USB_PID_NAK) || (lpid == USB_PID_NYET))
+		dbgp_breath();
+	
+	/* If I get a NACK reissue the transmission */
+	if (lpid == USB_PID_NAK)
+		goto retry;
+
+	return ret;
+}
+
+static void dbgp_set_data(const void *buf, int size)
+{
+	const unsigned char *bytes = buf;
+	unsigned lo, hi;
+	int i;
+	lo = hi = 0;
+	for (i = 0; i < 4 && i < size; i++)
+		lo |= bytes[i] << (8*i);
+	for (; i < 8 && i < size; i++)
+		hi |= bytes[i] << (8*(i - 4));
+	writel(lo, _debug->data03);
+	writel(hi, _debug->data47);
+}
+
+static void dbgp_get_data(void *buf, int size)
+{
+	unsigned char *bytes = buf;
+	unsigned lo, hi;
+	int i;
+	lo = readl(_debug->data03);
+	hi = readl(_debug->data47);
+	for (i = 0; i < 4 && i < size; i++)
+		bytes[i] = (lo >> (8*i)) & 0xff;
+	for (; i < 8 && i < size; i++)
+		bytes[i] = (hi >> (8*(i - 4))) & 0xff;
+}
+
+static int

Re: [LinuxBIOS] [linux-usb-devel] [RFC][PATCH 0/2] x86_64 Early usb debug port support.

2006-12-12 Thread Yinghai Lu


On 12/8/06, Eric W. Biederman [EMAIL PROTECTED] wrote:


Your or I missed a bug fix/enhancement in there somewhere.



I found the problem. the __set_fixmap need to __va, so the entries
will be referred from PAGE_OFFSET.

solution will be
1. move enable_dbgp_console from setup_early_printk, and call it from
setup_arch after init_memory_mapping.
2. or make __set_fixmap can use __pa or pa()+__START_KERNEL_map in
addtion to _va.

please check attached updated patch that is your patch plus 1.

YH
diff --git a/arch/i386/kernel/head.S b/arch/i386/kernel/head.S
index edef508..c8b1ec9 100644
--- a/arch/i386/kernel/head.S
+++ b/arch/i386/kernel/head.S
@@ -141,6 +141,12 @@ page_pde_offset = (__PAGE_OFFSET  20);
 	jb 10b
 	movl %edi,(init_pg_tables_end - __PAGE_OFFSET)
 
+	/* Do an early initialization of the fixmap area */
+	movl $(swapper_pg_dir - __PAGE_OFFSET), %edx
+	movl $(swapper_pg_pmd - __PAGE_OFFSET), %eax
+	addl $0x007, %eax			/* 0x007 = PRESENT+RW+USER */
+	movl %eax, 4092(%edx)
+
 #ifdef CONFIG_SMP
 	xorl %ebx,%ebx/* This is the boot CPU (BSP) */
 	jmp 3f
@@ -531,6 +537,8 @@ ENTRY(_stext)
 .section .bss.page_aligned,w
 ENTRY(swapper_pg_dir)
 	.fill 1024,4,0
+ENTRY(swapper_pg_pmd)
+	.fill 1024,4,0	
 ENTRY(empty_zero_page)
 	.fill 4096,1,0
 
diff --git a/arch/x86_64/kernel/early_printk.c b/arch/x86_64/kernel/early_printk.c
index 47b6d90..8b4c6f4 100644
--- a/arch/x86_64/kernel/early_printk.c
+++ b/arch/x86_64/kernel/early_printk.c
@@ -3,9 +3,19 @@
 #include linux/init.h
 #include linux/string.h
 #include linux/screen_info.h
+#include linux/usb_ch9.h
+#include linux/pci_regs.h
+#include linux/pci_ids.h
+#include linux/errno.h
 #include asm/io.h
 #include asm/processor.h
 #include asm/fcntl.h
+#include asm/pci-direct.h
+#include asm/pgtable.h
+#include asm/fixmap.h
+#define EARLY_PRINTK
+#include ../../../drivers/usb/host/ehci.h
+
 
 /* Simple VGA output */
 
@@ -156,6 +166,562 @@ static struct console early_serial_console = {
 	.index =	-1,
 };
 
+
+static struct ehci_caps __iomem *ehci_caps;
+static struct ehci_regs __iomem *ehci_regs;
+static struct ehci_dbg_port __iomem *ehci_debug;
+static unsigned dbgp_endpoint_out;
+
+#define USB_DEBUG_DEVNUM 127
+
+#define DBGP_DATA_TOGGLE	0x8800
+#define DBGP_PID_UPDATE(x, tok) \
+	x) ^ DBGP_DATA_TOGGLE)  0x00) | ((tok)  0xff))
+
+#define DBGP_LEN_UPDATE(x, len) (((x)  ~0x0f) | ((len)  0x0f))
+/*
+ * USB Packet IDs (PIDs)
+ */
+
+/* token */
+#define USB_PID_OUT		0xe1
+#define USB_PID_IN		0x69
+#define USB_PID_SOF		0xa5
+#define USB_PID_SETUP		0x2d
+/* handshake */
+#define USB_PID_ACK		0xd2
+#define USB_PID_NAK		0x5a
+#define USB_PID_STALL		0x1e
+#define USB_PID_NYET		0x96
+/* data */
+#define USB_PID_DATA0		0xc3
+#define USB_PID_DATA1		0x4b
+#define USB_PID_DATA2		0x87
+#define USB_PID_MDATA		0x0f
+/* Special */
+#define USB_PID_PREAMBLE	0x3c
+#define USB_PID_ERR		0x3c
+#define USB_PID_SPLIT		0x78
+#define USB_PID_PING		0xb4
+#define USB_PID_UNDEF_0		0xf0
+
+#define USB_PID_DATA_TOGGLE	0x88
+#define DBGP_CLAIM (DBGP_OWNER | DBGP_ENABLED | DBGP_INUSE)
+
+#define PCI_CAP_ID_EHCI_DEBUG	0xa
+
+#define HUB_ROOT_RESET_TIME	50	/* times are in msec */
+#define HUB_SHORT_RESET_TIME	10
+#define HUB_LONG_RESET_TIME	200
+#define HUB_RESET_TIMEOUT	500
+
+#define DBGP_MAX_PACKET		8
+
+static int dbgp_wait_until_complete(void)
+{
+	unsigned ctrl;
+	for (;;) {
+		ctrl = readl(ehci_debug-control);
+		/* Stop when the transaction is finished */
+		if (ctrl  DBGP_DONE)
+			break;
+	}
+	/* Now that we have observed the completed transaction,
+	 * clear the done bit.
+	 */
+	writel(ctrl | DBGP_DONE, ehci_debug-control);
+	return (ctrl  DBGP_ERROR) ? -DBGP_ERRCODE(ctrl) : DBGP_LEN(ctrl);
+}
+
+static void dbgp_mdelay(int ms)
+{
+	int i;
+	while (ms--) {
+		for (i = 0; i  1000; i++)
+			outb(0x1, 0x80);
+	}
+}
+
+static void dbgp_breath(void)
+{
+	/* Sleep to give the debug port a chance to breathe */
+}
+
+static int dbgp_wait_until_done(unsigned ctrl)
+{
+	unsigned pids, lpid;
+	int ret;
+
+retry:
+	writel(ctrl | DBGP_GO, ehci_debug-control);
+	ret = dbgp_wait_until_complete();
+	pids = readl(ehci_debug-pids);
+	lpid = DBGP_PID_GET(pids);
+
+	if (ret  0)
+		return ret;
+
+	/* If the port is getting full or it has dropped data
+	 * start pacing ourselves, not necessary but it's friendly.
+	 */
+	if ((lpid == USB_PID_NAK) || (lpid == USB_PID_NYET))
+		dbgp_breath();
+	
+	/* If I get a NACK reissue the transmission */
+	if (lpid == USB_PID_NAK)
+		goto retry;
+
+	return ret;
+}
+
+static void dbgp_set_data(const void *buf, int size)
+{
+	const unsigned char *bytes = buf;
+	unsigned lo, hi;
+	int i;
+	lo = hi = 0;
+	for (i = 0; i  4  i  size; i++)
+		lo |= bytes[i]  (8*i);
+	for (; i  8  i  size; i++)
+		hi |= bytes[i]  (8*(i - 4));
+	writel(lo, ehci_debug-data03);
+	writel(hi, ehci_debug-data47);
+}
+
+static void dbgp_get_data(void *buf, int size)
+{
+	unsigned char *bytes = buf;
+	unsigned lo, hi;
+	int i;
+	lo = readl(ehci_debug-data03);
+	hi = readl(ehci_debug-data47);

Re: [LinuxBIOS] [linux-usb-devel] [RFC][PATCH 0/2] x86_64 Early usb debug port support.

2006-12-12 Thread Eric W. Biederman

Yinghai Lu [EMAIL PROTECTED] writes:

 On 12/8/06, Eric W. Biederman [EMAIL PROTECTED] wrote:

 Your or I missed a bug fix/enhancement in there somewhere.


 I found the problem. the __set_fixmap need to __va, so the entries
 will be referred from PAGE_OFFSET.

 solution will be
 1. move enable_dbgp_console from setup_early_printk, and call it from
 setup_arch after init_memory_mapping.
 2. or make __set_fixmap can use __pa or pa()+__START_KERNEL_map in
 addtion to _va.

3.  Make __va always work.  I had this in my tree and I guess it didn't get
   into my big rollup patch.

Eric


x86_64: Fix the memory mapping in the early page table

diff --git a/arch/x86_64/kernel/head.S b/arch/x86_64/kernel/head.S
index 1e6f808..2f65469 100644
--- a/arch/x86_64/kernel/head.S
+++ b/arch/x86_64/kernel/head.S
@@ -328,9 +328,9 @@ ENTRY(wakeup_level4_pgt)
.align PAGE_SIZE
 ENTRY(boot_level4_pgt)
.quad   phys_level3_ident_pgt | 0x007
-   .fill   255,8,0
+   .fill   257,8,0
.quad   phys_level3_physmem_pgt | 0x007
-   .fill   254,8,0
+   .fill   252,8,0
/* (2^48-(2*1024*1024*1024))/(2^39) = 511 */
.quad   phys_level3_kernel_pgt | 0x007
 


-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [LinuxBIOS] [linux-usb-devel] [RFC][PATCH 0/2] x86_64 Early usb debug port support.

2006-12-09 Thread Peter Stuge

On Fri, Dec 08, 2006 at 07:16:09PM -0800, Lu, Yinghai wrote:
> It works in LinuxBIOS now.

Cool, can't wait to try it out.

Good work!


//Peter
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [LinuxBIOS] [linux-usb-devel] [RFC][PATCH 0/2] x86_64 Early usb debug port support.

2006-12-09 Thread Peter Stuge

On Fri, Dec 08, 2006 at 07:16:09PM -0800, Lu, Yinghai wrote:
 It works in LinuxBIOS now.

Cool, can't wait to try it out.

Good work!


//Peter
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

RE: [LinuxBIOS] [linux-usb-devel] [RFC][PATCH 0/2] x86_64 Early usb debug port support.

2006-12-08 Thread Lu, Yinghai

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] 
Sent: Thursday, December 07, 2006 11:42 PM
>> With Eric code in LinuxBIOS, it will report "No device found in debug
>> port"
>Hmm.  At least this is partial progress :)

It works in LinuxBIOS now. It will loop all connected port and find
debug device.
Will check in the code together with MCP55.

YH


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [LinuxBIOS] [linux-usb-devel] [RFC][PATCH 0/2] x86_64 Early usb debug port support.

2006-12-08 Thread Eric W. Biederman

"Yinghai Lu" <[EMAIL PROTECTED]> writes:

> On 12/7/06, Eric W. Biederman <[EMAIL PROTECTED]> wrote:
>> Ugh.  I'd check the code.  But it looks like my tweak to the
>> early fixmap code.  But my hunch is that my tweak to __fixmap
>> so that it's pud and pmd were prepopulated didn't take on
>> your build.
>
> I missed some options?

Your or I missed a bug fix/enhancement in there somewhere.

Basically my very early setup of the fixmap failed.
Now.  I thought I had that covered by preallocated the pud and the pmd
entries.   So the only thing missing was the pte entries.

If that is not a big enough hint I will look into it in a bit...

I'm starting to become a big fan of constant initializers.  So our
core subsystems don't need initialization code to be useful.  All of
these early things are just a pain.

Eric
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [LinuxBIOS] [linux-usb-devel] [RFC][PATCH 0/2] x86_64 Early usb debug port support.

2006-12-08 Thread Yinghai Lu


On 12/7/06, Eric W. Biederman <[EMAIL PROTECTED]> wrote:

Ugh.  I'd check the code.  But it looks like my tweak to the
early fixmap code.  But my hunch is that my tweak to __fixmap
so that it's pud and pmd were prepopulated didn't take on
your build.


I missed some options?

YH
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [LinuxBIOS] [linux-usb-devel] [RFC][PATCH 0/2] x86_64 Early usb debug port support.

2006-12-08 Thread Yinghai Lu

On 12/7/06, Greg KH <[EMAIL PROTECTED]> wrote:

Ugh, no, never use the usb-serial driver as a console device.

That was a bad hack done as a bet many years ago.  For many obvious
reasons it does not work well.

understood, I found with usb_serial convertor could lose some chatacter.
but the usb-debug cable seem it keep all character.

> host with cat /dev/ttyUSB0
> But if use minicom in host, it will not show '\r', I guess the usb debug
> cable eat return char. Greg, Can you add that back in usb_debug by
> replacing '\n' with '\r', '\n'?

The usb-serial console code should handle this, I thought we fixed it a
while ago.

Is it in the git tree?

But this kind of interface is not what these devices are good for.  They
are for the debug port information, not as a usb-serial console device.
Otherwise they are way too expensive of a device...

the problem is some "modern" PC will left out serial port. then the cable
could get cheap.

YH
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [LinuxBIOS] [linux-usb-devel] [RFC][PATCH 0/2] x86_64 Early usb debug port support.

2006-12-08 Thread Yinghai Lu


On 12/7/06, Greg KH [EMAIL PROTECTED] wrote:

Ugh, no, never use the usb-serial driver as a console device.

That was a bad hack done as a bet many years ago.  For many obvious
reasons it does not work well.

understood, I found with usb_serial convertor could lose some chatacter.
but the usb-debug cable seem it keep all character.


 host with cat /dev/ttyUSB0
 But if use minicom in host, it will not show '\r', I guess the usb debug
 cable eat return char. Greg, Can you add that back in usb_debug by
 replacing '\n' with '\r', '\n'?

The usb-serial console code should handle this, I thought we fixed it a
while ago.

Is it in the git tree?


But this kind of interface is not what these devices are good for.  They
are for the debug port information, not as a usb-serial console device.
Otherwise they are way too expensive of a device...

the problem is some modern PC will left out serial port. then the cable
could get cheap.

YH
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [LinuxBIOS] [linux-usb-devel] [RFC][PATCH 0/2] x86_64 Early usb debug port support.

2006-12-08 Thread Yinghai Lu


On 12/7/06, Eric W. Biederman [EMAIL PROTECTED] wrote:

Ugh.  I'd check the code.  But it looks like my tweak to the
early fixmap code.  But my hunch is that my tweak to __fixmap
so that it's pud and pmd were prepopulated didn't take on
your build.


I missed some options?

YH
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [LinuxBIOS] [linux-usb-devel] [RFC][PATCH 0/2] x86_64 Early usb debug port support.

2006-12-08 Thread Eric W. Biederman

Yinghai Lu [EMAIL PROTECTED] writes:

 On 12/7/06, Eric W. Biederman [EMAIL PROTECTED] wrote:
 Ugh.  I'd check the code.  But it looks like my tweak to the
 early fixmap code.  But my hunch is that my tweak to __fixmap
 so that it's pud and pmd were prepopulated didn't take on
 your build.

 I missed some options?

Your or I missed a bug fix/enhancement in there somewhere.

Basically my very early setup of the fixmap failed.
Now.  I thought I had that covered by preallocated the pud and the pmd
entries.   So the only thing missing was the pte entries.

If that is not a big enough hint I will look into it in a bit...

I'm starting to become a big fan of constant initializers.  So our
core subsystems don't need initialization code to be useful.  All of
these early things are just a pain.

Eric
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

RE: [LinuxBIOS] [linux-usb-devel] [RFC][PATCH 0/2] x86_64 Early usb debug port support.

2006-12-08 Thread Lu, Yinghai

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] 
Sent: Thursday, December 07, 2006 11:42 PM
 With Eric code in LinuxBIOS, it will report No device found in debug
 port
Hmm.  At least this is partial progress :)

It works in LinuxBIOS now. It will loop all connected port and find
debug device.
Will check in the code together with MCP55.

YH


-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [LinuxBIOS] [linux-usb-devel] [RFC][PATCH 0/2] x86_64 Early usb debug port support.

2006-12-07 Thread Eric W. Biederman

"Lu, Yinghai" <[EMAIL PROTECTED]> writes:

> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On Behalf Of
> [EMAIL PROTECTED]
>
>
>>Ok due to popular demands here is the slightly fixed patch that works
>>on both i386 and x86_64.  For the i386 version you must not have
>>HIGHMEM64G enabled. 
>
>>I just rolled it all into one patch as I'm to lazy to transmit all
>>3 of them.
>
>
> I got
>
> Firmware type: LinuxBIOS
> Linux version 2.6.19-smp-gc9976797-dirty ([EMAIL PROTECTED]) (gcc version
> 4.0.2) #196 6
> Command line: earlyprintk=ttyS0,115200 apic=debug pci=noacpi,routeirq
> snd-hda-i
> BIOS-provided physical RAM map:
>  BIOS-e820:  - 1000 (reserved)
>  BIOS-e820: 1000 - 000a (usable)
>  BIOS-e820: 000c - 000f (usable)
>  BIOS-e820: 000f - 0010 (reserved)
>  BIOS-e820: 0010 - c000 (usable)
>  BIOS-e820: 0001 - 00024000 (usable)
> dbgp_num: 0
> Found EHCI debug port
> bar: 10 offset: 098
> bar: 10 offset: 098
> dbgp pre-set_fixmap_nocache
> PANIC: early exception rip 809c24b4 error 0 cr2 81203ff8
>
> Call Trace:
>  [] __set_fixmap+0x84/0x202
>  [] early_dbgp_init+0x259/0x55c
>  [] __call_console_drivers+0x64/0x72
>  [] do_early_param+0x0/0x57
>  [] setup_early_printk+0x162/0x17e
>  [] do_early_param+0x2e/0x57
>  [] parse_args+0x159/0x1f3
>  [] parse_early_param+0x40/0x4c
>  [] setup_arch+0x1c1/0x636
>  [] start_kernel+0x55/0x208
>  [] _sinittext+0x173/0x177
>
> RIP __set_fixmap+0x84/0x202

Ugh.  I'd check the code.  But it looks like my tweak to the
early fixmap code.  But my hunch is that my tweak to __fixmap
so that it's pud and pmd were prepopulated didn't take on
your build.

> With Eric code in LinuxBIOS, it will report "No device found in debug
> port"

Hmm.  At least this is partial progress :)

Eric

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [LinuxBIOS] [linux-usb-devel] [RFC][PATCH 0/2] x86_64 Early usb debug port support.

2006-12-07 Thread Greg KH

On Thu, Dec 07, 2006 at 07:48:17PM -0800, Lu, Yinghai wrote:
> With Greg's USB Debug, host and target can talk.
> target with console=ttyUSB0,115200n8

Ugh, no, never use the usb-serial driver as a console device.

That was a bad hack done as a bet many years ago.  For many obvious
reasons it does not work well.

> host with cat /dev/ttyUSB0
> But if use minicom in host, it will not show '\r', I guess the usb debug
> cable eat return char. Greg, Can you add that back in usb_debug by
> replacing '\n' with '\r', '\n'?

The usb-serial console code should handle this, I thought we fixed it a
while ago.

But this kind of interface is not what these devices are good for.  They
are for the debug port information, not as a usb-serial console device.
Otherwise they are way too expensive of a device...

thanks,

greg k-h
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

RE: [LinuxBIOS] [linux-usb-devel] [RFC][PATCH 0/2] x86_64 Early usb debug port support.

2006-12-07 Thread Lu, Yinghai

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of
[EMAIL PROTECTED]


>Ok due to popular demands here is the slightly fixed patch that works
>on both i386 and x86_64.  For the i386 version you must not have
>HIGHMEM64G enabled. 

>I just rolled it all into one patch as I'm to lazy to transmit all
>3 of them.


I got

Firmware type: LinuxBIOS
Linux version 2.6.19-smp-gc9976797-dirty ([EMAIL PROTECTED]) (gcc version
4.0.2) #196 6
Command line: earlyprintk=ttyS0,115200 apic=debug pci=noacpi,routeirq
snd-hda-i
BIOS-provided physical RAM map:
 BIOS-e820:  - 1000 (reserved)
 BIOS-e820: 1000 - 000a (usable)
 BIOS-e820: 000c - 000f (usable)
 BIOS-e820: 000f - 0010 (reserved)
 BIOS-e820: 0010 - c000 (usable)
 BIOS-e820: 0001 - 00024000 (usable)
dbgp_num: 0
Found EHCI debug port
bar: 10 offset: 098
bar: 10 offset: 098
dbgp pre-set_fixmap_nocache
PANIC: early exception rip 809c24b4 error 0 cr2 81203ff8

Call Trace:
 [] __set_fixmap+0x84/0x202
 [] early_dbgp_init+0x259/0x55c
 [] __call_console_drivers+0x64/0x72
 [] do_early_param+0x0/0x57
 [] setup_early_printk+0x162/0x17e
 [] do_early_param+0x2e/0x57
 [] parse_args+0x159/0x1f3
 [] parse_early_param+0x40/0x4c
 [] setup_arch+0x1c1/0x636
 [] start_kernel+0x55/0x208
 [] _sinittext+0x173/0x177

RIP __set_fixmap+0x84/0x202

With Greg's USB Debug, host and target can talk.
target with console=ttyUSB0,115200n8
host with cat /dev/ttyUSB0
But if use minicom in host, it will not show '\r', I guess the usb debug
cable eat return char. Greg, Can you add that back in usb_debug by
replacing '\n' with '\r', '\n'?

With Eric code in LinuxBIOS, it will report "No device found in debug
port"

YH




-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

RE: [LinuxBIOS] [linux-usb-devel] [RFC][PATCH 0/2] x86_64 Early usb debug port support.

2006-12-07 Thread Lu, Yinghai

Two side are identical if two side are connected.

YH


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [LinuxBIOS] [linux-usb-devel] [RFC][PATCH 0/2] x86_64 Early usb debug port support.

2006-12-07 Thread Peter Stuge

On Wed, Dec 06, 2006 at 01:08:14PM -0800, Lu, Yinghai wrote:
> -Original Message-
> From: Andi Kleen [mailto:[EMAIL PROTECTED] 
> Sent: Wednesday, December 06, 2006 12:59 PM
> 
> >I haven't looked how the other usb_debug works -- if it's polled
> >too then it wouldn't have much advantage.
> 
> Need to verify if the two sides of debug cable are identical. 

I got my device yesterday and after a small plugfest I can confirm
that only one end of the device enumerates when connected to an ICH7
EHCI driven by 2.6.19.

--8<--
Bus 001 Device 027: ID 0525:127a Netchip Technology, Inc. 
Device Descriptor:
  bLength18
  bDescriptorType 1
  bcdUSB   2.00
  bDeviceClass  255 Vendor Specific Class
  bDeviceSubClass 0 
  bDeviceProtocol 0 
  bMaxPacketSize064
  idVendor   0x0525 Netchip Technology, Inc.
  idProduct  0x127a 
  bcdDevice1.01
  iManufacturer   1 NetChip
  iProduct2 NetChip TurboCONNECT 2.0
  iSerial 3 1
  bNumConfigurations  1
  Configuration Descriptor:
bLength 9
bDescriptorType 2
wTotalLength   32
bNumInterfaces  1
bConfigurationValue 1
iConfiguration  0 
bmAttributes 0xc0
  Self Powered
MaxPower0mA
Interface Descriptor:
  bLength 9
  bDescriptorType 4
  bInterfaceNumber0
  bAlternateSetting   0
  bNumEndpoints   2
  bInterfaceClass   255 Vendor Specific Class
  bInterfaceSubClass  0 
  bInterfaceProtocol  0 
  iInterface  0 
  Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x01  EP 1 OUT
bmAttributes2
  Transfer TypeBulk
  Synch Type   None
  Usage Type   Data
wMaxPacketSize 0x0200  1x 512 bytes
bInterval   0
  Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x82  EP 2 IN
bmAttributes2
  Transfer TypeBulk
  Synch Type   None
  Usage Type   Data
wMaxPacketSize 0x0200  1x 512 bytes
bInterval   0
Device Qualifier (for other device speed):
  bLength10
  bDescriptorType 6
  bcdUSB   2.00
  bDeviceClass  255 Vendor Specific Class
  bDeviceSubClass 0 
  bDeviceProtocol 0 
  bMaxPacketSize064
  bNumConfigurations  1
Debug descriptor:
  bLength 4
  bDescriptorType10
  bDebugInEndpoint 0x82
  bDebugOutEndpoint0x01
-->8--

The device is in fact not self-powered.

My theory is that the same set of descriptors are used for both ends,
but one end has been locked to address 127 in order to work with
simpler debug port drivers that assume it will be there.

I guess that the self-powered error is also to simplify life for
debug port drivers. IIRC most if not all USB power management
concerns are noops for debug ports.


//Peter
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [LinuxBIOS] [linux-usb-devel] [RFC][PATCH 0/2] x86_64 Early usb debug port support.

2006-12-07 Thread Peter Stuge

On Wed, Dec 06, 2006 at 01:08:14PM -0800, Lu, Yinghai wrote:
 -Original Message-
 From: Andi Kleen [mailto:[EMAIL PROTECTED] 
 Sent: Wednesday, December 06, 2006 12:59 PM
 
 I haven't looked how the other usb_debug works -- if it's polled
 too then it wouldn't have much advantage.
 
 Need to verify if the two sides of debug cable are identical. 

I got my device yesterday and after a small plugfest I can confirm
that only one end of the device enumerates when connected to an ICH7
EHCI driven by 2.6.19.

--8--
Bus 001 Device 027: ID 0525:127a Netchip Technology, Inc. 
Device Descriptor:
  bLength18
  bDescriptorType 1
  bcdUSB   2.00
  bDeviceClass  255 Vendor Specific Class
  bDeviceSubClass 0 
  bDeviceProtocol 0 
  bMaxPacketSize064
  idVendor   0x0525 Netchip Technology, Inc.
  idProduct  0x127a 
  bcdDevice1.01
  iManufacturer   1 NetChip
  iProduct2 NetChip TurboCONNECT 2.0
  iSerial 3 1
  bNumConfigurations  1
  Configuration Descriptor:
bLength 9
bDescriptorType 2
wTotalLength   32
bNumInterfaces  1
bConfigurationValue 1
iConfiguration  0 
bmAttributes 0xc0
  Self Powered
MaxPower0mA
Interface Descriptor:
  bLength 9
  bDescriptorType 4
  bInterfaceNumber0
  bAlternateSetting   0
  bNumEndpoints   2
  bInterfaceClass   255 Vendor Specific Class
  bInterfaceSubClass  0 
  bInterfaceProtocol  0 
  iInterface  0 
  Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x01  EP 1 OUT
bmAttributes2
  Transfer TypeBulk
  Synch Type   None
  Usage Type   Data
wMaxPacketSize 0x0200  1x 512 bytes
bInterval   0
  Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x82  EP 2 IN
bmAttributes2
  Transfer TypeBulk
  Synch Type   None
  Usage Type   Data
wMaxPacketSize 0x0200  1x 512 bytes
bInterval   0
Device Qualifier (for other device speed):
  bLength10
  bDescriptorType 6
  bcdUSB   2.00
  bDeviceClass  255 Vendor Specific Class
  bDeviceSubClass 0 
  bDeviceProtocol 0 
  bMaxPacketSize064
  bNumConfigurations  1
Debug descriptor:
  bLength 4
  bDescriptorType10
  bDebugInEndpoint 0x82
  bDebugOutEndpoint0x01
--8--

The device is in fact not self-powered.

My theory is that the same set of descriptors are used for both ends,
but one end has been locked to address 127 in order to work with
simpler debug port drivers that assume it will be there.

I guess that the self-powered error is also to simplify life for
debug port drivers. IIRC most if not all USB power management
concerns are noops for debug ports.


//Peter
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

RE: [LinuxBIOS] [linux-usb-devel] [RFC][PATCH 0/2] x86_64 Early usb debug port support.

2006-12-07 Thread Lu, Yinghai

Two side are identical if two side are connected.

YH


-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

RE: [LinuxBIOS] [linux-usb-devel] [RFC][PATCH 0/2] x86_64 Early usb debug port support.

2006-12-07 Thread Lu, Yinghai

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of
[EMAIL PROTECTED]


Ok due to popular demands here is the slightly fixed patch that works
on both i386 and x86_64.  For the i386 version you must not have
HIGHMEM64G enabled. 

I just rolled it all into one patch as I'm to lazy to transmit all
3 of them.


I got

Firmware type: LinuxBIOS
Linux version 2.6.19-smp-gc9976797-dirty ([EMAIL PROTECTED]) (gcc version
4.0.2) #196 6
Command line: earlyprintk=ttyS0,115200 apic=debug pci=noacpi,routeirq
snd-hda-i
BIOS-provided physical RAM map:
 BIOS-e820:  - 1000 (reserved)
 BIOS-e820: 1000 - 000a (usable)
 BIOS-e820: 000c - 000f (usable)
 BIOS-e820: 000f - 0010 (reserved)
 BIOS-e820: 0010 - c000 (usable)
 BIOS-e820: 0001 - 00024000 (usable)
dbgp_num: 0
Found EHCI debug port
bar: 10 offset: 098
bar: 10 offset: 098
dbgp pre-set_fixmap_nocache
PANIC: early exception rip 809c24b4 error 0 cr2 81203ff8

Call Trace:
 [809c24b4] __set_fixmap+0x84/0x202
 [809c05bb] early_dbgp_init+0x259/0x55c
 [8022d958] __call_console_drivers+0x64/0x72
 [809b242b] do_early_param+0x0/0x57
 [809c0a20] setup_early_printk+0x162/0x17e
 [809b2459] do_early_param+0x2e/0x57
 [8023d051] parse_args+0x159/0x1f3
 [809b24c2] parse_early_param+0x40/0x4c
 [809b88ca] setup_arch+0x1c1/0x636
 [809b2534] start_kernel+0x55/0x208
 [809b2173] _sinittext+0x173/0x177

RIP __set_fixmap+0x84/0x202

With Greg's USB Debug, host and target can talk.
target with console=ttyUSB0,115200n8
host with cat /dev/ttyUSB0
But if use minicom in host, it will not show '\r', I guess the usb debug
cable eat return char. Greg, Can you add that back in usb_debug by
replacing '\n' with '\r', '\n'?

With Eric code in LinuxBIOS, it will report No device found in debug
port

YH




-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [LinuxBIOS] [linux-usb-devel] [RFC][PATCH 0/2] x86_64 Early usb debug port support.

2006-12-07 Thread Greg KH

On Thu, Dec 07, 2006 at 07:48:17PM -0800, Lu, Yinghai wrote:
 With Greg's USB Debug, host and target can talk.
 target with console=ttyUSB0,115200n8

Ugh, no, never use the usb-serial driver as a console device.

That was a bad hack done as a bet many years ago.  For many obvious
reasons it does not work well.

 host with cat /dev/ttyUSB0
 But if use minicom in host, it will not show '\r', I guess the usb debug
 cable eat return char. Greg, Can you add that back in usb_debug by
 replacing '\n' with '\r', '\n'?

The usb-serial console code should handle this, I thought we fixed it a
while ago.

But this kind of interface is not what these devices are good for.  They
are for the debug port information, not as a usb-serial console device.
Otherwise they are way too expensive of a device...

thanks,

greg k-h
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [LinuxBIOS] [linux-usb-devel] [RFC][PATCH 0/2] x86_64 Early usb debug port support.

2006-12-07 Thread Eric W. Biederman

Lu, Yinghai [EMAIL PROTECTED] writes:

 -Original Message-
 From: [EMAIL PROTECTED]
 [mailto:[EMAIL PROTECTED] On Behalf Of
 [EMAIL PROTECTED]


Ok due to popular demands here is the slightly fixed patch that works
on both i386 and x86_64.  For the i386 version you must not have
HIGHMEM64G enabled. 

I just rolled it all into one patch as I'm to lazy to transmit all
3 of them.


 I got

 Firmware type: LinuxBIOS
 Linux version 2.6.19-smp-gc9976797-dirty ([EMAIL PROTECTED]) (gcc version
 4.0.2) #196 6
 Command line: earlyprintk=ttyS0,115200 apic=debug pci=noacpi,routeirq
 snd-hda-i
 BIOS-provided physical RAM map:
  BIOS-e820:  - 1000 (reserved)
  BIOS-e820: 1000 - 000a (usable)
  BIOS-e820: 000c - 000f (usable)
  BIOS-e820: 000f - 0010 (reserved)
  BIOS-e820: 0010 - c000 (usable)
  BIOS-e820: 0001 - 00024000 (usable)
 dbgp_num: 0
 Found EHCI debug port
 bar: 10 offset: 098
 bar: 10 offset: 098
 dbgp pre-set_fixmap_nocache
 PANIC: early exception rip 809c24b4 error 0 cr2 81203ff8

 Call Trace:
  [809c24b4] __set_fixmap+0x84/0x202
  [809c05bb] early_dbgp_init+0x259/0x55c
  [8022d958] __call_console_drivers+0x64/0x72
  [809b242b] do_early_param+0x0/0x57
  [809c0a20] setup_early_printk+0x162/0x17e
  [809b2459] do_early_param+0x2e/0x57
  [8023d051] parse_args+0x159/0x1f3
  [809b24c2] parse_early_param+0x40/0x4c
  [809b88ca] setup_arch+0x1c1/0x636
  [809b2534] start_kernel+0x55/0x208
  [809b2173] _sinittext+0x173/0x177

 RIP __set_fixmap+0x84/0x202

Ugh.  I'd check the code.  But it looks like my tweak to the
early fixmap code.  But my hunch is that my tweak to __fixmap
so that it's pud and pmd were prepopulated didn't take on
your build.

 With Eric code in LinuxBIOS, it will report No device found in debug
 port

Hmm.  At least this is partial progress :)

Eric

-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [linux-usb-devel] [RFC][PATCH 0/2] x86_64 Early usb debug port support.

2006-12-06 Thread David Brownell

On Wednesday 06 December 2006 1:24 pm, Andi Kleen wrote:
> >   - Host, to which that console connects (through the debug device);
> > runs usb_debug, much like any other usb-serial device
> 
> My understanding was that the client could run in user 
> space only on top of libusb.

I suppose it could, if you didn't want to use it like a normal
serial consoe.


> > It's analagous to debugging an embedded box using a serial console
> > with a Linux host ... except the target here is a PC, not an ARM
> > (or PPC, MIPS, etc) custom board.
> > 
> > 
> > Once the coexistence issues between the debug port and normal EHCI
> > driver get worked, there's no reason not to keep using that debug
> > port as a system console.  
> 
> One reason is the one I covered in my last mail -- locking of the PCI
> type 1 ports.

That'd be part of coexistence.  The debug port is _designed_ to share
two different drivers like that ... EHCI can see, as it comes up,
whether the debug port is in use, and could then ignore it.  (At least,
unless/until the debug device gets removed.)

- Dave

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [linux-usb-devel] [RFC][PATCH 0/2] x86_64 Early usb debug port support.

2006-12-06 Thread Andi Kleen


> > However I suppose it would be ok to switch Eric's code between early
> > pci access and locked one once the PCI subsystem is up and running.
> > Just don't forget bust_spinlocks()
> 
> No pci access on that path.

Hmm good point. Ok ignore that then.

keep should be default then.

-Andi
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [linux-usb-devel] [RFC][PATCH 0/2] x86_64 Early usb debug port support.

2006-12-06 Thread Eric W. Biederman

Andi Kleen <[EMAIL PROTECTED]> writes:

> \
>>   - Host, to which that console connects (through the debug device);
>> runs usb_debug, much like any other usb-serial device
>
> My understanding was that the client could run in user 
> space only on top of libusb.

Looks like a normal serial port with greg's patch.
I still need to try it though.

> One reason is the one I covered in my last mail -- locking of the PCI
> type 1 ports.
>
> However I suppose it would be ok to switch Eric's code between early
> pci access and locked one once the PCI subsystem is up and running.
> Just don't forget bust_spinlocks()

No pci access on that path.

Eric
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [linux-usb-devel] [RFC][PATCH 0/2] x86_64 Early usb debug port support.

2006-12-06 Thread Andi Kleen

\
>   - Host, to which that console connects (through the debug device);
> runs usb_debug, much like any other usb-serial device

My understanding was that the client could run in user 
space only on top of libusb.

> 
> It's analagous to debugging an embedded box using a serial console
> with a Linux host ... except the target here is a PC, not an ARM
> (or PPC, MIPS, etc) custom board.
> 
> 
> Once the coexistence issues between the debug port and normal EHCI
> driver get worked, there's no reason not to keep using that debug
> port as a system console.  

One reason is the one I covered in my last mail -- locking of the PCI
type 1 ports.

However I suppose it would be ok to switch Eric's code between early
pci access and locked one once the PCI subsystem is up and running.
Just don't forget bust_spinlocks()

-Andi
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [linux-usb-devel] [RFC][PATCH 0/2] x86_64 Early usb debug port support.

2006-12-06 Thread David Brownell

> > or usb_debug that Greg just added 
>
> Ah I didn't notice that. If there is a usb_debug that works later
> then yes it would need to be disabled.

I detect confusion here ... remember that there are potentially two
distinct Linux systems involved here:

  - Target, with some kind of console hooked up to the debug device;
runs this _new_ "early debug port" code.

  - Host, to which that console connects (through the debug device);
runs usb_debug, much like any other usb-serial device

It's analagous to debugging an embedded box using a serial console
with a Linux host ... except the target here is a PC, not an ARM
(or PPC, MIPS, etc) custom board.


Once the coexistence issues between the debug port and normal EHCI
driver get worked, there's no reason not to keep using that debug
port as a system console.  Heck, being able to do that might be a
huge win with some of the nasty suspend/resume problems we've got.

- Dave

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [linux-usb-devel] [RFC][PATCH 0/2] x86_64 Early usb debug port support.

2006-12-06 Thread Eric W. Biederman

Andi Kleen <[EMAIL PROTECTED]> writes:

> On Wednesday 06 December 2006 21:43, Lu, Yinghai wrote:
>> -Original Message-
>> From: Andi Kleen [mailto:[EMAIL PROTECTED] 
>> Sent: Wednesday, December 06, 2006 9:31 AM
>> 
>> >Also for usb console keep should be made default because the output
>> won't
>> >be duplicated.
>> 
>> Still need to tx_read to make console can take command?
>> 
>> Or transfer to generic usb_serial 
>
> I think the protocols are incompatible? 
>
>> or usb_debug that Greg just added 
>
> Ah I didn't notice that. If there is a usb_debug that works later
> then yes it would need to be disabled.
>
> However I see a certain advantage to keep using the early 
> usb console because it doesn't need any interrupts. So when the 
> kernel is very confused after an oops it might have a higher
> chance to still get the oops out.
>
> I haven't looked how the other usb_debug works -- if it's polled
> too then it wouldn't have much advantage.
>
> Ok one advantage of a non early usb_debug is that it will properly use pci 
> config space locking. The early implementation just ignores the port cf8 
> lock which might lead to corruption later. That's ok after
> an oops, but during normal output it can actually lead to
> data corruption if it interferes with somebody else's config write.
> Also on some systems cf8 is broken and doesn't work.
>
> Disadvantage of using the locks of course is that it can deadlock
> if an oops happen inside the critical region. So they might need
> to be added to bust_spinlocks()
>
> And it would be good if the late usb_debug still wouldn't rely
> on interrupts.
>
> But I agree it's probably better to transition to another usb_debug
> console and not do keep by default.

The only use of the early pci code is for finding the hardware.  Everything
else is through mmio.

The practical issue is that during the normal initialization of the ehci 
the reset of the hardware state is going to remove the delegation to the
ehci debug registers.

Greg's current thing uses the hardware but through the normal interrupt
driven usb methods.  I think it is worth using the ehci debug registers
if possible as that (except for reset) gives us independent control of
what is going on.

For understanding what needs to happen except for the initialization just
look at my dbgp_bulk_write routine.  That and the functions it call is
the only code in there that is executed.  It is just a hair more complicated
than other early debug port code because it has to deal with retransmits.
But I think it is still under 100 lines of code.

Eric
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

RE: [linux-usb-devel] [RFC][PATCH 0/2] x86_64 Early usb debug port support.

2006-12-06 Thread Lu, Yinghai

-Original Message-
From: Andi Kleen [mailto:[EMAIL PROTECTED] 
Sent: Wednesday, December 06, 2006 12:59 PM

>I haven't looked how the other usb_debug works -- if it's polled
>too then it wouldn't have much advantage.

Need to verify if the two sides of debug cable are identical. 

>And it would be good if the late usb_debug still wouldn't rely
>on interrupts.

Yes, esp. when usb can not get irq assigned correctly.

YH


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [linux-usb-devel] [RFC][PATCH 0/2] x86_64 Early usb debug port support.

2006-12-06 Thread Andi Kleen

On Wednesday 06 December 2006 21:43, Lu, Yinghai wrote:
> -Original Message-
> From: Andi Kleen [mailto:[EMAIL PROTECTED] 
> Sent: Wednesday, December 06, 2006 9:31 AM
> 
> >Also for usb console keep should be made default because the output
> won't
> >be duplicated.
> 
> Still need to tx_read to make console can take command?
> 
> Or transfer to generic usb_serial 

I think the protocols are incompatible? 

> or usb_debug that Greg just added 

Ah I didn't notice that. If there is a usb_debug that works later
then yes it would need to be disabled.

However I see a certain advantage to keep using the early 
usb console because it doesn't need any interrupts. So when the 
kernel is very confused after an oops it might have a higher
chance to still get the oops out.

I haven't looked how the other usb_debug works -- if it's polled
too then it wouldn't have much advantage.

Ok one advantage of a non early usb_debug is that it will properly use pci 
config space locking. The early implementation just ignores the port cf8 
lock which might lead to corruption later. That's ok after
an oops, but during normal output it can actually lead to
data corruption if it interferes with somebody else's config write.
Also on some systems cf8 is broken and doesn't work.

Disadvantage of using the locks of course is that it can deadlock
if an oops happen inside the critical region. So they might need
to be added to bust_spinlocks()

And it would be good if the late usb_debug still wouldn't rely
on interrupts.

But I agree it's probably better to transition to another usb_debug
console and not do keep by default.

-Andi
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

RE: [linux-usb-devel] [RFC][PATCH 0/2] x86_64 Early usb debug port support.

2006-12-06 Thread Lu, Yinghai

-Original Message-
From: Andi Kleen [mailto:[EMAIL PROTECTED] 
Sent: Wednesday, December 06, 2006 9:31 AM

>Also for usb console keep should be made default because the output
won't
>be duplicated.

Still need to tx_read to make console can take command?

Or transfer to generic usb_serial or usb_debug that Greg just added with
console=ttyUSB0 to get tty? Then you still need to disable that
early_console sometime later.

YH


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [linux-usb-devel] [RFC][PATCH 0/2] x86_64 Early usb debug port support.

2006-12-06 Thread Andi Kleen

On Tuesday 05 December 2006 12:01, Eric W. Biederman wrote:
> 
> Ok due to popular demands here is the slightly fixed patch that works
> on both i386 and x86_64.  For the i386 version you must not have
> HIGHMEM64G enabled. 
> 
> I just rolled it all into one patch as I'm to lazy to transmit all
> 3 of them.


You should definitely move the usb code to a separate file

Documentation/* needs to document the new option

Also for usb console keep should be made default because the output won't
be duplicated.


-Andi
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [LinuxBIOS] [linux-usb-devel] [RFC][PATCH 0/2] x86_64 Early usb debug port support.

2006-12-06 Thread Segher Boessenkool


What do you mean by
+   for (reps = 0; reps >= 0; reps++) {
?


If you will not reps is negative.  Roughly it is a loop
that will timeout eventually if a usb debug cable is not present.



So since I didn't know how many loop iterations made sense I allowed
it to loop for 2^31 times or until reps goes negative.


This doesn't work however.  Signed overflow in C is undefined,
and GCC actually optimises accordingly (unless -fwrapv is used).


Segher

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [LinuxBIOS] [linux-usb-devel] [RFC][PATCH 0/2] x86_64 Early usb debug port support.

2006-12-06 Thread Segher Boessenkool


What do you mean by
+   for (reps = 0; reps = 0; reps++) {
?


If you will not reps is negative.  Roughly it is a loop
that will timeout eventually if a usb debug cable is not present.



So since I didn't know how many loop iterations made sense I allowed
it to loop for 2^31 times or until reps goes negative.


This doesn't work however.  Signed overflow in C is undefined,
and GCC actually optimises accordingly (unless -fwrapv is used).


Segher

-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [linux-usb-devel] [RFC][PATCH 0/2] x86_64 Early usb debug port support.

2006-12-06 Thread Andi Kleen

On Tuesday 05 December 2006 12:01, Eric W. Biederman wrote:
 
 Ok due to popular demands here is the slightly fixed patch that works
 on both i386 and x86_64.  For the i386 version you must not have
 HIGHMEM64G enabled. 
 
 I just rolled it all into one patch as I'm to lazy to transmit all
 3 of them.


You should definitely move the usb code to a separate file

Documentation/* needs to document the new option

Also for usb console keep should be made default because the output won't
be duplicated.


-Andi
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

RE: [linux-usb-devel] [RFC][PATCH 0/2] x86_64 Early usb debug port support.

2006-12-06 Thread Lu, Yinghai

-Original Message-
From: Andi Kleen [mailto:[EMAIL PROTECTED] 
Sent: Wednesday, December 06, 2006 9:31 AM

Also for usb console keep should be made default because the output
won't
be duplicated.

Still need to tx_read to make console can take command?

Or transfer to generic usb_serial or usb_debug that Greg just added with
console=ttyUSB0 to get tty? Then you still need to disable that
early_console sometime later.

YH


-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [linux-usb-devel] [RFC][PATCH 0/2] x86_64 Early usb debug port support.

2006-12-06 Thread Andi Kleen

On Wednesday 06 December 2006 21:43, Lu, Yinghai wrote:
 -Original Message-
 From: Andi Kleen [mailto:[EMAIL PROTECTED] 
 Sent: Wednesday, December 06, 2006 9:31 AM
 
 Also for usb console keep should be made default because the output
 won't
 be duplicated.
 
 Still need to tx_read to make console can take command?
 
 Or transfer to generic usb_serial 

I think the protocols are incompatible? 

 or usb_debug that Greg just added 

Ah I didn't notice that. If there is a usb_debug that works later
then yes it would need to be disabled.

However I see a certain advantage to keep using the early 
usb console because it doesn't need any interrupts. So when the 
kernel is very confused after an oops it might have a higher
chance to still get the oops out.

I haven't looked how the other usb_debug works -- if it's polled
too then it wouldn't have much advantage.

Ok one advantage of a non early usb_debug is that it will properly use pci 
config space locking. The early implementation just ignores the port cf8 
lock which might lead to corruption later. That's ok after
an oops, but during normal output it can actually lead to
data corruption if it interferes with somebody else's config write.
Also on some systems cf8 is broken and doesn't work.

Disadvantage of using the locks of course is that it can deadlock
if an oops happen inside the critical region. So they might need
to be added to bust_spinlocks()

And it would be good if the late usb_debug still wouldn't rely
on interrupts.

But I agree it's probably better to transition to another usb_debug
console and not do keep by default.

-Andi
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

RE: [linux-usb-devel] [RFC][PATCH 0/2] x86_64 Early usb debug port support.

2006-12-06 Thread Lu, Yinghai

-Original Message-
From: Andi Kleen [mailto:[EMAIL PROTECTED] 
Sent: Wednesday, December 06, 2006 12:59 PM

I haven't looked how the other usb_debug works -- if it's polled
too then it wouldn't have much advantage.

Need to verify if the two sides of debug cable are identical. 

And it would be good if the late usb_debug still wouldn't rely
on interrupts.

Yes, esp. when usb can not get irq assigned correctly.

YH


-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [linux-usb-devel] [RFC][PATCH 0/2] x86_64 Early usb debug port support.

2006-12-06 Thread Eric W. Biederman

Andi Kleen [EMAIL PROTECTED] writes:

 On Wednesday 06 December 2006 21:43, Lu, Yinghai wrote:
 -Original Message-
 From: Andi Kleen [mailto:[EMAIL PROTECTED] 
 Sent: Wednesday, December 06, 2006 9:31 AM
 
 Also for usb console keep should be made default because the output
 won't
 be duplicated.
 
 Still need to tx_read to make console can take command?
 
 Or transfer to generic usb_serial 

 I think the protocols are incompatible? 

 or usb_debug that Greg just added 

 Ah I didn't notice that. If there is a usb_debug that works later
 then yes it would need to be disabled.

 However I see a certain advantage to keep using the early 
 usb console because it doesn't need any interrupts. So when the 
 kernel is very confused after an oops it might have a higher
 chance to still get the oops out.

 I haven't looked how the other usb_debug works -- if it's polled
 too then it wouldn't have much advantage.

 Ok one advantage of a non early usb_debug is that it will properly use pci 
 config space locking. The early implementation just ignores the port cf8 
 lock which might lead to corruption later. That's ok after
 an oops, but during normal output it can actually lead to
 data corruption if it interferes with somebody else's config write.
 Also on some systems cf8 is broken and doesn't work.

 Disadvantage of using the locks of course is that it can deadlock
 if an oops happen inside the critical region. So they might need
 to be added to bust_spinlocks()

 And it would be good if the late usb_debug still wouldn't rely
 on interrupts.

 But I agree it's probably better to transition to another usb_debug
 console and not do keep by default.

The only use of the early pci code is for finding the hardware.  Everything
else is through mmio.

The practical issue is that during the normal initialization of the ehci 
the reset of the hardware state is going to remove the delegation to the
ehci debug registers.

Greg's current thing uses the hardware but through the normal interrupt
driven usb methods.  I think it is worth using the ehci debug registers
if possible as that (except for reset) gives us independent control of
what is going on.

For understanding what needs to happen except for the initialization just
look at my dbgp_bulk_write routine.  That and the functions it call is
the only code in there that is executed.  It is just a hair more complicated
than other early debug port code because it has to deal with retransmits.
But I think it is still under 100 lines of code.


Eric
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [linux-usb-devel] [RFC][PATCH 0/2] x86_64 Early usb debug port support.

2006-12-06 Thread David Brownell

  or usb_debug that Greg just added 

 Ah I didn't notice that. If there is a usb_debug that works later
 then yes it would need to be disabled.

I detect confusion here ... remember that there are potentially two
distinct Linux systems involved here:

  - Target, with some kind of console hooked up to the debug device;
runs this _new_ early debug port code.

  - Host, to which that console connects (through the debug device);
runs usb_debug, much like any other usb-serial device

It's analagous to debugging an embedded box using a serial console
with a Linux host ... except the target here is a PC, not an ARM
(or PPC, MIPS, etc) custom board.


Once the coexistence issues between the debug port and normal EHCI
driver get worked, there's no reason not to keep using that debug
port as a system console.  Heck, being able to do that might be a
huge win with some of the nasty suspend/resume problems we've got.

- Dave

-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [linux-usb-devel] [RFC][PATCH 0/2] x86_64 Early usb debug port support.

2006-12-06 Thread Andi Kleen

\
   - Host, to which that console connects (through the debug device);
 runs usb_debug, much like any other usb-serial device

My understanding was that the client could run in user 
space only on top of libusb.

 
 It's analagous to debugging an embedded box using a serial console
 with a Linux host ... except the target here is a PC, not an ARM
 (or PPC, MIPS, etc) custom board.
 
 
 Once the coexistence issues between the debug port and normal EHCI
 driver get worked, there's no reason not to keep using that debug
 port as a system console.  

One reason is the one I covered in my last mail -- locking of the PCI
type 1 ports.

However I suppose it would be ok to switch Eric's code between early
pci access and locked one once the PCI subsystem is up and running.
Just don't forget bust_spinlocks()

-Andi
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [linux-usb-devel] [RFC][PATCH 0/2] x86_64 Early usb debug port support.

2006-12-06 Thread Eric W. Biederman

Andi Kleen [EMAIL PROTECTED] writes:

 \
   - Host, to which that console connects (through the debug device);
 runs usb_debug, much like any other usb-serial device

 My understanding was that the client could run in user 
 space only on top of libusb.

Looks like a normal serial port with greg's patch.
I still need to try it though.

 One reason is the one I covered in my last mail -- locking of the PCI
 type 1 ports.

 However I suppose it would be ok to switch Eric's code between early
 pci access and locked one once the PCI subsystem is up and running.
 Just don't forget bust_spinlocks()

No pci access on that path.

Eric
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [linux-usb-devel] [RFC][PATCH 0/2] x86_64 Early usb debug port support.

2006-12-06 Thread Andi Kleen


  However I suppose it would be ok to switch Eric's code between early
  pci access and locked one once the PCI subsystem is up and running.
  Just don't forget bust_spinlocks()
 
 No pci access on that path.

Hmm good point. Ok ignore that then.

keep should be default then.

-Andi
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [linux-usb-devel] [RFC][PATCH 0/2] x86_64 Early usb debug port support.

2006-12-06 Thread David Brownell

On Wednesday 06 December 2006 1:24 pm, Andi Kleen wrote:
- Host, to which that console connects (through the debug device);
  runs usb_debug, much like any other usb-serial device
 
 My understanding was that the client could run in user 
 space only on top of libusb.

I suppose it could, if you didn't want to use it like a normal
serial consoe.


  It's analagous to debugging an embedded box using a serial console
  with a Linux host ... except the target here is a PC, not an ARM
  (or PPC, MIPS, etc) custom board.
  
  
  Once the coexistence issues between the debug port and normal EHCI
  driver get worked, there's no reason not to keep using that debug
  port as a system console.  
 
 One reason is the one I covered in my last mail -- locking of the PCI
 type 1 ports.

That'd be part of coexistence.  The debug port is _designed_ to share
two different drivers like that ... EHCI can see, as it comes up,
whether the debug port is in use, and could then ignore it.  (At least,
unless/until the debug device gets removed.)

- Dave

-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

RE: [LinuxBIOS] [linux-usb-devel] [RFC][PATCH 0/2] x86_64 Early usb debug port support.

2006-12-05 Thread Lu, Yinghai



-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] 
Sent: Tuesday, December 05, 2006 3:50 PM


>If you will not reps is negative.  Roughly it is a loop
>that will timeout eventually if a usb debug cable is not present.
>Putting some deliberate delays in there so I could be certain
>of timing out after a second or two would probably be better, but
>I don't have anything that resembles a good timer at that point.

You have dbgp_mdelay in your code.

YH


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [LinuxBIOS] [linux-usb-devel] [RFC][PATCH 0/2] x86_64 Early usb debug port support.

2006-12-05 Thread Eric W. Biederman

"Lu, Yinghai" <[EMAIL PROTECTED]> writes:

> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On Behalf Of
> [EMAIL PROTECTED]
> Sent: Tuesday, December 05, 2006 3:01 AM
>
>>+static int ehci_wait_for_port(int port)
>>+{
>>+ unsigned status;
>>+ int ret, reps;
>>+ for (reps = 0; reps >= 0; reps++) {
>>+ status = readl(_regs->status);
>>+ if (status & STS_PCD) {
>>+ ret = ehci_reset_port(port);
>>+ if (ret == 0)
>>+ return 0;
>>+ }
>>+ }
>>+ return -ENOTCONN;
>>+}
>>+
>
> What do you mean by
> + for (reps = 0; reps >= 0; reps++) {
> ?

If you will not reps is negative.  Roughly it is a loop
that will timeout eventually if a usb debug cable is not present.
Putting some deliberate delays in there so I could be certain
of timing out after a second or two would probably be better, but
I don't have anything that resembles a good timer at that point.

The problem is you have to wait until the ehci notices your usb
debug cable before you reset it and get it going and that can be a
non-trivial amount of time.  So the loop is 100% necessary.

So since I didn't know how many loop iterations made sense I allowed
it to loop for 2^31 times or until reps goes negative.

Eric
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

RE: [LinuxBIOS] [linux-usb-devel] [RFC][PATCH 0/2] x86_64 Early usb debug port support.

2006-12-05 Thread Lu, Yinghai



-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of
[EMAIL PROTECTED]
Sent: Tuesday, December 05, 2006 3:01 AM

>+static int ehci_wait_for_port(int port)
>+{
>+  unsigned status;
>+  int ret, reps;
>+  for (reps = 0; reps >= 0; reps++) {
>+  status = readl(_regs->status);
>+  if (status & STS_PCD) {
>+  ret = ehci_reset_port(port);
>+  if (ret == 0)
>+  return 0;
>+  }
>+  }
>+  return -ENOTCONN;
>+}
>+

What do you mean by
+   for (reps = 0; reps >= 0; reps++) {
?

YH



-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [linux-usb-devel] [RFC][PATCH 0/2] x86_64 Early usb debug port support.

2006-12-05 Thread Eric W. Biederman

David Brownell <[EMAIL PROTECTED]> writes:

> On Sunday 03 December 2006 9:09 pm, Eric W. Biederman wrote:
>>
>> My driver should be sufficient to work with any EHCI in a realatively
>> clean state, and needs no special BIOS support just the hardware.
>> This appears to be different than the way the windows drivers are
>> using these debug devices.
>
> I'm glad to see someone finally got progress on this ... :)
>
> Separately, I forwarded some stuff I did last year ... maybe it'll help.
> You seem to have gotten further.  Have you also observed that the
> NetChip device seems to have polarity issues, such that only one
> end behaves properly?

I haven't yet.  But I don't think I have actually tried turning
the cable around in a very meaningful way yet either.  Possibly
this is something that has been fixed.  I know there are some
odd issues that I have encountered.  Like occasionally I would
need to stop the software on one side, or I would need to unplug
it when things got sufficiently confused.

> Note that this should **NOT** be specific to x86_64, since pretty
> much any PCI based EHCI can do this.  I wouldn't be able to use
> this on my NForce2 box, for example ...

So I took a quick look what it would take to do this truly generically
and even initializing this generally when console code typically
is registered looks like a problem.  Although only because we don't
get around to setting up pci_config space access helpers in a timely
manner.  To some extent that still sucks because you are still being
initialized before the general ehci-hcd code.

Regardless an arch specific i386 variant was easy to throw together.
It still needs a bit of work but it basically worked.

> As for EHCI registers, if this really _needs_ to live outside
> of drivers/usb/host, then I'd suggest  for
> the relevant declarations ... the  headers are
> provided exactly for sharing such declaration between otherwise
> unrelated parts of the tree.

Yep that sounds like the right thing to do.  I think I at least
need to be called from something outside of drivers/usb and may
need the code there.

Doing this in a truly generic fashion looks like a major pain.
Because all of the infrastructure needs to be fixed.

Eric
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [linux-usb-devel] [RFC][PATCH 0/2] x86_64 Early usb debug port support.

2006-12-05 Thread Eric W. Biederman


Ok due to popular demands here is the slightly fixed patch that works
on both i386 and x86_64.  For the i386 version you must not have
HIGHMEM64G enabled. 

I just rolled it all into one patch as I'm to lazy to transmit all
3 of them.

Eric

 arch/i386/kernel/head.S   |8 +
 arch/x86_64/kernel/early_printk.c |  580 +
 arch/x86_64/kernel/head.S |   11 +-
 drivers/usb/host/ehci.h   |8 +
 include/asm-i386/fixmap.h |1 +
 include/asm-x86_64/fixmap.h   |1 +
 6 files changed, 608 insertions(+), 1 deletions(-)

diff --git a/arch/i386/kernel/head.S b/arch/i386/kernel/head.S
index ca31f18..f683565 100644
--- a/arch/i386/kernel/head.S
+++ b/arch/i386/kernel/head.S
@@ -135,6 +135,12 @@ page_pde_offset = (__PAGE_OFFSET >> 20);
jb 10b
movl %edi,(init_pg_tables_end - __PAGE_OFFSET)
 
+   /* Do an early initialization of the fixmap area */
+   movl $(swapper_pg_dir - __PAGE_OFFSET), %edx
+   movl $(swapper_pg_pmd - __PAGE_OFFSET), %eax
+   addl $0x007, %eax   /* 0x007 = PRESENT+RW+USER */
+   movl %eax, 4092(%edx)
+
 #ifdef CONFIG_SMP
xorl %ebx,%ebx  /* This is the boot CPU (BSP) */
jmp 3f
@@ -477,6 +483,8 @@ ENTRY(_stext)
 .section ".bss.page_aligned","w"
 ENTRY(swapper_pg_dir)
.fill 1024,4,0
+ENTRY(swapper_pg_pmd)
+   .fill 1024,4,0  
 ENTRY(empty_zero_page)
.fill 4096,1,0
 
diff --git a/arch/x86_64/kernel/early_printk.c 
b/arch/x86_64/kernel/early_printk.c
index d4050a5..71f2f88 100644
--- a/arch/x86_64/kernel/early_printk.c
+++ b/arch/x86_64/kernel/early_printk.c
@@ -3,9 +3,19 @@
 #include 
 #include 
 #include 
+#include 
+#include 
+#include 
+#include 
 #include 
 #include 
 #include 
+#include 
+#include 
+#include 
+#define EARLY_PRINTK
+#include "../../../drivers/usb/host/ehci.h"
+
 
 /* Simple VGA output */
 
@@ -155,6 +165,564 @@ static struct console early_serial_console = {
.index =-1,
 };
 
+
+static struct ehci_caps __iomem *ehci_caps;
+static struct ehci_regs __iomem *ehci_regs;
+static struct ehci_dbg_port __iomem *ehci_debug;
+static unsigned dbgp_endpoint_out;
+
+#define USB_DEBUG_DEVNUM 127
+
+#define DBGP_DATA_TOGGLE   0x8800
+#define DBGP_PID_UPDATE(x, tok) \
+   x) ^ DBGP_DATA_TOGGLE) & 0x00) | ((tok) & 0xff))
+
+#define DBGP_LEN_UPDATE(x, len) (((x) & ~0x0f) | ((len) & 0x0f))
+/*
+ * USB Packet IDs (PIDs)
+ */
+
+/* token */
+#define USB_PID_OUT0xe1
+#define USB_PID_IN 0x69
+#define USB_PID_SOF0xa5
+#define USB_PID_SETUP  0x2d
+/* handshake */
+#define USB_PID_ACK0xd2
+#define USB_PID_NAK0x5a
+#define USB_PID_STALL  0x1e
+#define USB_PID_NYET   0x96
+/* data */
+#define USB_PID_DATA0  0xc3
+#define USB_PID_DATA1  0x4b
+#define USB_PID_DATA2  0x87
+#define USB_PID_MDATA  0x0f
+/* Special */
+#define USB_PID_PREAMBLE   0x3c
+#define USB_PID_ERR0x3c
+#define USB_PID_SPLIT  0x78
+#define USB_PID_PING   0xb4
+#define USB_PID_UNDEF_00xf0
+
+#define USB_PID_DATA_TOGGLE0x88
+#define DBGP_CLAIM (DBGP_OWNER | DBGP_ENABLED | DBGP_INUSE)
+
+#define PCI_CAP_ID_EHCI_DEBUG  0xa
+
+#define HUB_ROOT_RESET_TIME50  /* times are in msec */
+#define HUB_SHORT_RESET_TIME   10
+#define HUB_LONG_RESET_TIME200
+#define HUB_RESET_TIMEOUT  500
+
+#define DBGP_MAX_PACKET8
+
+static int dbgp_wait_until_complete(void)
+{
+   unsigned ctrl;
+   for (;;) {
+   ctrl = readl(_debug->control);
+   /* Stop when the transaction is finished */
+   if (ctrl & DBGP_DONE)
+   break;
+   }
+   /* Now that we have observed the completed transaction,
+* clear the done bit.
+*/
+   writel(ctrl | DBGP_DONE, _debug->control);
+   return (ctrl & DBGP_ERROR) ? -DBGP_ERRCODE(ctrl) : DBGP_LEN(ctrl);
+}
+
+static void dbgp_mdelay(int ms)
+{
+   int i;
+   while (ms--) {
+   for (i = 0; i < 1000; i++)
+   outb(0x1, 0x80);
+   }
+}
+
+static void dbgp_breath(void)
+{
+   /* Sleep to give the debug port a chance to breathe */
+}
+
+static int dbgp_wait_until_done(unsigned ctrl)
+{
+   unsigned pids, lpid;
+   int ret;
+
+retry:
+   writel(ctrl | DBGP_GO, _debug->control);
+   ret = dbgp_wait_until_complete();
+   pids = readl(_debug->pids);
+   lpid = DBGP_PID_GET(pids);
+
+   if (ret < 0)
+   return ret;
+
+   /* If the port is getting full or it has dropped data
+* start pacing ourselves, not necessary but it's friendly.
+*/
+   if ((lpid == USB_PID_NAK) || (lpid == USB_PID_NYET))
+   dbgp_breath();
+   
+   /* If I get a NACK reissue the transmission */
+   if (lpid == USB_PID_NAK)
+

Re: [linux-usb-devel] [RFC][PATCH 0/2] x86_64 Early usb debug port support.

2006-12-05 Thread Eric W. Biederman


Ok due to popular demands here is the slightly fixed patch that works
on both i386 and x86_64.  For the i386 version you must not have
HIGHMEM64G enabled. 

I just rolled it all into one patch as I'm to lazy to transmit all
3 of them.

Eric

 arch/i386/kernel/head.S   |8 +
 arch/x86_64/kernel/early_printk.c |  580 +
 arch/x86_64/kernel/head.S |   11 +-
 drivers/usb/host/ehci.h   |8 +
 include/asm-i386/fixmap.h |1 +
 include/asm-x86_64/fixmap.h   |1 +
 6 files changed, 608 insertions(+), 1 deletions(-)

diff --git a/arch/i386/kernel/head.S b/arch/i386/kernel/head.S
index ca31f18..f683565 100644
--- a/arch/i386/kernel/head.S
+++ b/arch/i386/kernel/head.S
@@ -135,6 +135,12 @@ page_pde_offset = (__PAGE_OFFSET  20);
jb 10b
movl %edi,(init_pg_tables_end - __PAGE_OFFSET)
 
+   /* Do an early initialization of the fixmap area */
+   movl $(swapper_pg_dir - __PAGE_OFFSET), %edx
+   movl $(swapper_pg_pmd - __PAGE_OFFSET), %eax
+   addl $0x007, %eax   /* 0x007 = PRESENT+RW+USER */
+   movl %eax, 4092(%edx)
+
 #ifdef CONFIG_SMP
xorl %ebx,%ebx  /* This is the boot CPU (BSP) */
jmp 3f
@@ -477,6 +483,8 @@ ENTRY(_stext)
 .section .bss.page_aligned,w
 ENTRY(swapper_pg_dir)
.fill 1024,4,0
+ENTRY(swapper_pg_pmd)
+   .fill 1024,4,0  
 ENTRY(empty_zero_page)
.fill 4096,1,0
 
diff --git a/arch/x86_64/kernel/early_printk.c 
b/arch/x86_64/kernel/early_printk.c
index d4050a5..71f2f88 100644
--- a/arch/x86_64/kernel/early_printk.c
+++ b/arch/x86_64/kernel/early_printk.c
@@ -3,9 +3,19 @@
 #include linux/init.h
 #include linux/string.h
 #include linux/screen_info.h
+#include linux/usb_ch9.h
+#include linux/pci_regs.h
+#include linux/pci_ids.h
+#include linux/errno.h
 #include asm/io.h
 #include asm/processor.h
 #include asm/fcntl.h
+#include asm/pci-direct.h
+#include asm/pgtable.h
+#include asm/fixmap.h
+#define EARLY_PRINTK
+#include ../../../drivers/usb/host/ehci.h
+
 
 /* Simple VGA output */
 
@@ -155,6 +165,564 @@ static struct console early_serial_console = {
.index =-1,
 };
 
+
+static struct ehci_caps __iomem *ehci_caps;
+static struct ehci_regs __iomem *ehci_regs;
+static struct ehci_dbg_port __iomem *ehci_debug;
+static unsigned dbgp_endpoint_out;
+
+#define USB_DEBUG_DEVNUM 127
+
+#define DBGP_DATA_TOGGLE   0x8800
+#define DBGP_PID_UPDATE(x, tok) \
+   x) ^ DBGP_DATA_TOGGLE)  0x00) | ((tok)  0xff))
+
+#define DBGP_LEN_UPDATE(x, len) (((x)  ~0x0f) | ((len)  0x0f))
+/*
+ * USB Packet IDs (PIDs)
+ */
+
+/* token */
+#define USB_PID_OUT0xe1
+#define USB_PID_IN 0x69
+#define USB_PID_SOF0xa5
+#define USB_PID_SETUP  0x2d
+/* handshake */
+#define USB_PID_ACK0xd2
+#define USB_PID_NAK0x5a
+#define USB_PID_STALL  0x1e
+#define USB_PID_NYET   0x96
+/* data */
+#define USB_PID_DATA0  0xc3
+#define USB_PID_DATA1  0x4b
+#define USB_PID_DATA2  0x87
+#define USB_PID_MDATA  0x0f
+/* Special */
+#define USB_PID_PREAMBLE   0x3c
+#define USB_PID_ERR0x3c
+#define USB_PID_SPLIT  0x78
+#define USB_PID_PING   0xb4
+#define USB_PID_UNDEF_00xf0
+
+#define USB_PID_DATA_TOGGLE0x88
+#define DBGP_CLAIM (DBGP_OWNER | DBGP_ENABLED | DBGP_INUSE)
+
+#define PCI_CAP_ID_EHCI_DEBUG  0xa
+
+#define HUB_ROOT_RESET_TIME50  /* times are in msec */
+#define HUB_SHORT_RESET_TIME   10
+#define HUB_LONG_RESET_TIME200
+#define HUB_RESET_TIMEOUT  500
+
+#define DBGP_MAX_PACKET8
+
+static int dbgp_wait_until_complete(void)
+{
+   unsigned ctrl;
+   for (;;) {
+   ctrl = readl(ehci_debug-control);
+   /* Stop when the transaction is finished */
+   if (ctrl  DBGP_DONE)
+   break;
+   }
+   /* Now that we have observed the completed transaction,
+* clear the done bit.
+*/
+   writel(ctrl | DBGP_DONE, ehci_debug-control);
+   return (ctrl  DBGP_ERROR) ? -DBGP_ERRCODE(ctrl) : DBGP_LEN(ctrl);
+}
+
+static void dbgp_mdelay(int ms)
+{
+   int i;
+   while (ms--) {
+   for (i = 0; i  1000; i++)
+   outb(0x1, 0x80);
+   }
+}
+
+static void dbgp_breath(void)
+{
+   /* Sleep to give the debug port a chance to breathe */
+}
+
+static int dbgp_wait_until_done(unsigned ctrl)
+{
+   unsigned pids, lpid;
+   int ret;
+
+retry:
+   writel(ctrl | DBGP_GO, ehci_debug-control);
+   ret = dbgp_wait_until_complete();
+   pids = readl(ehci_debug-pids);
+   lpid = DBGP_PID_GET(pids);
+
+   if (ret  0)
+   return ret;
+
+   /* If the port is getting full or it has dropped data
+* start pacing ourselves, not necessary but it's friendly.
+*/
+   if ((lpid ==

Re: [linux-usb-devel] [RFC][PATCH 0/2] x86_64 Early usb debug port support.

2006-12-05 Thread Eric W. Biederman

David Brownell [EMAIL PROTECTED] writes:

 On Sunday 03 December 2006 9:09 pm, Eric W. Biederman wrote:

 My driver should be sufficient to work with any EHCI in a realatively
 clean state, and needs no special BIOS support just the hardware.
 This appears to be different than the way the windows drivers are
 using these debug devices.

 I'm glad to see someone finally got progress on this ... :)

 Separately, I forwarded some stuff I did last year ... maybe it'll help.
 You seem to have gotten further.  Have you also observed that the
 NetChip device seems to have polarity issues, such that only one
 end behaves properly?

I haven't yet.  But I don't think I have actually tried turning
the cable around in a very meaningful way yet either.  Possibly
this is something that has been fixed.  I know there are some
odd issues that I have encountered.  Like occasionally I would
need to stop the software on one side, or I would need to unplug
it when things got sufficiently confused.

 Note that this should **NOT** be specific to x86_64, since pretty
 much any PCI based EHCI can do this.  I wouldn't be able to use
 this on my NForce2 box, for example ...

So I took a quick look what it would take to do this truly generically
and even initializing this generally when console code typically
is registered looks like a problem.  Although only because we don't
get around to setting up pci_config space access helpers in a timely
manner.  To some extent that still sucks because you are still being
initialized before the general ehci-hcd code.

Regardless an arch specific i386 variant was easy to throw together.
It still needs a bit of work but it basically worked.

 As for EHCI registers, if this really _needs_ to live outside
 of drivers/usb/host, then I'd suggest linux/usb/ehci.h for
 the relevant declarations ... the linux/usb/*.h headers are
 provided exactly for sharing such declaration between otherwise
 unrelated parts of the tree.

Yep that sounds like the right thing to do.  I think I at least
need to be called from something outside of drivers/usb and may
need the code there.

Doing this in a truly generic fashion looks like a major pain.
Because all of the infrastructure needs to be fixed.

Eric
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

RE: [LinuxBIOS] [linux-usb-devel] [RFC][PATCH 0/2] x86_64 Early usb debug port support.

2006-12-05 Thread Lu, Yinghai



-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of
[EMAIL PROTECTED]
Sent: Tuesday, December 05, 2006 3:01 AM

+static int ehci_wait_for_port(int port)
+{
+  unsigned status;
+  int ret, reps;
+  for (reps = 0; reps = 0; reps++) {
+  status = readl(ehci_regs-status);
+  if (status  STS_PCD) {
+  ret = ehci_reset_port(port);
+  if (ret == 0)
+  return 0;
+  }
+  }
+  return -ENOTCONN;
+}
+

What do you mean by
+   for (reps = 0; reps = 0; reps++) {
?

YH



-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [LinuxBIOS] [linux-usb-devel] [RFC][PATCH 0/2] x86_64 Early usb debug port support.

2006-12-05 Thread Eric W. Biederman

Lu, Yinghai [EMAIL PROTECTED] writes:

 -Original Message-
 From: [EMAIL PROTECTED]
 [mailto:[EMAIL PROTECTED] On Behalf Of
 [EMAIL PROTECTED]
 Sent: Tuesday, December 05, 2006 3:01 AM

+static int ehci_wait_for_port(int port)
+{
+ unsigned status;
+ int ret, reps;
+ for (reps = 0; reps = 0; reps++) {
+ status = readl(ehci_regs-status);
+ if (status  STS_PCD) {
+ ret = ehci_reset_port(port);
+ if (ret == 0)
+ return 0;
+ }
+ }
+ return -ENOTCONN;
+}
+

 What do you mean by
 + for (reps = 0; reps = 0; reps++) {
 ?

If you will not reps is negative.  Roughly it is a loop
that will timeout eventually if a usb debug cable is not present.
Putting some deliberate delays in there so I could be certain
of timing out after a second or two would probably be better, but
I don't have anything that resembles a good timer at that point.

The problem is you have to wait until the ehci notices your usb
debug cable before you reset it and get it going and that can be a
non-trivial amount of time.  So the loop is 100% necessary.

So since I didn't know how many loop iterations made sense I allowed
it to loop for 2^31 times or until reps goes negative.

Eric
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

RE: [LinuxBIOS] [linux-usb-devel] [RFC][PATCH 0/2] x86_64 Early usb debug port support.

2006-12-05 Thread Lu, Yinghai



-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] 
Sent: Tuesday, December 05, 2006 3:50 PM


If you will not reps is negative.  Roughly it is a loop
that will timeout eventually if a usb debug cable is not present.
Putting some deliberate delays in there so I could be certain
of timing out after a second or two would probably be better, but
I don't have anything that resembles a good timer at that point.

You have dbgp_mdelay in your code.

YH


-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

60 matches

Mail list logo