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
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
y 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: Lau
; 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
he 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: La
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
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 a
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
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,
lude/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
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
gt; 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
u 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
gt; + 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
tor*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
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
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: Laur
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/b
00/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 Szyp
c_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 ++++++
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
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
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
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: Laur
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: Laur
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: Laur
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: Laur
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: Laur
ring
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/d
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
> 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_SCRAM
e 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,
> -
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
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
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, 202
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
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 d
odate 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;
&g
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
move 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 |
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, Ma
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
> >
ed 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
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
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
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 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
<< 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
s, 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
; +++ 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
idge_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",
&g
te_device *adev;
> struct component *c;
> size_t i;
> 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
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);
> > > > >
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 fro
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
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
t 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
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:
>
nector->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
gt;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
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 n
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
);
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,
Reviewe
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 Pin
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:
> > > >
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
&g
!= 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
#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. W
st);
>
> 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
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&#
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: L
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/
@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 thi
-
>
> 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_k
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
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
rm_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
ane, 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
&
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-
gt; 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
> in
e);
> 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(
e 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
dded 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 an
> + 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
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
-
> > 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
> 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
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 wrot
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_i
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 heav
lways 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
_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
> ---
>
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() he
&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 im
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 wi
; 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
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
his 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
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 0
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.1
1 - 100 of 113 matches
Mail list logo
