Re: [PATCH RESEND] drm/mediatek: Add 0 size check to mtk_drm_gem_obj
Re: (subset) [PATCH 0/3] drm/panel: Pixel 3a Panel
On Thu, 08 Feb 2024 19:16:41 -0500, Richard Acayan wrote: > This adds support for the AMS559NK06 panel with the S6E3FA7 display > controller and enables the display subsystem on the Pixel 3a. > > Richard Acayan (3): > dt-bindings: display: panel-simple-dsi: add s6e3fa7 ams559nk06 compat > drm/panel: add samsung s6e3fa7 panel driver > arm64: dts: qcom: sdm670-google-sargo: add panel > > [...] Applied, thanks! [3/3] arm64: dts: qcom: sdm670-google-sargo: add panel commit: 232490b925272d54dd91847a183bdbc2deec904b Best regards, -- Bjorn Andersson
Re: [PATCH v2 3/4] drm/msm/dp: Delete the old 500 ms wait for eDP HPD in aux transfer
On Tue, 19 Mar 2024 at 02:19, Abhinav Kumar wrote:
>
> +bjorn, johan as fyi for sc8280xp
>
> On 3/15/2024 2:36 PM, Douglas Anderson wrote:
> > Before the introduction of the wait_hpd_asserted() callback in commit
> > 841d742f094e ("drm/dp: Add wait_hpd_asserted() callback to struct
> > drm_dp_aux") the API between panel drivers and DP AUX bus drivers was
> > that it was up to the AUX bus driver to wait for HPD in the transfer()
> > function.
> >
> > Now wait_hpd_asserted() has been added. The two panel drivers that are
> > DP AUX endpoints use it. See commit 2327b13d6c47 ("drm/panel-edp: Take
> > advantage of wait_hpd_asserted() in struct drm_dp_aux") and commit
> > 3b5765df375c ("drm/panel: atna33xc20: Take advantage of
> > wait_hpd_asserted() in struct drm_dp_aux"). We've implemented
> > wait_hpd_asserted() in the MSM DP driver as of commit e2969ee30252
> > ("drm/msm/dp: move of_dp_aux_populate_bus() to eDP probe()"). There is
> > no longer any reason for long wait in the AUX transfer() function.
> > Remove it.
> >
> > NOTE: the wait_hpd_asserted() is listed as "optional". That means it's
> > optional for the DP AUX bus to implement. In the case of the MSM DP
> > driver we implement it so we can assume it will be called.
> >
>
> How do we enforce that for any new edp panels to be used with MSM, the
> panels should atleast invoke wait_hpd_asserted()?
>
> I agree that since MSM implements it, even though its listed as
> optional, we can drop this additional wait. So nothing wrong with this
> patch for current users including sc8280xp, sc7280 and sc7180.
>
> But, does there need to be some documentation that the edp panels not
> using the panel-edp framework should still invoke wait_hpd_asserted()?
>
> Since its marked as optional, what happens if the edp panel driver,
> skips calling wait_hpd_asserted()?
It is optional for the DP AUX implementations, not for the panel to be called.
>
> Now, since the wait from MSM is removed, it has a potential to fail.
>
> > ALSO NOTE: the wait wasn't actually _hurting_ anything and wasn't even
> > causing long timeouts, but it's still nice to get rid of unneeded
> > code. Specificaly it's not truly needed because to handle other DP
> > drivers that can't power on as quickly (specifically parade-ps8640) we
> > already avoid DP AUX transfers for eDP panels that aren't powered
> > on. See commit 8df1ddb5bf11 ("drm/dp: Don't attempt AUX transfers when
> > eDP panels are not powered").
> >
> > Signed-off-by: Douglas Anderson
> > ---
> >
> > (no changes since v1)
> >
> > drivers/gpu/drm/msm/dp/dp_aux.c | 17 -
> > 1 file changed, 17 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/msm/dp/dp_aux.c
> > b/drivers/gpu/drm/msm/dp/dp_aux.c
> > index 75c51f3ee106..ecefd1922d6d 100644
> > --- a/drivers/gpu/drm/msm/dp/dp_aux.c
> > +++ b/drivers/gpu/drm/msm/dp/dp_aux.c
> > @@ -313,23 +313,6 @@ static ssize_t dp_aux_transfer(struct drm_dp_aux
> > *dp_aux,
> > goto exit;
> > }
> >
> > - /*
> > - * For eDP it's important to give a reasonably long wait here for HPD
> > - * to be asserted. This is because the panel driver may have _just_
> > - * turned on the panel and then tried to do an AUX transfer. The panel
> > - * driver has no way of knowing when the panel is ready, so it's up
> > - * to us to wait. For DP we never get into this situation so let's
> > - * avoid ever doing the extra long wait for DP.
> > - */
> > - if (aux->is_edp) {
> > - ret = dp_catalog_aux_wait_for_hpd_connect_state(aux->catalog,
> > - 50);
> > - if (ret) {
> > - DRM_DEBUG_DP("Panel not ready for aux
> > transactions\n");
> > - goto exit;
> > - }
> > - }
> > -
> > dp_aux_update_offset_and_segment(aux, msg);
> > dp_aux_transfer_helper(aux, msg, true);
> >
--
With best wishes
Dmitry
Re: [PATCH v2 5/8] drm: xlnx: zynqmp_dpsub: Set input live format
Hi Anatoliy,
Thank you for the patch.
On Tue, Mar 12, 2024 at 05:55:02PM -0700, Anatoliy Klymenko wrote:
> Program live video input format according to selected media bus format.
>
> In the bridge mode of operation, DPSUB is connected to FPGA CRTC which
> almost certainly supports a single media bus format as its output. Expect
> this to be delivered via the new bridge atomic state. Program DPSUB
> registers accordingly.
No line breaks within paragraphs. Add a blank line if you want to
paragraphs, remove the line break otherwise.
> Update zynqmp_disp_layer_set_format() API to fit both live and non-live
> layer types.
>
> Signed-off-by: Anatoliy Klymenko
> ---
> drivers/gpu/drm/xlnx/zynqmp_disp.c | 93
> +++---
> drivers/gpu/drm/xlnx/zynqmp_disp.h | 2 +-
> drivers/gpu/drm/xlnx/zynqmp_dp.c | 13 --
> drivers/gpu/drm/xlnx/zynqmp_kms.c | 2 +-
> 4 files changed, 87 insertions(+), 23 deletions(-)
>
> diff --git a/drivers/gpu/drm/xlnx/zynqmp_disp.c
> b/drivers/gpu/drm/xlnx/zynqmp_disp.c
> index dd48fa60fa9a..0cacd597f4b8 100644
> --- a/drivers/gpu/drm/xlnx/zynqmp_disp.c
> +++ b/drivers/gpu/drm/xlnx/zynqmp_disp.c
> @@ -383,7 +383,7 @@ static const struct zynqmp_disp_format avbuf_live_fmts[]
> = {
> ZYNQMP_DISP_AV_BUF_LIVE_CONFIG_FMT_RGB,
> .sf = scaling_factors_666,
> }, {
> - .bus_fmt= MEDIA_BUS_FMT_UYVY8_1X24,
> + .bus_fmt= MEDIA_BUS_FMT_RBG888_1X24,
Does this belong to a previous patch ?
> .buf_fmt= ZYNQMP_DISP_AV_BUF_LIVE_CONFIG_BPC_8 |
> ZYNQMP_DISP_AV_BUF_LIVE_CONFIG_FMT_RGB,
> .sf = scaling_factors_888,
> @@ -433,19 +433,28 @@ static void zynqmp_disp_avbuf_set_format(struct
> zynqmp_disp *disp,
>const struct zynqmp_disp_format *fmt)
> {
> unsigned int i;
> - u32 val;
> + u32 val, reg;
>
> - val = zynqmp_disp_avbuf_read(disp, ZYNQMP_DISP_AV_BUF_FMT);
> - val &= zynqmp_disp_layer_is_video(layer)
> - ? ~ZYNQMP_DISP_AV_BUF_FMT_NL_VID_MASK
> - : ~ZYNQMP_DISP_AV_BUF_FMT_NL_GFX_MASK;
> - val |= fmt->buf_fmt;
> - zynqmp_disp_avbuf_write(disp, ZYNQMP_DISP_AV_BUF_FMT, val);
> + layer->disp_fmt = fmt;
> + if (layer->mode == ZYNQMP_DPSUB_LAYER_NONLIVE) {
> + reg = ZYNQMP_DISP_AV_BUF_FMT;
> + val = zynqmp_disp_avbuf_read(disp, ZYNQMP_DISP_AV_BUF_FMT);
> + val &= zynqmp_disp_layer_is_video(layer)
> + ? ~ZYNQMP_DISP_AV_BUF_FMT_NL_VID_MASK
> + : ~ZYNQMP_DISP_AV_BUF_FMT_NL_GFX_MASK;
> + val |= fmt->buf_fmt;
> + } else {
> + reg = zynqmp_disp_layer_is_video(layer)
> + ? ZYNQMP_DISP_AV_BUF_LIVE_VID_CONFIG
> + : ZYNQMP_DISP_AV_BUF_LIVE_GFX_CONFIG;
> + val = fmt->buf_fmt;
> + }
> + zynqmp_disp_avbuf_write(disp, reg, val);
>
> for (i = 0; i < ZYNQMP_DISP_AV_BUF_NUM_SF; i++) {
> - unsigned int reg = zynqmp_disp_layer_is_video(layer)
> - ? ZYNQMP_DISP_AV_BUF_VID_COMP_SF(i)
> - : ZYNQMP_DISP_AV_BUF_GFX_COMP_SF(i);
> + reg = zynqmp_disp_layer_is_video(layer)
> + ? ZYNQMP_DISP_AV_BUF_VID_COMP_SF(i)
> + : ZYNQMP_DISP_AV_BUF_GFX_COMP_SF(i);
>
> zynqmp_disp_avbuf_write(disp, reg, fmt->sf[i]);
> }
> @@ -984,23 +993,73 @@ void zynqmp_disp_layer_disable(struct zynqmp_disp_layer
> *layer)
> zynqmp_disp_blend_layer_disable(layer->disp, layer);
> }
>
> +struct zynqmp_disp_bus_to_drm {
> + u32 bus_fmt;
> + u32 drm_fmt;
> +};
> +
> +/**
> + * zynqmp_disp_reference_drm_format - Get reference DRM format corresponding
> + * to the given media bus format.
> + * @bus_format: Media bus format
> + *
> + * Map media bus format to some DRM format that represents the same color
> space
> + * and chroma subsampling as the @bus_format video signal. These DRM format
> + * properties are required to program the blender.
> + *
> + * Return: DRM format code corresponding to @bus_format
> + */
> +static u32 zynqmp_disp_reference_drm_format(u32 bus_format)
> +{
> + static const struct zynqmp_disp_bus_to_drm format_map[] = {
> + {
> + .bus_fmt = MEDIA_BUS_FMT_RGB666_1X18,
> + .drm_fmt = DRM_FORMAT_RGB565,
> + }, {
> + .bus_fmt = MEDIA_BUS_FMT_RBG888_1X24,
> + .drm_fmt = DRM_FORMAT_RGB888,
> + }, {
> + .bus_fmt = MEDIA_BUS_FMT_UYVY8_1X16,
> + .drm_fmt = DRM_FORMAT_YUV422,
> + }, {
> + .bus_fmt = MEDIA_BUS_FMT_VUY8_1X24,
> + .drm_fmt = DRM_FORMAT_YUV444,
> + }, {
> + .bus_fmt = MEDIA_BUS_
Re: [PATCH v2 4/4] drm/msm/dp: Fix typo in static function (ststus => status)
On 3/18/2024 12:37 PM, Doug Anderson wrote:
Hi,
On Mon, Mar 18, 2024 at 12:26 PM Stephen Boyd wrote:
Quoting Douglas Anderson (2024-03-15 14:36:32)
This is a no-op change to just fix a typo in the name of a static function.
Signed-off-by: Douglas Anderson
---
Changes in v2:
- ("Fix typo in static function (ststus => status)") new for v2.
This was sent at
https://lore.kernel.org/r/20240306193515.455388-1-quic_abhin...@quicinc.com
Whoops! I guess we both noticed it at about the same time. My patch
should be dropped then. The rest of my series (patches #1 - #3) are
still relevant. I won't repost them since they can be applied just
fine even if this patch is dropped.
-Doug
Thanks for the patch.
I will pick up
https://lore.kernel.org/r/20240306193515.455388-1-quic_abhin...@quicinc.com
for -fixes so you can drop this one.
Re: [PATCH v2 3/4] drm/msm/dp: Delete the old 500 ms wait for eDP HPD in aux transfer
+bjorn, johan as fyi for sc8280xp
On 3/15/2024 2:36 PM, Douglas Anderson wrote:
Before the introduction of the wait_hpd_asserted() callback in commit
841d742f094e ("drm/dp: Add wait_hpd_asserted() callback to struct
drm_dp_aux") the API between panel drivers and DP AUX bus drivers was
that it was up to the AUX bus driver to wait for HPD in the transfer()
function.
Now wait_hpd_asserted() has been added. The two panel drivers that are
DP AUX endpoints use it. See commit 2327b13d6c47 ("drm/panel-edp: Take
advantage of wait_hpd_asserted() in struct drm_dp_aux") and commit
3b5765df375c ("drm/panel: atna33xc20: Take advantage of
wait_hpd_asserted() in struct drm_dp_aux"). We've implemented
wait_hpd_asserted() in the MSM DP driver as of commit e2969ee30252
("drm/msm/dp: move of_dp_aux_populate_bus() to eDP probe()"). There is
no longer any reason for long wait in the AUX transfer() function.
Remove it.
NOTE: the wait_hpd_asserted() is listed as "optional". That means it's
optional for the DP AUX bus to implement. In the case of the MSM DP
driver we implement it so we can assume it will be called.
How do we enforce that for any new edp panels to be used with MSM, the
panels should atleast invoke wait_hpd_asserted()?
I agree that since MSM implements it, even though its listed as
optional, we can drop this additional wait. So nothing wrong with this
patch for current users including sc8280xp, sc7280 and sc7180.
But, does there need to be some documentation that the edp panels not
using the panel-edp framework should still invoke wait_hpd_asserted()?
Since its marked as optional, what happens if the edp panel driver,
skips calling wait_hpd_asserted()?
Now, since the wait from MSM is removed, it has a potential to fail.
ALSO NOTE: the wait wasn't actually _hurting_ anything and wasn't even
causing long timeouts, but it's still nice to get rid of unneeded
code. Specificaly it's not truly needed because to handle other DP
drivers that can't power on as quickly (specifically parade-ps8640) we
already avoid DP AUX transfers for eDP panels that aren't powered
on. See commit 8df1ddb5bf11 ("drm/dp: Don't attempt AUX transfers when
eDP panels are not powered").
Signed-off-by: Douglas Anderson
---
(no changes since v1)
drivers/gpu/drm/msm/dp/dp_aux.c | 17 -
1 file changed, 17 deletions(-)
diff --git a/drivers/gpu/drm/msm/dp/dp_aux.c b/drivers/gpu/drm/msm/dp/dp_aux.c
index 75c51f3ee106..ecefd1922d6d 100644
--- a/drivers/gpu/drm/msm/dp/dp_aux.c
+++ b/drivers/gpu/drm/msm/dp/dp_aux.c
@@ -313,23 +313,6 @@ static ssize_t dp_aux_transfer(struct drm_dp_aux *dp_aux,
goto exit;
}
- /*
-* For eDP it's important to give a reasonably long wait here for HPD
-* to be asserted. This is because the panel driver may have _just_
-* turned on the panel and then tried to do an AUX transfer. The panel
-* driver has no way of knowing when the panel is ready, so it's up
-* to us to wait. For DP we never get into this situation so let's
-* avoid ever doing the extra long wait for DP.
-*/
- if (aux->is_edp) {
- ret = dp_catalog_aux_wait_for_hpd_connect_state(aux->catalog,
- 50);
- if (ret) {
- DRM_DEBUG_DP("Panel not ready for aux transactions\n");
- goto exit;
- }
- }
-
dp_aux_update_offset_and_segment(aux, msg);
dp_aux_transfer_helper(aux, msg, true);
Re: [PATCH v2 4/8] drm: xlnx: zynqmp_dpsub: Minimize usage of global flag
Hi Anatoliy,
Thank you for the patch.
On Tue, Mar 12, 2024 at 05:55:01PM -0700, Anatoliy Klymenko wrote:
> Avoid usage of global zynqmp_dpsub.dma_enabled flag in DPSUB layer
> context. This flag signals whether the driver runs in DRM CRTC or DRM
> bridge mode, assuming that all display layers share the same live or
> non-live mode of operation. Using per-layer mode instead of global flag
> will siplify future support of the hybrid scenario.
s/siplify/simplify/
> Signed-off-by: Anatoliy Klymenko
> ---
> drivers/gpu/drm/xlnx/zynqmp_disp.c | 11 ---
> 1 file changed, 4 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/gpu/drm/xlnx/zynqmp_disp.c
> b/drivers/gpu/drm/xlnx/zynqmp_disp.c
> index af851190f447..dd48fa60fa9a 100644
> --- a/drivers/gpu/drm/xlnx/zynqmp_disp.c
> +++ b/drivers/gpu/drm/xlnx/zynqmp_disp.c
> @@ -975,7 +975,7 @@ void zynqmp_disp_layer_disable(struct zynqmp_disp_layer
> *layer)
> {
> unsigned int i;
>
> - if (layer->disp->dpsub->dma_enabled) {
> + if (layer->mode == ZYNQMP_DPSUB_LAYER_NONLIVE) {
> for (i = 0; i < layer->drm_fmt->num_planes; i++)
> dmaengine_terminate_sync(layer->dmas[i].chan);
> }
> @@ -1001,7 +1001,7 @@ void zynqmp_disp_layer_set_format(struct
> zynqmp_disp_layer *layer,
>
> zynqmp_disp_avbuf_set_format(layer->disp, layer, layer->disp_fmt);
>
> - if (!layer->disp->dpsub->dma_enabled)
> + if (layer->mode == ZYNQMP_DPSUB_LAYER_LIVE)
> return;
>
> /*
> @@ -1039,7 +1039,7 @@ int zynqmp_disp_layer_update(struct zynqmp_disp_layer
> *layer,
> const struct drm_format_info *info = layer->drm_fmt;
> unsigned int i;
>
> - if (!layer->disp->dpsub->dma_enabled)
> + if (layer->mode == ZYNQMP_DPSUB_LAYER_LIVE)
> return 0;
The above changes look nice.
>
> for (i = 0; i < info->num_planes; i++) {
> @@ -1089,7 +1089,7 @@ static void zynqmp_disp_layer_release_dma(struct
> zynqmp_disp *disp,
> {
> unsigned int i;
>
> - if (!layer->info || !disp->dpsub->dma_enabled)
> + if (!layer->info)
This, however, doesn't seem right, as this function is called
unconditionally from the remove path. The change below seems weird too.
If I'm missing something, it should at least be explained in the commit
message.
> return;
>
> for (i = 0; i < layer->info->num_channels; i++) {
> @@ -1132,9 +1132,6 @@ static int zynqmp_disp_layer_request_dma(struct
> zynqmp_disp *disp,
> unsigned int i;
> int ret;
>
> - if (!disp->dpsub->dma_enabled)
> - return 0;
> -
> for (i = 0; i < layer->info->num_channels; i++) {
> struct zynqmp_disp_layer_dma *dma = &layer->dmas[i];
> char dma_channel_name[16];
>
--
Regards,
Laurent Pinchart
Re: [PATCH v2 3/8] drm: xlnx: zynqmp_dpsub: Anounce supported input formats
Hi Anatoliy,
Thank you for the patch.
On Tue, Mar 12, 2024 at 05:55:00PM -0700, Anatoliy Klymenko wrote:
> DPSUB in bridge mode supports multiple input media bus formats.
>
> Announce the list of supported input media bus formats via
> drm_bridge.atomic_get_input_bus_fmts callback.
> Introduce a set of live input formats, supported by DPSUB.
> Rename zynqmp_disp_layer_drm_formats() to zynqmp_disp_layer_formats() to
> reflect semantics for both live and non-live layer format lists.
>
> Signed-off-by: Anatoliy Klymenko
> ---
> drivers/gpu/drm/xlnx/zynqmp_disp.c | 67
> +-
> drivers/gpu/drm/xlnx/zynqmp_disp.h | 4 +--
> drivers/gpu/drm/xlnx/zynqmp_dp.c | 26 +++
> drivers/gpu/drm/xlnx/zynqmp_kms.c | 2 +-
> 4 files changed, 88 insertions(+), 11 deletions(-)
>
> diff --git a/drivers/gpu/drm/xlnx/zynqmp_disp.c
> b/drivers/gpu/drm/xlnx/zynqmp_disp.c
> index e6d26ef60e89..af851190f447 100644
> --- a/drivers/gpu/drm/xlnx/zynqmp_disp.c
> +++ b/drivers/gpu/drm/xlnx/zynqmp_disp.c
> @@ -18,6 +18,7 @@
> #include
> #include
> #include
> +#include
> #include
> #include
> #include
> @@ -77,12 +78,16 @@ enum zynqmp_dpsub_layer_mode {
> /**
> * struct zynqmp_disp_format - Display subsystem format information
> * @drm_fmt: DRM format (4CC)
> + * @bus_fmt: Media bus format
> * @buf_fmt: AV buffer format
> * @swap: Flag to swap R & B for RGB formats, and U & V for YUV formats
> * @sf: Scaling factors for color components
> */
> struct zynqmp_disp_format {
> - u32 drm_fmt;
> + union {
> + u32 drm_fmt;
> + u32 bus_fmt;
> + };
I'm not a big fan of the union, but I can live with it.
> u32 buf_fmt;
> bool swap;
> const u32 *sf;
> @@ -182,6 +187,12 @@ static const u32 scaling_factors_565[] = {
> ZYNQMP_DISP_AV_BUF_5BIT_SF,
> };
>
> +static const u32 scaling_factors_666[] = {
> + ZYNQMP_DISP_AV_BUF_6BIT_SF,
> + ZYNQMP_DISP_AV_BUF_6BIT_SF,
> + ZYNQMP_DISP_AV_BUF_6BIT_SF,
> +};
> +
> static const u32 scaling_factors_888[] = {
> ZYNQMP_DISP_AV_BUF_8BIT_SF,
> ZYNQMP_DISP_AV_BUF_8BIT_SF,
> @@ -364,6 +375,36 @@ static const struct zynqmp_disp_format avbuf_gfx_fmts[]
> = {
> },
> };
>
> +/* List of live video layer formats */
> +static const struct zynqmp_disp_format avbuf_live_fmts[] = {
> + {
> + .bus_fmt= MEDIA_BUS_FMT_RGB666_1X18,
> + .buf_fmt= ZYNQMP_DISP_AV_BUF_LIVE_CONFIG_BPC_6 |
> + ZYNQMP_DISP_AV_BUF_LIVE_CONFIG_FMT_RGB,
> + .sf = scaling_factors_666,
> + }, {
> + .bus_fmt= MEDIA_BUS_FMT_UYVY8_1X24,
> + .buf_fmt= ZYNQMP_DISP_AV_BUF_LIVE_CONFIG_BPC_8 |
> + ZYNQMP_DISP_AV_BUF_LIVE_CONFIG_FMT_RGB,
> + .sf = scaling_factors_888,
> + }, {
> + .bus_fmt= MEDIA_BUS_FMT_UYVY8_1X16,
> + .buf_fmt= ZYNQMP_DISP_AV_BUF_LIVE_CONFIG_BPC_8 |
> + ZYNQMP_DISP_AV_BUF_LIVE_CONFIG_FMT_YUV422,
> + .sf = scaling_factors_888,
> + }, {
> + .bus_fmt= MEDIA_BUS_FMT_VUY8_1X24,
> + .buf_fmt= ZYNQMP_DISP_AV_BUF_LIVE_CONFIG_BPC_8 |
> + ZYNQMP_DISP_AV_BUF_LIVE_CONFIG_FMT_YUV444,
> + .sf = scaling_factors_888,
> + }, {
> + .bus_fmt= MEDIA_BUS_FMT_UYVY10_1X20,
> + .buf_fmt= ZYNQMP_DISP_AV_BUF_LIVE_CONFIG_BPC_10 |
> + ZYNQMP_DISP_AV_BUF_LIVE_CONFIG_FMT_YUV422,
> + .sf = scaling_factors_101010,
> + },
> +};
> +
> static u32 zynqmp_disp_avbuf_read(struct zynqmp_disp *disp, int reg)
> {
> return readl(disp->avbuf.base + reg);
> @@ -883,16 +924,17 @@ zynqmp_disp_layer_find_format(struct zynqmp_disp_layer
> *layer,
> }
>
> /**
> - * zynqmp_disp_layer_drm_formats - Return the DRM formats supported by the
> layer
> + * zynqmp_disp_layer_formats - Return DRM or media bus formats supported by
> + * the layer
> * @layer: The layer
> * @num_formats: Pointer to the returned number of formats
> *
> - * Return: A newly allocated u32 array that stores all the DRM formats
> + * Return: A newly allocated u32 array that stores all DRM or media bus
> formats
> * supported by the layer. The number of formats in the array is returned
> * through the num_formats argument.
> */
> -u32 *zynqmp_disp_layer_drm_formats(struct zynqmp_disp_layer *layer,
> -unsigned int *num_formats)
> +u32 *zynqmp_disp_layer_formats(struct zynqmp_disp_layer *layer,
> +unsigned int *num_formats)
> {
> unsigned int i;
> u32 *formats;
> @@ -1131,6 +1173,11 @@ static int zynqmp_disp_create_layers(struct
> zynqmp_disp *disp)
>
[PATCH] video: fbdev: au1200fb: replace deprecated strncpy with strscpy
strncpy() is deprecated for use on NUL-terminated destination strings
[1] and as such we should prefer more robust and less ambiguous string
interfaces.
Let's use the new 2-argument strscpy() which guarantees NUL-termination
on the destination buffer while also simplifying the syntax. Note that
strscpy() will not NUL-pad the destination buffer like strncpy() does.
However, the NUL-padding behavior of strncpy() is not required since
fbdev is already NUL-allocated from au1200fb_drv_probe() ->
frameuffer_alloc(), rendering any additional NUL-padding redundant.
| p = kzalloc(fb_info_size + size, GFP_KERNEL);
Link:
https://www.kernel.org/doc/html/latest/process/deprecated.html#strncpy-on-nul-terminated-strings
[1]
Link: https://manpages.debian.org/testing/linux-manual-4.8/strscpy.9.en.html [2]
Link: https://github.com/KSPP/linux/issues/90
Cc: linux-harden...@vger.kernel.org
Signed-off-by: Justin Stitt
---
Note: build-tested only.
Found with: $ rg "strncpy\("
---
drivers/video/fbdev/au1200fb.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/video/fbdev/au1200fb.c b/drivers/video/fbdev/au1200fb.c
index 6f20efc663d7..e718fea63662 100644
--- a/drivers/video/fbdev/au1200fb.c
+++ b/drivers/video/fbdev/au1200fb.c
@@ -1557,7 +1557,7 @@ static int au1200fb_init_fbinfo(struct au1200fb_device
*fbdev)
return ret;
}
- strncpy(fbi->fix.id, "AU1200", sizeof(fbi->fix.id));
+ strscpy(fbi->fix.id, "AU1200");
fbi->fix.smem_start = fbdev->fb_phys;
fbi->fix.smem_len = fbdev->fb_len;
fbi->fix.type = FB_TYPE_PACKED_PIXELS;
---
base-commit: bf3a69c6861ff4dc7892d895c87074af7bc1c400
change-id: 20240318-strncpy-drivers-video-fbdev-au1200fb-c-7bc337998096
Best regards,
--
Justin Stitt
[PATCH] software node: Implement device_get_match_data fwnode callback
This makes it possible to support (and/or test) a few drivers that
originates from DT World on the x86-64 platform. Originally, those
drivers using the of_device_get_match_data() function to get match
data. For example, drivers/gpu/drm/bridge/simple-bridge.c and
drivers/gpu/drm/bridge/display-connector.c. Those drivers works very
well in the DT world, however, there is no counterpart to
of_device_get_match_data() when porting them to the x86 platform,
because x86 CPUs lack DT support.
By replacing it with device_get_match_data() and creating a software
graph that mimics the OF graph, everything else works fine, except that
there isn't an out-of-box replacement for the of_device_get_match_data()
function. Because the software node backend of the fwnode framework lacks
an implementation for the device_get_match_data callback.
Implement device_get_match_data fwnode callback fwnode callback to fill
this gap. Device drivers or platform setup codes are expected to provide
a "compatible" string property. The value of this string property is used
to match against the compatible entries in the of_device_id table. Which
is consistent with the original usage style.
Signed-off-by: Sui Jingfeng
---
drivers/base/swnode.c | 26 ++
1 file changed, 26 insertions(+)
diff --git a/drivers/base/swnode.c b/drivers/base/swnode.c
index 36512fb75a20..3670094592f2 100644
--- a/drivers/base/swnode.c
+++ b/drivers/base/swnode.c
@@ -8,6 +8,7 @@
#include
#include
+#include
#include
#include
@@ -379,6 +380,30 @@ static void software_node_put(struct fwnode_handle *fwnode)
kobject_put(&swnode->kobj);
}
+static const void *
+software_node_get_match_data(const struct fwnode_handle *fwnode,
+const struct device *dev)
+{
+ struct swnode *swnode = to_swnode(fwnode);
+ const struct of_device_id *matches = dev->driver->of_match_table;
+ const char *val = NULL;
+ int ret;
+
+ ret = property_entry_read_string_array(swnode->node->properties,
+ "compatible", &val, 1);
+ if (ret < 0 || !val)
+ return NULL;
+
+ while (matches && matches->compatible[0]) {
+ if (!strcmp(matches->compatible, val))
+ return matches->data;
+
+ matches++;
+ }
+
+ return NULL;
+}
+
static bool software_node_property_present(const struct fwnode_handle *fwnode,
const char *propname)
{
@@ -665,6 +690,7 @@ software_node_graph_parse_endpoint(const struct
fwnode_handle *fwnode,
static const struct fwnode_operations software_node_ops = {
.get = software_node_get,
.put = software_node_put,
+ .device_get_match_data = software_node_get_match_data,
.property_present = software_node_property_present,
.property_read_int_array = software_node_read_int_array,
.property_read_string_array = software_node_read_string_array,
--
2.34.1
Re: [PATCH v2 2/8] drm: xlnx: zynqmp_dpsub: Update live format defines
Hi Anatoliy, Thank you for the patch. On Tue, Mar 12, 2024 at 05:54:59PM -0700, Anatoliy Klymenko wrote: > Update live format defines to match DPSUB AV_BUF_LIVE_VID_CONFIG register > layout. > > Signed-off-by: Anatoliy Klymenko Reviewed-by: Laurent Pinchart > --- > drivers/gpu/drm/xlnx/zynqmp_disp_regs.h | 8 > 1 file changed, 4 insertions(+), 4 deletions(-) > > diff --git a/drivers/gpu/drm/xlnx/zynqmp_disp_regs.h > b/drivers/gpu/drm/xlnx/zynqmp_disp_regs.h > index f92a006d5070..fa3935384834 100644 > --- a/drivers/gpu/drm/xlnx/zynqmp_disp_regs.h > +++ b/drivers/gpu/drm/xlnx/zynqmp_disp_regs.h > @@ -165,10 +165,10 @@ > #define ZYNQMP_DISP_AV_BUF_LIVE_CONFIG_BPC_100x2 > #define ZYNQMP_DISP_AV_BUF_LIVE_CONFIG_BPC_120x3 > #define ZYNQMP_DISP_AV_BUF_LIVE_CONFIG_BPC_MASK GENMASK(2, 0) > -#define ZYNQMP_DISP_AV_BUF_LIVE_CONFIG_FMT_RGB 0x0 > -#define ZYNQMP_DISP_AV_BUF_LIVE_CONFIG_FMT_YUV4440x1 > -#define ZYNQMP_DISP_AV_BUF_LIVE_CONFIG_FMT_YUV4220x2 > -#define ZYNQMP_DISP_AV_BUF_LIVE_CONFIG_FMT_YONLY 0x3 > +#define ZYNQMP_DISP_AV_BUF_LIVE_CONFIG_FMT_RGB (0x0 << 4) > +#define ZYNQMP_DISP_AV_BUF_LIVE_CONFIG_FMT_YUV444(0x1 << 4) > +#define ZYNQMP_DISP_AV_BUF_LIVE_CONFIG_FMT_YUV422(0x2 << 4) > +#define ZYNQMP_DISP_AV_BUF_LIVE_CONFIG_FMT_YONLY (0x3 << 4) > #define ZYNQMP_DISP_AV_BUF_LIVE_CONFIG_FMT_MASK GENMASK(5, 4) > #define ZYNQMP_DISP_AV_BUF_LIVE_CONFIG_CB_FIRST BIT(8) > #define ZYNQMP_DISP_AV_BUF_PALETTE_MEMORY0x400 > -- Regards, Laurent Pinchart
Re: [01/43] drm/fbdev-generic: Do not set physical framebuffer address
Hi,
On 2024/3/12 23:44, Thomas Zimmermann wrote:
Framebuffer memory is allocated via vmalloc() from non-contiguous
physical pages. The physical framebuffer start address is therefore
meaningless. Do not set it.
The value is not used within the kernel and only exported to userspace
on dedicated ARM configs. No functional change is expected.
Signed-off-by: Thomas Zimmermann
Fixes: a5b44c4adb16 ("drm/fbdev-generic: Always use shadow buffering")
Cc: Thomas Zimmermann
Cc: Javier Martinez Canillas
Cc: Zack Rusin
Cc: Maarten Lankhorst
Cc: Maxime Ripard
Cc: # v6.4+
Reviewed-by: Javier Martinez Canillas
Reviewed-by: Zack Rusin
Reviewed-by: Sui Jingfeng
Tested-by: Sui Jingfeng
--
Best regards,
Sui
[PATCH v9 3/3] drm/tests: Add a test case for drm buddy clear allocation
Add a new test case for the drm buddy clear and dirty
allocation.
Signed-off-by: Arunpravin Paneer Selvam
Suggested-by: Matthew Auld
---
drivers/gpu/drm/tests/drm_buddy_test.c | 127 +
1 file changed, 127 insertions(+)
diff --git a/drivers/gpu/drm/tests/drm_buddy_test.c
b/drivers/gpu/drm/tests/drm_buddy_test.c
index 454ad9952f56..d355a6e61893 100644
--- a/drivers/gpu/drm/tests/drm_buddy_test.c
+++ b/drivers/gpu/drm/tests/drm_buddy_test.c
@@ -19,6 +19,132 @@ static inline u64 get_size(int order, u64 chunk_size)
return (1 << order) * chunk_size;
}
+static void drm_test_buddy_alloc_clear(struct kunit *test)
+{
+ unsigned long n_pages, total, i = 0;
+ const unsigned long ps = SZ_4K;
+ struct drm_buddy_block *block;
+ const int max_order = 12;
+ LIST_HEAD(allocated);
+ struct drm_buddy mm;
+ unsigned int order;
+ u64 mm_size, size;
+ LIST_HEAD(dirty);
+ LIST_HEAD(clean);
+
+ mm_size = PAGE_SIZE << max_order;
+ KUNIT_EXPECT_FALSE(test, drm_buddy_init(&mm, mm_size, ps));
+
+ KUNIT_EXPECT_EQ(test, mm.max_order, max_order);
+
+ /**
+* Idea is to allocate and free some random portion of the address
space,
+* returning those pages as non-dirty and randomly alternate between
+* requesting dirty and non-dirty pages (not going over the limit
+* we freed as non-dirty), putting that into two separate lists.
+* Loop over both lists at the end checking that the dirty list
+* is indeed all dirty pages and vice versa. Free it all again,
+* keeping the dirty/clear status.
+*/
+ KUNIT_ASSERT_FALSE_MSG(test, drm_buddy_alloc_blocks(&mm, 0, mm_size,
+ 5 * ps, ps,
&allocated,
+
DRM_BUDDY_TOPDOWN_ALLOCATION),
+ "buddy_alloc hit an error size=%u\n", 5 * ps);
+ drm_buddy_free_list(&mm, &allocated, DRM_BUDDY_CLEARED);
+
+ n_pages = 10;
+ do {
+ unsigned long flags;
+ struct list_head *list;
+ int slot = i % 2;
+
+ if (slot == 0) {
+ list = &dirty;
+ flags = 0;
+ } else if (slot == 1) {
+ list = &clean;
+ flags = DRM_BUDDY_CLEAR_ALLOCATION;
+ }
+
+ KUNIT_ASSERT_FALSE_MSG(test, drm_buddy_alloc_blocks(&mm, 0,
mm_size,
+ ps, ps,
list,
+ flags),
+ "buddy_alloc hit an error size=%u\n",
ps);
+ } while (++i < n_pages);
+
+ list_for_each_entry(block, &clean, link)
+ KUNIT_EXPECT_EQ(test, drm_buddy_block_is_clear(block), true);
+
+ list_for_each_entry(block, &dirty, link)
+ KUNIT_EXPECT_EQ(test, drm_buddy_block_is_clear(block), false);
+
+ drm_buddy_free_list(&mm, &clean, DRM_BUDDY_CLEARED);
+
+ /**
+* Trying to go over the clear limit for some allocation.
+* The allocation should never fail with reasonable page-size.
+*/
+ KUNIT_ASSERT_FALSE_MSG(test, drm_buddy_alloc_blocks(&mm, 0, mm_size,
+ 10 * ps, ps, &clean,
+
DRM_BUDDY_CLEAR_ALLOCATION),
+ "buddy_alloc hit an error size=%u\n", 10 * ps);
+
+ drm_buddy_free_list(&mm, &clean, DRM_BUDDY_CLEARED);
+ drm_buddy_free_list(&mm, &dirty, 0);
+ drm_buddy_fini(&mm);
+
+ KUNIT_EXPECT_FALSE(test, drm_buddy_init(&mm, mm_size, ps));
+
+ /**
+* Create a new mm. Intentionally fragment the address space by creating
+* two alternating lists. Free both lists, one as dirty the other as
clean.
+* Try to allocate double the previous size with matching
min_page_size. The
+* allocation should never fail as it calls the force_merge. Also check
that
+* the page is always dirty after force_merge. Free the page as dirty,
then
+* repeat the whole thing, increment the order until we hit the
max_order.
+*/
+
+ order = 1;
+ do {
+ size = PAGE_SIZE << order;
+ i = 0;
+ n_pages = mm_size / ps;
+ do {
+ struct list_head *list;
+ int slot = i % 2;
+
+ if (slot == 0)
+ list = &dirty;
+ else if (slot == 1)
+ list = &clean;
+
+ KUNIT_ASSERT_FALSE_MSG(test,
+ drm_buddy_alloc_blocks(&mm, 0,
mm_size,
+
[PATCH v9 2/3] drm/amdgpu: Enable clear page functionality
Add clear page support in vram memory region.
v1(Christian):
- Dont handle clear page as TTM flag since when moving the BO back
in from GTT again we don't need that.
- Make a specialized version of amdgpu_fill_buffer() which only
clears the VRAM areas which are not already cleared
- Drop the TTM_PL_FLAG_WIPE_ON_RELEASE check in
amdgpu_object.c
v2:
- Modify the function name amdgpu_ttm_* (Alex)
- Drop the delayed parameter (Christian)
- handle amdgpu_res_cleared(&cursor) just above the size
calculation (Christian)
- Use AMDGPU_GEM_CREATE_VRAM_WIPE_ON_RELEASE for clearing the buffers
in the free path to properly wait for fences etc.. (Christian)
v3(Christian):
- Remove buffer clear code in VRAM manager instead change the
AMDGPU_GEM_CREATE_VRAM_WIPE_ON_RELEASE handling to set
the DRM_BUDDY_CLEARED flag.
- Remove ! from amdgpu_res_cleared(&cursor) check.
Signed-off-by: Arunpravin Paneer Selvam
Suggested-by: Christian König
Acked-by: Felix Kuehling
---
drivers/gpu/drm/amd/amdgpu/amdgpu_object.c| 22 ---
.../gpu/drm/amd/amdgpu/amdgpu_res_cursor.h| 25
drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c | 61 ++-
drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.h | 5 +-
drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.c | 6 +-
drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.h | 5 ++
6 files changed, 111 insertions(+), 13 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
index 8bc79924d171..c92d92b28a57 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
@@ -39,6 +39,7 @@
#include "amdgpu.h"
#include "amdgpu_trace.h"
#include "amdgpu_amdkfd.h"
+#include "amdgpu_vram_mgr.h"
/**
* DOC: amdgpu_object
@@ -601,8 +602,7 @@ int amdgpu_bo_create(struct amdgpu_device *adev,
if (!amdgpu_bo_support_uswc(bo->flags))
bo->flags &= ~AMDGPU_GEM_CREATE_CPU_GTT_USWC;
- if (adev->ras_enabled)
- bo->flags |= AMDGPU_GEM_CREATE_VRAM_WIPE_ON_RELEASE;
+ bo->flags |= AMDGPU_GEM_CREATE_VRAM_WIPE_ON_RELEASE;
bo->tbo.bdev = &adev->mman.bdev;
if (bp->domain & (AMDGPU_GEM_DOMAIN_GWS | AMDGPU_GEM_DOMAIN_OA |
@@ -632,15 +632,17 @@ int amdgpu_bo_create(struct amdgpu_device *adev,
if (bp->flags & AMDGPU_GEM_CREATE_VRAM_CLEARED &&
bo->tbo.resource->mem_type == TTM_PL_VRAM) {
- struct dma_fence *fence;
+ struct dma_fence *fence = NULL;
- r = amdgpu_fill_buffer(bo, 0, bo->tbo.base.resv, &fence, true);
+ r = amdgpu_ttm_clear_buffer(bo, bo->tbo.base.resv, &fence);
if (unlikely(r))
goto fail_unreserve;
- dma_resv_add_fence(bo->tbo.base.resv, fence,
- DMA_RESV_USAGE_KERNEL);
- dma_fence_put(fence);
+ if (fence) {
+ dma_resv_add_fence(bo->tbo.base.resv, fence,
+ DMA_RESV_USAGE_KERNEL);
+ dma_fence_put(fence);
+ }
}
if (!bp->resv)
amdgpu_bo_unreserve(bo);
@@ -1365,8 +1367,12 @@ void amdgpu_bo_release_notify(struct ttm_buffer_object
*bo)
if (WARN_ON_ONCE(!dma_resv_trylock(bo->base.resv)))
return;
- r = amdgpu_fill_buffer(abo, AMDGPU_POISON, bo->base.resv, &fence, true);
+ r = amdgpu_fill_buffer(abo, 0, bo->base.resv, &fence, true);
if (!WARN_ON(r)) {
+ struct amdgpu_vram_mgr_resource *vres;
+
+ vres = to_amdgpu_vram_mgr_resource(bo->resource);
+ vres->flags |= DRM_BUDDY_CLEARED;
amdgpu_bo_fence(abo, fence, false);
dma_fence_put(fence);
}
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_res_cursor.h
b/drivers/gpu/drm/amd/amdgpu/amdgpu_res_cursor.h
index 381101d2bf05..50fcd86e1033 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_res_cursor.h
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_res_cursor.h
@@ -164,4 +164,29 @@ static inline void amdgpu_res_next(struct
amdgpu_res_cursor *cur, uint64_t size)
}
}
+/**
+ * amdgpu_res_cleared - check if blocks are cleared
+ *
+ * @cur: the cursor to extract the block
+ *
+ * Check if the @cur block is cleared
+ */
+static inline bool amdgpu_res_cleared(struct amdgpu_res_cursor *cur)
+{
+ struct drm_buddy_block *block;
+
+ switch (cur->mem_type) {
+ case TTM_PL_VRAM:
+ block = cur->node;
+
+ if (!amdgpu_vram_mgr_is_cleared(block))
+ return false;
+ break;
+ default:
+ return false;
+ }
+
+ return true;
+}
+
#endif
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
index 8722beba494e..bcbffe909b47 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_tt
[PATCH v9 1/3] drm/buddy: Implement tracking clear page feature
- Add tracking clear page feature.
- Driver should enable the DRM_BUDDY_CLEARED flag if it
successfully clears the blocks in the free path. On the otherhand,
DRM buddy marks each block as cleared.
- Track the available cleared pages size
- If driver requests cleared memory we prefer cleared memory
but fallback to uncleared if we can't find the cleared blocks.
when driver requests uncleared memory we try to use uncleared but
fallback to cleared memory if necessary.
- When a block gets freed we clear it and mark the freed block as cleared,
when there are buddies which are cleared as well we can merge them.
Otherwise, we prefer to keep the blocks as separated.
- Add a function to support defragmentation.
v1:
- Depends on the flag check DRM_BUDDY_CLEARED, enable the block as
cleared. Else, reset the clear flag for each block in the list(Christian)
- For merging the 2 cleared blocks compare as below,
drm_buddy_is_clear(block) != drm_buddy_is_clear(buddy)(Christian)
- Defragment the memory beginning from min_order
till the required memory space is available.
v2: (Matthew)
- Add a wrapper drm_buddy_free_list_internal for the freeing of blocks
operation within drm buddy.
- Write a macro block_incompatible() to allocate the required blocks.
- Update the xe driver for the drm_buddy_free_list change in arguments.
- add a warning if the two blocks are incompatible on
defragmentation
- call full defragmentation in the fini() function
- place a condition to test if min_order is equal to 0
- replace the list with safe_reverse() variant as we might
remove the block from the list.
v3:
- fix Gitlab user reported lockup issue.
- Keep DRM_BUDDY_HEADER_CLEAR define sorted(Matthew)
- modify to pass the root order instead max_order in fini()
function(Matthew)
- change bool 1 to true(Matthew)
- add check if min_block_size is power of 2(Matthew)
- modify the min_block_size datatype to u64(Matthew)
v4:
- rename the function drm_buddy_defrag with __force_merge.
- Include __force_merge directly in drm buddy file and remove
the defrag use in amdgpu driver.
- Remove list_empty() check(Matthew)
- Remove unnecessary space, headers and placement of new variables(Matthew)
- Add a unit test case(Matthew)
Signed-off-by: Arunpravin Paneer Selvam
Signed-off-by: Matthew Auld
Suggested-by: Christian König
Suggested-by: Matthew Auld
---
drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.c | 6 +-
drivers/gpu/drm/drm_buddy.c | 427 ++
drivers/gpu/drm/i915/i915_ttm_buddy_manager.c | 6 +-
drivers/gpu/drm/tests/drm_buddy_test.c| 18 +-
drivers/gpu/drm/xe/xe_ttm_vram_mgr.c | 4 +-
include/drm/drm_buddy.h | 16 +-
6 files changed, 360 insertions(+), 117 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.c
index 8db880244324..c0c851409241 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.c
@@ -571,7 +571,7 @@ static int amdgpu_vram_mgr_new(struct ttm_resource_manager
*man,
return 0;
error_free_blocks:
- drm_buddy_free_list(mm, &vres->blocks);
+ drm_buddy_free_list(mm, &vres->blocks, 0);
mutex_unlock(&mgr->lock);
error_fini:
ttm_resource_fini(man, &vres->base);
@@ -604,7 +604,7 @@ static void amdgpu_vram_mgr_del(struct ttm_resource_manager
*man,
amdgpu_vram_mgr_do_reserve(man);
- drm_buddy_free_list(mm, &vres->blocks);
+ drm_buddy_free_list(mm, &vres->blocks, 0);
mutex_unlock(&mgr->lock);
atomic64_sub(vis_usage, &mgr->vis_usage);
@@ -912,7 +912,7 @@ void amdgpu_vram_mgr_fini(struct amdgpu_device *adev)
kfree(rsv);
list_for_each_entry_safe(rsv, temp, &mgr->reserved_pages, blocks) {
- drm_buddy_free_list(&mgr->mm, &rsv->allocated);
+ drm_buddy_free_list(&mgr->mm, &rsv->allocated, 0);
kfree(rsv);
}
if (!adev->gmc.is_app_apu)
diff --git a/drivers/gpu/drm/drm_buddy.c b/drivers/gpu/drm/drm_buddy.c
index c4222b886db7..625a30a6b855 100644
--- a/drivers/gpu/drm/drm_buddy.c
+++ b/drivers/gpu/drm/drm_buddy.c
@@ -38,8 +38,8 @@ static void drm_block_free(struct drm_buddy *mm,
kmem_cache_free(slab_blocks, block);
}
-static void list_insert_sorted(struct drm_buddy *mm,
- struct drm_buddy_block *block)
+static void list_insert(struct drm_buddy *mm,
+ struct drm_buddy_block *block)
{
struct drm_buddy_block *node;
struct list_head *head;
@@ -57,6 +57,16 @@ static void list_insert_sorted(struct drm_buddy *mm,
__list_add(&block->link, node->link.prev, &node->link);
}
+static void clear_reset(struct drm_buddy_block *block)
+{
+ block->header &= ~DRM_BUDDY_HEADER_CLEAR;
+}
+
+static void mark_cleared(struct drm_buddy_b
Re: [PATCH 2/2] drm/panel: simple: Add POWERTIP PH128800T006-ZHC01 panel entry
On 3/18/2024 9:17 AM, Nathan Morrisson wrote:
Add support for the POWERTIP PH128800T006-ZHC01 10.1" (1280x800)
LCD-TFT panel.
Signed-off-by: Nathan Morrisson
Hi Nathan,
Acked-by: Jessica Zhang
Thanks,
Jessica Zhang
---
drivers/gpu/drm/panel/panel-simple.c | 29
1 file changed, 29 insertions(+)
diff --git a/drivers/gpu/drm/panel/panel-simple.c
b/drivers/gpu/drm/panel/panel-simple.c
index 20e3df1c59d4..02d238123753 100644
--- a/drivers/gpu/drm/panel/panel-simple.c
+++ b/drivers/gpu/drm/panel/panel-simple.c
@@ -3465,6 +3465,32 @@ static const struct panel_desc pda_91_00156_a0 = {
.bus_format = MEDIA_BUS_FMT_RGB888_1X24,
};
+static const struct drm_display_mode powertip_ph128800t006_zhc01_mode = {
+ .clock = 66500,
+ .hdisplay = 1280,
+ .hsync_start = 1280 + 12,
+ .hsync_end = 1280 + 12 + 20,
+ .htotal = 1280 + 12 + 20 + 56,
+ .vdisplay = 800,
+ .vsync_start = 800 + 1,
+ .vsync_end = 800 + 1 + 3,
+ .vtotal = 800 + 1 + 3 + 20,
+ .flags = DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC,
+};
+
+static const struct panel_desc powertip_ph128800t006_zhc01 = {
+ .modes = &powertip_ph128800t006_zhc01_mode,
+ .num_modes = 1,
+ .bpc = 8,
+ .size = {
+ .width = 216,
+ .height = 135,
+ },
+ .bus_format = MEDIA_BUS_FMT_RGB888_1X7X4_SPWG,
+ .bus_flags = DRM_BUS_FLAG_DE_HIGH,
+ .connector_type = DRM_MODE_CONNECTOR_LVDS,
+};
+
static const struct drm_display_mode powertip_ph800480t013_idf02_mode = {
.clock = 24750,
.hdisplay = 800,
@@ -4639,6 +4665,9 @@ static const struct of_device_id platform_of_match[] = {
}, {
.compatible = "pda,91-00156-a0",
.data = &pda_91_00156_a0,
+ }, {
+ .compatible = "powertip,ph128800t006-zhc01",
+ .data = &powertip_ph128800t006_zhc01,
}, {
.compatible = "powertip,ph800480t013-idf02",
.data = &powertip_ph800480t013_idf02,
--
2.25.1
[PATCH 0/2] Add POWERTIP PH128800T006-ZHC01 panel
Add the device tree bindings, timings, and compatible string for the POWERTIP PH128800T006-ZHC01 panel. Nathan Morrisson (2): dt-bindings: display: simple: Add POWERTIP PH128800T-006-ZHC01 panel drm/panel: simple: Add POWERTIP PH128800T006-ZHC01 panel entry .../bindings/display/panel/panel-simple.yaml | 2 ++ drivers/gpu/drm/panel/panel-simple.c | 29 +++ 2 files changed, 31 insertions(+) -- 2.25.1
[PATCH 1/2] dt-bindings: display: simple: Add POWERTIP PH128800T-006-ZHC01 panel
Add POWERTIP PH128800T-006-ZHC01 10.1" LCD-TFT LVDS panel compatible string. Signed-off-by: Nathan Morrisson --- .../devicetree/bindings/display/panel/panel-simple.yaml | 2 ++ 1 file changed, 2 insertions(+) diff --git a/Documentation/devicetree/bindings/display/panel/panel-simple.yaml b/Documentation/devicetree/bindings/display/panel/panel-simple.yaml index a95445f40870..312e760d7225 100644 --- a/Documentation/devicetree/bindings/display/panel/panel-simple.yaml +++ b/Documentation/devicetree/bindings/display/panel/panel-simple.yaml @@ -272,6 +272,8 @@ properties: - osddisplays,osd070t1718-19ts # One Stop Displays OSD101T2045-53TS 10.1" 1920x1200 panel - osddisplays,osd101t2045-53ts +# POWERTIP PH128800T006-ZHC01 10.1" WXGA TFT LCD panel + - powertip,ph128800t006-zhc01 # POWERTIP PH800480T013-IDF2 7.0" WVGA TFT LCD panel - powertip,ph800480t013-idf02 # QiaoDian XianShi Corporation 4"3 TFT LCD panel -- 2.25.1
[PATCH 2/2] drm/panel: simple: Add POWERTIP PH128800T006-ZHC01 panel entry
Add support for the POWERTIP PH128800T006-ZHC01 10.1" (1280x800)
LCD-TFT panel.
Signed-off-by: Nathan Morrisson
---
drivers/gpu/drm/panel/panel-simple.c | 29
1 file changed, 29 insertions(+)
diff --git a/drivers/gpu/drm/panel/panel-simple.c
b/drivers/gpu/drm/panel/panel-simple.c
index 20e3df1c59d4..02d238123753 100644
--- a/drivers/gpu/drm/panel/panel-simple.c
+++ b/drivers/gpu/drm/panel/panel-simple.c
@@ -3465,6 +3465,32 @@ static const struct panel_desc pda_91_00156_a0 = {
.bus_format = MEDIA_BUS_FMT_RGB888_1X24,
};
+static const struct drm_display_mode powertip_ph128800t006_zhc01_mode = {
+ .clock = 66500,
+ .hdisplay = 1280,
+ .hsync_start = 1280 + 12,
+ .hsync_end = 1280 + 12 + 20,
+ .htotal = 1280 + 12 + 20 + 56,
+ .vdisplay = 800,
+ .vsync_start = 800 + 1,
+ .vsync_end = 800 + 1 + 3,
+ .vtotal = 800 + 1 + 3 + 20,
+ .flags = DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC,
+};
+
+static const struct panel_desc powertip_ph128800t006_zhc01 = {
+ .modes = &powertip_ph128800t006_zhc01_mode,
+ .num_modes = 1,
+ .bpc = 8,
+ .size = {
+ .width = 216,
+ .height = 135,
+ },
+ .bus_format = MEDIA_BUS_FMT_RGB888_1X7X4_SPWG,
+ .bus_flags = DRM_BUS_FLAG_DE_HIGH,
+ .connector_type = DRM_MODE_CONNECTOR_LVDS,
+};
+
static const struct drm_display_mode powertip_ph800480t013_idf02_mode = {
.clock = 24750,
.hdisplay = 800,
@@ -4639,6 +4665,9 @@ static const struct of_device_id platform_of_match[] = {
}, {
.compatible = "pda,91-00156-a0",
.data = &pda_91_00156_a0,
+ }, {
+ .compatible = "powertip,ph128800t006-zhc01",
+ .data = &powertip_ph128800t006_zhc01,
}, {
.compatible = "powertip,ph800480t013-idf02",
.data = &powertip_ph800480t013_idf02,
--
2.25.1
[PATCH 2/3] drm/bridge: analogix_dp: simplify analogix_dp_{set/get}_lane_link_training helpers
From: Wyon Bi
There is no need for separate functions for each lane, as we can deduct the
register offset to read/write from the lane index.
Signed-off-by: Wyon Bi
Signed-off-by: Lucas Stach
---
.../drm/bridge/analogix/analogix_dp_core.c| 97 ++-
.../drm/bridge/analogix/analogix_dp_core.h| 22 +---
.../gpu/drm/bridge/analogix/analogix_dp_reg.c | 114 +++---
3 files changed, 26 insertions(+), 207 deletions(-)
diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
index df9370e0ff23..300385db7502 100644
--- a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
+++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
@@ -234,28 +234,6 @@ static int analogix_dp_training_pattern_dis(struct
analogix_dp_device *dp)
return ret < 0 ? ret : 0;
}
-static void
-analogix_dp_set_lane_lane_pre_emphasis(struct analogix_dp_device *dp,
- int pre_emphasis, int lane)
-{
- switch (lane) {
- case 0:
- analogix_dp_set_lane0_pre_emphasis(dp, pre_emphasis);
- break;
- case 1:
- analogix_dp_set_lane1_pre_emphasis(dp, pre_emphasis);
- break;
-
- case 2:
- analogix_dp_set_lane2_pre_emphasis(dp, pre_emphasis);
- break;
-
- case 3:
- analogix_dp_set_lane3_pre_emphasis(dp, pre_emphasis);
- break;
- }
-}
-
static int analogix_dp_link_start(struct analogix_dp_device *dp)
{
u8 buf[4];
@@ -286,10 +264,12 @@ static int analogix_dp_link_start(struct
analogix_dp_device *dp)
return retval;
}
- /* Set TX pre-emphasis to minimum */
+ /* Set TX voltage-swing and pre-emphasis to minimum */
for (lane = 0; lane < lane_count; lane++)
- analogix_dp_set_lane_lane_pre_emphasis(dp,
- PRE_EMPHASIS_LEVEL_0, lane);
+ dp->link_train.training_lane[lane] =
+ DP_TRAIN_VOLTAGE_SWING_LEVEL_0 |
+ DP_TRAIN_PRE_EMPH_LEVEL_0;
+ analogix_dp_set_lane_link_training(dp);
/* Wait for PLL lock */
pll_tries = 0;
@@ -384,54 +364,6 @@ static unsigned char
analogix_dp_get_adjust_request_pre_emphasis(
return ((link_value >> shift) & 0xc) >> 2;
}
-static void analogix_dp_set_lane_link_training(struct analogix_dp_device *dp,
- u8 training_lane_set, int lane)
-{
- switch (lane) {
- case 0:
- analogix_dp_set_lane0_link_training(dp, training_lane_set);
- break;
- case 1:
- analogix_dp_set_lane1_link_training(dp, training_lane_set);
- break;
-
- case 2:
- analogix_dp_set_lane2_link_training(dp, training_lane_set);
- break;
-
- case 3:
- analogix_dp_set_lane3_link_training(dp, training_lane_set);
- break;
- }
-}
-
-static unsigned int
-analogix_dp_get_lane_link_training(struct analogix_dp_device *dp,
- int lane)
-{
- u32 reg;
-
- switch (lane) {
- case 0:
- reg = analogix_dp_get_lane0_link_training(dp);
- break;
- case 1:
- reg = analogix_dp_get_lane1_link_training(dp);
- break;
- case 2:
- reg = analogix_dp_get_lane2_link_training(dp);
- break;
- case 3:
- reg = analogix_dp_get_lane3_link_training(dp);
- break;
- default:
- WARN_ON(1);
- return 0;
- }
-
- return reg;
-}
-
static void analogix_dp_reduce_link_rate(struct analogix_dp_device *dp)
{
analogix_dp_training_pattern_dis(dp);
@@ -523,10 +455,7 @@ static int analogix_dp_process_clock_recovery(struct
analogix_dp_device *dp)
}
analogix_dp_get_adjust_training_lane(dp, adjust_request);
-
- for (lane = 0; lane < lane_count; lane++)
- analogix_dp_set_lane_link_training(dp,
- dp->link_train.training_lane[lane], lane);
+ analogix_dp_set_lane_link_training(dp);
retval = drm_dp_dpcd_write(&dp->aux, DP_TRAINING_LANE0_SET,
dp->link_train.training_lane, lane_count);
@@ -538,7 +467,7 @@ static int analogix_dp_process_clock_recovery(struct
analogix_dp_device *dp)
static int analogix_dp_process_equalizer_training(struct analogix_dp_device
*dp)
{
- int lane, lane_count, retval;
+ int lane_count, retval;
u32 reg;
u8 link_align, link_status[2], adjust_request[2];
@@ -598,9 +527,7 @@ static int analogix_dp_process_equalizer_training(struct
analogix_dp_device *dp)
return -EIO;
}
- for (lane = 0; lane < lane_count; lane++)
- anal
[PATCH 3/3] drm/bridge: analogix_dp: don't adjust further when clock recovery succeeded
Take a early return from the clock recovery training when the sink reports
CR_DONE for all lanes. There is no point in trying to adjust the link
parameters further.
Signed-off-by: Lucas Stach
---
.../drm/bridge/analogix/analogix_dp_core.c| 58 +--
1 file changed, 29 insertions(+), 29 deletions(-)
diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
index 300385db7502..98454f0af90e 100644
--- a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
+++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
@@ -410,11 +410,6 @@ static int analogix_dp_process_clock_recovery(struct
analogix_dp_device *dp)
if (retval < 0)
return retval;
- retval = drm_dp_dpcd_read(&dp->aux, DP_ADJUST_REQUEST_LANE0_1,
- adjust_request, 2);
- if (retval < 0)
- return retval;
-
if (analogix_dp_clock_recovery_ok(link_status, lane_count) == 0) {
/* set training pattern 2 for EQ */
analogix_dp_set_training_pattern(dp, TRAINING_PTN2);
@@ -427,30 +422,35 @@ static int analogix_dp_process_clock_recovery(struct
analogix_dp_device *dp)
dev_dbg(dp->dev, "Link Training Clock Recovery success\n");
dp->link_train.lt_state = EQUALIZER_TRAINING;
- } else {
- for (lane = 0; lane < lane_count; lane++) {
- training_lane = analogix_dp_get_lane_link_training(
- dp, lane);
- voltage_swing = analogix_dp_get_adjust_request_voltage(
- adjust_request, lane);
- pre_emphasis =
analogix_dp_get_adjust_request_pre_emphasis(
- adjust_request, lane);
-
- if (DPCD_VOLTAGE_SWING_GET(training_lane) ==
- voltage_swing &&
- DPCD_PRE_EMPHASIS_GET(training_lane) ==
- pre_emphasis)
- dp->link_train.cr_loop[lane]++;
-
- if (dp->link_train.cr_loop[lane] == MAX_CR_LOOP ||
- voltage_swing == VOLTAGE_LEVEL_3 ||
- pre_emphasis == PRE_EMPHASIS_LEVEL_3) {
- dev_err(dp->dev, "CR Max reached (%d,%d,%d)\n",
- dp->link_train.cr_loop[lane],
- voltage_swing, pre_emphasis);
- analogix_dp_reduce_link_rate(dp);
- return -EIO;
- }
+
+ return 0;
+ }
+
+ retval = drm_dp_dpcd_read(&dp->aux, DP_ADJUST_REQUEST_LANE0_1,
+ adjust_request, 2);
+ if (retval < 0)
+ return retval;
+
+ for (lane = 0; lane < lane_count; lane++) {
+ training_lane = analogix_dp_get_lane_link_training(
+ dp, lane);
+ voltage_swing = analogix_dp_get_adjust_request_voltage(
+ adjust_request, lane);
+ pre_emphasis = analogix_dp_get_adjust_request_pre_emphasis(
+ adjust_request, lane);
+
+ if (DPCD_VOLTAGE_SWING_GET(training_lane) == voltage_swing &&
+ DPCD_PRE_EMPHASIS_GET(training_lane) == pre_emphasis)
+ dp->link_train.cr_loop[lane]++;
+
+ if (dp->link_train.cr_loop[lane] == MAX_CR_LOOP ||
+ voltage_swing == VOLTAGE_LEVEL_3 ||
+ pre_emphasis == PRE_EMPHASIS_LEVEL_3) {
+ dev_err(dp->dev, "CR Max reached (%d,%d,%d)\n",
+ dp->link_train.cr_loop[lane],
+ voltage_swing, pre_emphasis);
+ analogix_dp_reduce_link_rate(dp);
+ return -EIO;
}
}
--
2.39.2
[PATCH 1/3] drm/bridge: analogix_dp: properly handle zero sized AUX transactions
Address only transactions without any data are valid and should not be flagged as short transactions. Simply return the message size when no transaction errors occured. CC: sta...@vger.kernel.org Signed-off-by: Lucas Stach --- drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c | 5 + 1 file changed, 1 insertion(+), 4 deletions(-) diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c b/drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c index 6a4f20fccf84..7b0bc9704eac 100644 --- a/drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c +++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c @@ -1027,7 +1027,6 @@ ssize_t analogix_dp_transfer(struct analogix_dp_device *dp, u32 status_reg; u8 *buffer = msg->buffer; unsigned int i; - int num_transferred = 0; int ret; /* Buffer size of AUX CH is 16 bytes */ @@ -1079,7 +1078,6 @@ ssize_t analogix_dp_transfer(struct analogix_dp_device *dp, reg = buffer[i]; writel(reg, dp->reg_base + ANALOGIX_DP_BUF_DATA_0 + 4 * i); - num_transferred++; } } @@ -1127,7 +1125,6 @@ ssize_t analogix_dp_transfer(struct analogix_dp_device *dp, reg = readl(dp->reg_base + ANALOGIX_DP_BUF_DATA_0 + 4 * i); buffer[i] = (unsigned char)reg; - num_transferred++; } } @@ -1144,7 +1141,7 @@ ssize_t analogix_dp_transfer(struct analogix_dp_device *dp, (msg->request & ~DP_AUX_I2C_MOT) == DP_AUX_NATIVE_READ) msg->reply = DP_AUX_NATIVE_REPLY_ACK; - return num_transferred > 0 ? num_transferred : -EBUSY; + return msg->size; aux_error: /* if aux err happen, reset aux */ -- 2.39.2
Re: [PATCH] drm/i915/gt: Reset queue_priority_hint on parking
On Mon, Mar 18, 2024 at 02:58:47PM +0100, Janusz Krzysztofik wrote:
> From: Chris Wilson
>
> Originally, with strict in order execution, we could complete execution
> only when the queue was empty. Preempt-to-busy allows replacement of an
> active request that may complete before the preemption is processed by
> HW. If that happens, the request is retired from the queue, but the
> queue_priority_hint remains set, preventing direct submission until
> after the next CS interrupt is processed.
perhaps we are missing some intel_engine_flush_submission at preepmtion?
I wonder if there could be anything else we might be missing
with the lack of the flush.
>
> This preempt-to-busy race can be triggered by the heartbeat, which will
> also act as the power-management barrier and upon completion allow us to
> idle the HW. We may process the completion of the heartbeat, and begin
> parking the engine before the CS event that restores the
> queue_priority_hint, causing us to fail the assertion that it is MIN.
>
> <3>[ 166.210729] __engine_park:283
> GEM_BUG_ON(engine->sched_engine->queue_priority_hint != (-((int)(~0U >> 1)) -
> 1))
> <0>[ 166.210781] Dumping ftrace buffer:
> <0>[ 166.210795] -
> ...
> <0>[ 167.302811] drm_fdin-1097 2..s1. 165741070us : trace_ports:
> :00:02.0 rcs0: promote { ccid:20 1217:2 prio 0 }
> <0>[ 167.302861] drm_fdin-1097 2d.s2. 165741072us :
> execlists_submission_tasklet: :00:02.0 rcs0: preempting last=1217:2,
> prio=0, hint=2147483646
> <0>[ 167.302928] drm_fdin-1097 2d.s2. 165741072us :
> __i915_request_unsubmit: :00:02.0 rcs0: fence 1217:2, current 0
> <0>[ 167.302992] drm_fdin-1097 2d.s2. 165741073us :
> __i915_request_submit: :00:02.0 rcs0: fence 3:4660, current 4659
> <0>[ 167.303044] drm_fdin-1097 2d.s1. 165741076us :
> execlists_submission_tasklet: :00:02.0 rcs0: context:3 schedule-in,
> ccid:40
> <0>[ 167.303095] drm_fdin-1097 2d.s1. 165741077us : trace_ports:
> :00:02.0 rcs0: submit { ccid:40 3:4660* prio 2147483646 }
> <0>[ 167.303159] kworker/-89 11. 165741139us :
> i915_request_retire.part.0: :00:02.0 rcs0: fence c90:2, current 2
> <0>[ 167.303208] kworker/-89 11. 165741148us :
> __intel_context_do_unpin: :00:02.0 rcs0: context:c90 unpin
> <0>[ 167.303272] kworker/-89 11. 165741159us :
> i915_request_retire.part.0: :00:02.0 rcs0: fence 1217:2, current 2
> <0>[ 167.303321] kworker/-89 11. 165741166us :
> __intel_context_do_unpin: :00:02.0 rcs0: context:1217 unpin
> <0>[ 167.303384] kworker/-89 11. 165741170us :
> i915_request_retire.part.0: :00:02.0 rcs0: fence 3:4660, current 4660
> <0>[ 167.303434] kworker/-89 11d..1. 165741172us :
> __intel_context_retire: :00:02.0 rcs0: context:1216 retire runtime: {
> total:56028ns, avg:56028ns }
> <0>[ 167.303484] kworker/-89 11. 165741198us : __engine_park:
> :00:02.0 rcs0: parked
> <0>[ 167.303534] -0 5d.H3. 165741207us :
> execlists_irq_handler: :00:02.0 rcs0: semaphore yield: 0040
> <0>[ 167.303583] kworker/-89 11. 165741397us :
> __intel_context_retire: :00:02.0 rcs0: context:1217 retire runtime: {
> total:325575ns, avg:0ns }
> <0>[ 167.303756] kworker/-89 11. 165741777us :
> __intel_context_retire: :00:02.0 rcs0: context:c90 retire runtime: {
> total:0ns, avg:0ns }
> <0>[ 167.303806] kworker/-89 11. 165742017us : __engine_park:
> __engine_park:283 GEM_BUG_ON(engine->sched_engine->queue_priority_hint !=
> (-((int)(~0U >> 1)) - 1))
> <0>[ 167.303811] -
> <4>[ 167.304722] [ cut here ]
> <2>[ 167.304725] kernel BUG at drivers/gpu/drm/i915/gt/intel_engine_pm.c:283!
> <4>[ 167.304731] invalid opcode: [#1] PREEMPT SMP NOPTI
> <4>[ 167.304734] CPU: 11 PID: 89 Comm: kworker/11:1 Tainted: GW
> 6.8.0-rc2-CI_DRM_14193-gc655e0fd2804+ #1
> <4>[ 167.304736] Hardware name: Intel Corporation Rocket Lake Client
> Platform/RocketLake S UDIMM 6L RVP, BIOS RKLSFWI1.R00.3173.A03.2204210138
> 04/21/2022
> <4>[ 167.304738] Workqueue: i915-unordered retire_work_handler [i915]
> <4>[ 167.304839] RIP: 0010:__engine_park+0x3fd/0x680 [i915]
> <4>[ 167.304937] Code: 00 48 c7 c2 b0 e5 86 a0 48 8d 3d 00 00 00 00 e8 79 48
> d4 e0 bf 01 00 00 00 e8 ef 0a d4 e0 31 f6 bf 09 00 00 00 e8 03 49 c0 e0 <0f>
> 0b 0f 0b be 01 00 00 00 e8 f5 61 fd ff 31 c0 e9 34 fd ff ff 48
> <4>[ 167.304940] RSP: 0018:c959fce0 EFLAGS: 00010246
> <4>[ 167.304942] RAX: 0200 RBX: RCX:
> 0006
> <4>[ 167.304944] RDX: RSI: RDI:
> 0009
> <4>[ 167.304946] RBP: 8881330ca1b0 R08: 0001 R09:
> 0001
> <4>[ 167.304947] R10: 0001 R11: 0001 R12:
> 8881330ca000
> <4>[ 167.304948
Re: [PATCH v2 4/4] drm/msm/dp: Fix typo in static function (ststus => status)
Hi,
On Mon, Mar 18, 2024 at 12:26 PM Stephen Boyd wrote:
>
> Quoting Douglas Anderson (2024-03-15 14:36:32)
> > This is a no-op change to just fix a typo in the name of a static function.
> >
> > Signed-off-by: Douglas Anderson
> > ---
> >
> > Changes in v2:
> > - ("Fix typo in static function (ststus => status)") new for v2.
>
> This was sent at
> https://lore.kernel.org/r/20240306193515.455388-1-quic_abhin...@quicinc.com
Whoops! I guess we both noticed it at about the same time. My patch
should be dropped then. The rest of my series (patches #1 - #3) are
still relevant. I won't repost them since they can be applied just
fine even if this patch is dropped.
-Doug
Re: [PATCH] drm: bridge: thc63lvd1024: Print error message when DT parsing fails
On 2024/3/19 03:23, Sui Jingfeng wrote: 2) It should be exist at product level kernel. It should NOT be exist at product level kernel. -- Best regards, Sui
Re: [PATCH v2 4/4] drm/msm/dp: Fix typo in static function (ststus => status)
Quoting Douglas Anderson (2024-03-15 14:36:32)
> This is a no-op change to just fix a typo in the name of a static function.
>
> Signed-off-by: Douglas Anderson
> ---
>
> Changes in v2:
> - ("Fix typo in static function (ststus => status)") new for v2.
This was sent at
https://lore.kernel.org/r/20240306193515.455388-1-quic_abhin...@quicinc.com
Re: [PATCH] drm: bridge: thc63lvd1024: Print error message when DT parsing fails
Hi,
On 2024/3/19 02:04, Laurent Pinchart wrote:
Improving core helpers is certainly a good idea, and if we do so, we can
simplify drivers. What I'm concerned is that commit 00084f0c01bf creates
a silent probe failure path,
No, I can't agree here. It doesn't creates a silent probe failure path.
Simply because
1) It is NOT silent.
2) It should be exist at product level kernel.
which didn't exist before it.
Again, it shouldn't be exist.
Otherwise it hints us that there is ill-behavior-ed DT in the mainstream kernel
or a specific product(or development board). If I were you, I would like to fix
the boot failure first.
In the earlier stage of my attempt to contribute, I also would like to enable
debug output as much as possible. Just like you, the benefit is obvious: It
really
eliminate the pain on developing stage and when bugs happens.
But I was told many many times that mainstream kernel is not for debug, it is
for sound products. I bet you have seen some product level drivers print very
less.
I'm not understand why in the past, but I think I could understand something
now.
Probably because professional programmers really confident about what they have
wrote. As they have been tested and/or reviewed thousands or ten thousands
times.
Enable this debug output by default can only prove to the community that you are
not confident about something, either the community's reviewing power on DTS or
your debug techniques.
This is why
this patch references it in the Fixes: tag, making sure that this patch
will get backported to any stable kernel that includes commit
00084f0c01bf.
No, I keep insist on my judgement. A fixes tag is only meant for cases where
your
patch fixes a bug. The bug should really be happened. All of the discussion
ongoing
here are just things imaginary about the *debug* phase and development phase.
As far as I understand, this is business as usual. There's
nothing personal here, and no judgement on the quality of your code.
Please don't misunderstanding, I do cares the quality of my code.
If it is really introduce a bug, I will responsible and help to solve.
But this is not the case. Sorry.
Signed-off-by: Laurent Pinchart
---
drivers/gpu/drm/bridge/thc63lvd1024.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/bridge/thc63lvd1024.c
b/drivers/gpu/drm/bridge/thc63lvd1024.c
index 5f99f9724081..674efc489e3a 100644
--- a/drivers/gpu/drm/bridge/thc63lvd1024.c
+++ b/drivers/gpu/drm/bridge/thc63lvd1024.c
@@ -125,8 +125,11 @@ static int thc63_parse_dt(struct thc63_dev *thc63)
remote = of_graph_get_remote_node(thc63->dev->of_node,
THC63_RGB_OUT0, -1);
- if (!remote)
+ if (!remote) {
+ dev_err(thc63->dev, "No remote endpoint for port@%u\n",
+ THC63_RGB_OUT0);
return -ENODEV;
+ }
An side effect of this patch is that we will add one more extra error message
in the console.
As the of_graph_get_remote_node() function already print one for us if I add
'#define DEBUG 1'
on the top of this source file. What's worse, it does not really tell us what's
really the
error is.
It could be no valid endpoint or no valid remote node because of bad coding in
DT, or It is
also simply because the remove node(or device) is being disabled intentionally
by adding
'status = "disabled"' clause. Therefore, the error printing code added here is
very confusing
in practice. It cannot really help for locating the root cause of the problem.
After think about this more than twice, either help to improve the core
of_graph_get_remote_node()
function or just to drop this. This what I can tell as a ordinary reviewer.
Despite you and/or
other more advanced programmer & reviewer could override what I said though.
--
Best regards,
Sui
thc63->next = of_drm_find_bridge(remote);
of_node_put(remote);
base-commit: 00084f0c01bf3a2591d007010b196e048281c455
--
Best regards,
Sui
Re: [PATCH] drm/tilcdc: Set preferred depth
Hi, Kevin Kevin Hao writes: > I had also thought about a similar modification before, but personally, > I considered such changes a bit aggressive for a patch that needs to be > backported to a stable kernel (especially for a LTS kernel such as v6.6 > which I am working on). That's why I opted for minimal changes to fix this > regression, reducing the risk when we backport it to the stable kernel. Personally I only work with the latest stable mainline kernel, so I want to fix both the regression and enable a 24 bit color depth... > Additionally, my patch and your patch don't conflict semantically, and > setting a driver's preferred_depth shouldn't cause any other issues. True, we'll see what the maintainers say. Regards, --Frej
drm/tiny: QUESTION: What to use instead of drm_simple_display_pipe ?
Hello everyone :) I am implementing a tiny drm driver and I am currently working on the V2: https://lore.kernel.org/dri-devel/cover.1701267411.git.mehdi.dj...@bootlin.com/ I got a review on the v1 telling me not to use the drm_simple_display_pipe. Can someone please explain this further ? Or give me an example drm driver that does it the right way ? -- Kind Regards Mehdi Djait
Re: [PATCH v2] fbmon: prevent division by zero in fb_videomode_from_videomode()
On 3/18/24 09:11, Roman Smirnov wrote:
On Fri, 15 Mar 2024 09:44:08 +0100 Helge Deller wrote:
On 3/5/24 14:51, Roman Smirnov wrote:
The expression htotal * vtotal can have a zero value on
overflow.
I'm not sure if those always results in zero in kernel on overflow.
Might be architecture-depended too, but let's assume it
can become zero,
It is necessary to prevent division by zero like in
fb_var_to_videomode().
Found by Linux Verification Center (linuxtesting.org) with Svace.
Signed-off-by: Roman Smirnov
Reviewed-by: Sergey Shtylyov
---
V1 -> V2: Replaced the code of the first version with a check.
drivers/video/fbdev/core/fbmon.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/video/fbdev/core/fbmon.c b/drivers/video/fbdev/core/fbmon.c
index 79e5bfbdd34c..b137590386da 100644
--- a/drivers/video/fbdev/core/fbmon.c
+++ b/drivers/video/fbdev/core/fbmon.c
@@ -1344,7 +1344,7 @@ int fb_videomode_from_videomode(const struct videomode
*vm,
vtotal = vm->vactive + vm->vfront_porch + vm->vback_porch +
vm->vsync_len;
/* prevent division by zero */
- if (htotal && vtotal) {
+ if (htotal && vtotal && (vm->pixelclock / htotal >= vtotal)) {
why don't you then simply check for
if .. ((htotal * vtotal) == 0) ...
instead?
Helge
Thomas Zimmermann from the previous discussion said:
On Tue, 5 Mar 2024 11:18:05 +0100 Thomas Zimmerman wrote:
Maybe use
if (htotal && vtotal && (vm->pixelclock / htotal >= vtotal))
for the test. That rules out overflowing multiplication and sets
refresh to 0 in such cases.
This prevents overflow, which is also a problematic case.
I don't like adding another division here and I doubt we have
a problem with possible overflow.
So, I suggest to keep it simple, something like:
...
total = htotal * vtotal;
if (total)
fbmode->refresh = vm->pixelclock / total;
else...
Helge
Re: [PATCH 6/6] drm: zynqmp_dp: Add debugfs interface for compliance testing
On 3/18/24 13:50, Laurent Pinchart wrote:
> On Mon, Mar 18, 2024 at 11:06:40AM -0400, Sean Anderson wrote:
>> On 3/16/24 06:14, kernel test robot wrote:
>> > Hi Sean,
>> >
>> > kernel test robot noticed the following build warnings:
>> >
>> > [auto build test WARNING on v6.8]
>> > [cannot apply to drm-misc/drm-misc-next linus/master next-20240315]
>> > [If your patch is applied to the wrong git tree, kindly drop us a note.
>> > And when submitting patch, we suggest to use '--base' as documented in
>> > https://git-scm.com/docs/git-format-patch#_base_tree_information]
>> >
>> > url:
>> > https://github.com/intel-lab-lkp/linux/commits/Sean-Anderson/drm-zynqmp_dp-Downgrade-log-level-for-aux-retries-message/20240316-071208
>> > base: v6.8
>> > patch link:
>> > https://lore.kernel.org/r/20240315230916.1759060-7-sean.anderson%40linux.dev
>> > patch subject: [PATCH 6/6] drm: zynqmp_dp: Add debugfs interface for
>> > compliance testing
>> > config: microblaze-allmodconfig
>> > (https://download.01.org/0day-ci/archive/20240316/202403161704.achjdsjg-...@intel.com/config)
>> > compiler: microblaze-linux-gcc (GCC) 13.2.0
>> > reproduce (this is a W=1 build):
>> > (https://download.01.org/0day-ci/archive/20240316/202403161704.achjdsjg-...@intel.com/reproduce)
>> >
>> > If you fix the issue in a separate patch/commit (i.e. not just a new
>> > version of
>> > the same patch/commit), kindly add following tags
>> > | Reported-by: kernel test robot
>> > | Closes:
>> > https://lore.kernel.org/oe-kbuild-all/202403161704.achjdsjg-...@intel.com/
>> >
>> > All warnings (new ones prefixed by >>):
>> >
>> >drivers/gpu/drm/xlnx/zynqmp_dp.c: In function
>> > 'zynqmp_dp_bridge_debugfs_init':
>> >>> drivers/gpu/drm/xlnx/zynqmp_dp.c:2168:31: warning: 'sprintf' may write a
>> >>> terminating nul past the end of the destination [-Wformat-overflow=]
>> > 2168 | sprintf(name, fmt, i);
>> > | ^~~
>> >drivers/gpu/drm/xlnx/zynqmp_dp.c:2168:17: note: 'sprintf' output
>> > between 18 and 20 bytes into a destination of size 19
>> > 2168 | sprintf(name, fmt, i);
>> > | ^
>>
>> Not a bug, as i will be at most 4, which uses 1 digit.
>
> The compiler can't know that. Please fix this, there's a zero warning
> policy.
I cannot reproduce this with GCC 13.2.0. So given that this is not a bug and I
can't reproduce
it, I don't see how I can verify any fix.
--Sean
>> > vim +/sprintf +2168 drivers/gpu/drm/xlnx/zynqmp_dp.c
>> >
>> > 2136
>> > 2137 DEFINE_DEBUGFS_ATTRIBUTE(fops_zynqmp_dp_rate,
>> > zynqmp_dp_rate_get,
>> > 2138 zynqmp_dp_rate_set, "%llu\n");
>> > 2139
>> > 2140 static void zynqmp_dp_bridge_debugfs_init(struct drm_bridge
>> > *bridge,
>> > 2141 struct dentry *root)
>> > 2142 {
>> > 2143 struct zynqmp_dp *dp = bridge_to_dp(bridge);
>> > 2144 struct dentry *test;
>> > 2145 int i;
>> > 2146
>> > 2147 dp->test.bw_code = DP_LINK_BW_5_4;
>> > 2148 dp->test.link_cnt = dp->num_lanes;
>> > 2149
>> > 2150 test = debugfs_create_dir("test", root);
>> > 2151 #define CREATE_FILE(name) \
>> > 2152 debugfs_create_file(#name, 0600, test, dp,
>> > &fops_zynqmp_dp_##name)
>> > 2153 CREATE_FILE(pattern);
>> > 2154 CREATE_FILE(enhanced);
>> > 2155 CREATE_FILE(downspread);
>> > 2156 CREATE_FILE(active);
>> > 2157 CREATE_FILE(custom);
>> > 2158 CREATE_FILE(rate);
>> > 2159 CREATE_FILE(lanes);
>> > 2160
>> > 2161 for (i = 0; i < dp->num_lanes; i++) {
>> > 2162 static const char fmt[] = "lane%d_preemphasis";
>> > 2163 char name[sizeof(fmt)];
>> > 2164
>> > 2165 dp->debugfs_train_set[i].dp = dp;
>> > 2166 dp->debugfs_train_set[i].lane = i;
>> > 2167
>> >> 2168 sprintf(name, fmt, i);
>> > 2169 debugfs_create_file(name, 0600, test,
>> > 2170 &dp->debugfs_train_set[i],
>> > 2171
>> > &fops_zynqmp_dp_preemphasis);
>> > 2172
>> > 2173 sprintf(name, "lane%d_swing", i);
>> > 2174 debugfs_create_file(name, 0600, test,
>> > 2175 &dp->debugfs_train_set[i],
>> > 2176 &fops_zynqmp_dp_swing);
>> > 2177 }
>> > 2178 }
>> > 2179
>
Re: [PATCH] drm: bridge: thc63lvd1024: Print error message when DT parsing fails
Hi,
On 2024/3/19 02:04, Laurent Pinchart wrote:
Hi Sui,
On Tue, Mar 19, 2024 at 12:42:41AM +0800, Sui Jingfeng wrote:
On 2024/3/19 00:06, Laurent Pinchart wrote:
Commit 00084f0c01bf ("drm: bridge: thc63lvd1024: Switch to use
of_graph_get_remote_node()") simplified the thc63lvd1024 driver by
replacing hand-rolled code with a helper function.
[...]
While doing so, it
created an error code path at probe time without any error message,
If this is a reason or a concern, then every drm bridges drivers will suffer
from
such a concern. Right?
Yes, bridge drivers (or any driver, really) should avoid failing probe
silently.
Yes, I agree with you that bridge drivers should avoid failing probe.
But the real problem that deserve to discuss is that is it really *silently* ?
The of_graph_get_remote_node() function do have debug prints on failure:
- pr_debug("no valid endpoint (%d, %d) for node %pOF\n", port, endpoint,
node);
- pr_debug("no valid remote node\n");
- pr_debug("not available for remote node\n");
So it is not really *silently*.
Re: [PATCH v2 2/4] drm/msm/dp: Account for the timeout in wait_hpd_asserted() callback
On 3/15/2024 2:36 PM, Douglas Anderson wrote:
The DP wait_hpd_asserted() callback is passed a timeout which
indicates how long we should wait for HPD. This timeout was being
ignored in the MSM DP implementation and instead a hardcoded 500 ms
timeout was used. Fix it to use the proper timeout.
As part of this we move the hardcoded 500 ms number into the AUX
transfer function, which isn't given a timeout. The wait in the AUX
transfer function will be removed in a future commit.
Fixes: e2969ee30252 ("drm/msm/dp: move of_dp_aux_populate_bus() to eDP probe()")
Signed-off-by: Douglas Anderson
---
(no changes since v1)
drivers/gpu/drm/msm/dp/dp_aux.c | 5 +++--
drivers/gpu/drm/msm/dp/dp_catalog.c | 7 ---
drivers/gpu/drm/msm/dp/dp_catalog.h | 3 ++-
3 files changed, 9 insertions(+), 6 deletions(-)
Reviewed-by: Abhinav Kumar
Re: [PATCH v2 1/4] drm/msm/dp: Avoid a long timeout for AUX transfer if nothing connected
On 3/15/2024 2:36 PM, Douglas Anderson wrote:
As documented in the description of the transfer() function of
"struct drm_dp_aux", the transfer() function can be called at any time
regardless of the state of the DP port. Specifically if the kernel has
the DP AUX character device enabled and userspace accesses
"/dev/drm_dp_auxN" directly then the AUX transfer function will be
called regardless of whether a DP device is connected.
For eDP panels we have a special rule where we wait (with a 5 second
timeout) for HPD to go high. This rule was important before all panels
drivers were converted to call wait_hpd_asserted() and actually can be
removed in a future commit.
For external DP devices we never checked for HPD. That means that
trying to access the DP AUX character device (AKA `hexdump -C
/dev/drm_dp_auxN`) would very, very slowly timeout. Specifically on my
system:
$ time hexdump -C /dev/drm_dp_aux0
hexdump: /dev/drm_dp_aux0: Connection timed out
real0m8.200s
We want access to the drm_dp_auxN character device to fail faster than
8 seconds when no DP cable is plugged in.
Let's add a test to make transfers fail right away if a device isn't
plugged in. Rather than testing the HPD line directly, we have the
dp_display module tell us when AUX transfers should be enabled so we
can handle cases where HPD is signaled out of band like with Type C.
Fixes: c943b4948b58 ("drm/msm/dp: add displayPort driver support")
Signed-off-by: Douglas Anderson
---
Changes in v2:
- Don't look at the HPD line directly; have dp_display call us.
drivers/gpu/drm/msm/dp/dp_aux.c | 20
drivers/gpu/drm/msm/dp/dp_aux.h | 1 +
drivers/gpu/drm/msm/dp/dp_display.c | 4
3 files changed, 25 insertions(+)
Reviewed-by: Abhinav Kumar
Re: [PATCH 5/6] drm: zynqmp_dp: Optionally ignore DPCD errors
On 3/18/24 13:47, Laurent Pinchart wrote:
> Hi Sean,
>
> Thank you for the patch.
>
> On Fri, Mar 15, 2024 at 07:09:15PM -0400, Sean Anderson wrote:
>> When testing, it's convenient to be able to ignore DPCD errors if there
>> is test equipment which can't emulate a DPRX connected to the output.
>> Add some (currently-unused) options to ignore these errors and just
>> reconfigure our internal registers as we usually would.
>
> This seems to be a problem that is not limited to the ZynqMP DP.
> Wouldn't it be better to solve it in the DRM DP DPCD helpers instead ?
> You could expose a parameter on the AUX bus in debugfs to ignore errors,
> and cause the drm_dp_dpcd_write*() functions to return 0.
I think this is probably the easiest thing. I'll add this for v2.
I think something similar might be nice for HPD events (instead of always
ignoring them in test mode). This would make it easier to add DPRX-driven
testing in the future.
--Sean
>> Signed-off-by: Sean Anderson
>> ---
>>
>> drivers/gpu/drm/xlnx/zynqmp_dp.c | 37
>> 1 file changed, 23 insertions(+), 14 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/xlnx/zynqmp_dp.c
>> b/drivers/gpu/drm/xlnx/zynqmp_dp.c
>> index 24043847dab4..040f7b88ee51 100644
>> --- a/drivers/gpu/drm/xlnx/zynqmp_dp.c
>> +++ b/drivers/gpu/drm/xlnx/zynqmp_dp.c
>> @@ -628,6 +628,7 @@ static void zynqmp_dp_adjust_train(struct zynqmp_dp *dp,
>> * zynqmp_dp_update_vs_emph - Update the training values
>> * @dp: DisplayPort IP core structure
>> * @train_set: A set of training values
>> + * @ignore_dpcd: Ignore DPCD errors
>> *
>> * Update the training values based on the request from sink. The mapped
>> values
>> * are predefined, and values(vs, pe, pc) are from the device manual.
>> @@ -635,15 +636,19 @@ static void zynqmp_dp_adjust_train(struct zynqmp_dp
>> *dp,
>> * Return: 0 if vs and emph are updated successfully, or the error code
>> returned
>> * by drm_dp_dpcd_write().
>> */
>> -static int zynqmp_dp_update_vs_emph(struct zynqmp_dp *dp, u8 *train_set)
>> +static int zynqmp_dp_update_vs_emph(struct zynqmp_dp *dp, u8 *train_set,
>> +bool ignore_dpcd)
>> {
>> unsigned int i;
>> int ret;
>>
>> ret = drm_dp_dpcd_write(&dp->aux, DP_TRAINING_LANE0_SET, train_set,
>> dp->mode.lane_cnt);
>> -if (ret < 0)
>> -return ret;
>> +if (ret < 0) {
>> +if (!ignore_dpcd)
>> +return ret;
>> +dev_warn(dp->dev, "failed to update vs/emph\n");
>> +}
>>
>> for (i = 0; i < dp->mode.lane_cnt; i++) {
>> u32 reg = ZYNQMP_DP_SUB_TX_PHY_PRECURSOR_LANE_0 + i * 4;
>> @@ -692,7 +697,7 @@ static int zynqmp_dp_link_train_cr(struct zynqmp_dp *dp)
>> * So, This loop should exit before 512 iterations
>> */
>> for (max_tries = 0; max_tries < 512; max_tries++) {
>> -ret = zynqmp_dp_update_vs_emph(dp, dp->train_set);
>> +ret = zynqmp_dp_update_vs_emph(dp, dp->train_set, false);
>> if (ret)
>> return ret;
>>
>> @@ -757,7 +762,7 @@ static int zynqmp_dp_link_train_ce(struct zynqmp_dp *dp)
>> return ret;
>>
>> for (tries = 0; tries < DP_MAX_TRAINING_TRIES; tries++) {
>> -ret = zynqmp_dp_update_vs_emph(dp, dp->train_set);
>> +ret = zynqmp_dp_update_vs_emph(dp, dp->train_set, false);
>> if (ret)
>> return ret;
>>
>> @@ -785,11 +790,12 @@ static int zynqmp_dp_link_train_ce(struct zynqmp_dp
>> *dp)
>> * @lane_cnt: The number of lanes to use
>> * @enhanced: Use enhanced framing
>> * @downspread: Enable spread-spectrum clocking
>> + * @ignore_dpcd: Ignore DPCD errors; useful for testing
>> *
>> * Return: 0 on success, or -errno on failure
>> */
>> static int zynqmp_dp_setup(struct zynqmp_dp *dp, u8 bw_code, u8 lane_cnt,
>> - bool enhanced, bool downspread)
>> + bool enhanced, bool downspread, bool ignore_dpcd)
>> {
>> u32 reg;
>> u8 aux_lane_cnt = lane_cnt;
>> @@ -812,21 +818,24 @@ static int zynqmp_dp_setup(struct zynqmp_dp *dp, u8
>> bw_code, u8 lane_cnt,
>>
>> ret = drm_dp_dpcd_writeb(&dp->aux, DP_LANE_COUNT_SET, aux_lane_cnt);
>> if (ret < 0) {
>> -dev_err(dp->dev, "failed to set lane count\n");
>> -return ret;
>> +dev_warn(dp->dev, "failed to set lane count\n");
>> +if (!ignore_dpcd)
>> +return ret;
>> }
>>
>> ret = drm_dp_dpcd_writeb(&dp->aux, DP_MAIN_LINK_CHANNEL_CODING_SET,
>> DP_SET_ANSI_8B10B);
>> if (ret < 0) {
>> -dev_err(dp->dev, "failed to set ANSI 8B/10B encoding\n");
>> -return ret;
>> +dev_warn(dp->dev, "failed to set ANSI 8B/10B encoding\n");
>> +if (!ignore_dpcd)
>> +return r
Re: [PATCH] drm: bridge: thc63lvd1024: Print error message when DT parsing fails
Hi Sui,
On Tue, Mar 19, 2024 at 12:42:41AM +0800, Sui Jingfeng wrote:
> On 2024/3/19 00:06, Laurent Pinchart wrote:
> > Commit 00084f0c01bf ("drm: bridge: thc63lvd1024: Switch to use
> > of_graph_get_remote_node()") simplified the thc63lvd1024 driver by
> > replacing hand-rolled code with a helper function.
>
> [...]
>
> > While doing so, it
> > created an error code path at probe time without any error message,
>
> If this is a reason or a concern, then every drm bridges drivers will suffer
> from
> such a concern. Right?
Yes, bridge drivers (or any driver, really) should avoid failing probe
silently.
> > potentially causing probe issues that get annoying to debug.
>
> Sorry, let's keep it fair enough, it creates nothing annoyed.
>
> If there is a probe issues, then, it is caused by ill-behavioral DT.
> *NOT* my patch. And should be found during review stage.
Even before the review stage, in the DT development stage. My point is
that creating a silent failure path in probe will make it more difficult
for DT developers to debug issues.
> If the of_graph_get_remote_node() function is not good enough,
> I suggest to improve the of_graph_get_remote_node() function,
> then all callers of it will benefits.
>
> Well, the strong word here just terrifying new programmers to call
> core function helpers. Please use more *soft* description in the
> commit message.
Could you please propose a wording that you would consider more soft ?
> > Fix it by
> > adding an error message.
> >
> > Fixes: 00084f0c01bf ("drm: bridge: thc63lvd1024: Switch to use
> > of_graph_get_remote_node()")
>
> Please drop the fixes tag at here, append the tag to a real bug-fix patch
> will make more sense imo.
> I suggest to improve the of_graph_get_remote_node() function, then all
> callers of it will benefits.
> NOT a single implement like this.
Improving core helpers is certainly a good idea, and if we do so, we can
simplify drivers. What I'm concerned is that commit 00084f0c01bf creates
a silent probe failure path, which didn't exist before it. This is why
this patch references it in the Fixes: tag, making sure that this patch
will get backported to any stable kernel that includes commit
00084f0c01bf. As far as I understand, this is business as usual. There's
nothing personal here, and no judgement on the quality of your code.
> > Signed-off-by: Laurent Pinchart
> > ---
> > drivers/gpu/drm/bridge/thc63lvd1024.c | 5 -
> > 1 file changed, 4 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/gpu/drm/bridge/thc63lvd1024.c
> > b/drivers/gpu/drm/bridge/thc63lvd1024.c
> > index 5f99f9724081..674efc489e3a 100644
> > --- a/drivers/gpu/drm/bridge/thc63lvd1024.c
> > +++ b/drivers/gpu/drm/bridge/thc63lvd1024.c
> > @@ -125,8 +125,11 @@ static int thc63_parse_dt(struct thc63_dev *thc63)
> >
> > remote = of_graph_get_remote_node(thc63->dev->of_node,
> > THC63_RGB_OUT0, -1);
> > - if (!remote)
> > + if (!remote) {
> > + dev_err(thc63->dev, "No remote endpoint for port@%u\n",
> > + THC63_RGB_OUT0);
> > return -ENODEV;
> > + }
> >
> > thc63->next = of_drm_find_bridge(remote);
> > of_node_put(remote);
> >
> > base-commit: 00084f0c01bf3a2591d007010b196e048281c455
--
Regards,
Laurent Pinchart
Re: [PATCH 3/6] drm: zynqmp_dp: Add locking
On 3/18/24 13:59, Laurent Pinchart wrote:
> Hi Sean,
>
> On Mon, Mar 18, 2024 at 01:29:12PM -0400, Sean Anderson wrote:
>> On 3/18/24 13:16, Laurent Pinchart wrote:
>> > On Fri, Mar 15, 2024 at 07:09:13PM -0400, Sean Anderson wrote:
>> >> Add some locking, since none is provided by the drm subsystem. This will
>> >
>> > That's not quite right, the DRM core doesn't call bridge operations
>> > concurrently.
>>
>> I figured something like this was going on.
>>
>> > We may need locking to protect against race conditions
>> > between bridge operations and interrupts though.
>>
>> And of course this will only get worse once we let userspace get involved.
>>
>> >> prevent the IRQ/workers/bridge API calls from stepping on each other's
>> >> toes.
>> >>
>> >> Signed-off-by: Sean Anderson
>> >> ---
>> >>
>> >> drivers/gpu/drm/xlnx/zynqmp_dp.c | 59 +++-
>> >> 1 file changed, 42 insertions(+), 17 deletions(-)
>> >>
>> >> diff --git a/drivers/gpu/drm/xlnx/zynqmp_dp.c
>> >> b/drivers/gpu/drm/xlnx/zynqmp_dp.c
>> >> index 8635b5673386..d2dee58e7bf2 100644
>> >> --- a/drivers/gpu/drm/xlnx/zynqmp_dp.c
>> >> +++ b/drivers/gpu/drm/xlnx/zynqmp_dp.c
>> >> @@ -279,6 +279,7 @@ struct zynqmp_dp_config {
>> >> * @dpsub: Display subsystem
>> >> * @iomem: device I/O memory for register access
>> >> * @reset: reset controller
>> >> + * @lock: Mutex protecting this struct and register access (but not AUX)
>> >
>> > This patch does two things at once, it defers link training from the IRQ
>> > handler to a work queue, and covers everything with a big lock. The
>> > scope is too large.
>>
>> OK, I can split this.
>>
>> > Please restrict the lock scope and document the
>> > individual fields that need to be protected, and explain the locking
>> > design in the commit message (or comments in the code).
>>
>> As said, this lock protects
>>
>> - Non-atomic registers configuring the link. That is, everything but the IRQ
>> registers (since these are accessed in an atomic fashion), and the DP AUX
>> registers (since these don't affect the link).
>> - Link configuration. This is effectively everything in zynqmp_dp which isn't
>> read-only after probe time. So from next_bridge onward.
>>
>> It's designed to protect configuration changes so we don't have to do
>> anything
>> tricky. Configuration should never be in the hot path, so I'm not worried
>> about
>> performance.
>
> If userspace can control all this directly through debugfs, can you
> guarantee that locks will be enough ? The driver doesn't expect direct
> userspace access. I have a feeling this is really quite hacky.
Yes, this is fine. The most userspace can do is force a lot of retraining. But
we
have timeouts on everything so I'm not really concerned.
--Sean
>> >> * @irq: irq
>> >> * @bridge: DRM bridge for the DP encoder
>> >> * @next_bridge: The downstream bridge
>> >> @@ -299,6 +300,7 @@ struct zynqmp_dp {
>> >> struct zynqmp_dpsub *dpsub;
>> >> void __iomem *iomem;
>> >> struct reset_control *reset;
>> >> + struct mutex lock;
>> >> int irq;
>> >>
>> >> struct drm_bridge bridge;
>> >> @@ -308,7 +310,7 @@ struct zynqmp_dp {
>> >> struct drm_dp_aux aux;
>> >> struct phy *phy[ZYNQMP_DP_MAX_LANES];
>> >> u8 num_lanes;
>> >> - struct delayed_work hpd_work;
>> >> + struct delayed_work hpd_work, hpd_irq_work;
>> >
>> > One variable per line please.
>>
>> OK
>>
>> >> enum drm_connector_status status;
>> >> bool enabled;
>> >>
>> >> @@ -1371,8 +1373,10 @@ zynqmp_dp_bridge_mode_valid(struct drm_bridge
>> >> *bridge,
>> >> }
>> >>
>> >> /* Check with link rate and lane count */
>> >> + mutex_lock(&dp->lock);
>> >> rate = zynqmp_dp_max_rate(dp->link_config.max_rate,
>> >> dp->link_config.max_lanes, dp->config.bpp);
>> >> + mutex_unlock(&dp->lock);
>> >> if (mode->clock > rate) {
>> >> dev_dbg(dp->dev, "filtered mode %s for high pixel rate\n",
>> >> mode->name);
>> >> @@ -1399,6 +1403,7 @@ static void zynqmp_dp_bridge_atomic_enable(struct
>> >> drm_bridge *bridge,
>> >>
>> >> pm_runtime_get_sync(dp->dev);
>> >>
>> >> + mutex_lock(&dp->lock);
>> >> zynqmp_dp_disp_enable(dp, old_bridge_state);
>> >>
>> >> /*
>> >> @@ -1459,6 +1464,7 @@ static void zynqmp_dp_bridge_atomic_enable(struct
>> >> drm_bridge *bridge,
>> >> zynqmp_dp_write(dp, ZYNQMP_DP_SOFTWARE_RESET,
>> >> ZYNQMP_DP_SOFTWARE_RESET_ALL);
>> >> zynqmp_dp_write(dp, ZYNQMP_DP_MAIN_STREAM_ENABLE, 1);
>> >> + mutex_unlock(&dp->lock);
>> >> }
>> >>
>> >> static void zynqmp_dp_bridge_atomic_disable(struct drm_bridge *bridge,
>> >> @@ -1466,6 +1472,7 @@ static void zynqmp_dp_bridge_atomic_disable(struct
>> >> drm_bridge *bridge,
>> >> {
>> >> struct zynqmp_dp *dp = bridge_to_dp(bridge);
>> >>
>> >> + mutex_lock(&dp->lock);
>> >> dp->enabled = false;
>> >> cancel_delayed_work(&dp->hpd_work);
>> >> zynqmp_dp_write(dp, ZYNQMP_DP_MAIN
Re: [PATCH] drm/msm/dp: move link_ready out of HPD event thread
On 3/15/2024 8:57 AM, Johan Hovold wrote:
On Thu, Mar 14, 2024 at 09:30:57AM -0700, Abhinav Kumar wrote:
On 3/14/2024 8:38 AM, Johan Hovold wrote:
On Wed, Mar 13, 2024 at 10:24:08AM -0700, Abhinav Kumar wrote:
Perhaps I'm missing something in the race that you are trying to
describe (and which I've asked you to describe in more detail so that I
don't have to spend more time trying to come up with a reproducer
myself).
The race condition is between the time we get disconnect event and set
link_ready to false, a commit can come in. Because setting link_ready to
false happens in the event thread so it could be slightly delayed.
I get this part, just not why, or rather when, that becomes a problem.
Once the disconnect event is processed, dp_hpd_unplug_handle() will
update the state to ST_DISCONNECT_PENDING, and queue a notification
event. link_ready is (before this patch) still set to 1.
This is the case I am thinking of:
1) Disconnect event happens which will call dp_hpd_unplug_handle() but
link_ready is not false yet.
2) There is a commit with a modeset, which shall trigger
atomic_disable() followed by an atomic_enable()
atomic_disable() will go through disable clocks and set hpd_state to
ST_DISCONNECTED.
3) atomic_enable() will not go through because we will bail out because
state was ST_DISCONNECTED.
if (state != ST_DISPLAY_OFF && state != ST_MAINLINK_READY) {
mutex_unlock(&dp_display->event_mutex);
return;
}
4) Now, if there is another commit with a modeset, it will go and crash
at atomic_disable()
Here a commit comes in; what exactly are you suggesting would trigger
that? And in such a way that it breaks the state machine?
Like we have seen, the commit can either come directly from userspace as
one last frame (the original bug I had given the link to) or from the
__drm_fb_helper_restore_fbdev_mode_unlocked() which happened in
sc8280xp's case. This is totally independent of the hpd_thread() with no
mutual exclusion.
This commit() can come before the link_ready was set to false. If it had
come after link_ready was set to false, atomic_check() would have failed
and no issue would have been seen.
My change is making the link_ready false sooner in the disconnect case.
One way this could cause trouble is if you end up with a call to
dp_bridge_atomic_post_disable() which updates the state to
ST_DISCONNECTED. (1)
This would then need to be followed by another call to
dp_bridge_atomic_enable() which bails out early with the link clock
disabled. (2) (And if link_ready were to be set to 0 sooner, the
likelihood of this is reduced.)
This in turn, would trigger a reset when dp_bridge_atomic_disable() is
later called.
Yes, this is exactly what I have written above.
This is the kind of description of the race I expect to see in the
commit message, and I'm still not sure what would trigger the call to
dp_bridge_atomic_post_disable() and dp_bridge_atomic_enable() (i.e. (1)
and (2) above) and whether this is a real issue or not.
I have explained what triggers the disable/enable call below.
Also note that the above scenario is quite different from the one I've
hit and described earlier.
Why is that so? Eventually it will also translate to the same scenario.
I would like to understand why this is different. I think in your case,
probably we do not know what triggers the modeset, but its a minor
detail like I have written before.
It will be hard to reproduce this. Only way I can think of is to delay
the EV_NOTIFICATION for sometime and see in dp_bridge_hpd_notify()
else if (dp_display->link_ready && status ==
connector_status_disconnected)
dp_add_event(dp, EV_HPD_UNPLUG_INT, 0, 0);
as dp_add_event() will add the event, then wakeup the event_q.
Sure that would increase the race window with the current code, but that
alone isn't enough to trigger the bug AFAICT.
Before the event thread wakes up and processes this unplug event, the
commit can come in. This is the race condition i was thinking of.
Yes, but what triggers the commit? And why would it lead to a mode set
that disables the bridge?
Commit was triggered from the userspace as it did not process the
disconnect event on time and the userspace was triggering a couple of
modesets by by changing the mode on the CRTC from 1080P to NONE to 1080P.
[drm:drm_atomic_helper_check_modeset] [CRTC:60:crtc-1] mode changed
Johan
Re: [PATCH 3/6] drm: zynqmp_dp: Add locking
Hi Sean,
On Mon, Mar 18, 2024 at 01:29:12PM -0400, Sean Anderson wrote:
> On 3/18/24 13:16, Laurent Pinchart wrote:
> > On Fri, Mar 15, 2024 at 07:09:13PM -0400, Sean Anderson wrote:
> >> Add some locking, since none is provided by the drm subsystem. This will
> >
> > That's not quite right, the DRM core doesn't call bridge operations
> > concurrently.
>
> I figured something like this was going on.
>
> > We may need locking to protect against race conditions
> > between bridge operations and interrupts though.
>
> And of course this will only get worse once we let userspace get involved.
>
> >> prevent the IRQ/workers/bridge API calls from stepping on each other's
> >> toes.
> >>
> >> Signed-off-by: Sean Anderson
> >> ---
> >>
> >> drivers/gpu/drm/xlnx/zynqmp_dp.c | 59 +++-
> >> 1 file changed, 42 insertions(+), 17 deletions(-)
> >>
> >> diff --git a/drivers/gpu/drm/xlnx/zynqmp_dp.c
> >> b/drivers/gpu/drm/xlnx/zynqmp_dp.c
> >> index 8635b5673386..d2dee58e7bf2 100644
> >> --- a/drivers/gpu/drm/xlnx/zynqmp_dp.c
> >> +++ b/drivers/gpu/drm/xlnx/zynqmp_dp.c
> >> @@ -279,6 +279,7 @@ struct zynqmp_dp_config {
> >> * @dpsub: Display subsystem
> >> * @iomem: device I/O memory for register access
> >> * @reset: reset controller
> >> + * @lock: Mutex protecting this struct and register access (but not AUX)
> >
> > This patch does two things at once, it defers link training from the IRQ
> > handler to a work queue, and covers everything with a big lock. The
> > scope is too large.
>
> OK, I can split this.
>
> > Please restrict the lock scope and document the
> > individual fields that need to be protected, and explain the locking
> > design in the commit message (or comments in the code).
>
> As said, this lock protects
>
> - Non-atomic registers configuring the link. That is, everything but the IRQ
> registers (since these are accessed in an atomic fashion), and the DP AUX
> registers (since these don't affect the link).
> - Link configuration. This is effectively everything in zynqmp_dp which isn't
> read-only after probe time. So from next_bridge onward.
>
> It's designed to protect configuration changes so we don't have to do anything
> tricky. Configuration should never be in the hot path, so I'm not worried
> about
> performance.
If userspace can control all this directly through debugfs, can you
guarantee that locks will be enough ? The driver doesn't expect direct
userspace access. I have a feeling this is really quite hacky.
> >> * @irq: irq
> >> * @bridge: DRM bridge for the DP encoder
> >> * @next_bridge: The downstream bridge
> >> @@ -299,6 +300,7 @@ struct zynqmp_dp {
> >>struct zynqmp_dpsub *dpsub;
> >>void __iomem *iomem;
> >>struct reset_control *reset;
> >> + struct mutex lock;
> >>int irq;
> >>
> >>struct drm_bridge bridge;
> >> @@ -308,7 +310,7 @@ struct zynqmp_dp {
> >>struct drm_dp_aux aux;
> >>struct phy *phy[ZYNQMP_DP_MAX_LANES];
> >>u8 num_lanes;
> >> - struct delayed_work hpd_work;
> >> + struct delayed_work hpd_work, hpd_irq_work;
> >
> > One variable per line please.
>
> OK
>
> >>enum drm_connector_status status;
> >>bool enabled;
> >>
> >> @@ -1371,8 +1373,10 @@ zynqmp_dp_bridge_mode_valid(struct drm_bridge
> >> *bridge,
> >>}
> >>
> >>/* Check with link rate and lane count */
> >> + mutex_lock(&dp->lock);
> >>rate = zynqmp_dp_max_rate(dp->link_config.max_rate,
> >> dp->link_config.max_lanes, dp->config.bpp);
> >> + mutex_unlock(&dp->lock);
> >>if (mode->clock > rate) {
> >>dev_dbg(dp->dev, "filtered mode %s for high pixel rate\n",
> >>mode->name);
> >> @@ -1399,6 +1403,7 @@ static void zynqmp_dp_bridge_atomic_enable(struct
> >> drm_bridge *bridge,
> >>
> >>pm_runtime_get_sync(dp->dev);
> >>
> >> + mutex_lock(&dp->lock);
> >>zynqmp_dp_disp_enable(dp, old_bridge_state);
> >>
> >>/*
> >> @@ -1459,6 +1464,7 @@ static void zynqmp_dp_bridge_atomic_enable(struct
> >> drm_bridge *bridge,
> >>zynqmp_dp_write(dp, ZYNQMP_DP_SOFTWARE_RESET,
> >>ZYNQMP_DP_SOFTWARE_RESET_ALL);
> >>zynqmp_dp_write(dp, ZYNQMP_DP_MAIN_STREAM_ENABLE, 1);
> >> + mutex_unlock(&dp->lock);
> >> }
> >>
> >> static void zynqmp_dp_bridge_atomic_disable(struct drm_bridge *bridge,
> >> @@ -1466,6 +1472,7 @@ static void zynqmp_dp_bridge_atomic_disable(struct
> >> drm_bridge *bridge,
> >> {
> >>struct zynqmp_dp *dp = bridge_to_dp(bridge);
> >>
> >> + mutex_lock(&dp->lock);
> >>dp->enabled = false;
> >>cancel_delayed_work(&dp->hpd_work);
> >>zynqmp_dp_write(dp, ZYNQMP_DP_MAIN_STREAM_ENABLE, 0);
> >> @@ -1476,6 +1483,7 @@ static void zynqmp_dp_bridge_atomic_disable(struct
> >> drm_bridge *bridge,
> >>zynqmp_dp_write(dp, ZYNQMP_DP_TX_AUDIO_CONTROL, 0);
> >>
> >>zynqmp_dp_disp_disable(dp, old_bridge_state);
> >> + mutex_unlock(&dp->lock);
> >>
>
Re: [PATCH 6/6] drm: zynqmp_dp: Add debugfs interface for compliance testing
On Sat, Mar 16, 2024 at 07:56:52PM +0200, Dmitry Baryshkov wrote:
> On Sat, 16 Mar 2024 at 01:09, Sean Anderson wrote:
> >
> > Add a debugfs interface for exercising the various test modes supported
> > by the DisplayPort controller. This allows performing compliance
> > testing, or performing signal integrity measurements on a failing link.
> > At the moment, we do not support sink-driven link quality testing,
> > although such support would be fairly easy to add.
>
> Could you please point out how this is used for compliance testing? We
> have been using the msm_dp_compliance tool [1].
>
> I think it would be nice to rework our drivers towards a common
> debugfs interface used for DP connectors, maybe defining generic
> internal interface/helpers like Maxime is implementing for HDMI
> connectors.
This would be really nice :-)
> [1]
> https://gitlab.freedesktop.org/drm/igt-gpu-tools/-/blob/master/tools/msm_dp_compliance.c?ref_type=heads
>
> >
> > Signed-off-by: Sean Anderson
> > ---
> >
> > drivers/gpu/drm/xlnx/zynqmp_dp.c | 591 ++-
> > 1 file changed, 590 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/gpu/drm/xlnx/zynqmp_dp.c
> > b/drivers/gpu/drm/xlnx/zynqmp_dp.c
> > index 040f7b88ee51..57032186e1ca 100644
> > --- a/drivers/gpu/drm/xlnx/zynqmp_dp.c
> > +++ b/drivers/gpu/drm/xlnx/zynqmp_dp.c
> > @@ -18,7 +18,9 @@
> > #include
> > #include
> >
> > +#include
> > #include
> > +#include
> > #include
> > #include
> > #include
> > @@ -50,6 +52,7 @@ MODULE_PARM_DESC(power_on_delay_ms, "DP power on delay in
> > msec (default: 4)");
> > #define ZYNQMP_DP_LANE_COUNT_SET 0x4
> > #define ZYNQMP_DP_ENHANCED_FRAME_EN0x8
> > #define ZYNQMP_DP_TRAINING_PATTERN_SET 0xc
> > +#define ZYNQMP_DP_LINK_QUAL_PATTERN_SET0x10
> > #define ZYNQMP_DP_SCRAMBLING_DISABLE 0x14
> > #define ZYNQMP_DP_DOWNSPREAD_CTL 0x18
> > #define ZYNQMP_DP_SOFTWARE_RESET 0x1c
> > @@ -63,6 +66,9 @@ MODULE_PARM_DESC(power_on_delay_ms, "DP power on delay in
> > msec (default: 4)");
> >
> > ZYNQMP_DP_SOFTWARE_RESET_STREAM3 | \
> >
> > ZYNQMP_DP_SOFTWARE_RESET_STREAM4 | \
> >
> > ZYNQMP_DP_SOFTWARE_RESET_AUX)
> > +#define ZYNQMP_DP_COMP_PATTERN_80BIT_1 0x20
> > +#define ZYNQMP_DP_COMP_PATTERN_80BIT_2 0x24
> > +#define ZYNQMP_DP_COMP_PATTERN_80BIT_3 0x28
> >
> > /* Core enable registers */
> > #define ZYNQMP_DP_TRANSMITTER_ENABLE 0x80
> > @@ -206,6 +212,7 @@ MODULE_PARM_DESC(power_on_delay_ms, "DP power on delay
> > in msec (default: 4)");
> > #define ZYNQMP_DP_TX_PHY_POWER_DOWN_LANE_2 BIT(2)
> > #define ZYNQMP_DP_TX_PHY_POWER_DOWN_LANE_3 BIT(3)
> > #define ZYNQMP_DP_TX_PHY_POWER_DOWN_ALL0xf
> > +#define ZYNQMP_DP_TRANSMIT_PRBS7 0x230
> > #define ZYNQMP_DP_PHY_PRECURSOR_LANE_0 0x23c
> > #define ZYNQMP_DP_PHY_PRECURSOR_LANE_1 0x240
> > #define ZYNQMP_DP_PHY_PRECURSOR_LANE_2 0x244
> > @@ -273,6 +280,69 @@ struct zynqmp_dp_config {
> > u8 bpp;
> > };
> >
> > +/**
> > + * enum test_pattern - Test patterns for test testing
> > + * TEST_VIDEO: Use regular video input
> > + * TEST_SYMBOL_ERROR: Symbol error measurement pattern
> > + * TEST_PRBS7: Output of the PRBS7 (x^7 + x^6 + 1) polynomial
> > + * TEST_80BIT_CUSTOM: A custom 80-bit pattern
> > + * TEST_CP2520: HBR2 compliance eye pattern
> > + * TEST_TPS1: Link training symbol pattern TPS1 (/D10.2/)
> > + * TEST_TPS2: Link training symbol pattern TPS2
> > + * TEST_TPS3: Link training symbol pattern TPS3 (for HBR2)
> > + */
> > +enum test_pattern {
> > + TEST_VIDEO,
> > + TEST_TPS1,
> > + TEST_TPS2,
> > + TEST_TPS3,
> > + TEST_SYMBOL_ERROR,
> > + TEST_PRBS7,
> > + TEST_80BIT_CUSTOM,
> > + TEST_CP2520,
> > +};
> > +
> > +static const char *const test_pattern_str[] = {
> > + [TEST_VIDEO] = "video",
> > + [TEST_TPS1] = "tps1",
> > + [TEST_TPS2] = "tps2",
> > + [TEST_TPS3] = "tps3",
> > + [TEST_SYMBOL_ERROR] = "symbol-error",
> > + [TEST_PRBS7] = "prbs7",
> > + [TEST_80BIT_CUSTOM] = "80bit-custom",
> > + [TEST_CP2520] = "cp2520",
> > +};
> > +
> > +/**
> > + * struct zynqmp_dp_test - Configuration for test mode
> > + * @pattern: The test pattern
> > + * @enhanced: Use enhanced framing
> > + * @downspread: Use SSC
> > + * @active: Whether test mode is active
> > + * @custom: Custom pattern for %TEST_80BIT_CUSTOM
> > + * @train_set: Voltage/preemphasis settings
> > + * @bw_code: Bandwidth code for the link
> > + * @link_cnt: Number of lanes
> >
Re: [PATCH 6/6] drm: zynqmp_dp: Add debugfs interface for compliance testing
On Mon, Mar 18, 2024 at 11:06:40AM -0400, Sean Anderson wrote:
> On 3/16/24 06:14, kernel test robot wrote:
> > Hi Sean,
> >
> > kernel test robot noticed the following build warnings:
> >
> > [auto build test WARNING on v6.8]
> > [cannot apply to drm-misc/drm-misc-next linus/master next-20240315]
> > [If your patch is applied to the wrong git tree, kindly drop us a note.
> > And when submitting patch, we suggest to use '--base' as documented in
> > https://git-scm.com/docs/git-format-patch#_base_tree_information]
> >
> > url:
> > https://github.com/intel-lab-lkp/linux/commits/Sean-Anderson/drm-zynqmp_dp-Downgrade-log-level-for-aux-retries-message/20240316-071208
> > base: v6.8
> > patch link:
> > https://lore.kernel.org/r/20240315230916.1759060-7-sean.anderson%40linux.dev
> > patch subject: [PATCH 6/6] drm: zynqmp_dp: Add debugfs interface for
> > compliance testing
> > config: microblaze-allmodconfig
> > (https://download.01.org/0day-ci/archive/20240316/202403161704.achjdsjg-...@intel.com/config)
> > compiler: microblaze-linux-gcc (GCC) 13.2.0
> > reproduce (this is a W=1 build):
> > (https://download.01.org/0day-ci/archive/20240316/202403161704.achjdsjg-...@intel.com/reproduce)
> >
> > If you fix the issue in a separate patch/commit (i.e. not just a new
> > version of
> > the same patch/commit), kindly add following tags
> > | Reported-by: kernel test robot
> > | Closes:
> > https://lore.kernel.org/oe-kbuild-all/202403161704.achjdsjg-...@intel.com/
> >
> > All warnings (new ones prefixed by >>):
> >
> >drivers/gpu/drm/xlnx/zynqmp_dp.c: In function
> > 'zynqmp_dp_bridge_debugfs_init':
> >>> drivers/gpu/drm/xlnx/zynqmp_dp.c:2168:31: warning: 'sprintf' may write a
> >>> terminating nul past the end of the destination [-Wformat-overflow=]
> > 2168 | sprintf(name, fmt, i);
> > | ^~~
> >drivers/gpu/drm/xlnx/zynqmp_dp.c:2168:17: note: 'sprintf' output between
> > 18 and 20 bytes into a destination of size 19
> > 2168 | sprintf(name, fmt, i);
> > | ^
>
> Not a bug, as i will be at most 4, which uses 1 digit.
The compiler can't know that. Please fix this, there's a zero warning
policy.
> > vim +/sprintf +2168 drivers/gpu/drm/xlnx/zynqmp_dp.c
> >
> > 2136
> > 2137 DEFINE_DEBUGFS_ATTRIBUTE(fops_zynqmp_dp_rate,
> > zynqmp_dp_rate_get,
> > 2138 zynqmp_dp_rate_set, "%llu\n");
> > 2139
> > 2140 static void zynqmp_dp_bridge_debugfs_init(struct drm_bridge
> > *bridge,
> > 2141struct dentry *root)
> > 2142 {
> > 2143 struct zynqmp_dp *dp = bridge_to_dp(bridge);
> > 2144 struct dentry *test;
> > 2145 int i;
> > 2146
> > 2147 dp->test.bw_code = DP_LINK_BW_5_4;
> > 2148 dp->test.link_cnt = dp->num_lanes;
> > 2149
> > 2150 test = debugfs_create_dir("test", root);
> > 2151 #define CREATE_FILE(name) \
> > 2152 debugfs_create_file(#name, 0600, test, dp,
> > &fops_zynqmp_dp_##name)
> > 2153 CREATE_FILE(pattern);
> > 2154 CREATE_FILE(enhanced);
> > 2155 CREATE_FILE(downspread);
> > 2156 CREATE_FILE(active);
> > 2157 CREATE_FILE(custom);
> > 2158 CREATE_FILE(rate);
> > 2159 CREATE_FILE(lanes);
> > 2160
> > 2161 for (i = 0; i < dp->num_lanes; i++) {
> > 2162 static const char fmt[] = "lane%d_preemphasis";
> > 2163 char name[sizeof(fmt)];
> > 2164
> > 2165 dp->debugfs_train_set[i].dp = dp;
> > 2166 dp->debugfs_train_set[i].lane = i;
> > 2167
> >> 2168 sprintf(name, fmt, i);
> > 2169 debugfs_create_file(name, 0600, test,
> > 2170 &dp->debugfs_train_set[i],
> > 2171
> > &fops_zynqmp_dp_preemphasis);
> > 2172
> > 2173 sprintf(name, "lane%d_swing", i);
> > 2174 debugfs_create_file(name, 0600, test,
> > 2175 &dp->debugfs_train_set[i],
> > 2176 &fops_zynqmp_dp_swing);
> > 2177 }
> > 2178 }
> > 2179
--
Regards,
Laurent Pinchart
Re: [PATCH 5/6] drm: zynqmp_dp: Optionally ignore DPCD errors
Hi Sean,
Thank you for the patch.
On Fri, Mar 15, 2024 at 07:09:15PM -0400, Sean Anderson wrote:
> When testing, it's convenient to be able to ignore DPCD errors if there
> is test equipment which can't emulate a DPRX connected to the output.
> Add some (currently-unused) options to ignore these errors and just
> reconfigure our internal registers as we usually would.
This seems to be a problem that is not limited to the ZynqMP DP.
Wouldn't it be better to solve it in the DRM DP DPCD helpers instead ?
You could expose a parameter on the AUX bus in debugfs to ignore errors,
and cause the drm_dp_dpcd_write*() functions to return 0.
> Signed-off-by: Sean Anderson
> ---
>
> drivers/gpu/drm/xlnx/zynqmp_dp.c | 37
> 1 file changed, 23 insertions(+), 14 deletions(-)
>
> diff --git a/drivers/gpu/drm/xlnx/zynqmp_dp.c
> b/drivers/gpu/drm/xlnx/zynqmp_dp.c
> index 24043847dab4..040f7b88ee51 100644
> --- a/drivers/gpu/drm/xlnx/zynqmp_dp.c
> +++ b/drivers/gpu/drm/xlnx/zynqmp_dp.c
> @@ -628,6 +628,7 @@ static void zynqmp_dp_adjust_train(struct zynqmp_dp *dp,
> * zynqmp_dp_update_vs_emph - Update the training values
> * @dp: DisplayPort IP core structure
> * @train_set: A set of training values
> + * @ignore_dpcd: Ignore DPCD errors
> *
> * Update the training values based on the request from sink. The mapped
> values
> * are predefined, and values(vs, pe, pc) are from the device manual.
> @@ -635,15 +636,19 @@ static void zynqmp_dp_adjust_train(struct zynqmp_dp *dp,
> * Return: 0 if vs and emph are updated successfully, or the error code
> returned
> * by drm_dp_dpcd_write().
> */
> -static int zynqmp_dp_update_vs_emph(struct zynqmp_dp *dp, u8 *train_set)
> +static int zynqmp_dp_update_vs_emph(struct zynqmp_dp *dp, u8 *train_set,
> + bool ignore_dpcd)
> {
> unsigned int i;
> int ret;
>
> ret = drm_dp_dpcd_write(&dp->aux, DP_TRAINING_LANE0_SET, train_set,
> dp->mode.lane_cnt);
> - if (ret < 0)
> - return ret;
> + if (ret < 0) {
> + if (!ignore_dpcd)
> + return ret;
> + dev_warn(dp->dev, "failed to update vs/emph\n");
> + }
>
> for (i = 0; i < dp->mode.lane_cnt; i++) {
> u32 reg = ZYNQMP_DP_SUB_TX_PHY_PRECURSOR_LANE_0 + i * 4;
> @@ -692,7 +697,7 @@ static int zynqmp_dp_link_train_cr(struct zynqmp_dp *dp)
>* So, This loop should exit before 512 iterations
>*/
> for (max_tries = 0; max_tries < 512; max_tries++) {
> - ret = zynqmp_dp_update_vs_emph(dp, dp->train_set);
> + ret = zynqmp_dp_update_vs_emph(dp, dp->train_set, false);
> if (ret)
> return ret;
>
> @@ -757,7 +762,7 @@ static int zynqmp_dp_link_train_ce(struct zynqmp_dp *dp)
> return ret;
>
> for (tries = 0; tries < DP_MAX_TRAINING_TRIES; tries++) {
> - ret = zynqmp_dp_update_vs_emph(dp, dp->train_set);
> + ret = zynqmp_dp_update_vs_emph(dp, dp->train_set, false);
> if (ret)
> return ret;
>
> @@ -785,11 +790,12 @@ static int zynqmp_dp_link_train_ce(struct zynqmp_dp *dp)
> * @lane_cnt: The number of lanes to use
> * @enhanced: Use enhanced framing
> * @downspread: Enable spread-spectrum clocking
> + * @ignore_dpcd: Ignore DPCD errors; useful for testing
> *
> * Return: 0 on success, or -errno on failure
> */
> static int zynqmp_dp_setup(struct zynqmp_dp *dp, u8 bw_code, u8 lane_cnt,
> -bool enhanced, bool downspread)
> +bool enhanced, bool downspread, bool ignore_dpcd)
> {
> u32 reg;
> u8 aux_lane_cnt = lane_cnt;
> @@ -812,21 +818,24 @@ static int zynqmp_dp_setup(struct zynqmp_dp *dp, u8
> bw_code, u8 lane_cnt,
>
> ret = drm_dp_dpcd_writeb(&dp->aux, DP_LANE_COUNT_SET, aux_lane_cnt);
> if (ret < 0) {
> - dev_err(dp->dev, "failed to set lane count\n");
> - return ret;
> + dev_warn(dp->dev, "failed to set lane count\n");
> + if (!ignore_dpcd)
> + return ret;
> }
>
> ret = drm_dp_dpcd_writeb(&dp->aux, DP_MAIN_LINK_CHANNEL_CODING_SET,
>DP_SET_ANSI_8B10B);
> if (ret < 0) {
> - dev_err(dp->dev, "failed to set ANSI 8B/10B encoding\n");
> - return ret;
> + dev_warn(dp->dev, "failed to set ANSI 8B/10B encoding\n");
> + if (!ignore_dpcd)
> + return ret;
> }
>
> ret = drm_dp_dpcd_writeb(&dp->aux, DP_LINK_BW_SET, bw_code);
> if (ret < 0) {
> - dev_err(dp->dev, "failed to set DP bandwidth\n");
> - return ret;
> + dev_warn(dp->dev, "failed to set DP bandwidth\n");
> + if (!ignore_dpcd)
> + return ret;
> }
>
> zynqmp_
Re: [PATCH 4/6] drm: zynqmp_dp: Split off several helper functions
Hi Sean,
Thank you for the patch.
On Fri, Mar 15, 2024 at 07:09:14PM -0400, Sean Anderson wrote:
> In preparation for supporting compliance testing, split off several
> helper functions. No functional change intended.
>
> Signed-off-by: Sean Anderson
> ---
>
> drivers/gpu/drm/xlnx/zynqmp_dp.c | 49 +---
> 1 file changed, 33 insertions(+), 16 deletions(-)
>
> diff --git a/drivers/gpu/drm/xlnx/zynqmp_dp.c
> b/drivers/gpu/drm/xlnx/zynqmp_dp.c
> index d2dee58e7bf2..24043847dab4 100644
> --- a/drivers/gpu/drm/xlnx/zynqmp_dp.c
> +++ b/drivers/gpu/drm/xlnx/zynqmp_dp.c
> @@ -627,6 +627,7 @@ static void zynqmp_dp_adjust_train(struct zynqmp_dp *dp,
> /**
> * zynqmp_dp_update_vs_emph - Update the training values
> * @dp: DisplayPort IP core structure
> + * @train_set: A set of training values
> *
> * Update the training values based on the request from sink. The mapped
> values
> * are predefined, and values(vs, pe, pc) are from the device manual.
> @@ -634,12 +635,12 @@ static void zynqmp_dp_adjust_train(struct zynqmp_dp *dp,
> * Return: 0 if vs and emph are updated successfully, or the error code
> returned
> * by drm_dp_dpcd_write().
> */
> -static int zynqmp_dp_update_vs_emph(struct zynqmp_dp *dp)
> +static int zynqmp_dp_update_vs_emph(struct zynqmp_dp *dp, u8 *train_set)
> {
> unsigned int i;
> int ret;
>
> - ret = drm_dp_dpcd_write(&dp->aux, DP_TRAINING_LANE0_SET, dp->train_set,
> + ret = drm_dp_dpcd_write(&dp->aux, DP_TRAINING_LANE0_SET, train_set,
> dp->mode.lane_cnt);
> if (ret < 0)
> return ret;
> @@ -647,7 +648,7 @@ static int zynqmp_dp_update_vs_emph(struct zynqmp_dp *dp)
> for (i = 0; i < dp->mode.lane_cnt; i++) {
> u32 reg = ZYNQMP_DP_SUB_TX_PHY_PRECURSOR_LANE_0 + i * 4;
> union phy_configure_opts opts = { 0 };
> - u8 train = dp->train_set[i];
> + u8 train = train_set[i];
>
> opts.dp.voltage[0] = (train & DP_TRAIN_VOLTAGE_SWING_MASK)
> >> DP_TRAIN_VOLTAGE_SWING_SHIFT;
> @@ -691,7 +692,7 @@ static int zynqmp_dp_link_train_cr(struct zynqmp_dp *dp)
>* So, This loop should exit before 512 iterations
>*/
> for (max_tries = 0; max_tries < 512; max_tries++) {
> - ret = zynqmp_dp_update_vs_emph(dp);
> + ret = zynqmp_dp_update_vs_emph(dp, dp->train_set);
> if (ret)
> return ret;
>
> @@ -756,7 +757,7 @@ static int zynqmp_dp_link_train_ce(struct zynqmp_dp *dp)
> return ret;
>
> for (tries = 0; tries < DP_MAX_TRAINING_TRIES; tries++) {
> - ret = zynqmp_dp_update_vs_emph(dp);
> + ret = zynqmp_dp_update_vs_emph(dp, dp->train_set);
> if (ret)
> return ret;
>
> @@ -779,28 +780,28 @@ static int zynqmp_dp_link_train_ce(struct zynqmp_dp *dp)
> }
>
> /**
> - * zynqmp_dp_train - Train the link
> - * @dp: DisplayPort IP core structure
> + * zynqmp_dp_setup() - Set up major link parameters
> + * @bw_code: The link bandwidth as a multiple of 270 MHz
> + * @lane_cnt: The number of lanes to use
> + * @enhanced: Use enhanced framing
> + * @downspread: Enable spread-spectrum clocking
> *
> - * Return: 0 if all trains are done successfully, or corresponding error
> code.
> + * Return: 0 on success, or -errno on failure
> */
> -static int zynqmp_dp_train(struct zynqmp_dp *dp)
> +static int zynqmp_dp_setup(struct zynqmp_dp *dp, u8 bw_code, u8 lane_cnt,
> +bool enhanced, bool downspread)
> {
> u32 reg;
> - u8 bw_code = dp->mode.bw_code;
> - u8 lane_cnt = dp->mode.lane_cnt;
> u8 aux_lane_cnt = lane_cnt;
> - bool enhanced;
> int ret;
>
> zynqmp_dp_write(dp, ZYNQMP_DP_LANE_COUNT_SET, lane_cnt);
> - enhanced = drm_dp_enhanced_frame_cap(dp->dpcd);
> if (enhanced) {
> zynqmp_dp_write(dp, ZYNQMP_DP_ENHANCED_FRAME_EN, 1);
> aux_lane_cnt |= DP_LANE_COUNT_ENHANCED_FRAME_EN;
> }
>
> - if (dp->dpcd[3] & 0x1) {
> + if (downspread) {
> zynqmp_dp_write(dp, ZYNQMP_DP_DOWNSPREAD_CTL, 1);
> drm_dp_dpcd_writeb(&dp->aux, DP_DOWNSPREAD_CTRL,
> DP_SPREAD_AMP_0_5);
> @@ -843,8 +844,24 @@ static int zynqmp_dp_train(struct zynqmp_dp *dp)
> }
>
> zynqmp_dp_write(dp, ZYNQMP_DP_PHY_CLOCK_SELECT, reg);
> - ret = zynqmp_dp_phy_ready(dp);
> - if (ret < 0)
> + return zynqmp_dp_phy_ready(dp);
> +}
> +
> +
> +/**
> + * zynqmp_dp_train - Train the link
> + * @dp: DisplayPort IP core structure
> + *
> + * Return: 0 if all trains are done successfully, or corresponding error
> code.
> + */
> +static int zynqmp_dp_train(struct zynqmp_dp *dp)
> +{
> + int ret;
> +
> + ret = zynqmp_dp_setup(dp, dp->mode.bw_code, dp->mode.lane_cnt,
> +
Re: [PATCH 3/6] drm: zynqmp_dp: Add locking
On 3/18/24 13:16, Laurent Pinchart wrote:
> Hi Sean,
>
> Thank you for the patch.
>
> On Fri, Mar 15, 2024 at 07:09:13PM -0400, Sean Anderson wrote:
>> Add some locking, since none is provided by the drm subsystem. This will
>
> That's not quite right, the DRM core doesn't call bridge operations
> concurrently.
I figured something like this was going on.
> We may need locking to protect against race conditions
> between bridge operations and interrupts though.
And of course this will only get worse once we let userspace get involved.
>> prevent the IRQ/workers/bridge API calls from stepping on each other's
>> toes.
>>
>> Signed-off-by: Sean Anderson
>> ---
>>
>> drivers/gpu/drm/xlnx/zynqmp_dp.c | 59 +++-
>> 1 file changed, 42 insertions(+), 17 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/xlnx/zynqmp_dp.c
>> b/drivers/gpu/drm/xlnx/zynqmp_dp.c
>> index 8635b5673386..d2dee58e7bf2 100644
>> --- a/drivers/gpu/drm/xlnx/zynqmp_dp.c
>> +++ b/drivers/gpu/drm/xlnx/zynqmp_dp.c
>> @@ -279,6 +279,7 @@ struct zynqmp_dp_config {
>> * @dpsub: Display subsystem
>> * @iomem: device I/O memory for register access
>> * @reset: reset controller
>> + * @lock: Mutex protecting this struct and register access (but not AUX)
>
> This patch does two things at once, it defers link training from the IRQ
> handler to a work queue, and covers everything with a big lock. The
> scope is too large.
OK, I can split this.
> Please restrict the lock scope and document the
> individual fields that need to be protected, and explain the locking
> design in the commit message (or comments in the code).
As said, this lock protects
- Non-atomic registers configuring the link. That is, everything but the IRQ
registers (since these are accessed in an atomic fashion), and the DP AUX
registers (since these don't affect the link).
- Link configuration. This is effectively everything in zynqmp_dp which isn't
read-only after probe time. So from next_bridge onward.
It's designed to protect configuration changes so we don't have to do anything
tricky. Configuration should never be in the hot path, so I'm not worried about
performance.
>> * @irq: irq
>> * @bridge: DRM bridge for the DP encoder
>> * @next_bridge: The downstream bridge
>> @@ -299,6 +300,7 @@ struct zynqmp_dp {
>> struct zynqmp_dpsub *dpsub;
>> void __iomem *iomem;
>> struct reset_control *reset;
>> +struct mutex lock;
>> int irq;
>>
>> struct drm_bridge bridge;
>> @@ -308,7 +310,7 @@ struct zynqmp_dp {
>> struct drm_dp_aux aux;
>> struct phy *phy[ZYNQMP_DP_MAX_LANES];
>> u8 num_lanes;
>> -struct delayed_work hpd_work;
>> +struct delayed_work hpd_work, hpd_irq_work;
>
> One variable per line please.
OK
>> enum drm_connector_status status;
>> bool enabled;
>>
>> @@ -1371,8 +1373,10 @@ zynqmp_dp_bridge_mode_valid(struct drm_bridge *bridge,
>> }
>>
>> /* Check with link rate and lane count */
>> +mutex_lock(&dp->lock);
>> rate = zynqmp_dp_max_rate(dp->link_config.max_rate,
>>dp->link_config.max_lanes, dp->config.bpp);
>> +mutex_unlock(&dp->lock);
>> if (mode->clock > rate) {
>> dev_dbg(dp->dev, "filtered mode %s for high pixel rate\n",
>> mode->name);
>> @@ -1399,6 +1403,7 @@ static void zynqmp_dp_bridge_atomic_enable(struct
>> drm_bridge *bridge,
>>
>> pm_runtime_get_sync(dp->dev);
>>
>> +mutex_lock(&dp->lock);
>> zynqmp_dp_disp_enable(dp, old_bridge_state);
>>
>> /*
>> @@ -1459,6 +1464,7 @@ static void zynqmp_dp_bridge_atomic_enable(struct
>> drm_bridge *bridge,
>> zynqmp_dp_write(dp, ZYNQMP_DP_SOFTWARE_RESET,
>> ZYNQMP_DP_SOFTWARE_RESET_ALL);
>> zynqmp_dp_write(dp, ZYNQMP_DP_MAIN_STREAM_ENABLE, 1);
>> +mutex_unlock(&dp->lock);
>> }
>>
>> static void zynqmp_dp_bridge_atomic_disable(struct drm_bridge *bridge,
>> @@ -1466,6 +1472,7 @@ static void zynqmp_dp_bridge_atomic_disable(struct
>> drm_bridge *bridge,
>> {
>> struct zynqmp_dp *dp = bridge_to_dp(bridge);
>>
>> +mutex_lock(&dp->lock);
>> dp->enabled = false;
>> cancel_delayed_work(&dp->hpd_work);
>> zynqmp_dp_write(dp, ZYNQMP_DP_MAIN_STREAM_ENABLE, 0);
>> @@ -1476,6 +1483,7 @@ static void zynqmp_dp_bridge_atomic_disable(struct
>> drm_bridge *bridge,
>> zynqmp_dp_write(dp, ZYNQMP_DP_TX_AUDIO_CONTROL, 0);
>>
>> zynqmp_dp_disp_disable(dp, old_bridge_state);
>> +mutex_unlock(&dp->lock);
>>
>> pm_runtime_put_sync(dp->dev);
>> }
>> @@ -1518,6 +1526,8 @@ static enum drm_connector_status
>> zynqmp_dp_bridge_detect(struct drm_bridge *brid
>> u32 state, i;
>> int ret;
>>
>> +mutex_lock(&dp->lock);
>> +
>> /*
>> * This is from heuristic. It takes some delay (ex, 100 ~ 500 msec) to
>> * get the HPD signal with some monitors.
>> @@ -1545,11 +1555,13 @@ static enum drm
Re: [PATCH 3/6] drm: zynqmp_dp: Add locking
Hi Sean,
Thank you for the patch.
On Fri, Mar 15, 2024 at 07:09:13PM -0400, Sean Anderson wrote:
> Add some locking, since none is provided by the drm subsystem. This will
That's not quite right, the DRM core doesn't call bridge operations
concurrently. We may need locking to protect against race conditions
between bridge operations and interrupts though.
> prevent the IRQ/workers/bridge API calls from stepping on each other's
> toes.
>
> Signed-off-by: Sean Anderson
> ---
>
> drivers/gpu/drm/xlnx/zynqmp_dp.c | 59 +++-
> 1 file changed, 42 insertions(+), 17 deletions(-)
>
> diff --git a/drivers/gpu/drm/xlnx/zynqmp_dp.c
> b/drivers/gpu/drm/xlnx/zynqmp_dp.c
> index 8635b5673386..d2dee58e7bf2 100644
> --- a/drivers/gpu/drm/xlnx/zynqmp_dp.c
> +++ b/drivers/gpu/drm/xlnx/zynqmp_dp.c
> @@ -279,6 +279,7 @@ struct zynqmp_dp_config {
> * @dpsub: Display subsystem
> * @iomem: device I/O memory for register access
> * @reset: reset controller
> + * @lock: Mutex protecting this struct and register access (but not AUX)
This patch does two things at once, it defers link training from the IRQ
handler to a work queue, and covers everything with a big lock. The
scope is too large. Please restrict the lock scope and document the
individual fields that need to be protected, and explain the locking
design in the commit message (or comments in the code).
> * @irq: irq
> * @bridge: DRM bridge for the DP encoder
> * @next_bridge: The downstream bridge
> @@ -299,6 +300,7 @@ struct zynqmp_dp {
> struct zynqmp_dpsub *dpsub;
> void __iomem *iomem;
> struct reset_control *reset;
> + struct mutex lock;
> int irq;
>
> struct drm_bridge bridge;
> @@ -308,7 +310,7 @@ struct zynqmp_dp {
> struct drm_dp_aux aux;
> struct phy *phy[ZYNQMP_DP_MAX_LANES];
> u8 num_lanes;
> - struct delayed_work hpd_work;
> + struct delayed_work hpd_work, hpd_irq_work;
One variable per line please.
> enum drm_connector_status status;
> bool enabled;
>
> @@ -1371,8 +1373,10 @@ zynqmp_dp_bridge_mode_valid(struct drm_bridge *bridge,
> }
>
> /* Check with link rate and lane count */
> + mutex_lock(&dp->lock);
> rate = zynqmp_dp_max_rate(dp->link_config.max_rate,
> dp->link_config.max_lanes, dp->config.bpp);
> + mutex_unlock(&dp->lock);
> if (mode->clock > rate) {
> dev_dbg(dp->dev, "filtered mode %s for high pixel rate\n",
> mode->name);
> @@ -1399,6 +1403,7 @@ static void zynqmp_dp_bridge_atomic_enable(struct
> drm_bridge *bridge,
>
> pm_runtime_get_sync(dp->dev);
>
> + mutex_lock(&dp->lock);
> zynqmp_dp_disp_enable(dp, old_bridge_state);
>
> /*
> @@ -1459,6 +1464,7 @@ static void zynqmp_dp_bridge_atomic_enable(struct
> drm_bridge *bridge,
> zynqmp_dp_write(dp, ZYNQMP_DP_SOFTWARE_RESET,
> ZYNQMP_DP_SOFTWARE_RESET_ALL);
> zynqmp_dp_write(dp, ZYNQMP_DP_MAIN_STREAM_ENABLE, 1);
> + mutex_unlock(&dp->lock);
> }
>
> static void zynqmp_dp_bridge_atomic_disable(struct drm_bridge *bridge,
> @@ -1466,6 +1472,7 @@ static void zynqmp_dp_bridge_atomic_disable(struct
> drm_bridge *bridge,
> {
> struct zynqmp_dp *dp = bridge_to_dp(bridge);
>
> + mutex_lock(&dp->lock);
> dp->enabled = false;
> cancel_delayed_work(&dp->hpd_work);
> zynqmp_dp_write(dp, ZYNQMP_DP_MAIN_STREAM_ENABLE, 0);
> @@ -1476,6 +1483,7 @@ static void zynqmp_dp_bridge_atomic_disable(struct
> drm_bridge *bridge,
> zynqmp_dp_write(dp, ZYNQMP_DP_TX_AUDIO_CONTROL, 0);
>
> zynqmp_dp_disp_disable(dp, old_bridge_state);
> + mutex_unlock(&dp->lock);
>
> pm_runtime_put_sync(dp->dev);
> }
> @@ -1518,6 +1526,8 @@ static enum drm_connector_status
> zynqmp_dp_bridge_detect(struct drm_bridge *brid
> u32 state, i;
> int ret;
>
> + mutex_lock(&dp->lock);
> +
> /*
>* This is from heuristic. It takes some delay (ex, 100 ~ 500 msec) to
>* get the HPD signal with some monitors.
> @@ -1545,11 +1555,13 @@ static enum drm_connector_status
> zynqmp_dp_bridge_detect(struct drm_bridge *brid
> dp->num_lanes);
>
> dp->status = connector_status_connected;
> + mutex_unlock(&dp->lock);
> return connector_status_connected;
> }
>
> disconnected:
> dp->status = connector_status_disconnected;
> + mutex_unlock(&dp->lock);
> return connector_status_disconnected;
> }
>
> @@ -1611,6 +1623,29 @@ static void zynqmp_dp_hpd_work_func(struct work_struct
> *work)
> drm_bridge_hpd_notify(&dp->bridge, status);
> }
>
> +static void zynqmp_dp_hpd_irq_work_func(struct work_struct *work)
> +{
> + struct zynqmp_dp *dp = container_of(work, struct zynqmp_dp,
> + hpd_irq_work.work);
> + u8
Re: [PATCH 07/43] fbdev/deferred-io: Provide get_page hook in struct fb_deferred_io
Thomas Zimmermann writes: > Add a callback for drivers to provide framebuffer pages to fbdev's > deferred-I/O helpers. Implementations need to acquire a reference on > the page before returning it. Returning NULL generates a SIGBUS > signal. > > This will be useful for DRM's fbdev emulation with GEM-shemem buffer GEM-shmem > objects. > > Signed-off-by: Thomas Zimmermann > --- Reviewed-by: Javier Martinez Canillas -- Best regards, Javier Martinez Canillas Core Platforms Red Hat
Re: [PATCH 2/6] drm: zynqmp_dp: Adjust training values per-lane
Hi Sean,
Thank you for the patch.
On Fri, Mar 15, 2024 at 07:09:12PM -0400, Sean Anderson wrote:
> The feedback we get from the DPRX is per-lane. Make changes using this
> information, instead of picking the maximum values from all lanes. This
> results in more-consistent training on marginal links.
>
> Signed-off-by: Sean Anderson
> ---
>
> drivers/gpu/drm/xlnx/zynqmp_dp.c | 23 ---
> 1 file changed, 8 insertions(+), 15 deletions(-)
>
> diff --git a/drivers/gpu/drm/xlnx/zynqmp_dp.c
> b/drivers/gpu/drm/xlnx/zynqmp_dp.c
> index 98a32e6a0459..8635b5673386 100644
> --- a/drivers/gpu/drm/xlnx/zynqmp_dp.c
> +++ b/drivers/gpu/drm/xlnx/zynqmp_dp.c
> @@ -605,28 +605,21 @@ static void zynqmp_dp_adjust_train(struct zynqmp_dp *dp,
> u8 link_status[DP_LINK_STATUS_SIZE])
> {
> u8 *train_set = dp->train_set;
> - u8 voltage = 0, preemphasis = 0;
> u8 i;
>
> for (i = 0; i < dp->mode.lane_cnt; i++) {
> - u8 v = drm_dp_get_adjust_request_voltage(link_status, i);
> - u8 p = drm_dp_get_adjust_request_pre_emphasis(link_status, i);
> + u8 voltage = drm_dp_get_adjust_request_voltage(link_status, i);
> + u8 preemphasis =
> + drm_dp_get_adjust_request_pre_emphasis(link_status, i);
>
> - if (v > voltage)
> - voltage = v;
> + if (voltage >= DP_TRAIN_VOLTAGE_SWING_LEVEL_3)
> + voltage |= DP_TRAIN_MAX_SWING_REACHED;
>
> - if (p > preemphasis)
> - preemphasis = p;
> - }
> + if (preemphasis >= DP_TRAIN_PRE_EMPH_LEVEL_2)
> + preemphasis |= DP_TRAIN_MAX_PRE_EMPHASIS_REACHED;
>
> - if (voltage >= DP_TRAIN_VOLTAGE_SWING_LEVEL_3)
> - voltage |= DP_TRAIN_MAX_SWING_REACHED;
> -
> - if (preemphasis >= DP_TRAIN_PRE_EMPH_LEVEL_2)
> - preemphasis |= DP_TRAIN_MAX_PRE_EMPHASIS_REACHED;
> -
> - for (i = 0; i < dp->mode.lane_cnt; i++)
> train_set[i] = voltage | preemphasis;
> + }
I don't have enough DP knowledge to review this :-(
> }
>
> /**
--
Regards,
Laurent Pinchart
Re: [PATCH 06/43] fbdev/deferred-io: Always call get_page() for framebuffer pages
Thomas Zimmermann writes: > Unconditionally call get_page() after looking up a page from the > framebuffer memory. Guarantees that we always hold a reference. > > This change also refactors the code such that it can support a > driver-supplied get_page helper. This will be useful for DRM's > fbdev emulation. > > Signed-off-by: Thomas Zimmermann > --- Reviewed-by: Javier Martinez Canillas -- Best regards, Javier Martinez Canillas Core Platforms Red Hat
Re: [PATCH 05/43] fbdev/deferred-io: Test smem_start for I/O memory
Thomas Zimmermann writes: > Test smem_start before looking up pages from its value. Return > NULL if it is unset. This will result in a SIGBUS signal. > > Signed-off-by: Thomas Zimmermann > --- Reviewed-by: Javier Martinez Canillas -- Best regards, Javier Martinez Canillas Core Platforms Red Hat
Re: [PATCH] drm: bridge: thc63lvd1024: Print error message when DT parsing fails
Hi,
On 2024/3/19 00:06, Laurent Pinchart wrote:
Commit 00084f0c01bf ("drm: bridge: thc63lvd1024: Switch to use
of_graph_get_remote_node()") simplified the thc63lvd1024 driver by
replacing hand-rolled code with a helper function.
[...]
While doing so, it
created an error code path at probe time without any error message,
If this is a reason or a concern, then every drm bridges drivers will suffer
from
such a concern. Right?
potentially causing probe issues that get annoying to debug.
Sorry, let's keep it fair enough, it creates nothing annoyed.
If there is a probe issues, then, it is caused by ill-behavioral DT.
*NOT* my patch. And should be found during review stage.
If the of_graph_get_remote_node() function is not good enough,
I suggest to improve the of_graph_get_remote_node() function,
then all callers of it will benefits.
Well, the strong word here just terrifying new programmers to call
core function helpers. Please use more *soft* description in the
commit message.
Fix it by
adding an error message.
Fixes: 00084f0c01bf ("drm: bridge: thc63lvd1024: Switch to use
of_graph_get_remote_node()")
Please drop the fixes tag at here, append the tag to a real bug-fix patch will
make more sense imo.
I suggest to improve the of_graph_get_remote_node() function, then all callers
of it will benefits.
NOT a single implement like this.
Signed-off-by: Laurent Pinchart
---
drivers/gpu/drm/bridge/thc63lvd1024.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/bridge/thc63lvd1024.c
b/drivers/gpu/drm/bridge/thc63lvd1024.c
index 5f99f9724081..674efc489e3a 100644
--- a/drivers/gpu/drm/bridge/thc63lvd1024.c
+++ b/drivers/gpu/drm/bridge/thc63lvd1024.c
@@ -125,8 +125,11 @@ static int thc63_parse_dt(struct thc63_dev *thc63)
remote = of_graph_get_remote_node(thc63->dev->of_node,
THC63_RGB_OUT0, -1);
- if (!remote)
+ if (!remote) {
+ dev_err(thc63->dev, "No remote endpoint for port@%u\n",
+ THC63_RGB_OUT0);
return -ENODEV;
+ }
thc63->next = of_drm_find_bridge(remote);
of_node_put(remote);
base-commit: 00084f0c01bf3a2591d007010b196e048281c455
--
Best regards,
Sui
Re: [PATCH 1/6] drm: zynqmp_dp: Downgrade log level for aux retries message
Hi Sean,
Thank you for the patch.
On Fri, Mar 15, 2024 at 07:09:11PM -0400, Sean Anderson wrote:
> Enable this message for verbose debugging only as it is otherwise
> printed after every AUX message, quickly filling the log buffer.
>
> Signed-off-by: Sean Anderson
> ---
>
> drivers/gpu/drm/xlnx/zynqmp_dp.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/xlnx/zynqmp_dp.c
> b/drivers/gpu/drm/xlnx/zynqmp_dp.c
> index a0606fab0e22..98a32e6a0459 100644
> --- a/drivers/gpu/drm/xlnx/zynqmp_dp.c
> +++ b/drivers/gpu/drm/xlnx/zynqmp_dp.c
> @@ -1006,7 +1006,7 @@ zynqmp_dp_aux_transfer(struct drm_dp_aux *aux, struct
> drm_dp_aux_msg *msg)
> msg->buffer, msg->size,
> &msg->reply);
> if (!ret) {
> - dev_dbg(dp->dev, "aux %d retries\n", i);
> + dev_vdbg(dp->dev, "aux %d retries\n", i);
I didn't know about dev_vdbg(). I suppose this makes sense,
Reviewed-by: Laurent Pinchart
> return msg->size;
> }
>
--
Regards,
Laurent Pinchart
Re: [PATCH v6 1/3] dt-bindings: display: add STM32 LVDS device
Hi Raphael,
thanks for the patch.
Acked-by: Yannick Fertre
Best regards
On 2/26/24 11:48, Raphael Gallais-Pou wrote:
Add "st,stm32mp25-lvds" compatible.
Signed-off-by: Raphael Gallais-Pou
Reviewed-by: Conor Dooley
---
Depends on: "dt-bindings: stm32: add clocks and reset binding for
stm32mp25 platform" by Gabriel Fernandez
Changes in v6:
- Added Conor's Reviewed-by
Changes in v5:
- Fixed path in MAINTAINERS
Changes in v4:
- Align filename to compatible
- Fix compatible in the example
- Remove redundant word in the subject
Changes in v3:
- Clarify commit dependency
- Fix includes in the example
- Fix YAML
- Add "clock-cells" description
- s/regroups/is composed of/
- Changed compatible to show SoC specificity
Changes in v2:
- Switch compatible and clock-cells related areas
- Remove faulty #include in the example.
- Add entry in MAINTAINERS
---
.../bindings/display/st,stm32mp25-lvds.yaml| 119 +
MAINTAINERS| 1 +
2 files changed, 120 insertions(+)
diff --git a/Documentation/devicetree/bindings/display/st,stm32mp25-lvds.yaml
b/Documentation/devicetree/bindings/display/st,stm32mp25-lvds.yaml
new file mode 100644
index ..6736f93256b5
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/st,stm32mp25-lvds.yaml
@@ -0,0 +1,119 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/display/st,stm32mp25-lvds.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: STMicroelectronics STM32 LVDS Display Interface Transmitter
+
+maintainers:
+ - Raphael Gallais-Pou
+ - Yannick Fertre
+
+description: |
+ The STMicroelectronics STM32 LVDS Display Interface Transmitter handles the
+ LVDS protocol: it maps the pixels received from the upstream Pixel-DMA (LTDC)
+ onto the LVDS PHY.
+
+ It is composed of three sub blocks:
+- LVDS host: handles the LVDS protocol (FPD / OpenLDI) and maps its input
+ pixels onto the data lanes of the PHY
+- LVDS PHY: parallelize the data and drives the LVDS data lanes
+- LVDS wrapper: handles top-level settings
+
+ The LVDS controller driver supports the following high-level features:
+- FDP-Link-I and OpenLDI (v0.95) protocols
+- Single-Link or Dual-Link operation
+- Single-Display or Double-Display (with the same content duplicated on
both)
+- Flexible Bit-Mapping, including JEIDA and VESA
+- RGB888 or RGB666 output
+- Synchronous design, with one input pixel per clock cycle
+
+properties:
+ compatible:
+const: st,stm32mp25-lvds
+
+ "#clock-cells":
+const: 0
+description:
+ Provides the internal LVDS PHY clock to the framework.
+
+ reg:
+maxItems: 1
+
+ clocks:
+items:
+ - description: APB peripheral clock
+ - description: Reference clock for the internal PLL
+
+ clock-names:
+items:
+ - const: pclk
+ - const: ref
+
+ resets:
+maxItems: 1
+
+ ports:
+$ref: /schemas/graph.yaml#/properties/ports
+
+properties:
+ port@0:
+$ref: /schemas/graph.yaml#/properties/port
+description:
+ LVDS input port node, connected to the LTDC RGB output port.
+
+ port@1:
+$ref: /schemas/graph.yaml#/properties/port
+description:
+ LVDS output port node, connected to a panel or bridge input port.
+
+required:
+ - port@0
+ - port@1
+
+required:
+ - compatible
+ - "#clock-cells"
+ - reg
+ - clocks
+ - clock-names
+ - resets
+ - ports
+
+additionalProperties: false
+
+examples:
+ - |
+#include
+#include
+
+lvds: lvds@4806 {
+compatible = "st,stm32mp25-lvds";
+reg = <0x4806 0x2000>;
+#clock-cells = <0>;
+clocks = <&rcc CK_BUS_LVDS>, <&rcc CK_KER_LVDSPHY>;
+clock-names = "pclk", "ref";
+resets = <&rcc LVDS_R>;
+
+ports {
+#address-cells = <1>;
+#size-cells = <0>;
+
+port@0 {
+reg = <0>;
+lvds_in: endpoint {
+ remote-endpoint = <;
+};
+};
+
+port@1 {
+reg = <1>;
+lvds_out0: endpoint {
+ remote-endpoint = <&lvds_panel_in>;
+};
+};
+};
+};
+
+...
diff --git a/MAINTAINERS b/MAINTAINERS
index 3527a2ece6cd..ff5c945f206e 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -7240,6 +7240,7 @@ L:dri-devel@lists.freedesktop.org
S:Maintained
T:git git://anongit.freedesktop.org/drm/drm-misc
F:Documentation/devicetree/bindings/display/st,stm32-ltdc.yaml
+F: Documentation/devicetree/bindings/display/st,stm32mp25-lvds.yaml
F:drivers/gpu/drm/stm
DRM DRIVERS FOR TI KEYSTONE
Re: [PATCH 1/2] dt-bindings: display: simple: Add POWERTIP PH128800T-006-ZHC01 panel
On 18/03/2024 17:17, Nathan Morrisson wrote: > Add POWERTIP PH128800T-006-ZHC01 10.1" LCD-TFT LVDS panel compatible > string. > > Signed-off-by: Nathan Morrisson > --- > .../devicetree/bindings/display/panel/panel-simple.yaml | 2 ++ > 1 file changed, 2 insertions(+) > Acked-by: Krzysztof Kozlowski Best regards, Krzysztof
Re: [PATCH] drm/Makefile: Move tiny drivers before native drivers
Hi
Am 18.03.24 um 16:42 schrieb Jaak Ristioja:
Hi Huacai,
Uh, no, sorry, I did not get to test such changes. From what Thomas
wrote I presumed that this got fixed and no further action would be
required.
Right. We reverted the problematic patch and the issue should be gone now.
Best regards
Thomas
To speed things up I would appreciate it if you provided a patch. As I
worked around the problem for the end user by changing the kernel
configuration, I have long forgotten the exact details. It would
otherwise probably take me a while to understand what and where you
propose to change exactly.
Also, do you want me to test it on some newer kernel or should I
re-download the 6.5.# version sources?
Best regards,
Jaak
On 18.03.24 16:43, Huacai Chen wrote:
Hi, Jaak,
I'm still here as a boring man. :)
Have you ever tested whether using "fs_initcall(sysfb_init)" works
fine on your machine?
Huacai
On Wed, Jan 24, 2024 at 5:21 AM Jaak Ristioja wrote:
Hi,
I apologize for not finding the time to test this earlier.
On 11.12.23 05:08, Huacai Chen wrote:
And Jaak, could you please test with the below patch (but keep the
original order in Makefile) and then give me the dmesg output?
diff --git a/drivers/video/aperture.c b/drivers/video/aperture.c
index 561be8feca96..cc2e39fb98f5 100644
--- a/drivers/video/aperture.c
+++ b/drivers/video/aperture.c
@@ -350,21 +350,29 @@ int
aperture_remove_conflicting_pci_devices(struct pci_dev *pdev, const
char *na
resource_size_t base, size;
int bar, ret = 0;
- if (pdev == vga_default_device())
+ printk("DEBUG: remove 1\n");
+
+ if (pdev == vga_default_device()) {
+ printk("DEBUG: primary = true\n");
primary = true;
+ }
- if (primary)
+ if (primary) {
+ printk("DEBUG: disable sysfb\n");
sysfb_disable();
+ }
for (bar = 0; bar < PCI_STD_NUM_BARS; ++bar) {
if (!(pci_resource_flags(pdev, bar) &
IORESOURCE_MEM))
continue;
+ printk("DEBUG: remove 2\n");
base = pci_resource_start(pdev, bar);
size = pci_resource_len(pdev, bar);
aperture_detach_devices(base, size);
}
+ printk("DEBUG: remove 3\n");
/*
* If this is the primary adapter, there could be a VGA
device
* that consumes the VGA framebuffer I/O range. Remove this
[1]
https://lore.kernel.org/lkml/170222766284.86103.11020060769330721...@leemhuis.info/T/#u
Copy-pasting this from the e-mail body didn't work well, but I applied
the changes manually to a 6.5.9 kernel without any of the other
patches.
Here's the relevant dmesg output on the Lenovo L570:
...
[ 2.953405] ACPI: bus type drm_connector registered
[ 2.954014] i915 :00:02.0: [drm] VT-d active for gfx access
[ 2.954018] DEBUG: remove 1
[ 2.954020] DEBUG: remove 2
[ 2.954021] DEBUG: remove 2
[ 2.954023] DEBUG: remove 3
[ 2.954029] resource: resource sanity check: requesting [mem
0xe000-0xefff], which spans more than BOOTFB
[mem 0xe000-0xe012bfff]
[ 2.954035] caller i915_ggtt_init_hw+0x88/0x120 mapping multiple
BARs
[ 2.954061] i915 :00:02.0: [drm] Using Transparent Hugepages
[ 2.955103] Loading firmware: i915/kbl_dmc_ver1_04.bin
[ 2.955384] i915 :00:02.0: [drm] Finished loading DMC firmware
i915/kbl_dmc_ver1_04.bin (v1.4)
...
[ 4.145013] [drm] Initialized i915 1.6.0 20201103 for
:00:02.0 on
minor 0
[ 4.147101] ACPI: video: Video Device [GFX0] (multi-head: yes rom:
no post: no)
[ 4.147244] input: Video Bus as
/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/LNXVIDEO:00/input/input4
[ 4.147410] [drm] Initialized vgem 1.0.0 20120112 for vgem on
minor 1
[ 4.147420] usbcore: registered new interface driver udl
[ 4.147500] [drm] Initialized simpledrm 1.0.0 20200625 for
simple-framebuffer.0 on minor 2
[ 4.148643] Console: switching to colour frame buffer device 80x30
[ 4.153216] simple-framebuffer simple-framebuffer.0: [drm] fb0:
simpledrmdrmfb frame buffer device
[ 4.154043] loop: module loaded
[ 4.156017] ahci :00:17.0: version 3.0
[ 4.157373] i915 :00:02.0: [drm] fb1: i915drmfb frame buffer
device
...
J
--
--
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Frankenstrasse 146, 90461 Nuernberg, Germany
GF: Ivo Totev, Andrew Myers, Andrew McDonald, Boudien Moerman
HRB 36809 (AG Nuernberg)
Re: [PATCH v2] drm/panthor: Fix the CONFIG_PM=n case
Il 18/03/24 16:31, Boris Brezillon ha scritto:
Putting a hard dependency on CONFIG_PM is not possible because of a
circular dependency issue, and it's actually not desirable either. In
order to support this use case, we forcibly resume at init time, and
suspend at unplug time.
v2:
- Drop the #ifdef CONFIG_PM section around panthor_pm_ops's definition
Reported-by: kernel test robot
Closes:
https://lore.kernel.org/oe-kbuild-all/202403031944.eoimq8wk-...@intel.com/
Signed-off-by: Boris Brezillon
Reviewed-by: AngeloGioacchino Del Regno
---
Tested by faking CONFIG_PM=n in the driver (basically commenting
all pm_runtime calls, and making the panthor_device_suspend/resume()
calls unconditional in the panthor_device_unplug/init() path) since
CONFIG_ARCH_ROCKCHIP selects CONFIG_PM. Seems to work fine, but I
can't be 100% sure this will work correctly on a platform that has
CONFIG_PM=n.
---
drivers/gpu/drm/panthor/panthor_device.c | 13 +++--
drivers/gpu/drm/panthor/panthor_drv.c| 2 +-
2 files changed, 12 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/panthor/panthor_device.c
b/drivers/gpu/drm/panthor/panthor_device.c
index 69deb8e17778..ba7aedbb4931 100644
--- a/drivers/gpu/drm/panthor/panthor_device.c
+++ b/drivers/gpu/drm/panthor/panthor_device.c
@@ -87,6 +87,10 @@ void panthor_device_unplug(struct panthor_device *ptdev)
pm_runtime_dont_use_autosuspend(ptdev->base.dev);
pm_runtime_put_sync_suspend(ptdev->base.dev);
+ /* If PM is disabled, we need to call the suspend handler manually. */
+ if (!IS_ENABLED(CONFIG_PM))
+ panthor_device_suspend(ptdev->base.dev);
+
/* Report the unplug operation as done to unblock concurrent
* panthor_device_unplug() callers.
*/
@@ -218,6 +222,13 @@ int panthor_device_init(struct panthor_device *ptdev)
if (ret)
return ret;
+ /* If PM is disabled, we need to call panthor_device_resume() manually. */
+ if (!IS_ENABLED(CONFIG_PM)) {
+ ret = panthor_device_resume(ptdev->base.dev);
+ if (ret)
+ return ret;
+ }
+
ret = panthor_gpu_init(ptdev);
if (ret)
goto err_rpm_put;
@@ -402,7 +413,6 @@ int panthor_device_mmap_io(struct panthor_device *ptdev,
struct vm_area_struct *
return 0;
}
-#ifdef CONFIG_PM
int panthor_device_resume(struct device *dev)
{
struct panthor_device *ptdev = dev_get_drvdata(dev);
@@ -547,4 +557,3 @@ int panthor_device_suspend(struct device *dev)
mutex_unlock(&ptdev->pm.mmio_lock);
return ret;
}
-#endif
diff --git a/drivers/gpu/drm/panthor/panthor_drv.c
b/drivers/gpu/drm/panthor/panthor_drv.c
index ff484506229f..11b3ccd58f85 100644
--- a/drivers/gpu/drm/panthor/panthor_drv.c
+++ b/drivers/gpu/drm/panthor/panthor_drv.c
@@ -1417,7 +1417,7 @@ static struct platform_driver panthor_driver = {
.remove_new = panthor_remove,
.driver = {
.name = "panthor",
- .pm = &panthor_pm_ops,
+ .pm = pm_ptr(&panthor_pm_ops),
.of_match_table = dt_match,
},
};
Re: [PATCH v9 20/27] drm/connector: hdmi: Add Infoframes generation
On Mon, Mar 18, 2024 at 02:49:47PM +0100, Maxime Ripard wrote:
> Hi,
>
> On Fri, Mar 15, 2024 at 10:22:05AM +0200, Ville Syrjälä wrote:
> > On Mon, Mar 11, 2024 at 03:49:48PM +0100, Maxime Ripard wrote:
> > > Infoframes in KMS is usually handled by a bunch of low-level helpers
> > > that require quite some boilerplate for drivers. This leads to
> > > discrepancies with how drivers generate them, and which are actually
> > > sent.
> > >
> > > Now that we have everything needed to generate them in the HDMI
> > > connector state, we can generate them in our common logic so that
> > > drivers can simply reuse what we precomputed.
> > >
> > > Signed-off-by: Maxime Ripard
> > > ---
> > > drivers/gpu/drm/Kconfig| 1 +
> > > drivers/gpu/drm/drm_atomic_state_helper.c | 323
> > > +
> > > drivers/gpu/drm/drm_connector.c| 14 +
> > > .../gpu/drm/tests/drm_atomic_state_helper_test.c | 1 +
> > > drivers/gpu/drm/tests/drm_connector_test.c | 12 +
> > > include/drm/drm_atomic_state_helper.h | 8 +
> > > include/drm/drm_connector.h| 133 +
> > > 7 files changed, 492 insertions(+)
> > >
> > > diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig
> > > index 872edb47bb53..ad9c467e20ce 100644
> > > --- a/drivers/gpu/drm/Kconfig
> > > +++ b/drivers/gpu/drm/Kconfig
> > > @@ -97,10 +97,11 @@ config DRM_KUNIT_TEST
> > > If in doubt, say "N".
> > >
> > > config DRM_KMS_HELPER
> > > tristate
> > > depends on DRM
> > > + select DRM_DISPLAY_HDMI_HELPER
> > > help
> > > CRTC helpers for KMS drivers.
> > >
> > > config DRM_DEBUG_DP_MST_TOPOLOGY_REFS
> > > bool "Enable refcount backtrace history in the DP MST helpers"
> > > diff --git a/drivers/gpu/drm/drm_atomic_state_helper.c
> > > b/drivers/gpu/drm/drm_atomic_state_helper.c
> > > index e66272c0d006..2bf53666fc9d 100644
> > > --- a/drivers/gpu/drm/drm_atomic_state_helper.c
> > > +++ b/drivers/gpu/drm/drm_atomic_state_helper.c
> > > @@ -36,10 +36,12 @@
> > > #include
> > > #include
> > > #include
> > > #include
> > >
> > > +#include
> > > +
> > > #include
> > > #include
> > >
> > > /**
> > > * DOC: atomic state reset and initialization
> > > @@ -912,10 +914,143 @@ hdmi_compute_config(const struct drm_connector
> > > *connector,
> > > }
> > >
> > > return -EINVAL;
> > > }
> > >
> > > +static int hdmi_generate_avi_infoframe(const struct drm_connector
> > > *connector,
> > > +struct drm_connector_state *state)
> > > +{
> > > + const struct drm_display_mode *mode =
> > > + connector_state_get_mode(state);
> > > + struct drm_connector_hdmi_infoframe *infoframe =
> > > + &state->hdmi.infoframes.avi;
> > > + struct hdmi_avi_infoframe *frame =
> > > + &infoframe->data.avi;
> > > + bool is_full_range = state->hdmi.is_full_range;
> > > + enum hdmi_quantization_range rgb_quant_range =
> > > + is_full_range ? HDMI_QUANTIZATION_RANGE_FULL :
> > > HDMI_QUANTIZATION_RANGE_LIMITED;
> > > + int ret;
> > > +
> > > + ret = drm_hdmi_avi_infoframe_from_display_mode(frame, connector, mode);
> > > + if (ret)
> > > + return ret;
> > > +
> > > + frame->colorspace = state->hdmi.output_format;
> > > +
> > > + drm_hdmi_avi_infoframe_quant_range(frame, connector, mode,
> > > rgb_quant_range);
> >
> > drm_hdmi_avi_infoframe_quant_range() doesn't handle YCbCr currently.
>
> I guess it's not really a problem anymore if we drop YUV422 selection,
> but I'll add a comment.
>
> > > + drm_hdmi_avi_infoframe_colorimetry(frame, state);
> > > + drm_hdmi_avi_infoframe_bars(frame, state);
> > > +
> > > + infoframe->set = true;
> > > +
> > > + return 0;
> > > +}
> > > +
> >
> > > +
> > > +#define UPDATE_INFOFRAME(c, os, ns, i) \
> > > + write_or_clear_infoframe(c, \
> > > + &(c)->hdmi.infoframes.i, \
> > > + &(os)->hdmi.infoframes.i, \
> > > + &(ns)->hdmi.infoframes.i)
> >
> > This macro feels like pointless obfuscation to me.
>
> I'll remove it then.
>
> >
> > > @@ -1984,20 +2063,73 @@ struct drm_connector {
> > >
> > > /**
> > >* @hdmi: HDMI-related variable and properties.
> > >*/
> > > struct {
> > > +#define DRM_CONNECTOR_HDMI_VENDOR_LEN8
> > > + /**
> > > + * @vendor: HDMI Controller Vendor Name
> > > + */
> > > + unsigned char vendor[DRM_CONNECTOR_HDMI_VENDOR_LEN] __nonstring;
> > > +
> > > +#define DRM_CONNECTOR_HDMI_PRODUCT_LEN 16
> > > + /**
> > > + * @product: HDMI Controller Product Name
> > > + */
> > > + unsigned char product[DRM_CONNECTOR_HDMI_PRODUCT_LEN]
> > > __nonstring;
> > > +
> > > /**
> > >* @supported_formats: Bitmask of @hdmi_colorspace
> > >* suppor
Re: [PATCH v6 2/3] drm/stm: lvds: add new STM32 LVDS Display Interface Transmitter driver
Hi Raphael, thanks for the patch. Acked-by: Yannick Fertre Best regards On 2/26/24 11:48, Raphael Gallais-Pou wrote: The Low-Voltage Differential Signaling (LVDS) Display Interface Transmitter handles the LVDS protocol: it maps the pixels received from the upstream Pixel-DMA LCD-TFT Display Controller (LTDC) onto the LVDS PHY. It is composed of three sub blocks: * LVDS host: handles the LVDS protocol (FPD / OpenLDI) and maps its input pixels onto the data lanes of the PHY * LVDS PHY: parallelize the data and drives the LVDS data lanes * LVDS wrapper: handles top-level settings The LVDS controller driver supports the following high-level features: * FDP-Link-I and OpenLDI (v0.95) protocols * Single-Link or Dual-Link operation * Single-Display or Double-Display (with the same content duplicated on both) * Flexible Bit-Mapping, including JEIDA and VESA * RGB888 or RGB666 output * Synchronous design, with one input pixel per clock cycle Signed-off-by: Raphael Gallais-Pou --- Changes in v6: - Fixes sparse symbols detected by kernel test robot Changes in v5: - Align compatible Changes in v4: - Explicitly include linux/platform_device.h, dependency introduced by ef175b29a242 of: Stop circularly including of_device.h and of_platform.h Changes in v3: - s/regroups/is composed of/ in commit log - Change the compatible to show SoC specificity Changes in v2: - Fixed Camel Case macros - Removed debug log --- drivers/gpu/drm/stm/Kconfig | 11 + drivers/gpu/drm/stm/Makefile |2 + drivers/gpu/drm/stm/lvds.c | 1226 ++ 3 files changed, 1239 insertions(+) diff --git a/drivers/gpu/drm/stm/Kconfig b/drivers/gpu/drm/stm/Kconfig index fa49cde43bb2..9627814d027c 100644 --- a/drivers/gpu/drm/stm/Kconfig +++ b/drivers/gpu/drm/stm/Kconfig @@ -20,3 +20,14 @@ config DRM_STM_DSI select DRM_DW_MIPI_DSI help Choose this option for MIPI DSI support on STMicroelectronics SoC. + +config DRM_STM_LVDS + tristate "STMicroelectronics LVDS Display Interface Transmitter DRM driver" + depends on DRM_STM + help + Enable support for LVDS encoders on STMicroelectronics SoC. + The STM LVDS is a bridge which serialize pixel stream onto + a LVDS protocol. + + To compile this driver as a module, choose M here: the module will be + called lvds. diff --git a/drivers/gpu/drm/stm/Makefile b/drivers/gpu/drm/stm/Makefile index 4df5caf01f35..ad740d6175a6 100644 --- a/drivers/gpu/drm/stm/Makefile +++ b/drivers/gpu/drm/stm/Makefile @@ -5,4 +5,6 @@ stm-drm-y := \ obj-$(CONFIG_DRM_STM_DSI) += dw_mipi_dsi-stm.o +obj-$(CONFIG_DRM_STM_LVDS) += lvds.o + obj-$(CONFIG_DRM_STM) += stm-drm.o diff --git a/drivers/gpu/drm/stm/lvds.c b/drivers/gpu/drm/stm/lvds.c new file mode 100644 index ..bfc8cb13fbc5 --- /dev/null +++ b/drivers/gpu/drm/stm/lvds.c @@ -0,0 +1,1226 @@ +// SPDX-License-Identifier: GPL-2.0-only +/* + * Copyright (C) 2023, STMicroelectronics - All Rights Reserved + * Author(s): Raphaël GALLAIS-POU for STMicroelectronics. + */ + +#include +#include +#include +#include +#include +#include +#include + +#include +#include +#include +#include +#include +#include +#include +#include +#include + +/* LVDS Host registers */ +#define LVDS_CR0x /* configuration register */ +#define LVDS_DMLCR00x0004 /* data mapping lsb configuration register 0 */ +#define LVDS_DMMCR00x0008 /* data mapping msb configuration register 0 */ +#define LVDS_DMLCR10x000C /* data mapping lsb configuration register 1 */ +#define LVDS_DMMCR10x0010 /* data mapping msb configuration register 1 */ +#define LVDS_DMLCR20x0014 /* data mapping lsb configuration register 2 */ +#define LVDS_DMMCR20x0018 /* data mapping msb configuration register 2 */ +#define LVDS_DMLCR30x001C /* data mapping lsb configuration register 3 */ +#define LVDS_DMMCR30x0020 /* data mapping msb configuration register 3 */ +#define LVDS_DMLCR40x0024 /* data mapping lsb configuration register 4 */ +#define LVDS_DMMCR40x0028 /* data mapping msb configuration register 4 */ +#define LVDS_CDL1CR0x002C /* channel distrib link 1 configuration register */ +#define LVDS_CDL2CR0x0030 /* channel distrib link 2 configuration register */ + +#define CDL1CR_DEFAULT 0x04321 /* Default value for CDL1CR */ +#define CDL2CR_DEFAULT 0x59876 /* Default value for CDL2CR */ + +#define LVDS_DMLCR(bit)(LVDS_DMLCR0 + 0x8 * (bit)) +#define LVDS_DMMCR(bit)(LVDS_DMMCR0 + 0x8 * (bit)) + +/* LVDS Wrapper registers */ +#define LVDS_WCLKCR0x11B0 /* Wrapper clock control register */ + +#define LVDS_HWCFGR0x1FF0 /* HW configuration register*/ +#define LVDS_VERR 0x1FF4 /* Version register */ +#define LVDS_
Re: [PATCH v2] drm/panthor: Fix the CONFIG_PM=n case
On 18/03/2024 15:31, Boris Brezillon wrote:
> Putting a hard dependency on CONFIG_PM is not possible because of a
> circular dependency issue, and it's actually not desirable either. In
> order to support this use case, we forcibly resume at init time, and
> suspend at unplug time.
>
> v2:
> - Drop the #ifdef CONFIG_PM section around panthor_pm_ops's definition
>
> Reported-by: kernel test robot
> Closes:
> https://lore.kernel.org/oe-kbuild-all/202403031944.eoimq8wk-...@intel.com/
> Signed-off-by: Boris Brezillon
Reviewed-by: Steven Price
(and compile tested this time!)
Thanks,
Steve
> ---
> Tested by faking CONFIG_PM=n in the driver (basically commenting
> all pm_runtime calls, and making the panthor_device_suspend/resume()
> calls unconditional in the panthor_device_unplug/init() path) since
> CONFIG_ARCH_ROCKCHIP selects CONFIG_PM. Seems to work fine, but I
> can't be 100% sure this will work correctly on a platform that has
> CONFIG_PM=n.
> ---
> drivers/gpu/drm/panthor/panthor_device.c | 13 +++--
> drivers/gpu/drm/panthor/panthor_drv.c| 2 +-
> 2 files changed, 12 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/panthor/panthor_device.c
> b/drivers/gpu/drm/panthor/panthor_device.c
> index 69deb8e17778..ba7aedbb4931 100644
> --- a/drivers/gpu/drm/panthor/panthor_device.c
> +++ b/drivers/gpu/drm/panthor/panthor_device.c
> @@ -87,6 +87,10 @@ void panthor_device_unplug(struct panthor_device *ptdev)
> pm_runtime_dont_use_autosuspend(ptdev->base.dev);
> pm_runtime_put_sync_suspend(ptdev->base.dev);
>
> + /* If PM is disabled, we need to call the suspend handler manually. */
> + if (!IS_ENABLED(CONFIG_PM))
> + panthor_device_suspend(ptdev->base.dev);
> +
> /* Report the unplug operation as done to unblock concurrent
>* panthor_device_unplug() callers.
>*/
> @@ -218,6 +222,13 @@ int panthor_device_init(struct panthor_device *ptdev)
> if (ret)
> return ret;
>
> + /* If PM is disabled, we need to call panthor_device_resume() manually.
> */
> + if (!IS_ENABLED(CONFIG_PM)) {
> + ret = panthor_device_resume(ptdev->base.dev);
> + if (ret)
> + return ret;
> + }
> +
> ret = panthor_gpu_init(ptdev);
> if (ret)
> goto err_rpm_put;
> @@ -402,7 +413,6 @@ int panthor_device_mmap_io(struct panthor_device *ptdev,
> struct vm_area_struct *
> return 0;
> }
>
> -#ifdef CONFIG_PM
> int panthor_device_resume(struct device *dev)
> {
> struct panthor_device *ptdev = dev_get_drvdata(dev);
> @@ -547,4 +557,3 @@ int panthor_device_suspend(struct device *dev)
> mutex_unlock(&ptdev->pm.mmio_lock);
> return ret;
> }
> -#endif
> diff --git a/drivers/gpu/drm/panthor/panthor_drv.c
> b/drivers/gpu/drm/panthor/panthor_drv.c
> index ff484506229f..11b3ccd58f85 100644
> --- a/drivers/gpu/drm/panthor/panthor_drv.c
> +++ b/drivers/gpu/drm/panthor/panthor_drv.c
> @@ -1417,7 +1417,7 @@ static struct platform_driver panthor_driver = {
> .remove_new = panthor_remove,
> .driver = {
> .name = "panthor",
> - .pm = &panthor_pm_ops,
> + .pm = pm_ptr(&panthor_pm_ops),
> .of_match_table = dt_match,
> },
> };
[PATCH] drm: bridge: thc63lvd1024: Print error message when DT parsing fails
Commit 00084f0c01bf ("drm: bridge: thc63lvd1024: Switch to use
of_graph_get_remote_node()") simplified the thc63lvd1024 driver by
replacing hand-rolled code with a helper function. While doing so, it
created an error code path at probe time without any error message,
potentially causing probe issues that get annoying to debug. Fix it by
adding an error message.
Fixes: 00084f0c01bf ("drm: bridge: thc63lvd1024: Switch to use
of_graph_get_remote_node()")
Signed-off-by: Laurent Pinchart
---
drivers/gpu/drm/bridge/thc63lvd1024.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/bridge/thc63lvd1024.c
b/drivers/gpu/drm/bridge/thc63lvd1024.c
index 5f99f9724081..674efc489e3a 100644
--- a/drivers/gpu/drm/bridge/thc63lvd1024.c
+++ b/drivers/gpu/drm/bridge/thc63lvd1024.c
@@ -125,8 +125,11 @@ static int thc63_parse_dt(struct thc63_dev *thc63)
remote = of_graph_get_remote_node(thc63->dev->of_node,
THC63_RGB_OUT0, -1);
- if (!remote)
+ if (!remote) {
+ dev_err(thc63->dev, "No remote endpoint for port@%u\n",
+ THC63_RGB_OUT0);
return -ENODEV;
+ }
thc63->next = of_drm_find_bridge(remote);
of_node_put(remote);
base-commit: 00084f0c01bf3a2591d007010b196e048281c455
--
Regards,
Laurent Pinchart
Re: [PATCH] drm: bridge: thc63lvd1024: Switch to use of_graph_get_remote_node()
Hi,
On 2024/3/18 23:57, Laurent Pinchart wrote:
On Mon, Mar 18, 2024 at 11:53:11PM +0800, Sui Jingfeng wrote:
On 2024/3/18 23:33, Laurent Pinchart wrote:
On Sun, Mar 17, 2024 at 01:28:00AM +0800, Sui Jingfeng wrote:
To reduce boilerplate, use of_graph_get_remote_node() helper instead of
the hand-rolling code.
Signed-off-by: Sui Jingfeng
---
drivers/gpu/drm/bridge/thc63lvd1024.c | 24 +++-
1 file changed, 3 insertions(+), 21 deletions(-)
diff --git a/drivers/gpu/drm/bridge/thc63lvd1024.c
b/drivers/gpu/drm/bridge/thc63lvd1024.c
index d4c1a601bbb5..5f99f9724081 100644
--- a/drivers/gpu/drm/bridge/thc63lvd1024.c
+++ b/drivers/gpu/drm/bridge/thc63lvd1024.c
@@ -123,28 +123,10 @@ static int thc63_parse_dt(struct thc63_dev *thc63)
struct device_node *endpoint;
struct device_node *remote;
- endpoint = of_graph_get_endpoint_by_regs(thc63->dev->of_node,
-THC63_RGB_OUT0, -1);
- if (!endpoint) {
- dev_err(thc63->dev, "Missing endpoint in port@%u\n",
- THC63_RGB_OUT0);
- return -ENODEV;
- }
-
- remote = of_graph_get_remote_port_parent(endpoint);
- of_node_put(endpoint);
- if (!remote) {
- dev_err(thc63->dev, "Endpoint in port@%u unconnected\n",
- THC63_RGB_OUT0);
+ remote = of_graph_get_remote_node(thc63->dev->of_node,
+ THC63_RGB_OUT0, -1);
+ if (!remote)
The old logic is equivalent to of_graph_get_remote_node(), but now the
driver will fail probing without an error message. That's not very nice
as it leads to difficult to debug problems. I would keep one dev_err()
here:
dev_err(thc63->dev, "No remote endpoint for port@%u\n",
THC63_RGB_OUT0);
As your patch has been merged already, would you like to post a
follow-up patch to fix this ?
Yes, this is indeed a difference. I will post a follow-up patch to fix this.
I'm actually build-testing a patch I already wrote :-) I'll post it in a
moment.
OK, then.
return -ENODEV;
- }
-
- if (!of_device_is_available(remote)) {
- dev_err(thc63->dev, "port@%u remote endpoint is disabled\n",
- THC63_RGB_OUT0);
- of_node_put(remote);
- return -ENODEV;
- }
thc63->next = of_drm_find_bridge(remote);
of_node_put(remote);
--
Best regards,
Sui
Re: [PATCH] drm: bridge: thc63lvd1024: Switch to use of_graph_get_remote_node()
On Mon, Mar 18, 2024 at 11:53:11PM +0800, Sui Jingfeng wrote:
> On 2024/3/18 23:33, Laurent Pinchart wrote:
> > On Sun, Mar 17, 2024 at 01:28:00AM +0800, Sui Jingfeng wrote:
> >> To reduce boilerplate, use of_graph_get_remote_node() helper instead of
> >> the hand-rolling code.
> >>
> >> Signed-off-by: Sui Jingfeng
> >> ---
> >> drivers/gpu/drm/bridge/thc63lvd1024.c | 24 +++-
> >> 1 file changed, 3 insertions(+), 21 deletions(-)
> >>
> >> diff --git a/drivers/gpu/drm/bridge/thc63lvd1024.c
> >> b/drivers/gpu/drm/bridge/thc63lvd1024.c
> >> index d4c1a601bbb5..5f99f9724081 100644
> >> --- a/drivers/gpu/drm/bridge/thc63lvd1024.c
> >> +++ b/drivers/gpu/drm/bridge/thc63lvd1024.c
> >> @@ -123,28 +123,10 @@ static int thc63_parse_dt(struct thc63_dev *thc63)
> >>struct device_node *endpoint;
> >>struct device_node *remote;
> >>
> >> - endpoint = of_graph_get_endpoint_by_regs(thc63->dev->of_node,
> >> - THC63_RGB_OUT0, -1);
> >> - if (!endpoint) {
> >> - dev_err(thc63->dev, "Missing endpoint in port@%u\n",
> >> - THC63_RGB_OUT0);
> >> - return -ENODEV;
> >> - }
> >> -
> >> - remote = of_graph_get_remote_port_parent(endpoint);
> >> - of_node_put(endpoint);
> >> - if (!remote) {
> >> - dev_err(thc63->dev, "Endpoint in port@%u unconnected\n",
> >> - THC63_RGB_OUT0);
> >> + remote = of_graph_get_remote_node(thc63->dev->of_node,
> >> +THC63_RGB_OUT0, -1);
> >> + if (!remote)
> > The old logic is equivalent to of_graph_get_remote_node(), but now the
> > driver will fail probing without an error message. That's not very nice
> > as it leads to difficult to debug problems. I would keep one dev_err()
> > here:
> >
> > dev_err(thc63->dev, "No remote endpoint for port@%u\n",
> > THC63_RGB_OUT0);
> >
> > As your patch has been merged already, would you like to post a
> > follow-up patch to fix this ?
>
> Yes, this is indeed a difference. I will post a follow-up patch to fix this.
I'm actually build-testing a patch I already wrote :-) I'll post it in a
moment.
> >>return -ENODEV;
> >> - }
> >> -
> >> - if (!of_device_is_available(remote)) {
> >> - dev_err(thc63->dev, "port@%u remote endpoint is disabled\n",
> >> - THC63_RGB_OUT0);
> >> - of_node_put(remote);
> >> - return -ENODEV;
> >> - }
> >>
> >>thc63->next = of_drm_find_bridge(remote);
> >>of_node_put(remote);
--
Regards,
Laurent Pinchart
Re: [PATCH] drm: bridge: thc63lvd1024: Switch to use of_graph_get_remote_node()
Hi,
On 2024/3/18 23:33, Laurent Pinchart wrote:
Hi Sui,
Thank you for the patch.
On Sun, Mar 17, 2024 at 01:28:00AM +0800, Sui Jingfeng wrote:
To reduce boilerplate, use of_graph_get_remote_node() helper instead of
the hand-rolling code.
Signed-off-by: Sui Jingfeng
---
drivers/gpu/drm/bridge/thc63lvd1024.c | 24 +++-
1 file changed, 3 insertions(+), 21 deletions(-)
diff --git a/drivers/gpu/drm/bridge/thc63lvd1024.c
b/drivers/gpu/drm/bridge/thc63lvd1024.c
index d4c1a601bbb5..5f99f9724081 100644
--- a/drivers/gpu/drm/bridge/thc63lvd1024.c
+++ b/drivers/gpu/drm/bridge/thc63lvd1024.c
@@ -123,28 +123,10 @@ static int thc63_parse_dt(struct thc63_dev *thc63)
struct device_node *endpoint;
struct device_node *remote;
- endpoint = of_graph_get_endpoint_by_regs(thc63->dev->of_node,
-THC63_RGB_OUT0, -1);
- if (!endpoint) {
- dev_err(thc63->dev, "Missing endpoint in port@%u\n",
- THC63_RGB_OUT0);
- return -ENODEV;
- }
-
- remote = of_graph_get_remote_port_parent(endpoint);
- of_node_put(endpoint);
- if (!remote) {
- dev_err(thc63->dev, "Endpoint in port@%u unconnected\n",
- THC63_RGB_OUT0);
+ remote = of_graph_get_remote_node(thc63->dev->of_node,
+ THC63_RGB_OUT0, -1);
+ if (!remote)
The old logic is equivalent to of_graph_get_remote_node(), but now the
driver will fail probing without an error message. That's not very nice
as it leads to difficult to debug problems. I would keep one dev_err()
here:
dev_err(thc63->dev, "No remote endpoint for port@%u\n",
THC63_RGB_OUT0);
As your patch has been merged already, would you like to post a
follow-up patch to fix this ?
Yes, this is indeed a difference. I will post a follow-up patch to fix this.
return -ENODEV;
- }
-
- if (!of_device_is_available(remote)) {
- dev_err(thc63->dev, "port@%u remote endpoint is disabled\n",
- THC63_RGB_OUT0);
- of_node_put(remote);
- return -ENODEV;
- }
thc63->next = of_drm_find_bridge(remote);
of_node_put(remote);
--
Best regards,
Sui
Re: [PATCH] drm/Makefile: Move tiny drivers before native drivers
Hi Huacai,
Uh, no, sorry, I did not get to test such changes. From what Thomas
wrote I presumed that this got fixed and no further action would be
required.
To speed things up I would appreciate it if you provided a patch. As I
worked around the problem for the end user by changing the kernel
configuration, I have long forgotten the exact details. It would
otherwise probably take me a while to understand what and where you
propose to change exactly.
Also, do you want me to test it on some newer kernel or should I
re-download the 6.5.# version sources?
Best regards,
Jaak
On 18.03.24 16:43, Huacai Chen wrote:
Hi, Jaak,
I'm still here as a boring man. :)
Have you ever tested whether using "fs_initcall(sysfb_init)" works
fine on your machine?
Huacai
On Wed, Jan 24, 2024 at 5:21 AM Jaak Ristioja wrote:
Hi,
I apologize for not finding the time to test this earlier.
On 11.12.23 05:08, Huacai Chen wrote:
And Jaak, could you please test with the below patch (but keep the
original order in Makefile) and then give me the dmesg output?
diff --git a/drivers/video/aperture.c b/drivers/video/aperture.c
index 561be8feca96..cc2e39fb98f5 100644
--- a/drivers/video/aperture.c
+++ b/drivers/video/aperture.c
@@ -350,21 +350,29 @@ int
aperture_remove_conflicting_pci_devices(struct pci_dev *pdev, const
char *na
resource_size_t base, size;
int bar, ret = 0;
- if (pdev == vga_default_device())
+ printk("DEBUG: remove 1\n");
+
+ if (pdev == vga_default_device()) {
+ printk("DEBUG: primary = true\n");
primary = true;
+ }
- if (primary)
+ if (primary) {
+ printk("DEBUG: disable sysfb\n");
sysfb_disable();
+ }
for (bar = 0; bar < PCI_STD_NUM_BARS; ++bar) {
if (!(pci_resource_flags(pdev, bar) & IORESOURCE_MEM))
continue;
+ printk("DEBUG: remove 2\n");
base = pci_resource_start(pdev, bar);
size = pci_resource_len(pdev, bar);
aperture_detach_devices(base, size);
}
+ printk("DEBUG: remove 3\n");
/*
* If this is the primary adapter, there could be a VGA device
* that consumes the VGA framebuffer I/O range. Remove this
[1]
https://lore.kernel.org/lkml/170222766284.86103.11020060769330721...@leemhuis.info/T/#u
Copy-pasting this from the e-mail body didn't work well, but I applied
the changes manually to a 6.5.9 kernel without any of the other patches.
Here's the relevant dmesg output on the Lenovo L570:
...
[2.953405] ACPI: bus type drm_connector registered
[2.954014] i915 :00:02.0: [drm] VT-d active for gfx access
[2.954018] DEBUG: remove 1
[2.954020] DEBUG: remove 2
[2.954021] DEBUG: remove 2
[2.954023] DEBUG: remove 3
[2.954029] resource: resource sanity check: requesting [mem
0xe000-0xefff], which spans more than BOOTFB
[mem 0xe000-0xe012bfff]
[2.954035] caller i915_ggtt_init_hw+0x88/0x120 mapping multiple BARs
[2.954061] i915 :00:02.0: [drm] Using Transparent Hugepages
[2.955103] Loading firmware: i915/kbl_dmc_ver1_04.bin
[2.955384] i915 :00:02.0: [drm] Finished loading DMC firmware
i915/kbl_dmc_ver1_04.bin (v1.4)
...
[4.145013] [drm] Initialized i915 1.6.0 20201103 for :00:02.0 on
minor 0
[4.147101] ACPI: video: Video Device [GFX0] (multi-head: yes rom:
no post: no)
[4.147244] input: Video Bus as
/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/LNXVIDEO:00/input/input4
[4.147410] [drm] Initialized vgem 1.0.0 20120112 for vgem on minor 1
[4.147420] usbcore: registered new interface driver udl
[4.147500] [drm] Initialized simpledrm 1.0.0 20200625 for
simple-framebuffer.0 on minor 2
[4.148643] Console: switching to colour frame buffer device 80x30
[4.153216] simple-framebuffer simple-framebuffer.0: [drm] fb0:
simpledrmdrmfb frame buffer device
[4.154043] loop: module loaded
[4.156017] ahci :00:17.0: version 3.0
[4.157373] i915 :00:02.0: [drm] fb1: i915drmfb frame buffer device
...
J
Re: [PATCH] drm: bridge: thc63lvd1024: Switch to use of_graph_get_remote_node()
Hi Sui,
Thank you for the patch.
On Sun, Mar 17, 2024 at 01:28:00AM +0800, Sui Jingfeng wrote:
> To reduce boilerplate, use of_graph_get_remote_node() helper instead of
> the hand-rolling code.
>
> Signed-off-by: Sui Jingfeng
> ---
> drivers/gpu/drm/bridge/thc63lvd1024.c | 24 +++-
> 1 file changed, 3 insertions(+), 21 deletions(-)
>
> diff --git a/drivers/gpu/drm/bridge/thc63lvd1024.c
> b/drivers/gpu/drm/bridge/thc63lvd1024.c
> index d4c1a601bbb5..5f99f9724081 100644
> --- a/drivers/gpu/drm/bridge/thc63lvd1024.c
> +++ b/drivers/gpu/drm/bridge/thc63lvd1024.c
> @@ -123,28 +123,10 @@ static int thc63_parse_dt(struct thc63_dev *thc63)
> struct device_node *endpoint;
> struct device_node *remote;
>
> - endpoint = of_graph_get_endpoint_by_regs(thc63->dev->of_node,
> - THC63_RGB_OUT0, -1);
> - if (!endpoint) {
> - dev_err(thc63->dev, "Missing endpoint in port@%u\n",
> - THC63_RGB_OUT0);
> - return -ENODEV;
> - }
> -
> - remote = of_graph_get_remote_port_parent(endpoint);
> - of_node_put(endpoint);
> - if (!remote) {
> - dev_err(thc63->dev, "Endpoint in port@%u unconnected\n",
> - THC63_RGB_OUT0);
> + remote = of_graph_get_remote_node(thc63->dev->of_node,
> + THC63_RGB_OUT0, -1);
> + if (!remote)
The old logic is equivalent to of_graph_get_remote_node(), but now the
driver will fail probing without an error message. That's not very nice
as it leads to difficult to debug problems. I would keep one dev_err()
here:
dev_err(thc63->dev, "No remote endpoint for port@%u\n",
THC63_RGB_OUT0);
As your patch has been merged already, would you like to post a
follow-up patch to fix this ?
> return -ENODEV;
> - }
> -
> - if (!of_device_is_available(remote)) {
> - dev_err(thc63->dev, "port@%u remote endpoint is disabled\n",
> - THC63_RGB_OUT0);
> - of_node_put(remote);
> - return -ENODEV;
> - }
>
> thc63->next = of_drm_find_bridge(remote);
> of_node_put(remote);
--
Regards,
Laurent Pinchart
Re: [PATCH v4] Fix divide-by-zero regression on DP MST unplug with nouveau
On Sat, Mar 16, 2024 at 12:05:59PM +, Chris Bainbridge wrote: > Fix a regression when using nouveau and unplugging a StarTech MSTDP122DP > DisplayPort 1.2 MST hub (the same regression does not appear when using > a Cable Matters DisplayPort 1.4 MST hub). Trace: Thanks for the report and fix, pushed the patch to drm-misc-fixes. In the future, please add the appropriate 'drm:' prefix to the commit subject, I added this now while applying the patch. > > divide error: [#1] PREEMPT SMP PTI > CPU: 7 PID: 2962 Comm: Xorg Not tainted 6.8.0-rc3+ #744 > Hardware name: Razer Blade/DANA_MB, BIOS 01.01 08/31/2018 > RIP: 0010:drm_dp_bw_overhead+0xb4/0x110 [drm_display_helper] > Code: c6 b8 01 00 00 00 75 61 01 c6 41 0f af f3 41 0f af f1 c1 e1 04 48 63 > c7 31 d2 89 ff 48 8b 5d f8 c9 48 0f af f1 48 8d 44 06 ff <48> f7 f7 31 d2 31 > c9 31 f6 31 ff 45 31 c0 45 31 c9 45 31 d2 45 31 > RSP: 0018:b2c5c211fa30 EFLAGS: 00010206 > RAX: RBX: RCX: 00f59b00 > RDX: RSI: RDI: > RBP: b2c5c211fa48 R08: 0001 R09: 0020 > R10: 0004 R11: R12: 00023b4a > R13: 91d37d165800 R14: 91d36fac6d80 R15: 91d34a764010 > FS: 7f4a1ca3fa80() GS:91d6edbc() knlGS: > CS: 0010 DS: ES: CR0: 80050033 > CR2: 559491d49000 CR3: 00011d180002 CR4: 003706f0 > Call Trace: > > ? show_regs+0x6d/0x80 > ? die+0x37/0xa0 > ? do_trap+0xd4/0xf0 > ? do_error_trap+0x71/0xb0 > ? drm_dp_bw_overhead+0xb4/0x110 [drm_display_helper] > ? exc_divide_error+0x3a/0x70 > ? drm_dp_bw_overhead+0xb4/0x110 [drm_display_helper] > ? asm_exc_divide_error+0x1b/0x20 > ? drm_dp_bw_overhead+0xb4/0x110 [drm_display_helper] > ? drm_dp_calc_pbn_mode+0x2e/0x70 [drm_display_helper] > nv50_msto_atomic_check+0xda/0x120 [nouveau] > drm_atomic_helper_check_modeset+0xa87/0xdf0 [drm_kms_helper] > drm_atomic_helper_check+0x19/0xa0 [drm_kms_helper] > nv50_disp_atomic_check+0x13f/0x2f0 [nouveau] > drm_atomic_check_only+0x668/0xb20 [drm] > ? drm_connector_list_iter_next+0x86/0xc0 [drm] > drm_atomic_commit+0x58/0xd0 [drm] > ? __pfx___drm_printfn_info+0x10/0x10 [drm] > drm_atomic_connector_commit_dpms+0xd7/0x100 [drm] > drm_mode_obj_set_property_ioctl+0x1c5/0x450 [drm] > ? __pfx_drm_connector_property_set_ioctl+0x10/0x10 [drm] > drm_connector_property_set_ioctl+0x3b/0x60 [drm] > drm_ioctl_kernel+0xb9/0x120 [drm] > drm_ioctl+0x2d0/0x550 [drm] > ? __pfx_drm_connector_property_set_ioctl+0x10/0x10 [drm] > nouveau_drm_ioctl+0x61/0xc0 [nouveau] > __x64_sys_ioctl+0xa0/0xf0 > do_syscall_64+0x76/0x140 > ? do_syscall_64+0x85/0x140 > ? do_syscall_64+0x85/0x140 > entry_SYSCALL_64_after_hwframe+0x6e/0x76 > RIP: 0033:0x7f4a1cd1a94f > Code: 00 48 89 44 24 18 31 c0 48 8d 44 24 60 c7 04 24 10 00 00 00 48 89 44 > 24 08 48 8d 44 24 20 48 89 44 24 10 b8 10 00 00 00 0f 05 <41> 89 c0 3d 00 f0 > ff ff 77 1f 48 8b 44 24 18 64 48 2b 04 25 28 00 > RSP: 002b:7ffd2f1df520 EFLAGS: 0246 ORIG_RAX: 0010 > RAX: ffda RBX: 7ffd2f1df5b0 RCX: 7f4a1cd1a94f > RDX: 7ffd2f1df5b0 RSI: c01064ab RDI: 000f > RBP: c01064ab R08: 56347932deb8 R09: 56347a7d99c0 > R10: R11: 0246 R12: 56347938a220 > R13: 000f R14: 563479d9f3f0 R15: > > Modules linked in: rfcomm xt_conntrack nft_chain_nat xt_MASQUERADE nf_nat > nf_conntrack_netlink nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 xfrm_user > xfrm_algo xt_addrtype nft_compat nf_tables nfnetlink br_netfilter bridge stp > llc ccm cmac algif_hash overlay algif_skcipher af_alg bnep binfmt_misc > snd_sof_pci_intel_cnl snd_sof_intel_hda_common snd_soc_hdac_hda snd_sof_pci > snd_sof_xtensa_dsp snd_sof_intel_hda snd_sof snd_sof_utils > snd_soc_acpi_intel_match snd_soc_acpi snd_soc_core snd_compress > snd_sof_intel_hda_mlink snd_hda_ext_core iwlmvm intel_rapl_msr > intel_rapl_common intel_tcc_cooling x86_pkg_temp_thermal intel_powerclamp > mac80211 coretemp kvm_intel snd_hda_codec_hdmi kvm snd_hda_codec_realtek > snd_hda_codec_generic uvcvideo libarc4 snd_hda_intel snd_intel_dspcfg > snd_hda_codec iwlwifi videobuf2_vmalloc videobuf2_memops uvc irqbypass btusb > videobuf2_v4l2 snd_seq_midi crct10dif_pclmul hid_multitouch crc32_pclmul > snd_seq_midi_event btrtl snd_hwdep videodev polyval_clmulni polyval_generic > snd_rawmidi > ghash_clmulni_intel aesni_intel btintel crypto_simd snd_hda_core cryptd > snd_seq btbcm ee1004 8250_dw videobuf2_common btmtk rapl nls_iso8859_1 > mei_hdcp thunderbolt bluetooth intel_cstate wmi_bmof intel_wmi_thunderbolt > cfg80211 snd_pcm mc snd_seq_device i2c_i801 r8169 ecdh_generic snd_timer > i2c_smbus ecc snd mei_me intel_lpss_pci mei ahci intel_lpss soundcore realtek > libahci idma64 intel_pch
[PATCH v2] drm/panthor: Fix the CONFIG_PM=n case
Putting a hard dependency on CONFIG_PM is not possible because of a
circular dependency issue, and it's actually not desirable either. In
order to support this use case, we forcibly resume at init time, and
suspend at unplug time.
v2:
- Drop the #ifdef CONFIG_PM section around panthor_pm_ops's definition
Reported-by: kernel test robot
Closes:
https://lore.kernel.org/oe-kbuild-all/202403031944.eoimq8wk-...@intel.com/
Signed-off-by: Boris Brezillon
---
Tested by faking CONFIG_PM=n in the driver (basically commenting
all pm_runtime calls, and making the panthor_device_suspend/resume()
calls unconditional in the panthor_device_unplug/init() path) since
CONFIG_ARCH_ROCKCHIP selects CONFIG_PM. Seems to work fine, but I
can't be 100% sure this will work correctly on a platform that has
CONFIG_PM=n.
---
drivers/gpu/drm/panthor/panthor_device.c | 13 +++--
drivers/gpu/drm/panthor/panthor_drv.c| 2 +-
2 files changed, 12 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/panthor/panthor_device.c
b/drivers/gpu/drm/panthor/panthor_device.c
index 69deb8e17778..ba7aedbb4931 100644
--- a/drivers/gpu/drm/panthor/panthor_device.c
+++ b/drivers/gpu/drm/panthor/panthor_device.c
@@ -87,6 +87,10 @@ void panthor_device_unplug(struct panthor_device *ptdev)
pm_runtime_dont_use_autosuspend(ptdev->base.dev);
pm_runtime_put_sync_suspend(ptdev->base.dev);
+ /* If PM is disabled, we need to call the suspend handler manually. */
+ if (!IS_ENABLED(CONFIG_PM))
+ panthor_device_suspend(ptdev->base.dev);
+
/* Report the unplug operation as done to unblock concurrent
* panthor_device_unplug() callers.
*/
@@ -218,6 +222,13 @@ int panthor_device_init(struct panthor_device *ptdev)
if (ret)
return ret;
+ /* If PM is disabled, we need to call panthor_device_resume() manually.
*/
+ if (!IS_ENABLED(CONFIG_PM)) {
+ ret = panthor_device_resume(ptdev->base.dev);
+ if (ret)
+ return ret;
+ }
+
ret = panthor_gpu_init(ptdev);
if (ret)
goto err_rpm_put;
@@ -402,7 +413,6 @@ int panthor_device_mmap_io(struct panthor_device *ptdev,
struct vm_area_struct *
return 0;
}
-#ifdef CONFIG_PM
int panthor_device_resume(struct device *dev)
{
struct panthor_device *ptdev = dev_get_drvdata(dev);
@@ -547,4 +557,3 @@ int panthor_device_suspend(struct device *dev)
mutex_unlock(&ptdev->pm.mmio_lock);
return ret;
}
-#endif
diff --git a/drivers/gpu/drm/panthor/panthor_drv.c
b/drivers/gpu/drm/panthor/panthor_drv.c
index ff484506229f..11b3ccd58f85 100644
--- a/drivers/gpu/drm/panthor/panthor_drv.c
+++ b/drivers/gpu/drm/panthor/panthor_drv.c
@@ -1417,7 +1417,7 @@ static struct platform_driver panthor_driver = {
.remove_new = panthor_remove,
.driver = {
.name = "panthor",
- .pm = &panthor_pm_ops,
+ .pm = pm_ptr(&panthor_pm_ops),
.of_match_table = dt_match,
},
};
--
2.43.0
Re: [PATCH 2/5] drm/gem: Add a mountpoint parameter to drm_gem_object_init()
On 18/03/2024 15:05, Christian König wrote:
Am 18.03.24 um 15:24 schrieb Maíra Canal:
Not that the CC list wasn't big enough, but I'm adding MM folks
in the CC list.
On 3/18/24 11:04, Christian König wrote:
Am 18.03.24 um 14:28 schrieb Maíra Canal:
Hi Christian,
On 3/18/24 10:10, Christian König wrote:
Am 18.03.24 um 13:42 schrieb Maíra Canal:
Hi Christian,
On 3/12/24 10:48, Christian König wrote:
Am 12.03.24 um 14:09 schrieb Tvrtko Ursulin:
On 12/03/2024 10:37, Christian König wrote:
Am 12.03.24 um 11:31 schrieb Tvrtko Ursulin:
On 12/03/2024 10:23, Christian König wrote:
Am 12.03.24 um 10:30 schrieb Tvrtko Ursulin:
On 12/03/2024 08:59, Christian König wrote:
Am 12.03.24 um 09:51 schrieb Tvrtko Ursulin:
Hi Maira,
On 11/03/2024 10:05, Maíra Canal wrote:
For some applications, such as using huge pages, we might
want to have a
different mountpoint, for which we pass in mount flags
that better match
our usecase.
Therefore, add a new parameter to drm_gem_object_init()
that allow us to
define the tmpfs mountpoint where the GEM object will be
created. If
this parameter is NULL, then we fallback to
shmem_file_setup().
One strategy for reducing churn, and so the number of
drivers this patch touches, could be to add a lower level
drm_gem_object_init() (which takes vfsmount, call it
__drm_gem_object_init(), or drm__gem_object_init_mnt(),
and make drm_gem_object_init() call that one with a NULL
argument.
I would even go a step further into the other direction.
The shmem backed GEM object is just some special handling
as far as I can see.
So I would rather suggest to rename all drm_gem_* function
which only deal with the shmem backed GEM object into
drm_gem_shmem_*.
That makes sense although it would be very churny. I at
least would be on the fence regarding the cost vs benefit.
Yeah, it should clearly not be part of this patch here.
Also the explanation why a different mount point helps with
something isn't very satisfying.
Not satisfying as you think it is not detailed enough to say
driver wants to use huge pages for performance? Or not
satisying as you question why huge pages would help?
That huge pages are beneficial is clear to me, but I'm
missing the connection why a different mount point helps with
using huge pages.
Ah right, same as in i915, one needs to mount a tmpfs instance
passing huge=within_size or huge=always option. Default is
'never', see man 5 tmpfs.
Thanks for the explanation, I wasn't aware of that.
Mhm, shouldn't we always use huge pages? Is there a reason for
a DRM device to not use huge pages with the shmem backend?
AFAIU, according to b901bb89324a ("drm/i915/gemfs: enable THP"),
back then the understanding was within_size may overallocate,
meaning there would be some space wastage, until the memory
pressure makes the thp code split the trailing huge page. I
haven't checked if that still applies.
Other than that I don't know if some drivers/platforms could
have problems if they have some limitations or hardcoded
assumptions when they iterate the sg list.
Yeah, that was the whole point behind my question. As far as I
can see this isn't driver specific, but platform specific.
I might be wrong here, but I think we should then probably not
have that handling in each individual driver, but rather
centralized in the DRM code.
I don't see a point in enabling THP for all shmem drivers. A huge
page
is only useful if the driver is going to use it. On V3D, for example,
I only need huge pages because I need the memory contiguously
allocated
to implement Super Pages. Otherwise, if we don't have the Super Pages
support implemented in the driver, I would be creating memory
pressure
without any performance gain.
Well that's the point I'm disagreeing with. THP doesn't seem to
create much extra memory pressure for this use case.
As far as I can see background for the option is that files in
tmpfs usually have a varying size, so it usually isn't beneficial
to allocate a huge page just to find that the shmem file is much
smaller than what's needed.
But GEM objects have a fixed size. So we of hand knew if we need
4KiB or 1GiB and can therefore directly allocate huge pages if they
are available and object large enough to back them with.
If the memory pressure is so high that we don't have huge pages
available the shmem code falls back to standard pages anyway.
The matter is: how do we define the point where the memory pressure
is high?
Well as driver developers/maintainers we simply don't do that. This
is the job of the shmem code.
For example, notice that in this implementation of Super Pages
for the V3D driver, I only use a Super Page if the BO is bigger than
2MB. I'm doing that because the Raspberry Pi only has 4GB of RAM
available for the GPU. If I created huge pages for every BO
allocation (and initially, I tried that), I would end up with hangs
in some applications.
Yeah, that is what I
Re: [PATCH] drm/panthor: Don't use virt_to_pfn()
On Mon, 18 Mar 2024 15:11:42 +
Robin Murphy wrote:
> On 18/03/2024 2:51 pm, Steven Price wrote:
> > virt_to_pfn() isn't available on x86 (except to xen) so breaks
> > COMPILE_TEST builds. Avoid its use completely by instead storing the
> > struct page pointer allocated in panthor_device_init() and using
> > page_to_pfn() instead.
> >
> > Signed-off-by: Steven Price
> > ---
> > drivers/gpu/drm/panthor/panthor_device.c | 10 ++
> > drivers/gpu/drm/panthor/panthor_device.h | 2 +-
> > 2 files changed, 7 insertions(+), 5 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/panthor/panthor_device.c
> > b/drivers/gpu/drm/panthor/panthor_device.c
> > index 69deb8e17778..3c30da03fa48 100644
> > --- a/drivers/gpu/drm/panthor/panthor_device.c
> > +++ b/drivers/gpu/drm/panthor/panthor_device.c
> > @@ -154,6 +154,7 @@ int panthor_device_init(struct panthor_device *ptdev)
> > {
> > struct resource *res;
> > struct page *p;
> > + u32 *dummy_page_virt;
> > int ret;
> >
> > ptdev->coherent = device_get_dma_attr(ptdev->base.dev) ==
> > DEV_DMA_COHERENT;
> > @@ -172,9 +173,10 @@ int panthor_device_init(struct panthor_device *ptdev)
> > if (!p)
> > return -ENOMEM;
> >
> > - ptdev->pm.dummy_latest_flush = page_address(p);
> > + ptdev->pm.dummy_latest_flush = p;
> > + dummy_page_virt = page_address(p);
> > ret = drmm_add_action_or_reset(&ptdev->base, panthor_device_free_page,
> > - ptdev->pm.dummy_latest_flush);
> > + dummy_page_virt);
>
> Nit: I was about to say I'd be inclined to switch the callback to
> __free_page() instead, but then I realise there's no real need to be
> reinventing that in the first place:
>
> dummy_page_virt = (void *)devm_get_free_pages(ptdev->base.dev,
> GFP_KERNEL | GFP_ZERO, 0);
IIRC, the drm_device object might outlive the device it's been created
from if a process holds on the DRM dev FD after an unplug happened,
which can happen if panthor_device_unplug() is called from the reset
path (when a reset fails).
> if (!dummy_page_virt)
> return -ENOMEM;
>
> ptdev->pm.dummy_latest_flush = virt_to_page(dummy_page_virt);
>
> Cheers,
> Robin.
>
> > if (ret)
> > return ret;
> >
> > @@ -184,7 +186,7 @@ int panthor_device_init(struct panthor_device *ptdev)
> > * happens while the dummy page is mapped. Zero cannot be used because
> > * that means 'always flush'.
> > */
> > - *ptdev->pm.dummy_latest_flush = 1;
> > + *dummy_page_virt = 1;
> >
> > INIT_WORK(&ptdev->reset.work, panthor_device_reset_work);
> > ptdev->reset.wq = alloc_ordered_workqueue("panthor-reset-wq", 0);
> > @@ -353,7 +355,7 @@ static vm_fault_t panthor_mmio_vm_fault(struct vm_fault
> > *vmf)
> > if (active)
> > pfn = __phys_to_pfn(ptdev->phys_addr +
> > CSF_GPU_LATEST_FLUSH_ID);
> > else
> > - pfn = virt_to_pfn(ptdev->pm.dummy_latest_flush);
> > + pfn = page_to_pfn(ptdev->pm.dummy_latest_flush);
> > break;
> >
> > default:
> > diff --git a/drivers/gpu/drm/panthor/panthor_device.h
> > b/drivers/gpu/drm/panthor/panthor_device.h
> > index 51c9d61b6796..c84c27dcc92c 100644
> > --- a/drivers/gpu/drm/panthor/panthor_device.h
> > +++ b/drivers/gpu/drm/panthor/panthor_device.h
> > @@ -160,7 +160,7 @@ struct panthor_device {
> > * Used to replace the real LATEST_FLUSH page when the GPU
> > * is suspended.
> > */
> > - u32 *dummy_latest_flush;
> > + struct page *dummy_latest_flush;
> > } pm;
> > };
> >
Re: [PATCH] drm/bridge: Select DRM_KMS_HELPER for DRM_PANEL_BRIDGE
On Mon, 18 Mar 2024, "Luca Weiss" wrote: > Would you know the correct fix for this? I'm aware of the pattern > "select FOO || !FOO" but I guess it's also not applicable here? I don't think that pattern works for select, only for depends on. And I think the problem, again, is the abuse of select for symbols with dependencies. $ git grep "select DRM_KMS_HELPER" | wc -l 122 I'm guessing these only work because a) they are tristates, and b) they directly or indirectly already "depends on DRM", which satisfies DRM_KMS_HELPER's "depends on DRM". I think the correct fix for this, and a plethora of other kconfig problems, is adhering to the note in Documentation/kbuild/kconfig-language.rst: Note: select should be used with care. select will force a symbol to a value without visiting the dependencies. By abusing select you are able to select a symbol FOO even if FOO depends on BAR that is not set. In general use select only for non-visible symbols (no prompts anywhere) and for symbols with no dependencies. That will limit the usefulness but on the other hand avoid the illegal configurations all over. The downsides are that it's a lot of churn to fix them, they'll creep back in, and kconfig doesn't warn about these cases up front while it could, and menuconfig etc. aren't helpful in enabling dependencies for you recursively. So here we are, adding bandaid year after year. :( BR, Jani. -- Jani Nikula, Intel
Re: [PATCH] drm: bridge: thc63lvd1024: Switch to use of_graph_get_remote_node()
Hi, On Sun, 17 Mar 2024 01:28:00 +0800, Sui Jingfeng wrote: > To reduce boilerplate, use of_graph_get_remote_node() helper instead of > the hand-rolling code. > > Thanks, Applied to https://gitlab.freedesktop.org/drm/misc/kernel.git (drm-misc-next) [1/1] drm: bridge: thc63lvd1024: Switch to use of_graph_get_remote_node() https://gitlab.freedesktop.org/drm/misc/kernel/-/commit/00084f0c01bf3a2591d007010b196e048281c455 -- Neil
Re: [PATCH] drm: bridge: dw_hdmi: Switch to of_graph_get_remote_node()
Hi, On Sun, 17 Mar 2024 01:05:13 +0800, Sui Jingfeng wrote: > To reduce boilerplate, use of_graph_get_remote_node() helper instead of > the hand-rolling code. > > Thanks, Applied to https://gitlab.freedesktop.org/drm/misc/kernel.git (drm-misc-next) [1/1] drm: bridge: dw_hdmi: Switch to of_graph_get_remote_node() https://gitlab.freedesktop.org/drm/misc/kernel/-/commit/d576e5e235c9df1cdfe62db958b77c0b0023d08c -- Neil
Re: [PATCH] drm/bridge: it66121: Remove a duplicated invoke of of_device_is_available()
Hi, On Sun, 17 Mar 2024 01:44:19 +0800, Sui Jingfeng wrote: > The calling of of_device_is_available() in it66121_probe() is duplicated, > as the of_graph_get_remote_node() has already do the check for us. There > is no need to call it again, thus delete the later one. > > Thanks, Applied to https://gitlab.freedesktop.org/drm/misc/kernel.git (drm-misc-next) [1/1] drm/bridge: it66121: Remove a duplicated invoke of of_device_is_available() https://gitlab.freedesktop.org/drm/misc/kernel/-/commit/2c7d26555845ca5fb70353b4b77d8f6c4e32e54c -- Neil
Re: [PATCH] drm/bridge: ite66121: Register HPD interrupt handler only when 'client->irq > 0'
Hi, On Sun, 17 Mar 2024 00:05:36 +0800, Sui Jingfeng wrote: > If a specific design doesn't wire IT66121's interrupt signal output pin up > to the display controller side, then we should not register the interrupt > handler. Such a decision is valid usage, as we can fall back to polling > mode. So, don't make the assumption that a specific board always supports > HPD. Carry out a sanity check on 'client->irq' before using it, fall back > to polling mode if client->irq < 0 is true. Such a design increases the > overall flexibility. > > [...] Thanks, Applied to https://gitlab.freedesktop.org/drm/misc/kernel.git (drm-misc-next) [1/1] drm/bridge: ite66121: Register HPD interrupt handler only when 'client->irq > 0' https://gitlab.freedesktop.org/drm/misc/kernel/-/commit/ba2d3e6709681b6c16ba8d65a23d72c706d82b5c -- Neil
Re: [PATCH 6/6] drm: zynqmp_dp: Add debugfs interface for compliance testing
On 3/16/24 13:56, Dmitry Baryshkov wrote:
> On Sat, 16 Mar 2024 at 01:09, Sean Anderson wrote:
>>
>> Add a debugfs interface for exercising the various test modes supported
>> by the DisplayPort controller. This allows performing compliance
>> testing, or performing signal integrity measurements on a failing link.
>> At the moment, we do not support sink-driven link quality testing,
>> although such support would be fairly easy to add.
>
> Could you please point out how this is used for compliance testing? We
> have been using the msm_dp_compliance tool [1].
Here's some quick documentation I wrote up. This probably could be put
under Documentation for v2.
The following files in /sys/kernel/debug/dri/1/DP-1/test/ control the
DisplayPort test modes:
active:
Writing a 1 to this file will activate test mode, and writing a 0 will
deactivate test mode. Writing a 1 or 0 when the test mode is already
active/inactive will reactivate/re-deactivate test mode. When test mode
is inactive, changes made to other files will have no effect. When
test mode is active, changes made to other files will apply instantly.
Additionally, hotplug events (as removing the cable or if the monitor
requests link retraining) are ignored.
custom:
Custom test pattern value
downspread:
Enable/disable clock downspreading (spread-spectrum clocking) by
writing 1/0
enhanced:
Enable/disable enhanced framing
lane0_preemphasis:
Preemphasis from 0 (lowest) to 2 (most) for lane 0
lane0_swing:
Voltage swing from 0 (lowest) to 3 (most) for lane 0
lane1_preemphasis:
Preemphasis from 0 (lowest) to 2 (most) for lane 1
lane1_swing:
Voltage swing from 0 (lowest) to 3 (most) for lane 1
lanes:
Number of lanes to use (1 or 2)
pattern:
Test pattern. May be one of:
- video: Use regular video input
- symbol-error: Symbol error measurement pattern
- prbs7: Output of the PRBS7 (x^7 + x^6 + 1) polynomial
- 80bit-custom: A custom 80-bit pattern
- cp2520: HBR2 compliance eye pattern
- tps1: Link training symbol pattern TPS1 (/D10.2/)
- tps2: Link training symbol pattern TPS2
- tps3: Link training symbol pattern TPS3 (for HBR2)
rate:
Rate in hertz. One of
- 54: HBR2
- 27: HBR
- 162000: RBR
You can dump the displayport test settings with the following command:
for prop in /sys/kernel/debug/dri/1/DP-1/test/*; do
printf '%-20s ' ${prop##*/}
if [ ${prop##*/} = custom ]; then
hexdump -C $prop | head -1
else
cat $prop
fi
done
The output could look something like
active 1
custom 00 00 00 00 00 00 00 00 00 00
|..|
downspread 0
enhanced 1
lane0_preemphasis0
lane0_swing 3
lane1_preemphasis0
lane1_swing 3
lanes2
pattern prbs7
rate 162000
The recommended test procedure is to connect the board to a monitor,
configure test mode, activate test mode, and then disconnect the cable
and connect it to your test equipment of choice. For example, one
sequence of commands could be:
echo 1 > /sys/kernel/debug/dri/1/DP-1/test/enhanced
echo tps1 > /sys/kernel/debug/dri/1/DP-1/test/pattern
echo 162000 > /sys/kernel/debug/dri/1/DP-1/test/rate
echo 1 > /sys/kernel/debug/dri/1/DP-1/test/active
at which point the cable could be disconnected from the monitor. When
the cable is disconnected there will be several errors while changing
the settings. This is expected.
> I think it would be nice to rework our drivers towards a common
> debugfs interface used for DP connectors, maybe defining generic
> internal interface/helpers like Maxime is implementing for HDMI
> connectors.
>
> [1]
> https://gitlab.freedesktop.org/drm/igt-gpu-tools/-/blob/master/tools/msm_dp_compliance.c?ref_type=heads
I was definitely inspired by the msm, intel, and amd approaches.
However, those debugfs implementations seem to be oriented towards
DisplayPort text fixtures which emulate DPRXs. In particular, both the
intel and msm debugfs interfaces provide no method for configuring test
parameters in userspace. As test fixtures supporting DPCD can run into
the thousands of dollars, I think it is more economical to support
userspace-driven testing. I was particularly inspired by the AMD
approach:
/* Usage: set DP physical test pattern using debugfs with normal DP
* panel. Then plug out DP panel and connect a scope to measure
* For normal video mode and test pattern generated from CRCT,
* they are visibile to user. So do not disable HPD.
* Video Mode is also set to clear the test pattern, so enable HPD
* because it might have been disabled after a test pattern was set.
* AUX depends on HPD * sequence dependent, do not move!
*/
But I chose to always disable HPD events and ignore DPCD
errors in test mode. I think this is pr
Re: [PATCH 3/6] drm: zynqmp_dp: Add locking
On 3/16/24 05:52, kernel test robot wrote:
> Hi Sean,
>
> kernel test robot noticed the following build warnings:
>
> [auto build test WARNING on v6.8]
> [also build test WARNING on linus/master next-20240315]
> [cannot apply to drm-misc/drm-misc-next]
> [If your patch is applied to the wrong git tree, kindly drop us a note.
> And when submitting patch, we suggest to use '--base' as documented in
> https://git-scm.com/docs/git-format-patch#_base_tree_information]
>
> url:
> https://github.com/intel-lab-lkp/linux/commits/Sean-Anderson/drm-zynqmp_dp-Downgrade-log-level-for-aux-retries-message/20240316-071208
> base: v6.8
> patch link:
> https://lore.kernel.org/r/20240315230916.1759060-4-sean.anderson%40linux.dev
> patch subject: [PATCH 3/6] drm: zynqmp_dp: Add locking
> config: alpha-allyesconfig
> (https://download.01.org/0day-ci/archive/20240316/202403161747.trmfawhm-...@intel.com/config)
> compiler: alpha-linux-gcc (GCC) 13.2.0
> reproduce (this is a W=1 build):
> (https://download.01.org/0day-ci/archive/20240316/202403161747.trmfawhm-...@intel.com/reproduce)
>
> If you fix the issue in a separate patch/commit (i.e. not just a new version
> of
> the same patch/commit), kindly add following tags
> | Reported-by: kernel test robot
> | Closes:
> https://lore.kernel.org/oe-kbuild-all/202403161747.trmfawhm-...@intel.com/
>
> All warnings (new ones prefixed by >>):
>
>>> drivers/gpu/drm/xlnx/zynqmp_dp.c:321: warning: Function parameter or struct
>>> member 'hpd_irq_work' not described in 'zynqmp_dp'
Will document.
--Sean
>
> vim +321 drivers/gpu/drm/xlnx/zynqmp_dp.c
>
> d76271d22694e8 Hyun Kwon2018-07-07 275
> d76271d22694e8 Hyun Kwon2018-07-07 276 /**
> d76271d22694e8 Hyun Kwon2018-07-07 277 * struct zynqmp_dp - Xilinx
> DisplayPort core
> d76271d22694e8 Hyun Kwon2018-07-07 278 * @dev: device structure
> d76271d22694e8 Hyun Kwon2018-07-07 279 * @dpsub: Display subsystem
> d76271d22694e8 Hyun Kwon2018-07-07 280 * @iomem: device I/O memory
> for register access
> d76271d22694e8 Hyun Kwon2018-07-07 281 * @reset: reset controller
> 8ce380e6568015 Sean Anderson2024-03-15 282 * @lock: Mutex protecting
> this struct and register access (but not AUX)
> d76271d22694e8 Hyun Kwon2018-07-07 283 * @irq: irq
> 47e801bd0749f0 Laurent Pinchart 2021-08-04 284 * @bridge: DRM bridge for
> the DP encoder
> bd68b9b3cb2e0d Laurent Pinchart 2021-08-04 285 * @next_bridge: The
> downstream bridge
> d76271d22694e8 Hyun Kwon2018-07-07 286 * @config: IP core
> configuration from DTS
> d76271d22694e8 Hyun Kwon2018-07-07 287 * @aux: aux channel
> d76271d22694e8 Hyun Kwon2018-07-07 288 * @phy: PHY handles for DP
> lanes
> d76271d22694e8 Hyun Kwon2018-07-07 289 * @num_lanes: number of
> enabled phy lanes
> d76271d22694e8 Hyun Kwon2018-07-07 290 * @hpd_work: hot plug
> detection worker
> d76271d22694e8 Hyun Kwon2018-07-07 291 * @status: connection status
> d76271d22694e8 Hyun Kwon2018-07-07 292 * @enabled: flag to
> indicate if the device is enabled
> d76271d22694e8 Hyun Kwon2018-07-07 293 * @dpcd: DP configuration
> data from currently connected sink device
> d76271d22694e8 Hyun Kwon2018-07-07 294 * @link_config: common link
> configuration between IP core and sink device
> d76271d22694e8 Hyun Kwon2018-07-07 295 * @mode: current mode
> between IP core and sink device
> d76271d22694e8 Hyun Kwon2018-07-07 296 * @train_set: set of
> training data
> d76271d22694e8 Hyun Kwon2018-07-07 297 */
> d76271d22694e8 Hyun Kwon2018-07-07 298 struct zynqmp_dp {
> d76271d22694e8 Hyun Kwon2018-07-07 299 struct device *dev;
> d76271d22694e8 Hyun Kwon2018-07-07 300 struct zynqmp_dpsub
> *dpsub;
> d76271d22694e8 Hyun Kwon2018-07-07 301 void __iomem *iomem;
> d76271d22694e8 Hyun Kwon2018-07-07 302 struct reset_control
> *reset;
> 8ce380e6568015 Sean Anderson2024-03-15 303 struct mutex lock;
> d76271d22694e8 Hyun Kwon2018-07-07 304 int irq;
> d76271d22694e8 Hyun Kwon2018-07-07 305
> 47e801bd0749f0 Laurent Pinchart 2021-08-04 306 struct drm_bridge
> bridge;
> bd68b9b3cb2e0d Laurent Pinchart 2021-08-04 307 struct drm_bridge
> *next_bridge;
> 47e801bd0749f0 Laurent Pinchart 2021-08-04 308
> d76271d22694e8 Hyun Kwon2018-07-07 309 struct zynqmp_dp_config
> config;
> d76271d22694e8 Hyun Kwon2018-07-07 310 struct drm_dp_aux aux;
> d76271d22694e8 Hyun Kwon2018-07-07 311 struct phy
> *phy[ZYNQMP_DP_MAX_LANES];
> d76271d22694e8 Hyun Kwon2018-07-07 312 u8 num_lanes;
> 8ce380e6568015 Sean Anderson2024-03-15 313 struct delayed_work
> hpd_work, hpd_irq_work;
> d76271d22694e8 Hyun Kwon2018-07-07 314
Re: [PATCH] drm/panel: ilitek-ili9881c: Fix warning with GPIO controllers that sleep
Hi, On Sun, 17 Mar 2024 17:48:39 +0200, Laurent Pinchart wrote: > The ilitek-ili9881c controls the reset GPIO using the non-sleeping > gpiod_set_value() function. This complains loudly when the GPIO > controller needs to sleep. As the caller can sleep, use > gpiod_set_value_cansleep() to fix the issue. > > Thanks, Applied to https://gitlab.freedesktop.org/drm/misc/kernel.git (drm-misc-next) [1/1] drm/panel: ilitek-ili9881c: Fix warning with GPIO controllers that sleep https://gitlab.freedesktop.org/drm/misc/kernel/-/commit/ee7860cd8b5763017f8dc785c2851fecb7a0c565 -- Neil
Re: [PATCH 0/2] drm/panel: Add Startek KD050HDFIA020-C020A support
Hi, On Sun, 17 Mar 2024 17:57:44 +0200, Laurent Pinchart wrote: > This small series adds support for the Startek KD050HDFIA020-C020A panel > to the ilitek-ili9881c driver. There's not much special here, patch 1/2 > addresses the DT binding and patch 2/2 the driver. Please see individual > patches for details. > > The series has been tested witha Compulab SB-UCM-iMX8MPLUS carrier > board. > > [...] Thanks, Applied to https://gitlab.freedesktop.org/drm/misc/kernel.git (drm-misc-next) [1/2] dt-bindings: ili9881c: Add Startek KD050HDFIA020-C020A support https://gitlab.freedesktop.org/drm/misc/kernel/-/commit/77880bd4512e261372dfc3f49a5ed44fde9d3fa5 [2/2] drm/panel: ilitek-ili9881c: Add Startek KD050HDFIA020-C020A support https://gitlab.freedesktop.org/drm/misc/kernel/-/commit/9fb8aaff8eef56c1822e5267e52d4ab8ebb5b523 -- Neil
Re: [PATCH] drm/panthor: Don't use virt_to_pfn()
On 18/03/2024 2:51 pm, Steven Price wrote:
virt_to_pfn() isn't available on x86 (except to xen) so breaks
COMPILE_TEST builds. Avoid its use completely by instead storing the
struct page pointer allocated in panthor_device_init() and using
page_to_pfn() instead.
Signed-off-by: Steven Price
---
drivers/gpu/drm/panthor/panthor_device.c | 10 ++
drivers/gpu/drm/panthor/panthor_device.h | 2 +-
2 files changed, 7 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/panthor/panthor_device.c
b/drivers/gpu/drm/panthor/panthor_device.c
index 69deb8e17778..3c30da03fa48 100644
--- a/drivers/gpu/drm/panthor/panthor_device.c
+++ b/drivers/gpu/drm/panthor/panthor_device.c
@@ -154,6 +154,7 @@ int panthor_device_init(struct panthor_device *ptdev)
{
struct resource *res;
struct page *p;
+ u32 *dummy_page_virt;
int ret;
ptdev->coherent = device_get_dma_attr(ptdev->base.dev) == DEV_DMA_COHERENT;
@@ -172,9 +173,10 @@ int panthor_device_init(struct panthor_device *ptdev)
if (!p)
return -ENOMEM;
- ptdev->pm.dummy_latest_flush = page_address(p);
+ ptdev->pm.dummy_latest_flush = p;
+ dummy_page_virt = page_address(p);
ret = drmm_add_action_or_reset(&ptdev->base, panthor_device_free_page,
- ptdev->pm.dummy_latest_flush);
+ dummy_page_virt);
Nit: I was about to say I'd be inclined to switch the callback to
__free_page() instead, but then I realise there's no real need to be
reinventing that in the first place:
dummy_page_virt = (void *)devm_get_free_pages(ptdev->base.dev,
GFP_KERNEL | GFP_ZERO, 0);
if (!dummy_page_virt)
return -ENOMEM;
ptdev->pm.dummy_latest_flush = virt_to_page(dummy_page_virt);
Cheers,
Robin.
if (ret)
return ret;
@@ -184,7 +186,7 @@ int panthor_device_init(struct panthor_device *ptdev)
* happens while the dummy page is mapped. Zero cannot be used because
* that means 'always flush'.
*/
- *ptdev->pm.dummy_latest_flush = 1;
+ *dummy_page_virt = 1;
INIT_WORK(&ptdev->reset.work, panthor_device_reset_work);
ptdev->reset.wq = alloc_ordered_workqueue("panthor-reset-wq", 0);
@@ -353,7 +355,7 @@ static vm_fault_t panthor_mmio_vm_fault(struct vm_fault
*vmf)
if (active)
pfn = __phys_to_pfn(ptdev->phys_addr +
CSF_GPU_LATEST_FLUSH_ID);
else
- pfn = virt_to_pfn(ptdev->pm.dummy_latest_flush);
+ pfn = page_to_pfn(ptdev->pm.dummy_latest_flush);
break;
default:
diff --git a/drivers/gpu/drm/panthor/panthor_device.h
b/drivers/gpu/drm/panthor/panthor_device.h
index 51c9d61b6796..c84c27dcc92c 100644
--- a/drivers/gpu/drm/panthor/panthor_device.h
+++ b/drivers/gpu/drm/panthor/panthor_device.h
@@ -160,7 +160,7 @@ struct panthor_device {
* Used to replace the real LATEST_FLUSH page when the GPU
* is suspended.
*/
- u32 *dummy_latest_flush;
+ struct page *dummy_latest_flush;
} pm;
};
Re: [PATCH] drm/panthor: Don't use virt_to_pfn()
On Mon, 18 Mar 2024 14:51:19 +
Steven Price wrote:
> virt_to_pfn() isn't available on x86 (except to xen) so breaks
> COMPILE_TEST builds. Avoid its use completely by instead storing the
> struct page pointer allocated in panthor_device_init() and using
> page_to_pfn() instead.
>
> Signed-off-by: Steven Price
Reviewed-by: Boris Brezillon
Thanks,
Boris
> ---
> drivers/gpu/drm/panthor/panthor_device.c | 10 ++
> drivers/gpu/drm/panthor/panthor_device.h | 2 +-
> 2 files changed, 7 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/gpu/drm/panthor/panthor_device.c
> b/drivers/gpu/drm/panthor/panthor_device.c
> index 69deb8e17778..3c30da03fa48 100644
> --- a/drivers/gpu/drm/panthor/panthor_device.c
> +++ b/drivers/gpu/drm/panthor/panthor_device.c
> @@ -154,6 +154,7 @@ int panthor_device_init(struct panthor_device *ptdev)
> {
> struct resource *res;
> struct page *p;
> + u32 *dummy_page_virt;
> int ret;
>
> ptdev->coherent = device_get_dma_attr(ptdev->base.dev) ==
> DEV_DMA_COHERENT;
> @@ -172,9 +173,10 @@ int panthor_device_init(struct panthor_device *ptdev)
> if (!p)
> return -ENOMEM;
>
> - ptdev->pm.dummy_latest_flush = page_address(p);
> + ptdev->pm.dummy_latest_flush = p;
> + dummy_page_virt = page_address(p);
> ret = drmm_add_action_or_reset(&ptdev->base, panthor_device_free_page,
> -ptdev->pm.dummy_latest_flush);
> +dummy_page_virt);
> if (ret)
> return ret;
>
> @@ -184,7 +186,7 @@ int panthor_device_init(struct panthor_device *ptdev)
>* happens while the dummy page is mapped. Zero cannot be used because
>* that means 'always flush'.
>*/
> - *ptdev->pm.dummy_latest_flush = 1;
> + *dummy_page_virt = 1;
>
> INIT_WORK(&ptdev->reset.work, panthor_device_reset_work);
> ptdev->reset.wq = alloc_ordered_workqueue("panthor-reset-wq", 0);
> @@ -353,7 +355,7 @@ static vm_fault_t panthor_mmio_vm_fault(struct vm_fault
> *vmf)
> if (active)
> pfn = __phys_to_pfn(ptdev->phys_addr +
> CSF_GPU_LATEST_FLUSH_ID);
> else
> - pfn = virt_to_pfn(ptdev->pm.dummy_latest_flush);
> + pfn = page_to_pfn(ptdev->pm.dummy_latest_flush);
> break;
>
> default:
> diff --git a/drivers/gpu/drm/panthor/panthor_device.h
> b/drivers/gpu/drm/panthor/panthor_device.h
> index 51c9d61b6796..c84c27dcc92c 100644
> --- a/drivers/gpu/drm/panthor/panthor_device.h
> +++ b/drivers/gpu/drm/panthor/panthor_device.h
> @@ -160,7 +160,7 @@ struct panthor_device {
>* Used to replace the real LATEST_FLUSH page when the GPU
>* is suspended.
>*/
> - u32 *dummy_latest_flush;
> + struct page *dummy_latest_flush;
> } pm;
> };
>
Re: [PATCH 6/6] drm: zynqmp_dp: Add debugfs interface for compliance testing
On 3/16/24 06:55, kernel test robot wrote: > Hi Sean, > > kernel test robot noticed the following build errors: > > [auto build test ERROR on v6.8] > [cannot apply to drm-misc/drm-misc-next linus/master next-20240315] > [If your patch is applied to the wrong git tree, kindly drop us a note. > And when submitting patch, we suggest to use '--base' as documented in > https://git-scm.com/docs/git-format-patch#_base_tree_information] > > url: > https://github.com/intel-lab-lkp/linux/commits/Sean-Anderson/drm-zynqmp_dp-Downgrade-log-level-for-aux-retries-message/20240316-071208 > base: v6.8 > patch link: > https://lore.kernel.org/r/20240315230916.1759060-7-sean.anderson%40linux.dev > patch subject: [PATCH 6/6] drm: zynqmp_dp: Add debugfs interface for > compliance testing > config: m68k-allyesconfig > (https://download.01.org/0day-ci/archive/20240316/202403161837.76okcezn-...@intel.com/config) > compiler: m68k-linux-gcc (GCC) 13.2.0 > reproduce (this is a W=1 build): > (https://download.01.org/0day-ci/archive/20240316/202403161837.76okcezn-...@intel.com/reproduce) > > If you fix the issue in a separate patch/commit (i.e. not just a new version > of > the same patch/commit), kindly add following tags > | Reported-by: kernel test robot > | Closes: > https://lore.kernel.org/oe-kbuild-all/202403161837.76okcezn-...@intel.com/ > > All errors (new ones prefixed by >>): > >m68k-linux-ld: drivers/gpu/drm/xlnx/zynqmp_dp.o: in function > `zynqmp_dp_rate_set': >>> zynqmp_dp.c:(.text+0x1a7a): undefined reference to `__udivdi3' > Will fix. --Sean
Re: [PATCH 6/6] drm: zynqmp_dp: Add debugfs interface for compliance testing
On 3/16/24 06:14, kernel test robot wrote:
> Hi Sean,
>
> kernel test robot noticed the following build warnings:
>
> [auto build test WARNING on v6.8]
> [cannot apply to drm-misc/drm-misc-next linus/master next-20240315]
> [If your patch is applied to the wrong git tree, kindly drop us a note.
> And when submitting patch, we suggest to use '--base' as documented in
> https://git-scm.com/docs/git-format-patch#_base_tree_information]
>
> url:
> https://github.com/intel-lab-lkp/linux/commits/Sean-Anderson/drm-zynqmp_dp-Downgrade-log-level-for-aux-retries-message/20240316-071208
> base: v6.8
> patch link:
> https://lore.kernel.org/r/20240315230916.1759060-7-sean.anderson%40linux.dev
> patch subject: [PATCH 6/6] drm: zynqmp_dp: Add debugfs interface for
> compliance testing
> config: microblaze-allmodconfig
> (https://download.01.org/0day-ci/archive/20240316/202403161704.achjdsjg-...@intel.com/config)
> compiler: microblaze-linux-gcc (GCC) 13.2.0
> reproduce (this is a W=1 build):
> (https://download.01.org/0day-ci/archive/20240316/202403161704.achjdsjg-...@intel.com/reproduce)
>
> If you fix the issue in a separate patch/commit (i.e. not just a new version
> of
> the same patch/commit), kindly add following tags
> | Reported-by: kernel test robot
> | Closes:
> https://lore.kernel.org/oe-kbuild-all/202403161704.achjdsjg-...@intel.com/
>
> All warnings (new ones prefixed by >>):
>
>drivers/gpu/drm/xlnx/zynqmp_dp.c: In function
> 'zynqmp_dp_bridge_debugfs_init':
>>> drivers/gpu/drm/xlnx/zynqmp_dp.c:2168:31: warning: 'sprintf' may write a
>>> terminating nul past the end of the destination [-Wformat-overflow=]
> 2168 | sprintf(name, fmt, i);
> | ^~~
>drivers/gpu/drm/xlnx/zynqmp_dp.c:2168:17: note: 'sprintf' output between
> 18 and 20 bytes into a destination of size 19
> 2168 | sprintf(name, fmt, i);
> | ^
Not a bug, as i will be at most 4, which uses 1 digit.
--Sean
> vim +/sprintf +2168 drivers/gpu/drm/xlnx/zynqmp_dp.c
>
> 2136
> 2137DEFINE_DEBUGFS_ATTRIBUTE(fops_zynqmp_dp_rate,
> zynqmp_dp_rate_get,
> 2138 zynqmp_dp_rate_set, "%llu\n");
> 2139
> 2140static void zynqmp_dp_bridge_debugfs_init(struct drm_bridge
> *bridge,
> 2141 struct dentry *root)
> 2142{
> 2143struct zynqmp_dp *dp = bridge_to_dp(bridge);
> 2144struct dentry *test;
> 2145int i;
> 2146
> 2147dp->test.bw_code = DP_LINK_BW_5_4;
> 2148dp->test.link_cnt = dp->num_lanes;
> 2149
> 2150test = debugfs_create_dir("test", root);
> 2151#define CREATE_FILE(name) \
> 2152debugfs_create_file(#name, 0600, test, dp,
> &fops_zynqmp_dp_##name)
> 2153CREATE_FILE(pattern);
> 2154CREATE_FILE(enhanced);
> 2155CREATE_FILE(downspread);
> 2156CREATE_FILE(active);
> 2157CREATE_FILE(custom);
> 2158CREATE_FILE(rate);
> 2159CREATE_FILE(lanes);
> 2160
> 2161for (i = 0; i < dp->num_lanes; i++) {
> 2162static const char fmt[] = "lane%d_preemphasis";
> 2163char name[sizeof(fmt)];
> 2164
> 2165dp->debugfs_train_set[i].dp = dp;
> 2166dp->debugfs_train_set[i].lane = i;
> 2167
>> 2168 sprintf(name, fmt, i);
> 2169debugfs_create_file(name, 0600, test,
> 2170&dp->debugfs_train_set[i],
> 2171
> &fops_zynqmp_dp_preemphasis);
> 2172
> 2173sprintf(name, "lane%d_swing", i);
> 2174debugfs_create_file(name, 0600, test,
> 2175&dp->debugfs_train_set[i],
> 2176&fops_zynqmp_dp_swing);
> 2177}
> 2178}
> 2179
>
Re: [PATCH 2/5] drm/gem: Add a mountpoint parameter to drm_gem_object_init()
Am 18.03.24 um 15:24 schrieb Maíra Canal:
Not that the CC list wasn't big enough, but I'm adding MM folks
in the CC list.
On 3/18/24 11:04, Christian König wrote:
Am 18.03.24 um 14:28 schrieb Maíra Canal:
Hi Christian,
On 3/18/24 10:10, Christian König wrote:
Am 18.03.24 um 13:42 schrieb Maíra Canal:
Hi Christian,
On 3/12/24 10:48, Christian König wrote:
Am 12.03.24 um 14:09 schrieb Tvrtko Ursulin:
On 12/03/2024 10:37, Christian König wrote:
Am 12.03.24 um 11:31 schrieb Tvrtko Ursulin:
On 12/03/2024 10:23, Christian König wrote:
Am 12.03.24 um 10:30 schrieb Tvrtko Ursulin:
On 12/03/2024 08:59, Christian König wrote:
Am 12.03.24 um 09:51 schrieb Tvrtko Ursulin:
Hi Maira,
On 11/03/2024 10:05, Maíra Canal wrote:
For some applications, such as using huge pages, we might
want to have a
different mountpoint, for which we pass in mount flags
that better match
our usecase.
Therefore, add a new parameter to drm_gem_object_init()
that allow us to
define the tmpfs mountpoint where the GEM object will be
created. If
this parameter is NULL, then we fallback to
shmem_file_setup().
One strategy for reducing churn, and so the number of
drivers this patch touches, could be to add a lower level
drm_gem_object_init() (which takes vfsmount, call it
__drm_gem_object_init(), or drm__gem_object_init_mnt(),
and make drm_gem_object_init() call that one with a NULL
argument.
I would even go a step further into the other direction.
The shmem backed GEM object is just some special handling
as far as I can see.
So I would rather suggest to rename all drm_gem_* function
which only deal with the shmem backed GEM object into
drm_gem_shmem_*.
That makes sense although it would be very churny. I at
least would be on the fence regarding the cost vs benefit.
Yeah, it should clearly not be part of this patch here.
Also the explanation why a different mount point helps with
something isn't very satisfying.
Not satisfying as you think it is not detailed enough to say
driver wants to use huge pages for performance? Or not
satisying as you question why huge pages would help?
That huge pages are beneficial is clear to me, but I'm
missing the connection why a different mount point helps with
using huge pages.
Ah right, same as in i915, one needs to mount a tmpfs instance
passing huge=within_size or huge=always option. Default is
'never', see man 5 tmpfs.
Thanks for the explanation, I wasn't aware of that.
Mhm, shouldn't we always use huge pages? Is there a reason for
a DRM device to not use huge pages with the shmem backend?
AFAIU, according to b901bb89324a ("drm/i915/gemfs: enable THP"),
back then the understanding was within_size may overallocate,
meaning there would be some space wastage, until the memory
pressure makes the thp code split the trailing huge page. I
haven't checked if that still applies.
Other than that I don't know if some drivers/platforms could
have problems if they have some limitations or hardcoded
assumptions when they iterate the sg list.
Yeah, that was the whole point behind my question. As far as I
can see this isn't driver specific, but platform specific.
I might be wrong here, but I think we should then probably not
have that handling in each individual driver, but rather
centralized in the DRM code.
I don't see a point in enabling THP for all shmem drivers. A huge
page
is only useful if the driver is going to use it. On V3D, for example,
I only need huge pages because I need the memory contiguously
allocated
to implement Super Pages. Otherwise, if we don't have the Super Pages
support implemented in the driver, I would be creating memory
pressure
without any performance gain.
Well that's the point I'm disagreeing with. THP doesn't seem to
create much extra memory pressure for this use case.
As far as I can see background for the option is that files in
tmpfs usually have a varying size, so it usually isn't beneficial
to allocate a huge page just to find that the shmem file is much
smaller than what's needed.
But GEM objects have a fixed size. So we of hand knew if we need
4KiB or 1GiB and can therefore directly allocate huge pages if they
are available and object large enough to back them with.
If the memory pressure is so high that we don't have huge pages
available the shmem code falls back to standard pages anyway.
The matter is: how do we define the point where the memory pressure
is high?
Well as driver developers/maintainers we simply don't do that. This
is the job of the shmem code.
For example, notice that in this implementation of Super Pages
for the V3D driver, I only use a Super Page if the BO is bigger than
2MB. I'm doing that because the Raspberry Pi only has 4GB of RAM
available for the GPU. If I created huge pages for every BO
allocation (and initially, I tried that), I would end up with hangs
in some applications.
Yeah, that is what I meant with the trivial optimisation to the shme
Re: [PATCH] Revert "drm/bridge: Select DRM_KMS_HELPER for DRM_PANEL_BRIDGE"
Hi, On Mon, 18 Mar 2024 15:16:21 +0100, Neil Armstrong wrote: > This reverts commit e3f18b0dd1db242791afbc3bd173026163ce0ccc. > > Selecting DRM_KMS_HELPER for DRM_PANEL_BRIDGE leads to: > WARNING: unmet direct dependencies detected for DRM_KMS_HELPER > Depends on [m]: HAS_IOMEM [=y] && DRM [=m] > ... > > [...] Thanks, Applied to https://gitlab.freedesktop.org/drm/misc/kernel.git (drm-misc-fixes) [1/1] Revert "drm/bridge: Select DRM_KMS_HELPER for DRM_PANEL_BRIDGE" https://gitlab.freedesktop.org/drm/misc/kernel/-/commit/dbd9698830ebafcb6f3be6498fd4a6968dcbf89a -- Neil
[drm-misc:for-linux-next-fixes 1/1] ld.lld: error: undefined symbol: __drm_dev_dbg
tree: git://anongit.freedesktop.org/drm/drm-misc for-linux-next-fixes head: e3f18b0dd1db242791afbc3bd173026163ce0ccc commit: e3f18b0dd1db242791afbc3bd173026163ce0ccc [1/1] drm/bridge: Select DRM_KMS_HELPER for DRM_PANEL_BRIDGE config: riscv-defconfig (https://download.01.org/0day-ci/archive/20240318/202403182236.bedkbjub-...@intel.com/config) compiler: clang version 19.0.0git (https://github.com/llvm/llvm-project 8f68022f8e6e54d1aeae4ed301f5a015963089b7) reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20240318/202403182236.bedkbjub-...@intel.com/reproduce) If you fix the issue in a separate patch/commit (i.e. not just a new version of the same patch/commit), kindly add following tags | Reported-by: kernel test robot | Closes: https://lore.kernel.org/oe-kbuild-all/202403182236.bedkbjub-...@intel.com/ All errors (new ones prefixed by >>): >> ld.lld: error: undefined symbol: __drm_dev_dbg >>> referenced by drm_atomic_helper.c >>> drivers/gpu/drm/drm_atomic_helper.o:(drm_atomic_helper_check_modeset) in archive vmlinux.a >>> referenced by drm_atomic_helper.c >>> drivers/gpu/drm/drm_atomic_helper.o:(drm_atomic_helper_check_modeset) in archive vmlinux.a >>> referenced by drm_atomic_helper.c >>> drivers/gpu/drm/drm_atomic_helper.o:(drm_atomic_helper_check_modeset) in archive vmlinux.a >>> referenced 52 more times -- >> ld.lld: error: undefined symbol: drm_dev_has_vblank >>> referenced by drm_atomic_helper.c >>> drivers/gpu/drm/drm_atomic_helper.o:(drm_atomic_helper_check_modeset) in archive vmlinux.a >>> referenced by drm_atomic_helper.c >>> drivers/gpu/drm/drm_atomic_helper.o:(drm_atomic_helper_commit_modeset_disables) in archive vmlinux.a >>> referenced by drm_atomic_state_helper.c >>> drivers/gpu/drm/drm_atomic_state_helper.o:(__drm_atomic_helper_crtc_reset) in archive vmlinux.a >>> referenced 1 more times -- >> ld.lld: error: undefined symbol: drm_atomic_set_crtc_for_connector >>> referenced by drm_atomic_helper.c >>> drivers/gpu/drm/drm_atomic_helper.o:(handle_conflicting_encoders) in archive vmlinux.a >>> referenced by drm_atomic_helper.c >>> drivers/gpu/drm/drm_atomic_helper.o:(drm_atomic_helper_disable_all) in archive vmlinux.a -- >> ld.lld: error: undefined symbol: drm_atomic_set_mode_prop_for_crtc >>> referenced by drm_atomic_helper.c >>> drivers/gpu/drm/drm_atomic_helper.o:(handle_conflicting_encoders) in archive vmlinux.a >>> referenced by drm_atomic_helper.c >>> drivers/gpu/drm/drm_atomic_helper.o:(drm_atomic_helper_disable_all) in archive vmlinux.a -- >> ld.lld: error: undefined symbol: drm_connector_list_iter_end >>> referenced by drm_atomic_helper.c >>> drivers/gpu/drm/drm_atomic_helper.o:(handle_conflicting_encoders) in archive vmlinux.a >>> referenced by drm_atomic_helper.c >>> drivers/gpu/drm/drm_atomic_helper.o:(drm_atomic_helper_duplicate_state) in archive vmlinux.a >>> referenced by drm_atomic_helper.c >>> drivers/gpu/drm/drm_atomic_helper.o:(drm_atomic_helper_duplicate_state) in archive vmlinux.a >>> referenced 25 more times -- >> ld.lld: error: undefined symbol: drm_mode_copy >>> referenced by drm_atomic_helper.c >>> drivers/gpu/drm/drm_atomic_helper.o:(mode_fixup) in archive vmlinux.a >>> referenced by drm_crtc_helper.c >>> drivers/gpu/drm/drm_crtc_helper.o:(drm_crtc_helper_set_mode) in archive vmlinux.a >>> referenced by drm_crtc_helper.c >>> drivers/gpu/drm/drm_crtc_helper.o:(drm_crtc_helper_set_mode) in archive vmlinux.a >>> referenced 2 more times -- >> ld.lld: error: undefined symbol: drm_atomic_bridge_chain_check >>> referenced by drm_atomic_helper.c >>> drivers/gpu/drm/drm_atomic_helper.o:(mode_fixup) in archive vmlinux.a -- >> ld.lld: error: undefined symbol: drm_mode_get_hv_timing >>> referenced by drm_atomic_helper.c >>> drivers/gpu/drm/drm_atomic_helper.o:(drm_atomic_helper_check_plane_state) in archive vmlinux.a -- >> ld.lld: error: undefined symbol: drm_atomic_normalize_zpos >>> referenced by drm_atomic_helper.c >>> drivers/gpu/drm/drm_atomic_helper.o:(drm_atomic_helper_check) in archive vmlinux.a -- >> ld.lld: error: undefined symbol: drm_calc_timestamping_constants >>>
[drm-misc:for-linux-next-fixes 1/1] undefined reference to `__drm_dev_dbg'
tree: git://anongit.freedesktop.org/drm/drm-misc for-linux-next-fixes head: e3f18b0dd1db242791afbc3bd173026163ce0ccc commit: e3f18b0dd1db242791afbc3bd173026163ce0ccc [1/1] drm/bridge: Select DRM_KMS_HELPER for DRM_PANEL_BRIDGE config: parisc-defconfig (https://download.01.org/0day-ci/archive/20240318/202403182243.do4x1bo0-...@intel.com/config) compiler: hppa-linux-gcc (GCC) 13.2.0 reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20240318/202403182243.do4x1bo0-...@intel.com/reproduce) If you fix the issue in a separate patch/commit (i.e. not just a new version of the same patch/commit), kindly add following tags | Reported-by: kernel test robot | Closes: https://lore.kernel.org/oe-kbuild-all/202403182243.do4x1bo0-...@intel.com/ All errors (new ones prefixed by >>): hppa-linux-ld: drivers/gpu/drm/drm_atomic_helper.o: in function `drm_atomic_helper_check_wb_connector_state': >> (.text+0x9a4): undefined reference to `__drm_dev_dbg' hppa-linux-ld: drivers/gpu/drm/drm_atomic_helper.o: in function `drm_atomic_helper_check_crtc_primary_plane': (.text+0xa48): undefined reference to `__drm_dev_dbg' hppa-linux-ld: drivers/gpu/drm/drm_atomic_helper.o: in function `update_connector_routing': (.text+0xadc): undefined reference to `__drm_dev_dbg' >> hppa-linux-ld: (.text+0xc4c): undefined reference to `__drm_dev_dbg' hppa-linux-ld: (.text+0xcc4): undefined reference to `__drm_dev_dbg' hppa-linux-ld: drivers/gpu/drm/drm_atomic_helper.o:(.text+0xd48): more undefined references to `__drm_dev_dbg' follow hppa-linux-ld: drivers/gpu/drm/drm_atomic_helper.o: in function `handle_conflicting_encoders': >> (.text+0xf40): undefined reference to `drm_connector_list_iter_begin' >> hppa-linux-ld: (.text+0xf58): undefined reference to >> `drm_connector_list_iter_next' >> hppa-linux-ld: (.text+0xfbc): undefined reference to >> `drm_atomic_get_connector_state' hppa-linux-ld: (.text+0x1014): undefined reference to `__drm_dev_dbg' >> hppa-linux-ld: (.text+0x1038): undefined reference to >> `drm_atomic_set_crtc_for_connector' >> hppa-linux-ld: (.text+0x1050): undefined reference to >> `drm_atomic_set_mode_prop_for_crtc' hppa-linux-ld: (.text+0x1060): undefined reference to `drm_connector_list_iter_next' >> hppa-linux-ld: (.text+0x1070): undefined reference to >> `drm_connector_list_iter_end' hppa-linux-ld: (.text+0x112c): undefined reference to `__drm_dev_dbg' hppa-linux-ld: (.text+0x118c): undefined reference to `__drm_dev_dbg' hppa-linux-ld: drivers/gpu/drm/drm_atomic_helper.o: in function `mode_valid': >> (.text+0x1250): undefined reference to `drm_bridge_chain_mode_valid' hppa-linux-ld: (.text+0x1274): undefined reference to `__drm_dev_dbg' hppa-linux-ld: (.text+0x12fc): undefined reference to `__drm_dev_dbg' hppa-linux-ld: (.text+0x1334): undefined reference to `__drm_dev_dbg' hppa-linux-ld: drivers/gpu/drm/drm_atomic_helper.o: in function `mode_fixup': >> (.text+0x13c4): undefined reference to `drm_mode_copy' >> hppa-linux-ld: (.text+0x1460): undefined reference to >> `drm_atomic_bridge_chain_check' hppa-linux-ld: (.text+0x15b0): undefined reference to `__drm_dev_dbg' hppa-linux-ld: (.text+0x15c8): undefined reference to `drm_atomic_bridge_chain_check' hppa-linux-ld: (.text+0x15f4): undefined reference to `__drm_dev_dbg' hppa-linux-ld: (.text+0x1630): undefined reference to `__drm_dev_dbg' hppa-linux-ld: (.text+0x1668): undefined reference to `__drm_dev_dbg' hppa-linux-ld: drivers/gpu/drm/drm_atomic_helper.o: in function `drm_atomic_helper_check_modeset': >> (.text+0x17a8): undefined reference to `drm_mode_equal' hppa-linux-ld: (.text+0x17d8): undefined reference to `__drm_dev_dbg' hppa-linux-ld: (.text+0x181c): undefined reference to `__drm_dev_dbg' hppa-linux-ld: (.text+0x1864): undefined reference to `__drm_dev_dbg' >> hppa-linux-ld: (.text+0x1884): undefined reference to `drm_dev_has_vblank' hppa-linux-ld: (.text+0x1a08): undefined reference to `__drm_dev_dbg' hppa-linux-ld: (.text+0x1ae0): undefined reference to `__drm_dev_dbg' >> hppa-linux-ld: (.text+0x1aec): undefined reference to >> `drm_atomic_add_affected_connectors' >> hppa-linux-ld: (.text+0x1b00): undefined reference to >> `drm_atomic_add_affected_planes' >> hppa-linux-ld: (.text+0x1bdc): undefined reference to >> `drm_atomic_add_encoder_bridges' hppa-linux-ld: (.text+0x1bec): undefined reference to `drm_atomic_add_encoder_bridges' hppa-linux-ld: (.text+0x1c58): undefined reference to `__drm_dev_dbg' hppa-linux-ld: (.text+0x1c94): undefine
Re: [PATCH] drm/panthor: Fix the CONFIG_PM=n case
On 18/03/2024 14:49, Boris Brezillon wrote: > On Mon, 18 Mar 2024 14:34:07 + > Steven Price wrote: > >> On 18/03/2024 14:18, Boris Brezillon wrote: >>> On Mon, 18 Mar 2024 13:49:52 + >>> Steven Price wrote: >>> On 18/03/2024 13:08, Boris Brezillon wrote: > On Mon, 18 Mar 2024 11:31:05 + > Steven Price wrote: > >> On 18/03/2024 08:58, Boris Brezillon wrote: >>> Putting a hard dependency on CONFIG_PM is not possible because of a >>> circular dependency issue, and it's actually not desirable either. In >>> order to support this use case, we forcibly resume at init time, and >>> suspend at unplug time. >>> >>> Reported-by: kernel test robot >>> Closes: >>> https://lore.kernel.org/oe-kbuild-all/202403031944.eoimq8wk-...@intel.com/ >>> Signed-off-by: Boris Brezillon >> >> Reviewed-by: Steven Price >> >>> --- >>> Tested by faking CONFIG_PM=n in the driver (basically commenting >>> all pm_runtime calls, and making the panthor_device_suspend/resume() >>> calls unconditional in the panthor_device_unplug/init() path) since >>> CONFIG_ARCH_ROCKCHIP selects CONFIG_PM. Seems to work fine, but I >>> can't be 100% sure this will work correctly on a platform that has >>> CONFIG_PM=n. >> >> The same - I can't test this properly :( >> >> Note that the other option (which AFAICT doesn't cause any problems) is >> to "select PM" rather than depend on it - AIUI the 'select' dependency >> is considered in the opposite direction by kconfig so won't cause the >> dependency loop. > > Doesn't seem to work with COMPILE_TEST though? I mean, we need > something like > > depends on ARM || ARM64 || (COMPILE_TEST && PM) > ... > select PM > > but kconfig doesn't like that Why do we need the "&& PM" part? Just: depends on ARM || ARM64 || COMPILE_TEST ... select PM Or at least that appears to work for me. >>> >>> Uh, you're right, sorry for the brain fart. This is being said, I >>> see no other driver selecting the PM option directly (if you grep for >>> 'select PM' in drivers/, you'll find occurrences in drivers/soc, but >>> those are under ARCH_/SOC_ options, which means they are indirectly >>> arch/platform dependent, not driver dependent). I'm really not sure >>> selecting PM here from a driver is right to be honest. >> >> Yeah, I'm not very convinced about that either. It's just a pain that >> the code is going to go untested. > > If that's really bothering you, let's just return an error in the > probe path when CONFIG_PM=n as you were suggesting last week. Honestly I'm fine with this patch (modulo it needs compile testing!). I'd obviously just be happier if someone actually had a platform where this could be tested. But really one of two things will happen: a) Nobody will ever execute the code. In which case it doesn't really matter as long as it builds. b) Someone will execute the code, and it'll either work which is great (and so we won't hear), or it will break and hopefully then we'll have a willing tester ;) >> > drivers/gpu/drm/panthor/Kconfig:3:error: recursive dependency detected! > drivers/gpu/drm/panthor/Kconfig:3:symbol DRM_PANTHOR depends on > PM kernel/power/Kconfig:183: symbol PM is selected by DRM_PANTHOR > > which id why I initially when for a depends on PM > > >> Of course if there is actually anyone who has a >> platform which can be built !CONFIG_PM then that won't help. But the >> inability of anyone to actually properly test this configuration does >> worry me a little. > > Well, as long as it doesn't regress the PM behavior, I think I'm happy > to take the risk. Worst case scenario, someone complains that this is > not working properly when they do the !PM bringup :-). Indeed, I've no objection to this patch - although I really should have compiled tested it as Robin pointed out ;) But one other thing I've noticed when compile testing it - we don't appear to have fully fixed the virt_to_pfn() problem. On x86 with COMPILE_TEST I still get an error. Looking at the code it appears that virt_to_pfn() isn't available on x86... it overrides asm/page.h and doesn't provide a definition. The definition on x86 is hiding in asm/xen/page.h. >>> >>> Looks like the kbuild bot didn't catch that yet :-). >>> Outside of arch code it's only drivers/xen that currently uses that function. So I guess it's probably best to do a PFN_DOWN(virt_to_phys(...)) instead. Or look to fix x86 :) >>> >>> Mind sending a fix for that? >> >> Yeah, I'll have a go at Robin's suggestion of storing the struct page >> instead. > > If that's not too much to ask, could you also send a variant of this > patc
Re: [PATCH] Revert "drm/bridge: Select DRM_KMS_HELPER for DRM_PANEL_BRIDGE"
On Mon, 18 Mar 2024, Neil Armstrong wrote:
> This reverts commit e3f18b0dd1db242791afbc3bd173026163ce0ccc.
>
> Selecting DRM_KMS_HELPER for DRM_PANEL_BRIDGE leads to:
> WARNING: unmet direct dependencies detected for DRM_KMS_HELPER
> Depends on [m]: HAS_IOMEM [=y] && DRM [=m]
> ...
>
> and builds with CONFIG_DRM=m will fail with the above kconfig
> warns and then multiple linker error.
>
> Reported-by: Imre Deak
> Reported-by: Jani Nikula
> Reported-by: Ville Syrjälä
> Fixes: e3f18b0dd1db ("drm/bridge: Select DRM_KMS_HELPER for DRM_PANEL_BRIDGE")
> Signed-off-by: Neil Armstrong
Acked-by: Jani Nikula
Tested-by: Jani Nikula
> ---
> drivers/gpu/drm/bridge/Kconfig | 1 -
> 1 file changed, 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/bridge/Kconfig b/drivers/gpu/drm/bridge/Kconfig
> index 1d4f010af97b..efd996f6c138 100644
> --- a/drivers/gpu/drm/bridge/Kconfig
> +++ b/drivers/gpu/drm/bridge/Kconfig
> @@ -8,7 +8,6 @@ config DRM_BRIDGE
> config DRM_PANEL_BRIDGE
> def_bool y
> depends on DRM_BRIDGE
> - select DRM_KMS_HELPER
> select DRM_PANEL
> help
> DRM bridge wrapper of DRM panels
>
> ---
> base-commit: e3f18b0dd1db242791afbc3bd173026163ce0ccc
> change-id:
> 20240318-revert-select-drm_kms_helper-for-drm_panel_bridge-0e4ad7c73496
>
> Best regards,
--
Jani Nikula, Intel
[PATCH] drm/panthor: Don't use virt_to_pfn()
virt_to_pfn() isn't available on x86 (except to xen) so breaks
COMPILE_TEST builds. Avoid its use completely by instead storing the
struct page pointer allocated in panthor_device_init() and using
page_to_pfn() instead.
Signed-off-by: Steven Price
---
drivers/gpu/drm/panthor/panthor_device.c | 10 ++
drivers/gpu/drm/panthor/panthor_device.h | 2 +-
2 files changed, 7 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/panthor/panthor_device.c
b/drivers/gpu/drm/panthor/panthor_device.c
index 69deb8e17778..3c30da03fa48 100644
--- a/drivers/gpu/drm/panthor/panthor_device.c
+++ b/drivers/gpu/drm/panthor/panthor_device.c
@@ -154,6 +154,7 @@ int panthor_device_init(struct panthor_device *ptdev)
{
struct resource *res;
struct page *p;
+ u32 *dummy_page_virt;
int ret;
ptdev->coherent = device_get_dma_attr(ptdev->base.dev) ==
DEV_DMA_COHERENT;
@@ -172,9 +173,10 @@ int panthor_device_init(struct panthor_device *ptdev)
if (!p)
return -ENOMEM;
- ptdev->pm.dummy_latest_flush = page_address(p);
+ ptdev->pm.dummy_latest_flush = p;
+ dummy_page_virt = page_address(p);
ret = drmm_add_action_or_reset(&ptdev->base, panthor_device_free_page,
- ptdev->pm.dummy_latest_flush);
+ dummy_page_virt);
if (ret)
return ret;
@@ -184,7 +186,7 @@ int panthor_device_init(struct panthor_device *ptdev)
* happens while the dummy page is mapped. Zero cannot be used because
* that means 'always flush'.
*/
- *ptdev->pm.dummy_latest_flush = 1;
+ *dummy_page_virt = 1;
INIT_WORK(&ptdev->reset.work, panthor_device_reset_work);
ptdev->reset.wq = alloc_ordered_workqueue("panthor-reset-wq", 0);
@@ -353,7 +355,7 @@ static vm_fault_t panthor_mmio_vm_fault(struct vm_fault
*vmf)
if (active)
pfn = __phys_to_pfn(ptdev->phys_addr +
CSF_GPU_LATEST_FLUSH_ID);
else
- pfn = virt_to_pfn(ptdev->pm.dummy_latest_flush);
+ pfn = page_to_pfn(ptdev->pm.dummy_latest_flush);
break;
default:
diff --git a/drivers/gpu/drm/panthor/panthor_device.h
b/drivers/gpu/drm/panthor/panthor_device.h
index 51c9d61b6796..c84c27dcc92c 100644
--- a/drivers/gpu/drm/panthor/panthor_device.h
+++ b/drivers/gpu/drm/panthor/panthor_device.h
@@ -160,7 +160,7 @@ struct panthor_device {
* Used to replace the real LATEST_FLUSH page when the GPU
* is suspended.
*/
- u32 *dummy_latest_flush;
+ struct page *dummy_latest_flush;
} pm;
};
--
2.39.2
Re: [PATCH] drm/panthor: Fix the CONFIG_PM=n case
On Mon, 18 Mar 2024 14:34:07 + Steven Price wrote: > On 18/03/2024 14:18, Boris Brezillon wrote: > > On Mon, 18 Mar 2024 13:49:52 + > > Steven Price wrote: > > > >> On 18/03/2024 13:08, Boris Brezillon wrote: > >>> On Mon, 18 Mar 2024 11:31:05 + > >>> Steven Price wrote: > >>> > On 18/03/2024 08:58, Boris Brezillon wrote: > > Putting a hard dependency on CONFIG_PM is not possible because of a > > circular dependency issue, and it's actually not desirable either. In > > order to support this use case, we forcibly resume at init time, and > > suspend at unplug time. > > > > Reported-by: kernel test robot > > Closes: > > https://lore.kernel.org/oe-kbuild-all/202403031944.eoimq8wk-...@intel.com/ > > Signed-off-by: Boris Brezillon > > Reviewed-by: Steven Price > > > --- > > Tested by faking CONFIG_PM=n in the driver (basically commenting > > all pm_runtime calls, and making the panthor_device_suspend/resume() > > calls unconditional in the panthor_device_unplug/init() path) since > > CONFIG_ARCH_ROCKCHIP selects CONFIG_PM. Seems to work fine, but I > > can't be 100% sure this will work correctly on a platform that has > > CONFIG_PM=n. > > The same - I can't test this properly :( > > Note that the other option (which AFAICT doesn't cause any problems) is > to "select PM" rather than depend on it - AIUI the 'select' dependency > is considered in the opposite direction by kconfig so won't cause the > dependency loop. > >>> > >>> Doesn't seem to work with COMPILE_TEST though? I mean, we need > >>> something like > >>> > >>> depends on ARM || ARM64 || (COMPILE_TEST && PM) > >>> ... > >>> select PM > >>> > >>> but kconfig doesn't like that > >> > >> Why do we need the "&& PM" part? Just: > >> > >>depends on ARM || ARM64 || COMPILE_TEST > >>... > >>select PM > >> > >> Or at least that appears to work for me. > > > > Uh, you're right, sorry for the brain fart. This is being said, I > > see no other driver selecting the PM option directly (if you grep for > > 'select PM' in drivers/, you'll find occurrences in drivers/soc, but > > those are under ARCH_/SOC_ options, which means they are indirectly > > arch/platform dependent, not driver dependent). I'm really not sure > > selecting PM here from a driver is right to be honest. > > Yeah, I'm not very convinced about that either. It's just a pain that > the code is going to go untested. If that's really bothering you, let's just return an error in the probe path when CONFIG_PM=n as you were suggesting last week. > > >> > >>> drivers/gpu/drm/panthor/Kconfig:3:error: recursive dependency detected! > >>> drivers/gpu/drm/panthor/Kconfig:3:symbol DRM_PANTHOR depends on > >>> PM kernel/power/Kconfig:183: symbol PM is selected by DRM_PANTHOR > >>> > >>> which id why I initially when for a depends on PM > >>> > >>> > Of course if there is actually anyone who has a > platform which can be built !CONFIG_PM then that won't help. But the > inability of anyone to actually properly test this configuration does > worry me a little. > >>> > >>> Well, as long as it doesn't regress the PM behavior, I think I'm happy > >>> to take the risk. Worst case scenario, someone complains that this is > >>> not working properly when they do the !PM bringup :-). > >> > >> Indeed, I've no objection to this patch - although I really should have > >> compiled tested it as Robin pointed out ;) > >> > >> But one other thing I've noticed when compile testing it - we don't > >> appear to have fully fixed the virt_to_pfn() problem. On x86 with > >> COMPILE_TEST I still get an error. Looking at the code it appears that > >> virt_to_pfn() isn't available on x86... it overrides asm/page.h and > >> doesn't provide a definition. The definition on x86 is hiding in > >> asm/xen/page.h. > > > > Looks like the kbuild bot didn't catch that yet :-). > > > >> > >> Outside of arch code it's only drivers/xen that currently uses that > >> function. So I guess it's probably best to do a > >> PFN_DOWN(virt_to_phys(...)) instead. Or look to fix x86 :) > > > > Mind sending a fix for that? > > Yeah, I'll have a go at Robin's suggestion of storing the struct page > instead. If that's not too much to ask, could you also send a variant of this patch returning an error when CONFIG_PM is disabled (and fixing the other mistake I made, of course)? Thanks, Boris
Re: [PATCH v4 03/11] drm/ci: uprev IGT and update testlist
Hi Dmitry, On 15/03/24 17:07, Dmitry Baryshkov wrote: On Wed, 6 Mar 2024 at 05:08, Vignesh Raman wrote: Uprev IGT and add amd, v3d, vc4 and vgem specific tests to testlist. Have testlist.txt per driver and include a base testlist so that the driver specific tests will run only on those hardware. Also add testlists to the MAINTAINERS file. I think we should move away from specifying tests explicitly. They can easily get out of sync. A month ago I had to manually go through the list of the tests and update it to follow changes in the IGT. I think we should directly use testlist.txt from IGT and then filter it out using skips. So we use the test-list-full.txt or test-list.txt from IGT and generate a single testlist for drm-ci when we uprev IGT? Instead of adding the below to skips file for different driver, msm_.* ^amdgpu.* panfrost_.* v3d_.* vc4_.* If we have a separate testlist for each driver, we can update the main testlist.txt along with individual testlist for each driver. We just need to move the driver specific tests from main testlist to individual driver testlist file. Please let me know your thoughts. Thanks. Regards, Vignesh
Re: [PATCH] drm/Makefile: Move tiny drivers before native drivers
Hi, Jaak,
I'm still here as a boring man. :)
Have you ever tested whether using "fs_initcall(sysfb_init)" works
fine on your machine?
Huacai
On Wed, Jan 24, 2024 at 5:21 AM Jaak Ristioja wrote:
>
> Hi,
>
> I apologize for not finding the time to test this earlier.
>
> On 11.12.23 05:08, Huacai Chen wrote:
> > And Jaak, could you please test with the below patch (but keep the
> > original order in Makefile) and then give me the dmesg output?
> >
> > diff --git a/drivers/video/aperture.c b/drivers/video/aperture.c
> > index 561be8feca96..cc2e39fb98f5 100644
> > --- a/drivers/video/aperture.c
> > +++ b/drivers/video/aperture.c
> > @@ -350,21 +350,29 @@ int
> > aperture_remove_conflicting_pci_devices(struct pci_dev *pdev, const
> > char *na
> > resource_size_t base, size;
> > int bar, ret = 0;
> >
> > - if (pdev == vga_default_device())
> > + printk("DEBUG: remove 1\n");
> > +
> > + if (pdev == vga_default_device()) {
> > + printk("DEBUG: primary = true\n");
> > primary = true;
> > + }
> >
> > - if (primary)
> > + if (primary) {
> > + printk("DEBUG: disable sysfb\n");
> > sysfb_disable();
> > + }
> >
> > for (bar = 0; bar < PCI_STD_NUM_BARS; ++bar) {
> > if (!(pci_resource_flags(pdev, bar) & IORESOURCE_MEM))
> > continue;
> >
> > + printk("DEBUG: remove 2\n");
> > base = pci_resource_start(pdev, bar);
> > size = pci_resource_len(pdev, bar);
> > aperture_detach_devices(base, size);
> > }
> >
> > + printk("DEBUG: remove 3\n");
> > /*
> > * If this is the primary adapter, there could be a VGA device
> > * that consumes the VGA framebuffer I/O range. Remove this
> >
> > [1]
> > https://lore.kernel.org/lkml/170222766284.86103.11020060769330721...@leemhuis.info/T/#u
>
> Copy-pasting this from the e-mail body didn't work well, but I applied
> the changes manually to a 6.5.9 kernel without any of the other patches.
> Here's the relevant dmesg output on the Lenovo L570:
>
> ...
> [2.953405] ACPI: bus type drm_connector registered
> [2.954014] i915 :00:02.0: [drm] VT-d active for gfx access
> [2.954018] DEBUG: remove 1
> [2.954020] DEBUG: remove 2
> [2.954021] DEBUG: remove 2
> [2.954023] DEBUG: remove 3
> [2.954029] resource: resource sanity check: requesting [mem
> 0xe000-0xefff], which spans more than BOOTFB
> [mem 0xe000-0xe012bfff]
> [2.954035] caller i915_ggtt_init_hw+0x88/0x120 mapping multiple BARs
> [2.954061] i915 :00:02.0: [drm] Using Transparent Hugepages
> [2.955103] Loading firmware: i915/kbl_dmc_ver1_04.bin
> [2.955384] i915 :00:02.0: [drm] Finished loading DMC firmware
> i915/kbl_dmc_ver1_04.bin (v1.4)
> ...
> [4.145013] [drm] Initialized i915 1.6.0 20201103 for :00:02.0 on
> minor 0
> [4.147101] ACPI: video: Video Device [GFX0] (multi-head: yes rom:
> no post: no)
> [4.147244] input: Video Bus as
> /devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/LNXVIDEO:00/input/input4
> [4.147410] [drm] Initialized vgem 1.0.0 20120112 for vgem on minor 1
> [4.147420] usbcore: registered new interface driver udl
> [4.147500] [drm] Initialized simpledrm 1.0.0 20200625 for
> simple-framebuffer.0 on minor 2
> [4.148643] Console: switching to colour frame buffer device 80x30
> [4.153216] simple-framebuffer simple-framebuffer.0: [drm] fb0:
> simpledrmdrmfb frame buffer device
> [4.154043] loop: module loaded
> [4.156017] ahci :00:17.0: version 3.0
> [4.157373] i915 :00:02.0: [drm] fb1: i915drmfb frame buffer device
> ...
>
> J
>
Re: [PATCH v17 0/9] Enable Adaptive Sync SDP Support for DP
On Mon, 11 Mar 2024, Mitul Golani wrote: > An Adaptive-Sync-capable DP protocol converter indicates its > support by setting the related bit in the DPCD register. This > is valid for DP and edp as well. > > Computes AS SDP values based on the display configuration, > ensuring proper handling of Variable Refresh Rate (VRR) > in the context of Adaptive Sync. [snip] > Mitul Golani (9): > drm/dp: Add support to indicate if sink supports AS SDP > drm: Add Adaptive Sync SDP logging Maarten, Maxime, Thomas, ack for merging these two patches via drm-intel-next? BR, Jani. > drm/i915/display: Add crtc state dump for Adaptive Sync SDP > drm/i915/dp: Add Read/Write support for Adaptive Sync SDP > drm/i915/dp: Add wrapper function to check AS SDP > drm/i915/display: Compute AS SDP parameters > drm/i915/display: Add state checker for Adaptive Sync SDP > drm/i915/display: Compute vrr_vsync params > drm/i915/display: Read/Write Adaptive Sync SDP > > drivers/gpu/drm/display/drm_dp_helper.c | 37 ++ > .../drm/i915/display/intel_crtc_state_dump.c | 13 ++ > drivers/gpu/drm/i915/display/intel_ddi.c | 1 + > drivers/gpu/drm/i915/display/intel_display.c | 48 +++ > .../drm/i915/display/intel_display_device.h | 1 + > .../drm/i915/display/intel_display_types.h| 2 + > drivers/gpu/drm/i915/display/intel_dp.c | 125 ++ > drivers/gpu/drm/i915/display/intel_dp.h | 1 + > drivers/gpu/drm/i915/display/intel_hdmi.c | 14 +- > drivers/gpu/drm/i915/display/intel_vrr.c | 30 - > drivers/gpu/drm/i915/i915_reg.h | 15 +++ > include/drm/display/drm_dp.h | 11 ++ > include/drm/display/drm_dp_helper.h | 30 + > 13 files changed, 325 insertions(+), 3 deletions(-) -- Jani Nikula, Intel
Re: [v3,5/5] drm/xe: Enable 32bits build
On 3/18/24 06:28, Lucas De Marchi wrote: On Sun, Mar 17, 2024 at 09:14:14AM -0700, Guenter Roeck wrote: Hi, On Thu, Jan 18, 2024 at 04:16:12PM -0800, Lucas De Marchi wrote: Now that all the issues with 32bits are fixed, enable it again. Reviewed-by: Matt Roper Signed-off-by: Lucas De Marchi --- drivers/gpu/drm/xe/Kconfig | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/xe/Kconfig b/drivers/gpu/drm/xe/Kconfig index 1b57ae38210d..1b0ef91a5d2c 100644 --- a/drivers/gpu/drm/xe/Kconfig +++ b/drivers/gpu/drm/xe/Kconfig @@ -1,7 +1,7 @@ # SPDX-License-Identifier: GPL-2.0-only config DRM_XE tristate "Intel Xe Graphics" - depends on DRM && PCI && MMU && (m || (y && KUNIT=y)) && 64BIT + depends on DRM && PCI && MMU && (m || (y && KUNIT=y)) I am curious about changes like this. Enabling 32-bit builds results in build failures for mips_allmodconfig because the driver redefines END. END is also used as macro in assembler code, the define happens to be included for mips builds, and it would be difficult to change it there. Unlike the i915 code, DRM_XE is not marked as depending on x86. This means it will be built for pretty much all "allmodconfig" builds for all architectures. Yet, there have been recent complaints about "allmodconfig" builds of drm code causing build failures on "oddball" architectures. Is there an assumption that DRM_XE (or DRM in general) is manually excluded from all architectures where it fails to build ? If so, would for all the reports we've been receiving we fixed the build and improved CI to try to avoid the regressions. DRM_XE doesn't really depend on x86, but I see your point of filtering out the "oddball architectures" or just expose the ones we know it builds against. Yet, I don't see that approach done in the wild in other drivers. At least on the build side, we constantly check the reports from lkp like https://lore.kernel.org/all/202403152008.klwyyggo-...@intel.com/ which also includes mips: mips allnoconfig gcc mips allyesconfig gcc is that not sufficient? allyesconfig should be covering it afaics All I can say is that drivers/gpu/drm/xe/xe_lrc.c doesn't build for mips builds in the mainline kernel. This is for both allmodconfig and allyesconfig. Both automatically build 32-bit kernels. Those builds are only enabled with this commit. The problem is also seen with 64-bit builds, but those are not enabled with allmodconfig/alldefconfig. I don't know what and how exactly 0-day runs its tests, but the failure is also seen in the drm-xe-next branch. I am going to blame this on my environment and just exclude DRM_XE from mips test builds going forward. Thanks, Guenter
Re: [PATCH] drm/panthor: Fix the CONFIG_PM=n case
On 18/03/2024 14:18, Boris Brezillon wrote: > On Mon, 18 Mar 2024 13:49:52 + > Steven Price wrote: > >> On 18/03/2024 13:08, Boris Brezillon wrote: >>> On Mon, 18 Mar 2024 11:31:05 + >>> Steven Price wrote: >>> On 18/03/2024 08:58, Boris Brezillon wrote: > Putting a hard dependency on CONFIG_PM is not possible because of a > circular dependency issue, and it's actually not desirable either. In > order to support this use case, we forcibly resume at init time, and > suspend at unplug time. > > Reported-by: kernel test robot > Closes: > https://lore.kernel.org/oe-kbuild-all/202403031944.eoimq8wk-...@intel.com/ > Signed-off-by: Boris Brezillon Reviewed-by: Steven Price > --- > Tested by faking CONFIG_PM=n in the driver (basically commenting > all pm_runtime calls, and making the panthor_device_suspend/resume() > calls unconditional in the panthor_device_unplug/init() path) since > CONFIG_ARCH_ROCKCHIP selects CONFIG_PM. Seems to work fine, but I > can't be 100% sure this will work correctly on a platform that has > CONFIG_PM=n. The same - I can't test this properly :( Note that the other option (which AFAICT doesn't cause any problems) is to "select PM" rather than depend on it - AIUI the 'select' dependency is considered in the opposite direction by kconfig so won't cause the dependency loop. >>> >>> Doesn't seem to work with COMPILE_TEST though? I mean, we need >>> something like >>> >>> depends on ARM || ARM64 || (COMPILE_TEST && PM) >>> ... >>> select PM >>> >>> but kconfig doesn't like that >> >> Why do we need the "&& PM" part? Just: >> >> depends on ARM || ARM64 || COMPILE_TEST >> ... >> select PM >> >> Or at least that appears to work for me. > > Uh, you're right, sorry for the brain fart. This is being said, I > see no other driver selecting the PM option directly (if you grep for > 'select PM' in drivers/, you'll find occurrences in drivers/soc, but > those are under ARCH_/SOC_ options, which means they are indirectly > arch/platform dependent, not driver dependent). I'm really not sure > selecting PM here from a driver is right to be honest. Yeah, I'm not very convinced about that either. It's just a pain that the code is going to go untested. >> >>> drivers/gpu/drm/panthor/Kconfig:3:error: recursive dependency detected! >>> drivers/gpu/drm/panthor/Kconfig:3: symbol DRM_PANTHOR depends on >>> PM kernel/power/Kconfig:183:symbol PM is selected by DRM_PANTHOR >>> >>> which id why I initially when for a depends on PM >>> >>> Of course if there is actually anyone who has a platform which can be built !CONFIG_PM then that won't help. But the inability of anyone to actually properly test this configuration does worry me a little. >>> >>> Well, as long as it doesn't regress the PM behavior, I think I'm happy >>> to take the risk. Worst case scenario, someone complains that this is >>> not working properly when they do the !PM bringup :-). >> >> Indeed, I've no objection to this patch - although I really should have >> compiled tested it as Robin pointed out ;) >> >> But one other thing I've noticed when compile testing it - we don't >> appear to have fully fixed the virt_to_pfn() problem. On x86 with >> COMPILE_TEST I still get an error. Looking at the code it appears that >> virt_to_pfn() isn't available on x86... it overrides asm/page.h and >> doesn't provide a definition. The definition on x86 is hiding in >> asm/xen/page.h. > > Looks like the kbuild bot didn't catch that yet :-). > >> >> Outside of arch code it's only drivers/xen that currently uses that >> function. So I guess it's probably best to do a >> PFN_DOWN(virt_to_phys(...)) instead. Or look to fix x86 :) > > Mind sending a fix for that? Yeah, I'll have a go at Robin's suggestion of storing the struct page instead. Steve
Re: [PATCH 2/5] drm/gem: Add a mountpoint parameter to drm_gem_object_init()
Not that the CC list wasn't big enough, but I'm adding MM folks
in the CC list.
On 3/18/24 11:04, Christian König wrote:
Am 18.03.24 um 14:28 schrieb Maíra Canal:
Hi Christian,
On 3/18/24 10:10, Christian König wrote:
Am 18.03.24 um 13:42 schrieb Maíra Canal:
Hi Christian,
On 3/12/24 10:48, Christian König wrote:
Am 12.03.24 um 14:09 schrieb Tvrtko Ursulin:
On 12/03/2024 10:37, Christian König wrote:
Am 12.03.24 um 11:31 schrieb Tvrtko Ursulin:
On 12/03/2024 10:23, Christian König wrote:
Am 12.03.24 um 10:30 schrieb Tvrtko Ursulin:
On 12/03/2024 08:59, Christian König wrote:
Am 12.03.24 um 09:51 schrieb Tvrtko Ursulin:
Hi Maira,
On 11/03/2024 10:05, Maíra Canal wrote:
For some applications, such as using huge pages, we might
want to have a
different mountpoint, for which we pass in mount flags that
better match
our usecase.
Therefore, add a new parameter to drm_gem_object_init()
that allow us to
define the tmpfs mountpoint where the GEM object will be
created. If
this parameter is NULL, then we fallback to
shmem_file_setup().
One strategy for reducing churn, and so the number of
drivers this patch touches, could be to add a lower level
drm_gem_object_init() (which takes vfsmount, call it
__drm_gem_object_init(), or drm__gem_object_init_mnt(), and
make drm_gem_object_init() call that one with a NULL argument.
I would even go a step further into the other direction. The
shmem backed GEM object is just some special handling as far
as I can see.
So I would rather suggest to rename all drm_gem_* function
which only deal with the shmem backed GEM object into
drm_gem_shmem_*.
That makes sense although it would be very churny. I at least
would be on the fence regarding the cost vs benefit.
Yeah, it should clearly not be part of this patch here.
Also the explanation why a different mount point helps with
something isn't very satisfying.
Not satisfying as you think it is not detailed enough to say
driver wants to use huge pages for performance? Or not
satisying as you question why huge pages would help?
That huge pages are beneficial is clear to me, but I'm missing
the connection why a different mount point helps with using
huge pages.
Ah right, same as in i915, one needs to mount a tmpfs instance
passing huge=within_size or huge=always option. Default is
'never', see man 5 tmpfs.
Thanks for the explanation, I wasn't aware of that.
Mhm, shouldn't we always use huge pages? Is there a reason for a
DRM device to not use huge pages with the shmem backend?
AFAIU, according to b901bb89324a ("drm/i915/gemfs: enable THP"),
back then the understanding was within_size may overallocate,
meaning there would be some space wastage, until the memory
pressure makes the thp code split the trailing huge page. I
haven't checked if that still applies.
Other than that I don't know if some drivers/platforms could have
problems if they have some limitations or hardcoded assumptions
when they iterate the sg list.
Yeah, that was the whole point behind my question. As far as I can
see this isn't driver specific, but platform specific.
I might be wrong here, but I think we should then probably not have
that handling in each individual driver, but rather centralized in
the DRM code.
I don't see a point in enabling THP for all shmem drivers. A huge page
is only useful if the driver is going to use it. On V3D, for example,
I only need huge pages because I need the memory contiguously allocated
to implement Super Pages. Otherwise, if we don't have the Super Pages
support implemented in the driver, I would be creating memory pressure
without any performance gain.
Well that's the point I'm disagreeing with. THP doesn't seem to
create much extra memory pressure for this use case.
As far as I can see background for the option is that files in tmpfs
usually have a varying size, so it usually isn't beneficial to
allocate a huge page just to find that the shmem file is much smaller
than what's needed.
But GEM objects have a fixed size. So we of hand knew if we need 4KiB
or 1GiB and can therefore directly allocate huge pages if they are
available and object large enough to back them with.
If the memory pressure is so high that we don't have huge pages
available the shmem code falls back to standard pages anyway.
The matter is: how do we define the point where the memory pressure is
high?
Well as driver developers/maintainers we simply don't do that. This is
the job of the shmem code.
For example, notice that in this implementation of Super Pages
for the V3D driver, I only use a Super Page if the BO is bigger than
2MB. I'm doing that because the Raspberry Pi only has 4GB of RAM
available for the GPU. If I created huge pages for every BO allocation
(and initially, I tried that), I would end up with hangs in some
applications.
Yeah, that is what I meant with the trivial optimisation to the shmem
code. Essentially when you have 2MiB+4KiB as BO
Re: [PATCH] Revert "drm/bridge: Select DRM_KMS_HELPER for DRM_PANEL_BRIDGE"
On Mon, Mar 18, 2024 at 03:16:21PM +0100, Neil Armstrong wrote:
This reverts commit e3f18b0dd1db242791afbc3bd173026163ce0ccc.
Selecting DRM_KMS_HELPER for DRM_PANEL_BRIDGE leads to:
WARNING: unmet direct dependencies detected for DRM_KMS_HELPER
Depends on [m]: HAS_IOMEM [=y] && DRM [=m]
...
and builds with CONFIG_DRM=m will fail with the above kconfig
warns and then multiple linker error.
Reported-by: Imre Deak
Reported-by: Jani Nikula
Reported-by: Ville Syrjälä
Fixes: e3f18b0dd1db ("drm/bridge: Select DRM_KMS_HELPER for DRM_PANEL_BRIDGE")
Signed-off-by: Neil Armstrong
Acked-by: Lucas De Marchi
Lucas De Marchi
Re: [PATCH] drm/panthor: Fix the CONFIG_PM=n case
On Mon, 18 Mar 2024 13:49:52 + Steven Price wrote: > On 18/03/2024 13:08, Boris Brezillon wrote: > > On Mon, 18 Mar 2024 11:31:05 + > > Steven Price wrote: > > > >> On 18/03/2024 08:58, Boris Brezillon wrote: > >>> Putting a hard dependency on CONFIG_PM is not possible because of a > >>> circular dependency issue, and it's actually not desirable either. In > >>> order to support this use case, we forcibly resume at init time, and > >>> suspend at unplug time. > >>> > >>> Reported-by: kernel test robot > >>> Closes: > >>> https://lore.kernel.org/oe-kbuild-all/202403031944.eoimq8wk-...@intel.com/ > >>> Signed-off-by: Boris Brezillon > >> > >> Reviewed-by: Steven Price > >> > >>> --- > >>> Tested by faking CONFIG_PM=n in the driver (basically commenting > >>> all pm_runtime calls, and making the panthor_device_suspend/resume() > >>> calls unconditional in the panthor_device_unplug/init() path) since > >>> CONFIG_ARCH_ROCKCHIP selects CONFIG_PM. Seems to work fine, but I > >>> can't be 100% sure this will work correctly on a platform that has > >>> CONFIG_PM=n. > >> > >> The same - I can't test this properly :( > >> > >> Note that the other option (which AFAICT doesn't cause any problems) is > >> to "select PM" rather than depend on it - AIUI the 'select' dependency > >> is considered in the opposite direction by kconfig so won't cause the > >> dependency loop. > > > > Doesn't seem to work with COMPILE_TEST though? I mean, we need > > something like > > > > depends on ARM || ARM64 || (COMPILE_TEST && PM) > > ... > > select PM > > > > but kconfig doesn't like that > > Why do we need the "&& PM" part? Just: > > depends on ARM || ARM64 || COMPILE_TEST > ... > select PM > > Or at least that appears to work for me. Uh, you're right, sorry for the brain fart. This is being said, I see no other driver selecting the PM option directly (if you grep for 'select PM' in drivers/, you'll find occurrences in drivers/soc, but those are under ARCH_/SOC_ options, which means they are indirectly arch/platform dependent, not driver dependent). I'm really not sure selecting PM here from a driver is right to be honest. > > > drivers/gpu/drm/panthor/Kconfig:3:error: recursive dependency detected! > > drivers/gpu/drm/panthor/Kconfig:3: symbol DRM_PANTHOR depends on > > PM kernel/power/Kconfig:183:symbol PM is selected by DRM_PANTHOR > > > > which id why I initially when for a depends on PM > > > > > >> Of course if there is actually anyone who has a > >> platform which can be built !CONFIG_PM then that won't help. But the > >> inability of anyone to actually properly test this configuration does > >> worry me a little. > > > > Well, as long as it doesn't regress the PM behavior, I think I'm happy > > to take the risk. Worst case scenario, someone complains that this is > > not working properly when they do the !PM bringup :-). > > Indeed, I've no objection to this patch - although I really should have > compiled tested it as Robin pointed out ;) > > But one other thing I've noticed when compile testing it - we don't > appear to have fully fixed the virt_to_pfn() problem. On x86 with > COMPILE_TEST I still get an error. Looking at the code it appears that > virt_to_pfn() isn't available on x86... it overrides asm/page.h and > doesn't provide a definition. The definition on x86 is hiding in > asm/xen/page.h. Looks like the kbuild bot didn't catch that yet :-). > > Outside of arch code it's only drivers/xen that currently uses that > function. So I guess it's probably best to do a > PFN_DOWN(virt_to_phys(...)) instead. Or look to fix x86 :) Mind sending a fix for that?
[PATCH] Revert "drm/bridge: Select DRM_KMS_HELPER for DRM_PANEL_BRIDGE"
This reverts commit e3f18b0dd1db242791afbc3bd173026163ce0ccc.
Selecting DRM_KMS_HELPER for DRM_PANEL_BRIDGE leads to:
WARNING: unmet direct dependencies detected for DRM_KMS_HELPER
Depends on [m]: HAS_IOMEM [=y] && DRM [=m]
...
and builds with CONFIG_DRM=m will fail with the above kconfig
warns and then multiple linker error.
Reported-by: Imre Deak
Reported-by: Jani Nikula
Reported-by: Ville Syrjälä
Fixes: e3f18b0dd1db ("drm/bridge: Select DRM_KMS_HELPER for DRM_PANEL_BRIDGE")
Signed-off-by: Neil Armstrong
---
drivers/gpu/drm/bridge/Kconfig | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/gpu/drm/bridge/Kconfig b/drivers/gpu/drm/bridge/Kconfig
index 1d4f010af97b..efd996f6c138 100644
--- a/drivers/gpu/drm/bridge/Kconfig
+++ b/drivers/gpu/drm/bridge/Kconfig
@@ -8,7 +8,6 @@ config DRM_BRIDGE
config DRM_PANEL_BRIDGE
def_bool y
depends on DRM_BRIDGE
- select DRM_KMS_HELPER
select DRM_PANEL
help
DRM bridge wrapper of DRM panels
---
base-commit: e3f18b0dd1db242791afbc3bd173026163ce0ccc
change-id:
20240318-revert-select-drm_kms_helper-for-drm_panel_bridge-0e4ad7c73496
Best regards,
--
Neil Armstrong
Re: [PATCH] drm/bridge: Select DRM_KMS_HELPER for DRM_PANEL_BRIDGE
On 18/03/2024 14:41, Ville Syrjälä wrote:
On Mon, Mar 18, 2024 at 12:52:10PM +0200, Jani Nikula wrote:
On Mon, 18 Mar 2024, Neil Armstrong wrote:
Hi,
On Thu, 11 Jan 2024 13:38:04 +0100, Luca Weiss wrote:
Since the kconfig symbol of DRM_PANEL_BRIDGE is only adding
bridge/panel.o to drm_kms_helper object, we need to select
DRM_KMS_HELPER to make sure the file is actually getting built.
Otherwise with certain defconfigs e.g. devm_drm_of_get_bridge will not
be properly available:
[...]
Thanks, Applied to https://gitlab.freedesktop.org/drm/misc/kernel.git
(drm-misc-fixes)
[1/1] drm/bridge: Select DRM_KMS_HELPER for DRM_PANEL_BRIDGE
https://gitlab.freedesktop.org/drm/misc/kernel/-/commit/e3f18b0dd1db242791afbc3bd173026163ce0ccc
With my kernel config, e3f18b0dd1db ("drm/bridge: Select DRM_KMS_HELPER
for DRM_PANEL_BRIDGE") leads to:
WARNING: unmet direct dependencies detected for DRM_KMS_HELPER
Depends on [m]: HAS_IOMEM [=y] && DRM [=m]
...
All the defconfigs in drm-rerere also seem to fail here.
Neil, are you using some weird .config, or did you not actually
build test this before pushing?
It definitely built fine, but my config test is not extensive and went through
it,
I'll send a revert patch ASAP.
Neil
PS. the drm-rerere defconfigs seem pretty outdated (eg. missing
tons of panel drivers). Would be good if someone could update
those to provide better coverage
Re: [PATCH 2/5] drm/gem: Add a mountpoint parameter to drm_gem_object_init()
Am 18.03.24 um 14:28 schrieb Maíra Canal:
Hi Christian,
On 3/18/24 10:10, Christian König wrote:
Am 18.03.24 um 13:42 schrieb Maíra Canal:
Hi Christian,
On 3/12/24 10:48, Christian König wrote:
Am 12.03.24 um 14:09 schrieb Tvrtko Ursulin:
On 12/03/2024 10:37, Christian König wrote:
Am 12.03.24 um 11:31 schrieb Tvrtko Ursulin:
On 12/03/2024 10:23, Christian König wrote:
Am 12.03.24 um 10:30 schrieb Tvrtko Ursulin:
On 12/03/2024 08:59, Christian König wrote:
Am 12.03.24 um 09:51 schrieb Tvrtko Ursulin:
Hi Maira,
On 11/03/2024 10:05, Maíra Canal wrote:
For some applications, such as using huge pages, we might
want to have a
different mountpoint, for which we pass in mount flags that
better match
our usecase.
Therefore, add a new parameter to drm_gem_object_init()
that allow us to
define the tmpfs mountpoint where the GEM object will be
created. If
this parameter is NULL, then we fallback to
shmem_file_setup().
One strategy for reducing churn, and so the number of
drivers this patch touches, could be to add a lower level
drm_gem_object_init() (which takes vfsmount, call it
__drm_gem_object_init(), or drm__gem_object_init_mnt(), and
make drm_gem_object_init() call that one with a NULL argument.
I would even go a step further into the other direction. The
shmem backed GEM object is just some special handling as far
as I can see.
So I would rather suggest to rename all drm_gem_* function
which only deal with the shmem backed GEM object into
drm_gem_shmem_*.
That makes sense although it would be very churny. I at least
would be on the fence regarding the cost vs benefit.
Yeah, it should clearly not be part of this patch here.
Also the explanation why a different mount point helps with
something isn't very satisfying.
Not satisfying as you think it is not detailed enough to say
driver wants to use huge pages for performance? Or not
satisying as you question why huge pages would help?
That huge pages are beneficial is clear to me, but I'm missing
the connection why a different mount point helps with using
huge pages.
Ah right, same as in i915, one needs to mount a tmpfs instance
passing huge=within_size or huge=always option. Default is
'never', see man 5 tmpfs.
Thanks for the explanation, I wasn't aware of that.
Mhm, shouldn't we always use huge pages? Is there a reason for a
DRM device to not use huge pages with the shmem backend?
AFAIU, according to b901bb89324a ("drm/i915/gemfs: enable THP"),
back then the understanding was within_size may overallocate,
meaning there would be some space wastage, until the memory
pressure makes the thp code split the trailing huge page. I
haven't checked if that still applies.
Other than that I don't know if some drivers/platforms could have
problems if they have some limitations or hardcoded assumptions
when they iterate the sg list.
Yeah, that was the whole point behind my question. As far as I can
see this isn't driver specific, but platform specific.
I might be wrong here, but I think we should then probably not have
that handling in each individual driver, but rather centralized in
the DRM code.
I don't see a point in enabling THP for all shmem drivers. A huge page
is only useful if the driver is going to use it. On V3D, for example,
I only need huge pages because I need the memory contiguously allocated
to implement Super Pages. Otherwise, if we don't have the Super Pages
support implemented in the driver, I would be creating memory pressure
without any performance gain.
Well that's the point I'm disagreeing with. THP doesn't seem to
create much extra memory pressure for this use case.
As far as I can see background for the option is that files in tmpfs
usually have a varying size, so it usually isn't beneficial to
allocate a huge page just to find that the shmem file is much smaller
than what's needed.
But GEM objects have a fixed size. So we of hand knew if we need 4KiB
or 1GiB and can therefore directly allocate huge pages if they are
available and object large enough to back them with.
If the memory pressure is so high that we don't have huge pages
available the shmem code falls back to standard pages anyway.
The matter is: how do we define the point where the memory pressure is
high?
Well as driver developers/maintainers we simply don't do that. This is
the job of the shmem code.
For example, notice that in this implementation of Super Pages
for the V3D driver, I only use a Super Page if the BO is bigger than
2MB. I'm doing that because the Raspberry Pi only has 4GB of RAM
available for the GPU. If I created huge pages for every BO allocation
(and initially, I tried that), I would end up with hangs in some
applications.
Yeah, that is what I meant with the trivial optimisation to the shmem
code. Essentially when you have 2MiB+4KiB as BO size then the shmem code
should use a 2MiB and a 4KiB page to back them, but what it currently
does is to use two 2MiB p
