All of lore.kernel.org
 help / color / mirror / Atom feed
From: Javier Martinez Canillas <javierm@redhat.com>
To: Thomas Zimmermann <tzimmermann@suse.de>,
	daniel@ffwll.ch, airlied@linux.ie,
	maarten.lankhorst@linux.intel.com, mripard@kernel.org,
	jani.nikula@linux.intel.com, lyude@redhat.com
Cc: dri-devel@lists.freedesktop.org
Subject: Re: [PATCH 3/8] drm/display: Introduce a DRM display-helper module
Date: Thu, 7 Apr 2022 09:43:05 +0200	[thread overview]
Message-ID: <f6daa1b3-8267-72ee-182a-6ed61fe650cf@redhat.com> (raw)
In-Reply-To: <b17ead61-b7f1-d57a-d51f-c961d8ad59a1@suse.de>

On 4/6/22 21:08, Thomas Zimmermann wrote:
> Hi Javier
> 
> Am 30.03.22 um 11:23 schrieb Javier Martinez Canillas:
>> On 3/22/22 20:27, Thomas Zimmermann wrote:
>>> Replace the DP-helper module with a display-helper module. Update
>>> all related Kconfig and Makefile rules.
>>>
>>> Besides the existing code for DisplayPort, the new module will
>>> contain helpers for other video-output standards, such as HDMI.
>>> Drivers will still be able to select the required video-output
>>> helpers. Linking all such code into a single module avoids the
>>> proliferation of small kernel modules.
>>>
>>> Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
>>> ---
>>
>> [snip]
>>
>>> +config DRM_DISPLAY_HELPER
>>> +	tristate
>>> +	depends on DRM
>>> +	help
>>> +	  DRM helpers for display adapters.
>>> +
>>>   config DRM_DP_HELPER
>>>   	tristate
>>>   	depends on DRM
>>> +	select DRM_DISPLAY_HELPER
>>>   	help
>>>   	  DRM helpers for DisplayPort.
>>>
>>
>> I was about to ask why this would still be needed but then re-read the
>> commit message that says drivers will still be able to select required
>> video-output helpers.
>>
>> That makes sense since the fact that all helpers will be in the same module
>> would be transparent to drivers.
> 
> After some more testing, it turns out to be not so easy. For example, if 
> we have DP_HELPER=m and HDMI_HELPER=y, then DISPLAY_HELPER would be 
> auto-selected as 'y'. The code for DP_HELPER would not be linked correctly.
>
> I'm going to make drivers select DISPLAY_HELPER and the rsp helpers 
> explicitly. The individual helpers would be covered boolean options that 
> enable the feature in the display-helper library.
> 
> If you know some Kconfig magic to enable the original design, let me know.
>

I do not. But I wonder if the problem here is the usage of select rather than
depends and if with the later the original design could still be achieved...

But yes, probably the only way to prevent that issue is to make the drivers
to explicitly select both DRM_DISPLAY_HELPER and respective helpers symbol.
 -- 
Best regards,

Javier Martinez Canillas
Linux Engineering
Red Hat


  reply	other threads:[~2022-04-07  7:43 UTC|newest]

Thread overview: 33+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-03-22 19:27 [PATCH 0/8] drm: Introduce display-helper library Thomas Zimmermann
2022-03-22 19:27 ` [PATCH 1/8] drm: Put related statements next to each other in Makefile Thomas Zimmermann
2022-03-30  8:13   ` Jani Nikula
2022-03-30  8:13   ` Javier Martinez Canillas
2022-03-22 19:27 ` [PATCH 2/8] drm: Rename dp/ to display/ Thomas Zimmermann
2022-03-30  9:04   ` Javier Martinez Canillas
2022-03-30  9:24     ` Thomas Zimmermann
2022-03-30 13:52   ` Alex Deucher
2022-03-22 19:27 ` [PATCH 3/8] drm/display: Introduce a DRM display-helper module Thomas Zimmermann
2022-03-30  9:23   ` Javier Martinez Canillas
2022-03-30 10:32     ` Thomas Zimmermann
2022-03-31  6:57       ` Javier Martinez Canillas
2022-04-06 19:08     ` Thomas Zimmermann
2022-04-07  7:43       ` Javier Martinez Canillas [this message]
2022-04-07  8:03         ` Thomas Zimmermann
2022-04-07  8:45           ` Jani Nikula
2022-04-18 18:13             ` Thomas Zimmermann
2022-03-22 19:27 ` [PATCH 4/8] drm/display: Split DisplayPort header into core and helper Thomas Zimmermann
2022-04-01  7:18   ` Javier Martinez Canillas
2022-03-22 19:27 ` [PATCH 5/8] drm/display: Move DSC header and helpers into display-helper module Thomas Zimmermann
2022-04-01  7:23   ` Javier Martinez Canillas
2022-03-22 19:27 ` [PATCH 6/8] drm/display: Move HDCP " Thomas Zimmermann
2022-03-30  7:12   ` Jani Nikula
2022-03-30  8:05     ` Thomas Zimmermann
2022-04-01  8:23   ` Javier Martinez Canillas
2022-03-22 19:27 ` [PATCH 7/8] drm/display: Move HDMI " Thomas Zimmermann
2022-03-30 10:35   ` Jani Nikula
2022-04-06 19:47     ` Thomas Zimmermann
2022-04-07  7:32       ` Jani Nikula
2022-04-07  7:34         ` Jani Nikula
2022-04-07  7:44           ` Thomas Zimmermann
2022-03-22 19:27 ` [PATCH 8/8] drm/display: Move SCDC helpers into display-helper library Thomas Zimmermann
2022-03-29 19:26 ` [PATCH 0/8] drm: Introduce " Lyude Paul

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=f6daa1b3-8267-72ee-182a-6ed61fe650cf@redhat.com \
    --to=javierm@redhat.com \
    --cc=airlied@linux.ie \
    --cc=daniel@ffwll.ch \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=jani.nikula@linux.intel.com \
    --cc=lyude@redhat.com \
    --cc=maarten.lankhorst@linux.intel.com \
    --cc=mripard@kernel.org \
    --cc=tzimmermann@suse.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.