Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.31 as permitted sender) client-ip=23.128.96.31;
From:   Javier Martinez Canillas <javierm@redhat.com>
To:     Maxime Ripard <mripard@kernel.org>
Cc:     linux-kernel@vger.kernel.org,
        Thomas Zimmermann <tzimmermann@suse.de>,
        Geert Uytterhoeven <geert@linux-m68k.org>,
        Daniel Vetter <daniel@ffwll.ch>,
        David Airlie <airlied@gmail.com>,
        dri-devel@lists.freedesktop.org
Subject: Re: [PATCH v4] drm/ssd130x: Store the HW buffer in the
 driver-private CRTC state
In-Reply-To: <b4gfkcv3zdtdgcpucufwfmi7225redkxll75gr72zdirqtrrj4@u4kvevdmhtvt>
References: <20230913052938.1114651-1-javierm@redhat.com>
 <4norb2kxq4uxs3imi3qjxhyxpvnyf5cpl4sg7yyf3ydrykqhfl@cb3w4wstak7r>
 <871qf028ie.fsf@minerva.mail-host-address-is-not-set>
 <b4gfkcv3zdtdgcpucufwfmi7225redkxll75gr72zdirqtrrj4@u4kvevdmhtvt>
Date:   Thu, 14 Sep 2023 18:38:16 +0200
Message-ID: <8734zg677r.fsf@minerva.mail-host-address-is-not-set>
MIME-Version: 1.0
Content-Type: text/plain
Precedence: bulk

Maxime Ripard <mripard@kernel.org> writes:

> On Thu, Sep 14, 2023 at 03:23:53PM +0200, Javier Martinez Canillas wrote:
>> Maxime Ripard <mripard@kernel.org> writes:
>> 
>> Hello Maxime,
>> 
>> > Hi,
>> >
>> > On Wed, Sep 13, 2023 at 07:29:25AM +0200, Javier Martinez Canillas wrote:
>> >>  static const struct drm_crtc_helper_funcs ssd130x_crtc_helper_funcs = {
>> >>  	.mode_valid = ssd130x_crtc_helper_mode_valid,
>> >> -	.atomic_check = drm_crtc_helper_atomic_check,
>> >> +	.atomic_check = ssd130x_crtc_helper_atomic_check,
>> >>  };
>> >
>> > Sorry I didn't catch that sooner, but there's no reason to call that
>> > function a helper.
>> >
>> 
>> Yeah, agreed that there's no reason but others drivers already add the
>> _helper prefix for struct drm_*_helper_funcs callbacks, and I did that
>> in this driver as well to follow (what appears to be?) a convention.
>
> From a quick grep, it looks like it's the exception rather than the norm
>

Ah, I guess that was just unlucky when looking at others drivers as
reference when writing this one.

>> So I've to that now for the struct drm_crtc_helper_funcs handlers to be
>> consistent with the rest of the driver, e.g for plane:
>> 
>> static const struct drm_plane_helper_funcs ssd130x_primary_plane_helper_funcs = {
>> 	DRM_GEM_SHADOW_PLANE_HELPER_FUNCS,
>> 	.atomic_check = ssd130x_primary_plane_helper_atomic_check,
>> 	.atomic_update = ssd130x_primary_plane_helper_atomic_update,
>> 	.atomic_disable = ssd130x_primary_plane_helper_atomic_disable,
>> };
>> 
>> static const struct drm_plane_funcs ssd130x_primary_plane_funcs = {
>> 	.update_plane = drm_atomic_helper_update_plane,
>> 	.disable_plane = drm_atomic_helper_disable_plane,
>> 	.reset = ssd130x_primary_plane_reset,
>> 	.atomic_duplicate_state = ssd130x_primary_plane_duplicate_state,
>> 	.atomic_destroy_state = ssd130x_primary_plane_destroy_state,
>> 	.destroy = drm_plane_cleanup,
>> };
>
> Ack.
>
> I still believe we should be removing the helper part, those are not
> helpers. But it's not a big deal anyway.
>

Probably it comes down to semantics since one could argue that are helper
functions in the driver that are used as callbacks.

But yes, I agree that if is not the norm, it's better to get rid of those.
I'll post a follow-up patch.

> Maxime

-- 
Best regards,

Javier Martinez Canillas
Core Platforms
Red Hat