[PATCH 0/2] Renesas R-Car Gen3 DU alpha and z-order support
On 21 April 2016 at 11:14, Laurent Pinchart wrote: > Hello, > > This patch series implement support for alpha and z-order configuration in the > R-Car DU driver for the Gen3 SoCs family. > > The Gen3 SoCs delegate composition to an external IP core called VSP, > supported by a V4L2 driver. The DU driver interfaces with the VSP driver using > direct function calls. Alpha and z-order configuration is implemented in the > VSP driver, the DU driver thus just needs to pass the values using the VSP > API. > > This series depends on a large VSP series that has been merged in the Linux > media git tree for v4.7. Dave, instead of merging the media tree in your tree > to pull the dependency in, it would be easier to get those two patches > upstream through the media tree. I don't expect any conflict related to the > DU driver for v4.7. If you're fine with that, could you ack the patches ? > > Laurent Pinchart (2): > drm: rcar-du: Add Z-order support for VSP planes > drm: rcar-du: Add alpha support for VSP planes > Seems fine, Acked-by: Dave AIrlie for inclusion via media. Dave. > drivers/gpu/drm/rcar-du/rcar_du_vsp.c | 16 > drivers/gpu/drm/rcar-du/rcar_du_vsp.h | 2 ++ > 2 files changed, 14 insertions(+), 4 deletions(-) > > -- > Regards, > > Laurent Pinchart > > ___ > dri-devel mailing list > dri-devel at lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/dri-devel
[GIT PULL] MT8173 DRM support
On 19 April 2016 at 23:42, Philipp Zabel wrote: > Hi Dave, > > please consider pulling this tag with initial MediaTek MT8173 DRM > support, corresponding to v14 of the patch series. These patches have > been mostly stable for the last few rounds. I'll follow up with the HDMI > encoder support pending review of the latest version. > Close but no cigar, building as a module screws up here, drivers/gpu/drm/mediatek/mtk_drm_drv.o: In function `init_module': mtk_drm_drv.c:(.init.text+0x0): multiple definition of `init_module' drivers/gpu/drm/mediatek/mtk_drm_ddp.o:mtk_drm_ddp.c:(.init.text+0x0): first defined here drivers/gpu/drm/mediatek/mtk_drm_drv.o: In function `cleanup_module': mtk_drm_drv.c:(.exit.text+0x0): multiple definition of `cleanup_module' drivers/gpu/drm/mediatek/mtk_drm_ddp.o:mtk_drm_ddp.c:(.exit.text+0x0): first defined here Try again! (or tell me I pulled the wrong thing :-) Dave.
[PATCH 1/2] drm: rcar-du: Add Z-order support for VSP planes
Hi Daniel,
On Thursday 21 Apr 2016 18:10:25 Daniel Vetter wrote:
> On Thu, Apr 21, 2016 at 04:14:12AM +0300, Laurent Pinchart wrote:
> > Make the Z-order of VSP planes configurable through the zpos property,
> > exactly as for the native DU planes.
> >
> > Signed-off-by: Laurent Pinchart
> >
> > ---
> >
> > drivers/gpu/drm/rcar-du/rcar_du_vsp.c | 16
> > drivers/gpu/drm/rcar-du/rcar_du_vsp.h | 2 ++
> > 2 files changed, 14 insertions(+), 4 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/rcar-du/rcar_du_vsp.c
> > b/drivers/gpu/drm/rcar-du/rcar_du_vsp.c index de7ef041182b..62e9619eaea4
> > 100644
> > --- a/drivers/gpu/drm/rcar-du/rcar_du_vsp.c
> > +++ b/drivers/gpu/drm/rcar-du/rcar_du_vsp.c
> > @@ -180,8 +180,9 @@ static void rcar_du_vsp_plane_setup(struct
> > rcar_du_vsp_plane *plane)>
> > WARN_ON(!pixelformat);
> >
> > - vsp1_du_atomic_update(plane->vsp->vsp, plane->index, pixelformat,
> > - fb->pitches[0], paddr, &src, &dst);
> > + vsp1_du_atomic_update_zpos(plane->vsp->vsp, plane->index, pixelformat,
> > + fb->pitches[0], paddr, &src, &dst,
> > + state->zpos);
> >
> > }
> >
> > static int rcar_du_vsp_plane_atomic_check(struct drm_plane *plane,
> >
> > @@ -220,8 +221,8 @@ static void rcar_du_vsp_plane_atomic_update(struct
> > drm_plane *plane,>
> > if (plane->state->crtc)
> >
> > rcar_du_vsp_plane_setup(rplane);
> >
> > else
> >
> > - vsp1_du_atomic_update(rplane->vsp->vsp, rplane->index, 0, 0, 0,
> > - NULL, NULL);
> > + vsp1_du_atomic_update_zpos(rplane->vsp->vsp, rplane->index,
> > + 0, 0, 0, NULL, NULL, 0);
> >
> > }
> >
> > static const struct drm_plane_helper_funcs rcar_du_vsp_plane_helper_funcs
> > = {>
> > @@ -269,6 +270,7 @@ static void rcar_du_vsp_plane_reset(struct drm_plane
> > *plane)>
> > return;
> >
> > state->alpha = 255;
> >
> > + state->zpos = plane->type == DRM_PLANE_TYPE_PRIMARY ? 0 : 1;
> >
> > plane->state = &state->state;
> > plane->state->plane = plane;
> >
> > @@ -283,6 +285,8 @@ static int
> > rcar_du_vsp_plane_atomic_set_property(struct drm_plane *plane,>
> > if (property == rcdu->props.alpha)
> >
> > rstate->alpha = val;
> >
> > + else if (property == rcdu->props.zpos)
> > + rstate->zpos = val;
> >
> > else
> >
> > return -EINVAL;
> >
> > @@ -299,6 +303,8 @@ static int
> > rcar_du_vsp_plane_atomic_get_property(struct drm_plane *plane,>
> > if (property == rcdu->props.alpha)
> >
> > *val = rstate->alpha;
> >
> > + else if (property == rcdu->props.zpos)
> > + *val = rstate->zpos;
> >
> > else
> >
> > return -EINVAL;
> >
> > @@ -378,6 +384,8 @@ int rcar_du_vsp_init(struct rcar_du_vsp *vsp)
> >
> > drm_object_attach_property(&plane->plane.base,
> >
> >rcdu->props.alpha, 255);
> >
> > + drm_object_attach_property(&plane->plane.base,
> > + rcdu->props.zpos, 1);
> >
> > }
> >
> > return 0;
> >
> > diff --git a/drivers/gpu/drm/rcar-du/rcar_du_vsp.h
> > b/drivers/gpu/drm/rcar-du/rcar_du_vsp.h index df3bf3805c69..510dcc9c6816
> > 100644
> > --- a/drivers/gpu/drm/rcar-du/rcar_du_vsp.h
> > +++ b/drivers/gpu/drm/rcar-du/rcar_du_vsp.h
> > @@ -44,6 +44,7 @@ static inline struct rcar_du_vsp_plane
> > *to_rcar_vsp_plane(struct drm_plane *p)>
> > * @state: base DRM plane state
> > * @format: information about the pixel format used by the plane
> > * @alpha: value of the plane alpha property
> >
> > + * @zpos: value of the plane zpos property
> >
> > */
> >
> > struct rcar_du_vsp_plane_state {
> >
> > struct drm_plane_state state;
> >
> > @@ -51,6 +52,7 @@ struct rcar_du_vsp_plane_state {
> >
> > const struct rcar_du_format_info *format;
> >
> > unsigned int alpha;
> >
> > + unsigned int zpos;
>
> There's lots of effort by various people to create a generic zpos/blending
> set of properties. Care to jump onto that effort and making it finally
> happen for real? I kinda don't want to have a propliferation of slightly
> diffferent zpos/blending props across all the drivers ...
OK, I'll try to. Would you mind if we got these patches merged first for v4.7,
and then switched to a generic property for v4.8 ? The reason is that this
series depends on a large patch series queued in the linux-media tree for
v4.7, and it would be easier to handle the dependency by merging these two
patches in linux-media. A rework of the zpos and alpha properties would need
to be merged through the drm tree.
> > };
> >
> > static inline struct rcar_du_vsp_plane_state *
--
Regards,
Laurent Pinchart
[PATCH v3 4/7] drm/i2c: adv7511: Create a MIPI DSI device
Hi Archit,
Thank you for the patch.
On Wednesday 09 Mar 2016 16:27:15 Archit Taneja wrote:
> In order to pass DSI specific parameters to the DSI host, we need the
> driver to create a mipi_dsi_device DSI device that attaches to the
> host.
>
> Use of_graph helpers to get the DSI host DT node. Create a MIPI DSI
> device using this host. Finally, attach this device to the DSI host.
>
> Populate DT parameters (number of data lanes for now) that are required
> for DSI RX to work correctly. Hardcode few other parameters (rgb,
> embedded_sync) for now.
>
> Signed-off-by: Archit Taneja
This adds a hard dependency on CONFIG_DRM_MIPI_DSI, otherwise the kernel won't
link. As the ADV7511 doesn't require DSI, could you make it optional with
conditional compilation to avoid pulling in dead code ?
> ---
> drivers/gpu/drm/i2c/adv7511.c | 130 ---
> 1 file changed, 123 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/gpu/drm/i2c/adv7511.c b/drivers/gpu/drm/i2c/adv7511.c
> index 75be17c..6c2a89a 100644
> --- a/drivers/gpu/drm/i2c/adv7511.c
> +++ b/drivers/gpu/drm/i2c/adv7511.c
> @@ -11,6 +11,7 @@
> #include
> #include
> #include
> +#include
> #include
> #include
>
> @@ -19,6 +20,7 @@
> #include
> #include
> #include
> +#include
>
> #include "adv7511.h"
>
> @@ -56,6 +58,11 @@ struct adv7511 {
>
> struct gpio_desc *gpio_pd;
>
> + /* ADV7533 DSI RX related params */
> + struct device_node *host_node;
> + struct mipi_dsi_device *dsi;
> + u8 num_dsi_lanes;
> +
> enum adv7511_type type;
> };
>
> @@ -392,8 +399,10 @@ static void adv7511_set_link_config(struct adv7511
> *adv7511,
>
> static void adv7533_dsi_power_on(struct adv7511 *adv)
> {
> - /* set number of dsi lanes (hardcoded to 4 for now) */
> - regmap_write(adv->regmap_cec, 0x1c, 0x4 << 4);
> + struct mipi_dsi_device *dsi = adv->dsi;
> +
> + /* set number of dsi lanes */
> + regmap_write(adv->regmap_cec, 0x1c, dsi->lanes << 4);
> /* disable internal timing generator */
> regmap_write(adv->regmap_cec, 0x27, 0x0b);
> /* enable hdmi */
> @@ -889,6 +898,51 @@ static void adv7511_bridge_mode_set(struct drm_bridge
> *bridge, adv7511_mode_set(adv, mode, adj_mode);
> }
>
> +static int adv7533_attach_dsi(struct adv7511 *adv)
> +{
> + struct device *dev = &adv->i2c_main->dev;
> + struct mipi_dsi_host *host;
> + struct mipi_dsi_device *dsi;
> + int ret = 0;
> + const struct mipi_dsi_device_info info = { .type = "adv7533",
> +.channel = 0,
> +.node = NULL,
> + };
> +
> + host = of_find_mipi_dsi_host_by_node(adv->host_node);
> + if (!host) {
> + dev_err(dev, "failed to find dsi host\n");
> + return -EPROBE_DEFER;
> + }
> +
> + dsi = mipi_dsi_device_register_full(host, &info);
> + if (IS_ERR(dsi)) {
> + dev_err(dev, "failed to create dsi device\n");
> + ret = PTR_ERR(dsi);
> + goto err_dsi_device;
> + }
> +
> + adv->dsi = dsi;
> +
> + dsi->lanes = adv->num_dsi_lanes;
> + dsi->format = MIPI_DSI_FMT_RGB888;
> + dsi->mode_flags = MIPI_DSI_MODE_VIDEO | MIPI_DSI_MODE_VIDEO_SYNC_PULSE |
> + MIPI_DSI_MODE_EOT_PACKET | MIPI_DSI_MODE_VIDEO_HSE;
> +
> + ret = mipi_dsi_attach(dsi);
> + if (ret < 0) {
> + dev_err(dev, "failed to attach dsi to host\n");
> + goto err_dsi_attach;
> + }
> +
> + return 0;
> +
> +err_dsi_attach:
> + mipi_dsi_device_unregister(dsi);
> +err_dsi_device:
> + return ret;
> +}
> +
> static int adv7511_bridge_attach(struct drm_bridge *bridge)
> {
> struct adv7511 *adv = bridge_to_adv7511(bridge);
> @@ -912,6 +966,9 @@ static int adv7511_bridge_attach(struct drm_bridge
> *bridge) &adv7511_connector_helper_funcs);
> drm_mode_connector_attach_encoder(&adv->connector, bridge->encoder);
>
> + if (adv->type == ADV7533)
> + ret = adv7533_attach_dsi(adv);
> +
> return ret;
> }
>
> @@ -1009,6 +1066,41 @@ static int adv7511_parse_dt(struct device_node *np,
> return 0;
> }
>
> +static int adv7533_parse_dt(struct device_node *np, struct adv7511 *adv)
> +{
> + u32 num_lanes;
> + struct device_node *endpoint;
> +
> + of_property_read_u32(np, "adi,dsi-lanes", &num_lanes);
> +
> + if (num_lanes < 1 || num_lanes > 4)
> + return -EINVAL;
> +
> + adv->num_dsi_lanes = num_lanes;
> +
> + endpoint = of_graph_get_next_endpoint(np, NULL);
> + if (!endpoint) {
> + DRM_ERROR("ADV7533 DSI input endpoint not found\n");
> + return -ENODEV;
> + }
> +
> + adv->host_node = of_graph_get_remote_port_parent(endpoint);
> + if (!adv->host_node) {
> + DRM_ERROR("DSI host node not found\n");
> + of_
[PATCH v3 7/7] dt-bindings: drm/bridge: Update bindings for ADV7533
Hi Archit,
Thank you for the patch.
On Wednesday 09 Mar 2016 16:27:18 Archit Taneja wrote:
> Add description of ADV7533. Add the required and optional properties that
> are specific to it.
>
> Cc: devicetree at vger.kernel.org
> Cc: Rob Herring
>
> Signed-off-by: Archit Taneja
> ---
> .../bindings/display/bridge/adi,adv7511.txt| 25 ++-
> 1 file changed, 20 insertions(+), 5 deletions(-)
>
> diff --git
> a/Documentation/devicetree/bindings/display/bridge/adi,adv7511.txt
> b/Documentation/devicetree/bindings/display/bridge/adi,adv7511.txt index
> 96c25ee..420da5a 100644
> --- a/Documentation/devicetree/bindings/display/bridge/adi,adv7511.txt
> +++ b/Documentation/devicetree/bindings/display/bridge/adi,adv7511.txt
> @@ -1,13 +1,19 @@
> -Analog Device ADV7511(W)/13 HDMI Encoders
> +Analog Device ADV7511(W)/13/33 HDMI Encoders
> -
>
> -The ADV7511, ADV7511W and ADV7513 are HDMI audio and video transmitters
> +The ADV7511, ADV7511W, ADV7513 and ADV7533 are HDMI audio and video
> transmitters compatible with HDMI 1.4 and DVI 1.0. They support color space
> conversion, -S/PDIF, CEC and HDCP.
> +S/PDIF, CEC and HDCP. ADV7533 supports the DSI interface for input pixels,
> while +the others support RGB interface.
>
> Required properties:
>
> -- compatible: Should be one of "adi,adv7511", "adi,adv7511w" or
> "adi,adv7513" +- compatible: Should be one of:
> + "adi,adv7511"
> + "adi,adv7511w"
> + "adi,adv7513"
> + "adi,adv7533"
> +
> - reg: I2C slave address
>
> The ADV7511 supports a large number of input data formats that differ by
> their @@ -32,6 +38,11 @@ The following input format properties are required
> except in "rgb 1x" and - adi,input-justification: The input bit
> justification ("left", "evenly", "right").
>
> +The following properties are required for ADV7533:
> +
> +- adi,dsi-lanes: Number of DSI data lanes connected to the DSI host. It
> should + be one of 1, 2, 3 or 4.
Does the ADV7533 support data lanes remapping ?
> Optional properties:
>
> - interrupts: Specifier for the ADV7511 interrupt
> @@ -42,13 +53,17 @@ Optional properties:
> - adi,embedded-sync: The input uses synchronization signals embedded in the
> data stream (similar to BT.656). Defaults to separate H/V synchronization
> signals.
> +- adi,disable-timing-generator: Only for ADV7533. Disables the internal
> timing + generator. The chip will rely on the sync signals in the DSI data
> lanes, + rather than generate its own timings for HDMI output.
Isn't that something that should be selectable at runtime ?
> Required nodes:
>
> The ADV7511 has two video ports. Their connections are modelled using the
> OF graph bindings specified in Documentation/devicetree/bindings/graph.txt.
>
> -- Video port 0 for the RGB or YUV input
> +- Video port 0 for the RGB, YUV or DSI input. In the case of ADV7533, the
> + remote endpoint phandle should refer to a valid mipi_dsi_host device
Nitpicking, I would write "reference" instead of "refer to".
> node. - Video port 1 for the HDMI output
--
Regards,
Laurent Pinchart
[PATCH v3 0/7] drm/i2c: adv7511: ADV7533 support
Hi Archit, On Thursday 14 Apr 2016 20:26:11 Archit Taneja wrote: > On 3/9/2016 4:27 PM, Archit Taneja wrote: > > ADV7533 is a DSI to HDMI encoder chip. It's like ADV7511, but with an > > additional DSI RX block that takes in DSI video mode output. > > > > Trying to get this driver merged has had some challenges: > > > > - ADV7533 has an I2C control bus, but acts as a DSI peripheral too. > > > >After discussions, it was concluded that we'd want to provide an > >API to create MIPI DSI devices, rather than expose two different > >interfaces on DT. The first version [1] tried the former approach > >the second version [2] showed how the driver would look like if > >exposed 2 DT nodes. This lateset patchset relies on the MIPI DSI > >device creation API provided by [3], this has been accepted and > >should be merged for 4.6. > > > > - The driver was designed as an I2C slave encoder. When ADV7533 > > > >patches were posted [1], it was modelled as a bridge, but ADV7511 > >and others were still left as I2C slave encoders. This wasn't > >accepted. After discussions, it was decided that ADV7511 too would > >be converted into a bridge driver, and all the users of ADV7511 > >should assume it is a bridge. This bridge conversion was done in > >[4]. There is still some debate over whether the bridge driver be > >involved in the connector creation, or the KMS driver that has > >the whole view of the display pipeline. This discussion shouldn't > >affect this patch set, though. > > > > This patch set enables ADV7533 support with the above two issues > > now resolved. It also incorporates ADV7533 specific features and fixes > > that we've discovered since the first version of this patch was posted. > > > > Tested on ADV7533 chips on DB410c. It should work on the Hikey board too. > > I'd appreaciate if someone could test it on a ADV7511 platform since I > > don't have one. > > Could you try this patch set on the rcar-du platform? It would help to > verify if this doesn't break ADV7511. Basic testing didn't show any regression. For the whole series, Tested-by: Laurent Pinchart > > [4] > > https://lists.freedesktop.org/archives/dri-devel/2016-January/098287.html > > [3] > > https://lkml.org/lkml/2016/2/12/67 > > [2] > > https://lists.freedesktop.org/archives/dri-devel/2015-September/089884.htm > > l > > [1]: > > https://lists.freedesktop.org/archives/dri-devel/2015-July/087088.html > > > > Archit Taneja (7): > >drm/i2c: adv7511: Convert to drm_bridge > >drm/i2c: adv7511: Fix mutex deadlock when interrupts are disabled > >drm/i2c: adv7511: Initial support for ADV7533 > >drm/i2c: adv7511: Create a MIPI DSI device > >drm/i2c: adv7511: Use internal timing generator > >drm/i2c: adv7511: Change number of DSI lanes dynamically > >dt-bindings: drm/bridge: Update bindings for ADV7533 > > > > .../bindings/display/bridge/adi,adv7511.txt| 25 +- > > drivers/gpu/drm/i2c/adv7511.c | 539 +++ > > 2 files changed, 476 insertions(+), 88 deletions(-) -- Regards, Laurent Pinchart
[PATCH v3 0/7] drm/i2c: adv7511: ADV7533 support
Hi Archit, On Monday 18 Apr 2016 15:18:30 Archit Taneja wrote: > On 04/17/2016 05:01 PM, Xinliang Liu wrote: > > On 9 March 2016 at 18:57, Archit Taneja wrote: > >> ADV7533 is a DSI to HDMI encoder chip. It's like ADV7511, but with an > >> additional DSI RX block that takes in DSI video mode output. > >> > >> Trying to get this driver merged has had some challenges: > >> > >> - ADV7533 has an I2C control bus, but acts as a DSI peripheral too. > >> After discussions, it was concluded that we'd want to provide an > >> API to create MIPI DSI devices, rather than expose two different > >> interfaces on DT. The first version [1] tried the former approach > >> the second version [2] showed how the driver would look like if > >> exposed 2 DT nodes. This lateset patchset relies on the MIPI DSI > >> device creation API provided by [3], this has been accepted and > >> should be merged for 4.6. > >> > >> - The driver was designed as an I2C slave encoder. When ADV7533 > >> patches were posted [1], it was modelled as a bridge, but ADV7511 > >> and others were still left as I2C slave encoders. This wasn't > >> accepted. After discussions, it was decided that ADV7511 too would > >> be converted into a bridge driver, and all the users of ADV7511 > >> should assume it is a bridge. This bridge conversion was done in > >> [4]. There is still some debate over whether the bridge driver be > >> involved in the connector creation, or the KMS driver that has > >> the whole view of the display pipeline. This discussion shouldn't > >> affect this patch set, though. > > > > I also agree with Laurent Pinchart that bridge driver shoudn't get > > involved in in the connector creation. > > It is better for KMS driver that has the whole view of the display > > pipeline. > > Yes, that's the eventual plan. We were thinking of creating an > additional drm bridge api (drm_bridge_create_connector) that > helps the KMS driver create a connector for the bridge. > > Since there are certain connector related properties that the KMS > driver may not be aware of, we were thinking of creating another > drm_bridge op which fills up connector properties. Some properties > (like whether we want POLLED HPD or not) are more platform specific, > and would be parsed via the connector's DT node (that is, if DT is > supported on that platform) > > For now, this series creates the connector in the bridge's > attach op, but relies on the KMS driver to call > drm_connector_register. The other stuff I mentioned above can come > later. Do you think you'd have time to lead that effort ? > > In this case, I mean creating bridge driver to support ADV7533. I > > think this is something look like panel driver. Maybe we need to add > > some callback to the bridge to avoid creating connector in bridge > > driver. > > We can refer to panel entity to see what callbacks to be added. One > > callback I can see is the get_modes callback might be need. > > > >> This patch set enables ADV7533 support with the above two issues > >> now resolved. It also incorporates ADV7533 specific features and fixes > >> that we've discovered since the first version of this patch was posted. > >> > >> Tested on ADV7533 chips on DB410c. It should work on the Hikey board too. > > > > I have tested the this tracking branch : > > https://git.linaro.org/landing-teams/working/qualcomm/kernel.git/shortlog/ > > refs/heads/tracking-qcomlt-adv7511 it works for HiKey. > > But it seems this patch set is a little different from the above > > branch. I think I need to tested this patch set. > > Yes, it would be great if you could test the posted patch set and > provided a Tested-by. The patches "drm/i2c: adv7511: Init regulators" > and above need to still be applied from this branch. I'll post these > out in another patch set later. > > >> I'd appreaciate if someone could test it on a ADV7511 platform since I > >> don't have one. > >> > >> [4] > >> https://lists.freedesktop.org/archives/dri-devel/2016-January/098287.html > >> [3] > >> https://lkml.org/lkml/2016/2/12/67 > >> [2] > >> https://lists.freedesktop.org/archives/dri-devel/2015-September/089884.ht > >> ml > >> [1]: > >> https://lists.freedesktop.org/archives/dri-devel/2015-July/087088.html > >> > >> Archit Taneja (7): > >>drm/i2c: adv7511: Convert to drm_bridge > >>drm/i2c: adv7511: Fix mutex deadlock when interrupts are disabled > >>drm/i2c: adv7511: Initial support for ADV7533 > >>drm/i2c: adv7511: Create a MIPI DSI device > >>drm/i2c: adv7511: Use internal timing generator > >>drm/i2c: adv7511: Change number of DSI lanes dynamically > >>dt-bindings: drm/bridge: Update bindings for ADV7533 > >> > >> .../bindings/display/bridge/adi,adv7511.txt| 25 +- > >> drivers/gpu/drm/i2c/adv7511.c | 539 ++ > >> 2 files changed, 476 insertions(+), 88 deletions(-) -- Regards, Laurent Pinchart
[PATCH 00/14] Add/update DRM entries in the MAINTAINERS file
Hi all, A bunch of trivial updates for the MAINTAINERS file - corrected files lists, git repos. The last few patches 'nominate' developers who have already been the effective maintainers of the specific drivers. With the final patch we explicitly list the legacy/UMS drivers, as Orphan/Obsolete. Who knows we might get a few volunteers to give them the some love for the first time in ~8 years. Maintainers, Can we get a few acks and get all (most) of them in one go or do you prefer to carry them via your tree ? Thanks Emil Emil Velikov (14): MAINTAINERS: Remove unneded wildcard for the Radeon/AMDGPU drivers MAINTAINERS: Remove unneded wildcard for the i915 DRM driver MAINTAINERS: Update the files list for the Exynos DRM driver MAINTAINERS: Update the files list for the GMA500 DRM driver MAINTAINERS: Update the files list for the Rockchip DRM driver MAINTAINERS: Update the files list for the Etnaviv DRM driver MAINTAINERS: Update the files list for the Armada DRM driver MAINTAINERS: Update the files list for the Renesas DRM drivers MAINTAINERS: List the correct git repo for the Renesas DRM drivers MAINTAINERS: Add maintainer entry for the Nouveau DRM driver MAINTAINERS: Add maintainer entry for the MSM DRM driver MAINTAINERS: Add maintainer entry for the VMWGFX DRM driver MAINTAINERS: Add a few DRM drivers by Dave Airlie MAINTAINERS: Add a bunch of legacy (UMS) DRM drivers MAINTAINERS | 113 ++-- 1 file changed, 102 insertions(+), 11 deletions(-) -- 2.6.2
[PATCH 01/14] MAINTAINERS: Remove unneded wildcard for the Radeon/AMDGPU drivers
There are no other files but the UAPI headers, thus we can drop the wildcard. Cc: Alex Deucher Cc: Christian König Signed-off-by: Emil Velikov --- MAINTAINERS | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/MAINTAINERS b/MAINTAINERS index 1c32f8a..2ac57ac 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -3769,9 +3769,9 @@ L:dri-devel at lists.freedesktop.org T: git git://people.freedesktop.org/~agd5f/linux S: Supported F: drivers/gpu/drm/radeon/ -F: include/uapi/drm/radeon* +F: include/uapi/drm/radeon_drm.h F: drivers/gpu/drm/amd/ -F: include/uapi/drm/amdgpu* +F: include/uapi/drm/amdgpu_drm.h DRM PANEL DRIVERS M: Thierry Reding -- 2.6.2
[PATCH 02/14] MAINTAINERS: Remove unneded wildcard for the i915 DRM driver
There is no other file but the UAPI header, thus we can drop the wildcard. Cc: Daniel Vetter Cc: Jani Nikula Cc: intel-gfx at lists.freedesktop.org Cc: dri-devel at lists.freedesktop.org Signed-off-by: Emil Velikov --- MAINTAINERS | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/MAINTAINERS b/MAINTAINERS index 2ac57ac..08ae19a 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -3794,7 +3794,7 @@ T:git git://anongit.freedesktop.org/drm-intel S: Supported F: drivers/gpu/drm/i915/ F: include/drm/i915* -F: include/uapi/drm/i915* +F: include/uapi/drm/i915_drm.h DRM DRIVERS FOR ATMEL HLCDC M: Boris Brezillon -- 2.6.2
[PATCH 03/14] MAINTAINERS: Update the files list for the Exynos DRM driver
Cc: Inki Dae Cc: Joonyoung Shim Cc: Seung-Woo Kim Cc: Kyungmin Park Cc: dri-devel at lists.freedesktop.org Signed-off-by: Emil Velikov --- MAINTAINERS | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/MAINTAINERS b/MAINTAINERS index 08ae19a..17dc561 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -3812,8 +3812,8 @@ L:dri-devel at lists.freedesktop.org T: git git://git.kernel.org/pub/scm/linux/kernel/git/daeinki/drm-exynos.git S: Supported F: drivers/gpu/drm/exynos/ -F: include/drm/exynos* -F: include/uapi/drm/exynos* +F: include/uapi/drm/exynos_drm.h +F: Documentation/devicetree/bindings/display/exynos/ DRM DRIVERS FOR FREESCALE DCU M: Stefan Agner -- 2.6.2
[PATCH 04/14] MAINTAINERS: Update the files list for the GMA500 DRM driver
Cc: Patrik Jakobsson Cc: dri-devel at lists.freedesktop.org Signed-off-by: Emil Velikov --- MAINTAINERS | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/MAINTAINERS b/MAINTAINERS index 17dc561..205b3c1 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -3837,8 +3837,7 @@ M:Patrik Jakobsson L: dri-devel at lists.freedesktop.org T: git git://github.com/patjak/drm-gma500 S: Maintained -F: drivers/gpu/drm/gma500 -F: include/drm/gma500* +F: drivers/gpu/drm/gma500/ DRM DRIVERS FOR NVIDIA TEGRA M: Thierry Reding -- 2.6.2
[PATCH 05/14] MAINTAINERS: Update the files list for the Rockchip DRM driver
The location listed is a folder - swap the wildcard with '/' Cc: Mark Yao Cc: dri-devel at lists.freedesktop.org Signed-off-by: Emil Velikov --- MAINTAINERS | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/MAINTAINERS b/MAINTAINERS index 205b3c1..9df1555 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -3867,7 +3867,7 @@ M:Mark Yao L: dri-devel at lists.freedesktop.org S: Maintained F: drivers/gpu/drm/rockchip/ -F: Documentation/devicetree/bindings/display/rockchip* +F: Documentation/devicetree/bindings/display/rockchip/ DRM DRIVERS FOR STI M: Benjamin Gaignard -- 2.6.2
[PATCH 06/14] MAINTAINERS: Update the files list for the Etnaviv DRM driver
Cc: Lucas Stach Cc: Russell King Cc: Christian Gmeiner Cc: dri-devel at lists.freedesktop.org Signed-off-by: Emil Velikov --- MAINTAINERS | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/MAINTAINERS b/MAINTAINERS index 9df1555..47a09fe 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -3884,8 +3884,9 @@ R:Russell King R: Christian Gmeiner L: dri-devel at lists.freedesktop.org S: Maintained -F: drivers/gpu/drm/etnaviv -F: Documentation/devicetree/bindings/display/etnaviv +F: drivers/gpu/drm/etnaviv/ +F: include/uapi/drm/etnaviv_drm.h +F: Documentation/devicetree/bindings/display/etnaviv/ DSBR100 USB FM RADIO DRIVER M: Alexey Klimov -- 2.6.2
[PATCH 07/14] MAINTAINERS: Update the files list for the Armada DRM driver
Cc: Russell King Cc: dri-devel at lists.freedesktop.org Signed-off-by: Emil Velikov --- MAINTAINERS | 2 ++ 1 file changed, 2 insertions(+) diff --git a/MAINTAINERS b/MAINTAINERS index 47a09fe..f759b53 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -6908,6 +6908,8 @@ MARVELL ARMADA DRM SUPPORT M: Russell King S: Maintained F: drivers/gpu/drm/armada/ +F: include/uapi/drm/armada_drm.h +F: Documentation/devicetree/bindings/display/armada/ MARVELL 88E6352 DSA support M: Guenter Roeck -- 2.6.2
[PATCH 08/14] MAINTAINERS: Update the files list for the Renesas DRM drivers
Cc: Laurent Pinchart Cc: dri-devel at lists.freedesktop.org Cc: linux-renesas-soc at vger.kernel.org Signed-off-by: Emil Velikov --- MAINTAINERS | 1 + 1 file changed, 1 insertion(+) diff --git a/MAINTAINERS b/MAINTAINERS index f759b53..776d614 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -3861,6 +3861,7 @@ S:Supported F: drivers/gpu/drm/rcar-du/ F: drivers/gpu/drm/shmobile/ F: include/linux/platform_data/shmob_drm.h +F: Documentation/devicetree/bindings/display/renesas,du.txt DRM DRIVERS FOR ROCKCHIP M: Mark Yao -- 2.6.2
[PATCH 09/14] MAINTAINERS: List the correct git repo for the Renesas DRM drivers
Cc: Laurent Pinchart Cc: dri-devel at lists.freedesktop.org Cc: linux-renesas-soc at vger.kernel.org Signed-off-by: Emil Velikov --- MAINTAINERS | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/MAINTAINERS b/MAINTAINERS index 776d614..b9eddf1 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -3856,7 +3856,7 @@ DRM DRIVERS FOR RENESAS M: Laurent Pinchart L: dri-devel at lists.freedesktop.org L: linux-renesas-soc at vger.kernel.org -T: git git://people.freedesktop.org/~airlied/linux +T: git git://linuxtv.org/pinchartl/fbdev S: Supported F: drivers/gpu/drm/rcar-du/ F: drivers/gpu/drm/shmobile/ -- 2.6.2
[PATCH 10/14] MAINTAINERS: Add maintainer entry for the Nouveau DRM driver
Ben has been the maintainer of the driver even before it got included in the kernel. Cc: Ben Skeggs Cc: Dave Airlie Signed-off-by: Emil Velikov --- MAINTAINERS | 9 + 1 file changed, 9 insertions(+) diff --git a/MAINTAINERS b/MAINTAINERS index b9eddf1..c81e02d 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -3839,6 +3839,15 @@ T: git git://github.com/patjak/drm-gma500 S: Maintained F: drivers/gpu/drm/gma500/ +DRM DRIVER FOR NVIDIA GEFORCE/QUADRO GPUS +M: Ben Skeggs +L: dri-devel at lists.freedesktop.org +L: nouveau at lists.freedesktop.org +T: git git://github.com/skeggsb/linux +S: Supported +F: drivers/gpu/drm/nouveau/ +F: include/uapi/drm/nouveau_drm.h + DRM DRIVERS FOR NVIDIA TEGRA M: Thierry Reding M: Terje Bergström -- 2.6.2
[PATCH 11/14] MAINTAINERS: Add maintainer entry for the MSM DRM driver
Rob and Archit are the main developers behind the driver. Cc: Rob Clark Cc: Archit Taneja Signed-off-by: Emil Velikov --- Archit, I believe Rob is the maintainer atm, although considering the amazing work that you've been doing for MSM and DRM in general, I think it's worth adding you as well. I can see that you're contributing as part of your job, right ? So should we use Supported here ? --- MAINTAINERS | 11 +++ 1 file changed, 11 insertions(+) diff --git a/MAINTAINERS b/MAINTAINERS index c81e02d..da88d74 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -3839,6 +3839,17 @@ T: git git://github.com/patjak/drm-gma500 S: Maintained F: drivers/gpu/drm/gma500/ +DRM DRIVER FOR MSM ADRENO GPU +M: Rob Clark +M: Archit Taneja +L: dri-devel at lists.freedesktop.org +L: freedreno at lists.freedesktop.org +T: git git://people.freedesktop.org/~robclark/linux +S: Maintained / Supported +F: drivers/gpu/drm/msm/ +F: include/uapi/drm/msm_drm.h +F: Documentation/devicetree/bindings/display/msm/ + DRM DRIVER FOR NVIDIA GEFORCE/QUADRO GPUS M: Ben Skeggs L: dri-devel at lists.freedesktop.org -- 2.6.2
[PATCH 12/14] MAINTAINERS: Add maintainer entry for the VMWGFX DRM driver
Thomas is one of the original authors of the driver, with recent contributions from Sinclair and Brian. Cc: Sinclair Yeh Cc: Thomas Hellstrom Cc: Brian Paul Cc: "VMware Graphics" Signed-off-by: Emil Velikov --- Gents can anyone confirm if the data is correct ? I'm thinking that the status should be Supported, although the driver hasn't see much action recently. NOTE: The following email linux-graphics-maintainer at vmware.com is also listed for the VMMOUSE driver. Is that correct ? --- MAINTAINERS | 8 1 file changed, 8 insertions(+) diff --git a/MAINTAINERS b/MAINTAINERS index da88d74..e8ad8b1 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -3909,6 +3909,14 @@ F: drivers/gpu/drm/etnaviv/ F: include/uapi/drm/etnaviv_drm.h F: Documentation/devicetree/bindings/display/etnaviv/ +DRM DRIVER FOR VMWARE VIRTUAL GPU +M: "VMware Graphics" +M: Thomas Hellstrom +L: dri-devel at lists.freedesktop.org +S: Maintained / Supported +F: drivers/gpu/drm/vmwgfx/ +F: include/uapi/drm/vmwgfx_drm.h + DSBR100 USB FM RADIO DRIVER M: Alexey Klimov L: linux-media at vger.kernel.org -- 2.6.2
[PATCH 13/14] MAINTAINERS: Add a few DRM drivers by Dave Airlie
Almost exclusively done by Dave Airlie. Explicitly list him as a maintainer and classify them as "Odd Fixes" as I doubt he's got much time for them these days. Cc: Dave Airlie Signed-off-by: Emil Velikov --- Dave, please correct me if I got it wrong. --- MAINTAINERS | 31 +++ 1 file changed, 31 insertions(+) diff --git a/MAINTAINERS b/MAINTAINERS index e8ad8b1..3774081 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -3762,6 +3762,21 @@ F: drivers/gpu/vga/ F: include/drm/ F: include/uapi/drm/ +DRM DRIVER FOR AST SERVER GRAPHICS CHIPS +M: Dave Airlie +S: Odd Fixes +F: drivers/gpu/drm/ast/ + +DRM DRIVER FOR BOCHS VIRTUAL GPU +M: Gerd Hoffmann +S: Odd Fixes +F: drivers/gpu/drm/bochs/ + +DRM DRIVER FOR QEMU'S CIRRUS DEVICE +M: Dave Airlie +S: Odd Fixes +F: drivers/gpu/drm/cirrus/ + RADEON and AMDGPU DRM DRIVERS M: Alex Deucher M: Christian König @@ -3872,6 +3887,11 @@ F: include/linux/host1x.h F: include/uapi/drm/tegra_drm.h F: Documentation/devicetree/bindings/display/tegra/nvidia,tegra20-host1x.txt +DRM DRIVER FOR MGA G200 SERVER GRAPHICS CHIPS +M: Dave Airlie +S: Odd Fixes +F: drivers/gpu/drm/mgag200/ + DRM DRIVERS FOR RENESAS M: Laurent Pinchart L: dri-devel at lists.freedesktop.org @@ -3883,6 +3903,12 @@ F: drivers/gpu/drm/shmobile/ F: include/linux/platform_data/shmob_drm.h F: Documentation/devicetree/bindings/display/renesas,du.txt +DRM DRIVER FOR QXL VIRTUAL GPU +M: Dave Airlie +S: Odd Fixes +F: drivers/gpu/drm/qxl/ +F: include/uapi/drm/qxl_drm.h + DRM DRIVERS FOR ROCKCHIP M: Mark Yao L: dri-devel at lists.freedesktop.org @@ -3899,6 +3925,11 @@ S: Maintained F: drivers/gpu/drm/sti F: Documentation/devicetree/bindings/display/st,stih4xx.txt +DRM DRIVER FOR USB DISPLAYLINK VIDEO ADAPTERS +M: Dave Airlie +S: Odd Fixes +F: drivers/gpu/drm/udl/ + DRM DRIVERS FOR VIVANTE GPU IP M: Lucas Stach R: Russell King -- 2.6.2
[PATCH 14/14] MAINTAINERS: Add a bunch of legacy (UMS) DRM drivers
Pretty much all of these hasn't seen any action singe 2008 at the very least. Barring the occasional buildfix and DRM-wide refactoring of course. Note: some distributions have stopped shipping their userspace counterparts for a while. Although some still do. Signed-off-by: Emil Velikov --- I'm inclined to list these as Obsolete, yet that implies that there's something better in the works, yet there isn't. I believe many people will be happy to see these drivers go, although I doubt interested parties are about to port them to KMS/DRI2 unless we make some noise. Like, say, propose their removal ? ;-) --- MAINTAINERS | 29 + 1 file changed, 29 insertions(+) diff --git a/MAINTAINERS b/MAINTAINERS index 3774081..c808542 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -3854,6 +3854,11 @@ T: git git://github.com/patjak/drm-gma500 S: Maintained F: drivers/gpu/drm/gma500/ +DRM DRIVER FOR INTEL I810 VIDEO CARDS +S: Orphan / Obsolete +F: drivers/gpu/drm/i810/ +F: include/uapi/drm/i810_drm.h + DRM DRIVER FOR MSM ADRENO GPU M: Rob Clark M: Archit Taneja @@ -3887,11 +3892,21 @@ F: include/linux/host1x.h F: include/uapi/drm/tegra_drm.h F: Documentation/devicetree/bindings/display/tegra/nvidia,tegra20-host1x.txt +DRM DRIVER FOR MATROX G200/G400 GRAPHICS CARDS +S: Orphan / Obsolete +F: drivers/gpu/drm/mga/ +F: include/uapi/drm/mga_drm.h + DRM DRIVER FOR MGA G200 SERVER GRAPHICS CHIPS M: Dave Airlie S: Odd Fixes F: drivers/gpu/drm/mgag200/ +DRM DRIVER FOR RAGE 128 VIDEO CARDS +S: Orphan / Obsolete +F: drivers/gpu/drm/r128/ +F: include/uapi/drm/r128_drm.h + DRM DRIVERS FOR RENESAS M: Laurent Pinchart L: dri-devel at lists.freedesktop.org @@ -3916,6 +3931,16 @@ S: Maintained F: drivers/gpu/drm/rockchip/ F: Documentation/devicetree/bindings/display/rockchip/ +DRM DRIVER FOR SAVAGE VIDEO CARDS +S: Orphan / Obsolete +F: drivers/gpu/drm/savage/ +F: include/uapi/drm/savage_drm.h + +DRM DRIVER FOR SIS VIDEO CARDS +S: Orphan / Obsolete +F: drivers/gpu/drm/sis/ +F: include/uapi/drm/sis_drm.h + DRM DRIVERS FOR STI M: Benjamin Gaignard M: Vincent Abriou @@ -3925,6 +3950,10 @@ S: Maintained F: drivers/gpu/drm/sti F: Documentation/devicetree/bindings/display/st,stih4xx.txt +DRM DRIVER FOR TDFX VIDEO CARDS +S: Orphan / Obsolete +F: drivers/gpu/drm/tdfx/ + DRM DRIVER FOR USB DISPLAYLINK VIDEO ADAPTERS M: Dave Airlie S: Odd Fixes -- 2.6.2
[pull] radeon and amdgpu drm-fixes-4.6
On 21 April 2016 at 02:05, Alex Deucher wrote: > Hi Dave, > > Misc radeon and amdgpu bug fixes for 4.6. The big change is a patch > to fix possible display problems on NI and newer parts when reprogramming > the mc when DP is in use. > > The following changes since commit ff3e84e8e479c3ba7148f8dc35a56cf091ab56d9: > > Merge branch 'exynos-drm-fixes' of > git://git.kernel.org/pub/scm/linux/kernel/git/daeinki/drm-exynos into > drm-fixes (2016-04-14 13:06:19 +1000) > > are available in the git repository at: > > git://people.freedesktop.org/~agd5f/linux drm-fixes-4.6 > > for you to fetch changes up to e030c67f21803c8b03e9a50f70742312dceb2a78: > > amdgpu/uvd: add uvd fw version for amdgpu (2016-04-20 11:46:10 -0400) > > > Alex Deucher (8): > drm/radeon: fix initial connector audio value > drm/radeon: print pci revision as well as pci ids on driver load > drm/radeon: add a quirk for a XFX R9 270X > drm/amdgpu/acp: fix resume on CZ systems with AZ audio > Revert "drm/radeon: disable runtime pm on PX laptops without dGPU power > control" > drm/radeon: print a message if ATPX dGPU power control is missing > drm/amdgpu: use defines for CRTCs and AMFT blocks > drm/amdgpu: bump the afmt limit for CZ, ST, Polaris > > Jérôme Glisse (2): > drm/radeon: forbid mapping of userptr bo through radeon device file > drm/amdgpu: forbid mapping of userptr bo through radeon device file > > Rex Zhu (1): > drm/amdgpu: when suspending, if uvd/vce was running. need to cancel > delay work. > > Sonny Jiang (1): > amdgpu/uvd: add uvd fw version for amdgpu > > Vitaly Prosyak (1): > drm/radeon: fix vertical bars appear on monitor While I'm sure this patch fixes a problem, it's pretty ugly, checkpatch doesn't like it, and it fails coding standards by a long way and I haven't seen it on the list. So no for this one just yet. Dave.
[PATCH] drm/radeon: add cayman VM support for append packet.
From: Dave Airlie
This adds support for SET_APPEND_CNT packet3 to the VM paths.
Signed-off-by: Dave Airlie
---
drivers/gpu/drm/radeon/evergreen_cs.c | 21 +
1 file changed, 21 insertions(+)
diff --git a/drivers/gpu/drm/radeon/evergreen_cs.c
b/drivers/gpu/drm/radeon/evergreen_cs.c
index 18ddd75..0d3f744 100644
--- a/drivers/gpu/drm/radeon/evergreen_cs.c
+++ b/drivers/gpu/drm/radeon/evergreen_cs.c
@@ -3483,6 +3483,27 @@ static int evergreen_vm_packet3_check(struct
radeon_device *rdev,
}
}
break;
+ case PACKET3_SET_APPEND_CNT: {
+ uint32_t areg;
+ uint32_t allowed_reg_base;
+
+ if (pkt->count != 2) {
+ DRM_ERROR("bad SET_APPEND_CNT (invalid count)\n");
+ return -EINVAL;
+ }
+
+ allowed_reg_base = GDS_APPEND_COUNT_0;
+ allowed_reg_base -= PACKET3_SET_CONTEXT_REG_START;
+ allowed_reg_base >>= 2;
+
+ areg = idx_value >> 16;
+ if (areg < allowed_reg_base || areg > (allowed_reg_base + 11)) {
+ DRM_ERROR("forbidden register for append cnt 0x%08x at
%d\n",
+ areg, idx);
+ return -EINVAL;
+ }
+ break;
+ }
default:
return -EINVAL;
}
--
2.1.0
[patch] drm/rockchip: inno_hdmi: fix an error code
On 2016å¹´04æ21æ¥ 22:03, Dan Carpenter wrote:
> On Fri, Feb 26, 2016 at 02:26:23PM +0800, Yakir Yang wrote:
>> Dan,
>>
>> On 02/26/2016 05:30 AM, Dan Carpenter wrote:
>>> We were accidentally returning PTR_ERR(NULL) which means success when we
>>> wanted to return a negative error code.
>>>
>>> Fixes: 412d4ae6b7a5 ('drm/rockchip: hdmi: add Innosilicon HDMI support')
>>> Signed-off-by: Dan Carpenter
>> Reviewed-by: Yakir Yang
> We still need to apply this.
>
> regards,
> dan carpenter
>
>
>
>
Oh, Sorry, Miss this patch.
Applied to my drm-fixes.
Thanks.
--
ï¼ark Yao
[pull] radeon and amdgpu drm-fixes-4.6
> -Original Message- > From: Dave Airlie [mailto:airlied at gmail.com] > Sent: Thursday, April 21, 2016 7:52 PM > To: Alex Deucher > Cc: dri-devel; Deucher, Alexander > Subject: Re: [pull] radeon and amdgpu drm-fixes-4.6 > > On 21 April 2016 at 02:05, Alex Deucher wrote: > > Hi Dave, > > > > Misc radeon and amdgpu bug fixes for 4.6. The big change is a patch > > to fix possible display problems on NI and newer parts when > reprogramming > > the mc when DP is in use. > > > > The following changes since commit > ff3e84e8e479c3ba7148f8dc35a56cf091ab56d9: > > > > Merge branch 'exynos-drm-fixes' of > git://git.kernel.org/pub/scm/linux/kernel/git/daeinki/drm-exynos into drm- > fixes (2016-04-14 13:06:19 +1000) > > > > are available in the git repository at: > > > > git://people.freedesktop.org/~agd5f/linux drm-fixes-4.6 > > > > for you to fetch changes up to > e030c67f21803c8b03e9a50f70742312dceb2a78: > > > > amdgpu/uvd: add uvd fw version for amdgpu (2016-04-20 11:46:10 -0400) > > > > > > Alex Deucher (8): > > drm/radeon: fix initial connector audio value > > drm/radeon: print pci revision as well as pci ids on driver load > > drm/radeon: add a quirk for a XFX R9 270X > > drm/amdgpu/acp: fix resume on CZ systems with AZ audio > > Revert "drm/radeon: disable runtime pm on PX laptops without dGPU > power control" > > drm/radeon: print a message if ATPX dGPU power control is missing > > drm/amdgpu: use defines for CRTCs and AMFT blocks > > drm/amdgpu: bump the afmt limit for CZ, ST, Polaris > > > > Jérôme Glisse (2): > > drm/radeon: forbid mapping of userptr bo through radeon device file > > drm/amdgpu: forbid mapping of userptr bo through radeon device file > > > > Rex Zhu (1): > > drm/amdgpu: when suspending, if uvd/vce was running. need to cancel > delay work. > > > > Sonny Jiang (1): > > amdgpu/uvd: add uvd fw version for amdgpu > > > > Vitaly Prosyak (1): > > drm/radeon: fix vertical bars appear on monitor > > While I'm sure this patch fixes a problem, it's pretty ugly, > checkpatch doesn't like it, > and it fails coding standards by a long way and I haven't seen it on the list. > > So no for this one just yet. Updated request at the same URL. Alex > > Dave.
[git pull] drm fixes
Hi Linus, i915, nouveau and amdgpu/radeon fixes in this. Two nouveau fixes, one for a regression with dithering and one for a bug hit by the userspace drivers. i915 has a few fixes, mostly things heading for stable, two important skylake GT3/4 hangs. radeon/amdgpu has some audio, suspend/resume and some runtime PM fixes, along with two patches to harden the userptr ABI a bit. Thanks, (Since this only contained one other capital letter, I decided to add one here.) Dave. The following changes since commit 5f44abd041c5f3be76d57579ab254d78e601315b: Merge tag 'rtc-4.6-3' of git://git.kernel.org/pub/scm/linux/kernel/git/abelloni/linux (2016-04-21 15:41:13 -0700) are available in the git repository at: git://people.freedesktop.org/~airlied/linux drm-fixes for you to fetch changes up to 18cdfe751f26ffa610f2a7b59775c5cc4c1c9619: Merge branch 'drm-fixes-4.6' of git://people.freedesktop.org/~agd5f/linux into drm-fixes (2016-04-22 10:39:26 +1000) Akash Goel (1): drm/i915: Fixup the free space logic in ring_prepare Alex Deucher (8): drm/radeon: fix initial connector audio value drm/radeon: print pci revision as well as pci ids on driver load drm/radeon: add a quirk for a XFX R9 270X drm/amdgpu/acp: fix resume on CZ systems with AZ audio Revert "drm/radeon: disable runtime pm on PX laptops without dGPU power control" drm/radeon: print a message if ATPX dGPU power control is missing drm/amdgpu: use defines for CRTCs and AMFT blocks drm/amdgpu: bump the afmt limit for CZ, ST, Polaris Ben Skeggs (2): drm/nouveau/kms: fix setting of default values for dithering properties drm/nouveau/gr/gf100: select a stream master to fixup tfb offset queries Chris Wilson (2): drm/i915/userptr: Hold mmref whilst calling get-user-pages drm/i915: Force ringbuffers to not be at offset 0 Dave Airlie (4): Merge tag 'drm-intel-fixes-2016-04-21' of git://anongit.freedesktop.org/drm-intel into drm-fixes Merge branch 'linux-4.6' of git://github.com/skeggsb/linux into drm-fixes Merge branch 'linux-4.6' of git://github.com/skeggsb/linux into drm-fixes Merge branch 'drm-fixes-4.6' of git://people.freedesktop.org/~agd5f/linux into drm-fixes Huacai Chen (1): drm: Loongson-3 doesn't fully support wc memory Jérôme Glisse (2): drm/radeon: forbid mapping of userptr bo through radeon device file drm/amdgpu: forbid mapping of userptr bo through radeon device file Kumar, Mahesh (1): drm/i915/skl+: Use plane size for relative data rate calculation MichaŠWiniarski (1): drm/i915: Adjust size of PIPE_CONTROL used for gen8 render seqno write Mika Kuoppala (2): drm/i915/skl: Fix rc6 based gpu/system hang drm/i915/skl: Fix spurious gpu hang with gt3/gt4 revs Rex Zhu (1): drm/amdgpu: when suspending, if uvd/vce was running. need to cancel delay work. Sonny Jiang (1): amdgpu/uvd: add uvd fw version for amdgpu Ville Syrjälä (1): drm/i915: Use fw_domains_put_with_fifo() on HSW cpaul at redhat.com (1): drm/dp/mst: Validate port in drm_dp_payload_send_msg() drivers/gpu/drm/amd/amdgpu/amdgpu.h| 1 + drivers/gpu/drm/amd/amdgpu/amdgpu_acp.c| 4 +++ drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c| 2 +- drivers/gpu/drm/amd/amdgpu/amdgpu_mode.h | 6 ++-- drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c| 2 ++ drivers/gpu/drm/amd/amdgpu/amdgpu_uvd.c| 5 +++ drivers/gpu/drm/amd/amdgpu/amdgpu_vce.c| 1 + drivers/gpu/drm/drm_dp_mst_topology.c | 9 +- drivers/gpu/drm/i915/i915_drv.h| 5 +-- drivers/gpu/drm/i915/i915_gem_userptr.c| 29 ++ drivers/gpu/drm/i915/intel_lrc.c | 16 +++--- drivers/gpu/drm/i915/intel_pm.c| 42 +- drivers/gpu/drm/i915/intel_ringbuffer.c| 18 ++- drivers/gpu/drm/i915/intel_uncore.c| 6 +++- drivers/gpu/drm/nouveau/nouveau_connector.c| 4 +-- drivers/gpu/drm/nouveau/nvkm/engine/gr/gf100.c | 2 ++ drivers/gpu/drm/radeon/radeon_atpx_handler.c | 11 --- drivers/gpu/drm/radeon/radeon_connectors.c | 7 - drivers/gpu/drm/radeon/radeon_device.c | 14 +++-- drivers/gpu/drm/radeon/radeon_ttm.c| 2 ++ drivers/gpu/drm/radeon/si_dpm.c| 1 + include/drm/drm_cache.h| 2 ++ 22 files changed, 126 insertions(+), 63 deletions(-)
[PATCH 5/9] drm/i915: Enable i915 perf stream for Haswell OA unit
On Thu, Apr 21, 2016 at 4:18 PM, Robert Bragg wrote:
>
>
> On Thu, Apr 21, 2016 at 12:09 AM, Chris Wilson
> wrote:
>
>> On Wed, Apr 20, 2016 at 03:23:10PM +0100, Robert Bragg wrote:
>> > +static void i915_oa_stream_enable(struct i915_perf_stream *stream)
>> > +{
>> > + struct drm_i915_private *dev_priv = stream->dev_priv;
>> > +
>> > + dev_priv->perf.oa.ops.oa_enable(dev_priv);
>> > +
>> > + if (dev_priv->perf.oa.periodic)
>> > + hrtimer_start(&dev_priv->perf.oa.poll_check_timer,
>> > + ns_to_ktime(POLL_PERIOD),
>> > + HRTIMER_MODE_REL_PINNED);
>> > +}
>>
>> > +static void i915_oa_stream_disable(struct i915_perf_stream *stream)
>> > +{
>> > + struct drm_i915_private *dev_priv = stream->dev_priv;
>> > +
>> > + dev_priv->perf.oa.ops.oa_disable(dev_priv);
>> > +
>> > + if (dev_priv->perf.oa.periodic)
>> > + hrtimer_cancel(&dev_priv->perf.oa.poll_check_timer);
>> > +}
>>
>> > +static enum hrtimer_restart oa_poll_check_timer_cb(struct hrtimer
>> *hrtimer)
>> > +{
>> > + struct drm_i915_private *dev_priv =
>> > + container_of(hrtimer, typeof(*dev_priv),
>> > + perf.oa.poll_check_timer);
>> > +
>> > + if (!dev_priv->perf.oa.ops.oa_buffer_is_empty(dev_priv))
>> > + wake_up(&dev_priv->perf.oa.poll_wq);
>> > +
>> > + hrtimer_forward_now(hrtimer, ns_to_ktime(POLL_PERIOD));
>> > +
>> > + return HRTIMER_RESTART;
>> > +}
>>
>> > @@ -424,8 +1313,37 @@ void i915_perf_init(struct drm_device *dev)
>> > {
>> > struct drm_i915_private *dev_priv = to_i915(dev);
>> >
>> > + if (!IS_HASWELL(dev))
>> > + return;
>> > +
>> > + hrtimer_init(&dev_priv->perf.oa.poll_check_timer,
>> > + CLOCK_MONOTONIC, HRTIMER_MODE_REL);
>> > + dev_priv->perf.oa.poll_check_timer.function =
>> oa_poll_check_timer_cb;
>> > + init_waitqueue_head(&dev_priv->perf.oa.poll_wq);
>>
>> This timer only serves to wake up pollers / wait_unlocked, right? So why
>> is it always running (when the stream is enabled)?
>>
>>
> Right, it's unecessary. I'll look at limitting it to just while polling or
> for blocking reads.
>
Actually, looking at this, I couldn't see a clean way to synchronized with
do_sys_poll() returning to be able to cancel the hrtimer. The .poll fop is
only responsible for registering a wait queue via poll_wait() and checking
if there are already events pending before any wait.
The current hrtimer frequency was picked as a reasonable default to ensure
we pick up samples before an overflow with high frequency OA sampling but
also avoids latency in picking up samples written at a lower frequency.
Something I've considered a few times before is that we might want to add a
property that can influence the latency userspace is happy with, which
might also alieviate some of this concern that the hrtimer runs all the
time the stream is enabled when it could often be fine to run at a much
lower frequency than the current 200Hz.
For now, maybe it's ok to stick with the fixed frequency, and I'll plan to
experiment with a property for influencing the maximum latency?
Regards,
- Robert
-- next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160422/9a0f26f5/attachment.html>
[Bug 95058] When monitors sleep, backlights stay on, screen is black, and can't be woke up
https://bugs.freedesktop.org/show_bug.cgi?id=95058 Bug ID: 95058 Summary: When monitors sleep, backlights stay on, screen is black, and can't be woke up Product: DRI Version: XOrg git Hardware: x86-64 (AMD64) OS: Linux (All) Status: NEW Severity: normal Priority: medium Component: DRM/AMDgpu Assignee: dri-devel at lists.freedesktop.org Reporter: Espionage724 at gmail.com I use 3 monitors. I leave, come back, and my monitors are on, but all of them show a black background. Mouse cursor doesn't show, and trying to switch to TTY doesn't work. Keyboard caps lock light doesn't toggle. REISUB magic keys work to reboot the system. I'm using a R9 380 (MSI GAMING 4G) with AMDGPU, a GIGABYTE GA-990FX-Gaming motherboard, FX-8350, and a 750W Corsair PSU. I'm using Xubuntu 16.04 (4.4.0-21-generic; default kernel) and use padoka-PPA (DRI3, TearFree, sisched, forcedma). This has happened only after I got the R9 380 about a week or so ago. I've ran a Radeon HD 7850 prior to that on the same set-up (only with radeon instead of amdgpu) and haven't had this happen. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20160422/c8e8a201/attachment.html>
[PATCH v3 4/7] drm/i2c: adv7511: Create a MIPI DSI device
Hi Laurent,
On 04/22/2016 03:59 AM, Laurent Pinchart wrote:
> Hi Archit,
>
> Thank you for the patch.
>
> On Wednesday 09 Mar 2016 16:27:15 Archit Taneja wrote:
>> In order to pass DSI specific parameters to the DSI host, we need the
>> driver to create a mipi_dsi_device DSI device that attaches to the
>> host.
>>
>> Use of_graph helpers to get the DSI host DT node. Create a MIPI DSI
>> device using this host. Finally, attach this device to the DSI host.
>>
>> Populate DT parameters (number of data lanes for now) that are required
>> for DSI RX to work correctly. Hardcode few other parameters (rgb,
>> embedded_sync) for now.
>>
>> Signed-off-by: Archit Taneja
>
> This adds a hard dependency on CONFIG_DRM_MIPI_DSI, otherwise the kernel won't
> link. As the ADV7511 doesn't require DSI, could you make it optional with
> conditional compilation to avoid pulling in dead code ?
You're right. The driver's Kconfig should at least select DRM_MIPI_DSI
in the current state to make sure we don't break build.
Do you suggest we create another config option for ADV7533, which
selects DRM_MIPI_DSI and builds the ADV7533 parts? Or did you mean
something else?
Thanks for the review.
Archit
>
>> ---
>> drivers/gpu/drm/i2c/adv7511.c | 130 ---
>> 1 file changed, 123 insertions(+), 7 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/i2c/adv7511.c b/drivers/gpu/drm/i2c/adv7511.c
>> index 75be17c..6c2a89a 100644
>> --- a/drivers/gpu/drm/i2c/adv7511.c
>> +++ b/drivers/gpu/drm/i2c/adv7511.c
>> @@ -11,6 +11,7 @@
>> #include
>> #include
>> #include
>> +#include
>> #include
>> #include
>>
>> @@ -19,6 +20,7 @@
>> #include
>> #include
>> #include
>> +#include
>>
>> #include "adv7511.h"
>>
>> @@ -56,6 +58,11 @@ struct adv7511 {
>>
>> struct gpio_desc *gpio_pd;
>>
>> +/* ADV7533 DSI RX related params */
>> +struct device_node *host_node;
>> +struct mipi_dsi_device *dsi;
>> +u8 num_dsi_lanes;
>> +
>> enum adv7511_type type;
>> };
>>
>> @@ -392,8 +399,10 @@ static void adv7511_set_link_config(struct adv7511
>> *adv7511,
>>
>> static void adv7533_dsi_power_on(struct adv7511 *adv)
>> {
>> -/* set number of dsi lanes (hardcoded to 4 for now) */
>> -regmap_write(adv->regmap_cec, 0x1c, 0x4 << 4);
>> +struct mipi_dsi_device *dsi = adv->dsi;
>> +
>> +/* set number of dsi lanes */
>> +regmap_write(adv->regmap_cec, 0x1c, dsi->lanes << 4);
>> /* disable internal timing generator */
>> regmap_write(adv->regmap_cec, 0x27, 0x0b);
>> /* enable hdmi */
>> @@ -889,6 +898,51 @@ static void adv7511_bridge_mode_set(struct drm_bridge
>> *bridge, adv7511_mode_set(adv, mode, adj_mode);
>> }
>>
>> +static int adv7533_attach_dsi(struct adv7511 *adv)
>> +{
>> +struct device *dev = &adv->i2c_main->dev;
>> +struct mipi_dsi_host *host;
>> +struct mipi_dsi_device *dsi;
>> +int ret = 0;
>> +const struct mipi_dsi_device_info info = { .type = "adv7533",
>> + .channel = 0,
>> + .node = NULL,
>> + };
>> +
>> +host = of_find_mipi_dsi_host_by_node(adv->host_node);
>> +if (!host) {
>> +dev_err(dev, "failed to find dsi host\n");
>> +return -EPROBE_DEFER;
>> +}
>> +
>> +dsi = mipi_dsi_device_register_full(host, &info);
>> +if (IS_ERR(dsi)) {
>> +dev_err(dev, "failed to create dsi device\n");
>> +ret = PTR_ERR(dsi);
>> +goto err_dsi_device;
>> +}
>> +
>> +adv->dsi = dsi;
>> +
>> +dsi->lanes = adv->num_dsi_lanes;
>> +dsi->format = MIPI_DSI_FMT_RGB888;
>> +dsi->mode_flags = MIPI_DSI_MODE_VIDEO | MIPI_DSI_MODE_VIDEO_SYNC_PULSE |
>> + MIPI_DSI_MODE_EOT_PACKET | MIPI_DSI_MODE_VIDEO_HSE;
>> +
>> +ret = mipi_dsi_attach(dsi);
>> +if (ret < 0) {
>> +dev_err(dev, "failed to attach dsi to host\n");
>> +goto err_dsi_attach;
>> +}
>> +
>> +return 0;
>> +
>> +err_dsi_attach:
>> +mipi_dsi_device_unregister(dsi);
>> +err_dsi_device:
>> +return ret;
>> +}
>> +
>> static int adv7511_bridge_attach(struct drm_bridge *bridge)
>> {
>> struct adv7511 *adv = bridge_to_adv7511(bridge);
>> @@ -912,6 +966,9 @@ static int adv7511_bridge_attach(struct drm_bridge
>> *bridge) &adv7511_connector_helper_funcs);
>> drm_mode_connector_attach_encoder(&adv->connector, bridge->encoder);
>>
>> +if (adv->type == ADV7533)
>> +ret = adv7533_attach_dsi(adv);
>> +
>> return ret;
>> }
>>
>> @@ -1009,6 +1066,41 @@ static int adv7511_parse_dt(struct device_node *np,
>> return 0;
>> }
>>
>> +static int adv7533_parse_dt(struct device_node *np, struct adv7511 *adv)
>> +{
>> +u32 num_lanes;
>> +struct device_node *endpoint;
>> +
>> +of_property_read_u32(np, "adi,dsi-lanes", &num_lanes);
>> +
>> +if (num_lanes <
[PATCH] drm/exynos/hdmi: Don't print error on deferral due to regulators
On 04/21/2016 08:51 PM, Javier Martinez Canillas wrote: > The regulators may not be available just because their driver's probe > function was just not executed and so the regulators not registered. > > So, in this case the Exynos HDMI driver should not print logs since > a -EPROBE_DEFER is not really an error and that will just pollute > the kernel log and confuse users. > > This patch prevents the following misleading messages to be printed: > > [1.443638] [drm:hdmi_probe] *ERROR* failed to get regulators > [1.449326] [drm:hdmi_probe] *ERROR* hdmi_resources_init failed > > Reported-by: Krzysztof Kozlowski > Signed-off-by: Javier Martinez Canillas > > --- > > The real fix for these kind of issues is to change the device model > core to support device dependencies so the number of probe deferral > should be minimal or non-existent, instead of fixing on each driver. > > But there have been different attempts [0,1] to implement this and > there doesn't seem that this will be solved in the short term. > > [0]: https://lkml.org/lkml/2014/5/12/452 > [1]: https://lkml.org/lkml/2015/5/25/251 > > drivers/gpu/drm/exynos/exynos_hdmi.c | 6 -- > 1 file changed, 4 insertions(+), 2 deletions(-) Since I like to look at 'dmesg -l err' then I find this useful: Reviewed-by: Krzysztof Kozlowski Best regards, Krzysztof
[Intel-gfx] [PATCH 5/5] drm/i915: Add support for new aspect ratios
Thanks for the review Daniel. My comments inline. Regards Shashank On 4/21/2016 8:34 PM, Daniel Vetter wrote: > On Fri, Mar 25, 2016 at 01:47:35PM +0530, Shashank Sharma wrote: >> HDMI 2.0/CEA-861-F introduces two new aspect ratios: >> - 64:27 >> - 256:135 >> >> This patch adds support for these aspect ratios in >> I915 driver, at various places. >> >> Signed-off-by: Shashank Sharma > > Ok, we discussed this a bit internally and I had some questions. Reading > this series patches make sense up to this one, but here I have a few > questions/comments. > >> --- >> drivers/gpu/drm/drm_modes.c | 12 >> drivers/gpu/drm/i915/intel_hdmi.c | 6 ++ >> drivers/gpu/drm/i915/intel_sdvo.c | 6 ++ >> 3 files changed, 24 insertions(+) >> >> diff --git a/drivers/gpu/drm/drm_modes.c b/drivers/gpu/drm/drm_modes.c >> index 6e66136..11f219a 100644 >> --- a/drivers/gpu/drm/drm_modes.c >> +++ b/drivers/gpu/drm/drm_modes.c >> @@ -1482,6 +1482,12 @@ void drm_mode_convert_to_umode(struct >> drm_mode_modeinfo *out, >> case HDMI_PICTURE_ASPECT_16_9: >> out->flags |= DRM_MODE_FLAG_PAR16_9; >> break; >> +case HDMI_PICTURE_ASPECT_64_27: >> +out->flags |= DRM_MODE_FLAG_PAR64_27; >> +break; >> +case DRM_MODE_PICTURE_ASPECT_256_135: >> +out->flags |= DRM_MODE_FLAG_PAR256_135; >> +break; >> case HDMI_PICTURE_ASPECT_NONE: >> case HDMI_PICTURE_ASPECT_RESERVED: >> default: >> @@ -1544,6 +1550,12 @@ int drm_mode_convert_umode(struct drm_display_mode >> *out, >> case DRM_MODE_FLAG_PAR16_9: >> out->picture_aspect_ratio |= HDMI_PICTURE_ASPECT_16_9; >> break; >> +case DRM_MODE_FLAG_PAR64_27: >> +out->picture_aspect_ratio |= HDMI_PICTURE_ASPECT_64_27; >> +break; >> +case DRM_MODE_FLAG_PAR256_135: >> +out->picture_aspect_ratio |= HDMI_PICTURE_ASPECT_256_135; >> +break; >> default: >> out->picture_aspect_ratio = HDMI_PICTURE_ASPECT_NONE; >> } > > Above two parts is core enabling, I guess those should be squashed into > the preceeding patch? > Sure, we can do this. The idea was to create a separate patch for new aspect ratio, so that one can segregate HDMI 2.0 patches and HDMI 1.4 patches. If you still recommend this, I can move this part in next patch. >> diff --git a/drivers/gpu/drm/i915/intel_hdmi.c >> b/drivers/gpu/drm/i915/intel_hdmi.c >> index e2dab48..bc8e2c8 100644 >> --- a/drivers/gpu/drm/i915/intel_hdmi.c >> +++ b/drivers/gpu/drm/i915/intel_hdmi.c >> @@ -1545,6 +1545,12 @@ intel_hdmi_set_property(struct drm_connector >> *connector, >> case DRM_MODE_PICTURE_ASPECT_16_9: >> intel_hdmi->aspect_ratio = HDMI_PICTURE_ASPECT_16_9; >> break; >> +case DRM_MODE_PICTURE_ASPECT_64_27: >> +intel_hdmi->aspect_ratio = HDMI_PICTURE_ASPECT_64_27; >> +break; >> +case DRM_MODE_PICTURE_ASPECT_256_135: >> +intel_hdmi->aspect_ratio = HDMI_PICTURE_ASPECT_256_135; >> +break; >> default: >> return -EINVAL; >> } >> diff --git a/drivers/gpu/drm/i915/intel_sdvo.c >> b/drivers/gpu/drm/i915/intel_sdvo.c >> index fae64bc..370e4f9 100644 >> --- a/drivers/gpu/drm/i915/intel_sdvo.c >> +++ b/drivers/gpu/drm/i915/intel_sdvo.c >> @@ -2071,6 +2071,12 @@ intel_sdvo_set_property(struct drm_connector >> *connector, >> case DRM_MODE_PICTURE_ASPECT_16_9: >> intel_sdvo->aspect_ratio = HDMI_PICTURE_ASPECT_16_9; >> break; >> +case DRM_MODE_PICTURE_ASPECT_64_27: >> +intel_sdvo->aspect_ratio = HDMI_PICTURE_ASPECT_64_27; >> +break; >> +case DRM_MODE_PICTURE_ASPECT_256_135: >> +intel_sdvo->aspect_ratio = HDMI_PICTURE_ASPECT_256_135; >> +break; >> default: >> return -EINVAL; >> } > > The trouble with the aspect_ratio prop as currently implemented is that we > currently unconditionally overwrite adjusted_mode->picture_aspect_ratio > with it. > > But your patches here move the aspect ratio handling into > drm_mode_modeinfo (uabi) and drm_display_mode (kernel-internal), where it > imo belongs. But we need to figure out how to the interaction with the > property correctly. What's probably needed is a new value in the > aspect_ratio enum called "default", which selects the aspect_ratio from > the mode. Only when userspace overrides (NONE, or one of the CEA aspect > ratios) would we obey the aspect_ratio of the property. Otherwise the > aspect ratio stored in the mode would be lost. This is exactly how we have handled this in Android branch(with NONE as default), thanks for the suggestion. I will incorporate this in next patch set. > > The o
[PATCH v3 7/7] dt-bindings: drm/bridge: Update bindings for ADV7533
On 04/22/2016 04:02 AM, Laurent Pinchart wrote:
> Hi Archit,
>
> Thank you for the patch.
>
> On Wednesday 09 Mar 2016 16:27:18 Archit Taneja wrote:
>> Add description of ADV7533. Add the required and optional properties that
>> are specific to it.
>>
>> Cc: devicetree at vger.kernel.org
>> Cc: Rob Herring
>>
>> Signed-off-by: Archit Taneja
>> ---
>> .../bindings/display/bridge/adi,adv7511.txt| 25 ++-
>> 1 file changed, 20 insertions(+), 5 deletions(-)
>>
>> diff --git
>> a/Documentation/devicetree/bindings/display/bridge/adi,adv7511.txt
>> b/Documentation/devicetree/bindings/display/bridge/adi,adv7511.txt index
>> 96c25ee..420da5a 100644
>> --- a/Documentation/devicetree/bindings/display/bridge/adi,adv7511.txt
>> +++ b/Documentation/devicetree/bindings/display/bridge/adi,adv7511.txt
>> @@ -1,13 +1,19 @@
>> -Analog Device ADV7511(W)/13 HDMI Encoders
>> +Analog Device ADV7511(W)/13/33 HDMI Encoders
>> -
>>
>> -The ADV7511, ADV7511W and ADV7513 are HDMI audio and video transmitters
>> +The ADV7511, ADV7511W, ADV7513 and ADV7533 are HDMI audio and video
>> transmitters compatible with HDMI 1.4 and DVI 1.0. They support color space
>> conversion, -S/PDIF, CEC and HDCP.
>> +S/PDIF, CEC and HDCP. ADV7533 supports the DSI interface for input pixels,
>> while +the others support RGB interface.
>>
>> Required properties:
>>
>> -- compatible: Should be one of "adi,adv7511", "adi,adv7511w" or
>> "adi,adv7513" +- compatible: Should be one of:
>> +"adi,adv7511"
>> +"adi,adv7511w"
>> +"adi,adv7513"
>> +"adi,adv7533"
>> +
>> - reg: I2C slave address
>>
>> The ADV7511 supports a large number of input data formats that differ by
>> their @@ -32,6 +38,11 @@ The following input format properties are required
>> except in "rgb 1x" and - adi,input-justification: The input bit
>> justification ("left", "evenly", "right").
>>
>> +The following properties are required for ADV7533:
>> +
>> +- adi,dsi-lanes: Number of DSI data lanes connected to the DSI host. It
>> should + be one of 1, 2, 3 or 4.
>
> Does the ADV7533 support data lanes remapping ?
It doesn't support remapping of lanes. There is only one register field
that allows us to select the number of lanes.
>
>> Optional properties:
>>
>> - interrupts: Specifier for the ADV7511 interrupt
>> @@ -42,13 +53,17 @@ Optional properties:
>> - adi,embedded-sync: The input uses synchronization signals embedded in the
>> data stream (similar to BT.656). Defaults to separate H/V synchronization
>> signals.
>> +- adi,disable-timing-generator: Only for ADV7533. Disables the internal
>> timing + generator. The chip will rely on the sync signals in the DSI data
>> lanes, + rather than generate its own timings for HDMI output.
>
> Isn't that something that should be selectable at runtime ?
The timing generator can be enabled/disabled at runtime. Although, we
don't have a way to tell the driver whether we want to keep it enabled
or not.
It's a hardware feature that works well on most platforms, but not on
all. In particular, it works well on DB410c, but causes issues with
the Hikey 96 board. The DSI host on Hikey has different clock sources
that generate the display controller's pixel clock and DSI byte clock,
whereas the Qualcomm SoC uses the same source. My guess is that the
ADV7533's timing generator doesn't like it when the pixel data and
clock are out of phase or something.
Since it is a hardware feature which needs tweaking, I thought it
qualified as a DT property.
>
>> Required nodes:
>>
>> The ADV7511 has two video ports. Their connections are modelled using the
>> OF graph bindings specified in Documentation/devicetree/bindings/graph.txt.
>>
>> -- Video port 0 for the RGB or YUV input
>> +- Video port 0 for the RGB, YUV or DSI input. In the case of ADV7533, the
>> + remote endpoint phandle should refer to a valid mipi_dsi_host device
>
> Nitpicking, I would write "reference" instead of "refer to".
I'll fix this in the next revision.
Thanks,
Archit
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora
Forum, hosted by The Linux Foundation
[PATCH 02/14] MAINTAINERS: Remove unneded wildcard for the i915 DRM driver
On Fri, 22 Apr 2016, Emil Velikov wrote: > [ text/plain ] > There is no other file but the UAPI header, thus we can drop the > wildcard. > > Cc: Daniel Vetter > Cc: Jani Nikula > Cc: intel-gfx at lists.freedesktop.org > Cc: dri-devel at lists.freedesktop.org > Signed-off-by: Emil Velikov Acked-by: Jani Nikula > --- > MAINTAINERS | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/MAINTAINERS b/MAINTAINERS > index 2ac57ac..08ae19a 100644 > --- a/MAINTAINERS > +++ b/MAINTAINERS > @@ -3794,7 +3794,7 @@ T: git git://anongit.freedesktop.org/drm-intel > S: Supported > F: drivers/gpu/drm/i915/ > F: include/drm/i915* > -F: include/uapi/drm/i915* > +F: include/uapi/drm/i915_drm.h > > DRM DRIVERS FOR ATMEL HLCDC > M: Boris Brezillon -- Jani Nikula, Intel Open Source Technology Center
[PATCH v3 0/7] drm/i2c: adv7511: ADV7533 support
On 04/22/2016 04:06 AM, Laurent Pinchart wrote: > Hi Archit, > > On Monday 18 Apr 2016 15:18:30 Archit Taneja wrote: >> On 04/17/2016 05:01 PM, Xinliang Liu wrote: >>> On 9 March 2016 at 18:57, Archit Taneja wrote: ADV7533 is a DSI to HDMI encoder chip. It's like ADV7511, but with an additional DSI RX block that takes in DSI video mode output. Trying to get this driver merged has had some challenges: - ADV7533 has an I2C control bus, but acts as a DSI peripheral too. After discussions, it was concluded that we'd want to provide an API to create MIPI DSI devices, rather than expose two different interfaces on DT. The first version [1] tried the former approach the second version [2] showed how the driver would look like if exposed 2 DT nodes. This lateset patchset relies on the MIPI DSI device creation API provided by [3], this has been accepted and should be merged for 4.6. - The driver was designed as an I2C slave encoder. When ADV7533 patches were posted [1], it was modelled as a bridge, but ADV7511 and others were still left as I2C slave encoders. This wasn't accepted. After discussions, it was decided that ADV7511 too would be converted into a bridge driver, and all the users of ADV7511 should assume it is a bridge. This bridge conversion was done in [4]. There is still some debate over whether the bridge driver be involved in the connector creation, or the KMS driver that has the whole view of the display pipeline. This discussion shouldn't affect this patch set, though. >>> >>> I also agree with Laurent Pinchart that bridge driver shoudn't get >>> involved in in the connector creation. >>> It is better for KMS driver that has the whole view of the display >>> pipeline. >> >> Yes, that's the eventual plan. We were thinking of creating an >> additional drm bridge api (drm_bridge_create_connector) that >> helps the KMS driver create a connector for the bridge. >> >> Since there are certain connector related properties that the KMS >> driver may not be aware of, we were thinking of creating another >> drm_bridge op which fills up connector properties. Some properties >> (like whether we want POLLED HPD or not) are more platform specific, >> and would be parsed via the connector's DT node (that is, if DT is >> supported on that platform) >> >> For now, this series creates the connector in the bridge's >> attach op, but relies on the KMS driver to call >> drm_connector_register. The other stuff I mentioned above can come >> later. > > Do you think you'd have time to lead that effort ? Yeah, I think I should. I'll prepare a RFC and we can see how that goes. Thanks, Archit -- The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, hosted by The Linux Foundation
[PATCH v3 0/7] drm/i2c: adv7511: ADV7533 support
On 04/22/2016 04:03 AM, Laurent Pinchart wrote: > Hi Archit, > > On Thursday 14 Apr 2016 20:26:11 Archit Taneja wrote: >> On 3/9/2016 4:27 PM, Archit Taneja wrote: >>> ADV7533 is a DSI to HDMI encoder chip. It's like ADV7511, but with an >>> additional DSI RX block that takes in DSI video mode output. >>> >>> Trying to get this driver merged has had some challenges: >>> >>> - ADV7533 has an I2C control bus, but acts as a DSI peripheral too. >>> >>> After discussions, it was concluded that we'd want to provide an >>> API to create MIPI DSI devices, rather than expose two different >>> interfaces on DT. The first version [1] tried the former approach >>> the second version [2] showed how the driver would look like if >>> exposed 2 DT nodes. This lateset patchset relies on the MIPI DSI >>> device creation API provided by [3], this has been accepted and >>> should be merged for 4.6. >>> >>> - The driver was designed as an I2C slave encoder. When ADV7533 >>> >>> patches were posted [1], it was modelled as a bridge, but ADV7511 >>> and others were still left as I2C slave encoders. This wasn't >>> accepted. After discussions, it was decided that ADV7511 too would >>> be converted into a bridge driver, and all the users of ADV7511 >>> should assume it is a bridge. This bridge conversion was done in >>> [4]. There is still some debate over whether the bridge driver be >>> involved in the connector creation, or the KMS driver that has >>> the whole view of the display pipeline. This discussion shouldn't >>> affect this patch set, though. >>> >>> This patch set enables ADV7533 support with the above two issues >>> now resolved. It also incorporates ADV7533 specific features and fixes >>> that we've discovered since the first version of this patch was posted. >>> >>> Tested on ADV7533 chips on DB410c. It should work on the Hikey board too. >>> I'd appreaciate if someone could test it on a ADV7511 platform since I >>> don't have one. >> >> Could you try this patch set on the rcar-du platform? It would help to >> verify if this doesn't break ADV7511. > > Basic testing didn't show any regression. For the whole series, > > Tested-by: Laurent Pinchart Thanks! Archit -- The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, hosted by The Linux Foundation
[PATCH 2/2] drm/exynos: fix imported dma-buf to be mapped
The imported dma-buf should be mapped by sub-system exporting it. Signed-off-by: Joonyoung Shim --- drivers/gpu/drm/exynos/exynos_drm_gem.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/gpu/drm/exynos/exynos_drm_gem.c b/drivers/gpu/drm/exynos/exynos_drm_gem.c index 9f688c28fa8e..6c83884f1fe6 100644 --- a/drivers/gpu/drm/exynos/exynos_drm_gem.c +++ b/drivers/gpu/drm/exynos/exynos_drm_gem.c @@ -547,6 +547,9 @@ int exynos_drm_gem_mmap(struct file *filp, struct vm_area_struct *vma) obj = vma->vm_private_data; + if (obj->import_attach) + return dma_buf_mmap(obj->dma_buf, vma, 0); + return exynos_drm_gem_mmap_obj(obj, vma); } -- 1.9.1
[PATCH 1/2] drm/exynos: support gem_prime_mmap
This allows exported dma-bufs to be mapped using gem_prime_mmap.
Signed-off-by: Joonyoung Shim
---
drivers/gpu/drm/exynos/exynos_drm_drv.c | 1 +
drivers/gpu/drm/exynos/exynos_drm_gem.c | 45 +++--
drivers/gpu/drm/exynos/exynos_drm_gem.h | 2 ++
3 files changed, 35 insertions(+), 13 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.c
b/drivers/gpu/drm/exynos/exynos_drm_drv.c
index 5344940c8a07..94d0d785fac2 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_drv.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_drv.c
@@ -431,6 +431,7 @@ static struct drm_driver exynos_drm_driver = {
.gem_prime_import_sg_table = exynos_drm_gem_prime_import_sg_table,
.gem_prime_vmap = exynos_drm_gem_prime_vmap,
.gem_prime_vunmap = exynos_drm_gem_prime_vunmap,
+ .gem_prime_mmap = exynos_drm_gem_prime_mmap,
.ioctls = exynos_ioctls,
.num_ioctls = ARRAY_SIZE(exynos_ioctls),
.fops = &exynos_drm_driver_fops,
diff --git a/drivers/gpu/drm/exynos/exynos_drm_gem.c
b/drivers/gpu/drm/exynos/exynos_drm_gem.c
index 6fb98f4c3544..9f688c28fa8e 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_gem.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_gem.c
@@ -503,22 +503,12 @@ out:
}
}
-int exynos_drm_gem_mmap(struct file *filp, struct vm_area_struct *vma)
+static int exynos_drm_gem_mmap_obj(struct drm_gem_object *obj,
+ struct vm_area_struct *vma)
{
- struct exynos_drm_gem *exynos_gem;
- struct drm_gem_object *obj;
+ struct exynos_drm_gem *exynos_gem = to_exynos_gem(obj);
int ret;
- /* set vm_area_struct. */
- ret = drm_gem_mmap(filp, vma);
- if (ret < 0) {
- DRM_ERROR("failed to mmap.\n");
- return ret;
- }
-
- obj = vma->vm_private_data;
- exynos_gem = to_exynos_gem(obj);
-
DRM_DEBUG_KMS("flags = 0x%x\n", exynos_gem->flags);
/* non-cachable as default. */
@@ -543,6 +533,23 @@ err_close_vm:
return ret;
}
+int exynos_drm_gem_mmap(struct file *filp, struct vm_area_struct *vma)
+{
+ struct drm_gem_object *obj;
+ int ret;
+
+ /* set vm_area_struct. */
+ ret = drm_gem_mmap(filp, vma);
+ if (ret < 0) {
+ DRM_ERROR("failed to mmap.\n");
+ return ret;
+ }
+
+ obj = vma->vm_private_data;
+
+ return exynos_drm_gem_mmap_obj(obj, vma);
+}
+
/* low-level interface prime helpers */
struct sg_table *exynos_drm_gem_prime_get_sg_table(struct drm_gem_object *obj)
{
@@ -617,3 +624,15 @@ void exynos_drm_gem_prime_vunmap(struct drm_gem_object
*obj, void *vaddr)
{
/* Nothing to do */
}
+
+int exynos_drm_gem_prime_mmap(struct drm_gem_object *obj,
+ struct vm_area_struct *vma)
+{
+ int ret;
+
+ ret = drm_gem_mmap_obj(obj, obj->size, vma);
+ if (ret < 0)
+ return ret;
+
+ return exynos_drm_gem_mmap_obj(obj, vma);
+}
diff --git a/drivers/gpu/drm/exynos/exynos_drm_gem.h
b/drivers/gpu/drm/exynos/exynos_drm_gem.h
index 00223052b87b..895125431227 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_gem.h
+++ b/drivers/gpu/drm/exynos/exynos_drm_gem.h
@@ -139,5 +139,7 @@ exynos_drm_gem_prime_import_sg_table(struct drm_device *dev,
struct sg_table *sgt);
void *exynos_drm_gem_prime_vmap(struct drm_gem_object *obj);
void exynos_drm_gem_prime_vunmap(struct drm_gem_object *obj, void *vaddr);
+int exynos_drm_gem_prime_mmap(struct drm_gem_object *obj,
+ struct vm_area_struct *vma);
#endif
--
1.9.1
[PATCH] drm/exynos: use directly DMA mapping APIs on g2d
There is no reason to be wapper functions to use DMA mapping APIs. Use
directly DMA mapping APIs and remove the wapper functions.
Signed-off-by: Joonyoung Shim
---
This is based on linux-next for 20160422.
drivers/gpu/drm/exynos/exynos_drm_g2d.c | 10 +-
drivers/gpu/drm/exynos/exynos_drm_gem.c | 22 --
drivers/gpu/drm/exynos/exynos_drm_gem.h | 10 --
3 files changed, 5 insertions(+), 37 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_g2d.c
b/drivers/gpu/drm/exynos/exynos_drm_g2d.c
index 193d3602dffb..493552368295 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_g2d.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_g2d.c
@@ -383,8 +383,8 @@ static void g2d_userptr_put_dma_addr(struct drm_device
*drm_dev,
return;
out:
- exynos_gem_unmap_sgt_from_dma(drm_dev, g2d_userptr->sgt,
- DMA_BIDIRECTIONAL);
+ dma_unmap_sg(to_dma_dev(drm_dev), g2d_userptr->sgt->sgl,
+ g2d_userptr->sgt->nents, DMA_BIDIRECTIONAL);
pages = frame_vector_pages(g2d_userptr->vec);
if (!IS_ERR(pages)) {
@@ -501,10 +501,10 @@ static dma_addr_t *g2d_userptr_get_dma_addr(struct
drm_device *drm_dev,
g2d_userptr->sgt = sgt;
- ret = exynos_gem_map_sgt_with_dma(drm_dev, g2d_userptr->sgt,
- DMA_BIDIRECTIONAL);
- if (ret < 0) {
+ if (!dma_map_sg(to_dma_dev(drm_dev), sgt->sgl, sgt->nents,
+ DMA_BIDIRECTIONAL)) {
DRM_ERROR("failed to map sgt with dma region.\n");
+ ret = -ENOMEM;
goto err_sg_free_table;
}
diff --git a/drivers/gpu/drm/exynos/exynos_drm_gem.c
b/drivers/gpu/drm/exynos/exynos_drm_gem.c
index 6fb98f4c3544..96bb40361b1c 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_gem.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_gem.c
@@ -378,28 +378,6 @@ int exynos_drm_gem_get_ioctl(struct drm_device *dev, void
*data,
return 0;
}
-int exynos_gem_map_sgt_with_dma(struct drm_device *drm_dev,
- struct sg_table *sgt,
- enum dma_data_direction dir)
-{
- int nents;
-
- nents = dma_map_sg(to_dma_dev(drm_dev), sgt->sgl, sgt->nents, dir);
- if (!nents) {
- DRM_ERROR("failed to map sgl with dma.\n");
- return nents;
- }
-
- return 0;
-}
-
-void exynos_gem_unmap_sgt_from_dma(struct drm_device *drm_dev,
- struct sg_table *sgt,
- enum dma_data_direction dir)
-{
- dma_unmap_sg(to_dma_dev(drm_dev), sgt->sgl, sgt->nents, dir);
-}
-
void exynos_drm_gem_free_object(struct drm_gem_object *obj)
{
exynos_drm_gem_destroy(to_exynos_gem(obj));
diff --git a/drivers/gpu/drm/exynos/exynos_drm_gem.h
b/drivers/gpu/drm/exynos/exynos_drm_gem.h
index 00223052b87b..c1df26877b76 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_gem.h
+++ b/drivers/gpu/drm/exynos/exynos_drm_gem.h
@@ -121,16 +121,6 @@ int exynos_drm_gem_fault(struct vm_area_struct *vma,
struct vm_fault *vmf);
/* set vm_flags and we can change the vm attribute to other one at here. */
int exynos_drm_gem_mmap(struct file *filp, struct vm_area_struct *vma);
-/* map sgt with dma region. */
-int exynos_gem_map_sgt_with_dma(struct drm_device *drm_dev,
- struct sg_table *sgt,
- enum dma_data_direction dir);
-
-/* unmap sgt from dma region. */
-void exynos_gem_unmap_sgt_from_dma(struct drm_device *drm_dev,
- struct sg_table *sgt,
- enum dma_data_direction dir);
-
/* low-level interface prime helpers */
struct sg_table *exynos_drm_gem_prime_get_sg_table(struct drm_gem_object *obj);
struct drm_gem_object *
--
1.9.1
[Bug 94984] XCom2 crashes with SIGSEGV on radeonsi
https://bugs.freedesktop.org/show_bug.cgi?id=94984 --- Comment #7 from Edwin Smith --- (In reply to kuehner.moritz from comment #6) > So I was able to continue the game over the point of the crash on may laptop > and than save the game. This gives me a save game that crashes upon loading. For anyone testing please make sure you remove the .txt that might get added to the end of the save game when downloading. The save game file should be called "save498" and placed ins the follow path inside the games preference folder. /VFS/Local/my\ games/XCOM2/XComGame/SaveData/save498 You can automatically open you preference folder using the button in the pre game launcher on the support tab. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20160422/64de4be6/attachment.html>
[PATCH v2 2/4] dt-bindings: Add jdi lt070me05000 panel bindings
On Thu, Apr 21, 2016 at 9:15 PM, Rob Herring wrote:
> On Wed, Apr 20, 2016 at 03:02:31PM +0530, Vinay Simha BN wrote:
>> Add documentation for lt070me05000 panel
>>
>> Signed-off-by: Vinay Simha BN
>> ---
>> .../bindings/display/panel/jdi,lt070me05000.txt| 43
>> ++
>> 1 file changed, 43 insertions(+)
>> create mode 100644
>> Documentation/devicetree/bindings/display/panel/jdi,lt070me05000.txt
>>
>> diff --git
>> a/Documentation/devicetree/bindings/display/panel/jdi,lt070me05000.txt
>> b/Documentation/devicetree/bindings/display/panel/jdi,lt070me05000.txt
>> new file mode 100644
>> index 000..ffe0550
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/display/panel/jdi,lt070me05000.txt
>> @@ -0,0 +1,43 @@
>> +JDI model LT070ME05000 1200x1920 7" DSI Panel
>> +
>> +Required properties:
>> +- compatible: should be "jdi,lt070me05000"
>> +- power-supply: phandle of the regulator that provides the supply voltage
>> + IOVCC , power supply for LCM (1.8V)
>> +- vddp-supply: phandle of the regulator that provides the supply voltage
>> + Power IC supply (3-5V)
>> +- dcdc_en-supply: phandle of the regulator that provides the supply voltage
>> + Power IC supply enable, High active
>> +- reset-gpio: phandle of gpio for reset line
>> + This should be 8mA, gpio can be configured using mux and pinctrl.
>> + XRES, Reset, Low active
>> +- enable-gpio: phandle of gpio for enable line
>> + LED_EN, LED backlight enable, High active
>
> These should all be -gpios instead.
will implement in v3
>
>> +- vcc-gpio: phandle of regulator/gpio that provides the supply voltage
>> + VDD, LED power supply (3-5V)
>
> Is it a regulator or gpio?
>
VDD is LED power supply, but in nexus 7 2nd gen they are using gpio 23
instead of regulator.
if we use vcc-supply, not sure we can give the gpio device tree entry
to it in nexus 7 dts. Any inputs ?
>> +
>> +Optional properties:
>> +- pwm-gpio: phandle of gpio/pwm
>
> This should use the PWM binding. It may not be a GPIO on some hosts.
pwm-gpio will go to the backlight (pwm). right now it is not used
since pwm pm8921 upstream driver is not yet implemented. Shall i
remove this pwm-gpio now and the backlight property when pwm pm8921 is
implemented?
>
>> + pwm backlight control, this should be mapped to the backlight level
>> + display brightness (0x51)
>> +
>> +Example:
>> +
>> + dsi0: qcom,mdss_dsi at 470 {
>> + panel at 0 {
>> + compatible = "jdi,lt070me05000";
>> + reg = <0>;
>> + pinctrl-names = "default";
>> + pinctrl-0 = <&dsi_panel_pinctrl>;
>> +
>> + power-supply = <&pm8921_lvs5>;
>> + vddp-supply = <&pm8921_l17>;
>> + dcdc_en-supply = <&pm8921_lvs7>;
>> +
>> + reset-gpio = <&tlmm_pinmux 54 0>;
>> + enable-gpio = <&pm8921_gpio 36 GPIO_ACTIVE_HIGH>;
>> + vcc-gpio = <&pm8921_gpio 23 GPIO_ACTIVE_HIGH>;
>> +
>> + pwm-gpio = <&pm8921_gpio 26 GPIO_ACTIVE_HIGH>;
>> + };
>> + };
>> --
>> 2.1.2
>>
--
Regards,
Vinay Simha.B.N.
[Intel-gfx] [PATCH 5/5] drm/i915: Add support for new aspect ratios
On Fri, Apr 22, 2016 at 10:58:34AM +0530, Sharma, Shashank wrote: > Thanks for the review Daniel. > My comments inline. > > Regards > Shashank > On 4/21/2016 8:34 PM, Daniel Vetter wrote: > >On Fri, Mar 25, 2016 at 01:47:35PM +0530, Shashank Sharma wrote: > >>HDMI 2.0/CEA-861-F introduces two new aspect ratios: > >>- 64:27 > >>- 256:135 > >> > >>This patch adds support for these aspect ratios in > >>I915 driver, at various places. > >> > >>Signed-off-by: Shashank Sharma > > > >Ok, we discussed this a bit internally and I had some questions. Reading > >this series patches make sense up to this one, but here I have a few > >questions/comments. > > > >>--- > >> drivers/gpu/drm/drm_modes.c | 12 > >> drivers/gpu/drm/i915/intel_hdmi.c | 6 ++ > >> drivers/gpu/drm/i915/intel_sdvo.c | 6 ++ > >> 3 files changed, 24 insertions(+) > >> > >>diff --git a/drivers/gpu/drm/drm_modes.c b/drivers/gpu/drm/drm_modes.c > >>index 6e66136..11f219a 100644 > >>--- a/drivers/gpu/drm/drm_modes.c > >>+++ b/drivers/gpu/drm/drm_modes.c > >>@@ -1482,6 +1482,12 @@ void drm_mode_convert_to_umode(struct > >>drm_mode_modeinfo *out, > >>case HDMI_PICTURE_ASPECT_16_9: > >>out->flags |= DRM_MODE_FLAG_PAR16_9; > >>break; > >>+ case HDMI_PICTURE_ASPECT_64_27: > >>+ out->flags |= DRM_MODE_FLAG_PAR64_27; > >>+ break; > >>+ case DRM_MODE_PICTURE_ASPECT_256_135: > >>+ out->flags |= DRM_MODE_FLAG_PAR256_135; > >>+ break; > >>case HDMI_PICTURE_ASPECT_NONE: > >>case HDMI_PICTURE_ASPECT_RESERVED: > >>default: > >>@@ -1544,6 +1550,12 @@ int drm_mode_convert_umode(struct drm_display_mode > >>*out, > >>case DRM_MODE_FLAG_PAR16_9: > >>out->picture_aspect_ratio |= HDMI_PICTURE_ASPECT_16_9; > >>break; > >>+ case DRM_MODE_FLAG_PAR64_27: > >>+ out->picture_aspect_ratio |= HDMI_PICTURE_ASPECT_64_27; > >>+ break; > >>+ case DRM_MODE_FLAG_PAR256_135: > >>+ out->picture_aspect_ratio |= HDMI_PICTURE_ASPECT_256_135; > >>+ break; > >>default: > >>out->picture_aspect_ratio = HDMI_PICTURE_ASPECT_NONE; > >>} > > > >Above two parts is core enabling, I guess those should be squashed into > >the preceeding patch? > > > Sure, we can do this. > The idea was to create a separate patch for new aspect ratio, so that one > can segregate HDMI 2.0 patches and HDMI 1.4 patches. If you still recommend > this, I can move this part in next patch. Definitely a good idea, and you have that separate patch already in "drm: Add flags for new aspect ratios". I just think that the above 2 hunks belong into the core patch, not the i915 enabling patch. > >>diff --git a/drivers/gpu/drm/i915/intel_hdmi.c > >>b/drivers/gpu/drm/i915/intel_hdmi.c > >>index e2dab48..bc8e2c8 100644 > >>--- a/drivers/gpu/drm/i915/intel_hdmi.c > >>+++ b/drivers/gpu/drm/i915/intel_hdmi.c > >>@@ -1545,6 +1545,12 @@ intel_hdmi_set_property(struct drm_connector > >>*connector, > >>case DRM_MODE_PICTURE_ASPECT_16_9: > >>intel_hdmi->aspect_ratio = HDMI_PICTURE_ASPECT_16_9; > >>break; > >>+ case DRM_MODE_PICTURE_ASPECT_64_27: > >>+ intel_hdmi->aspect_ratio = HDMI_PICTURE_ASPECT_64_27; > >>+ break; > >>+ case DRM_MODE_PICTURE_ASPECT_256_135: > >>+ intel_hdmi->aspect_ratio = HDMI_PICTURE_ASPECT_256_135; > >>+ break; > >>default: > >>return -EINVAL; > >>} > >>diff --git a/drivers/gpu/drm/i915/intel_sdvo.c > >>b/drivers/gpu/drm/i915/intel_sdvo.c > >>index fae64bc..370e4f9 100644 > >>--- a/drivers/gpu/drm/i915/intel_sdvo.c > >>+++ b/drivers/gpu/drm/i915/intel_sdvo.c > >>@@ -2071,6 +2071,12 @@ intel_sdvo_set_property(struct drm_connector > >>*connector, > >>case DRM_MODE_PICTURE_ASPECT_16_9: > >>intel_sdvo->aspect_ratio = HDMI_PICTURE_ASPECT_16_9; > >>break; > >>+ case DRM_MODE_PICTURE_ASPECT_64_27: > >>+ intel_sdvo->aspect_ratio = HDMI_PICTURE_ASPECT_64_27; > >>+ break; > >>+ case DRM_MODE_PICTURE_ASPECT_256_135: > >>+ intel_sdvo->aspect_ratio = HDMI_PICTURE_ASPECT_256_135; > >>+ break; > >>default: > >>return -EINVAL; > >>} > > > >The trouble with the aspect_ratio prop as currently implemented is that we > >currently unconditionally overwrite adjusted_mode->picture_aspect_ratio > >with it. > > > >But your patches here move the aspect ratio handling into > >drm_mode_modeinfo (uabi) and drm_display_mode (kernel-internal), where it > >imo belongs. But we need to figure out how to the interaction with the > >property correctly. What's probably needed is a new value in the > >aspect_ratio enum called "default", which selects the aspect_ratio from > >the
[GIT PULL] MT8173 DRM support
Am Freitag, den 22.04.2016, 05:50 +1000 schrieb Dave Airlie: > On 19 April 2016 at 23:42, Philipp Zabel wrote: > > Hi Dave, > > > > please consider pulling this tag with initial MediaTek MT8173 DRM > > support, corresponding to v14 of the patch series. These patches have > > been mostly stable for the last few rounds. I'll follow up with the HDMI > > encoder support pending review of the latest version. > > > Close but no cigar, > > building as a module screws up here, Turns out I haven't tested modular build for a while. At some point I've mistakenly synced from the chromeos config and never noticed. I've fixed my build script to check for this. > drivers/gpu/drm/mediatek/mtk_drm_drv.o: In function `init_module': > mtk_drm_drv.c:(.init.text+0x0): multiple definition of `init_module' > drivers/gpu/drm/mediatek/mtk_drm_ddp.o:mtk_drm_ddp.c:(.init.text+0x0): > first defined here > drivers/gpu/drm/mediatek/mtk_drm_drv.o: In function `cleanup_module': > mtk_drm_drv.c:(.exit.text+0x0): multiple definition of `cleanup_module' > drivers/gpu/drm/mediatek/mtk_drm_ddp.o:mtk_drm_ddp.c:(.exit.text+0x0): > first defined here > > Try again! (or tell me I pulled the wrong thing :-) Try again it is. The mediatek-drm/next branch has the fix now, built as a module and tested. I'll tag this and resend a pull request later today. regards Philipp
[Intel-gfx] [PATCH] drm: i915: Improve behavior in case of broken HDMI EDID
On Thu, Apr 21, 2016 at 03:13:51PM -0300, Ezequiel Garcia wrote:
> Daniel,
>
> Thanks a lot for the quick reply!
>
> On 20 Apr 01:34 PM, Daniel Vetter wrote:
> > On Tue, Apr 19, 2016 at 02:31:13PM -0300, Ezequiel Garcia wrote:
> > > Currently, our implementation of drm_connector_funcs.detect is
> > > based on getting a valid EDID.
> > >
> > > This requirement makes the driver fail to detect connected
> > > connectors in case of EDID corruption, which in turn prevents
> > > from falling back to modes provided by builtin or user-provided
> > > EDIDs.
> >
> > Imo, this should be fixed in the probe helpers. Something like the below
> > might make sense:
> >
> >
> > diff --git a/drivers/gpu/drm/drm_probe_helper.c
> > b/drivers/gpu/drm/drm_probe_helper.c
> > index e714b5a7955f..d3b9dc7535da 100644
> > --- a/drivers/gpu/drm/drm_probe_helper.c
> > +++ b/drivers/gpu/drm/drm_probe_helper.c
> > @@ -214,7 +214,10 @@ int drm_helper_probe_single_connector_modes(struct
> > drm_connector *connector,
> > else
> > connector->status = connector_status_disconnected;
> > if (connector->funcs->force)
> > - connector->funcs->force(connector);
> > + connector->funcs->force(connector);
> > + } else if (connector->override_edid){
> > + connector->status = connector_status_connected;
> > + connector->funcs->force(connector);
> > } else {
> > connector->status = connector->funcs->detect(connector, true);
> > }
> >
> >
> > It should do what you want it to do, still allow us to override force
> > state manually and also fix things up for every, not just i915-hdmi. Also,
> > much smaller patch.
> >
>
> The patch you are proposing doesn't seem to be related
> to the issue I want to fix, so maybe my explanation is still
> unclear. After re-reading my commit log, I came to realize
> I'm still not explaining the issue properly.
>
> Let me try again :-)
>
> A user can connect any kind of HDMI monitor to the box, and
> the kernel should be able to output some video, even when the
> HDMI monitor is a piece of crap and sends completely broken EDID.
>
> Currently, the i915 driver uses the return value of intel_hdmi_set_edid()
> to set the connector status. IOW, the connector status is set to "connected"
> *only* if the EDID is correct, and is left as "disconnected" if the EDID
> is corrupt.
>
> However, the connector status can be detected by just probing
> the I2C bus (drm_probe_ddc).
>
> The DRM probe helper relies on the .detect callback to decide if
> the modes' fallbacks, EDID provided modes, etc are going to be set.
>
> It only set those modes if the .detect callback handler returns
> a "connected" status and does nothing if .detect returns
> "disconnected".
>
> If the connector is reported as "disconnected" it will skip it and
> the user won't be able to use it (except if the state is forced
> with a parameter).
>
> I am currently shipping intel boxes without monitors, and the
> user can connect its own monitor. I can't know before hand
> what device is going to be plugged (neither on which output
> connector, HDMI, DVI, etc)... so I am not able to force any state.
>
> The patch I am proposing makes the kernel work without any
> user intervention, in the face of corrupted EDID coming out of
> a monitor. This works because the .detect logic after my patch
> just checks if a I2C device is present in the bus to mark the
> connector as "connected" and does not use the EDID parsing for that.
>
> In fact, the EDID parsing is moved to .get_modes() since they're
> not really used before. This at the very least, is consistent with
> how other drivers work (I'm not inventing anything).
>
> Maybe the following commit log is better. How does it look now?
But in that case the only thing you get is the 1024x756 fallback mode.
You're users are happy with that? I thought your use-case was that you
need to overwrite the edid anyway, and that doing the edid override alone
doesn't work. Hence my patch to make stuff work directly with just the
edid override.
At least I myself wouldn't consider 1024x756 "working" ...
-Daniel
>
> --8<--
> drm: i915: Fix HDMI connector status detection in case of broken EDID
>
> The i915 DRM driver attempts to parse the EDID in the HDMI connector
> .detect callback and use the return status of intel_hdmi_set_edid()
> to decide if the connector status is connected or disconnected.
>
> The problem is that intel_hdmi_set_edid() fails if the EDID is not
> correct (i.e: corrupted) and so .detect will wrongly report to the
> DRM core that the connector is disconnected.
>
> It's totally acceptable to use a HDMI connector even in the case of
> a broken EDID, by using the CONFIG_DRM_LOAD_EDID_FIRMWARE
> and noedid fallback options. The only thing that .detect should
> check is that there is a device answering in the correct I2C address
> and bus.
>
> So this patch changes the .d
[PATCH 2/8] drm/udl: Change drm_fb_helper_sys_*() calls to sys_*()
On Thu, Apr 21, 2016 at 08:18:48PM +0200, Noralf Trønnes wrote:
>
> Den 21.04.2016 09:28, skrev Daniel Vetter:
> >On Wed, Apr 20, 2016 at 08:15:30PM +0200, Noralf Trønnes wrote:
> >>Den 20.04.2016 19:42, skrev Daniel Vetter:
> >>>On Wed, Apr 20, 2016 at 05:25:23PM +0200, Noralf Trønnes wrote:
> Now that drm_fb_helper gets deferred io support, the
> drm_fb_helper_sys_{fillrect,copyarea,imageblit} functions will schedule
> the worker that calls the deferred_io callback. This will break this
> driver so use the sys_{fillrect,copyarea,imageblit} functions directly.
>
> Signed-off-by: Noralf Trønnes
> >>>I think this intermediately breaks the build, if you disable fbdev
> >>>support. That's now supported in the fbdev helpers core generically across
> >>>all drivers.
> >>>
> >>>Not sure how to best fix this up, since the only way would be to squash
> >>>these patches, plus generic deferred io plus the conversion patches for
> >>>udl/qxl all into one. Tricky.
> >>Yes you're right, I missed that.
> >>How about this:
> >>#ifdef CONFIG_FB
> >> sys_fillrect(info, rect);
> >>#endif
> >>
> >>The later patch will then remove this ugliness...
> >Yeah I think we have to bite the bullet and take this temporary ugliness
> >:(
>
> Turns out the #ifdef isn't necessary since FB is always selected.
>
> Both udl and qxl have this:
> select DRM_KMS_HELPER
> select DRM_KMS_FB_HELPER
>
> And then we have:
>
> config DRM_KMS_HELPER
> tristate
> depends on DRM
>
> config DRM_KMS_FB_HELPER
> bool
> depends on DRM_KMS_HELPER
> select FB
> ...
> select FB_SYS_FILLRECT
> select FB_SYS_COPYAREA
> select FB_SYS_IMAGEBLIT
Hm ... the thing that actually builds fbdev emulation is
DRM_FBDEV_EMULATION, and you can disable that. Otoh the select FB stuff
seems to be at the wrong level and probably should be moved.
But indeed I tried doing this and it's an impossible config. I guess I
need to type a patch to ditch all these selects from drivers ;-)
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
[PATCH 4/8] drm/fb-helper: Add fb_deferred_io support
On Thu, Apr 21, 2016 at 08:54:45PM +0200, Noralf Trønnes wrote:
>
> Den 20.04.2016 17:25, skrev Noralf Trønnes:
> >This adds deferred io support if CONFIG_FB_DEFERRED_IO is enabled.
> >Accumulated fbdev framebuffer changes are signaled using the callback
> >(struct drm_framebuffer_funcs *)->dirty()
> >
> >The drm_fb_helper_sys_*() functions will accumulate changes and
> >schedule fb_info.deferred_work _if_ fb_info.fbdefio is set.
> >This worker is used by the deferred io mmap code to signal that it
> >has been collecting page faults. The page faults and/or other changes
> >are then merged into a drm_clip_rect and passed to the framebuffer
> >dirty() function.
> >
> >The driver is responsible for setting up the fb_info.fbdefio structure
> >and calling fb_deferred_io_init() using the provided callback:
> >(struct fb_deferred_io).deferred_io = drm_fb_helper_deferred_io;
> >
> >Signed-off-by: Noralf Trønnes
> >---
> > drivers/gpu/drm/drm_fb_helper.c | 119
> > +++-
> > include/drm/drm_fb_helper.h | 15 +
> > 2 files changed, 133 insertions(+), 1 deletion(-)
> >
> >diff --git a/drivers/gpu/drm/drm_fb_helper.c
> >b/drivers/gpu/drm/drm_fb_helper.c
>
> [...]
>
> >+#ifdef CONFIG_FB_DEFERRED_IO
> >+/**
> >+ * drm_fb_helper_deferred_io() - (struct fb_deferred_io *)->deferred_io
> >callback
> >+ * function
> >+ *
> >+ * This function always runs in process context (struct delayed_work) and
> >calls
> >+ * the (struct drm_framebuffer_funcs)->dirty function with the collected
> >+ * damage. There's no need to worry about the possibility that the
> >fb_sys_*()
> >+ * functions could be running in atomic context. They only schedule the
> >+ * delayed worker which then calls this deferred_io callback.
> >+ */
> >+void drm_fb_helper_deferred_io(struct fb_info *info,
> >+ struct list_head *pagelist)
> >+{
> >+struct drm_fb_helper *helper = info->par;
> >+unsigned long start, end, min, max;
> >+struct drm_clip_rect clip;
> >+unsigned long flags;
> >+struct page *page;
> >+
> >+if (!helper->fb->funcs->dirty)
> >+return;
> >+
> >+spin_lock_irqsave(&helper->dirty_lock, flags);
> >+clip = helper->dirty_clip;
> >+drm_clip_rect_reset(&helper->dirty_clip);
> >+spin_unlock_irqrestore(&helper->dirty_lock, flags);
> >+
> >+min = ULONG_MAX;
> >+max = 0;
> >+list_for_each_entry(page, pagelist, lru) {
> >+start = page->index << PAGE_SHIFT;
> >+end = start + PAGE_SIZE - 1;
> >+min = min(min, start);
> >+max = max(max, end);
> >+}
> >+
> >+if (min < max) {
> >+struct drm_clip_rect mmap_clip;
> >+
> >+mmap_clip.x1 = 0;
> >+mmap_clip.x2 = info->var.xres;
> >+mmap_clip.y1 = min / info->fix.line_length;
> >+mmap_clip.y2 = min_t(u32, max / info->fix.line_length,
> >+ info->var.yres);
> >+drm_clip_rect_merge(&clip, &mmap_clip, 1, 0, 0, 0);
> >+}
> >+
> >+if (!drm_clip_rect_is_empty(&clip))
> >+helper->fb->funcs->dirty(helper->fb, NULL, 0, 0, &clip, 1);
> >+}
> >+EXPORT_SYMBOL(drm_fb_helper_deferred_io);
>
> There is one thing I have wondered about when it comes to deferred io and
> long run times for the defio worker with my displays:
>
> Userspace writes to some pages then the deferred io worker kicks off and
> runs for 100ms holding the page list mutex. While this is happening,
> userspace writes to a new page triggering a page_mkwrite. Now this
> function has to wait for the mutex to be released.
>
> Who is actually waiting here and is there a problem that this can last
> for 100ms?
No idea at all - I haven't looked that closely at fbdev defio. But one
reason we have an explicit ioctl in drm to flush out frontbuffer rendering
is exactly that flushing could take some time, and should only be done
once userspace has completed some rendering. Not right in the middle of an
op.
I guess fix up your userspace to use dumb drm fb + drm dirtyfb ioctl?
Otherwise you'll get to improve fbdev defio, and fbdev is deprecated
subsystem and a real horror show. I highly recommend against touching it
;-)
Cheers, Daniel
>
> Excerpt from drivers/video/fbdev/core/fb_defio.c:
>
> /* vm_ops->page_mkwrite handler */
> static int fb_deferred_io_mkwrite(struct vm_area_struct *vma,
> struct vm_fault *vmf)
> {
> ...
> /* this is a callback we get when userspace first tries to
> write to the page. we schedule a workqueue. that workqueue
> will eventually mkclean the touched pages and execute the
> deferred framebuffer IO. then if userspace touches a page
> again, we repeat the same scheme */
> ...
> /* protect against the workqueue changing the page list */
> mutex_lock(&fbdefio->lock);
> ...
> /*
> * We want the page to remain locked from ->page_mkwrite unti
[PATCH 1/2] drm: rcar-du: Add Z-order support for VSP planes
On Fri, Apr 22, 2016 at 12:00:39AM +0300, Laurent Pinchart wrote:
> Hi Daniel,
>
> On Thursday 21 Apr 2016 18:10:25 Daniel Vetter wrote:
> > On Thu, Apr 21, 2016 at 04:14:12AM +0300, Laurent Pinchart wrote:
> > > Make the Z-order of VSP planes configurable through the zpos property,
> > > exactly as for the native DU planes.
> > >
> > > Signed-off-by: Laurent Pinchart
> > >
> > > ---
> > >
> > > drivers/gpu/drm/rcar-du/rcar_du_vsp.c | 16
> > > drivers/gpu/drm/rcar-du/rcar_du_vsp.h | 2 ++
> > > 2 files changed, 14 insertions(+), 4 deletions(-)
> > >
> > > diff --git a/drivers/gpu/drm/rcar-du/rcar_du_vsp.c
> > > b/drivers/gpu/drm/rcar-du/rcar_du_vsp.c index de7ef041182b..62e9619eaea4
> > > 100644
> > > --- a/drivers/gpu/drm/rcar-du/rcar_du_vsp.c
> > > +++ b/drivers/gpu/drm/rcar-du/rcar_du_vsp.c
> > > @@ -180,8 +180,9 @@ static void rcar_du_vsp_plane_setup(struct
> > > rcar_du_vsp_plane *plane)>
> > > WARN_ON(!pixelformat);
> > >
> > > - vsp1_du_atomic_update(plane->vsp->vsp, plane->index, pixelformat,
> > > - fb->pitches[0], paddr, &src, &dst);
> > > + vsp1_du_atomic_update_zpos(plane->vsp->vsp, plane->index, pixelformat,
> > > +fb->pitches[0], paddr, &src, &dst,
> > > +state->zpos);
> > >
> > > }
> > >
> > > static int rcar_du_vsp_plane_atomic_check(struct drm_plane *plane,
> > >
> > > @@ -220,8 +221,8 @@ static void rcar_du_vsp_plane_atomic_update(struct
> > > drm_plane *plane,>
> > > if (plane->state->crtc)
> > >
> > > rcar_du_vsp_plane_setup(rplane);
> > >
> > > else
> > >
> > > - vsp1_du_atomic_update(rplane->vsp->vsp, rplane->index, 0, 0, 0,
> > > - NULL, NULL);
> > > + vsp1_du_atomic_update_zpos(rplane->vsp->vsp, rplane->index,
> > > +0, 0, 0, NULL, NULL, 0);
> > >
> > > }
> > >
> > > static const struct drm_plane_helper_funcs rcar_du_vsp_plane_helper_funcs
> > > = {>
> > > @@ -269,6 +270,7 @@ static void rcar_du_vsp_plane_reset(struct drm_plane
> > > *plane)>
> > > return;
> > >
> > > state->alpha = 255;
> > >
> > > + state->zpos = plane->type == DRM_PLANE_TYPE_PRIMARY ? 0 : 1;
> > >
> > > plane->state = &state->state;
> > > plane->state->plane = plane;
> > >
> > > @@ -283,6 +285,8 @@ static int
> > > rcar_du_vsp_plane_atomic_set_property(struct drm_plane *plane,>
> > > if (property == rcdu->props.alpha)
> > >
> > > rstate->alpha = val;
> > >
> > > + else if (property == rcdu->props.zpos)
> > > + rstate->zpos = val;
> > >
> > > else
> > >
> > > return -EINVAL;
> > >
> > > @@ -299,6 +303,8 @@ static int
> > > rcar_du_vsp_plane_atomic_get_property(struct drm_plane *plane,>
> > > if (property == rcdu->props.alpha)
> > >
> > > *val = rstate->alpha;
> > >
> > > + else if (property == rcdu->props.zpos)
> > > + *val = rstate->zpos;
> > >
> > > else
> > >
> > > return -EINVAL;
> > >
> > > @@ -378,6 +384,8 @@ int rcar_du_vsp_init(struct rcar_du_vsp *vsp)
> > >
> > > drm_object_attach_property(&plane->plane.base,
> > >
> > > rcdu->props.alpha, 255);
> > >
> > > + drm_object_attach_property(&plane->plane.base,
> > > +rcdu->props.zpos, 1);
> > >
> > > }
> > >
> > > return 0;
> > >
> > > diff --git a/drivers/gpu/drm/rcar-du/rcar_du_vsp.h
> > > b/drivers/gpu/drm/rcar-du/rcar_du_vsp.h index df3bf3805c69..510dcc9c6816
> > > 100644
> > > --- a/drivers/gpu/drm/rcar-du/rcar_du_vsp.h
> > > +++ b/drivers/gpu/drm/rcar-du/rcar_du_vsp.h
> > > @@ -44,6 +44,7 @@ static inline struct rcar_du_vsp_plane
> > > *to_rcar_vsp_plane(struct drm_plane *p)>
> > > * @state: base DRM plane state
> > > * @format: information about the pixel format used by the plane
> > > * @alpha: value of the plane alpha property
> > >
> > > + * @zpos: value of the plane zpos property
> > >
> > > */
> > >
> > > struct rcar_du_vsp_plane_state {
> > >
> > > struct drm_plane_state state;
> > >
> > > @@ -51,6 +52,7 @@ struct rcar_du_vsp_plane_state {
> > >
> > > const struct rcar_du_format_info *format;
> > >
> > > unsigned int alpha;
> > >
> > > + unsigned int zpos;
> >
> > There's lots of effort by various people to create a generic zpos/blending
> > set of properties. Care to jump onto that effort and making it finally
> > happen for real? I kinda don't want to have a propliferation of slightly
> > diffferent zpos/blending props across all the drivers ...
>
> OK, I'll try to. Would you mind if we got these patches merged first for
> v4.7,
> and then switched to a generic property for v4.8 ? The reason is that this
> series depends on a large patch series queued in the linux-media tree for
> v4.7, and it would be easier to handle the dependency by merging these two
> patches in linux-me
[Intel-gfx] [PATCH] libdrm/fourcc: Add formats R8, RG88, GR88
On Thu, Apr 21, 2016 at 08:44:36PM +0300, Hwang, Dongseong wrote: > Ok, I'll send new patch with the commit and tree. You can't do that yet since the commit hasn't landed in upstream. Taking a sha1 from your own tree is useless. My point of noting the sha1 is that it must be from a non-rebasing tree which will land in Linus' tree, so that in the future it can be found again. -Daniel > > Thanks and Regards, > Dongseong > > On Thu, Apr 21, 2016 at 7:02 PM, Emil Velikov > wrote: > > > On 21 April 2016 at 16:32, Dongseong Hwang > > wrote: > > > Follow-up of kernel patch: > > https://lists.freedesktop.org/archives/dri-devel/2015-July/086041.html > > > > > > The Kodi/XBMC and ChromeOS developers want to transcode NV12 to RGB > > > with OpenGL shaders, importing the two source planes through > > > EGL_EXT_image_dma_buf_import. That requires importing the Y plane as an > > > R8 EGLImage and the UV plane as either an RG88 or GR88 EGLImage. > > > > > > > Can we please add a note about the commit and tree where this is based on. > > See how Danel Vetter has done it recently (barring the typo > > -s/fromd/from/). > > > > Thank you ! > > Emil > > > ___ > Intel-gfx mailing list > Intel-gfx at lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/intel-gfx -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch
[PATCH v12 1/2] kernel.h: add u64_to_user_ptr()
On Thu, Apr 21, 2016 at 12:38:49PM -0300, Gustavo Padovan wrote:
> From: Gustavo Padovan
>
> This function had copies in 3 different files. Unify them in kernel.h.
>
> Cc: Joe Perches
> Cc: Andrew Morton
> Cc: David Airlie
> Cc: Daniel Vetter
> Cc: Rob Clark
> Signed-off-by: Gustavo Padovan
Ack for i915 parts for merging through any suitable tree. But since this
mostly touches drm I'd propose we pull this in through drm-misc. Joe?
-Daniel
>
> ---
> v2: add typecheck() (comment from Maarten Lankhorst)
>
> v3: make u64_to_user_ptr() a macro (comment from Joe Perches)
> ---
> drivers/gpu/drm/etnaviv/etnaviv_gem_submit.c | 11 +++
> drivers/gpu/drm/i915/i915_drv.h | 5 -
> drivers/gpu/drm/i915/i915_gem.c | 14 +++---
> drivers/gpu/drm/i915/i915_gem_execbuffer.c | 14 +++---
> drivers/gpu/drm/msm/msm_gem_submit.c | 11 +++
> include/linux/kernel.h | 7 +++
> 6 files changed, 27 insertions(+), 35 deletions(-)
>
> diff --git a/drivers/gpu/drm/etnaviv/etnaviv_gem_submit.c
> b/drivers/gpu/drm/etnaviv/etnaviv_gem_submit.c
> index 236ada9..afdd55d 100644
> --- a/drivers/gpu/drm/etnaviv/etnaviv_gem_submit.c
> +++ b/drivers/gpu/drm/etnaviv/etnaviv_gem_submit.c
> @@ -28,11 +28,6 @@
> #define BO_LOCKED 0x4000
> #define BO_PINNED 0x2000
>
> -static inline void __user *to_user_ptr(u64 address)
> -{
> - return (void __user *)(uintptr_t)address;
> -}
> -
> static struct etnaviv_gem_submit *submit_create(struct drm_device *dev,
> struct etnaviv_gpu *gpu, size_t nr)
> {
> @@ -347,21 +342,21 @@ int etnaviv_ioctl_gem_submit(struct drm_device *dev,
> void *data,
> cmdbuf->exec_state = args->exec_state;
> cmdbuf->ctx = file->driver_priv;
>
> - ret = copy_from_user(bos, to_user_ptr(args->bos),
> + ret = copy_from_user(bos, u64_to_user_ptr(args->bos),
>args->nr_bos * sizeof(*bos));
> if (ret) {
> ret = -EFAULT;
> goto err_submit_cmds;
> }
>
> - ret = copy_from_user(relocs, to_user_ptr(args->relocs),
> + ret = copy_from_user(relocs, u64_to_user_ptr(args->relocs),
>args->nr_relocs * sizeof(*relocs));
> if (ret) {
> ret = -EFAULT;
> goto err_submit_cmds;
> }
>
> - ret = copy_from_user(stream, to_user_ptr(args->stream),
> + ret = copy_from_user(stream, u64_to_user_ptr(args->stream),
>args->stream_size);
> if (ret) {
> ret = -EFAULT;
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index 1048093..bb624cc 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -3576,11 +3576,6 @@ static inline i915_reg_t i915_vgacntrl_reg(struct
> drm_device *dev)
> return VGACNTRL;
> }
>
> -static inline void __user *to_user_ptr(u64 address)
> -{
> - return (void __user *)(uintptr_t)address;
> -}
> -
> static inline unsigned long msecs_to_jiffies_timeout(const unsigned int m)
> {
> unsigned long j = msecs_to_jiffies(m);
> diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
> index dabc089..2889716 100644
> --- a/drivers/gpu/drm/i915/i915_gem.c
> +++ b/drivers/gpu/drm/i915/i915_gem.c
> @@ -324,7 +324,7 @@ i915_gem_phys_pwrite(struct drm_i915_gem_object *obj,
> {
> struct drm_device *dev = obj->base.dev;
> void *vaddr = obj->phys_handle->vaddr + args->offset;
> - char __user *user_data = to_user_ptr(args->data_ptr);
> + char __user *user_data = u64_to_user_ptr(args->data_ptr);
> int ret = 0;
>
> /* We manually control the domain here and pretend that it
> @@ -605,7 +605,7 @@ i915_gem_shmem_pread(struct drm_device *dev,
> int needs_clflush = 0;
> struct sg_page_iter sg_iter;
>
> - user_data = to_user_ptr(args->data_ptr);
> + user_data = u64_to_user_ptr(args->data_ptr);
> remain = args->size;
>
> obj_do_bit17_swizzling = i915_gem_object_needs_bit17_swizzle(obj);
> @@ -692,7 +692,7 @@ i915_gem_pread_ioctl(struct drm_device *dev, void *data,
> return 0;
>
> if (!access_ok(VERIFY_WRITE,
> -to_user_ptr(args->data_ptr),
> +u64_to_user_ptr(args->data_ptr),
> args->size))
> return -EFAULT;
>
> @@ -783,7 +783,7 @@ i915_gem_gtt_pwrite_fast(struct drm_device *dev,
> if (ret)
> goto out_unpin;
>
> - user_data = to_user_ptr(args->data_ptr);
> + user_data = u64_to_user_ptr(args->data_ptr);
> remain = args->size;
>
> offset = i915_gem_obj_ggtt_offset(obj) + args->offset;
> @@ -907,7 +907,7 @@ i915_gem_shmem_pwrite(struct drm_device *dev,
> int needs_clflush_before = 0;
> struct sg_page_iter sg_iter;
>
> - user_data = to_user_ptr(args->data_ptr);
> + us
[PATCH 00/24] drm: add extern C guard for the UAPI headers
On Thu, Apr 21, 2016 at 09:17:13PM +0100, Emil Velikov wrote:
> [Re-sending to the correct mailing list. Apologies if you've seen it already]
>
> Hi all, David Howells
>
> Dave Airlie pointed out that "polluting" the headers in a manner as seen
> with this series might not be too wise. David H, can we hear your view
> on the topic ?
>
> Note that these headers are meant to be used by more than just Linux
> (various BSD and Solaris come to mind), making things more complicated.
>
>
> The change:
>
>
> As some of you may know there are some subtle distinctions between C and
> C++ structs/enums, thus one should wrap/annotate them roughly like below.
>
>
> ...
> #if defined(__cplusplus)
> extern "C" {
> #endif
>
> struct foo {
> int bar;
> ...
> };
>
> ...
>
> #if defined(__cplusplus)
> }
> #endif
>
>
> In order to work around the lack of these users can wrap the header
> inclusion in the same way. For example:
>
>
> ...
> #if defined(__cplusplus)
> extern "C" {
> #endif
>
> #include
>
> #if defined(__cplusplus)
> }
> #endif
>
>
> Yet we should avoid this approach, as it might cause issues [1] [2] [3].
> Thus here is a series which systematically updates all the UAPI headers
> in one go.
>
> I would prefer if we get this merged in one go. Daniel, is it possible
> to go through drm-misc ? The series is already based on it.
>
> Maintainers, does this sound reasonable, can we get a few acks ?
Ack on the concept. I really want that new uapi flows from the kernel,
anything we can do to make conversion to headers suitable for libdrm fully
automatic has my approval - currently we have headaches with divergent
evolution sometimes.
I want this.
-Daniel
>
>
> Thanks
> Emil
>
> [1]
> http://developers.redhat.com/blog/2016/02/29/why-cstdlib-is-more-complicated-than-you-might-think/
> [2] https://isocpp.org/wiki/faq/mixing-c-and-cpp
> [3]
> http://www.oracle.com/technetwork/articles/servers-storage-dev/mixingcandcpluspluscode-305840.html
>
> Cc: Alex Deucher
> Cc: Andrzej Hajda
> Cc: Ben Skeggs
> Cc: Brian Paul
> Cc: Christian Gmeiner
> Cc: Christian König
> Cc: Daniel Vetter
> Cc: Dave Airlie
> Cc: David Howells
> Cc: Eric Anholt
> Cc: Erik Faye-Lund
> Cc: Gerd Hoffmann
> Cc: Inki Dae
> Cc: Jani Nikula
> Cc: Laurent Pinchart
> Cc: Lucas Stach
> Cc: Michel Dänzer
> Cc: Rob Clark
> Cc: Russell King
> Cc: Sinclair Yeh
> Cc: Thierry Reding
> Cc: Thomas Hellstrom
> Cc: Tomi Valkeinen
>
>
> Emil Velikov (24):
> drm/amdgpu: add extern C guard for the UAPI header
> drm/armada: add extern C guard for the UAPI header
> drm: add extern C guard for the UAPI headers
> drm/etnaviv: add extern C guard for the UAPI header
> drm/exynos: add extern C guard for the UAPI header
> drm/i810: add extern C guard for the UAPI header
> drm/i915: add extern C guard for the UAPI header
> drm/mga: add extern C guard for the UAPI header
> drm/msm: add extern C guard for the UAPI header
> drm/nouveau: add extern C guard for the UAPI header
> drm/nouveau: drop drm/ prefix from include
> drm/omap: add extern C guard for the UAPI header
> drm/qxl: add extern C guard for the UAPI header
> drm/qxl: remove XXX comment from the UAPI header
> drm/r128: add extern C guard for the UAPI header
> drm/radeon: add extern C guard for the UAPI header
> drm/savage: add extern C guard for the UAPI header
> drm/sis: add extern C guard for the UAPI header
> drm/sis: add missing include drm.h for the UAPI header
> drm/tegra: add extern C guard for the UAPI header
> drm/vc4: add extern C guard for the UAPI header
> drm/via: add extern C guard for the UAPI header
> drm/virgl: add extern C guard for the UAPI header
> drm/vmwgfx: add extern C guard for the UAPI header
>
> include/uapi/drm/amdgpu_drm.h | 8
> include/uapi/drm/armada_drm.h | 8
> include/uapi/drm/drm.h | 16
> include/uapi/drm/drm_fourcc.h | 8
> include/uapi/drm/drm_mode.h| 8
> include/uapi/drm/drm_sarea.h | 8
> include/uapi/drm/etnaviv_drm.h | 8
> include/uapi/drm/exynos_drm.h | 8
> include/uapi/drm/i810_drm.h| 8
> include/uapi/drm/i915_drm.h| 8
> include/uapi/drm/mga_drm.h | 8
> include/uapi/drm/msm_drm.h | 8
> include/uapi/drm/nouveau_drm.h | 10 +-
> include/uapi/drm/omap_drm.h| 8
> include/uapi/drm/qxl_drm.h | 9 -
> include/uapi/drm/r128_drm.h| 8
> include/uapi/drm/radeon_drm.h | 8
> include/uapi/drm/savage_drm.h | 8
> include/uapi/drm/sis_drm.h | 10 ++
> include/uapi/drm/tegra_drm.h | 8
> include/uapi/drm/vc4_drm.h | 8
> include/uapi/drm/via_drm.h | 8
> include/uapi/drm/virtgpu_drm.h | 8
> include/uapi/drm/vmwgfx_drm.h | 9 +
> 24 files changed, 204 insertions(+), 2
[PATCH 06/24] drm/i810: add extern C guard for the UAPI header
On Thu, Apr 21, 2016 at 09:17:19PM +0100, Emil Velikov wrote:
> Cc: Daniel Vetter
> Signed-off-by: Emil Velikov
>
> ---
>
> Daniel,
>
> Based on earlier chat that his file has never been used by userspace,
> should we just move it for internal usage (to include/drm) ?
The userspace that cares has its own private copy (with different names
even), and this is definitely uapi. I think it should stay in
include/uapi, and maybe for simplicity we simply include it in the set of
headers delivered by libdrm? It certainly doesn't hurt to do so I think.
Ack on this patch, and ack on updating libdrm with it.
-Daniel
>
> Regards,
> Emil
> ---
> include/uapi/drm/i810_drm.h | 8
> 1 file changed, 8 insertions(+)
>
> diff --git a/include/uapi/drm/i810_drm.h b/include/uapi/drm/i810_drm.h
> index bdb0287..6e6cf86 100644
> --- a/include/uapi/drm/i810_drm.h
> +++ b/include/uapi/drm/i810_drm.h
> @@ -3,6 +3,10 @@
>
> #include "drm.h"
>
> +#if defined(__cplusplus)
> +extern "C" {
> +#endif
> +
> /* WARNING: These defines must be the same as what the Xserver uses.
> * if you change them, you must change the defines in the Xserver.
> */
> @@ -280,4 +284,8 @@ typedef struct _drm_i810_mc {
> unsigned int last_render; /* Last Render Request */
> } drm_i810_mc_t;
>
> +#if defined(__cplusplus)
> +}
> +#endif
> +
> #endif /* _I810_DRM_H_ */
> --
> 2.6.2
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
[PATCH 19/24] drm/sis: add missing include drm.h for the UAPI header
On Thu, Apr 21, 2016 at 09:17:32PM +0100, Emil Velikov wrote:
> Signed-off-by: Emil Velikov
If the extern C stuff falls through, maybe we want to pull this one out
ahead?
-Daniel
> ---
> include/uapi/drm/sis_drm.h | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/include/uapi/drm/sis_drm.h b/include/uapi/drm/sis_drm.h
> index 3f7d8ca..3e3f7e9 100644
> --- a/include/uapi/drm/sis_drm.h
> +++ b/include/uapi/drm/sis_drm.h
> @@ -27,6 +27,8 @@
> #ifndef __SIS_DRM_H__
> #define __SIS_DRM_H__
>
> +#include "drm.h"
> +
> #if defined(__cplusplus)
> extern "C" {
> #endif
> --
> 2.6.2
>
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
[PATCH 14/14] MAINTAINERS: Add a bunch of legacy (UMS) DRM drivers
On Fri, Apr 22, 2016 at 12:04:02AM +0100, Emil Velikov wrote: > Pretty much all of these hasn't seen any action singe 2008 at the very > least. Barring the occasional buildfix and DRM-wide refactoring of > course. > > Note: some distributions have stopped shipping their userspace > counterparts for a while. Although some still do. > > Signed-off-by: Emil Velikov > --- > I'm inclined to list these as Obsolete, yet that implies that there's > something better in the works, yet there isn't. > > I believe many people will be happy to see these drivers go, although I > doubt interested parties are about to port them to KMS/DRI2 unless we > make some noise. Like, say, propose their removal ? ;-) If we do this, does get_maintainers.pl still list dri-devel at fd.o and Dave's mail address? Just want to make sure that patches for those won't suddenly disappear out of sight (not that there are many really). -Daniel > --- > MAINTAINERS | 29 + > 1 file changed, 29 insertions(+) > > diff --git a/MAINTAINERS b/MAINTAINERS > index 3774081..c808542 100644 > --- a/MAINTAINERS > +++ b/MAINTAINERS > @@ -3854,6 +3854,11 @@ T: git git://github.com/patjak/drm-gma500 > S: Maintained > F: drivers/gpu/drm/gma500/ > > +DRM DRIVER FOR INTEL I810 VIDEO CARDS > +S: Orphan / Obsolete > +F: drivers/gpu/drm/i810/ > +F: include/uapi/drm/i810_drm.h > + > DRM DRIVER FOR MSM ADRENO GPU > M: Rob Clark > M: Archit Taneja > @@ -3887,11 +3892,21 @@ F:include/linux/host1x.h > F: include/uapi/drm/tegra_drm.h > F: > Documentation/devicetree/bindings/display/tegra/nvidia,tegra20-host1x.txt > > +DRM DRIVER FOR MATROX G200/G400 GRAPHICS CARDS > +S: Orphan / Obsolete > +F: drivers/gpu/drm/mga/ > +F: include/uapi/drm/mga_drm.h > + > DRM DRIVER FOR MGA G200 SERVER GRAPHICS CHIPS > M: Dave Airlie > S: Odd Fixes > F: drivers/gpu/drm/mgag200/ > > +DRM DRIVER FOR RAGE 128 VIDEO CARDS > +S: Orphan / Obsolete > +F: drivers/gpu/drm/r128/ > +F: include/uapi/drm/r128_drm.h > + > DRM DRIVERS FOR RENESAS > M: Laurent Pinchart > L: dri-devel at lists.freedesktop.org > @@ -3916,6 +3931,16 @@ S: Maintained > F: drivers/gpu/drm/rockchip/ > F: Documentation/devicetree/bindings/display/rockchip/ > > +DRM DRIVER FOR SAVAGE VIDEO CARDS > +S: Orphan / Obsolete > +F: drivers/gpu/drm/savage/ > +F: include/uapi/drm/savage_drm.h > + > +DRM DRIVER FOR SIS VIDEO CARDS > +S: Orphan / Obsolete > +F: drivers/gpu/drm/sis/ > +F: include/uapi/drm/sis_drm.h > + > DRM DRIVERS FOR STI > M: Benjamin Gaignard > M: Vincent Abriou > @@ -3925,6 +3950,10 @@ S: Maintained > F: drivers/gpu/drm/sti > F: Documentation/devicetree/bindings/display/st,stih4xx.txt > > +DRM DRIVER FOR TDFX VIDEO CARDS > +S: Orphan / Obsolete > +F: drivers/gpu/drm/tdfx/ > + > DRM DRIVER FOR USB DISPLAYLINK VIDEO ADAPTERS > M: Dave Airlie > S: Odd Fixes > -- > 2.6.2 > > ___ > dri-devel mailing list > dri-devel at lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/dri-devel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch
[Intel-gfx] [PATCH] drm: i915: Improve behavior in case of broken HDMI EDID
On Fri, Apr 22, 2016 at 10:15:20AM +0200, Daniel Vetter wrote:
> On Thu, Apr 21, 2016 at 03:13:51PM -0300, Ezequiel Garcia wrote:
> > Daniel,
> >
> > Thanks a lot for the quick reply!
> >
> > On 20 Apr 01:34 PM, Daniel Vetter wrote:
> > > On Tue, Apr 19, 2016 at 02:31:13PM -0300, Ezequiel Garcia wrote:
> > > > Currently, our implementation of drm_connector_funcs.detect is
> > > > based on getting a valid EDID.
> > > >
> > > > This requirement makes the driver fail to detect connected
> > > > connectors in case of EDID corruption, which in turn prevents
> > > > from falling back to modes provided by builtin or user-provided
> > > > EDIDs.
> > >
> > > Imo, this should be fixed in the probe helpers. Something like the below
> > > might make sense:
> > >
> > >
> > > diff --git a/drivers/gpu/drm/drm_probe_helper.c
> > > b/drivers/gpu/drm/drm_probe_helper.c
> > > index e714b5a7955f..d3b9dc7535da 100644
> > > --- a/drivers/gpu/drm/drm_probe_helper.c
> > > +++ b/drivers/gpu/drm/drm_probe_helper.c
> > > @@ -214,7 +214,10 @@ int drm_helper_probe_single_connector_modes(struct
> > > drm_connector *connector,
> > > else
> > > connector->status = connector_status_disconnected;
> > > if (connector->funcs->force)
> > > - connector->funcs->force(connector);
> > > + connector->funcs->force(connector);
> > > + } else if (connector->override_edid){
> > > + connector->status = connector_status_connected;
> > > + connector->funcs->force(connector);
> > > } else {
> > > connector->status = connector->funcs->detect(connector, true);
> > > }
> > >
> > >
> > > It should do what you want it to do, still allow us to override force
> > > state manually and also fix things up for every, not just i915-hdmi. Also,
> > > much smaller patch.
> > >
> >
> > The patch you are proposing doesn't seem to be related
> > to the issue I want to fix, so maybe my explanation is still
> > unclear. After re-reading my commit log, I came to realize
> > I'm still not explaining the issue properly.
> >
> > Let me try again :-)
> >
> > A user can connect any kind of HDMI monitor to the box, and
> > the kernel should be able to output some video, even when the
> > HDMI monitor is a piece of crap and sends completely broken EDID.
> >
> > Currently, the i915 driver uses the return value of intel_hdmi_set_edid()
> > to set the connector status. IOW, the connector status is set to "connected"
> > *only* if the EDID is correct, and is left as "disconnected" if the EDID
> > is corrupt.
> >
> > However, the connector status can be detected by just probing
> > the I2C bus (drm_probe_ddc).
> >
> > The DRM probe helper relies on the .detect callback to decide if
> > the modes' fallbacks, EDID provided modes, etc are going to be set.
> >
> > It only set those modes if the .detect callback handler returns
> > a "connected" status and does nothing if .detect returns
> > "disconnected".
> >
> > If the connector is reported as "disconnected" it will skip it and
> > the user won't be able to use it (except if the state is forced
> > with a parameter).
> >
> > I am currently shipping intel boxes without monitors, and the
> > user can connect its own monitor. I can't know before hand
> > what device is going to be plugged (neither on which output
> > connector, HDMI, DVI, etc)... so I am not able to force any state.
> >
> > The patch I am proposing makes the kernel work without any
> > user intervention, in the face of corrupted EDID coming out of
> > a monitor. This works because the .detect logic after my patch
> > just checks if a I2C device is present in the bus to mark the
> > connector as "connected" and does not use the EDID parsing for that.
> >
> > In fact, the EDID parsing is moved to .get_modes() since they're
> > not really used before. This at the very least, is consistent with
> > how other drivers work (I'm not inventing anything).
> >
> > Maybe the following commit log is better. How does it look now?
>
> But in that case the only thing you get is the 1024x756 fallback mode.
> You're users are happy with that? I thought your use-case was that you
> need to overwrite the edid anyway, and that doing the edid override alone
> doesn't work. Hence my patch to make stuff work directly with just the
> edid override.
>
> At least I myself wouldn't consider 1024x756 "working" ...
Not sure it's even guaranteed to work with all displays. I can't
remember if HDMI specifies any fallback mode. DP does, but it's
640x480 which isn't entirely useful these days.
--
Ville Syrjälä
Intel OTC
[PATCH 13/15] drm: take references to connectors used in a modeset.
On Fri, Apr 15, 2016 at 03:10:44PM +1000, Dave Airlie wrote:
> From: Dave Airlie
>
> As suggested by Daniel, if we are actively using the connector in a modeset
> we don't want it to disappear from underneath us. This takes a reference
> to the connector in the atomic paths when we are setting the state up,
> and in the non-atomic paths when binding the encoder.
>
> Signed-off-by: Dave Airlie
> ---
> drivers/gpu/drm/drm_atomic.c | 11 ++-
> drivers/gpu/drm/drm_crtc_helper.c | 6 ++
> 2 files changed, 16 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
> index 9d5e3c8..d899dac 100644
> --- a/drivers/gpu/drm/drm_atomic.c
> +++ b/drivers/gpu/drm/drm_atomic.c
> @@ -1159,7 +1159,7 @@ drm_atomic_set_crtc_for_connector(struct
> drm_connector_state *conn_state,
> struct drm_crtc *crtc)
> {
> struct drm_crtc_state *crtc_state;
> -
> + bool had_crtc = conn_state->crtc ? true : false;
> if (conn_state->crtc && conn_state->crtc != crtc) {
> crtc_state =
> drm_atomic_get_existing_crtc_state(conn_state->state,
>
> conn_state->crtc);
> @@ -1179,6 +1179,15 @@ drm_atomic_set_crtc_for_connector(struct
> drm_connector_state *conn_state,
>
> conn_state->crtc = crtc;
>
> + /* If we had no crtc then got one, add a reference,
> + * if we had a crtc and are going to none, drop a reference,
> + * otherwise just keep the reference we have.
> + */
> + if (!had_crtc && crtc)
> + drm_connector_reference(conn_state->connector);
> + else if (!crtc && had_crtc)
> + drm_connector_unreference(conn_state->connector);
> +
> if (crtc)
> DRM_DEBUG_ATOMIC("Link connector state %p to [CRTC:%d:%s]\n",
>conn_state, crtc->base.id, crtc->name);
I'm super paranoid about the refcounting for modesets, since at least with
fbs that was where we had endless amounts of pain and random bugs.
- I think we should split this patch into atomic and legacy parts, since
the code-paths are completely different.
- I'm not sure on the atomic version. I think conceptually it would be
even cleaner for atomic to say that drm_connector_state holds a ref on
the connector iff the crtc pointer is set. This would mean we grab the
reference also in duplicate_state and drop it in destroy_state (and ofc
update it in set_crtc_for_connector). It's a bit funny semantics, but by
attaching the refcounting to the lifetime of the state struct we fully
align with how refcounting is done for everything else in atomic. And
avoiding special cases in refcounting is good imo.
Also since we know that the state structures are tracked correctly I
wouldn't have to think about correctness at all, makes the review easier
;-)
Cheers, Daniel
> diff --git a/drivers/gpu/drm/drm_crtc_helper.c
> b/drivers/gpu/drm/drm_crtc_helper.c
> index 79555d2..71b6c72 100644
> --- a/drivers/gpu/drm/drm_crtc_helper.c
> +++ b/drivers/gpu/drm/drm_crtc_helper.c
> @@ -456,6 +456,9 @@ drm_crtc_helper_disable(struct drm_crtc *crtc)
>* between them is henceforth no longer available.
>*/
> connector->dpms = DRM_MODE_DPMS_OFF;
> +
> + /* we keep a reference while the encoder is bound */
> + drm_connector_unreference(connector);
> }
> }
>
> @@ -635,9 +638,12 @@ int drm_crtc_helper_set_config(struct drm_mode_set *set)
> mode_changed = true;
> /* If the encoder is reused for another connector, then
>* the appropriate crtc will be set later.
> + * take a reference only if we haven't had an encoder
> before.
>*/
> if (connector->encoder)
> connector->encoder->crtc = NULL;
> + else
> + drm_connector_reference(connector);
> connector->encoder = new_encoder;
> }
> }
> --
> 2.5.5
>
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
[Bug 94984] XCom2 crashes with SIGSEGV on radeonsi
https://bugs.freedesktop.org/show_bug.cgi?id=94984 --- Comment #8 from Edwin Smith --- "save498" (crash on load) testing results: Mac OS X - Success Linux 15.10 Nvidia 361.42 - Success Linux 15.10 AMD Mesa 11.3-git1604150730.eeff13 - Crash on load -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20160422/53cea213/attachment.html>
[PATCH 14/15] drm/i915/mst: use reference counted connectors.
On Fri, Apr 15, 2016 at 03:10:45PM +1000, Dave Airlie wrote:
> From: Dave Airlie
>
> Don't just free the connector when we get the destroy callback.
>
> Drop a reference to it, and set it's mst_port to NULL so
> no more mst work is done on it.
>
> Signed-off-by: Dave Airlie
Looks correct, but two comments for better api for shared helpers inline below.
-Daniel
> ---
> drivers/gpu/drm/i915/intel_dp_mst.c | 46
> ++---
> drivers/gpu/drm/i915/intel_drv.h| 2 +-
> 2 files changed, 24 insertions(+), 24 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_dp_mst.c
> b/drivers/gpu/drm/i915/intel_dp_mst.c
> index a2bd698..2e730b6 100644
> --- a/drivers/gpu/drm/i915/intel_dp_mst.c
> +++ b/drivers/gpu/drm/i915/intel_dp_mst.c
> @@ -113,7 +113,7 @@ static void intel_mst_disable_dp(struct intel_encoder
> *encoder)
>
> DRM_DEBUG_KMS("%d\n", intel_dp->active_mst_links);
>
> - drm_dp_mst_reset_vcpi_slots(&intel_dp->mst_mgr, intel_mst->port);
> + drm_dp_mst_reset_vcpi_slots(&intel_dp->mst_mgr,
> intel_mst->connector->port);
>
> ret = drm_dp_update_payload_part1(&intel_dp->mst_mgr);
> if (ret) {
> @@ -138,10 +138,12 @@ static void intel_mst_post_disable_dp(struct
> intel_encoder *encoder)
> /* and this can also fail */
> drm_dp_update_payload_part2(&intel_dp->mst_mgr);
>
> - drm_dp_mst_deallocate_vcpi(&intel_dp->mst_mgr, intel_mst->port);
> + drm_dp_mst_deallocate_vcpi(&intel_dp->mst_mgr,
> intel_mst->connector->port);
>
> intel_dp->active_mst_links--;
> - intel_mst->port = NULL;
> +
> + drm_connector_unreference(&intel_mst->connector->base);
> + intel_mst->connector = NULL;
> if (intel_dp->active_mst_links == 0) {
> intel_dig_port->base.post_disable(&intel_dig_port->base);
> intel_dp_sink_dpms(intel_dp, DRM_MODE_DPMS_OFF);
> @@ -181,7 +183,9 @@ static void intel_mst_pre_enable_dp(struct intel_encoder
> *encoder)
> found->encoder = encoder;
>
> DRM_DEBUG_KMS("%d\n", intel_dp->active_mst_links);
> - intel_mst->port = found->port;
> +
> + intel_mst->connector = found;
> + drm_connector_reference(&intel_mst->connector->base);
>
> if (intel_dp->active_mst_links == 0) {
> intel_prepare_ddi_buffer(&intel_dig_port->base);
> @@ -199,7 +203,7 @@ static void intel_mst_pre_enable_dp(struct intel_encoder
> *encoder)
> }
>
> ret = drm_dp_mst_allocate_vcpi(&intel_dp->mst_mgr,
> -intel_mst->port,
> +intel_mst->connector->port,
> intel_crtc->config->pbn, &slots);
> if (ret == false) {
> DRM_ERROR("failed to allocate vcpi\n");
> @@ -248,7 +252,7 @@ static bool intel_dp_mst_enc_get_hw_state(struct
> intel_encoder *encoder,
> {
> struct intel_dp_mst_encoder *intel_mst = enc_to_mst(&encoder->base);
> *pipe = intel_mst->pipe;
> - if (intel_mst->port)
> + if (intel_mst->connector)
> return true;
> return false;
> }
> @@ -312,6 +316,11 @@ static int intel_dp_mst_get_ddc_modes(struct
> drm_connector *connector)
> struct edid *edid;
> int ret;
>
> + if (!intel_connector->port || !intel_dp) {
> + ret = intel_connector_update_modes(connector, NULL);
> + return ret;
> + }
> +
> edid = drm_dp_mst_get_edid(connector, &intel_dp->mst_mgr,
> intel_connector->port);
> if (!edid)
> return 0;
> @@ -328,6 +337,8 @@ intel_dp_mst_detect(struct drm_connector *connector, bool
> force)
> struct intel_connector *intel_connector = to_intel_connector(connector);
> struct intel_dp *intel_dp = intel_connector->mst_port;
>
> + if (!intel_connector->port || !intel_dp)
> + return connector_status_disconnected;
> return drm_dp_mst_detect_port(connector, &intel_dp->mst_mgr,
> intel_connector->port);
Should we push this change and the preceeding one into dp helpers, i.e.
make them cope with a null port? Otoh more work to fish out the
->mst_mgr, so not sure.
Hm ... isn't the mst_mgr a redundant argument, and we could figure that
out purely from the port? Would be a bit of refactoring, but I think the
shared code for this crucial bit of semantics (there's no way the mst port
is ever connected if it's unplugged) would be good.
> }
>
> @@ -393,6 +404,8 @@ static struct drm_encoder
> *intel_mst_atomic_best_encoder(struct drm_connector *c
> struct intel_dp *intel_dp = intel_connector->mst_port;
> struct intel_crtc *crtc = to_intel_crtc(state->crtc);
>
> + if (!intel_dp)
> + return NULL;
> return &intel_dp->mst_encoders[crtc->pipe]->base.base;
> }
>
> @@ -400,6 +413,8 @@ static struct drm_encoder *intel_mst_best_encoder(struct
> drm_connector *connecto
> {
> struct intel_connector *intel_connector = to_intel_connector(connector
[PATCH v2] libdrm/fourcc: Add formats R8, RG88, GR88, NV24, NV42
I incorrectly interpreted your comments. I thought you want me to reply every feedback. It's first trial for me to contribute on linux. sorry for lots of noise. I've learnt linux practice. next time it will be more smooth. My undesirable behavior doesn't represent CrOS development. CrOS development keeps in mind of product, so also prefers quality and robustness. I checked the change is already landed. Close this patch as WontFix. Thanks you for good guidance. Dongseong On Thu, Apr 21, 2016 at 8:56 PM, Emil Velikov wrote: > On 21 April 2016 at 18:46, Dongseong Hwang > wrote: > > Produced from headers_install of 9dabb0053b63bc32ab6ad5d13209d1e43395313f > > (drm-intel-nightly) in the kernel. > > > > ChromeOS will use new format to optimize video decoding. > > > Did you check before sending the patch out ? > As mentioned over IRC a few times - there's no need for the > update.danvet already sorted it out. > > Also, I realise that CrOS development is quite high paced, although > some of us prefer quality over quantity. Meaning: don't send multiple > emails (spam?) if you have not covered (ideally) all the concerns > mentioned. Not doing so is one of the ways to alienate developers. > > Pretty please ? > > Thanks > Emil > -- next part -- An HTML attachment was scrubbed... URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20160422/75ad6c87/attachment.html>
[PATCH 15/15] drm/radeon/dp_mst: use connector ref counting
On Fri, Apr 15, 2016 at 03:10:46PM +1000, Dave Airlie wrote:
> From: Dave Airlie
>
> Use connector reference counting in radeon mst code.
>
> Signed-off-by: Dave Airlie
> ---
> drivers/gpu/drm/radeon/radeon_dp_mst.c | 5 ++---
> 1 file changed, 2 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/radeon/radeon_dp_mst.c
> b/drivers/gpu/drm/radeon/radeon_dp_mst.c
> index 43cffb5..4f1792a 100644
> --- a/drivers/gpu/drm/radeon/radeon_dp_mst.c
> +++ b/drivers/gpu/drm/radeon/radeon_dp_mst.c
> @@ -242,6 +242,7 @@ radeon_dp_mst_connector_destroy(struct drm_connector
> *connector)
>
> drm_encoder_cleanup(&radeon_encoder->base);
> kfree(radeon_encoder);
> +
> drm_connector_cleanup(connector);
> kfree(radeon_connector);
> }
> @@ -313,11 +314,9 @@ static void radeon_dp_destroy_mst_connector(struct
> drm_dp_mst_topology_mgr *mgr,
> drm_modeset_lock_all(dev);
> /* dpms off */
> radeon_fb_remove_connector(rdev, connector);
Why not drop the force-off here, like for i915?
-Daniel
> -
> - drm_connector_cleanup(connector);
> drm_modeset_unlock_all(dev);
>
> - kfree(connector);
> + drm_connector_unreference(connector);
> DRM_DEBUG_KMS("\n");
> }
>
> --
> 2.5.5
>
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
[PATCH 12/15] drm/modes: add connector reference counting.
On Fri, Apr 15, 2016 at 03:10:43PM +1000, Dave Airlie wrote:
> From: Dave Airlie
>
> This uses the previous changes to add reference counting to the
> drm connector objects.
>
> Signed-off-by: Dave Airlie
Bunch of nitpicks in this one. And I noticed a pretty serious issue we
have with the generic prop code since forever. I'll write testcases and
bugfixes for that (hopefully today).
> ---
> drivers/gpu/drm/drm_atomic.c| 19 +--
> drivers/gpu/drm/drm_crtc.c | 39 ++-
> drivers/gpu/drm/drm_fb_helper.c | 38 ++
> include/drm/drm_crtc.h | 13 -
> 4 files changed, 65 insertions(+), 44 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
> index 8ee1db8..9d5e3c8 100644
> --- a/drivers/gpu/drm/drm_atomic.c
> +++ b/drivers/gpu/drm/drm_atomic.c
> @@ -154,6 +154,7 @@ void drm_atomic_state_default_clear(struct
> drm_atomic_state *state)
>
> state->connector_states[i]);
> state->connectors[i] = NULL;
> state->connector_states[i] = NULL;
> + drm_connector_unreference(connector);
> }
>
> for (i = 0; i < config->num_crtc; i++) {
> @@ -924,6 +925,7 @@ drm_atomic_get_connector_state(struct drm_atomic_state
> *state,
> if (!connector_state)
> return ERR_PTR(-ENOMEM);
>
> + drm_connector_reference(connector);
> state->connector_states[index] = connector_state;
> state->connectors[index] = connector;
> connector_state->state = state;
> @@ -1614,12 +1616,19 @@ retry:
> }
>
> obj = drm_mode_object_find(dev, obj_id, DRM_MODE_OBJECT_ANY);
> - if (!obj || !obj->properties) {
> + if (!obj) {
> + ret = -ENOENT;
> + goto out;
> + }
> +
> + if (!obj->properties) {
> + drm_mode_object_unreference(obj);
> ret = -ENOENT;
> goto out;
> }
>
> if (get_user(count_props, count_props_ptr + copied_objs)) {
> + drm_mode_object_unreference(obj);
> ret = -EFAULT;
> goto out;
> }
> @@ -1632,12 +1641,14 @@ retry:
> struct drm_property *prop;
>
> if (get_user(prop_id, props_ptr + copied_props)) {
> + drm_mode_object_unreference(obj);
> ret = -EFAULT;
> goto out;
> }
>
> prop = drm_property_find(dev, prop_id);
> if (!prop) {
> + drm_mode_object_unreference(obj);
> ret = -ENOENT;
> goto out;
> }
> @@ -1645,13 +1656,16 @@ retry:
> if (copy_from_user(&prop_value,
> prop_values_ptr + copied_props,
> sizeof(prop_value))) {
> + drm_mode_object_unreference(obj);
> ret = -EFAULT;
> goto out;
> }
>
> ret = atomic_set_prop(state, obj, prop, prop_value);
> - if (ret)
> + if (ret) {
> + drm_mode_object_unreference(obj);
> goto out;
> + }
>
> copied_props++;
> }
> @@ -1662,6 +1676,7 @@ retry:
> plane_mask |= (1 << drm_plane_index(plane));
> plane->old_fb = plane->fb;
> }
> + drm_mode_object_unreference(obj);
Could we maybe do something like this to share the unreference calls:
continue;
fail_loop:
drm_mode_object_unreference(obj);
goto out;
And then change all the goto out; in the loop to goto fail_loop;? Just a
suggestion, either is fine with me. I just like common exit code a lot.
> }
>
> if (arg->flags & DRM_MODE_PAGE_FLIP_EVENT) {
> diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
> index f6bf828..90bc597 100644
> --- a/drivers/gpu/drm/drm_crtc.c
> +++ b/drivers/gpu/drm/drm_crtc.c
> @@ -861,6 +861,16 @@ static void drm_connector_get_cmdline_mode(struct
> drm_connector *connector)
> mode->interlace ? " interlaced" : "");
> }
>
> +static void drm_connector_free(struct kref *kref)
> +{
> + struct drm_connector *connector =
> + container_of(kref, struct drm_connector, base.refcount);
> + struct drm_device *dev = connector->dev;
> +
> + drm_mode_object_unregister(dev, &connecto
[Bug 91202] Output to DVI-I (or DVI-D) is blank on Tonga (R9 285 and 380X) with multiple monitors
https://bugs.freedesktop.org/show_bug.cgi?id=91202 --- Comment #12 from Marco Wentsch --- Created attachment 123142 --> https://bugs.freedesktop.org/attachment.cgi?id=123142&action=edit xrandr --verbose output with DVI-I-0 in a working 1680x1050 mode -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20160422/e8cda20a/attachment-0001.html>
[Bug 91202] Output to DVI-I (or DVI-D) is blank on Tonga (R9 285 and 380X) with multiple monitors
https://bugs.freedesktop.org/show_bug.cgi?id=91202 --- Comment #13 from Marco Wentsch --- Created attachment 123143 --> https://bugs.freedesktop.org/attachment.cgi?id=123143&action=edit Xorg.log -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20160422/c4c5e128/attachment.html>
[Bug 91202] Output to DVI-I (or DVI-D) is blank on Tonga (R9 285 and 380X) with multiple monitors
https://bugs.freedesktop.org/show_bug.cgi?id=91202 --- Comment #14 from Marco Wentsch --- hi, i have the same issue on Ubuntu 16.04 LTS final. I tried to upgrade the kernel to 4.6 rc4 by self compile but nothing have changed, it doesn't work. My graphiccard: 01:00.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI] Amethyst XT [Radeon R9 M295X Mac Edition / R9 380X] (rev f1) XFX R9 380X DD Black Edition OC On HDMI-A-0 it works on native solution on DVI-I-1 its does not work on native solutions but on 1680x1050, i have choose at the moment 1600x900 because it looks better befor i upgrade i have ubuntu 15.10 (fgrlx and amdgpu) with the orginal kernel and self compiled 4.3 with kvm patches and with both driver it works. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20160422/6a6f1aac/attachment.html>
[PATCH 04/14] MAINTAINERS: Update the files list for the GMA500 DRM driver
On Fri, Apr 22, 2016 at 1:03 AM, Emil Velikov wrote: > Cc: Patrik Jakobsson > Cc: dri-devel at lists.freedesktop.org > Signed-off-by: Emil Velikov > --- > MAINTAINERS | 3 +-- > 1 file changed, 1 insertion(+), 2 deletions(-) > > diff --git a/MAINTAINERS b/MAINTAINERS > index 17dc561..205b3c1 100644 > --- a/MAINTAINERS > +++ b/MAINTAINERS > @@ -3837,8 +3837,7 @@ M:Patrik Jakobsson gmail.com> > L: dri-devel at lists.freedesktop.org > T: git git://github.com/patjak/drm-gma500 > S: Maintained > -F: drivers/gpu/drm/gma500 > -F: include/drm/gma500* There is actually a header file for gma500 (include/drm/gma_drm.h) but that one is empty so this looks good (I'll remove gma_drm.h). Acked-by: Patrik Jakobsson > +F: drivers/gpu/drm/gma500/ > > DRM DRIVERS FOR NVIDIA TEGRA > M: Thierry Reding > -- > 2.6.2 >
[PATCH 5/9] drm/i915: Enable i915 perf stream for Haswell OA unit
On Wed, Apr 20, 2016 at 11:46 PM, Chris Wilson
wrote:
> On Wed, Apr 20, 2016 at 03:23:10PM +0100, Robert Bragg wrote:
> > +static void gen7_init_oa_buffer(struct drm_i915_private *dev_priv)
> > +{
> > + /* Pre-DevBDW: OABUFFER must be set with counters off,
> > + * before OASTATUS1, but after OASTATUS2
> > + */
> > + I915_WRITE(GEN7_OASTATUS2, dev_priv->perf.oa.oa_buffer.gtt_offset |
> > +OA_MEM_SELECT_GGTT); /* head */
> > + I915_WRITE(GEN7_OABUFFER, dev_priv->perf.oa.oa_buffer.gtt_offset);
> > + I915_WRITE(GEN7_OASTATUS1, dev_priv->perf.oa.oa_buffer.gtt_offset |
> > +OABUFFER_SIZE_16M); /* tail */
> > +
> > + /* On Haswell we have to track which OASTATUS1 flags we've
> > + * already seen since they can't be cleared while periodic
> > + * sampling is enabled.
> > + */
> > + dev_priv->perf.oa.gen7_latched_oastatus1 = 0;
> > +
> > + /* We have a sanity check in gen7_append_oa_reports() that
> > + * looks at the report-id field to make sure it's non-zero
> > + * which relies on the assumption that new reports are
> > + * being written to zeroed memory...
> > + */
> > + memset(dev_priv->perf.oa.oa_buffer.addr, 0, SZ_16M);
>
> You allocated zeroed memory.
>
yup. currently I have this memset here because we may re-init the buffer if
the stream is disabled then re-enabled (via I915_PERF_IOCTL_ENABLE) or if
we have to reset the unit on error. In these cases there may be some number
of reports in the buffer with non-zero report-id fields while we still want
to be sure new reports are being written to zereod memory so that the
sanity check that report-id != 0 will continue to be valid.
I've had it in mind to consider optimizing this at some point to minimize
how much of the buffer is cleared, maybe just for the _DISABLE/_ENABLE case
where I'd expect the buffer will mostly be empty before disabling the
stream.
- Robert
-Chris
>
> --
> Chris Wilson, Intel Open Source Technology Centre
>
-- next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160422/9f807cc3/attachment.html>
[PATCH v3 1/2] drm: bridge: Add sii902x driver
Hi Boris,
> -Original Message-
> From: Boris Brezillon [mailto:boris.brezillon at free-electrons.com]
> +
> +static int sii902x_bridge_attach(struct drm_bridge *bridge) {
> + const struct drm_connector_funcs *funcs = &sii902x_connector_funcs;
> + struct sii902x *sii902x = bridge_to_sii902x(bridge);
> + struct drm_device *drm = bridge->dev;
> + int ret;
> +
> + drm_connector_helper_add(&sii902x->connector,
> + &sii902x_connector_helper_funcs);
> +
> + if (drm_core_check_feature(drm, DRIVER_ATOMIC))
> + funcs = &sii902x_atomic_connector_funcs;
> +
> + ret = drm_connector_init(drm, &sii902x->connector, funcs,
> + DRM_MODE_CONNECTOR_HDMIA);
> + if (ret)
> + return ret;
> +
I think drm_connector_register should be used here, or drmlib can't find this
connector.
> + if (sii902x->i2c->irq > 0)
> + sii902x->connector.polled = DRM_CONNECTOR_POLL_HPD;
> + else
> + sii902x->connector.polled =
> DRM_CONNECTOR_POLL_CONNECT;
> +
> + drm_mode_connector_attach_encoder(&sii902x->connector,
> +bridge->encoder);
> +
> + return 0;
> +}
> +
...
> +
> +static int sii902x_probe(struct i2c_client *client,
> + const struct i2c_device_id *id)
> +{
> + struct device *dev = &client->dev;
> + unsigned int status = 0;
> + struct sii902x *sii902x;
> + u8 chipid[4];
> + int ret;
> +
> + sii902x = devm_kzalloc(dev, sizeof(*sii902x), GFP_KERNEL);
> + if (!sii902x)
> + return -ENOMEM;
> +
> + sii902x->i2c = client;
> + sii902x->regmap = devm_regmap_init_i2c(client,
> &sii902x_regmap_config);
> + if (IS_ERR(sii902x->regmap))
> + return PTR_ERR(sii902x->regmap);
> +
> + sii902x->reset_gpio = devm_gpiod_get(dev, "reset",
> GPIOD_OUT_LOW);
> + if (IS_ERR(sii902x->reset_gpio)) {
> + dev_err(dev, "Failed to retrieve/request reset gpio: %ld\n",
> + PTR_ERR(sii902x->reset_gpio));
> + return PTR_ERR(sii902x->reset_gpio);
Maybe we can use "warning" instead of "dev_err" if there is no "reset_gpio" ,
because some board using CPLD to manage the reset order , they can't reset the
HDMI chip independently.
> + }
> +
> + sii902x_reset(sii902x);
> +
Regards,
Meng
[PATCH 5/9] drm/i915: Enable i915 perf stream for Haswell OA unit
On Fri, Apr 22, 2016 at 12:04:26PM +0100, Robert Bragg wrote:
>On Wed, Apr 20, 2016 at 11:46 PM, Chris Wilson
><[1]chris at chris-wilson.co.uk> wrote:
>
> On Wed, Apr 20, 2016 at 03:23:10PM +0100, Robert Bragg wrote:
> > +static void gen7_init_oa_buffer(struct drm_i915_private *dev_priv)
> > +{
> > +Â Â Â /* Pre-DevBDW: OABUFFER must be set with counters off,
> > +Â Â Â * before OASTATUS1, but after OASTATUS2
> > +Â Â Â */
> > +Â Â Â I915_WRITE(GEN7_OASTATUS2,
> dev_priv->perf.oa.oa_buffer.gtt_offset |
> > +Â Â Â Â Â Â Â Â OA_MEM_SELECT_GGTT); /* head */
> > +Â Â Â I915_WRITE(GEN7_OABUFFER,
> dev_priv->perf.oa.oa_buffer.gtt_offset);
> > +Â Â Â I915_WRITE(GEN7_OASTATUS1,
> dev_priv->perf.oa.oa_buffer.gtt_offset |
> > +Â Â Â Â Â Â Â Â OABUFFER_SIZE_16M); /* tail */
> > +
> > +Â Â Â /* On Haswell we have to track which OASTATUS1 flags we've
> > +Â Â Â * already seen since they can't be cleared while periodic
> > +Â Â Â * sampling is enabled.
> > +Â Â Â */
> > +Â Â Â dev_priv->perf.oa.gen7_latched_oastatus1 = 0;
> > +
> > +Â Â Â /* We have a sanity check in gen7_append_oa_reports() that
> > +Â Â Â * looks at the report-id field to make sure it's non-zero
> > +Â Â Â * which relies on the assumption that new reports are
> > +Â Â Â * being written to zeroed memory...
> > +Â Â Â */
> > +Â Â Â memset(dev_priv->perf.oa.oa_buffer.addr, 0, SZ_16M);
>
> You allocated zeroed memory.
>
>yup. currently I have this memset here because we may re-init the buffer
>if the stream is disabled then re-enabled (via I915_PERF_IOCTL_ENABLE) or
>if we have to reset the unit on error. In these cases there may be some
>number of reports in the buffer with non-zero report-id fields while we
>still want to be sure new reports are being written to zereod memory so
>that the sanity check that report-id != 0 will continue to be valid.
>
>I've had it in mind to consider optimizing this at some point to minimize
>how much of the buffer is cleared, maybe just for the _DISABLE/_ENABLE
>case where I'd expect the buffer will mostly be empty before disabling the
>stream.
Or just make it clear that you are considering buffer reuse. Having the
memset here allows us to use non-shmemfs allocation, it wasn't that I
objected I just didn't understand the comment in the context of
allocation path.
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
[PATCH v3 1/2] drm: bridge: Add sii902x driver
Hi Meng,
On Fri, 22 Apr 2016 09:58:34 +
Meng Yi wrote:
> Hi Boris,
>
> > -Original Message-
> > From: Boris Brezillon [mailto:boris.brezillon at free-electrons.com]
> > +
>
> > +static int sii902x_bridge_attach(struct drm_bridge *bridge) {
> > + const struct drm_connector_funcs *funcs = &sii902x_connector_funcs;
> > + struct sii902x *sii902x = bridge_to_sii902x(bridge);
> > + struct drm_device *drm = bridge->dev;
> > + int ret;
> > +
> > + drm_connector_helper_add(&sii902x->connector,
> > +&sii902x_connector_helper_funcs);
> > +
> > + if (drm_core_check_feature(drm, DRIVER_ATOMIC))
> > + funcs = &sii902x_atomic_connector_funcs;
> > +
> > + ret = drm_connector_init(drm, &sii902x->connector, funcs,
> > +DRM_MODE_CONNECTOR_HDMIA);
> > + if (ret)
> > + return ret;
> > +
>
>
> I think drm_connector_register should be used here, or drmlib can't find this
> connector.
Hm, I think this should be left to the DRM master device
(some of them already call drm_connector_register_all() at the end of
their ->probe() function).
>
>
> > + if (sii902x->i2c->irq > 0)
> > + sii902x->connector.polled = DRM_CONNECTOR_POLL_HPD;
> > + else
> > + sii902x->connector.polled =
> > DRM_CONNECTOR_POLL_CONNECT;
> > +
> > + drm_mode_connector_attach_encoder(&sii902x->connector,
> > +bridge->encoder);
> > +
> > + return 0;
> > +}
> > +
>
> ...
> > +
> > +static int sii902x_probe(struct i2c_client *client,
> > +const struct i2c_device_id *id)
> > +{
> > + struct device *dev = &client->dev;
> > + unsigned int status = 0;
> > + struct sii902x *sii902x;
> > + u8 chipid[4];
> > + int ret;
> > +
> > + sii902x = devm_kzalloc(dev, sizeof(*sii902x), GFP_KERNEL);
> > + if (!sii902x)
> > + return -ENOMEM;
> > +
> > + sii902x->i2c = client;
> > + sii902x->regmap = devm_regmap_init_i2c(client,
> > &sii902x_regmap_config);
> > + if (IS_ERR(sii902x->regmap))
> > + return PTR_ERR(sii902x->regmap);
> > +
> > + sii902x->reset_gpio = devm_gpiod_get(dev, "reset",
> > GPIOD_OUT_LOW);
> > + if (IS_ERR(sii902x->reset_gpio)) {
> > + dev_err(dev, "Failed to retrieve/request reset gpio: %ld\n",
> > + PTR_ERR(sii902x->reset_gpio));
> > + return PTR_ERR(sii902x->reset_gpio);
>
>
> Maybe we can use "warning" instead of "dev_err" if there is no "reset_gpio"
> , because some board using CPLD to manage the reset order , they can't reset
> the HDMI chip independently.
Sure, since it's optional maybe we should use dev_info().
Thanks for your review.
Regards,
Boris
--
Boris Brezillon, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
[PATCH v2 2/4] dt-bindings: Add jdi lt070me05000 panel bindings
On Fri, Apr 22, 2016 at 12:25:52PM +0530, Vinay Simha wrote: > On Thu, Apr 21, 2016 at 9:15 PM, Rob Herring wrote: > > On Wed, Apr 20, 2016 at 03:02:31PM +0530, Vinay Simha BN wrote: > >> Add documentation for lt070me05000 panel > >> > >> Signed-off-by: Vinay Simha BN > >> --- > >> .../bindings/display/panel/jdi,lt070me05000.txt| 43 > >> ++ > >> 1 file changed, 43 insertions(+) > >> create mode 100644 > >> Documentation/devicetree/bindings/display/panel/jdi,lt070me05000.txt > >> > >> diff --git > >> a/Documentation/devicetree/bindings/display/panel/jdi,lt070me05000.txt > >> b/Documentation/devicetree/bindings/display/panel/jdi,lt070me05000.txt > >> new file mode 100644 > >> index 000..ffe0550 > >> --- /dev/null > >> +++ b/Documentation/devicetree/bindings/display/panel/jdi,lt070me05000.txt > >> @@ -0,0 +1,43 @@ > >> +JDI model LT070ME05000 1200x1920 7" DSI Panel > >> + > >> +Required properties: > >> +- compatible: should be "jdi,lt070me05000" > >> +- power-supply: phandle of the regulator that provides the supply voltage > >> + IOVCC , power supply for LCM (1.8V) > >> +- vddp-supply: phandle of the regulator that provides the supply voltage > >> + Power IC supply (3-5V) > >> +- dcdc_en-supply: phandle of the regulator that provides the supply > >> voltage > >> + Power IC supply enable, High active > >> +- reset-gpio: phandle of gpio for reset line > >> + This should be 8mA, gpio can be configured using mux and pinctrl. > >> + XRES, Reset, Low active > >> +- enable-gpio: phandle of gpio for enable line > >> + LED_EN, LED backlight enable, High active > > > > These should all be -gpios instead. > will implement in v3 > > > >> +- vcc-gpio: phandle of regulator/gpio that provides the supply voltage > >> + VDD, LED power supply (3-5V) > > > > Is it a regulator or gpio? > > > VDD is LED power supply, but in nexus 7 2nd gen they are using gpio 23 > instead of regulator. > if we use vcc-supply, not sure we can give the gpio device tree entry > to it in nexus 7 dts. Any inputs ? You can model it as a fixed regulator that's enabled by a GPIO. See: Documentation/devicetree/bindings/regulator/fixed-regulator.txt > >> + > >> +Optional properties: > >> +- pwm-gpio: phandle of gpio/pwm > > > > This should use the PWM binding. It may not be a GPIO on some hosts. > > pwm-gpio will go to the backlight (pwm). right now it is not used > since pwm pm8921 upstream driver is not yet implemented. Shall i > remove this pwm-gpio now and the backlight property when pwm pm8921 is > implemented? This suggests to me that you don't have a good idea yet what the final binding would need to look like, so it might be better to get all the dependencies in place first so that the binding can be validated to work properly. Thierry -- next part -- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: not available URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20160422/16ab3612/attachment.sig>
[PATCH 20/24] drm/tegra: add extern C guard for the UAPI header
On Thu, Apr 21, 2016 at 09:17:33PM +0100, Emil Velikov wrote: > Cc: Erik Faye-Lund > Cc: Thierry Reding > Signed-off-by: Emil Velikov > --- > include/uapi/drm/tegra_drm.h | 8 > 1 file changed, 8 insertions(+) Acked-by: Thierry Reding -- next part -- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: not available URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20160422/3ceceee0/attachment.sig>
i.MX6 imx-drm framebuffer rotation. Kernel 3.14.52.
Am Freitag, den 22.04.2016, 15:21 +0300 schrieb Ivan Nikolaenko: > Hi, Phillip! > > Thank you for the fast responce. > Ifollowed your adviceandrealized thatIincorrectlyformulatedthought. I > need a 180 degree rotation, not the flip. > I got the vertical flip (screen reflected by Y axis), butmy attempt to > reflect it by X axis (xrandr --output DISP3\ BG --reflect x) failed > (nothing happened). That is because the IDMAC controller considers the VF bit when calculating the line start addresses (so reflect Y works) but completely ignores the HF bit. The IC has a line buffer that is sampled backwards if the HF bit is set. > Is there a way to do 180deg rotation somehow? If your display is < 1024 pixels in both width and height, it should be possible to get reflect x functionality by hooking up the IC -> DMFC direct flow. regards Philipp
[PATCH v8 11/11] drm: sti: Add DRM driver itself
On Wed, Jul 30, 2014 at 7:42 PM, Benjamin Gaignard
wrote:
> +static int sti_drm_crtc_page_flip(struct drm_crtc *crtc,
> + struct drm_framebuffer *fb,
> + struct drm_pending_vblank_event *event,
> + uint32_t page_flip_flags)
> +{
> + struct drm_device *drm_dev = crtc->dev;
> + struct drm_framebuffer *old_fb;
> + struct sti_mixer *mixer = to_sti_mixer(crtc);
> + unsigned long flags;
> + int ret;
> +
> + DRM_DEBUG_KMS("fb %d --> fb %d\n",
> + crtc->primary->fb->base.id, fb->base.id);
> +
> + mutex_lock(&drm_dev->struct_mutex);
struct_mutex locking here is pure cargo-cult. Please remove asap.
-Daniel
> +
> + old_fb = crtc->primary->fb;
> + crtc->primary->fb = fb;
> + ret = sti_drm_crtc_mode_set_base(crtc, crtc->x, crtc->y, old_fb);
> + if (ret) {
> + DRM_ERROR("failed\n");
> + crtc->primary->fb = old_fb;
> + goto out;
> + }
> +
> + if (event) {
> + event->pipe = mixer->id;
> +
> + ret = drm_vblank_get(drm_dev, event->pipe);
> + if (ret) {
> + DRM_ERROR("Cannot get vblank\n");
> + goto out;
> + }
> +
> + spin_lock_irqsave(&drm_dev->event_lock, flags);
> + if (mixer->pending_event) {
> + drm_vblank_put(drm_dev, event->pipe);
> + ret = -EBUSY;
> + } else {
> + mixer->pending_event = event;
> + }
> + spin_unlock_irqrestore(&drm_dev->event_lock, flags);
> + }
> +out:
> + mutex_unlock(&drm_dev->struct_mutex);
> + return ret;
> +}
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
[PATCH 00/10] drm/sti: debugfs
On Fri, Feb 12, 2016 at 10:13:59AM +0100, Vincent Abriou wrote: > Those patches introduce debugfs for connector, encoder, crtc and planes. > It adds the following entries: > - planes: >gdpx / gdpx_node >hqvdp >cursor >vid >fps_get / fps_show > > - crtc: >mixer_aux / mixer_main > > - encoder: >tvout > > - connectors: >hda >hdmi >dvo Just noticed that all your debugfs files lock dev->struct_mutex. That's pure cargo-cult garbage. Please fix asap and replace the useless locking you have with the right ones where needed (e.g. modeset structures where never protected by dev->struct_mutex). Did someone bother to review the locking in these patches? Thanks, Daniel > > Vincent Abriou (10): > drm/sti: add debugfs entries for HDMI connector > drm/sti: add debugfs entries for DVO connector > drm/sti: add debugfs entries for HDA connector > drm/sti: add debugfs entries for CURSOR plane > drm/sti: add debugfs entries for GDP planes > drm/sti: add debugfs entries for HQVDP plane > drm/sti: add debugfs entries for VID plane > drm/sti: add debugfs entries for MIXER crtc > drm/sti: add debugfs entries for TVOUT encoders > drm/sti: add debugfs fps_show/fps_get mechanism for planes > > drivers/gpu/drm/sti/sti_compositor.c | 4 +- > drivers/gpu/drm/sti/sti_cursor.c | 81 +++ > drivers/gpu/drm/sti/sti_drv.c| 128 ++ > drivers/gpu/drm/sti/sti_dvo.c| 70 ++ > drivers/gpu/drm/sti/sti_gdp.c| 238 > drivers/gpu/drm/sti/sti_hda.c| 105 ++- > drivers/gpu/drm/sti/sti_hdmi.c | 175 +++- > drivers/gpu/drm/sti/sti_hdmi.h | 4 +- > drivers/gpu/drm/sti/sti_hqvdp.c | 254 > ++- > drivers/gpu/drm/sti/sti_mixer.c | 146 +++- > drivers/gpu/drm/sti/sti_mixer.h | 4 +- > drivers/gpu/drm/sti/sti_plane.c | 63 + > drivers/gpu/drm/sti/sti_plane.h | 17 +++ > drivers/gpu/drm/sti/sti_tvout.c | 157 ++ > drivers/gpu/drm/sti/sti_vid.c| 94 - > drivers/gpu/drm/sti/sti_vid.h| 4 +- > 16 files changed, 1524 insertions(+), 20 deletions(-) > > -- > 1.9.1 > > ___ > dri-devel mailing list > dri-devel at lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/dri-devel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch
[PATCH 4/8] drm/fb-helper: Add fb_deferred_io support
Den 22.04.2016 10:27, skrev Daniel Vetter:
> On Thu, Apr 21, 2016 at 08:54:45PM +0200, Noralf Trønnes wrote:
>> Den 20.04.2016 17:25, skrev Noralf Trønnes:
>>> This adds deferred io support if CONFIG_FB_DEFERRED_IO is enabled.
>>> Accumulated fbdev framebuffer changes are signaled using the callback
>>> (struct drm_framebuffer_funcs *)->dirty()
>>>
>>> The drm_fb_helper_sys_*() functions will accumulate changes and
>>> schedule fb_info.deferred_work _if_ fb_info.fbdefio is set.
>>> This worker is used by the deferred io mmap code to signal that it
>>> has been collecting page faults. The page faults and/or other changes
>>> are then merged into a drm_clip_rect and passed to the framebuffer
>>> dirty() function.
>>>
>>> The driver is responsible for setting up the fb_info.fbdefio structure
>>> and calling fb_deferred_io_init() using the provided callback:
>>> (struct fb_deferred_io).deferred_io = drm_fb_helper_deferred_io;
>>>
>>> Signed-off-by: Noralf Trønnes
>>> ---
>>> drivers/gpu/drm/drm_fb_helper.c | 119
>>> +++-
>>> include/drm/drm_fb_helper.h | 15 +
>>> 2 files changed, 133 insertions(+), 1 deletion(-)
>>>
>>> diff --git a/drivers/gpu/drm/drm_fb_helper.c
>>> b/drivers/gpu/drm/drm_fb_helper.c
>> [...]
>>
>>> +#ifdef CONFIG_FB_DEFERRED_IO
>>> +/**
>>> + * drm_fb_helper_deferred_io() - (struct fb_deferred_io *)->deferred_io
>>> callback
>>> + * function
>>> + *
>>> + * This function always runs in process context (struct delayed_work) and
>>> calls
>>> + * the (struct drm_framebuffer_funcs)->dirty function with the collected
>>> + * damage. There's no need to worry about the possibility that the
>>> fb_sys_*()
>>> + * functions could be running in atomic context. They only schedule the
>>> + * delayed worker which then calls this deferred_io callback.
>>> + */
>>> +void drm_fb_helper_deferred_io(struct fb_info *info,
>>> + struct list_head *pagelist)
>>> +{
>>> + struct drm_fb_helper *helper = info->par;
>>> + unsigned long start, end, min, max;
>>> + struct drm_clip_rect clip;
>>> + unsigned long flags;
>>> + struct page *page;
>>> +
>>> + if (!helper->fb->funcs->dirty)
>>> + return;
>>> +
>>> + spin_lock_irqsave(&helper->dirty_lock, flags);
>>> + clip = helper->dirty_clip;
>>> + drm_clip_rect_reset(&helper->dirty_clip);
>>> + spin_unlock_irqrestore(&helper->dirty_lock, flags);
>>> +
>>> + min = ULONG_MAX;
>>> + max = 0;
>>> + list_for_each_entry(page, pagelist, lru) {
>>> + start = page->index << PAGE_SHIFT;
>>> + end = start + PAGE_SIZE - 1;
>>> + min = min(min, start);
>>> + max = max(max, end);
>>> + }
>>> +
>>> + if (min < max) {
>>> + struct drm_clip_rect mmap_clip;
>>> +
>>> + mmap_clip.x1 = 0;
>>> + mmap_clip.x2 = info->var.xres;
>>> + mmap_clip.y1 = min / info->fix.line_length;
>>> + mmap_clip.y2 = min_t(u32, max / info->fix.line_length,
>>> +info->var.yres);
>>> + drm_clip_rect_merge(&clip, &mmap_clip, 1, 0, 0, 0);
>>> + }
>>> +
>>> + if (!drm_clip_rect_is_empty(&clip))
>>> + helper->fb->funcs->dirty(helper->fb, NULL, 0, 0, &clip, 1);
>>> +}
>>> +EXPORT_SYMBOL(drm_fb_helper_deferred_io);
>> There is one thing I have wondered about when it comes to deferred io and
>> long run times for the defio worker with my displays:
>>
>> Userspace writes to some pages then the deferred io worker kicks off and
>> runs for 100ms holding the page list mutex. While this is happening,
>> userspace writes to a new page triggering a page_mkwrite. Now this
>> function has to wait for the mutex to be released.
>>
>> Who is actually waiting here and is there a problem that this can last
>> for 100ms?
> No idea at all - I haven't looked that closely at fbdev defio. But one
> reason we have an explicit ioctl in drm to flush out frontbuffer rendering
> is exactly that flushing could take some time, and should only be done
> once userspace has completed some rendering. Not right in the middle of an
> op.
>
> I guess fix up your userspace to use dumb drm fb + drm dirtyfb ioctl?
> Otherwise you'll get to improve fbdev defio, and fbdev is deprecated
> subsystem and a real horror show. I highly recommend against touching it
> ;-)
I have tried to track the call chain and it seems to be part of the
page fault handler. Which means it's userspace wanting to write to the
page that has to wait. And it has to wait at some random point in
whatever rendering it's doing.
Unless someone has any objections, I will make a change and add a worker
like qxl does. This decouples the deferred_io worker holding the mutex
from the framebuffer flushing job. However I intend to differ from qxl in
that I will use a delayed worker (run immediately from the mmap side which
has already been deferred). Since I don't see any point in flushing the
fram
[PATCH 12/14] MAINTAINERS: Add maintainer entry for the VMWGFX DRM driver
Hi, On Fri, Apr 22, 2016 at 12:04:00AM +0100, Emil Velikov wrote: > Thomas is one of the original authors of the driver, with recent > contributions from Sinclair and Brian. > > Cc: Sinclair Yeh > Cc: Thomas Hellstrom > Cc: Brian Paul > Cc: "VMware Graphics" > Signed-off-by: Emil Velikov > --- > Gents can anyone confirm if the data is correct ? You can also add me as a maintainer for vmwgfx if you like. > > I'm thinking that the status should be Supported, although the driver > hasn't see much action recently. > > NOTE: The following email linux-graphics-maintainer at vmware.com is also > listed for the VMMOUSE driver. Is that correct ? Yes, correct since it's the same team that maintains the vmmouse driver. Sinclair > --- > MAINTAINERS | 8 > 1 file changed, 8 insertions(+) > > diff --git a/MAINTAINERS b/MAINTAINERS > index da88d74..e8ad8b1 100644 > --- a/MAINTAINERS > +++ b/MAINTAINERS > @@ -3909,6 +3909,14 @@ F: drivers/gpu/drm/etnaviv/ > F: include/uapi/drm/etnaviv_drm.h > F: Documentation/devicetree/bindings/display/etnaviv/ > > +DRM DRIVER FOR VMWARE VIRTUAL GPU > +M: "VMware Graphics" > +M: Thomas Hellstrom > +L: dri-devel at lists.freedesktop.org > +S: Maintained / Supported > +F: drivers/gpu/drm/vmwgfx/ > +F: include/uapi/drm/vmwgfx_drm.h > + > DSBR100 USB FM RADIO DRIVER > M: Alexey Klimov > L: linux-media at vger.kernel.org > -- > 2.6.2 >
i.MX6 imx-drm framebuffer rotation. Kernel 3.14.52.
Hi, Phillip! Thank you for the fast responce. Ifollowed your adviceandrealized thatIincorrectlyformulatedthought. I need a 180 degree rotation, not the flip. I got the vertical flip (screen reflected by Y axis), butmy attempt to reflect it by X axis (xrandr --output DISP3\ BG --reflect x) failed (nothing happened). Is there a way to do 180deg rotation somehow? On 21.04.2016 16:16, Philipp Zabel wrote: > to do a 180 degree vertical flip of the framebuffer using imx-drm > >upon kernel initialization. But I can see th Best regards, Ivan Nikolaenko. i.nikolaenko at geoscan.aero
bug in autoloading of imx-ipuv3-crtc
On Thursday, April 21, 2016 1:03:17 AM CDT Uwe Kleine-König wrote:
> Hello,
>
> On Tue, Apr 19, 2016 at 03:16:01PM -0500, Dennis Gilmore wrote:
> > On Tuesday, April 19, 2016 2:27:17 PM CDT Dennis Gilmore wrote:
> > > On Tuesday, April 19, 2016 7:50:49 PM CDT Russell King - ARM Linux
wrote:
> > > > On Tue, Apr 19, 2016 at 01:34:23PM -0500, Dennis Gilmore wrote:
> > > > > on all of my i.MX6 systems imx-ipuv3-crtc ius not getting
> > > > > automatically
> > > > > loaded. Everything is built as a module
> > > > >
> > > > > CONFIG_DRM_IMX=m
> > > > > CONFIG_DRM_IMX_FB_HELPER=m
> > > > > CONFIG_DRM_IMX_HDMI=m
> > > > > CONFIG_DRM_IMX_IPUV3=m
> > > > > CONFIG_DRM_IMX_LDB=m
> > > > > CONFIG_DRM_IMX_PARALLEL_DISPLAY=m
> > > > > CONFIG_DRM_IMX_TVE=m
> > > > > CONFIG_IMX_IPUV3_CORE=m
> > > > >
> > > > > The result is that until I log in via serial or ssh and modprobe the
> > > > > module there is no display. I suspect that there is some devicetree
> > > > > glue missing 4.4 and 4.5 seem to both be effected.
> > > >
> > > > DT doesn't come into it for imx-ipuv3-crtc - these platform devices
> > > > are
> > > > created by drivers/gpu/ipu-v3/ipu-common.c itself.
> > > >
> > > > drivers/gpu/drm/imx/ipuv3-crtc.c contains the proper module alias
> > > > which
> > > > should result in the module loaded at boot time when the
> > > > imx-ipuv3-crtc
> > > > devices are created.
> > > >
> > > > Could the problem be that imx-ipu-v3 isn't being loaded? However,
> > > > again,
> > > > it looks to me like everything is correct there.
> > > >
> > > > Are you saying that this used to work in older kernel versions like
> > > > 4.3,
> > > > but stopped in 4.4?
> > >
> > > yers it used to work and stopped working. I would need to go back and
> > > test
> > > old kernels to figure out where it broke.
> >
> > after installing some old kernels it broke with 4.4-rc4 which included a
> > patch with teh subject of "drm/imx: Remove of_node assignment from
> > ipuv3-crtc driver probe"
>
> Just to be sure: 4.4-rc4 with 407c9eba7897 ("drm/imx: Remove of_node
> assignment from ipuv3-crtc driver probe") reverted works fine for you?
>
> Best regards
> Uwe
I reverted the 4 patches in that series
407c9eba drm/imx: Remove of_node assignment from ipuv3-crtc driver probe
304e6be6 gpu: ipu-v3: Assign of_node of child platform devices to
corresponding ports
99ae78c3 gpu: ipu-v3: Remove reg_offset field
c3ede03c gpu: ipu-v3: drop unused dmfc field from client platform data
and it then worked again.
Dennis
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: This is a digitally signed message part.
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160422/c24659a7/attachment.sig>
[PATCH v12 1/2] kernel.h: add u64_to_user_ptr()
2016-04-22 Daniel Vetter : > On Thu, Apr 21, 2016 at 12:38:49PM -0300, Gustavo Padovan wrote: > > From: Gustavo Padovan > > > > This function had copies in 3 different files. Unify them in kernel.h. > > > > Cc: Joe Perches > > Cc: Andrew Morton > > Cc: David Airlie > > Cc: Daniel Vetter > > Cc: Rob Clark > > Signed-off-by: Gustavo Padovan > > Ack for i915 parts for merging through any suitable tree. But since this > mostly touches drm I'd propose we pull this in through drm-misc. Joe? Patch 2 needs this change and it is meant to be applied against the staging tree. Gustavo
[PATCH] drm/rockchip: support prime fd import
On 4 March 2016 at 17:45, Emil Velikov wrote: > On 23 February 2016 at 23:56, Rob Clark wrote: >> On Tue, Feb 23, 2016 at 6:29 PM, Emil Velikov >> wrote: >>> Hi Zach, >>> >>> On 2 February 2016 at 23:37, Zach Reizner wrote: The prime fd to handle ioctl was not used with rockchip before. Support was added in order to support potential uses (e.g. zero-copy video decode, camera). >>> Similar patch came around a few months ago and got this reply [1]. If >>> the situation has changed (there is an open-source driver/user for >>> this) it should be clearly mentioned in the commit message, as opposed >>> to "in order to support potential uses". >> >> hmm, well it is not driver specific uabi, and we have let several >> other mali/img users do prime.. >> >> I'm not sure, maybe those platforms can do a basic v4l <-> display >> thing w/ prime. Although upstream tends to hurt a bit for camera >> support.. >> > Actually... one possible user is vgem. With the series from Tiago > "Direct userspace dma-buf mmap" hitting upstream, we can actually > reapply the problematic parts of vgem, and get this in as well. > > Hopefully echoing the slogan "upstream kernel needs users for > interfaces", did not come too much for people. > If it did, sorry but it's a rule which was set before I came along. > Gents, just realised that this hasn't landed yet. As mentioned above, my earlier 'rant' is no longer applicable so feel free to check with the Rockchip maintainer and get this upstream. Regards, Emil
[PATCH] drm: rcar-du: Fix compilation warning
Commit d63c25e4245a ("drm: rcar-du: Use generic
drm_connector_register_all() helper") left an unused local variable
behind. Remove it.
Fixes: d63c25e4245a ("drm: rcar-du: Use generic drm_connector_register_all()
helper")
Signed-off-by: Laurent Pinchart
---
drivers/gpu/drm/rcar-du/rcar_du_drv.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/gpu/drm/rcar-du/rcar_du_drv.c
b/drivers/gpu/drm/rcar-du/rcar_du_drv.c
index 0f251dc11082..fb9242d27883 100644
--- a/drivers/gpu/drm/rcar-du/rcar_du_drv.c
+++ b/drivers/gpu/drm/rcar-du/rcar_du_drv.c
@@ -297,7 +297,6 @@ static int rcar_du_probe(struct platform_device *pdev)
{
struct device_node *np = pdev->dev.of_node;
struct rcar_du_device *rcdu;
- struct drm_connector *connector;
struct drm_device *ddev;
struct resource *mem;
int ret;
--
Regards,
Laurent Pinchart
[PATCH] drm: sti: remove useless call to dev->struct_mutex
No need to protect debugfs functions with dev->struct_mutex
Signed-off-by: Benjamin Gaignard
---
drivers/gpu/drm/sti/sti_cursor.c | 7 ---
drivers/gpu/drm/sti/sti_drv.c| 6 --
drivers/gpu/drm/sti/sti_dvo.c| 7 ---
drivers/gpu/drm/sti/sti_gdp.c| 14 --
drivers/gpu/drm/sti/sti_hda.c| 7 ---
drivers/gpu/drm/sti/sti_hdmi.c | 7 ---
drivers/gpu/drm/sti/sti_hqvdp.c | 7 ---
drivers/gpu/drm/sti/sti_mixer.c | 7 ---
drivers/gpu/drm/sti/sti_tvout.c | 7 ---
drivers/gpu/drm/sti/sti_vid.c| 7 ---
10 files changed, 76 deletions(-)
diff --git a/drivers/gpu/drm/sti/sti_cursor.c b/drivers/gpu/drm/sti/sti_cursor.c
index 3abb400..e6ee4c5 100644
--- a/drivers/gpu/drm/sti/sti_cursor.c
+++ b/drivers/gpu/drm/sti/sti_cursor.c
@@ -103,12 +103,6 @@ static int cursor_dbg_show(struct seq_file *s, void *data)
{
struct drm_info_node *node = s->private;
struct sti_cursor *cursor = (struct sti_cursor *)node->info_ent->data;
- struct drm_device *dev = node->minor->dev;
- int ret;
-
- ret = mutex_lock_interruptible(&dev->struct_mutex);
- if (ret)
- return ret;
seq_printf(s, "%s: (vaddr = 0x%p)",
sti_plane_to_str(&cursor->plane), cursor->regs);
@@ -127,7 +121,6 @@ static int cursor_dbg_show(struct seq_file *s, void *data)
DBGFS_DUMP(CUR_AWE);
seq_puts(s, "\n");
- mutex_unlock(&dev->struct_mutex);
return 0;
}
diff --git a/drivers/gpu/drm/sti/sti_drv.c b/drivers/gpu/drm/sti/sti_drv.c
index 6bd6aba..a8eece2 100644
--- a/drivers/gpu/drm/sti/sti_drv.c
+++ b/drivers/gpu/drm/sti/sti_drv.c
@@ -72,11 +72,6 @@ static int sti_drm_fps_dbg_show(struct seq_file *s, void
*data)
struct drm_info_node *node = s->private;
struct drm_device *dev = node->minor->dev;
struct drm_plane *p;
- int ret;
-
- ret = mutex_lock_interruptible(&dev->struct_mutex);
- if (ret)
- return ret;
list_for_each_entry(p, &dev->mode_config.plane_list, head) {
struct sti_plane *plane = to_sti_plane(p);
@@ -86,7 +81,6 @@ static int sti_drm_fps_dbg_show(struct seq_file *s, void
*data)
plane->fps_info.fips_str);
}
- mutex_unlock(&dev->struct_mutex);
return 0;
}
diff --git a/drivers/gpu/drm/sti/sti_dvo.c b/drivers/gpu/drm/sti/sti_dvo.c
index 25f7663..d439128 100644
--- a/drivers/gpu/drm/sti/sti_dvo.c
+++ b/drivers/gpu/drm/sti/sti_dvo.c
@@ -177,12 +177,6 @@ static int dvo_dbg_show(struct seq_file *s, void *data)
{
struct drm_info_node *node = s->private;
struct sti_dvo *dvo = (struct sti_dvo *)node->info_ent->data;
- struct drm_device *dev = node->minor->dev;
- int ret;
-
- ret = mutex_lock_interruptible(&dev->struct_mutex);
- if (ret)
- return ret;
seq_printf(s, "DVO: (vaddr = 0x%p)", dvo->regs);
DBGFS_DUMP(DVO_AWG_DIGSYNC_CTRL);
@@ -193,7 +187,6 @@ static int dvo_dbg_show(struct seq_file *s, void *data)
dvo_dbg_awg_microcode(s, dvo->regs + DVO_DIGSYNC_INSTR_I);
seq_puts(s, "\n");
- mutex_unlock(&dev->struct_mutex);
return 0;
}
diff --git a/drivers/gpu/drm/sti/sti_gdp.c b/drivers/gpu/drm/sti/sti_gdp.c
index ff3d3e7..3d098f1 100644
--- a/drivers/gpu/drm/sti/sti_gdp.c
+++ b/drivers/gpu/drm/sti/sti_gdp.c
@@ -207,14 +207,8 @@ static int gdp_dbg_show(struct seq_file *s, void *data)
{
struct drm_info_node *node = s->private;
struct sti_gdp *gdp = (struct sti_gdp *)node->info_ent->data;
- struct drm_device *dev = node->minor->dev;
struct drm_plane *drm_plane = &gdp->plane.drm_plane;
struct drm_crtc *crtc = drm_plane->crtc;
- int ret;
-
- ret = mutex_lock_interruptible(&dev->struct_mutex);
- if (ret)
- return ret;
seq_printf(s, "%s: (vaddr = 0x%p)",
sti_plane_to_str(&gdp->plane), gdp->regs);
@@ -247,7 +241,6 @@ static int gdp_dbg_show(struct seq_file *s, void *data)
seq_printf(s, " Connected to DRM CRTC #%d (%s)\n",
crtc->base.id, sti_mixer_to_str(to_sti_mixer(crtc)));
- mutex_unlock(&dev->struct_mutex);
return 0;
}
@@ -278,13 +271,7 @@ static int gdp_node_dbg_show(struct seq_file *s, void *arg)
{
struct drm_info_node *node = s->private;
struct sti_gdp *gdp = (struct sti_gdp *)node->info_ent->data;
- struct drm_device *dev = node->minor->dev;
unsigned int b;
- int ret;
-
- ret = mutex_lock_interruptible(&dev->struct_mutex);
- if (ret)
- return ret;
for (b = 0; b < GDP_NODE_NB_BANK; b++) {
seq_printf(s, "\n%s[%d].top", sti_plane_to_str(&gdp->plane), b);
@@ -293,7 +280,6 @@ static int gdp_node_dbg_show(struct seq_file *s, void *arg)
gdp_node_dump_node(s, gdp->node_list[b].btm_field);
}
- m
[PATCH v12 1/2] kernel.h: add u64_to_user_ptr()
On Thu, Apr 21, 2016 at 11:38 AM, Gustavo Padovan
wrote:
> From: Gustavo Padovan
>
> This function had copies in 3 different files. Unify them in kernel.h.
>
> Cc: Joe Perches
> Cc: Andrew Morton
> Cc: David Airlie
> Cc: Daniel Vetter
> Cc: Rob Clark
> Signed-off-by: Gustavo Padovan
Acked-by: Rob Clark
>
> ---
> v2: add typecheck() (comment from Maarten Lankhorst)
>
> v3: make u64_to_user_ptr() a macro (comment from Joe Perches)
> ---
> drivers/gpu/drm/etnaviv/etnaviv_gem_submit.c | 11 +++
> drivers/gpu/drm/i915/i915_drv.h | 5 -
> drivers/gpu/drm/i915/i915_gem.c | 14 +++---
> drivers/gpu/drm/i915/i915_gem_execbuffer.c | 14 +++---
> drivers/gpu/drm/msm/msm_gem_submit.c | 11 +++
> include/linux/kernel.h | 7 +++
> 6 files changed, 27 insertions(+), 35 deletions(-)
>
> diff --git a/drivers/gpu/drm/etnaviv/etnaviv_gem_submit.c
> b/drivers/gpu/drm/etnaviv/etnaviv_gem_submit.c
> index 236ada9..afdd55d 100644
> --- a/drivers/gpu/drm/etnaviv/etnaviv_gem_submit.c
> +++ b/drivers/gpu/drm/etnaviv/etnaviv_gem_submit.c
> @@ -28,11 +28,6 @@
> #define BO_LOCKED 0x4000
> #define BO_PINNED 0x2000
>
> -static inline void __user *to_user_ptr(u64 address)
> -{
> - return (void __user *)(uintptr_t)address;
> -}
> -
> static struct etnaviv_gem_submit *submit_create(struct drm_device *dev,
> struct etnaviv_gpu *gpu, size_t nr)
> {
> @@ -347,21 +342,21 @@ int etnaviv_ioctl_gem_submit(struct drm_device *dev,
> void *data,
> cmdbuf->exec_state = args->exec_state;
> cmdbuf->ctx = file->driver_priv;
>
> - ret = copy_from_user(bos, to_user_ptr(args->bos),
> + ret = copy_from_user(bos, u64_to_user_ptr(args->bos),
> args->nr_bos * sizeof(*bos));
> if (ret) {
> ret = -EFAULT;
> goto err_submit_cmds;
> }
>
> - ret = copy_from_user(relocs, to_user_ptr(args->relocs),
> + ret = copy_from_user(relocs, u64_to_user_ptr(args->relocs),
> args->nr_relocs * sizeof(*relocs));
> if (ret) {
> ret = -EFAULT;
> goto err_submit_cmds;
> }
>
> - ret = copy_from_user(stream, to_user_ptr(args->stream),
> + ret = copy_from_user(stream, u64_to_user_ptr(args->stream),
> args->stream_size);
> if (ret) {
> ret = -EFAULT;
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index 1048093..bb624cc 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -3576,11 +3576,6 @@ static inline i915_reg_t i915_vgacntrl_reg(struct
> drm_device *dev)
> return VGACNTRL;
> }
>
> -static inline void __user *to_user_ptr(u64 address)
> -{
> - return (void __user *)(uintptr_t)address;
> -}
> -
> static inline unsigned long msecs_to_jiffies_timeout(const unsigned int m)
> {
> unsigned long j = msecs_to_jiffies(m);
> diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
> index dabc089..2889716 100644
> --- a/drivers/gpu/drm/i915/i915_gem.c
> +++ b/drivers/gpu/drm/i915/i915_gem.c
> @@ -324,7 +324,7 @@ i915_gem_phys_pwrite(struct drm_i915_gem_object *obj,
> {
> struct drm_device *dev = obj->base.dev;
> void *vaddr = obj->phys_handle->vaddr + args->offset;
> - char __user *user_data = to_user_ptr(args->data_ptr);
> + char __user *user_data = u64_to_user_ptr(args->data_ptr);
> int ret = 0;
>
> /* We manually control the domain here and pretend that it
> @@ -605,7 +605,7 @@ i915_gem_shmem_pread(struct drm_device *dev,
> int needs_clflush = 0;
> struct sg_page_iter sg_iter;
>
> - user_data = to_user_ptr(args->data_ptr);
> + user_data = u64_to_user_ptr(args->data_ptr);
> remain = args->size;
>
> obj_do_bit17_swizzling = i915_gem_object_needs_bit17_swizzle(obj);
> @@ -692,7 +692,7 @@ i915_gem_pread_ioctl(struct drm_device *dev, void *data,
> return 0;
>
> if (!access_ok(VERIFY_WRITE,
> - to_user_ptr(args->data_ptr),
> + u64_to_user_ptr(args->data_ptr),
>args->size))
> return -EFAULT;
>
> @@ -783,7 +783,7 @@ i915_gem_gtt_pwrite_fast(struct drm_device *dev,
> if (ret)
> goto out_unpin;
>
> - user_data = to_user_ptr(args->data_ptr);
> + user_data = u64_to_user_ptr(args->data_ptr);
> remain = args->size;
>
> offset = i915_gem_obj_ggtt_offset(obj) + args->offset;
> @@ -907,7 +907,7 @@ i915_gem_shmem_pwrite(struct drm_device *dev,
> int needs_clflush_before = 0;
> struct sg_page_iter sg_iter;
>
> - user_data = to_user_ptr(args->data_ptr);
> + user_data = u64_to_user_ptr(args->data_ptr);
> remain
[Intel-gfx] [PATCH] drm: i915: Improve behavior in case of broken HDMI EDID
On 22 Apr 10:15 AM, Daniel Vetter wrote:
> On Thu, Apr 21, 2016 at 03:13:51PM -0300, Ezequiel Garcia wrote:
> > Daniel,
> >
> > Thanks a lot for the quick reply!
> >
> > On 20 Apr 01:34 PM, Daniel Vetter wrote:
> > > On Tue, Apr 19, 2016 at 02:31:13PM -0300, Ezequiel Garcia wrote:
> > > > Currently, our implementation of drm_connector_funcs.detect is
> > > > based on getting a valid EDID.
> > > >
> > > > This requirement makes the driver fail to detect connected
> > > > connectors in case of EDID corruption, which in turn prevents
> > > > from falling back to modes provided by builtin or user-provided
> > > > EDIDs.
> > >
> > > Imo, this should be fixed in the probe helpers. Something like the below
> > > might make sense:
> > >
> > >
> > > diff --git a/drivers/gpu/drm/drm_probe_helper.c
> > > b/drivers/gpu/drm/drm_probe_helper.c
> > > index e714b5a7955f..d3b9dc7535da 100644
> > > --- a/drivers/gpu/drm/drm_probe_helper.c
> > > +++ b/drivers/gpu/drm/drm_probe_helper.c
> > > @@ -214,7 +214,10 @@ int drm_helper_probe_single_connector_modes(struct
> > > drm_connector *connector,
> > > else
> > > connector->status = connector_status_disconnected;
> > > if (connector->funcs->force)
> > > - connector->funcs->force(connector);
> > > + connector->funcs->force(connector);
> > > + } else if (connector->override_edid){
> > > + connector->status = connector_status_connected;
> > > + connector->funcs->force(connector);
> > > } else {
> > > connector->status = connector->funcs->detect(connector, true);
> > > }
> > >
> > >
> > > It should do what you want it to do, still allow us to override force
> > > state manually and also fix things up for every, not just i915-hdmi. Also,
> > > much smaller patch.
> > >
> >
> > The patch you are proposing doesn't seem to be related
> > to the issue I want to fix, so maybe my explanation is still
> > unclear. After re-reading my commit log, I came to realize
> > I'm still not explaining the issue properly.
> >
> > Let me try again :-)
> >
> > A user can connect any kind of HDMI monitor to the box, and
> > the kernel should be able to output some video, even when the
> > HDMI monitor is a piece of crap and sends completely broken EDID.
> >
> > Currently, the i915 driver uses the return value of intel_hdmi_set_edid()
> > to set the connector status. IOW, the connector status is set to "connected"
> > *only* if the EDID is correct, and is left as "disconnected" if the EDID
> > is corrupt.
> >
> > However, the connector status can be detected by just probing
> > the I2C bus (drm_probe_ddc).
> >
> > The DRM probe helper relies on the .detect callback to decide if
> > the modes' fallbacks, EDID provided modes, etc are going to be set.
> >
> > It only set those modes if the .detect callback handler returns
> > a "connected" status and does nothing if .detect returns
> > "disconnected".
> >
> > If the connector is reported as "disconnected" it will skip it and
> > the user won't be able to use it (except if the state is forced
> > with a parameter).
> >
> > I am currently shipping intel boxes without monitors, and the
> > user can connect its own monitor. I can't know before hand
> > what device is going to be plugged (neither on which output
> > connector, HDMI, DVI, etc)... so I am not able to force any state.
> >
> > The patch I am proposing makes the kernel work without any
> > user intervention, in the face of corrupted EDID coming out of
> > a monitor. This works because the .detect logic after my patch
> > just checks if a I2C device is present in the bus to mark the
> > connector as "connected" and does not use the EDID parsing for that.
> >
> > In fact, the EDID parsing is moved to .get_modes() since they're
> > not really used before. This at the very least, is consistent with
> > how other drivers work (I'm not inventing anything).
> >
> > Maybe the following commit log is better. How does it look now?
>
> But in that case the only thing you get is the 1024x756 fallback mode.
> You're users are happy with that?
Well, users are happy when things Just Work :-)
> I thought your use-case was that you
> need to overwrite the edid anyway, and that doing the edid override alone
> doesn't work. Hence my patch to make stuff work directly with just the
> edid override.
>
I don't think the edid override does what you think it does. If you take
a look at the sources, you'll find it's only a debugfs interface to
inject EDID. I'm sure it's probably useful for debugging and development,
but it won't help at all in this case.
So, your patch doesn't improve the situation I have described in any way.
The patch you proposed only does one thing: if you inject some EDID using
debugfs edid_override file, and *then* you probe the driver, it will force
the state to connected, and use that EDID.
However, I'm trying to fix a completely different issue: the i915 driver
is unable to detect
[PATCH] drm/radeon: fix vertical bars appear on monitor (v2)
From: Vitaly Prosyak
When crtc/timing is disabled on boot the dig block
should be stopped in order ignore timing from crtc,
reset the steering fifo otherwise we get display
corruption or hung in dp sst mode.
v2: agd: fix coding style
Signed-off-by: Vitaly Prosyak
Signed-off-by: Alex Deucher
Cc: stable at vger.kernel.org
Signed-off-by: Alex Deucher
---
drivers/gpu/drm/radeon/evergreen.c | 154 -
drivers/gpu/drm/radeon/evergreen_reg.h | 46 ++
2 files changed, 199 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/radeon/evergreen.c
b/drivers/gpu/drm/radeon/evergreen.c
index 76c4bdf..34f7a29 100644
--- a/drivers/gpu/drm/radeon/evergreen.c
+++ b/drivers/gpu/drm/radeon/evergreen.c
@@ -2608,10 +2608,152 @@ static void evergreen_agp_enable(struct radeon_device
*rdev)
WREG32(VM_CONTEXT1_CNTL, 0);
}
+static const unsigned ni_dig_offsets[] =
+{
+ NI_DIG0_REGISTER_OFFSET,
+ NI_DIG1_REGISTER_OFFSET,
+ NI_DIG2_REGISTER_OFFSET,
+ NI_DIG3_REGISTER_OFFSET,
+ NI_DIG4_REGISTER_OFFSET,
+ NI_DIG5_REGISTER_OFFSET
+};
+
+static const unsigned ni_tx_offsets[] =
+{
+ NI_DCIO_UNIPHY0_UNIPHY_TX_CONTROL1,
+ NI_DCIO_UNIPHY1_UNIPHY_TX_CONTROL1,
+ NI_DCIO_UNIPHY2_UNIPHY_TX_CONTROL1,
+ NI_DCIO_UNIPHY3_UNIPHY_TX_CONTROL1,
+ NI_DCIO_UNIPHY4_UNIPHY_TX_CONTROL1,
+ NI_DCIO_UNIPHY5_UNIPHY_TX_CONTROL1
+};
+
+static const unsigned evergreen_dp_offsets[] =
+{
+ EVERGREEN_DP0_REGISTER_OFFSET,
+ EVERGREEN_DP1_REGISTER_OFFSET,
+ EVERGREEN_DP2_REGISTER_OFFSET,
+ EVERGREEN_DP3_REGISTER_OFFSET,
+ EVERGREEN_DP4_REGISTER_OFFSET,
+ EVERGREEN_DP5_REGISTER_OFFSET
+};
+
+
+/*
+ * Assumption is that EVERGREEN_CRTC_MASTER_EN enable for requested crtc
+ * We go from crtc to connector and it is not relible since it
+ * should be an opposite direction .If crtc is enable then
+ * find the dig_fe which selects this crtc and insure that it enable.
+ * if such dig_fe is found then find dig_be which selects found dig_be and
+ * insure that it enable and in DP_SST mode.
+ * if UNIPHY_PLL_CONTROL1.enable then we should disconnect timing
+ * from dp symbols clocks .
+ */
+static bool evergreen_is_dp_sst_stream_enabled(struct radeon_device *rdev,
+ unsigned crtc_id, unsigned
*ret_dig_fe)
+{
+ unsigned i;
+ unsigned dig_fe;
+ unsigned dig_be;
+ unsigned dig_en_be;
+ unsigned uniphy_pll;
+ unsigned digs_fe_selected;
+ unsigned dig_be_mode;
+ unsigned dig_fe_mask;
+ bool is_enabled = false;
+ bool found_crtc = false;
+
+ /* loop through all running dig_fe to find selected crtc */
+ for (i = 0; i < ARRAY_SIZE(ni_dig_offsets); i++) {
+ dig_fe = RREG32(NI_DIG_FE_CNTL + ni_dig_offsets[i]);
+ if (dig_fe & NI_DIG_FE_CNTL_SYMCLK_FE_ON &&
+ crtc_id == NI_DIG_FE_CNTL_SOURCE_SELECT(dig_fe)) {
+ /* found running pipe */
+ found_crtc = true;
+ dig_fe_mask = 1 << i;
+ dig_fe = i;
+ break;
+ }
+ }
+
+ if (found_crtc) {
+ /* loop through all running dig_be to find selected dig_fe */
+ for (i = 0; i < ARRAY_SIZE(ni_dig_offsets); i++) {
+ dig_be = RREG32(NI_DIG_BE_CNTL + ni_dig_offsets[i]);
+ /* if dig_fe_selected by dig_be? */
+ digs_fe_selected =
NI_DIG_BE_CNTL_FE_SOURCE_SELECT(dig_be);
+ dig_be_mode = NI_DIG_FE_CNTL_MODE(dig_be);
+ if (dig_fe_mask & digs_fe_selected &&
+ /* if dig_be in sst mode? */
+ dig_be_mode == NI_DIG_BE_DPSST) {
+ dig_en_be = RREG32(NI_DIG_BE_EN_CNTL +
+ ni_dig_offsets[i]);
+ uniphy_pll =
RREG32(NI_DCIO_UNIPHY0_PLL_CONTROL1 +
+ ni_tx_offsets[i]);
+ /* dig_be enable and tx is running */
+ if (dig_en_be & NI_DIG_BE_EN_CNTL_ENABLE &&
+ dig_en_be & NI_DIG_BE_EN_CNTL_SYMBCLK_ON &&
+ uniphy_pll &
NI_DCIO_UNIPHY0_PLL_CONTROL1_ENABLE) {
+ is_enabled = true;
+ *ret_dig_fe = dig_fe;
+ break;
+ }
+ }
+ }
+ }
+
+ return is_enabled;
+}
+
+/*
+ * Blank dig when in dp sst mode
+ * Dig ignores crtc timing
+ */
+static void evergreen_blank_dp_output(struct radeon_device *rdev,
+ unsigned dig_fe)
+{
+ unsign
[Bug 95072] [wine] Rendering bug in GTA IV
https://bugs.freedesktop.org/show_bug.cgi?id=95072 Bug ID: 95072 Summary: [wine] Rendering bug in GTA IV Product: Mesa Version: git Hardware: Other OS: All Status: NEW Severity: normal Priority: medium Component: Drivers/Gallium/radeonsi Assignee: dri-devel at lists.freedesktop.org Reporter: sa at whiz.se QA Contact: dri-devel at lists.freedesktop.org Created attachment 123156 --> https://bugs.freedesktop.org/attachment.cgi?id=123156&action=edit screenshot I'm getting a peculiar rendering bug in the game GTA IV (using Wine). The bug could best be described as "christmas lights" (screenshot attached). Apitrace (439 MB) https://www.dropbox.com/s/7xto4gmvwkk5ksm/gtaiv.trace?dl=0 The bug happens both with 11.1.2 and recent git 1883613 The trace renders fine with i965 and with software rendering but with a lot of warnings. Replaying the trace with radeonsi gives this warning: 16375: message: shader compiler issue 1: Shader Stats: SGPRS: 80 VGPRS: 12 Code Size: 72 LDS: 0 Scratch: 0 Max Waves: 10 System environment: -- system architecture: 64-bit -- Linux distribution: Debian unstable -- GPU: TONGA -- Model: Asus Strix R9 285 2GB -- Display connector: DVI -- xf86-video-amdgpu: 1.1.0 -- xserver: 1.18.3 -- mesa: -- drm: 2.4.67 -- kernel: 4.5.0 -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20160422/941252f6/attachment.html>
[PATCH v5 4/4] drm/i915: Get rid of intel_dp_dpcd_read_wake()
On Wed, Apr 13, 2016 at 10:58:33AM -0400, Lyude wrote:
> Since we've fixed up drm_dp_dpcd_read() to allow for retries when things
> timeout, there's no use for having this function anymore. Good riddens.
>
> Signed-off-by: Lyude
All applied to drm-misc, thanks.
-Daniel
> ---
> drivers/gpu/drm/i915/intel_dp.c | 81
> -
> 1 file changed, 23 insertions(+), 58 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
> index 6c6f95a2..363629c 100644
> --- a/drivers/gpu/drm/i915/intel_dp.c
> +++ b/drivers/gpu/drm/i915/intel_dp.c
> @@ -3074,47 +3074,14 @@ static void chv_dp_post_pll_disable(struct
> intel_encoder *encoder)
> }
>
> /*
> - * Native read with retry for link status and receiver capability reads for
> - * cases where the sink may still be asleep.
> - *
> - * Sinks are *supposed* to come up within 1ms from an off state, but we're
> also
> - * supposed to retry 3 times per the spec.
> - */
> -static ssize_t
> -intel_dp_dpcd_read_wake(struct drm_dp_aux *aux, unsigned int offset,
> - void *buffer, size_t size)
> -{
> - ssize_t ret;
> - int i;
> -
> - /*
> - * Sometime we just get the same incorrect byte repeated
> - * over the entire buffer. Doing just one throw away read
> - * initially seems to "solve" it.
> - */
> - drm_dp_dpcd_read(aux, DP_DPCD_REV, buffer, 1);
> -
> - for (i = 0; i < 3; i++) {
> - ret = drm_dp_dpcd_read(aux, offset, buffer, size);
> - if (ret == size)
> - return ret;
> - msleep(1);
> - }
> -
> - return ret;
> -}
> -
> -/*
> * Fetch AUX CH registers 0x202 - 0x207 which contain
> * link status information
> */
> bool
> intel_dp_get_link_status(struct intel_dp *intel_dp, uint8_t
> link_status[DP_LINK_STATUS_SIZE])
> {
> - return intel_dp_dpcd_read_wake(&intel_dp->aux,
> -DP_LANE0_1_STATUS,
> -link_status,
> -DP_LINK_STATUS_SIZE) ==
> DP_LINK_STATUS_SIZE;
> + return drm_dp_dpcd_read(&intel_dp->aux, DP_LANE0_1_STATUS, link_status,
> + DP_LINK_STATUS_SIZE) == DP_LINK_STATUS_SIZE;
> }
>
> /* These are source-specific values. */
> @@ -3749,8 +3716,8 @@ intel_dp_get_dpcd(struct intel_dp *intel_dp)
> struct drm_i915_private *dev_priv = dev->dev_private;
> uint8_t rev;
>
> - if (intel_dp_dpcd_read_wake(&intel_dp->aux, 0x000, intel_dp->dpcd,
> - sizeof(intel_dp->dpcd)) < 0)
> + if (drm_dp_dpcd_read(&intel_dp->aux, 0x000, intel_dp->dpcd,
> + sizeof(intel_dp->dpcd)) < 0)
> return false; /* aux transfer failed */
>
> DRM_DEBUG_KMS("DPCD: %*ph\n", (int) sizeof(intel_dp->dpcd),
> intel_dp->dpcd);
> @@ -3758,8 +3725,8 @@ intel_dp_get_dpcd(struct intel_dp *intel_dp)
> if (intel_dp->dpcd[DP_DPCD_REV] == 0)
> return false; /* DPCD not present */
>
> - if (intel_dp_dpcd_read_wake(&intel_dp->aux, DP_SINK_COUNT,
> - &intel_dp->sink_count, 1) < 0)
> + if (drm_dp_dpcd_read(&intel_dp->aux, DP_SINK_COUNT,
> + &intel_dp->sink_count, 1) < 0)
> return false;
>
> /*
> @@ -3782,9 +3749,9 @@ intel_dp_get_dpcd(struct intel_dp *intel_dp)
> /* Check if the panel supports PSR */
> memset(intel_dp->psr_dpcd, 0, sizeof(intel_dp->psr_dpcd));
> if (is_edp(intel_dp)) {
> - intel_dp_dpcd_read_wake(&intel_dp->aux, DP_PSR_SUPPORT,
> - intel_dp->psr_dpcd,
> - sizeof(intel_dp->psr_dpcd));
> + drm_dp_dpcd_read(&intel_dp->aux, DP_PSR_SUPPORT,
> + intel_dp->psr_dpcd,
> + sizeof(intel_dp->psr_dpcd));
> if (intel_dp->psr_dpcd[0] & DP_PSR_IS_SUPPORTED) {
> dev_priv->psr.sink_support = true;
> DRM_DEBUG_KMS("Detected EDP PSR Panel.\n");
> @@ -3795,9 +3762,9 @@ intel_dp_get_dpcd(struct intel_dp *intel_dp)
> uint8_t frame_sync_cap;
>
> dev_priv->psr.sink_support = true;
> - intel_dp_dpcd_read_wake(&intel_dp->aux,
> - DP_SINK_DEVICE_AUX_FRAME_SYNC_CAP,
> - &frame_sync_cap, 1);
> + drm_dp_dpcd_read(&intel_dp->aux,
> + DP_SINK_DEVICE_AUX_FRAME_SYNC_CAP,
> + &frame_sync_cap, 1);
> dev_priv->psr.aux_frame_sync = frame_sync_cap ? true :
> false;
> /* PSR2 needs frame sync as well */
> dev_priv->psr.psr2_support =
> dev_priv->psr.aux_frame_sync;
> @@ -
[PATCH] drm: rcar-du: Fix compilation warning
On Fri, Apr 22, 2016 at 05:54:39PM +0300, Laurent Pinchart wrote:
> Commit d63c25e4245a ("drm: rcar-du: Use generic
> drm_connector_register_all() helper") left an unused local variable
> behind. Remove it.
>
> Fixes: d63c25e4245a ("drm: rcar-du: Use generic drm_connector_register_all()
> helper")
> Signed-off-by: Laurent Pinchart
Oops, my apologies for not spotting this right away. Applied to drm-misc,
thanks.
-Daniel
> ---
> drivers/gpu/drm/rcar-du/rcar_du_drv.c | 1 -
> 1 file changed, 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/rcar-du/rcar_du_drv.c
> b/drivers/gpu/drm/rcar-du/rcar_du_drv.c
> index 0f251dc11082..fb9242d27883 100644
> --- a/drivers/gpu/drm/rcar-du/rcar_du_drv.c
> +++ b/drivers/gpu/drm/rcar-du/rcar_du_drv.c
> @@ -297,7 +297,6 @@ static int rcar_du_probe(struct platform_device *pdev)
> {
> struct device_node *np = pdev->dev.of_node;
> struct rcar_du_device *rcdu;
> - struct drm_connector *connector;
> struct drm_device *ddev;
> struct resource *mem;
> int ret;
> --
> Regards,
>
> Laurent Pinchart
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
[PATCH] drm: sti: remove useless call to dev->struct_mutex
On Fri, Apr 22, 2016 at 05:03:09PM +0200, Benjamin Gaignard wrote:
> No need to protect debugfs functions with dev->struct_mutex
>
> Signed-off-by: Benjamin Gaignard
Reviewed-by: Daniel Vetter
> ---
> drivers/gpu/drm/sti/sti_cursor.c | 7 ---
> drivers/gpu/drm/sti/sti_drv.c| 6 --
> drivers/gpu/drm/sti/sti_dvo.c| 7 ---
> drivers/gpu/drm/sti/sti_gdp.c| 14 --
> drivers/gpu/drm/sti/sti_hda.c| 7 ---
> drivers/gpu/drm/sti/sti_hdmi.c | 7 ---
> drivers/gpu/drm/sti/sti_hqvdp.c | 7 ---
> drivers/gpu/drm/sti/sti_mixer.c | 7 ---
> drivers/gpu/drm/sti/sti_tvout.c | 7 ---
> drivers/gpu/drm/sti/sti_vid.c| 7 ---
> 10 files changed, 76 deletions(-)
>
> diff --git a/drivers/gpu/drm/sti/sti_cursor.c
> b/drivers/gpu/drm/sti/sti_cursor.c
> index 3abb400..e6ee4c5 100644
> --- a/drivers/gpu/drm/sti/sti_cursor.c
> +++ b/drivers/gpu/drm/sti/sti_cursor.c
> @@ -103,12 +103,6 @@ static int cursor_dbg_show(struct seq_file *s, void
> *data)
> {
> struct drm_info_node *node = s->private;
> struct sti_cursor *cursor = (struct sti_cursor *)node->info_ent->data;
> - struct drm_device *dev = node->minor->dev;
> - int ret;
> -
> - ret = mutex_lock_interruptible(&dev->struct_mutex);
> - if (ret)
> - return ret;
>
> seq_printf(s, "%s: (vaddr = 0x%p)",
> sti_plane_to_str(&cursor->plane), cursor->regs);
> @@ -127,7 +121,6 @@ static int cursor_dbg_show(struct seq_file *s, void *data)
> DBGFS_DUMP(CUR_AWE);
> seq_puts(s, "\n");
>
> - mutex_unlock(&dev->struct_mutex);
> return 0;
> }
>
> diff --git a/drivers/gpu/drm/sti/sti_drv.c b/drivers/gpu/drm/sti/sti_drv.c
> index 6bd6aba..a8eece2 100644
> --- a/drivers/gpu/drm/sti/sti_drv.c
> +++ b/drivers/gpu/drm/sti/sti_drv.c
> @@ -72,11 +72,6 @@ static int sti_drm_fps_dbg_show(struct seq_file *s, void
> *data)
> struct drm_info_node *node = s->private;
> struct drm_device *dev = node->minor->dev;
> struct drm_plane *p;
> - int ret;
> -
> - ret = mutex_lock_interruptible(&dev->struct_mutex);
> - if (ret)
> - return ret;
>
> list_for_each_entry(p, &dev->mode_config.plane_list, head) {
> struct sti_plane *plane = to_sti_plane(p);
> @@ -86,7 +81,6 @@ static int sti_drm_fps_dbg_show(struct seq_file *s, void
> *data)
> plane->fps_info.fips_str);
> }
>
> - mutex_unlock(&dev->struct_mutex);
> return 0;
> }
>
> diff --git a/drivers/gpu/drm/sti/sti_dvo.c b/drivers/gpu/drm/sti/sti_dvo.c
> index 25f7663..d439128 100644
> --- a/drivers/gpu/drm/sti/sti_dvo.c
> +++ b/drivers/gpu/drm/sti/sti_dvo.c
> @@ -177,12 +177,6 @@ static int dvo_dbg_show(struct seq_file *s, void *data)
> {
> struct drm_info_node *node = s->private;
> struct sti_dvo *dvo = (struct sti_dvo *)node->info_ent->data;
> - struct drm_device *dev = node->minor->dev;
> - int ret;
> -
> - ret = mutex_lock_interruptible(&dev->struct_mutex);
> - if (ret)
> - return ret;
>
> seq_printf(s, "DVO: (vaddr = 0x%p)", dvo->regs);
> DBGFS_DUMP(DVO_AWG_DIGSYNC_CTRL);
> @@ -193,7 +187,6 @@ static int dvo_dbg_show(struct seq_file *s, void *data)
> dvo_dbg_awg_microcode(s, dvo->regs + DVO_DIGSYNC_INSTR_I);
> seq_puts(s, "\n");
>
> - mutex_unlock(&dev->struct_mutex);
> return 0;
> }
>
> diff --git a/drivers/gpu/drm/sti/sti_gdp.c b/drivers/gpu/drm/sti/sti_gdp.c
> index ff3d3e7..3d098f1 100644
> --- a/drivers/gpu/drm/sti/sti_gdp.c
> +++ b/drivers/gpu/drm/sti/sti_gdp.c
> @@ -207,14 +207,8 @@ static int gdp_dbg_show(struct seq_file *s, void *data)
> {
> struct drm_info_node *node = s->private;
> struct sti_gdp *gdp = (struct sti_gdp *)node->info_ent->data;
> - struct drm_device *dev = node->minor->dev;
> struct drm_plane *drm_plane = &gdp->plane.drm_plane;
> struct drm_crtc *crtc = drm_plane->crtc;
> - int ret;
> -
> - ret = mutex_lock_interruptible(&dev->struct_mutex);
> - if (ret)
> - return ret;
>
> seq_printf(s, "%s: (vaddr = 0x%p)",
> sti_plane_to_str(&gdp->plane), gdp->regs);
> @@ -247,7 +241,6 @@ static int gdp_dbg_show(struct seq_file *s, void *data)
> seq_printf(s, " Connected to DRM CRTC #%d (%s)\n",
> crtc->base.id, sti_mixer_to_str(to_sti_mixer(crtc)));
>
> - mutex_unlock(&dev->struct_mutex);
> return 0;
> }
>
> @@ -278,13 +271,7 @@ static int gdp_node_dbg_show(struct seq_file *s, void
> *arg)
> {
> struct drm_info_node *node = s->private;
> struct sti_gdp *gdp = (struct sti_gdp *)node->info_ent->data;
> - struct drm_device *dev = node->minor->dev;
> unsigned int b;
> - int ret;
> -
> - ret = mutex_lock_interruptible(&dev->struct_mutex);
> - if (ret)
> - return ret;
>
> for (b = 0; b < GDP_NODE_NB_BANK;
[Intel-gfx] [PATCH] drm: i915: Improve behavior in case of broken HDMI EDID
On Fri, Apr 22, 2016 at 12:18:07PM -0300, Ezequiel Garcia wrote:
> On 22 Apr 10:15 AM, Daniel Vetter wrote:
> > On Thu, Apr 21, 2016 at 03:13:51PM -0300, Ezequiel Garcia wrote:
> > > Daniel,
> > >
> > > Thanks a lot for the quick reply!
> > >
> > > On 20 Apr 01:34 PM, Daniel Vetter wrote:
> > > > On Tue, Apr 19, 2016 at 02:31:13PM -0300, Ezequiel Garcia wrote:
> > > > > Currently, our implementation of drm_connector_funcs.detect is
> > > > > based on getting a valid EDID.
> > > > >
> > > > > This requirement makes the driver fail to detect connected
> > > > > connectors in case of EDID corruption, which in turn prevents
> > > > > from falling back to modes provided by builtin or user-provided
> > > > > EDIDs.
> > > >
> > > > Imo, this should be fixed in the probe helpers. Something like the below
> > > > might make sense:
> > > >
> > > >
> > > > diff --git a/drivers/gpu/drm/drm_probe_helper.c
> > > > b/drivers/gpu/drm/drm_probe_helper.c
> > > > index e714b5a7955f..d3b9dc7535da 100644
> > > > --- a/drivers/gpu/drm/drm_probe_helper.c
> > > > +++ b/drivers/gpu/drm/drm_probe_helper.c
> > > > @@ -214,7 +214,10 @@ int drm_helper_probe_single_connector_modes(struct
> > > > drm_connector *connector,
> > > > else
> > > > connector->status =
> > > > connector_status_disconnected;
> > > > if (connector->funcs->force)
> > > > - connector->funcs->force(connector);
> > > > + connector->funcs->force(connector);
> > > > + } else if (connector->override_edid){
> > > > + connector->status = connector_status_connected;
> > > > + connector->funcs->force(connector);
> > > > } else {
> > > > connector->status = connector->funcs->detect(connector,
> > > > true);
> > > > }
> > > >
> > > >
> > > > It should do what you want it to do, still allow us to override force
> > > > state manually and also fix things up for every, not just i915-hdmi.
> > > > Also,
> > > > much smaller patch.
> > > >
> > >
> > > The patch you are proposing doesn't seem to be related
> > > to the issue I want to fix, so maybe my explanation is still
> > > unclear. After re-reading my commit log, I came to realize
> > > I'm still not explaining the issue properly.
> > >
> > > Let me try again :-)
> > >
> > > A user can connect any kind of HDMI monitor to the box, and
> > > the kernel should be able to output some video, even when the
> > > HDMI monitor is a piece of crap and sends completely broken EDID.
> > >
> > > Currently, the i915 driver uses the return value of intel_hdmi_set_edid()
> > > to set the connector status. IOW, the connector status is set to
> > > "connected"
> > > *only* if the EDID is correct, and is left as "disconnected" if the EDID
> > > is corrupt.
> > >
> > > However, the connector status can be detected by just probing
> > > the I2C bus (drm_probe_ddc).
> > >
> > > The DRM probe helper relies on the .detect callback to decide if
> > > the modes' fallbacks, EDID provided modes, etc are going to be set.
> > >
> > > It only set those modes if the .detect callback handler returns
> > > a "connected" status and does nothing if .detect returns
> > > "disconnected".
> > >
> > > If the connector is reported as "disconnected" it will skip it and
> > > the user won't be able to use it (except if the state is forced
> > > with a parameter).
> > >
> > > I am currently shipping intel boxes without monitors, and the
> > > user can connect its own monitor. I can't know before hand
> > > what device is going to be plugged (neither on which output
> > > connector, HDMI, DVI, etc)... so I am not able to force any state.
> > >
> > > The patch I am proposing makes the kernel work without any
> > > user intervention, in the face of corrupted EDID coming out of
> > > a monitor. This works because the .detect logic after my patch
> > > just checks if a I2C device is present in the bus to mark the
> > > connector as "connected" and does not use the EDID parsing for that.
> > >
> > > In fact, the EDID parsing is moved to .get_modes() since they're
> > > not really used before. This at the very least, is consistent with
> > > how other drivers work (I'm not inventing anything).
> > >
> > > Maybe the following commit log is better. How does it look now?
> >
> > But in that case the only thing you get is the 1024x756 fallback mode.
> > You're users are happy with that?
>
> Well, users are happy when things Just Work :-)
>
> > I thought your use-case was that you
> > need to overwrite the edid anyway, and that doing the edid override alone
> > doesn't work. Hence my patch to make stuff work directly with just the
> > edid override.
> >
>
> I don't think the edid override does what you think it does. If you take
> a look at the sources, you'll find it's only a debugfs interface to
> inject EDID. I'm sure it's probably useful for debugging and development,
> but it won't help at
[PATCH 4/8] drm/fb-helper: Add fb_deferred_io support
On Fri, Apr 22, 2016 at 04:17:14PM +0200, Noralf Trønnes wrote:
>
> Den 22.04.2016 10:27, skrev Daniel Vetter:
> >On Thu, Apr 21, 2016 at 08:54:45PM +0200, Noralf Trønnes wrote:
> >>Den 20.04.2016 17:25, skrev Noralf Trønnes:
> >>>This adds deferred io support if CONFIG_FB_DEFERRED_IO is enabled.
> >>>Accumulated fbdev framebuffer changes are signaled using the callback
> >>>(struct drm_framebuffer_funcs *)->dirty()
> >>>
> >>>The drm_fb_helper_sys_*() functions will accumulate changes and
> >>>schedule fb_info.deferred_work _if_ fb_info.fbdefio is set.
> >>>This worker is used by the deferred io mmap code to signal that it
> >>>has been collecting page faults. The page faults and/or other changes
> >>>are then merged into a drm_clip_rect and passed to the framebuffer
> >>>dirty() function.
> >>>
> >>>The driver is responsible for setting up the fb_info.fbdefio structure
> >>>and calling fb_deferred_io_init() using the provided callback:
> >>>(struct fb_deferred_io).deferred_io = drm_fb_helper_deferred_io;
> >>>
> >>>Signed-off-by: Noralf Trønnes
> >>>---
> >>> drivers/gpu/drm/drm_fb_helper.c | 119
> >>> +++-
> >>> include/drm/drm_fb_helper.h | 15 +
> >>> 2 files changed, 133 insertions(+), 1 deletion(-)
> >>>
> >>>diff --git a/drivers/gpu/drm/drm_fb_helper.c
> >>>b/drivers/gpu/drm/drm_fb_helper.c
> >>[...]
> >>
> >>>+#ifdef CONFIG_FB_DEFERRED_IO
> >>>+/**
> >>>+ * drm_fb_helper_deferred_io() - (struct fb_deferred_io *)->deferred_io
> >>>callback
> >>>+ * function
> >>>+ *
> >>>+ * This function always runs in process context (struct delayed_work) and
> >>>calls
> >>>+ * the (struct drm_framebuffer_funcs)->dirty function with the collected
> >>>+ * damage. There's no need to worry about the possibility that the
> >>>fb_sys_*()
> >>>+ * functions could be running in atomic context. They only schedule the
> >>>+ * delayed worker which then calls this deferred_io callback.
> >>>+ */
> >>>+void drm_fb_helper_deferred_io(struct fb_info *info,
> >>>+ struct list_head *pagelist)
> >>>+{
> >>>+ struct drm_fb_helper *helper = info->par;
> >>>+ unsigned long start, end, min, max;
> >>>+ struct drm_clip_rect clip;
> >>>+ unsigned long flags;
> >>>+ struct page *page;
> >>>+
> >>>+ if (!helper->fb->funcs->dirty)
> >>>+ return;
> >>>+
> >>>+ spin_lock_irqsave(&helper->dirty_lock, flags);
> >>>+ clip = helper->dirty_clip;
> >>>+ drm_clip_rect_reset(&helper->dirty_clip);
> >>>+ spin_unlock_irqrestore(&helper->dirty_lock, flags);
> >>>+
> >>>+ min = ULONG_MAX;
> >>>+ max = 0;
> >>>+ list_for_each_entry(page, pagelist, lru) {
> >>>+ start = page->index << PAGE_SHIFT;
> >>>+ end = start + PAGE_SIZE - 1;
> >>>+ min = min(min, start);
> >>>+ max = max(max, end);
> >>>+ }
> >>>+
> >>>+ if (min < max) {
> >>>+ struct drm_clip_rect mmap_clip;
> >>>+
> >>>+ mmap_clip.x1 = 0;
> >>>+ mmap_clip.x2 = info->var.xres;
> >>>+ mmap_clip.y1 = min / info->fix.line_length;
> >>>+ mmap_clip.y2 = min_t(u32, max / info->fix.line_length,
> >>>+ info->var.yres);
> >>>+ drm_clip_rect_merge(&clip, &mmap_clip, 1, 0, 0, 0);
> >>>+ }
> >>>+
> >>>+ if (!drm_clip_rect_is_empty(&clip))
> >>>+ helper->fb->funcs->dirty(helper->fb, NULL, 0, 0, &clip, 1);
> >>>+}
> >>>+EXPORT_SYMBOL(drm_fb_helper_deferred_io);
> >>There is one thing I have wondered about when it comes to deferred io and
> >>long run times for the defio worker with my displays:
> >>
> >>Userspace writes to some pages then the deferred io worker kicks off and
> >>runs for 100ms holding the page list mutex. While this is happening,
> >>userspace writes to a new page triggering a page_mkwrite. Now this
> >>function has to wait for the mutex to be released.
> >>
> >>Who is actually waiting here and is there a problem that this can last
> >>for 100ms?
> >No idea at all - I haven't looked that closely at fbdev defio. But one
> >reason we have an explicit ioctl in drm to flush out frontbuffer rendering
> >is exactly that flushing could take some time, and should only be done
> >once userspace has completed some rendering. Not right in the middle of an
> >op.
> >
> >I guess fix up your userspace to use dumb drm fb + drm dirtyfb ioctl?
> >Otherwise you'll get to improve fbdev defio, and fbdev is deprecated
> >subsystem and a real horror show. I highly recommend against touching it
> >;-)
>
> I have tried to track the call chain and it seems to be part of the
> page fault handler. Which means it's userspace wanting to write to the
> page that has to wait. And it has to wait at some random point in
> whatever rendering it's doing.
>
> Unless someone has any objections, I will make a change and add a worker
> like qxl does. This decouples the deferred_io worker holding the mutex
> from the framebuffer flushing job. However I intend to di
[git pull] drm fixes
On Thu, Apr 21, 2016 at 5:57 PM, Dave Airlie wrote: > > git://people.freedesktop.org/~airlied/linux drm-fixes Hmm. freedesktop.org seems to be feeling a bit under the weather. It's not just the git part - it's not doing web either, and doesn't seem to answer to pings either (I saw _one_ ping response, but that was over a minute or two, so..) Can you kick it? Do you have a mirror? Linus
[git pull] drm fixes
On Fri, Apr 22, 2016 at 7:16 PM, Linus Torvalds wrote: > On Thu, Apr 21, 2016 at 5:57 PM, Dave Airlie wrote: >> >> git://people.freedesktop.org/~airlied/linux drm-fixes > > Hmm. freedesktop.org seems to be feeling a bit under the weather. It's > not just the git part - it's not doing web either, and doesn't seem to > answer to pings either (I saw _one_ ping response, but that was over a > minute or two, so..) > > Can you kick it? Do you have a mirror? Works all fine here, http, ssh & git protocols all up&running well. Maybe temporary, or just your part of the interwebs fell off? -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch
[PATCH 4/8] drm/fb-helper: Add fb_deferred_io support
Den 22.04.2016 19:05, skrev Daniel Vetter:
> On Fri, Apr 22, 2016 at 04:17:14PM +0200, Noralf Trønnes wrote:
>> Den 22.04.2016 10:27, skrev Daniel Vetter:
>>> On Thu, Apr 21, 2016 at 08:54:45PM +0200, Noralf Trønnes wrote:
Den 20.04.2016 17:25, skrev Noralf Trønnes:
> This adds deferred io support if CONFIG_FB_DEFERRED_IO is enabled.
> Accumulated fbdev framebuffer changes are signaled using the callback
> (struct drm_framebuffer_funcs *)->dirty()
>
> The drm_fb_helper_sys_*() functions will accumulate changes and
> schedule fb_info.deferred_work _if_ fb_info.fbdefio is set.
> This worker is used by the deferred io mmap code to signal that it
> has been collecting page faults. The page faults and/or other changes
> are then merged into a drm_clip_rect and passed to the framebuffer
> dirty() function.
>
> The driver is responsible for setting up the fb_info.fbdefio structure
> and calling fb_deferred_io_init() using the provided callback:
> (struct fb_deferred_io).deferred_io = drm_fb_helper_deferred_io;
>
> Signed-off-by: Noralf Trønnes
> ---
> drivers/gpu/drm/drm_fb_helper.c | 119
> +++-
> include/drm/drm_fb_helper.h | 15 +
> 2 files changed, 133 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/drm_fb_helper.c
> b/drivers/gpu/drm/drm_fb_helper.c
[...]
> +#ifdef CONFIG_FB_DEFERRED_IO
> +/**
> + * drm_fb_helper_deferred_io() - (struct fb_deferred_io *)->deferred_io
> callback
> + * function
> + *
> + * This function always runs in process context (struct delayed_work)
> and calls
> + * the (struct drm_framebuffer_funcs)->dirty function with the collected
> + * damage. There's no need to worry about the possibility that the
> fb_sys_*()
> + * functions could be running in atomic context. They only schedule the
> + * delayed worker which then calls this deferred_io callback.
> + */
> +void drm_fb_helper_deferred_io(struct fb_info *info,
> +struct list_head *pagelist)
> +{
> + struct drm_fb_helper *helper = info->par;
> + unsigned long start, end, min, max;
> + struct drm_clip_rect clip;
> + unsigned long flags;
> + struct page *page;
> +
> + if (!helper->fb->funcs->dirty)
> + return;
> +
> + spin_lock_irqsave(&helper->dirty_lock, flags);
> + clip = helper->dirty_clip;
> + drm_clip_rect_reset(&helper->dirty_clip);
> + spin_unlock_irqrestore(&helper->dirty_lock, flags);
> +
> + min = ULONG_MAX;
> + max = 0;
> + list_for_each_entry(page, pagelist, lru) {
> + start = page->index << PAGE_SHIFT;
> + end = start + PAGE_SIZE - 1;
> + min = min(min, start);
> + max = max(max, end);
> + }
> +
> + if (min < max) {
> + struct drm_clip_rect mmap_clip;
> +
> + mmap_clip.x1 = 0;
> + mmap_clip.x2 = info->var.xres;
> + mmap_clip.y1 = min / info->fix.line_length;
> + mmap_clip.y2 = min_t(u32, max / info->fix.line_length,
> + info->var.yres);
> + drm_clip_rect_merge(&clip, &mmap_clip, 1, 0, 0, 0);
> + }
> +
> + if (!drm_clip_rect_is_empty(&clip))
> + helper->fb->funcs->dirty(helper->fb, NULL, 0, 0, &clip, 1);
> +}
> +EXPORT_SYMBOL(drm_fb_helper_deferred_io);
There is one thing I have wondered about when it comes to deferred io and
long run times for the defio worker with my displays:
Userspace writes to some pages then the deferred io worker kicks off and
runs for 100ms holding the page list mutex. While this is happening,
userspace writes to a new page triggering a page_mkwrite. Now this
function has to wait for the mutex to be released.
Who is actually waiting here and is there a problem that this can last
for 100ms?
>>> No idea at all - I haven't looked that closely at fbdev defio. But one
>>> reason we have an explicit ioctl in drm to flush out frontbuffer rendering
>>> is exactly that flushing could take some time, and should only be done
>>> once userspace has completed some rendering. Not right in the middle of an
>>> op.
>>>
>>> I guess fix up your userspace to use dumb drm fb + drm dirtyfb ioctl?
>>> Otherwise you'll get to improve fbdev defio, and fbdev is deprecated
>>> subsystem and a real horror show. I highly recommend against touching it
>>> ;-)
>> I have tried to track the call chain and it seems to be part of the
>> page fault handler. Which means it's userspace wanting to write to the
>> page that has to wait. And it has to wait at some random point in
>> whatever rendering it's doing.
>>
>> Unless someone has any objections, I will make a change and add a worker
>> like qxl does. This
[git pull] drm fixes
On Fri, Apr 22, 2016 at 10:23 AM, Daniel Vetter wrote: > > Works all fine here, http, ssh & git protocols all up&running well. > Maybe temporary, or just your part of the interwebs fell off? It's up for me now too, so something temporary. I don't think it was at my end, everything else seemed to work fine and be reachable.. Maybe it was going through a reboot and I was just unlucky with timing. Linus
[git pull] drm fixes
On Fri, Apr 22, 2016 at 7:30 PM, Linus Torvalds wrote: > On Fri, Apr 22, 2016 at 10:23 AM, Daniel Vetter wrote: >> >> Works all fine here, http, ssh & git protocols all up&running well. >> Maybe temporary, or just your part of the interwebs fell off? > > It's up for me now too, so something temporary. I don't think it was > at my end, everything else seemed to work fine and be reachable.. > > Maybe it was going through a reboot and I was just unlucky with timing. Just chatted with the Portland folks and at least they said half the internet fell off for a few minutes, not just fd.o (gmail among others). And it's back again since a few minutes. Anyway seems all back up again. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch
[PATCH 4/8] drm/fb-helper: Add fb_deferred_io support
On Fri, Apr 22, 2016 at 7:28 PM, Noralf Trønnes wrote: > This patch extend the use of the fbdev deferred_io worker to also handle > the fbdev drawing operations, which can happen in atomic context. > The qxl driver adds an extra worker (struct qxl_device).fb_work which is > used to flush the framebuffer. Both the mmap deferred_io (qxl_deferred_io()) > code which is run by the deferred io worker and the fbdev drawing operations > (qxl_fb_fillrect() etc.) schedule this fb_work worker. > > So this patch uses 1 worker, qxl uses 2 workers. Oh, I didn't realize that you're reusing the same worker for both things. 2 workers indeed make sense, since the mmap one must have a built-in delay (to coalesce a bunch of writes), whereas the other one probably should be run right away, after each op. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch
[Intel-gfx] [PATCH] drm: i915: Improve behavior in case of broken HDMI EDID
On 22 April 2016 at 14:02, Daniel Vetter wrote:
> On Fri, Apr 22, 2016 at 12:18:07PM -0300, Ezequiel Garcia wrote:
>> On 22 Apr 10:15 AM, Daniel Vetter wrote:
>> > On Thu, Apr 21, 2016 at 03:13:51PM -0300, Ezequiel Garcia wrote:
>> > > Daniel,
>> > >
>> > > Thanks a lot for the quick reply!
>> > >
>> > > On 20 Apr 01:34 PM, Daniel Vetter wrote:
>> > > > On Tue, Apr 19, 2016 at 02:31:13PM -0300, Ezequiel Garcia wrote:
>> > > > > Currently, our implementation of drm_connector_funcs.detect is
>> > > > > based on getting a valid EDID.
>> > > > >
>> > > > > This requirement makes the driver fail to detect connected
>> > > > > connectors in case of EDID corruption, which in turn prevents
>> > > > > from falling back to modes provided by builtin or user-provided
>> > > > > EDIDs.
>> > > >
>> > > > Imo, this should be fixed in the probe helpers. Something like the
>> > > > below
>> > > > might make sense:
>> > > >
>> > > >
>> > > > diff --git a/drivers/gpu/drm/drm_probe_helper.c
>> > > > b/drivers/gpu/drm/drm_probe_helper.c
>> > > > index e714b5a7955f..d3b9dc7535da 100644
>> > > > --- a/drivers/gpu/drm/drm_probe_helper.c
>> > > > +++ b/drivers/gpu/drm/drm_probe_helper.c
>> > > > @@ -214,7 +214,10 @@ int
>> > > > drm_helper_probe_single_connector_modes(struct drm_connector
>> > > > *connector,
>> > > > else
>> > > > connector->status =
>> > > > connector_status_disconnected;
>> > > > if (connector->funcs->force)
>> > > > - connector->funcs->force(connector);
>> > > > + connector->funcs->force(connector);
>> > > > + } else if (connector->override_edid){
>> > > > + connector->status = connector_status_connected;
>> > > > + connector->funcs->force(connector);
>> > > > } else {
>> > > > connector->status =
>> > > > connector->funcs->detect(connector, true);
>> > > > }
>> > > >
>> > > >
>> > > > It should do what you want it to do, still allow us to override force
>> > > > state manually and also fix things up for every, not just i915-hdmi.
>> > > > Also,
>> > > > much smaller patch.
>> > > >
>> > >
>> > > The patch you are proposing doesn't seem to be related
>> > > to the issue I want to fix, so maybe my explanation is still
>> > > unclear. After re-reading my commit log, I came to realize
>> > > I'm still not explaining the issue properly.
>> > >
>> > > Let me try again :-)
>> > >
>> > > A user can connect any kind of HDMI monitor to the box, and
>> > > the kernel should be able to output some video, even when the
>> > > HDMI monitor is a piece of crap and sends completely broken EDID.
>> > >
>> > > Currently, the i915 driver uses the return value of intel_hdmi_set_edid()
>> > > to set the connector status. IOW, the connector status is set to
>> > > "connected"
>> > > *only* if the EDID is correct, and is left as "disconnected" if the EDID
>> > > is corrupt.
>> > >
>> > > However, the connector status can be detected by just probing
>> > > the I2C bus (drm_probe_ddc).
>> > >
>> > > The DRM probe helper relies on the .detect callback to decide if
>> > > the modes' fallbacks, EDID provided modes, etc are going to be set.
>> > >
>> > > It only set those modes if the .detect callback handler returns
>> > > a "connected" status and does nothing if .detect returns
>> > > "disconnected".
>> > >
>> > > If the connector is reported as "disconnected" it will skip it and
>> > > the user won't be able to use it (except if the state is forced
>> > > with a parameter).
>> > >
>> > > I am currently shipping intel boxes without monitors, and the
>> > > user can connect its own monitor. I can't know before hand
>> > > what device is going to be plugged (neither on which output
>> > > connector, HDMI, DVI, etc)... so I am not able to force any state.
>> > >
>> > > The patch I am proposing makes the kernel work without any
>> > > user intervention, in the face of corrupted EDID coming out of
>> > > a monitor. This works because the .detect logic after my patch
>> > > just checks if a I2C device is present in the bus to mark the
>> > > connector as "connected" and does not use the EDID parsing for that.
>> > >
>> > > In fact, the EDID parsing is moved to .get_modes() since they're
>> > > not really used before. This at the very least, is consistent with
>> > > how other drivers work (I'm not inventing anything).
>> > >
>> > > Maybe the following commit log is better. How does it look now?
>> >
>> > But in that case the only thing you get is the 1024x756 fallback mode.
>> > You're users are happy with that?
>>
>> Well, users are happy when things Just Work :-)
>>
>> > I thought your use-case was that you
>> > need to overwrite the edid anyway, and that doing the edid override alone
>> > doesn't work. Hence my patch to make stuff work directly with just the
>> > edid override.
>> >
>>
>> I don't think the edid override does what you think it does. If you take
>> a look at th
[PATCH 24/24] drm/vmwgfx: add extern C guard for the UAPI header
Are these going to be ported over to corresponding files in libdrm?
Reviewed-by: Sinclair Yeh
On Thu, Apr 21, 2016 at 08:42:45PM +0100, Emil Velikov wrote:
> Cc: Sinclair Yeh
> Cc: Thomas Hellstrom
> Cc: Brian Paul
> Signed-off-by: Emil Velikov
> ---
> include/uapi/drm/vmwgfx_drm.h | 9 +
> 1 file changed, 9 insertions(+)
>
> diff --git a/include/uapi/drm/vmwgfx_drm.h b/include/uapi/drm/vmwgfx_drm.h
> index 5b68b4d..d325a41 100644
> --- a/include/uapi/drm/vmwgfx_drm.h
> +++ b/include/uapi/drm/vmwgfx_drm.h
> @@ -30,6 +30,10 @@
>
> #include "drm.h"
>
> +#if defined(__cplusplus)
> +extern "C" {
> +#endif
> +
> #define DRM_VMW_MAX_SURFACE_FACES 6
> #define DRM_VMW_MAX_MIP_LEVELS 24
>
> @@ -1087,4 +1091,9 @@ union drm_vmw_extended_context_arg {
> enum drm_vmw_extended_context req;
> struct drm_vmw_context_arg rep;
> };
> +
> +#if defined(__cplusplus)
> +}
> +#endif
> +
> #endif
> --
> 2.6.2
>
[PATCH] drm: atmel-hlcdc: fix atmel_hlcdc_crtc_reset() implementation
Reset crtc->state to NULL after freeing the state object and call
__drm_atomic_helper_crtc_destroy_state() helper instead of manually
calling drm_property_unreference_blob().
Signed-off-by: Boris Brezillon
---
drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c
b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c
index 8df0aaf..15c1679 100644
--- a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c
+++ b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c
@@ -391,12 +391,11 @@ void atmel_hlcdc_crtc_reset(struct drm_crtc *crtc)
{
struct atmel_hlcdc_crtc_state *state;
- if (crtc->state && crtc->state->mode_blob)
- drm_property_unreference_blob(crtc->state->mode_blob);
-
if (crtc->state) {
+ __drm_atomic_helper_crtc_destroy_state(crtc, crtc->state);
state = drm_crtc_state_to_atmel_hlcdc_crtc_state(crtc->state);
kfree(state);
+ crtc->state = NULL;
}
state = kzalloc(sizeof(*state), GFP_KERNEL);
--
2.7.4
[PATCH i-g-t 1/2] tests/kms_addfb_basic: Add invalid tests to set fb props
There's no properties on fb modeset objects, bug bugs in the
kernel when trying to use those ioctls in such an invalid way.
Cc: Dave Airlie
Signed-off-by: Daniel Vetter
---
tests/kms_addfb_basic.c | 66 +
1 file changed, 66 insertions(+)
diff --git a/tests/kms_addfb_basic.c b/tests/kms_addfb_basic.c
index 64047303dea7..de77b3cd907d 100644
--- a/tests/kms_addfb_basic.c
+++ b/tests/kms_addfb_basic.c
@@ -477,6 +477,70 @@ static void addfb25_ytile(int fd)
}
}
+static void prop_tests(int fd)
+{
+ struct drm_mode_fb_cmd2 f = {};
+ struct drm_mode_obj_get_properties get_props = {};
+ struct drm_mode_obj_set_property set_prop = {};
+ uint64_t prop, prop_val;
+
+ f.width = 1024;
+ f.height = 1024;
+ f.pixel_format = DRM_FORMAT_XRGB;
+ f.pitches[0] = 1024*4;
+
+ igt_fixture {
+ gem_bo = igt_create_bo_with_dimensions(fd, 1024, 1024,
+ DRM_FORMAT_XRGB, 0, 0, NULL, NULL, NULL);
+ igt_assert(gem_bo);
+
+ f.handles[0] = gem_bo;
+
+ igt_assert(drmIoctl(fd, DRM_IOCTL_MODE_ADDFB2, &f) == 0);
+ }
+
+ get_props.props_ptr = (uintptr_t) ∝
+ get_props.prop_values_ptr = (uintptr_t) &prop_val;
+ get_props.count_props = 1;
+ get_props.obj_id = f.fb_id;
+
+ igt_subtest("invalid-get-prop-any") {
+ get_props.obj_type = 0; /* DRM_MODE_OBJECT_ANY */
+
+ igt_assert(drmIoctl(fd, DRM_IOCTL_MODE_OBJ_GETPROPERTIES,
+ &get_props) == -1 && errno == EINVAL);
+ }
+
+ igt_subtest("invalid-get-prop") {
+ get_props.obj_type = DRM_MODE_OBJECT_FB;
+
+ igt_assert(drmIoctl(fd, DRM_IOCTL_MODE_OBJ_GETPROPERTIES,
+ &get_props) == -1 && errno == EINVAL);
+ }
+
+ set_prop.value = 0;
+ set_prop.prop_id = 1;
+ set_prop.obj_id = f.fb_id;
+
+ igt_subtest("invalid-set-prop-any") {
+ set_prop.obj_type = 0; /* DRM_MODE_OBJECT_ANY */
+
+ igt_assert(drmIoctl(fd, DRM_IOCTL_MODE_OBJ_SETPROPERTY,
+ &set_prop) == -1 && errno == EINVAL);
+ }
+
+ igt_subtest("invalid-set-prop") {
+ set_prop.obj_type = DRM_MODE_OBJECT_FB;
+
+ igt_assert(drmIoctl(fd, DRM_IOCTL_MODE_OBJ_SETPROPERTY,
+ &set_prop) == -1 && errno == EINVAL);
+ }
+
+ igt_fixture
+ igt_assert(drmIoctl(fd, DRM_IOCTL_MODE_RMFB, &f.fb_id) == 0);
+
+}
+
int fd;
igt_main
@@ -496,6 +560,8 @@ igt_main
tiling_tests(fd);
+ prop_tests(fd);
+
igt_fixture
close(fd);
}
--
2.5.0
