Hi Thomas,
On Thu, Sep 22, 2022 at 1:33 PM Thomas Zimmermann <tzimmermann@xxxxxxx> wrote:
> Support the CRTC's color-management property and implement each model's
> palette support.
>
> The OF hardware has different methods of setting the palette. The
> respective code has been taken from fbdev's offb and refactored into
> per-model device functions. The device functions integrate this
> functionality into the overall modesetting.
>
> As palette handling is a CRTC property that depends on the primary
> plane's color format, the plane's atomic_check helper now updates the
> format field in ofdrm's custom CRTC state. The CRTC's atomic_flush
> helper updates the palette for the format as needed.
>
> v3:
> * lookup CRTC state with drm_atomic_get_new_crtc_state()
> * access HW palette with writeb(), writel(), and readl() (Ben)
> * declare register values as u32
>
> Signed-off-by: Thomas Zimmermann <tzimmermann@xxxxxxx>
> Reviewed-by: Javier Martinez Canillas <javierm@xxxxxxxxxx>
Thanks for your patch!
> --- a/drivers/gpu/drm/tiny/ofdrm.c
> +++ b/drivers/gpu/drm/tiny/ofdrm.c
> +static void __iomem *ofdrm_qemu_cmap_ioremap(struct ofdrm_device *odev,
> + struct device_node *of_node,
> + u64 fb_base)
> +{
> +#ifdef __BIG_ENDIAN
> + static const __be32 io_of_addr[3] = { 0x01000000, 0x0, 0x0 };
> +#else
> + static const __be32 io_of_addr[3] = { 0x00000001, 0x0, 0x0 };
> +#endif
You can easily get rid of the #ifdef:
static const __be32 io_of_addr[3] = { cpu_to_be32(0x01000000), 0x0, 0x0 };
And probably sparse ("make C=2") will complain about the plain zeros,
so "cpu_to_be32(0x0)" as well.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@xxxxxxxxxxxxxx
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
