Re: [PATCH 2/3] mfd: intel_soc_pmic: Rename pwm_backlight pwm-lookup to pwm_pmic_backlight
On Tue, 17 Dec 2019, Lee Jones wrote: > Hans was making the case that this was impractical for DRM, due to the > amount of churn you guys receive, hence the discussion. I'm very > pleased that this is not the case. Heh, well, it is the case, but the point is that should be our problem, not yours. ;) BR, Jani. -- Jani Nikula, Intel Open Source Graphics Center ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3 00/50] drm/omap: Replace custom display drivers with drm_bridge and drm_panel
On 18/12/2019 04:03, Laurent Pinchart wrote: Hopefully we can soon have this series landed so we can start working on top of the new bridge/connector handling. I assume it will be applied direct to drm-misc-next, so we do not have to wait extra time to get it. Tomi, how would you like to proceed ? The core patches are ready in my opinion. I can post a v4 without the omapdrm patches, which could be merged to drm-misc already while you finish reviewing patches 30/50 onwards. This sounds good to me. I have tested your branch on AM5 EMV, AM4 EVM and Panda, without any issues. But that's with the omapdrm patches, and things will be slightly different without them. You add TPD12S015 and OPA362 driver in the earlier part. Should those be moved to the omapdrm side? In theory there won't be any issues, but having multiple drivers for the same device can create conflicts. Tomi -- Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3 10/50] drm/bridge: simple-bridge: Add support for the TI OP362
On 11/12/2019 00:57, Laurent Pinchart wrote: The TI OP362 is an analog video amplifier controlled through a GPIO. Add support for it to the simple-bridge driver. Noticed just now, you have "OP" instead of "OPA" above and in the subject. Tomi -- Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3 11/50] drm/bridge: Add bridge driver for display connectors
On 18/12/2019 03:45, Laurent Pinchart wrote: + dev_info(&pdev->dev, +"Found %s display connector '%s' %s DDC bus and %s HPD GPIO (ops 0x%x)\n", +drm_get_connector_type_name(conn->bridge.type), +conn->label ? conn->label : "", +conn->bridge.ddc ? "with" : "without", +conn->hpd_gpio ? "with" : "without", +conn->bridge.ops); On AM5 EVM, we have HDMI output with DDC and HPD, but I get a kernel print: display-connector connector: Found HDMI-A display connector 'hdmi' without DDC bus and without HPD GPIO (ops 0x0) I think that print may be quite confusing for someone who doesn't know the details of the drivers involved. I agree, but the information could be useful for developers. Do you think it should be dropped ? Or do you have an alternative wording to propose ? I would just go with dev_dbg. I personally don't like to use dev_info unless it's really something a normal user needs to see. Otherwise it's just spam for most of the people. If everything is fine, I think the driver should be quiet. Did we discuss this already earlier? =) That said, even as a dev_dbg it's somewhat confusing. But I can't come up with alternate working... Somehow it should indicate that this piece of the display pipeline doesn't handle DDC/HPD, without implying that there are no such features. "unassigned DDC"? I don't know... I'm fine with the print as dev_dbg. Tomi -- Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/4] dt-binds: display: mediatek: add property to control mipi tx drive current
Hi, Jitao:
On Mon, 2019-12-16 at 16:29 +0800, Jitao Shi wrote:
> Add a property to control mipi tx drive current:
> "mipitx-current-drive"
>
> Signed-off-by: Jitao Shi
> ---
> .../devicetree/bindings/display/mediatek/mediatek,dsi.txt | 4
> 1 file changed, 4 insertions(+)
>
> diff --git
> a/Documentation/devicetree/bindings/display/mediatek/mediatek,dsi.txt
> b/Documentation/devicetree/bindings/display/mediatek/mediatek,dsi.txt
> index a19a6cc375ed..780201ddcd5c 100644
> --- a/Documentation/devicetree/bindings/display/mediatek/mediatek,dsi.txt
> +++ b/Documentation/devicetree/bindings/display/mediatek/mediatek,dsi.txt
> @@ -33,6 +33,9 @@ Required properties:
> - #clock-cells: must be <0>;
> - #phy-cells: must be <0>.
>
> +Optional properties:
> +- mipitx-current-drive: adjust driving current, should be 1 ~ 0xF
> +
In "[PATCH 3/4] drm/mediatek: add the mipitx driving control" [1], I see
that you actually control a register its name is MIPITX_VOLTAGE_SEL, so
I guess this control the voltage. If mipi_tx has the ability to control
the voltage, could we just treat mipi_tx as a regulator? For a
regulator, regulator-min-microvolt and regulator-max-microvolt would
limit the volt range and you could get it by
of_get_regulator_init_data(). If it actually control the current,
regulator-min-microamp and regulator-max-microamp could be used. I'm not
expert on this, so please give me more information on this.
[1]
http://lists.infradead.org/pipermail/linux-mediatek/2019-December/025638.html
Regards,
CK
> Example:
>
> mipi_tx0: mipi-dphy@10215000 {
> @@ -42,6 +45,7 @@ mipi_tx0: mipi-dphy@10215000 {
> clock-output-names = "mipi_tx0_pll";
> #clock-cells = <0>;
> #phy-cells = <0>;
> + mipitx-current-drive = <0x8>;
> };
>
> dsi0: dsi@1401b000 {
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 9/9] drm/bridge: ti-sn65dsi86: Avoid invalid rates
On Tue, Dec 17, 2019 at 8:01 PM Rob Clark wrote:
>
> On Tue, Dec 17, 2019 at 4:48 PM Douglas Anderson
> wrote:
> >
> > Based on work by Bjorn Andersson ,
> > Jeffrey Hugo , and
> > Rob Clark .
> >
> > Let's read the SUPPORTED_LINK_RATES and/or MAX_LINK_RATE (depending on
> > the eDP version of the sink) to figure out what eDP rates are
> > supported and pick the ideal one.
> >
> > Signed-off-by: Douglas Anderson
> > ---
> >
> > Changes in v2:
> > - Patch ("Avoid invalid rates") replaces ("Skip non-standard DP rates")
> >
> > drivers/gpu/drm/bridge/ti-sn65dsi86.c | 118 --
> > 1 file changed, 93 insertions(+), 25 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/bridge/ti-sn65dsi86.c
> > b/drivers/gpu/drm/bridge/ti-sn65dsi86.c
> > index e1b817ccd9c7..da5ddf6be92b 100644
> > --- a/drivers/gpu/drm/bridge/ti-sn65dsi86.c
> > +++ b/drivers/gpu/drm/bridge/ti-sn65dsi86.c
> > @@ -475,39 +475,103 @@ static int ti_sn_bridge_calc_min_dp_rate_idx(struct
> > ti_sn_bridge *pdata)
> > return i;
> > }
> >
> > -static int ti_sn_bridge_get_max_dp_rate_idx(struct ti_sn_bridge *pdata)
> > +static void ti_sn_bridge_read_valid_rates(struct ti_sn_bridge *pdata,
> > + bool rate_valid[])
> > {
> > - u8 data;
> > + u8 dpcd_val;
> > + int rate_times_200khz;
> > int ret;
> > + int i;
> >
> > - ret = drm_dp_dpcd_readb(&pdata->aux, DP_MAX_LINK_RATE, &data);
> > + ret = drm_dp_dpcd_readb(&pdata->aux, DP_EDP_DPCD_REV, &dpcd_val);
> > + if (ret != 1) {
> > + DRM_DEV_ERROR(pdata->dev,
> > + "Can't read eDP rev (%d), assuming 1.1\n",
> > ret);
> > + dpcd_val = DP_EDP_11;
> > + }
> > +
> > + if (dpcd_val >= DP_EDP_14) {
> > + /* eDP 1.4 devices must provide a custom table */
> > + __le16 sink_rates[DP_MAX_SUPPORTED_RATES];
> > +
> > + ret = drm_dp_dpcd_read(&pdata->aux, DP_SUPPORTED_LINK_RATES,
> > + sink_rates, sizeof(sink_rates));
> > +
> > + if (ret != sizeof(sink_rates)) {
> > + DRM_DEV_ERROR(pdata->dev,
> > + "Can't read supported rate table (%d)\n",
> > ret);
> > +
> > + /* By zeroing we'll fall back to DP_MAX_LINK_RATE.
> > */
> > + memset(sink_rates, 0, sizeof(sink_rates));
> > + }
> > +
> > + for (i = 0; i < ARRAY_SIZE(sink_rates); i++) {
> > + rate_times_200khz = le16_to_cpu(sink_rates[i]);
> > +
> > + if (!rate_times_200khz)
> > + break;
> > +
> > + switch (rate_times_200khz) {
> > + case 27000:
>
> maybe a bit bike-sheddy, but I kinda prefer to use traditional normal
> units, ie. just multiply the returned value by 200 and adjust the
> switch case values. At least then they match the values in the lut
> (other than khz vs mhz), which makes this whole logic a bit more
> obvious... and at that point, maybe just loop over the lut table?
(hit SEND too soon)
and other than that, lgtm but haven't had a chance to test it yet
(although I guess none of us have an eDP 1.4+ screen so maybe that is
moot :-))
BR,
-R
> BR,
> -R
>
> > + rate_valid[7] = 1;
> > + break;
> > + case 21600:
> > + rate_valid[6] = 1;
> > + break;
> > + case 16200:
> > + rate_valid[5] = 1;
> > + break;
> > + case 13500:
> > + rate_valid[4] = 1;
> > + break;
> > + case 12150:
> > + rate_valid[3] = 1;
> > + break;
> > + case 10800:
> > + rate_valid[2] = 1;
> > + break;
> > + case 8100:
> > + rate_valid[1] = 1;
> > + break;
> > + default:
> > + /* unsupported */
> > + break;
> > + }
> > + }
> > +
> > + for (i = 0; i < ARRAY_SIZE(ti_sn_bridge_dp_rate_lut); i++) {
> > + if (rate_valid[i])
> > + return;
> > + }
> > + DRM_DEV_ERROR(pdata->dev,
> > + "No matching eDP rates in table; falling
> > back\n");
> > + }
> > +
> > + /* On older versions best we can do is use DP_MAX_LINK_RATE */
> > + ret = drm_dp_dpcd_readb(&pdata->aux, DP_MAX_LINK_RATE, &dpc
Re: [PATCH v2 9/9] drm/bridge: ti-sn65dsi86: Avoid invalid rates
On Tue, Dec 17, 2019 at 4:48 PM Douglas Anderson wrote:
>
> Based on work by Bjorn Andersson ,
> Jeffrey Hugo , and
> Rob Clark .
>
> Let's read the SUPPORTED_LINK_RATES and/or MAX_LINK_RATE (depending on
> the eDP version of the sink) to figure out what eDP rates are
> supported and pick the ideal one.
>
> Signed-off-by: Douglas Anderson
> ---
>
> Changes in v2:
> - Patch ("Avoid invalid rates") replaces ("Skip non-standard DP rates")
>
> drivers/gpu/drm/bridge/ti-sn65dsi86.c | 118 --
> 1 file changed, 93 insertions(+), 25 deletions(-)
>
> diff --git a/drivers/gpu/drm/bridge/ti-sn65dsi86.c
> b/drivers/gpu/drm/bridge/ti-sn65dsi86.c
> index e1b817ccd9c7..da5ddf6be92b 100644
> --- a/drivers/gpu/drm/bridge/ti-sn65dsi86.c
> +++ b/drivers/gpu/drm/bridge/ti-sn65dsi86.c
> @@ -475,39 +475,103 @@ static int ti_sn_bridge_calc_min_dp_rate_idx(struct
> ti_sn_bridge *pdata)
> return i;
> }
>
> -static int ti_sn_bridge_get_max_dp_rate_idx(struct ti_sn_bridge *pdata)
> +static void ti_sn_bridge_read_valid_rates(struct ti_sn_bridge *pdata,
> + bool rate_valid[])
> {
> - u8 data;
> + u8 dpcd_val;
> + int rate_times_200khz;
> int ret;
> + int i;
>
> - ret = drm_dp_dpcd_readb(&pdata->aux, DP_MAX_LINK_RATE, &data);
> + ret = drm_dp_dpcd_readb(&pdata->aux, DP_EDP_DPCD_REV, &dpcd_val);
> + if (ret != 1) {
> + DRM_DEV_ERROR(pdata->dev,
> + "Can't read eDP rev (%d), assuming 1.1\n", ret);
> + dpcd_val = DP_EDP_11;
> + }
> +
> + if (dpcd_val >= DP_EDP_14) {
> + /* eDP 1.4 devices must provide a custom table */
> + __le16 sink_rates[DP_MAX_SUPPORTED_RATES];
> +
> + ret = drm_dp_dpcd_read(&pdata->aux, DP_SUPPORTED_LINK_RATES,
> + sink_rates, sizeof(sink_rates));
> +
> + if (ret != sizeof(sink_rates)) {
> + DRM_DEV_ERROR(pdata->dev,
> + "Can't read supported rate table (%d)\n",
> ret);
> +
> + /* By zeroing we'll fall back to DP_MAX_LINK_RATE. */
> + memset(sink_rates, 0, sizeof(sink_rates));
> + }
> +
> + for (i = 0; i < ARRAY_SIZE(sink_rates); i++) {
> + rate_times_200khz = le16_to_cpu(sink_rates[i]);
> +
> + if (!rate_times_200khz)
> + break;
> +
> + switch (rate_times_200khz) {
> + case 27000:
maybe a bit bike-sheddy, but I kinda prefer to use traditional normal
units, ie. just multiply the returned value by 200 and adjust the
switch case values. At least then they match the values in the lut
(other than khz vs mhz), which makes this whole logic a bit more
obvious... and at that point, maybe just loop over the lut table?
BR,
-R
> + rate_valid[7] = 1;
> + break;
> + case 21600:
> + rate_valid[6] = 1;
> + break;
> + case 16200:
> + rate_valid[5] = 1;
> + break;
> + case 13500:
> + rate_valid[4] = 1;
> + break;
> + case 12150:
> + rate_valid[3] = 1;
> + break;
> + case 10800:
> + rate_valid[2] = 1;
> + break;
> + case 8100:
> + rate_valid[1] = 1;
> + break;
> + default:
> + /* unsupported */
> + break;
> + }
> + }
> +
> + for (i = 0; i < ARRAY_SIZE(ti_sn_bridge_dp_rate_lut); i++) {
> + if (rate_valid[i])
> + return;
> + }
> + DRM_DEV_ERROR(pdata->dev,
> + "No matching eDP rates in table; falling
> back\n");
> + }
> +
> + /* On older versions best we can do is use DP_MAX_LINK_RATE */
> + ret = drm_dp_dpcd_readb(&pdata->aux, DP_MAX_LINK_RATE, &dpcd_val);
> if (ret != 1) {
> DRM_DEV_ERROR(pdata->dev,
> "Can't read max rate (%d); assuming 5.4 GHz\n",
> ret);
> - return ARRAY_SIZE(ti_sn_bridge_dp_rate_lut) - 1;
> + dpcd_val = DP_LINK_BW_5_4;
> }
>
> - /*
> -* Return an index into ti_sn_bridge_dp_rate_lut. Just hardcode
> -* these indicies since it's not like the register spe
Re: [PATCH v3 00/50] drm/omap: Replace custom display drivers with drm_bridge and drm_panel
Hi Sam, On Sun, Dec 15, 2019 at 01:27:28PM +0100, Sam Ravnborg wrote: > Hi Laurent. > > I have now been through this impressive series of patches. > It is a nice series properly split into small readable chunks. > A few nits in a few patches - already sent by separate mails. > > Patch 2,4,13 (with nits addressed): > Reviewed-by: Sam Ravnborg > > Patch 1-20 (except the ones with r-b): > Acked-by: Sam Ravnborg > > I have browsed the remaining omap related patches. > Everything looked good but as I am not familiar with the code > so I can have missed something obvious. Thank you very much. > Hopefully we can soon have this series landed so we can start > working on top of the new bridge/connector handling. > > I assume it will be applied direct to drm-misc-next, so we do not > have to wait extra time to get it. Tomi, how would you like to proceed ? The core patches are ready in my opinion. I can post a v4 without the omapdrm patches, which could be merged to drm-misc already while you finish reviewing patches 30/50 onwards. -- Regards, Laurent Pinchart ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3 35/50] drm/omap: Create connector for bridges
Hi Sam,
Thank you for the review.
On Sun, Dec 15, 2019 at 11:00:18AM +0100, Sam Ravnborg wrote:
> On Wed, Dec 11, 2019 at 12:57:35AM +0200, Laurent Pinchart wrote:
> > Use the drm_bridge_connector helper to create a connector for pipelines
> > that use drm_bridge. This allows splitting connector operations across
> > multiple bridges when necessary, instead of having the last bridge in
> > the chain creating the connector and handling all connector operations
> > internally.
> >
> > Signed-off-by: Laurent Pinchart
> > ---
> > Changes since v1:
> >
> > - Squash with patch "drm/omap: Detach from panels at remove time"
> > ---
> > drivers/gpu/drm/omapdrm/omap_drv.c | 79 +-
> > 1 file changed, 67 insertions(+), 12 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/omapdrm/omap_drv.c
> > b/drivers/gpu/drm/omapdrm/omap_drv.c
> > index 1df509342b5d..097fbbaa5df0 100644
> > --- a/drivers/gpu/drm/omapdrm/omap_drv.c
> > +++ b/drivers/gpu/drm/omapdrm/omap_drv.c
> > @@ -12,10 +12,12 @@
> > #include
> > #include
> > #include
> > +#include
> > #include
> > #include
> > #include
> > #include
> > +#include
> > #include
> > #include
> > #include
> > @@ -291,9 +293,14 @@ static int omap_modeset_init(struct drm_device *dev)
> >
> > if (pipe->output->bridge) {
> > ret = drm_bridge_attach(pipe->encoder,
> > - pipe->output->bridge, NULL, 0);
> > - if (ret < 0)
> > + pipe->output->bridge, NULL,
> > + DRM_BRIDGE_ATTACH_NO_CONNECTOR);
> > + if (ret < 0) {
> > + dev_err(priv->dev,
> > + "unable to attach bridge %pOF\n",
> > + pipe->output->bridge->of_node);
> > return ret;
> > + }
> > }
> >
> > id = omap_display_id(pipe->output);
> > @@ -329,8 +336,28 @@ static int omap_modeset_init(struct drm_device *dev)
> > encoder);
> > if (!pipe->connector)
> > return -ENOMEM;
> > + } else {
> > + pipe->connector = drm_bridge_connector_init(dev,
> > encoder);
> > + if (IS_ERR(pipe->connector)) {
> > + dev_err(priv->dev,
> > + "unable to create bridge connector for
> > %s\n",
> > + pipe->output->name);
> > + return PTR_ERR(pipe->connector);
> > + }
> > + }
> >
> > - drm_connector_attach_encoder(pipe->connector, encoder);
> > + drm_connector_attach_encoder(pipe->connector, encoder);
> > +
> > + /*
> > +* FIXME: drm_panel should not store the drm_connector pointer
> > +* internally but should receive it in its .get_modes()
> > +* operation.
> > +*/
>
> This FIXME is not fully up-to-date.
> drm_panel_attach ignores the connector argumant, and we could also pass
> NULL here.
You're right, I'll remove the comment.
> I am not convinced we need the drm_panel_(attach|detach) anymore, but
> this is not the thread to take that discussion.
Indeed :-) I think we should replace all direct panel usage with the DRM
panel bridge, then we'll be able to refactor the panel API freely.
--
Regards,
Laurent Pinchart
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3 11/50] drm/bridge: Add bridge driver for display connectors
Hi Sam,
Thank you for the review.
On Sun, Dec 15, 2019 at 01:03:31PM +0100, Sam Ravnborg wrote:
> Hi Laurent.
>
> One nit below.
>
> > +
> > +struct display_connector {
> > + struct drm_bridge bridge;
> > +
> > + const char *label;
>
> label is defined here.
>
> > + struct gpio_desc*hpd_gpio;
> > + int hpd_irq;
> > +};
> > +
> ...
> > +
> > + /* Get the optional connector label. */
> > + of_property_read_string(pdev->dev.of_node, "label", &conn->label);
>
> Assinged here.
>
> > +
> > + /*
> > +* Get the HPD GPIO for DVI and HDMI connectors. If the GPIO can provide
> > +* edge interrupts, register an interrupt handler.
> > +*/
>...
> > +
> > + dev_info(&pdev->dev,
> > +"Found %s display connector '%s' %s DDC bus and %s HPD GPIO
> > (ops 0x%x)\n",
> > +drm_get_connector_type_name(conn->bridge.type),
> > +conn->label ? conn->label : "",
> > +conn->bridge.ddc ? "with" : "without",
> > +conn->hpd_gpio ? "with" : "without",
> > +conn->bridge.ops);
>
> And this is the only user - within the same function where label is
> assigned.
> We could use a loacal variable, no need to have it in struct display_connector
> unless futher use is planned.
Agreed, I'll move the field to a local variable. We can always move it
back to the display_connector structure later if needed.
--
Regards,
Laurent Pinchart
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3 11/50] drm/bridge: Add bridge driver for display connectors
Hi Tomi, On Mon, Dec 16, 2019 at 03:11:23PM +0200, Tomi Valkeinen wrote: > On 11/12/2019 00:57, Laurent Pinchart wrote: > > Display connectors are modelled in DT as a device node, but have so far > > been handled manually in several bridge drivers. This resulted in > > duplicate code in several bridge drivers, with slightly different (and > > thus confusing) logics. > > > > In order to fix this, implement a bridge driver for display connectors. > > The driver centralises logic for the DVI, HDMI, VGAn composite and > > S-video connectors and exposes corresponding bridge operations. > > > > This driver in itself doesn't solve the issue completely, changes in > > bridge and display controller drivers are needed to make use of the new > > connector driver. > > > > Signed-off-by: Laurent Pinchart > > Reviewed-by: Maxime Ripard > > --- > > Changes since v2: > > > > - Fall back to polling if the GPIO IRQ chip doesn't support > >edge-triggered interrupts > > > > Changes since v1: > > > > - Use drm_get_connector_type_name() instead of open-coding > >display_connector_type_name() > > - Remove empty .hpd_enable() and .hpd_disable() operations > > - Set bridge.ddc > > --- > > drivers/gpu/drm/bridge/Kconfig | 11 + > > drivers/gpu/drm/bridge/Makefile| 1 + > > drivers/gpu/drm/bridge/display-connector.c | 292 + > > 3 files changed, 304 insertions(+) > > create mode 100644 drivers/gpu/drm/bridge/display-connector.c > > > > > + dev_info(&pdev->dev, > > +"Found %s display connector '%s' %s DDC bus and %s HPD GPIO > > (ops 0x%x)\n", > > +drm_get_connector_type_name(conn->bridge.type), > > +conn->label ? conn->label : "", > > +conn->bridge.ddc ? "with" : "without", > > +conn->hpd_gpio ? "with" : "without", > > +conn->bridge.ops); > > On AM5 EVM, we have HDMI output with DDC and HPD, but I get a kernel print: > > display-connector connector: Found HDMI-A display connector 'hdmi' without > DDC bus and without HPD > GPIO (ops 0x0) > > I think that print may be quite confusing for someone who doesn't know the > details of the drivers > involved. I agree, but the information could be useful for developers. Do you think it should be dropped ? Or do you have an alternative wording to propose ? -- Regards, Laurent Pinchart ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3 05/50] drm/bridge: Extend bridge API to disable connector creation
Hi Tomi,
On Tue, Dec 17, 2019 at 02:12:59PM +0200, Tomi Valkeinen wrote:
> On 11/12/2019 00:57, Laurent Pinchart wrote:
> > Most bridge drivers create a DRM connector to model the connector at the
> > output of the bridge. This model is historical and has worked pretty
> > well so far, but causes several issues:
> >
> > - It prevents supporting more complex display pipelines where DRM
> > connector operations are split over multiple components. For instance a
> > pipeline with a bridge connected to the DDC signals to read EDID data,
> > and another one connected to the HPD signal to detect connection and
> > disconnection, will not be possible to support through this model.
> >
> > - It requires every bridge driver to implement similar connector
> > handling code, resulting in code duplication.
> >
> > - It assumes that a bridge will either be wired to a connector or to
> > another bridge, but doesn't support bridges that can be used in both
> > positions very well (although there is some ad-hoc support for this in
> > the analogix_dp bridge driver).
> >
> > In order to solve these issues, ownership of the connector should be
> > moved to the display controller driver (where it can be implemented
> > using helpers provided by the core).
> >
> > Extend the bridge API to allow disabling connector creation in bridge
> > drivers as a first step towards the new model. The new flags argument to
> > the bridge .attach() operation allows instructing the bridge driver to
> > skip creating a connector. Unconditionally set the new flags argument to
> > 0 for now to keep the existing behaviour, and modify all existing bridge
> > drivers to return an error when connector creation is not requested as
> > they don't support this feature yet.
> >
> > The change is based on the following semantic patch, with manual review
> > and edits.
> >
> > @ rule1 @
> > identifier funcs;
> > identifier fn;
> > @@
> > struct drm_bridge_funcs funcs = {
> > ...,
> > .attach = fn
> > };
> >
> > @ depends on rule1 @
> > identifier rule1.fn;
> > identifier bridge;
> > statement S, S1;
> > @@
> > int fn(
> > struct drm_bridge *bridge
> > + , enum drm_bridge_attach_flags flags
> > )
> > {
> > ... when != S
> > + if (flags & DRM_BRIDGE_ATTACH_NO_CONNECTOR)
> > + return -EINVAL;
> > +
>
> Should there be a dev_err or such here? This should only happen when your
> setting up a new board,
> and you try to use a bridge that doesn't support no-connector-mode yet, right?
>
> I hit this when trying out AM4 EVM with SiI9022 driver. It wasn't too
> difficult to pinpoint where
> the failure happens, but an error would have made it immediately obvious.
I hate that you're right as it forces me to re-review the change
manually :-) I'll fix this.
--
Regards,
Laurent Pinchart
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3 04/50] drm/bridge: Add connector-related bridge operations and data
Hi Sam,
Thank you for the review.
On Sun, Dec 15, 2019 at 11:22:44AM +0100, Sam Ravnborg wrote:
> > /**
> > * struct drm_bridge_funcs - drm_bridge control functions
> > @@ -338,6 +343,119 @@ struct drm_bridge_funcs {
> > */
> > void (*atomic_post_disable)(struct drm_bridge *bridge,
> > struct drm_atomic_state *old_state);
> > +
> > + /**
> > +* @detect:
> > +*
> > +* Check if anything is attached to the bridge output.
> > +*
> > +* This callback is optional, if not implemented the bridge will be
> > +* considered as always having a component attached to its output.
> > +* Bridges that implement this callback shall set the
> > +* DRM_BRIDGE_OP_DETECT flag in their &drm_bridge->ops.
> > +*
> > +* RETURNS:
> > +*
> > +* drm_connector_status indicating the bridge output status.
> > +*/
> > + enum drm_connector_status (*detect)(struct drm_bridge *bridge);
> > +
> > + /**
> > +* @get_modes:
> > +*
> > +* Fill all modes currently valid for the sink into the &drm_connector
> > +* with drm_mode_probed_add().
> > +*
> > +* The @get_modes callback is mostly intended to support non-probable
>
> non-probeable?
It will be interested to see how we'll support improbable displays, but
for now I indeed want to focus on the non-probeable ones :-)
> > +* displays such as many fixed panels. Bridges that support reading
> > +* EDID shall leave @get_modes unimplemented and implement the
> > +* &drm_bridge_funcs->get_edid callback instead.
> > +*
> > +* This callback is optional. Bridges that implement it shall set the
> > +* DRM_BRIDGE_OP_MODES flag in their &drm_bridge->ops.
> > +*
> > +* The connector parameter shall be used for the sole purpose of
> > +* filling modes, and shall not be stored internally by bridge drivers
> > +* for future usage.
> > +*
> > +* RETURNS:
> > +*
> > +* The number of modes added by calling drm_mode_probed_add().
> > +*/
> > + int (*get_modes)(struct drm_bridge *bridge,
> > +struct drm_connector *connector);
> > +
> > + /**
> > +* @get_edid:
> > +*
> > +* Read and parse the EDID data of the connected display.
> > +*
> > +* The @get_edid callback is the preferred way of reporting mode
> > +* information for a display connected to the bridge output. Bridges
> > +* that support readind EDID shall implement this callback and leave
>
> s/readind/probing/? - or fix the spelling mistake.
I think I prefer reading as the operation is documented as "read and
parse the EDID".
> > +* the @get_modes callback unimplemented.
> > +*
> > +* The caller of this operation shall first verify the output
> > +* connection status and refrain from reading EDID from a disconnected
> > +* output.
> > +*
> > +* This callback is optional. Bridges that implement it shall set the
> > +* DRM_BRIDGE_OP_EDID flag in their &drm_bridge->ops.
> > +*
> > +* The connector parameter shall be used for the sole purpose of EDID
> > +* retrieval and parsing, and shall not be stored internally by bridge
> > +* drivers for future usage.
> > +*
> > +* RETURNS:
> > +*
> > +* An edid structure newly allocated with kmalloc() (or similar) on
> > +* success, or NULL otherwise. The caller is responsible for freeing
> > +* the returned edid structure with kfree().
> > +*/
> > + struct edid *(*get_edid)(struct drm_bridge *bridge,
> > +struct drm_connector *connector);
> > +
> > + /**
> > +* @hpd_notify:
> > +*
> > +* Notify the bridge of hot plug detection.
> > +*
> > +* This callback is optional, it may be implemented by bridges that
> > +* need to be notified of display connection or disconnection for
> > +* internal reasons. One use case is to reset the internal state of CEC
> > +* controllers for HDMI bridges.
> > +*/
> > + void (*hpd_notify)(struct drm_bridge *bridge,
> > + enum drm_connector_status status);
> > +
> > + /**
> > +* @hpd_enable:
> > +*
> > +* Enable hot plug detection. From now on the bridge shall call
> > +* drm_bridge_hpd_notify() each time a change is detected in the output
> > +* connection status, until hot plug detection gets disabled with
> > +* @hpd_disable.
> > +*
> > +* This callback is optional and shall only be implemented by bridges
> > +* that support hot-plug notification without polling. Bridges that
> > +* implement it shall also implement the @hpd_disable callback and set
> > +* the DRM_BRIDGE_OP_HPD flag in their &drm_bridge->ops.
> > +*/
> > + void (*hpd_enable)(struct drm_bridge *bridge);
> > +
> > + /**
> > +* @hpd_disable:
> > +*
> > +* Disable hot plug detection. Once this function returns the bridge
> > +* shall not call drm_bridge_hpd_
[PATCH 6/9] drm/virtio: move to_virtio_fence inside virtgpu_fence
That's the only file that uses it.
Signed-off-by: Gurchetan Singh
---
drivers/gpu/drm/virtio/virtgpu_drv.h | 2 --
drivers/gpu/drm/virtio/virtgpu_fence.c | 3 +++
2 files changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/virtio/virtgpu_drv.h
b/drivers/gpu/drm/virtio/virtgpu_drv.h
index 77f446608ca9..4ec80563d1ca 100644
--- a/drivers/gpu/drm/virtio/virtgpu_drv.h
+++ b/drivers/gpu/drm/virtio/virtgpu_drv.h
@@ -103,8 +103,6 @@ struct virtio_gpu_fence {
struct virtio_gpu_fence_driver *drv;
struct list_head node;
};
-#define to_virtio_fence(x) \
- container_of(x, struct virtio_gpu_fence, f)
struct virtio_gpu_vbuffer {
char *buf;
diff --git a/drivers/gpu/drm/virtio/virtgpu_fence.c
b/drivers/gpu/drm/virtio/virtgpu_fence.c
index 5466aab7d39a..5b2a4146c5bd 100644
--- a/drivers/gpu/drm/virtio/virtgpu_fence.c
+++ b/drivers/gpu/drm/virtio/virtgpu_fence.c
@@ -27,6 +27,9 @@
#include "virtgpu_drv.h"
+#define to_virtio_fence(x) \
+ container_of(x, struct virtio_gpu_fence, f)
+
static const char *virtio_get_driver_name(struct dma_fence *f)
{
return "virtio_gpu";
--
2.24.1.735.g03f4e72817-goog
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 5/9] drm/virtio: remove virtgpu_gem_prime_import_sg_table
Sharing memory between virtio devices is ill-defined, so until
we have something let's get rid of this.
drm_gem_prime_import_dev returns an error if the callback is NULL.
Signed-off-by: Gurchetan Singh
---
drivers/gpu/drm/virtio/Makefile| 2 +-
drivers/gpu/drm/virtio/virtgpu_drv.c | 3 +-
drivers/gpu/drm/virtio/virtgpu_drv.h | 5
drivers/gpu/drm/virtio/virtgpu_prime.c | 38 --
4 files changed, 2 insertions(+), 46 deletions(-)
delete mode 100644 drivers/gpu/drm/virtio/virtgpu_prime.c
diff --git a/drivers/gpu/drm/virtio/Makefile b/drivers/gpu/drm/virtio/Makefile
index 92aa2b3d349d..36d8cf8e0cec 100644
--- a/drivers/gpu/drm/virtio/Makefile
+++ b/drivers/gpu/drm/virtio/Makefile
@@ -6,6 +6,6 @@
virtio-gpu-y := virtgpu_drv.o virtgpu_kms.o virtgpu_gem.o \
virtgpu_display.o virtgpu_vq.o \
virtgpu_fence.o virtgpu_object.o virtgpu_debugfs.o virtgpu_plane.o \
- virtgpu_ioctl.o virtgpu_prime.o virtgpu_trace_points.o
+ virtgpu_ioctl.o virtgpu_trace_points.o
obj-$(CONFIG_DRM_VIRTIO_GPU) += virtio-gpu.o
diff --git a/drivers/gpu/drm/virtio/virtgpu_drv.c
b/drivers/gpu/drm/virtio/virtgpu_drv.c
index 8cf27af3ad53..e942465e4fb1 100644
--- a/drivers/gpu/drm/virtio/virtgpu_drv.c
+++ b/drivers/gpu/drm/virtio/virtgpu_drv.c
@@ -200,8 +200,7 @@ static struct drm_driver driver = {
.prime_handle_to_fd = drm_gem_prime_handle_to_fd,
.prime_fd_to_handle = drm_gem_prime_fd_to_handle,
.gem_prime_mmap = drm_gem_prime_mmap,
- .gem_prime_import_sg_table = virtgpu_gem_prime_import_sg_table,
-
+ .gem_prime_import_sg_table = NULL,
.gem_create_object = virtio_gpu_create_object,
.fops = &virtio_gpu_driver_fops,
diff --git a/drivers/gpu/drm/virtio/virtgpu_drv.h
b/drivers/gpu/drm/virtio/virtgpu_drv.h
index 8dfb39f98552..77f446608ca9 100644
--- a/drivers/gpu/drm/virtio/virtgpu_drv.h
+++ b/drivers/gpu/drm/virtio/virtgpu_drv.h
@@ -359,11 +359,6 @@ int virtio_gpu_object_create(struct virtio_gpu_device
*vgdev,
struct virtio_gpu_object_params *params,
struct virtio_gpu_object **bo_ptr,
struct virtio_gpu_fence *fence);
-/* virtgpu_prime.c */
-struct drm_gem_object *virtgpu_gem_prime_import_sg_table(
- struct drm_device *dev, struct dma_buf_attachment *attach,
- struct sg_table *sgt);
-
/* virgl debugfs */
int virtio_gpu_debugfs_init(struct drm_minor *minor);
diff --git a/drivers/gpu/drm/virtio/virtgpu_prime.c
b/drivers/gpu/drm/virtio/virtgpu_prime.c
deleted file mode 100644
index 050d24c39a8f..
--- a/drivers/gpu/drm/virtio/virtgpu_prime.c
+++ /dev/null
@@ -1,38 +0,0 @@
-/*
- * Copyright 2014 Canonical
- *
- * Permission is hereby granted, free of charge, to any person obtaining a
- * copy of this software and associated documentation files (the "Software"),
- * to deal in the Software without restriction, including without limitation
- * the rights to use, copy, modify, merge, publish, distribute, sublicense,
- * and/or sell copies of the Software, and to permit persons to whom the
- * Software is furnished to do so, subject to the following conditions:
- *
- * The above copyright notice and this permission notice shall be included in
- * all copies or substantial portions of the Software.
- *
- * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
- * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
- * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL
- * THE COPYRIGHT HOLDER(S) OR AUTHOR(S) BE LIABLE FOR ANY CLAIM, DAMAGES OR
- * OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE,
- * ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
- * OTHER DEALINGS IN THE SOFTWARE.
- *
- * Authors: Andreas Pokorny
- */
-
-#include
-
-#include "virtgpu_drv.h"
-
-/* Empty Implementations as there should not be any other driver for a virtual
- * device that might share buffers with virtgpu
- */
-
-struct drm_gem_object *virtgpu_gem_prime_import_sg_table(
- struct drm_device *dev, struct dma_buf_attachment *attach,
- struct sg_table *table)
-{
- return ERR_PTR(-ENODEV);
-}
--
2.24.1.735.g03f4e72817-goog
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 8/9] drm/virtio: split out vq functions from virtgpu_drv.h
virtgpu_drv.h is getting very big, let's try to split it into smaller header files. Start with virtgpu_vq. Signed-off-by: Gurchetan Singh --- drivers/gpu/drm/virtio/virtgpu_display.c | 1 + drivers/gpu/drm/virtio/virtgpu_drv.h | 79 -- drivers/gpu/drm/virtio/virtgpu_gem.c | 1 + drivers/gpu/drm/virtio/virtgpu_ioctl.c | 1 + drivers/gpu/drm/virtio/virtgpu_kms.c | 1 + drivers/gpu/drm/virtio/virtgpu_object.c | 1 + drivers/gpu/drm/virtio/virtgpu_plane.c | 1 + drivers/gpu/drm/virtio/virtgpu_vq.c | 1 + drivers/gpu/drm/virtio/virtgpu_vq.h | 100 +++ 9 files changed, 107 insertions(+), 79 deletions(-) create mode 100644 drivers/gpu/drm/virtio/virtgpu_vq.h diff --git a/drivers/gpu/drm/virtio/virtgpu_display.c b/drivers/gpu/drm/virtio/virtgpu_display.c index 0966208ec30d..03cd5e40bfa1 100644 --- a/drivers/gpu/drm/virtio/virtgpu_display.c +++ b/drivers/gpu/drm/virtio/virtgpu_display.c @@ -33,6 +33,7 @@ #include #include "virtgpu_drv.h" +#include "virtgpu_vq.h" #define XRES_MIN32 #define YRES_MIN32 diff --git a/drivers/gpu/drm/virtio/virtgpu_drv.h b/drivers/gpu/drm/virtio/virtgpu_drv.h index 7e447784e493..cd98df412cda 100644 --- a/drivers/gpu/drm/virtio/virtgpu_drv.h +++ b/drivers/gpu/drm/virtio/virtgpu_drv.h @@ -250,85 +250,6 @@ void virtio_gpu_array_put_free_delayed(struct virtio_gpu_device *vgdev, struct virtio_gpu_object_array *objs); void virtio_gpu_array_put_free_work(struct work_struct *work); -/* virtio vg */ -int virtio_gpu_alloc_vbufs(struct virtio_gpu_device *vgdev); -void virtio_gpu_free_vbufs(struct virtio_gpu_device *vgdev); -void virtio_gpu_cmd_create_resource(struct virtio_gpu_device *vgdev, - struct virtio_gpu_object *bo, - struct virtio_gpu_object_params *params, - struct virtio_gpu_object_array *objs, - struct virtio_gpu_fence *fence); -void virtio_gpu_cmd_unref_resource(struct virtio_gpu_device *vgdev, - uint32_t resource_id); -void virtio_gpu_cmd_transfer_to_host_2d(struct virtio_gpu_device *vgdev, - uint64_t offset, - uint32_t width, uint32_t height, - uint32_t x, uint32_t y, - struct virtio_gpu_object_array *objs, - struct virtio_gpu_fence *fence); -void virtio_gpu_cmd_resource_flush(struct virtio_gpu_device *vgdev, - uint32_t resource_id, - uint32_t x, uint32_t y, - uint32_t width, uint32_t height); -void virtio_gpu_cmd_set_scanout(struct virtio_gpu_device *vgdev, - uint32_t scanout_id, uint32_t resource_id, - uint32_t width, uint32_t height, - uint32_t x, uint32_t y); -int virtio_gpu_object_attach(struct virtio_gpu_device *vgdev, -struct virtio_gpu_object *obj, -struct virtio_gpu_fence *fence); -void virtio_gpu_object_detach(struct virtio_gpu_device *vgdev, - struct virtio_gpu_object *obj); -int virtio_gpu_attach_status_page(struct virtio_gpu_device *vgdev); -int virtio_gpu_detach_status_page(struct virtio_gpu_device *vgdev); -void virtio_gpu_cursor_ping(struct virtio_gpu_device *vgdev, - struct virtio_gpu_output *output); -int virtio_gpu_cmd_get_display_info(struct virtio_gpu_device *vgdev); -int virtio_gpu_cmd_get_capset_info(struct virtio_gpu_device *vgdev, int idx); -int virtio_gpu_cmd_get_capset(struct virtio_gpu_device *vgdev, - int idx, int version, - struct virtio_gpu_drv_cap_cache **cache_p); -int virtio_gpu_cmd_get_edids(struct virtio_gpu_device *vgdev); -void virtio_gpu_cmd_context_create(struct virtio_gpu_device *vgdev, uint32_t id, - uint32_t nlen, const char *name); -void virtio_gpu_cmd_context_destroy(struct virtio_gpu_device *vgdev, - uint32_t id); -void virtio_gpu_cmd_context_attach_resource(struct virtio_gpu_device *vgdev, - uint32_t ctx_id, - struct virtio_gpu_object_array *objs); -void virtio_gpu_cmd_context_detach_resource(struct virtio_gpu_device *vgdev, - uint32_t ctx_id, - struct virtio_gpu_object_array *objs); -void virtio_gpu_cmd_submit(struct virtio_gpu_device *vgdev, - void *data, uint32_t data_size, - uint32_t ctx_id, -
[PATCH 7/9] drm/virtio: move drm_connector_to_virtio_gpu_output to virtgpu_display
That's the only file that uses it.
Signed-off-by: Gurchetan Singh
---
drivers/gpu/drm/virtio/virtgpu_display.c | 3 +++
drivers/gpu/drm/virtio/virtgpu_drv.h | 2 --
2 files changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/virtio/virtgpu_display.c
b/drivers/gpu/drm/virtio/virtgpu_display.c
index c76d69fecfeb..0966208ec30d 100644
--- a/drivers/gpu/drm/virtio/virtgpu_display.c
+++ b/drivers/gpu/drm/virtio/virtgpu_display.c
@@ -43,6 +43,9 @@
#define XRES_MAX 8192
#define YRES_MAX 8192
+#define drm_connector_to_virtio_gpu_output(x) \
+ container_of(x, struct virtio_gpu_output, conn)
+
static const struct drm_crtc_funcs virtio_gpu_crtc_funcs = {
.set_config = drm_atomic_helper_set_config,
.destroy= drm_crtc_cleanup,
diff --git a/drivers/gpu/drm/virtio/virtgpu_drv.h
b/drivers/gpu/drm/virtio/virtgpu_drv.h
index 4ec80563d1ca..7e447784e493 100644
--- a/drivers/gpu/drm/virtio/virtgpu_drv.h
+++ b/drivers/gpu/drm/virtio/virtgpu_drv.h
@@ -133,8 +133,6 @@ struct virtio_gpu_output {
};
#define drm_crtc_to_virtio_gpu_output(x) \
container_of(x, struct virtio_gpu_output, crtc)
-#define drm_connector_to_virtio_gpu_output(x) \
- container_of(x, struct virtio_gpu_output, conn)
struct virtio_gpu_framebuffer {
struct drm_framebuffer base;
--
2.24.1.735.g03f4e72817-goog
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 9/9] drm/virtio: split out gem functions from virtgpu_drv.h
virtgpu_drv.h is getting very big, let's try to split it into smaller header files. This time, GEM functions. Signed-off-by: Gurchetan Singh --- drivers/gpu/drm/virtio/virtgpu_drv.c| 1 + drivers/gpu/drm/virtio/virtgpu_drv.h| 34 drivers/gpu/drm/virtio/virtgpu_gem.c| 1 + drivers/gpu/drm/virtio/virtgpu_gem.h| 52 + drivers/gpu/drm/virtio/virtgpu_ioctl.c | 1 + drivers/gpu/drm/virtio/virtgpu_kms.c| 1 + drivers/gpu/drm/virtio/virtgpu_object.c | 1 + drivers/gpu/drm/virtio/virtgpu_plane.c | 1 + drivers/gpu/drm/virtio/virtgpu_vq.c | 1 + 9 files changed, 59 insertions(+), 34 deletions(-) create mode 100644 drivers/gpu/drm/virtio/virtgpu_gem.h diff --git a/drivers/gpu/drm/virtio/virtgpu_drv.c b/drivers/gpu/drm/virtio/virtgpu_drv.c index e942465e4fb1..7bd46e915761 100644 --- a/drivers/gpu/drm/virtio/virtgpu_drv.c +++ b/drivers/gpu/drm/virtio/virtgpu_drv.c @@ -35,6 +35,7 @@ #include #include "virtgpu_drv.h" +#include "virtgpu_gem.h" static struct drm_driver driver; diff --git a/drivers/gpu/drm/virtio/virtgpu_drv.h b/drivers/gpu/drm/virtio/virtgpu_drv.h index cd98df412cda..fa921f07c331 100644 --- a/drivers/gpu/drm/virtio/virtgpu_drv.h +++ b/drivers/gpu/drm/virtio/virtgpu_drv.h @@ -216,40 +216,6 @@ void virtio_gpu_deinit(struct drm_device *dev); int virtio_gpu_driver_open(struct drm_device *dev, struct drm_file *file); void virtio_gpu_driver_postclose(struct drm_device *dev, struct drm_file *file); -/* virtio_gem.c */ -void virtio_gpu_gem_free_object(struct drm_gem_object *gem_obj); -int virtio_gpu_gem_init(struct virtio_gpu_device *vgdev); -void virtio_gpu_gem_fini(struct virtio_gpu_device *vgdev); -int virtio_gpu_gem_create(struct drm_file *file, - struct drm_device *dev, - struct virtio_gpu_object_params *params, - struct drm_gem_object **obj_p, - uint32_t *handle_p); -int virtio_gpu_gem_object_open(struct drm_gem_object *obj, - struct drm_file *file); -void virtio_gpu_gem_object_close(struct drm_gem_object *obj, -struct drm_file *file); -int virtio_gpu_mode_dumb_create(struct drm_file *file_priv, - struct drm_device *dev, - struct drm_mode_create_dumb *args); -int virtio_gpu_mode_dumb_mmap(struct drm_file *file_priv, - struct drm_device *dev, - uint32_t handle, uint64_t *offset_p); - -struct virtio_gpu_object_array *virtio_gpu_array_alloc(u32 nents); -struct virtio_gpu_object_array* -virtio_gpu_array_from_handles(struct drm_file *drm_file, u32 *handles, u32 nents); -void virtio_gpu_array_add_obj(struct virtio_gpu_object_array *objs, - struct drm_gem_object *obj); -int virtio_gpu_array_lock_resv(struct virtio_gpu_object_array *objs); -void virtio_gpu_array_unlock_resv(struct virtio_gpu_object_array *objs); -void virtio_gpu_array_add_fence(struct virtio_gpu_object_array *objs, - struct dma_fence *fence); -void virtio_gpu_array_put_free(struct virtio_gpu_object_array *objs); -void virtio_gpu_array_put_free_delayed(struct virtio_gpu_device *vgdev, - struct virtio_gpu_object_array *objs); -void virtio_gpu_array_put_free_work(struct work_struct *work); - /* virtio_gpu_display.c */ void virtio_gpu_modeset_init(struct virtio_gpu_device *vgdev); void virtio_gpu_modeset_fini(struct virtio_gpu_device *vgdev); diff --git a/drivers/gpu/drm/virtio/virtgpu_gem.c b/drivers/gpu/drm/virtio/virtgpu_gem.c index 409dd3863c7b..61cfc9e11f75 100644 --- a/drivers/gpu/drm/virtio/virtgpu_gem.c +++ b/drivers/gpu/drm/virtio/virtgpu_gem.c @@ -27,6 +27,7 @@ #include #include "virtgpu_drv.h" +#include "virtgpu_gem.h" #include "virtgpu_vq.h" int virtio_gpu_gem_create(struct drm_file *file, diff --git a/drivers/gpu/drm/virtio/virtgpu_gem.h b/drivers/gpu/drm/virtio/virtgpu_gem.h new file mode 100644 index ..2ee81980e384 --- /dev/null +++ b/drivers/gpu/drm/virtio/virtgpu_gem.h @@ -0,0 +1,52 @@ +/* SPDX-License-Identifier: GPL-2.0 */ +#ifndef VIRTIO_GEM_H +#define VIRTIO_GEM_H + +#include + +struct dma_fence; +struct drm_device; +struct drm_file; +struct drm_gem_object; + +struct virtio_gpu_device; +struct virtio_gpu_object_array; +struct virtio_gpu_object_params; + +struct work_struct; + +void virtio_gpu_gem_free_object(struct drm_gem_object *gem_obj); +int virtio_gpu_gem_init(struct virtio_gpu_device *vgdev); +void virtio_gpu_gem_fini(struct virtio_gpu_device *vgdev); +int virtio_gpu_gem_create(struct drm_file *file, + struct drm_device *dev, + struct virtio_gpu_object_params *params, + struct drm_gem_object **obj_p, + uint32_t *handle_p); +int virtio_gpu_gem_object
[PATCH 3/9] drm/virtio: get rid of drm_encoder_to_virtio_gpu_output
Not used anywhere.
Signed-off-by: Gurchetan Singh
---
drivers/gpu/drm/virtio/virtgpu_drv.h | 2 --
1 file changed, 2 deletions(-)
diff --git a/drivers/gpu/drm/virtio/virtgpu_drv.h
b/drivers/gpu/drm/virtio/virtgpu_drv.h
index b2270153528c..45b4c3324b2c 100644
--- a/drivers/gpu/drm/virtio/virtgpu_drv.h
+++ b/drivers/gpu/drm/virtio/virtgpu_drv.h
@@ -137,8 +137,6 @@ struct virtio_gpu_output {
container_of(x, struct virtio_gpu_output, crtc)
#define drm_connector_to_virtio_gpu_output(x) \
container_of(x, struct virtio_gpu_output, conn)
-#define drm_encoder_to_virtio_gpu_output(x) \
- container_of(x, struct virtio_gpu_output, enc)
struct virtio_gpu_framebuffer {
struct drm_framebuffer base;
--
2.24.1.735.g03f4e72817-goog
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 0/9] *** virtgpu cleanups ***
With so many new features on the horizon, perhaps it's time to do a little "winter cleaning" beforehand. Enjoy! Gurchetan Singh (9): drm/virtio: static-ify virtio_fence_signaled drm/virtio: static-ify virtio_gpu_framebuffer_init drm/virtio: get rid of drm_encoder_to_virtio_gpu_output drm/virtio: simplify getting fake offset drm/virtio: remove virtgpu_gem_prime_import_sg_table drm/virtio: move to_virtio_fence inside virtgpu_fence drm/virtio: move drm_connector_to_virtio_gpu_output to virtgpu_display drm/virtio: split out vq functions from virtgpu_drv.h drm/virtio: split out gem functions from virtgpu_drv.h drivers/gpu/drm/virtio/Makefile | 2 +- drivers/gpu/drm/virtio/virtgpu_display.c | 6 +- drivers/gpu/drm/virtio/virtgpu_drv.c | 4 +- drivers/gpu/drm/virtio/virtgpu_drv.h | 137 +-- drivers/gpu/drm/virtio/virtgpu_fence.c | 5 +- drivers/gpu/drm/virtio/virtgpu_gem.c | 6 +- drivers/gpu/drm/virtio/virtgpu_gem.h | 52 + drivers/gpu/drm/virtio/virtgpu_ioctl.c | 2 + drivers/gpu/drm/virtio/virtgpu_kms.c | 2 + drivers/gpu/drm/virtio/virtgpu_object.c | 2 + drivers/gpu/drm/virtio/virtgpu_plane.c | 2 + drivers/gpu/drm/virtio/virtgpu_prime.c | 38 --- drivers/gpu/drm/virtio/virtgpu_vq.c | 2 + drivers/gpu/drm/virtio/virtgpu_vq.h | 100 + 14 files changed, 178 insertions(+), 182 deletions(-) create mode 100644 drivers/gpu/drm/virtio/virtgpu_gem.h delete mode 100644 drivers/gpu/drm/virtio/virtgpu_prime.c create mode 100644 drivers/gpu/drm/virtio/virtgpu_vq.h -- 2.24.1.735.g03f4e72817-goog ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 2/9] drm/virtio: static-ify virtio_gpu_framebuffer_init
Not used anywhere else.
Signed-off-by: Gurchetan Singh
---
drivers/gpu/drm/virtio/virtgpu_display.c | 2 +-
drivers/gpu/drm/virtio/virtgpu_drv.h | 4
2 files changed, 1 insertion(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/virtio/virtgpu_display.c
b/drivers/gpu/drm/virtio/virtgpu_display.c
index e622485ae826..c76d69fecfeb 100644
--- a/drivers/gpu/drm/virtio/virtgpu_display.c
+++ b/drivers/gpu/drm/virtio/virtgpu_display.c
@@ -59,7 +59,7 @@ static const struct drm_framebuffer_funcs virtio_gpu_fb_funcs
= {
.dirty = drm_atomic_helper_dirtyfb,
};
-int
+static int
virtio_gpu_framebuffer_init(struct drm_device *dev,
struct virtio_gpu_framebuffer *vgfb,
const struct drm_mode_fb_cmd2 *mode_cmd,
diff --git a/drivers/gpu/drm/virtio/virtgpu_drv.h
b/drivers/gpu/drm/virtio/virtgpu_drv.h
index 6b3f1551a2f1..b2270153528c 100644
--- a/drivers/gpu/drm/virtio/virtgpu_drv.h
+++ b/drivers/gpu/drm/virtio/virtgpu_drv.h
@@ -336,10 +336,6 @@ void virtio_gpu_dequeue_cursor_func(struct work_struct
*work);
void virtio_gpu_dequeue_fence_func(struct work_struct *work);
/* virtio_gpu_display.c */
-int virtio_gpu_framebuffer_init(struct drm_device *dev,
- struct virtio_gpu_framebuffer *vgfb,
- const struct drm_mode_fb_cmd2 *mode_cmd,
- struct drm_gem_object *obj);
void virtio_gpu_modeset_init(struct virtio_gpu_device *vgdev);
void virtio_gpu_modeset_fini(struct virtio_gpu_device *vgdev);
--
2.24.1.735.g03f4e72817-goog
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 4/9] drm/virtio: simplify getting fake offset
This is a little simpler.
Signed-off-by: Gurchetan Singh
---
drivers/gpu/drm/virtio/virtgpu_drv.h | 8 +---
drivers/gpu/drm/virtio/virtgpu_gem.c | 4 +---
2 files changed, 2 insertions(+), 10 deletions(-)
diff --git a/drivers/gpu/drm/virtio/virtgpu_drv.h
b/drivers/gpu/drm/virtio/virtgpu_drv.h
index 45b4c3324b2c..8dfb39f98552 100644
--- a/drivers/gpu/drm/virtio/virtgpu_drv.h
+++ b/drivers/gpu/drm/virtio/virtgpu_drv.h
@@ -359,18 +359,12 @@ int virtio_gpu_object_create(struct virtio_gpu_device
*vgdev,
struct virtio_gpu_object_params *params,
struct virtio_gpu_object **bo_ptr,
struct virtio_gpu_fence *fence);
-
/* virtgpu_prime.c */
struct drm_gem_object *virtgpu_gem_prime_import_sg_table(
struct drm_device *dev, struct dma_buf_attachment *attach,
struct sg_table *sgt);
-static inline u64 virtio_gpu_object_mmap_offset(struct virtio_gpu_object *bo)
-{
- return drm_vma_node_offset_addr(&bo->base.base.vma_node);
-}
-
-/* virgl debufs */
+/* virgl debugfs */
int virtio_gpu_debugfs_init(struct drm_minor *minor);
#endif
diff --git a/drivers/gpu/drm/virtio/virtgpu_gem.c
b/drivers/gpu/drm/virtio/virtgpu_gem.c
index 4c1f579edfb3..0a2b62279647 100644
--- a/drivers/gpu/drm/virtio/virtgpu_gem.c
+++ b/drivers/gpu/drm/virtio/virtgpu_gem.c
@@ -96,14 +96,12 @@ int virtio_gpu_mode_dumb_mmap(struct drm_file *file_priv,
uint32_t handle, uint64_t *offset_p)
{
struct drm_gem_object *gobj;
- struct virtio_gpu_object *obj;
BUG_ON(!offset_p);
gobj = drm_gem_object_lookup(file_priv, handle);
if (gobj == NULL)
return -ENOENT;
- obj = gem_to_virtio_gpu_obj(gobj);
- *offset_p = virtio_gpu_object_mmap_offset(obj);
+ *offset_p = drm_vma_node_offset_addr(&gobj->vma_node);
drm_gem_object_put_unlocked(gobj);
return 0;
}
--
2.24.1.735.g03f4e72817-goog
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 1/9] drm/virtio: static-ify virtio_fence_signaled
Not used anywhere else.
Signed-off-by: Gurchetan Singh
---
drivers/gpu/drm/virtio/virtgpu_drv.h | 1 -
drivers/gpu/drm/virtio/virtgpu_fence.c | 2 +-
2 files changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/virtio/virtgpu_drv.h
b/drivers/gpu/drm/virtio/virtgpu_drv.h
index eedae2a7b532..6b3f1551a2f1 100644
--- a/drivers/gpu/drm/virtio/virtgpu_drv.h
+++ b/drivers/gpu/drm/virtio/virtgpu_drv.h
@@ -350,7 +350,6 @@ struct drm_plane *virtio_gpu_plane_init(struct
virtio_gpu_device *vgdev,
int index);
/* virtio_gpu_fence.c */
-bool virtio_fence_signaled(struct dma_fence *f);
struct virtio_gpu_fence *virtio_gpu_fence_alloc(
struct virtio_gpu_device *vgdev);
void virtio_gpu_fence_emit(struct virtio_gpu_device *vgdev,
diff --git a/drivers/gpu/drm/virtio/virtgpu_fence.c
b/drivers/gpu/drm/virtio/virtgpu_fence.c
index a4b9881ca1d3..5466aab7d39a 100644
--- a/drivers/gpu/drm/virtio/virtgpu_fence.c
+++ b/drivers/gpu/drm/virtio/virtgpu_fence.c
@@ -37,7 +37,7 @@ static const char *virtio_get_timeline_name(struct dma_fence
*f)
return "controlq";
}
-bool virtio_fence_signaled(struct dma_fence *f)
+static bool virtio_fence_signaled(struct dma_fence *f)
{
struct virtio_gpu_fence *fence = to_virtio_fence(f);
--
2.24.1.735.g03f4e72817-goog
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 2/2] fixup! drm/bridge: ti-sn65dsi86: Skip non-standard DP rates
Hi, On Sun, Dec 15, 2019 at 12:06 PM Rob Clark wrote: > > From: Rob Clark > > --- > Note however, the panel I have on the yoga c630 is not eDP 1.4+, so I > cannot test that path. But I think it looks correct. > > drivers/gpu/drm/bridge/ti-sn65dsi86.c | 110 +- > 1 file changed, 89 insertions(+), 21 deletions(-) I ended up basing patch #9 in my v2 series slightly more on Jeffrey's patch. Hopefully it looks OK. I don't have any eDP 1.4 panels either, so hopefully it's all good there... -Doug ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/2] fixup! drm/bridge: ti-sn65dsi86: Train at faster rates if slower ones fail
Hi, On Sun, Dec 15, 2019 at 12:05 PM Rob Clark wrote: > > From: Rob Clark > > Fixes: > > In file included from ../drivers/gpu/drm/bridge/ti-sn65dsi86.c:25: > ../drivers/gpu/drm/bridge/ti-sn65dsi86.c: In function ‘ti_sn_bridge_enable’: > ../include/drm/drm_print.h:339:2: warning: ‘last_err_str’ may be used > uninitialized in this function [-Wmaybe-uninitialized] > 339 | drm_dev_printk(dev, KERN_ERR, "*ERROR* " fmt, ##__VA_ARGS__) > | ^~ > ../drivers/gpu/drm/bridge/ti-sn65dsi86.c:650:14: note: ‘last_err_str’ was > declared here > 650 | const char *last_err_str; > | ^~~~ > In file included from ../drivers/gpu/drm/bridge/ti-sn65dsi86.c:25: > ../include/drm/drm_print.h:339:2: warning: ‘ret’ may be used uninitialized in > this function [-Wmaybe-uninitialized] > 339 | drm_dev_printk(dev, KERN_ERR, "*ERROR* " fmt, ##__VA_ARGS__) > | ^~ > ../drivers/gpu/drm/bridge/ti-sn65dsi86.c:654:6: note: ‘ret’ was declared here > 654 | int ret; > | ^~~ > Building modules, stage 2. > --- > drivers/gpu/drm/bridge/ti-sn65dsi86.c | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) Thanks! I have rolled this into my v2. -Doug ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2] drm/bridge: ti-sn65dsi86: Decouple DP output lanes from DSI input lanes
Hi,
On Tue, Oct 22, 2019 at 12:01 PM Jeffrey Hugo wrote:
>
> Based on work by Bjorn Andersson
>
> The bridge can be configured to use 1, 2, or 4 DP lanes. This
> configuration is independent of the input DSI lanes. Right now, the
> driver assumes that there is 1:1 mapping of input lanes to output lanes
> which is not correct and does not work for manu devices such as the
> Lenovo Miix 630 and Lenovo Yoga C630 laptops.
>
> The bridge can also be configured to use one of a number of data rates on
> the DP lanes. Currently any of the supported rates is considered valid,
> however the configured rate must also be supported by the connected panel,
> and not all rates are supported or even valid for any particular panel.
>
> Luckily, we can determine what we need at runtime by reading the DPCD from
> the attached panel. DPCD will tell us the maximum number of supported
> lanes, and the supported data rates.
>
> Signed-off-by: Jeffrey Hugo
> ---
>
> Bjorn, I think this should address the issue you pointed out concerning
> the data rate glitch I missed in your origional work. Would you kindly
> give this a test and let me know if it appears to address all of the
> issues you were working around?
>
> v2:
> -Use DPCD instead of DT to address the issue of some panels not
> supporting all the rates
>
> drivers/gpu/drm/bridge/ti-sn65dsi86.c | 97 ++-
> 1 file changed, 94 insertions(+), 3 deletions(-)
Overall I'm suggesting moving over to my series and I've taken the
best stuff from your patch and put it atop my series. Please yell if
you disagree. You can find the cover letter for my v2 at:
https://lore.kernel.org/r/20191218004741.102067-1-diand...@chromium.org
A few misc comments below in any case.
> @@ -444,10 +447,91 @@ static void ti_sn_bridge_set_dsi_dp_rate(struct
> ti_sn_bridge *pdata)
> regmap_write(pdata->regmap, SN_DSIA_CLK_FREQ_REG, val);
>
> /* set DP data rate */
> - dp_rate_mhz = ((bit_rate_mhz / pdata->dsi->lanes) * DP_CLK_FUDGE_NUM)
> /
> + dp_rate_mhz = ((bit_rate_mhz / pdata->dp_lanes) * DP_CLK_FUDGE_NUM) /
> DP_CLK_FUDGE_DEN;
One note is that "bit_rate_mhz" is still calculated using the MIPI
pixel format, which is wrong. It happens that (at the moment) we have
24 bits per pixel for both cases, though.
> + /* read the panel capabilities to determine valid supported rates */
> + val = drm_dp_dpcd_readb(&pdata->aux, DP_MAX_LINK_RATE, &dpcd_val);
> + if (!val) {
> + DRM_ERROR("Reading max link rate from DPCD failed\n");
> + return;
> + }
> +
> + if (dpcd_val) {
I think your patch is assuming that the only case you want to use the
table is if dpcd_val is 0. This doesn't appear to be the case. In
Table 4-24 of the spec it states that you can have a non-zero value
here and still provide a table. That might be useful if you want to
be backward compatible with an eDP 1.3 source but also provide an
optimized rate for a eDP 1.4 source.
We should be checking the eDP revision first and always using the
table if it's eDP 1.4.
> + /* cap to the max rate supported by the bridge */
> + if (dpcd_val > 0x14)
> + dpcd_val = 0x14;
> +
> + switch (dpcd_val) {
> + case 0x14:
There are constants. Like DP_LINK_BW_5_4
> @@ -505,7 +589,14 @@ static void ti_sn_bridge_enable(struct drm_bridge
> *bridge)
>CHA_DSI_LANES_MASK, val);
>
> /* DP lane config */
> - val = DP_NUM_LANES(pdata->dsi->lanes - 1);
> + ret = drm_dp_dpcd_readb(&pdata->aux, DP_MAX_LANE_COUNT, (u8 *)&val);
This is an iffy cast. The function is only guaranteed to set the
first byte of val which could be the most or least significant byte.
Other bytes will remain as-is.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 7/9] drm/bridge: ti-sn65dsi86: Group DP link training bits in a function
We'll re-organize the ti_sn_bridge_enable() function a bit to group
together all the parts relating to link training and split them into a
sub-function. This is not intended to have any functional change and
is in preparation for trying link training several times at different
rates. One small side effect here is that if link training fails
we'll now leave the DP PLL disabled, but that seems like a sane thing
to do.
Signed-off-by: Douglas Anderson
Tested-by: Rob Clark
Reviewed-by: Rob Clark
---
Changes in v2: None
drivers/gpu/drm/bridge/ti-sn65dsi86.c | 86 ---
1 file changed, 52 insertions(+), 34 deletions(-)
diff --git a/drivers/gpu/drm/bridge/ti-sn65dsi86.c
b/drivers/gpu/drm/bridge/ti-sn65dsi86.c
index d5990a0947b9..48fb4dc72e1c 100644
--- a/drivers/gpu/drm/bridge/ti-sn65dsi86.c
+++ b/drivers/gpu/drm/bridge/ti-sn65dsi86.c
@@ -530,6 +530,46 @@ static unsigned int ti_sn_get_max_lanes(struct
ti_sn_bridge *pdata)
return data & DP_LANE_COUNT_MASK;
}
+static int ti_sn_link_training(struct ti_sn_bridge *pdata)
+{
+ unsigned int val;
+ int ret;
+
+ /* set dp clk frequency value */
+ ti_sn_bridge_set_dp_rate(pdata);
+
+ /* enable DP PLL */
+ regmap_write(pdata->regmap, SN_PLL_ENABLE_REG, 1);
+
+ ret = regmap_read_poll_timeout(pdata->regmap, SN_DPPLL_SRC_REG, val,
+ val & DPPLL_SRC_DP_PLL_LOCK, 1000,
+ 50 * 1000);
+ if (ret) {
+ DRM_ERROR("DP_PLL_LOCK polling failed (%d)\n", ret);
+ goto exit;
+ }
+
+ /* Semi auto link training mode */
+ regmap_write(pdata->regmap, SN_ML_TX_MODE_REG, 0x0A);
+ ret = regmap_read_poll_timeout(pdata->regmap, SN_ML_TX_MODE_REG, val,
+ val == ML_TX_MAIN_LINK_OFF ||
+ val == ML_TX_NORMAL_MODE, 1000,
+ 500 * 1000);
+ if (ret) {
+ DRM_ERROR("Training complete polling failed (%d)\n", ret);
+ } else if (val == ML_TX_MAIN_LINK_OFF) {
+ DRM_ERROR("Link training failed, link is off\n");
+ ret = -EIO;
+ }
+
+exit:
+ /* Disable the PLL if we failed */
+ if (ret)
+ regmap_write(pdata->regmap, SN_PLL_ENABLE_REG, 0);
+
+ return ret;
+}
+
static void ti_sn_bridge_enable(struct drm_bridge *bridge)
{
struct ti_sn_bridge *pdata = bridge_to_ti_sn_bridge(bridge);
@@ -555,29 +595,8 @@ static void ti_sn_bridge_enable(struct drm_bridge *bridge)
regmap_update_bits(pdata->regmap, SN_DSI_LANES_REG,
CHA_DSI_LANES_MASK, val);
- /* Set the DP output format (18 bpp or 24 bpp) */
- val = (ti_sn_bridge_get_bpp(pdata) == 18) ? BPP_18_RGB : 0;
- regmap_update_bits(pdata->regmap, SN_DATA_FORMAT_REG, BPP_18_RGB, val);
-
- /* DP lane config */
- val = DP_NUM_LANES(min(pdata->dp_lanes, 3));
- regmap_update_bits(pdata->regmap, SN_SSC_CONFIG_REG, DP_NUM_LANES_MASK,
- val);
-
- /* set dsi/dp clk frequency value */
+ /* set dsi clk frequency value */
ti_sn_bridge_set_dsi_rate(pdata);
- ti_sn_bridge_set_dp_rate(pdata);
-
- /* enable DP PLL */
- regmap_write(pdata->regmap, SN_PLL_ENABLE_REG, 1);
-
- ret = regmap_read_poll_timeout(pdata->regmap, SN_DPPLL_SRC_REG, val,
- val & DPPLL_SRC_DP_PLL_LOCK, 1000,
- 50 * 1000);
- if (ret) {
- DRM_ERROR("DP_PLL_LOCK polling failed (%d)\n", ret);
- return;
- }
/**
* The SN65DSI86 only supports ASSR Display Authentication method and
@@ -588,19 +607,18 @@ static void ti_sn_bridge_enable(struct drm_bridge *bridge)
drm_dp_dpcd_writeb(&pdata->aux, DP_EDP_CONFIGURATION_SET,
DP_ALTERNATE_SCRAMBLER_RESET_ENABLE);
- /* Semi auto link training mode */
- regmap_write(pdata->regmap, SN_ML_TX_MODE_REG, 0x0A);
- ret = regmap_read_poll_timeout(pdata->regmap, SN_ML_TX_MODE_REG, val,
- val == ML_TX_MAIN_LINK_OFF ||
- val == ML_TX_NORMAL_MODE, 1000,
- 500 * 1000);
- if (ret) {
- DRM_ERROR("Training complete polling failed (%d)\n", ret);
- return;
- } else if (val == ML_TX_MAIN_LINK_OFF) {
- DRM_ERROR("Link training failed, link is off\n");
+ /* Set the DP output format (18 bpp or 24 bpp) */
+ val = (ti_sn_bridge_get_bpp(pdata) == 18) ? BPP_18_RGB : 0;
+ regmap_update_bits(pdata->regmap, SN_DATA_FORMAT_REG, BPP_18_RGB, val);
+
+ /* DP lane config */
+ val = DP_NUM_LANES(min(pdata->dp_lanes, 3));
+ regmap_update_bits(pdata->regmap, SN_SSC_CONFIG_REG, DP_NUM_LANES_
[PATCH v2 6/9] drm/bridge: ti-sn65dsi86: Use 18-bit DP if we can
The current bridge driver always forced us to use 24 bits per pixel
over the DP link. This is a waste if you are hooked up to a panel
that only supports 6 bits per color or fewer, since in that case you
ran run at 18 bits per pixel and thus end up at a lower DP clock rate.
Let's support this.
While at it, let's clean up the math in the function to avoid rounding
errors (and round in the correct direction when we have to round).
Numbers are sufficiently small (because mode->clock is in kHz) that we
don't need to worry about integer overflow.
Signed-off-by: Douglas Anderson
Tested-by: Rob Clark
Reviewed-by: Rob Clark
---
Changes in v2: None
drivers/gpu/drm/bridge/ti-sn65dsi86.c | 27 ++-
1 file changed, 18 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/bridge/ti-sn65dsi86.c
b/drivers/gpu/drm/bridge/ti-sn65dsi86.c
index 0fc9e97b2d98..d5990a0947b9 100644
--- a/drivers/gpu/drm/bridge/ti-sn65dsi86.c
+++ b/drivers/gpu/drm/bridge/ti-sn65dsi86.c
@@ -51,6 +51,7 @@
#define SN_ENH_FRAME_REG 0x5A
#define VSTREAM_ENABLEBIT(3)
#define SN_DATA_FORMAT_REG 0x5B
+#define BPP_18_RGBBIT(0)
#define SN_HPD_DISABLE_REG 0x5C
#define HPD_DISABLE BIT(0)
#define SN_AUX_WDATA_REG(x)(0x64 + (x))
@@ -436,6 +437,14 @@ static void ti_sn_bridge_set_dsi_rate(struct ti_sn_bridge
*pdata)
regmap_write(pdata->regmap, SN_DSIA_CLK_FREQ_REG, val);
}
+static unsigned int ti_sn_bridge_get_bpp(struct ti_sn_bridge *pdata)
+{
+ if (pdata->connector.display_info.bpc <= 6)
+ return 18;
+ else
+ return 24;
+}
+
/**
* LUT index corresponds to register value and
* LUT values corresponds to dp data rate supported
@@ -447,21 +456,17 @@ static const unsigned int ti_sn_bridge_dp_rate_lut[] = {
static void ti_sn_bridge_set_dp_rate(struct ti_sn_bridge *pdata)
{
- unsigned int bit_rate_mhz, dp_rate_mhz;
+ unsigned int bit_rate_khz, dp_rate_mhz;
unsigned int i;
struct drm_display_mode *mode =
&pdata->bridge.encoder->crtc->state->adjusted_mode;
- /*
-* Calculate minimum bit rate based on our pixel clock. At
-* the moment this driver never sets the DP_18BPP_EN bit in
-* register 0x5b so we hardcode 24bpp.
-*/
- bit_rate_mhz = (mode->clock / 1000) * 24;
+ /* Calculate minimum bit rate based on our pixel clock. */
+ bit_rate_khz = mode->clock * ti_sn_bridge_get_bpp(pdata);
/* Calculate minimum DP data rate, taking 80% as per DP spec */
- dp_rate_mhz = ((bit_rate_mhz / pdata->dp_lanes) * DP_CLK_FUDGE_NUM) /
- DP_CLK_FUDGE_DEN;
+ dp_rate_mhz = DIV_ROUND_UP(bit_rate_khz * DP_CLK_FUDGE_NUM,
+ 1000 * pdata->dp_lanes * DP_CLK_FUDGE_DEN);
for (i = 1; i < ARRAY_SIZE(ti_sn_bridge_dp_rate_lut) - 1; i++)
if (ti_sn_bridge_dp_rate_lut[i] > dp_rate_mhz)
@@ -550,6 +555,10 @@ static void ti_sn_bridge_enable(struct drm_bridge *bridge)
regmap_update_bits(pdata->regmap, SN_DSI_LANES_REG,
CHA_DSI_LANES_MASK, val);
+ /* Set the DP output format (18 bpp or 24 bpp) */
+ val = (ti_sn_bridge_get_bpp(pdata) == 18) ? BPP_18_RGB : 0;
+ regmap_update_bits(pdata->regmap, SN_DATA_FORMAT_REG, BPP_18_RGB, val);
+
/* DP lane config */
val = DP_NUM_LANES(min(pdata->dp_lanes, 3));
regmap_update_bits(pdata->regmap, SN_SSC_CONFIG_REG, DP_NUM_LANES_MASK,
--
2.24.1.735.g03f4e72817-goog
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 5/9] drm/bridge: ti-sn65dsi86: Read num lanes from the DP sink
At least one panel hooked up to the bridge (AUO B116XAK01) only
supports 1 lane of DP. Let's read this information and stop
hardcoding 4 DP lanes.
Signed-off-by: Douglas Anderson
Tested-by: Rob Clark
Reviewed-by: Rob Clark
---
Changes in v2: None
drivers/gpu/drm/bridge/ti-sn65dsi86.c | 32 +--
1 file changed, 30 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/bridge/ti-sn65dsi86.c
b/drivers/gpu/drm/bridge/ti-sn65dsi86.c
index d55d19759796..0fc9e97b2d98 100644
--- a/drivers/gpu/drm/bridge/ti-sn65dsi86.c
+++ b/drivers/gpu/drm/bridge/ti-sn65dsi86.c
@@ -313,8 +313,7 @@ static int ti_sn_bridge_attach(struct drm_bridge *bridge)
goto err_dsi_host;
}
- /* TODO: setting to 4 lanes always for now */
- pdata->dp_lanes = 4;
+ /* TODO: setting to 4 MIPI lanes always for now */
dsi->lanes = 4;
dsi->format = MIPI_DSI_FMT_RGB888;
dsi->mode_flags = MIPI_DSI_MODE_VIDEO;
@@ -511,12 +510,41 @@ static void ti_sn_bridge_set_video_timings(struct
ti_sn_bridge *pdata)
usleep_range(1, 10500); /* 10ms delay recommended by spec */
}
+static unsigned int ti_sn_get_max_lanes(struct ti_sn_bridge *pdata)
+{
+ u8 data;
+ int ret;
+
+ ret = drm_dp_dpcd_readb(&pdata->aux, DP_MAX_LANE_COUNT, &data);
+ if (ret != 1) {
+ DRM_DEV_ERROR(pdata->dev,
+ "Can't read lane count (%d); assuming 4\n", ret);
+ return 4;
+ }
+
+ return data & DP_LANE_COUNT_MASK;
+}
+
static void ti_sn_bridge_enable(struct drm_bridge *bridge)
{
struct ti_sn_bridge *pdata = bridge_to_ti_sn_bridge(bridge);
unsigned int val;
int ret;
+ /*
+* Run with the maximum number of lanes that the DP sink supports.
+*
+* Depending use cases, we might want to revisit this later because:
+* - It's plausible that someone may have run fewer lines to the
+* sink than the sink actually supports, assuming that the lines
+* will just be driven at a higher rate.
+* - The DP spec seems to indicate that it's more important to minimize
+* the number of lanes than the link rate.
+*
+* If we do revisit, it would be important to measure the power impact.
+*/
+ pdata->dp_lanes = ti_sn_get_max_lanes(pdata);
+
/* DSI_A lane config */
val = CHA_DSI_LANES(4 - pdata->dsi->lanes);
regmap_update_bits(pdata->regmap, SN_DSI_LANES_REG,
--
2.24.1.735.g03f4e72817-goog
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 9/9] drm/bridge: ti-sn65dsi86: Avoid invalid rates
Based on work by Bjorn Andersson ,
Jeffrey Hugo , and
Rob Clark .
Let's read the SUPPORTED_LINK_RATES and/or MAX_LINK_RATE (depending on
the eDP version of the sink) to figure out what eDP rates are
supported and pick the ideal one.
Signed-off-by: Douglas Anderson
---
Changes in v2:
- Patch ("Avoid invalid rates") replaces ("Skip non-standard DP rates")
drivers/gpu/drm/bridge/ti-sn65dsi86.c | 118 --
1 file changed, 93 insertions(+), 25 deletions(-)
diff --git a/drivers/gpu/drm/bridge/ti-sn65dsi86.c
b/drivers/gpu/drm/bridge/ti-sn65dsi86.c
index e1b817ccd9c7..da5ddf6be92b 100644
--- a/drivers/gpu/drm/bridge/ti-sn65dsi86.c
+++ b/drivers/gpu/drm/bridge/ti-sn65dsi86.c
@@ -475,39 +475,103 @@ static int ti_sn_bridge_calc_min_dp_rate_idx(struct
ti_sn_bridge *pdata)
return i;
}
-static int ti_sn_bridge_get_max_dp_rate_idx(struct ti_sn_bridge *pdata)
+static void ti_sn_bridge_read_valid_rates(struct ti_sn_bridge *pdata,
+ bool rate_valid[])
{
- u8 data;
+ u8 dpcd_val;
+ int rate_times_200khz;
int ret;
+ int i;
- ret = drm_dp_dpcd_readb(&pdata->aux, DP_MAX_LINK_RATE, &data);
+ ret = drm_dp_dpcd_readb(&pdata->aux, DP_EDP_DPCD_REV, &dpcd_val);
+ if (ret != 1) {
+ DRM_DEV_ERROR(pdata->dev,
+ "Can't read eDP rev (%d), assuming 1.1\n", ret);
+ dpcd_val = DP_EDP_11;
+ }
+
+ if (dpcd_val >= DP_EDP_14) {
+ /* eDP 1.4 devices must provide a custom table */
+ __le16 sink_rates[DP_MAX_SUPPORTED_RATES];
+
+ ret = drm_dp_dpcd_read(&pdata->aux, DP_SUPPORTED_LINK_RATES,
+ sink_rates, sizeof(sink_rates));
+
+ if (ret != sizeof(sink_rates)) {
+ DRM_DEV_ERROR(pdata->dev,
+ "Can't read supported rate table (%d)\n", ret);
+
+ /* By zeroing we'll fall back to DP_MAX_LINK_RATE. */
+ memset(sink_rates, 0, sizeof(sink_rates));
+ }
+
+ for (i = 0; i < ARRAY_SIZE(sink_rates); i++) {
+ rate_times_200khz = le16_to_cpu(sink_rates[i]);
+
+ if (!rate_times_200khz)
+ break;
+
+ switch (rate_times_200khz) {
+ case 27000:
+ rate_valid[7] = 1;
+ break;
+ case 21600:
+ rate_valid[6] = 1;
+ break;
+ case 16200:
+ rate_valid[5] = 1;
+ break;
+ case 13500:
+ rate_valid[4] = 1;
+ break;
+ case 12150:
+ rate_valid[3] = 1;
+ break;
+ case 10800:
+ rate_valid[2] = 1;
+ break;
+ case 8100:
+ rate_valid[1] = 1;
+ break;
+ default:
+ /* unsupported */
+ break;
+ }
+ }
+
+ for (i = 0; i < ARRAY_SIZE(ti_sn_bridge_dp_rate_lut); i++) {
+ if (rate_valid[i])
+ return;
+ }
+ DRM_DEV_ERROR(pdata->dev,
+ "No matching eDP rates in table; falling back\n");
+ }
+
+ /* On older versions best we can do is use DP_MAX_LINK_RATE */
+ ret = drm_dp_dpcd_readb(&pdata->aux, DP_MAX_LINK_RATE, &dpcd_val);
if (ret != 1) {
DRM_DEV_ERROR(pdata->dev,
"Can't read max rate (%d); assuming 5.4 GHz\n",
ret);
- return ARRAY_SIZE(ti_sn_bridge_dp_rate_lut) - 1;
+ dpcd_val = DP_LINK_BW_5_4;
}
- /*
-* Return an index into ti_sn_bridge_dp_rate_lut. Just hardcode
-* these indicies since it's not like the register spec is ever going
-* to change and a loop would just be more complicated. Apparently
-* the DP sink can only return these few rates as supported even
-* though the bridge allows some rates in between.
-*/
- switch (data) {
- case DP_LINK_BW_1_62:
- return 1;
- case DP_LINK_BW_2_7:
- return 4;
+ switch (dpcd_val) {
+ default:
+ DRM_DEV_ERROR(pdata->dev,
+ "Unexpected max rate (%#x); assuming 5.4 GHz\n",
+ (int)dpcd_val);
+ /* fall through */
cas
[PATCH v2 8/9] drm/bridge: ti-sn65dsi86: Train at faster rates if slower ones fail
If we fail training at a lower DP link rate let's now keep trying
until we run out of rates to try. Basically the algorithm here is to
start at the link rate that is the theoretical minimum and then slowly
bump up until we run out of rates or hit the max rate of the sink. We
query the sink using a DPCD read.
This is, in fact, important in practice. Specifically at least one
panel hooked up to the bridge (AUO B116XAK01) had a theoretical min
rate more than 1.62 GHz (if run at 24 bpp) and fails to train at the
next rate (2.16 GHz). It would train at 2.7 GHz, though.
Signed-off-by: Douglas Anderson
Tested-by: Rob Clark
Reviewed-by: Rob Clark
---
Changes in v2:
- Squash in maybe-uninitialized fix from Rob Clark.
drivers/gpu/drm/bridge/ti-sn65dsi86.c | 71 ++-
1 file changed, 60 insertions(+), 11 deletions(-)
diff --git a/drivers/gpu/drm/bridge/ti-sn65dsi86.c
b/drivers/gpu/drm/bridge/ti-sn65dsi86.c
index 48fb4dc72e1c..e1b817ccd9c7 100644
--- a/drivers/gpu/drm/bridge/ti-sn65dsi86.c
+++ b/drivers/gpu/drm/bridge/ti-sn65dsi86.c
@@ -454,7 +454,7 @@ static const unsigned int ti_sn_bridge_dp_rate_lut[] = {
0, 1620, 2160, 2430, 2700, 3240, 4320, 5400
};
-static void ti_sn_bridge_set_dp_rate(struct ti_sn_bridge *pdata)
+static int ti_sn_bridge_calc_min_dp_rate_idx(struct ti_sn_bridge *pdata)
{
unsigned int bit_rate_khz, dp_rate_mhz;
unsigned int i;
@@ -472,8 +472,42 @@ static void ti_sn_bridge_set_dp_rate(struct ti_sn_bridge
*pdata)
if (ti_sn_bridge_dp_rate_lut[i] > dp_rate_mhz)
break;
- regmap_update_bits(pdata->regmap, SN_DATARATE_CONFIG_REG,
- DP_DATARATE_MASK, DP_DATARATE(i));
+ return i;
+}
+
+static int ti_sn_bridge_get_max_dp_rate_idx(struct ti_sn_bridge *pdata)
+{
+ u8 data;
+ int ret;
+
+ ret = drm_dp_dpcd_readb(&pdata->aux, DP_MAX_LINK_RATE, &data);
+ if (ret != 1) {
+ DRM_DEV_ERROR(pdata->dev,
+ "Can't read max rate (%d); assuming 5.4 GHz\n",
+ ret);
+ return ARRAY_SIZE(ti_sn_bridge_dp_rate_lut) - 1;
+ }
+
+ /*
+* Return an index into ti_sn_bridge_dp_rate_lut. Just hardcode
+* these indicies since it's not like the register spec is ever going
+* to change and a loop would just be more complicated. Apparently
+* the DP sink can only return these few rates as supported even
+* though the bridge allows some rates in between.
+*/
+ switch (data) {
+ case DP_LINK_BW_1_62:
+ return 1;
+ case DP_LINK_BW_2_7:
+ return 4;
+ case DP_LINK_BW_5_4:
+ return 7;
+ }
+
+ DRM_DEV_ERROR(pdata->dev,
+ "Unexpected max data rate (%#x); assuming 5.4 GHz\n",
+ (int)data);
+ return ARRAY_SIZE(ti_sn_bridge_dp_rate_lut) - 1;
}
static void ti_sn_bridge_set_video_timings(struct ti_sn_bridge *pdata)
@@ -530,13 +564,15 @@ static unsigned int ti_sn_get_max_lanes(struct
ti_sn_bridge *pdata)
return data & DP_LANE_COUNT_MASK;
}
-static int ti_sn_link_training(struct ti_sn_bridge *pdata)
+static int ti_sn_link_training(struct ti_sn_bridge *pdata, int dp_rate_idx,
+ const char **last_err_str)
{
unsigned int val;
int ret;
/* set dp clk frequency value */
- ti_sn_bridge_set_dp_rate(pdata);
+ regmap_update_bits(pdata->regmap, SN_DATARATE_CONFIG_REG,
+ DP_DATARATE_MASK, DP_DATARATE(dp_rate_idx));
/* enable DP PLL */
regmap_write(pdata->regmap, SN_PLL_ENABLE_REG, 1);
@@ -545,7 +581,7 @@ static int ti_sn_link_training(struct ti_sn_bridge *pdata)
val & DPPLL_SRC_DP_PLL_LOCK, 1000,
50 * 1000);
if (ret) {
- DRM_ERROR("DP_PLL_LOCK polling failed (%d)\n", ret);
+ *last_err_str = "DP_PLL_LOCK polling failed";
goto exit;
}
@@ -556,9 +592,9 @@ static int ti_sn_link_training(struct ti_sn_bridge *pdata)
val == ML_TX_NORMAL_MODE, 1000,
500 * 1000);
if (ret) {
- DRM_ERROR("Training complete polling failed (%d)\n", ret);
+ *last_err_str = "Training complete polling failed";
} else if (val == ML_TX_MAIN_LINK_OFF) {
- DRM_ERROR("Link training failed, link is off\n");
+ *last_err_str = "Link training failed, link is off";
ret = -EIO;
}
@@ -573,8 +609,11 @@ static int ti_sn_link_training(struct ti_sn_bridge *pdata)
static void ti_sn_bridge_enable(struct drm_bridge *bridge)
{
struct ti_sn_bridge *pdata = bridge_to_ti_sn_bridge(bridge);
+ const char *last_err_str = "No supported DP rate"
[PATCH v2 2/9] drm/bridge: ti-sn65dsi86: zero is never greater than an unsigned int
When we iterate over ti_sn_bridge_dp_rate_lut, there's no reason to start at index 0 which always contains the value 0. 0 is not a valid link rate. This change should have no real effect but is a small cleanup. Signed-off-by: Douglas Anderson Tested-by: Rob Clark Reviewed-by: Rob Clark --- Changes in v2: None drivers/gpu/drm/bridge/ti-sn65dsi86.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/bridge/ti-sn65dsi86.c b/drivers/gpu/drm/bridge/ti-sn65dsi86.c index 2fb9370a76e6..7b596af265e4 100644 --- a/drivers/gpu/drm/bridge/ti-sn65dsi86.c +++ b/drivers/gpu/drm/bridge/ti-sn65dsi86.c @@ -458,7 +458,7 @@ static void ti_sn_bridge_set_dp_rate(struct ti_sn_bridge *pdata) /* set DP data rate */ dp_rate_mhz = ((bit_rate_mhz / pdata->dsi->lanes) * DP_CLK_FUDGE_NUM) / DP_CLK_FUDGE_DEN; - for (i = 0; i < ARRAY_SIZE(ti_sn_bridge_dp_rate_lut) - 1; i++) + for (i = 1; i < ARRAY_SIZE(ti_sn_bridge_dp_rate_lut) - 1; i++) if (ti_sn_bridge_dp_rate_lut[i] > dp_rate_mhz) break; -- 2.24.1.735.g03f4e72817-goog ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 1/9] drm/bridge: ti-sn65dsi86: Split the setting of the dp and dsi rates
These two things were in one function. Split into two. This looks
like it's duplicating some code, but don't worry. This is is just in
preparation for future changes.
This is intended to have zero functional change and will just make
future patches easier to understand.
Signed-off-by: Douglas Anderson
Tested-by: Rob Clark
Reviewed-by: Rob Clark
---
Changes in v2: None
drivers/gpu/drm/bridge/ti-sn65dsi86.c | 33 +++
1 file changed, 23 insertions(+), 10 deletions(-)
diff --git a/drivers/gpu/drm/bridge/ti-sn65dsi86.c
b/drivers/gpu/drm/bridge/ti-sn65dsi86.c
index 43abf01ebd4c..2fb9370a76e6 100644
--- a/drivers/gpu/drm/bridge/ti-sn65dsi86.c
+++ b/drivers/gpu/drm/bridge/ti-sn65dsi86.c
@@ -417,6 +417,24 @@ static void ti_sn_bridge_set_refclk_freq(struct
ti_sn_bridge *pdata)
REFCLK_FREQ(i));
}
+static void ti_sn_bridge_set_dsi_rate(struct ti_sn_bridge *pdata)
+{
+ unsigned int bit_rate_mhz, clk_freq_mhz;
+ unsigned int val;
+ struct drm_display_mode *mode =
+ &pdata->bridge.encoder->crtc->state->adjusted_mode;
+
+ /* set DSIA clk frequency */
+ bit_rate_mhz = (mode->clock / 1000) *
+ mipi_dsi_pixel_format_to_bpp(pdata->dsi->format);
+ clk_freq_mhz = bit_rate_mhz / (pdata->dsi->lanes * 2);
+
+ /* for each increment in val, frequency increases by 5MHz */
+ val = (MIN_DSI_CLK_FREQ_MHZ / 5) +
+ (((clk_freq_mhz - MIN_DSI_CLK_FREQ_MHZ) / 5) & 0xFF);
+ regmap_write(pdata->regmap, SN_DSIA_CLK_FREQ_REG, val);
+}
+
/**
* LUT index corresponds to register value and
* LUT values corresponds to dp data rate supported
@@ -426,22 +444,16 @@ static const unsigned int ti_sn_bridge_dp_rate_lut[] = {
0, 1620, 2160, 2430, 2700, 3240, 4320, 5400
};
-static void ti_sn_bridge_set_dsi_dp_rate(struct ti_sn_bridge *pdata)
+static void ti_sn_bridge_set_dp_rate(struct ti_sn_bridge *pdata)
{
- unsigned int bit_rate_mhz, clk_freq_mhz, dp_rate_mhz;
- unsigned int val, i;
+ unsigned int bit_rate_mhz, dp_rate_mhz;
+ unsigned int i;
struct drm_display_mode *mode =
&pdata->bridge.encoder->crtc->state->adjusted_mode;
/* set DSIA clk frequency */
bit_rate_mhz = (mode->clock / 1000) *
mipi_dsi_pixel_format_to_bpp(pdata->dsi->format);
- clk_freq_mhz = bit_rate_mhz / (pdata->dsi->lanes * 2);
-
- /* for each increment in val, frequency increases by 5MHz */
- val = (MIN_DSI_CLK_FREQ_MHZ / 5) +
- (((clk_freq_mhz - MIN_DSI_CLK_FREQ_MHZ) / 5) & 0xFF);
- regmap_write(pdata->regmap, SN_DSIA_CLK_FREQ_REG, val);
/* set DP data rate */
dp_rate_mhz = ((bit_rate_mhz / pdata->dsi->lanes) * DP_CLK_FUDGE_NUM) /
@@ -510,7 +522,8 @@ static void ti_sn_bridge_enable(struct drm_bridge *bridge)
val);
/* set dsi/dp clk frequency value */
- ti_sn_bridge_set_dsi_dp_rate(pdata);
+ ti_sn_bridge_set_dsi_rate(pdata);
+ ti_sn_bridge_set_dp_rate(pdata);
/* enable DP PLL */
regmap_write(pdata->regmap, SN_PLL_ENABLE_REG, 1);
--
2.24.1.735.g03f4e72817-goog
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 3/9] drm/bridge: ti-sn65dsi86: Don't use MIPI variables for DP link
The ti-sn65dsi86 is a bridge from MIPI to DP and thus has two links:
the MIPI link and the DP link. The two links do not need to have the
same format or number of lanes. Stop using MIPI variables when
talking about the DP link.
This has zero functional change because:
* currently we are hardcoding the MIPI link as unpacked RGB888 which
requires 24 bits and currently we are not changing the DP link rate
from the bridge's default of 8 bits per pixel.
* currently we are hardcoding both the MIPI and DP as being 4 lanes.
This is all in prep for fixing some of the above.
Signed-off-by: Douglas Anderson
Tested-by: Rob Clark
Reviewed-by: Rob Clark
---
Changes in v2: None
drivers/gpu/drm/bridge/ti-sn65dsi86.c | 18 --
1 file changed, 12 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/bridge/ti-sn65dsi86.c
b/drivers/gpu/drm/bridge/ti-sn65dsi86.c
index 7b596af265e4..ab644baaf90c 100644
--- a/drivers/gpu/drm/bridge/ti-sn65dsi86.c
+++ b/drivers/gpu/drm/bridge/ti-sn65dsi86.c
@@ -100,6 +100,7 @@ struct ti_sn_bridge {
struct drm_panel*panel;
struct gpio_desc*enable_gpio;
struct regulator_bulk_data supplies[SN_REGULATOR_SUPPLY_NUM];
+ int dp_lanes;
};
static const struct regmap_range ti_sn_bridge_volatile_ranges[] = {
@@ -313,6 +314,7 @@ static int ti_sn_bridge_attach(struct drm_bridge *bridge)
}
/* TODO: setting to 4 lanes always for now */
+ pdata->dp_lanes = 4;
dsi->lanes = 4;
dsi->format = MIPI_DSI_FMT_RGB888;
dsi->mode_flags = MIPI_DSI_MODE_VIDEO;
@@ -451,13 +453,17 @@ static void ti_sn_bridge_set_dp_rate(struct ti_sn_bridge
*pdata)
struct drm_display_mode *mode =
&pdata->bridge.encoder->crtc->state->adjusted_mode;
- /* set DSIA clk frequency */
- bit_rate_mhz = (mode->clock / 1000) *
- mipi_dsi_pixel_format_to_bpp(pdata->dsi->format);
+ /*
+* Calculate minimum bit rate based on our pixel clock. At
+* the moment this driver never sets the DP_18BPP_EN bit in
+* register 0x5b so we hardcode 24bpp.
+*/
+ bit_rate_mhz = (mode->clock / 1000) * 24;
- /* set DP data rate */
- dp_rate_mhz = ((bit_rate_mhz / pdata->dsi->lanes) * DP_CLK_FUDGE_NUM) /
+ /* Calculate minimum DP data rate, taking 80% as per DP spec */
+ dp_rate_mhz = ((bit_rate_mhz / pdata->dp_lanes) * DP_CLK_FUDGE_NUM) /
DP_CLK_FUDGE_DEN;
+
for (i = 1; i < ARRAY_SIZE(ti_sn_bridge_dp_rate_lut) - 1; i++)
if (ti_sn_bridge_dp_rate_lut[i] > dp_rate_mhz)
break;
@@ -517,7 +523,7 @@ static void ti_sn_bridge_enable(struct drm_bridge *bridge)
CHA_DSI_LANES_MASK, val);
/* DP lane config */
- val = DP_NUM_LANES(pdata->dsi->lanes - 1);
+ val = DP_NUM_LANES(pdata->dp_lanes - 1);
regmap_update_bits(pdata->regmap, SN_SSC_CONFIG_REG, DP_NUM_LANES_MASK,
val);
--
2.24.1.735.g03f4e72817-goog
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 4/9] drm/bridge: ti-sn65dsi86: Config number of DP lanes Mo' Betta
The driver used to say that the value to program into bridge register 0x93 was dp_lanes - 1. Looking at the datasheet for the bridge, this is wrong. The data sheet says: * 1 = 1 lane * 2 = 2 lanes * 3 = 4 lanes A more proper way to express this encoding is min(dp_lanes, 3). At the moment this change has zero effect because we've hardcoded the number of DP lanes to 4. ...and (4 - 1) == min(4, 3). How fortunate! ...but soon we'll stop hardcoding the number of lanes. Signed-off-by: Douglas Anderson Tested-by: Rob Clark Reviewed-by: Rob Clark --- Changes in v2: None drivers/gpu/drm/bridge/ti-sn65dsi86.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/bridge/ti-sn65dsi86.c b/drivers/gpu/drm/bridge/ti-sn65dsi86.c index ab644baaf90c..d55d19759796 100644 --- a/drivers/gpu/drm/bridge/ti-sn65dsi86.c +++ b/drivers/gpu/drm/bridge/ti-sn65dsi86.c @@ -523,7 +523,7 @@ static void ti_sn_bridge_enable(struct drm_bridge *bridge) CHA_DSI_LANES_MASK, val); /* DP lane config */ - val = DP_NUM_LANES(pdata->dp_lanes - 1); + val = DP_NUM_LANES(min(pdata->dp_lanes, 3)); regmap_update_bits(pdata->regmap, SN_SSC_CONFIG_REG, DP_NUM_LANES_MASK, val); -- 2.24.1.735.g03f4e72817-goog ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 0/9] drm/bridge: ti-sn65dsi86: Improve support for AUO B116XAK01 + other DP
This series contains a pile of patches that was created to support
hooking up the AUO B116XAK01 panel to the eDP side of the bridge. In
general it should be useful for hooking up a wider variety of DP
panels to the bridge, especially those with lower resolution and lower
bits per pixel.
The overall result of this series:
* Allows panels with fewer than 4 DP lanes hooked up to work.
* Optimizes the link rate for panels with 6 bpp.
* Supports trying more than one link rate when training if the main
link rate didn't work.
* Avoids invalid link rates.
It's not expected that this series will break any existing users but
testing is always good.
To support the AUO B116XAK01, we could actually stop at the ("Use
18-bit DP if we can") patch since that causes the panel to run at a
link rate of 1.62 which works. The patches to try more than one link
rate were all developed prior to realizing that I could just use
18-bit mode and were validated with that patch reverted.
These patches were tested on sdm845-cheza atop mainline as of
2019-12-13 and also on another board (the one with AUO B116XAK01) atop
a downstream kernel tree.
This patch series doesn't do anything to optimize the MIPI link and
only focuses on the DP link. For instance, it's left as an exercise
to the reader to see if we can use the 666-packed mode on the MIPI
link and save some power (because we could lower the clock rate).
I am nowhere near a display expert and my knowledge of DP and MIPI is
pretty much zero. If something about this patch series smells wrong,
it probably is. Please let know and I'll try to fix it.
Changes in v2:
- Squash in maybe-uninitialized fix from Rob Clark.
- Patch ("Avoid invalid rates") replaces ("Skip non-standard DP rates")
Douglas Anderson (9):
drm/bridge: ti-sn65dsi86: Split the setting of the dp and dsi rates
drm/bridge: ti-sn65dsi86: zero is never greater than an unsigned int
drm/bridge: ti-sn65dsi86: Don't use MIPI variables for DP link
drm/bridge: ti-sn65dsi86: Config number of DP lanes Mo' Betta
drm/bridge: ti-sn65dsi86: Read num lanes from the DP sink
drm/bridge: ti-sn65dsi86: Use 18-bit DP if we can
drm/bridge: ti-sn65dsi86: Group DP link training bits in a function
drm/bridge: ti-sn65dsi86: Train at faster rates if slower ones fail
drm/bridge: ti-sn65dsi86: Avoid invalid rates
drivers/gpu/drm/bridge/ti-sn65dsi86.c | 277 ++
1 file changed, 234 insertions(+), 43 deletions(-)
--
2.24.1.735.g03f4e72817-goog
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [GIT PULL FOR v5.6] R-Car DU & LVDS decoder
Hi Neil,
On Tue, Dec 17, 2019 at 02:23:57PM +0100, Neil Armstrong wrote:
> On 17/12/2019 13:43, Daniel Vetter wrote:
> > On Thu, Nov 28, 2019 at 04:45:24AM +0200, Laurent Pinchart wrote:
> >> Hi Dave,
> >>
> >> The following changes since commit
> >> acc61b8929365e63a3e8c8c8913177795aa45594:
> >>
> >> Merge tag 'drm-next-5.5-2019-11-22' of
> >> git://people.freedesktop.org/~agd5f/linux into drm-next (2019-11-26
> >> 08:40:23 +1000)
> >>
> >> are available in the Git repository at:
> >>
> >> git://linuxtv.org/pinchartl/media.git tags/du-next-20191128
> >>
> >> for you to fetch changes up to c43bcd64c7c703ff7196f74cb6bfc67e35b562d9:
> >>
> >> dt-bindings: display: bridge: lvds-codec: Document ti,ds90cf384a
> >> (2019-11-28 03:55:56 +0200)
> >>
> >>
> >> - R-Car DU Color Management Module support
> >> - LVDS decoder support
> >>
> >>
> >> Fabrizio Castro (9):
> >> dt-bindings: display: bridge: Convert lvds-transmitter binding to
> >> json-schema
> >> dt-bindings: display: bridge: lvds-transmitter: Document
> >> powerdown-gpios
> >> dt-bindings: display: bridge: lvds-transmitter: Absorb
> >> ti,ds90c185.txt
> >> dt-bindings: display: bridge: lvds-transmitter: Document
> >> "ti,sn75lvds83"
> >> drm/bridge: Repurpose lvds-encoder.c
> >> drm/bridge: lvds-codec: Add "lvds-decoder" support
> >> drm/bridge: lvds-codec: Simplify panel DT node localisation
> >> dt-bindings: display: bridge: Repurpose lvds-encoder
> >> dt-bindings: display: bridge: lvds-codec: Document ti,ds90cf384a
> >
> > Why bridge stuff not in drm-misc?
> >
> > Also, and the reason I've not pulled this:
> >
> > dim: c43bcd64c7c7 ("dt-bindings: display: bridge: lvds-codec: Document
> > ti,ds90cf384a"): committer Signed-off-by missing.
> > dim: bb29b64ac196 ("dt-bindings: display: bridge: Repurpose lvds-encoder"):
> > committer Signed-off-by missing.
> > dim: 5db8ae664da4 ("drm/bridge: lvds-codec: Simplify panel DT node
> > localisation"): committer Signed-off-by missing.
> > dim: e94bb2bf88e2 ("drm/bridge: lvds-codec: Add "lvds-decoder" support"):
> > committer Signed-off-by missing.
> > dim: b6fafff0c335 ("drm/bridge: Repurpose lvds-encoder.c"): committer
> > Signed-off-by missing.
> > dim: 1c060450177f ("dt-bindings: display: bridge: lvds-transmitter:
> > Document "ti,sn75lvds83""): committer Signed-off-by missing.
> > dim: d2f2a148ba7c ("dt-bindings: display: bridge: lvds-transmitter: Absorb
> > ti,ds90c185.txt"): committer Signed-off-by missing.
> > dim: 07e5c8731999 ("dt-bindings: display: bridge: lvds-transmitter:
> > Document powerdown-gpios"): committer Signed-off-by missing.
> > dim: 0fa9d2323ed3 ("dt-bindings: display: bridge: Convert lvds-transmitter
> > binding to json-schema"): committer Signed-off-by missing.
> > dim: ERROR: issues in commits detected, aborting
>
> Laurent, I can push them into drm-misc if needed, so it will unlock boris.
Thanks for the offer. I've gathered all the bridge patches that are not
specific to Renesas in
The following changes since commit d1eef1c619749b2a57e514a3fa67d9a516ffa919:
Linux 5.5-rc2 (2019-12-15 15:16:08 -0800)
are available in the Git repository at:
git://linuxtv.org/pinchartl/media.git drm/bridge/next
for you to fetch changes up to efe52545bccf56d62c1fd1704937a971fa2d24f8:
dt-bindings: display: bridge: lvds-codec: Absorb thine,thc63lvdm83d.txt
(2019-12-18 02:37:47 +0200)
Fabrizio Castro (10):
dt-bindings: display: bridge: Convert lvds-transmitter binding to
json-schema
dt-bindings: display: bridge: lvds-transmitter: Document powerdown-gpios
dt-bindings: display: bridge: lvds-transmitter: Absorb ti,ds90c185.txt
dt-bindings: display: bridge: lvds-transmitter: Document "ti,sn75lvds83"
drm/bridge: Repurpose lvds-encoder.c
drm/bridge: lvds-codec: Add "lvds-decoder" support
drm/bridge: lvds-codec: Simplify panel DT node localisation
dt-bindings: display: bridge: Repurpose lvds-encoder
dt-bindings: display: bridge: lvds-codec: Document ti,ds90cf384a
dt-bindings: display: bridge: lvds-codec: Absorb thine,thc63lvdm83d.txt
.../bindings/display/bridge/lvds-codec.yaml| 131 +
.../bindings/display/bridge/lvds-transmitter.txt | 66 -
.../bindings/display/bridge/thine,thc63lvdm83d.txt | 50 ---
.../bindings/display/bridge/ti,ds90c185.txt| 55
drivers/gpu/drm/bridge/Kconfig | 8 +-
drivers/gpu/drm/bridge/Makefile| 2 +-
drivers/gpu/drm/bridge/lvds-codec.c| 151
drivers/gpu/drm/bridge/lvds-encoder.c | 155 -
8 files changed, 287 insertions(+), 331 deletions(-)
create mode 100644
Documentation/d
Re: [PATCH v6 0/6] Add dual-LVDS panel support to EK874
Hi Fabrizio, Thank you for the patch. On Tue, Dec 17, 2019 at 01:45:55PM +, Fabrizio Castro wrote: > Dear All, > > this series adds support for dual-LVDS panel IDK-2121WR > from Advantech: > https://buy.advantech.eu/Displays/Embedded-LCD-Kits-High-Brightness/model-IDK-2121WR-K2FHA2E.htm > > V6 reworks patch "drm: rcar-du: lvds: Allow for even and odd pixels swap", > and rebases the series on top of patch: > https://patchwork.kernel.org/patch/11295991/ I've taken patch 1/6 to 4/6 in my tree. I expect Geert to take 6/6. For 5/6, I'll give Rob a chance to review the patch. Sam, could you handle it afterwards ? > Fabrizio Castro (6): > drm: of: Add drm_of_lvds_get_dual_link_pixel_order > drm: rcar-du: lvds: Improve identification of panels > drm: rcar-du: lvds: Get dual link configuration from DT > drm: rcar-du: lvds: Allow for even and odd pixels swap > dt-bindings: display: Add idk-2121wr binding > arm64: dts: renesas: Add EK874 board with idk-2121wr display support > > .../display/panel/advantech,idk-2121wr.yaml| 128 +++ > arch/arm64/boot/dts/renesas/Makefile | 3 +- > .../boot/dts/renesas/r8a774c0-ek874-idk-2121wr.dts | 116 + > drivers/gpu/drm/drm_of.c | 116 + > drivers/gpu/drm/rcar-du/rcar_lvds.c| 180 > - > include/drm/drm_of.h | 20 +++ > 6 files changed, 483 insertions(+), 80 deletions(-) > create mode 100644 > Documentation/devicetree/bindings/display/panel/advantech,idk-2121wr.yaml > create mode 100644 arch/arm64/boot/dts/renesas/r8a774c0-ek874-idk-2121wr.dts -- Regards, Laurent Pinchart ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm: rcar-du: Add r8a77980 support
On Mon, Dec 16, 2019 at 11:37:00AM +0100, Geert Uytterhoeven wrote: > On Mon, Dec 16, 2019 at 10:47 AM Kieran Bingham wrote: > > On 13/12/2019 00:48, Laurent Pinchart wrote: > >> On Mon, Dec 09, 2019 at 12:41:07PM +, Kieran Bingham wrote: > >>> On 13/09/2019 10:03, Laurent Pinchart wrote: > On Fri, Sep 13, 2019 at 10:21:29AM +0200, Simon Horman wrote: > > On Thu, Sep 12, 2019 at 01:00:41PM +0300, Sergei Shtylyov wrote: > >> On 11.09.2019 22:25, Kieran Bingham wrote: > >> > >>> Add direct support for the r8a77980 (V3H). > >>> > >>> The V3H shares a common, compatible configuration with the r8a77970 > >>> (V3M) so that device info structure is reused. > >> > >>Do we really need to add yet another compatible in this case? > >> I just added r8a77970 to the compatible prop in the r8a77980 DT. > >> That's why > >> a patch like this one didn't get posted by me. > > > > The reason for having per-SoC compat strings is that the IP blocks > > are not versioned and while we can observe that there are similarities > > between, f.e. the DU on the r8a77970 and r8a77980, we can't be certain > > that > > differences may not emerge at some point. By having per-SoC compat > > strings > > we have the flexibility for the driver to address any such differences > > as > > the need arises. > > > > My recollection is that this scheme has been adopted for non-versioned > > Renesas IP blocks since June 2015 and uses of this scheme well before > > that. > > Sure, but we could use > > compatible = "renesas,du-r8a77980", "renesas,du-r8a77970"; > > > > We already do in arch/arm64/boot/dts/renesas/r8a77980.dtsi. > > > > However that is the *only* non r8a77980 reference in the file so it, > > itself looks *very* much out of place. > > > > > > Furthermore, the main purpose of this patch is that we clearly document > > the driver as supporting the r8a77980 in the bindings (No mention that > > you must use the ..970 binding), yet in actual fact - the driver could > > not currently support loading a device with the following compatible: > > > > compatible = "renesas,du-r8a77980"; > > > > > in DT without updating the driver. If the r8a77980 turns out to be > different, we'll then update the driver without a need to modify DT. I'm > fine either way, so > > Reviewed-by: Laurent Pinchart > >>> > >>> Thanks, > >>> > >>> This patch has an RB tag from you, and Simon, but alas I don't believe > >>> it has been picked up in your drm/du/next branch. > >>> > >>> Is this patch acceptable? Or do I need to repost? > >> > >> Could you just confirm I should apply this patch, and not go for the > >> alternative proposal above ? > > > > I believe the alternative proposal above is what we have today isn't it? > > > > > > Yes, I do believe we should apply this patch. > > +1. > > I'm waiting for the driver part to go upstream, so I can apply the DTS patch. > Note that this will lead to a messy situation in LTS, as the DTS patch will > likely be backported, so the driver part must be backported, too. Reviewed-by: Laurent Pinchart and taken in my tree. > > I'm going to assume you haven't read the other arguments on this thread > > so I'll paste them here: > > Thanks for recollecting! ;-) -- Regards, Laurent Pinchart ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v4 06/13] drm/bridge: lvds-codec: Add "lvds-decoder" support
On Tue, Dec 17, 2019 at 10:06:14PM +, Fabrizio Castro wrote:
> On 17 December 2019 13:54, Laurent Pinchart wrote:
> > On Tue, Dec 17, 2019 at 01:38:51PM +0100, Geert Uytterhoeven wrote:
> >> On Tue, Dec 17, 2019 at 1:31 PM Fabrizio Castro wrote:
> >>> On 17 December 2019 12:21, Geert Uytterhoeven wrote:
> On Tue, Dec 17, 2019 at 12:03 PM Fabrizio Castro wrote:
> > On 13 December 2019 17:11, Laurent Pinchart wrote:
> >> On Wed, Nov 13, 2019 at 03:51:25PM +, Fabrizio Castro wrote:
> >>> Add support for transparent LVDS decoders by adding a new
> >>> compatible string ("lvds-decoder") to the driver.
> >>> This patch also adds member connector_type to struct lvds_codec,
> >>> and that's because LVDS decoders have a different connector type
> >>> from LVDS encoders. We fill this new member up with the data
> >>> matching the compatible string.
> >>>
> >>> Signed-off-by: Fabrizio Castro
> >>>
> >>> --- a/drivers/gpu/drm/bridge/lvds-codec.c
> >>> +++ b/drivers/gpu/drm/bridge/lvds-codec.c
> >>>
> >>> @@ -65,6 +67,7 @@ static int lvds_codec_probe(struct platform_device
> >>> *pdev)
> >>> if (!lvds_codec)
> >>> return -ENOMEM;
> >>>
> >>> + lvds_codec->connector_type =
> >>> (u32)of_device_get_match_data(&pdev->dev);
> >>
> >> I'm now getting a compilation failure here:
> >>
> >> drivers/gpu/drm/bridge/lvds-codec.c: In function ‘lvds_codec_probe’:
> >> drivers/gpu/drm/bridge/lvds-codec.c:68:31: error: cast from pointer to
> >> integer of different size [-Werror=pointer-to-int-cast]
> >> lvds_codec->connector_type =
> >> (u32)of_device_get_match_data(&pdev->dev);
> >>^
> >>
> >> The fix should be simple:
> >>
> >> lvds_codec->connector_type =
> >> (uintptr_t)of_device_get_match_data(dev);
> >>
> >> I'm bothered by the fact that I've compiled this before without any
> >> issue, so this really puzzles me. Do you get the same warning ?
> >
> > The warning appears when compiling for arm64, understandably so.
> > We must have compiled this for arm only the first time around.
> >
> > I think the right way to solve this is to either cast to
> > (u32)(uintptr_t) or (u32)(unsigned long).
>
> Just casting to uintptr_t should be sufficient.
> >>>
> >>> It should be sufficient for the compiler, but I have seen examples where
> >>> people
> >>> preferred to be explicit, like in:
> >>> drivers/mailbox/mtk-cmdq-mailbox.c
> >>> drivers/leds/leds-pm8058.c
> >>>
> >>> Since the kernel is increasing its tightness with respect to warnings, I
> >>> personally prefer
> >>> (u32)(uintptr_t), even though not strictly necessary, but I am fine with
> >>> (uintptr_t) if you
> >>> don't like (u32)(uintptr_t).
> >>
> >> It depends. I try to have as few casts as possible ("casts are evil").
> >>
> >> While adding the extra (u32) cast makes it clearer that the intended
> >> result is a u32 (for now), it will cause silent truncation on 64-bit if
> >> connector_type is ever enlarged to unsigned long, and larger values are
> >> used.
> >>
> >> In this particular case this is unlikely, though, as unsigned long would
> >> still be 32-bit on 32-bit platforms, so the larger values cannot be
> >> used.
> >
> > I also try to add as few casts as possible, so (uintptr_t) would be my
> > preference.
> >
> > Fabrizio, could you submit a new version of this patch with the problem
> > fixed (and with the casts you decide to use, but using uintptr_t instead
> > of unsigned long in any case) ?
>
> Will send a new version tomorrow with (uintptr_t)
Done as v4.1 :-)
--
Regards,
Laurent Pinchart
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v4.1 06/13] drm/bridge: lvds-codec: Add "lvds-decoder" support
From: Fabrizio Castro
Add support for transparent LVDS decoders by adding a new
compatible string ("lvds-decoder") to the driver.
This patch also adds member connector_type to struct lvds_codec,
and that's because LVDS decoders have a different connector type
from LVDS encoders. We fill this new member up with the data
matching the compatible string.
Signed-off-by: Fabrizio Castro
Reviewed-by: Laurent Pinchart
[Fix pointer to int cast warning]
Signed-off-by: Laurent Pinchart
---
Changes since v4:
- Fix compiler warning to to a cast from 64-bit pointer to 32-bit
integer
v3->v4:
* New patch
---
drivers/gpu/drm/bridge/lvds-codec.c | 19 ---
1 file changed, 16 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/bridge/lvds-codec.c
b/drivers/gpu/drm/bridge/lvds-codec.c
index b5801a287a0a..d072a76b20d9 100644
--- a/drivers/gpu/drm/bridge/lvds-codec.c
+++ b/drivers/gpu/drm/bridge/lvds-codec.c
@@ -7,6 +7,7 @@
#include
#include
#include
+#include
#include
#include
@@ -17,6 +18,7 @@ struct lvds_codec {
struct drm_bridge bridge;
struct drm_bridge *panel_bridge;
struct gpio_desc *powerdown_gpio;
+ u32 connector_type;
};
static int lvds_codec_attach(struct drm_bridge *bridge)
@@ -65,6 +67,7 @@ static int lvds_codec_probe(struct platform_device *pdev)
if (!lvds_codec)
return -ENOMEM;
+ lvds_codec->connector_type = (uintptr_t)of_device_get_match_data(dev);
lvds_codec->powerdown_gpio = devm_gpiod_get_optional(dev, "powerdown",
GPIOD_OUT_HIGH);
if (IS_ERR(lvds_codec->powerdown_gpio)) {
@@ -105,7 +108,7 @@ static int lvds_codec_probe(struct platform_device *pdev)
lvds_codec->panel_bridge =
devm_drm_panel_bridge_add_typed(dev, panel,
- DRM_MODE_CONNECTOR_LVDS);
+ lvds_codec->connector_type);
if (IS_ERR(lvds_codec->panel_bridge))
return PTR_ERR(lvds_codec->panel_bridge);
@@ -133,8 +136,18 @@ static int lvds_codec_remove(struct platform_device *pdev)
}
static const struct of_device_id lvds_codec_match[] = {
- { .compatible = "lvds-encoder" },
- { .compatible = "thine,thc63lvdm83d" },
+ {
+ .compatible = "lvds-decoder",
+ .data = (void *)DRM_MODE_CONNECTOR_DPI,
+ },
+ {
+ .compatible = "lvds-encoder",
+ .data = (void *)DRM_MODE_CONNECTOR_LVDS,
+ },
+ {
+ .compatible = "thine,thc63lvdm83d",
+ .data = (void *)DRM_MODE_CONNECTOR_LVDS,
+ },
{},
};
MODULE_DEVICE_TABLE(of, lvds_codec_match);
--
Regards,
Laurent Pinchart
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] udmabuf: fix dma-buf cpu access
I'm just going to put Chia's review comment here since it sums
the issue rather nicely:
"(1) Semantically, a dma-buf is in DMA domain. CPU access from the
importer must be surrounded by {begin,end}_cpu_access. This gives the
exporter a chance to move the buffer to the CPU domain temporarily.
(2) When the exporter itself has other means to do CPU access, it is
only reasonable for the exporter to move the buffer to the CPU domain
before access, and to the DMA domain after access. The exporter can
potentially reuse {begin,end}_cpu_access for that purpose.
Because of (1), udmabuf does need to implement the
{begin,end}_cpu_access hooks. But "begin" should mean
dma_sync_sg_for_cpu and "end" should mean dma_sync_sg_for_device.
Because of (2), if userspace wants to continuing accessing through the
memfd mapping, it should call udmabuf's {begin,end}_cpu_access to
avoid cache issues."
Reported-by: Chia-I Wu
Suggested-by: Chia-I Wu
Fixes: 284562e1f348 ("udmabuf: implement begin_cpu_access/end_cpu_access hooks")
Signed-off-by: Gurchetan Singh
---
drivers/dma-buf/udmabuf.c | 7 +++
1 file changed, 3 insertions(+), 4 deletions(-)
diff --git a/drivers/dma-buf/udmabuf.c b/drivers/dma-buf/udmabuf.c
index 61b0a2cff874..acb26c627d27 100644
--- a/drivers/dma-buf/udmabuf.c
+++ b/drivers/dma-buf/udmabuf.c
@@ -122,9 +122,8 @@ static int begin_cpu_udmabuf(struct dma_buf *buf,
if (IS_ERR(ubuf->sg))
return PTR_ERR(ubuf->sg);
} else {
- dma_sync_sg_for_device(dev, ubuf->sg->sgl,
- ubuf->sg->nents,
- direction);
+ dma_sync_sg_for_cpu(dev, ubuf->sg->sgl, ubuf->sg->nents,
+ direction);
}
return 0;
@@ -139,7 +138,7 @@ static int end_cpu_udmabuf(struct dma_buf *buf,
if (!ubuf->sg)
return -EINVAL;
- dma_sync_sg_for_cpu(dev, ubuf->sg->sgl, ubuf->sg->nents, direction);
+ dma_sync_sg_for_device(dev, ubuf->sg->sgl, ubuf->sg->nents, direction);
return 0;
}
--
2.24.1.735.g03f4e72817-goog
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v7.1 5.7] drm: rcar-du: crtc: Control CMM operations
From: Jacopo Mondi
Implement CMM handling in the crtc begin and enable atomic callbacks,
and enable CMM unit through the Display Extensional Functions
register at group setup time.
Reviewed-by: Laurent Pinchart
Reviewed-by: Kieran Bingham
Signed-off-by: Jacopo Mondi
[Fix printk format modifier for size_t variable]
Signed-off-by: Laurent Pinchart
---
Changes since v7:
- Fix compilation warning on 32-bit platforms due to incorrect printk
modifier for a size_t variable (tested on both Gen2 and Gen3)
v6 -> v7
- Drop check for CMM in rcar_du_cmm_check as if the gamma_table property is
available, a CMM unit for this CRTC was registered
- Add TODO note to investigate how the activation order of CMM and CRTC
impact on the first displayed fram
---
drivers/gpu/drm/rcar-du/rcar_du_crtc.c | 61 +
drivers/gpu/drm/rcar-du/rcar_du_group.c | 10
drivers/gpu/drm/rcar-du/rcar_du_regs.h | 5 ++
3 files changed, 76 insertions(+)
diff --git a/drivers/gpu/drm/rcar-du/rcar_du_crtc.c
b/drivers/gpu/drm/rcar-du/rcar_du_crtc.c
index 23f1d6cc1719..84477d27e145 100644
--- a/drivers/gpu/drm/rcar-du/rcar_du_crtc.c
+++ b/drivers/gpu/drm/rcar-du/rcar_du_crtc.c
@@ -21,6 +21,7 @@
#include
#include
+#include "rcar_cmm.h"
#include "rcar_du_crtc.h"
#include "rcar_du_drv.h"
#include "rcar_du_encoder.h"
@@ -474,6 +475,45 @@ static void rcar_du_crtc_wait_page_flip(struct
rcar_du_crtc *rcrtc)
rcar_du_crtc_finish_page_flip(rcrtc);
}
+/*
-
+ * Color Management Module (CMM)
+ */
+
+static int rcar_du_cmm_check(struct drm_crtc *crtc,
+struct drm_crtc_state *state)
+{
+ struct drm_property_blob *drm_lut = state->gamma_lut;
+ struct rcar_du_crtc *rcrtc = to_rcar_crtc(crtc);
+ struct device *dev = rcrtc->dev->dev;
+
+ if (!drm_lut)
+ return 0;
+
+ /* We only accept fully populated LUT tables. */
+ if (drm_color_lut_size(drm_lut) != CM2_LUT_SIZE) {
+ dev_err(dev, "invalid gamma lut size: %zu bytes\n",
+ drm_lut->length);
+ return -EINVAL;
+ }
+
+ return 0;
+}
+
+static void rcar_du_cmm_setup(struct drm_crtc *crtc)
+{
+ struct drm_property_blob *drm_lut = crtc->state->gamma_lut;
+ struct rcar_du_crtc *rcrtc = to_rcar_crtc(crtc);
+ struct rcar_cmm_config cmm_config = {};
+
+ if (!rcrtc->cmm)
+ return;
+
+ if (drm_lut)
+ cmm_config.lut.table = (struct drm_color_lut *)drm_lut->data;
+
+ rcar_cmm_setup(rcrtc->cmm, &cmm_config);
+}
+
/*
-
* Start/Stop and Suspend/Resume
*/
@@ -619,6 +659,9 @@ static void rcar_du_crtc_stop(struct rcar_du_crtc *rcrtc)
if (rcar_du_has(rcrtc->dev, RCAR_DU_FEATURE_VSP1_SOURCE))
rcar_du_vsp_disable(rcrtc);
+ if (rcrtc->cmm)
+ rcar_cmm_disable(rcrtc->cmm);
+
/*
* Select switch sync mode. This stops display operation and configures
* the HSYNC and VSYNC signals as inputs.
@@ -642,6 +685,11 @@ static int rcar_du_crtc_atomic_check(struct drm_crtc *crtc,
{
struct rcar_du_crtc_state *rstate = to_rcar_crtc_state(state);
struct drm_encoder *encoder;
+ int ret;
+
+ ret = rcar_du_cmm_check(crtc, state);
+ if (ret)
+ return ret;
/* Store the routes from the CRTC output to the DU outputs. */
rstate->outputs = 0;
@@ -667,6 +715,8 @@ static void rcar_du_crtc_atomic_enable(struct drm_crtc
*crtc,
struct rcar_du_crtc_state *rstate = to_rcar_crtc_state(crtc->state);
struct rcar_du_device *rcdu = rcrtc->dev;
+ if (rcrtc->cmm)
+ rcar_cmm_enable(rcrtc->cmm);
rcar_du_crtc_get(rcrtc);
/*
@@ -686,6 +736,13 @@ static void rcar_du_crtc_atomic_enable(struct drm_crtc
*crtc,
}
rcar_du_crtc_start(rcrtc);
+
+ /*
+* TODO: The chip manual indicates that CMM tables should be written
+* after the DU channel has been activated. Investigate the impact
+* of this restriction on the first displayed frame.
+*/
+ rcar_du_cmm_setup(crtc);
}
static void rcar_du_crtc_atomic_disable(struct drm_crtc *crtc,
@@ -739,6 +796,10 @@ static void rcar_du_crtc_atomic_begin(struct drm_crtc
*crtc,
*/
rcar_du_crtc_get(rcrtc);
+ /* If the active state changed, we let .atomic_enable handle CMM. */
+ if (crtc->state->color_mgmt_changed && !crtc->state->active_changed)
+ rcar_du_cmm_setup(crtc);
+
if (rcar_du_has(rcrtc->dev, RCAR_DU_FEATURE_VSP1_SOURCE))
rcar_du_vsp_atomic_begin(rcrtc);
}
diff --git a/drivers/gpu/drm/rcar-du/rcar_du_group.c
b/drivers/gpu/drm/rcar-du/rcar_du_group.c
index 9eee47969e77..88a783ceb3e9 100644
--- a/drivers/gpu/d
Re: [PATCH v3 2/3] dt-bindings: display: panel: Add binding document for Xinpeng XPP055C272
Hi Maxime, Am Dienstag, 17. Dezember 2019, 17:01:22 CET schrieb Maxime Ripard: > On Tue, Dec 17, 2019 at 04:08:49PM +0100, Heiko Stübner wrote: > > Am Dienstag, 17. Dezember 2019, 15:24:46 CET schrieb Maxime Ripard: > > > Hi, > > > > > > On Tue, Dec 17, 2019 at 03:07:02PM +0100, Heiko Stuebner wrote: > > > > From: Heiko Stuebner > > > > > > > > The XPP055C272 is a 5.5" 720x1280 DSI display. > > > > > > > > changes in v2: > > > > - add size info into binding title (Sam) > > > > - add more required properties (Sam) > > > > > > > > Signed-off-by: Heiko Stuebner > > > > Reviewed-by: Sam Ravnborg > > > > --- > > > > .../display/panel/xinpeng,xpp055c272.yaml | 48 +++ > > > > 1 file changed, 48 insertions(+) > > > > create mode 100644 > > > > Documentation/devicetree/bindings/display/panel/xinpeng,xpp055c272.yaml > > > > > > > > diff --git > > > > a/Documentation/devicetree/bindings/display/panel/xinpeng,xpp055c272.yaml > > > > > > > > b/Documentation/devicetree/bindings/display/panel/xinpeng,xpp055c272.yaml > > > > new file mode 100644 > > > > index ..2d0fc97d735c > > > > --- /dev/null > > > > +++ > > > > b/Documentation/devicetree/bindings/display/panel/xinpeng,xpp055c272.yaml > > > > @@ -0,0 +1,48 @@ > > > > +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) > > > > +%YAML 1.2 > > > > +--- > > > > +$id: http://devicetree.org/schemas/display/panel/sony,acx424akp.yaml# > > > > > > The ID doesn't match the file name. > > > > > > Did you run dt_bindings_check? > > > > Thanks for that pointer ... I did run dtbs_check on the binding and was > > sooo happy to not find any panel errors in the pages of other dt errors > > but till now didn't realize that there's also a dtbinding_check. > > dt_bindings_check is a sanity check on the bindings > themselves. dtbs_check is using those bindings to check the device > trees. > > dtbs_check used to have a dependency on dt_bindings_check, but it got > removed recently. > > Maxime > > > > > Will keep that in mind for future bindings - and of course fix things > > in the next version. > > > > > > > > +$schema: http://devicetree.org/meta-schemas/core.yaml# > > > > + > > > > +title: Xinpeng XPP055C272 5.5in 720x1280 DSI panel > > > > + > > > > +maintainers: > > > > + - Heiko Stuebner > > > > + > > > > +allOf: > > > > + - $ref: panel-common.yaml# > > > > + > > > > +properties: > > > > + compatible: > > > > +const: xinpeng,xpp055c272 > > > > + reg: true > > > > + backlight: true > > > > + port: true > > > > > > What is the port supposed to be doing? > > > > Hooking the display up to the dsi controller. But you're right, > > works without port as well with these single-dsi displays. > > > > I just remember needing one for the Gru-Scarlet display that needed > > to connect to two dsi controllers. > > > > So I'll drop the port node here and from my board devicetree. > > It's not really what I meant though :) > > If it's needed then we should definitely have it, but we should > document our expectations here: is it the input port ? output? in > which case do we want to use it since it's optional, etc. The port was actually unnecessary. As far as I understand dsi stuff, the common case is the panel as subnode of the dsi controller and the controller then finding the display itself automatically. If you look at "drm/bridge/synopsys: dsi: use mipi_dsi_device to find panel or bridge" [0] I just sent, you'll see that the dw-mipi-dsi used drm_of_find_panel_or_bridge to find its panel/bridge thus requiring port connections in all cases where it had the dsi-device available already, so wouldn't need to use ports for it. Or I'm completely wrong and port usage is better, we'll see :-D Heiko [0] https://patchwork.freedesktop.org/patch/345666/ ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/bridge/synopsys: dsi: use mipi_dsi_device to find panel or bridge
From: Heiko Stuebner
Right now the dsi driver uses drm_of_find_panel_or_bridge() to find a
connected panel or bridge. But this requires an of-graph connection
between the dsi-host and dsi-device, where normal bindings for regular
panels just expect the dsi device to be a subnode of the actual dsi host
not requiring ports.
drm_of_find_panel_or_bridge is used to find panel/bridge under the actual
device-node of the dsi device, but as this happens in the dsi_host_attach
callback we already have the dsi-device and its device-node available and
therefore can just call the relevant panel+bridge functions ourself,
making it work as well in setups without port-connections.
Tested on a Rockchip px30 single-dsi with panels form Leadtek and Xinpeng
as well on Gru-Scarlet (rk3399) with dual-dsi (and thus port-connections
to both dsi controllers) connected to the Innotek display variant.
changes in v2:
- rework commit message, rereading what I had written was just too
cringe-worthy ;-)
Signed-off-by: Heiko Stuebner
---
drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c | 17 ++---
1 file changed, 10 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c
b/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c
index 981d532cdd59..4b4961e7c680 100644
--- a/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c
+++ b/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c
@@ -26,6 +26,7 @@
#include
#include
#include
+#include
#include
#include
@@ -310,16 +311,16 @@ static int dw_mipi_dsi_host_attach(struct mipi_dsi_host
*host,
dsi->format = device->format;
dsi->mode_flags = device->mode_flags;
- ret = drm_of_find_panel_or_bridge(host->dev->of_node, 1, 0,
- &panel, &bridge);
- if (ret)
- return ret;
-
- if (panel) {
+ panel = of_drm_find_panel(device->dev.of_node);
+ if (!IS_ERR(panel)) {
bridge = drm_panel_bridge_add_typed(panel,
DRM_MODE_CONNECTOR_DSI);
if (IS_ERR(bridge))
return PTR_ERR(bridge);
+ } else {
+ bridge = of_drm_find_bridge(device->dev.of_node);
+ if (!bridge)
+ return -EPROBE_DEFER;
}
dsi->panel_bridge = bridge;
@@ -340,6 +341,7 @@ static int dw_mipi_dsi_host_detach(struct mipi_dsi_host
*host,
{
struct dw_mipi_dsi *dsi = host_to_dsi(host);
const struct dw_mipi_dsi_plat_data *pdata = dsi->plat_data;
+ struct drm_bridge *bridge;
int ret;
if (pdata->host_ops && pdata->host_ops->detach) {
@@ -348,7 +350,8 @@ static int dw_mipi_dsi_host_detach(struct mipi_dsi_host
*host,
return ret;
}
- drm_of_panel_bridge_remove(host->dev->of_node, 1, 0);
+ bridge = of_drm_find_bridge(device->dev.of_node);
+ drm_panel_bridge_remove(bridge);
drm_bridge_remove(&dsi->bridge);
--
2.24.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/bridge/synopsys: dsi: use mipi_dsi_device to find panel or bridge
From: Heiko Stuebner
Right now the dsi driver uses drm_of_find_panel_or_bridge() to find a
connected panel or bridge. But this requires an of-graph connection
between the dsi-host and dsi-device, where normal bindings for regular
panels just expect the dsi device to be a subnode of the actual dsi host
not requiring port connections.
drm_of_find_panel_or_bridge used to find the actual device-node of the
dsi device, but as this happens in the dsi_host_attach callback we already
have the dsi-device and its device-node available already, so can just
call the relevant panel+bridge functions ourself, making it work as well
in setups without port-connections.
Tested on a Rockchip px30 single-dsi with panels form Leadtek and Xinpeng
as well on Gru-Scarlet (rk3399) with dual-dsi (and therefore ports)
connected to the Innotek display variant.
Signed-off-by: Heiko Stuebner
---
drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c | 17 ++---
1 file changed, 10 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c
b/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c
index 981d532cdd59..4b4961e7c680 100644
--- a/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c
+++ b/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c
@@ -26,6 +26,7 @@
#include
#include
#include
+#include
#include
#include
@@ -310,16 +311,16 @@ static int dw_mipi_dsi_host_attach(struct mipi_dsi_host
*host,
dsi->format = device->format;
dsi->mode_flags = device->mode_flags;
- ret = drm_of_find_panel_or_bridge(host->dev->of_node, 1, 0,
- &panel, &bridge);
- if (ret)
- return ret;
-
- if (panel) {
+ panel = of_drm_find_panel(device->dev.of_node);
+ if (!IS_ERR(panel)) {
bridge = drm_panel_bridge_add_typed(panel,
DRM_MODE_CONNECTOR_DSI);
if (IS_ERR(bridge))
return PTR_ERR(bridge);
+ } else {
+ bridge = of_drm_find_bridge(device->dev.of_node);
+ if (!bridge)
+ return -EPROBE_DEFER;
}
dsi->panel_bridge = bridge;
@@ -340,6 +341,7 @@ static int dw_mipi_dsi_host_detach(struct mipi_dsi_host
*host,
{
struct dw_mipi_dsi *dsi = host_to_dsi(host);
const struct dw_mipi_dsi_plat_data *pdata = dsi->plat_data;
+ struct drm_bridge *bridge;
int ret;
if (pdata->host_ops && pdata->host_ops->detach) {
@@ -348,7 +350,8 @@ static int dw_mipi_dsi_host_detach(struct mipi_dsi_host
*host,
return ret;
}
- drm_of_panel_bridge_remove(host->dev->of_node, 1, 0);
+ bridge = of_drm_find_bridge(device->dev.of_node);
+ drm_panel_bridge_remove(bridge);
drm_bridge_remove(&dsi->bridge);
--
2.24.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v4 3/3] drm/panel: add panel driver for Xinpeng XPP055C272 panels
From: Heiko Stuebner
Base on the somewhat similar Rocktech driver but adapted for
panel-specific init of the XPP055C272.
changes in v3:
- remove wrong negative sync flags from display-mode to fix a display
artifact of the output getting move a tiny bit to the right
changes in v2:
- move to drm-panel-internal backlight handling (Sam)
- adapt to changes that happened to drm_panel structs+functions (Sam)
- sort includes (Sam)
- drop unnecessary DRV_NAME constant (Sam)
- do mipi_dsi_dcs_exit_sleep_mode and mipi_dsi_dcs_set_display_on
in panel prepare (not init_sequence) to keep symmetric (Sam)
Signed-off-by: Heiko Stuebner
---
drivers/gpu/drm/panel/Kconfig | 10 +
drivers/gpu/drm/panel/Makefile| 1 +
.../gpu/drm/panel/panel-xinpeng-xpp055c272.c | 400 ++
3 files changed, 411 insertions(+)
create mode 100644 drivers/gpu/drm/panel/panel-xinpeng-xpp055c272.c
diff --git a/drivers/gpu/drm/panel/Kconfig b/drivers/gpu/drm/panel/Kconfig
index f152bc4eeb53..fb1ded47677e 100644
--- a/drivers/gpu/drm/panel/Kconfig
+++ b/drivers/gpu/drm/panel/Kconfig
@@ -355,4 +355,14 @@ config DRM_PANEL_TRULY_NT35597_WQXGA
help
Say Y here if you want to enable support for Truly NT35597 WQXGA Dual
DSI
Video Mode panel
+
+config DRM_PANEL_XINPENG_XPP055C272
+ tristate "Xinpeng XPP055C272 panel driver"
+ depends on OF
+ depends on DRM_MIPI_DSI
+ depends on BACKLIGHT_CLASS_DEVICE
+ help
+ Say Y here if you want to enable support for the Xinpeng
+ XPP055C272 controller for 720x1280 LCD panels with MIPI/RGB/SPI
+ system interfaces.
endmenu
diff --git a/drivers/gpu/drm/panel/Makefile b/drivers/gpu/drm/panel/Makefile
index b6cd39fe0f20..71d7722146a7 100644
--- a/drivers/gpu/drm/panel/Makefile
+++ b/drivers/gpu/drm/panel/Makefile
@@ -38,3 +38,4 @@ obj-$(CONFIG_DRM_PANEL_TPO_TD028TTEC1) +=
panel-tpo-td028ttec1.o
obj-$(CONFIG_DRM_PANEL_TPO_TD043MTEA1) += panel-tpo-td043mtea1.o
obj-$(CONFIG_DRM_PANEL_TPO_TPG110) += panel-tpo-tpg110.o
obj-$(CONFIG_DRM_PANEL_TRULY_NT35597_WQXGA) += panel-truly-nt35597.o
+obj-$(CONFIG_DRM_PANEL_XINPENG_XPP055C272) += panel-xinpeng-xpp055c272.o
diff --git a/drivers/gpu/drm/panel/panel-xinpeng-xpp055c272.c
b/drivers/gpu/drm/panel/panel-xinpeng-xpp055c272.c
new file mode 100644
index ..1a7ded012344
--- /dev/null
+++ b/drivers/gpu/drm/panel/panel-xinpeng-xpp055c272.c
@@ -0,0 +1,400 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Xinpeng xpp055c272 5.5" MIPI-DSI panel driver
+ * Copyright (C) 2019 Theobroma Systems Design und Consulting GmbH
+ *
+ * based on
+ *
+ * Rockteck jh057n00900 5.5" MIPI-DSI panel driver
+ * Copyright (C) Purism SPC 2019
+ */
+
+#include
+#include
+#include
+#include
+
+#include
+#include
+
+#include
+#include
+#include
+#include
+#include
+#include
+
+/* Manufacturer specific Commands send via DSI */
+#define XPP055C272_CMD_ALL_PIXEL_OFF 0x22
+#define XPP055C272_CMD_ALL_PIXEL_ON0x23
+#define XPP055C272_CMD_SETDISP 0xb2
+#define XPP055C272_CMD_SETRGBIF0xb3
+#define XPP055C272_CMD_SETCYC 0xb4
+#define XPP055C272_CMD_SETBGP 0xb5
+#define XPP055C272_CMD_SETVCOM 0xb6
+#define XPP055C272_CMD_SETOTP 0xb7
+#define XPP055C272_CMD_SETPOWER_EXT0xb8
+#define XPP055C272_CMD_SETEXTC 0xb9
+#define XPP055C272_CMD_SETMIPI 0xbA
+#define XPP055C272_CMD_SETVDC 0xbc
+#define XPP055C272_CMD_SETPCR 0xbf
+#define XPP055C272_CMD_SETSCR 0xc0
+#define XPP055C272_CMD_SETPOWER0xc1
+#define XPP055C272_CMD_SETECO 0xc6
+#define XPP055C272_CMD_SETPANEL0xcc
+#define XPP055C272_CMD_SETGAMMA0xe0
+#define XPP055C272_CMD_SETEQ 0xe3
+#define XPP055C272_CMD_SETGIP1 0xe9
+#define XPP055C272_CMD_SETGIP2 0xea
+
+struct xpp055c272 {
+ struct device *dev;
+ struct drm_panel panel;
+ struct gpio_desc *reset_gpio;
+ struct regulator *vci;
+ struct regulator *iovcc;
+ bool prepared;
+};
+
+static inline struct xpp055c272 *panel_to_xpp055c272(struct drm_panel *panel)
+{
+ return container_of(panel, struct xpp055c272, panel);
+}
+
+#define dsi_generic_write_seq(dsi, cmd, seq...) do { \
+ static const u8 d[] = { seq }; \
+ int ret;\
+ ret = mipi_dsi_dcs_write(dsi, cmd, d, ARRAY_SIZE(d)); \
+ if (ret < 0)\
+ return ret; \
+ } while (0)
+
+static int xpp055c272_init_sequence(struct xpp055c272 *ctx)
+{
+ struct mipi_dsi_device *dsi = to_mipi_dsi_device(ctx->dev);
+ struct device *dev = ctx->dev;
+
+ /*
+* Init sequence was supplied by the panel vendor without much
+
[PATCH v2 2/3] dt-bindings: display: panel: Add binding document for Leadtek LTK500HD1829
From: Heiko Stuebner
The LTK500HD1829 is a 5.0" 720x1280 DSI display.
changes in v2:
- fix id (Maxime)
- drop port (Maxime)
Signed-off-by: Heiko Stuebner
---
.../display/panel/leadtek,ltk500hd1829.yaml | 47 +++
1 file changed, 47 insertions(+)
create mode 100644
Documentation/devicetree/bindings/display/panel/leadtek,ltk500hd1829.yaml
diff --git
a/Documentation/devicetree/bindings/display/panel/leadtek,ltk500hd1829.yaml
b/Documentation/devicetree/bindings/display/panel/leadtek,ltk500hd1829.yaml
new file mode 100644
index ..123869533a5e
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/panel/leadtek,ltk500hd1829.yaml
@@ -0,0 +1,47 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/display/panel/leadtek,ltk500hd1829.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Leadtek LTK500HD1829 5.0in 720x1280 DSI panel
+
+maintainers:
+ - Heiko Stuebner
+
+allOf:
+ - $ref: panel-common.yaml#
+
+properties:
+ compatible:
+const: leadtek,ltk500hd1829
+ reg: true
+ backlight: true
+ reset-gpios: true
+ iovcc-supply:
+ description: regulator that supplies the iovcc voltage
+ vcc-supply:
+ description: regulator that supplies the vcc voltage
+
+required:
+ - compatible
+ - reg
+ - backlight
+ - iovcc-supply
+ - vcc-supply
+
+additionalProperties: false
+
+examples:
+ - |
+dsi@ff45 {
+panel@0 {
+compatible = "leadtek,ltk500hd1829";
+reg = <0>;
+backlight = <&backlight>;
+iovcc-supply = <&vcc_1v8>;
+vcc-supply = <&vcc_2v8>;
+};
+};
+
+...
--
2.24.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v4 1/3] dt-bindings: Add vendor prefix for Xinpeng Technology
From: Heiko Stuebner Shenzhen Xinpeng Technology Co., Ltd produces for example display panels. Signed-off-by: Heiko Stuebner Acked-by: Sam Ravnborg --- Documentation/devicetree/bindings/vendor-prefixes.yaml | 2 ++ 1 file changed, 2 insertions(+) diff --git a/Documentation/devicetree/bindings/vendor-prefixes.yaml b/Documentation/devicetree/bindings/vendor-prefixes.yaml index 6046f4555852..85e7c26a05c7 100644 --- a/Documentation/devicetree/bindings/vendor-prefixes.yaml +++ b/Documentation/devicetree/bindings/vendor-prefixes.yaml @@ -1056,6 +1056,8 @@ patternProperties: description: Extreme Engineering Solutions (X-ES) "^xillybus,.*": description: Xillybus Ltd. + "^xinpeng,.*": +description: Shenzhen Xinpeng Technology Co., Ltd "^xlnx,.*": description: Xilinx "^xunlong,.*": -- 2.24.0 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 1/3] dt-bindings: Add vendor prefix for Leadtek Technology
From: Heiko Stuebner Shenzhen Leadtek Technology Co., Ltd. produces for example display and touch panels. Signed-off-by: Heiko Stuebner --- Documentation/devicetree/bindings/vendor-prefixes.yaml | 2 ++ 1 file changed, 2 insertions(+) diff --git a/Documentation/devicetree/bindings/vendor-prefixes.yaml b/Documentation/devicetree/bindings/vendor-prefixes.yaml index 85e7c26a05c7..4e6248ec5ed9 100644 --- a/Documentation/devicetree/bindings/vendor-prefixes.yaml +++ b/Documentation/devicetree/bindings/vendor-prefixes.yaml @@ -513,6 +513,8 @@ patternProperties: description: Lantiq Semiconductor "^lattice,.*": description: Lattice Semiconductor + "^leadtek,.*": +description: Shenzhen Leadtek Technology Co., Ltd. "^leez,.*": description: Leez "^lego,.*": -- 2.24.0 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v4 2/3] dt-bindings: display: panel: Add binding document for Xinpeng XPP055C272
From: Heiko Stuebner
The XPP055C272 is a 5.5" 720x1280 DSI display.
changes in v4:
- fix id (Maxime)
- drop port (Maxime)
changes in v2:
- add size info into binding title (Sam)
- add more required properties (Sam)
Signed-off-by: Heiko Stuebner
Reviewed-by: Sam Ravnborg
---
.../display/panel/xinpeng,xpp055c272.yaml | 47 +++
1 file changed, 47 insertions(+)
create mode 100644
Documentation/devicetree/bindings/display/panel/xinpeng,xpp055c272.yaml
diff --git
a/Documentation/devicetree/bindings/display/panel/xinpeng,xpp055c272.yaml
b/Documentation/devicetree/bindings/display/panel/xinpeng,xpp055c272.yaml
new file mode 100644
index ..378cf9e2549d
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/panel/xinpeng,xpp055c272.yaml
@@ -0,0 +1,47 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/display/panel/xinpeng,xpp055c272.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Xinpeng XPP055C272 5.5in 720x1280 DSI panel
+
+maintainers:
+ - Heiko Stuebner
+
+allOf:
+ - $ref: panel-common.yaml#
+
+properties:
+ compatible:
+const: xinpeng,xpp055c272
+ reg: true
+ backlight: true
+ reset-gpios: true
+ iovcc-supply:
+ description: regulator that supplies the iovcc voltage
+ vci-supply:
+ description: regulator that supplies the vci voltage
+
+required:
+ - compatible
+ - reg
+ - backlight
+ - iovcc-supply
+ - vci-supply
+
+additionalProperties: false
+
+examples:
+ - |
+dsi@ff45 {
+panel@0 {
+compatible = "xinpeng,xpp055c272";
+reg = <0>;
+backlight = <&backlight>;
+iovcc-supply = <&vcc_1v8>;
+vci-supply = <&vcc3v3_lcd>;
+};
+};
+
+...
--
2.24.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 3/3] drm/panel: add panel driver for Leadtek LTK500HD1829
From: Heiko Stuebner
The LTK500HD1829 is 5.5" DSI display.
Signed-off-by: Heiko Stuebner
---
drivers/gpu/drm/panel/Kconfig | 11 +
drivers/gpu/drm/panel/Makefile| 1 +
.../drm/panel/panel-leadtek-ltk500hd1829.c| 533 ++
3 files changed, 545 insertions(+)
create mode 100644 drivers/gpu/drm/panel/panel-leadtek-ltk500hd1829.c
diff --git a/drivers/gpu/drm/panel/Kconfig b/drivers/gpu/drm/panel/Kconfig
index fb1ded47677e..2ba8f4241680 100644
--- a/drivers/gpu/drm/panel/Kconfig
+++ b/drivers/gpu/drm/panel/Kconfig
@@ -98,6 +98,17 @@ config DRM_PANEL_KINGDISPLAY_KD097D04
24 bit RGB per pixel. It provides a MIPI DSI interface to
the host and has a built-in LED backlight.
+config DRM_PANEL_LEADTEK_LTK500HD1829
+ tristate "Leadtek LTK500HD1829 panel"
+ depends on OF
+ depends on DRM_MIPI_DSI
+ depends on BACKLIGHT_CLASS_DEVICE
+ help
+ Say Y here if you want to enable support for Kingdisplay kd097d04
+ TFT-LCD modules. The panel has a 1536x2048 resolution and uses
+ 24 bit RGB per pixel. It provides a MIPI DSI interface to
+ the host and has a built-in LED backlight.
+
config DRM_PANEL_SAMSUNG_LD9040
tristate "Samsung LD9040 RGB/SPI panel"
depends on OF && SPI
diff --git a/drivers/gpu/drm/panel/Makefile b/drivers/gpu/drm/panel/Makefile
index 71d7722146a7..42d6679b156d 100644
--- a/drivers/gpu/drm/panel/Makefile
+++ b/drivers/gpu/drm/panel/Makefile
@@ -8,6 +8,7 @@ obj-$(CONFIG_DRM_PANEL_ILITEK_ILI9881C) +=
panel-ilitek-ili9881c.o
obj-$(CONFIG_DRM_PANEL_INNOLUX_P079ZCA) += panel-innolux-p079zca.o
obj-$(CONFIG_DRM_PANEL_JDI_LT070ME05000) += panel-jdi-lt070me05000.o
obj-$(CONFIG_DRM_PANEL_KINGDISPLAY_KD097D04) += panel-kingdisplay-kd097d04.o
+obj-$(CONFIG_DRM_PANEL_LEADTEK_LTK500HD1829) += panel-leadtek-ltk500hd1829.o
obj-$(CONFIG_DRM_PANEL_LG_LB035Q02) += panel-lg-lb035q02.o
obj-$(CONFIG_DRM_PANEL_LG_LG4573) += panel-lg-lg4573.o
obj-$(CONFIG_DRM_PANEL_NEC_NL8048HL11) += panel-nec-nl8048hl11.o
diff --git a/drivers/gpu/drm/panel/panel-leadtek-ltk500hd1829.c
b/drivers/gpu/drm/panel/panel-leadtek-ltk500hd1829.c
new file mode 100644
index ..e3b4fce357e1
--- /dev/null
+++ b/drivers/gpu/drm/panel/panel-leadtek-ltk500hd1829.c
@@ -0,0 +1,533 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Copyright (c) 2019 Theobroma Systems Design und Consulting GmbH
+ *
+ * base on panel-kingdisplay-kd097d04.c
+ * Copyright (c) 2017, Fuzhou Rockchip Electronics Co., Ltd
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include
+
+#include
+#include
+#include
+#include
+#include
+#include
+
+struct ltk500hd1829 {
+ struct device *dev;
+ struct drm_panel panel;
+ struct gpio_desc *reset_gpio;
+ struct regulator *vcc;
+ struct regulator *iovcc;
+ bool prepared;
+};
+
+struct ltk500hd1829_cmd {
+ char cmd;
+ char data;
+};
+
+/*
+ * There is no description in the Reference Manual about these commands.
+ * We received them from the vendor, so just use them as is.
+ */
+static const struct ltk500hd1829_cmd init_code[] = {
+ { 0xE0, 0x00 },
+ { 0xE1, 0x93 },
+ { 0xE2, 0x65 },
+ { 0xE3, 0xF8 },
+ { 0x80, 0x03 },
+ { 0xE0, 0x04 },
+ { 0x2D, 0x03 },
+ { 0xE0, 0x01 },
+ { 0x00, 0x00 },
+ { 0x01, 0xB6 },
+ { 0x03, 0x00 },
+ { 0x04, 0xC5 },
+ { 0x17, 0x00 },
+ { 0x18, 0xBF },
+ { 0x19, 0x01 },
+ { 0x1A, 0x00 },
+ { 0x1B, 0xBF },
+ { 0x1C, 0x01 },
+ { 0x1F, 0x7C },
+ { 0x20, 0x26 },
+ { 0x21, 0x26 },
+ { 0x22, 0x4E },
+ { 0x37, 0x09 },
+ { 0x38, 0x04 },
+ { 0x39, 0x08 },
+ { 0x3A, 0x1F },
+ { 0x3B, 0x1F },
+ { 0x3C, 0x78 },
+ { 0x3D, 0xFF },
+ { 0x3E, 0xFF },
+ { 0x3F, 0x00 },
+ { 0x40, 0x04 },
+ { 0x41, 0xA0 },
+ { 0x43, 0x0F },
+ { 0x44, 0x0A },
+ { 0x45, 0x24 },
+ { 0x55, 0x01 },
+ { 0x56, 0x01 },
+ { 0x57, 0xA5 },
+ { 0x58, 0x0A },
+ { 0x59, 0x4A },
+ { 0x5A, 0x38 },
+ { 0x5B, 0x10 },
+ { 0x5C, 0x19 },
+ { 0x5D, 0x7C },
+ { 0x5E, 0x64 },
+ { 0x5F, 0x54 },
+ { 0x60, 0x48 },
+ { 0x61, 0x44 },
+ { 0x62, 0x35 },
+ { 0x63, 0x3A },
+ { 0x64, 0x24 },
+ { 0x65, 0x3B },
+ { 0x66, 0x39 },
+ { 0x67, 0x37 },
+ { 0x68, 0x56 },
+ { 0x69, 0x41 },
+ { 0x6A, 0x47 },
+ { 0x6B, 0x2F },
+ { 0x6C, 0x23 },
+ { 0x6D, 0x13 },
+ { 0x6E, 0x02 },
+ { 0x6F, 0x08 },
+ { 0x70, 0x7C },
+ { 0x71, 0x64 },
+ { 0x72, 0x54 },
+ { 0x73, 0x48 },
+ { 0x74, 0x44 },
+ { 0x75, 0x35 },
+ { 0x76, 0x3A },
+ { 0x77, 0x22 },
+ { 0x78, 0x3B },
+ { 0x79, 0x39 },
+ { 0x7A, 0x38 },
+ { 0x7B, 0x52 },
+
Re: [GIT PULL FOR v5.6] R-Car DU & LVDS decoder
Hi Daniel,
On Tue, Dec 17, 2019 at 01:43:44PM +0100, Daniel Vetter wrote:
> On Thu, Nov 28, 2019 at 04:45:24AM +0200, Laurent Pinchart wrote:
> > Hi Dave,
> >
> > The following changes since commit acc61b8929365e63a3e8c8c8913177795aa45594:
> >
> > Merge tag 'drm-next-5.5-2019-11-22' of
> > git://people.freedesktop.org/~agd5f/linux into drm-next (2019-11-26
> > 08:40:23 +1000)
> >
> > are available in the Git repository at:
> >
> > git://linuxtv.org/pinchartl/media.git tags/du-next-20191128
> >
> > for you to fetch changes up to c43bcd64c7c703ff7196f74cb6bfc67e35b562d9:
> >
> > dt-bindings: display: bridge: lvds-codec: Document ti,ds90cf384a
> > (2019-11-28 03:55:56 +0200)
> >
> >
> > - R-Car DU Color Management Module support
> > - LVDS decoder support
> >
> >
> > Fabrizio Castro (9):
> > dt-bindings: display: bridge: Convert lvds-transmitter binding to
> > json-schema
> > dt-bindings: display: bridge: lvds-transmitter: Document
> > powerdown-gpios
> > dt-bindings: display: bridge: lvds-transmitter: Absorb ti,ds90c185.txt
> > dt-bindings: display: bridge: lvds-transmitter: Document
> > "ti,sn75lvds83"
> > drm/bridge: Repurpose lvds-encoder.c
> > drm/bridge: lvds-codec: Add "lvds-decoder" support
> > drm/bridge: lvds-codec: Simplify panel DT node localisation
> > dt-bindings: display: bridge: Repurpose lvds-encoder
> > dt-bindings: display: bridge: lvds-codec: Document ti,ds90cf384a
>
> Why bridge stuff not in drm-misc?
This was submitted as part of a Renesas-related series, so I've grouped
all the Renesas-related patches in a single pull request.
> Also, and the reason I've not pulled this:
>
> dim: c43bcd64c7c7 ("dt-bindings: display: bridge: lvds-codec: Document
> ti,ds90cf384a"): committer Signed-off-by missing.
> dim: bb29b64ac196 ("dt-bindings: display: bridge: Repurpose lvds-encoder"):
> committer Signed-off-by missing.
> dim: 5db8ae664da4 ("drm/bridge: lvds-codec: Simplify panel DT node
> localisation"): committer Signed-off-by missing.
> dim: e94bb2bf88e2 ("drm/bridge: lvds-codec: Add "lvds-decoder" support"):
> committer Signed-off-by missing.
> dim: b6fafff0c335 ("drm/bridge: Repurpose lvds-encoder.c"): committer
> Signed-off-by missing.
> dim: 1c060450177f ("dt-bindings: display: bridge: lvds-transmitter: Document
> "ti,sn75lvds83""): committer Signed-off-by missing.
> dim: d2f2a148ba7c ("dt-bindings: display: bridge: lvds-transmitter: Absorb
> ti,ds90c185.txt"): committer Signed-off-by missing.
> dim: 07e5c8731999 ("dt-bindings: display: bridge: lvds-transmitter: Document
> powerdown-gpios"): committer Signed-off-by missing.
> dim: 0fa9d2323ed3 ("dt-bindings: display: bridge: Convert lvds-transmitter
> binding to json-schema"): committer Signed-off-by missing.
> dim: ERROR: issues in commits detected, aborting
>
> *insert small sermon about if you do your own maintainer, pls do it right ...
Sorry, I'll fix it and make sure it doesn't happen again.
> > Geert Uytterhoeven (2):
> > dt-bindings: display: renesas: du: Add vendor prefix to vsps property
> > drm: rcar-du: Recognize "renesas,vsps" in addition to "vsps"
> >
> > Jacopo Mondi (6):
> > dt-bindings: display: renesas,cmm: Add R-Car CMM documentation
> > dt-bindings: display: renesas,du: Document cmms property
> > drm: rcar-du: Add support for CMM
> > drm: rcar-du: kms: Initialize CMM instances
> > drm: rcar-du: crtc: Control CMM operations
> > drm: rcar-du: crtc: Register GAMMA_LUT properties
> >
> > .../bindings/display/bridge/lvds-codec.yaml| 132 +
> > .../bindings/display/bridge/lvds-transmitter.txt | 66 ---
> > .../bindings/display/bridge/ti,ds90c185.txt| 55 --
> > .../devicetree/bindings/display/renesas,cmm.yaml | 67 +++
> > .../devicetree/bindings/display/renesas,du.txt | 15 +-
> > drivers/gpu/drm/bridge/Kconfig | 8 +-
> > drivers/gpu/drm/bridge/Makefile| 2 +-
> > drivers/gpu/drm/bridge/lvds-codec.c| 151 ++
> > drivers/gpu/drm/bridge/lvds-encoder.c | 155 ---
> > drivers/gpu/drm/rcar-du/Kconfig| 8 +
> > drivers/gpu/drm/rcar-du/Makefile | 1 +
> > drivers/gpu/drm/rcar-du/rcar_cmm.c | 217
> > +
> > drivers/gpu/drm/rcar-du/rcar_cmm.h | 58 ++
> > drivers/gpu/drm/rcar-du/rcar_du_crtc.c | 71 +++
> > drivers/gpu/drm/rcar-du/rcar_du_crtc.h | 2 +
> > drivers/gpu/drm/rcar-du/rcar_du_drv.h | 2 +
> > drivers/gpu/drm/rcar-du/rcar_du_group.c| 10 +
> > drivers/gpu/drm/rcar-du/rcar_du_group.h| 2 +
> > drivers/gpu/drm/rcar-du/rcar_du_kms.c |
Re: [PATCH 1/2] drm: Handle connector tile support only for modes that match tile size
On Wed, Dec 11, 2019 at 01:24:32PM -0800, Manasi Navare wrote:
> DRM Fb driver expects multiple CRTCs if it sees connector->has_tile
> is set, but we need to handle tile support and look for multiple CRTCs
> only for the modes that match the tile size. The other modes should
> be able to be displayed without tile support or uisng single CRTC.
>
> This patch adds the check to match the tile size with requested mode
> to handle the tile support.
>
> Cc: Ville Syrjälä
> Cc: Maarten Lankhorst
> Cc: Jani Nikula
> Cc: Dave Airlie
> Signed-off-by: Manasi Navare
Capturing Dave Airlie's r-b from IRC:
Reviewed-by: Dave Airlie
Manasi
> ---
> drivers/gpu/drm/drm_fb_helper.c | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c
> index fb9bff0f4581..4978363714a9 100644
> --- a/drivers/gpu/drm/drm_fb_helper.c
> +++ b/drivers/gpu/drm/drm_fb_helper.c
> @@ -1558,7 +1558,9 @@ static int drm_fb_helper_single_fb_probe(struct
> drm_fb_helper *fb_helper,
> for (j = 0; j < mode_set->num_connectors; j++) {
> struct drm_connector *connector =
> mode_set->connectors[j];
>
> - if (connector->has_tile) {
> + if (connector->has_tile &&
> + desired_mode->hdisplay == connector->tile_h_size &&
> + desired_mode->vdisplay == connector->tile_v_size) {
> lasth = (connector->tile_h_loc ==
> (connector->num_h_tile - 1));
> lastv = (connector->tile_v_loc ==
> (connector->num_v_tile - 1));
> /* cloning to multiple tiles is just
> crazy-talk, so: */
> --
> 2.19.1
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: linux-next: build failure after merge of the drm-misc tree
Hi Daniel,
On Tue, 17 Dec 2019 14:19:37 +0100 Daniel Vetter wrote:
>
> On Mon, Dec 16, 2019 at 12:23:31PM +1100, Stephen Rothwell wrote:
> >
> > After merging the drm-misc tree, today's linux-next build (x86_64
> > allmodconfig) failed like this:
> >
> > drivers/gpu/drm/bridge/analogix/analogix-anx6345.c: In function
> > 'anx6345_i2c_probe':
> > drivers/gpu/drm/bridge/analogix/analogix-anx6345.c:738:30: error: implicit
> > declaration of function 'i2c_new_dummy'
> > [-Werror=implicit-function-declaration]
> > 738 |anx6345->i2c_clients[i] = i2c_new_dummy(client->adapter,
> > | ^
> > drivers/gpu/drm/bridge/analogix/analogix-anx6345.c:738:28: warning:
> > assignment to 'struct i2c_client *' from 'int' makes pointer from integer
> > without a cast [-Wint-conversion]
> > 738 |anx6345->i2c_clients[i] = i2c_new_dummy(client->adapter,
> > |^
> >
> > Caused by commit
> >
> > 6aa192698089 ("drm/bridge: Add Analogix anx6345 support")
> >
> > interacting with commit
> >
> > 2c2f00ab1641 ("i2c: remove i2c_new_dummy() API")
> >
> > From Linus' tree.
> >
> > I have applied the following fix up patch for today:
> >
> > From: Stephen Rothwell
> > Date: Mon, 16 Dec 2019 12:11:19 +1100
> > Subject: [PATCH] drm/bridge: fix up for removal of i2c_new_dummy()
> >
> > Signed-off-by: Stephen Rothwell
>
> Thanks pulled into drm-next since I just processed the first drm-misc-next
> pull.
Thanks. For the future, though, merge fixes like this should be part
of the actual merge commit to avoid bisection problems.
--
Cheers,
Stephen Rothwell
pgpsZcZlvDrVG.pgp
Description: OpenPGP digital signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 libdrm] intel: sync i915_pciids.h with kernel
On Tue, Dec 17, 2019 at 11:31:40AM -0800, José Roberto de Souza wrote:
> Changes:
> 651cc835d5f6 ("drm/i915: Add new EHL/JSL PCI ids")
> b6a8781a447c ("drm/i915/cml: Remove unsupport PCI ID")
> 8717c6b7414f ("drm/i915/cml: Separate U series pci id from origianl list.")
>
> v2: added the latest CML changes
>
> Cc: James Ausmus
> Cc: Matt Roper
> Cc: Lucas De Marchi
> Reviewed-by: Matt Roper (v1 EHL/JSL changes)
Diff against same file in drm-tip is empty, so r-b stands for this
version too.
Matt
> Signed-off-by: José Roberto de Souza
> ---
> intel/i915_pciids.h | 31 ++-
> 1 file changed, 18 insertions(+), 13 deletions(-)
>
> diff --git a/intel/i915_pciids.h b/intel/i915_pciids.h
> index b1f66b11..1d2c1221 100644
> --- a/intel/i915_pciids.h
> +++ b/intel/i915_pciids.h
> @@ -446,23 +446,18 @@
>
> /* CML GT1 */
> #define INTEL_CML_GT1_IDS(info) \
> - INTEL_VGA_DEVICE(0x9B21, info), \
> - INTEL_VGA_DEVICE(0x9BAA, info), \
> - INTEL_VGA_DEVICE(0x9BAB, info), \
> - INTEL_VGA_DEVICE(0x9BAC, info), \
> - INTEL_VGA_DEVICE(0x9BA0, info), \
> INTEL_VGA_DEVICE(0x9BA5, info), \
> INTEL_VGA_DEVICE(0x9BA8, info), \
> INTEL_VGA_DEVICE(0x9BA4, info), \
> INTEL_VGA_DEVICE(0x9BA2, info)
>
> +#define INTEL_CML_U_GT1_IDS(info) \
> + INTEL_VGA_DEVICE(0x9B21, info), \
> + INTEL_VGA_DEVICE(0x9BAA, info), \
> + INTEL_VGA_DEVICE(0x9BAC, info)
> +
> /* CML GT2 */
> #define INTEL_CML_GT2_IDS(info) \
> - INTEL_VGA_DEVICE(0x9B41, info), \
> - INTEL_VGA_DEVICE(0x9BCA, info), \
> - INTEL_VGA_DEVICE(0x9BCB, info), \
> - INTEL_VGA_DEVICE(0x9BCC, info), \
> - INTEL_VGA_DEVICE(0x9BC0, info), \
> INTEL_VGA_DEVICE(0x9BC5, info), \
> INTEL_VGA_DEVICE(0x9BC8, info), \
> INTEL_VGA_DEVICE(0x9BC4, info), \
> @@ -471,6 +466,11 @@
> INTEL_VGA_DEVICE(0x9BE6, info), \
> INTEL_VGA_DEVICE(0x9BF6, info)
>
> +#define INTEL_CML_U_GT2_IDS(info) \
> + INTEL_VGA_DEVICE(0x9B41, info), \
> + INTEL_VGA_DEVICE(0x9BCA, info), \
> + INTEL_VGA_DEVICE(0x9BCC, info)
> +
> #define INTEL_KBL_IDS(info) \
> INTEL_KBL_GT1_IDS(info), \
> INTEL_KBL_GT2_IDS(info), \
> @@ -536,7 +536,9 @@
> INTEL_WHL_U_GT3_IDS(info), \
> INTEL_AML_CFL_GT2_IDS(info), \
> INTEL_CML_GT1_IDS(info), \
> - INTEL_CML_GT2_IDS(info)
> + INTEL_CML_GT2_IDS(info), \
> + INTEL_CML_U_GT1_IDS(info), \
> + INTEL_CML_U_GT2_IDS(info)
>
> /* CNL */
> #define INTEL_CNL_PORT_F_IDS(info) \
> @@ -579,12 +581,15 @@
> INTEL_VGA_DEVICE(0x8A51, info), \
> INTEL_VGA_DEVICE(0x8A5D, info)
>
> -/* EHL */
> +/* EHL/JSL */
> #define INTEL_EHL_IDS(info) \
> INTEL_VGA_DEVICE(0x4500, info), \
> INTEL_VGA_DEVICE(0x4571, info), \
> INTEL_VGA_DEVICE(0x4551, info), \
> - INTEL_VGA_DEVICE(0x4541, info)
> + INTEL_VGA_DEVICE(0x4541, info), \
> + INTEL_VGA_DEVICE(0x4E71, info), \
> + INTEL_VGA_DEVICE(0x4E61, info), \
> + INTEL_VGA_DEVICE(0x4E51, info)
>
> /* TGL */
> #define INTEL_TGL_12_IDS(info) \
> --
> 2.24.1
>
--
Matt Roper
Graphics Software Engineer
VTT-OSGC Platform Enablement
Intel Corporation
(916) 356-2795
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v1 1/1] drm/drm_panel: Fix EXPORT of drm_panel_of_backlight() one more time
On Tue, Dec 17, 2019 at 08:25:03AM -0800, Randy Dunlap wrote:
> On 12/17/19 6:07 AM, Andy Shevchenko wrote:
> > The initial commit followed by the fix didn't take into consideration the
> > case
> >
> > CONFIG_DRM_PANEL=y
> > CONFIG_BACKLIGHT_CLASS_DEVICE=m
> > CONFIG_DRM_I915=y
> >
> > where symbol devm_of_find_backlight() is not reachable from DRM subsystem.
> > Quick fix is to avoid drm_panel_of_backlight() from exporting in such case.
> >
> > Fixes: 907aa265fde6 ("drm/drm_panel: fix EXPORT of drm_panel_of_backlight")
> > Reported-by: Randy Dunlap
> > Cc: Linus Walleij
> > Cc: Sam Ravnborg
> > Cc: Laurent Pinchart
> > Cc: Thierry Reding
> > Cc: Maarten Lankhorst
> > Cc: Sean Paul
> > Cc: David Airlie
> > Cc: Daniel Vetter
> > Cc: Maxime Ripard
> > Cc: dri-devel@lists.freedesktop.org
> > Signed-off-by: Andy Shevchenko
>
> Yes, that fixes the build error. Thanks.
>
> Acked-by: Randy Dunlap # build-tested
Hi Andy - thanks for fixing this. And thanks Randy for verifying the
fix.
It passed my build test and is now pushed to drm-misc-next.
Sam
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Intel-gfx] [PATCH] drm/i915/display: cleanup intel_bw_state on i915 module removal
On Thu, Dec 12, 2019 at 12:34:49PM -0800, Lucas De Marchi wrote: On Thu, Dec 12, 2019 at 09:37:17AM -0800, Matt Roper wrote: On Wed, Dec 11, 2019 at 04:22:50PM -0800, Lucas De Marchi wrote: On Wed, Dec 11, 2019 at 12:10:41PM +0530, Bharadiya,Pankaj wrote: On Tue, Dec 10, 2019 at 09:57:39PM -0800, Lucas De Marchi wrote: > On Mon, Dec 09, 2019 at 08:09:02PM +0530, Pankaj Bharadiya wrote: > >intel_bw_state allocated memory is not getting freed even after > >module removal. > > > >kmemleak reported backtrace: > > > > [<79019739>] kmemdup+0x17/0x40 > > [] intel_bw_duplicate_state+0x1b/0x40 [i915] > > [<7423ed0c>] drm_atomic_get_private_obj_state+0xca/0x140 > > [<100e3533>] intel_bw_atomic_check+0x133/0x350 [i915] > > [<126d0e0c>] intel_atomic_check+0x1ab7/0x20d0 [i915] > > [ ] drm_atomic_check_only+0x563/0x810 > > [ ] drm_atomic_commit+0xe/0x50 > > [ ] drm_atomic_helper_disable_all+0x133/0x160 > > [<3c44760c>] drm_atomic_helper_shutdown+0x65/0xc0 > > [<414e3e5c>] i915_driver_remove+0xcb/0x130 [i915] > > [ ] i915_pci_remove+0x19/0x40 [i915] > > [<2dcbd148>] pci_device_remove+0x36/0xb0 > > [<3c8c6b0a>] device_release_driver_internal+0xe0/0x1c0 > > [<580e9566>] unbind_store+0xc3/0x120 > > [<869d0df5>] kernfs_fop_write+0x104/0x190 > > [<4dc1a355>] vfs_write+0xb9/0x1d0 > > what I find strange in this is that the last state was allocated by the > "driver remove" code path. > > > > >Call the drm_atomic_private_obj_fini(), which inturn calls the > >intel_bw_destroy_state() to make sure the intel_bw_state memory is > >freed properly. > > > >Signed-off-by: Pankaj Bharadiya > >--- > >drivers/gpu/drm/i915/display/intel_bw.c | 5 + > >drivers/gpu/drm/i915/display/intel_bw.h | 1 + > >drivers/gpu/drm/i915/display/intel_display.c | 2 ++ > >3 files changed, 8 insertions(+) > > > >diff --git a/drivers/gpu/drm/i915/display/intel_bw.c b/drivers/gpu/drm/i915/display/intel_bw.c > >index dcb66a33be9b..b228671d5a5d 100644 > >--- a/drivers/gpu/drm/i915/display/intel_bw.c > >+++ b/drivers/gpu/drm/i915/display/intel_bw.c > >@@ -486,3 +486,8 @@ int intel_bw_init(struct drm_i915_private *dev_priv) > > > > return 0; > >} > >+ > >+void intel_bw_cleanup(struct drm_i915_private *dev_priv) > >+{ > >+ drm_atomic_private_obj_fini(&dev_priv->bw_obj); > >+} > >diff --git a/drivers/gpu/drm/i915/display/intel_bw.h b/drivers/gpu/drm/i915/display/intel_bw.h > >index 9db10af012f4..20b9ad241802 100644 > >--- a/drivers/gpu/drm/i915/display/intel_bw.h > >+++ b/drivers/gpu/drm/i915/display/intel_bw.h > >@@ -25,6 +25,7 @@ struct intel_bw_state { > > > >void intel_bw_init_hw(struct drm_i915_private *dev_priv); > >int intel_bw_init(struct drm_i915_private *dev_priv); > >+void intel_bw_cleanup(struct drm_i915_private *dev_priv); > >int intel_bw_atomic_check(struct intel_atomic_state *state); > >void intel_bw_crtc_update(struct intel_bw_state *bw_state, > > const struct intel_crtc_state *crtc_state); > >diff --git a/drivers/gpu/drm/i915/display/intel_display.c b/drivers/gpu/drm/i915/display/intel_display.c > >index 3190aa27ffdc..756eb90b1bb1 100644 > >--- a/drivers/gpu/drm/i915/display/intel_display.c > >+++ b/drivers/gpu/drm/i915/display/intel_display.c > >@@ -17912,6 +17912,8 @@ void intel_modeset_driver_remove(struct drm_i915_private *i915) > > > > intel_gmbus_teardown(i915); > > > >+ intel_bw_cleanup(i915); > > This doesn't seem to match the (reverse) order of > intel_modeset_init()... but it's actually the gmbus_teardown() that is > out of place. Did you check if it's not a wrong shutdown ordering? > In intel_modeset_init(), intel_gmbus_setup() happens after intel_bw_init(). I think the patch follows the reverse ordering properly. Am I missing anything? I said it seems that it's the gmbus_teardown() that is out of place. Have you seen my comment above? Why are we duplicating the bw_state on the module-remove code path? I think that part is legitimate. Part of the module remove sequence does an atomic commit to turn everything off. During atomic transactions, we create duplicates of all modesetting state objects can be modified; if/when the transaction succeeds, those duplicates are swapped into the actual driver state and the old objects are destroyed. Thus in cases like this where we forget to destroy a private object state, that leaked state structure will be the one allocated during the very last atomic transaction that happened (i.e., on the driver teardown codepath). humn, that makes sense. The new duplicate state will replace the previous one and hence why we see it in the backtrace, rather than one allocated previously. thanks Lucas De Marchi and... Reviewed-by: Lucas De Marchi Lucas De Marchi Matt Lucas De Marchi Thanks, Pankaj > thanks > Lucas De Mar
[PATCH v2 libdrm] intel: sync i915_pciids.h with kernel
Changes:
651cc835d5f6 ("drm/i915: Add new EHL/JSL PCI ids")
b6a8781a447c ("drm/i915/cml: Remove unsupport PCI ID")
8717c6b7414f ("drm/i915/cml: Separate U series pci id from origianl list.")
v2: added the latest CML changes
Cc: James Ausmus
Cc: Matt Roper
Cc: Lucas De Marchi
Reviewed-by: Matt Roper (v1 EHL/JSL changes)
Signed-off-by: José Roberto de Souza
---
intel/i915_pciids.h | 31 ++-
1 file changed, 18 insertions(+), 13 deletions(-)
diff --git a/intel/i915_pciids.h b/intel/i915_pciids.h
index b1f66b11..1d2c1221 100644
--- a/intel/i915_pciids.h
+++ b/intel/i915_pciids.h
@@ -446,23 +446,18 @@
/* CML GT1 */
#define INTEL_CML_GT1_IDS(info)\
- INTEL_VGA_DEVICE(0x9B21, info), \
- INTEL_VGA_DEVICE(0x9BAA, info), \
- INTEL_VGA_DEVICE(0x9BAB, info), \
- INTEL_VGA_DEVICE(0x9BAC, info), \
- INTEL_VGA_DEVICE(0x9BA0, info), \
INTEL_VGA_DEVICE(0x9BA5, info), \
INTEL_VGA_DEVICE(0x9BA8, info), \
INTEL_VGA_DEVICE(0x9BA4, info), \
INTEL_VGA_DEVICE(0x9BA2, info)
+#define INTEL_CML_U_GT1_IDS(info) \
+ INTEL_VGA_DEVICE(0x9B21, info), \
+ INTEL_VGA_DEVICE(0x9BAA, info), \
+ INTEL_VGA_DEVICE(0x9BAC, info)
+
/* CML GT2 */
#define INTEL_CML_GT2_IDS(info)\
- INTEL_VGA_DEVICE(0x9B41, info), \
- INTEL_VGA_DEVICE(0x9BCA, info), \
- INTEL_VGA_DEVICE(0x9BCB, info), \
- INTEL_VGA_DEVICE(0x9BCC, info), \
- INTEL_VGA_DEVICE(0x9BC0, info), \
INTEL_VGA_DEVICE(0x9BC5, info), \
INTEL_VGA_DEVICE(0x9BC8, info), \
INTEL_VGA_DEVICE(0x9BC4, info), \
@@ -471,6 +466,11 @@
INTEL_VGA_DEVICE(0x9BE6, info), \
INTEL_VGA_DEVICE(0x9BF6, info)
+#define INTEL_CML_U_GT2_IDS(info) \
+ INTEL_VGA_DEVICE(0x9B41, info), \
+ INTEL_VGA_DEVICE(0x9BCA, info), \
+ INTEL_VGA_DEVICE(0x9BCC, info)
+
#define INTEL_KBL_IDS(info) \
INTEL_KBL_GT1_IDS(info), \
INTEL_KBL_GT2_IDS(info), \
@@ -536,7 +536,9 @@
INTEL_WHL_U_GT3_IDS(info), \
INTEL_AML_CFL_GT2_IDS(info), \
INTEL_CML_GT1_IDS(info), \
- INTEL_CML_GT2_IDS(info)
+ INTEL_CML_GT2_IDS(info), \
+ INTEL_CML_U_GT1_IDS(info), \
+ INTEL_CML_U_GT2_IDS(info)
/* CNL */
#define INTEL_CNL_PORT_F_IDS(info) \
@@ -579,12 +581,15 @@
INTEL_VGA_DEVICE(0x8A51, info), \
INTEL_VGA_DEVICE(0x8A5D, info)
-/* EHL */
+/* EHL/JSL */
#define INTEL_EHL_IDS(info) \
INTEL_VGA_DEVICE(0x4500, info), \
INTEL_VGA_DEVICE(0x4571, info), \
INTEL_VGA_DEVICE(0x4551, info), \
- INTEL_VGA_DEVICE(0x4541, info)
+ INTEL_VGA_DEVICE(0x4541, info), \
+ INTEL_VGA_DEVICE(0x4E71, info), \
+ INTEL_VGA_DEVICE(0x4E61, info), \
+ INTEL_VGA_DEVICE(0x4E51, info)
/* TGL */
#define INTEL_TGL_12_IDS(info) \
--
2.24.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 5/8] drm/mipi-dbi: convert to drm device based logging
On Tue, Dec 17, 2019 at 08:00:11PM +0100, Sam Ravnborg wrote:
> On Tue, Dec 10, 2019 at 02:30:47PM +0200, Jani Nikula wrote:
> > Prefer drm device based logging where possible.
> >
> > Signed-off-by: Jani Nikula
> > ---
> > drivers/gpu/drm/drm_mipi_dbi.c | 15 ---
> > 1 file changed, 8 insertions(+), 7 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/drm_mipi_dbi.c b/drivers/gpu/drm/drm_mipi_dbi.c
> > index e34058c721be..86d98e7fc30a 100644
> > --- a/drivers/gpu/drm/drm_mipi_dbi.c
> > +++ b/drivers/gpu/drm/drm_mipi_dbi.c
> > @@ -225,7 +225,7 @@ int mipi_dbi_buf_copy(void *dst, struct drm_framebuffer
> > *fb,
> > drm_fb_xrgb_to_rgb565(dst, src, fb, clip, swap);
> > break;
> > default:
> > - dev_err_once(fb->dev->dev, "Format is not supported: %s\n",
> > + drm_err_once(fb->dev, "Format is not supported: %s\n",
> > drm_get_format_name(fb->format->format,
> > &format_name));
> > return -EINVAL;
> > @@ -242,7 +242,8 @@ static void mipi_dbi_fb_dirty(struct drm_framebuffer
> > *fb, struct drm_rect *rect)
> > {
> > struct drm_gem_object *gem = drm_gem_fb_get_obj(fb, 0);
> > struct drm_gem_cma_object *cma_obj = to_drm_gem_cma_obj(gem);
> > - struct mipi_dbi_dev *dbidev = drm_to_mipi_dbi_dev(fb->dev);
> > + struct drm_device *dev = fb->dev;
>
> In this file the pattern is to use the variable name "drm" for a
> drm_device *. Your changes should follow the same pattern.
With this fixed:
Reviewed-by: Sam Ravnborg
>
> Sam
>
> > + struct mipi_dbi_dev *dbidev = drm_to_mipi_dbi_dev(dev);
> > unsigned int height = rect->y2 - rect->y1;
> > unsigned int width = rect->x2 - rect->x1;
> > struct mipi_dbi *dbi = &dbidev->dbi;
> > @@ -259,7 +260,7 @@ static void mipi_dbi_fb_dirty(struct drm_framebuffer
> > *fb, struct drm_rect *rect)
> >
> > full = width == fb->width && height == fb->height;
> >
> > - DRM_DEBUG_KMS("Flushing [FB:%d] " DRM_RECT_FMT "\n", fb->base.id,
> > DRM_RECT_ARG(rect));
> > + drm_dbg_kms(dev, "Flushing [FB:%d] " DRM_RECT_FMT "\n", fb->base.id,
> > DRM_RECT_ARG(rect));
> >
> > if (!dbi->dc || !full || swap ||
> > fb->format->format == DRM_FORMAT_XRGB) {
> > @@ -282,7 +283,7 @@ static void mipi_dbi_fb_dirty(struct drm_framebuffer
> > *fb, struct drm_rect *rect)
> >width * height * 2);
> > err_msg:
> > if (ret)
> > - dev_err_once(fb->dev->dev, "Failed to update display %d\n",
> > ret);
> > + drm_err_once(dev, "Failed to update display %d\n", ret);
> >
> > drm_dev_exit(idx);
> > }
> > @@ -649,14 +650,14 @@ EXPORT_SYMBOL(mipi_dbi_display_is_on);
> >
> > static int mipi_dbi_poweron_reset_conditional(struct mipi_dbi_dev *dbidev,
> > bool cond)
> > {
> > - struct device *dev = dbidev->drm.dev;
> > + struct drm_device *dev = &dbidev->drm;
> > struct mipi_dbi *dbi = &dbidev->dbi;
> > int ret;
> >
> > if (dbidev->regulator) {
> > ret = regulator_enable(dbidev->regulator);
> > if (ret) {
> > - DRM_DEV_ERROR(dev, "Failed to enable regulator (%d)\n",
> > ret);
> > + drm_err(dev, "Failed to enable regulator (%d)\n", ret);
> > return ret;
> > }
> > }
> > @@ -667,7 +668,7 @@ static int mipi_dbi_poweron_reset_conditional(struct
> > mipi_dbi_dev *dbidev, bool
> > mipi_dbi_hw_reset(dbi);
> > ret = mipi_dbi_command(dbi, MIPI_DCS_SOFT_RESET);
> > if (ret) {
> > - DRM_DEV_ERROR(dev, "Failed to send reset command (%d)\n", ret);
> > + drm_err(dev, "Failed to send reset command (%d)\n", ret);
> > if (dbidev->regulator)
> > regulator_disable(dbidev->regulator);
> > return ret;
> > --
> > 2.20.1
> >
> > ___
> > dri-devel mailing list
> > dri-devel@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/dri-devel
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] dma-heap: Make the symbol 'dma_heap_ioctl_cmds' static
From: zhong jiang
Fix the following sparse warning.
drivers/dma-buf/dma-heap.c:109:14: warning: symbol 'dma_heap_ioctl_cmds'
was not declared. Should it be static?
Acked-by: Andrew F. Davis
Acked-by: John Stultz
Signed-off-by: zhong jiang
Signed-off-by: Sumit Semwal
[sumits: rebased over IOCTL rename patches]
---
drivers/dma-buf/dma-heap.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/dma-buf/dma-heap.c b/drivers/dma-buf/dma-heap.c
index 1886aee46131..afd22c9dbdcf 100644
--- a/drivers/dma-buf/dma-heap.c
+++ b/drivers/dma-buf/dma-heap.c
@@ -106,7 +106,7 @@ static long dma_heap_ioctl_allocate(struct file *file, void
*data)
return 0;
}
-unsigned int dma_heap_ioctl_cmds[] = {
+static unsigned int dma_heap_ioctl_cmds[] = {
DMA_HEAP_IOCTL_ALLOC,
};
--
2.18.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 6/8] drm/atomic: convert to drm device based logging
Hi Jani.
On Tue, Dec 10, 2019 at 02:30:48PM +0200, Jani Nikula wrote:
> Prefer drm_dbg_atomic().
This patch simplify code by introducing a local drm_device varialble
which is good. But this is not mentioned in the cahngelog.
Anf the patch uses more than just drm_dbg_atomic(), see for example the
first patch below.
With updated changelog and small nit mentioned later fixed:
Reviewed-by: Sam Ravnborg
Sam
>
> Signed-off-by: Jani Nikula
> ---
> drivers/gpu/drm/drm_agpsupport.c | 4 +-
> drivers/gpu/drm/drm_atomic.c | 187 +--
> 2 files changed, 102 insertions(+), 89 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_agpsupport.c
> b/drivers/gpu/drm/drm_agpsupport.c
> index 4c7ad46fdd21..cd675e58de50 100644
> --- a/drivers/gpu/drm/drm_agpsupport.c
> +++ b/drivers/gpu/drm/drm_agpsupport.c
> @@ -330,8 +330,8 @@ int drm_agp_bind(struct drm_device *dev, struct
> drm_agp_binding *request)
> if (retcode)
> return retcode;
> entry->bound = dev->agp->base + (page << PAGE_SHIFT);
> - DRM_DEBUG("base = 0x%lx entry->bound = 0x%lx\n",
> - dev->agp->base, entry->bound);
> + drm_dbg_core(dev, "base = 0x%lx entry->bound = 0x%lx\n",
> + dev->agp->base, entry->bound);
> return 0;
> }
> EXPORT_SYMBOL(drm_agp_bind);
> diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
> index 14aeaf736321..8494b1c29bf0 100644
> --- a/drivers/gpu/drm/drm_atomic.c
> +++ b/drivers/gpu/drm/drm_atomic.c
> @@ -99,7 +99,7 @@ drm_atomic_state_init(struct drm_device *dev, struct
> drm_atomic_state *state)
>
> state->dev = dev;
>
> - DRM_DEBUG_ATOMIC("Allocated atomic state %p\n", state);
> + drm_dbg_atomic(dev, "Allocated atomic state %p\n", state);
>
> return 0;
> fail:
> @@ -150,7 +150,7 @@ void drm_atomic_state_default_clear(struct
> drm_atomic_state *state)
> struct drm_mode_config *config = &dev->mode_config;
> int i;
>
> - DRM_DEBUG_ATOMIC("Clearing atomic state %p\n", state);
> + drm_dbg_atomic(dev, "Clearing atomic state %p\n", state);
>
> for (i = 0; i < state->num_connector; i++) {
> struct drm_connector *connector = state->connectors[i].ptr;
> @@ -256,11 +256,12 @@ EXPORT_SYMBOL(drm_atomic_state_clear);
> void __drm_atomic_state_free(struct kref *ref)
> {
> struct drm_atomic_state *state = container_of(ref, typeof(*state), ref);
> - struct drm_mode_config *config = &state->dev->mode_config;
> + struct drm_device *dev = state->dev;
> + struct drm_mode_config *config = &dev->mode_config;
>
> drm_atomic_state_clear(state);
>
> - DRM_DEBUG_ATOMIC("Freeing atomic state %p\n", state);
> + drm_dbg_atomic(dev, "Freeing atomic state %p\n", state);
>
> if (config->funcs->atomic_state_free) {
> config->funcs->atomic_state_free(state);
> @@ -290,8 +291,9 @@ struct drm_crtc_state *
> drm_atomic_get_crtc_state(struct drm_atomic_state *state,
> struct drm_crtc *crtc)
> {
> - int ret, index = drm_crtc_index(crtc);
> + struct drm_device *dev = state->dev;
> struct drm_crtc_state *crtc_state;
> + int ret, index = drm_crtc_index(crtc);
>
> WARN_ON(!state->acquire_ctx);
>
> @@ -313,8 +315,8 @@ drm_atomic_get_crtc_state(struct drm_atomic_state *state,
> state->crtcs[index].ptr = crtc;
> crtc_state->state = state;
>
> - DRM_DEBUG_ATOMIC("Added [CRTC:%d:%s] %p state to %p\n",
> - crtc->base.id, crtc->name, crtc_state, state);
> + drm_dbg_atomic(dev, "Added [CRTC:%d:%s] %p state to %p\n",
> +crtc->base.id, crtc->name, crtc_state, state);
>
> return crtc_state;
> }
> @@ -324,6 +326,7 @@ static int drm_atomic_crtc_check(const struct
> drm_crtc_state *old_crtc_state,
>const struct drm_crtc_state *new_crtc_state)
> {
> struct drm_crtc *crtc = new_crtc_state->crtc;
> + struct drm_device *dev = crtc->dev;
>
> /* NOTE: we explicitly don't enforce constraints such as primary
>* layer covering entire screen, since that is something we want
> @@ -334,25 +337,25 @@ static int drm_atomic_crtc_check(const struct
> drm_crtc_state *old_crtc_state,
>*/
>
> if (new_crtc_state->active && !new_crtc_state->enable) {
> - DRM_DEBUG_ATOMIC("[CRTC:%d:%s] active without enabled\n",
> - crtc->base.id, crtc->name);
> + drm_dbg_atomic(dev, "[CRTC:%d:%s] active without enabled\n",
> +crtc->base.id, crtc->name);
> return -EINVAL;
> }
>
> /* The state->enable vs. state->mode_blob checks can be WARN_ON,
>* as this is a kernel-internal detail that userspace should never
>* be able to trigger. */
> - if (drm_core_check_feature(crtc->dev, DRIVER_ATOMIC) &&
> + if (drm_core_check_feature(dev, DRIV
Re: [PATCH 5/8] drm/mipi-dbi: convert to drm device based logging
On Tue, Dec 10, 2019 at 02:30:47PM +0200, Jani Nikula wrote:
> Prefer drm device based logging where possible.
>
> Signed-off-by: Jani Nikula
> ---
> drivers/gpu/drm/drm_mipi_dbi.c | 15 ---
> 1 file changed, 8 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_mipi_dbi.c b/drivers/gpu/drm/drm_mipi_dbi.c
> index e34058c721be..86d98e7fc30a 100644
> --- a/drivers/gpu/drm/drm_mipi_dbi.c
> +++ b/drivers/gpu/drm/drm_mipi_dbi.c
> @@ -225,7 +225,7 @@ int mipi_dbi_buf_copy(void *dst, struct drm_framebuffer
> *fb,
> drm_fb_xrgb_to_rgb565(dst, src, fb, clip, swap);
> break;
> default:
> - dev_err_once(fb->dev->dev, "Format is not supported: %s\n",
> + drm_err_once(fb->dev, "Format is not supported: %s\n",
>drm_get_format_name(fb->format->format,
>&format_name));
> return -EINVAL;
> @@ -242,7 +242,8 @@ static void mipi_dbi_fb_dirty(struct drm_framebuffer *fb,
> struct drm_rect *rect)
> {
> struct drm_gem_object *gem = drm_gem_fb_get_obj(fb, 0);
> struct drm_gem_cma_object *cma_obj = to_drm_gem_cma_obj(gem);
> - struct mipi_dbi_dev *dbidev = drm_to_mipi_dbi_dev(fb->dev);
> + struct drm_device *dev = fb->dev;
In this file the pattern is to use the variable name "drm" for a
drm_device *. Your changes should follow the same pattern.
Sam
> + struct mipi_dbi_dev *dbidev = drm_to_mipi_dbi_dev(dev);
> unsigned int height = rect->y2 - rect->y1;
> unsigned int width = rect->x2 - rect->x1;
> struct mipi_dbi *dbi = &dbidev->dbi;
> @@ -259,7 +260,7 @@ static void mipi_dbi_fb_dirty(struct drm_framebuffer *fb,
> struct drm_rect *rect)
>
> full = width == fb->width && height == fb->height;
>
> - DRM_DEBUG_KMS("Flushing [FB:%d] " DRM_RECT_FMT "\n", fb->base.id,
> DRM_RECT_ARG(rect));
> + drm_dbg_kms(dev, "Flushing [FB:%d] " DRM_RECT_FMT "\n", fb->base.id,
> DRM_RECT_ARG(rect));
>
> if (!dbi->dc || !full || swap ||
> fb->format->format == DRM_FORMAT_XRGB) {
> @@ -282,7 +283,7 @@ static void mipi_dbi_fb_dirty(struct drm_framebuffer *fb,
> struct drm_rect *rect)
> width * height * 2);
> err_msg:
> if (ret)
> - dev_err_once(fb->dev->dev, "Failed to update display %d\n",
> ret);
> + drm_err_once(dev, "Failed to update display %d\n", ret);
>
> drm_dev_exit(idx);
> }
> @@ -649,14 +650,14 @@ EXPORT_SYMBOL(mipi_dbi_display_is_on);
>
> static int mipi_dbi_poweron_reset_conditional(struct mipi_dbi_dev *dbidev,
> bool cond)
> {
> - struct device *dev = dbidev->drm.dev;
> + struct drm_device *dev = &dbidev->drm;
> struct mipi_dbi *dbi = &dbidev->dbi;
> int ret;
>
> if (dbidev->regulator) {
> ret = regulator_enable(dbidev->regulator);
> if (ret) {
> - DRM_DEV_ERROR(dev, "Failed to enable regulator (%d)\n",
> ret);
> + drm_err(dev, "Failed to enable regulator (%d)\n", ret);
> return ret;
> }
> }
> @@ -667,7 +668,7 @@ static int mipi_dbi_poweron_reset_conditional(struct
> mipi_dbi_dev *dbidev, bool
> mipi_dbi_hw_reset(dbi);
> ret = mipi_dbi_command(dbi, MIPI_DCS_SOFT_RESET);
> if (ret) {
> - DRM_DEV_ERROR(dev, "Failed to send reset command (%d)\n", ret);
> + drm_err(dev, "Failed to send reset command (%d)\n", ret);
> if (dbidev->regulator)
> regulator_disable(dbidev->regulator);
> return ret;
> --
> 2.20.1
>
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 4/8] drm/gem-fb-helper: convert to drm device based logging
On Tue, Dec 10, 2019 at 02:30:46PM +0200, Jani Nikula wrote:
> Prefer drm_dbg_kms() and drm_err() over all other logging.
>
> Signed-off-by: Jani Nikula
Reviewed-by: Sam Ravnborg
> ---
> drivers/gpu/drm/drm_gem_framebuffer_helper.c | 5 ++---
> 1 file changed, 2 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_gem_framebuffer_helper.c
> b/drivers/gpu/drm/drm_gem_framebuffer_helper.c
> index b9bcd310ca2d..3a7ace19a902 100644
> --- a/drivers/gpu/drm/drm_gem_framebuffer_helper.c
> +++ b/drivers/gpu/drm/drm_gem_framebuffer_helper.c
> @@ -74,8 +74,7 @@ drm_gem_fb_alloc(struct drm_device *dev,
>
> ret = drm_framebuffer_init(dev, fb, funcs);
> if (ret) {
> - DRM_DEV_ERROR(dev->dev, "Failed to init framebuffer: %d\n",
> - ret);
> + drm_err(dev, "Failed to init framebuffer: %d\n", ret);
> kfree(fb);
> return ERR_PTR(ret);
> }
> @@ -160,7 +159,7 @@ drm_gem_fb_create_with_funcs(struct drm_device *dev,
> struct drm_file *file,
>
> objs[i] = drm_gem_object_lookup(file, mode_cmd->handles[i]);
> if (!objs[i]) {
> - DRM_DEBUG_KMS("Failed to lookup GEM object\n");
> + drm_dbg_kms(dev, "Failed to lookup GEM object\n");
> ret = -ENOENT;
> goto err_gem_object_put;
> }
> --
> 2.20.1
>
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 3/8] drm/fb-helper: convert to drm device based logging
Hi Jani.
On Tue, Dec 10, 2019 at 02:30:45PM +0200, Jani Nikula wrote:
> Prefer drm_dbg_kms(), drm_info(), and drm_err() over all other
> logging. This is about KMS so switch to the KMS category while at it.
>
> Signed-off-by: Jani Nikula
Reviewed-by: Sam Ravnborg
> ---
> drivers/gpu/drm/drm_fb_helper.c | 36 ++---
> 1 file changed, 20 insertions(+), 16 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c
> index fb9bff0f4581..f8e905192608 100644
> --- a/drivers/gpu/drm/drm_fb_helper.c
> +++ b/drivers/gpu/drm/drm_fb_helper.c
> @@ -191,6 +191,7 @@ int drm_fb_helper_debug_leave(struct fb_info *info)
> {
> struct drm_fb_helper *helper = info->par;
> struct drm_client_dev *client = &helper->client;
> + struct drm_device *dev = helper->dev;
> struct drm_crtc *crtc;
> const struct drm_crtc_helper_funcs *funcs;
> struct drm_mode_set *mode_set;
> @@ -209,7 +210,7 @@ int drm_fb_helper_debug_leave(struct fb_info *info)
> continue;
>
> if (!fb) {
> - DRM_ERROR("no fb to restore??\n");
> + drm_err(dev, "no fb to restore?\n");
> continue;
> }
>
> @@ -1248,12 +1249,13 @@ int drm_fb_helper_check_var(struct fb_var_screeninfo
> *var,
> {
> struct drm_fb_helper *fb_helper = info->par;
> struct drm_framebuffer *fb = fb_helper->fb;
> + struct drm_device *dev = fb_helper->dev;
>
> if (in_dbg_master())
> return -EINVAL;
>
> if (var->pixclock != 0) {
> - DRM_DEBUG("fbdev emulation doesn't support changing the pixel
> clock, value of pixclock is ignored\n");
> + drm_dbg_kms(dev, "fbdev emulation doesn't support changing the
> pixel clock, value of pixclock is ignored\n");
> var->pixclock = 0;
> }
>
> @@ -1268,7 +1270,7 @@ int drm_fb_helper_check_var(struct fb_var_screeninfo
> *var,
> if (var->bits_per_pixel != fb->format->cpp[0] * 8 ||
> var->xres > fb->width || var->yres > fb->height ||
> var->xres_virtual > fb->width || var->yres_virtual > fb->height) {
> - DRM_DEBUG("fb requested width/height/bpp can't fit in current
> fb "
> + drm_dbg_kms(dev, "fb requested width/height/bpp can't fit in
> current fb "
> "request %dx%d-%d (virtual %dx%d) > %dx%d-%d\n",
> var->xres, var->yres, var->bits_per_pixel,
> var->xres_virtual, var->yres_virtual,
> @@ -1295,7 +1297,7 @@ int drm_fb_helper_check_var(struct fb_var_screeninfo
> *var,
>* so reject all pixel format changing requests.
>*/
> if (!drm_fb_pixel_format_equal(var, &info->var)) {
> - DRM_DEBUG("fbdev emulation doesn't support changing the pixel
> format\n");
> + drm_dbg_kms(dev, "fbdev emulation doesn't support changing the
> pixel format\n");
> return -EINVAL;
> }
>
> @@ -1320,7 +1322,7 @@ int drm_fb_helper_set_par(struct fb_info *info)
> return -EBUSY;
>
> if (var->pixclock != 0) {
> - DRM_ERROR("PIXEL CLOCK SET\n");
> + drm_err(fb_helper->dev, "PIXEL CLOCK SET\n");
> return -EINVAL;
> }
>
> @@ -1430,6 +1432,7 @@ static int drm_fb_helper_single_fb_probe(struct
> drm_fb_helper *fb_helper,
>int preferred_bpp)
> {
> struct drm_client_dev *client = &fb_helper->client;
> + struct drm_device *dev = fb_helper->dev;
> int ret = 0;
> int crtc_count = 0;
> struct drm_connector_list_iter conn_iter;
> @@ -1493,7 +1496,7 @@ static int drm_fb_helper_single_fb_probe(struct
> drm_fb_helper *fb_helper,
> struct drm_plane *plane = crtc->primary;
> int j;
>
> - DRM_DEBUG("test CRTC %u primary plane\n", drm_crtc_index(crtc));
> + drm_dbg_kms(dev, "test CRTC %u primary plane\n",
> drm_crtc_index(crtc));
>
> for (j = 0; j < plane->format_count; j++) {
> const struct drm_format_info *fmt;
> @@ -1526,7 +1529,7 @@ static int drm_fb_helper_single_fb_probe(struct
> drm_fb_helper *fb_helper,
> }
> }
> if (sizes.surface_depth != best_depth && best_depth) {
> - DRM_INFO("requested bpp %d, scaled depth down to %d",
> + drm_info(dev, "requested bpp %d, scaled depth down to %d",
>sizes.surface_bpp, best_depth);
> sizes.surface_depth = best_depth;
> }
> @@ -1574,7 +1577,7 @@ static int drm_fb_helper_single_fb_probe(struct
> drm_fb_helper *fb_helper,
> mutex_unlock(&client->modeset_mutex);
>
> if (crtc_count == 0 || sizes.fb_width == -1 || sizes.fb_height == -1) {
> - DRM_INFO("Cannot find any crtc or sizes\n");
> + drm_info(dev, "Cannot find any
Re: [PATCH 2/8] drm/client: convert to drm device based logging
Hi Jani.
On Tue, Dec 10, 2019 at 02:30:44PM +0200, Jani Nikula wrote:
> Prefer drm_dbg_kms() and drm_err() over DRM_DEV_DEBUG_KMS() and
> DRM_DEV_ERROR().
>
> Signed-off-by: Jani Nikula
Reviewed-by: Sam Ravnborg
> ---
> drivers/gpu/drm/drm_client.c | 10 +-
> 1 file changed, 5 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_client.c b/drivers/gpu/drm/drm_client.c
> index d9a2e3695525..b031b45aa8ef 100644
> --- a/drivers/gpu/drm/drm_client.c
> +++ b/drivers/gpu/drm/drm_client.c
> @@ -150,7 +150,7 @@ void drm_client_release(struct drm_client_dev *client)
> {
> struct drm_device *dev = client->dev;
>
> - DRM_DEV_DEBUG_KMS(dev->dev, "%s\n", client->name);
> + drm_dbg_kms(dev, "%s\n", client->name);
>
> drm_client_modeset_free(client);
> drm_client_close(client);
> @@ -203,7 +203,7 @@ void drm_client_dev_hotplug(struct drm_device *dev)
> continue;
>
> ret = client->funcs->hotplug(client);
> - DRM_DEV_DEBUG_KMS(dev->dev, "%s: ret=%d\n", client->name, ret);
> + drm_dbg_kms(dev, "%s: ret=%d\n", client->name, ret);
> }
> mutex_unlock(&dev->clientlist_mutex);
> }
> @@ -223,7 +223,7 @@ void drm_client_dev_restore(struct drm_device *dev)
> continue;
>
> ret = client->funcs->restore(client);
> - DRM_DEV_DEBUG_KMS(dev->dev, "%s: ret=%d\n", client->name, ret);
> + drm_dbg_kms(dev, "%s: ret=%d\n", client->name, ret);
> if (!ret) /* The first one to return zero gets the privilege to
> restore */
> break;
> }
> @@ -351,8 +351,8 @@ static void drm_client_buffer_rmfb(struct
> drm_client_buffer *buffer)
>
> ret = drm_mode_rmfb(buffer->client->dev, buffer->fb->base.id,
> buffer->client->file);
> if (ret)
> - DRM_DEV_ERROR(buffer->client->dev->dev,
> - "Error removing FB:%u (%d)\n",
> buffer->fb->base.id, ret);
> + drm_err(buffer->client->dev,
> + "Error removing FB:%u (%d)\n", buffer->fb->base.id,
> ret);
>
> buffer->fb = NULL;
> }
> --
> 2.20.1
>
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Intel-gfx] [RFC v2 02/12] drm/i915/svm: Runtime (RT) allocator support
On Sun, Dec 15, 2019 at 10:24 PM Niranjan Vishwanathapura <
niranjana.vishwanathap...@intel.com> wrote:
> On Sat, Dec 14, 2019 at 10:31:37AM +, Chris Wilson wrote:
> >Quoting Jason Ekstrand (2019-12-14 00:36:19)
> >> On Fri, Dec 13, 2019 at 5:24 PM Niranjan Vishwanathapura <
> >> niranjana.vishwanathap...@intel.com> wrote:
> >>
> >> On Fri, Dec 13, 2019 at 04:58:42PM -0600, Jason Ekstrand wrote:
> >> >
> >> > +/**
> >> > + * struct drm_i915_gem_vm_bind
> >> > + *
> >> > + * Bind an object in a vm's page table.
> >> >
> >> > First off, this is something I've wanted for a while for
> Vulkan, it's
> >> just
> >> > never made its way high enough up the priority list. However,
> it's
> >> going
> >> > to have to come one way or another soon. I'm glad to see
> kernel API
> >> for
> >> > this being proposed.
> >> > I do, however, have a few high-level comments/questions about
> the API:
> >> >1. In order to be useful for sparse memory support, the API
> has to go
> >> the
> >> > other way around so that it binds a VA range to a range within
> the BO.
> >> It
> >> > also needs to be able to handle overlapping where two different
> VA
> >> ranges
> >> > may map to the same underlying bytes in the BO. This likely
> means that
> >> > unbind needs to also take a VA range and only unbind that range.
> >> >2. If this is going to be useful for managing GL's address
> space where
> >> we
> >> > have lots of BOs, we probably want it to take a list of ranges
> so we
> >> > aren't making one ioctl for each thing we want to bind.
> >>
> >> Hi Jason,
> >>
> >> Yah, some of these requirements came up.
> >>
> >>
> >> Yes, I have raised them every single time an API like this has come
> across my
> >> e-mail inbox for years and they continue to get ignored. Why are we
> landing an
> >> API that we know isn't the API we want especially when it's pretty
> obvious
> >> roughly what the API we want is? It may be less time in the short
> term, but
> >> long-term it means two ioctls and two implementations in i915, IGT
> tests for
> >> both code paths, and code in all UMDs to call one or the other
> depending on
> >> what kernel you're running on, and we have to maintain all that code
> going
> >> forward forever. Sure, that's a price we pay today for a variety of
> things but
> >> that's because they all seemed like the right thing at the time.
> Landing the
> >> wrong API when we know it's the wrong API seems foolish.
> >
> >Exactly. This is not even close to the uAPI we need. Reposting an RFC
> >without taking in the concerns last time (or the time before that, or
> >the time before that...) suggests that you aren't really requesting for
> >comments at all.
>
> Thanks Jason for detailed exlanation.
> Chris, all comments and guidance are much appreciated :)
>
> I haven't looked in detail, but my concern is that implementing
> partial object binding (offset, lenght) from vma down to [un]binding
> in ppgtt might be a lot of work to include in this SVM patch series.
> I believe we need the partial object binding in non-SVM scenario
> as well?
>
Yes, the Vulkan APIs require both partial binding and aliasing.
It may be worth pointing out that we're already doing some of this stuff
today, although in a rather backwards way. Our non-softpin model for
Vulkan uses a memfd which we then map in userspace and turn into a BO via
userptr. Due to the way we handle threading in the driver, we end up with
multiple BOs pointing to the same overlapping range in the memfd and hence
the same pages. That doesn't mean that everything in the path is already
set up for what you need but the VA -> page mappings should be. Also,
avoiding these kinds of shinanigans is exactly why we want a "real" kernel
API for this. :-)
> Ok, let me change the interface as below.
>
> struct drm_i915_gem_vm_bind_va
> {
> /** VA start to bind **/
> __u64 start;
>
> /** Offset in Object to bind for I915_GEM_VM_BIND_SVM_OBJ type **/
> __u64 offset;
>
> /** VA length to [un]bind **/
> __u64 length;
>
> /** Type of memory to [un]bind **/
> __u32 type;
> #define I915_GEM_VM_BIND_SVM_OBJ 0
> #define I915_GEM_VM_BIND_SVM_BUFFER 1
>
> /** Object handle to [un]bind for I915_GEM_VM_BIND_SVM_OBJ type **/
> __u32 handle;
>
> /** Flags **/
> __u32 flags;
> #define I915_GEM_VM_BIND_UNBIND (1 << 0)
> #define I915_GEM_VM_BIND_READONLY(1 << 1)
> }
>
> struct drm_i915_gem_vm_bind {
> /** vm to [un]bind **/
> __u32 vm_id;
>
> /** number of VAs to bind **/
> __u32 num_vas;
>
> /** Array of VAs to bind **/
> struct drm_i915_gem_vm_bind_va *bind_vas;
>
> /** User extensions **/
> __u64 extensions;
> };
>
> When synchronization control is added as ext
Re: [pull] amdgpu, amdkfd, radeon drm-next-5.6
On Tue, Dec 17, 2019 at 12:41:06PM -0500, Alex Deucher wrote: > On Tue, Dec 17, 2019 at 11:46 AM Daniel Vetter wrote: > > > > On Tue, Dec 17, 2019 at 09:17:51AM -0500, Alex Deucher wrote: > > > On Tue, Dec 17, 2019 at 8:47 AM Alex Deucher > > > wrote: > > > > > > > > On Tue, Dec 17, 2019 at 7:52 AM Daniel Vetter wrote: > > > > > > > > > > On Wed, Dec 11, 2019 at 05:30:20PM -0500, Alex Deucher wrote: > > > > > > Hi Dave, Daniel, > > > > > > > > > > > > Kicking off 5.6 with new stuff from AMD. There is a UAPI addition. > > > > > > We > > > > > > added a new firmware for display, and this just adds the version > > > > > > query > > > > > > to our existing firmware query interface. UMDs like mesa use this > > > > > > interface to > > > > > > query things like CP or UVD firmware versions to see what features > > > > > > are > > > > > > supported. > > > > > > > > > > I got bored, and a quick serach for what the userspace for > > > > > AMDGPU_INFO_FW_DMCUB didn't turn up anything. At least didn't spot any > > > > > patches on mesa-devel or mesa MR and the patch on amd-gfx also didn't > > > > > come > > > > > with pointers. From the patch series description I have no idea why > > > > > you'd > > > > > even want this in userspace (but then I stopped being surprised by hw > > > > > design long ago). > > > > > > > > > > > > > We expose all the firmwares via the same interface for consistency, > > > > but the only ones user space generally cares about are the versions > > > > for the acceleration engines like gfx and multimedia. I can revert it > > > > if it's a big deal, but I'd prefer to keep it for consistency since > > > > all the others are already available via the same interface. It's not > > > > really a new interace with no user per se. > > > > Imo not the best style adding uapi just in case. We have a lot of that > > which then ended up (in other drivers at least) being for some hacks for > > blobs or vendor trees and stuff like that. So personally I'd lean towards > > just taking all the ones out you don't need (but keep the debugfs ofc), > > but meh. > > > > > Also, there are a few minor conflicts. I backmerged drm-next into my > > > drm-next branch if that is helpful. I can also send another PR with > > > the backmerge if you'd prefer. > > > > Looks like you didn't push, and I've thrown in the towel on the wm stuff. > > I honestly wonder how exactly you validate this stuff internally, this is > > almost as bad as i915 :-) > > > > Fixing your scripts to also push your validated integration tree (whatever > > funny kernel version that's based on, at least I'm assuming you're testing > > the merged version somewhere) might be really good here. Or use dim push, > > so that the git rr-cache is shared. > > Here's the relevant backmerge in my drm-next branch: > https://cgit.freedesktop.org/~agd5f/linux/commit/?h=drm-next&id=a759ca47934e83a117a7095a5fd9b91e62a91a0c > > And here's the standalong branch with just the merge on top of my last PR: > https://cgit.freedesktop.org/~agd5f/linux/log/?h=drm-next-5.6-backmerge Oh silly me didn't scroll down enough. btw there's a bunch of other things now in drm/amd from drm-misc, I think you want to redo your backmerge (and double check what I've done). Pulled, thanks for the pile. -Daniel > > Thanks! > > Alex > > > > > Thanks, Daniel > > > > > > > > Alex > > > > > > > Alex > > > > > > > > > Otherwise looks all good, no complaints from dim at least :-) > > > > > -Daniel > > > > > > > > > > > > > > > > > The following changes since commit > > > > > > 622b2a0ab647d2755f2c1f1000d3403e86a69763: > > > > > > > > > > > > drm/amdgpu/vcn: finish delay work before release resources > > > > > > (2019-11-13 15:29:42 -0500) > > > > > > > > > > > > are available in the Git repository at: > > > > > > > > > > > > git://people.freedesktop.org/~agd5f/linux > > > > > > tags/drm-next-5.6-2019-12-11 > > > > > > > > > > > > for you to fetch changes up to > > > > > > ad808910be68dcf8da5d837d4511d00ad5d3678a: > > > > > > > > > > > > drm/amdgpu: fix license on Kconfig and Makefiles (2019-12-11 > > > > > > 15:22:08 -0500) > > > > > > > > > > > > > > > > > > drm-next-5.6-2019-12-11: > > > > > > > > > > > > amdgpu: > > > > > > - Add MST atomic routines > > > > > > - Add support for DMCUB (new helper microengine for displays) > > > > > > - Add OEM i2c support in DC > > > > > > - Use vstartup for vblank events on DCN > > > > > > - Simplify Kconfig for DC > > > > > > - Renoir fixes for DC > > > > > > - Clean up function pointers in DC > > > > > > - Initial support for HDCP 2.x > > > > > > - Misc code cleanups > > > > > > - GFX10 fixes > > > > > > - Rework JPEG engine handling for VCN > > > > > > - Add clock and power gating support for JPEG > > > > > > - BACO support for Arcturus > > > > > > - Cleanup PSP ring handling > > > > > > - Add framework for using BACO with runtime pm to save power > > > > > > -
Re: [PATCH v6] drm/mcde: Some fixes to handling video mode
On Tue, Dec 17, 2019 at 04:09:59PM +0100, Linus Walleij wrote:
> The video DSI mode had not really been tested. These fixes makes
> it more likely to work on real hardware:
> - Put the active width (x width) in the right bits and the VSA
> (vertical sync active) in the right bits (those were swapped).
> - Calculate the packet sizes in bytes as in the vendor driver,
> rather than in bits. Test the calculations agains a
> spreadsheet and confirmed by debug prints to be reasonable.
> - Also verified the register values with relative confidence
> to register dumps from the Samsung GT-I8190 boot loader
> graphics. We are not identical but not off by far either.
> - Error out if the current mode and refresh frequency doesn't
> work out. (In the future we may simply want to scale down
> the vrefresh.)
> - Handle negative result in front/back/sync packages and fall
> back to zero like in the vendor driver.
> - Put in lots of clarifying comments and references to the
> documentation where the code is hard to understand.
> - Set the DSI_VID_VCA_SETTING2 field
> DSI_VID_VCA_SETTING2_MAX_LINE_LIMIT to blkline_pck - 6 as in
> the vendor driver and mask the field properly.
> - Set the DSI_VID_VCA_SETTING1 field
> DSI_VID_VCA_SETTING1_MAX_BURST_LIMIT to blkeol_pck - 6 to
> blkeol_duration - 6 as in the vendor driver.
>
> Cc: Stephan Gerhold
> Fixes: 5fc537bfd000 ("drm/mcde: Add new driver for ST-Ericsson MCDE")
> Signed-off-by: Linus Walleij
Thanks for making all the changes!
I don't fully understand most of the calculations,
but it seems to match the code in the vendor kernel now. Therefore:
Reviewed-by: Stephan Gerhold
> ---
> ChangeLog v5->v6:
> - DSI_VID_VCA_SETTING1_MAX_BURST_LIMIT should be blkeol_pck - 6
> not blkeol_duration - 6.
> - Parenthesize some calculations.
> ChangeLog v4->v5:
> - Restore log order, last verstion of the changelog inadvertedly
> merged v3 and v4 into v3 since I thought I didn't send out v3...
> - Parens in blkeol_pck = bpl - (mode->htotal * cpp) - 6 for
> explicit priority.
> - Use mask-and-set for DSI_VID_PCK_TIME and DSI_VID_VCA_SETTING1
> - Restore DSI_VID_VCA_SETTING2 field
> DSI_VID_VCA_SETTING2_MAX_LINE_LIMIT to blkline_pck - 6 as in
> the vendor driver and mask the field properly.
> ChangeLog v3->v4:
> - Calculate toward actual HS rate of the clock rather than the
> idealized rate provided by the panel resolution, this is what
> the vendor driver does.
> - Add much comments and elaborate with references to the manual
> so the code can be understood as far as possible.
> - Compared register dumps to that on the Samsung GT-I8190 (Golden)
> boot loader settings. We are now reasonably close to these,
> it may be that the boot loader driver is using slightly different
> settings for porches and syncs etc. But all figures makes sense.
> - Duplicated the vendor code in a spread sheet and compared to
> what this code gives and we have an identical match with one
> small exception that the vendor code adds a small padding of 2
> lines to the vertical blanking area. This looks weird and might
> be some hackishly specified porch.
> ChangeLog v2->v3:
> - Rename the "bpp" variable to "cpp" since it is "chars per pixel"
> this was confusingly named in the vendor driver and it got
> carried over.
> - Assign the SETTING2_EXACT_BURST_LIMIT by first shifting
> then masking.
> - Also mask with the inverse of DSI_VID_BLKSIZE1_BLKEOL_PCK_MASK
> before writing blkeol into DSI_VID_BLKSIZE1, so we make sure
> to zero these bits first.
> - Also mask with DSI_VID_BLKSIZE1_BLKLINE_EVENT_PCK_MASK
> when writing event package length.
> - Comb through the code and compare it to vendor code and try
> to get closer to doing what the vendor driver is doing.
> ChangeLog v1->v2:
> - Fix some more comments so we understand what is going on.
> - Set up the maximum line limit size in the right register
> instead of setting it in the burst size register portion.
> - Set some default wakeup time other than zero (still need
> fixing more).
> ---
> drivers/gpu/drm/mcde/mcde_dsi.c | 239 +--
> drivers/gpu/drm/mcde/mcde_dsi_regs.h | 1 +
> 2 files changed, 192 insertions(+), 48 deletions(-)
>
> diff --git a/drivers/gpu/drm/mcde/mcde_dsi.c b/drivers/gpu/drm/mcde/mcde_dsi.c
> index 21cee4d9d2fd..6613c68c0633 100644
> --- a/drivers/gpu/drm/mcde/mcde_dsi.c
> +++ b/drivers/gpu/drm/mcde/mcde_dsi.c
> @@ -379,13 +379,14 @@ void mcde_dsi_te_request(struct mipi_dsi_device *mdsi)
> static void mcde_dsi_setup_video_mode(struct mcde_dsi *d,
> const struct drm_display_mode *mode)
> {
> - u8 bpp = mipi_dsi_pixel_format_to_bpp(d->mdsi->format);
> + /* cpp, characters per pixel, number of bytes per pixel */
> + u8 cpp = mipi_dsi_pixel_format_to_bpp(d->mdsi->format) / 8;
> + u64 pclk;
> u64 bpl;
> - u32 hfp;
> - u32 hbp;
> - u32 hsa;
> + int hfp;
> + i
Re: [pull] amdgpu, amdkfd, radeon drm-next-5.6
On Tue, Dec 17, 2019 at 11:46 AM Daniel Vetter wrote: > > On Tue, Dec 17, 2019 at 09:17:51AM -0500, Alex Deucher wrote: > > On Tue, Dec 17, 2019 at 8:47 AM Alex Deucher wrote: > > > > > > On Tue, Dec 17, 2019 at 7:52 AM Daniel Vetter wrote: > > > > > > > > On Wed, Dec 11, 2019 at 05:30:20PM -0500, Alex Deucher wrote: > > > > > Hi Dave, Daniel, > > > > > > > > > > Kicking off 5.6 with new stuff from AMD. There is a UAPI addition. > > > > > We > > > > > added a new firmware for display, and this just adds the version query > > > > > to our existing firmware query interface. UMDs like mesa use this > > > > > interface to > > > > > query things like CP or UVD firmware versions to see what features are > > > > > supported. > > > > > > > > I got bored, and a quick serach for what the userspace for > > > > AMDGPU_INFO_FW_DMCUB didn't turn up anything. At least didn't spot any > > > > patches on mesa-devel or mesa MR and the patch on amd-gfx also didn't > > > > come > > > > with pointers. From the patch series description I have no idea why > > > > you'd > > > > even want this in userspace (but then I stopped being surprised by hw > > > > design long ago). > > > > > > > > > > We expose all the firmwares via the same interface for consistency, > > > but the only ones user space generally cares about are the versions > > > for the acceleration engines like gfx and multimedia. I can revert it > > > if it's a big deal, but I'd prefer to keep it for consistency since > > > all the others are already available via the same interface. It's not > > > really a new interace with no user per se. > > Imo not the best style adding uapi just in case. We have a lot of that > which then ended up (in other drivers at least) being for some hacks for > blobs or vendor trees and stuff like that. So personally I'd lean towards > just taking all the ones out you don't need (but keep the debugfs ofc), > but meh. > > > Also, there are a few minor conflicts. I backmerged drm-next into my > > drm-next branch if that is helpful. I can also send another PR with > > the backmerge if you'd prefer. > > Looks like you didn't push, and I've thrown in the towel on the wm stuff. > I honestly wonder how exactly you validate this stuff internally, this is > almost as bad as i915 :-) > > Fixing your scripts to also push your validated integration tree (whatever > funny kernel version that's based on, at least I'm assuming you're testing > the merged version somewhere) might be really good here. Or use dim push, > so that the git rr-cache is shared. Here's the relevant backmerge in my drm-next branch: https://cgit.freedesktop.org/~agd5f/linux/commit/?h=drm-next&id=a759ca47934e83a117a7095a5fd9b91e62a91a0c And here's the standalong branch with just the merge on top of my last PR: https://cgit.freedesktop.org/~agd5f/linux/log/?h=drm-next-5.6-backmerge Thanks! Alex > > Thanks, Daniel > > > > > Alex > > > > > Alex > > > > > > > Otherwise looks all good, no complaints from dim at least :-) > > > > -Daniel > > > > > > > > > > > > > > The following changes since commit > > > > > 622b2a0ab647d2755f2c1f1000d3403e86a69763: > > > > > > > > > > drm/amdgpu/vcn: finish delay work before release resources > > > > > (2019-11-13 15:29:42 -0500) > > > > > > > > > > are available in the Git repository at: > > > > > > > > > > git://people.freedesktop.org/~agd5f/linux > > > > > tags/drm-next-5.6-2019-12-11 > > > > > > > > > > for you to fetch changes up to > > > > > ad808910be68dcf8da5d837d4511d00ad5d3678a: > > > > > > > > > > drm/amdgpu: fix license on Kconfig and Makefiles (2019-12-11 > > > > > 15:22:08 -0500) > > > > > > > > > > > > > > > drm-next-5.6-2019-12-11: > > > > > > > > > > amdgpu: > > > > > - Add MST atomic routines > > > > > - Add support for DMCUB (new helper microengine for displays) > > > > > - Add OEM i2c support in DC > > > > > - Use vstartup for vblank events on DCN > > > > > - Simplify Kconfig for DC > > > > > - Renoir fixes for DC > > > > > - Clean up function pointers in DC > > > > > - Initial support for HDCP 2.x > > > > > - Misc code cleanups > > > > > - GFX10 fixes > > > > > - Rework JPEG engine handling for VCN > > > > > - Add clock and power gating support for JPEG > > > > > - BACO support for Arcturus > > > > > - Cleanup PSP ring handling > > > > > - Add framework for using BACO with runtime pm to save power > > > > > - Move core pci state handling out of the driver for pm ops > > > > > - Allow guest power control in 1 VF case with SR-IOV > > > > > - SR-IOV fixes > > > > > - RAS fixes > > > > > - Support for power metrics on renoir > > > > > - Golden settings updates for gfx10 > > > > > - Enable gfxoff on supported navi10 skus > > > > > - Update MAINTAINERS > > > > > > > > > > amdkfd: > > > > > - Clean up generational gfx code > > > > > - Fixes for gfx10 > > > > > - DIQ fixes > > > > > - Share more code with amdgpu > > > > > > > > > > radeon: > > > > >
Re: [PATCH v2] dma-heap: Make the symbol 'dma_heap_ioctl_cmds' static
Hello Zhong Jiang,
On Tue, 17 Dec 2019 at 07:56, zhong jiang wrote:
>
> On 2019/12/17 5:13, John Stultz wrote:
> > On Mon, Dec 16, 2019 at 5:43 AM zhong jiang wrote:
> >> Fix the following sparse warning.
Thanks for the patch; could I request you to please use
scripts/get_maintainer.pl to get the cc: list for the patches?
+ dri-devel.
> >>
> >> drivers/dma-buf/dma-heap.c:109:14: warning: symbol 'dma_heap_ioctl_cmds'
> >> was not declared. Should it be static?
> >>
> >> Signed-off-by: zhong jiang
> >> ---
> >> drivers/dma-buf/dma-heap.c | 2 +-
> >> 1 file changed, 1 insertion(+), 1 deletion(-)
> >>
> >> diff --git a/drivers/dma-buf/dma-heap.c b/drivers/dma-buf/dma-heap.c
> >> index 4f04d10..da2090e 100644
> >> --- a/drivers/dma-buf/dma-heap.c
> >> +++ b/drivers/dma-buf/dma-heap.c
> >> @@ -106,7 +106,7 @@ static long dma_heap_ioctl_allocate(struct file *file,
> >> void *data)
> >> return 0;
> >> }
> >>
> >> -unsigned int dma_heap_ioctl_cmds[] = {
> >> +static unsigned int dma_heap_ioctl_cmds[] = {
> >> DMA_HEAP_IOC_ALLOC,
> >> };
> > Acked-by: John Stultz
> >
> > This patch will collide with Andrew's _IOCTL_ naming change, but its a
> > fairly simple thing to resolve.
> >
> > Sumit: If you're comfortable resolving the collision, please queue
> > with the rest of the recent changes for drm-misc-next.
> > Otherwise, I'm happy to submit the resolution I tested with here
> > afterwards. Let me know.
Of course, I am sure I can handle collisions, John, or else being a
maintainer might get a tad difficult :)
> As it is an fairly simple patch, I hope you can resolve the issue directly.
>
> Thanks,
> zhong jiang
> > thanks
> > -john
> >
Best,
Sumit.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [pull] amdgpu, amdkfd, radeon drm-next-5.6
On Tue, Dec 17, 2019 at 09:17:51AM -0500, Alex Deucher wrote: > On Tue, Dec 17, 2019 at 8:47 AM Alex Deucher wrote: > > > > On Tue, Dec 17, 2019 at 7:52 AM Daniel Vetter wrote: > > > > > > On Wed, Dec 11, 2019 at 05:30:20PM -0500, Alex Deucher wrote: > > > > Hi Dave, Daniel, > > > > > > > > Kicking off 5.6 with new stuff from AMD. There is a UAPI addition. We > > > > added a new firmware for display, and this just adds the version query > > > > to our existing firmware query interface. UMDs like mesa use this > > > > interface to > > > > query things like CP or UVD firmware versions to see what features are > > > > supported. > > > > > > I got bored, and a quick serach for what the userspace for > > > AMDGPU_INFO_FW_DMCUB didn't turn up anything. At least didn't spot any > > > patches on mesa-devel or mesa MR and the patch on amd-gfx also didn't come > > > with pointers. From the patch series description I have no idea why you'd > > > even want this in userspace (but then I stopped being surprised by hw > > > design long ago). > > > > > > > We expose all the firmwares via the same interface for consistency, > > but the only ones user space generally cares about are the versions > > for the acceleration engines like gfx and multimedia. I can revert it > > if it's a big deal, but I'd prefer to keep it for consistency since > > all the others are already available via the same interface. It's not > > really a new interace with no user per se. Imo not the best style adding uapi just in case. We have a lot of that which then ended up (in other drivers at least) being for some hacks for blobs or vendor trees and stuff like that. So personally I'd lean towards just taking all the ones out you don't need (but keep the debugfs ofc), but meh. > Also, there are a few minor conflicts. I backmerged drm-next into my > drm-next branch if that is helpful. I can also send another PR with > the backmerge if you'd prefer. Looks like you didn't push, and I've thrown in the towel on the wm stuff. I honestly wonder how exactly you validate this stuff internally, this is almost as bad as i915 :-) Fixing your scripts to also push your validated integration tree (whatever funny kernel version that's based on, at least I'm assuming you're testing the merged version somewhere) might be really good here. Or use dim push, so that the git rr-cache is shared. Thanks, Daniel > > Alex > > > Alex > > > > > Otherwise looks all good, no complaints from dim at least :-) > > > -Daniel > > > > > > > > > > > The following changes since commit > > > > 622b2a0ab647d2755f2c1f1000d3403e86a69763: > > > > > > > > drm/amdgpu/vcn: finish delay work before release resources > > > > (2019-11-13 15:29:42 -0500) > > > > > > > > are available in the Git repository at: > > > > > > > > git://people.freedesktop.org/~agd5f/linux tags/drm-next-5.6-2019-12-11 > > > > > > > > for you to fetch changes up to ad808910be68dcf8da5d837d4511d00ad5d3678a: > > > > > > > > drm/amdgpu: fix license on Kconfig and Makefiles (2019-12-11 15:22:08 > > > > -0500) > > > > > > > > > > > > drm-next-5.6-2019-12-11: > > > > > > > > amdgpu: > > > > - Add MST atomic routines > > > > - Add support for DMCUB (new helper microengine for displays) > > > > - Add OEM i2c support in DC > > > > - Use vstartup for vblank events on DCN > > > > - Simplify Kconfig for DC > > > > - Renoir fixes for DC > > > > - Clean up function pointers in DC > > > > - Initial support for HDCP 2.x > > > > - Misc code cleanups > > > > - GFX10 fixes > > > > - Rework JPEG engine handling for VCN > > > > - Add clock and power gating support for JPEG > > > > - BACO support for Arcturus > > > > - Cleanup PSP ring handling > > > > - Add framework for using BACO with runtime pm to save power > > > > - Move core pci state handling out of the driver for pm ops > > > > - Allow guest power control in 1 VF case with SR-IOV > > > > - SR-IOV fixes > > > > - RAS fixes > > > > - Support for power metrics on renoir > > > > - Golden settings updates for gfx10 > > > > - Enable gfxoff on supported navi10 skus > > > > - Update MAINTAINERS > > > > > > > > amdkfd: > > > > - Clean up generational gfx code > > > > - Fixes for gfx10 > > > > - DIQ fixes > > > > - Share more code with amdgpu > > > > > > > > radeon: > > > > - PPC DMA fix > > > > - Register checker fixes for r1xx/r2xx > > > > - Misc cleanups > > > > > > > > > > > > Alex Deucher (34): > > > > drm/amdgpu/display: fix the build when CONFIG_DRM_AMD_DC_DCN is > > > > not set > > > > drm/amdgpu/display: fix warning when CONFIG_DRM_AMD_DC_DCN is not > > > > set > > > > drm/amdgpu/soc15: move struct definition around to align with > > > > other soc15 asics > > > > drm/amdgpu/nv: add asic func for fetching vbios from rom directly > > > > drm/amdgpu/powerplay: properly set PP_GFXOFF_MASK (v2) > > > >
Re: Warnings in DRM code when removing/unbinding a driver
Hi John,
On Mon, 2019-12-16 at 17:23 +, John Garry wrote:
> Hi all,
>
> Enabling CONFIG_DEBUG_TEST_DRIVER_REMOVE causes many warns on a system
> with the HIBMC hw:
>
> [ 27.788806] WARNING: CPU: 24 PID: 1 at
> drivers/gpu/drm/drm_gem_vram_helper.c:564 bo_driver_move_notify+0x8c/0x98
A total shot in the dark. This might make no sense,
but it's worth a try:
diff --git a/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c
b/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c
index 2fd4ca91a62d..69bb0e29da88 100644
--- a/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c
+++ b/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c
@@ -247,9 +247,8 @@ static int hibmc_unload(struct drm_device *dev)
{
struct hibmc_drm_private *priv = dev->dev_private;
- hibmc_fbdev_fini(priv);
-
drm_atomic_helper_shutdown(dev);
+ hibmc_fbdev_fini(priv);
if (dev->irq_enabled)
drm_irq_uninstall(dev);
Hope it helps,
Ezequiel
> [ 27.798969] Modules linked in:
> [ 27.802018] CPU: 24 PID: 1 Comm: swapper/0 Tainted: GB
> 5.5.0-rc1-dirty #565
> [ 27.810358] Hardware name: Huawei D06 /D06, BIOS Hisilicon D06 UEFI
> RC0 - V1.16.01 03/15/2019
> [ 27.818872] pstate: 20c9 (nzCv daif +PAN +UAO)
> [ 27.823654] pc : bo_driver_move_notify+0x8c/0x98
> [ 27.828262] lr : bo_driver_move_notify+0x40/0x98
> [ 27.832868] sp : 00236f0677e0
> [ 27.836173] x29: 00236f0677e0 x28: a0001454e5e0
> [ 27.841476] x27: 002366e52128 x26: a000149e67b0
> [ 27.846779] x25: 002366e523e0 x24: 002336936120
> [ 27.852082] x23: 0023346f4010 x22: 002336936128
> [ 27.857385] x21: a000149c15c0 x20: 0023369361f8
> [ 27.862687] x19: 002336936000 x18: 1258
> [ 27.867989] x17: 1190 x16: 11d0
> [ 27.873292] x15: 1348 x14: a00012d68190
> [ 27.878595] x13: 0006 x12: 140003241f91
> [ 27.883897] x11: 940003241f91 x10: dfffa000
> [ 27.889200] x9 : 940003241f92 x8 : 0001
> [ 27.894502] x7 : a0001920fc88 x6 : 940003241f92
> [ 27.899804] x5 : 940003241f92 x4 : 0023369363a0
> [ 27.905107] x3 : a00010c104b8 x2 : dfffa000
> [ 27.910409] x1 : 0003 x0 : 0001
> [ 27.915712] Call trace:
> [ 27.918151] bo_driver_move_notify+0x8c/0x98
> [ 27.922412] ttm_bo_cleanup_memtype_use+0x54/0x100
> [ 27.927194] ttm_bo_put+0x3a0/0x5d0
> [ 27.930673] drm_gem_vram_object_free+0xc/0x18
> [ 27.935109] drm_gem_object_free+0x34/0xd0
> [ 27.939196] drm_gem_object_put_unlocked+0xc8/0xf0
> [ 27.943978] hibmc_user_framebuffer_destroy+0x20/0x40
> [ 27.949020] drm_framebuffer_free+0x48/0x58
> [ 27.953194] drm_mode_object_put.part.1+0x90/0xe8
> [ 27.957889] drm_mode_object_put+0x28/0x38
> [ 27.961976] hibmc_fbdev_fini+0x54/0x78
> [ 27.965802] hibmc_unload+0x2c/0xd0
> [ 27.969281] hibmc_pci_remove+0x2c/0x40
> [ 27.973109] pci_device_remove+0x6c/0x140
> [ 27.977110] really_probe+0x174/0x548
> [ 27.980763] driver_probe_device+0x7c/0x148
> [ 27.984936] device_driver_attach+0x94/0xa0
> [ 27.989109] __driver_attach+0xa8/0x110
> [ 27.992935] bus_for_each_dev+0xe8/0x158
> [ 27.996849] driver_attach+0x30/0x40
> [ 28.000415] bus_add_driver+0x234/0x2f0
> [ 28.004241] driver_register+0xbc/0x1d0
> [ 28.008067] __pci_register_driver+0xbc/0xd0
> [ 28.012329] hibmc_pci_driver_init+0x20/0x28
> [ 28.016590] do_one_initcall+0xb4/0x254
> [ 28.020417] kernel_init_freeable+0x27c/0x328
> [ 28.024765] kernel_init+0x10/0x118
> [ 28.028245] ret_from_fork+0x10/0x18
> [ 28.031813] ---[ end trace 35a83b71b657878d ]---
> [ 28.036503] [ cut here ]
> [ 28.041115] WARNING: CPU: 24 PID: 1 at
> drivers/gpu/drm/drm_gem_vram_helper.c:40 ttm_buffer_object_destroy+0x4c/0x80
> [ 28.051537] Modules linked in:
> [ 28.054585] CPU: 24 PID: 1 Comm: swapper/0 Tainted: GB W
> 5.5.0-rc1-dirty #565
> [ 28.062924] Hardware name: Huawei D06 /D06, BIOS Hisilicon D06 UEFI
> RC0 - V1.16.01 03/15/2019
>
> [snip]
>
> Indeed, simply unbinding the device from the driver causes the same sort
> of issue:
>
> root@(none)$ cd ./bus/pci/drivers/hibmc-drm/
> root@(none)$ ls
> :05:00.0 bind new_idremove_id ueventunbind
> root@(none)$ echo \:05\:00.0 > unbind
> [ 116.074352] [ cut here ]
> [ 116.078978] WARNING: CPU: 17 PID: 1178 at
> drivers/gpu/drm/drm_gem_vram_helper.c:40 ttm_buffer_object_destroy+0x4c/0x80
> [ 116.089661] Modules linked in:
> [ 116.092711] CPU: 17 PID: 1178 Comm: sh Tainted: GB W
> 5.5.0-rc1-dirty #565
> [ 116.100704] Hardware name: Huawei D06 /D06, BIOS Hisilicon D06 UEFI
> RC0 - V1.16.01 03/15/2019
> [ 116.109218] pstate: 2049 (nzCv daif +PAN -UAO)
> [ 116.114001] pc : ttm_buffer_object_destroy+0x4c/0x80
> [ 116.118956] lr : ttm_buffer_object_de
Re: [PATCH 1/8] drm/print: introduce new struct drm_device based logging macros
Hi Jani. Will you type a todo entry as requested by Daniel? > Pushed this one patch, thanks for the reviews and acks. The rest could > still use review. ;) Will take a look again later tonight. I recall from last time I looked they were fine but I just never sent anything to the ML. Sam ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Intel-gfx] linux-next: Tree for Dec 16 (drm_panel & intel_panel)
On Tue, 17 Dec 2019, Andy Shevchenko wrote: > On Tue, Dec 17, 2019 at 5:28 PM Jani Nikula > wrote: >> On Tue, 17 Dec 2019, Andy Shevchenko wrote: >> > On Tue, Dec 17, 2019 at 1:56 PM Steven Price wrote: > >> > I think the proper one is to have s/IS_ENABLED/IS_REACHABLE/. >> > It fixes issue for me. >> >> As discussed off-line, this will allow silently building and linking a >> configuration that's actually broken. (No backlight support despite >> expectations.) > > In my case I have deliberately compile backlight as a module to be > used exclusively with backlight-gpio which has nothing to do with > i915. I dunno if backlight is a MUST dependency for i915. It's not a required dependency, all combinations of i915 and backlight are fine, *except* i915=y, backlight=m. This can be achieved with: depends on BACKLIGHT_CLASS_DEVICE || BACKLIGHT_CLASS_DEVICE=n BR, Jani. > > From my perspective the original commit, with all good that it > provides, should not break previously working configurations. Though > we might argue if my "working" kernel configuration had been broken in > the first place... > > Just my 2 cents, though. > >> IMO deep down the problem is that we "select" BACKLIGHT_CLASS_DEVICE all >> over the place, while we should "depends on" it. Everything else is just >> duct tape that allows configurations where built-in code calls backlight >> symbols in modules. It used to be more about an interaction with ACPI, >> now we've added DRM_PANEL to the mix. >> >> I've proposed a fix five years ago [1]. That's what it takes to fix >> these recurring failures for good. I'm not really all that interested in >> the whack-a-mole with the hacks. > > Agree with this. The root cause must be fixed once and for all. > I guess it should be a logical continuation of Sam's series. > >> [1] >> http://lore.kernel.org/r/1413580403-16225-1-git-send-email-jani.nik...@intel.com -- Jani Nikula, Intel Open Source Graphics Center ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Intel-gfx] linux-next: Tree for Dec 16 (drm_panel & intel_panel)
On Tue, Dec 17, 2019 at 5:28 PM Jani Nikula wrote: > On Tue, 17 Dec 2019, Andy Shevchenko wrote: > > On Tue, Dec 17, 2019 at 1:56 PM Steven Price wrote: > > I think the proper one is to have s/IS_ENABLED/IS_REACHABLE/. > > It fixes issue for me. > > As discussed off-line, this will allow silently building and linking a > configuration that's actually broken. (No backlight support despite > expectations.) In my case I have deliberately compile backlight as a module to be used exclusively with backlight-gpio which has nothing to do with i915. I dunno if backlight is a MUST dependency for i915. >From my perspective the original commit, with all good that it provides, should not break previously working configurations. Though we might argue if my "working" kernel configuration had been broken in the first place... Just my 2 cents, though. > IMO deep down the problem is that we "select" BACKLIGHT_CLASS_DEVICE all > over the place, while we should "depends on" it. Everything else is just > duct tape that allows configurations where built-in code calls backlight > symbols in modules. It used to be more about an interaction with ACPI, > now we've added DRM_PANEL to the mix. > > I've proposed a fix five years ago [1]. That's what it takes to fix > these recurring failures for good. I'm not really all that interested in > the whack-a-mole with the hacks. Agree with this. The root cause must be fixed once and for all. I guess it should be a logical continuation of Sam's series. > [1] > http://lore.kernel.org/r/1413580403-16225-1-git-send-email-jani.nik...@intel.com -- With Best Regards, Andy Shevchenko ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Intel-gfx] linux-next: Tree for Dec 16 (drm_panel & intel_panel)
On Tue, 17 Dec 2019, Andy Shevchenko wrote:
> On Tue, Dec 17, 2019 at 1:56 PM Steven Price wrote:
>> On 17/12/2019 06:37, Randy Dunlap wrote:
>> > On 12/16/19 9:42 PM, Sam Ravnborg wrote:
>> >> On Mon, Dec 16, 2019 at 08:25:11AM -0800, Randy Dunlap wrote:
>> >>> On 12/15/19 9:22 PM, Stephen Rothwell wrote:
>
>> >>> on x86_64:
>> >>>
>> >>> ld: drivers/gpu/drm/drm_panel.o: in function `drm_panel_of_backlight':
>> >>> (.text+0x2ee): undefined reference to `devm_of_find_backlight'
>> >>>
>> >>> ld: drivers/gpu/drm/i915/display/intel_panel.o: in function
>> >>> `intel_backlight_device_register':
>> >>> intel_panel.c:(.text+0x593e): undefined reference to
>> >>> `backlight_device_register'
>> >>> ld: drivers/gpu/drm/i915/display/intel_panel.o: in function
>> >>> `intel_backlight_device_unregister':
>> >>> intel_panel.c:(.text+0x5a04): undefined reference to
>> >>> `backlight_device_unregister'
>> >>>
>> >>> CONFIG_DRM_PANEL=y
>> >>> CONFIG_BACKLIGHT_CLASS_DEVICE=m
>> >>> CONFIG_DRM_I915=y
>> >>>
>> >>> Full randconfig file is attached.
>> >>
>> >> Can you please verify if you have:
>> >> 907aa265fde6589b8059dc51649c6d1f49ade2f3
>> >> ("drm/drm_panel: fix EXPORT of drm_panel_of_backlight")
>> >>
>> >> This commit is supposed to fix it.
>> >>
>> >> Sam
>> >>
>> >
>> > Hi Sam,
>> > I don't have the linux-next.git tree so I can't check that.
>> > I just built whatever is in linux-next of 20191216.
>> >
>>
>> 907aa265fde6589b8059dc51649c6d1f49ade2f3 ("drm/drm_panel: fix EXPORT of
>> drm_panel_of_backlight") is fixing drm_panel_of_backlight(), but the
>> error above is for backlight_device_register().
>>
>> From what I can tell, that commit is actually the cause of the error -
>> now intel_backlight_device_register() is being included in the kernel
>> even though it calls backlight_device_register() which is in a module.
>> Of course it also fixed the original error, so reverting it isn't any
>> use.
>>
>> The below Kconfig change fixes the build for me, but I've no idea
>> whether this is the correct fix.
>
> I think the proper one is to have s/IS_ENABLED/IS_REACHABLE/.
> It fixes issue for me.
As discussed off-line, this will allow silently building and linking a
configuration that's actually broken. (No backlight support despite
expectations.)
IMO deep down the problem is that we "select" BACKLIGHT_CLASS_DEVICE all
over the place, while we should "depends on" it. Everything else is just
duct tape that allows configurations where built-in code calls backlight
symbols in modules. It used to be more about an interaction with ACPI,
now we've added DRM_PANEL to the mix.
I've proposed a fix five years ago [1]. That's what it takes to fix
these recurring failures for good. I'm not really all that interested in
the whack-a-mole with the hacks.
BR,
Jani.
[1]
http://lore.kernel.org/r/1413580403-16225-1-git-send-email-jani.nik...@intel.com
--
Jani Nikula, Intel Open Source Graphics Center
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] backlight: corgi: Convert to use GPIO descriptors
On Mon, Dec 16, 2019 at 5:27 PM Lee Jones wrote:
> On Tue, 03 Dec 2019, Linus Walleij wrote:
>
> > The code in the Corgi backlight driver can be considerably
> > simplified by moving to GPIO descriptors and lookup tables
> > from the board files instead of passing GPIO numbers using
> > the old API.
> >
> > Make sure to encode inversion semantics for the Akita and
> > Spitz platforms inside the GPIO lookup table and drop the
> > custom inversion semantics from the driver.
> >
> > All in-tree users are converted in this patch.
> >
> > Cc: Andrea Adami
> > Cc: Robert Jarzmik
> > Signed-off-by: Linus Walleij
> > ---
> > arch/arm/mach-pxa/corgi.c | 12 -
> > arch/arm/mach-pxa/spitz.c | 34 +++
>
> Does this have an Arm Ack yet?
Yes Robert Jarzmik is the maintainer of arch/arm/mach-pxa,
or do you mean I should ask for the ARM SoC maintainers'
ACK explicitly (then I'd just resend, NP).
> > drivers/video/backlight/corgi_lcd.c | 68 -
> > include/linux/spi/corgi_lcd.h | 3 --
>
> What about SPI?
That include file should technically be in the backlight
include path or platform_data (yeah someone should
fix...) but let's ask Mark explicitly if this is OK.
Mark: the hunk hitting the include/linux/spi/corgi_lcd.h
file looks like this:
@@ -11,9 +11,6 @@ struct corgi_lcd_platform_data {
int default_intensity;
int limit_mask;
- int gpio_backlight_on; /* -1 if n/a */
- int gpio_backlight_cont;/* -1 if n/a */
-
void (*notify)(int intensity);
void (*kick_battery)(void);
};
OK with you? If you want I can resend the whole patch
as well so you can have a look.
Yours,
Linus Walleij
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v6] drm/mcde: Some fixes to handling video mode
The video DSI mode had not really been tested. These fixes makes
it more likely to work on real hardware:
- Put the active width (x width) in the right bits and the VSA
(vertical sync active) in the right bits (those were swapped).
- Calculate the packet sizes in bytes as in the vendor driver,
rather than in bits. Test the calculations agains a
spreadsheet and confirmed by debug prints to be reasonable.
- Also verified the register values with relative confidence
to register dumps from the Samsung GT-I8190 boot loader
graphics. We are not identical but not off by far either.
- Error out if the current mode and refresh frequency doesn't
work out. (In the future we may simply want to scale down
the vrefresh.)
- Handle negative result in front/back/sync packages and fall
back to zero like in the vendor driver.
- Put in lots of clarifying comments and references to the
documentation where the code is hard to understand.
- Set the DSI_VID_VCA_SETTING2 field
DSI_VID_VCA_SETTING2_MAX_LINE_LIMIT to blkline_pck - 6 as in
the vendor driver and mask the field properly.
- Set the DSI_VID_VCA_SETTING1 field
DSI_VID_VCA_SETTING1_MAX_BURST_LIMIT to blkeol_pck - 6 to
blkeol_duration - 6 as in the vendor driver.
Cc: Stephan Gerhold
Fixes: 5fc537bfd000 ("drm/mcde: Add new driver for ST-Ericsson MCDE")
Signed-off-by: Linus Walleij
---
ChangeLog v5->v6:
- DSI_VID_VCA_SETTING1_MAX_BURST_LIMIT should be blkeol_pck - 6
not blkeol_duration - 6.
- Parenthesize some calculations.
ChangeLog v4->v5:
- Restore log order, last verstion of the changelog inadvertedly
merged v3 and v4 into v3 since I thought I didn't send out v3...
- Parens in blkeol_pck = bpl - (mode->htotal * cpp) - 6 for
explicit priority.
- Use mask-and-set for DSI_VID_PCK_TIME and DSI_VID_VCA_SETTING1
- Restore DSI_VID_VCA_SETTING2 field
DSI_VID_VCA_SETTING2_MAX_LINE_LIMIT to blkline_pck - 6 as in
the vendor driver and mask the field properly.
ChangeLog v3->v4:
- Calculate toward actual HS rate of the clock rather than the
idealized rate provided by the panel resolution, this is what
the vendor driver does.
- Add much comments and elaborate with references to the manual
so the code can be understood as far as possible.
- Compared register dumps to that on the Samsung GT-I8190 (Golden)
boot loader settings. We are now reasonably close to these,
it may be that the boot loader driver is using slightly different
settings for porches and syncs etc. But all figures makes sense.
- Duplicated the vendor code in a spread sheet and compared to
what this code gives and we have an identical match with one
small exception that the vendor code adds a small padding of 2
lines to the vertical blanking area. This looks weird and might
be some hackishly specified porch.
ChangeLog v2->v3:
- Rename the "bpp" variable to "cpp" since it is "chars per pixel"
this was confusingly named in the vendor driver and it got
carried over.
- Assign the SETTING2_EXACT_BURST_LIMIT by first shifting
then masking.
- Also mask with the inverse of DSI_VID_BLKSIZE1_BLKEOL_PCK_MASK
before writing blkeol into DSI_VID_BLKSIZE1, so we make sure
to zero these bits first.
- Also mask with DSI_VID_BLKSIZE1_BLKLINE_EVENT_PCK_MASK
when writing event package length.
- Comb through the code and compare it to vendor code and try
to get closer to doing what the vendor driver is doing.
ChangeLog v1->v2:
- Fix some more comments so we understand what is going on.
- Set up the maximum line limit size in the right register
instead of setting it in the burst size register portion.
- Set some default wakeup time other than zero (still need
fixing more).
---
drivers/gpu/drm/mcde/mcde_dsi.c | 239 +--
drivers/gpu/drm/mcde/mcde_dsi_regs.h | 1 +
2 files changed, 192 insertions(+), 48 deletions(-)
diff --git a/drivers/gpu/drm/mcde/mcde_dsi.c b/drivers/gpu/drm/mcde/mcde_dsi.c
index 21cee4d9d2fd..6613c68c0633 100644
--- a/drivers/gpu/drm/mcde/mcde_dsi.c
+++ b/drivers/gpu/drm/mcde/mcde_dsi.c
@@ -379,13 +379,14 @@ void mcde_dsi_te_request(struct mipi_dsi_device *mdsi)
static void mcde_dsi_setup_video_mode(struct mcde_dsi *d,
const struct drm_display_mode *mode)
{
- u8 bpp = mipi_dsi_pixel_format_to_bpp(d->mdsi->format);
+ /* cpp, characters per pixel, number of bytes per pixel */
+ u8 cpp = mipi_dsi_pixel_format_to_bpp(d->mdsi->format) / 8;
+ u64 pclk;
u64 bpl;
- u32 hfp;
- u32 hbp;
- u32 hsa;
+ int hfp;
+ int hbp;
+ int hsa;
u32 blkline_pck, line_duration;
- u32 blkeol_pck, blkeol_duration;
u32 val;
val = 0;
@@ -422,11 +423,21 @@ static void mcde_dsi_setup_video_mode(struct mcde_dsi *d,
return;
}
- /* TODO: TVG could be enabled here */
+ /* TODO: TVG (test video generator) could be enabled here */
- /* Send blanking packet */
+ /*
+
Re: [PATCH v3 2/3] dt-bindings: display: panel: Add binding document for Xinpeng XPP055C272
Am Dienstag, 17. Dezember 2019, 15:24:46 CET schrieb Maxime Ripard:
> Hi,
>
> On Tue, Dec 17, 2019 at 03:07:02PM +0100, Heiko Stuebner wrote:
> > From: Heiko Stuebner
> >
> > The XPP055C272 is a 5.5" 720x1280 DSI display.
> >
> > changes in v2:
> > - add size info into binding title (Sam)
> > - add more required properties (Sam)
> >
> > Signed-off-by: Heiko Stuebner
> > Reviewed-by: Sam Ravnborg
> > ---
> > .../display/panel/xinpeng,xpp055c272.yaml | 48 +++
> > 1 file changed, 48 insertions(+)
> > create mode 100644
> > Documentation/devicetree/bindings/display/panel/xinpeng,xpp055c272.yaml
> >
> > diff --git
> > a/Documentation/devicetree/bindings/display/panel/xinpeng,xpp055c272.yaml
> > b/Documentation/devicetree/bindings/display/panel/xinpeng,xpp055c272.yaml
> > new file mode 100644
> > index ..2d0fc97d735c
> > --- /dev/null
> > +++
> > b/Documentation/devicetree/bindings/display/panel/xinpeng,xpp055c272.yaml
> > @@ -0,0 +1,48 @@
> > +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> > +%YAML 1.2
> > +---
> > +$id: http://devicetree.org/schemas/display/panel/sony,acx424akp.yaml#
>
> The ID doesn't match the file name.
>
> Did you run dt_bindings_check?
Thanks for that pointer ... I did run dtbs_check on the binding and was
sooo happy to not find any panel errors in the pages of other dt errors
but till now didn't realize that there's also a dtbinding_check.
Will keep that in mind for future bindings - and of course fix things
in the next version.
> > +$schema: http://devicetree.org/meta-schemas/core.yaml#
> > +
> > +title: Xinpeng XPP055C272 5.5in 720x1280 DSI panel
> > +
> > +maintainers:
> > + - Heiko Stuebner
> > +
> > +allOf:
> > + - $ref: panel-common.yaml#
> > +
> > +properties:
> > + compatible:
> > +const: xinpeng,xpp055c272
> > + reg: true
> > + backlight: true
> > + port: true
>
> What is the port supposed to be doing?
Hooking the display up to the dsi controller. But you're right,
works without port as well with these single-dsi displays.
I just remember needing one for the Gru-Scarlet display that needed
to connect to two dsi controllers.
So I'll drop the port node here and from my board devicetree.
Thanks for the review
Heiko
>
> > + reset-gpios: true
> > + iovcc-supply:
> > + description: regulator that supplies the iovcc voltage
> > + vci-supply:
> > + description: regulator that supplies the vci voltage
> > +
> > +required:
> > + - compatible
> > + - reg
> > + - backlight
> > + - iovcc-supply
> > + - vci-supply
> > +
> > +additionalProperties: false
> > +
> > +examples:
> > + - |
> > +dsi@ff45 {
> > +panel@0 {
> > +compatible = "xinpeng,xpp055c272";
> > +reg = <0>;
> > +backlight = <&backlight>;
> > +iovcc-supply = <&vcc_1v8>;
> > +vci-supply = <&vcc3v3_lcd>;
> > +};
> > +};
> > +
> > +...
>
> Thanks!
> Maxime
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v5] drm/mcde: Some fixes to handling video mode
On Tue, Dec 17, 2019 at 11:27 AM Stephan Gerhold wrote: > I feel kind of bad to keep requesting changes for this patch, Don't feel like that. It is complex hardware and complex code, so it leads to complex development. Also I am making way too many stupid mistakes :/ > > + val = readl(d->regs + DSI_VID_PCK_TIME); > > + val &= ~DSI_VID_PCK_TIME_BLKEOL_DURATION_MASK; > > + val |= blkeol_duration << > > + DSI_VID_PCK_TIME_BLKEOL_DURATION_SHIFT; > > + writel(val, d->regs + DSI_VID_PCK_TIME); > > + > > + /* Max burst limit, this is given in bytes */ > > + val = readl(d->regs + DSI_VID_VCA_SETTING1); > > + val &= ~DSI_VID_VCA_SETTING1_MAX_BURST_LIMIT_MASK; > > + val |= blkeol_duration - 6; > > The vendor kernel writes blkeol_pck - 6 (instead of blkeol_duration) here: > > dsi_wfld(io, DSI_VID_VCA_SETTING1, MAX_BURST_LIMIT, vid_regs->blkeol_pck - 6); You're right, and still I read the code over and over... It's good we have 2 pairs of eyes. > Also: It does not make a functional difference here but for clarity we > should shift the value by DSI_VID_VCA_SETTING1_MAX_BURST_LIMIT_SHIFT (= 0), > i.e. > > val |= blkeol_pck - 6 << DSI_VID_VCA_SETTING1_MAX_BURST_LIMIT_SHIFT; OK I fix! Yours, Linus Walleij ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCHv5 31/34] drm/arm/malidp: Factor in afbc framebuffer verification
Prepare for using generic afbc-aware helpers.
Signed-off-by: Andrzej Pietrasiewicz
---
drivers/gpu/drm/arm/malidp_drv.c | 142 +++
1 file changed, 68 insertions(+), 74 deletions(-)
diff --git a/drivers/gpu/drm/arm/malidp_drv.c b/drivers/gpu/drm/arm/malidp_drv.c
index e1502666bce0..b53fc01baf2b 100644
--- a/drivers/gpu/drm/arm/malidp_drv.c
+++ b/drivers/gpu/drm/arm/malidp_drv.c
@@ -269,94 +269,88 @@ static const struct drm_mode_config_helper_funcs
malidp_mode_config_helpers = {
.atomic_commit_tail = malidp_atomic_commit_tail,
};
-static bool
-malidp_verify_afbc_framebuffer(struct drm_device *dev, struct drm_file *file,
- const struct drm_mode_fb_cmd2 *mode_cmd)
+static struct drm_framebuffer *
+malidp_fb_create(struct drm_device *dev, struct drm_file *file,
+const struct drm_mode_fb_cmd2 *mode_cmd)
{
- int n_superblocks = 0;
- const struct drm_format_info *info;
- struct drm_gem_object *objs = NULL;
- u32 afbc_superblock_size = 0, afbc_superblock_height = 0;
- u32 afbc_superblock_width = 0, afbc_size = 0;
- int bpp = 0;
-
- if (malidp_format_mod_supported(dev, mode_cmd->pixel_format,
- mode_cmd->modifier[0]) == false)
- return false;
-
- if (mode_cmd->offsets[0] != 0) {
- DRM_DEBUG_KMS("AFBC buffers' plane offset should be 0\n");
- return false;
- }
+ if (mode_cmd->modifier[0]) {
+ int n_superblocks = 0;
+ const struct drm_format_info *info;
+ struct drm_gem_object *objs = NULL;
+ u32 afbc_superblock_size = 0, afbc_superblock_height = 0;
+ u32 afbc_superblock_width = 0, afbc_size = 0;
+ int bpp = 0;
+
+ if (malidp_format_mod_supported(dev, mode_cmd->pixel_format,
+ mode_cmd->modifier[0]) == false)
+ return ERR_PTR(-EINVAL);
- switch (mode_cmd->modifier[0] & AFBC_SIZE_MASK) {
- case AFBC_SIZE_16X16:
- if ((mode_cmd->width % 16) || (mode_cmd->height % 16)) {
- DRM_DEBUG_KMS("AFBC buffers must be aligned to 16
pixels\n");
- return false;
+ if (mode_cmd->offsets[0] != 0) {
+ DRM_DEBUG_KMS("AFBC buffers' plane offset should be
0\n");
+ return ERR_PTR(-EINVAL);
}
- break;
- default:
- DRM_DEBUG_KMS("Unsupported AFBC block size\n");
- return false;
- }
- switch (mode_cmd->modifier[0] & AFBC_SIZE_MASK) {
- case AFBC_SIZE_16X16:
- afbc_superblock_height = 16;
- afbc_superblock_width = 16;
- break;
- default:
- DRM_DEBUG_KMS("AFBC superblock size is not supported\n");
- return false;
- }
+ switch (mode_cmd->modifier[0] & AFBC_SIZE_MASK) {
+ case AFBC_SIZE_16X16:
+ if ((mode_cmd->width % 16) || (mode_cmd->height % 16)) {
+ DRM_DEBUG_KMS("AFBC buffers must be aligned to
16 pixels\n");
+ return ERR_PTR(-EINVAL);
+ }
+ break;
+ default:
+ DRM_DEBUG_KMS("Unsupported AFBC block size\n");
+ return ERR_PTR(-EINVAL);
+ }
- info = drm_get_format_info(dev, mode_cmd);
+ switch (mode_cmd->modifier[0] & AFBC_SIZE_MASK) {
+ case AFBC_SIZE_16X16:
+ afbc_superblock_height = 16;
+ afbc_superblock_width = 16;
+ break;
+ default:
+ DRM_DEBUG_KMS("AFBC superblock size is not
supported\n");
+ return ERR_PTR(-EINVAL);
+ }
- n_superblocks = (mode_cmd->width / afbc_superblock_width) *
- (mode_cmd->height / afbc_superblock_height);
+ info = drm_get_format_info(dev, mode_cmd);
- bpp = malidp_format_get_bpp(info->format);
+ n_superblocks = (mode_cmd->width / afbc_superblock_width) *
+ (mode_cmd->height / afbc_superblock_height);
- afbc_superblock_size = (bpp * afbc_superblock_width *
afbc_superblock_height)
- / BITS_PER_BYTE;
+ bpp = malidp_format_get_bpp(info->format);
- afbc_size = ALIGN(n_superblocks * AFBC_HEADER_SIZE,
AFBC_SUPERBLK_ALIGNMENT);
- afbc_size += n_superblocks * ALIGN(afbc_superblock_size,
AFBC_SUPERBLK_ALIGNMENT);
+ afbc_superblock_size =
+ (bpp * afbc_superblock_width * afbc_superblock_height)
+ / BITS_PER_BYTE;
- if ((mode_cmd->width * bpp
[PATCHv5 32/34] drm/arm/malidp: Use generic helpers for afbc checks
Helpers are now available for checking afbc buffer properties. Use those.
Signed-off-by: Andrzej Pietrasiewicz
---
drivers/gpu/drm/arm/malidp_drv.c | 71 ++--
1 file changed, 30 insertions(+), 41 deletions(-)
diff --git a/drivers/gpu/drm/arm/malidp_drv.c b/drivers/gpu/drm/arm/malidp_drv.c
index b53fc01baf2b..4cbd920b48cd 100644
--- a/drivers/gpu/drm/arm/malidp_drv.c
+++ b/drivers/gpu/drm/arm/malidp_drv.c
@@ -273,12 +273,17 @@ static struct drm_framebuffer *
malidp_fb_create(struct drm_device *dev, struct drm_file *file,
const struct drm_mode_fb_cmd2 *mode_cmd)
{
+ struct drm_size_check check = { 0 };
+ struct drm_gem_object *objs[4];
+ struct drm_afbc_framebuffer *afbc_fb;
+ int ret, i, num_planes;
+
+ afbc_fb = kzalloc(sizeof(*afbc_fb), GFP_KERNEL);
+ if (!afbc_fb)
+ return ERR_PTR(-ENOMEM);
+
if (mode_cmd->modifier[0]) {
- int n_superblocks = 0;
const struct drm_format_info *info;
- struct drm_gem_object *objs = NULL;
- u32 afbc_superblock_size = 0, afbc_superblock_height = 0;
- u32 afbc_superblock_width = 0, afbc_size = 0;
int bpp = 0;
if (malidp_format_mod_supported(dev, mode_cmd->pixel_format,
@@ -302,32 +307,9 @@ malidp_fb_create(struct drm_device *dev, struct drm_file
*file,
return ERR_PTR(-EINVAL);
}
- switch (mode_cmd->modifier[0] & AFBC_SIZE_MASK) {
- case AFBC_SIZE_16X16:
- afbc_superblock_height = 16;
- afbc_superblock_width = 16;
- break;
- default:
- DRM_DEBUG_KMS("AFBC superblock size is not
supported\n");
- return ERR_PTR(-EINVAL);
- }
-
info = drm_get_format_info(dev, mode_cmd);
-
- n_superblocks = (mode_cmd->width / afbc_superblock_width) *
- (mode_cmd->height / afbc_superblock_height);
-
bpp = malidp_format_get_bpp(info->format);
- afbc_superblock_size =
- (bpp * afbc_superblock_width * afbc_superblock_height)
- / BITS_PER_BYTE;
-
- afbc_size = ALIGN(n_superblocks * AFBC_HEADER_SIZE,
- AFBC_SUPERBLK_ALIGNMENT);
- afbc_size += n_superblocks
- * ALIGN(afbc_superblock_size, AFBC_SUPERBLK_ALIGNMENT);
-
if ((mode_cmd->width * bpp) !=
(mode_cmd->pitches[0] * BITS_PER_BYTE)) {
DRM_DEBUG_KMS("Invalid value of (pitch * BITS_PER_BYTE)
(=%u) "
@@ -336,24 +318,31 @@ malidp_fb_create(struct drm_device *dev, struct drm_file
*file,
mode_cmd->width, bpp);
return ERR_PTR(-EINVAL);
}
+ afbc_fb->bpp = bpp;
+ check.data = afbc_fb;
+ }
- objs = drm_gem_object_lookup(file, mode_cmd->handles[0]);
- if (!objs) {
- DRM_DEBUG_KMS("Failed to lookup GEM object\n");
- return ERR_PTR(-EINVAL);
- }
+ ret = drm_gem_fb_lookup(dev, file, mode_cmd, objs);
+ if (ret < 0)
+ goto err_free;
+ num_planes = ret;
- if (objs->size < afbc_size) {
- DRM_DEBUG_KMS("buffer size (%zu) too small for AFBC
buffer size = %u\n",
- objs->size, afbc_size);
- drm_gem_object_put_unlocked(objs);
- return ERR_PTR(-EINVAL);
- }
+ ret = drm_gem_fb_size_check2(dev, mode_cmd, &check, objs);
+ if (ret < 0)
+ goto err_cleanup;
- drm_gem_object_put_unlocked(objs);
- }
+ ret = drm_gem_fb_init(&afbc_fb->base, dev, mode_cmd, objs, num_planes);
+ if (ret < 0)
+ goto err_cleanup;
+
+ return &afbc_fb->base;
- return drm_gem_fb_create(dev, file, mode_cmd);
+err_cleanup:
+ for (i = 0; i < num_planes; ++i)
+ drm_gem_object_put_unlocked(objs[i]);
+err_free:
+ kfree(afbc_fb);
+ return ERR_PTR(ret);
}
static const struct drm_mode_config_funcs malidp_mode_config_funcs = {
--
2.17.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCHv5 33/34] drm/rockchip: Use helper for common task
Use generic helper code.
Signed-off-by: Andrzej Pietrasiewicz
---
drivers/gpu/drm/rockchip/rockchip_drm_fb.c | 12 ++--
1 file changed, 2 insertions(+), 10 deletions(-)
diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_fb.c
b/drivers/gpu/drm/rockchip/rockchip_drm_fb.c
index 221e72e71432..5806f908aa53 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_fb.c
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_fb.c
@@ -18,6 +18,7 @@
#include "rockchip_drm_fb.h"
#include "rockchip_drm_gem.h"
+
static const struct drm_framebuffer_funcs rockchip_drm_fb_funcs = {
.destroy = drm_gem_fb_destroy,
.create_handle = drm_gem_fb_create_handle,
@@ -30,22 +31,13 @@ rockchip_fb_alloc(struct drm_device *dev, const struct
drm_mode_fb_cmd2 *mode_cm
{
struct drm_framebuffer *fb;
int ret;
- int i;
fb = kzalloc(sizeof(*fb), GFP_KERNEL);
if (!fb)
return ERR_PTR(-ENOMEM);
- drm_helper_mode_fill_fb_struct(dev, fb, mode_cmd);
-
- for (i = 0; i < num_planes; i++)
- fb->obj[i] = obj[i];
-
- ret = drm_framebuffer_init(dev, fb, &rockchip_drm_fb_funcs);
+ ret = drm_gem_fb_init_with_funcs(fb, dev, mode_cmd, obj, num_planes,
&rockchip_drm_fb_funcs);
if (ret) {
- DRM_DEV_ERROR(dev->dev,
- "Failed to initialize framebuffer: %d\n",
- ret);
kfree(fb);
return ERR_PTR(ret);
}
--
2.17.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCHv5 20/34] drm/komeda: Move helper invocation to after size checks
Between the old and new place nothing depends on data retrieved with the
helper, so it is safe to move its invocation.
The err_cleanup case is changed accordingly.
Signed-off-by: Andrzej Pietrasiewicz
---
drivers/gpu/drm/arm/display/komeda/komeda_framebuffer.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/arm/display/komeda/komeda_framebuffer.c
b/drivers/gpu/drm/arm/display/komeda/komeda_framebuffer.c
index 42ccd4647919..c2b29d4e6fbb 100644
--- a/drivers/gpu/drm/arm/display/komeda/komeda_framebuffer.c
+++ b/drivers/gpu/drm/arm/display/komeda/komeda_framebuffer.c
@@ -154,7 +154,6 @@ komeda_fb_create(struct drm_device *dev, struct drm_file
*file,
if (ret < 0)
goto err_free;
- drm_helper_mode_fill_fb_struct(dev, &kfb->base, mode_cmd);
info = drm_get_format_info(dev, mode_cmd);
if (mode_cmd->modifier[0]) {
@@ -185,6 +184,8 @@ komeda_fb_create(struct drm_device *dev, struct drm_file
*file,
goto err_cleanup;
}
+ drm_helper_mode_fill_fb_struct(dev, &kfb->base, mode_cmd);
+
for (i = 0; i < info->num_planes; ++i)
kfb->base.obj[i] = objs[i];
@@ -200,7 +201,7 @@ komeda_fb_create(struct drm_device *dev, struct drm_file
*file,
return &kfb->base;
err_cleanup:
- for (i = 0; i < kfb->base.format->num_planes; i++)
+ for (i = 0; i < info->num_planes; i++)
drm_gem_object_put_unlocked(objs[i]);
err_free:
kfree(kfb);
--
2.17.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCHv5 01/34] drm/core: Add afbc helper functions
Add checking if a modifier is afbc and getting afbc block size.
Signed-off-by: Andrzej Pietrasiewicz
---
drivers/gpu/drm/drm_fourcc.c | 53
include/drm/drm_fourcc.h | 4 +++
2 files changed, 57 insertions(+)
diff --git a/drivers/gpu/drm/drm_fourcc.c b/drivers/gpu/drm/drm_fourcc.c
index b234bfaeda06..d14dd7c86020 100644
--- a/drivers/gpu/drm/drm_fourcc.c
+++ b/drivers/gpu/drm/drm_fourcc.c
@@ -29,6 +29,7 @@
#include
#include
+#include
static char printable_char(int c)
{
@@ -393,3 +394,55 @@ uint64_t drm_format_info_min_pitch(const struct
drm_format_info *info,
drm_format_info_block_height(info, plane));
}
EXPORT_SYMBOL(drm_format_info_min_pitch);
+
+/**
+ * drm_is_afbc - test if the modifier describes an afbc buffer
+ * @modifier - modifier to be tested
+ *
+ * Returns: true if the modifier describes an afbc buffer
+ */
+bool drm_is_afbc(u64 modifier)
+{
+ /* is it ARM AFBC? */
+ if ((modifier & DRM_FORMAT_MOD_ARM_AFBC(0)) == 0)
+ return false;
+
+ /* Block size must be known */
+ if ((modifier & AFBC_FORMAT_MOD_BLOCK_SIZE_MASK) == 0)
+ return false;
+
+ return true;
+}
+EXPORT_SYMBOL_GPL(drm_is_afbc);
+
+/**
+ * drm_afbc_get_superblock_wh - extract afbc block width/height from modifier
+ * @modifier: the modifier to be looked at
+ * @w: address of a place to store the block width
+ * @h: address of a place to store the block height
+ *
+ * Returns: true if the modifier describes a supported block size
+ */
+bool drm_afbc_get_superblock_wh(u64 modifier, u32 *w, u32 *h)
+{
+ switch (modifier & AFBC_FORMAT_MOD_BLOCK_SIZE_MASK) {
+ case AFBC_FORMAT_MOD_BLOCK_SIZE_16x16:
+ *w = 16;
+ *h = 16;
+ break;
+ case AFBC_FORMAT_MOD_BLOCK_SIZE_32x8:
+ *w = 32;
+ *h = 8;
+ break;
+ case AFBC_FORMAT_MOD_BLOCK_SIZE_64x4:
+ /* fall through */
+ case AFBC_FORMAT_MOD_BLOCK_SIZE_32x8_64x4:
+ /* fall through */
+ default:
+ DRM_DEBUG_KMS("Invalid AFBC_FORMAT_MOD_BLOCK_SIZE: %lld.\n",
+ modifier & AFBC_FORMAT_MOD_BLOCK_SIZE_MASK);
+ return false;
+ }
+ return true;
+}
+EXPORT_SYMBOL_GPL(drm_afbc_get_superblock_wh);
diff --git a/include/drm/drm_fourcc.h b/include/drm/drm_fourcc.h
index 306d1efeb5e0..7eb23062bf45 100644
--- a/include/drm/drm_fourcc.h
+++ b/include/drm/drm_fourcc.h
@@ -320,4 +320,8 @@ uint64_t drm_format_info_min_pitch(const struct
drm_format_info *info,
int plane, unsigned int buffer_width);
const char *drm_get_format_name(uint32_t format, struct drm_format_name_buf
*buf);
+bool drm_is_afbc(u64 modifier);
+
+bool drm_afbc_get_superblock_wh(u64 modifier, u32 *w, u32 *h);
+
#endif /* __DRM_FOURCC_H__ */
--
2.17.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCHv5 27/34] drm/komeda: Move special helper invocation outside if-else
The invocation is the same in both cases and is the last thing inside a
block, so move it outside the if-else clause.
Signed-off-by: Andrzej Pietrasiewicz
---
.../gpu/drm/arm/display/komeda/komeda_framebuffer.c| 10 +++---
1 file changed, 3 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/arm/display/komeda/komeda_framebuffer.c
b/drivers/gpu/drm/arm/display/komeda/komeda_framebuffer.c
index 7e02a04cdd11..bf4309b62d37 100644
--- a/drivers/gpu/drm/arm/display/komeda/komeda_framebuffer.c
+++ b/drivers/gpu/drm/arm/display/komeda/komeda_framebuffer.c
@@ -44,6 +44,8 @@ komeda_fb_create(struct drm_device *dev, struct drm_file
*file,
struct drm_gem_object *objs[4];
struct komeda_fb *kfb;
const struct drm_format_info *info;
+ struct drm_size_check check = { 0 };
+
int ret = 0, i, num_planes;
kfb = kzalloc(sizeof(*kfb), GFP_KERNEL);
@@ -68,7 +70,6 @@ komeda_fb_create(struct drm_device *dev, struct drm_file
*file,
info = drm_get_format_info(dev, mode_cmd);
if (mode_cmd->modifier[0]) {
- struct drm_size_check check = { 0 };
u32 alignment_w = 0, alignment_h = 0;
u32 alignment_header, n_blocks, bpp;
@@ -109,11 +110,7 @@ komeda_fb_create(struct drm_device *dev, struct drm_file
*file,
+ n_blocks * ALIGN(bpp * AFBC_SUPERBLK_PIXELS /
8, AFBC_SUPERBLK_ALIGNMENT);
check.min_size[0] = kfb->afbc_size + mode_cmd->offsets[0];
check.use_min_size = true;
-
- ret = drm_gem_fb_size_check2(dev, mode_cmd, &check, objs);
} else {
- struct drm_size_check check = { 0 };
-
ret = komeda_fb_check_src_coords(kfb, 0, 0, mode_cmd->width,
mode_cmd->height);
if (ret)
@@ -135,9 +132,8 @@ komeda_fb_create(struct drm_device *dev, struct drm_file
*file,
check.pitch_modulo = mdev->chip.bus_width;
check.use_pitch_multiplier = true;
check.use_min_size = true;
-
- ret = drm_gem_fb_size_check2(dev, mode_cmd, &check, objs);
}
+ ret = drm_gem_fb_size_check2(dev, mode_cmd, &check, objs);
if (ret < 0)
goto err_cleanup;
--
2.17.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCHv5 34/34] drm/rockchip: Add support for afbc
This patch adds support for afbc handling. afbc is a compressed format
which reduces the necessary memory bandwidth.
Co-developed-by: Mark Yao
Signed-off-by: Mark Yao
Signed-off-by: Andrzej Pietrasiewicz
# Conflicts:
# drivers/gpu/drm/rockchip/rockchip_drm_fb.c
---
drivers/gpu/drm/rockchip/rockchip_drm_fb.c | 105 +-
drivers/gpu/drm/rockchip/rockchip_drm_vop.c | 147 ++--
drivers/gpu/drm/rockchip/rockchip_drm_vop.h | 12 ++
drivers/gpu/drm/rockchip/rockchip_vop_reg.c | 83 ++-
4 files changed, 329 insertions(+), 18 deletions(-)
diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_fb.c
b/drivers/gpu/drm/rockchip/rockchip_drm_fb.c
index 5806f908aa53..f26cbaa46135 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_fb.c
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_fb.c
@@ -18,6 +18,7 @@
#include "rockchip_drm_fb.h"
#include "rockchip_drm_gem.h"
+#define ROCKCHIP_MAX_AFBC_WIDTH2560
static const struct drm_framebuffer_funcs rockchip_drm_fb_funcs = {
.destroy = drm_gem_fb_destroy,
@@ -25,32 +26,122 @@ static const struct drm_framebuffer_funcs
rockchip_drm_fb_funcs = {
.dirty = drm_atomic_helper_dirtyfb,
};
+static int rockchip_afbc_post_check(struct drm_afbc_framebuffer *afbc_fb)
+{
+ if (afbc_fb->offset) {
+ DRM_WARN("AFBC plane offset must be zero!\n");
+ return -EINVAL;
+ }
+
+ if (afbc_fb->block_width != 16 || afbc_fb->block_height != 16) {
+ DRM_WARN("Unsupported AFBC block w/h [%d/%d]\n",
afbc_fb->block_width, afbc_fb->block_height);
+ return -EINVAL;
+ }
+
+ if (afbc_fb->aligned_width > ROCKCHIP_MAX_AFBC_WIDTH) {
+ DRM_WARN("Unsupported width %d>%d\n", afbc_fb->aligned_width,
ROCKCHIP_MAX_AFBC_WIDTH);
+ return -EINVAL;
+ }
+
+ return 0;
+}
+
static struct drm_framebuffer *
rockchip_fb_alloc(struct drm_device *dev, const struct drm_mode_fb_cmd2
*mode_cmd,
struct drm_gem_object **obj, unsigned int num_planes)
{
- struct drm_framebuffer *fb;
+ struct drm_afbc_framebuffer *afbc_fb;
+ struct drm_size_check check = { 0 };
int ret;
- fb = kzalloc(sizeof(*fb), GFP_KERNEL);
- if (!fb)
+ afbc_fb = kzalloc(sizeof(*afbc_fb), GFP_KERNEL);
+ if (!afbc_fb)
return ERR_PTR(-ENOMEM);
- ret = drm_gem_fb_init_with_funcs(fb, dev, mode_cmd, obj, num_planes,
&rockchip_drm_fb_funcs);
+ if (drm_is_afbc(mode_cmd->modifier[0])) {
+ const struct drm_format_info *info = drm_get_format_info(dev,
mode_cmd);
+
+ afbc_fb->bpp = info->cpp[0] * 8;
+ check.data = afbc_fb;
+ }
+
+ ret = drm_gem_fb_size_check2(dev, mode_cmd, &check, obj);
if (ret) {
- kfree(fb);
+ kfree(afbc_fb);
return ERR_PTR(ret);
}
- return fb;
+ if (drm_is_afbc(mode_cmd->modifier[0]))
+ if (rockchip_afbc_post_check(afbc_fb)) {
+ kfree(afbc_fb);
+ return ERR_PTR(-EINVAL);
+ }
+
+ ret = drm_gem_fb_init_with_funcs(&afbc_fb->base, dev, mode_cmd, obj,
num_planes, &rockchip_drm_fb_funcs);
+ if (ret) {
+ kfree(afbc_fb);
+ return ERR_PTR(ret);
+ }
+
+ return &afbc_fb->base;
}
static const struct drm_mode_config_helper_funcs rockchip_mode_config_helpers
= {
.atomic_commit_tail = drm_atomic_helper_commit_tail_rpm,
};
+
+static struct drm_framebuffer *
+rockchip_fb_create(struct drm_device *dev, struct drm_file *file,
+ const struct drm_mode_fb_cmd2 *mode_cmd)
+{
+ struct drm_afbc_framebuffer *afbc_fb;
+ struct drm_size_check check = { 0 };
+ struct drm_gem_object *objs[4];
+ int ret, i, num_planes;
+
+ afbc_fb = kzalloc(sizeof(*afbc_fb), GFP_KERNEL);
+ if (!afbc_fb)
+ return ERR_PTR(-ENOMEM);
+
+ if (drm_is_afbc(mode_cmd->modifier[0])) {
+ const struct drm_format_info *info = drm_get_format_info(dev,
mode_cmd);
+
+ afbc_fb->bpp = info->cpp[0] * 8;
+ check.data = afbc_fb;
+ }
+
+ ret = drm_gem_fb_lookup(dev, file, mode_cmd, objs);
+ if (ret < 0)
+ goto err_free;
+ num_planes = ret;
+
+ ret = drm_gem_fb_size_check2(dev, mode_cmd, &check, objs);
+ if (ret)
+ goto err_cleanup;
+
+ if (drm_is_afbc(mode_cmd->modifier[0]))
+ if (rockchip_afbc_post_check(afbc_fb)) {
+ ret = -EINVAL;
+ goto err_cleanup;
+ }
+
+ ret = drm_gem_fb_init_with_funcs(&afbc_fb->base, dev, mode_cmd, objs,
num_planes, &rockchip_drm_fb_funcs);
+ if (ret)
+ goto err_cleanup;
+
+ return &afbc_fb->base;
+
+err_cleanup:
+ for (i = 0; i < nu
[PATCHv5 18/34] drm/komeda: Move object assignments to framebuffer to after size checks
The assignments are the same in both branches of the "if" statement and
nothing depends on them between their original position and the new
position, so this can be safely done.
Signed-off-by: Andrzej Pietrasiewicz
---
drivers/gpu/drm/arm/display/komeda/komeda_framebuffer.c | 7 +++
1 file changed, 3 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/arm/display/komeda/komeda_framebuffer.c
b/drivers/gpu/drm/arm/display/komeda/komeda_framebuffer.c
index acffceeb26f1..d52278ca27fb 100644
--- a/drivers/gpu/drm/arm/display/komeda/komeda_framebuffer.c
+++ b/drivers/gpu/drm/arm/display/komeda/komeda_framebuffer.c
@@ -166,8 +166,6 @@ komeda_fb_create(struct drm_device *dev, struct drm_file
*file,
ret = komeda_fb_afbc_size_check(kfb, info, objs, file,
mode_cmd);
- for (i = 0; i < info->num_planes; ++i)
- kfb->base.obj[i] = objs[i];
} else {
ret = komeda_fb_check_src_coords(kfb, 0, 0, kfb->base.width,
kfb->base.height);
@@ -176,8 +174,6 @@ komeda_fb_create(struct drm_device *dev, struct drm_file
*file,
ret = komeda_fb_none_afbc_size_check(mdev, info, objs,
file, mode_cmd);
- for (i = 0; i < info->num_planes; ++i)
- kfb->base.obj[i] = objs[i];
}
if (ret < 0)
goto err_cleanup;
@@ -189,6 +185,9 @@ komeda_fb_create(struct drm_device *dev, struct drm_file
*file,
goto err_cleanup;
}
+ for (i = 0; i < info->num_planes; ++i)
+ kfb->base.obj[i] = objs[i];
+
ret = drm_framebuffer_init(dev, &kfb->base, &komeda_fb_funcs);
if (ret < 0) {
DRM_DEBUG_KMS("failed to initialize fb\n");
--
2.17.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCHv5 12/34] drm/komeda: Factor out object lookups for non-afbc case
Ultimately we want lookups happening only once in komeda's fb_create
implementation.
Signed-off-by: Andrzej Pietrasiewicz
---
.../arm/display/komeda/komeda_framebuffer.c | 21 ---
1 file changed, 13 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/arm/display/komeda/komeda_framebuffer.c
b/drivers/gpu/drm/arm/display/komeda/komeda_framebuffer.c
index 08f31478c6a8..2014cd843aeb 100644
--- a/drivers/gpu/drm/arm/display/komeda/komeda_framebuffer.c
+++ b/drivers/gpu/drm/arm/display/komeda/komeda_framebuffer.c
@@ -100,6 +100,7 @@ static int
komeda_fb_none_afbc_size_check(struct komeda_dev *mdev,
struct komeda_fb *kfb,
const struct drm_format_info *info,
+ struct drm_gem_object **objs,
struct drm_file *file,
const struct drm_mode_fb_cmd2 *mode_cmd)
{
@@ -109,12 +110,7 @@ komeda_fb_none_afbc_size_check(struct komeda_dev *mdev,
u64 min_size;
for (i = 0; i < info->num_planes; i++) {
- obj = drm_gem_object_lookup(file, mode_cmd->handles[i]);
- if (!obj) {
- DRM_DEBUG_KMS("Failed to lookup GEM object\n");
- return -ENOENT;
- }
- fb->obj[i] = obj;
+ obj = objs[i];
block_h = drm_format_info_block_height(info, i);
if ((fb->pitches[i] * block_h) % mdev->chip.bus_width) {
@@ -174,14 +170,23 @@ komeda_fb_create(struct drm_device *dev, struct drm_file
*file,
}
ret = komeda_fb_afbc_size_check(kfb, info, file, mode_cmd);
} else {
+ struct drm_gem_object *objs[4];
+
if (komeda_fb_check_src_coords(kfb, 0, 0, kfb->base.width,
kfb->base.height)) {
kfree(kfb);
return ERR_PTR(-EINVAL);
}
+ ret = drm_gem_fb_lookup(dev, file, mode_cmd, objs);
+ if (ret < 0) {
+ kfree(kfb);
+ return ERR_PTR(ret);
+ }
- ret = komeda_fb_none_afbc_size_check(mdev, kfb, info, file,
-mode_cmd);
+ ret = komeda_fb_none_afbc_size_check(mdev, kfb, info, objs,
+file, mode_cmd);
+ for (i = 0; i < info->num_planes; ++i)
+ kfb->base.obj[i] = objs[i];
}
if (ret < 0)
goto err_cleanup;
--
2.17.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCHv5 24/34] drm/komeda: Factor in the invocation of special helper
Don't use a separate function to call the helper. The ultimate goal is
to unify non-afbc and afbc cases as much as possible and then moving the
helper invocation outside the if-else clause.
Signed-off-by: Andrzej Pietrasiewicz
---
.../arm/display/komeda/komeda_framebuffer.c | 57 +++
1 file changed, 20 insertions(+), 37 deletions(-)
diff --git a/drivers/gpu/drm/arm/display/komeda/komeda_framebuffer.c
b/drivers/gpu/drm/arm/display/komeda/komeda_framebuffer.c
index d75176e24f24..766b6944c53c 100644
--- a/drivers/gpu/drm/arm/display/komeda/komeda_framebuffer.c
+++ b/drivers/gpu/drm/arm/display/komeda/komeda_framebuffer.c
@@ -87,41 +87,6 @@ komeda_fb_afbc_size_check(struct komeda_fb *kfb,
return 0;
}
-static int
-komeda_fb_none_afbc_size_check(struct drm_device *dev,
- const struct drm_format_info *info,
- struct drm_gem_object **objs,
- struct drm_file *file,
- const struct drm_mode_fb_cmd2 *mode_cmd)
-{
- struct komeda_dev *mdev = dev->dev_private;
- struct drm_size_check check = { 0 };
- struct drm_gem_object *obj;
- u32 i;
-
- for (i = 0; i < info->num_planes; i++) {
- obj = objs[i];
-
- check.pitch_multiplier[i] =
- drm_format_info_block_height(info, i);
-
- check.min_size[i] =
- komeda_fb_get_pixel_addr_nofb(info,
- mode_cmd->modifier[0],
- mode_cmd->pitches,
- mode_cmd->offsets,
- obj,
- 0, mode_cmd->height, i)
- - to_drm_gem_cma_obj(obj)->paddr;
- }
-
- check.pitch_modulo = mdev->chip.bus_width;
- check.use_pitch_multiplier = true;
- check.use_min_size = true;
-
- return drm_gem_fb_size_check2(dev, mode_cmd, &check, objs);
-}
-
struct drm_framebuffer *
komeda_fb_create(struct drm_device *dev, struct drm_file *file,
const struct drm_mode_fb_cmd2 *mode_cmd)
@@ -163,13 +128,31 @@ komeda_fb_create(struct drm_device *dev, struct drm_file
*file,
ret = komeda_fb_afbc_size_check(kfb, info, objs, file,
mode_cmd);
} else {
+ struct drm_size_check check = { 0 };
+
ret = komeda_fb_check_src_coords(kfb, 0, 0, mode_cmd->width,
mode_cmd->height);
if (ret)
goto err_cleanup;
- ret = komeda_fb_none_afbc_size_check(dev, info, objs,
-file, mode_cmd);
+ for (i = 0; i < num_planes; i++) {
+ check.pitch_multiplier[i] =
+ drm_format_info_block_height(info, i);
+
+ check.min_size[i] =
+ komeda_fb_get_pixel_addr_nofb(info,
+ mode_cmd->modifier[0],
+ mode_cmd->pitches,
+ mode_cmd->offsets, objs[i],
+ 0, mode_cmd->height, i)
+ - to_drm_gem_cma_obj(objs[i])->paddr;
+ }
+
+ check.pitch_modulo = mdev->chip.bus_width;
+ check.use_pitch_multiplier = true;
+ check.use_min_size = true;
+
+ ret = drm_gem_fb_size_check2(dev, mode_cmd, &check, objs);
}
if (ret < 0)
goto err_cleanup;
--
2.17.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCHv5 21/34] drm/komeda: Use helper for common tasks
The replaced fragment is 1:1 with the helper code.
Signed-off-by: Andrzej Pietrasiewicz
---
.../gpu/drm/arm/display/komeda/komeda_framebuffer.c | 13 +++--
1 file changed, 3 insertions(+), 10 deletions(-)
diff --git a/drivers/gpu/drm/arm/display/komeda/komeda_framebuffer.c
b/drivers/gpu/drm/arm/display/komeda/komeda_framebuffer.c
index c2b29d4e6fbb..26d1a3cfb587 100644
--- a/drivers/gpu/drm/arm/display/komeda/komeda_framebuffer.c
+++ b/drivers/gpu/drm/arm/display/komeda/komeda_framebuffer.c
@@ -184,17 +184,10 @@ komeda_fb_create(struct drm_device *dev, struct drm_file
*file,
goto err_cleanup;
}
- drm_helper_mode_fill_fb_struct(dev, &kfb->base, mode_cmd);
-
- for (i = 0; i < info->num_planes; ++i)
- kfb->base.obj[i] = objs[i];
-
- ret = drm_framebuffer_init(dev, &kfb->base, &komeda_fb_funcs);
- if (ret < 0) {
- DRM_DEBUG_KMS("failed to initialize fb\n");
-
+ ret = drm_gem_fb_init_with_funcs(&kfb->base, dev, mode_cmd, objs,
+info->num_planes, &komeda_fb_funcs);
+ if (ret < 0)
goto err_cleanup;
- }
kfb->is_va = mdev->iommu ? true : false;
--
2.17.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCHv5 28/34] drm/komeda: Move to helper checking afbc buffer size
Use generic helper code. Adapt struct komeda_fb users to new location
of respective data members.
Signed-off-by: Andrzej Pietrasiewicz
---
.../arm/display/komeda/d71/d71_component.c| 6 +--
.../arm/display/komeda/komeda_framebuffer.c | 44 +--
.../arm/display/komeda/komeda_framebuffer.h | 14 ++
.../display/komeda/komeda_pipeline_state.c| 14 +++---
4 files changed, 26 insertions(+), 52 deletions(-)
diff --git a/drivers/gpu/drm/arm/display/komeda/d71/d71_component.c
b/drivers/gpu/drm/arm/display/komeda/d71/d71_component.c
index 8a02ade369db..5131e51e56d4 100644
--- a/drivers/gpu/drm/arm/display/komeda/d71/d71_component.c
+++ b/drivers/gpu/drm/arm/display/komeda/d71/d71_component.c
@@ -186,7 +186,7 @@ static void d71_layer_update_fb(struct komeda_component *c,
struct komeda_fb *kfb,
dma_addr_t *addr)
{
- struct drm_framebuffer *fb = &kfb->base;
+ struct drm_framebuffer *fb = &kfb->base.base;
const struct drm_format_info *info = fb->format;
u32 __iomem *reg = c->reg;
int block_h;
@@ -234,9 +234,9 @@ static void d71_layer_update(struct komeda_component *c,
st->afbc_crop_b));
/* afbc 1.2 wants payload, afbc 1.0/1.1 wants end_addr */
if (fb->modifier & AFBC_FORMAT_MOD_TILED)
- addr = st->addr[0] + kfb->offset_payload;
+ addr = st->addr[0] + kfb->base.offset_payload;
else
- addr = st->addr[0] + kfb->afbc_size - 1;
+ addr = st->addr[0] + kfb->base.afbc_size - 1;
malidp_write32(reg, BLK_P1_PTR_LOW, lower_32_bits(addr));
malidp_write32(reg, BLK_P1_PTR_HIGH, upper_32_bits(addr));
diff --git a/drivers/gpu/drm/arm/display/komeda/komeda_framebuffer.c
b/drivers/gpu/drm/arm/display/komeda/komeda_framebuffer.c
index bf4309b62d37..45318ed052a9 100644
--- a/drivers/gpu/drm/arm/display/komeda/komeda_framebuffer.c
+++ b/drivers/gpu/drm/arm/display/komeda/komeda_framebuffer.c
@@ -70,46 +70,26 @@ komeda_fb_create(struct drm_device *dev, struct drm_file
*file,
info = drm_get_format_info(dev, mode_cmd);
if (mode_cmd->modifier[0]) {
- u32 alignment_w = 0, alignment_h = 0;
- u32 alignment_header, n_blocks, bpp;
-
if (num_planes != 1) {
DRM_DEBUG_KMS("AFBC requires exactly 1 plane.\n");
ret = -EINVAL;
goto err_cleanup;
}
- if (!drm_afbc_get_superblock_wh(mode_cmd->modifier[0],
&alignment_w, &alignment_h)) {
- ret = -EINVAL;
- goto err_cleanup;
- }
-
/* tiled header afbc */
- if (mode_cmd->modifier[0] & AFBC_FORMAT_MOD_TILED) {
- alignment_w *= AFBC_TH_LAYOUT_ALIGNMENT;
- alignment_h *= AFBC_TH_LAYOUT_ALIGNMENT;
- alignment_header = AFBC_TH_BODY_START_ALIGNMENT;
- } else {
- alignment_header = AFBC_BODY_START_ALIGNMENT;
- }
-
- kfb->aligned_w = ALIGN(mode_cmd->width, alignment_w);
- kfb->aligned_h = ALIGN(mode_cmd->height, alignment_h);
+ if (mode_cmd->modifier[0] & AFBC_FORMAT_MOD_TILED)
+ kfb->base.alignment_header =
AFBC_TH_BODY_START_ALIGNMENT;
+ else
+ kfb->base.alignment_header = AFBC_BODY_START_ALIGNMENT;
- if (mode_cmd->offsets[0] % alignment_header) {
+ if (mode_cmd->offsets[0] % kfb->base.alignment_header) {
DRM_DEBUG_KMS("afbc offset alignment check failed.\n");
ret = -EINVAL;
goto err_cleanup;
}
- n_blocks = (kfb->aligned_w * kfb->aligned_h) /
AFBC_SUPERBLK_PIXELS;
- kfb->offset_payload = ALIGN(n_blocks * AFBC_HEADER_SIZE,
alignment_header);
-
- bpp = komeda_get_afbc_format_bpp(info, mode_cmd->modifier[0]);
- kfb->afbc_size = kfb->offset_payload
- + n_blocks * ALIGN(bpp * AFBC_SUPERBLK_PIXELS /
8, AFBC_SUPERBLK_ALIGNMENT);
- check.min_size[0] = kfb->afbc_size + mode_cmd->offsets[0];
- check.use_min_size = true;
+ kfb->base.bpp = komeda_get_afbc_format_bpp(info,
mode_cmd->modifier[0]);
+ check.data = &kfb->base;
} else {
ret = komeda_fb_check_src_coords(kfb, 0, 0, mode_cmd->width,
mode_cmd->height);
@@ -144,14 +124,14 @@ komeda_fb_create(struct drm_device *dev, struct drm_file
*file,
goto err_cleanup;
}
- ret = drm_
[PATCHv5 30/34] drm/arm/malidp: Integrate verify functions
The next step towards using generic afbc-aware helpers.
Signed-off-by: Andrzej Pietrasiewicz
---
drivers/gpu/drm/arm/malidp_drv.c | 36
1 file changed, 9 insertions(+), 27 deletions(-)
diff --git a/drivers/gpu/drm/arm/malidp_drv.c b/drivers/gpu/drm/arm/malidp_drv.c
index 961e5a3f5b08..e1502666bce0 100644
--- a/drivers/gpu/drm/arm/malidp_drv.c
+++ b/drivers/gpu/drm/arm/malidp_drv.c
@@ -270,9 +270,16 @@ static const struct drm_mode_config_helper_funcs
malidp_mode_config_helpers = {
};
static bool
-malidp_verify_afbc_framebuffer_caps(struct drm_device *dev,
- const struct drm_mode_fb_cmd2 *mode_cmd)
+malidp_verify_afbc_framebuffer(struct drm_device *dev, struct drm_file *file,
+ const struct drm_mode_fb_cmd2 *mode_cmd)
{
+ int n_superblocks = 0;
+ const struct drm_format_info *info;
+ struct drm_gem_object *objs = NULL;
+ u32 afbc_superblock_size = 0, afbc_superblock_height = 0;
+ u32 afbc_superblock_width = 0, afbc_size = 0;
+ int bpp = 0;
+
if (malidp_format_mod_supported(dev, mode_cmd->pixel_format,
mode_cmd->modifier[0]) == false)
return false;
@@ -294,21 +301,6 @@ malidp_verify_afbc_framebuffer_caps(struct drm_device *dev,
return false;
}
- return true;
-}
-
-static bool
-malidp_verify_afbc_framebuffer_size(struct drm_device *dev,
- struct drm_file *file,
- const struct drm_mode_fb_cmd2 *mode_cmd)
-{
- int n_superblocks = 0;
- const struct drm_format_info *info;
- struct drm_gem_object *objs = NULL;
- u32 afbc_superblock_size = 0, afbc_superblock_height = 0;
- u32 afbc_superblock_width = 0, afbc_size = 0;
- int bpp = 0;
-
switch (mode_cmd->modifier[0] & AFBC_SIZE_MASK) {
case AFBC_SIZE_16X16:
afbc_superblock_height = 16;
@@ -358,16 +350,6 @@ malidp_verify_afbc_framebuffer_size(struct drm_device *dev,
return true;
}
-static bool
-malidp_verify_afbc_framebuffer(struct drm_device *dev, struct drm_file *file,
- const struct drm_mode_fb_cmd2 *mode_cmd)
-{
- if (!malidp_verify_afbc_framebuffer_caps(dev, mode_cmd))
- return false;
-
- return malidp_verify_afbc_framebuffer_size(dev, file, mode_cmd);
-}
-
static struct drm_framebuffer *
malidp_fb_create(struct drm_device *dev, struct drm_file *file,
const struct drm_mode_fb_cmd2 *mode_cmd)
--
2.17.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCHv5 29/34] drm/arm/malidp: Make verify funcitons invocations independent
This will make it easier to transition to generic afbc-aware helpers.
Signed-off-by: Andrzej Pietrasiewicz
---
drivers/gpu/drm/arm/malidp_drv.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/arm/malidp_drv.c b/drivers/gpu/drm/arm/malidp_drv.c
index 37d92a06318e..961e5a3f5b08 100644
--- a/drivers/gpu/drm/arm/malidp_drv.c
+++ b/drivers/gpu/drm/arm/malidp_drv.c
@@ -362,10 +362,10 @@ static bool
malidp_verify_afbc_framebuffer(struct drm_device *dev, struct drm_file *file,
const struct drm_mode_fb_cmd2 *mode_cmd)
{
- if (malidp_verify_afbc_framebuffer_caps(dev, mode_cmd))
- return malidp_verify_afbc_framebuffer_size(dev, file, mode_cmd);
+ if (!malidp_verify_afbc_framebuffer_caps(dev, mode_cmd))
+ return false;
- return false;
+ return malidp_verify_afbc_framebuffer_size(dev, file, mode_cmd);
}
static struct drm_framebuffer *
--
2.17.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCHv5 26/34] drm/komeda: Factor in the invocation of special helper, afbc case
Prepare for unification with non-afbc case.
Signed-off-by: Andrzej Pietrasiewicz
---
.../arm/display/komeda/komeda_framebuffer.c | 84 ---
1 file changed, 37 insertions(+), 47 deletions(-)
diff --git a/drivers/gpu/drm/arm/display/komeda/komeda_framebuffer.c
b/drivers/gpu/drm/arm/display/komeda/komeda_framebuffer.c
index 2c9691b86cff..7e02a04cdd11 100644
--- a/drivers/gpu/drm/arm/display/komeda/komeda_framebuffer.c
+++ b/drivers/gpu/drm/arm/display/komeda/komeda_framebuffer.c
@@ -36,51 +36,6 @@ static const struct drm_framebuffer_funcs komeda_fb_funcs = {
.create_handle = komeda_fb_create_handle,
};
-static int
-komeda_fb_afbc_size_check(struct drm_device *dev,
- struct komeda_fb *kfb,
- const struct drm_format_info *info,
- struct drm_gem_object **objs,
- struct drm_file *file,
- const struct drm_mode_fb_cmd2 *mode_cmd)
-{
- struct drm_size_check check = { 0 };
- u32 alignment_w = 0, alignment_h = 0, alignment_header, n_blocks, bpp;
-
- if (!drm_afbc_get_superblock_wh(mode_cmd->modifier[0], &alignment_w,
&alignment_h))
- return -EINVAL;
-
- /* tiled header afbc */
- if (mode_cmd->modifier[0] & AFBC_FORMAT_MOD_TILED) {
- alignment_w *= AFBC_TH_LAYOUT_ALIGNMENT;
- alignment_h *= AFBC_TH_LAYOUT_ALIGNMENT;
- alignment_header = AFBC_TH_BODY_START_ALIGNMENT;
- } else {
- alignment_header = AFBC_BODY_START_ALIGNMENT;
- }
-
- kfb->aligned_w = ALIGN(mode_cmd->width, alignment_w);
- kfb->aligned_h = ALIGN(mode_cmd->height, alignment_h);
-
- if (mode_cmd->offsets[0] % alignment_header) {
- DRM_DEBUG_KMS("afbc offset alignment check failed.\n");
- return -EINVAL;
- }
-
- n_blocks = (kfb->aligned_w * kfb->aligned_h) / AFBC_SUPERBLK_PIXELS;
- kfb->offset_payload = ALIGN(n_blocks * AFBC_HEADER_SIZE,
- alignment_header);
-
- bpp = komeda_get_afbc_format_bpp(info, mode_cmd->modifier[0]);
- kfb->afbc_size = kfb->offset_payload + n_blocks *
-ALIGN(bpp * AFBC_SUPERBLK_PIXELS / 8,
- AFBC_SUPERBLK_ALIGNMENT);
- check.min_size[0] = kfb->afbc_size + mode_cmd->offsets[0];
- check.use_min_size = true;
-
- return drm_gem_fb_size_check2(dev, mode_cmd, &check, objs);
-}
-
struct drm_framebuffer *
komeda_fb_create(struct drm_device *dev, struct drm_file *file,
const struct drm_mode_fb_cmd2 *mode_cmd)
@@ -113,14 +68,49 @@ komeda_fb_create(struct drm_device *dev, struct drm_file
*file,
info = drm_get_format_info(dev, mode_cmd);
if (mode_cmd->modifier[0]) {
+ struct drm_size_check check = { 0 };
+ u32 alignment_w = 0, alignment_h = 0;
+ u32 alignment_header, n_blocks, bpp;
+
if (num_planes != 1) {
DRM_DEBUG_KMS("AFBC requires exactly 1 plane.\n");
ret = -EINVAL;
goto err_cleanup;
}
- ret = komeda_fb_afbc_size_check(dev, kfb, info, objs,
- file, mode_cmd);
+ if (!drm_afbc_get_superblock_wh(mode_cmd->modifier[0],
&alignment_w, &alignment_h)) {
+ ret = -EINVAL;
+ goto err_cleanup;
+ }
+
+ /* tiled header afbc */
+ if (mode_cmd->modifier[0] & AFBC_FORMAT_MOD_TILED) {
+ alignment_w *= AFBC_TH_LAYOUT_ALIGNMENT;
+ alignment_h *= AFBC_TH_LAYOUT_ALIGNMENT;
+ alignment_header = AFBC_TH_BODY_START_ALIGNMENT;
+ } else {
+ alignment_header = AFBC_BODY_START_ALIGNMENT;
+ }
+
+ kfb->aligned_w = ALIGN(mode_cmd->width, alignment_w);
+ kfb->aligned_h = ALIGN(mode_cmd->height, alignment_h);
+
+ if (mode_cmd->offsets[0] % alignment_header) {
+ DRM_DEBUG_KMS("afbc offset alignment check failed.\n");
+ ret = -EINVAL;
+ goto err_cleanup;
+ }
+
+ n_blocks = (kfb->aligned_w * kfb->aligned_h) /
AFBC_SUPERBLK_PIXELS;
+ kfb->offset_payload = ALIGN(n_blocks * AFBC_HEADER_SIZE,
alignment_header);
+
+ bpp = komeda_get_afbc_format_bpp(info, mode_cmd->modifier[0]);
+ kfb->afbc_size = kfb->offset_payload
+ + n_blocks * ALIGN(bpp * AFBC_SUPERBLK_PIXELS /
8, AFBC_SUPERBLK_ALIGNMENT);
+ check.min_size[0] = kfb->afbc_size + mode_cmd->offsets[0];
+ check.use_min_size = true;
+
+ ret = drm_gem_fb_size_check2(dev, mode_cmd, &check, objs)
[PATCHv5 03/34] drm/gem-fb-helper: Add special version of drm_gem_fb_size_check
The new version accepts a struct describing deviations from standard way of
doing the size checks. The caller must provide the respective values.
Signed-off-by: Andrzej Pietrasiewicz
---
drivers/gpu/drm/drm_gem_framebuffer_helper.c | 46
include/drm/drm_gem_framebuffer_helper.h | 16 +++
2 files changed, 54 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/drm_gem_framebuffer_helper.c
b/drivers/gpu/drm/drm_gem_framebuffer_helper.c
index b3494f6b66bb..d2fce1ec8f37 100644
--- a/drivers/gpu/drm/drm_gem_framebuffer_helper.c
+++ b/drivers/gpu/drm/drm_gem_framebuffer_helper.c
@@ -300,8 +300,8 @@ int drm_gem_fb_lookup(struct drm_device *dev,
EXPORT_SYMBOL_GPL(drm_gem_fb_lookup);
/**
- * drm_gem_fb_size_check() - Helper function for use in
- * &drm_mode_config_funcs.fb_create implementations
+ * drm_gem_fb_size_check2() - Helper function for use in
+ * &drm_mode_config_funcs.fb_create implementations
* @dev: DRM device
* @mode_cmd: Metadata from the userspace framebuffer creation request
*
@@ -311,9 +311,10 @@ EXPORT_SYMBOL_GPL(drm_gem_fb_lookup);
* Returns:
* Zero on success or a negative error code on failure.
*/
-int drm_gem_fb_size_check(struct drm_device *dev,
- const struct drm_mode_fb_cmd2 *mode_cmd,
- struct drm_gem_object **objs)
+int drm_gem_fb_size_check2(struct drm_device *dev,
+ const struct drm_mode_fb_cmd2 *mode_cmd,
+ const struct drm_size_check *check,
+ struct drm_gem_object **objs)
{
const struct drm_format_info *info;
int i;
@@ -326,10 +327,19 @@ int drm_gem_fb_size_check(struct drm_device *dev,
unsigned int width = mode_cmd->width / (i ? info->hsub : 1);
unsigned int height = mode_cmd->height / (i ? info->vsub : 1);
unsigned int min_size;
+ u32 pitch = mode_cmd->pitches[i];
+
+ if (check && check->use_pitch_multiplier)
+ if ((pitch * check->pitch_multiplier[i]) %
+ check->pitch_modulo)
+ return -EINVAL;
- min_size = (height - 1) * mode_cmd->pitches[i]
-+ drm_format_info_min_pitch(info, i, width)
-+ mode_cmd->offsets[i];
+ if (check && check->use_min_size)
+ min_size = check->min_size[i];
+ else
+ min_size = (height - 1) * pitch
++ drm_format_info_min_pitch(info, i, width)
++ mode_cmd->offsets[i];
if (objs[i]->size < min_size)
return -EINVAL;
@@ -338,6 +348,26 @@ int drm_gem_fb_size_check(struct drm_device *dev,
return 0;
}
+EXPORT_SYMBOL_GPL(drm_gem_fb_size_check2);
+
+/**
+ * drm_gem_fb_size_check() - Helper function for use in
+ * &drm_mode_config_funcs.fb_create implementations
+ * @dev: DRM device
+ * @mode_cmd: Metadata from the userspace framebuffer creation request
+ *
+ * This function can be used to verify buffer sizes for all planes.
+ * It is caller's responsibility to put the objects on failure.
+ *
+ * Returns:
+ * Zero on success or a negative error code on failure.
+ */
+int drm_gem_fb_size_check(struct drm_device *dev,
+ const struct drm_mode_fb_cmd2 *mode_cmd,
+ struct drm_gem_object **objs)
+{
+ return drm_gem_fb_size_check2(dev, mode_cmd, NULL, objs);
+}
EXPORT_SYMBOL_GPL(drm_gem_fb_size_check);
static const struct drm_framebuffer_funcs drm_gem_fb_funcs_dirtyfb = {
diff --git a/include/drm/drm_gem_framebuffer_helper.h
b/include/drm/drm_gem_framebuffer_helper.h
index c85d4b152e91..4955af96d6c3 100644
--- a/include/drm/drm_gem_framebuffer_helper.h
+++ b/include/drm/drm_gem_framebuffer_helper.h
@@ -11,6 +11,18 @@ struct drm_mode_fb_cmd2;
struct drm_plane;
struct drm_plane_state;
struct drm_simple_display_pipe;
+struct drm_size_check;
+
+/**
+ * struct drm_size_check - Description of special requirements for size checks.
+ */
+struct drm_size_check {
+ unsigned int min_size[4];
+ bool use_min_size;
+ u32 pitch_multiplier[4];
+ u32 pitch_modulo;
+ bool use_pitch_multiplier;
+};
struct drm_gem_object *drm_gem_fb_get_obj(struct drm_framebuffer *fb,
unsigned int plane);
@@ -32,6 +44,10 @@ int drm_gem_fb_lookup(struct drm_device *dev,
struct drm_file *file,
const struct drm_mode_fb_cmd2 *mode_cmd,
struct drm_gem_object **objs);
+int drm_gem_fb_size_check2(struct drm_device *dev,
+ const struct drm_mode_fb_cmd2 *mode_cmd,
+ const struct drm_size_check *check,
+
[PATCHv5 23/34] drm/komeda: Use special helper for non-afbc size checks
Use the generic helper code.
Signed-off-by: Andrzej Pietrasiewicz
---
.../arm/display/komeda/komeda_framebuffer.c | 46 +--
1 file changed, 21 insertions(+), 25 deletions(-)
diff --git a/drivers/gpu/drm/arm/display/komeda/komeda_framebuffer.c
b/drivers/gpu/drm/arm/display/komeda/komeda_framebuffer.c
index 9139fe5619be..d75176e24f24 100644
--- a/drivers/gpu/drm/arm/display/komeda/komeda_framebuffer.c
+++ b/drivers/gpu/drm/arm/display/komeda/komeda_framebuffer.c
@@ -88,42 +88,38 @@ komeda_fb_afbc_size_check(struct komeda_fb *kfb,
}
static int
-komeda_fb_none_afbc_size_check(struct komeda_dev *mdev,
+komeda_fb_none_afbc_size_check(struct drm_device *dev,
const struct drm_format_info *info,
struct drm_gem_object **objs,
struct drm_file *file,
const struct drm_mode_fb_cmd2 *mode_cmd)
{
+ struct komeda_dev *mdev = dev->dev_private;
+ struct drm_size_check check = { 0 };
struct drm_gem_object *obj;
- u32 i, block_h;
- u64 min_size;
+ u32 i;
for (i = 0; i < info->num_planes; i++) {
obj = objs[i];
- block_h = drm_format_info_block_height(info, i);
- if ((mode_cmd->pitches[i] * block_h) % mdev->chip.bus_width) {
- DRM_DEBUG_KMS("Pitch[%d]: 0x%x doesn't align to 0x%x\n",
- i, mode_cmd->pitches[i],
- mdev->chip.bus_width);
- return -EINVAL;
- }
-
- min_size = komeda_fb_get_pixel_addr_nofb(info,
-mode_cmd->modifier[0],
-mode_cmd->pitches,
-mode_cmd->offsets,
-obj,
-0, mode_cmd->height, i)
-- to_drm_gem_cma_obj(obj)->paddr;
- if (obj->size < min_size) {
- DRM_DEBUG_KMS("The fb->obj[%d] size: 0x%zx lower than
the minimum requirement: 0x%llx.\n",
- i, obj->size, min_size);
- return -EINVAL;
- }
+ check.pitch_multiplier[i] =
+ drm_format_info_block_height(info, i);
+
+ check.min_size[i] =
+ komeda_fb_get_pixel_addr_nofb(info,
+ mode_cmd->modifier[0],
+ mode_cmd->pitches,
+ mode_cmd->offsets,
+ obj,
+ 0, mode_cmd->height, i)
+ - to_drm_gem_cma_obj(obj)->paddr;
}
- return 0;
+ check.pitch_modulo = mdev->chip.bus_width;
+ check.use_pitch_multiplier = true;
+ check.use_min_size = true;
+
+ return drm_gem_fb_size_check2(dev, mode_cmd, &check, objs);
}
struct drm_framebuffer *
@@ -172,7 +168,7 @@ komeda_fb_create(struct drm_device *dev, struct drm_file
*file,
if (ret)
goto err_cleanup;
- ret = komeda_fb_none_afbc_size_check(mdev, info, objs,
+ ret = komeda_fb_none_afbc_size_check(dev, info, objs,
file, mode_cmd);
}
if (ret < 0)
--
2.17.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCHv5 19/34] drm/komeda: Make the size checks independent from framebuffer structure
The same data is available in mode_cmd.
Signed-off-by: Andrzej Pietrasiewicz
---
.../gpu/drm/arm/display/komeda/komeda_framebuffer.c| 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/arm/display/komeda/komeda_framebuffer.c
b/drivers/gpu/drm/arm/display/komeda/komeda_framebuffer.c
index d52278ca27fb..42ccd4647919 100644
--- a/drivers/gpu/drm/arm/display/komeda/komeda_framebuffer.c
+++ b/drivers/gpu/drm/arm/display/komeda/komeda_framebuffer.c
@@ -155,9 +155,9 @@ komeda_fb_create(struct drm_device *dev, struct drm_file
*file,
goto err_free;
drm_helper_mode_fill_fb_struct(dev, &kfb->base, mode_cmd);
- info = kfb->base.format;
+ info = drm_get_format_info(dev, mode_cmd);
- if (kfb->base.modifier) {
+ if (mode_cmd->modifier[0]) {
if (info->num_planes != 1) {
DRM_DEBUG_KMS("AFBC requires exactly 1 plane.\n");
ret = -EINVAL;
@@ -167,8 +167,8 @@ komeda_fb_create(struct drm_device *dev, struct drm_file
*file,
ret = komeda_fb_afbc_size_check(kfb, info, objs, file,
mode_cmd);
} else {
- ret = komeda_fb_check_src_coords(kfb, 0, 0, kfb->base.width,
-kfb->base.height);
+ ret = komeda_fb_check_src_coords(kfb, 0, 0, mode_cmd->width,
+mode_cmd->height);
if (ret)
goto err_cleanup;
@@ -179,7 +179,7 @@ komeda_fb_create(struct drm_device *dev, struct drm_file
*file,
goto err_cleanup;
if (info->num_planes == 3)
- if (kfb->base.pitches[1] != kfb->base.pitches[2]) {
+ if (mode_cmd->pitches[1] != mode_cmd->pitches[2]) {
DRM_DEBUG_KMS("The pitch[1] and [2] are not same\n");
ret = -EINVAL;
goto err_cleanup;
--
2.17.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCHv5 15/34] drm/komeda: Free komeda_fb_afbc_size_check from framebuffer dependency
It does still depend on komeda_fb, but only for komeda-specific parameters.
Signed-off-by: Andrzej Pietrasiewicz
---
.../drm/arm/display/komeda/komeda_framebuffer.c | 15 +++
1 file changed, 7 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/arm/display/komeda/komeda_framebuffer.c
b/drivers/gpu/drm/arm/display/komeda/komeda_framebuffer.c
index 6b11a1b21ef6..aa703aabbeee 100644
--- a/drivers/gpu/drm/arm/display/komeda/komeda_framebuffer.c
+++ b/drivers/gpu/drm/arm/display/komeda/komeda_framebuffer.c
@@ -43,18 +43,17 @@ komeda_fb_afbc_size_check(struct komeda_fb *kfb,
struct drm_file *file,
const struct drm_mode_fb_cmd2 *mode_cmd)
{
- struct drm_framebuffer *fb = &kfb->base;
struct drm_gem_object *obj;
u32 alignment_w = 0, alignment_h = 0, alignment_header, n_blocks, bpp;
u64 min_size;
obj = objs[0];
- if (!drm_afbc_get_superblock_wh(fb->modifier, &alignment_w,
&alignment_h))
+ if (!drm_afbc_get_superblock_wh(mode_cmd->modifier[0], &alignment_w,
&alignment_h))
return -EINVAL;
/* tiled header afbc */
- if (fb->modifier & AFBC_FORMAT_MOD_TILED) {
+ if (mode_cmd->modifier[0] & AFBC_FORMAT_MOD_TILED) {
alignment_w *= AFBC_TH_LAYOUT_ALIGNMENT;
alignment_h *= AFBC_TH_LAYOUT_ALIGNMENT;
alignment_header = AFBC_TH_BODY_START_ALIGNMENT;
@@ -62,10 +61,10 @@ komeda_fb_afbc_size_check(struct komeda_fb *kfb,
alignment_header = AFBC_BODY_START_ALIGNMENT;
}
- kfb->aligned_w = ALIGN(fb->width, alignment_w);
- kfb->aligned_h = ALIGN(fb->height, alignment_h);
+ kfb->aligned_w = ALIGN(mode_cmd->width, alignment_w);
+ kfb->aligned_h = ALIGN(mode_cmd->height, alignment_h);
- if (fb->offsets[0] % alignment_header) {
+ if (mode_cmd->offsets[0] % alignment_header) {
DRM_DEBUG_KMS("afbc offset alignment check failed.\n");
return -EINVAL;
}
@@ -74,11 +73,11 @@ komeda_fb_afbc_size_check(struct komeda_fb *kfb,
kfb->offset_payload = ALIGN(n_blocks * AFBC_HEADER_SIZE,
alignment_header);
- bpp = komeda_get_afbc_format_bpp(info, fb->modifier);
+ bpp = komeda_get_afbc_format_bpp(info, mode_cmd->modifier[0]);
kfb->afbc_size = kfb->offset_payload + n_blocks *
ALIGN(bpp * AFBC_SUPERBLK_PIXELS / 8,
AFBC_SUPERBLK_ALIGNMENT);
- min_size = kfb->afbc_size + fb->offsets[0];
+ min_size = kfb->afbc_size + mode_cmd->offsets[0];
if (min_size > obj->size) {
DRM_DEBUG_KMS("afbc size check failed, obj_size: 0x%zx.
min_size 0x%llx.\n",
obj->size, min_size);
--
2.17.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
