[PATCH] drm/msm: Remove prototypes for non-existing functions
The msm_atomic_state_clear() and msm_atomic_state_free() functions are declared but never defined. Remove their prototypes. Signed-off-by: Laurent Pinchart Reviewed-by: Kieran Bingham --- drivers/gpu/drm/msm/msm_drv.h | 2 -- 1 file changed, 2 deletions(-) diff --git a/drivers/gpu/drm/msm/msm_drv.h b/drivers/gpu/drm/msm/msm_drv.h index be016d7b4ef1..48799c678a6b 100644 --- a/drivers/gpu/drm/msm/msm_drv.h +++ b/drivers/gpu/drm/msm/msm_drv.h @@ -254,8 +254,6 @@ void msm_atomic_destroy_pending_timer(struct msm_pending_timer *timer); void msm_atomic_commit_tail(struct drm_atomic_state *state); int msm_atomic_check(struct drm_device *dev, struct drm_atomic_state *state); struct drm_atomic_state *msm_atomic_state_alloc(struct drm_device *dev); -void msm_atomic_state_clear(struct drm_atomic_state *state); -void msm_atomic_state_free(struct drm_atomic_state *state); int msm_crtc_enable_vblank(struct drm_crtc *crtc); void msm_crtc_disable_vblank(struct drm_crtc *crtc); base-commit: f60ef67ff21ede6f3d27d439a136481446dbd8aa -- Regards, Laurent Pinchart
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: [Freedreno] [PATCH] drm: improve the documentation of connector hpd ops
Hi Abhinav,
Thank you for the patch (and thank to Dmitry for pinging me on IRC, this
patch got burried in my inbox).
On Wed, Sep 20, 2023 at 01:13:58PM -0700, Abhinav Kumar wrote:
> While making the changes in [1], it was noted that the documentation
> of the enable_hpd() and disable_hpd() does not make it clear that
> these ops should not try to do hpd state maintenance and should only
> attempt to enable/disable hpd related hardware for the connector.
s/attempt to //
>
> The state management of these calls to make sure these calls are
> balanced is handled by the DRM core and we should keep it that way
> to minimize the overhead in the drivers which implement these ops.
>
> [1]: https://patchwork.freedesktop.org/patch/558387/
>
You could add a
Suggested-by: Laurent Pinchart
> Signed-off-by: Abhinav Kumar
Reviewed-by: Laurent Pinchart
> ---
> include/drm/drm_modeset_helper_vtables.h | 10 ++
> 1 file changed, 10 insertions(+)
>
> diff --git a/include/drm/drm_modeset_helper_vtables.h
> b/include/drm/drm_modeset_helper_vtables.h
> index e3c3ac615909..a33cf7488737 100644
> --- a/include/drm/drm_modeset_helper_vtables.h
> +++ b/include/drm/drm_modeset_helper_vtables.h
> @@ -1154,6 +1154,11 @@ struct drm_connector_helper_funcs {
>* This operation is optional.
>*
>* This callback is used by the drm_kms_helper_poll_enable() helpers.
> + *
> + * This operation does not need to perform any hpd state tracking as
> + * the DRM core handles that maintenance and ensures the calls to enable
> + * and disable hpd are balanced.
> + *
>*/
> void (*enable_hpd)(struct drm_connector *connector);
>
> @@ -1165,6 +1170,11 @@ struct drm_connector_helper_funcs {
>* This operation is optional.
>*
>* This callback is used by the drm_kms_helper_poll_disable() helpers.
> + *
> + * This operation does not need to perform any hpd state tracking as
> + * the DRM core handles that maintenance and ensures the calls to enable
> + * and disable hpd are balanced.
> + *
>*/
> void (*disable_hpd)(struct drm_connector *connector);
> };
--
Regards,
Laurent Pinchart
Re: [Freedreno] [RFC PATCH 03/10] drm/mipi-dsi: add API for manual control over the DSI link power state
On Wed, Nov 08, 2023 at 04:34:39PM +0100, Maxime Ripard wrote: > On Tue, Nov 07, 2023 at 04:26:34PM +0100, Greg Kroah-Hartman wrote: > > On Tue, Nov 07, 2023 at 01:18:14PM +0100, Maxime Ripard wrote: > > > On Tue, Nov 07, 2023 at 12:22:21PM +0100, Greg Kroah-Hartman wrote: > > > > On Tue, Nov 07, 2023 at 11:57:49AM +0100, Maxime Ripard wrote: > > > > > +GKH > > > > > > > > Why? I don't see a question for me here, sorry. > > > > > > I guess the question is: we have a bus with various power states > > > (powered off, low power, high speed) > > > > Great, have fun! And is this per-device or per-bus-instance? > > Per bus instance To be precise, those power states are link states. They don't necessarily translate directly to device power states, and they're not so much about power management than speed (and bus turn-around for reads) management. Also, while DSI allows for multiple peripherals on a bus, the link is point-to-point, with the peripherals being all behind a single DSI RX. > > > low power is typically used to send commands to a device, high speed to > > > transmit pixels, but still allows to send commands. Low power (LP) is a link state where commands can be transmitted at a low speed, as opposed to the high speed (HS) link state that is used to transmit both video data and commands at high speed. Any device-to-host data transfer (in response to read commands) occurs exclusively in LP mode (at least with DSI v1.3, I don't have acces to newer specifications). > > > Depending on the devices, there's different requirements about the state > > > devices expect the bus to be in to send commands. Some will need to send > > > all the commands in the low power state, some don't care, etc. See > > > the mail I was replying too for more details. > > > > > > We've tried so far to model that in KMS itself, so the framework the > > > drivers would register too, but we're kind of reaching the limits of > > > what we can do there. It also feels to me that "the driver can't access > > > its device" is more of a problem for the bus to solve rather than the > > > framework. > > > > This is up to the specific bus to resolve, there's nothing special > > needed in the driver core for it, right? > > Yeah, we weren't really looking to handle this into the driver core, but > rather if there was a set of guidelines or feedback on implementing > those kind of features for a bus. > > > > Do you agree? Are you aware of any other bus in Linux with similar > > > requirements we could look at? Or any suggestion on how to solve it? > > > > There might be others, yes, look at how the dynamic power management > > works for different devices on most busses, that might help you out > > here. > > Thanks for the pointers, we'll have a look -- Regards, Laurent Pinchart
Re: [Freedreno] [PATCH] drm: remove drm_bridge_hpd_disable() from drm_bridge_connector_destroy()
Hi Abhinav,
Thank you for the patch.
On Tue, Sep 19, 2023 at 10:48:12AM -0700, Abhinav Kumar wrote:
> drm_bridge_hpd_enable()/drm_bridge_hpd_disable() callbacks call into
> the respective driver's hpd_enable()/hpd_disable() ops. These ops control
> the HPD enable/disable logic which in some cases like MSM can be a
> dedicate hardware block to control the HPD.
>
> During probe_defer cases, a connector can be initialized and then later
> destroyed till the probe is retried. During connector destroy in these
> cases, the hpd_disable() callback gets called without a corresponding
> hpd_enable() leading to an unbalanced state potentially causing even
> a crash.
>
> This can be avoided by the respective drivers maintaining their own
> state logic to ensure that a hpd_disable() without a corresponding
> hpd_enable() just returns without doing anything.
>
> However, to have a generic fix it would be better to avoid the
> hpd_disable() callback from the connector destroy path and let
> the hpd_enable() / hpd_disable() balance be maintained by the
> corresponding drm_bridge_connector_enable_hpd() /
> drm_bridge_connector_disable_hpd() APIs which should get called by
> drm_kms_helper_disable_hpd().
The change makes sense to me, but I'm a bit worried this could introduce
a regression by leaving HPD enabled in some cases.
I agree that bridges shouldn't track the HPD state, it should be tracked
by the core and the .enable_hpd() and .disable_hpd() operations should
be balanced. Their documentation, however, doesn't clearly state this,
and the documentation of the callers of these operations is also fairly
unclear.
Could you perhaps try to improve the documentation ? With that,
Reviewed-by: Laurent Pinchart
for this patch.
> changes in v2:
> - minor change in commit text (Dmitry)
>
> Signed-off-by: Abhinav Kumar
> Reviewed-by: Dmitry Baryshkov
> ---
> drivers/gpu/drm/drm_bridge_connector.c | 6 --
> 1 file changed, 6 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_bridge_connector.c
> b/drivers/gpu/drm/drm_bridge_connector.c
> index 1da93d5a1f61..c4dba39acfd8 100644
> --- a/drivers/gpu/drm/drm_bridge_connector.c
> +++ b/drivers/gpu/drm/drm_bridge_connector.c
> @@ -187,12 +187,6 @@ static void drm_bridge_connector_destroy(struct
> drm_connector *connector)
> struct drm_bridge_connector *bridge_connector =
> to_drm_bridge_connector(connector);
>
> - if (bridge_connector->bridge_hpd) {
> - struct drm_bridge *hpd = bridge_connector->bridge_hpd;
> -
> - drm_bridge_hpd_disable(hpd);
> - }
> -
> drm_connector_unregister(connector);
> drm_connector_cleanup(connector);
>
--
Regards,
Laurent Pinchart
Re: [Freedreno] [PATCH v4 0/3] drm: simplify support for transparent DRM bridges
Hi Dmitry, On Mon, Sep 04, 2023 at 12:02:18AM +0300, Dmitry Baryshkov wrote: > On Tue, 22 Aug 2023 at 17:17, Laurent Pinchart wrote: > > On Thu, Aug 17, 2023 at 05:55:13PM +0300, Dmitry Baryshkov wrote: > > > Supporting DP/USB-C can result in a chain of several transparent > > > bridges (PHY, redrivers, mux, etc). This results in drivers having > > > similar boilerplate code for such bridges. > > > > What do you mean by transparent bridge here ? Bridges are a DRM concept, > > and as far as I can tell, a PHY isn't a bridge. Why does it need to be > > handled as one, especially if it's completely transparent ? > > > > > Next, these drivers are susceptible to -EPROBE_DEFER loops: the next > > > bridge can either be probed from the bridge->attach callback, when it is > > > too late to return -EPROBE_DEFER, or from the probe() callback, when the > > > next bridge might not yet be available, because it depends on the > > > resources provided by the probing device. > > > > Can't device links help avoiding defer probing in those cases ? > > It looks like both Neil and I missed this question. And I missed this reply before replying to Neil and pointing to device links again :-) > Two items wrt devlinks. First, I view them as a helper. So if one > disables the devlinks enforcement, he'd still get a deferral loop. That may be true, but I don't think that's a compelling argument. If one disables components meant to avoid probe deferral, they should expect probe deferral :-) > Second, in this case we can not enforce devlinks (or return > -EPROBE_DEFER from the probe() function) because the next bridge is > not yet available when the main driver probes. Unfortunately bridges > are allocated in the opposite order. So, using AUX devices helps us to > break it. Because first typec mux/retimer/switch/etc devices probe (in > the direction from the typec source to the typec port). Then DRM > bridge devices are probed starting from the end of the chain > (connector) to the DP source (root DP bridge/controller). I'm not too familiar with the drivers involved in the typec chain. Do you mean that the sink driver needs to get hold of the source device at probe time, deferring probe if the source is not available ? Does the driver handler the USB connector need to do the same ? I'm looking at the qcom_pmic_typec driver and I don't immediately see where it would defer probing if its source isn't available, but I may well be missing something. > > > Last, but not least, this results in the the internal knowledge of DRM > > > subsystem slowly diffusing into other subsystems, like PHY or USB/TYPEC. > > > > Why so ? The PHY subsystem should provide a PHY, without considering > > what subsystem it will be used by. This patch series seems to me to > > actually create this DRM dependency in other subsystems, which I don't > > think is a very good idea. Resources should be registered in their own > > subsystem with the appropriate API, not in a way that is tied to a > > particular consumer. > > > > > To solve all these issues, define a separate DRM helper, which creates > > > separate aux device just for the bridge. During probe such aux device > > > doesn't result in the EPROBE_DEFER loops. Instead it allows the device > > > drivers to probe properly, according to the actual resource > > > dependencies. The bridge auxdevs are then probed when the next bridge > > > becomes available, sparing drivers from drm_bridge_attach() returning > > > -EPROBE_DEFER. > > > > I'm not thrilled :-( Let's discuss the questions above first. > > Laurent, please excuse me for the ping. Any further response from your side? > I'd like to send the next iteration of this patchset. > > > > Proposed merge strategy: immutable branch with the drm commit, which is > > > then merged into PHY and USB subsystems together with the corresponding > > > patch. -- Regards, Laurent Pinchart
Re: [Freedreno] [PATCH v4 0/3] drm: simplify support for transparent DRM bridges
Hi Neil, Sorry about the delay, the series got burried in my inbox. On Tue, Aug 22, 2023 at 04:27:37PM +0200, Neil Armstrong wrote: > On 22/08/2023 16:19, Laurent Pinchart wrote: > > On Tue, Aug 22, 2023 at 05:17:37PM +0300, Laurent Pinchart wrote: > >> On Thu, Aug 17, 2023 at 05:55:13PM +0300, Dmitry Baryshkov wrote: > >>> Supporting DP/USB-C can result in a chain of several transparent > >>> bridges (PHY, redrivers, mux, etc). This results in drivers having > >>> similar boilerplate code for such bridges. > >> > >> What do you mean by transparent bridge here ? Bridges are a DRM concept, > >> and as far as I can tell, a PHY isn't a bridge. Why does it need to be > >> handled as one, especially if it's completely transparent ? > >> > >>> Next, these drivers are susceptible to -EPROBE_DEFER loops: the next > >>> bridge can either be probed from the bridge->attach callback, when it is > >>> too late to return -EPROBE_DEFER, or from the probe() callback, when the > >>> next bridge might not yet be available, because it depends on the > >>> resources provided by the probing device. > >> > >> Can't device links help avoiding defer probing in those cases ? > >> > >>> Last, but not least, this results in the the internal knowledge of DRM > >>> subsystem slowly diffusing into other subsystems, like PHY or USB/TYPEC. > >> > >> Why so ? The PHY subsystem should provide a PHY, without considering > >> what subsystem it will be used by. This patch series seems to me to > >> actually create this DRM dependency in other subsystems, > > > > I was wrong on this one, there are indeed existing drm_bridge instances > > in drivers/usb/ and drivers/phy/. That's certainly not nice. Why do we > > even need drm_bridge there, why can't the PHYs be acquired by their > > consumers in DRM (and anywhere else) using the PHY API ? > > Because with USB-C Altmode/USB4/Thunderbolt, DisplayPort is one of the > data streams handled by PHYs, USB-C PD manager, re-timers, SBU muxes... > and all this must be coordinated with the display controller and can > be considered as bridges between the DP controller and the USB-C connector. > > As of today, it has been handled by OOB events on Intel & AMD, but the > entirety > of USB-C chain is handled in firmare, so this scales. > When we need to describe the entire USB-C data stream chain as port/endpoint > in DT, OOB handling doesn't work anymore since we need to sync the entire > USB-C chain (muxes, switches, retimers, phys...) handled by Linux before > starting the DP stream. No disagreement here. Handling the component as part of the bridges chain certainly helps. Ideally, this should be done without spreading usage of drm_bridge outside of the DRM subsystem. For instance, we handle (some) D-PHYs in DRM and V4L2 by exposing them as PHYs, and acquiring them in DSI or CSI-2 controller drivers. Do I understand correctly that, in this case, the video stream is fully handled by the PHY (& related) component, without any other device (in the OF sense) wrapping the PHY like the DSI and CSI-2 controllers do ? If so that would indeed make it difficult to create the drm_bridge in a DRM driver that would acquire the PHY. We could come up with a different mechanism, but that's likely overkill to solve this particular issue (at least until other similar use cases create a critical mass that will call for a major refactoring). In this specific case, however, I'm a bit puzzled. What coordination is required between the PHYs and the display controller ? The two drivers modified in patches 2/3 and 3/3 indeed create bridges, but those bridges don't implement any operation other than attach. Is this needed only because the PHY has an OF node that sits between the display controller and the connector, requiring a drm_bridge to exist to bridge the gap and create a complete chain of bridges up to the connector ? This would simplify the use case, but probably still call for creating a drm_bridge in the PHY driver, as other solutions are likely still too complex. It seems to me that this series tries to address two issues. One of them is minimizing the DRM-specific amount of code needed in the PHY drivers. The second one is to avoid probe deferrals. For the first issue, I agree that a helper is currently a good option. For the second issue, however, couldn't device links help avoiding probe deferral ? If so, the helper could be simplified, avoiding the need to create an auxiliary device. > >> which I don't > >> think is a very good idea. Resources should be registered in their own > >> subsystem with the appro
Re: [Freedreno] [RFC PATCH v1 01/12] Revert "drm/sysfs: Link DRM connectors to corresponding Type-C connectors"
On Wed, Sep 06, 2023 at 03:48:35PM +0300, Dmitry Baryshkov wrote: > On Wed, 6 Sept 2023 at 15:44, Heikki Krogerus wrote: > > On Tue, Sep 05, 2023 at 01:56:59PM +0300, Dmitry Baryshkov wrote: > > > On Tue, 5 Sept 2023 at 11:50, Heikki Krogerus wrote: > > > > On Mon, Sep 04, 2023 at 12:41:39AM +0300, Dmitry Baryshkov wrote: > > > > > The kdev->fwnode pointer is never set in drm_sysfs_connector_add(), so > > > > > dev_fwnode() checks never succeed, making the respective commit NOP. > > > > > > > > That's not true. The dev->fwnode is assigned when the device is > > > > created on ACPI platforms automatically. If the drm_connector fwnode > > > > member is assigned before the device is registered, then that fwnode > > > > is assigned also to the device - see > > > > drm_connector_acpi_find_companion(). > > > > > > > > But please note that even if drm_connector does not have anything in > > > > its fwnode member, the device may still be assigned fwnode, just based > > > > on some other logic (maybe in drivers/acpi/acpi_video.c?). > > > > > > > > > And if drm_sysfs_connector_add() is modified to set kdev->fwnode, it > > > > > breaks drivers already using components (as it was pointed at [1]), > > > > > resulting in a deadlock. Lockdep trace is provided below. > > > > > > > > > > Granted these two issues, it seems impractical to fix this commit in > > > > > any > > > > > sane way. Revert it instead. > > > > > > > > I think there is already user space stuff that relies on these links, > > > > so I'm not sure you can just remove them like that. If the component > > > > framework is not the correct tool here, then I think you need to > > > > suggest some other way of creating them. > > > > > > The issue (that was pointed out during review) is that having a > > > component code in the framework code can lead to lockups. With the > > > patch #2 in place (which is the only logical way to set kdev->fwnode > > > for non-ACPI systems) probing of drivers which use components and set > > > drm_connector::fwnode breaks immediately. > > > > > > Can we move the component part to the respective drivers? With the > > > patch 2 in place, connector->fwnode will be copied to the created > > > kdev's fwnode pointer. > > > > > > Another option might be to make this drm_sysfs component registration > > > optional. > > > > You don't need to use the component framework at all if there is > > a better way of determining the connection between the DP and its > > Type-C connector (I'm assuming that that's what this series is about). > > You just need the symlinks, not the component. > > The problem is that right now this component registration has become > mandatory. And if I set the kdev->fwnode manually (like in the patch > 2), the kernel hangs inside the component code. > That's why I proposed to move the components to the place where they > are really necessary, e.g. i915 and amd drivers. I'm all for keeping the component framework out of common code. I dislike that framework with passion, and still haven't lost all hopes of replacing it with something better. -- Regards, Laurent Pinchart
Re: [Freedreno] [PATCH v4 0/3] drm: simplify support for transparent DRM bridges
On Tue, Aug 22, 2023 at 05:17:37PM +0300, Laurent Pinchart wrote: > Hi Dmitry, > > Thank you for the patches. > > On Thu, Aug 17, 2023 at 05:55:13PM +0300, Dmitry Baryshkov wrote: > > Supporting DP/USB-C can result in a chain of several transparent > > bridges (PHY, redrivers, mux, etc). This results in drivers having > > similar boilerplate code for such bridges. > > What do you mean by transparent bridge here ? Bridges are a DRM concept, > and as far as I can tell, a PHY isn't a bridge. Why does it need to be > handled as one, especially if it's completely transparent ? > > > Next, these drivers are susceptible to -EPROBE_DEFER loops: the next > > bridge can either be probed from the bridge->attach callback, when it is > > too late to return -EPROBE_DEFER, or from the probe() callback, when the > > next bridge might not yet be available, because it depends on the > > resources provided by the probing device. > > Can't device links help avoiding defer probing in those cases ? > > > Last, but not least, this results in the the internal knowledge of DRM > > subsystem slowly diffusing into other subsystems, like PHY or USB/TYPEC. > > Why so ? The PHY subsystem should provide a PHY, without considering > what subsystem it will be used by. This patch series seems to me to > actually create this DRM dependency in other subsystems, I was wrong on this one, there are indeed existing drm_bridge instances in drivers/usb/ and drivers/phy/. That's certainly not nice. Why do we even need drm_bridge there, why can't the PHYs be acquired by their consumers in DRM (and anywhere else) using the PHY API ? > which I don't > think is a very good idea. Resources should be registered in their own > subsystem with the appropriate API, not in a way that is tied to a > particular consumer. > > > To solve all these issues, define a separate DRM helper, which creates > > separate aux device just for the bridge. During probe such aux device > > doesn't result in the EPROBE_DEFER loops. Instead it allows the device > > drivers to probe properly, according to the actual resource > > dependencies. The bridge auxdevs are then probed when the next bridge > > becomes available, sparing drivers from drm_bridge_attach() returning > > -EPROBE_DEFER. > > I'm not thrilled :-( Let's discuss the questions above first. > > > Proposed merge strategy: immutable branch with the drm commit, which is > > then merged into PHY and USB subsystems together with the corresponding > > patch. > > > > Changes since v3: > > - Moved bridge driver to gpu/drm/bridge (Neil Armstrong) > > - Renamed it to aux-bridge (since there is already a simple_bridge driver) > > - Made CONFIG_OF mandatory for this driver (Neil Armstrong) > > - Added missing kfree and ida_free (Dan Carpenter) > > > > Changes since v2: > > - ifdef'ed bridge->of_node access (LKP) > > > > Changes since v1: > > - Added EXPORT_SYMBOL_GPL / MODULE_LICENSE / etc. to drm_simple_bridge > > > > Dmitry Baryshkov (3): > > drm/bridge: add transparent bridge helper > > phy: qcom: qmp-combo: switch to DRM_AUX_BRIDGE > > usb: typec: nb7vpq904m: switch to DRM_AUX_BRIDGE > > > > drivers/gpu/drm/bridge/Kconfig| 9 ++ > > drivers/gpu/drm/bridge/Makefile | 1 + > > drivers/gpu/drm/bridge/aux-bridge.c | 132 ++ > > drivers/phy/qualcomm/Kconfig | 2 +- > > drivers/phy/qualcomm/phy-qcom-qmp-combo.c | 44 +--- > > drivers/usb/typec/mux/Kconfig | 2 +- > > drivers/usb/typec/mux/nb7vpq904m.c| 44 +--- > > include/drm/bridge/aux-bridge.h | 19 > > 8 files changed, 167 insertions(+), 86 deletions(-) > > create mode 100644 drivers/gpu/drm/bridge/aux-bridge.c > > create mode 100644 include/drm/bridge/aux-bridge.h -- Regards, Laurent Pinchart
Re: [Freedreno] [PATCH v4 0/3] drm: simplify support for transparent DRM bridges
Hi Dmitry, Thank you for the patches. On Thu, Aug 17, 2023 at 05:55:13PM +0300, Dmitry Baryshkov wrote: > Supporting DP/USB-C can result in a chain of several transparent > bridges (PHY, redrivers, mux, etc). This results in drivers having > similar boilerplate code for such bridges. What do you mean by transparent bridge here ? Bridges are a DRM concept, and as far as I can tell, a PHY isn't a bridge. Why does it need to be handled as one, especially if it's completely transparent ? > Next, these drivers are susceptible to -EPROBE_DEFER loops: the next > bridge can either be probed from the bridge->attach callback, when it is > too late to return -EPROBE_DEFER, or from the probe() callback, when the > next bridge might not yet be available, because it depends on the > resources provided by the probing device. Can't device links help avoiding defer probing in those cases ? > Last, but not least, this results in the the internal knowledge of DRM > subsystem slowly diffusing into other subsystems, like PHY or USB/TYPEC. Why so ? The PHY subsystem should provide a PHY, without considering what subsystem it will be used by. This patch series seems to me to actually create this DRM dependency in other subsystems, which I don't think is a very good idea. Resources should be registered in their own subsystem with the appropriate API, not in a way that is tied to a particular consumer. > To solve all these issues, define a separate DRM helper, which creates > separate aux device just for the bridge. During probe such aux device > doesn't result in the EPROBE_DEFER loops. Instead it allows the device > drivers to probe properly, according to the actual resource > dependencies. The bridge auxdevs are then probed when the next bridge > becomes available, sparing drivers from drm_bridge_attach() returning > -EPROBE_DEFER. I'm not thrilled :-( Let's discuss the questions above first. > Proposed merge strategy: immutable branch with the drm commit, which is > then merged into PHY and USB subsystems together with the corresponding > patch. > > Changes since v3: > - Moved bridge driver to gpu/drm/bridge (Neil Armstrong) > - Renamed it to aux-bridge (since there is already a simple_bridge driver) > - Made CONFIG_OF mandatory for this driver (Neil Armstrong) > - Added missing kfree and ida_free (Dan Carpenter) > > Changes since v2: > - ifdef'ed bridge->of_node access (LKP) > > Changes since v1: > - Added EXPORT_SYMBOL_GPL / MODULE_LICENSE / etc. to drm_simple_bridge > > Dmitry Baryshkov (3): > drm/bridge: add transparent bridge helper > phy: qcom: qmp-combo: switch to DRM_AUX_BRIDGE > usb: typec: nb7vpq904m: switch to DRM_AUX_BRIDGE > > drivers/gpu/drm/bridge/Kconfig| 9 ++ > drivers/gpu/drm/bridge/Makefile | 1 + > drivers/gpu/drm/bridge/aux-bridge.c | 132 ++ > drivers/phy/qualcomm/Kconfig | 2 +- > drivers/phy/qualcomm/phy-qcom-qmp-combo.c | 44 +--- > drivers/usb/typec/mux/Kconfig | 2 +- > drivers/usb/typec/mux/nb7vpq904m.c| 44 +--- > include/drm/bridge/aux-bridge.h | 19 ++++ > 8 files changed, 167 insertions(+), 86 deletions(-) > create mode 100644 drivers/gpu/drm/bridge/aux-bridge.c > create mode 100644 include/drm/bridge/aux-bridge.h -- Regards, Laurent Pinchart
Re: [Freedreno] [PATCH 00/53] drm: Convert to platform remove callback returning void
Hi Doug, On Thu, Jun 08, 2023 at 09:08:15AM -0700, Doug Anderson wrote: > On Thu, Jun 1, 2023 at 8:40 AM Uwe Kleine-König wrote: > > On Sun, May 07, 2023 at 06:25:23PM +0200, Uwe Kleine-König wrote: > > > this patch series adapts the platform drivers below drivers/gpu/drm > > > to use the .remove_new() callback. Compared to the traditional .remove() > > > callback .remove_new() returns no value. This is a good thing because > > > the driver core doesn't (and cannot) cope for errors during remove. The > > > only effect of a non-zero return value in .remove() is that the driver > > > core emits a warning. The device is removed anyhow and an early return > > > from .remove() usually yields a resource leak. > > > > > > By changing the remove callback to return void driver authors cannot > > > reasonably (but wrongly) assume any more that there happens some kind of > > > cleanup later. > > > > I wonder if someone would volunteer to add the whole series to > > drm-misc-next?! > > It looks as if Neil applied quite a few of them already, so I looked > at what was left... > > I'm a little hesitant to just apply the whole kit-and-caboodle to > drm-misc-next since there are specific DRM trees for a bunch of them > and it would be better if they landed there. ...so I went through all > the patches that still applied to drm-misc-next, then used > 'scripts/get_maintainer.pl --scm' to check if they were maintained > through drm-misc. That still left quite a few patches. I've applied > those ones and pushed to drm-misc-next: > > 71722685cd17 drm/xlnx/zynqmp_dpsub: Convert to platform remove > callback returning void > 1ed54a19f3b3 drm/vc4: Convert to platform remove callback returning void > b957812839f8 drm/v3d: Convert to platform remove callback returning void > e2fd3192e267 drm/tve200: Convert to platform remove callback returning void > 84e6da7ad553 drm/tiny: Convert to platform remove callback returning void > 34cdd1f691ad drm/tidss: Convert to platform remove callback returning void > d665e3c9d37a drm/sun4i: Convert to platform remove callback returning void > 0c259ab19146 drm/stm: Convert to platform remove callback returning void > 9a865e45884a drm/sti: Convert to platform remove callback returning void > 3c855610840e drm/rockchip: Convert to platform remove callback returning void > e41977a83b71 drm/panfrost: Convert to platform remove callback returning void > cef3776d0b5a drm/panel: Convert to platform remove callback returning void > bd296a594e87 drm/mxsfb: Convert to platform remove callback returning void > 38ca2d93d323 drm/meson: Convert to platform remove callback returning void > fd1457d84bae drm/mcde: Convert to platform remove callback returning void > 41a56a18615c drm/logicvc: Convert to platform remove callback returning void > 980ec6444372 drm/lima: Convert to platform remove callback returning void > 82a2c0cc1a22 drm/hisilicon: Convert to platform remove callback returning void > c3b28b29ac0a drm/fsl-dcu: Convert to platform remove callback returning void > a118fc6e71f9 drm/atmel-hlcdc: Convert to platform remove callback returning > void > 9a32dd324c46 drm/aspeed: Convert to platform remove callback returning void > 2c7d291c498c drm/arm/malidp: Convert to platform remove callback returning > void > a920028df679 drm/arm/hdlcd: Convert to platform remove callback returning void > 1bf3d76a7d15 drm/komeda: Convert to platform remove callback returning void > > The following ones appeared to apply to the top of drm-misc-next, but > I didn't apply them since get_maintainer didn't say they were part of > drm-misc-next: > > drm/tiny: Convert to platform remove callback returning void > drm/tilcdc: Convert to platform remove callback returning void > drm/sprd: Convert to platform remove callback returning void > drm/shmobile: Convert to platform remove callback returning void > drm/rcar-du: Convert to platform remove callback returning void If you don't mind, could you take the rcar-du patch through drm-misc too ? I don't plan to send another pull request for v6.5. > drm/omap: Convert to platform remove callback returning void Tomi, should drm/omap moved to being maintained through drm-misc ? > drm/nouveau: Convert to platform remove callback returning void > drm/mediatek: Convert to platform remove callback returning void > drm/kmb: Convert to platform remove callback returning void > drm/ingenic: Convert to platform remove callback returning void > drm/imx/ipuv3: Convert to platform remove callback returning void > drm/imx/dcss: Convert to platform remove callback returning void > drm/etnaviv: Convert to platform remove callback returning void > drm/armada: Convert to platform remove callback returning void -- Regards, Laurent Pinchart
Re: [Freedreno] [PATCH 1/3] dt-bindings: display: hdmi-connector: add hdmi-pwr supply
Hi Dmitry, Thank you for the patch. On Sun, May 07, 2023 at 11:12:16PM +0300, Dmitry Baryshkov wrote: > Follow the dp-connector example and add hdmi-pwr supply to drive the 5V > pin of the HDMI connector (together with some simple glue logic possibly > attached to the connector). > > Signed-off-by: Dmitry Baryshkov > --- > .../devicetree/bindings/display/connector/hdmi-connector.yaml | 3 +++ > 1 file changed, 3 insertions(+) > > diff --git > a/Documentation/devicetree/bindings/display/connector/hdmi-connector.yaml > b/Documentation/devicetree/bindings/display/connector/hdmi-connector.yaml > index 83c0d008265b..94f75359c6ff 100644 > --- a/Documentation/devicetree/bindings/display/connector/hdmi-connector.yaml > +++ b/Documentation/devicetree/bindings/display/connector/hdmi-connector.yaml > @@ -36,6 +36,9 @@ properties: > description: GPIO signal to enable DDC bus > maxItems: 1 > > + hdmi-pwr-supply: > +description: Power supply for the HDMI 5v pin connector I'd write description: Power supply for the HDMI +5V Power pin to match the HDMI specification. With that, Reviewed-by: Laurent Pinchart > + >port: > $ref: /schemas/graph.yaml#/properties/port > description: Connection to controller providing HDMI signals -- Regards, Laurent Pinchart
Re: [Freedreno] [PATCH 1/3] dt-bindings: display: hdmi-connector: add hdmi-pwr supply
Hi Rob,
On Sun, May 07, 2023 at 04:25:44PM -0500, Rob Herring wrote:
> On Sun, 07 May 2023 23:12:16 +0300, Dmitry Baryshkov wrote:
> > Follow the dp-connector example and add hdmi-pwr supply to drive the 5V
> > pin of the HDMI connector (together with some simple glue logic possibly
> > attached to the connector).
> >
> > Signed-off-by: Dmitry Baryshkov
> > ---
> > .../devicetree/bindings/display/connector/hdmi-connector.yaml | 3 +++
> > 1 file changed, 3 insertions(+)
> >
>
> My bot found errors running 'make DT_CHECKER_FLAGS=-m dt_binding_check'
> on your patch (DT_CHECKER_FLAGS is new in v5.13):
The issues below don't seem to be related to Dmitry's patch, are they ?
> yamllint warnings/errors:
>
> dtschema/dtc warnings/errors:
> /builds/robherring/dt-review-ci/linux/Documentation/devicetree/bindings/media/i2c/ovti,ov2685.example.dtb:
> camera-sensor@3c: port:endpoint:data-lanes: [[1]] is too short
> From schema:
> /builds/robherring/dt-review-ci/linux/Documentation/devicetree/bindings/media/i2c/ovti,ov2685.yaml
> /builds/robherring/dt-review-ci/linux/Documentation/devicetree/bindings/media/rockchip-isp1.example.dtb:
> camera@3c: port:endpoint:data-lanes: [[1]] is too short
> From schema:
> /builds/robherring/dt-review-ci/linux/Documentation/devicetree/bindings/media/i2c/ovti,ov2685.yaml
> /builds/robherring/dt-review-ci/linux/Documentation/devicetree/bindings/pci/fsl,imx6q-pcie-ep.example.dtb:
> pcie-ep@3380: Unevaluated properties are not allowed
> ('assigned-clock-parents', 'assigned-clock-rates', 'assigned-clocks' were
> unexpected)
> From schema:
> /builds/robherring/dt-review-ci/linux/Documentation/devicetree/bindings/pci/fsl,imx6q-pcie-ep.yaml
>
> doc reference errors (make refcheckdocs):
> Documentation/usb/gadget_uvc.rst:
> Documentation/userspace-api/media/v4l/pixfmt-packed.yuv.rst
> MAINTAINERS: Documentation/devicetree/bindings/pwm/pwm-apple.yaml
>
> See
> https://patchwork.ozlabs.org/project/devicetree-bindings/patch/20230507201218.2339014-2-dmitry.barysh...@linaro.org
>
> The base for the series is generally the latest rc1. A different dependency
> should be noted in *this* patch.
>
> If you already ran 'make dt_binding_check' and didn't see the above
> error(s), then make sure 'yamllint' is installed and dt-schema is up to
> date:
>
> pip3 install dtschema --upgrade
>
> Please check and re-submit after running the above command yourself. Note
> that DT_SCHEMA_FILES can be set to your schema file to speed up checking
> your schema. However, it must be unset to test all examples with your schema.
--
Regards,
Laurent Pinchart
Re: [Freedreno] [PATCH 3/3] drm/bridge: display-connector: handle hdmi-pwr supply
Hi Dmitry,
Thank you for the patch.
On Sun, May 07, 2023 at 11:12:18PM +0300, Dmitry Baryshkov wrote:
> On some devices the 5V pin of the HDMI connector and/or the ESD
> protection logic is powered on by a separate regulator. Instead of
> declaring this regulator as always-on, make hdmi-connector support the
> additional hdmi-pwr supply.
>
> Signed-off-by: Dmitry Baryshkov
> ---
> drivers/gpu/drm/bridge/display-connector.c | 37 +-
> 1 file changed, 29 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/gpu/drm/bridge/display-connector.c
> b/drivers/gpu/drm/bridge/display-connector.c
> index 0d94e6edea50..037ba2eb5a2f 100644
> --- a/drivers/gpu/drm/bridge/display-connector.c
> +++ b/drivers/gpu/drm/bridge/display-connector.c
> @@ -337,18 +337,12 @@ static int display_connector_probe(struct
> platform_device *pdev)
> return ret;
> }
> }
> -
> - if (conn->connector_pwr) {
> - ret = regulator_enable(conn->connector_pwr);
> - if (ret) {
> - dev_err(&pdev->dev, "failed to enable DP PWR
> regulator: %d\n", ret);
> - return ret;
> - }
> - }
> }
>
> /* enable DDC */
> if (type == DRM_MODE_CONNECTOR_HDMIA) {
> + int ret;
> +
> conn->ddc_en = devm_gpiod_get_optional(&pdev->dev, "ddc-en",
> GPIOD_OUT_HIGH);
>
> @@ -356,6 +350,33 @@ static int display_connector_probe(struct
> platform_device *pdev)
> dev_err(&pdev->dev, "Couldn't get ddc-en gpio\n");
> return PTR_ERR(conn->ddc_en);
> }
> +
> + conn->connector_pwr = devm_regulator_get_optional(&pdev->dev,
> "hdmi-pwr");
> +
> + if (IS_ERR(conn->connector_pwr)) {
> + ret = PTR_ERR(conn->connector_pwr);
> +
> + switch (ret) {
> + case -ENODEV:
> + conn->connector_pwr = NULL;
> + break;
> +
> + case -EPROBE_DEFER:
> + return -EPROBE_DEFER;
> +
> + default:
> + dev_err(&pdev->dev, "failed to get HDMI PWR
> regulator: %d\n", ret);
> + return ret;
> + }
> + }
> + }
Please share this logic with the DP code. You can move it to a separate
function for instance, that would take the regulator name as a
parameter.
> +
> + if (conn->connector_pwr) {
> + ret = regulator_enable(conn->connector_pwr);
> + if (ret) {
> + dev_err(&pdev->dev, "failed to enable DP PWR regulator:
> %d\n", ret);
> + return ret;
> + }
> }
>
> conn->bridge.funcs = &display_connector_bridge_funcs;
--
Regards,
Laurent Pinchart
Re: [Freedreno] [PATCH 2/3] drm/bridge: display-connector: rename dp_pwr to connector_pwr
Hi Dmitry,
Thank you for the patch.
On Sun, May 07, 2023 at 11:12:17PM +0300, Dmitry Baryshkov wrote:
> In preparation to adding support for the hdmi_pwr supply, rename dp_pwr
> structure field to the generic connector_pwr.
>
> Signed-off-by: Dmitry Baryshkov
> ---
> drivers/gpu/drm/bridge/display-connector.c | 18 +-
> 1 file changed, 9 insertions(+), 9 deletions(-)
>
> diff --git a/drivers/gpu/drm/bridge/display-connector.c
> b/drivers/gpu/drm/bridge/display-connector.c
> index 9a12449ad7b8..0d94e6edea50 100644
> --- a/drivers/gpu/drm/bridge/display-connector.c
> +++ b/drivers/gpu/drm/bridge/display-connector.c
> @@ -24,7 +24,7 @@ struct display_connector {
> struct gpio_desc*hpd_gpio;
> int hpd_irq;
>
> - struct regulator*dp_pwr;
> + struct regulator*connector_pwr;
This makes sense, but I would shorten the name to just "pwr", "power" or
"supply". The field is part of the display_connector structure, so it
implicitly refers to the connector.
With or without that change,
Reviewed-by: Laurent Pinchart
> struct gpio_desc*ddc_en;
> };
>
> @@ -319,14 +319,14 @@ static int display_connector_probe(struct
> platform_device *pdev)
> if (type == DRM_MODE_CONNECTOR_DisplayPort) {
> int ret;
>
> - conn->dp_pwr = devm_regulator_get_optional(&pdev->dev,
> "dp-pwr");
> + conn->connector_pwr = devm_regulator_get_optional(&pdev->dev,
> "dp-pwr");
>
> - if (IS_ERR(conn->dp_pwr)) {
> - ret = PTR_ERR(conn->dp_pwr);
> + if (IS_ERR(conn->connector_pwr)) {
> + ret = PTR_ERR(conn->connector_pwr);
>
> switch (ret) {
> case -ENODEV:
> - conn->dp_pwr = NULL;
> + conn->connector_pwr = NULL;
> break;
>
> case -EPROBE_DEFER:
> @@ -338,8 +338,8 @@ static int display_connector_probe(struct platform_device
> *pdev)
> }
> }
>
> - if (conn->dp_pwr) {
> - ret = regulator_enable(conn->dp_pwr);
> + if (conn->connector_pwr) {
> + ret = regulator_enable(conn->connector_pwr);
> if (ret) {
> dev_err(&pdev->dev, "failed to enable DP PWR
> regulator: %d\n", ret);
> return ret;
> @@ -389,8 +389,8 @@ static int display_connector_remove(struct
> platform_device *pdev)
> if (conn->ddc_en)
> gpiod_set_value(conn->ddc_en, 0);
>
> - if (conn->dp_pwr)
> - regulator_disable(conn->dp_pwr);
> + if (conn->connector_pwr)
> + regulator_disable(conn->connector_pwr);
>
> drm_bridge_remove(&conn->bridge);
>
--
Regards,
Laurent Pinchart
Re: [Freedreno] 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: [Freedreno] [PATCH] dt-bindings: display: Drop unneeded quotes
Hi Rob, Thank you for the patch. On Fri, Mar 17, 2023 at 06:36:24PM -0500, Rob Herring wrote: > Cleanup bindings dropping unneeded quotes. Once all these are fixed, > checking for this can be enabled in yamllint. > > Signed-off-by: Rob Herring Reviewed-by: Laurent Pinchart > --- > .../bindings/auxdisplay/holtek,ht16k33.yaml| 2 +- > .../bindings/display/bridge/nxp,ptn3460.yaml | 2 +- > .../display/bridge/toshiba,tc358767.yaml | 2 +- > .../bindings/display/dp-aux-bus.yaml | 2 +- > .../display/mediatek/mediatek,hdmi.yaml| 2 +- > .../display/msm/dsi-controller-main.yaml | 8 > .../bindings/display/msm/dsi-phy-10nm.yaml | 2 +- > .../bindings/display/panel/ronbo,rb070d30.yaml | 2 +- > .../bindings/display/renesas,du.yaml | 4 ++-- > .../display/tegra/nvidia,tegra114-mipi.yaml| 2 +- > .../display/tegra/nvidia,tegra124-sor.yaml | 12 ++-- > .../display/tegra/nvidia,tegra186-dc.yaml | 4 ++-- > .../tegra/nvidia,tegra186-dsi-padctl.yaml | 2 +- > .../display/tegra/nvidia,tegra20-dsi.yaml | 12 ++-- > .../display/tegra/nvidia,tegra20-hdmi.yaml | 6 +++--- > .../bindings/display/ti/ti,am65x-dss.yaml | 2 +- > .../display/xylon,logicvc-display.yaml | 18 +- > 17 files changed, 42 insertions(+), 42 deletions(-) > > diff --git a/Documentation/devicetree/bindings/auxdisplay/holtek,ht16k33.yaml > b/Documentation/devicetree/bindings/auxdisplay/holtek,ht16k33.yaml > index fc4873deb76f..4f6ffb8182a9 100644 > --- a/Documentation/devicetree/bindings/auxdisplay/holtek,ht16k33.yaml > +++ b/Documentation/devicetree/bindings/auxdisplay/holtek,ht16k33.yaml > @@ -10,7 +10,7 @@ maintainers: >- Robin van der Gracht > > allOf: > - - $ref: "/schemas/input/matrix-keymap.yaml#" > + - $ref: /schemas/input/matrix-keymap.yaml# > > properties: >compatible: > diff --git > a/Documentation/devicetree/bindings/display/bridge/nxp,ptn3460.yaml > b/Documentation/devicetree/bindings/display/bridge/nxp,ptn3460.yaml > index 107dd138e6c6..cdeb67bc05f0 100644 > --- a/Documentation/devicetree/bindings/display/bridge/nxp,ptn3460.yaml > +++ b/Documentation/devicetree/bindings/display/bridge/nxp,ptn3460.yaml > @@ -18,7 +18,7 @@ properties: > maxItems: 1 > >edid-emulation: > -$ref: "/schemas/types.yaml#/definitions/uint32" > +$ref: /schemas/types.yaml#/definitions/uint32 > description: >The EDID emulation entry to use >Value Resolution Description > diff --git > a/Documentation/devicetree/bindings/display/bridge/toshiba,tc358767.yaml > b/Documentation/devicetree/bindings/display/bridge/toshiba,tc358767.yaml > index 140927884418..e1494b5007cb 100644 > --- a/Documentation/devicetree/bindings/display/bridge/toshiba,tc358767.yaml > +++ b/Documentation/devicetree/bindings/display/bridge/toshiba,tc358767.yaml > @@ -23,7 +23,7 @@ properties: > i2c address of the bridge, 0x68 or 0x0f, depending on bootstrap pins > >clock-names: > -const: "ref" > +const: ref > >clocks: > maxItems: 1 > diff --git a/Documentation/devicetree/bindings/display/dp-aux-bus.yaml > b/Documentation/devicetree/bindings/display/dp-aux-bus.yaml > index 5e4afe9f98fb..0ece7b01790b 100644 > --- a/Documentation/devicetree/bindings/display/dp-aux-bus.yaml > +++ b/Documentation/devicetree/bindings/display/dp-aux-bus.yaml > @@ -26,7 +26,7 @@ description: > > properties: >$nodename: > -const: "aux-bus" > +const: aux-bus > >panel: > $ref: panel/panel-common.yaml# > diff --git > a/Documentation/devicetree/bindings/display/mediatek/mediatek,hdmi.yaml > b/Documentation/devicetree/bindings/display/mediatek/mediatek,hdmi.yaml > index 8afdd67d6780..b90b6d18a828 100644 > --- a/Documentation/devicetree/bindings/display/mediatek/mediatek,hdmi.yaml > +++ b/Documentation/devicetree/bindings/display/mediatek/mediatek,hdmi.yaml > @@ -50,7 +50,7 @@ properties: >- const: hdmi > >mediatek,syscon-hdmi: > -$ref: '/schemas/types.yaml#/definitions/phandle-array' > +$ref: /schemas/types.yaml#/definitions/phandle-array > items: >- items: >- description: phandle to system configuration registers > diff --git > a/Documentation/devicetree/bindings/display/msm/dsi-controller-main.yaml > b/Documentation/devicetree/bindings/display/msm/dsi-controller-main.yaml > index e75a3efe4dac..2188d7c9b0bb 100644 > --- a/Documentation/devicetree/bindings/display/msm/dsi-controller-main.yaml > +++ b/Documentation/devicetree/bindings/display/msm/dsi-cont
Re: [Freedreno] [PATCH] drm: Use of_property_present() for testing DT property presence
Hi Rob,
Thank you for the patch.
On Fri, Mar 10, 2023 at 08:47:05AM -0600, Rob Herring wrote:
> It is preferred to use typed property access functions (i.e.
> of_property_read_ functions) rather than low-level
> of_get_property/of_find_property functions for reading properties. As
> part of this, convert of_get_property/of_find_property calls to the
> recently added of_property_present() helper when we just want to test
> for presence of a property and nothing more.
>
> Signed-off-by: Rob Herring
Reviewed-by: Laurent Pinchart
> ---
> drivers/gpu/drm/bridge/imx/imx8qxp-pixel-link.c | 2 +-
> drivers/gpu/drm/drm_mipi_dsi.c | 2 +-
> drivers/gpu/drm/msm/adreno/adreno_gpu.c | 2 +-
> drivers/gpu/drm/sun4i/sun4i_backend.c | 2 +-
> drivers/gpu/drm/sun4i/sun8i_mixer.c | 2 +-
> drivers/gpu/drm/vc4/vc4_hdmi.c | 2 +-
> 6 files changed, 6 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/gpu/drm/bridge/imx/imx8qxp-pixel-link.c
> b/drivers/gpu/drm/bridge/imx/imx8qxp-pixel-link.c
> index 9e5f2b4dc2e5..fab139b324af 100644
> --- a/drivers/gpu/drm/bridge/imx/imx8qxp-pixel-link.c
> +++ b/drivers/gpu/drm/bridge/imx/imx8qxp-pixel-link.c
> @@ -313,7 +313,7 @@ imx8qxp_pixel_link_find_next_bridge(struct
> imx8qxp_pixel_link *pl)
> }
>
> /* specially select the next bridge with companion PXL2DPI */
> - if (of_find_property(remote, "fsl,companion-pxl2dpi", NULL))
> + if (of_property_present(remote, "fsl,companion-pxl2dpi"))
> bridge_sel = ep_cnt;
>
> ep_cnt++;
> diff --git a/drivers/gpu/drm/drm_mipi_dsi.c b/drivers/gpu/drm/drm_mipi_dsi.c
> index b41aaf2bb9f1..7900a4707d7c 100644
> --- a/drivers/gpu/drm/drm_mipi_dsi.c
> +++ b/drivers/gpu/drm/drm_mipi_dsi.c
> @@ -329,7 +329,7 @@ int mipi_dsi_host_register(struct mipi_dsi_host *host)
>
> for_each_available_child_of_node(host->dev->of_node, node) {
> /* skip nodes without reg property */
> - if (!of_find_property(node, "reg", NULL))
> + if (!of_property_present(node, "reg"))
> continue;
> of_mipi_dsi_device_add(host, node);
> }
> diff --git a/drivers/gpu/drm/msm/adreno/adreno_gpu.c
> b/drivers/gpu/drm/msm/adreno/adreno_gpu.c
> index ce6b76c45b6f..2359dca80492 100644
> --- a/drivers/gpu/drm/msm/adreno/adreno_gpu.c
> +++ b/drivers/gpu/drm/msm/adreno/adreno_gpu.c
> @@ -964,7 +964,7 @@ static void adreno_get_pwrlevels(struct device *dev,
> gpu->fast_rate = 0;
>
> /* You down with OPP? */
> - if (!of_find_property(dev->of_node, "operating-points-v2", NULL))
> + if (!of_property_present(dev->of_node, "operating-points-v2"))
> ret = adreno_get_legacy_pwrlevels(dev);
> else {
> ret = devm_pm_opp_of_add_table(dev);
> diff --git a/drivers/gpu/drm/sun4i/sun4i_backend.c
> b/drivers/gpu/drm/sun4i/sun4i_backend.c
> index 38070fc261f3..b11dbd50d73e 100644
> --- a/drivers/gpu/drm/sun4i/sun4i_backend.c
> +++ b/drivers/gpu/drm/sun4i/sun4i_backend.c
> @@ -792,7 +792,7 @@ static int sun4i_backend_bind(struct device *dev, struct
> device *master,
> dev_set_drvdata(dev, backend);
> spin_lock_init(&backend->frontend_lock);
>
> - if (of_find_property(dev->of_node, "interconnects", NULL)) {
> + if (of_property_present(dev->of_node, "interconnects")) {
> /*
>* This assume we have the same DMA constraints for all our the
>* devices in our pipeline (all the backends, but also the
> diff --git a/drivers/gpu/drm/sun4i/sun8i_mixer.c
> b/drivers/gpu/drm/sun4i/sun8i_mixer.c
> index bafee05f6b24..11d5244a5aa5 100644
> --- a/drivers/gpu/drm/sun4i/sun8i_mixer.c
> +++ b/drivers/gpu/drm/sun4i/sun8i_mixer.c
> @@ -391,7 +391,7 @@ static int sun8i_mixer_bind(struct device *dev, struct
> device *master,
> mixer->engine.ops = &sun8i_engine_ops;
> mixer->engine.node = dev->of_node;
>
> - if (of_find_property(dev->of_node, "iommus", NULL)) {
> + if (of_property_present(dev->of_node, "iommus")) {
> /*
>* This assume we have the same DMA constraints for
>* all our the mixers in our pipeline. This sounds
> diff --git a/drivers/gpu/drm/vc4/vc4_hdmi.c b/drivers/gpu/drm/vc4/vc4_hdmi.c
> index ea22c9bf223a..bec1e0cdddb3 100644
> --- a/drivers/gpu/drm/vc4/vc4_hdmi.c
> +++ b/drivers/gpu/drm/vc4/vc4_hdmi.c
> @@ -3018,7 +3018,7 @@ static int vc4_hdmi_cec_init(struct vc4_hdmi *vc4_hdmi)
> struct device *dev = &pdev->dev;
> int ret;
>
> - if (!of_find_property(dev->of_node, "interrupts", NULL)) {
> + if (!of_property_present(dev->of_node, "interrupts")) {
> dev_warn(dev, "'interrupts' DT property is missing, no CEC\n");
> return 0;
> }
--
Regards,
Laurent Pinchart
Re: [Freedreno] [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, &conn_iter);
> + drm_for_each_connector_iter(connector, &conn_iter) {
> + const struct drm_connector_helper_funcs *funcs =
> + connector->helper_private;
> +
> + if (funcs && funcs->disable_hpd)
> + funcs->disable_hpd(connector);
> +
Re: [Freedreno] [RFC PATCH 0/3] Support for Solid Fill Planes
On Mon, Nov 07, 2022 at 09:37:08PM +0200, Ville Syrjälä wrote:
> On Fri, Oct 28, 2022 at 03:59:49PM -0700, Jessica Zhang wrote:
> > Introduce and add support for COLOR_FILL and COLOR_FILL_FORMAT
> > properties. When the color fill value is set, and the framebuffer is set
> > to NULL, memory fetch will be disabled.
>
> Thinking a bit more universally I wonder if there should be
> some kind of enum property:
>
> enum plane_pixel_source {
> FB,
> COLOR,
> LIVE_FOO,
> LIVE_BAR,
> ...
> }
That's something I could use on (older) Renesas hardware, where planes
can be fed with a live source. The issue there is that the live source
is a compositor with multiple inputs, handled through the V4L2 API. How
to synchronize the configuration of the compositor and the display
engine is an unsolved problem at the moment, but it could be solved
another day.
> > In addition, loosen the NULL FB checks within the atomic commit callstack
> > to allow a NULL FB when color_fill is nonzero and add FB checks in
> > methods where the FB was previously assumed to be non-NULL.
> >
> > Finally, have the DPU driver use drm_plane_state.color_fill and
> > drm_plane_state.color_fill_format instead of dpu_plane_state.color_fill,
> > and add extra checks in the DPU atomic commit callstack to account for a
> > NULL FB in cases where color_fill is set.
> >
> > Some drivers support hardware that have optimizations for solid fill
> > planes. This series aims to expose these capabilities to userspace as
> > some compositors have a solid fill flag (ex. SOLID_COLOR in the Android
> > hardware composer HAL) that can be set by apps like the Android Gears
> > app.
> >
> > Userspace can set the color_fill value by setting COLOR_FILL_FORMAT to a
> > DRM format, setting COLOR_FILL to a color fill value, and setting the
> > framebuffer to NULL.
>
> Is there some real reason for the format property? Ie. why not
> just do what was the plan for the crttc background color and
> specify the color in full 16bpc format and just pick as many
> msbs from that as the hw can use?
>
> > Jessica Zhang (3):
> > drm: Introduce color fill properties for drm plane
> > drm: Adjust atomic checks for solid fill color
> > drm/msm/dpu: Use color_fill property for DPU planes
> >
> > drivers/gpu/drm/drm_atomic.c | 68 ---
> > drivers/gpu/drm/drm_atomic_helper.c | 34 +++-
> > drivers/gpu/drm/drm_atomic_uapi.c | 8 +++
> > drivers/gpu/drm/drm_blend.c | 38 +
> > drivers/gpu/drm/drm_plane.c | 8 +--
> > drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c | 7 ++-
> > drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c | 66 ++++++----
> > include/drm/drm_atomic_helper.h | 5 +-
> > include/drm/drm_blend.h | 2 +
> > include/drm/drm_plane.h | 28 ++
> > 10 files changed, 188 insertions(+), 76 deletions(-)
--
Regards,
Laurent Pinchart
Re: [Freedreno] [RFC] drm/bridge: adv7533: remove dynamic lane switching from adv7533 bridge
Hi Dmitry, On Fri, Aug 26, 2022 at 04:52:12PM +0300, Dmitry Baryshkov wrote: > On 26/08/2022 14:55, Laurent Pinchart wrote: > > On Fri, Aug 26, 2022 at 01:17:43PM +0300, Dmitry Baryshkov wrote: > >> On 22/08/2022 19:31, Dmitry Baryshkov wrote: > >>> On 09/08/2022 22:40, Laurent Pinchart wrote: > >>>> On Mon, Aug 08, 2022 at 05:35:30PM -0700, Abhinav Kumar wrote: > >>>>> adv7533 bridge tries to dynamically switch lanes based on the > >>>>> mode by detaching and attaching the mipi dsi device. > >>>>> > >>>>> This approach is incorrect because as per the DSI spec the > >>>>> number of lanes is fixed at the time of system design or initial > >>>>> configuration and may not change dynamically. > >>>> > >>>> Is that really so ? The number of lanes connected on the board is > >>>> certainlyset at design time, but a lower number of lanes can be used at > >>>> runtime. It shouldn't change dynamically while the display is on, but it > >>>> could change at mode set time. > >>> > >>> I'm not sure if I interpreted the standard correctly, but I tended to > >>> have the same interpretation as Abhinav did. > >>> > >>> Anyway, even if we allow the drivers to switch the amount of lanes, this > >>> should not happen in the form of detach()/attach() cycle. The drivers > > > > Agreed. > > > >>> use mipi_dsi_attach() as way to signal the DSI hosts that the sink > >>> device is ready. Some of DSI hosts (including MSM one) would bind > >>> components from the attach callback. > >>> > >>> If we were to support dynamically changing the amount of lanes, I would > >>> ask for additional mipi_dsi API call telling the host to switch the > >>> amount of lanes. And note that this can open the can of worms. Different > >>> hosts might have different requirements here. For example for the MSM > >>> platform the amount of lanes is programmed during bridge_pre_enable > >>> chain call, so it is possible to just set the amount of lanes following > >>> the msm_dsi_device::lanes. Other hosts might have other requirements. > > > > Conceptually, I would expect the number of effective lanes to be > > selected at mode set time, because it has to be done while the output is > > disabled. > > There is one tightly coupled question. The dual-DSI (or bonded-DSI) > mode. Currently it is exposed as two independent DSI hosts. If we allow > changing the amount of DSI lanes at runtime, bonded DSI mode would > become complicated by fixing amount of lanes for each of outputs (or > switching them in tight loop). And then comes the question of switching > between single-DSI and bonded-DSI at runtime. Maybe we can leave dynamic selection of the number of lanes for dual-DSI out at this point ? I have no experienced with bonded DSI, is it typical to have to switch between single and bonded links at runtime (to be precise, at mode set time, not while the display is on) ? > > With the atomic API for bridges the .mode_set() operation is > > deprecated, so .pre_enable() sounds best, but there's a potential issue: > > the .pre_enable() operation is called from sink to source. It means that > > a DSI sink .pre_enable() operation would need to call a DSI host > > operation to set (or maybe negotiate instead of just setting a fixed > > value) the number of lanes first if it wants to control the sink through > > DCS at .pre_enable() time. We'd have to see how that fits. > > What is the fate of the patchset that implemented 'parent-first' opt-in > for the drm_bridge chains? It was supposed to solve this this kind of > issues. I'm asking because until it is merged some DSI hosts (e.g. the > msm dsi) turn on the power in .mode_set() to allow the pre_enable() > callbacks work when the DSI link is in LP11 mode. > > Back then I voted for the explicit mipi_dsi_power_on kind of calls, > which would allow the sink bridge to prepare for the DSI powerup (e.g. > by setting the amount of lanes), power up the DSI host, putting the link > into LP11 and after that communicate with the sink using the DSI data > lanes. A long time ago, I worked on converting the omapdrm driver to the DRM bridge API. It was using internal bridge and panel drivers with an API specific to omapdrm, and it was based on a similar principle: enabling or disabling an output went from the last component in the chain, which was the responsible for calling into its parent explicitly, with a bus-spec
Re: [Freedreno] [RFC] drm/bridge: adv7533: remove dynamic lane switching from adv7533 bridge
Hi Abhinav,
On Tue, Aug 09, 2022 at 02:47:32PM -0700, Abhinav Kumar wrote:
> On 8/9/2022 12:40 PM, Laurent Pinchart wrote:
> > On Mon, Aug 08, 2022 at 05:35:30PM -0700, Abhinav Kumar wrote:
> >> adv7533 bridge tries to dynamically switch lanes based on the
> >> mode by detaching and attaching the mipi dsi device.
> >>
> >> This approach is incorrect because as per the DSI spec the
> >> number of lanes is fixed at the time of system design or initial
> >> configuration and may not change dynamically.
> >
> > Is that really so ? The number of lanes connected on the board is
> > certainlyset at design time, but a lower number of lanes can be used at
> > runtime. It shouldn't change dynamically while the display is on, but it
> > could change at mode set time.
>
> So as per the spec it says this:
>
> "The number of Lanes used shall be a static parameter. It shall be fixed
> at the time of system design or initial configuration and may not change
> dynamically. Typically, the peripheral’s bandwidth requirement and its
> corresponding Lane configuration establishes the number of Lanes used in
> a system."
>
> But I do agree with you that this does not prohibit us from changing the
> lanes during mode_set time because display might have been off.
Yes, I would consider mode set time as "initial configuration".
> Although, I really did not see any other bridges doing it this way.
>
> At the same time, detach() and attach() cycle seems the incorrect way to
> do it here.
I fully agree.
> We did think of another approach of having a new mipi_dsi_op to
> reconfigure the host without the component_del()/component_add() because
> most of the host drivers also do component_del()/component_add() in
> detach()/attach().
Anything that avoids the usage of the component framework is likely a
good idea :-) I'd really like to see it go.
> But that would not work here either because this bridge is after the DSI
> controller's bridge in the chain.
>
> Hence DSI controller's modeset would happen earlier than this one.
With the atomic bridge API the .mode_set() operation is deprecated in
favour of the atomic version of the enable and pre-enable operations.
Pre-enable would likely be a good time to handle this.
> So even if we do have another op to reconfigure the host , this bridge's
> modeset would be too late to call that new op.
>
> It complicates things a bit, so we thought that not supporting dynamic
> lane switching would be the better way forward unless there is another
> suggestion on how to support this.
>
> >> In addition this method of dynamic switch of detaching and
> >> attaching the mipi dsi device also results in removing
> >> and adding the component which is not necessary.
> >
> > Yes, that doesn't look good, and the .mode_valid() operation is
> > definitely not the right point where to set the number of lanes.
>
> I didnt follow this. Did you mean mode_set() is not the right point to
> set the number of lanes?
Mode set time is conceptually the right point (but the .mode_set()
operation isn't, given the above), but .mode_valid() isn't.
.mode_valid() validates a mode, it should not affect the hardware
configuration in any way.
> So without this change, adv7533 changes the number of lanes during
> mode_set time followed by a detach/attach cycle.
>
> >> This approach is also prone to deadlocks. So for example, on the
> >> db410c whenever this path is executed with lockdep enabled,
> >> this results in a deadlock due to below ordering of locks.
> >>
> >> -> #1 (crtc_ww_class_acquire){+.+.}-{0:0}:
> >> lock_acquire+0x6c/0x90
> >> drm_modeset_acquire_init+0xf4/0x150
> >> drmm_mode_config_init+0x220/0x770
> >> msm_drm_bind+0x13c/0x654
> >> try_to_bring_up_aggregate_device+0x164/0x1d0
> >> __component_add+0xa8/0x174
> >> component_add+0x18/0x2c
> >> dsi_dev_attach+0x24/0x30
> >> dsi_host_attach+0x98/0x14c
> >> devm_mipi_dsi_attach+0x38/0xb0
> >> adv7533_attach_dsi+0x8c/0x110
> >> adv7511_probe+0x5a0/0x930
> >> i2c_device_probe+0x30c/0x350
> >> really_probe.part.0+0x9c/0x2b0
> >> __driver_probe_device+0x98/0x144
> >> driver_probe_device+0xac/0x14c
> >> __device_attach_driver+0xbc/0x124
> >> bus_for_each_drv+0x78/0xd0
> >> __device_attach+0xa8/0x1c0
> >> device_initial_probe+0x18/0x24
&
Re: [Freedreno] [RFC] drm/bridge: adv7533: remove dynamic lane switching from adv7533 bridge
Hello,
On Fri, Aug 26, 2022 at 01:17:43PM +0300, Dmitry Baryshkov wrote:
> On 22/08/2022 19:31, Dmitry Baryshkov wrote:
> > On 09/08/2022 22:40, Laurent Pinchart wrote:
> >> On Mon, Aug 08, 2022 at 05:35:30PM -0700, Abhinav Kumar wrote:
> >>> adv7533 bridge tries to dynamically switch lanes based on the
> >>> mode by detaching and attaching the mipi dsi device.
> >>>
> >>> This approach is incorrect because as per the DSI spec the
> >>> number of lanes is fixed at the time of system design or initial
> >>> configuration and may not change dynamically.
> >>
> >> Is that really so ? The number of lanes connected on the board is
> >> certainlyset at design time, but a lower number of lanes can be used at
> >> runtime. It shouldn't change dynamically while the display is on, but it
> >> could change at mode set time.
> >
> > I'm not sure if I interpreted the standard correctly, but I tended to
> > have the same interpretation as Abhinav did.
> >
> > Anyway, even if we allow the drivers to switch the amount of lanes, this
> > should not happen in the form of detach()/attach() cycle. The drivers
Agreed.
> > use mipi_dsi_attach() as way to signal the DSI hosts that the sink
> > device is ready. Some of DSI hosts (including MSM one) would bind
> > components from the attach callback.
> >
> > If we were to support dynamically changing the amount of lanes, I would
> > ask for additional mipi_dsi API call telling the host to switch the
> > amount of lanes. And note that this can open the can of worms. Different
> > hosts might have different requirements here. For example for the MSM
> > platform the amount of lanes is programmed during bridge_pre_enable
> > chain call, so it is possible to just set the amount of lanes following
> > the msm_dsi_device::lanes. Other hosts might have other requirements.
Conceptually, I would expect the number of effective lanes to be
selected at mode set time, because it has to be done while the output is
disabled. With the atomic API for bridges the .mode_set() operation is
deprecated, so .pre_enable() sounds best, but there's a potential issue:
the .pre_enable() operation is called from sink to source. It means that
a DSI sink .pre_enable() operation would need to call a DSI host
operation to set (or maybe negotiate instead of just setting a fixed
value) the number of lanes first if it wants to control the sink through
DCS at .pre_enable() time. We'd have to see how that fits.
> > Thus said I'd suggest accepting this patch and maybe working on the
> > API/support for the lane switching as a followup.
I don't have a personal need for the ADV7533 so I won't really complain
about any potential regression this may introduce (given that it fixes a
deadlock maybe things are completely broken already and nothing can
regress). I'd like to see this fixed though, doing it as a follow up is
too often a way to avoid doing it at all :-)
In any case, the commit message should be reworded to explain the
rationale and what needs to be done. Adding a TODO or FIXME comment in
the code would also help.
> Laurent, gracious ping for your response.
Done :-)
> >>> In addition this method of dynamic switch of detaching and
> >>> attaching the mipi dsi device also results in removing
> >>> and adding the component which is not necessary.
> >>
> >> Yes, that doesn't look good, and the .mode_valid() operation is
> >> definitely not the right point where to set the number of lanes.
> >
> > .mode_set()?
> >
> >>> This approach is also prone to deadlocks. So for example, on the
> >>> db410c whenever this path is executed with lockdep enabled,
> >>> this results in a deadlock due to below ordering of locks.
> >
> > Even without the deadlock, we are pulling the whole DRM device from
> > beneath the DSI panel by unbinding all the components. This is not going
> > to work correctly.
> >
> >>>
> >>> -> #1 (crtc_ww_class_acquire){+.+.}-{0:0}:
> >>> lock_acquire+0x6c/0x90
> >>> drm_modeset_acquire_init+0xf4/0x150
> >>> drmm_mode_config_init+0x220/0x770
> >>> msm_drm_bind+0x13c/0x654
> >>> try_to_bring_up_aggregate_device+0x164/0x1d0
> >>> __component_add+0xa8/0x174
> >>> component_add+0x18/0x2c
> >>> dsi_dev_attach+0x24/0x30
> >>> dsi_host_attach+0x98/0x14c
> >>> devm_mipi_dsi_attach+0x38/0xb0
> >>>
Re: [Freedreno] [PATCH 5/5] dt-bindings: display: drop minItems equal to maxItems
Hi Krzysztof, Thank you for the patch. On Thu, Aug 25, 2022 at 02:33:34PM +0300, Krzysztof Kozlowski wrote: > minItems, if missing, are implicitly equal to maxItems, so drop > redundant piece to reduce size of code. > > Signed-off-by: Krzysztof Kozlowski Reviewed-by: Laurent Pinchart > --- > Documentation/devicetree/bindings/display/bridge/fsl,ldb.yaml | 1 - > .../devicetree/bindings/display/msm/dsi-controller-main.yaml| 2 -- > Documentation/devicetree/bindings/display/msm/dsi-phy-10nm.yaml | 2 -- > .../bindings/display/samsung/samsung,exynos5433-decon.yaml | 2 -- > .../bindings/display/samsung/samsung,exynos5433-mic.yaml| 1 - > .../bindings/display/samsung/samsung,exynos7-decon.yaml | 1 - > .../devicetree/bindings/display/samsung/samsung,fimd.yaml | 1 - > .../devicetree/bindings/display/tegra/nvidia,tegra20-gr3d.yaml | 1 - > .../devicetree/bindings/display/tegra/nvidia,tegra20-mpe.yaml | 2 -- > 9 files changed, 13 deletions(-) > > diff --git a/Documentation/devicetree/bindings/display/bridge/fsl,ldb.yaml > b/Documentation/devicetree/bindings/display/bridge/fsl,ldb.yaml > index 2ebaa43eb62e..b19be0804abe 100644 > --- a/Documentation/devicetree/bindings/display/bridge/fsl,ldb.yaml > +++ b/Documentation/devicetree/bindings/display/bridge/fsl,ldb.yaml > @@ -25,7 +25,6 @@ properties: > const: ldb > >reg: > -minItems: 2 > maxItems: 2 > >reg-names: > diff --git > a/Documentation/devicetree/bindings/display/msm/dsi-controller-main.yaml > b/Documentation/devicetree/bindings/display/msm/dsi-controller-main.yaml > index 880bfe930830..3b609c19e0bc 100644 > --- a/Documentation/devicetree/bindings/display/msm/dsi-controller-main.yaml > +++ b/Documentation/devicetree/bindings/display/msm/dsi-controller-main.yaml > @@ -66,13 +66,11 @@ properties: >2 DSI links. > >assigned-clocks: > -minItems: 2 > maxItems: 2 > description: | >Parents of "byte" and "pixel" for the given platform. > >assigned-clock-parents: > -minItems: 2 > maxItems: 2 > description: | >The Byte clock and Pixel clock PLL outputs provided by a DSI PHY block. > diff --git a/Documentation/devicetree/bindings/display/msm/dsi-phy-10nm.yaml > b/Documentation/devicetree/bindings/display/msm/dsi-phy-10nm.yaml > index 716f921e3532..d9ad8b659f58 100644 > --- a/Documentation/devicetree/bindings/display/msm/dsi-phy-10nm.yaml > +++ b/Documentation/devicetree/bindings/display/msm/dsi-phy-10nm.yaml > @@ -37,7 +37,6 @@ properties: > >qcom,phy-rescode-offset-top: > $ref: /schemas/types.yaml#/definitions/int8-array > -minItems: 5 > maxItems: 5 > description: >Integer array of offset for pull-up legs rescode for all five lanes. > @@ -49,7 +48,6 @@ properties: > >qcom,phy-rescode-offset-bot: > $ref: /schemas/types.yaml#/definitions/int8-array > -minItems: 5 > maxItems: 5 > description: >Integer array of offset for pull-down legs rescode for all five lanes. > diff --git > a/Documentation/devicetree/bindings/display/samsung/samsung,exynos5433-decon.yaml > > b/Documentation/devicetree/bindings/display/samsung/samsung,exynos5433-decon.yaml > index 921bfe925cd6..6380eeebb073 100644 > --- > a/Documentation/devicetree/bindings/display/samsung/samsung,exynos5433-decon.yaml > +++ > b/Documentation/devicetree/bindings/display/samsung/samsung,exynos5433-decon.yaml > @@ -24,7 +24,6 @@ properties: >- samsung,exynos5433-decon-tv > >clocks: > -minItems: 11 > maxItems: 11 > >clock-names: > @@ -59,7 +58,6 @@ properties: >- const: te > >iommus: > -minItems: 2 > maxItems: 2 > >iommu-names: > diff --git > a/Documentation/devicetree/bindings/display/samsung/samsung,exynos5433-mic.yaml > > b/Documentation/devicetree/bindings/display/samsung/samsung,exynos5433-mic.yaml > index 7d405f2febcd..26e5017737a3 100644 > --- > a/Documentation/devicetree/bindings/display/samsung/samsung,exynos5433-mic.yaml > +++ > b/Documentation/devicetree/bindings/display/samsung/samsung,exynos5433-mic.yaml > @@ -24,7 +24,6 @@ properties: > const: samsung,exynos5433-mic > >clocks: > -minItems: 2 > maxItems: 2 > >clock-names: > diff --git > a/Documentation/devicetree/bindings/display/samsung/samsung,exynos7-decon.yaml > > b/Documentation/devicetree/bindings/display/samsung/samsung,exynos7-decon.yaml > index 969bd8c563a5..c06f306e8d14 100644 > --- > a/Documentation/devicetree/bindings/display/samsung/samsung,exynos7-decon.yaml > +++ >
Re: [Freedreno] [PATCH 4/5] dt-bindings: crypto: drop minItems equal to maxItems
Hi Krzysztof, Thank you for the patch. On Thu, Aug 25, 2022 at 02:33:33PM +0300, Krzysztof Kozlowski wrote: > minItems, if missing, are implicitly equal to maxItems, so drop > redundant piece to reduce size of code. > > Signed-off-by: Krzysztof Kozlowski Reviewed-by: Laurent Pinchart > --- > Documentation/devicetree/bindings/crypto/samsung-slimsss.yaml | 1 - > 1 file changed, 1 deletion(-) > > diff --git a/Documentation/devicetree/bindings/crypto/samsung-slimsss.yaml > b/Documentation/devicetree/bindings/crypto/samsung-slimsss.yaml > index 676950bb7b37..5b31891c97fe 100644 > --- a/Documentation/devicetree/bindings/crypto/samsung-slimsss.yaml > +++ b/Documentation/devicetree/bindings/crypto/samsung-slimsss.yaml > @@ -24,7 +24,6 @@ properties: > maxItems: 1 > >clocks: > -minItems: 2 > maxItems: 2 > >clock-names: -- Regards, Laurent Pinchart
Re: [Freedreno] [PATCH 3/5] dt-bindings: clock: drop minItems equal to maxItems
Hi Krzysztof, Thank you for the patch. On Thu, Aug 25, 2022 at 02:33:32PM +0300, Krzysztof Kozlowski wrote: > minItems, if missing, are implicitly equal to maxItems, so drop > redundant piece to reduce size of code. > > Signed-off-by: Krzysztof Kozlowski Reviewed-by: Laurent Pinchart > --- > Documentation/devicetree/bindings/clock/cirrus,cs2000-cp.yaml | 1 - > .../devicetree/bindings/clock/renesas,rcar-usb2-clock-sel.yaml | 2 -- > Documentation/devicetree/bindings/clock/samsung,s2mps11.yaml| 1 - > 3 files changed, 4 deletions(-) > > diff --git a/Documentation/devicetree/bindings/clock/cirrus,cs2000-cp.yaml > b/Documentation/devicetree/bindings/clock/cirrus,cs2000-cp.yaml > index 0abd6ba82dfd..82836086cac1 100644 > --- a/Documentation/devicetree/bindings/clock/cirrus,cs2000-cp.yaml > +++ b/Documentation/devicetree/bindings/clock/cirrus,cs2000-cp.yaml > @@ -23,7 +23,6 @@ properties: >clocks: > description: >Common clock binding for CLK_IN, XTI/REF_CLK > -minItems: 2 > maxItems: 2 > >clock-names: > diff --git > a/Documentation/devicetree/bindings/clock/renesas,rcar-usb2-clock-sel.yaml > b/Documentation/devicetree/bindings/clock/renesas,rcar-usb2-clock-sel.yaml > index 6eaabb4d82ec..81f09df7147e 100644 > --- a/Documentation/devicetree/bindings/clock/renesas,rcar-usb2-clock-sel.yaml > +++ b/Documentation/devicetree/bindings/clock/renesas,rcar-usb2-clock-sel.yaml > @@ -47,7 +47,6 @@ properties: > maxItems: 1 > >clocks: > -minItems: 4 > maxItems: 4 > >clock-names: > @@ -64,7 +63,6 @@ properties: > maxItems: 1 > >resets: > -minItems: 2 > maxItems: 2 > >reset-names: > diff --git a/Documentation/devicetree/bindings/clock/samsung,s2mps11.yaml > b/Documentation/devicetree/bindings/clock/samsung,s2mps11.yaml > index 9248bfc16d48..d5296e6053a1 100644 > --- a/Documentation/devicetree/bindings/clock/samsung,s2mps11.yaml > +++ b/Documentation/devicetree/bindings/clock/samsung,s2mps11.yaml > @@ -34,7 +34,6 @@ properties: > const: 1 > >clock-output-names: > -minItems: 3 > maxItems: 3 > description: Names for AP, CP and BT clocks. > -- Regards, Laurent Pinchart
Re: [Freedreno] [PATCH 2/5] dt-bindings: ata: drop minItems equal to maxItems
Hi Krzysztof, Thank you for the patch. On Thu, Aug 25, 2022 at 02:33:31PM +0300, Krzysztof Kozlowski wrote: > minItems, if missing, are implicitly equal to maxItems, so drop > redundant piece to reduce size of code. > > Signed-off-by: Krzysztof Kozlowski Reviewed-by: Laurent Pinchart > --- > Documentation/devicetree/bindings/ata/brcm,sata-brcm.yaml | 1 - > .../devicetree/bindings/ata/cortina,gemini-sata-bridge.yaml | 2 -- > Documentation/devicetree/bindings/ata/sata_highbank.yaml| 1 - > 3 files changed, 4 deletions(-) > > diff --git a/Documentation/devicetree/bindings/ata/brcm,sata-brcm.yaml > b/Documentation/devicetree/bindings/ata/brcm,sata-brcm.yaml > index 235a93ac86b0..3766cc80cb17 100644 > --- a/Documentation/devicetree/bindings/ata/brcm,sata-brcm.yaml > +++ b/Documentation/devicetree/bindings/ata/brcm,sata-brcm.yaml > @@ -30,7 +30,6 @@ properties: >- const: brcm,bcm-nsp-ahci > >reg: > -minItems: 2 > maxItems: 2 > >reg-names: > diff --git > a/Documentation/devicetree/bindings/ata/cortina,gemini-sata-bridge.yaml > b/Documentation/devicetree/bindings/ata/cortina,gemini-sata-bridge.yaml > index 21a90975593b..529093666508 100644 > --- a/Documentation/devicetree/bindings/ata/cortina,gemini-sata-bridge.yaml > +++ b/Documentation/devicetree/bindings/ata/cortina,gemini-sata-bridge.yaml > @@ -22,7 +22,6 @@ properties: > maxItems: 1 > >resets: > -minItems: 2 > maxItems: 2 > description: phandles to the reset lines for both SATA bridges > > @@ -32,7 +31,6 @@ properties: >- const: sata1 > >clocks: > -minItems: 2 > maxItems: 2 > description: phandles to the compulsory peripheral clocks > > diff --git a/Documentation/devicetree/bindings/ata/sata_highbank.yaml > b/Documentation/devicetree/bindings/ata/sata_highbank.yaml > index 49679b58041c..f23f26a8f21c 100644 > --- a/Documentation/devicetree/bindings/ata/sata_highbank.yaml > +++ b/Documentation/devicetree/bindings/ata/sata_highbank.yaml > @@ -52,7 +52,6 @@ properties: > minItems: 1 > maxItems: 8 > items: > - minItems: 2 >maxItems: 2 > >calxeda,tx-atten: -- Regards, Laurent Pinchart
Re: [Freedreno] [PATCH 1/5] dt-bindings: socionext, uniphier-system-cache: drop minItems equal to maxItems
Hi Krzysztof, Thank you for the patch. On Thu, Aug 25, 2022 at 02:33:30PM +0300, Krzysztof Kozlowski wrote: > minItems, if missing, are implicitly equal to maxItems, so drop > redundant piece to reduce size of code. > > Signed-off-by: Krzysztof Kozlowski Reviewed-by: Laurent Pinchart > --- > .../bindings/arm/socionext/socionext,uniphier-system-cache.yaml | 1 - > 1 file changed, 1 deletion(-) > > diff --git > a/Documentation/devicetree/bindings/arm/socionext/socionext,uniphier-system-cache.yaml > > b/Documentation/devicetree/bindings/arm/socionext/socionext,uniphier-system-cache.yaml > index 7ca5375f278f..6096c082d56d 100644 > --- > a/Documentation/devicetree/bindings/arm/socionext/socionext,uniphier-system-cache.yaml > +++ > b/Documentation/devicetree/bindings/arm/socionext/socionext,uniphier-system-cache.yaml > @@ -22,7 +22,6 @@ properties: > description: | >should contain 3 regions: control register, revision register, >operation register, in this order. > -minItems: 3 > maxItems: 3 > >interrupts: -- Regards, Laurent Pinchart
Re: [Freedreno] [PATCH] dt-bindings: display: Add missing (unevaluated|additional)Properties on child nodes
Hi Rob, Thank you for the patch. On Tue, Aug 23, 2022 at 09:56:42AM -0500, Rob Herring wrote: > In order to ensure only documented properties are present, node schemas > must have unevaluatedProperties or additionalProperties set to false > (typically). > > Signed-off-by: Rob Herring Reviewed-by: Laurent Pinchart > --- > Documentation/devicetree/bindings/display/arm,komeda.yaml| 1 + > Documentation/devicetree/bindings/display/bridge/lvds-codec.yaml | 1 + > Documentation/devicetree/bindings/display/msm/gpu.yaml | 1 + > .../bindings/display/samsung/samsung,exynos7-decon.yaml | 1 + > .../devicetree/bindings/display/samsung/samsung,fimd.yaml| 1 + > 5 files changed, 5 insertions(+) > > diff --git a/Documentation/devicetree/bindings/display/arm,komeda.yaml > b/Documentation/devicetree/bindings/display/arm,komeda.yaml > index 9f4aade97f10..3ad3eef89ca8 100644 > --- a/Documentation/devicetree/bindings/display/arm,komeda.yaml > +++ b/Documentation/devicetree/bindings/display/arm,komeda.yaml > @@ -58,6 +58,7 @@ properties: > patternProperties: >'^pipeline@[01]$': > type: object > +additionalProperties: false > description: >clocks > > diff --git a/Documentation/devicetree/bindings/display/bridge/lvds-codec.yaml > b/Documentation/devicetree/bindings/display/bridge/lvds-codec.yaml > index 3a8614e0f627..84aafcbf0919 100644 > --- a/Documentation/devicetree/bindings/display/bridge/lvds-codec.yaml > +++ b/Documentation/devicetree/bindings/display/bridge/lvds-codec.yaml > @@ -51,6 +51,7 @@ properties: > properties: >port@0: > $ref: /schemas/graph.yaml#/$defs/port-base > +unevaluatedProperties: false > description: | >For LVDS encoders, port 0 is the parallel input >For LVDS decoders, port 0 is the LVDS input > diff --git a/Documentation/devicetree/bindings/display/msm/gpu.yaml > b/Documentation/devicetree/bindings/display/msm/gpu.yaml > index 3397bc31d087..0179c816fa6d 100644 > --- a/Documentation/devicetree/bindings/display/msm/gpu.yaml > +++ b/Documentation/devicetree/bindings/display/msm/gpu.yaml > @@ -81,6 +81,7 @@ properties: > >zap-shader: > type: object > +additionalProperties: false > description: | >For a5xx and a6xx devices this node contains a memory-region that >points to reserved memory to store the zap shader that can be used to > diff --git > a/Documentation/devicetree/bindings/display/samsung/samsung,exynos7-decon.yaml > > b/Documentation/devicetree/bindings/display/samsung/samsung,exynos7-decon.yaml > index 969bd8c563a5..dec1c9058876 100644 > --- > a/Documentation/devicetree/bindings/display/samsung/samsung,exynos7-decon.yaml > +++ > b/Documentation/devicetree/bindings/display/samsung/samsung,exynos7-decon.yaml > @@ -37,6 +37,7 @@ properties: > >i80-if-timings: > type: object > +additionalProperties: false > description: timing configuration for lcd i80 interface support > properties: >cs-setup: > diff --git > a/Documentation/devicetree/bindings/display/samsung/samsung,fimd.yaml > b/Documentation/devicetree/bindings/display/samsung/samsung,fimd.yaml > index 5d5cc220f78a..7593938601bb 100644 > --- a/Documentation/devicetree/bindings/display/samsung/samsung,fimd.yaml > +++ b/Documentation/devicetree/bindings/display/samsung/samsung,fimd.yaml > @@ -40,6 +40,7 @@ properties: > >i80-if-timings: > type: object > +additionalProperties: false > description: | >Timing configuration for lcd i80 interface support. >The parameters are defined as:: -- Regards, Laurent Pinchart
Re: [Freedreno] [RFC] drm/bridge: adv7533: remove dynamic lane switching from adv7533 bridge
> -void adv7533_mode_set(struct adv7511 *adv, const struct drm_display_mode
> *mode);
> +enum drm_mode_status adv7533_mode_valid(struct adv7511 *adv,
> + const struct drm_display_mode *mode);
> int adv7533_patch_registers(struct adv7511 *adv);
> int adv7533_patch_cec_registers(struct adv7511 *adv);
> int adv7533_attach_dsi(struct adv7511 *adv);
> diff --git a/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c
> b/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c
> index 5bb9300040dd..1115ef9be83c 100644
> --- a/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c
> +++ b/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c
> @@ -697,7 +697,7 @@ adv7511_detect(struct adv7511 *adv7511, struct
> drm_connector *connector)
> }
>
> static enum drm_mode_status adv7511_mode_valid(struct adv7511 *adv7511,
> - struct drm_display_mode *mode)
> + const struct drm_display_mode *mode)
> {
> if (mode->clock > 165000)
> return MODE_CLOCK_HIGH;
> @@ -791,9 +791,6 @@ static void adv7511_mode_set(struct adv7511 *adv7511,
> regmap_update_bits(adv7511->regmap, 0x17,
> 0x60, (vsync_polarity << 6) | (hsync_polarity << 5));
>
> - if (adv7511->type == ADV7533 || adv7511->type == ADV7535)
> - adv7533_mode_set(adv7511, adj_mode);
> -
> drm_mode_copy(&adv7511->curr_mode, adj_mode);
>
> /*
> @@ -913,6 +910,18 @@ static void adv7511_bridge_mode_set(struct drm_bridge
> *bridge,
> adv7511_mode_set(adv, mode, adj_mode);
> }
>
> +static enum drm_mode_status adv7511_bridge_mode_valid(struct drm_bridge
> *bridge,
> + const struct drm_display_info *info,
> + const struct drm_display_mode *mode)
> +{
> + struct adv7511 *adv = bridge_to_adv7511(bridge);
> +
> + if (adv->type == ADV7533 || adv->type == ADV7535)
> + return adv7533_mode_valid(adv, mode);
> + else
> + return adv7511_mode_valid(adv, mode);
> +}
> +
> static int adv7511_bridge_attach(struct drm_bridge *bridge,
>enum drm_bridge_attach_flags flags)
> {
> @@ -960,6 +969,7 @@ static const struct drm_bridge_funcs adv7511_bridge_funcs
> = {
> .enable = adv7511_bridge_enable,
> .disable = adv7511_bridge_disable,
> .mode_set = adv7511_bridge_mode_set,
> + .mode_valid = adv7511_bridge_mode_valid,
> .attach = adv7511_bridge_attach,
> .detect = adv7511_bridge_detect,
> .get_edid = adv7511_bridge_get_edid,
> diff --git a/drivers/gpu/drm/bridge/adv7511/adv7533.c
> b/drivers/gpu/drm/bridge/adv7511/adv7533.c
> index ef6270806d1d..4a6d45edf431 100644
> --- a/drivers/gpu/drm/bridge/adv7511/adv7533.c
> +++ b/drivers/gpu/drm/bridge/adv7511/adv7533.c
> @@ -100,26 +100,27 @@ void adv7533_dsi_power_off(struct adv7511 *adv)
> regmap_write(adv->regmap_cec, 0x27, 0x0b);
> }
>
> -void adv7533_mode_set(struct adv7511 *adv, const struct drm_display_mode
> *mode)
> +enum drm_mode_status adv7533_mode_valid(struct adv7511 *adv,
> + const struct drm_display_mode *mode)
> {
> + int lanes;
> struct mipi_dsi_device *dsi = adv->dsi;
> - int lanes, ret;
> -
> - if (adv->num_dsi_lanes != 4)
> - return;
>
> if (mode->clock > 8)
> lanes = 4;
> else
> lanes = 3;
>
> - if (lanes != dsi->lanes) {
> - mipi_dsi_detach(dsi);
> - dsi->lanes = lanes;
> - ret = mipi_dsi_attach(dsi);
> - if (ret)
> - dev_err(&dsi->dev, "failed to change host lanes\n");
> - }
> + /*
> + * number of lanes cannot be changed after initialization
> + * as per section 6.1 of the DSI specification. Hence filter
> + * out the modes which shall need different number of lanes
> + * than what was configured in the device tree.
> + */
> + if (lanes != dsi->lanes)
> + return MODE_BAD;
> +
> + return MODE_OK;
> }
>
> int adv7533_patch_registers(struct adv7511 *adv)
--
Regards,
Laurent Pinchart
Re: [Freedreno] [RFC PATCH 2/3] drm/bridge: ti-sn65dsi86: fetch bpc using drm_atomic_state
Hi Dmitry,
Thank you for the patch.
On Sun, Jul 10, 2022 at 09:45:35PM +0300, Dmitry Baryshkov wrote:
> Rather than reading the pdata->connector directly, fetch the connector
> using drm_atomic_state. This allows us to make pdata->connector optional
> (and thus supporting DRM_BRIDGE_ATTACH_NO_CONNECTOR).
>
> Signed-off-by: Dmitry Baryshkov
> ---
> drivers/gpu/drm/bridge/ti-sn65dsi86.c | 20 ++--
> 1 file changed, 14 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/gpu/drm/bridge/ti-sn65dsi86.c
> b/drivers/gpu/drm/bridge/ti-sn65dsi86.c
> index 01171547f638..df08207d6223 100644
> --- a/drivers/gpu/drm/bridge/ti-sn65dsi86.c
> +++ b/drivers/gpu/drm/bridge/ti-sn65dsi86.c
> @@ -779,9 +779,9 @@ static void ti_sn_bridge_set_dsi_rate(struct ti_sn65dsi86
> *pdata)
> regmap_write(pdata->regmap, SN_DSIA_CLK_FREQ_REG, val);
> }
>
> -static unsigned int ti_sn_bridge_get_bpp(struct ti_sn65dsi86 *pdata)
> +static unsigned int ti_sn_bridge_get_bpp(struct drm_connector *connector)
> {
> - if (pdata->connector->display_info.bpc <= 6)
> + if (connector->display_info.bpc <= 6)
> return 18;
> else
> return 24;
> @@ -796,7 +796,7 @@ static const unsigned int ti_sn_bridge_dp_rate_lut[] = {
> 0, 1620, 2160, 2430, 2700, 3240, 4320, 5400
> };
>
> -static int ti_sn_bridge_calc_min_dp_rate_idx(struct ti_sn65dsi86 *pdata)
> +static int ti_sn_bridge_calc_min_dp_rate_idx(struct ti_sn65dsi86 *pdata,
> unsigned int bpp)
> {
> unsigned int bit_rate_khz, dp_rate_mhz;
> unsigned int i;
> @@ -804,7 +804,7 @@ static int ti_sn_bridge_calc_min_dp_rate_idx(struct
> ti_sn65dsi86 *pdata)
> &pdata->bridge.encoder->crtc->state->adjusted_mode;
>
> /* Calculate minimum bit rate based on our pixel clock. */
> - bit_rate_khz = mode->clock * ti_sn_bridge_get_bpp(pdata);
> + bit_rate_khz = mode->clock * bpp;
>
> /* Calculate minimum DP data rate, taking 80% as per DP spec */
> dp_rate_mhz = DIV_ROUND_UP(bit_rate_khz * DP_CLK_FUDGE_NUM,
> @@ -1016,12 +1016,19 @@ static void ti_sn_bridge_atomic_enable(struct
> drm_bridge *bridge,
> struct drm_bridge_state
> *old_bridge_state)
> {
> struct ti_sn65dsi86 *pdata = bridge_to_ti_sn65dsi86(bridge);
> + struct drm_connector *connector;
> const char *last_err_str = "No supported DP rate";
> unsigned int valid_rates;
> int dp_rate_idx;
> unsigned int val;
> int ret = -EINVAL;
> int max_dp_lanes;
> + unsigned int bpp;
> +
> + connector =
> drm_atomic_get_new_connector_for_encoder(old_bridge_state->base.state,
> + bridge->encoder);
> + if (!connector)
As Sam mentioned, a dev_err() would be good here if you think this can
happen. If there's no risk that connector will be null, you could drop
the check.
> + return;
>
> max_dp_lanes = ti_sn_get_max_lanes(pdata);
> pdata->dp_lanes = min(pdata->dp_lanes, max_dp_lanes);
> @@ -1047,8 +1054,9 @@ static void ti_sn_bridge_atomic_enable(struct
> drm_bridge *bridge,
> drm_dp_dpcd_writeb(&pdata->aux, DP_EDP_CONFIGURATION_SET,
> DP_ALTERNATE_SCRAMBLER_RESET_ENABLE);
>
> + bpp = ti_sn_bridge_get_bpp(connector);
> /* Set the DP output format (18 bpp or 24 bpp) */
> - val = (ti_sn_bridge_get_bpp(pdata) == 18) ? BPP_18_RGB : 0;
> + val = (bpp == 18) ? BPP_18_RGB : 0;
You can drop the parentheses.
Reviewed-by: Laurent Pinchart
> regmap_update_bits(pdata->regmap, SN_DATA_FORMAT_REG, BPP_18_RGB, val);
>
> /* DP lane config */
> @@ -1059,7 +1067,7 @@ static void ti_sn_bridge_atomic_enable(struct
> drm_bridge *bridge,
> valid_rates = ti_sn_bridge_read_valid_rates(pdata);
>
> /* Train until we run out of rates */
> - for (dp_rate_idx = ti_sn_bridge_calc_min_dp_rate_idx(pdata);
> + for (dp_rate_idx = ti_sn_bridge_calc_min_dp_rate_idx(pdata, bpp);
>dp_rate_idx < ARRAY_SIZE(ti_sn_bridge_dp_rate_lut);
>dp_rate_idx++) {
> if (!(valid_rates & BIT(dp_rate_idx)))
--
Regards,
Laurent Pinchart
Re: [Freedreno] [RFC PATCH 3/3] drm/bridge: ti-sn65dsi86: support DRM_BRIDGE_ATTACH_NO_CONNECTOR
Hi Dmitry,
Thank you for the patch.
On Sun, Jul 10, 2022 at 09:45:36PM +0300, Dmitry Baryshkov wrote:
> Now as the driver does not depend on pdata->connector, add support for
> attaching the bridge with DRM_BRIDGE_ATTACH_NO_CONNECTOR.
>
> Signed-off-by: Dmitry Baryshkov
> ---
> drivers/gpu/drm/bridge/ti-sn65dsi86.c | 15 +--
> 1 file changed, 5 insertions(+), 10 deletions(-)
>
> diff --git a/drivers/gpu/drm/bridge/ti-sn65dsi86.c
> b/drivers/gpu/drm/bridge/ti-sn65dsi86.c
> index df08207d6223..9bca4615f71b 100644
> --- a/drivers/gpu/drm/bridge/ti-sn65dsi86.c
> +++ b/drivers/gpu/drm/bridge/ti-sn65dsi86.c
> @@ -698,11 +698,6 @@ static int ti_sn_bridge_attach(struct drm_bridge *bridge,
> struct ti_sn65dsi86 *pdata = bridge_to_ti_sn65dsi86(bridge);
> int ret;
>
> - if (flags & DRM_BRIDGE_ATTACH_NO_CONNECTOR) {
> - DRM_ERROR("Fix bridge driver to make connector optional!");
> - return -EINVAL;
> - }
> -
> pdata->aux.drm_dev = bridge->dev;
> ret = drm_dp_aux_register(&pdata->aux);
> if (ret < 0) {
> @@ -710,15 +705,15 @@ static int ti_sn_bridge_attach(struct drm_bridge
> *bridge,
> return ret;
> }
>
> - /* We never want the next bridge to *also* create a connector: */
> - flags |= DRM_BRIDGE_ATTACH_NO_CONNECTOR;
> -
> - /* Attach the next bridge */
> + /* Attach the next bridge, We never want the next bridge to *also*
> create a connector. */
s/bridge,/bridge./
I also would have wrapped this line.
Reviewed-by: Laurent Pinchart
> ret = drm_bridge_attach(bridge->encoder, pdata->next_bridge,
> - &pdata->bridge, flags);
> + &pdata->bridge, flags |
> DRM_BRIDGE_ATTACH_NO_CONNECTOR);
> if (ret < 0)
> goto err_initted_aux;
>
> + if (flags & DRM_BRIDGE_ATTACH_NO_CONNECTOR)
> + return 0;
> +
> pdata->connector = drm_bridge_connector_init(pdata->bridge.dev,
>pdata->bridge.encoder);
> if (IS_ERR(pdata->connector)) {
--
Regards,
Laurent Pinchart
Re: [Freedreno] [PATCH v5 15/19] drm/msm/dpu: initialize dpu encoder and connector for writeback
On Tue, Apr 26, 2022 at 05:11:41AM +0300, Dmitry Baryshkov wrote:
> On 26/04/2022 03:32, Laurent Pinchart wrote:
> > On Sun, Apr 24, 2022 at 05:32:06PM -0700, Abhinav Kumar wrote:
> >> Initialize dpu encoder and connector for writeback if the
> >> target supports it in the catalog.
> >>
> >> changes in v2:
> >>- start initialing the encoder for writeback since we
> >>have migrated to using drm_writeback_connector_init_with_encoder()
> >>- instead of checking for WB_2 inside _dpu_kms_initialize_writeback
> >>call it only when its WB_2
> >>- rebase on tip of msm-next and remove usage of priv->encoders
> >>
> >> changes in v3:
> >>- none
> >>
> >> changes in v4:
> >>- fix copyright years order
> >>
> >> Signed-off-by: Abhinav Kumar
> >> Reviewed-by: Dmitry Baryshkov
> >> ---
> >> drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c | 27 +
> >> drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c | 61
> >> -
> >> 2 files changed, 80 insertions(+), 8 deletions(-)
> >>
> >> diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
> >> b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
> >> index 24870eb..2d79002 100644
> >> --- a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
> >> +++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
> >> @@ -2102,7 +2102,7 @@ static void dpu_encoder_early_unregister(struct
> >> drm_encoder *encoder)
> >> }
> >>
> >> static int dpu_encoder_virt_add_phys_encs(
> >> - u32 display_caps,
> >> + struct msm_display_info *disp_info,
> >>struct dpu_encoder_virt *dpu_enc,
> >>struct dpu_enc_phys_init_params *params)
> >> {
> >> @@ -2121,7 +2121,7 @@ static int dpu_encoder_virt_add_phys_encs(
> >>return -EINVAL;
> >>}
> >>
> >> - if (display_caps & MSM_DISPLAY_CAP_VID_MODE) {
> >> + if (disp_info->capabilities & MSM_DISPLAY_CAP_VID_MODE) {
> >>enc = dpu_encoder_phys_vid_init(params);
> >>
> >>if (IS_ERR_OR_NULL(enc)) {
> >> @@ -2134,7 +2134,7 @@ static int dpu_encoder_virt_add_phys_encs(
> >>++dpu_enc->num_phys_encs;
> >>}
> >>
> >> - if (display_caps & MSM_DISPLAY_CAP_CMD_MODE) {
> >> + if (disp_info->capabilities & MSM_DISPLAY_CAP_CMD_MODE) {
> >>enc = dpu_encoder_phys_cmd_init(params);
> >>
> >>if (IS_ERR_OR_NULL(enc)) {
> >> @@ -2147,6 +2147,19 @@ static int dpu_encoder_virt_add_phys_encs(
> >>++dpu_enc->num_phys_encs;
> >>}
> >>
> >> + if (disp_info->intf_type == DRM_MODE_ENCODER_VIRTUAL) {
> >> + enc = dpu_encoder_phys_wb_init(params);
> >> +
> >> + if (IS_ERR_OR_NULL(enc)) {
> >> + DPU_ERROR_ENC(dpu_enc, "failed to init wb enc: %ld\n",
> >> + PTR_ERR(enc));
> >> + return enc == NULL ? -EINVAL : PTR_ERR(enc);
> >> + }
> >> +
> >> + dpu_enc->phys_encs[dpu_enc->num_phys_encs] = enc;
> >> + ++dpu_enc->num_phys_encs;
> >> + }
> >> +
> >>if (params->split_role == ENC_ROLE_SLAVE)
> >>dpu_enc->cur_slave = enc;
> >>else
> >> @@ -2248,9 +2261,8 @@ static int dpu_encoder_setup_display(struct
> >> dpu_encoder_virt *dpu_enc,
> >>}
> >>
> >>if (!ret) {
> >> - ret =
> >> dpu_encoder_virt_add_phys_encs(disp_info->capabilities,
> >> -
> >> dpu_enc,
> >> -
> >> &phys_params);
> >> + ret = dpu_encoder_virt_add_phys_encs(disp_info,
> >> + dpu_enc, &phys_params);
> >>if (ret)
> >>DPU_ERROR_ENC(dpu_enc, "failed to add phys
> >> encs\n");
> >>}
> >> @@ -2367,8 +2379,9 @@ struct drm_encoder *dpu_encoder_init(struct
> >> drm_device *dev,
> >>if (!dpu_enc)
> >>re
Re: [Freedreno] [PATCH v5 15/19] drm/msm/dpu: initialize dpu encoder and connector for writeback
dation. All rights reserved.
> + * Copyright (c) 2022 Qualcomm Innovation Center, Inc. All rights reserved.
> + *
> * Author: Rob Clark
> */
>
> @@ -15,6 +17,7 @@
> #include
> #include
> #include
> +#include
>
> #include "msm_drv.h"
> #include "msm_mmu.h"
> @@ -29,6 +32,7 @@
> #include "dpu_kms.h"
> #include "dpu_plane.h"
> #include "dpu_vbif.h"
> +#include "dpu_writeback.h"
>
> #define CREATE_TRACE_POINTS
> #include "dpu_trace.h"
> @@ -648,6 +652,45 @@ static int _dpu_kms_initialize_displayport(struct
> drm_device *dev,
> return 0;
> }
>
> +static int _dpu_kms_initialize_writeback(struct drm_device *dev,
> + struct msm_drm_private *priv, struct dpu_kms *dpu_kms,
> + const u32 *wb_formats, int n_formats)
> +{
> + struct drm_encoder *encoder = NULL;
> + struct msm_display_info info;
> + int rc;
> +
> + encoder = dpu_encoder_init(dev, DRM_MODE_ENCODER_VIRTUAL);
I'm puzzled. I thought the whole purpose of the
drm_writeback_connector_init_with_encoder() function was to share an
encoder between writeback and a real display output, but the encoder you
create here seems to be specific to writeback. What am I missing ?
> + if (IS_ERR(encoder)) {
> + DPU_ERROR("encoder init failed for dsi display\n");
> + return PTR_ERR(encoder);
> + }
> +
> + memset(&info, 0, sizeof(info));
> +
> + rc = dpu_writeback_init(dev, encoder, wb_formats,
> + n_formats);
> + if (rc) {
> + DPU_ERROR("dpu_writeback_init, rc = %d\n", rc);
> + drm_encoder_cleanup(encoder);
> + return rc;
> + }
> +
> + info.num_of_h_tiles = 1;
> + /* use only WB idx 2 instance for DPU */
> + info.h_tile_instance[0] = WB_2;
> + info.intf_type = encoder->encoder_type;
> +
> + rc = dpu_encoder_setup(dev, encoder, &info);
> + if (rc) {
> + DPU_ERROR("failed to setup DPU encoder %d: rc:%d\n",
> + encoder->base.id, rc);
> + return rc;
> + }
> +
> + return 0;
> +}
> +
> /**
> * _dpu_kms_setup_displays - create encoders, bridges and connectors
> * for underlying displays
> @@ -661,6 +704,7 @@ static int _dpu_kms_setup_displays(struct drm_device *dev,
> struct dpu_kms *dpu_kms)
> {
> int rc = 0;
> + int i;
>
> rc = _dpu_kms_initialize_dsi(dev, priv, dpu_kms);
> if (rc) {
> @@ -674,6 +718,21 @@ static int _dpu_kms_setup_displays(struct drm_device
> *dev,
> return rc;
> }
>
> + /* Since WB isn't a driver check the catalog before initializing */
> + if (dpu_kms->catalog->wb_count) {
> + for (i = 0; i < dpu_kms->catalog->wb_count; i++) {
> + if (dpu_kms->catalog->wb[i].id == WB_2) {
> + rc = _dpu_kms_initialize_writeback(dev, priv,
> dpu_kms,
> +
> dpu_kms->catalog->wb[i].format_list,
> +
> dpu_kms->catalog->wb[i].num_formats);
> + if (rc) {
> + DPU_ERROR("initialize_WB failed, rc =
> %d\n", rc);
> + return rc;
> + }
> + }
> + }
> + }
> +
> return rc;
> }
>
--
Regards,
Laurent Pinchart
Re: [Freedreno] [PATCH v4 03/20] drm: allow real encoder to be passed for drm_writeback_connector
On Mon, Apr 25, 2022 at 10:48:07AM -0700, Abhinav Kumar wrote: > On 4/25/2022 10:32 AM, Laurent Pinchart wrote: > > On Mon, Apr 25, 2022 at 01:50:43PM +0300, Dmitry Baryshkov wrote: > >> On Sun, 24 Apr 2022 at 22:59, Laurent Pinchart wrote: > >>> On Sun, Apr 24, 2022 at 11:23:20AM -0700, Abhinav Kumar wrote: > >>>> On 4/24/2022 11:12 AM, Abhinav Kumar wrote: > >>>>> On 4/24/2022 7:50 AM, Laurent Pinchart wrote: > >>>>>> On Fri, Apr 22, 2022 at 04:06:38PM -0700, Abhinav Kumar wrote: > >>>>>>> For some vendor driver implementations, display hardware can > >>>>>>> be shared between the encoder used for writeback and the physical > >>>>>>> display. > >>>>>>> > >>>>>>> In addition resources such as clocks and interrupts can > >>>>>>> also be shared between writeback and the real encoder. > >>>>>>> > >>>>>>> To accommodate such vendor drivers and hardware, allow > >>>>>>> real encoder to be passed for drm_writeback_connector. > >>>>>>> > >>>>>>> For existing clients, drm_writeback_connector_init() will use > >>>>>>> an internal_encoder under the hood and hence no changes will > >>>>>>> be needed. > >>>>>>> > >>>>>>> changes in v7: > >>>>>>> - move this change before the vc4 change in the series > >>>>>>>to minimize the changes to vendor drivers in drm core > >>>>>>>changes > >>>>>> > >>>>>> Why is this needed ? The drm_writeback_connector functions don't need > >>>>>> the drm_encoder after drm_writeback_connector_init() (or > >>>>>> drm_writeback_connector_init_with_encoder()) returns. > >>>>>> > >>>>> > >>>>> Sorry I didnt follow this comment. This change log is incorrect, so > >>>>> after changing the previous change in the series and modifying this, no > >>>>> further changes are needed to vc4, so I decided to drop the next change. > >>>>> So this change log is incorrect. I can remove this. > >>>>> > >>>>> Is that what you meant? > >>>> > >>>> So till the previous change, the only user of > >>>> drm_writeback_connector_init_with_encoder() was > >>>> drm_writeback_connector_init() which was still passing its own > >>>> internal_encoder. > >>>> > >>>> Only if the wb_connector->encoder is changed to a pointer, other vendor > >>>> drivers can pass their own encoder to > >>>> drm_writeback_connector_init_with_encoder(). > >>>> > >>>> Hence you are right that drm_writeback_connector functions do not need > >>>> drm_encoder after init() returns, but till this change is done, other > >>>> vendor drivers cannot directly call > >>>> drm_writeback_connector_init_with_encoder() because the encoder will not > >>>> be valid till then. > >>> > >>> Users of drm_writeback_connector_init_with_encoder() handle the encoder > >>> themselves, they can simply ignore drm_writeback_connector.encoder. The > >>> documentation of the encoder field needs to be updated though (I'd do so > >>> in the previous patch), to clearly mention that the field is valid only > >>> when using drm_writeback_connector_init(), not when calling > >>> drm_writeback_connector_init_with_encoder(). > >> > >> If we allow it to be unitialized, it might end with hard-to-trace > >> bugs, additional conditions, etc. > >> In my opnion we should: > >> - either make drm_writeback_connector.encoder a valid pointer > >> - or drop the field completely. > >> > >> And up to some point I'd vote for the second option. The code using > >> internal_encoder can continue using it directly. The code using > >> drm_writeback_connector_init_with_encoder() will manage encoder on > >> their own. We will loose a single entry point for wb's encoder, but do > >> we really need it? (Frankly speaking I didn't check.) > > > > As far as I understand, we went for the second option as Abhinav dropped > > this patch for the next version. > > I dropped the patch as there wa
Re: [Freedreno] [PATCH v4 03/20] drm: allow real encoder to be passed for drm_writeback_connector
On Mon, Apr 25, 2022 at 01:50:43PM +0300, Dmitry Baryshkov wrote: > On Sun, 24 Apr 2022 at 22:59, Laurent Pinchart wrote: > > On Sun, Apr 24, 2022 at 11:23:20AM -0700, Abhinav Kumar wrote: > > > On 4/24/2022 11:12 AM, Abhinav Kumar wrote: > > > > On 4/24/2022 7:50 AM, Laurent Pinchart wrote: > > > >> On Fri, Apr 22, 2022 at 04:06:38PM -0700, Abhinav Kumar wrote: > > > >>> For some vendor driver implementations, display hardware can > > > >>> be shared between the encoder used for writeback and the physical > > > >>> display. > > > >>> > > > >>> In addition resources such as clocks and interrupts can > > > >>> also be shared between writeback and the real encoder. > > > >>> > > > >>> To accommodate such vendor drivers and hardware, allow > > > >>> real encoder to be passed for drm_writeback_connector. > > > >>> > > > >>> For existing clients, drm_writeback_connector_init() will use > > > >>> an internal_encoder under the hood and hence no changes will > > > >>> be needed. > > > >>> > > > >>> changes in v7: > > > >>> - move this change before the vc4 change in the series > > > >>> to minimize the changes to vendor drivers in drm core > > > >>> changes > > > >> > > > >> Why is this needed ? The drm_writeback_connector functions don't need > > > >> the drm_encoder after drm_writeback_connector_init() (or > > > >> drm_writeback_connector_init_with_encoder()) returns. > > > >> > > > > > > > > Sorry I didnt follow this comment. This change log is incorrect, so > > > > after changing the previous change in the series and modifying this, no > > > > further changes are needed to vc4, so I decided to drop the next change. > > > > So this change log is incorrect. I can remove this. > > > > > > > > Is that what you meant? > > > > > > So till the previous change, the only user of > > > drm_writeback_connector_init_with_encoder() was > > > drm_writeback_connector_init() which was still passing its own > > > internal_encoder. > > > > > > Only if the wb_connector->encoder is changed to a pointer, other vendor > > > drivers can pass their own encoder to > > > drm_writeback_connector_init_with_encoder(). > > > > > > Hence you are right that drm_writeback_connector functions do not need > > > drm_encoder after init() returns, but till this change is done, other > > > vendor drivers cannot directly call > > > drm_writeback_connector_init_with_encoder() because the encoder will not > > > be valid till then. > > > > Users of drm_writeback_connector_init_with_encoder() handle the encoder > > themselves, they can simply ignore drm_writeback_connector.encoder. The > > documentation of the encoder field needs to be updated though (I'd do so > > in the previous patch), to clearly mention that the field is valid only > > when using drm_writeback_connector_init(), not when calling > > drm_writeback_connector_init_with_encoder(). > > If we allow it to be unitialized, it might end with hard-to-trace > bugs, additional conditions, etc. > In my opnion we should: > - either make drm_writeback_connector.encoder a valid pointer > - or drop the field completely. > > And up to some point I'd vote for the second option. The code using > internal_encoder can continue using it directly. The code using > drm_writeback_connector_init_with_encoder() will manage encoder on > their own. We will loose a single entry point for wb's encoder, but do > we really need it? (Frankly speaking I didn't check.) As far as I understand, we went for the second option as Abhinav dropped this patch for the next version. > > > Hope this clarifies it. > > > > > > >>> Signed-off-by: Abhinav Kumar > > > >>> Reviewed-by: Dmitry Baryshkov > > > >>> --- > > > >>> drivers/gpu/drm/drm_writeback.c | 18 -- > > > >>> drivers/gpu/drm/vc4/vc4_txp.c | 4 ++-- > > > >>> include/drm/drm_writeback.h | 22 -- > > > >>> 3 files changed, 34 insertions(+), 10 deletions(-) > > > >>> > > > >>> diff --git a/drivers/gpu/drm/drm_writeback.c > > > >>> b/drivers/gpu/drm/d
Re: [Freedreno] [PATCH v4 03/20] drm: allow real encoder to be passed for drm_writeback_connector
Hi Abhinav,
On Sun, Apr 24, 2022 at 11:23:20AM -0700, Abhinav Kumar wrote:
> On 4/24/2022 11:12 AM, Abhinav Kumar wrote:
> > On 4/24/2022 7:50 AM, Laurent Pinchart wrote:
> >> On Fri, Apr 22, 2022 at 04:06:38PM -0700, Abhinav Kumar wrote:
> >>> For some vendor driver implementations, display hardware can
> >>> be shared between the encoder used for writeback and the physical
> >>> display.
> >>>
> >>> In addition resources such as clocks and interrupts can
> >>> also be shared between writeback and the real encoder.
> >>>
> >>> To accommodate such vendor drivers and hardware, allow
> >>> real encoder to be passed for drm_writeback_connector.
> >>>
> >>> For existing clients, drm_writeback_connector_init() will use
> >>> an internal_encoder under the hood and hence no changes will
> >>> be needed.
> >>>
> >>> changes in v7:
> >>> - move this change before the vc4 change in the series
> >>> to minimize the changes to vendor drivers in drm core
> >>> changes
> >>
> >> Why is this needed ? The drm_writeback_connector functions don't need
> >> the drm_encoder after drm_writeback_connector_init() (or
> >> drm_writeback_connector_init_with_encoder()) returns.
> >>
> >
> > Sorry I didnt follow this comment. This change log is incorrect, so
> > after changing the previous change in the series and modifying this, no
> > further changes are needed to vc4, so I decided to drop the next change.
> > So this change log is incorrect. I can remove this.
> >
> > Is that what you meant?
>
> So till the previous change, the only user of
> drm_writeback_connector_init_with_encoder() was
> drm_writeback_connector_init() which was still passing its own
> internal_encoder.
>
> Only if the wb_connector->encoder is changed to a pointer, other vendor
> drivers can pass their own encoder to
> drm_writeback_connector_init_with_encoder().
>
> Hence you are right that drm_writeback_connector functions do not need
> drm_encoder after init() returns, but till this change is done, other
> vendor drivers cannot directly call
> drm_writeback_connector_init_with_encoder() because the encoder will not
> be valid till then.
Users of drm_writeback_connector_init_with_encoder() handle the encoder
themselves, they can simply ignore drm_writeback_connector.encoder. The
documentation of the encoder field needs to be updated though (I'd do so
in the previous patch), to clearly mention that the field is valid only
when using drm_writeback_connector_init(), not when calling
drm_writeback_connector_init_with_encoder().
> Hope this clarifies it.
>
> >>> Signed-off-by: Abhinav Kumar
> >>> Reviewed-by: Dmitry Baryshkov
> >>> ---
> >>> drivers/gpu/drm/drm_writeback.c | 18 --
> >>> drivers/gpu/drm/vc4/vc4_txp.c | 4 ++--
> >>> include/drm/drm_writeback.h | 22 --
> >>> 3 files changed, 34 insertions(+), 10 deletions(-)
> >>>
> >>> diff --git a/drivers/gpu/drm/drm_writeback.c
> >>> b/drivers/gpu/drm/drm_writeback.c
> >>> index 92658ad..0538674 100644
> >>> --- a/drivers/gpu/drm/drm_writeback.c
> >>> +++ b/drivers/gpu/drm/drm_writeback.c
> >>> @@ -180,21 +180,21 @@ int drm_writeback_connector_init(struct
> >>> drm_device *dev,
> >>> {
> >>> int ret = 0;
> >>> - drm_encoder_helper_add(&wb_connector->encoder, enc_helper_funcs);
> >>> + drm_encoder_helper_add(&wb_connector->internal_encoder,
> >>> enc_helper_funcs);
> >>> - wb_connector->encoder.possible_crtcs = possible_crtcs;
> >>> + wb_connector->internal_encoder.possible_crtcs = possible_crtcs;
> >>> - ret = drm_encoder_init(dev, &wb_connector->encoder,
> >>> + ret = drm_encoder_init(dev, &wb_connector->internal_encoder,
> >>> &drm_writeback_encoder_funcs,
> >>> DRM_MODE_ENCODER_VIRTUAL, NULL);
> >>> if (ret)
> >>> return ret;
> >>> - ret = drm_writeback_connector_init_with_encoder(dev, wb_connector,
> >>> &wb_connector->encoder,
> >>> - con_funcs, formats, n_formats);
> >>> + ret = drm_writeback_connector_init_with_encoder(dev, wb_connector,
> >>> + &wb_connector->internal_encoder, con_fun
Re: [Freedreno] [PATCH v4 03/20] drm: allow real encoder to be passed for drm_writeback_connector
equirements. The users of the >* @drm_writeback_connector control the behaviour of the @encoder >* by passing the @enc_funcs parameter to drm_writeback_connector_init() >* function. > + * > + * For some vendor drivers, the hardware resources are shared between > + * writeback encoder and rest of the display pipeline. > + * To accommodate such cases, encoder is a handle to the real encoder > + * hardware. > + * > + * For current existing writeback users, this shall continue to be the > + * embedded encoder for the writeback connector. > + */ > + struct drm_encoder *encoder; > + > + /** > + * @internal_encoder: internal encoder used by writeback when > + * drm_writeback_connector_init() is used. > + * @encoder will be assigned to this for those cases > + * > + * This will be unused when drm_writeback_connector_init_with_encoder() > + * is used. >*/ > - struct drm_encoder encoder; > + struct drm_encoder internal_encoder; > > /** >* @pixel_formats_blob_ptr: -- Regards, Laurent Pinchart
Re: [Freedreno] [PATCH v4 02/20] drm: introduce drm_writeback_connector_init_with_encoder() API
Hi Abhinav,
Thank you for the patch.
On Fri, Apr 22, 2022 at 04:06:37PM -0700, Abhinav Kumar wrote:
> For vendors drivers which pass an already allocated and
> initialized encoder especially for cases where the encoder
> hardware is shared OR the writeback encoder shares the resources
> with the rest of the display pipeline introduce a new API,
> drm_writeback_connector_init_with_encoder() which expects
> an initialized encoder as a parameter and only sets up the
> writeback connector.
>
> changes in v4:
> - removed the possible_crtcs part
>
> changes in v5:
> - reorder this change to come before in the series
> to avoid incorrect functionality in subsequent changes
> - continue using struct drm_encoder instead of
> struct drm_encoder * and switch it in next change
>
> changes in v6:
> - remove drm_writeback_connector_setup() and instead
> directly call drm_writeback_connector_init_with_encoder()
> - fix a drm_writeback_connector typo and function doc which
> incorrectly shows that the function accepts enc_helper_funcs
> - pass encoder as a parameter explicitly to the new API
> for better readability
>
> changes in v7:
> - fix the function doc slightly as suggested by Liviu
>
> Reviewed-by: Liviu Dudau
> Signed-off-by: Abhinav Kumar
> Reviewed-by: Dmitry Baryshkov
> ---
> drivers/gpu/drm/drm_writeback.c | 72
> +
> include/drm/drm_writeback.h | 6
> 2 files changed, 64 insertions(+), 14 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_writeback.c b/drivers/gpu/drm/drm_writeback.c
> index 9e0b845..92658ad 100644
> --- a/drivers/gpu/drm/drm_writeback.c
> +++ b/drivers/gpu/drm/drm_writeback.c
> @@ -178,6 +178,62 @@ int drm_writeback_connector_init(struct drm_device *dev,
>const u32 *formats, int n_formats,
>u32 possible_crtcs)
> {
> + int ret = 0;
> +
> + drm_encoder_helper_add(&wb_connector->encoder, enc_helper_funcs);
> +
> + wb_connector->encoder.possible_crtcs = possible_crtcs;
> +
> + ret = drm_encoder_init(dev, &wb_connector->encoder,
> +&drm_writeback_encoder_funcs,
> +DRM_MODE_ENCODER_VIRTUAL, NULL);
> + if (ret)
> + return ret;
> +
> + ret = drm_writeback_connector_init_with_encoder(dev, wb_connector,
> &wb_connector->encoder,
> + con_funcs, formats, n_formats);
> +
> + if (ret)
> + drm_encoder_cleanup(&wb_connector->encoder);
> +
> + return ret;
> +}
> +EXPORT_SYMBOL(drm_writeback_connector_init);
> +
> +/**
> + * drm_writeback_connector_init_with_encoder - Initialize a writeback
> connector and its properties
> + * using the encoder which already assigned and initialized
That sounds a bit convoluted to me. How about
* drm_writeback_connector_init_with_encoder - Initialize a writeback connector
* with a custom encoder
Reviewed-by: Laurent Pinchart
> + *
> + * @dev: DRM device
> + * @wb_connector: Writeback connector to initialize
> + * @enc: handle to the already initialized drm encoder
> + * @con_funcs: Connector funcs vtable
> + * @formats: Array of supported pixel formats for the writeback engine
> + * @n_formats: Length of the formats array
> + *
> + * This function creates the writeback-connector-specific properties if they
> + * have not been already created, initializes the connector as
> + * type DRM_MODE_CONNECTOR_WRITEBACK, and correctly initializes the property
> + * values.
> + *
> + * This function assumes that the drm_writeback_connector's encoder has
> already been
> + * created and initialized before invoking this function.
> + *
> + * In addition, this function also assumes that callers of this API will
> manage
> + * assigning the encoder helper functions, possible_crtcs and any other
> encoder
> + * specific operation.
> + *
> + * Drivers should always use this function instead of drm_connector_init() to
> + * set up writeback connectors if they want to manage themselves the
> lifetime of the
> + * associated encoder.
> + *
> + * Returns: 0 on success, or a negative error code
> + */
> +int drm_writeback_connector_init_with_encoder(struct drm_device *dev,
> + struct drm_writeback_connector *wb_connector, struct
> drm_encoder *enc,
> + const struct drm_connector_funcs *con_funcs, const u32 *formats,
> + int n_formats)
> +{
> struct drm_property_blob *blob;
> struct drm_connector *connector = &wb_connect
Re: [Freedreno] [PATCH v4 01/20] drm: allow passing possible_crtcs to drm_writeback_connector_init()
Hi Abhinav,
Thank you for the patch.
On Fri, Apr 22, 2022 at 04:06:36PM -0700, Abhinav Kumar wrote:
> Clients of drm_writeback_connector_init() initialize the
> possible_crtcs and then invoke the call to this API.
>
> To simplify things, allow passing possible_crtcs as a parameter
> to drm_writeback_connector_init() and make changes to the
> other drm drivers to make them compatible with this change.
>
> changes in v2:
> - split the changes according to their functionality
>
> changes in v3:
> - allow passing possible_crtcs for existing users of
> drm_writeback_connector_init()
> - squash the vendor changes into the same commit so
> that each patch in the series can compile individually
>
> changes in v4:
> - keep only changes related to possible_crtcs
> - add line breaks after ARRAY_SIZE
> - stop using temporary variables for possible_crtcs
>
> changes in v5:
> - None
>
> changes in v6:
> - None
>
> changes in v7:
> - wrap long lines to match the coding style of existing drivers
> - Fix indentation and remove parenthesis where not needed
> - use u32 instead of uint32_t for possible_crtcs
>
> Signed-off-by: Abhinav Kumar
> Acked-by: Liviu Dudau
> Reviewed-by: Dmitry Baryshkov
Reviewed-by: Laurent Pinchart
> ---
> drivers/gpu/drm/arm/display/komeda/komeda_wb_connector.c | 4 ++--
> drivers/gpu/drm/arm/malidp_mw.c | 4 ++--
> drivers/gpu/drm/drm_writeback.c | 7 ++-
> drivers/gpu/drm/rcar-du/rcar_du_writeback.c | 4 ++--
> drivers/gpu/drm/vc4/vc4_txp.c| 3 ++-
> drivers/gpu/drm/vkms/vkms_writeback.c| 4 ++--
> include/drm/drm_writeback.h | 3 ++-
> 7 files changed, 18 insertions(+), 11 deletions(-)
>
> diff --git a/drivers/gpu/drm/arm/display/komeda/komeda_wb_connector.c
> b/drivers/gpu/drm/arm/display/komeda/komeda_wb_connector.c
> index e465cc4..ce4b760 100644
> --- a/drivers/gpu/drm/arm/display/komeda/komeda_wb_connector.c
> +++ b/drivers/gpu/drm/arm/display/komeda/komeda_wb_connector.c
> @@ -155,7 +155,6 @@ static int komeda_wb_connector_add(struct komeda_kms_dev
> *kms,
> kwb_conn->wb_layer = kcrtc->master->wb_layer;
>
> wb_conn = &kwb_conn->base;
> - wb_conn->encoder.possible_crtcs = BIT(drm_crtc_index(&kcrtc->base));
>
> formats = komeda_get_layer_fourcc_list(&mdev->fmt_tbl,
> kwb_conn->wb_layer->layer_type,
> @@ -164,7 +163,8 @@ static int komeda_wb_connector_add(struct komeda_kms_dev
> *kms,
> err = drm_writeback_connector_init(&kms->base, wb_conn,
> &komeda_wb_connector_funcs,
> &komeda_wb_encoder_helper_funcs,
> -formats, n_formats);
> +formats, n_formats,
> +BIT(drm_crtc_index(&kcrtc->base)));
> komeda_put_fourcc_list(formats);
> if (err) {
> kfree(kwb_conn);
> diff --git a/drivers/gpu/drm/arm/malidp_mw.c b/drivers/gpu/drm/arm/malidp_mw.c
> index f5847a7..204c869 100644
> --- a/drivers/gpu/drm/arm/malidp_mw.c
> +++ b/drivers/gpu/drm/arm/malidp_mw.c
> @@ -212,7 +212,6 @@ int malidp_mw_connector_init(struct drm_device *drm)
> if (!malidp->dev->hw->enable_memwrite)
> return 0;
>
> - malidp->mw_connector.encoder.possible_crtcs = 1 <<
> drm_crtc_index(&malidp->crtc);
> drm_connector_helper_add(&malidp->mw_connector.base,
>&malidp_mw_connector_helper_funcs);
>
> @@ -223,7 +222,8 @@ int malidp_mw_connector_init(struct drm_device *drm)
> ret = drm_writeback_connector_init(drm, &malidp->mw_connector,
> &malidp_mw_connector_funcs,
> &malidp_mw_encoder_helper_funcs,
> -formats, n_formats);
> +formats, n_formats,
> +1 << drm_crtc_index(&malidp->crtc));
> kfree(formats);
> if (ret)
> return ret;
> diff --git a/drivers/gpu/drm/drm_writeback.c b/drivers/gpu/drm/drm_writeback.c
> index dccf4504..9e0b845 100644
> --- a/drivers/gpu/drm/drm_writeback.c
> +++ b/drivers/gpu/drm/drm_writeback.c
> @@ -157,6 +157,7 @@ static const struct drm_encoder_funcs
> drm_writeback_e
Re: [Freedreno] [PATCH v6 4/4] drm: allow real encoder to be passed for drm_writeback_connector
Hi Abhinav,
On Tue, Apr 05, 2022 at 09:53:57AM -0700, Abhinav Kumar wrote:
> On 4/5/2022 9:47 AM, Laurent Pinchart wrote:
> > On Mon, Apr 04, 2022 at 11:43:37AM -0700, Rob Clark wrote:
> >> On Fri, Apr 1, 2022 at 8:38 AM Laurent Pinchart wrote:
> >>> On Thu, Mar 31, 2022 at 05:12:13PM -0700, Abhinav Kumar wrote:
> >>>> For some vendor driver implementations, display hardware can
> >>>> be shared between the encoder used for writeback and the physical
> >>>> display.
> >>>>
> >>>> In addition resources such as clocks and interrupts can
> >>>> also be shared between writeback and the real encoder.
> >>>>
> >>>> To accommodate such vendor drivers and hardware, allow
> >>>> real encoder to be passed for drm_writeback_connector.
> >>>>
> >>>> changes in v6:
> >>>>- assign the encoder inside
> >>>> drm_writeback_connector_init_with_encoder() for
> >>>> better readability
> >>>>- improve some documentation for internal encoder
> >>>>
> >>>> Co-developed-by: Kandpal Suraj
> >>>> Signed-off-by: Kandpal Suraj
> >>>> Signed-off-by: Abhinav Kumar
> >>>> ---
> >>>> drivers/gpu/drm/drm_writeback.c | 18 --
> >>>> drivers/gpu/drm/vc4/vc4_txp.c | 14 --
> >>>> include/drm/drm_writeback.h | 21 +++--
> >>>
> >>> Please split this in two patches, one for the DRM core and one for the
> >>> VC4 driver. This applies to most patches as a general rule, with the
> >>> main exception being API refactoring that requires changing the
> >>> implementation and all its users in a single patch.
> >>
> >> But this *is* API refactoring ;-)
> >
> > Partly at least :-) Looking at the API change itself, wouldn't we
> > minimize the extra changes to vc4 if we moved this patch before 3/4 ?
>
> I can move all the changes done in vc4 except below part to the change
> 3/4 itself because that way I can show usage of vc4->drm_enc with the
> new API. Let me know if that works.
What I meant is moving the API refactoring from 4/4 before the current
3/4, with minimal changes to vc4 there (only to avoid introducing a
bisection breakge), and then move most of the vc4 changes from this
patch to the current 3/4 (which will become 4/4). If that's what you
meant too, it sounds good to me.
> The only part which will remain is the below one:
>
> @@ -523,7 +525,7 @@ static int vc4_txp_bind(struct device *dev, struct
> device *master, void *data)
> if (ret)
> return ret;
>
> - encoder = &txp->connector.encoder;
> + encoder = txp->connector.encoder;
> encoder->possible_crtcs = drm_crtc_mask(crtc);
>
> Since i dont know vc4 driver very well, I was not sure of a good way to
> decouple this dependency.
>
> Let me know if that works.
>
> >>>> 3 files changed, 39 insertions(+), 14 deletions(-)
> >>>>
> >>>> diff --git a/drivers/gpu/drm/drm_writeback.c
> >>>> b/drivers/gpu/drm/drm_writeback.c
> >>>> index 797223c..7f72109 100644
> >>>> --- a/drivers/gpu/drm/drm_writeback.c
> >>>> +++ b/drivers/gpu/drm/drm_writeback.c
> >>>> @@ -179,21 +179,21 @@ int drm_writeback_connector_init(struct drm_device
> >>>> *dev,
> >>>> {
> >>>>int ret = 0;
> >>>>
> >>>> - drm_encoder_helper_add(&wb_connector->encoder, enc_helper_funcs);
> >>>> + drm_encoder_helper_add(&wb_connector->internal_encoder,
> >>>> enc_helper_funcs);
> >>>>
> >>>> - wb_connector->encoder.possible_crtcs = possible_crtcs;
> >>>> + wb_connector->internal_encoder.possible_crtcs = possible_crtcs;
> >>>>
> >>>> - ret = drm_encoder_init(dev, &wb_connector->encoder,
> >>>> + ret = drm_encoder_init(dev, &wb_connector->internal_encoder,
> >>>> &drm_writeback_encoder_funcs,
> >>>> DRM_MODE_ENCODER_VIRTUAL, NULL);
> >>>>if (ret)
> >>>>return ret;
> >>>>
> >>>> - ret = drm_writeback_connector_init_with_encoder(dev, wb_connector,
> >>>> &wb_connector->encoder,
&
Re: [Freedreno] [PATCH v6 4/4] drm: allow real encoder to be passed for drm_writeback_connector
Hi Rob and Abhinav,
On Mon, Apr 04, 2022 at 11:43:37AM -0700, Rob Clark wrote:
> On Fri, Apr 1, 2022 at 8:38 AM Laurent Pinchart wrote:
> > On Thu, Mar 31, 2022 at 05:12:13PM -0700, Abhinav Kumar wrote:
> > > For some vendor driver implementations, display hardware can
> > > be shared between the encoder used for writeback and the physical
> > > display.
> > >
> > > In addition resources such as clocks and interrupts can
> > > also be shared between writeback and the real encoder.
> > >
> > > To accommodate such vendor drivers and hardware, allow
> > > real encoder to be passed for drm_writeback_connector.
> > >
> > > changes in v6:
> > > - assign the encoder inside
> > > drm_writeback_connector_init_with_encoder() for
> > > better readability
> > > - improve some documentation for internal encoder
> > >
> > > Co-developed-by: Kandpal Suraj
> > > Signed-off-by: Kandpal Suraj
> > > Signed-off-by: Abhinav Kumar
> > > ---
> > > drivers/gpu/drm/drm_writeback.c | 18 --
> > > drivers/gpu/drm/vc4/vc4_txp.c | 14 --
> > > include/drm/drm_writeback.h | 21 +++--
> >
> > Please split this in two patches, one for the DRM core and one for the
> > VC4 driver. This applies to most patches as a general rule, with the
> > main exception being API refactoring that requires changing the
> > implementation and all its users in a single patch.
>
> But this *is* API refactoring ;-)
Partly at least :-) Looking at the API change itself, wouldn't we
minimize the extra changes to vc4 if we moved this patch before 3/4 ?
> > > 3 files changed, 39 insertions(+), 14 deletions(-)
> > >
> > > diff --git a/drivers/gpu/drm/drm_writeback.c
> > > b/drivers/gpu/drm/drm_writeback.c
> > > index 797223c..7f72109 100644
> > > --- a/drivers/gpu/drm/drm_writeback.c
> > > +++ b/drivers/gpu/drm/drm_writeback.c
> > > @@ -179,21 +179,21 @@ int drm_writeback_connector_init(struct drm_device
> > > *dev,
> > > {
> > > int ret = 0;
> > >
> > > - drm_encoder_helper_add(&wb_connector->encoder, enc_helper_funcs);
> > > + drm_encoder_helper_add(&wb_connector->internal_encoder,
> > > enc_helper_funcs);
> > >
> > > - wb_connector->encoder.possible_crtcs = possible_crtcs;
> > > + wb_connector->internal_encoder.possible_crtcs = possible_crtcs;
> > >
> > > - ret = drm_encoder_init(dev, &wb_connector->encoder,
> > > + ret = drm_encoder_init(dev, &wb_connector->internal_encoder,
> > > &drm_writeback_encoder_funcs,
> > > DRM_MODE_ENCODER_VIRTUAL, NULL);
> > > if (ret)
> > > return ret;
> > >
> > > - ret = drm_writeback_connector_init_with_encoder(dev, wb_connector,
> > > &wb_connector->encoder,
> > > - con_funcs, formats, n_formats);
> > > + ret = drm_writeback_connector_init_with_encoder(dev, wb_connector,
> > > + &wb_connector->internal_encoder, con_funcs,
> > > formats, n_formats);
> > >
> > > if (ret)
> > > - drm_encoder_cleanup(&wb_connector->encoder);
> > > + drm_encoder_cleanup(&wb_connector->internal_encoder);
> > >
> > > return ret;
> > > }
> > > @@ -238,6 +238,12 @@ int drm_writeback_connector_init_with_encoder(struct
> > > drm_device *dev,
> > > struct drm_mode_config *config = &dev->mode_config;
> > > int ret = create_writeback_properties(dev);
> > >
> > > + /*
> > > + * Assign the encoder passed to this API to the wb_connector's
> > > encoder.
> > > + * For drm_writeback_connector_init(), this shall be the
> > > internal_encoder
> > > + */
> > > + wb_connector->encoder = enc;
> > > +
> > > if (ret != 0)
> > > return ret;
> > >
> > > diff --git a/drivers/gpu/drm/vc4/vc4_txp.c b/drivers/gpu/drm/vc4/vc4_txp.c
> > > index 5e53f02..a9b4f83 100644
> > > --- a/drivers/gpu/drm/vc4/vc4_txp.c
> > > +++ b/drivers/gpu/drm/vc4/vc4_txp.c
> > > @@ -151,6 +151,8 @@ struct vc4_txp {
> > >
> > > struct platform_device *pdev;
> > >
>
Re: [Freedreno] [PATCH v6 4/4] drm: allow real encoder to be passed for drm_writeback_connector
xp_bind(struct device *dev, struct
> device *master, void *data)
> drm_connector_helper_add(&wb_conn->base,
>&vc4_txp_connector_helper_funcs);
>
> - ret = drm_writeback_connector_init_with_encoder(drm, wb_conn,
> &wb_conn->encoder,
> + ret = drm_writeback_connector_init_with_encoder(drm, wb_conn,
> &txp->drm_enc,
> &vc4_txp_connector_funcs, drm_fmts,
> ARRAY_SIZE(drm_fmts));
> if (ret) {
> - drm_encoder_cleanup(&wb_conn->encoder);
> + drm_encoder_cleanup(&txp->drm_enc);
> return ret;
> }
>
> @@ -523,7 +525,7 @@ static int vc4_txp_bind(struct device *dev, struct device
> *master, void *data)
> if (ret)
> return ret;
>
> - encoder = &txp->connector.encoder;
> + encoder = txp->connector.encoder;
> encoder->possible_crtcs = drm_crtc_mask(crtc);
>
> ret = devm_request_irq(dev, irq, vc4_txp_interrupt, 0,
> diff --git a/include/drm/drm_writeback.h b/include/drm/drm_writeback.h
> index 4795024..3f5c330 100644
> --- a/include/drm/drm_writeback.h
> +++ b/include/drm/drm_writeback.h
> @@ -25,15 +25,32 @@ struct drm_writeback_connector {
> struct drm_connector base;
>
> /**
> - * @encoder: Internal encoder used by the connector to fulfill
> + * @encoder: handle to drm_encoder used by the connector to fulfill
>* the DRM framework requirements. The users of the
>* @drm_writeback_connector control the behaviour of the @encoder
>* by passing the @enc_funcs parameter to drm_writeback_connector_init()
>* function.
> + *
> + * For some vendor drivers, the hardware resources are shared between
> + * writeback encoder and rest of the display pipeline.
> + * To accommodate such cases, encoder is a handle to the real encoder
> + * hardware.
> + *
> + * For current existing writeback users, this shall continue to be the
> + * embedded encoder for the writeback connector.
>*/
> - struct drm_encoder encoder;
> + struct drm_encoder *encoder;
>
> /**
> + * @internal_encoder: internal encoder used by writeback when
> + * drm_writeback_connector_init() is used.
> + * @encoder will be assigned to this for those cases
> + *
> + * This will be unused when drm_writeback_connector_init_with_encoder()
> + * is used.
> + */
> + struct drm_encoder internal_encoder;
> + /**
>* @pixel_formats_blob_ptr:
>*
>* DRM blob property data for the pixel formats list on writeback
> --
> 2.7.4
>
--
Regards,
Laurent Pinchart
Re: [Freedreno] [PATCH v6 1/4] drm: allow passing possible_crtcs to drm_writeback_connector_init()
lper_funcs
> *enc_helper_funcs,
> - const u32 *formats, int n_formats)
> + const u32 *formats, int n_formats, uint32_t
> possible_crtcs)
For in-kernel code, you can use u32 instead of uint32_t.
> {
> struct drm_property_blob *blob;
> struct drm_connector *connector = &wb_connector->base;
> @@ -190,6 +191,9 @@ int drm_writeback_connector_init(struct drm_device *dev,
> return PTR_ERR(blob);
>
> drm_encoder_helper_add(&wb_connector->encoder, enc_helper_funcs);
> +
> + wb_connector->encoder.possible_crtcs = possible_crtcs;
> +
> ret = drm_encoder_init(dev, &wb_connector->encoder,
> &drm_writeback_encoder_funcs,
> DRM_MODE_ENCODER_VIRTUAL, NULL);
> diff --git a/drivers/gpu/drm/rcar-du/rcar_du_writeback.c
> b/drivers/gpu/drm/rcar-du/rcar_du_writeback.c
> index c79d125..fcfb0b3 100644
> --- a/drivers/gpu/drm/rcar-du/rcar_du_writeback.c
> +++ b/drivers/gpu/drm/rcar-du/rcar_du_writeback.c
> @@ -200,7 +200,6 @@ int rcar_du_writeback_init(struct rcar_du_device *rcdu,
> {
> struct drm_writeback_connector *wb_conn = &rcrtc->writeback;
>
> - wb_conn->encoder.possible_crtcs = 1 << drm_crtc_index(&rcrtc->crtc);
> drm_connector_helper_add(&wb_conn->base,
>&rcar_du_wb_conn_helper_funcs);
>
> @@ -208,7 +207,8 @@ int rcar_du_writeback_init(struct rcar_du_device *rcdu,
> &rcar_du_wb_conn_funcs,
> &rcar_du_wb_enc_helper_funcs,
> writeback_formats,
> - ARRAY_SIZE(writeback_formats));
> + ARRAY_SIZE(writeback_formats),
> +(1 << drm_crtc_index(&rcrtc->crtc)));
Wrong indentation, and outer parentheses are not needed.
> }
>
> void rcar_du_writeback_setup(struct rcar_du_crtc *rcrtc,
> diff --git a/drivers/gpu/drm/vc4/vc4_txp.c b/drivers/gpu/drm/vc4/vc4_txp.c
> index 9809ca3..3447eb6 100644
> --- a/drivers/gpu/drm/vc4/vc4_txp.c
> +++ b/drivers/gpu/drm/vc4/vc4_txp.c
> @@ -497,7 +497,8 @@ static int vc4_txp_bind(struct device *dev, struct device
> *master, void *data)
> ret = drm_writeback_connector_init(drm, &txp->connector,
> &vc4_txp_connector_funcs,
> &vc4_txp_encoder_helper_funcs,
> -drm_fmts, ARRAY_SIZE(drm_fmts));
> +drm_fmts, ARRAY_SIZE(drm_fmts),
> +0);
> if (ret)
> return ret;
>
> diff --git a/drivers/gpu/drm/vkms/vkms_writeback.c
> b/drivers/gpu/drm/vkms/vkms_writeback.c
> index 8694227..6d01e55 100644
> --- a/drivers/gpu/drm/vkms/vkms_writeback.c
> +++ b/drivers/gpu/drm/vkms/vkms_writeback.c
> @@ -140,12 +140,12 @@ int vkms_enable_writeback_connector(struct vkms_device
> *vkmsdev)
> {
> struct drm_writeback_connector *wb = &vkmsdev->output.wb_connector;
>
> - vkmsdev->output.wb_connector.encoder.possible_crtcs = 1;
> drm_connector_helper_add(&wb->base, &vkms_wb_conn_helper_funcs);
>
> return drm_writeback_connector_init(&vkmsdev->drm, wb,
> &vkms_wb_connector_funcs,
> &vkms_wb_encoder_helper_funcs,
> vkms_wb_formats,
> - ARRAY_SIZE(vkms_wb_formats));
> + ARRAY_SIZE(vkms_wb_formats),
> + 1);
> }
> diff --git a/include/drm/drm_writeback.h b/include/drm/drm_writeback.h
> index 9697d27..db6214f 100644
> --- a/include/drm/drm_writeback.h
> +++ b/include/drm/drm_writeback.h
> @@ -150,7 +150,7 @@ int drm_writeback_connector_init(struct drm_device *dev,
>struct drm_writeback_connector *wb_connector,
>const struct drm_connector_funcs *con_funcs,
>const struct drm_encoder_helper_funcs
> *enc_helper_funcs,
> - const u32 *formats, int n_formats);
> + const u32 *formats, int n_formats, uint32_t
> possible_crtcs);
Line wrap here too.
>
> int drm_writeback_set_fb(struct drm_connector_state *conn_state,
>struct drm_framebuffer *fb);
--
Regards,
Laurent Pinchart
Re: [Freedreno] [PATCH v3 1/3] drm: allow real encoder to be passed for drm_writeback_connector
per_funcs,
> + drm_fmts, ARRAY_SIZE(drm_fmts), 0);
Most of this also doesn't belong to this patch.
> if (ret)
> return ret;
>
> @@ -506,7 +511,7 @@ static int vc4_txp_bind(struct device *dev, struct device
> *master, void *data)
> if (ret)
> return ret;
>
> - encoder = &txp->connector.encoder;
> + encoder = txp->connector.encoder;
> encoder->possible_crtcs = drm_crtc_mask(crtc);
>
> ret = devm_request_irq(dev, irq, vc4_txp_interrupt, 0,
> diff --git a/drivers/gpu/drm/vkms/vkms_writeback.c
> b/drivers/gpu/drm/vkms/vkms_writeback.c
> index 8694227..381e7b7 100644
> --- a/drivers/gpu/drm/vkms/vkms_writeback.c
> +++ b/drivers/gpu/drm/vkms/vkms_writeback.c
> @@ -140,12 +140,11 @@ int vkms_enable_writeback_connector(struct vkms_device
> *vkmsdev)
> {
> struct drm_writeback_connector *wb = &vkmsdev->output.wb_connector;
>
> - vkmsdev->output.wb_connector.encoder.possible_crtcs = 1;
> drm_connector_helper_add(&wb->base, &vkms_wb_conn_helper_funcs);
>
> return drm_writeback_connector_init(&vkmsdev->drm, wb,
> &vkms_wb_connector_funcs,
> &vkms_wb_encoder_helper_funcs,
> vkms_wb_formats,
> - ARRAY_SIZE(vkms_wb_formats));
> + ARRAY_SIZE(vkms_wb_formats), 1);
> }
> diff --git a/include/drm/drm_writeback.h b/include/drm/drm_writeback.h
> index 9697d27..5e002bc 100644
> --- a/include/drm/drm_writeback.h
> +++ b/include/drm/drm_writeback.h
> @@ -25,13 +25,29 @@ struct drm_writeback_connector {
> struct drm_connector base;
>
> /**
> - * @encoder: Internal encoder used by the connector to fulfill
> + * @encoder: handle to drm_encoder used by the connector to fulfill
>* the DRM framework requirements. The users of the
>* @drm_writeback_connector control the behaviour of the @encoder
>* by passing the @enc_funcs parameter to drm_writeback_connector_init()
>* function.
> + *
> + * For some vendor drivers, the hardware resources are shared between
> + * writeback encoder and rest of the display pipeline.
> + * To accommodate such cases, encoder is a handle to the real encoder
> + * hardware.
> + *
> + * For current existing writeback users, this shall continue to be the
> + * embedded encoder for the writeback connector.
> + *
> + */
> + struct drm_encoder *encoder;
> +
> + /**
> + * @internal_encoder: internal encoder used by writeback when
> + * a real encoder is not provided by the vendor drm drivers.
> + * @encoder will be assigned to this for those cases.
>*/
> - struct drm_encoder encoder;
> + struct drm_encoder internal_encoder;
None of this belong here.
>
> /**
>* @pixel_formats_blob_ptr:
> @@ -150,7 +166,7 @@ int drm_writeback_connector_init(struct drm_device *dev,
>struct drm_writeback_connector *wb_connector,
>const struct drm_connector_funcs *con_funcs,
>const struct drm_encoder_helper_funcs
> *enc_helper_funcs,
> - const u32 *formats, int n_formats);
> + const u32 *formats, int n_formats, uint32_t
> possible_crtcs);
>
> int drm_writeback_set_fb(struct drm_connector_state *conn_state,
>struct drm_framebuffer *fb);
--
Regards,
Laurent Pinchart
Re: [Freedreno] [PATCH 5/6] drm/rcar_du: use drm_encoder pointer for drm_writeback_connector
Hi Abhinav
On Fri, Mar 11, 2022 at 09:47:17AM -0800, Abhinav Kumar wrote:
> On 3/10/2022 11:28 PM, Laurent Pinchart wrote:
> > On Thu, Mar 10, 2022 at 05:49:59PM -0800, Abhinav Kumar wrote:
> >> Make changes to rcar_du driver to start using drm_encoder pointer
> >> for drm_writeback_connector.
> >>
> >> Co-developed-by: Kandpal Suraj
> >> Signed-off-by: Abhinav Kumar
> >> ---
> >> drivers/gpu/drm/rcar-du/rcar_du_writeback.c | 3 ++-
> >> 1 file changed, 2 insertions(+), 1 deletion(-)
> >>
> >> diff --git a/drivers/gpu/drm/rcar-du/rcar_du_writeback.c
> >> b/drivers/gpu/drm/rcar-du/rcar_du_writeback.c
> >> index c79d125..03930ad 100644
> >> --- a/drivers/gpu/drm/rcar-du/rcar_du_writeback.c
> >> +++ b/drivers/gpu/drm/rcar-du/rcar_du_writeback.c
> >> @@ -200,7 +200,8 @@ int rcar_du_writeback_init(struct rcar_du_device *rcdu,
> >> {
> >>struct drm_writeback_connector *wb_conn = &rcrtc->writeback;
> >>
> >> - wb_conn->encoder.possible_crtcs = 1 << drm_crtc_index(&rcrtc->crtc);
> >> + wb_conn->encoder = kzalloc(sizeof(struct drm_encoder), GFP_KERNEL);
> >
> > Where is this freed ?
>
> You are right, this isnt. Looking more into this, it seems like moving
> the allocation of encoder to drm_writeback.c for cases which dont pass a
> real encoder is much better so that I will not have to add alloc() /
> free() code for all the vendor driver changes which is what I originally
> thought in my RFC but changed my mind because of below.
Yes, I think that would be better indeed. You could even skip the
dynamic allocation, you could have
struct drm_encoder *encoder;
struct drm_encoder internal_encoder;
in drm_writeback_connector, and set
wb->encoder = &wb->internal_encoder;
when the user doesn't pass an encoder.
> >> + wb_conn->encoder->possible_crtcs = 1 << drm_crtc_index(&rcrtc->crtc);
>
> Do you think we can just move usage of wb_conn->encoder->possible_crtcs
> just right after drm_writeback_connector_init() so that it wont crash?
How about adding a possible_crtcs argument to
drm_writeback_connector_init() (to cover existing use cases), and adding
a new drm_writeback_connector_init_with_encoder() that would get an
encoder pointer (and expect possible_crtcs, as well as all the other
appropriate encoder fields, having been initialized) ?
> 198 int rcar_du_writeback_init(struct rcar_du_device *rcdu,
> 199 struct rcar_du_crtc *rcrtc)
> 200 {
> 201 struct drm_writeback_connector *wb_conn = &rcrtc->writeback;
> 202
> 203 wb_conn->encoder.possible_crtcs = 1 << drm_crtc_index(&rcrtc->crtc);
> 204 drm_connector_helper_add(&wb_conn->base,
> 205&rcar_du_wb_conn_helper_funcs);
> 206
> 207 return drm_writeback_connector_init(&rcdu->ddev, wb_conn,
> 208 &rcar_du_wb_conn_funcs,
> 209 &rcar_du_wb_enc_helper_funcs,
> 210 writeback_formats,
> 211 ARRAY_SIZE(writeback_formats));
> 212 }
>
> >>drm_connector_helper_add(&wb_conn->base,
> >> &rcar_du_wb_conn_helper_funcs);
> >>
--
Regards,
Laurent Pinchart
Re: [Freedreno] [PATCH 1/6] drm: allow real encoder to be passed for drm_writeback_connector
On Fri, Mar 11, 2022 at 10:46:13AM +0300, Dmitry Baryshkov wrote:
> On Fri, 11 Mar 2022 at 04:50, Abhinav Kumar wrote:
> >
> > For some vendor driver implementations, display hardware can
> > be shared between the encoder used for writeback and the physical
> > display.
> >
> > In addition resources such as clocks and interrupts can
> > also be shared between writeback and the real encoder.
> >
> > To accommodate such vendor drivers and hardware, allow
> > real encoder to be passed for drm_writeback_connector.
> >
> > Co-developed-by: Kandpal Suraj
> > Signed-off-by: Abhinav Kumar
> > ---
> > drivers/gpu/drm/drm_writeback.c | 8
> > include/drm/drm_writeback.h | 13 +++--
> > 2 files changed, 15 insertions(+), 6 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/drm_writeback.c
> > b/drivers/gpu/drm/drm_writeback.c
> > index dccf4504..4dad687 100644
> > --- a/drivers/gpu/drm/drm_writeback.c
> > +++ b/drivers/gpu/drm/drm_writeback.c
> > @@ -189,8 +189,8 @@ int drm_writeback_connector_init(struct drm_device *dev,
> > if (IS_ERR(blob))
> > return PTR_ERR(blob);
> >
> > - drm_encoder_helper_add(&wb_connector->encoder, enc_helper_funcs);
> > - ret = drm_encoder_init(dev, &wb_connector->encoder,
> > + drm_encoder_helper_add(wb_connector->encoder, enc_helper_funcs);
> > + ret = drm_encoder_init(dev, wb_connector->encoder,
> >&drm_writeback_encoder_funcs,
> >DRM_MODE_ENCODER_VIRTUAL, NULL);
>
> If the encoder is provided by a separate driver, it might use a
> different set of encoder funcs.
More than that, if the encoder is provided externally but doesn't have
custom operations, I don't really see the point of having an external
encoder in the first place.
Has this series been tested with a driver that needs to provide an
encoder, to make sure it fits the purpose ?
> I'd suggest checking whether the wb_connector->encoder is NULL here.
> If it is, allocate one using drmm_kzalloc and init it.
> If it is not NULL, assume that it has been initialized already, so
> skip the drm_encoder_init() and just call the drm_encoder_helper_add()
>
> > if (ret)
> > @@ -204,7 +204,7 @@ int drm_writeback_connector_init(struct drm_device *dev,
> > goto connector_fail;
> >
> > ret = drm_connector_attach_encoder(connector,
> > - &wb_connector->encoder);
> > + wb_connector->encoder);
> > if (ret)
> > goto attach_fail;
> >
> > @@ -233,7 +233,7 @@ int drm_writeback_connector_init(struct drm_device *dev,
> > attach_fail:
> > drm_connector_cleanup(connector);
> > connector_fail:
> > - drm_encoder_cleanup(&wb_connector->encoder);
> > + drm_encoder_cleanup(wb_connector->encoder);
> > fail:
> > drm_property_blob_put(blob);
> > return ret;
> > diff --git a/include/drm/drm_writeback.h b/include/drm/drm_writeback.h
> > index 9697d27..0ba266e 100644
> > --- a/include/drm/drm_writeback.h
> > +++ b/include/drm/drm_writeback.h
> > @@ -25,13 +25,22 @@ struct drm_writeback_connector {
> > struct drm_connector base;
> >
> > /**
> > -* @encoder: Internal encoder used by the connector to fulfill
> > +* @encoder: handle to drm_encoder used by the connector to fulfill
> > * the DRM framework requirements. The users of the
> > * @drm_writeback_connector control the behaviour of the @encoder
> > * by passing the @enc_funcs parameter to
> > drm_writeback_connector_init()
> > * function.
> > +*
> > +* For some vendor drivers, the hardware resources are shared
> > between
> > +* writeback encoder and rest of the display pipeline.
> > +* To accommodate such cases, encoder is a handle to the real
> > encoder
> > +* hardware.
> > +*
> > +* For current existing writeback users, this shall continue to be
> > the
> > +* embedded encoder for the writeback connector.
> > +*
> > */
> > - struct drm_encoder encoder;
> > + struct drm_encoder *encoder;
> >
> > /**
> > * @pixel_formats_blob_ptr:
--
Regards,
Laurent Pinchart
Re: [Freedreno] [PATCH 5/6] drm/rcar_du: use drm_encoder pointer for drm_writeback_connector
Hi Abhinav
Thank you for the patch.
On Thu, Mar 10, 2022 at 05:49:59PM -0800, Abhinav Kumar wrote:
> Make changes to rcar_du driver to start using drm_encoder pointer
> for drm_writeback_connector.
>
> Co-developed-by: Kandpal Suraj
> Signed-off-by: Abhinav Kumar
> ---
> drivers/gpu/drm/rcar-du/rcar_du_writeback.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/rcar-du/rcar_du_writeback.c
> b/drivers/gpu/drm/rcar-du/rcar_du_writeback.c
> index c79d125..03930ad 100644
> --- a/drivers/gpu/drm/rcar-du/rcar_du_writeback.c
> +++ b/drivers/gpu/drm/rcar-du/rcar_du_writeback.c
> @@ -200,7 +200,8 @@ int rcar_du_writeback_init(struct rcar_du_device *rcdu,
> {
> struct drm_writeback_connector *wb_conn = &rcrtc->writeback;
>
> - wb_conn->encoder.possible_crtcs = 1 << drm_crtc_index(&rcrtc->crtc);
> + wb_conn->encoder = kzalloc(sizeof(struct drm_encoder), GFP_KERNEL);
Where is this freed ?
> + wb_conn->encoder->possible_crtcs = 1 << drm_crtc_index(&rcrtc->crtc);
> drm_connector_helper_add(&wb_conn->base,
>&rcar_du_wb_conn_helper_funcs);
>
--
Regards,
Laurent Pinchart
Re: [Freedreno] [PATCH v6 02/35] component: Introduce the aggregate bus_type
Hi Daniel, On Mon, Jan 31, 2022 at 04:15:09PM +0100, Daniel Vetter wrote: > On Mon, Jan 31, 2022 at 2:48 PM Greg Kroah-Hartman wrote: > > On Thu, Jan 27, 2022 at 12:01:08PM -0800, Stephen Boyd wrote: > > > The component framework only provides 'bind' and 'unbind' callbacks to > > > tell the host driver that it is time to assemble the aggregate driver > > > now that all the components have probed. The component framework doesn't > > > attempt to resolve runtime PM or suspend/resume ordering, and explicitly > > > mentions this in the code. This lack of support leads to some pretty > > > gnarly usages of the 'prepare' and 'complete' power management hooks in > > > drivers that host the aggregate device, and it fully breaks down when > > > faced with ordering shutdown between the various components, the > > > aggregate driver, and the host driver that registers the whole thing. > > > > > > In a concrete example, the MSM display driver at drivers/gpu/drm/msm is > > > using 'prepare' and 'complete' to call the drm helpers > > > drm_mode_config_helper_suspend() and drm_mode_config_helper_resume() > > > respectively, so that it can move the aggregate driver suspend/resume > > > callbacks to be before and after the components that make up the drm > > > device call any suspend/resume hooks they have. This only works as long > > > as the component devices don't do anything in their own 'prepare' and > > > 'complete' callbacks. If they did, then the ordering would be incorrect > > > and we would be doing something in the component drivers before the > > > aggregate driver could do anything. Yuck! > > > > > > Similarly, when trying to add shutdown support to the MSM driver we run > > > across a problem where we're trying to shutdown the drm device via > > > drm_atomic_helper_shutdown(), but some of the devices in the encoder > > > chain have already been shutdown. This time, the component devices > > > aren't the problem (although they could be if they did anything in their > > > shutdown callbacks), but there's a DSI to eDP bridge in the encoder > > > chain that has already been shutdown before the driver hosting the > > > aggregate device runs shutdown. The ordering of driver probe is like > > > this: > > > > > > 1. msm_pdev_probe() (host driver) > > > 2. DSI bridge > > > 3. aggregate bind > > > > > > When it comes to shutdown we have this order: > > > > > > 1. DSI bridge > > > 2. msm_pdev_shutdown() (host driver) > > > > > > and so the bridge is already off, but we want to communicate to it to > > > turn things off on the display during msm_pdev_shutdown(). Double yuck! > > > Unfortunately, this time we can't split shutdown into multiple phases > > > and swap msm_pdev_shutdown() with the DSI bridge. > > > > > > Let's make the component_master_ops into an actual device driver that has > > > probe/remove/shutdown functions. The driver will only be bound to the > > > aggregate device once all component drivers have called component_add() > > > to indicate they're ready to assemble the aggregate driver. This allows > > > us to attach shutdown logic (and in the future runtime PM logic) to the > > > aggregate driver so that it runs the hooks in the correct order. > > > > I know I asked before, but I can not remember the answer. > > > > This really looks like it is turning into the aux bus code. Why can't > > you just use that instead here for this type of thing? You are creating > > another bus and drivers for that bus that are "fake" which is great, but > > that's what the aux bus code was supposed to help out with, so we > > wouldn't have to write more of these. > > > > So, if this really is different, can you document it here so I remember > > next time you resend this patch series? > > aux takes a device and splits it into a lot of sub-devices, each with > their own driver. > > This takes a pile of devices, and turns it into a single logical > device with a single driver. > > So aux is 1:N, component is N:1. > > And yes you asked this already, I typed this up already :-) That's clear, but I'm still not sure why we need a bus for this :-) I'm not very enthousiastic about that. Some of our problems come from the fact we need to coordinate many devices, adding new ones hardly seem to be a solution to that. Granted, the components framework doesn't work nicely, and is in dire need of love (and documentation), or possibly better a complete replacement. I'll try to review the series this week and see if alternatives would be possible. -- Regards, Laurent Pinchart
Re: [Freedreno] [RFC PATCH] drm: allow passing a real encoder object for wb connector
Hi Abhinav,
Thank you for the patch.
On Thu, Jan 20, 2022 at 06:29:55PM -0800, Abhinav Kumar wrote:
> Instead of creating an internal encoder for the writeback
> connector to satisfy DRM requirements, allow the clients
> to pass a real encoder to it by changing the drm_writeback's
> encoder to a pointer.
>
> If a real encoder is not passed, drm_writeback_connector_init
> will internally allocate one.
>
> This will help the clients to manage the real encoder states
> better as they will allocate and maintain the encoder.
A writeback connector is a bit of a hack. It was implemented that way to
minimize the extensions to the KMS userspace API for writeback support.
There's no "encoder" there, as there's no real "connector" either. The
only reason we register a drm_encoder in the writeback implementation is
because encoders are exposed to userspace and are thus required (this is
considered a historical mistake that we can't fix anymore). Why do you
thus need to create a "real encoder" ?
> Signed-off-by: Abhinav Kumar
> ---
> drivers/gpu/drm/drm_writeback.c | 11 +++
> include/drm/drm_writeback.h | 2 +-
> 2 files changed, 8 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_writeback.c b/drivers/gpu/drm/drm_writeback.c
> index dccf4504..fdb7381 100644
> --- a/drivers/gpu/drm/drm_writeback.c
> +++ b/drivers/gpu/drm/drm_writeback.c
> @@ -189,8 +189,11 @@ int drm_writeback_connector_init(struct drm_device *dev,
> if (IS_ERR(blob))
> return PTR_ERR(blob);
>
> - drm_encoder_helper_add(&wb_connector->encoder, enc_helper_funcs);
> - ret = drm_encoder_init(dev, &wb_connector->encoder,
> + /* allocate the internal drm encoder if a real one wasnt passed */
> + if (!wb_connector->encoder)
> + wb_connector->encoder = devm_kzalloc(dev->dev, sizeof(struct
> drm_encoder), GFP_KERNEL);
> + drm_encoder_helper_add(wb_connector->encoder, enc_helper_funcs);
> + ret = drm_encoder_init(dev, wb_connector->encoder,
> &drm_writeback_encoder_funcs,
> DRM_MODE_ENCODER_VIRTUAL, NULL);
> if (ret)
> @@ -204,7 +207,7 @@ int drm_writeback_connector_init(struct drm_device *dev,
> goto connector_fail;
>
> ret = drm_connector_attach_encoder(connector,
> - &wb_connector->encoder);
> + wb_connector->encoder);
> if (ret)
> goto attach_fail;
>
> @@ -233,7 +236,7 @@ int drm_writeback_connector_init(struct drm_device *dev,
> attach_fail:
> drm_connector_cleanup(connector);
> connector_fail:
> - drm_encoder_cleanup(&wb_connector->encoder);
> + drm_encoder_cleanup(wb_connector->encoder);
> fail:
> drm_property_blob_put(blob);
> return ret;
> diff --git a/include/drm/drm_writeback.h b/include/drm/drm_writeback.h
> index 9697d27..f0d8147 100644
> --- a/include/drm/drm_writeback.h
> +++ b/include/drm/drm_writeback.h
> @@ -31,7 +31,7 @@ struct drm_writeback_connector {
>* by passing the @enc_funcs parameter to drm_writeback_connector_init()
>* function.
>*/
> - struct drm_encoder encoder;
> + struct drm_encoder *encoder;
>
> /**
>* @pixel_formats_blob_ptr:
--
Regards,
Laurent Pinchart
Re: [Freedreno] [PATCH 1/2] drm/ bridge: tc358762: move bridge init to enable callback
> > > 1 file changed, 10 insertions(+), 10 deletions(-)
> > >
> > > diff --git a/drivers/gpu/drm/bridge/tc358762.c
> > > b/drivers/gpu/drm/bridge/tc358762.c
> > > index 7104828024fd..ebdf771a1e49 100644
> > > --- a/drivers/gpu/drm/bridge/tc358762.c
> > > +++ b/drivers/gpu/drm/bridge/tc358762.c
> > > @@ -64,7 +64,7 @@ struct tc358762 {
> > > struct drm_connector connector;
> > > struct regulator *regulator;
> > > struct drm_bridge *panel_bridge;
> > > - bool pre_enabled;
> > > + bool enabled;
> > > int error;
> > > };
> > >
> > > @@ -125,26 +125,26 @@ static int tc358762_init(struct tc358762 *ctx)
> > > return tc358762_clear_error(ctx);
> > > }
> > >
> > > -static void tc358762_post_disable(struct drm_bridge *bridge)
> > > +static void tc358762_disable(struct drm_bridge *bridge)
> > > {
> > > struct tc358762 *ctx = bridge_to_tc358762(bridge);
> > > int ret;
> > >
> > > /*
> > > -* The post_disable hook might be called multiple times.
> > > +* The disable hook might be called multiple times.
> > > * We want to avoid regulator imbalance below.
> > > */
> > > - if (!ctx->pre_enabled)
> > > + if (!ctx->enabled)
> > > return;
> > >
> > > - ctx->pre_enabled = false;
> > > + ctx->enabled = false;
> > >
> > > ret = regulator_disable(ctx->regulator);
> > > if (ret < 0)
> > > dev_err(ctx->dev, "error disabling regulators (%d)\n",
> > > ret);
> > > }
> > >
> > > -static void tc358762_pre_enable(struct drm_bridge *bridge)
> > > +static void tc358762_enable(struct drm_bridge *bridge)
> > > {
> > > struct tc358762 *ctx = bridge_to_tc358762(bridge);
> > > int ret;
> > > @@ -157,7 +157,7 @@ static void tc358762_pre_enable(struct drm_bridge
> > > *bridge)
> > > if (ret < 0)
> > > dev_err(ctx->dev, "error initializing bridge (%d)\n",
> > > ret);
> > >
> > > - ctx->pre_enabled = true;
> > > + ctx->enabled = true;
> > > }
> > >
> > > static int tc358762_attach(struct drm_bridge *bridge,
> > > @@ -170,8 +170,8 @@ static int tc358762_attach(struct drm_bridge *bridge,
> > > }
> > >
> > > static const struct drm_bridge_funcs tc358762_bridge_funcs = {
> > > - .post_disable = tc358762_post_disable,
> > > - .pre_enable = tc358762_pre_enable,
> > > + .disable = tc358762_disable,
> > > + .enable = tc358762_enable,
> > > .attach = tc358762_attach,
> > > };
> > >
> > > @@ -218,7 +218,7 @@ static int tc358762_probe(struct mipi_dsi_device *dsi)
> > > mipi_dsi_set_drvdata(dsi, ctx);
> > >
> > > ctx->dev = dev;
> > > - ctx->pre_enabled = false;
> > > + ctx->enabled = false;
> > >
> > > /* TODO: Find out how to get dual-lane mode working */
> > > dsi->lanes = 1;
--
Regards,
Laurent Pinchart
Re: [Freedreno] [PATCH v2 01/34] component: Introduce struct aggregate_device
int ret = 0;
>
> WARN_ON(!mutex_is_locked(&component_mutex));
>
> - master = __master_find(parent, NULL);
> - if (!master)
> + adev = __aggregate_find(parent, NULL);
> + if (!adev)
> return -EINVAL;
>
> /* Bind components in match order */
> - for (i = 0; i < master->match->num; i++)
> - if (!master->match->compare[i].duplicate) {
> - c = master->match->compare[i].component;
> - ret = component_bind(c, master, data);
> + for (i = 0; i < adev->match->num; i++)
> + if (!adev->match->compare[i].duplicate) {
> + c = adev->match->compare[i].component;
> + ret = component_bind(c, adev, data);
> if (ret)
> break;
> }
>
> if (ret != 0) {
> for (; i > 0; i--)
> - if (!master->match->compare[i - 1].duplicate) {
> - c = master->match->compare[i - 1].component;
> - component_unbind(c, master, data);
> + if (!adev->match->compare[i - 1].duplicate) {
> + c = adev->match->compare[i - 1].component;
> + component_unbind(c, adev, data);
> }
> }
>
> @@ -675,8 +691,8 @@ static int __component_add(struct device *dev, const
> struct component_ops *ops,
>
> ret = try_to_bring_up_masters(component);
> if (ret < 0) {
> - if (component->master)
> - remove_component(component->master, component);
> + if (component->adev)
> + remove_component(component->adev, component);
> list_del(&component->node);
>
> kfree(component);
> @@ -757,9 +773,9 @@ void component_del(struct device *dev, const struct
> component_ops *ops)
> break;
> }
>
> - if (component && component->master) {
> - take_down_master(component->master);
> - remove_component(component->master, component);
> + if (component && component->adev) {
> + take_down_aggregate_device(component->adev);
> + remove_component(component->adev, component);
> }
>
> mutex_unlock(&component_mutex);
> diff --git a/include/linux/component.h b/include/linux/component.h
> index 16de18f473d7..71bfc3862633 100644
> --- a/include/linux/component.h
> +++ b/include/linux/component.h
> @@ -41,7 +41,7 @@ void component_del(struct device *, const struct
> component_ops *);
> int component_bind_all(struct device *master, void *master_data);
> void component_unbind_all(struct device *master, void *master_data);
>
> -struct master;
> +struct aggregate_device;
>
> /**
> * struct component_master_ops - callback for the aggregate driver
--
Regards,
Laurent Pinchart
Re: [Freedreno] [PATCH v2 3/3] drm/bridge: ti-sn65dsi86: Add NO_CONNECTOR support
Hi Doug, On Fri, Oct 01, 2021 at 11:02:54AM -0700, Doug Anderson wrote: > On Thu, Sep 23, 2021 at 7:26 PM Laurent Pinchart wrote: > > > > > > > err_conn_init: > > > > > drm_dp_aux_unregister(&pdata->aux); > > > > > return ret; > > > > > @@ -792,9 +790,30 @@ static void ti_sn_bridge_set_dsi_rate(struct > > > > > ti_sn65dsi86 *pdata) > > > > > regmap_write(pdata->regmap, SN_DSIA_CLK_FREQ_REG, val); > > > > > } > > > > > > > > > > +/* > > > > > + * Find the connector and fish out the bpc from display_info. It > > > > > would > > > > > + * be nice if we could get this instead from drm_bridge_state, but > > > > > that > > > > > + * doesn't yet appear to be the case. > > > > > > > > You already have a bus format in the bridge state, from which you can > > > > derive the bpp. Could you give it a try ? > > > > > > Possibly the bridge should be converted to ->atomic_enable(), etc.. > > > I'll leave that for another time > > > > It should be fairly straightforward, and would avoid the hack below. > > Given this point of controversy, my inclination is to wait and not > apply this patch now. I don't think there's anything urgent here, > right? Worst case eventually Laurent might pick it up in his patch > series? At least we know it will work with the MSM driver once patch > #1 lands. :-) I've recorded the task for my upcoming work on the ti-sn65dsi86 driver. -- Regards, Laurent Pinchart
Re: [Freedreno] [PATCH v4 00/24] drm/bridge: Make panel and bridge probe order consistent
Hi Maxime,
On Thu, Sep 30, 2021 at 12:56:02AM +0300, Laurent Pinchart wrote:
> On Fri, Sep 10, 2021 at 12:11:54PM +0200, Maxime Ripard wrote:
> > Hi,
> >
> > We've encountered an issue with the RaspberryPi DSI panel that prevented the
> > whole display driver from probing.
> >
> > The issue is described in detail in the commit 7213246a803f ("drm/vc4: dsi:
> > Only register our component once a DSI device is attached"), but the basic
> > idea
> > is that since the panel is probed through i2c, there's no synchronization
> > between its probe and the registration of the MIPI-DSI host it's attached
> > to.
> >
> > We initially moved the component framework registration to the MIPI-DSI Host
> > attach hook to make sure we register our component only when we have a DSI
> > device attached to our MIPI-DSI host, and then use lookup our DSI device in
> > our
> > bind hook.
> >
> > However, all the DSI bridges controlled through i2c are only registering
> > their
> > associated DSI device in their bridge attach hook, meaning with our change
> > above, we never got that far, and therefore ended up in the same situation
> > than
> > the one we were trying to fix for panels.
> >
> > The best practice to avoid those issues is to register its functions only
> > after
> > all its dependencies are live. We also shouldn't wait any longer than we
> > should
> > to play nice with the other components that are waiting for us, so in our
> > case
> > that would mean moving the DSI device registration to the bridge probe.
> >
> > I also had a look at all the DSI hosts, and it seems that exynos, kirin and
> > msm
> > would be affected by this and wouldn't probe anymore after those changes.
> > Exynos and kirin seems to be simple enough for a mechanical change (that
> > still
> > requires to be tested), but the changes in msm seemed to be far more
> > important
> > and I wasn't confortable doing them.
> >
> > Let me know what you think,
>
> I've tested this series on my RPi CM4-based board, and there's a clear
> improvement: the sn65dsi83 now probes successfully !
>
> The downside is that I can now look at a panel that desperately refuses
> to display anything. That's a separate issue, but it prevents me from
> telling whether this series introduces regressions :-S I'll try to debug
> that separately.
I managed to (partly) fix that issue with a few backports from the RPi
kernel, making me confident enough to say
Tested-by: Laurent Pinchart
for
drivers/gpu/drm/bridge/ti-sn65dsi83.c
drivers/gpu/drm/drm_bridge.c
drivers/gpu/drm/drm_mipi_dsi.c
include/drm/drm_mipi_dsi.h
> Also, Kieran, would you be able to test this with the SN65DSI86 ?
>
> > ---
> >
> > Changes from v3:
> > - Converted exynos and kirin
> > - Converted all the affected bridge drivers
> > - Reworded the documentation a bit
> >
> > Changes from v2:
> > - Changed the approach as suggested by Andrzej, and aligned the bridge on
> > the
> > panel this time.
> > - Fixed some typos
> >
> > Changes from v1:
> > - Change the name of drm_of_get_next function to drm_of_get_bridge
> > - Mention the revert of 87154ff86bf6 and squash the two patches that were
> > reverting that commit
> > - Add some documentation
> > - Make drm_panel_attach and _detach succeed when no callback is there
> >
> > Maxime Ripard (24):
> > drm/bridge: Add documentation sections
> > drm/bridge: Document the probe issue with MIPI-DSI bridges
> > drm/mipi-dsi: Create devm device registration
> > drm/mipi-dsi: Create devm device attachment
> > drm/bridge: adv7533: Switch to devm MIPI-DSI helpers
> > drm/bridge: adv7511: Register and attach our DSI device at probe
> > drm/bridge: anx7625: Switch to devm MIPI-DSI helpers
> > drm/bridge: anx7625: Register and attach our DSI device at probe
> > drm/bridge: lt8912b: Switch to devm MIPI-DSI helpers
> > drm/bridge: lt8912b: Register and attach our DSI device at probe
> > drm/bridge: lt9611: Switch to devm MIPI-DSI helpers
> > drm/bridge: lt9611: Register and attach our DSI device at probe
> > drm/bridge: lt9611uxc: Switch to devm MIPI-DSI helpers
> > drm/bridge: lt9611uxc: Register and attach our DSI device at probe
> > drm/bridge: ps8640: Switch to devm MIPI-DSI helpers
> > drm/bridge: ps8640: Register and attach our DSI device at probe
> > drm/bridge: sn65dsi83: Switch to devm MIPI-DSI helpers
&
Re: [Freedreno] [PATCH v4 00/24] drm/bridge: Make panel and bridge probe order consistent
31 ++ > drivers/gpu/drm/bridge/lontium-lt9611.c | 62 +--- > drivers/gpu/drm/bridge/lontium-lt9611uxc.c | 65 +--- > drivers/gpu/drm/bridge/parade-ps8640.c | 101 ++- > drivers/gpu/drm/bridge/tc358775.c| 50 + > drivers/gpu/drm/bridge/ti-sn65dsi83.c| 86 > drivers/gpu/drm/bridge/ti-sn65dsi86.c| 94 - > drivers/gpu/drm/drm_bridge.c | 69 - > drivers/gpu/drm/drm_mipi_dsi.c | 81 +++ > drivers/gpu/drm/exynos/exynos_drm_dsi.c | 19 ++-- > drivers/gpu/drm/hisilicon/kirin/dw_drm_dsi.c | 27 +++-- > include/drm/drm_mipi_dsi.h | 4 + > 17 files changed, 460 insertions(+), 317 deletions(-) -- Regards, Laurent Pinchart
Re: [Freedreno] [PATCH v2 3/3] drm/bridge: ti-sn65dsi86: Add NO_CONNECTOR support
Hi Rob,
On Thu, Sep 23, 2021 at 10:31:52AM -0700, Rob Clark wrote:
> On Wed, Sep 22, 2021 at 5:44 PM Laurent Pinchart wrote:
> > On Mon, Sep 20, 2021 at 03:58:00PM -0700, Rob Clark wrote:
> > > From: Rob Clark
> > >
> > > Slightly awkward to fish out the display_info when we aren't creating
> > > own connector. But I don't see an obvious better way.
> > >
> > > v2: Remove error return with NO_CONNECTOR flag
> > >
> > > Signed-off-by: Rob Clark
> > > ---
> > > drivers/gpu/drm/bridge/ti-sn65dsi86.c | 39 ---
> > > 1 file changed, 29 insertions(+), 10 deletions(-)
> > >
> > > diff --git a/drivers/gpu/drm/bridge/ti-sn65dsi86.c
> > > b/drivers/gpu/drm/bridge/ti-sn65dsi86.c
> > > index 6154bed0af5b..94c94cc8a4d8 100644
> > > --- a/drivers/gpu/drm/bridge/ti-sn65dsi86.c
> > > +++ b/drivers/gpu/drm/bridge/ti-sn65dsi86.c
> > > @@ -667,11 +667,6 @@ static int ti_sn_bridge_attach(struct drm_bridge
> > > *bridge,
> > > .node = NULL,
> > >};
> > >
> > > - if (flags & DRM_BRIDGE_ATTACH_NO_CONNECTOR) {
> > > - DRM_ERROR("Fix bridge driver to make connector optional!");
> > > - return -EINVAL;
> > > - }
> > > -
> > > pdata->aux.drm_dev = bridge->dev;
> > > ret = drm_dp_aux_register(&pdata->aux);
> > > if (ret < 0) {
> > > @@ -679,9 +674,11 @@ static int ti_sn_bridge_attach(struct drm_bridge
> > > *bridge,
> > > return ret;
> > > }
> > >
> > > - ret = ti_sn_bridge_connector_init(pdata);
> > > - if (ret < 0)
> > > - goto err_conn_init;
> > > + if (!(flags & DRM_BRIDGE_ATTACH_NO_CONNECTOR)) {
> > > + ret = ti_sn_bridge_connector_init(pdata);
> > > + if (ret < 0)
> > > + goto err_conn_init;
> > > + }
> > >
> > > /*
> > >* TODO: ideally finding host resource and dsi dev registration
> > > needs
> > > @@ -743,7 +740,8 @@ static int ti_sn_bridge_attach(struct drm_bridge
> > > *bridge,
> > > err_dsi_attach:
> > > mipi_dsi_device_unregister(dsi);
> > > err_dsi_host:
> > > - drm_connector_cleanup(&pdata->connector);
> > > + if (!(flags & DRM_BRIDGE_ATTACH_NO_CONNECTOR))
> > > + drm_connector_cleanup(&pdata->connector);
> >
> > I wonder if we actually need this. The connector gets attached to the
> > encoder, won't it be destroyed by the DRM core in the error path ?
>
> This does not appear to be the case, we leak the connector if I remove
> this (and add a hack to trigger the error path)
OK.
> > > err_conn_init:
> > > drm_dp_aux_unregister(&pdata->aux);
> > > return ret;
> > > @@ -792,9 +790,30 @@ static void ti_sn_bridge_set_dsi_rate(struct
> > > ti_sn65dsi86 *pdata)
> > > regmap_write(pdata->regmap, SN_DSIA_CLK_FREQ_REG, val);
> > > }
> > >
> > > +/*
> > > + * Find the connector and fish out the bpc from display_info. It would
> > > + * be nice if we could get this instead from drm_bridge_state, but that
> > > + * doesn't yet appear to be the case.
> >
> > You already have a bus format in the bridge state, from which you can
> > derive the bpp. Could you give it a try ?
>
> Possibly the bridge should be converted to ->atomic_enable(), etc..
> I'll leave that for another time
It should be fairly straightforward, and would avoid the hack below.
> > > + */
> > > static unsigned int ti_sn_bridge_get_bpp(struct ti_sn65dsi86 *pdata)
> > > {
> > > - if (pdata->connector.display_info.bpc <= 6)
> > > + struct drm_bridge *bridge = &pdata->bridge;
> > > + struct drm_connector_list_iter conn_iter;
> > > + struct drm_connector *connector;
> > > + unsigned bpc = 0;
> > > +
> > > + drm_connector_list_iter_begin(bridge->dev, &conn_iter);
> > > + drm_for_each_connector_iter(connector, &conn_iter) {
> > > + if (drm_connector_has_possible_encoder(connector,
> > > bridge->encoder)) {
> > > + bpc = connector->display_info.bpc;
> > > + break;
> > > + }
> > > + }
> > > + drm_connector_list_iter_end(&conn_iter);
> > > +
> > > + WARN_ON(bpc == 0);
> > > +
> > > + if (bpc <= 6)
> > > return 18;
> > > else
> > > return 24;
--
Regards,
Laurent Pinchart
Re: [Freedreno] [PATCH v2 3/3] drm/bridge: ti-sn65dsi86: Add NO_CONNECTOR support
Hi Rob,
Thank you for the patch.
On Mon, Sep 20, 2021 at 03:58:00PM -0700, Rob Clark wrote:
> From: Rob Clark
>
> Slightly awkward to fish out the display_info when we aren't creating
> own connector. But I don't see an obvious better way.
>
> v2: Remove error return with NO_CONNECTOR flag
>
> Signed-off-by: Rob Clark
> ---
> drivers/gpu/drm/bridge/ti-sn65dsi86.c | 39 ---
> 1 file changed, 29 insertions(+), 10 deletions(-)
>
> diff --git a/drivers/gpu/drm/bridge/ti-sn65dsi86.c
> b/drivers/gpu/drm/bridge/ti-sn65dsi86.c
> index 6154bed0af5b..94c94cc8a4d8 100644
> --- a/drivers/gpu/drm/bridge/ti-sn65dsi86.c
> +++ b/drivers/gpu/drm/bridge/ti-sn65dsi86.c
> @@ -667,11 +667,6 @@ static int ti_sn_bridge_attach(struct drm_bridge *bridge,
> .node = NULL,
>};
>
> - if (flags & DRM_BRIDGE_ATTACH_NO_CONNECTOR) {
> - DRM_ERROR("Fix bridge driver to make connector optional!");
> - return -EINVAL;
> - }
> -
> pdata->aux.drm_dev = bridge->dev;
> ret = drm_dp_aux_register(&pdata->aux);
> if (ret < 0) {
> @@ -679,9 +674,11 @@ static int ti_sn_bridge_attach(struct drm_bridge *bridge,
> return ret;
> }
>
> - ret = ti_sn_bridge_connector_init(pdata);
> - if (ret < 0)
> - goto err_conn_init;
> + if (!(flags & DRM_BRIDGE_ATTACH_NO_CONNECTOR)) {
> + ret = ti_sn_bridge_connector_init(pdata);
> + if (ret < 0)
> + goto err_conn_init;
> + }
>
> /*
>* TODO: ideally finding host resource and dsi dev registration needs
> @@ -743,7 +740,8 @@ static int ti_sn_bridge_attach(struct drm_bridge *bridge,
> err_dsi_attach:
> mipi_dsi_device_unregister(dsi);
> err_dsi_host:
> - drm_connector_cleanup(&pdata->connector);
> + if (!(flags & DRM_BRIDGE_ATTACH_NO_CONNECTOR))
> + drm_connector_cleanup(&pdata->connector);
I wonder if we actually need this. The connector gets attached to the
encoder, won't it be destroyed by the DRM core in the error path ?
> err_conn_init:
> drm_dp_aux_unregister(&pdata->aux);
> return ret;
> @@ -792,9 +790,30 @@ static void ti_sn_bridge_set_dsi_rate(struct
> ti_sn65dsi86 *pdata)
> regmap_write(pdata->regmap, SN_DSIA_CLK_FREQ_REG, val);
> }
>
> +/*
> + * Find the connector and fish out the bpc from display_info. It would
> + * be nice if we could get this instead from drm_bridge_state, but that
> + * doesn't yet appear to be the case.
You already have a bus format in the bridge state, from which you can
derive the bpp. Could you give it a try ?
> + */
> static unsigned int ti_sn_bridge_get_bpp(struct ti_sn65dsi86 *pdata)
> {
> - if (pdata->connector.display_info.bpc <= 6)
> + struct drm_bridge *bridge = &pdata->bridge;
> + struct drm_connector_list_iter conn_iter;
> + struct drm_connector *connector;
> + unsigned bpc = 0;
> +
> + drm_connector_list_iter_begin(bridge->dev, &conn_iter);
> + drm_for_each_connector_iter(connector, &conn_iter) {
> + if (drm_connector_has_possible_encoder(connector,
> bridge->encoder)) {
> + bpc = connector->display_info.bpc;
> + break;
> + }
> + }
> + drm_connector_list_iter_end(&conn_iter);
> +
> + WARN_ON(bpc == 0);
> +
> + if (bpc <= 6)
> return 18;
> else
> return 24;
--
Regards,
Laurent Pinchart
Re: [Freedreno] [PATCH 4/4] drm/bridge: ti-sn65dsi86: Add NO_CONNECTOR support
Hi Rob and Doug, On Mon, Sep 20, 2021 at 11:32:02AM -0700, Rob Clark wrote: > On Thu, Aug 12, 2021 at 1:08 PM Doug Anderson wrote: > > On Thu, Aug 12, 2021 at 12:26 PM Laurent Pinchart wrote: > > > On Wed, Aug 11, 2021 at 04:52:50PM -0700, Rob Clark wrote: > > > > From: Rob Clark > > > > > > > > Slightly awkward to fish out the display_info when we aren't creating > > > > own connector. But I don't see an obvious better way. > > > > > > We need a bit more than this, to support the NO_CONNECTOR case, the > > > bridge has to implement a few extra operations, and set the bridge .ops > > > field. I've submitted two patches to do so a while ago: > > > > > > - [RFC PATCH 08/11] drm/bridge: ti-sn65dsi86: Implement bridge connector > > > operations ([1]) > > > > Rob asked me about this over IRC, so if he left it out and it's needed > > then it's my fault. However, I don't believe it's needed until your > > series making this bridge chip support full DP. For the the eDP case > > the bridge chip driver in ToT no longer queries the EDID itself. It > > simply provides an AUX bus to the panel driver and the panel driver > > queries the EDID. I think that means we don't need to add > > DRM_BRIDGE_OP_EDID, right? That's right. > > I was also wondering if in the full DP case we should actually model > > the physical DP jack as a drm_bridge and have it work the same way. It > > would get probed via the DP AUX bus just like a panel. I seem to > > remember Stephen Boyd was talking about modeling the DP connector as a > > drm_bridge because it would allow us to handle the fact that some TCPC > > chips could only support HBR2 whereas others could support HBR3. Maybe > > it would end up being a fairly elegant solution? Physical connectors are already handled as bridges, see drivers/gpu/drm/bridge/display-connector.c. I however don't think it should handle EDID retrieval, because that's really not an operation implemented by the connector itself. > > > - [RFC PATCH 09/11] drm/bridge: ti-sn65dsi86: Make connector creation > > > optional ([2]) > > > > > > The second patch is similar to the first half of this patch, but misses > > > the cleanup code. I'll try to rebase this and resubmit, but it may take > > > a bit of time. > > > > Whoops! You're right that Rob's patch won't work at all because we'll > > just hit the "Fix bridge driver to make connector optional!" case. I > > should have noticed that. :( > > Yes, indeed.. once I fix that, I get no display.. > > Not sure if Laurent is still working on his series, otherwise I can > try to figure out what bridge ops are missing I am, but too slowly. I don't mind fast-tracking the changes you need though. -- Regards, Laurent Pinchart
Re: [Freedreno] [PATCH v2 2/3] drm/bridge: ti-sn65dsi86: Implement bridge->mode_valid()
Hi Rob,
Thank you for the patch.
On Mon, Sep 20, 2021 at 03:57:59PM -0700, Rob Clark wrote:
> From: Rob Clark
>
> For the brave new world of bridges not creating their own connectors, we
> need to implement the max clock limitation via bridge->mode_valid()
> instead of connector->mode_valid().
>
> v2: Drop unneeded connector->mode_valid()
>
> Signed-off-by: Rob Clark
> Reviewed-by: Douglas Anderson
Reviewed-by: Laurent Pinchart
> ---
> drivers/gpu/drm/bridge/ti-sn65dsi86.c | 25 +
> 1 file changed, 13 insertions(+), 12 deletions(-)
>
> diff --git a/drivers/gpu/drm/bridge/ti-sn65dsi86.c
> b/drivers/gpu/drm/bridge/ti-sn65dsi86.c
> index 41d48a393e7f..6154bed0af5b 100644
> --- a/drivers/gpu/drm/bridge/ti-sn65dsi86.c
> +++ b/drivers/gpu/drm/bridge/ti-sn65dsi86.c
> @@ -615,20 +615,8 @@ static int ti_sn_bridge_connector_get_modes(struct
> drm_connector *connector)
> return drm_bridge_get_modes(pdata->next_bridge, connector);
> }
>
> -static enum drm_mode_status
> -ti_sn_bridge_connector_mode_valid(struct drm_connector *connector,
> - struct drm_display_mode *mode)
> -{
> - /* maximum supported resolution is 4K at 60 fps */
> - if (mode->clock > 594000)
> - return MODE_CLOCK_HIGH;
> -
> - return MODE_OK;
> -}
> -
> static struct drm_connector_helper_funcs ti_sn_bridge_connector_helper_funcs
> = {
> .get_modes = ti_sn_bridge_connector_get_modes,
> - .mode_valid = ti_sn_bridge_connector_mode_valid,
> };
>
> static const struct drm_connector_funcs ti_sn_bridge_connector_funcs = {
> @@ -766,6 +754,18 @@ static void ti_sn_bridge_detach(struct drm_bridge
> *bridge)
> drm_dp_aux_unregister(&bridge_to_ti_sn65dsi86(bridge)->aux);
> }
>
> +static enum drm_mode_status
> +ti_sn_bridge_mode_valid(struct drm_bridge *bridge,
> + const struct drm_display_info *info,
> + const struct drm_display_mode *mode)
> +{
> + /* maximum supported resolution is 4K at 60 fps */
> + if (mode->clock > 594000)
> + return MODE_CLOCK_HIGH;
> +
> + return MODE_OK;
> +}
> +
> static void ti_sn_bridge_disable(struct drm_bridge *bridge)
> {
> struct ti_sn65dsi86 *pdata = bridge_to_ti_sn65dsi86(bridge);
> @@ -1127,6 +1127,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,
> + .mode_valid = ti_sn_bridge_mode_valid,
> .pre_enable = ti_sn_bridge_pre_enable,
> .enable = ti_sn_bridge_enable,
> .disable = ti_sn_bridge_disable,
--
Regards,
Laurent Pinchart
Re: [Freedreno] [PATCH 4/4] drm/bridge: ti-sn65dsi86: Add NO_CONNECTOR support
Hi Rob,
Thank you for the patch.
On Wed, Aug 11, 2021 at 04:52:50PM -0700, Rob Clark wrote:
> From: Rob Clark
>
> Slightly awkward to fish out the display_info when we aren't creating
> own connector. But I don't see an obvious better way.
We need a bit more than this, to support the NO_CONNECTOR case, the
bridge has to implement a few extra operations, and set the bridge .ops
field. I've submitted two patches to do so a while ago:
- [RFC PATCH 08/11] drm/bridge: ti-sn65dsi86: Implement bridge connector
operations ([1])
- [RFC PATCH 09/11] drm/bridge: ti-sn65dsi86: Make connector creation optional
([2])
The second patch is similar to the first half of this patch, but misses
the cleanup code. I'll try to rebase this and resubmit, but it may take
a bit of time.
[1]
https://lore.kernel.org/dri-devel/20210322030128.2283-9-laurent.pinchart+rene...@ideasonboard.com/
[2]
https://lore.kernel.org/dri-devel/20210322030128.2283-10-laurent.pinchart+rene...@ideasonboard.com/
> Signed-off-by: Rob Clark
> ---
> drivers/gpu/drm/bridge/ti-sn65dsi86.c | 34 +++
> 1 file changed, 29 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/gpu/drm/bridge/ti-sn65dsi86.c
> b/drivers/gpu/drm/bridge/ti-sn65dsi86.c
> index 38dcc49eccaf..dc8112bab3d3 100644
> --- a/drivers/gpu/drm/bridge/ti-sn65dsi86.c
> +++ b/drivers/gpu/drm/bridge/ti-sn65dsi86.c
> @@ -693,9 +693,11 @@ static int ti_sn_bridge_attach(struct drm_bridge *bridge,
> return ret;
> }
>
> - ret = ti_sn_bridge_connector_init(pdata);
> - if (ret < 0)
> - goto err_conn_init;
> + if (!(flags & DRM_BRIDGE_ATTACH_NO_CONNECTOR)) {
> + ret = ti_sn_bridge_connector_init(pdata);
> + if (ret < 0)
> + goto err_conn_init;
> + }
>
> /*
>* TODO: ideally finding host resource and dsi dev registration needs
> @@ -757,7 +759,8 @@ static int ti_sn_bridge_attach(struct drm_bridge *bridge,
> err_dsi_attach:
> mipi_dsi_device_unregister(dsi);
> err_dsi_host:
> - drm_connector_cleanup(&pdata->connector);
> + if (!(flags & DRM_BRIDGE_ATTACH_NO_CONNECTOR))
> + drm_connector_cleanup(&pdata->connector);
> err_conn_init:
> drm_dp_aux_unregister(&pdata->aux);
> return ret;
> @@ -806,9 +809,30 @@ static void ti_sn_bridge_set_dsi_rate(struct
> ti_sn65dsi86 *pdata)
> regmap_write(pdata->regmap, SN_DSIA_CLK_FREQ_REG, val);
> }
>
> +/*
> + * Find the connector and fish out the bpc from display_info. It would
> + * be nice if we could get this instead from drm_bridge_state, but that
> + * doesn't yet appear to be the case.
> + */
This should be done with
struct drm_atomic_state *state = old_bridge_state->base.state;
struct drm_connector *connector;
connector = drm_atomic_get_new_connector_for_encoder(state,
bridge->encoder);
> static unsigned int ti_sn_bridge_get_bpp(struct ti_sn65dsi86 *pdata)
> {
> - if (pdata->connector.display_info.bpc <= 6)
> + struct drm_bridge *bridge = &pdata->bridge;
> + struct drm_connector_list_iter conn_iter;
> + struct drm_connector *connector;
> + unsigned bpc = 0;
> +
> + drm_connector_list_iter_begin(bridge->dev, &conn_iter);
> + drm_for_each_connector_iter(connector, &conn_iter) {
> + if (drm_connector_has_possible_encoder(connector,
> bridge->encoder)) {
> + bpc = connector->display_info.bpc;
> + break;
> + }
> + }
> + drm_connector_list_iter_end(&conn_iter);
> +
> + WARN_ON(bpc == 0);
> +
> + if (bpc <= 6)
> return 18;
> else
> return 24;
--
Regards,
Laurent Pinchart
Re: [Freedreno] [PATCH 3/4] drm/bridge: ti-sn65dsi86: Implement bridge->mode_valid()
Hi Rob,
On Thu, Aug 12, 2021 at 12:09:12PM -0700, Rob Clark wrote:
> On Thu, Aug 12, 2021 at 11:44 AM Laurent Pinchart wrote:
> > On Wed, Aug 11, 2021 at 04:52:49PM -0700, Rob Clark wrote:
> > > From: Rob Clark
> > >
> > > For the brave new world of bridges not creating their own connectors, we
> > > need to implement the max clock limitation via bridge->mode_valid()
> > > instead of connector->mode_valid().
> > >
> > > Signed-off-by: Rob Clark
> > > ---
> > > drivers/gpu/drm/bridge/ti-sn65dsi86.c | 24 +++-
> > > 1 file changed, 19 insertions(+), 5 deletions(-)
> > >
> > > diff --git a/drivers/gpu/drm/bridge/ti-sn65dsi86.c
> > > b/drivers/gpu/drm/bridge/ti-sn65dsi86.c
> > > index 5d3b30b2f547..38dcc49eccaf 100644
> > > --- a/drivers/gpu/drm/bridge/ti-sn65dsi86.c
> > > +++ b/drivers/gpu/drm/bridge/ti-sn65dsi86.c
> > > @@ -595,6 +595,15 @@ static struct auxiliary_driver ti_sn_aux_driver = {
> > > .id_table = ti_sn_aux_id_table,
> > > };
> > >
> > > +static enum drm_mode_status check_mode(const struct drm_display_mode
> > > *mode)
> > > +{
> > > + /* maximum supported resolution is 4K at 60 fps */
> > > + if (mode->clock > 594000)
> > > + return MODE_CLOCK_HIGH;
> > > +
> > > + return MODE_OK;
> > > +}
> > > +
> > > /*
> > > -
> > > * DRM Connector Operations
> > > */
> > > @@ -616,11 +625,7 @@ static enum drm_mode_status
> > > ti_sn_bridge_connector_mode_valid(struct drm_connector *connector,
> > > struct drm_display_mode *mode)
> > > {
> > > - /* maximum supported resolution is 4K at 60 fps */
> > > - if (mode->clock > 594000)
> > > - return MODE_CLOCK_HIGH;
> > > -
> > > - return MODE_OK;
> > > + return check_mode(mode);
> >
> > Do we need to implement the connector .mode_valid() operation, given
> > that the bridge is linked in the chain ?
>
> My understanding is that we need to keep it for display drivers that
> are not converted to NO_CONNECTOR..
>
> But AFAIK snapdragon is the only upstream user of this bridge, so
> after the drm/msm/dsi patch lands we could probably garbage collect
> the connector support.
Even in the !NO_CONNECTOR case, the bridge will still be linked in the
chain, so the atomic helpers should call the bridge .mode_valid() in
addition to the connector .mode_valid(). I think the connector operation
is redundant.
> > > }
> > >
> > > static struct drm_connector_helper_funcs
> > > ti_sn_bridge_connector_helper_funcs = {
> > > @@ -763,6 +768,14 @@ static void ti_sn_bridge_detach(struct drm_bridge
> > > *bridge)
> > > drm_dp_aux_unregister(&bridge_to_ti_sn65dsi86(bridge)->aux);
> > > }
> > >
> > > +static enum drm_mode_status
> > > +ti_sn_bridge_mode_valid(struct drm_bridge *bridge,
> > > + const struct drm_display_info *info,
> > > + const struct drm_display_mode *mode)
> > > +{
> > > + return check_mode(mode);
> > > +}
> > > +
> > > static void ti_sn_bridge_disable(struct drm_bridge *bridge)
> > > {
> > > struct ti_sn65dsi86 *pdata = bridge_to_ti_sn65dsi86(bridge);
> > > @@ -1118,6 +1131,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,
> > > + .mode_valid = ti_sn_bridge_mode_valid,
> > > .pre_enable = ti_sn_bridge_pre_enable,
> > > .enable = ti_sn_bridge_enable,
> > > .disable = ti_sn_bridge_disable,
--
Regards,
Laurent Pinchart
Re: [Freedreno] [PATCH 3/4] drm/bridge: ti-sn65dsi86: Implement bridge->mode_valid()
Hi Rob,
Thank you for the patch.
On Wed, Aug 11, 2021 at 04:52:49PM -0700, Rob Clark wrote:
> From: Rob Clark
>
> For the brave new world of bridges not creating their own connectors, we
> need to implement the max clock limitation via bridge->mode_valid()
> instead of connector->mode_valid().
>
> Signed-off-by: Rob Clark
> ---
> drivers/gpu/drm/bridge/ti-sn65dsi86.c | 24 +++-
> 1 file changed, 19 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/gpu/drm/bridge/ti-sn65dsi86.c
> b/drivers/gpu/drm/bridge/ti-sn65dsi86.c
> index 5d3b30b2f547..38dcc49eccaf 100644
> --- a/drivers/gpu/drm/bridge/ti-sn65dsi86.c
> +++ b/drivers/gpu/drm/bridge/ti-sn65dsi86.c
> @@ -595,6 +595,15 @@ static struct auxiliary_driver ti_sn_aux_driver = {
> .id_table = ti_sn_aux_id_table,
> };
>
> +static enum drm_mode_status check_mode(const struct drm_display_mode *mode)
> +{
> + /* maximum supported resolution is 4K at 60 fps */
> + if (mode->clock > 594000)
> + return MODE_CLOCK_HIGH;
> +
> + return MODE_OK;
> +}
> +
> /*
> -
> * DRM Connector Operations
> */
> @@ -616,11 +625,7 @@ static enum drm_mode_status
> ti_sn_bridge_connector_mode_valid(struct drm_connector *connector,
> struct drm_display_mode *mode)
> {
> - /* maximum supported resolution is 4K at 60 fps */
> - if (mode->clock > 594000)
> - return MODE_CLOCK_HIGH;
> -
> - return MODE_OK;
> + return check_mode(mode);
Do we need to implement the connector .mode_valid() operation, given
that the bridge is linked in the chain ?
> }
>
> static struct drm_connector_helper_funcs ti_sn_bridge_connector_helper_funcs
> = {
> @@ -763,6 +768,14 @@ static void ti_sn_bridge_detach(struct drm_bridge
> *bridge)
> drm_dp_aux_unregister(&bridge_to_ti_sn65dsi86(bridge)->aux);
> }
>
> +static enum drm_mode_status
> +ti_sn_bridge_mode_valid(struct drm_bridge *bridge,
> + const struct drm_display_info *info,
> + const struct drm_display_mode *mode)
> +{
> + return check_mode(mode);
> +}
> +
> static void ti_sn_bridge_disable(struct drm_bridge *bridge)
> {
> struct ti_sn65dsi86 *pdata = bridge_to_ti_sn65dsi86(bridge);
> @@ -1118,6 +1131,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,
> + .mode_valid = ti_sn_bridge_mode_valid,
> .pre_enable = ti_sn_bridge_pre_enable,
> .enable = ti_sn_bridge_enable,
> .disable = ti_sn_bridge_disable,
--
Regards,
Laurent Pinchart
Re: [Freedreno] [PATCH 2/4] drm/msm/dsi: Support NO_CONNECTOR bridges
Hi Rob
Thank you for the patch.
On Wed, Aug 11, 2021 at 04:52:48PM -0700, Rob Clark wrote:
> From: Rob Clark
>
> For now, since we have a mix of bridges which support this flag, which
> which do *not* support this flag, or work both ways, try it once with
> NO_CONNECTOR and then fall back to the old way if that doesn't work.
> Eventually we can drop the fallback path.
>
> Signed-off-by: Rob Clark
> ---
> drivers/gpu/drm/msm/Kconfig | 2 ++
> drivers/gpu/drm/msm/dsi/dsi_manager.c | 41 ++-
> 2 files changed, 30 insertions(+), 13 deletions(-)
>
> diff --git a/drivers/gpu/drm/msm/Kconfig b/drivers/gpu/drm/msm/Kconfig
> index e9c6af78b1d7..36e5ba3ccc28 100644
> --- a/drivers/gpu/drm/msm/Kconfig
> +++ b/drivers/gpu/drm/msm/Kconfig
> @@ -14,6 +14,8 @@ config DRM_MSM
> select REGULATOR
> select DRM_KMS_HELPER
> select DRM_PANEL
> + select DRM_BRIDGE
> + select DRM_PANEL_BRIDGE
> select DRM_SCHED
> select SHMEM
> select TMPFS
> diff --git a/drivers/gpu/drm/msm/dsi/dsi_manager.c
> b/drivers/gpu/drm/msm/dsi/dsi_manager.c
> index c41d39f5b7cf..1fd1cf93abbf 100644
> --- a/drivers/gpu/drm/msm/dsi/dsi_manager.c
> +++ b/drivers/gpu/drm/msm/dsi/dsi_manager.c
> @@ -3,6 +3,8 @@
> * Copyright (c) 2015, The Linux Foundation. All rights reserved.
> */
>
> +#include "drm/drm_bridge_connector.h"
> +
> #include "msm_kms.h"
> #include "dsi.h"
>
> @@ -690,8 +692,7 @@ struct drm_connector *msm_dsi_manager_ext_bridge_init(u8
> id)
> struct drm_device *dev = msm_dsi->dev;
> struct drm_encoder *encoder;
> struct drm_bridge *int_bridge, *ext_bridge;
> - struct drm_connector *connector;
> - struct list_head *connector_list;
> + int ret;
>
> int_bridge = msm_dsi->bridge;
> ext_bridge = msm_dsi->external_bridge =
> @@ -699,22 +700,36 @@ struct drm_connector
> *msm_dsi_manager_ext_bridge_init(u8 id)
>
> encoder = msm_dsi->encoder;
>
> - /* link the internal dsi bridge to the external bridge */
> - drm_bridge_attach(encoder, ext_bridge, int_bridge, 0);
> -
> /*
> - * we need the drm_connector created by the external bridge
> - * driver (or someone else) to feed it to our driver's
> - * priv->connector[] list, mainly for msm_fbdev_init()
> + * Try first to create the bridge without it creating it's own
s/it's/its/
> + * connector.. currently some bridges support this, and others
> + * do not (and some support both modes)
>*/
> - connector_list = &dev->mode_config.connector_list;
> + ret = drm_bridge_attach(encoder, ext_bridge, int_bridge,
> + DRM_BRIDGE_ATTACH_NO_CONNECTOR);
Should all this be moved one layer up, to the code that attaches to the
mem_dsi->bridge ? I suppose we can start here, but as part of a global
move to bridges and DRM_BRIDGE_ATTACH_NO_CONNECTOR, I think the
top-level would make more sense in the long term.
If you want to start here,
Reviewed-by: Laurent Pinchart
> + if (ret == -EINVAL) {
> + struct drm_connector *connector;
> + struct list_head *connector_list;
> +
> + /* link the internal dsi bridge to the external bridge */
> + drm_bridge_attach(encoder, ext_bridge, int_bridge, 0);
> +
> + /*
> + * we need the drm_connector created by the external bridge
> + * driver (or someone else) to feed it to our driver's
> + * priv->connector[] list, mainly for msm_fbdev_init()
> + */
> + connector_list = &dev->mode_config.connector_list;
> +
> + list_for_each_entry(connector, connector_list, head) {
> + if (drm_connector_has_possible_encoder(connector,
> encoder))
> + return connector;
> + }
>
> - list_for_each_entry(connector, connector_list, head) {
> - if (drm_connector_has_possible_encoder(connector, encoder))
> - return connector;
> + return ERR_PTR(-ENODEV);
> }
>
> - return ERR_PTR(-ENODEV);
> + return drm_bridge_connector_init(dev, encoder);
> }
>
> void msm_dsi_manager_bridge_destroy(struct drm_bridge *bridge)
--
Regards,
Laurent Pinchart
Re: [Freedreno] [PATCH 1/4] drm/bridge: ti-sn65dsi86: Avoid creating multiple connectors
Hi Rob,
Thank you for the patch.
On Wed, Aug 11, 2021 at 04:52:47PM -0700, Rob Clark wrote:
> From: Rob Clark
>
> If we created our own connector because the driver does not support the
> NO_CONNECTOR flag, we don't want the downstream bridge to *also* create
> a connector. And if this driver did pass the NO_CONNECTOR flag (and we
> supported that mode) this would change nothing.
>
> Fixes: 4e5763f03e10 ("drm/bridge: ti-sn65dsi86: Wrap panel with panel-bridge")
> Signed-off-by: Rob Clark
Makes complete sense.
Reviewed-by: Laurent Pinchart
> ---
> drivers/gpu/drm/bridge/ti-sn65dsi86.c | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/drivers/gpu/drm/bridge/ti-sn65dsi86.c
> b/drivers/gpu/drm/bridge/ti-sn65dsi86.c
> index 9bf889302bcc..5d3b30b2f547 100644
> --- a/drivers/gpu/drm/bridge/ti-sn65dsi86.c
> +++ b/drivers/gpu/drm/bridge/ti-sn65dsi86.c
> @@ -736,6 +736,9 @@ static int ti_sn_bridge_attach(struct drm_bridge *bridge,
> }
> pdata->dsi = dsi;
>
> + /* We never want the next bridge to *also* create a connector: */
> + flags |= DRM_BRIDGE_ATTACH_NO_CONNECTOR;
> +
> /* Attach the next bridge */
> ret = drm_bridge_attach(bridge->encoder, pdata->next_bridge,
> &pdata->bridge, flags);
--
Regards,
Laurent Pinchart
Re: [Freedreno] [v8 4/6] drm/panel-simple: Update validation warnings for eDP panel description
Hi Doug,
On Mon, Jun 28, 2021 at 08:34:04AM -0700, Doug Anderson wrote:
> On Mon, Jun 28, 2021 at 6:33 AM Laurent Pinchart wrote:
> > On Mon, Jun 28, 2021 at 05:46:24PM +0530, rajee...@codeaurora.org wrote:
> > > On 27-06-2021 23:48, Laurent Pinchart wrote:
> > > > On Sat, Jun 26, 2021 at 10:21:06PM +0530, Rajeev Nandan wrote:
> > > >> Do not give a warning for the eDP panels if the "bus_format" is
> > > >> not specified, since most eDP panels can support more than one
> > > >> bus formats and this can be auto-detected.
> > > >> Also, update the check to include bpc=10 for the eDP panel.
> > > >>
> > > >> Signed-off-by: Rajeev Nandan
> > > >> ---
> > > >>
> > > >> Changes in v8:
> > > >> - New patch, to address the review comments of Sam Ravnborg [1]
> > > >>
> > > >> [1]
> > > >> https://lore.kernel.org/dri-devel/20210621184157.gb918...@ravnborg.org/
> > > >>
> > > >> drivers/gpu/drm/panel/panel-simple.c | 6 ++
> > > >> 1 file changed, 2 insertions(+), 4 deletions(-)
> > > >>
> > > >> diff --git a/drivers/gpu/drm/panel/panel-simple.c
> > > >> b/drivers/gpu/drm/panel/panel-simple.c
> > > >> index 86e5a45..f966b562 100644
> > > >> --- a/drivers/gpu/drm/panel/panel-simple.c
> > > >> +++ b/drivers/gpu/drm/panel/panel-simple.c
> > > >> @@ -772,10 +772,8 @@ static int panel_simple_probe(struct device *dev,
> > > >> const struct panel_desc *desc,
> > > >>desc->bpc != 8);
> > > >>break;
> > > >>case DRM_MODE_CONNECTOR_eDP:
> > > >> - if (desc->bus_format == 0)
> > > >> - dev_warn(dev, "Specify missing bus_format\n");
> > > >> - if (desc->bpc != 6 && desc->bpc != 8)
> > > >> - dev_warn(dev, "Expected bpc in {6,8} but got:
> > > >> %u\n", desc->bpc);
> > > >> + if (desc->bpc != 6 && desc->bpc != 8 && desc->bpc != 10)
> > > >> + dev_warn(dev, "Expected bpc in {6,8,10} but got:
> > > >> %u\n", desc->bpc);
> > > >
> > > > You'll still get a warning is bpc == 0, is that intentional ?
> > >
> > > This was not intentional, I missed considering bpc=0 case. As we are
> > > removing the warning for bus_format=0 then a similar thing can be done
> > > for the bpc=0 also. The bpc value should be a valid one if it is
> > > specified. Unlike the bus_format, bpc has few possible values that can
> > > be checked here along with 0. Please correct me if I misunderstood the
> > > concept.
> > > I will fix this.
> >
> > What's the point of specifying bpc if it's optional though ? Users of
> > the panel will need to support the case where bpc is set to 0. Have you
> > ensured that they all do ? Can they meaningfully use the bpc value if
> > they need to be ready to support bpc == 0 ?
>
> I must be missing something, but to me it seems like Rajeev's patch is
> fine as-is. From my reading of the code:
>
> * Removes the warning if bus_format == 0. This is correct since I
> don't think specifying bus format for eDP panels makes lots of sense.
This is embarassing, I've been reading it as desc->bpc == 0 from the
beginning :-( My bad. The bpc change is correct.
> * Removes the warning if bpc == 10. This is correct since we've seen
> eDP panels with 10bpc.
>
> * Keeps the warning if bpc == 0. IMO we can/should still require
> panels to specify their BPC. I guess I'm treating this as a "max BPC".
> I know that we use this field in the sn65dsi86 driver, so if it's OK
> for this to be 0 then we'll have to change that driver to handle it.
>
> Does that sound right to you Laurent? So since I think Rajeev's patch
> is OK, I'm happy with:
>
> Reviewed-by: Douglas Anderson
>
> Unless I missed something and this patch needs to change then it feels
> like Rajeev's patch series is in pretty good shape to land. I'm happy
> to commit it but since Sam made comments on the previous version I'd
> plan to wait a bit to make sure he has a chance for another look if he
> wants to. I've also only got 2 days left before I vanish for 1 week of
> vacation. ...so my plan is:
> * If Sam / Laurent come back before tomorrow and say they're happy
> then I'll commit.
> * If I hear nothing then I'll check back after my vacation. If someone
> else has committed then I'll be happy. If not and there has just been
> silence then I'll commit it myself.
>
> Please yell if that's not OK. :-)
--
Regards,
Laurent Pinchart
___
Freedreno mailing list
Freedreno@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/freedreno
Re: [Freedreno] [v8 4/6] drm/panel-simple: Update validation warnings for eDP panel description
Hi Rajeev,
On Mon, Jun 28, 2021 at 05:46:24PM +0530, rajee...@codeaurora.org wrote:
> On 27-06-2021 23:48, Laurent Pinchart wrote:
> > On Sat, Jun 26, 2021 at 10:21:06PM +0530, Rajeev Nandan wrote:
> >> Do not give a warning for the eDP panels if the "bus_format" is
> >> not specified, since most eDP panels can support more than one
> >> bus formats and this can be auto-detected.
> >> Also, update the check to include bpc=10 for the eDP panel.
> >>
> >> Signed-off-by: Rajeev Nandan
> >> ---
> >>
> >> Changes in v8:
> >> - New patch, to address the review comments of Sam Ravnborg [1]
> >>
> >> [1]
> >> https://lore.kernel.org/dri-devel/20210621184157.gb918...@ravnborg.org/
> >>
> >> drivers/gpu/drm/panel/panel-simple.c | 6 ++
> >> 1 file changed, 2 insertions(+), 4 deletions(-)
> >>
> >> diff --git a/drivers/gpu/drm/panel/panel-simple.c
> >> b/drivers/gpu/drm/panel/panel-simple.c
> >> index 86e5a45..f966b562 100644
> >> --- a/drivers/gpu/drm/panel/panel-simple.c
> >> +++ b/drivers/gpu/drm/panel/panel-simple.c
> >> @@ -772,10 +772,8 @@ static int panel_simple_probe(struct device *dev,
> >> const struct panel_desc *desc,
> >>desc->bpc != 8);
> >>break;
> >>case DRM_MODE_CONNECTOR_eDP:
> >> - if (desc->bus_format == 0)
> >> - dev_warn(dev, "Specify missing bus_format\n");
> >> - if (desc->bpc != 6 && desc->bpc != 8)
> >> - dev_warn(dev, "Expected bpc in {6,8} but got: %u\n",
> >> desc->bpc);
> >> + if (desc->bpc != 6 && desc->bpc != 8 && desc->bpc != 10)
> >> + dev_warn(dev, "Expected bpc in {6,8,10} but got: %u\n",
> >> desc->bpc);
> >
> > You'll still get a warning is bpc == 0, is that intentional ?
>
> This was not intentional, I missed considering bpc=0 case. As we are
> removing the warning for bus_format=0 then a similar thing can be done
> for the bpc=0 also. The bpc value should be a valid one if it is
> specified. Unlike the bus_format, bpc has few possible values that can
> be checked here along with 0. Please correct me if I misunderstood the
> concept.
> I will fix this.
What's the point of specifying bpc if it's optional though ? Users of
the panel will need to support the case where bpc is set to 0. Have you
ensured that they all do ? Can they meaningfully use the bpc value if
they need to be ready to support bpc == 0 ?
--
Regards,
Laurent Pinchart
___
Freedreno mailing list
Freedreno@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/freedreno
Re: [Freedreno] [v8 4/6] drm/panel-simple: Update validation warnings for eDP panel description
Hi Rajeev,
On Sat, Jun 26, 2021 at 10:21:06PM +0530, Rajeev Nandan wrote:
> Do not give a warning for the eDP panels if the "bus_format" is
> not specified, since most eDP panels can support more than one
> bus formats and this can be auto-detected.
> Also, update the check to include bpc=10 for the eDP panel.
>
> Signed-off-by: Rajeev Nandan
> ---
>
> Changes in v8:
> - New patch, to address the review comments of Sam Ravnborg [1]
>
> [1] https://lore.kernel.org/dri-devel/20210621184157.gb918...@ravnborg.org/
>
> drivers/gpu/drm/panel/panel-simple.c | 6 ++
> 1 file changed, 2 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/panel/panel-simple.c
> b/drivers/gpu/drm/panel/panel-simple.c
> index 86e5a45..f966b562 100644
> --- a/drivers/gpu/drm/panel/panel-simple.c
> +++ b/drivers/gpu/drm/panel/panel-simple.c
> @@ -772,10 +772,8 @@ static int panel_simple_probe(struct device *dev, const
> struct panel_desc *desc,
> desc->bpc != 8);
> break;
> case DRM_MODE_CONNECTOR_eDP:
> - if (desc->bus_format == 0)
> - dev_warn(dev, "Specify missing bus_format\n");
> - if (desc->bpc != 6 && desc->bpc != 8)
> - dev_warn(dev, "Expected bpc in {6,8} but got: %u\n",
> desc->bpc);
> + if (desc->bpc != 6 && desc->bpc != 8 && desc->bpc != 10)
> + dev_warn(dev, "Expected bpc in {6,8,10} but got: %u\n",
> desc->bpc);
You'll still get a warning is bpc == 0, is that intentional ?
> break;
> case DRM_MODE_CONNECTOR_DSI:
> if (desc->bpc != 6 && desc->bpc != 8)
--
Regards,
Laurent Pinchart
___
Freedreno mailing list
Freedreno@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/freedreno
Re: [Freedreno] [PATCH v3 2/3] dt-bindings: msm: dsi: document phy-type property for 7nm dsi phy
Hi Jonathan,
Thank you for the patch.
On Tue, Jun 08, 2021 at 03:53:28PM -0400, Jonathan Marek wrote:
> Document a new phy-type property which will be used to determine whether
> the phy should operate in D-PHY or C-PHY mode.
>
> Signed-off-by: Jonathan Marek
> ---
> .../devicetree/bindings/display/msm/dsi-phy-7nm.yaml | 4
> include/dt-bindings/phy/phy.h | 2 ++
> 2 files changed, 6 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/display/msm/dsi-phy-7nm.yaml
> b/Documentation/devicetree/bindings/display/msm/dsi-phy-7nm.yaml
> index bf16b1c65e10..d447b517ea19 100644
> --- a/Documentation/devicetree/bindings/display/msm/dsi-phy-7nm.yaml
> +++ b/Documentation/devicetree/bindings/display/msm/dsi-phy-7nm.yaml
> @@ -34,6 +34,10 @@ properties:
> description: |
>Connected to VDD_A_DSI_PLL_0P9 pin (or VDDA_DSI{0,1}_PLL_0P9 for
> sm8150)
>
> + phy-type:
> +description: |
> + D-PHY (default) or C-PHY mode: PHY_TYPE_DSI_DPHY or PHY_TYPE_DSI_CPHY
> +
> required:
>- compatible
>- reg
> diff --git a/include/dt-bindings/phy/phy.h b/include/dt-bindings/phy/phy.h
> index 887a31b250a8..b978dac16bb8 100644
> --- a/include/dt-bindings/phy/phy.h
> +++ b/include/dt-bindings/phy/phy.h
> @@ -20,5 +20,7 @@
> #define PHY_TYPE_XPCS7
> #define PHY_TYPE_SGMII 8
> #define PHY_TYPE_QSGMII 9
> +#define PHY_TYPE_DSI_DPHY10
> +#define PHY_TYPE_DSI_CPHY11
The MIPI D-PHY and C-PHY apply to both DSI and CSI. I'd name this
PHY_TYPE_DPHY and PHY_TYPE_CPHY, or possibly, PHY_TYPE_MIPI_DPHY and
PHY_TYPE_MIPI_CPHY, without a DSI prefix. With this addressed and the DT
bindings updated accordingly,
Reviewed-by: Laurent Pinchart
(You may be asked to split this in two patches though, not sure)
> #endif /* _DT_BINDINGS_PHY */
--
Regards,
Laurent Pinchart
___
Freedreno mailing list
Freedreno@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/freedreno
Re: [Freedreno] [v3 1/2] dt-bindings: backlight: add DisplayPort aux backlight
.org/r/87zgxl5qar@intel.com
> >> >
> >> > ...but you're right that it makes sense not to model the backlight as
> >> > a separate node in the device tree. The panel driver can handle
> >> > setting up the backlight.
> >>
> >> It was not a good idea to create a separate backlight driver and use
> >> ddc-i2c-bus to get access to DP aux. I am working to move the code
> >> to the panel driver and to utilize the new DRM helper functions
> >> (drm_edp_backlight_*) Lyude has added [1].
> >>
> >> To use these helper functions, the panel driver should have access to the
> >> "struct drm_dp_aux *". The simple-panel has a "ddc-i2c-bus" property
> >> to give the panel access to the DDC bus and is currently being used to
> >> get the EDID from the panel. Can I use the same ddc bus i2c_adapter to get
> >> the "struct drm_dp_aux *"?
> >>
> >> As per the suggestion [2], I get the "struct drm_dp_aux *" from the
> >> i2c_adapter of ddc bus (maybe I didn't understand the suggestion
> >> correctly),
> >> and, it turned out, the way I have implemented is not the right way [3].
> >> So, I am afraid to use the same method in the panel driver.
> >>
> >>
> >> [1] https://lore.kernel.org/dri-devel/871rb5bcf9@intel.com/
> >> [2] https://www.spinics.net/lists/dri-devel/msg295429.html
> >> [3]
> >> https://lore.kernel.org/dri-devel/2021042616.4lc3ekxjugjr3...@maple.lan/
> >
> > So it's definitely up to maintainers, not me. ...but I guess I would
> > have expected something like a new property called "ddc-aux-bus". Then
> > you'd have to create a new API call called something like
> > "of_find_ddc_aux_adapter_by_node()" that would allow you to find it.
>
> To implement the first suggestion, I can think of the following way
> to get the "struct drm_dp_aux" in the panel_simple_probe function:
>
> - Create a new panel-simple DT property "ddc-aux-bus", a phandle to the
> platform device that implements the AUX channel.
>
> - Create a global list of drm_dp_aux in drm_dp_helper.c. Initialize list
> head
> in drm_dp_aux_init(), add the drm_dp_aux onto the list in
> drm_dp_aux_register().
> Similarly, remove the drm_dp_aux from list in drm_dp_aux_unregister().
>
> - Create a new function of_drm_find_dp_aux_by_node() to get the expected
> drm_dp_aux from this global list.
>
> Please let me know your views on this implementation.
>
> Below is the summary of the changes in drm dp helper:
>
> ---
>
> // drm_dp_helper.h
>
> struct drm_dp_aux {
> ...
> struct list_head list;
> ...
> }
>
> // drm_dp_helper.c
>
> static DEFINE_MUTEX(dp_aux_lock);
> static LIST_HEAD(dp_aux_list);
>
> static void drm_dp_aux_add(struct drm_dp_aux *aux)
> {
> mutex_lock(&dp_aux_lock);
> list_add_tail(&aux->list, &dp_aux_list);
> mutex_unlock(&dp_aux_lock);
> }
>
> static void drm_dp_aux_remove(struct drm_dp_aux *aux)
> {
> mutex_lock(&dp_aux_lock);
> list_del_init(&aux->list);
> mutex_unlock(&dp_aux_lock);
> }
>
> #ifdef CONFIG_OF
> struct drm_dp_aux *of_drm_find_dp_aux_by_node(struct device_node *np)
> {
> struct drm_dp_aux *aux;
> mutex_lock(&dp_aux_lock);
>
> list_for_each_entry(aux, &dp_aux_list, list) {
> if (aux->dev->of_node == np) {
> mutex_unlock(&dp_aux_lock);
> return aux;
> }
> }
>
> mutex_unlock(&dp_aux_lock);
> return NULL;
> }
> EXPORT_SYMBOL(of_drm_find_dp_aux_by_node);
> #endif
>
>
> int drm_dp_aux_init(struct drm_dp_aux *aux)
> {
> INIT_LIST_HEAD(&aux->list);
> ...
> }
>
> int drm_dp_aux_register(struct drm_dp_aux *aux)
> {
> ...
> drm_dp_aux_add(aux);
>
> return 0;
> }
>
> void drm_dp_aux_unregister(struct drm_dp_aux *aux)
> {
> drm_dp_aux_remove(aux);
> ...
> }
Overall this seems like a good approach, but there's one unanswered
question: what happens if drm_dp_aux_unregister() is called while a
panel holds a reference to it ? The drm_dp_aux instances likely need to
be reference-counted.
> > I guess an alternate way to solve this (I'm not totally sure whether
> > it's better or worse) would be to add a function that would walk up
> > the chain of parent bridges and ask them for a pointer to the aux bus.
> > I definitely haven't thought it all the way through, but I'd imagine
> > something like drm_bridge_chain_get_ddc_aux(). This is _probably_
> > better than adding the "ddc-aux-bus" property but it assumes that the
> > aux bus is provided by one of our parents. Hrm, looking at this
> > briefly, though, I'm not sure how to do it. It doesn't seem possible
> > to get the parent bridges from the panel structure. Even if you assume
> > that your parent is wrapping you with a panel_bridge it still doesn't
> > seem possible?
> >
> > This probably needs more drm-expertise.
--
Regards,
Laurent Pinchart
___
Freedreno mailing list
Freedreno@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/freedreno
Re: [Freedreno] [PATCH] drm/dsi: Add _NO_ to MIPI_DSI_* flags disabling features
Hi Nicolas,
Thank you for the patch.
On Thu, Feb 11, 2021 at 11:33:55AM +0800, Nicolas Boichat wrote:
> Many of the DSI flags have names opposite to their actual effects,
> e.g. MIPI_DSI_MODE_EOT_PACKET means that EoT packets will actually
> be disabled. Fix this by including _NO_ in the flag names, e.g.
> MIPI_DSI_MODE_NO_EOT_PACKET.
>
> Signed-off-by: Nicolas Boichat
This looks good to me, it increases readability.
Reviewed-by: Laurent Pinchart
Please however see the end of the mail for a comment.
> ---
> I considered adding _DISABLE_ instead, but that'd make the
> flag names a big too long.
>
> Generated with:
> flag=MIPI_DSI_MODE_VIDEO_HFP; git grep $flag | cut -f1 -d':' | \
> xargs -I{} sed -i -e "s/$flag/MIPI_DSI_MODE_VIDEO_NO_HFP/" {}
> flag=MIPI_DSI_MODE_VIDEO_HBP; git grep $flag | cut -f1 -d':' | \
> xargs -I{} sed -i -e "s/$flag/MIPI_DSI_MODE_VIDEO_NO_HBP/" {}
> flag=MIPI_DSI_MODE_VIDEO_HSA; git grep $flag | cut -f1 -d':' | \
> xargs -I{} sed -i -e "s/$flag/MIPI_DSI_MODE_VIDEO_NO_HSA/" {}
> flag=MIPI_DSI_MODE_EOT_PACKET; git grep $flag | cut -f1 -d':' | \
> xargs -I{} sed -i -e "s/$flag/MIPI_DSI_MODE_NO_EOT_PACKET/" {}
> (then minor format changes)
Ever tried coccinelle ? :-)
> drivers/gpu/drm/bridge/adv7511/adv7533.c | 2 +-
> drivers/gpu/drm/bridge/analogix/anx7625.c| 2 +-
> drivers/gpu/drm/bridge/cdns-dsi.c| 4 ++--
> drivers/gpu/drm/bridge/tc358768.c| 2 +-
> drivers/gpu/drm/exynos/exynos_drm_dsi.c | 8
> drivers/gpu/drm/mcde/mcde_dsi.c | 2 +-
> drivers/gpu/drm/mediatek/mtk_dsi.c | 2 +-
> drivers/gpu/drm/msm/dsi/dsi_host.c | 8
> drivers/gpu/drm/panel/panel-asus-z00t-tm5p5-n35596.c | 2 +-
> drivers/gpu/drm/panel/panel-dsi-cm.c | 2 +-
> drivers/gpu/drm/panel/panel-elida-kd35t133.c | 2 +-
> drivers/gpu/drm/panel/panel-khadas-ts050.c | 2 +-
> drivers/gpu/drm/panel/panel-leadtek-ltk050h3146w.c | 2 +-
> drivers/gpu/drm/panel/panel-leadtek-ltk500hd1829.c | 2 +-
> drivers/gpu/drm/panel/panel-novatek-nt35510.c| 2 +-
> drivers/gpu/drm/panel/panel-osd-osd101t2587-53ts.c | 2 +-
> drivers/gpu/drm/panel/panel-samsung-s6d16d0.c| 2 +-
> drivers/gpu/drm/panel/panel-samsung-s6e63j0x03.c | 2 +-
> drivers/gpu/drm/panel/panel-samsung-s6e63m0-dsi.c| 2 +-
> drivers/gpu/drm/panel/panel-samsung-s6e8aa0.c| 4 ++--
> drivers/gpu/drm/panel/panel-sharp-ls043t1le01.c | 2 +-
> drivers/gpu/drm/panel/panel-simple.c | 2 +-
> drivers/gpu/drm/panel/panel-sony-acx424akp.c | 2 +-
> drivers/gpu/drm/panel/panel-xinpeng-xpp055c272.c | 2 +-
> include/drm/drm_mipi_dsi.h | 8
> 25 files changed, 36 insertions(+), 36 deletions(-)
>
> diff --git a/drivers/gpu/drm/bridge/adv7511/adv7533.c
> b/drivers/gpu/drm/bridge/adv7511/adv7533.c
> index aa19d5a40e31..59d718bde8c4 100644
> --- a/drivers/gpu/drm/bridge/adv7511/adv7533.c
> +++ b/drivers/gpu/drm/bridge/adv7511/adv7533.c
> @@ -165,7 +165,7 @@ int adv7533_attach_dsi(struct adv7511 *adv)
> dsi->lanes = adv->num_dsi_lanes;
> dsi->format = MIPI_DSI_FMT_RGB888;
> dsi->mode_flags = MIPI_DSI_MODE_VIDEO | MIPI_DSI_MODE_VIDEO_SYNC_PULSE |
> - MIPI_DSI_MODE_EOT_PACKET | MIPI_DSI_MODE_VIDEO_HSE;
> + MIPI_DSI_MODE_NO_EOT_PACKET | MIPI_DSI_MODE_VIDEO_HSE;
>
> ret = mipi_dsi_attach(dsi);
> if (ret < 0) {
> diff --git a/drivers/gpu/drm/bridge/analogix/anx7625.c
> b/drivers/gpu/drm/bridge/analogix/anx7625.c
> index 65cc05982f82..beecfe6bf359 100644
> --- a/drivers/gpu/drm/bridge/analogix/anx7625.c
> +++ b/drivers/gpu/drm/bridge/analogix/anx7625.c
> @@ -1334,7 +1334,7 @@ static int anx7625_attach_dsi(struct anx7625_data *ctx)
> dsi->format = MIPI_DSI_FMT_RGB888;
> dsi->mode_flags = MIPI_DSI_MODE_VIDEO |
> MIPI_DSI_MODE_VIDEO_SYNC_PULSE |
> - MIPI_DSI_MODE_EOT_PACKET|
> + MIPI_DSI_MODE_NO_EOT_PACKET |
> MIPI_DSI_MODE_VIDEO_HSE;
>
> if (mipi_dsi_attach(dsi) < 0) {
> diff --git a/drivers/gpu/drm/bridge/cdns-dsi.c
> b/drivers/gpu/drm/bridge/cdns-dsi.c
> index 76373e31df92..34aa24269a57 100644
> --- a/drivers/gpu/drm/bridge/cdns-dsi.c
> +++ b/drivers/gpu/drm/bridge/cdns-dsi.c
> @@ -829,7 +829,7 @@ static void cdns_dsi_bridge_enable(struct drm_bridge
> *bridge)
> tmp = DIV_ROUND_UP(dsi_cfg.htotal, nlanes) -
> DIV_ROUND_UP(dsi_cfg.hsa, nlanes);
Re: [Freedreno] [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(&intel_dp->aux,
> intel_dp->dpcd);
> } else {
> const u8 *phy_caps = intel_dp_lttpr_phy_caps(intel_dp, dp_phy);
&
Re: [Freedreno] [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(&intel_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
&g
Re: [Freedreno] [PATCH 15/30] drm/dp: Add backpointer to drm_device in drm_dp_aux
-1069,6 +1069,7 @@ static int zynqmp_dp_aux_init(struct zynqmp_dp *dp)
>
> dp->aux.name = "ZynqMP DP AUX";
> dp->aux.dev = dp->dev;
> + dp->aux.drm_dev = dp->drm;
> dp->aux.transfer = zynqmp_dp_aux_transfer;
>
> return drm_dp_aux_register(&dp->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 &drm_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 &drm_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
___
Freedreno mailing list
Freedreno@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/freedreno
Re: [Freedreno] [PATCH v2 09/11] drm/atomic: Pass the full state to planes atomic disable and update
Hi Maxime,
Thank you for the patch.
On Thu, Jan 21, 2021 at 05:35:34PM +0100, Maxime Ripard wrote:
> The current atomic helpers have either their object state being passed as
> an argument or the full atomic state.
>
> The former is the pattern that was done at first, before switching to the
> latter for new hooks or when it was needed.
>
> Let's convert the remaining helpers to provide a consistent interface,
> this time with the planes atomic_update and atomic_disable.
>
> The conversion was done using the coccinelle script below, built tested on
> all the drivers.
>
> @@
> identifier plane, plane_state;
> symbol state;
> @@
>
> struct drm_plane_helper_funcs {
> ...
> void (*atomic_update)(struct drm_plane *plane,
> - struct drm_plane_state *plane_state);
> + struct drm_atomic_state *state);
> ...
> }
>
> @@
> identifier plane, plane_state;
> symbol state;
> @@
>
> struct drm_plane_helper_funcs {
> ...
> void (*atomic_disable)(struct drm_plane *plane,
> -struct drm_plane_state *plane_state);
> +struct drm_atomic_state *state);
> ...
> }
>
> @ plane_atomic_func @
> identifier helpers;
> identifier func;
> @@
>
> (
> static const struct drm_plane_helper_funcs helpers = {
> ...,
> .atomic_update = func,
> ...,
> };
> |
> static const struct drm_plane_helper_funcs helpers = {
> ...,
> .atomic_disable = func,
> ...,
> };
> )
>
> @@
> struct drm_plane_helper_funcs *FUNCS;
> identifier f;
> identifier crtc_state;
> identifier plane, plane_state, state;
> expression e;
> @@
>
> f(struct drm_crtc_state *crtc_state)
> {
> ...
> struct drm_atomic_state *state = e;
> <+...
> (
> - FUNCS->atomic_disable(plane, plane_state)
> + FUNCS->atomic_disable(plane, state)
> |
> - FUNCS->atomic_update(plane, plane_state)
> + FUNCS->atomic_update(plane, state)
> )
> ...+>
> }
>
> @@
> identifier plane_atomic_func.func;
> identifier plane;
> symbol state;
> @@
>
> func(struct drm_plane *plane,
> -struct drm_plane_state *state)
> +struct drm_plane_state *old_plane_state)
> {
> <...
> - state
> + old_plane_state
> ...>
> }
>
> @ ignores_old_state @
> identifier plane_atomic_func.func;
> identifier plane, old_state;
> @@
>
> func(struct drm_plane *plane, struct drm_plane_state *old_state)
> {
> ... when != old_state
> }
>
> @ adds_old_state depends on plane_atomic_func && !ignores_old_state @
> identifier plane_atomic_func.func;
> identifier plane, plane_state;
> @@
>
> func(struct drm_plane *plane, struct drm_plane_state *plane_state)
> {
> + struct drm_plane_state *plane_state =
> drm_atomic_get_old_plane_state(state, plane);
> ...
> }
>
> @ depends on plane_atomic_func @
> identifier plane_atomic_func.func;
> identifier plane, plane_state;
> @@
>
> func(struct drm_plane *plane,
> - struct drm_plane_state *plane_state
> + struct drm_atomic_state *state
> )
> { ... }
>
> @ include depends on adds_old_state @
> @@
>
> #include
>
> @ no_include depends on !include && adds_old_state @
> @@
>
> + #include
> #include
>
> @@
> identifier plane_atomic_func.func;
> identifier plane, state;
> identifier plane_state;
> @@
>
> func(struct drm_plane *plane, struct drm_atomic_state *state) {
> ...
> struct drm_plane_state *plane_state =
> drm_atomic_get_old_plane_state(state, plane);
> <+...
> - plane_state->state
> + state
> ...+>
> }
>
> Signed-off-by: Maxime Ripard
>
> ---
>
> Changes from v1:
> - Reintroduce the old_plane_state check in zynqmp_disp_crtc_atomic_disable
> ---
> drivers/gpu/drm/drm_atomic_helper.c | 8
> drivers/gpu/drm/drm_simple_kms_helper.c | 4 +++-
> drivers/gpu/drm/mxsfb/mxsfb_kms.c | 6 --
> drivers/gpu/drm/omapdrm/omap_plane.c | 4 ++--
> drivers/gpu/drm/rcar-du/rcar_du_plane.c | 4 +++-
> drivers/gpu/drm/rcar-du/rcar_du_vsp.c | 4 +++-
> drivers/gpu/drm/tidss/tidss_plane.c | 4 ++--
> drivers/gpu/drm/tilcdc/tilcdc_plane.c | 2 +-
> drivers/gpu/drm/xlnx/zynqmp_disp.c| 15 ---
> include/drm/drm_modeset_helper_vtables.h | 4 ++--
For these,
Reviewed-by: Laurent Pinchart
> 58 files changed, 211 insertions(+), 123 deletions(-)
--
Regards,
Laurent Pinchart
___
Freedreno mailing list
Freedreno@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/freedreno
Re: [Freedreno] [PATCH 04/10] drm/atomic: Pass the full state to planes atomic_check
Hi Maxime,
Thank you for the patch.
On Fri, Jan 15, 2021 at 01:56:56PM +0100, Maxime Ripard wrote:
> The current atomic helpers have either their object state being passed as
> an argument or the full atomic state.
>
> The former is the pattern that was done at first, before switching to the
> latter for new hooks or when it was needed.
>
> Let's start convert all the remaining helpers to provide a consistent
s/start convert/convert/ ?
> interface, starting with the planes atomic_check.
>
> The conversion was done using the coccinelle script below plus some
> manual changes for vmwgfx, built tested on all the drivers.
>
> @@
> identifier plane, plane_state;
> symbol state;
> @@
>
> struct drm_plane_helper_funcs {
> ...
> int (*atomic_check)(struct drm_plane *plane,
> - struct drm_plane_state *plane_state);
> + struct drm_atomic_state *state);
> ...
> }
>
> @ plane_atomic_func @
> identifier helpers;
> identifier func;
> @@
>
> static const struct drm_plane_helper_funcs helpers = {
> ...,
> .atomic_check = func,
> ...,
> };
>
> @@
> struct drm_plane_helper_funcs *FUNCS;
> identifier f;
> identifier dev;
> identifier plane, plane_state, state;
> @@
>
> f(struct drm_device *dev, struct drm_atomic_state *state)
> {
> <+...
> - FUNCS->atomic_check(plane, plane_state)
> + FUNCS->atomic_check(plane, state)
> ...+>
> }
>
> @@
> identifier plane_atomic_func.func;
> identifier plane;
> symbol state;
> @@
>
> func(struct drm_plane *plane,
> -struct drm_plane_state *state)
> +struct drm_plane_state *new_plane_state)
> {
> <...
> - state
> + new_plane_state
> ...>
> }
>
Is this needed, or is it a leftover from 02/10 ?
> @ ignores_new_state @
> identifier plane_atomic_func.func;
> identifier plane, new_plane_state;
> @@
>
> func(struct drm_plane *plane, struct drm_plane_state *new_plane_state)
> {
> ... when != new_plane_state
> }
>
> @ adds_new_state depends on plane_atomic_func && !ignores_new_state @
> identifier plane_atomic_func.func;
> identifier plane, new_plane_state;
> @@
>
> func(struct drm_plane *plane, struct drm_plane_state *new_plane_state)
> {
> + struct drm_plane_state *new_plane_state =
> drm_atomic_get_new_plane_state(state, plane);
> ...
> }
>
> @ depends on plane_atomic_func @
> identifier plane_atomic_func.func;
> identifier plane, new_plane_state;
> @@
>
> func(struct drm_plane *plane,
> - struct drm_plane_state *new_plane_state
> + struct drm_atomic_state *state
> )
> { ... }
>
> @ include depends on adds_new_state @
> @@
>
> #include
>
> @ no_include depends on !include && adds_new_state @
> @@
>
> + #include
> #include
>
> Signed-off-by: Maxime Ripard
> ---
[snip]
> drivers/gpu/drm/drm_atomic_helper.c | 2 +-
> drivers/gpu/drm/drm_simple_kms_helper.c | 4 +++-
> drivers/gpu/drm/omapdrm/omap_plane.c | 4 +++-
> drivers/gpu/drm/rcar-du/rcar_du_plane.c | 4 +++-
> drivers/gpu/drm/rcar-du/rcar_du_vsp.c | 5 -
> drivers/gpu/drm/xlnx/zynqmp_disp.c| 4 +++-
For these,
Reviewed-by: Laurent Pinchart
[snip]
--
Regards,
Laurent Pinchart
___
Freedreno mailing list
Freedreno@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/freedreno
Re: [Freedreno] [PATCH 10/10] drm: Use state helper instead of the plane state pointer
Hi Maxime,
Thank you for the patch.
On Fri, Jan 15, 2021 at 01:57:02PM +0100, Maxime Ripard wrote:
> Many drivers reference the plane->state pointer in order to get the
> current plane state in their atomic_update or atomic_disable hooks,
Please don't use the word "current", it's ambiguous. Do you mean old
state or new state ?
> which would be the new plane state in the global atomic state since
> _swap_state happened when those hooks are run.
Is this relevant ? drm_atomic_helper_swap_state() doesn't change the
old_state and new_state pointers in drm_atomic_state as far as I can
tell.
> Use the drm_atomic_get_new_plane_state helper to get that state to make it
> more obvious.
>
> This was made using the coccinelle script below:
>
> @ plane_atomic_func @
> identifier helpers;
> identifier func;
> @@
>
> (
> static const struct drm_plane_helper_funcs helpers = {
> ...,
> .atomic_disable = func,
> ...,
> };
> |
> static const struct drm_plane_helper_funcs helpers = {
> ...,
> .atomic_update = func,
> ...,
> };
> )
>
> @ adds_new_state @
> identifier plane_atomic_func.func;
> identifier plane, state;
> identifier new_state;
> @@
>
> func(struct drm_plane *plane, struct drm_atomic_state *state)
> {
> ...
> - struct drm_plane_state *new_state = plane->state;
> + struct drm_plane_state *new_state =
> drm_atomic_get_new_plane_state(state, plane);
> ...
> }
>
> @ include depends on adds_new_state @
> @@
>
> #include
>
> @ no_include depends on !include && adds_new_state @
> @@
>
> + #include
> #include
>
> Signed-off-by: Maxime Ripard
> ---
[snip]
> drivers/gpu/drm/omapdrm/omap_plane.c| 6 --
> drivers/gpu/drm/rcar-du/rcar_du_plane.c | 3 ++-
> drivers/gpu/drm/rcar-du/rcar_du_vsp.c | 3 ++-
> drivers/gpu/drm/xlnx/zynqmp_disp.c | 3 ++-
[snip]
> diff --git a/drivers/gpu/drm/omapdrm/omap_plane.c
> b/drivers/gpu/drm/omapdrm/omap_plane.c
> index cd8cf7c786b5..021a94de84a1 100644
> --- a/drivers/gpu/drm/omapdrm/omap_plane.c
> +++ b/drivers/gpu/drm/omapdrm/omap_plane.c
> @@ -44,7 +44,8 @@ static void omap_plane_atomic_update(struct drm_plane
> *plane,
> {
> struct omap_drm_private *priv = plane->dev->dev_private;
> struct omap_plane *omap_plane = to_omap_plane(plane);
> - struct drm_plane_state *new_state = plane->state;
This seems to imply that you're interested in the new state.
> + struct drm_plane_state *new_state =
> drm_atomic_get_new_plane_state(state,
> +
> plane);
Does this really make things more obvious ?
> struct omap_overlay_info info;
> int ret;
>
> @@ -89,7 +90,8 @@ static void omap_plane_atomic_update(struct drm_plane
> *plane,
> static void omap_plane_atomic_disable(struct drm_plane *plane,
> struct drm_atomic_state *state)
> {
> - struct drm_plane_state *new_state = plane->state;
> + struct drm_plane_state *new_state =
> drm_atomic_get_new_plane_state(state,
> +
> plane);
> struct omap_drm_private *priv = plane->dev->dev_private;
> struct omap_plane *omap_plane = to_omap_plane(plane);
>
[snip]
--
Regards,
Laurent Pinchart
___
Freedreno mailing list
Freedreno@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/freedreno
Re: [Freedreno] [PATCH 05/10] drm: Use the state pointer directly in planes atomic_check
Hi Maxime,
Thank you for the patch.
On Fri, Jan 15, 2021 at 01:56:57PM +0100, Maxime Ripard wrote:
> Now that atomic_check takes the global atomic state as a parameter, we
> don't need to go through the pointer in the plane state.
>
> This was done using the following coccinelle script:
>
> @ plane_atomic_func @
> identifier helpers;
> identifier func;
> @@
>
> static struct drm_plane_helper_funcs helpers = {
> ...,
> .atomic_check = func,
> ...,
> };
>
> @@
> identifier plane_atomic_func.func;
> identifier plane, state;
> identifier plane_state;
> @@
>
> func(struct drm_plane *plane, struct drm_atomic_state *state) {
> ...
> - struct drm_plane_state *plane_state = drm_atomic_get_new_plane_state(state,
> plane);
> <... when != plane_state
> - plane_state->state
> + state
> ...>
> }
>
> @@
> identifier plane_atomic_func.func;
> identifier plane, state;
> identifier plane_state;
> @@
>
> func(struct drm_plane *plane, struct drm_atomic_state *state) {
> ...
> struct drm_plane_state *plane_state = drm_atomic_get_new_plane_state(state,
> plane);
> <...
> - plane_state->state
> + state
> ...>
> }
>
> Signed-off-by: Maxime Ripard
> ---
[snip]
> drivers/gpu/drm/omapdrm/omap_plane.c | 2 +-
> drivers/gpu/drm/xlnx/zynqmp_disp.c| 2 +-
For these, with the small issue below addressed,
Reviewed-by: Laurent Pinchart
[snip]
> diff --git a/drivers/gpu/drm/xlnx/zynqmp_disp.c
> b/drivers/gpu/drm/xlnx/zynqmp_disp.c
> index b0a3ba528718..d749acc78c85 100644
> --- a/drivers/gpu/drm/xlnx/zynqmp_disp.c
> +++ b/drivers/gpu/drm/xlnx/zynqmp_disp.c
> @@ -1152,7 +1152,7 @@ zynqmp_disp_plane_atomic_check(struct drm_plane *plane,
> if (!new_plane_state->crtc)
> return 0;
>
> - crtc_state = drm_atomic_get_crtc_state(new_plane_state->state,
> + crtc_state = drm_atomic_get_crtc_state(state,
> new_plane_state->crtc);
This now holds on a single line.
> if (IS_ERR(crtc_state))
> return PTR_ERR(crtc_state);
[snip]
--
Regards,
Laurent Pinchart
___
Freedreno mailing list
Freedreno@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/freedreno
Re: [Freedreno] [PATCH 09/10] drm/atomic: Pass the full state to planes atomic disable and update
Hi Maxime,
Thank you for the patch.
On Fri, Jan 15, 2021 at 01:57:01PM +0100, Maxime Ripard wrote:
> The current atomic helpers have either their object state being passed as
> an argument or the full atomic state.
>
> The former is the pattern that was done at first, before switching to the
> latter for new hooks or when it was needed.
>
> Let's start convert all the remaining helpers to provide a consistent
s/start convert/convert/ ?
> interface, starting with the planes atomic_update and atomic_disable.
You're not starting anymore, its 09/10 already :-)
> The conversion was done using the coccinelle script below, built tested on
> all the drivers.
>
> @@
> identifier plane, plane_state;
> symbol state;
> @@
>
> struct drm_plane_helper_funcs {
> ...
> void (*atomic_update)(struct drm_plane *plane,
> - struct drm_plane_state *plane_state);
> + struct drm_atomic_state *state);
> ...
> }
>
> @@
> identifier plane, plane_state;
> symbol state;
> @@
>
> struct drm_plane_helper_funcs {
> ...
> void (*atomic_disable)(struct drm_plane *plane,
> -struct drm_plane_state *plane_state);
> +struct drm_atomic_state *state);
> ...
> }
>
> @ plane_atomic_func @
> identifier helpers;
> identifier func;
> @@
>
> (
> static const struct drm_plane_helper_funcs helpers = {
> ...,
> .atomic_update = func,
> ...,
> };
> |
> static const struct drm_plane_helper_funcs helpers = {
> ...,
> .atomic_disable = func,
> ...,
> };
> )
>
> @@
> struct drm_plane_helper_funcs *FUNCS;
> identifier f;
> identifier crtc_state;
> identifier plane, plane_state, state;
> expression e;
> @@
>
> f(struct drm_crtc_state *crtc_state)
> {
> ...
> struct drm_atomic_state *state = e;
> <+...
> (
> - FUNCS->atomic_disable(plane, plane_state)
> + FUNCS->atomic_disable(plane, state)
> |
> - FUNCS->atomic_update(plane, plane_state)
> + FUNCS->atomic_update(plane, state)
> )
> ...+>
> }
>
> @@
> identifier plane_atomic_func.func;
> identifier plane;
> symbol state;
> @@
>
> func(struct drm_plane *plane,
> -struct drm_plane_state *state)
> +struct drm_plane_state *old_plane_state)
> {
> <...
> - state
> + old_plane_state
> ...>
> }
>
> @ ignores_old_state @
> identifier plane_atomic_func.func;
> identifier plane, old_state;
> @@
>
> func(struct drm_plane *plane, struct drm_plane_state *old_state)
> {
> ... when != old_state
> }
>
> @ adds_old_state depends on plane_atomic_func && !ignores_old_state @
> identifier plane_atomic_func.func;
> identifier plane, plane_state;
> @@
>
> func(struct drm_plane *plane, struct drm_plane_state *plane_state)
> {
> + struct drm_plane_state *plane_state =
> drm_atomic_get_old_plane_state(state, plane);
> ...
> }
>
> @ depends on plane_atomic_func @
> identifier plane_atomic_func.func;
> identifier plane, plane_state;
> @@
>
> func(struct drm_plane *plane,
> - struct drm_plane_state *plane_state
> + struct drm_atomic_state *state
> )
> { ... }
>
> @ include depends on adds_old_state @
> @@
>
> #include
>
> @ no_include depends on !include && adds_old_state @
> @@
>
> + #include
> #include
>
> @@
> identifier plane_atomic_func.func;
> identifier plane, state;
> identifier plane_state;
> @@
>
> func(struct drm_plane *plane, struct drm_atomic_state *state) {
> ...
> struct drm_plane_state *plane_state =
> drm_atomic_get_old_plane_state(state, plane);
> <+...
> - plane_state->state
> + state
> ...+>
> }
>
> Signed-off-by: Maxime Ripard
> ---
[snip]
> drivers/gpu/drm/drm_atomic_helper.c | 8
> drivers/gpu/drm/drm_simple_kms_helper.c | 4 +++-
> drivers/gpu/drm/omapdrm/omap_plane.c | 4 ++--
> drivers/gpu/drm/rcar-du/rcar_du_plane.c | 4 +++-
> drivers/gpu/drm/rcar-du/rcar_du_vsp.c | 4 +++-
> include/drm/drm_modeset_helper_vtables.h | 4 ++--
For these,
Reviewed-by: Laurent Pinchart
For drivers/gpu/drm/xlnx/zynqmp_disp.c, please see below.
[snip]
> diff --git a/drivers/gpu/drm/xlnx/zynqmp_disp.c
> b/drivers/gpu/drm/xlnx/zynqmp_disp.c
> index e278680b7d5a..39f9e6e76064 100644
> --- a/drivers/gpu/drm/xlnx/zynqmp_disp.c
> +++ b/driv
Re: [Freedreno] [PATCH 02/10] drm: Rename plane atomic_check state names
Hi Maxime,
Thank you for the patch.
On Fri, Jan 15, 2021 at 01:56:54PM +0100, Maxime Ripard wrote:
> Most drivers call the argument to the plane atomic_check hook simply
> state, which is going to conflict with the global atomic state in a
> later rework. Let's rename it to new_plane_state (or new_state depending
> on the convention used in the driver).
>
> This was done using the coccinelle script below, and built tested:
>
> @ plane_atomic_func @
> identifier helpers;
> identifier func;
> @@
>
> static const struct drm_plane_helper_funcs helpers = {
> .atomic_check = func,
> };
>
> @ has_old_state @
> identifier plane_atomic_func.func;
> identifier plane;
> expression e;
> symbol old_state;
> symbol state;
> @@
>
> func(struct drm_plane *plane, struct drm_plane_state *state)
> {
> ...
> struct drm_plane_state *old_state = e;
> ...
> }
>
> @ depends on has_old_state @
> identifier plane_atomic_func.func;
> identifier plane;
> symbol old_state;
> @@
>
> func(struct drm_plane *plane,
> - struct drm_plane_state *state
> + struct drm_plane_state *new_state
> )
> {
> <+...
> - state
> + new_state
> ...+>
> }
>
> @ has_state @
> identifier plane_atomic_func.func;
> identifier plane;
> symbol state;
> @@
>
> func(struct drm_plane *plane, struct drm_plane_state *state)
> {
> ...
> }
>
> @ depends on has_state @
> identifier plane_atomic_func.func;
> identifier plane;
> symbol old_state;
> @@
>
> func(struct drm_plane *plane,
> - struct drm_plane_state *state
> + struct drm_plane_state *new_plane_state
> )
> {
> <+...
> - state
> + new_plane_state
> ...+>
> }
>
> Signed-off-by: Maxime Ripard
> ---
[...]
> drivers/gpu/drm/omapdrm/omap_plane.c | 19 +++++
> drivers/gpu/drm/rcar-du/rcar_du_plane.c | 7 ++--
> drivers/gpu/drm/rcar-du/rcar_du_vsp.c | 7 ++--
> drivers/gpu/drm/xlnx/zynqmp_disp.c| 10 +++--
For these, with the comment below addressed,
Reviewed-by: Laurent Pinchart
> 41 files changed, 402 insertions(+), 357 deletions(-)
[snip]
> diff --git a/drivers/gpu/drm/omapdrm/omap_plane.c
> b/drivers/gpu/drm/omapdrm/omap_plane.c
> index 51dc24acea73..78d0eb1fd69d 100644
> --- a/drivers/gpu/drm/omapdrm/omap_plane.c
> +++ b/drivers/gpu/drm/omapdrm/omap_plane.c
> @@ -99,18 +99,19 @@ static void omap_plane_atomic_disable(struct drm_plane
> *plane,
> }
>
> static int omap_plane_atomic_check(struct drm_plane *plane,
> -struct drm_plane_state *state)
> +struct drm_plane_state *new_plane_state)
> {
> struct drm_crtc_state *crtc_state;
>
> - if (!state->fb)
> + if (!new_plane_state->fb)
> return 0;
>
> /* crtc should only be NULL when disabling (i.e., !state->fb) */
s/state/new_plane_state/ here too ?
> - if (WARN_ON(!state->crtc))
> + if (WARN_ON(!new_plane_state->crtc))
> return 0;
>
> - crtc_state = drm_atomic_get_existing_crtc_state(state->state,
> state->crtc);
> + crtc_state = drm_atomic_get_existing_crtc_state(new_plane_state->state,
> + new_plane_state->crtc);
> /* we should have a crtc state if the plane is attached to a crtc */
> if (WARN_ON(!crtc_state))
> return 0;
> @@ -118,17 +119,17 @@ static int omap_plane_atomic_check(struct drm_plane
> *plane,
> if (!crtc_state->enable)
> return 0;
>
> - if (state->crtc_x < 0 || state->crtc_y < 0)
> + if (new_plane_state->crtc_x < 0 || new_plane_state->crtc_y < 0)
> return -EINVAL;
>
> - if (state->crtc_x + state->crtc_w > crtc_state->adjusted_mode.hdisplay)
> + if (new_plane_state->crtc_x + new_plane_state->crtc_w >
> crtc_state->adjusted_mode.hdisplay)
I can't help thinking we're using too long variable names... :-(
> return -EINVAL;
>
> - if (state->crtc_y + state->crtc_h > crtc_state->adjusted_mode.vdisplay)
> + if (new_plane_state->crtc_y + new_plane_state->crtc_h >
> crtc_state->adjusted_mode.vdisplay)
> return -EINVAL;
>
> - if (state->rotation != DRM_MODE_ROTATE_0 &&
> - !omap_framebuffer_supports_rotation(state->fb))
> + if (new_plane_state->rotation != DRM_MODE_ROTATE_0 &&
> + !omap_framebuffer_supports_rotation(new_plane_state->fb))
> return -EINVAL;
>
> return 0;
[...]
--
Regards,
Laurent Pinchart
___
Freedreno mailing list
Freedreno@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/freedreno
Re: [Freedreno] [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 = &drm_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 = &zynqmp_dpsub_drm_fops,
>
--
Regards,
Laurent Pinchart
___
Freedreno mailing list
Freedreno@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/freedreno
Re: [Freedreno] [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 = &omap_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 = &omap_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 = &omap_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
___
Freedreno mailing list
Freedreno@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/freedreno
Re: [Freedreno] [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 = &drm_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 = &zynqmp_dpsub_drm_fops,
>
--
Regards,
Laurent Pinchart
___
Freedreno mailing list
Freedreno@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/freedreno
Re: [Freedreno] [PATCH v2 00/28] drm/bridge: Consolidate initialization
Hi Mihail, Thank you for the patches. On Wed, Dec 04, 2019 at 11:48:01AM +, Mihail Atanassov wrote: > Hi all, > > I've dropped the fun parts of this series since they need more work, but > figured drm_bridge_init() as a concept is still valuable on its own (and > I think I'll need it to roll out device links for registered bridges), > so here goes. > > v2: > - expanded commit messages and added some extra bridge-related >documentation (Daniel) > - dropped v1 patches 29 and 30: 29 needs more work, and 30 depends on >it > - added all remaining drm_bridge implementers, found by searching for >drm_bridge_funcs which is mandatory for any bridge; new uses in >patches 3, 27, and 28 (Sam) > - due to the above, I've decided to squash all analogix changes into >one patch For patches 02, 04 to 11 and 13 to 17, 19 to 24, and 27 to 28, Reviewed-by: Laurent Pinchart > --- > v1 [https://patchwork.freedesktop.org/series/70039/] cover text below: > > This series adds device links support to drm_bridge. The motivation > behind it is that a drm_bridge in a module could get removed under the > feet of the bridge user without warning, so we need a way to remove and > reprobe the client as needed to avoid peering into the void. > > 1: Add a drm_bridge_init() function which wraps all initialisation of > the structure prior to calling drm_bridge_add(). > > 2-26,28: Apply the drm_bridge_init() refactor to every bridge that uses > drm_bridge_add(). > > 27: Minor cleanup in rcar-du. > > 29: Add of_drm_find_bridge_devlink() which functions the same as > of_drm_find_bridge() plus adds a device device link from the owning > drm_device to the bridge device. > > 30: As a motivating example, convert komeda to exclusively use > drm_bridge for its pipe outputs; this isn't a regression in usability > any more since device links bring the same automatic remove/reprobe > feature as components. > > Mihail Atanassov (28): > drm: Introduce drm_bridge_init() > drm/bridge: adv7511: Use drm_bridge_init() > drm/bridge/analogix: Use drm_bridge_init() > drm/bridge: cdns: Use drm_bridge_init() > drm/bridge: dumb-vga-dac: Use drm_bridge_init() > drm/bridge: lvds-encoder: Use drm_bridge_init() > drm/bridge: megachips-stdp-ge-b850v3-fw: Use drm_bridge_init() > drm/bridge: nxp-ptn3460: Use drm_bridge_init() > drm/bridge: panel: Use drm_bridge_init() > drm/bridge: ps8622: Use drm_bridge_init() > drm/bridge: sii902x: Use drm_bridge_init() > gpu: drm: bridge: sii9234: Use drm_bridge_init() > drm/bridge: sil_sii8620: Use drm_bridge_init() > drm/bridge: dw-hdmi: Use drm_bridge_init() > drm/bridge/synopsys: dsi: Use drm_bridge_init() > drm/bridge: tc358764: Use drm_bridge_init() > drm/bridge: tc358767: Use drm_bridge_init() > drm/bridge: thc63: Use drm_bridge_init() > drm/bridge: ti-sn65dsi86: Use drm_bridge_init() > drm/bridge: ti-tfp410: Use drm_bridge_init() > drm/exynos: mic: Use drm_bridge_init() > drm/i2c: tda998x: Use drm_bridge_init() > drm/mcde: dsi: Use drm_bridge_init() > drm/mediatek: hdmi: Use drm_bridge_init() > drm: rcar-du: lvds: Use drm_bridge_init() > drm: rcar-du: lvds: Don't set drm_bridge private pointer > drm/sti: Use drm_bridge_init() > drm/msm: Use drm_bridge_init() > > drivers/gpu/drm/bridge/adv7511/adv7511_drv.c | 5 ++- > .../drm/bridge/analogix/analogix-anx6345.c| 5 ++- > .../drm/bridge/analogix/analogix-anx78xx.c| 8 ++--- > .../drm/bridge/analogix/analogix_dp_core.c| 5 ++- > drivers/gpu/drm/bridge/cdns-dsi.c | 4 +-- > drivers/gpu/drm/bridge/dumb-vga-dac.c | 6 ++-- > drivers/gpu/drm/bridge/lvds-encoder.c | 7 ++-- > .../bridge/megachips-stdp-ge-b850v3-fw.c | 4 +-- > drivers/gpu/drm/bridge/nxp-ptn3460.c | 4 +-- > drivers/gpu/drm/bridge/panel.c| 7 ++-- > drivers/gpu/drm/bridge/parade-ps8622.c| 3 +- > drivers/gpu/drm/bridge/sii902x.c | 5 ++- > drivers/gpu/drm/bridge/sii9234.c | 3 +- > drivers/gpu/drm/bridge/sil-sii8620.c | 3 +- > drivers/gpu/drm/bridge/synopsys/dw-hdmi.c | 7 ++-- > drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c | 7 ++-- > drivers/gpu/drm/bridge/tc358764.c | 4 +-- > drivers/gpu/drm/bridge/tc358767.c | 3 +- > drivers/gpu/drm/bridge/thc63lvd1024.c | 7 ++-- > drivers/gpu/drm/bridge/ti-sn65dsi86.c | 5 ++- > drivers/gpu/drm/bridge/ti-tfp410.c| 5 ++- > drivers/gpu/drm/drm_bridge.c | 34 ++- > drivers/gpu/drm/exynos/exynos_drm_mic.c | 8 + > drivers/gpu/drm/i2c/tda998
Re: [Freedreno] [PATCH RFC v2 1/5] drm/bridge: analogix-anx78xx: add support for avdd33 regulator
Hi Brian,
Thank you for the patch.
On Sun, Oct 06, 2019 at 09:45:05PM -0400, Brian Masney wrote:
> Add support for the avdd33 regulator to the analogix-anx78xx driver.
> Note that the regulator is currently enabled during driver probe and
> disabled when the driver is removed. This is currently how the
> downstream MSM kernel sources do this.
>
> Let's not merge this upstream for the mean time until I get the external
> display fully working on the Nexus 5 and then I can submit proper
> support then that powers down this regulator in the power off function.
Please then also update the corresponding DT bindings to describe the
avdd33 supply.
> Signed-off-by: Brian Masney
> ---
> Changes since v1:
> - None
>
> drivers/gpu/drm/bridge/analogix-anx78xx.c | 33 +++
> 1 file changed, 33 insertions(+)
>
> diff --git a/drivers/gpu/drm/bridge/analogix-anx78xx.c
> b/drivers/gpu/drm/bridge/analogix-anx78xx.c
> index dec3f7e66aa0..e25fae36dbe1 100644
> --- a/drivers/gpu/drm/bridge/analogix-anx78xx.c
> +++ b/drivers/gpu/drm/bridge/analogix-anx78xx.c
> @@ -56,6 +56,7 @@ static const u8 anx781x_i2c_addresses[] = {
>
> struct anx78xx_platform_data {
> struct regulator *dvdd10;
> + struct regulator *avdd33;
> struct gpio_desc *gpiod_hpd;
> struct gpio_desc *gpiod_pd;
> struct gpio_desc *gpiod_reset;
> @@ -715,10 +716,42 @@ static int anx78xx_start(struct anx78xx *anx78xx)
> return err;
> }
>
> +static void anx78xx_disable_regulator_action(void *_data)
> +{
> + struct anx78xx_platform_data *pdata = _data;
> +
> + regulator_disable(pdata->avdd33);
> +}
> +
> static int anx78xx_init_pdata(struct anx78xx *anx78xx)
> {
> struct anx78xx_platform_data *pdata = &anx78xx->pdata;
> struct device *dev = &anx78xx->client->dev;
> + int err;
> +
> + /* 3.3V digital core power regulator */
> + pdata->avdd33 = devm_regulator_get(dev, "avdd33");
> + if (IS_ERR(pdata->avdd33)) {
> + err = PTR_ERR(pdata->avdd33);
> + if (err != -EPROBE_DEFER)
> + DRM_ERROR("avdd33 regulator not found\n");
> +
> + return err;
> + }
> +
> + err = regulator_enable(pdata->avdd33);
> + if (err) {
> + DRM_ERROR("Failed to enable avdd33 regulator: %d\n", err);
> + return err;
> + }
> +
> + err = devm_add_action(dev, anx78xx_disable_regulator_action,
> + pdata);
> + if (err < 0) {
> + dev_err(dev, "Failed to setup regulator cleanup action %d\n",
> + err);
> + return err;
> + }
>
> /* 1.0V digital core power regulator */
> pdata->dvdd10 = devm_regulator_get(dev, "dvdd10");
--
Regards,
Laurent Pinchart
___
Freedreno mailing list
Freedreno@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/freedreno
Re: [Freedreno] [PATCH 05/11] drm/bridge: analogix-anx78xx: correct value of TX_P0
Hi Brian, On Mon, Sep 16, 2019 at 06:36:14AM -0400, Brian Masney wrote: > On Mon, Sep 16, 2019 at 12:02:09PM +0200, Andrzej Hajda wrote: > > On 15.08.2019 02:48, Brian Masney wrote: > > > When attempting to configure this driver on a Nexus 5 phone (msm8974), > > > setting up the dummy i2c bus for TX_P0 would fail due to an -EBUSY > > > error. The downstream MSM kernel sources [1] shows that the proper value > > > for TX_P0 is 0x78, not 0x70, so correct the value to allow device > > > probing to succeed. > > > > > > [1] > > > https://github.com/AICP/kernel_lge_hammerhead/blob/n7.1/drivers/video/slimport/slimport_tx_reg.h > > > > > > Signed-off-by: Brian Masney > > > --- > > > drivers/gpu/drm/bridge/analogix-anx78xx.h | 2 +- > > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > > > diff --git a/drivers/gpu/drm/bridge/analogix-anx78xx.h > > > b/drivers/gpu/drm/bridge/analogix-anx78xx.h > > > index 25e063bcecbc..bc511fc605c9 100644 > > > --- a/drivers/gpu/drm/bridge/analogix-anx78xx.h > > > +++ b/drivers/gpu/drm/bridge/analogix-anx78xx.h > > > @@ -6,7 +6,7 @@ > > > #ifndef __ANX78xx_H > > > #define __ANX78xx_H > > > > > > -#define TX_P00x70 > > > +#define TX_P00x78 > > > > > > This bothers me little. There are no upstream users, grepping android > > sources suggests that both values can be used [1][2] (grep for "#define > > TX_P0"), moreover there is code suggesting both values can be valid [3]. > > > > Could you verify datasheet which i2c slave addresses are valid for this > > chip, if both I guess this patch should be reworked. > > > > > > [1]: > > https://android.googlesource.com/kernel/msm/+/android-msm-flo-3.4-jb-mr2/drivers/misc/slimport_anx7808/slimport_tx_reg.h > > > > [2]: > > https://github.com/AndroidGX/SimpleGX-MM-6.0_H815_20d/blob/master/drivers/video/slimport/anx7812/slimport7812_tx_reg.h > > > > [3]: > > https://github.com/commaai/android_kernel_leeco_msm8996/blob/master/drivers/video/msm/mdss/dp/slimport_custom_declare.h#L73 > > This address is 0x78 on my Nexus 5. Given [3] above it looks like we > need to support both addresses. What do you think about moving these > addresses into device tree? Assuming that the device supports different addresses (I can't validate that as I don't have access to the datasheet), and different addresses need to be used on different systems, then the address to be used needs to be provided by the firmware (DT in this case). Two options are possible, either specifying the address explicitly in the device's DT node, or specifying free addresses (in the form of a white list or black list) and allocating an address from that pool. The latter has been discussed in a BoF at the Linux Plumbers Conference last week, https://linuxplumbersconf.org/event/4/contributions/542/. > The downstream and upstream kernel sources divide these addresses by two > to get the i2c address. Here's the code in upstream: > > https://elixir.bootlin.com/linux/latest/source/drivers/gpu/drm/bridge/analogix-anx78xx.c#L1353 > https://elixir.bootlin.com/linux/latest/source/drivers/gpu/drm/bridge/analogix-anx78xx.c#L41 > > I'm not sure why the actual i2c address isn't used in this code. -- Regards, Laurent Pinchart ___ Freedreno mailing list Freedreno@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/freedreno
Re: [Freedreno] [PATCH v6 00/24] Associate ddc adapters with connectors
.c:1 > - unrelated > > > 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 ___ Freedreno mailing list Freedreno@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/freedreno
Re: [Freedreno] [PATCH v6 00/24] Associate ddc adapters with connectors
gt; .../gpu/drm/amd/amdgpu/amdgpu_connectors.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 ___ Freedreno mailing list Freedreno@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/freedreno
Re: [Freedreno] [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(&connector->kdev->kobj,
> > +&connector->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(&connector->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
___
Freedreno mailing list
Freedreno@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/freedreno
Re: [Freedreno] [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(&connector->kdev->kobj,
> + &connector->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(&connector->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
___
Freedreno mailing list
Freedreno@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/freedreno
Re: [Freedreno] [PATCH v3 00/22] Associate ddc adapters with connectors
Hi Andrzej, On Fri, Jul 05, 2019 at 10:38:27AM +0200, Andrzej Pietrasiewicz wrote: > W dniu 28.06.2019 o 18:11, Laurent Pinchart pisze: > > Hi Andrzej, > > > > Just FYI, I have a patch series that reworks how bridges and connectors > > are handled, and it will heavily conflict with this. The purpose of the > > two series isn't the same, so both make sense. I will post the patches > > this weekend, and will then review this series in that context. > > Hopefully we'll get the best of both worlds :-) > > Hi Laurent, > > Did you have a chance to review my patch series? Not yet I'm afraid. I've been fairly busy this week, and coupled with some health issues (but I'm feeling better now, so nothing to worry about) it delayed my reviews. I'll get to it as soon as possible. Thank you for pinging me. -- Regards, Laurent Pinchart ___ Freedreno mailing list Freedreno@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/freedreno
Re: [Freedreno] [PATCH 5/5] drm/bridge: ti-sn65dsi86: support booloader enabled display
Hi Rob,
Thank you for the patch.
On Sun, Jun 30, 2019 at 08:01:43AM -0700, Rob Clark wrote:
> From: Rob Clark
>
> Request the enable gpio ASIS to avoid disabling bridge during probe, if
> already enabled. And if already enabled, defer enabling runpm until
> attach to avoid cutting off the power to the bridge.
>
> Once we get to attach, we know panel and drm driver are probed
> successfully, so at this point it i s safe to enable runpm and reset the
> bridge. If we do it earlier, we kill efifb (in the case that panel or
> drm driver do not probe successfully, giving the user no way to see what
> is going on.
>
> Signed-off-by: Rob Clark
> ---
> drivers/gpu/drm/bridge/ti-sn65dsi86.c | 12 ++--
> 1 file changed, 10 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/bridge/ti-sn65dsi86.c
> b/drivers/gpu/drm/bridge/ti-sn65dsi86.c
> index 7a046bcdd81b..8bdc33576992 100644
> --- a/drivers/gpu/drm/bridge/ti-sn65dsi86.c
> +++ b/drivers/gpu/drm/bridge/ti-sn65dsi86.c
> @@ -257,6 +257,12 @@ static int ti_sn_bridge_attach(struct drm_bridge *bridge)
> .node = NULL,
>};
>
> + if (gpiod_get_value(pdata->enable_gpio)) {
> + pm_runtime_enable(pdata->dev);
Does this need to be balanced with a pm_runtime_disable() call ? Bridges
can be attached and detached at runtime when reloading the display
controller drivers, so you need to ensure that detach/re-attach cycles
work.
> + ti_sn_bridge_resume(pdata->dev);
> + ti_sn_bridge_suspend(pdata->dev);
> + }
> +
> ret = drm_connector_init(bridge->dev, &pdata->connector,
>&ti_sn_bridge_connector_funcs,
>DRM_MODE_CONNECTOR_eDP);
> @@ -813,7 +819,7 @@ static int ti_sn_bridge_probe(struct i2c_client *client,
> dev_set_drvdata(&client->dev, pdata);
>
> pdata->enable_gpio = devm_gpiod_get(pdata->dev, "enable",
> - GPIOD_OUT_LOW);
> + GPIOD_ASIS);
> if (IS_ERR(pdata->enable_gpio)) {
> DRM_ERROR("failed to get enable gpio from DT\n");
> ret = PTR_ERR(pdata->enable_gpio);
> @@ -843,7 +849,9 @@ static int ti_sn_bridge_probe(struct i2c_client *client,
> if (ret)
> return ret;
>
> - pm_runtime_enable(pdata->dev);
> + if (!gpiod_get_value(pdata->enable_gpio)) {
> + pm_runtime_enable(pdata->dev);
> + }
If I understand the issue correctly, this is part of an effort to avoid
disabling a potentially display output until we get as close as possible
to display handover, right ? Is there a drawback in always enabling
runtime PM when the bridge is attached instead of at probe time ? I
think we need to come up with a set of rules for bridge driver authors,
otherwise we'll end up with incompatible expectations of bridge drivers
and display controller drivers.
>
> i2c_set_clientdata(client, pdata);
>
--
Regards,
Laurent Pinchart
___
Freedreno mailing list
Freedreno@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/freedreno
Re: [Freedreno] [PATCH 1/4] gpu: Use dev_get_drvdata()
Hi Fuqian,
Thank you for the pach.
On Mon, Jul 01, 2019 at 11:22:35AM +0800, Fuqian Huang wrote:
> Using dev_get_drvdata directly.
This could be expanded a bit. Maybe
"Several drivers cast a struct device pointer to a struct
platform_device pointer only to then call platform_get_drvdata(). These
constructs can be simplified by using dev_get_drvdata() directly."
I would also replace the "gpu: " prefix with "drm: " in the subject
line. With these small issues addressed,
Reviewed-by: Laurent Pinchart
> Signed-off-by: Fuqian Huang
> ---
> drivers/gpu/drm/msm/adreno/adreno_device.c | 6 ++
> drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c | 13 +
> drivers/gpu/drm/msm/disp/mdp5/mdp5_kms.c| 6 ++
> drivers/gpu/drm/msm/dsi/dsi_host.c | 6 ++
> drivers/gpu/drm/msm/msm_drv.c | 3 +--
> drivers/gpu/drm/omapdrm/displays/panel-dsi-cm.c | 15 +--
> drivers/gpu/drm/panfrost/panfrost_device.c | 6 ++
> 7 files changed, 19 insertions(+), 36 deletions(-)
>
> diff --git a/drivers/gpu/drm/msm/adreno/adreno_device.c
> b/drivers/gpu/drm/msm/adreno/adreno_device.c
> index b3deb346a42b..fafd00d2574a 100644
> --- a/drivers/gpu/drm/msm/adreno/adreno_device.c
> +++ b/drivers/gpu/drm/msm/adreno/adreno_device.c
> @@ -403,16 +403,14 @@ static const struct of_device_id dt_match[] = {
> #ifdef CONFIG_PM
> static int adreno_resume(struct device *dev)
> {
> - struct platform_device *pdev = to_platform_device(dev);
> - struct msm_gpu *gpu = platform_get_drvdata(pdev);
> + struct msm_gpu *gpu = dev_get_drvdata(dev);
>
> return gpu->funcs->pm_resume(gpu);
> }
>
> static int adreno_suspend(struct device *dev)
> {
> - struct platform_device *pdev = to_platform_device(dev);
> - struct msm_gpu *gpu = platform_get_drvdata(pdev);
> + struct msm_gpu *gpu = dev_get_drvdata(dev);
>
> return gpu->funcs->pm_suspend(gpu);
> }
> diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
> b/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
> index ae885e5dd07d..6c6f8ca9380f 100644
> --- a/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
> +++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
> @@ -1025,16 +1025,15 @@ static int dpu_bind(struct device *dev, struct device
> *master, void *data)
>
> static void dpu_unbind(struct device *dev, struct device *master, void *data)
> {
> - struct platform_device *pdev = to_platform_device(dev);
> - struct dpu_kms *dpu_kms = platform_get_drvdata(pdev);
> + struct dpu_kms *dpu_kms = dev_get_drvdata(dev);
> struct dss_module_power *mp = &dpu_kms->mp;
>
> msm_dss_put_clk(mp->clk_config, mp->num_clk);
> - devm_kfree(&pdev->dev, mp->clk_config);
> + devm_kfree(dev, mp->clk_config);
> mp->num_clk = 0;
>
> if (dpu_kms->rpm_enabled)
> - pm_runtime_disable(&pdev->dev);
> + pm_runtime_disable(dev);
> }
>
> static const struct component_ops dpu_ops = {
> @@ -1056,8 +1055,7 @@ static int dpu_dev_remove(struct platform_device *pdev)
> static int __maybe_unused dpu_runtime_suspend(struct device *dev)
> {
> int rc = -1;
> - struct platform_device *pdev = to_platform_device(dev);
> - struct dpu_kms *dpu_kms = platform_get_drvdata(pdev);
> + struct dpu_kms *dpu_kms = dev_get_drvdata(dev);
> struct drm_device *ddev;
> struct dss_module_power *mp = &dpu_kms->mp;
>
> @@ -1077,8 +1075,7 @@ static int __maybe_unused dpu_runtime_suspend(struct
> device *dev)
> static int __maybe_unused dpu_runtime_resume(struct device *dev)
> {
> int rc = -1;
> - struct platform_device *pdev = to_platform_device(dev);
> - struct dpu_kms *dpu_kms = platform_get_drvdata(pdev);
> + struct dpu_kms *dpu_kms = dev_get_drvdata(dev);
> struct drm_encoder *encoder;
> struct drm_device *ddev;
> struct dss_module_power *mp = &dpu_kms->mp;
> diff --git a/drivers/gpu/drm/msm/disp/mdp5/mdp5_kms.c
> b/drivers/gpu/drm/msm/disp/mdp5/mdp5_kms.c
> index 901009e1f219..25d1ebb32e73 100644
> --- a/drivers/gpu/drm/msm/disp/mdp5/mdp5_kms.c
> +++ b/drivers/gpu/drm/msm/disp/mdp5/mdp5_kms.c
> @@ -1052,8 +1052,7 @@ static int mdp5_dev_remove(struct platform_device *pdev)
>
> static __maybe_unused int mdp5_runtime_suspend(struct device *dev)
> {
> - struct platform_device *pdev = to_platform_device(dev);
> - struct mdp5_kms *mdp5_kms = platform_get_drvdata(pdev);
> + struct mdp5_kms *mdp5_kms = dev_get_drvdata(dev);
>
> DBG("");
>
> @@ -1062,8 +1061,7 @@ static __maybe_unused int mdp5_
Re: [Freedreno] [PATCH 4/4] drm/bridge: ti-sn65dsi86: use helper to lookup panel-id
Hi Rob,
On Sun, Jun 30, 2019 at 02:50:59PM -0700, Rob Clark wrote:
> On Sun, Jun 30, 2019 at 2:17 PM Laurent Pinchart wrote:
> > On Sun, Jun 30, 2019 at 01:36:08PM -0700, Rob Clark wrote:
> > > From: Rob Clark
> > >
> > > Use the drm_of_find_panel_id() helper to decide which endpoint to use
> > > when looking up panel. This way we can support devices that have
> > > multiple possible panels, such as the aarch64 laptops.
> > >
> > > Signed-off-by: Rob Clark
> > > ---
> > > drivers/gpu/drm/bridge/ti-sn65dsi86.c | 5 +++--
> > > 1 file changed, 3 insertions(+), 2 deletions(-)
> > >
> > > diff --git a/drivers/gpu/drm/bridge/ti-sn65dsi86.c
> > > b/drivers/gpu/drm/bridge/ti-sn65dsi86.c
> > > index 2719d9c0864b..56c66a43f1a6 100644
> > > --- a/drivers/gpu/drm/bridge/ti-sn65dsi86.c
> > > +++ b/drivers/gpu/drm/bridge/ti-sn65dsi86.c
> > > @@ -790,7 +790,7 @@ static int ti_sn_bridge_probe(struct i2c_client
> > > *client,
> > > const struct i2c_device_id *id)
> > > {
> > > struct ti_sn_bridge *pdata;
> > > - int ret;
> > > + int ret, panel_id;
> > >
> > > if (!i2c_check_functionality(client->adapter, I2C_FUNC_I2C)) {
> > > DRM_ERROR("device doesn't support I2C\n");
> > > @@ -811,7 +811,8 @@ static int ti_sn_bridge_probe(struct i2c_client
> > > *client,
> > >
> > > pdata->dev = &client->dev;
> > >
> > > - ret = drm_of_find_panel_or_bridge(pdata->dev->of_node, 1, 0,
> > > + panel_id = drm_of_find_panel_id();
> > > + ret = drm_of_find_panel_or_bridge(pdata->dev->of_node, 1, panel_id,
> > > &pdata->panel, NULL);
> > > if (ret) {
> > > DRM_ERROR("could not find any panel node\n");
> >
> > No, I'm sorry, but that's a no-go. We can't patch every single bridge
> > driver to support this hack. We need a solution implemented at another
> > level that will not spread throughout the whole subsystem.
>
> it could be possible to make a better helper.. but really there aren't
> *that* many bridge drivers
>
> suggestions ofc welcome, but I think one way or another we are going
> to need to patch bridges by the time we get to adding ACPI support, so
> really trivial couple line patches to the handful of bridges we have
> isn't really something that worries me
It's only one right now as that's the only one you care about, but
before we'll have time to blink, it will be another one, and another
one, ... Sorry, that's a no-go for me.
--
Regards,
Laurent Pinchart
___
Freedreno mailing list
Freedreno@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/freedreno
Re: [Freedreno] [PATCH 4/4] drm/bridge: ti-sn65dsi86: use helper to lookup panel-id
Hi Rob,
Thank you for the patch.
On Sun, Jun 30, 2019 at 01:36:08PM -0700, Rob Clark wrote:
> From: Rob Clark
>
> Use the drm_of_find_panel_id() helper to decide which endpoint to use
> when looking up panel. This way we can support devices that have
> multiple possible panels, such as the aarch64 laptops.
>
> Signed-off-by: Rob Clark
> ---
> drivers/gpu/drm/bridge/ti-sn65dsi86.c | 5 +++--
> 1 file changed, 3 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/bridge/ti-sn65dsi86.c
> b/drivers/gpu/drm/bridge/ti-sn65dsi86.c
> index 2719d9c0864b..56c66a43f1a6 100644
> --- a/drivers/gpu/drm/bridge/ti-sn65dsi86.c
> +++ b/drivers/gpu/drm/bridge/ti-sn65dsi86.c
> @@ -790,7 +790,7 @@ static int ti_sn_bridge_probe(struct i2c_client *client,
> const struct i2c_device_id *id)
> {
> struct ti_sn_bridge *pdata;
> - int ret;
> + int ret, panel_id;
>
> if (!i2c_check_functionality(client->adapter, I2C_FUNC_I2C)) {
> DRM_ERROR("device doesn't support I2C\n");
> @@ -811,7 +811,8 @@ static int ti_sn_bridge_probe(struct i2c_client *client,
>
> pdata->dev = &client->dev;
>
> - ret = drm_of_find_panel_or_bridge(pdata->dev->of_node, 1, 0,
> + panel_id = drm_of_find_panel_id();
> + ret = drm_of_find_panel_or_bridge(pdata->dev->of_node, 1, panel_id,
> &pdata->panel, NULL);
> if (ret) {
> DRM_ERROR("could not find any panel node\n");
No, I'm sorry, but that's a no-go. We can't patch every single bridge
driver to support this hack. We need a solution implemented at another
level that will not spread throughout the whole subsystem.
--
Regards,
Laurent Pinchart
___
Freedreno mailing list
Freedreno@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/freedreno
Re: [Freedreno] [PATCH 0/4] drm+dt+efi: support devices with multiple possible panels
Hi Rob, On Sun, Jun 30, 2019 at 02:05:21PM -0700, Rob Clark wrote: > On Sun, Jun 30, 2019 at 1:47 PM Laurent Pinchart wrote: > > On Sun, Jun 30, 2019 at 01:36:04PM -0700, Rob Clark wrote: > > > From: Rob Clark > > > > > > Now that we can deal gracefully with bootloader (firmware) initialized > > > display on aarch64 laptops[1], the next step is to deal with the fact > > > that the same model of laptop can have one of multiple different panels. > > > (For the yoga c630 that I have, I know of at least two possible panels, > > > there might be a third.) > > > > I have to ask the obvious question: why doesn't the boot loader just > > pass a correct DT to Linux ? There's no point in passing a list of > > panels that are not there, this seems quite a big hack to me. A proper > > boot loader should construct the DT based on hardware detection. > > Hi Laurent, > > Actually the bootloader on these devices is passing *no* dt (they boot > ACPI, we are loading dtb from grub currently) Ah, the broken promises of ACPI on ARM64. I wonder how long it will take before a public acknowledgement that it was a bad idea. Bad ideas happen and can be forgiven, but stubborness in claiming it was the right decision is another story. (Not that you can be blamed for this of course :-)) > I think normally a device built w/ dt in mind would populate > /chosen/panel-id directly (rather than the way it is currently > populated based on reading an efi variable prior to ExitBootServices). > But that is considerably easier ask than having it re-write of_graph > bindings. Either way, we aren't in control of the bootloader on these > devices, If you can't control the initial boot loader, then I see two options, none of which you will like I'm afraid. - As you pass the DT to Linux from grub, there's your intermediate boot loader where you can construct a valid DT. - If the ACPI cult needs to be venerated, then drivers should be converted to support ACPI without the need for DT. A possible a middleground could be a platform driver (in drivers/firmware/efi/ ? in drivers/platform/ ?) that will patch the DT to instantiate the right panel based on the information retrieved from the boot loader. We will need something similar for the Intel IPU3 camera driver, as Intel decided to come up with two different ACPI "bindings", one for Windows and one for Chrome OS, leaving Windows machine impossible to handle from a kernel driver due to required information being hardcoded in Windows drivers shipped by Intel. This is thus an option that may (unfortunately) need to become more widespread for ACPI-based systems. > so it is a matter of coming up with something that works on actual hw > that we don't like rather than idealized hw that we don't have ;-) That doesn't however justify not going for the best solution we can achieve. What do you like best in the above ? :-) -- Regards, Laurent Pinchart ___ Freedreno mailing list Freedreno@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/freedreno
Re: [Freedreno] [PATCH 0/4] drm+dt+efi: support devices with multiple possible panels
Hi Rob,
Thank you for the patch.
On Sun, Jun 30, 2019 at 01:36:04PM -0700, Rob Clark wrote:
> From: Rob Clark
>
> Now that we can deal gracefully with bootloader (firmware) initialized
> display on aarch64 laptops[1], the next step is to deal with the fact
> that the same model of laptop can have one of multiple different panels.
> (For the yoga c630 that I have, I know of at least two possible panels,
> there might be a third.)
I have to ask the obvious question: why doesn't the boot loader just
pass a correct DT to Linux ? There's no point in passing a list of
panels that are not there, this seems quite a big hack to me. A proper
boot loader should construct the DT based on hardware detection.
> This is actually a scenario that comes up frequently in phones and
> tablets as well, so it is useful to have an upstream solution for this.
>
> The basic idea is to add a 'panel-id' property in dt chosen node, and
> use that to pick the endpoint we look at when loading the panel driver,
> e.g.
>
> / {
> chosen {
> panel-id = <0xc4>;
> };
>
> ivo_panel {
> compatible = "ivo,m133nwf4-r0";
> power-supply = <&vlcm_3v3>;
> no-hpd;
>
> ports {
> port {
> ivo_panel_in_edp: endpoint {
> remote-endpoint = <&sn65dsi86_out_ivo>;
> };
> };
> };
> };
>
> boe_panel {
> compatible = "boe,nv133fhm-n61";
> power-supply = <&vlcm_3v3>;
> no-hpd;
>
> ports {
> port {
> boe_panel_in_edp: endpoint {
> remote-endpoint = <&sn65dsi86_out_boe>;
> };
> };
> };
> };
>
> sn65dsi86: bridge@2c {
> compatible = "ti,sn65dsi86";
>
> ...
>
> ports {
> #address-cells = <1>;
> #size-cells = <0>;
>
> ...
>
> port@1 {
> #address-cells = <1>;
> #size-cells = <0>;
> reg = <1>;
>
> endpoint@c4 {
> reg = <0xc4>;
> remote-endpoint = <&boe_panel_in_edp>;
> };
>
> endpoint@c5 {
> reg = <0xc5>;
> remote-endpoint = <&ivo_panel_in_edp>;
> };
> };
> };
> }
> };
>
> Note that the panel-id is potentially a sparse-int. The values I've
> seen so far on aarch64 laptops are:
>
> * 0xc2
> * 0xc3
> * 0xc4
> * 0xc5
> * 0x8011
> * 0x8012
> * 0x8055
> * 0x8056
>
> At least on snapdragon aarch64 laptops, they can be any u32 value.
>
> However, on these laptops, the bootloader/firmware is not populating the
> chosen node, but instead providing an "UEFIDisplayInfo" variable, which
> contains the panel id. Unfortunately EFI variables are only available
> before ExitBootServices, so the second patch checks for this variable
> before EBS and populates the /chosen/panel-id variable.
>
> [1] https://patchwork.freedesktop.org/series/63001/
>
> Rob Clark (4):
> dt-bindings: chosen: document panel-id binding
> efi/libstub: detect panel-id
> drm: add helper to lookup panel-id
> drm/bridge: ti-sn65dsi86: use helper to lookup panel-id
>
> Documentation/devicetree/bindings/chosen.txt | 69
> drivers/firmware/efi/libstub/arm-stub.c | 49 ++
> drivers/firmware/efi/libstub/efistub.h | 2 +
> drivers/firmware/efi/libstub/fdt.c | 9 +++
> drivers/gpu/drm/bridge/ti-sn65dsi86.c| 5 +-
> drivers/gpu/drm/drm_of.c | 21 ++
> include/drm/drm_of.h | 7 ++
> 7 files changed, 160 insertions(+), 2 deletions(-)
--
Regards,
Laurent Pinchart
___
Freedreno mailing list
Freedreno@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/freedreno
Re: [Freedreno] [PATCH v3 00/22] Associate ddc adapters with connectors
Hi Andrzej, Just FYI, I have a patch series that reworks how bridges and connectors are handled, and it will heavily conflict with this. The purpose of the two series isn't the same, so both make sense. I will post the patches this weekend, and will then review this series in that context. Hopefully we'll get the best of both worlds :-) On Fri, Jun 28, 2019 at 06:01:14PM +0200, Andrzej Pietrasiewicz wrote: > It is difficult for a user to know which of the i2c adapters is for which > drm connector. This series addresses this problem. > > The idea is to have a symbolic link in connector's sysfs directory, e.g.: > > 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 > > The user then knows that their card0-HDMI-A-1 uses i2c-2 and can e.g. run > ddcutil: > > ddcutil -b 2 getvcp 0x10 > VCP code 0x10 (Brightness): current value =90, max > value = 100 > > The first patch in the series adds struct i2c_adapter pointer to struct > drm_connector. If the field is used by a particular driver, then an > appropriate symbolic link is created by the generic code, which is also added > by this patch. > > The second patch is an example of how to convert a driver to this new scheme. > > v1..v2: > > - used fixed name "ddc" for the symbolic link in order to make it easy for > userspace to find the i2c adapter > > v2..v3: > > - converted as many drivers as possible. > > PATCHES 3/22-22/22 SHOULD BE CONSIDERED RFC! > > Andrzej Pietrasiewicz (22): > drm: Include ddc adapter pointer in struct drm_connector > drm/exynos: Provide ddc symlink in connector's sysfs > drm: rockchip: Provide ddc symlink in rk3066_hdmi sysfs directory > drm: rockchip: Provide ddc symlink in inno_hdmi sysfs directory > drm/msm/hdmi: Provide ddc symlink in hdmi connector sysfs directory > drm/sun4i: hdmi: Provide ddc symlink in sun4i hdmi connector sysfs > directory > drm/mediatek: Provide ddc symlink in hdmi connector sysfs directory > drm/tegra: Provide ddc symlink in output connector sysfs directory > drm/imx: imx-ldb: Provide ddc symlink in connector's sysfs > drm/imx: imx-tve: Provide ddc symlink in connector's sysfs > drm/vc4: Provide ddc symlink in connector sysfs directory > drm: zte: Provide ddc symlink in hdmi connector sysfs directory > drm: zte: Provide ddc symlink in vga connector sysfs directory > drm/tilcdc: Provide ddc symlink in connector sysfs directory > drm: sti: Provide ddc symlink in hdmi connector sysfs directory > drm/mgag200: Provide ddc symlink in connector sysfs directory > drm/ast: Provide ddc symlink in connector sysfs directory > drm/bridge: dumb-vga-dac: Provide ddc symlink in connector sysfs > directory > drm/bridge: dw-hdmi: Provide ddc symlink in connector sysfs directory > drm/bridge: ti-tfp410: Provide ddc symlink in connector sysfs > directory > drm/amdgpu: Provide ddc symlink in connector sysfs directory > drm/radeon: Provide ddc symlink in connector sysfs directory > > .../gpu/drm/amd/amdgpu/amdgpu_connectors.c| 70 +++- > drivers/gpu/drm/ast/ast_mode.c| 1 + > drivers/gpu/drm/bridge/dumb-vga-dac.c | 19 ++--- > drivers/gpu/drm/bridge/synopsys/dw-hdmi.c | 40 - > drivers/gpu/drm/bridge/ti-tfp410.c| 19 ++--- > drivers/gpu/drm/drm_sysfs.c | 7 ++ > drivers/gpu/drm/exynos/exynos_hdmi.c | 11 ++- > drivers/gpu/drm/imx/imx-ldb.c | 13 ++- > drivers/gpu/drm/imx/imx-tve.c | 8 +- > drivers/gpu/drm/mediatek/mtk_hdmi.c | 9 +- > drivers/gpu/drm/mgag200/mgag200_mode.c| 1 + > drivers/gpu/drm/msm/hdmi/hdmi_connector.c | 1 + > drivers/gpu/drm/radeon/radeon_connectors.c| 82 ++- > drivers/gpu/drm/rockchip/inno_hdmi.c | 17 ++-- > drivers/gpu/drm/rockchip/rk3066_hdmi.c| 17 ++-- > drivers/gpu/drm/sti/sti_hdmi.c| 1 + > drivers/gpu/drm/sun4i/sun4i_hdmi.h| 1 - > drivers/gpu/drm/sun4i/sun4i_hdmi_enc.c| 14 ++-- > drivers/gpu/drm/tegra/drm.h | 1 - > drivers/gpu/drm/tegra/output.c| 12 +-- > drivers/gpu/drm/tegra/sor.c | 6 +- > drivers/gpu/drm/tilcdc/tilcdc_tfp410.c| 1 + > drivers/gpu/drm/vc4/vc4_hdmi.c | 16 ++-- > drivers/gpu/drm/zte/zx_hdmi.c | 25 ++ > drivers/gpu/drm/zte/zx_vga.c | 25 ++ > include/drm/drm_connector.h | 11 +++ > 26 files changed, 252 insertions(+), 176 deletions(-) > > -- > 2.17.1 > -- Regards, Laurent Pinchart ___ Freedreno mailing list Freedreno@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/freedreno
Re: [Freedreno] [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-...@lists.freedesktop.org > Cc: linux-media...@lists.infradead.org > Cc: linux-amlo...@lists.infradead.org > Cc: linux-arm-...@vger.kernel.org > Cc: freedreno@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 @@ > #i
Re: [Freedreno] [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 ___ Freedreno mailing list Freedreno@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/freedreno
Re: [Freedreno] [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: freedreno@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 |
