| 00:59 | _rmk_ | okay, my conclusion is that you have LCD_D7:0 -> VPC7:0, LCD_D15:8 -> VPB7:0, LCD_D23:16 -> VPA7:0 |
| 01:02 | _rmk_ | So, we have under the NXP driver for the TDA19988: |
| 01:02 | _rmk_ | FB LCD out Pins VIP Int Vp |
| 01:02 | _rmk_ | R:23:16 R:7:0 VPC7:0 7:0 7:0[R] |
| 01:02 | _rmk_ | G:15:8 G:15:8 VPB7:0 23:16 23:16[G] |
| 01:02 | _rmk_ | B:7:0 B:23:16 VPA7:0 15:8 15:8[B] |
| 01:03 | _rmk_ | where we have the swap_rb between the framebuffer and LCD_D out pins |
| 01:03 | _rmk_ | then we have the horrid VIP input muxing between the TDA19988 pins (Pins) and its VIP block |
| 01:04 | _rmk_ | and finally another round of muxing between the VIP and the internal bus |
| 01:05 | _rmk_ | that final mux is not transparent in the nxp driver, due to this: |
| 01:05 | _rmk_ | const UInt8 VideoPortNoMux[MAX_UNITS] = { VIP_MUX_G_B | VIP_MUX_B_R | VIP_MUX_R_G |
| 01:05 | _rmk_ | }; |
| 01:05 | _rmk_ | in comps/tmdlHdmiTx/cfg/TDA9989/tmdlHdmiTx_cfg.c |
| 01:05 | _rmk_ | the internal bus is GBR format |
| 01:06 | _rmk_ | setting that mux to be transparent (so internal bus 23:0 = VIP 23:0) means that the VIP then expects GBR format as well... |
| 01:07 | _rmk_ | which can only be satisfied by an a-f swap of 2,3,4,5,0,1, which is what I need for the DRM TDA19988 driver from powerup |
| 01:07 | _rmk_ | and now, my head is close to exploding due to all these muxes :P |
| 04:50 | Netham45 | Anyone know if the USB Serial controller on the Cu |
| 04:50 | Netham45 | bah |
| 04:50 | Netham45 | on the CuBox's drivers are open source for Windows? |
| 06:12 | frilled | heh, windows and open source drivers ;-) |
| 06:12 | frilled | The drivers are closed source for all I know, look here: http://www.ftdichip.com/Support/Knowledgebase/index.html?doftdidistributedriversourc.htm |
| 06:13 | frilled | Never heard prolific was any different |
| 08:24 | Netham45 | Hrm, disappointing. |
| 08:24 | Netham45 | I was hoping to port them over to Windows RT. |
| 10:51 | _rmk | 10:51 * _rmk_ prods rabeeh re dove to tda19988 wiring for lcd_d23:0 |
| 13:49 | frilled | rabeeh, was there any hint on the missing pixels on hdmi? particulat kernel patch? |
| 13:58 | Marmotte | frilled: the problem doesn't appear on geexbox, we can try to pick some geexbox elements to test :) |
| 13:59 | dbsx | Where are the pixels missing, I am either unobservant or do not have the problem. |
| 14:43 | Marmotte | dbsx: on top of my screen, there are about 6~7 pixels missing |
| 14:49 | frilled | ok |
| 15:55 | _rmk | 15:55 * _rmk_ wonders if that means rabeeh is now here |
| 16:09 | dbsx | rabeeh: any plans for adding the spi flash patch to your kernel? |
| 16:10 | dbsx | m25p80 spi0.0: unrecognized JEDEC id 20ba16 |
| 16:10 | dbsx | It has been working in thirstys kernel for a long time |
| 16:10 | _rmk_ | it works in 3.8 too |
| 16:11 | dbsx | gnite |
| 19:32 | _rmk_ | now have 3.9 running on my cubox |
| 19:36 | jnettlet | _rmk_, is that setting up the hardware with device-tree? |
| 19:37 | _rmk_ | no, this is rabeeh's v3.5.something kernel with v3.9 merged into it plus all my stuff |
| 19:38 | jnettlet | k |
| 19:38 | _rmk_ | well, to be pedantic, rabeeh v3.5.something + v3.8 + mystuff + v3.9 on top. its going to be some effort to move v3.9 down that chain (I just did it with v3.8) |
| 19:39 | _rmk_ | also trying to move more of my patches so they're on the mainline side rather than the merged-with-rabeeh side of the tree |
| 19:59 | _rmk_ | jnetttlet: I need to pull it all forward to v3.9 anyway because otherwise generating patches for mainline becomes even more difficult - especially when I've currently got random other patches from mainline cherry picked into my working tree |
| 21:25 | _rmk_ | well, I'm posting my DRM driver |
| 23:29 | dv_ | _rmk_: \o/ |
| 23:29 | _rmk_ | and also posted my i2c driver fixes too now |
| 23:30 | dv_ | where? |
| 23:30 | _rmk_ | to the appropriate mailing lists, but all copied to linux-arm-kernel |
| 23:30 | dv_ | okay |
| 23:31 | _rmk_ | see the bottom of: http://lists.infradead.org/pipermail/linux-arm-kernel/2013-May/thread.html |
| 23:32 | _rmk_ | one set of 8 and one set of 9 |
| 23:33 | _rmk_ | but that's only a fraction of what I'm actually running, gitk tells me 232 commits in total (including merges) |
| 23:33 | _rmk_ | oh, and I've also sent a fix for the network driver shutdown problem (if you have lockdep enabled) |
| 23:34 | _rmk_ | I wouldn't say my drm stuff is "well polished" because its mostly done for the cubox only |
| 23:35 | _rmk_ | and as I don't run it with DT (yet) I've not even considered that side of it |
| 23:47 | dv_ | wow. nice work. |
| 23:52 | _rmk_ | I'll look at what I can push out from the ASoC branch next, most of that isn't against mainline at the moment so will need some work |
| 23:53 | _rmk_ | most of that is trivial stuff tho |
| 23:56 | _rmk_ | much of what Rabeeh has fixed in his kernel (like the vmeta uio driver "optimization") I've had for ages already but in a different form. |
| 23:56 | _rmk_ | that optimization isn't really a fix, it's a hack, because the real problem is the userspace side isn't respecting the UIO API correctly. |
| 23:57 | _rmk_ | you poll. when there's an event ready, you're supposed to read from the fd to clear the poll status. the library doesn't do that. |