**** BEGIN LOGGING AT Wed Jan 13 02:59:59 2016 Jan 13 03:00:03 notably he was seeing "lost sync" irqs, which the current driver doesn't check for Jan 13 03:00:14 yeah I agree Jan 13 03:00:21 so that's either the tilcdc driver or lcdc itself Jan 13 03:02:00 there's also a scratch-branch of Tomi Valkeinen (who also participated in the thread) attempting to simplify and fix the driver -> https://git.kernel.org/cgit/linux/kernel/git/tomba/linux.git/log/?h=ti/lcdc-fixing-4.1 Jan 13 03:02:48 zmatt, rcn-ee: best to start with an e2e.ti.com post and then let me escalate from that documentation. Jan 13 03:04:10 I also did some tests with lcdc from baremetal, and am still left puzzled how it's possible he was getting LOST_SYNC... I failed to produce them on purpose except when the frame buffer has the wrong size, but that would require the dma controller to finish a frame exactly between setting the 'start' and 'end' pointers, which are consecutive statements in the tilcdc driver Jan 13 03:07:30 Tomi Valkeinen is a TI employee btw Jan 13 03:08:27 and the thread remained unresolved Jan 13 03:09:20 http://e2e.ti.com/support/arm/sitara_arm/f/791/t/446385?pi316653=5 Jan 13 03:09:38 I'll follow-up with Tomi and the LCDC apps guys... but, trying to get all the info straight can be a pain. A pointer to the e2e post that properly defines the issue is what helps the most. Jan 13 03:10:02 zmatt: is that it? Jan 13 03:10:18 sounds lke there are/should be multiple issues/symptoms... Jan 13 03:10:28 there might be, but I'm not sure Jan 13 03:10:36 since all of them are equally mysterious to me Jan 13 03:11:22 might be worth zmatt writing up what he has done here now on e2e for reference Jan 13 03:11:53 ref'ing anything else that has been found already Jan 13 03:13:24 that thread also left me puzzled about the exact behaviour of lcdc itself... this post summarized my puzzlement best probably -> http://e2e.ti.com/support/arm/sitara_arm/f/791/p/446385/1675351#1675351 Jan 13 03:13:39 I haven't checked yet whether SYNC LOST is also occurring with the issue *I* am seeing Jan 13 03:13:47 the kernel driver doesn't enable that irq Jan 13 03:13:58 which does however mean I can easily check for it via /dev/mem Jan 13 03:14:14 hmm, I think at least, depends on how the irq handler is coded... *checks* Jan 13 03:14:37 (well, otherwise I can easily add a check for it to the irq handler) Jan 13 03:16:55 veremit: what I've done so far on my issue is observe it and be puzzled Jan 13 03:17:21 zmatt: sounds good to me :) Jan 13 03:17:24 I was already puzzled about the jumping (which rcn-ee had apparently also observed already since 3.8) Jan 13 03:17:33 I'm even more puzzled about the new issue Jan 13 03:17:48 clearly we've identified a complex issue ... Jan 13 03:18:20 a long-standing issue Jan 13 03:19:08 who knows, it might turn out really simple and obvious... in hindsight :P Jan 13 03:19:23 once you find it, yeah lol Jan 13 03:20:50 * zmatt grabs barebone, μhdmi cable, and xds100v2 Jan 13 03:21:25 eww leave that extended character outta here :P lolol Jan 13 03:21:27 showoff Jan 13 03:21:49 μ ← that one? Jan 13 03:21:55 yup Jan 13 03:22:02 those Jan 13 03:22:04 ;) Jan 13 03:22:04 all them Jan 13 03:22:17 I'm only 8-bit here :p Jan 13 03:22:24 me too... utf-8 Jan 13 03:22:46 well .. ok because this is is linux, its proper utf8.. but irc uses some weird hybrid Jan 13 03:23:12 I'm using utf-8, period Jan 13 03:23:18 irc itself has no defined encoding Jan 13 03:23:35 yes, thats a key problem .. but I digress .. lcdc Jan 13 03:23:50 fortunately, nowadays everything uses utf-8 anyway Jan 13 03:24:07 doubt windoze does Jan 13 03:24:32 its capable of supporting .. but I think native uses variants of isoZZZZ Jan 13 03:24:45 localised iirc Jan 13 03:25:18 * zmatt doesn't care about deprecated ancient encodings like iso8859-1/15 or utf-16 Jan 13 03:30:08 go fix your client :P Jan 13 03:30:20 it probably has an encoding setting somewhere Jan 13 03:37:23 oh this is perfectly sane Jan 13 03:37:28 well .. except when it isn't Jan 13 03:37:44 :P Jan 13 03:38:06 compatibility .. always makes trouble Jan 13 03:38:14 always someone using strange encodings :p Jan 13 03:38:26 my solution is typically: not caring \o/ Jan 13 03:38:30 ;) Jan 13 03:38:36 yup Jan 13 03:38:47 so .. what's the solution to this lcdc thing, zmatt?! Jan 13 03:39:21 ok, got hdmi output, now let's see if I can get some bogus output Jan 13 04:18:06 is dram, which begins at 0x80000000 aliased up through 0xffffffff? Jan 13 04:18:44 i'm not getting dabort exceptions when i test past 0xa0000000, which is the end of my 512M dram... Jan 13 04:18:46 probably yes Jan 13 04:19:03 or rather 0x9fffffff Jan 13 04:19:05 right. Jan 13 04:19:25 i do if i try 0x40000000 (thankfully rom doesn't test good...) Jan 13 04:19:39 "thou shalt not read secrom" Jan 13 04:19:52 "...nor write it" Jan 13 04:20:01 0x40020000 will read ok (but abort on write :P ) Jan 13 04:21:12 are there usable functions defined there? Jan 13 04:21:43 not any that are documented Jan 13 04:21:55 but there is an api vector table Jan 13 04:22:10 so yes there is an api, just not one TI made public Jan 13 04:22:31 you can also find a crc-ccitt table there if you need it Jan 13 04:24:05 what do you do, spend your nights hacking rom? Jan 13 04:24:07 :) Jan 13 04:25:36 even funnier are the USB string descriptors starting at 0x2953a Jan 13 04:26:29 (on an xam3359azcz100, haven't checked whether they moved in rev b) Jan 13 04:28:04 hhmm. Jan 13 04:28:44 they'll presumably still be thereabouts Jan 13 04:33:08 http://pastebin.com/VxP0VrBP Jan 13 04:35:06 hey, why is this instruction not assembling? "orr r2, r7, lsl r0" Jan 13 04:35:16 Error: garbage following instruction -- `orr r2,r7,lsl r0' Jan 13 04:35:54 ah. Jan 13 04:35:58 I'm not sure whether you can do that in thumb mode, combining an alu op with a variable shift Jan 13 04:36:05 got it. Jan 13 04:36:08 no, this is a1 Jan 13 04:36:34 in that case you probably need an explicit destination reg Jan 13 04:36:37 you MUST specify all the registers, including the destination Jan 13 04:36:46 that's what i just said... lol Jan 13 04:42:24 ok, tv is being annoying, I'll try again later when I have a proper display to test with -.- Jan 13 04:46:55 did you use a mersenne twister for your prng? Jan 13 04:47:53 I think something simpler, like xorshift Jan 13 04:55:10 if you're worried about passing all rigorous statistical tests, apparently this variant does -> https://github.com/MersenneTwister-Lab/XSadd/blob/master/xsadd.h Jan 13 04:55:28 if you generate four words at a time you avoid moving the state around Jan 13 04:58:01 oh heck no. Jan 13 04:58:15 not for this. just a simple xorshift like you used is sufficient. Jan 13 04:58:32 simpler and easier to implement Jan 13 04:58:37 I think I may have used something even simpler, but it's too long ago Jan 13 04:58:51 the first example here: https://en.wikipedia.org/wiki/Xorshift#xorshift.2A Jan 13 05:00:53 actually the linked algo is the same except it uses different shift amounts, returns w+z, and is written in a pointlessly verbose way Jan 13 05:01:38 but yes, the first one one wikipedia will obviously suffice generously Jan 13 05:11:26 hi to all Jan 13 06:35:00 type pixel slips could be a clocking problem Jan 13 06:53:59 s/type/the/ Jan 13 07:52:05 <_dieter> Hello everybody out there Jan 13 07:52:40 <_dieter> I am new to this forum and would like to know if there config files for Beagleboard-X15 for TI's pinmux tool available? Jan 13 07:53:19 * jkridner hasn't looked for the pinmux tool yet for AM572x. Jan 13 07:53:48 looks like AM5728 is supported in the latest version of the tool: http://processors.wiki.ti.com/index.php/TI_PinMux_Tool Jan 13 07:54:00 as far as config files, do you mean for the X15 defaults? Jan 13 07:54:49 * jkridner checks out https://dev.ti.com/pinmux Jan 13 08:03:24 <_dieter> @jkridner no, I mean the settings used for the beagleboard-x15 Jan 13 08:04:58 <_dieter> @jkridner sorry, yes - you asked for the X15 defaults! This is exactly what I am looking for Jan 13 08:05:30 can you ask on the beagleboard-x15 list? I'll be sure the message goes through. Jan 13 08:05:44 https://groups.google.com/forum/#!forum/beagleboard-x15 Jan 13 08:05:59 <_dieter> you mean the google groups forum, right? Jan 13 08:06:16 <_dieter> too fast for me this morning ;) Jan 13 10:07:40 zmatt: I don't mind the kernel setting up the FB again once it is up and running, I just need a preliminary fb during boot. The kernel driver will handle connects/disconnects and probably set up better resolutions etc. Jan 13 13:00:11 hello, any news on x15? Jan 13 13:12:14 hi guys I need some help. I am at my wits end with this element14 board. Can a loose ethernet port prevent a board from booting? I have noticed while trying to get this board to show signs of life that the ethernet port will blink at times. This has happened multiple times during cape removal and every now and then it may boot. Its out of mcm eletronics warranty period and element14 wouldnt do anything about the board Jan 13 13:17:07 What do you mean by 'loose port'? Jan 13 13:17:27 I don't know but in theory u-boot supports networking. Jan 13 14:30:08 jkridner: I also made a preliminary spreadsheet for the x15 ( http://goo.gl/S4t2lw ) Jan 13 15:19:25 zmatt, i want a x15 ;) Jan 13 15:19:53 any reason why they didnt try to match the current beaglebones form factor or something close in size? Jan 13 15:21:53 mistawright: I think they were looking for something more powerful, akin to the older BeagleBoards :-) Jan 13 16:25:30 Any prediction on how much power the BB blue motor controller will make? Jan 13 16:45:26 hi! Jan 13 16:46:35 Trying to create and run beaglebone system in qemu emulator from scratch. Jan 13 16:47:28 Just boot device with u-boot so far. Jan 13 16:50:17 Could u plz show me the way, provide link to guides or docs. Jan 13 16:50:31 I just cannot find the right info I suppose. Jan 13 17:00:49 hi Jan 13 17:08:09 konstunn: you'd need to emulate quite a few peripherals... not necessarily their exact behaviour of course, but at least enough to satisfy the drivers in u-boot and linux Jan 13 17:11:23 off the top of my head you'll at least need some memory device (NOR flash, NAND flash, SD card or eMMC) and the peripheral used to access it (GPMC for NOR/NAND, HSMMC for SD/eMMC), timers, parts of PRCM and the control module Jan 13 17:11:41 serial port for the console Jan 13 17:15:17 the omap-i2c peripheral with an eeprom and pmic attached Jan 13 17:16:19 I think most other stuff could be disabled in kernel config and/or device tree Jan 13 17:16:53 oh, interrupt controller Jan 13 17:17:58 I think there's been previous effort to emulate an omap3, parts of that will be reusable Jan 13 17:19:10 quite a few peripherals acquired a Highlander-compliant wrapper though, so you need to check for that Jan 13 17:19:58 zmat, thanks a lot for your detailed answer Jan 13 17:21:23 zmatt, sorry Jan 13 17:23:01 the global memory map is also different from the omap3; this spreadsheet might be of use -> https://goo.gl/UHF2Fy (start on the "HASS" tab, which shows the local routes within the cortex-a8 subsystem) Jan 13 17:23:41 the columns labeled "Subarctic" refer to the am335x, Centaurus is an earlier chip Jan 13 17:27:39 zmatt, It's worth clarifying that I don't need to implement emulator. I want to configure QEMU (qemu-linaro) to use it for beaglebone emulation. Jan 13 17:28:11 well you can only configure it so if all the ingredients you need are already implemented Jan 13 17:28:39 that's a big "if". Jan 13 17:29:13 especially since PRCM and control module are very device-dependent Jan 13 17:29:51 I hope, they are implemented. Jan 13 17:30:16 I can not manage to configure qemu. The documentation seems poor to me or absent. Can not find good info. Jan 13 17:30:55 note that the am335x is a much newer generation, being a Netra-descendent Jan 13 17:31:56 which also makes it more closely related to omap4 than omap3 Jan 13 17:32:17 Ok. Although it does not sounds familiar and clear for at least this time so far. Jan 13 17:32:31 * does not sound Jan 13 17:33:14 I'm not familiar enough with the capabilities of qemu, but it seems quite likely to me at least some custom code will be needed Jan 13 17:33:39 but you're not the first to want this, so there may be previous efforts of this already Jan 13 17:35:37 qemu can accept "beagle" as -M (machine) option. Jan 13 17:36:03 So it supports it somehow. Jan 13 17:36:55 that's tne old beagleboard though Jan 13 17:36:58 omap3 Jan 13 17:37:09 To be precise, it supports beagle (OMAP3530) and beaglexm (OMAP3630). Jan 13 17:37:14 exactly Jan 13 17:37:44 the beaglebone uses a much newer cpu Jan 13 17:38:12 Do you speak about am335x ? Jan 13 17:38:15 yes Jan 13 17:38:36 it is newer than omap3 and omap4 Jan 13 17:39:19 But are they backward compatible in some degree? Jan 13 17:40:25 somewhat... a number of peripherals are still similar, though as I said some of them have acquired a wrapper Jan 13 17:41:57 This time so far I need only some of them. Only to test u-boot. And create bootable media that would be portable to real hardware. Jan 13 17:41:57 anybody knows how to read data from azure in my beaglebone black? Jan 13 17:43:05 Test u-boot - I mean get the command prompt / shell. Jan 13 17:45:15 And that's all so far this time. Jan 13 17:46:39 for that you need at least a serial peripheral (which is probably still comaptible with omap3, so you just need to instantiate it at the right address), the omap-i2c peripheral I think is slightly different, an emulated i2c eeprom with the right content, and the tps65217 pmic (which should be easy to emulate to sufficient degree to satisfy u-boot) Jan 13 17:47:55 and parts of the control module and PRCM... easiest is probably to see if you can make qemu print out the reads/writes performed to unknown locations (if it doesn't already do that by default) and fix those one at a time Jan 13 17:48:26 for more help you'll need to see someone who actually knows how qemu works, I don't Jan 13 17:49:10 Okay. Thank you so very much for your help. Jan 13 17:49:40 oh and emif (the ddr3 memory controller) is also different, but you can probably just instantiate it as a piece of RAM with some values preinitialized (I think u-boot checks the version register) Jan 13 17:50:35 u-boot will write values there to initialize the controller but you can of course happily ignore those Jan 13 17:51:00 Thanks. But if only my brain could handle all this now. Jan 13 17:51:39 sorry, if the cpu itself isn't yet supported by qemu (let alone the board), significant effort will be needed to get this working Jan 13 17:52:08 I'd start with googling to see if you can find previous efforts by people, see (or ask them) how far they've come Jan 13 17:53:09 I think I should also check some qemu dedicated channels. Jan 13 17:53:53 yes, if you have question about how the AM335x or early boot process works I can probably answer them, but I don't know much about qemu Jan 13 17:57:28 VersatilePB emulation, for instance, seems to work flawlessly in QEMU. At least I managed to get the u-boot command shell. I did it with little effort. That's because I've found a corresponding guide. Jan 13 17:58:42 $ qemu-system-arm -M versatilepb -m 128M -kernel u-boot.bin Jan 13 17:58:49 And that's all. Jan 13 17:59:02 yes, but that's because the board is already implemented Jan 13 17:59:49 Sure thing. Jan 13 18:00:07 Yes, sure thing. Jan 13 18:03:12 and hw/arm/omap3.c in the qemu-linaro repository is 165 KB of source code Jan 13 18:03:26 there's no omap4.c or am335.c in the same repository Jan 13 18:03:40 *am335x.c Jan 13 18:04:54 Yes. And there is the point. Jan 13 18:06:15 if you're lucky not quite as much code is needed, the am335x is less complex than an omap3/4, and parts will be reusable Jan 13 18:06:28 but it will not be easy anyhow Jan 13 18:07:40 you'll need to become quite familiar with both qemu and the am335x, and invest a lot of time, if you really want this to work Jan 13 18:08:13 That would be interesting but really challenging, that's because it's the last thing I would do. Jan 13 18:09:02 the alternative is to try to convince someone with the knowledge and skill to implement it Jan 13 18:09:14 (I probably do, but I have absolutely no time or motivation to do so) Jan 13 18:10:13 speaking of time, I've got to go Jan 13 18:14:08 Thank you. Jan 13 18:15:52 i have power 12V 3A and box 12v 5A, can i plug the power without any problem? Jan 13 18:25:16 *BANG!* Jan 13 18:50:26 zmatt: I'm getting closer with the simple framebuffer. It seems to get initialized right, only something in the kernel boot process is killing the LCDC. The kernel then initililizes fb1 sine fb0 is taken. Jan 13 18:50:54 why are you using simple-framebuffer if you're okay with tilcdc taking over? Jan 13 18:50:58 the two are incompatible Jan 13 18:51:31 and getting simple-framebuffer to work will be difficult due to kernel interference as I explained earlier Jan 13 18:53:28 Yeah, you are right, but I had to test it just because I wanted to. Jan 13 18:54:28 if you want to try simple-framebuffer then you'll need to suppress the tilcdc driver, and keep the kernel from disabling lcdc Jan 13 18:55:59 Yes. I'll poke around some more. I'll grep for the LCDC power register and see if I can find out what is causing it to be disabled. Jan 13 18:56:01 and reserve the framebuffer memory (u-boot hopefully has some way of adding a memreserve to DT, which I assume perform that task) Jan 13 18:56:16 there's a kernel config option about disabling "unused" clocks Jan 13 18:56:21 Yes, that has been done. Jan 13 18:56:28 that's been disabled? ok Jan 13 18:56:35 The memory reserve stuff Jan 13 18:56:39 ah Jan 13 18:57:46 I'll add an option to the u-boot env so simple framebuffer init can be enabled/disabled. Jan 13 18:59:07 well u-boot's job is the same regardless of whether you use simple framebuffer or tilcdc... or, well I guess for simple framebuffer you need to pass the address to the kernel Jan 13 19:00:06 CONFIG_OMAP_RESET_CLOCKS Jan 13 19:01:06 that's the option to disable to keep the kernel from disabling 'unused' clocks Jan 13 19:01:40 The simple-framebuffer node is disabled in the FDT by default, and gets enabled by u-boot. Jan 13 19:02:07 Ok, I'll see what that looks like now. Jan 13 19:02:14 does it not make more sense to detect the presence or absence of the node? Jan 13 19:03:15 especially since preserving the clock in a clean way will require adding a ti,hwmods = "lcdc"; property to the simple framebuffer node, but that might conflict with the tilcdc node even if only one of them is enabled (but I'm not sure) Jan 13 19:03:49 I'm also not sure whether that property would suffice, but it's worth a try Jan 13 19:04:34 but given that you mentioned having two framebuffers, that suggests tilcdc is still being loaded so you need to fix that first... you need to delete or disable its DT entry Jan 13 19:05:30 when combined with adding the ti,hwmods property to the simple-framebuffer node that might suffice to keep the kernel from disabling the clock Jan 13 19:30:05 Ok, I tried both, but same result. Jan 13 19:30:53 same result? I do hope you no longer have two fb devices? Jan 13 19:35:32 Well, I have not removed the simple-framebuffer node yet, but from what I can tell, the LCDC si still initialized OK with the two FBs. Jan 13 19:35:54 oh I thought you wanted to try simple-fb instead of tilcdc Jan 13 19:36:05 I'll have to run some more tests and get back to you. Jan 13 19:36:22 note that if tilcdc takes over the screen will be cleared Jan 13 19:37:08 but you could use e.g. an udev rule to display a new image as soon as the /dev/fb0 device node shows up Jan 13 19:38:07 but to be honest, I'm not sure how well lcdc will hold up if the tilcdc driver loads while lcdc has already been initialized Jan 13 19:38:31 I think it will be ruthlessly reset or something like that Jan 13 19:41:34 Jan 13 19:41:42 hi ds2 Jan 13 19:49:27 eliasbakken: btw, since I'm also having fights with lcdc I'm working on debug utils to inspect/validate its clocks and configuration, and probably to meddle with the config from userspace... I'll let you know when I have something Jan 13 19:51:15 Cool! I actually considered fixing whatever was broken with the framer/lcdc from my eMMC flasher script... an ugly hack using /dev/mem :o Jan 13 19:58:08 I'm actually considering a userspace lcdc driver, using uio :) and then just modifying e.g. the qt5 linuxfb backend to use that instead should be easy Jan 13 20:00:01 like simple-fb that would allow smooth transition from u-boot splash to application, but unlike simple-fb you retain the ability to use multiple buffers, vsync events, and hw panning (vertical only) Jan 13 20:02:05 the latest versions of the edma driver also allow making reservations using DT, which means accelerated blitting also becomes a piece of cake Jan 13 20:03:41 the only thing requiring some attention is mapping memory into userspace as "normal uncacheable" instead of device or strongly-ordered Jan 13 20:25:32 hm, I wonder if on an -rt kernel you can do kill -STOP on an irq handler Jan 13 20:54:35 anybody knows how to read data from azure in my beaglebone black? Jan 13 23:52:17 zmatt: OK I'm back. I had a problem with the LCDC loading fine during u-boot, but failed to come up during kernel init. Turned out it was the raster control register that was screwing things up. Wring PAL mode. Jan 13 23:55:06 A UIO driver would be nice! How far along are you? Jan 13 23:56:45 Hey, was wondering if anyone has tried loading a custom DTO and getting an I/O error? Jan 13 23:57:31 the command i'm running: sudo sh -c "echo libpruio >> /sys/devices/bone_capemgr.9/slots" Jan 13 23:59:23 From the command line, what does: echo libpruio > /sys/devices/bone_capemgr.9/slots give you? Jan 13 23:59:25 check dmesg Jan 14 00:00:20 let me try Jan 14 00:01:00 root@beaglebone:/home/libpruio/libpruio-0.2/src/examples# echo libpruio > /sys/devices/bone_capemgr.9/slots -bash: echo: write error: No such file or directory Jan 14 00:01:27 I had this issue before and tried to change the permissions of the entire directory to 777, still no luck Jan 14 00:04:42 find /sys -name slots Jan 14 00:12:29 -bash: /sys: Is a directory Jan 14 00:13:38 sorry for the delayed response Jan 14 00:18:15 the .9 is unpredictable, try .* instead Jan 14 00:18:33 even if Jan 14 00:18:34 root@beaglebone:/sys/devices# ls 44e10800.pinmux bone_capemgr.9 fixedregulator.10 ocp.3 pmu.0 software tracepoint ARMv7 Cortex-A8 breakpoint iio_sysfs_trigger platform soc.1 system virtual Jan 14 00:18:36 it's right there? Jan 14 00:20:57 ah I see it's a write error, then probably the kernel can't find the file you're trying to load, which would be /lib/firmware/libpruio-00A0.dtbo Jan 14 00:21:23 or it has some kind of trouble loading that file, e.g. it can't resolve some symbols Jan 14 00:25:57 eliasbakken: how far I am? I just had the idea :P though I also have a fair amount of experience already with uio and with lcdc, I reckon it wouldn't be very difficult Jan 14 00:26:56 Yeah, I've gotten that impression :) Jan 14 00:27:55 But the you will also run into the problem of the kernel disabling the LCDC. I'm poking around now t see where I could start.. Jan 14 00:31:00 no I won't, since 1. opening an uio device with appropriate ti,hwmods will actually make the kernel *enable* the necessary clocks for me 2. even if it didn't, the kernel only disables "unnecessary" clocks once during boot, after that you can sneak behind its back and turn things on Jan 14 00:33:02 btw, I don't know what kernel version you're using, but beware that many of them have buggy clock config code in tilcdc that has been patched by in 4.1-ti but those patches for some reason never made it upstream Jan 14 00:35:53 I'm not on the TI-branch, using the 4.1.15-bone17 Jan 14 00:36:51 probably RN's patched Jan 14 00:37:12 veremit: unfortunately not Jan 14 00:37:18 WHAT? Jan 14 00:37:30 * veremit stares in rcn-ee's general direction ... Jan 14 00:37:31 So I can put the ti,hwmod = "lcdc" into just about any DT node and it will enable it? I've tried reading up n the hwmod, but not quite there yet. Jan 14 00:38:19 eliasbakken: yeah, you stick it onto a node representing a device and Magic™ happens Jan 14 00:38:22 no idea how it works Jan 14 00:39:17 except that it links the device to the hardcoded platform knowledge (somewhere in arch/arm/mach-omap2/) Jan 14 00:40:07 Is there a way to enable debugging of it? Jan 14 00:41:06 no idea... there might be stuff in /sys/kernel/debug ? Jan 14 00:43:02 veremit: well, on the bright side the buggy code still works for *at least* 50% of all possible pixel clock rates Jan 14 00:46:56 zmatt: Thanks for your feedback, I'll have to continue with this tomorrow. Jan 14 00:48:47 zmatt: wow 50% .. that's awesome! Jan 14 00:48:53 esp. for am335x :( Jan 14 00:49:21 veremit: I think including many common rates Jan 14 00:51:25 the LCD frame buffer device a bit of a pain? I assume it's the same as what the original beagle board had on it. Jan 14 00:57:44 GenTooMan: no Jan 14 01:01:10 GenTooMan: lcdc is much much simpler than omap-dss Jan 14 01:01:40 it's a slightly enhanced version of the lcdc on Freon/Primus (omap-L13x et al) Jan 14 01:05:12 zmatt well I can be wrong. The Am335x series isn't designed for being a smart phone or set top box. I suppose that would be the reason from the simpler frame buffer controller. I suppose I will have too look at it. Not like I can do anything useful with it any time soon. :D Jan 14 01:15:41 GenTooMan: it's basically just a very simple dma controller connected via an async fifo to a simple raster controller Jan 14 01:15:53 no compositing or colorspace conversion or any fancy stuff like that Jan 14 01:16:15 nicely put zmatt Jan 14 01:17:11 oh and a simple bus interface controller for things like character displays, as alternative to the raster controller (they're basically two different peripherals under one roof) Jan 14 01:17:30 it can optionally use the dma controller too Jan 14 01:19:12 it's a shame you can't configure 0 blanking, otherwise it would have made a nice 24-channel parallel digital output player Jan 14 01:27:01 heh Jan 14 01:41:23 I was looking at using it for DDS for RF myself. Jan 14 02:33:51 eliasbakken: ok, basic dumper of lcdc config is done... http://gerbil.xs4all.nl/lcd-util.tgz Jan 14 02:41:06 hm, can someone try it while X11 is running? I wonder if it double-buffers, since linuxfb evidently does not (dma fb 0 and 1 are fixed) Jan 14 02:45:19 how can we know when we might get a bus error trying to mmap dev/mem? Jan 14 02:46:24 you're getting a bus error?/ Jan 14 02:47:20 yes sir, on the BBB, trying to access the ADC_TSC region Jan 14 02:47:47 oh, not related to what I just pasted, sorry, I assumed Jan 14 02:47:55 hahahah Jan 14 02:48:01 ohh Jan 14 02:48:04 sorry about that Jan 14 02:48:05 you can get a bus error in a variety of ways Jan 14 02:48:44 invalid address, misaligned access, peripheral not enabled in PRCM (that's a common one) Jan 14 02:49:08 i did read about them but i'm glad you pointed me towards that last one Jan 14 02:49:36 the nicer way to use a peripheral is using uio Jan 14 02:49:50 http://pastebin.com/GrHwgYiR Jan 14 02:51:30 then the kernel will enable the module for you Jan 14 02:51:35 when you open /dev/uio/adc Jan 14 02:51:46 (which you can mmap() similar to /dev/mem, but use file offset 0) Jan 14 02:52:02 oh i have to read about that Jan 14 02:52:40 has the added benefit that root privileges aren't required (you can set the permissions of the uio device node however you like, as my example udev rule shows) Jan 14 02:53:08 and you can receive interrupts if you want Jan 14 02:53:34 so thats userspace i/o? Jan 14 02:54:13 yep Jan 14 02:54:35 thanks i'm gonna read the kernel docs Jan 14 02:54:39 the uio_pdrv_genirq driver is included in all recent rcn-ee kernels Jan 14 02:54:43 no need really Jan 14 02:55:43 most of that doc assumes x86 platforms with shared irq lines, which still forces you to implement a tiny kernel driver Jan 14 02:55:56 that's irrelevant on the am335x Jan 14 02:56:34 just follow my pastebin instructions, and open /dev/uio/adc and mmap() it Jan 14 02:56:36 okay so i should just take it that /dev/uio/adc is pretty much /dev/mem but offset to start at the relevant region Jan 14 02:56:43 yep Jan 14 02:56:51 i do really really like that Jan 14 02:57:57 if you want interrupts, the instructions are also really simple: make sure the DT node has one (that's taken care of in this case by reusing the existing tscadc node), write (u32)1 to the file descriptor to enable the irq Jan 14 02:59:14 then read an u32 from the fd to wait for the irq (you can discard the value), or you can use select()/poll()/epoll or whatever to check for readability Jan 14 02:59:31 you need to write (u32)1 again to rearm it Jan 14 02:59:40 (after you cleared the interrupt condition) **** ENDING LOGGING AT Thu Jan 14 02:59:58 2016