**** BEGIN LOGGING AT Thu Nov 05 03:00:15 2015
Nov 05 03:00:18 <zmatt> (the DM814x TRM has somewhat more info than the AM335x TRM)
Nov 05 03:03:29 <ds2> no numbers in the am335x one... will look in the other one later
Nov 05 03:03:44 <zmatt> no numbers there either afaik
Nov 05 03:03:56 <ds2> oh blah
Nov 05 03:04:00 <zmatt> you asked whether it has... not how much
Nov 05 03:04:15 <ds2> trying to see how useful it is as a parallel core
Nov 05 03:06:47 <zmatt> veremit: I see no evidence yet that the kernel is waiting until transmit is complete, but still staring
Nov 05 03:07:46 <zmatt> would have to be somewhere in 8250_omap.c I geuss
Nov 05 03:07:48 <zmatt> *guess
Nov 05 03:09:53 <zmatt> oh btw, never change sw/hw handshake options on the fly, this may lead to random data corruption
Nov 05 03:10:02 <zmatt> another nice feature of the modal register interface
Nov 05 03:13:17 <veremit> zmatt .. lol
Nov 05 03:13:30 <veremit> interesting so far though
Nov 05 03:13:43 <veremit> you on mainline?
Nov 05 03:14:08 <zmatt> no, good point, I'm on.. eh..
Nov 05 03:14:20 <zmatt> 4.1.9-ti-r20
Nov 05 03:14:30 <veremit> oh ok .. mainline  -ish
Nov 05 03:14:35 <veremit> nearly.almost.
Nov 05 03:14:40 <zmatt> ?
Nov 05 03:14:57 <veremit> lol nvm
Nov 05 03:15:05 <zmatt> if you call *that* mainline-ish, what exactly isn't?
Nov 05 03:15:06 <zmatt> :P
Nov 05 03:15:23 <veremit> what is stable up to these days?
Nov 05 03:15:33 <zmatt> how should I know
Nov 05 03:15:37 <veremit> 4.0.5 is the latest I've built
Nov 05 03:15:44 <veremit> and thats x64
Nov 05 03:15:46 <zmatt> this is really funny
Nov 05 03:16:00 <veremit> well... I was just satyin :p
Nov 05 03:16:08 <veremit> -t
Nov 05 03:16:47 <zmatt> veremit: I think I'm gonna look at serial output on the scope myself next time I'm in the office, I expect it'll be funny
Nov 05 03:17:02 <veremit> oh .. lol
Nov 05 03:17:07 <zmatt> wait, I think I still use the omap-serial driver, it might be saner
Nov 05 03:17:12 <veremit> funny haha?! or...
Nov 05 03:18:01 <zmatt> well, if I'm reading this right, it seems the kernel does wait for transmit complete (i.e. fifo drained and tx serializer idle)
Nov 05 03:18:06 <zmatt> for every char
Nov 05 03:18:13 <veremit> erm .. oh.
Nov 05 03:18:26 <zmatt> I hope I'm misreading it
Nov 05 03:18:39 <veremit> thats funny-hilarious..totally fuckedup
Nov 05 03:18:43 <veremit> :/
Nov 05 03:18:50 <zmatt> it's a big enough mess of code so I might be
Nov 05 03:18:55 <zmatt> blergh
Nov 05 03:19:19 <veremit> all things are possible..
Nov 05 03:20:38 <zmatt> but if that's fixed, then the rs485 will deassert TXEN with data still in the fifo, you'd need to configure delays to avoid that
Nov 05 03:20:58 <zmatt> the main 8250 code has no notion of txempty at all afaict
Nov 05 03:21:28 <veremit> ah great
Nov 05 03:21:43 <zmatt> which makes sense since it's multiplexed with the normal tx ready event on the same irq bit
Nov 05 03:21:56 <zmatt> you select which of the two you want in an omap-specific config register
Nov 05 03:22:15 <veremit> ugh really
Nov 05 03:22:28 <zmatt> this sort of thing is exactly why having a "generic" 8250 driver makes no sense to me
Nov 05 03:22:42 <zmatt> that thing is already riddled with special cases for many variants
Nov 05 03:23:41 <zmatt> and probably works suboptimal on most of them
Nov 05 03:23:48 <veremit> well .. regrettably, 1) thats not surprising and 2) another 'special ccase' won't hurt ..
Nov 05 03:24:31 <zmatt> it's not really a special case though... most uarts have fifos, I just have no idea how you know about txempty on those
Nov 05 03:25:04 <veremit> I guess it's assumed you don't want/need to know :(
Nov 05 03:25:26 <veremit> which is a lie .. cos you might
Nov 05 03:25:35 <veremit> you certainly do in microcontroller-land
Nov 05 03:26:00 <zmatt> you could also change the write burst size to the whole fifo size to know when that is empty (although that's still one char before txempty)
Nov 05 03:26:11 <zmatt> or rather, I could do that in my driver
Nov 05 03:26:31 <zmatt> since I leave access open to the fifo config regs instead of the useless modem status register
Nov 05 03:26:44 <zmatt> but that's not being 8250-compatible of course
Nov 05 03:27:18 <veremit> nothing wrong with having some,. as ds2 suggested ... Omap 'extensions' .. you can even enable/disable them ! :D
Nov 05 03:27:51 <zmatt> and make the driver even more complex :D  because everybody knows that's the best way to get a well-working driver
Nov 05 03:28:11 <veremit> of course!!! :D
Nov 05 03:28:57 <zmatt> maybe consider using uio instead of the kernel driver
Nov 05 03:28:58 <zmatt> :P
Nov 05 03:29:30 <zmatt> I'd even be willing to share the magic incantations needed to initialize the thing
Nov 05 03:30:06 <veremit> uio?!
Nov 05 03:32:03 <zmatt> uio_pdrv_genirq ... it's like a little chunk of /dev/mem in a device (which you can give proper permissions using an udev rule, so no need to be root unlike /dev/mem) and it even supports irq delivery to userspace
Nov 05 03:32:21 <zmatt> designed to allow writing drivers in userspace
Nov 05 03:33:13 <veremit> ah
Nov 05 03:33:16 <veremit> clever
Nov 05 03:34:02 <zmatt> http://pastebin.com/GrHwgYiR  <-- that's for example all that's needed to make the adc show up as /dev/uio/adc
Nov 05 03:34:22 <zmatt> an analogous device tree node would work for an uart
Nov 05 03:34:49 <zmatt> unlike /dev/mem, the kernel will even enable the module clocks for you when you open the device
Nov 05 03:35:03 <veremit> ah so you're directly exposing the peripheral
Nov 05 03:35:55 <veremit> from device tree into userspace .. via its registers?
Nov 05 03:36:35 <zmatt> device tree just declares that the uio_pdrv_genirq should be used for it
Nov 05 03:36:50 <zmatt> I reuse the existing DT node which already declares the module's register ranges, irq, etc
Nov 05 03:39:09 * zmatt really ought to make some good uio examples for the BBB
Nov 05 03:40:27 <zmatt> you can also do funny stuff like make an uio device whose irq is a gpio (level or edge)
Nov 05 03:55:59 <veremit> zmatt .. did you see the 8250_omap on http://lists.infradead.org/pipermail/linux-arm-kernel/2014-July/271068.html ?
Nov 05 03:56:25 <veremit> possibly a better bet?
Nov 05 03:57:37 <zmatt> veremit: that's the driver I looked at, except I was looking at a newer one
Nov 05 03:57:50 <zmatt> or maybe not newer
Nov 05 03:58:21 <zmatt> in any case, I didn't look at omap-serial since you linked to patches for the 8250 version
Nov 05 03:59:39 <veremit> yea everything is going 8250-based. Does the TI kernel still use the omap-serial ?
Nov 05 03:59:55 <veremit> and does that even work?!
Nov 05 04:00:06 <zmatt> no idea, I still do in my own kernels
Nov 05 04:00:10 <zmatt> why on earth wouldn't it?
Nov 05 04:00:36 <veremit> -shrug-
Nov 05 04:00:57 <zmatt> a driver specific to omap-serial makes far more sense to me than this pile of 8250 crap
Nov 05 04:01:19 <zmatt> (note that I haven't looked at the omap-serial driver itself, it may very well also be a pile of crap)
Nov 05 04:01:39 <zmatt> it's just for the console anyway
Nov 05 04:01:46 <zmatt> if I needed it for serious use I would use uio
Nov 05 04:02:26 <veremit> heh ok
Nov 05 04:02:50 <veremit> the one I linked looks a better approach
Nov 05 04:03:29 <veremit> ah and then there's the mctrl_helpers ..
Nov 05 04:03:32 <zmatt> I have no idea what you're referring to right now
Nov 05 04:03:34 <veremit> but that's omap
Nov 05 04:06:22 <veremit> zmatt .. I linked two sets I believe.
Nov 05 04:06:35 <veremit> based on 8250 with and without _omap suffix
Nov 05 04:07:30 <zmatt> you linked something, and then gave a different link saying "update" so I used that one
Nov 05 04:07:37 <veremit> Oh.. I didn't notice .. 8250_omap has been adopted .. but are there any 485 patches ..
Nov 05 04:07:48 <zmatt> you linked to them
Nov 05 04:07:59 <zmatt> the 485 patches for 8250
Nov 05 04:08:33 <zmatt> _omap just provides some init/support functions
Nov 05 04:08:51 <zmatt> 8250_core does the actual data transfer, hence that's where the 485 patches go
Nov 05 04:09:11 <veremit> ok now I'm confused lol
Nov 05 04:09:20 <veremit> ah ok .. that makes senes
Nov 05 04:09:31 <veremit> 485 patches still missing from mainline in the _core.c
Nov 05 04:09:55 <veremit> but yea .. it should be divided up better
Nov 05 04:10:03 <veremit> aka .. Its a Mess(tm)
Nov 05 04:10:34 <zmatt> no it shouldn't be divided up at all
Nov 05 04:10:34 <veremit> so .. based on what you wrote before .. you think you can set the IRQ using the omap 'bits' of the driver? or is it more complex..
Nov 05 04:11:18 <veremit> kernel drivers and c code generally not my forte
Nov 05 04:11:23 <zmatt> right now core has no notion of txempty afaict, hence specific implementations also can't provide this notion
Nov 05 04:11:35 <zmatt> I also don't do kernel programming
Nov 05 04:12:08 <zmatt> everything is complicated there
Nov 05 04:14:06 <zmatt> note that maybe I'm still wrong about the txempty... I eventually got tired staring at that thing
Nov 05 04:15:19 <zmatt> if you have a chance, just hook up a scope and see what the output looks like :P
Nov 05 04:17:12 <veremit> zmatt .. yeah that was broadly my plan ..
Nov 05 04:17:30 <veremit> just poking others who might take even a passing interest :D
Nov 05 09:02:28 <ison> request help to change usb mode from OTG to HOST
Nov 05 09:07:16 <tbr> look at the scripts in opt and disable the bit where it turns device mode on
Nov 05 14:39:50 <Rotti> hi
**** BEGIN LOGGING AT Thu Nov 05 23:50:44 2015
Nov 06 02:13:36 * zmatt decides to skip pointing out to gerald he's contradicting himself -.-
Nov 06 02:38:35 <HardChuck> t
**** ENDING LOGGING AT Fri Nov 06 02:59:58 2015