Re: 2024 X.Org Foundation Membership deadline for voting in the election
Hi Pekka, On Tue, Apr 02, 2024 at 10:46:08AM +0300, Pekka Paalanen wrote: > On Tue, 26 Mar 2024 11:42:48 -0400 Christopher Michael wrote: > > > The 2024 X.Org Foundation membership renewal period has been extended > > one additional week and elections will start the following week on 01 > > April 2024. > > > > Please note that only current members can vote in the upcoming election, > > and that the deadline for new memberships or renewals to vote in the > > upcoming election is 01 April 2024 at 23:59 UTC. > > > > If you are interested in joining the X.Org Foundation or in renewing > > your membership, please visit the membership system site at: > > https://members.x.org/ > > > > Christopher Michael, on behalf of the X.Org elections committee > > Hi everyone, > > given that the year's first email reminding everyone to renew their > memberships was sent on Feb 7 when the renewal was NOT open yet, I > wonder how many people thought they had already renewed and are now > thinking they don't need to do anything? > > I fell for that: On Feb 7, I went to members.x.org to check my status, > it said I was registered for "2023-2024" and there was no button to > renew, so I closed the page confident that I was a member for 2024. > After all, it said 2024. This was a mistake I realised only after being > personally poked to renew. I know for sure of one other person falling > for the same. Make that two. Thanks for the notice. > Now, the members page for this year says "Application for the period: > 02/2024-02/2025". Thanks to the people adding the month to reduce > confusion. -- Regards, Laurent Pinchart
Re: [Intel-gfx] [PATCH 3/4] drm/uapi: document the USB subconnector type
On Thu, Aug 03, 2023 at 03:31:16PM +, Simon Ser wrote: > On Thursday, August 3rd, 2023 at 17:22, Simon Ser wrote: > > > The KMS docs describe "subconnector" to be defined as "downstream port" for > > DP. > > Can USB-C (or USB) be seen as a DP downstream port? > > To expand on this a bit: I'm wondering if we're mixing apples and > oranges here. The current values of "subconnector" typically describe > the lower-level protocol tunneled inside DP. For instance, VGA can be > tunneled inside the DP cable when using DP → VGA adapter. Doesn't this contradict the example use case you gave in your previous e-mail, with wlroots stating "DP-3 via DVI-D" ? I understand that as DP carried over a DVI-D physical connector, did I get it wrong ? > However, in the USB-C case, DP itself is tunneled inside USB-C. And you > might use a USB-C → DP adapter. So it's not really *sub*connector, it's > more of a *super*connector, right? > > I think [1] is somewhat related, since it also allows user-space to > discover whether a connector uses USB-C. But relying on sysfs to figure > this out isn't super optimal perhaps. > > [1]: > https://lore.kernel.org/dri-devel/20221108185004.2263578-1-wonch...@google.com/ -- Regards, Laurent Pinchart
Re: [Intel-gfx] [PATCH 3/4] drm/uapi: document the USB subconnector type
On Wed, Aug 02, 2023 at 10:01:19PM +0300, Dmitry Baryshkov wrote:
> On 02/08/2023 21:55, Laurent Pinchart wrote:
> > Hi Dmitry,
> >
> > Thank you for the patch.
> >
> > On Sat, Jul 29, 2023 at 03:49:12AM +0300, Dmitry Baryshkov wrote:
> >> To properly define the USB-C DP altmode connectors, add the USB
> >> subconnector type.
> >>
> >> Suggested-by: Simon Ser
> >> Signed-off-by: Dmitry Baryshkov
> >> ---
> >> drivers/gpu/drm/drm_connector.c | 1 +
> >> include/uapi/drm/drm_mode.h | 1 +
> >> 2 files changed, 2 insertions(+)
> >>
> >> diff --git a/drivers/gpu/drm/drm_connector.c
> >> b/drivers/gpu/drm/drm_connector.c
> >> index a6066e4a5e9a..9e96b038f5d0 100644
> >> --- a/drivers/gpu/drm/drm_connector.c
> >> +++ b/drivers/gpu/drm/drm_connector.c
> >> @@ -1050,6 +1050,7 @@ static const struct drm_prop_enum_list
> >> drm_dp_subconnector_enum_list[] = {
> >>{ DRM_MODE_SUBCONNECTOR_DisplayPort, "DP"}, /* DP */
> >>{ DRM_MODE_SUBCONNECTOR_Wireless,"Wireless" }, /* DP */
> >>{ DRM_MODE_SUBCONNECTOR_Native, "Native"}, /* DP */
> >> + { DRM_MODE_SUBCONNECTOR_USB, "USB" }, /* DP */
> >
> > Should this be DRM_MODE_SUBCONNECTOR_USB_C and "USB-C", in case we get
> > another USB type later ?
>
> Hmm, which id should I use for micro-USB then? (consider anx7808,
> SlimPort). I thought about using DRM_MODE_SUBCONNECTOR_USB for both of
> them. But maybe I should add another subtype for SlimPort.
I suppose it depends on whether userspace needs a way to differentiate
those. Do you have a good visibility on the userspace use cases ?
> >> };
> >>
> >> DRM_ENUM_NAME_FN(drm_get_dp_subconnector_name,
> >> diff --git a/include/uapi/drm/drm_mode.h b/include/uapi/drm/drm_mode.h
> >> index 92d96a2b6763..0f74918b011c 100644
> >> --- a/include/uapi/drm/drm_mode.h
> >> +++ b/include/uapi/drm/drm_mode.h
> >> @@ -398,6 +398,7 @@ enum drm_mode_subconnector {
> >>DRM_MODE_SUBCONNECTOR_HDMIA = 11, /*DP */
> >>DRM_MODE_SUBCONNECTOR_Native = 15, /*DP */
> >>DRM_MODE_SUBCONNECTOR_Wireless= 18, /*DP */
> >> + DRM_MODE_SUBCONNECTOR_USB = 20, /*DP */
> >> };
> >>
> >> #define DRM_MODE_CONNECTOR_Unknown 0
--
Regards,
Laurent Pinchart
Re: [Intel-gfx] [PATCH 3/4] drm/uapi: document the USB subconnector type
Hi Dmitry,
Thank you for the patch.
On Sat, Jul 29, 2023 at 03:49:12AM +0300, Dmitry Baryshkov wrote:
> To properly define the USB-C DP altmode connectors, add the USB
> subconnector type.
>
> Suggested-by: Simon Ser
> Signed-off-by: Dmitry Baryshkov
> ---
> drivers/gpu/drm/drm_connector.c | 1 +
> include/uapi/drm/drm_mode.h | 1 +
> 2 files changed, 2 insertions(+)
>
> diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
> index a6066e4a5e9a..9e96b038f5d0 100644
> --- a/drivers/gpu/drm/drm_connector.c
> +++ b/drivers/gpu/drm/drm_connector.c
> @@ -1050,6 +1050,7 @@ static const struct drm_prop_enum_list
> drm_dp_subconnector_enum_list[] = {
> { DRM_MODE_SUBCONNECTOR_DisplayPort, "DP"}, /* DP */
> { DRM_MODE_SUBCONNECTOR_Wireless,"Wireless" }, /* DP */
> { DRM_MODE_SUBCONNECTOR_Native, "Native"}, /* DP */
> + { DRM_MODE_SUBCONNECTOR_USB, "USB" }, /* DP */
Should this be DRM_MODE_SUBCONNECTOR_USB_C and "USB-C", in case we get
another USB type later ?
> };
>
> DRM_ENUM_NAME_FN(drm_get_dp_subconnector_name,
> diff --git a/include/uapi/drm/drm_mode.h b/include/uapi/drm/drm_mode.h
> index 92d96a2b6763..0f74918b011c 100644
> --- a/include/uapi/drm/drm_mode.h
> +++ b/include/uapi/drm/drm_mode.h
> @@ -398,6 +398,7 @@ enum drm_mode_subconnector {
> DRM_MODE_SUBCONNECTOR_HDMIA = 11, /*DP */
> DRM_MODE_SUBCONNECTOR_Native = 15, /*DP */
> DRM_MODE_SUBCONNECTOR_Wireless= 18, /* DP */
> + DRM_MODE_SUBCONNECTOR_USB = 20, /*DP */
> };
>
> #define DRM_MODE_CONNECTOR_Unknown 0
--
Regards,
Laurent Pinchart
Re: [Intel-gfx] [PATCH 1/4] drm: allow specifying default subtype for the DP subconnector property
roperty(connector); > diff --git a/include/drm/drm_connector.h b/include/drm/drm_connector.h > index 5a8115dca359..a130a78f6e0f 100644 > --- a/include/drm/drm_connector.h > +++ b/include/drm/drm_connector.h > @@ -1990,7 +1990,8 @@ const char *drm_get_hdcp_content_type_name(int val); > int drm_get_tv_mode_from_name(const char *name, size_t len); > > int drm_mode_create_dvi_i_properties(struct drm_device *dev); > -void drm_connector_attach_dp_subconnector_property(struct drm_connector > *connector); > +void drm_connector_attach_dp_subconnector_property(struct drm_connector > *connector, > +enum drm_mode_subconnector > subtype); > > int drm_mode_create_tv_margin_properties(struct drm_device *dev); > int drm_mode_create_tv_properties_legacy(struct drm_device *dev, -- Regards, Laurent Pinchart
Re: [Intel-gfx] [PATCH 2/4] drm/bridge-connector: handle subconnector types
Those ports would correspond to different connectors, so I agree with
Neil, I don't think it's right to create a single property with all
modes and attach it to all analog output connectors.
If you want to support multiple analog outputs that have different
capabilities, this will need changes to drm_mode_create_tv_properties()
to allow creating multiple properties. If you don't want to do so now,
and prefer limiting support to devices where all ports support the same
modes (which includes devices with a single analog output), then the
modes should reflect what the device supports.
> > > +
> > > + drm_object_attach_property(>base,
> > > +
> > > drm->mode_config.tv_subconnector_property,
> > > +subconnector);
> >
> > Here, only add the property if drm->mode_config.tv_subconnector_property
> > exists,
> > and perhaps add a warning if not.
>
> This property is created in the previous call,
> drm_mode_create_tv_properties() ->
> drm_mode_create_tv_properties_legacy().
>
> > AFAIK same for DRM_MODE_CONNECTOR_DVII.
> >
> > > + }
> > > +
> > > return connector;
> > > }
> > > EXPORT_SYMBOL_GPL(drm_bridge_connector_init);
> > > diff --git a/include/drm/drm_bridge.h b/include/drm/drm_bridge.h
> > > index bf964cdfb330..68b14ac5ac0d 100644
> > > --- a/include/drm/drm_bridge.h
> > > +++ b/include/drm/drm_bridge.h
> > > @@ -739,6 +739,10 @@ struct drm_bridge {
> > >* identifies the type of connected display.
> > >*/
> > > int type;
> > > + /**
> > > + * @subtype: the subtype of the connector for the DP/TV/DVI-I cases.
> > > + */
> > > + enum drm_mode_subconnector subtype;
> > > /**
> > >* @interlace_allowed: Indicate that the bridge can handle
> > > interlaced
> > >* modes.
--
Regards,
Laurent Pinchart
Re: [Intel-gfx] 2023 X.Org Foundation Membership deadline for voting in the election
Hi Ricardo, On Mon, Mar 13, 2023 at 04:22:54PM +0100, Ricardo Garcia wrote: > This is a reminder that the deadline for new memberships and renewals > finishes in a couple of weeks. Original email follows. > > Thanks for your attention. I don't know if I'm the only one affected by this issue, but I've just received today two months of e-mails from x.org, including all the reminders aboud membership renewal and election nomination period. This isn't the first time this happens, and the last time I was told there was no automated process to quick the mail queues when errors happen, making mails pile up forever on x.org's side until someone handles it manually. This is something you really want to automate, or at least monitored. > On Wed, 2023-02-15 at 16:58 +0100, Ricardo Garcia wrote: > > The 2023 X.Org Foundation elections are rapidly approaching. We will be > > forwarding the election schedule and nominating process to the > > membership shortly. > > > > Please note that only current members can vote in the upcoming election, > > and that the deadline for new memberships or renewals to vote in the > > upcoming election is 26 March 2023 at 23:59 UTC. > > > > If you are interested in joining the X.Org Foundation or in renewing > > your membership, please visit the membership system site at: > > https://members.x.org/ > > > > Ricardo Garcia, on behalf of the X.Org elections committee -- Regards, Laurent Pinchart
Re: [Intel-gfx] [PATCH v2] drm/scdc-helper: Pimp SCDC debugs
Hi Ville,
Thank you for the patch.
On Tue, Apr 04, 2023 at 01:36:52AM +0300, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> Include the device and connector information in the SCDC
> debugs. Makes it easier to figure out who did what.
>
> v2: Rely on connector->ddc (Maxime)
>
> Cc: Andrzej Hajda
> Cc: Neil Armstrong
> Cc: Robert Foss
> Cc: Laurent Pinchart
> Cc: Jonas Karlman
> Cc: Jernej Skrabec
> Cc: Thierry Reding
> Cc: Emma Anholt
> Cc: Maxime Ripard
> Cc: intel-gfx@lists.freedesktop.org
> Cc: linux-te...@vger.kernel.org
> Signed-off-by: Ville Syrjälä
Reviewed-by: Laurent Pinchart
> ---
> drivers/gpu/drm/bridge/synopsys/dw-hdmi.c | 8 ++--
> drivers/gpu/drm/display/drm_scdc_helper.c | 46 +++
> drivers/gpu/drm/i915/display/intel_ddi.c | 4 +-
> drivers/gpu/drm/i915/display/intel_hdmi.c | 8 +---
> drivers/gpu/drm/tegra/sor.c | 15 +++-
> drivers/gpu/drm/vc4/vc4_hdmi.c| 21 ++-
> include/drm/display/drm_scdc_helper.h | 7 ++--
> 7 files changed, 59 insertions(+), 50 deletions(-)
>
> diff --git a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
> b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
> index aa51c61a78c7..603bb3c51027 100644
> --- a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
> +++ b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
> @@ -1426,9 +1426,9 @@ void dw_hdmi_set_high_tmds_clock_ratio(struct dw_hdmi
> *hdmi,
> /* Control for TMDS Bit Period/TMDS Clock-Period Ratio */
> if (dw_hdmi_support_scdc(hdmi, display)) {
> if (mtmdsclock > HDMI14_MAX_TMDSCLK)
> - drm_scdc_set_high_tmds_clock_ratio(hdmi->ddc, 1);
> + drm_scdc_set_high_tmds_clock_ratio(>connector, 1);
> else
> - drm_scdc_set_high_tmds_clock_ratio(hdmi->ddc, 0);
> + drm_scdc_set_high_tmds_clock_ratio(>connector, 0);
> }
> }
> EXPORT_SYMBOL_GPL(dw_hdmi_set_high_tmds_clock_ratio);
> @@ -2116,7 +2116,7 @@ static void hdmi_av_composer(struct dw_hdmi *hdmi,
> min_t(u8, bytes, SCDC_MIN_SOURCE_VERSION));
>
> /* Enabled Scrambling in the Sink */
> - drm_scdc_set_scrambling(hdmi->ddc, 1);
> + drm_scdc_set_scrambling(>connector, 1);
>
> /*
>* To activate the scrambler feature, you must ensure
> @@ -2132,7 +2132,7 @@ static void hdmi_av_composer(struct dw_hdmi *hdmi,
> hdmi_writeb(hdmi, 0, HDMI_FC_SCRAMBLER_CTRL);
> hdmi_writeb(hdmi, (u8)~HDMI_MC_SWRSTZ_TMDSSWRST_REQ,
> HDMI_MC_SWRSTZ);
> - drm_scdc_set_scrambling(hdmi->ddc, 0);
> + drm_scdc_set_scrambling(>connector, 0);
> }
> }
>
> diff --git a/drivers/gpu/drm/display/drm_scdc_helper.c
> b/drivers/gpu/drm/display/drm_scdc_helper.c
> index c3ad4ab2b456..6d2f244e5830 100644
> --- a/drivers/gpu/drm/display/drm_scdc_helper.c
> +++ b/drivers/gpu/drm/display/drm_scdc_helper.c
> @@ -26,6 +26,8 @@
> #include
>
> #include
> +#include
> +#include
> #include
>
> /**
> @@ -140,7 +142,7 @@ EXPORT_SYMBOL(drm_scdc_write);
>
> /**
> * drm_scdc_get_scrambling_status - what is status of scrambling?
> - * @adapter: I2C adapter for DDC channel
> + * @connector: connector
> *
> * Reads the scrambler status over SCDC, and checks the
> * scrambling status.
> @@ -148,14 +150,16 @@ EXPORT_SYMBOL(drm_scdc_write);
> * Returns:
> * True if the scrambling is enabled, false otherwise.
> */
> -bool drm_scdc_get_scrambling_status(struct i2c_adapter *adapter)
> +bool drm_scdc_get_scrambling_status(struct drm_connector *connector)
> {
> u8 status;
> int ret;
>
> - ret = drm_scdc_readb(adapter, SCDC_SCRAMBLER_STATUS, );
> + ret = drm_scdc_readb(connector->ddc, SCDC_SCRAMBLER_STATUS, );
> if (ret < 0) {
> - DRM_DEBUG_KMS("Failed to read scrambling status: %d\n", ret);
> + drm_dbg_kms(connector->dev,
> + "[CONNECTOR:%d:%s] Failed to read scrambling
> status: %d\n",
> + connector->base.id, connector->name, ret);
> return false;
> }
>
> @@ -165,7 +169,7 @@ EXPORT_SYMBOL(drm_scdc_get_scrambling_status);
>
> /**
> * drm_scdc_set_scrambling - enable scrambling
> - * @adapter: I2C adapter for DDC channel
> + * @connector: connector
> * @enable: bool to indicate if scrambling is to be enabled/disab
Re: [Intel-gfx] [PATCH v2] drm/probe_helper: sort out poll_running vs poll_enabled
Hi Dmitry,
Thank you for the patch.
On Wed, Jan 18, 2023 at 01:39:05AM +0200, Dmitry Baryshkov wrote:
> There are two flags attemting to guard connector polling:
> poll_enabled and poll_running. While poll_enabled semantics is clearly
> defined and fully adhered (mark that drm_kms_helper_poll_init() was
> called and not finalized by the _fini() call), the poll_running flag
> doesn't have such clearliness.
>
> This flag is used only in drm_helper_probe_single_connector_modes() to
> guard calling of drm_kms_helper_poll_enable, it doesn't guard the
> drm_kms_helper_poll_fini(), etc. Change it to only be set if the polling
> is actually running. Tie HPD enablement to this flag.
>
> This fixes the following warning reported after merging the HPD series:
>
> Hot plug detection already enabled
> WARNING: CPU: 2 PID: 9 at drivers/gpu/drm/drm_bridge.c:1257
> drm_bridge_hpd_enable+0x94/0x9c [drm]
> Modules linked in: videobuf2_memops snd_soc_simple_card
> snd_soc_simple_card_utils fsl_imx8_ddr_perf videobuf2_common
> snd_soc_imx_spdif adv7511 etnaviv imx8m_ddrc imx_dcss mc cec nwl_dsi gov
> CPU: 2 PID: 9 Comm: kworker/u8:0 Not tainted 6.2.0-rc2-15208-g25b283acd578 #6
> Hardware name: NXP i.MX8MQ EVK (DT)
> Workqueue: events_unbound deferred_probe_work_func
> pstate: 6005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)
> pc : drm_bridge_hpd_enable+0x94/0x9c [drm]
> lr : drm_bridge_hpd_enable+0x94/0x9c [drm]
> sp : 89ef3740
> x29: 89ef3740 x28: 09331f00 x27: 1000
> x26: 0020 x25: 81148ed8 x24: 0a8fe000
> x23: fffd x22: 05086348 x21: 81133ee0
> x20: 0550d800 x19: 05086288 x18: 0006
> x17: x16: 896ef008 x15: 972891004260
> x14: 2a1403e19400 x13: 972891004260 x12: 2a1403e19400
> x11: 7100385f29400801 x10: 0aa0 x9 : 88112744
> x8 : 00250b00 x7 : 0003 x6 : 0011
> x5 : x4 : bd986a48 x3 : 0001
> x2 : x1 : x0 : 0025
> Call trace:
> drm_bridge_hpd_enable+0x94/0x9c [drm]
> drm_bridge_connector_enable_hpd+0x2c/0x3c [drm_kms_helper]
> drm_kms_helper_poll_enable+0x94/0x10c [drm_kms_helper]
> drm_helper_probe_single_connector_modes+0x1a8/0x510 [drm_kms_helper]
> drm_client_modeset_probe+0x204/0x1190 [drm]
> __drm_fb_helper_initial_config_and_unlock+0x5c/0x4a4 [drm_kms_helper]
> drm_fb_helper_initial_config+0x54/0x6c [drm_kms_helper]
> drm_fbdev_client_hotplug+0xd0/0x140 [drm_kms_helper]
> drm_fbdev_generic_setup+0x90/0x154 [drm_kms_helper]
> dcss_kms_attach+0x1c8/0x254 [imx_dcss]
> dcss_drv_platform_probe+0x90/0xfc [imx_dcss]
> platform_probe+0x70/0xcc
> really_probe+0xc4/0x2e0
> __driver_probe_device+0x80/0xf0
> driver_probe_device+0xe0/0x164
> __device_attach_driver+0xc0/0x13c
> bus_for_each_drv+0x84/0xe0
> __device_attach+0xa4/0x1a0
> device_initial_probe+0x1c/0x30
> bus_probe_device+0xa4/0xb0
> deferred_probe_work_func+0x90/0xd0
> process_one_work+0x200/0x474
> worker_thread+0x74/0x43c
> kthread+0xfc/0x110
> ret_from_fork+0x10/0x20
> ---[ end trace ]---
>
> Reported-by: Laurentiu Palcu
> Fixes: c8268795c9a9 ("drm/probe-helper: enable and disable HPD on connectors")
> Tested-by: Marek Szyprowski
> Tested-by: Chen-Yu Tsai
> Signed-off-by: Dmitry Baryshkov
This fixes the issue on my Renesas boards.
Tested-by: Laurent Pinchart
Please see below for a few comments.
> ---
>
> Changes since v1:
> - Fixed drm_kms_helper_enable_hpd() to call enable_hpd() instead of
> disable_hpd().
>
> ---
> drivers/gpu/drm/drm_probe_helper.c | 110 +
> 1 file changed, 63 insertions(+), 47 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_probe_helper.c
> b/drivers/gpu/drm/drm_probe_helper.c
> index 7973f2589ced..04754bb7b131 100644
> --- a/drivers/gpu/drm/drm_probe_helper.c
> +++ b/drivers/gpu/drm/drm_probe_helper.c
> @@ -222,6 +222,45 @@ drm_connector_mode_valid(struct drm_connector *connector,
> return ret;
> }
>
> +static void drm_kms_helper_disable_hpd(struct drm_device *dev)
> +{
> + struct drm_connector *connector;
> + struct drm_connector_list_iter conn_iter;
> +
> + drm_connector_list_iter_begin(dev, _iter);
> + drm_for_each_connector_iter(connector, _iter) {
> + const struct drm_connector_helper_funcs *funcs =
> + connector->helper_private;
> +
> + if (funcs && funcs->disable_hpd)
> + funcs->disable_hpd(connector);
> + }
> + drm_con
Re: [Intel-gfx] [RFC 0/2] drm/connector: connector iterator with filtering
Hi Jani, On Tue, Nov 29, 2022 at 11:29:45AM +0200, Jani Nikula wrote: > On Fri, 25 Nov 2022, Harry Wentland wrote: > > On 10/5/22 06:51, Jani Nikula wrote: > >> Currently i915 assumes all drm_connectors it encounters are embedded in > >> intel_connectors that i915 allocated. The drm_writeback_connector forces > >> a design where this is not the case; we can't provide our own connector, > >> and writeback embeds the drm_connector it initializes itself. > >> > >> To use drm writeback, none of the i915 connector iteration could assume > >> the drm connector is embedded in intel_connector. Checking this is > >> tedious, and would require an intermediate step with > >> drm_connector. Here's an idea I came up with; filtering at the drm > >> connector iterator level with a caller supplied function. Not too much > >> code, and could be used for other things as well. > >> > > > > We've been trying to hook up drm_writeback_connector in amdgpu and > > this would be really helpful. I've had to do liberal sprinkling > > of "!= DRM_MODE_CONNECTOR_WRITEBACK" all over the place. > > > >> Mind you, we'd still much rather modify drm writeback to allow passing > >> the connector i915 allocated, instead of the current midlayer design > >> that forces drivers to a certain model. Working around this is a bunch > >> of error prone and tedious code that we really could do without. > > > > I think this would be even better but also be much more work and impact > > every driver that implements writeback. FWIW, there was no way for me > > to add writeback connector handling without KASAN. Interpreting the > > connector wrong in one place leads to memory corruption and > > undefined behavior and is almost impossible to spot without KASAN. > > Laurent, I once again plead - could we please reconsider this and give > drivers the option to allocate and provide the drm_connector to > writeback themselves? > > All things considered I think that would be the safer option. I do think all this stems from the decision of using connectors for writeback, and we're paying the price for it now. It's painful in drivers, and that's why I would prefer hiding it from drivers and handling it completely in the DRM core. Ideally the connector enumeration API exposed to drivers should not even enumerate the writeback connectors by default. I'm just a contributor to the subsystem, so I don't make the call. If there's a general consensus it's better to require all drivers to handle writeback connectors explicitly everywhere (Daniel and Dave may want to chime in here), I can be overruled, like anybody else. > > This series is > > Acked-by: Harry Wentland > > > >> Cc: Arun R Murthy > >> Cc: Dave Airlie > >> Cc: Laurent Pinchart > >> Cc: Suraj Kandpal > >> Cc: Ville Syrjälä > >> > >> Jani Nikula (2): > >> drm/connector: add connector list iteration with filtering > >> drm/i915: iterate intel_connectors only > >> > >> drivers/gpu/drm/drm_connector.c | 57 +++ > >> drivers/gpu/drm/i915/display/intel_display.c | 3 +- > >> .../drm/i915/display/intel_display_types.h| 7 +++ > >> drivers/gpu/drm/i915/display/intel_dp.c | 6 +- > >> drivers/gpu/drm/i915/display/intel_dp_mst.c | 3 +- > >> drivers/gpu/drm/i915/display/intel_hdcp.c | 3 +- > >> drivers/gpu/drm/i915/display/intel_hotplug.c | 12 ++-- > >> .../drm/i915/display/intel_modeset_setup.c| 6 +- > >> drivers/gpu/drm/i915/display/intel_opregion.c | 9 ++- > >> include/drm/drm_connector.h | 9 +++ > >> 10 files changed, 89 insertions(+), 26 deletions(-) -- Regards, Laurent Pinchart
Re: [Intel-gfx] [RFC 1/2] drm/connector: add connector list iteration with filtering
Hi Jani,
Thank you for the patch.
On Wed, Oct 05, 2022 at 01:51:43PM +0300, Jani Nikula wrote:
> Add new function drm_connector_list_iter_filter_begin() to initialize
> connector list iterator with a filter function. Subsequent iteration on
> the list will only return connectors on which the filter function
> returns true.
>
> Cc: Arun R Murthy
> Cc: Suraj Kandpal
> Cc: Ville Syrjälä
> Signed-off-by: Jani Nikula
> ---
> drivers/gpu/drm/drm_connector.c | 57 ++---
> include/drm/drm_connector.h | 9 ++
> 2 files changed, 54 insertions(+), 12 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
> index e3142c8142b3..d54b4b54cecb 100644
> --- a/drivers/gpu/drm/drm_connector.c
> +++ b/drivers/gpu/drm/drm_connector.c
> @@ -762,6 +762,29 @@ static struct lockdep_map connector_list_iter_dep_map = {
> };
> #endif
>
> +/**
> + * drm_connector_list_iter_filter_begin - initialize a connector_list
> iterator with filter
> + * @dev: DRM device
> + * @iter: connector_list iterator
> + * @filter: connector filter function
> + * @filter_context: context to be passed to the filter function
> + *
> + * Same as drm_connector_list_iter_begin(), but sets up the iterator to only
> + * return connectors where filter(connector) returns true.
> + */
> +void drm_connector_list_iter_filter_begin(struct drm_device *dev,
> + struct drm_connector_list_iter *iter,
> + drm_connector_list_iter_filter_fn
> filter,
> + void *filter_context)
> +{
> + iter->dev = dev;
> + iter->conn = NULL;
> + iter->filter = filter;
> + iter->filter_context = filter_context;
> + lock_acquire_shared_recursive(_list_iter_dep_map, 0, 1, NULL,
> _RET_IP_);
> +}
> +EXPORT_SYMBOL(drm_connector_list_iter_filter_begin);
> +
> /**
> * drm_connector_list_iter_begin - initialize a connector_list iterator
> * @dev: DRM device
> @@ -775,9 +798,7 @@ static struct lockdep_map connector_list_iter_dep_map = {
> void drm_connector_list_iter_begin(struct drm_device *dev,
> struct drm_connector_list_iter *iter)
> {
> - iter->dev = dev;
> - iter->conn = NULL;
> - lock_acquire_shared_recursive(_list_iter_dep_map, 0, 1, NULL,
> _RET_IP_);
> + drm_connector_list_iter_filter_begin(dev, iter, NULL, NULL);
> }
> EXPORT_SYMBOL(drm_connector_list_iter_begin);
I would have made this a static inline function in
include/drm/drm_connector.h. Apart from that,
Reviewed-by: Laurent Pinchart
>
> @@ -800,15 +821,8 @@ __drm_connector_put_safe(struct drm_connector *conn)
> schedule_work(>connector_free_work);
> }
>
> -/**
> - * drm_connector_list_iter_next - return next connector
> - * @iter: connector_list iterator
> - *
> - * Returns: the next connector for @iter, or NULL when the list walk has
> - * completed.
> - */
> -struct drm_connector *
> -drm_connector_list_iter_next(struct drm_connector_list_iter *iter)
> +static struct drm_connector *
> +__drm_connector_list_iter_next(struct drm_connector_list_iter *iter)
> {
> struct drm_connector *old_conn = iter->conn;
> struct drm_mode_config *config = >dev->mode_config;
> @@ -836,6 +850,25 @@ drm_connector_list_iter_next(struct
> drm_connector_list_iter *iter)
>
> return iter->conn;
> }
> +
> +/**
> + * drm_connector_list_iter_next - return next connector
> + * @iter: connector_list iterator
> + *
> + * Returns: the next connector for @iter, or NULL when the list walk has
> + * completed.
> + */
> +struct drm_connector *
> +drm_connector_list_iter_next(struct drm_connector_list_iter *iter)
> +{
> + struct drm_connector *connector;
> +
> + while ((connector = __drm_connector_list_iter_next(iter)) &&
> +iter->filter && !iter->filter(connector, iter->filter_context))
> + ;
> +
> + return connector;
> +}
> EXPORT_SYMBOL(drm_connector_list_iter_next);
>
> /**
> diff --git a/include/drm/drm_connector.h b/include/drm/drm_connector.h
> index 56aee949c6fa..497b98197d3a 100644
> --- a/include/drm/drm_connector.h
> +++ b/include/drm/drm_connector.h
> @@ -1868,6 +1868,9 @@ struct drm_tile_group *drm_mode_get_tile_group(struct
> drm_device *dev,
> void drm_mode_put_tile_group(struct drm_device *dev,
>struct drm_tile_group *tg);
>
> +typedef bool (*drm_connector_list_iter_filter_fn)(const struct drm_connector
> *connector,
> +
Re: [Intel-gfx] [PATCH] gpu: move from strlcpy with unused retval to strscpy
Hi Wolfram,
Thank you for the patch.
On Thu, Aug 18, 2022 at 11:00:07PM +0200, Wolfram Sang wrote:
> Follow the advice of the below link and prefer 'strscpy' in this
> subsystem. Conversion is 1:1 because the return value is not used.
> Generated by a coccinelle script.
>
> Link:
> https://lore.kernel.org/r/CAHk-=wgfRnXz0W3D37d01q3JFkr_i_uTL=v6a6g1ouzcprm...@mail.gmail.com/
> Signed-off-by: Wolfram Sang
Reviewed-by: Laurent Pinchart
> ---
> drivers/gpu/drm/amd/amdgpu/atom.c | 2 +-
> drivers/gpu/drm/amd/pm/legacy-dpm/legacy_dpm.c | 2 +-
> drivers/gpu/drm/bridge/synopsys/dw-hdmi-ahb-audio.c | 6 +++---
> drivers/gpu/drm/bridge/synopsys/dw-hdmi.c | 2 +-
> drivers/gpu/drm/display/drm_dp_helper.c | 2 +-
> drivers/gpu/drm/display/drm_dp_mst_topology.c | 2 +-
> drivers/gpu/drm/drm_mipi_dsi.c | 2 +-
> drivers/gpu/drm/i2c/tda998x_drv.c | 2 +-
> drivers/gpu/drm/i915/selftests/i915_perf.c | 2 +-
> drivers/gpu/drm/mediatek/mtk_hdmi_ddc.c | 2 +-
> drivers/gpu/drm/radeon/radeon_atombios.c| 4 ++--
> drivers/gpu/drm/radeon/radeon_combios.c | 4 ++--
> drivers/gpu/drm/rockchip/inno_hdmi.c| 2 +-
> drivers/gpu/drm/rockchip/rk3066_hdmi.c | 2 +-
> drivers/gpu/drm/sun4i/sun4i_hdmi_i2c.c | 2 +-
> 15 files changed, 19 insertions(+), 19 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/atom.c
> b/drivers/gpu/drm/amd/amdgpu/atom.c
> index 1c5d9388ad0b..5f610e9a5f0f 100644
> --- a/drivers/gpu/drm/amd/amdgpu/atom.c
> +++ b/drivers/gpu/drm/amd/amdgpu/atom.c
> @@ -1509,7 +1509,7 @@ struct atom_context *amdgpu_atom_parse(struct card_info
> *card, void *bios)
> str = CSTR(idx);
> if (*str != '\0') {
> pr_info("ATOM BIOS: %s\n", str);
> - strlcpy(ctx->vbios_version, str, sizeof(ctx->vbios_version));
> + strscpy(ctx->vbios_version, str, sizeof(ctx->vbios_version));
> }
>
> atom_rom_header = (struct _ATOM_ROM_HEADER *)CSTR(base);
> diff --git a/drivers/gpu/drm/amd/pm/legacy-dpm/legacy_dpm.c
> b/drivers/gpu/drm/amd/pm/legacy-dpm/legacy_dpm.c
> index d3fe149d8476..81fb4e5dd804 100644
> --- a/drivers/gpu/drm/amd/pm/legacy-dpm/legacy_dpm.c
> +++ b/drivers/gpu/drm/amd/pm/legacy-dpm/legacy_dpm.c
> @@ -794,7 +794,7 @@ void amdgpu_add_thermal_controller(struct amdgpu_device
> *adev)
> struct i2c_board_info info = { };
> const char *name =
> pp_lib_thermal_controller_names[controller->ucType];
> info.addr = controller->ucI2cAddress >> 1;
> - strlcpy(info.type, name, sizeof(info.type));
> + strscpy(info.type, name, sizeof(info.type));
>
> i2c_new_client_device(>pm.i2c_bus->adapter, );
> }
> } else {
> diff --git a/drivers/gpu/drm/bridge/synopsys/dw-hdmi-ahb-audio.c
> b/drivers/gpu/drm/bridge/synopsys/dw-hdmi-ahb-audio.c
> index 7d2ed0ed2fe2..4efb62bcdb63 100644
> --- a/drivers/gpu/drm/bridge/synopsys/dw-hdmi-ahb-audio.c
> +++ b/drivers/gpu/drm/bridge/synopsys/dw-hdmi-ahb-audio.c
> @@ -542,8 +542,8 @@ static int snd_dw_hdmi_probe(struct platform_device *pdev)
> if (ret < 0)
> return ret;
>
> - strlcpy(card->driver, DRIVER_NAME, sizeof(card->driver));
> - strlcpy(card->shortname, "DW-HDMI", sizeof(card->shortname));
> + strscpy(card->driver, DRIVER_NAME, sizeof(card->driver));
> + strscpy(card->shortname, "DW-HDMI", sizeof(card->shortname));
> snprintf(card->longname, sizeof(card->longname),
>"%s rev 0x%02x, irq %d", card->shortname, revision,
>data->irq);
> @@ -561,7 +561,7 @@ static int snd_dw_hdmi_probe(struct platform_device *pdev)
>
> dw->pcm = pcm;
> pcm->private_data = dw;
> - strlcpy(pcm->name, DRIVER_NAME, sizeof(pcm->name));
> + strscpy(pcm->name, DRIVER_NAME, sizeof(pcm->name));
> snd_pcm_set_ops(pcm, SNDRV_PCM_STREAM_PLAYBACK, _dw_hdmi_ops);
>
> /*
> diff --git a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
> b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
> index 25a60eb4d67c..4f3ae976e677 100644
> --- a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
> +++ b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
> @@ -533,7 +533,7 @@ static struct i2c_adapter *dw_hdmi_i2c_adapter(struct
> dw_hdmi *hdmi)
> adap->owner = THIS_MODULE;
> adap->dev.parent =
Re: [Intel-gfx] [RFC PATCH 0/3] i915 writeback private framework
Hi Suraj, On Thu, Apr 28, 2022 at 05:51:47AM +, Kandpal, Suraj wrote: > ++Laurent ,Dmitry, and Abhinav > > Hi, > Can you have a look at the private implementation i915 is currently going > with till > we can figure out how to work with drm core . No, sorry, I barely have time to follow up on core DRM changes, I can't help with private i915 topics in my spare time. > > A patch series was floated in the drm mailing list which aimed to change the > > drm_connector and drm_encoder fields to pointer in the > > drm_connector_writeback structure, this received a huge pushback from the > > community but since i915 expects each connector present in the drm_device > > list to be a intel_connector but drm_writeback framework. > > [1] https://patchwork.kernel.org/project/dri- > > devel/patch/20220202081702.22119-1-suraj.kand...@intel.com/ > > [2] https://patchwork.kernel.org/project/dri- > > devel/patch/20220202085429.22261-6-suraj.kand...@intel.com/ > > This forces us to use a drm_connector which is not embedded in > > intel_connector the current drm_writeback framework becomes very > > unfeasible to us as it would mean a lot of checks at a lot of places to > > take into > > account the above issue.Since no one had an issue with encoder field being > > changed into a pointer it was decided to break the connector and encoder > > pointer changes into two different series.The encoder field changes is > > currently being worked upon by Abhinav Kumar > > [3]https://patchwork.kernel.org/project/dri-devel/list/?series=633565 > > In the meantime for i915 to start using the writeback functionality we came > > up with a interim solution to own writeback pipeline bypassing one provided > > by drm which is what these patches do. > > Note: these are temp patches till we figure out how we can either change > > drm core writeback to work with our intel_connector structure or find a > > different solution which allows us to work with the current drm_writeback > > framework > > > > Suraj Kandpal (3): > > drm/i915: Creating writeback pipeline to bypass drm_writeback > > framework > > drm/i915: Define WD trancoder for i915 > > drm/i915: Enabling WD Transcoder > > > > drivers/gpu/drm/i915/Makefile | 2 + > > drivers/gpu/drm/i915/display/intel_acpi.c | 1 + > > drivers/gpu/drm/i915/display/intel_display.c | 89 +- > > drivers/gpu/drm/i915/display/intel_display.h | 15 + > > .../drm/i915/display/intel_display_types.h| 18 + > > drivers/gpu/drm/i915/display/intel_dpll.c | 3 + > > drivers/gpu/drm/i915/display/intel_opregion.c | 3 + > > .../gpu/drm/i915/display/intel_wb_connector.c | 296 ++ > > .../gpu/drm/i915/display/intel_wb_connector.h | 99 ++ > > drivers/gpu/drm/i915/display/intel_wd.c | 978 ++ > > drivers/gpu/drm/i915/display/intel_wd.h | 82 ++ > > drivers/gpu/drm/i915/i915_drv.h | 5 + > > drivers/gpu/drm/i915/i915_irq.c | 8 +- > > drivers/gpu/drm/i915/i915_pci.c | 7 +- > > drivers/gpu/drm/i915/i915_reg.h | 139 +++ > > 15 files changed, 1742 insertions(+), 3 deletions(-) create mode 100644 > > drivers/gpu/drm/i915/display/intel_wb_connector.c > > create mode 100644 drivers/gpu/drm/i915/display/intel_wb_connector.h > > create mode 100644 drivers/gpu/drm/i915/display/intel_wd.c > > create mode 100644 drivers/gpu/drm/i915/display/intel_wd.h -- Regards, Laurent Pinchart
Re: [Intel-gfx] [PATCH 5/6] drm/rcar_du: changes to rcar-du driver resulting from drm_writeback_connector structure changes
Hi Abhinav,
On Wed, Mar 02, 2022 at 10:28:03AM -0800, Abhinav Kumar wrote:
> On 2/28/2022 5:42 AM, Laurent Pinchart wrote:
> > On Mon, Feb 28, 2022 at 02:28:27PM +0200, Laurent Pinchart wrote:
> >> On Mon, Feb 28, 2022 at 02:09:15PM +0200, Jani Nikula wrote:
> >>> On Mon, 28 Feb 2022, Laurent Pinchart wrote:
> >>>> On Sat, Feb 26, 2022 at 10:27:59AM -0800, Rob Clark wrote:
> >>>>> On Wed, Feb 2, 2022 at 7:41 AM Jani Nikula wrote:
> >>>>>> On Wed, 02 Feb 2022, Laurent Pinchart wrote:
> >>>>>>> On Wed, Feb 02, 2022 at 03:15:03PM +0200, Jani Nikula wrote:
> >>>>>>>> On Wed, 02 Feb 2022, Laurent Pinchart wrote:
> >>>>>>>>> On Wed, Feb 02, 2022 at 02:24:28PM +0530, Kandpal Suraj wrote:
> >>>>>>>>>> Changing rcar_du driver to accomadate the change of
> >>>>>>>>>> drm_writeback_connector.base and drm_writeback_connector.encoder
> >>>>>>>>>> to a pointer the reason for which is explained in the
> >>>>>>>>>> Patch(drm: add writeback pointers to drm_connector).
> >>>>>>>>>>
> >>>>>>>>>> Signed-off-by: Kandpal Suraj
> >>>>>>>>>> ---
> >>>>>>>>>> drivers/gpu/drm/rcar-du/rcar_du_crtc.h | 2 ++
> >>>>>>>>>> drivers/gpu/drm/rcar-du/rcar_du_writeback.c | 8 +---
> >>>>>>>>>> 2 files changed, 7 insertions(+), 3 deletions(-)
> >>>>>>>>>>
> >>>>>>>>>> diff --git a/drivers/gpu/drm/rcar-du/rcar_du_crtc.h
> >>>>>>>>>> b/drivers/gpu/drm/rcar-du/rcar_du_crtc.h
> >>>>>>>>>> index 66e8839db708..68f387a04502 100644
> >>>>>>>>>> --- a/drivers/gpu/drm/rcar-du/rcar_du_crtc.h
> >>>>>>>>>> +++ b/drivers/gpu/drm/rcar-du/rcar_du_crtc.h
> >>>>>>>>>> @@ -72,6 +72,8 @@ struct rcar_du_crtc {
> >>>>>>>>>>const char *const *sources;
> >>>>>>>>>>unsigned int sources_count;
> >>>>>>>>>>
> >>>>>>>>>> + struct drm_connector connector;
> >>>>>>>>>> + struct drm_encoder encoder;
> >>>>>>>>>
> >>>>>>>>> Those fields are, at best, poorly named. Furthermore, there's no
> >>>>>>>>> need in
> >>>>>>>>> this driver or in other drivers using drm_writeback_connector to
> >>>>>>>>> create
> >>>>>>>>> an encoder or connector manually. Let's not polute all drivers
> >>>>>>>>> because
> >>>>>>>>> i915 doesn't have its abstractions right.
> >>>>>>>>
> >>>>>>>> i915 uses the quite common model for struct inheritance:
> >>>>>>>>
> >>>>>>>> struct intel_connector {
> >>>>>>>> struct drm_connector base;
> >>>>>>>> /* ... */
> >>>>>>>> }
> >>>>>>>>
> >>>>>>>> Same with at least amd, ast, fsl-dcu, hisilicon, mga200, msm,
> >>>>>>>> nouveau,
> >>>>>>>> radeon, tilcdc, and vboxvideo.
> >>>>>>>>
> >>>>>>>> We could argue about the relative merits of that abstraction, but I
> >>>>>>>> think the bottom line is that it's popular and the drivers using it
> >>>>>>>> are
> >>>>>>>> not going to be persuaded to move away from it.
> >>>>>>>
> >>>>>>> Nobody said inheritance is bad.
> >>>>>>>
> >>>>>>>> It's no coincidence that the drivers who've implemented writeback so
> >>>>>>>> far
> >>>>>>>> (komeda, mali, rcar-du, vc4, and vkms) do not use the abstraction,
> >>>>>>>> because the drm_writeback_connector midlayer does, forcing the issue.
> >>>>>>>
> >>>>>>> Are you sure it's not a coincidence ? :-)
> >>>>>>>
> >
Re: [Intel-gfx] [PATCH 5/6] drm/rcar_du: changes to rcar-du driver resulting from drm_writeback_connector structure changes
Hello,
On Mon, Feb 28, 2022 at 02:28:27PM +0200, Laurent Pinchart wrote:
> On Mon, Feb 28, 2022 at 02:09:15PM +0200, Jani Nikula wrote:
> > On Mon, 28 Feb 2022, Laurent Pinchart wrote:
> > > On Sat, Feb 26, 2022 at 10:27:59AM -0800, Rob Clark wrote:
> > >> On Wed, Feb 2, 2022 at 7:41 AM Jani Nikula wrote:
> > >> > On Wed, 02 Feb 2022, Laurent Pinchart wrote:
> > >> > > On Wed, Feb 02, 2022 at 03:15:03PM +0200, Jani Nikula wrote:
> > >> > >> On Wed, 02 Feb 2022, Laurent Pinchart wrote:
> > >> > >> > On Wed, Feb 02, 2022 at 02:24:28PM +0530, Kandpal Suraj wrote:
> > >> > >> >> Changing rcar_du driver to accomadate the change of
> > >> > >> >> drm_writeback_connector.base and drm_writeback_connector.encoder
> > >> > >> >> to a pointer the reason for which is explained in the
> > >> > >> >> Patch(drm: add writeback pointers to drm_connector).
> > >> > >> >>
> > >> > >> >> Signed-off-by: Kandpal Suraj
> > >> > >> >> ---
> > >> > >> >> drivers/gpu/drm/rcar-du/rcar_du_crtc.h | 2 ++
> > >> > >> >> drivers/gpu/drm/rcar-du/rcar_du_writeback.c | 8 +---
> > >> > >> >> 2 files changed, 7 insertions(+), 3 deletions(-)
> > >> > >> >>
> > >> > >> >> diff --git a/drivers/gpu/drm/rcar-du/rcar_du_crtc.h
> > >> > >> >> b/drivers/gpu/drm/rcar-du/rcar_du_crtc.h
> > >> > >> >> index 66e8839db708..68f387a04502 100644
> > >> > >> >> --- a/drivers/gpu/drm/rcar-du/rcar_du_crtc.h
> > >> > >> >> +++ b/drivers/gpu/drm/rcar-du/rcar_du_crtc.h
> > >> > >> >> @@ -72,6 +72,8 @@ struct rcar_du_crtc {
> > >> > >> >> const char *const *sources;
> > >> > >> >> unsigned int sources_count;
> > >> > >> >>
> > >> > >> >> + struct drm_connector connector;
> > >> > >> >> + struct drm_encoder encoder;
> > >> > >> >
> > >> > >> > Those fields are, at best, poorly named. Furthermore, there's no
> > >> > >> > need in
> > >> > >> > this driver or in other drivers using drm_writeback_connector to
> > >> > >> > create
> > >> > >> > an encoder or connector manually. Let's not polute all drivers
> > >> > >> > because
> > >> > >> > i915 doesn't have its abstractions right.
> > >> > >>
> > >> > >> i915 uses the quite common model for struct inheritance:
> > >> > >>
> > >> > >> struct intel_connector {
> > >> > >> struct drm_connector base;
> > >> > >> /* ... */
> > >> > >> }
> > >> > >>
> > >> > >> Same with at least amd, ast, fsl-dcu, hisilicon, mga200, msm,
> > >> > >> nouveau,
> > >> > >> radeon, tilcdc, and vboxvideo.
> > >> > >>
> > >> > >> We could argue about the relative merits of that abstraction, but I
> > >> > >> think the bottom line is that it's popular and the drivers using it
> > >> > >> are
> > >> > >> not going to be persuaded to move away from it.
> > >> > >
> > >> > > Nobody said inheritance is bad.
> > >> > >
> > >> > >> It's no coincidence that the drivers who've implemented writeback
> > >> > >> so far
> > >> > >> (komeda, mali, rcar-du, vc4, and vkms) do not use the abstraction,
> > >> > >> because the drm_writeback_connector midlayer does, forcing the
> > >> > >> issue.
> > >> > >
> > >> > > Are you sure it's not a coincidence ? :-)
> > >> > >
> > >> > > The encoder and especially connector created by
> > >> > > drm_writeback_connector
> > >> > > are there only because KMS requires a drm_encoder and a
> > >> > > drm_connector to
> > >> > > be exposed to userspace (and I could argue that using a connector for
> > >> > > writeback is a hack, but that wo
Re: [Intel-gfx] [PATCH 5/6] drm/rcar_du: changes to rcar-du driver resulting from drm_writeback_connector structure changes
Hi Jani,
On Mon, Feb 28, 2022 at 02:09:15PM +0200, Jani Nikula wrote:
> On Mon, 28 Feb 2022, Laurent Pinchart wrote:
> > On Sat, Feb 26, 2022 at 10:27:59AM -0800, Rob Clark wrote:
> >> On Wed, Feb 2, 2022 at 7:41 AM Jani Nikula wrote:
> >> > On Wed, 02 Feb 2022, Laurent Pinchart wrote:
> >> > > On Wed, Feb 02, 2022 at 03:15:03PM +0200, Jani Nikula wrote:
> >> > >> On Wed, 02 Feb 2022, Laurent Pinchart wrote:
> >> > >> > On Wed, Feb 02, 2022 at 02:24:28PM +0530, Kandpal Suraj wrote:
> >> > >> >> Changing rcar_du driver to accomadate the change of
> >> > >> >> drm_writeback_connector.base and drm_writeback_connector.encoder
> >> > >> >> to a pointer the reason for which is explained in the
> >> > >> >> Patch(drm: add writeback pointers to drm_connector).
> >> > >> >>
> >> > >> >> Signed-off-by: Kandpal Suraj
> >> > >> >> ---
> >> > >> >> drivers/gpu/drm/rcar-du/rcar_du_crtc.h | 2 ++
> >> > >> >> drivers/gpu/drm/rcar-du/rcar_du_writeback.c | 8 +---
> >> > >> >> 2 files changed, 7 insertions(+), 3 deletions(-)
> >> > >> >>
> >> > >> >> diff --git a/drivers/gpu/drm/rcar-du/rcar_du_crtc.h
> >> > >> >> b/drivers/gpu/drm/rcar-du/rcar_du_crtc.h
> >> > >> >> index 66e8839db708..68f387a04502 100644
> >> > >> >> --- a/drivers/gpu/drm/rcar-du/rcar_du_crtc.h
> >> > >> >> +++ b/drivers/gpu/drm/rcar-du/rcar_du_crtc.h
> >> > >> >> @@ -72,6 +72,8 @@ struct rcar_du_crtc {
> >> > >> >> const char *const *sources;
> >> > >> >> unsigned int sources_count;
> >> > >> >>
> >> > >> >> + struct drm_connector connector;
> >> > >> >> + struct drm_encoder encoder;
> >> > >> >
> >> > >> > Those fields are, at best, poorly named. Furthermore, there's no
> >> > >> > need in
> >> > >> > this driver or in other drivers using drm_writeback_connector to
> >> > >> > create
> >> > >> > an encoder or connector manually. Let's not polute all drivers
> >> > >> > because
> >> > >> > i915 doesn't have its abstractions right.
> >> > >>
> >> > >> i915 uses the quite common model for struct inheritance:
> >> > >>
> >> > >> struct intel_connector {
> >> > >> struct drm_connector base;
> >> > >> /* ... */
> >> > >> }
> >> > >>
> >> > >> Same with at least amd, ast, fsl-dcu, hisilicon, mga200, msm, nouveau,
> >> > >> radeon, tilcdc, and vboxvideo.
> >> > >>
> >> > >> We could argue about the relative merits of that abstraction, but I
> >> > >> think the bottom line is that it's popular and the drivers using it
> >> > >> are
> >> > >> not going to be persuaded to move away from it.
> >> > >
> >> > > Nobody said inheritance is bad.
> >> > >
> >> > >> It's no coincidence that the drivers who've implemented writeback so
> >> > >> far
> >> > >> (komeda, mali, rcar-du, vc4, and vkms) do not use the abstraction,
> >> > >> because the drm_writeback_connector midlayer does, forcing the issue.
> >> > >
> >> > > Are you sure it's not a coincidence ? :-)
> >> > >
> >> > > The encoder and especially connector created by drm_writeback_connector
> >> > > are there only because KMS requires a drm_encoder and a drm_connector
> >> > > to
> >> > > be exposed to userspace (and I could argue that using a connector for
> >> > > writeback is a hack, but that won't change). The connector is
> >> > > "virtual",
> >> > > I still fail to see why i915 or any other driver would need to wrap it
> >> > > into something else. The whole point of the drm_writeback_connector
> >> > > abstraction is that drivers do not have to manage the writeback
> >> > > drm_connector manually, they shouldn't touch it at all.
> >> >
> >> > The thing is, drm_writeback_connecto
Re: [Intel-gfx] [PATCH 5/6] drm/rcar_du: changes to rcar-du driver resulting from drm_writeback_connector structure changes
Hi Dmitry, On Mon, Feb 28, 2022 at 11:07:41AM +0300, Dmitry Baryshkov wrote: > On Mon, 28 Feb 2022 at 11:00, Laurent Pinchart wrote: > > On Sat, Feb 26, 2022 at 05:10:06AM +, Kandpal, Suraj wrote: > > > Hi Abhinav, > > > > > > > Based on the discussion in this thread [1] , it seems like having > > > > drm_encoder > > > > as a pointer seems to have merits for both of us and also in agreement > > > > with > > > > the folks on this thread and has a better chance of an ack. > > > > > > > > However drm_connector is not. > > > > > > > > I had a brief look at your implementation. Any reason you need to go > > > > through intel_connector here and not drm_writeback_connector directly? > > > > > > > > The reason I ask is that I see you are not using prepare_writeback_job > > > > hook. > > > > If you use that, you can use the drm_writeback_connector passed on from > > > > there instead of looping through your list like you are doing in > > > > intel_find_writeback_connector. > > > > > > > > Also, none of the other entries of struct intel_connector are being > > > > used for > > > > the writeback implementation. So does the drm_writeback_connector in > > > > your implementation need to be an intel_connector when its anyway not > > > > using other fields? Why cant it be just stored as a > > > > drm_writeback_connector > > > > itself in your struct intel_wd. > > > > > > The reason we can't do that is i915 driver always assumes that all > > > connectors > > > present in device list is an intel connector and since > > > drm_writeback_connector > > > even though a faux connector in it's initialization calls > > > drm_connector_init() > > > and gets added to the drm device list and hence the i915 driver also > > > expects > > > a corresponding intel connector to go with it. In case I do try to make > > > writeback > > > connector standalone a lot of checks, a lot will have to be added all > > > around the > > > driver as there could be a chance that one of the drm_connector in the > > > drm device > > > list may not be an intel_connector. > > > Yes right now not all fields of intel_connector are being used but we > > > will be working > > > on filling them as we add more functionality to writeback for example > > > introducing > > > content protection. > > > So even if I do float the patch series with just drm_encoder as pointer > > > it won't help > > > us with our implementation if drm_connector isn't a pointer too. > > > > This is a direct consequence of the decision to use connectors for > > writeback in the userspace API. This disrupts any code that assumes that > > a connector is a connector. The problem isn't limited to kernelspace, > > userspace has the same exact problem, which resulted in a hack to avoid > > breaking everything. Userspace software that needs to deal with > > writeback needs to set the DRM_CLIENT_CAP_WRITEBACK_CONNECTORS > > capability to get the writeback connectors exposed by the kernel, but > > more than that, a large refactoring is then often needed to chase all > > code paths that assume a connector is a connector. > > > > I'm afraid the same applies to the kernel. Drivers that don't use > > writeback are largely unaffected. Drievrs that want to use writeback > > need to be refactored to properly handle the fact that writeback > > connectors are special. i915 will need to go that way. > > Laurent, you have frown upon the idea of separating the connector from > the drm_writeback_connector struct. What about the encoder? > The msm code in question can be found at the patchwork: > https://patchwork.freedesktop.org/series/99724/. This series depends > on Intel's patch, but should give you the overall feeling of the code > being shared between to-the-display and writeback pipelines. I'm not too fond of separating the encoder either as explained separately in this mail thread, but I won't block that as it's even more difficult to avoid today. drm_encoder is a bit of a historical mistake that we need to keep around because it's exposed to userspace. With drivers more and more reliant on drm_bridge, drm_encoder is less meaningful than it used to be. I would like to see the subsystem continuing in that direction, with drm_encoder becoming an empty shell. Drivers should decouple the CRTC outputs from the drm_encoder object, likely creating driver-specific structures to model a CRTC output (which is largely what the driver-specific subclasses of drm_encoder do today), and create drm_encoder instances only for the purpose of exposing the display topology to userspace. Longer term I can even imagine having a different way to expose the display topology to userspace, without drm_encoder but with objects that will be allowed to support more complex topologies that the CRTC + encoder + connector abstraction can't model. Later :-) -- Regards, Laurent Pinchart
Re: [Intel-gfx] [PATCH 5/6] drm/rcar_du: changes to rcar-du driver resulting from drm_writeback_connector structure changes
Hi Rob,
On Sat, Feb 26, 2022 at 10:27:59AM -0800, Rob Clark wrote:
> On Wed, Feb 2, 2022 at 7:41 AM Jani Nikula wrote:
> > On Wed, 02 Feb 2022, Laurent Pinchart wrote:
> > > On Wed, Feb 02, 2022 at 03:15:03PM +0200, Jani Nikula wrote:
> > >> On Wed, 02 Feb 2022, Laurent Pinchart wrote:
> > >> > On Wed, Feb 02, 2022 at 02:24:28PM +0530, Kandpal Suraj wrote:
> > >> >> Changing rcar_du driver to accomadate the change of
> > >> >> drm_writeback_connector.base and drm_writeback_connector.encoder
> > >> >> to a pointer the reason for which is explained in the
> > >> >> Patch(drm: add writeback pointers to drm_connector).
> > >> >>
> > >> >> Signed-off-by: Kandpal Suraj
> > >> >> ---
> > >> >> drivers/gpu/drm/rcar-du/rcar_du_crtc.h | 2 ++
> > >> >> drivers/gpu/drm/rcar-du/rcar_du_writeback.c | 8 +---
> > >> >> 2 files changed, 7 insertions(+), 3 deletions(-)
> > >> >>
> > >> >> diff --git a/drivers/gpu/drm/rcar-du/rcar_du_crtc.h
> > >> >> b/drivers/gpu/drm/rcar-du/rcar_du_crtc.h
> > >> >> index 66e8839db708..68f387a04502 100644
> > >> >> --- a/drivers/gpu/drm/rcar-du/rcar_du_crtc.h
> > >> >> +++ b/drivers/gpu/drm/rcar-du/rcar_du_crtc.h
> > >> >> @@ -72,6 +72,8 @@ struct rcar_du_crtc {
> > >> >> const char *const *sources;
> > >> >> unsigned int sources_count;
> > >> >>
> > >> >> + struct drm_connector connector;
> > >> >> + struct drm_encoder encoder;
> > >> >
> > >> > Those fields are, at best, poorly named. Furthermore, there's no need
> > >> > in
> > >> > this driver or in other drivers using drm_writeback_connector to create
> > >> > an encoder or connector manually. Let's not polute all drivers because
> > >> > i915 doesn't have its abstractions right.
> > >>
> > >> i915 uses the quite common model for struct inheritance:
> > >>
> > >> struct intel_connector {
> > >> struct drm_connector base;
> > >> /* ... */
> > >> }
> > >>
> > >> Same with at least amd, ast, fsl-dcu, hisilicon, mga200, msm, nouveau,
> > >> radeon, tilcdc, and vboxvideo.
> > >>
> > >> We could argue about the relative merits of that abstraction, but I
> > >> think the bottom line is that it's popular and the drivers using it are
> > >> not going to be persuaded to move away from it.
> > >
> > > Nobody said inheritance is bad.
> > >
> > >> It's no coincidence that the drivers who've implemented writeback so far
> > >> (komeda, mali, rcar-du, vc4, and vkms) do not use the abstraction,
> > >> because the drm_writeback_connector midlayer does, forcing the issue.
> > >
> > > Are you sure it's not a coincidence ? :-)
> > >
> > > The encoder and especially connector created by drm_writeback_connector
> > > are there only because KMS requires a drm_encoder and a drm_connector to
> > > be exposed to userspace (and I could argue that using a connector for
> > > writeback is a hack, but that won't change). The connector is "virtual",
> > > I still fail to see why i915 or any other driver would need to wrap it
> > > into something else. The whole point of the drm_writeback_connector
> > > abstraction is that drivers do not have to manage the writeback
> > > drm_connector manually, they shouldn't touch it at all.
> >
> > The thing is, drm_writeback_connector_init() calling
> > drm_connector_init() on the drm_connector embedded in
> > drm_writeback_connector leads to that connector being added to the
> > drm_device's list of connectors. Ditto for the encoder.
> >
> > All the driver code that handles drm_connectors would need to take into
> > account they might not be embedded in intel_connector. Throughout the
> > driver. Ditto for the encoders.
>
> The assumption that a connector is embedded in intel_connector doesn't
> really play that well with how bridge and panel connectors work.. so
> in general this seems like a good thing to unwind.
>
> But as a point of practicality, i915 is a large driver covering a lot
> of generations of hw with a lot of users. So I can understand
> changing this design isn't something that can happen quickly or
> easily. IMO we should allow i915 to create it's own connector for
> writeback, and just document clearly that this isn't the approach new
> drivers should take. I mean, I understand idealism, but sometimes a
> dose of pragmatism is needed. :-)
i915 is big, but so is Intel. It's not fair to treat everybody else as a
second class citizen and let Intel get away without doing its homework.
I want to see this refactoring effort moving forward in i915 (and moving
to drm_bridge would then be a good idea too). If writeback support in
i915 urgent, then we can discuss *temporary* pragmatic stopgap measures,
but not without a real effort to fix the core issue.
> > The point is, you can't initialize a connector or an encoder for a
> > drm_device in isolation of the rest of the driver, even if it were
> > supposed to be hidden away.
--
Regards,
Laurent Pinchart
Re: [Intel-gfx] [PATCH 5/6] drm/rcar_du: changes to rcar-du driver resulting from drm_writeback_connector structure changes
Hi Suraj, On Sat, Feb 26, 2022 at 05:10:06AM +, Kandpal, Suraj wrote: > Hi Abhinav, > > > Based on the discussion in this thread [1] , it seems like having > > drm_encoder > > as a pointer seems to have merits for both of us and also in agreement with > > the folks on this thread and has a better chance of an ack. > > > > However drm_connector is not. > > > > I had a brief look at your implementation. Any reason you need to go > > through intel_connector here and not drm_writeback_connector directly? > > > > The reason I ask is that I see you are not using prepare_writeback_job hook. > > If you use that, you can use the drm_writeback_connector passed on from > > there instead of looping through your list like you are doing in > > intel_find_writeback_connector. > > > > Also, none of the other entries of struct intel_connector are being used for > > the writeback implementation. So does the drm_writeback_connector in > > your implementation need to be an intel_connector when its anyway not > > using other fields? Why cant it be just stored as a drm_writeback_connector > > itself in your struct intel_wd. > > The reason we can't do that is i915 driver always assumes that all connectors > present in device list is an intel connector and since drm_writeback_connector > even though a faux connector in it's initialization calls drm_connector_init() > and gets added to the drm device list and hence the i915 driver also expects > a corresponding intel connector to go with it. In case I do try to make > writeback > connector standalone a lot of checks, a lot will have to be added all around > the > driver as there could be a chance that one of the drm_connector in the drm > device > list may not be an intel_connector. > Yes right now not all fields of intel_connector are being used but we will be > working > on filling them as we add more functionality to writeback for example > introducing > content protection. > So even if I do float the patch series with just drm_encoder as pointer it > won't help > us with our implementation if drm_connector isn't a pointer too. This is a direct consequence of the decision to use connectors for writeback in the userspace API. This disrupts any code that assumes that a connector is a connector. The problem isn't limited to kernelspace, userspace has the same exact problem, which resulted in a hack to avoid breaking everything. Userspace software that needs to deal with writeback needs to set the DRM_CLIENT_CAP_WRITEBACK_CONNECTORS capability to get the writeback connectors exposed by the kernel, but more than that, a large refactoring is then often needed to chase all code paths that assume a connector is a connector. I'm afraid the same applies to the kernel. Drivers that don't use writeback are largely unaffected. Drievrs that want to use writeback need to be refactored to properly handle the fact that writeback connectors are special. i915 will need to go that way. -- Regards, Laurent Pinchart
Re: [Intel-gfx] [PATCH 5/6] drm/rcar_du: changes to rcar-du driver resulting from drm_writeback_connector structure changes
Hi Dmitry,
On Tue, Feb 22, 2022 at 06:32:50AM +0300, Dmitry Baryshkov wrote:
> On Thu, 10 Feb 2022 at 07:59, Laurent Pinchart wrote:
> > On Wed, Feb 09, 2022 at 05:40:29PM -0800, Abhinav Kumar wrote:
> > > Hi Laurent
> > >
> > > Gentle reminder on this.
> >
> > I won't have time before next week I'm afraid.
>
> Laurent, another gentle ping.
I'm really late on this so I probably deserve a bit of a rougher ping,
but thanks for being gentle :-)
> > > On 2/6/2022 11:20 PM, Abhinav Kumar wrote:
> > > > On 2/6/2022 3:32 PM, Dmitry Baryshkov wrote:
> > > >> On Wed, 2 Feb 2022 at 16:26, Laurent Pinchart wrote:
> > > >>> On Wed, Feb 02, 2022 at 03:15:03PM +0200, Jani Nikula wrote:
> > > >>>> On Wed, 02 Feb 2022, Laurent Pinchart wrote:
> > > >>>>> On Wed, Feb 02, 2022 at 02:24:28PM +0530, Kandpal Suraj wrote:
> > > >>>>>> Changing rcar_du driver to accomadate the change of
> > > >>>>>> drm_writeback_connector.base and drm_writeback_connector.encoder
> > > >>>>>> to a pointer the reason for which is explained in the
> > > >>>>>> Patch(drm: add writeback pointers to drm_connector).
> > > >>>>>>
> > > >>>>>> Signed-off-by: Kandpal Suraj
> > > >>>>>> ---
> > > >>>>>> drivers/gpu/drm/rcar-du/rcar_du_crtc.h | 2 ++
> > > >>>>>> drivers/gpu/drm/rcar-du/rcar_du_writeback.c | 8 +---
> > > >>>>>> 2 files changed, 7 insertions(+), 3 deletions(-)
> > > >>>>>>
> > > >>>>>> diff --git a/drivers/gpu/drm/rcar-du/rcar_du_crtc.h
> > > >>>>>> b/drivers/gpu/drm/rcar-du/rcar_du_crtc.h
> > > >>>>>> index 66e8839db708..68f387a04502 100644
> > > >>>>>> --- a/drivers/gpu/drm/rcar-du/rcar_du_crtc.h
> > > >>>>>> +++ b/drivers/gpu/drm/rcar-du/rcar_du_crtc.h
> > > >>>>>> @@ -72,6 +72,8 @@ struct rcar_du_crtc {
> > > >>>>>> const char *const *sources;
> > > >>>>>> unsigned int sources_count;
> > > >>>>>>
> > > >>>>>> + struct drm_connector connector;
> > > >>>>>> + struct drm_encoder encoder;
> > > >>>>>
> > > >>>>> Those fields are, at best, poorly named. Furthermore, there's no
> > > >>>>> need in
> > > >>>>> this driver or in other drivers using drm_writeback_connector to
> > > >>>>> create
> > > >>>>> an encoder or connector manually. Let's not polute all drivers
> > > >>>>> because
> > > >>>>> i915 doesn't have its abstractions right.
> > > >>>>
> > > >>>> i915 uses the quite common model for struct inheritance:
> > > >>>>
> > > >>>>struct intel_connector {
> > > >>>>struct drm_connector base;
> > > >>>>/* ... */
> > > >>>>}
> > > >>>>
> > > >>>> Same with at least amd, ast, fsl-dcu, hisilicon, mga200, msm,
> > > >>>> nouveau,
> > > >>>> radeon, tilcdc, and vboxvideo.
> > > >>>>
> > > >>>> We could argue about the relative merits of that abstraction, but I
> > > >>>> think the bottom line is that it's popular and the drivers using it
> > > >>>> are
> > > >>>> not going to be persuaded to move away from it.
> > > >>>
> > > >>> Nobody said inheritance is bad.
> > > >>>
> > > >>>> It's no coincidence that the drivers who've implemented writeback so
> > > >>>> far
> > > >>>> (komeda, mali, rcar-du, vc4, and vkms) do not use the abstraction,
> > > >>>> because the drm_writeback_connector midlayer does, forcing the issue.
> > > >>>
> > > >>> Are you sure it's not a coincidence ? :-)
> > > >>>
> > > >>> The encoder and especially connector created by
> > > >>> drm_writeback_connector
> > > >>> are there only because KMS requires a drm_encoder and a drm_connector
> >
Re: [Intel-gfx] [PATCH 06/22] drm/bridge: Use drm_mode_copy()
Hi Ville,
Thank you for the patch.
On Fri, Feb 18, 2022 at 12:03:47PM +0200, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> struct drm_display_mode embeds a list head, so overwriting
> the full struct with another one will corrupt the list
> (if the destination mode is on a list). Use drm_mode_copy()
> instead which explicitly preserves the list head of
> the destination mode.
>
> Even if we know the destination mode is not on any list
> using drm_mode_copy() seems decent as it sets a good
> example. Bad examples of not using it might eventually
> get copied into code where preserving the list head
> actually matters.
>
> Obviously one case not covered here is when the mode
> itself is embedded in a larger structure and the whole
> structure is copied. But if we are careful when copying
> into modes embedded in structures I think we can be a
> little more reassured that bogus list heads haven't been
> propagated in.
>
> @is_mode_copy@
> @@
> drm_mode_copy(...)
> {
> ...
> }
>
> @depends on !is_mode_copy@
> struct drm_display_mode *mode;
> expression E, S;
> @@
> (
> - *mode = E
> + drm_mode_copy(mode, )
> |
> - memcpy(mode, E, S)
> + drm_mode_copy(mode, E)
> )
>
> @depends on !is_mode_copy@
> struct drm_display_mode mode;
> expression E;
> @@
> (
> - mode = E
> + drm_mode_copy(, )
> |
> - memcpy(, E, S)
> + drm_mode_copy(, E)
> )
>
> @@
> struct drm_display_mode *mode;
> @@
> - &*mode
> + mode
>
> Cc: Andrzej Hajda
> Cc: Neil Armstrong
> Cc: Robert Foss
> Cc: Laurent Pinchart
> Cc: Jonas Karlman
> Cc: Jernej Skrabec
> Signed-off-by: Ville Syrjälä
Reviewed-by: Laurent Pinchart
> ---
> drivers/gpu/drm/bridge/nwl-dsi.c | 2 +-
> drivers/gpu/drm/bridge/synopsys/dw-hdmi.c | 2 +-
> drivers/gpu/drm/bridge/tc358767.c | 2 +-
> 3 files changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/bridge/nwl-dsi.c
> b/drivers/gpu/drm/bridge/nwl-dsi.c
> index 963a6794735f..881cf338d5cf 100644
> --- a/drivers/gpu/drm/bridge/nwl-dsi.c
> +++ b/drivers/gpu/drm/bridge/nwl-dsi.c
> @@ -857,7 +857,7 @@ nwl_dsi_bridge_mode_set(struct drm_bridge *bridge,
> /* Save the new desired phy config */
> memcpy(>phy_cfg, _cfg, sizeof(new_cfg));
>
> - memcpy(>mode, adjusted_mode, sizeof(dsi->mode));
> + drm_mode_copy(>mode, adjusted_mode);
> drm_mode_debug_printmodeline(adjusted_mode);
>
> if (pm_runtime_resume_and_get(dev) < 0)
> diff --git a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
> b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
> index 4befc104d220..a563460f8d20 100644
> --- a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
> +++ b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
> @@ -2830,7 +2830,7 @@ static void dw_hdmi_bridge_mode_set(struct drm_bridge
> *bridge,
> mutex_lock(>mutex);
>
> /* Store the display mode for plugin/DKMS poweron events */
> - memcpy(>previous_mode, mode, sizeof(hdmi->previous_mode));
> + drm_mode_copy(>previous_mode, mode);
>
> mutex_unlock(>mutex);
> }
> diff --git a/drivers/gpu/drm/bridge/tc358767.c
> b/drivers/gpu/drm/bridge/tc358767.c
> index c23e0abc65e8..7f9574b17caa 100644
> --- a/drivers/gpu/drm/bridge/tc358767.c
> +++ b/drivers/gpu/drm/bridge/tc358767.c
> @@ -1312,7 +1312,7 @@ static void tc_bridge_mode_set(struct drm_bridge
> *bridge,
> {
> struct tc_data *tc = bridge_to_tc(bridge);
>
> - tc->mode = *mode;
> + drm_mode_copy(>mode, mode);
> }
>
> static struct edid *tc_get_edid(struct drm_bridge *bridge,
--
Regards,
Laurent Pinchart
Re: [Intel-gfx] [PATCH 5/6] drm/rcar_du: changes to rcar-du driver resulting from drm_writeback_connector structure changes
Hi Abhinav,
On Wed, Feb 09, 2022 at 05:40:29PM -0800, Abhinav Kumar wrote:
> Hi Laurent
>
> Gentle reminder on this.
I won't have time before next week I'm afraid.
> On 2/6/2022 11:20 PM, Abhinav Kumar wrote:
> > Hi Laurent
> >
> > On 2/6/2022 3:32 PM, Dmitry Baryshkov wrote:
> >> On Wed, 2 Feb 2022 at 16:26, Laurent Pinchart
> >> wrote:
> >>>
> >>> Hi Jani,
> >>>
> >>> On Wed, Feb 02, 2022 at 03:15:03PM +0200, Jani Nikula wrote:
> >>>> On Wed, 02 Feb 2022, Laurent Pinchart wrote:
> >>>>> On Wed, Feb 02, 2022 at 02:24:28PM +0530, Kandpal Suraj wrote:
> >>>>>> Changing rcar_du driver to accomadate the change of
> >>>>>> drm_writeback_connector.base and drm_writeback_connector.encoder
> >>>>>> to a pointer the reason for which is explained in the
> >>>>>> Patch(drm: add writeback pointers to drm_connector).
> >>>>>>
> >>>>>> Signed-off-by: Kandpal Suraj
> >>>>>> ---
> >>>>>> drivers/gpu/drm/rcar-du/rcar_du_crtc.h | 2 ++
> >>>>>> drivers/gpu/drm/rcar-du/rcar_du_writeback.c | 8 +---
> >>>>>> 2 files changed, 7 insertions(+), 3 deletions(-)
> >>>>>>
> >>>>>> diff --git a/drivers/gpu/drm/rcar-du/rcar_du_crtc.h
> >>>>>> b/drivers/gpu/drm/rcar-du/rcar_du_crtc.h
> >>>>>> index 66e8839db708..68f387a04502 100644
> >>>>>> --- a/drivers/gpu/drm/rcar-du/rcar_du_crtc.h
> >>>>>> +++ b/drivers/gpu/drm/rcar-du/rcar_du_crtc.h
> >>>>>> @@ -72,6 +72,8 @@ struct rcar_du_crtc {
> >>>>>> const char *const *sources;
> >>>>>> unsigned int sources_count;
> >>>>>>
> >>>>>> + struct drm_connector connector;
> >>>>>> + struct drm_encoder encoder;
> >>>>>
> >>>>> Those fields are, at best, poorly named. Furthermore, there's no
> >>>>> need in
> >>>>> this driver or in other drivers using drm_writeback_connector to
> >>>>> create
> >>>>> an encoder or connector manually. Let's not polute all drivers because
> >>>>> i915 doesn't have its abstractions right.
> >>>>
> >>>> i915 uses the quite common model for struct inheritance:
> >>>>
> >>>> struct intel_connector {
> >>>> struct drm_connector base;
> >>>> /* ... */
> >>>> }
> >>>>
> >>>> Same with at least amd, ast, fsl-dcu, hisilicon, mga200, msm, nouveau,
> >>>> radeon, tilcdc, and vboxvideo.
> >>>>
> >>>> We could argue about the relative merits of that abstraction, but I
> >>>> think the bottom line is that it's popular and the drivers using it are
> >>>> not going to be persuaded to move away from it.
> >>>
> >>> Nobody said inheritance is bad.
> >>>
> >>>> It's no coincidence that the drivers who've implemented writeback so
> >>>> far
> >>>> (komeda, mali, rcar-du, vc4, and vkms) do not use the abstraction,
> >>>> because the drm_writeback_connector midlayer does, forcing the issue.
> >>>
> >>> Are you sure it's not a coincidence ? :-)
> >>>
> >>> The encoder and especially connector created by drm_writeback_connector
> >>> are there only because KMS requires a drm_encoder and a drm_connector to
> >>> be exposed to userspace (and I could argue that using a connector for
> >>> writeback is a hack, but that won't change). The connector is "virtual",
> >>> I still fail to see why i915 or any other driver would need to wrap it
> >>> into something else. The whole point of the drm_writeback_connector
> >>> abstraction is that drivers do not have to manage the writeback
> >>> drm_connector manually, they shouldn't touch it at all.
> >>
> >> Laurent, I wanted to shift a bit from the question of drm_connector to
> >> the question of drm_encoder being embedded in the
> >> drm_writeback_connector.
> >> In case of the msm driver the drm_encoder is not a lightweight entity,
> >> but a full-featured driver part. Significant part of it can be shared
> >> with the writeback implementation, if we
Re: [Intel-gfx] [PATCH 5/6] drm/rcar_du: changes to rcar-du driver resulting from drm_writeback_connector structure changes
Hi Jani,
On Wed, Feb 02, 2022 at 03:15:03PM +0200, Jani Nikula wrote:
> On Wed, 02 Feb 2022, Laurent Pinchart wrote:
> > On Wed, Feb 02, 2022 at 02:24:28PM +0530, Kandpal Suraj wrote:
> >> Changing rcar_du driver to accomadate the change of
> >> drm_writeback_connector.base and drm_writeback_connector.encoder
> >> to a pointer the reason for which is explained in the
> >> Patch(drm: add writeback pointers to drm_connector).
> >>
> >> Signed-off-by: Kandpal Suraj
> >> ---
> >> drivers/gpu/drm/rcar-du/rcar_du_crtc.h | 2 ++
> >> drivers/gpu/drm/rcar-du/rcar_du_writeback.c | 8 +---
> >> 2 files changed, 7 insertions(+), 3 deletions(-)
> >>
> >> diff --git a/drivers/gpu/drm/rcar-du/rcar_du_crtc.h
> >> b/drivers/gpu/drm/rcar-du/rcar_du_crtc.h
> >> index 66e8839db708..68f387a04502 100644
> >> --- a/drivers/gpu/drm/rcar-du/rcar_du_crtc.h
> >> +++ b/drivers/gpu/drm/rcar-du/rcar_du_crtc.h
> >> @@ -72,6 +72,8 @@ struct rcar_du_crtc {
> >>const char *const *sources;
> >>unsigned int sources_count;
> >>
> >> + struct drm_connector connector;
> >> + struct drm_encoder encoder;
> >
> > Those fields are, at best, poorly named. Furthermore, there's no need in
> > this driver or in other drivers using drm_writeback_connector to create
> > an encoder or connector manually. Let's not polute all drivers because
> > i915 doesn't have its abstractions right.
>
> i915 uses the quite common model for struct inheritance:
>
> struct intel_connector {
> struct drm_connector base;
> /* ... */
> }
>
> Same with at least amd, ast, fsl-dcu, hisilicon, mga200, msm, nouveau,
> radeon, tilcdc, and vboxvideo.
>
> We could argue about the relative merits of that abstraction, but I
> think the bottom line is that it's popular and the drivers using it are
> not going to be persuaded to move away from it.
Nobody said inheritance is bad.
> It's no coincidence that the drivers who've implemented writeback so far
> (komeda, mali, rcar-du, vc4, and vkms) do not use the abstraction,
> because the drm_writeback_connector midlayer does, forcing the issue.
Are you sure it's not a coincidence ? :-)
The encoder and especially connector created by drm_writeback_connector
are there only because KMS requires a drm_encoder and a drm_connector to
be exposed to userspace (and I could argue that using a connector for
writeback is a hack, but that won't change). The connector is "virtual",
I still fail to see why i915 or any other driver would need to wrap it
into something else. The whole point of the drm_writeback_connector
abstraction is that drivers do not have to manage the writeback
drm_connector manually, they shouldn't touch it at all.
> So I think drm_writeback_connector should *not* use the inheritance
> abstraction because it's a midlayer that should leave that option to the
> drivers. I think drm_writeback_connector needs to be changed to
> accommodate that, and, unfortunately, it means current writeback users
> need to be changed as well.
>
> I am not sure, however, if the series at hand is the right
> approach. Perhaps writeback can be modified to allocate the stuff for
> you if you prefer it that way, as long as the drm_connector is not
> embedded in struct drm_writeback_connector.
>
> > Nack.
> >
> >>struct drm_writeback_connector writeback;
> >> };
> >>
> >> diff --git a/drivers/gpu/drm/rcar-du/rcar_du_writeback.c
> >> b/drivers/gpu/drm/rcar-du/rcar_du_writeback.c
> >> index c79d1259e49b..5b1e83380c47 100644
> >> --- a/drivers/gpu/drm/rcar-du/rcar_du_writeback.c
> >> +++ b/drivers/gpu/drm/rcar-du/rcar_du_writeback.c
> >> @@ -200,8 +200,10 @@ int rcar_du_writeback_init(struct rcar_du_device
> >> *rcdu,
> >> {
> >>struct drm_writeback_connector *wb_conn = >writeback;
> >>
> >> - wb_conn->encoder.possible_crtcs = 1 << drm_crtc_index(>crtc);
> >> - drm_connector_helper_add(_conn->base,
> >> + wb_conn->base = >connector;
> >> + wb_conn->encoder = >encoder;
> >> + wb_conn->encoder->possible_crtcs = 1 << drm_crtc_index(>crtc);
> >> + drm_connector_helper_add(wb_conn->base,
> >> _du_wb_conn_helper_funcs);
> >>
> >>return drm_writeback_connector_init(>ddev, wb_conn,
> >> @@ -220,7 +222,7 @@ void rcar_du_writeback_setup(struct rcar_du_crtc
> >> *rcrtc,
> >>struct drm_framebuffer *fb;
> >>unsigned int i;
> >>
> >> - state = rcrtc->writeback.base.state;
> >> + state = rcrtc->writeback.base->state;
> >>if (!state || !state->writeback_job)
> >>return;
> >>
--
Regards,
Laurent Pinchart
Re: [Intel-gfx] [PATCH 5/6] drm/rcar_du: changes to rcar-du driver resulting from drm_writeback_connector structure changes
Hi Kandpal,
Thank you for the patch.
On Wed, Feb 02, 2022 at 02:24:28PM +0530, Kandpal Suraj wrote:
> Changing rcar_du driver to accomadate the change of
> drm_writeback_connector.base and drm_writeback_connector.encoder
> to a pointer the reason for which is explained in the
> Patch(drm: add writeback pointers to drm_connector).
>
> Signed-off-by: Kandpal Suraj
> ---
> drivers/gpu/drm/rcar-du/rcar_du_crtc.h | 2 ++
> drivers/gpu/drm/rcar-du/rcar_du_writeback.c | 8 +---
> 2 files changed, 7 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/rcar-du/rcar_du_crtc.h
> b/drivers/gpu/drm/rcar-du/rcar_du_crtc.h
> index 66e8839db708..68f387a04502 100644
> --- a/drivers/gpu/drm/rcar-du/rcar_du_crtc.h
> +++ b/drivers/gpu/drm/rcar-du/rcar_du_crtc.h
> @@ -72,6 +72,8 @@ struct rcar_du_crtc {
> const char *const *sources;
> unsigned int sources_count;
>
> + struct drm_connector connector;
> + struct drm_encoder encoder;
Those fields are, at best, poorly named. Furthermore, there's no need in
this driver or in other drivers using drm_writeback_connector to create
an encoder or connector manually. Let's not polute all drivers because
i915 doesn't have its abstractions right.
Nack.
> struct drm_writeback_connector writeback;
> };
>
> diff --git a/drivers/gpu/drm/rcar-du/rcar_du_writeback.c
> b/drivers/gpu/drm/rcar-du/rcar_du_writeback.c
> index c79d1259e49b..5b1e83380c47 100644
> --- a/drivers/gpu/drm/rcar-du/rcar_du_writeback.c
> +++ b/drivers/gpu/drm/rcar-du/rcar_du_writeback.c
> @@ -200,8 +200,10 @@ int rcar_du_writeback_init(struct rcar_du_device *rcdu,
> {
> struct drm_writeback_connector *wb_conn = >writeback;
>
> - wb_conn->encoder.possible_crtcs = 1 << drm_crtc_index(>crtc);
> - drm_connector_helper_add(_conn->base,
> + wb_conn->base = >connector;
> + wb_conn->encoder = >encoder;
> + wb_conn->encoder->possible_crtcs = 1 << drm_crtc_index(>crtc);
> + drm_connector_helper_add(wb_conn->base,
>_du_wb_conn_helper_funcs);
>
> return drm_writeback_connector_init(>ddev, wb_conn,
> @@ -220,7 +222,7 @@ void rcar_du_writeback_setup(struct rcar_du_crtc *rcrtc,
> struct drm_framebuffer *fb;
> unsigned int i;
>
> - state = rcrtc->writeback.base.state;
> + state = rcrtc->writeback.base->state;
> if (!state || !state->writeback_job)
> return;
>
--
Regards,
Laurent Pinchart
Re: [Intel-gfx] [PATCH v3 24/27] drm/vkms: Don't set struct drm_device.irq_enabled
Hi Thomas,
Thank you for the patch.
On Thu, Jun 24, 2021 at 09:29:13AM +0200, Thomas Zimmermann wrote:
> The field drm_device.irq_enabled is only used by legacy drivers
> with userspace modesetting. Don't set it in vkms.
>
> Signed-off-by: Thomas Zimmermann
Reviewed-by: Laurent Pinchart
> ---
> drivers/gpu/drm/vkms/vkms_drv.c | 2 --
> 1 file changed, 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/vkms/vkms_drv.c b/drivers/gpu/drm/vkms/vkms_drv.c
> index 027ffe759440..496de38ad983 100644
> --- a/drivers/gpu/drm/vkms/vkms_drv.c
> +++ b/drivers/gpu/drm/vkms/vkms_drv.c
> @@ -163,8 +163,6 @@ static int vkms_create(struct vkms_config *config)
> goto out_devres;
> }
>
> - vkms_device->drm.irq_enabled = true;
> -
> ret = drm_vblank_init(_device->drm, 1);
> if (ret) {
> DRM_ERROR("Failed to vblank\n");
--
Regards,
Laurent Pinchart
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v3 16/27] drm/rcar-du: Don't set struct drm_device.irq_enabled
Hi Thomas, Thank you for the patch. On Thu, Jun 24, 2021 at 09:29:05AM +0200, Thomas Zimmermann wrote: > The field drm_device.irq_enabled is only used by legacy drivers > with userspace modesetting. Don't set it in rcar-du. > > Signed-off-by: Thomas Zimmermann Reviewed-by: Laurent Pinchart > --- > drivers/gpu/drm/rcar-du/rcar_du_drv.c | 2 -- > 1 file changed, 2 deletions(-) > > diff --git a/drivers/gpu/drm/rcar-du/rcar_du_drv.c > b/drivers/gpu/drm/rcar-du/rcar_du_drv.c > index bfbff90588cb..e289a66594a7 100644 > --- a/drivers/gpu/drm/rcar-du/rcar_du_drv.c > +++ b/drivers/gpu/drm/rcar-du/rcar_du_drv.c > @@ -593,8 +593,6 @@ static int rcar_du_probe(struct platform_device *pdev) > goto error; > } > > - rcdu->ddev.irq_enabled = 1; > - > /* >* Register the DRM device with the core and the connectors with >* sysfs. -- Regards, Laurent Pinchart ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 20/30] drm/dp: Pass drm_dp_aux to drm_dp*_link_train_channel_eq_delay()
Hi Lyude,
Thank you for the patch.
On Fri, Feb 19, 2021 at 04:53:16PM -0500, Lyude Paul wrote:
> So that we can start using drm_dbg_*() for
> drm_dp_link_train_channel_eq_delay() and
> drm_dp_lttpr_link_train_channel_eq_delay().
>
> Signed-off-by: Lyude Paul
Reviewed-by: Laurent Pinchart
> ---
> drivers/gpu/drm/amd/amdgpu/atombios_dp.c | 2 +-
> drivers/gpu/drm/drm_dp_helper.c| 14 +-
> .../gpu/drm/i915/display/intel_dp_link_training.c | 4 ++--
> drivers/gpu/drm/msm/dp/dp_ctrl.c | 4 ++--
> drivers/gpu/drm/msm/edp/edp_ctrl.c | 4 ++--
> drivers/gpu/drm/radeon/atombios_dp.c | 2 +-
> drivers/gpu/drm/xlnx/zynqmp_dp.c | 2 +-
> include/drm/drm_dp_helper.h| 6 --
> 8 files changed, 22 insertions(+), 16 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/atombios_dp.c
> b/drivers/gpu/drm/amd/amdgpu/atombios_dp.c
> index 4468f9d6b4dd..59ce6f620fdc 100644
> --- a/drivers/gpu/drm/amd/amdgpu/atombios_dp.c
> +++ b/drivers/gpu/drm/amd/amdgpu/atombios_dp.c
> @@ -676,7 +676,7 @@ amdgpu_atombios_dp_link_train_ce(struct
> amdgpu_atombios_dp_link_train_info *dp_i
> dp_info->tries = 0;
> channel_eq = false;
> while (1) {
> - drm_dp_link_train_channel_eq_delay(dp_info->dpcd);
> + drm_dp_link_train_channel_eq_delay(dp_info->aux, dp_info->dpcd);
>
> if (drm_dp_dpcd_read_link_status(dp_info->aux,
>dp_info->link_status) <= 0) {
> diff --git a/drivers/gpu/drm/drm_dp_helper.c b/drivers/gpu/drm/drm_dp_helper.c
> index ce08eb3bface..a9316c1ecb52 100644
> --- a/drivers/gpu/drm/drm_dp_helper.c
> +++ b/drivers/gpu/drm/drm_dp_helper.c
> @@ -151,7 +151,8 @@ void drm_dp_link_train_clock_recovery_delay(const struct
> drm_dp_aux *aux,
> }
> EXPORT_SYMBOL(drm_dp_link_train_clock_recovery_delay);
>
> -static void __drm_dp_link_train_channel_eq_delay(unsigned long rd_interval)
> +static void __drm_dp_link_train_channel_eq_delay(const struct drm_dp_aux
> *aux,
> + unsigned long rd_interval)
> {
> if (rd_interval > 4)
> DRM_DEBUG_KMS("AUX interval %lu, out of range (max 4)\n",
> @@ -165,9 +166,11 @@ static void
> __drm_dp_link_train_channel_eq_delay(unsigned long rd_interval)
> usleep_range(rd_interval, rd_interval * 2);
> }
>
> -void drm_dp_link_train_channel_eq_delay(const u8 dpcd[DP_RECEIVER_CAP_SIZE])
> +void drm_dp_link_train_channel_eq_delay(const struct drm_dp_aux *aux,
> + const u8 dpcd[DP_RECEIVER_CAP_SIZE])
> {
> - __drm_dp_link_train_channel_eq_delay(dpcd[DP_TRAINING_AUX_RD_INTERVAL] &
> + __drm_dp_link_train_channel_eq_delay(aux,
> + dpcd[DP_TRAINING_AUX_RD_INTERVAL] &
>DP_TRAINING_AUX_RD_MASK);
> }
> EXPORT_SYMBOL(drm_dp_link_train_channel_eq_delay);
> @@ -183,13 +186,14 @@ static u8 dp_lttpr_phy_cap(const u8
> phy_cap[DP_LTTPR_PHY_CAP_SIZE], int r)
> return phy_cap[r - DP_TRAINING_AUX_RD_INTERVAL_PHY_REPEATER1];
> }
>
> -void drm_dp_lttpr_link_train_channel_eq_delay(const u8
> phy_cap[DP_LTTPR_PHY_CAP_SIZE])
> +void drm_dp_lttpr_link_train_channel_eq_delay(const struct drm_dp_aux *aux,
> + const u8
> phy_cap[DP_LTTPR_PHY_CAP_SIZE])
> {
> u8 interval = dp_lttpr_phy_cap(phy_cap,
>
> DP_TRAINING_AUX_RD_INTERVAL_PHY_REPEATER1) &
> DP_TRAINING_AUX_RD_MASK;
>
> - __drm_dp_link_train_channel_eq_delay(interval);
> + __drm_dp_link_train_channel_eq_delay(aux, interval);
> }
> EXPORT_SYMBOL(drm_dp_lttpr_link_train_channel_eq_delay);
>
> diff --git a/drivers/gpu/drm/i915/display/intel_dp_link_training.c
> b/drivers/gpu/drm/i915/display/intel_dp_link_training.c
> index 222073d46bdb..fe8b5a5d9d1a 100644
> --- a/drivers/gpu/drm/i915/display/intel_dp_link_training.c
> +++ b/drivers/gpu/drm/i915/display/intel_dp_link_training.c
> @@ -593,11 +593,11 @@
> intel_dp_link_training_channel_equalization_delay(struct intel_dp *intel_dp,
> enum drm_dp_phy dp_phy)
> {
> if (dp_phy == DP_PHY_DPRX) {
> - drm_dp_link_train_channel_eq_delay(intel_dp->dpcd);
> + drm_dp_link_train_channel_eq_delay(_dp->aux,
> intel_dp->dpcd);
> } else {
> const u8 *phy_caps = intel_dp_lttpr_phy_caps(intel_dp, dp_phy);
>
> -
Re: [Intel-gfx] [PATCH 19/30] drm/dp: Pass drm_dp_aux to drm_dp_link_train_clock_recovery_delay()
Hi Lyude,
Thank you for the patch.
On Fri, Feb 19, 2021 at 04:53:15PM -0500, Lyude Paul wrote:
> So that we can start using drm_dbg_*() in
> drm_dp_link_train_clock_recovery_delay().
>
> Signed-off-by: Lyude Paul
Reviewed-by: Laurent Pinchart
> ---
> drivers/gpu/drm/amd/amdgpu/atombios_dp.c | 2 +-
> drivers/gpu/drm/drm_dp_helper.c | 3 ++-
> drivers/gpu/drm/i915/display/intel_dp_link_training.c | 2 +-
> drivers/gpu/drm/msm/dp/dp_ctrl.c | 2 +-
> drivers/gpu/drm/msm/edp/edp_ctrl.c| 2 +-
> drivers/gpu/drm/radeon/atombios_dp.c | 2 +-
> drivers/gpu/drm/xlnx/zynqmp_dp.c | 2 +-
> include/drm/drm_dp_helper.h | 4 +++-
> 8 files changed, 11 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/atombios_dp.c
> b/drivers/gpu/drm/amd/amdgpu/atombios_dp.c
> index 6d35da65e09f..4468f9d6b4dd 100644
> --- a/drivers/gpu/drm/amd/amdgpu/atombios_dp.c
> +++ b/drivers/gpu/drm/amd/amdgpu/atombios_dp.c
> @@ -611,7 +611,7 @@ amdgpu_atombios_dp_link_train_cr(struct
> amdgpu_atombios_dp_link_train_info *dp_i
> dp_info->tries = 0;
> voltage = 0xff;
> while (1) {
> - drm_dp_link_train_clock_recovery_delay(dp_info->dpcd);
> + drm_dp_link_train_clock_recovery_delay(dp_info->aux,
> dp_info->dpcd);
>
> if (drm_dp_dpcd_read_link_status(dp_info->aux,
>dp_info->link_status) <= 0) {
> diff --git a/drivers/gpu/drm/drm_dp_helper.c b/drivers/gpu/drm/drm_dp_helper.c
> index 194e0c273809..ce08eb3bface 100644
> --- a/drivers/gpu/drm/drm_dp_helper.c
> +++ b/drivers/gpu/drm/drm_dp_helper.c
> @@ -132,7 +132,8 @@ u8 drm_dp_get_adjust_request_post_cursor(const u8
> link_status[DP_LINK_STATUS_SIZ
> }
> EXPORT_SYMBOL(drm_dp_get_adjust_request_post_cursor);
>
> -void drm_dp_link_train_clock_recovery_delay(const u8
> dpcd[DP_RECEIVER_CAP_SIZE])
> +void drm_dp_link_train_clock_recovery_delay(const struct drm_dp_aux *aux,
> + const u8 dpcd[DP_RECEIVER_CAP_SIZE])
> {
> unsigned long rd_interval = dpcd[DP_TRAINING_AUX_RD_INTERVAL] &
>DP_TRAINING_AUX_RD_MASK;
> diff --git a/drivers/gpu/drm/i915/display/intel_dp_link_training.c
> b/drivers/gpu/drm/i915/display/intel_dp_link_training.c
> index 892d7db7d94f..222073d46bdb 100644
> --- a/drivers/gpu/drm/i915/display/intel_dp_link_training.c
> +++ b/drivers/gpu/drm/i915/display/intel_dp_link_training.c
> @@ -441,7 +441,7 @@ static void
> intel_dp_link_training_clock_recovery_delay(struct intel_dp *intel_d
> enum drm_dp_phy dp_phy)
> {
> if (dp_phy == DP_PHY_DPRX)
> - drm_dp_link_train_clock_recovery_delay(intel_dp->dpcd);
> + drm_dp_link_train_clock_recovery_delay(_dp->aux,
> intel_dp->dpcd);
> else
> drm_dp_lttpr_link_train_clock_recovery_delay();
> }
> diff --git a/drivers/gpu/drm/msm/dp/dp_ctrl.c
> b/drivers/gpu/drm/msm/dp/dp_ctrl.c
> index 36b39c381b3f..2501a6b326a3 100644
> --- a/drivers/gpu/drm/msm/dp/dp_ctrl.c
> +++ b/drivers/gpu/drm/msm/dp/dp_ctrl.c
> @@ -1103,7 +1103,7 @@ static int dp_ctrl_link_train_1(struct dp_ctrl_private
> *ctrl,
> tries = 0;
> old_v_level = ctrl->link->phy_params.v_level;
> for (tries = 0; tries < maximum_retries; tries++) {
> - drm_dp_link_train_clock_recovery_delay(ctrl->panel->dpcd);
> + drm_dp_link_train_clock_recovery_delay(ctrl->aux,
> ctrl->panel->dpcd);
>
> ret = dp_ctrl_read_link_status(ctrl, link_status);
> if (ret)
> diff --git a/drivers/gpu/drm/msm/edp/edp_ctrl.c
> b/drivers/gpu/drm/msm/edp/edp_ctrl.c
> index 57af3d8b6699..6501598448b4 100644
> --- a/drivers/gpu/drm/msm/edp/edp_ctrl.c
> +++ b/drivers/gpu/drm/msm/edp/edp_ctrl.c
> @@ -608,7 +608,7 @@ static int edp_start_link_train_1(struct edp_ctrl *ctrl)
> tries = 0;
> old_v_level = ctrl->v_level;
> while (1) {
> - drm_dp_link_train_clock_recovery_delay(ctrl->dpcd);
> + drm_dp_link_train_clock_recovery_delay(ctrl->drm_aux,
> ctrl->dpcd);
>
> rlen = drm_dp_dpcd_read_link_status(ctrl->drm_aux, link_status);
> if (rlen < DP_LINK_STATUS_SIZE) {
> diff --git a/drivers/gpu/drm/radeon/atombios_dp.c
> b/drivers/gpu/drm/radeon/atombios_dp.c
> index c50c504bad50..299b9d8da376 100644
> --- a/drivers/gpu/drm/radeon/atombios_dp.c
> +
Re: [Intel-gfx] [PATCH 15/30] drm/dp: Add backpointer to drm_device in drm_dp_aux
= zynqmp_dp_aux_transfer;
>
> return drm_dp_aux_register(>aux);
> diff --git a/include/drm/drm_dp_helper.h b/include/drm/drm_dp_helper.h
> index b35a1c1339e8..45ec74862212 100644
> --- a/include/drm/drm_dp_helper.h
> +++ b/include/drm/drm_dp_helper.h
> @@ -1833,13 +1833,19 @@ struct drm_dp_aux_cec {
> * @name: user-visible name of this AUX channel and the I2C-over-AUX adapter
> * @ddc: I2C adapter that can be used for I2C-over-AUX communication
> * @dev: pointer to struct device that is the parent for this AUX channel
> + * @drm_dev: pointer to the _device that owns this AUX channel. Beware,
> this may be %NULL
> + * before drm_dp_aux_register() has been called.
> * @crtc: backpointer to the crtc that is currently using this AUX channel
> * @hw_mutex: internal mutex used for locking transfers
> * @crc_work: worker that captures CRCs for each frame
> * @crc_count: counter of captured frame CRCs
> * @transfer: transfers a message representing a single AUX transaction
> *
> - * The @dev field should be set to a pointer to the device that implements
> the AUX channel.
> + * The @dev field should be set to a pointer to the device that implements
> the AUX channel. As well,
> + * the @drm_dev field should be set to the _device that will be using
> this AUX channel as early
> + * as possible. For many graphics drivers this should happen before
> drm_dp_aux_init(), however it's
> + * perfectly fine to set this field later so long as it's assigned before
> calling
> + * drm_dp_aux_register().
> *
> * The @name field may be used to specify the name of the I2C adapter. If
> set to %NULL, dev_name()
> * of @dev will be used.
> @@ -1866,6 +1872,7 @@ struct drm_dp_aux {
> const char *name;
> struct i2c_adapter ddc;
> struct device *dev;
> + struct drm_device *drm_dev;
> struct drm_crtc *crtc;
> struct mutex hw_mutex;
> struct work_struct crc_work;
--
Regards,
Laurent Pinchart
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 06/30] drm/bridge/ti-sn65dsi86: (Un)register aux device on bridge attach/detach
Hi Lyude,
Thank you for the patch.
On Fri, Feb 19, 2021 at 04:53:02PM -0500, Lyude Paul wrote:
> Since we're about to add a back-pointer to drm_dev in drm_dp_aux, let's
> move the AUX adapter registration to the first point where we know which
> DRM device we'll be working with - when the drm_bridge is attached.
> Likewise, we unregister the AUX adapter on bridge detachment by adding a
> ti_sn_bridge_detach() callback.
>
> Signed-off-by: Lyude Paul
Reviewed-by: Laurent Pinchart
> ---
> drivers/gpu/drm/bridge/ti-sn65dsi86.c | 18 --
> 1 file changed, 16 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/bridge/ti-sn65dsi86.c
> b/drivers/gpu/drm/bridge/ti-sn65dsi86.c
> index f27306c51e4d..88df4dd0f39d 100644
> --- a/drivers/gpu/drm/bridge/ti-sn65dsi86.c
> +++ b/drivers/gpu/drm/bridge/ti-sn65dsi86.c
> @@ -362,12 +362,18 @@ static int ti_sn_bridge_attach(struct drm_bridge
> *bridge,
> return -EINVAL;
> }
>
> + ret = drm_dp_aux_register(>aux);
> + if (ret < 0) {
> + drm_err(bridge->dev, "Failed to register DP AUX channel: %d\n",
> ret);
> + return ret;
> + }
> +
> ret = drm_connector_init(bridge->dev, >connector,
>_sn_bridge_connector_funcs,
>DRM_MODE_CONNECTOR_eDP);
> if (ret) {
> DRM_ERROR("Failed to initialize connector with drm\n");
> - return ret;
> + goto err_conn_init;
> }
>
> drm_connector_helper_add(>connector,
> @@ -424,9 +430,16 @@ static int ti_sn_bridge_attach(struct drm_bridge *bridge,
> mipi_dsi_device_unregister(dsi);
> err_dsi_host:
> drm_connector_cleanup(>connector);
> +err_conn_init:
> + drm_dp_aux_unregister(>aux);
> return ret;
> }
>
> +static void ti_sn_bridge_detach(struct drm_bridge *bridge)
> +{
> + drm_dp_aux_unregister(_to_ti_sn_bridge(bridge)->aux);
> +}
> +
> static void ti_sn_bridge_disable(struct drm_bridge *bridge)
> {
> struct ti_sn_bridge *pdata = bridge_to_ti_sn_bridge(bridge);
> @@ -863,6 +876,7 @@ static void ti_sn_bridge_post_disable(struct drm_bridge
> *bridge)
>
> static const struct drm_bridge_funcs ti_sn_bridge_funcs = {
> .attach = ti_sn_bridge_attach,
> + .detach = ti_sn_bridge_detach,
> .pre_enable = ti_sn_bridge_pre_enable,
> .enable = ti_sn_bridge_enable,
> .disable = ti_sn_bridge_disable,
> @@ -1287,7 +1301,7 @@ static int ti_sn_bridge_probe(struct i2c_client *client,
> pdata->aux.name = "ti-sn65dsi86-aux";
> pdata->aux.dev = pdata->dev;
> pdata->aux.transfer = ti_sn_aux_transfer;
> - drm_dp_aux_register(>aux);
> + drm_dp_aux_init(>aux);
>
> pdata->bridge.funcs = _sn_bridge_funcs;
> pdata->bridge.of_node = client->dev.of_node;
--
Regards,
Laurent Pinchart
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 14/65] drm/rcar-du: Annotate dma-fence critical section in commit path
Hi Daniel, Thank you for the patch. On Fri, Oct 23, 2020 at 02:21:25PM +0200, Daniel Vetter wrote: > Ends right after drm_atomic_helper_commit_hw_done(), absolutely > nothing fancy going on here. > > Signed-off-by: Daniel Vetter > Cc: Laurent Pinchart > Cc: Kieran Bingham > Cc: linux-renesas-...@vger.kernel.org I'm lacking context here, there's only one instance of a call to dma_fence_begin_signalling() in the subsystem, and no cover letter in the series to explain what's going on. Some information would help reviewing the patch :-) Also, could you mention in the cover letter for the next version if you will merge the whole series, or expect individual maintainers to pick up the relevant patches ? > --- > drivers/gpu/drm/rcar-du/rcar_du_kms.c | 2 ++ > 1 file changed, 2 insertions(+) > > diff --git a/drivers/gpu/drm/rcar-du/rcar_du_kms.c > b/drivers/gpu/drm/rcar-du/rcar_du_kms.c > index 72dda446355f..8d91140151cc 100644 > --- a/drivers/gpu/drm/rcar-du/rcar_du_kms.c > +++ b/drivers/gpu/drm/rcar-du/rcar_du_kms.c > @@ -441,6 +441,7 @@ static void rcar_du_atomic_commit_tail(struct > drm_atomic_state *old_state) > struct drm_crtc_state *crtc_state; > struct drm_crtc *crtc; > unsigned int i; > + bool fence_cookie = dma_fence_begin_signalling(); > > /* >* Store RGB routing to DPAD0 and DPAD1, the hardware will be configured > @@ -467,6 +468,7 @@ static void rcar_du_atomic_commit_tail(struct > drm_atomic_state *old_state) > drm_atomic_helper_commit_modeset_enables(dev, old_state); > > drm_atomic_helper_commit_hw_done(old_state); > + dma_fence_end_signalling(fence_cookie); > drm_atomic_helper_wait_for_flip_done(dev, old_state); > > drm_atomic_helper_cleanup_planes(dev, old_state); -- Regards, Laurent Pinchart ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2 20/21] drm/xlnx: Initialize DRM driver instance with CMA helper macro
Hi Thomas,
Thank you for the patch.
On Tue, Sep 15, 2020 at 04:59:57PM +0200, Thomas Zimmermann wrote:
> The xlnx driver uses CMA helpers with default callback functions.
> Initialize the driver structure with the rsp CMA helper macro. The
> driver is being converted to use GEM object functions as part of
> this change.
>
> Two callbacks, .dumb_destroy and .gem_prime_import, were initialized
> to their default implementations, so they are just kept empty now.
>
> v2:
> * initialize with DRM_GEM_CMA_DRIVER_OPS_WITH_DUMB_CREATE (Laurent)
>
> Signed-off-by: Thomas Zimmermann
Reviewed-by: Laurent Pinchart
> ---
> drivers/gpu/drm/xlnx/zynqmp_dpsub.c | 14 +-
> 1 file changed, 1 insertion(+), 13 deletions(-)
>
> diff --git a/drivers/gpu/drm/xlnx/zynqmp_dpsub.c
> b/drivers/gpu/drm/xlnx/zynqmp_dpsub.c
> index 8e69303aad3f..f3ffc3703a0e 100644
> --- a/drivers/gpu/drm/xlnx/zynqmp_dpsub.c
> +++ b/drivers/gpu/drm/xlnx/zynqmp_dpsub.c
> @@ -80,19 +80,7 @@ static struct drm_driver zynqmp_dpsub_drm_driver = {
> .driver_features= DRIVER_MODESET | DRIVER_GEM |
> DRIVER_ATOMIC,
>
> - .prime_handle_to_fd = drm_gem_prime_handle_to_fd,
> - .prime_fd_to_handle = drm_gem_prime_fd_to_handle,
> - .gem_prime_export = drm_gem_prime_export,
> - .gem_prime_import = drm_gem_prime_import,
> - .gem_prime_get_sg_table = drm_gem_cma_prime_get_sg_table,
> - .gem_prime_import_sg_table = drm_gem_cma_prime_import_sg_table,
> - .gem_prime_vmap = drm_gem_cma_prime_vmap,
> - .gem_prime_vunmap = drm_gem_cma_prime_vunmap,
> - .gem_prime_mmap = drm_gem_cma_prime_mmap,
> - .gem_free_object_unlocked = drm_gem_cma_free_object,
> - .gem_vm_ops = _gem_cma_vm_ops,
> - .dumb_create= zynqmp_dpsub_dumb_create,
> - .dumb_destroy = drm_gem_dumb_destroy,
> + DRM_GEM_CMA_DRIVER_OPS_WITH_DUMB_CREATE(zynqmp_dpsub_dumb_create),
>
> .fops = _dpsub_drm_fops,
>
--
Regards,
Laurent Pinchart
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 10/20] drm/omapdrm: Introduce GEM object functions
Hi Thomas,
Thank you for the patch.
On Thu, Aug 13, 2020 at 10:36:34AM +0200, Thomas Zimmermann wrote:
> GEM object functions deprecate several similar callback interfaces in
> struct drm_driver. This patch replaces the per-driver callbacks with
> per-instance callbacks in omapdrm.
>
> Signed-off-by: Thomas Zimmermann
> ---
> drivers/gpu/drm/omapdrm/omap_drv.c | 9 -
> drivers/gpu/drm/omapdrm/omap_gem.c | 16 +++-
> drivers/gpu/drm/omapdrm/omap_gem.h | 1 -
> 3 files changed, 15 insertions(+), 11 deletions(-)
>
> diff --git a/drivers/gpu/drm/omapdrm/omap_drv.c
> b/drivers/gpu/drm/omapdrm/omap_drv.c
> index 53d5e184ee77..2e598b8b72af 100644
> --- a/drivers/gpu/drm/omapdrm/omap_drv.c
> +++ b/drivers/gpu/drm/omapdrm/omap_drv.c
> @@ -521,12 +521,6 @@ static int dev_open(struct drm_device *dev, struct
> drm_file *file)
> return 0;
> }
>
> -static const struct vm_operations_struct omap_gem_vm_ops = {
> - .fault = omap_gem_fault,
> - .open = drm_gem_vm_open,
> - .close = drm_gem_vm_close,
> -};
> -
> static const struct file_operations omapdriver_fops = {
> .owner = THIS_MODULE,
> .open = drm_open,
> @@ -549,10 +543,7 @@ static struct drm_driver omap_drm_driver = {
> #endif
> .prime_handle_to_fd = drm_gem_prime_handle_to_fd,
> .prime_fd_to_handle = drm_gem_prime_fd_to_handle,
> - .gem_prime_export = omap_gem_prime_export,
> .gem_prime_import = omap_gem_prime_import,
> - .gem_free_object_unlocked = omap_gem_free_object,
> - .gem_vm_ops = _gem_vm_ops,
> .dumb_create = omap_gem_dumb_create,
> .dumb_map_offset = omap_gem_dumb_map_offset,
> .ioctls = ioctls,
> diff --git a/drivers/gpu/drm/omapdrm/omap_gem.c
> b/drivers/gpu/drm/omapdrm/omap_gem.c
> index d0d12d5dd76c..d68dc63dea0a 100644
> --- a/drivers/gpu/drm/omapdrm/omap_gem.c
> +++ b/drivers/gpu/drm/omapdrm/omap_gem.c
> @@ -487,7 +487,7 @@ static vm_fault_t omap_gem_fault_2d(struct drm_gem_object
> *obj,
> * vma->vm_private_data points to the GEM object that is backing this
> * mapping.
> */
> -vm_fault_t omap_gem_fault(struct vm_fault *vmf)
> +static vm_fault_t omap_gem_fault(struct vm_fault *vmf)
> {
> struct vm_area_struct *vma = vmf->vma;
> struct drm_gem_object *obj = vma->vm_private_data;
> @@ -1169,6 +1169,18 @@ static bool omap_gem_validate_flags(struct drm_device
> *dev, u32 flags)
> return true;
> }
>
> +static const struct vm_operations_struct omap_gem_vm_ops = {
> + .fault = omap_gem_fault,
> + .open = drm_gem_vm_open,
> + .close = drm_gem_vm_close,
> +};
> +
> +static const struct drm_gem_object_funcs omap_gem_object_funcs = {
> + .free = omap_gem_free_object,
> + .export = omap_gem_prime_export,
> + .vm_ops = _gem_vm_ops,
> +};
> +
> /* GEM buffer object constructor */
> struct drm_gem_object *omap_gem_new(struct drm_device *dev,
> union omap_gem_size gsize, u32 flags)
> @@ -1236,6 +1248,8 @@ struct drm_gem_object *omap_gem_new(struct drm_device
> *dev,
> size = PAGE_ALIGN(gsize.bytes);
> }
>
> + obj->funcs = _gem_object_funcs;
> +
> /* Initialize the GEM object. */
> if (!(flags & OMAP_BO_MEM_SHMEM)) {
> drm_gem_private_object_init(dev, obj, size);
> diff --git a/drivers/gpu/drm/omapdrm/omap_gem.h
> b/drivers/gpu/drm/omapdrm/omap_gem.h
> index 729b7812a815..9e6b5c8195d9 100644
> --- a/drivers/gpu/drm/omapdrm/omap_gem.h
> +++ b/drivers/gpu/drm/omapdrm/omap_gem.h
> @@ -69,7 +69,6 @@ struct dma_buf *omap_gem_prime_export(struct drm_gem_object
> *obj, int flags);
> struct drm_gem_object *omap_gem_prime_import(struct drm_device *dev,
> struct dma_buf *buffer);
>
> -vm_fault_t omap_gem_fault(struct vm_fault *vmf);
I like how this function now becomes internal to omap_gem.c.
Reviewed-by: Laurent Pinchart
> int omap_gem_roll(struct drm_gem_object *obj, u32 roll);
> void omap_gem_cpu_sync_page(struct drm_gem_object *obj, int pgoff);
> void omap_gem_dma_sync_buffer(struct drm_gem_object *obj,
--
Regards,
Laurent Pinchart
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 19/20] drm/xlnx: Initialize DRM driver instance with CMA helper macro
Hi Thomas,
Thank you for the patch.
On Thu, Aug 13, 2020 at 10:36:43AM +0200, Thomas Zimmermann wrote:
> The xlnx driver uses CMA helpers with default callback functions.
> Initialize the driver structure with the rsp CMA helper macro. The
> driver is being converted to use GEM object functions as part of
> this change.
>
> Two callbacks, .dumb_destroy and .gem_prime_import, were initialized
> to their default implementations, so they are just kept empty now.
>
> Signed-off-by: Thomas Zimmermann
> ---
> drivers/gpu/drm/xlnx/zynqmp_dpsub.c | 14 +-
> 1 file changed, 1 insertion(+), 13 deletions(-)
>
> diff --git a/drivers/gpu/drm/xlnx/zynqmp_dpsub.c
> b/drivers/gpu/drm/xlnx/zynqmp_dpsub.c
> index 26328c76305b..058044dcc062 100644
> --- a/drivers/gpu/drm/xlnx/zynqmp_dpsub.c
> +++ b/drivers/gpu/drm/xlnx/zynqmp_dpsub.c
> @@ -80,19 +80,7 @@ static struct drm_driver zynqmp_dpsub_drm_driver = {
> .driver_features= DRIVER_MODESET | DRIVER_GEM |
> DRIVER_ATOMIC,
>
> - .prime_handle_to_fd = drm_gem_prime_handle_to_fd,
> - .prime_fd_to_handle = drm_gem_prime_fd_to_handle,
> - .gem_prime_export = drm_gem_prime_export,
> - .gem_prime_import = drm_gem_prime_import,
> - .gem_prime_get_sg_table = drm_gem_cma_prime_get_sg_table,
> - .gem_prime_import_sg_table = drm_gem_cma_prime_import_sg_table,
> - .gem_prime_vmap = drm_gem_cma_prime_vmap,
> - .gem_prime_vunmap = drm_gem_cma_prime_vunmap,
> - .gem_prime_mmap = drm_gem_cma_prime_mmap,
> - .gem_free_object_unlocked = drm_gem_cma_free_object,
> - .gem_vm_ops = _gem_cma_vm_ops,
> - .dumb_create= zynqmp_dpsub_dumb_create,
> - .dumb_destroy = drm_gem_dumb_destroy,
> + DRM_GEM_CMA_DRIVER_OPS_VMAP_WITH_DUMB_CREATE(zynqmp_dpsub_dumb_create),
The only effective change here is
- .gem_prime_import_sg_table = drm_gem_cma_prime_import_sg_table,
- .gem_prime_mmap = drm_gem_cma_prime_mmap,
+ .gem_prime_import_sg_table =
drm_gem_cma_prime_import_sg_table_vmap,
+ .gem_prime_mmap = drm_gem_prime_mmap,
The change is significant, and I have a hard time following the code to
verify that it's correct, or if it's an undesired side effect. If it's
correct, could the change be mentioned in the commit message, with at
least a brief explanation of why this is correct, and what the
consequences here ?
>
> .fops = _dpsub_drm_fops,
>
--
Regards,
Laurent Pinchart
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 12/25] drm/rcar-du: Annotate dma-fence critical section in commit path
Hi Daniel, Thank you for the patch. On Tue, Jul 07, 2020 at 10:12:16PM +0200, Daniel Vetter wrote: > Ends right after drm_atomic_helper_commit_hw_done(), absolutely > nothing fancy going on here. Just looking at this patch and the commit message, I have no idea what this does, and why. It would be nice to expand the commit message to give some more context, and especially explain why ending signalling right after drm_atomic_helper_commit_hw_done() is the right option. I suppose I'll have to check the whole series in the meantime :-) > Signed-off-by: Daniel Vetter > Cc: Laurent Pinchart > Cc: Kieran Bingham > Cc: linux-renesas-...@vger.kernel.org > --- > drivers/gpu/drm/rcar-du/rcar_du_kms.c | 2 ++ > 1 file changed, 2 insertions(+) > > diff --git a/drivers/gpu/drm/rcar-du/rcar_du_kms.c > b/drivers/gpu/drm/rcar-du/rcar_du_kms.c > index 482329102f19..42c5dc588435 100644 > --- a/drivers/gpu/drm/rcar-du/rcar_du_kms.c > +++ b/drivers/gpu/drm/rcar-du/rcar_du_kms.c > @@ -391,6 +391,7 @@ static void rcar_du_atomic_commit_tail(struct > drm_atomic_state *old_state) > struct drm_crtc_state *crtc_state; > struct drm_crtc *crtc; > unsigned int i; > + bool fence_cookie = dma_fence_begin_signalling(); Can this be moved right before the drm_atomic_helper_commit_modeset_disables() call ? > > /* >* Store RGB routing to DPAD0 and DPAD1, the hardware will be configured > @@ -417,6 +418,7 @@ static void rcar_du_atomic_commit_tail(struct > drm_atomic_state *old_state) > drm_atomic_helper_commit_modeset_enables(dev, old_state); > > drm_atomic_helper_commit_hw_done(old_state); > + dma_fence_end_signalling(fence_cookie); > drm_atomic_helper_wait_for_flip_done(dev, old_state); > > drm_atomic_helper_cleanup_planes(dev, old_state); -- Regards, Laurent Pinchart ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/8] drm/atomic-helper: reset vblank on crtc reset
Hi Daniel,
Thank you for the patch.
On Fri, Jun 12, 2020 at 06:00:49PM +0200, Daniel Vetter wrote:
> Only when vblanks are supported ofc.
>
> Some drivers do this already, but most unfortunately missed it. This
> opens up bugs after driver load, before the crtc is enabled for the
> first time. syzbot spotted this when loading vkms as a secondary
> output. Given how many drivers are buggy it's best to solve this once
> and for all in shared helper code.
>
> Aside from moving the few existing calls to drm_crtc_vblank_reset into
> helpers (i915 doesn't use helpers, so keeps its own) I think the
> regression risk is minimal: atomic helpers already rely on drivers
> calling drm_crtc_vblank_on/off correctly in their hooks when they
> support vblanks. And driver that's failing to handle vblanks after
> this is missing those calls already, and vblanks could only work by
> accident when enabling a CRTC for the first time right after boot.
>
> Big thanks to Tetsuo for helping track down what's going wrong here.
>
> There's only a few drivers which already had the necessary call and
> needed some updating:
> - komeda, atmel and tidss also needed to be changed to call
> __drm_atomic_helper_crtc_reset() intead of open coding it
> - tegra and msm even had it in the same place already, just code
> motion, and malidp already uses __drm_atomic_helper_crtc_reset().
Should you mention rcar-du and omapdrm here ?
> Only call left is in i915, which doesn't use drm_mode_config_reset,
> but has its own fastboot infrastructure. So that's the only case where
> we actually want this in the driver still.
>
> I've also reviewed all other drivers which set up vblank support with
> drm_vblank_init. After the previous patch fixing mxsfb all atomic
> drivers do call drm_crtc_vblank_on/off as they should, the remaining
> drivers are either legacy kms or legacy dri1 drivers, so not affected
> by this change to atomic helpers.
>
> v2: Use the drm_dev_has_vblank() helper.
>
> v3: Laurent pointed out that omap and rcar-du used drm_crtc_vblank_off
> instead of drm_crtc_vblank_reset. Adjust them too.
>
> v4: Laurent noticed that rcar-du and omap open-code their crtc reset
> and hence would actually be broken by this patch now. So fix them up
> by reusing the helpers, which brings the drm_crtc_vblank_reset() back.
>
> Cc: Laurent Pinchart
> Reviewed-by: Boris Brezillon
> Acked-by: Liviu Dudau
> Acked-by: Thierry Reding
> Link:
> https://syzkaller.appspot.com/bug?id=0ba17d70d062b2595e1f061231474800f076c7cb
> Reported-by: Tetsuo Handa
> Reported-by: syzbot+0871b14ca2e2fb64f...@syzkaller.appspotmail.com
> Cc: Tetsuo Handa
> Cc: "James (Qian) Wang"
> Cc: Liviu Dudau
> Cc: Mihail Atanassov
> Cc: Brian Starkey
> Cc: Sam Ravnborg
> Cc: Boris Brezillon
> Cc: Nicolas Ferre
> Cc: Alexandre Belloni
> Cc: Ludovic Desroches
> Cc: Maarten Lankhorst
> Cc: Maxime Ripard
> Cc: Thomas Zimmermann
> Cc: David Airlie
> Cc: Daniel Vetter
> Cc: Thierry Reding
> Cc: Jonathan Hunter
> Cc: Jyri Sarha
> Cc: Tomi Valkeinen
> Cc: Rob Clark
> Cc: Sean Paul
> Cc: Brian Masney
> Cc: Emil Velikov
> Cc: zhengbin
> Cc: Thomas Gleixner
> Cc: linux-te...@vger.kernel.org
> Cc: Kieran Bingham
> Cc: linux-arm-ker...@lists.infradead.org
> Cc: linux-renesas-...@vger.kernel.org
> Signed-off-by: Daniel Vetter
> ---
> drivers/gpu/drm/arm/display/komeda/komeda_crtc.c | 7 ++-
> drivers/gpu/drm/arm/malidp_drv.c | 1 -
> drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c | 7 ++-
> drivers/gpu/drm/drm_atomic_state_helper.c| 4
> drivers/gpu/drm/msm/disp/mdp5/mdp5_crtc.c| 2 --
> drivers/gpu/drm/omapdrm/omap_crtc.c | 8 +---
> drivers/gpu/drm/omapdrm/omap_drv.c | 4
> drivers/gpu/drm/rcar-du/rcar_du_crtc.c | 6 +-
> drivers/gpu/drm/tegra/dc.c | 1 -
> drivers/gpu/drm/tidss/tidss_crtc.c | 3 +--
> drivers/gpu/drm/tidss/tidss_kms.c| 4
> 11 files changed, 15 insertions(+), 32 deletions(-)
>
> diff --git a/drivers/gpu/drm/arm/display/komeda/komeda_crtc.c
> b/drivers/gpu/drm/arm/display/komeda/komeda_crtc.c
> index 56bd938961ee..f33418d6e1a0 100644
> --- a/drivers/gpu/drm/arm/display/komeda/komeda_crtc.c
> +++ b/drivers/gpu/drm/arm/display/komeda/komeda_crtc.c
> @@ -492,10 +492,8 @@ static void komeda_crtc_reset(struct drm_crtc *crtc)
> crtc->state = NULL;
>
> state = kzalloc(sizeof(*state), GFP_KERNEL);
> - if (state) {
> - crtc->state = >base;
> - crtc->state->crtc = crtc;
> - }
> + if (state)
> +
Re: [Intel-gfx] [PATCH 1/3] drm/atomic-helper: reset vblank on crtc reset
Hi Daniel,
Thank you for the patch.
May I remind you about the -v option to git-format-patch ? :-) Seriously
speaking, it really helps review.
On Tue, Jun 02, 2020 at 11:51:38AM +0200, Daniel Vetter wrote:
> Only when vblanks are supported ofc.
>
> Some drivers do this already, but most unfortunately missed it. This
> opens up bugs after driver load, before the crtc is enabled for the
> first time. syzbot spotted this when loading vkms as a secondary
> output. Given how many drivers are buggy it's best to solve this once
> and for all in shared helper code.
>
> Aside from moving the few existing calls to drm_crtc_vblank_reset into
> helpers (i915 doesn't use helpers, so keeps its own) I think the
> regression risk is minimal: atomic helpers already rely on drivers
> calling drm_crtc_vblank_on/off correctly in their hooks when they
> support vblanks. And driver that's failing to handle vblanks after
> this is missing those calls already, and vblanks could only work by
> accident when enabling a CRTC for the first time right after boot.
>
> Big thanks to Tetsuo for helping track down what's going wrong here.
>
> There's only a few drivers which already had the necessary call and
> needed some updating:
> - komeda, atmel and tidss also needed to be changed to call
> __drm_atomic_helper_crtc_reset() intead of open coding it
> - tegra and msm even had it in the same place already, just code
> motion, and malidp already uses __drm_atomic_helper_crtc_reset().
>
> Only call left is in i915, which doesn't use drm_mode_config_reset,
> but has its own fastboot infrastructure. So that's the only case where
> we actually want this in the driver still.
>
> I've also reviewed all other drivers which set up vblank support with
> drm_vblank_init. After the previous patch fixing mxsfb all atomic
> drivers do call drm_crtc_vblank_on/off as they should, the remaining
> drivers are either legacy kms or legacy dri1 drivers, so not affected
> by this change to atomic helpers.
>
> v2: Use the drm_dev_has_vblank() helper.
>
> v3: Laurent pointed out that omap and rcar-du used drm_crtc_vblank_off
> instead of drm_crtc_vblank_reset. Adjust them too.
>
> Cc: Laurent Pinchart
> Reviewed-by: Laurent Pinchart
> Reviewed-by: Boris Brezillon
> Acked-by: Liviu Dudau
> Acked-by: Thierry Reding
> Link:
> https://syzkaller.appspot.com/bug?id=0ba17d70d062b2595e1f061231474800f076c7cb
> Reported-by: Tetsuo Handa
> Reported-by: syzbot+0871b14ca2e2fb64f...@syzkaller.appspotmail.com
> Cc: Tetsuo Handa
> Cc: "James (Qian) Wang"
> Cc: Liviu Dudau
> Cc: Mihail Atanassov
> Cc: Brian Starkey
> Cc: Sam Ravnborg
> Cc: Boris Brezillon
> Cc: Nicolas Ferre
> Cc: Alexandre Belloni
> Cc: Ludovic Desroches
> Cc: Maarten Lankhorst
> Cc: Maxime Ripard
> Cc: Thomas Zimmermann
> Cc: David Airlie
> Cc: Daniel Vetter
> Cc: Thierry Reding
> Cc: Jonathan Hunter
> Cc: Jyri Sarha
> Cc: Tomi Valkeinen
> Cc: Rob Clark
> Cc: Sean Paul
> Cc: Brian Masney
> Cc: Emil Velikov
> Cc: zhengbin
> Cc: Thomas Gleixner
> Cc: linux-te...@vger.kernel.org
> Signed-off-by: Daniel Vetter
> ---
> drivers/gpu/drm/arm/display/komeda/komeda_crtc.c | 7 ++-
> drivers/gpu/drm/arm/malidp_drv.c | 1 -
> drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c | 7 ++-
> drivers/gpu/drm/drm_atomic_state_helper.c| 4
> drivers/gpu/drm/msm/disp/mdp5/mdp5_crtc.c| 2 --
> drivers/gpu/drm/omapdrm/omap_drv.c | 3 ---
> drivers/gpu/drm/rcar-du/rcar_du_crtc.c | 3 ---
> drivers/gpu/drm/tegra/dc.c | 1 -
> drivers/gpu/drm/tidss/tidss_crtc.c | 3 +--
> drivers/gpu/drm/tidss/tidss_kms.c| 4
> 10 files changed, 9 insertions(+), 26 deletions(-)
>
> diff --git a/drivers/gpu/drm/arm/display/komeda/komeda_crtc.c
> b/drivers/gpu/drm/arm/display/komeda/komeda_crtc.c
> index 56bd938961ee..f33418d6e1a0 100644
> --- a/drivers/gpu/drm/arm/display/komeda/komeda_crtc.c
> +++ b/drivers/gpu/drm/arm/display/komeda/komeda_crtc.c
> @@ -492,10 +492,8 @@ static void komeda_crtc_reset(struct drm_crtc *crtc)
> crtc->state = NULL;
>
> state = kzalloc(sizeof(*state), GFP_KERNEL);
> - if (state) {
> - crtc->state = >base;
> - crtc->state->crtc = crtc;
> - }
> + if (state)
> + __drm_atomic_helper_crtc_reset(crtc, >base);
> }
>
> static struct drm_crtc_state *
> @@ -616,7 +614,6 @@ static int komeda_crtc_add(struct komeda_kms_dev *kms,
> return err;
>
> drm_crtc_helper_add(crtc, _crtc_helper_funcs);
> - drm_crtc_vb
Re: [Intel-gfx] [PATCH] drm/atomic-helper: reset vblank on crtc reset
Hi Daniel,
Thank you for the patch.
On Wed, May 27, 2020 at 11:53:32AM +0200, Daniel Vetter wrote:
> Only when vblanks are supported ofc.
>
> Some drivers do this already, but most unfortunately missed it. This
> opens up bugs after driver load, before the crtc is enabled for the
> first time. syzbot spotted this when loading vkms as a secondary
> output. Given how many drivers are buggy it's best to solve this once
> and for all in shared helper code.
>
> Aside from moving the few existing calls to drm_crtc_vblank_reset into
> helpers (i915 doesn't use helpers, so keeps its own) I think the
> regression risk is minimal: atomic helpers already rely on drivers
> calling drm_crtc_vblank_on/off correctly in their hooks when they
> support vblanks. And driver that's failing to handle vblanks after
> this is missing those calls already, and vblanks could only work by
> accident when enabling a CRTC for the first time right after boot.
>
> Big thanks to Tetsuo for helping track down what's going wrong here.
>
> There's only a few drivers which already had the necessary call and
> needed some updating:
> - komeda, atmel and tidss also needed to be changed to call
> __drm_atomic_helper_crtc_reset() intead of open coding it
> - tegra and msm even had it in the same place already, just code
> motion, and malidp already uses __drm_atomic_helper_crtc_reset().
Have you intentionally not touched drivers that use
drm_crtc_vblank_off() at init time instead of drm_crtc_vblank_reset() ?
I'm thinking about omapdrm and rcar-du that both call neither
drm_crtc_vblank_reset() nor __drm_atomic_helper_crtc_reset() in their
CRTC reset handler, and call drm_crtc_vblank_off() at init time. Should
these (and likely other) drivers be updated ?
Other than that the patch looks good to me,
Reviewed-by: Laurent Pinchart
> Only call left is in i915, which doesn't use drm_mode_config_reset,
> but has its own fastboot infrastructure. So that's the only case where
> we actually want this in the driver still.
>
> I've also reviewed all other drivers which set up vblank support with
> drm_vblank_init. After the previous patch fixing mxsfb all atomic
> drivers do call drm_crtc_vblank_on/off as they should, the remaining
> drivers are either legacy kms or legacy dri1 drivers, so not affected
> by this change to atomic helpers.
>
> v2: Use the drm_dev_has_vblank() helper.
>
> Link:
> https://syzkaller.appspot.com/bug?id=0ba17d70d062b2595e1f061231474800f076c7cb
> Reported-by: Tetsuo Handa
> Reported-by: syzbot+0871b14ca2e2fb64f...@syzkaller.appspotmail.com
> Cc: Tetsuo Handa
> Cc: "James (Qian) Wang"
> Cc: Liviu Dudau
> Cc: Mihail Atanassov
> Cc: Brian Starkey
> Cc: Sam Ravnborg
> Cc: Boris Brezillon
> Cc: Nicolas Ferre
> Cc: Alexandre Belloni
> Cc: Ludovic Desroches
> Cc: Maarten Lankhorst
> Cc: Maxime Ripard
> Cc: Thomas Zimmermann
> Cc: David Airlie
> Cc: Daniel Vetter
> Cc: Thierry Reding
> Cc: Jonathan Hunter
> Cc: Jyri Sarha
> Cc: Tomi Valkeinen
> Cc: Rob Clark
> Cc: Sean Paul
> Cc: Brian Masney
> Cc: Emil Velikov
> Cc: zhengbin
> Cc: Thomas Gleixner
> Cc: linux-te...@vger.kernel.org
> Signed-off-by: Daniel Vetter
> ---
> drivers/gpu/drm/arm/display/komeda/komeda_crtc.c | 7 ++-
> drivers/gpu/drm/arm/malidp_drv.c | 1 -
> drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c | 7 ++-
> drivers/gpu/drm/drm_atomic_state_helper.c| 4
> drivers/gpu/drm/msm/disp/mdp5/mdp5_crtc.c| 2 --
> drivers/gpu/drm/tegra/dc.c | 1 -
> drivers/gpu/drm/tidss/tidss_crtc.c | 3 +--
> drivers/gpu/drm/tidss/tidss_kms.c| 4
> 8 files changed, 9 insertions(+), 20 deletions(-)
>
> diff --git a/drivers/gpu/drm/arm/display/komeda/komeda_crtc.c
> b/drivers/gpu/drm/arm/display/komeda/komeda_crtc.c
> index 56bd938961ee..f33418d6e1a0 100644
> --- a/drivers/gpu/drm/arm/display/komeda/komeda_crtc.c
> +++ b/drivers/gpu/drm/arm/display/komeda/komeda_crtc.c
> @@ -492,10 +492,8 @@ static void komeda_crtc_reset(struct drm_crtc *crtc)
> crtc->state = NULL;
>
> state = kzalloc(sizeof(*state), GFP_KERNEL);
> - if (state) {
> - crtc->state = >base;
> - crtc->state->crtc = crtc;
> - }
> + if (state)
> + __drm_atomic_helper_crtc_reset(crtc, >base);
> }
>
> static struct drm_crtc_state *
> @@ -616,7 +614,6 @@ static int komeda_crtc_add(struct komeda_kms_dev *kms,
> return err;
>
> drm_crtc_helper_add(crtc, _crtc_helper_funcs);
> - drm_crtc_vblank_reset(crtc);
>
> crtc->port = kcrtc->master->of_output_port;
Re: [Intel-gfx] [PATCH] drm: Fix page flip ioctl format check
Hi Ville,
Thank you for the patch.
On Thu, Apr 16, 2020 at 08:04:20PM +0300, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> Revert back to comparing fb->format->format instead fb->format for the
> page flip ioctl. This check was originally only here to disallow pixel
> format changes, but when we changed it to do the pointer comparison
> we potentially started to reject some (but definitely not all) modifier
> changes as well. In fact the current behaviour depends on whether the
> driver overrides the format info for a specific format+modifier combo.
> Eg. on i915 this now rejects compression vs. no compression changes but
> does not reject any other tiling changes. That's just inconsistent
> nonsense.
>
> The main reason we have to go back to the old behaviour is to fix page
> flipping with Xorg. At some point Xorg got its atomic rights taken away
> and since then we can't page flip between compressed and non-compressed
> fbs on i915. Currently we get no page flipping for any games pretty much
> since Mesa likes to use compressed buffers. Not sure how compositors are
> working around this (don't use one myself). I guess they must be doing
> something to get non-compressed buffers instead. Either that or
> somehow no one noticed the tearing from the blit fallback.
>
> Looking back at the original discussion on this change we pretty much
> just did it in the name of skipping a few extra pointer dereferences.
> However, I've decided not to revert the whole thing in case someone
> has since started to depend on these changes. None of the other checks
> are relevant for i915 anyways.
Do display controller usually support changing modifiers for page flips
? I understand from the information about that i915 does, but is that
usual ? Could there be drivers that really on this check to reject
modifier changes, and that aren't prepared to handle them if they are
not rejected by the core ? I'm not opposed to this change, but I'd like
to carefully consider the fallout.
> Cc: sta...@vger.kernel.org
> Cc: Laurent Pinchart
> Fixes: dbd4d5761e1f ("drm: Replace 'format->format' comparisons to just
> 'format' comparisons")
> Signed-off-by: Ville Syrjälä
> ---
> drivers/gpu/drm/drm_plane.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/drm_plane.c b/drivers/gpu/drm/drm_plane.c
> index d6ad60ab0d38..f2ca5315f23b 100644
> --- a/drivers/gpu/drm/drm_plane.c
> +++ b/drivers/gpu/drm/drm_plane.c
> @@ -1153,7 +1153,7 @@ int drm_mode_page_flip_ioctl(struct drm_device *dev,
> if (ret)
> goto out;
>
> - if (old_fb->format != fb->format) {
> + if (old_fb->format->format != fb->format->format) {
> DRM_DEBUG_KMS("Page flip is not allowed to change frame buffer
> format.\n");
> ret = -EINVAL;
> goto out;
--
Regards,
Laurent Pinchart
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 02/44] drm: Add devm_drm_dev_alloc macro
Hi Daniel,
Thank you for the patch.
On Fri, Apr 03, 2020 at 03:57:46PM +0200, Daniel Vetter wrote:
> The kerneldoc is only added for this new function. Existing kerneldoc
> and examples will be udated at the very end, since once all drivers
> are converted over to devm_drm_dev_alloc we can unexport a lot of
> interim functions and make the documentation for driver authors a lot
> cleaner and less confusing. There will be only one true way to
> initialize a drm_device at the end of this, which is going to be
> devm_drm_dev_alloc.
How about drivers that expose another interface towards userspace ? If
the other related subsystem also required allocation of the driver
private structure through its corresponding API, we'd be stuck. As
stated before, I want this API to be optional.
> Cc: Paul Kocialkowski
> Cc: Laurent Pinchart
> Signed-off-by: Daniel Vetter
> ---
> drivers/gpu/drm/drm_drv.c | 23 +++
> include/drm/drm_drv.h | 33 +
> 2 files changed, 56 insertions(+)
>
> diff --git a/drivers/gpu/drm/drm_drv.c b/drivers/gpu/drm/drm_drv.c
> index 1bb4f636b83c..9e60b784b3ac 100644
> --- a/drivers/gpu/drm/drm_drv.c
> +++ b/drivers/gpu/drm/drm_drv.c
> @@ -739,6 +739,29 @@ int devm_drm_dev_init(struct device *parent,
> }
> EXPORT_SYMBOL(devm_drm_dev_init);
>
> +void* __devm_drm_dev_alloc(struct device *parent, struct drm_driver *driver,
> +size_t size, size_t offset)
> +{
> + void *container;
> + struct drm_device *drm;
> + int ret;
> +
> + container = kzalloc(size, GFP_KERNEL);
> + if (!container)
> + return ERR_PTR(-ENOMEM);
> +
> + drm = container + offset;
> + ret = devm_drm_dev_init(parent, drm, driver);
> + if (ret) {
> + kfree(container);
> + return ERR_PTR(ret);
> + }
> + drmm_add_final_kfree(drm, container);
> +
> + return container;
> +}
> +EXPORT_SYMBOL(__devm_drm_dev_alloc);
> +
> /**
> * drm_dev_alloc - Allocate new DRM device
> * @driver: DRM driver to allocate device for
> diff --git a/include/drm/drm_drv.h b/include/drm/drm_drv.h
> index e7c6ea261ed1..26776be5a21e 100644
> --- a/include/drm/drm_drv.h
> +++ b/include/drm/drm_drv.h
> @@ -626,6 +626,39 @@ int devm_drm_dev_init(struct device *parent,
> struct drm_device *dev,
> struct drm_driver *driver);
>
> +void* __devm_drm_dev_alloc(struct device *parent, struct drm_driver *driver,
> +size_t size, size_t offset);
> +
> +/**
> + * devm_drm_dev_alloc - Resource managed allocation of a _device instance
> + * @parent: Parent device object
> + * @driver: DRM driver
> + * @type: the type of the struct which contains struct _device
> + * @member: the name of the _device within @type.
> + *
> + * This allocates and initialize a new DRM device. No device registration is
> done.
> + * Call drm_dev_register() to advertice the device to user space and
> register it
> + * with other core subsystems. This should be done last in the device
> + * initialization sequence to make sure userspace can't access an
> inconsistent
> + * state.
> + *
> + * The initial ref-count of the object is 1. Use drm_dev_get() and
> + * drm_dev_put() to take and drop further ref-counts.
> + *
> + * It is recommended that drivers embed drm_device into their own
> device
> + * structure.
> + *
> + * Note that this manages the lifetime of the resulting _device
> + * automatically using devres. The DRM device initialized with this function
> is
> + * automatically put on driver detach using drm_dev_put().
> + *
> + * RETURNS:
> + * Pointer to new DRM device, or ERR_PTR on failure.
> + */
> +#define devm_drm_dev_alloc(parent, driver, type, member) \
> + ((type *) __devm_drm_dev_alloc(parent, driver, sizeof(type), \
> +offsetof(type, member)))
> +
> struct drm_device *drm_dev_alloc(struct drm_driver *driver,
>struct device *parent);
> int drm_dev_register(struct drm_device *dev, unsigned long flags);
--
Regards,
Laurent Pinchart
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2 03/17] drm: Nuke mode->vrefresh
Hi Ville,
Thank you for the patch.
On Fri, Apr 03, 2020 at 11:39:54PM +0300, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> Get rid of mode->vrefresh and just calculate it on demand. Saves
> a bit of space and avoids the cached value getting out of sync
> with reality.
>
> Mostly done with cocci, with the following manual fixups:
> - Remove the now empty loop in drm_helper_probe_single_connector_modes()
> - Fix __MODE() macro in ch7006_mode.c
> - Fix DRM_MODE_ARG() macro in drm_modes.h
> - Remove leftover comment from samsung_s6d16d0_mode
> - Drop the TODO
>
> @@
> @@
> struct drm_display_mode {
> ...
> - int vrefresh;
> ...
> };
>
> @@
> identifier N;
> expression E;
> @@
> struct drm_display_mode N = {
> - .vrefresh = E
> };
>
> @@
> identifier N;
> expression E;
> @@
> struct drm_display_mode N[...] = {
> ...,
> {
> - .vrefresh = E
> }
> ,...
> };
>
> @@
> expression E;
> @@
> {
> DRM_MODE(...),
> - .vrefresh = E,
> }
>
> @@
> identifier M, R;
> @@
> int drm_mode_vrefresh(const struct drm_display_mode *M)
> {
> ...
> - if (M->vrefresh > 0)
> - R = M->vrefresh;
> - else
> if (...) {
> ...
> }
> ...
> }
>
> @@
> struct drm_display_mode *p;
> expression E;
> @@
> (
> - p->vrefresh = E;
> |
> - p->vrefresh
> + drm_mode_vrefresh(p)
> )
>
> @@
> struct drm_display_mode s;
> expression E;
> @@
> (
> - s.vrefresh = E;
> |
> - s.vrefresh
> + drm_mode_vrefresh()
> )
>
> @@
> expression E;
> @@
> - drm_mode_vrefresh(E) ? drm_mode_vrefresh(E) : drm_mode_vrefresh(E)
> + drm_mode_vrefresh(E)
>
> @find_substruct@
> identifier X;
> identifier S;
> @@
> struct X {
> ...
> struct drm_display_mode S;
> ...
> };
>
> @@
> identifier find_substruct.S;
> expression E;
> identifier I;
> @@
> {
> .S = {
> - .vrefresh = E
> }
> }
>
> @@
> identifier find_substruct.S;
> identifier find_substruct.X;
> expression E;
> identifier I;
> @@
> struct X I[...] = {
> ...,
> .S = {
> - .vrefresh = E
> }
> ,...
> };
>
> v2: Drop TODO
>
> Cc: Andrzej Hajda
> Cc: Neil Armstrong
> Cc: Laurent Pinchart
> Cc: Jonas Karlman
> Cc: Jernej Skrabec
> Cc: Inki Dae
> Cc: Joonyoung Shim
> Cc: Seung-Woo Kim
> Cc: Kyungmin Park
> Cc: Linus Walleij
> Cc: CK Hu
> Cc: Philipp Zabel
> Cc: Ben Skeggs
> Cc: Thierry Reding
> Cc: Sam Ravnborg
> Cc: Jerry Han
> Cc: Icenowy Zheng
> Cc: Jagan Teki
> Cc: Stefan Mavrodiev
> Cc: Robert Chiras
> Cc: "Guido Günther"
> Cc: Purism Kernel Team
> Cc: Benjamin Gaignard
> Cc: Vincent Abriou
> Cc: VMware Graphics
> Cc: Thomas Hellstrom
> Cc: linux-amlo...@lists.infradead.org
> Cc: nouv...@lists.freedesktop.org
> Reviewed-by: Emil Velikov
> Reviewed-by: Sam Ravnborg
> Acked-by: Linus Walleij
> Signed-off-by: Ville Syrjälä
> ---
> Documentation/gpu/todo.rst| 20 --
> drivers/gpu/drm/bridge/sii902x.c | 2 +-
> drivers/gpu/drm/drm_client_modeset.c | 2 +-
> drivers/gpu/drm/drm_edid.c| 328 +-
> drivers/gpu/drm/drm_modes.c | 9 +-
> drivers/gpu/drm/drm_probe_helper.c| 3 -
> drivers/gpu/drm/exynos/exynos_hdmi.c | 5 +-
> drivers/gpu/drm/exynos/exynos_mixer.c | 2 +-
> drivers/gpu/drm/i2c/ch7006_mode.c | 1 -
> drivers/gpu/drm/i915/display/intel_display.c | 1 -
> .../drm/i915/display/intel_display_debugfs.c | 4 +-
> drivers/gpu/drm/i915/display/intel_dp.c | 10 +-
> drivers/gpu/drm/i915/display/intel_tv.c | 3 -
> drivers/gpu/drm/mcde/mcde_dsi.c | 6 +-
> drivers/gpu/drm/mediatek/mtk_drm_crtc.c | 4 +-
> drivers/gpu/drm/mediatek/mtk_hdmi.c | 2 +-
> drivers/gpu/drm/meson/meson_venc_cvbs.c | 2 -
> drivers/gpu/drm/nouveau/nouveau_connector.c | 5 +-
> drivers/gpu/drm/panel/panel-arm-versatile.c | 4 -
> drivers/gpu/drm/panel/panel-boe-himax8279d.c | 3 +-
> .../gpu/drm/panel/panel-boe-tv101wum-nl6.c| 6 +-
> drivers/gpu/drm/panel/panel-elida-kd35t133.c | 3 +-
> .../gpu/drm/panel/panel-feixin-k101-im2ba02.c | 3 +-
> .../drm/panel/panel-feiyang-fy07024di26a30d.c | 3 +-
> drivers/gpu/drm/panel/panel-ilitek-ili9322.c | 7 -
> drivers/gpu/drm/panel/panel-ilitek-ili9881c.c | 3 +-
> drivers/gpu/drm/panel/panel-innolux-p079zca.c | 4 +-
> .../gpu/drm/panel/panel-jdi-lt070me05000.c| 3 +-
Re: [Intel-gfx] [PATCH 19/51] drm: Cleanups after drmm_add_final_kfree rollout
Hi Daniel,
On Thu, Apr 02, 2020 at 07:17:40AM +0200, Daniel Vetter wrote:
> On Thu, Apr 2, 2020 at 2:50 AM Laurent Pinchart wrote:
> > On Mon, Mar 23, 2020 at 03:49:18PM +0100, Daniel Vetter wrote:
> > > A few things:
> > > - Update the example driver in the documentation.
> > > - We can drop the old kfree in drm_dev_release.
> > > - Add a WARN_ON check in drm_dev_register to make sure everyone calls
> > > drmm_add_final_kfree and there's no leaks.
> > >
> > > v2: Restore the full cleanup, I accidentally left some moved code
> > > behind when fixing the bisectability of the series.
> > >
> > > Acked-by: Sam Ravnborg
> > > Acked-by: Thomas Zimmermann
> > > Cc: Sam Ravnborg
> > > Cc: Dan Carpenter
> > > Signed-off-by: Daniel Vetter
> > > ---
> > > drivers/gpu/drm/drm_drv.c | 12 +---
> > > 1 file changed, 5 insertions(+), 7 deletions(-)
> > >
> > > diff --git a/drivers/gpu/drm/drm_drv.c b/drivers/gpu/drm/drm_drv.c
> > > index 877ded348b6e..7f9d7ea543a0 100644
> > > --- a/drivers/gpu/drm/drm_drv.c
> > > +++ b/drivers/gpu/drm/drm_drv.c
> > > @@ -297,8 +297,6 @@ void drm_minor_release(struct drm_minor *minor)
> > > *
> > > * drm_mode_config_cleanup(drm);
> > > * drm_dev_fini(drm);
> > > - * kfree(priv->userspace_facing);
> > > - * kfree(priv);
> > > * }
> > > *
> > > * static struct drm_driver driver_drm_driver = {
> > > @@ -326,10 +324,11 @@ void drm_minor_release(struct drm_minor *minor)
> > > * kfree(drm);
> > > * return ret;
> > > * }
> > > + * drmm_add_final_kfree(drm, priv);
> > > *
> > > * drm_mode_config_init(drm);
> > > *
> > > - * priv->userspace_facing = kzalloc(..., GFP_KERNEL);
> > > + * priv->userspace_facing = drmm_kzalloc(..., GFP_KERNEL);
> > > * if (!priv->userspace_facing)
> > > * return -ENOMEM;
> > > *
> > > @@ -837,10 +836,7 @@ static void drm_dev_release(struct kref *ref)
> > >
> > > drm_managed_release(dev);
> > >
> > > - if (!dev->driver->release && !dev->managed.final_kfree) {
> > > - WARN_ON(!list_empty(>managed.resources));
> > > - kfree(dev);
> > > - } else if (dev->managed.final_kfree)
> > > + if (dev->managed.final_kfree)
> > > kfree(dev->managed.final_kfree);
> > > }
> > >
> > > @@ -961,6 +957,8 @@ int drm_dev_register(struct drm_device *dev, unsigned
> > > long flags)
> > > if (!driver->load)
> > > drm_mode_config_validate(dev);
> > >
> > > + WARN_ON(!dev->managed.final_kfree);
> >
> > That's too aggressive. Driver freeing their private object in .release()
> > isn't wrong. I'd even go as far as saying that it should be the norm,
> > until we manage to find a better way to handle that (which this series
> > doesn't achieve). Many drivers need to allocate resources at probe time
> > before they get a chance to init the drm device. Those resources must be
> > released in the error handling paths of probe. By requiring
> > drmm_add_final_kfree(), you're making that much more complex. I can't
> > release those resources in the error path anymore after calling
> > drmm_add_final_kfree(), or they will be released twice. And I can't rely
> > on drmm_* to release them in all cases, as the error path may be hit
> > before touching anything drm-related.
> >
> > Until we figure out a good way forward and test it on a significant
> > number of drivers, let's not add WARN_ON() that will be hit with the
> > majority of drivers, forcing them to be converted to something that is
> > clearly half-baked.
>
> Hm, is this conjecture, or did you actually hit this WARN_ON with a
> driver? Because I did audit them all, none should hit this, all are
> fixed up.
I'm sorry, I should have been clear about that. I hit the issue
yesterday after rebasing the Xilinx ZynqMP DPSUB driver. I took Sam's
suggestion to embed struct drm_device instead of allocating it
dynamically, and then hit the WARN_ON. You're of course not responsible
for a driver that is still out-of-tree. I then looked at how to convert
other drivers I work on in a similar way (rcar-du and omapdrm in
particular), and realized it could actually m
Re: [Intel-gfx] [PATCH 19/51] drm: Cleanups after drmm_add_final_kfree rollout
Hi Daniel,
(On a side note, git-format-patch accepts a -v argument to specify the
version, I didn't realize you were not aware of it :-))
On Mon, Mar 23, 2020 at 03:49:18PM +0100, Daniel Vetter wrote:
> A few things:
> - Update the example driver in the documentation.
> - We can drop the old kfree in drm_dev_release.
> - Add a WARN_ON check in drm_dev_register to make sure everyone calls
> drmm_add_final_kfree and there's no leaks.
>
> v2: Restore the full cleanup, I accidentally left some moved code
> behind when fixing the bisectability of the series.
>
> Acked-by: Sam Ravnborg
> Acked-by: Thomas Zimmermann
> Cc: Sam Ravnborg
> Cc: Dan Carpenter
> Signed-off-by: Daniel Vetter
> ---
> drivers/gpu/drm/drm_drv.c | 12 +---
> 1 file changed, 5 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_drv.c b/drivers/gpu/drm/drm_drv.c
> index 877ded348b6e..7f9d7ea543a0 100644
> --- a/drivers/gpu/drm/drm_drv.c
> +++ b/drivers/gpu/drm/drm_drv.c
> @@ -297,8 +297,6 @@ void drm_minor_release(struct drm_minor *minor)
> *
> * drm_mode_config_cleanup(drm);
> * drm_dev_fini(drm);
> - * kfree(priv->userspace_facing);
> - * kfree(priv);
> * }
> *
> * static struct drm_driver driver_drm_driver = {
> @@ -326,10 +324,11 @@ void drm_minor_release(struct drm_minor *minor)
> * kfree(drm);
> * return ret;
> * }
> + * drmm_add_final_kfree(drm, priv);
> *
> * drm_mode_config_init(drm);
> *
> - * priv->userspace_facing = kzalloc(..., GFP_KERNEL);
> + * priv->userspace_facing = drmm_kzalloc(..., GFP_KERNEL);
> * if (!priv->userspace_facing)
> * return -ENOMEM;
> *
> @@ -837,10 +836,7 @@ static void drm_dev_release(struct kref *ref)
>
> drm_managed_release(dev);
>
> - if (!dev->driver->release && !dev->managed.final_kfree) {
> - WARN_ON(!list_empty(>managed.resources));
> - kfree(dev);
> - } else if (dev->managed.final_kfree)
> + if (dev->managed.final_kfree)
> kfree(dev->managed.final_kfree);
> }
>
> @@ -961,6 +957,8 @@ int drm_dev_register(struct drm_device *dev, unsigned
> long flags)
> if (!driver->load)
> drm_mode_config_validate(dev);
>
> + WARN_ON(!dev->managed.final_kfree);
That's too aggressive. Driver freeing their private object in .release()
isn't wrong. I'd even go as far as saying that it should be the norm,
until we manage to find a better way to handle that (which this series
doesn't achieve). Many drivers need to allocate resources at probe time
before they get a chance to init the drm device. Those resources must be
released in the error handling paths of probe. By requiring
drmm_add_final_kfree(), you're making that much more complex. I can't
release those resources in the error path anymore after calling
drmm_add_final_kfree(), or they will be released twice. And I can't rely
on drmm_* to release them in all cases, as the error path may be hit
before touching anything drm-related.
Until we figure out a good way forward and test it on a significant
number of drivers, let's not add WARN_ON() that will be hit with the
majority of drivers, forcing them to be converted to something that is
clearly half-baked.
> +
> if (drm_dev_needs_global_mutex(dev))
> mutex_lock(_global_mutex);
>
--
Regards,
Laurent Pinchart
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v7 05/18] video/hdmi: Add Unpack only function for DRM infoframe
OL(hdmi_drm_infoframe_unpack_only);
> >> +
> >> +/**
> >> + * hdmi_drm_infoframe_unpack() - unpack binary buffer to a HDMI DRM
> >> infoframe
> >> + * @frame: HDMI DRM infoframe
> >> + * @buffer: source buffer
> >> + * @size: size of buffer
> >> + *
> >> + * Unpacks the information contained in binary @buffer into a structured
Same here. The difference between the two functions is "information data
block" vs. "information", it's very unclear to the reader without
looking at either the commit message or the implementation.
> >> + * @frame of the HDMI Dynamic Range and Mastering (DRM) information frame.
> >> + * Also verifies the checksum as required by section 5.3.5 of the HDMI 1.4
> >> + * specification.
> >> + *
> >> + * Returns 0 on success or a negative error code on failure.
> >> + */
> >> +static int hdmi_drm_infoframe_unpack(struct hdmi_drm_infoframe *frame,
> >> + const void *buffer, size_t size)
> >> +{
> >> + const u8 *ptr = buffer;
> >> + int ret;
> >> +
> >> + if (size < HDMI_INFOFRAME_SIZE(DRM))
> >> + return -EINVAL;
> >> +
> >> + if (ptr[0] != HDMI_INFOFRAME_TYPE_DRM ||
> >> + ptr[1] != 1 ||
> >> + ptr[2] != HDMI_DRM_INFOFRAME_SIZE)
> >> + return -EINVAL;
> >> +
> >> + if (hdmi_infoframe_checksum(buffer, HDMI_INFOFRAME_SIZE(DRM)) != 0)
> >> + return -EINVAL;
> >> +
> >> + ret = hdmi_drm_infoframe_unpack_only(frame, ptr +
> >> HDMI_INFOFRAME_HEADER_SIZE,
> >> + size - HDMI_INFOFRAME_HEADER_SIZE);
> >> + return ret;
> >> +}
> >>
> >> /**
> >> * hdmi_infoframe_unpack() - unpack binary buffer to a HDMI infoframe
> >> diff --git a/include/linux/hdmi.h b/include/linux/hdmi.h
> >> index 9918a6c910c5..afb43efc03e0 100644
> >> --- a/include/linux/hdmi.h
> >> +++ b/include/linux/hdmi.h
> >> @@ -219,6 +219,8 @@ ssize_t hdmi_drm_infoframe_pack(struct
> >> hdmi_drm_infoframe *frame, void *buffer,
> >> ssize_t hdmi_drm_infoframe_pack_only(const struct hdmi_drm_infoframe
> >> *frame,
> >> void *buffer, size_t size);
> >> int hdmi_drm_infoframe_check(struct hdmi_drm_infoframe *frame);
> >> +int hdmi_drm_infoframe_unpack_only(struct hdmi_drm_infoframe *frame,
> >> + const void *buffer, size_t size);
> >>
> >> enum hdmi_spd_sdi {
> >>HDMI_SPD_SDI_UNKNOWN,
--
Regards,
Laurent Pinchart
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 6/9] drm/nouveau: Fix unused variable warning
Hi Pankaj,
Thank you for the patch.
On Mon, Mar 02, 2020 at 06:26:46PM +0530, Pankaj Bharadiya wrote:
> nouveau_drm pointer is not getting used anymore in
> nv50_mstm_{register,destroy}_connector functions, hence remove it.
>
> This fixes below warning.
>
> drivers/gpu/drm/nouveau/dispnv50/disp.c: In function
> ‘nv50_mstm_destroy_connector’:
> drivers/gpu/drm/nouveau/dispnv50/disp.c:1263:22: warning: unused variable
> ‘drm’ [-Wunused-variable]
> struct nouveau_drm *drm = nouveau_drm(connector->dev);
> ^~~
> drivers/gpu/drm/nouveau/dispnv50/disp.c: In function
> ‘nv50_mstm_register_connector’:
> drivers/gpu/drm/nouveau/dispnv50/disp.c:1274:22: warning: unused variable
> ‘drm’ [-Wunused-variable]
> struct nouveau_drm *drm = nouveau_drm(connector->dev);
> ^~~
As commented on 7/9, you should squash this with the patch that
introduces the warnings.
> Signed-off-by: Pankaj Bharadiya
> ---
> drivers/gpu/drm/nouveau/dispnv50/disp.c | 3 ---
> 1 file changed, 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/nouveau/dispnv50/disp.c
> b/drivers/gpu/drm/nouveau/dispnv50/disp.c
> index 97dd50e2917d..4e164ad8003f 100644
> --- a/drivers/gpu/drm/nouveau/dispnv50/disp.c
> +++ b/drivers/gpu/drm/nouveau/dispnv50/disp.c
> @@ -1260,7 +1260,6 @@ static void
> nv50_mstm_destroy_connector(struct drm_dp_mst_topology_mgr *mgr,
> struct drm_connector *connector)
> {
> - struct nouveau_drm *drm = nouveau_drm(connector->dev);
> struct nv50_mstc *mstc = nv50_mstc(connector);
>
> drm_connector_unregister(>connector);
> @@ -1271,8 +1270,6 @@ nv50_mstm_destroy_connector(struct
> drm_dp_mst_topology_mgr *mgr,
> static void
> nv50_mstm_register_connector(struct drm_connector *connector)
> {
> - struct nouveau_drm *drm = nouveau_drm(connector->dev);
> -
> drm_connector_register(connector);
> }
>
--
Regards,
Laurent Pinchart
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 9/9] drm/todo: Update drm_fb_helper tasks
Hi Pankaj, Thank you for the patch. On Mon, Mar 02, 2020 at 06:26:49PM +0530, Pankaj Bharadiya wrote: > Remove completed drm_fb_helper tasks from todo list. > > Signed-off-by: Pankaj Bharadiya > --- > Documentation/gpu/todo.rst | 15 --- > 1 file changed, 4 insertions(+), 11 deletions(-) > > diff --git a/Documentation/gpu/todo.rst b/Documentation/gpu/todo.rst > index ccf5e8e34222..98d8782e1440 100644 > --- a/Documentation/gpu/todo.rst > +++ b/Documentation/gpu/todo.rst > @@ -362,17 +362,10 @@ Level: Starter > drm_fb_helper tasks > --- > > -- drm_fb_helper_restore_fbdev_mode_unlocked() should call > restore_fbdev_mode() > - not the _force variant so it can bail out if there is a master. But first > - these igt tests need to be fixed: kms_fbcon_fbt@psr and > - kms_fbcon_fbt@psr-suspend. > - > -- The max connector argument for drm_fb_helper_init() isn't used anymore and > - can be removed. > - > -- The helper doesn't keep an array of connectors anymore so these can be > - removed: drm_fb_helper_single_add_all_connectors(), > - drm_fb_helper_add_one_connector() and drm_fb_helper_remove_one_connector(). > +drm_fb_helper_restore_fbdev_mode_unlocked() should call restore_fbdev_mode() > +not the _force variant so it can bail out if there is a master. But first > +these igt tests need to be fixed: kms_fbcon_fbt@psr and > +kms_fbcon_fbt@psr-suspend. No need to reflow, you can keep the first list entry as-is and just remove the next two. With this fixed, Reviewed-by: Laurent Pinchart > Level: Intermediate > -- Regards, Laurent Pinchart ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 8/9] drm/fb-helper: Remove drm_fb_helper add, add_all and remove connector functions
Hi Pankaj,
Thank you for the patch.
On Mon, Mar 02, 2020 at 06:26:48PM +0530, Pankaj Bharadiya wrote:
> drm_fb_helper_single_add_all_connectors(), drm_fb_helper_add_one_connector()
> and drm_fb_helper_remove_one_connector() doesn't keep an array of
s/doesn't/don't/
> connectors anymore and are just dummy. Now we have no callers to these
> functions hence remove them.
>
> Signed-off-by: Pankaj Bharadiya
I like this :-)
Reviewed-by: Laurent Pinchart
> ---
> include/drm/drm_fb_helper.h | 21 -
> 1 file changed, 21 deletions(-)
>
> diff --git a/include/drm/drm_fb_helper.h b/include/drm/drm_fb_helper.h
> index 62e8dda6d1d1..208dbf87afa3 100644
> --- a/include/drm/drm_fb_helper.h
> +++ b/include/drm/drm_fb_helper.h
> @@ -451,27 +451,6 @@ drm_fbdev_generic_setup(struct drm_device *dev, unsigned
> int preferred_bpp)
>
> #endif
>
> -/* TODO: There's a todo entry to remove these three */
> -static inline int
> -drm_fb_helper_single_add_all_connectors(struct drm_fb_helper *fb_helper)
> -{
> - return 0;
> -}
> -
> -static inline int
> -drm_fb_helper_add_one_connector(struct drm_fb_helper *fb_helper,
> - struct drm_connector *connector)
> -{
> - return 0;
> -}
> -
> -static inline int
> -drm_fb_helper_remove_one_connector(struct drm_fb_helper *fb_helper,
> -struct drm_connector *connector)
> -{
> - return 0;
> -}
> -
> /**
> * drm_fb_helper_remove_conflicting_framebuffers - remove
> firmware-configured framebuffers
> * @a: memory range, users of which are to be removed
--
Regards,
Laurent Pinchart
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 7/9] drm/bridge: remove unused variable warning in tc358764_detach
Hi Pankaj,
Thank you for the patch.
You can squash this with the patch that introduced the issue in the same
series. Otherwise we will be left with a compilation breakage in the
history, which could be annoying when bisecting issues.
On Mon, Mar 02, 2020 at 06:26:47PM +0530, Pankaj Bharadiya wrote:
> drm_device pointer is not getting used in tc358764_detach() anymore,
> hence remove it.
>
> This fixes below warning.
>
> drivers/gpu/drm/bridge/tc358764.c: In function ‘tc358764_detach’:
> drivers/gpu/drm/bridge/tc358764.c:386:21: warning: unused variable ‘drm’
> [-Wunused-variable]
> struct drm_device *drm = bridge->dev;
> ^~~
>
> Signed-off-by: Pankaj Bharadiya
> ---
> drivers/gpu/drm/bridge/tc358764.c | 1 -
> 1 file changed, 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/bridge/tc358764.c
> b/drivers/gpu/drm/bridge/tc358764.c
> index 530342dd4a34..5ac1430fab04 100644
> --- a/drivers/gpu/drm/bridge/tc358764.c
> +++ b/drivers/gpu/drm/bridge/tc358764.c
> @@ -383,7 +383,6 @@ static int tc358764_attach(struct drm_bridge *bridge,
> static void tc358764_detach(struct drm_bridge *bridge)
> {
> struct tc358764 *ctx = bridge_to_tc358764(bridge);
> - struct drm_device *drm = bridge->dev;
>
> drm_connector_unregister(>connector);
> drm_panel_detach(ctx->panel);
--
Regards,
Laurent Pinchart
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 03/52] drm: add managed resources tied to drm_device
Hi Greg, On Wed, Feb 19, 2020 at 07:19:32PM +0100, Greg Kroah-Hartman wrote: > On Wed, Feb 19, 2020 at 07:36:52PM +0200, Laurent Pinchart wrote: > > On Wed, Feb 19, 2020 at 06:00:46PM +0100, Greg Kroah-Hartman wrote: > >> On Wed, Feb 19, 2020 at 03:22:49PM +0100, Daniel Vetter wrote: > >>> On Wed, Feb 19, 2020 at 2:33 PM Greg Kroah-Hartman wrote: > >>>> On Wed, Feb 19, 2020 at 03:28:47PM +0200, Laurent Pinchart wrote: > >>>>> On Wed, Feb 19, 2020 at 11:20:33AM +0100, Daniel Vetter wrote: > >>>>>> We have lots of these. And the cleanup code tends to be of dubious > >>>>>> quality. The biggest wrong pattern is that developers use devm_, which > >>>>>> ties the release action to the underlying struct device, whereas > >>>>>> all the userspace visible stuff attached to a drm_device can long > >>>>>> outlive that one (e.g. after a hotunplug while userspace has open > >>>>>> files and mmap'ed buffers). Give people what they want, but with more > >>>>>> correctness. > >>>>>> > >>>>>> Mostly copied from devres.c, with types adjusted to fit drm_device and > >>>>>> a few simplifications - I didn't (yet) copy over everything. Since > >>>>>> the types don't match code sharing looked like a hopeless endeavour. > >>>>>> > >>>>>> For now it's only super simplified, no groups, you can't remove > >>>>>> actions (but kfree exists, we'll need that soon). Plus all specific to > >>>>>> drm_device ofc, including the logging. Which I didn't bother to make > >>>>>> compile-time optional, since none of the other drm logging is compile > >>>>>> time optional either. > >>>>>> > >>>>>> One tricky bit here is the chicken between allocating your > >>>>>> drm_device structure and initiliazing it with drm_dev_init. For > >>>>>> perfect onion unwinding we'd need to have the action to kfree the > >>>>>> allocation registered before drm_dev_init registers any of its own > >>>>>> release handlers. But drm_dev_init doesn't know where exactly the > >>>>>> drm_device is emebedded into the overall structure, and by the time it > >>>>>> returns it'll all be too late. And forcing drivers to be able clean up > >>>>>> everything except the one kzalloc is silly. > >>>>>> > >>>>>> Work around this by having a very special final_kfree pointer. This > >>>>>> also avoids troubles with the list head possibly disappearing from > >>>>>> underneath us when we release all resources attached to the > >>>>>> drm_device. > >>>>> > >>>>> This is all a very good idea ! Many subsystems are plagged by drivers > >>>>> using devm_k*alloc to allocate data accessible by userspace. Since the > >>>>> introduction of devm_*, we've likely reduced the number of memory leaks, > >>>>> but I'm pretty sure we've increased the risk of crashes as I've seen > >>>>> some drivers that used .release() callbacks correctly being naively > >>>>> converted to incorrect devm_* usage :-( > >>>>> > >>>>> This leads me to a question: if other subsystems have the same problem, > >>>>> could we turn this implementation into something more generic ? It > >>>>> doesn't have to be done right away and shouldn't block merging this > >>>>> series, but I think it would be very useful. > >>>> > >>>> It shouldn't be that hard to tie this into a drv_m() type of a thing > >>>> (driver_memory?) > >>>> > >>>> And yes, I think it's much better than devm_* for the obvious reasons of > >>>> this being needed here. > >>> > >>> There's two reasons I went with copypasta instead of trying to share code: > >>> - Type checking, I definitely don't want people to mix up devm_ with > >>> drmm_. But even if we do a drv_m that subsystems could embed we do > >>> have quite a few different types of component drivers (and with > >>> drm_panel and drm_bridge even standardized), and I don't want people > >>> to be able to pass the wrong kind of struct to e.g. a managed > >>> drmm_connector_init - it really needs to be the drm_d
Re: [Intel-gfx] [PATCH 03/52] drm: add managed resources tied to drm_device
Hi Greg, On Wed, Feb 19, 2020 at 06:00:46PM +0100, Greg Kroah-Hartman wrote: > On Wed, Feb 19, 2020 at 03:22:49PM +0100, Daniel Vetter wrote: > > On Wed, Feb 19, 2020 at 2:33 PM Greg Kroah-Hartman wrote: > > > On Wed, Feb 19, 2020 at 03:28:47PM +0200, Laurent Pinchart wrote: > > > > On Wed, Feb 19, 2020 at 11:20:33AM +0100, Daniel Vetter wrote: > > > > > We have lots of these. And the cleanup code tends to be of dubious > > > > > quality. The biggest wrong pattern is that developers use devm_, which > > > > > ties the release action to the underlying struct device, whereas > > > > > all the userspace visible stuff attached to a drm_device can long > > > > > outlive that one (e.g. after a hotunplug while userspace has open > > > > > files and mmap'ed buffers). Give people what they want, but with more > > > > > correctness. > > > > > > > > > > Mostly copied from devres.c, with types adjusted to fit drm_device and > > > > > a few simplifications - I didn't (yet) copy over everything. Since > > > > > the types don't match code sharing looked like a hopeless endeavour. > > > > > > > > > > For now it's only super simplified, no groups, you can't remove > > > > > actions (but kfree exists, we'll need that soon). Plus all specific to > > > > > drm_device ofc, including the logging. Which I didn't bother to make > > > > > compile-time optional, since none of the other drm logging is compile > > > > > time optional either. > > > > > > > > > > One tricky bit here is the chicken between allocating your > > > > > drm_device structure and initiliazing it with drm_dev_init. For > > > > > perfect onion unwinding we'd need to have the action to kfree the > > > > > allocation registered before drm_dev_init registers any of its own > > > > > release handlers. But drm_dev_init doesn't know where exactly the > > > > > drm_device is emebedded into the overall structure, and by the time it > > > > > returns it'll all be too late. And forcing drivers to be able clean up > > > > > everything except the one kzalloc is silly. > > > > > > > > > > Work around this by having a very special final_kfree pointer. This > > > > > also avoids troubles with the list head possibly disappearing from > > > > > underneath us when we release all resources attached to the > > > > > drm_device. > > > > > > > > This is all a very good idea ! Many subsystems are plagged by drivers > > > > using devm_k*alloc to allocate data accessible by userspace. Since the > > > > introduction of devm_*, we've likely reduced the number of memory leaks, > > > > but I'm pretty sure we've increased the risk of crashes as I've seen > > > > some drivers that used .release() callbacks correctly being naively > > > > converted to incorrect devm_* usage :-( > > > > > > > > This leads me to a question: if other subsystems have the same problem, > > > > could we turn this implementation into something more generic ? It > > > > doesn't have to be done right away and shouldn't block merging this > > > > series, but I think it would be very useful. > > > > > > It shouldn't be that hard to tie this into a drv_m() type of a thing > > > (driver_memory?) > > > > > > And yes, I think it's much better than devm_* for the obvious reasons of > > > this being needed here. > > > > There's two reasons I went with copypasta instead of trying to share code: > > - Type checking, I definitely don't want people to mix up devm_ with > > drmm_. But even if we do a drv_m that subsystems could embed we do > > have quite a few different types of component drivers (and with > > drm_panel and drm_bridge even standardized), and I don't want people > > to be able to pass the wrong kind of struct to e.g. a managed > > drmm_connector_init - it really needs to be the drm_device, not a > > panel or bridge or something else. > > Fair enough, that makes sense. > > > - We could still share the code as a kind of implementation/backend > > library. But it's not much, and with embedding I could use the drm > > device logging stuff which is kinda nice. But if there's more demand > > for this I can definitely see the point in sharing this, as Laurent > > pointed out with the tiny optimization with not allocating a NULL void > > * th
Re: [Intel-gfx] [PATCH 03/52] drm: add managed resources tied to drm_device
Hi Daniel, On Wed, Feb 19, 2020 at 05:53:59PM +0100, Daniel Vetter wrote: > On Wed, Feb 19, 2020 at 5:46 PM Laurent Pinchart wrote: > > On Wed, Feb 19, 2020 at 05:22:38PM +0100, Daniel Vetter wrote: > >> On Wed, Feb 19, 2020 at 5:09 PM Emil Velikov wrote: > >>> On Wed, 19 Feb 2020 at 14:23, Daniel Vetter wrote: > >>>> On Wed, Feb 19, 2020 at 2:33 PM Greg Kroah-Hartman wrote: > >>>>> On Wed, Feb 19, 2020 at 03:28:47PM +0200, Laurent Pinchart wrote: > >>>>>> On Wed, Feb 19, 2020 at 11:20:33AM +0100, Daniel Vetter wrote: > >>>>>>> We have lots of these. And the cleanup code tends to be of dubious > >>>>>>> quality. The biggest wrong pattern is that developers use devm_, which > >>>>>>> ties the release action to the underlying struct device, whereas > >>>>>>> all the userspace visible stuff attached to a drm_device can long > >>>>>>> outlive that one (e.g. after a hotunplug while userspace has open > >>>>>>> files and mmap'ed buffers). Give people what they want, but with more > >>>>>>> correctness. > >>>>>>> > >>>>>>> Mostly copied from devres.c, with types adjusted to fit drm_device and > >>>>>>> a few simplifications - I didn't (yet) copy over everything. Since > >>>>>>> the types don't match code sharing looked like a hopeless endeavour. > >>>>>>> > >>>>>>> For now it's only super simplified, no groups, you can't remove > >>>>>>> actions (but kfree exists, we'll need that soon). Plus all specific to > >>>>>>> drm_device ofc, including the logging. Which I didn't bother to make > >>>>>>> compile-time optional, since none of the other drm logging is compile > >>>>>>> time optional either. > >>>>>>> > >>>>>>> One tricky bit here is the chicken between allocating your > >>>>>>> drm_device structure and initiliazing it with drm_dev_init. For > >>>>>>> perfect onion unwinding we'd need to have the action to kfree the > >>>>>>> allocation registered before drm_dev_init registers any of its own > >>>>>>> release handlers. But drm_dev_init doesn't know where exactly the > >>>>>>> drm_device is emebedded into the overall structure, and by the time it > >>>>>>> returns it'll all be too late. And forcing drivers to be able clean up > >>>>>>> everything except the one kzalloc is silly. > >>>>>>> > >>>>>>> Work around this by having a very special final_kfree pointer. This > >>>>>>> also avoids troubles with the list head possibly disappearing from > >>>>>>> underneath us when we release all resources attached to the > >>>>>>> drm_device. > >>>>>> > >>>>>> This is all a very good idea ! Many subsystems are plagged by drivers > >>>>>> using devm_k*alloc to allocate data accessible by userspace. Since the > >>>>>> introduction of devm_*, we've likely reduced the number of memory > >>>>>> leaks, > >>>>>> but I'm pretty sure we've increased the risk of crashes as I've seen > >>>>>> some drivers that used .release() callbacks correctly being naively > >>>>>> converted to incorrect devm_* usage :-( > >>>>>> > >>>>>> This leads me to a question: if other subsystems have the same problem, > >>>>>> could we turn this implementation into something more generic ? It > >>>>>> doesn't have to be done right away and shouldn't block merging this > >>>>>> series, but I think it would be very useful. > >>>>> > >>>>> It shouldn't be that hard to tie this into a drv_m() type of a thing > >>>>> (driver_memory?) > >>>>> > >>>>> And yes, I think it's much better than devm_* for the obvious reasons of > >>>>> this being needed here. > >>>> > >>>> There's two reasons I went with copypasta instead of trying to share > >>>> code: > >>>> - Type checking, I definitely don't want people to mix up devm_ with > >>>> drmm_. But even if we do a drv_m that subsystems could embed we do >
Re: [Intel-gfx] [PATCH 03/52] drm: add managed resources tied to drm_device
Hi Daniel, On Wed, Feb 19, 2020 at 05:22:38PM +0100, Daniel Vetter wrote: > On Wed, Feb 19, 2020 at 5:09 PM Emil Velikov wrote: > > On Wed, 19 Feb 2020 at 14:23, Daniel Vetter wrote: > >> On Wed, Feb 19, 2020 at 2:33 PM Greg Kroah-Hartman wrote: > >>> On Wed, Feb 19, 2020 at 03:28:47PM +0200, Laurent Pinchart wrote: > >>>> On Wed, Feb 19, 2020 at 11:20:33AM +0100, Daniel Vetter wrote: > >>>>> We have lots of these. And the cleanup code tends to be of dubious > >>>>> quality. The biggest wrong pattern is that developers use devm_, which > >>>>> ties the release action to the underlying struct device, whereas > >>>>> all the userspace visible stuff attached to a drm_device can long > >>>>> outlive that one (e.g. after a hotunplug while userspace has open > >>>>> files and mmap'ed buffers). Give people what they want, but with more > >>>>> correctness. > >>>>> > >>>>> Mostly copied from devres.c, with types adjusted to fit drm_device and > >>>>> a few simplifications - I didn't (yet) copy over everything. Since > >>>>> the types don't match code sharing looked like a hopeless endeavour. > >>>>> > >>>>> For now it's only super simplified, no groups, you can't remove > >>>>> actions (but kfree exists, we'll need that soon). Plus all specific to > >>>>> drm_device ofc, including the logging. Which I didn't bother to make > >>>>> compile-time optional, since none of the other drm logging is compile > >>>>> time optional either. > >>>>> > >>>>> One tricky bit here is the chicken between allocating your > >>>>> drm_device structure and initiliazing it with drm_dev_init. For > >>>>> perfect onion unwinding we'd need to have the action to kfree the > >>>>> allocation registered before drm_dev_init registers any of its own > >>>>> release handlers. But drm_dev_init doesn't know where exactly the > >>>>> drm_device is emebedded into the overall structure, and by the time it > >>>>> returns it'll all be too late. And forcing drivers to be able clean up > >>>>> everything except the one kzalloc is silly. > >>>>> > >>>>> Work around this by having a very special final_kfree pointer. This > >>>>> also avoids troubles with the list head possibly disappearing from > >>>>> underneath us when we release all resources attached to the > >>>>> drm_device. > >>>> > >>>> This is all a very good idea ! Many subsystems are plagged by drivers > >>>> using devm_k*alloc to allocate data accessible by userspace. Since the > >>>> introduction of devm_*, we've likely reduced the number of memory leaks, > >>>> but I'm pretty sure we've increased the risk of crashes as I've seen > >>>> some drivers that used .release() callbacks correctly being naively > >>>> converted to incorrect devm_* usage :-( > >>>> > >>>> This leads me to a question: if other subsystems have the same problem, > >>>> could we turn this implementation into something more generic ? It > >>>> doesn't have to be done right away and shouldn't block merging this > >>>> series, but I think it would be very useful. > >>> > >>> It shouldn't be that hard to tie this into a drv_m() type of a thing > >>> (driver_memory?) > >>> > >>> And yes, I think it's much better than devm_* for the obvious reasons of > >>> this being needed here. > >> > >> There's two reasons I went with copypasta instead of trying to share code: > >> - Type checking, I definitely don't want people to mix up devm_ with > >> drmm_. But even if we do a drv_m that subsystems could embed we do > >> have quite a few different types of component drivers (and with > >> drm_panel and drm_bridge even standardized), and I don't want people > >> to be able to pass the wrong kind of struct to e.g. a managed > >> drmm_connector_init - it really needs to be the drm_device, not a > >> panel or bridge or something else. > >> > >> - We could still share the code as a kind of implementation/backend > >> library. But it's not much, and with embedding I could use the drm > >> device logging stuff which is kinda nice. But if there's more demand > >>
Re: [Intel-gfx] [PATCH 27/52] drm: Manage drm_mode_config_init with drmm_
Hi Daniel,
On Wed, Feb 19, 2020 at 04:47:55PM +0100, Daniel Vetter wrote:
> On Wed, Feb 19, 2020 at 2:50 PM Laurent Pinchart wrote:
> > On Wed, Feb 19, 2020 at 11:20:57AM +0100, Daniel Vetter wrote:
> > > drm_mode_config_cleanup is idempotent, so no harm in calling this
> > > twice. This allows us to gradually switch drivers over by removing
> > > explicit drm_mode_config_cleanup calls.
> > >
> > > With this step it's not also possible that (at least for simple
> > > drivers) automatic resource cleanup can be done correctly without a
> > > drm_driver->release hook. Therefore allow this now in
> > > devm_drm_dev_init().
> > >
> > > Also with drmm_ explicit drm_driver->release hooks are kinda not the
> > > best option, so deprecate that hook to discourage future users.
> > >
> > > v2: Fixup the example in the kerneldoc too.
> > >
> > > Cc: "Noralf Trønnes"
> > > Cc: Sam Ravnborg
> > > Cc: Thomas Zimmermann
> > > Signed-off-by: Daniel Vetter
> > > ---
> > > drivers/gpu/drm/drm_drv.c | 21 +
> > > drivers/gpu/drm/drm_mode_config.c | 12 +++-
> > > include/drm/drm_mode_config.h | 2 +-
> > > 3 files changed, 17 insertions(+), 18 deletions(-)
> > >
> > > diff --git a/drivers/gpu/drm/drm_drv.c b/drivers/gpu/drm/drm_drv.c
> > > index 3cf40864d4a6..428c569aaaf1 100644
> > > --- a/drivers/gpu/drm/drm_drv.c
> > > +++ b/drivers/gpu/drm/drm_drv.c
> > > @@ -267,8 +267,7 @@ void drm_minor_release(struct drm_minor *minor)
> > > *
> > > * The following example shows a typical structure of a DRM display
> > > driver.
> > > * The example focus on the probe() function and the other functions
> > > that is
> > > - * almost always present and serves as a demonstration of
> > > devm_drm_dev_init()
> > > - * usage with its accompanying drm_driver->release callback.
> > > + * almost always present and serves as a demonstration of
> > > devm_drm_dev_init().
> > > *
> > > * .. code-block:: c
> > > *
> > > @@ -278,16 +277,8 @@ void drm_minor_release(struct drm_minor *minor)
> > > * struct clk *pclk;
> > > * };
> > > *
> > > - * static void driver_drm_release(struct drm_device *drm)
> > > - * {
> > > - * struct driver_device *priv = container_of(...);
> > > - *
> > > - * drm_mode_config_cleanup(drm);
> > > - * }
> > > - *
> > > * static struct drm_driver driver_drm_driver = {
> > > * [...]
> > > - * .release = driver_drm_release,
> > > * };
> > > *
> > > * static int driver_probe(struct platform_device *pdev)
> > > @@ -312,7 +303,9 @@ void drm_minor_release(struct drm_minor *minor)
> > > * }
> > > * drmm_add_final_kfree(drm, priv);
> > > *
> > > - * drm_mode_config_init(drm);
> > > + * ret = drm_mode_config_init(drm);
> > > + * if (ret)
> > > + * return ret;
> > > *
> > > * priv->userspace_facing = drmm_kzalloc(..., GFP_KERNEL);
> > > * if (!priv->userspace_facing)
> > > @@ -710,8 +703,7 @@ static void devm_drm_dev_init_release(void *data)
> > > * @driver: DRM driver
> > > *
> > > * Managed drm_dev_init(). The DRM device initialized with this function
> > > is
> > > - * automatically put on driver detach using drm_dev_put(). You must
> > > supply a
> > > - * _driver.release callback to control the finalization explicitly.
> > > + * automatically put on driver detach using drm_dev_put().
> > > *
> > > * RETURNS:
> > > * 0 on success, or error code on failure.
> > > @@ -722,9 +714,6 @@ int devm_drm_dev_init(struct device *parent,
> > > {
> > > int ret;
> > >
> > > - if (WARN_ON(!driver->release))
> > > - return -EINVAL;
> > > -
> > > ret = drm_dev_init(dev, driver, parent);
> > > if (ret)
> > > return ret;
> > > diff --git a/drivers/gpu/drm/drm_mode_config.c
> > > b/drivers/gpu/drm/drm_mode_config.c
> > > index 08e6eff6a179..957db1edba0c 100644
> > > --- a/drivers/gpu/drm/drm_mode_config.c
> > > +++ b/drivers/gpu/drm/drm_mode_config.c
Re: [Intel-gfx] [PATCH 22/52] drm: Use drmm_ for drm_dev_init cleanup
Hi Daniel,
On Wed, Feb 19, 2020 at 04:27:57PM +0100, Daniel Vetter wrote:
> On Wed, Feb 19, 2020 at 3:35 PM Laurent Pinchart wrote:
> > On Wed, Feb 19, 2020 at 11:20:52AM +0100, Daniel Vetter wrote:
> > > Well for the simple stuff at least, vblank, gem and minor cleanup I
> > > want to further split up as a demonstration.
> > >
> > > v2: We need to clear drm_device->dev otherwise the debug drm printing
> > > after our cleanup hook (e.g. in drm_manged_release) will chase
> > > released memory and result in a use-after-free. Not really pretty, but
> > > oh well.
> > >
> > > Signed-off-by: Daniel Vetter
> > > ---
> > > drivers/gpu/drm/drm_drv.c | 48 ---
> > > 1 file changed, 25 insertions(+), 23 deletions(-)
> >
> > Is the managed API overhead, coupled with the fact that the code size
> > doesn't get reduced, worth it for core code ?
>
> I've mostly done this as an example, to show how if you do this
> consistently, you can drop a few if (is_it_set_up) checks and remove
> the onion unwinding with lots of gotos.
That's however more a matter of making the cleanup handlers idempotent
than using a managed API, isn't it ?
> I do think it's worth it from
> that pov, since long-term I want to get to a world where everything
> related to drm_device gets unwound with drmm_ actions. The logging
> output becomes fairly nice if you enable it :-)
>
> But yeah stand-alone it's not a good pitch. Heck even the overall
> patch series is still a net loss I think, simply because this is just
> the bare minimum to get started.
> -Daniel
>
> > > diff --git a/drivers/gpu/drm/drm_drv.c b/drivers/gpu/drm/drm_drv.c
> > > index 782fd5d6f8b2..1f7ab88d9435 100644
> > > --- a/drivers/gpu/drm/drm_drv.c
> > > +++ b/drivers/gpu/drm/drm_drv.c
> > > @@ -580,6 +580,23 @@ static void drm_fs_inode_free(struct inode *inode)
> > > *used.
> > > */
> > >
> > > +static void drm_dev_init_release(struct drm_device *dev, void *res)
> > > +{
> > > + drm_legacy_ctxbitmap_cleanup(dev);
> > > + drm_legacy_remove_map_hash(dev);
> > > + drm_fs_inode_free(dev->anon_inode);
> > > +
> > > + put_device(dev->dev);
> > > + /* Prevent use-after-free in drm_managed_release when debugging is
> > > + * enabled. Slightly awkward, but can't really be helped. */
> > > + dev->dev = NULL;
> > > + mutex_destroy(>master_mutex);
> > > + mutex_destroy(>clientlist_mutex);
> > > + mutex_destroy(>filelist_mutex);
> > > + mutex_destroy(>struct_mutex);
> > > + drm_legacy_destroy_members(dev);
> > > +}
> > > +
> > > /**
> > > * drm_dev_init - Initialise new DRM device
> > > * @dev: DRM device
> > > @@ -647,11 +664,15 @@ int drm_dev_init(struct drm_device *dev,
> > > mutex_init(>clientlist_mutex);
> > > mutex_init(>master_mutex);
> > >
> > > + ret = drmm_add_action(dev, drm_dev_init_release, NULL);
> > > + if (ret)
> > > + return ret;
> > > +
> > > dev->anon_inode = drm_fs_inode_new();
> > > if (IS_ERR(dev->anon_inode)) {
> > > ret = PTR_ERR(dev->anon_inode);
> > > DRM_ERROR("Cannot allocate anonymous inode: %d\n", ret);
> > > - goto err_free;
> > > + goto err;
> > > }
> > >
> > > if (drm_core_check_feature(dev, DRIVER_RENDER)) {
> > > @@ -688,19 +709,12 @@ int drm_dev_init(struct drm_device *dev,
> > > if (drm_core_check_feature(dev, DRIVER_GEM))
> > > drm_gem_destroy(dev);
> > > err_ctxbitmap:
> > > - drm_legacy_ctxbitmap_cleanup(dev);
> > > - drm_legacy_remove_map_hash(dev);
> > > err_minors:
> > > drm_minor_free(dev, DRM_MINOR_PRIMARY);
> > > drm_minor_free(dev, DRM_MINOR_RENDER);
> > > - drm_fs_inode_free(dev->anon_inode);
> > > -err_free:
> > > - put_device(dev->dev);
> > > - mutex_destroy(>master_mutex);
> > > - mutex_destroy(>clientlist_mutex);
> > > - mutex_destroy(>filelist_mutex);
> > > - mutex_destroy(>struct_mutex);
> > > - drm_legacy_destroy_members(dev);
> > > +err:
> > > + drm_managed_release(dev);
> > > +
> > >
Re: [Intel-gfx] [PATCH 52/52] drm: Add docs for managed resources
ed on the final drm_dev_put() and works exactly
> + * like a memory allocation obtained by drmm_kmalloc().
> + */
> static inline void *drmm_kmalloc_array(struct drm_device *dev,
> size_t n, size_t size, gfp_t flags)
> +
> +/**
> + * drmm_kcalloc - _device managed kcalloc()
> + * @dev: DRM device
> + * @size: 0 terminated string to be duplicated
Ditto.
> + * @gfp: GFP allocation flags
> + *
> + * This is a _device managed version of kcalloc(). The allocated memory
> is
> + * automatically freed on the final drm_dev_put() and works exactly like a
> + * memory allocation obtained by drmm_kmalloc().
> + */
> {
> size_t bytes;
>
> @@ -41,6 +87,7 @@ static inline void *drmm_kcalloc(struct drm_device *dev,
> {
> return drmm_kmalloc_array(dev, n, size, flags | __GFP_ZERO);
> }
> +
> char *drmm_kstrdup(struct drm_device *dev, const char *s, gfp_t gfp);
>
> void drmm_kfree(struct drm_device *dev, void *data);
--
Regards,
Laurent Pinchart
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 24/52] drm: Manage drm_gem_init with drmm_
Hi Daniel,
On Wed, Feb 19, 2020 at 03:37:46PM +0100, Daniel Vetter wrote:
> On Wed, Feb 19, 2020 at 3:22 PM Laurent Pinchart wrote:
> > On Wed, Feb 19, 2020 at 11:20:54AM +0100, Daniel Vetter wrote:
> > > We might want to look into pushing this down into drm_mm_init, but
> > > that would mean rolling out return codes to a pile of functions
> > > unfortunately. So let's leave that for now.
> > >
> > > Signed-off-by: Daniel Vetter
> > > ---
> > > drivers/gpu/drm/drm_drv.c | 8 +---
> > > drivers/gpu/drm/drm_gem.c | 21 ++---
> > > drivers/gpu/drm/drm_internal.h | 1 -
> > > 3 files changed, 11 insertions(+), 19 deletions(-)
> > >
> > > diff --git a/drivers/gpu/drm/drm_drv.c b/drivers/gpu/drm/drm_drv.c
> > > index 03a1fb377830..7b3df1188da9 100644
> > > --- a/drivers/gpu/drm/drm_drv.c
> > > +++ b/drivers/gpu/drm/drm_drv.c
> > > @@ -688,13 +688,10 @@ int drm_dev_init(struct drm_device *dev,
> > >
> > > ret = drm_dev_set_unique(dev, dev_name(parent));
> > > if (ret)
> > > - goto err_setunique;
> > > + goto err;
> > >
> > > return 0;
> > >
> > > -err_setunique:
> > > - if (drm_core_check_feature(dev, DRIVER_GEM))
> > > - drm_gem_destroy(dev);
> > > err:
> > > drm_managed_release(dev);
> > >
> > > @@ -756,9 +753,6 @@ EXPORT_SYMBOL(devm_drm_dev_init);
> > > void drm_dev_fini(struct drm_device *dev)
> > > {
> > > drm_vblank_cleanup(dev);
> > > -
> > > - if (drm_core_check_feature(dev, DRIVER_GEM))
> > > - drm_gem_destroy(dev);
> > > }
> > > EXPORT_SYMBOL(drm_dev_fini);
> > >
> > > diff --git a/drivers/gpu/drm/drm_gem.c b/drivers/gpu/drm/drm_gem.c
> > > index 0b6e6623735e..31095e0f6b9f 100644
> > > --- a/drivers/gpu/drm/drm_gem.c
> > > +++ b/drivers/gpu/drm/drm_gem.c
> > > @@ -44,6 +44,7 @@
> > > #include
> > > #include
> > > #include
> > > +#include
> > > #include
> > > #include
> > >
> > > @@ -77,6 +78,12 @@
> > > * up at a later date, and as our interface with shmfs for memory
> > > allocation.
> > > */
> > >
> > > +static void
> > > +drm_gem_init_release(struct drm_device *dev, void *ptr)
> > > +{
> > > + drm_vma_offset_manager_destroy(dev->vma_offset_manager);
> > > +}
> > > +
> > > /**
> > > * drm_gem_init - Initialize the GEM device fields
> > > * @dev: drm_devic structure to initialize
> > > @@ -89,7 +96,8 @@ drm_gem_init(struct drm_device *dev)
> > > mutex_init(>object_name_lock);
> > > idr_init_base(>object_name_idr, 1);
> > >
> > > - vma_offset_manager = kzalloc(sizeof(*vma_offset_manager),
> > > GFP_KERNEL);
> > > + vma_offset_manager = drmm_kzalloc(dev, sizeof(*vma_offset_manager),
> > > + GFP_KERNEL);
> > > if (!vma_offset_manager) {
> > > DRM_ERROR("out of memory\n");
> > > return -ENOMEM;
> > > @@ -100,16 +108,7 @@ drm_gem_init(struct drm_device *dev)
> > > DRM_FILE_PAGE_OFFSET_START,
> > > DRM_FILE_PAGE_OFFSET_SIZE);
> > >
> > > - return 0;
> > > -}
> > > -
> > > -void
> > > -drm_gem_destroy(struct drm_device *dev)
> > > -{
> > > -
> > > - drm_vma_offset_manager_destroy(dev->vma_offset_manager);
> > > - kfree(dev->vma_offset_manager);
> > > - dev->vma_offset_manager = NULL;
> > > + return drmm_add_action(dev, drm_gem_init_release, NULL);
> >
> > This looks fine as such (although I'm not sure if the managed API
> > overhead is really worth it for core code), but it leads to a potential
> > issue: if we handle more of the cleanup through the managed API, how do
> > we ensure that the cleanup functions are called in the right order (when
> > order matters) ?
>
> KASAN essentially (already helped while developing this), plus review.
> It's still the same problem like reviewing onion unwind code, it's
> just less fragile for the normal case.
That wasn't really my question though. If there are ordering
constraints, and if we want to honour them, the ordering of cleanups
need t
Re: [Intel-gfx] [PATCH 23/52] drm: manage drm_minor cleanup with drmm_
t; DRM_ERROR("Cannot initialize graphics execution manager
> (GEM)\n");
> - goto err_ctxbitmap;
> + goto err;
> }
> }
>
> @@ -708,10 +695,6 @@ int drm_dev_init(struct drm_device *dev,
> err_setunique:
> if (drm_core_check_feature(dev, DRIVER_GEM))
> drm_gem_destroy(dev);
> -err_ctxbitmap:
> -err_minors:
> - drm_minor_free(dev, DRM_MINOR_PRIMARY);
> - drm_minor_free(dev, DRM_MINOR_RENDER);
> err:
> drm_managed_release(dev);
>
> @@ -776,9 +759,6 @@ void drm_dev_fini(struct drm_device *dev)
>
> if (drm_core_check_feature(dev, DRIVER_GEM))
> drm_gem_destroy(dev);
> -
> - drm_minor_free(dev, DRM_MINOR_PRIMARY);
> - drm_minor_free(dev, DRM_MINOR_RENDER);
> }
> EXPORT_SYMBOL(drm_dev_fini);
>
> diff --git a/drivers/gpu/drm/drm_managed.c b/drivers/gpu/drm/drm_managed.c
> index d8a484e19830..fb44fe65c2cd 100644
> --- a/drivers/gpu/drm/drm_managed.c
> +++ b/drivers/gpu/drm/drm_managed.c
> @@ -132,6 +132,34 @@ int __drmm_add_action(struct drm_device *dev,
> }
> EXPORT_SYMBOL(__drmm_add_action);
>
> +void drmm_remove_action(struct drm_device *dev,
> + drmres_release_t action,
> + void *data)
> +{
> + struct drmres *dr = NULL, *tmp;
> + unsigned long flags;
> +
> + if (!data)
> + return;
> +
> + spin_lock_irqsave(>managed.lock, flags);
> + list_for_each_entry(tmp, >managed.resources, node.entry) {
> + if (tmp->node.release == action &&
> + * (void **) tmp->data == data) {
As before, >data, and let's rename tmp.
> + dr = tmp;
> + del_dr(dev, dr);
> + break;
> + }
> + }
> + spin_unlock_irqrestore(>managed.lock, flags);
> +
> + if (WARN_ON(!dr))
> + return;
> +
> + kfree(dr);
> +}
> +EXPORT_SYMBOL(drmm_remove_action);
> +
> void *drmm_kmalloc(struct drm_device *dev, size_t size, gfp_t gfp)
> {
> struct drmres *dr;
> diff --git a/include/drm/drm_managed.h b/include/drm/drm_managed.h
> index 240edd395e88..df30f9355902 100644
> --- a/include/drm/drm_managed.h
> +++ b/include/drm/drm_managed.h
> @@ -14,6 +14,10 @@ int __must_check __drmm_add_action(struct drm_device *dev,
> drmres_release_t action,
> void *data, const char *name);
>
> +void drmm_remove_action(struct drm_device *dev,
> + drmres_release_t action,
> + void *data);
> +
> void drmm_add_final_kfree(struct drm_device *dev, void *parent);
>
> void *drmm_kmalloc(struct drm_device *dev, size_t size, gfp_t gfp) __malloc;
--
Regards,
Laurent Pinchart
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 19/52] drm/: Use drmm_add_final_kfree
Hi Daniel, On Wed, Feb 19, 2020 at 03:30:59PM +0100, Daniel Vetter wrote: > On Wed, Feb 19, 2020 at 3:11 PM Laurent Pinchart wrote: > > On Wed, Feb 19, 2020 at 11:20:49AM +0100, Daniel Vetter wrote: > > > These are the leftover drivers that didn't have a ->release hook that > > > needed to be updated. > > > > > > Signed-off-by: Daniel Vetter > > > Cc: "James (Qian) Wang" > > > Cc: Liviu Dudau > > > Cc: Mihail Atanassov > > > Cc: Russell King > > > Cc: Hans de Goede > > > --- > > > drivers/gpu/drm/arm/display/komeda/komeda_kms.c | 2 ++ > > > drivers/gpu/drm/armada/armada_drv.c | 2 ++ > > > drivers/gpu/drm/vboxvideo/vbox_drv.c| 2 ++ > > > 3 files changed, 6 insertions(+) > > > > > > diff --git a/drivers/gpu/drm/arm/display/komeda/komeda_kms.c > > > b/drivers/gpu/drm/arm/display/komeda/komeda_kms.c > > > index 442d4656150a..16dfd5cdb66c 100644 > > > --- a/drivers/gpu/drm/arm/display/komeda/komeda_kms.c > > > +++ b/drivers/gpu/drm/arm/display/komeda/komeda_kms.c > > > @@ -14,6 +14,7 @@ > > > #include > > > #include > > > #include > > > +#include > > > #include > > > #include > > > > > > @@ -271,6 +272,7 @@ struct komeda_kms_dev *komeda_kms_attach(struct > > > komeda_dev *mdev) > > > err = drm_dev_init(drm, _kms_driver, mdev->dev); > > > if (err) > > > goto free_kms; > > > + drmm_add_final_kfree(drm, kms); > > > > Instead of sprinkling calls to drmm_add_final_kfree() everywhere, > > wouldn't it be better to pass the parent pointer to drm_dev_init() ? > > Would lead to a horrendous monster patch, and even with this splitting > there were a few corner cases. It could be generated by coccinelle, with the semantic patch included in the commit message, so that regenerating it should be possible when merging if conflict arise. > My plan is to add a devm_drm_dev_alloc > pattern which combines the usual pattern that most drivers use, see > the last patch for all these glorious ideas. OK I will. > So yeah I hope this will all go away (or mostly at least), but for > bisecting I didn't come up with a better idea to get this all off the > ground unfortunately. > > > > > > > drm->dev_private = mdev; > > > > > > diff --git a/drivers/gpu/drm/armada/armada_drv.c > > > b/drivers/gpu/drm/armada/armada_drv.c > > > index 197dca3fc84c..dd9ed71ed942 100644 > > > --- a/drivers/gpu/drm/armada/armada_drv.c > > > +++ b/drivers/gpu/drm/armada/armada_drv.c > > > @@ -12,6 +12,7 @@ > > > #include > > > #include > > > #include > > > +#include > > > #include > > > #include > > > #include > > > @@ -103,6 +104,7 @@ static int armada_drm_bind(struct device *dev) > > > kfree(priv); > > > return ret; > > > } > > > + drmm_add_final_kfree(>drm, priv); > > > > > > /* Remove early framebuffers */ > > > ret = drm_fb_helper_remove_conflicting_framebuffers(NULL, > > > diff --git a/drivers/gpu/drm/vboxvideo/vbox_drv.c > > > b/drivers/gpu/drm/vboxvideo/vbox_drv.c > > > index 8512d970a09f..13eaae7921f5 100644 > > > --- a/drivers/gpu/drm/vboxvideo/vbox_drv.c > > > +++ b/drivers/gpu/drm/vboxvideo/vbox_drv.c > > > @@ -17,6 +17,7 @@ > > > #include > > > #include > > > #include > > > +#include > > > > > > #include "vbox_drv.h" > > > > > > @@ -54,6 +55,7 @@ static int vbox_pci_probe(struct pci_dev *pdev, const > > > struct pci_device_id *ent) > > > vbox->ddev.pdev = pdev; > > > vbox->ddev.dev_private = vbox; > > > pci_set_drvdata(pdev, vbox); > > > + drmm_add_final_kfree(>ddev, vbox); > > > mutex_init(>hw_mutex); > > > > > > ret = pci_enable_device(pdev); -- Regards, Laurent Pinchart ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 22/52] drm: Use drmm_ for drm_dev_init cleanup
Hi Daniel,
Thank you for the patch.
On Wed, Feb 19, 2020 at 11:20:52AM +0100, Daniel Vetter wrote:
> Well for the simple stuff at least, vblank, gem and minor cleanup I
> want to further split up as a demonstration.
>
> v2: We need to clear drm_device->dev otherwise the debug drm printing
> after our cleanup hook (e.g. in drm_manged_release) will chase
> released memory and result in a use-after-free. Not really pretty, but
> oh well.
>
> Signed-off-by: Daniel Vetter
> ---
> drivers/gpu/drm/drm_drv.c | 48 ---
> 1 file changed, 25 insertions(+), 23 deletions(-)
Is the managed API overhead, coupled with the fact that the code size
doesn't get reduced, worth it for core code ?
> diff --git a/drivers/gpu/drm/drm_drv.c b/drivers/gpu/drm/drm_drv.c
> index 782fd5d6f8b2..1f7ab88d9435 100644
> --- a/drivers/gpu/drm/drm_drv.c
> +++ b/drivers/gpu/drm/drm_drv.c
> @@ -580,6 +580,23 @@ static void drm_fs_inode_free(struct inode *inode)
> *used.
> */
>
> +static void drm_dev_init_release(struct drm_device *dev, void *res)
> +{
> + drm_legacy_ctxbitmap_cleanup(dev);
> + drm_legacy_remove_map_hash(dev);
> + drm_fs_inode_free(dev->anon_inode);
> +
> + put_device(dev->dev);
> + /* Prevent use-after-free in drm_managed_release when debugging is
> + * enabled. Slightly awkward, but can't really be helped. */
> + dev->dev = NULL;
> + mutex_destroy(>master_mutex);
> + mutex_destroy(>clientlist_mutex);
> + mutex_destroy(>filelist_mutex);
> + mutex_destroy(>struct_mutex);
> + drm_legacy_destroy_members(dev);
> +}
> +
> /**
> * drm_dev_init - Initialise new DRM device
> * @dev: DRM device
> @@ -647,11 +664,15 @@ int drm_dev_init(struct drm_device *dev,
> mutex_init(>clientlist_mutex);
> mutex_init(>master_mutex);
>
> + ret = drmm_add_action(dev, drm_dev_init_release, NULL);
> + if (ret)
> + return ret;
> +
> dev->anon_inode = drm_fs_inode_new();
> if (IS_ERR(dev->anon_inode)) {
> ret = PTR_ERR(dev->anon_inode);
> DRM_ERROR("Cannot allocate anonymous inode: %d\n", ret);
> - goto err_free;
> + goto err;
> }
>
> if (drm_core_check_feature(dev, DRIVER_RENDER)) {
> @@ -688,19 +709,12 @@ int drm_dev_init(struct drm_device *dev,
> if (drm_core_check_feature(dev, DRIVER_GEM))
> drm_gem_destroy(dev);
> err_ctxbitmap:
> - drm_legacy_ctxbitmap_cleanup(dev);
> - drm_legacy_remove_map_hash(dev);
> err_minors:
> drm_minor_free(dev, DRM_MINOR_PRIMARY);
> drm_minor_free(dev, DRM_MINOR_RENDER);
> - drm_fs_inode_free(dev->anon_inode);
> -err_free:
> - put_device(dev->dev);
> - mutex_destroy(>master_mutex);
> - mutex_destroy(>clientlist_mutex);
> - mutex_destroy(>filelist_mutex);
> - mutex_destroy(>struct_mutex);
> - drm_legacy_destroy_members(dev);
> +err:
> + drm_managed_release(dev);
> +
> return ret;
> }
> EXPORT_SYMBOL(drm_dev_init);
> @@ -763,20 +777,8 @@ void drm_dev_fini(struct drm_device *dev)
> if (drm_core_check_feature(dev, DRIVER_GEM))
> drm_gem_destroy(dev);
>
> - drm_legacy_ctxbitmap_cleanup(dev);
> - drm_legacy_remove_map_hash(dev);
> - drm_fs_inode_free(dev->anon_inode);
> -
> drm_minor_free(dev, DRM_MINOR_PRIMARY);
> drm_minor_free(dev, DRM_MINOR_RENDER);
> -
> - put_device(dev->dev);
> -
> - mutex_destroy(>master_mutex);
> - mutex_destroy(>clientlist_mutex);
> - mutex_destroy(>filelist_mutex);
> - mutex_destroy(>struct_mutex);
> - drm_legacy_destroy_members(dev);
> }
> EXPORT_SYMBOL(drm_dev_fini);
>
--
Regards,
Laurent Pinchart
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 21/52] drm: Handle dev->unique with drmm_
Hi Daniel,
Thank you for the patch.
On Wed, Feb 19, 2020 at 11:20:51AM +0100, Daniel Vetter wrote:
> We need to add a drmm_kstrdup for this, but let's start somewhere.
>
> This is not exactly perfect onion unwinding, but it's jsut a kfree so
> doesn't really matter at all.
>
> Signed-off-by: Daniel Vetter
> ---
> drivers/gpu/drm/drm_drv.c | 5 ++---
> drivers/gpu/drm/drm_managed.c | 16
> include/drm/drm_managed.h | 1 +
> 3 files changed, 19 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_drv.c b/drivers/gpu/drm/drm_drv.c
> index 1ee606b4a4f9..782fd5d6f8b2 100644
> --- a/drivers/gpu/drm/drm_drv.c
> +++ b/drivers/gpu/drm/drm_drv.c
> @@ -777,7 +777,6 @@ void drm_dev_fini(struct drm_device *dev)
> mutex_destroy(>filelist_mutex);
> mutex_destroy(>struct_mutex);
> drm_legacy_destroy_members(dev);
> - kfree(dev->unique);
> }
> EXPORT_SYMBOL(drm_dev_fini);
>
> @@ -1063,8 +1062,8 @@ EXPORT_SYMBOL(drm_dev_unregister);
> */
> int drm_dev_set_unique(struct drm_device *dev, const char *name)
> {
> - kfree(dev->unique);
> - dev->unique = kstrdup(name, GFP_KERNEL);
> + drmm_kfree(dev, dev->unique);
> + dev->unique = drmm_kstrdup(dev, name, GFP_KERNEL);
>
> return dev->unique ? 0 : -ENOMEM;
> }
> diff --git a/drivers/gpu/drm/drm_managed.c b/drivers/gpu/drm/drm_managed.c
> index ee7c7253af61..d8a484e19830 100644
> --- a/drivers/gpu/drm/drm_managed.c
> +++ b/drivers/gpu/drm/drm_managed.c
> @@ -147,6 +147,22 @@ void *drmm_kmalloc(struct drm_device *dev, size_t size,
> gfp_t gfp)
> }
> EXPORT_SYMBOL(drmm_kmalloc);
>
> +char *drmm_kstrdup(struct drm_device *dev, const char *s, gfp_t gfp)
Do we need support for gfp_t other than GFP_KERNEL ? Given that the
memory will be released when the drm_device is destroyed, GFP_ATOMIC
would seem of dubious use to me, and we may want to not make it possible
to use it.
> +{
> + size_t size;
> + char *buf;
> +
> + if (!s)
> + return NULL;
> +
> + size = strlen(s) + 1;
> + buf = drmm_kmalloc(dev, size, gfp);
> + if (buf)
> + memcpy(buf, s, size);
> + return buf;
> +}
> +EXPORT_SYMBOL_GPL(drmm_kstrdup);
> +
> void drmm_kfree(struct drm_device *dev, void *data)
> {
> struct drmres *dr = NULL, *tmp;
> diff --git a/include/drm/drm_managed.h b/include/drm/drm_managed.h
> index 75f2c8932c69..240edd395e88 100644
> --- a/include/drm/drm_managed.h
> +++ b/include/drm/drm_managed.h
> @@ -21,5 +21,6 @@ static inline void *drmm_kzalloc(struct drm_device *dev,
> size_t size, gfp_t gfp)
> {
> return drmm_kmalloc(dev, size, gfp | __GFP_ZERO);
> }
> +char *drmm_kstrdup(struct drm_device *dev, const char *s, gfp_t gfp);
>
> void drmm_kfree(struct drm_device *dev, void *data);
--
Regards,
Laurent Pinchart
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 24/52] drm: Manage drm_gem_init with drmm_
Hi Daniel,
Thank you for the patch.
On Wed, Feb 19, 2020 at 11:20:54AM +0100, Daniel Vetter wrote:
> We might want to look into pushing this down into drm_mm_init, but
> that would mean rolling out return codes to a pile of functions
> unfortunately. So let's leave that for now.
>
> Signed-off-by: Daniel Vetter
> ---
> drivers/gpu/drm/drm_drv.c | 8 +---
> drivers/gpu/drm/drm_gem.c | 21 ++---
> drivers/gpu/drm/drm_internal.h | 1 -
> 3 files changed, 11 insertions(+), 19 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_drv.c b/drivers/gpu/drm/drm_drv.c
> index 03a1fb377830..7b3df1188da9 100644
> --- a/drivers/gpu/drm/drm_drv.c
> +++ b/drivers/gpu/drm/drm_drv.c
> @@ -688,13 +688,10 @@ int drm_dev_init(struct drm_device *dev,
>
> ret = drm_dev_set_unique(dev, dev_name(parent));
> if (ret)
> - goto err_setunique;
> + goto err;
>
> return 0;
>
> -err_setunique:
> - if (drm_core_check_feature(dev, DRIVER_GEM))
> - drm_gem_destroy(dev);
> err:
> drm_managed_release(dev);
>
> @@ -756,9 +753,6 @@ EXPORT_SYMBOL(devm_drm_dev_init);
> void drm_dev_fini(struct drm_device *dev)
> {
> drm_vblank_cleanup(dev);
> -
> - if (drm_core_check_feature(dev, DRIVER_GEM))
> - drm_gem_destroy(dev);
> }
> EXPORT_SYMBOL(drm_dev_fini);
>
> diff --git a/drivers/gpu/drm/drm_gem.c b/drivers/gpu/drm/drm_gem.c
> index 0b6e6623735e..31095e0f6b9f 100644
> --- a/drivers/gpu/drm/drm_gem.c
> +++ b/drivers/gpu/drm/drm_gem.c
> @@ -44,6 +44,7 @@
> #include
> #include
> #include
> +#include
> #include
> #include
>
> @@ -77,6 +78,12 @@
> * up at a later date, and as our interface with shmfs for memory allocation.
> */
>
> +static void
> +drm_gem_init_release(struct drm_device *dev, void *ptr)
> +{
> + drm_vma_offset_manager_destroy(dev->vma_offset_manager);
> +}
> +
> /**
> * drm_gem_init - Initialize the GEM device fields
> * @dev: drm_devic structure to initialize
> @@ -89,7 +96,8 @@ drm_gem_init(struct drm_device *dev)
> mutex_init(>object_name_lock);
> idr_init_base(>object_name_idr, 1);
>
> - vma_offset_manager = kzalloc(sizeof(*vma_offset_manager), GFP_KERNEL);
> + vma_offset_manager = drmm_kzalloc(dev, sizeof(*vma_offset_manager),
> + GFP_KERNEL);
> if (!vma_offset_manager) {
> DRM_ERROR("out of memory\n");
> return -ENOMEM;
> @@ -100,16 +108,7 @@ drm_gem_init(struct drm_device *dev)
> DRM_FILE_PAGE_OFFSET_START,
> DRM_FILE_PAGE_OFFSET_SIZE);
>
> - return 0;
> -}
> -
> -void
> -drm_gem_destroy(struct drm_device *dev)
> -{
> -
> - drm_vma_offset_manager_destroy(dev->vma_offset_manager);
> - kfree(dev->vma_offset_manager);
> - dev->vma_offset_manager = NULL;
> + return drmm_add_action(dev, drm_gem_init_release, NULL);
This looks fine as such (although I'm not sure if the managed API
overhead is really worth it for core code), but it leads to a potential
issue: if we handle more of the cleanup through the managed API, how do
we ensure that the cleanup functions are called in the right order (when
order matters) ?
> }
>
> /**
> diff --git a/drivers/gpu/drm/drm_internal.h b/drivers/gpu/drm/drm_internal.h
> index 8c2628dfc6c7..cb09e95a795e 100644
> --- a/drivers/gpu/drm/drm_internal.h
> +++ b/drivers/gpu/drm/drm_internal.h
> @@ -144,7 +144,6 @@ void drm_sysfs_lease_event(struct drm_device *dev);
> /* drm_gem.c */
> struct drm_gem_object;
> int drm_gem_init(struct drm_device *dev);
> -void drm_gem_destroy(struct drm_device *dev);
> int drm_gem_handle_create_tail(struct drm_file *file_priv,
> struct drm_gem_object *obj,
> u32 *handlep);
--
Regards,
Laurent Pinchart
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 19/52] drm/: Use drmm_add_final_kfree
Hi Daniel, Thank you for the patch. On Wed, Feb 19, 2020 at 11:20:49AM +0100, Daniel Vetter wrote: > These are the leftover drivers that didn't have a ->release hook that > needed to be updated. > > Signed-off-by: Daniel Vetter > Cc: "James (Qian) Wang" > Cc: Liviu Dudau > Cc: Mihail Atanassov > Cc: Russell King > Cc: Hans de Goede > --- > drivers/gpu/drm/arm/display/komeda/komeda_kms.c | 2 ++ > drivers/gpu/drm/armada/armada_drv.c | 2 ++ > drivers/gpu/drm/vboxvideo/vbox_drv.c| 2 ++ > 3 files changed, 6 insertions(+) > > diff --git a/drivers/gpu/drm/arm/display/komeda/komeda_kms.c > b/drivers/gpu/drm/arm/display/komeda/komeda_kms.c > index 442d4656150a..16dfd5cdb66c 100644 > --- a/drivers/gpu/drm/arm/display/komeda/komeda_kms.c > +++ b/drivers/gpu/drm/arm/display/komeda/komeda_kms.c > @@ -14,6 +14,7 @@ > #include > #include > #include > +#include > #include > #include > > @@ -271,6 +272,7 @@ struct komeda_kms_dev *komeda_kms_attach(struct > komeda_dev *mdev) > err = drm_dev_init(drm, _kms_driver, mdev->dev); > if (err) > goto free_kms; > + drmm_add_final_kfree(drm, kms); Instead of sprinkling calls to drmm_add_final_kfree() everywhere, wouldn't it be better to pass the parent pointer to drm_dev_init() ? > > drm->dev_private = mdev; > > diff --git a/drivers/gpu/drm/armada/armada_drv.c > b/drivers/gpu/drm/armada/armada_drv.c > index 197dca3fc84c..dd9ed71ed942 100644 > --- a/drivers/gpu/drm/armada/armada_drv.c > +++ b/drivers/gpu/drm/armada/armada_drv.c > @@ -12,6 +12,7 @@ > #include > #include > #include > +#include > #include > #include > #include > @@ -103,6 +104,7 @@ static int armada_drm_bind(struct device *dev) > kfree(priv); > return ret; > } > + drmm_add_final_kfree(>drm, priv); > > /* Remove early framebuffers */ > ret = drm_fb_helper_remove_conflicting_framebuffers(NULL, > diff --git a/drivers/gpu/drm/vboxvideo/vbox_drv.c > b/drivers/gpu/drm/vboxvideo/vbox_drv.c > index 8512d970a09f..13eaae7921f5 100644 > --- a/drivers/gpu/drm/vboxvideo/vbox_drv.c > +++ b/drivers/gpu/drm/vboxvideo/vbox_drv.c > @@ -17,6 +17,7 @@ > #include > #include > #include > +#include > > #include "vbox_drv.h" > > @@ -54,6 +55,7 @@ static int vbox_pci_probe(struct pci_dev *pdev, const > struct pci_device_id *ent) > vbox->ddev.pdev = pdev; > vbox->ddev.dev_private = vbox; > pci_set_drvdata(pdev, vbox); > + drmm_add_final_kfree(>ddev, vbox); > mutex_init(>hw_mutex); > > ret = pci_enable_device(pdev); -- Regards, Laurent Pinchart ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 40/52] drm/shmob: Drop explicit drm_mode_config_cleanup call
Hi Daniel,
Thank you for the patch.
On Wed, Feb 19, 2020 at 11:21:10AM +0100, Daniel Vetter wrote:
> It's right above the drm_dev_put().
>
> Aside: Another driver with a bit much devm_kzalloc, which should
> probably use drmm_kzalloc instead ...
With the same comments as the one for the rcar-du patch taken into
account,
Reviewed-by: Laurent Pinchart
> Signed-off-by: Daniel Vetter
> Cc: Laurent Pinchart
> Cc: Kieran Bingham
> Cc: linux-renesas-...@vger.kernel.org
> ---
> drivers/gpu/drm/shmobile/shmob_drm_drv.c | 2 --
> drivers/gpu/drm/shmobile/shmob_drm_kms.c | 6 +-
> 2 files changed, 5 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/shmobile/shmob_drm_drv.c
> b/drivers/gpu/drm/shmobile/shmob_drm_drv.c
> index b8c0930959c7..ae9d6b8d3ca8 100644
> --- a/drivers/gpu/drm/shmobile/shmob_drm_drv.c
> +++ b/drivers/gpu/drm/shmobile/shmob_drm_drv.c
> @@ -192,7 +192,6 @@ static int shmob_drm_remove(struct platform_device *pdev)
>
> drm_dev_unregister(ddev);
> drm_kms_helper_poll_fini(ddev);
> - drm_mode_config_cleanup(ddev);
> drm_irq_uninstall(ddev);
> drm_dev_put(ddev);
>
> @@ -288,7 +287,6 @@ static int shmob_drm_probe(struct platform_device *pdev)
> drm_irq_uninstall(ddev);
> err_modeset_cleanup:
> drm_kms_helper_poll_fini(ddev);
> - drm_mode_config_cleanup(ddev);
> err_free_drm_dev:
> drm_dev_put(ddev);
>
> diff --git a/drivers/gpu/drm/shmobile/shmob_drm_kms.c
> b/drivers/gpu/drm/shmobile/shmob_drm_kms.c
> index c51197b6fd85..e6e34bb75ba0 100644
> --- a/drivers/gpu/drm/shmobile/shmob_drm_kms.c
> +++ b/drivers/gpu/drm/shmobile/shmob_drm_kms.c
> @@ -126,7 +126,11 @@ static const struct drm_mode_config_funcs
> shmob_drm_mode_config_funcs = {
>
> int shmob_drm_modeset_init(struct shmob_drm_device *sdev)
> {
> - drm_mode_config_init(sdev->ddev);
> + int ret;
> +
> + ret = drm_mode_config_init(sdev->ddev);
> + if (ret)
> + return ret;
>
> shmob_drm_crtc_create(sdev);
> shmob_drm_encoder_create(sdev);
--
Regards,
Laurent Pinchart
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 37/52] drm/rcar-du: Drop explicit drm_mode_config_cleanup call
Hi Daniel, Thank you for the patch. On Wed, Feb 19, 2020 at 11:21:07AM +0100, Daniel Vetter wrote: > It's right above the drm_dev_put(). Could you mention in the commit message that the call can be dropped because drm_mode_config_init() uses the managed API to handle cleaning automatically, removing the need to do so in drivers ? Otherwise when someone will look at the commit later, without having the full context in mind, the reason why the call is dropped won't be immediately clear. With this fixed, Reviewed-by: Laurent Pinchart This also applies to similar patches for other drivers. > Aside: Another driver with a bit much devm_kzalloc, which should > probably use drmm_kzalloc instead ... I agree, but I'm not sure this should be part of the commit message :-) > Signed-off-by: Daniel Vetter > Cc: Laurent Pinchart > Cc: Kieran Bingham > Cc: linux-renesas-...@vger.kernel.org > --- > drivers/gpu/drm/rcar-du/rcar_du_drv.c | 1 - > drivers/gpu/drm/rcar-du/rcar_du_kms.c | 4 +++- > 2 files changed, 3 insertions(+), 2 deletions(-) > > diff --git a/drivers/gpu/drm/rcar-du/rcar_du_drv.c > b/drivers/gpu/drm/rcar-du/rcar_du_drv.c > index 654e2dd08146..3e67cf70f040 100644 > --- a/drivers/gpu/drm/rcar-du/rcar_du_drv.c > +++ b/drivers/gpu/drm/rcar-du/rcar_du_drv.c > @@ -530,7 +530,6 @@ static int rcar_du_remove(struct platform_device *pdev) > drm_dev_unregister(ddev); > > drm_kms_helper_poll_fini(ddev); > - drm_mode_config_cleanup(ddev); > > drm_dev_put(ddev); > > diff --git a/drivers/gpu/drm/rcar-du/rcar_du_kms.c > b/drivers/gpu/drm/rcar-du/rcar_du_kms.c > index fcfd916227d1..dcdc1580b511 100644 > --- a/drivers/gpu/drm/rcar-du/rcar_du_kms.c > +++ b/drivers/gpu/drm/rcar-du/rcar_du_kms.c > @@ -712,7 +712,9 @@ int rcar_du_modeset_init(struct rcar_du_device *rcdu) > unsigned int i; > int ret; > > - drm_mode_config_init(dev); > + ret = drm_mode_config_init(dev); > + if (ret) > + return ret; > > dev->mode_config.min_width = 0; > dev->mode_config.min_height = 0; -- Regards, Laurent Pinchart ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 27/52] drm: Manage drm_mode_config_init with drmm_
ock_init(>mode_config.connection_mutex);
> @@ -443,6 +451,8 @@ void drm_mode_config_init(struct drm_device *dev)
> drm_modeset_acquire_fini(_ctx);
> dma_resv_fini();
> }
> +
> + return drmm_add_action(dev, drm_mode_config_init_release, NULL);
If this fails, shouldn't drm_mode_config_cleanup() be called here ?
> }
> EXPORT_SYMBOL(drm_mode_config_init);
>
> diff --git a/include/drm/drm_mode_config.h b/include/drm/drm_mode_config.h
> index 3bcbe30339f0..160a3e4b51c3 100644
> --- a/include/drm/drm_mode_config.h
> +++ b/include/drm/drm_mode_config.h
> @@ -929,7 +929,7 @@ struct drm_mode_config {
> const struct drm_mode_config_helper_funcs *helper_private;
> };
>
> -void drm_mode_config_init(struct drm_device *dev);
> +int drm_mode_config_init(struct drm_device *dev);
> void drm_mode_config_reset(struct drm_device *dev);
> void drm_mode_config_cleanup(struct drm_device *dev);
>
--
Regards,
Laurent Pinchart
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 07/52] drm/udl: Use drmm_add_final_kfree
Hi Daniel,
Thank you for the patch.
On Wed, Feb 19, 2020 at 11:20:37AM +0100, Daniel Vetter wrote:
> With this we can drop the final kfree from the release function.
>
> v2: We need drm_dev_put to unroll the driver creation (once
> drm_dev_init and drmm_add_final_kfree suceeded), otherwise
> the drmm_ magic doesn't happen.
>
> Signed-off-by: Daniel Vetter
Did you mean to squash this with the previous commit ?
> Cc: Dave Airlie
> Cc: Sean Paul
> Cc: Thomas Zimmermann
> Cc: Emil Velikov
> Cc: Daniel Vetter
> Cc: "Noralf Trønnes"
> Cc: Thomas Gleixner
> Cc: Sam Ravnborg
> ---
> drivers/gpu/drm/udl/udl_drv.c | 3 +--
> 1 file changed, 1 insertion(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/udl/udl_drv.c b/drivers/gpu/drm/udl/udl_drv.c
> index d5b89711ab1e..6a5594946096 100644
> --- a/drivers/gpu/drm/udl/udl_drv.c
> +++ b/drivers/gpu/drm/udl/udl_drv.c
> @@ -81,8 +81,7 @@ static struct udl_device *udl_driver_create(struct
> usb_interface *interface)
>
> r = udl_init(udl);
> if (r) {
> - drm_dev_fini(>drm);
> - kfree(udl);
> + drm_dev_put(>drm);
> return ERR_PTR(r);
> }
>
--
Regards,
Laurent Pinchart
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 04/52] drm: Set final_kfree in drm_dev_alloc
Hi Daniel, Thank you for the patch. On Wed, Feb 19, 2020 at 11:20:34AM +0100, Daniel Vetter wrote: > I also did a full review of all callers, and only the xen driver > forgot to call drm_dev_put in the failure path. Fix that up too. I'd split this patch in two then, with the Xen first coming first, and with an explanation in the commit message of the second patch about why you call drmm_add_final_kfree() in drm_dev_alloc(). > v2: I noticed that xen has a drm_driver.release hook, and uses > drm_dev_alloc(). We need to remove the kfree from > xen_drm_drv_release(). > > bochs also has a release hook, but leaked the drm_device ever since > > commit 0a6659bdc5e8221da99eebb176fd9591435e38de > Author: Gerd Hoffmann > Date: Tue Dec 17 18:04:46 2013 +0100 > > drm/bochs: new driver > > This patch here fixes that leak. > > Same for virtio, started leaking with > > commit b1df3a2b24a917f8853d43fe9683c0e360d2c33a > Author: Gerd Hoffmann > Date: Tue Feb 11 14:58:04 2020 +0100 > > drm/virtio: add drm_driver.release callback. > > Cc: Gerd Hoffmann > Cc: Oleksandr Andrushchenko > Cc: xen-de...@lists.xenproject.org > > Signed-off-by: Daniel Vetter > Cc: Maarten Lankhorst > Cc: Maxime Ripard > Cc: Thomas Zimmermann > Cc: David Airlie > Cc: Daniel Vetter > Cc: Oleksandr Andrushchenko > Cc: xen-de...@lists.xenproject.org > --- > drivers/gpu/drm/drm_drv.c | 3 +++ > drivers/gpu/drm/xen/xen_drm_front.c | 2 +- > 2 files changed, 4 insertions(+), 1 deletion(-) > > diff --git a/drivers/gpu/drm/drm_drv.c b/drivers/gpu/drm/drm_drv.c > index 3e5627d6eba6..9e62e28bbc62 100644 > --- a/drivers/gpu/drm/drm_drv.c > +++ b/drivers/gpu/drm/drm_drv.c > @@ -39,6 +39,7 @@ > #include > #include > #include > +#include > #include > #include > > @@ -819,6 +820,8 @@ struct drm_device *drm_dev_alloc(struct drm_driver > *driver, > return ERR_PTR(ret); > } > > + drmm_add_final_kfree(dev, dev); drmm_add_final_kfree() can only be called once. Does this mean that a driver using drm_dev_alloc() isn't allowed to use drmm_add_final_kfree() to tract its own private structure ? > + > return dev; > } > EXPORT_SYMBOL(drm_dev_alloc); > diff --git a/drivers/gpu/drm/xen/xen_drm_front.c > b/drivers/gpu/drm/xen/xen_drm_front.c > index 4be49c1aef51..d22b5da38935 100644 > --- a/drivers/gpu/drm/xen/xen_drm_front.c > +++ b/drivers/gpu/drm/xen/xen_drm_front.c > @@ -461,7 +461,6 @@ static void xen_drm_drv_release(struct drm_device *dev) > drm_mode_config_cleanup(dev); > > drm_dev_fini(dev); > - kfree(dev); > > if (front_info->cfg.be_alloc) > xenbus_switch_state(front_info->xb_dev, > @@ -561,6 +560,7 @@ static int xen_drm_drv_init(struct xen_drm_front_info > *front_info) > fail_modeset: > drm_kms_helper_poll_fini(drm_dev); > drm_mode_config_cleanup(drm_dev); > + drm_dev_put(drm_dev); > fail: > kfree(drm_info); > return ret; -- Regards, Laurent Pinchart ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 03/52] drm: add managed resources tied to drm_device
.0
No header guard ?
> +
> +#include
> +#include
Alphabetically sorted ?
> +
> +struct drm_device;
> +
> +typedef void (*drmres_release_t)(struct drm_device *dev, void *res);
> +
> +#define drmm_add_action(dev, action, data) \
> + __drmm_add_action(dev, action, data, #action)
> +
> +int __must_check __drmm_add_action(struct drm_device *dev,
> +drmres_release_t action,
> +void *data, const char *name);
> +
> +void drmm_add_final_kfree(struct drm_device *dev, void *parent);
> +
> +void *drmm_kmalloc(struct drm_device *dev, size_t size, gfp_t gfp) __malloc;
> +static inline void *drmm_kzalloc(struct drm_device *dev, size_t size, gfp_t
> gfp)
> +{
> + return drmm_kmalloc(dev, size, gfp | __GFP_ZERO);
> +}
> +
> +void drmm_kfree(struct drm_device *dev, void *data);
> diff --git a/include/drm/drm_print.h b/include/drm/drm_print.h
> index ca7cee8e728a..1c9417430d08 100644
> --- a/include/drm/drm_print.h
> +++ b/include/drm/drm_print.h
> @@ -313,6 +313,10 @@ enum drm_debug_category {
>* @DRM_UT_DP: Used in the DP code.
>*/
> DRM_UT_DP = 0x100,
> + /**
> + * @DRM_UT_DRMRES: Used in the drm managed resources code.
> + */
> + DRM_UT_DRMRES = 0x200,
> };
>
> static inline bool drm_debug_enabled(enum drm_debug_category category)
> @@ -442,6 +446,8 @@ void drm_dev_dbg(const struct device *dev, enum
> drm_debug_category category,
> drm_dev_dbg((drm)->dev, DRM_UT_LEASE, fmt, ##__VA_ARGS__)
> #define drm_dbg_dp(drm, fmt, ...)\
> drm_dev_dbg((drm)->dev, DRM_UT_DP, fmt, ##__VA_ARGS__)
> +#define drm_dbg_drmres(drm, fmt, ...)
> \
> + drm_dev_dbg((drm)->dev, DRM_UT_DRMRES, fmt, ##__VA_ARGS__)
>
>
> /*
--
Regards,
Laurent Pinchart
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 37/52] drm/rcar-du: Drop explicit drm_mode_config_cleanup call
Hi Daniel, On Wed, Feb 19, 2020 at 12:10:18PM +0100, Geert Uytterhoeven wrote: > On Wed, Feb 19, 2020 at 11:57 AM Daniel Vetter wrote: > > On Wed, Feb 19, 2020 at 11:30 AM Geert Uytterhoeven wrote: > > > On Wed, Feb 19, 2020 at 11:22 AM Daniel Vetter wrote: > > > > It's right above the drm_dev_put(). > > > > > > > > Aside: Another driver with a bit much devm_kzalloc, which should > > > > probably use drmm_kzalloc instead ... > > > > > > What's drmm_kzalloc()? > > > The only references I can find are in this patch series. > > > > Yup, it's all new. Read cover letter for reading instructions for the > > entire patch series. I'm afraid the driver patches wont make much > > sense without the context. None actually :-/ > > IC, as the cover letter was sent only to dri-devel and intel-gfx, many > recipients of the patches won't have received it... > https://lore.kernel.org/dri-devel/20200219102122.1607365-1-daniel.vet...@ffwll.ch/ I was also going to mention that it would be nice to send the cover letter to all recipients from the series, otherwise it's a bit painful. Daniel, is this something that could be integrated in your workflow ? -- Regards, Laurent Pinchart ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/2] drm/connector: Share with non-atomic drivers the function to get the single encoder
Hi José,
Thank you for the patch.
On Thu, Sep 12, 2019 at 12:51:31PM -0700, José Roberto de Souza wrote:
> This 3 non-atomic drivers all have the same function getting the
> only encoder available in the connector, also atomic drivers have
> this fallback. So moving it a common place and sharing between atomic
> and non-atomic drivers.
>
> While at it I also removed the mention of
> drm_atomic_helper_best_encoder() that was renamed in
> commit 297e30b5d9b6 ("drm/atomic-helper: Unexport
> drm_atomic_helper_best_encoder").
>
> v3: moving drm_connector_get_single_encoder to drm_kms_helper module
>
> Suggested-by: Ville Syrjälä
> Cc: Ville Syrjälä
> Cc: Daniel Vetter
> Cc: Laurent Pinchart
> Cc: dri-de...@lists.freedesktop.org
> Cc: intel-gfx@lists.freedesktop.org
> Signed-off-by: José Roberto de Souza
> ---
> drivers/gpu/drm/ast/ast_mode.c | 12
> drivers/gpu/drm/drm_atomic_helper.c| 15 ++-
> drivers/gpu/drm/drm_crtc_helper.c | 17 -
> drivers/gpu/drm/drm_crtc_helper_internal.h | 3 +++
> drivers/gpu/drm/mgag200/mgag200_mode.c | 11 ---
> drivers/gpu/drm/udl/udl_connector.c| 8
> include/drm/drm_modeset_helper_vtables.h | 6 +++---
> 7 files changed, 24 insertions(+), 48 deletions(-)
>
> diff --git a/drivers/gpu/drm/ast/ast_mode.c b/drivers/gpu/drm/ast/ast_mode.c
> index d349c721501c..eef95e1af06b 100644
> --- a/drivers/gpu/drm/ast/ast_mode.c
> +++ b/drivers/gpu/drm/ast/ast_mode.c
> @@ -687,17 +687,6 @@ static void ast_encoder_destroy(struct drm_encoder
> *encoder)
> kfree(encoder);
> }
>
> -
> -static struct drm_encoder *ast_best_single_encoder(struct drm_connector
> *connector)
> -{
> - int enc_id = connector->encoder_ids[0];
> - /* pick the encoder ids */
> - if (enc_id)
> - return drm_encoder_find(connector->dev, NULL, enc_id);
> - return NULL;
> -}
> -
> -
> static const struct drm_encoder_funcs ast_enc_funcs = {
> .destroy = ast_encoder_destroy,
> };
> @@ -847,7 +836,6 @@ static void ast_connector_destroy(struct drm_connector
> *connector)
> static const struct drm_connector_helper_funcs ast_connector_helper_funcs = {
> .mode_valid = ast_mode_valid,
> .get_modes = ast_get_modes,
> - .best_encoder = ast_best_single_encoder,
> };
>
> static const struct drm_connector_funcs ast_connector_funcs = {
> diff --git a/drivers/gpu/drm/drm_atomic_helper.c
> b/drivers/gpu/drm/drm_atomic_helper.c
> index 4706439fb490..9d7e4da6c292 100644
> --- a/drivers/gpu/drm/drm_atomic_helper.c
> +++ b/drivers/gpu/drm/drm_atomic_helper.c
> @@ -97,17 +97,6 @@ drm_atomic_helper_plane_changed(struct drm_atomic_state
> *state,
> }
> }
>
> -/*
> - * For connectors that support multiple encoders, either the
> - * .atomic_best_encoder() or .best_encoder() operation must be implemented.
> - */
> -static struct drm_encoder *
> -pick_single_encoder_for_connector(struct drm_connector *connector)
> -{
> - WARN_ON(connector->encoder_ids[1]);
> - return drm_encoder_find(connector->dev, NULL,
> connector->encoder_ids[0]);
> -}
> -
> static int handle_conflicting_encoders(struct drm_atomic_state *state,
> bool disable_conflicting_encoders)
> {
> @@ -135,7 +124,7 @@ static int handle_conflicting_encoders(struct
> drm_atomic_state *state,
> else if (funcs->best_encoder)
> new_encoder = funcs->best_encoder(connector);
> else
> - new_encoder =
> pick_single_encoder_for_connector(connector);
> + new_encoder =
> drm_connector_get_single_encoder(connector);
>
> if (new_encoder) {
> if (encoder_mask & drm_encoder_mask(new_encoder)) {
> @@ -359,7 +348,7 @@ update_connector_routing(struct drm_atomic_state *state,
> else if (funcs->best_encoder)
> new_encoder = funcs->best_encoder(connector);
> else
> - new_encoder = pick_single_encoder_for_connector(connector);
> + new_encoder = drm_connector_get_single_encoder(connector);
>
> if (!new_encoder) {
> DRM_DEBUG_ATOMIC("No suitable encoder found for
> [CONNECTOR:%d:%s]\n",
> diff --git a/drivers/gpu/drm/drm_crtc_helper.c
> b/drivers/gpu/drm/drm_crtc_helper.c
> index a51824a7e7c1..4a7447a53cea 100644
> --- a/drivers/gpu/drm/drm_crtc_helper.c
> +++ b/drivers/gpu/drm/drm_crtc_helper.c
> @@ -460,6 +460,17 @@ drm_crtc_helper_disable(struct drm_crtc *crtc)
> __dr
Re: [Intel-gfx] linux-next: build warning after merge of the drm-misc tree
On Fri, Aug 16, 2019 at 12:47:15PM +0300, Laurent Pinchart wrote:
> On Fri, Aug 16, 2019 at 08:23:54AM +0200, Daniel Vetter wrote:
> > On Fri, Aug 16, 2019 at 6:48 AM Sam Ravnborg wrote:
> > > > Hi all,
> > > >
> > > > After merging the drm-misc tree, today's linux-next build (x86_64
> > > > allmodconfig) produced this warning:
> > > >
> > > > warning: same module names found:
> > > > drivers/video/fbdev/omap2/omapfb/displays/panel-nec-nl8048hl11.ko
> > > > drivers/gpu/drm/panel/panel-nec-nl8048hl11.ko
> > > > warning: same module names found:
> > > > drivers/video/fbdev/omap2/omapfb/displays/panel-sharp-ls037v7dw01.ko
> > > > drivers/gpu/drm/panel/panel-sharp-ls037v7dw01.ko
> > > > warning: same module names found:
> > > > drivers/video/fbdev/omap2/omapfb/displays/panel-sony-acx565akm.ko
> > > > drivers/gpu/drm/panel/panel-sony-acx565akm.ko
> > > > warning: same module names found:
> > > > drivers/video/fbdev/omap2/omapfb/displays/panel-tpo-td028ttec1.ko
> > > > drivers/gpu/drm/panel/panel-tpo-td028ttec1.ko
> > > > warning: same module names found:
> > > > drivers/video/fbdev/omap2/omapfb/displays/panel-tpo-td043mtea1.ko
> > > > drivers/gpu/drm/panel/panel-tpo-td043mtea1.ko
> > > >
> > > > Introduced by commits
> > > >
> > > > df439abe6501 ("drm/panel: Add driver for the NEC NL8048HL11 panel")
> > > > c9cf4c2a3bd3 ("drm/panel: Add driver for the Sharp LS037V7DW01 panel")
> > > > 1c8fc3f0c5d2 ("drm/panel: Add driver for the Sony ACX565AKM panel")
> > > > 415b8dd08711 ("drm/panel: Add driver for the Toppoly TD028TTEC1
> > > > panel")
> > > > dc2e1e5b2799 ("drm/panel: Add driver for the Toppoly TD043MTEA1
> > > > panel")
> > >
> > > Ups, had not seen this one coming.
> > > We are in the process of removing the drivers in
> > > drivers/video/fbdev/omap2/omapfb/
> > > and decided to introduce the new drivers early to get them out of a
> > > longer patch series.
>
> Oops :-(
>
> The new drivers were initially part of a patch series that removed the
> duplicated drivers. The new drivers then got fast-tracked, and I didn't
> notice this issue.
>
> > Should we have a config dependency to not allow the old fbdev omap
> > when the drm omap driver is enabled? I think that would take care of
> > all this.
> >
> > Or too annoying for development?
> >
> > Also note that fbdev is in drm-misc now, so we should be able to fix
> > this all without cross-tree conflicts.
>
> Note that drivers/video/fbdev/omap2/omapfb/ will stay, it's
> drivers/gpu/drm/omapdrm/displays/ that is being removed. FB_OMAP2
> already depends on DRM_OMAP = n, I propose doing something similar at
> the level of the individual display drivers.
I've just posted "[PATCH 0/2] Fix module name clash with omapdrm and DRM
panel modules" that should solve this issue.
--
Regards,
Laurent Pinchart
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] Linux Kernel 5.2.8 (uvc or i915? <<<)
Hi Randy, On Thu, Aug 15, 2019 at 08:10:03PM -0700, Randy Dunlap wrote: > [adding mailing lists etc. with Nathaniel's test info] > > On 8/15/19 7:21 PM, Nathaniel Russell wrote: > > Well i surpressed the uvcvideo driver and you are right Randy it > > definitely is not the uvcvideo driver. There is something going on in > > the i915 driver. > > > > On 8/15/19, Randy Dunlap wrote: > >> On 8/15/19 6:15 PM, Nathaniel Russell wrote: > >>> I would really like help with the kernel error with my uvcvideo driver. > >> > >> Hi again. > >> > >> What makes you think that the problem is related to the uvcvideo driver? > >> Does some previous kernel version work correctly? If so, what version(s)? > >> > >> > >> Does this warning message only happen when the uvcvideo driver is being > >> loaded? > >> Can you suppress loading of the uvcvideo driver to find out? > >> > >> Most of the problems/errors/warnings that I see are related to the i915 > >> driver: > >> > >> [ 13.032341] timed out waiting for port C ready: got 0x20, expected 0xe0 > >> [ 13.032872] WARNING: CPU: 1 PID: 239 at > >> drivers/gpu/drm/i915/intel_display.c:1597 vlv_wait_port_ready+0x99/0xe0 > >> [i915] > >> [ 13.033632] RIP: 0010:vlv_wait_port_ready+0x99/0xe0 [i915] > >> > >> although there are a few uvcvideo warnings: > >> [ 13.039305] uvcvideo 1-5:1.0: Entity type for entity Extension 4 was not > >> initialized! > >> [ 13.039318] uvcvideo 1-5:1.0: Entity type for entity Extension 3 was not > >> initialized! > >> [ 13.039330] uvcvideo 1-5:1.0: Entity type for entity Processing 2 was > >> not > >> initialized! > >> [ 13.039339] uvcvideo 1-5:1.0: Entity type for entity Camera 1 was not > >> initialized! > >> > >> Laurent, do you see any uvc issues here? Any ideas/suggestions? No, uvcvideo seems completely reunlated. > >> @intel-gfx: any ideas about what is going on here with the i915 driver? > >> > >> Original message to lkml: > >> https://lore.kernel.org/lkml/CAONH+Jm-O6=dq+k2n5pntnmg2sq1kcvnfluwevh6w82opef...@mail.gmail.com/T/#u > >> > >> Previous message for 5.1.21 kernel: > >> https://lore.kernel.org/lkml/CAONH+JkTFujY9vEyNNuem+9rJ2qBKkf-PbKk9=DBSVEp6kW=y...@mail.gmail.com/ -- Regards, Laurent Pinchart ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] linux-next: build warning after merge of the drm-misc tree
Hello,
On Fri, Aug 16, 2019 at 08:23:54AM +0200, Daniel Vetter wrote:
> On Fri, Aug 16, 2019 at 6:48 AM Sam Ravnborg wrote:
> > > Hi all,
> > >
> > > After merging the drm-misc tree, today's linux-next build (x86_64
> > > allmodconfig) produced this warning:
> > >
> > > warning: same module names found:
> > > drivers/video/fbdev/omap2/omapfb/displays/panel-nec-nl8048hl11.ko
> > > drivers/gpu/drm/panel/panel-nec-nl8048hl11.ko
> > > warning: same module names found:
> > > drivers/video/fbdev/omap2/omapfb/displays/panel-sharp-ls037v7dw01.ko
> > > drivers/gpu/drm/panel/panel-sharp-ls037v7dw01.ko
> > > warning: same module names found:
> > > drivers/video/fbdev/omap2/omapfb/displays/panel-sony-acx565akm.ko
> > > drivers/gpu/drm/panel/panel-sony-acx565akm.ko
> > > warning: same module names found:
> > > drivers/video/fbdev/omap2/omapfb/displays/panel-tpo-td028ttec1.ko
> > > drivers/gpu/drm/panel/panel-tpo-td028ttec1.ko
> > > warning: same module names found:
> > > drivers/video/fbdev/omap2/omapfb/displays/panel-tpo-td043mtea1.ko
> > > drivers/gpu/drm/panel/panel-tpo-td043mtea1.ko
> > >
> > > Introduced by commits
> > >
> > > df439abe6501 ("drm/panel: Add driver for the NEC NL8048HL11 panel")
> > > c9cf4c2a3bd3 ("drm/panel: Add driver for the Sharp LS037V7DW01 panel")
> > > 1c8fc3f0c5d2 ("drm/panel: Add driver for the Sony ACX565AKM panel")
> > > 415b8dd08711 ("drm/panel: Add driver for the Toppoly TD028TTEC1 panel")
> > > dc2e1e5b2799 ("drm/panel: Add driver for the Toppoly TD043MTEA1 panel")
> >
> > Ups, had not seen this one coming.
> > We are in the process of removing the drivers in
> > drivers/video/fbdev/omap2/omapfb/
> > and decided to introduce the new drivers early to get them out of a
> > longer patch series.
Oops :-(
The new drivers were initially part of a patch series that removed the
duplicated drivers. The new drivers then got fast-tracked, and I didn't
notice this issue.
> Should we have a config dependency to not allow the old fbdev omap
> when the drm omap driver is enabled? I think that would take care of
> all this.
>
> Or too annoying for development?
>
> Also note that fbdev is in drm-misc now, so we should be able to fix
> this all without cross-tree conflicts.
Note that drivers/video/fbdev/omap2/omapfb/ will stay, it's
drivers/gpu/drm/omapdrm/displays/ that is being removed. FB_OMAP2
already depends on DRM_OMAP = n, I propose doing something similar at
the level of the individual display drivers.
--
Regards,
Laurent Pinchart
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v6 00/24] Associate ddc adapters with connectors
; > > drivers/gpu/drm/exynos/exynos_hdmi.c | 6 +- > > drivers/gpu/drm/gma500/cdv_intel_dp.c:3 > drivers/gpu/drm/gma500/cdv_intel_hdmi.c:2 > drivers/gpu/drm/gma500/oaktrail_hdmi.c:1 > drivers/gpu/drm/gma500/oaktrail_lvds.c:2 > drivers/gpu/drm/gma500/psb_intel_modes.c:1 > drivers/gpu/drm/gma500/psb_intel_sdvo.c:2 > - should be updated at some point (as you pointed out). > > > drivers/gpu/drm/i915/display/intel_hdmi.c | 12 +- > drivers/gpu/drm/i915/intel_connector.c:1 > drivers/gpu/drm/i915/intel_crt.c:2 > - not too sure here > > drivers/gpu/drm/i915/intel_dp.c:2 > - not applicable: aux dp/mst > > drivers/gpu/drm/i915/intel_lvds.c:1 > drivers/gpu/drm/i915/intel_sdvo.c:2 > - not too sure here > > > > drivers/gpu/drm/imx/imx-ldb.c | 7 +- > > drivers/gpu/drm/imx/imx-tve.c | 6 +- > > drivers/gpu/drm/mediatek/mtk_hdmi.c | 7 +- > > drivers/gpu/drm/mgag200/mgag200_mode.c| 13 +- > > drivers/gpu/drm/msm/hdmi/hdmi_connector.c | 6 +- > drivers/gpu/drm/msm/edp/edp_ctrl.c:1 > - not applicable: aux dp/mst > > drivers/gpu/drm/nouveau/nouveau_connector.c:2 > - should be updated at some point (as you pointed out). > > > drivers/gpu/drm/panel/panel-simple.c:1 > - no applicable: panel driver > > > > drivers/gpu/drm/radeon/radeon_connectors.c| 142 +- > > drivers/gpu/drm/rockchip/inno_hdmi.c | 6 +- > > drivers/gpu/drm/rockchip/rk3066_hdmi.c| 7 +- > > drivers/gpu/drm/sti/sti_hdmi.c| 6 +- > > drivers/gpu/drm/sun4i/sun4i_hdmi_enc.c| 7 +- > > drivers/gpu/drm/tegra/hdmi.c | 7 +- > > drivers/gpu/drm/tegra/sor.c | 7 +- > > drivers/gpu/drm/tegra/output.c:1 > - already handled in hdmi/sor > > > drivers/gpu/drm/tilcdc/tilcdc_tfp410.c| 6 +- > > drivers/gpu/drm/vc4/vc4_hdmi.c| 12 +- > > drivers/gpu/drm/zte/zx_hdmi.c | 6 +- > > drivers/gpu/drm/zte/zx_vga.c | 6 +- > > include/drm/drm_connector.h | 18 +++ > > 26 files changed, 336 insertions(+), 121 deletions(-) > > In a Tl;Dr: I think this series covers 90%+ of the existing rather huge) > driverset. > > For the series: > Reviewed-by: Emil Velikov > > Fwiw I'm in favour of Jani's suggestion to fold the dcc into the usual > helper drm_connector_init(). Although since we have 130+ instances it > might be better left for another day. > > HTH > -Emil -- Regards, Laurent Pinchart ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v6 00/24] Associate ddc adapters with connectors
ctors.c| 96 > drivers/gpu/drm/ast/ast_mode.c| 13 +- > drivers/gpu/drm/bridge/dumb-vga-dac.c | 6 +- > drivers/gpu/drm/bridge/synopsys/dw-hdmi.c | 6 +- > drivers/gpu/drm/bridge/ti-tfp410.c| 6 +- > drivers/gpu/drm/drm_connector.c | 35 + > drivers/gpu/drm/drm_sysfs.c | 8 + > drivers/gpu/drm/exynos/exynos_hdmi.c | 6 +- > drivers/gpu/drm/i915/display/intel_hdmi.c | 12 +- > drivers/gpu/drm/imx/imx-ldb.c | 7 +- > drivers/gpu/drm/imx/imx-tve.c | 6 +- > drivers/gpu/drm/mediatek/mtk_hdmi.c | 7 +- > drivers/gpu/drm/mgag200/mgag200_mode.c| 13 +- > drivers/gpu/drm/msm/hdmi/hdmi_connector.c | 6 +- > drivers/gpu/drm/radeon/radeon_connectors.c| 142 +- > drivers/gpu/drm/rockchip/inno_hdmi.c | 6 +- > drivers/gpu/drm/rockchip/rk3066_hdmi.c| 7 +- > drivers/gpu/drm/sti/sti_hdmi.c| 6 +- > drivers/gpu/drm/sun4i/sun4i_hdmi_enc.c| 7 +- > drivers/gpu/drm/tegra/hdmi.c | 7 +- > drivers/gpu/drm/tegra/sor.c | 7 +- > drivers/gpu/drm/tilcdc/tilcdc_tfp410.c| 6 +- > drivers/gpu/drm/vc4/vc4_hdmi.c| 12 +- > drivers/gpu/drm/zte/zx_hdmi.c | 6 +- > drivers/gpu/drm/zte/zx_vga.c | 6 +- > include/drm/drm_connector.h | 18 +++ > 26 files changed, 336 insertions(+), 121 deletions(-) -- Regards, Laurent Pinchart ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v6 01/24] drm: Add ddc link in sysfs created by drm_connector
Hi Andrzej,
On Sun, Aug 04, 2019 at 03:04:37PM +0300, Laurent Pinchart wrote:
> Hi Andrzej,
>
> Thank you for the patch, and sorry for the late review (I've been
> travelling for the past few weeks).
>
> On Fri, Jul 26, 2019 at 07:22:55PM +0200, Andrzej Pietrasiewicz wrote:
> > Add generic code which creates symbolic links in sysfs, pointing to ddc
> > interface used by a particular video output. For example:
> >
> > ls -l /sys/class/drm/card0-HDMI-A-1/ddc
> > lrwxrwxrwx 1 root root 0 Jun 24 10:42 /sys/class/drm/card0-HDMI-A-1/ddc \
> > -> ../../../../soc/1388.i2c/i2c-2
> >
> > This makes it easy for user to associate a display with its ddc adapter
> > and use e.g. ddcutil to control the chosen monitor.
> >
> > This patch adds an i2c_adapter pointer to struct drm_connector. Particular
> > drivers can then use it instead of using their own private instance. If a
> > connector contains a ddc, then create a symbolic link in sysfs.
> >
> > Signed-off-by: Andrzej Pietrasiewicz
> > Acked-by: Daniel Vetter
> > Reviewed-by: Andrzej Hajda
> > ---
> > drivers/gpu/drm/drm_sysfs.c | 8
> > include/drm/drm_connector.h | 11 +++
> > 2 files changed, 19 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/drm_sysfs.c b/drivers/gpu/drm/drm_sysfs.c
> > index ad10810bc972..e962a9d45f7e 100644
> > --- a/drivers/gpu/drm/drm_sysfs.c
> > +++ b/drivers/gpu/drm/drm_sysfs.c
> > @@ -14,6 +14,7 @@
> > #include
> > #include
> > #include
> > +#include
> > #include
> > #include
> >
> > @@ -294,6 +295,9 @@ int drm_sysfs_connector_add(struct drm_connector
> > *connector)
> > /* Let userspace know we have a new connector */
> > drm_sysfs_hotplug_event(dev);
> >
> > + if (connector->ddc)
> > + return sysfs_create_link(>kdev->kobj,
> > +>ddc->dev.kobj, "ddc");
> > return 0;
> > }
> >
> > @@ -301,6 +305,10 @@ void drm_sysfs_connector_remove(struct drm_connector
> > *connector)
> > {
> > if (!connector->kdev)
> > return;
> > +
> > + if (connector->ddc)
> > + sysfs_remove_link(>kdev->kobj, "ddc");
> > +
> > DRM_DEBUG("removing \"%s\" from sysfs\n",
> > connector->name);
> >
> > diff --git a/include/drm/drm_connector.h b/include/drm/drm_connector.h
> > index 4c30d751487a..33a6fff85fdb 100644
> > --- a/include/drm/drm_connector.h
> > +++ b/include/drm/drm_connector.h
> > @@ -41,6 +41,7 @@ struct drm_property;
> > struct drm_property_blob;
> > struct drm_printer;
> > struct edid;
> > +struct i2c_adapter;
> >
> > enum drm_connector_force {
> > DRM_FORCE_UNSPECIFIED,
> > @@ -1311,6 +1312,16 @@ struct drm_connector {
> > * [0]: progressive, [1]: interlaced
> > */
> > int audio_latency[2];
> > +
> > + /**
> > +* @ddc: associated ddc adapter.
> > +* A connector usually has its associated ddc adapter. If a driver uses
> > +* this field, then an appropriate symbolic link is created in connector
> > +* sysfs directory to make it easy for the user to tell which i2c
> > +* adapter is for a particular display.
>
> The first sentence isn't very clear. The rest is mixing "ddc adapter"
> and "i2c adapter". How about the following ?
>
> "When the connector carries DDC signals, this field points to the I2C
> adapter connected to the DDC signals, if any. When this field is not
> NULL a symbolic link is created in the connector's sysfs directory to
> expose the I2C adapter used by the connector."
>
> Should we also mention that the field isn't meant to be set directly,
> but shall be set with drm_connector_init_with_ddc() ?
>
> "This field shall not be set directly by drivers, use
> drm_connector_init_with_ddc() instead."
I should have read patch 02/24 before answering this :-)
> I'm also slightly concerned about the lifetime of this pointer, and what
> would happen if the I2C adapter disappears while the connector is still
> exposed to userspace, but I suppose this isn't a new issue, existing
> code likely suffers from this.
>
> With the updated documentation,
>
> Reviewed-by: Laurent Pinchart
I've just realised that this patch has been applied already. I'll send
the above as a documentation update patch.
> > +*/
> > + struct i2c_adapter *ddc;
> > +
> > /**
> > * @null_edid_counter: track sinks that give us all zeros for the EDID.
> > * Needed to workaround some HW bugs where we get all 0s
--
Regards,
Laurent Pinchart
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v6 01/24] drm: Add ddc link in sysfs created by drm_connector
Hi Andrzej,
Thank you for the patch, and sorry for the late review (I've been
travelling for the past few weeks).
On Fri, Jul 26, 2019 at 07:22:55PM +0200, Andrzej Pietrasiewicz wrote:
> Add generic code which creates symbolic links in sysfs, pointing to ddc
> interface used by a particular video output. For example:
>
> ls -l /sys/class/drm/card0-HDMI-A-1/ddc
> lrwxrwxrwx 1 root root 0 Jun 24 10:42 /sys/class/drm/card0-HDMI-A-1/ddc \
> -> ../../../../soc/1388.i2c/i2c-2
>
> This makes it easy for user to associate a display with its ddc adapter
> and use e.g. ddcutil to control the chosen monitor.
>
> This patch adds an i2c_adapter pointer to struct drm_connector. Particular
> drivers can then use it instead of using their own private instance. If a
> connector contains a ddc, then create a symbolic link in sysfs.
>
> Signed-off-by: Andrzej Pietrasiewicz
> Acked-by: Daniel Vetter
> Reviewed-by: Andrzej Hajda
> ---
> drivers/gpu/drm/drm_sysfs.c | 8
> include/drm/drm_connector.h | 11 +++
> 2 files changed, 19 insertions(+)
>
> diff --git a/drivers/gpu/drm/drm_sysfs.c b/drivers/gpu/drm/drm_sysfs.c
> index ad10810bc972..e962a9d45f7e 100644
> --- a/drivers/gpu/drm/drm_sysfs.c
> +++ b/drivers/gpu/drm/drm_sysfs.c
> @@ -14,6 +14,7 @@
> #include
> #include
> #include
> +#include
> #include
> #include
>
> @@ -294,6 +295,9 @@ int drm_sysfs_connector_add(struct drm_connector
> *connector)
> /* Let userspace know we have a new connector */
> drm_sysfs_hotplug_event(dev);
>
> + if (connector->ddc)
> + return sysfs_create_link(>kdev->kobj,
> + >ddc->dev.kobj, "ddc");
> return 0;
> }
>
> @@ -301,6 +305,10 @@ void drm_sysfs_connector_remove(struct drm_connector
> *connector)
> {
> if (!connector->kdev)
> return;
> +
> + if (connector->ddc)
> + sysfs_remove_link(>kdev->kobj, "ddc");
> +
> DRM_DEBUG("removing \"%s\" from sysfs\n",
> connector->name);
>
> diff --git a/include/drm/drm_connector.h b/include/drm/drm_connector.h
> index 4c30d751487a..33a6fff85fdb 100644
> --- a/include/drm/drm_connector.h
> +++ b/include/drm/drm_connector.h
> @@ -41,6 +41,7 @@ struct drm_property;
> struct drm_property_blob;
> struct drm_printer;
> struct edid;
> +struct i2c_adapter;
>
> enum drm_connector_force {
> DRM_FORCE_UNSPECIFIED,
> @@ -1311,6 +1312,16 @@ struct drm_connector {
>* [0]: progressive, [1]: interlaced
>*/
> int audio_latency[2];
> +
> + /**
> + * @ddc: associated ddc adapter.
> + * A connector usually has its associated ddc adapter. If a driver uses
> + * this field, then an appropriate symbolic link is created in connector
> + * sysfs directory to make it easy for the user to tell which i2c
> + * adapter is for a particular display.
The first sentence isn't very clear. The rest is mixing "ddc adapter"
and "i2c adapter". How about the following ?
"When the connector carries DDC signals, this field points to the I2C
adapter connected to the DDC signals, if any. When this field is not
NULL a symbolic link is created in the connector's sysfs directory to
expose the I2C adapter used by the connector."
Should we also mention that the field isn't meant to be set directly,
but shall be set with drm_connector_init_with_ddc() ?
"This field shall not be set directly by drivers, use
drm_connector_init_with_ddc() instead."
I'm also slightly concerned about the lifetime of this pointer, and what
would happen if the I2C adapter disappears while the connector is still
exposed to userspace, but I suppose this isn't a new issue, existing
code likely suffers from this.
With the updated documentation,
Reviewed-by: Laurent Pinchart
> + */
> + struct i2c_adapter *ddc;
> +
> /**
>* @null_edid_counter: track sinks that give us all zeros for the EDID.
>* Needed to workaround some HW bugs where we get all 0s
--
Regards,
Laurent Pinchart
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 28/59] drm/shmob: Drop drm_gem_prime_export/import
Hi Daniel,
Thank you for the patch.
On Fri, Jun 14, 2019 at 10:35:44PM +0200, Daniel Vetter wrote:
> They're the default.
>
> Aside: Would be really nice to switch the others over to
> drm_gem_object_funcs.
>
> Signed-off-by: Daniel Vetter
> Cc: Laurent Pinchart
> Cc: Kieran Bingham
> Cc: linux-renesas-...@vger.kernel.org
Reviewed-by: Laurent Pinchart
Feel free to merged this as part of the series.
> ---
> drivers/gpu/drm/shmobile/shmob_drm_drv.c | 2 --
> 1 file changed, 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/shmobile/shmob_drm_drv.c
> b/drivers/gpu/drm/shmobile/shmob_drm_drv.c
> index 9047a49ff35e..6c106b7a3bfe 100644
> --- a/drivers/gpu/drm/shmobile/shmob_drm_drv.c
> +++ b/drivers/gpu/drm/shmobile/shmob_drm_drv.c
> @@ -133,8 +133,6 @@ static struct drm_driver shmob_drm_driver = {
> .gem_vm_ops = _gem_cma_vm_ops,
> .prime_handle_to_fd = drm_gem_prime_handle_to_fd,
> .prime_fd_to_handle = drm_gem_prime_fd_to_handle,
> - .gem_prime_import = drm_gem_prime_import,
> - .gem_prime_export = drm_gem_prime_export,
> .gem_prime_get_sg_table = drm_gem_cma_prime_get_sg_table,
> .gem_prime_import_sg_table = drm_gem_cma_prime_import_sg_table,
> .gem_prime_vmap = drm_gem_cma_prime_vmap,
--
Regards,
Laurent Pinchart
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 26/59] drm/rcar-du: Drop drm_gem_prime_export/import
Hi Daniel,
Thank you for the patch.
On Fri, Jun 14, 2019 at 10:35:42PM +0200, Daniel Vetter wrote:
> They're the default.
>
> Aside: Would be really nice to switch the others over to
> drm_gem_object_funcs.
>
> Signed-off-by: Daniel Vetter
> Cc: Laurent Pinchart
> Cc: Kieran Bingham
> Cc: linux-renesas-...@vger.kernel.org
Reviewed-by: Laurent Pinchart
Feel free to merged this as part of the series.
> ---
> drivers/gpu/drm/rcar-du/rcar_du_drv.c | 2 --
> 1 file changed, 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/rcar-du/rcar_du_drv.c
> b/drivers/gpu/drm/rcar-du/rcar_du_drv.c
> index 83685250319d..9c93eb4fad8b 100644
> --- a/drivers/gpu/drm/rcar-du/rcar_du_drv.c
> +++ b/drivers/gpu/drm/rcar-du/rcar_du_drv.c
> @@ -446,8 +446,6 @@ static struct drm_driver rcar_du_driver = {
> .gem_vm_ops = _gem_cma_vm_ops,
> .prime_handle_to_fd = drm_gem_prime_handle_to_fd,
> .prime_fd_to_handle = drm_gem_prime_fd_to_handle,
> - .gem_prime_import = drm_gem_prime_import,
> - .gem_prime_export = drm_gem_prime_export,
> .gem_prime_get_sg_table = drm_gem_cma_prime_get_sg_table,
> .gem_prime_import_sg_table = drm_gem_cma_prime_import_sg_table,
> .gem_prime_vmap = drm_gem_cma_prime_vmap,
--
Regards,
Laurent Pinchart
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/rcar-du: Fix error check when retrieving crtc state
Hi Sean,
Thank you for the patch.
On Mon, Jun 17, 2019 at 02:15:42PM -0400, Sean Paul wrote:
> From: Sean Paul
>
> drm_atomic_get_crtc_state() returns an error pointer when it fails, so
> the null check is doing nothing here.
>
> Credit to 0-day/Dan Carpenter for reporting this.
>
> Fixes: 6f3b62781bbd ("drm: Convert connector_helper_funcs->atomic_check to
> accept drm_atomic_state")
> Cc: Daniel Vetter
> Cc: Ville Syrjälä
> Cc: Jani Nikula
> Cc: Joonas Lahtinen
> Cc: Rodrigo Vivi
> Cc: Ben Skeggs
> Cc: Laurent Pinchart
> Cc: Kieran Bingham
> Cc: Eric Anholt
> Cc: Laurent Pinchart [for rcar lvds]
> Cc: Sean Paul
> Cc: Maarten Lankhorst
> Cc: Maxime Ripard
> Cc: Sean Paul
> Cc: David Airlie
> Cc: Lyude Paul
> Cc: Karol Herbst
> Cc: Ilia Mirkin
> Cc: dri-de...@lists.freedesktop.org
> Cc: intel-gfx@lists.freedesktop.org
> Cc: linux-renesas-...@vger.kernel.org
> Reported-by: kbuild test robot
> Reported-by: Dan Carpenter
> Signed-off-by: Sean Paul
Reviewed-by: Laurent Pinchart
I have no pending conflicting changes for rcar_lvds.c. Do you plan to
merge this through drm-misc ?
> ---
> drivers/gpu/drm/rcar-du/rcar_lvds.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/rcar-du/rcar_lvds.c
> b/drivers/gpu/drm/rcar-du/rcar_lvds.c
> index f2a5d4d997073..1c62578590f46 100644
> --- a/drivers/gpu/drm/rcar-du/rcar_lvds.c
> +++ b/drivers/gpu/drm/rcar-du/rcar_lvds.c
> @@ -115,8 +115,8 @@ static int rcar_lvds_connector_atomic_check(struct
> drm_connector *connector,
>
> /* We're not allowed to modify the resolution. */
> crtc_state = drm_atomic_get_crtc_state(state, conn_state->crtc);
> - if (!crtc_state)
> - return -EINVAL;
> + if (IS_ERR(crtc_state))
> + return PTR_ERR(crtc_state);
>
> if (crtc_state->mode.hdisplay != panel_mode->hdisplay ||
> crtc_state->mode.vdisplay != panel_mode->vdisplay)
--
Regards,
Laurent Pinchart
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v5 04/11] drm: Convert connector_helper_funcs->atomic_check to accept drm_atomic_state
Hi Sean,
Thank you for the patch.
On Tue, Jun 11, 2019 at 12:08:18PM -0400, Sean Paul wrote:
> From: Sean Paul
>
> Everyone who implements connector_helper_funcs->atomic_check reaches
> into the connector state to get the atomic state. Instead of continuing
> this pattern, change the callback signature to just give atomic state
> and let the driver determine what it does and does not need from it.
>
> Eventually all atomic functions should do this, but that's just too much
> busy work for me.
>
> Changes in v3:
> - Added to the set
> Changes in v4:
> - None
> Changes in v5:
> - intel_digital_connector_atomic_check declaration moved to i915_atomic.h
>
> Link to v3:
> https://patchwork.freedesktop.org/patch/msgid/20190502194956.218441-5-s...@poorly.run
> Link to v4:
> https://patchwork.freedesktop.org/patch/msgid/20190508160920.144739-5-s...@poorly.run
>
> Cc: Daniel Vetter
> Cc: Ville Syrjälä
> Cc: Jani Nikula
> Cc: Joonas Lahtinen
> Cc: Rodrigo Vivi
> Cc: Ben Skeggs
> Cc: Laurent Pinchart
> Cc: Kieran Bingham
> Cc: Eric Anholt
> Tested-by: Heiko Stuebner
> Acked-by: Daniel Vetter
> Signed-off-by: Sean Paul
> ---
> drivers/gpu/drm/drm_atomic_helper.c | 4 ++--
> drivers/gpu/drm/i915/intel_atomic.c | 8 +---
> drivers/gpu/drm/i915/intel_atomic.h | 2 +-
> drivers/gpu/drm/i915/intel_dp_mst.c | 7 ---
> drivers/gpu/drm/i915/intel_sdvo.c| 9 +
> drivers/gpu/drm/i915/intel_tv.c | 8 +---
> drivers/gpu/drm/nouveau/dispnv50/disp.c | 5 +++--
> drivers/gpu/drm/rcar-du/rcar_lvds.c | 12 +++-
For the R-Car LVDS driver,
Reviewed-by: Laurent Pinchart
> drivers/gpu/drm/vc4/vc4_txp.c| 7 ---
> include/drm/drm_modeset_helper_vtables.h | 2 +-
> 10 files changed, 37 insertions(+), 27 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_atomic_helper.c
> b/drivers/gpu/drm/drm_atomic_helper.c
> index 2133f62539176..e58be69960692 100644
> --- a/drivers/gpu/drm/drm_atomic_helper.c
> +++ b/drivers/gpu/drm/drm_atomic_helper.c
> @@ -686,7 +686,7 @@ drm_atomic_helper_check_modeset(struct drm_device *dev,
> }
>
> if (funcs->atomic_check)
> - ret = funcs->atomic_check(connector,
> new_connector_state);
> + ret = funcs->atomic_check(connector, state);
> if (ret)
> return ret;
>
> @@ -728,7 +728,7 @@ drm_atomic_helper_check_modeset(struct drm_device *dev,
> continue;
>
> if (funcs->atomic_check)
> - ret = funcs->atomic_check(connector,
> new_connector_state);
> + ret = funcs->atomic_check(connector, state);
> if (ret)
> return ret;
> }
> diff --git a/drivers/gpu/drm/i915/intel_atomic.c
> b/drivers/gpu/drm/i915/intel_atomic.c
> index 58b8049649a0f..ab40448a19d56 100644
> --- a/drivers/gpu/drm/i915/intel_atomic.c
> +++ b/drivers/gpu/drm/i915/intel_atomic.c
> @@ -106,12 +106,14 @@ int intel_digital_connector_atomic_set_property(struct
> drm_connector *connector,
> }
>
> int intel_digital_connector_atomic_check(struct drm_connector *conn,
> - struct drm_connector_state *new_state)
> + struct drm_atomic_state *state)
> {
> + struct drm_connector_state *new_state =
> + drm_atomic_get_new_connector_state(state, conn);
> struct intel_digital_connector_state *new_conn_state =
> to_intel_digital_connector_state(new_state);
> struct drm_connector_state *old_state =
> - drm_atomic_get_old_connector_state(new_state->state, conn);
> + drm_atomic_get_old_connector_state(state, conn);
> struct intel_digital_connector_state *old_conn_state =
> to_intel_digital_connector_state(old_state);
> struct drm_crtc_state *crtc_state;
> @@ -121,7 +123,7 @@ int intel_digital_connector_atomic_check(struct
> drm_connector *conn,
> if (!new_state->crtc)
> return 0;
>
> - crtc_state = drm_atomic_get_new_crtc_state(new_state->state,
> new_state->crtc);
> + crtc_state = drm_atomic_get_new_crtc_state(state, new_state->crtc);
>
> /*
>* These properties are handled by fastset, and might not end
> diff --git a/drivers/gpu/drm/i915/intel_atomic.h
> b/drivers/gpu/drm/i915/intel_atomic.h
> index 1c8507da1a690..58065d3161a34 100644
> --- a/drivers/gpu/drm/i915/intel_atomic.h
> +++ b/drivers/gpu/drm/i915/intel_atomic.h
> @@ -28,7 +28,7 @@
Re: [Intel-gfx] [PATCH v8 2/6] drm: Rename struct edp_vsc_psr to struct dp_sdp
s/gpu/drm/bridge/analogix/analogix_dp_reg.c
> > +++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c
> > @@ -1041,7 +1041,7 @@ static ssize_t analogix_dp_get_psr_status(struct
> > analogix_dp_device *dp)
> > }
> >
> > int analogix_dp_send_psr_spd(struct analogix_dp_device *dp,
> > -struct edp_vsc_psr *vsc, bool blocking)
> > +struct dp_sdp *vsc, bool blocking)
> > {
> > unsigned int val;
> > int ret;
> > @@ -1069,8 +1069,8 @@ int analogix_dp_send_psr_spd(struct
> > analogix_dp_device *dp,
> > writel(0x5D, dp->reg_base + ANALOGIX_DP_SPD_PB3);
> >
> > /* configure DB0 / DB1 values */
> > - writel(vsc->DB0, dp->reg_base + ANALOGIX_DP_VSC_SHADOW_DB0);
> > - writel(vsc->DB1, dp->reg_base + ANALOGIX_DP_VSC_SHADOW_DB1);
> > + writel(vsc->DB[0], dp->reg_base + ANALOGIX_DP_VSC_SHADOW_DB0);
> > + writel(vsc->DB[1], dp->reg_base + ANALOGIX_DP_VSC_SHADOW_DB1);
> >
> > /* set reuse spd inforframe */
> > val = readl(dp->reg_base + ANALOGIX_DP_VIDEO_CTL_3);
> > @@ -1092,8 +1092,8 @@ int analogix_dp_send_psr_spd(struct
> > analogix_dp_device *dp,
> >
> > ret = readx_poll_timeout(analogix_dp_get_psr_status, dp, psr_status,
> > psr_status >= 0 &&
> > - ((vsc->DB1 && psr_status == DP_PSR_SINK_ACTIVE_RFB) ||
> > - (!vsc->DB1 && psr_status == DP_PSR_SINK_INACTIVE)), 1500,
> > + ((vsc->DB[1] && psr_status == DP_PSR_SINK_ACTIVE_RFB) ||
> > + (!vsc->DB[1] && psr_status == DP_PSR_SINK_INACTIVE)), 1500,
> > DP_TIMEOUT_PSR_LOOP_MS * 1000);
> > if (ret) {
> > dev_warn(dp->dev, "Failed to apply PSR %d\n", ret);
> > diff --git a/drivers/gpu/drm/i915/intel_psr.c
> > b/drivers/gpu/drm/i915/intel_psr.c
> > index 2a547a128a37..01ca502099df 100644
> > --- a/drivers/gpu/drm/i915/intel_psr.c
> > +++ b/drivers/gpu/drm/i915/intel_psr.c
> > @@ -342,7 +342,7 @@ static void intel_psr_setup_vsc(struct intel_dp
> > *intel_dp,
> > {
> > struct intel_digital_port *intel_dig_port = dp_to_dig_port(intel_dp);
> > struct drm_i915_private *dev_priv = dp_to_i915(intel_dp);
> > - struct edp_vsc_psr psr_vsc;
> > + struct dp_sdp psr_vsc;
> >
> > if (dev_priv->psr.psr2_enabled) {
> > /* Prepare VSC Header for SU as per EDP 1.4 spec, Table 6.11 */
> > diff --git a/include/drm/drm_dp_helper.h b/include/drm/drm_dp_helper.h
> > index 97ce790a5b5a..8d7c47e46f2d 100644
> > --- a/include/drm/drm_dp_helper.h
> > +++ b/include/drm/drm_dp_helper.h
> > @@ -1083,17 +1083,30 @@ struct dp_sdp_header {
> > #define EDP_SDP_HEADER_VALID_PAYLOAD_BYTES 0x1F
> > #define DP_SDP_PPS_HEADER_PAYLOAD_BYTES_MINUS_1 0x7F
> >
> > -struct edp_vsc_psr {
> > +/**
> > + * struct dp_sdp - DP secondary data packet
> > + * @sdp_header: DP secondary data packet header
> > + * @DB: DP secondaray data packet data blocks
> > + * VSC SDP Payload for PSR
> > + * DB[0]: Stereo Interface
> > + * DB[1]: 0 - PSR State; 1 - Update RFB; 2 - CRC Valid
> > + * DB[2]: CRC value bits 7:0 of the R or Cr component
> > + * DB[3]: CRC value bits 15:8 of the R or Cr component
> > + * DB[4]: CRC value bits 7:0 of the G or Y component
> > + * DB[5]: CRC value bits 15:8 of the G or Y component
> > + * DB[6]: CRC value bits 7:0 of the B or Cb component
> > + * DB[7]: CRC value bits 15:8 of the B or Cb component
> > + * DB[8] - DB[31]: Reserved
> > + * VSC SDP Payload for Pixel Encoding/Colorimetry Format
> > + * DB[0] - DB[15]: Reserved
> > + * DB[16]: Pixel Encoding and Colorimetry Formats
> > + * DB[17]: Dynamic Range and Component Bit Depth
> > + * DB[18]: Content Type
> > + * DB[19] - DB[31]: Reserved
> > + */
> > +struct dp_sdp {
> > struct dp_sdp_header sdp_header;
> > - u8 DB0; /* Stereo Interface */
> > - u8 DB1; /* 0 - PSR State; 1 - Update RFB; 2 - CRC Valid */
> > - u8 DB2; /* CRC value bits 7:0 of the R or Cr component */
> > - u8 DB3; /* CRC value bits 15:8 of the R or Cr component */
> > - u8 DB4; /* CRC value bits 7:0 of the G or Y component */
> > - u8 DB5; /* CRC value bits 15:8 of the G or Y component */
> > - u8 DB6; /* CRC value bits 7:0 of the B or Cb component */
> > - u8 DB7; /* CRC value bits 15:8 of the B or Cb component */
> > - u8 DB8_31[24]; /* Reserved */
> > + u8 DB[32];
While at it, would it make sense to rename DB to db ?
Apart from that,
Acked-by: Laurent Pinchart
> > } __packed;
> >
> > #define EDP_VSC_PSR_STATE_ACTIVE (1<<0)
>
> --
> Jani Nikula, Intel Open Source Graphics Center
--
Regards,
Laurent Pinchart
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v3 04/10] drm: Convert connector_helper_funcs->atomic_check to accept drm_atomic_state
Hi Daniel, On Mon, May 13, 2019 at 04:47:47PM +0200, Daniel Vetter wrote: > On Sat, May 11, 2019 at 10:12:02PM +0300, Laurent Pinchart wrote: > > On Thu, May 02, 2019 at 03:49:46PM -0400, Sean Paul wrote: > >> From: Sean Paul > >> > >> Everyone who implements connector_helper_funcs->atomic_check reaches > >> into the connector state to get the atomic state. Instead of continuing > >> this pattern, change the callback signature to just give atomic state > >> and let the driver determine what it does and does not need from it. > >> > >> Eventually all atomic functions should do this, but that's just too much > >> busy work for me. > > > > Given that drivers also access the connector state, isn't this slightly > > more inefficient ? > > It's atomic code, we're trying to optimize for clean code at the expense > of a bit of runtime overhead due to more pointer chasing. And I agree with > the general push, the pile of old/new_state pointers of various objects > we're passing around is confusing. Passing the overall drm_atomic_state > seems much more reasonable, and with that we can get everything else. Plus > it's much more obvious whether you have the old/new state (since that's > explicit when you look it up from the drm_atomic_state). Yes, I agree it's cleaner. I just hope the atomic state tracking cost can be kept under control :-) By the way, this is likely not going to happen as it would be way too intrusive, but it would be nice to rename drm_atomic_state to drm_atomic_transaction (or something similar). It doesn't model a state, but a change between an old state to a new state. This confused me in the past, and I'm sure it can still be confusing to newcomers. > If we ever see this show up in profile, and it starts mattering, first > thing we need is a hashtable I think (atm it's list walking, which is just > terrible). But thus far no one cares. > > >> Changes in v3: > >> - Added to the set > >> > >> Cc: Daniel Vetter > >> Cc: Ville Syrjälä > >> Cc: Jani Nikula > >> Cc: Joonas Lahtinen > >> Cc: Rodrigo Vivi > >> Cc: Ben Skeggs > >> Cc: Laurent Pinchart > >> Cc: Kieran Bingham > >> Cc: Eric Anholt > >> Signed-off-by: Sean Paul > >> --- > >> drivers/gpu/drm/drm_atomic_helper.c | 4 ++-- > >> drivers/gpu/drm/i915/intel_atomic.c | 8 +--- > >> drivers/gpu/drm/i915/intel_dp_mst.c | 7 --- > >> drivers/gpu/drm/i915/intel_drv.h | 2 +- > >> drivers/gpu/drm/i915/intel_sdvo.c| 9 + > >> drivers/gpu/drm/i915/intel_tv.c | 8 +--- > >> drivers/gpu/drm/nouveau/dispnv50/disp.c | 5 +++-- > >> drivers/gpu/drm/rcar-du/rcar_lvds.c | 12 +++- > >> drivers/gpu/drm/vc4/vc4_txp.c| 7 --- > >> include/drm/drm_modeset_helper_vtables.h | 2 +- > >> 10 files changed, 37 insertions(+), 27 deletions(-) > >> > >> diff --git a/drivers/gpu/drm/drm_atomic_helper.c > >> b/drivers/gpu/drm/drm_atomic_helper.c > >> index 9d9e47276839..fa5a367507c1 100644 > >> --- a/drivers/gpu/drm/drm_atomic_helper.c > >> +++ b/drivers/gpu/drm/drm_atomic_helper.c > >> @@ -683,7 +683,7 @@ drm_atomic_helper_check_modeset(struct drm_device *dev, > >>} > >> > >>if (funcs->atomic_check) > >> - ret = funcs->atomic_check(connector, > >> new_connector_state); > >> + ret = funcs->atomic_check(connector, state); > >>if (ret) > >>return ret; > >> > >> @@ -725,7 +725,7 @@ drm_atomic_helper_check_modeset(struct drm_device *dev, > >>continue; > >> > >>if (funcs->atomic_check) > >> - ret = funcs->atomic_check(connector, > >> new_connector_state); > >> + ret = funcs->atomic_check(connector, state); > >>if (ret) > >>return ret; > >>} > >> diff --git a/drivers/gpu/drm/i915/intel_atomic.c > >> b/drivers/gpu/drm/i915/intel_atomic.c > >> index b844e8840c6f..e8a5b82e9242 100644 > >> --- a/drivers/gpu/drm/i915/intel_atomic.c > >> +++ b/drivers/gpu/drm/i915/intel_atomic.c > >> @@ -103,12 +103,14 @@ int > >> intel_digital_connector_atomic_set_property(struct drm_connector > >> *connector, > >> } > >> > >
Re: [Intel-gfx] [PATCH v3 04/10] drm: Convert connector_helper_funcs->atomic_check to accept drm_atomic_state
Hi Sean,
On Mon, May 13, 2019 at 10:38:58AM -0400, Sean Paul wrote:
> On Sat, May 11, 2019 at 3:12 PM Laurent Pinchart wrote:
> > On Thu, May 02, 2019 at 03:49:46PM -0400, Sean Paul wrote:
> >> From: Sean Paul
> >>
> >> Everyone who implements connector_helper_funcs->atomic_check reaches
> >> into the connector state to get the atomic state. Instead of continuing
> >> this pattern, change the callback signature to just give atomic state
> >> and let the driver determine what it does and does not need from it.
> >>
> >> Eventually all atomic functions should do this, but that's just too much
> >> busy work for me.
> >
> > Given that drivers also access the connector state, isn't this slightly
> > more inefficient ?
>
> Inefficient in terms of what?
In terms of the operation having to lookup the connector state, when the
caller has it and can easily pass it. As Daniel commented, this may be
the price to pay for a cleaner API, but I wonder how much overhead all
the state tracking is costing.
> Agree that in isolation this patch might seem unnecessary, but it ties
> in with the encoder and bridge CLs which accept drm_atomic_state in
CLs ?
> their hooks. In general the idea is to convert all atomic functions to
> take overall atomic state instead of just their object state. Reality
> has proven to be more complicated and we need more access than what
> the current implementation provides.
>
> Sean
>
> >> Changes in v3:
> >> - Added to the set
> >>
> >> Cc: Daniel Vetter
> >> Cc: Ville Syrjälä
> >> Cc: Jani Nikula
> >> Cc: Joonas Lahtinen
> >> Cc: Rodrigo Vivi
> >> Cc: Ben Skeggs
> >> Cc: Laurent Pinchart
> >> Cc: Kieran Bingham
> >> Cc: Eric Anholt
> >> Signed-off-by: Sean Paul
> >> ---
> >> drivers/gpu/drm/drm_atomic_helper.c | 4 ++--
> >> drivers/gpu/drm/i915/intel_atomic.c | 8 +---
> >> drivers/gpu/drm/i915/intel_dp_mst.c | 7 ---
> >> drivers/gpu/drm/i915/intel_drv.h | 2 +-
> >> drivers/gpu/drm/i915/intel_sdvo.c| 9 +
> >> drivers/gpu/drm/i915/intel_tv.c | 8 +---
> >> drivers/gpu/drm/nouveau/dispnv50/disp.c | 5 +++--
> >> drivers/gpu/drm/rcar-du/rcar_lvds.c | 12 +++-
> >> drivers/gpu/drm/vc4/vc4_txp.c| 7 ---
> >> include/drm/drm_modeset_helper_vtables.h | 2 +-
> >> 10 files changed, 37 insertions(+), 27 deletions(-)
> >>
> >> diff --git a/drivers/gpu/drm/drm_atomic_helper.c
> >> b/drivers/gpu/drm/drm_atomic_helper.c
> >> index 9d9e47276839..fa5a367507c1 100644
> >> --- a/drivers/gpu/drm/drm_atomic_helper.c
> >> +++ b/drivers/gpu/drm/drm_atomic_helper.c
> >> @@ -683,7 +683,7 @@ drm_atomic_helper_check_modeset(struct drm_device *dev,
> >> }
> >>
> >> if (funcs->atomic_check)
> >> - ret = funcs->atomic_check(connector,
> >> new_connector_state);
> >> + ret = funcs->atomic_check(connector, state);
> >> if (ret)
> >> return ret;
> >>
> >> @@ -725,7 +725,7 @@ drm_atomic_helper_check_modeset(struct drm_device *dev,
> >> continue;
> >>
> >> if (funcs->atomic_check)
> >> - ret = funcs->atomic_check(connector,
> >> new_connector_state);
> >> + ret = funcs->atomic_check(connector, state);
> >> if (ret)
> >> return ret;
> >> }
> >> diff --git a/drivers/gpu/drm/i915/intel_atomic.c
> >> b/drivers/gpu/drm/i915/intel_atomic.c
> >> index b844e8840c6f..e8a5b82e9242 100644
> >> --- a/drivers/gpu/drm/i915/intel_atomic.c
> >> +++ b/drivers/gpu/drm/i915/intel_atomic.c
> >> @@ -103,12 +103,14 @@ int
> >> intel_digital_connector_atomic_set_property(struct drm_connector
> >> *connector,
> >> }
> >>
> >> int intel_digital_connector_atomic_check(struct drm_connector *conn,
> >> - struct drm_connector_state
> >> *new_state)
> >> + struct drm_atomic_state *state)
> >> {
> >> + struct drm_connector_state *new_state =
> >> + drm_atomic_get_new_connector_state(state, conn);
> >> struct intel_digital_connector_state *new_c
Re: [Intel-gfx] [PATCH v3 04/10] drm: Convert connector_helper_funcs->atomic_check to accept drm_atomic_state
Hi Sean,
Thank you for the patch.
On Thu, May 02, 2019 at 03:49:46PM -0400, Sean Paul wrote:
> From: Sean Paul
>
> Everyone who implements connector_helper_funcs->atomic_check reaches
> into the connector state to get the atomic state. Instead of continuing
> this pattern, change the callback signature to just give atomic state
> and let the driver determine what it does and does not need from it.
>
> Eventually all atomic functions should do this, but that's just too much
> busy work for me.
Given that drivers also access the connector state, isn't this slightly
more inefficient ?
> Changes in v3:
> - Added to the set
>
> Cc: Daniel Vetter
> Cc: Ville Syrjälä
> Cc: Jani Nikula
> Cc: Joonas Lahtinen
> Cc: Rodrigo Vivi
> Cc: Ben Skeggs
> Cc: Laurent Pinchart
> Cc: Kieran Bingham
> Cc: Eric Anholt
> Signed-off-by: Sean Paul
> ---
> drivers/gpu/drm/drm_atomic_helper.c | 4 ++--
> drivers/gpu/drm/i915/intel_atomic.c | 8 +---
> drivers/gpu/drm/i915/intel_dp_mst.c | 7 ---
> drivers/gpu/drm/i915/intel_drv.h | 2 +-
> drivers/gpu/drm/i915/intel_sdvo.c| 9 +
> drivers/gpu/drm/i915/intel_tv.c | 8 +---
> drivers/gpu/drm/nouveau/dispnv50/disp.c | 5 +++--
> drivers/gpu/drm/rcar-du/rcar_lvds.c | 12 +++-
> drivers/gpu/drm/vc4/vc4_txp.c| 7 ---
> include/drm/drm_modeset_helper_vtables.h | 2 +-
> 10 files changed, 37 insertions(+), 27 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_atomic_helper.c
> b/drivers/gpu/drm/drm_atomic_helper.c
> index 9d9e47276839..fa5a367507c1 100644
> --- a/drivers/gpu/drm/drm_atomic_helper.c
> +++ b/drivers/gpu/drm/drm_atomic_helper.c
> @@ -683,7 +683,7 @@ drm_atomic_helper_check_modeset(struct drm_device *dev,
> }
>
> if (funcs->atomic_check)
> - ret = funcs->atomic_check(connector,
> new_connector_state);
> + ret = funcs->atomic_check(connector, state);
> if (ret)
> return ret;
>
> @@ -725,7 +725,7 @@ drm_atomic_helper_check_modeset(struct drm_device *dev,
> continue;
>
> if (funcs->atomic_check)
> - ret = funcs->atomic_check(connector,
> new_connector_state);
> + ret = funcs->atomic_check(connector, state);
> if (ret)
> return ret;
> }
> diff --git a/drivers/gpu/drm/i915/intel_atomic.c
> b/drivers/gpu/drm/i915/intel_atomic.c
> index b844e8840c6f..e8a5b82e9242 100644
> --- a/drivers/gpu/drm/i915/intel_atomic.c
> +++ b/drivers/gpu/drm/i915/intel_atomic.c
> @@ -103,12 +103,14 @@ int intel_digital_connector_atomic_set_property(struct
> drm_connector *connector,
> }
>
> int intel_digital_connector_atomic_check(struct drm_connector *conn,
> - struct drm_connector_state *new_state)
> + struct drm_atomic_state *state)
> {
> + struct drm_connector_state *new_state =
> + drm_atomic_get_new_connector_state(state, conn);
> struct intel_digital_connector_state *new_conn_state =
> to_intel_digital_connector_state(new_state);
> struct drm_connector_state *old_state =
> - drm_atomic_get_old_connector_state(new_state->state, conn);
> + drm_atomic_get_old_connector_state(state, conn);
> struct intel_digital_connector_state *old_conn_state =
> to_intel_digital_connector_state(old_state);
> struct drm_crtc_state *crtc_state;
> @@ -118,7 +120,7 @@ int intel_digital_connector_atomic_check(struct
> drm_connector *conn,
> if (!new_state->crtc)
> return 0;
>
> - crtc_state = drm_atomic_get_new_crtc_state(new_state->state,
> new_state->crtc);
> + crtc_state = drm_atomic_get_new_crtc_state(state, new_state->crtc);
>
> /*
>* These properties are handled by fastset, and might not end
> diff --git a/drivers/gpu/drm/i915/intel_dp_mst.c
> b/drivers/gpu/drm/i915/intel_dp_mst.c
> index 19d81cef2ab6..89cfec128ba0 100644
> --- a/drivers/gpu/drm/i915/intel_dp_mst.c
> +++ b/drivers/gpu/drm/i915/intel_dp_mst.c
> @@ -143,9 +143,10 @@ static int intel_dp_mst_compute_config(struct
> intel_encoder *encoder,
>
> static int
> intel_dp_mst_atomic_check(struct drm_connector *connector,
> - struct drm_connector_state *new_conn_state)
> + struct drm_atomic_state *state)
> {
> - struct drm_atomic_state *state = new_conn_state->state;
> + s
Re: [Intel-gfx] [PATCH] gpu:drm: Remove duplicate headers
Hi Jagadeesh,
Thank you for the patch.
On Thu, Mar 28, 2019 at 02:41:56AM +0530, jagdsh.li...@gmail.com wrote:
> From: Jagadeesh Pagadala
>
> Remove duplicate headers which are included twice.
Could you, while at it, also sort the existing #include statements
alphabetically ? This should help avoiding similar issues in the future.
> Signed-off-by: Jagadeesh Pagadala
> ---
> drivers/gpu/drm/bridge/panel.c | 1 -
> drivers/gpu/drm/i915/intel_display.c | 7 ---
> 2 files changed, 8 deletions(-)
>
> diff --git a/drivers/gpu/drm/bridge/panel.c b/drivers/gpu/drm/bridge/panel.c
> index 38eeaf8..eb9567d 100644
> --- a/drivers/gpu/drm/bridge/panel.c
> +++ b/drivers/gpu/drm/bridge/panel.c
> @@ -15,7 +15,6 @@
> #include
> #include
> #include
> -#include
>
> struct panel_bridge {
> struct drm_bridge bridge;
> diff --git a/drivers/gpu/drm/i915/intel_display.c
> b/drivers/gpu/drm/i915/intel_display.c
> index ccb6163..1166342 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -51,14 +51,7 @@
> #include "intel_dsi.h"
> #include "intel_frontbuffer.h"
>
> -#include "intel_drv.h"
> -#include "intel_dsi.h"
> -#include "intel_frontbuffer.h"
> -
> -#include "i915_drv.h"
> -#include "i915_gem_clflush.h"
> #include "i915_reset.h"
> -#include "i915_trace.h"
>
> /* Primary plane formats for gen <= 3 */
> static const u32 i8xx_primary_formats[] = {
--
Regards,
Laurent Pinchart
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 12/17] drm/rcar-du: Convert to using __drm_atomic_helper_crtc_reset() for reset.
Hi Marteen,
On Fri, Mar 01, 2019 at 03:47:02PM +0100, Maarten Lankhorst wrote:
> Op 01-03-2019 om 15:36 schreef Laurent Pinchart:
> > On Fri, Mar 01, 2019 at 03:08:20PM +0100, Maarten Lankhorst wrote:
> >> Op 01-03-2019 om 14:13 schreef Laurent Pinchart:
> >>> On Fri, Mar 01, 2019 at 01:56:22PM +0100, Maarten Lankhorst wrote:
> >>>> Convert rcar-du to using __drm_atomic_helper_crtc_reset(), instead of
> >>>> writing its own version. Instead of open coding destroy_state(), call
> >>>> it directly for freeing the old state.
> >>> I don't think the second sentence applies to this patch.
> >>>
> >>>> Signed-off-by: Maarten Lankhorst
> >>>> Cc: Laurent Pinchart
> >>>> Cc: Kieran Bingham
> >>>> Cc: linux-renesas-...@vger.kernel.org
> >>>> ---
> >>>> drivers/gpu/drm/rcar-du/rcar_du_crtc.c | 11 +++
> >>>> 1 file changed, 3 insertions(+), 8 deletions(-)
> >>>>
> >>>> diff --git a/drivers/gpu/drm/rcar-du/rcar_du_crtc.c
> >>>> b/drivers/gpu/drm/rcar-du/rcar_du_crtc.c
> >>>> index 4cdea14d552f..7766551e67fc 100644
> >>>> --- a/drivers/gpu/drm/rcar-du/rcar_du_crtc.c
> >>>> +++ b/drivers/gpu/drm/rcar-du/rcar_du_crtc.c
> >>>> @@ -891,22 +891,17 @@ static void rcar_du_crtc_cleanup(struct drm_crtc
> >>>> *crtc)
> >>>>
> >>>> static void rcar_du_crtc_reset(struct drm_crtc *crtc)
> >>>> {
> >>>> -struct rcar_du_crtc_state *state;
> >>>> +struct rcar_du_crtc_state *state = kzalloc(sizeof(*state),
> >>>> GFP_KERNEL);
> >>>>
> >>>> -if (crtc->state) {
> >>>> +if (crtc->state)
> >>>> rcar_du_crtc_atomic_destroy_state(crtc, crtc->state);
> >>>> -crtc->state = NULL;
> >>>> -}
> >>>>
> >>>> -state = kzalloc(sizeof(*state), GFP_KERNEL);
> >>>> +__drm_atomic_helper_crtc_reset(crtc, >state);
> >>> state may be NULL here if the above kzalloc() failed. Let's keep the
> >>> original order of the function, and simply call
> >>> __drm_atomic_helper_crtc_reset() after the NULL check below.
> >> There were 10 different ways crtc was implemented, I felt it was good to
> >> settle on one.
> >>
> >> We don't handle during reset at all, would need to start propagating this
> >> first before we should handle errors, imho.
> > That's not the point. As state can be NULL, you could end up
> > dereferencing a NULL pointer. The fact that the base state is the first
> > field in the rcar_du_crtc_state structure is just luck, and shouldn't be
> > relied on.
>
> Would it be ok if I changed it to state ? >state : NULL and let
> the compiler deal with it?
What's wrong with a proper implementation ?
static void rcar_du_crtc_reset(struct drm_crtc *crtc)
{
struct rcar_du_crtc_state *state;
if (crtc->state) {
rcar_du_crtc_atomic_destroy_state(crtc, crtc->state);
crtc->state = NULL;
}
state = kzalloc(sizeof(*state), GFP_KERNEL);
if (state == NULL)
return;
__drm_atomic_helper_crtc_reset(crtc, >state);
state->crc.source = VSP1_DU_CRC_NONE;
state->crc.index = 0;
}
> Will probably fix up all other patches as well before committing.
You won't commit this one before I ack it, right ? :-)
> >> Looking more closely, it's the same way that errors in
> >> rcar_du_plane_reset() are handled. :)
> > It's not, the return value of kzalloc() is checked explicitly in
> > rcar_du_plane_reset() before calling __drm_atomic_helper_plane_reset().
> > Please copy the code flow of rcar_du_plane_reset() to implement
> > rcar_du_crtc_reset().
--
Regards,
Laurent Pinchart
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 12/17] drm/rcar-du: Convert to using __drm_atomic_helper_crtc_reset() for reset.
Hi Marteen,
On Fri, Mar 01, 2019 at 03:08:20PM +0100, Maarten Lankhorst wrote:
> Op 01-03-2019 om 14:13 schreef Laurent Pinchart:
> > On Fri, Mar 01, 2019 at 01:56:22PM +0100, Maarten Lankhorst wrote:
> >> Convert rcar-du to using __drm_atomic_helper_crtc_reset(), instead of
> >> writing its own version. Instead of open coding destroy_state(), call
> >> it directly for freeing the old state.
> > I don't think the second sentence applies to this patch.
> >
> >> Signed-off-by: Maarten Lankhorst
> >> Cc: Laurent Pinchart
> >> Cc: Kieran Bingham
> >> Cc: linux-renesas-...@vger.kernel.org
> >> ---
> >> drivers/gpu/drm/rcar-du/rcar_du_crtc.c | 11 +++
> >> 1 file changed, 3 insertions(+), 8 deletions(-)
> >>
> >> diff --git a/drivers/gpu/drm/rcar-du/rcar_du_crtc.c
> >> b/drivers/gpu/drm/rcar-du/rcar_du_crtc.c
> >> index 4cdea14d552f..7766551e67fc 100644
> >> --- a/drivers/gpu/drm/rcar-du/rcar_du_crtc.c
> >> +++ b/drivers/gpu/drm/rcar-du/rcar_du_crtc.c
> >> @@ -891,22 +891,17 @@ static void rcar_du_crtc_cleanup(struct drm_crtc
> >> *crtc)
> >>
> >> static void rcar_du_crtc_reset(struct drm_crtc *crtc)
> >> {
> >> - struct rcar_du_crtc_state *state;
> >> + struct rcar_du_crtc_state *state = kzalloc(sizeof(*state), GFP_KERNEL);
> >>
> >> - if (crtc->state) {
> >> + if (crtc->state)
> >>rcar_du_crtc_atomic_destroy_state(crtc, crtc->state);
> >> - crtc->state = NULL;
> >> - }
> >>
> >> - state = kzalloc(sizeof(*state), GFP_KERNEL);
> >> + __drm_atomic_helper_crtc_reset(crtc, >state);
> >
> > state may be NULL here if the above kzalloc() failed. Let's keep the
> > original order of the function, and simply call
> > __drm_atomic_helper_crtc_reset() after the NULL check below.
>
> There were 10 different ways crtc was implemented, I felt it was good to
> settle on one.
>
> We don't handle during reset at all, would need to start propagating this
> first before we should handle errors, imho.
That's not the point. As state can be NULL, you could end up
dereferencing a NULL pointer. The fact that the base state is the first
field in the rcar_du_crtc_state structure is just luck, and shouldn't be
relied on.
> Looking more closely, it's the same way that errors in
> rcar_du_plane_reset() are handled. :)
It's not, the return value of kzalloc() is checked explicitly in
rcar_du_plane_reset() before calling __drm_atomic_helper_plane_reset().
Please copy the code flow of rcar_du_plane_reset() to implement
rcar_du_crtc_reset().
--
Regards,
Laurent Pinchart
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 12/17] drm/rcar-du: Convert to using __drm_atomic_helper_crtc_reset() for reset.
Hi Maarten,
Thank you for the patch.
On Fri, Mar 01, 2019 at 01:56:22PM +0100, Maarten Lankhorst wrote:
> Convert rcar-du to using __drm_atomic_helper_crtc_reset(), instead of
> writing its own version. Instead of open coding destroy_state(), call
> it directly for freeing the old state.
I don't think the second sentence applies to this patch.
> Signed-off-by: Maarten Lankhorst
> Cc: Laurent Pinchart
> Cc: Kieran Bingham
> Cc: linux-renesas-...@vger.kernel.org
> ---
> drivers/gpu/drm/rcar-du/rcar_du_crtc.c | 11 +++
> 1 file changed, 3 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/gpu/drm/rcar-du/rcar_du_crtc.c
> b/drivers/gpu/drm/rcar-du/rcar_du_crtc.c
> index 4cdea14d552f..7766551e67fc 100644
> --- a/drivers/gpu/drm/rcar-du/rcar_du_crtc.c
> +++ b/drivers/gpu/drm/rcar-du/rcar_du_crtc.c
> @@ -891,22 +891,17 @@ static void rcar_du_crtc_cleanup(struct drm_crtc *crtc)
>
> static void rcar_du_crtc_reset(struct drm_crtc *crtc)
> {
> - struct rcar_du_crtc_state *state;
> + struct rcar_du_crtc_state *state = kzalloc(sizeof(*state), GFP_KERNEL);
>
> - if (crtc->state) {
> + if (crtc->state)
> rcar_du_crtc_atomic_destroy_state(crtc, crtc->state);
> - crtc->state = NULL;
> - }
>
> - state = kzalloc(sizeof(*state), GFP_KERNEL);
> + __drm_atomic_helper_crtc_reset(crtc, >state);
state may be NULL here if the above kzalloc() failed. Let's keep the
original order of the function, and simply call
__drm_atomic_helper_crtc_reset() after the NULL check below.
> if (state == NULL)
> return;
>
> state->crc.source = VSP1_DU_CRC_NONE;
> state->crc.index = 0;
> -
> - crtc->state = >state;
> - crtc->state->crtc = crtc;
> }
>
> static int rcar_du_crtc_enable_vblank(struct drm_crtc *crtc)
--
Regards,
Laurent Pinchart
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v12 01/38] drm/doc: document recommended component helper usage
Hi Daniel, Thank you for the patch. On Sat, Feb 09, 2019 at 12:42:30PM +0530, Ramalingam C wrote: > From: Daniel Vetter > > Now that component has docs it's worth spending a few words and > hyperlinks on recommended best practices in drm. > > Cc: Russell King - ARM Linux admin > Signed-off-by: Daniel Vetter > --- > Documentation/driver-api/component.rst | 2 ++ > Documentation/gpu/drm-internals.rst| 5 + > drivers/gpu/drm/drm_drv.c | 14 ++ > 3 files changed, 21 insertions(+) > > diff --git a/Documentation/driver-api/component.rst > b/Documentation/driver-api/component.rst > index 2da4a8f20607..57e37590733f 100644 > --- a/Documentation/driver-api/component.rst > +++ b/Documentation/driver-api/component.rst > @@ -1,3 +1,5 @@ > +.. _component: > + > == > Component Helper for Aggregate Drivers > == > diff --git a/Documentation/gpu/drm-internals.rst > b/Documentation/gpu/drm-internals.rst > index 3ae23a5454ac..966bd2d9f0cc 100644 > --- a/Documentation/gpu/drm-internals.rst > +++ b/Documentation/gpu/drm-internals.rst > @@ -93,6 +93,11 @@ Device Instance and Driver Handling > Driver Load > --- > > +Component Helper Usage > +~~ > + > +.. kernel-doc:: drivers/gpu/drm/drm_drv.c > + :doc: component helper usage recommendations > > IRQ Helper Library > ~~ > diff --git a/drivers/gpu/drm/drm_drv.c b/drivers/gpu/drm/drm_drv.c > index 381581b01d48..aae413003705 100644 > --- a/drivers/gpu/drm/drm_drv.c > +++ b/drivers/gpu/drm/drm_drv.c > @@ -457,6 +457,20 @@ static void drm_fs_inode_free(struct inode *inode) > } > > /** > + * DOC: component helper usage recommendations > + * > + * DRM drivers that drive hardware where a logical device consists of a pile > of > + * independent hardware blocks are recommended to use the :ref:`component > helper > + * library`. That's the first recommendation I would challenge :-) When using drm_bridge and drm_panel, the component framework is not strictly needed. The DRM/KMS probe function can defer probe when a bridge or panel is missing. Only when two-way dependencies exist between the display controller and the external components is the component framework required. > The entire device initialization procedure should be run > + * from the _master_ops.master_bind callback, starting with > + * drm_dev_init(), then binding all components with component_bind_all() and > + * finishing with drm_dev_register(). The omapdss driver, for instance, performs hardware-specific initialization of the DSS in the probe() handler itself (DT-related parsing, memory mapping, IRQ registration, ...). I don't see why this would need to move to the .master_bind() callback. > For consistency and easier sharing of > + * components across drivers the opaque pointer passed to all components > through > + * component_bind_all() should point at drm_device of the device > + * instance, not some driver specific private structure. I'd say "shall" instead of "should" to make this a hard requirement. The opaque pointer is something that I have never really liked in the component framework as it hinders reusability. I have a few ideas on how to fix that but haven't had time to try them out yet as the changes would be quite intrusive. Long term major changes will be needed there anyway as it makes no sense to have to frameworks with similar purposes in DRM/KMS and V4L2. > + */ > + > +/** > * drm_dev_init - Initialise new DRM device > * @dev: DRM device > * @driver: DRM driver -- Regards, Laurent Pinchart ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm: Split out drm_probe_helper.h
Hi Daniel, Thank you for the patch. On Tuesday, 15 January 2019 12:41:37 EET Daniel Vetter wrote: > Having the probe helper stuff (which pretty much everyone needs) in > the drm_crtc_helper.h file (which atomic drivers should never need) is > confusing. Split them out. > > To make sure I actually achieved the goal here I went through all > drivers. And indeed, all atomic drivers are now free of > drm_crtc_helper.h includes. > > v2: Make it compile. There was so much compile fail on arm drivers > that I figured I'll better not include any of the acks on v1. > > v3: Massive rebase because i915 has lost a lot of drmP.h includes, but > not all: Through drm_crtc_helper.h > drm_modeset_helper.h -> drmP.h > there was still one, which this patch largely removes. Which means > rolling out lots more includes all over. > > This will also conflict with ongoing drmP.h cleanup by others I > expect. > > v3: Rebase on top of atomic bochs. > > Cc: Sam Ravnborg > Cc: Jani Nikula > Cc: Laurent Pinchart > Acked-by: Rodrigo Vivi (v2) > Acked-by: Benjamin Gaignard (v2) > Signed-off-by: Daniel Vetter > Cc: linux-arm-ker...@lists.infradead.org > Cc: virtualizat...@lists.linux-foundation.org > Cc: etna...@lists.freedesktop.org > Cc: linux-samsung-...@vger.kernel.org > Cc: intel-gfx@lists.freedesktop.org > Cc: linux-media...@lists.infradead.org > Cc: linux-amlo...@lists.infradead.org > Cc: linux-arm-...@vger.kernel.org > Cc: freedr...@lists.freedesktop.org > Cc: nouv...@lists.freedesktop.org > Cc: spice-de...@lists.freedesktop.org > Cc: amd-...@lists.freedesktop.org > Cc: linux-renesas-...@vger.kernel.org > Cc: linux-rockc...@lists.infradead.org > Cc: linux-st...@st-md-mailman.stormreply.com > Cc: linux-te...@vger.kernel.org > Cc: xen-de...@lists.xen.org > --- > Merging this is going to be a bit a mess due to all the ongoing drmP.h > cleanups. I think the following should work: > - Apply Sam's prep patches for removing drmP.h from > drm_modeset_helper.h > - Get the i915 drmP.h cleanup backmerged into drm-misc-next > - Apply this patch. > - Apply Sam's patch to remove drmP.h from drm_modeset_helper.h > - All through drm-misc-next, which has some potential for trivial > conflicts around #includes with other drivers unfortunately. > > I hope there's no other driver who'll blow up accidentally because > someone else is doing a drmP.h cleanup. Laurent maybe? There's a drmP.h cleanup in the R-Car DU driver, but it doesn't conflict with this patch, the combination of both compiles fine. > Jani, ack on this? > -Daniel > --- [snip] > drivers/gpu/drm/bridge/adv7511/adv7511.h | 5 +- > drivers/gpu/drm/bridge/analogix-anx78xx.c | 2 +- > drivers/gpu/drm/bridge/dumb-vga-dac.c | 2 +- > drivers/gpu/drm/bridge/synopsys/dw-hdmi.c | 2 +- > drivers/gpu/drm/bridge/ti-tfp410.c| 2 +- > drivers/gpu/drm/drm_atomic_helper.c | 1 - > drivers/gpu/drm/drm_dp_mst_topology.c | 2 +- > drivers/gpu/drm/drm_modeset_helper.c | 2 +- > drivers/gpu/drm/drm_probe_helper.c| 2 +- > drivers/gpu/drm/drm_simple_kms_helper.c | 2 +- > drivers/gpu/drm/omapdrm/omap_connector.c | 2 +- > drivers/gpu/drm/omapdrm/omap_crtc.c | 2 +- > drivers/gpu/drm/omapdrm/omap_drv.c| 2 +- > drivers/gpu/drm/omapdrm/omap_drv.h| 2 +- > drivers/gpu/drm/omapdrm/omap_encoder.c| 2 +- > drivers/gpu/drm/omapdrm/omap_fb.c | 2 +- > drivers/gpu/drm/rcar-du/rcar_du_crtc.c| 2 +- > drivers/gpu/drm/rcar-du/rcar_du_drv.c | 2 +- > drivers/gpu/drm/rcar-du/rcar_du_encoder.c | 2 +- > drivers/gpu/drm/rcar-du/rcar_du_kms.c | 2 +- > drivers/gpu/drm/rcar-du/rcar_du_plane.c | 2 +- > drivers/gpu/drm/rcar-du/rcar_du_vsp.c | 2 +- > drivers/gpu/drm/rcar-du/rcar_lvds.c | 2 +- > drivers/gpu/drm/shmobile/shmob_drm_crtc.c | 1 + > drivers/gpu/drm/shmobile/shmob_drm_drv.c | 1 + > drivers/gpu/drm/shmobile/shmob_drm_kms.c | 1 + > include/drm/drm_crtc_helper.h | 16 -- > include/drm/drm_probe_helper.h| 50 +++ For the above files, with the comments below addressed, Reviewed-by: Laurent Pinchart > 227 files changed, 289 insertions(+), 200 deletions(-) > create mode 100644 include/drm/drm_probe_helper.h [snip] > diff --git a/drivers/gpu/drm/bridge/adv7511/adv7511.h > b/drivers/gpu/drm/bridge/adv7511/adv7511.h index 73d8ccb97742..d52ffab41eb4 > 100644 > --- a/drivers/gpu/drm/bridge/adv7511/adv7511.h > +++ b/drivers/gpu/drm/bridge/adv7511/adv7511.h > @@ -14,8 +14,11 @@ > #include > #include > >
Re: [Intel-gfx] [PATCH 0/6] drm/i915: drmP.h include removal w/ drm prep work
Hi Jani, On Wednesday, 2 January 2019 09:47:58 EET Jani Nikula wrote: > On Fri, 28 Dec 2018, Jani Nikula wrote: > > Thanks for all the reviews, pushed patches 1-5 to topic/drmp-cleanup > > with $(git merge-base drm-misc-next drm-intel-next-queued) as the > > starting point. It's also included in drm-tip now. > > So I did this *before* I got the review feedback from Laurent, based on > Daniel's review only. Would you all like me to redo the branch with > Laurent's comments addressed and r-b added? If you think my comments are valuable, that may be a good idea :-) -- Regards, Laurent Pinchart ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2] drm: forward declare struct drm_file in drm_syncobj.h
Hi Jani, Thank you for the patch. On Friday, 28 December 2018 10:28:15 EET Jani Nikula wrote: > Make it easier to drop drmP.h includes. Switch from "" to <> includes > while at it. > > v2: forward declare instead of including drm_file.h (Daniel) Reviewed-by: Laurent Pinchart but with the same comments as for the previous patches. > Cc: Sam Ravnborg > Cc: Daniel Vetter > Cc: Laurent Pinchart > Reviewed-by: Daniel Vetter > Signed-off-by: Jani Nikula > --- > include/drm/drm_syncobj.h | 4 +++- > 1 file changed, 3 insertions(+), 1 deletion(-) > > diff --git a/include/drm/drm_syncobj.h b/include/drm/drm_syncobj.h > index 7c6ed845c70d..0311c9fdbd2f 100644 > --- a/include/drm/drm_syncobj.h > +++ b/include/drm/drm_syncobj.h > @@ -26,7 +26,9 @@ > #ifndef __DRM_SYNCOBJ_H__ > #define __DRM_SYNCOBJ_H__ > > -#include "linux/dma-fence.h" > +#include > + > +struct drm_file; > > /** > * struct drm_syncobj - sync object. -- Regards, Laurent Pinchart ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 4/6] drm: include types.h from drm_hdcp.h
Hi Jani, Thank you for the patch. On Thursday, 27 December 2018 14:56:39 EET Jani Nikula wrote: > Make it easier to drop drmP.h includes. Same comment as for the previous patches, let's explain the reason. "drm_hdcp.h uses kernel integer types, make it self-contained by including linux/kernel.h. This prepares for dropping drmP.h from files including drm_hdcp.h." Reviewed-by: Laurent Pinchart > Cc: Sam Ravnborg > Cc: Daniel Vetter > Cc: Laurent Pinchart > Signed-off-by: Jani Nikula > --- > include/drm/drm_hdcp.h | 2 ++ > 1 file changed, 2 insertions(+) > > diff --git a/include/drm/drm_hdcp.h b/include/drm/drm_hdcp.h > index a6de09c5e47f..d6dfef8cff6a 100644 > --- a/include/drm/drm_hdcp.h > +++ b/include/drm/drm_hdcp.h > @@ -9,6 +9,8 @@ > #ifndef _DRM_HDCP_H_INCLUDED_ > #define _DRM_HDCP_H_INCLUDED_ > > +#include > + > /* Period of hdcp checks (to ensure we're still authenticated) */ > #define DRM_HDCP_CHECK_PERIOD_MS (128 * 16) -- Regards, Laurent Pinchart ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 3/6] drm: include idr.h from drm_file.h
Hi Jani, Thank you for the patch. On Thursday, 27 December 2018 14:56:38 EET Jani Nikula wrote: > Make it easier to drop drmP.h includes. How about explaining why idr.h is needed ? "drm_file.h embeds idr structures in DRM-specific structures. Include the corresponding header to make drm_file.h self-contained." Reviewed-by: Laurent Pinchart > Cc: Sam Ravnborg > Cc: Daniel Vetter > Cc: Laurent Pinchart > Signed-off-by: Jani Nikula > --- > include/drm/drm_file.h | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/include/drm/drm_file.h b/include/drm/drm_file.h > index 84ac79219e4c..6710b612e2f6 100644 > --- a/include/drm/drm_file.h > +++ b/include/drm/drm_file.h > @@ -32,6 +32,7 @@ > > #include > #include > +#include > > #include -- Regards, Laurent Pinchart ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2] drm: un-inline drm_legacy_findmap()
Hi Jani,
Thank you for the patch.
On Friday, 28 December 2018 15:04:46 EET Jani Nikula wrote:
> Also include drm_hashtab.h and add struct drm_device forward declaration
> in drm_legacy.h to make it more self-contained. Make it easier to drop
> drmP.h includes.
>
> v2: avoid including drm_device.h by un-inlining (Daniel)
It would be nice to explain why you de-inline the function (I assume because
it's a bit too large).
Reviewed-by: Laurent Pinchart
> Cc: Sam Ravnborg
> Cc: Daniel Vetter
> Cc: Laurent Pinchart
> Signed-off-by: Jani Nikula
> ---
> drivers/gpu/drm/drm_bufs.c | 11 +++
> include/drm/drm_legacy.h | 14 --
> 2 files changed, 15 insertions(+), 10 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_bufs.c b/drivers/gpu/drm/drm_bufs.c
> index d7d10cabb9bb..a39ab2193bfe 100644
> --- a/drivers/gpu/drm/drm_bufs.c
> +++ b/drivers/gpu/drm/drm_bufs.c
> @@ -377,6 +377,17 @@ int drm_legacy_addmap(struct drm_device *dev,
> resource_size_t offset, }
> EXPORT_SYMBOL(drm_legacy_addmap);
>
> +struct drm_local_map *drm_legacy_findmap(struct drm_device *dev,
> + unsigned int token)
> +{
> + struct drm_map_list *_entry;
> + list_for_each_entry(_entry, >maplist, head)
> + if (_entry->user_token == token)
> + return _entry->map;
> + return NULL;
> +}
> +EXPORT_SYMBOL(drm_legacy_findmap);
> +
> /**
> * Ioctl to specify a range of memory that is available for mapping by a
> * non-root process.
> diff --git a/include/drm/drm_legacy.h b/include/drm/drm_legacy.h
> index 8fad66f88e4f..3e99ab69c122 100644
> --- a/include/drm/drm_legacy.h
> +++ b/include/drm/drm_legacy.h
> @@ -2,6 +2,9 @@
> #define __DRM_DRM_LEGACY_H__
>
> #include
> +#include
> +
> +struct drm_device;
>
> /*
> * Legacy driver interfaces for the Direct Rendering Manager
> @@ -156,6 +159,7 @@ struct drm_map_list {
> int drm_legacy_addmap(struct drm_device *d, resource_size_t offset,
> unsigned int size, enum drm_map_type type,
> enum drm_map_flags flags, struct drm_local_map **map_p);
> +struct drm_local_map *drm_legacy_findmap(struct drm_device *dev, unsigned
> int token); void drm_legacy_rmmap(struct drm_device *d, struct
> drm_local_map *map); int drm_legacy_rmmap_locked(struct drm_device *d,
> struct drm_local_map *map); void drm_legacy_master_rmmaps(struct drm_device
> *dev,
> @@ -194,14 +198,4 @@ void drm_legacy_ioremap(struct drm_local_map *map,
> struct drm_device *dev); void drm_legacy_ioremap_wc(struct drm_local_map
> *map, struct drm_device *dev); void drm_legacy_ioremapfree(struct
> drm_local_map *map, struct drm_device *dev);
>
> -static inline struct drm_local_map *drm_legacy_findmap(struct drm_device
> *dev, - unsigned int
> token)
> -{
> - struct drm_map_list *_entry;
> - list_for_each_entry(_entry, >maplist, head)
> - if (_entry->user_token == token)
> - return _entry->map;
> - return NULL;
> -}
> -
> #endif /* __DRM_DRM_LEGACY_H__ */
--
Regards,
Laurent Pinchart
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/4] drm/edid: Pass connector to AVI inforframe functions
Hi Andrzej, On Wednesday, 5 December 2018 10:46:40 EET Andrzej Hajda wrote: > On 05.12.2018 07:32, Laurent Pinchart wrote: > > On Tuesday, 4 December 2018 21:13:20 EET Ville Syrjälä wrote: > >> On Tue, Dec 04, 2018 at 08:46:53AM +0100, Andrzej Hajda wrote: > >>> On 03.12.2018 22:38, Ville Syrjälä wrote: > >>>> On Thu, Nov 29, 2018 at 10:08:07AM +0100, Andrzej Hajda wrote: > >>>>> On 21.11.2018 19:19, Laurent Pinchart wrote: > >>>>>> On Tuesday, 20 November 2018 18:13:42 EET Ville Syrjala wrote: > >>>>>>> From: Ville Syrjälä > >>>>>>> > >>>>>>> Make life easier for drivers by simply passing the connector > >>>>>>> to drm_hdmi_avi_infoframe_from_display_mode() and > >>>>>>> drm_hdmi_avi_infoframe_quant_range(). That way drivers don't > >>>>>>> need to worry about is_hdmi2_sink mess. > >>>>>> > >>>>>> While this is good for display controller drivers, the change isn't > >>>>>> great for bridge drivers. Down the road we're looking at moving > >>>>>> connector support out of the bridge drivers. Adding an additional > >>>>>> dependency to connectors in the bridges will make that more > >>>>>> difficult. Ideally bridges should retrieve the information from their > >>>>>> sink, regardless of whether it is a connector or another bridge. > >>>>> > >>>>> I agree with it, and case of sii8620 shows that there are cases where > >>>>> bridge has no direct access to the connector. > >>>> > >>>> It's just a matter of plumbing it through. > >>> > >>> What do you mean exactly? > >> > >> void bridge_foo(... > >> + ,struct drm_connector *connector); > >> > >>>>> On the other side, since you are passing connector to > >>>>> drm_hdmi_avi_infoframe_from_display_mode(), you could drop mode > >>>>> parameter and rename the function to > >>>>> drm_hdmi_avi_infoframe_from_connector() then, unless mode passed and > >>>>> mode set on the connector differs? > >>>> > >>>> Connectors don't have a mode. > >>> > >>> As they are passing video stream they should have it, even if not > >>> directly, for example: > >>> > >>> connector->state->crtc->mode > >> > >> That's not really how atomic works. One shouldn't go digging > >> through the obj->state pointers when we're not holding the > >> relevant locks anymore. The atomic way would be to pass either > >> both crtc state and connector state, or drm_atomic_state + > >> crtc/connector. > > Usually infoframe contents is generated in modesetting/enable callbacks > so the locks should be in place. > > And the locks should be hold for > drm_hdmi_avi_infoframe_from_display_mode as well - it wouldn't be correct if > > generated infoframe is not relevant to actual video mode. I guess that > if connector->state->crtc->mode > > differs from mode passed to drm_hdmi_avi_infoframe_from_display_mode it > is a sign of possible problem. > > And if they do not differ passing mode as an extra argument is redundant. > > > Or a bridge state ? With chained bridges the mode can vary along the > > pipeline, the CRTC adjusted mode will only cover the link between the > > CRTC and the first bridge. It's only a matter of time until we need to > > store other intermediate modes in states. I'd rather prepare for that > > instead of passing the CRTC state to bridges. > > Yes, optional bridge states seems reasonable, volunteers needed :) I'll give it a go eventually, if nobody beats me to it. The exact timing will depend on many variables so I can't estimate it I'm afraid. All I'm asking is to avoid extending the drm_bridge API in a way that would make introduction of bridge states more complex. If someone needs bridge states, for instance to solve the above issue, then they should be added. [snip] -- Regards, Laurent Pinchart ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/4] drm/edid: Pass connector to AVI inforframe functions
Hi Ville, On Tuesday, 4 December 2018 21:13:20 EET Ville Syrjälä wrote: > On Tue, Dec 04, 2018 at 08:46:53AM +0100, Andrzej Hajda wrote: > > On 03.12.2018 22:38, Ville Syrjälä wrote: > >> On Thu, Nov 29, 2018 at 10:08:07AM +0100, Andrzej Hajda wrote: > >>> On 21.11.2018 19:19, Laurent Pinchart wrote: > >>>> On Tuesday, 20 November 2018 18:13:42 EET Ville Syrjala wrote: > >>>>> From: Ville Syrjälä > >>>>> > >>>>> Make life easier for drivers by simply passing the connector > >>>>> to drm_hdmi_avi_infoframe_from_display_mode() and > >>>>> drm_hdmi_avi_infoframe_quant_range(). That way drivers don't > >>>>> need to worry about is_hdmi2_sink mess. > >>>> > >>>> While this is good for display controller drivers, the change isn't > >>>> great for bridge drivers. Down the road we're looking at moving > >>>> connector support out of the bridge drivers. Adding an additional > >>>> dependency to connectors in the bridges will make that more > >>>> difficult. Ideally bridges should retrieve the information from their > >>>> sink, regardless of whether it is a connector or another bridge. > >>> > >>> I agree with it, and case of sii8620 shows that there are cases where > >>> bridge has no direct access to the connector. > >> > >> It's just a matter of plumbing it through. > > > > What do you mean exactly? > > void bridge_foo(... > + ,struct drm_connector *connector); > > >>> On the other side, since you are passing connector to > >>> drm_hdmi_avi_infoframe_from_display_mode(), you could drop mode > >>> parameter and rename the function to > >>> drm_hdmi_avi_infoframe_from_connector() then, unless mode passed and > >>> mode set on the connector differs? > >> > >> Connectors don't have a mode. > > > > As they are passing video stream they should have it, even if not > > directly, for example: > > > > connector->state->crtc->mode > > That's not really how atomic works. One shouldn't go digging > through the obj->state pointers when we're not holding the > relevant locks anymore. The atomic way would be to pass either > both crtc state and connector state, or drm_atomic_state + > crtc/connector. Or a bridge state ? With chained bridges the mode can vary along the pipeline, the CRTC adjusted mode will only cover the link between the CRTC and the first bridge. It's only a matter of time until we need to store other intermediate modes in states. I'd rather prepare for that instead of passing the CRTC state to bridges. > > In moment of creating infoframe it should be set properly. > > > >>>> Please see below for an additional comment. > >>>> > >>>>> Cc: Alex Deucher > >>>>> Cc: "Christian König" > >>>>> Cc: "David (ChunMing) Zhou" > >>>>> Cc: Archit Taneja > >>>>> Cc: Andrzej Hajda > >>>>> Cc: Laurent Pinchart > >>>>> Cc: Inki Dae > >>>>> Cc: Joonyoung Shim > >>>> Cc: Seung-Woo Kim > >>>>> Cc: Kyungmin Park > >>>>> Cc: Russell King > >>>>> Cc: CK Hu > >>>>> Cc: Philipp Zabel > >>>>> Cc: Rob Clark > >>>>> Cc: Ben Skeggs > >>>>> Cc: Tomi Valkeinen > >>>>> Cc: Sandy Huang > >>>>> Cc: "Heiko Stübner" > >>>>> Cc: Benjamin Gaignard > >>>>> Cc: Vincent Abriou > >>>>> Cc: Thierry Reding > >>>>> Cc: Eric Anholt > >>>>> Cc: Shawn Guo > >>>>> Cc: Ilia Mirkin > >>>>> Cc: amd-...@lists.freedesktop.org > >>>>> Cc: linux-arm-...@vger.kernel.org > >>>>> Cc: freedr...@lists.freedesktop.org > >>>>> Cc: nouv...@lists.freedesktop.org > >>>>> Cc: linux-te...@vger.kernel.org > >>>>> Signed-off-by: Ville Syrjälä > >>>>> --- > >>>>> > >>>>> drivers/gpu/drm/amd/amdgpu/dce_v10_0.c| 2 +- > >>>>> drivers/gpu/drm/amd/amdgpu/dce_v11_0.c| 2 +- > >>>>> drivers/gpu/drm/amd/amdgpu/dce_v6_0.c | 3 ++- > >>>>> drivers/gpu/drm/amd/amdgpu/dce_v8_0.c | 2 +- > >>>>> drivers/gpu/drm/
Re: [Intel-gfx] [PATCH 1/4] drm/edid: Pass connector to AVI inforframe functions
Hi Ville, Thank you for the patch. On Tuesday, 20 November 2018 18:13:42 EET Ville Syrjala wrote: > From: Ville Syrjälä > > Make life easier for drivers by simply passing the connector > to drm_hdmi_avi_infoframe_from_display_mode() and > drm_hdmi_avi_infoframe_quant_range(). That way drivers don't > need to worry about is_hdmi2_sink mess. While this is good for display controller drivers, the change isn't great for bridge drivers. Down the road we're looking at moving connector support out of the bridge drivers. Adding an additional dependency to connectors in the bridges will make that more difficult. Ideally bridges should retrieve the information from their sink, regardless of whether it is a connector or another bridge. Please see below for an additional comment. > Cc: Alex Deucher > Cc: "Christian König" > Cc: "David (ChunMing) Zhou" > Cc: Archit Taneja > Cc: Andrzej Hajda > Cc: Laurent Pinchart > Cc: Inki Dae > Cc: Joonyoung Shim > Cc: Seung-Woo Kim > Cc: Kyungmin Park > Cc: Russell King > Cc: CK Hu > Cc: Philipp Zabel > Cc: Rob Clark > Cc: Ben Skeggs > Cc: Tomi Valkeinen > Cc: Sandy Huang > Cc: "Heiko Stübner" > Cc: Benjamin Gaignard > Cc: Vincent Abriou > Cc: Thierry Reding > Cc: Eric Anholt > Cc: Shawn Guo > Cc: Ilia Mirkin > Cc: amd-...@lists.freedesktop.org > Cc: linux-arm-...@vger.kernel.org > Cc: freedr...@lists.freedesktop.org > Cc: nouv...@lists.freedesktop.org > Cc: linux-te...@vger.kernel.org > Signed-off-by: Ville Syrjälä > --- > drivers/gpu/drm/amd/amdgpu/dce_v10_0.c| 2 +- > drivers/gpu/drm/amd/amdgpu/dce_v11_0.c| 2 +- > drivers/gpu/drm/amd/amdgpu/dce_v6_0.c | 3 ++- > drivers/gpu/drm/amd/amdgpu/dce_v8_0.c | 2 +- > drivers/gpu/drm/bridge/analogix-anx78xx.c | 5 ++-- > drivers/gpu/drm/bridge/sii902x.c | 3 ++- > drivers/gpu/drm/bridge/sil-sii8620.c | 3 +-- > drivers/gpu/drm/bridge/synopsys/dw-hdmi.c | 3 ++- > drivers/gpu/drm/drm_edid.c| 33 ++- > drivers/gpu/drm/exynos/exynos_hdmi.c | 3 ++- > drivers/gpu/drm/i2c/tda998x_drv.c | 3 ++- > drivers/gpu/drm/i915/intel_hdmi.c | 14 +- > drivers/gpu/drm/i915/intel_lspcon.c | 15 ++- > drivers/gpu/drm/i915/intel_sdvo.c | 10 --- > drivers/gpu/drm/mediatek/mtk_hdmi.c | 3 ++- > drivers/gpu/drm/msm/hdmi/hdmi_bridge.c| 3 ++- > drivers/gpu/drm/nouveau/dispnv50/disp.c | 7 +++-- > drivers/gpu/drm/omapdrm/omap_encoder.c| 5 ++-- > drivers/gpu/drm/radeon/radeon_audio.c | 2 +- > drivers/gpu/drm/rockchip/inno_hdmi.c | 4 ++- > drivers/gpu/drm/sti/sti_hdmi.c| 3 ++- > drivers/gpu/drm/sun4i/sun4i_hdmi_enc.c| 3 ++- > drivers/gpu/drm/tegra/hdmi.c | 3 ++- > drivers/gpu/drm/tegra/sor.c | 3 ++- > drivers/gpu/drm/vc4/vc4_hdmi.c| 11 +--- > drivers/gpu/drm/zte/zx_hdmi.c | 4 ++- > include/drm/drm_edid.h| 8 +++--- > 27 files changed, 94 insertions(+), 66 deletions(-) For dw-hdmi and omapdrm, Reviewed-by: Laurent Pinchart -- Regards, Laurent Pinchart ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 02/18] drm/atomic-helper: Unexport drm_atomic_helper_best_encoder
Hi Daniel,
On Wednesday, 3 October 2018 12:08:38 EEST Daniel Vetter wrote:
> On Tue, Oct 02, 2018 at 04:53:12PM +0300, Laurent Pinchart wrote:
> > On Tuesday, 2 October 2018 16:35:10 EEST Daniel Vetter wrote:
> > > It's the default. The exported version was kinda a transition state,
> > > before we made this the default.
> > >
> > > To stop new atomic drivers from using it (instead of just relying on
> > > the default) let's unexport it.
> > >
> > > Signed-off-by: Daniel Vetter
> > > Cc: Gustavo Padovan
> > > Cc: Maarten Lankhorst
> > > Cc: Sean Paul
> > > Cc: David Airlie
> > > Cc: VMware Graphics
> > > Cc: Sinclair Yeh
> > > Cc: Thomas Hellstrom
> > > Cc: Archit Taneja
> > > Cc: Neil Armstrong
> > > Cc: Laurent Pinchart
> > > Cc: Hans Verkuil
> > > Cc: Daniel Vetter
> > > Cc: Russell King
> > > Cc: Jernej Skrabec
> > > Cc: Jani Nikula
> > > Cc: Pierre-Hugues Husson
> > > Cc: Fabio Estevam
> > > ---
> > >
> > > drivers/gpu/drm/bridge/synopsys/dw-hdmi.c | 1 -
> > > drivers/gpu/drm/drm_atomic_helper.c | 24 +++
> > > drivers/gpu/drm/vmwgfx/vmwgfx_ldu.c | 1 -
> > > drivers/gpu/drm/vmwgfx/vmwgfx_scrn.c | 1 -
> > > drivers/gpu/drm/vmwgfx/vmwgfx_stdu.c | 1 -
> > > include/drm/drm_atomic_helper.h | 2 --
> > > 6 files changed, 7 insertions(+), 23 deletions(-)
> > >
> > > diff --git a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
> > > b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c index
> > > ac37c50d6c4b..5ac979d3450b 100644
> > > --- a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
> > > +++ b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
> >
> > [snip]
> >
> > > diff --git a/drivers/gpu/drm/drm_atomic_helper.c
> > > b/drivers/gpu/drm/drm_atomic_helper.c index f92b7cf4cbd7..8c93f33fe92f
> > > 100644
> > > --- a/drivers/gpu/drm/drm_atomic_helper.c
> > > +++ b/drivers/gpu/drm/drm_atomic_helper.c
> > > @@ -92,6 +92,13 @@ drm_atomic_helper_plane_changed(struct
> > > drm_atomic_state
> > > *state, }
> > >
> > > }
> > >
> > > +static struct drm_encoder *
> > > +drm_atomic_helper_best_encoder(struct drm_connector *connector)
> > > +{
> > > + WARN_ON(connector->encoder_ids[1]);
> >
> > As you're removing the documentation, I would add a comment here to
> > explain the WARN_ON. Something along the lines of "For connectors that
> > support multiple encoders, the .atomic_best_encoder() or .atomic_encoder()
> > operation must be implemented".
> >
> > You could also rename the function to make it more explicit that it's a
> > default for the single encoder case.
>
> So pick_single_encoder_for_connector()?
Works for me.
> I think that would avoid the need for a comment.
I'd still keep the comment, it won't hurt, and you have it already :-)
> r-b: you with that fixed up?
With the comment and function renamed,
Reviewed-by: Laurent Pinchart
> > > + return drm_encoder_find(connector->dev, NULL,
> > > connector->encoder_ids[0]);
> > > +}
> > > +
> > >
> > > static int handle_conflicting_encoders(struct drm_atomic_state *state,
> > >
> > > bool disable_conflicting_encoders)
> > >
> > > {
> > >
> > > @@ -3376,23 +3383,6 @@ int drm_atomic_helper_page_flip_target(struct
> > > drm_crtc *crtc, }
> > >
> > > EXPORT_SYMBOL(drm_atomic_helper_page_flip_target);
> > >
> > > -/**
> > > - * drm_atomic_helper_best_encoder - Helper for
> > > - * _connector_helper_funcs.best_encoder callback
> > > - * @connector: Connector control structure
> > > - *
> > > - * This is a _connector_helper_funcs.best_encoder callback helper
> > > for
> > > - * connectors that support exactly 1 encoder, statically determined at
> > > driver - * init time.
> > > - */
> > > -struct drm_encoder *
> > > -drm_atomic_helper_best_encoder(struct drm_connector *connector)
> > > -{
> > > - WARN_ON(connector->encoder_ids[1]);
> > > - return drm_encoder_find(connector->dev, NULL,
> > > connector->encoder_ids[0]);
> > > -}
> > > -EXPORT_SYMBOL(drm_atomic_helper_best_encoder);
> > > -
> > >
> > > /**
> > >
> > > * DOC: atomic state reset and initialization
> > > *
> >
> > [snip]
--
Regards,
Laurent Pinchart
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
