Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
MIME-Version: 1.0
References: <20230713085859.907127-1-javierm@redhat.com>
In-Reply-To: <20230713085859.907127-1-javierm@redhat.com>
From:   Geert Uytterhoeven <geert@linux-m68k.org>
Date:   Thu, 13 Jul 2023 11:56:28 +0200
Message-ID: <CAMuHMdXWfeX9EESbiSnJ-G-TuyFKt7ZnMKi2Y85HRG2695siTg@mail.gmail.com>
Subject: Re: [PATCH] drm/ssd130x: Change pixel format used to compute the
 buffer size
To:     Javier Martinez Canillas <javierm@redhat.com>
Cc:     linux-kernel@vger.kernel.org, Daniel Vetter <daniel@ffwll.ch>,
        David Airlie <airlied@gmail.com>,
        dri-devel@lists.freedesktop.org
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8BIT
Precedence: bulk

On Thu, Jul 13, 2023 at 10:59 AM Javier Martinez Canillas
<javierm@redhat.com> wrote:
> The commit e254b584dbc0 ("drm/ssd130x: Remove hardcoded bits-per-pixel in
> ssd130x_buf_alloc()") used a pixel format info instead of a hardcoded bpp
> to calculate the size of the buffer allocated to store the native pixels.
>
> But that wrongly used the DRM_FORMAT_C1 fourcc pixel format, which is for
> color-indexed frame buffer formats. While the ssd103x controllers don't
> support different single-channel colors nor a Color Lookup Table (CLUT).
>
> Both formats use eight pixels/byte, so in practice there is no functional
> changes in this patch. But still the correct pixel format should be used.
>
> Suggested-by: Geert Uytterhoeven <geert@linux-m68k.org>
> Signed-off-by: Javier Martinez Canillas <javierm@redhat.com>

Reviewed-by: Geert Uytterhoeven <geert@linux-m68k.org>

Gr{oetje,eeting}s,

                        Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

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