Re: [PATCH] drivers: char: hvc: add arm JTAG DCC console support
On Thu, Apr 7, 2011 at 14:39, RONETIX - Asen Dimov wrote: On 11/30/2010 09:25 PM, Daniel Walker wrote: This driver adds a basic console that uses the arm JTAG DCC to transfer data back and forth. It has support for ARMv6 and ARMv7. This console is created under the HVC driver, and should be named /dev/hvcX (or /dev/hvc0 for example). drivers/char/Kconfig | 9 +++ drivers/char/Makefile | 1 + drivers/char/hvc_dcc.c | 133 ... this DCC driver implements one channel, but what about implementing multiple channels. For example reserve few(3) bits for channel number, and two bits for carried data, then fill the rest bytes with with some data and send the word(32 bits) over DCC. On the Linux side writing on /dev/hvcX puts the number X as channel number, and on the other side the CPU emulator gets the data and redistribute it to TCP/IP socket. I have started write some code implementing this. Are there any one interested in this multiple channels, and are there any one started to work on it? this sort of multiplexing of the data stream sounds like the job for userspace ? or maybe a line discipline ? inserting structured data into the kernel driver doesnt sound right to me ... -mike -- To unsubscribe from this list: send the line unsubscribe linux-arm-msm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] drivers: char: hvc: add arm JTAG DCC console support
* Stephen Boyd sb...@codeaurora.org [101207 11:00]: On 12/01/2010 12:20 PM, Stephen Boyd wrote: Definitely for TX since it seems like a redundant loop, but I agree RX code has changed. Instead of If RX buffer full Poll for RX buffer full Read character from RX buffer we would have If RX buffer full Read character from RX buffer which doesn't seem all that different assuming the RX buffer doesn't go from full to empty between the If and Poll steps. Hopefully Tony knows more. Tony, any thoughts? Sorry for the delay, looks like I'm only 1 month behind with email.. Sounds like it should work to me. I can try it out if you point me to a patch. Regards, Tony -- To unsubscribe from this list: send the line unsubscribe linux-arm-msm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] drivers: char: hvc: add arm JTAG DCC console support
On 01/14/2011 11:19 AM, Tony Lindgren wrote: * Stephen Boyd sb...@codeaurora.org [101207 11:00]: On 12/01/2010 12:20 PM, Stephen Boyd wrote: Definitely for TX since it seems like a redundant loop, but I agree RX code has changed. Instead of If RX buffer full Poll for RX buffer full Read character from RX buffer we would have If RX buffer full Read character from RX buffer which doesn't seem all that different assuming the RX buffer doesn't go from full to empty between the If and Poll steps. Hopefully Tony knows more. Tony, any thoughts? Sorry for the delay, looks like I'm only 1 month behind with email.. Sounds like it should work to me. I can try it out if you point me to a patch. I think you acked the patches to make this change. You can test them out by applying the hvc_dcc cleanups and fixes patches (Message-Id: 1292875718-7980-1-git-send-email-sb...@codeaurora.org) on top of this patch. They were sent as a reply to this thread. Stephen -- Sent by an employee of the Qualcomm Innovation Center, Inc. The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum. -- To unsubscribe from this list: send the line unsubscribe linux-arm-msm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] drivers: char: hvc: add arm JTAG DCC console support
On 12/01/2010 12:20 PM, Stephen Boyd wrote: Definitely for TX since it seems like a redundant loop, but I agree RX code has changed. Instead of If RX buffer full Poll for RX buffer full Read character from RX buffer we would have If RX buffer full Read character from RX buffer which doesn't seem all that different assuming the RX buffer doesn't go from full to empty between the If and Poll steps. Hopefully Tony knows more. Tony, any thoughts? -- Sent by an employee of the Qualcomm Innovation Center, Inc. The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum. -- To unsubscribe from this list: send the line unsubscribe linux-arm-msm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] drivers: char: hvc: add arm JTAG DCC console support
On Tue, 2010-11-30 at 21:30 -0800, Stephen Boyd wrote:
On 11/30/2010 11:25 AM, Daniel Walker wrote:
@@ -682,6 +682,15 @@ config HVC_UDBG
select HVC_DRIVER
default n
+config HVC_DCC
+ bool ARM JTAG DCC console
+ depends on ARM
+ select HVC_DRIVER
+ help
+ This console uses the JTAG DCC on ARM to create a console under
the HVC
Looks like you added one too many spaces for indent here.
The first line is fine, but the other two might need an extra space.
diff --git a/drivers/char/hvc_dcc.c b/drivers/char/hvc_dcc.c
new file mode 100644
index 000..6470f63
--- /dev/null
+++ b/drivers/char/hvc_dcc.c
+static inline u32 __dcc_getstatus(void)
+{
+ u32 __ret;
+
+ asm(mrc p14, 0, %0, c0, c1, 0 @ read comms ctrl reg
+ : =r (__ret) : : cc);
+
+ return __ret;
+}
Without marking this asm volatile my compiler decides it can cache the
value of __ret in a register and then check the value of it continually
in hvc_dcc_put_chars() (I had to replace get_wait/put_wait with 1 and
fixup the branch otherwise my disassembler barfed on __dcc_(get|put)char).
hvc_dcc_put_chars:
0: ee103e11mrc 14, 0, r3, cr0, cr1, {0}
4: e3a0c000mov ip, #0 ; 0x0
8: e2033202and r3, r3, #536870912 ; 0x2000
c: ea06b 2c hvc_dcc_put_chars+0x2c
10: e353cmp r3, #0 ; 0x0
14: 1afdbne 10 hvc_dcc_put_chars+0x10
18: e7d1000cldrbr0, [r1, ip]
1c: ee10fe11mrc 14, 0, pc, cr0, cr1, {0}
20: 2afdbcs 1c hvc_dcc_put_chars+0x1c
24: ee000e15mcr 14, 0, r0, cr0, cr5, {0}
28: e28cc001add ip, ip, #1 ; 0x1
2c: e15c0002cmp ip, r2
30: baf6blt 10 hvc_dcc_put_chars+0x10
34: e1a2mov r0, r2
38: e12fff1ebx lr
As you can see, the value of the mrc is checked against DCC_STATUS_TX
(bit 29) and then stored in r3 for later use. Marking this volatile
produces the following:
hvc_dcc_put_chars:
0: e3a03000mov r3, #0 ; 0x0
4: ea07b 28 hvc_dcc_put_chars+0x28
8: ee100e11mrc 14, 0, r0, cr0, cr1, {0}
c: e3100202tst r0, #536870912 ; 0x2000
10: 1afcbne 8 hvc_dcc_put_chars+0x8
14: e7d10003ldrbr0, [r1, r3]
18: ee10fe11mrc 14, 0, pc, cr0, cr1, {0}
1c: 2afdbcs 18 hvc_dcc_put_chars+0x18
20: ee000e15mcr 14, 0, r0, cr0, cr5, {0}
24: e2833001add r3, r3, #1 ; 0x1
28: e1530002cmp r3, r2
2c: baf5blt 8 hvc_dcc_put_chars+0x8
30: e1a2mov r0, r2
34: e12fff1ebx lr
which looks better.
I marked all the asm in this driver as volatile. Is that correct?
Are you talking about __dcc_getstatus only? I don't think adding
volatile is going to hurt anything, if not having it causes problems.
+#if defined(CONFIG_CPU_V7)
+static inline char __dcc_getchar(void)
+{
+ char __c;
+
+ asm(get_wait: mrc p14, 0, pc, c0, c1, 0 \n\
+ bne get_wait \n\
+ mrc p14, 0, %0, c0, c5, 0 @ read comms data reg
+ : =r (__c) : : cc);
+
+ return __c;
+}
+#else
+static inline char __dcc_getchar(void)
+{
+ char __c;
+
+ asm(mrc p14, 0, %0, c0, c5, 0 @ read comms data reg
+ : =r (__c));
+
+ return __c;
+}
+#endif
+
+#if defined(CONFIG_CPU_V7)
+static inline void __dcc_putchar(char c)
+{
+ asm(put_wait: mrc p14, 0, pc, c0, c1, 0 \n\
+ bcs put_wait \n\
+ mcr p14, 0, %0, c0, c5, 0
+ : : r (c) : cc);
+}
+#else
+static inline void __dcc_putchar(char c)
+{
+ asm(mcr p14, 0, %0, c0, c5, 0 @ write a char
+ : /* no output register */
+ : r (c));
+}
+#endif
+
I don't think both the v7 and v6 functions are necessary. It seems I can
get away with just the second version of __dcc_(get|put)char() on a v7.
The mrc p14, 0, pc, c0, c1, 0 will assign the top 4 bits (31-28) to the
condition codes NZCV on v7. It also looks like on an ARM11 (a v6) will
also do the same thing if I read the manuals right. The test in the
inline assembly is saying, wait for a character to be ready or wait for
a character to be read then actually write a character or read one. The
code in hvc_dcc_put_chars() is already doing the same thing, albeit in a
slightly different form. Instead of getting the status bits put into the
condition codes and looping with bne or bcs it will read the register,
and it with
Re: [PATCH] drivers: char: hvc: add arm JTAG DCC console support
On Wed, Dec 01, 2010 at 10:54:56AM -0800, Daniel Walker wrote: On Tue, 2010-11-30 at 21:30 -0800, Stephen Boyd wrote: On 11/30/2010 11:25 AM, Daniel Walker wrote: @@ -682,6 +682,15 @@ config HVC_UDBG select HVC_DRIVER default n +config HVC_DCC + bool ARM JTAG DCC console + depends on ARM + select HVC_DRIVER + help + This console uses the JTAG DCC on ARM to create a console under the HVC Looks like you added one too many spaces for indent here. The first line is fine, but the other two might need an extra space. For this, or any other changes you want, I'll gladly take a follow-on patch as this one is already in my tty-next tree. thanks, greg k-h -- To unsubscribe from this list: send the line unsubscribe linux-arm-msm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] drivers: char: hvc: add arm JTAG DCC console support
On 12/01/2010 10:54 AM, Daniel Walker wrote:
Are you talking about __dcc_getstatus only? I don't think adding
volatile is going to hurt anything, if not having it causes problems.
Just marking __dcc_getstatus volatile gives me
0038 hvc_dcc_get_chars:
38: ee10fe11mrc 14, 0, pc, cr0, cr1, {0}
3c: 1afdbne 38 hvc_dcc_get_chars
40: ee103e15mrc 14, 0, r3, cr0, cr5, {0}
44: e3a0mov r0, #0 ; 0x0
48: e6ef3073uxtbr3, r3
4c: ea04b 64 hvc_dcc_get_chars+0x2c
50: ee10ce11mrc 14, 0, ip, cr0, cr1, {0}
54: e31c0101tst ip, #1073741824 ; 0x4000
58: 012fff1ebxeqlr
5c: e7c13000strbr3, [r1, r0]
60: e281add r0, r0, #1 ; 0x1
64: e152cmp r0, r2
68: baf8blt 50 hvc_dcc_get_chars+0x18
6c: e12fff1ebx lr
Seems the compiler keeps the value of __dcc_getchar() in r3 for the
duration of the loop. So we need to mark that one volatile too. I don't
think __dcc_putchar() needs to be marked volatile but it probably
doesn't hurt.
We could maybe drop the looping for TX, but RX has no C based looping
even tho for v7 it's recommended that we loop (presumably for v6 it's
not recommended).
Definitely for TX since it seems like a redundant loop, but I agree RX
code has changed. Instead of
If RX buffer full
Poll for RX buffer full
Read character from RX buffer
we would have
If RX buffer full
Read character from RX buffer
which doesn't seem all that different assuming the RX buffer doesn't go
from full to empty between the If and Poll steps. Hopefully Tony knows more.
Like this?
for (i = 0; i count; ++i) {
if (__dcc_getstatus() DCC_STATUS_RX)
buf[i] = __dcc_getchar();
else
break;
}
It's a micro clean up I guess ..
Yes, it's much clearer that way.
--
Sent by an employee of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum.
--
To unsubscribe from this list: send the line unsubscribe linux-arm-msm in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] drivers: char: hvc: add arm JTAG DCC console support
On Tuesday 30 November 2010, Nicolas Pitre wrote: Cc: Tony Lindgren t...@atomide.com Cc: Arnd Bergmann a...@arndb.de Cc: Nicolas Pitre n...@fluxnic.net Cc: Greg Kroah-Hartman gre...@suse.de Cc: Mike Frysinger vap...@gentoo.org Signed-off-by: Daniel Walker dwal...@codeaurora.org Acked-by: Nicolas Pitre nicolas.pi...@linaro.org Acked-by: Arnd Bergmann a...@arndb.de This doesn't support both ARMv6 and ARMv7 at run time, but this can trivially be added later when needed. I was about to make a similar comment when I saw yours ;-) -- To unsubscribe from this list: send the line unsubscribe linux-arm-msm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
