[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <2de65f47-6512-400d-82c9-ae2ba9fdaa12@gmail.com>
Date: Mon, 18 Dec 2023 13:32:56 +0100
From: Alex Bee <knaerzche@...il.com>
To: Maxime Ripard <mripard@...nel.org>
Cc: Sandy Huang <hjc@...k-chips.com>, Heiko Stübner
<heiko@...ech.de>, Andy Yan <andyshrk@....com>,
Rob Herring <robh+dt@...nel.org>,
Krzysztof Kozlowski <krzysztof.kozlowski+dt@...aro.org>,
Conor Dooley <conor+dt@...nel.org>,
Maarten Lankhorst <maarten.lankhorst@...ux.intel.com>,
Thomas Zimmermann <tzimmermann@...e.de>, David Airlie <airlied@...il.com>,
Daniel Vetter <daniel@...ll.ch>, devicetree@...r.kernel.org,
linux-arm-kernel@...ts.infradead.org, linux-rockchip@...ts.infradead.org,
linux-kernel@...r.kernel.org
Subject: Re: [PATCH v2 18/27] drm/rockchip: inno_hdmi: Subclass connector
state
Hi,
Am 18.12.23 um 10:02 schrieb Maxime Ripard:
> Hi,
>
> Thanks for working on that, it's much better now.
>
> On Sat, Dec 16, 2023 at 05:26:29PM +0100, Alex Bee wrote:
>> +static struct drm_connector_state *
>> +inno_hdmi_connector_duplicate_state(struct drm_connector *connector)
>> +{
>> + struct inno_hdmi_connector_state *inno_conn_state;
>> +
>> + if (WARN_ON(!connector->state))
>> + return NULL;
>> +
>> + inno_conn_state = kmemdup(to_inno_hdmi_conn_state(connector->state),
>> + sizeof(*inno_conn_state), GFP_KERNEL);
>> +
>> + if (!inno_conn_state)
>> + return NULL;
>> +
>> + __drm_atomic_helper_connector_duplicate_state(connector,
>> + &inno_conn_state->base);
>> +
>> + return &inno_conn_state->base;
>> +}
>> +
>> static const struct drm_connector_funcs inno_hdmi_connector_funcs = {
>> .fill_modes = inno_hdmi_probe_single_connector_modes,
>> .detect = inno_hdmi_connector_detect,
>> .destroy = inno_hdmi_connector_destroy,
>> .reset = drm_atomic_helper_connector_reset,
>> - .atomic_duplicate_state = drm_atomic_helper_connector_duplicate_state,
>> + .atomic_duplicate_state = inno_hdmi_connector_duplicate_state,
>> .atomic_destroy_state = drm_atomic_helper_connector_destroy_state,
>> };
> You also need a custom reset and atomic_destroy_state implementations
Yea sure - thanks for the heads up.
I had this in multiple commits locally and thought I squashed them into
this one. Well, I obviously didn't :)
Alex
> Maxime
Powered by blists - more mailing lists