Re: [PATCH 16/21] drm/omap: Merge HPD enable operation with HPD callback registration
Hi,
On Wed, Jun 06, 2018 at 12:36:45PM +0300, Laurent Pinchart wrote:
> The omap_dss_device .enable_hpd() and .disable_hpd() are used to enable
> and disable hot-plug detection at omapdrm probe and remove time. This is
> required to avoid reporting hot-plug detection events before the DRM
> infrastructure is ready to accept them, as that could result in crashes
> or other malfunction.
>
> Hot-plug event reporting is conditioned by both HPD being enabled
> through the .enable_hpd() operation and by the HPD callback being
> registered though the .register_hpd_cb() operation. We thus don't need a
> separate enable operation if we can guarantee that callbacks won't be
> registered too early.
>
> HPD callbacks are registered at connector initialization time, which is
> too early to start reporting HPD events. There's however nothing
> blocking a move of callback registration to a later time when the
> omapdrm driver calls the HPD enable operations. Do so, and remove the
> HPD enable operation completely from omap_dss_device drivers.
>
> Signed-off-by: Laurent Pinchart
> ---
>
> [...]
>
> @@ -391,12 +387,8 @@ static void omap_modeset_disable_external_hpd(struct
> drm_device *ddev)
> struct omap_drm_private *priv = ddev->dev_private;
> int i;
>
> - for (i = 0; i < priv->num_pipes; i++) {
> - struct omap_dss_device *display = priv->pipes[i].display;
> -
> - if (display->ops->disable_hpd)
> - display->ops->disable_hpd(display);
> - }
> + for (i = 0; i < priv->num_pipes; i++)
> + omap_connector_enable_hpd(priv->pipes[i].connector);
> }
>
> /*
> --
omap_connector_disable_hpd... Otherwise:
Reviewed-by: Sebastian Reichel
-- Sebastian
signature.asc
Description: PGP signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 20/21] drm/omap: Pass both output and display omap_dss_device to encoder init
Hi,
On Wed, Jun 06, 2018 at 12:36:49PM +0300, Laurent Pinchart wrote:
> The drm_encoder implementation requires access to the omap_dss_device
> corresponding to the display, which is passed to its initialization
> function and stored internally. Clean up of the HDMI mode and infoframe
> handling will require access to the output omap_dss_device. To prepare
> for that, pass it to the encoder initialization function and store it
> internally as well.
>
> Signed-off-by: Laurent Pinchart
> ---
Reviewed-by: Sebastian Reichel
-- Sebastian
> drivers/gpu/drm/omapdrm/omap_drv.c | 2 +-
> drivers/gpu/drm/omapdrm/omap_encoder.c | 17 ++---
> drivers/gpu/drm/omapdrm/omap_encoder.h | 3 ++-
> 3 files changed, 13 insertions(+), 9 deletions(-)
>
> diff --git a/drivers/gpu/drm/omapdrm/omap_drv.c
> b/drivers/gpu/drm/omapdrm/omap_drv.c
> index bbcd467cd83f..49cd7609fa3b 100644
> --- a/drivers/gpu/drm/omapdrm/omap_drv.c
> +++ b/drivers/gpu/drm/omapdrm/omap_drv.c
> @@ -318,7 +318,7 @@ static int omap_modeset_init(struct drm_device *dev)
> struct drm_encoder *encoder;
> struct drm_crtc *crtc;
>
> - encoder = omap_encoder_init(dev, display);
> + encoder = omap_encoder_init(dev, pipe->output, display);
> if (!encoder)
> return -ENOMEM;
>
> diff --git a/drivers/gpu/drm/omapdrm/omap_encoder.c
> b/drivers/gpu/drm/omapdrm/omap_encoder.c
> index 87e2b3799a45..2689ae74ea60 100644
> --- a/drivers/gpu/drm/omapdrm/omap_encoder.c
> +++ b/drivers/gpu/drm/omapdrm/omap_encoder.c
> @@ -36,7 +36,8 @@
> */
> struct omap_encoder {
> struct drm_encoder base;
> - struct omap_dss_device *dssdev;
> + struct omap_dss_device *output;
> + struct omap_dss_device *display;
> };
>
> static void omap_encoder_destroy(struct drm_encoder *encoder)
> @@ -57,7 +58,7 @@ static void omap_encoder_mode_set(struct drm_encoder
> *encoder,
> {
> struct drm_device *dev = encoder->dev;
> struct omap_encoder *omap_encoder = to_omap_encoder(encoder);
> - struct omap_dss_device *dssdev = omap_encoder->dssdev;
> + struct omap_dss_device *dssdev = omap_encoder->display;
> struct drm_connector *connector;
> bool hdmi_mode;
> int r;
> @@ -86,7 +87,7 @@ static void omap_encoder_mode_set(struct drm_encoder
> *encoder,
> static void omap_encoder_disable(struct drm_encoder *encoder)
> {
> struct omap_encoder *omap_encoder = to_omap_encoder(encoder);
> - struct omap_dss_device *dssdev = omap_encoder->dssdev;
> + struct omap_dss_device *dssdev = omap_encoder->display;
>
> dssdev->ops->disable(dssdev);
> }
> @@ -97,7 +98,7 @@ static int omap_encoder_update(struct drm_encoder *encoder,
> {
> struct drm_device *dev = encoder->dev;
> struct omap_encoder *omap_encoder = to_omap_encoder(encoder);
> - struct omap_dss_device *dssdev = omap_encoder->dssdev;
> + struct omap_dss_device *dssdev = omap_encoder->display;
> int ret;
>
> if (dssdev->ops->check_timings) {
> @@ -127,7 +128,7 @@ static int omap_encoder_update(struct drm_encoder
> *encoder,
> static void omap_encoder_enable(struct drm_encoder *encoder)
> {
> struct omap_encoder *omap_encoder = to_omap_encoder(encoder);
> - struct omap_dss_device *dssdev = omap_encoder->dssdev;
> + struct omap_dss_device *dssdev = omap_encoder->display;
> int r;
>
> omap_encoder_update(encoder, omap_crtc_channel(encoder->crtc),
> @@ -156,7 +157,8 @@ static const struct drm_encoder_helper_funcs
> omap_encoder_helper_funcs = {
>
> /* initialize encoder */
> struct drm_encoder *omap_encoder_init(struct drm_device *dev,
> - struct omap_dss_device *dssdev)
> + struct omap_dss_device *output,
> + struct omap_dss_device *display)
> {
> struct drm_encoder *encoder = NULL;
> struct omap_encoder *omap_encoder;
> @@ -165,7 +167,8 @@ struct drm_encoder *omap_encoder_init(struct drm_device
> *dev,
> if (!omap_encoder)
> goto fail;
>
> - omap_encoder->dssdev = dssdev;
> + omap_encoder->output = output;
> + omap_encoder->display = display;
>
> encoder = _encoder->base;
>
> diff --git a/drivers/gpu/drm/omapdrm/omap_encoder.h
> b/drivers/gpu/drm/omapdrm/omap_encoder.h
> index e8f1a35dce2f..a7b5dde63ecb 100644
> --- a/drivers/gpu/drm/omapdrm/omap_encoder.h
> +++ b/drivers/gpu/drm/omapdrm/omap_encoder.h
> @@ -25,6 +25,7 @@ struct drm_encoder;
> struct omap_dss_device;
>
> struct drm_encoder *omap_encoder_init(struct drm_device *dev,
> - struct omap_dss_device *dssdev);
> + struct omap_dss_device *output,
> + struct omap_dss_device *display);
>
> #endif /* __OMAPDRM_ENCODER_H__ */
> --
> Regards,
>
> Laurent Pinchart
>
> ___
>
Re: [PATCH 18/21] drm/omap: Don't call EDID read operation recursively
Hi,
On Wed, Jun 06, 2018 at 12:36:47PM +0300, Laurent Pinchart wrote:
> Instead of calling the EDID read operation (.read_edid()) recursively
> from the display device back to the first device that provides EDID read
> support, iterate over the devices manually in the DRM connector code.
> This moves the complexity to a single central location and simplifies
> the logic in omap_dss_device drivers.
>
> Signed-off-by: Laurent Pinchart
> ---
Reviewed-by: Sebastian Reichel
-- Sebastian
> drivers/gpu/drm/omapdrm/displays/connector-dvi.c | 15 +--
> drivers/gpu/drm/omapdrm/displays/connector-hdmi.c | 11 ---
> .../gpu/drm/omapdrm/displays/encoder-tpd12s015.c | 13 ---
> drivers/gpu/drm/omapdrm/dss/hdmi4.c| 1 +
> drivers/gpu/drm/omapdrm/dss/hdmi5.c| 1 +
> drivers/gpu/drm/omapdrm/omap_connector.c | 101
> -
> 6 files changed, 65 insertions(+), 77 deletions(-)
>
> diff --git a/drivers/gpu/drm/omapdrm/displays/connector-dvi.c
> b/drivers/gpu/drm/omapdrm/displays/connector-dvi.c
> index 6be260ff6458..eae4108330f1 100644
> --- a/drivers/gpu/drm/omapdrm/displays/connector-dvi.c
> +++ b/drivers/gpu/drm/omapdrm/displays/connector-dvi.c
> @@ -166,12 +166,6 @@ static int dvic_read_edid(struct omap_dss_device *dssdev,
> struct panel_drv_data *ddata = to_panel_data(dssdev);
> int r, l, bytes_read;
>
> - if (ddata->hpd_gpio && !gpiod_get_value_cansleep(ddata->hpd_gpio))
> - return -ENODEV;
> -
> - if (!ddata->i2c_adapter)
> - return -ENODEV;
> -
> l = min(EDID_LENGTH, len);
> r = dvic_ddc_read(ddata->i2c_adapter, edid, l, 0);
> if (r)
> @@ -341,10 +335,11 @@ static int dvic_probe(struct platform_device *pdev)
> dssdev->of_ports = BIT(0);
>
> if (ddata->hpd_gpio)
> - dssdev->ops_flags = OMAP_DSS_DEVICE_OP_DETECT
> - | OMAP_DSS_DEVICE_OP_HPD;
> - else if (ddata->i2c_adapter)
> - dssdev->ops_flags = OMAP_DSS_DEVICE_OP_DETECT;
> + dssdev->ops_flags |= OMAP_DSS_DEVICE_OP_DETECT
> + | OMAP_DSS_DEVICE_OP_HPD;
> + if (ddata->i2c_adapter)
> + dssdev->ops_flags |= OMAP_DSS_DEVICE_OP_DETECT
> + | OMAP_DSS_DEVICE_OP_EDID;
>
> omapdss_display_init(dssdev);
> omapdss_device_register(dssdev);
> diff --git a/drivers/gpu/drm/omapdrm/displays/connector-hdmi.c
> b/drivers/gpu/drm/omapdrm/displays/connector-hdmi.c
> index 6f2364afb14a..16dc22edcb8e 100644
> --- a/drivers/gpu/drm/omapdrm/displays/connector-hdmi.c
> +++ b/drivers/gpu/drm/omapdrm/displays/connector-hdmi.c
> @@ -15,8 +15,6 @@
> #include
> #include
>
> -#include
> -
> #include "../dss/omapdss.h"
>
> static const struct videomode hdmic_default_vm = {
> @@ -126,14 +124,6 @@ static int hdmic_check_timings(struct omap_dss_device
> *dssdev,
> return src->ops->check_timings(src, vm);
> }
>
> -static int hdmic_read_edid(struct omap_dss_device *dssdev,
> - u8 *edid, int len)
> -{
> - struct omap_dss_device *src = dssdev->src;
> -
> - return src->ops->read_edid(src, edid, len);
> -}
> -
> static bool hdmic_detect(struct omap_dss_device *dssdev)
> {
> struct panel_drv_data *ddata = to_panel_data(dssdev);
> @@ -190,7 +180,6 @@ static const struct omap_dss_device_ops hdmic_ops = {
> .get_timings= hdmic_get_timings,
> .check_timings = hdmic_check_timings,
>
> - .read_edid = hdmic_read_edid,
> .detect = hdmic_detect,
> .register_hpd_cb= hdmic_register_hpd_cb,
> .unregister_hpd_cb = hdmic_unregister_hpd_cb,
> diff --git a/drivers/gpu/drm/omapdrm/displays/encoder-tpd12s015.c
> b/drivers/gpu/drm/omapdrm/displays/encoder-tpd12s015.c
> index 2772af84531a..dbbf9683bd51 100644
> --- a/drivers/gpu/drm/omapdrm/displays/encoder-tpd12s015.c
> +++ b/drivers/gpu/drm/omapdrm/displays/encoder-tpd12s015.c
> @@ -115,18 +115,6 @@ static int tpd_check_timings(struct omap_dss_device
> *dssdev,
> return src->ops->check_timings(src, vm);
> }
>
> -static int tpd_read_edid(struct omap_dss_device *dssdev,
> - u8 *edid, int len)
> -{
> - struct panel_drv_data *ddata = to_panel_data(dssdev);
> - struct omap_dss_device *src = dssdev->src;
> -
> - if (!gpiod_get_value_cansleep(ddata->hpd_gpio))
> - return -ENODEV;
> -
> - return src->ops->read_edid(src, edid, len);
> -}
> -
> static bool tpd_detect(struct omap_dss_device *dssdev)
> {
> struct panel_drv_data *ddata = to_panel_data(dssdev);
> @@ -180,7 +168,6 @@ static const struct omap_dss_device_ops tpd_ops = {
> .disable= tpd_disable,
> .check_timings = tpd_check_timings,
> .set_timings= tpd_set_timings,
> - .read_edid = tpd_read_edid,
> .detect =
Re: [PATCH 19/21] drm/omap: Get from CRTC to display device directly
Hi,
On Wed, Jun 06, 2018 at 12:36:48PM +0300, Laurent Pinchart wrote:
> The CRTC mode set implementation needs to access the omap_dss_device for
> the pipeline display. To do so, it iterates over all pipelines to find
> the one that contains an encoder corresponding to the CRTC, and request
> the display device from the encoder. That's a very complicated dance
> when the CRTC has a direct pipeline pointer already, and the pipeline
> contains a pointer to the display device.
>
> Replace the convoluted code with direct access.
>
> Signed-off-by: Laurent Pinchart
> ---
Reviewed-by: Sebastian Reichel
-- Sebastian
> drivers/gpu/drm/omapdrm/omap_crtc.c| 25 -
> drivers/gpu/drm/omapdrm/omap_encoder.c | 7 ---
> drivers/gpu/drm/omapdrm/omap_encoder.h | 3 ---
> 3 files changed, 4 insertions(+), 31 deletions(-)
>
> diff --git a/drivers/gpu/drm/omapdrm/omap_crtc.c
> b/drivers/gpu/drm/omapdrm/omap_crtc.c
> index 197d05312306..6e7a777907f5 100644
> --- a/drivers/gpu/drm/omapdrm/omap_crtc.c
> +++ b/drivers/gpu/drm/omapdrm/omap_crtc.c
> @@ -419,12 +419,12 @@ static enum drm_mode_status omap_crtc_mode_valid(struct
> drm_crtc *crtc,
> static void omap_crtc_mode_set_nofb(struct drm_crtc *crtc)
> {
> struct omap_crtc *omap_crtc = to_omap_crtc(crtc);
> + struct omap_dss_device *display = omap_crtc->pipe->display;
> struct drm_display_mode *mode = >state->adjusted_mode;
> - struct omap_drm_private *priv = crtc->dev->dev_private;
> const u32 flags_mask = DISPLAY_FLAGS_DE_HIGH | DISPLAY_FLAGS_DE_LOW |
> DISPLAY_FLAGS_PIXDATA_POSEDGE | DISPLAY_FLAGS_PIXDATA_NEGEDGE |
> DISPLAY_FLAGS_SYNC_POSEDGE | DISPLAY_FLAGS_SYNC_NEGEDGE;
> - unsigned int i;
> + struct videomode vm = {0};
>
> DBG("%s: set mode: %d:\"%s\" %d %d %d %d %d %d %d %d %d %d 0x%x 0x%x",
> omap_crtc->name, mode->base.id, mode->name,
> @@ -447,25 +447,8 @@ static void omap_crtc_mode_set_nofb(struct drm_crtc
> *crtc)
>* has been changed to the DRM model.
>*/
>
> - for (i = 0; i < priv->num_pipes; ++i) {
> - struct drm_encoder *encoder = priv->pipes[i].encoder;
> -
> - if (encoder->crtc == crtc) {
> - struct omap_dss_device *dssdev;
> -
> - dssdev = omap_encoder_get_dssdev(encoder);
> -
> - if (dssdev) {
> - struct videomode vm = {0};
> -
> - dssdev->ops->get_timings(dssdev, );
> -
> - omap_crtc->vm.flags |= vm.flags & flags_mask;
> - }
> -
> - break;
> - }
> - }
> + display->ops->get_timings(display, );
> + omap_crtc->vm.flags |= vm.flags & flags_mask;
> }
>
> static int omap_crtc_atomic_check(struct drm_crtc *crtc,
> diff --git a/drivers/gpu/drm/omapdrm/omap_encoder.c
> b/drivers/gpu/drm/omapdrm/omap_encoder.c
> index 7bbf3700e393..87e2b3799a45 100644
> --- a/drivers/gpu/drm/omapdrm/omap_encoder.c
> +++ b/drivers/gpu/drm/omapdrm/omap_encoder.c
> @@ -39,13 +39,6 @@ struct omap_encoder {
> struct omap_dss_device *dssdev;
> };
>
> -struct omap_dss_device *omap_encoder_get_dssdev(struct drm_encoder *encoder)
> -{
> - struct omap_encoder *omap_encoder = to_omap_encoder(encoder);
> -
> - return omap_encoder->dssdev;
> -}
> -
> static void omap_encoder_destroy(struct drm_encoder *encoder)
> {
> struct omap_encoder *omap_encoder = to_omap_encoder(encoder);
> diff --git a/drivers/gpu/drm/omapdrm/omap_encoder.h
> b/drivers/gpu/drm/omapdrm/omap_encoder.h
> index d2f308bec494..e8f1a35dce2f 100644
> --- a/drivers/gpu/drm/omapdrm/omap_encoder.h
> +++ b/drivers/gpu/drm/omapdrm/omap_encoder.h
> @@ -27,7 +27,4 @@ struct omap_dss_device;
> struct drm_encoder *omap_encoder_init(struct drm_device *dev,
> struct omap_dss_device *dssdev);
>
> -/* map crtc to vblank mask */
> -struct omap_dss_device *omap_encoder_get_dssdev(struct drm_encoder *encoder);
> -
> #endif /* __OMAPDRM_ENCODER_H__ */
> --
> Regards,
>
> Laurent Pinchart
>
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
signature.asc
Description: PGP signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
RE: [RFC v3 0/8] Add Plane Color Properties
>-Original Message- >From: dri-devel [mailto:dri-devel-boun...@lists.freedesktop.org] On Behalf Of >Alexandru-Cosmin Gheorghe >Sent: Monday, June 11, 2018 3:47 PM >To: Shankar, Uma >Cc: dcasta...@chromium.org; intel-...@lists.freedesktop.org; >emil.l.veli...@gmail.com; dri-devel@lists.freedesktop.org; Syrjala, Ville >; n...@arm.com; Lankhorst, Maarten > >Subject: Re: [RFC v3 0/8] Add Plane Color Properties > >Hi Uma, > >Any progress on userspace for this? >I was thinking on working on using this in drm_hwcomposer. > Hi Alex, Not much work has been done till now on user space side. You can go ahead and try to enable it in drm_hwcomposer. Regards, Uma Shankar >Thank you, >Alex Gheorghe > >On Fri, Mar 09, 2018 at 11:47:41PM +0530, Uma Shankar wrote: >> This patch series adds properties for plane color features. It adds >> properties for degamma used to linearize data, CSC used for gamut >> conversion, and gamma used to again non-linearize data as per panel >> supported color space. These can be utilize by user space to convert >> planes from one format to another, one color space to another etc. >> >> Usersapce can take smart blending decisions and utilize these hardware >> supported plane color features to get accurate color profile. The same >> can help in consistent color quality from source to panel taking >> advantage of advanced color features in hardware. >> >> These patches just add the property interfaces and enable helper >> functions. >> >> This series adds Intel Gen9 specific plane gamma feature. We can build >> up and add other platform/hardware specific implementation on top of >> this series >> >> Note: This is just to get a design feedback whether these interfaces >> look ok. Based on community feedback on interfaces, we will implement >> IGT tests to validate plane color features. This is un-tested currently. >> Also, userspace implementation to use these properties is currently >> not available. >> >> v2: Dropped legacy gamma table for plane as suggested by Maarten. >> Added Gen9/BDW plane gamma feature and rebase on tot. >> >> v3: Added a new drm_color_lut_ext structure to accommodate 32 bit >> precision entries, pointed to by Brian, Starkey for HDR usecases. >> Addressed Sean,Paul comments and moved plane color properties to >> drm_plane instead of mode_config. Added property documentation as >suggested by Daniel, Vetter. >> Fixed a rebase fumble which occurred in v2, pointed by Emil Velikov. >> >> Uma Shankar (8): >> drm: Add Enhanced Gamma LUT precision structure >> drm: Add Plane Degamma properties >> drm: Add Plane CTM property >> drm: Add Plane Gamma properties >> drm: Define helper function for plane color enabling >> drm/i915: Enable plane color features >> drm/i915: Implement Plane Gamma for Bdw and Gen9 platforms >> drm/i915: Load plane color luts from atomic flip >> >> Documentation/gpu/drm-kms.rst | 18 >> drivers/gpu/drm/drm_atomic.c | 30 +++ >> drivers/gpu/drm/drm_atomic_helper.c | 12 +++ >> drivers/gpu/drm/drm_plane.c | 131 >++ >> drivers/gpu/drm/i915/i915_drv.h | 5 ++ >> drivers/gpu/drm/i915/i915_pci.c | 5 +- >> drivers/gpu/drm/i915/i915_reg.h | 24 ++ >> drivers/gpu/drm/i915/intel_atomic_plane.c | 4 + >> drivers/gpu/drm/i915/intel_color.c| 80 ++ >> drivers/gpu/drm/i915/intel_device_info.h | 5 ++ >> drivers/gpu/drm/i915/intel_display.c | 4 + >> drivers/gpu/drm/i915/intel_drv.h | 10 +++ >> drivers/gpu/drm/i915/intel_sprite.c | 4 + >> include/drm/drm_color_mgmt.h | 5 ++ >> include/drm/drm_plane.h | 66 +++ >> include/uapi/drm/drm_mode.h | 15 >> 16 files changed, 417 insertions(+), 1 deletion(-) >> >> -- >> 1.9.1 >> >> ___ >> dri-devel mailing list >> dri-devel@lists.freedesktop.org >> https://lists.freedesktop.org/mailman/listinfo/dri-devel > >-- >Cheers, >Alex G >___ >dri-devel mailing list >dri-devel@lists.freedesktop.org >https://lists.freedesktop.org/mailman/listinfo/dri-devel ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PULL] drm-intel-next
On 12 June 2018 at 02:27, Rodrigo Vivi wrote: > Hi Dave, > > This is the first round targeting 4.19. > Does this tree feed into linux-next already? Since we shouldn't have new stuff for linux-next feeding into it until after rc1. I won't be pulling this until after rc1 anyways. Dave. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 15/21] drm/omap: Remove unneeded safety checks in the HPD operations
Hi,
On Wed, Jun 06, 2018 at 12:36:44PM +0300, Laurent Pinchart wrote:
> The HPD-related omap_dss_device operations are now only called when the
> device supports HPD. There's no need to duplicate that check in the
> omap_dss_device drivers. The .register_hpd_cb() operation can as a
> result be turned into a void operation.
>
> Signed-off-by: Laurent Pinchart
> ---
Reviewed-by: Sebastian Reichel
-- Sebastian
> drivers/gpu/drm/omapdrm/displays/connector-dvi.c | 9 +
> drivers/gpu/drm/omapdrm/displays/connector-hdmi.c| 14 +++---
> drivers/gpu/drm/omapdrm/displays/encoder-tpd12s015.c | 8 +++-
> drivers/gpu/drm/omapdrm/dss/omapdss.h| 6 +++---
> drivers/gpu/drm/omapdrm/omap_connector.c | 17 -
> 5 files changed, 14 insertions(+), 40 deletions(-)
>
> diff --git a/drivers/gpu/drm/omapdrm/displays/connector-dvi.c
> b/drivers/gpu/drm/omapdrm/displays/connector-dvi.c
> index e9353e4cd297..a53d5967e5a9 100644
> --- a/drivers/gpu/drm/omapdrm/displays/connector-dvi.c
> +++ b/drivers/gpu/drm/omapdrm/displays/connector-dvi.c
> @@ -211,30 +211,23 @@ static bool dvic_detect(struct omap_dss_device *dssdev)
> return r == 0;
> }
>
> -static int dvic_register_hpd_cb(struct omap_dss_device *dssdev,
> +static void dvic_register_hpd_cb(struct omap_dss_device *dssdev,
>void (*cb)(void *cb_data,
> enum drm_connector_status status),
>void *cb_data)
> {
> struct panel_drv_data *ddata = to_panel_data(dssdev);
>
> - if (!ddata->hpd_gpio)
> - return -ENOTSUPP;
> -
> mutex_lock(>hpd_lock);
> ddata->hpd_cb = cb;
> ddata->hpd_cb_data = cb_data;
> mutex_unlock(>hpd_lock);
> - return 0;
> }
>
> static void dvic_unregister_hpd_cb(struct omap_dss_device *dssdev)
> {
> struct panel_drv_data *ddata = to_panel_data(dssdev);
>
> - if (!ddata->hpd_gpio)
> - return;
> -
> mutex_lock(>hpd_lock);
> ddata->hpd_cb = NULL;
> ddata->hpd_cb_data = NULL;
> diff --git a/drivers/gpu/drm/omapdrm/displays/connector-hdmi.c
> b/drivers/gpu/drm/omapdrm/displays/connector-hdmi.c
> index 8eae973474dd..c58bf64d1a9b 100644
> --- a/drivers/gpu/drm/omapdrm/displays/connector-hdmi.c
> +++ b/drivers/gpu/drm/omapdrm/displays/connector-hdmi.c
> @@ -147,31 +147,23 @@ static bool hdmic_detect(struct omap_dss_device *dssdev)
> return connected;
> }
>
> -static int hdmic_register_hpd_cb(struct omap_dss_device *dssdev,
> - void (*cb)(void *cb_data,
> +static void hdmic_register_hpd_cb(struct omap_dss_device *dssdev,
> + void (*cb)(void *cb_data,
> enum drm_connector_status status),
> - void *cb_data)
> + void *cb_data)
> {
> struct panel_drv_data *ddata = to_panel_data(dssdev);
>
> - if (!ddata->hpd_gpio)
> - return -ENOTSUPP;
> -
> mutex_lock(>hpd_lock);
> ddata->hpd_cb = cb;
> ddata->hpd_cb_data = cb_data;
> mutex_unlock(>hpd_lock);
> -
> - return 0;
> }
>
> static void hdmic_unregister_hpd_cb(struct omap_dss_device *dssdev)
> {
> struct panel_drv_data *ddata = to_panel_data(dssdev);
>
> - if (!ddata->hpd_gpio)
> - return;
> -
> mutex_lock(>hpd_lock);
> ddata->hpd_cb = NULL;
> ddata->hpd_cb_data = NULL;
> diff --git a/drivers/gpu/drm/omapdrm/displays/encoder-tpd12s015.c
> b/drivers/gpu/drm/omapdrm/displays/encoder-tpd12s015.c
> index e5a25baa0364..7a6cac5b29e1 100644
> --- a/drivers/gpu/drm/omapdrm/displays/encoder-tpd12s015.c
> +++ b/drivers/gpu/drm/omapdrm/displays/encoder-tpd12s015.c
> @@ -140,10 +140,10 @@ static bool tpd_detect(struct omap_dss_device *dssdev)
> return connected;
> }
>
> -static int tpd_register_hpd_cb(struct omap_dss_device *dssdev,
> -void (*cb)(void *cb_data,
> +static void tpd_register_hpd_cb(struct omap_dss_device *dssdev,
> + void (*cb)(void *cb_data,
> enum drm_connector_status status),
> -void *cb_data)
> + void *cb_data)
> {
> struct panel_drv_data *ddata = to_panel_data(dssdev);
>
> @@ -151,8 +151,6 @@ static int tpd_register_hpd_cb(struct omap_dss_device
> *dssdev,
> ddata->hpd_cb = cb;
> ddata->hpd_cb_data = cb_data;
> mutex_unlock(>hpd_lock);
> -
> - return 0;
> }
>
> static void tpd_unregister_hpd_cb(struct omap_dss_device *dssdev)
> diff --git a/drivers/gpu/drm/omapdrm/dss/omapdss.h
> b/drivers/gpu/drm/omapdrm/dss/omapdss.h
> index e9a47d8c0edc..d7e06883f95c 100644
> --- a/drivers/gpu/drm/omapdrm/dss/omapdss.h
> +++ b/drivers/gpu/drm/omapdrm/dss/omapdss.h
> @@ -372,10 +372,10 @@
Re: [PATCH 14/21] drm/omap: Don't call HPD registration operations recursively
Hi,
On Wed, Jun 06, 2018 at 12:36:43PM +0300, Laurent Pinchart wrote:
> Instead of calling the hot-plug detection callback registration
> operations (.register_hpd_cb() and .unregister_hpd_cb()) recursively
> from the display device back to the first device that provides hot plug
> detection support, iterate over the devices manually in the DRM
> connector code. This moves the complexity to a single central location
> and simplifies the logic in omap_dss_device drivers.
>
> Signed-off-by: Laurent Pinchart
> ---
Reviewed-by: Sebastian Reichel
-- Sebastian
> drivers/gpu/drm/omapdrm/displays/connector-dvi.c | 8 ++-
> drivers/gpu/drm/omapdrm/displays/connector-hdmi.c | 67 --
> .../gpu/drm/omapdrm/displays/encoder-tpd12s015.c | 3 +-
> drivers/gpu/drm/omapdrm/omap_connector.c | 79
> ++
> 4 files changed, 88 insertions(+), 69 deletions(-)
>
> diff --git a/drivers/gpu/drm/omapdrm/displays/connector-dvi.c
> b/drivers/gpu/drm/omapdrm/displays/connector-dvi.c
> index f1674b3eee50..e9353e4cd297 100644
> --- a/drivers/gpu/drm/omapdrm/displays/connector-dvi.c
> +++ b/drivers/gpu/drm/omapdrm/displays/connector-dvi.c
> @@ -372,8 +372,12 @@ static int dvic_probe(struct platform_device *pdev)
> dssdev->type = OMAP_DISPLAY_TYPE_DVI;
> dssdev->owner = THIS_MODULE;
> dssdev->of_ports = BIT(0);
> - dssdev->ops_flags = ddata->hpd_gpio || ddata->i2c_adapter
> - ? OMAP_DSS_DEVICE_OP_DETECT : 0;
> +
> + if (ddata->hpd_gpio)
> + dssdev->ops_flags = OMAP_DSS_DEVICE_OP_DETECT
> + | OMAP_DSS_DEVICE_OP_HPD;
> + else if (ddata->i2c_adapter)
> + dssdev->ops_flags = OMAP_DSS_DEVICE_OP_DETECT;
>
> omapdss_display_init(dssdev);
> omapdss_device_register(dssdev);
> diff --git a/drivers/gpu/drm/omapdrm/displays/connector-hdmi.c
> b/drivers/gpu/drm/omapdrm/displays/connector-hdmi.c
> index 0d22d7004c98..8eae973474dd 100644
> --- a/drivers/gpu/drm/omapdrm/displays/connector-hdmi.c
> +++ b/drivers/gpu/drm/omapdrm/displays/connector-hdmi.c
> @@ -153,62 +153,53 @@ static int hdmic_register_hpd_cb(struct omap_dss_device
> *dssdev,
>void *cb_data)
> {
> struct panel_drv_data *ddata = to_panel_data(dssdev);
> - struct omap_dss_device *src = dssdev->src;
>
> - if (ddata->hpd_gpio) {
> - mutex_lock(>hpd_lock);
> - ddata->hpd_cb = cb;
> - ddata->hpd_cb_data = cb_data;
> - mutex_unlock(>hpd_lock);
> - return 0;
> - } else if (src->ops->register_hpd_cb) {
> - return src->ops->register_hpd_cb(src, cb, cb_data);
> - }
> + if (!ddata->hpd_gpio)
> + return -ENOTSUPP;
>
> - return -ENOTSUPP;
> + mutex_lock(>hpd_lock);
> + ddata->hpd_cb = cb;
> + ddata->hpd_cb_data = cb_data;
> + mutex_unlock(>hpd_lock);
> +
> + return 0;
> }
>
> static void hdmic_unregister_hpd_cb(struct omap_dss_device *dssdev)
> {
> struct panel_drv_data *ddata = to_panel_data(dssdev);
> - struct omap_dss_device *src = dssdev->src;
>
> - if (ddata->hpd_gpio) {
> - mutex_lock(>hpd_lock);
> - ddata->hpd_cb = NULL;
> - ddata->hpd_cb_data = NULL;
> - mutex_unlock(>hpd_lock);
> - } else if (src->ops->unregister_hpd_cb) {
> - src->ops->unregister_hpd_cb(src);
> - }
> + if (!ddata->hpd_gpio)
> + return;
> +
> + mutex_lock(>hpd_lock);
> + ddata->hpd_cb = NULL;
> + ddata->hpd_cb_data = NULL;
> + mutex_unlock(>hpd_lock);
> }
>
> static void hdmic_enable_hpd(struct omap_dss_device *dssdev)
> {
> struct panel_drv_data *ddata = to_panel_data(dssdev);
> - struct omap_dss_device *src = dssdev->src;
>
> - if (ddata->hpd_gpio) {
> - mutex_lock(>hpd_lock);
> - ddata->hpd_enabled = true;
> - mutex_unlock(>hpd_lock);
> - } else if (src->ops->enable_hpd) {
> - src->ops->enable_hpd(src);
> - }
> + if (!ddata->hpd_gpio)
> + return;
> +
> + mutex_lock(>hpd_lock);
> + ddata->hpd_enabled = true;
> + mutex_unlock(>hpd_lock);
> }
>
> static void hdmic_disable_hpd(struct omap_dss_device *dssdev)
> {
> struct panel_drv_data *ddata = to_panel_data(dssdev);
> - struct omap_dss_device *src = dssdev->src;
>
> - if (ddata->hpd_gpio) {
> - mutex_lock(>hpd_lock);
> - ddata->hpd_enabled = false;
> - mutex_unlock(>hpd_lock);
> - } else if (src->ops->disable_hpd) {
> - src->ops->disable_hpd(src);
> - }
> + if (!ddata->hpd_gpio)
> + return;
> +
> + mutex_lock(>hpd_lock);
> + ddata->hpd_enabled = false;
> + mutex_unlock(>hpd_lock);
> }
>
> static int hdmic_set_hdmi_mode(struct omap_dss_device *dssdev, bool
> hdmi_mode)
> @@ -314,7 +305,9 @@ static
[Bug 106446] Stutter at higher refresh rates ( 75 Hz) and artifacts on desktop
https://bugs.freedesktop.org/show_bug.cgi?id=106446 --- Comment #7 from Mike Bendel --- Adding amdgpu.dpm=1 did not fix it, unfortunately. Noticed no change on my WX7100. Thanks for the suggestion though. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 199959] amdgpu, regression?: system freezes after resume
https://bugzilla.kernel.org/show_bug.cgi?id=199959 --- Comment #15 from Alexander Mezin (mezin.alexan...@gmail.com) --- No, it doesn't change anything, system freezes on resume. -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 106892] GPU hang with radeon glx driver
https://bugs.freedesktop.org/show_bug.cgi?id=106892 --- Comment #1 from Simon --- Ok seems the radeon driver has problems with my monitor at 1440x900@75Hz, because if I reduce that to 1440x900@60Hz it seems to work stable, though my Intel iGPU never had problems with 75Hz.. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 17/21] drm/omap: Move HPD disconnection handling to omap_connector
Hi,
On Wed, Jun 06, 2018 at 12:36:46PM +0300, Laurent Pinchart wrote:
> On HDMI outputs, CEC support requires notification of HPD signal
> deassertion. The HPD signal can be handled by various omap_dss_device
> instances in the pipeline, and all of them forward HPD events to the
> OMAP4 internal HDMI encoder.
>
> Knowledge of the DSS internals need to be removed from the
> omap_dss_device instances in order to migrate to drm_bridge. To do so,
> move HPD handling for CEC to the omap_connector.
>
> Signed-off-by: Laurent Pinchart
> ---
Reviewed-by: Sebastian Reichel
-- Sebastian
> drivers/gpu/drm/omapdrm/displays/connector-hdmi.c | 7 +
> .../gpu/drm/omapdrm/displays/encoder-tpd12s015.c | 7 +
> drivers/gpu/drm/omapdrm/omap_connector.c | 33
> ++
> 3 files changed, 29 insertions(+), 18 deletions(-)
>
> diff --git a/drivers/gpu/drm/omapdrm/displays/connector-hdmi.c
> b/drivers/gpu/drm/omapdrm/displays/connector-hdmi.c
> index 84cc68388940..6f2364afb14a 100644
> --- a/drivers/gpu/drm/omapdrm/displays/connector-hdmi.c
> +++ b/drivers/gpu/drm/omapdrm/displays/connector-hdmi.c
> @@ -137,13 +137,8 @@ static int hdmic_read_edid(struct omap_dss_device
> *dssdev,
> static bool hdmic_detect(struct omap_dss_device *dssdev)
> {
> struct panel_drv_data *ddata = to_panel_data(dssdev);
> - struct omap_dss_device *src = dssdev->src;
> - bool connected;
>
> - connected = gpiod_get_value_cansleep(ddata->hpd_gpio);
> - if (!connected && src->ops->hdmi.lost_hotplug)
> - src->ops->hdmi.lost_hotplug(src);
> - return connected;
> + return gpiod_get_value_cansleep(ddata->hpd_gpio);
> }
>
> static void hdmic_register_hpd_cb(struct omap_dss_device *dssdev,
> diff --git a/drivers/gpu/drm/omapdrm/displays/encoder-tpd12s015.c
> b/drivers/gpu/drm/omapdrm/displays/encoder-tpd12s015.c
> index 1fa1d332dbc4..2772af84531a 100644
> --- a/drivers/gpu/drm/omapdrm/displays/encoder-tpd12s015.c
> +++ b/drivers/gpu/drm/omapdrm/displays/encoder-tpd12s015.c
> @@ -130,13 +130,8 @@ static int tpd_read_edid(struct omap_dss_device *dssdev,
> static bool tpd_detect(struct omap_dss_device *dssdev)
> {
> struct panel_drv_data *ddata = to_panel_data(dssdev);
> - struct omap_dss_device *src = dssdev->src;
> - bool connected;
>
> - connected = gpiod_get_value_cansleep(ddata->hpd_gpio);
> - if (!connected && src->ops->hdmi.lost_hotplug)
> - src->ops->hdmi.lost_hotplug(src);
> - return connected;
> + return gpiod_get_value_cansleep(ddata->hpd_gpio);
> }
>
> static void tpd_register_hpd_cb(struct omap_dss_device *dssdev,
> diff --git a/drivers/gpu/drm/omapdrm/omap_connector.c
> b/drivers/gpu/drm/omapdrm/omap_connector.c
> index 56985c191740..1b3f85a02c85 100644
> --- a/drivers/gpu/drm/omapdrm/omap_connector.c
> +++ b/drivers/gpu/drm/omapdrm/omap_connector.c
> @@ -34,6 +34,22 @@ struct omap_connector {
> bool hdmi_mode;
> };
>
> +static void omap_connector_hpd_notify(struct drm_connector *connector,
> + struct omap_dss_device *src,
> + enum drm_connector_status status)
> +{
> + if (status == connector_status_disconnected) {
> + /*
> + * If the source is an HDMI encoder, notify it of disconnection.
> + * This is required to let the HDMI encoder reset any internal
> + * state related to connection status, such as the CEC address.
> + */
> + if (src && src->type == OMAP_DISPLAY_TYPE_HDMI &&
> + src->ops->hdmi.lost_hotplug)
> + src->ops->hdmi.lost_hotplug(src);
> + }
> +}
> +
> static void omap_connector_hpd_cb(void *cb_data,
> enum drm_connector_status status)
> {
> @@ -47,8 +63,12 @@ static void omap_connector_hpd_cb(void *cb_data,
> connector->status = status;
> mutex_unlock(>mode_config.mutex);
>
> - if (old_status != status)
> - drm_kms_helper_hotplug_event(dev);
> + if (old_status == status)
> + return;
> +
> + omap_connector_hpd_notify(connector, omap_connector->hpd, status);
> +
> + drm_kms_helper_hotplug_event(dev);
> }
>
> void omap_connector_enable_hpd(struct drm_connector *connector)
> @@ -103,10 +123,11 @@ static enum drm_connector_status omap_connector_detect(
> OMAP_DSS_DEVICE_OP_DETECT);
>
> if (dssdev) {
> - if (dssdev->ops->detect(dssdev))
> - status = connector_status_connected;
> - else
> - status = connector_status_disconnected;
> + status = dssdev->ops->detect(dssdev)
> +? connector_status_connected
> +: connector_status_disconnected;
> +
> + omap_connector_hpd_notify(connector, dssdev->src, status);
> } else {
>
Re: [PATCH 04/21] drm/omap: Check omap_dss_device type based on the output_type field
Hi,
On Wed, Jun 06, 2018 at 12:36:33PM +0300, Laurent Pinchart wrote:
> Various functions that need to differentiate between omap_dss_device
> instances corresponding to displays and to internal encoders use the
> omap_dss_device.driver field, which is only set for display instances.
> This gets in the way of the omap_dss_device operations refactoring.
> Replace that with a check based on the output_type field which is set
> for all omap_dss_device instances but displays.
>
> Signed-off-by: Laurent Pinchart
> ---
Reviewed-by: Sebastian Reichel
-- Sebastian
> drivers/gpu/drm/omapdrm/dss/base.c| 4 ++--
> drivers/gpu/drm/omapdrm/dss/omapdss.h | 6 ++
> 2 files changed, 8 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/omapdrm/dss/base.c
> b/drivers/gpu/drm/omapdrm/dss/base.c
> index cce09a48d769..6a73d3559257 100644
> --- a/drivers/gpu/drm/omapdrm/dss/base.c
> +++ b/drivers/gpu/drm/omapdrm/dss/base.c
> @@ -165,7 +165,7 @@ struct omap_dss_device *omapdss_device_get_next(struct
> omap_dss_device *from,
>* Filter out non-display entries if display_only is set, and
>* non-output entries if output_only is set.
>*/
> - if (display_only && !dssdev->driver)
> + if (display_only && dssdev->output_type)
> continue;
> if (output_only && (!dssdev->id || !dssdev->next))
> continue;
> @@ -224,7 +224,7 @@ void omapdss_device_disconnect(struct omap_dss_device
> *src,
> dev_dbg(src->dev, "disconnect\n");
>
> if (!omapdss_device_is_connected(dst)) {
> - WARN_ON(!dst->driver);
> + WARN_ON(dst->output_type);
> return;
> }
>
> diff --git a/drivers/gpu/drm/omapdrm/dss/omapdss.h
> b/drivers/gpu/drm/omapdrm/dss/omapdss.h
> index 3bfb62b28a77..ae30802f2151 100644
> --- a/drivers/gpu/drm/omapdrm/dss/omapdss.h
> +++ b/drivers/gpu/drm/omapdrm/dss/omapdss.h
> @@ -401,6 +401,12 @@ struct omap_dss_device {
> unsigned int alias_id;
>
> enum omap_display_type type;
> + /*
> + * DSS output type that this device generates (for DSS internal devices)
> + * or requires (for external encoders). Must be OMAP_DISPLAY_TYPE_NONE
> + * for display devices (connectors and panels) and to non-zero value for
> + * all other devices.
> + */
> enum omap_display_type output_type;
>
> const char *name;
> --
> Regards,
>
> Laurent Pinchart
>
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
signature.asc
Description: PGP signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 21/21] drm/omap: Don't call HDMI mode and infoframe operations recursively
Hi,
On Wed, Jun 06, 2018 at 12:36:50PM +0300, Laurent Pinchart wrote:
> The HDMI mode (.set_hdmi_mode()) and infoframe (.set_infoframe())
> operations are called recursively from the display device back to the
> HDMI encoder. This isn't required, as all components other than the HDMI
> encoder just forward the operation to the previous component in the
> chain. Call the operations directly on the HDMI encoder.
>
> Signed-off-by: Laurent Pinchart
> ---
Reviewed-by: Sebastian Reichel
-- Sebastian
> drivers/gpu/drm/omapdrm/displays/connector-hdmi.c | 20
> .../gpu/drm/omapdrm/displays/encoder-tpd12s015.c| 21
> -
> drivers/gpu/drm/omapdrm/omap_encoder.c | 2 +-
> 3 files changed, 1 insertion(+), 42 deletions(-)
>
> diff --git a/drivers/gpu/drm/omapdrm/displays/connector-hdmi.c
> b/drivers/gpu/drm/omapdrm/displays/connector-hdmi.c
> index 16dc22edcb8e..fe6d2923ed81 100644
> --- a/drivers/gpu/drm/omapdrm/displays/connector-hdmi.c
> +++ b/drivers/gpu/drm/omapdrm/displays/connector-hdmi.c
> @@ -154,21 +154,6 @@ static void hdmic_unregister_hpd_cb(struct
> omap_dss_device *dssdev)
> mutex_unlock(>hpd_lock);
> }
>
> -static int hdmic_set_hdmi_mode(struct omap_dss_device *dssdev, bool
> hdmi_mode)
> -{
> - struct omap_dss_device *src = dssdev->src;
> -
> - return src->ops->hdmi.set_hdmi_mode(src, hdmi_mode);
> -}
> -
> -static int hdmic_set_infoframe(struct omap_dss_device *dssdev,
> - const struct hdmi_avi_infoframe *avi)
> -{
> - struct omap_dss_device *src = dssdev->src;
> -
> - return src->ops->hdmi.set_infoframe(src, avi);
> -}
> -
> static const struct omap_dss_device_ops hdmic_ops = {
> .connect= hdmic_connect,
> .disconnect = hdmic_disconnect,
> @@ -183,11 +168,6 @@ static const struct omap_dss_device_ops hdmic_ops = {
> .detect = hdmic_detect,
> .register_hpd_cb= hdmic_register_hpd_cb,
> .unregister_hpd_cb = hdmic_unregister_hpd_cb,
> -
> - .hdmi = {
> - .set_hdmi_mode = hdmic_set_hdmi_mode,
> - .set_infoframe = hdmic_set_infoframe,
> - },
> };
>
> static irqreturn_t hdmic_hpd_isr(int irq, void *data)
> diff --git a/drivers/gpu/drm/omapdrm/displays/encoder-tpd12s015.c
> b/drivers/gpu/drm/omapdrm/displays/encoder-tpd12s015.c
> index dbbf9683bd51..3ad60f4b331e 100644
> --- a/drivers/gpu/drm/omapdrm/displays/encoder-tpd12s015.c
> +++ b/drivers/gpu/drm/omapdrm/displays/encoder-tpd12s015.c
> @@ -145,22 +145,6 @@ static void tpd_unregister_hpd_cb(struct omap_dss_device
> *dssdev)
> mutex_unlock(>hpd_lock);
> }
>
> -static int tpd_set_infoframe(struct omap_dss_device *dssdev,
> - const struct hdmi_avi_infoframe *avi)
> -{
> - struct omap_dss_device *src = dssdev->src;
> -
> - return src->ops->hdmi.set_infoframe(src, avi);
> -}
> -
> -static int tpd_set_hdmi_mode(struct omap_dss_device *dssdev,
> - bool hdmi_mode)
> -{
> - struct omap_dss_device *src = dssdev->src;
> -
> - return src->ops->hdmi.set_hdmi_mode(src, hdmi_mode);
> -}
> -
> static const struct omap_dss_device_ops tpd_ops = {
> .connect= tpd_connect,
> .disconnect = tpd_disconnect,
> @@ -171,11 +155,6 @@ static const struct omap_dss_device_ops tpd_ops = {
> .detect = tpd_detect,
> .register_hpd_cb= tpd_register_hpd_cb,
> .unregister_hpd_cb = tpd_unregister_hpd_cb,
> -
> - .hdmi = {
> - .set_infoframe = tpd_set_infoframe,
> - .set_hdmi_mode = tpd_set_hdmi_mode,
> - },
> };
>
> static irqreturn_t tpd_hpd_isr(int irq, void *data)
> diff --git a/drivers/gpu/drm/omapdrm/omap_encoder.c
> b/drivers/gpu/drm/omapdrm/omap_encoder.c
> index 2689ae74ea60..94b75d018e71 100644
> --- a/drivers/gpu/drm/omapdrm/omap_encoder.c
> +++ b/drivers/gpu/drm/omapdrm/omap_encoder.c
> @@ -58,7 +58,7 @@ static void omap_encoder_mode_set(struct drm_encoder
> *encoder,
> {
> struct drm_device *dev = encoder->dev;
> struct omap_encoder *omap_encoder = to_omap_encoder(encoder);
> - struct omap_dss_device *dssdev = omap_encoder->display;
> + struct omap_dss_device *dssdev = omap_encoder->output;
> struct drm_connector *connector;
> bool hdmi_mode;
> int r;
> --
> Regards,
>
> Laurent Pinchart
>
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
signature.asc
Description: PGP signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 46/60] drm/omap: dss: Remove duplicated parameter to dss_mgr_(dis)connect()
Hi Sebastian,
On Monday, 11 June 2018 02:48:45 EEST Sebastian Reichel wrote:
> On Sat, May 26, 2018 at 08:25:04PM +0300, Laurent Pinchart wrote:
> > The dss_mgr_connect() and dss_mgr_disconnect() functions take two
> > omap_dss_device pointers as parameters, which are always set to the same
> > value by all callers. Remove the duplicated pointer.
> >
> > Signed-off-by: Laurent Pinchart
> > ---
> >
> > drivers/gpu/drm/omapdrm/dss/dpi.c | 8 +++-
> > drivers/gpu/drm/omapdrm/dss/dsi.c | 8 +++-
> > drivers/gpu/drm/omapdrm/dss/hdmi4.c | 8 +++-
> > drivers/gpu/drm/omapdrm/dss/hdmi5.c | 8 +++-
> > drivers/gpu/drm/omapdrm/dss/omapdss.h | 6 ++
> > drivers/gpu/drm/omapdrm/dss/output.c | 9 -
> > drivers/gpu/drm/omapdrm/dss/sdi.c | 8 +++-
> > drivers/gpu/drm/omapdrm/dss/venc.c| 8 +++-
> > 8 files changed, 24 insertions(+), 39 deletions(-)
[snip]
> > diff --git a/drivers/gpu/drm/omapdrm/dss/output.c
> > b/drivers/gpu/drm/omapdrm/dss/output.c index 191b2e801257..2f7a019d059e
> > 100644
> > --- a/drivers/gpu/drm/omapdrm/dss/output.c
> > +++ b/drivers/gpu/drm/omapdrm/dss/output.c
> > @@ -109,18 +109,17 @@ void dss_uninstall_mgr_ops(struct dss_device *dss)
> > }
> > EXPORT_SYMBOL(dss_uninstall_mgr_ops);
> >
> > -int dss_mgr_connect(struct omap_dss_device *dssdev, struct
> > omap_dss_device *dst)
> > +int dss_mgr_connect(struct omap_dss_device *dssdev)
> > {
> > return dssdev->dss->mgr_ops->connect(dssdev->dss->mgr_ops_priv,
> > -dssdev->dispc_channel, dst);
> > +dssdev->dispc_channel, dssdev);
>
> Maybe also change mgr_ops->connect, so that it only takes dssdev
> as a parameter? Otherwise
It would make sense, but patch 60/60 in this series drops the mgr_ops->connect
operation completely, so I don't think it's worth changing this.
> Reviewed-by: Sebastian Reichel
>
> > }
> > EXPORT_SYMBOL(dss_mgr_connect);
[snip]
--
Regards,
Laurent Pinchart
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PULL] drm-intel-next
Hi Dave, This is the first round targeting 4.19. Here goes drm-intel-next-2018-06-06: - Ice Lake's display enabling patches (Jose, Mahesh, Dhinakaran, Paulo, Manasi, Anusha, Arkadiusz) - Ice Lake's workarounds (Oscar and Yunwei) - Ice Lake interrupt registers fixes (Oscar) - Context switch timeline fixes and improvements (Chris) - Spelling fixes (Colin) - GPU reset fixes and improvements (Chris) - Including fixes on execlist and preemption for a proper GPU reset (Chris) - Clean-up the port pipe select bits (Ville) - Other execlist improvements (Chris) - Remove unused enable_cmd_parser parameter (Chris) - Fix order of enabling pipe/transcoder/planes on HSW+ to avoid hang on ICL (Paulo) - Simplification and changes on intel_context (Chris) - Disable LVDS on Radiant P845 (Ondrej) - Improve HSW/BDW voltage swing handling (Ville) - Cleanup and renames on few parts of intel_dp code to make code clear and less confusing (Ville) - Move acpi lid notification code for fixing LVDS (Chris) - Speed up GPU idle detection (Chris) - Make intel_engine_dump irqsafe (Chris) - Fix GVT crash (Zhenyu) - Move GEM BO inside drm_framebuffer and use intel_fb_obj everywhere (Chris) - Revert edp's alternate fixed mode (Jani) - Protect tainted function pointer lookup (Chris) - And subsequent unsigned long size fix (Chris) - Allow page directory allocation to fail (Chris) - VBT's edp and lvds fix and clean-up (Ville) - Many other reorganizations and cleanups on DDI and DP code, as well on scaler and planes (Ville) - Selftest pin the mock kernel context (Chris) - Many PSR Fixes, clean-up and improvements (Dhinakaran) - PSR VBT fix (Vathsala) - Fix i915_scheduler and intel_context declaration (Tvrtko) - Improve PCH underruns detection on ILK-IVB (Ville) - Few s/drm_priv/i915 (Chris, Michal) - Notify opregion of the sanitized encoder state (Maarten) - Guc's event handling improvements and fixes on initialization failures (Michal) - Many gtt fixes and improvements (Chris) - Fixes and improvements for Suspend and Freeze safely (Chris) - i915_gem init and fini cleanup and fixes (Michal) - Remove obsolete switch_mm for gen8+ (Chris) - hw and context id fixes for GuC (Lionel) - Add new vGPU cap info bit VGT_CAPS_HUGE_GTT (Changbin) - Make context pin/unpin symmetric (Chris) - vma: Move the bind_count vs pin_count assertion to a helper (Chris) - Use available SZ_1M instead of 1 << 20 (Chris) - Trace and PMU fixes and improvements (Tvrtko) Thanks, Rodrigo. The following changes since commit 01f83786f9ab9c8883ce634cb9a0de51086ad7ea: drm/i915: Update DRIVER_DATE to 20180514 (2018-05-14 15:28:05 +0300) are available in the Git repository at: git://anongit.freedesktop.org/drm/drm-intel tags/drm-intel-next-2018-06-06 for you to fetch changes up to 14c3f8425080a1ff97df7b81f7c339bf42c427a3: drm/i915: Update DRIVER_DATE to 20180606 (2018-06-06 15:10:47 -0700) - Ice Lake's display enabling patches (Jose, Mahesh, Dhinakaran, Paulo, Manasi, Anusha, Arkadiusz) - Ice Lake's workarounds (Oscar and Yunwei) - Ice Lake interrupt registers fixes (Oscar) - Context switch timeline fixes and improvements (Chris) - Spelling fixes (Colin) - GPU reset fixes and improvements (Chris) - Including fixes on execlist and preemption for a proper GPU reset (Chris) - Clean-up the port pipe select bits (Ville) - Other execlist improvements (Chris) - Remove unused enable_cmd_parser parameter (Chris) - Fix order of enabling pipe/transcoder/planes on HSW+ to avoid hang on ICL (Paulo) - Simplification and changes on intel_context (Chris) - Disable LVDS on Radiant P845 (Ondrej) - Improve HSW/BDW voltage swing handling (Ville) - Cleanup and renames on few parts of intel_dp code to make code clear and less confusing (Ville) - Move acpi lid notification code for fixing LVDS (Chris) - Speed up GPU idle detection (Chris) - Make intel_engine_dump irqsafe (Chris) - Fix GVT crash (Zhenyu) - Move GEM BO inside drm_framebuffer and use intel_fb_obj everywhere (Chris) - Revert edp's alternate fixed mode (Jani) - Protect tainted function pointer lookup (Chris) - And subsequent unsigned long size fix (Chris) - Allow page directory allocation to fail (Chris) - VBT's edp and lvds fix and clean-up (Ville) - Many other reorganizations and cleanups on DDI and DP code, as well on scaler and planes (Ville) - Selftest pin the mock kernel context (Chris) - Many PSR Fixes, clean-up and improvements (Dhinakaran) - PSR VBT fix (Vathsala) - Fix i915_scheduler and intel_context declaration (Tvrtko) - Improve PCH underruns detection on ILK-IVB (Ville) - Few s/drm_priv/i915 (Chris, Michal) - Notify opregion of the sanitized encoder state (Maarten) - Guc's event handling improvements and fixes on initialization failures (Michal) - Many gtt fixes and improvements (Chris) - Fixes and improvements for Suspend and Freeze safely (Chris) - i915_gem init and fini cleanup and fixes (Michal) - Remove obsolete switch_mm for
[Bug 199619] screen stays dark for long on bootup since kernel 4.17.0-rc2+
https://bugzilla.kernel.org/show_bug.cgi?id=199619 Giorgio (giorgio.colacc...@gmail.com) changed: What|Removed |Added CC||giorgio.colacc...@gmail.com --- Comment #7 from Giorgio (giorgio.colacc...@gmail.com) --- Hi Elmar, I don’t know if it may be of help, anyway I have a similar problem: the point is that my problem does not seem related to graphic drivers. My OS is Slackware64 14.2, kernel 4.17.0. At boot, after the usual kernel messages, this is what I see, at the end, on the screen (please, note that I boot in non graphical mode, that is in init 3): Welcome to Linux 4.17.0 (tty1) darkstar login: [ 15.869206] wlan0: authenticate with 64:59:f8:cd:3a:88 [ 15.887504] wlan0: send auth to 64:59:f8:cd:3a:88 (try 1/3) [ 15.892825] wlan0: authenticated [ 15.895108] wlan0: associate with 64:59:f8:cd:3a:88 (try 1/3) [ 15.899592] wlan0: RX AssocResp from 64:59:f8:cd:3a:88 (capab=0x411 status=0 aid=3) [ 15.900872] wlan0: associated as you can see, after the welcome message I can’t insert my login username – because of the extra messages related to wlan authentication/association – and as a consequence the system gets stuck. However, (in my case) we are dealing here with a “trivial” bug, since it suffices to press Enter in order to restore the login prompt and then start X. I don’t know if this bug may be related to yours: in any case I would try to boot in runlevel 3 in order to see what happens. All the best, Giorgio -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 199619] screen stays dark for long on bootup since kernel 4.17.0-rc2+
https://bugzilla.kernel.org/show_bug.cgi?id=199619 --- Comment #8 from Giorgio (giorgio.colacc...@gmail.com) --- Hi Elmar, I don’t know if it may be of help, anyway I have a similar problem: the point is that my problem does not seem related to graphic drivers. My OS is Slackware64 14.2, kernel 4.17.0. At boot, after the usual kernel messages, this is what I see, at the end, on the screen (please, note that I boot in non graphical mode, that is in init 3): Welcome to Linux 4.17.0 (tty1) darkstar login: [ 15.869206] wlan0: authenticate with 64:59:f8:cd:3a:88 [ 15.887504] wlan0: send auth to 64:59:f8:cd:3a:88 (try 1/3) [ 15.892825] wlan0: authenticated [ 15.895108] wlan0: associate with 64:59:f8:cd:3a:88 (try 1/3) [ 15.899592] wlan0: RX AssocResp from 64:59:f8:cd:3a:88 (capab=0x411 status=0 aid=3) [ 15.900872] wlan0: associated as you can see, after the welcome message I can’t insert my login username – because of the extra messages related to wlan authentication/association – and as a consequence the system gets stuck. However, (in my case) we are dealing here with a “trivial” bug, since it suffices to press Enter in order to restore the login prompt and then start X. I don’t know if this bug may be related to yours: in any case I would try to boot in runlevel 3 in order to see what happens. All the best, Giorgio -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Intel-gfx] [PATCH] drm/i915/guc: remove redundant GEM_BUG_ON check
On 11/06/18 17:25, Ville Syrjälä wrote:
> On Mon, Jun 11, 2018 at 05:00:37PM +0100, Colin King wrote:
>> From: Colin Ian King
>>
>> The check for level being less than zero is redundant as level
>> is an unsigned u32 and hence will never be less than zero.
>> Remove this redundant check.
>>
>> Detected by CoverityScan, CID#1468363 ("Macro compares unsigned to 0")
>>
>> Signed-off-by: Colin Ian King
>> ---
>> drivers/gpu/drm/i915/intel_guc.c | 2 --
>> 1 file changed, 2 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/i915/intel_guc.c
>> b/drivers/gpu/drm/i915/intel_guc.c
>> index 116f4ccf1bbd..a2f782a4f97d 100644
>> --- a/drivers/gpu/drm/i915/intel_guc.c
>> +++ b/drivers/gpu/drm/i915/intel_guc.c
>> @@ -208,8 +208,6 @@ static u32 get_log_control_flags(void)
>> u32 level = i915_modparams.guc_log_level;
>> u32 flags = 0;
>>
>> -GEM_BUG_ON(level < 0);
>
> i915_modparams.guc_log_level is a signed int. So s/u32/int would seem
> like a better fix.
Good point, I somehow thought it guc_loc_level was unsigned, but I was
wrong. Sending a V2.
>
>> -
>> if (!GUC_LOG_LEVEL_IS_ENABLED(level))
>> flags |= GUC_LOG_DEFAULT_DISABLED;
>>
>> --
>> 2.17.0
>>
>> ___
>> Intel-gfx mailing list
>> intel-...@lists.freedesktop.org
>> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH][V2] drm/i915/guc: fix GEM_BUG_ON check
From: Colin Ian King
The check for level being less than zero always false because flags
is currently unsigned and can never be negative. Fix this by making
flags a s32.
Detected by CoverityScan, CID#1468363 ("Macro compares unsigned to 0")
Signed-off-by: Colin Ian King
---
V2: Make flags s32 rather than remove the GEM_BUG_ON check, thanks to
Ville Syrjälä for spotting the mistake in my first attempt.
---
drivers/gpu/drm/i915/intel_guc.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/intel_guc.c b/drivers/gpu/drm/i915/intel_guc.c
index 116f4ccf1bbd..fb31f5004bcf 100644
--- a/drivers/gpu/drm/i915/intel_guc.c
+++ b/drivers/gpu/drm/i915/intel_guc.c
@@ -206,7 +206,7 @@ void intel_guc_fini(struct intel_guc *guc)
static u32 get_log_control_flags(void)
{
u32 level = i915_modparams.guc_log_level;
- u32 flags = 0;
+ s32 flags = 0;
GEM_BUG_ON(level < 0);
--
2.17.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm: Constify mode argument to connector .mode_valid() helper operation
On Thu, Jun 07, 2018 at 03:13:23PM +0300, Laurent Pinchart wrote: > Hi Ville, > > On Thursday, 7 June 2018 15:03:12 EEST Ville Syrjälä wrote: > > On Wed, Jun 06, 2018 at 12:08:12PM +0300, Laurent Pinchart wrote: > > > The drm_connector_helper_funcs .mode_valid() operation should not modify > > > the mode it receives in any way. To make this explicit, constify the > > > mode pointer as done for all other .mode_valid() operations, and update > > > all drivers accordingly. > > > > > > Signed-off-by: Laurent Pinchart > > > > Didn't spot anything wrong. I think the omap case should be fine as > > well since the probe helper will populate the vrefresh for the mode > > eventually. > > > > Reviewed-by: Ville Syrjälä > > The patch has lived in my public tree for a few days now and the kbuild bot > hasn't complained (or rather it complained on the previous version that I > hadn't posted to the list yet, and I've fixed the problems before posting > this > version). Given the risk of conflicts I'd rather get this merged sooner than > later. Is that fine with you ? Seems safe to me. So IMO just push if no one has complained. > > > > --- > > > > > > This patch touches lots of drivers, so checkpatch.pl created a huge CC > > > list that would likely be too large for the mailing list. As changes to > > > most files just boil down to adding a const keyword, I've decided to only > > > CC the DRM misc maintainers, as well as Tomi for omapdrm as the change to > > > that driver is slightly more complex. > > > > > > drivers/gpu/drm/amd/amdgpu/amdgpu_connectors.c | 8 > > > drivers/gpu/drm/amd/amdgpu/atombios_dp.c | 2 +- > > > drivers/gpu/drm/amd/amdgpu/atombios_dp.h | 2 +- > > > drivers/gpu/drm/amd/amdgpu/dce_virtual.c | 2 +- > > > drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c| 2 +- > > > drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.h| 2 +- > > > drivers/gpu/drm/ast/ast_mode.c | 2 +- > > > drivers/gpu/drm/bochs/bochs_kms.c| 2 +- > > > drivers/gpu/drm/bridge/adv7511/adv7511_drv.c | 4 ++-- > > > drivers/gpu/drm/bridge/megachips-stdp-ge-b850v3-fw.c | 2 +- > > > drivers/gpu/drm/bridge/sii902x.c | 2 +- > > > drivers/gpu/drm/bridge/tc358767.c| 2 +- > > > drivers/gpu/drm/exynos/exynos_hdmi.c | 2 +- > > > drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_rgb.c| 2 +- > > > drivers/gpu/drm/gma500/cdv_intel_crt.c | 2 +- > > > drivers/gpu/drm/gma500/cdv_intel_dp.c| 2 +- > > > drivers/gpu/drm/gma500/cdv_intel_hdmi.c | 2 +- > > > drivers/gpu/drm/gma500/cdv_intel_lvds.c | 2 +- > > > drivers/gpu/drm/gma500/mdfld_dsi_output.c| 2 +- > > > drivers/gpu/drm/gma500/oaktrail_hdmi.c | 2 +- > > > drivers/gpu/drm/gma500/psb_intel_drv.h | 2 +- > > > drivers/gpu/drm/gma500/psb_intel_lvds.c | 2 +- > > > drivers/gpu/drm/gma500/psb_intel_sdvo.c | 2 +- > > > drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_vdac.c | 2 +- > > > drivers/gpu/drm/i2c/ch7006_drv.c | 2 +- > > > drivers/gpu/drm/i2c/sil164_drv.c | 2 +- > > > drivers/gpu/drm/i2c/tda998x_drv.c| 2 +- > > > drivers/gpu/drm/i915/dvo.h | 2 +- > > > drivers/gpu/drm/i915/dvo_ch7017.c| 2 +- > > > drivers/gpu/drm/i915/dvo_ch7xxx.c| 2 +- > > > drivers/gpu/drm/i915/dvo_ivch.c | 2 +- > > > drivers/gpu/drm/i915/dvo_ns2501.c| 2 +- > > > drivers/gpu/drm/i915/dvo_sil164.c| 2 +- > > > drivers/gpu/drm/i915/dvo_tfp410.c| 2 +- > > > drivers/gpu/drm/i915/intel_crt.c | 2 +- > > > drivers/gpu/drm/i915/intel_dp.c | 2 +- > > > drivers/gpu/drm/i915/intel_dp_mst.c | 2 +- > > > drivers/gpu/drm/i915/intel_dsi.c | 2 +- > > > drivers/gpu/drm/i915/intel_dvo.c | 2 +- > > > drivers/gpu/drm/i915/intel_hdmi.c| 2 +- > > > drivers/gpu/drm/i915/intel_lvds.c| 2 +- > > > drivers/gpu/drm/i915/intel_sdvo.c| 2 +- > > > drivers/gpu/drm/i915/intel_tv.c | 2 +- > > > drivers/gpu/drm/imx/imx-tve.c| 2 +- > > > drivers/gpu/drm/mediatek/mtk_hdmi.c | 2 +- > > > drivers/gpu/drm/meson/meson_venc_cvbs.c | 2 +- > > > drivers/gpu/drm/mgag200/mgag200_mode.c | 4 ++-- > > > drivers/gpu/drm/msm/disp/mdp4/mdp4_lvds_connector.c | 2 +- >
Re: [Xen-devel] [PATCH v2 5/9] xen/gntdev: Allow mappings for DMA buffers
On Mon, 11 Jun 2018, Oleksandr Andrushchenko wrote:
> On 06/08/2018 10:21 PM, Boris Ostrovsky wrote:
> > On 06/08/2018 01:59 PM, Stefano Stabellini wrote:
> > > > > > > > > > @@ -325,6 +401,14 @@ static int map_grant_pages(struct
> > > > > > > > > > grant_map
> > > > > > > > > > *map)
> > > > > > > > > > map->unmap_ops[i].handle =
> > > > > > > > > > map->map_ops[i].handle;
> > > > > > > > > > if (use_ptemod)
> > > > > > > > > > map->kunmap_ops[i].handle =
> > > > > > > > > > map->kmap_ops[i].handle;
> > > > > > > > > > +#ifdef CONFIG_XEN_GRANT_DMA_ALLOC
> > > > > > > > > > + else if (map->dma_vaddr) {
> > > > > > > > > > + unsigned long mfn;
> > > > > > > > > > +
> > > > > > > > > > + mfn = __pfn_to_mfn(page_to_pfn(map->pages[i]));
> > > > > > > > > Not pfn_to_mfn()?
> > > > > > > > I'd love to, but pfn_to_mfn is only defined for x86, not ARM:
> > > > > > > > [1]
> > > > > > > > and [2]
> > > > > > > > Thus,
> > > > > > > >
> > > > > > > > drivers/xen/gntdev.c:408:10: error: implicit declaration of
> > > > > > > > function
> > > > > > > > ‘pfn_to_mfn’ [-Werror=implicit-function-declaration]
> > > > > > > > mfn = pfn_to_mfn(page_to_pfn(map->pages[i]));
> > > > > > > >
> > > > > > > > So, I'll keep __pfn_to_mfn
> > > > > > > How will this work on non-PV x86?
> > > > > > So, you mean I need:
> > > > > > #ifdef CONFIG_X86
> > > > > > mfn = pfn_to_mfn(page_to_pfn(map->pages[i]));
> > > > > > #else
> > > > > > mfn = __pfn_to_mfn(page_to_pfn(map->pages[i]));
> > > > > > #endif
> > > > > >
> > > > > I'd rather fix it in ARM code. Stefano, why does ARM uses the
> > > > > underscored version?
> > > > Do you want me to add one more patch for ARM to wrap __pfn_to_mfn
> > > > with static inline for ARM? e.g.
> > > > static inline ...pfn_to_mfn(...)
> > > > {
> > > > __pfn_to_mfn();
> > > > }
> > > A Xen on ARM guest doesn't actually know the mfns behind its own
> > > pseudo-physical pages. This is why we stopped using pfn_to_mfn and
> > > started using pfn_to_bfn instead, which will generally return "pfn",
> > > unless the page is a foreign grant. See include/xen/arm/page.h.
> > > pfn_to_bfn was also introduced on x86. For example, see the usage of
> > > pfn_to_bfn in drivers/xen/swiotlb-xen.c. Otherwise, if you don't care
> > > about other mapped grants, you can just use pfn_to_gfn, that always
> > > returns pfn.
> >
> > I think then this code needs to use pfn_to_bfn().
> Ok
> >
> >
> > > Also, for your information, we support different page granularities in
> > > Linux as a Xen guest, see the comment at include/xen/arm/page.h:
> > >
> > >/*
> > > * The pseudo-physical frame (pfn) used in all the helpers is always
> > > based
> > > * on Xen page granularity (i.e 4KB).
> > > *
> > > * A Linux page may be split across multiple non-contiguous Xen page so
> > > we
> > > * have to keep track with frame based on 4KB page granularity.
> > > *
> > > * PV drivers should never make a direct usage of those helpers
> > > (particularly
> > > * pfn_to_gfn and gfn_to_pfn).
> > > */
> > >
> > > A Linux page could be 64K, but a Xen page is always 4K. A granted page
> > > is also 4K. We have helpers to take into account the offsets to map
> > > multiple Xen grants in a single Linux page, see for example
> > > drivers/xen/grant-table.c:gnttab_foreach_grant. Most PV drivers have
> > > been converted to be able to work with 64K pages correctly, but if I
> > > remember correctly gntdev.c is the only remaining driver that doesn't
> > > support 64K pages yet, so you don't have to deal with it if you don't
> > > want to.
> >
> > I believe somewhere in this series there is a test for PAGE_SIZE vs.
> > XEN_PAGE_SIZE. Right, Oleksandr?
> Not in gntdev. You might have seen this in xen-drmfront/xen-sndfront,
> but I didn't touch gntdev for that. Do you want me to add yet another patch
> in the series to check for that?
gntdev.c is already not capable of handling PAGE_SIZE != XEN_PAGE_SIZE,
so you are not going to break anything that is not already broken :-) If
your new gntdev.c code relies on PAGE_SIZE == XEN_PAGE_SIZE, it might be
good to add an in-code comment about it, just to make it easier to fix
the whole of gntdev.c in the future.
> > Thanks for the explanation.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 44/60] drm/omap: dss: Add for_each_dss_output() macro
Hi Sebastian,
On Monday, 11 June 2018 02:52:44 EEST Sebastian Reichel wrote:
> On Sat, May 26, 2018 at 08:25:02PM +0300, Laurent Pinchart wrote:
> > Similarly to for_each_dss_display(), the for_each_dss_output() macro
> > iterates over all the DSS connected outputs.
> >
> > Signed-off-by: Laurent Pinchart
> > ---
> >
> > drivers/gpu/drm/omapdrm/dss/base.c| 20 ++--
> > drivers/gpu/drm/omapdrm/dss/omapdss.h | 9 ++---
> > 2 files changed, 20 insertions(+), 9 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/omapdrm/dss/base.c
> > b/drivers/gpu/drm/omapdrm/dss/base.c index 96be800a0f25..519682f18d36
> > 100644
> > --- a/drivers/gpu/drm/omapdrm/dss/base.c
> > +++ b/drivers/gpu/drm/omapdrm/dss/base.c
> > @@ -127,11 +127,13 @@ struct omap_dss_device
> > *omapdss_find_device_by_port(struct device_node *src,>
> > /*
> >
> > * Search for the next device starting at @from. If display_only is true,
> > skip>
> > - * non-display devices. Release the reference to the @from device, and
> > acquire - * a reference to the returned device if found.
> > + * non-display devices. If output_only is true, skip non-output devices
> > and + * non-connected output devices. Release the reference to the @from
> > device, and + * acquire a reference to the returned device if found.
> >
> > */
> >
> > struct omap_dss_device *omapdss_device_get_next(struct omap_dss_device
> > *from,>
> > - bool display_only)
> > + bool display_only,
> > + bool output_only)
>
> display_only and output_only are mutually exclusive, so I think it
> would be better to use this as parameter. It would also improve
> code readability a bit:
>
> enum omapdss_device_type {
> OMAPDSS_DEVICE_TYPE_ALL,
> OMAPDSS_DEVICE_TYPE_OUTPUT_ONLY,
> OMAPDSS_DEVICE_TYPE_DISPLAY_ONLY,
> };
That's a good point, even if all this code is meant to disappear.
What would you think of
enum omap_dss_device_type {
OMAP_DSS_DEVICE_TYPE_OUTPUT = (1 << 0),
OMAP_DSS_DEVICE_TYPE_DISPLAY = (1 << 1),
};
and combining the flags when passed to omapdss_device_get_next() ?
> > {
> >
> > struct omap_dss_device *dssdev;
> > struct list_head *list;
> >
> > @@ -159,9 +161,15 @@ struct omap_dss_device
> > *omapdss_device_get_next(struct omap_dss_device *from,>
> > goto done;
> >
> > }
> >
> > - /* Filter out non-display entries if display_only is set. */
> > - if (!display_only || dssdev->driver)
> > - goto done;
> > + /*
> > +* Filter out non-display entries if display_only is set, and
> > +* non-output entries if output_only is set.
> > +*/
> > + if (display_only && !dssdev->driver)
> > + continue;
> > + if (output_only && (!dssdev->id || !dssdev->next))
> > + continue;
> > + goto done;
> >
> > }
> >
> > dssdev = NULL;
> >
> > diff --git a/drivers/gpu/drm/omapdrm/dss/omapdss.h
> > b/drivers/gpu/drm/omapdrm/dss/omapdss.h index 5d3e4ced73d1..723124f6e596
> > 100644
> > --- a/drivers/gpu/drm/omapdrm/dss/omapdss.h
> > +++ b/drivers/gpu/drm/omapdrm/dss/omapdss.h
> > @@ -488,9 +488,9 @@ static inline bool omapdss_is_initialized(void)
> >
> > return !!omapdss_get_dss();
> >
> > }
> >
> > -void omapdss_display_init(struct omap_dss_device *dssdev);
> >
> > #define for_each_dss_display(d) \
> >
> > - while ((d = omapdss_device_get_next(d, true)) != NULL)
> > + while ((d = omapdss_device_get_next(d, true, false)) != NULL)
> > +void omapdss_display_init(struct omap_dss_device *dssdev);
> >
> > void omapdss_device_register(struct omap_dss_device *dssdev);
> > void omapdss_device_unregister(struct omap_dss_device *dssdev);
> >
> > @@ -499,7 +499,8 @@ void omapdss_device_put(struct omap_dss_device
> > *dssdev);>
> > struct omap_dss_device *omapdss_find_device_by_port(struct device_node
> > *src,>
> > unsigned int port);
> >
> > struct omap_dss_device *omapdss_device_get_next(struct omap_dss_device
> > *from,>
> > - bool display_only);
> > + bool display_only,
> > + bool output_only);
> >
> > int omapdss_device_connect(struct dss_device *dss,
> >
> >struct omap_dss_device *src,
> >struct omap_dss_device *dst);
> >
> > @@ -511,6 +512,8 @@ int omap_dss_get_num_overlay_managers(void);
> >
> > int omap_dss_get_num_overlays(void);
> >
> > +#define for_each_dss_output(d) \
> > + while ((d = omapdss_device_get_next(d, false, true)) != NULL)
> >
> > int omapdss_output_set_device(struct omap_dss_device *out,
> >
> > struct
[Bug 106872] vram sizes reported by the kernel totally off
https://bugs.freedesktop.org/show_bug.cgi?id=106872 --- Comment #1 from Michel Dänzer --- Please attach the dmesg output from the affected system, preferably captured while or after the problem occurs. (In reply to Bas Nieuwenhuizen from comment #0) > e.g. the last report we had kernel reported total VRAM size of > 0xfffb3070f000 (16.0 EiB) and a visible VRAM size of 0x86135000 (2.09 > GiB). Not the other way around? One potential issue I can see is that only BOs with AMDGPU_GEM_CREATE_NO_CPU_ACCESS are accounted for invisible_pin_size. But such BOs can still end up pinned at least partially in CPU visible VRAM, which would mess up the calculation of how much visible VRAM currently isn't pinned. One possible solution for this would be for amdgpu_bo_pin_restricted and amdgpu_bo_unpin to walk the list of memory nodes and calculate exactly how much of each of them lies in visible or invisible VRAM. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 02/13] drm/vmwgfx: Stop using plane->fb in vmw_kms_helper_dirty()
On Mon, Jun 04, 2018 at 11:13:53AM -0700, Sinclair Yeh wrote:
> On Wed, May 30, 2018 at 11:08:57PM +0300, Ville Syrjälä wrote:
> > On Fri, May 25, 2018 at 09:50:34PM +0300, Ville Syrjala wrote:
> > > From: Ville Syrjälä
> > >
> > > Instead of plane->fb (which we're going to deprecate for atomic drivers)
> > > we need to look at plane->state->fb. The maze of code leading to
> > > vmw_kms_helper_dirty() wasn't particularly clear, but my analysis
> > > concluded that the calls originating from
> > > vmw_*_primary_plane_atomic_update()
> > > all pass in the crtc which means we'll never end up in this branch
> > > of the function. All other callers use drm_modeset_lock_all() somewhere
> > > higher up, which means accessing plane->state is safe. We'll toss in
> > > a lockdep assert to catch wrongdoers.
> > >
> > > v2: Drop the comment and make the code do what it did before (Thomas)
> > >
> > > Cc: Deepak Rawat
> > > Cc: Thomas Hellstrom
> > > Cc: Sinclair Yeh
> > > Cc: VMware Graphics
> > > Cc: Daniel Vetter
> > > Signed-off-by: Ville Syrjälä
> > > ---
> > > drivers/gpu/drm/vmwgfx/vmwgfx_kms.c | 9 ++---
> > > 1 file changed, 6 insertions(+), 3 deletions(-)
> > >
> > > diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c
> > > b/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c
> > > index 2e4c38bb846d..5417eb1b486e 100644
> > > --- a/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c
> > > +++ b/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c
> > > @@ -2326,9 +2326,12 @@ int vmw_kms_helper_dirty(struct vmw_private
> > > *dev_priv,
> > > } else {
> > > list_for_each_entry(crtc, _priv->dev->mode_config.crtc_list,
> > > head) {
> > > - if (crtc->primary->fb != >base)
> > > - continue;
> > > - units[num_units++] = vmw_crtc_to_du(crtc);
> > > + struct drm_plane *plane = crtc->primary;
> > > +
> > > + lockdep_assert_held(>mutex);
> >
> > kbuild test robot told me
> > >> include/linux/lockdep.h:347:52: error: 'struct drm_modeset_lock' has
> > >> no member named 'dep_map'
> > #define lockdep_is_held(lock) lock_is_held(&(lock)->dep_map)
> >
> >
> > Maybe I'll just drop the asserts? Or do people really want them
> > (in which case I gues I need to dig out the underlying mutex)?
>
> Eitherway is fine with me.
I just dropped them, and pushe the series to drm-misc-next. Thanks for
the reviews everyone.
Fingers crossed that no new uses of the legacy pointers have been added
in the meantime. A quick grep didn't seem to catch anything at least,
but selective blindness can occur sometimes. So just holler if
anything broke...
--
Ville Syrjälä
Intel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 106287] 18.0.1 introduced glitches in Dying Light
https://bugs.freedesktop.org/show_bug.cgi?id=106287 --- Comment #9 from Henrik Holst --- Just tried that and the black box around the sight vanished but the water effect is still there for me, this is on 18.0.1 however so perhaps 18.1.x works differently there. Wouldn't be surprised either if this is an actual game bug considering how unstable Dying Light is (cannot currently go past the granary since the game crashes there every time). -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] staging: android: ion: Return an ERR_PTR in ion_map_kernel
The expected return value from ion_map_kernel is an ERR_PTR. The error path for a vmalloc failure currently just returns NULL, triggering a warning in ion_buffer_kmap_get. Encode the vmalloc failure as an ERR_PTR. Reported-by: syzbot+55b1d9f811650de94...@syzkaller.appspotmail.com Signed-off-by: Laura Abbott --- drivers/staging/android/ion/ion_heap.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/staging/android/ion/ion_heap.c b/drivers/staging/android/ion/ion_heap.c index 772dad65396e..f32c12439eee 100644 --- a/drivers/staging/android/ion/ion_heap.c +++ b/drivers/staging/android/ion/ion_heap.c @@ -29,7 +29,7 @@ void *ion_heap_map_kernel(struct ion_heap *heap, struct page **tmp = pages; if (!pages) - return NULL; + return ERR_PTR(-ENOMEM); if (buffer->flags & ION_FLAG_CACHED) pgprot = PAGE_KERNEL; -- 2.17.0 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 51/60] drm/omap: Reverse direction of DSS device (dis)connect operations
Hi Sebastian,
On Monday, 11 June 2018 14:59:13 EEST Sebastian Reichel wrote:
> On Sat, May 26, 2018 at 08:25:09PM +0300, Laurent Pinchart wrote:
> > The omapdrm and omapdss drivers are architectured based on display
> > pipelines made of multiple components handled from sink (display) to
> > source (DSS output). This is incompatible with the DRM bridge and panel
> > APIs that handle components from source to sink.
> >
> > To reconcile the omapdrm and omapdss drivers with the DRM bridge and
> > panel model, we need to reverse the direction of the DSS device
> > operations. Start with the connect and disconnect operations.
> >
> > Signed-off-by: Laurent Pinchart
> > ---
>
> Looks mostly good, but I found one issue:
>
> [...]
>
> > -static void dsicm_disconnect(struct omap_dss_device *dssdev)
> > +static void dsicm_disconnect(struct omap_dss_device *src,
> > +struct omap_dss_device *dst)
> > {
> > - struct panel_drv_data *ddata = to_panel_data(dssdev);
> > - struct omap_dss_device *src = dssdev->src;
> > + struct panel_drv_data *ddata = to_panel_data(dst);
> >
> > src->ops->dsi.release_vc(src, ddata->channel);
>
> ^^^ using src in dsicm_disconnect()
>
> > - omapdss_device_disconnect(src, dssdev);
> > -
> > - omapdss_device_put(src);
> > }
> >
> > static int dsicm_enable(struct omap_dss_device *dssdev)
> > @@ -1404,7 +1382,7 @@ static int __exit dsicm_remove(struct
> > platform_device *pdev)>
> > omapdss_device_unregister(dssdev);
> >
> > dsicm_disable(dssdev);
> > - dsicm_disconnect(dssdev);
> > + dsicm_disconnect(NULL, dssdev);
>
> ^^^ calling dsicm_disconnect() with src=NULL
>
> This will execute dsi_release_vc(NULL, channel), which will try to
> dereference NULL.
Good catch. I'll replace this line with
dsicm_disconnect(dssdev->src, dssdev);
--
Regards,
Laurent Pinchart
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 106871] Screen with blank cursor (raven ridge on MSI B350)
https://bugs.freedesktop.org/show_bug.cgi?id=106871 --- Comment #2 from Erik --- Thank a lot!, i will forward the bug. (Still interesting how you can figure this out from my logging.) -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 0/5] drm/msm: Add support for Adreno a6xx
This is an initial version of support for the Adreno a6xx GPU family starting with the a630 from the sdm845 SoC. This code is ahead of much of the sdm845 code that would be needed to actually bring up a device and it is also in advance of any user side support for the a6xx GPU so this is mainly just a chance to look over the code structure and get a feel for the direction that the hardware is going in. The a6xx GPU is an iteration of a5xx so most of the GPU side code looks pretty identical except for the usual register differences. The big different is in power control. On the a5xx there was a rudimentary device called the GPMU that did some basic power stuff but left most of the complexity to the kernel. On the a6xx the power complexity is being moved to a component called the GMU (graphics management unit) which handles the power control of the GPU and shuts it down quickly after it goes idle. This stack has a number of dependencies that are in various stages of being merged: https://patchwork.kernel.org/patch/10286375/ - dev_pm_opp_get_of_node() https://patchwork.kernel.org/patch/10333575/ - command DB https://patchwork.kernel.org/patch/10301163/ - pm_runtime ops for arm-smmu [v5 - Move firmware loading to adreno_load_gpu() so it is easier to fail if the firmware isn't found ] [v4 - Add clock parsing helper function and use it for GPU and GMU. Update recommended clock gating settings. Fix a bug in the CMD DB parser. Update register values from updated database ] [v3 - fix inverted register definition for GMU_SPTPRAC_CLK_STATUS; fix incorrect register check in a5xx_gmu_gx_is_on(), use dev_pm_opp_get_of_node() from Rajendra and Viresh to read the qcom,level from the device tree; read qcom,level from the DT to get the voltage level to pass to the GMU, fix issues identified by smatch] [v2 - addressed comments from Lucas Stach; added pm_runtime_get_supplier calls for accesses to the GMU IOMMU; moved to SPDX headers for new files] Jordan Crouse (4): drm/msm: Remove pm_runtime operations from msm_iommu drm/msm: Add a helper function to parse clock names drm/msm/adreno: Load the firmware before bringing up the hardware drm/msm: Add A6XX device support Sharat Masetty (1): drm/msm: Add generated headers for A6XX drivers/gpu/drm/msm/Makefile |3 + drivers/gpu/drm/msm/adreno/a6xx.xml.h | 1784 drivers/gpu/drm/msm/adreno/a6xx_gmu.c | 1172 + drivers/gpu/drm/msm/adreno/a6xx_gmu.h | 162 ++ drivers/gpu/drm/msm/adreno/a6xx_gmu.xml.h | 382 + drivers/gpu/drm/msm/adreno/a6xx_gpu.c | 807 + drivers/gpu/drm/msm/adreno/a6xx_gpu.h | 60 + drivers/gpu/drm/msm/adreno/a6xx_hfi.c | 435 + drivers/gpu/drm/msm/adreno/a6xx_hfi.h | 127 ++ drivers/gpu/drm/msm/adreno/adreno_device.c | 35 +- drivers/gpu/drm/msm/adreno/adreno_gpu.c|2 +- drivers/gpu/drm/msm/adreno/adreno_gpu.h|4 + drivers/gpu/drm/msm/msm_drv.c | 57 + drivers/gpu/drm/msm/msm_drv.h |4 + drivers/gpu/drm/msm/msm_gpu.c | 62 +- drivers/gpu/drm/msm/msm_gpu.h |2 +- drivers/gpu/drm/msm/msm_iommu.c|8 - 17 files changed, 5044 insertions(+), 62 deletions(-) create mode 100644 drivers/gpu/drm/msm/adreno/a6xx.xml.h create mode 100644 drivers/gpu/drm/msm/adreno/a6xx_gmu.c create mode 100644 drivers/gpu/drm/msm/adreno/a6xx_gmu.h create mode 100644 drivers/gpu/drm/msm/adreno/a6xx_gmu.xml.h create mode 100644 drivers/gpu/drm/msm/adreno/a6xx_gpu.c create mode 100644 drivers/gpu/drm/msm/adreno/a6xx_gpu.h create mode 100644 drivers/gpu/drm/msm/adreno/a6xx_hfi.c create mode 100644 drivers/gpu/drm/msm/adreno/a6xx_hfi.h -- 2.17.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 3/5] drm/msm/adreno: Load the firmware before bringing up the hardware
Failure to load firwmare is the primary reason to fail adreno_load_gpu().
Try to load it first before going into the hardware initialization code and
unwinding it. This is important for a6xx because the GMU gets loaded from
the runtime power code and it is more costly to fail in that path because
of missing firmware.
Signed-off-by: Jordan Crouse
---
drivers/gpu/drm/msm/adreno/adreno_device.c | 23 +-
1 file changed, 22 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/msm/adreno/adreno_device.c
b/drivers/gpu/drm/msm/adreno/adreno_device.c
index 0c0eaad68065..d70e7d145dae 100644
--- a/drivers/gpu/drm/msm/adreno/adreno_device.c
+++ b/drivers/gpu/drm/msm/adreno/adreno_device.c
@@ -155,6 +155,7 @@ struct msm_gpu *adreno_load_gpu(struct drm_device *dev)
struct msm_drm_private *priv = dev->dev_private;
struct platform_device *pdev = priv->gpu_pdev;
struct msm_gpu *gpu = NULL;
+ struct adreno_gpu *adreno_gpu;
int ret;
if (pdev)
@@ -165,7 +166,27 @@ struct msm_gpu *adreno_load_gpu(struct drm_device *dev)
return NULL;
}
- pm_runtime_get_sync(>dev);
+ adreno_gpu = to_adreno_gpu(gpu);
+
+ /*
+* The number one reason for HW init to fail is if the firmware isn't
+* loaded yet. Try that first and don't bother continuing on
+* otherwise
+*/
+
+ ret = adreno_load_fw(adreno_gpu);
+ if (ret)
+ return NULL;
+
+ /* Make sure pm runtime is active and reset any previous errors */
+ pm_runtime_set_active(>dev);
+
+ ret = pm_runtime_get_sync(>dev);
+ if (ret < 0) {
+ dev_err(dev->dev, "Couldn't power up the GPU: %d\n", ret);
+ return NULL;
+ }
+
mutex_lock(>struct_mutex);
ret = msm_gpu_hw_init(gpu);
mutex_unlock(>struct_mutex);
--
2.17.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 5/5] drm/msm: Add A6XX device support
Add support for the A6XX family of Adreno GPUs. The biggest addition
is the GMU (Graphics Management Unit) which takes over most of the
power management of the GPU itself but in a ironic twist of fate
needs a goodly amount of management itself. Add support for the
A6XX core code, the GMU and the HFI (hardware firmware interface)
queue that the CPU uses to communicate with the GMU.
Signed-off-by: Jordan Crouse
---
drivers/gpu/drm/msm/Makefile |3 +
drivers/gpu/drm/msm/adreno/a6xx_gmu.c | 1172
drivers/gpu/drm/msm/adreno/a6xx_gmu.h | 162 +++
drivers/gpu/drm/msm/adreno/a6xx_gpu.c | 807 ++
drivers/gpu/drm/msm/adreno/a6xx_gpu.h | 60 +
drivers/gpu/drm/msm/adreno/a6xx_hfi.c | 435
drivers/gpu/drm/msm/adreno/a6xx_hfi.h | 127 +++
drivers/gpu/drm/msm/adreno/adreno_device.c | 12 +
drivers/gpu/drm/msm/adreno/adreno_gpu.c|2 +-
drivers/gpu/drm/msm/adreno/adreno_gpu.h|4 +
drivers/gpu/drm/msm/msm_gpu.c |2 +-
11 files changed, 2784 insertions(+), 2 deletions(-)
create mode 100644 drivers/gpu/drm/msm/adreno/a6xx_gmu.c
create mode 100644 drivers/gpu/drm/msm/adreno/a6xx_gmu.h
create mode 100644 drivers/gpu/drm/msm/adreno/a6xx_gpu.c
create mode 100644 drivers/gpu/drm/msm/adreno/a6xx_gpu.h
create mode 100644 drivers/gpu/drm/msm/adreno/a6xx_hfi.c
create mode 100644 drivers/gpu/drm/msm/adreno/a6xx_hfi.h
diff --git a/drivers/gpu/drm/msm/Makefile b/drivers/gpu/drm/msm/Makefile
index cd40c050b2d7..4affc665c0de 100644
--- a/drivers/gpu/drm/msm/Makefile
+++ b/drivers/gpu/drm/msm/Makefile
@@ -10,6 +10,9 @@ msm-y := \
adreno/a5xx_gpu.o \
adreno/a5xx_power.o \
adreno/a5xx_preempt.o \
+ adreno/a6xx_gpu.o \
+ adreno/a6xx_gmu.o \
+ adreno/a6xx_hfi.o \
hdmi/hdmi.o \
hdmi/hdmi_audio.o \
hdmi/hdmi_bridge.o \
diff --git a/drivers/gpu/drm/msm/adreno/a6xx_gmu.c
b/drivers/gpu/drm/msm/adreno/a6xx_gmu.c
new file mode 100644
index ..9ecd7afe6321
--- /dev/null
+++ b/drivers/gpu/drm/msm/adreno/a6xx_gmu.c
@@ -0,0 +1,1172 @@
+// SPDX-License-Identifier: GPL-2.0
+/* Copyright (c) 2017-2018 The Linux Foundation. All rights reserved. */
+
+#include
+#include
+#include
+#include
+
+#include "a6xx_gpu.h"
+#include "a6xx_gmu.xml.h"
+
+static irqreturn_t a6xx_gmu_irq(int irq, void *data)
+{
+ struct a6xx_gmu *gmu = data;
+ u32 status;
+
+ status = gmu_read(gmu, REG_A6XX_GMU_AO_HOST_INTERRUPT_STATUS);
+ gmu_write(gmu, REG_A6XX_GMU_AO_HOST_INTERRUPT_CLR, status);
+
+ if (status & A6XX_GMU_AO_HOST_INTERRUPT_STATUS_WDOG_BITE) {
+ dev_err_ratelimited(gmu->dev, "GMU watchdog expired\n");
+
+ /* Temporary until we can recover safely */
+ BUG();
+ }
+
+ if (status & A6XX_GMU_AO_HOST_INTERRUPT_STATUS_HOST_AHB_BUS_ERROR)
+ dev_err_ratelimited(gmu->dev, "GMU AHB bus error\n");
+
+ if (status & A6XX_GMU_AO_HOST_INTERRUPT_STATUS_FENCE_ERR)
+ dev_err_ratelimited(gmu->dev, "GMU fence error: 0x%x\n",
+ gmu_read(gmu, REG_A6XX_GMU_AHB_FENCE_STATUS));
+
+ return IRQ_HANDLED;
+}
+
+static irqreturn_t a6xx_hfi_irq(int irq, void *data)
+{
+ struct a6xx_gmu *gmu = data;
+ u32 status;
+
+ status = gmu_read(gmu, REG_A6XX_GMU_GMU2HOST_INTR_INFO);
+ gmu_write(gmu, REG_A6XX_GMU_GMU2HOST_INTR_CLR, status);
+
+ if (status & A6XX_GMU_GMU2HOST_INTR_INFO_MSGQ)
+ tasklet_schedule(>hfi_tasklet);
+
+ if (status & A6XX_GMU_GMU2HOST_INTR_INFO_CM3_FAULT) {
+ dev_err_ratelimited(gmu->dev, "GMU firmware fault\n");
+
+ /* Temporary until we can recover safely */
+ BUG();
+ }
+
+ return IRQ_HANDLED;
+}
+
+/* Check to see if the GX rail is still powered */
+static bool a6xx_gmu_gx_is_on(struct a6xx_gmu *gmu)
+{
+ u32 val = gmu_read(gmu, REG_A6XX_GMU_SPTPRAC_PWR_CLK_STATUS);
+
+ return !(val &
+ (A6XX_GMU_SPTPRAC_PWR_CLK_STATUS_GX_HM_GDSC_POWER_OFF |
+ A6XX_GMU_SPTPRAC_PWR_CLK_STATUS_GX_HM_CLK_OFF));
+}
+
+static bool a6xx_gmu_check_idle_level(struct a6xx_gmu *gmu)
+{
+ u32 val;
+ int local = gmu->idle_level;
+
+ /* SPTP and IFPC both report as IFPC */
+ if (gmu->idle_level == GMU_IDLE_STATE_SPTP)
+ local = GMU_IDLE_STATE_IFPC;
+
+ val = gmu_read(gmu, REG_A6XX_GPU_GMU_CX_GMU_RPMH_POWER_STATE);
+
+ if (val == local) {
+ if (gmu->idle_level != GMU_IDLE_STATE_IFPC ||
+ !a6xx_gmu_gx_is_on(gmu))
+ return true;
+ }
+
+ return false;
+}
+
+/* Wait for the GMU to get to its most idle state */
+int a6xx_gmu_wait_for_idle(struct a6xx_gpu *a6xx_gpu)
+{
+ struct a6xx_gmu *gmu = _gpu->gmu;
+
+ return spin_until(a6xx_gmu_check_idle_level(gmu));
+}
+
+static int
[PATCH 2/5] drm/msm: Add a helper function to parse clock names
Add a helper function to parse the clock names and set up
the bulk data so we can take advantage of the bulk clock
functions instead of rolling our own. This is added
as a helper function so the upcoming a6xx GMU code can
also take advantage of it.
Signed-off-by: Jordan Crouse
---
drivers/gpu/drm/msm/msm_drv.c | 57 +
drivers/gpu/drm/msm/msm_drv.h | 4 +++
drivers/gpu/drm/msm/msm_gpu.c | 60 ++-
drivers/gpu/drm/msm/msm_gpu.h | 2 +-
4 files changed, 72 insertions(+), 51 deletions(-)
diff --git a/drivers/gpu/drm/msm/msm_drv.c b/drivers/gpu/drm/msm/msm_drv.c
index 7f7321eb5312..3e86fc9be39f 100644
--- a/drivers/gpu/drm/msm/msm_drv.c
+++ b/drivers/gpu/drm/msm/msm_drv.c
@@ -78,6 +78,63 @@ module_param(modeset, bool, 0600);
* Util/helpers:
*/
+int msm_clk_bulk_get(struct device *dev, struct clk_bulk_data **bulk)
+{
+ struct property *prop;
+ const char *name;
+ struct clk_bulk_data *local;
+ int i = 0, ret, count;
+
+ count = of_property_count_strings(dev->of_node, "clock-names");
+ if (count < 1)
+ return 0;
+
+ local = devm_kcalloc(dev, sizeof(struct clk_bulk_data *),
+ count, GFP_KERNEL);
+ if (!local)
+ return -ENOMEM;
+
+ of_property_for_each_string(dev->of_node, "clock-names", prop, name) {
+ local[i].id = devm_kstrdup(dev, name, GFP_KERNEL);
+ if (!local[i].id) {
+ devm_kfree(dev, local);
+ return -ENOMEM;
+ }
+
+ i++;
+ }
+
+ ret = devm_clk_bulk_get(dev, count, local);
+
+ if (ret) {
+ for (i = 0; i < count; i++)
+ devm_kfree(dev, (void *) local[i].id);
+ devm_kfree(dev, local);
+
+ return ret;
+ }
+
+ *bulk = local;
+ return count;
+}
+
+struct clk *msm_clk_bulk_get_clock(struct clk_bulk_data *bulk, int count,
+ const char *name)
+{
+ int i;
+ char n[32];
+
+ snprintf(n, sizeof(n), "%s_clk", name);
+
+ for (i = 0; bulk && i < count; i++) {
+ if (!strcmp(bulk[i].id, name) || !strcmp(bulk[i].id, n))
+ return bulk[i].clk;
+ }
+
+
+ return NULL;
+}
+
struct clk *msm_clk_get(struct platform_device *pdev, const char *name)
{
struct clk *clk;
diff --git a/drivers/gpu/drm/msm/msm_drv.h b/drivers/gpu/drm/msm/msm_drv.h
index 17cefca1d566..011c34ad1f93 100644
--- a/drivers/gpu/drm/msm/msm_drv.h
+++ b/drivers/gpu/drm/msm/msm_drv.h
@@ -307,6 +307,10 @@ static inline void msm_perf_debugfs_cleanup(struct
msm_drm_private *priv) {}
#endif
struct clk *msm_clk_get(struct platform_device *pdev, const char *name);
+int msm_clk_bulk_get(struct device *dev, struct clk_bulk_data **bulk);
+
+struct clk *msm_clk_bulk_get_clock(struct clk_bulk_data *bulk, int count,
+ const char *name);
void __iomem *msm_ioremap(struct platform_device *pdev, const char *name,
const char *dbgname);
void msm_writel(u32 data, void __iomem *addr);
diff --git a/drivers/gpu/drm/msm/msm_gpu.c b/drivers/gpu/drm/msm/msm_gpu.c
index 1c09acfb4028..d4d5a68e468d 100644
--- a/drivers/gpu/drm/msm/msm_gpu.c
+++ b/drivers/gpu/drm/msm/msm_gpu.c
@@ -141,8 +141,6 @@ static int disable_pwrrail(struct msm_gpu *gpu)
static int enable_clk(struct msm_gpu *gpu)
{
- int i;
-
if (gpu->core_clk && gpu->fast_rate)
clk_set_rate(gpu->core_clk, gpu->fast_rate);
@@ -150,28 +148,14 @@ static int enable_clk(struct msm_gpu *gpu)
if (gpu->rbbmtimer_clk)
clk_set_rate(gpu->rbbmtimer_clk, 1920);
- for (i = gpu->nr_clocks - 1; i >= 0; i--)
- if (gpu->grp_clks[i])
- clk_prepare(gpu->grp_clks[i]);
-
- for (i = gpu->nr_clocks - 1; i >= 0; i--)
- if (gpu->grp_clks[i])
- clk_enable(gpu->grp_clks[i]);
+ clk_bulk_prepare_enable(gpu->nr_clocks, gpu->grp_clks);
return 0;
}
static int disable_clk(struct msm_gpu *gpu)
{
- int i;
-
- for (i = gpu->nr_clocks - 1; i >= 0; i--)
- if (gpu->grp_clks[i])
- clk_disable(gpu->grp_clks[i]);
-
- for (i = gpu->nr_clocks - 1; i >= 0; i--)
- if (gpu->grp_clks[i])
- clk_unprepare(gpu->grp_clks[i]);
+ clk_bulk_disable_unprepare(gpu->nr_clocks, gpu->grp_clks);
/*
* Set the clock to a deliberately low rate. On older targets the clock
@@ -660,44 +644,20 @@ static irqreturn_t irq_handler(int irq, void *data)
return gpu->funcs->irq(gpu);
}
-static struct clk *get_clock(struct device *dev, const char *name)
-{
- struct clk *clk = devm_clk_get(dev, name);
-
- return IS_ERR(clk) ? NULL : clk;
-}
-
static int get_clocks(struct platform_device *pdev, struct msm_gpu *gpu)
{
-
[PATCH 4/5] drm/msm: Add generated headers for A6XX
From: Sharat Masetty
Add initial register headers for A6XX targets.
Signed-off-by: Sharat Masetty
Signed-off-by: Jordan Crouse
---
drivers/gpu/drm/msm/adreno/a6xx.xml.h | 1784 +
drivers/gpu/drm/msm/adreno/a6xx_gmu.xml.h | 382 +
2 files changed, 2166 insertions(+)
create mode 100644 drivers/gpu/drm/msm/adreno/a6xx.xml.h
create mode 100644 drivers/gpu/drm/msm/adreno/a6xx_gmu.xml.h
diff --git a/drivers/gpu/drm/msm/adreno/a6xx.xml.h
b/drivers/gpu/drm/msm/adreno/a6xx.xml.h
new file mode 100644
index ..5af12fe3f95c
--- /dev/null
+++ b/drivers/gpu/drm/msm/adreno/a6xx.xml.h
@@ -0,0 +1,1784 @@
+#ifndef A6XX_XML
+#define A6XX_XML
+
+/* Autogenerated file, DO NOT EDIT manually!
+
+This file was generated by the rules-ng-ng headergen tool in this git
repository:
+http://github.com/freedreno/envytools/
+git clone https://github.com/freedreno/envytools.git
+
+The rules-ng-ng source files this header was generated from are:
+- ./adreno.xml (501 bytes, from 2018-05-23 16:51:57)
+- ./freedreno_copyright.xml ( 1572 bytes, from 2016-10-24 21:12:27)
+- ./adreno/a2xx.xml ( 36805 bytes, from 2018-05-23 16:51:57)
+- ./adreno/adreno_common.xml ( 13634 bytes, from 2018-05-23 16:51:57)
+- ./adreno/adreno_pm4.xml( 38703 bytes, from 2018-05-23 16:51:57)
+- ./adreno/a3xx.xml ( 83840 bytes, from 2017-12-05 18:20:27)
+- ./adreno/a4xx.xml ( 112086 bytes, from 2018-05-23 16:51:57)
+- ./adreno/a5xx.xml ( 146494 bytes, from 2018-05-23 16:51:57)
+- ./adreno/a6xx.xml ( 69957 bytes, from 2018-05-23 17:09:08)
+- ./adreno/a6xx_gmu.xml ( 10431 bytes, from 2018-05-23 16:52:19)
+- ./adreno/ocmem.xml ( 1773 bytes, from 2016-10-24 21:12:27)
+
+Copyright (C) 2013-2018 by the following authors:
+- Rob Clark (robclark)
+- Ilia Mirkin (imirkin)
+
+Permission is hereby granted, free of charge, to any person obtaining
+a copy of this software and associated documentation files (the
+"Software"), to deal in the Software without restriction, including
+without limitation the rights to use, copy, modify, merge, publish,
+distribute, sublicense, and/or sell copies of the Software, and to
+permit persons to whom the Software is furnished to do so, subject to
+the following conditions:
+
+The above copyright notice and this permission notice (including the
+next paragraph) shall be included in all copies or substantial
+portions of the Software.
+
+THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
+EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF
+MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.
+IN NO EVENT SHALL THE COPYRIGHT OWNER(S) AND/OR ITS SUPPLIERS BE
+LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION
+OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION
+WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.
+*/
+
+
+enum a6xx_cp_perfcounter_select {
+ PERF_CP_ALWAYS_COUNT = 0,
+};
+
+enum a6xx_event_write {
+ PC_CCU_INVALIDATE_DEPTH = 24,
+ PC_CCU_INVALIDATE_COLOR = 25,
+};
+
+#define A6XX_RBBM_INT_0_MASK_RBBM_GPU_IDLE 0x0001
+#define A6XX_RBBM_INT_0_MASK_CP_AHB_ERROR 0x0002
+#define A6XX_RBBM_INT_0_MASK_RBBM_ATB_ASYNCFIFO_OVERFLOW 0x0040
+#define A6XX_RBBM_INT_0_MASK_RBBM_GPC_ERROR0x0080
+#define A6XX_RBBM_INT_0_MASK_CP_SW 0x0100
+#define A6XX_RBBM_INT_0_MASK_CP_HW_ERROR 0x0200
+#define A6XX_RBBM_INT_0_MASK_CP_CCU_FLUSH_DEPTH_TS 0x0400
+#define A6XX_RBBM_INT_0_MASK_CP_CCU_FLUSH_COLOR_TS 0x0800
+#define A6XX_RBBM_INT_0_MASK_CP_CCU_RESOLVE_TS 0x1000
+#define A6XX_RBBM_INT_0_MASK_CP_IB20x2000
+#define A6XX_RBBM_INT_0_MASK_CP_IB10x4000
+#define A6XX_RBBM_INT_0_MASK_CP_RB 0x8000
+#define A6XX_RBBM_INT_0_MASK_CP_RB_DONE_TS 0x0002
+#define A6XX_RBBM_INT_0_MASK_CP_WT_DONE_TS 0x0004
+#define A6XX_RBBM_INT_0_MASK_CP_CACHE_FLUSH_TS 0x0010
+#define A6XX_RBBM_INT_0_MASK_RBBM_ATB_BUS_OVERFLOW 0x0040
+#define A6XX_RBBM_INT_0_MASK_RBBM_HANG_DETECT 0x0080
+#define A6XX_RBBM_INT_0_MASK_UCHE_OOB_ACCESS 0x0100
+#define A6XX_RBBM_INT_0_MASK_UCHE_TRAP_INTR0x0200
+#define A6XX_RBBM_INT_0_MASK_DEBBUS_INTR_0 0x0400
+#define A6XX_RBBM_INT_0_MASK_DEBBUS_INTR_1 0x0800
+#define A6XX_RBBM_INT_0_MASK_ISDB_CPU_IRQ 0x4000
+#define A6XX_RBBM_INT_0_MASK_ISDB_UNDER_DEBUG 0x8000
+#define A6XX_CP_INT_CP_OPCODE_ERROR0x0001
+#define A6XX_CP_INT_CP_UCODE_ERROR
[PATCH 1/5] drm/msm: Remove pm_runtime operations from msm_iommu
Now that the IOMMU is the master of it's own power we don't need to bring
up the GPU to do IOMMU operations. This is good because bringing up a6xx
requires the GMU so calling pm_runtime_get_sync() too early in the process
gets us into some nasty circular dependency situations.
Signed-off-by: Jordan Crouse
---
drivers/gpu/drm/msm/msm_iommu.c | 8
1 file changed, 8 deletions(-)
diff --git a/drivers/gpu/drm/msm/msm_iommu.c b/drivers/gpu/drm/msm/msm_iommu.c
index b23d33622f37..ccd93ac6a4d8 100644
--- a/drivers/gpu/drm/msm/msm_iommu.c
+++ b/drivers/gpu/drm/msm/msm_iommu.c
@@ -40,9 +40,7 @@ static int msm_iommu_attach(struct msm_mmu *mmu, const char *
const *names,
struct msm_iommu *iommu = to_msm_iommu(mmu);
int ret;
- pm_runtime_get_sync(mmu->dev);
ret = iommu_attach_device(iommu->domain, mmu->dev);
- pm_runtime_put_sync(mmu->dev);
return ret;
}
@@ -52,9 +50,7 @@ static void msm_iommu_detach(struct msm_mmu *mmu, const char
* const *names,
{
struct msm_iommu *iommu = to_msm_iommu(mmu);
- pm_runtime_get_sync(mmu->dev);
iommu_detach_device(iommu->domain, mmu->dev);
- pm_runtime_put_sync(mmu->dev);
}
static int msm_iommu_map(struct msm_mmu *mmu, uint64_t iova,
@@ -63,9 +59,7 @@ static int msm_iommu_map(struct msm_mmu *mmu, uint64_t iova,
struct msm_iommu *iommu = to_msm_iommu(mmu);
size_t ret;
-// pm_runtime_get_sync(mmu->dev);
ret = iommu_map_sg(iommu->domain, iova, sgt->sgl, sgt->nents, prot);
-// pm_runtime_put_sync(mmu->dev);
WARN_ON(ret < 0);
return (ret == len) ? 0 : -EINVAL;
@@ -76,9 +70,7 @@ static int msm_iommu_unmap(struct msm_mmu *mmu, uint64_t iova,
{
struct msm_iommu *iommu = to_msm_iommu(mmu);
- pm_runtime_get_sync(mmu->dev);
iommu_unmap(iommu->domain, iova, len);
- pm_runtime_put_sync(mmu->dev);
return 0;
}
--
2.17.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: Kernel and ADM hardware roulette ( was AMD graphics performance regression in 4.15 and later )
On Mon, Jun 11, 2018 at 12:07 AM Christoph Hellwig wrote: > > For now I'd say revert this commit for 4.17/4.18-rc and I'll look into > addressing these issues properly. Ok, reverted in my tree, and marked for stable (for 4.17). Thanks, Linus ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 1/3] drm/atomic: Improve debug messages
From: Ville Syrjälä
Print the id/name of the object we're dealing with. Makes it easier to
figure out what's going on. Also toss in a few extra debug prints that
might be useful.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/drm_atomic.c | 88 ++--
1 file changed, 61 insertions(+), 27 deletions(-)
diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
index ee4b43b9404e..d7de83a6c1c2 100644
--- a/drivers/gpu/drm/drm_atomic.c
+++ b/drivers/gpu/drm/drm_atomic.c
@@ -339,6 +339,7 @@ static s32 __user *get_out_fence_for_crtc(struct
drm_atomic_state *state,
int drm_atomic_set_mode_for_crtc(struct drm_crtc_state *state,
const struct drm_display_mode *mode)
{
+ struct drm_crtc *crtc = state->crtc;
struct drm_mode_modeinfo umode;
/* Early return for no change. */
@@ -359,13 +360,13 @@ int drm_atomic_set_mode_for_crtc(struct drm_crtc_state
*state,
drm_mode_copy(>mode, mode);
state->enable = true;
- DRM_DEBUG_ATOMIC("Set [MODE:%s] for CRTC state %p\n",
-mode->name, state);
+ DRM_DEBUG_ATOMIC("Set [MODE:%s] for [CRTC:%d:%s] state %p\n",
+mode->name, crtc->base.id, crtc->name, state);
} else {
memset(>mode, 0, sizeof(state->mode));
state->enable = false;
- DRM_DEBUG_ATOMIC("Set [NOMODE] for CRTC state %p\n",
-state);
+ DRM_DEBUG_ATOMIC("Set [NOMODE] for [CRTC:%d:%s] state %p\n",
+crtc->base.id, crtc->name, state);
}
return 0;
@@ -388,6 +389,8 @@ EXPORT_SYMBOL(drm_atomic_set_mode_for_crtc);
int drm_atomic_set_mode_prop_for_crtc(struct drm_crtc_state *state,
struct drm_property_blob *blob)
{
+ struct drm_crtc *crtc = state->crtc;
+
if (blob == state->mode_blob)
return 0;
@@ -404,12 +407,13 @@ int drm_atomic_set_mode_prop_for_crtc(struct
drm_crtc_state *state,
state->mode_blob = drm_property_blob_get(blob);
state->enable = true;
- DRM_DEBUG_ATOMIC("Set [MODE:%s] for CRTC state %p\n",
-state->mode.name, state);
+ DRM_DEBUG_ATOMIC("Set [MODE:%s] for [CRTC:%d:%s] state %p\n",
+state->mode.name, crtc->base.id, crtc->name,
+state);
} else {
state->enable = false;
- DRM_DEBUG_ATOMIC("Set [NOMODE] for CRTC state %p\n",
-state);
+ DRM_DEBUG_ATOMIC("Set [NOMODE] for [CRTC:%d:%s] state %p\n",
+crtc->base.id, crtc->name, state);
}
return 0;
@@ -539,10 +543,14 @@ int drm_atomic_crtc_set_property(struct drm_crtc *crtc,
return -EFAULT;
set_out_fence_for_crtc(state->state, crtc, fence_ptr);
- } else if (crtc->funcs->atomic_set_property)
+ } else if (crtc->funcs->atomic_set_property) {
return crtc->funcs->atomic_set_property(crtc, state, property,
val);
- else
+ } else {
+ DRM_DEBUG_ATOMIC("[CRTC:%d:%s] unknown property
[PROP:%d:%s]]\n",
+crtc->base.id, crtc->name,
+property->base.id, property->name);
return -EINVAL;
+ }
return 0;
}
@@ -799,8 +807,11 @@ static int drm_atomic_plane_set_property(struct drm_plane
*plane,
} else if (property == plane->alpha_property) {
state->alpha = val;
} else if (property == plane->rotation_property) {
- if (!is_power_of_2(val & DRM_MODE_ROTATE_MASK))
+ if (!is_power_of_2(val & DRM_MODE_ROTATE_MASK)) {
+ DRM_DEBUG_ATOMIC("[PLANE:%d:%s] bad rotation bitmask:
0x%llx\n",
+plane->base.id, plane->name, val);
return -EINVAL;
+ }
state->rotation = val;
} else if (property == plane->zpos_property) {
state->zpos = val;
@@ -812,6 +823,9 @@ static int drm_atomic_plane_set_property(struct drm_plane
*plane,
return plane->funcs->atomic_set_property(plane, state,
property, val);
} else {
+ DRM_DEBUG_ATOMIC("[PLANE:%d:%s] unknown property
[PROP:%d:%s]]\n",
+plane->base.id, plane->name,
+property->base.id, property->name);
return -EINVAL;
}
@@ -919,10 +933,12 @@ static int drm_atomic_plane_check(struct drm_plane *plane,
/* either *both* CRTC and FB must be set, or neither */
if (state->crtc &&
[PATCH 3/3] drm/i915: Print prop name/id when rejecting it
From: Ville Syrjälä
Use the '[PROP:id:name]' format I introduced for the core in the driver
debug messages as well.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/intel_atomic.c | 6 --
drivers/gpu/drm/i915/intel_atomic_plane.c | 6 --
2 files changed, 8 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_atomic.c
b/drivers/gpu/drm/i915/intel_atomic.c
index 61ddb5871d8a..b04952bacf77 100644
--- a/drivers/gpu/drm/i915/intel_atomic.c
+++ b/drivers/gpu/drm/i915/intel_atomic.c
@@ -59,7 +59,8 @@ int intel_digital_connector_atomic_get_property(struct
drm_connector *connector,
else if (property == dev_priv->broadcast_rgb_property)
*val = intel_conn_state->broadcast_rgb;
else {
- DRM_DEBUG_ATOMIC("Unknown property %s\n", property->name);
+ DRM_DEBUG_ATOMIC("Unknown property [PROP:%d:%s]\n",
+property->base.id, property->name);
return -EINVAL;
}
@@ -95,7 +96,8 @@ int intel_digital_connector_atomic_set_property(struct
drm_connector *connector,
return 0;
}
- DRM_DEBUG_ATOMIC("Unknown property %s\n", property->name);
+ DRM_DEBUG_ATOMIC("Unknown property [PROP:%d:%s]\n",
+property->base.id, property->name);
return -EINVAL;
}
diff --git a/drivers/gpu/drm/i915/intel_atomic_plane.c
b/drivers/gpu/drm/i915/intel_atomic_plane.c
index e8bf4cc499e1..dcba645cabb8 100644
--- a/drivers/gpu/drm/i915/intel_atomic_plane.c
+++ b/drivers/gpu/drm/i915/intel_atomic_plane.c
@@ -265,7 +265,8 @@ intel_plane_atomic_get_property(struct drm_plane *plane,
struct drm_property *property,
uint64_t *val)
{
- DRM_DEBUG_KMS("Unknown plane property '%s'\n", property->name);
+ DRM_DEBUG_KMS("Unknown property [PROP:%d:%s]\n",
+ property->base.id, property->name);
return -EINVAL;
}
@@ -287,6 +288,7 @@ intel_plane_atomic_set_property(struct drm_plane *plane,
struct drm_property *property,
uint64_t val)
{
- DRM_DEBUG_KMS("Unknown plane property '%s'\n", property->name);
+ DRM_DEBUG_KMS("Unknown property [PROP:%d:%s]\n",
+ property->base.id, property->name);
return -EINVAL;
}
--
2.16.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 2/3] drm: Print bad user modes
From: Ville Syrjälä
Print out the modeline when we reject a bad user mode. Avoids having to
guess why it was rejected.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/drm_atomic.c| 20 +---
drivers/gpu/drm/drm_crtc.c | 4 +++-
drivers/gpu/drm/drm_crtc_internal.h | 3 +++
drivers/gpu/drm/drm_modes.c | 2 +-
4 files changed, 24 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
index d7de83a6c1c2..5fe5e06062a9 100644
--- a/drivers/gpu/drm/drm_atomic.c
+++ b/drivers/gpu/drm/drm_atomic.c
@@ -400,10 +400,24 @@ int drm_atomic_set_mode_prop_for_crtc(struct
drm_crtc_state *state,
memset(>mode, 0, sizeof(state->mode));
if (blob) {
- if (blob->length != sizeof(struct drm_mode_modeinfo) ||
- drm_mode_convert_umode(state->crtc->dev, >mode,
- blob->data))
+ int ret;
+
+ if (blob->length != sizeof(struct drm_mode_modeinfo)) {
+ DRM_DEBUG_ATOMIC("[CRTC:%d:%s] bad mode blob length:
%zu\n",
+crtc->base.id, crtc->name,
+blob->length);
+ return -EINVAL;
+ }
+
+ ret = drm_mode_convert_umode(crtc->dev,
+>mode, blob->data);
+ if (ret) {
+ DRM_DEBUG_ATOMIC("[CRTC:%d:%s] invalid mode (ret=%d,
status=%s):\n",
+crtc->base.id, crtc->name,
+ret,
drm_get_mode_status_name(state->mode.status));
+ drm_mode_debug_printmodeline(>mode);
return -EINVAL;
+ }
state->mode_blob = drm_property_blob_get(blob);
state->enable = true;
diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
index 53828fc8d911..163d82ac7d76 100644
--- a/drivers/gpu/drm/drm_crtc.c
+++ b/drivers/gpu/drm/drm_crtc.c
@@ -649,7 +649,9 @@ int drm_mode_setcrtc(struct drm_device *dev, void *data,
ret = drm_mode_convert_umode(dev, mode, _req->mode);
if (ret) {
- DRM_DEBUG_KMS("Invalid mode\n");
+ DRM_DEBUG_KMS("Invalid mode (ret=%d, status=%s)\n",
+ ret,
drm_get_mode_status_name(mode->status));
+ drm_mode_debug_printmodeline(mode);
goto out;
}
diff --git a/drivers/gpu/drm/drm_crtc_internal.h
b/drivers/gpu/drm/drm_crtc_internal.h
index 5d307b23a4e6..34499800932a 100644
--- a/drivers/gpu/drm/drm_crtc_internal.h
+++ b/drivers/gpu/drm/drm_crtc_internal.h
@@ -56,6 +56,9 @@ int drm_mode_setcrtc(struct drm_device *dev,
int drm_modeset_register_all(struct drm_device *dev);
void drm_modeset_unregister_all(struct drm_device *dev);
+/* drm_modes.c */
+const char *drm_get_mode_status_name(enum drm_mode_status status);
+
/* IOCTLs */
int drm_mode_getresources(struct drm_device *dev,
void *data, struct drm_file *file_priv);
diff --git a/drivers/gpu/drm/drm_modes.c b/drivers/gpu/drm/drm_modes.c
index c78ca0e84ffd..7f552d5fa88e 100644
--- a/drivers/gpu/drm/drm_modes.c
+++ b/drivers/gpu/drm/drm_modes.c
@@ -1257,7 +1257,7 @@ static const char * const drm_mode_status_names[] = {
#undef MODE_STATUS
-static const char *drm_get_mode_status_name(enum drm_mode_status status)
+const char *drm_get_mode_status_name(enum drm_mode_status status)
{
int index = status + 3;
--
2.16.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 44/60] drm/omap: dss: Add for_each_dss_output() macro
Hi,
On Mon, Jun 11, 2018 at 08:11:09PM +0300, Laurent Pinchart wrote:
> Hi Sebastian,
>
> On Monday, 11 June 2018 02:52:44 EEST Sebastian Reichel wrote:
> > On Sat, May 26, 2018 at 08:25:02PM +0300, Laurent Pinchart wrote:
> > > Similarly to for_each_dss_display(), the for_each_dss_output() macro
> > > iterates over all the DSS connected outputs.
> > >
> > > Signed-off-by: Laurent Pinchart
> > > ---
> > >
> > > drivers/gpu/drm/omapdrm/dss/base.c| 20 ++--
> > > drivers/gpu/drm/omapdrm/dss/omapdss.h | 9 ++---
> > > 2 files changed, 20 insertions(+), 9 deletions(-)
> > >
> > > diff --git a/drivers/gpu/drm/omapdrm/dss/base.c
> > > b/drivers/gpu/drm/omapdrm/dss/base.c index 96be800a0f25..519682f18d36
> > > 100644
> > > --- a/drivers/gpu/drm/omapdrm/dss/base.c
> > > +++ b/drivers/gpu/drm/omapdrm/dss/base.c
> > > @@ -127,11 +127,13 @@ struct omap_dss_device
> > > *omapdss_find_device_by_port(struct device_node *src,>
> > > /*
> > >
> > > * Search for the next device starting at @from. If display_only is true,
> > > skip>
> > > - * non-display devices. Release the reference to the @from device, and
> > > acquire - * a reference to the returned device if found.
> > > + * non-display devices. If output_only is true, skip non-output devices
> > > and + * non-connected output devices. Release the reference to the @from
> > > device, and + * acquire a reference to the returned device if found.
> > >
> > > */
> > >
> > > struct omap_dss_device *omapdss_device_get_next(struct omap_dss_device
> > > *from,>
> > > - bool display_only)
> > > + bool display_only,
> > > + bool output_only)
> >
> > display_only and output_only are mutually exclusive, so I think it
> > would be better to use this as parameter. It would also improve
> > code readability a bit:
> >
> > enum omapdss_device_type {
> > OMAPDSS_DEVICE_TYPE_ALL,
> > OMAPDSS_DEVICE_TYPE_OUTPUT_ONLY,
> > OMAPDSS_DEVICE_TYPE_DISPLAY_ONLY,
> > };
>
> That's a good point, even if all this code is meant to disappear.
> What would you think of
>
> enum omap_dss_device_type {
> OMAP_DSS_DEVICE_TYPE_OUTPUT = (1 << 0),
> OMAP_DSS_DEVICE_TYPE_DISPLAY = (1 << 1),
> };
>
> and combining the flags when passed to omapdss_device_get_next() ?
Sounds good to me.
-- Sebastian
signature.asc
Description: PGP signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[DPU PATCH v3 1/7] drm/msm: remove connector custom properties
Cleanup residual connector property enumerations.
changes in v2:
- none
changes in v3:
- rebased on https://gitlab.freedesktop.org/seanpaul/
dpu-staging/commit/481d29d31cd629fd216381b53de5695f645465d5
Signed-off-by: Jeykumar Sankaran
Reviewed-by: Sean Paul
---
drivers/gpu/drm/msm/msm_drv.h | 27 ---
1 file changed, 27 deletions(-)
diff --git a/drivers/gpu/drm/msm/msm_drv.h b/drivers/gpu/drm/msm/msm_drv.h
index 52a026d..b73112a 100644
--- a/drivers/gpu/drm/msm/msm_drv.h
+++ b/drivers/gpu/drm/msm/msm_drv.h
@@ -137,32 +137,6 @@ enum msm_mdp_crtc_property {
CRTC_PROP_COUNT
};
-enum msm_mdp_conn_property {
- /* blob properties, always put these first */
- CONNECTOR_PROP_DPU_INFO,
- CONNECTOR_PROP_HDR_INFO,
- CONNECTOR_PROP_PP_DITHER,
-
- /* # of blob properties */
- CONNECTOR_PROP_BLOBCOUNT,
-
- /* range properties */
- CONNECTOR_PROP_OUT_FB = CONNECTOR_PROP_BLOBCOUNT,
- CONNECTOR_PROP_DST_X,
- CONNECTOR_PROP_DST_Y,
- CONNECTOR_PROP_DST_W,
- CONNECTOR_PROP_DST_H,
- CONNECTOR_PROP_BL_SCALE,
- CONNECTOR_PROP_AD_BL_SCALE,
-
- /* enum/bitmask properties */
- CONNECTOR_PROP_AUTOREFRESH,
- CONNECTOR_PROP_LP,
-
- /* total # of properties */
- CONNECTOR_PROP_COUNT
-};
-
struct msm_vblank_ctrl {
struct kthread_work work;
struct list_head event_list;
@@ -428,7 +402,6 @@ struct msm_drm_private {
/* Properties */
struct drm_property *plane_property[PLANE_PROP_COUNT];
struct drm_property *crtc_property[CRTC_PROP_COUNT];
- struct drm_property *conn_property[CONNECTOR_PROP_COUNT];
/* Color processing properties for the crtc */
struct drm_property **cp_property;
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[DPU PATCH v3 7/7] drm/msm: remove dpu specific uapi header
remove unwanted dpu uapi headers exposing custom payload layouts for custom properties changs in v2: - none changes in v3: - rebased on https://gitlab.freedesktop.org/seanpaul/ dpu-staging/commit/481d29d31cd629fd216381b53de5695f645465d5 Signed-off-by: Jeykumar Sankaran Reviewed-by: Sean Paul --- drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.h | 1 - drivers/gpu/drm/msm/disp/dpu1/dpu_hw_lm.c | 1 - include/uapi/drm/dpu_drm.h| 220 --- include/uapi/drm/msm_drm_pp.h | 345 -- 4 files changed, 567 deletions(-) delete mode 100644 include/uapi/drm/dpu_drm.h delete mode 100644 include/uapi/drm/msm_drm_pp.h diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.h b/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.h index cc23b33..39def93 100644 --- a/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.h +++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.h @@ -20,7 +20,6 @@ #define _DPU_CRTC_H_ #include -#include #include #include "dpu_kms.h" #include "dpu_core_perf.h" diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_lm.c b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_lm.c index 830b69e..5b4d529 100644 --- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_lm.c +++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_lm.c @@ -10,7 +10,6 @@ * GNU General Public License for more details. */ -#include #include "dpu_kms.h" #include "dpu_hw_catalog.h" #include "dpu_hwio.h" diff --git a/include/uapi/drm/dpu_drm.h b/include/uapi/drm/dpu_drm.h deleted file mode 100644 index 93af1fb..000 --- a/include/uapi/drm/dpu_drm.h +++ /dev/null @@ -1,220 +0,0 @@ -#ifndef _DPU_DRM_H_ -#define _DPU_DRM_H_ - -#include "drm.h" - -/* Total number of supported color planes */ -#define DPU_MAX_PLANES 4 - -/* Total number of parameterized detail enhancer mapping curves */ -#define DPU_MAX_DE_CURVES 3 - - /* Y/RGB and UV filter configuration */ -#define FILTER_EDGE_DIRECTED_2D0x0 -#define FILTER_CIRCULAR_2D 0x1 -#define FILTER_SEPARABLE_1D0x2 -#define FILTER_BILINEAR0x3 - -/* Alpha filters */ -#define FILTER_ALPHA_DROP_REPEAT 0x0 -#define FILTER_ALPHA_BILINEAR 0x1 -#define FILTER_ALPHA_2D0x3 - -/* Blend filters */ -#define FILTER_BLEND_CIRCULAR_2D 0x0 -#define FILTER_BLEND_SEPARABLE_1D 0x1 - -/* LUT configuration flags */ -#define SCALER_LUT_SWAP0x1 -#define SCALER_LUT_DIR_WR 0x2 -#define SCALER_LUT_Y_CIR_WR0x4 -#define SCALER_LUT_UV_CIR_WR 0x8 -#define SCALER_LUT_Y_SEP_WR0x10 -#define SCALER_LUT_UV_SEP_WR 0x20 - -/** - * Blend operations for "blend_op" property - * - * @DPU_DRM_BLEND_OP_NOT_DEFINED: No blend operation defined for the layer. - * @DPU_DRM_BLEND_OP_OPAQUE:Apply a constant blend operation. The layer - * would appear opaque in case fg plane alpha - * is 0xff. - * @DPU_DRM_BLEND_OP_PREMULTIPLIED: Apply source over blend rule. Layer already - * has alpha pre-multiplication done. If the fg - * plane alpha is less than 0xff, apply - * modulation as well. This operation is - * intended on layers having alpha channel. - * @DPU_DRM_BLEND_OP_COVERAGE: Apply source over blend rule. Layer is not - * alpha pre-multiplied. Apply - * pre-multiplication. If fg plane alpha is - * less than 0xff, apply modulation as well. - * @DPU_DRM_BLEND_OP_MAX: Used to track maximum blend operation - * possible by mdp. - */ -#define DPU_DRM_BLEND_OP_NOT_DEFINED0 -#define DPU_DRM_BLEND_OP_OPAQUE 1 -#define DPU_DRM_BLEND_OP_PREMULTIPLIED 2 -#define DPU_DRM_BLEND_OP_COVERAGE 3 -#define DPU_DRM_BLEND_OP_MAX4 - -/** - * Bit masks for "src_config" property - * construct bitmask via (1UL << DPU_DRM_) - */ -#define DPU_DRM_DEINTERLACE 0 /* Specifies interlaced input */ - -/* DRM bitmasks are restricted to 0..63 */ -#define DPU_DRM_BITMASK_COUNT 64 - -/* Number of dest scalers supported */ -#define DPU_MAX_DS_COUNT 2 - -/* - * Destination scaler flag config - */ -#define DPU_DRM_DESTSCALER_ENABLE 0x1 -#define DPU_DRM_DESTSCALER_SCALE_UPDATE 0x2 -#define DPU_DRM_DESTSCALER_ENHANCER_UPDATE 0x4 -#define DPU_DRM_DESTSCALER_PU_ENABLE0x8 - -/** - * struct dpu_drm_dest_scaler_cfg - destination scaler config structure - * @flags: Flag to switch between mode for destination scaler - * refer to destination scaler flag config - * @index: Destination scaler selection index - * @lm_width: Layer mixer width configuration - * @lm_height: Layer mixer height configuration - * @scaler_cfg: The
[DPU PATCH v3 3/7] drm/msm: enable zpos normalization
Enable drm core zpos normalization for planes.
changes in v2:
- none
changes in v3:
- rebased on https://gitlab.freedesktop.org/seanpaul/
dpu-staging/commit/481d29d31cd629fd216381b53de5695f645465d5
Signed-off-by: Jeykumar Sankaran
Reviewed-by: Sean Paul
---
drivers/gpu/drm/msm/msm_drv.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/gpu/drm/msm/msm_drv.c b/drivers/gpu/drm/msm/msm_drv.c
index acfda2a..ffea915 100644
--- a/drivers/gpu/drm/msm/msm_drv.c
+++ b/drivers/gpu/drm/msm/msm_drv.c
@@ -567,6 +567,9 @@ static int msm_drm_init(struct device *dev, struct
drm_driver *drv)
ddev->mode_config.funcs = _config_funcs;
ddev->mode_config.helper_private = _config_helper_funcs;
+ /* Enable normalization of plane zpos */
+ ddev->mode_config.normalize_zpos = true;
+
if (kms) {
ret = kms->funcs->hw_init(kms);
if (ret) {
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[DPU PATCH v3 4/7] drm/msm/dpu: switch to drm zpos property
Replace custom plane zpos property with drm core zpos
property. CRTC relies on the normalized zpos values
to configure blend stages of each plane.
changes in v2:
- Move out unrelated changes in plane init (Sean Paul)
changes in v3:
- rebased on https://gitlab.freedesktop.org/seanpaul/
dpu-staging/commit/481d29d31cd629fd216381b53de5695f645465d5
Signed-off-by: Jeykumar Sankaran
---
drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c | 36 +--
drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c | 16 +++---
2 files changed, 14 insertions(+), 38 deletions(-)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
index 7cf5a7a..a7d9aff 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
@@ -2583,24 +2583,6 @@ struct plane_state {
u32 pipe_id;
};
-static int pstate_cmp(const void *a, const void *b)
-{
- struct plane_state *pa = (struct plane_state *)a;
- struct plane_state *pb = (struct plane_state *)b;
- int rc = 0;
- int pa_zpos, pb_zpos;
-
- pa_zpos = dpu_plane_get_property(pa->dpu_pstate, PLANE_PROP_ZPOS);
- pb_zpos = dpu_plane_get_property(pb->dpu_pstate, PLANE_PROP_ZPOS);
-
- if (pa_zpos != pb_zpos)
- rc = pa_zpos - pb_zpos;
- else
- rc = pa->drm_pstate->crtc_x - pb->drm_pstate->crtc_x;
-
- return rc;
-}
-
static int dpu_crtc_atomic_check(struct drm_crtc *crtc,
struct drm_crtc_state *state)
{
@@ -2666,8 +2648,7 @@ static int dpu_crtc_atomic_check(struct drm_crtc *crtc,
pstates[cnt].dpu_pstate = to_dpu_plane_state(pstate);
pstates[cnt].drm_pstate = pstate;
- pstates[cnt].stage = dpu_plane_get_property(
- pstates[cnt].dpu_pstate, PLANE_PROP_ZPOS);
+ pstates[cnt].stage = pstate->normalized_zpos;
pstates[cnt].pipe_id = dpu_plane_pipe(plane);
/* check dim layer stage with every plane */
@@ -2723,21 +2704,6 @@ static int dpu_crtc_atomic_check(struct drm_crtc *crtc,
}
}
- /* assign mixer stages based on sorted zpos property */
- sort(pstates, cnt, sizeof(pstates[0]), pstate_cmp, NULL);
-
- if (!dpu_is_custom_client()) {
- int stage_old = pstates[0].stage;
-
- z_pos = 0;
- for (i = 0; i < cnt; i++) {
- if (stage_old != pstates[i].stage)
- ++z_pos;
- stage_old = pstates[i].stage;
- pstates[i].stage = z_pos;
- }
- }
-
z_pos = -1;
for (i = 0; i < cnt; i++) {
/* reset counts at every new blend stage */
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c
index e81cb1f..c6be158 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c
@@ -59,6 +59,7 @@
#define DPU_NAME_SIZE 12
#define DPU_PLANE_COLOR_FILL_FLAG BIT(31)
+#define DPU_ZPOS_MAX 255
/* multirect rect index */
enum {
@@ -1516,9 +1517,6 @@ static void _dpu_plane_install_properties(struct
drm_plane *plane,
/* reserve zpos == 0 for primary planes */
zpos_def = drm_plane_index(plane) + 1;
}
-
- msm_property_install_range(>property_info, "zpos",
- 0x0, 0, zpos_max, zpos_def, PLANE_PROP_ZPOS);
}
static int dpu_plane_atomic_set_property(struct drm_plane *plane,
@@ -1956,6 +1954,7 @@ struct drm_plane *dpu_plane_init(struct drm_device *dev,
struct msm_drm_private *priv;
struct dpu_kms *kms;
enum drm_plane_type type;
+ int zpos_max = DPU_ZPOS_MAX;
int ret = -EINVAL;
if (!dev) {
@@ -2049,6 +2048,17 @@ struct drm_plane *dpu_plane_init(struct drm_device *dev,
pdpu->catalog = kms->catalog;
+ if (kms->catalog->mixer_count &&
+ kms->catalog->mixer[0].sblk->maxblendstages) {
+ zpos_max = kms->catalog->mixer[0].sblk->maxblendstages - 1;
+ if (zpos_max > DPU_STAGE_MAX - DPU_STAGE_0 - 1)
+ zpos_max = DPU_STAGE_MAX - DPU_STAGE_0 - 1;
+ }
+
+ ret = drm_plane_create_zpos_property(plane, 0, 0, zpos_max);
+ if (ret)
+ DPU_ERROR("failed to install zpos property, rc = %d\n", ret);
+
/* success! finalize initialization */
drm_plane_helper_add(plane, _plane_helper_funcs);
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[DPU PATCH v3 0/7] clean up DPU custom properties
Submitting a series of patches to further clean up DPU driver by stripping down a list of custom properties supporting proprietary features. It removes the property installers/handlers and cleans up relevant files of of some of the advanced features. This series is based on the patch[1] available on the drm-next tip. [1]https://patchwork.kernel.org/patch/10202847/ Thanks. changes in v2: - remove stale code in blend config - move unrelated code while updating zpos property - Makefile changes changes in v3: - rebase on https://gitlab.freedesktop.org/seanpaul/ dpu-staging/commit/481d29d31cd629fd216381b53de5695f645465d5 Thanks. Jeykumar Sankaran (7): drm/msm: remove connector custom properties drm/msm/dpu: clean up dpu plane custom properties drm/msm: enable zpos normalization drm/msm/dpu: switch to drm zpos property Remove dpu crtc custom properties and its handlers. drm/msm: remove msm_prop files drm/msm: remove dpu specific uapi header drivers/gpu/drm/msm/Makefile |9 - drivers/gpu/drm/msm/disp/dpu1/dpu_ad4.h| 99 -- .../gpu/drm/msm/disp/dpu1/dpu_color_processing.c | 1521 .../gpu/drm/msm/disp/dpu1/dpu_color_processing.h | 120 -- drivers/gpu/drm/msm/disp/dpu1/dpu_core_perf.c | 30 - drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c | 1328 + drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.h | 45 +- drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c| 14 - drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.h|2 - drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ad4.c | 1443 --- drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c | 72 +- drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h | 89 -- .../msm/disp/dpu1/dpu_hw_color_proc_common_v4.h| 69 - .../gpu/drm/msm/disp/dpu1/dpu_hw_color_proc_v4.c | 242 .../gpu/drm/msm/disp/dpu1/dpu_hw_color_proc_v4.h | 40 - .../drm/msm/disp/dpu1/dpu_hw_color_processing.h| 20 - .../msm/disp/dpu1/dpu_hw_color_processing_v1_7.c | 565 .../msm/disp/dpu1/dpu_hw_color_processing_v1_7.h | 92 -- drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.c | 44 - drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.h | 15 - drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ds.c | 149 -- drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ds.h | 111 -- drivers/gpu/drm/msm/disp/dpu1/dpu_hw_dspp.c| 209 --- drivers/gpu/drm/msm/disp/dpu1/dpu_hw_dspp.h| 220 --- drivers/gpu/drm/msm/disp/dpu1/dpu_hw_lm.c | 67 - drivers/gpu/drm/msm/disp/dpu1/dpu_hw_lm.h | 14 - drivers/gpu/drm/msm/disp/dpu1/dpu_hw_mdss.h| 58 +- drivers/gpu/drm/msm/disp/dpu1/dpu_hw_pingpong.c| 68 - drivers/gpu/drm/msm/disp/dpu1/dpu_hw_pingpong.h|6 - drivers/gpu/drm/msm/disp/dpu1/dpu_hw_reg_dma_v1.c | 757 -- drivers/gpu/drm/msm/disp/dpu1/dpu_hw_reg_dma_v1.h | 27 - .../msm/disp/dpu1/dpu_hw_reg_dma_v1_color_proc.c | 943 .../msm/disp/dpu1/dpu_hw_reg_dma_v1_color_proc.h | 75 - drivers/gpu/drm/msm/disp/dpu1/dpu_hw_sspp.c| 220 --- drivers/gpu/drm/msm/disp/dpu1/dpu_hw_sspp.h| 73 - drivers/gpu/drm/msm/disp/dpu1/dpu_hw_util.c|1 - drivers/gpu/drm/msm/disp/dpu1/dpu_hw_util.h| 156 ++ drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c| 11 - drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c | 1404 ++ drivers/gpu/drm/msm/disp/dpu1/dpu_plane.h | 43 - drivers/gpu/drm/msm/disp/dpu1/dpu_reg_dma.c| 139 -- drivers/gpu/drm/msm/disp/dpu1/dpu_reg_dma.h| 310 drivers/gpu/drm/msm/disp/dpu1/dpu_rm.c | 149 +- drivers/gpu/drm/msm/disp/dpu1/dpu_rm.h |2 - drivers/gpu/drm/msm/msm_drv.c |3 + drivers/gpu/drm/msm/msm_drv.h | 86 +- drivers/gpu/drm/msm/msm_prop.c | 688 - drivers/gpu/drm/msm/msm_prop.h | 438 -- include/uapi/drm/dpu_drm.h | 407 -- include/uapi/drm/msm_drm.h |1 - include/uapi/drm/msm_drm_pp.h | 345 - 51 files changed, 297 insertions(+), 12742 deletions(-) delete mode 100644 drivers/gpu/drm/msm/disp/dpu1/dpu_ad4.h delete mode 100644 drivers/gpu/drm/msm/disp/dpu1/dpu_color_processing.c delete mode 100644 drivers/gpu/drm/msm/disp/dpu1/dpu_color_processing.h delete mode 100644 drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ad4.c delete mode 100644 drivers/gpu/drm/msm/disp/dpu1/dpu_hw_color_proc_common_v4.h delete mode 100644 drivers/gpu/drm/msm/disp/dpu1/dpu_hw_color_proc_v4.c delete mode 100644 drivers/gpu/drm/msm/disp/dpu1/dpu_hw_color_proc_v4.h delete mode 100644 drivers/gpu/drm/msm/disp/dpu1/dpu_hw_color_processing.h delete mode 100644 drivers/gpu/drm/msm/disp/dpu1/dpu_hw_color_processing_v1_7.c delete mode 100644
[DPU PATCH v3 6/7] drm/msm: remove msm_prop files
Remove hand rolled msm property caching to handle DPU
custom properties. This change also cleans up all its
dependencies to cache and restore respective drm
states.
changes in v2:
- none
changes in v3:
- rebased on https://gitlab.freedesktop.org/seanpaul/
dpu-staging/commit/481d29d31cd629fd216381b53de5695f645465d5
Signed-off-by: Jeykumar Sankaran
Reviewed-by: Sean Paul dd
---
drivers/gpu/drm/msm/disp/dpu1/dpu_core_perf.c | 2 -
drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c | 239 +
drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.h | 16 -
drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.h | 2 -
drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c | 123 +
drivers/gpu/drm/msm/disp/dpu1/dpu_plane.h | 12 -
drivers/gpu/drm/msm/msm_drv.h | 16 +-
drivers/gpu/drm/msm/msm_prop.c| 688 --
drivers/gpu/drm/msm/msm_prop.h| 438
9 files changed, 8 insertions(+), 1528 deletions(-)
delete mode 100644 drivers/gpu/drm/msm/msm_prop.c
delete mode 100644 drivers/gpu/drm/msm/msm_prop.h
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_core_perf.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_core_perf.c
index 7eafca3..6c0f66c 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_core_perf.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_core_perf.c
@@ -19,8 +19,6 @@
#include
#include
-#include "msm_prop.h"
-
#include "dpu_kms.h"
#include "dpu_trace.h"
#include "dpu_crtc.h"
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
index 8254cd6..4616a62 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
@@ -583,10 +583,6 @@ static void dpu_crtc_destroy(struct drm_crtc *crtc)
if (!crtc)
return;
- if (dpu_crtc->blob_info)
- drm_property_blob_put(dpu_crtc->blob_info);
- msm_property_destroy(_crtc->property_info);
-
_dpu_crtc_deinit_events(dpu_crtc);
dpu_crtc->phandle = NULL;
@@ -1346,9 +1342,7 @@ static void dpu_crtc_destroy_state(struct drm_crtc *crtc,
__drm_atomic_helper_crtc_destroy_state(state);
- /* destroy value helper */
- msm_property_destroy_state(_crtc->property_info, cstate,
- >property_state);
+ kfree(cstate);
}
static int _dpu_crtc_wait_for_frame_done(struct drm_crtc *crtc)
@@ -1596,17 +1590,12 @@ static struct drm_crtc_state
*dpu_crtc_duplicate_state(struct drm_crtc *crtc)
dpu_crtc = to_dpu_crtc(crtc);
old_cstate = to_dpu_crtc_state(crtc->state);
- cstate = msm_property_alloc_state(_crtc->property_info);
+ cstate = kmemdup(old_cstate, sizeof(*old_cstate), GFP_KERNEL);
if (!cstate) {
DPU_ERROR("failed to allocate state\n");
return NULL;
}
- /* duplicate value helper */
- msm_property_duplicate_state(_crtc->property_info,
- old_cstate, cstate,
- >property_state, cstate->property_values);
-
/* duplicate base helper */
__drm_atomic_helper_crtc_duplicate_state(crtc, >base);
@@ -1642,17 +1631,12 @@ static void dpu_crtc_reset(struct drm_crtc *crtc)
}
dpu_crtc = to_dpu_crtc(crtc);
- cstate = msm_property_alloc_state(_crtc->property_info);
+ cstate = kzalloc(sizeof(*cstate), GFP_KERNEL);
if (!cstate) {
DPU_ERROR("failed to allocate state\n");
return;
}
- /* reset value helper */
- msm_property_reset_state(_crtc->property_info, cstate,
- >property_state,
- cstate->property_values);
-
_dpu_crtc_rp_reset(>rp, _crtc->rp_lock,
_crtc->rp_head);
@@ -2146,212 +2130,6 @@ void dpu_crtc_cancel_pending_flip(struct drm_crtc
*crtc, struct drm_file *file)
_dpu_crtc_complete_flip(crtc, file);
}
-/**
- * dpu_crtc_install_properties - install all drm properties for crtc
- * @crtc: Pointer to drm crtc structure
- */
-static void dpu_crtc_install_properties(struct drm_crtc *crtc,
- struct dpu_mdss_cfg *catalog)
-{
- struct dpu_crtc *dpu_crtc;
- struct drm_device *dev;
- struct dpu_kms_info *info;
- struct dpu_kms *dpu_kms;
-
- DPU_DEBUG("\n");
-
- if (!crtc || !catalog) {
- DPU_ERROR("invalid crtc or catalog\n");
- return;
- }
-
- dpu_crtc = to_dpu_crtc(crtc);
- dev = crtc->dev;
- dpu_kms = _dpu_crtc_get_kms(crtc);
-
- if (!dpu_kms) {
- DPU_ERROR("invalid argument\n");
- return;
- }
-
- info = kzalloc(sizeof(struct dpu_kms_info), GFP_KERNEL);
- if (!info) {
- DPU_ERROR("failed to allocate info memory\n");
- return;
- }
-
- msm_property_install_blob(_crtc->property_info, "capabilities",
-
[DPU PATCH v3 5/7] Remove dpu crtc custom properties and its handlers.
changes in v2:
- none
changes in v3:
- rebased on https://gitlab.freedesktop.org/seanpaul/
dpu-staging/commit/481d29d31cd629fd216381b53de5695f645465d5
Signed-off-by: Jeykumar Sankaran
Reviewed-by: Sean Paul
---
drivers/gpu/drm/msm/Makefile | 1 -
drivers/gpu/drm/msm/disp/dpu1/dpu_core_perf.c | 28 -
drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c | 856 +-
drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.h | 27 +-
drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c | 12 -
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ds.c | 149 -
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ds.h | 111
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_lm.c | 67 --
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_lm.h | 14 -
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_mdss.h | 16 -
drivers/gpu/drm/msm/disp/dpu1/dpu_rm.c| 71 +--
drivers/gpu/drm/msm/msm_drv.h | 15 -
12 files changed, 11 insertions(+), 1356 deletions(-)
delete mode 100644 drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ds.c
delete mode 100644 drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ds.h
diff --git a/drivers/gpu/drm/msm/Makefile b/drivers/gpu/drm/msm/Makefile
index 8ec0bff..dc56904 100644
--- a/drivers/gpu/drm/msm/Makefile
+++ b/drivers/gpu/drm/msm/Makefile
@@ -57,7 +57,6 @@ msm-y := \
disp/dpu1/dpu_hw_catalog.o \
disp/dpu1/dpu_hw_cdm.o \
disp/dpu1/dpu_hw_ctl.o \
- disp/dpu1/dpu_hw_ds.o \
disp/dpu1/dpu_hw_interrupts.o \
disp/dpu1/dpu_hw_intf.o \
disp/dpu1/dpu_hw_lm.o \
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_core_perf.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_core_perf.c
index 85c0229..7eafca3 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_core_perf.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_core_perf.c
@@ -102,34 +102,6 @@ static void _dpu_core_perf_calc_crtc(struct dpu_kms *kms,
dpu_cstate = to_dpu_crtc_state(state);
memset(perf, 0, sizeof(struct dpu_core_perf_params));
- perf->bw_ctl[DPU_POWER_HANDLE_DBUS_ID_MNOC] =
- dpu_crtc_get_property(dpu_cstate, CRTC_PROP_CORE_AB);
- perf->max_per_pipe_ib[DPU_POWER_HANDLE_DBUS_ID_MNOC] =
- dpu_crtc_get_property(dpu_cstate, CRTC_PROP_CORE_IB);
-
- if (dpu_cstate->bw_split_vote) {
- perf->bw_ctl[DPU_POWER_HANDLE_DBUS_ID_LLCC] =
- dpu_crtc_get_property(dpu_cstate, CRTC_PROP_LLCC_AB);
- perf->max_per_pipe_ib[DPU_POWER_HANDLE_DBUS_ID_LLCC] =
- dpu_crtc_get_property(dpu_cstate, CRTC_PROP_LLCC_IB);
- perf->bw_ctl[DPU_POWER_HANDLE_DBUS_ID_EBI] =
- dpu_crtc_get_property(dpu_cstate, CRTC_PROP_DRAM_AB);
- perf->max_per_pipe_ib[DPU_POWER_HANDLE_DBUS_ID_EBI] =
- dpu_crtc_get_property(dpu_cstate, CRTC_PROP_DRAM_IB);
- } else {
- perf->bw_ctl[DPU_POWER_HANDLE_DBUS_ID_LLCC] =
- dpu_crtc_get_property(dpu_cstate, CRTC_PROP_CORE_AB);
- perf->max_per_pipe_ib[DPU_POWER_HANDLE_DBUS_ID_LLCC] =
- dpu_crtc_get_property(dpu_cstate, CRTC_PROP_CORE_IB);
- perf->bw_ctl[DPU_POWER_HANDLE_DBUS_ID_EBI] =
- dpu_crtc_get_property(dpu_cstate, CRTC_PROP_CORE_AB);
- perf->max_per_pipe_ib[DPU_POWER_HANDLE_DBUS_ID_EBI] =
- dpu_crtc_get_property(dpu_cstate, CRTC_PROP_CORE_IB);
- }
-
- perf->core_clk_rate =
- dpu_crtc_get_property(dpu_cstate, CRTC_PROP_CORE_CLK);
-
if (!dpu_cstate->bw_control) {
for (i = 0; i < DPU_POWER_HANDLE_DBUS_ID_MAX; i++) {
perf->bw_ctl[i] = kms->catalog->perf.max_bw_high *
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
index a7d9aff..8254cd6 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
@@ -574,18 +574,6 @@ static void _dpu_crtc_deinit_events(struct dpu_crtc
*dpu_crtc)
return;
}
-/**
- * dpu_crtc_destroy_dest_scaler - free memory allocated for scaler lut
- * @dpu_crtc: Pointer to dpu crtc
- */
-static void _dpu_crtc_destroy_dest_scaler(struct dpu_crtc *dpu_crtc)
-{
- if (!dpu_crtc)
- return;
-
- kfree(dpu_crtc->scl3_lut_cfg);
-}
-
static void dpu_crtc_destroy(struct drm_crtc *crtc)
{
struct dpu_crtc *dpu_crtc = to_dpu_crtc(crtc);
@@ -598,7 +586,6 @@ static void dpu_crtc_destroy(struct drm_crtc *crtc)
if (dpu_crtc->blob_info)
drm_property_blob_put(dpu_crtc->blob_info);
msm_property_destroy(_crtc->property_info);
- _dpu_crtc_destroy_dest_scaler(dpu_crtc);
_dpu_crtc_deinit_events(dpu_crtc);
dpu_crtc->phandle = NULL;
@@ -635,71 +622,6 @@ static void _dpu_crtc_setup_blend_cfg(struct
dpu_crtc_mixer *mixer,
DPU_BLEND_BG_ALPHA_BG_CONST);
}
-static void
[Bug 104520] Intermittent X crashes: GPU HANG: ecode 9:0:0x85dffffb, in Xorg [443], reason: Hang on rcs0, action: reset
https://bugs.freedesktop.org/show_bug.cgi?id=104520 --- Comment #22 from Alif Wahid --- Created attachment 140127 --> https://bugs.freedesktop.org/attachment.cgi?id=140127=edit Log dump from /sys/class/drm/card0/error after GPU hang (as printed in dmesg output). I see this error intermittently when running the Xilinx Vivado v2016.4 software on my Ubuntu 16.04 LTS desktop (kernel 4.4.0, Intel core i5-6400 cpu with Intel skylake-gt2 gpu). Attached the full dump from /sys/class/drm/card0/error as instructed by dmesg below. [ 255.622496] [drm] stuck on render ring [ 255.623115] [drm] GPU HANG: ecode 9:0:0x84d8, in Xorg [1006], reason: Engine(s) hung, action: reset [ 255.623120] [drm] GPU hangs can indicate a bug anywhere in the entire gfx stack, including userspace. [ 255.623122] [drm] Please file a _new_ bug report on bugs.freedesktop.org against DRI -> DRM/Intel [ 255.623125] [drm] drm/i915 developers can then reassign to the right component if it's not a kernel issue. [ 255.623127] [drm] The gpu crash dump is required to analyze gpu hangs, so please always attach it. [ 255.623130] [drm] GPU crash dump saved to /sys/class/drm/card0/error [ 255.624623] drm/i915: Resetting chip after gpu hang [ 257.622605] [drm] RC6 on [ 311.628103] [drm] stuck on render ring [ 311.628686] [drm] GPU HANG: ecode 9:0:0x84d8, in Xorg [1006], reason: Engine(s) hung, action: reset [ 311.630227] drm/i915: Resetting chip after gpu hang [ 313.628765] [drm] RC6 on -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 106892] GPU hang with radeon glx driver
https://bugs.freedesktop.org/show_bug.cgi?id=106892 Bug ID: 106892 Summary: GPU hang with radeon glx driver Product: Mesa Version: 18.0 Hardware: x86-64 (AMD64) OS: Linux (All) Status: NEW Severity: major Priority: medium Component: Drivers/Gallium/r600 Assignee: dri-devel@lists.freedesktop.org Reporter: s...@gmx.de QA Contact: dri-devel@lists.freedesktop.org Created attachment 140126 --> https://bugs.freedesktop.org/attachment.cgi?id=140126=edit dmesg from xonotic hang Hi I'm using Mesa 18.1.1, when trying to play OpenGL games (e.g. Xonotic, Minetest) with my Radeon HD 4670 I get some graphics glitches and then the GPU is hanging and the X Server resets and until a complete restart mesa seems to use some VMware LLVMpipe driver then. Also the driver seems to spam my dmesg with annoying EDID messages. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 46/60] drm/omap: dss: Remove duplicated parameter to dss_mgr_(dis)connect()
Hi,
On Mon, Jun 11, 2018 at 08:16:24PM +0300, Laurent Pinchart wrote:
> Hi Sebastian,
>
> On Monday, 11 June 2018 02:48:45 EEST Sebastian Reichel wrote:
> > On Sat, May 26, 2018 at 08:25:04PM +0300, Laurent Pinchart wrote:
> > > The dss_mgr_connect() and dss_mgr_disconnect() functions take two
> > > omap_dss_device pointers as parameters, which are always set to the same
> > > value by all callers. Remove the duplicated pointer.
> > >
> > > Signed-off-by: Laurent Pinchart
> > > ---
> > >
> > > drivers/gpu/drm/omapdrm/dss/dpi.c | 8 +++-
> > > drivers/gpu/drm/omapdrm/dss/dsi.c | 8 +++-
> > > drivers/gpu/drm/omapdrm/dss/hdmi4.c | 8 +++-
> > > drivers/gpu/drm/omapdrm/dss/hdmi5.c | 8 +++-
> > > drivers/gpu/drm/omapdrm/dss/omapdss.h | 6 ++
> > > drivers/gpu/drm/omapdrm/dss/output.c | 9 -
> > > drivers/gpu/drm/omapdrm/dss/sdi.c | 8 +++-
> > > drivers/gpu/drm/omapdrm/dss/venc.c| 8 +++-
> > > 8 files changed, 24 insertions(+), 39 deletions(-)
>
> [snip]
>
> > > diff --git a/drivers/gpu/drm/omapdrm/dss/output.c
> > > b/drivers/gpu/drm/omapdrm/dss/output.c index 191b2e801257..2f7a019d059e
> > > 100644
> > > --- a/drivers/gpu/drm/omapdrm/dss/output.c
> > > +++ b/drivers/gpu/drm/omapdrm/dss/output.c
> > > @@ -109,18 +109,17 @@ void dss_uninstall_mgr_ops(struct dss_device *dss)
> > > }
> > > EXPORT_SYMBOL(dss_uninstall_mgr_ops);
> > >
> > > -int dss_mgr_connect(struct omap_dss_device *dssdev, struct
> > > omap_dss_device *dst)
> > > +int dss_mgr_connect(struct omap_dss_device *dssdev)
> > > {
> > > return dssdev->dss->mgr_ops->connect(dssdev->dss->mgr_ops_priv,
> > > - dssdev->dispc_channel, dst);
> > > + dssdev->dispc_channel, dssdev);
> >
> > Maybe also change mgr_ops->connect, so that it only takes dssdev
> > as a parameter? Otherwise
>
> It would make sense, but patch 60/60 in this series drops the
> mgr_ops->connect
> operation completely, so I don't think it's worth changing this.
Right. I only checked a few patches ahead:
Reviewed-by: Sebastian Reichel
-- Sebastian
signature.asc
Description: PGP signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 3/5] drm/msm/adreno: Load the firmware before bringing up the hardware
Hi Jordan,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on robclark/msm-next]
[also build test ERROR on v4.17 next-20180608]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
url:
https://github.com/0day-ci/linux/commits/Jordan-Crouse/drm-msm-Add-support-for-Adreno-a6xx/20180612-022828
base: git://people.freedesktop.org/~robclark/linux msm-next
config: arm64-defconfig (attached as .config)
compiler: aarch64-linux-gnu-gcc (Debian 7.2.0-11) 7.2.0
reproduce:
wget
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O
~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
GCC_VERSION=7.2.0 make.cross ARCH=arm64
Note: the
linux-review/Jordan-Crouse/drm-msm-Add-support-for-Adreno-a6xx/20180612-022828
HEAD 716a0bd2934f1b01e622ac7a6714789861824f8f builds fine.
It only hurts bisectibility.
All errors (new ones prefixed by >>):
drivers/gpu/drm/msm/adreno/adreno_device.c: In function 'adreno_load_gpu':
>> drivers/gpu/drm/msm/adreno/adreno_device.c:177:8: error: implicit
>> declaration of function 'adreno_load_fw'; did you mean 'adreno_load_gpu'?
>> [-Werror=implicit-function-declaration]
ret = adreno_load_fw(adreno_gpu);
^~
adreno_load_gpu
cc1: some warnings being treated as errors
vim +177 drivers/gpu/drm/msm/adreno/adreno_device.c
152
153 struct msm_gpu *adreno_load_gpu(struct drm_device *dev)
154 {
155 struct msm_drm_private *priv = dev->dev_private;
156 struct platform_device *pdev = priv->gpu_pdev;
157 struct msm_gpu *gpu = NULL;
158 struct adreno_gpu *adreno_gpu;
159 int ret;
160
161 if (pdev)
162 gpu = platform_get_drvdata(pdev);
163
164 if (!gpu) {
165 dev_err_once(dev->dev, "no GPU device was found\n");
166 return NULL;
167 }
168
169 adreno_gpu = to_adreno_gpu(gpu);
170
171 /*
172 * The number one reason for HW init to fail is if the firmware
isn't
173 * loaded yet. Try that first and don't bother continuing on
174 * otherwise
175 */
176
> 177 ret = adreno_load_fw(adreno_gpu);
178 if (ret)
179 return NULL;
180
181 /* Make sure pm runtime is active and reset any previous errors
*/
182 pm_runtime_set_active(>dev);
183
184 ret = pm_runtime_get_sync(>dev);
185 if (ret < 0) {
186 dev_err(dev->dev, "Couldn't power up the GPU: %d\n",
ret);
187 return NULL;
188 }
189
190 mutex_lock(>struct_mutex);
191 ret = msm_gpu_hw_init(gpu);
192 mutex_unlock(>struct_mutex);
193 pm_runtime_put_autosuspend(>dev);
194 if (ret) {
195 dev_err(dev->dev, "gpu hw init failed: %d\n", ret);
196 return NULL;
197 }
198
---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
.config.gz
Description: application/gzip
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v7 0/6] Add ChromeOS EC CEC Support
On Fri, 08 Jun 2018, Hans Verkuil wrote: > On 08/06/18 10:17, Neil Armstrong wrote: > > On 08/06/2018 09:53, Hans Verkuil wrote: > >> On 06/01/2018 10:19 AM, Neil Armstrong wrote: > >>> Hi All, > >>> > >>> The new Google "Fizz" Intel-based ChromeOS device is gaining CEC support > >>> through it's Embedded Controller, to enable the Linux CEC Core to > >>> communicate > >>> with it and get the CEC Physical Address from the correct HDMI Connector, > >>> the > >>> following must be added/changed: > >>> - Add the CEC sub-device registration in the ChromeOS EC MFD Driver > >>> - Add the CEC related commands and events definitions into the EC MFD > >>> driver > >>> - Add a way to get a CEC notifier with it's (optional) connector name > >>> - Add the CEC notifier to the i915 HDMI driver > >>> - Add the proper ChromeOS EC CEC Driver > >>> > >>> The CEC notifier with the connector name is the tricky point, since even > >>> on > >>> Device-Tree platforms, there is no way to distinguish between multiple > >>> HDMI > >>> connectors from the same DRM driver. The solution I implemented is pretty > >>> simple and only adds an optional connector name to eventually distinguish > >>> an HDMI connector notifier from another if they share the same device. > >> > >> This looks good to me, which brings me to the next question: how to merge > >> this? > >> > >> It touches on three subsystems (media, drm, mfd), so that makes this > >> tricky. > >> > >> I think there are two options: either the whole series goes through the > >> media tree, or patches 1+2 go through drm and 3-6 through media. If there > >> is a high chance of conflicts in the mfd code, then it is also an option to > >> have patches 3-6 go through the mfd subsystem. > > > > I think patches 3-6 should go in the mfd tree, Lee is used to handle this, > > then I think the rest could go in the media tree. > > > > Lee, do you think it would be possible to have an immutable branch with > > patches 3-6 ? > > > > Could we have an immutable branch from media tree with patch 1 to be merged > > in > > the i915 tree for patch 2 ? > > > > Or patch 1+2 could me merged into the i915 tree and generate an immutable > > branch > > I think patches 1+2 can just go to the i915 tree. The i915 driver changes > often, > so going through that tree makes sense. The cec-notifier code is unlikely to > change, > and I am fine with that patch going through i915. > > > for media to merge the mfd branch + patch 7 ? > > Patch 7? I only count 6? > > If 1+2 go through drm and 3-6 go through mfd, then media isn't affected at > all. > There is chance of a conflict when this is eventually pushed to mainline for > the media Kconfig, but that's all. What are the *build* dependencies within the set? I'd be happy to send out a pull-request for either all of the patches, or just the MFD changes once I've had chance to review them. -- Lee Jones [李琼斯] Linaro Services Technical Lead Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[git pull] drm next (msm) + fixes
Hi Linus, I looked at Rob's msm tree, he kept it small due to being late, and it was in -next for a while before he was ill, so I think it should be fine. Otherwise this contains a set of i915 fixes and a v3d build fix, and vc4 leak fix. Thanks, Dave. drm-next-2018-06-11: msm next, i915, vc4, v3d fixes The following changes since commit 568cf2e6aa0c762f14d2d0d481a006f93c63ab7a: Merge tag 'drm-amdkfd-next-2018-05-28' of git://people.freedesktop.org/~gabbayo/linux into drm-next (2018-05-30 11:12:22 +1000) are available in the Git repository at: git://anongit.freedesktop.org/drm/drm tags/drm-next-2018-06-11 for you to fetch changes up to 33ce21d6a2491ef9adb8dc395e3f5bbbfcdc95b5: Merge tag 'drm-intel-next-fixes-2018-06-08-2' of git://anongit.freedesktop.org/drm/drm-intel into drm-next (2018-06-09 06:34:51 +1000) msm next, i915, vc4, v3d fixes Abhinav Kumar (3): drm/msm/dsi: check return value for video done waits drm/msm/dsi: check video mode engine status before waiting drm/msm/dsi: implement auto PHY timing calculator for 10nm PHY Archit Taneja (3): drm/msm/mdp5: Add global state as a private atomic object drm/msm/mdp5: Use the new private_obj state drm/msm: Don't subclass drm_atomic_state anymore Arnd Bergmann (1): drm/v3d: add CONFIG_MMU dependency Ben Hutchings (1): drm/msm: Fix possible null dereference on failure of get_pages() Changbin Du (2): drm/i915/gvt: Fix the validation on size field of dp aux header drm/i915/kvmgt: Check the pfn got from vfio_pin_pages Chris Wilson (2): drm/i915: Nul-terminate legacy debug string drm/i915: Remove stale asserts from i915_gem_find_active_request() Colin Ian King (1): drm/i915/gvt: fix memory leak of a cmd_entry struct on error exit path Daniel Mack (2): drm/msm: remove unbalanced mutex unlock drm/msm: use correct aspace pointer in msm_gem_put_iova() Dave Airlie (3): Merge tag 'drm-msm-next-2018-06-04' of git://people.freedesktop.org/~robclark/linux into drm-next Merge tag 'drm-misc-next-fixes-2018-05-31' of git://anongit.freedesktop.org/drm/drm-misc into drm-next Merge tag 'drm-intel-next-fixes-2018-06-08-2' of git://anongit.freedesktop.org/drm/drm-intel into drm-next Emil Velikov (1): drm/msm: don't deref error pointer in the msm_fbdev_create error path Eric Anholt (1): drm/vc4: Fix leak of the file_priv that stored the perfmon. Jani Nikula (2): Revert "drm/i915/edp: Allow alternate fixed mode for eDP if available." Merge tag 'gvt-fixes-2018-04-19' of https://github.com/intel/gvt-linux into drm-intel-next-fixes Jeykumar Sankaran (1): drm/msm: Add modifier to mdp_get_format arguments Mahesh Kumar (2): drm/i915/icl: fix icl_unmap/map_plls_to_ports drm/i915/icl: Don't update enabled dbuf slices struct until updated in hw Sean Paul (7): drm/msm: Mark the crtc->state->event consumed drm/msm: Refactor complete_commit() to look more the helpers drm/msm: Move implicit sync handling to prepare_fb drm/msm: Issue queued events when disabling crtc drm/msm: Remove msm_commit/worker, use atomic helper commit drm/msm: Switch to atomic_helper_commit() drm/msm: Fix NULL deref on bind/probe deferral Stefan Agner (1): drm/msm/dsi: use correct enum in dsi_get_cmd_fmt Ville Syrjälä (1): drm/i915: Remove bogus NV12 PLANE_COLOR_CTL setup Xiong Zhang (1): drm/i915/gvt: Dereference msi eventfd_ctx when it isn't used anymore Zhenyu Wang (1): Back merge 'drm-intel-fixes' into gvt-fixes drivers/gpu/drm/i915/gvt/cmd_parser.c | 1 + drivers/gpu/drm/i915/gvt/display.h | 2 +- drivers/gpu/drm/i915/gvt/handlers.c| 13 +- drivers/gpu/drm/i915/gvt/kvmgt.c | 34 +++- drivers/gpu/drm/i915/i915_gem.c| 17 +- drivers/gpu/drm/i915/intel_ddi.c | 6 +- drivers/gpu/drm/i915/intel_display.c | 7 +- drivers/gpu/drm/i915/intel_dp.c| 38 + drivers/gpu/drm/i915/intel_drv.h | 2 - drivers/gpu/drm/i915/intel_dsi.c | 2 +- drivers/gpu/drm/i915/intel_dvo.c | 2 +- drivers/gpu/drm/i915/intel_engine_cs.c | 2 +- drivers/gpu/drm/i915/intel_lvds.c | 3 +- drivers/gpu/drm/i915/intel_panel.c | 6 - drivers/gpu/drm/i915/intel_pm.c| 1 - drivers/gpu/drm/msm/disp/mdp4/mdp4_plane.c | 17 +- drivers/gpu/drm/msm/disp/mdp5/mdp5_crtc.c | 9 + drivers/gpu/drm/msm/disp/mdp5/mdp5_kms.c | 105 drivers/gpu/drm/msm/disp/mdp5/mdp5_kms.h | 27 +-- drivers/gpu/drm/msm/disp/mdp5/mdp5_mixer.c | 12 +- drivers/gpu/drm/msm/disp/mdp5/mdp5_pipe.c | 20 ++- drivers/gpu/drm/msm/disp/mdp5/mdp5_plane.c | 16 +- drivers/gpu/drm/msm/disp/mdp5/mdp5_smp.c | 17 +-
Re: Kernel and ADM hardware roulette ( was AMD graphics performance regression in 4.15 and later )
I think the prime issue is that dma_direct_alloc respects the dma mask. Which we don't need if actually using the iommu. This would be mostly harmless exept for the the SEV bit high in the address that makes the checks fail. For now I'd say revert this commit for 4.17/4.18-rc and I'll look into addressing these issues properly. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: Kernel and ADM hardware roulette ( was AMD graphics performance regression in 4.15 and later )
2018-06-08 8:52 GMT+02:00 Christian König : > Am 08.06.2018 um 08:02 schrieb Christoph Hellwig: >> >> On Thu, Jun 07, 2018 at 02:32:46PM +0200, Gabriel C wrote: >>> >>> Ok done.. bisect points to: >> >> What is the failure mode you are seeing? Can't find anything in the >> mail unfortunately. > > > As far as I analyzed it we now get an -ENOMEM from dma_alloc_attrs() in > drivers/gpu/drm/ttm/ttm_page_alloc_dma.c when IOMMU is enabled. > > Still need to figure out which parameters we want to use for the allocation, > but I think it is only 4k or 8k. When you guys need me to test something , or run debug patches or patches of any sort just let me know.. > > Regards, > Christian. BR ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 3/3] ANDROID: goldfish_fb: Set pixclock = 0
Hi, thank you for reviewing our patches. I sent "v2". Regards, Roman. On Fri, Jun 8, 2018 at 9:24 AM Bartlomiej Zolnierkiewicz wrote: > > > [ + linux-fbdev ML ] > > On Thursday, May 31, 2018 03:02:52 PM r...@google.com wrote: > > From: Christoffer Dall > > > > User space Android code identifies pixclock == 0 as a sign for emulation > > and will set the frame rate to 60 fps when reading this value, which is > > the desired outcome. > > > > Change-Id: I759bf518bf6683446bc786bf1be3cafa02dd8d42 > > please drop your local Change-Id from the upstream kernel submissions > > > Signed-off-by: Christoffer Dall > > Signed-off-by: Peter Maydell > > your S-o-b line is also needed > > Best regards, > -- > Bartlomiej Zolnierkiewicz > Samsung R Institute Poland > Samsung Electronics > ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
WARNING in ion_dma_buf_begin_cpu_access
Hello, syzbot found the following crash on: HEAD commit:a16afaf7928b Merge tag 'for-v4.18' of git://git.kernel.org.. git tree: upstream console output: https://syzkaller.appspot.com/x/log.txt?x=1480e36f80 kernel config: https://syzkaller.appspot.com/x/.config?x=314f2150f36c16ca dashboard link: https://syzkaller.appspot.com/bug?extid=55b1d9f811650de944c6 compiler: gcc (GCC) 8.0.1 20180413 (experimental) syzkaller repro:https://syzkaller.appspot.com/x/repro.syz?x=150b8abf80 C reproducer: https://syzkaller.appspot.com/x/repro.c?x=1204efdf80 IMPORTANT: if you fix the bug, please add the following tag to the commit: Reported-by: syzbot+55b1d9f811650de94...@syzkaller.appspotmail.com 1965969 pages RAM 0 pages HighMem/MovableOnly 340001 pages reserved [ cut here ] heap->ops->map_kernel should return ERR_PTR on error WARNING: CPU: 1 PID: 4564 at drivers/staging/android/ion/ion.c:148 ion_buffer_kmap_get drivers/staging/android/ion/ion.c:147 [inline] WARNING: CPU: 1 PID: 4564 at drivers/staging/android/ion/ion.c:148 ion_dma_buf_begin_cpu_access+0x48e/0x5a0 drivers/staging/android/ion/ion.c:328 Kernel panic - not syncing: panic_on_warn set ... CPU: 1 PID: 4564 Comm: syz-executor145 Not tainted 4.17.0+ #93 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 Call Trace: __dump_stack lib/dump_stack.c:77 [inline] dump_stack+0x1b9/0x294 lib/dump_stack.c:113 panic+0x22f/0x4de kernel/panic.c:184 __warn.cold.8+0x163/0x1b3 kernel/panic.c:536 report_bug+0x252/0x2d0 lib/bug.c:186 fixup_bug arch/x86/kernel/traps.c:178 [inline] do_error_trap+0x1fc/0x4d0 arch/x86/kernel/traps.c:296 do_invalid_op+0x1b/0x20 arch/x86/kernel/traps.c:316 invalid_op+0x14/0x20 arch/x86/entry/entry_64.S:992 RIP: 0010:ion_buffer_kmap_get drivers/staging/android/ion/ion.c:147 [inline] RIP: 0010:ion_dma_buf_begin_cpu_access+0x48e/0x5a0 drivers/staging/android/ion/ion.c:328 Code: ff 41 bc ea ff ff ff 89 de e8 8e b0 ba fb 84 db 75 a8 e8 b5 af ba fb 48 c7 c7 00 05 68 88 c6 05 39 8d d9 03 01 e8 02 c7 86 fb <0f> 0b eb 8c 48 c7 c7 40 09 ef 88 e8 12 a3 f7 fb e9 15 ff ff ff e8 RSP: 0018:8801ac87fb08 EFLAGS: 00010286 RAX: 0034 RBX: RCX: 816191ea RDX: RSI: 8161f4e1 RDI: 8801ac87f7e0 RBP: 8801ac87fb60 R08: 8801d8856480 R09: 0006 R10: 8801d8856480 R11: R12: ffea R13: 8801d977d148 R14: 0001 R15: 89724b80 dma_buf_begin_cpu_access+0x7f/0x160 drivers/dma-buf/dma-buf.c:823 dma_buf_ioctl+0x1aa/0x240 drivers/dma-buf/dma-buf.c:314 vfs_ioctl fs/ioctl.c:46 [inline] file_ioctl fs/ioctl.c:500 [inline] do_vfs_ioctl+0x1cf/0x16f0 fs/ioctl.c:684 ksys_ioctl+0xa9/0xd0 fs/ioctl.c:701 __do_sys_ioctl fs/ioctl.c:708 [inline] __se_sys_ioctl fs/ioctl.c:706 [inline] __x64_sys_ioctl+0x73/0xb0 fs/ioctl.c:706 do_syscall_64+0x1b1/0x800 arch/x86/entry/common.c:287 entry_SYSCALL_64_after_hwframe+0x49/0xbe RIP: 0033:0x440479 Code: 18 89 d0 c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 0f 83 5b 14 fc ff c3 66 2e 0f 1f 84 00 00 00 00 RSP: 002b:7fff6df8d2f8 EFLAGS: 0246 ORIG_RAX: 0010 RAX: ffda RBX: RCX: 00440479 RDX: 20fd3ff8 RSI: 40086200 RDI: 0004 RBP: 006cb018 R08: 0001 R09: 7fff6df80031 R10: R11: 0246 R12: 0005 R13: R14: R15: Dumping ftrace buffer: (ftrace buffer empty) Kernel Offset: disabled Rebooting in 86400 seconds.. --- This bug is generated by a bot. It may contain errors. See https://goo.gl/tpsmEJ for more information about syzbot. syzbot engineers can be reached at syzkal...@googlegroups.com. syzbot will keep track of this bug report. See: https://goo.gl/tpsmEJ#bug-status-tracking for how to communicate with syzbot. syzbot can test patches for this bug, for details see: https://goo.gl/tpsmEJ#testing-patches ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 1/3] video: fbdev: Fix checkpatch warnings in goldfishfb.c
From: Roman Kiryanov
Address issues pointed by checkpatch.pl
Signed-off-by: Roman Kiryanov
---
Changes in v2:
- Updated the commit message to include "video: fbdev:" and added a
description.
drivers/video/fbdev/goldfishfb.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/video/fbdev/goldfishfb.c b/drivers/video/fbdev/goldfishfb.c
index 3b70044773b6..de29c4ff77e5 100644
--- a/drivers/video/fbdev/goldfishfb.c
+++ b/drivers/video/fbdev/goldfishfb.c
@@ -124,6 +124,7 @@ static int goldfish_fb_check_var(struct fb_var_screeninfo
*var,
static int goldfish_fb_set_par(struct fb_info *info)
{
struct goldfish_fb *fb = container_of(info, struct goldfish_fb, fb);
+
if (fb->rotation != fb->fb.var.rotate) {
info->fix.line_length = info->var.xres * 2;
fb->rotation = fb->fb.var.rotate;
@@ -148,13 +149,14 @@ static int goldfish_fb_pan_display(struct
fb_var_screeninfo *var,
wait_event_timeout(fb->wait,
fb->base_update_count != base_update_count, HZ / 15);
if (fb->base_update_count == base_update_count)
- pr_err("goldfish_fb_pan_display: timeout waiting for base
update\n");
+ pr_err("%s: timeout waiting for base update\n", __func__);
return 0;
}
static int goldfish_fb_blank(int blank, struct fb_info *info)
{
struct goldfish_fb *fb = container_of(info, struct goldfish_fb, fb);
+
switch (blank) {
case FB_BLANK_NORMAL:
writel(1, fb->reg_base + FB_SET_BLANK);
--
2.18.0.rc1.242.g61856ae69a-goog
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v7 2/2] drm/i915: remove intel_cursor_plane_funcs
From: Gustavo Padovan
After converting legacy cursor updates to atomic async commits
intel_cursor_plane_funcs just duplicates intel_plane_funcs now.
Cc: Daniel Vetter
Signed-off-by: Gustavo Padovan
Signed-off-by: Enric Balletbo i Serra
---
Changes in v7: None
Changes in v6: None
Changes in v5: None
Changes in v4: None
Changes in v3: None
drivers/gpu/drm/i915/intel_display.c | 23 +--
1 file changed, 1 insertion(+), 22 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 4ff73bfd1616..06f53960ccd8 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -13320,16 +13320,6 @@ static bool
intel_primary_plane_format_mod_supported(struct drm_plane *plane,
return i8xx_mod_supported(format, modifier);
}
-static bool intel_cursor_plane_format_mod_supported(struct drm_plane *plane,
- uint32_t format,
- uint64_t modifier)
-{
- if (WARN_ON(modifier == DRM_FORMAT_MOD_INVALID))
- return false;
-
- return modifier == DRM_FORMAT_MOD_LINEAR && format ==
DRM_FORMAT_ARGB;
-}
-
static struct drm_plane_funcs intel_plane_funcs = {
.update_plane = drm_atomic_helper_update_plane,
.disable_plane = drm_atomic_helper_disable_plane,
@@ -13341,17 +13331,6 @@ static struct drm_plane_funcs intel_plane_funcs = {
.format_mod_supported = intel_primary_plane_format_mod_supported,
};
-static const struct drm_plane_funcs intel_cursor_plane_funcs = {
- .update_plane = drm_atomic_helper_update_plane,
- .disable_plane = drm_atomic_helper_disable_plane,
- .destroy = intel_plane_destroy,
- .atomic_get_property = intel_plane_atomic_get_property,
- .atomic_set_property = intel_plane_atomic_set_property,
- .atomic_duplicate_state = intel_plane_duplicate_state,
- .atomic_destroy_state = intel_plane_destroy_state,
- .format_mod_supported = intel_cursor_plane_format_mod_supported,
-};
-
static bool i9xx_plane_has_fbc(struct drm_i915_private *dev_priv,
enum i9xx_plane_id i9xx_plane)
{
@@ -13614,7 +13593,7 @@ intel_cursor_plane_create(struct drm_i915_private
*dev_priv,
cursor->cursor.size = ~0;
ret = drm_universal_plane_init(_priv->drm, >base,
- 0, _cursor_plane_funcs,
+ 0, _plane_funcs,
intel_cursor_formats,
ARRAY_SIZE(intel_cursor_formats),
cursor_format_modifiers,
--
2.17.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Xen-devel] [PATCH v2 5/9] xen/gntdev: Allow mappings for DMA buffers
On 06/08/2018 01:59 PM, Stefano Stabellini wrote:
>
@@ -325,6 +401,14 @@ static int map_grant_pages(struct
grant_map
*map)
map->unmap_ops[i].handle = map->map_ops[i].handle;
if (use_ptemod)
map->kunmap_ops[i].handle =
map->kmap_ops[i].handle;
+#ifdef CONFIG_XEN_GRANT_DMA_ALLOC
+ else if (map->dma_vaddr) {
+ unsigned long mfn;
+
+ mfn = __pfn_to_mfn(page_to_pfn(map->pages[i]));
>>> Not pfn_to_mfn()?
>> I'd love to, but pfn_to_mfn is only defined for x86, not ARM: [1]
>> and [2]
>> Thus,
>>
>> drivers/xen/gntdev.c:408:10: error: implicit declaration of function
>> ‘pfn_to_mfn’ [-Werror=implicit-function-declaration]
>> mfn = pfn_to_mfn(page_to_pfn(map->pages[i]));
>>
>> So, I'll keep __pfn_to_mfn
> How will this work on non-PV x86?
So, you mean I need:
#ifdef CONFIG_X86
mfn = pfn_to_mfn(page_to_pfn(map->pages[i]));
#else
mfn = __pfn_to_mfn(page_to_pfn(map->pages[i]));
#endif
>>> I'd rather fix it in ARM code. Stefano, why does ARM uses the
>>> underscored version?
>> Do you want me to add one more patch for ARM to wrap __pfn_to_mfn
>> with static inline for ARM? e.g.
>> static inline ...pfn_to_mfn(...)
>> {
>> __pfn_to_mfn();
>> }
>
> A Xen on ARM guest doesn't actually know the mfns behind its own
> pseudo-physical pages. This is why we stopped using pfn_to_mfn and
> started using pfn_to_bfn instead, which will generally return "pfn",
> unless the page is a foreign grant. See include/xen/arm/page.h.
> pfn_to_bfn was also introduced on x86. For example, see the usage of
> pfn_to_bfn in drivers/xen/swiotlb-xen.c. Otherwise, if you don't care
> about other mapped grants, you can just use pfn_to_gfn, that always
> returns pfn.
I think then this code needs to use pfn_to_bfn().
>
> Also, for your information, we support different page granularities in
> Linux as a Xen guest, see the comment at include/xen/arm/page.h:
>
> /*
>* The pseudo-physical frame (pfn) used in all the helpers is always based
>* on Xen page granularity (i.e 4KB).
>*
>* A Linux page may be split across multiple non-contiguous Xen page so we
>* have to keep track with frame based on 4KB page granularity.
>*
>* PV drivers should never make a direct usage of those helpers
> (particularly
>* pfn_to_gfn and gfn_to_pfn).
>*/
>
> A Linux page could be 64K, but a Xen page is always 4K. A granted page
> is also 4K. We have helpers to take into account the offsets to map
> multiple Xen grants in a single Linux page, see for example
> drivers/xen/grant-table.c:gnttab_foreach_grant. Most PV drivers have
> been converted to be able to work with 64K pages correctly, but if I
> remember correctly gntdev.c is the only remaining driver that doesn't
> support 64K pages yet, so you don't have to deal with it if you don't
> want to.
I believe somewhere in this series there is a test for PAGE_SIZE vs.
XEN_PAGE_SIZE. Right, Oleksandr?
Thanks for the explanation.
-boris
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 3/3] video: fbdev: Set pixclock = 0 in goldfishfb
From: Christoffer Dall User space Android code identifies pixclock == 0 as a sign for emulation and will set the frame rate to 60 fps when reading this value, which is the desired outcome. Signed-off-by: Christoffer Dall Signed-off-by: Peter Maydell Signed-off-by: Roman Kiryanov --- Changes in v2: - Updated the commit message to include "video: fbdev:". - Dropped Change-Id. - Signed-off the commit. drivers/video/fbdev/goldfishfb.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/video/fbdev/goldfishfb.c b/drivers/video/fbdev/goldfishfb.c index 01732858b60d..3a9e5f1b758e 100644 --- a/drivers/video/fbdev/goldfishfb.c +++ b/drivers/video/fbdev/goldfishfb.c @@ -237,7 +237,7 @@ static int goldfish_fb_probe(struct platform_device *pdev) fb->fb.var.activate = FB_ACTIVATE_NOW; fb->fb.var.height = readl(fb->reg_base + FB_GET_PHYS_HEIGHT); fb->fb.var.width= readl(fb->reg_base + FB_GET_PHYS_WIDTH); - fb->fb.var.pixclock = 1; + fb->fb.var.pixclock = 0; fb->fb.var.red.offset = 11; fb->fb.var.red.length = 5; -- 2.18.0.rc1.242.g61856ae69a-goog ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 2/3] video: fbdev: Enable ACPI-based enumeration for goldfishfb
From: Yu Ning
Add an ACPI id to make goldfish framebuffer to support ACPI enumeration.
Signed-off-by: Yu Ning
Signed-off-by: Roman Kiryanov
---
Changes in v2:
- Removed references to commits outside of kernel.org.
- Updated the commit description.
drivers/video/fbdev/goldfishfb.c | 8
1 file changed, 8 insertions(+)
diff --git a/drivers/video/fbdev/goldfishfb.c b/drivers/video/fbdev/goldfishfb.c
index de29c4ff77e5..01732858b60d 100644
--- a/drivers/video/fbdev/goldfishfb.c
+++ b/drivers/video/fbdev/goldfishfb.c
@@ -26,6 +26,7 @@
#include
#include
#include
+#include
enum {
FB_GET_WIDTH= 0x00,
@@ -312,12 +313,19 @@ static const struct of_device_id goldfish_fb_of_match[] =
{
};
MODULE_DEVICE_TABLE(of, goldfish_fb_of_match);
+static const struct acpi_device_id goldfish_fb_acpi_match[] = {
+ { "GFSH0004", 0 },
+ { },
+};
+MODULE_DEVICE_TABLE(acpi, goldfish_fb_acpi_match);
+
static struct platform_driver goldfish_fb_driver = {
.probe = goldfish_fb_probe,
.remove = goldfish_fb_remove,
.driver = {
.name = "goldfish_fb",
.of_match_table = goldfish_fb_of_match,
+ .acpi_match_table = ACPI_PTR(goldfish_fb_acpi_match),
}
};
--
2.18.0.rc1.242.g61856ae69a-goog
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v7 1/2] drm/i915: update cursors asynchronously through atomic
From: Gustavo Padovan
Add support to async updates of cursors by using the new atomic
interface for that. Basically what this commit does is do what
intel_legacy_cursor_update() did but through atomic.
Cc: Daniel Vetter
Cc: intel-...@lists.freedesktop.org
Signed-off-by: Gustavo Padovan
Signed-off-by: Enric Balletbo i Serra
---
This is another attempt to land the patches to update cursors
asynchronously through atomic for the i915 driver. Last version was sent
some time ago [1], so these series are rebased on top of current mainline
and also solves some issues found. The patches were tested by running the
igt test and check there is no regressions (kms_cursor_legacy and
kms_atomic plane_cursor_legacy)
Waiting for your feedback,
Enric
[1] https://lists.freedesktop.org/archives/dri-devel/2017-September/152141.html
Changes in v7:
- Rebase on top of drm-intel repository. Hopefully now will play
nicely with autobuilders.
Changes in v6:
- Rework the intel_plane_atomic_async_update due driver changed from
last time.
- Removed the mutex_lock/unlock as causes a deadlock.
Changes in v5:
- Call drm_atomic_helper_async_check() from the check hook
Changes in v4:
- Set correct vma to new state for cleanup
- Move size checks back to drivers (Ville Syrjälä)
Changes in v3:
- Move fb setting to core and use new state (Eric Anholt)
drivers/gpu/drm/i915/intel_atomic_plane.c | 69 ++
drivers/gpu/drm/i915/intel_display.c | 155 +++---
2 files changed, 87 insertions(+), 137 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_atomic_plane.c
b/drivers/gpu/drm/i915/intel_atomic_plane.c
index 6d068786eb41..5fc38ee55aba 100644
--- a/drivers/gpu/drm/i915/intel_atomic_plane.c
+++ b/drivers/gpu/drm/i915/intel_atomic_plane.c
@@ -253,11 +253,80 @@ static void intel_plane_atomic_update(struct drm_plane
*plane,
}
}
+static int intel_plane_atomic_async_check(struct drm_plane *plane,
+ struct drm_plane_state *state)
+{
+ struct drm_crtc_state *crtc_state;
+
+ if (plane->type != DRM_PLANE_TYPE_CURSOR)
+ return -EINVAL;
+
+ crtc_state = drm_atomic_get_existing_crtc_state(state->state,
+ state->crtc);
+ if (WARN_ON(!crtc_state))
+ return -EINVAL;
+
+ /*
+* When crtc is inactive or there is a modeset pending,
+* wait for it to complete in the slowpath
+*/
+ if (!crtc_state->active || to_intel_crtc_state(crtc_state)->update_pipe)
+ return -EINVAL;
+
+ /*
+* If any parameters change that may affect watermarks,
+* take the slowpath. Only changing fb or position should be
+* in the fastpath.
+*/
+ if (plane->state->crtc != state->crtc ||
+ plane->state->src_w != state->src_w ||
+ plane->state->src_h != state->src_h ||
+ plane->state->crtc_w != state->crtc_w ||
+ plane->state->crtc_h != state->crtc_h ||
+ !plane->state->fb != !state->fb)
+ return -EINVAL;
+
+ return 0;
+}
+
+static void intel_plane_atomic_async_update(struct drm_plane *plane,
+ struct drm_plane_state *new_state)
+{
+ struct intel_plane *intel_plane = to_intel_plane(plane);
+ struct drm_crtc *crtc = plane->state->crtc;
+ struct drm_framebuffer *old_fb;
+
+ old_fb = plane->state->fb;
+
+ i915_gem_track_fb(intel_fb_obj(old_fb), intel_fb_obj(new_state->fb),
+ intel_plane->frontbuffer_bit);
+
+ plane->state->src_x = new_state->src_x;
+ plane->state->src_y = new_state->src_y;
+ plane->state->crtc_x = new_state->crtc_x;
+ plane->state->crtc_y = new_state->crtc_y;
+ plane->state->fb = new_state->fb;
+
+ new_state->fb = old_fb;
+
+ if (plane->state->visible) {
+ trace_intel_update_plane(plane, to_intel_crtc(crtc));
+ intel_plane->update_plane(intel_plane,
+ to_intel_crtc_state(crtc->state),
+ to_intel_plane_state(plane->state));
+ } else {
+ trace_intel_disable_plane(plane, to_intel_crtc(crtc));
+ intel_plane->disable_plane(intel_plane, to_intel_crtc(crtc));
+ }
+}
+
const struct drm_plane_helper_funcs intel_plane_helper_funcs = {
.prepare_fb = intel_prepare_plane_fb,
.cleanup_fb = intel_cleanup_plane_fb,
.atomic_check = intel_plane_atomic_check,
.atomic_update = intel_plane_atomic_update,
+ .atomic_async_check = intel_plane_atomic_async_check,
+ .atomic_async_update = intel_plane_atomic_async_update,
};
/**
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 17c590b42fd7..4ff73bfd1616 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++
Re: [PATCHv2 01/17] drm/omap: fix omap_fbdev_free() when omap_fbdev_create() wasn't called
Hi, On Wed, Feb 28, 2018 at 01:25:58PM +0200, Tomi Valkeinen wrote: > If we have no crtcs/connectors, fbdev init goes fine, but > omap_fbdev_create() is never called. This means that omap_fbdev->bo is > NULL and omap_fbdev_free() crashes. > > Add a check to omap_fbdev_free() to handle the NULL case. > > Signed-off-by: Tomi Valkeinen > Reviewed-by: Laurent Pinchart > --- Reviewed-by: Sebastian Reichel -- Sebastian > drivers/gpu/drm/omapdrm/omap_fbdev.c | 3 ++- > 1 file changed, 2 insertions(+), 1 deletion(-) > > diff --git a/drivers/gpu/drm/omapdrm/omap_fbdev.c > b/drivers/gpu/drm/omapdrm/omap_fbdev.c > index 1ace63e2ff22..632ebcf2165f 100644 > --- a/drivers/gpu/drm/omapdrm/omap_fbdev.c > +++ b/drivers/gpu/drm/omapdrm/omap_fbdev.c > @@ -303,7 +303,8 @@ void omap_fbdev_free(struct drm_device *dev) > fbdev = to_omap_fbdev(priv->fbdev); > > /* unpin the GEM object pinned in omap_fbdev_create() */ > - omap_gem_unpin(fbdev->bo); > + if (fbdev->bo) > + omap_gem_unpin(fbdev->bo); > > /* this will free the backing object */ > if (fbdev->fb) > -- > Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. > Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki > > ___ > dri-devel mailing list > dri-devel@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/dri-devel signature.asc Description: PGP signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 04/60] drm/omap: dss: Remove display ordering from dss/display.c
Hi,
On Sat, May 26, 2018 at 08:24:22PM +0300, Laurent Pinchart wrote:
> From: Peter Ujfalusi
>
> As ordering of the dss_devices based on DT aliases is now implemented in
> omap_drm.c, there is no need to do the ordering in dss/display.c
> anymore.
>
> At the same time remove the alias member of the omap_dss_device struct
> since it is no longer needed. The only place it was used is in the
> omapdss_register_display() function.
>
> Signed-off-by: Peter Ujfalusi
> Signed-off-by: Tomi Valkeinen
> Reviewed-by: Laurent Pinchart
> Signed-off-by: Laurent Pinchart
> ---
Reviewed-by: Sebastian Reichel
-- Sebastian
> Changes since v0:
>
> - Use %u to format display ID
> ---
> drivers/gpu/drm/omapdrm/dss/display.c | 15 +++
> drivers/gpu/drm/omapdrm/dss/omapdss.h | 2 --
> 2 files changed, 3 insertions(+), 14 deletions(-)
>
> diff --git a/drivers/gpu/drm/omapdrm/dss/display.c
> b/drivers/gpu/drm/omapdrm/dss/display.c
> index 3ef99f344bd3..25c3be86d7f4 100644
> --- a/drivers/gpu/drm/omapdrm/dss/display.c
> +++ b/drivers/gpu/drm/omapdrm/dss/display.c
> @@ -41,7 +41,6 @@ static int disp_num_counter;
> int omapdss_register_display(struct omap_dss_device *dssdev)
> {
> struct omap_dss_driver *drv = dssdev->driver;
> - struct list_head *cur;
> int id;
>
> /*
> @@ -54,26 +53,18 @@ int omapdss_register_display(struct omap_dss_device
> *dssdev)
>
> dssdev->alias_id = id;
>
> - snprintf(dssdev->alias, sizeof(dssdev->alias), "display%d", id);
> -
> /* Use 'label' property for name, if it exists */
> of_property_read_string(dssdev->dev->of_node, "label", >name);
>
> if (dssdev->name == NULL)
> - dssdev->name = dssdev->alias;
> + dssdev->name = devm_kasprintf(dssdev->dev, GFP_KERNEL,
> + "display%u", id);
>
> if (drv && drv->get_timings == NULL)
> drv->get_timings = omapdss_default_get_timings;
>
> mutex_lock(_list_mutex);
> - list_for_each(cur, _list) {
> - struct omap_dss_device *ldev = list_entry(cur,
> - struct omap_dss_device,
> - panel_list);
> - if (strcmp(ldev->alias, dssdev->alias) > 0)
> - break;
> - }
> - list_add_tail(>panel_list, cur);
> + list_add_tail(>panel_list, _list);
> mutex_unlock(_list_mutex);
> return 0;
> }
> diff --git a/drivers/gpu/drm/omapdrm/dss/omapdss.h
> b/drivers/gpu/drm/omapdrm/dss/omapdss.h
> index eae105b0b961..8d530057a4b9 100644
> --- a/drivers/gpu/drm/omapdrm/dss/omapdss.h
> +++ b/drivers/gpu/drm/omapdrm/dss/omapdss.h
> @@ -465,8 +465,6 @@ struct omap_dss_device {
>
> struct list_head panel_list;
>
> - /* alias in the form of "display%d" */
> - char alias[16];
> unsigned int alias_id;
>
> enum omap_display_type type;
> --
> Regards,
>
> Laurent Pinchart
>
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
signature.asc
Description: PGP signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2] gpu: drm: omapdrm: Adding new typedef vm_fault_t
On Fri, Jun 8, 2018 at 11:47 AM, Tomi Valkeinen wrote:
> Hi,
>
> On 22/05/18 21:13, Souptick Joarder wrote:
>> Use new return type vm_fault_t for fault handler. For
>> now, this is just documenting that the function returns
>> a VM_FAULT value rather than an errno. Once all instances
>> are converted, vm_fault_t will become a distinct type.
>>
>> Ref-> commit 1c8f422059ae ("mm: change return type to vm_fault_t")
>>
>> Previously vm_insert_mixed() returns err which driver
>> mapped into VM_FAULT_* type. Also return value of
>> vm_insert_mixed() not handled correctly and 0 was
>> returned inside fault_2d() as default. The new function
>> vmf_insert_mixed() will replace this inefficiency by
>> returning correct VM_FAULT_* type.
>>
>> vmf_error() is the newly introduce inline function
>> in 4.17-rc6.
>>
>> Signed-off-by: Souptick Joarder
>> Reviewed-by: Matthew Wilcox
>> ---
>> v2: Fixed kbuild error by initialized ret
>> in fault_2d().
>>
>> drivers/gpu/drm/omapdrm/omap_gem.c | 51
>> +-
>> drivers/gpu/drm/omapdrm/omap_gem.h | 3 ++-
>> 2 files changed, 25 insertions(+), 29 deletions(-)
>
> Reviewed-by: Tomi Valkeinen
>
> It's too late to get this to 4.18 via my normal routes. If you have
> other similar patches queued and Linus/maintainers are ok to merge this
> late, feel free to queue this that way.
>
> Otherwise I can pick this up for my 4.19 patches.
>
4.19 looks ok. In case, we have pushed this patch into 4.18-rc-x along
with few others, will notify you.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 106879] Ugly bug present in kernels 4.14, 4.15, 4.16, 4.17
https://bugs.freedesktop.org/show_bug.cgi?id=106879 Bug ID: 106879 Summary: Ugly bug present in kernels 4.14, 4.15, 4.16, 4.17 Product: DRI Version: unspecified Hardware: x86-64 (AMD64) OS: Linux (All) Status: NEW Severity: major Priority: medium Component: DRM/AMDgpu Assignee: dri-devel@lists.freedesktop.org Reporter: javier.castillo.alci...@gmail.com Hi, I'm running Manjaro Linux over the following HW: $ inxi -Fx System:Host: hpzbook Kernel: 4.9.94-1-MANJARO x86_64 bits: 64 compiler: gcc v: 7.3.1 Desktop: KDE Plasma 5.12.4 (Qt 5.10.1) Distro: Manjaro Linux 17.1.8 Hakoila Machine: Type: Laptop System: HP product: HP ZBook 14u G5 v: N/A serial: N/A Mobo: HP model: 83B2 v: KBC Version 04.45.00 serial: N/A UEFI: HP v: Q78 Ver. 01.00.05 date: 01/25/2018 Battery: ID-1: BAT0 charge: 49.8 Wh condition: 49.8/49.8 Wh (100%) model: Hewlett-Packard Primary status: Full CPU: Topology: Quad Core model: Intel Core i7-8550U type: MT MCP arch: Kaby Lake rev: 10 L2 cache: 8192 KiB flags: lm nx pae sse sse2 sse3 sse4_1 sse4_2 ssse3 vmx bogomips: 31880 Speed: 784 MHz min/max: 400/4000 MHz Core speeds (MHz): 1: 784 2: 787 3: 797 4: 795 5: 800 6: 800 7: 799 8: 799 Graphics: Card-1: Intel UHD Graphics 620 driver: i915 v: kernel bus ID: 00:02.0 Card-2: Advanced Micro Devices [AMD/ATI] Lexa XT [Radeon PRO WX 3100] driver: N/A bus ID: 01:00.0 Display Server: x11 (X.Org 1.19.6) driver: modesetting unloaded: fbdev,intel,vesa resolution: 1920x1080~60Hz OpenGL: renderer: Mesa DRI Intel UHD Graphics 620 (Kabylake GT2) v: 4.5 Mesa 18.0.0 direct render: Yes With this HW, everytime I close the laptop lid, the system enters into suspension mode, and an AMDBUG pops up: jun 11 07:21:47 hpzbook kernel: IP: smu7_populate_single_firmware_entry.isra.4+0x55/0xd0 [amdgpu] jun 11 07:21:47 hpzbook kernel: PGD 82ed15067 P4D 82ed15067 PUD 0 jun 11 07:21:47 hpzbook kernel: Oops: 0002 [#1] PREEMPT SMP PTI jun 11 07:21:47 hpzbook kernel: Modules linked in: nf_conntrack_netbios_ns nf_conntrack_broadcast xt_CT ccm fuse rfcomm xt_CHECKSUM ipt_MASQUERADE nf_nat_masquerade_ipv4 tun xt_tcpudp ip6t_rpfilter ip6t_REJECT nf_reject_ipv6 ipt_REJECT nf_reject_ipv4 xt_conntrack ip_set nfnetlink ebtable_nat ebtable_broute bridge stp llc ip6table_nat nf_conntrack_ipv6 nf_defrag_ipv6 nf_nat_ipv6 ip6table_mangle ip6table_raw ip6table_security devlink iptable_nat nf_conntrack_ipv4 nf_defrag_ipv4 nf_nat_ipv4 nf_nat nf_conntrack libcrc32c iptable_mangle iptable_raw iptable_security snd_hda_codec_hdmi bnep snd_hda_codec_conexant snd_hda_codec_generic uvcvideo btusb btrtl videobuf2_vmalloc btbcm videobuf2_memops btintel videobuf2_v4l2 bluetooth videobuf2_core videodev ebtable_filter ebtables media ecdh_generic ip6table_filter ip6_tables iptable_filter jun 11 07:21:47 hpzbook kernel: joydev mousedev hp_wmi sparse_keymap wmi_bmof snd_soc_skl arc4 snd_soc_skl_ipc iTCO_wdt iTCO_vendor_support mei_wdt snd_soc_sst_ipc hid_multitouch snd_soc_sst_dsp snd_hda_ext_core snd_soc_sst_match snd_soc_core snd_compress snd_pcm_dmaengine ac97_bus tpm_crb amdkfd amd_iommu_v2 intel_rapl nls_iso8859_1 x86_pkg_temp_thermal iwlmvm intel_powerclamp coretemp nls_cp437 mac80211 amdgpu kvm_intel vfat fat i915 kvm iwlwifi irqbypass crct10dif_pclmul crc32_pclmul ghash_clmulni_intel pcbc snd_hda_intel snd_hda_codec cfg80211 aesni_intel aes_x86_64 crypto_simd glue_helper cryptd snd_hda_core intel_cstate ttm intel_rapl_perf snd_hwdep i2c_algo_bit snd_pcm e1000e pcspkr drm_kms_helper rfkill psmouse snd_timer evdev input_leds led_class mac_hid snd ptp soundcore pps_core i2c_i801 drm mei_me shpchp jun 11 07:21:47 hpzbook kernel: mei idma64 intel_gtt agpgart intel_lpss_pci ucsi_acpi intel_lpss typec_ucsi syscopyarea processor_thermal_device sysfillrect intel_pch_thermal sysimgblt int3400_thermal int3403_thermal fb_sys_fops intel_soc_dts_iosf typec i2c_hid wmi battery thermal int340x_thermal_zone acpi_thermal_rel tpm_tis tpm_tis_core video tpm button ac pinctrl_sunrisepoint pinctrl_intel acpi_pad hp_wireless sch_fq_codel uinput pci_stub vboxpci(O) vboxnetflt(O) vboxnetadp(O) vboxdrv(O) crypto_user ip_tables x_tables ext4 crc32c_generic crc16 mbcache jbd2 fscrypto hid_generic usbhid hid serio_raw atkbd libps2 xhci_pci crc32c_intel xhci_hcd nvme nvme_core usbcore usb_common i8042 serio jun 11 07:21:47 hpzbook kernel: CPU: 1 PID: 168 Comm: kworker/1:2 Tainted: G O4.14.48-2-MANJARO #1 jun 11 07:21:47 hpzbook kernel: Hardware name: HP HP ZBook 14u G5/83B2, BIOS Q78 Ver. 01.00.05 01/25/2018 jun 11 07:21:47 hpzbook kernel: Workqueue: pm pm_runtime_work jun 11 07:21:47 hpzbook kernel: task: 94baa93ce900 task.stack: bb8b4397 jun 11 07:21:47 hpzbook kernel: RIP:
[Bug 106877] The game Rise of the Tomb Raider lead to GPU hang when I try in same place jump into the hole.
https://bugs.freedesktop.org/show_bug.cgi?id=106877 Michel Dänzer changed: What|Removed |Added Component|DRM/AMDgpu |Drivers/Gallium/radeonsi QA Contact||dri-devel@lists.freedesktop ||.org Product|DRI |Mesa Version|XOrg git|git -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 198713] AMD DC crashes when computing clocks/detecting freesync
https://bugzilla.kernel.org/show_bug.cgi?id=198713 Nicholas Johnson (nicholas.john...@outlook.com.au) changed: What|Removed |Added CC||nicholas.john...@outlook.co ||m.au --- Comment #4 from Nicholas Johnson (nicholas.john...@outlook.com.au) --- I did not find this when posting my bug. This might be the same thing. Except mine is two whole kernel versions newer, and it is still doing it. AMD do not seem to be taking Linux seriously https://bugzilla.kernel.org/show_bug.cgi?id=199917 Could somebody who knows the ropes around here poke the AMD driver team for us? Thank you! -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v7 0/6] Add ChromeOS EC CEC Support
Hi Lee, On 11/06/2018 08:03, Lee Jones wrote: > On Fri, 08 Jun 2018, Hans Verkuil wrote: >> On 08/06/18 10:17, Neil Armstrong wrote: >>> On 08/06/2018 09:53, Hans Verkuil wrote: On 06/01/2018 10:19 AM, Neil Armstrong wrote: > Hi All, > > The new Google "Fizz" Intel-based ChromeOS device is gaining CEC support > through it's Embedded Controller, to enable the Linux CEC Core to > communicate > with it and get the CEC Physical Address from the correct HDMI Connector, > the > following must be added/changed: > - Add the CEC sub-device registration in the ChromeOS EC MFD Driver > - Add the CEC related commands and events definitions into the EC MFD > driver > - Add a way to get a CEC notifier with it's (optional) connector name > - Add the CEC notifier to the i915 HDMI driver > - Add the proper ChromeOS EC CEC Driver > > The CEC notifier with the connector name is the tricky point, since even > on > Device-Tree platforms, there is no way to distinguish between multiple > HDMI > connectors from the same DRM driver. The solution I implemented is pretty > simple and only adds an optional connector name to eventually distinguish > an HDMI connector notifier from another if they share the same device. This looks good to me, which brings me to the next question: how to merge this? It touches on three subsystems (media, drm, mfd), so that makes this tricky. I think there are two options: either the whole series goes through the media tree, or patches 1+2 go through drm and 3-6 through media. If there is a high chance of conflicts in the mfd code, then it is also an option to have patches 3-6 go through the mfd subsystem. >>> >>> I think patches 3-6 should go in the mfd tree, Lee is used to handle this, >>> then I think the rest could go in the media tree. >>> >>> Lee, do you think it would be possible to have an immutable branch with >>> patches 3-6 ? >>> >>> Could we have an immutable branch from media tree with patch 1 to be merged >>> in >>> the i915 tree for patch 2 ? >>> >>> Or patch 1+2 could me merged into the i915 tree and generate an immutable >>> branch >> >> I think patches 1+2 can just go to the i915 tree. The i915 driver changes >> often, >> so going through that tree makes sense. The cec-notifier code is unlikely to >> change, >> and I am fine with that patch going through i915. >> >>> for media to merge the mfd branch + patch 7 ? >> >> Patch 7? I only count 6? >> >> If 1+2 go through drm and 3-6 go through mfd, then media isn't affected at >> all. >> There is chance of a conflict when this is eventually pushed to mainline for >> the media Kconfig, but that's all. > > What are the *build* dependencies within the set? Here are the hard the build dependency : Patch 2 depends on Patch 1 Patch 5 depends on Patch 4 Patch 6 depends on Patches 1 & 4 > > I'd be happy to send out a pull-request for either all of the patches, > or just the MFD changes once I've had chance to review them. > Great, thanks ! Neil ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 106877] The game Rise of the Tomb Raider lead to GPU hang when I try in same place jump into the hole.
https://bugs.freedesktop.org/show_bug.cgi?id=106877 Samuel Pitoiset changed: What|Removed |Added Component|Drivers/Gallium/radeonsi|Drivers/Vulkan/radeon QA Contact|dri-devel@lists.freedesktop |mesa-dev@lists.freedesktop. |.org|org Assignee|dri-devel@lists.freedesktop |mesa-dev@lists.freedesktop. |.org|org --- Comment #1 from Samuel Pitoiset --- AFAIK, RoTR only supports Vulkan. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 106870] [Raven Ridge occasionally hangs] VM_L2_PROTECTION_FAULT_STATUS:0x00000000
https://bugs.freedesktop.org/show_bug.cgi?id=106870 --- Comment #1 from Michel Dänzer --- The attached dmesg looks like bug 106418. Other than that, per https://bugs.freedesktop.org/show_bug.cgi?id=105251#c9 , try the latest microcode files from https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git/tree/amdgpu and make sure LLVM is version >= 6. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 106418] kernel BUG at drivers/dma-buf/reservation.c:234!
https://bugs.freedesktop.org/show_bug.cgi?id=106418 Michel Dänzer changed: What|Removed |Added CC||ckoenig.leichtzumerken@gmai ||l.com --- Comment #2 from Michel Dänzer --- Christian, could this be related to commit a35f2f34b5b4 "dma-buf: make returning the exclusive fence optional", or do you have other ideas? I'm now running into this BUG fairly often, roughly every other daily piglit run on amd-staging-drm-next. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 106871] Screen with blank cursor (raven ridge on MSI B350)
https://bugs.freedesktop.org/show_bug.cgi?id=106871 Michel Dänzer changed: What|Removed |Added Attachment #140110|text/x-log |text/plain mime type|| -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 106871] Screen with blank cursor (raven ridge on MSI B350)
https://bugs.freedesktop.org/show_bug.cgi?id=106871 Michel Dänzer changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |NOTOURBUG --- Comment #1 from Michel Dänzer --- The Debian kernel packages don't enable CONFIG_DRM_AMD_DC_DCN1_0, so the amdgpu driver doesn't have display support for your GPU. Please report this in the Debian bug tracker. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC v3 0/8] Add Plane Color Properties
Hi Uma, Any progress on userspace for this? I was thinking on working on using this in drm_hwcomposer. Thank you, Alex Gheorghe On Fri, Mar 09, 2018 at 11:47:41PM +0530, Uma Shankar wrote: > This patch series adds properties for plane color features. It adds > properties for degamma used to linearize data, CSC used for gamut > conversion, and gamma used to again non-linearize data as per panel > supported color space. These can be utilize by user space to convert > planes from one format to another, one color space to another etc. > > Usersapce can take smart blending decisions and utilize these hardware > supported plane color features to get accurate color profile. The same > can help in consistent color quality from source to panel taking > advantage of advanced color features in hardware. > > These patches just add the property interfaces and enable helper > functions. > > This series adds Intel Gen9 specific plane gamma feature. We can > build up and add other platform/hardware specific implementation > on top of this series > > Note: This is just to get a design feedback whether these interfaces > look ok. Based on community feedback on interfaces, we will implement > IGT tests to validate plane color features. This is un-tested currently. > Also, userspace implementation to use these properties is currently not > available. > > v2: Dropped legacy gamma table for plane as suggested by Maarten. Added > Gen9/BDW plane gamma feature and rebase on tot. > > v3: Added a new drm_color_lut_ext structure to accommodate 32 bit precision > entries, pointed to by Brian, Starkey for HDR usecases. Addressed Sean,Paul > comments and moved plane color properties to drm_plane instead of > mode_config. Added property documentation as suggested by Daniel, Vetter. > Fixed a rebase fumble which occurred in v2, pointed by Emil Velikov. > > Uma Shankar (8): > drm: Add Enhanced Gamma LUT precision structure > drm: Add Plane Degamma properties > drm: Add Plane CTM property > drm: Add Plane Gamma properties > drm: Define helper function for plane color enabling > drm/i915: Enable plane color features > drm/i915: Implement Plane Gamma for Bdw and Gen9 platforms > drm/i915: Load plane color luts from atomic flip > > Documentation/gpu/drm-kms.rst | 18 > drivers/gpu/drm/drm_atomic.c | 30 +++ > drivers/gpu/drm/drm_atomic_helper.c | 12 +++ > drivers/gpu/drm/drm_plane.c | 131 > ++ > drivers/gpu/drm/i915/i915_drv.h | 5 ++ > drivers/gpu/drm/i915/i915_pci.c | 5 +- > drivers/gpu/drm/i915/i915_reg.h | 24 ++ > drivers/gpu/drm/i915/intel_atomic_plane.c | 4 + > drivers/gpu/drm/i915/intel_color.c| 80 ++ > drivers/gpu/drm/i915/intel_device_info.h | 5 ++ > drivers/gpu/drm/i915/intel_display.c | 4 + > drivers/gpu/drm/i915/intel_drv.h | 10 +++ > drivers/gpu/drm/i915/intel_sprite.c | 4 + > include/drm/drm_color_mgmt.h | 5 ++ > include/drm/drm_plane.h | 66 +++ > include/uapi/drm/drm_mode.h | 15 > 16 files changed, 417 insertions(+), 1 deletion(-) > > -- > 1.9.1 > > ___ > dri-devel mailing list > dri-devel@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/dri-devel -- Cheers, Alex G ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v7 0/6] Add ChromeOS EC CEC Support
On 11/06/18 10:56, Neil Armstrong wrote: > Hi Lee, > > On 11/06/2018 08:03, Lee Jones wrote: >> On Fri, 08 Jun 2018, Hans Verkuil wrote: >>> On 08/06/18 10:17, Neil Armstrong wrote: On 08/06/2018 09:53, Hans Verkuil wrote: > On 06/01/2018 10:19 AM, Neil Armstrong wrote: >> Hi All, >> >> The new Google "Fizz" Intel-based ChromeOS device is gaining CEC support >> through it's Embedded Controller, to enable the Linux CEC Core to >> communicate >> with it and get the CEC Physical Address from the correct HDMI >> Connector, the >> following must be added/changed: >> - Add the CEC sub-device registration in the ChromeOS EC MFD Driver >> - Add the CEC related commands and events definitions into the EC MFD >> driver >> - Add a way to get a CEC notifier with it's (optional) connector name >> - Add the CEC notifier to the i915 HDMI driver >> - Add the proper ChromeOS EC CEC Driver >> >> The CEC notifier with the connector name is the tricky point, since even >> on >> Device-Tree platforms, there is no way to distinguish between multiple >> HDMI >> connectors from the same DRM driver. The solution I implemented is pretty >> simple and only adds an optional connector name to eventually distinguish >> an HDMI connector notifier from another if they share the same device. > > This looks good to me, which brings me to the next question: how to merge > this? > > It touches on three subsystems (media, drm, mfd), so that makes this > tricky. > > I think there are two options: either the whole series goes through the > media tree, or patches 1+2 go through drm and 3-6 through media. If there > is a high chance of conflicts in the mfd code, then it is also an option > to > have patches 3-6 go through the mfd subsystem. I think patches 3-6 should go in the mfd tree, Lee is used to handle this, then I think the rest could go in the media tree. Lee, do you think it would be possible to have an immutable branch with patches 3-6 ? Could we have an immutable branch from media tree with patch 1 to be merged in the i915 tree for patch 2 ? Or patch 1+2 could me merged into the i915 tree and generate an immutable branch >>> >>> I think patches 1+2 can just go to the i915 tree. The i915 driver changes >>> often, >>> so going through that tree makes sense. The cec-notifier code is unlikely >>> to change, >>> and I am fine with that patch going through i915. >>> for media to merge the mfd branch + patch 7 ? >>> >>> Patch 7? I only count 6? >>> >>> If 1+2 go through drm and 3-6 go through mfd, then media isn't affected at >>> all. >>> There is chance of a conflict when this is eventually pushed to mainline for >>> the media Kconfig, but that's all. >> >> What are the *build* dependencies within the set? > > Here are the hard the build dependency : > > Patch 2 depends on Patch 1 > Patch 5 depends on Patch 4 > Patch 6 depends on Patches 1 & 4 Ah, I missed the dependency of patch 6 on patch 1. So the whole series needs to be merged as a single unit. > >> >> I'd be happy to send out a pull-request for either all of the patches, >> or just the MFD changes once I've had chance to review them. >> > > Great, thanks ! > > Neil > I'm OK if this goes through the mfd tree. Regards, Hans ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: RE: [Intel-gfx] DRM Inquiry
Hi Jani, Thanks for the help. I was able to manage your advice on the drm_dp_aux_chardev. Though I still need to learn more about the DRM vs kernel process flow. Like for example, upon changing/adding DRM_DP_AUX_CHARDEV in kernel .config, How did DRM_DP_AUX_CHARDEV was being invoke here? From the code, I notice character device will be created under drm_dp_aux_register_devnode method. For example I made two kernel 4.6 with DRM_DP_AUX_CHARDEV=y and another kernel 4.6 with DRM_DP_AUX_CHARDEV=n. So the steps was to build and install the kernel with DRM_DP_AUX_CHARDEV=y. Once finish, I tried to reboot and verified the /dev/drm_dp_aux_chardev* and it was there. Now, I will change the .config DRM_DP_AUXCHARDEV=n then follow the steps below to manual build the DRM module. I'm not really sure if I'm correct on this one. 1. rm /dev/drm_dp_aux_chardev* 2. make modules_prepare3. make SUBDIRS=scripts/mod4. make SUBDIRS=drivers/gpu/drm modules5. cp drivers/gpu/drm/i915/i915.ko /lib/modules/4.6.0-94.11-default/kernel/drivers/gpu/drm6. ... I copy all .ko under drm to the lib/modules/4.67. depmod8. modprobe i9159. ... I also modprobe all modules10. reboot The result was /dev/drm_dp_aux_chardev* was still there. My expectation was it would disrepair or remove. Please have comments and advice. Regards,John On Saturday, May 26, 2018, 1:14:40 AM GMT+8, Jani Nikula wrote: On Fri, 25 May 2018, "Taylor, Clinton A" wrote: > Looks like the seek=%d in the sprintf is not working. Yeah. Try skip=%d instead. BR, Jani. -- Jani Nikula, Intel Open Source Graphics Center ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 106418] kernel BUG at drivers/dma-buf/reservation.c:234!
https://bugs.freedesktop.org/show_bug.cgi?id=106418 --- Comment #3 from Christian König --- (In reply to Michel Dänzer from comment #2) > Christian, could this be related to commit a35f2f34b5b4 "dma-buf: make > returning the exclusive fence optional", or do you have other ideas? I'm now > running into this BUG fairly often, roughly every other daily piglit run on > amd-staging-drm-next. Good to know, David and I actually already fixed one cause for this. So I assumed that this should do it, but that obviously isn't the case. Any usable way to reproduce the issue? -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 106418] kernel BUG at drivers/dma-buf/reservation.c:234!
https://bugs.freedesktop.org/show_bug.cgi?id=106418 --- Comment #4 from Michel Dänzer --- (In reply to Christian König from comment #3) > Good to know, David and I actually already fixed one cause for this. So I > assumed that this should do it, but that obviously isn't the case. FWIW, I hit it from the CS ioctl at least once, like in bug 106870. Unfortunately, the other recent cases didn't seem to get captured in the log files. > Any usable way to reproduce the issue? Not particularly, I'm afraid. My script just pulls LLVM, xserver, Mesa etc. from Git, builds them and runs piglit. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 50/60] drm/omap: Group CRTC, encoder, connector and dssdev in a structure
Hi,
On Sat, May 26, 2018 at 08:25:08PM +0300, Laurent Pinchart wrote:
> Create an omap_drm_pipeline structure to model display pipelines, made
> of a CRTC, an encoder, a connector and a DSS display device. This allows
> grouping related parameters together instead of storing them in
> independent arrays and thus improves code readability.
>
> Signed-off-by: Laurent Pinchart
> ---
Reviewed-by: Sebastian Reichel
-- Sebastian
> drivers/gpu/drm/omapdrm/omap_crtc.c | 4 +-
> drivers/gpu/drm/omapdrm/omap_drv.c | 144
> +--
> drivers/gpu/drm/omapdrm/omap_drv.h | 20 +++--
> drivers/gpu/drm/omapdrm/omap_fbdev.c | 4 +-
> drivers/gpu/drm/omapdrm/omap_irq.c | 4 +-
> 5 files changed, 84 insertions(+), 92 deletions(-)
>
> diff --git a/drivers/gpu/drm/omapdrm/omap_crtc.c
> b/drivers/gpu/drm/omapdrm/omap_crtc.c
> index c5f1915aef67..f5bf553a862f 100644
> --- a/drivers/gpu/drm/omapdrm/omap_crtc.c
> +++ b/drivers/gpu/drm/omapdrm/omap_crtc.c
> @@ -474,8 +474,8 @@ static void omap_crtc_mode_set_nofb(struct drm_crtc *crtc)
>* has been changed to the DRM model.
>*/
>
> - for (i = 0; i < priv->num_encoders; ++i) {
> - struct drm_encoder *encoder = priv->encoders[i];
> + for (i = 0; i < priv->num_pipes; ++i) {
> + struct drm_encoder *encoder = priv->pipes[i].encoder;
>
> if (encoder->crtc == crtc) {
> struct omap_dss_device *dssdev;
> diff --git a/drivers/gpu/drm/omapdrm/omap_drv.c
> b/drivers/gpu/drm/omapdrm/omap_drv.c
> index 99ed47a17ce3..298d594a0c65 100644
> --- a/drivers/gpu/drm/omapdrm/omap_drv.c
> +++ b/drivers/gpu/drm/omapdrm/omap_drv.c
> @@ -129,9 +129,9 @@ static const struct drm_mode_config_funcs
> omap_mode_config_funcs = {
> .atomic_commit = drm_atomic_helper_commit,
> };
>
> -static int get_connector_type(struct omap_dss_device *dssdev)
> +static int get_connector_type(struct omap_dss_device *display)
> {
> - switch (dssdev->type) {
> + switch (display->type) {
> case OMAP_DISPLAY_TYPE_HDMI:
> return DRM_MODE_CONNECTOR_HDMIA;
> case OMAP_DISPLAY_TYPE_DVI:
> @@ -151,65 +151,65 @@ static int get_connector_type(struct omap_dss_device
> *dssdev)
> }
> }
>
> -static void omap_disconnect_dssdevs(struct drm_device *ddev)
> +static void omap_disconnect_pipelines(struct drm_device *ddev)
> {
> struct omap_drm_private *priv = ddev->dev_private;
> unsigned int i;
>
> - for (i = 0; i < priv->num_dssdevs; i++) {
> - struct omap_dss_device *dssdev = priv->dssdevs[i];
> + for (i = 0; i < priv->num_pipes; i++) {
> + struct omap_dss_device *display = priv->pipes[i].display;
>
> - omapdss_device_disconnect(dssdev, NULL);
> - priv->dssdevs[i] = NULL;
> - omapdss_device_put(dssdev);
> + omapdss_device_disconnect(display, NULL);
> + priv->pipes[i].display = NULL;
> + omapdss_device_put(display);
> }
>
> - priv->num_dssdevs = 0;
> + priv->num_pipes = 0;
> }
>
> -static int omap_compare_dssdevs(const void *a, const void *b)
> +static int omap_compare_pipes(const void *a, const void *b)
> {
> - const struct omap_dss_device *dssdev1 = *(struct omap_dss_device **)a;
> - const struct omap_dss_device *dssdev2 = *(struct omap_dss_device **)b;
> + const struct omap_drm_pipeline *pipe1 = a;
> + const struct omap_drm_pipeline *pipe2 = b;
>
> - if (dssdev1->alias_id > dssdev2->alias_id)
> + if (pipe1->display->alias_id > pipe2->display->alias_id)
> return 1;
> - else if (dssdev1->alias_id < dssdev2->alias_id)
> + else if (pipe1->display->alias_id < pipe2->display->alias_id)
> return -1;
> return 0;
> }
>
> -static int omap_connect_dssdevs(struct drm_device *ddev)
> +static int omap_connect_pipelines(struct drm_device *ddev)
> {
> struct omap_drm_private *priv = ddev->dev_private;
> - struct omap_dss_device *dssdev = NULL;
> + struct omap_dss_device *display = NULL;
> int r;
>
> if (!omapdss_stack_is_ready())
> return -EPROBE_DEFER;
>
> - for_each_dss_display(dssdev) {
> - r = omapdss_device_connect(priv->dss, dssdev, NULL);
> + for_each_dss_display(display) {
> + r = omapdss_device_connect(priv->dss, display, NULL);
> if (r == -EPROBE_DEFER) {
> - omapdss_device_put(dssdev);
> + omapdss_device_put(display);
> goto cleanup;
> } else if (r) {
> - dev_warn(dssdev->dev, "could not connect display: %s\n",
> - dssdev->name);
> + dev_warn(display->dev, "could not connect display:
> %s\n",
> + display->name);
> } else {
> - omapdss_device_get(dssdev);
>
Re: RE: [Intel-gfx] DRM Inquiry
On Mon, 11 Jun 2018, John Sledge wrote: > Thanks for the help. I was able to manage your advice on the > drm_dp_aux_chardev. Though I still need to learn more about the DRM vs > kernel process flow. Like for example, upon changing/adding > DRM_DP_AUX_CHARDEV in kernel .config, How did DRM_DP_AUX_CHARDEV was > being invoke here? From the code, I notice character device will be > created under drm_dp_aux_register_devnode method. > For example I made two kernel 4.6 with DRM_DP_AUX_CHARDEV=y and > another kernel 4.6 with DRM_DP_AUX_CHARDEV=n. > So the steps was to build and install the kernel with > DRM_DP_AUX_CHARDEV=y. Once finish, I tried to reboot and verified the > /dev/drm_dp_aux_chardev* and it was there. > Now, I will change the .config DRM_DP_AUXCHARDEV=n then follow the > steps below to manual build the DRM module. I'm not really sure if I'm > correct on this one. Why are you disabling it again? Just enable the config, use the resulting kernel, and do the rest in userspace. > 1. rm /dev/drm_dp_aux_chardev* 2. make modules_prepare3. make > SUBDIRS=scripts/mod4. make SUBDIRS=drivers/gpu/drm modules5. cp > drivers/gpu/drm/i915/i915.ko > /lib/modules/4.6.0-94.11-default/kernel/drivers/gpu/drm6. ... I copy > all .ko under drm to the lib/modules/4.67. depmod8. modprobe > i9159. ... I also modprobe all modules10. reboot > The result was /dev/drm_dp_aux_chardev* was still there. My > expectation was it would disrepair or remove. Don't do this. I don't understand what you're trying to do. > Please have comments and advice. Please explain what you're trying to do to begin with. What's your end goal? BR, Jani. PS. Please prefer plain text instead of html on the list. -- Jani Nikula, Intel Open Source Graphics Center ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 51/60] drm/omap: Reverse direction of DSS device (dis)connect operations
Hi,
On Sat, May 26, 2018 at 08:25:09PM +0300, Laurent Pinchart wrote:
> The omapdrm and omapdss drivers are architectured based on display
> pipelines made of multiple components handled from sink (display) to
> source (DSS output). This is incompatible with the DRM bridge and panel
> APIs that handle components from source to sink.
>
> To reconcile the omapdrm and omapdss drivers with the DRM bridge and
> panel model, we need to reverse the direction of the DSS device
> operations. Start with the connect and disconnect operations.
>
> Signed-off-by: Laurent Pinchart
> ---
Looks mostly good, but I found one issue:
[...]
> -static void dsicm_disconnect(struct omap_dss_device *dssdev)
> +static void dsicm_disconnect(struct omap_dss_device *src,
> + struct omap_dss_device *dst)
> {
> - struct panel_drv_data *ddata = to_panel_data(dssdev);
> - struct omap_dss_device *src = dssdev->src;
> + struct panel_drv_data *ddata = to_panel_data(dst);
>
> src->ops->dsi.release_vc(src, ddata->channel);
^^^ using src in dsicm_disconnect()
> - omapdss_device_disconnect(src, dssdev);
> -
> - omapdss_device_put(src);
> }
>
> static int dsicm_enable(struct omap_dss_device *dssdev)
> @@ -1404,7 +1382,7 @@ static int __exit dsicm_remove(struct platform_device
> *pdev)
> omapdss_device_unregister(dssdev);
>
> dsicm_disable(dssdev);
> - dsicm_disconnect(dssdev);
> + dsicm_disconnect(NULL, dssdev);
^^^ calling dsicm_disconnect() with src=NULL
This will execute dsi_release_vc(NULL, channel), which will try to
dereference NULL.
-- Sebastian
signature.asc
Description: PGP signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 52/60] drm/omap: dss: Move connection checks to omapdss_device_(dis)connect
Hi,
On Sat, May 26, 2018 at 08:25:10PM +0300, Laurent Pinchart wrote:
> When a DSS output is (dis)connected the omapdss_output_(un)set_device()
> function performs a sanity check to ensure that the output isn't already
> (dis)connected. The check is unnecessary as those situations should
> never happen, but can nonetheless be useful to catch driver bugs. To
> prepare for removal of the omapdss_output_(un)set_device() functions
> move the connection check to the omapdss_device_connect() function. The
> omapdss_device_disconnect() already contains a corresponding check.
>
> Signed-off-by: Laurent Pinchart
> ---
Reviewed-by: Sebastian Reichel
-- Sebastian
> drivers/gpu/drm/omapdrm/dss/base.c | 1 +
> drivers/gpu/drm/omapdrm/dss/output.c | 29 ++---
> 2 files changed, 3 insertions(+), 27 deletions(-)
>
> diff --git a/drivers/gpu/drm/omapdrm/dss/base.c
> b/drivers/gpu/drm/omapdrm/dss/base.c
> index 7f41c541397b..3afb3d574a7b 100644
> --- a/drivers/gpu/drm/omapdrm/dss/base.c
> +++ b/drivers/gpu/drm/omapdrm/dss/base.c
> @@ -209,6 +209,7 @@ int omapdss_device_connect(struct dss_device *dss,
> }
>
> if (src) {
> + WARN_ON(src->dst);
> dst->src = src;
> src->dst = dst;
> }
> diff --git a/drivers/gpu/drm/omapdrm/dss/output.c
> b/drivers/gpu/drm/omapdrm/dss/output.c
> index 2f7a019d059e..96d74218cf91 100644
> --- a/drivers/gpu/drm/omapdrm/dss/output.c
> +++ b/drivers/gpu/drm/omapdrm/dss/output.c
> @@ -29,61 +29,36 @@ static DEFINE_MUTEX(output_lock);
> int omapdss_output_set_device(struct omap_dss_device *out,
> struct omap_dss_device *dssdev)
> {
> - int r;
> + int r = 0;
>
> mutex_lock(_lock);
>
> - if (out->dst) {
> - dev_err(out->dev,
> - "output already has device %s connected to it\n",
> - out->dst->name);
> - r = -EINVAL;
> - goto err;
> - }
> -
> if (out->output_type != dssdev->type) {
> dev_err(out->dev, "output type and display type don't match\n");
> r = -EINVAL;
> - goto err;
> }
>
> mutex_unlock(_lock);
>
> - return 0;
> -err:
> - mutex_unlock(_lock);
> -
> return r;
> }
> EXPORT_SYMBOL(omapdss_output_set_device);
>
> int omapdss_output_unset_device(struct omap_dss_device *out)
> {
> - int r;
> + int r = 0;
>
> mutex_lock(_lock);
>
> - if (!out->dst) {
> - dev_err(out->dev,
> - "output doesn't have a device connected to it\n");
> - r = -EINVAL;
> - goto err;
> - }
> -
> if (out->dst->state != OMAP_DSS_DISPLAY_DISABLED) {
> dev_err(out->dev,
> "device %s is not disabled, cannot unset device\n",
> out->dst->name);
> r = -EINVAL;
> - goto err;
> }
>
> mutex_unlock(_lock);
>
> - return 0;
> -err:
> - mutex_unlock(_lock);
> -
> return r;
> }
> EXPORT_SYMBOL(omapdss_output_unset_device);
> --
> Regards,
>
> Laurent Pinchart
>
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
signature.asc
Description: PGP signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 53/60] drm/omap: dss: Move display type validation to initialization time
Hi,
On Sat, May 26, 2018 at 08:25:11PM +0300, Laurent Pinchart wrote:
> The display type is validated when the display is connected to the DSS
> output. We already have all the information we need for validation when
> initializing the outputs. Move validation to output initialization to
> simplify pipeline connection handling.
>
> Signed-off-by: Laurent Pinchart
> ---
Reviewed-by: Sebastian Reichel
-- Sebastian
> drivers/gpu/drm/omapdrm/dss/dpi.c | 25 +++--
> drivers/gpu/drm/omapdrm/dss/dsi.c | 25 +++--
> drivers/gpu/drm/omapdrm/dss/hdmi4.c | 25 +++--
> drivers/gpu/drm/omapdrm/dss/hdmi5.c | 25 +++--
> drivers/gpu/drm/omapdrm/dss/omapdss.h | 3 +--
> drivers/gpu/drm/omapdrm/dss/output.c | 17 +
> drivers/gpu/drm/omapdrm/dss/sdi.c | 25 +++--
> drivers/gpu/drm/omapdrm/dss/venc.c| 25 +++--
> 8 files changed, 72 insertions(+), 98 deletions(-)
>
> diff --git a/drivers/gpu/drm/omapdrm/dss/dpi.c
> b/drivers/gpu/drm/omapdrm/dss/dpi.c
> index dc50a220382c..831de09770a3 100644
> --- a/drivers/gpu/drm/omapdrm/dss/dpi.c
> +++ b/drivers/gpu/drm/omapdrm/dss/dpi.c
> @@ -620,24 +620,13 @@ static int dpi_connect(struct omap_dss_device *src,
> if (r)
> return r;
>
> - r = omapdss_output_set_device(dst, dst->next);
> + r = omapdss_device_connect(dst->dss, dst, dst->next);
> if (r) {
> - DSSERR("failed to connect output to new device: %s\n",
> - dst->name);
> - goto err_mgr_disconnect;
> + dss_mgr_disconnect(dst);
> + return r;
> }
>
> - r = omapdss_device_connect(dst->dss, dst, dst->next);
> - if (r)
> - goto err_output_unset;
> -
> return 0;
> -
> -err_output_unset:
> - omapdss_output_unset_device(dst);
> -err_mgr_disconnect:
> - dss_mgr_disconnect(dst);
> - return r;
> }
>
> static void dpi_disconnect(struct omap_dss_device *src,
> @@ -664,6 +653,7 @@ static int dpi_init_output_port(struct dpi_data *dpi,
> struct device_node *port)
> {
> struct omap_dss_device *out = >output;
> u32 port_num = 0;
> + int r;
>
> of_property_read_u32(port, "reg", _num);
> dpi->id = port_num <= 2 ? port_num : 0;
> @@ -696,6 +686,13 @@ static int dpi_init_output_port(struct dpi_data *dpi,
> struct device_node *port)
> return PTR_ERR(out->next);
> }
>
> + r = omapdss_output_validate(out);
> + if (r) {
> + omapdss_device_put(out->next);
> + out->next = NULL;
> + return r;
> + }
> +
> omapdss_device_register(out);
>
> return 0;
> diff --git a/drivers/gpu/drm/omapdrm/dss/dsi.c
> b/drivers/gpu/drm/omapdrm/dss/dsi.c
> index a5516d6e8017..53a32e20c3bd 100644
> --- a/drivers/gpu/drm/omapdrm/dss/dsi.c
> +++ b/drivers/gpu/drm/omapdrm/dss/dsi.c
> @@ -4890,24 +4890,13 @@ static int dsi_connect(struct omap_dss_device *src,
> if (r)
> return r;
>
> - r = omapdss_output_set_device(dst, dst->next);
> + r = omapdss_device_connect(dst->dss, dst, dst->next);
> if (r) {
> - DSSERR("failed to connect output to new device: %s\n",
> - dst->name);
> - goto err_mgr_disconnect;
> + dss_mgr_disconnect(dst);
> + return r;
> }
>
> - r = omapdss_device_connect(dst->dss, dst, dst->next);
> - if (r)
> - goto err_output_unset;
> -
> return 0;
> -
> -err_output_unset:
> - omapdss_output_unset_device(dst);
> -err_mgr_disconnect:
> - dss_mgr_disconnect(dst);
> - return r;
> }
>
> static void dsi_disconnect(struct omap_dss_device *src,
> @@ -5147,6 +5136,7 @@ static const struct component_ops dsi_component_ops = {
> static int dsi_init_output(struct dsi_data *dsi)
> {
> struct omap_dss_device *out = >output;
> + int r;
>
> out->dev = dsi->dev;
> out->id = dsi->module_id == 0 ?
> @@ -5166,6 +5156,13 @@ static int dsi_init_output(struct dsi_data *dsi)
> return PTR_ERR(out->next);
> }
>
> + r = omapdss_output_validate(out);
> + if (r) {
> + omapdss_device_put(out->next);
> + out->next = NULL;
> + return r;
> + }
> +
> omapdss_device_register(out);
>
> return 0;
> diff --git a/drivers/gpu/drm/omapdrm/dss/hdmi4.c
> b/drivers/gpu/drm/omapdrm/dss/hdmi4.c
> index 9f883669e71b..22f8b74f5bf5 100644
> --- a/drivers/gpu/drm/omapdrm/dss/hdmi4.c
> +++ b/drivers/gpu/drm/omapdrm/dss/hdmi4.c
> @@ -437,24 +437,13 @@ static int hdmi_connect(struct omap_dss_device *src,
> if (r)
> return r;
>
> - r = omapdss_output_set_device(dst, dst->next);
> + r = omapdss_device_connect(dst->dss, dst, dst->next);
> if (r) {
> - DSSERR("failed to connect
Re: [PATCH v2 55/60] drm/omap: Pass pipe pointer to omap_crtc_init()
Hi,
On Sat, May 26, 2018 at 08:25:13PM +0300, Laurent Pinchart wrote:
> Replace the dss display device pointer by a pipe pointer that will allow
> the omap_crtc_init() function to access both the display and the DSS
> output. As a result we can remove the omapdss_device_get_dispc_channel()
> function that is now unneeded.
>
> Signed-off-by: Laurent Pinchart
> ---
Reviewed-by: Sebastian Reichel
-- Sebastian
> drivers/gpu/drm/omapdrm/dss/base.c| 9 -
> drivers/gpu/drm/omapdrm/dss/omapdss.h | 1 -
> drivers/gpu/drm/omapdrm/omap_crtc.c | 7 ---
> drivers/gpu/drm/omapdrm/omap_crtc.h | 4 +++-
> drivers/gpu/drm/omapdrm/omap_drv.c| 2 +-
> 5 files changed, 8 insertions(+), 15 deletions(-)
>
> diff --git a/drivers/gpu/drm/omapdrm/dss/base.c
> b/drivers/gpu/drm/omapdrm/dss/base.c
> index fbb600d49ad2..cce09a48d769 100644
> --- a/drivers/gpu/drm/omapdrm/dss/base.c
> +++ b/drivers/gpu/drm/omapdrm/dss/base.c
> @@ -247,15 +247,6 @@ void omapdss_device_disconnect(struct omap_dss_device
> *src,
> }
> EXPORT_SYMBOL_GPL(omapdss_device_disconnect);
>
> -enum omap_channel omapdss_device_get_dispc_channel(struct omap_dss_device
> *dssdev)
> -{
> - while (dssdev->src)
> - dssdev = dssdev->src;
> -
> - return dssdev->dispc_channel;
> -}
> -EXPORT_SYMBOL(omapdss_device_get_dispc_channel);
> -
> /*
> -
> * Components Handling
> */
> diff --git a/drivers/gpu/drm/omapdrm/dss/omapdss.h
> b/drivers/gpu/drm/omapdrm/dss/omapdss.h
> index 672761b5b017..d7084ca36d0e 100644
> --- a/drivers/gpu/drm/omapdrm/dss/omapdss.h
> +++ b/drivers/gpu/drm/omapdrm/dss/omapdss.h
> @@ -509,7 +509,6 @@ int omapdss_device_connect(struct dss_device *dss,
> struct omap_dss_device *dst);
> void omapdss_device_disconnect(struct omap_dss_device *src,
> struct omap_dss_device *dst);
> -enum omap_channel omapdss_device_get_dispc_channel(struct omap_dss_device
> *dssdev);
>
> int omap_dss_get_num_overlay_managers(void);
>
> diff --git a/drivers/gpu/drm/omapdrm/omap_crtc.c
> b/drivers/gpu/drm/omapdrm/omap_crtc.c
> index f5bf553a862f..f5bdb8de98f4 100644
> --- a/drivers/gpu/drm/omapdrm/omap_crtc.c
> +++ b/drivers/gpu/drm/omapdrm/omap_crtc.c
> @@ -693,7 +693,8 @@ void omap_crtc_pre_uninit(struct omap_drm_private *priv)
>
> /* initialize crtc */
> struct drm_crtc *omap_crtc_init(struct drm_device *dev,
> - struct drm_plane *plane, struct omap_dss_device *dssdev)
> + struct omap_drm_pipeline *pipe,
> + struct drm_plane *plane)
> {
> struct omap_drm_private *priv = dev->dev_private;
> struct drm_crtc *crtc = NULL;
> @@ -701,7 +702,7 @@ struct drm_crtc *omap_crtc_init(struct drm_device *dev,
> enum omap_channel channel;
> int ret;
>
> - channel = omapdss_device_get_dispc_channel(dssdev);
> + channel = pipe->output->dispc_channel;
>
> DBG("%s", channel_names[channel]);
>
> @@ -724,7 +725,7 @@ struct drm_crtc *omap_crtc_init(struct drm_device *dev,
> _crtc_funcs, NULL);
> if (ret < 0) {
> dev_err(dev->dev, "%s(): could not init crtc for: %s\n",
> - __func__, dssdev->name);
> + __func__, pipe->display->name);
> kfree(omap_crtc);
> return ERR_PTR(ret);
> }
> diff --git a/drivers/gpu/drm/omapdrm/omap_crtc.h
> b/drivers/gpu/drm/omapdrm/omap_crtc.h
> index 1c6530703855..d9de437ba9dd 100644
> --- a/drivers/gpu/drm/omapdrm/omap_crtc.h
> +++ b/drivers/gpu/drm/omapdrm/omap_crtc.h
> @@ -27,6 +27,7 @@ enum omap_channel;
> struct drm_crtc;
> struct drm_device;
> struct drm_plane;
> +struct omap_drm_pipeline;
> struct omap_dss_device;
> struct videomode;
>
> @@ -35,7 +36,8 @@ enum omap_channel omap_crtc_channel(struct drm_crtc *crtc);
> void omap_crtc_pre_init(struct omap_drm_private *priv);
> void omap_crtc_pre_uninit(struct omap_drm_private *priv);
> struct drm_crtc *omap_crtc_init(struct drm_device *dev,
> - struct drm_plane *plane, struct omap_dss_device *dssdev);
> + struct omap_drm_pipeline *pipe,
> + struct drm_plane *plane);
> int omap_crtc_wait_pending(struct drm_crtc *crtc);
> void omap_crtc_error_irq(struct drm_crtc *crtc, u32 irqstatus);
> void omap_crtc_vblank_irq(struct drm_crtc *crtc);
> diff --git a/drivers/gpu/drm/omapdrm/omap_drv.c
> b/drivers/gpu/drm/omapdrm/omap_drv.c
> index dc2f059f8f4d..6bc826515684 100644
> --- a/drivers/gpu/drm/omapdrm/omap_drv.c
> +++ b/drivers/gpu/drm/omapdrm/omap_drv.c
> @@ -308,7 +308,7 @@ static int omap_modeset_init(struct drm_device *dev)
> if (!connector)
> return -ENOMEM;
>
> - crtc = omap_crtc_init(dev, priv->planes[i], display);
> + crtc =
Re: [PATCH v2 54/60] drm/omap: dss: Merge two disconnection helpers
Hi,
On Sat, May 26, 2018 at 08:25:12PM +0300, Laurent Pinchart wrote:
> To simplify the pipeline disconnection handling merge the
> omapdss_device_disconnect() and omapdss_output_unset_device() functions.
> The device state check is now called for every device in the pipeline,
> extending this sanity check coverage.
>
> There is no need to return an error from omapdss_device_disconnect()
> when the check fails, as omapdss_output_unset_device() used to do, given
> that we can't prevent disconnection due to device unbinding (the return
> value of omapdss_output_unset_device() is never checked in the current
> code for that reason).
>
> Signed-off-by: Laurent Pinchart
> ---
Reviewed-by: Sebastian Reichel
-- Sebastian
> drivers/gpu/drm/omapdrm/dss/base.c| 2 ++
> drivers/gpu/drm/omapdrm/dss/dpi.c | 1 -
> drivers/gpu/drm/omapdrm/dss/dsi.c | 1 -
> drivers/gpu/drm/omapdrm/dss/hdmi4.c | 1 -
> drivers/gpu/drm/omapdrm/dss/hdmi5.c | 1 -
> drivers/gpu/drm/omapdrm/dss/omapdss.h | 1 -
> drivers/gpu/drm/omapdrm/dss/output.c | 21 -
> drivers/gpu/drm/omapdrm/dss/sdi.c | 1 -
> drivers/gpu/drm/omapdrm/dss/venc.c| 1 -
> 9 files changed, 2 insertions(+), 28 deletions(-)
>
> diff --git a/drivers/gpu/drm/omapdrm/dss/base.c
> b/drivers/gpu/drm/omapdrm/dss/base.c
> index 3afb3d574a7b..fbb600d49ad2 100644
> --- a/drivers/gpu/drm/omapdrm/dss/base.c
> +++ b/drivers/gpu/drm/omapdrm/dss/base.c
> @@ -236,6 +236,8 @@ void omapdss_device_disconnect(struct omap_dss_device
> *src,
> src->dst = NULL;
> }
>
> + WARN_ON(dst->state != OMAP_DSS_DISPLAY_DISABLED);
> +
> if (dst->driver)
> dst->driver->disconnect(src, dst);
> else
> diff --git a/drivers/gpu/drm/omapdrm/dss/dpi.c
> b/drivers/gpu/drm/omapdrm/dss/dpi.c
> index 831de09770a3..4cf397c9300e 100644
> --- a/drivers/gpu/drm/omapdrm/dss/dpi.c
> +++ b/drivers/gpu/drm/omapdrm/dss/dpi.c
> @@ -633,7 +633,6 @@ static void dpi_disconnect(struct omap_dss_device *src,
> struct omap_dss_device *dst)
> {
> omapdss_device_disconnect(dst, dst->next);
> - omapdss_output_unset_device(dst);
>
> dss_mgr_disconnect(dst);
> }
> diff --git a/drivers/gpu/drm/omapdrm/dss/dsi.c
> b/drivers/gpu/drm/omapdrm/dss/dsi.c
> index 53a32e20c3bd..bc470baa4f5c 100644
> --- a/drivers/gpu/drm/omapdrm/dss/dsi.c
> +++ b/drivers/gpu/drm/omapdrm/dss/dsi.c
> @@ -4903,7 +4903,6 @@ static void dsi_disconnect(struct omap_dss_device *src,
> struct omap_dss_device *dst)
> {
> omapdss_device_disconnect(dst, dst->next);
> - omapdss_output_unset_device(dst);
>
> dss_mgr_disconnect(dst);
> }
> diff --git a/drivers/gpu/drm/omapdrm/dss/hdmi4.c
> b/drivers/gpu/drm/omapdrm/dss/hdmi4.c
> index 22f8b74f5bf5..6616530d5fe6 100644
> --- a/drivers/gpu/drm/omapdrm/dss/hdmi4.c
> +++ b/drivers/gpu/drm/omapdrm/dss/hdmi4.c
> @@ -450,7 +450,6 @@ static void hdmi_disconnect(struct omap_dss_device *src,
> struct omap_dss_device *dst)
> {
> omapdss_device_disconnect(dst, dst->next);
> - omapdss_output_unset_device(dst);
>
> dss_mgr_disconnect(dst);
> }
> diff --git a/drivers/gpu/drm/omapdrm/dss/hdmi5.c
> b/drivers/gpu/drm/omapdrm/dss/hdmi5.c
> index d8592d02a58d..f7e15edc05fc 100644
> --- a/drivers/gpu/drm/omapdrm/dss/hdmi5.c
> +++ b/drivers/gpu/drm/omapdrm/dss/hdmi5.c
> @@ -455,7 +455,6 @@ static void hdmi_disconnect(struct omap_dss_device *src,
> struct omap_dss_device *dst)
> {
> omapdss_device_disconnect(dst, dst->next);
> - omapdss_output_unset_device(dst);
>
> dss_mgr_disconnect(dst);
> }
> diff --git a/drivers/gpu/drm/omapdrm/dss/omapdss.h
> b/drivers/gpu/drm/omapdrm/dss/omapdss.h
> index 7add73a5479a..672761b5b017 100644
> --- a/drivers/gpu/drm/omapdrm/dss/omapdss.h
> +++ b/drivers/gpu/drm/omapdrm/dss/omapdss.h
> @@ -518,7 +518,6 @@ int omap_dss_get_num_overlays(void);
> #define for_each_dss_output(d) \
> while ((d = omapdss_device_get_next(d, false, true)) != NULL)
> int omapdss_output_validate(struct omap_dss_device *out);
> -int omapdss_output_unset_device(struct omap_dss_device *out);
>
> typedef void (*omap_dispc_isr_t) (void *arg, u32 mask);
> int omap_dispc_register_isr(omap_dispc_isr_t isr, void *arg, u32 mask);
> diff --git a/drivers/gpu/drm/omapdrm/dss/output.c
> b/drivers/gpu/drm/omapdrm/dss/output.c
> index be544dd48bf4..2da480be918d 100644
> --- a/drivers/gpu/drm/omapdrm/dss/output.c
> +++ b/drivers/gpu/drm/omapdrm/dss/output.c
> @@ -24,8 +24,6 @@
> #include "dss.h"
> #include "omapdss.h"
>
> -static DEFINE_MUTEX(output_lock);
> -
> int omapdss_output_validate(struct omap_dss_device *out)
> {
> if (out->next && out->output_type != out->next->type) {
> @@ -37,25 +35,6 @@ int omapdss_output_validate(struct omap_dss_device *out)
> }
> EXPORT_SYMBOL(omapdss_output_validate);
>
> -int
Re: [PATCH v2 56/60] drm/omap: Store CRTC lookup by channel table in omap_drm_private
Hi,
On Sat, May 26, 2018 at 08:25:14PM +0300, Laurent Pinchart wrote:
> The omap_crtcs global array is used to store pointers to omap_crtc
> indexed by DISPC channel number, in order to look them up in the dss_mgr
> operations. Store the information in the omap_drm_private structure in
> the form of an array of omap_drm_pipeline pointers.
>
> Signed-off-by: Laurent Pinchart
> ---
Reviewed-by: Sebastian Reichel
-- Sebastian
> drivers/gpu/drm/omapdrm/omap_crtc.c | 22 +-
> drivers/gpu/drm/omapdrm/omap_drv.c | 19 +++
> drivers/gpu/drm/omapdrm/omap_drv.h | 1 +
> 3 files changed, 29 insertions(+), 13 deletions(-)
>
> diff --git a/drivers/gpu/drm/omapdrm/omap_crtc.c
> b/drivers/gpu/drm/omapdrm/omap_crtc.c
> index f5bdb8de98f4..9742d9f49a7c 100644
> --- a/drivers/gpu/drm/omapdrm/omap_crtc.c
> +++ b/drivers/gpu/drm/omapdrm/omap_crtc.c
> @@ -109,7 +109,6 @@ int omap_crtc_wait_pending(struct drm_crtc *crtc)
> */
>
> /* ovl-mgr-id -> crtc */
> -static struct omap_crtc *omap_crtcs[8];
> static struct omap_dss_device *omap_crtc_output[8];
>
> /* we can probably ignore these until we support command-mode panels: */
> @@ -215,7 +214,8 @@ static void omap_crtc_set_enabled(struct drm_crtc *crtc,
> bool enable)
> static int omap_crtc_dss_enable(struct omap_drm_private *priv,
> enum omap_channel channel)
> {
> - struct omap_crtc *omap_crtc = omap_crtcs[channel];
> + struct drm_crtc *crtc = priv->channels[channel]->crtc;
> + struct omap_crtc *omap_crtc = to_omap_crtc(crtc);
>
> priv->dispc_ops->mgr_set_timings(priv->dispc, omap_crtc->channel,
>_crtc->vm);
> @@ -227,7 +227,8 @@ static int omap_crtc_dss_enable(struct omap_drm_private
> *priv,
> static void omap_crtc_dss_disable(struct omap_drm_private *priv,
> enum omap_channel channel)
> {
> - struct omap_crtc *omap_crtc = omap_crtcs[channel];
> + struct drm_crtc *crtc = priv->channels[channel]->crtc;
> + struct omap_crtc *omap_crtc = to_omap_crtc(crtc);
>
> omap_crtc_set_enabled(_crtc->base, false);
> }
> @@ -236,7 +237,9 @@ static void omap_crtc_dss_set_timings(struct
> omap_drm_private *priv,
> enum omap_channel channel,
> const struct videomode *vm)
> {
> - struct omap_crtc *omap_crtc = omap_crtcs[channel];
> + struct drm_crtc *crtc = priv->channels[channel]->crtc;
> + struct omap_crtc *omap_crtc = to_omap_crtc(crtc);
> +
> DBG("%s", omap_crtc->name);
> omap_crtc->vm = *vm;
> }
> @@ -245,7 +248,8 @@ static void omap_crtc_dss_set_lcd_config(struct
> omap_drm_private *priv,
> enum omap_channel channel,
> const struct dss_lcd_mgr_config *config)
> {
> - struct omap_crtc *omap_crtc = omap_crtcs[channel];
> + struct drm_crtc *crtc = priv->channels[channel]->crtc;
> + struct omap_crtc *omap_crtc = to_omap_crtc(crtc);
>
> DBG("%s", omap_crtc->name);
> priv->dispc_ops->mgr_set_lcd_config(priv->dispc, omap_crtc->channel,
> @@ -681,8 +685,6 @@ static const char *channel_names[] = {
>
> void omap_crtc_pre_init(struct omap_drm_private *priv)
> {
> - memset(omap_crtcs, 0, sizeof(omap_crtcs));
> -
> dss_install_mgr_ops(priv->dss, _ops, priv);
> }
>
> @@ -706,10 +708,6 @@ struct drm_crtc *omap_crtc_init(struct drm_device *dev,
>
> DBG("%s", channel_names[channel]);
>
> - /* Multiple displays on same channel is not allowed */
> - if (WARN_ON(omap_crtcs[channel] != NULL))
> - return ERR_PTR(-EINVAL);
> -
> omap_crtc = kzalloc(sizeof(*omap_crtc), GFP_KERNEL);
> if (!omap_crtc)
> return ERR_PTR(-ENOMEM);
> @@ -748,7 +746,5 @@ struct drm_crtc *omap_crtc_init(struct drm_device *dev,
>
> omap_plane_install_properties(crtc->primary, >base);
>
> - omap_crtcs[channel] = omap_crtc;
> -
> return crtc;
> }
> diff --git a/drivers/gpu/drm/omapdrm/omap_drv.c
> b/drivers/gpu/drm/omapdrm/omap_drv.c
> index 6bc826515684..c3c657d90029 100644
> --- a/drivers/gpu/drm/omapdrm/omap_drv.c
> +++ b/drivers/gpu/drm/omapdrm/omap_drv.c
> @@ -167,6 +167,8 @@ static void omap_disconnect_pipelines(struct drm_device
> *ddev)
> pipe->display = NULL;
> }
>
> + memset(>channels, 0, sizeof(priv->channels));
> +
> priv->num_pipes = 0;
> }
>
> @@ -186,6 +188,7 @@ static int omap_connect_pipelines(struct drm_device *ddev)
> {
> struct omap_drm_private *priv = ddev->dev_private;
> struct omap_dss_device *output = NULL;
> + unsigned int i;
> int r;
>
> if (!omapdss_stack_is_ready())
> @@ -218,6 +221,22 @@ static int omap_connect_pipelines(struct drm_device
> *ddev)
> sort(priv->pipes, priv->num_pipes, sizeof(priv->pipes[0]),
>omap_compare_pipes, NULL);
>
> + /*
> + * Populate the pipeline lookup table by DISPC channel. Only
Re: [PATCH v2 57/60] drm/omap: Remove omap_crtc_output global array
Hi,
On Sat, May 26, 2018 at 08:25:15PM +0300, Laurent Pinchart wrote:
> The omap_crtc_output global array is used to look up the DSS output
> device by channel. We can replace that by accessing the output device
> from the pipeline if we store the pipeline pointer in the omap_crtc
> structure.
>
> The global array is also used to protect against double connection of an
> output. This can't happen with the connection handling mechanism going
> from DSS outputs to displays. We can thus drop that check, allowing
> removal of the global array.
>
> Signed-off-by: Laurent Pinchart
> ---
Reviewed-by: Sebastian Reichel
-- Sebastian
> drivers/gpu/drm/omapdrm/omap_crtc.c | 12 +++-
> 1 file changed, 3 insertions(+), 9 deletions(-)
>
> diff --git a/drivers/gpu/drm/omapdrm/omap_crtc.c
> b/drivers/gpu/drm/omapdrm/omap_crtc.c
> index 9742d9f49a7c..5a56c8e02179 100644
> --- a/drivers/gpu/drm/omapdrm/omap_crtc.c
> +++ b/drivers/gpu/drm/omapdrm/omap_crtc.c
> @@ -41,6 +41,7 @@ struct omap_crtc {
> struct drm_crtc base;
>
> const char *name;
> + struct omap_drm_pipeline *pipe;
> enum omap_channel channel;
>
> struct videomode vm;
> @@ -108,9 +109,6 @@ int omap_crtc_wait_pending(struct drm_crtc *crtc)
> * job of sequencing the setup of the video pipe in the proper order
> */
>
> -/* ovl-mgr-id -> crtc */
> -static struct omap_dss_device *omap_crtc_output[8];
> -
> /* we can probably ignore these until we support command-mode panels: */
> static int omap_crtc_dss_connect(struct omap_drm_private *priv,
> enum omap_channel channel,
> @@ -119,13 +117,9 @@ static int omap_crtc_dss_connect(struct omap_drm_private
> *priv,
> const struct dispc_ops *dispc_ops = priv->dispc_ops;
> struct dispc_device *dispc = priv->dispc;
>
> - if (omap_crtc_output[channel])
> - return -EINVAL;
> -
> if (!(dispc_ops->mgr_get_supported_outputs(dispc, channel) & dst->id))
> return -EINVAL;
>
> - omap_crtc_output[channel] = dst;
> dst->dispc_channel_connected = true;
>
> return 0;
> @@ -135,7 +129,6 @@ static void omap_crtc_dss_disconnect(struct
> omap_drm_private *priv,
> enum omap_channel channel,
> struct omap_dss_device *dst)
> {
> - omap_crtc_output[channel] = NULL;
> dst->dispc_channel_connected = false;
> }
>
> @@ -158,7 +151,7 @@ static void omap_crtc_set_enabled(struct drm_crtc *crtc,
> bool enable)
> if (WARN_ON(omap_crtc->enabled == enable))
> return;
>
> - if (omap_crtc_output[channel]->output_type == OMAP_DISPLAY_TYPE_HDMI) {
> + if (omap_crtc->pipe->output->output_type == OMAP_DISPLAY_TYPE_HDMI) {
> priv->dispc_ops->mgr_enable(priv->dispc, channel, enable);
> omap_crtc->enabled = enable;
> return;
> @@ -716,6 +709,7 @@ struct drm_crtc *omap_crtc_init(struct drm_device *dev,
>
> init_waitqueue_head(_crtc->pending_wait);
>
> + omap_crtc->pipe = pipe;
> omap_crtc->channel = channel;
> omap_crtc->name = channel_names[channel];
>
> --
> Regards,
>
> Laurent Pinchart
>
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
signature.asc
Description: PGP signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 58/60] drm/omap: Remove supported output check in CRTC connect handler
Hi,
On Sat, May 26, 2018 at 08:25:16PM +0300, Laurent Pinchart wrote:
> The CRTC connect handler checks whether the DSS output supports the
> DISPC channel assigned to it. As the channel is assigned to the output
> by the output driver a failure there could only result from a driver
> bug. All the output drivers have been verified and they are always
> assigned a DISPC channel that is supported on the SoC they run on. The
> check can thus be removed.
>
> Signed-off-by: Laurent Pinchart
> ---
Reviewed-by: Sebastian Reichel
-- Sebastian
> drivers/gpu/drm/omapdrm/dss/dispc.c | 8
> drivers/gpu/drm/omapdrm/dss/dss.c | 6 --
> drivers/gpu/drm/omapdrm/dss/dss.h | 2 --
> drivers/gpu/drm/omapdrm/dss/omapdss.h | 2 --
> drivers/gpu/drm/omapdrm/omap_crtc.c | 6 --
> 5 files changed, 24 deletions(-)
>
> diff --git a/drivers/gpu/drm/omapdrm/dss/dispc.c
> b/drivers/gpu/drm/omapdrm/dss/dispc.c
> index 7f3ac6b13b56..bc207f2fb200 100644
> --- a/drivers/gpu/drm/omapdrm/dss/dispc.c
> +++ b/drivers/gpu/drm/omapdrm/dss/dispc.c
> @@ -2904,13 +2904,6 @@ static int dispc_ovl_enable(struct dispc_device *dispc,
> return 0;
> }
>
> -static enum omap_dss_output_id
> -dispc_mgr_get_supported_outputs(struct dispc_device *dispc,
> - enum omap_channel channel)
> -{
> - return dss_get_supported_outputs(dispc->dss, channel);
> -}
> -
> static void dispc_lcd_enable_signal_polarity(struct dispc_device *dispc,
>bool act_high)
> {
> @@ -4742,7 +4735,6 @@ static const struct dispc_ops dispc_ops = {
> .mgr_set_lcd_config = dispc_mgr_set_lcd_config,
> .mgr_set_timings = dispc_mgr_set_timings,
> .mgr_setup = dispc_mgr_setup,
> - .mgr_get_supported_outputs = dispc_mgr_get_supported_outputs,
> .mgr_gamma_size = dispc_mgr_gamma_size,
> .mgr_set_gamma = dispc_mgr_set_gamma,
>
> diff --git a/drivers/gpu/drm/omapdrm/dss/dss.c
> b/drivers/gpu/drm/omapdrm/dss/dss.c
> index 5b7613ff2f2e..d2760107ccf2 100644
> --- a/drivers/gpu/drm/omapdrm/dss/dss.c
> +++ b/drivers/gpu/drm/omapdrm/dss/dss.c
> @@ -678,12 +678,6 @@ unsigned long dss_get_max_fck_rate(struct dss_device
> *dss)
> return dss->feat->fck_freq_max;
> }
>
> -enum omap_dss_output_id dss_get_supported_outputs(struct dss_device *dss,
> - enum omap_channel channel)
> -{
> - return dss->feat->outputs[channel];
> -}
> -
> static int dss_setup_default_clock(struct dss_device *dss)
> {
> unsigned long max_dss_fck, prate;
> diff --git a/drivers/gpu/drm/omapdrm/dss/dss.h
> b/drivers/gpu/drm/omapdrm/dss/dss.h
> index 54f96241b9ea..81dd0c910ea1 100644
> --- a/drivers/gpu/drm/omapdrm/dss/dss.h
> +++ b/drivers/gpu/drm/omapdrm/dss/dss.h
> @@ -314,8 +314,6 @@ void dss_runtime_put(struct dss_device *dss);
>
> unsigned long dss_get_dispc_clk_rate(struct dss_device *dss);
> unsigned long dss_get_max_fck_rate(struct dss_device *dss);
> -enum omap_dss_output_id dss_get_supported_outputs(struct dss_device *dss,
> - enum omap_channel channel);
> int dss_dpi_select_source(struct dss_device *dss, int port,
> enum omap_channel channel);
> void dss_select_hdmi_venc_clk_source(struct dss_device *dss,
> diff --git a/drivers/gpu/drm/omapdrm/dss/omapdss.h
> b/drivers/gpu/drm/omapdrm/dss/omapdss.h
> index d7084ca36d0e..bb340a08c44a 100644
> --- a/drivers/gpu/drm/omapdrm/dss/omapdss.h
> +++ b/drivers/gpu/drm/omapdrm/dss/omapdss.h
> @@ -636,8 +636,6 @@ struct dispc_ops {
> const struct videomode *vm);
> void (*mgr_setup)(struct dispc_device *dispc, enum omap_channel channel,
> const struct omap_overlay_manager_info *info);
> - enum omap_dss_output_id (*mgr_get_supported_outputs)(
> - struct dispc_device *dispc, enum omap_channel channel);
> u32 (*mgr_gamma_size)(struct dispc_device *dispc,
> enum omap_channel channel);
> void (*mgr_set_gamma)(struct dispc_device *dispc,
> diff --git a/drivers/gpu/drm/omapdrm/omap_crtc.c
> b/drivers/gpu/drm/omapdrm/omap_crtc.c
> index 5a56c8e02179..90917d040ddb 100644
> --- a/drivers/gpu/drm/omapdrm/omap_crtc.c
> +++ b/drivers/gpu/drm/omapdrm/omap_crtc.c
> @@ -114,12 +114,6 @@ static int omap_crtc_dss_connect(struct omap_drm_private
> *priv,
> enum omap_channel channel,
> struct omap_dss_device *dst)
> {
> - const struct dispc_ops *dispc_ops = priv->dispc_ops;
> - struct dispc_device *dispc = priv->dispc;
> -
> - if (!(dispc_ops->mgr_get_supported_outputs(dispc, channel) & dst->id))
> - return -EINVAL;
> -
> dst->dispc_channel_connected = true;
>
> return 0;
> --
> Regards,
>
> Laurent Pinchart
>
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
Re: [PATCH v2 59/60] drm/omap: Set dispc_channel_connect from DSS output connect handlers
Hi,
On Sat, May 26, 2018 at 08:25:17PM +0300, Laurent Pinchart wrote:
> The omap_dss_device.dispc_channel_connect field is used by DSS outputs
> to fail the .enable() operation if they're not connected. Set the field
> directly from the (dis)connect handlers of the DSS outputs instead of
> going through the CRTC dss_mgr operations.
>
> Signed-off-by: Laurent Pinchart
> ---
Reviewed-by: Sebastian Reichel
-- Sebastian
> drivers/gpu/drm/omapdrm/dss/dpi.c | 3 +++
> drivers/gpu/drm/omapdrm/dss/dsi.c | 3 +++
> drivers/gpu/drm/omapdrm/dss/hdmi4.c | 3 +++
> drivers/gpu/drm/omapdrm/dss/hdmi5.c | 3 +++
> drivers/gpu/drm/omapdrm/dss/sdi.c | 3 +++
> drivers/gpu/drm/omapdrm/dss/venc.c | 3 +++
> drivers/gpu/drm/omapdrm/omap_crtc.c | 3 ---
> 7 files changed, 18 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/omapdrm/dss/dpi.c
> b/drivers/gpu/drm/omapdrm/dss/dpi.c
> index 4cf397c9300e..72d873c2abcc 100644
> --- a/drivers/gpu/drm/omapdrm/dss/dpi.c
> +++ b/drivers/gpu/drm/omapdrm/dss/dpi.c
> @@ -626,12 +626,15 @@ static int dpi_connect(struct omap_dss_device *src,
> return r;
> }
>
> + dst->dispc_channel_connected = true;
> return 0;
> }
>
> static void dpi_disconnect(struct omap_dss_device *src,
> struct omap_dss_device *dst)
> {
> + dst->dispc_channel_connected = false;
> +
> omapdss_device_disconnect(dst, dst->next);
>
> dss_mgr_disconnect(dst);
> diff --git a/drivers/gpu/drm/omapdrm/dss/dsi.c
> b/drivers/gpu/drm/omapdrm/dss/dsi.c
> index bc470baa4f5c..bd5e463558be 100644
> --- a/drivers/gpu/drm/omapdrm/dss/dsi.c
> +++ b/drivers/gpu/drm/omapdrm/dss/dsi.c
> @@ -4896,12 +4896,15 @@ static int dsi_connect(struct omap_dss_device *src,
> return r;
> }
>
> + dst->dispc_channel_connected = true;
> return 0;
> }
>
> static void dsi_disconnect(struct omap_dss_device *src,
> struct omap_dss_device *dst)
> {
> + dst->dispc_channel_connected = false;
> +
> omapdss_device_disconnect(dst, dst->next);
>
> dss_mgr_disconnect(dst);
> diff --git a/drivers/gpu/drm/omapdrm/dss/hdmi4.c
> b/drivers/gpu/drm/omapdrm/dss/hdmi4.c
> index 6616530d5fe6..1e025a8b99c9 100644
> --- a/drivers/gpu/drm/omapdrm/dss/hdmi4.c
> +++ b/drivers/gpu/drm/omapdrm/dss/hdmi4.c
> @@ -443,12 +443,15 @@ static int hdmi_connect(struct omap_dss_device *src,
> return r;
> }
>
> + dst->dispc_channel_connected = true;
> return 0;
> }
>
> static void hdmi_disconnect(struct omap_dss_device *src,
> struct omap_dss_device *dst)
> {
> + dst->dispc_channel_connected = false;
> +
> omapdss_device_disconnect(dst, dst->next);
>
> dss_mgr_disconnect(dst);
> diff --git a/drivers/gpu/drm/omapdrm/dss/hdmi5.c
> b/drivers/gpu/drm/omapdrm/dss/hdmi5.c
> index f7e15edc05fc..d5860438ddd9 100644
> --- a/drivers/gpu/drm/omapdrm/dss/hdmi5.c
> +++ b/drivers/gpu/drm/omapdrm/dss/hdmi5.c
> @@ -448,12 +448,15 @@ static int hdmi_connect(struct omap_dss_device *src,
> return r;
> }
>
> + dst->dispc_channel_connected = true;
> return 0;
> }
>
> static void hdmi_disconnect(struct omap_dss_device *src,
> struct omap_dss_device *dst)
> {
> + dst->dispc_channel_connected = false;
> +
> omapdss_device_disconnect(dst, dst->next);
>
> dss_mgr_disconnect(dst);
> diff --git a/drivers/gpu/drm/omapdrm/dss/sdi.c
> b/drivers/gpu/drm/omapdrm/dss/sdi.c
> index 09c10ba4946b..ed2595a60984 100644
> --- a/drivers/gpu/drm/omapdrm/dss/sdi.c
> +++ b/drivers/gpu/drm/omapdrm/dss/sdi.c
> @@ -264,12 +264,15 @@ static int sdi_connect(struct omap_dss_device *src,
> return r;
> }
>
> + dst->dispc_channel_connected = true;
> return 0;
> }
>
> static void sdi_disconnect(struct omap_dss_device *src,
> struct omap_dss_device *dst)
> {
> + dst->dispc_channel_connected = false;
> +
> omapdss_device_disconnect(dst, dst->next);
>
> dss_mgr_disconnect(dst);
> diff --git a/drivers/gpu/drm/omapdrm/dss/venc.c
> b/drivers/gpu/drm/omapdrm/dss/venc.c
> index 997c4aebd560..4f20183c7861 100644
> --- a/drivers/gpu/drm/omapdrm/dss/venc.c
> +++ b/drivers/gpu/drm/omapdrm/dss/venc.c
> @@ -706,12 +706,15 @@ static int venc_connect(struct omap_dss_device *src,
> return r;
> }
>
> + dst->dispc_channel_connected = true;
> return 0;
> }
>
> static void venc_disconnect(struct omap_dss_device *src,
> struct omap_dss_device *dst)
> {
> + dst->dispc_channel_connected = false;
> +
> omapdss_device_disconnect(dst, dst->next);
>
> dss_mgr_disconnect(dst);
> diff --git a/drivers/gpu/drm/omapdrm/omap_crtc.c
> b/drivers/gpu/drm/omapdrm/omap_crtc.c
> index 90917d040ddb..7f837697e76c 100644
> --- a/drivers/gpu/drm/omapdrm/omap_crtc.c
> +++
Re: [PATCH v2 60/60] drm/omap: dss: Remove the dss_mgr_(dis)connect() operations
Hi,
On Sat, May 26, 2018 at 08:25:18PM +0300, Laurent Pinchart wrote:
> The dss_mgr .connect() and .disconnect() are implemented as no-op in
> omapdrm. The operations are unneeded, remove them.
>
> Signed-off-by: Laurent Pinchart
> ---
Reviewed-by: Sebastian Reichel
-- Sebastian
> drivers/gpu/drm/omapdrm/dss/dpi.c | 10 +-
> drivers/gpu/drm/omapdrm/dss/dsi.c | 10 +-
> drivers/gpu/drm/omapdrm/dss/hdmi4.c | 10 +-
> drivers/gpu/drm/omapdrm/dss/hdmi5.c | 10 +-
> drivers/gpu/drm/omapdrm/dss/omapdss.h | 9 -
> drivers/gpu/drm/omapdrm/dss/output.c | 14 --
> drivers/gpu/drm/omapdrm/dss/sdi.c | 10 +-
> drivers/gpu/drm/omapdrm/dss/venc.c| 10 +-
> drivers/gpu/drm/omapdrm/omap_crtc.c | 15 ---
> 9 files changed, 6 insertions(+), 92 deletions(-)
>
> diff --git a/drivers/gpu/drm/omapdrm/dss/dpi.c
> b/drivers/gpu/drm/omapdrm/dss/dpi.c
> index 72d873c2abcc..764ffc4bad32 100644
> --- a/drivers/gpu/drm/omapdrm/dss/dpi.c
> +++ b/drivers/gpu/drm/omapdrm/dss/dpi.c
> @@ -616,15 +616,9 @@ static int dpi_connect(struct omap_dss_device *src,
>
> dpi_init_pll(dpi);
>
> - r = dss_mgr_connect(dst);
> - if (r)
> - return r;
> -
> r = omapdss_device_connect(dst->dss, dst, dst->next);
> - if (r) {
> - dss_mgr_disconnect(dst);
> + if (r)
> return r;
> - }
>
> dst->dispc_channel_connected = true;
> return 0;
> @@ -636,8 +630,6 @@ static void dpi_disconnect(struct omap_dss_device *src,
> dst->dispc_channel_connected = false;
>
> omapdss_device_disconnect(dst, dst->next);
> -
> - dss_mgr_disconnect(dst);
> }
>
> static const struct omap_dss_device_ops dpi_ops = {
> diff --git a/drivers/gpu/drm/omapdrm/dss/dsi.c
> b/drivers/gpu/drm/omapdrm/dss/dsi.c
> index bd5e463558be..6fe9e2b78144 100644
> --- a/drivers/gpu/drm/omapdrm/dss/dsi.c
> +++ b/drivers/gpu/drm/omapdrm/dss/dsi.c
> @@ -4886,15 +4886,9 @@ static int dsi_connect(struct omap_dss_device *src,
> {
> int r;
>
> - r = dss_mgr_connect(dst);
> - if (r)
> - return r;
> -
> r = omapdss_device_connect(dst->dss, dst, dst->next);
> - if (r) {
> - dss_mgr_disconnect(dst);
> + if (r)
> return r;
> - }
>
> dst->dispc_channel_connected = true;
> return 0;
> @@ -4906,8 +4900,6 @@ static void dsi_disconnect(struct omap_dss_device *src,
> dst->dispc_channel_connected = false;
>
> omapdss_device_disconnect(dst, dst->next);
> -
> - dss_mgr_disconnect(dst);
> }
>
> static const struct omap_dss_device_ops dsi_ops = {
> diff --git a/drivers/gpu/drm/omapdrm/dss/hdmi4.c
> b/drivers/gpu/drm/omapdrm/dss/hdmi4.c
> index 1e025a8b99c9..c4fcdc9ed62d 100644
> --- a/drivers/gpu/drm/omapdrm/dss/hdmi4.c
> +++ b/drivers/gpu/drm/omapdrm/dss/hdmi4.c
> @@ -433,15 +433,9 @@ static int hdmi_connect(struct omap_dss_device *src,
> {
> int r;
>
> - r = dss_mgr_connect(dst);
> - if (r)
> - return r;
> -
> r = omapdss_device_connect(dst->dss, dst, dst->next);
> - if (r) {
> - dss_mgr_disconnect(dst);
> + if (r)
> return r;
> - }
>
> dst->dispc_channel_connected = true;
> return 0;
> @@ -453,8 +447,6 @@ static void hdmi_disconnect(struct omap_dss_device *src,
> dst->dispc_channel_connected = false;
>
> omapdss_device_disconnect(dst, dst->next);
> -
> - dss_mgr_disconnect(dst);
> }
>
> static int hdmi_read_edid(struct omap_dss_device *dssdev,
> diff --git a/drivers/gpu/drm/omapdrm/dss/hdmi5.c
> b/drivers/gpu/drm/omapdrm/dss/hdmi5.c
> index d5860438ddd9..889c31745492 100644
> --- a/drivers/gpu/drm/omapdrm/dss/hdmi5.c
> +++ b/drivers/gpu/drm/omapdrm/dss/hdmi5.c
> @@ -438,15 +438,9 @@ static int hdmi_connect(struct omap_dss_device *src,
> {
> int r;
>
> - r = dss_mgr_connect(dst);
> - if (r)
> - return r;
> -
> r = omapdss_device_connect(dst->dss, dst, dst->next);
> - if (r) {
> - dss_mgr_disconnect(dst);
> + if (r)
> return r;
> - }
>
> dst->dispc_channel_connected = true;
> return 0;
> @@ -458,8 +452,6 @@ static void hdmi_disconnect(struct omap_dss_device *src,
> dst->dispc_channel_connected = false;
>
> omapdss_device_disconnect(dst, dst->next);
> -
> - dss_mgr_disconnect(dst);
> }
>
> static int hdmi_read_edid(struct omap_dss_device *dssdev,
> diff --git a/drivers/gpu/drm/omapdrm/dss/omapdss.h
> b/drivers/gpu/drm/omapdrm/dss/omapdss.h
> index bb340a08c44a..882a2f8f7ac5 100644
> --- a/drivers/gpu/drm/omapdrm/dss/omapdss.h
> +++ b/drivers/gpu/drm/omapdrm/dss/omapdss.h
> @@ -550,13 +550,6 @@ enum dss_writeback_channel {
> };
>
> struct dss_mgr_ops {
> - int (*connect)(struct omap_drm_private *priv,
> -enum omap_channel channel,
> -
Re: Fwd: Re: [PATCHv5 0/3] drm/i915: add DisplayPort CEC-Tunneling-over-AUX support
Hi Ville, I finally found some time to dig deeper into when a CEC device should be registered. Since it's been a long while since we discussed this let me just recap the situation and then propose three solutions: CEC is implemented for DP-to-HDMI branch devices through DPCD CEC registers. When HPD is high we can read these registers and check if CEC is supported or not. If an external USB-C/DP/mini-DP to HDMI adapter is used, then when the HPD goes low you lose access to the DPCD registers since that is (I think) powered by the HPD. If an integrated branch device is used (such as for the HDMI connector on the NUC) the DPCD registers will remain available even if the display is disconnected. The problem is with external adapters since if the HPD goes low you do not know if the adapter has been disconnected, or if the display just pulled the HPD low for a short time (updating the EDID, HDCP changes). In the latter case you do not want to unregister and reregister the cec device. I see three options: 1) register a cec device when a connector is registered and keep it for the life time of the connector. If HPD goes low, or the branch device doesn't support CEC, then just set the physical address of the CEC adapter to f.f.f.f. This is simple, but the disadvantage is that there is a CEC device around, even if the branch device doesn't support CEC. 2) register a cec device when HPD goes high and if a branch device that supports CEC is detected. Unregister the cec device when the HPD goes low and stays low for more than a second. This prevents a cec device from disappearing whenever the display toggles the HPD. It does require a delayed workqueue to handle this delay. It would be nice if there is a way to avoid a delayed workqueue, but I didn't see anything in the i915 code. 3) A hybrid option where the cec device is only registered when a CEC capable branch device is detected, but then we keep it for the remaining lifetime of the connector. This avoids the delayed workqueue, and avoids creating cec devices if the branch device doesn't support CEC. But once it is created it won't be removed until the connector is also unregistered. I'm leaning towards the second or third option. Opinions? Other ideas? Regards, Hans ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 2/3] drm/exynos: Suspend/resume display pipeline as early/late as possible
In the current code, exynos_drm_suspend() function is called after all
real devices (CRTCs, Encoders, etc) are suspended, because Exynos DRM
virtual platform device is created as last device in the system (as
a part of DRM registration). None of the devices for real hardware
modules has its own system suspend/resume callbacks, so it doesn't
change any order of the executed code, but it has a side-effect:
runtime PM callbacks for real devices are not executed, because those
devices are considered by PM core as already suspended. This might
cause issues on boards with complex pipelines, where something
depends on the runtime PM state of the given device.
To ensure that exynos_drm_suspend() is called before any suspend
callback from the real devices, assign it to .prepare callback. Same
for exynos_drm_resume(), using .complete callback ensures that all
real devices have been resumed when calling it.
Signed-off-by: Marek Szyprowski
---
drivers/gpu/drm/exynos/exynos_drm_drv.c | 9 +++--
1 file changed, 3 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.c
b/drivers/gpu/drm/exynos/exynos_drm_drv.c
index c0b4a03ae1b6..d98bc15d490d 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_drv.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_drv.c
@@ -147,7 +147,6 @@ static struct drm_driver exynos_drm_driver = {
.minor = DRIVER_MINOR,
};
-#ifdef CONFIG_PM_SLEEP
static int exynos_drm_suspend(struct device *dev)
{
struct drm_device *drm_dev = dev_get_drvdata(dev);
@@ -170,7 +169,7 @@ static int exynos_drm_suspend(struct device *dev)
return 0;
}
-static int exynos_drm_resume(struct device *dev)
+static void exynos_drm_resume(struct device *dev)
{
struct drm_device *drm_dev = dev_get_drvdata(dev);
struct exynos_drm_private *private;
@@ -182,13 +181,11 @@ static int exynos_drm_resume(struct device *dev)
drm_atomic_helper_resume(drm_dev, private->suspend_state);
exynos_drm_fbdev_resume(drm_dev);
drm_kms_helper_poll_enable(drm_dev);
-
- return 0;
}
-#endif
static const struct dev_pm_ops exynos_drm_pm_ops = {
- SET_SYSTEM_SLEEP_PM_OPS(exynos_drm_suspend, exynos_drm_resume)
+ .prepare = exynos_drm_suspend,
+ .complete = exynos_drm_resume,
};
/* forward declaration */
--
2.17.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 1/3] drm/exynos: Drop useless check from exynos_drm_{suspend,resume}
The virtual Exynos DRM device has no runtime PM enabled, so checking for its runtime suspended state is useless. Signed-off-by: Marek Szyprowski --- drivers/gpu/drm/exynos/exynos_drm_drv.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.c b/drivers/gpu/drm/exynos/exynos_drm_drv.c index a81b4a5e24a7..c0b4a03ae1b6 100644 --- a/drivers/gpu/drm/exynos/exynos_drm_drv.c +++ b/drivers/gpu/drm/exynos/exynos_drm_drv.c @@ -153,7 +153,7 @@ static int exynos_drm_suspend(struct device *dev) struct drm_device *drm_dev = dev_get_drvdata(dev); struct exynos_drm_private *private; - if (pm_runtime_suspended(dev) || !drm_dev) + if (!drm_dev) return 0; private = drm_dev->dev_private; @@ -175,8 +175,8 @@ static int exynos_drm_resume(struct device *dev) struct drm_device *drm_dev = dev_get_drvdata(dev); struct exynos_drm_private *private; - if (pm_runtime_suspended(dev) || !drm_dev) - return 0; + if (!drm_dev) + return; private = drm_dev->dev_private; drm_atomic_helper_resume(drm_dev, private->suspend_state); -- 2.17.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 3/3] drm/exynos: Ensure suspended runtime PM state during system suspend
Add calls to pm_runtime_force_{suspend,resume} as SYSTEM_SLEEP_PM_OPS for
all drivers for the real Exynos DRM hardware modules. This ensures that
the resources will be released for the system PM suspend/resume cycle.
Exynos DRM core already takes care of suspending the whole display pipeline
before PM callbacks of the real devices are called.
Signed-off-by: Marek Szyprowski
---
drivers/gpu/drm/exynos/exynos5433_drm_decon.c | 2 ++
drivers/gpu/drm/exynos/exynos7_drm_decon.c| 2 ++
drivers/gpu/drm/exynos/exynos_dp.c| 3 +++
drivers/gpu/drm/exynos/exynos_drm_dsi.c | 2 ++
drivers/gpu/drm/exynos/exynos_drm_fimd.c | 2 ++
drivers/gpu/drm/exynos/exynos_drm_mic.c | 2 ++
drivers/gpu/drm/exynos/exynos_hdmi.c | 2 ++
drivers/gpu/drm/exynos/exynos_mixer.c | 2 ++
8 files changed, 17 insertions(+)
diff --git a/drivers/gpu/drm/exynos/exynos5433_drm_decon.c
b/drivers/gpu/drm/exynos/exynos5433_drm_decon.c
index 82c95c34447f..aac0b383027e 100644
--- a/drivers/gpu/drm/exynos/exynos5433_drm_decon.c
+++ b/drivers/gpu/drm/exynos/exynos5433_drm_decon.c
@@ -673,6 +673,8 @@ static int exynos5433_decon_resume(struct device *dev)
static const struct dev_pm_ops exynos5433_decon_pm_ops = {
SET_RUNTIME_PM_OPS(exynos5433_decon_suspend, exynos5433_decon_resume,
NULL)
+ SET_SYSTEM_SLEEP_PM_OPS(pm_runtime_force_suspend,
+pm_runtime_force_resume)
};
static const struct of_device_id exynos5433_decon_driver_dt_match[] = {
diff --git a/drivers/gpu/drm/exynos/exynos7_drm_decon.c
b/drivers/gpu/drm/exynos/exynos7_drm_decon.c
index 3931d5e33fe0..88cbd000eb09 100644
--- a/drivers/gpu/drm/exynos/exynos7_drm_decon.c
+++ b/drivers/gpu/drm/exynos/exynos7_drm_decon.c
@@ -832,6 +832,8 @@ static int exynos7_decon_resume(struct device *dev)
static const struct dev_pm_ops exynos7_decon_pm_ops = {
SET_RUNTIME_PM_OPS(exynos7_decon_suspend, exynos7_decon_resume,
NULL)
+ SET_SYSTEM_SLEEP_PM_OPS(pm_runtime_force_suspend,
+ pm_runtime_force_resume)
};
struct platform_driver decon_driver = {
diff --git a/drivers/gpu/drm/exynos/exynos_dp.c
b/drivers/gpu/drm/exynos/exynos_dp.c
index 86330f396784..7bda7cbb 100644
--- a/drivers/gpu/drm/exynos/exynos_dp.c
+++ b/drivers/gpu/drm/exynos/exynos_dp.c
@@ -16,6 +16,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -276,6 +277,8 @@ static int exynos_dp_resume(struct device *dev)
static const struct dev_pm_ops exynos_dp_pm_ops = {
SET_RUNTIME_PM_OPS(exynos_dp_suspend, exynos_dp_resume, NULL)
+ SET_SYSTEM_SLEEP_PM_OPS(pm_runtime_force_suspend,
+ pm_runtime_force_resume)
};
static const struct of_device_id exynos_dp_match[] = {
diff --git a/drivers/gpu/drm/exynos/exynos_drm_dsi.c
b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
index 7c3030b7e586..95faea0d5f59 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_dsi.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
@@ -1860,6 +1860,8 @@ static int __maybe_unused exynos_dsi_resume(struct device
*dev)
static const struct dev_pm_ops exynos_dsi_pm_ops = {
SET_RUNTIME_PM_OPS(exynos_dsi_suspend, exynos_dsi_resume, NULL)
+ SET_SYSTEM_SLEEP_PM_OPS(pm_runtime_force_suspend,
+ pm_runtime_force_resume)
};
struct platform_driver dsi_driver = {
diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
index 01b1570d0c3a..b7f56935a46b 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
@@ -1192,6 +1192,8 @@ static int exynos_fimd_resume(struct device *dev)
static const struct dev_pm_ops exynos_fimd_pm_ops = {
SET_RUNTIME_PM_OPS(exynos_fimd_suspend, exynos_fimd_resume, NULL)
+ SET_SYSTEM_SLEEP_PM_OPS(pm_runtime_force_suspend,
+ pm_runtime_force_resume)
};
struct platform_driver fimd_driver = {
diff --git a/drivers/gpu/drm/exynos/exynos_drm_mic.c
b/drivers/gpu/drm/exynos/exynos_drm_mic.c
index 2174814273e2..2fd299a58297 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_mic.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_mic.c
@@ -367,6 +367,8 @@ static int exynos_mic_resume(struct device *dev)
static const struct dev_pm_ops exynos_mic_pm_ops = {
SET_RUNTIME_PM_OPS(exynos_mic_suspend, exynos_mic_resume, NULL)
+ SET_SYSTEM_SLEEP_PM_OPS(pm_runtime_force_suspend,
+ pm_runtime_force_resume)
};
static int exynos_mic_probe(struct platform_device *pdev)
diff --git a/drivers/gpu/drm/exynos/exynos_hdmi.c
b/drivers/gpu/drm/exynos/exynos_hdmi.c
index 09c4bc0b1859..2fef61144743 100644
--- a/drivers/gpu/drm/exynos/exynos_hdmi.c
+++ b/drivers/gpu/drm/exynos/exynos_hdmi.c
@@ -2093,6 +2093,8 @@ static int __maybe_unused exynos_hdmi_resume(struct
device *dev)
static const struct
[PATCH 0/3] Exynos DRM: cleanup of suspend/resume code
Dear all,
This patchset performs a significant cleanup of Exynos DRM suspend/resume
code. A side effect of this cleanup is working system suspend/resume on
Exynos5433 SoCs, where there are more dependencies between hardware
device drivers, clock controllers and power domains than in case of the
previous SoCs.
Best regards
Marek Szyprowski
Samsung R Institute Poland
Patch summary:
Marek Szyprowski (3):
drm/exynos: Drop useless check from exynos_drm_{suspend,resume}
drm/exynos: Suspend/resume display pipeline as early/late as possible
drm/exynos: Ensure suspended runtime PM state during system suspend
drivers/gpu/drm/exynos/exynos5433_drm_decon.c | 2 ++
drivers/gpu/drm/exynos/exynos7_drm_decon.c| 2 ++
drivers/gpu/drm/exynos/exynos_dp.c| 3 +++
drivers/gpu/drm/exynos/exynos_drm_drv.c | 15 ++-
drivers/gpu/drm/exynos/exynos_drm_dsi.c | 2 ++
drivers/gpu/drm/exynos/exynos_drm_fimd.c | 2 ++
drivers/gpu/drm/exynos/exynos_drm_mic.c | 2 ++
drivers/gpu/drm/exynos/exynos_hdmi.c | 2 ++
drivers/gpu/drm/exynos/exynos_mixer.c | 2 ++
9 files changed, 23 insertions(+), 9 deletions(-)
--
2.17.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 105145] vaExportSurfaceHandle interaction with surface interlaced flag prevents switching on vaapi deinterlacing dynamically
https://bugs.freedesktop.org/show_bug.cgi?id=105145 --- Comment #11 from k.phil...@gmail.com --- Hi again, > The PR got merged. I do have a patch ready (it's just a few lines anyway), but vaapi has not seen a release yet so it is unclear which API version it should depend on. Also we have encountered even more corner cases that prompts me to now follow up on a comment to the PR, https://github.com/intel/libva/pull/196#issuecomment-371769757 - see below. In this bug report, I described the approach (or workaround, rather) we took in Kodi to get useful vaapi-accelerated playback working on most videos. In the meantime, we have encountered more edge cases. Namely: 1. The described approach will not work for 1080p HEVC and VP9 videos, since the AMD decoder does not support the interlaced (field) format for HEVC and VP9 (see si_get_video_param) and will re-allocate the decode surfaces to progressive format when decoding the first picture. Then they cannot be used as post-processing input any more. This could be fixed by setting the export usage hint on the post-processing output surface, since then both input and output to post-processing are progressive. 2. We encountered a DVB H.264 PAFF mixed progressive/interlaced video with resolution 1920x1088, which failed the size check for always inserting post-processing by a few pixels. This can be fixed by making the check more lenient. Now as you see these issues are not unfixable (or un-workaroundable), but you can probably see that in the long run these kind of edge cases will continue to crop up and cause problems. Our alternative workaround would be to always re-initialize the whole decode pipeline when encountering a change from interlaced to progressive frames or vice-versa, losing a bunch of already decoded frames in the pipeline in the process. As this is also far from optimal and Christian König seemed positively inclined to switch to progressive by default, I want to investigate this route after all. The only missing piece for this to work seems to be de-weaving the frames when switching to the interlaced format, and I can have a look at that (can't promise a time frame though). However, before investing time into that I want to ask if it would be also possible to go one step even further: Is the interlaced format necessary in the first place? With DVB (or other, but this seems the most common) PAFF streams, you will have to reallocate surfaces and weave/de-weave very often, possibly after few frames. Wouldn't it be more efficient then to ditch the interlaced format and have post-processing accept progressive-format frames for deinterlacing, like intel-vaapi-driver seems to do? -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 105145] vaExportSurfaceHandle interaction with surface interlaced flag prevents switching on vaapi deinterlacing dynamically
https://bugs.freedesktop.org/show_bug.cgi?id=105145 --- Comment #12 from Christian König --- (In reply to k.philipp from comment #11) > Is the interlaced format necessary in the first place? Unfortunately yes it is. The pixel shader used for de-interlacing needs to have access to the top/bottom field separately and that only works efficiently when they aren't mangled together. We could try to double the stride to work around that, but that isn't easily doable with the interface we have and we would stress the memory interface quite a bit more. Additional to that most hardware de-interlacer work only with that layout, .e.g it is actually the more natural one for MPEG2. And that's also the reason why for example NVidia hardware only works with that as well. That HEVC and VP9 only support progressive layout in the output format is also only logical because those formats don't support interlaced content. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Xen-devel] [PATCH v2 5/9] xen/gntdev: Allow mappings for DMA buffers
On 06/08/2018 10:21 PM, Boris Ostrovsky wrote:
On 06/08/2018 01:59 PM, Stefano Stabellini wrote:
@@ -325,6 +401,14 @@ static int map_grant_pages(struct
grant_map
*map)
map->unmap_ops[i].handle = map->map_ops[i].handle;
if (use_ptemod)
map->kunmap_ops[i].handle =
map->kmap_ops[i].handle;
+#ifdef CONFIG_XEN_GRANT_DMA_ALLOC
+ else if (map->dma_vaddr) {
+ unsigned long mfn;
+
+ mfn = __pfn_to_mfn(page_to_pfn(map->pages[i]));
Not pfn_to_mfn()?
I'd love to, but pfn_to_mfn is only defined for x86, not ARM: [1]
and [2]
Thus,
drivers/xen/gntdev.c:408:10: error: implicit declaration of function
‘pfn_to_mfn’ [-Werror=implicit-function-declaration]
mfn = pfn_to_mfn(page_to_pfn(map->pages[i]));
So, I'll keep __pfn_to_mfn
How will this work on non-PV x86?
So, you mean I need:
#ifdef CONFIG_X86
mfn = pfn_to_mfn(page_to_pfn(map->pages[i]));
#else
mfn = __pfn_to_mfn(page_to_pfn(map->pages[i]));
#endif
I'd rather fix it in ARM code. Stefano, why does ARM uses the
underscored version?
Do you want me to add one more patch for ARM to wrap __pfn_to_mfn
with static inline for ARM? e.g.
static inline ...pfn_to_mfn(...)
{
__pfn_to_mfn();
}
A Xen on ARM guest doesn't actually know the mfns behind its own
pseudo-physical pages. This is why we stopped using pfn_to_mfn and
started using pfn_to_bfn instead, which will generally return "pfn",
unless the page is a foreign grant. See include/xen/arm/page.h.
pfn_to_bfn was also introduced on x86. For example, see the usage of
pfn_to_bfn in drivers/xen/swiotlb-xen.c. Otherwise, if you don't care
about other mapped grants, you can just use pfn_to_gfn, that always
returns pfn.
I think then this code needs to use pfn_to_bfn().
Ok
Also, for your information, we support different page granularities in
Linux as a Xen guest, see the comment at include/xen/arm/page.h:
/*
* The pseudo-physical frame (pfn) used in all the helpers is always based
* on Xen page granularity (i.e 4KB).
*
* A Linux page may be split across multiple non-contiguous Xen page so we
* have to keep track with frame based on 4KB page granularity.
*
* PV drivers should never make a direct usage of those helpers (particularly
* pfn_to_gfn and gfn_to_pfn).
*/
A Linux page could be 64K, but a Xen page is always 4K. A granted page
is also 4K. We have helpers to take into account the offsets to map
multiple Xen grants in a single Linux page, see for example
drivers/xen/grant-table.c:gnttab_foreach_grant. Most PV drivers have
been converted to be able to work with 64K pages correctly, but if I
remember correctly gntdev.c is the only remaining driver that doesn't
support 64K pages yet, so you don't have to deal with it if you don't
want to.
I believe somewhere in this series there is a test for PAGE_SIZE vs.
XEN_PAGE_SIZE. Right, Oleksandr?
Not in gntdev. You might have seen this in xen-drmfront/xen-sndfront,
but I didn't touch gntdev for that. Do you want me to add yet another patch
in the series to check for that?
Thanks for the explanation.
-boris
Thank you,
Oleksandr
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
