Re: [PATCH 3/7] drm/i915/skl: Adjust intel_fb_align_height() for Yb/Yf tiling

[Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com>]

On 02/24/2015 04:54 PM, Damien Lespiau wrote:
> On Mon, Feb 23, 2015 at 03:55:57PM +0000, Tvrtko Ursulin wrote:
>> From: Damien Lespiau <damien.lespiau@intel.com>
>>
>> We now need the bpp of the fb as Yf tiling has different tile widths
>> depending on it.
>>
>> v2: Rebased for the new addfb2 interface. (Tvrtko Ursulin)
>> v3: Rebased for fb modifier changes. (Tvrtko Ursulin)
>>
>> Signed-off-by: Damien Lespiau <damien.lespiau@intel.com>
>> Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
>> Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
>
> Might want to add a MISSING_CASE() here as well. For the record, the

Will do.

> vertical alignments for Yf are taken from a dodgy looking document found
> by chance.
>
> We don't have a 128bpp format supported by display

Ok but we can't really error out from this helper so what do you suggest?

> Now that I think about it, for the horizontal stride, BSpec says:
>
>    - 8 bpp -> 64 bytes
>    - * bpp -> 128 bytes
>
> Given that a tile is a page size this would give for the vertical
> alignment:
>
>    - 8 bpp -> 64 byes (that's what we have)
>    - * -> 32 bytes
>
> So the 64bpp cases look a bit suspicious. Given that one the goals for
> this new tiling format is to have tiles as square as possible (in terms
> of pixels, not byte size), it'd make sense to have different strides
> constraints for the 64bpp format, so it could be BSpec being wrong on
> the horizontal stride constraint for 64bpp?

It's either square or 2:1 rectangular. I'll try to double check the 
numbers for 64bpp then.

Regards,

Tvrtko
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx