Re: [Intel-gfx] [PATCH 1/9] drm/i915: Check pixel clock when setting mode for DP
On Fri, 2015-07-03 at 15:57 +0300, Ville Syrjälä wrote:
> On Fri, Jul 03, 2015 at 02:35:49PM +0300, Mika Kahola wrote:
> > It is possible the we request to have a mode that has
> > higher pixel clock than our HW can support. This patch
> > checks if requested pixel clock is lower than the one
> > supported by the HW. The requested mode is discarded
> > if we cannot support the requested pixel clock.
> >
> > This patch applies to DisplayPort.
> >
> > Signed-off-by: Mika Kahola
> > ---
> > drivers/gpu/drm/i915/intel_dp.c | 25 -
> > 1 file changed, 24 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/gpu/drm/i915/intel_dp.c
> > b/drivers/gpu/drm/i915/intel_dp.c
> > index fcc64e5..2e55dff 100644
> > --- a/drivers/gpu/drm/i915/intel_dp.c
> > +++ b/drivers/gpu/drm/i915/intel_dp.c
> > @@ -197,6 +197,26 @@ intel_dp_max_data_rate(int max_link_clock, int
> > max_lanes)
> > return (max_link_clock * max_lanes * 8) / 10;
> > }
> >
> > +static int
> > +intel_dp_max_pixclk(struct intel_dp *intel_dp)
> > +{
> > + struct intel_digital_port *intel_dig_port = dp_to_dig_port(intel_dp);
> > + struct intel_encoder *encoder = &intel_dig_port->base;
> > + struct drm_device *dev = encoder->base.dev;
> > + struct drm_crtc *crtc = intel_dig_port->base.base.crtc;
> > + struct drm_i915_private *dev_priv = to_i915(dev);
> > + struct intel_crtc *intel_crtc = to_intel_crtc(crtc);
> > +
> > + if (IS_CHERRYVIEW(dev))
> > + return DIV_ROUND_UP(dev_priv->max_cdclk_freq * 100, 95);
>
> Maybe we should precompute this stuff and store as max_dotclock into dev_priv?
> It has really nothing to do with DP.
>
> > + else if (IS_VALLEYVIEW(dev))
> > + return DIV_ROUND_UP(dev_priv->max_cdclk_freq * 100, 90);
> > + else if (IS_BROADWELL(dev) && intel_crtc->config->ips_enabled)
>
> You can't look at the current crtc config at this point. Here we just
> need to consider the max we can support under any conditions and filter
> the modes based on that. That does mean that under some circumstances
> not all of the validated modes will actually work, but there's really
> nothing sensible we can do about that.
>
> In the specific case of IPS, we can always choose to disable it at
> modeset time if the mode would otherwise exceed the limit. So IPS is
> never a good reason for rejecting a mode.
>
> > + return DIV_ROUND_UP(dev_priv->max_cdclk_freq * 100, 95);
> > + else
> > + return dev_priv->max_cdclk_freq;
>
> 90% is the correct limit for all older platforms.
>
> Exceptions are CHV which has the 95% limit, and starting from HSW+
> we should be able to handle 100%.
>
> For gen2/3 we also have the option of using double wide mode which means
> the limit there should be 2 * cdclk * 9 / 10.
>
Thanks for the comments. I rephrase this patch series and store the
dotclock in dev_priv. This way, I hope, I can get rid of the repetitive
code what Chris pointed out.
Cheers,
Mika
> > +}
> > +
> > static enum drm_mode_status
> > intel_dp_mode_valid(struct drm_connector *connector,
> > struct drm_display_mode *mode)
> > @@ -206,6 +226,7 @@ intel_dp_mode_valid(struct drm_connector *connector,
> > struct drm_display_mode *fixed_mode = intel_connector->panel.fixed_mode;
> > int target_clock = mode->clock;
> > int max_rate, mode_rate, max_lanes, max_link_clock;
> > + int max_pixclk;
> >
> > if (is_edp(intel_dp) && fixed_mode) {
> > if (mode->hdisplay > fixed_mode->hdisplay)
> > @@ -223,7 +244,9 @@ intel_dp_mode_valid(struct drm_connector *connector,
> > max_rate = intel_dp_max_data_rate(max_link_clock, max_lanes);
> > mode_rate = intel_dp_link_required(target_clock, 18);
> >
> > - if (mode_rate > max_rate)
> > + max_pixclk = intel_dp_max_pixclk(intel_dp);
> > +
> > + if ((mode_rate > max_rate) || (target_clock > max_pixclk))
> > return MODE_CLOCK_HIGH;
> >
> > if (mode->clock < 1)
> > --
> > 1.9.1
> >
> > ___
> > Intel-gfx mailing list
> > Intel-gfx@lists.freedesktop.org
> > http://lists.freedesktop.org/mailman/listinfo/intel-gfx
>
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] Error in inner loop in validate_cmds_sorted / out of bounds issue
On Mon, Jul 27, 2015 at 09:15:32PM -0700, Hanno Böck wrote: > On Mon, 27 Jul 2015 09:59:45 +0100 > Chris Wilson wrote: > > > The tables aren't sorted, that is worth fixing. > > Attached patch should do that and fix the loop. Now it boots without > errors. > > Does that look okay? If so please apply. Indeed, nice catch. Could you please read Documentation/SubmittingPatches and apply your Signed-off-by and then we can accept this patch under your authorship. Preferrably this is two patches, (a) fix the tables, (b) fix the validator. That way we can delay enabling the validator if we need to fix the tables for others. -Chris -- Chris Wilson, Intel Open Source Technology Centre ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 05/18] drm/i915/gen9: csr_init after runtime pm enable
On Sun, Jul 26, 2015 at 12:30:26AM +0530, Animesh Manna wrote:
> As skl is fully dependent on dmc to go to low power state (dc5/dc6)
> which requires a trigger from rpm and to ensure the dmc firmware
> is available for runtime pm support rpm-reference-count is used
> by not releasing the rpm reference acquire when starting the
> firmware loader work.
>
> So moved the intel_csr_ucode_init call after runtime pm enable.
>
> Since have introduced a async work in next patches for loading
> firmware and flush_work() will be used while disabling pw2. So
> there's no need for any additional synchronization between the
> dmc loader and trigger for low power state.
>
> Note that for bxt without dmc, display engine can go to lowest
> possible state (dc9), so releasing the rpm reference.
>
> Cc: Daniel Vetter
> Cc: Damien Lespiau
> Cc: Imre Deak
> Cc: Sunil Kamath
> Signed-off-by: Animesh Manna
> ---
> drivers/gpu/drm/i915/i915_dma.c | 6 +++---
> drivers/gpu/drm/i915/intel_csr.c| 11 ++-
> drivers/gpu/drm/i915/intel_runtime_pm.c | 17 +++--
> 3 files changed, 12 insertions(+), 22 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_dma.c b/drivers/gpu/drm/i915/i915_dma.c
> index b1f9e55..cdd3fbd 100644
> --- a/drivers/gpu/drm/i915/i915_dma.c
> +++ b/drivers/gpu/drm/i915/i915_dma.c
> @@ -877,9 +877,6 @@ int i915_driver_load(struct drm_device *dev, unsigned
> long flags)
>
> intel_uncore_init(dev);
>
> - /* Load CSR Firmware for SKL */
> - intel_csr_ucode_init(dev);
> -
> ret = i915_gem_gtt_init(dev);
> if (ret)
> goto out_freecsr;
> @@ -1025,6 +1022,9 @@ int i915_driver_load(struct drm_device *dev, unsigned
> long flags)
>
> intel_runtime_pm_enable(dev_priv);
>
> + /* Load CSR Firmware for SKL */
> + intel_csr_ucode_init(dev);
> +
> i915_audio_component_init(dev_priv);
>
> return 0;
> diff --git a/drivers/gpu/drm/i915/intel_csr.c
> b/drivers/gpu/drm/i915/intel_csr.c
> index f440299..e759190 100644
> --- a/drivers/gpu/drm/i915/intel_csr.c
> +++ b/drivers/gpu/drm/i915/intel_csr.c
> @@ -404,10 +404,13 @@ static void finish_csr_load(const struct firmware *fw,
> void *context)
>
> DRM_DEBUG_KMS("Finished loading %s\n", dev_priv->csr.fw_path);
> out:
> - if (fw_loaded)
> + if (fw_loaded || IS_BROXTON(dev))
Imo the IS_BXT should be separate patch.
> intel_runtime_pm_put(dev_priv);
> - else
> - intel_csr_load_status_set(dev_priv, FW_FAILED);
> +
> + /*
> + * We require the dmc firmware for runtime pm on skl - leak the rpm
> + * reference in case this failed to disable rpm on.
> + */
Looks like part of my "drm/i915: Only allow rpm on gen9+ with dmc loaded"
patch snuck in here, should be split out again.
-Daniel
>
> release_firmware(fw);
> }
> @@ -477,8 +480,6 @@ void intel_csr_ucode_fini(struct drm_device *dev)
>
> void assert_csr_loaded(struct drm_i915_private *dev_priv)
> {
> - WARN(intel_csr_load_status_get(dev_priv) != FW_LOADED,
> - "CSR is not loaded.\n");
> WARN(!I915_READ(CSR_PROGRAM_BASE),
> "CSR program storage start is NULL\n");
> WARN(!I915_READ(CSR_SSP_BASE), "CSR SSP Base Not fine\n");
> diff --git a/drivers/gpu/drm/i915/intel_runtime_pm.c
> b/drivers/gpu/drm/i915/intel_runtime_pm.c
> index e6156d5..a9bb299 100644
> --- a/drivers/gpu/drm/i915/intel_runtime_pm.c
> +++ b/drivers/gpu/drm/i915/intel_runtime_pm.c
> @@ -644,21 +644,10 @@ static void skl_set_power_well(struct drm_i915_private
> *dev_priv,
>
> if ((GEN9_ENABLE_DC5(dev) || SKL_ENABLE_DC6(dev)) &&
> power_well->data == SKL_DISP_PW_2) {
> - enum csr_state state;
> - /* TODO: wait for a completion event or
> - * similar here instead of busy
> - * waiting using wait_for function.
> - */
> - wait_for((state =
> intel_csr_load_status_get(dev_priv)) !=
> - FW_UNINITIALIZED, 1000);
> - if (state != FW_LOADED)
> - DRM_ERROR("CSR firmware not ready
> (%d)\n",
> - state);
> + if (SKL_ENABLE_DC6(dev))
> + skl_enable_dc6(dev_priv);
> else
> - if (SKL_ENABLE_DC6(dev))
> - skl_enable_dc6(dev_priv);
> - else
> - gen9_enable_dc5(dev_priv);
> + gen9_enable_dc5(dev_priv);
> }
> }
> }
> --
> 2.0.2
>
>
Re: [Intel-gfx] [PATCH 04/18] drm/i915/gen9: block disable call for pw1 if dmc firmware is present.
On Mon, Jul 27, 2015 at 10:48:16AM +0200, Daniel Vetter wrote: > On Sun, Jul 26, 2015 at 12:30:25AM +0530, Animesh Manna wrote: > > Grabbing a runtime pm reference with intel_runtime_pm_get will only > > prevent device D3. But dmc firmware is required even earlier (namely > > for the skl power well 1). DMC is responsible to save the status of > > power well 1 and shut off the power well when panel is self refresh > > mode of display is completely off. > > > > Another interesting criteria to work dmc as expected is pw1 to be > > enabled by driver and dmc will shut it off in its execution > > sequence. If already disabled by driver dmc will get confuse and > > behave differently than expected found during pc10 entry issue > > for skl. > > > > So berfore we disable power-well 1, added check if dmc firmware is > > present and driver will not disable power well 1, but for any reason > > if firmware is not present of failed to load we can shut off the > > power well 1 which will save some power. > > > > As skl is currently fully dependent on dmc to go in lowest possible > > power state (dc6) but the same is not applicable for bxt. Display > > engine can enter into dc9 without dmc, hence unblocking disable call. > > > > Cc: Daniel Vetter > > Cc: Damien Lespiau > > Cc: Imre Deak > > Cc: Sunil Kamath > > Signed-off-by: Animesh Manna > > Signed-off-by: Vathsala Nagaraju > > Please use the approach I've laid out in my original patch series with > "drm/i915: use correct power domain for csr loading" and "drm/i915: Only > allow rpm on gen9+ with dmc loaded". Your approach here requires a > flush_work in the runtime pm callbacks which can deadlock. > > If you want to make dmc optional on bxt then you need to adjust the 2nd > patch a bit to no longer leak the runtime pm reference. Your approach here > is an inversion of control and that doesn't work well since control > inversions very easily lead to locking inversions. Summary of what we just discussed offline: Ok I was confused here with the intel_csr_load_status_get() check. If we apply the above to patch from me first then we don't need that check any more, and the patch itself looks good as a bugfix for skl dmc firmware assumptions. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2 01/12] drm/i915: Make the force_thru workaround atomic.
Op 27-07-15 om 16:04 schreef Daniel Vetter: > On Mon, Jul 27, 2015 at 02:35:30PM +0200, Maarten Lankhorst wrote: >> Set active_changed to force a modeset if the panel fitter's force >> enabled. >> >> Signed-off-by: Maarten Lankhorst > Hm, shouldn't our fancy fastset logic be able to detect that we've changed > pfit change here and force a full modeset? Or am I blind again? > > Abusing active_changed for this feels a bit tricksy tbh, can't we use > mode_changed for this? mode_changed is kinda for "crtc configuration that > needs a full modeset changed", not just for modes. active_changed is > "enable/disable it, but strictly speaking no need to recompute stuff". > > At least that's how the atomic helpers treat it. > I think for !PIPE_A it's ok, but pipe_a + edp can use a different power well iirc. I wasn't sure how that was treated so I went for active_changed instead of mode_changed. ~Maarten ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 14/18] drm/i915/gen9: Use flush_work to synchronize with dmc loader
On Sun, Jul 26, 2015 at 12:30:35AM +0530, Animesh Manna wrote:
> As power well 1 is superset of power well 2 and always pw2
> will be disabled first and then pw1. On the other hand dmc
> is responsible to save & restore back pw1 when display
> engine goes and come back from low power state. Before
> disabling pw1 dmc must be loaded, so adding flush_work()
> while disabling pw2 which ensure that firmware will be
> available before disabling pw1 in suspend flow.
>
> Cc: Daniel Vetter
> Cc: Damien Lespiau
> Cc: Imre Deak
> Cc: Sunil Kamath
> Signed-off-by: Animesh Manna
> ---
> drivers/gpu/drm/i915/i915_drv.c | 2 --
> drivers/gpu/drm/i915/intel_csr.c| 2 ++
> drivers/gpu/drm/i915/intel_runtime_pm.c | 1 +
> 3 files changed, 3 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
> index 98343eb..ddf8a25 100644
> --- a/drivers/gpu/drm/i915/i915_drv.c
> +++ b/drivers/gpu/drm/i915/i915_drv.c
> @@ -995,8 +995,6 @@ static int i915_pm_resume(struct device *dev)
>
> static int skl_suspend_complete(struct drm_i915_private *dev_priv)
> {
> - /* Enabling DC6 is not a hard requirement to enter runtime D3 */
Don't we need a flush_work here to make sure dmc is ready before going
into suspend?
> -
> skl_uninit_cdclk(dev_priv);
>
> return 0;
> diff --git a/drivers/gpu/drm/i915/intel_csr.c
> b/drivers/gpu/drm/i915/intel_csr.c
> index 36386324..1858f02 100644
> --- a/drivers/gpu/drm/i915/intel_csr.c
> +++ b/drivers/gpu/drm/i915/intel_csr.c
> @@ -417,5 +417,7 @@ void intel_csr_ucode_fini(struct drm_i915_private
> *dev_priv)
> if (!HAS_CSR(dev_priv))
> return;
>
> + flush_work(&dev_priv->csr.work);
> +
> kfree(dev_priv->csr.dmc_payload);
> }
> diff --git a/drivers/gpu/drm/i915/intel_runtime_pm.c
> b/drivers/gpu/drm/i915/intel_runtime_pm.c
> index 5f1ae23..a5059e8 100644
> --- a/drivers/gpu/drm/i915/intel_runtime_pm.c
> +++ b/drivers/gpu/drm/i915/intel_runtime_pm.c
> @@ -652,6 +652,7 @@ static void skl_set_power_well(struct drm_i915_private
> *dev_priv,
>
> if ((GEN9_ENABLE_DC5(dev) || SKL_ENABLE_DC6(dev)) &&
> power_well->data == SKL_DISP_PW_2) {
> + flush_work(&dev_priv->csr.work);
This flush_work here has two problems:
- It's an inversion of control since this is low-level code blocking on
high-level. I think this is here is safe but in general it's very easy
to create deadlocks and hence this pattern is discouraged.
- dmc loading might take a while (especially on cros/android where i915 is
built-in but fw needs to wait for the full system before it can be
loaded). We do it asynchronously so that i915 init can proceed and we
can enable outputs really early, but the modeset code also does power
well get/put calls and might end up in here, resulting in a stall.
If we instead prevent execution of this low-level power-well code by
grabbing a power_domain reference then both problems are solved:
- No flush_work needed since we'll only get into this code when the last
power domain references is dropped, which necessarily means dmc loader
has completed.
- No blocking of modesets while dmc loading is still in progress since the
get/put power_domain calls will simply be no-ops too.
Long story short: If you apply the two patches I mentioned in my reply to
patch 4 there shouldn't be a need for this flush_work here in
skl_set_power_well.
Thanks, Daniel
> if (SKL_ENABLE_DC6(dev))
> skl_enable_dc6(dev_priv);
> else
> --
> 2.0.2
>
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 18/18] drm/i915/gen9: Removed byte swapping for csr firmware.
Signed-off-by: Vatsala Nagaraju
It's Vathsala Nagaraju
Commit message: Removed byte swapping for csr firmware.
Commit message does not convey as to why the change was made. "This change is
needed as DMC firmware loading failed on skylake due byte swap done in the
driver"
-Original Message-
From: Intel-gfx [mailto:intel-gfx-boun...@lists.freedesktop.org] On Behalf Of
Animesh Manna
Sent: Sunday, July 26, 2015 12:31 AM
To: intel-gfx@lists.freedesktop.org
Cc: Vatsala Nagaraju
Subject: [Intel-gfx] [PATCH 18/18] drm/i915/gen9: Removed byte swapping for csr
firmware.
Cc: Damien Lespiau
Cc: Imre Deak
Cc: Sunil Kamath
Signed-off-by: Animesh Manna
Signed-off-by: Vatsala Nagaraju
---
drivers/gpu/drm/i915/intel_csr.c | 11 +--
1 file changed, 1 insertion(+), 10 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_csr.c b/drivers/gpu/drm/i915/intel_csr.c
index 1858f02..50779e0 100644
--- a/drivers/gpu/drm/i915/intel_csr.c
+++ b/drivers/gpu/drm/i915/intel_csr.c
@@ -328,16 +328,7 @@ static uint32_t *parse_csr_fw(struct drm_i915_private
*dev_priv,
return NULL;
}
- for (i = 0; i < dmc_header->fw_size; i++) {
- uint32_t *tmp = (u32 *)&fw->data[readcount + i * 4];
- /*
-* The firmware payload is an array of 32 bit words stored in
-* little-endian format in the firmware image and programmed
-* as 32 bit big-endian format to memory.
-*/
- dmc_payload[i] = (uint32_t __force) cpu_to_be32(*tmp);
- }
-
+ memcpy(dmc_payload, &fw->data[readcount], dmc_header->fw_size);
return dmc_payload;
}
--
2.0.2
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] Error in inner loop in validate_cmds_sorted / out of bounds issue
On Tue, Jul 28, 2015 at 08:45:51AM +0100, Chris Wilson wrote: > On Mon, Jul 27, 2015 at 09:15:32PM -0700, Hanno Böck wrote: > > On Mon, 27 Jul 2015 09:59:45 +0100 > > Chris Wilson wrote: > > > > > The tables aren't sorted, that is worth fixing. > > > > Attached patch should do that and fix the loop. Now it boots without > > errors. > > > > Does that look okay? If so please apply. > > Indeed, nice catch. Could you please read > Documentation/SubmittingPatches and apply your Signed-off-by and then we > can accept this patch under your authorship. > > Preferrably this is two patches, (a) fix the tables, (b) fix the > validator. That way we can delay enabling the validator if we need to > fix the tables for others. Also can you please add signed-off-by lines to your patch when resubmitting? See Documentation/SubmittingPatches for all the details. Thanks, Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: VLV/CHV PSR: Increase wait delay time before active PSR.
On Mon, Jul 27, 2015 at 06:37:28PM +, Vivi, Rodrigo wrote: > On Mon, 2015-07-27 at 10:36 +0200, Daniel Vetter wrote: > > On Fri, Jul 24, 2015 at 04:42:27PM -0700, Rodrigo Vivi wrote: > > > Since active function on VLV immediately activate PSR let's give more > > > time for idleness. Different from core platforms where we have idle_frames > > > count. > > > > > > Also kms_psr_sink_crc now is automated and always get this: > > > > > > [drm:intel_enable_pipe] enabling pipe A > > > [drm:intel_edp_backlight_on] > > > [drm:intel_panel_enable_backlight] pipe > > > [drm:intel_panel_enable_backlight] pipe A > > > [drm:intel_panel_actually_set_backlight] set backlight PWM = 7812 > > > > > > PSR gets enabled somewhere here after backlight. > > > > > > [drm:intel_get_hpd_pins] hotplug event received, stat 0x, dig 0x0 > > > [drm:vlv_pipe_set_fifo_size] Pipe A FIFO split 511 / 511 / 511 > > > [drm:vlv_update_wm] Setting FIFO watermarks - A: plane=391, cursor=63, sp > > > > > > PSR gets flushed around here by intel_atomic_commit > > > > > > [drm:vlv_pipe_set_fifo_size] Pipe A FIFO split 511 / 511 / 511 > > > [drm:vlv_update_wm] Setting FIFO watermarks - A: plane=391, cursor=63, sp > > > [drm:intel_set_memory_cxsr] memory self-refresh is enabled > > > [drm:intel_connector_check_state] [CONNECTOR:39:eDP-1] > > > [drm:check_encoder_state] [ENCODER:30:DAC-30] > > > [drm:check_encoder_state] [ENCODER:31:TMDS-31] > > > [drm:check_encoder_state] [ENCODER:36:TMDS-36] > > > [drm:check_encoder_state] [ENCODER:38:TMDS-38] > > > [drm:check_crtc_state] [CRTC:21] > > > [drm:check_crtc_state] [CRTC:26] > > > [drm:intel_psr_activate [i915]] *ERROR* PSR Active > > > [drm:intel_get_hpd_pins] hotplug event received, stat 0x, dig 0x > > > [drm:intel_set_cpu_fifo_underrun_reporting [i915]] *ERROR* pipe A underrun > > > [drm:intel_cpu_fifo_underrun_irq_handler [i915]] *ERROR* CPU pipe A FIFO > > > Underrun. > > > > > > It is true that in a product we won't keep disabling and enabling planes > > > so > > > frequently, but for safeness let's stay conservative. > > > > > > It is also true that 500ms is an etternity. But PSR is anyway a power > > > saving > > > feature for idle scenario. So if it is idle feature stays on and 500ms to > > > get > > > it reanabled is not that insane. > > > > > > v2: Rebase over intel_psr.c and fix typo. > > > v3: Revival: Manual tests indicated that this is needed. With a short > > > delay > > > there is a huge risk of getting blank screens when planes are being > > > enabled. > > > v4: Revival 2 with reasonable delay. 1/2 sec instead of 5. VBT is 10 sec > > > but > > > actually time for link training what we aren't doing, but with only > > > 100 sec > > > in some cases kms_psr_sink_crc manual was showing blank screen, > > > so let's use this for now. Also changed comment by a FIXME. > > > v5: Rebase after a long time, remove FIXME and update comment above. > > > v6: msecs_to_jiffies is already on delay. remove duplication. > > > > > > Reviewed-by: Durgadoss R (v4) > > > Signed-off-by: Rodrigo Vivi > > > --- > > > drivers/gpu/drm/i915/intel_psr.c | 4 ++-- > > > 1 file changed, 2 insertions(+), 2 deletions(-) > > > > > > diff --git a/drivers/gpu/drm/i915/intel_psr.c > > > b/drivers/gpu/drm/i915/intel_psr.c > > > index acd8ec8..bec13b8 100644 > > > --- a/drivers/gpu/drm/i915/intel_psr.c > > > +++ b/drivers/gpu/drm/i915/intel_psr.c > > > @@ -698,6 +698,7 @@ void intel_psr_flush(struct drm_device *dev, > > > struct drm_i915_private *dev_priv = dev->dev_private; > > > struct drm_crtc *crtc; > > > enum pipe pipe; > > > + int delay = msecs_to_jiffies(HAS_DDI(dev) ? 100 : 500); > > > > Note that for a timeout you should be using our own > > msecs_to_jiffies_timeout if it's for a timeout. This is needed since you > > can't know when the next jiffy update happens and that might be right > > away, therefore waiting for 10 jiffies might only be a wait for 9/HZ. > > Anyway tiny nitpick. > > This is actually only used on schedule_delayed_work that receives the > numer of jiffies to wait. > I believe to avoid confusion I should let the msecs_to_jiffies on > schedule_delayed_work only and delay in ms. Do you want another v++? If you feel like, was kinda just an aside bikeshed really. I'm just constantly confused about jiffies timeouts myself ;-) -Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2 01/12] drm/i915: Make the force_thru workaround atomic.
On Tue, Jul 28, 2015 at 09:57:37AM +0200, Maarten Lankhorst wrote: > Op 27-07-15 om 16:04 schreef Daniel Vetter: > > On Mon, Jul 27, 2015 at 02:35:30PM +0200, Maarten Lankhorst wrote: > >> Set active_changed to force a modeset if the panel fitter's force > >> enabled. > >> > >> Signed-off-by: Maarten Lankhorst > > Hm, shouldn't our fancy fastset logic be able to detect that we've changed > > pfit change here and force a full modeset? Or am I blind again? > > > > Abusing active_changed for this feels a bit tricksy tbh, can't we use > > mode_changed for this? mode_changed is kinda for "crtc configuration that > > needs a full modeset changed", not just for modes. active_changed is > > "enable/disable it, but strictly speaking no need to recompute stuff". > > > > At least that's how the atomic helpers treat it. > > > I think for !PIPE_A it's ok, but pipe_a + edp can use a different power well > iirc. > I wasn't sure how that was treated so I went for active_changed instead of > mode_changed. Following up from our irc discussion: mode_changed is indeed not a good idea since with the fastset tricks we might accidentally ellide the modeset if intel_pipe_config_compare doesn't catch it (and right now it won't). But I still think active_changed is abuse since active_changed should _not_ result in state recomputation really, the entire point of crtc_state->active is that you can always flip it and it will never fail due to lack of resources. But with your latest patches we have connector_changed to track routing changes, and force_thru is very much a routing change. I think using that would be best. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2 12/12] drm/i915: Handle return value in intel_pin_and_fence_fb_obj, v2.
Tested-By: Intel Graphics QA PRTS (Patch Regression Test System Contact: shuang...@intel.com) Task id: 6874 -Summary- Platform Delta drm-intel-nightly Series Applied ILK 297/297 297/297 SNB 315/315 315/315 IVB 342/342 342/342 BYT 284/284 284/284 HSW 378/378 378/378 -Detailed- Platform Testdrm-intel-nightly Series Applied Note: You need to pay more attention to line start with '*' ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915/bxt: WA for swapped HPD pins in A stepping
Tested-By: Intel Graphics QA PRTS (Patch Regression Test System Contact: shuang...@intel.com) Task id: 6870 -Summary- Platform Delta drm-intel-nightly Series Applied ILK -1 296/296 295/296 SNB -1 316/316 315/316 IVB -1 343/343 342/343 BYT -3 286/286 283/286 HSW -1 379/379 378/379 -Detailed- Platform Testdrm-intel-nightly Series Applied *ILK igt@gem_reg_read PASS(1) NRUN(1) *SNB igt@gem_reg_read PASS(1) INIT(1) *IVB igt@gem_reg_read PASS(1) NRUN(1) *BYT igt@drm_read@short-buffer-block PASS(1) FAIL(1) *BYT igt@gem_partial_pwrite_pread@reads-uncached PASS(1) FAIL(1) *BYT igt@gem_reg_read PASS(1) INIT(1) *HSW igt@gem_reg_read PASS(1) INIT(1) Note: You need to pay more attention to line start with '*' ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Fake AGP is dead
Tested-By: Intel Graphics QA PRTS (Patch Regression Test System Contact: shuang...@intel.com) Task id: 6873 -Summary- Platform Delta drm-intel-nightly Series Applied ILK 297/297 297/297 SNB 315/315 315/315 IVB 342/342 342/342 BYT -1 284/284 283/284 HSW 378/378 378/378 -Detailed- Platform Testdrm-intel-nightly Series Applied *BYT igt@gem_partial_pwrite_pread@reads PASS(1) FAIL(1) Note: You need to pay more attention to line start with '*' ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 2/2] drm/i915: Switch a couple of BUG_ONs in the cmdparser over to DRM_ERROR
Tested-By: Intel Graphics QA PRTS (Patch Regression Test System Contact: shuang...@intel.com) Task id: 6871 -Summary- Platform Delta drm-intel-nightly Series Applied ILK 297/297 297/297 SNB 315/315 315/315 IVB 342/342 342/342 BYT 284/284 284/284 HSW 378/378 378/378 -Detailed- Platform Testdrm-intel-nightly Series Applied Note: You need to pay more attention to line start with '*' ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PULL] topic/drm-misc
Hi Dave, More drm-misc, mostly fine-tuning of atomic helpers. They're mostly driver-wide interface changes of the helpers and I need them for i915 work, so I plan to pull this tag into drm-intel-next too. Cheers, Daniel The following changes since commit dcd14dd957f02ef679c61325a2221a0574bdcab3: Merge tag 'topic/connector-locking-2015-07-23' of git://anongit.freedesktop.org/drm-intel into drm-next (2015-07-24 14:30:29 +1000) are available in the git repository at: git://anongit.freedesktop.org/drm-intel tags/topic/drm-misc-2015-07-28 for you to fetch changes up to 8c10342cb48f3140d9abeadcfd2fa6625d447282: drm/atomic: Update legacy DPMS state during modesets, v3. (2015-07-27 16:23:29 +0200) Maarten Lankhorst (4): drm/atomic: add connectors_changed to separate it from mode_changed, v2 drm/atomic: pass old crtc state to atomic_begin/flush. drm: Make the connector dpms callback return a value, v2. drm/atomic: Update legacy DPMS state during modesets, v3. Rodrigo Vivi (1): drm: Fix DP_TEST_COUNT_MASK drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c | 6 +- drivers/gpu/drm/drm_atomic_helper.c| 101 + drivers/gpu/drm/drm_crtc.c | 4 +- drivers/gpu/drm/drm_crtc_helper.c | 9 ++- drivers/gpu/drm/drm_plane_helper.c | 4 +- drivers/gpu/drm/exynos/exynos_drm_crtc.c | 6 +- drivers/gpu/drm/i915/intel_crt.c | 8 +- drivers/gpu/drm/i915/intel_display.c | 27 +++ drivers/gpu/drm/i915/intel_drv.h | 2 +- drivers/gpu/drm/i915/intel_dvo.c | 8 +- drivers/gpu/drm/i915/intel_sdvo.c | 8 +- drivers/gpu/drm/msm/mdp/mdp4/mdp4_crtc.c | 6 +- drivers/gpu/drm/msm/mdp/mdp5/mdp5_crtc.c | 6 +- drivers/gpu/drm/nouveau/nouveau_connector.c| 4 +- drivers/gpu/drm/radeon/radeon_dp_mst.c | 3 +- drivers/gpu/drm/rcar-du/rcar_du_crtc.c | 6 +- drivers/gpu/drm/sti/sti_drm_crtc.c | 6 +- drivers/gpu/drm/tegra/dc.c | 6 +- drivers/gpu/drm/tegra/dsi.c| 3 +- drivers/gpu/drm/tegra/hdmi.c | 5 +- drivers/gpu/drm/tegra/rgb.c| 5 +- drivers/gpu/drm/tegra/sor.c| 3 +- drivers/gpu/drm/vmwgfx/vmwgfx_kms.c| 3 +- drivers/gpu/drm/vmwgfx/vmwgfx_kms.h| 2 +- include/drm/drm_atomic.h | 3 +- include/drm/drm_atomic_helper.h| 4 +- include/drm/drm_crtc.h | 10 ++- include/drm/drm_crtc_helper.h | 8 +- include/drm/drm_dp_helper.h| 2 +- 29 files changed, 169 insertions(+), 99 deletions(-) -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2.1 01/12] drm/i915: Make the force_thru workaround atomic, v2.
Set connectors_changed to force a modeset if the panel fitter's force
enabled on eDP.
Changes since v1:
- Use connectors_changed instead of active_changed because it's a
routing update.
Signed-off-by: Maarten Lankhorst
---
diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
b/drivers/gpu/drm/i915/i915_debugfs.c
index 23a69307e12e..d1c643a82267 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -3645,74 +3645,40 @@ static int ilk_pipe_crc_ctl_reg(enum
intel_pipe_crc_source *source,
return 0;
}
-static void hsw_trans_edp_pipe_A_crc_wa(struct drm_device *dev)
+static void hsw_trans_edp_pipe_A_crc_wa(struct drm_device *dev, bool enable)
{
struct drm_i915_private *dev_priv = dev->dev_private;
struct intel_crtc *crtc =
to_intel_crtc(dev_priv->pipe_to_crtc_mapping[PIPE_A]);
struct intel_crtc_state *pipe_config;
+ struct drm_atomic_state *state;
+ int ret = 0;
drm_modeset_lock_all(dev);
- pipe_config = to_intel_crtc_state(crtc->base.state);
-
- /*
-* If we use the eDP transcoder we need to make sure that we don't
-* bypass the pfit, since otherwise the pipe CRC source won't work. Only
-* relevant on hsw with pipe A when using the always-on power well
-* routing.
-*/
- if (pipe_config->cpu_transcoder == TRANSCODER_EDP &&
- !pipe_config->pch_pfit.enabled) {
- bool active = pipe_config->base.active;
-
- if (active) {
- intel_crtc_control(&crtc->base, false);
- pipe_config = to_intel_crtc_state(crtc->base.state);
- }
-
- pipe_config->pch_pfit.force_thru = true;
-
- intel_display_power_get(dev_priv,
- POWER_DOMAIN_PIPE_PANEL_FITTER(PIPE_A));
-
- if (active)
- intel_crtc_control(&crtc->base, true);
+ state = drm_atomic_state_alloc(dev);
+ if (!state) {
+ ret = -ENOMEM;
+ goto out;
}
- drm_modeset_unlock_all(dev);
-}
-static void hsw_undo_trans_edp_pipe_A_crc_wa(struct drm_device *dev)
-{
- struct drm_i915_private *dev_priv = dev->dev_private;
- struct intel_crtc *crtc =
- to_intel_crtc(dev_priv->pipe_to_crtc_mapping[PIPE_A]);
- struct intel_crtc_state *pipe_config;
-
- drm_modeset_lock_all(dev);
- /*
-* If we use the eDP transcoder we need to make sure that we don't
-* bypass the pfit, since otherwise the pipe CRC source won't work. Only
-* relevant on hsw with pipe A when using the always-on power well
-* routing.
-*/
- pipe_config = to_intel_crtc_state(crtc->base.state);
- if (pipe_config->pch_pfit.force_thru) {
- bool active = pipe_config->base.active;
-
- if (active) {
- intel_crtc_control(&crtc->base, false);
- pipe_config = to_intel_crtc_state(crtc->base.state);
- }
-
- pipe_config->pch_pfit.force_thru = false;
+ state->acquire_ctx = drm_modeset_legacy_acquire_ctx(&crtc->base);
+ pipe_config = intel_atomic_get_crtc_state(state, crtc);
+ if (IS_ERR(pipe_config)) {
+ ret = PTR_ERR(pipe_config);
+ goto out;
+ }
- intel_display_power_put(dev_priv,
- POWER_DOMAIN_PIPE_PANEL_FITTER(PIPE_A));
+ pipe_config->pch_pfit.force_thru = enable;
+ if (pipe_config->cpu_transcoder == TRANSCODER_EDP &&
+ pipe_config->pch_pfit.enabled != enable)
+ pipe_config->base.connectors_changed = true;
- if (active)
- intel_crtc_control(&crtc->base, true);
- }
+ ret = drm_atomic_commit(state);
+out:
drm_modeset_unlock_all(dev);
+ WARN(ret, "Toggling workaround to %i returns %i\n", enable, ret);
+ if (ret)
+ drm_atomic_state_free(state);
}
static int ivb_pipe_crc_ctl_reg(struct drm_device *dev,
@@ -3732,7 +3698,7 @@ static int ivb_pipe_crc_ctl_reg(struct drm_device *dev,
break;
case INTEL_PIPE_CRC_SOURCE_PF:
if (IS_HASWELL(dev) && pipe == PIPE_A)
- hsw_trans_edp_pipe_A_crc_wa(dev);
+ hsw_trans_edp_pipe_A_crc_wa(dev, true);
*val = PIPE_CRC_ENABLE | PIPE_CRC_SOURCE_PF_IVB;
break;
@@ -3844,7 +3810,7 @@ static int pipe_crc_set_source(struct drm_device *dev,
enum pipe pipe,
else if (IS_VALLEYVIEW(dev))
vlv_undo_pipe_scramble_reset(dev, pipe);
else if (IS_HASWELL(dev) && pipe == PIPE_A)
- hsw_undo_trans_edp_pipe_A_crc_wa(dev);
+ hsw_trans_edp_pipe_A_crc_wa(dev, false);
hsw_ena
[Intel-gfx] [MIPI SEQ PARSING v1 PATCH 2/9] drm/i915: Parsing VBT if size of VBT exceeds 6KB
Currently the iomap for VBT works only if the size of the
VBT is less than 6KB, but if the size of the VBT exceeds
6KB than the physical address and the size of the VBT to
be iomapped is specified in the mailbox3 and is iomapped
accordingly.
Signed-off-by: Deepak M
---
drivers/gpu/drm/i915/intel_bios.c | 13 +++
drivers/gpu/drm/i915/intel_opregion.c | 39 ++---
2 files changed, 45 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_bios.c
b/drivers/gpu/drm/i915/intel_bios.c
index 2583587..1b9164e 100644
--- a/drivers/gpu/drm/i915/intel_bios.c
+++ b/drivers/gpu/drm/i915/intel_bios.c
@@ -1219,6 +1219,7 @@ intel_parse_bios(struct drm_device *dev)
struct drm_i915_private *dev_priv = dev->dev_private;
struct pci_dev *pdev = dev->pdev;
const struct bdb_header *bdb = NULL;
+ const struct vbt_header *vbt = NULL;
u8 __iomem *bios = NULL;
if (HAS_PCH_NOP(dev))
@@ -1226,10 +1227,14 @@ intel_parse_bios(struct drm_device *dev)
init_vbt_defaults(dev_priv);
- /* XXX Should this validation be moved to intel_opregion.c? */
- if (!dmi_check_system(intel_no_opregion_vbt) && dev_priv->opregion.vbt)
- bdb = validate_vbt(dev_priv->opregion.header, OPREGION_SIZE,
- dev_priv->opregion.vbt, "OpRegion");
+ if (!dmi_check_system(intel_no_opregion_vbt) &&
+ dev_priv->opregion.vbt) {
+ vbt = (struct vbt_header *)dev_priv->opregion.vbt;
+ bdb = (struct bdb_header *)(dev_priv->opregion.vbt +
+ vbt->bdb_offset);
+ DRM_DEBUG_KMS("Using VBT from Opregion: %20s\n",
+ vbt->signature);
+ }
if (bdb == NULL) {
size_t size;
diff --git a/drivers/gpu/drm/i915/intel_opregion.c
b/drivers/gpu/drm/i915/intel_opregion.c
index 71e87ab..1372e39 100644
--- a/drivers/gpu/drm/i915/intel_opregion.c
+++ b/drivers/gpu/drm/i915/intel_opregion.c
@@ -50,6 +50,7 @@
#define OPREGION_VBT_OFFSET0x400
#define OPREGION_SIGNATURE "IntelGraphicsMem"
+#define VBT_SIGNATURE "$VBT"
#define MBOX_ACPI (1<<0)
#define MBOX_SWSCI (1<<1)
#define MBOX_ASLE (1<<2)
@@ -113,7 +114,12 @@ struct opregion_asle {
u32 pcft; /* power conservation features */
u32 srot; /* supported rotation angles */
u32 iuer; /* IUER events */
- u8 rsvd[86];
+ u64 fdss; /* DSS Buffer address allocated for IFFS feature */
+ u32 fdsp; /* Size of DSS Buffer */
+ u32 stat; /* State Indicator */
+ u64 rvda; /* Physical address of raw vbt data */
+ u32 rvds; /* Size of raw vbt data */
+ u8 rsvd[58];
} __packed;
/* Driver readiness indicator */
@@ -858,8 +864,10 @@ int intel_opregion_setup(struct drm_device *dev)
struct drm_i915_private *dev_priv = dev->dev_private;
struct intel_opregion *opregion = &dev_priv->opregion;
void __iomem *base;
+ void __iomem *vbt_base;
u32 asls, mboxes;
char buf[sizeof(OPREGION_SIGNATURE)];
+ char vbt_sig_buf[sizeof(VBT_SIGNATURE)];
int err = 0;
pci_read_config_dword(dev->pdev, PCI_ASLS, &asls);
@@ -873,7 +881,7 @@ int intel_opregion_setup(struct drm_device *dev)
INIT_WORK(&opregion->asle_work, asle_work);
#endif
- base = acpi_os_ioremap(asls, OPREGION_SIZE);
+ base = acpi_os_ioremap(asls, OPREGION_VBT_OFFSET);
if (!base)
return -ENOMEM;
@@ -884,8 +892,31 @@ int intel_opregion_setup(struct drm_device *dev)
err = -EINVAL;
goto err_out;
}
+
opregion->header = base;
- opregion->vbt = base + OPREGION_VBT_OFFSET;
+ opregion->asle = base + OPREGION_ASLE_OFFSET;
+
+ if (opregion->header->opregion_ver >= 2) {
+ if (opregion->asle->rvda)
+ vbt_base = acpi_os_ioremap(opregion->asle->rvda,
+ opregion->asle->rvds);
+ else
+ vbt_base = acpi_os_ioremap(asls + OPREGION_VBT_OFFSET,
+ OPREGION_SIZE - OPREGION_VBT_OFFSET);
+ } else
+ vbt_base = acpi_os_ioremap(asls + OPREGION_VBT_OFFSET,
+ OPREGION_SIZE - OPREGION_VBT_OFFSET);
+
+
+ memcpy_fromio(vbt_sig_buf, vbt_base, sizeof(vbt_sig_buf));
+
+ if (memcmp(vbt_sig_buf, VBT_SIGNATURE, 4)) {
+ DRM_ERROR("VBT signature mismatch\n");
+ err = -EINVAL;
+ goto err_vbt;
+ }
+
+ opregion->vbt = vbt_base;
opregion->lid_state = base + ACPI_CLID;
@@ -909,6 +940,8 @@ int intel_opregion_setup(struct drm_device *dev)
return 0;
+err_vbt:
+ iounmap(vbt_base);
err_out:
iounmap(base);
[Intel-gfx] [MIPI SEQ PARSING v1 PATCH 6/9] drm/i915: GPIO for CHT generic MIPI
From: Yogesh Mohan Marimuthu
The GPIO configuration and register offsets are different from
baytrail for cherrytrail. Port the gpio programming accordingly
for cherrytrail in this patch.
Signed-off-by: Yogesh Mohan Marimuthu
---
drivers/gpu/drm/i915/i915_reg.h| 23 ++
drivers/gpu/drm/i915/intel_dsi_panel_vbt.c | 116 +++-
2 files changed, 121 insertions(+), 18 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 3efea0e..2d13e34 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -554,11 +554,21 @@
#define IOSF_PORT_DPIO 0x12
#define IOSF_PORT_DPIO_2 0x1a
#define IOSF_PORT_GPIO_NC0x13
+#define CHV_IOSF_PORT_GPIO_N 0x13
#define IOSF_PORT_GPIO_SC0x48
+#define CHV_IOSF_PORT_GPIO_SE0x48
+#define CHV_IOSF_PORT_GPIO_SW0xB2
#define IOSF_PORT_GPIO_SUS 0xA8
+#define CHV_IOSF_PORT_GPIO_E 0xA8
#define MAX_GPIO_NUM_NC 26
#define MAX_GPIO_NUM_SC 128
#define MAX_GPIO_NUM 172
+#define CHV_MAX_GPIO_NUM_N 72
+#define CHV_MAX_GPIO_NUM_SE 99
+#define CHV_MAX_GPIO_NUM_SW 197
+#define CHV_MIN_GPIO_NUM_SE 73
+#define CHV_MIN_GPIO_NUM_SW 100
+#define CHV_MIN_GPIO_NUM_E 198
#define IOSF_PORT_CCK0x14
#define IOSF_PORT_CCU0xA9
#define IOSF_PORT_GPS_CORE 0x48
@@ -566,6 +576,19 @@
#define VLV_IOSF_DATA (VLV_DISPLAY_BASE + 0x2104)
#define VLV_IOSF_ADDR (VLV_DISPLAY_BASE + 0x2108)
+#define VLV_GPIO_CFG 0x2000CC00
+#define VLV_GPIO_INPUT_DIS 0x04
+
+#define CHV_PAD_FMLY_BASE 0x4400
+#define CHV_PAD_FMLY_SIZE 0x400
+#define CHV_PAD_CFG_0_1_REG_SIZE 0x8
+#define CHV_PAD_CFG_REG_SIZE 0x4
+#define CHV_VBT_MAX_PINS_PER_FMLY 15
+
+#define CHV_GPIO_CFG_UNLOCK0x
+#define CHV_GPIO_CFG_HiZ 0x8100
+#define CHV_GPIO_CFG_TX_STATE_SHIFT1
+
/* See configdb bunit SB addr map */
#define BUNIT_REG_BISOC0x11
diff --git a/drivers/gpu/drm/i915/intel_dsi_panel_vbt.c
b/drivers/gpu/drm/i915/intel_dsi_panel_vbt.c
index f2ea875..060305d 100644
--- a/drivers/gpu/drm/i915/intel_dsi_panel_vbt.c
+++ b/drivers/gpu/drm/i915/intel_dsi_panel_vbt.c
@@ -416,17 +416,75 @@ static const u8 *mipi_exec_delay(struct intel_dsi
*intel_dsi, const u8 *data)
return data;
}
-
-static const u8 *mipi_exec_gpio(struct intel_dsi *intel_dsi, const u8 *data)
+static int chv_program_gpio(struct intel_dsi *intel_dsi,
+ const u8 *data, const u8 **cur_data)
{
+ struct drm_device *dev = intel_dsi->base.base.dev;
+ struct drm_i915_private *dev_priv = dev->dev_private;
u8 gpio, action;
+ u16 family_num;
u16 function, pad;
- u32 val;
u8 block;
+
+ /*
+* Skipping the first byte as it is of no
+* interest for linux kernel in new VBT version
+*/
+ if (dev_priv->vbt.dsi.seq_version >= 3)
+ data++;
+
+ gpio = *data++;
+
+ /* pull up/down */
+ action = *data++;
+
+ if (dev_priv->vbt.dsi.seq_version >= 3) {
+ if (gpio <= CHV_MAX_GPIO_NUM_N) {
+ block = CHV_IOSF_PORT_GPIO_N;
+ DRM_DEBUG_DRIVER("GPIO is in the north Block\n");
+ } else if (gpio <= CHV_MAX_GPIO_NUM_SE) {
+ block = CHV_IOSF_PORT_GPIO_SE;
+ gpio = gpio - CHV_MIN_GPIO_NUM_SE;
+ DRM_DEBUG_DRIVER("GPIO is in the south east Block\n");
+ } else if (gpio <= CHV_MAX_GPIO_NUM_SW) {
+ block = CHV_IOSF_PORT_GPIO_SW;
+ gpio = gpio - CHV_MIN_GPIO_NUM_SW;
+ DRM_DEBUG_DRIVER("GPIO is in the south west Block\n");
+ } else {
+ block = CHV_IOSF_PORT_GPIO_E;
+ gpio = gpio - CHV_MIN_GPIO_NUM_E;
+ DRM_DEBUG_DRIVER("GPIO is in the east Block\n");
+ }
+ } else
+ block = IOSF_PORT_GPIO_NC;
+
+ family_num = gpio / CHV_VBT_MAX_PINS_PER_FMLY;
+ gpio = gpio - (family_num * CHV_VBT_MAX_PINS_PER_FMLY);
+ pad = CHV_PAD_FMLY_BASE + (family_num * CHV_PAD_FMLY_SIZE) +
+ (((u16)gpio) * CHV_PAD_CFG_0_1_REG_SIZE);
+ function = pad + CHV_PAD_CFG_REG_SIZE;
+
+
[Intel-gfx] [MIPI SEQ PARSING v1 PATCH 4/9] drm/i915: Added support the v3 mipi sequence block
From: vkorjani
The Block 53 of the VBT, which is the MIPI sequence block
has undergone a design change because of which the parsing
logic has to be changed.
The current code will handle the parsing of v3 and other
lower versions of the MIPI sequence block.
Signed-off-by: vkorjani
Signed-off-by: Deepak M
---
drivers/gpu/drm/i915/intel_bios.c | 119 +++-
drivers/gpu/drm/i915/intel_bios.h |8 ++
drivers/gpu/drm/i915/intel_dsi_panel_vbt.c |7 ++
3 files changed, 114 insertions(+), 20 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_bios.c
b/drivers/gpu/drm/i915/intel_bios.c
index 5e0ff22..858bd02 100644
--- a/drivers/gpu/drm/i915/intel_bios.c
+++ b/drivers/gpu/drm/i915/intel_bios.c
@@ -45,6 +45,7 @@ find_section(struct drm_i915_private *dev_priv,
int index = 0;
u32 total, current_size;
u8 current_id;
+ u8 version;
/* skip to first section */
index += bdb->header_size;
@@ -59,7 +60,17 @@ find_section(struct drm_i915_private *dev_priv,
current_id = *(base + index);
index++;
- current_size = *((const u16 *)(base + index));
+ if (current_id == BDB_MIPI_SEQUENCE) {
+ version = *(base + index + 2);
+ if (version >= 3)
+ current_size = *((const u32 *)(base +
+ index + 3));
+ else
+ current_size = *((const u16 *)(base + index));
+ } else {
+ current_size = *((const u16 *)(base + index));
+ }
+
index += 2;
if (index + current_size > total)
@@ -748,6 +759,55 @@ static u8 *goto_next_sequence(u8 *data, int *size)
return data;
}
+static u8 *goto_next_sequence_v3(u8 *data, int *size)
+{
+ int tmp = *size;
+ int op_size;
+
+ if (--tmp < 0)
+ return NULL;
+
+ /* Skip the panel id and the sequence size */
+ data = data + 5;
+ while (*data != 0) {
+ u8 element_type = *data++;
+
+ switch (element_type) {
+ default:
+ DRM_ERROR("Unknown element type %d\n", element_type);
+ case MIPI_SEQ_ELEM_SEND_PKT:
+ case MIPI_SEQ_ELEM_DELAY:
+ case MIPI_SEQ_ELEM_GPIO:
+ case MIPI_SEQ_ELEM_I2C:
+ case MIPI_SEQ_ELEM_SPI:
+ case MIPI_SEQ_ELEM_PMIC:
+ /*
+* skip by this element payload size
+* skip elem id, command flag and data type
+*/
+ op_size = *data++;
+ tmp = tmp - (op_size + 1);
+ if (tmp < 0)
+ return NULL;
+
+ /* skip by len */
+ data += op_size;
+ break;
+ }
+ }
+
+ /* goto next sequence or end of block byte */
+ if (--tmp < 0)
+ return NULL;
+
+ /* Skip the end element marker */
+ data++;
+
+ /* update amount of data left for the sequence block to be parsed */
+ *size = tmp;
+ return data;
+}
+
static void
parse_mipi(struct drm_i915_private *dev_priv, const struct bdb_header *bdb)
{
@@ -757,7 +817,7 @@ parse_mipi(struct drm_i915_private *dev_priv, const struct
bdb_header *bdb)
const struct mipi_pps_data *pps;
u8 *data;
const u8 *seq_data;
- int i, panel_id, seq_size;
+ int i, panel_id, panel_seq_size;
u16 block_size;
/* parse MIPI blocks only if LFP type is MIPI */
@@ -814,29 +874,40 @@ parse_mipi(struct drm_i915_private *dev_priv, const
struct bdb_header *bdb)
DRM_DEBUG_DRIVER("Found MIPI sequence block\n");
- block_size = get_blocksize(sequence);
-
/*
* parse the sequence block for individual sequences
*/
dev_priv->vbt.dsi.seq_version = sequence->version;
seq_data = &sequence->data[0];
+ if (dev_priv->vbt.dsi.seq_version >= 3) {
+ block_size = *((unsigned int *)seq_data);
+ seq_data = seq_data + 4;
+ } else
+ block_size = get_blocksize(sequence);
/*
* sequence block is variable length and hence we need to parse and
* get the sequence data for specific panel id
*/
for (i = 0; i < MAX_MIPI_CONFIGURATIONS; i++) {
- panel_id = *seq_data;
- seq_size = *((u16 *) (seq_data + 1));
+ panel_id = *seq_data++;
+ if (dev_priv->vbt.dsi.seq_version >= 3) {
+ panel_seq_size = *((u32 *)seq_data);
+ seq_data += sizeof(u32);
+ } else {
+
[Intel-gfx] [MIPI SEQ PARSING v1 PATCH 5/9] drm/i915: Added the generic gpio sequence support and gpio table
The generic gpio is sequence is parsed from the VBT and the GPIO table is updated with the North core, South core and SUS core elements. Signed-off-by: Deepak M --- drivers/gpu/drm/i915/i915_drv.h|5 +- drivers/gpu/drm/i915/i915_reg.h|5 + drivers/gpu/drm/i915/intel_dsi.h | 355 drivers/gpu/drm/i915/intel_dsi_panel_vbt.c | 219 +++-- drivers/gpu/drm/i915/intel_sideband.c |9 +- 5 files changed, 573 insertions(+), 20 deletions(-) diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h index b38f52ee..8cf133e 100644 --- a/drivers/gpu/drm/i915/i915_drv.h +++ b/drivers/gpu/drm/i915/i915_drv.h @@ -3306,8 +3306,9 @@ int sandybridge_pcode_write(struct drm_i915_private *dev_priv, u32 mbox, u32 val u32 vlv_punit_read(struct drm_i915_private *dev_priv, u32 addr); void vlv_punit_write(struct drm_i915_private *dev_priv, u32 addr, u32 val); u32 vlv_nc_read(struct drm_i915_private *dev_priv, u8 addr); -u32 vlv_gpio_nc_read(struct drm_i915_private *dev_priv, u32 reg); -void vlv_gpio_nc_write(struct drm_i915_private *dev_priv, u32 reg, u32 val); +u32 vlv_gpio_read(struct drm_i915_private *dev_priv, u8 core_offset, u32 reg); +void vlv_gpio_write(struct drm_i915_private *dev_priv, u8 core_offset, + u32 reg, u32 val); u32 vlv_cck_read(struct drm_i915_private *dev_priv, u32 reg); void vlv_cck_write(struct drm_i915_private *dev_priv, u32 reg, u32 val); u32 vlv_ccu_read(struct drm_i915_private *dev_priv, u32 reg); diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h index 313b1f9..3efea0e 100644 --- a/drivers/gpu/drm/i915/i915_reg.h +++ b/drivers/gpu/drm/i915/i915_reg.h @@ -554,6 +554,11 @@ #define IOSF_PORT_DPIO 0x12 #define IOSF_PORT_DPIO_2 0x1a #define IOSF_PORT_GPIO_NC0x13 +#define IOSF_PORT_GPIO_SC0x48 +#define IOSF_PORT_GPIO_SUS 0xA8 +#define MAX_GPIO_NUM_NC 26 +#define MAX_GPIO_NUM_SC 128 +#define MAX_GPIO_NUM 172 #define IOSF_PORT_CCK0x14 #define IOSF_PORT_CCU0xA9 #define IOSF_PORT_GPS_CORE 0x48 diff --git a/drivers/gpu/drm/i915/intel_dsi.h b/drivers/gpu/drm/i915/intel_dsi.h index 2784ac4..13d3d22 100644 --- a/drivers/gpu/drm/i915/intel_dsi.h +++ b/drivers/gpu/drm/i915/intel_dsi.h @@ -34,6 +34,361 @@ #define DSI_DUAL_LINK_FRONT_BACK 1 #define DSI_DUAL_LINK_PIXEL_ALT2 +#define HV_DDI0_HPD_GPIONC_0_PCONF00x4130 +#define HV_DDI0_HPD_GPIONC_0_PAD 0x4138 +#define HV_DDI0_DDC_SDA_GPIONC_1_PCONF00x4120 +#define HV_DDI0_DDC_SDA_GPIONC_1_PAD 0x4128 +#define HV_DDI0_DDC_SCL_GPIONC_2_PCONF00x4110 +#define HV_DDI0_DDC_SCL_GPIONC_2_PAD 0x4118 +#define PANEL0_VDDEN_GPIONC_3_PCONF0 0x4140 +#define PANEL0_VDDEN_GPIONC_3_PAD 0x4148 +#define PANEL0_BKLTEN_GPIONC_4_PCONF0 0x4150 +#define PANEL0_BKLTEN_GPIONC_4_PAD 0x4158 +#define PANEL0_BKLTCTL_GPIONC_5_PCONF0 0x4160 +#define PANEL0_BKLTCTL_GPIONC_5_PAD0x4168 +#define HV_DDI1_HPD_GPIONC_6_PCONF00x4180 +#define HV_DDI1_HPD_GPIONC_6_PAD 0x4188 +#define HV_DDI1_DDC_SDA_GPIONC_7_PCONF00x4190 +#define HV_DDI1_DDC_SDA_GPIONC_7_PAD 0x4198 +#define HV_DDI1_DDC_SCL_GPIONC_8_PCONF00x4170 +#define HV_DDI1_DDC_SCL_GPIONC_8_PAD 0x4178 +#define PANEL1_VDDEN_GPIONC_9_PCONF0 0x4100 +#define PANEL1_VDDEN_GPIONC_9_PAD 0x4108 +#define PANEL1_BKLTEN_GPIONC_10_PCONF0 0x40E0 +#define PANEL1_BKLTEN_GPIONC_10_PAD0x40E8 +#define PANEL1_BKLTCTL_GPIONC_11_PCONF00x40F0 +#define PANEL1_BKLTCTL_GPIONC_11_PAD 0x40F8 +#define GP_INTD_DSI_TE1_GPIONC_12_PCONF0 0x40C0 +#define GP_INTD_DSI_TE1_GPIONC_12_PAD 0x40C8 +#define HV_DDI2_DDC_SDA_GPIONC_13_PCONF0 0x41A0 +#define HV_DDI2_DDC_SDA_GPIONC_13_PAD 0x41A8 +#define HV_DDI2_DDC_SCL_GPIONC_14_PCONF0 0x41B0 +#define HV_DDI2_DDC_SCL_GPIONC_14_PAD 0x41B8 +#define GP_CAMERASB00_GPIONC_15_PCONF0 0x4010 +#define GP_CAMERASB00_GPIONC_15_PAD0x4018 +#define GP_CAMERASB01_GPIONC_16_PCONF0 0x4040 +#define GP_CAMERASB01_GPIONC_16_PAD0x4048 +#define GP_CAMERASB02_GPIONC_17_PCONF0 0x4080 +#define GP_CAMERASB02_GPIONC_17_PAD0x4088 +#define GP_CAMERASB03_GPIONC_18_PCONF0 0x40B0 +#define GP_CAMERASB03_GPIONC_18_PAD0x40B8 +#define GP_CAMERASB04_GPIONC_19_PCONF0 0x4000 +#define GP_CAMERASB04_GPIONC_19_PAD0x4008 +#define GP_CAMERASB05_GPIONC_20_PCONF0 0x4030 +#define GP_CAMERASB05_GPIONC_20_P
[Intel-gfx] [MIPI SEQ PARSING v1 PATCH 3/9] drm/i915: Using the approprite vbt size if vbt is not in mailbox4 of opregion
Currently the field in bdb header which indicates the VBT size
is of 2 bytes, but there are some cases where VBT size exceeds
64KB in which case this field may not contain the correct VBT size.
So its better to get the VBT size from the mailbox3 if
VBT is not present in the mailbox4 of opregion.
Signed-off-by: Deepak M
---
drivers/gpu/drm/i915/i915_drv.h |5
drivers/gpu/drm/i915/intel_bios.c | 43 +++--
drivers/gpu/drm/i915/intel_opregion.c |7 --
3 files changed, 35 insertions(+), 20 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 1dbd957..b38f52ee 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1740,6 +1740,11 @@ struct drm_i915_private {
u32 pm_rps_events;
u32 pipestat_irq_mask[I915_MAX_PIPES];
+ bool vbt_in_mailbox4;
+
+ /* value is true when VBT is present in mailbox4 */
+ u32 vbt_size;
+
struct i915_hotplug hotplug;
struct i915_fbc fbc;
struct i915_drrs drrs;
diff --git a/drivers/gpu/drm/i915/intel_bios.c
b/drivers/gpu/drm/i915/intel_bios.c
index 1b9164e..5e0ff22 100644
--- a/drivers/gpu/drm/i915/intel_bios.c
+++ b/drivers/gpu/drm/i915/intel_bios.c
@@ -37,17 +37,22 @@
static int panel_type;
static const void *
-find_section(const void *_bdb, int section_id)
+find_section(struct drm_i915_private *dev_priv,
+ const void *_bdb, int section_id)
{
const struct bdb_header *bdb = _bdb;
const u8 *base = _bdb;
int index = 0;
- u16 total, current_size;
+ u32 total, current_size;
u8 current_id;
/* skip to first section */
index += bdb->header_size;
- total = bdb->bdb_size;
+
+ if (dev_priv->vbt_in_mailbox4)
+ total = bdb->bdb_size;
+ else
+ total = dev_priv->vbt_size;
/* walk the sections looking for section_id */
while (index + 3 < total) {
@@ -179,7 +184,7 @@ parse_lfp_panel_data(struct drm_i915_private *dev_priv,
struct drm_display_mode *panel_fixed_mode;
int drrs_mode;
- lvds_options = find_section(bdb, BDB_LVDS_OPTIONS);
+ lvds_options = find_section(dev_priv, bdb, BDB_LVDS_OPTIONS);
if (!lvds_options)
return;
@@ -211,11 +216,12 @@ parse_lfp_panel_data(struct drm_i915_private *dev_priv,
break;
}
- lvds_lfp_data = find_section(bdb, BDB_LVDS_LFP_DATA);
+ lvds_lfp_data = find_section(dev_priv, bdb, BDB_LVDS_LFP_DATA);
if (!lvds_lfp_data)
return;
- lvds_lfp_data_ptrs = find_section(bdb, BDB_LVDS_LFP_DATA_PTRS);
+ lvds_lfp_data_ptrs = find_section(dev_priv, bdb,
+ BDB_LVDS_LFP_DATA_PTRS);
if (!lvds_lfp_data_ptrs)
return;
@@ -257,7 +263,7 @@ parse_lfp_backlight(struct drm_i915_private *dev_priv,
const struct bdb_lfp_backlight_data *backlight_data;
const struct bdb_lfp_backlight_data_entry *entry;
- backlight_data = find_section(bdb, BDB_LVDS_BACKLIGHT);
+ backlight_data = find_section(dev_priv, bdb, BDB_LVDS_BACKLIGHT);
if (!backlight_data)
return;
@@ -305,14 +311,15 @@ parse_sdvo_panel_data(struct drm_i915_private *dev_priv,
if (index == -1) {
const struct bdb_sdvo_lvds_options *sdvo_lvds_options;
- sdvo_lvds_options = find_section(bdb, BDB_SDVO_LVDS_OPTIONS);
+ sdvo_lvds_options = find_section(dev_priv, bdb,
+ BDB_SDVO_LVDS_OPTIONS);
if (!sdvo_lvds_options)
return;
index = sdvo_lvds_options->panel_type;
}
- dvo_timing = find_section(bdb, BDB_SDVO_PANEL_DTDS);
+ dvo_timing = find_section(dev_priv, bdb, BDB_SDVO_PANEL_DTDS);
if (!dvo_timing)
return;
@@ -349,7 +356,7 @@ parse_general_features(struct drm_i915_private *dev_priv,
struct drm_device *dev = dev_priv->dev;
const struct bdb_general_features *general;
- general = find_section(bdb, BDB_GENERAL_FEATURES);
+ general = find_section(dev_priv, bdb, BDB_GENERAL_FEATURES);
if (general) {
dev_priv->vbt.int_tv_support = general->int_tv_support;
dev_priv->vbt.int_crt_support = general->int_crt_support;
@@ -374,7 +381,7 @@ parse_general_definitions(struct drm_i915_private *dev_priv,
{
const struct bdb_general_definitions *general;
- general = find_section(bdb, BDB_GENERAL_DEFINITIONS);
+ general = find_section(dev_priv, bdb, BDB_GENERAL_DEFINITIONS);
if (general) {
u16 block_size = get_blocksize(general);
if (block_size >= sizeof(*general)) {
@@ -405,7 +412,7 @@ parse_sdvo_device_mapping(struct drm_i915_private *dev_priv,
int i, c
[Intel-gfx] [MIPI SEQ V3 PARSING PATCH 0/9] Patches to support the version 3 of MIPI sequence in VBT.
Currently in our kernel we ioremap 8KB of memory for the opregion and it holds a maximum of 6KB sized RAW vbt data. As per the latest opregion spec when the VBT size exceeds 6KB it cant be placed in the mailbox4 of the opregion, so the physical address of the buffer where the Raw VBT is stored will be mentioned in the mailbox3 with the VBT size in the opregion version 2 and above. A non-zero value here is an indication to driver that a valid Raw VBT is stored here and driver should not refer to mailbox4 for getting VBT. This is implemented in one of the patches in this series. link for the opregion spec : https://securewiki.ith.intel.com/pages/viewpage.action?pageId=48147378 (spec is under intel firewall) In the version 3 of the MIPI sequence block, the size field is 4 bytes so that it can support block size of more than 64KB, but the vbt size field in the bdb header is only 2 bytes. Based on the below points this issue can be handled. 1. When the VBT is not present in the mailbox4 then VBT size needs to be read from the mailbox3 and this VBT size field is of 4 bytes which implies that it can be more than 64KB also. 2. If the VBT size is more than 64KB then the VBT size field in the bdb header cant be relied. So its better to consider the vbt size from the mailbox3 when the VBT is not present in mailbox4. Other patches implements the parsing of the new sequence type which are added in the block 53 and adding new wrapper functions for the struct drm_panel_funcs. Deepak M (4): drm/i915: Parsing VBT if size of VBT exceeds 6KB drm/i915: Using the approprite vbt size if vbt is not in mailbox4 of opregion drm/i915: Added the generic gpio sequence support and gpio table drm: Add few more wrapper functions for drm panel Gaurav K Singh (1): drm/i915: Add functions to execute the new sequences from VBT Uma Shankar (1): BXT GPIO support for backlight and panel control Yogesh Mohan Marimuthu (1): drm/i915: GPIO for CHT generic MIPI vkorjani (2): drm/i915: Adding the parsing logic for the i2c element drm/i915: Added support the v3 mipi sequence block drivers/gpu/drm/i915/i915_drv.h| 10 +- drivers/gpu/drm/i915/i915_reg.h| 28 ++ drivers/gpu/drm/i915/intel_bios.c | 181 +++--- drivers/gpu/drm/i915/intel_bios.h |9 + drivers/gpu/drm/i915/intel_dsi.h | 355 +++ drivers/gpu/drm/i915/intel_dsi_panel_vbt.c | 513 ++-- drivers/gpu/drm/i915/intel_opregion.c | 42 ++- drivers/gpu/drm/i915/intel_sideband.c |9 +- include/drm/drm_panel.h| 47 +++ 9 files changed, 1119 insertions(+), 75 deletions(-) -- 1.7.9.5 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [MIPI SEQ PARSING v1 PATCH 1/9] drm/i915: Adding the parsing logic for the i2c element
From: vkorjani
New sequence element for i2c is been added in the
mipi sequence block of the VBT. This patch parses
and executes the i2c sequence.
Signed-off-by: vkorjani
Signed-off-by: Deepak M
---
drivers/gpu/drm/i915/intel_bios.c |6 +++
drivers/gpu/drm/i915/intel_bios.h |1 +
drivers/gpu/drm/i915/intel_dsi_panel_vbt.c | 59
3 files changed, 66 insertions(+)
diff --git a/drivers/gpu/drm/i915/intel_bios.c
b/drivers/gpu/drm/i915/intel_bios.c
index 2ff9eb0..2583587 100644
--- a/drivers/gpu/drm/i915/intel_bios.c
+++ b/drivers/gpu/drm/i915/intel_bios.c
@@ -714,6 +714,12 @@ static u8 *goto_next_sequence(u8 *data, int *size)
data += 3;
break;
+ case MIPI_SEQ_ELEM_I2C:
+ /* skip by this element payload size */
+ data += 7;
+ len = *data;
+ data += len + 1;
+ break;
default:
DRM_ERROR("Unknown element\n");
return NULL;
diff --git a/drivers/gpu/drm/i915/intel_bios.h
b/drivers/gpu/drm/i915/intel_bios.h
index af0b476..1703a83 100644
--- a/drivers/gpu/drm/i915/intel_bios.h
+++ b/drivers/gpu/drm/i915/intel_bios.h
@@ -942,6 +942,7 @@ enum mipi_seq_element {
MIPI_SEQ_ELEM_SEND_PKT,
MIPI_SEQ_ELEM_DELAY,
MIPI_SEQ_ELEM_GPIO,
+ MIPI_SEQ_ELEM_I2C,
MIPI_SEQ_ELEM_STATUS,
MIPI_SEQ_ELEM_MAX
};
diff --git a/drivers/gpu/drm/i915/intel_dsi_panel_vbt.c
b/drivers/gpu/drm/i915/intel_dsi_panel_vbt.c
index a5e99ac..e061a42 100644
--- a/drivers/gpu/drm/i915/intel_dsi_panel_vbt.c
+++ b/drivers/gpu/drm/i915/intel_dsi_panel_vbt.c
@@ -31,6 +31,7 @@
#include
#include
#include
+#include
#include
#include
#include "i915_drv.h"
@@ -104,6 +105,63 @@ static struct gpio_table gtable[] = {
{ GPIO_NC_11_PCONF0, GPIO_NC_11_PAD, 0}
};
+static const u8 *mipi_exec_i2c(struct intel_dsi *intel_dsi, const u8 *data)
+{
+ struct i2c_adapter *adapter;
+ int ret;
+ u8 reg_offset, payload_size, retries = 5;
+ struct i2c_msg msg;
+ u8 *transmit_buffer = NULL;
+ u8 flag = *data++;
+ u8 index = *data++;
+ u8 bus_number = *data++;
+ u16 slave_add = *(u16 *)(data);
+
+ data = data + 2;
+ reg_offset = *data++;
+ payload_size = *data++;
+
+ adapter = i2c_get_adapter(bus_number);
+
+ if (!adapter) {
+ DRM_ERROR("i2c_get_adapter(%u) failed, index:%u flag: %u\n",
+ (bus_number + 1), index, flag);
+ goto out;
+ }
+
+ transmit_buffer = kmalloc(1 + payload_size, GFP_TEMPORARY);
+
+ if (!transmit_buffer)
+ goto out;
+
+ transmit_buffer[0] = reg_offset;
+ memcpy(&transmit_buffer[1], data, (size_t)payload_size);
+
+ msg.addr = slave_add;
+ msg.flags = 0;
+ msg.len= 2;
+ msg.buf= &transmit_buffer[0];
+
+ do {
+ ret = i2c_transfer(adapter, &msg, 1);
+ if (ret == -EAGAIN)
+ usleep_range(1000, 2500);
+ else if (ret != 1) {
+ DRM_ERROR("i2c transfer failed %d\n", ret);
+ break;
+ }
+ } while (retries--);
+
+ if (retries == 0)
+ DRM_ERROR("i2c transfer failed");
+
+out:
+ kfree(transmit_buffer);
+
+ data = data + payload_size;
+ return data;
+}
+
static inline enum port intel_dsi_seq_port_to_port(u8 port)
{
return port ? PORT_C : PORT_A;
@@ -236,6 +294,7 @@ static const fn_mipi_elem_exec exec_elem[] = {
mipi_exec_send_packet,
mipi_exec_delay,
mipi_exec_gpio,
+ mipi_exec_i2c,
NULL, /* status read; later */
};
--
1.7.9.5
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [MIPI SEQ PARSING v1 PATCH 7/9] drm: Add few more wrapper functions for drm panel
Currently there are few pair of functions which
are called during the panel enable/disable sequence.
To improve the granularity, adding few more wrapper
functions so that the functions are more specific
on what they are doing and also in some cases
some specific operations have to be done between these
functions.
Signed-off-by: Deepak M
Signed-off-by: Gaurav K Singh
---
include/drm/drm_panel.h | 47 +++
1 file changed, 47 insertions(+)
diff --git a/include/drm/drm_panel.h b/include/drm/drm_panel.h
index 13ff44b..c729f6d 100644
--- a/include/drm/drm_panel.h
+++ b/include/drm/drm_panel.h
@@ -73,6 +73,12 @@ struct drm_panel_funcs {
int (*get_modes)(struct drm_panel *panel);
int (*get_timings)(struct drm_panel *panel, unsigned int num_timings,
struct display_timing *timings);
+ int (*power_on)(struct drm_panel *panel);
+ int (*power_off)(struct drm_panel *panel);
+ int (*backlight_on)(struct drm_panel *panel);
+ int (*backlight_off)(struct drm_panel *panel);
+ int (*get_info)(struct drm_panel *panel,
+ struct drm_connector *connector);
};
struct drm_panel {
@@ -117,6 +123,47 @@ static inline int drm_panel_enable(struct drm_panel *panel)
return panel ? -ENOSYS : -EINVAL;
}
+static inline int drm_panel_power_on(struct drm_panel *panel)
+{
+ if (panel && panel->funcs && panel->funcs->power_on)
+ return panel->funcs->power_on(panel);
+
+ return panel ? -ENOSYS : -EINVAL;
+}
+
+static inline int drm_panel_power_off(struct drm_panel *panel)
+{
+ if (panel && panel->funcs && panel->funcs->power_off)
+ return panel->funcs->power_off(panel);
+
+ return panel ? -ENOSYS : -EINVAL;
+}
+
+static inline int drm_panel_backlight_on(struct drm_panel *panel)
+{
+ if (panel && panel->funcs && panel->funcs->backlight_on)
+ return panel->funcs->backlight_on(panel);
+
+ return panel ? -ENOSYS : -EINVAL;
+}
+
+static inline int drm_panel_backlight_off(struct drm_panel *panel)
+{
+ if (panel && panel->funcs && panel->funcs->backlight_off)
+ return panel->funcs->backlight_off(panel);
+
+ return panel ? -ENOSYS : -EINVAL;
+}
+
+static inline int drm_panel_get_info(struct drm_panel *panel,
+ struct drm_connector *connector)
+{
+ if (connector && panel && panel->funcs && panel->funcs->get_info)
+ return panel->funcs->get_info(panel, connector);
+
+ return panel ? -ENOSYS : -EINVAL;
+}
+
static inline int drm_panel_get_modes(struct drm_panel *panel)
{
if (panel && panel->funcs && panel->funcs->get_modes)
--
1.7.9.5
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [MIPI SEQ PARSING v1 PATCH 8/9] drm/i915: Add functions to execute the new sequences from VBT
From: Gaurav K Singh
New sequences are added in the mipi sequence block of the
VBT from version 3 onwards. The sequences are added to
make the code more generic as the panel related info
are placed in the VBT.
Signed-off-by: Gaurav K Singh
Signed-off-by: Shobhit Kumar
Signed-off-by: Deepak M
---
drivers/gpu/drm/i915/intel_dsi_panel_vbt.c | 84 +++-
1 file changed, 83 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/intel_dsi_panel_vbt.c
b/drivers/gpu/drm/i915/intel_dsi_panel_vbt.c
index 060305d..c6f66e4 100644
--- a/drivers/gpu/drm/i915/intel_dsi_panel_vbt.c
+++ b/drivers/gpu/drm/i915/intel_dsi_panel_vbt.c
@@ -581,7 +581,13 @@ static const char * const seq_name[] = {
"MIPI_SEQ_INIT_OTP",
"MIPI_SEQ_DISPLAY_ON",
"MIPI_SEQ_DISPLAY_OFF",
- "MIPI_SEQ_DEASSERT_RESET"
+ "MIPI_SEQ_DEASSERT_RESET",
+ "MIPI_SEQ_BACKLIGHT_ON",
+ "MIPI_SEQ_BACKLIGHT_OFF",
+ "MIPI_SEQ_TEAR_ON",
+ "MIPI_SEQ_TEAR_OFF",
+ "MIPI_SEQ_POWER_ON",
+ "MIPI_SEQ_POWER_OFF"
};
static void generic_exec_sequence(struct intel_dsi *intel_dsi, const u8 *data)
@@ -710,12 +716,88 @@ static int vbt_panel_get_modes(struct drm_panel *panel)
return 1;
}
+static int vbt_panel_power_on(struct drm_panel *panel)
+{
+ struct vbt_panel *vbt_panel = to_vbt_panel(panel);
+ struct intel_dsi *intel_dsi = vbt_panel->intel_dsi;
+ struct drm_device *dev = intel_dsi->base.base.dev;
+ struct drm_i915_private *dev_priv = dev->dev_private;
+ const u8 *sequence;
+
+ sequence = dev_priv->vbt.dsi.sequence[MIPI_SEQ_POWER_ON];
+ generic_exec_sequence(intel_dsi, sequence);
+
+ return 0;
+}
+
+static int vbt_panel_power_off(struct drm_panel *panel)
+{
+ struct vbt_panel *vbt_panel = to_vbt_panel(panel);
+ struct intel_dsi *intel_dsi = vbt_panel->intel_dsi;
+ struct drm_device *dev = intel_dsi->base.base.dev;
+ struct drm_i915_private *dev_priv = dev->dev_private;
+ const u8 *sequence;
+
+ sequence = dev_priv->vbt.dsi.sequence[MIPI_SEQ_POWER_OFF];
+ generic_exec_sequence(intel_dsi, sequence);
+
+ return 0;
+}
+
+static int vbt_panel_backlight_on(struct drm_panel *panel)
+{
+ struct vbt_panel *vbt_panel = to_vbt_panel(panel);
+ struct intel_dsi *intel_dsi = vbt_panel->intel_dsi;
+ struct drm_device *dev = intel_dsi->base.base.dev;
+ struct drm_i915_private *dev_priv = dev->dev_private;
+ const u8 *sequence;
+
+ sequence = dev_priv->vbt.dsi.sequence[MIPI_SEQ_BACKLIGHT_ON];
+ generic_exec_sequence(intel_dsi, sequence);
+
+ return 0;
+}
+
+static int vbt_panel_backlight_off(struct drm_panel *panel)
+{
+ struct vbt_panel *vbt_panel = to_vbt_panel(panel);
+ struct intel_dsi *intel_dsi = vbt_panel->intel_dsi;
+ struct drm_device *dev = intel_dsi->base.base.dev;
+ struct drm_i915_private *dev_priv = dev->dev_private;
+ const u8 *sequence;
+
+ sequence = dev_priv->vbt.dsi.sequence[MIPI_SEQ_BACKLIGHT_OFF];
+ generic_exec_sequence(intel_dsi, sequence);
+
+ return 0;
+}
+
+static int vbt_panel_get_info(struct drm_panel *panel,
+ struct drm_connector *connector)
+{
+ struct intel_connector *intel_connector =
+ to_intel_connector(connector);
+
+ if (intel_connector) {
+ connector->display_info.width_mm =
+ intel_connector->panel.fixed_mode->width_mm;
+ connector->display_info.height_mm =
+ intel_connector->panel.fixed_mode->height_mm;
+ }
+ return 0;
+}
+
static const struct drm_panel_funcs vbt_panel_funcs = {
.disable = vbt_panel_disable,
.unprepare = vbt_panel_unprepare,
.prepare = vbt_panel_prepare,
.enable = vbt_panel_enable,
.get_modes = vbt_panel_get_modes,
+ .power_on = vbt_panel_power_on,
+ .power_off = vbt_panel_power_off,
+ .backlight_on = vbt_panel_backlight_on,
+ .backlight_off = vbt_panel_backlight_off,
+ .get_info = vbt_panel_get_info,
};
struct drm_panel *vbt_panel_init(struct intel_dsi *intel_dsi, u16 panel_id)
--
1.7.9.5
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [MIPI SEQ PARSING v1 PATCH 9/9] BXT GPIO support for backlight and panel control
From: Uma Shankar
Added the BXT GPIO pin configuration and programming logic for
backlight and panel control.
Signed-off-by: Uma Shankar
---
drivers/gpu/drm/i915/intel_dsi_panel_vbt.c | 46
1 file changed, 46 insertions(+)
diff --git a/drivers/gpu/drm/i915/intel_dsi_panel_vbt.c
b/drivers/gpu/drm/i915/intel_dsi_panel_vbt.c
index c6f66e4..f27a568 100644
--- a/drivers/gpu/drm/i915/intel_dsi_panel_vbt.c
+++ b/drivers/gpu/drm/i915/intel_dsi_panel_vbt.c
@@ -32,6 +32,7 @@
#include
#include
#include
+#include
#include
#include
#include "i915_drv.h"
@@ -325,6 +326,16 @@ out:
return data;
}
+struct bxt_gpio_table {
+ u16 gpio_pin;
+ u16 offset;
+};
+
+static struct bxt_gpio_table bxt_gtable[] = {
+ {0xC1, 270},
+ {0x1B, 456}
+};
+
static inline enum port intel_dsi_seq_port_to_port(u8 port)
{
return port ? PORT_C : PORT_A;
@@ -537,6 +548,39 @@ static int vlv_program_gpio(struct intel_dsi *intel_dsi,
return 0;
}
+static int bxt_program_gpio(struct intel_dsi *intel_dsi,
+ const u8 *data, const u8 **cur_data)
+{
+ struct drm_device *dev = intel_dsi->base.base.dev;
+ struct drm_i915_private *dev_priv = dev->dev_private;
+ u8 gpio, action;
+ u16 function;
+
+ /*
+* Skipping the first byte as it is of no
+* interest for android in new version
+*/
+ if (dev_priv->vbt.dsi.seq_version >= 3)
+ data++;
+
+ gpio = *data++;
+
+ /* pull up/down */
+ action = *data++;
+ function = (bxt_gtable[0].gpio_pin == gpio) ?
+ bxt_gtable[0].offset :
+ (bxt_gtable[1].gpio_pin == gpio) ?
+ bxt_gtable[1].offset : 0;
+ if (!function)
+ return -1;
+
+ gpio_request_one(function, GPIOF_DIR_OUT, "MIPI");
+ gpio_set_value(function, action);
+
+ *cur_data = data;
+ return 0;
+}
+
static const u8 *mipi_exec_gpio(struct intel_dsi *intel_dsi, const u8 *data)
{
struct drm_device *dev = intel_dsi->base.base.dev;
@@ -550,6 +594,8 @@ static const u8 *mipi_exec_gpio(struct intel_dsi
*intel_dsi, const u8 *data)
ret = chv_program_gpio(intel_dsi, data, &data);
else if (IS_VALLEYVIEW(dev))
ret = vlv_program_gpio(intel_dsi, data, &data);
+ else if (IS_BROXTON(dev))
+ ret = bxt_program_gpio(intel_dsi, data, &data);
else
DRM_ERROR("GPIO programming missing for this platform.\n");
--
1.7.9.5
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [RFC 3/9] drm/i915: Convert requests to use struct fence
On 21/07/2015 08:05, Daniel Vetter wrote:
On Fri, Jul 17, 2015 at 03:31:17PM +0100, john.c.harri...@intel.com wrote:
From: John Harrison
There is a construct in the linux kernel called 'struct fence' that is intended
to keep track of work that is executed on hardware. I.e. it solves the basic
problem that the drivers 'struct drm_i915_gem_request' is trying to address. The
request structure does quite a lot more than simply track the execution progress
so is very definitely still required. However, the basic completion status side
could be updated to use the ready made fence implementation and gain all the
advantages that provides.
This patch makes the first step of integrating a struct fence into the request.
It replaces the explicit reference count with that of the fence. It also
replaces the 'is completed' test with the fence's equivalent. Currently, that
simply chains on to the original request implementation. A future patch will
improve this.
For: VIZ-5190
Signed-off-by: John Harrison
---
drivers/gpu/drm/i915/i915_drv.h | 45 +
drivers/gpu/drm/i915/i915_gem.c | 58 ++---
drivers/gpu/drm/i915/intel_lrc.c| 1 +
drivers/gpu/drm/i915/intel_ringbuffer.c | 1 +
drivers/gpu/drm/i915/intel_ringbuffer.h | 3 ++
5 files changed, 80 insertions(+), 28 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index cf6761c..79d346c 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -50,6 +50,7 @@
#include
#include
#include
+#include
/* General customization:
*/
@@ -2150,7 +2151,17 @@ void i915_gem_track_fb(struct drm_i915_gem_object *old,
* initial reference taken using kref_init
*/
struct drm_i915_gem_request {
- struct kref ref;
+ /**
+* Underlying object for implementing the signal/wait stuff.
+* NB: Never call fence_later() or return this fence object to user
+* land! Due to lazy allocation, scheduler re-ordering, pre-emption,
+* etc., there is no guarantee at all about the validity or
+* sequentiality of the fence's seqno! It is also unsafe to let
+* anything outside of the i915 driver get hold of the fence object
+* as the clean up when decrementing the reference count requires
+* holding the driver mutex lock.
+*/
This comment is outdated.
Not at this point in the patch series. Until the 'delay freeing of
requests' patch it is very definitely unsafe to allow external reference
counting of the fence object as decrementing the count must only be done
with the mutex lock held. Likewise, without the per context per ring
timeline, the seqno value would unsafe if any scheduling code was added.
The comment is written from the point of view of what happens if this
patch is taken as a stand alone patch without the rest of the series
following and describes the state of the driver at that moment in time.
Also I'm leaning towards squashing this patch
with the one implementing fences with explicit irq enabling, to avoid
churn and intermediate WARN_ONs. Each patch should be fully functional
without requiring follow-up patches.
It is fully functional as a stand alone patch. The intermediate WARN_ONs
would never fire unless someone takes only this patch and the starts
adding extra (unsupported) usage of the fence object. If they want to do
that then they must first add in the extra support that they need. Or
they could just take the rest of the series which adds in that support
for them.
Squashing the interrupt support into the basic fence implementation
would just make for a much more complicated single patch.
-Daniel
+ struct fence fence;
/** On Which ring this request was generated */
struct drm_i915_private *i915;
@@ -2227,7 +2238,13 @@ int i915_gem_request_alloc(struct intel_engine_cs *ring,
struct intel_context *ctx,
struct drm_i915_gem_request **req_out);
void i915_gem_request_cancel(struct drm_i915_gem_request *req);
-void i915_gem_request_free(struct kref *req_ref);
+
+static inline bool i915_gem_request_completed(struct drm_i915_gem_request *req,
+ bool lazy_coherency)
+{
+ return fence_is_signaled(&req->fence);
+}
+
int i915_gem_request_add_to_client(struct drm_i915_gem_request *req,
struct drm_file *file);
@@ -2247,7 +2264,7 @@ static inline struct drm_i915_gem_request *
i915_gem_request_reference(struct drm_i915_gem_request *req)
{
if (req)
- kref_get(&req->ref);
+ fence_get(&req->fence);
return req;
}
@@ -2255,7 +2272,7 @@ static inline void
i915_gem_request_unreference(struct drm_i915_gem_request *req)
{
WARN_ON(!mutex_is_locked(&req->ring->dev->struct_mutex));
- kref_put(&re
Re: [Intel-gfx] [RFC 3/9] drm/i915: Convert requests to use struct fence
On 22/07/2015 15:26, Tvrtko Ursulin wrote:
Hi,
On 07/17/2015 03:31 PM, john.c.harri...@intel.com wrote:
From: John Harrison
There is a construct in the linux kernel called 'struct fence' that
is intended
to keep track of work that is executed on hardware. I.e. it solves
the basic
problem that the drivers 'struct drm_i915_gem_request' is trying to
address. The
request structure does quite a lot more than simply track the
execution progress
so is very definitely still required. However, the basic completion
status side
could be updated to use the ready made fence implementation and gain
all the
advantages that provides.
This patch makes the first step of integrating a struct fence into
the request.
It replaces the explicit reference count with that of the fence. It also
replaces the 'is completed' test with the fence's equivalent.
Currently, that
simply chains on to the original request implementation. A future
patch will
improve this.
For: VIZ-5190
Signed-off-by: John Harrison
---
drivers/gpu/drm/i915/i915_drv.h | 45 +
drivers/gpu/drm/i915/i915_gem.c | 58
++---
drivers/gpu/drm/i915/intel_lrc.c| 1 +
drivers/gpu/drm/i915/intel_ringbuffer.c | 1 +
drivers/gpu/drm/i915/intel_ringbuffer.h | 3 ++
5 files changed, 80 insertions(+), 28 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h
b/drivers/gpu/drm/i915/i915_drv.h
index cf6761c..79d346c 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -50,6 +50,7 @@
#include
#include
#include
+#include
/* General customization:
*/
@@ -2150,7 +2151,17 @@ void i915_gem_track_fb(struct
drm_i915_gem_object *old,
* initial reference taken using kref_init
*/
struct drm_i915_gem_request {
-struct kref ref;
+/**
+ * Underlying object for implementing the signal/wait stuff.
+ * NB: Never call fence_later() or return this fence object to user
+ * land! Due to lazy allocation, scheduler re-ordering,
pre-emption,
+ * etc., there is no guarantee at all about the validity or
+ * sequentiality of the fence's seqno! It is also unsafe to let
+ * anything outside of the i915 driver get hold of the fence object
+ * as the clean up when decrementing the reference count requires
+ * holding the driver mutex lock.
+ */
+struct fence fence;
/** On Which ring this request was generated */
struct drm_i915_private *i915;
@@ -2227,7 +2238,13 @@ int i915_gem_request_alloc(struct
intel_engine_cs *ring,
struct intel_context *ctx,
struct drm_i915_gem_request **req_out);
void i915_gem_request_cancel(struct drm_i915_gem_request *req);
-void i915_gem_request_free(struct kref *req_ref);
+
+static inline bool i915_gem_request_completed(struct
drm_i915_gem_request *req,
+ bool lazy_coherency)
+{
+return fence_is_signaled(&req->fence);
+}
+
int i915_gem_request_add_to_client(struct drm_i915_gem_request *req,
struct drm_file *file);
@@ -2247,7 +2264,7 @@ static inline struct drm_i915_gem_request *
i915_gem_request_reference(struct drm_i915_gem_request *req)
{
if (req)
-kref_get(&req->ref);
+fence_get(&req->fence);
return req;
}
@@ -2255,7 +2272,7 @@ static inline void
i915_gem_request_unreference(struct drm_i915_gem_request *req)
{
WARN_ON(!mutex_is_locked(&req->ring->dev->struct_mutex));
-kref_put(&req->ref, i915_gem_request_free);
+fence_put(&req->fence);
}
static inline void
@@ -2267,7 +2284,7 @@ i915_gem_request_unreference__unlocked(struct
drm_i915_gem_request *req)
return;
dev = req->ring->dev;
-if (kref_put_mutex(&req->ref, i915_gem_request_free,
&dev->struct_mutex))
+if (kref_put_mutex(&req->fence.refcount, fence_release,
&dev->struct_mutex))
mutex_unlock(&dev->struct_mutex);
Would it be nicer to add fence_put_mutex(struct fence *, struct mutex
*) for this? It would avoid the layering violation of requests peeking
into fence implementation details.
Maarten pointed out that adding 'fence_put_mutex()' is breaking the
fence ABI itself. It requires users of any random fence to know and
worry about what mutex objects that fence's internal implementation
might require.
This is a bit more hacky from our point of view but it is only a
temporary measure until the mutex lock is not required for
dereferencing. At that point all the nasty stuff disappears completely.
}
@@ -2284,12 +2301,6 @@ static inline void
i915_gem_request_assign(struct drm_i915_gem_request **pdst,
}
/*
- * XXX: i915_gem_request_completed should be here but currently
needs the
- * definition of i915_seqno_passed() which is below. It will be
moved in
- * a later patch when the call to i915_seqno_passed() is obsoleted...
- */
-
-/*
* A command that requires special handling by the command
Re: [Intel-gfx] [RFC 3/9] drm/i915: Convert requests to use struct fence
On 22/07/2015 15:45, Tvrtko Ursulin wrote:
On 07/17/2015 03:31 PM, john.c.harri...@intel.com wrote:
From: John Harrison
There is a construct in the linux kernel called 'struct fence' that
is intended
to keep track of work that is executed on hardware. I.e. it solves
the basic
problem that the drivers 'struct drm_i915_gem_request' is trying to
address. The
request structure does quite a lot more than simply track the
execution progress
so is very definitely still required. However, the basic completion
status side
could be updated to use the ready made fence implementation and gain
all the
advantages that provides.
This patch makes the first step of integrating a struct fence into
the request.
It replaces the explicit reference count with that of the fence. It also
replaces the 'is completed' test with the fence's equivalent.
Currently, that
simply chains on to the original request implementation. A future
patch will
improve this.
For: VIZ-5190
Signed-off-by: John Harrison
---
drivers/gpu/drm/i915/i915_drv.h | 45 +
drivers/gpu/drm/i915/i915_gem.c | 58
++---
drivers/gpu/drm/i915/intel_lrc.c| 1 +
drivers/gpu/drm/i915/intel_ringbuffer.c | 1 +
drivers/gpu/drm/i915/intel_ringbuffer.h | 3 ++
5 files changed, 80 insertions(+), 28 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h
b/drivers/gpu/drm/i915/i915_drv.h
index cf6761c..79d346c 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -50,6 +50,7 @@
#include
#include
#include
+#include
/* General customization:
*/
@@ -2150,7 +2151,17 @@ void i915_gem_track_fb(struct
drm_i915_gem_object *old,
* initial reference taken using kref_init
*/
struct drm_i915_gem_request {
-struct kref ref;
+/**
+ * Underlying object for implementing the signal/wait stuff.
+ * NB: Never call fence_later() or return this fence object to user
+ * land! Due to lazy allocation, scheduler re-ordering,
pre-emption,
+ * etc., there is no guarantee at all about the validity or
+ * sequentiality of the fence's seqno! It is also unsafe to let
+ * anything outside of the i915 driver get hold of the fence object
+ * as the clean up when decrementing the reference count requires
+ * holding the driver mutex lock.
+ */
+struct fence fence;
/** On Which ring this request was generated */
struct drm_i915_private *i915;
@@ -2227,7 +2238,13 @@ int i915_gem_request_alloc(struct
intel_engine_cs *ring,
struct intel_context *ctx,
struct drm_i915_gem_request **req_out);
void i915_gem_request_cancel(struct drm_i915_gem_request *req);
-void i915_gem_request_free(struct kref *req_ref);
+
+static inline bool i915_gem_request_completed(struct
drm_i915_gem_request *req,
+ bool lazy_coherency)
+{
+return fence_is_signaled(&req->fence);
+}
+
int i915_gem_request_add_to_client(struct drm_i915_gem_request *req,
struct drm_file *file);
@@ -2247,7 +2264,7 @@ static inline struct drm_i915_gem_request *
i915_gem_request_reference(struct drm_i915_gem_request *req)
{
if (req)
-kref_get(&req->ref);
+fence_get(&req->fence);
return req;
}
@@ -2255,7 +2272,7 @@ static inline void
i915_gem_request_unreference(struct drm_i915_gem_request *req)
{
WARN_ON(!mutex_is_locked(&req->ring->dev->struct_mutex));
-kref_put(&req->ref, i915_gem_request_free);
+fence_put(&req->fence);
}
static inline void
@@ -2267,7 +2284,7 @@ i915_gem_request_unreference__unlocked(struct
drm_i915_gem_request *req)
return;
dev = req->ring->dev;
-if (kref_put_mutex(&req->ref, i915_gem_request_free,
&dev->struct_mutex))
+if (kref_put_mutex(&req->fence.refcount, fence_release,
&dev->struct_mutex))
mutex_unlock(&dev->struct_mutex);
}
@@ -2284,12 +2301,6 @@ static inline void
i915_gem_request_assign(struct drm_i915_gem_request **pdst,
}
/*
- * XXX: i915_gem_request_completed should be here but currently
needs the
- * definition of i915_seqno_passed() which is below. It will be
moved in
- * a later patch when the call to i915_seqno_passed() is obsoleted...
- */
-
-/*
* A command that requires special handling by the command parser.
*/
struct drm_i915_cmd_descriptor {
@@ -2851,18 +2862,6 @@ i915_seqno_passed(uint32_t seq1, uint32_t seq2)
return (int32_t)(seq1 - seq2) >= 0;
}
-static inline bool i915_gem_request_completed(struct
drm_i915_gem_request *req,
- bool lazy_coherency)
-{
-u32 seqno;
-
-BUG_ON(req == NULL);
-
-seqno = req->ring->get_seqno(req->ring, lazy_coherency);
-
-return i915_seqno_passed(seqno, req->seqno);
-}
-
int __must_check i915_gem_get_seqno(struct drm_device *dev, u32
*seqno);
int __must_check i915_gem_set_seqno(struct drm_device *dev, u32
seqno)
Re: [Intel-gfx] [PATCH 04/18] drm/i915/gen9: block disable call for pw1 if dmc firmware is present.
On Tuesday 28 July 2015 01:27 PM, Daniel Vetter wrote: On Mon, Jul 27, 2015 at 10:48:16AM +0200, Daniel Vetter wrote: On Sun, Jul 26, 2015 at 12:30:25AM +0530, Animesh Manna wrote: Grabbing a runtime pm reference with intel_runtime_pm_get will only prevent device D3. But dmc firmware is required even earlier (namely for the skl power well 1). DMC is responsible to save the status of power well 1 and shut off the power well when panel is self refresh mode of display is completely off. Another interesting criteria to work dmc as expected is pw1 to be enabled by driver and dmc will shut it off in its execution sequence. If already disabled by driver dmc will get confuse and behave differently than expected found during pc10 entry issue for skl. So berfore we disable power-well 1, added check if dmc firmware is present and driver will not disable power well 1, but for any reason if firmware is not present of failed to load we can shut off the power well 1 which will save some power. As skl is currently fully dependent on dmc to go in lowest possible power state (dc6) but the same is not applicable for bxt. Display engine can enter into dc9 without dmc, hence unblocking disable call. Cc: Daniel Vetter Cc: Damien Lespiau Cc: Imre Deak Cc: Sunil Kamath Signed-off-by: Animesh Manna Signed-off-by: Vathsala Nagaraju Please use the approach I've laid out in my original patch series with "drm/i915: use correct power domain for csr loading" and "drm/i915: Only allow rpm on gen9+ with dmc loaded". Your approach here requires a flush_work in the runtime pm callbacks which can deadlock. If you want to make dmc optional on bxt then you need to adjust the 2nd patch a bit to no longer leak the runtime pm reference. Your approach here is an inversion of control and that doesn't work well since control inversions very easily lead to locking inversions. Summary of what we just discussed offline: Ok I was confused here with the intel_csr_load_status_get() check. If we apply the above to patch from me first then we don't need that check any more, and the patch itself looks good as a bugfix for skl dmc firmware assumptions. -Daniel Thanks alot Damien. Animesh, As discussed in same call, bug fix should go initial patches in this series. also its good to add the check in skl_set_power_well function itself than intel_display_power_put - Sunil ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 18/18] drm/i915/gen9: Removed byte swapping for csr firmware.
On Tuesday 28 July 2015 01:38 PM, Nagaraju, Vathsala wrote:
Signed-off-by: Vatsala Nagaraju
It's Vathsala Nagaraju
Commit message: Removed byte swapping for csr firmware.
Commit message does not convey as to why the change was made. "This change is
needed as DMC firmware loading failed on skylake due byte swap done in the driver"
yes. agree.
Same review comments as other patches. Bug fixing patches should go
first in sequence and also commit message should contain relevant info
on fix/patch.
This byte swapping is not needed at all.
Minimal things to take care.
- Sunil
-Original Message-
From: Intel-gfx [mailto:intel-gfx-boun...@lists.freedesktop.org] On Behalf Of
Animesh Manna
Sent: Sunday, July 26, 2015 12:31 AM
To: intel-gfx@lists.freedesktop.org
Cc: Vatsala Nagaraju
Subject: [Intel-gfx] [PATCH 18/18] drm/i915/gen9: Removed byte swapping for csr
firmware.
Cc: Damien Lespiau
Cc: Imre Deak
Cc: Sunil Kamath
Signed-off-by: Animesh Manna
Signed-off-by: Vatsala Nagaraju
---
drivers/gpu/drm/i915/intel_csr.c | 11 +--
1 file changed, 1 insertion(+), 10 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_csr.c b/drivers/gpu/drm/i915/intel_csr.c
index 1858f02..50779e0 100644
--- a/drivers/gpu/drm/i915/intel_csr.c
+++ b/drivers/gpu/drm/i915/intel_csr.c
@@ -328,16 +328,7 @@ static uint32_t *parse_csr_fw(struct drm_i915_private
*dev_priv,
return NULL;
}
- for (i = 0; i < dmc_header->fw_size; i++) {
- uint32_t *tmp = (u32 *)&fw->data[readcount + i * 4];
- /*
-* The firmware payload is an array of 32 bit words stored in
-* little-endian format in the firmware image and programmed
-* as 32 bit big-endian format to memory.
-*/
- dmc_payload[i] = (uint32_t __force) cpu_to_be32(*tmp);
- }
-
+ memcpy(dmc_payload, &fw->data[readcount], dmc_header->fw_size);
return dmc_payload;
}
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [drm-intel:topic/drm-misc 8/30] DockBook: Warning(drivers/gpu/drm/drm_fb_helper.c:772): No description found for parameter 'info'
tree: git://anongit.freedesktop.org/drm-intel topic/drm-misc head: 109cd1d0fe187769f5e8ea414b9479b1c33b1d9f commit: 9c4b750e97facd19749a44e0c8eeb9d2a78dd55f [8/30] drm/fb_helper: Create wrappers for fb_sys_read/write funcs reproduce: make htmldocs All warnings (new ones prefixed by >>): Warning(drivers/gpu/drm/i915/i915_irq.c:484): No description found for parameter 'dev' Warning(drivers/gpu/drm/i915/i915_irq.c:2164): No description found for parameter 'dev' Warning(drivers/gpu/drm/i915/i915_irq.c:2344): No description found for parameter 'wedged' Warning(drivers/gpu/drm/i915/i915_irq.c:2344): No description found for parameter 'fmt' Warning(include/drm/drm_crtc.h:310): No description found for parameter 'mode_blob' Warning(include/drm/drm_crtc.h:750): No description found for parameter 'tile_blob_ptr' Warning(include/drm/drm_crtc.h:750): No description found for parameter 'destroy_list' Warning(include/drm/drm_crtc.h:789): No description found for parameter 'rotation' Warning(include/drm/drm_crtc.h:885): No description found for parameter 'mutex' Warning(include/drm/drm_crtc.h:885): No description found for parameter 'helper_private' Warning(include/drm/drm_crtc.h:933): Excess struct/union/enum/typedef member 'base' description in 'drm_bridge' Warning(include/drm/drm_crtc.h:1171): No description found for parameter 'tile_idr' Warning(include/drm/drm_crtc.h:1171): No description found for parameter 'delayed_event' Warning(include/drm/drm_crtc.h:1171): No description found for parameter 'edid_property' Warning(include/drm/drm_crtc.h:1171): No description found for parameter 'dpms_property' Warning(include/drm/drm_crtc.h:1171): No description found for parameter 'path_property' Warning(include/drm/drm_crtc.h:1171): No description found for parameter 'tile_property' Warning(include/drm/drm_crtc.h:1171): No description found for parameter 'plane_type_property' Warning(include/drm/drm_crtc.h:1171): No description found for parameter 'rotation_property' Warning(include/drm/drm_crtc.h:1171): No description found for parameter 'prop_src_x' Warning(include/drm/drm_crtc.h:1171): No description found for parameter 'prop_src_y' Warning(include/drm/drm_crtc.h:1171): No description found for parameter 'prop_src_w' Warning(include/drm/drm_crtc.h:1171): No description found for parameter 'prop_src_h' Warning(include/drm/drm_crtc.h:1171): No description found for parameter 'prop_crtc_x' Warning(include/drm/drm_crtc.h:1171): No description found for parameter 'prop_crtc_y' Warning(include/drm/drm_crtc.h:1171): No description found for parameter 'prop_crtc_w' Warning(include/drm/drm_crtc.h:1171): No description found for parameter 'prop_crtc_h' Warning(include/drm/drm_crtc.h:1171): No description found for parameter 'prop_fb_id' Warning(include/drm/drm_crtc.h:1171): No description found for parameter 'prop_crtc_id' Warning(include/drm/drm_crtc.h:1171): No description found for parameter 'prop_active' Warning(include/drm/drm_crtc.h:1171): No description found for parameter 'prop_mode_id' Warning(include/drm/drm_crtc.h:1171): No description found for parameter 'dvi_i_subconnector_property' Warning(include/drm/drm_crtc.h:1171): No description found for parameter 'dvi_i_select_subconnector_property' Warning(include/drm/drm_crtc.h:1171): No description found for parameter 'tv_subconnector_property' Warning(include/drm/drm_crtc.h:1171): No description found for parameter 'tv_select_subconnector_property' Warning(include/drm/drm_crtc.h:1171): No description found for parameter 'tv_mode_property' Warning(include/drm/drm_crtc.h:1171): No description found for parameter 'tv_left_margin_property' Warning(include/drm/drm_crtc.h:1171): No description found for parameter 'tv_right_margin_property' Warning(include/drm/drm_crtc.h:1171): No description found for parameter 'tv_top_margin_property' Warning(include/drm/drm_crtc.h:1171): No description found for parameter 'tv_bottom_margin_property' Warning(include/drm/drm_crtc.h:1171): No description found for parameter 'tv_brightness_property' Warning(include/drm/drm_crtc.h:1171): No description found for parameter 'tv_contrast_property' Warning(include/drm/drm_crtc.h:1171): No description found for parameter 'tv_flicker_reduction_property' Warning(include/drm/drm_crtc.h:1171): No description found for parameter 'tv_overscan_property' Warning(include/drm/drm_crtc.h:1171): No description found for parameter 'tv_saturation_property' Warning(include/drm/drm_crtc.h:1171): No description found for parameter 'tv_hue_property' Warning(include/drm/drm_crtc.h:1171): No description found for parameter 'scaling_mode_property' Warning(include/drm/drm_crtc.h:1171): No description found for parameter 'aspect_ratio_property' Warning(include/drm/drm_crtc.h:1171): No description found for parameter 'dirty_info_
Re: [Intel-gfx] [PATCH v5 17/19] drm/i915: Wa32bitGeneralStateOffset & Wa32bitInstructionBaseOffset
On 7/27/2015 10:11 PM, Chris Wilson wrote: On Thu, Jul 16, 2015 at 10:33:29AM +0100, Michel Thierry wrote: + if (!(entry->flags & EXEC_OBJECT_SUPPORTS_48B_ADDRESS) && + (vma->node.start + vma->node.size) >= (1ULL << 32)) + return true; gcc completely screwed this up here and used 0 for 1ULL<<32. Note that we can allow state + size == 4G (since the end is exclusive), so I went with if ((entry->flags & EXEC_OBJECT_SUPPORTS_48B_ADDRESS) == 0 && (vma->node.start + vma->node.size - 1) >> 32) return true; instead. -Chris Thanks, I'll include this change in the next patch version. ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 1/3] drm/fbdev: Return -EBUSY when oopsing
Trying to do anything with kms drivers when oopsing has become a
failing proposition. But since we can end up in the fbdev code simply
due to the console unblanking that's done unconditionally just
removing our panic handler isn't enough. We need to block all fbdev
callbacks when oopsing.
There was already one in the blank handler, but it failed silently.
That makes it impossible for drivers (like i915) who subclass these
functions to figure this out.
Instead consistently return -EBUSY so that everyone knows that we
really don't want to be bothered right now. This also allows us to
remove a pile of FIXMEs from the i915 fbdev code (since due to the
failure code they now won't attempt to grab dangerous locks any more).
Cc: Dave Airlie
Cc: Rodrigo Vivi
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/drm_fb_helper.c| 24
drivers/gpu/drm/i915/intel_fbdev.c | 21 -
2 files changed, 12 insertions(+), 33 deletions(-)
diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c
index 73f90f7e2f74..77f570a470da 100644
--- a/drivers/gpu/drm/drm_fb_helper.c
+++ b/drivers/gpu/drm/drm_fb_helper.c
@@ -491,14 +491,6 @@ static void drm_fb_helper_dpms(struct fb_info *info, int
dpms_mode)
int i, j;
/*
-* fbdev->blank can be called from irq context in case of a panic.
-* Since we already have our own special panic handler which will
-* restore the fbdev console mode completely, just bail out early.
-*/
- if (oops_in_progress)
- return;
-
- /*
* For each CRTC in this fb, turn the connectors on/off.
*/
drm_modeset_lock_all(dev);
@@ -531,6 +523,9 @@ static void drm_fb_helper_dpms(struct fb_info *info, int
dpms_mode)
*/
int drm_fb_helper_blank(int blank, struct fb_info *info)
{
+ if (oops_in_progress)
+ return -EBUSY;
+
switch (blank) {
/* Display: On; HSync: On, VSync: On */
case FB_BLANK_UNBLANK:
@@ -755,9 +750,10 @@ int drm_fb_helper_setcmap(struct fb_cmap *cmap, struct
fb_info *info)
int i, j, rc = 0;
int start;
- if (__drm_modeset_lock_all(dev, !!oops_in_progress)) {
+ if (oops_in_progress)
return -EBUSY;
- }
+
+ drm_modeset_lock_all(dev);
if (!drm_fb_helper_is_bound(fb_helper)) {
drm_modeset_unlock_all(dev);
return -EBUSY;
@@ -906,6 +902,9 @@ int drm_fb_helper_set_par(struct fb_info *info)
struct drm_fb_helper *fb_helper = info->par;
struct fb_var_screeninfo *var = &info->var;
+ if (oops_in_progress)
+ return -EBUSY;
+
if (var->pixclock != 0) {
DRM_ERROR("PIXEL CLOCK SET\n");
return -EINVAL;
@@ -931,9 +930,10 @@ int drm_fb_helper_pan_display(struct fb_var_screeninfo
*var,
int ret = 0;
int i;
- if (__drm_modeset_lock_all(dev, !!oops_in_progress)) {
+ if (oops_in_progress)
return -EBUSY;
- }
+
+ drm_modeset_lock_all(dev);
if (!drm_fb_helper_is_bound(fb_helper)) {
drm_modeset_unlock_all(dev);
return -EBUSY;
diff --git a/drivers/gpu/drm/i915/intel_fbdev.c
b/drivers/gpu/drm/i915/intel_fbdev.c
index eef54feb7545..b763f24e20ef 100644
--- a/drivers/gpu/drm/i915/intel_fbdev.c
+++ b/drivers/gpu/drm/i915/intel_fbdev.c
@@ -55,13 +55,6 @@ static int intel_fbdev_set_par(struct fb_info *info)
ret = drm_fb_helper_set_par(info);
if (ret == 0) {
- /*
-* FIXME: fbdev presumes that all callbacks also work from
-* atomic contexts and relies on that for emergency oops
-* printing. KMS totally doesn't do that and the locking here is
-* by far not the only place this goes wrong. Ignore this for
-* now until we solve this for real.
-*/
mutex_lock(&fb_helper->dev->struct_mutex);
intel_fb_obj_invalidate(ifbdev->fb->obj, ORIGIN_GTT);
mutex_unlock(&fb_helper->dev->struct_mutex);
@@ -80,13 +73,6 @@ static int intel_fbdev_blank(int blank, struct fb_info *info)
ret = drm_fb_helper_blank(blank, info);
if (ret == 0) {
- /*
-* FIXME: fbdev presumes that all callbacks also work from
-* atomic contexts and relies on that for emergency oops
-* printing. KMS totally doesn't do that and the locking here is
-* by far not the only place this goes wrong. Ignore this for
-* now until we solve this for real.
-*/
mutex_lock(&fb_helper->dev->struct_mutex);
intel_fb_obj_invalidate(ifbdev->fb->obj, ORIGIN_GTT);
mutex_unlock(&fb_helper->dev->struct_mutex);
@@ -106,13 +92,6 @@ static int intel_fbdev_pan_display(struct fb_var_screen
[Intel-gfx] [PATCH 3/3] drm: Remove __drm_modeset_lock_all
The last user is gone, no need for trylocking any more in this legacy
helper.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/drm_modeset_lock.c | 52 --
include/drm/drm_modeset_lock.h | 1 -
2 files changed, 11 insertions(+), 42 deletions(-)
diff --git a/drivers/gpu/drm/drm_modeset_lock.c
b/drivers/gpu/drm/drm_modeset_lock.c
index b4ddd1801642..9abee87c1501 100644
--- a/drivers/gpu/drm/drm_modeset_lock.c
+++ b/drivers/gpu/drm/drm_modeset_lock.c
@@ -53,41 +53,27 @@
* drm_modeset_acquire_fini(&ctx);
*/
-
/**
- * __drm_modeset_lock_all - internal helper to grab all modeset locks
- * @dev: DRM device
- * @trylock: trylock mode for atomic contexts
- *
- * This is a special version of drm_modeset_lock_all() which can also be used
in
- * atomic contexts. Then @trylock must be set to true.
+ * drm_modeset_lock_all - take all modeset locks
+ * @dev: drm device
*
- * Returns:
- * 0 on success or negative error code on failure.
+ * This function takes all modeset locks, suitable where a more fine-grained
+ * scheme isn't (yet) implemented. Locks must be dropped with
+ * drm_modeset_unlock_all.
*/
-int __drm_modeset_lock_all(struct drm_device *dev,
- bool trylock)
+void drm_modeset_lock_all(struct drm_device *dev)
{
struct drm_mode_config *config = &dev->mode_config;
struct drm_modeset_acquire_ctx *ctx;
int ret;
- ctx = kzalloc(sizeof(*ctx),
- trylock ? GFP_ATOMIC : GFP_KERNEL);
- if (!ctx)
- return -ENOMEM;
+ ctx = kzalloc(sizeof(*ctx), GFP_KERNEL);
+ if (WARN_ON(!ctx))
+ return;
- if (trylock) {
- if (!mutex_trylock(&config->mutex)) {
- ret = -EBUSY;
- goto out;
- }
- } else {
- mutex_lock(&config->mutex);
- }
+ mutex_lock(&config->mutex);
drm_modeset_acquire_init(ctx, 0);
- ctx->trylock_only = trylock;
retry:
ret = drm_modeset_lock(&config->connection_mutex, ctx);
@@ -106,7 +92,7 @@ retry:
drm_warn_on_modeset_not_all_locked(dev);
- return 0;
+ return;
fail:
if (ret == -EDEADLK) {
@@ -114,23 +100,7 @@ fail:
goto retry;
}
-out:
kfree(ctx);
- return ret;
-}
-EXPORT_SYMBOL(__drm_modeset_lock_all);
-
-/**
- * drm_modeset_lock_all - take all modeset locks
- * @dev: drm device
- *
- * This function takes all modeset locks, suitable where a more fine-grained
- * scheme isn't (yet) implemented. Locks must be dropped with
- * drm_modeset_unlock_all.
- */
-void drm_modeset_lock_all(struct drm_device *dev)
-{
- WARN_ON(__drm_modeset_lock_all(dev, false) != 0);
}
EXPORT_SYMBOL(drm_modeset_lock_all);
diff --git a/include/drm/drm_modeset_lock.h b/include/drm/drm_modeset_lock.h
index 70595ff565ba..5dd18bfdf601 100644
--- a/include/drm/drm_modeset_lock.h
+++ b/include/drm/drm_modeset_lock.h
@@ -130,7 +130,6 @@ struct drm_crtc;
struct drm_plane;
void drm_modeset_lock_all(struct drm_device *dev);
-int __drm_modeset_lock_all(struct drm_device *dev, bool trylock);
void drm_modeset_unlock_all(struct drm_device *dev);
void drm_modeset_lock_crtc(struct drm_crtc *crtc,
struct drm_plane *plane);
--
2.1.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 2/3] drm/fb-helper: Stop using trylocks in force_restore
Since the panic handling is gone this is only used for force-restoring
the fbdev/fbcon from sysrq, and that's done with a work item. No need
any more to do trylocks, we can just do normal locking.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/drm_fb_helper.c | 11 +--
1 file changed, 1 insertion(+), 10 deletions(-)
diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c
index 77f570a470da..a9043ab7f58b 100644
--- a/drivers/gpu/drm/drm_fb_helper.c
+++ b/drivers/gpu/drm/drm_fb_helper.c
@@ -416,19 +416,10 @@ static bool drm_fb_helper_force_kernel_mode(void)
if (dev->switch_power_state == DRM_SWITCH_POWER_OFF)
continue;
- /*
-* NOTE: Use trylock mode to avoid deadlocks and sleeping in
-* panic context.
-*/
- if (__drm_modeset_lock_all(dev, true) != 0) {
- error = true;
- continue;
- }
-
+ drm_modeset_lock_all(dev);
ret = drm_fb_helper_restore_fbdev_mode(helper);
if (ret)
error = true;
-
drm_modeset_unlock_all(dev);
}
return error;
--
2.1.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [drm-intel:topic/drm-misc 8/30] DockBook: Warning(drivers/gpu/drm/drm_fb_helper.c:772): No description found for parameter 'info'
On Tue, Jul 28, 2015 at 07:10:30PM +0800, kbuild test robot wrote: > tree: git://anongit.freedesktop.org/drm-intel topic/drm-misc > head: 109cd1d0fe187769f5e8ea414b9479b1c33b1d9f > commit: 9c4b750e97facd19749a44e0c8eeb9d2a78dd55f [8/30] drm/fb_helper: Create > wrappers for fb_sys_read/write funcs > reproduce: make htmldocs > > All warnings (new ones prefixed by >>): Archit can you please resend these patches with fixed-up kerneldoc? I'll exchange them in drm-misc. Thanks, Daniel > >Warning(drivers/gpu/drm/i915/i915_irq.c:484): No description found for > parameter 'dev' >Warning(drivers/gpu/drm/i915/i915_irq.c:2164): No description found for > parameter 'dev' >Warning(drivers/gpu/drm/i915/i915_irq.c:2344): No description found for > parameter 'wedged' >Warning(drivers/gpu/drm/i915/i915_irq.c:2344): No description found for > parameter 'fmt' >Warning(include/drm/drm_crtc.h:310): No description found for parameter > 'mode_blob' >Warning(include/drm/drm_crtc.h:750): No description found for parameter > 'tile_blob_ptr' >Warning(include/drm/drm_crtc.h:750): No description found for parameter > 'destroy_list' >Warning(include/drm/drm_crtc.h:789): No description found for parameter > 'rotation' >Warning(include/drm/drm_crtc.h:885): No description found for parameter > 'mutex' >Warning(include/drm/drm_crtc.h:885): No description found for parameter > 'helper_private' >Warning(include/drm/drm_crtc.h:933): Excess struct/union/enum/typedef > member 'base' description in 'drm_bridge' >Warning(include/drm/drm_crtc.h:1171): No description found for parameter > 'tile_idr' >Warning(include/drm/drm_crtc.h:1171): No description found for parameter > 'delayed_event' >Warning(include/drm/drm_crtc.h:1171): No description found for parameter > 'edid_property' >Warning(include/drm/drm_crtc.h:1171): No description found for parameter > 'dpms_property' >Warning(include/drm/drm_crtc.h:1171): No description found for parameter > 'path_property' >Warning(include/drm/drm_crtc.h:1171): No description found for parameter > 'tile_property' >Warning(include/drm/drm_crtc.h:1171): No description found for parameter > 'plane_type_property' >Warning(include/drm/drm_crtc.h:1171): No description found for parameter > 'rotation_property' >Warning(include/drm/drm_crtc.h:1171): No description found for parameter > 'prop_src_x' >Warning(include/drm/drm_crtc.h:1171): No description found for parameter > 'prop_src_y' >Warning(include/drm/drm_crtc.h:1171): No description found for parameter > 'prop_src_w' >Warning(include/drm/drm_crtc.h:1171): No description found for parameter > 'prop_src_h' >Warning(include/drm/drm_crtc.h:1171): No description found for parameter > 'prop_crtc_x' >Warning(include/drm/drm_crtc.h:1171): No description found for parameter > 'prop_crtc_y' >Warning(include/drm/drm_crtc.h:1171): No description found for parameter > 'prop_crtc_w' >Warning(include/drm/drm_crtc.h:1171): No description found for parameter > 'prop_crtc_h' >Warning(include/drm/drm_crtc.h:1171): No description found for parameter > 'prop_fb_id' >Warning(include/drm/drm_crtc.h:1171): No description found for parameter > 'prop_crtc_id' >Warning(include/drm/drm_crtc.h:1171): No description found for parameter > 'prop_active' >Warning(include/drm/drm_crtc.h:1171): No description found for parameter > 'prop_mode_id' >Warning(include/drm/drm_crtc.h:1171): No description found for parameter > 'dvi_i_subconnector_property' >Warning(include/drm/drm_crtc.h:1171): No description found for parameter > 'dvi_i_select_subconnector_property' >Warning(include/drm/drm_crtc.h:1171): No description found for parameter > 'tv_subconnector_property' >Warning(include/drm/drm_crtc.h:1171): No description found for parameter > 'tv_select_subconnector_property' >Warning(include/drm/drm_crtc.h:1171): No description found for parameter > 'tv_mode_property' >Warning(include/drm/drm_crtc.h:1171): No description found for parameter > 'tv_left_margin_property' >Warning(include/drm/drm_crtc.h:1171): No description found for parameter > 'tv_right_margin_property' >Warning(include/drm/drm_crtc.h:1171): No description found for parameter > 'tv_top_margin_property' >Warning(include/drm/drm_crtc.h:1171): No description found for parameter > 'tv_bottom_margin_property' >Warning(include/drm/drm_crtc.h:1171): No description found for parameter > 'tv_brightness_property' >Warning(include/drm/drm_crtc.h:1171): No description found for parameter > 'tv_contrast_property' >Warning(include/drm/drm_crtc.h:1171): No description found for parameter > 'tv_flicker_reduction_property' >Warning(include/drm/drm_crtc.h:1171): No description found for parameter > 'tv_overscan_property' >Warning(include/drm/drm_crtc.h:1171): No description found for parameter > 'tv_saturation_property' >
Re: [Intel-gfx] [PATCH 17/18] drm/i915/skl: Removed csr firmware load in resume path.
On Sunday 26 July 2015 12:30 AM, Animesh Manna wrote: As csr firmware is taking care of loading the firmware, so no need for driver to load again. Cc: Damien Lespiau Cc: Imre Deak Cc: Sunil Kamath Signed-off-by: Animesh Manna Signed-off-by: Vathsala Nagaraju --- drivers/gpu/drm/i915/i915_drv.c | 1 - 1 file changed, 1 deletion(-) diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c index 77b35fd..f5e720b 100644 --- a/drivers/gpu/drm/i915/i915_drv.c +++ b/drivers/gpu/drm/i915/i915_drv.c @@ -1048,7 +1048,6 @@ static int skl_resume_prepare(struct drm_i915_private *dev_priv) skl_disable_dc6(dev_priv); skl_init_cdclk(dev_priv); - intel_csr_load_program(dev_priv); The context save and restore program is reset on cold boot, warm reset, PCI function level reset, and hibernate/suspend. Will it not impact? - Sunil return 0; } ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Keep the mm.bound_list in rough LRU order
On Mon, Jul 27, 2015 at 10:26:26AM +0100, Chris Wilson wrote: > When we shrink our working sets, we want to avoid stealing pages from > objects that likely to be reused in the near future. We first look at > inactive objects before processing active objects - but what about a > recently active object that is about to be used again. That object's > position in the bound_list is ordered by the time of binding, not the > time of last use, so the most recently used inactive object could well > be at the head of the shrink list. To compensate, give the object a bump > to MRU when it becomes inactive (thus transitioning to the end of the > first pass in shrink lists). Conversely, bumping on inactive makes > bumping on active useless, since when we do have to reap from the active > working set, everything is going to become inactive very quickly and the > order pretty much random - just hope for the best at that point, as once > we start stalling on active objects, we can hope that the rebinding > neatly orders vital objects. > > Suggested-by: Daniel Vetter > Signed-off-by: Chris Wilson > Cc: Daniel Vetter Queued for -next, thanks for the patch and let's see what happens. We have a history of innocent list order changes uncovering interesting bugs ... -Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [drm-intel:topic/drm-misc 8/30] DockBook: Warning(drivers/gpu/drm/drm_fb_helper.c:772): No description found for parameter 'info'
On 07/28/2015 04:55 PM, Daniel Vetter wrote: On Tue, Jul 28, 2015 at 07:10:30PM +0800, kbuild test robot wrote: tree: git://anongit.freedesktop.org/drm-intel topic/drm-misc head: 109cd1d0fe187769f5e8ea414b9479b1c33b1d9f commit: 9c4b750e97facd19749a44e0c8eeb9d2a78dd55f [8/30] drm/fb_helper: Create wrappers for fb_sys_read/write funcs reproduce: make htmldocs All warnings (new ones prefixed by >>): Archit can you please resend these patches with fixed-up kerneldoc? I'll exchange them in drm-misc. Will do. Archit -- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 10/13 v4] drm/i915: Interrupt routing for GuC submission
On 27/07/15 16:33, O'Rourke, Tom wrote:
On Thu, Jul 09, 2015 at 07:29:11PM +0100, Dave Gordon wrote:
Turn on interrupt steering to route necessary interrupts to GuC.
v4:
Rebased
Issue: VIZ-4884
Signed-off-by: Alex Dai
Signed-off-by: Dave Gordon
---
drivers/gpu/drm/i915/i915_reg.h | 11 +--
drivers/gpu/drm/i915/intel_guc_loader.c | 51 +
2 files changed, 60 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 63728c1..1c2072b 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -1664,12 +1664,18 @@ enum skl_disp_power_wells {
#define GFX_MODE_GEN7 0x0229c
#define RING_MODE_GEN7(ring) ((ring)->mmio_base+0x29c)
#define GFX_RUN_LIST_ENABLE (1<<15)
+#define GFX_INTERRUPT_STEERING (1<<14)
#define GFX_TLB_INVALIDATE_EXPLICIT (1<<13)
#define GFX_SURFACE_FAULT_ENABLE(1<<12)
#define GFX_REPLAY_MODE (1<<11)
#define GFX_PSMI_GRANULARITY(1<<10)
#define GFX_PPGTT_ENABLE(1<<9)
+#define GFX_FORWARD_VBLANK_MASK (3<<5)
+#define GFX_FORWARD_VBLANK_NEVER (0<<5)
+#define GFX_FORWARD_VBLANK_ALWAYS(1<<5)
+#define GFX_FORWARD_VBLANK_COND (2<<5)
+
#define VLV_DISPLAY_BASE 0x18
#define VLV_MIPI_BASE VLV_DISPLAY_BASE
@@ -5683,11 +5689,12 @@ enum skl_disp_power_wells {
#define GEN8_GT_IIR(which) (0x44308 + (0x10 * (which)))
#define GEN8_GT_IER(which) (0x4430c + (0x10 * (which)))
-#define GEN8_BCS_IRQ_SHIFT 16
#define GEN8_RCS_IRQ_SHIFT 0
-#define GEN8_VCS2_IRQ_SHIFT 16
+#define GEN8_BCS_IRQ_SHIFT 16
#define GEN8_VCS1_IRQ_SHIFT 0
+#define GEN8_VCS2_IRQ_SHIFT 16
#define GEN8_VECS_IRQ_SHIFT 0
+#define GEN8_WD_IRQ_SHIFT 16
#define GEN8_DE_PIPE_ISR(pipe) (0x44400 + (0x10 * (pipe)))
#define GEN8_DE_PIPE_IMR(pipe) (0x44404 + (0x10 * (pipe)))
diff --git a/drivers/gpu/drm/i915/intel_guc_loader.c
b/drivers/gpu/drm/i915/intel_guc_loader.c
index 25ba29f..2aa9227 100644
--- a/drivers/gpu/drm/i915/intel_guc_loader.c
+++ b/drivers/gpu/drm/i915/intel_guc_loader.c
@@ -79,6 +79,53 @@ const char *intel_guc_fw_status_repr(enum
intel_guc_fw_status status)
}
};
+static void direct_interrupts_to_host(struct drm_i915_private *dev_priv)
+{
+ struct intel_engine_cs *ring;
+ int i, irqs;
+
+ /* tell all command streamers NOT to forward interrupts and vblank to
GuC */
+ irqs = _MASKED_FIELD(GFX_FORWARD_VBLANK_MASK, GFX_FORWARD_VBLANK_NEVER);
+ irqs |= _MASKED_BIT_DISABLE(GFX_INTERRUPT_STEERING);
+ for_each_ring(ring, dev_priv, i)
+ I915_WRITE(RING_MODE_GEN7(ring), irqs);
+
+ /* tell DE to send nothing to GuC */
+ I915_WRITE(DE_GUCRMR, ~0);
+
+ /* route all GT interrupts to the host */
+ I915_WRITE(GUC_BCS_RCS_IER, 0);
+ I915_WRITE(GUC_VCS2_VCS1_IER, 0);
+ I915_WRITE(GUC_WD_VECS_IER, 0);
+}
+
+static void direct_interrupts_to_guc(struct drm_i915_private *dev_priv)
+{
+ struct intel_engine_cs *ring;
+ int i, irqs;
+
+ /* tell all command streamers to forward interrupts and vblank to GuC */
+ irqs = _MASKED_FIELD(GFX_FORWARD_VBLANK_MASK,
GFX_FORWARD_VBLANK_ALWAYS);
+ irqs |= _MASKED_BIT_ENABLE(GFX_INTERRUPT_STEERING);
+ for_each_ring(ring, dev_priv, i)
+ I915_WRITE(RING_MODE_GEN7(ring), irqs);
+
+ /* tell DE to send (all) flip_done to GuC */
+ irqs = DERRMR_PIPEA_PRI_FLIP_DONE | DERRMR_PIPEA_SPR_FLIP_DONE |
+ DERRMR_PIPEB_PRI_FLIP_DONE | DERRMR_PIPEB_SPR_FLIP_DONE |
+ DERRMR_PIPEC_PRI_FLIP_DONE | DERRMR_PIPEC_SPR_FLIP_DONE;
+ /* Unmasked bits will cause GuC response message to be sent */
+ I915_WRITE(DE_GUCRMR, ~irqs);
+
+ /* route USER_INTERRUPT to Host, all others are sent to GuC. */
+ irqs = GT_RENDER_USER_INTERRUPT << GEN8_RCS_IRQ_SHIFT |
+ GT_RENDER_USER_INTERRUPT << GEN8_BCS_IRQ_SHIFT;
+ /* These three registers have the same bit definitions */
>> + I915_WRITE(GUC_BCS_RCS_IER, ~irqs);
>> + I915_WRITE(GUC_VCS2_VCS1_IER, ~irqs);
>> + I915_WRITE(GUC_WD_VECS_IER, ~irqs);
>> +}
>> +
>
[TOR:] Reliance on the registers having the same bit
definitions does not seem safe. Each of the three
registers has shift constants defined. I would expect
the shift constants for the second and third registers
to be used when writing those registers.
Also, GT_RENDER_USER_INTERRUPT seems to have been defined
for use with a different register than this set.
On the other hand, this code does actually write the
correct values.
The header file that defines GT_RENDER_USER_INTERRUPT,
GEN8_RCS_IRQ_SHIFT et al. contains this comment:
/* On modern GEN architectures interrupt control consists of two sets
* of registers. The first set pertains to the ring generating the
* interrupt. The second control is for the functional block generating
* the
[Intel-gfx] [drm-intel:topic/drm-misc 9/30] DockBook: Warning(drivers/gpu/drm/drm_fb_helper.c:798): No description found for parameter 'rect'
tree: git://anongit.freedesktop.org/drm-intel topic/drm-misc head: 109cd1d0fe187769f5e8ea414b9479b1c33b1d9f commit: be38e2b849aaa8cb223d807a4582fd666aefbd73 [9/30] drm/fb_helper: Create wrappers for blit, copyarea and fillrect funcs reproduce: make htmldocs All warnings (new ones prefixed by >>): Warning(drivers/gpu/drm/i915/i915_irq.c:484): No description found for parameter 'dev' Warning(drivers/gpu/drm/i915/i915_irq.c:2164): No description found for parameter 'dev' Warning(drivers/gpu/drm/i915/i915_irq.c:2344): No description found for parameter 'wedged' Warning(drivers/gpu/drm/i915/i915_irq.c:2344): No description found for parameter 'fmt' Warning(include/drm/drm_crtc.h:310): No description found for parameter 'mode_blob' Warning(include/drm/drm_crtc.h:750): No description found for parameter 'tile_blob_ptr' Warning(include/drm/drm_crtc.h:750): No description found for parameter 'destroy_list' Warning(include/drm/drm_crtc.h:789): No description found for parameter 'rotation' Warning(include/drm/drm_crtc.h:885): No description found for parameter 'mutex' Warning(include/drm/drm_crtc.h:885): No description found for parameter 'helper_private' Warning(include/drm/drm_crtc.h:933): Excess struct/union/enum/typedef member 'base' description in 'drm_bridge' Warning(include/drm/drm_crtc.h:1171): No description found for parameter 'tile_idr' Warning(include/drm/drm_crtc.h:1171): No description found for parameter 'delayed_event' Warning(include/drm/drm_crtc.h:1171): No description found for parameter 'edid_property' Warning(include/drm/drm_crtc.h:1171): No description found for parameter 'dpms_property' Warning(include/drm/drm_crtc.h:1171): No description found for parameter 'path_property' Warning(include/drm/drm_crtc.h:1171): No description found for parameter 'tile_property' Warning(include/drm/drm_crtc.h:1171): No description found for parameter 'plane_type_property' Warning(include/drm/drm_crtc.h:1171): No description found for parameter 'rotation_property' Warning(include/drm/drm_crtc.h:1171): No description found for parameter 'prop_src_x' Warning(include/drm/drm_crtc.h:1171): No description found for parameter 'prop_src_y' Warning(include/drm/drm_crtc.h:1171): No description found for parameter 'prop_src_w' Warning(include/drm/drm_crtc.h:1171): No description found for parameter 'prop_src_h' Warning(include/drm/drm_crtc.h:1171): No description found for parameter 'prop_crtc_x' Warning(include/drm/drm_crtc.h:1171): No description found for parameter 'prop_crtc_y' Warning(include/drm/drm_crtc.h:1171): No description found for parameter 'prop_crtc_w' Warning(include/drm/drm_crtc.h:1171): No description found for parameter 'prop_crtc_h' Warning(include/drm/drm_crtc.h:1171): No description found for parameter 'prop_fb_id' Warning(include/drm/drm_crtc.h:1171): No description found for parameter 'prop_crtc_id' Warning(include/drm/drm_crtc.h:1171): No description found for parameter 'prop_active' Warning(include/drm/drm_crtc.h:1171): No description found for parameter 'prop_mode_id' Warning(include/drm/drm_crtc.h:1171): No description found for parameter 'dvi_i_subconnector_property' Warning(include/drm/drm_crtc.h:1171): No description found for parameter 'dvi_i_select_subconnector_property' Warning(include/drm/drm_crtc.h:1171): No description found for parameter 'tv_subconnector_property' Warning(include/drm/drm_crtc.h:1171): No description found for parameter 'tv_select_subconnector_property' Warning(include/drm/drm_crtc.h:1171): No description found for parameter 'tv_mode_property' Warning(include/drm/drm_crtc.h:1171): No description found for parameter 'tv_left_margin_property' Warning(include/drm/drm_crtc.h:1171): No description found for parameter 'tv_right_margin_property' Warning(include/drm/drm_crtc.h:1171): No description found for parameter 'tv_top_margin_property' Warning(include/drm/drm_crtc.h:1171): No description found for parameter 'tv_bottom_margin_property' Warning(include/drm/drm_crtc.h:1171): No description found for parameter 'tv_brightness_property' Warning(include/drm/drm_crtc.h:1171): No description found for parameter 'tv_contrast_property' Warning(include/drm/drm_crtc.h:1171): No description found for parameter 'tv_flicker_reduction_property' Warning(include/drm/drm_crtc.h:1171): No description found for parameter 'tv_overscan_property' Warning(include/drm/drm_crtc.h:1171): No description found for parameter 'tv_saturation_property' Warning(include/drm/drm_crtc.h:1171): No description found for parameter 'tv_hue_property' Warning(include/drm/drm_crtc.h:1171): No description found for parameter 'scaling_mode_property' Warning(include/drm/drm_crtc.h:1171): No description found for parameter 'aspect_ratio_property' Warning(include/drm/drm_crtc.h:1171): No description found for parameter 'd
Re: [Intel-gfx] [PATCH] drm/i915: Fake AGP is dead
On Tue, Jul 28, 2015 at 01:43:11AM -0700, shuang...@intel.com wrote: > Tested-By: Intel Graphics QA PRTS (Patch Regression Test System Contact: > shuang...@intel.com) > Task id: 6873 > -Summary- > Platform Delta drm-intel-nightly Series Applied > ILK 297/297 297/297 > SNB 315/315 315/315 > IVB 342/342 342/342 > BYT -1 284/284 283/284 > HSW 378/378 378/378 > -Detailed- > Platform Testdrm-intel-nightly > Series Applied > *BYT igt@gem_partial_pwrite_pread@reads PASS(1) FAIL(1) > Note: You need to pay more attention to line start with '*' The original message went astry, but I read through it on patchwork and it really is just dead code elimination. Reviewed-by: Chris Wilson I felt the changelog was a little vague (I didn't understand the "really no users left" comment), so I wouldn't mind if you tighten it up a bit! -Chris -- Chris Wilson, Intel Open Source Technology Centre ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [drm-intel:topic/drm-misc 10/30] DockBook: Warning(drivers/gpu/drm/drm_fb_helper.c:875): No description found for parameter 'state'
tree: git://anongit.freedesktop.org/drm-intel topic/drm-misc head: 109cd1d0fe187769f5e8ea414b9479b1c33b1d9f commit: 97db4bc61cd0f862e0fd2bc13e7f87d82a2529ef [10/30] drm/fb_helper: Create a wrapper for fb_set_suspend reproduce: make htmldocs All warnings (new ones prefixed by >>): Warning(drivers/gpu/drm/i915/i915_irq.c:484): No description found for parameter 'dev' Warning(drivers/gpu/drm/i915/i915_irq.c:2164): No description found for parameter 'dev' Warning(drivers/gpu/drm/i915/i915_irq.c:2344): No description found for parameter 'wedged' Warning(drivers/gpu/drm/i915/i915_irq.c:2344): No description found for parameter 'fmt' Warning(include/drm/drm_crtc.h:310): No description found for parameter 'mode_blob' Warning(include/drm/drm_crtc.h:750): No description found for parameter 'tile_blob_ptr' Warning(include/drm/drm_crtc.h:750): No description found for parameter 'destroy_list' Warning(include/drm/drm_crtc.h:789): No description found for parameter 'rotation' Warning(include/drm/drm_crtc.h:885): No description found for parameter 'mutex' Warning(include/drm/drm_crtc.h:885): No description found for parameter 'helper_private' Warning(include/drm/drm_crtc.h:933): Excess struct/union/enum/typedef member 'base' description in 'drm_bridge' Warning(include/drm/drm_crtc.h:1171): No description found for parameter 'tile_idr' Warning(include/drm/drm_crtc.h:1171): No description found for parameter 'delayed_event' Warning(include/drm/drm_crtc.h:1171): No description found for parameter 'edid_property' Warning(include/drm/drm_crtc.h:1171): No description found for parameter 'dpms_property' Warning(include/drm/drm_crtc.h:1171): No description found for parameter 'path_property' Warning(include/drm/drm_crtc.h:1171): No description found for parameter 'tile_property' Warning(include/drm/drm_crtc.h:1171): No description found for parameter 'plane_type_property' Warning(include/drm/drm_crtc.h:1171): No description found for parameter 'rotation_property' Warning(include/drm/drm_crtc.h:1171): No description found for parameter 'prop_src_x' Warning(include/drm/drm_crtc.h:1171): No description found for parameter 'prop_src_y' Warning(include/drm/drm_crtc.h:1171): No description found for parameter 'prop_src_w' Warning(include/drm/drm_crtc.h:1171): No description found for parameter 'prop_src_h' Warning(include/drm/drm_crtc.h:1171): No description found for parameter 'prop_crtc_x' Warning(include/drm/drm_crtc.h:1171): No description found for parameter 'prop_crtc_y' Warning(include/drm/drm_crtc.h:1171): No description found for parameter 'prop_crtc_w' Warning(include/drm/drm_crtc.h:1171): No description found for parameter 'prop_crtc_h' Warning(include/drm/drm_crtc.h:1171): No description found for parameter 'prop_fb_id' Warning(include/drm/drm_crtc.h:1171): No description found for parameter 'prop_crtc_id' Warning(include/drm/drm_crtc.h:1171): No description found for parameter 'prop_active' Warning(include/drm/drm_crtc.h:1171): No description found for parameter 'prop_mode_id' Warning(include/drm/drm_crtc.h:1171): No description found for parameter 'dvi_i_subconnector_property' Warning(include/drm/drm_crtc.h:1171): No description found for parameter 'dvi_i_select_subconnector_property' Warning(include/drm/drm_crtc.h:1171): No description found for parameter 'tv_subconnector_property' Warning(include/drm/drm_crtc.h:1171): No description found for parameter 'tv_select_subconnector_property' Warning(include/drm/drm_crtc.h:1171): No description found for parameter 'tv_mode_property' Warning(include/drm/drm_crtc.h:1171): No description found for parameter 'tv_left_margin_property' Warning(include/drm/drm_crtc.h:1171): No description found for parameter 'tv_right_margin_property' Warning(include/drm/drm_crtc.h:1171): No description found for parameter 'tv_top_margin_property' Warning(include/drm/drm_crtc.h:1171): No description found for parameter 'tv_bottom_margin_property' Warning(include/drm/drm_crtc.h:1171): No description found for parameter 'tv_brightness_property' Warning(include/drm/drm_crtc.h:1171): No description found for parameter 'tv_contrast_property' Warning(include/drm/drm_crtc.h:1171): No description found for parameter 'tv_flicker_reduction_property' Warning(include/drm/drm_crtc.h:1171): No description found for parameter 'tv_overscan_property' Warning(include/drm/drm_crtc.h:1171): No description found for parameter 'tv_saturation_property' Warning(include/drm/drm_crtc.h:1171): No description found for parameter 'tv_hue_property' Warning(include/drm/drm_crtc.h:1171): No description found for parameter 'scaling_mode_property' Warning(include/drm/drm_crtc.h:1171): No description found for parameter 'aspect_ratio_property' Warning(include/drm/drm_crtc.h:1171): No description found for parameter 'dirty_info_propert
Re: [Intel-gfx] [PATCH v2 02/12] drm/i915: Update atomic state when removing mst connector.
Reviewed-by: Ander Conselvan de Oliveira
On Mon, 2015-07-27 at 14:35 +0200, Maarten Lankhorst wrote:
> Signed-off-by: Maarten Lankhorst
> ---
> drivers/gpu/drm/i915/intel_display.c | 7 --
> drivers/gpu/drm/i915/intel_dp_mst.c | 45
> +++-
> 2 files changed, 44 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_display.c
> b/drivers/gpu/drm/i915/intel_display.c
> index 7747520bf9f6..3ab0a8a8e702 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -12751,13 +12751,6 @@ check_encoder_state(struct drm_device *dev)
> encoder->base.crtc,
>"connector's crtc doesn't match encoder
> crtc\n");
> }
> - /*
> - * for MST connectors if we unplug the connector is
> gone
> - * away but the encoder is still connected to a crtc
> - * until a modeset happens in response to the
> hotplug.
> - */
> - if (!enabled && encoder->base.encoder_type ==
> DRM_MODE_ENCODER_DPMST)
> - continue;
>
> I915_STATE_WARN(!!encoder->base.crtc != enabled,
>"encoder's enabled state mismatch "
> diff --git a/drivers/gpu/drm/i915/intel_dp_mst.c
> b/drivers/gpu/drm/i915/intel_dp_mst.c
> index 585f0a45b3f1..35f2eb59818a 100644
> --- a/drivers/gpu/drm/i915/intel_dp_mst.c
> +++ b/drivers/gpu/drm/i915/intel_dp_mst.c
> @@ -448,6 +448,49 @@ static struct drm_connector
> *intel_dp_add_mst_connector(struct drm_dp_mst_topolo
> return connector;
> }
>
> +static void
> +intel_dp_unbind_mst_connector(struct drm_device *dev,
> + struct drm_connector *connector)
> +{
> + struct drm_atomic_state *state;
> + struct drm_connector_state *conn_state;
> + struct drm_crtc *crtc = connector->state->crtc;
> + int ret;
> +
> + if (!crtc)
> + return;
> +
> + state = drm_atomic_state_alloc(dev);
> + if (!state)
> + return;
> +
> + state->acquire_ctx = dev->mode_config.acquire_ctx;
> +
> + conn_state = drm_atomic_get_connector_state(state,
> connector);
> + ret = PTR_ERR_OR_ZERO(conn_state);
> + if (!ret)
> + ret = drm_atomic_set_crtc_for_connector(conn_state,
> NULL);
> +
> + if (!ret)
> + ret = drm_atomic_add_affected_connectors(state,
> crtc);
> +
> + if (!ret && !drm_atomic_connectors_for_crtc(state, crtc)) {
> + struct drm_crtc_state *crtc_state =
> + drm_atomic_get_existing_crtc_state(state,
> crtc);
> +
> + crtc_state->active = false;
> + ret = drm_atomic_set_mode_for_crtc(crtc_state,
> NULL);
> + }
> +
> + if (!ret)
> + ret = drm_atomic_commit(state);
> +
> + if (ret)
> + drm_atomic_state_free(state);
> +
> + I915_STATE_WARN_ON(ret);
> +}
> +
> static void intel_dp_destroy_mst_connector(struct
> drm_dp_mst_topology_mgr *mgr,
> struct drm_connector
> *connector)
> {
> @@ -455,7 +498,7 @@ static void intel_dp_destroy_mst_connector(struct
> drm_dp_mst_topology_mgr *mgr,
> struct drm_device *dev = connector->dev;
> /* need to nuke the connector */
> drm_modeset_lock_all(dev);
> - intel_connector_dpms(connector, DRM_MODE_DPMS_OFF);
> + intel_dp_unbind_mst_connector(dev, connector);
> drm_modeset_unlock_all(dev);
>
> intel_connector->unregister(intel_connector);
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [drm-intel:topic/drm-misc 11/30] DockBook: Warning(drivers/gpu/drm/drm_fb_helper.c:891): No description found for parameter 'a'
tree: git://anongit.freedesktop.org/drm-intel topic/drm-misc head: 109cd1d0fe187769f5e8ea414b9479b1c33b1d9f commit: 3a28c82f569178f2cb96fae03841fc9d71416fa7 [11/30] drm/fb_helper: Create a wrapper for remove_conflicting_framebuffers reproduce: make htmldocs All warnings (new ones prefixed by >>): Warning(drivers/gpu/drm/i915/i915_irq.c:484): No description found for parameter 'dev' Warning(drivers/gpu/drm/i915/i915_irq.c:2164): No description found for parameter 'dev' Warning(drivers/gpu/drm/i915/i915_irq.c:2344): No description found for parameter 'wedged' Warning(drivers/gpu/drm/i915/i915_irq.c:2344): No description found for parameter 'fmt' Warning(include/drm/drm_crtc.h:310): No description found for parameter 'mode_blob' Warning(include/drm/drm_crtc.h:750): No description found for parameter 'tile_blob_ptr' Warning(include/drm/drm_crtc.h:750): No description found for parameter 'destroy_list' Warning(include/drm/drm_crtc.h:789): No description found for parameter 'rotation' Warning(include/drm/drm_crtc.h:885): No description found for parameter 'mutex' Warning(include/drm/drm_crtc.h:885): No description found for parameter 'helper_private' Warning(include/drm/drm_crtc.h:933): Excess struct/union/enum/typedef member 'base' description in 'drm_bridge' Warning(include/drm/drm_crtc.h:1171): No description found for parameter 'tile_idr' Warning(include/drm/drm_crtc.h:1171): No description found for parameter 'delayed_event' Warning(include/drm/drm_crtc.h:1171): No description found for parameter 'edid_property' Warning(include/drm/drm_crtc.h:1171): No description found for parameter 'dpms_property' Warning(include/drm/drm_crtc.h:1171): No description found for parameter 'path_property' Warning(include/drm/drm_crtc.h:1171): No description found for parameter 'tile_property' Warning(include/drm/drm_crtc.h:1171): No description found for parameter 'plane_type_property' Warning(include/drm/drm_crtc.h:1171): No description found for parameter 'rotation_property' Warning(include/drm/drm_crtc.h:1171): No description found for parameter 'prop_src_x' Warning(include/drm/drm_crtc.h:1171): No description found for parameter 'prop_src_y' Warning(include/drm/drm_crtc.h:1171): No description found for parameter 'prop_src_w' Warning(include/drm/drm_crtc.h:1171): No description found for parameter 'prop_src_h' Warning(include/drm/drm_crtc.h:1171): No description found for parameter 'prop_crtc_x' Warning(include/drm/drm_crtc.h:1171): No description found for parameter 'prop_crtc_y' Warning(include/drm/drm_crtc.h:1171): No description found for parameter 'prop_crtc_w' Warning(include/drm/drm_crtc.h:1171): No description found for parameter 'prop_crtc_h' Warning(include/drm/drm_crtc.h:1171): No description found for parameter 'prop_fb_id' Warning(include/drm/drm_crtc.h:1171): No description found for parameter 'prop_crtc_id' Warning(include/drm/drm_crtc.h:1171): No description found for parameter 'prop_active' Warning(include/drm/drm_crtc.h:1171): No description found for parameter 'prop_mode_id' Warning(include/drm/drm_crtc.h:1171): No description found for parameter 'dvi_i_subconnector_property' Warning(include/drm/drm_crtc.h:1171): No description found for parameter 'dvi_i_select_subconnector_property' Warning(include/drm/drm_crtc.h:1171): No description found for parameter 'tv_subconnector_property' Warning(include/drm/drm_crtc.h:1171): No description found for parameter 'tv_select_subconnector_property' Warning(include/drm/drm_crtc.h:1171): No description found for parameter 'tv_mode_property' Warning(include/drm/drm_crtc.h:1171): No description found for parameter 'tv_left_margin_property' Warning(include/drm/drm_crtc.h:1171): No description found for parameter 'tv_right_margin_property' Warning(include/drm/drm_crtc.h:1171): No description found for parameter 'tv_top_margin_property' Warning(include/drm/drm_crtc.h:1171): No description found for parameter 'tv_bottom_margin_property' Warning(include/drm/drm_crtc.h:1171): No description found for parameter 'tv_brightness_property' Warning(include/drm/drm_crtc.h:1171): No description found for parameter 'tv_contrast_property' Warning(include/drm/drm_crtc.h:1171): No description found for parameter 'tv_flicker_reduction_property' Warning(include/drm/drm_crtc.h:1171): No description found for parameter 'tv_overscan_property' Warning(include/drm/drm_crtc.h:1171): No description found for parameter 'tv_saturation_property' Warning(include/drm/drm_crtc.h:1171): No description found for parameter 'tv_hue_property' Warning(include/drm/drm_crtc.h:1171): No description found for parameter 'scaling_mode_property' Warning(include/drm/drm_crtc.h:1171): No description found for parameter 'aspect_ratio_property' Warning(include/drm/drm_crtc.h:1171): No description found for parameter 'd
Re: [Intel-gfx] [PATCH v5 00/19] 48-bit PPGTT
On Thu, Jul 16, 2015 at 10:33:12AM +0100, Michel Thierry wrote: > This clean-up version delays the 48-bit work to later patches and includes > other review comments from Akash and Chris Wilson. The first 4 patches > prepare the dynamic page allocation code to handle independent pdps, but > no specific code for 48-bit mode is added before the 5th patch. > > In order expand the GPU address space, a 4th level translation is added, > the Page Map Level 4 (PML4). This PML4 has 512 PML4 Entries (PML4E), > PML4[0-511], each pointing to a PDP. All the existing "dynamic alloc > ppgtt" functions are used, only adding the 4th level changes. I also > updated some remaining variables that were 32b only. > > There are 2 hardware workarounds needed to allow correct operation with > 48b addresses (Wa32bitGeneralStateOffset & Wa32bitInstructionBaseOffset). > This new patchset version includes the comments and suggestions from Chris > Wilson. A flag (EXEC_OBJECT_SUPPORTS_48B_ADDRESS) will indicate if a given > object can be allocated outside the first 4 PDPs; if not, the end range is > forced to 4GB. Also, more objects now use the DRM_MM_CREATE_TOP flag. To > maintain compatibility, in libdrm I added a new drm_intel_bo_emit_reloc_48bit > function that will flag these objects, while the existing > drm_intel_bo_emit_reloc > clears it. > > Finally, this feature is only available in BDW and Gen9, requires LRC > submission mode (execlists) and it can be detected by i915.enable_ppgtt=3. > > Also note that this expanded address space is only available for full > PPGTT, aliasing PPGTT and Global GTT remain 32-bit. A test I just thought of is to extend gem_evict_alignment to iterate over for (align = 1<<12; align < 1<<48; align <<= 1) exec(obj.align=align) i.e. basically force the kernel to place the object in every power-of-two zone. The idea here is to exercise and allocate as much of the 4-level page table handling code as is trivially possible (to work on extents tracking you could leave each level in place. Now this is starting to feel more like a gem_ppgtt test). Using softpin we would move control over exercising every boundary in the code (but then requires softpin). Also noticed that constructing the bitmaps for va_alloc_range tracking was very expensive, even in the trivial no-op case (rebinding to the same location). A benchmark to measure that allocation overhead would be very useful. For that I think a synthetic like using softpin to move an object through the entire address space or even flip between two locations would do the job. -Chris -- Chris Wilson, Intel Open Source Technology Centre ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2 03/12] drm/i915: Convert connector checking to atomic.
On Mon, 2015-07-27 at 14:35 +0200, Maarten Lankhorst wrote:
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/i915/intel_crt.c | 2 -
drivers/gpu/drm/i915/intel_display.c | 79
drivers/gpu/drm/i915/intel_drv.h | 1 -
drivers/gpu/drm/i915/intel_dvo.c | 2 -
drivers/gpu/drm/i915/intel_sdvo.c| 2 -
5 files changed, 36 insertions(+), 50 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_crt.c b/drivers/gpu/drm/i915/intel_crt.c
index 5d78c1feec81..9eba3dd5b434 100644
--- a/drivers/gpu/drm/i915/intel_crt.c
+++ b/drivers/gpu/drm/i915/intel_crt.c
@@ -280,8 +280,6 @@ static int intel_crt_dpms(struct drm_connector *connector,
int mode)
intel_crtc_update_dpms(crtc);
}
- intel_modeset_check_state(connector->dev);
-
return 0;
}
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 3ab0a8a8e702..ba0b68a4209d 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -6360,42 +6360,33 @@ static void intel_encoder_dpms(struct intel_encoder
*encoder, int mode)
* internal consistency). */
static void intel_connector_check_state(struct intel_connector *connector)
{
+ struct drm_crtc *crtc = connector->base.state->crtc;
+
+ DRM_DEBUG_KMS("[CONNECTOR:%d:%s]\n",
+ connector->base.base.id,
+ connector->base.name);
+
if (connector->get_hw_state(connector)) {
- struct intel_encoder *encoder = connector->encoder;
- struct drm_crtc *crtc;
- bool encoder_enabled;
- enum pipe pipe;
+ struct drm_encoder *encoder = &connector->encoder->base;
+ struct drm_connector_state *conn_state = connector->base.state;
- DRM_DEBUG_KMS("[CONNECTOR:%d:%s]\n",
- connector->base.base.id,
- connector->base.name);
+ I915_STATE_WARN(!crtc,
+"connector enabled without attached crtc\n");
- /* there is no real hw state for MST connectors */
- if (connector->mst_port)
Should the above deletion be part of the previous patch?
> + if (!crtc)
return;
- I915_STATE_WARN(connector->base.dpms == DRM_MODE_DPMS_OFF,
-"wrong connector dpms state\n");
- I915_STATE_WARN(connector->base.encoder != &encoder->base,
-"active connector not linked to encoder\n");
+ I915_STATE_WARN(!crtc->state->active,
+ "connector is active, but attached crtc isn't\n");
- if (encoder) {
- I915_STATE_WARN(!encoder->connectors_active,
-"encoder->connectors_active not set\n");
The converted version doesn't check connectors_active. I see it is
later removed in the patch series, so I assume it is left out on
purpose, but I think this is worth mentioning in the commit message.
> -
- encoder_enabled = encoder->get_hw_state(encoder, &pipe);
- I915_STATE_WARN(!encoder_enabled, "encoder not
enabled\n");
- if (I915_STATE_WARN_ON(!encoder->base.crtc))
- return;
These are also left out. It looks like check_encoder_state() performs
the same check, but I think the commit message should mention this if
that's the case.
> + I915_STATE_WARN(conn_state->best_encoder != encoder,
+ "atomic encoder doesn't match attached encoder\n");
- crtc = encoder->base.crtc;
-
- I915_STATE_WARN(!crtc->state->enable,
- "crtc not enabled\n");
- I915_STATE_WARN(!to_intel_crtc(crtc)->active, "crtc not
active\n");
- I915_STATE_WARN(pipe != to_intel_crtc(crtc)->pipe,
-"encoder active on the wrong pipe\n");
- }
+ I915_STATE_WARN(conn_state->crtc != encoder->crtc,
+ "attached encoder crtc differs from connector crtc\n");
+ } else {
+ I915_STATE_WARN(!crtc && connector->base.state->best_encoder,
+ "best encoder set without crtc!\n");
}
}
@@ -6444,8 +6435,6 @@ int intel_connector_dpms(struct drm_connector *connector,
int mode)
if (connector->encoder)
intel_encoder_dpms(to_intel_encoder(connector->encoder), mode);
- intel_modeset_check_state(connector->dev);
-
return 0;
}
@@ -12705,20 +12694,22 @@ static void check_wm_state(struct drm_device *dev)
}
static void
-check_connector_state(struct drm_device *dev)
+check_connector_state(struct drm_device *dev, struct drm_atomic_state *state)
This is called after a state swap, so I think t
[Intel-gfx] [PATCH] drm: Add DRM_NOTICE_IF
Styled after WARN_ON/DRM_ERROR_ON, this prints a mild warning message (a
KERN_NOTICE for significant but mild events) that allows us to insert
interesting events without alarming the user or bug reporting tools.
For an example I have changed a DRM_ERROR for being unable to set a
performance enhancement in i915.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/intel_lrc.c | 5 ++---
include/drm/drmP.h | 20
2 files changed, 22 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
index 184d5f2dce21..f62cd78f8691 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -1902,13 +1902,12 @@ static int gen8_init_rcs_context(struct
drm_i915_gem_request *req)
if (ret)
return ret;
- ret = intel_rcs_context_init_mocs(req);
/*
* Failing to program the MOCS is non-fatal.The system will not
* run at peak performance. So generate an error and carry on.
*/
- if (ret)
- DRM_ERROR("MOCS failed to program: expect performance
issues.\n");
+ DRM_NOTICE_IF(intel_rcs_context_init_mocs(req),
+ "MOCS failed to program: expect performance issues.\n");
return intel_lr_context_render_state_init(req);
}
diff --git a/include/drm/drmP.h b/include/drm/drmP.h
index b76af322d812..f2d68d185274 100644
--- a/include/drm/drmP.h
+++ b/include/drm/drmP.h
@@ -181,6 +181,26 @@ void drm_err(const char *format, ...);
})
/**
+ * Mild warning on assertion-esque failure.
+ *
+ * \param cond condition on which to *fail*
+ * \param fmt printf() like format string.
+ * \param arg arguments
+ *
+ * This is similar to WARN_ON but only prints a NOTICE rather than a warning
+ * and the whole stacktrace. It is only intended for mild issues which
+ * while significant do not critically impact the user (such as a performance
+ * issue).
+ */
+#define DRM_NOTICE_IF(cond, fmt, ...) ({ \
+ bool __cond = !!(cond); \
+ if (unlikely(__cond)) \
+ printk(KERN_NOTICE "[" DRM_NAME ":%s] " fmt,\
+ __func__, ##__VA_ARGS__);\
+ unlikely(__cond); \
+})
+
+/**
* Rate limited error output. Like DRM_ERROR() but won't flood the log.
*
* \param fmt printf() like format string.
--
2.4.6
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 2/2] drm/i915: Soften error messages in i915_gem_object_create_from_data()
Since we already return -EFAULT to the user, emitting an error message
*and* WARN is overkill. If the caller is upset, they can do so, but for
the purposes of debugging we need only log the erroneous values.
Signed-off-by: Chris Wilson
Cc:: Alex Dai
Cc: Dave Gordon
Cc: Tom O'Rourke
---
drivers/gpu/drm/i915/i915_gem.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index c1ded76a6eb4..2039798f4403 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -5243,8 +5243,8 @@ i915_gem_object_create_from_data(struct drm_device *dev,
i915_gem_object_unpin_pages(obj);
- if (WARN_ON(bytes != size)) {
- DRM_ERROR("Incomplete copy, wrote %zu of %zu", bytes, size);
+ if (bytes != size) {
+ DRM_DEBUG_GEM("Incomplete copy, wrote %zu of %zu", bytes, size);
ret = -EFAULT;
goto fail;
}
--
2.4.6
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 1/2] drm: Add DRM_DEBUG_GEM
Add a new debug value to distinguish and filter upon debug messages
emanating from GEM support code.
Signed-off-by: Chris Wilson
---
include/drm/drmP.h | 15 +--
1 file changed, 13 insertions(+), 2 deletions(-)
diff --git a/include/drm/drmP.h b/include/drm/drmP.h
index f2d68d185274..e7b58e37c583 100644
--- a/include/drm/drmP.h
+++ b/include/drm/drmP.h
@@ -107,6 +107,11 @@ struct dma_buf_attachment;
* ATOMIC: used in the atomic code.
* This is the category used by the DRM_DEBUG_ATOMIC() macro.
*
+ * GEM: used by portions of code backing the GEM interface, both in the
+ * core (e.g. drm_gem.c) and vendor specific code.
+ * This is the category used by the DRM_DEBUG_GEM() macro.
+ *
+ *
* Enabling verbose debug messages is done through the drm.debug parameter,
* each category being enabled by a bit.
*
@@ -114,17 +119,18 @@ struct dma_buf_attachment;
* drm.debug=0x2 will enable DRIVER messages
* drm.debug=0x3 will enable CORE and DRIVER messages
* ...
- * drm.debug=0xf will enable all messages
+ * drm.debug=0xff will enable all messages
*
* An interesting feature is that it's possible to enable verbose logging at
* run-time by echoing the debug value in its sysfs node:
- * # echo 0xf > /sys/module/drm/parameters/debug
+ * # echo 0xff > /sys/module/drm/parameters/debug
*/
#define DRM_UT_CORE0x01
#define DRM_UT_DRIVER 0x02
#define DRM_UT_KMS 0x04
#define DRM_UT_PRIME 0x08
#define DRM_UT_ATOMIC 0x10
+#define DRM_UT_GEM 0x20
extern __printf(2, 3)
void drm_ut_debug_printk(const char *function_name,
@@ -254,6 +260,11 @@ void drm_err(const char *format, ...);
if (unlikely(drm_debug & DRM_UT_ATOMIC))\
drm_ut_debug_printk(__func__, fmt, ##args); \
} while (0)
+#define DRM_DEBUG_GEM(fmt, args...)\
+ do {\
+ if (unlikely(drm_debug & DRM_UT_GEM)) \
+ drm_ut_debug_printk(__func__, fmt, ##args); \
+ } while (0)
/*@}*/
--
2.4.6
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2 04/12] drm/i915: Remove some unneeded checks from check_crtc_state.
Reviewed-by: Ander Conselvan de Oliveira
On Mon, 2015-07-27 at 14:35 +0200, Maarten Lankhorst wrote:
> This is handled by the atomic core now, no need to check this for
> ourself.
>
> Signed-off-by: Maarten Lankhorst
> ---
> drivers/gpu/drm/i915/intel_display.c | 19 +--
> 1 file changed, 1 insertion(+), 18 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_display.c
> b/drivers/gpu/drm/i915/intel_display.c
> index ba0b68a4209d..59eb6db10740 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -12781,8 +12781,7 @@ check_crtc_state(struct drm_device *dev)
> struct intel_crtc_state pipe_config;
>
> for_each_intel_crtc(dev, crtc) {
> - bool enabled = false;
> - bool active = false;
> + bool active;
>
> memset(&pipe_config, 0, sizeof(pipe_config));
>
> @@ -12792,22 +12791,6 @@ check_crtc_state(struct drm_device *dev)
> I915_STATE_WARN(crtc->active && !crtc->base.state
> ->enable,
>"active crtc, but not enabled in sw
> tracking\n");
>
> - for_each_intel_encoder(dev, encoder) {
> - if (encoder->base.crtc != &crtc->base)
> - continue;
> - enabled = true;
> - if (encoder->connectors_active)
> - active = true;
> - }
> -
> - I915_STATE_WARN(active != crtc->active,
> - "crtc's computed active state doesn't match
> tracked active state "
> - "(expected %i, found %i)\n", active, crtc
> ->active);
> - I915_STATE_WARN(enabled != crtc->base.state->enable,
> - "crtc's computed enabled state doesn't match
> tracked enabled state "
> - "(expected %i, found %i)\n", enabled,
> - crtc->base.state->enable);
> -
> active = dev_priv->display.get_pipe_config(crtc,
>
> &pipe_config);
>
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915: Assert that we hold struct_mutex in i915_gem_object_create_from_data()
Unlike the other i915_gem_object create functions, _from_data() requires the struct_mutex as it also allocates the backing storage and so interacts with the common lists. Document this requirement. Signed-off-by: Chris Wilson --- drivers/gpu/drm/i915/i915_gem.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c index 2039798f4403..2bf139396660 100644 --- a/drivers/gpu/drm/i915/i915_gem.c +++ b/drivers/gpu/drm/i915/i915_gem.c @@ -5226,6 +5226,8 @@ i915_gem_object_create_from_data(struct drm_device *dev, size_t bytes; int ret; + lockdep_assert_held(&dev->struct_mutex); + obj = i915_gem_alloc_object(dev, PAGE_ALIGN(size)); if (IS_ERR_OR_NULL(obj)) return obj; -- 2.4.6 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2 05/12] drm/i915: Remove connectors_active from state checking.
Reviewed-by: Ander Conselvan de Oliveira
On Mon, 2015-07-27 at 14:35 +0200, Maarten Lankhorst wrote:
> Connectors are updated atomically now, so the only interaction
> with the encoder is through base.crtc.
>
> If it's NULL the encoder's not part of any crtc, and if it's
> not NULL then active should be equal to crtc_state->active.
>
> Signed-off-by: Maarten Lankhorst
> ---
> drivers/gpu/drm/i915/intel_display.c | 21 ++---
> 1 file changed, 10 insertions(+), 11 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_display.c
> b/drivers/gpu/drm/i915/intel_display.c
> index 59eb6db10740..fbb257d4728c 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -12728,9 +12728,6 @@ check_encoder_state(struct drm_device *dev)
> encoder->base.base.id,
> encoder->base.name);
>
> - I915_STATE_WARN(encoder->connectors_active &&
> !encoder->base.crtc,
> - "encoder's active_connectors set, but no
> crtc\n");
> -
> for_each_intel_connector(dev, connector) {
> if (connector->base.encoder != &encoder
> ->base)
> continue;
> @@ -12750,18 +12747,20 @@ check_encoder_state(struct drm_device *dev)
> I915_STATE_WARN(active && !encoder->base.crtc,
>"active encoder with no crtc\n");
>
> - I915_STATE_WARN(encoder->connectors_active !=
> active,
> - "encoder's computed active state doesn't match
> tracked active state "
> - "(expected %i, found %i)\n", active, encoder
> ->connectors_active);
> -
> active = encoder->get_hw_state(encoder, &pipe);
> - I915_STATE_WARN(active != encoder
> ->connectors_active,
> +
> + if (!encoder->base.crtc) {
> + I915_STATE_WARN(active,
> + "encoder detached but not turned
> off.\n");
> +
> + continue;
> + }
> +
> + I915_STATE_WARN(active != encoder->base.crtc->state
> ->active,
>"encoder's hw state doesn't match sw tracking "
>"(expected %i, found %i)\n",
> - encoder->connectors_active, active);
> + encoder->base.crtc->state->active, active);
>
> - if (!encoder->base.crtc)
> - continue;
>
> tracked_pipe = to_intel_crtc(encoder->base.crtc)
> ->pipe;
> I915_STATE_WARN(active && pipe != tracked_pipe,
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Replace WARN inside I915_READ64_2x32 with retry loop
On Wed, Jul 15, 2015 at 09:50:42AM +0100, Chris Wilson wrote:
> Since we may conceivably encounter situations where the upper part of the
> 64bit register changes between reads, for example when a timestamp
> counter overflows, change the WARN into a retry loop.
>
> Signed-off-by: Chris Wilson
> Cc: Michał Winiarski
Michał, as you correctly predicted this WARN will be hit in the wild
after adjusting reg_read_ioctl(TIMESTAMP).
Anyone care to review this patch?
> ---
> drivers/gpu/drm/i915/i915_drv.h | 17 -
> 1 file changed, 8 insertions(+), 9 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index ee53873ab252..cfddd69bd06c 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -3484,15 +3484,14 @@ int intel_freq_opcode(struct drm_i915_private
> *dev_priv, int val);
> #define I915_READ64(reg) dev_priv->uncore.funcs.mmio_readq(dev_priv,
> (reg), true)
>
> #define I915_READ64_2x32(lower_reg, upper_reg) ({\
> - u32 upper = I915_READ(upper_reg); \
> - u32 lower = I915_READ(lower_reg); \
> - u32 tmp = I915_READ(upper_reg); \
> - if (upper != tmp) { \
> - upper = tmp;\
> - lower = I915_READ(lower_reg); \
> - WARN_ON(I915_READ(upper_reg) != upper); \
> - } \
> - (u64)upper << 32 | lower; })
> + u32 upper, lower, tmp; \
> + tmp = I915_READ(upper_reg); \
> + do {\
> + upper = tmp;\
> + lower = I915_READ(lower_reg); \
> + tmp = I915_READ(upper_reg); \
> + } while (upper != tmp); \
> + (u64)upper << 32 | lower; })
>
> #define POSTING_READ(reg)(void)I915_READ_NOTRACE(reg)
> #define POSTING_READ16(reg) (void)I915_READ16_NOTRACE(reg)
--
Chris Wilson, Intel Open Source Technology Centre
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 11/13 v4] drm/i915: Integrate GuC-based command submission
On 27/07/15 16:57, O'Rourke, Tom wrote:
On Thu, Jul 09, 2015 at 07:29:12PM +0100, Dave Gordon wrote:
From: Alex Dai
GuC-based submission is mostly the same as execlist mode, up to
intel_logical_ring_advance_and_submit(), where the context being
dispatched would be added to the execlist queue; at this point
we submit the context to the GuC backend instead.
There are, however, a few other changes also required, notably:
1. Contexts must be pinned at GGTT addresses accessible by the GuC
i.e. NOT in the range [0..WOPCM_SIZE), so we have to add the
PIN_OFFSET_BIAS flag to the relevant GGTT-pinning calls.
2. The GuC's TLB must be invalidated after a context is pinned at
a new GGTT address.
[snip]
static int gen8_init_rcs_context(struct drm_i915_gem_request *req)
{
+ struct drm_i915_private *dev_priv = req->i915;
int ret;
+ /* Invalidate GuC TLB. */
+ if (i915.enable_guc_submission)
+ I915_WRITE(GEN8_GTCR, GEN8_GTCR_INVALIDATE);
+
>
[TOR:] This invalidation is in the init_context for render
ring but not the other rings. Is this needed for other
rings? Or, should this invalidation happen at a different
level? It seems this may depend on the on render ring being
initialized first.
Thanks,
Tom
Hi Tom,
it looks like this is redundant here in the case where its called from
the non-default-context case of intel_lr_context_deferred_create(); but
when called from i915_gem_init_hw() [via i915_gem_context_enable()] it
wouldn't be, because the GuC TLB wouldn't have been flushed since the
default context was pinned [which is in a completely different path
through intel_lr_context_deferred_create()!].
However, if we add a TLB flush just after that point, we can remove this
one here, with several advantages:
* firstly, that path is taken just once, rather than every time a new
render context is created, and
* secondly, each flush can be specifically associated with a pin-to-gtt
call that includes the (PIN_OFFSET_BIAS | GUC_WOPCM_SIZE_VALUE) flags,
showing that the pinned object is of interest to the GuC.
I'll also move the existing TLB flushes in guc_submission.c and
guc_loader.c so that they're also just after the relevant 'pin' calls.
Thanks,
.Dave.
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/3] drm/fbdev: Return -EBUSY when oopsing
On Tue, Jul 28, 2015 at 7:18 AM, Daniel Vetter wrote:
> Trying to do anything with kms drivers when oopsing has become a
> failing proposition. But since we can end up in the fbdev code simply
> due to the console unblanking that's done unconditionally just
> removing our panic handler isn't enough. We need to block all fbdev
> callbacks when oopsing.
>
> There was already one in the blank handler, but it failed silently.
> That makes it impossible for drivers (like i915) who subclass these
> functions to figure this out.
>
> Instead consistently return -EBUSY so that everyone knows that we
> really don't want to be bothered right now. This also allows us to
> remove a pile of FIXMEs from the i915 fbdev code (since due to the
> failure code they now won't attempt to grab dangerous locks any more).
I guess drivers that were keeping fbdev buffer pinned just for opps'
can stop doing that now..
anyways, lgtm.. for the series:
Reviewed-by: Rob Clark
> Cc: Dave Airlie
> Cc: Rodrigo Vivi
> Signed-off-by: Daniel Vetter
> ---
> drivers/gpu/drm/drm_fb_helper.c| 24
> drivers/gpu/drm/i915/intel_fbdev.c | 21 -
> 2 files changed, 12 insertions(+), 33 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c
> index 73f90f7e2f74..77f570a470da 100644
> --- a/drivers/gpu/drm/drm_fb_helper.c
> +++ b/drivers/gpu/drm/drm_fb_helper.c
> @@ -491,14 +491,6 @@ static void drm_fb_helper_dpms(struct fb_info *info, int
> dpms_mode)
> int i, j;
>
> /*
> -* fbdev->blank can be called from irq context in case of a panic.
> -* Since we already have our own special panic handler which will
> -* restore the fbdev console mode completely, just bail out early.
> -*/
> - if (oops_in_progress)
> - return;
> -
> - /*
> * For each CRTC in this fb, turn the connectors on/off.
> */
> drm_modeset_lock_all(dev);
> @@ -531,6 +523,9 @@ static void drm_fb_helper_dpms(struct fb_info *info, int
> dpms_mode)
> */
> int drm_fb_helper_blank(int blank, struct fb_info *info)
> {
> + if (oops_in_progress)
> + return -EBUSY;
> +
> switch (blank) {
> /* Display: On; HSync: On, VSync: On */
> case FB_BLANK_UNBLANK:
> @@ -755,9 +750,10 @@ int drm_fb_helper_setcmap(struct fb_cmap *cmap, struct
> fb_info *info)
> int i, j, rc = 0;
> int start;
>
> - if (__drm_modeset_lock_all(dev, !!oops_in_progress)) {
> + if (oops_in_progress)
> return -EBUSY;
> - }
> +
> + drm_modeset_lock_all(dev);
> if (!drm_fb_helper_is_bound(fb_helper)) {
> drm_modeset_unlock_all(dev);
> return -EBUSY;
> @@ -906,6 +902,9 @@ int drm_fb_helper_set_par(struct fb_info *info)
> struct drm_fb_helper *fb_helper = info->par;
> struct fb_var_screeninfo *var = &info->var;
>
> + if (oops_in_progress)
> + return -EBUSY;
> +
> if (var->pixclock != 0) {
> DRM_ERROR("PIXEL CLOCK SET\n");
> return -EINVAL;
> @@ -931,9 +930,10 @@ int drm_fb_helper_pan_display(struct fb_var_screeninfo
> *var,
> int ret = 0;
> int i;
>
> - if (__drm_modeset_lock_all(dev, !!oops_in_progress)) {
> + if (oops_in_progress)
> return -EBUSY;
> - }
> +
> + drm_modeset_lock_all(dev);
> if (!drm_fb_helper_is_bound(fb_helper)) {
> drm_modeset_unlock_all(dev);
> return -EBUSY;
> diff --git a/drivers/gpu/drm/i915/intel_fbdev.c
> b/drivers/gpu/drm/i915/intel_fbdev.c
> index eef54feb7545..b763f24e20ef 100644
> --- a/drivers/gpu/drm/i915/intel_fbdev.c
> +++ b/drivers/gpu/drm/i915/intel_fbdev.c
> @@ -55,13 +55,6 @@ static int intel_fbdev_set_par(struct fb_info *info)
> ret = drm_fb_helper_set_par(info);
>
> if (ret == 0) {
> - /*
> -* FIXME: fbdev presumes that all callbacks also work from
> -* atomic contexts and relies on that for emergency oops
> -* printing. KMS totally doesn't do that and the locking here
> is
> -* by far not the only place this goes wrong. Ignore this for
> -* now until we solve this for real.
> -*/
> mutex_lock(&fb_helper->dev->struct_mutex);
> intel_fb_obj_invalidate(ifbdev->fb->obj, ORIGIN_GTT);
> mutex_unlock(&fb_helper->dev->struct_mutex);
> @@ -80,13 +73,6 @@ static int intel_fbdev_blank(int blank, struct fb_info
> *info)
> ret = drm_fb_helper_blank(blank, info);
>
> if (ret == 0) {
> - /*
> -* FIXME: fbdev presumes that all callbacks also work from
> -* atomic contexts and relies on that for emergency oops
> -* printing. KMS totally doesn't do that and t
Re: [Intel-gfx] [PATCH v5 17/19] drm/i915: Wa32bitGeneralStateOffset & Wa32bitInstructionBaseOffset
On Tue, Jul 28, 2015 at 12:12:11PM +0100, Michel Thierry wrote:
> On 7/27/2015 10:11 PM, Chris Wilson wrote:
> >On Thu, Jul 16, 2015 at 10:33:29AM +0100, Michel Thierry wrote:
> >>+ if (!(entry->flags & EXEC_OBJECT_SUPPORTS_48B_ADDRESS) &&
> >>+ (vma->node.start + vma->node.size) >= (1ULL << 32))
> >>+ return true;
> >
> >gcc completely screwed this up here and used 0 for 1ULL<<32.
> >
> >Note that we can allow state + size == 4G (since the end is exclusive),
> >so I went with
> >
> > if ((entry->flags & EXEC_OBJECT_SUPPORTS_48B_ADDRESS) == 0 &&
> > (vma->node.start + vma->node.size - 1) >> 32)
> > return true;
> >
> >instead.
> >-Chris
> >
>
> Thanks, I'll include this change in the next patch version.
I've also got a couple of other stylistic changes, plus an earlier
request:
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 1e2764a324b2..b0fe9b4124fd 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -3356,13 +3356,9 @@ i915_gem_object_bind_to_vm(struct drm_i915_gem_object
*obj,
struct drm_device *dev = obj->base.dev;
struct drm_i915_private *dev_priv = dev->dev_private;
u32 fence_alignment, unfenced_alignment;
+ u64 start, end;
u64 size, fence_size;
- u32 search_flag = DRM_MM_SEARCH_DEFAULT;
- u32 alloc_flag = DRM_MM_CREATE_DEFAULT;
- u64 start =
- flags & PIN_OFFSET_BIAS ? flags & PIN_OFFSET_MASK : 0;
- u64 end =
- flags & PIN_MAPPABLE ? dev_priv->gtt.mappable_end : vm->total;
+ u32 search_flag, alloc_flag;
struct i915_vma *vma;
int ret;
@@ -3400,15 +3396,15 @@ i915_gem_object_bind_to_vm(struct drm_i915_gem_object
*obj,
obj->tiling_mode,
false);
size = flags & PIN_MAPPABLE ? fence_size : obj->base.size;
+ }
- if (flags & PIN_HIGH) {
- search_flag = DRM_MM_SEARCH_BELOW;
- alloc_flag = DRM_MM_CREATE_TOP;
- }
+ start = flags & PIN_OFFSET_BIAS ? flags & PIN_OFFSET_MASK : 0;
- if (flags & PIN_ZONE_4G)
- end = (1ULL << 32);
- }
+ end = vm->total;
+ if (flags & PIN_MAPPABLE)
+ end = min_t(u64, end, dev_priv->gtt.mappable_end);
+ if (flags & PIN_ZONE_4G)
+ end = min_t(u64, end, 1ULL << 32);
if (alignment == 0)
alignment = flags & PIN_MAPPABLE ? fence_alignment :
@@ -3445,6 +3441,14 @@ i915_gem_object_bind_to_vm(struct drm_i915_gem_object
*obj,
if (IS_ERR(vma))
goto err_unpin;
+ if (flags & PIN_HIGH) {
+ search_flag = DRM_MM_SEARCH_BELOW;
+ alloc_flag = DRM_MM_CREATE_TOP;
+ } else {
+ search_flag = DRM_MM_SEARCH_DEFAULT;
+ alloc_flag = DRM_MM_CREATE_DEFAULT;
+ }
+
search_free:
ret = drm_mm_insert_node_in_range_generic(&vm->mm, &vma->node,
size, alignment,
diff --git a/drivers/gpu/drm/i915/i915_gem_execbuffer.c
b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
index 209e8e2b07be..78fc8810d6e0 100644
--- a/drivers/gpu/drm/i915/i915_gem_execbuffer.c
+++ b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
@@ -680,8 +680,8 @@ eb_vma_misplaced(struct i915_vma *vma)
if (entry->flags & __EXEC_OBJECT_NEEDS_MAP && !obj->map_and_fenceable)
return !only_mappable_for_reloc(entry->flags);
- if (!(entry->flags & EXEC_OBJECT_SUPPORTS_48B_ADDRESS) &&
- (vma->node.start + vma->node.size) >= (1ULL << 32))
+ if ((entry->flags & EXEC_OBJECT_SUPPORTS_48B_ADDRESS) == 0 &&
+ (vma->node.start + vma->node.size - 1) >> 32)
return true;
return false;
--
Chris Wilson, Intel Open Source Technology Centre
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [MIPI SEQ PARSING v1 PATCH 2/9] drm/i915: Parsing VBT if size of VBT exceeds 6KB
On Tue, 28 Jul 2015, Deepak M wrote:
> Currently the iomap for VBT works only if the size of the
> VBT is less than 6KB, but if the size of the VBT exceeds
> 6KB than the physical address and the size of the VBT to
> be iomapped is specified in the mailbox3 and is iomapped
> accordingly.
>
> Signed-off-by: Deepak M
> ---
> drivers/gpu/drm/i915/intel_bios.c | 13 +++
> drivers/gpu/drm/i915/intel_opregion.c | 39
> ++---
> 2 files changed, 45 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_bios.c
> b/drivers/gpu/drm/i915/intel_bios.c
> index 2583587..1b9164e 100644
> --- a/drivers/gpu/drm/i915/intel_bios.c
> +++ b/drivers/gpu/drm/i915/intel_bios.c
> @@ -1219,6 +1219,7 @@ intel_parse_bios(struct drm_device *dev)
> struct drm_i915_private *dev_priv = dev->dev_private;
> struct pci_dev *pdev = dev->pdev;
> const struct bdb_header *bdb = NULL;
> + const struct vbt_header *vbt = NULL;
> u8 __iomem *bios = NULL;
>
> if (HAS_PCH_NOP(dev))
> @@ -1226,10 +1227,14 @@ intel_parse_bios(struct drm_device *dev)
>
> init_vbt_defaults(dev_priv);
>
> - /* XXX Should this validation be moved to intel_opregion.c? */
> - if (!dmi_check_system(intel_no_opregion_vbt) && dev_priv->opregion.vbt)
> - bdb = validate_vbt(dev_priv->opregion.header, OPREGION_SIZE,
> -dev_priv->opregion.vbt, "OpRegion");
> + if (!dmi_check_system(intel_no_opregion_vbt) &&
> + dev_priv->opregion.vbt) {
> + vbt = (struct vbt_header *)dev_priv->opregion.vbt;
> + bdb = (struct bdb_header *)(dev_priv->opregion.vbt +
> + vbt->bdb_offset);
> + DRM_DEBUG_KMS("Using VBT from Opregion: %20s\n",
> + vbt->signature);
> + }
Please read the comment in the beginning of validate_vbt. Please keep
things that way. I put in some effort to clean this up and get rid of a
bunch of extra casts, so please don't add new ones back.
You should probably move some of this stuff to intel_opregion.c and have
a function to return the struct bdb_header *pointer from there.
Please also look into in i915_opregion in i915_debugfs.c, and fix that.
>
> if (bdb == NULL) {
> size_t size;
> diff --git a/drivers/gpu/drm/i915/intel_opregion.c
> b/drivers/gpu/drm/i915/intel_opregion.c
> index 71e87ab..1372e39 100644
> --- a/drivers/gpu/drm/i915/intel_opregion.c
> +++ b/drivers/gpu/drm/i915/intel_opregion.c
> @@ -50,6 +50,7 @@
> #define OPREGION_VBT_OFFSET0x400
>
> #define OPREGION_SIGNATURE "IntelGraphicsMem"
> +#define VBT_SIGNATURE"$VBT"
Adding this does you no good when you're duplicating this from
intel_bios.c and not removing any from there... really the check should
be in one place only.
> #define MBOX_ACPI (1<<0)
> #define MBOX_SWSCI (1<<1)
> #define MBOX_ASLE (1<<2)
> @@ -113,7 +114,12 @@ struct opregion_asle {
> u32 pcft; /* power conservation features */
> u32 srot; /* supported rotation angles */
> u32 iuer; /* IUER events */
> - u8 rsvd[86];
> + u64 fdss; /* DSS Buffer address allocated for IFFS feature */
> + u32 fdsp; /* Size of DSS Buffer */
> + u32 stat; /* State Indicator */
> + u64 rvda; /* Physical address of raw vbt data */
> + u32 rvds; /* Size of raw vbt data */
> + u8 rsvd[58];
These should be a prep patch that could be merged quickly with a check
against the spec.
> } __packed;
>
> /* Driver readiness indicator */
> @@ -858,8 +864,10 @@ int intel_opregion_setup(struct drm_device *dev)
> struct drm_i915_private *dev_priv = dev->dev_private;
> struct intel_opregion *opregion = &dev_priv->opregion;
> void __iomem *base;
> + void __iomem *vbt_base;
> u32 asls, mboxes;
> char buf[sizeof(OPREGION_SIGNATURE)];
> + char vbt_sig_buf[sizeof(VBT_SIGNATURE)];
> int err = 0;
>
> pci_read_config_dword(dev->pdev, PCI_ASLS, &asls);
> @@ -873,7 +881,7 @@ int intel_opregion_setup(struct drm_device *dev)
> INIT_WORK(&opregion->asle_work, asle_work);
> #endif
>
> - base = acpi_os_ioremap(asls, OPREGION_SIZE);
> + base = acpi_os_ioremap(asls, OPREGION_VBT_OFFSET);
> if (!base)
> return -ENOMEM;
>
> @@ -884,8 +892,31 @@ int intel_opregion_setup(struct drm_device *dev)
> err = -EINVAL;
> goto err_out;
> }
> +
> opregion->header = base;
> - opregion->vbt = base + OPREGION_VBT_OFFSET;
> + opregion->asle = base + OPREGION_ASLE_OFFSET;
Why is this addition needed or even correct?
> +
> + if (opregion->header->opregion_ver >= 2) {
> + if (opregion->asle->rvda)
> + vbt_base = acpi_os_ioremap(opregion->asle->rvda,
> + opregion->asle->rvds);
Re: [Intel-gfx] [PATCH] drm/i915: Fake AGP is dead
On Tue, Jul 28, 2015 at 12:29:37PM +0100, Chris Wilson wrote: > On Tue, Jul 28, 2015 at 01:43:11AM -0700, shuang...@intel.com wrote: > > Tested-By: Intel Graphics QA PRTS (Patch Regression Test System Contact: > > shuang...@intel.com) > > Task id: 6873 > > -Summary- > > Platform Delta drm-intel-nightly Series Applied > > ILK 297/297 297/297 > > SNB 315/315 315/315 > > IVB 342/342 342/342 > > BYT -1 284/284 283/284 > > HSW 378/378 378/378 > > -Detailed- > > Platform Testdrm-intel-nightly > > Series Applied > > *BYT igt@gem_partial_pwrite_pread@reads PASS(1) FAIL(1) > > Note: You need to pay more attention to line start with '*' > > The original message went astry, but I read through it on patchwork and > it really is just dead code elimination. > > Reviewed-by: Chris Wilson > > I felt the changelog was a little vague (I didn't understand the "really > no users left" comment), so I wouldn't mind if you tighten it up a bit! Done a bit of clarification and pushed to dinq, thanks for the review. And yay for mailer delay ... -Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [MIPI SEQ PARSING v1 PATCH 3/9] drm/i915: Using the approprite vbt size if vbt is not in mailbox4 of opregion
On Tue, 28 Jul 2015, Deepak M wrote:
> Currently the field in bdb header which indicates the VBT size
> is of 2 bytes, but there are some cases where VBT size exceeds
> 64KB in which case this field may not contain the correct VBT size.
> So its better to get the VBT size from the mailbox3 if
> VBT is not present in the mailbox4 of opregion.
>
> Signed-off-by: Deepak M
> ---
> drivers/gpu/drm/i915/i915_drv.h |5
> drivers/gpu/drm/i915/intel_bios.c | 43
> +++--
> drivers/gpu/drm/i915/intel_opregion.c |7 --
> 3 files changed, 35 insertions(+), 20 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index 1dbd957..b38f52ee 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -1740,6 +1740,11 @@ struct drm_i915_private {
> u32 pm_rps_events;
> u32 pipestat_irq_mask[I915_MAX_PIPES];
>
> + bool vbt_in_mailbox4;
> +
> + /* value is true when VBT is present in mailbox4 */
> + u32 vbt_size;
> +
There's already struct intel_opregion opregion field in dev_priv where
this belongs instead of cluttering the top level.
You should only add vbt size in the struct, and make sure it's valid for
all scenarios, mailbox 4 or not, and always check against that. Having
size fields with separate validity fields will drive people insane.
> struct i915_hotplug hotplug;
> struct i915_fbc fbc;
> struct i915_drrs drrs;
> diff --git a/drivers/gpu/drm/i915/intel_bios.c
> b/drivers/gpu/drm/i915/intel_bios.c
> index 1b9164e..5e0ff22 100644
> --- a/drivers/gpu/drm/i915/intel_bios.c
> +++ b/drivers/gpu/drm/i915/intel_bios.c
> @@ -37,17 +37,22 @@
> static int panel_type;
>
> static const void *
> -find_section(const void *_bdb, int section_id)
> +find_section(struct drm_i915_private *dev_priv,
> + const void *_bdb, int section_id)
> {
> const struct bdb_header *bdb = _bdb;
> const u8 *base = _bdb;
> int index = 0;
> - u16 total, current_size;
> + u32 total, current_size;
> u8 current_id;
>
> /* skip to first section */
> index += bdb->header_size;
> - total = bdb->bdb_size;
> +
> + if (dev_priv->vbt_in_mailbox4)
> + total = bdb->bdb_size;
> + else
> + total = dev_priv->vbt_size;
>
> /* walk the sections looking for section_id */
> while (index + 3 < total) {
> @@ -179,7 +184,7 @@ parse_lfp_panel_data(struct drm_i915_private *dev_priv,
> struct drm_display_mode *panel_fixed_mode;
> int drrs_mode;
>
> - lvds_options = find_section(bdb, BDB_LVDS_OPTIONS);
> + lvds_options = find_section(dev_priv, bdb, BDB_LVDS_OPTIONS);
> if (!lvds_options)
> return;
>
> @@ -211,11 +216,12 @@ parse_lfp_panel_data(struct drm_i915_private *dev_priv,
> break;
> }
>
> - lvds_lfp_data = find_section(bdb, BDB_LVDS_LFP_DATA);
> + lvds_lfp_data = find_section(dev_priv, bdb, BDB_LVDS_LFP_DATA);
> if (!lvds_lfp_data)
> return;
>
> - lvds_lfp_data_ptrs = find_section(bdb, BDB_LVDS_LFP_DATA_PTRS);
> + lvds_lfp_data_ptrs = find_section(dev_priv, bdb,
> + BDB_LVDS_LFP_DATA_PTRS);
> if (!lvds_lfp_data_ptrs)
> return;
>
> @@ -257,7 +263,7 @@ parse_lfp_backlight(struct drm_i915_private *dev_priv,
> const struct bdb_lfp_backlight_data *backlight_data;
> const struct bdb_lfp_backlight_data_entry *entry;
>
> - backlight_data = find_section(bdb, BDB_LVDS_BACKLIGHT);
> + backlight_data = find_section(dev_priv, bdb, BDB_LVDS_BACKLIGHT);
> if (!backlight_data)
> return;
>
> @@ -305,14 +311,15 @@ parse_sdvo_panel_data(struct drm_i915_private *dev_priv,
> if (index == -1) {
> const struct bdb_sdvo_lvds_options *sdvo_lvds_options;
>
> - sdvo_lvds_options = find_section(bdb, BDB_SDVO_LVDS_OPTIONS);
> + sdvo_lvds_options = find_section(dev_priv, bdb,
> + BDB_SDVO_LVDS_OPTIONS);
> if (!sdvo_lvds_options)
> return;
>
> index = sdvo_lvds_options->panel_type;
> }
>
> - dvo_timing = find_section(bdb, BDB_SDVO_PANEL_DTDS);
> + dvo_timing = find_section(dev_priv, bdb, BDB_SDVO_PANEL_DTDS);
> if (!dvo_timing)
> return;
>
> @@ -349,7 +356,7 @@ parse_general_features(struct drm_i915_private *dev_priv,
> struct drm_device *dev = dev_priv->dev;
> const struct bdb_general_features *general;
>
> - general = find_section(bdb, BDB_GENERAL_FEATURES);
> + general = find_section(dev_priv, bdb, BDB_GENERAL_FEATURES);
> if (general) {
> dev_priv->vbt.int_tv_support = general->int_tv_support;
> dev_priv->vbt.int_crt_support = general->int_crt_support;
> @@ -374,7 +381,7 @@ par
Re: [Intel-gfx] [MIPI SEQ PARSING v1 PATCH 1/9] drm/i915: Adding the parsing logic for the i2c element
On Tue, 28 Jul 2015, Deepak M wrote:
> From: vkorjani
>
> New sequence element for i2c is been added in the
> mipi sequence block of the VBT. This patch parses
> and executes the i2c sequence.
>
> Signed-off-by: vkorjani
> Signed-off-by: Deepak M
> ---
> drivers/gpu/drm/i915/intel_bios.c |6 +++
> drivers/gpu/drm/i915/intel_bios.h |1 +
> drivers/gpu/drm/i915/intel_dsi_panel_vbt.c | 59
>
> 3 files changed, 66 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/intel_bios.c
> b/drivers/gpu/drm/i915/intel_bios.c
> index 2ff9eb0..2583587 100644
> --- a/drivers/gpu/drm/i915/intel_bios.c
> +++ b/drivers/gpu/drm/i915/intel_bios.c
> @@ -714,6 +714,12 @@ static u8 *goto_next_sequence(u8 *data, int *size)
>
> data += 3;
> break;
> + case MIPI_SEQ_ELEM_I2C:
> + /* skip by this element payload size */
> + data += 7;
> + len = *data;
> + data += len + 1;
> + break;
> default:
> DRM_ERROR("Unknown element\n");
> return NULL;
> diff --git a/drivers/gpu/drm/i915/intel_bios.h
> b/drivers/gpu/drm/i915/intel_bios.h
> index af0b476..1703a83 100644
> --- a/drivers/gpu/drm/i915/intel_bios.h
> +++ b/drivers/gpu/drm/i915/intel_bios.h
> @@ -942,6 +942,7 @@ enum mipi_seq_element {
> MIPI_SEQ_ELEM_SEND_PKT,
> MIPI_SEQ_ELEM_DELAY,
> MIPI_SEQ_ELEM_GPIO,
> + MIPI_SEQ_ELEM_I2C,
> MIPI_SEQ_ELEM_STATUS,
> MIPI_SEQ_ELEM_MAX
> };
> diff --git a/drivers/gpu/drm/i915/intel_dsi_panel_vbt.c
> b/drivers/gpu/drm/i915/intel_dsi_panel_vbt.c
> index a5e99ac..e061a42 100644
> --- a/drivers/gpu/drm/i915/intel_dsi_panel_vbt.c
> +++ b/drivers/gpu/drm/i915/intel_dsi_panel_vbt.c
> @@ -31,6 +31,7 @@
> #include
> #include
> #include
> +#include
> #include
> #include
> #include "i915_drv.h"
> @@ -104,6 +105,63 @@ static struct gpio_table gtable[] = {
> { GPIO_NC_11_PCONF0, GPIO_NC_11_PAD, 0}
> };
>
> +static const u8 *mipi_exec_i2c(struct intel_dsi *intel_dsi, const u8 *data)
> +{
> + struct i2c_adapter *adapter;
> + int ret;
> + u8 reg_offset, payload_size, retries = 5;
> + struct i2c_msg msg;
> + u8 *transmit_buffer = NULL;
> + u8 flag = *data++;
> + u8 index = *data++;
> + u8 bus_number = *data++;
> + u16 slave_add = *(u16 *)(data);
> +
> + data = data + 2;
> + reg_offset = *data++;
> + payload_size = *data++;
> +
> + adapter = i2c_get_adapter(bus_number);
Where's the corresponding i2c_put_adapter?
BR,
Jani.
> +
> + if (!adapter) {
> + DRM_ERROR("i2c_get_adapter(%u) failed, index:%u flag: %u\n",
> + (bus_number + 1), index, flag);
> + goto out;
> + }
> +
> + transmit_buffer = kmalloc(1 + payload_size, GFP_TEMPORARY);
> +
> + if (!transmit_buffer)
> + goto out;
> +
> + transmit_buffer[0] = reg_offset;
> + memcpy(&transmit_buffer[1], data, (size_t)payload_size);
> +
> + msg.addr = slave_add;
> + msg.flags = 0;
> + msg.len= 2;
> + msg.buf= &transmit_buffer[0];
> +
> + do {
> + ret = i2c_transfer(adapter, &msg, 1);
> + if (ret == -EAGAIN)
> + usleep_range(1000, 2500);
> + else if (ret != 1) {
> + DRM_ERROR("i2c transfer failed %d\n", ret);
> + break;
> + }
> + } while (retries--);
> +
> + if (retries == 0)
> + DRM_ERROR("i2c transfer failed");
> +
> +out:
> + kfree(transmit_buffer);
> +
> + data = data + payload_size;
> + return data;
> +}
> +
> static inline enum port intel_dsi_seq_port_to_port(u8 port)
> {
> return port ? PORT_C : PORT_A;
> @@ -236,6 +294,7 @@ static const fn_mipi_elem_exec exec_elem[] = {
> mipi_exec_send_packet,
> mipi_exec_delay,
> mipi_exec_gpio,
> + mipi_exec_i2c,
> NULL, /* status read; later */
> };
>
> --
> 1.7.9.5
>
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Jani Nikula, Intel Open Source Technology Center
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 07/13 v4] drm/i915: GuC submission setup, phase 1
On 28/07/15 00:12, O'Rourke, Tom wrote: On Mon, Jul 27, 2015 at 03:41:31PM -0700, Yu Dai wrote: On 07/24/2015 03:31 PM, O'Rourke, Tom wrote: [TOR:] When I see "phase 1" I also look for "phase 2". A subject that better describes the change in this patch would help. On Thu, Jul 09, 2015 at 07:29:08PM +0100, Dave Gordon wrote: From: Alex Dai This adds the first of the data structures used to communicate with the GuC (the pool of guc_context structures). We create a GuC-specific wrapper round the GEM object allocator as all GEM objects shared with the GuC must be pinned into GGTT space at an address that is NOT in the range [0..WOPCM_SIZE), as that range of GGTT addresses is not accessible to the GuC (from the GuC's point of view, it's permanently reserved for other objects such as the BootROM & SRAM). [TOR:] I would like a clarfication on the excluded range. The excluded range should be 0 to "size for guc within WOPCM area" and not 0 to "size of WOPCM area". Nope, GGTT range [0..WOPCM_SIZE) should be excluded from GuC usage. BSpec clearly says, from 0 to WOPCM_TOP-1 is for BootROM, SRAM and WOPCM. From WOPCM_TOP and above is GFX DRAM. Be note that, that GGTT space is still available to any gfx obj as long as it is not accessed by GuC (OK to pass through GuC). [TOR:] Should we take a closer look at the pin offset bias for guc objects? GUC_WOPCM_SIZE_VALUE is not the full size of WOPCM area. I'm inclined to set the bias to GUC_WOPCM_TOP, and then define that as the sum of GUC_WOPCM_OFFSET_VALUE and GUC_WOPCM_SIZE_VALUE. That seems to be what the BSpec pages "WriteOnceProtectedContentMemory (WOPCM) Management" and "WOPCM Memory Map" suggest, although I think they're pretty unclear on the details :( Do you (both) agree this would be the right value? [snip] + /* If GuC scheduling is enabled, setup params here. */ [TOR:] I assume from this "GuC scheduling" == "GuC submission". This is a little confusing. I recommend either reword "GuC scheduling" or add comment text to explain. For now, yes the GuC scheduling is only doing the 'submission' work because of the current kernel in-order queue. If we have client direct submission enabled, there WILL BE GuC scheduling inside firmware according to the priority of each queue etc. Thanks, Alex I changed the line above to "GuC submission", while the one a few lines further down now says: /* Unmask this bit to enable the GuC's internal scheduler */ to make it quite clear that we're not referring to the host-based GPU scheduler curently in review. .Dave. ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [MIPI SEQ PARSING v1 PATCH 5/9] drm/i915: Added the generic gpio sequence support and gpio table
On Tue, 28 Jul 2015, Deepak M wrote: > The generic gpio is sequence is parsed from the VBT and the > GPIO table is updated with the North core, South core and > SUS core elements. > > Signed-off-by: Deepak M > --- > drivers/gpu/drm/i915/i915_drv.h|5 +- > drivers/gpu/drm/i915/i915_reg.h|5 + > drivers/gpu/drm/i915/intel_dsi.h | 355 > > drivers/gpu/drm/i915/intel_dsi_panel_vbt.c | 219 +++-- > drivers/gpu/drm/i915/intel_sideband.c |9 +- The changes to intel_sideband.c should be a separate patch. BR, Jani. > 5 files changed, 573 insertions(+), 20 deletions(-) > > diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h > index b38f52ee..8cf133e 100644 > --- a/drivers/gpu/drm/i915/i915_drv.h > +++ b/drivers/gpu/drm/i915/i915_drv.h > @@ -3306,8 +3306,9 @@ int sandybridge_pcode_write(struct drm_i915_private > *dev_priv, u32 mbox, u32 val > u32 vlv_punit_read(struct drm_i915_private *dev_priv, u32 addr); > void vlv_punit_write(struct drm_i915_private *dev_priv, u32 addr, u32 val); > u32 vlv_nc_read(struct drm_i915_private *dev_priv, u8 addr); > -u32 vlv_gpio_nc_read(struct drm_i915_private *dev_priv, u32 reg); > -void vlv_gpio_nc_write(struct drm_i915_private *dev_priv, u32 reg, u32 val); > +u32 vlv_gpio_read(struct drm_i915_private *dev_priv, u8 core_offset, u32 > reg); > +void vlv_gpio_write(struct drm_i915_private *dev_priv, u8 core_offset, > + u32 reg, u32 val); > u32 vlv_cck_read(struct drm_i915_private *dev_priv, u32 reg); > void vlv_cck_write(struct drm_i915_private *dev_priv, u32 reg, u32 val); > u32 vlv_ccu_read(struct drm_i915_private *dev_priv, u32 reg); > diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h > index 313b1f9..3efea0e 100644 > --- a/drivers/gpu/drm/i915/i915_reg.h > +++ b/drivers/gpu/drm/i915/i915_reg.h > @@ -554,6 +554,11 @@ > #define IOSF_PORT_DPIO 0x12 > #define IOSF_PORT_DPIO_2 0x1a > #define IOSF_PORT_GPIO_NC 0x13 > +#define IOSF_PORT_GPIO_SC 0x48 > +#define IOSF_PORT_GPIO_SUS 0xA8 > +#define MAX_GPIO_NUM_NC26 > +#define MAX_GPIO_NUM_SC128 > +#define MAX_GPIO_NUM 172 > #define IOSF_PORT_CCK 0x14 > #define IOSF_PORT_CCU 0xA9 > #define IOSF_PORT_GPS_CORE 0x48 > diff --git a/drivers/gpu/drm/i915/intel_dsi.h > b/drivers/gpu/drm/i915/intel_dsi.h > index 2784ac4..13d3d22 100644 > --- a/drivers/gpu/drm/i915/intel_dsi.h > +++ b/drivers/gpu/drm/i915/intel_dsi.h > @@ -34,6 +34,361 @@ > #define DSI_DUAL_LINK_FRONT_BACK 1 > #define DSI_DUAL_LINK_PIXEL_ALT 2 > > +#define HV_DDI0_HPD_GPIONC_0_PCONF0 0x4130 > +#define HV_DDI0_HPD_GPIONC_0_PAD 0x4138 > +#define HV_DDI0_DDC_SDA_GPIONC_1_PCONF0 0x4120 > +#define HV_DDI0_DDC_SDA_GPIONC_1_PAD 0x4128 > +#define HV_DDI0_DDC_SCL_GPIONC_2_PCONF0 0x4110 > +#define HV_DDI0_DDC_SCL_GPIONC_2_PAD 0x4118 > +#define PANEL0_VDDEN_GPIONC_3_PCONF0 0x4140 > +#define PANEL0_VDDEN_GPIONC_3_PAD0x4148 > +#define PANEL0_BKLTEN_GPIONC_4_PCONF00x4150 > +#define PANEL0_BKLTEN_GPIONC_4_PAD 0x4158 > +#define PANEL0_BKLTCTL_GPIONC_5_PCONF0 0x4160 > +#define PANEL0_BKLTCTL_GPIONC_5_PAD 0x4168 > +#define HV_DDI1_HPD_GPIONC_6_PCONF0 0x4180 > +#define HV_DDI1_HPD_GPIONC_6_PAD 0x4188 > +#define HV_DDI1_DDC_SDA_GPIONC_7_PCONF0 0x4190 > +#define HV_DDI1_DDC_SDA_GPIONC_7_PAD 0x4198 > +#define HV_DDI1_DDC_SCL_GPIONC_8_PCONF0 0x4170 > +#define HV_DDI1_DDC_SCL_GPIONC_8_PAD 0x4178 > +#define PANEL1_VDDEN_GPIONC_9_PCONF0 0x4100 > +#define PANEL1_VDDEN_GPIONC_9_PAD0x4108 > +#define PANEL1_BKLTEN_GPIONC_10_PCONF0 0x40E0 > +#define PANEL1_BKLTEN_GPIONC_10_PAD 0x40E8 > +#define PANEL1_BKLTCTL_GPIONC_11_PCONF0 0x40F0 > +#define PANEL1_BKLTCTL_GPIONC_11_PAD 0x40F8 > +#define GP_INTD_DSI_TE1_GPIONC_12_PCONF0 0x40C0 > +#define GP_INTD_DSI_TE1_GPIONC_12_PAD0x40C8 > +#define HV_DDI2_DDC_SDA_GPIONC_13_PCONF0 0x41A0 > +#define HV_DDI2_DDC_SDA_GPIONC_13_PAD0x41A8 > +#define HV_DDI2_DDC_SCL_GPIONC_14_PCONF0 0x41B0 > +#define HV_DDI2_DDC_SCL_GPIONC_14_PAD0x41B8 > +#define GP_CAMERASB00_GPIONC_15_PCONF0 0x4010 > +#define GP_CAMERASB00_GPIONC_15_PAD 0x4018 > +#define GP_CAMERASB01_GPIONC_16_PCONF0 0x4040 > +#define GP_CAMERASB01_GPIONC_16_PAD 0x4048 > +#define GP_CAMERASB02_GPIONC_17_PCONF0 0x4080 > +#define GP_CAMERASB02_GPIONC_17_PAD 0x4088 > +#define GP_CAMERASB03_GPIONC
Re: [Intel-gfx] [PATCH v2 03/12] drm/i915: Convert connector checking to atomic.
Op 28-07-15 om 15:13 schreef Ander Conselvan De Oliveira:
> On Mon, 2015-07-27 at 14:35 +0200, Maarten Lankhorst wrote:
> Signed-off-by: Maarten Lankhorst
> ---
> drivers/gpu/drm/i915/intel_crt.c | 2 -
> drivers/gpu/drm/i915/intel_display.c | 79
>
> drivers/gpu/drm/i915/intel_drv.h | 1 -
> drivers/gpu/drm/i915/intel_dvo.c | 2 -
> drivers/gpu/drm/i915/intel_sdvo.c| 2 -
> 5 files changed, 36 insertions(+), 50 deletions(-)
>
>
> diff --git a/drivers/gpu/drm/i915/intel_crt.c
> b/drivers/gpu/drm/i915/intel_crt.c
> index 5d78c1feec81..9eba3dd5b434 100644
> --- a/drivers/gpu/drm/i915/intel_crt.c
> +++ b/drivers/gpu/drm/i915/intel_crt.c
> @@ -280,8 +280,6 @@ static int intel_crt_dpms(struct drm_connector
> *connector, int mode)
> intel_crtc_update_dpms(crtc);
> }
>
> - intel_modeset_check_state(connector->dev);
> -
> return 0;
> }
>
> diff --git a/drivers/gpu/drm/i915/intel_display.c
> b/drivers/gpu/drm/i915/intel_display.c
> index 3ab0a8a8e702..ba0b68a4209d 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -6360,42 +6360,33 @@ static void intel_encoder_dpms(struct intel_encoder
> *encoder, int mode)
> * internal consistency). */
> static void intel_connector_check_state(struct intel_connector *connector)
> {
> + struct drm_crtc *crtc = connector->base.state->crtc;
> +
> + DRM_DEBUG_KMS("[CONNECTOR:%d:%s]\n",
> + connector->base.base.id,
> + connector->base.name);
> +
> if (connector->get_hw_state(connector)) {
> - struct intel_encoder *encoder = connector->encoder;
> - struct drm_crtc *crtc;
> - bool encoder_enabled;
> - enum pipe pipe;
> + struct drm_encoder *encoder = &connector->encoder->base;
> + struct drm_connector_state *conn_state = connector->base.state;
>
> - DRM_DEBUG_KMS("[CONNECTOR:%d:%s]\n",
> - connector->base.base.id,
> - connector->base.name);
> + I915_STATE_WARN(!crtc,
> + "connector enabled without attached crtc\n");
>
> - /* there is no real hw state for MST connectors */
> - if (connector->mst_port)
>
> Should the above deletion be part of the previous patch?
Huh weird, indeed..
>> +if (!crtc)
> return;
>
> - I915_STATE_WARN(connector->base.dpms == DRM_MODE_DPMS_OFF,
> - "wrong connector dpms state\n");
> - I915_STATE_WARN(connector->base.encoder != &encoder->base,
> - "active connector not linked to encoder\n");
> + I915_STATE_WARN(!crtc->state->active,
> + "connector is active, but attached crtc isn't\n");
>
> - if (encoder) {
> - I915_STATE_WARN(!encoder->connectors_active,
> - "encoder->connectors_active not set\n");
>
> The converted version doesn't check connectors_active. I see it is
> later removed in the patch series, so I assume it is left out on
> purpose, but I think this is worth mentioning in the commit message.
>
>> -
> - encoder_enabled = encoder->get_hw_state(encoder, &pipe);
> - I915_STATE_WARN(!encoder_enabled, "encoder not
> enabled\n");
> - if (I915_STATE_WARN_ON(!encoder->base.crtc))
> - return;
>
> These are also left out. It looks like check_encoder_state() performs
> the same check, but I think the commit message should mention this if
> that's the case.
It's the case.
>> +I915_STATE_WARN(conn_state->best_encoder != encoder,
> + "atomic encoder doesn't match attached encoder\n");
>
> - crtc = encoder->base.crtc;
> -
> - I915_STATE_WARN(!crtc->state->enable,
> - "crtc not enabled\n");
> - I915_STATE_WARN(!to_intel_crtc(crtc)->active, "crtc not
> active\n");
> - I915_STATE_WARN(pipe != to_intel_crtc(crtc)->pipe,
> - "encoder active on the wrong pipe\n");
> - }
> + I915_STATE_WARN(conn_state->crtc != encoder->crtc,
> + "attached encoder crtc differs from connector crtc\n");
> + } else {
> + I915_STATE_WARN(!crtc && connector->base.state->best_encoder,
> + "best encoder set without crtc!\n");
> }
> }
>
> @@ -6444,8 +6435,6 @@ int intel_connector_dpms(struct drm_connector
> *connector, int mode)
> if (connector->encoder)
> intel_encoder_dpms(to_intel_encoder(connector->encoder), mode);
>
> - intel_modeset_check_state(connector->dev);
> -
> return 0;
> }
>
> @@ -12705,20 +12694,22 @@ static void check_wm_state(st
Re: [Intel-gfx] [PATCH 1/3] drm/fbdev: Return -EBUSY when oopsing
On Tue, Jul 28, 2015 at 10:30:08AM -0400, Rob Clark wrote:
> On Tue, Jul 28, 2015 at 7:18 AM, Daniel Vetter wrote:
> > Trying to do anything with kms drivers when oopsing has become a
> > failing proposition. But since we can end up in the fbdev code simply
> > due to the console unblanking that's done unconditionally just
> > removing our panic handler isn't enough. We need to block all fbdev
> > callbacks when oopsing.
> >
> > There was already one in the blank handler, but it failed silently.
> > That makes it impossible for drivers (like i915) who subclass these
> > functions to figure this out.
> >
> > Instead consistently return -EBUSY so that everyone knows that we
> > really don't want to be bothered right now. This also allows us to
> > remove a pile of FIXMEs from the i915 fbdev code (since due to the
> > failure code they now won't attempt to grab dangerous locks any more).
>
> I guess drivers that were keeping fbdev buffer pinned just for opps'
> can stop doing that now..
Well there's still the kgdb stuff, but we might want to nuke that too.
Also fbdev assumes (at least afaik) that the mmap is always valid and it
just writes to it. At least that's why we have the fbdev_set_suspend call
to in suspend/resume to tell it that now it's really no longer cool to
draw fbcon. But userspace doesn't have anything like that I think.
> anyways, lgtm.. for the series:
>
> Reviewed-by: Rob Clark
Thanks for the review, all merged.
-Daniel
>
> > Cc: Dave Airlie
> > Cc: Rodrigo Vivi
> > Signed-off-by: Daniel Vetter
> > ---
> > drivers/gpu/drm/drm_fb_helper.c| 24
> > drivers/gpu/drm/i915/intel_fbdev.c | 21 -
> > 2 files changed, 12 insertions(+), 33 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/drm_fb_helper.c
> > b/drivers/gpu/drm/drm_fb_helper.c
> > index 73f90f7e2f74..77f570a470da 100644
> > --- a/drivers/gpu/drm/drm_fb_helper.c
> > +++ b/drivers/gpu/drm/drm_fb_helper.c
> > @@ -491,14 +491,6 @@ static void drm_fb_helper_dpms(struct fb_info *info,
> > int dpms_mode)
> > int i, j;
> >
> > /*
> > -* fbdev->blank can be called from irq context in case of a panic.
> > -* Since we already have our own special panic handler which will
> > -* restore the fbdev console mode completely, just bail out early.
> > -*/
> > - if (oops_in_progress)
> > - return;
> > -
> > - /*
> > * For each CRTC in this fb, turn the connectors on/off.
> > */
> > drm_modeset_lock_all(dev);
> > @@ -531,6 +523,9 @@ static void drm_fb_helper_dpms(struct fb_info *info,
> > int dpms_mode)
> > */
> > int drm_fb_helper_blank(int blank, struct fb_info *info)
> > {
> > + if (oops_in_progress)
> > + return -EBUSY;
> > +
> > switch (blank) {
> > /* Display: On; HSync: On, VSync: On */
> > case FB_BLANK_UNBLANK:
> > @@ -755,9 +750,10 @@ int drm_fb_helper_setcmap(struct fb_cmap *cmap, struct
> > fb_info *info)
> > int i, j, rc = 0;
> > int start;
> >
> > - if (__drm_modeset_lock_all(dev, !!oops_in_progress)) {
> > + if (oops_in_progress)
> > return -EBUSY;
> > - }
> > +
> > + drm_modeset_lock_all(dev);
> > if (!drm_fb_helper_is_bound(fb_helper)) {
> > drm_modeset_unlock_all(dev);
> > return -EBUSY;
> > @@ -906,6 +902,9 @@ int drm_fb_helper_set_par(struct fb_info *info)
> > struct drm_fb_helper *fb_helper = info->par;
> > struct fb_var_screeninfo *var = &info->var;
> >
> > + if (oops_in_progress)
> > + return -EBUSY;
> > +
> > if (var->pixclock != 0) {
> > DRM_ERROR("PIXEL CLOCK SET\n");
> > return -EINVAL;
> > @@ -931,9 +930,10 @@ int drm_fb_helper_pan_display(struct fb_var_screeninfo
> > *var,
> > int ret = 0;
> > int i;
> >
> > - if (__drm_modeset_lock_all(dev, !!oops_in_progress)) {
> > + if (oops_in_progress)
> > return -EBUSY;
> > - }
> > +
> > + drm_modeset_lock_all(dev);
> > if (!drm_fb_helper_is_bound(fb_helper)) {
> > drm_modeset_unlock_all(dev);
> > return -EBUSY;
> > diff --git a/drivers/gpu/drm/i915/intel_fbdev.c
> > b/drivers/gpu/drm/i915/intel_fbdev.c
> > index eef54feb7545..b763f24e20ef 100644
> > --- a/drivers/gpu/drm/i915/intel_fbdev.c
> > +++ b/drivers/gpu/drm/i915/intel_fbdev.c
> > @@ -55,13 +55,6 @@ static int intel_fbdev_set_par(struct fb_info *info)
> > ret = drm_fb_helper_set_par(info);
> >
> > if (ret == 0) {
> > - /*
> > -* FIXME: fbdev presumes that all callbacks also work from
> > -* atomic contexts and relies on that for emergency oops
> > -* printing. KMS totally doesn't do that and the locking
> > here is
> > -* by far not the only place this goes wron
Re: [Intel-gfx] [PATCH] drm: Add DRM_NOTICE_IF
On 28/07/15 14:14, Chris Wilson wrote:
Styled after WARN_ON/DRM_ERROR_ON, this prints a mild warning message (a
KERN_NOTICE for significant but mild events) that allows us to insert
interesting events without alarming the user or bug reporting tools.
For an example I have changed a DRM_ERROR for being unable to set a
performance enhancement in i915.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/intel_lrc.c | 5 ++---
include/drm/drmP.h | 20
2 files changed, 22 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
index 184d5f2dce21..f62cd78f8691 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -1902,13 +1902,12 @@ static int gen8_init_rcs_context(struct
drm_i915_gem_request *req)
if (ret)
return ret;
- ret = intel_rcs_context_init_mocs(req);
/*
* Failing to program the MOCS is non-fatal.The system will not
* run at peak performance. So generate an error and carry on.
*/
- if (ret)
- DRM_ERROR("MOCS failed to program: expect performance
issues.\n");
+ DRM_NOTICE_IF(intel_rcs_context_init_mocs(req),
+ "MOCS failed to program: expect performance issues.\n");
I like the general idea of the macro, but I don't like this style of
usage, specifically, embedding a function with side-effects inside the
macro call. I'd much prefer
ret = intel_rcs_context_init_mocs(req);
DRM_NOTICE_IF(ret, "MOCS failed to program: expect performance
issues.\n");
I think it's because the shouty MACRO_IN_ALL_CAPS distracts from looking
at the details of the boolean thing-being-tested. Or maybe that anything
that looks like a JUST_PRINT_A_MESSAGE() call should be optional, so I
can delete it or comment it out without making a difference to the rest
of the code - and putting important calls inside the macro invocation
violates that principle.
return intel_lr_context_render_state_init(req);
}
diff --git a/include/drm/drmP.h b/include/drm/drmP.h
index b76af322d812..f2d68d185274 100644
--- a/include/drm/drmP.h
+++ b/include/drm/drmP.h
@@ -181,6 +181,26 @@ void drm_err(const char *format, ...);
})
/**
+ * Mild warning on assertion-esque failure.
+ *
+ * \param cond condition on which to *fail*
+ * \param fmt printf() like format string.
+ * \param arg arguments
+ *
+ * This is similar to WARN_ON but only prints a NOTICE rather than a warning
+ * and the whole stacktrace. It is only intended for mild issues which
+ * while significant do not critically impact the user (such as a performance
+ * issue).
+ */
+#define DRM_NOTICE_IF(cond, fmt, ...) ({ \
+ bool __cond = !!(cond); \
+ if (unlikely(__cond)) \
+ printk(KERN_NOTICE "[" DRM_NAME ":%s] " fmt,\
+ __func__, ##__VA_ARGS__);\
+ unlikely(__cond); \
+})
Why DRM_NOTICE_IF() rather than DRM_NOTICE_ON() ? It might actually be a
more sensible name but sort of loses the connection with the BUG_ON and
WARN_ON macros.
.Dave.
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [REGRESSION BISECTED] System hang during hibernation on EeePC 1015PE
Hi, On ASUS EeePC 1015PE with kernel 3.18 - 4.1, there is a problem very similar to the one fixed for Lenovo by the following commit in the mainline kernel: commit ab3be73fa7b43f4c3648ce29b5fd649ea54d3adb drm/i915: gen4: work around hang during hibernation When I try to put the system to hibernation, the hibernation image is created, the screen turns off but the laptop does not turn off after that (the fan continues to work, the leds are on, etc.) and the system seems to hang. The laptop has Atom CPU N455 and an integrated graphics controller (PCI ID: 8086-a011-1043-83ac) managed by i915 module. Detailed information about the hardware, as well as dmidecode, logs and other data is available here: http://hw.rosalinux.ru/index.php?probe=1c0329fde5 Bisection of the mainline git tree pointed to the same "bad" commit as it was for Lenovo: commit da2bc1b9db3351addd293e5b82757efe1f77ed1d drm/i915: add poweroff_late handler If I revert that change, hibernation works well. Regards, Eugene -- Eugene Shatokhin, ROSA www.rosalab.com ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 3/3] drm/i915: Support DDI lane reversal for DP
The DP outputs connected through a USB Type-C port can have inverted
lanes. To detect that case, we implement autodetection by training only
the first lane if it doesn't work, we assume that we need to invert
the lanes.
Tested on a Chromebook Pixel 2015 (samus) with a USB Type-C to HDMI
adapter and a Dell 4K and some various regular monitors.
Based on 2 patches from the ChromeOS tree by:
Stéphane Marchesin
Todd Broch
Signed-off-by: Benjamin Tissoires
---
drivers/gpu/drm/i915/intel_ddi.c | 13 +
drivers/gpu/drm/i915/intel_dp.c | 36
drivers/gpu/drm/i915/intel_drv.h | 1 +
3 files changed, 50 insertions(+)
diff --git a/drivers/gpu/drm/i915/intel_ddi.c b/drivers/gpu/drm/i915/intel_ddi.c
index 9a40bfb..0b0c1ec 100644
--- a/drivers/gpu/drm/i915/intel_ddi.c
+++ b/drivers/gpu/drm/i915/intel_ddi.c
@@ -2249,6 +2249,7 @@ static void intel_ddi_pre_enable(struct intel_encoder
*intel_encoder)
enum port port = intel_ddi_get_encoder_port(intel_encoder);
int type = intel_encoder->type;
int hdmi_level;
+ bool reversed = false;
if (type == INTEL_OUTPUT_EDP) {
struct intel_dp *intel_dp = enc_to_intel_dp(encoder);
@@ -2295,8 +2296,20 @@ static void intel_ddi_pre_enable(struct intel_encoder
*intel_encoder)
if (type == INTEL_OUTPUT_DISPLAYPORT || type == INTEL_OUTPUT_EDP) {
struct intel_dp *intel_dp = enc_to_intel_dp(encoder);
+ if (IS_BROADWELL(dev) && type == INTEL_OUTPUT_DISPLAYPORT) {
+ intel_ddi_init_dp_buf_reg(intel_encoder);
+ reversed = intel_dp_is_reversed(intel_dp);
+ }
+
intel_ddi_init_dp_buf_reg(intel_encoder);
+ if (IS_BROADWELL(dev)) {
+ if (reversed)
+ intel_dp->DP |= DDI_BUF_PORT_REVERSAL;
+ else
+ intel_dp->DP &= ~DDI_BUF_PORT_REVERSAL;
+ }
+
intel_dp_sink_dpms(intel_dp, DRM_MODE_DPMS_ON);
intel_dp_start_link_train(intel_dp);
intel_dp_complete_link_train(intel_dp);
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index b740987..18280cc 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -3820,6 +3820,42 @@ intel_dp_complete_link_train(struct intel_dp *intel_dp)
intel_dp->DP = DP;
}
+bool intel_dp_is_reversed(struct intel_dp *intel_dp)
+{
+ struct drm_encoder *encoder = &dp_to_dig_port(intel_dp)->base.base;
+ struct drm_device *dev = encoder->dev;
+ struct drm_i915_private *dev_priv = dev->dev_private;
+ uint32_t DP = intel_dp->DP;
+
+ /*
+* Train with 1 lane. There is no guarantee that the monitor supports
+* 2 or 4 lanes, and we wouldn't see any asymetricity with 4 lanes.
+*/
+ const uint8_t lane_count = 1;
+ bool reversed;
+
+ if (!HAS_DDI(dev))
+ return false;
+
+ DP &= ~(DDI_BUF_PORT_REVERSAL | DDI_PORT_WIDTH(4));
+ DP |= DDI_PORT_WIDTH(lane_count);
+
+ I915_WRITE(intel_dp->output_reg, DP);
+ POSTING_READ(intel_dp->output_reg);
+ udelay(600);
+
+ if (!_intel_dp_start_link_train(intel_dp, lane_count, &DP, true))
+ return true;
+
+ reversed = !_intel_dp_complete_link_train(intel_dp, lane_count, &DP,
true);
+
+ /* clear training, we had only one lane */
+ intel_dp->train_set_valid = false;
+
+ return reversed;
+
+}
+
void intel_dp_stop_link_train(struct intel_dp *intel_dp)
{
intel_dp_set_link_train(intel_dp, &intel_dp->DP,
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index 320c9e6..cba00c6 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -1169,6 +1169,7 @@ int intel_dp_sink_crc(struct intel_dp *intel_dp, u8 *crc);
bool intel_dp_compute_config(struct intel_encoder *encoder,
struct intel_crtc_state *pipe_config);
bool intel_dp_is_edp(struct drm_device *dev, enum port port);
+bool intel_dp_is_reversed(struct intel_dp *intel_dp);
enum irqreturn intel_dp_hpd_pulse(struct intel_digital_port *intel_dig_port,
bool long_hpd);
void intel_edp_backlight_on(struct intel_dp *intel_dp);
--
2.4.3
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 2/3] drm/i915: hide errors when probing for a reverse display port
We check the polarity of the attached dp, so it is normal to fail.
Do not send errors to the users.
Signed-off-by: Benjamin Tissoires
---
drivers/gpu/drm/i915/intel_dp.c | 74 -
1 file changed, 58 insertions(+), 16 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index f2352d8..b740987 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -3568,7 +3568,7 @@ static void intel_dp_set_idle_link_train(struct intel_dp
*intel_dp)
/* Enable corresponding port and start training pattern 1 */
static bool
_intel_dp_start_link_train(struct intel_dp *intel_dp, uint8_t lane_count,
- uint32_t *DP)
+ uint32_t *DP, bool probing)
{
struct drm_encoder *encoder = &dp_to_dig_port(intel_dp)->base.base;
struct drm_device *dev = encoder->dev;
@@ -3576,6 +3576,7 @@ _intel_dp_start_link_train(struct intel_dp *intel_dp,
uint8_t lane_count,
uint8_t voltage;
int voltage_tries, loop_tries;
uint8_t link_config[2];
+ char *error_str;
if (HAS_DDI(dev))
intel_ddi_prepare_link_retrain(encoder);
@@ -3600,7 +3601,11 @@ _intel_dp_start_link_train(struct intel_dp *intel_dp,
uint8_t lane_count,
if (!intel_dp_reset_link_train(intel_dp, DP,
DP_TRAINING_PATTERN_1 |
DP_LINK_SCRAMBLING_DISABLE)) {
- DRM_ERROR("failed to enable link training\n");
+ error_str = "failed to enable link training\n";
+ if (!probing)
+ DRM_ERROR(error_str);
+ else
+ DRM_DEBUG(error_str);
return false;
}
@@ -3612,7 +3617,11 @@ _intel_dp_start_link_train(struct intel_dp *intel_dp,
uint8_t lane_count,
drm_dp_link_train_clock_recovery_delay(intel_dp->dpcd);
if (!intel_dp_get_link_status(intel_dp, link_status)) {
- DRM_ERROR("failed to get link status\n");
+ error_str = "failed to get link status\n";
+ if (!probing)
+ DRM_ERROR(error_str);
+ else
+ DRM_DEBUG(error_str);
break;
}
@@ -3632,7 +3641,11 @@ _intel_dp_start_link_train(struct intel_dp *intel_dp,
uint8_t lane_count,
if (!intel_dp_reset_link_train(intel_dp, DP,
DP_TRAINING_PATTERN_1 |
DP_LINK_SCRAMBLING_DISABLE)) {
- DRM_ERROR("failed to enable link training\n");
+ error_str = "failed to enable link training\n";
+ if (!probing)
+ DRM_ERROR(error_str);
+ else
+ DRM_DEBUG(error_str);
return false;
}
continue;
@@ -3645,7 +3658,11 @@ _intel_dp_start_link_train(struct intel_dp *intel_dp,
uint8_t lane_count,
if (i == lane_count) {
++loop_tries;
if (loop_tries == 5) {
- DRM_ERROR("too many full retries, give up\n");
+ error_str = "too many full retries, give up\n";
+ if (!probing)
+ DRM_ERROR(error_str);
+ else
+ DRM_DEBUG(error_str);
break;
}
intel_dp_reset_link_train(intel_dp, DP,
@@ -3659,7 +3676,11 @@ _intel_dp_start_link_train(struct intel_dp *intel_dp,
uint8_t lane_count,
if ((intel_dp->train_set[0] & DP_TRAIN_VOLTAGE_SWING_MASK) ==
voltage) {
++voltage_tries;
if (voltage_tries == 5) {
- DRM_ERROR("too many voltage retries, give
up\n");
+ error_str = "too many voltage retries, give
up\n";
+ if (!probing)
+ DRM_ERROR(error_str);
+ else
+ DRM_DEBUG(error_str);
break;
}
} else
@@ -3668,7 +3689,11 @@ _intel_dp_start_link_train(struct intel_dp *intel_dp,
uint8_t lane_count,
/* Update training set as requested by target */
if (!intel_dp_update_link_train(intel_dp, DP, link_status)) {
- DRM_ERROR("failed to update link training\n");
[Intel-gfx] [PATCH 1/3] drm/i915: add parameters to dp_start_link_train and dp_complete_link_train
In order to detect if the Display Port is reversed or not (when connected
to a USC type-C connector), we need to probe the training with one lane
to check if the polarity is correct.
Factor out the code that we need later on.
This commit has no functional change
Signed-off-by: Benjamin Tissoires
---
drivers/gpu/drm/i915/intel_dp.c | 75 ++---
1 file changed, 47 insertions(+), 28 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index f1b9f93..f2352d8 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -3566,15 +3566,15 @@ static void intel_dp_set_idle_link_train(struct
intel_dp *intel_dp)
}
/* Enable corresponding port and start training pattern 1 */
-void
-intel_dp_start_link_train(struct intel_dp *intel_dp)
+static bool
+_intel_dp_start_link_train(struct intel_dp *intel_dp, uint8_t lane_count,
+ uint32_t *DP)
{
struct drm_encoder *encoder = &dp_to_dig_port(intel_dp)->base.base;
struct drm_device *dev = encoder->dev;
int i;
uint8_t voltage;
int voltage_tries, loop_tries;
- uint32_t DP = intel_dp->DP;
uint8_t link_config[2];
if (HAS_DDI(dev))
@@ -3582,7 +3582,7 @@ intel_dp_start_link_train(struct intel_dp *intel_dp)
/* Write the link configuration data */
link_config[0] = intel_dp->link_bw;
- link_config[1] = intel_dp->lane_count;
+ link_config[1] = lane_count;
if (drm_dp_enhanced_frame_cap(intel_dp->dpcd))
link_config[1] |= DP_LANE_COUNT_ENHANCED_FRAME_EN;
drm_dp_dpcd_write(&intel_dp->aux, DP_LINK_BW_SET, link_config, 2);
@@ -3594,14 +3594,14 @@ intel_dp_start_link_train(struct intel_dp *intel_dp)
link_config[1] = DP_SET_ANSI_8B10B;
drm_dp_dpcd_write(&intel_dp->aux, DP_DOWNSPREAD_CTRL, link_config, 2);
- DP |= DP_PORT_EN;
+ *DP |= DP_PORT_EN;
/* clock recovery */
- if (!intel_dp_reset_link_train(intel_dp, &DP,
+ if (!intel_dp_reset_link_train(intel_dp, DP,
DP_TRAINING_PATTERN_1 |
DP_LINK_SCRAMBLING_DISABLE)) {
DRM_ERROR("failed to enable link training\n");
- return;
+ return false;
}
voltage = 0xff;
@@ -3616,7 +3616,7 @@ intel_dp_start_link_train(struct intel_dp *intel_dp)
break;
}
- if (drm_dp_clock_recovery_ok(link_status,
intel_dp->lane_count)) {
+ if (drm_dp_clock_recovery_ok(link_status, lane_count)) {
DRM_DEBUG_KMS("clock recovery OK\n");
break;
}
@@ -3629,26 +3629,26 @@ intel_dp_start_link_train(struct intel_dp *intel_dp)
DRM_DEBUG_KMS("clock recovery not ok, reset");
/* clear the flag as we are not reusing train set */
intel_dp->train_set_valid = false;
- if (!intel_dp_reset_link_train(intel_dp, &DP,
+ if (!intel_dp_reset_link_train(intel_dp, DP,
DP_TRAINING_PATTERN_1 |
DP_LINK_SCRAMBLING_DISABLE)) {
DRM_ERROR("failed to enable link training\n");
- return;
+ return false;
}
continue;
}
/* Check to see if we've tried the max voltage */
- for (i = 0; i < intel_dp->lane_count; i++)
+ for (i = 0; i < lane_count; i++)
if ((intel_dp->train_set[i] &
DP_TRAIN_MAX_SWING_REACHED) == 0)
break;
- if (i == intel_dp->lane_count) {
+ if (i == lane_count) {
++loop_tries;
if (loop_tries == 5) {
DRM_ERROR("too many full retries, give up\n");
break;
}
- intel_dp_reset_link_train(intel_dp, &DP,
+ intel_dp_reset_link_train(intel_dp, DP,
DP_TRAINING_PATTERN_1 |
DP_LINK_SCRAMBLING_DISABLE);
voltage_tries = 0;
@@ -3667,21 +3667,31 @@ intel_dp_start_link_train(struct intel_dp *intel_dp)
voltage = intel_dp->train_set[0] & DP_TRAIN_VOLTAGE_SWING_MASK;
/* Update training set as requested by target */
- if (!intel_dp_update_link_train(intel_dp, &DP, link_status)) {
+ if (!intel_dp_update_link_train(intel_dp, DP, link_status)) {
DRM_ERROR("failed to u
[Intel-gfx] [PATCH 0/3] drm/i915: fix USB Type-C reversed connector
Hi, plugging a USB Type-C to HDMI adapter on a Chromebook Pixel 2015 works only if the HDMI port is in its normal (not reverted) state. Theorically, the USB chip should provide the information whether or not the lane are resversed, but I could not find anything in the Intel PRM regarding this. So use the technical solution implemented in ChromeOS by Stéphane and Todd: try to train one lane in the normal setting, if it doesn't work, then chances are that the lane are reverted. The ChromeOS commits are: https://chromium.googlesource.com/chromiumos/third_party/kernel/+/e8c654a0a6d466b3a7b0e84fd27e3a7236a2243e https://chromium.googlesource.com/chromiumos/third_party/kernel/+/4fed50fad79ba3fde782d913bac2968b2d0262bc If I could have a Signed-off-by by Stéphane and Todd, that would be even better :) I should also note that while testing this, I discovered 2 regressions in drm-intel-nightly: - b432e5cfd (drm/i915: BDW clock change support): this one prevents the Broadwell-U GPU to correctly set the clock when we connect a 4K monitor over HDMI (30.0 Hz) Using a lower resolution works (the internal display is 2560x1700) I ended up disabling in intel_display.c all of the codes that are broadwell specific, and the default are just working. - aaf5ec2e5 (drm/i915: Handle HPD when it has actually occurred): this one raises a storm of errors: [drm:gen8_irq_handler [i915]] *ERROR* The master control interrupt lied (SDE)! This doesn't seems to affect the DP output, but having that many errors is not always a good sign IMO :) Reverting this commit makes them go away. Cheers, Benjamin Benjamin Tissoires (3): drm/i915: add parameters to dp_start_link_train and dp_complete_link_train drm/i915: hide errors when probing for a reverse display port drm/i915: Support DDI lane reversal for DP drivers/gpu/drm/i915/intel_ddi.c | 13 +++ drivers/gpu/drm/i915/intel_dp.c | 173 ++- drivers/gpu/drm/i915/intel_drv.h | 1 + 3 files changed, 149 insertions(+), 38 deletions(-) -- 2.4.3 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm: Add DRM_NOTICE_IF
On Tue, Jul 28, 2015 at 04:58:27PM +0100, Dave Gordon wrote:
> On 28/07/15 14:14, Chris Wilson wrote:
> >Styled after WARN_ON/DRM_ERROR_ON, this prints a mild warning message (a
> >KERN_NOTICE for significant but mild events) that allows us to insert
> >interesting events without alarming the user or bug reporting tools.
> >
> >For an example I have changed a DRM_ERROR for being unable to set a
> >performance enhancement in i915.
> >
> >Signed-off-by: Chris Wilson
> >---
> > drivers/gpu/drm/i915/intel_lrc.c | 5 ++---
> > include/drm/drmP.h | 20
> > 2 files changed, 22 insertions(+), 3 deletions(-)
> >
> >diff --git a/drivers/gpu/drm/i915/intel_lrc.c
> >b/drivers/gpu/drm/i915/intel_lrc.c
> >index 184d5f2dce21..f62cd78f8691 100644
> >--- a/drivers/gpu/drm/i915/intel_lrc.c
> >+++ b/drivers/gpu/drm/i915/intel_lrc.c
> >@@ -1902,13 +1902,12 @@ static int gen8_init_rcs_context(struct
> >drm_i915_gem_request *req)
> > if (ret)
> > return ret;
> >
> >-ret = intel_rcs_context_init_mocs(req);
> > /*
> > * Failing to program the MOCS is non-fatal.The system will not
> > * run at peak performance. So generate an error and carry on.
> > */
> >-if (ret)
> >-DRM_ERROR("MOCS failed to program: expect performance
> >issues.\n");
> >+DRM_NOTICE_IF(intel_rcs_context_init_mocs(req),
> >+ "MOCS failed to program: expect performance issues.\n");
>
> I like the general idea of the macro, but I don't like this style of
> usage, specifically, embedding a function with side-effects inside
> the macro call. I'd much prefer
>
> ret = intel_rcs_context_init_mocs(req);
> DRM_NOTICE_IF(ret, "MOCS failed to program: expect performance
> issues.\n");
>
> I think it's because the shouty MACRO_IN_ALL_CAPS distracts from
> looking at the details of the boolean thing-being-tested. Or maybe
> that anything that looks like a JUST_PRINT_A_MESSAGE() call should
> be optional, so I can delete it or comment it out without making a
> difference to the rest of the code - and putting important calls
> inside the macro invocation violates that principle.
On the other hand, if it printed the condition that failed as part of
the message, then the function name is much more expressive than ret. I
am also not convinced that the latter is more readable than the former
in this particular example.
> >+#define DRM_NOTICE_IF(cond, fmt, ...) ({\
> >+bool __cond = !!(cond); \
> >+if (unlikely(__cond)) \
> >+printk(KERN_NOTICE "[" DRM_NAME ":%s] " fmt,\
> >+ __func__, ##__VA_ARGS__);\
> >+unlikely(__cond); \
> >+})
>
> Why DRM_NOTICE_IF() rather than DRM_NOTICE_ON() ? It might actually
> be a more sensible name but sort of loses the connection with the
> BUG_ON and WARN_ON macros.
Because I was trying to avoid having it confused with the BUG_ON and the
NOTICE_IF did serve to make it a gentler and milder request to do something.
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/3] drm/fbdev: Return -EBUSY when oopsing
On Tue, Jul 28, 2015 at 11:55 AM, Daniel Vetter wrote:
> On Tue, Jul 28, 2015 at 10:30:08AM -0400, Rob Clark wrote:
>> On Tue, Jul 28, 2015 at 7:18 AM, Daniel Vetter
>> wrote:
>> > Trying to do anything with kms drivers when oopsing has become a
>> > failing proposition. But since we can end up in the fbdev code simply
>> > due to the console unblanking that's done unconditionally just
>> > removing our panic handler isn't enough. We need to block all fbdev
>> > callbacks when oopsing.
>> >
>> > There was already one in the blank handler, but it failed silently.
>> > That makes it impossible for drivers (like i915) who subclass these
>> > functions to figure this out.
>> >
>> > Instead consistently return -EBUSY so that everyone knows that we
>> > really don't want to be bothered right now. This also allows us to
>> > remove a pile of FIXMEs from the i915 fbdev code (since due to the
>> > failure code they now won't attempt to grab dangerous locks any more).
>>
>> I guess drivers that were keeping fbdev buffer pinned just for opps'
>> can stop doing that now..
>
> Well there's still the kgdb stuff, but we might want to nuke that too.
> Also fbdev assumes (at least afaik) that the mmap is always valid and it
> just writes to it. At least that's why we have the fbdev_set_suspend call
> to in suspend/resume to tell it that now it's really no longer cool to
> draw fbcon. But userspace doesn't have anything like that I think.
we couldn't put_pages but we could unpin from iommu/gtt/etc and unpin
the pages so they could be moved by mm at least.. but letting 'em get
swapped out, probably not..
BR,
-R
>> anyways, lgtm.. for the series:
>>
>> Reviewed-by: Rob Clark
>
> Thanks for the review, all merged.
> -Daniel
>
>>
>> > Cc: Dave Airlie
>> > Cc: Rodrigo Vivi
>> > Signed-off-by: Daniel Vetter
>> > ---
>> > drivers/gpu/drm/drm_fb_helper.c| 24
>> > drivers/gpu/drm/i915/intel_fbdev.c | 21 -
>> > 2 files changed, 12 insertions(+), 33 deletions(-)
>> >
>> > diff --git a/drivers/gpu/drm/drm_fb_helper.c
>> > b/drivers/gpu/drm/drm_fb_helper.c
>> > index 73f90f7e2f74..77f570a470da 100644
>> > --- a/drivers/gpu/drm/drm_fb_helper.c
>> > +++ b/drivers/gpu/drm/drm_fb_helper.c
>> > @@ -491,14 +491,6 @@ static void drm_fb_helper_dpms(struct fb_info *info,
>> > int dpms_mode)
>> > int i, j;
>> >
>> > /*
>> > -* fbdev->blank can be called from irq context in case of a panic.
>> > -* Since we already have our own special panic handler which will
>> > -* restore the fbdev console mode completely, just bail out early.
>> > -*/
>> > - if (oops_in_progress)
>> > - return;
>> > -
>> > - /*
>> > * For each CRTC in this fb, turn the connectors on/off.
>> > */
>> > drm_modeset_lock_all(dev);
>> > @@ -531,6 +523,9 @@ static void drm_fb_helper_dpms(struct fb_info *info,
>> > int dpms_mode)
>> > */
>> > int drm_fb_helper_blank(int blank, struct fb_info *info)
>> > {
>> > + if (oops_in_progress)
>> > + return -EBUSY;
>> > +
>> > switch (blank) {
>> > /* Display: On; HSync: On, VSync: On */
>> > case FB_BLANK_UNBLANK:
>> > @@ -755,9 +750,10 @@ int drm_fb_helper_setcmap(struct fb_cmap *cmap,
>> > struct fb_info *info)
>> > int i, j, rc = 0;
>> > int start;
>> >
>> > - if (__drm_modeset_lock_all(dev, !!oops_in_progress)) {
>> > + if (oops_in_progress)
>> > return -EBUSY;
>> > - }
>> > +
>> > + drm_modeset_lock_all(dev);
>> > if (!drm_fb_helper_is_bound(fb_helper)) {
>> > drm_modeset_unlock_all(dev);
>> > return -EBUSY;
>> > @@ -906,6 +902,9 @@ int drm_fb_helper_set_par(struct fb_info *info)
>> > struct drm_fb_helper *fb_helper = info->par;
>> > struct fb_var_screeninfo *var = &info->var;
>> >
>> > + if (oops_in_progress)
>> > + return -EBUSY;
>> > +
>> > if (var->pixclock != 0) {
>> > DRM_ERROR("PIXEL CLOCK SET\n");
>> > return -EINVAL;
>> > @@ -931,9 +930,10 @@ int drm_fb_helper_pan_display(struct
>> > fb_var_screeninfo *var,
>> > int ret = 0;
>> > int i;
>> >
>> > - if (__drm_modeset_lock_all(dev, !!oops_in_progress)) {
>> > + if (oops_in_progress)
>> > return -EBUSY;
>> > - }
>> > +
>> > + drm_modeset_lock_all(dev);
>> > if (!drm_fb_helper_is_bound(fb_helper)) {
>> > drm_modeset_unlock_all(dev);
>> > return -EBUSY;
>> > diff --git a/drivers/gpu/drm/i915/intel_fbdev.c
>> > b/drivers/gpu/drm/i915/intel_fbdev.c
>> > index eef54feb7545..b763f24e20ef 100644
>> > --- a/drivers/gpu/drm/i915/intel_fbdev.c
>> > +++ b/drivers/gpu/drm/i915/intel_fbdev.c
>> > @@ -55,13 +55,6 @@ static int intel_fbdev_set_par(struct fb_info *info)
>> > ret = drm_fb_helper_set_par(info);
>> >
Re: [Intel-gfx] [PATCH 2/3] drm/i915: hide errors when probing for a reverse display port
On Tue, Jul 28, 2015 at 12:03:28PM -0400, Benjamin Tissoires wrote: > We check the polarity of the attached dp, so it is normal to fail. > Do not send errors to the users. if (probe) DRM_DEBUG else DRM_ERROR is fairly offensive. It strikes me that you could make each of these functions report the failure to the caller (have the caller even do so error handling!) and as part of that have the caller report an error and so demote all of these to DRM_DEBUG_KMS(). Who knows, actually doing some error handling may make monitor training more reliable! Or we may even get carried away and report the failure all the way back to userspace. -Chris -- Chris Wilson, Intel Open Source Technology Centre ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 2/2] drm/i915: Soften error messages in i915_gem_object_create_from_data()
On 28/07/15 14:27, Chris Wilson wrote:
Since we already return -EFAULT to the user, emitting an error message
*and* WARN is overkill. If the caller is upset, they can do so, but for
the purposes of debugging we need only log the erroneous values.
Signed-off-by: Chris Wilson
Cc:: Alex Dai
Cc: Dave Gordon
Cc: Tom O'Rourke
---
drivers/gpu/drm/i915/i915_gem.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index c1ded76a6eb4..2039798f4403 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -5243,8 +5243,8 @@ i915_gem_object_create_from_data(struct drm_device *dev,
i915_gem_object_unpin_pages(obj);
- if (WARN_ON(bytes != size)) {
- DRM_ERROR("Incomplete copy, wrote %zu of %zu", bytes, size);
+ if (bytes != size) {
+ DRM_DEBUG_GEM("Incomplete copy, wrote %zu of %zu", bytes, size);
ret = -EFAULT;
goto fail;
}
I agree the WARN_ON() is overkill, but I think maybe the DRM_ERROR() is
useful. The (one current) caller will report an error, but at that level
it's just:
DRM_ERROR("Failed to fetch GuC firmware from %s\n", ...)
with no more detail as to whether that was due to file-not-found,
bad-file-size, out-of-memory, failed-to-get-pages, or any of the other
errors that might arise.
At present this code is only called once, and I think this copy failure
"shouldn't ever happen", so it won't be filling the logfile. But
emitting the error here for the truly unexpected case (as opposed to the
commonplace "out-of-memory" and suchlike) helps current and future
callers avoid doing the detailed failure analysis.
Or maybe it's a good place for your (other) new macro?
DRM_NOTICE_ON(bytes != size,
"Incomplete copy, wrote %zu of %zu", bytes, size);
.Dave.
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 2/2] drm/i915: Soften error messages in i915_gem_object_create_from_data()
On Tue, Jul 28, 2015 at 05:29:09PM +0100, Dave Gordon wrote:
> On 28/07/15 14:27, Chris Wilson wrote:
> >Since we already return -EFAULT to the user, emitting an error message
> >*and* WARN is overkill. If the caller is upset, they can do so, but for
> >the purposes of debugging we need only log the erroneous values.
> >
> >Signed-off-by: Chris Wilson
> >Cc:: Alex Dai
> >Cc: Dave Gordon
> >Cc: Tom O'Rourke
> >---
> > drivers/gpu/drm/i915/i915_gem.c | 4 ++--
> > 1 file changed, 2 insertions(+), 2 deletions(-)
> >
> >diff --git a/drivers/gpu/drm/i915/i915_gem.c
> >b/drivers/gpu/drm/i915/i915_gem.c
> >index c1ded76a6eb4..2039798f4403 100644
> >--- a/drivers/gpu/drm/i915/i915_gem.c
> >+++ b/drivers/gpu/drm/i915/i915_gem.c
> >@@ -5243,8 +5243,8 @@ i915_gem_object_create_from_data(struct drm_device
> >*dev,
> >
> > i915_gem_object_unpin_pages(obj);
> >
> >-if (WARN_ON(bytes != size)) {
> >-DRM_ERROR("Incomplete copy, wrote %zu of %zu", bytes, size);
> >+if (bytes != size) {
> >+DRM_DEBUG_GEM("Incomplete copy, wrote %zu of %zu", bytes, size);
> > ret = -EFAULT;
> > goto fail;
> > }
>
> I agree the WARN_ON() is overkill, but I think maybe the DRM_ERROR()
> is useful. The (one current) caller will report an error, but at
> that level it's just:
>
> DRM_ERROR("Failed to fetch GuC firmware from %s\n", ...)
>
> with no more detail as to whether that was due to file-not-found,
> bad-file-size, out-of-memory, failed-to-get-pages, or any of the
> other errors that might arise.
>
> At present this code is only called once, and I think this copy
> failure "shouldn't ever happen", so it won't be filling the logfile.
> But emitting the error here for the truly unexpected case (as
> opposed to the commonplace "out-of-memory" and suchlike) helps
> current and future callers avoid doing the detailed failure
> analysis.
The message is still there though, it's just a debug message for the
developer. And all it could mean is that the caller passed in a bad
value for the size.
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 11/13 v4] drm/i915: Integrate GuC-based command submission
On 07/28/2015 06:59 AM, Dave Gordon wrote:
On 27/07/15 16:57, O'Rourke, Tom wrote:
> On Thu, Jul 09, 2015 at 07:29:12PM +0100, Dave Gordon wrote:
>> From: Alex Dai
>>
>> GuC-based submission is mostly the same as execlist mode, up to
>> intel_logical_ring_advance_and_submit(), where the context being
>> dispatched would be added to the execlist queue; at this point
>> we submit the context to the GuC backend instead.
>>
>> There are, however, a few other changes also required, notably:
>> 1. Contexts must be pinned at GGTT addresses accessible by the GuC
>> i.e. NOT in the range [0..WOPCM_SIZE), so we have to add the
>> PIN_OFFSET_BIAS flag to the relevant GGTT-pinning calls.
>>
>> 2. The GuC's TLB must be invalidated after a context is pinned at
>> a new GGTT address.
[snip]
>> static int gen8_init_rcs_context(struct drm_i915_gem_request *req)
>> {
>> + struct drm_i915_private *dev_priv = req->i915;
>>int ret;
>>
>> + /* Invalidate GuC TLB. */
>> + if (i915.enable_guc_submission)
>> + I915_WRITE(GEN8_GTCR, GEN8_GTCR_INVALIDATE);
>> +
>
> [TOR:] This invalidation is in the init_context for render
> ring but not the other rings. Is this needed for other
> rings? Or, should this invalidation happen at a different
> level? It seems this may depend on the on render ring being
> initialized first.
>
> Thanks,
> Tom
Hi Tom,
it looks like this is redundant here in the case where its called from
the non-default-context case of intel_lr_context_deferred_create(); but
when called from i915_gem_init_hw() [via i915_gem_context_enable()] it
wouldn't be, because the GuC TLB wouldn't have been flushed since the
default context was pinned [which is in a completely different path
through intel_lr_context_deferred_create()!].
However, if we add a TLB flush just after that point, we can remove this
one here, with several advantages:
* firstly, that path is taken just once, rather than every time a new
render context is created, and
* secondly, each flush can be specifically associated with a pin-to-gtt
call that includes the (PIN_OFFSET_BIAS | GUC_WOPCM_SIZE_VALUE) flags,
showing that the pinned object is of interest to the GuC.
I'll also move the existing TLB flushes in guc_submission.c and
guc_loader.c so that they're also just after the relevant 'pin' calls.
Aye. -Alex
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 2/2] drm/i915: Soften error messages in i915_gem_object_create_from_data()
On 28/07/15 17:34, Chris Wilson wrote:
On Tue, Jul 28, 2015 at 05:29:09PM +0100, Dave Gordon wrote:
On 28/07/15 14:27, Chris Wilson wrote:
Since we already return -EFAULT to the user, emitting an error message
*and* WARN is overkill. If the caller is upset, they can do so, but for
the purposes of debugging we need only log the erroneous values.
Signed-off-by: Chris Wilson
Cc:: Alex Dai
Cc: Dave Gordon
Cc: Tom O'Rourke
---
drivers/gpu/drm/i915/i915_gem.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index c1ded76a6eb4..2039798f4403 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -5243,8 +5243,8 @@ i915_gem_object_create_from_data(struct drm_device *dev,
i915_gem_object_unpin_pages(obj);
- if (WARN_ON(bytes != size)) {
- DRM_ERROR("Incomplete copy, wrote %zu of %zu", bytes, size);
+ if (bytes != size) {
+ DRM_DEBUG_GEM("Incomplete copy, wrote %zu of %zu", bytes, size);
ret = -EFAULT;
goto fail;
}
I agree the WARN_ON() is overkill, but I think maybe the DRM_ERROR()
is useful. The (one current) caller will report an error, but at
that level it's just:
DRM_ERROR("Failed to fetch GuC firmware from %s\n", ...)
with no more detail as to whether that was due to file-not-found,
bad-file-size, out-of-memory, failed-to-get-pages, or any of the
other errors that might arise.
At present this code is only called once, and I think this copy
failure "shouldn't ever happen", so it won't be filling the logfile.
But emitting the error here for the truly unexpected case (as
opposed to the commonplace "out-of-memory" and suchlike) helps
current and future callers avoid doing the detailed failure
analysis.
The message is still there though, it's just a debug message for the
developer. And all it could mean is that the caller passed in a bad
value for the size.
-Chris
I'm not sure you could trigger it with a bad size. The copy-target has
just been allocated (in this function) and so is known to be the right
size. If the size specified is larger than the data source buffer, the
copy will likely have OOPSed anyway - or just continued with whatever
happens to be next in memory.
So AFAICT the bytes vs. size mismatch can only happen if something is
broken in the GEM (or SG-list) framework, hence worth announcing. If you
reload the driver with debug enabled, it probably won't happen again
(and you would have to reload, not just change the debug level, because
at present this is only called during driver load).
If not an actual ERROR, then maybe a NOTICE is the right level:
DRM_NOTICE_IF(bytes != size,
"Incomplete copy, wrote %zu of %zu", bytes, size);
so the the support engineer who sees the "failed to fetch" message in
the log at least gets some hint about what particular weirdness has
occurred on this occasion. (Other cases are easier: missing firmware
file is obvious, wrong version gets a specific ERROR in the log; and
these errors would be persistent. But a copy-fail would be a puzzle.)
.Dave.
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 2/2] drm/i915: Soften error messages in i915_gem_object_create_from_data()
On Tue, Jul 28, 2015 at 06:09:16PM +0100, Dave Gordon wrote:
> On 28/07/15 17:34, Chris Wilson wrote:
> >On Tue, Jul 28, 2015 at 05:29:09PM +0100, Dave Gordon wrote:
> >>On 28/07/15 14:27, Chris Wilson wrote:
> >>>Since we already return -EFAULT to the user, emitting an error message
> >>>*and* WARN is overkill. If the caller is upset, they can do so, but for
> >>>the purposes of debugging we need only log the erroneous values.
> >>>
> >>>Signed-off-by: Chris Wilson
> >>>Cc:: Alex Dai
> >>>Cc: Dave Gordon
> >>>Cc: Tom O'Rourke
> >>>---
> >>> drivers/gpu/drm/i915/i915_gem.c | 4 ++--
> >>> 1 file changed, 2 insertions(+), 2 deletions(-)
> >>>
> >>>diff --git a/drivers/gpu/drm/i915/i915_gem.c
> >>>b/drivers/gpu/drm/i915/i915_gem.c
> >>>index c1ded76a6eb4..2039798f4403 100644
> >>>--- a/drivers/gpu/drm/i915/i915_gem.c
> >>>+++ b/drivers/gpu/drm/i915/i915_gem.c
> >>>@@ -5243,8 +5243,8 @@ i915_gem_object_create_from_data(struct drm_device
> >>>*dev,
> >>>
> >>> i915_gem_object_unpin_pages(obj);
> >>>
> >>>- if (WARN_ON(bytes != size)) {
> >>>- DRM_ERROR("Incomplete copy, wrote %zu of %zu", bytes, size);
> >>>+ if (bytes != size) {
> >>>+ DRM_DEBUG_GEM("Incomplete copy, wrote %zu of %zu", bytes, size);
> >>> ret = -EFAULT;
> >>> goto fail;
> >>> }
> >>
> >>I agree the WARN_ON() is overkill, but I think maybe the DRM_ERROR()
> >>is useful. The (one current) caller will report an error, but at
> >>that level it's just:
> >>
> >> DRM_ERROR("Failed to fetch GuC firmware from %s\n", ...)
> >>
> >>with no more detail as to whether that was due to file-not-found,
> >>bad-file-size, out-of-memory, failed-to-get-pages, or any of the
> >>other errors that might arise.
> >>
> >>At present this code is only called once, and I think this copy
> >>failure "shouldn't ever happen", so it won't be filling the logfile.
> >>But emitting the error here for the truly unexpected case (as
> >>opposed to the commonplace "out-of-memory" and suchlike) helps
> >>current and future callers avoid doing the detailed failure
> >>analysis.
> >
> >The message is still there though, it's just a debug message for the
> >developer. And all it could mean is that the caller passed in a bad
> >value for the size.
> >-Chris
>
> I'm not sure you could trigger it with a bad size. The copy-target
> has just been allocated (in this function) and so is known to be the
> right size. If the size specified is larger than the data source
> buffer, the copy will likely have OOPSed anyway - or just continued
> with whatever happens to be next in memory.
>
> So AFAICT the bytes vs. size mismatch can only happen if something
> is broken in the GEM (or SG-list) framework, hence worth announcing.
> If you reload the driver with debug enabled, it probably won't
> happen again (and you would have to reload, not just change the
> debug level, because at present this is only called during driver
> load).
Hmm, I was thinking that the access of data[size] would be checked and
the likely cause of the failure (thinking this was basically just
another copy_from_user check). I disagree that this one failure is any
more significant that any of the other internal failure cases then.
> If not an actual ERROR, then maybe a NOTICE is the right level:
No.
> DRM_NOTICE_IF(bytes != size,
> "Incomplete copy, wrote %zu of %zu", bytes, size);
>
> so the the support engineer who sees the "failed to fetch" message
> in the log at least gets some hint about what particular weirdness
> has occurred on this occasion. (Other cases are easier: missing
> firmware file is obvious, wrong version gets a specific ERROR in the
> log; and these errors would be persistent. But a copy-fail would be
> a puzzle.)
That equally applies to a debug message. And even more so since EFAULT
here is unique. Under my assumption bytes would be recognisable in the
context of the caller, however if it ever happens it will be an equally
opaque value.
Given your arguments here, I think we should just remove it.
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] Error in inner loop in validate_cmds_sorted / out of bounds issue
Hi,
On Tue, 28 Jul 2015 10:14:51 +0200
Daniel Vetter wrote:
> > Indeed, nice catch. Could you please read
> > Documentation/SubmittingPatches and apply your Signed-off-by and
> > then we can accept this patch under your authorship.
> >
> > Preferrably this is two patches, (a) fix the tables, (b) fix the
> > validator. That way we can delay enabling the validator if we need
> > to fix the tables for others.
I think I have checked all tables, not just the ones used on my gpu,
they should be fine. But I've splittet the patch.
> Also can you please add signed-off-by lines to your patch when
> resubmitting? See Documentation/SubmittingPatches for all the details.
The patch already had a "Signed-off-by" line.
The checkpatch script complains that it doesn't like the formatting of
the CMD command. However I won't change that in this patch, as this is
how the whole file is formatted. If this is wanted I can submit a patch
changing the formatting afterwards, but I think this is an unrelated
change.
Please apply.
--
Hanno Böck
http://hboeck.de/
mail/jabber: ha...@hboeck.de
GPG: BBB51E42
Properly sort cmd tables.
Signed-off-by: Hanno Boeck
diff --git a/drivers/gpu/drm/i915/i915_cmd_parser.c b/drivers/gpu/drm/i915/i915_cmd_parser.c
index 306d9e4..5fdd8c8 100644
--- a/drivers/gpu/drm/i915/i915_cmd_parser.c
+++ b/drivers/gpu/drm/i915/i915_cmd_parser.c
@@ -151,8 +151,8 @@ static const struct drm_i915_cmd_descriptor render_cmds[] = {
CMD( MI_ARB_ON_OFF,SMI,F, 1, R ),
CMD( MI_PREDICATE, SMI,F, 1, S ),
CMD( MI_TOPOLOGY_FILTER, SMI,F, 1, S ),
- CMD( MI_DISPLAY_FLIP, SMI, !F, 0xFF, R ),
CMD( MI_SET_APPID, SMI,F, 1, S ),
+ CMD( MI_DISPLAY_FLIP, SMI, !F, 0xFF, R ),
CMD( MI_SET_CONTEXT, SMI, !F, 0xFF, R ),
CMD( MI_URB_CLEAR, SMI, !F, 0xFF, S ),
CMD( MI_STORE_DWORD_IMM, SMI, !F, 0x3F, B,
Fix loop checking cmd tables.
Signed-off-by: Hanno Boeck
diff --git a/drivers/gpu/drm/i915/i915_cmd_parser.c b/drivers/gpu/drm/i915/i915_cmd_parser.c
index 306d9e4..3a53bf3 100644
--- a/drivers/gpu/drm/i915/i915_cmd_parser.c
+++ b/drivers/gpu/drm/i915/i915_cmd_parser.c
@@ -564,7 +564,7 @@ static bool validate_cmds_sorted(struct intel_engine_cs *ring,
for (j = 0; j < table->count; j++) {
const struct drm_i915_cmd_descriptor *desc =
-&table->table[i];
+&table->table[j];
u32 curr = desc->cmd.value & desc->cmd.mask;
if (curr < previous) {
pgpJAk7z38zpZ.pgp
Description: OpenPGP digital signature
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 0/4] Add support for Hyperlinks and Markup on kernel-doc
On 07/25/2015 07:20 AM, Stephan Mueller wrote: > Am Donnerstag, 23. Juli 2015, 15:16:23 schrieb Danilo Cesar Lemes de Paula: > > Hi Danilo, > >> This series add supports for hyperlink cross-references on Docbooks and >> an optional markup syntax for in-source Documentation. > > Can you please give an example what you mean with the latter? Sure, take a look on https://people.collabora.com/~danilo/intel/Documentation.MarkDown/DocBook/drm/API-drm-dev-ref.html The words "must" and "any" are emphasised, it's different from the original https://people.collabora.com/~danilo/intel/Documentation.old/DocBook/drm/API-drm-dev-ref.html That page is created from drivers/gpu/drm/drm_drv.c, part of drm_dev_ref Documentation, where the text is "You *must* already own". This is a ridiculous simple example but there are some bullet lists, numbered lists and code example in my patch 4/4. It can also do asciiart and tables. I'm sending a v2 of this patch series later as I have some fixes for it. Danilo Cesar ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] Error in inner loop in validate_cmds_sorted / out of bounds issue
On Tue, Jul 28, 2015 at 11:14:19AM -0700, Hanno Böck wrote:
> Hi,
>
> On Tue, 28 Jul 2015 10:14:51 +0200
> Daniel Vetter wrote:
>
> > > Indeed, nice catch. Could you please read
> > > Documentation/SubmittingPatches and apply your Signed-off-by and
> > > then we can accept this patch under your authorship.
> > >
> > > Preferrably this is two patches, (a) fix the tables, (b) fix the
> > > validator. That way we can delay enabling the validator if we need
> > > to fix the tables for others.
>
> I think I have checked all tables, not just the ones used on my gpu,
> they should be fine. But I've splittet the patch.
>
> > Also can you please add signed-off-by lines to your patch when
> > resubmitting? See Documentation/SubmittingPatches for all the details.
>
> The patch already had a "Signed-off-by" line.
>
> The checkpatch script complains that it doesn't like the formatting of
> the CMD command. However I won't change that in this patch, as this is
> how the whole file is formatted. If this is wanted I can submit a patch
> changing the formatting afterwards, but I think this is an unrelated
> change.
>
> Please apply.
>
> --
> Hanno Böck
> http://hboeck.de/
>
> mail/jabber: ha...@hboeck.de
> GPG: BBB51E42
> Properly sort cmd tables.
drm/i915: Properly sort MI coomand table
In the future, we may want to speed up command/register searching using
a bisection and so we require them to be in ascending order respectively
by command value or register address. However, this was not true for one
pair in the MI table; make it so.
> Signed-off-by: Hanno Boeck
Reviewed-by: Chris Wilson
> diff --git a/drivers/gpu/drm/i915/i915_cmd_parser.c
> b/drivers/gpu/drm/i915/i915_cmd_parser.c
> index 306d9e4..5fdd8c8 100644
> --- a/drivers/gpu/drm/i915/i915_cmd_parser.c
> +++ b/drivers/gpu/drm/i915/i915_cmd_parser.c
> @@ -151,8 +151,8 @@ static const struct drm_i915_cmd_descriptor render_cmds[]
> = {
> CMD( MI_ARB_ON_OFF,SMI,F, 1, R ),
> CMD( MI_PREDICATE, SMI,F, 1, S ),
> CMD( MI_TOPOLOGY_FILTER, SMI,F, 1, S ),
> - CMD( MI_DISPLAY_FLIP, SMI, !F, 0xFF, R ),
> CMD( MI_SET_APPID, SMI,F, 1, S ),
> + CMD( MI_DISPLAY_FLIP, SMI, !F, 0xFF, R ),
> CMD( MI_SET_CONTEXT, SMI, !F, 0xFF, R ),
> CMD( MI_URB_CLEAR, SMI, !F, 0xFF, S ),
> CMD( MI_STORE_DWORD_IMM, SMI, !F, 0x3F, B,
> Fix loop checking cmd tables.
drm/i915: Fix command parser table validator
As we may like to use a bisection search on the tables in future, we
need them to be ordered. For convenience we expect the compiled tables
to be order and check on initialisation. However, the validator used the
wrong iterators failed to spot the misordered MI tables and instead
walked off into the unknown (as spotted by kasan).
> Signed-off-by: Hanno Boeck
Reviewed-by: Chris Wilson
> diff --git a/drivers/gpu/drm/i915/i915_cmd_parser.c
> b/drivers/gpu/drm/i915/i915_cmd_parser.c
> index 306d9e4..3a53bf3 100644
> --- a/drivers/gpu/drm/i915/i915_cmd_parser.c
> +++ b/drivers/gpu/drm/i915/i915_cmd_parser.c
> @@ -564,7 +564,7 @@ static bool validate_cmds_sorted(struct intel_engine_cs
> *ring,
>
> for (j = 0; j < table->count; j++) {
> const struct drm_i915_cmd_descriptor *desc =
> - &table->table[i];
> + &table->table[j];
> u32 curr = desc->cmd.value & desc->cmd.mask;
>
> if (curr < previous) {
--
Chris Wilson, Intel Open Source Technology Centre
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 07/13 v4] drm/i915: GuC submission setup, phase 1
On 28/07/15 16:16, Dave Gordon wrote: On 28/07/15 00:12, O'Rourke, Tom wrote: On Mon, Jul 27, 2015 at 03:41:31PM -0700, Yu Dai wrote: On 07/24/2015 03:31 PM, O'Rourke, Tom wrote: [TOR:] When I see "phase 1" I also look for "phase 2". A subject that better describes the change in this patch would help. On Thu, Jul 09, 2015 at 07:29:08PM +0100, Dave Gordon wrote: From: Alex Dai This adds the first of the data structures used to communicate with the GuC (the pool of guc_context structures). We create a GuC-specific wrapper round the GEM object allocator as all GEM objects shared with the GuC must be pinned into GGTT space at an address that is NOT in the range [0..WOPCM_SIZE), as that range of GGTT addresses is not accessible to the GuC (from the GuC's point of view, it's permanently reserved for other objects such as the BootROM & SRAM). [TOR:] I would like a clarfication on the excluded range. The excluded range should be 0 to "size for guc within WOPCM area" and not 0 to "size of WOPCM area". Nope, GGTT range [0..WOPCM_SIZE) should be excluded from GuC usage. BSpec clearly says, from 0 to WOPCM_TOP-1 is for BootROM, SRAM and WOPCM. From WOPCM_TOP and above is GFX DRAM. Be note that, that GGTT space is still available to any gfx obj as long as it is not accessed by GuC (OK to pass through GuC). [TOR:] Should we take a closer look at the pin offset bias for guc objects? GUC_WOPCM_SIZE_VALUE is not the full size of WOPCM area. I'm inclined to set the bias to GUC_WOPCM_TOP, and then define that as the sum of GUC_WOPCM_OFFSET_VALUE and GUC_WOPCM_SIZE_VALUE. That seems to be what the BSpec pages "WriteOnceProtectedContentMemory (WOPCM) Management" and "WOPCM Memory Map" suggest, although I think they're pretty unclear on the details :( Do you (both) agree this would be the right value? Actually I've changed my mind (again). On rereading this stuff, I now think that GUC_WOPCM_TOP is the same as the value put into the SIZE register. The (physical) range between the (real) WOPCM BASE and that plus the GUC WOPCM OFFSET isn't part of the GuC address space at all, so GuC address 0 maps (would map) to (real WOPCM BASE+GUC WOPCM OFFSET) in physical addresses, except that the bottom 80k is shadowed by the bootrom and SRAM; and then the SIZE register defines the size of the range from (GuC address) 0 to GUC_WOPCM_TOP; and then higher addresses map through the GTT as expected. Or so I think. Does anyone know for sure? Please let me know ASAP as I want to submit an updated patchset tomorrow! Thanks, .Dave. ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2 0/4] Add support for Hyperlinks and Markup on kernel-doc
This series add supports for hyperlink cross-references on Docbooks and an optional markup syntax for in-source Documentation. eg: https://people.collabora.com/~danilo/intel/Documentation.MarkDown/DocBook/drm/API-drm-dev-ref.html old: https://people.collabora.com/~danilo/intel/Documentation.old/DocBook/drm/API-drm-dev-ref.html Danilo Cesar Lemes de Paula (4): scripts/kernel-doc: Adding cross-reference links to html documentation. scripts/kernel-doc: Replacing highlights hash by an array scripts/kernel-doc: Adding infrastructure for markdown support drm/doc: Convert to markdown Documentation/DocBook/Makefile | 68 + Documentation/DocBook/drm.tmpl | 86 drivers/gpu/drm/drm_modes.c| 12 +-- drivers/gpu/drm/drm_modeset_lock.c | 14 ++- drivers/gpu/drm/drm_prime.c| 16 ++- drivers/gpu/drm/i915/i915_reg.h| 48 - include/drm/drm_vma_manager.h | 10 +- scripts/docproc.c | 54 +++--- scripts/kernel-doc | 170 ++- scripts/kernel-doc-xml-ref | 198 + 10 files changed, 454 insertions(+), 222 deletions(-) create mode 100755 scripts/kernel-doc-xml-ref -- 2.4.6 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2 4/4] drm/doc: Convert to markdown
DRM Docbook is now Markdown ready. This means its doc is able to use markdown text on it. * Documentation/DocBook/drm.tmpl: Contains a table duplicated from drivers/gpu/drm/i915/i915_reg.h. This is not needed anymore * drivers/gpu/drm/drm_modeset_lock.c: had a code example that used to look pretty bad on html. Fixed by using proper code markup. * drivers/gpu/drm/drm_prime.c: Remove spaces between lines to make a proper markup list. * drivers/gpu/drm/i915/i915_reg.h: Altought pandoc supports tables, it doesn't support table cell spanning. But we can use fixed-width for those special cases. * include/drm/drm_vma_manager.h: Another code example that should be proper indented with four spaces. Signed-off-by: Danilo Cesar Lemes de Paula Cc: Randy Dunlap Cc: Daniel Vetter Cc: Laurent Pinchart Cc: Jonathan Corbet Cc: Herbert Xu Cc: Stephan Mueller Cc: Michal Marek Cc: linux-ker...@vger.kernel.org Cc: linux-...@vger.kernel.org Cc: intel-gfx Cc: dri-devel --- Changelog: v2: * Improve markup in drivers/gpu/drm/drm_modes.c Documentation/DocBook/Makefile | 2 +- Documentation/DocBook/drm.tmpl | 86 -- drivers/gpu/drm/drm_modes.c| 12 +++--- drivers/gpu/drm/drm_modeset_lock.c | 14 +++ drivers/gpu/drm/drm_prime.c| 16 +++ drivers/gpu/drm/i915/i915_reg.h| 48 ++--- include/drm/drm_vma_manager.h | 10 ++--- 7 files changed, 48 insertions(+), 140 deletions(-) diff --git a/Documentation/DocBook/Makefile b/Documentation/DocBook/Makefile index 8e6d022..f2408b3 100644 --- a/Documentation/DocBook/Makefile +++ b/Documentation/DocBook/Makefile @@ -17,7 +17,7 @@ DOCBOOKS := z8530book.xml device-drivers.xml \ tracepoint.xml drm.xml media_api.xml w1.xml \ writing_musb_glue_layer.xml crypto-API.xml -MARKDOWNREADY := +MARKDOWNREADY := drm.xml include Documentation/DocBook/media/Makefile diff --git a/Documentation/DocBook/drm.tmpl b/Documentation/DocBook/drm.tmpl index 2fb9a54..4fb4636 100644 --- a/Documentation/DocBook/drm.tmpl +++ b/Documentation/DocBook/drm.tmpl @@ -4073,92 +4073,6 @@ int num_ioctls; DPIO !Pdrivers/gpu/drm/i915/i915_reg.h DPIO - - Dual channel PHY (VLV/CHV/BXT) - - - - - - - - - - - - - - - - - - CH0 - CH1 - - - - - CMN/PLL/REF - CMN/PLL/REF - - - PCS01 - PCS23 - PCS01 - PCS23 - - - TX0 - TX1 - TX2 - TX3 - TX0 - TX1 - TX2 - TX3 - - - DDI0 - DDI1 - - - - - - Single channel PHY (CHV/BXT) - - - - - - - - - - - CH0 - - - - - CMN/PLL/REF - - - PCS01 - PCS23 - - - TX0 - TX1 - TX2 - TX3 - - - DDI2 - - - - diff --git a/drivers/gpu/drm/drm_modes.c b/drivers/gpu/drm/drm_modes.c index cd74a09..9480464 100644 --- a/drivers/gpu/drm/drm_modes.c +++ b/drivers/gpu/drm/drm_modes.c @@ -553,10 +553,10 @@ EXPORT_SYMBOL(drm_gtf_mode_complex); * drivers/video/fbmon.c * * Standard GTF parameters: - * M = 600 - * C = 40 - * K = 128 - * J = 20 + * M = 600 + * C = 40 + * K = 128 + * J = 20 * * Returns: * The modeline based on the GTF algorithm stored in a drm_display_mode object. @@ -1212,7 +1212,7 @@ EXPORT_SYMBOL(drm_mode_connector_list_update); * This uses the same parameters as the fb modedb.c, except for an extra * force-enable, force-enable-digital and force-disable bit at the end: * - * x[M][R][-][@][i][m][eDd] + * x[M][R][-][@][i][m][eDd] * * The intermediate drm_cmdline_mode structure is required to store additional * options from the command line modline like the force-enable/disable flag. @@ -1491,4 +1491,4 @@ int drm_mode_convert_umode(struct drm_display_mode *out, out: return ret; -} \ No newline at end of file +} diff --git a/drivers/gpu/drm/drm_modeset_lock.c b/drivers/gpu/drm/drm_modeset_lock.c index c0a5cd8..de59b0c 100644 --- a/drivers/gpu/drm/drm_modeset_lock.c +++ b/drivers/gpu/drm/drm_modeset_lock.c @@ -40,17 +40,15 @@ * The basic usage pattern is
[Intel-gfx] [PATCH v2 3/4] scripts/kernel-doc: Adding infrastructure for markdown support
Markdown support is given by calling an external tool, pandoc, for all
highlighted text on kernel-doc.
Pandoc converts Markdown text to proper Docbook tags, which will be
later translated to pdf, html or other targets.
This adds the capability of adding human-readle text highlight (bold,
underline, etc), bullet and numbered lists, simple tables, fixed-width
text (including asciiart), requiring minimal changes to current
documentation.
So, text using *must* will be rendered as must
inside DocBook and then must for HTML.
Bullet lists eg:
* Element 1
* Element 2
will also be converted to proper docbook/html lists.
Although it has the support for a good part of the markup language,
pandoc has some limitations and won't render tables with spanning cells
or headings. The use of those features are not recommended.
At this moment, pandoc is totally optional. Docbooks ready for markdown
should be added to the MARKDOWNREADY variable inside the Makefile. In
case the developer doesn't have pandoc installed, Make will throw a
warning and the documentation build will continue, generating
simple Documentation without the features brought by pandoc.
Signed-off-by: Danilo Cesar Lemes de Paula
Cc: Randy Dunlap
Cc: Daniel Vetter
Cc: Laurent Pinchart
Cc: Jonathan Corbet
Cc: Herbert Xu
Cc: Stephan Mueller
Cc: Michal Marek
Cc: linux-ker...@vger.kernel.org
Cc: linux-...@vger.kernel.org
Cc: intel-gfx
Cc: dri-devel
---
Changelog:
v2:
* Fix checkpatch issues.
* Improved commit message.
* Fixed dependency issue causing "make htmldocs" recalculate without
any code change.
Documentation/DocBook/Makefile | 25 +++-
scripts/docproc.c | 54 --
scripts/kernel-doc | 66 --
3 files changed, 119 insertions(+), 26 deletions(-)
diff --git a/Documentation/DocBook/Makefile b/Documentation/DocBook/Makefile
index 322255b..8e6d022 100644
--- a/Documentation/DocBook/Makefile
+++ b/Documentation/DocBook/Makefile
@@ -17,6 +17,8 @@ DOCBOOKS := z8530book.xml device-drivers.xml \
tracepoint.xml drm.xml media_api.xml w1.xml \
writing_musb_glue_layer.xml crypto-API.xml
+MARKDOWNREADY :=
+
include Documentation/DocBook/media/Makefile
###
@@ -79,18 +81,23 @@ XMLTOFLAGS += --skip-validation
# The following rules are used to generate the .xml documentation
# required to generate the final targets. (ps, pdf, html).
quiet_cmd_docproc = DOCPROC $@
- cmd_docproc = SRCTREE=$(srctree)/ $(DOCPROC) doc $< >$@
+ cmd_docproc = SRCTREE=$(srctree)/ $(DOCPROC) doc $<
define rule_docproc
- set -e; \
-$(if $($(quiet)cmd_$(1)),echo ' $($(quiet)cmd_$(1))';)\
-$(cmd_$(1)); \
-( \
- echo 'cmd_$@ := $(cmd_$(1))';\
- echo $@: `SRCTREE=$(srctree) $(DOCPROC) depend $<`; \
+ set -e;
\
+ USEMARKDOWN="";
\
+ FILE=`basename $@`;
\
+ [[ "$(MARKDOWNREADY)" =~ "$${FILE}" ]] && USEMARKDOWN="-use-markdown";
\
+$(if $($(quiet)cmd_$(1)),echo ' $($(quiet)cmd_$(1))';)
\
+$(cmd_$(1)) $$USEMARKDOWN >$@;
\
+(
\
+ echo 'cmd_$@ := $(cmd_$(1))';
\
+ echo $@: `SRCTREE=$(srctree) $(DOCPROC) depend $<`;
\
) > $(dir $@).$(notdir $@).cmd
endef
%.xml: %.tmpl $(KERNELDOC) $(DOCPROC) $(KERNELDOCXMLREF) FORCE
+ @(which pandoc > /dev/null 2>&1) || \
+ (echo "*** To get propper documentation you need to install pandoc
***";)
$(call if_changed_rule,docproc)
# Tell kbuild to always build the programs
@@ -101,6 +108,10 @@ notfoundtemplate = echo "*** You have to install
docbook-utils or xmlto ***"; \
db2xtemplate = db2TYPE -o $(dir $@) $<
xmltotemplate = xmlto TYPE $(XMLTOFLAGS) -o $(dir $@) $<
+ifneq ($(shell which pandoc >/dev/null 2>&1 && echo found),found)
+ MARKDOWNREADY := "";
+endif
+
# determine which methods are available
ifeq ($(shell which db2ps >/dev/null 2>&1 && echo found),found)
use-db2x = db2x
diff --git a/scripts/docproc.c b/scripts/docproc.c
index e267e621..7c6b225 100644
--- a/scripts/docproc.c
+++ b/scripts/docproc.c
@@ -73,12 +73,15 @@ FILELINE * docsection;
#define NOFUNCTION"-nofunction"
#define NODOCSECTIONS "-no-doc-sections"
#define SHOWNOTFOUND "-show-not-found"
+#define USEMARKDOWN "-use-markdown"
static char
[Intel-gfx] [PATCH v2 2/4] scripts/kernel-doc: Replacing highlights hash by an array
The "highlight" code is very sensible to the order of the hash keys, but the order of the keys cannot be predicted on Perl. It generates faulty DocBook entries like: - @device_for_each_child We should use an array for that job, so we can guarantee that the order of the regex execution on dohighlight won't change. Signed-off-by: Danilo Cesar Lemes de Paula Cc: Randy Dunlap Cc: Daniel Vetter Cc: Laurent Pinchart Cc: Jonathan Corbet Cc: Herbert Xu Cc: Stephan Mueller Cc: Michal Marek Cc: linux-ker...@vger.kernel.org Cc: linux-...@vger.kernel.org Cc: intel-gfx Cc: dri-devel --- Changelog: v2: No changes scripts/kernel-doc | 104 ++--- 1 file changed, 60 insertions(+), 44 deletions(-) diff --git a/scripts/kernel-doc b/scripts/kernel-doc index 9922e66..a38a69a 100755 --- a/scripts/kernel-doc +++ b/scripts/kernel-doc @@ -182,59 +182,73 @@ my $type_env = '(\$\w+)'; # One for each output format # these work fairly well -my %highlights_html = ( $type_constant, "\$1", - $type_func, "\$1", - $type_struct_xml, "\$1", - $type_env, "\$1", - $type_param, "\$1" ); +my @highlights_html = ( + [$type_constant, "\$1"], + [$type_func, "\$1"], + [$type_struct_xml, "\$1"], + [$type_env, "\$1"], + [$type_param, "\$1"] + ); my $local_lt = "lt:"; my $local_gt = "gt:"; my $blankline_html = $local_lt . "p" . $local_gt; # was "" # html version 5 -my %highlights_html5 = ( $type_constant, "\$1", - $type_func, "\$1", - $type_struct_xml, "\$1", - $type_env, "\$1", - $type_param, "\$1" ); +my @highlights_html5 = ( +[$type_constant, "\$1"], +[$type_func, "\$1"], +[$type_struct_xml, "\$1"], +[$type_env, "\$1"], +[$type_param, "\$1]"] + ); my $blankline_html5 = $local_lt . "br /" . $local_gt; # XML, docbook format -my %highlights_xml = ( "([^=])\\\"([^\\\"<]+)\\\"", "\$1\$2", - $type_constant, "\$1", - $type_func, "\$1", - $type_struct_xml, "\$1", - $type_env, "\$1", - $type_param, "\$1" ); +my @highlights_xml = ( + ["([^=])\\\"([^\\\"<]+)\\\"", "\$1\$2"], + [$type_constant, "\$1"], + [$type_struct_xml, "\$1"], + [$type_param, "\$1"], + [$type_func, "\$1"], + [$type_env, "\$1"] +); my $blankline_xml = $local_lt . "/para" . $local_gt . $local_lt . "para" . $local_gt . "\n"; # gnome, docbook format -my %highlights_gnome = ( $type_constant, "\$1", -$type_func, "\$1", -$type_struct, "\$1", -$type_env, "\$1", -$type_param, "\$1" ); +my @highlights_gnome = ( +[$type_constant, "\$1"], +[$type_func, "\$1"], +[$type_struct, "\$1"], +[$type_env, "\$1"], +[$type_param, "\$1" ] + ); my $blankline_gnome = "\n"; # these are pretty rough -my %highlights_man = ( $type_constant, "\$1", - $type_func, "fB\$1fP", - $type_struct, "fI\$1fP", - $type_param, "fI\$1fP" ); +my @highlights_man = ( + [$type_constant, "\$1"], + [$type_func, "fB\$1fP"], + [$type_struct, "fI\$1fP"], + [$type_param, "fI\$1fP"] +); my $blankline_man = ""; # text-mode -my %highlights_text = ( $type_constant, "\$1", - $type_func, "\$1", - $type_struct, "\$1", - $type_param, "\$1" ); +my @highlights_text = ( + [$type_constant, "\$1"], + [$type_func, "\$1"], + [$type_struct, "\$1"], + [$type_param, "\$1"] + ); my $blankline_text = ""; # list mode -my %highlights_list = ( $type_constant, "\$1", - $type_func, "\$1", - $type_struct, "\$1", - $type_param, "\$1" ); +my @highlights_list = ( + [$type_constant, "\$1"], + [$type_func, "\$1"], + [$type_struct, "\$1"], + [$type_param, "\$1"] + ); my $
[Intel-gfx] [PATCH v2 1/4] scripts/kernel-doc: Adding cross-reference links to html documentation.
Functions, Structs and Parameters definitions on kernel documentation are pure cosmetic, it only highlights the element. To ease the navigation in the documentation we should use inside those tags so readers can easily jump between methods directly. This was discussed in 2014[1] and is implemented by getting a list of from the DocBook XML to generate a database. Then it looks for , and tags that matches the ones in the database. As it only links existent references, no broken links are added. [1] - lists.freedesktop.org/archives/dri-devel/2014-August/065404.html Signed-off-by: Danilo Cesar Lemes de Paula Cc: Randy Dunlap Cc: Daniel Vetter Cc: Laurent Pinchart Cc: Jonathan Corbet Cc: Herbert Xu Cc: Stephan Mueller Cc: Michal Marek Cc: linux-ker...@vger.kernel.org Cc: linux-...@vger.kernel.org Cc: intel-gfx Cc: dri-devel --- Changelog: v1 (missing changlog from v1): * Add a "XMLREF FooBar.xml" as build output to reduce build noise. * Make kernel-doc-xml-ref ignore invalid arguments. * Improve kernel-doc-xml-ref documentation. Documentation/DocBook/Makefile | 43 ++--- scripts/kernel-doc-xml-ref | 198 + 2 files changed, 228 insertions(+), 13 deletions(-) create mode 100755 scripts/kernel-doc-xml-ref diff --git a/Documentation/DocBook/Makefile b/Documentation/DocBook/Makefile index b6a6a2e..322255b 100644 --- a/Documentation/DocBook/Makefile +++ b/Documentation/DocBook/Makefile @@ -64,8 +64,9 @@ installmandocs: mandocs ### #External programs used -KERNELDOC = $(srctree)/scripts/kernel-doc -DOCPROC = $(objtree)/scripts/docproc +KERNELDOCXMLREF = $(srctree)/scripts/kernel-doc-xml-ref +KERNELDOC = $(srctree)/scripts/kernel-doc +DOCPROC = $(objtree)/scripts/docproc XMLTOFLAGS = -m $(srctree)/$(src)/stylesheet.xsl XMLTOFLAGS += --skip-validation @@ -89,7 +90,7 @@ define rule_docproc ) > $(dir $@).$(notdir $@).cmd endef -%.xml: %.tmpl $(KERNELDOC) $(DOCPROC) FORCE +%.xml: %.tmpl $(KERNELDOC) $(DOCPROC) $(KERNELDOCXMLREF) FORCE $(call if_changed_rule,docproc) # Tell kbuild to always build the programs @@ -140,7 +141,20 @@ quiet_cmd_db2html = HTML$@ echo ' \ $(patsubst %.html,%,$(notdir $@))' > $@ -%.html:%.xml +### +# Rules to create an aux XML and .db, and use them to re-process the DocBook XML +# to fill internal hyperlinks + gen_aux_xml = : + quiet_gen_aux_xml = echo ' XMLREF $@' +silent_gen_aux_xml = : +%.aux.xml: %.xml + @$($(quiet)gen_aux_xml) + @rm -rf $@ + @(cat $< | egrep "^ $<.db) + @$(KERNELDOCXMLREF) -db $<.db $< > $@ +.PRECIOUS: %.aux.xml + +%.html:%.aux.xml @(which xmlto > /dev/null 2>&1) || \ (echo "*** You need to install xmlto ***"; \ exit 1) @@ -209,15 +223,18 @@ dochelp: ### # Temporary files left by various tools clean-files := $(DOCBOOKS) \ - $(patsubst %.xml, %.dvi, $(DOCBOOKS)) \ - $(patsubst %.xml, %.aux, $(DOCBOOKS)) \ - $(patsubst %.xml, %.tex, $(DOCBOOKS)) \ - $(patsubst %.xml, %.log, $(DOCBOOKS)) \ - $(patsubst %.xml, %.out, $(DOCBOOKS)) \ - $(patsubst %.xml, %.ps, $(DOCBOOKS)) \ - $(patsubst %.xml, %.pdf, $(DOCBOOKS)) \ - $(patsubst %.xml, %.html, $(DOCBOOKS)) \ - $(patsubst %.xml, %.9,$(DOCBOOKS)) \ + $(patsubst %.xml, %.dvi, $(DOCBOOKS)) \ + $(patsubst %.xml, %.aux, $(DOCBOOKS)) \ + $(patsubst %.xml, %.tex, $(DOCBOOKS)) \ + $(patsubst %.xml, %.log, $(DOCBOOKS)) \ + $(patsubst %.xml, %.out, $(DOCBOOKS)) \ + $(patsubst %.xml, %.ps, $(DOCBOOKS)) \ + $(patsubst %.xml, %.pdf, $(DOCBOOKS)) \ + $(patsubst %.xml, %.html,$(DOCBOOKS)) \ + $(patsubst %.xml, %.9, $(DOCBOOKS)) \ + $(patsubst %.xml, %.aux.xml, $(DOCBOOKS)) \ + $(patsubst %.xml, %.xml.db, $(DOCBOOKS)) \ + $(patsubst %.xml, %.xml, $(DOCBOOKS)) \ $(index) clean-dirs := $(patsubst %.xml,%,$(DOCBOOKS)) man diff --git a/scripts/kernel-doc-xml-ref b/scripts/kernel-doc-xml-ref new file mode 100755 index 000..104a5a5 --- /dev/null +++ b/scripts/kernel-doc-xml-ref @@ -0,0 +1,198 @@ +#!/usr/bin/perl -w + +use strict; + +## Copyright (C) 2015 Intel Corporation ## +### +## This software falls under the GNU General Public License. ## +## Please read the COPYING file for more information ## +# +# +# This software reads a XML file and a list of valid interal +# references to replace Docbook tags with links. +# +# The list of "valid internal references" must be one-per-line in the following format: +# API-struct-foo +# API-enum-bar +# API-my-function +# +# The software walks over the XML file looking for xml tags representing possible references +# to the Document. Each reference will be
Re: [Intel-gfx] [PATCH 4/7] drm/i915: Split sink_crc function in start, stop and read.
On Thu, Jul 23, 2015 at 04:35:47PM -0700, Rodrigo Vivi wrote:
> No functional change. Just a preparation patch to make clear
> what operation we are performing.
>
> Signed-off-by: Rodrigo Vivi
Good. The place where you call hsw_disable_ips() changes, but as you
explained earlier, this is required.
Reviewed-by: Rafael Antognolli
> ---
> drivers/gpu/drm/i915/intel_dp.c | 89
> +++--
> 1 file changed, 50 insertions(+), 39 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
> index 44f8a32..10cbc98 100644
> --- a/drivers/gpu/drm/i915/intel_dp.c
> +++ b/drivers/gpu/drm/i915/intel_dp.c
> @@ -3958,40 +3958,64 @@ intel_dp_probe_mst(struct intel_dp *intel_dp)
> return intel_dp->is_mst;
> }
>
> -int intel_dp_sink_crc(struct intel_dp *intel_dp, u8 *crc)
> +static void intel_dp_sink_crc_stop(struct intel_dp *intel_dp)
> {
> - struct intel_digital_port *intel_dig_port = dp_to_dig_port(intel_dp);
> - struct drm_device *dev = intel_dig_port->base.base.dev;
> - struct intel_crtc *intel_crtc =
> - to_intel_crtc(intel_dig_port->base.base.crtc);
> + struct intel_digital_port *dig_port = dp_to_dig_port(intel_dp);
> + struct intel_crtc *intel_crtc = to_intel_crtc(dig_port->base.base.crtc);
> u8 buf;
> - int test_crc_count;
> - int attempts = 6;
> - int ret = 0;
> -
> - hsw_disable_ips(intel_crtc);
>
> - if (drm_dp_dpcd_readb(&intel_dp->aux, DP_TEST_SINK_MISC, &buf) < 0) {
> - ret = -EIO;
> - goto out;
> + if (drm_dp_dpcd_readb(&intel_dp->aux, DP_TEST_SINK, &buf) < 0) {
> + DRM_DEBUG_KMS("Sink CRC couldn't be stopped properly\n");
> + return;
> }
>
> - if (!(buf & DP_TEST_CRC_SUPPORTED)) {
> - ret = -ENOTTY;
> - goto out;
> - }
> + if (drm_dp_dpcd_writeb(&intel_dp->aux, DP_TEST_SINK,
> +buf & ~DP_TEST_SINK_START) < 0)
> + DRM_DEBUG_KMS("Sink CRC couldn't be stopped properly\n");
>
> - if (drm_dp_dpcd_readb(&intel_dp->aux, DP_TEST_SINK, &buf) < 0) {
> - ret = -EIO;
> - goto out;
> - }
> + hsw_enable_ips(intel_crtc);
> +}
> +
> +static int intel_dp_sink_crc_start(struct intel_dp *intel_dp)
> +{
> + struct intel_digital_port *dig_port = dp_to_dig_port(intel_dp);
> + struct intel_crtc *intel_crtc = to_intel_crtc(dig_port->base.base.crtc);
> + u8 buf;
> +
> + if (drm_dp_dpcd_readb(&intel_dp->aux, DP_TEST_SINK_MISC, &buf) < 0)
> + return -EIO;
> +
> + if (!(buf & DP_TEST_CRC_SUPPORTED))
> + return -ENOTTY;
> +
> + if (drm_dp_dpcd_readb(&intel_dp->aux, DP_TEST_SINK, &buf) < 0)
> + return -EIO;
> +
> + hsw_disable_ips(intel_crtc);
>
> if (drm_dp_dpcd_writeb(&intel_dp->aux, DP_TEST_SINK,
> - buf | DP_TEST_SINK_START) < 0) {
> - ret = -EIO;
> - goto out;
> +buf | DP_TEST_SINK_START) < 0) {
> + hsw_enable_ips(intel_crtc);
> + return -EIO;
> }
>
> + return 0;
> +}
> +
> +int intel_dp_sink_crc(struct intel_dp *intel_dp, u8 *crc)
> +{
> + struct intel_digital_port *dig_port = dp_to_dig_port(intel_dp);
> + struct drm_device *dev = dig_port->base.base.dev;
> + struct intel_crtc *intel_crtc = to_intel_crtc(dig_port->base.base.crtc);
> + u8 buf;
> + int test_crc_count;
> + int attempts = 6;
> + int ret;
> +
> + ret = intel_dp_sink_crc_start(intel_dp);
> + if (ret)
> + return ret;
> +
> if (drm_dp_dpcd_readb(&intel_dp->aux, DP_TEST_SINK_MISC, &buf) < 0) {
> ret = -EIO;
> goto stop;
> @@ -4014,23 +4038,10 @@ int intel_dp_sink_crc(struct intel_dp *intel_dp, u8
> *crc)
> goto stop;
> }
>
> - if (drm_dp_dpcd_read(&intel_dp->aux, DP_TEST_CRC_R_CR, crc, 6) < 0) {
> + if (drm_dp_dpcd_read(&intel_dp->aux, DP_TEST_CRC_R_CR, crc, 6) < 0)
> ret = -EIO;
> - goto stop;
> - }
> -
> stop:
> - if (drm_dp_dpcd_readb(&intel_dp->aux, DP_TEST_SINK, &buf) < 0) {
> - DRM_DEBUG_KMS("Sink CRC couldn't be stopped properly\n");
> - goto out;
> - }
> - if (drm_dp_dpcd_writeb(&intel_dp->aux, DP_TEST_SINK,
> -buf & ~DP_TEST_SINK_START) < 0) {
> - DRM_DEBUG_KMS("Sink CRC couldn't be stopped properly\n");
> - goto out;
> - }
> -out:
> - hsw_enable_ips(intel_crtc);
> + intel_dp_sink_crc_stop(intel_dp);
> return ret;
> }
>
> --
> 2.1.0
>
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.fr
Re: [Intel-gfx] [PATCH 5/7] drm/i915: Force sink crc stop before start.
On Thu, Jul 23, 2015 at 04:35:48PM -0700, Rodrigo Vivi wrote:
> By Vesa DP spec, test counter at DP_TEST_SINK_MISC just reset to 0
> when unsetting DP_TEST_SINK_START, so let's force this stop here.
>
> But let's minimize the aux transactions and just do it when we know
> it hasn't been properly stoped.
>
> Signed-off-by: Rodrigo Vivi
Reviewed-by: Rafael Antognolli
> ---
> drivers/gpu/drm/i915/intel_dp.c | 22 +++---
> drivers/gpu/drm/i915/intel_drv.h | 1 +
> 2 files changed, 20 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
> index 10cbc98..3ba031d 100644
> --- a/drivers/gpu/drm/i915/intel_dp.c
> +++ b/drivers/gpu/drm/i915/intel_dp.c
> @@ -3958,22 +3958,30 @@ intel_dp_probe_mst(struct intel_dp *intel_dp)
> return intel_dp->is_mst;
> }
>
> -static void intel_dp_sink_crc_stop(struct intel_dp *intel_dp)
> +static int intel_dp_sink_crc_stop(struct intel_dp *intel_dp)
> {
> struct intel_digital_port *dig_port = dp_to_dig_port(intel_dp);
> struct intel_crtc *intel_crtc = to_intel_crtc(dig_port->base.base.crtc);
> u8 buf;
> + int ret = 0;
>
> if (drm_dp_dpcd_readb(&intel_dp->aux, DP_TEST_SINK, &buf) < 0) {
> DRM_DEBUG_KMS("Sink CRC couldn't be stopped properly\n");
> - return;
> + ret = -EIO;
> + goto out;
> }
>
> if (drm_dp_dpcd_writeb(&intel_dp->aux, DP_TEST_SINK,
> -buf & ~DP_TEST_SINK_START) < 0)
> +buf & ~DP_TEST_SINK_START) < 0) {
> DRM_DEBUG_KMS("Sink CRC couldn't be stopped properly\n");
> + ret = -EIO;
> + goto out;
> + }
>
> + intel_dp->sink_crc_started = false;
> + out:
> hsw_enable_ips(intel_crtc);
> + return ret;
> }
>
> static int intel_dp_sink_crc_start(struct intel_dp *intel_dp)
> @@ -3981,6 +3989,13 @@ static int intel_dp_sink_crc_start(struct intel_dp
> *intel_dp)
> struct intel_digital_port *dig_port = dp_to_dig_port(intel_dp);
> struct intel_crtc *intel_crtc = to_intel_crtc(dig_port->base.base.crtc);
> u8 buf;
> + int ret;
> +
> + if (intel_dp->sink_crc_started) {
> + ret = intel_dp_sink_crc_stop(intel_dp);
> + if (ret)
> + return ret;
> + }
>
> if (drm_dp_dpcd_readb(&intel_dp->aux, DP_TEST_SINK_MISC, &buf) < 0)
> return -EIO;
> @@ -3999,6 +4014,7 @@ static int intel_dp_sink_crc_start(struct intel_dp
> *intel_dp)
> return -EIO;
> }
>
> + intel_dp->sink_crc_started = true;
> return 0;
> }
>
> diff --git a/drivers/gpu/drm/i915/intel_drv.h
> b/drivers/gpu/drm/i915/intel_drv.h
> index 47cef0e..cc74400 100644
> --- a/drivers/gpu/drm/i915/intel_drv.h
> +++ b/drivers/gpu/drm/i915/intel_drv.h
> @@ -714,6 +714,7 @@ struct intel_dp {
> /* sink rates as reported by DP_SUPPORTED_LINK_RATES */
> uint8_t num_sink_rates;
> int sink_rates[DP_MAX_SUPPORTED_RATES];
> + bool sink_crc_started;
> struct drm_dp_aux aux;
> uint8_t train_set[4];
> int panel_power_up_delay;
> --
> 2.1.0
>
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 6/7] drm/i915: Save latest known sink CRC to compensate delayed counter reset.
On Thu, Jul 23, 2015 at 04:35:49PM -0700, Rodrigo Vivi wrote:
> By Vesa DP 1.2 Spec TEST_CRC_COUNT should be
> "reset to 0 when TEST_SINK bit 0 = 0."
>
> However for some strange reason when PSR is enabled in
> certain platforms this is not true. At least not immediatelly.
>
> So we face cases like this:
>
> first get_sink_crc operation:
>count: 0, crc:
>count: 1, crc: c101c101c101
> returned expected crc: c101c101c101
>
> secont get_sink_crc operation:
>count: 1, crc: c101c101c101
>count: 0, crc:
>count: 1, crc: c101
> should return expected crc: c101
>
> But also the reset to 0 should be faster resulting into:
>
> get_sink_crc operation:
>count: 1, crc: c101c101c101
>count: 1, crc: c101
> should return expected crc: c101
>
> So in order to know that the second one is valid one
> we need to compare the pair (count, crc) with latest (count, crc).
>
> If the pair changed you have your valid CRC.
>
> Signed-off-by: Rodrigo Vivi
We discussed this before, unfortunately I don't see any other way to do
this, since there is no way to know that the crc count really restarted,
became 0 and then 1 again. So I think this workaround is needed.
Reviewed-by: Rafael Antognolli
> ---
> drivers/gpu/drm/i915/intel_dp.c | 42
> +---
> drivers/gpu/drm/i915/intel_drv.h | 8 +++-
> 2 files changed, 33 insertions(+), 17 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
> index 3ba031d..c7372a1 100644
> --- a/drivers/gpu/drm/i915/intel_dp.c
> +++ b/drivers/gpu/drm/i915/intel_dp.c
> @@ -3978,7 +3978,7 @@ static int intel_dp_sink_crc_stop(struct intel_dp
> *intel_dp)
> goto out;
> }
>
> - intel_dp->sink_crc_started = false;
> + intel_dp->sink_crc.started = false;
> out:
> hsw_enable_ips(intel_crtc);
> return ret;
> @@ -3991,7 +3991,7 @@ static int intel_dp_sink_crc_start(struct intel_dp
> *intel_dp)
> u8 buf;
> int ret;
>
> - if (intel_dp->sink_crc_started) {
> + if (intel_dp->sink_crc.started) {
> ret = intel_dp_sink_crc_stop(intel_dp);
> if (ret)
> return ret;
> @@ -4003,6 +4003,8 @@ static int intel_dp_sink_crc_start(struct intel_dp
> *intel_dp)
> if (!(buf & DP_TEST_CRC_SUPPORTED))
> return -ENOTTY;
>
> + intel_dp->sink_crc.last_count = buf & DP_TEST_COUNT_MASK;
> +
> if (drm_dp_dpcd_readb(&intel_dp->aux, DP_TEST_SINK, &buf) < 0)
> return -EIO;
>
> @@ -4014,7 +4016,7 @@ static int intel_dp_sink_crc_start(struct intel_dp
> *intel_dp)
> return -EIO;
> }
>
> - intel_dp->sink_crc_started = true;
> + intel_dp->sink_crc.started = true;
> return 0;
> }
>
> @@ -4024,29 +4026,39 @@ int intel_dp_sink_crc(struct intel_dp *intel_dp, u8
> *crc)
> struct drm_device *dev = dig_port->base.base.dev;
> struct intel_crtc *intel_crtc = to_intel_crtc(dig_port->base.base.crtc);
> u8 buf;
> - int test_crc_count;
> + int count, ret;
> int attempts = 6;
> - int ret;
>
> ret = intel_dp_sink_crc_start(intel_dp);
> if (ret)
> return ret;
>
> - if (drm_dp_dpcd_readb(&intel_dp->aux, DP_TEST_SINK_MISC, &buf) < 0) {
> - ret = -EIO;
> - goto stop;
> - }
> -
> - test_crc_count = buf & DP_TEST_COUNT_MASK;
> -
> do {
> + intel_wait_for_vblank(dev, intel_crtc->pipe);
> +
> if (drm_dp_dpcd_readb(&intel_dp->aux,
> DP_TEST_SINK_MISC, &buf) < 0) {
> ret = -EIO;
> goto stop;
> }
> - intel_wait_for_vblank(dev, intel_crtc->pipe);
> - } while (--attempts && (buf & DP_TEST_COUNT_MASK) == test_crc_count);
> + count = buf & DP_TEST_COUNT_MASK;
> + /*
> + * Count might be reset during the loop. In this case
> + * last known count needs to be reset as well.
> + */
> + if (count == 0)
> + intel_dp->sink_crc.last_count = 0;
> +
> + if (drm_dp_dpcd_read(&intel_dp->aux, DP_TEST_CRC_R_CR, crc, 6)
> < 0) {
> + ret = -EIO;
> + goto stop;
> + }
> + } while (--attempts && (count == 0 || (count ==
> intel_dp->sink_crc.last_count &&
> +
> !memcmp(intel_dp->sink_crc.last_crc, crc,
> +6 * sizeof(u8);
> +
> + intel_dp->sink_crc.last_count = buf & DP_TEST_COUNT_MASK;
> + memcpy(intel_dp->sink_crc.last_crc, crc, 6 * sizeof(u8));
>
> if (attempts == 0) {
> DRM_DEBUG_KMS("Panel is unable to calculate CRC after 6
> vbla
Re: [Intel-gfx] [PATCH 7/7] drm/i915: Dont -ETIMEDOUT on identical new and previous (count, crc).
On Thu, Jul 23, 2015 at 04:35:50PM -0700, Rodrigo Vivi wrote:
> By Vesa DP 1.2 spec TEST_CRC_COUNT is a "4 bit wrap counter which
> increments each time the TEST_CRC_x_x are updated."
>
> However if we are trying to verify the screen hasn't changed we get
> same (count, crc) pair twice. Without this patch we would return
> -ETIMEOUT in this case.
>
> So, if in 6 vblanks the pair (count, crc) hasn't changed we
> return it anyway instead of returning error and let test case decide
> if it was right or not.
>
> Signed-off-by: Rodrigo Vivi
Looks good.
> ---
> drivers/gpu/drm/i915/intel_dp.c | 21 +++--
> 1 file changed, 15 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
> index c7372a1..e99ec7a 100644
> --- a/drivers/gpu/drm/i915/intel_dp.c
> +++ b/drivers/gpu/drm/i915/intel_dp.c
> @@ -4028,6 +4028,7 @@ int intel_dp_sink_crc(struct intel_dp *intel_dp, u8
> *crc)
> u8 buf;
> int count, ret;
> int attempts = 6;
> + bool old_equal_new;
>
> ret = intel_dp_sink_crc_start(intel_dp);
> if (ret)
> @@ -4042,6 +4043,7 @@ int intel_dp_sink_crc(struct intel_dp *intel_dp, u8
> *crc)
> goto stop;
> }
> count = buf & DP_TEST_COUNT_MASK;
> +
> /*
>* Count might be reset during the loop. In this case
>* last known count needs to be reset as well.
> @@ -4053,17 +4055,24 @@ int intel_dp_sink_crc(struct intel_dp *intel_dp, u8
> *crc)
> ret = -EIO;
> goto stop;
> }
> - } while (--attempts && (count == 0 || (count ==
> intel_dp->sink_crc.last_count &&
> -
> !memcmp(intel_dp->sink_crc.last_crc, crc,
> -6 * sizeof(u8);
> +
> + old_equal_new = (count == intel_dp->sink_crc.last_count &&
> + !memcmp(intel_dp->sink_crc.last_crc, crc,
> + 6 * sizeof(u8)));
> +
> + } while (--attempts && (count == 0 || old_equal_new));
>
> intel_dp->sink_crc.last_count = buf & DP_TEST_COUNT_MASK;
> memcpy(intel_dp->sink_crc.last_crc, crc, 6 * sizeof(u8));
>
> if (attempts == 0) {
> - DRM_DEBUG_KMS("Panel is unable to calculate CRC after 6
> vblanks\n");
> - ret = -ETIMEDOUT;
> - goto stop;
> + if (old_equal_new) {
> + DRM_DEBUG_KMS("Unreliable Sink CRC counter: Current
> returned CRC is identical to the previous one\n");
Isn't this line a little too long?
> + } else {
> + DRM_ERROR("Panel is unable to calculate any CRC after 6
> vblanks\n");
> + ret = -ETIMEDOUT;
> + goto stop;
> + }
> }
>
> stop:
> --
> 2.1.0
>
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm: Add DRM_NOTICE_IF
On 28/07/15 14:14, Chris Wilson wrote: > Styled after WARN_ON/DRM_ERROR_ON, this prints a mild warning message (a > KERN_NOTICE for significant but mild events) that allows us to insert > interesting events without alarming the user or bug reporting tools. > Wouldn't it be better to opt for DRM_NOTICE_ON to be consistent with the other two ? It sounds fine here, although I am a non-native English speaker, so take it with a grain of salt. Thanks Emil ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm: Add DRM_NOTICE_IF
On 28/07/15 14:14, Chris Wilson wrote: > Styled after WARN_ON/DRM_ERROR_ON, this prints a mild warning message (a > KERN_NOTICE for significant but mild events) that allows us to insert > interesting events without alarming the user or bug reporting tools. > Wouldn't it be better to opt for DRM_NOTICE_ON to be consistent with the other two ? It sounds fine here, although I am a non-native English speaker, so take it with a grain of salt. Thanks Emil ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 07/13 v4] drm/i915: GuC submission setup, phase 1
On Tue, Jul 28, 2015 at 04:16:03PM +0100, Dave Gordon wrote: > On 28/07/15 00:12, O'Rourke, Tom wrote: > >On Mon, Jul 27, 2015 at 03:41:31PM -0700, Yu Dai wrote: > >> > >>On 07/24/2015 03:31 PM, O'Rourke, Tom wrote: > >>>[TOR:] When I see "phase 1" I also look for "phase 2". > >>>A subject that better describes the change in this patch > >>>would help. > >>> > >>>On Thu, Jul 09, 2015 at 07:29:08PM +0100, Dave Gordon wrote: > From: Alex Dai > > This adds the first of the data structures used to communicate with the > GuC (the pool of guc_context structures). > > We create a GuC-specific wrapper round the GEM object allocator as all > GEM objects shared with the GuC must be pinned into GGTT space at an > address that is NOT in the range [0..WOPCM_SIZE), as that range of GGTT > addresses is not accessible to the GuC (from the GuC's point of view, > it's permanently reserved for other objects such as the BootROM & SRAM). > >>>[TOR:] I would like a clarfication on the excluded range. > >>>The excluded range should be 0 to "size for guc within > >>>WOPCM area" and not 0 to "size of WOPCM area". > >> > >>Nope, GGTT range [0..WOPCM_SIZE) should be excluded from GuC usage. > >>BSpec clearly says, from 0 to WOPCM_TOP-1 is for BootROM, SRAM and > >>WOPCM. From WOPCM_TOP and above is GFX DRAM. Be note that, that GGTT > >>space is still available to any gfx obj as long as it is not > >>accessed by GuC (OK to pass through GuC). > >> > >[TOR:] Should we take a closer look at the pin offset bias > >for guc objects? GUC_WOPCM_SIZE_VALUE is not the full size > >of WOPCM area. > > I'm inclined to set the bias to GUC_WOPCM_TOP, and then define that > as the sum of GUC_WOPCM_OFFSET_VALUE and GUC_WOPCM_SIZE_VALUE. That > seems to be what the BSpec pages "WriteOnceProtectedContentMemory > (WOPCM) Management" and "WOPCM Memory Map" suggest, although I think > they're pretty unclear on the details :( > > Do you (both) agree this would be the right value? [TOR:] No, I do not think that is the right value. I think the excluded range should be [0 ... GUC_WOPCM_SIZE_VALUE) and that GUC_WOPCM_SIZE_VALUE should be used as the bias (as it is now) for objects used by GuC. The term "WOPCM_SIZE" is ambiguous since it could mean GUC_WOPCM_SIZE (as in 0xc050) or it could mean "size of WOPCM area" (as in 0x1082C0). It gets used both ways in the BSpec. > > [snip] [snip] ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 7/7] drm/i915: Dont -ETIMEDOUT on identical new and previous (count, crc).
On Tue, 2015-07-28 at 13:25 -0700, Rafael Antognolli wrote:
> On Thu, Jul 23, 2015 at 04:35:50PM -0700, Rodrigo Vivi wrote:
> > By Vesa DP 1.2 spec TEST_CRC_COUNT is a "4 bit wrap counter which
> > increments each time the TEST_CRC_x_x are updated."
> >
> > However if we are trying to verify the screen hasn't changed we get
> > same (count, crc) pair twice. Without this patch we would return
> > -ETIMEOUT in this case.
> >
> > So, if in 6 vblanks the pair (count, crc) hasn't changed we
> > return it anyway instead of returning error and let test case decide
> > if it was right or not.
> >
> > Signed-off-by: Rodrigo Vivi
>
> Looks good.
>
> > ---
> > drivers/gpu/drm/i915/intel_dp.c | 21 +++--
> > 1 file changed, 15 insertions(+), 6 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/intel_dp.c
> > b/drivers/gpu/drm/i915/intel_dp.c
> > index c7372a1..e99ec7a 100644
> > --- a/drivers/gpu/drm/i915/intel_dp.c
> > +++ b/drivers/gpu/drm/i915/intel_dp.c
> > @@ -4028,6 +4028,7 @@ int intel_dp_sink_crc(struct intel_dp *intel_dp, u8
> > *crc)
> > u8 buf;
> > int count, ret;
> > int attempts = 6;
> > + bool old_equal_new;
> >
> > ret = intel_dp_sink_crc_start(intel_dp);
> > if (ret)
> > @@ -4042,6 +4043,7 @@ int intel_dp_sink_crc(struct intel_dp *intel_dp, u8
> > *crc)
> > goto stop;
> > }
> > count = buf & DP_TEST_COUNT_MASK;
> > +
> > /*
> > * Count might be reset during the loop. In this case
> > * last known count needs to be reset as well.
> > @@ -4053,17 +4055,24 @@ int intel_dp_sink_crc(struct intel_dp *intel_dp, u8
> > *crc)
> > ret = -EIO;
> > goto stop;
> > }
> > - } while (--attempts && (count == 0 || (count ==
> > intel_dp->sink_crc.last_count &&
> > -
> > !memcmp(intel_dp->sink_crc.last_crc, crc,
> > - 6 * sizeof(u8);
> > +
> > + old_equal_new = (count == intel_dp->sink_crc.last_count &&
> > +!memcmp(intel_dp->sink_crc.last_crc, crc,
> > +6 * sizeof(u8)));
> > +
> > + } while (--attempts && (count == 0 || old_equal_new));
> >
> > intel_dp->sink_crc.last_count = buf & DP_TEST_COUNT_MASK;
> > memcpy(intel_dp->sink_crc.last_crc, crc, 6 * sizeof(u8));
> >
> > if (attempts == 0) {
> > - DRM_DEBUG_KMS("Panel is unable to calculate CRC after 6
> > vblanks\n");
> > - ret = -ETIMEDOUT;
> > - goto stop;
> > + if (old_equal_new) {
> > + DRM_DEBUG_KMS("Unreliable Sink CRC counter: Current
> > returned CRC is identical to the previous one\n");
>
> Isn't this line a little too long?
I agree, but I had no idea how to make it shorter. I believe this long
debug message is the only case where we can go over 80 characters in
i915. but if it isn't true and/or have a suggestion how to make it
shorter please let me know that I can change.
>
> > + } else {
> > + DRM_ERROR("Panel is unable to calculate any CRC after 6
> > vblanks\n");
> > + ret = -ETIMEDOUT;
> > + goto stop;
> > + }
> > }
> >
> > stop:
> > --
> > 2.1.0
> >
> > ___
> > Intel-gfx mailing list
> > Intel-gfx@lists.freedesktop.org
> > http://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 05/14] drm: Check locking in drm_for_each_connector
Hi Daniel,
On Thursday 09 July 2015 23:44:28 Daniel Vetter wrote:
> Because of DP MST connectors can now be hotplugged and we must hold
> the right lock when walking the connector lists. Enforce this by
> checking the locking in our shiny new list walking macros.
>
> v2: Extract the locking check into a small static inline helper to
> help readability. This will be more important when we make the
> read list access rules more complicated in later patches. Inspired by
> comments from Chris. Unfortunately, due to header loops around the
> definition of struct drm_device the function interface is a bit funny.
>
> v3: Encoders aren't hotadded/removed. For each dp mst encoder we
> statically create one fake encoder per pipe so that we can support as
> many mst sinks as the hw can (Dave).
>
> Cc: Chris Wilson
> Cc: Dave Airlie
> Signed-off-by: Daniel Vetter
> ---
> include/drm/drm_crtc.h | 12 +++-
> 1 file changed, 11 insertions(+), 1 deletion(-)
>
> diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
> index 7c95a7df6065..499562274353 100644
> --- a/include/drm/drm_crtc.h
> +++ b/include/drm/drm_crtc.h
> @@ -1589,8 +1589,18 @@ static inline struct drm_property
> *drm_property_find(struct drm_device *dev, #define drm_for_each_crtc(crtc,
> dev) \
> list_for_each_entry(crtc, &(dev)->mode_config.crtc_list, head)
>
> +static inline void
> +assert_drm_connector_list_read_locked(struct drm_mode_config *mode_config)
> +{
> + WARN_ON(!mutex_is_locked(&mode_config->mutex));
I believe this introduced a regression for all drivers that call
drm_mode_config_reset() at .load() time (and there's lots of them), as the
mode config mutex isn't locked then.
> +}
> +
> #define drm_for_each_connector(connector, dev) \
> - list_for_each_entry(connector, &(dev)->mode_config.connector_list, head)
> + for (assert_drm_connector_list_read_locked(&(dev)->mode_config),
> \
> + connector = list_first_entry(&(dev)->mode_config.connector_list,
\
> + struct drm_connector, head);
> \
> + &connector->head != (&(dev)->mode_config.connector_list);
> \
> + connector = list_next_entry(connector, head))
>
> #define drm_for_each_encoder(encoder, dev) \
> list_for_each_entry(encoder, &(dev)->mode_config.encoder_list, head)
--
Regards,
Laurent Pinchart
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 07/13 v4] drm/i915: GuC submission setup, phase 1
On Tue, Jul 28, 2015 at 08:40:58PM +0100, Dave Gordon wrote: > On 28/07/15 16:16, Dave Gordon wrote: > >On 28/07/15 00:12, O'Rourke, Tom wrote: > >>On Mon, Jul 27, 2015 at 03:41:31PM -0700, Yu Dai wrote: > >>> > >>>On 07/24/2015 03:31 PM, O'Rourke, Tom wrote: > [TOR:] When I see "phase 1" I also look for "phase 2". > A subject that better describes the change in this patch > would help. > > On Thu, Jul 09, 2015 at 07:29:08PM +0100, Dave Gordon wrote: > >From: Alex Dai > > > >This adds the first of the data structures used to communicate with > >the GuC (the pool of guc_context structures). > > > >We create a GuC-specific wrapper round the GEM object allocator as all > >GEM objects shared with the GuC must be pinned into GGTT space at an > >address that is NOT in the range [0..WOPCM_SIZE), as that range of > >GGTT > >addresses is not accessible to the GuC (from the GuC's point of view, > >it's permanently reserved for other objects such as the BootROM & > >SRAM). > > [TOR:] I would like a clarfication on the excluded range. > The excluded range should be 0 to "size for guc within > WOPCM area" and not 0 to "size of WOPCM area". > >>> > >>>Nope, GGTT range [0..WOPCM_SIZE) should be excluded from GuC usage. > >>>BSpec clearly says, from 0 to WOPCM_TOP-1 is for BootROM, SRAM and > >>>WOPCM. From WOPCM_TOP and above is GFX DRAM. Be note that, that GGTT > >>>space is still available to any gfx obj as long as it is not > >>>accessed by GuC (OK to pass through GuC). > >>> > >>[TOR:] Should we take a closer look at the pin offset bias > >>for guc objects? GUC_WOPCM_SIZE_VALUE is not the full size > >>of WOPCM area. > > > >I'm inclined to set the bias to GUC_WOPCM_TOP, and then define that as > >the sum of GUC_WOPCM_OFFSET_VALUE and GUC_WOPCM_SIZE_VALUE. That seems > >to be what the BSpec pages "WriteOnceProtectedContentMemory (WOPCM) > >Management" and "WOPCM Memory Map" suggest, although I think they're > >pretty unclear on the details :( > > > >Do you (both) agree this would be the right value? > > Actually I've changed my mind (again). On rereading this stuff, I > now think that GUC_WOPCM_TOP is the same as the value put into the > SIZE register. The (physical) range between the (real) WOPCM BASE > and that plus the GUC WOPCM OFFSET isn't part of the GuC address > space at all, so GuC address 0 maps (would map) to (real WOPCM > BASE+GUC WOPCM OFFSET) in physical addresses, except that the bottom > 80k is shadowed by the bootrom and SRAM; and then the SIZE register > defines the size of the range from (GuC address) 0 to GUC_WOPCM_TOP; > and then higher addresses map through the GTT as expected. > > Or so I think. Does anyone know for sure? Please let me know ASAP as > I want to submit an updated patchset tomorrow! > > Thanks, > .Dave. [TOR:] Hi Dave, Sorry, I did not see your message earlier. Please see my other reply on this thread. I think you are right here, but to be clear, I think by "SIZE" you mean "GUC_WOPCM_SIZE_VALUE". Also, this should not matter here, but the SKL guc SRAM shadow is 128k, not 80k. Thanks, Tom ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm: Fixup locking WARNINGs in drm_mode_config_reset
With commit 7a3f3d6667f5f9ffd1517f6b21d64bbf5312042c Author: Daniel Vetter Date: Thu Jul 9 23:44:28 2015 +0200 drm: Check locking in drm_for_each_connector we started checking the locking in drm_for_each_connector but somehow I totally missed drm_mode_config_reset. There's no problem there since this function should only be called in single-threaded contexts (driver load or resume), so just wrap the loop with the right lock. Cc: Laurent Pinchart Reported-by: Laurent Pinchart Signed-off-by: Daniel Vetter --- drivers/gpu/drm/drm_crtc.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c index c91c18b2b1d4..a8e5ca79aad1 100644 --- a/drivers/gpu/drm/drm_crtc.c +++ b/drivers/gpu/drm/drm_crtc.c @@ -5273,9 +5273,11 @@ void drm_mode_config_reset(struct drm_device *dev) if (encoder->funcs->reset) encoder->funcs->reset(encoder); + mutex_lock(dev->mode_config.mutex); drm_for_each_connector(connector, dev) if (connector->funcs->reset) connector->funcs->reset(connector); + mutex_unlock(dev->mode_config.mutex); } EXPORT_SYMBOL(drm_mode_config_reset); -- 2.1.4 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
