On Mon, 08 Apr 2024, Dmitry Baryshkov wrote:
> On Mon, 8 Apr 2024 at 11:09, Jani Nikula wrote:
>> Thanks! Do you take this via the msm tree?
>
> Yes, I will
Forgot to mention, there's a Tested-by at [1].
Tested-by: Aishwarya TCV
[1]
On Mon, 8 Apr 2024 at 11:09, Jani Nikula wrote:
>
> On Fri, 05 Apr 2024, Dmitry Baryshkov wrote:
> > On Fri, Apr 05, 2024 at 12:29:07PM +0300, Jani Nikula wrote:
> >> Logging u32 pixel formats using %4.4s format string with a pointer to
> >> the u32 is somewhat questionable, as well as dependent
On Fri, 05 Apr 2024, Dmitry Baryshkov wrote:
> On Fri, Apr 05, 2024 at 12:29:07PM +0300, Jani Nikula wrote:
>> Logging u32 pixel formats using %4.4s format string with a pointer to
>> the u32 is somewhat questionable, as well as dependent on byte
>> order. There's a kernel extension format
On Fri, Apr 05, 2024 at 12:29:07PM +0300, Jani Nikula wrote:
> Logging u32 pixel formats using %4.4s format string with a pointer to
> the u32 is somewhat questionable, as well as dependent on byte
> order. There's a kernel extension format specifier %p4cc to format 4cc
> codes. Use it across the
Logging u32 pixel formats using %4.4s format string with a pointer to
the u32 is somewhat questionable, as well as dependent on byte
order. There's a kernel extension format specifier %p4cc to format 4cc
codes. Use it across the board in msm for pixel format logging.
This should also fix the
