| 00:00.24 | chrisf_ | trying to do in-kernel rs485 support for a 16550A-compatible uart on a pxa270... any hints? has this been done before? is this a stupid idea? etc |
| 00:01.06 | chrisf_ | i have an existing driver hack that exposes the uart state to userspace via /proc, but that's crap because you have to poll it |
| 00:02.18 | roxfan | well, i would guess you'll need to either modify an existing (rs232?) driver or port one from another system |
| 00:02.21 | MonMotha | chrisf_: what I've seen done usually is just a compile time option in the BSP definitions to dump a UART into the built in RS-485 mode |
| 00:02.34 | MonMotha | if the UART doesn't have a built-in RS-485 mode, just create something to manage it and again add BSP definitions |
| 00:03.08 | MonMotha | in most cases, the board itself defines the medium type (RS-232 with or without handshaking, bare TTL, RS-422, RS-485, IrDA, etc.), so no need to make things like that userspace configurable |
| 00:04.06 | chrisf_ | if i pastebin the hacked source for this driver, can you have a look and tell me whether that's doable? |
| 00:04.53 | chrisf_ | $(KERNEL_SOURCE)/drivers/serial/pxa.c: http://pastebin.com/m3435e44b |
| 00:05.24 | chrisf_ | you can clearly see the /proc hack there at the end - subtly broken as it is. |
| 00:06.02 | chrisf_ | afaik, "rs485 mode" on these things is auto-toggling rts. |
| 00:06.09 | chrisf_ | all i want to do is: |
| 00:06.40 | chrisf_ | - just before tx start, assert RTS - asap after tx end, deassert RTS |
| 00:08.04 | chrisf_ | ive got the 16550 docs - it looks like MCR[RTS] controls the line, im just not sure where to put the code. |
| 00:09.16 | chrisf_ | no doubt there's also some settle time requirements, on the order of a few microseconds, which i assume can be dealt with via udelay() or whatever |
| 00:10.22 | roxfan | it seems it has auto-flow which might handle rts and cts itself |
| 00:11.16 | roxfan | Auto-flow mode can be used in two ways: full auto-flow, automating both nCTS and nRTS; and |
| 00:11.16 | roxfan | half auto-flow, automating only nCTS. To enable full auto-flow, set bits MCR[1] and MCR[5]. To |
| 00:11.16 | roxfan | enable auto-nCTS-only mode, set MCR[5] and clear MCR[1]. |
| 00:11.16 | roxfan | hm, "Auto-flow mode can be used only in conjunction with FIFO mode." |
| 00:11.23 | roxfan | maybe not your case then |
| 00:32.06 | roxfan | killed the chat >.> |
| 01:03.29 | chrisf_ | i dont want autoflow |
| 01:03.54 | chrisf_ | i want to use the RTS to attach my transmitter to the rs485 bus |
| 01:04.37 | chrisf_ | this is the same as the NT serial driver's RTS_CONTROL_TOGGLE mode |
| 01:31.34 | *** join/#elinux thraxisp (n=thraxisp@24.139.16.154) |
| 01:40.03 | *** join/#elinux SarahEmm (n=SarahEmm@meowcat.net) |
| 02:08.51 | chrisf_ | roxfan: you still there? |
| 02:09.08 | *** join/#elinux thraxisp1 (n=Adium@24.139.16.154) |
| 02:22.52 | MonMotha | chrisf_: I don't see how this isn't doable. Many SoC's already have an auto-485 mode, though. |
| 02:23.23 | chrisf_ | ill pastebin my patch; tell me if im doing something really dumb |
| 02:24.16 | chrisf_ | http://pastebin.com/m5c006f9e |
| 02:24.31 | chrisf_ | ive not hacked the kernel before, so i may be doing something stupid. |
| 02:25.26 | MonMotha | can you just pastebin the whole file, rather than the diff? |
| 02:25.44 | MonMotha | I don't have enough context in that to figure out where you are since I'm not familiar with the PXA drivers. |
| 02:26.29 | MonMotha | I don't see any no-nos as long as that's all in user context. Calling udelay from interrupt context is frowned upon (though it shouldn't deadlock or anything) |
| 02:28.42 | chrisf_ | the original source is here: http://pastebin.com/m3435e44b |
| 02:40.51 | chrisf_ | here's the patched sources http://pastebin.com/m48065bce |
| 02:45.21 | MonMotha | chrisf_: looks like the routines you are patching are called from an interrupt handler. You can use udelay in an interrupt handler, but it's frowned upon. Be sure to keep the delays *REALLY* short. |
| 02:45.42 | MonMotha | calling udelay in an interrupt handler causes the CPU to just sit there doing absolutely NOTHING (not even servicing other interrupts) |
| 02:45.57 | chrisf_ | i got that. |
| 02:46.04 | MonMotha | that said, build it and see if it works :) |
| 02:46.12 | chrisf_ | i assume it does what i think it does - wait for N us? |
| 02:46.23 | MonMotha | yup |
| 02:46.27 | MonMotha | it's a busy wait |
| 02:46.34 | MonMotha | i.e. it just sits there burning time in a calibrated loop |
| 02:47.00 | chrisf_ | ok, cool. |
| 02:47.01 | MonMotha | in an interrupt, that'll get you an exact wait (which could be what you need for your "line release" timing), but the CPU also isn't able to do ANYTHING else, so you have to keep them brief |
| 02:47.30 | chrisf_ | it should just be a few us. |
| 02:48.22 | chrisf_ | my rs485 transceiver is meant to be up & stable in <100ns.. add line impedance and its a bit more, but not much. |
| 02:48.41 | MonMotha | that should be OK |
| 02:48.43 | chrisf_ | and awesomely, that code doesnt build, because i screwed up :) |
| 02:48.51 | MonMotha | anything more than about 100us tends to cause problems with interactivity |
| 02:49.06 | chrisf_ | im a bit worried about the tx stop |
| 02:49.12 | chrisf_ | since there's a fifo. |
| 02:49.45 | chrisf_ | and that's potentially going to sit there from the last fill point until the uart is empty |
| 02:49.54 | MonMotha | um, that's very bad |
| 02:50.04 | MonMotha | don't you get a "TX FIFO empty" interrupt? |
| 02:50.10 | chrisf_ | at halfway. |
| 02:50.16 | MonMotha | or, even better, a "transmit complete" interrupt |
| 02:52.05 | chrisf_ | i havent found anything :( it's a pxa's 16550-compat BTUART |
| 02:53.48 | MonMotha | looks like a 16550 should have a "transmit holding register empty" interrupt. You should get that right as the last character from the FIFO starts to be transmitted |
| 02:54.25 | chrisf_ | ok, in response to that, transmit_chars() gets called. |
| 02:55.52 | MonMotha | interesting...that's not how I would have written the driver, but OK |
| 02:56.09 | MonMotha | unfortunately, it looks like if you want to avoid a busy wait of at least one character time, you'll need a timer |
| 02:57.01 | MonMotha | grab the "I'm on the last character in the FIFO" condition, set a timer for slightly less than one character length, let the timer interrupt handler busy wait out the remainder of the time (possibly polling the UART to see if it's done, if possible), then release the transceiver |
| 02:57.07 | MonMotha | ugly, but 16550 UARTs aren't exactly modern |
| 02:58.49 | chrisf_ | they are fairly well understood, though. |
| 02:59.07 | chrisf_ | i guess id rather have a 16550 than some random thing |
| 02:59.47 | MonMotha | eh, UART drivers aren't exactly common |
| 02:59.55 | MonMotha | and most Linux-supported SoCs already have drivers for them |
| 03:00.11 | MonMotha | and most of them support some form of auto-485 operation in hardware (even if the Linux driver doesn't) |
| 03:03.28 | chrisf_ | well apparently this doesnt :( |
| 03:03.46 | chrisf_ | win, kernel builds now. |
| 03:03.56 | chrisf_ | always a good start :) |
| 03:38.34 | chrisf_ | MonMotha: how to print a debug message to the console from the kernel? |
| 03:39.35 | MonMotha | kprintf(...) |
| 03:39.46 | MonMotha | you'll need to spec a loglevel for the print |
| 03:40.40 | chrisf_ | ok, whats a good default? |
| 03:40.58 | MonMotha | well, it depends on what you're logging |
| 03:41.28 | MonMotha | if you're logging "I'm dead" conditions, critical is good, but if it's register dumps, debug might be better |
| 03:42.19 | chrisf_ | its just debug stuff. |
| 03:42.44 | MonMotha | KERN_DEBUG would be appropriate, then |
| 03:43.17 | chrisf_ | where do i find the docs for this? |
| 03:43.42 | chrisf_ | google is sucking |
| 03:44.30 | MonMotha | google the "lxr" |
| 03:44.41 | MonMotha | it's a big cross-reference thing automatically generated on the kernel source |
| 03:44.46 | MonMotha | very handy |
| 03:57.03 | chrisf_ | cool. |
| 04:01.04 | chrisf_ | ok, it sortof works |
| 04:01.29 | chrisf_ | ended up just using printk |
| 04:02.15 | chrisf_ | here's my current source: http://pastebin.com/m4cc98796 |
| 04:03.46 | chrisf_ | it stops after printing *rs485 start*. |
| 04:04.51 | chrisf_ | for example, |
| 04:05.42 | chrisf_ | $ echo "hello" > /dev/ttyS1 |
| 04:05.44 | chrisf_ | *rs485 start* |
| 04:05.45 | chrisf_ | ^C |
| 04:05.47 | chrisf_ | *rs485 end* |
| 04:05.48 | chrisf_ | *rs485 idle* |
| 04:07.04 | chrisf_ | confirmed that this is caused by my code. prehack kernel works correctly (but no 485, obviously) |
| 04:11.34 | MonMotha | sounds like you've got a deadlock |
| 04:11.34 | MonMotha | and yeah, it's printk, not kprintf |
| 04:11.34 | MonMotha | been a while since I was in the kernel |
| 04:15.05 | chrisf_ | kernel deadlocks dont take out the machine? nice. |
| 04:15.12 | chrisf_ | (i can recover with ^C) |
| 04:21.04 | chrisf_ | so why is that deadlocking? |
| 04:22.18 | chrisf_ | i know its not the printk |
| 05:17.01 | chrisf_ | MonMotha: if you're still there; the source of the problem was NOT a deadlock. |
| 05:17.24 | chrisf_ | but stale bits in register image. |
| 05:17.53 | chrisf_ | doing up->mcr = serial_in( up, UART_MCR ) before trying to turn on rts makes it work. |
| 05:50.19 | *** join/#elinux pleemans (n=toi@d54C2AAB7.access.telenet.be) |
| 06:06.18 | *** join/#elinux tsjsieb (n=tsjsieb@dejongbeheer.nl) |
| 06:11.42 | *** join/#elinux lyakh (n=lyakh@p57BD1C08.dip0.t-ipconnect.de) |
| 06:16.23 | *** join/#elinux hw__ (n=hw@87.139.57.5) |
| 06:40.51 | *** join/#elinux harpal (n=Harpal@121.246.75.165) |
| 06:47.48 | *** join/#elinux pytey (n=pytey@84.233.192.144) |
| 06:58.01 | methril|work | yo |
| 08:35.12 | *** join/#elinux Madsy (n=madsy@ti0207a340-0714.bb.online.no) |
| 10:16.40 | *** join/#elinux ibot (i=ibot@rikers.org) |
| 10:16.40 | *** topic/#elinux is Embedded Linux || http://eLinux.org/ || cross compile, uClibc, busybox, handhelds, post-sale linux installs ;-), etc. |
| 10:16.40 | *** mode/#elinux [+o ibot] by ChanServ |
| 10:57.47 | *** join/#elinux pirho (i=pirho@gateway/gpg-tor/key-0x2CEEC9CB) |
| 11:25.26 | *** join/#elinux tsjsieb (n=tsjsieb@dejongbeheer.nl) |
| 12:11.07 | *** join/#elinux gustavoz (n=gustavoz@imhotep.toptech.com.ar) |
| 12:50.03 | *** join/#elinux GPSFan (n=kenm@64.92.145.112) |
| 13:44.32 | *** join/#elinux Dr_Who (n=tgall@gentoo/developer/dr-who) |
| 14:42.29 | *** join/#elinux Othello (i=Othello@gateway/tor/x-3388951554aebbf9) |
| 15:05.30 | *** join/#elinux TimRiker (i=timr@2002:ad75:2a64:0:0:0:0:1) |
| 15:05.30 | *** mode/#elinux [+o TimRiker] by ChanServ |
| 15:15.34 | *** join/#elinux thraxisp (n=thraxisp@century.precidia.com) |
| 15:16.02 | *** join/#elinux thraxisp_ (n=thraxisp@century.precidia.com) |
| 15:49.59 | *** join/#elinux Dr_Who (n=tgall@gentoo/developer/dr-who) |
| 16:28.54 | *** join/#elinux Dr_Who (n=tgall@gentoo/developer/dr-who) |
| 16:29.35 | *** join/#elinux linac (n=lin@123.249.160.78) |
| 16:49.42 | *** join/#elinux pcgeil (n=steffen@p5B17F9E1.dip.t-dialin.net) |
| 17:37.39 | *** join/#elinux pirho (i=pirho@gateway/gpg-tor/key-0x2CEEC9CB) |
| 17:54.14 | *** join/#elinux albech_ (n=albech@119.42.76.2) |
| 18:40.23 | *** join/#elinux markl (n=mark@tpsit.com) |
| 19:21.43 | *** join/#elinux roxfan (n=dunno@165.44-244-81.adsl-dyn.isp.belgacom.be) |
| 21:14.16 | *** join/#elinux flavioribeiro (n=avaty@189.71.70.187) |
| 21:35.53 | chrisf_ | anyone who may have been listening to the rs485 stuff yesterday, here's a patch which works (not mine!) http://markmail.org/message/uyw4hqsipap5z4il |
| 21:41.56 | *** join/#elinux CIA-53 (n=CIA@208.69.182.149.simpli.biz) |
| 21:42.30 | *** join/#elinux gandhijee (i=akp@host-66-202-34-165.spr.choiceone.net) |
| 22:14.15 | *** join/#elinux likewise (n=chatzill@82-171-51-231.ip.telfort.nl) |
| 22:27.45 | *** join/#elinux jlg (n=jlg@lit75-2-87-91-59-235.dsl.club-internet.fr) |
| 22:45.21 | *** join/#elinux jlg_ (n=jlg@lit75-2-87-91-59-235.dsl.club-internet.fr) |
| 23:08.43 | *** join/#elinux thraxisp (n=thraxisp@24.139.16.154) |
| 23:16.11 | *** join/#elinux SarahEmm (n=SarahEmm@meowcat.net) |