Re: [PATCH v2] drm/display: Select DP helper for DRM_DP_AUX_CHARDEV and DRM_DP_CEC

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi

Am 28.04.22 um 09:52 schrieb Javier Martinez Canillas:
On 4/28/22 09:45, Thomas Zimmermann wrote:

[snip]

You cannot select DISPLAY_DP_HELPER without DISPLAY_HELPER.


That was my original thought as well and what did in v1, but then I noticed
that doing that it would force DRM_DISPLAY_HELPER to be set as built-in and
not allow to be built as a module.

It was a rhetorical only. I didn't mean to actually set DISPLAY_HELPER.


Ah, sorry for misunderstanding.

Can't you simply make it depend on DISPLAY_DP_HELPER.  The menu entry
will show up as soon as there's a driver that selcets DISPLAY_DP_HELPER.


I could but then that means that once won't be able to select these two config
options unless some enable symbol selects DRM_DISPLAY_DP_HELPER.

In my opinion, DRM_DP_AUX_CHARDEV and DRM_DP_CEC are different than all other
options that select DRM_DISPLAY_DP_HELPER, since those are drivers and want to
have both DRM_DISPLAY_DP_HELPER and DRM_DISPLAY_HELPER set.

But DRM_DP_AUX_CHARDEV and DRM_DP_CEC are just included in drm_display_helper.o
if enabled, and depend on symbols that are present if CONFIG_DRM_DISPLAY_DP_HELPER
is enabled. So just need the latter, if DRM_DISPLAY_HELPER is not enabled then it
will just be a no-op.

Having written that though I noticed that a "depends on DRM_DISPLAY_HELPER" makes
sense. If you agree I can add it and post a v3.

Yes please.  These options enable features of the DP code. If there's no
driver with DP, it doesn't make sense to allow them.

I know that there could be an odd situation where userspace might not
have DP, but still wants the chardev file of aux bus.  But that
situation existed already when the code was located within KMS helpers.


Agreed.


Now, pondering more about this issue, probably the most correct thing to do is for
the drivers that make use of the symbols exported by DRM_DP_{AUX_CHARDEV,CEC} to
select these. What do you think ?

That's not considered good style. Select should not be used for anything
that is user-configurable. [1]


Right. So giving even more thought to this, now I think that we should just include
drm_dp_aux_dev.o, drm_dp_cec.o (and probably drm_dp_aux_bus.o?) unconditionally to
drm_display_helper-$(CONFIG_DRM_DISPLAY_DP_HELPER).

After all, these are not big objects and drm_display_helper can now be built as module.

I don't see that much value to have separate user-configurable config options...


I don't know the side effects of this. We're exporting another device file after all.

For know I'd make them depend on DRM_DISPLAY_DP_HELPER. If someone complains we can revert and fix the linker error by adding stub functions for the missing symbols.

Best regards
Thomas

--
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Maxfeldstr. 5, 90409 Nürnberg, Germany
(HRB 36809, AG Nürnberg)
Geschäftsführer: Ivo Totev

Attachment: OpenPGP_signature
Description: OpenPGP digital signature


[Index of Archives]     [Linux DRI Users]     [Linux Intel Graphics]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [XFree86]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [XFree86]
  Powered by Linux