[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <87bkkaonkr.fsf@oltmanns.dev>
Date: Thu, 30 Mar 2023 06:41:44 +0200
From: Frank Oltmanns <frank@...manns.dev>
To: Maxime Ripard <maxime@...no.tech>
Cc: Roman Beranek <romanberanek@...oud.com>,
Chen-Yu Tsai <wens@...e.org>, David Airlie <airlied@...il.com>,
Daniel Vetter <daniel@...ll.ch>,
Jernej Skrabec <jernej.skrabec@...il.com>,
Samuel Holland <samuel@...lland.org>,
dri-devel@...ts.freedesktop.org,
linux-arm-kernel@...ts.infradead.org, linux-sunxi@...ts.linux.dev,
linux-kernel@...r.kernel.org
Subject: Re: [PATCH] drm/sun4i: uncouple DSI dotclock divider from
TCON0_DCLK_REG
Hi,
On 2023-03-29 at 21:56:39 +0200, Maxime Ripard <maxime@...no.tech> wrote:
> Hi,
>
> On Tue, Mar 28, 2023 at 09:28:19PM +0200, Frank Oltmanns wrote:
>> --- a/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c
>> +++ b/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c
>> @@ -819,6 +819,34 @@ static void sun6i_dsi_encoder_disable(struct drm_encoder *encoder)
>> regulator_disable(dsi->regulator);
>> }
>>
>> +static bool sun6i_dsi_encoder_mode_fixup(
>> + struct drm_encoder *encoder,
>> + const struct drm_display_mode *mode,
>> + struct drm_display_mode *adjusted_mode)
>
> So, mode_fixup is kind of deprecated in favour of atomic_check
I see. Thanks for pointing that out.
>> +{
>> + if (encoder->encoder_type == DRM_MODE_ENCODER_DSI) {
>> + /*
>> + * For DSI the PLL rate has to respect the bits per pixel and
>> + * number of lanes.
>> + *
>> + * According to the BSP code:
>> + * PLL rate = DOTCLOCK * bpp / lanes
>> + *
>> + * Therefore, the clock has to be adjusted in order to set the
>> + * correct PLL rate when actually setting the clock.
>> + */
>> + struct sun6i_dsi *dsi = encoder_to_sun6i_dsi(encoder);
>> + struct mipi_dsi_device *device = dsi->device;
>> + u8 bpp = mipi_dsi_pixel_format_to_bpp(device->format);
>> + u8 lanes = device->lanes;
>> +
>> + adjusted_mode->crtc_clock = mode->crtc_clock
>> + * bpp / (lanes * SUN6I_DSI_TCON_DIV);
>
> And that's visible to the userspace, so it's not where we should store
> that value. I guess the best way to do something similar would be to
> store it into crtc_state, and then reuse it there. But it starts to make
> a lot of rather complicated code compared to your previous patch.
Ah, interesting. But I agree, let's stick to the simpler aproach.
Thanks,
Frank
>
> Maxime
>
> [[End of PGP Signed Part]]
--
Powered by blists - more mailing lists