Request for Intel 915 hw information
jbarnes at virtuousgeek.org
Thu Sep 20 07:49:42 PDT 2007
On Tuesday, September 18, 2007 6:28:08 pm Krzysztof Halasa wrote:
> Simple questions for you Intel experts. I'm using interlaced mode
> on PIPE A:
> How do I read currently displayed scan line number, and/or field
> number? Is it the following?
> #define PIPEAFRAMEHIGH 0x70040
> #define PIPE_FRAME_HIGH_MASK 0x0000ffff
> #define PIPE_FRAME_HIGH_SHIFT 0
> #define PIPEAFRAMEPIXEL 0x70044
> #define PIPE_FRAME_LOW_MASK 0xff000000
> #define PIPE_FRAME_LOW_SHIFT 24
> (and 0x71040 + 0x71044 for PIPEB)?
Yeah, plus PIPE*_DSL
> On my 915 PIPEACONF, PIPEA_DSL and the above registers produce:
> PIPEACONF PIPEA_DSL FRAME_HIGH FRAMEPIXEL
> 0x80C00000 288 0 0x1207A04E
> 0x80C00000 288 0 0x1307A03E
> 0x80C00000 288 0 0x1407A026
> 0x80C00000 288 0 0x1507A06E
> 0x80C00000 288 0 0x1607A06A
> 0x80C00000 288 0 0x1707A0CA
> 0x80C00000 288 0 0x1807A126
> 0x80C00000 288 0 0x1907A0EB
> 0x80C00000 288 0 0x1A07A0C2
> 0x80C00000 288 0 0x1B07A149
> 0x80C00000 288 0 0x1C07A076
> 0x80C00000 288 0 0x1D07A19C
> 0x80C00000 288 0 0x1E07A031
> Why is FRAME_HIGH always 0 for PIPE A (the active one)? Not implemented
> on 915?
No, this should work on i915. FRAMEPIXEL's upper bits seem to be increasing
slowly too (assuming you're printf'ing them while your app is running and not
stuffing them into a buffer to dump out later). Are you sure you should be
looking at pipe A? On a laptop, only pipe B will be active unless you have
an external display plugged in.
> Should I expect the 8 MSBs of FRAME_PIXEL to always be the frame (field)
> count? On all chips?
> Can I assume that even/odd frame# in FRAME_PIXEL = even/odd field in
> output, or something like that?
In the case of an interlaced mode, I think the frame count registers will
count whole fields, not individual interlaced frames.
> What is PIPEA_DSL? Is it implemented on 915 and/or other chips?
Yeah, i915 has it. It gives you the actual scanline number currently being
scanned out. Again for interlaced modes it'll give you a field relative
number, so you'd expect all even numbers for one frame, then all odd numbers
> Is it possible to generate IRQ only on the second (final) vertical
Yeah, that's how things *should* work afaik. Are you seeing something
> Obviously I'm trying to reliably sync interlaced video to the full
> interlaced frame (in IRQ handler), is
> field_parity = (INREG(PIPEAFRAMEPIXEL) >> 24) & 1
> a reliable way to do it?
See above, I think you'll get field counts here, though I'll have to check
some more recent docs to be sure.
> How about that Xvideo overlay, is it possible to have no vertical
> scaling etc. in interlaced mode? Current X.org code causes the chip
> to deinterlace somehow, even if I have 576 visible lines and 576-line
> video stream.
Not sure about the video overlay, I'll have to look that up.
More information about the xorg