| 23:59 | _rmk_ | TERM=linux setterm -blank 0 >/dev/tty1 |
| 23:59 | _rmk_ | if you don't have setterm... |
| 23:59 | _rmk_ | echo -e '\033[9;0]' >/dev/tty1 |
| 00:00 | shesselba | setterm worked |
| 00:00 | shesselba | 0: 0x01b8: 0x6000000d |
| 00:00 | _rmk_ | good :) |
| 00:00 | shesselba | ok, ready for the sum up? |
| 00:00 | _rmk_ | yep |
| 00:02 | shesselba | The original mode is 1680x1050p60, pixclk 101MHz, PHSYNC (+h), NVSYNC (-v) .. or is it +he, -ve ? |
| 00:02 | shesselba | I stick with +h/-h and +v/-v |
| 00:02 | shesselba | TDA sets REG_VIP_CNTRL_3, VIP_CNTRL_3_V_TGL |
| 00:02 | shesselba | and REG_TBG_CNTRL_1, TBG_CNTRL_1_VH_TGL_0 |
| 00:03 | shesselba | dove_drm adjusts mode to -h, -v |
| 00:03 | shesselba | actual mode on monitor is 1680x1050p49, pixclk 83MHz (=AXICLK/4) |
| 00:04 | shesselba | DE is high during active and low during blanking |
| 00:04 | shesselba | VS is high during active and low during blanking (Neg pulse ~74.9us, 49.46Hz) |
| 00:05 | shesselba | HS is high during active and low during blanking (Neg pulse ~384ns, 53.42kHz) |
| 00:05 | shesselba | that's it |
| 00:05 | _rmk_ | ok, this is 1680x1050 rather than the 1400x1050 you mentioned above? |
| 00:06 | shesselba | let me double check |
| 00:06 | shesselba | Monitor says 1680x1050 49Hz |
| 00:06 | _rmk_ | the only things which really matters is the register value vs what you're seeing on the 'scope. |
| 00:07 | shesselba | decoded edid is |
| 00:07 | shesselba | (or what dove_drm gets) |
| 00:07 | shesselba | H: 1400 1448 1480 1560 lm 80 rm 48 |
| 00:07 | shesselba | V: 1050 1053 1057 1080 tm 23 bm 3 |
| 00:08 | shesselba | so it is 1400x1050 |
| 00:09 | _rmk_ | okay, so what I can say is that with no inversion, the sync pulses produced by dove are +ve going. |
| 00:10 | _rmk_ | in other words, active high. that fills in a piece of the jigsaw which isn't in the docs. |
| 00:11 | _rmk_ | so... in the functional spec, figures 38 and 39 - those are with the inversion bits set! |
| 00:11 | shesselba | with hsync_inv set, HS is low active, i.e. low-active sync pulse |
| 00:11 | shesselba | vsync_inv also |
| 00:11 | _rmk_ | whereas figure 32 is with the inversion bits clear. |
| 00:11 | _rmk_ | documentation, don't you just love it :) |
| 00:12 | shesselba | wrt to fig 32 yes |
| 00:12 | shesselba | or .. assume.. I only _verified_ that with inv bit set it is low-active ;) |
| 00:12 | _rmk_ | I shall add comments to my dove_hw.h about the normal state of those signals. |
| 00:12 | shesselba | you want me to verify? |
| 00:12 | _rmk_ | if you want to check... |
| 00:13 | _rmk_ | echo 0x1b8 0x60000009 > /sys/kernel/debug/dri/0/reg_wr |
| 00:13 | _rmk_ | err |
| 00:13 | _rmk_ | echo 0x1b8 0x60000001 > /sys/kernel/debug/dri/0/reg_wr |
| 00:13 | _rmk_ | then you should have both sync's +ve going |
| 00:13 | shesselba | hehe |
| 00:14 | shesselba | monitor likes the frame now |
| 00:14 | _rmk_ | okay, good. I shall document this up now, and fix any comments in the driver which need fixing. |
| 00:15 | _rmk_ | many thanks for taking the time to get that info for me, much appreciated. |
| 00:15 | shesselba | np |
| 00:16 | shesselba | verified that with inversion bits not set, it's high-active during sync pulses |
| 00:16 | shesselba | I have to minor fixes |
| 00:17 | shesselba | s/to/two |
| 00:18 | _rmk | 00:18 * _rmk_ really wishes his TV wouldn't overscan all the time. |
| 00:18 | shesselba | please let dove_drm_tda19988_create and dove_output_create return error codes instead of struct drm_connector* |
| 00:19 | shesselba | if i2c adapter gets registered after dove-drm it doesn't DEFER |
| 00:19 | _rmk_ | yep, that'll allow me to return -EPROBEDEFER if the TDA slave isn't there :) |
| 00:19 | shesselba | exactly |
| 00:19 | shesselba | I ran into it |
| 00:20 | _rmk_ | let me just sort out my tree from todays efforts with cursors :) |
| 00:27 | shesselba | ok, next week I ll retest all polarities at an DVI decoder output |
| 00:27 | shesselba | should give some insight into TDA behaviour |
| 00:27 | _rmk_ | and I'll probably have new patches by then :) |
| 00:29 | shesselba | great |
| 00:30 | shesselba | btw. you don't need a TV without overscan |
| 00:31 | shesselba | with hsync and vsync polarity set to what the monitor wants, I can see no single line of blanking |
| 00:32 | shesselba | in active video |
| 00:37 | _rmk | 00:37 * _rmk_ fixes the missing file too :) |
| 00:39 | shesselb | 00:39 * shesselba will check out lcdc fractional divider |
| 00:42 | shesselba | _rmk_: maybe you should also always set 0x1a8 bit 29 |
| 00:43 | shesselba | SCLK_DIV, change clock on new frame start |
| 00:46 | _rmk | 00:46 * _rmk_ ponders that... I'm updating everything else on mode set immediately, but with the output disabled |
| 00:47 | shesselba | ok, then it doesn't really matter |
| 00:49 | shesselba | *OMG* |
| 00:49 | _rmk_ | one last piece to the cursor thing - I need to ask David Airlie if there's any defined format for cursors being passed to drm or whether it can be hw specific. I suspect it can be hw specific. |
| 00:49 | shesselba | yeah |
| 00:50 | shesselba | and about fractional divider: it is useless |
| 00:50 | _rmk_ | let me guess, it causes clock instability? |
| 00:50 | _rmk_ | either that or it has no effect at all |
| 00:51 | shesselba | well, the clock is still "stable" but it skips 1 out of n clocks completely |
| 00:51 | shesselba | so it is not continuously running anymore |
| 00:52 | _rmk_ | oh my. |
| 00:52 | _rmk_ | that's not going to work very well for anything but a synchronously clocked panel |
| 00:52 | shesselba | yep |
| 00:53 | shesselba | even if i skip 1 out of some thousand, the monitor immediately stops recognizing a valid mode |
| 00:53 | _rmk_ | and even then it could be violating minimum clock timings |
| 00:54 | shesselba | could have been useful if it would skip _reference_ clock cycles.. but pixclk cycles? please |
| 00:57 | _rmk_ | bah. cursor data is ARGB |
| 00:57 | shesselba | so with no extclk connected, every non-VESA mode will not work.. monitors tend to be picky with TV pixclk but accept almost any pixclk for computer mode |
| 00:57 | shesselba | 32b cursor? |
| 00:57 | _rmk_ | yep. Xorg internally deals with 2 colour+transparent cursors or ARGB cursors |
| 00:58 | _rmk_ | and yes, it alphablends the cursor |
| 00:58 | _rmk_ | which we won't be able to do properly with the limitations of the 510's lcd controllers |
| 01:01 | shesselba | from what I see on a quick glimpse with dove lcdc there is FG/BG+A color? |
| 01:02 | _rmk_ | yep. if you look at the X cursor files through, they're all ARGB |
| 01:03 | shesselba | hmm section 11.3 has HWC32 |
| 01:03 | _rmk_ | [msg(airlied)] ok. follow-on question: is the cursor size defined? I notice the i915 driver always uses 64x64, but would 64x32 or 32x64 also be acceptable? |
| 01:03 | _rmk_ | [airlied([email protected])] X and userside programs expect 64x64 to work |
| 01:03 | shesselba | dooh |
| 01:03 | _rmk_ | [airlied([email protected])] so its possibly pointless supporting anything less, as in you'd wriet code but nobody would end up using it |
| 01:03 | _rmk_ | [msg(airlied)] okay, so what would you do if you had the option in hardware of: (a) 64x64 RGB with transparency, or (b) 32x64 or 64x32 ARGB. |
| 01:04 | _rmk_ | I think I know his answer... probably "don't bother" |
| 01:05 | shesselba | (c) 32x32 ARGB? |
| 01:08 | shesselba | now I got the conversation, i.e. who is you and who is David |
| 01:11 | _rmk_ | David goes on to say: |
| 01:11 | _rmk_ | you'd probably need to expose some cap from the kernel so the generic driver knows a 64x32 ARGB is all you have, and see if making -modesetting using 64, 32 works |
| 01:11 | _rmk_ | I suppose most cursors might fit in 64x32 |
| 01:11 | _rmk_ | me: Xcursor files seem to have 24x24, 32x32 and 48x48 |
| 01:12 | _rmk_ | David: yeah quite what the client side uses though I'm not sure |
| 01:12 | _rmk_ | the other option is to expose non-ARGB cursors, we just haven't felt it worth the trouble yet, since most sane hw can support 64x64 |
| 01:12 | _rmk_ | probably what Windows demanded |
| 01:13 | shesselba | hmm.. maybe exposing pixfmt and max pixels would be sufficient? |
| 01:15 | _rmk_ | okay, just been through all the other drm drivers. some error out if the cursor is not 64x64, others error out if its larger than 64x64 but permit smaller |
| 01:16 | shesselba | btw.. did you ever notice the name of the lcdclk pll as it is referenced in marvell lsp? "accurate_LCDCLK" *g* |
| 01:20 | shesselba | core pll provides 2GHz, "accurate" lcd pll allows integer dividers 5 >= N >= 32, and there is a "Half integer" divider, i.e. N+0.5 |
| 01:21 | shesselba | you'd be lucky if you get even close to any pixclk for HD video ;) |
| 01:22 | shesselba | maybe skip some pixclks with fractional divider ;) |
| 01:23 | shesselba | I am getting tired, thanks for the drm driver RFC for now! |
| 01:23 | _rmk_ | yea. me too. I'll see about kicking out the xorg bits sometime next week if I get time |
| 01:24 | shesselba | have a nice long weekend! n8 |
| 01:24 | _rmk_ | heh. :) |
| 01:25 | _rmk_ | just kicked the cubox off playing a film, but I'm not watching it all tonight :) |
| 01:25 | _rmk_ | more a case of making sure that didn't break. |
| 01:25 | _rmk_ | anyway, thanks, sleep well |
| 11:05 | _rmk_ | shesselba: I went back to the NXP TDA19988 driver, and tried fiddling around with the sync output polarity from the 510... and yes, following what's requested does seem to behave correctly, so I'm not sure where I got the idea that I needed to fix the sync polarity... |
| 11:06 | _rmk_ | also... its interesting that the dovefb driver fixes the hsync polarity to be what it's supposed to be as defined by CEA for 1080 and 720 resolutions (which is +ve) |
| 11:07 | _rmk_ | for that, I suspect if someone has a display device which incorrectly advertises -ve syncs for those modes, they need a patched EDID, which the kernel supports as a way of fixing stuff like this, and not a driver hack. |
| 11:07 | shesselba | _rmk_: I know looking for bugs at places where the aren't also. Seriously, I suggest to make tda998x behave transparent wrt to sync |
| 11:07 | shesselba | that is what I would expect from a hdmi transmitter |
| 11:08 | shesselba | yeah, the dovefb stuff is full of those dirty hacks |
| 11:08 | _rmk_ | well, I checked that audio works too, so I'm happy just to remove that fixup code |
| 11:08 | shesselba | FWIW, ACK! ;) |
| 11:09 | shesselba | I can look through my previous dove-drm/tda998x work and strip out tda irq |
| 11:09 | shesselba | and send it to you |
| 11:10 | _rmk_ | ok, I can then stick it into this branch - we'll need that for when we want to extend this stuff for CEC |
| 11:11 | shesselba | although, it is using DT for gpio passing.. so I will have to add gpio to tda private data first |
| 11:11 | _rmk_ | right, breakfast time :) |
| 11:12 | shesselba | :) |
| 11:17 | shesselba | for sync mangling of tda998x, I can think of flags that make it either transparent (default), always_invert, always_high, or always_low. That way, you can catch some even dumber lcd controllers that can't invert sync |
| 13:52 | shesselba | _rmk_: when dealing with gpio irqs, should I request the gpio first, get the corresponding irq, and request the irq myself.. or should I rather pass the already converted irq in the first place? |
| 14:04 | _rmk_ | always pass the gpio - a gpio can always be converted to an irq, but an irq may not be convertable to a gpio |
| 14:04 | shesselba | ok, thanks! |
| 15:28 | dv_ | listening to you guys hack away makes me sad, since i am currently busy with completely different stuff, and I'd like to participate :| |
| 18:56 | _rmk | 18:56 * _rmk_ just tripped over a bug in DRM's memory management :( |
| 18:58 | shesselba | well, I tripped over drm not liking OF i2c nodes.. |
| 19:00 | shesselba | albeit easier to solve |