[Intel-gfx] [PATCH] Revert "drm/i915: start adding dp mst audio"
On Tue, May 03, 2016 at 11:01:32AM -0400, Lyude wrote:
> Right now MST audio is causing too many kernel panics to really keep
> around in the kernel. On top of that, even after fixing said panics it's
> still basically non-functional (at least on all the setups I've tested
> it on). Revert until we have a proper solution for this.
>
> This reverts commit 3d52ccf52f2c51f613e42e65be0f06e4e6788093.
>
> Signed-off-by: Lyude
Applied (with appropriate Fixes: and cc: stable tags), thanks.
-Daniel
> ---
> drivers/gpu/drm/i915/i915_debugfs.c | 16
> drivers/gpu/drm/i915/intel_audio.c | 9 +++--
> drivers/gpu/drm/i915/intel_ddi.c| 24 +---
> drivers/gpu/drm/i915/intel_dp_mst.c | 22 --
> drivers/gpu/drm/i915/intel_drv.h| 2 --
> 5 files changed, 8 insertions(+), 65 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
> b/drivers/gpu/drm/i915/i915_debugfs.c
> index a0f1bd7..e3f4c72 100644
> --- a/drivers/gpu/drm/i915/i915_debugfs.c
> +++ b/drivers/gpu/drm/i915/i915_debugfs.c
> @@ -2872,20 +2872,6 @@ static void intel_dp_info(struct seq_file *m,
> intel_panel_info(m, &intel_connector->panel);
> }
>
> -static void intel_dp_mst_info(struct seq_file *m,
> - struct intel_connector *intel_connector)
> -{
> - struct intel_encoder *intel_encoder = intel_connector->encoder;
> - struct intel_dp_mst_encoder *intel_mst =
> - enc_to_mst(&intel_encoder->base);
> - struct intel_digital_port *intel_dig_port = intel_mst->primary;
> - struct intel_dp *intel_dp = &intel_dig_port->dp;
> - bool has_audio = drm_dp_mst_port_has_audio(&intel_dp->mst_mgr,
> - intel_connector->port);
> -
> - seq_printf(m, "\taudio support: %s\n", yesno(has_audio));
> -}
> -
> static void intel_hdmi_info(struct seq_file *m,
> struct intel_connector *intel_connector)
> {
> @@ -2929,8 +2915,6 @@ static void intel_connector_info(struct seq_file *m,
> intel_hdmi_info(m, intel_connector);
> else if (intel_encoder->type == INTEL_OUTPUT_LVDS)
> intel_lvds_info(m, intel_connector);
> - else if (intel_encoder->type == INTEL_OUTPUT_DP_MST)
> - intel_dp_mst_info(m, intel_connector);
> }
>
> seq_printf(m, "\tmodes:\n");
> diff --git a/drivers/gpu/drm/i915/intel_audio.c
> b/drivers/gpu/drm/i915/intel_audio.c
> index 30f9214..7d281b4 100644
> --- a/drivers/gpu/drm/i915/intel_audio.c
> +++ b/drivers/gpu/drm/i915/intel_audio.c
> @@ -262,8 +262,7 @@ static void hsw_audio_codec_disable(struct intel_encoder
> *encoder)
> tmp |= AUD_CONFIG_N_PROG_ENABLE;
> tmp &= ~AUD_CONFIG_UPPER_N_MASK;
> tmp &= ~AUD_CONFIG_LOWER_N_MASK;
> - if (intel_pipe_has_type(intel_crtc, INTEL_OUTPUT_DISPLAYPORT) ||
> - intel_pipe_has_type(intel_crtc, INTEL_OUTPUT_DP_MST))
> + if (intel_pipe_has_type(intel_crtc, INTEL_OUTPUT_DISPLAYPORT))
> tmp |= AUD_CONFIG_N_VALUE_INDEX;
> I915_WRITE(HSW_AUD_CFG(pipe), tmp);
>
> @@ -476,8 +475,7 @@ static void ilk_audio_codec_enable(struct drm_connector
> *connector,
> tmp &= ~AUD_CONFIG_N_VALUE_INDEX;
> tmp &= ~AUD_CONFIG_N_PROG_ENABLE;
> tmp &= ~AUD_CONFIG_PIXEL_CLOCK_HDMI_MASK;
> - if (intel_pipe_has_type(intel_crtc, INTEL_OUTPUT_DISPLAYPORT) ||
> - intel_pipe_has_type(intel_crtc, INTEL_OUTPUT_DP_MST))
> + if (intel_pipe_has_type(intel_crtc, INTEL_OUTPUT_DISPLAYPORT))
> tmp |= AUD_CONFIG_N_VALUE_INDEX;
> else
> tmp |= audio_config_hdmi_pixel_clock(adjusted_mode);
> @@ -515,8 +513,7 @@ void intel_audio_codec_enable(struct intel_encoder
> *intel_encoder)
>
> /* ELD Conn_Type */
> connector->eld[5] &= ~(3 << 2);
> - if (intel_pipe_has_type(crtc, INTEL_OUTPUT_DISPLAYPORT) ||
> - intel_pipe_has_type(crtc, INTEL_OUTPUT_DP_MST))
> + if (intel_pipe_has_type(crtc, INTEL_OUTPUT_DISPLAYPORT))
> connector->eld[5] |= (1 << 2);
>
> connector->eld[6] = drm_av_sync_delay(connector, adjusted_mode) / 2;
> diff --git a/drivers/gpu/drm/i915/intel_ddi.c
> b/drivers/gpu/drm/i915/intel_ddi.c
> index 62de9f4..1c3487a 100644
> --- a/drivers/gpu/drm/i915/intel_ddi.c
> +++ b/drivers/gpu/drm/i915/intel_ddi.c
> @@ -3098,23 +3098,6 @@ void intel_ddi_fdi_disable(struct drm_crtc *crtc)
> I915_WRITE(FDI_RX_CTL(PIPE_A), val);
> }
>
> -bool intel_ddi_is_audio_enabled(struct drm_i915_private *dev_priv,
> - struct intel_crtc *intel_crtc)
> -{
> - u32 temp;
> -
> - if (intel_display_power_get_if_enabled(dev_priv, POWER_DOMAIN_AUDIO)) {
> - temp = I915_READ(HSW_AUD_PIN_ELD_CP_VLD);
> -
> - intel_display_power_put(dev_priv, POWER_DOMAIN_AUDIO);
> -
> - if (temp & AUDIO_OUTPUT_ENABLE(intel_crtc->pipe))
> -
[PATCH] drm/edid : calculate vsync and hsync from range limits block according to the EDID 1.4
On Tue, May 03, 2016 at 11:05:25AM -0400, Vitaly Prosyak wrote: > Do calculation of vsync and hsync from range limits > EDID block according to the spec. EDID 1.4. > > Signed-off-by: Vitaly Prosyak Forgot one: For anything related to edid please cc Adam Jackson. Applies to both patches. -Daniel > --- > drivers/gpu/drm/drm_edid.c | 16 > 1 file changed, 8 insertions(+), 8 deletions(-) > > diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c > index 7e49962..601152b 100644 > --- a/drivers/gpu/drm/drm_edid.c > +++ b/drivers/gpu/drm/drm_edid.c > @@ -1977,11 +1977,11 @@ mode_in_hsync_range(const struct drm_display_mode > *mode, > int hsync, hmin, hmax; > > hmin = t[7]; > - if (edid->revision >= 4) > - hmin += ((t[4] & 0x04) ? 255 : 0); > + if (edid->revision >= 4 && ((t[4] & 0x0c) == 0x0c)) > + hmin += 255 ; > hmax = t[8]; > - if (edid->revision >= 4) > - hmax += ((t[4] & 0x08) ? 255 : 0); > + if (edid->revision >= 4 && (t[4] & 0x08)) > + hmax += 255; > hsync = drm_mode_hsync(mode); > > return (hsync <= hmax && hsync >= hmin); > @@ -1994,11 +1994,11 @@ mode_in_vsync_range(const struct drm_display_mode > *mode, > int vsync, vmin, vmax; > > vmin = t[5]; > - if (edid->revision >= 4) > - vmin += ((t[4] & 0x01) ? 255 : 0); > + if (edid->revision >= 4 && ((t[4] & 0x03) == 0x03)) > + vmin += 255; > vmax = t[6]; > - if (edid->revision >= 4) > - vmax += ((t[4] & 0x02) ? 255 : 0); > + if (edid->revision >= 4 && (t[4] & 0x02)) > + vmax += 255; > vsync = drm_mode_vrefresh(mode); > > return (vsync <= vmax && vsync >= vmin); > -- > 1.9.1 > > ___ > dri-devel mailing list > dri-devel at lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/dri-devel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch
[PATCH] drm/edid : calculate vsync and hsync from range limits block according to the EDID 1.4
On Tue, May 03, 2016 at 11:05:25AM -0400, Vitaly Prosyak wrote: > Do calculation of vsync and hsync from range limits > EDID block according to the spec. EDID 1.4. > > Signed-off-by: Vitaly Prosyak Seems unrelated to the previous patch, please submit in a separate series. > --- > drivers/gpu/drm/drm_edid.c | 16 > 1 file changed, 8 insertions(+), 8 deletions(-) > > diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c > index 7e49962..601152b 100644 > --- a/drivers/gpu/drm/drm_edid.c > +++ b/drivers/gpu/drm/drm_edid.c > @@ -1977,11 +1977,11 @@ mode_in_hsync_range(const struct drm_display_mode > *mode, > int hsync, hmin, hmax; > > hmin = t[7]; > - if (edid->revision >= 4) > - hmin += ((t[4] & 0x04) ? 255 : 0); > + if (edid->revision >= 4 && ((t[4] & 0x0c) == 0x0c)) > + hmin += 255 ; > hmax = t[8]; > - if (edid->revision >= 4) > - hmax += ((t[4] & 0x08) ? 255 : 0); > + if (edid->revision >= 4 && (t[4] & 0x08)) > + hmax += 255; Please don't reshuffle code without functional changes. Same above, for such small bugfixes it's best to only change what you need changed. It might also be useful to introduce symbolic #defines for all these magic constants. -Daniel > hsync = drm_mode_hsync(mode); > > return (hsync <= hmax && hsync >= hmin); > @@ -1994,11 +1994,11 @@ mode_in_vsync_range(const struct drm_display_mode > *mode, > int vsync, vmin, vmax; > > vmin = t[5]; > - if (edid->revision >= 4) > - vmin += ((t[4] & 0x01) ? 255 : 0); > + if (edid->revision >= 4 && ((t[4] & 0x03) == 0x03)) > + vmin += 255; > vmax = t[6]; > - if (edid->revision >= 4) > - vmax += ((t[4] & 0x02) ? 255 : 0); > + if (edid->revision >= 4 && (t[4] & 0x02)) > + vmax += 255; > vsync = drm_mode_vrefresh(mode); > > return (vsync <= vmax && vsync >= vmin); > -- > 1.9.1 > > ___ > dri-devel mailing list > dri-devel at lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/dri-devel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch
[PATCH] drm/edid : cache edid range limits in drm connector
On Tue, May 03, 2016 at 11:05:24AM -0400, Vitaly Prosyak wrote:
> Cache in drm connector the edid range limits properties:
> min/max vertical refresh rates and max pixel clock.
> It would be used when enter to drr mode.
>
> Signed-off-by: Vitaly Prosyak
Where's the patches that will use this? It might make sense to instead
have some helper functions to compute these values, so that drivers can
store them wherever they want/need. But impossible to tell without the
users of this stuff.
-Daniel
> ---
> drivers/gpu/drm/drm_edid.c | 11 +++
> include/drm/drm_crtc.h | 5 +
> 2 files changed, 16 insertions(+)
>
> diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
> index 04cb487..7e49962 100644
> --- a/drivers/gpu/drm/drm_edid.c
> +++ b/drivers/gpu/drm/drm_edid.c
> @@ -2190,6 +2190,17 @@ do_inferred_modes(struct detailed_timing *timing, void
> *c)
> timing);
> break;
> case 0x01: /* just the ranges, no formula */
> + closure->connector->min_vfreq = range->min_vfreq;
> + closure->connector->max_vfreq = range->max_vfreq;
> + if (closure->edid->revision >= 4) {
> + if ((range->flags & 0x03) == 0x3)
> + closure->connector->min_vfreq += 255;
> + if (range->flags & 0x02)
> + closure->connector->max_vfreq += 255;
> + }
> + closure->connector->max_pixel_clock_khz =
> + range_pixel_clock(closure->edid, (u8 *)timing);
> + break;
> default:
> break;
> }
> diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
> index c5b4b81..85fc554 100644
> --- a/include/drm/drm_crtc.h
> +++ b/include/drm/drm_crtc.h
> @@ -1230,6 +1230,11 @@ struct drm_connector {
> uint8_t num_h_tile, num_v_tile;
> uint8_t tile_h_loc, tile_v_loc;
> uint16_t tile_h_size, tile_v_size;
> +
> + /*EDID range limits for drr*/
> + int min_vfreq ;
> + int max_vfreq ;
> + int max_pixel_clock_khz;
> };
>
> /**
> --
> 1.9.1
>
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
[Bug 95198] Shadow of Mordor beta has missing geometry with gl 4.3
https://bugs.freedesktop.org/show_bug.cgi?id=95198 --- Comment #5 from John --- I was going to create a new bug but I think my issue may be the same. With llvm-svn up to revision 267861 everything works fine, but starting with revision 268162 I get the same issue as in Ersnt's screenshot. My console prints many of these : LLVM triggered Diagnostic Handler: LDS size exceeds device maximum LLVM failed to compile shader radeonsi: can't create a shader Card is 280x so a bit different. I am on latest mesa-git, and linux 4.5 (patched to get computer shader). Downgrading llvm-svn fixes the issue right away. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20160503/72f7ad5a/attachment.html>
[PATCH] drm/atomic: use connector references (v3)
On Wed, May 04, 2016 at 06:03:05AM +1000, Dave Airlie wrote:
> From: Dave Airlie
>
> Take a reference when setting a crtc on a connecter,
> also take one when duplicating if a crtc is set,
> and drop one on destroy if a crtc is set.
>
> v2: take Daniel Stone's advice and simplify the
> ref/unref dances, also take care of NULL as connector
> to state reset.
>
> v3: remove need for connector NULL check.
>
> Signed-off-by: Dave Airlie
This patch series seems cursed with lots of embarrassement for reviewers.
I totally missed/forgot the FIXME in drm_atomic_state_default_clear(),
which this patch fixes. Anyway, I'm happy to burn my hands again ;-)
Reviewed-by: Daniel Vetter
> ---
> drivers/gpu/drm/drm_atomic.c| 14 +-
> drivers/gpu/drm/drm_atomic_helper.c | 4
> 2 files changed, 9 insertions(+), 9 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
> index 9d5e3c8..0df87a5 100644
> --- a/drivers/gpu/drm/drm_atomic.c
> +++ b/drivers/gpu/drm/drm_atomic.c
> @@ -142,15 +142,7 @@ void drm_atomic_state_default_clear(struct
> drm_atomic_state *state)
> if (!connector)
> continue;
>
> - /*
> - * FIXME: Async commits can race with connector unplugging and
> - * there's currently nothing that prevents cleanup up state for
> - * deleted connectors. As long as the callback doesn't look at
> - * the connector we'll be fine though, so make sure that's the
> - * case by setting all connector pointers to NULL.
> - */
> - state->connector_states[i]->connector = NULL;
> - connector->funcs->atomic_destroy_state(NULL,
> + connector->funcs->atomic_destroy_state(connector,
>
> state->connector_states[i]);
> state->connectors[i] = NULL;
> state->connector_states[i] = NULL;
> @@ -1160,6 +1152,8 @@ drm_atomic_set_crtc_for_connector(struct
> drm_connector_state *conn_state,
> {
> struct drm_crtc_state *crtc_state;
>
> + if (crtc)
> + drm_connector_reference(conn_state->connector);
> if (conn_state->crtc && conn_state->crtc != crtc) {
> crtc_state =
> drm_atomic_get_existing_crtc_state(conn_state->state,
>
> conn_state->crtc);
> @@ -1177,6 +1171,8 @@ drm_atomic_set_crtc_for_connector(struct
> drm_connector_state *conn_state,
> 1 << drm_connector_index(conn_state->connector);
> }
>
> + if (conn_state->crtc)
> + drm_connector_unreference(conn_state->connector);
> conn_state->crtc = crtc;
>
> if (crtc)
> diff --git a/drivers/gpu/drm/drm_atomic_helper.c
> b/drivers/gpu/drm/drm_atomic_helper.c
> index d25abce..c48446d 100644
> --- a/drivers/gpu/drm/drm_atomic_helper.c
> +++ b/drivers/gpu/drm/drm_atomic_helper.c
> @@ -2762,6 +2762,8 @@ __drm_atomic_helper_connector_duplicate_state(struct
> drm_connector *connector,
> struct drm_connector_state *state)
> {
> memcpy(state, connector->state, sizeof(*state));
> + if (state->crtc)
> + drm_connector_reference(connector);
> }
> EXPORT_SYMBOL(__drm_atomic_helper_connector_duplicate_state);
>
> @@ -2889,6 +2891,8 @@ __drm_atomic_helper_connector_destroy_state(struct
> drm_connector *connector,
>* state will automatically do the right thing if code is ever added
>* to this function.
>*/
> + if (state->crtc)
> + drm_connector_unreference(state->connector);
> }
> EXPORT_SYMBOL(__drm_atomic_helper_connector_destroy_state);
>
> --
> 2.5.5
>
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
[PATCH v2 1/4] drm: Add helper for DP++ adaptors
On 5/3/2016 12:38 AM, ville.syrjala at linux.intel.com wrote: > From: Ville Syrjälä > > Add a helper which aids in the identification of DP dual mode > (aka. DP++) adaptors. There are several types of adaptors > specified: type 1 DVI, type 1 HDMI, type 2 DVI, type 2 HDMI > > Type 1 adaptors have a max TMDS clock limit of 165MHz, type 2 adaptors > may go as high as 300MHz and they provide a register informing the > source device what the actual limit is. Supposedly also type 1 adaptors > may optionally implement this register. This TMDS clock limit is the > main reason why we need to identify these adaptors. > > Type 1 adaptors provide access to their internal registers and the sink > DDC bus through I2C. Type 2 adaptors provide this access both via I2C > and I2C-over-AUX. A type 2 source device may choose to implement either > of these methods. If a source device implements the I2C-over-AUX > method, then the driver will obviously need specific support for such > adaptors since the port is driven like an HDMI port, but DDC > communication happes over the AUX channel. > > This helper should be enough to identify the adaptor type (some > type 1 DVI adaptors may be a slight exception) and the maximum TMDS > clock limit. Another feature that may be available is control over > the TMDS output buffers on the adaptor, possibly allowing for some > power saving when the TMDS link is down. > > Other user controllable features that may be available in the adaptors > are downstream i2c bus speed control when using i2c-over-aux, and > some control over the CEC pin. I chose not to provide any helper > functions for those since I have no use for them in i915 at this time. > The rest of the registers in the adaptor are mostly just information, > eg. IEEE OUI, hardware and firmware revision, etc. > > v2: Pass adaptor type to helper functions to ease driver implementation > Fix a bunch of typoes (Paulo) > Add DRM_DP_DUAL_MODE_UNKNOWN for the case where we don't (yet) know > the type (Paulo) > Reject 0x00 and 0xff DP_DUAL_MODE_MAX_TMDS_CLOCK values (Paulo) > Adjust drm_dp_dual_mode_detect() type2 vs. type1 detection to > ease future LSPCON enabling > Remove the unused DP_DUAL_MODE_LAST_RESERVED define > > Cc: stable at vger.kernel.org > Cc: Tore Anderson > Cc: Paulo Zanoni > Cc: Shashank Sharma > Cc: Daniel Vetter > Signed-off-by: Ville Syrjälä > --- > drivers/gpu/drm/Makefile | 2 +- > drivers/gpu/drm/drm_dp_dual_mode_helper.c | 356 > ++ > include/drm/drm_dp_dual_mode_helper.h | 83 +++ > 3 files changed, 440 insertions(+), 1 deletion(-) > create mode 100644 drivers/gpu/drm/drm_dp_dual_mode_helper.c > create mode 100644 include/drm/drm_dp_dual_mode_helper.h > > diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile > index 1a26b4eb1ce0..29f2ee9b9534 100644 > --- a/drivers/gpu/drm/Makefile > +++ b/drivers/gpu/drm/Makefile > @@ -23,7 +23,7 @@ drm-$(CONFIG_AGP) += drm_agpsupport.o > > drm_kms_helper-y := drm_crtc_helper.o drm_dp_helper.o drm_probe_helper.o \ > drm_plane_helper.o drm_dp_mst_topology.o drm_atomic_helper.o \ > - drm_kms_helper_common.o > + drm_kms_helper_common.o drm_dp_dual_mode_helper.o > > drm_kms_helper-$(CONFIG_DRM_LOAD_EDID_FIRMWARE) += drm_edid_load.o > drm_kms_helper-$(CONFIG_DRM_FBDEV_EMULATION) += drm_fb_helper.o > diff --git a/drivers/gpu/drm/drm_dp_dual_mode_helper.c > b/drivers/gpu/drm/drm_dp_dual_mode_helper.c > new file mode 100644 > index ..949c0fbeb542 > --- /dev/null > +++ b/drivers/gpu/drm/drm_dp_dual_mode_helper.c > @@ -0,0 +1,356 @@ > +/* > + * Copyright © 2016 Intel Corporation > + * > + * Permission is hereby granted, free of charge, to any person obtaining a > + * copy of this software and associated documentation files (the "Software"), > + * to deal in the Software without restriction, including without limitation > + * the rights to use, copy, modify, merge, publish, distribute, sublicense, > + * and/or sell copies of the Software, and to permit persons to whom the > + * Software is furnished to do so, subject to the following conditions: > + * > + * The above copyright notice and this permission notice shall be included in > + * all copies or substantial portions of the Software. > + * > + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR > + * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, > + * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL > + * THE COPYRIGHT HOLDER(S) OR AUTHOR(S) BE LIABLE FOR ANY CLAIM, DAMAGES OR > + * OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, > + * ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR > + * OTHER DEALINGS IN THE SOFTWARE. > + */ > + > +#include > +#include > +#include > +#include > +#include > +#include > +#include > + > +/** > + * DOC: D
drm/radeon/kms: add dpm support for KB/KV
Hello Alex Deucher,
The patch 41a524abff26: "drm/radeon/kms: add dpm support for KB/KV"
from Aug 14, 2013, leads to the following static checker warning:
drivers/gpu/drm/radeon/kv_dpm.c:1376 kv_init_fps_limits()
error: wrong number of bits for 'cpu_to_be16' (8 vs 16) left=
'pi->fps_low_t' pi->fps_low_t = (__builtin_bswap16(((tmp
drivers/gpu/drm/radeon/kv_dpm.c
1359 static int kv_init_fps_limits(struct radeon_device *rdev)
1360 {
1361 struct kv_power_info *pi = kv_get_pi(rdev);
1362 int ret = 0;
1363
1364 if (pi->caps_fps) {
1365 u16 tmp;
1366
1367 tmp = 45;
1368 pi->fps_high_t = cpu_to_be16(tmp);
1369 ret = kv_copy_bytes_to_smc(rdev,
1370 pi->dpm_table_start +
1371
offsetof(SMU7_Fusion_DpmTable, FpsHighT),
1372 (u8 *)&pi->fps_high_t,
1373 sizeof(u16), pi->sram_end);
1374
1375 tmp = 30;
1376 pi->fps_low_t = cpu_to_be16(tmp);
^
This is a u8 so it can't hold a be16.
1377
1378 ret = kv_copy_bytes_to_smc(rdev,
1379 pi->dpm_table_start +
1380
offsetof(SMU7_Fusion_DpmTable, FpsLowT),
1381 (u8 *)&pi->fps_low_t,
^^
This cast is not needed since it's already a u8 pointer.
1382 sizeof(u16), pi->sram_end);
1383
1384 }
1385 return ret;
1386 }
regards,
dan carpenter
[Intel-gfx] [PATCH] drm/atomic: use connector references (v3)
Hi, On 3 May 2016 at 21:09, Daniel Vetter wrote: > This patch series seems cursed with lots of embarrassement for reviewers. > I totally missed/forgot the FIXME in drm_atomic_state_default_clear(), > which this patch fixes. Anyway, I'm happy to burn my hands again ;-) Let's share the embarrassment. What could possibly go wrong? Reviewed-by: Daniel Stone Cheers, Daniel
[Bug 95015] [drm:.r600_ring_test [radeon]] *ERROR* radeon: ring 0 test failed (scratch(0x8504)=0xCAFEDEAD)
https://bugs.freedesktop.org/show_bug.cgi?id=95015 --- Comment #5 from Rui Salvaterra --- (In reply to Oded Gabbay from comment #4) > Did you try running a 4.5 kernel ? > I added a POWER relevant fix for radeon in 4.5, which relates to caches > (c524498 - drm/radeon: mask out WC from BO on unsupported arches) Hi, Oded I compiled 4.6-rc6 today and the result is the same (actually, now that I see, the second dmesg I attached is from 4.6-rc4). The card works on the x8 slot (behind the DART) but not on the x16 slot (bypassing the DART). Thanks, Rui -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20160503/4033de2a/attachment.html>
[PATCH 5/9] drm/i915: Enable i915 perf stream for Haswell OA unit
On Tue, May 3, 2016 at 8:34 PM, Robert Bragg wrote: > Sorry for the delay replying to this, I missed it. > > On Sat, Apr 23, 2016 at 11:34 AM, Martin Peres > wrote: > >> On 20/04/16 17:23, Robert Bragg wrote: >> >>> Gen graphics hardware can be set up to periodically write snapshots of >>> performance counters into a circular buffer via its Observation >>> Architecture and this patch exposes that capability to userspace via the >>> i915 perf interface. >>> >>> Cc: Chris Wilson >>> Signed-off-by: Robert Bragg >>> Signed-off-by: Zhenyu Wang >>> --- >>> drivers/gpu/drm/i915/i915_drv.h | 56 +- >>> drivers/gpu/drm/i915/i915_gem_context.c | 24 +- >>> drivers/gpu/drm/i915/i915_perf.c| 940 >>> +++- >>> drivers/gpu/drm/i915/i915_reg.h | 338 >>> include/uapi/drm/i915_drm.h | 70 ++- >>> 5 files changed, 1408 insertions(+), 20 deletions(-) >>> >>> + >>> + >>> + /* It takes a fairly long time for a new MUX configuration to >>> +* be be applied after these register writes. This delay >>> +* duration was derived empirically based on the render_basic >>> +* config but hopefully it covers the maximum configuration >>> +* latency... >>> +*/ >>> + mdelay(100); >>> >> >> With such a HW and SW design, how can we ever expose hope to get any >> kind of performance when we are trying to monitor different metrics on >> each >> draw call? This may be acceptable for system monitoring, but it is >> problematic >> for the GL extensions :s >> > >> Since it seems like we are going for a perf API, it means that for every >> change >> of metrics, we need to flush the commands, wait for the GPU to be done, >> then >> program the new set of metrics via an IOCTL, wait 100 ms, and then we may >> resume rendering ... until the next change. We are talking about a >> latency of >> 6-7 frames at 60 Hz here... this is non-negligeable... >> > >> I understand that we have a ton of counters and we may hide latency by not >> allowing using more than half of the counters for every draw call or >> frame, but >> even then, this 100ms delay is killing this approach altogether. >> > > > So revisiting this to double check how things fail with my latest driver/tests without the delay, I apparently can't reproduce test failures without the delay any more... I think the explanation is that since first adding the delay to the driver I also made the the driver a bit more careful to not forward spurious reports that look invalid due to a zeroed report id field, and that mechanism keeps the unit tests happy, even though there are still some number of invalid reports generated if we don't wait. One problem with simply having no delay is that the driver prints an error if it sees an invalid reports so I get a lot of 'Skipping spurious, invalid OA report' dmesg spam. Also this was intended more as a last resort mechanism, and I wouldn't feel too happy about squashing the error message and potentially sweeping other error cases under the carpet. Experimenting to see if the delay can at least be reduced, I brought the delay up in millisecond increments and found that although I still see a lot of spurious reports only waiting 1 or 5 milliseconds, at 10 milliseconds its reduced quite a bit and at 15 milliseconds I don't seem to have any errors. 15 milliseconds is still a long time, but at least not as long as 100. Regards, - Robert -- next part -- An HTML attachment was scrubbed... URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20160503/0071cad5/attachment.html>
[PATCH] drm/edid : cache edid range limits in drm connector
Added Adam.
-Original Message-
From: Prosyak, Vitaly
Sent: Tuesday, May 03, 2016 4:45 PM
To: 'Daniel Vetter'
Cc: dri-devel at lists.freedesktop.org; Deucher, Alexander
Subject: RE: [PATCH] drm/edid : cache edid range limits in drm connector
We are going to use min/max vertical refresh rate when enter/exit to the
dynamic refresh rate mode ,it is known as 'freesync', enter/exit to full
screen games.
Right , we may have a helper function which extracts these properties and store
wherever need it.
But this an alternative solution with additional helper adds some code
duplication into drm_edid.c since the case already present in the code:
case 0x01: /* just the ranges, no formula */ Also these values are parsed
during each mode enumeration.
Why I put into connector:
Drm connector have already similar items from EDID: drm_tile_group ,etc...
Vitaly
-Original Message-.
From: Daniel Vetter [mailto:daniel.vet...@ffwll.ch] On Behalf Of Daniel Vetter
Sent: Tuesday, May 03, 2016 4:24 PM
To: Prosyak, Vitaly
Cc: dri-devel at lists.freedesktop.org
Subject: Re: [PATCH] drm/edid : cache edid range limits in drm connector
On Tue, May 03, 2016 at 11:05:24AM -0400, Vitaly Prosyak wrote:
> Cache in drm connector the edid range limits properties:
> min/max vertical refresh rates and max pixel clock.
> It would be used when enter to drr mode.
>
> Signed-off-by: Vitaly Prosyak
Where's the patches that will use this? It might make sense to instead have
some helper functions to compute these values, so that drivers can store them
wherever they want/need. But impossible to tell without the users of this stuff.
-Daniel
> ---
> drivers/gpu/drm/drm_edid.c | 11 +++
> include/drm/drm_crtc.h | 5 +
> 2 files changed, 16 insertions(+)
>
> diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
> index 04cb487..7e49962 100644
> --- a/drivers/gpu/drm/drm_edid.c
> +++ b/drivers/gpu/drm/drm_edid.c
> @@ -2190,6 +2190,17 @@ do_inferred_modes(struct detailed_timing *timing, void
> *c)
> timing);
> break;
> case 0x01: /* just the ranges, no formula */
> + closure->connector->min_vfreq = range->min_vfreq;
> + closure->connector->max_vfreq = range->max_vfreq;
> + if (closure->edid->revision >= 4) {
> + if ((range->flags & 0x03) == 0x3)
> + closure->connector->min_vfreq += 255;
> + if (range->flags & 0x02)
> + closure->connector->max_vfreq += 255;
> + }
> + closure->connector->max_pixel_clock_khz =
> + range_pixel_clock(closure->edid, (u8 *)timing);
> + break;
> default:
> break;
> }
> diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h index
> c5b4b81..85fc554 100644
> --- a/include/drm/drm_crtc.h
> +++ b/include/drm/drm_crtc.h
> @@ -1230,6 +1230,11 @@ struct drm_connector {
> uint8_t num_h_tile, num_v_tile;
> uint8_t tile_h_loc, tile_v_loc;
> uint16_t tile_h_size, tile_v_size;
> +
> + /*EDID range limits for drr*/
> + int min_vfreq ;
> + int max_vfreq ;
> + int max_pixel_clock_khz;
> };
>
> /**
> --
> 1.9.1
>
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
[Bug 95015] [drm:.r600_ring_test [radeon]] *ERROR* radeon: ring 0 test failed (scratch(0x8504)=0xCAFEDEAD)
https://bugs.freedesktop.org/show_bug.cgi?id=95015 --- Comment #4 from Oded Gabbay --- Did you try running a 4.5 kernel ? I added a POWER relevant fix for radeon in 4.5, which relates to caches (c524498 - drm/radeon: mask out WC from BO on unsupported arches) -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20160503/9482dc5b/attachment-0001.html>
[PATCH] drm/edid : cache edid range limits in drm connector
We are going to use min/max vertical refresh rate when enter/exit to the
dynamic refresh rate mode ,it is known as 'freesync', enter/exit to full
screen games.
Right , we may have a helper function which extracts these properties and store
wherever need it.
But this an alternative solution with additional helper adds some code
duplication into drm_edid.c since the case already present in the code:
case 0x01: /* just the ranges, no formula */
Also these values are parsed during each mode enumeration.
Why I put into connector:
Drm connector have already similar items from EDID: drm_tile_group ,etc...
Vitaly
-Original Message-.
From: Daniel Vetter [mailto:daniel.vet...@ffwll.ch] On Behalf Of Daniel Vetter
Sent: Tuesday, May 03, 2016 4:24 PM
To: Prosyak, Vitaly
Cc: dri-devel at lists.freedesktop.org
Subject: Re: [PATCH] drm/edid : cache edid range limits in drm connector
On Tue, May 03, 2016 at 11:05:24AM -0400, Vitaly Prosyak wrote:
> Cache in drm connector the edid range limits properties:
> min/max vertical refresh rates and max pixel clock.
> It would be used when enter to drr mode.
>
> Signed-off-by: Vitaly Prosyak
Where's the patches that will use this? It might make sense to instead have
some helper functions to compute these values, so that drivers can store them
wherever they want/need. But impossible to tell without the users of this stuff.
-Daniel
> ---
> drivers/gpu/drm/drm_edid.c | 11 +++
> include/drm/drm_crtc.h | 5 +
> 2 files changed, 16 insertions(+)
>
> diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
> index 04cb487..7e49962 100644
> --- a/drivers/gpu/drm/drm_edid.c
> +++ b/drivers/gpu/drm/drm_edid.c
> @@ -2190,6 +2190,17 @@ do_inferred_modes(struct detailed_timing *timing, void
> *c)
> timing);
> break;
> case 0x01: /* just the ranges, no formula */
> + closure->connector->min_vfreq = range->min_vfreq;
> + closure->connector->max_vfreq = range->max_vfreq;
> + if (closure->edid->revision >= 4) {
> + if ((range->flags & 0x03) == 0x3)
> + closure->connector->min_vfreq += 255;
> + if (range->flags & 0x02)
> + closure->connector->max_vfreq += 255;
> + }
> + closure->connector->max_pixel_clock_khz =
> + range_pixel_clock(closure->edid, (u8 *)timing);
> + break;
> default:
> break;
> }
> diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h index
> c5b4b81..85fc554 100644
> --- a/include/drm/drm_crtc.h
> +++ b/include/drm/drm_crtc.h
> @@ -1230,6 +1230,11 @@ struct drm_connector {
> uint8_t num_h_tile, num_v_tile;
> uint8_t tile_h_loc, tile_v_loc;
> uint16_t tile_h_size, tile_v_size;
> +
> + /*EDID range limits for drr*/
> + int min_vfreq ;
> + int max_vfreq ;
> + int max_pixel_clock_khz;
> };
>
> /**
> --
> 1.9.1
>
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
[PATCH v2 1/4] drm: Add helper for DP++ adaptors
On Tue, May 03, 2016 at 10:03:30PM +0530, Sharma, Shashank wrote: > > > On 5/3/2016 12:38 AM, ville.syrjala at linux.intel.com wrote: > > From: Ville Syrjälä > > > > Add a helper which aids in the identification of DP dual mode > > (aka. DP++) adaptors. There are several types of adaptors > > specified: type 1 DVI, type 1 HDMI, type 2 DVI, type 2 HDMI > > > > Type 1 adaptors have a max TMDS clock limit of 165MHz, type 2 adaptors > > may go as high as 300MHz and they provide a register informing the > > source device what the actual limit is. Supposedly also type 1 adaptors > > may optionally implement this register. This TMDS clock limit is the > > main reason why we need to identify these adaptors. > > > > Type 1 adaptors provide access to their internal registers and the sink > > DDC bus through I2C. Type 2 adaptors provide this access both via I2C > > and I2C-over-AUX. A type 2 source device may choose to implement either > > of these methods. If a source device implements the I2C-over-AUX > > method, then the driver will obviously need specific support for such > > adaptors since the port is driven like an HDMI port, but DDC > > communication happes over the AUX channel. > > > > This helper should be enough to identify the adaptor type (some > > type 1 DVI adaptors may be a slight exception) and the maximum TMDS > > clock limit. Another feature that may be available is control over > > the TMDS output buffers on the adaptor, possibly allowing for some > > power saving when the TMDS link is down. > > > > Other user controllable features that may be available in the adaptors > > are downstream i2c bus speed control when using i2c-over-aux, and > > some control over the CEC pin. I chose not to provide any helper > > functions for those since I have no use for them in i915 at this time. > > The rest of the registers in the adaptor are mostly just information, > > eg. IEEE OUI, hardware and firmware revision, etc. > > > > v2: Pass adaptor type to helper functions to ease driver implementation > > Fix a bunch of typoes (Paulo) > > Add DRM_DP_DUAL_MODE_UNKNOWN for the case where we don't (yet) know > > the type (Paulo) > > Reject 0x00 and 0xff DP_DUAL_MODE_MAX_TMDS_CLOCK values (Paulo) > > Adjust drm_dp_dual_mode_detect() type2 vs. type1 detection to > > ease future LSPCON enabling > > Remove the unused DP_DUAL_MODE_LAST_RESERVED define > > > > Cc: stable at vger.kernel.org > > Cc: Tore Anderson > > Cc: Paulo Zanoni > > Cc: Shashank Sharma > > Cc: Daniel Vetter > > Signed-off-by: Ville Syrjälä > > --- > > drivers/gpu/drm/Makefile | 2 +- > > drivers/gpu/drm/drm_dp_dual_mode_helper.c | 356 > > ++ > > include/drm/drm_dp_dual_mode_helper.h | 83 +++ > > 3 files changed, 440 insertions(+), 1 deletion(-) > > create mode 100644 drivers/gpu/drm/drm_dp_dual_mode_helper.c > > create mode 100644 include/drm/drm_dp_dual_mode_helper.h > > > > diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile > > index 1a26b4eb1ce0..29f2ee9b9534 100644 > > --- a/drivers/gpu/drm/Makefile > > +++ b/drivers/gpu/drm/Makefile > > @@ -23,7 +23,7 @@ drm-$(CONFIG_AGP) += drm_agpsupport.o > > > > drm_kms_helper-y := drm_crtc_helper.o drm_dp_helper.o drm_probe_helper.o \ > > drm_plane_helper.o drm_dp_mst_topology.o drm_atomic_helper.o \ > > - drm_kms_helper_common.o > > + drm_kms_helper_common.o drm_dp_dual_mode_helper.o > > > > drm_kms_helper-$(CONFIG_DRM_LOAD_EDID_FIRMWARE) += drm_edid_load.o > > drm_kms_helper-$(CONFIG_DRM_FBDEV_EMULATION) += drm_fb_helper.o > > diff --git a/drivers/gpu/drm/drm_dp_dual_mode_helper.c > > b/drivers/gpu/drm/drm_dp_dual_mode_helper.c > > new file mode 100644 > > index ..949c0fbeb542 > > --- /dev/null > > +++ b/drivers/gpu/drm/drm_dp_dual_mode_helper.c > > @@ -0,0 +1,356 @@ > > +/* > > + * Copyright © 2016 Intel Corporation > > + * > > + * Permission is hereby granted, free of charge, to any person obtaining a > > + * copy of this software and associated documentation files (the > > "Software"), > > + * to deal in the Software without restriction, including without > > limitation > > + * the rights to use, copy, modify, merge, publish, distribute, sublicense, > > + * and/or sell copies of the Software, and to permit persons to whom the > > + * Software is furnished to do so, subject to the following conditions: > > + * > > + * The above copyright notice and this permission notice shall be included > > in > > + * all copies or substantial portions of the Software. > > + * > > + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS > > OR > > + * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, > > + * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL > > + * THE COPYRIGHT HOLDER(S) OR AUTHOR(S) BE LIABLE FOR ANY CLAIM, DAMAGES OR > > + * OTHER LIABILITY, WHETHER IN AN AC
[PATCH 5/9] drm/i915: Enable i915 perf stream for Haswell OA unit
waiting for the GPU to be idle would usually > not > take more than a few ms... which is nothing compared to waiting 100ms. > Yeah, I think this is a really quite different programming model to what the OA unit is geared for, even if we can somehow knock out this 100ms MUX config delay. > > So, now, the elephant in the room, how can it take that long to apply the > change? Are the OA registers double buffered (NVIDIA's are, so as we can > reconfigure and start monitoring multiple counters at the same time)? > Based on my understanding of how the HW works internally I can see how some delay would be expected, but can't currently fathom why it would need to have this order of magnitude, and so the delay is currently simply based on experimentation where I was getting unit test failures at 10ms, for invalid looking reports, but the tests ran reliably at 100ms. OA configuration state isn't double buffered to allow configuration while in use. > > Maybe this 100ms is the polling period and the HW does not allow changing > the configuration in the middle of a polling session. In this case, this > delay > should be dependent on the polling frequency. But even then, I would really > hope that the HW would allow us to tear down everything, reconfigure and > start polling again without waiting for the next tick. If not possible, > maybe we > can change the frequency for the polling clock to make the polling event > happen > sooner. > The tests currently test periods from 160ns to 168 milliseconds while the delay required falls somewhere between 10 and 100 milliseconds. I think I'd expect the delay to be > all periods tested if this was the link. Generally this seems unlikely to me, in part considering how the MUX isn't really part of the OA unit that handles periodic sampling. I wouldn't rule out some interaction though so some experimenting along these lines could be interesting. > > HW delays are usually a few microseconds, not milliseconds, that really > suggests > that something funny is happening and the HW design is not understood > properly. > Yup. Although I understand more about the HW than I can write up here, I can't currently see why the HW should ever really take this long to apply a MUX config - although I can see why some delay would be required. It's on my list of things to try and get feedback/ideas on from the OA architect/HW engineers. I brought this up briefly some time ago but we didn't have time to go into details. > If the documentation has nothing on this and the HW teams cannot help, > then I > suggest a little REing session There's no precisely documented delay requirement. Insofar as REing is the process of inferring how black box HW works through poking it with a stick and seeing how it reacts, then yep more of that may be necessary. At least in this case the HW isn't really a black box (maybe stain glass), where I hopefully have a fairly good sense of how the HW is designed and can prod folks closer to the HW for feedback/ideas. So far I haven't spent too long investigating this besides recently homing in on needing a delay here when my unit tests were failing. > I really want to see this work land, but the way I see > it right now is that we cannot rely on it because of this bug. Maybe > fixing this bug > would require changing the architecture, so better address it before > landing the > patches. > I think it's unlikely to change the architecture; rather we might just find some other things to frob that make the MUX config apply faster (e.g. clock gating issue); we find a way to get explicit feedback of completion so we can minimize the delay or a better understanding that lets us choose a shorter delay in most cases. The driver is already usable with gputop with this delay and considering how config changes are typically associated with user interaction I wouldn't see this as a show stopper - even though it's not ideal. I think the assertions about it being unusable with GL, were a little overstated based on making frequent OA config changes which is not really how the interface is intended to be used. Thanks for starting to take a look through the code. Kind Regards, - Robert > Worst case scenario, do not hesitate to contact me if non of the proposed > explanation pans out, I will take the time to read through the OA material > and try my > REing skills on it. As I said, I really want to see this upstream! > > Sorry... > > Martin > -- next part -- An HTML attachment was scrubbed... URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20160503/3032f5df/attachment-0001.html>
[PATCH 5/6] drm/atomic: use connector references (v2)
>>*/
>> + if (connector && state->crtc) {
>> + drm_connector_unreference(state->connector);
>> + }
>
> Bikeshed: no need for {} and you don't need to check that connector is
> NULL either. Tbh all the destroy_state helpers don't really need their
> object argument, only the state. Cleaning that up is somewhere on my todo.
Yes you really do need the connector, lost a boot to an oops,
drm_atomic_state_default_clear does some funky stuff that can possibly go away
after this, but I'm not sure.
Dave.
[Bug 117591] amdgpu: Black screens on A10-8700P (Carrizo) + R7 M260/M265 (Topaz) Combo
https://bugzilla.kernel.org/show_bug.cgi?id=117591 Alex Deucher changed: What|Removed |Added CC||alexdeucher at gmail.com --- Comment #7 from Alex Deucher --- Does appending amdgpu.runpm=0 to the kernel command line in grub help? -- You are receiving this mail because: You are watching the assignee of the bug.
[PATCH 00/14] Add/update DRM entries in the MAINTAINERS file
On Fri, Apr 22, 2016 at 12:03:48AM +0100, Emil Velikov wrote: > Hi all, > > A bunch of trivial updates for the MAINTAINERS file - corrected files > lists, git repos. The last few patches 'nominate' developers who have > already been the effective maintainers of the specific drivers. > > With the final patch we explicitly list the legacy/UMS drivers, as > Orphan/Obsolete. Who knows we might get a few volunteers to give them > the some love for the first time in ~8 years. > > > Maintainers, > > Can we get a few acks and get all (most) of them in one go or do you > prefer to carry them via your tree ? Makes all sense and Dave said I should just go ahead and pick up the ones who haven't seen an ack yet. All applied to drm-misc, thanks. -Daniel > > > Thanks > Emil > > > Emil Velikov (14): > MAINTAINERS: Remove unneded wildcard for the Radeon/AMDGPU drivers > MAINTAINERS: Remove unneded wildcard for the i915 DRM driver > MAINTAINERS: Update the files list for the Exynos DRM driver > MAINTAINERS: Update the files list for the GMA500 DRM driver > MAINTAINERS: Update the files list for the Rockchip DRM driver > MAINTAINERS: Update the files list for the Etnaviv DRM driver > MAINTAINERS: Update the files list for the Armada DRM driver > MAINTAINERS: Update the files list for the Renesas DRM drivers > MAINTAINERS: List the correct git repo for the Renesas DRM drivers > MAINTAINERS: Add maintainer entry for the Nouveau DRM driver > MAINTAINERS: Add maintainer entry for the MSM DRM driver > MAINTAINERS: Add maintainer entry for the VMWGFX DRM driver > MAINTAINERS: Add a few DRM drivers by Dave Airlie > MAINTAINERS: Add a bunch of legacy (UMS) DRM drivers > > MAINTAINERS | 113 > ++-- > 1 file changed, 102 insertions(+), 11 deletions(-) > > -- > 2.6.2 > > ___ > dri-devel mailing list > dri-devel at lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/dri-devel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch
[PATCH v3 1/4] drm: Add helper for DP++ adaptors
From: Ville Syrjälä Add a helper which aids in the identification of DP dual mode (aka. DP++) adaptors. There are several types of adaptors specified: type 1 DVI, type 1 HDMI, type 2 DVI, type 2 HDMI Type 1 adaptors have a max TMDS clock limit of 165MHz, type 2 adaptors may go as high as 300MHz and they provide a register informing the source device what the actual limit is. Supposedly also type 1 adaptors may optionally implement this register. This TMDS clock limit is the main reason why we need to identify these adaptors. Type 1 adaptors provide access to their internal registers and the sink DDC bus through I2C. Type 2 adaptors provide this access both via I2C and I2C-over-AUX. A type 2 source device may choose to implement either of these methods. If a source device implements the I2C-over-AUX method, then the driver will obviously need specific support for such adaptors since the port is driven like an HDMI port, but DDC communication happes over the AUX channel. This helper should be enough to identify the adaptor type (some type 1 DVI adaptors may be a slight exception) and the maximum TMDS clock limit. Another feature that may be available is control over the TMDS output buffers on the adaptor, possibly allowing for some power saving when the TMDS link is down. Other user controllable features that may be available in the adaptors are downstream i2c bus speed control when using i2c-over-aux, and some control over the CEC pin. I chose not to provide any helper functions for those since I have no use for them in i915 at this time. The rest of the registers in the adaptor are mostly just information, eg. IEEE OUI, hardware and firmware revision, etc. v2: Pass adaptor type to helper functions to ease driver implementation Fix a bunch of typoes (Paulo) Add DRM_DP_DUAL_MODE_UNKNOWN for the case where we don't (yet) know the type (Paulo) Reject 0x00 and 0xff DP_DUAL_MODE_MAX_TMDS_CLOCK values (Paulo) Adjust drm_dp_dual_mode_detect() type2 vs. type1 detection to ease future LSPCON enabling Remove the unused DP_DUAL_MODE_LAST_RESERVED define v3: Fix kernel doc function argument descriptions (Jani) s/NONE/UNKNOWN/ in drm_dp_dual_mode_detect() docs Add kernel doc for enum drm_dp_dual_mode_type Actually build the docs Fix more typoes Cc: stable at vger.kernel.org Cc: Tore Anderson Cc: Paulo Zanoni Cc: Shashank Sharma Cc: Daniel Vetter Signed-off-by: Ville Syrjälä --- Documentation/DocBook/gpu.tmpl| 6 + drivers/gpu/drm/Makefile | 2 +- drivers/gpu/drm/drm_dp_dual_mode_helper.c | 356 ++ include/drm/drm_dp_dual_mode_helper.h | 92 4 files changed, 455 insertions(+), 1 deletion(-) create mode 100644 drivers/gpu/drm/drm_dp_dual_mode_helper.c create mode 100644 include/drm/drm_dp_dual_mode_helper.h diff --git a/Documentation/DocBook/gpu.tmpl b/Documentation/DocBook/gpu.tmpl index 1464fb2f3c46..c248124357df 100644 --- a/Documentation/DocBook/gpu.tmpl +++ b/Documentation/DocBook/gpu.tmpl @@ -1623,6 +1623,12 @@ void intel_crt_init(struct drm_device *dev) !Edrivers/gpu/drm/drm_dp_helper.c + Display Port Dual Mode Adaptor Helper Functions Reference +!Pdrivers/gpu/drm/drm_dp_dual_mode_helper.c dp dual mode helpers +!Iinclude/drm/drm_dp_dual_mode_helper.h +!Edrivers/gpu/drm/drm_dp_dual_mode_helper.c + + Display Port MST Helper Functions Reference !Pdrivers/gpu/drm/drm_dp_mst_topology.c dp mst helper !Iinclude/drm/drm_dp_mst_helper.h diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile index 1a26b4eb1ce0..29f2ee9b9534 100644 --- a/drivers/gpu/drm/Makefile +++ b/drivers/gpu/drm/Makefile @@ -23,7 +23,7 @@ drm-$(CONFIG_AGP) += drm_agpsupport.o drm_kms_helper-y := drm_crtc_helper.o drm_dp_helper.o drm_probe_helper.o \ drm_plane_helper.o drm_dp_mst_topology.o drm_atomic_helper.o \ - drm_kms_helper_common.o + drm_kms_helper_common.o drm_dp_dual_mode_helper.o drm_kms_helper-$(CONFIG_DRM_LOAD_EDID_FIRMWARE) += drm_edid_load.o drm_kms_helper-$(CONFIG_DRM_FBDEV_EMULATION) += drm_fb_helper.o diff --git a/drivers/gpu/drm/drm_dp_dual_mode_helper.c b/drivers/gpu/drm/drm_dp_dual_mode_helper.c new file mode 100644 index ..af68c4cdf817 --- /dev/null +++ b/drivers/gpu/drm/drm_dp_dual_mode_helper.c @@ -0,0 +1,356 @@ +/* + * Copyright © 2016 Intel Corporation + * + * Permission is hereby granted, free of charge, to any person obtaining a + * copy of this software and associated documentation files (the "Software"), + * to deal in the Software without restriction, including without limitation + * the rights to use, copy, modify, merge, publish, distribute, sublicense, + * and/or sell copies of the Software, and to permit persons to whom the + * Software is furnished to do so, subject to the following conditions: + * + * The above copyright notice and this permission notice shall be included in +
[Bug 117591] amdgpu: Black screens on A10-8700P (Carrizo) + R7 M260/M265 (Topaz) Combo
https://bugzilla.kernel.org/show_bug.cgi?id=117591 --- Comment #6 from Jani Väinölä --- Also, this machine worked flawlessly with the old fglrx 15.12 drivers. The troubles started when I did the upgrade to Ubuntu 16.04, but I did do fresh install of several distros to try it out. -- You are receiving this mail because: You are watching the assignee of the bug.
[Bug 117591] amdgpu: Black screens on A10-8700P (Carrizo) + R7 M260/M265 (Topaz) Combo
https://bugzilla.kernel.org/show_bug.cgi?id=117591 --- Comment #5 from Jani Väinölä --- Created attachment 215221 --> https://bugzilla.kernel.org/attachment.cgi?id=215221&action=edit Output of lspci -vv -- You are receiving this mail because: You are watching the assignee of the bug.
[Bug 117591] amdgpu: Black screens on A10-8700P (Carrizo) + R7 M260/M265 (Topaz) Combo
https://bugzilla.kernel.org/show_bug.cgi?id=117591 --- Comment #4 from Jani Väinölä --- Created attachment 215211 --> https://bugzilla.kernel.org/attachment.cgi?id=215211&action=edit Kernel log -- You are receiving this mail because: You are watching the assignee of the bug.
[Bug 117591] amdgpu: Black screens on A10-8700P (Carrizo) + R7 M260/M265 (Topaz) Combo
https://bugzilla.kernel.org/show_bug.cgi?id=117591 --- Comment #3 from Jani Väinölä --- Created attachment 215201 --> https://bugzilla.kernel.org/attachment.cgi?id=215201&action=edit xorg.log -- You are receiving this mail because: You are watching the assignee of the bug.
[Bug 117591] amdgpu: Black screens on A10-8700P (Carrizo) + R7 M260/M265 (Topaz) Combo
https://bugzilla.kernel.org/show_bug.cgi?id=117591 --- Comment #2 from Jani Väinölä --- Created attachment 215191 --> https://bugzilla.kernel.org/attachment.cgi?id=215191&action=edit xrandr outputs after the black screen This is what I get after the black screen (taken with ssh -X) -- You are receiving this mail because: You are watching the assignee of the bug.
[Bug 117591] amdgpu: Black screens on A10-8700P (Carrizo) + R7 M260/M265 (Topaz) Combo
https://bugzilla.kernel.org/show_bug.cgi?id=117591 --- Comment #1 from Jani Väinölä --- Created attachment 215181 --> https://bugzilla.kernel.org/attachment.cgi?id=215181&action=edit xrandr outputs before the black screen This is what I get with xrandr commands before I get the black screen -- You are receiving this mail because: You are watching the assignee of the bug.
[Bug 117591] New: amdgpu: Black screens on A10-8700P (Carrizo) + R7 M260/M265 (Topaz) Combo
https://bugzilla.kernel.org/show_bug.cgi?id=117591 Bug ID: 117591 Summary: amdgpu: Black screens on A10-8700P (Carrizo) + R7 M260/M265 (Topaz) Combo Product: Drivers Version: 2.5 Kernel Version: 4.4.0-21-generic Hardware: x86-64 OS: Linux Tree: Mainline Status: NEW Severity: normal Priority: P1 Component: Video(DRI - non Intel) Assignee: drivers_video-dri at kernel-bugs.osdl.org Reporter: jani.vainola at gmail.com Regression: No Created attachment 215171 --> https://bugzilla.kernel.org/attachment.cgi?id=215171&action=edit dmesg Getting black screens after fresh install on HP pavillion laptop with A10-8700P (Carrizo) + R7 M260/M265 (Topaz). Happened both in Ubuntu, Antergos and Debian (Testing). The computer is still running and I can access it and operate it via SSH. It just seems that the driver is unloaded in some way. The blackscreen can occur basically at any time after login. Sometimes it occurs directly after login, sometimes a bit later, but it hasn't been longer than 5 min. -- You are receiving this mail because: You are watching the assignee of the bug.
[Intel-gfx] [PATCH 1/3] drm/i915: Check pixel rate for DP to VGA dongle
On Tue, May 03, 2016 at 04:28:00PM +0200, Daniel Vetter wrote:
> On Tue, May 03, 2016 at 04:23:34PM +0300, Ville Syrjälä wrote:
> > On Tue, May 03, 2016 at 02:46:36PM +0300, Mika Kahola wrote:
> > > Prep work to improve DP branch device handling.
> > >
> > > Filter out a mode that exceeds the max pixel rate setting
> > > for DP to VGA dongle. This is defined in DPCD register 0x81
> > > if detailed cap info i.e. info field is 4 bytes long and
> > > it is available for DP downstream port.
> > >
> > > The register defines the pixel rate divided by 8 in MP/s.
> > >
> > > Signed-off-by: Mika Kahola
> > > ---
> > > drivers/gpu/drm/i915/intel_dp.c | 34 ++
> > > drivers/gpu/drm/i915/intel_drv.h | 9 +
> > > 2 files changed, 43 insertions(+)
> > >
> > > diff --git a/drivers/gpu/drm/i915/intel_dp.c
> > > b/drivers/gpu/drm/i915/intel_dp.c
> > > index 3633002..74a04ce 100644
> > > --- a/drivers/gpu/drm/i915/intel_dp.c
> > > +++ b/drivers/gpu/drm/i915/intel_dp.c
> > > @@ -201,6 +201,13 @@ intel_dp_mode_valid(struct drm_connector *connector,
> > > int max_rate, mode_rate, max_lanes, max_link_clock;
> > > int max_dotclk = to_i915(connector->dev)->max_dotclk_freq;
> > >
> > > + /* DP to VGA dongle may define max pixel rate in DPCD */
> > > + if (intel_dp->dfp.present &&
> > > + intel_dp->dfp.detailed_cap_info &&
> > > + (intel_dp->dfp.type & DP_DS_PORT_TYPE_VGA) &&
> > > + (intel_dp->dfp.dot_clk > 0))
> > > + max_dotclk = min(max_dotclk, intel_dp->dfp.dot_clk);
> >
> > What's dfp?
> >
> > Looks like most of this stuff is not really needed. Just storing a max
> > dotclock per downstream port would seem to suffice.
> >
> > > +
> > > if (is_edp(intel_dp) && fixed_mode) {
> > > if (mode->hdisplay > fixed_mode->hdisplay)
> > > return MODE_PANEL;
> > > @@ -4566,6 +4573,28 @@ static const struct drm_encoder_funcs
> > > intel_dp_enc_funcs = {
> > > .destroy = intel_dp_encoder_destroy,
> > > };
> > >
> > > +static void intel_dp_get_dfp(struct intel_dp *intel_dp)
> > > +{
> > > + uint8_t dfp_info[4];
> > > +
> > > + intel_dp->dfp.detailed_cap_info =
> > > intel_dp->dpcd[DP_DOWNSTREAMPORT_PRESENT] &
> > > DP_DETAILED_CAP_INFO_AVAILABLE;
> > > +
> > > + if (drm_dp_dpcd_read(&intel_dp->aux, DP_DOWNSTREAM_PORT_0, dfp_info, 4)
> > > < 0) {
> > > + intel_dp->dfp.present = false;
> > > + intel_dp->dfp.detailed_cap_info = false;
> > > + return; /* aux transfer failed */
> > > + }
> > > +
> > > + intel_dp->dfp.type = dfp_info[0] & DP_DS_PORT_TYPE_MASK;
> > > +
> > > + if (intel_dp->dfp.detailed_cap_info) {
> > > + if (intel_dp->dfp.type & DP_DS_PORT_TYPE_VGA) {
> > > + intel_dp->dfp.dot_clk = dfp_info[1] * 8 * 1000;
> > > + DRM_DEBUG_KMS("max pixel rate for VGA is %d kHz\n",
> > > intel_dp->dfp.dot_clk);
> > > + }
> >
> > I would suggest putting this sort of stuff into the dp helper. I once
> > started to hatch something to deal with these downstream port limits,
> > but never finished it. I pushed my WIP stuff (mostly ideas how to parse
> > these port caps) to
> >
> > git://github.com/vsyrjala/linux.git dp_downstream_ports
> >
> > maybe you can to see if there's anything useful for you there.
>
> Seconded on at least moving the computation into the dp helpers. i915.ko
> really should only ask the helpers for the final result, maybe with an
> intermediate step to cache the dp aux register stuff. There's already some
> structures in the dp helpers to store sink state, we could start using
> those (unfortunately they're not agreeing on what the canonical one should
> be).
Yeah that thing is a bit of mess right now. As usual, I have a branch to
clean some of it up a bit. Mainly aiming to respect the sink HDMI TMDS
clock limits better. But I need to get the DP++ stuff landed before
I continue with that.
--
Ville Syrjälä
Intel OTC
[PATCH] drm: sun4i: print DMA address correctly
The newly added sun4i drm driver prints a dma address using the %x
format string, which cannot work when dma_addr_t is 64 bit,
and gcc warns about this configuration:
drm/sun4i/sun4i_backend.c: In function 'sun4i_backend_update_layer_buffer':
drm/sun4i/sun4i_backend.c:193:84: error: format '%x' expects argument of type
'unsigned int', but argument 3 has type 'dma_addr_t {aka long long unsigned
int}' [-Werror=format=]
DRM_DEBUG_DRIVER("Using GEM @ 0x%x\n", gem->paddr);
drm/sun4i/sun4i_backend.c:201:84: error: format '%x' expects argument of type
'unsigned int', but argument 3 has type 'dma_addr_t {aka long long unsigned
int}' [-Werror=format=]
DRM_DEBUG_DRIVER("Setting buffer address to 0x%x\n", paddr);
This changes the code to use the explicit %pad format string, which
always prints the right length.
Signed-off-by: Arnd Bergmann
---
drivers/gpu/drm/sun4i/sun4i_backend.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/sun4i/sun4i_backend.c
b/drivers/gpu/drm/sun4i/sun4i_backend.c
index f7a15c1a93bf..3ab560450a82 100644
--- a/drivers/gpu/drm/sun4i/sun4i_backend.c
+++ b/drivers/gpu/drm/sun4i/sun4i_backend.c
@@ -190,7 +190,7 @@ int sun4i_backend_update_layer_buffer(struct sun4i_backend
*backend,
/* Get the physical address of the buffer in memory */
gem = drm_fb_cma_get_gem_obj(fb, 0);
- DRM_DEBUG_DRIVER("Using GEM @ 0x%x\n", gem->paddr);
+ DRM_DEBUG_DRIVER("Using GEM @ %pad\n", &gem->paddr);
/* Compute the start of the displayed memory */
bpp = drm_format_plane_cpp(fb->pixel_format, 0);
@@ -198,7 +198,7 @@ int sun4i_backend_update_layer_buffer(struct sun4i_backend
*backend,
paddr += (state->src_x >> 16) * bpp;
paddr += (state->src_y >> 16) * fb->pitches[0];
- DRM_DEBUG_DRIVER("Setting buffer address to 0x%x\n", paddr);
+ DRM_DEBUG_DRIVER("Setting buffer address to %pad\n", &paddr);
/* Write the 32 lower bits of the address (in bits) */
lo_paddr = paddr << 3;
--
2.7.0
[Bug 94708] Open source radeon drivers not working properly with Radeon HD 8550M
https://bugs.freedesktop.org/show_bug.cgi?id=94708 --- Comment #15 from Arthur Hrast Essenfelder --- (In reply to Alex Deucher from comment #13) > gears is not a good test for PRIME systems. It basically tests how fast the > driver can swap buffers. With PRIME the dGPU rendered buffers ends up > getting copied several times before getting to the IGP. Dear Alex, Thank you for your reply. Could you please tell me a test I can run to verify this issue? I tried also glmark2 and glxspheres64, none of which showing better results. Also when gaming this behaviour is observable. Cheers, Arthur -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20160503/43d20c2a/attachment.html>
[Bug 76490] Hang during boot when DPM is on (R9 270X)
https://bugs.freedesktop.org/show_bug.cgi?id=76490 --- Comment #111 from Alex Deucher --- (In reply to thirdloop from comment #110) > Created attachment 123371 [details] > sapphire nitro r7 370 4gb lspci -vnn output > > I'm on ubuntu 16.04 (can't use the fglrx driver anymore) and I have been > trying the most recent kernels, but I think the SAPPHIRE NITRO R7 370 4GB > still suffers from this bug. > Product link just in case... > http://www.newegg.com/Product/Product. > aspx?Item=N82E16814202152&cm_re=sapphire_nitro_r7_370-_-14-202-152-_-Product > Can anyone help me out please? Attaching lspci -vnn output. Already fixed in this patch: http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=0e5585dc870af947fab2af96a88c2d8b4270247c -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20160503/66e0c670/attachment.html>
[Bug 94708] Open source radeon drivers not working properly with Radeon HD 8550M
https://bugs.freedesktop.org/show_bug.cgi?id=94708 --- Comment #14 from Marko Tikvic --- I was about to say the same thing about gears. I see now that I have not mentioned another issue when using discrete card: If I play a video in browser or with a media player and go to full screen I can clearly see some image corruption bellow or over the main diagonal (imagine picture being made of two triangles). The problem is more severe as more pixels need to be rendered, on still portions of video the corruption is not as visible. I assume not many people can dedicate their time to solving this so I will keep posting here as new kernel and driver packages versions get uploaded to debian repos. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20160503/0b828c97/attachment.html>
[Bug 94708] Open source radeon drivers not working properly with Radeon HD 8550M
https://bugs.freedesktop.org/show_bug.cgi?id=94708 --- Comment #13 from Alex Deucher --- (In reply to Arthur Hrast Essenfelder from comment #12) > # vblank_mode=0 glxgears > ATTENTION: default value of option vblank_mode overridden by environment. > ATTENTION: default value of option vblank_mode overridden by environment. > 35719 frames in 5.0 seconds = 7143.730 FPS > 35715 frames in 5.0 seconds = 7142.853 FPS > 34593 frames in 5.0 seconds = 6910.545 FPS > > # DRI_PRIME=1 vblank_mode=0 glxgears > ATTENTION: default value of option vblank_mode overridden by environment. > 8298 frames in 5.0 seconds = 1659.484 FPS > 8313 frames in 5.0 seconds = 1662.389 FPS > 8315 frames in 5.0 seconds = 1662.897 FPS > gears is not a good test for PRIME systems. It basically tests how fast the driver can swap buffers. With PRIME the dGPU rendered buffers ends up getting copied several times before getting to the IGP. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20160503/2bd12409/attachment-0001.html>
[Bug 94708] Open source radeon drivers not working properly with Radeon HD 8550M
https://bugs.freedesktop.org/show_bug.cgi?id=94708 --- Comment #12 from Arthur Hrast Essenfelder --- I am also facing a similar issue. I also get very low performance when using the DIS Card and the radeon driver in comparison with the IGD Intel card. # vblank_mode=0 glxgears ATTENTION: default value of option vblank_mode overridden by environment. ATTENTION: default value of option vblank_mode overridden by environment. 35719 frames in 5.0 seconds = 7143.730 FPS 35715 frames in 5.0 seconds = 7142.853 FPS 34593 frames in 5.0 seconds = 6910.545 FPS # DRI_PRIME=1 vblank_mode=0 glxgears ATTENTION: default value of option vblank_mode overridden by environment. 8298 frames in 5.0 seconds = 1659.484 FPS 8313 frames in 5.0 seconds = 1662.389 FPS 8315 frames in 5.0 seconds = 1662.897 FPS I posted this issue a few days ago on ask.fedoraproject.org but so far no luck: https://ask.fedoraproject.org/en/question/87235/low-performance-when-using-the-dis-card/ In any case, I think this is the best place to seek help. Here are more details on my system: Distributor ID:Fedora Description:Fedora release 23 (Twenty Three) # lspci | grep VGA 00:02.0 VGA compatible controller: Intel Corporation 2nd Generation Core Processor Family Integrated Graphics Controller (rev 09) 01:00.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI] Whistler [Radeon HD 6730M/6770M/7690M XT] # cat /sys/kernel/debug/vgaswitcheroo/switch 0:IGD:+:Pwr::00:02.0 1:DIS: :Pwr::01:00.0 # glxinfo | grep "OpenGL renderer" OpenGL renderer string: Mesa DRI Intel(R) Sandybridge Mobile # DRI_PRIME=1 glxinfo | grep "OpenGL renderer" OpenGL renderer string: Gallium 0.4 on AMD TURKS (DRM 2.43.0, LLVM 3.7.0) # Xorg -version X.Org X Server 1.18.3 -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20160503/ed8d8b81/attachment.html>
[Intel-gfx] [PATCH v2 1/4] drm: Add helper for DP++ adaptors
On Tue, May 03, 2016 at 10:46:26AM +0300, Jani Nikula wrote: > On Mon, 02 May 2016, ville.syrjala at linux.intel.com wrote: > > From: Ville Syrjälä > > > > Add a helper which aids in the identification of DP dual mode > > (aka. DP++) adaptors. There are several types of adaptors > > specified: type 1 DVI, type 1 HDMI, type 2 DVI, type 2 HDMI > > > > Type 1 adaptors have a max TMDS clock limit of 165MHz, type 2 adaptors > > may go as high as 300MHz and they provide a register informing the > > source device what the actual limit is. Supposedly also type 1 adaptors > > may optionally implement this register. This TMDS clock limit is the > > main reason why we need to identify these adaptors. > > > > Type 1 adaptors provide access to their internal registers and the sink > > DDC bus through I2C. Type 2 adaptors provide this access both via I2C > > and I2C-over-AUX. A type 2 source device may choose to implement either > > of these methods. If a source device implements the I2C-over-AUX > > method, then the driver will obviously need specific support for such > > adaptors since the port is driven like an HDMI port, but DDC > > communication happes over the AUX channel. > > > > This helper should be enough to identify the adaptor type (some > > type 1 DVI adaptors may be a slight exception) and the maximum TMDS > > clock limit. Another feature that may be available is control over > > the TMDS output buffers on the adaptor, possibly allowing for some > > power saving when the TMDS link is down. > > > > Other user controllable features that may be available in the adaptors > > are downstream i2c bus speed control when using i2c-over-aux, and > > some control over the CEC pin. I chose not to provide any helper > > functions for those since I have no use for them in i915 at this time. > > The rest of the registers in the adaptor are mostly just information, > > eg. IEEE OUI, hardware and firmware revision, etc. > > > > v2: Pass adaptor type to helper functions to ease driver implementation > > Fix a bunch of typoes (Paulo) > > Add DRM_DP_DUAL_MODE_UNKNOWN for the case where we don't (yet) know > > the type (Paulo) > > Reject 0x00 and 0xff DP_DUAL_MODE_MAX_TMDS_CLOCK values (Paulo) > > Adjust drm_dp_dual_mode_detect() type2 vs. type1 detection to > > ease future LSPCON enabling > > Remove the unused DP_DUAL_MODE_LAST_RESERVED define > > > > Cc: stable at vger.kernel.org > > Cc: Tore Anderson > > Cc: Paulo Zanoni > > Cc: Shashank Sharma > > Cc: Daniel Vetter > > Signed-off-by: Ville Syrjälä > > --- > > drivers/gpu/drm/Makefile | 2 +- > > drivers/gpu/drm/drm_dp_dual_mode_helper.c | 356 > > ++ > > include/drm/drm_dp_dual_mode_helper.h | 83 +++ > > 3 files changed, 440 insertions(+), 1 deletion(-) > > create mode 100644 drivers/gpu/drm/drm_dp_dual_mode_helper.c > > create mode 100644 include/drm/drm_dp_dual_mode_helper.h > > > > diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile > > index 1a26b4eb1ce0..29f2ee9b9534 100644 > > --- a/drivers/gpu/drm/Makefile > > +++ b/drivers/gpu/drm/Makefile > > @@ -23,7 +23,7 @@ drm-$(CONFIG_AGP) += drm_agpsupport.o > > > > drm_kms_helper-y := drm_crtc_helper.o drm_dp_helper.o drm_probe_helper.o \ > > drm_plane_helper.o drm_dp_mst_topology.o drm_atomic_helper.o \ > > - drm_kms_helper_common.o > > + drm_kms_helper_common.o drm_dp_dual_mode_helper.o > > > > drm_kms_helper-$(CONFIG_DRM_LOAD_EDID_FIRMWARE) += drm_edid_load.o > > drm_kms_helper-$(CONFIG_DRM_FBDEV_EMULATION) += drm_fb_helper.o > > diff --git a/drivers/gpu/drm/drm_dp_dual_mode_helper.c > > b/drivers/gpu/drm/drm_dp_dual_mode_helper.c > > new file mode 100644 > > index ..949c0fbeb542 > > --- /dev/null > > +++ b/drivers/gpu/drm/drm_dp_dual_mode_helper.c > > @@ -0,0 +1,356 @@ > > +/* > > + * Copyright © 2016 Intel Corporation > > + * > > + * Permission is hereby granted, free of charge, to any person obtaining a > > + * copy of this software and associated documentation files (the > > "Software"), > > + * to deal in the Software without restriction, including without > > limitation > > + * the rights to use, copy, modify, merge, publish, distribute, sublicense, > > + * and/or sell copies of the Software, and to permit persons to whom the > > + * Software is furnished to do so, subject to the following conditions: > > + * > > + * The above copyright notice and this permission notice shall be included > > in > > + * all copies or substantial portions of the Software. > > + * > > + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS > > OR > > + * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, > > + * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL > > + * THE COPYRIGHT HOLDER(S) OR AUTHOR(S) BE LIABLE FOR ANY CLAIM, DAMAGES OR > > + * OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT O
[Intel-gfx] [PATCH] drm/i915: Discard previous atomic state on resume if connectors change
On Tue, May 03, 2016 at 10:03:40AM -0400, Lyude wrote:
> If an MST device is disconnected while the machine is suspended, the
> number of connectors will change as well after we call
> intel_dp_mst_resume(). This means that any previous atomic state we had
> before suspending is no longer valid, since it'll still be pointing to
> missing connectors. We need to check for this before committing the
> state, otherwise we'll kernel panic on resume whenever if any MST
> display was disconnected before we started resuming:
>
> BUG: unable to handle kernel NULL pointer dereference at 0008
> IP: [] drm_atomic_helper_check_modeset+0x29f/0xb40
> [drm_kms_helper]
> Call Trace:
> [] intel_atomic_check+0x34/0x1180 [i915]
> [] ? mark_held_locks+0x6f/0xa0
> [] ? trace_hardirqs_on_caller+0x129/0x1b0
> [] drm_atomic_check_only+0x192/0x620 [drm]
> [] ? pci_pm_thaw+0x21/0x90
> [] drm_atomic_commit+0x17/0x60 [drm]
> [] intel_display_resume+0xbd/0x160 [i915]
> [] ? pci_pm_thaw+0x90/0x90
> [] i915_drm_resume+0xd8/0x160 [i915]
> [] i915_pm_resume+0x25/0x30 [i915]
> [] pci_pm_resume+0x64/0xa0
> [] dpm_run_callback+0x90/0x190
> [] device_resume+0xd5/0x1f0
> [] async_resume+0x1d/0x50
> [] async_run_entry_fn+0x48/0x150
> [] process_one_work+0x1e9/0x5c0
> [] ? process_one_work+0x166/0x5c0
> [] worker_thread+0x48/0x4e0
> [] ? process_one_work+0x5c0/0x5c0
> [] kthread+0xe4/0x100
> [] ret_from_fork+0x22/0x50
> [] ? kthread_create_on_node+0x200/0x200
>
> Cc: stable at vger.kernel.org
> Signed-off-by: Lyude
This should be addressed by the connector refcounting fixes Dave Airlie
has for 4.7 (not all merged yet though). Can you please retest with those?
-Daniel
> ---
> drivers/gpu/drm/i915/intel_display.c | 11 +++
> 1 file changed, 11 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/intel_display.c
> b/drivers/gpu/drm/i915/intel_display.c
> index 6e0d828..252c06c 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -15945,6 +15945,17 @@ void intel_display_resume(struct drm_device *dev)
> dev_priv->modeset_restore_state = NULL;
>
> /*
> + * With MST, the number of connectors can change between suspend and
> + * resume, which means that the state we want to restore might now be
> + * impossible to use since it'll be pointing to non-existant
> + * connectors.
> + */
> + if (state->num_connector != dev->mode_config.num_connector) {
> + drm_atomic_state_free(state);
> + state = NULL;
> + }
> +
> + /*
>* This is a cludge because with real atomic modeset mode_config.mutex
>* won't be taken. Unfortunately some probed state like
>* audio_codec_enable is still protected by mode_config.mutex, so lock
> --
> 2.5.5
>
> ___
> Intel-gfx mailing list
> Intel-gfx at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
[PATCH 9/9] dt-bindings: msm/dsi: Add assigned clocks bindings
The PLL in the DSI PHY block generates 2 clock outputs (Byte and Pixel clocks) that are fed into the Multimedia Clock Controller (MMCC). The MMCC uses these as source clocks for some of its RCGs to generate clocks that finally feed to the DSI host controller. Use the assigned clocks DT bindings to set up the MMCC RCGs that feed to the DSI host. Use the DSI PHY provided clocks to set up the parents of these assigned clocks. Signed-off-by: Archit Taneja --- Documentation/devicetree/bindings/display/msm/dsi.txt | 15 +++ 1 file changed, 15 insertions(+) diff --git a/Documentation/devicetree/bindings/display/msm/dsi.txt b/Documentation/devicetree/bindings/display/msm/dsi.txt index 0223f06..686f475 100644 --- a/Documentation/devicetree/bindings/display/msm/dsi.txt +++ b/Documentation/devicetree/bindings/display/msm/dsi.txt @@ -22,6 +22,10 @@ Required properties: * "core_clk" For DSIv2, we need an additional clock: * "src_clk" +- assigned-clocks: Parents of "byte_clk" and "pixel_clk" for the given platform. + See [1] for more details. +- assigned-clock-parents: The Byte clock and Pixel clock PLL outputs provided + by a DSI PHY block. - vdd-supply: phandle to vdd regulator device node - vddio-supply: phandle to vdd-io regulator device node - vdda-supply: phandle to vdda regulator device node @@ -90,6 +94,8 @@ Required properties: * "dsi_pll" * "dsi_phy" * "dsi_phy_regulator" +- clock-cells: Must be 1. The DSI PHY block acts as a clock provider, creating + 2 clocks: A byte clock (index 0), and a pixel clock (index 1). - qcom,dsi-phy-index: The ID of DSI PHY hardware instance. This should be 0 or 1, since we have 2 DSI PHYs at most for now. - power-domains: Should be <&mmcc MDSS_GDSC>. @@ -132,6 +138,14 @@ Example: <&mmcc MDSS_AHB_CLK>, <&mmcc MDSS_MDP_CLK>, <&mmcc MDSS_PCLK0_CLK>; + + assigned-clocks = +<&mmcc BYTE0_CLK_SRC>, +<&mmcc PCLK0_CLK_SRC>; + assigned-clock-parents = +<&dsi0_phy 0>, +<&dsi0_phy 1>; + vdda-supply = <&pma8084_l2>; vdd-supply = <&pma8084_l22>; vddio-supply = <&pma8084_l12>; @@ -195,6 +209,7 @@ Example: <0xfd922d80 0x7b>; clock-names = "iface_clk"; clocks = <&mmcc MDSS_AHB_CLK>; + #clock-cells = <1>; vddio-supply = <&pma8084_l12>; qcom,dsi-phy-regulator-ldo-mode; -- The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, hosted by The Linux Foundation
[PATCH 8/9] dt-bindings: msm/dsi: Modify port and PHY bindings
The DSI node now has two ports that describe the connection between the
MDP interface output and the DSI input, and the connection between the DSI
output and the connected panel/bridge. Update the properties and the
example.
Also, use generic PHY bindings instead of the custom one.
Signed-off-by: Archit Taneja
---
.../devicetree/bindings/display/msm/dsi.txt| 53 +++---
1 file changed, 37 insertions(+), 16 deletions(-)
diff --git a/Documentation/devicetree/bindings/display/msm/dsi.txt
b/Documentation/devicetree/bindings/display/msm/dsi.txt
index bf41d7c..0223f06 100644
--- a/Documentation/devicetree/bindings/display/msm/dsi.txt
+++ b/Documentation/devicetree/bindings/display/msm/dsi.txt
@@ -25,12 +25,18 @@ Required properties:
- vdd-supply: phandle to vdd regulator device node
- vddio-supply: phandle to vdd-io regulator device node
- vdda-supply: phandle to vdda regulator device node
-- qcom,dsi-phy: phandle to DSI PHY device node
+- phys: phandle to DSI PHY device node
+- phy-names: the name of the corresponding PHY device
- syscon-sfpb: A phandle to mmss_sfpb syscon node (only for DSIv2)
+- ports: Contains 2 DSI controller ports as child nodes. Each port contains
+ an endpoint subnode as defined in [2] and [3]. port at 0 describes the
+ connection between the MDP interface output and the DSI input. port at 1
+ describes the connection between the DSI output and the connected
+ panel/bridge.
Optional properties:
- panel at 0: Node of panel connected to this DSI controller.
- See files in [2] for each supported panel.
+ See files in [4] for each supported panel.
- qcom,dual-dsi-mode: Boolean value indicating if the DSI controller is
driving a panel which needs 2 DSI links.
- qcom,master-dsi: Boolean value indicating if the DSI controller is driving
@@ -42,15 +48,15 @@ Optional properties:
- pinctrl-names: the pin control state names; should contain "default"
- pinctrl-0: the default pinctrl state (active)
- pinctrl-n: the "sleep" pinctrl state
-- port: DSI controller output port, containing one endpoint subnode.
DSI Endpoint properties:
- - remote-endpoint: set to phandle of the connected panel's endpoint.
-See [3] for device graph info.
+ - remote-endpoint: For port at 0, set to phandle of the connected
panel/bridge's
+input endpoint. For port at 1, set to the MDP interface output.
- qcom,data-lane-map: this describes how the logical DSI lanes are mapped
to the physical lanes on the given platform. The value contained in
index n describes what logical data lane is mapped to the physical data
-lane n (DATAn, where n lies between 0 and 3).
+lane n (DATAn, where n lies between 0 and 3). Only for the endpoint in
+port at 1.
For example:
@@ -97,8 +103,9 @@ Optional properties:
regulator is wanted.
[1] Documentation/devicetree/bindings/clock/clock-bindings.txt
-[2] Documentation/devicetree/bindings/display/panel/
-[3] Documentation/devicetree/bindings/graph.txt
+[2] Documentation/devicetree/bindings/graph.txt
+[3] Documentation/devicetree/bindings/media/video-interfaces.txt
+[4] Documentation/devicetree/bindings/display/panel/
Example:
dsi0: dsi at fd922800 {
@@ -129,7 +136,8 @@ Example:
vdd-supply = <&pma8084_l22>;
vddio-supply = <&pma8084_l12>;
- qcom,dsi-phy = <&dsi_phy0>;
+ phys = <&dsi_phy0>;
+ phy-names ="dsi_phy";
qcom,dual-dsi-mode;
qcom,master-dsi;
@@ -139,6 +147,26 @@ Example:
pinctrl-0 = <&mdss_dsi_active>;
pinctrl-1 = <&mdss_dsi_suspend>;
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port at 0 {
+ reg = <0>;
+ dsi0_in: endpoint {
+ remote-endpoint = <&mdp_intf1_out>;
+ };
+ };
+
+ port at 1 {
+ reg = <1>;
+ dsi0_out: endpoint {
+ remote-endpoint = <&panel_in>;
+ qcom,data-lane-map = <0 1 2 3>;
+ };
+ };
+ };
+
panel: panel at 0 {
compatible = "sharp,lq101r1sx01";
reg = <0>;
@@ -153,13 +181,6 @@ Example:
};
};
};
-
- port {
- dsi0_out: endpoint {
- remote-endpoint = <&panel_in>;
- qcom,data-lane-map = <0 1 2 3>;
- };
- };
};
dsi_phy0: dsi_phy at fd922a00 {
--
The Qualcomm Innovation Center, Inc. is a member of the
[Intel-gfx] [PATCH 1/3] drm/i915: Check pixel rate for DP to VGA dongle
On Tue, May 03, 2016 at 04:23:34PM +0300, Ville Syrjälä wrote:
> On Tue, May 03, 2016 at 02:46:36PM +0300, Mika Kahola wrote:
> > Prep work to improve DP branch device handling.
> >
> > Filter out a mode that exceeds the max pixel rate setting
> > for DP to VGA dongle. This is defined in DPCD register 0x81
> > if detailed cap info i.e. info field is 4 bytes long and
> > it is available for DP downstream port.
> >
> > The register defines the pixel rate divided by 8 in MP/s.
> >
> > Signed-off-by: Mika Kahola
> > ---
> > drivers/gpu/drm/i915/intel_dp.c | 34 ++
> > drivers/gpu/drm/i915/intel_drv.h | 9 +
> > 2 files changed, 43 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/i915/intel_dp.c
> > b/drivers/gpu/drm/i915/intel_dp.c
> > index 3633002..74a04ce 100644
> > --- a/drivers/gpu/drm/i915/intel_dp.c
> > +++ b/drivers/gpu/drm/i915/intel_dp.c
> > @@ -201,6 +201,13 @@ intel_dp_mode_valid(struct drm_connector *connector,
> > int max_rate, mode_rate, max_lanes, max_link_clock;
> > int max_dotclk = to_i915(connector->dev)->max_dotclk_freq;
> >
> > + /* DP to VGA dongle may define max pixel rate in DPCD */
> > + if (intel_dp->dfp.present &&
> > + intel_dp->dfp.detailed_cap_info &&
> > + (intel_dp->dfp.type & DP_DS_PORT_TYPE_VGA) &&
> > + (intel_dp->dfp.dot_clk > 0))
> > + max_dotclk = min(max_dotclk, intel_dp->dfp.dot_clk);
>
> What's dfp?
>
> Looks like most of this stuff is not really needed. Just storing a max
> dotclock per downstream port would seem to suffice.
>
> > +
> > if (is_edp(intel_dp) && fixed_mode) {
> > if (mode->hdisplay > fixed_mode->hdisplay)
> > return MODE_PANEL;
> > @@ -4566,6 +4573,28 @@ static const struct drm_encoder_funcs
> > intel_dp_enc_funcs = {
> > .destroy = intel_dp_encoder_destroy,
> > };
> >
> > +static void intel_dp_get_dfp(struct intel_dp *intel_dp)
> > +{
> > + uint8_t dfp_info[4];
> > +
> > + intel_dp->dfp.detailed_cap_info =
> > intel_dp->dpcd[DP_DOWNSTREAMPORT_PRESENT] & DP_DETAILED_CAP_INFO_AVAILABLE;
> > +
> > + if (drm_dp_dpcd_read(&intel_dp->aux, DP_DOWNSTREAM_PORT_0, dfp_info, 4)
> > < 0) {
> > + intel_dp->dfp.present = false;
> > + intel_dp->dfp.detailed_cap_info = false;
> > + return; /* aux transfer failed */
> > + }
> > +
> > + intel_dp->dfp.type = dfp_info[0] & DP_DS_PORT_TYPE_MASK;
> > +
> > + if (intel_dp->dfp.detailed_cap_info) {
> > + if (intel_dp->dfp.type & DP_DS_PORT_TYPE_VGA) {
> > + intel_dp->dfp.dot_clk = dfp_info[1] * 8 * 1000;
> > + DRM_DEBUG_KMS("max pixel rate for VGA is %d kHz\n",
> > intel_dp->dfp.dot_clk);
> > + }
>
> I would suggest putting this sort of stuff into the dp helper. I once
> started to hatch something to deal with these downstream port limits,
> but never finished it. I pushed my WIP stuff (mostly ideas how to parse
> these port caps) to
>
> git://github.com/vsyrjala/linux.git dp_downstream_ports
>
> maybe you can to see if there's anything useful for you there.
Seconded on at least moving the computation into the dp helpers. i915.ko
really should only ask the helpers for the final result, maybe with an
intermediate step to cache the dp aux register stuff. There's already some
structures in the dp helpers to store sink state, we could start using
those (unfortunately they're not agreeing on what the canonical one should
be).
-Daniel
>
> > + }
> > +}
> > +
> > enum irqreturn
> > intel_dp_hpd_pulse(struct intel_digital_port *intel_dig_port, bool
> > long_hpd)
> > {
> > @@ -4599,6 +4628,11 @@ intel_dp_hpd_pulse(struct intel_digital_port
> > *intel_dig_port, bool long_hpd)
> > power_domain = intel_display_port_aux_power_domain(intel_encoder);
> > intel_display_power_get(dev_priv, power_domain);
> >
> > + intel_dp->dfp.present = intel_dp->dpcd[DP_DOWNSTREAMPORT_PRESENT] & 0x1;
> > +
> > + if (intel_dp->dfp.present)
> > + intel_dp_get_dfp(intel_dp);
> > +
> > if (long_hpd) {
> > /* indicate that we need to restart link training */
> > intel_dp->train_set_valid = false;
> > diff --git a/drivers/gpu/drm/i915/intel_drv.h
> > b/drivers/gpu/drm/i915/intel_drv.h
> > index 21dee3f..9798a59 100644
> > --- a/drivers/gpu/drm/i915/intel_drv.h
> > +++ b/drivers/gpu/drm/i915/intel_drv.h
> > @@ -794,6 +794,13 @@ enum link_m_n_set {
> > M2_N2
> > };
> >
> > +struct intel_dp_dfp {
> > + bool present;
> > + int type;
> > + bool detailed_cap_info;
> > + int dot_clk; /* pixel rate for VGA dongles */
> > +};
> > +
> > struct intel_dp {
> > i915_reg_t output_reg;
> > i915_reg_t aux_ch_ctl_reg;
> > @@ -861,6 +868,8 @@ struct intel_dp {
> >
> > bool train_set_valid;
> >
> > + struct intel_dp_dfp dfp;
> > +
> > /* Displayport compliance testing */
> > unsigned long compliance_test_type;
> > unsigned long compli
[PATCH 7/9] drm/msm/dsi: Use generic PHY bindings
The DSI host links to the DSI PHY device using a custom binding. Switch to
the generic PHY bindings. The DSI PHY driver itself doesn't use the common
PHY framework for now.
Signed-off-by: Archit Taneja
---
drivers/gpu/drm/msm/dsi/dsi.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/msm/dsi/dsi.c b/drivers/gpu/drm/msm/dsi/dsi.c
index 6edcd6f..ec572f8 100644
--- a/drivers/gpu/drm/msm/dsi/dsi.c
+++ b/drivers/gpu/drm/msm/dsi/dsi.c
@@ -29,7 +29,7 @@ static int dsi_get_phy(struct msm_dsi *msm_dsi)
struct platform_device *phy_pdev;
struct device_node *phy_node;
- phy_node = of_parse_phandle(pdev->dev.of_node, "qcom,dsi-phy", 0);
+ phy_node = of_parse_phandle(pdev->dev.of_node, "phys", 0);
if (!phy_node) {
dev_err(&pdev->dev, "cannot find phy device\n");
return -ENXIO;
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
hosted by The Linux Foundation
[PATCH 6/9] drm/msm/dsi: Modify port parsing
The DSI interface is going to have two ports defined in its device node.
The first port is always going to be the link between the MDP output
and the input to DSI, the second port is going to be the link between
the DSI output and the connected panel/bridge:
- - ---
| MDP | --> | DSI | --> | Panel |
- - ---
(Port 0) (Port 1)
Until now, there was only one Port representing the output. Update the
DSI host driver such that it parses Port #1 for a connected device.
Signed-off-by: Archit Taneja
---
drivers/gpu/drm/msm/dsi/dsi_host.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/msm/dsi/dsi_host.c
b/drivers/gpu/drm/msm/dsi/dsi_host.c
index 51fbbf8..15c70ac 100644
--- a/drivers/gpu/drm/msm/dsi/dsi_host.c
+++ b/drivers/gpu/drm/msm/dsi/dsi_host.c
@@ -1616,12 +1616,12 @@ static int dsi_host_parse_dt(struct msm_dsi_host
*msm_host)
}
/*
-* Get the first endpoint node. In our case, dsi has one output port
-* to which the panel is connected. Don't return an error if a port
-* isn't defined. It's possible that there is nothing connected to
-* the dsi output.
+* Get the endpoint of the output port of the DSI host. In our case,
+* this is mapped to port number with reg = 1. Don't return an error if
+* the remote endpoint isn't defined. It's possible that there is
+* nothing connected to the dsi output.
*/
- endpoint = of_graph_get_next_endpoint(np, NULL);
+ endpoint = of_graph_get_endpoint_by_regs(np, 1, -1);
if (!endpoint) {
dev_dbg(dev, "%s: no endpoint\n", __func__);
return 0;
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
hosted by The Linux Foundation
[PATCH 5/9] dt-bindings: msm/dsi: Some binding doc cleanups
Some cleanups:
- Use simpler names for DT nodes in the example
- Fix phandle for specifying data lane mapping in the example.
- Use references instead of dumping Document links everywhere
Signed-off-by: Archit Taneja
---
.../devicetree/bindings/display/msm/dsi.txt| 23 +++---
1 file changed, 12 insertions(+), 11 deletions(-)
diff --git a/Documentation/devicetree/bindings/display/msm/dsi.txt
b/Documentation/devicetree/bindings/display/msm/dsi.txt
index f5948c4..bf41d7c 100644
--- a/Documentation/devicetree/bindings/display/msm/dsi.txt
+++ b/Documentation/devicetree/bindings/display/msm/dsi.txt
@@ -11,8 +11,7 @@ Required properties:
be 0 or 1, since we have 2 DSI controllers at most for now.
- interrupts: The interrupt signal from the DSI block.
- power-domains: Should be <&mmcc MDSS_GDSC>.
-- clocks: device clocks
- See Documentation/devicetree/bindings/clocks/clock-bindings.txt for details.
+- clocks: Phandles to device clocks as descirbed in [1]
- clock-names: the following clocks are required:
* "mdp_core_clk"
* "iface_clk"
@@ -31,8 +30,7 @@ Required properties:
Optional properties:
- panel at 0: Node of panel connected to this DSI controller.
- See files in Documentation/devicetree/bindings/display/panel/ for each
supported
- panel.
+ See files in [2] for each supported panel.
- qcom,dual-dsi-mode: Boolean value indicating if the DSI controller is
driving a panel which needs 2 DSI links.
- qcom,master-dsi: Boolean value indicating if the DSI controller is driving
@@ -48,7 +46,7 @@ Optional properties:
DSI Endpoint properties:
- remote-endpoint: set to phandle of the connected panel's endpoint.
-See Documentation/devicetree/bindings/graph.txt for device graph info.
+See [3] for device graph info.
- qcom,data-lane-map: this describes how the logical DSI lanes are mapped
to the physical lanes on the given platform. The value contained in
index n describes what logical data lane is mapped to the physical data
@@ -89,8 +87,7 @@ Required properties:
- qcom,dsi-phy-index: The ID of DSI PHY hardware instance. This should
be 0 or 1, since we have 2 DSI PHYs at most for now.
- power-domains: Should be <&mmcc MDSS_GDSC>.
-- clocks: device clocks
- See Documentation/devicetree/bindings/clocks/clock-bindings.txt for details.
+- clocks: Phandles to device clocks as descirbed in [1]
- clock-names: the following clocks are required:
* "iface_clk"
- vddio-supply: phandle to vdd-io regulator device node
@@ -99,8 +96,12 @@ Optional properties:
- qcom,dsi-phy-regulator-ldo-mode: Boolean value indicating if the LDO mode PHY
regulator is wanted.
+[1] Documentation/devicetree/bindings/clock/clock-bindings.txt
+[2] Documentation/devicetree/bindings/display/panel/
+[3] Documentation/devicetree/bindings/graph.txt
+
Example:
- mdss_dsi0: qcom,mdss_dsi at fd922800 {
+ dsi0: dsi at fd922800 {
compatible = "qcom,mdss-dsi-ctrl";
qcom,dsi-host-index = <0>;
interrupt-parent = <&mdss_mdp>;
@@ -128,7 +129,7 @@ Example:
vdd-supply = <&pma8084_l22>;
vddio-supply = <&pma8084_l12>;
- qcom,dsi-phy = <&mdss_dsi_phy0>;
+ qcom,dsi-phy = <&dsi_phy0>;
qcom,dual-dsi-mode;
qcom,master-dsi;
@@ -156,12 +157,12 @@ Example:
port {
dsi0_out: endpoint {
remote-endpoint = <&panel_in>;
- lanes = <0 1 2 3>;
+ qcom,data-lane-map = <0 1 2 3>;
};
};
};
- mdss_dsi_phy0: qcom,mdss_dsi_phy at fd922a00 {
+ dsi_phy0: dsi_phy at fd922a00 {
compatible = "qcom,dsi-phy-28nm-hpm";
qcom,dsi-phy-index = <0>;
reg-names =
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
hosted by The Linux Foundation
[PATCH 4/9] dt-bindings: msm/mdp: Remove connector and gpu bindings
The MDP DT node now contains a list of ports that describe how it connects
to external encoder interfaces like DSI and HDMI. These follow the
standard of_graph bindings, and allow us to get rid of the 'connectors'
phandle that contained a list of all the external encoders connected to
MDP.
The GPU phandle is removed too until we figure out what's the right way
to specify it in DT.
Signed-off-by: Archit Taneja
---
.../devicetree/bindings/display/msm/mdp.txt| 75 --
1 file changed, 71 insertions(+), 4 deletions(-)
diff --git a/Documentation/devicetree/bindings/display/msm/mdp.txt
b/Documentation/devicetree/bindings/display/msm/mdp.txt
index a214f6c..5f6ae3c 100644
--- a/Documentation/devicetree/bindings/display/msm/mdp.txt
+++ b/Documentation/devicetree/bindings/display/msm/mdp.txt
@@ -6,7 +6,6 @@ Required properties:
* "qcom,mdp5" - mdp5
- reg: Physical base address and length of the controller's registers.
- interrupts: The interrupt signal from the display controller.
-- connectors: array of phandles for output device(s)
- clocks: device clocks
See ../clocks/clock-bindings.txt for details.
- clock-names: the following clocks are required.
@@ -24,9 +23,33 @@ Required properties:
* "core_clk"
* "lut_clk" (some MDP5 versions may not need this)
* "vsync_clk"
+- ports: contains the list of output ports from MDP. These connect to
interfaces
+ that are external to the MDP hardware, such as HDMI, DSI, EDP etc (LVDS is a
+ special case since it is a part of the MDP block itself).
+
+ Each output port contains an endpoint that describes how it is connected to
an
+ external interface. These are described by the standard properties documented
+ here:
+ Documentation/devicetree/bindings/graph.txt
+ Documentation/devicetree/bindings/media/video-interfaces.txt
+
+ For MDP4, the output port mappings are:
+ Port 0 -> LCDC/LVDS
+ Port 1 -> DSI1 Cmd/Video
+ Port 2 -> DSI2 Cmd/Video
+ Port 3 -> DTV
+
+ For MDP5, the availability of output ports vary across each SoC revision, but
+ they generally have the following mapping:
+ Port 0 -> MDP_INTF0 (eDP)
+ Port 1 -> MDP_INTF1 (DSI1)
+ Port 2 -> MDP_INTF2 (DSI2)
+ Port 3 -> MDP_INTF3 (HDMI)
+
+ See drivers/gpu/drm/msm/mdp/mdp5/mdp5_cfg.c to see what all INTFs a particular
+ SoC revision has enabled.
Optional properties:
-- gpus: phandle for gpu device
- clock-names: the following clocks are optional:
* "lut_clk"
@@ -35,11 +58,25 @@ Example:
/ {
...
- mdp: qcom,mdp at 510 {
+ hdmi: hdmi at 4a0 {
+ ...
+ ports {
+ ...
+ port at 0 {
+ reg = <0>;
+ hdmi_in: endpoint {
+ remote-endpoint = <&mdp_dtv_out>;
+ };
+ };
+ ...
+ };
+ ...
+ };
+
+ mdp: mdp at 510 {
compatible = "qcom,mdp4";
reg = <0x0510 0xf>;
interrupts = ;
- connectors = <&hdmi>;
gpus = <&gpu>;
clock-names =
"core_clk",
@@ -55,5 +92,35 @@ Example:
<&mmcc TV_SRC>,
<&mmcc HDMI_TV_CLK>,
<&mmcc MDP_TV_CLK>;
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port at 0 {
+ reg = <0>;
+ mdp_lvds_out: endpoint {
+ };
+ };
+
+ port at 1 {
+ reg = <1>;
+ mdp_dsi1_out: endpoint {
+ };
+ };
+
+ port at 2 {
+ reg = <2>;
+ mdp_dsi2_out: endpoint {
+ };
+ };
+
+ port at 3 {
+ reg = <3>;
+ mdp_dtv_out: endpoint {
+ remote-endpoint = <&hdmi_in>;
+ };
+ };
+ };
};
};
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
hosted by The Linux Foundation
[PATCH 3/9] drm/msm/mdp: mdp4: Update LCDC/LVDS port parsing
The LCDC port is the first in the list of the output ports in MDP4.
Mention this explicitly in the driver.
Signed-off-by: Archit Taneja
---
drivers/gpu/drm/msm/mdp/mdp4/mdp4_kms.c | 8 ++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/msm/mdp/mdp4/mdp4_kms.c
b/drivers/gpu/drm/msm/mdp/mdp4/mdp4_kms.c
index f8e0cea..cd129f4 100644
--- a/drivers/gpu/drm/msm/mdp/mdp4/mdp4_kms.c
+++ b/drivers/gpu/drm/msm/mdp/mdp4/mdp4_kms.c
@@ -263,9 +263,13 @@ static struct device_node *mdp4_detect_lcdc_panel(struct
drm_device *dev)
struct device_node *endpoint, *panel_node;
struct device_node *np = dev->dev->of_node;
- endpoint = of_graph_get_next_endpoint(np, NULL);
+ /*
+* LCDC/LVDS is the first port described in the list of ports in the
+* MDP4 DT node.
+*/
+ endpoint = of_graph_get_endpoint_by_regs(np, 0, -1);
if (!endpoint) {
- DBG("no endpoint in MDP4 to fetch LVDS panel\n");
+ DBG("no LVDS panel remote endpoint\n");
return NULL;
}
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
hosted by The Linux Foundation
[PATCH 2/9] drm/msm: Drop the gpu binding
The driver currently identifies the GPU components it needs by parsing
a phandle list from the 'gpus' DT property.
This isn't the right binding to go with. So, for now, just search all
device nodes and find the gpu node we need by parsing a list of
compatible strings.
Once we know how to link the kms and gpu drivers, we'll drop this method
and use the correct binding.
Signed-off-by: Archit Taneja
---
drivers/gpu/drm/msm/msm_drv.c | 26 +++---
1 file changed, 19 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/msm/msm_drv.c b/drivers/gpu/drm/msm/msm_drv.c
index 30b8f3b..f717a69 100644
--- a/drivers/gpu/drm/msm/msm_drv.c
+++ b/drivers/gpu/drm/msm/msm_drv.c
@@ -1068,20 +1068,32 @@ static int compare_of(struct device *dev, void *data)
return dev->of_node == data;
}
-static int add_components(struct device *dev, struct component_match
**matchptr,
- const char *name)
+static const char * const msm_compatible_gpus[] = {
+ "qcom,adreno-3xx",
+ "qcom,kgsl-3d0",
+};
+
+/*
+ * We don't know what's the best binding to link the gpu with the drm device.
+ * Fow now, we just hunt for all the possible gpus that we support, and add
them
+ * as components.
+ */
+static int add_gpu_components(struct device *dev,
+ struct component_match **matchptr)
{
- struct device_node *np = dev->of_node;
unsigned i;
- for (i = 0; ; i++) {
+ for (i = 0; i < ARRAY_SIZE(msm_compatible_gpus); i++) {
struct device_node *node;
- node = of_parse_phandle(np, name, i);
+ node = of_find_compatible_node(NULL, NULL,
+ msm_compatible_gpus[i]);
if (!node)
- break;
+ continue;
component_match_add(dev, matchptr, compare_of, node);
+
+ of_node_put(node);
}
return 0;
@@ -1163,7 +1175,7 @@ static int msm_pdev_probe(struct platform_device *pdev)
struct component_match *match = NULL;
add_mdss_components(&pdev->dev, &match);
- add_components(&pdev->dev, &match, "gpus");
+ add_gpu_components(&pdev->dev, &match);
pdev->dev.coherent_dma_mask = DMA_BIT_MASK(32);
return component_master_add_with_match(&pdev->dev, &msm_drm_ops, match);
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
hosted by The Linux Foundation
[PATCH 1/9] drm/msm: Get mdss components via parsing ports
The driver currently identifies all the mdss components it needs by
parsing a phandle list from the 'connectors' DT property.
Instead of this, describe a list of ports that the MDP hardware provides
to the external world. These ports are linked to external encoder
interfaces such as DSI, HDMI in MDSS. These are also the subcomponent
devices that we need add. This description of ports complies with the
generic graph bindings.
In MDP4, the LVDS port's output connects directly to the LVDS panel. In
this case, we don't try to add it as a component.
Signed-off-by: Archit Taneja
---
drivers/gpu/drm/msm/msm_drv.c | 54 ++-
1 file changed, 53 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/msm/msm_drv.c b/drivers/gpu/drm/msm/msm_drv.c
index 955ddfd..30b8f3b 100644
--- a/drivers/gpu/drm/msm/msm_drv.c
+++ b/drivers/gpu/drm/msm/msm_drv.c
@@ -1087,6 +1087,58 @@ static int add_components(struct device *dev, struct
component_match **matchptr,
return 0;
}
+/*
+ * Identify what components need to be added by parsing what the endpoints in
+ * our output ports are we. In the case of LVDS, there is no external component
+ * that we need to add since it's a part of MDP itself.
+ */
+static int add_mdss_components(struct device *dev,
+ struct component_match **matchptr)
+{
+ struct device_node *np = dev->of_node;
+ struct device_node *ep_node;
+
+ for_each_endpoint_of_node(np, ep_node) {
+ struct device_node *intf;
+ struct of_endpoint ep;
+ int ret;
+
+ ret = of_graph_parse_endpoint(ep_node, &ep);
+ if (ret) {
+ dev_err(dev, "unable to parse port endpoint\n");
+ of_node_put(ep_node);
+ return ret;
+ }
+
+ /*
+* The LCDC/LVDS port on MDP4 is a speacial case where the
+* remote-endpoint isn't a component that we need to add
+*/
+ if (of_device_is_compatible(np, "qcom,mdp4") && ep.port == 0) {
+ of_node_put(ep_node);
+ continue;
+ }
+
+ /*
+* It's okay if some of the ports don't have a remote endpoint
+* specified. It just means that the port isn't connected to
+* any external interface.
+*/
+ intf = of_graph_get_remote_port_parent(ep_node);
+ if (!intf) {
+ of_node_put(ep_node);
+ continue;
+ }
+
+ component_match_add(dev, matchptr, compare_of, intf);
+
+ of_node_put(intf);
+ of_node_put(ep_node);
+ }
+
+ return 0;
+}
+
static int msm_drm_bind(struct device *dev)
{
return msm_drm_init(dev, &msm_driver);
@@ -1110,7 +1162,7 @@ static int msm_pdev_probe(struct platform_device *pdev)
{
struct component_match *match = NULL;
- add_components(&pdev->dev, &match, "connectors");
+ add_mdss_components(&pdev->dev, &match);
add_components(&pdev->dev, &match, "gpus");
pdev->dev.coherent_dma_mask = DMA_BIT_MASK(32);
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
hosted by The Linux Foundation
[PATCH 0/9] drm/msm: Fix issues with DT bindings
Currently, none of the upstream Qualcomm DT files have the display device nodes populated, even when the DT binding documents are upstream. I am not aware of all the issues with the bindings which has prevented it from getting merged, but 2 properties "connectors" (maintains a list of all the external interfaces (DSI, HDMI etc)) and "gpus" (list of GPU devices) seem like the ones that can't be merged. This patch set aligns with the graph bindings to describe the connection between the display controller block (MDP) and the external encoder interfaces. This is similar to the graph bindings used by some of the drivers (imx, rockchip), but not exactly the same. These drivers expect a top level "display-subsytem" DT node which lists down the display interface ports to be used. Our implementation just parses the interface ports in the MDP node as is, and add the components that are needed. I've Cc-ed Heiko and Philipp in case they had any comments on this. The 'gpu' property is removed in a hack-ish way. The driver contains a list of all the compatible strings for gpus, and searches the entire OF firmware for a matching node. Once we know what's the right way to link the gpu and display nodes together (if needed at all) we can add the required binding. The rest of the changes are minor cleanups and fixes to prepare the driver and binding documents before we really start adding the display nodes. Archit Taneja (9): drm/msm: Get mdss components via parsing ports drm/msm: Drop the gpu binding drm/msm/mdp: mdp4: Update LCDC/LVDS port parsing dt-bindings: msm/mdp: Remove connector and gpu bindings dt-bindings: msm/dsi: Some binding doc cleanups drm/msm/dsi: Modify port parsing drm/msm/dsi: Use generic PHY bindings dt-bindings: msm/dsi: Modify port and PHY bindings dt-bindings: msm/dsi: Add assigned clocks bindings .../devicetree/bindings/display/msm/dsi.txt| 79 +++-- .../devicetree/bindings/display/msm/mdp.txt| 75 ++-- drivers/gpu/drm/msm/dsi/dsi.c | 2 +- drivers/gpu/drm/msm/dsi/dsi_host.c | 10 +-- drivers/gpu/drm/msm/mdp/mdp4/mdp4_kms.c| 8 ++- drivers/gpu/drm/msm/msm_drv.c | 80 +++--- 6 files changed, 213 insertions(+), 41 deletions(-) -- The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, hosted by The Linux Foundation
[Intel-gfx] [PATCH 3/3] drm/i915: Check HDMI TMDS clock rate from DPCD
On Tue, May 03, 2016 at 02:46:38PM +0300, Mika Kahola wrote:
> Read TMDS clock rate from DPCD for HDMI to filter out
> modes that might require higher TMDS clock rate than
> supported.
>
> Signed-off-by: Mika Kahola
> ---
> drivers/gpu/drm/i915/intel_dp.c | 3 +++
> drivers/gpu/drm/i915/intel_drv.h | 1 +
> drivers/gpu/drm/i915/intel_hdmi.c | 7 ---
> 3 files changed, 8 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
> index 74a04ce..0fd078c 100644
> --- a/drivers/gpu/drm/i915/intel_dp.c
> +++ b/drivers/gpu/drm/i915/intel_dp.c
> @@ -4591,6 +4591,9 @@ static void intel_dp_get_dfp(struct intel_dp *intel_dp)
> if (intel_dp->dfp.type & DP_DS_PORT_TYPE_VGA) {
> intel_dp->dfp.dot_clk = dfp_info[1] * 8 * 1000;
> DRM_DEBUG_KMS("max pixel rate for VGA is %d kHz\n",
> intel_dp->dfp.dot_clk);
> + } else if (!(intel_dp->dfp.type & DP_DS_PORT_TYPE_WIRELESS)) {
> + intel_dp->dfp.tmds_clk = DIV_ROUND_CLOSEST(dfp_info[1]
> * 25 * 1000, 10);
> + DRM_DEBUG_KMS("max TMDS clock is %d kHz\n",
> intel_dp->dfp.tmds_clk);
> }
> }
> }
> diff --git a/drivers/gpu/drm/i915/intel_drv.h
> b/drivers/gpu/drm/i915/intel_drv.h
> index 9798a59..8bf97da 100644
> --- a/drivers/gpu/drm/i915/intel_drv.h
> +++ b/drivers/gpu/drm/i915/intel_drv.h
> @@ -799,6 +799,7 @@ struct intel_dp_dfp {
> int type;
> bool detailed_cap_info;
> int dot_clk; /* pixel rate for VGA dongles */
> + int tmds_clk;
> };
>
> struct intel_dp {
> diff --git a/drivers/gpu/drm/i915/intel_hdmi.c
> b/drivers/gpu/drm/i915/intel_hdmi.c
> index e1012d6..70e8e17 100644
> --- a/drivers/gpu/drm/i915/intel_hdmi.c
> +++ b/drivers/gpu/drm/i915/intel_hdmi.c
> @@ -1170,13 +1170,14 @@ static void pch_post_disable_hdmi(struct
> intel_encoder *encoder)
> static int hdmi_port_clock_limit(struct intel_hdmi *hdmi, bool
> respect_dvi_limit)
> {
> struct drm_device *dev = intel_hdmi_to_dev(hdmi);
> + int tmds_clock = hdmi_to_dig_port(hdmi)->dp.dfp.tmds_clk;
>
> if ((respect_dvi_limit && !hdmi->has_hdmi_sink) || IS_G4X(dev))
> - return 165000;
> + return (tmds_clock > 0 ? min(165000, tmds_clock) : 165000);
> else if (IS_HASWELL(dev) || INTEL_INFO(dev)->gen >= 8)
> - return 30;
> + return (tmds_clock > 0 ? min(30, tmds_clock) : 30);
> else
> - return 225000;
> + return (tmds_clock > 0 ? min(225000, tmds_clock) : 225000);
Changing limits for native HDMI ports isn't going to do much when
dealing with active DP dongles.
> }
>
> static enum drm_mode_status
> --
> 1.9.1
>
> ___
> Intel-gfx mailing list
> Intel-gfx at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Ville Syrjälä
Intel OTC
[PATCH] drm/imx: ipuv3-plane: enable UYVY and VYUY formats
Advertise the DRM_FORMAT_UYVY and DRM_FORMAT_VYUY formats to userspace.
Signed-off-by: Philipp Zabel
---
drivers/gpu/drm/imx/ipuv3-plane.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/gpu/drm/imx/ipuv3-plane.c
b/drivers/gpu/drm/imx/ipuv3-plane.c
index 681ec6e..8c24df7 100644
--- a/drivers/gpu/drm/imx/ipuv3-plane.c
+++ b/drivers/gpu/drm/imx/ipuv3-plane.c
@@ -38,6 +38,8 @@ static const uint32_t ipu_plane_formats[] = {
DRM_FORMAT_RGBX,
DRM_FORMAT_BGRA,
DRM_FORMAT_BGRA,
+ DRM_FORMAT_UYVY,
+ DRM_FORMAT_VYUY,
DRM_FORMAT_YUYV,
DRM_FORMAT_YVYU,
DRM_FORMAT_YUV420,
--
2.8.0.rc3
[Intel-gfx] [PATCH 1/3] drm/i915: Check pixel rate for DP to VGA dongle
On Tue, May 03, 2016 at 02:46:36PM +0300, Mika Kahola wrote:
> Prep work to improve DP branch device handling.
>
> Filter out a mode that exceeds the max pixel rate setting
> for DP to VGA dongle. This is defined in DPCD register 0x81
> if detailed cap info i.e. info field is 4 bytes long and
> it is available for DP downstream port.
>
> The register defines the pixel rate divided by 8 in MP/s.
>
> Signed-off-by: Mika Kahola
> ---
> drivers/gpu/drm/i915/intel_dp.c | 34 ++
> drivers/gpu/drm/i915/intel_drv.h | 9 +
> 2 files changed, 43 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
> index 3633002..74a04ce 100644
> --- a/drivers/gpu/drm/i915/intel_dp.c
> +++ b/drivers/gpu/drm/i915/intel_dp.c
> @@ -201,6 +201,13 @@ intel_dp_mode_valid(struct drm_connector *connector,
> int max_rate, mode_rate, max_lanes, max_link_clock;
> int max_dotclk = to_i915(connector->dev)->max_dotclk_freq;
>
> + /* DP to VGA dongle may define max pixel rate in DPCD */
> + if (intel_dp->dfp.present &&
> + intel_dp->dfp.detailed_cap_info &&
> + (intel_dp->dfp.type & DP_DS_PORT_TYPE_VGA) &&
> + (intel_dp->dfp.dot_clk > 0))
> + max_dotclk = min(max_dotclk, intel_dp->dfp.dot_clk);
What's dfp?
Looks like most of this stuff is not really needed. Just storing a max
dotclock per downstream port would seem to suffice.
> +
> if (is_edp(intel_dp) && fixed_mode) {
> if (mode->hdisplay > fixed_mode->hdisplay)
> return MODE_PANEL;
> @@ -4566,6 +4573,28 @@ static const struct drm_encoder_funcs
> intel_dp_enc_funcs = {
> .destroy = intel_dp_encoder_destroy,
> };
>
> +static void intel_dp_get_dfp(struct intel_dp *intel_dp)
> +{
> + uint8_t dfp_info[4];
> +
> + intel_dp->dfp.detailed_cap_info =
> intel_dp->dpcd[DP_DOWNSTREAMPORT_PRESENT] & DP_DETAILED_CAP_INFO_AVAILABLE;
> +
> + if (drm_dp_dpcd_read(&intel_dp->aux, DP_DOWNSTREAM_PORT_0, dfp_info, 4)
> < 0) {
> + intel_dp->dfp.present = false;
> + intel_dp->dfp.detailed_cap_info = false;
> + return; /* aux transfer failed */
> + }
> +
> + intel_dp->dfp.type = dfp_info[0] & DP_DS_PORT_TYPE_MASK;
> +
> + if (intel_dp->dfp.detailed_cap_info) {
> + if (intel_dp->dfp.type & DP_DS_PORT_TYPE_VGA) {
> + intel_dp->dfp.dot_clk = dfp_info[1] * 8 * 1000;
> + DRM_DEBUG_KMS("max pixel rate for VGA is %d kHz\n",
> intel_dp->dfp.dot_clk);
> + }
I would suggest putting this sort of stuff into the dp helper. I once
started to hatch something to deal with these downstream port limits,
but never finished it. I pushed my WIP stuff (mostly ideas how to parse
these port caps) to
git://github.com/vsyrjala/linux.git dp_downstream_ports
maybe you can to see if there's anything useful for you there.
> + }
> +}
> +
> enum irqreturn
> intel_dp_hpd_pulse(struct intel_digital_port *intel_dig_port, bool long_hpd)
> {
> @@ -4599,6 +4628,11 @@ intel_dp_hpd_pulse(struct intel_digital_port
> *intel_dig_port, bool long_hpd)
> power_domain = intel_display_port_aux_power_domain(intel_encoder);
> intel_display_power_get(dev_priv, power_domain);
>
> + intel_dp->dfp.present = intel_dp->dpcd[DP_DOWNSTREAMPORT_PRESENT] & 0x1;
> +
> + if (intel_dp->dfp.present)
> + intel_dp_get_dfp(intel_dp);
> +
> if (long_hpd) {
> /* indicate that we need to restart link training */
> intel_dp->train_set_valid = false;
> diff --git a/drivers/gpu/drm/i915/intel_drv.h
> b/drivers/gpu/drm/i915/intel_drv.h
> index 21dee3f..9798a59 100644
> --- a/drivers/gpu/drm/i915/intel_drv.h
> +++ b/drivers/gpu/drm/i915/intel_drv.h
> @@ -794,6 +794,13 @@ enum link_m_n_set {
> M2_N2
> };
>
> +struct intel_dp_dfp {
> + bool present;
> + int type;
> + bool detailed_cap_info;
> + int dot_clk; /* pixel rate for VGA dongles */
> +};
> +
> struct intel_dp {
> i915_reg_t output_reg;
> i915_reg_t aux_ch_ctl_reg;
> @@ -861,6 +868,8 @@ struct intel_dp {
>
> bool train_set_valid;
>
> + struct intel_dp_dfp dfp;
> +
> /* Displayport compliance testing */
> unsigned long compliance_test_type;
> unsigned long compliance_test_data;
> --
> 1.9.1
>
> ___
> Intel-gfx mailing list
> Intel-gfx at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Ville Syrjälä
Intel OTC
[PATCH 5/9] dt-bindings: msm/dsi: Some binding doc cleanups
Am Dienstag, den 03.05.2016, 16:27 +0530 schrieb Archit Taneja:
> Some cleanups:
>
> - Use simpler names for DT nodes in the example
> - Fix phandle for specifying data lane mapping in the example.
> - Use references instead of dumping Document links everywhere
>
> Signed-off-by: Archit Taneja
> ---
> .../devicetree/bindings/display/msm/dsi.txt| 23
> +++---
> 1 file changed, 12 insertions(+), 11 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/display/msm/dsi.txt
> b/Documentation/devicetree/bindings/display/msm/dsi.txt
> index f5948c4..bf41d7c 100644
> --- a/Documentation/devicetree/bindings/display/msm/dsi.txt
> +++ b/Documentation/devicetree/bindings/display/msm/dsi.txt
> @@ -11,8 +11,7 @@ Required properties:
>be 0 or 1, since we have 2 DSI controllers at most for now.
> - interrupts: The interrupt signal from the DSI block.
> - power-domains: Should be <&mmcc MDSS_GDSC>.
> -- clocks: device clocks
> - See Documentation/devicetree/bindings/clocks/clock-bindings.txt for
> details.
> +- clocks: Phandles to device clocks as descirbed in [1]
s/descirbed/described/
> - clock-names: the following clocks are required:
>* "mdp_core_clk"
>* "iface_clk"
> @@ -31,8 +30,7 @@ Required properties:
>
> Optional properties:
> - panel at 0: Node of panel connected to this DSI controller.
> - See files in Documentation/devicetree/bindings/display/panel/ for each
> supported
> - panel.
> + See files in [2] for each supported panel.
> - qcom,dual-dsi-mode: Boolean value indicating if the DSI controller is
>driving a panel which needs 2 DSI links.
> - qcom,master-dsi: Boolean value indicating if the DSI controller is driving
> @@ -48,7 +46,7 @@ Optional properties:
>
>DSI Endpoint properties:
>- remote-endpoint: set to phandle of the connected panel's endpoint.
> -See Documentation/devicetree/bindings/graph.txt for device graph info.
> +See [3] for device graph info.
>- qcom,data-lane-map: this describes how the logical DSI lanes are mapped
> to the physical lanes on the given platform. The value contained in
> index n describes what logical data lane is mapped to the physical data
> @@ -89,8 +87,7 @@ Required properties:
> - qcom,dsi-phy-index: The ID of DSI PHY hardware instance. This should
>be 0 or 1, since we have 2 DSI PHYs at most for now.
> - power-domains: Should be <&mmcc MDSS_GDSC>.
> -- clocks: device clocks
> - See Documentation/devicetree/bindings/clocks/clock-bindings.txt for
> details.
> +- clocks: Phandles to device clocks as descirbed in [1]
s/descirbed/described/
> - clock-names: the following clocks are required:
>* "iface_clk"
> - vddio-supply: phandle to vdd-io regulator device node
> @@ -99,8 +96,12 @@ Optional properties:
> - qcom,dsi-phy-regulator-ldo-mode: Boolean value indicating if the LDO mode
> PHY
>regulator is wanted.
>
> +[1] Documentation/devicetree/bindings/clock/clock-bindings.txt
> +[2] Documentation/devicetree/bindings/display/panel/
> +[3] Documentation/devicetree/bindings/graph.txt
> +
> Example:
> - mdss_dsi0: qcom,mdss_dsi at fd922800 {
> + dsi0: dsi at fd922800 {
> compatible = "qcom,mdss-dsi-ctrl";
> qcom,dsi-host-index = <0>;
> interrupt-parent = <&mdss_mdp>;
> @@ -128,7 +129,7 @@ Example:
> vdd-supply = <&pma8084_l22>;
> vddio-supply = <&pma8084_l12>;
>
> - qcom,dsi-phy = <&mdss_dsi_phy0>;
> + qcom,dsi-phy = <&dsi_phy0>;
>
>
> qcom,dual-dsi-mode;
> qcom,master-dsi;
> @@ -156,12 +157,12 @@ Example:
> port {
> dsi0_out: endpoint {
> remote-endpoint = <&panel_in>;
> - lanes = <0 1 2 3>;
> + qcom,data-lane-map = <0 1 2 3>;
See my comment about the CSI-2 data-lanes binding in the other mail,
could the existing binding be reused?
regards
Philipp
[PATCH 8/9] dt-bindings: msm/dsi: Modify port and PHY bindings
Am Dienstag, den 03.05.2016, 16:28 +0530 schrieb Archit Taneja:
> The DSI node now has two ports that describe the connection between the
> MDP interface output and the DSI input, and the connection between the DSI
> output and the connected panel/bridge. Update the properties and the
> example.
>
> Also, use generic PHY bindings instead of the custom one.
>
> Signed-off-by: Archit Taneja
> ---
> .../devicetree/bindings/display/msm/dsi.txt| 53
> +++---
> 1 file changed, 37 insertions(+), 16 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/display/msm/dsi.txt
> b/Documentation/devicetree/bindings/display/msm/dsi.txt
> index bf41d7c..0223f06 100644
> --- a/Documentation/devicetree/bindings/display/msm/dsi.txt
> +++ b/Documentation/devicetree/bindings/display/msm/dsi.txt
> @@ -25,12 +25,18 @@ Required properties:
> - vdd-supply: phandle to vdd regulator device node
> - vddio-supply: phandle to vdd-io regulator device node
> - vdda-supply: phandle to vdda regulator device node
> -- qcom,dsi-phy: phandle to DSI PHY device node
> +- phys: phandle to DSI PHY device node
> +- phy-names: the name of the corresponding PHY device
Should "dsi_phy" be specified here?
Also is there any kind of system to the PHY naming? I've seen more
bindings use hyphen instead of underscore in the name, for example.
I have called the MediaTek MIPI_TX PHY "dphy" for no other reason than
it's a MIPI D-PHY.
> - syscon-sfpb: A phandle to mmss_sfpb syscon node (only for DSIv2)
> +- ports: Contains 2 DSI controller ports as child nodes. Each port contains
> + an endpoint subnode as defined in [2] and [3]. port at 0 describes the
> + connection between the MDP interface output and the DSI input. port at 1
> + describes the connection between the DSI output and the connected
> + panel/bridge.
>
> Optional properties:
> - panel at 0: Node of panel connected to this DSI controller.
> - See files in [2] for each supported panel.
> + See files in [4] for each supported panel.
> - qcom,dual-dsi-mode: Boolean value indicating if the DSI controller is
>driving a panel which needs 2 DSI links.
> - qcom,master-dsi: Boolean value indicating if the DSI controller is driving
> @@ -42,15 +48,15 @@ Optional properties:
> - pinctrl-names: the pin control state names; should contain "default"
> - pinctrl-0: the default pinctrl state (active)
> - pinctrl-n: the "sleep" pinctrl state
> -- port: DSI controller output port, containing one endpoint subnode.
>
>DSI Endpoint properties:
> - - remote-endpoint: set to phandle of the connected panel's endpoint.
> -See [3] for device graph info.
> + - remote-endpoint: For port at 0, set to phandle of the connected
> panel/bridge's
> +input endpoint. For port at 1, set to the MDP interface output.
>- qcom,data-lane-map: this describes how the logical DSI lanes are mapped
> to the physical lanes on the given platform. The value contained in
> index n describes what logical data lane is mapped to the physical data
> -lane n (DATAn, where n lies between 0 and 3).
> +lane n (DATAn, where n lies between 0 and 3). Only for the endpoint in
> +port at 1.
I approve of the of graph change, but I notice that the
qcom,data-lane-map is very similar to the data-lanes property documented
in Documentation/devicetree/bindings/media/video-interfaces.txt for MIPI
CSI-2. Could that maybe be reused for DSI?
> For example:
>
> @@ -97,8 +103,9 @@ Optional properties:
>regulator is wanted.
>
> [1] Documentation/devicetree/bindings/clock/clock-bindings.txt
> -[2] Documentation/devicetree/bindings/display/panel/
> -[3] Documentation/devicetree/bindings/graph.txt
> +[2] Documentation/devicetree/bindings/graph.txt
> +[3] Documentation/devicetree/bindings/media/video-interfaces.txt
> +[4] Documentation/devicetree/bindings/display/panel/
>
> Example:
> dsi0: dsi at fd922800 {
> @@ -129,7 +136,8 @@ Example:
> vdd-supply = <&pma8084_l22>;
> vddio-supply = <&pma8084_l12>;
>
> - qcom,dsi-phy = <&dsi_phy0>;
> + phys = <&dsi_phy0>;
> + phy-names ="dsi_phy";
>
> qcom,dual-dsi-mode;
> qcom,master-dsi;
> @@ -139,6 +147,26 @@ Example:
> pinctrl-0 = <&mdss_dsi_active>;
> pinctrl-1 = <&mdss_dsi_suspend>;
>
> + ports {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + port at 0 {
> + reg = <0>;
> + dsi0_in: endpoint {
> + remote-endpoint = <&mdp_intf1_out>;
> + };
> + };
> +
> + port at 1 {
> + reg = <1>;
> + dsi0_out: endpoint {
> + remote-endpoint = <&panel_in>;
> +
[PATCH 3/9] drm/msm/mdp: mdp4: Update LCDC/LVDS port parsing
Am Dienstag, den 03.05.2016, 16:27 +0530 schrieb Archit Taneja:
> The LCDC port is the first in the list of the output ports in MDP4.
> Mention this explicitly in the driver.
>
> Signed-off-by: Archit Taneja
> ---
> drivers/gpu/drm/msm/mdp/mdp4/mdp4_kms.c | 8 ++--
> 1 file changed, 6 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/msm/mdp/mdp4/mdp4_kms.c
> b/drivers/gpu/drm/msm/mdp/mdp4/mdp4_kms.c
> index f8e0cea..cd129f4 100644
> --- a/drivers/gpu/drm/msm/mdp/mdp4/mdp4_kms.c
> +++ b/drivers/gpu/drm/msm/mdp/mdp4/mdp4_kms.c
> @@ -263,9 +263,13 @@ static struct device_node *mdp4_detect_lcdc_panel(struct
> drm_device *dev)
> struct device_node *endpoint, *panel_node;
> struct device_node *np = dev->dev->of_node;
>
> - endpoint = of_graph_get_next_endpoint(np, NULL);
> + /*
> + * LCDC/LVDS is the first port described in the list of ports in the
> + * MDP4 DT node.
> + */
> + endpoint = of_graph_get_endpoint_by_regs(np, 0, -1);
> if (!endpoint) {
> - DBG("no endpoint in MDP4 to fetch LVDS panel\n");
> + DBG("no LVDS panel remote endpoint\n");
> return NULL;
> }
Oh nice, I wasn't aware of of_graph_get_endpoint_by_regs().
We should switch imx-drm and exynos to use it, too.
regards
Philipp
[PATCH 2/2] drm/imx: parallel-display: use of_graph_get_endpoint_by_regs helper
Instead of using of_graph_get_port_by_id() to get the port and then
of_get_child_by_name() to get the first endpoint, get to the endpoint
in a single step.
Signed-off-by: Philipp Zabel
---
drivers/gpu/drm/imx/parallel-display.c | 24
1 file changed, 12 insertions(+), 12 deletions(-)
diff --git a/drivers/gpu/drm/imx/parallel-display.c
b/drivers/gpu/drm/imx/parallel-display.c
index 363e2c7..27755ec 100644
--- a/drivers/gpu/drm/imx/parallel-display.c
+++ b/drivers/gpu/drm/imx/parallel-display.c
@@ -203,7 +203,7 @@ static int imx_pd_bind(struct device *dev, struct device
*master, void *data)
{
struct drm_device *drm = data;
struct device_node *np = dev->of_node;
- struct device_node *port;
+ struct device_node *ep;
const u8 *edidp;
struct imx_parallel_display *imxpd;
int ret;
@@ -230,18 +230,18 @@ static int imx_pd_bind(struct device *dev, struct device
*master, void *data)
}
/* port at 1 is the output port */
- port = of_graph_get_port_by_id(np, 1);
- if (port) {
- struct device_node *endpoint, *remote;
-
- endpoint = of_get_child_by_name(port, "endpoint");
- if (endpoint) {
- remote = of_graph_get_remote_port_parent(endpoint);
- if (remote)
- imxpd->panel = of_drm_find_panel(remote);
- if (!imxpd->panel)
- return -EPROBE_DEFER;
+ ep = of_graph_get_endpoint_by_regs(np, 1, -1);
+ if (ep) {
+ struct device_node *remote;
+
+ remote = of_graph_get_remote_port_parent(ep);
+ of_node_put(ep);
+ if (remote) {
+ imxpd->panel = of_drm_find_panel(remote);
+ of_node_put(remote);
}
+ if (!imxpd->panel)
+ return -EPROBE_DEFER;
}
imxpd->dev = dev;
--
2.8.0.rc3
[PATCH 1/2] drm/imx: imx-ldb: use of_graph_get_endpoint_by_regs helper
Instead of using of_graph_get_port_by_id() to get the port and then
of_get_child_by_name() to get the first endpoint, get to the endpoint
in a single step.
Signed-off-by: Philipp Zabel
---
drivers/gpu/drm/imx/imx-ldb.c | 35 ++-
1 file changed, 18 insertions(+), 17 deletions(-)
diff --git a/drivers/gpu/drm/imx/imx-ldb.c b/drivers/gpu/drm/imx/imx-ldb.c
index a58eee5..d8e7ba4 100644
--- a/drivers/gpu/drm/imx/imx-ldb.c
+++ b/drivers/gpu/drm/imx/imx-ldb.c
@@ -553,7 +553,7 @@ static int imx_ldb_bind(struct device *dev, struct device
*master, void *data)
for_each_child_of_node(np, child) {
struct imx_ldb_channel *channel;
- struct device_node *port;
+ struct device_node *ep;
ret = of_property_read_u32(child, "reg", &i);
if (ret || i < 0 || i > 1)
@@ -576,22 +576,23 @@ static int imx_ldb_bind(struct device *dev, struct device
*master, void *data)
* The output port is port at 4 with an external 4-port mux or
* port at 2 with the internal 2-port mux.
*/
- port = of_graph_get_port_by_id(child, imx_ldb->lvds_mux ? 4 :
2);
- if (port) {
- struct device_node *endpoint, *remote;
-
- endpoint = of_get_child_by_name(port, "endpoint");
- if (endpoint) {
- remote =
of_graph_get_remote_port_parent(endpoint);
- if (remote)
- channel->panel =
of_drm_find_panel(remote);
- else
- return -EPROBE_DEFER;
- if (!channel->panel) {
- dev_err(dev, "panel not found: %s\n",
- remote->full_name);
- return -EPROBE_DEFER;
- }
+ ep = of_graph_get_endpoint_by_regs(child,
+ imx_ldb->lvds_mux ? 4 : 2,
+ -1);
+ if (ep) {
+ struct device_node *remote;
+
+ remote = of_graph_get_remote_port_parent(ep);
+ of_node_put(ep);
+ if (remote)
+ channel->panel = of_drm_find_panel(remote);
+ else
+ return -EPROBE_DEFER;
+ of_node_put(remote);
+ if (!channel->panel) {
+ dev_err(dev, "panel not found: %s\n",
+ remote->full_name);
+ return -EPROBE_DEFER;
}
}
--
2.8.0.rc3
[PATCH 2/2] drm/exynos/dsi: use of_graph_get_endpoint_by_regs helper
This allows to remove the local of_graph_get_port_by_reg(),
of_graph_get_endpoint_by_reg(), and of_get_child_by_name_reg()
functions.
Signed-off-by: Philipp Zabel
---
drivers/gpu/drm/exynos/exynos_drm_dsi.c | 57 ++---
1 file changed, 3 insertions(+), 54 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_dsi.c
b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
index 63c84a1..61251fe 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_dsi.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
@@ -1641,50 +1641,6 @@ static const struct drm_encoder_funcs
exynos_dsi_encoder_funcs = {
MODULE_DEVICE_TABLE(of, exynos_dsi_of_match);
-/* of_* functions will be removed after merge of of_graph patches */
-static struct device_node *
-of_get_child_by_name_reg(struct device_node *parent, const char *name, u32 reg)
-{
- struct device_node *np;
-
- for_each_child_of_node(parent, np) {
- u32 r;
-
- if (!np->name || of_node_cmp(np->name, name))
- continue;
-
- if (of_property_read_u32(np, "reg", &r) < 0)
- r = 0;
-
- if (reg == r)
- break;
- }
-
- return np;
-}
-
-static struct device_node *of_graph_get_port_by_reg(struct device_node *parent,
- u32 reg)
-{
- struct device_node *ports, *port;
-
- ports = of_get_child_by_name(parent, "ports");
- if (ports)
- parent = ports;
-
- port = of_get_child_by_name_reg(parent, "port", reg);
-
- of_node_put(ports);
-
- return port;
-}
-
-static struct device_node *
-of_graph_get_endpoint_by_reg(struct device_node *port, u32 reg)
-{
- return of_get_child_by_name_reg(port, "endpoint", reg);
-}
-
static int exynos_dsi_of_read_u32(const struct device_node *np,
const char *propname, u32 *out_value)
{
@@ -1706,7 +1662,7 @@ static int exynos_dsi_parse_dt(struct exynos_dsi *dsi)
{
struct device *dev = dsi->dev;
struct device_node *node = dev->of_node;
- struct device_node *port, *ep;
+ struct device_node *ep;
int ret;
ret = exynos_dsi_of_read_u32(node, "samsung,pll-clock-frequency",
@@ -1714,16 +1670,9 @@ static int exynos_dsi_parse_dt(struct exynos_dsi *dsi)
if (ret < 0)
return ret;
- port = of_graph_get_port_by_reg(node, DSI_PORT_OUT);
- if (!port) {
- dev_err(dev, "no output port specified\n");
- return -EINVAL;
- }
-
- ep = of_graph_get_endpoint_by_reg(port, 0);
- of_node_put(port);
+ ep = of_graph_get_endpoint_by_regs(node, DSI_PORT_OUT, 0);
if (!ep) {
- dev_err(dev, "no endpoint specified in output port\n");
+ dev_err(dev, "no output port with endpoint specified\n");
return -EINVAL;
}
--
2.8.0.rc3
[PATCH 1/2] drm/exynos/dpi: use of_graph_get_endpoint_by_regs helper
This allows to remove the local of_graph_get_port_by_reg(),
of_graph_get_endpoint_by_reg(), of_get_child_by_name_reg(),
and of_graph_get_remote_port_parent() functions.
Signed-off-by: Philipp Zabel
---
drivers/gpu/drm/exynos/exynos_drm_dpi.c | 69 +
1 file changed, 2 insertions(+), 67 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_dpi.c
b/drivers/gpu/drm/exynos/exynos_drm_dpi.c
index 75e570f..5e38e74 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_dpi.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_dpi.c
@@ -15,6 +15,7 @@
#include
#include
+#include
#include
#include
@@ -164,67 +165,6 @@ static const struct drm_encoder_funcs
exynos_dpi_encoder_funcs = {
.destroy = drm_encoder_cleanup,
};
-/* of_* functions will be removed after merge of of_graph patches */
-static struct device_node *
-of_get_child_by_name_reg(struct device_node *parent, const char *name, u32 reg)
-{
- struct device_node *np;
-
- for_each_child_of_node(parent, np) {
- u32 r;
-
- if (!np->name || of_node_cmp(np->name, name))
- continue;
-
- if (of_property_read_u32(np, "reg", &r) < 0)
- r = 0;
-
- if (reg == r)
- break;
- }
-
- return np;
-}
-
-static struct device_node *of_graph_get_port_by_reg(struct device_node *parent,
- u32 reg)
-{
- struct device_node *ports, *port;
-
- ports = of_get_child_by_name(parent, "ports");
- if (ports)
- parent = ports;
-
- port = of_get_child_by_name_reg(parent, "port", reg);
-
- of_node_put(ports);
-
- return port;
-}
-
-static struct device_node *
-of_graph_get_endpoint_by_reg(struct device_node *port, u32 reg)
-{
- return of_get_child_by_name_reg(port, "endpoint", reg);
-}
-
-static struct device_node *
-of_graph_get_remote_port_parent(const struct device_node *node)
-{
- struct device_node *np;
- unsigned int depth;
-
- np = of_parse_phandle(node, "remote-endpoint", 0);
-
- /* Walk 3 levels up only if there is 'ports' node. */
- for (depth = 3; depth && np; depth--) {
- np = of_get_next_parent(np);
- if (depth == 2 && of_node_cmp(np->name, "ports"))
- break;
- }
- return np;
-}
-
enum {
FIMD_PORT_IN0,
FIMD_PORT_IN1,
@@ -237,12 +177,7 @@ static struct device_node
*exynos_dpi_of_find_panel_node(struct device *dev)
{
struct device_node *np, *ep;
- np = of_graph_get_port_by_reg(dev->of_node, FIMD_PORT_RGB);
- if (!np)
- return NULL;
-
- ep = of_graph_get_endpoint_by_reg(np, 0);
- of_node_put(np);
+ ep = of_graph_get_endpoint_by_regs(dev->of_node, FIMD_PORT_RGB, 0);
if (!ep)
return NULL;
--
2.8.0.rc3
[Intel-gfx] [PATCH 5/6] drm/atomic: use connector references (v2)
Hi, On 3 May 2016 at 05:28, Dave Airlie wrote: > From: Dave Airlie > > Take a reference when setting a crtc on a connecter, > also take one when duplicating if a crtc is set, > and drop one on destroy if a crtc is set. > > v2: take Daniel Stone's advice and simplify the > ref/unref dances, also take care of NULL as connector > to state reset. > > Signed-off-by: Dave Airlie I expect we'll still end up with all kinds of comedy races here, but on the grounds that it's unambiguously an improvement on what came before, and I can't see anything obviously wrong, for patches 1-5: Reviewed-by: Daniel Stone Cheers, Daniel
[PATCH v3 1/2] drm: bridge: Add sii902x driver
On Tue, May 03, 2016 at 12:03:08PM +0200, Boris Brezillon wrote: > On Tue, 3 May 2016 11:53:18 +0200 > Daniel Vetter wrote: > > > On Tue, May 3, 2016 at 11:39 AM, Boris Brezillon > > wrote: > > >> > + .detect = sii902x_connector_detect, > > >> > + .fill_modes = drm_helper_probe_single_connector_modes, > > >> > + .destroy = sii902x_connector_destroy, > > >> > +}; > > >> > > >> I'm guessing this is to support both atomic and !atomic drivers. I > > >> thought it was working automatically? > > > > > > Hm, the dw-hdmi driver is providing both, but maybe it's not needed. > > > Daniel, any comments? > > > > You only need this in case you actually have atomic and !atomic users > > of your bridge. We discussed whether we should have a dpms helper that > > dtrt automatically, but with just 1 driver that doesn't seem worth it. > > You wouldn't need to have 2 entier vfunc tables, you could just switch > > on DRIVER_ATOMIC. > > Ok, I'll drop the !atomic helpers. Should I still test > drm_core_check_feature(drm, DRIVER_ATOMIC) in the ->attach() > implementation and return an error if the DRM device does not support > atomic operations? If you feel like. If someone tries to use this bridge driver with a non-atomic driver then - they'll have a big fireworks show either way - a really good reason to fix up their driver to be atomic, like it should be ;-) Cheers, Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch
[PATCH v2] MAINTAINERS: Add myself for the new VC4 (RPi GPU) graphics driver.
From: Eric Anholt Signed-off-by: Eric Anholt [Emil Velikov: drop wildcard, add UAPI and Documentation files] Signed-off-by: Emil Velikov --- This patch is rebased/applied on top of the maintainer series from earlier. --- MAINTAINERS | 8 1 file changed, 8 insertions(+) diff --git a/MAINTAINERS b/MAINTAINERS index 92e5a12..f864fd6 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -3980,6 +3980,14 @@ S: Supported F: drivers/gpu/drm/vmwgfx/ F: include/uapi/drm/vmwgfx_drm.h +DRM DRIVERS FOR VC4 +M: Eric Anholt +T: git git://github.com/anholt/linux +S: Supported +F: drivers/gpu/drm/vc4/ +F: include/uapi/drm/vc4_drm.h +F: Documentation/devicetree/bindings/display/brcm,bcm-vc4.txt + DSBR100 USB FM RADIO DRIVER M: Alexey Klimov L: linux-media at vger.kernel.org -- 2.6.2
[PATCH 2/2] drm/amdgpu: make sure vertical front porch is at least 1
hw doesn't like a 0 value. Signed-off-by: Alex Deucher Cc: stable at vger.kernel.org --- drivers/gpu/drm/amd/amdgpu/atombios_encoders.c | 4 1 file changed, 4 insertions(+) diff --git a/drivers/gpu/drm/amd/amdgpu/atombios_encoders.c b/drivers/gpu/drm/amd/amdgpu/atombios_encoders.c index 1e0bba2..1cd6de5 100644 --- a/drivers/gpu/drm/amd/amdgpu/atombios_encoders.c +++ b/drivers/gpu/drm/amd/amdgpu/atombios_encoders.c @@ -298,6 +298,10 @@ bool amdgpu_atombios_encoder_mode_fixup(struct drm_encoder *encoder, && (mode->crtc_vsync_start < (mode->crtc_vdisplay + 2))) adjusted_mode->crtc_vsync_start = adjusted_mode->crtc_vdisplay + 2; + /* vertical FP must be at least 1 */ + if (mode->crtc_vsync_start == mode->crtc_vdisplay) + adjusted_mode->crtc_vsync_start++; + /* get the native mode for scaling */ if (amdgpu_encoder->active_device & (ATOM_DEVICE_LCD_SUPPORT)) amdgpu_panel_mode_fixup(encoder, adjusted_mode); -- 2.5.5
[PATCH 1/2] drm/radeon: make sure vertical front porch is at least 1
hw doesn't like a 0 value.
Signed-off-by: Alex Deucher
Cc: stable at vger.kernel.org
---
drivers/gpu/drm/radeon/atombios_encoders.c | 4
1 file changed, 4 insertions(+)
diff --git a/drivers/gpu/drm/radeon/atombios_encoders.c
b/drivers/gpu/drm/radeon/atombios_encoders.c
index edd05cd..587cae4 100644
--- a/drivers/gpu/drm/radeon/atombios_encoders.c
+++ b/drivers/gpu/drm/radeon/atombios_encoders.c
@@ -310,6 +310,10 @@ static bool radeon_atom_mode_fixup(struct drm_encoder
*encoder,
&& (mode->crtc_vsync_start < (mode->crtc_vdisplay + 2)))
adjusted_mode->crtc_vsync_start = adjusted_mode->crtc_vdisplay
+ 2;
+ /* vertical FP must be at least 1 */
+ if (mode->crtc_vsync_start == mode->crtc_vdisplay)
+ adjusted_mode->crtc_vsync_start++;
+
/* get the native mode for scaling */
if (radeon_encoder->active_device & (ATOM_DEVICE_LCD_SUPPORT)) {
radeon_panel_mode_fixup(encoder, adjusted_mode);
--
2.5.5
[PATCH 3/3] drm/i915: Check HDMI TMDS clock rate from DPCD
Read TMDS clock rate from DPCD for HDMI to filter out
modes that might require higher TMDS clock rate than
supported.
Signed-off-by: Mika Kahola
---
drivers/gpu/drm/i915/intel_dp.c | 3 +++
drivers/gpu/drm/i915/intel_drv.h | 1 +
drivers/gpu/drm/i915/intel_hdmi.c | 7 ---
3 files changed, 8 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 74a04ce..0fd078c 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -4591,6 +4591,9 @@ static void intel_dp_get_dfp(struct intel_dp *intel_dp)
if (intel_dp->dfp.type & DP_DS_PORT_TYPE_VGA) {
intel_dp->dfp.dot_clk = dfp_info[1] * 8 * 1000;
DRM_DEBUG_KMS("max pixel rate for VGA is %d kHz\n",
intel_dp->dfp.dot_clk);
+ } else if (!(intel_dp->dfp.type & DP_DS_PORT_TYPE_WIRELESS)) {
+ intel_dp->dfp.tmds_clk = DIV_ROUND_CLOSEST(dfp_info[1]
* 25 * 1000, 10);
+ DRM_DEBUG_KMS("max TMDS clock is %d kHz\n",
intel_dp->dfp.tmds_clk);
}
}
}
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index 9798a59..8bf97da 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -799,6 +799,7 @@ struct intel_dp_dfp {
int type;
bool detailed_cap_info;
int dot_clk; /* pixel rate for VGA dongles */
+ int tmds_clk;
};
struct intel_dp {
diff --git a/drivers/gpu/drm/i915/intel_hdmi.c
b/drivers/gpu/drm/i915/intel_hdmi.c
index e1012d6..70e8e17 100644
--- a/drivers/gpu/drm/i915/intel_hdmi.c
+++ b/drivers/gpu/drm/i915/intel_hdmi.c
@@ -1170,13 +1170,14 @@ static void pch_post_disable_hdmi(struct intel_encoder
*encoder)
static int hdmi_port_clock_limit(struct intel_hdmi *hdmi, bool
respect_dvi_limit)
{
struct drm_device *dev = intel_hdmi_to_dev(hdmi);
+ int tmds_clock = hdmi_to_dig_port(hdmi)->dp.dfp.tmds_clk;
if ((respect_dvi_limit && !hdmi->has_hdmi_sink) || IS_G4X(dev))
- return 165000;
+ return (tmds_clock > 0 ? min(165000, tmds_clock) : 165000);
else if (IS_HASWELL(dev) || INTEL_INFO(dev)->gen >= 8)
- return 30;
+ return (tmds_clock > 0 ? min(30, tmds_clock) : 30);
else
- return 225000;
+ return (tmds_clock > 0 ? min(225000, tmds_clock) : 225000);
}
static enum drm_mode_status
--
1.9.1
[PATCH 2/3] drm: Add DP port types from DP 1.3 specification
DP specification 1.3 defines DP downstream ports for DP++ and wireless devices. Let's add these to port definitions. Signed-off-by: Mika Kahola --- include/drm/drm_dp_helper.h | 2 ++ 1 file changed, 2 insertions(+) diff --git a/include/drm/drm_dp_helper.h b/include/drm/drm_dp_helper.h index 92d9a52..9a15099 100644 --- a/include/drm/drm_dp_helper.h +++ b/include/drm/drm_dp_helper.h @@ -210,6 +210,8 @@ # define DP_DS_PORT_TYPE_DVI 2 # define DP_DS_PORT_TYPE_HDMI 3 # define DP_DS_PORT_TYPE_NON_EDID 4 +# define DP_DP_PORT_TYPE_DP_DUALMODE5 +# define DP_DS_PORT_TYPE_WIRELESS 6 # define DP_DS_PORT_HPD(1 << 3) /* offset 1 for VGA is maximum megapixels per second / 8 */ /* offset 2 */ -- 1.9.1
[PATCH 1/3] drm/i915: Check pixel rate for DP to VGA dongle
Prep work to improve DP branch device handling.
Filter out a mode that exceeds the max pixel rate setting
for DP to VGA dongle. This is defined in DPCD register 0x81
if detailed cap info i.e. info field is 4 bytes long and
it is available for DP downstream port.
The register defines the pixel rate divided by 8 in MP/s.
Signed-off-by: Mika Kahola
---
drivers/gpu/drm/i915/intel_dp.c | 34 ++
drivers/gpu/drm/i915/intel_drv.h | 9 +
2 files changed, 43 insertions(+)
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 3633002..74a04ce 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -201,6 +201,13 @@ intel_dp_mode_valid(struct drm_connector *connector,
int max_rate, mode_rate, max_lanes, max_link_clock;
int max_dotclk = to_i915(connector->dev)->max_dotclk_freq;
+ /* DP to VGA dongle may define max pixel rate in DPCD */
+ if (intel_dp->dfp.present &&
+ intel_dp->dfp.detailed_cap_info &&
+ (intel_dp->dfp.type & DP_DS_PORT_TYPE_VGA) &&
+ (intel_dp->dfp.dot_clk > 0))
+ max_dotclk = min(max_dotclk, intel_dp->dfp.dot_clk);
+
if (is_edp(intel_dp) && fixed_mode) {
if (mode->hdisplay > fixed_mode->hdisplay)
return MODE_PANEL;
@@ -4566,6 +4573,28 @@ static const struct drm_encoder_funcs intel_dp_enc_funcs
= {
.destroy = intel_dp_encoder_destroy,
};
+static void intel_dp_get_dfp(struct intel_dp *intel_dp)
+{
+ uint8_t dfp_info[4];
+
+ intel_dp->dfp.detailed_cap_info =
intel_dp->dpcd[DP_DOWNSTREAMPORT_PRESENT] & DP_DETAILED_CAP_INFO_AVAILABLE;
+
+ if (drm_dp_dpcd_read(&intel_dp->aux, DP_DOWNSTREAM_PORT_0, dfp_info, 4)
< 0) {
+ intel_dp->dfp.present = false;
+ intel_dp->dfp.detailed_cap_info = false;
+ return; /* aux transfer failed */
+ }
+
+ intel_dp->dfp.type = dfp_info[0] & DP_DS_PORT_TYPE_MASK;
+
+ if (intel_dp->dfp.detailed_cap_info) {
+ if (intel_dp->dfp.type & DP_DS_PORT_TYPE_VGA) {
+ intel_dp->dfp.dot_clk = dfp_info[1] * 8 * 1000;
+ DRM_DEBUG_KMS("max pixel rate for VGA is %d kHz\n",
intel_dp->dfp.dot_clk);
+ }
+ }
+}
+
enum irqreturn
intel_dp_hpd_pulse(struct intel_digital_port *intel_dig_port, bool long_hpd)
{
@@ -4599,6 +4628,11 @@ intel_dp_hpd_pulse(struct intel_digital_port
*intel_dig_port, bool long_hpd)
power_domain = intel_display_port_aux_power_domain(intel_encoder);
intel_display_power_get(dev_priv, power_domain);
+ intel_dp->dfp.present = intel_dp->dpcd[DP_DOWNSTREAMPORT_PRESENT] & 0x1;
+
+ if (intel_dp->dfp.present)
+ intel_dp_get_dfp(intel_dp);
+
if (long_hpd) {
/* indicate that we need to restart link training */
intel_dp->train_set_valid = false;
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index 21dee3f..9798a59 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -794,6 +794,13 @@ enum link_m_n_set {
M2_N2
};
+struct intel_dp_dfp {
+ bool present;
+ int type;
+ bool detailed_cap_info;
+ int dot_clk; /* pixel rate for VGA dongles */
+};
+
struct intel_dp {
i915_reg_t output_reg;
i915_reg_t aux_ch_ctl_reg;
@@ -861,6 +868,8 @@ struct intel_dp {
bool train_set_valid;
+ struct intel_dp_dfp dfp;
+
/* Displayport compliance testing */
unsigned long compliance_test_type;
unsigned long compliance_test_data;
--
1.9.1
[PATCH 0/3] drm/i915: DP branch devices
This series of patches reads either pixel rate or TMDS clock rate from DPCD. Pixel rate is defined for DP to VGA dongles and TMDS clock rate for others except wireless dongle. The mode that requires either higher pixel rate or TMDS clock rate are filtered out during the mode validity check. Mika Kahola (3): drm/i915: Check pixel rate for DP to VGA dongle drm: Add DP port types from DP 1.3 specification drm/i915: Check HDMI TMDS clock rate from DPCD drivers/gpu/drm/i915/intel_dp.c | 37 + drivers/gpu/drm/i915/intel_drv.h | 10 ++ drivers/gpu/drm/i915/intel_hdmi.c | 7 --- include/drm/drm_dp_helper.h | 2 ++ 4 files changed, 53 insertions(+), 3 deletions(-) -- 1.9.1
[Intel-gfx] [PATCH] drm/atomic: Add WARN_ON when state->acquire_ctx is not set.
On Tue, May 03, 2016 at 11:12:31AM +0200, Maarten Lankhorst wrote:
> When I was writing an atomic wrapper for rmfb, I ran into the
> following backtrace from lockdep:
>
> =
> [ INFO: possible recursive locking detected ]
> 4.5.0-patser+ #4696 Tainted: G U
> -
> kworker/2:2/2608 is trying to acquire lock:
> (crtc_ww_class_mutex){+.+.+.}, at: []
> drm_modeset_lock+0x7c/0x120 [drm]
>
> but task is already holding lock:
> (crtc_ww_class_mutex){+.+.+.}, at: []
> modeset_backoff+0x8d/0x220 [drm]
>
> other info that might help us debug this:
> Possible unsafe locking scenario:
>
>CPU0
>
> lock(crtc_ww_class_mutex);
> lock(crtc_ww_class_mutex);
>
> *** DEADLOCK ***
>
> May be due to missing lock nesting notation
>
> 4 locks held by kworker/2:2/2608:
> #0: ("events"){.+.+.+}, at: []
> process_one_work+0x15a/0x6c0
> #1: ((&arg.work)){+.+.+.}, at: []
> process_one_work+0x15a/0x6c0
> #2: (crtc_ww_class_acquire){+.+.+.}, at: []
> drm_atomic_helper_remove_fb+0x4a/0x1d0 [drm_kms_helper]
> #3: (crtc_ww_class_mutex){+.+.+.}, at: []
> modeset_backoff+0x8d/0x220 [drm]
>
> While lockdep probably catches this bug when it happens, it's better
> to explicitly warn when state->acquire_ctx is not set.
>
> Signed-off-by: Maarten Lankhorst
Yeah, because of the automagic fallback to normal mutex semantics when
acquire_ctx == NULL in ww_mutex_lock this can go boom, and the lockdep
splat is pretty hard to read. Makes sense to have an explicit WARN_ON
about it.
Applied to drm-misc, thanks.
-Daniel
> ---
> drivers/gpu/drm/drm_atomic.c | 6 ++
> 1 file changed, 6 insertions(+)
>
> diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
> index 0b526423f19f..69adcf3944cc 100644
> --- a/drivers/gpu/drm/drm_atomic.c
> +++ b/drivers/gpu/drm/drm_atomic.c
> @@ -263,6 +263,8 @@ drm_atomic_get_crtc_state(struct drm_atomic_state *state,
> int ret, index = drm_crtc_index(crtc);
> struct drm_crtc_state *crtc_state;
>
> + WARN_ON(!state->acquire_ctx);
> +
> crtc_state = drm_atomic_get_existing_crtc_state(state, crtc);
> if (crtc_state)
> return crtc_state;
> @@ -622,6 +624,8 @@ drm_atomic_get_plane_state(struct drm_atomic_state *state,
> int ret, index = drm_plane_index(plane);
> struct drm_plane_state *plane_state;
>
> + WARN_ON(!state->acquire_ctx);
> +
> plane_state = drm_atomic_get_existing_plane_state(state, plane);
> if (plane_state)
> return plane_state;
> @@ -890,6 +894,8 @@ drm_atomic_get_connector_state(struct drm_atomic_state
> *state,
> struct drm_mode_config *config = &connector->dev->mode_config;
> struct drm_connector_state *connector_state;
>
> + WARN_ON(!state->acquire_ctx);
> +
> ret = drm_modeset_lock(&config->connection_mutex, state->acquire_ctx);
> if (ret)
> return ERR_PTR(ret);
> --
> 2.5.5
>
> ___
> Intel-gfx mailing list
> Intel-gfx at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
[PATCH 6/6] drm/i915/mst: use reference counted connectors. (v3)
From: Dave Airlie
Don't just free the connector when we get the destroy callback.
Drop a reference to it, and set it's mst_port to NULL so
no more mst work is done on it.
v2: core mst accepts NULLs fine. Cleanup EDID code properly.
v3: drop the extra reference we were taking.
Reviewed-by: Daniel Vetter
Signed-off-by: Dave Airlie
---
drivers/gpu/drm/i915/intel_dp_mst.c | 43 +
drivers/gpu/drm/i915/intel_drv.h| 2 +-
2 files changed, 21 insertions(+), 24 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_dp_mst.c
b/drivers/gpu/drm/i915/intel_dp_mst.c
index 94b4e83..b6bf7fd 100644
--- a/drivers/gpu/drm/i915/intel_dp_mst.c
+++ b/drivers/gpu/drm/i915/intel_dp_mst.c
@@ -109,7 +109,7 @@ static void intel_mst_disable_dp(struct intel_encoder
*encoder)
DRM_DEBUG_KMS("%d\n", intel_dp->active_mst_links);
- drm_dp_mst_reset_vcpi_slots(&intel_dp->mst_mgr, intel_mst->port);
+ drm_dp_mst_reset_vcpi_slots(&intel_dp->mst_mgr,
intel_mst->connector->port);
ret = drm_dp_update_payload_part1(&intel_dp->mst_mgr);
if (ret) {
@@ -134,10 +134,11 @@ static void intel_mst_post_disable_dp(struct
intel_encoder *encoder)
/* and this can also fail */
drm_dp_update_payload_part2(&intel_dp->mst_mgr);
- drm_dp_mst_deallocate_vcpi(&intel_dp->mst_mgr, intel_mst->port);
+ drm_dp_mst_deallocate_vcpi(&intel_dp->mst_mgr,
intel_mst->connector->port);
intel_dp->active_mst_links--;
- intel_mst->port = NULL;
+
+ intel_mst->connector = NULL;
if (intel_dp->active_mst_links == 0) {
intel_dig_port->base.post_disable(&intel_dig_port->base);
intel_dp_sink_dpms(intel_dp, DRM_MODE_DPMS_OFF);
@@ -177,7 +178,8 @@ static void intel_mst_pre_enable_dp(struct intel_encoder
*encoder)
found->encoder = encoder;
DRM_DEBUG_KMS("%d\n", intel_dp->active_mst_links);
- intel_mst->port = found->port;
+
+ intel_mst->connector = found;
if (intel_dp->active_mst_links == 0) {
intel_prepare_ddi_buffer(&intel_dig_port->base);
@@ -195,7 +197,7 @@ static void intel_mst_pre_enable_dp(struct intel_encoder
*encoder)
}
ret = drm_dp_mst_allocate_vcpi(&intel_dp->mst_mgr,
- intel_mst->port,
+ intel_mst->connector->port,
intel_crtc->config->pbn, &slots);
if (ret == false) {
DRM_ERROR("failed to allocate vcpi\n");
@@ -244,7 +246,7 @@ static bool intel_dp_mst_enc_get_hw_state(struct
intel_encoder *encoder,
{
struct intel_dp_mst_encoder *intel_mst = enc_to_mst(&encoder->base);
*pipe = intel_mst->pipe;
- if (intel_mst->port)
+ if (intel_mst->connector)
return true;
return false;
}
@@ -308,10 +310,11 @@ static int intel_dp_mst_get_ddc_modes(struct
drm_connector *connector)
struct edid *edid;
int ret;
- edid = drm_dp_mst_get_edid(connector, &intel_dp->mst_mgr,
intel_connector->port);
- if (!edid)
- return 0;
+ if (!intel_dp) {
+ return intel_connector_update_modes(connector, NULL);
+ }
+ edid = drm_dp_mst_get_edid(connector, &intel_dp->mst_mgr,
intel_connector->port);
ret = intel_connector_update_modes(connector, edid);
kfree(edid);
@@ -324,6 +327,8 @@ intel_dp_mst_detect(struct drm_connector *connector, bool
force)
struct intel_connector *intel_connector = to_intel_connector(connector);
struct intel_dp *intel_dp = intel_connector->mst_port;
+ if (!intel_dp)
+ return connector_status_disconnected;
return drm_dp_mst_detect_port(connector, &intel_dp->mst_mgr,
intel_connector->port);
}
@@ -389,6 +394,8 @@ static struct drm_encoder
*intel_mst_atomic_best_encoder(struct drm_connector *c
struct intel_dp *intel_dp = intel_connector->mst_port;
struct intel_crtc *crtc = to_intel_crtc(state->crtc);
+ if (!intel_dp)
+ return NULL;
return &intel_dp->mst_encoders[crtc->pipe]->base.base;
}
@@ -396,6 +403,8 @@ static struct drm_encoder *intel_mst_best_encoder(struct
drm_connector *connecto
{
struct intel_connector *intel_connector = to_intel_connector(connector);
struct intel_dp *intel_dp = intel_connector->mst_port;
+ if (!intel_dp)
+ return NULL;
return &intel_dp->mst_encoders[0]->base.base;
}
@@ -506,23 +515,11 @@ static void intel_dp_destroy_mst_connector(struct
drm_dp_mst_topology_mgr *mgr,
/* need to nuke the connector */
drm_modeset_lock_all(dev);
- if (connector->state->crtc) {
- struct drm_mode_set set;
- int ret;
-
- memset(&set, 0, sizeof(set));
- set.crtc = connector->state->crtc,
-
- ret = drm_atomic_helper_set_config(&set);
-
[PATCH 5/6] drm/atomic: use connector references (v2)
From: Dave Airlie
Take a reference when setting a crtc on a connecter,
also take one when duplicating if a crtc is set,
and drop one on destroy if a crtc is set.
v2: take Daniel Stone's advice and simplify the
ref/unref dances, also take care of NULL as connector
to state reset.
Signed-off-by: Dave Airlie
---
drivers/gpu/drm/drm_atomic.c| 4
drivers/gpu/drm/drm_atomic_helper.c | 5 +
2 files changed, 9 insertions(+)
diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
index 9d5e3c8..91cae88 100644
--- a/drivers/gpu/drm/drm_atomic.c
+++ b/drivers/gpu/drm/drm_atomic.c
@@ -1160,6 +1160,8 @@ drm_atomic_set_crtc_for_connector(struct
drm_connector_state *conn_state,
{
struct drm_crtc_state *crtc_state;
+ if (crtc)
+ drm_connector_reference(conn_state->connector);
if (conn_state->crtc && conn_state->crtc != crtc) {
crtc_state =
drm_atomic_get_existing_crtc_state(conn_state->state,
conn_state->crtc);
@@ -1177,6 +1179,8 @@ drm_atomic_set_crtc_for_connector(struct
drm_connector_state *conn_state,
1 << drm_connector_index(conn_state->connector);
}
+ if (conn_state->crtc)
+ drm_connector_unreference(conn_state->connector);
conn_state->crtc = crtc;
if (crtc)
diff --git a/drivers/gpu/drm/drm_atomic_helper.c
b/drivers/gpu/drm/drm_atomic_helper.c
index d25abce..f3e2642 100644
--- a/drivers/gpu/drm/drm_atomic_helper.c
+++ b/drivers/gpu/drm/drm_atomic_helper.c
@@ -2762,6 +2762,8 @@ __drm_atomic_helper_connector_duplicate_state(struct
drm_connector *connector,
struct drm_connector_state *state)
{
memcpy(state, connector->state, sizeof(*state));
+ if (state->crtc)
+ drm_connector_reference(connector);
}
EXPORT_SYMBOL(__drm_atomic_helper_connector_duplicate_state);
@@ -2889,6 +2891,9 @@ __drm_atomic_helper_connector_destroy_state(struct
drm_connector *connector,
* state will automatically do the right thing if code is ever added
* to this function.
*/
+ if (connector && state->crtc) {
+ drm_connector_unreference(state->connector);
+ }
}
EXPORT_SYMBOL(__drm_atomic_helper_connector_destroy_state);
--
2.5.5
[PATCH 4/6] drm/crtc: take references to connectors used in a modeset. (v2)
From: Dave Airlie
This just takes a reference on the connector when we set a mode
in the non-atomic paths.
v2: Follow Daniel Stone's suggestions on when to take/drop
references.
Signed-off-by: Dave Airlie
---
drivers/gpu/drm/drm_crtc_helper.c | 19 +++
1 file changed, 19 insertions(+)
diff --git a/drivers/gpu/drm/drm_crtc_helper.c
b/drivers/gpu/drm/drm_crtc_helper.c
index 66ca313..f47a252 100644
--- a/drivers/gpu/drm/drm_crtc_helper.c
+++ b/drivers/gpu/drm/drm_crtc_helper.c
@@ -456,6 +456,9 @@ drm_crtc_helper_disable(struct drm_crtc *crtc)
* between them is henceforth no longer available.
*/
connector->dpms = DRM_MODE_DPMS_OFF;
+
+ /* we keep a reference while the encoder is bound */
+ drm_connector_unreference(connector);
}
}
@@ -606,6 +609,11 @@ int drm_crtc_helper_set_config(struct drm_mode_set *set)
mode_changed = true;
}
+ /* take a reference on all connectors in set */
+ for (ro = 0; ro < set->num_connectors; ro++) {
+ drm_connector_reference(set->connectors[ro]);
+ }
+
/* a) traverse passed in connector list and get encoders for them */
count = 0;
drm_for_each_connector(connector, dev) {
@@ -724,6 +732,12 @@ int drm_crtc_helper_set_config(struct drm_mode_set *set)
}
}
+ /* after fail drop reference on all connectors in save set */
+ count = 0;
+ drm_for_each_connector(connector, dev) {
+ drm_connector_unreference(&save_connectors[count++]);
+ }
+
kfree(save_connectors);
kfree(save_encoders);
return 0;
@@ -740,6 +754,11 @@ fail:
*connector = save_connectors[count++];
}
+ /* after fail drop reference on all connectors in set */
+ for (ro = 0; ro < set->num_connectors; ro++) {
+ drm_connector_unreference(set->connectors[ro]);
+ }
+
/* Try to restore the config */
if (mode_changed &&
!drm_crtc_helper_set_mode(save_set.crtc, save_set.mode, save_set.x,
--
2.5.5
[PATCH 3/6] drm/fb_helper: add connector reference counting. (v2)
From: Dave Airlie
This takes a reference count when fbdev adds the connector,
and drops it when it removes the connector.
It also drops the now unneeded code to find connectors
and remove the from the modeset as they are reference counted.
v2: drop references when removing all connectors at end.
Signed-off-by: Dave Airlie
---
drivers/gpu/drm/drm_fb_helper.c | 38 +-
1 file changed, 5 insertions(+), 33 deletions(-)
diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c
index 855108e..19a7a71 100644
--- a/drivers/gpu/drm/drm_fb_helper.c
+++ b/drivers/gpu/drm/drm_fb_helper.c
@@ -153,40 +153,13 @@ int drm_fb_helper_add_one_connector(struct drm_fb_helper
*fb_helper, struct drm_
if (!fb_helper_connector)
return -ENOMEM;
+ drm_connector_reference(connector);
fb_helper_connector->connector = connector;
fb_helper->connector_info[fb_helper->connector_count++] =
fb_helper_connector;
return 0;
}
EXPORT_SYMBOL(drm_fb_helper_add_one_connector);
-static void remove_from_modeset(struct drm_mode_set *set,
- struct drm_connector *connector)
-{
- int i, j;
-
- for (i = 0; i < set->num_connectors; i++) {
- if (set->connectors[i] == connector)
- break;
- }
-
- if (i == set->num_connectors)
- return;
-
- for (j = i + 1; j < set->num_connectors; j++) {
- set->connectors[j - 1] = set->connectors[j];
- }
- set->num_connectors--;
-
- /*
-* TODO maybe need to makes sure we set it back to !=NULL somewhere?
-*/
- if (set->num_connectors == 0) {
- set->fb = NULL;
- drm_mode_destroy(connector->dev, set->mode);
- set->mode = NULL;
- }
-}
-
int drm_fb_helper_remove_one_connector(struct drm_fb_helper *fb_helper,
struct drm_connector *connector)
{
@@ -206,6 +179,7 @@ int drm_fb_helper_remove_one_connector(struct drm_fb_helper
*fb_helper,
if (i == fb_helper->connector_count)
return -EINVAL;
fb_helper_connector = fb_helper->connector_info[i];
+ drm_connector_unreference(fb_helper_connector->connector);
for (j = i + 1; j < fb_helper->connector_count; j++) {
fb_helper->connector_info[j - 1] = fb_helper->connector_info[j];
@@ -213,10 +187,6 @@ int drm_fb_helper_remove_one_connector(struct
drm_fb_helper *fb_helper,
fb_helper->connector_count--;
kfree(fb_helper_connector);
- /* also cleanup dangling references to the connector: */
- for (i = 0; i < fb_helper->crtc_count; i++)
- remove_from_modeset(&fb_helper->crtc_info[i].mode_set,
connector);
-
return 0;
}
EXPORT_SYMBOL(drm_fb_helper_remove_one_connector);
@@ -626,8 +596,10 @@ static void drm_fb_helper_crtc_free(struct drm_fb_helper
*helper)
{
int i;
- for (i = 0; i < helper->connector_count; i++)
+ for (i = 0; i < helper->connector_count; i++) {
+ drm_connector_unreference(helper->connector_info[i]->connector);
kfree(helper->connector_info[i]);
+ }
kfree(helper->connector_info);
for (i = 0; i < helper->crtc_count; i++) {
kfree(helper->crtc_info[i].mode_set.connectors);
--
2.5.5
[PATCH 2/6] drm/modes: add connector reference counting. (v2)
From: Dave Airlie
This uses the previous changes to add reference counts
to drm connector objects.
v2: move fbdev changes to their own patch.
add some kerneldoc
Reviewed-by: Daniel Vetter
Signed-off-by: Dave Airlie
---
drivers/gpu/drm/drm_atomic.c | 19 +--
drivers/gpu/drm/drm_crtc.c | 28
include/drm/drm_crtc.h | 32 +++-
3 files changed, 72 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
index 8ee1db8..9d5e3c8 100644
--- a/drivers/gpu/drm/drm_atomic.c
+++ b/drivers/gpu/drm/drm_atomic.c
@@ -154,6 +154,7 @@ void drm_atomic_state_default_clear(struct drm_atomic_state
*state)
state->connector_states[i]);
state->connectors[i] = NULL;
state->connector_states[i] = NULL;
+ drm_connector_unreference(connector);
}
for (i = 0; i < config->num_crtc; i++) {
@@ -924,6 +925,7 @@ drm_atomic_get_connector_state(struct drm_atomic_state
*state,
if (!connector_state)
return ERR_PTR(-ENOMEM);
+ drm_connector_reference(connector);
state->connector_states[index] = connector_state;
state->connectors[index] = connector;
connector_state->state = state;
@@ -1614,12 +1616,19 @@ retry:
}
obj = drm_mode_object_find(dev, obj_id, DRM_MODE_OBJECT_ANY);
- if (!obj || !obj->properties) {
+ if (!obj) {
+ ret = -ENOENT;
+ goto out;
+ }
+
+ if (!obj->properties) {
+ drm_mode_object_unreference(obj);
ret = -ENOENT;
goto out;
}
if (get_user(count_props, count_props_ptr + copied_objs)) {
+ drm_mode_object_unreference(obj);
ret = -EFAULT;
goto out;
}
@@ -1632,12 +1641,14 @@ retry:
struct drm_property *prop;
if (get_user(prop_id, props_ptr + copied_props)) {
+ drm_mode_object_unreference(obj);
ret = -EFAULT;
goto out;
}
prop = drm_property_find(dev, prop_id);
if (!prop) {
+ drm_mode_object_unreference(obj);
ret = -ENOENT;
goto out;
}
@@ -1645,13 +1656,16 @@ retry:
if (copy_from_user(&prop_value,
prop_values_ptr + copied_props,
sizeof(prop_value))) {
+ drm_mode_object_unreference(obj);
ret = -EFAULT;
goto out;
}
ret = atomic_set_prop(state, obj, prop, prop_value);
- if (ret)
+ if (ret) {
+ drm_mode_object_unreference(obj);
goto out;
+ }
copied_props++;
}
@@ -1662,6 +1676,7 @@ retry:
plane_mask |= (1 << drm_plane_index(plane));
plane->old_fb = plane->fb;
}
+ drm_mode_object_unreference(obj);
}
if (arg->flags & DRM_MODE_PAGE_FLIP_EVENT) {
diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
index 4e5b015..a78e202 100644
--- a/drivers/gpu/drm/drm_crtc.c
+++ b/drivers/gpu/drm/drm_crtc.c
@@ -862,6 +862,16 @@ static void drm_connector_get_cmdline_mode(struct
drm_connector *connector)
mode->interlace ? " interlaced" : "");
}
+static void drm_connector_free(struct kref *kref)
+{
+ struct drm_connector *connector =
+ container_of(kref, struct drm_connector, base.refcount);
+ struct drm_device *dev = connector->dev;
+
+ drm_mode_object_unregister(dev, &connector->base);
+ connector->funcs->destroy(connector);
+}
+
/**
* drm_connector_init - Init a preallocated connector
* @dev: DRM device
@@ -887,7 +897,9 @@ int drm_connector_init(struct drm_device *dev,
drm_modeset_lock_all(dev);
- ret = drm_mode_object_get_reg(dev, &connector->base,
DRM_MODE_OBJECT_CONNECTOR, false, NULL);
+ ret = drm_mode_object_get_reg(dev, &connector->base,
+ DRM_MODE_OBJECT_CONNECTOR,
+ false, drm_connector_free);
if (ret)
goto out_unlock;
@@ -2147,7 +2159,7 @@ int drm_mode_getconnector(struct drm_device *dev, void
*da
[PATCH 1/6] drm/fb: fix missing /** in kerneldoc comment.
From: Dave Airlie Signed-off-by: Dave Airlie --- include/drm/drm_crtc.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h index 297e527..6279989 100644 --- a/include/drm/drm_crtc.h +++ b/include/drm/drm_crtc.h @@ -2606,7 +2606,7 @@ static inline uint32_t drm_color_lut_extract(uint32_t user_input, return clamp_val(val, 0, max); } -/* +/** * drm_framebuffer_reference - incr the fb refcnt * @fb: framebuffer * -- 2.5.5
[PATCH 5/6] drm/atomic: use connector references (v2)
On Tue, May 3, 2016 at 12:09 PM, Dave Airlie wrote:
>>>*/
>>> + if (connector && state->crtc) {
>>> + drm_connector_unreference(state->connector);
>>> + }
>>
>> Bikeshed: no need for {} and you don't need to check that connector is
>> NULL either. Tbh all the destroy_state helpers don't really need their
>> object argument, only the state. Cleaning that up is somewhere on my todo.
>
> Yes you really do need the connector, lost a boot to an oops,
>
> drm_atomic_state_default_clear does some funky stuff that can possibly go away
> after this, but I'm not sure.
Surprising, didn't expect that. Do you still have the backtrace
somewhere? I really wonder what goes boom with that one ...
What we might need is check for state->connector (instead of
connector), but that being NULL for a valid state is also a bit a bug.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
[PATCH 02/23] drm: omapdrm: fb: Don't store format BPP for each plane
On Tue, May 03, 2016 at 09:08:06AM +0300, Tomi Valkeinen wrote:
>
> On 03/05/16 00:01, Rob Clark wrote:
> > On Mon, May 2, 2016 at 11:43 AM, Tomi Valkeinen
> > wrote:
> >> Hi Laurent,
> >>
> >> On 26/04/16 23:35, Laurent Pinchart wrote:
> >>> The number of bits per pixel is identical for all planes, don't store
> >>> multiple copies.
> >>
> >> That's not true, as with NV12, Y has 8 bits per pixel and UV has 16 bits
> >> per pixel. But as the subsampling is precalculated into the stride_bpp
> >> (is it bytes or bits? bpp always confuses me =), the 'stride_bpp' ends
> >> up being same for both planes.
> >>
> >> To be honest, I'd rather go into more complex struct than simpler one.
> >> The current one is already confusing, I think, and your version is too.
> >> The main issue is that the sub_x is encoded into the stride_bpp. In
> >> kmsxx I used this format:
> >>
> >> { PixelFormat::NV12, { 2, { { 8, 1, 1, }, { 8, 2, 2 } }, } },
> >>
> >> The first number is the number of planes, and for each plane, bitspp,
> >> xsub and ysub. It's more verbose, but (I think) easier to understand.
> >
> > fwiw, I guess a lot of data from that table could these days be
> > replaced w/ some of the drm format helpers
> > (drm_format_num_planes()/drm_format_plane_cpp()/drm_format_{horz,vert}_chroma_subsampling()/etc)
>
> Indeed, I think we can remove all but the DRM -> DSS format mapping.
>
> Btw, what is "cpp" short from?
Bytes per pixel. The 'c' is silent :P
PS.
Actually it's "chars per pixel"
--
Ville Syrjälä
Intel OTC
[GIT PULL] drm/rockchip: some fixes
Hi Dave Here are some little fixes for rockchip drm, looks good for me, and seems there is no doubt on them, So I'd like you can land them. The following changes since commit b89359bdf0f1e95a4c5f92300594ba9dde323fc4: Merge branch 'for-next' of http://git.agner.ch/git/linux-drm-fsl-dcu into drm-next (2016-04-29 14:57:51 +1000) are available in the git repository at: https://github.com/markyzq/kernel-drm-rockchip.git drm-rockchip-next-fixes-05-03 for you to fetch changes up to 2db00cf5a07b7c543392ff88163428509cda38ae: drm/rockchip: vop: Initialize vskiplines to zero (2016-05-03 14:11:23 +0800) Dan Carpenter (1): drm/rockchip: inno_hdmi: fix an error code John Keeping (2): drm/rockchip: remove redundant statement drm/rockchip: don't leak iommu mapping Mark Yao (4): drm/rockchip: get rid of rockchip_drm_crtc_mode_config drm/rockchip: support non-iommu buffer path drm/rockchip: vop: fix iommu crash with async atomic drm/rockchip: vop: Initialize vskiplines to zero drivers/gpu/drm/rockchip/analogix_dp-rockchip.c | 48 +++- drivers/gpu/drm/rockchip/dw-mipi-dsi.c | 38 -- drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c | 17 ++--- drivers/gpu/drm/rockchip/inno_hdmi.c| 20 drivers/gpu/drm/rockchip/rockchip_drm_drv.c | 66 +++--- drivers/gpu/drm/rockchip/rockchip_drm_drv.h | 10 -- drivers/gpu/drm/rockchip/rockchip_drm_vop.c | 95 --- 7 files changed, 196 insertions(+), 98 deletions(-) -- ï¼ark Yao
[PATCH] drm/core: Do not preserve framebuffer on rmfb, v3.
Hi,
Sorry for the late response, been very busy with other stuff lately.
I've tested this version against drm-fixes and it indeed fixes the
problem, as far as I can tell.
Tested-by: Thomas Hellstrom
On 03/31/2016 01:26 PM, Maarten Lankhorst wrote:
> It turns out that preserving framebuffers after the rmfb call breaks
> vmwgfx userspace. This was originally introduced because it was thought
> nobody relied on the behavior, but unfortunately it seems there are
> exceptions.
>
> drm_framebuffer_remove may fail with -EINTR now, so a straight revert
> is impossible. There is no way to remove the framebuffer from the lists
> and active planes without introducing a race because of the different
> locking requirements. Instead call drm_framebuffer_remove from a
> workqueue, which is unaffected by signals.
>
> Changes since v1:
> - Add comment.
> Changes since v2:
> - Add fastpath for refcount = 1. (danvet)
>
> Cc: stable at vger.kernel.org #v4.4+
> Fixes: 13803132818c ("drm/core: Preserve the framebuffer after removing it.")
> Testcase: kms_flip.flip-vs-rmfb-interruptible
> References:
> https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.freedesktop.org_archives_dri-2Ddevel_2016-2DMarch_102876.html&d=BQIBAg&c=Sqcl0Ez6M0X8aeM67LKIiDJAXVeAw-YihVMNtXt-uEs&r=vpukPkBtpoNQp2IUKuFviOmPNYWVKmen3Jeeu55zmEA&m=_2qOX1NGnSnJOTgqvu1Ud574i5T3fLDlX91oUS3WXXI&s=9D34PFYdb1PT2vzX_M_7lNVoSebfM9-KsAqe5AXAQbQ&e=
>
> Cc: Thomas Hellstrom
> Cc: David Herrmann
> ---
> drivers/gpu/drm/drm_crtc.c | 29 -
> 1 file changed, 28 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
> index 55ffde5a3a4a..743bece1f579 100644
> --- a/drivers/gpu/drm/drm_crtc.c
> +++ b/drivers/gpu/drm/drm_crtc.c
> @@ -3434,6 +3434,18 @@ int drm_mode_addfb2(struct drm_device *dev,
> return 0;
> }
>
> +struct drm_mode_rmfb_work {
> + struct work_struct work;
> + struct drm_framebuffer *fb;
> +};
> +
> +static void drm_mode_rmfb_work_fn(struct work_struct *w)
> +{
> + struct drm_mode_rmfb_work *arg = container_of(w, typeof(*arg), work);
> +
> + drm_framebuffer_remove(arg->fb);
> +}
> +
> /**
> * drm_mode_rmfb - remove an FB from the configuration
> * @dev: drm device for the ioctl
> @@ -3474,7 +3486,22 @@ int drm_mode_rmfb(struct drm_device *dev,
> mutex_unlock(&dev->mode_config.fb_lock);
> mutex_unlock(&file_priv->fbs_lock);
>
> - drm_framebuffer_unreference(fb);
> + /*
> + * drm_framebuffer_remove may fail with -EINTR on pending signals,
> + * so run this in a separate stack as there's no way to correctly
> + * handle this after the fb is already removed from the lookup table.
> + */
> + if (atomic_read(&fb->refcount.refcount) > 1) {
> + struct drm_mode_rmfb_work arg;
> +
> + INIT_WORK_ONSTACK(&arg.work, drm_mode_rmfb_work_fn);
> + arg.fb = fb;
> +
> + schedule_work(&arg.work);
> + flush_work(&arg.work);
> + destroy_work_on_stack(&arg.work);
> + } else
> + drm_framebuffer_unreference(fb);
>
> return 0;
>
[PATCH v2] drm/vc4: Return -EBUSY if there's already a pending flip event.
From: Robert Foss
As per the documentation in drm_crtc.h, atomic_commit should return
-EBUSY if an asycnhronous update is requested and there is an earlier
update pending.
Note: docs cited here are drm_crtc.h, and the whole quote is:
* - -EBUSY, if an asynchronous updated is requested and there is
*an earlier updated pending. Drivers are allowed to support a queue
*of outstanding updates, but currently no driver supports that.
*Note that drivers must wait for preceding updates to complete if a
*synchronous update is requested, they are not allowed to fail the
*commit in that case.
Signed-off-by: Robert Foss
---
Changes since v1:
- Corrected and simplified patch to piggyback on a previously existing check.
drivers/gpu/drm/vc4/vc4_kms.c | 16
1 file changed, 12 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/vc4/vc4_kms.c b/drivers/gpu/drm/vc4/vc4_kms.c
index 4718ae5..7c7188d 100644
--- a/drivers/gpu/drm/vc4/vc4_kms.c
+++ b/drivers/gpu/drm/vc4/vc4_kms.c
@@ -117,10 +117,18 @@ static int vc4_atomic_commit(struct drm_device *dev,
return -ENOMEM;
/* Make sure that any outstanding modesets have finished. */
- ret = down_interruptible(&vc4->async_modeset);
- if (ret) {
- kfree(c);
- return ret;
+ if (async) {
+ ret = down_trylock(&vc4->async_modeset);
+ if (ret) {
+ kfree(c);
+ return -EBUSY;
+ }
+ } else {
+ ret = down_interruptible(&vc4->async_modeset);
+ if (ret) {
+ kfree(c);
+ return ret;
+ }
}
ret = drm_atomic_helper_prepare_planes(dev, state);
--
2.5.0
linux-next: manual merge of the drm-msm tree with the drm-misc tree
Hi Rob,
Today's linux-next merge of the drm-msm tree got a conflict in:
drivers/gpu/drm/msm/msm_atomic.c
between commit:
a3ccfb9feb46 ("drm/msm: Rename async to nonblock.")
from the drm-misc tree and commit:
afadc4bb9380 ("drm/msm: remove fence_cbs")
from the drm-msm tree.
I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging. You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.
--
Cheers,
Stephen Rothwell
diff --cc drivers/gpu/drm/msm/msm_atomic.c
index 5c6130969f4d,2b4142a05024..
--- a/drivers/gpu/drm/msm/msm_atomic.c
+++ b/drivers/gpu/drm/msm/msm_atomic.c
@@@ -199,11 -190,11 +189,11 @@@ int msm_atomic_check(struct drm_device
* Zero for success or -errno.
*/
int msm_atomic_commit(struct drm_device *dev,
- struct drm_atomic_state *state, bool async)
+ struct drm_atomic_state *state, bool nonblock)
{
+ struct msm_drm_private *priv = dev->dev_private;
int nplanes = dev->mode_config.num_total_plane;
int ncrtcs = dev->mode_config.num_crtc;
- ktime_t timeout;
struct msm_commit *c;
int i, ret;
@@@ -275,8 -270,8 +269,8 @@@
* current layout.
*/
- if (async) {
+ if (nonblock) {
- msm_queue_fence_cb(dev, &c->fence_cb, c->fence);
+ queue_work(priv->atomic_wq, &c->work);
return 0;
}
linux-next: manual merge of the drm-misc tree with the drm-intel tree
Hi all,
Today's linux-next merge of the drm-misc tree got a conflict in:
drivers/gpu/drm/i915/intel_display.c
between commits:
f7e5838bb37d ("drm/i915: Simplify reset_counter handling during atomic
modesetting")
from the drm-intel tree and commit:
81072bfd13f2 ("drm/i915: Rename async to nonblock.")
from the drm-misc tree.
I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging. You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.
--
Cheers,
Stephen Rothwell
diff --cc drivers/gpu/drm/i915/intel_display.c
index ff60241b1f76,5d29b838d8d7..
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@@ -13462,9 -13414,12 +13462,9 @@@ static int intel_atomic_prepare_commit(
return ret;
ret = drm_atomic_helper_prepare_planes(dev, state);
- if (!ret && !nonblock && !i915_reset_in_progress(&dev_priv->gpu_error))
{
- u32 reset_counter;
-
- reset_counter = atomic_read(&dev_priv->gpu_error.reset_counter);
- mutex_unlock(&dev->struct_mutex);
+ mutex_unlock(&dev->struct_mutex);
- if (!ret && !async) {
++ if (!ret && !nonblock) {
for_each_plane_in_state(state, plane, plane_state, i) {
struct intel_plane_state *intel_plane_state =
to_intel_plane_state(plane_state);
[PATCH] drm/amdgpu: set metadata pointer to NULL after freeing.
From: Dave Airlie
Without this there was a double free of the metadata,
which ended up freeing the fd table for me here, and taking
out the machine more often than not.
I reproduced with X.org + modesetting DDX + latest llvm/mesa,
also required using dri3.
Cc: stable at vger.kernel.org
Signed-off-by: Dave Airlie
---
drivers/gpu/drm/amd/amdgpu/amdgpu_object.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
index e557fc1..7ecea83 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
@@ -541,6 +541,7 @@ int amdgpu_bo_set_metadata (struct amdgpu_bo *bo, void
*metadata,
if (!metadata_size) {
if (bo->metadata_size) {
kfree(bo->metadata);
+ bo->metadata = NULL;
bo->metadata_size = 0;
}
return 0;
--
2.5.5
[PATCH v3 4/7] drm/i2c: adv7511: Create a MIPI DSI device
Hi Laurent,
On 04/22/2016 10:40 AM, Archit Taneja wrote:
> Hi Laurent,
>
>
> On 04/22/2016 03:59 AM, Laurent Pinchart wrote:
>> Hi Archit,
>>
>> Thank you for the patch.
>>
>> On Wednesday 09 Mar 2016 16:27:15 Archit Taneja wrote:
>>> In order to pass DSI specific parameters to the DSI host, we need the
>>> driver to create a mipi_dsi_device DSI device that attaches to the
>>> host.
>>>
>>> Use of_graph helpers to get the DSI host DT node. Create a MIPI DSI
>>> device using this host. Finally, attach this device to the DSI host.
>>>
>>> Populate DT parameters (number of data lanes for now) that are required
>>> for DSI RX to work correctly. Hardcode few other parameters (rgb,
>>> embedded_sync) for now.
>>>
>>> Signed-off-by: Archit Taneja
>>
>> This adds a hard dependency on CONFIG_DRM_MIPI_DSI, otherwise the
>> kernel won't
>> link. As the ADV7511 doesn't require DSI, could you make it optional with
>> conditional compilation to avoid pulling in dead code ?
>
> You're right. The driver's Kconfig should at least select DRM_MIPI_DSI
> in the current state to make sure we don't break build.
>
> Do you suggest we create another config option for ADV7533, which
> selects DRM_MIPI_DSI and builds the ADV7533 parts? Or did you mean
> something else?
Do you have any suggestions for this point? For the next revision, I've
just selected DRM_MIPI_DSI in the Kconfig to ensure build doesn't break.
For this driver, to conditionally compile DRM_MIPI_DSI, it essentially
means we allow conditional support for ADV7533. I would imagine us
#ifdef-ing out the ADV7533 compatible string in the of_match_table. Is
this something we want to do?
Thanks,
Archit
>
>>
>>> ---
>>> drivers/gpu/drm/i2c/adv7511.c | 130
>>> ---
>>> 1 file changed, 123 insertions(+), 7 deletions(-)
>>>
>>> diff --git a/drivers/gpu/drm/i2c/adv7511.c
>>> b/drivers/gpu/drm/i2c/adv7511.c
>>> index 75be17c..6c2a89a 100644
>>> --- a/drivers/gpu/drm/i2c/adv7511.c
>>> +++ b/drivers/gpu/drm/i2c/adv7511.c
>>> @@ -11,6 +11,7 @@
>>> #include
>>> #include
>>> #include
>>> +#include
>>> #include
>>> #include
>>>
>>> @@ -19,6 +20,7 @@
>>> #include
>>> #include
>>> #include
>>> +#include
>>>
>>> #include "adv7511.h"
>>>
>>> @@ -56,6 +58,11 @@ struct adv7511 {
>>>
>>> struct gpio_desc *gpio_pd;
>>>
>>> +/* ADV7533 DSI RX related params */
>>> +struct device_node *host_node;
>>> +struct mipi_dsi_device *dsi;
>>> +u8 num_dsi_lanes;
>>> +
>>> enum adv7511_type type;
>>> };
>>>
>>> @@ -392,8 +399,10 @@ static void adv7511_set_link_config(struct adv7511
>>> *adv7511,
>>>
>>> static void adv7533_dsi_power_on(struct adv7511 *adv)
>>> {
>>> -/* set number of dsi lanes (hardcoded to 4 for now) */
>>> -regmap_write(adv->regmap_cec, 0x1c, 0x4 << 4);
>>> +struct mipi_dsi_device *dsi = adv->dsi;
>>> +
>>> +/* set number of dsi lanes */
>>> +regmap_write(adv->regmap_cec, 0x1c, dsi->lanes << 4);
>>> /* disable internal timing generator */
>>> regmap_write(adv->regmap_cec, 0x27, 0x0b);
>>> /* enable hdmi */
>>> @@ -889,6 +898,51 @@ static void adv7511_bridge_mode_set(struct
>>> drm_bridge
>>> *bridge, adv7511_mode_set(adv, mode, adj_mode);
>>> }
>>>
>>> +static int adv7533_attach_dsi(struct adv7511 *adv)
>>> +{
>>> +struct device *dev = &adv->i2c_main->dev;
>>> +struct mipi_dsi_host *host;
>>> +struct mipi_dsi_device *dsi;
>>> +int ret = 0;
>>> +const struct mipi_dsi_device_info info = { .type = "adv7533",
>>> + .channel = 0,
>>> + .node = NULL,
>>> + };
>>> +
>>> +host = of_find_mipi_dsi_host_by_node(adv->host_node);
>>> +if (!host) {
>>> +dev_err(dev, "failed to find dsi host\n");
>>> +return -EPROBE_DEFER;
>>> +}
>>> +
>>> +dsi = mipi_dsi_device_register_full(host, &info);
>>> +if (IS_ERR(dsi)) {
>>> +dev_err(dev, "failed to create dsi device\n");
>>> +ret = PTR_ERR(dsi);
>>> +goto err_dsi_device;
>>> +}
>>> +
>>> +adv->dsi = dsi;
>>> +
>>> +dsi->lanes = adv->num_dsi_lanes;
>>> +dsi->format = MIPI_DSI_FMT_RGB888;
>>> +dsi->mode_flags = MIPI_DSI_MODE_VIDEO |
>>> MIPI_DSI_MODE_VIDEO_SYNC_PULSE |
>>> + MIPI_DSI_MODE_EOT_PACKET | MIPI_DSI_MODE_VIDEO_HSE;
>>> +
>>> +ret = mipi_dsi_attach(dsi);
>>> +if (ret < 0) {
>>> +dev_err(dev, "failed to attach dsi to host\n");
>>> +goto err_dsi_attach;
>>> +}
>>> +
>>> +return 0;
>>> +
>>> +err_dsi_attach:
>>> +mipi_dsi_device_unregister(dsi);
>>> +err_dsi_device:
>>> +return ret;
>>> +}
>>> +
>>> static int adv7511_bridge_attach(struct drm_bridge *bridge)
>>> {
>>> struct adv7511 *adv = bridge_to_adv7511(bridge);
>>> @@ -912,6 +966,9 @@ static int adv7511_bridge_attach(struct drm_bridge
>>> *bridge) &adv7511_connector_helper_funcs);
>>> drm_mode_connector_attach_enco
[PATCH v3 0/7] drm/i2c: adv7511: ADV7533 support
On 05/03/2016 07:22 AM, Xinliang Liu wrote: > On 9 March 2016 at 18:57, Archit Taneja wrote: >> ADV7533 is a DSI to HDMI encoder chip. It's like ADV7511, but with an >> additional DSI RX block that takes in DSI video mode output. >> >> Trying to get this driver merged has had some challenges: >> >> - ADV7533 has an I2C control bus, but acts as a DSI peripheral too. >>After discussions, it was concluded that we'd want to provide an >>API to create MIPI DSI devices, rather than expose two different >>interfaces on DT. The first version [1] tried the former approach >>the second version [2] showed how the driver would look like if >>exposed 2 DT nodes. This lateset patchset relies on the MIPI DSI >>device creation API provided by [3], this has been accepted and >>should be merged for 4.6. >> >> - The driver was designed as an I2C slave encoder. When ADV7533 >>patches were posted [1], it was modelled as a bridge, but ADV7511 >>and others were still left as I2C slave encoders. This wasn't >>accepted. After discussions, it was decided that ADV7511 too would >>be converted into a bridge driver, and all the users of ADV7511 >>should assume it is a bridge. This bridge conversion was done in >>[4]. There is still some debate over whether the bridge driver be >>involved in the connector creation, or the KMS driver that has >>the whole view of the display pipeline. This discussion shouldn't >>affect this patch set, though. >> >> This patch set enables ADV7533 support with the above two issues >> now resolved. It also incorporates ADV7533 specific features and fixes >> that we've discovered since the first version of this patch was posted. >> >> Tested on ADV7533 chips on DB410c. It should work on the Hikey board too. >> I'd appreaciate if someone could test it on a ADV7511 platform since I >> don't have one. >> >> [4] >> https://lists.freedesktop.org/archives/dri-devel/2016-January/098287.html >> >> [3] >> https://lkml.org/lkml/2016/2/12/67 >> >> [2] >> https://lists.freedesktop.org/archives/dri-devel/2015-September/089884.html >> >> [1]: >> https://lists.freedesktop.org/archives/dri-devel/2015-July/087088.html >> >> Archit Taneja (7): >>drm/i2c: adv7511: Convert to drm_bridge >>drm/i2c: adv7511: Fix mutex deadlock when interrupts are disabled >>drm/i2c: adv7511: Initial support for ADV7533 >>drm/i2c: adv7511: Create a MIPI DSI device >>drm/i2c: adv7511: Use internal timing generator >>drm/i2c: adv7511: Change number of DSI lanes dynamically >>dt-bindings: drm/bridge: Update bindings for ADV7533 >> >> .../bindings/display/bridge/adi,adv7511.txt| 25 +- >> drivers/gpu/drm/i2c/adv7511.c | 539 >> + >> 2 files changed, 476 insertions(+), 88 deletions(-) >> >> -- >> The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, >> hosted by The Linux Foundation >> > > This patch set is Tested-by: Xinliang Liu Thanks for testing! Archit > > Thanks > -xinliang > -- > To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" in > the body of a message to majordomo at vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > -- The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, hosted by The Linux Foundation
[PATCH v2] drm/vc4: Return -EBUSY if there's already a pending flip event.
robert.foss at collabora.com writes: > From: Robert Foss > > As per the documentation in drm_crtc.h, atomic_commit should return > -EBUSY if an asycnhronous update is requested and there is an earlier > update pending. > > Note: docs cited here are drm_crtc.h, and the whole quote is: > > * - -EBUSY, if an asynchronous updated is requested and there is > *an earlier updated pending. Drivers are allowed to support a queue > *of outstanding updates, but currently no driver supports that. > *Note that drivers must wait for preceding updates to complete if a > *synchronous update is requested, they are not allowed to fail the > *commit in that case. > > Signed-off-by: Robert Foss This looks good to me. Let's give it a few days on the list for any other KMS folks to catch anything. -- next part -- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 818 bytes Desc: not available URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20160503/c0d82795/attachment.sig>
[PATCH v3 1/2] drm: bridge: Add sii902x driver
On Tue, 3 May 2016 11:53:18 +0200 Daniel Vetter wrote: > On Tue, May 3, 2016 at 11:39 AM, Boris Brezillon > wrote: > >> > + .detect = sii902x_connector_detect, > >> > + .fill_modes = drm_helper_probe_single_connector_modes, > >> > + .destroy = sii902x_connector_destroy, > >> > +}; > >> > >> I'm guessing this is to support both atomic and !atomic drivers. I > >> thought it was working automatically? > > > > Hm, the dw-hdmi driver is providing both, but maybe it's not needed. > > Daniel, any comments? > > You only need this in case you actually have atomic and !atomic users > of your bridge. We discussed whether we should have a dpms helper that > dtrt automatically, but with just 1 driver that doesn't seem worth it. > You wouldn't need to have 2 entier vfunc tables, you could just switch > on DRIVER_ATOMIC. Ok, I'll drop the !atomic helpers. Should I still test drm_core_check_feature(drm, DRIVER_ATOMIC) in the ->attach() implementation and return an error if the DRM device does not support atomic operations? -- Boris Brezillon, Free Electrons Embedded Linux and Kernel engineering http://free-electrons.com
[PATCH] drm/gem: support BO freeing without dev->struct_mutex
On Mon, May 2, 2016 at 4:40 AM, Daniel Vetter wrote:
> Finally all the core gem and a lot of drivers are entirely free of
> dev->struct_mutex depencies, and we can start to have an entirely
> lockless unref path.
>
> To make sure that no one who touches the core code accidentally breaks
> existing drivers which still require dev->struct_mutex I've made the
> might_lock check unconditional.
>
> While at it de-inline the ref/unref functions, they've become a bit
> too big.
>
> v2: Make it not leak like a sieve.
>
> v3: Review from Lucas:
> - drop != NULL in pointer checks.
> - fixup copypasted kerneldoc to actually match the functions.
>
> v4:
> Add __drm_gem_object_unreference as a fastpath helper for drivers who
> abolished dev->struct_mutex, requested by Chris.
>
> v5: Fix silly mistake in drm_gem_object_unreference_unlocked caught by
> intel-gfx CI - I checked for gem_free_object instead of
> gem_free_object_unlocked ...
>
> Cc: Chris Wilson
> Cc: Alex Deucher
> Cc: Lucas Stach
> Reviewed-by: Lucas Stach (v3)
> Reviewed-by: Chris Wilson (v4)
> Signed-off-by: Daniel Vetter
Reviewed-by: Alex Deucher
> ---
> drivers/gpu/drm/drm_gem.c | 54
> ++-
> include/drm/drmP.h| 15 ++---
> include/drm/drm_gem.h | 48 +
> 3 files changed, 80 insertions(+), 37 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_gem.c b/drivers/gpu/drm/drm_gem.c
> index 25dac31eef37..973eb8805ce0 100644
> --- a/drivers/gpu/drm/drm_gem.c
> +++ b/drivers/gpu/drm/drm_gem.c
> @@ -806,12 +806,64 @@ drm_gem_object_free(struct kref *kref)
>
> WARN_ON(!mutex_is_locked(&dev->struct_mutex));
>
> - if (dev->driver->gem_free_object != NULL)
> + if (dev->driver->gem_free_object_unlocked)
> + dev->driver->gem_free_object_unlocked(obj);
> + else if (dev->driver->gem_free_object)
> dev->driver->gem_free_object(obj);
> }
> EXPORT_SYMBOL(drm_gem_object_free);
>
> /**
> + * drm_gem_object_unreference_unlocked - release a GEM BO reference
> + * @obj: GEM buffer object
> + *
> + * This releases a reference to @obj. Callers must not hold the
> + * dev->struct_mutex lock when calling this function.
> + *
> + * See also __drm_gem_object_unreference().
> + */
> +void
> +drm_gem_object_unreference_unlocked(struct drm_gem_object *obj)
> +{
> + struct drm_device *dev;
> +
> + if (!obj)
> + return;
> +
> + dev = obj->dev;
> + might_lock(&dev->struct_mutex);
> +
> + if (dev->driver->gem_free_object_unlocked)
> + kref_put(&obj->refcount, drm_gem_object_free);
> + else if (kref_put_mutex(&obj->refcount, drm_gem_object_free,
> + &dev->struct_mutex))
> + mutex_unlock(&dev->struct_mutex);
> +}
> +EXPORT_SYMBOL(drm_gem_object_unreference_unlocked);
> +
> +/**
> + * drm_gem_object_unreference - release a GEM BO reference
> + * @obj: GEM buffer object
> + *
> + * This releases a reference to @obj. Callers must hold the dev->struct_mutex
> + * lock when calling this function, even when the driver doesn't use
> + * dev->struct_mutex for anything.
> + *
> + * For drivers not encumbered with legacy locking use
> + * drm_gem_object_unreference_unlocked() instead.
> + */
> +void
> +drm_gem_object_unreference(struct drm_gem_object *obj)
> +{
> + if (obj) {
> + WARN_ON(!mutex_is_locked(&obj->dev->struct_mutex));
> +
> + kref_put(&obj->refcount, drm_gem_object_free);
> + }
> +}
> +EXPORT_SYMBOL(drm_gem_object_unreference);
> +
> +/**
> * drm_gem_vm_open - vma->ops->open implementation for GEM
> * @vma: VM area structure
> *
> diff --git a/include/drm/drmP.h b/include/drm/drmP.h
> index c81dd2250fc6..bd7b262d7af0 100644
> --- a/include/drm/drmP.h
> +++ b/include/drm/drmP.h
> @@ -580,12 +580,21 @@ struct drm_driver {
> void (*debugfs_cleanup)(struct drm_minor *minor);
>
> /**
> -* Driver-specific constructor for drm_gem_objects, to set up
> -* obj->driver_private.
> +* @gem_free_object: deconstructor for drm_gem_objects
> *
> -* Returns 0 on success.
> +* This is deprecated and should not be used by new drivers. Use
> +* @gem_free_object_unlocked instead.
> */
> void (*gem_free_object) (struct drm_gem_object *obj);
> +
> + /**
> +* @gem_free_object_unlocked: deconstructor for drm_gem_objects
> +*
> +* This is for drivers which are not encumbered with dev->struct_mutex
> +* legacy locking schemes. Use this hook instead of @gem_free_object.
> +*/
> + void (*gem_free_object_unlocked) (struct drm_gem_object *obj);
> +
> int (*gem_open_object) (struct drm_gem_object *, struct drm_file *);
> void (*gem_close_object) (struct drm_gem_object *, struct drm_file *);
>
> diff --git a/include/drm/drm_gem.h b/include/drm/dr
[PATCH] drm/amdgpu: set metadata pointer to NULL after freeing.
On Tue, May 3, 2016 at 3:06 AM, Christian König
wrote:
> Am 03.05.2016 um 04:44 schrieb Dave Airlie:
>>
>> From: Dave Airlie
>>
>> Without this there was a double free of the metadata,
>> which ended up freeing the fd table for me here, and taking
>> out the machine more often than not.
>>
>> I reproduced with X.org + modesetting DDX + latest llvm/mesa,
>> also required using dri3.
>>
>> Cc: stable at vger.kernel.org
>> Signed-off-by: Dave Airlie
>
>
> Nice catch, patch is Reviewed-by: Christian König amd.com>
Applied! thanks.
Alex
>
>> ---
>> drivers/gpu/drm/amd/amdgpu/amdgpu_object.c | 1 +
>> 1 file changed, 1 insertion(+)
>>
>> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
>> b/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
>> index e557fc1..7ecea83 100644
>> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
>> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
>> @@ -541,6 +541,7 @@ int amdgpu_bo_set_metadata (struct amdgpu_bo *bo, void
>> *metadata,
>> if (!metadata_size) {
>> if (bo->metadata_size) {
>> kfree(bo->metadata);
>> + bo->metadata = NULL;
>> bo->metadata_size = 0;
>> }
>> return 0;
>
>
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3 1/2] drm: bridge: Add sii902x driver
On Tue, May 3, 2016 at 11:39 AM, Boris Brezillon wrote: >> > + .detect = sii902x_connector_detect, >> > + .fill_modes = drm_helper_probe_single_connector_modes, >> > + .destroy = sii902x_connector_destroy, >> > +}; >> >> I'm guessing this is to support both atomic and !atomic drivers. I >> thought it was working automatically? > > Hm, the dw-hdmi driver is providing both, but maybe it's not needed. > Daniel, any comments? You only need this in case you actually have atomic and !atomic users of your bridge. We discussed whether we should have a dpms helper that dtrt automatically, but with just 1 driver that doesn't seem worth it. You wouldn't need to have 2 entier vfunc tables, you could just switch on DRIVER_ATOMIC. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch
[PATCH v3 1/2] drm: bridge: Add sii902x driver
Hi Maxime,
On Mon, 2 May 2016 13:05:57 +0200
Maxime Ripard wrote:
> > +static void sii902x_reset(struct sii902x *sii902x)
> > +{
> > + gpiod_set_value(sii902x->reset_gpio, 1);
> > +
> > + msleep(100);
>
> Sleeping for 100ms seems like a lot. Is it required, or is it just a
> leftover from an early development?
I wish I had the answer, unfortunately I don't have the datasheet and
the implementation I based my work on [1] is sleeping 100ms.
>
> > +
> > + gpiod_set_value(sii902x->reset_gpio, 0);
> > +}
> > +
> > +static void sii902x_connector_destroy(struct drm_connector *connector)
> > +{
> > + drm_connector_unregister(connector);
> > + drm_connector_cleanup(connector);
> > +}
> > +
> > +static enum drm_connector_status
> > +sii902x_connector_detect(struct drm_connector *connector, bool force)
> > +{
> > + struct sii902x *sii902x = connector_to_sii902x(connector);
> > + unsigned int status;
> > +
> > + regmap_read(sii902x->regmap, SI902X_INT_STATUS, &status);
> > +
> > + return (status & SI902X_PLUGGED_STATUS) ?
> > + connector_status_connected : connector_status_disconnected;
> > +}
> > +
> > +static const struct drm_connector_funcs sii902x_atomic_connector_funcs = {
> > + .dpms = drm_atomic_helper_connector_dpms,
> > + .detect = sii902x_connector_detect,
> > + .fill_modes = drm_helper_probe_single_connector_modes,
> > + .destroy = sii902x_connector_destroy,
> > + .reset = drm_atomic_helper_connector_reset,
> > + .atomic_duplicate_state = drm_atomic_helper_connector_duplicate_state,
> > + .atomic_destroy_state = drm_atomic_helper_connector_destroy_state,
> > +};
> > +
> > +static const struct drm_connector_funcs sii902x_connector_funcs = {
> > + .dpms = drm_atomic_helper_connector_dpms,
Should be drm_atomic_helper_dpms here.
> > + .detect = sii902x_connector_detect,
> > + .fill_modes = drm_helper_probe_single_connector_modes,
> > + .destroy = sii902x_connector_destroy,
> > +};
>
> I'm guessing this is to support both atomic and !atomic drivers. I
> thought it was working automatically?
Hm, the dw-hdmi driver is providing both, but maybe it's not needed.
Daniel, any comments?
Thanks for the review.
Boris
[1]https://github.com/linux4sam/linux-at91/blob/linux-3.10-at91/drivers/hdmi/encoder-sii9022.c#L92
--
Boris Brezillon, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
[PATCH] drm/atomic: Add WARN_ON when state->acquire_ctx is not set.
When I was writing an atomic wrapper for rmfb, I ran into the
following backtrace from lockdep:
=
[ INFO: possible recursive locking detected ]
4.5.0-patser+ #4696 Tainted: G U
-
kworker/2:2/2608 is trying to acquire lock:
(crtc_ww_class_mutex){+.+.+.}, at: []
drm_modeset_lock+0x7c/0x120 [drm]
but task is already holding lock:
(crtc_ww_class_mutex){+.+.+.}, at: []
modeset_backoff+0x8d/0x220 [drm]
other info that might help us debug this:
Possible unsafe locking scenario:
CPU0
lock(crtc_ww_class_mutex);
lock(crtc_ww_class_mutex);
*** DEADLOCK ***
May be due to missing lock nesting notation
4 locks held by kworker/2:2/2608:
#0: ("events"){.+.+.+}, at: [] process_one_work+0x15a/0x6c0
#1: ((&arg.work)){+.+.+.}, at: []
process_one_work+0x15a/0x6c0
#2: (crtc_ww_class_acquire){+.+.+.}, at: []
drm_atomic_helper_remove_fb+0x4a/0x1d0 [drm_kms_helper]
#3: (crtc_ww_class_mutex){+.+.+.}, at: []
modeset_backoff+0x8d/0x220 [drm]
While lockdep probably catches this bug when it happens, it's better
to explicitly warn when state->acquire_ctx is not set.
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/drm_atomic.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
index 0b526423f19f..69adcf3944cc 100644
--- a/drivers/gpu/drm/drm_atomic.c
+++ b/drivers/gpu/drm/drm_atomic.c
@@ -263,6 +263,8 @@ drm_atomic_get_crtc_state(struct drm_atomic_state *state,
int ret, index = drm_crtc_index(crtc);
struct drm_crtc_state *crtc_state;
+ WARN_ON(!state->acquire_ctx);
+
crtc_state = drm_atomic_get_existing_crtc_state(state, crtc);
if (crtc_state)
return crtc_state;
@@ -622,6 +624,8 @@ drm_atomic_get_plane_state(struct drm_atomic_state *state,
int ret, index = drm_plane_index(plane);
struct drm_plane_state *plane_state;
+ WARN_ON(!state->acquire_ctx);
+
plane_state = drm_atomic_get_existing_plane_state(state, plane);
if (plane_state)
return plane_state;
@@ -890,6 +894,8 @@ drm_atomic_get_connector_state(struct drm_atomic_state
*state,
struct drm_mode_config *config = &connector->dev->mode_config;
struct drm_connector_state *connector_state;
+ WARN_ON(!state->acquire_ctx);
+
ret = drm_modeset_lock(&config->connection_mutex, state->acquire_ctx);
if (ret)
return ERR_PTR(ret);
--
2.5.5
[Intel-gfx] [PATCH] drm/i915: Discard previous atomic state on resume if connectors change
Yeah airlied said the same thing. This patch is more intended for just 4.6 since
the refcounting patch isn't very likely to get into 4.6.
On Tue, 2016-05-03 at 16:29 +0200, Daniel Vetter wrote:
> On Tue, May 03, 2016 at 10:03:40AM -0400, Lyude wrote:
> >
> > If an MST device is disconnected while the machine is suspended, the
> > number of connectors will change as well after we call
> > intel_dp_mst_resume(). This means that any previous atomic state we had
> > before suspending is no longer valid, since it'll still be pointing to
> > missing connectors. We need to check for this before committing the
> > state, otherwise we'll kernel panic on resume whenever if any MST
> > display was disconnected before we started resuming:
> >
> > BUG: unable to handle kernel NULL pointer dereference at 0008
> > IP: [] drm_atomic_helper_check_modeset+0x29f/0xb40
> > [drm_kms_helper]
> > Call Trace:
> > Â [] intel_atomic_check+0x34/0x1180 [i915]
> > Â [] ? mark_held_locks+0x6f/0xa0
> > Â [] ? trace_hardirqs_on_caller+0x129/0x1b0
> > Â [] drm_atomic_check_only+0x192/0x620 [drm]
> > Â [] ? pci_pm_thaw+0x21/0x90
> > Â [] drm_atomic_commit+0x17/0x60 [drm]
> > Â [] intel_display_resume+0xbd/0x160 [i915]
> > Â [] ? pci_pm_thaw+0x90/0x90
> > Â [] i915_drm_resume+0xd8/0x160 [i915]
> > Â [] i915_pm_resume+0x25/0x30 [i915]
> > Â [] pci_pm_resume+0x64/0xa0
> > Â [] dpm_run_callback+0x90/0x190
> > Â [] device_resume+0xd5/0x1f0
> > Â [] async_resume+0x1d/0x50
> > Â [] async_run_entry_fn+0x48/0x150
> > Â [] process_one_work+0x1e9/0x5c0
> > Â [] ? process_one_work+0x166/0x5c0
> > Â [] worker_thread+0x48/0x4e0
> > Â [] ? process_one_work+0x5c0/0x5c0
> > Â [] kthread+0xe4/0x100
> > Â [] ret_from_fork+0x22/0x50
> > Â [] ? kthread_create_on_node+0x200/0x200
> >
> > Cc: stable at vger.kernel.org
> > Signed-off-by: Lyude
> This should be addressed by the connector refcounting fixes Dave Airlie
> has for 4.7 (not all merged yet though). Can you please retest with those?
> -Daniel
>
> >
> > ---
> > Â drivers/gpu/drm/i915/intel_display.c | 11 +++
> > Â 1 file changed, 11 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/i915/intel_display.c
> > b/drivers/gpu/drm/i915/intel_display.c
> > index 6e0d828..252c06c 100644
> > --- a/drivers/gpu/drm/i915/intel_display.c
> > +++ b/drivers/gpu/drm/i915/intel_display.c
> > @@ -15945,6 +15945,17 @@ void intel_display_resume(struct drm_device *dev)
> > Â dev_priv->modeset_restore_state = NULL;
> > Â
> > Â /*
> > + Â * With MST, the number of connectors can change between suspend
> > and
> > + Â * resume, which means that the state we want to restore might now
> > be
> > + Â * impossible to use since it'll be pointing to non-existant
> > + Â * connectors.
> > + Â */
> > + if (state->num_connector != dev->mode_config.num_connector) {
> > + drm_atomic_state_free(state);
> > + state = NULL;
> > + }
> > +
> > + /*
> > Â Â * This is a cludge because with real atomic modeset
> > mode_config.mutex
> > Â Â * won't be taken. Unfortunately some probed state like
> > Â Â * audio_codec_enable is still protected by mode_config.mutex, so
> > lock
> > --Â
> > 2.5.5
> >
> > ___
> > Intel-gfx mailing list
> > Intel-gfx at lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[PATCH v3 2/2] dt-bindings: imx: ldb: Add ddc-i2c-bus property
On Fri, Apr 29, 2016 at 09:44:12AM +0200, Philipp Zabel wrote: > Am Donnerstag, den 28.04.2016, 16:48 -0500 schrieb Rob Herring: > > On Wed, Apr 27, 2016 at 04:23:34PM -0400, Akshay Bhat wrote: > > > Document the ddc-i2c-bus property used by imx-ldb driver to read EDID > > > information via I2C interface. > > > > > > Signed-off-by: Akshay Bhat > > > --- > > > > > > v3: > > > Newly added. > > > > > > Documentation/devicetree/bindings/display/imx/ldb.txt | 1 + > > > 1 file changed, 1 insertion(+) > > > > > > diff --git a/Documentation/devicetree/bindings/display/imx/ldb.txt > > > b/Documentation/devicetree/bindings/display/imx/ldb.txt > > > index 0a175d9..a407462 100644 > > > --- a/Documentation/devicetree/bindings/display/imx/ldb.txt > > > +++ b/Documentation/devicetree/bindings/display/imx/ldb.txt > > > @@ -62,6 +62,7 @@ Required properties: > > > display-timings are used instead. > > > > > > Optional properties (required if display-timings are used): > > > > The required part doesn't make sense if you add this, but... > > > > > + - ddc-i2c-bus: phandle of an I2C controller used for DDC EDID probing > > > > Really, this should be part of a connector node since i2c goes from the > > i2c controller to a connector and is not part of the display controller. > > If the ddc i2c bus does indeed go through a connector, yes. Would that > warrant a generic "lvds-connector" binding for all those different types > of internal LVDS connectors? Probably an overkill for that case. It could be part of the panel node, but I'm reluctant to define a 3rd way. So this is fine as is. Acked-by: Rob Herring Rob
[Bug 94900] HD6950 GPU lockup with various steam games (octodad, saints row 4)
https://bugs.freedesktop.org/show_bug.cgi?id=94900 --- Comment #3 from Daniel T. --- Saints row 4 causes this lockup [118144.509627] radeon :01:00.0: ring 0 stalled for more than 10060msec [118144.509638] radeon :01:00.0: GPU lockup (current fence id 0x01dccef9 last fence id 0x01dccefe on ring 0) [118144.582926] radeon :01:00.0: ring 4 stalled for more than 10133msec [118144.582941] radeon :01:00.0: GPU lockup (current fence id 0x00a861a1 last fence id 0x00a861a2 on ring 4) [118145.009595] radeon :01:00.0: ring 0 stalled for more than 10560msec [118145.009605] radeon :01:00.0: GPU lockup (current fence id 0x01dccef9 last fence id 0x01dccefe on ring 0) [118145.082921] radeon :01:00.0: ring 4 stalled for more than 10633msec [118145.082930] radeon :01:00.0: GPU lockup (current fence id 0x00a861a1 last fence id 0x00a861a2 on ring 4) [118145.509637] radeon :01:00.0: ring 0 stalled for more than 11060msec [118145.509647] radeon :01:00.0: GPU lockup (current fence id 0x01dccef9 last fence id 0x01dccefe on ring 0) [118145.579594] radeon :01:00.0: ring 4 stalled for more than 11130msec [118145.579603] radeon :01:00.0: GPU lockup (current fence id 0x00a861a1 last fence id 0x00a861a2 on ring 4) [118146.009631] radeon :01:00.0: ring 0 stalled for more than 11560msec [118146.009641] radeon :01:00.0: GPU lockup (current fence id 0x01dccef9 last fence id 0x01dccefe on ring 0) [118146.082911] radeon :01:00.0: ring 4 stalled for more than 11633msec [118146.082921] radeon :01:00.0: GPU lockup (current fence id 0x00a861a1 last fence id 0x00a861a2 on ring 4) [118146.379880] radeon :01:00.0: Saved 31 dwords of commands on ring 0. [118146.379961] radeon :01:00.0: GPU softreset: 0x0029 [118146.379963] radeon :01:00.0: GRBM_STATUS = 0xE5703828 [118146.379964] radeon :01:00.0: GRBM_STATUS_SE0 = 0xFC07 [118146.379965] radeon :01:00.0: GRBM_STATUS_SE1 = 0x0007 [118146.379966] radeon :01:00.0: SRBM_STATUS = 0x20C0 [118146.380033] radeon :01:00.0: SRBM_STATUS2 = 0x [118146.380034] radeon :01:00.0: R_008674_CP_STALLED_STAT1 = 0x [118146.380035] radeon :01:00.0: R_008678_CP_STALLED_STAT2 = 0x00018000 [118146.380036] radeon :01:00.0: R_00867C_CP_BUSY_STAT = 0x8004 [118146.380037] radeon :01:00.0: R_008680_CP_STAT = 0x80038647 [118146.380039] radeon :01:00.0: R_00D034_DMA_STATUS_REG = 0x44C83D57 [118146.380040] radeon :01:00.0: R_00D834_DMA_STATUS_REG = 0x44C83146 [118146.380041] radeon :01:00.0: VM_CONTEXT0_PROTECTION_FAULT_ADDR 0x [118146.380043] radeon :01:00.0: VM_CONTEXT0_PROTECTION_FAULT_STATUS 0x [118146.380044] radeon :01:00.0: VM_CONTEXT1_PROTECTION_FAULT_ADDR 0x [118146.380045] radeon :01:00.0: VM_CONTEXT1_PROTECTION_FAULT_STATUS 0x [118146.390413] radeon :01:00.0: GRBM_SOFT_RESET=0xDF7B [118146.390465] radeon :01:00.0: SRBM_SOFT_RESET=0x0140 [118146.391620] radeon :01:00.0: GRBM_STATUS = 0x3828 [118146.391621] radeon :01:00.0: GRBM_STATUS_SE0 = 0x0007 [118146.391622] radeon :01:00.0: GRBM_STATUS_SE1 = 0x0007 [118146.391623] radeon :01:00.0: SRBM_STATUS = 0x20C0 [118146.391690] radeon :01:00.0: SRBM_STATUS2 = 0x [118146.391691] radeon :01:00.0: R_008674_CP_STALLED_STAT1 = 0x [118146.391692] radeon :01:00.0: R_008678_CP_STALLED_STAT2 = 0x [118146.391693] radeon :01:00.0: R_00867C_CP_BUSY_STAT = 0x [118146.391694] radeon :01:00.0: R_008680_CP_STAT = 0x [118146.391696] radeon :01:00.0: R_00D034_DMA_STATUS_REG = 0x44C83D57 [118146.391697] radeon :01:00.0: R_00D834_DMA_STATUS_REG = 0x44C83D57 [118146.391772] radeon :01:00.0: GPU reset succeeded, trying to resume -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20160503/a558fff4/attachment-0001.html>
[Bug 94900] HD6950 GPU lockup with various steam games (octodad, saints row 4)
https://bugs.freedesktop.org/show_bug.cgi?id=94900 Daniel T. changed: What|Removed |Added Summary|HD6950 GPU lockup with |HD6950 GPU lockup with |octodad: dadliest catch |various steam games ||(octodad, saints row 4) -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20160503/5f4915fd/attachment.html>
[PATCH] drm/edid : calculate vsync and hsync from range limits block according to the EDID 1.4
Do calculation of vsync and hsync from range limits EDID block according to the spec. EDID 1.4. Signed-off-by: Vitaly Prosyak --- drivers/gpu/drm/drm_edid.c | 16 1 file changed, 8 insertions(+), 8 deletions(-) diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c index 7e49962..601152b 100644 --- a/drivers/gpu/drm/drm_edid.c +++ b/drivers/gpu/drm/drm_edid.c @@ -1977,11 +1977,11 @@ mode_in_hsync_range(const struct drm_display_mode *mode, int hsync, hmin, hmax; hmin = t[7]; - if (edid->revision >= 4) - hmin += ((t[4] & 0x04) ? 255 : 0); + if (edid->revision >= 4 && ((t[4] & 0x0c) == 0x0c)) + hmin += 255 ; hmax = t[8]; - if (edid->revision >= 4) - hmax += ((t[4] & 0x08) ? 255 : 0); + if (edid->revision >= 4 && (t[4] & 0x08)) + hmax += 255; hsync = drm_mode_hsync(mode); return (hsync <= hmax && hsync >= hmin); @@ -1994,11 +1994,11 @@ mode_in_vsync_range(const struct drm_display_mode *mode, int vsync, vmin, vmax; vmin = t[5]; - if (edid->revision >= 4) - vmin += ((t[4] & 0x01) ? 255 : 0); + if (edid->revision >= 4 && ((t[4] & 0x03) == 0x03)) + vmin += 255; vmax = t[6]; - if (edid->revision >= 4) - vmax += ((t[4] & 0x02) ? 255 : 0); + if (edid->revision >= 4 && (t[4] & 0x02)) + vmax += 255; vsync = drm_mode_vrefresh(mode); return (vsync <= vmax && vsync >= vmin); -- 1.9.1
[PATCH] drm/edid : cache edid range limits in drm connector
Cache in drm connector the edid range limits properties:
min/max vertical refresh rates and max pixel clock.
It would be used when enter to drr mode.
Signed-off-by: Vitaly Prosyak
---
drivers/gpu/drm/drm_edid.c | 11 +++
include/drm/drm_crtc.h | 5 +
2 files changed, 16 insertions(+)
diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index 04cb487..7e49962 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -2190,6 +2190,17 @@ do_inferred_modes(struct detailed_timing *timing, void
*c)
timing);
break;
case 0x01: /* just the ranges, no formula */
+ closure->connector->min_vfreq = range->min_vfreq;
+ closure->connector->max_vfreq = range->max_vfreq;
+ if (closure->edid->revision >= 4) {
+ if ((range->flags & 0x03) == 0x3)
+ closure->connector->min_vfreq += 255;
+ if (range->flags & 0x02)
+ closure->connector->max_vfreq += 255;
+ }
+ closure->connector->max_pixel_clock_khz =
+ range_pixel_clock(closure->edid, (u8 *)timing);
+ break;
default:
break;
}
diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
index c5b4b81..85fc554 100644
--- a/include/drm/drm_crtc.h
+++ b/include/drm/drm_crtc.h
@@ -1230,6 +1230,11 @@ struct drm_connector {
uint8_t num_h_tile, num_v_tile;
uint8_t tile_h_loc, tile_v_loc;
uint16_t tile_h_size, tile_v_size;
+
+ /*EDID range limits for drr*/
+ int min_vfreq ;
+ int max_vfreq ;
+ int max_pixel_clock_khz;
};
/**
--
1.9.1
[PATCH] Revert "drm/i915: start adding dp mst audio"
Right now MST audio is causing too many kernel panics to really keep
around in the kernel. On top of that, even after fixing said panics it's
still basically non-functional (at least on all the setups I've tested
it on). Revert until we have a proper solution for this.
This reverts commit 3d52ccf52f2c51f613e42e65be0f06e4e6788093.
Signed-off-by: Lyude
---
drivers/gpu/drm/i915/i915_debugfs.c | 16
drivers/gpu/drm/i915/intel_audio.c | 9 +++--
drivers/gpu/drm/i915/intel_ddi.c| 24 +---
drivers/gpu/drm/i915/intel_dp_mst.c | 22 --
drivers/gpu/drm/i915/intel_drv.h| 2 --
5 files changed, 8 insertions(+), 65 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
b/drivers/gpu/drm/i915/i915_debugfs.c
index a0f1bd7..e3f4c72 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -2872,20 +2872,6 @@ static void intel_dp_info(struct seq_file *m,
intel_panel_info(m, &intel_connector->panel);
}
-static void intel_dp_mst_info(struct seq_file *m,
- struct intel_connector *intel_connector)
-{
- struct intel_encoder *intel_encoder = intel_connector->encoder;
- struct intel_dp_mst_encoder *intel_mst =
- enc_to_mst(&intel_encoder->base);
- struct intel_digital_port *intel_dig_port = intel_mst->primary;
- struct intel_dp *intel_dp = &intel_dig_port->dp;
- bool has_audio = drm_dp_mst_port_has_audio(&intel_dp->mst_mgr,
- intel_connector->port);
-
- seq_printf(m, "\taudio support: %s\n", yesno(has_audio));
-}
-
static void intel_hdmi_info(struct seq_file *m,
struct intel_connector *intel_connector)
{
@@ -2929,8 +2915,6 @@ static void intel_connector_info(struct seq_file *m,
intel_hdmi_info(m, intel_connector);
else if (intel_encoder->type == INTEL_OUTPUT_LVDS)
intel_lvds_info(m, intel_connector);
- else if (intel_encoder->type == INTEL_OUTPUT_DP_MST)
- intel_dp_mst_info(m, intel_connector);
}
seq_printf(m, "\tmodes:\n");
diff --git a/drivers/gpu/drm/i915/intel_audio.c
b/drivers/gpu/drm/i915/intel_audio.c
index 30f9214..7d281b4 100644
--- a/drivers/gpu/drm/i915/intel_audio.c
+++ b/drivers/gpu/drm/i915/intel_audio.c
@@ -262,8 +262,7 @@ static void hsw_audio_codec_disable(struct intel_encoder
*encoder)
tmp |= AUD_CONFIG_N_PROG_ENABLE;
tmp &= ~AUD_CONFIG_UPPER_N_MASK;
tmp &= ~AUD_CONFIG_LOWER_N_MASK;
- if (intel_pipe_has_type(intel_crtc, INTEL_OUTPUT_DISPLAYPORT) ||
- intel_pipe_has_type(intel_crtc, INTEL_OUTPUT_DP_MST))
+ if (intel_pipe_has_type(intel_crtc, INTEL_OUTPUT_DISPLAYPORT))
tmp |= AUD_CONFIG_N_VALUE_INDEX;
I915_WRITE(HSW_AUD_CFG(pipe), tmp);
@@ -476,8 +475,7 @@ static void ilk_audio_codec_enable(struct drm_connector
*connector,
tmp &= ~AUD_CONFIG_N_VALUE_INDEX;
tmp &= ~AUD_CONFIG_N_PROG_ENABLE;
tmp &= ~AUD_CONFIG_PIXEL_CLOCK_HDMI_MASK;
- if (intel_pipe_has_type(intel_crtc, INTEL_OUTPUT_DISPLAYPORT) ||
- intel_pipe_has_type(intel_crtc, INTEL_OUTPUT_DP_MST))
+ if (intel_pipe_has_type(intel_crtc, INTEL_OUTPUT_DISPLAYPORT))
tmp |= AUD_CONFIG_N_VALUE_INDEX;
else
tmp |= audio_config_hdmi_pixel_clock(adjusted_mode);
@@ -515,8 +513,7 @@ void intel_audio_codec_enable(struct intel_encoder
*intel_encoder)
/* ELD Conn_Type */
connector->eld[5] &= ~(3 << 2);
- if (intel_pipe_has_type(crtc, INTEL_OUTPUT_DISPLAYPORT) ||
- intel_pipe_has_type(crtc, INTEL_OUTPUT_DP_MST))
+ if (intel_pipe_has_type(crtc, INTEL_OUTPUT_DISPLAYPORT))
connector->eld[5] |= (1 << 2);
connector->eld[6] = drm_av_sync_delay(connector, adjusted_mode) / 2;
diff --git a/drivers/gpu/drm/i915/intel_ddi.c b/drivers/gpu/drm/i915/intel_ddi.c
index 62de9f4..1c3487a 100644
--- a/drivers/gpu/drm/i915/intel_ddi.c
+++ b/drivers/gpu/drm/i915/intel_ddi.c
@@ -3098,23 +3098,6 @@ void intel_ddi_fdi_disable(struct drm_crtc *crtc)
I915_WRITE(FDI_RX_CTL(PIPE_A), val);
}
-bool intel_ddi_is_audio_enabled(struct drm_i915_private *dev_priv,
-struct intel_crtc *intel_crtc)
-{
- u32 temp;
-
- if (intel_display_power_get_if_enabled(dev_priv, POWER_DOMAIN_AUDIO)) {
- temp = I915_READ(HSW_AUD_PIN_ELD_CP_VLD);
-
- intel_display_power_put(dev_priv, POWER_DOMAIN_AUDIO);
-
- if (temp & AUDIO_OUTPUT_ENABLE(intel_crtc->pipe))
- return true;
- }
-
- return false;
-}
-
void intel_ddi_get_config(struct intel_encoder *encoder,
struct intel_crtc_state *pipe_config)
{
@@ -3175,8 +3158,11 @@ void intel_ddi_get_config(struct intel_encoder *
[PATCH] st/omx/enc: fix incorrect reference picture order for B frames
Never mind. Sorry about it.
On 05/03/2016 10:49 AM, Leo Liu wrote:
> Stacking frames is for driver that's capable to do dual instances
> encoding. Such feature is not enabled for B frames currently.
>
> Signed-off-by: Leo Liu
> Cc: "11.1 11.2"
> ---
> src/gallium/state_trackers/omx/vid_enc.c | 19 ---
> 1 file changed, 12 insertions(+), 7 deletions(-)
>
> diff --git a/src/gallium/state_trackers/omx/vid_enc.c
> b/src/gallium/state_trackers/omx/vid_enc.c
> index 5565241..d70439a 100644
> --- a/src/gallium/state_trackers/omx/vid_enc.c
> +++ b/src/gallium/state_trackers/omx/vid_enc.c
> @@ -180,11 +180,6 @@ static OMX_ERRORTYPE
> vid_enc_Constructor(OMX_COMPONENTTYPE *comp, OMX_STRING nam
> PIPE_VIDEO_ENTRYPOINT_ENCODE,
> PIPE_VIDEO_CAP_SUPPORTED))
> return OMX_ErrorBadParameter;
>
> - priv->stacked_frames_num = screen->get_video_param(screen,
> -PIPE_VIDEO_PROFILE_MPEG4_AVC_HIGH,
> -PIPE_VIDEO_ENTRYPOINT_ENCODE,
> -PIPE_VIDEO_CAP_STACKED_FRAMES);
> -
> priv->s_pipe = screen->context_create(screen, priv->screen, 0);
> if (!priv->s_pipe)
> return OMX_ErrorInsufficientResources;
> @@ -699,9 +694,19 @@ static OMX_ERRORTYPE
> vid_enc_MessageHandler(OMX_COMPONENTTYPE* comp, internalReq
> priv->scale.xWidth :
> port->sPortParam.format.video.nFrameWidth;
>templat.height = priv->scale_buffer[priv->current_scale_buffer] ?
> priv->scale.xHeight :
> port->sPortParam.format.video.nFrameHeight;
> - templat.max_references = (templat.profile ==
> PIPE_VIDEO_PROFILE_MPEG4_AVC_BASELINE) ?
> -1 : OMX_VID_ENC_P_PERIOD_DEFAULT;
>
> + if (templat.profile == PIPE_VIDEO_PROFILE_MPEG4_AVC_BASELINE) {
> +struct pipe_screen *screen = priv->screen->pscreen;
> +templat.max_references = 1;
> +priv->stacked_frames_num =
> + screen->get_video_param(screen,
> + PIPE_VIDEO_PROFILE_MPEG4_AVC_HIGH,
> + PIPE_VIDEO_ENTRYPOINT_ENCODE,
> + PIPE_VIDEO_CAP_STACKED_FRAMES);
> + } else {
> +templat.max_references = OMX_VID_ENC_P_PERIOD_DEFAULT;
> +priv->stacked_frames_num = 1;
> + }
>priv->codec = priv->s_pipe->create_video_codec(priv->s_pipe,
> &templat);
>
> } else if ((msg->messageParam == OMX_StateLoaded) && (priv->state ==
> OMX_StateIdle)) {
[PATCH] st/omx/enc: fix incorrect reference picture order for B frames
Stacking frames is for driver that's capable to do dual instances
encoding. Such feature is not enabled for B frames currently.
Signed-off-by: Leo Liu
Cc: "11.1 11.2"
---
src/gallium/state_trackers/omx/vid_enc.c | 19 ---
1 file changed, 12 insertions(+), 7 deletions(-)
diff --git a/src/gallium/state_trackers/omx/vid_enc.c
b/src/gallium/state_trackers/omx/vid_enc.c
index 5565241..d70439a 100644
--- a/src/gallium/state_trackers/omx/vid_enc.c
+++ b/src/gallium/state_trackers/omx/vid_enc.c
@@ -180,11 +180,6 @@ static OMX_ERRORTYPE vid_enc_Constructor(OMX_COMPONENTTYPE
*comp, OMX_STRING nam
PIPE_VIDEO_ENTRYPOINT_ENCODE,
PIPE_VIDEO_CAP_SUPPORTED))
return OMX_ErrorBadParameter;
- priv->stacked_frames_num = screen->get_video_param(screen,
-PIPE_VIDEO_PROFILE_MPEG4_AVC_HIGH,
-PIPE_VIDEO_ENTRYPOINT_ENCODE,
-PIPE_VIDEO_CAP_STACKED_FRAMES);
-
priv->s_pipe = screen->context_create(screen, priv->screen, 0);
if (!priv->s_pipe)
return OMX_ErrorInsufficientResources;
@@ -699,9 +694,19 @@ static OMX_ERRORTYPE
vid_enc_MessageHandler(OMX_COMPONENTTYPE* comp, internalReq
priv->scale.xWidth :
port->sPortParam.format.video.nFrameWidth;
templat.height = priv->scale_buffer[priv->current_scale_buffer] ?
priv->scale.xHeight :
port->sPortParam.format.video.nFrameHeight;
- templat.max_references = (templat.profile ==
PIPE_VIDEO_PROFILE_MPEG4_AVC_BASELINE) ?
-1 : OMX_VID_ENC_P_PERIOD_DEFAULT;
+ if (templat.profile == PIPE_VIDEO_PROFILE_MPEG4_AVC_BASELINE) {
+struct pipe_screen *screen = priv->screen->pscreen;
+templat.max_references = 1;
+priv->stacked_frames_num =
+ screen->get_video_param(screen,
+ PIPE_VIDEO_PROFILE_MPEG4_AVC_HIGH,
+ PIPE_VIDEO_ENTRYPOINT_ENCODE,
+ PIPE_VIDEO_CAP_STACKED_FRAMES);
+ } else {
+templat.max_references = OMX_VID_ENC_P_PERIOD_DEFAULT;
+priv->stacked_frames_num = 1;
+ }
priv->codec = priv->s_pipe->create_video_codec(priv->s_pipe,
&templat);
} else if ((msg->messageParam == OMX_StateLoaded) && (priv->state ==
OMX_StateIdle)) {
--
2.7.4
[GIT PULL] imx-drm module autoloading fix
Hi Dave,
here is the imx-ipuv3-crtc autoloading fix so you don't have to revert commit
304e6be652e2 ("gpu: ipu-v3: Assign of_node of child platform devices to
corresponding ports").
regards
Philipp
The following changes since commit 02da2d72174c61988eb4456b53f405e3ebdebce4:
Linux 4.6-rc5 (2016-04-24 16:17:05 -0700)
are available in the git repository at:
git://git.pengutronix.de/git/pza/linux.git tags/imx-drm-fixes-2016-05-03
for you to fetch changes up to 7a850aca7e2f0aba312e68285c1a381aabd8860e:
gpu: ipu-v3: Fix imx-ipuv3-crtc module autoloading (2016-04-27 16:09:32 +0200)
imx-drm module autoloading fix
Commit 304e6be652e2 ("gpu: ipu-v3: Assign of_node of child platform devices to
corresponding ports") broke autoloading of the imx-ipuv3-crtc module, this
reenables the platform modalias to fix it.
Philipp Zabel (1):
gpu: ipu-v3: Fix imx-ipuv3-crtc module autoloading
drivers/gpu/ipu-v3/ipu-common.c | 7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
