Re: [PATCH] gpu: ipu-v3: Allow negative offsets for interlaced scanning

[Steve Longerbeam <slongerbeam@gmail.com>]

On 06/20/2018 01:54 AM, Philipp Zabel wrote:
> Hi Steve,
>
> On Tue, 2018-06-19 at 18:30 -0700, Steve Longerbeam wrote:
>> I've found some time to diagnose the behavior of interweave with B/T line
>> swapping (to support interlaced-bt) with planar formats.
>>
>> There are a couple problems (one known and one unknown):
>>
>> 1. This requires 32 pixel alignment to meet the IDMAC 8-byte alignment
>>       of the planar U/V buffer offsets, and 32 pixel alignment precludes
>>       capturing raw NTSC/PAL at 720 pixel line stride.
> What needs to be aligned to multiples of 32 pixels?
>
> I thought 8 pixel width alignment should be good enough for NV12/NV16,
> for which luma and chroma strides are equal to the width in pixels, and
> 16 pixel alignment for YUV420/YVU420/YUV422P, where chroma stride is
> half the width in pixels.

I see where the problem is now. I was basing my mistaken 32 pixel
alignment from a read of the U_OFFSET/V_OFFSET macros in
ipu-cpmem.c:

u_offset = pix->width * pix->height + pix->width * y / 4 + x / 2

But you can probably see the bug now. This does not produce
a correct offset for odd values of y. It should read:

u_offset = pix->width * pix->height + pix->width * (y / 2) / 2 + x / 2

With that fix, interweave line swap with planar 4:2:0 is working now.
That includes YUV420, YVU420, and NV12.

NV16 is also working after programming SLUV with double
the chroma line stride.

>> 2. Even with 32 pixel aligned frames, for example by using the prpenc scaler
>>       to generate 704 pixel strides from 720, the colors are still wrong when
>>       capturing interlaced-bt.
> As a side note, we can't properly scale seq-tb/bt direct input from the
> CSI vertically with the IC, as the bottom line of the first field will
> be blended with the top line of the second field...
>
>>   I thought for sure this must be because we
>> also
>>       need to double the SLUV line strides in addition to doubling SLY
>> line stride.
>>       But I tried this and the results are that it works only for YUV
>> 4:2:2. For 4:2:0
>>       it causes system hard lockups. (Aside note: interweave without line
>> swap
>>       apparently has never worked for 4:2:2, even when doubling SLUV, so it's
>>       quite bizarre to me why 4:2:2 interweave _with_ line swap _does_ work
>>       after doubling SLUV).
> When you say 4:2:2 you only mean YUV422P, not NV16 or YUYV/UYVY ?

Correct, I meant planar YUV422P.


>
>> For these reasons I think we should disallow interlaced-bt with planar
>> formats.
> Does that include NV12/NV16? Capturing to NV12 could be desirable if at
> all possible, because the result can be encoded by the CODA. The other
> formats are bandwidth inefficient anyway.

Never mind, I found the bug described above in the U_OFFSET/V_OFFSET
macros.

In summary, at this point all planar formats are working with interlaced
bt and tb, except for YUV422P.

Steve