Re: [Intel-gfx] [PATCH] drm/i915/bdw: Use timeout mode for RC6 on bdw
On Mon, Jun 02, 2014 at 09:51:27PM +, O'Rourke, Tom wrote: > >From: Daniel Vetter [mailto:daniel.vet...@ffwll.ch] On Behalf Of Daniel > >Vetter > >Sent: Monday, June 02, 2014 1:26 AM > >To: O'Rourke, Tom > >Cc: intel-gfx@lists.freedesktop.org; Ben Widawsky; Kristen Carlson Accardi > >Subject: Re: [Intel-gfx] [PATCH] drm/i915/bdw: Use timeout mode for RC6 on > >bdw > > > >On Fri, May 30, 2014 at 11:30:18PM +, O'Rourke, Tom wrote: > >> >On Wed, Apr 30, 2014 at 02:14:02PM -0700, Kristen Carlson Accardi wrote: > >> >> On Thu, 01 May 2014 00:03:15 +0300 > >> >> Imre Deak wrote: > >> >> > >> >> > On Wed, 2014-04-30 at 13:41 -0700, Ben Widawsky wrote: > >> >> > > On Wed, Apr 30, 2014 at 01:34:36PM -0700, Kristen Carlson Accardi > >wrote: > >> >> > > > On Tue, 29 Apr 2014 22:31:49 -0700 Ben Widawsky > >> >> > > > wrote: > >> >> > > > > >> >> > > > > On Wed, Apr 09, 2014 at 11:44:06AM -0700, Tom O'Rourke wrote: > >> >> > > > > > Higher RC6 residency is observed using timeout mode > >> >> > > > > > instead of EI mode. This applies to Broadwell only. > >> >> > > > > > The difference is particularly noticeable with video > >> >> > > > > > playback. > >> >> > > > > > > >> >> > > > > > Issue: VIZ-3778 > >> >> > > > > > Change-Id: I62bb12e21caf19651034826b45cde7f73a80938d > >> >> > > > > > Signed-off-by: Tom O'Rourke > >> >> > > > > > >> >> > > > > I've merged this one to my bdw-rc6 branch, and therefore my > >> >> > > > > broadwell branch. Hopefully Kristen will see some improvement. > >> >> > > > > >> >> > > > Unfortunately, I built your bdw-rc6 branch along with the > >> >> > > > revert I need to get my panel to work, and I get zero rc6 > >> >> > > > residency. > >> >> > > > Do I have to explicitly enable it? > >> >> > > > >> >> > > I'm not actually sure. You can try it and let me know. I > >> >> > > haven't had any time to verify the rebase. We can check my hack. > >> >> > > >> >> > Note that in -nightly you also have to update > >> >> > sanitize_rc6_option() along with intel_enable_gt_powersave() and > >> >> > intel_disable_gt_powersave() since atm these keep RC6 disabled on BDW. > >> >> > > >> >> > --Imre > >> >> > > >> >> > >> >> > >> >> Yes, I reverted fb5ed3b201fe5670c9ffeec3b5f6ff044d543c9e and was > >> >> able to see some rc6 residency. With the idle workload, residency > >> >> appears to be similar to before, so no regression. > >> > > >> >Thanks. I'll squash this in where appropriate. > >> > > >> >-- > >> >Ben Widawsky, Intel Open Source Technology Center > >> > >> [TOR:] Can we get this patch merged now that RC6 is working on drm-intel- > >nightly? > > > >Needs some review from bdw people. Also some relative residency > >improvement date should be added to the commit message (yes, we're allowed > >to do that now officially). > >-Daniel > >-- > > [TOR:] Hello bdw people, please review this patch. > > Is relative performance data now required in the commit message? A week > ago this would have been prohibited. You might need to double-check with your own manager, but we're now again allowed to officially add it to the commit message. It was kinda always required, just had to be washed down more. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - 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 10/11] drm/i915: Improve PSR debugfs status.
On Mon, Jun 02, 2014 at 11:54:10PM +0530, Vijay Purushothaman wrote: > On 5/16/2014 5:43 AM, Rodrigo Vivi wrote: > >Now we have the active/inactive state for exit and this actually changes the > >HW enable bit the status was a bit confusing for users. So let's provide > >more info. > > > >Signed-off-by: Rodrigo Vivi > >--- > > drivers/gpu/drm/i915/i915_debugfs.c | 4 +++- > > 1 file changed, 3 insertions(+), 1 deletion(-) > > > >diff --git a/drivers/gpu/drm/i915/i915_debugfs.c > >b/drivers/gpu/drm/i915/i915_debugfs.c > >index 6636ca2..0ca9376 100644 > >--- a/drivers/gpu/drm/i915/i915_debugfs.c > >+++ b/drivers/gpu/drm/i915/i915_debugfs.c > >@@ -1975,10 +1975,12 @@ static int i915_edp_psr_status(struct seq_file *m, > >void *data) > > > > seq_printf(m, "Sink_Support: %s\n", yesno(dev_priv->psr.sink_support)); > > seq_printf(m, "Source_OK: %s\n", yesno(dev_priv->psr.source_ok)); > >+seq_printf(m, "Enabled: %s\n", yesno(dev_priv->psr.enabled)); > >+seq_printf(m, "Active: %s\n", yesno(dev_priv->psr.active)); > > > > enabled = HAS_PSR(dev) && > > I915_READ(EDP_PSR_CTL(dev)) & EDP_PSR_ENABLE; > >-seq_printf(m, "Enabled: %s\n", yesno(enabled)); > >+seq_printf(m, "HW Enabled & Active bit: %s\n", yesno(enabled)); > > > > if (HAS_PSR(dev)) > > psrperf = I915_READ(EDP_PSR_PERF_CNT(dev)) & > > Please remove all references to PSR performance counter. This register is > primarily meant as a debug register and its implementation is broken in the > h/w. Whenever the cdclk is gated to save power, the performance counter is > stopped. But when the clk is re-enabled it doesn't reset the counter. This > unnecessarily confuses the end users.. When the system goes through suspend > / resume cycle the performance counter most likely will transition from a > non-zero value to zero.. I already received few queries from our customers > related to this performance customer and they refuse to believe me when i > tell them PSR is still functional when the performance counter reports 0 :-) We expose other such perf registers and imo this is handy for debugging. Also we have a big push to expose all this perf stuff recently ... Imo we should keep this, if we can. If confused customers noodle around in debugfs without clue, maybe they shouldn't. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [alsa-devel] [RFC] set up an sync channel between audio and display driver (i.e. ALSA and DRM)
On Tue, Jun 03, 2014 at 01:42:03AM +, Lin, Mengdong wrote: > > -Original Message- > > From: Daniel Vetter [mailto:daniel.vet...@ffwll.ch] > > > > Hi Daniel, > > > > > > Would you please share more info about your idea? > > > > > > - What would be an avsink device represent here? > > > E.g. on Intel platforms, will the whole display device have a child > > > avsink device or multiple avsink devices for each DDI port? > > > > My idea would be to have one for each output pipe (i.e. the link between > > audio and gfx), not one per ddi. Gfx driver would then let audio know > > when a screen is connected and which one (e.g. exact model serial from > > edid). > > This is somewhat important for dp mst where there's no longer a fixed > > relationship between audio pin and screen > > Thanks. But if we use avsink device, I prefer to have an avsink device per > DDI or several avsink devices per DDI, > It's because > 1. Without DP MST, there is a fixed mapping between each audio codec pin and > DDI; > 2. With DP MST, the above pin: DDI mapping is still valid (at least on Intel > platforms), > and there is also a fixed mapping between each device (screen) connected to > a pin/DDI. > 3. HD-Audio driver creates a PCM (audio stream) devices for each pin. > Keeping this behavior can make audio driver works on platforms without > implementing the sound/gfx sync channel. > And I guess in the future the audio driver will creates more than one PCM > devices for a DP MST-capable pin, according how many devices a DDI can > support. > > 4. Display mode change can change the pipe connected to a DDI even if the > monitor stays on the same DDI, > If we have an avsink device per pipe, the audio driver will have to check > another avsink device for this case. It seems not convenient. All this can also be solved by making the connector/avsink/sound pcm known to userspace and let userspace figure it out. A few links in sysfs should be good enough, plus exposing the full edid on the sound pcm side (so that userspace can compare the serial number in the edid). > > > - And for the relationship between audio driver and the avsink device, > > > which would be the master and which would be the component? > > > > 1:1 for avsink:alsa pin (iirc it's called a pin, not sure about the name). > > That way the audio driver has a clear point for getting at the eld and > > similar information. > > Since the audio driver usually already binds to some device (PCI or platform > device), > I think the audio driver cannot bind to the new avsink devices created by > display driver, and we need a new driver to handle these device and > communication. > > While the display driver creates the new endpoint "avsink" devices, the audio > driver can also create the same number of audio endpoint devices. > And we could let the audio endpoint device be the master and its peer display > endpoint device be the component. > Thus the master/component framework can help us to bind/unbind each pair of > display/audio endpoint devices. > > Is it doable? If okay, I'll modify the RFC and see if there are other gaps. Yeah, that should be doable. gfx creates avsink devices, audio binds to them using the component framework. > > > In addition, the component framework does not touch PM now. > > > And introducing PM to the component framework seems not easy since > > > there can be potential conflict caused by parent-child relationship of > > > the involved devices. > > > > Yeah, the entire PM situation seems to be a bit bad. It also looks like on > > resume/suspend we still have problems, at least on the audio side since > > we need to coordinate between 2 completel different underlying devices. > > But at least with the parent->child relationship we have a guranatee that > > the avsink won't be suspended after the gfx device is already off. > > -Daniel > > Yes. You're right. > And we could find a way to hide the Intel-specific display "power well" > from the audio driver by using runtime PM API on these devices. Yeah, that's one of the goals a I have here. Cheers, Daneil -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - 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] [v5] drm/i915/bdw: Only use 2g GGTT for 32b platforms
On Tue, Jun 03, 2014 at 06:05:45AM +, Yang, Guang A wrote: > Tested-by: "Yang, Guang A" > With this patch, the 32 bit system can be able to boot normally. I wonder what's going to happen on 64 bit kernels with 32 bit userspace. Since that one's a really common thing with games. Whatever. Queued for -next, thanks for the patch. -Daniel > > > > Best Regards~~ > > Open Source Technology Center (OTC) > Terence Yang（杨光） > Tel: 86-021-61167360 > iNet: 8821-7360 > > > -Original Message- > > From: Intel-gfx [mailto:intel-gfx-boun...@lists.freedesktop.org] On Behalf > > Of > > Ben Widawsky > > Sent: Wednesday, May 28, 2014 7:53 AM > > To: Intel GFX > > Cc: Ben Widawsky; sta...@vger.kernel.org; Widawsky, Benjamin > > Subject: [Intel-gfx] [PATCH] [v5] drm/i915/bdw: Only use 2g GGTT for 32b > > platforms > > > > Daniel requested in the bug that I use a 3GB fallback size. Since this is > > not in > > the spec as a valid size, I decided against it. We could potentially add a > > patch to > > bump it to 3GB on top of this one. > > > > This probably should be CC: stable - but I'll let the powers that be decide > > that > > one. > > > > Regression from a revert of the revert: > > commit 7907f45bf9f67a1c5e5d4ae05bab428d7c2f43b2 > > Author: Ben Widawsky > > Date: Wed Feb 19 22:05:46 2014 -0800 > > > > Revert "drm/i915/bdw: Limit GTT to 2GB" > > > > v2: Change ifdef to 32b, instead of ifndef update comment > > > > v3. Update comment to not wrap (Daniel). > > Update commit message > > > > v4: s/CONFIG_32/CONFIG_X86_32 (Jani). > > > > v5: s/CONFIG_x86_32BIT/CONFIG_x86_32, as meant in v4 s/32B/32b (chris) > > > > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=76619 > > Cc: sta...@vger.kernel.org > > Reviewed-by: Daniel Vetter > > Signed-off-by: Rodrigo Vivi > > Signed-off-by: Ben Widawsky > > --- > > drivers/gpu/drm/i915/i915_gem_gtt.c | 7 +++ > > 1 file changed, 7 insertions(+) > > > > diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c > > b/drivers/gpu/drm/i915/i915_gem_gtt.c > > index 931b906..eec820a 100644 > > --- a/drivers/gpu/drm/i915/i915_gem_gtt.c > > +++ b/drivers/gpu/drm/i915/i915_gem_gtt.c > > @@ -1775,6 +1775,13 @@ static inline unsigned int > > gen8_get_total_gtt_size(u16 bdw_gmch_ctl) > > bdw_gmch_ctl &= BDW_GMCH_GGMS_MASK; > > if (bdw_gmch_ctl) > > bdw_gmch_ctl = 1 << bdw_gmch_ctl; > > + > > +#ifdef CONFIG_X86_32 > > + /* Limit 32b platforms to a 2GB GGTT: 4 << 20 / pte size * PAGE_SIZE */ > > + if (bdw_gmch_ctl > 4) > > + bdw_gmch_ctl = 4; > > +#endif > > + > > return bdw_gmch_ctl << 20; > > } > > > > -- > > 1.9.3 > > > > ___ > > 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 -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - 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: Drop unused lut tables from intel_plane
On Mon, Jun 02, 2014 at 07:06:52PM +0100, Damien Lespiau wrote:
> On Mon, Jun 02, 2014 at 10:12:06AM -0700, Matt Roper wrote:
> > Signed-off-by: Matt Roper
>
> The commit message is a bit terse and could do with some digging.
> Something like:
>
> Those LUT where defined in the original sprite patch introducing intel_plane,
> but were never used.
>
> commit b840d907fcf6d5d5ef91af4518b3dab3a5da0f75
> Author: Jesse Barnes
> Date: Tue Dec 13 13:19:38 2011 -0800
>
> drm/i915: add SNB and IVB video sprite support v6
Added.
> Reviewed-by: Damien Lespiau
Queued for -next, thanks for the patch.
-Daniel
>
> > ---
> > drivers/gpu/drm/i915/intel_drv.h | 1 -
> > 1 file changed, 1 deletion(-)
> >
> > diff --git a/drivers/gpu/drm/i915/intel_drv.h
> > b/drivers/gpu/drm/i915/intel_drv.h
> > index 76de420..fea8e05 100644
> > --- a/drivers/gpu/drm/i915/intel_drv.h
> > +++ b/drivers/gpu/drm/i915/intel_drv.h
> > @@ -428,7 +428,6 @@ struct intel_plane {
> > struct drm_i915_gem_object *obj;
> > bool can_scale;
> > int max_downscale;
> > - u32 lut_r[1024], lut_g[1024], lut_b[1024];
> > int crtc_x, crtc_y;
> > unsigned int crtc_w, crtc_h;
> > uint32_t src_x, src_y;
> > --
> > 1.8.5.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
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915: Simplify intel_gpu_reset
From: Robert Beckett
Replaced ever growing switch for gen version with chained conditionals.
Futre gen's only need to add a new one if they require something different.
Reviewed-by: Damien Lespiau
Signed-off-by: Robert Beckett
[danvet: Picked from internal tree and white-wash commit message.]
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/i915/intel_uncore.c | 22 ++
1 file changed, 10 insertions(+), 12 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_uncore.c
b/drivers/gpu/drm/i915/intel_uncore.c
index b1dd880c3093..acffcecf79d4 100644
--- a/drivers/gpu/drm/i915/intel_uncore.c
+++ b/drivers/gpu/drm/i915/intel_uncore.c
@@ -1177,18 +1177,16 @@ static int gen6_do_reset(struct drm_device *dev)
int intel_gpu_reset(struct drm_device *dev)
{
- switch (INTEL_INFO(dev)->gen) {
- case 8:
- case 7:
- case 6: return gen6_do_reset(dev);
- case 5: return ironlake_do_reset(dev);
- case 4:
- if (IS_G4X(dev))
- return g4x_do_reset(dev);
- else
- return i965_do_reset(dev);
- default: return -ENODEV;
- }
+ if (INTEL_INFO(dev)->gen >= 6)
+ return gen6_do_reset(dev);
+ else if (IS_GEN5(dev))
+ return ironlake_do_reset(dev);
+ else if (IS_G4X(dev))
+ return g4x_do_reset(dev);
+ else if (IS_GEN4(dev))
+ return i965_do_reset(dev);
+ else
+ return -ENODEV;
}
void intel_uncore_check_errors(struct drm_device *dev)
--
1.8.3.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915/vlv: T12 eDP panel timing enforcement during reboot.
On Mon, 02 Jun 2014, clinton.a.tay...@intel.com wrote:
> From: Clint Taylor
>
> The panel power sequencer on vlv doesn't appear to accept changes to its
> T12 power down duration during warm reboots. This change forces a delay
> for warm reboots to the T12 panel timing as defined in the VBT table for
> the connected panel.
>
> Ver2: removed redundant pr_crit(), commented magic value for pp_div_reg
>
> Ver3: moved SYS_RESTART check earlier, new name for pp_div.
>
> Signed-off-by: Clint Taylor
> ---
> drivers/gpu/drm/i915/intel_dp.c | 42
> ++
> drivers/gpu/drm/i915/intel_drv.h |2 ++
> 2 files changed, 44 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
> index 5ca68aa9..fb7725a 100644
> --- a/drivers/gpu/drm/i915/intel_dp.c
> +++ b/drivers/gpu/drm/i915/intel_dp.c
> @@ -28,6 +28,8 @@
> #include
> #include
> #include
> +#include
> +#include
> #include
> #include
> #include
> @@ -302,6 +304,38 @@ static u32 _pp_stat_reg(struct intel_dp *intel_dp)
> return VLV_PIPE_PP_STATUS(vlv_power_sequencer_pipe(intel_dp));
> }
>
> +/* Reboot notifier handler to shutdown panel power to guarantee T12 timing */
> +static int edp_notify_handler(struct notifier_block *this, unsigned long
> code,
> + void *unused)
> +{
> + struct intel_dp *intel_dp = container_of(this, typeof(* intel_dp),
> + edp_notifier);
> + struct intel_digital_port *intel_dig_port = dp_to_dig_port(intel_dp);
> + struct drm_device *dev = intel_dig_port->base.base.dev;
> + struct drm_i915_private *dev_priv = dev->dev_private;
> + u32 pp_div;
> + u32 pp_ctrl_reg, pp_div_reg;
> + enum pipe pipe = vlv_power_sequencer_pipe(intel_dp);
> +
> + if ((!is_edp(intel_dp)) &&
> + (code != SYS_RESTART ))
Should be:
if (!is_edp(intel_dp) || code != SYS_RESTART)
> + return 0;
> +
> + if (IS_VALLEYVIEW(dev)) {
> + pp_ctrl_reg = VLV_PIPE_PP_CONTROL(pipe);
> + pp_div_reg = VLV_PIPE_PP_DIVISOR(pipe);
> + pp_div = I915_READ(VLV_PIPE_PP_DIVISOR(pipe));
> + pp_div &= PP_REFERENCE_DIVIDER_MASK;
> +
> + /* 0x1F write to PP_DIV_REG sets max cycle delay */
> + I915_WRITE(pp_div_reg , pp_div | 0x1F);
Superfluous space before comma.
> + I915_WRITE(pp_ctrl_reg,
> +PANEL_UNLOCK_REGS | PANEL_POWER_OFF);
> + msleep(intel_dp->panel_power_cycle_delay);
> + }
A blank line before final return statement is customary.
> + return 0;
> +}
> +
> static bool edp_have_panel_power(struct intel_dp *intel_dp)
> {
> struct drm_device *dev = intel_dp_to_dev(intel_dp);
> @@ -3344,6 +3378,10 @@ void intel_dp_encoder_destroy(struct drm_encoder
> *encoder)
> mutex_lock(&dev->mode_config.mutex);
> edp_panel_vdd_off_sync(intel_dp);
> mutex_unlock(&dev->mode_config.mutex);
> + if (intel_dp->edp_notifier.notifier_call) {
> + unregister_reboot_notifier(&intel_dp->edp_notifier);
> + intel_dp->edp_notifier.notifier_call = NULL;
> + }
> }
> kfree(intel_dig_port);
> }
> @@ -3782,6 +3820,10 @@ intel_dp_init_connector(struct intel_digital_port
> *intel_dig_port,
> if (is_edp(intel_dp)) {
> intel_dp_init_panel_power_timestamps(intel_dp);
> intel_dp_init_panel_power_sequencer(dev, intel_dp, &power_seq);
> + if (IS_VALLEYVIEW(dev)) {
> + intel_dp->edp_notifier.notifier_call =
> edp_notify_handler;
> + register_reboot_notifier(&intel_dp->edp_notifier);
> + }
> }
>
> intel_dp_aux_init(intel_dp, intel_connector);
> diff --git a/drivers/gpu/drm/i915/intel_drv.h
> b/drivers/gpu/drm/i915/intel_drv.h
> index 328b1a7..ea2cc07 100644
> --- a/drivers/gpu/drm/i915/intel_drv.h
> +++ b/drivers/gpu/drm/i915/intel_drv.h
> @@ -510,6 +510,8 @@ struct intel_dp {
> unsigned long last_power_on;
> unsigned long last_backlight_off;
> bool psr_setup_done;
> + struct notifier_block edp_notifier;
Use only one space between type and name.
With all of the above fixed it's
Reviewed-by: Jani Nikula
> +
> bool use_tps3;
> struct intel_connector *attached_connector;
>
> --
> 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 03/11] drm/i915: Use HAS_PSR to avoid unecessary interactions.
On 5/16/2014 5:43 AM, Rodrigo Vivi wrote:
Let's be more conservative and protect platforms that don't
support PSR from unecessary interactions.
Signed-off-by: Rodrigo Vivi
---
drivers/gpu/drm/i915/intel_dp.c | 13 -
1 file changed, 8 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 34e8f7a..58537b7 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -1739,11 +1739,6 @@ static bool intel_edp_psr_match_conditions(struct
intel_dp *intel_dp)
dev_priv->psr.source_ok = false;
- if (!HAS_PSR(dev)) {
- DRM_DEBUG_KMS("PSR not supported on this platform\n");
- return false;
- }
-
if ((intel_encoder->type != INTEL_OUTPUT_EDP) ||
(dig_port->port != PORT_A)) {
DRM_DEBUG_KMS("HSW ties PSR to DDI A (eDP)\n");
@@ -1816,6 +1811,11 @@ void intel_edp_psr_enable(struct intel_dp *intel_dp)
{
struct drm_device *dev = intel_dp_to_dev(intel_dp);
+ if (!HAS_PSR(dev)) {
+ DRM_DEBUG_KMS("PSR not supported on this platform\n");
+ return;
+ }
+
if (intel_edp_psr_match_conditions(intel_dp) &&
!intel_edp_is_psr_enabled(dev))
intel_edp_psr_do_enable(intel_dp);
@@ -1843,6 +1843,9 @@ void intel_edp_psr_update(struct drm_device *dev)
struct intel_encoder *encoder;
struct intel_dp *intel_dp = NULL;
+ if (!HAS_PSR(dev))
+ return;
+
list_for_each_entry(encoder, &dev->mode_config.encoder_list, base.head)
if (encoder->type == INTEL_OUTPUT_EDP) {
intel_dp = enc_to_intel_dp(&encoder->base);
Reviewed-by: Vijay Purushothaman
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 04/11] drm/i915: Don't let update_psr function actually enable PSR.
On 5/16/2014 5:43 AM, Rodrigo Vivi wrote:
Being more conservative by enabling PSR only on psr_enable function.
Signed-off-by: Rodrigo Vivi
---
drivers/gpu/drm/i915/intel_dp.c | 10 +++---
1 file changed, 7 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 58537b7..fe28eb7 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -1797,9 +1797,6 @@ static void intel_edp_psr_do_enable(struct intel_dp
*intel_dp)
intel_edp_is_psr_enabled(dev))
return;
- /* Setup PSR once */
- intel_edp_psr_setup(intel_dp);
-
/* Enable PSR on the panel */
intel_edp_psr_enable_sink(intel_dp);
@@ -1816,6 +1813,9 @@ void intel_edp_psr_enable(struct intel_dp *intel_dp)
return;
}
+ /* Setup PSR once */
+ intel_edp_psr_setup(intel_dp);
+
if (intel_edp_psr_match_conditions(intel_dp) &&
!intel_edp_is_psr_enabled(dev))
intel_edp_psr_do_enable(intel_dp);
@@ -1840,12 +1840,16 @@ void intel_edp_psr_disable(struct intel_dp *intel_dp)
void intel_edp_psr_update(struct drm_device *dev)
{
+ struct drm_i915_private *dev_priv = dev->dev_private;
struct intel_encoder *encoder;
struct intel_dp *intel_dp = NULL;
if (!HAS_PSR(dev))
return;
+ if (!dev_priv->psr.setup_done)
+ return;
+
list_for_each_entry(encoder, &dev->mode_config.encoder_list, base.head)
if (encoder->type == INTEL_OUTPUT_EDP) {
intel_dp = enc_to_intel_dp(&encoder->base);
Reviewed-by: Vijay Purushothaman
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 06/11] drm/i915: Force PSR exit by inactivating it.
On 5/16/2014 10:12 PM, Rodrigo Vivi wrote: On Fri, May 16, 2014 at 3:23 AM, Chris Wilson mailto:ch...@chris-wilson.co.uk>> wrote: On Thu, May 15, 2014 at 08:13:05PM -0400, Rodrigo Vivi wrote: > The perfect solution for psr_exit is the hardware tracking the changes and > doing the psr exit by itself. This scenario works for HSW and BDW with some > environments like Gnome and Wayland. > > However there are many other scenarios that this isn't true. Mainly one right > now is KDE users on HSW and BDW with PSR on. User would miss many screen > updates. For instances any key typed could be seen only when mouse cursor is > moved. So this patch introduces the ability of trigger PSR exit on kernel side > on some common cases that. You know that userspace has been waiting for a PSR flag for over a year now so that it can use the more efficient rendering paths when it makes sense. yeah... this item is lingering on my to do list... but reaching a point where I won't be able to continue postponing it ;) What happened to the front buffer tracking? What front buffer tracking? hehe I'm wondering about this since I started looking to fbc and psr and could never find a reliable way. FBC should cover most of the scenarios except cursor planes.. When ever cursor planes are enabled you can fall back to s/w controlled exit path. If you can elaborate on the exact issue that you are facing with FBC and PSR may be i can help.. Thanks, Vijay -Chris -- Chris Wilson, Intel Open Source Technology Centre -- Rodrigo Vivi Blog: http://blog.vivi.eng.br ___ 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 08/11] drm/i915: BDW PSR: Remove limitations that aren't valid for BDW.
On 5/16/2014 5:43 AM, Rodrigo Vivi wrote:
Signed-off-by: Rodrigo Vivi
---
drivers/gpu/drm/i915/intel_dp.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 28144d3..9421b0b 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -1768,6 +1768,10 @@ static bool intel_edp_psr_match_conditions(struct
intel_dp *intel_dp)
return false;
}
+ /* Below limitations aren't valid for Broadwell */
+ if (IS_BROADWELL(dev))
+ goto out;
I couldn't figure out any sprite related restrictions for HSW as well.
Is this because FBC logic doesn't track sprites in HSW?
Thanks,
Vijay
+
if (I915_READ(SPRCTL(intel_crtc->pipe)) & SPRITE_ENABLE) {
DRM_DEBUG_KMS("PSR condition failed: Sprite is Enabled\n");
return false;
@@ -1784,6 +1788,7 @@ static bool intel_edp_psr_match_conditions(struct
intel_dp *intel_dp)
return false;
}
+ out:
dev_priv->psr.source_ok = true;
return true;
}
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 10/11] drm/i915: Improve PSR debugfs status.
On 6/3/2014 1:10 PM, Daniel Vetter wrote: On Mon, Jun 02, 2014 at 11:54:10PM +0530, Vijay Purushothaman wrote: On 5/16/2014 5:43 AM, Rodrigo Vivi wrote: Now we have the active/inactive state for exit and this actually changes the HW enable bit the status was a bit confusing for users. So let's provide more info. Signed-off-by: Rodrigo Vivi --- drivers/gpu/drm/i915/i915_debugfs.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/i915/i915_debugfs.c b/drivers/gpu/drm/i915/i915_debugfs.c index 6636ca2..0ca9376 100644 --- a/drivers/gpu/drm/i915/i915_debugfs.c +++ b/drivers/gpu/drm/i915/i915_debugfs.c @@ -1975,10 +1975,12 @@ static int i915_edp_psr_status(struct seq_file *m, void *data) seq_printf(m, "Sink_Support: %s\n", yesno(dev_priv->psr.sink_support)); seq_printf(m, "Source_OK: %s\n", yesno(dev_priv->psr.source_ok)); + seq_printf(m, "Enabled: %s\n", yesno(dev_priv->psr.enabled)); + seq_printf(m, "Active: %s\n", yesno(dev_priv->psr.active)); enabled = HAS_PSR(dev) && I915_READ(EDP_PSR_CTL(dev)) & EDP_PSR_ENABLE; - seq_printf(m, "Enabled: %s\n", yesno(enabled)); + seq_printf(m, "HW Enabled & Active bit: %s\n", yesno(enabled)); if (HAS_PSR(dev)) psrperf = I915_READ(EDP_PSR_PERF_CNT(dev)) & Please remove all references to PSR performance counter. This register is primarily meant as a debug register and its implementation is broken in the h/w. Whenever the cdclk is gated to save power, the performance counter is stopped. But when the clk is re-enabled it doesn't reset the counter. This unnecessarily confuses the end users.. When the system goes through suspend / resume cycle the performance counter most likely will transition from a non-zero value to zero.. I already received few queries from our customers related to this performance customer and they refuse to believe me when i tell them PSR is still functional when the performance counter reports 0 :-) We expose other such perf registers and imo this is handy for debugging. Also we have a big push to expose all this perf stuff recently ... Imo we should keep this, if we can. If confused customers noodle around in debugfs without clue, maybe they shouldn't. -Daniel In that case here is my Reviewed-by: Vijay Purushothaman Thanks, Vijay ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 11/11] drm/i915: PSR HSW: update after enabling sprite.
On 5/16/2014 5:43 AM, Rodrigo Vivi wrote: On the current structure HSW doesn't support PSR with sprites enabled but sprites can be enabled after PSR was enabled what would cause user to miss screen updates. Could you please explain this a bit more? Did you get a confirmation from h/w team that this is not possible? AFAIK, HSW should be able to support PSR with sprites enabled. Thanks, Vijay v2: move it to update_plane. Cc: Ville Syrjälä Signed-off-by: Rodrigo Vivi --- drivers/gpu/drm/i915/intel_sprite.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/gpu/drm/i915/intel_sprite.c b/drivers/gpu/drm/i915/intel_sprite.c index 213cd58..4b85400 100644 --- a/drivers/gpu/drm/i915/intel_sprite.c +++ b/drivers/gpu/drm/i915/intel_sprite.c @@ -1051,6 +1051,8 @@ intel_update_plane(struct drm_plane *plane, struct drm_crtc *crtc, mutex_unlock(&dev->struct_mutex); } + intel_edp_psr_update(dev); + return 0; } ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2 2/8] drm/i915: replace drm_get_connector_name() with direct name field use
Generated using semantic patches:
@@
expression E;
@@
- drm_get_connector_name(&E)
+ E.name
@@
expression E;
@@
- drm_get_connector_name(E)
+ E->name
v2: Turn drm_get_connector_name(&E) into E.name instead of &(E)->name.
Acked-by: David Herrmann
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/i915_debugfs.c | 4 ++--
drivers/gpu/drm/i915/i915_irq.c | 8
drivers/gpu/drm/i915/intel_crt.c | 2 +-
drivers/gpu/drm/i915/intel_display.c | 16
drivers/gpu/drm/i915/intel_dp.c | 2 +-
drivers/gpu/drm/i915/intel_dvo.c | 2 +-
drivers/gpu/drm/i915/intel_fbdev.c | 2 +-
drivers/gpu/drm/i915/intel_hdmi.c| 2 +-
drivers/gpu/drm/i915/intel_lvds.c| 2 +-
drivers/gpu/drm/i915/intel_panel.c | 2 +-
drivers/gpu/drm/i915/intel_sdvo.c| 8
drivers/gpu/drm/i915/intel_tv.c | 2 +-
12 files changed, 26 insertions(+), 26 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
b/drivers/gpu/drm/i915/i915_debugfs.c
index 18b3565f431a..6f2cad83e2f4 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -2161,7 +2161,7 @@ static void intel_encoder_info(struct seq_file *m,
struct drm_connector *connector = &intel_connector->base;
seq_printf(m, "\t\tconnector %d: type: %s, status: %s",
connector->base.id,
- drm_get_connector_name(connector),
+ connector->name,
drm_get_connector_status_name(connector->status));
if (connector->status == connector_status_connected) {
struct drm_display_mode *mode = &crtc->mode;
@@ -2232,7 +2232,7 @@ static void intel_connector_info(struct seq_file *m,
struct drm_display_mode *mode;
seq_printf(m, "connector %d: type %s, status: %s\n",
- connector->base.id, drm_get_connector_name(connector),
+ connector->base.id, connector->name,
drm_get_connector_status_name(connector->status));
if (connector->status == connector_status_connected) {
seq_printf(m, "\tname: %s\n", connector->display_info.name);
diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index 2d7618366b75..8c516be8e206 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -949,7 +949,7 @@ static bool intel_hpd_irq_event(struct drm_device *dev,
DRM_DEBUG_KMS("[CONNECTOR:%d:%s] status updated from %s to %s\n",
connector->base.id,
- drm_get_connector_name(connector),
+ connector->name,
drm_get_connector_status_name(old_status),
drm_get_connector_status_name(connector->status));
@@ -994,7 +994,7 @@ static void i915_hotplug_work_func(struct work_struct *work)
connector->polled == DRM_CONNECTOR_POLL_HPD) {
DRM_INFO("HPD interrupt storm detected on connector %s:
"
"switching from hotplug detection to
polling\n",
- drm_get_connector_name(connector));
+ connector->name);
dev_priv->hpd_stats[intel_encoder->hpd_pin].hpd_mark =
HPD_DISABLED;
connector->polled = DRM_CONNECTOR_POLL_CONNECT
| DRM_CONNECTOR_POLL_DISCONNECT;
@@ -1002,7 +1002,7 @@ static void i915_hotplug_work_func(struct work_struct
*work)
}
if (hpd_event_bits & (1 << intel_encoder->hpd_pin)) {
DRM_DEBUG_KMS("Connector %s (pin %i) received hotplug
event.\n",
- drm_get_connector_name(connector),
intel_encoder->hpd_pin);
+ connector->name, intel_encoder->hpd_pin);
}
}
/* if there were no outputs to poll, poll was disabled,
@@ -3993,7 +3993,7 @@ static void intel_hpd_irq_reenable(unsigned long data)
if (intel_connector->encoder->hpd_pin == i) {
if (connector->polled !=
intel_connector->polled)
DRM_DEBUG_DRIVER("Reenabling HPD on
connector %s\n",
-
drm_get_connector_name(connector));
+connector->name);
connector->polled = intel_connector->polled;
if (!connector->polled)
connector->polled =
DRM_CONNECTOR_POLL_HPD;
diff --git a/drivers/gpu/drm/i915/intel_crt.c b/drivers/gpu/drm/i915/intel_crt.c
index 22d8347f7838..1fc91df58296 100644
--- a/drivers/gpu/drm/i915/intel_crt.c
+++ b/drivers/gpu/drm/i915/intel_crt.c
@@ -634,7 +634,7 @@ intel_crt_
[Intel-gfx] [PATCH v2 5/8] drm: replace drm_get_connector_name() with direct name field use
Generated using semantic patch:
@@
expression E;
@@
- drm_get_connector_name(E)
+ E->name
Acked-by: David Herrmann
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/drm_crtc.c | 4 ++--
drivers/gpu/drm/drm_crtc_helper.c | 6 +++---
drivers/gpu/drm/drm_edid.c | 6 +++---
drivers/gpu/drm/drm_edid_load.c| 2 +-
drivers/gpu/drm/drm_fb_helper.c| 6 +++---
drivers/gpu/drm/drm_probe_helper.c | 10 +-
drivers/gpu/drm/drm_sysfs.c| 6 +++---
7 files changed, 20 insertions(+), 20 deletions(-)
diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
index edee61bccd14..242937c76638 100644
--- a/drivers/gpu/drm/drm_crtc.c
+++ b/drivers/gpu/drm/drm_crtc.c
@@ -1663,7 +1663,7 @@ int drm_mode_getresources(struct drm_device *dev, void
*data,
head) {
DRM_DEBUG_KMS("[CONNECTOR:%d:%s]\n",
connector->base.id,
- drm_get_connector_name(connector));
+ connector->name);
if (put_user(connector->base.id,
connector_id + copied)) {
ret = -EFAULT;
@@ -2458,7 +2458,7 @@ int drm_mode_setcrtc(struct drm_device *dev, void *data,
connector = obj_to_connector(obj);
DRM_DEBUG_KMS("[CONNECTOR:%d:%s]\n",
connector->base.id,
- drm_get_connector_name(connector));
+ connector->name);
connector_set[i] = connector;
}
diff --git a/drivers/gpu/drm/drm_crtc_helper.c
b/drivers/gpu/drm/drm_crtc_helper.c
index 54e8fdba02b4..d31659f7dfaa 100644
--- a/drivers/gpu/drm/drm_crtc_helper.c
+++ b/drivers/gpu/drm/drm_crtc_helper.c
@@ -600,11 +600,11 @@ int drm_crtc_helper_set_config(struct drm_mode_set *set)
}
if (new_crtc) {
DRM_DEBUG_KMS("[CONNECTOR:%d:%s] to [CRTC:%d]\n",
- connector->base.id,
drm_get_connector_name(connector),
+ connector->base.id, connector->name,
new_crtc->base.id);
} else {
DRM_DEBUG_KMS("[CONNECTOR:%d:%s] to [NOCRTC]\n",
- connector->base.id,
drm_get_connector_name(connector));
+ connector->base.id, connector->name);
}
}
@@ -630,7 +630,7 @@ int drm_crtc_helper_set_config(struct drm_mode_set *set)
DRM_DEBUG_KMS("Setting connector DPMS state to on\n");
for (i = 0; i < set->num_connectors; i++) {
DRM_DEBUG_KMS("\t[CONNECTOR:%d:%s] set DPMS
on\n", set->connectors[i]->base.id,
-
drm_get_connector_name(set->connectors[i]));
+ set->connectors[i]->name);
set->connectors[i]->funcs->dpms(set->connectors[i], DRM_MODE_DPMS_ON);
}
}
diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index d74239fec291..ab8aa6d462e6 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -1227,7 +1227,7 @@ drm_do_get_edid(struct drm_connector *connector, struct
i2c_adapter *adapter)
if (i == 4 && print_bad_edid) {
dev_warn(connector->dev->dev,
"%s: Ignoring invalid EDID block %d.\n",
-drm_get_connector_name(connector), j);
+connector->name, j);
connector->bad_edid_counter++;
}
@@ -1247,7 +1247,7 @@ drm_do_get_edid(struct drm_connector *connector, struct
i2c_adapter *adapter)
carp:
if (print_bad_edid) {
dev_warn(connector->dev->dev, "%s: EDID block %d invalid.\n",
-drm_get_connector_name(connector), j);
+connector->name, j);
}
connector->bad_edid_counter++;
@@ -3517,7 +3517,7 @@ int drm_add_edid_modes(struct drm_connector *connector,
struct edid *edid)
}
if (!drm_edid_is_valid(edid)) {
dev_warn(connector->dev->dev, "%s: EDID invalid.\n",
-drm_get_connector_name(connector));
+connector->name);
return 0;
}
diff --git a/drivers/gpu/drm/drm_edid_load.c b/drivers/gpu/drm/drm_edid_load.c
index 6e09f615ebc9..0a235fe61c9b 100644
--- a/drivers/gpu/drm/drm_edid_load.c
+++ b/drivers/gpu/drm/drm_edid_load.c
@@ -261,7 +261,7 @@ out:
int drm_load_edid_firmware(struct drm_connector *connector)
{
- const char *conn
[Intel-gfx] [PATCH v2 4/8] drm/radeon: replace drm_get_connector_name() with direct name field use
Generated using semantic patch:
@@
expression E;
@@
- drm_get_connector_name(E)
+ E->name
Acked-by: Alex Deucher
Acked-by: David Herrmann
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/radeon/radeon_connectors.c | 19 ---
drivers/gpu/drm/radeon/radeon_display.c| 2 +-
2 files changed, 13 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/radeon/radeon_connectors.c
b/drivers/gpu/drm/radeon/radeon_connectors.c
index ea50e0ae7bf7..19e733d5a7a4 100644
--- a/drivers/gpu/drm/radeon/radeon_connectors.c
+++ b/drivers/gpu/drm/radeon/radeon_connectors.c
@@ -260,13 +260,17 @@ radeon_connector_analog_encoder_conflict_solve(struct
drm_connector *connector,
continue;
if (priority == true) {
- DRM_DEBUG_KMS("1: conflicting encoders
switching off %s\n", drm_get_connector_name(conflict));
- DRM_DEBUG_KMS("in favor of %s\n",
drm_get_connector_name(connector));
+ DRM_DEBUG_KMS("1: conflicting encoders
switching off %s\n",
+ conflict->name);
+ DRM_DEBUG_KMS("in favor of %s\n",
+ connector->name);
conflict->status =
connector_status_disconnected;
radeon_connector_update_scratch_regs(conflict, connector_status_disconnected);
} else {
- DRM_DEBUG_KMS("2: conflicting encoders
switching off %s\n", drm_get_connector_name(connector));
- DRM_DEBUG_KMS("in favor of %s\n",
drm_get_connector_name(conflict));
+ DRM_DEBUG_KMS("2: conflicting encoders
switching off %s\n",
+ connector->name);
+ DRM_DEBUG_KMS("in favor of %s\n",
+ conflict->name);
current_status =
connector_status_disconnected;
}
break;
@@ -787,7 +791,7 @@ radeon_vga_detect(struct drm_connector *connector, bool
force)
if (!radeon_connector->edid) {
DRM_ERROR("%s: probed a monitor but no|invalid EDID\n",
- drm_get_connector_name(connector));
+ connector->name);
ret = connector_status_connected;
} else {
radeon_connector->use_digital =
!!(radeon_connector->edid->input & DRM_EDID_INPUT_DIGITAL);
@@ -1010,12 +1014,13 @@ radeon_dvi_detect(struct drm_connector *connector, bool
force)
if (!radeon_connector->edid) {
DRM_ERROR("%s: probed a monitor but no|invalid EDID\n",
- drm_get_connector_name(connector));
+ connector->name);
/* rs690 seems to have a problem with connectors not
existing and always
* return a block of 0's. If we see this just stop
polling on this output */
if ((rdev->family == CHIP_RS690 || rdev->family ==
CHIP_RS740) && radeon_connector->base.null_edid_counter) {
ret = connector_status_disconnected;
- DRM_ERROR("%s: detected RS690 floating bus bug,
stopping ddc detect\n", drm_get_connector_name(connector));
+ DRM_ERROR("%s: detected RS690 floating bus bug,
stopping ddc detect\n",
+ connector->name);
radeon_connector->ddc_bus = NULL;
} else {
ret = connector_status_connected;
diff --git a/drivers/gpu/drm/radeon/radeon_display.c
b/drivers/gpu/drm/radeon/radeon_display.c
index 8d99d5ee8014..7a1a70a04d5a 100644
--- a/drivers/gpu/drm/radeon/radeon_display.c
+++ b/drivers/gpu/drm/radeon/radeon_display.c
@@ -657,7 +657,7 @@ static void radeon_print_display_setup(struct drm_device
*dev)
list_for_each_entry(connector, &dev->mode_config.connector_list, head) {
radeon_connector = to_radeon_connector(connector);
DRM_INFO("Connector %d:\n", i);
- DRM_INFO(" %s\n", drm_get_connector_name(connector));
+ DRM_INFO(" %s\n", connector->name);
if (radeon_connector->hpd.hpd != RADEON_HPD_NONE)
DRM_INFO(" %s\n",
hpd_names[radeon_connector->hpd.hpd]);
if (radeon_connector->ddc_bus) {
--
1.9.1
__
[Intel-gfx] [PATCH v2 0/8] drm & drivers: kill drm_get_connector_name() and drm_get_encoder_name()
Hi all, this is v2 of [1] to remove drm_get_connector_name() and drm_get_encoder_name(), adding patch 1 for imx in staging and making some dereferences less of an eye sore. This is based on Dave's drm-next branch. BR, Jani. [1] http://mid.gmane.org/cover.1401110921.git.jani.nik...@intel.com Jani Nikula (8): staging: imx-drm-core: replace drm_get_connector_name() with direct name field use drm/i915: replace drm_get_connector_name() with direct name field use drm/nouveau: replace drm_get_connector_name() with direct name field use drm/radeon: replace drm_get_connector_name() with direct name field use drm: replace drm_get_connector_name() with direct name field use drm/i915: replace drm_get_encoder_name() with direct name field use drm: replace drm_get_encoder_name() with direct name field use drm: drop drm_get_connector_name() and drm_get_encoder_name() drivers/gpu/drm/drm_crtc.c | 26 +++ drivers/gpu/drm/drm_crtc_helper.c | 8 drivers/gpu/drm/drm_edid.c | 6 +++--- drivers/gpu/drm/drm_edid_load.c | 2 +- drivers/gpu/drm/drm_fb_helper.c | 6 +++--- drivers/gpu/drm/drm_probe_helper.c | 10 - drivers/gpu/drm/drm_sysfs.c | 6 +++--- drivers/gpu/drm/i915/i915_debugfs.c | 6 +++--- drivers/gpu/drm/i915/i915_irq.c | 8 drivers/gpu/drm/i915/intel_crt.c| 2 +- drivers/gpu/drm/i915/intel_display.c| 32 ++--- drivers/gpu/drm/i915/intel_dp.c | 4 ++-- drivers/gpu/drm/i915/intel_dvo.c| 2 +- drivers/gpu/drm/i915/intel_fbdev.c | 2 +- drivers/gpu/drm/i915/intel_hdmi.c | 2 +- drivers/gpu/drm/i915/intel_lvds.c | 2 +- drivers/gpu/drm/i915/intel_panel.c | 2 +- drivers/gpu/drm/i915/intel_sdvo.c | 8 drivers/gpu/drm/i915/intel_tv.c | 2 +- drivers/gpu/drm/nouveau/dispnv04/dac.c | 2 +- drivers/gpu/drm/nouveau/dispnv04/dfp.c | 2 +- drivers/gpu/drm/nouveau/dispnv04/disp.c | 2 +- drivers/gpu/drm/nouveau/dispnv04/tvnv04.c | 3 ++- drivers/gpu/drm/nouveau/dispnv04/tvnv17.c | 3 +-- drivers/gpu/drm/nouveau/nouveau_connector.c | 8 drivers/gpu/drm/nouveau/nv50_display.c | 2 +- drivers/gpu/drm/radeon/radeon_connectors.c | 19 ++--- drivers/gpu/drm/radeon/radeon_display.c | 2 +- drivers/staging/imx-drm/imx-drm-core.c | 2 +- include/drm/drm_crtc.h | 2 -- 30 files changed, 83 insertions(+), 100 deletions(-) -- 1.9.1 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2 1/8] staging: imx-drm-core: replace drm_get_connector_name() with direct name field use
Generated using semantic patch: @@ expression E; @@ - drm_get_connector_name(E) + E->name Acked-by: David Herrmann Signed-off-by: Jani Nikula --- drivers/staging/imx-drm/imx-drm-core.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/staging/imx-drm/imx-drm-core.c b/drivers/staging/imx-drm/imx-drm-core.c index 53ff005245c5..6543b349bfb6 100644 --- a/drivers/staging/imx-drm/imx-drm-core.c +++ b/drivers/staging/imx-drm/imx-drm-core.c @@ -298,7 +298,7 @@ static int imx_drm_driver_load(struct drm_device *drm, unsigned long flags) dev_err(drm->dev, "[CONNECTOR:%d:%s] drm_sysfs_connector_add failed: %d\n", connector->base.id, - drm_get_connector_name(connector), ret); + connector->name, ret); goto err_unbind; } } -- 1.9.1 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2 7/8] drm: replace drm_get_encoder_name() with direct name field use
Generated using semantic patch:
@@
expression E;
@@
- drm_get_encoder_name(E)
+ E->name
Acked-by: David Herrmann
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/drm_crtc.c| 2 +-
drivers/gpu/drm/drm_crtc_helper.c | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
index 242937c76638..986531395872 100644
--- a/drivers/gpu/drm/drm_crtc.c
+++ b/drivers/gpu/drm/drm_crtc.c
@@ -1631,7 +1631,7 @@ int drm_mode_getresources(struct drm_device *dev, void
*data,
&dev->mode_config.encoder_list,
head) {
DRM_DEBUG_KMS("[ENCODER:%d:%s]\n",
encoder->base.id,
- drm_get_encoder_name(encoder));
+ encoder->name);
if (put_user(encoder->base.id, encoder_id +
copied)) {
ret = -EFAULT;
diff --git a/drivers/gpu/drm/drm_crtc_helper.c
b/drivers/gpu/drm/drm_crtc_helper.c
index d31659f7dfaa..231c9433341f 100644
--- a/drivers/gpu/drm/drm_crtc_helper.c
+++ b/drivers/gpu/drm/drm_crtc_helper.c
@@ -330,7 +330,7 @@ bool drm_crtc_helper_set_mode(struct drm_crtc *crtc,
continue;
DRM_DEBUG_KMS("[ENCODER:%d:%s] set [MODE:%d:%s]\n",
- encoder->base.id, drm_get_encoder_name(encoder),
+ encoder->base.id, encoder->name,
mode->base.id, mode->name);
encoder_funcs = encoder->helper_private;
encoder_funcs->mode_set(encoder, mode, adjusted_mode);
--
1.9.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2 3/8] drm/nouveau: replace drm_get_connector_name() with direct name field use
Generated using semantic patches:
@@
expression E;
@@
- drm_get_connector_name(&E)
+ E.name
@@
expression E;
@@
- drm_get_connector_name(E)
+ E->name
v2: Turn drm_get_connector_name(&E) into E.name instead of &(E)->name.
Acked-by: David Herrmann
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/nouveau/dispnv04/dac.c | 2 +-
drivers/gpu/drm/nouveau/dispnv04/dfp.c | 2 +-
drivers/gpu/drm/nouveau/dispnv04/disp.c | 2 +-
drivers/gpu/drm/nouveau/dispnv04/tvnv04.c | 3 ++-
drivers/gpu/drm/nouveau/dispnv04/tvnv17.c | 3 +--
drivers/gpu/drm/nouveau/nouveau_connector.c | 8
drivers/gpu/drm/nouveau/nv50_display.c | 2 +-
7 files changed, 11 insertions(+), 11 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/dispnv04/dac.c
b/drivers/gpu/drm/nouveau/dispnv04/dac.c
index 434b920f6bd4..a96dda48718e 100644
--- a/drivers/gpu/drm/nouveau/dispnv04/dac.c
+++ b/drivers/gpu/drm/nouveau/dispnv04/dac.c
@@ -414,7 +414,7 @@ static void nv04_dac_commit(struct drm_encoder *encoder)
helper->dpms(encoder, DRM_MODE_DPMS_ON);
NV_DEBUG(drm, "Output %s is running on CRTC %d using output %c\n",
-
drm_get_connector_name(&nouveau_encoder_connector_get(nv_encoder)->base),
+nouveau_encoder_connector_get(nv_encoder)->base.name,
nv_crtc->index, '@' + ffs(nv_encoder->dcb->or));
}
diff --git a/drivers/gpu/drm/nouveau/dispnv04/dfp.c
b/drivers/gpu/drm/nouveau/dispnv04/dfp.c
index a2d669b4acf2..e57babb206d3 100644
--- a/drivers/gpu/drm/nouveau/dispnv04/dfp.c
+++ b/drivers/gpu/drm/nouveau/dispnv04/dfp.c
@@ -477,7 +477,7 @@ static void nv04_dfp_commit(struct drm_encoder *encoder)
helper->dpms(encoder, DRM_MODE_DPMS_ON);
NV_DEBUG(drm, "Output %s is running on CRTC %d using output %c\n",
-
drm_get_connector_name(&nouveau_encoder_connector_get(nv_encoder)->base),
+nouveau_encoder_connector_get(nv_encoder)->base.name,
nv_crtc->index, '@' + ffs(nv_encoder->dcb->or));
}
diff --git a/drivers/gpu/drm/nouveau/dispnv04/disp.c
b/drivers/gpu/drm/nouveau/dispnv04/disp.c
index 2f1ed61f7c8c..4342fdaee707 100644
--- a/drivers/gpu/drm/nouveau/dispnv04/disp.c
+++ b/drivers/gpu/drm/nouveau/dispnv04/disp.c
@@ -115,7 +115,7 @@ nv04_display_create(struct drm_device *dev)
&dev->mode_config.connector_list, head) {
if (!connector->encoder_ids[0]) {
NV_WARN(drm, "%s has no encoders, removing\n",
- drm_get_connector_name(connector));
+ connector->name);
connector->funcs->destroy(connector);
}
}
diff --git a/drivers/gpu/drm/nouveau/dispnv04/tvnv04.c
b/drivers/gpu/drm/nouveau/dispnv04/tvnv04.c
index 244822df8ffc..8667620b703a 100644
--- a/drivers/gpu/drm/nouveau/dispnv04/tvnv04.c
+++ b/drivers/gpu/drm/nouveau/dispnv04/tvnv04.c
@@ -171,7 +171,8 @@ static void nv04_tv_commit(struct drm_encoder *encoder)
helper->dpms(encoder, DRM_MODE_DPMS_ON);
NV_DEBUG(drm, "Output %s is running on CRTC %d using output %c\n",
-
drm_get_connector_name(&nouveau_encoder_connector_get(nv_encoder)->base),
nv_crtc->index, '@' + ffs(nv_encoder->dcb->or));
+nouveau_encoder_connector_get(nv_encoder)->base.name,
+nv_crtc->index, '@' + ffs(nv_encoder->dcb->or));
}
static void nv04_tv_destroy(struct drm_encoder *encoder)
diff --git a/drivers/gpu/drm/nouveau/dispnv04/tvnv17.c
b/drivers/gpu/drm/nouveau/dispnv04/tvnv17.c
index acef48f4a4ea..195bd8e86c6a 100644
--- a/drivers/gpu/drm/nouveau/dispnv04/tvnv17.c
+++ b/drivers/gpu/drm/nouveau/dispnv04/tvnv17.c
@@ -612,8 +612,7 @@ static void nv17_tv_commit(struct drm_encoder *encoder)
helper->dpms(encoder, DRM_MODE_DPMS_ON);
NV_INFO(drm, "Output %s is running on CRTC %d using output %c\n",
- drm_get_connector_name(
- &nouveau_encoder_connector_get(nv_encoder)->base),
+ nouveau_encoder_connector_get(nv_encoder)->base.name,
nv_crtc->index, '@' + ffs(nv_encoder->dcb->or));
}
diff --git a/drivers/gpu/drm/nouveau/nouveau_connector.c
b/drivers/gpu/drm/nouveau/nouveau_connector.c
index d07ce028af51..6ecea9b2b15a 100644
--- a/drivers/gpu/drm/nouveau/nouveau_connector.c
+++ b/drivers/gpu/drm/nouveau/nouveau_connector.c
@@ -265,14 +265,14 @@ nouveau_connector_detect(struct drm_connector *connector,
bool force)
nv_connector->edid);
if (!nv_connector->edid) {
NV_ERROR(drm, "DDC responded, but no EDID for %s\n",
-drm_get_connector_name(connector));
+connector->name);
goto detect_analog;
}
if (nv_encoder->dcb->type == DCB_OUTPUT_DP &&
[Intel-gfx] [PATCH v2 8/8] drm: drop drm_get_connector_name() and drm_get_encoder_name()
No longer used or needed as the structs have a name field.
Acked-by: David Herrmann
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/drm_crtc.c | 20
include/drm/drm_crtc.h | 2 --
2 files changed, 22 deletions(-)
diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
index 986531395872..f6664a75ad57 100644
--- a/drivers/gpu/drm/drm_crtc.c
+++ b/drivers/gpu/drm/drm_crtc.c
@@ -257,26 +257,6 @@ void drm_connector_ida_destroy(void)
}
/**
- * drm_get_encoder_name - return a string for encoder
- * @encoder: the encoder to get name for
- */
-const char *drm_get_encoder_name(const struct drm_encoder *encoder)
-{
- return encoder->name;
-}
-EXPORT_SYMBOL(drm_get_encoder_name);
-
-/**
- * drm_get_connector_name - return a string for connector
- * @connector: the connector to get name for
- */
-const char *drm_get_connector_name(const struct drm_connector *connector)
-{
- return connector->name;
-}
-EXPORT_SYMBOL(drm_get_connector_name);
-
-/**
* drm_get_connector_status_name - return a string for connector status
* @status: connector status to compute name of
*
diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
index 5c1c31cc11cd..e8fe9d8e135c 100644
--- a/include/drm/drm_crtc.h
+++ b/include/drm/drm_crtc.h
@@ -909,7 +909,6 @@ extern int drm_crtc_check_viewport(const struct drm_crtc
*crtc,
extern void drm_encoder_cleanup(struct drm_encoder *encoder);
-extern const char *drm_get_connector_name(const struct drm_connector
*connector);
extern const char *drm_get_connector_status_name(enum drm_connector_status
status);
extern const char *drm_get_subpixel_order_name(enum subpixel_order order);
extern const char *drm_get_dpms_name(int val);
@@ -972,7 +971,6 @@ extern int drm_mode_create_tv_properties(struct drm_device
*dev, int num_formats
char *formats[]);
extern int drm_mode_create_scaling_mode_property(struct drm_device *dev);
extern int drm_mode_create_dirty_info_property(struct drm_device *dev);
-extern const char *drm_get_encoder_name(const struct drm_encoder *encoder);
extern int drm_mode_connector_attach_encoder(struct drm_connector *connector,
struct drm_encoder *encoder);
--
1.9.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2 6/8] drm/i915: replace drm_get_encoder_name() with direct name field use
Generated using semantic patches:
@@
expression E;
@@
- drm_get_encoder_name(&E)
+ E.name
@@
expression E;
@@
- drm_get_encoder_name(E)
+ E->name
v2: Turn drm_get_encoder_name(&E) into E.name instead of &(E)->name.
Acked-by: David Herrmann
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/i915_debugfs.c | 2 +-
drivers/gpu/drm/i915/intel_display.c | 16
drivers/gpu/drm/i915/intel_dp.c | 2 +-
3 files changed, 10 insertions(+), 10 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
b/drivers/gpu/drm/i915/i915_debugfs.c
index 6f2cad83e2f4..d092b087b99f 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -2156,7 +2156,7 @@ static void intel_encoder_info(struct seq_file *m,
encoder = &intel_encoder->base;
seq_printf(m, "\tencoder %d: type: %s, connectors:\n",
- encoder->base.id, drm_get_encoder_name(encoder));
+ encoder->base.id, encoder->name);
for_each_connector_on_encoder(dev, encoder, intel_connector) {
struct drm_connector *connector = &intel_connector->base;
seq_printf(m, "\t\tconnector %d: type: %s, status: %s",
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 87e5a586457e..9d8ad7e55d47 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -7206,7 +7206,7 @@ static int intel_crtc_mode_set(struct drm_crtc *crtc,
for_each_encoder_on_crtc(dev, crtc, encoder) {
DRM_DEBUG_KMS("[ENCODER:%d:%s] set [MODE:%d:%s]\n",
encoder->base.base.id,
- drm_get_encoder_name(&encoder->base),
+ encoder->base.name,
mode->base.id, mode->name);
if (encoder->mode_set)
@@ -7518,7 +7518,7 @@ void intel_write_eld(struct drm_encoder *encoder,
connector->base.id,
connector->name,
connector->encoder->base.id,
-drm_get_encoder_name(connector->encoder));
+connector->encoder->name);
connector->eld[6] = drm_av_sync_delay(connector, mode) / 2;
@@ -7986,7 +7986,7 @@ bool intel_get_load_detect_pipe(struct drm_connector
*connector,
DRM_DEBUG_KMS("[CONNECTOR:%d:%s], [ENCODER:%d:%s]\n",
connector->base.id, connector->name,
- encoder->base.id, drm_get_encoder_name(encoder));
+ encoder->base.id, encoder->name);
/*
* Algorithm gets a little messy:
@@ -8098,7 +8098,7 @@ void intel_release_load_detect_pipe(struct drm_connector
*connector,
DRM_DEBUG_KMS("[CONNECTOR:%d:%s], [ENCODER:%d:%s]\n",
connector->base.id, connector->name,
- encoder->base.id, drm_get_encoder_name(encoder));
+ encoder->base.id, encoder->name);
if (old->load_detect_temp) {
to_intel_connector(connector)->new_encoder = NULL;
@@ -9701,7 +9701,7 @@ check_encoder_state(struct drm_device *dev)
DRM_DEBUG_KMS("[ENCODER:%d:%s]\n",
encoder->base.base.id,
- drm_get_encoder_name(&encoder->base));
+ encoder->base.name);
WARN(&encoder->new_crtc->base != encoder->base.crtc,
"encoder's stage crtc doesn't match current crtc\n");
@@ -11526,7 +11526,7 @@ static void intel_sanitize_encoder(struct intel_encoder
*encoder)
if (encoder->connectors_active && !has_active_crtc) {
DRM_DEBUG_KMS("[ENCODER:%d:%s] has active connectors but no
active pipe!\n",
encoder->base.base.id,
- drm_get_encoder_name(&encoder->base));
+ encoder->base.name);
/* Connector is active, but has no active pipe. This is
* fallout from our resume register restoring. Disable
@@ -11534,7 +11534,7 @@ static void intel_sanitize_encoder(struct intel_encoder
*encoder)
if (encoder->base.crtc) {
DRM_DEBUG_KMS("[ENCODER:%d:%s] manually disabled\n",
encoder->base.base.id,
- drm_get_encoder_name(&encoder->base));
+ encoder->base.name);
encoder->disable(encoder);
}
@@ -11654,7 +11654,7 @@ static void intel_modeset_readout_hw_state(struct
drm_device *dev)
encoder->connectors_active = false;
DRM_DEBUG_KMS("[ENCODER:%d:%s] hw state readout: %s, pipe %c\n",
encoder->base.base.id,
- drm_get_encoder_name(&encoder->base),
+ encoder->base.name,
Re: [Intel-gfx] [PATCH] drm/i915: Make intel_dsi_init() return void
On Wed, 28 May 2014, Damien Lespiau wrote:
> Functions that can't fail are such a bliss to work with, it'd be shame
> to miss the occasion. The "failure" mode is the DSI connector not being
> created, the rest of the initialization can carry on happily.
>
> We weren't even checking that value anyway.
>
> Suggested-by: Ville Syrjälä
> Suggested-by: Shobhit Kumar
> Cc: Ville Syrjälä
> Cc: Shobhit Kumar
> Signed-off-by: Damien Lespiau
> ---
> drivers/gpu/drm/i915/intel_drv.h | 2 +-
> drivers/gpu/drm/i915/intel_dsi.c | 12 ++--
> 2 files changed, 7 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_drv.h
> b/drivers/gpu/drm/i915/intel_drv.h
> index edecf89..62686b2 100644
> --- a/drivers/gpu/drm/i915/intel_drv.h
> +++ b/drivers/gpu/drm/i915/intel_drv.h
> @@ -831,7 +831,7 @@ void intel_edp_psr_update(struct drm_device *dev);
> void intel_dp_set_drrs_state(struct drm_device *dev, int refresh_rate);
>
> /* intel_dsi.c */
> -bool intel_dsi_init(struct drm_device *dev);
> +void intel_dsi_init(struct drm_device *dev);
>
>
> /* intel_dvo.c */
> diff --git a/drivers/gpu/drm/i915/intel_dsi.c
> b/drivers/gpu/drm/i915/intel_dsi.c
> index e73bec6..4dbd160 100644
> --- a/drivers/gpu/drm/i915/intel_dsi.c
> +++ b/drivers/gpu/drm/i915/intel_dsi.c
> @@ -646,7 +646,7 @@ static const struct drm_connector_funcs
> intel_dsi_connector_funcs = {
> .fill_modes = drm_helper_probe_single_connector_modes,
> };
>
> -bool intel_dsi_init(struct drm_device *dev)
> +void intel_dsi_init(struct drm_device *dev)
> {
> struct intel_dsi *intel_dsi;
> struct intel_encoder *intel_encoder;
> @@ -662,12 +662,12 @@ bool intel_dsi_init(struct drm_device *dev)
>
> intel_dsi = kzalloc(sizeof(*intel_dsi), GFP_KERNEL);
> if (!intel_dsi)
> - return false;
> + return;
>
> intel_connector = kzalloc(sizeof(*intel_connector), GFP_KERNEL);
> if (!intel_connector) {
> kfree(intel_dsi);
> - return false;
> + return;
> }
>
> intel_encoder = &intel_dsi->base;
> @@ -678,7 +678,7 @@ bool intel_dsi_init(struct drm_device *dev)
> dev_priv->mipi_mmio_base = VLV_MIPI_BASE;
> } else {
> DRM_ERROR("Unsupported Mipi device to reg base");
> - return false;
> + return;
> }
>
> connector = &intel_connector->base;
> @@ -738,12 +738,12 @@ bool intel_dsi_init(struct drm_device *dev)
> fixed_mode->type |= DRM_MODE_TYPE_PREFERRED;
> intel_panel_init(&intel_connector->panel, fixed_mode, NULL);
>
> - return true;
> + return;
>
> err:
> drm_encoder_cleanup(&intel_encoder->base);
> kfree(intel_dsi);
> kfree(intel_connector);
>
> - return false;
> + return;
Okay this went in already, but I find return statements at the end of
void functions like that a bit silly...
...but hey, you can send a fix removing that! ;)
BR,
Jani.
> }
> --
> 1.8.3.1
>
> ___
> 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
[Intel-gfx] hsw edp regression (was: Re: World's worst bug report :)
Kenneth, please file a bug report on DRM/Intel at [1], with the below
information, and attach dmesg from boot with drm.debug=0xe module
parameter set.
Please find a further question below inline.
[1] https://bugs.freedesktop.org/enter_bug.cgi?product=DRI
On Wed, 28 May 2014, "Kenneth R. Crudup" wrote:
> I tend to run the tip of Linus' master branch, and that's been working
> well. After merging in "master" about 3 weeks ago though, I'd often come
> back to a hard-hung laptop after being gone for 15-20 mins or so, i.e.,
> after the (blank-screen) screensaver had kicked in, but only when I'm
> at the office and I had a higher-res monitor (2560x1440) plugged in.
>
> I started going thru the i915 commit logs and after ruling out stuff
> that doesn't appear to apply to my laptop, I'd reverted:
>
> eeb6324d ("drm/i915: consider the source max DP lane count too")
> and
> 56071a20 ("drm/i915: use lane count and link rate from VBT as minimums for
> eDP")
>
> ... and when I'd come in this morning, my laptop was still up and came
> up from the screen saver (it stays on when I'm away from it and not
> suspended). Due to the sporadic nature of the hangs (not always
> reproducible) and time constraints on my part, I haven't narrowed down
> which commit seems to have broken things, but I hope this does help
> you guys to perhaps have an "A-ha!" moment.
>
> My laptop's a Toshiba Satellite P75-A7200 with a Haswell CPU and fairly
> standard i915 graphics:
>
>
> processor : 0
> vendor_id : GenuineIntel
> cpu family : 6
> model : 60
> model name : Intel(R) Core(TM) i7-4700MQ CPU @ 2.40GHz
> stepping: 3
> microcode : 0x16
> cpu MHz : 886.500
> cache size : 6144 KB
> physical id : 0
> siblings: 8
> core id : 0
> cpu cores : 4
> apicid : 0
> initial apicid : 0
> fpu : yes
> fpu_exception : yes
> cpuid level : 13
> wp : yes
>
> 00:02.0 0300: 8086:0416 (rev 06) (prog-if 00 [VGA controller])
> Subsystem: 1179:fa72
> Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr-
> Stepping- SERR- FastB2B- DisINTx+
> Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort-
> SERR- Latency: 0
> Interrupt: pin A routed to IRQ 40
> Region 0: Memory at b200 (64-bit, non-prefetchable) [size=4M]
> Region 2: Memory at a000 (64-bit, prefetchable) [size=256M]
> Region 4: I/O ports at 5000 [size=64]
> Expansion ROM at [disabled]
> Capabilities: [90] MSI: Enable+ Count=1/1 Maskable- 64bit-
> Address: feeff00c Data: 4181
> Capabilities: [d0] Power Management version 2
> Flags: PMEClk- DSI+ D1- D2- AuxCurrent=0mA
> PME(D0-,D1-,D2-,D3hot-,D3cold-)
> Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME-
> Capabilities: [a4] PCI Advanced Features
> AFCap: TP+ FLR+
> AFCtrl: FLR-
> AFStatus: TP-
> Kernel driver in use: i915
>
> eDP1 connected primary 1920x1080+0+360 (normal left inverted right x axis y
> axis) 381mm x 214mm
>1920x1080 60.5*+ 59.9 40.3
>
> HDMI1 connected 2560x1440+1920+0 (normal left inverted right x axis y axis)
> 597mm x 336mm
> ...
> 2560x1440_40 40.0*
>
>
> If you need any other information from me, please don't hesitate to ask.
>
> Thanks,
>
> -Kenny
>
> --
> Kenneth R. Crudup Sr. SW Engineer, Scott County Consulting, Los Angeles
On Thu, 29 May 2014, "Kenneth R. Crudup" wrote:
> On Wed, 28 May 2014, Kenneth R. Crudup wrote:
>
>> [I'd get] back to a hard-hung laptop after being gone for 15-20 mins
>> ... after the (blank-screen) screensaver had kicked in, but only when I'm
>> at the office and I had a higher-res monitor (2560x1440) plugged in.
> ...
>> 56071a20 ("drm/i915: use lane count and link rate from VBT as minimums for
>> eDP")
>
> It's apparently this commit; reverting it (which also pulls f4cdbc214
> ("drm/i915/dp: force eDP lane count to max available lanes on BDW") as
> a side-effect, which doesn't matter on my non-Broadwell machine anyway)
> seems to have stopped the panic-after-screen-off issue for me.
You refer both to a hard hang and a panic, which one is it? What
happens? Do you get a backtrace? Does the machine stop responding to
ping? Can you ssh in and get dmesg?
BR,
Jani.
>
> HTH someone,
>
> -Kenny
>
> --
> Kenneth R. Crudup Sr. SW Engineer, Scott County Consulting, Los Angeles
--
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] drm/i915: Make intel_dsi_init() return void
On Tue, Jun 03, 2014 at 03:05:14PM +0300, Jani Nikula wrote: > > - return false; > > + return; > > Okay this went in already, but I find return statements at the end of > void functions like that a bit silly... > > ...but hey, you can send a fix removing that! ;) Sigh, will do, thanks for pointed it out. -- Damien ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915: Remove return; at the end of a function returning void
intel_dsi_init() lost its return value in: Damien Lespiau Date: Wed May 28 12:30:56 2014 +0100 drm/i915: Make intel_dsi_init() return void However, I left a return; at the end of the function and, as Jani noticed, it looks silly. Suggested-by: Jani Nikula Signed-off-by: Damien Lespiau --- drivers/gpu/drm/i915/intel_dsi.c | 2 -- 1 file changed, 2 deletions(-) diff --git a/drivers/gpu/drm/i915/intel_dsi.c b/drivers/gpu/drm/i915/intel_dsi.c index 9d789b3..bd89de5 100644 --- a/drivers/gpu/drm/i915/intel_dsi.c +++ b/drivers/gpu/drm/i915/intel_dsi.c @@ -759,6 +759,4 @@ err: drm_encoder_cleanup(&intel_encoder->base); kfree(intel_dsi); kfree(intel_connector); - - return; } -- 1.8.3.1 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Remove return; at the end of a function returning void
On Tue, 03 Jun 2014, Damien Lespiau wrote: > intel_dsi_init() lost its return value in: > > Damien Lespiau > Date: Wed May 28 12:30:56 2014 +0100 > > drm/i915: Make intel_dsi_init() return void > > However, I left a return; at the end of the function and, as Jani noticed, it > looks silly. Thanks. R-b and all that if Daniel needs it. > Suggested-by: Jani Nikula > Signed-off-by: Damien Lespiau > --- > drivers/gpu/drm/i915/intel_dsi.c | 2 -- > 1 file changed, 2 deletions(-) > > diff --git a/drivers/gpu/drm/i915/intel_dsi.c > b/drivers/gpu/drm/i915/intel_dsi.c > index 9d789b3..bd89de5 100644 > --- a/drivers/gpu/drm/i915/intel_dsi.c > +++ b/drivers/gpu/drm/i915/intel_dsi.c > @@ -759,6 +759,4 @@ err: > drm_encoder_cleanup(&intel_encoder->base); > kfree(intel_dsi); > kfree(intel_connector); > - > - return; > } > -- > 1.8.3.1 > -- 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] drm/i915: Remove return; at the end of a function returning void
On Tue, Jun 03, 2014 at 04:35:01PM +0300, Jani Nikula wrote: > On Tue, 03 Jun 2014, Damien Lespiau wrote: > > intel_dsi_init() lost its return value in: > > > > Damien Lespiau > > Date: Wed May 28 12:30:56 2014 +0100 > > > > drm/i915: Make intel_dsi_init() return void > > > > However, I left a return; at the end of the function and, as Jani noticed, > > it > > looks silly. > > Thanks. R-b and all that if Daniel needs it. If it's not too late to rewrite history, please consider squashing it with: drm/i915: Make intel_dsi_init() return void -- Damien ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm: Move plane helpers into drm_kms_helper.ko
The drm core shouldn't depend upon any helpers, and we make sure this doesn't accidentally happen by moving them into the helper-only drm_kms_helper.ko module. Cc: Matt Roper Signed-off-by: Daniel Vetter --- drivers/gpu/drm/Makefile | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile index 48e38ba22783..863db8415c22 100644 --- a/drivers/gpu/drm/Makefile +++ b/drivers/gpu/drm/Makefile @@ -13,8 +13,7 @@ drm-y :=drm_auth.o drm_buffer.o drm_bufs.o drm_cache.o \ drm_crtc.o drm_modes.o drm_edid.o \ drm_info.o drm_debugfs.o drm_encoder_slave.o \ drm_trace_points.o drm_global.o drm_prime.o \ - drm_rect.o drm_vma_manager.o drm_flip_work.o \ - drm_plane_helper.o + drm_rect.o drm_vma_manager.o drm_flip_work.o drm-$(CONFIG_COMPAT) += drm_ioc32.o drm-$(CONFIG_DRM_GEM_CMA_HELPER) += drm_gem_cma_helper.o @@ -23,7 +22,8 @@ drm-$(CONFIG_DRM_PANEL) += drm_panel.o drm-usb-y := drm_usb.o -drm_kms_helper-y := drm_crtc_helper.o drm_dp_helper.o drm_probe_helper.o +drm_kms_helper-y := drm_crtc_helper.o drm_dp_helper.o drm_probe_helper.o \ + drm_plane_helper.o drm_kms_helper-$(CONFIG_DRM_LOAD_EDID_FIRMWARE) += drm_edid_load.o drm_kms_helper-$(CONFIG_DRM_KMS_FB_HELPER) += drm_fb_helper.o drm_kms_helper-$(CONFIG_DRM_KMS_CMA_HELPER) += drm_fb_cma_helper.o -- 2.0.0 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] intel-gpu-tools: re-enable gem_exec_params on Android
From: Tim Gore The missing macro that was preventing the gem_exec_params test from building is now in i915_drm.h, in ABT at least, and this test can now build. So I have removed it from the skip list in Android.mk For Gmin I have added a patch for i915_drm.h to the Wiki Signed-off-by: Tim Gore --- tests/Android.mk | 1 - 1 file changed, 1 deletion(-) diff --git a/tests/Android.mk b/tests/Android.mk index dde2cd2..6e9dc67 100644 --- a/tests/Android.mk +++ b/tests/Android.mk @@ -32,7 +32,6 @@ skip_tests_list += gem_seqno_wrap skip_tests_list += testdisplay# needs glib.h skip_tests_list += pm_rpm skip_tests_list += kms_render # needs glib.h -skip_tests_list += gem_exec_params# needs macro that's missing from external/PRIVATE/drm/include/drmi915_drm.h # set local compilation flags for IGT tests IGT_LOCAL_CFLAGS += -DHAVE_STRUCT_SYSINFO_TOTALRAM -DANDROID -UNDEBUG -- 1.9.2 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] intel-gpu-tools: remove testdisplay.h from kms_render.c
From: Tim Gore kms_render.c included testdisplay.h but did not need it. This was preventing it from building on Android due to the lack of a Glib port. So I have removed this #include and changed Android.mk so that kms_render is built if we have cairo. Signed-off-by: Tim Gore --- tests/Android.mk | 4 ++-- tests/kms_render.c | 1 - 2 files changed, 2 insertions(+), 3 deletions(-) diff --git a/tests/Android.mk b/tests/Android.mk index 6e9dc67..3fd32f5 100644 --- a/tests/Android.mk +++ b/tests/Android.mk @@ -31,7 +31,6 @@ skip_tests_list := skip_tests_list += gem_seqno_wrap skip_tests_list += testdisplay# needs glib.h skip_tests_list += pm_rpm -skip_tests_list += kms_render # needs glib.h # set local compilation flags for IGT tests IGT_LOCAL_CFLAGS += -DHAVE_STRUCT_SYSINFO_TOTALRAM -DANDROID -UNDEBUG @@ -69,7 +68,8 @@ else gem_render_copy \ pm_lpsp \ kms_fence_pin_leak \ -kms_mmio_vs_cs_flip +kms_mmio_vs_cs_flip \ +kms_render IGT_LOCAL_CFLAGS += -DANDROID_HAS_CAIRO=0 endif diff --git a/tests/kms_render.c b/tests/kms_render.c index d9c0a58..6c742e2 100644 --- a/tests/kms_render.c +++ b/tests/kms_render.c @@ -31,7 +31,6 @@ #include #include "drmtest.h" -#include "testdisplay.h" #include "intel_bufmgr.h" #include "intel_batchbuffer.h" #include "intel_io.h" -- 1.9.2 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] configure: Don't link the driver against libX11
78dc0c04745ad4485b994f67833f4a155749f01d added REQUIRED_MODULES to the driver link line for... some reason. That pulled in the libs from the XF86DRI check, which near as I can tell has always been wrong, all of the other extension checks just look for the protocol module and xextproto doesn't define dri1 protocol in any case. Signed-off-by: Adam Jackson --- configure.ac | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/configure.ac b/configure.ac index 353f942..30bed3e 100644 --- a/configure.ac +++ b/configure.ac @@ -330,7 +330,7 @@ fi # Store the list of server defined optional extensions in REQUIRED_MODULES XORG_DRIVER_CHECK_EXT(RANDR, randrproto) XORG_DRIVER_CHECK_EXT(RENDER, renderproto) -XORG_DRIVER_CHECK_EXT(XF86DRI, xextproto x11) +XORG_DRIVER_CHECK_EXT(XF86DRI, xf86driproto) XORG_DRIVER_CHECK_EXT(DPMSExtension, xextproto) # Obtain compiler/linker options for the driver dependencies -- 1.9.0 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Remove return; at the end of a function returning void
On Tue, Jun 03, 2014 at 02:37:27PM +0100, Damien Lespiau wrote: > On Tue, Jun 03, 2014 at 04:35:01PM +0300, Jani Nikula wrote: > > On Tue, 03 Jun 2014, Damien Lespiau wrote: > > > intel_dsi_init() lost its return value in: > > > > > > Damien Lespiau > > > Date: Wed May 28 12:30:56 2014 +0100 > > > > > > drm/i915: Make intel_dsi_init() return void > > > > > > However, I left a return; at the end of the function and, as Jani > > > noticed, it > > > looks silly. > > > > Thanks. R-b and all that if Daniel needs it. > > If it's not too late to rewrite history, please consider squashing it > with: > drm/i915: Make intel_dsi_init() return void History is rectified. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] Breaking suspend/resume by the Pipe A quirk
Hi Daniel, dear intel experts, We've put a crtc restriction on VGA (it needs to be crtc 0) to work around some issues. DVI/LVDS should work on crtc 1. You can set this with the --crtc knob for xrandr. Unfortunately, I cannot. Whenever I put DVI1 (which is connected to the internal screen) on crt1, the internal screen stays blank. Where would I need to modify the sources to test whether I could try the reverse, i.e. drive VGA with crt1? (That's not possibly, as you say). I neither found a way to un-clone the screens, i.e. you can say that xrandr should place VGA1 to the left of DVI1, but xrandr --verbose still claims that VGA1 and DVI1 are clones of each other. The best you get is a blank screen on DVI1, and a high-resolution display on VGA1, but not two independent monitors with differing resolutions. Here is the configuration when booting. It clones the monitors, even though the bios says "internal only". Never mind, this works: (p.s. any news from the watermark-alignment patch? Is this acceptable?) Screen 0: minimum 320 x 200, current 2048 x 1536, maximum 2048 x 2048 VGA1 disconnected 2048x1536+0+0 (0x48) normal (normal left inverted right x axis y axis) 0mm x 0mm panning 2048x1536+0+0 Identifier: 0x41 Timestamp: 463642 Subpixel: unknown Gamma: 1.0:1.0:1.0 Brightness: 1.0 Clones: DVI1 CRTC: 0 CRTCs: 0 Panning:2048x1536+0+0 Tracking: 0x0+0+0 Border: 0/0/0/0 Transform: 1.00 0.00 0.00 0.00 1.00 0.00 0.00 0.00 1.00 filter: DVI1 connected 2048x1536+0+0 (0x48) normal (normal left inverted right x axis y axis) 0mm x 0mm panning 2048x1536+0+0 Identifier: 0x42 Timestamp: 463642 Subpixel: horizontal rgb Gamma: 1.0:1.0:1.0 Brightness: 1.0 Clones: VGA1 CRTC: 0 CRTCs: 0 1 Panning:2048x1536+0+0 Tracking: 0x0+0+0 Border: 0/0/0/0 Transform: 1.00 0.00 0.00 0.00 1.00 0.00 0.00 0.00 1.00 filter: 1024x768 (0x48) 65.0MHz -HSync -VSync *current h: width 1024 start 1048 end 1184 total 1344 skew0 clock 48.4KHz v: height 768 start 771 end 777 total 806 clock 60.0Hz 800x600 (0x4c) 40.0MHz +HSync +VSync h: width 800 start 840 end 968 total 1056 skew0 clock 37.9KHz v: height 600 start 601 end 605 total 628 clock 60.3Hz 800x600 (0x4d) 36.0MHz +HSync +VSync h: width 800 start 824 end 896 total 1024 skew0 clock 35.2KHz v: height 600 start 601 end 603 total 625 clock 56.2Hz 640x480 (0x52) 25.2MHz -HSync -VSync h: width 640 start 656 end 752 total 800 skew0 clock 31.5KHz v: height 480 start 489 end 492 total 525 clock 59.9Hz -- And this is the register dump: DCC: 0x (`7rbFtndu) CHDECMISC: 0x (none, ch2 enh disabled, ch1 enh disabled, ch0 enh disabled, flex disabled, ep not present) C0DRB0: 0x (0x) C0DRB1: 0x (0x) C0DRB2: 0x (0x) C0DRB3: 0x (0x) C1DRB0: 0x (0x) C1DRB1: 0x (0x) C1DRB2: 0x (0x) C1DRB3: 0x (0x) C0DRA01: 0x (0x) C0DRA23: 0x (0x) C1DRA01: 0x (0x) C1DRA23: 0x (0x) PGETBL_CTL: 0x3ff60001 VCLK_DIVISOR_VGA0: 0x00021207 (n = 2, m1 = 18, m2 = 7) VCLK_DIVISOR_VGA1: 0x00031406 (n = 3, m1 = 20, m2 = 6) VCLK_POST_DIV: 0x888b (vga0 p1 = 13, p2 = 4, vga1 p1 = 10, p2 = 4) DPLL_TEST: 0x (, DPLLA input buffer disabled, DPLLB input buffer disabled) CACHE_MODE_0: 0x D_STATE: 0x DSPCLK_GATE_D: 0x0008 (clock gates disabled: OVRUNIT) RENCLK_GATE_D1: 0x RENCLK_GATE_D2: 0x SDVOB: 0x80004084 (enabled, pipe A, stall disabled, detected) SDVOC: 0x90004084 (enabled, pipe A, stall disabled, detected) SDVOUDI: 0x DSPARB: 0x00017e5f DSPFW1: 0x DSPFW2: 0x DSPFW3: 0x ADPA: 0x8000 (enabled, pipe A, -hsync, -vsync) LVDS: 0x (disabled, pipe A, 18 bit, 1 channel) DVOA: 0x (disabled, pipe A, no stall, -hsync, -vsync) DVOB: 0x80004084 (enabled, pipe A, no stall, -hsync, -vsync) DVOC: 0x90004084 (enabled, pipe A, stall, -hsync, -vsync) DVOA_SRCDIM: 0x DVOB_SRCDIM: 0x DVOC_SRCDIM:
Re: [Intel-gfx] [PATCH] drm: Move plane helpers into drm_kms_helper.ko
On Tue, Jun 03, 2014 at 03:38:56PM +0200, Daniel Vetter wrote: > The drm core shouldn't depend upon any helpers, and we make sure this > doesn't accidentally happen by moving them into the helper-only > drm_kms_helper.ko module. > > Cc: Matt Roper > Signed-off-by: Daniel Vetter Are there any KMS drivers that don't 'select DRM_KMS_HELPER' in their Kconfig today? From a quick grep + cscope it looks like radeon and vmwgfx don't select the helper library. Since drm_crtc_init() is part of the helper library now (since it creates a helper-created primary plane), I think those drivers either need to select the helper in their Kconfig to get a proper build, or they need to be updated to provide their own primary planes and call drm_crtc_init_with_planes(), right? Matt > --- > drivers/gpu/drm/Makefile | 6 +++--- > 1 file changed, 3 insertions(+), 3 deletions(-) > > diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile > index 48e38ba22783..863db8415c22 100644 > --- a/drivers/gpu/drm/Makefile > +++ b/drivers/gpu/drm/Makefile > @@ -13,8 +13,7 @@ drm-y := drm_auth.o drm_buffer.o drm_bufs.o > drm_cache.o \ > drm_crtc.o drm_modes.o drm_edid.o \ > drm_info.o drm_debugfs.o drm_encoder_slave.o \ > drm_trace_points.o drm_global.o drm_prime.o \ > - drm_rect.o drm_vma_manager.o drm_flip_work.o \ > - drm_plane_helper.o > + drm_rect.o drm_vma_manager.o drm_flip_work.o > > drm-$(CONFIG_COMPAT) += drm_ioc32.o > drm-$(CONFIG_DRM_GEM_CMA_HELPER) += drm_gem_cma_helper.o > @@ -23,7 +22,8 @@ drm-$(CONFIG_DRM_PANEL) += drm_panel.o > > drm-usb-y := drm_usb.o > > -drm_kms_helper-y := drm_crtc_helper.o drm_dp_helper.o drm_probe_helper.o > +drm_kms_helper-y := drm_crtc_helper.o drm_dp_helper.o drm_probe_helper.o \ > + drm_plane_helper.o > drm_kms_helper-$(CONFIG_DRM_LOAD_EDID_FIRMWARE) += drm_edid_load.o > drm_kms_helper-$(CONFIG_DRM_KMS_FB_HELPER) += drm_fb_helper.o > drm_kms_helper-$(CONFIG_DRM_KMS_CMA_HELPER) += drm_fb_cma_helper.o > -- > 2.0.0 > -- Matt Roper Graphics Software Engineer IoTG Platform Enabling & Development Intel Corporation (916) 356-2795 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] Breaking suspend/resume by the Pipe A quirk
On Tue, Jun 03, 2014 at 04:38:40PM +0200, Thomas Richter wrote: > Hi Daniel, dear intel experts, > > >We've put a crtc restriction on VGA (it needs to be crtc 0) to work around > >some issues. DVI/LVDS should work on crtc 1. You can set this with the > >--crtc knob for xrandr. > > > Unfortunately, I cannot. Whenever I put DVI1 (which is connected to the > internal screen) on crt1, > the internal screen stays blank. Where would I need to modify the sources to > test whether I could try > the reverse, i.e. drive VGA with crt1? (That's not possibly, as you say). diff --git a/drivers/gpu/drm/i915/intel_crt.c b/drivers/gpu/drm/i915/intel_crt.c index 22d8347f7838..80e3f1fc1ad6 100644 --- a/drivers/gpu/drm/i915/intel_crt.c +++ b/drivers/gpu/drm/i915/intel_crt.c @@ -833,10 +833,7 @@ void intel_crt_init(struct drm_device *dev) crt->base.type = INTEL_OUTPUT_ANALOG; crt->base.cloneable = (1 << INTEL_OUTPUT_DVO) | (1 << INTEL_OUTPUT_HDMI); - if (IS_I830(dev)) - crt->base.crtc_mask = (1 << 0); - else - crt->base.crtc_mask = (1 << 0) | (1 << 1) | (1 << 2); + crt->base.crtc_mask = (1 << 0) | (1 << 1) | (1 << 2); if (IS_GEN2(dev)) connector->interlace_allowed = 0; > I neither found a way to un-clone the screens, i.e. you can say that xrandr > should place VGA1 to the left > of DVI1, but xrandr --verbose still claims that VGA1 and DVI1 are clones of > each other. The best you get is > a blank screen on DVI1, and a high-resolution display on VGA1, but not two > independent monitors with > differing resolutions. Yeah, if you can't move the panel to the crtc 1 only cloning will be possible. > Here is the configuration when booting. It clones the monitors, even though > the bios says "internal only". Never mind, > this works: Yeah, both connectors use CRTC 0. Have you tried what happens if you: - disable DVI1 first (--off) - then enable it on crtc 1? Cheers, Daniel > > (p.s. any news from the watermark-alignment patch? Is this acceptable?) > > Screen 0: minimum 320 x 200, current 2048 x 1536, maximum 2048 x 2048 > VGA1 disconnected 2048x1536+0+0 (0x48) normal (normal left inverted right x > axis y axis) 0mm x 0mm panning 2048x1536+0+0 > Identifier: 0x41 > Timestamp: 463642 > Subpixel: unknown > Gamma: 1.0:1.0:1.0 > Brightness: 1.0 > Clones: DVI1 > CRTC: 0 > CRTCs: 0 > Panning:2048x1536+0+0 > Tracking: 0x0+0+0 > Border: 0/0/0/0 > Transform: 1.00 0.00 0.00 > 0.00 1.00 0.00 > 0.00 0.00 1.00 >filter: > DVI1 connected 2048x1536+0+0 (0x48) normal (normal left inverted right x > axis y axis) 0mm x 0mm panning 2048x1536+0+0 > Identifier: 0x42 > Timestamp: 463642 > Subpixel: horizontal rgb > Gamma: 1.0:1.0:1.0 > Brightness: 1.0 > Clones: VGA1 > CRTC: 0 > CRTCs: 0 1 > Panning:2048x1536+0+0 > Tracking: 0x0+0+0 > Border: 0/0/0/0 > Transform: 1.00 0.00 0.00 > 0.00 1.00 0.00 > 0.00 0.00 1.00 >filter: > 1024x768 (0x48) 65.0MHz -HSync -VSync *current > h: width 1024 start 1048 end 1184 total 1344 skew0 clock > 48.4KHz > v: height 768 start 771 end 777 total 806 clock > 60.0Hz > 800x600 (0x4c) 40.0MHz +HSync +VSync > h: width 800 start 840 end 968 total 1056 skew0 clock > 37.9KHz > v: height 600 start 601 end 605 total 628 clock > 60.3Hz > 800x600 (0x4d) 36.0MHz +HSync +VSync > h: width 800 start 824 end 896 total 1024 skew0 clock > 35.2KHz > v: height 600 start 601 end 603 total 625 clock > 56.2Hz > 640x480 (0x52) 25.2MHz -HSync -VSync > h: width 640 start 656 end 752 total 800 skew0 clock > 31.5KHz > v: height 480 start 489 end 492 total 525 clock > 59.9Hz > > -- > > And this is the register dump: > > DCC: 0x (`7rbFtndu) >CHDECMISC: 0x (none, ch2 enh disabled, ch1 enh disabled, > ch0 enh disabled, flex disabled, ep not present) > C0DRB0: 0x (0x) > C0DRB1: 0x (0x) > C0DRB2: 0x (0x) > C0DRB3: 0x (0x) > C1DRB0: 0x (0x) > C1DRB1: 0x (0x) > C1DRB2: 0x (0x) > C1DRB3: 0x (0x) > C0DRA01: 0x (0x) > C0DRA23: 0x (0x) > C1DRA01: 0x (0x) > C1DRA23: 0x (0x) > PGETBL_CTL: 0x3ff60001 >VCLK_DIVISOR_VGA0: 0x00021207 (n = 2, m1 = 18, m2 = 7) >VCLK_DIVISOR_VGA1: 0x00031406 (n = 3, m1 = 20, m2 = 6) >
[Intel-gfx] [PATCH] quick_dump: make autodetect the default option
Signed-off-by: Imre Deak
---
tools/quick_dump/quick_dump.py | 5 +
1 file changed, 1 insertion(+), 4 deletions(-)
diff --git a/tools/quick_dump/quick_dump.py b/tools/quick_dump/quick_dump.py
index 523f675..2eb7724 100755
--- a/tools/quick_dump/quick_dump.py
+++ b/tools/quick_dump/quick_dump.py
@@ -75,9 +75,6 @@ if __name__ == "__main__":
parser.add_argument('-b', '--baseless',
action='store_true', default=False,
help='baseless mode, ignore files starting with base_')
-parser.add_argument('-a', '--autodetect',
-action='store_true', default=False,
-help='autodetect chipset')
parser.add_argument('-f', '--file',
type=argparse.FileType('r'), default=None)
parser.add_argument('profile', nargs='?',
@@ -101,7 +98,7 @@ if __name__ == "__main__":
if args.baseless == False:
walk_base_files()
-if args.autodetect:
+if args.profile == None:
args.profile = autodetect_chipset()
if args.profile == None:
--
1.8.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] intel-gpu-tools: remove testdisplay.h from kms_render.c
On Tue, Jun 03, 2014 at 03:18:31PM +0100, tim.g...@intel.com wrote: > From: Tim Gore > > kms_render.c included testdisplay.h but did not need it. > This was preventing it from building on Android due to the > lack of a Glib port. So I have removed this #include and > changed Android.mk so that kms_render is built if we have > cairo. > > Signed-off-by: Tim Gore Both patches merged, thanks. -Daniel > --- > tests/Android.mk | 4 ++-- > tests/kms_render.c | 1 - > 2 files changed, 2 insertions(+), 3 deletions(-) > > diff --git a/tests/Android.mk b/tests/Android.mk > index 6e9dc67..3fd32f5 100644 > --- a/tests/Android.mk > +++ b/tests/Android.mk > @@ -31,7 +31,6 @@ skip_tests_list := > skip_tests_list += gem_seqno_wrap > skip_tests_list += testdisplay# needs glib.h > skip_tests_list += pm_rpm > -skip_tests_list += kms_render # needs glib.h > > # set local compilation flags for IGT tests > IGT_LOCAL_CFLAGS += -DHAVE_STRUCT_SYSINFO_TOTALRAM -DANDROID -UNDEBUG > @@ -69,7 +68,8 @@ else > gem_render_copy \ > pm_lpsp \ > kms_fence_pin_leak \ > -kms_mmio_vs_cs_flip > +kms_mmio_vs_cs_flip \ > +kms_render > IGT_LOCAL_CFLAGS += -DANDROID_HAS_CAIRO=0 > endif > > diff --git a/tests/kms_render.c b/tests/kms_render.c > index d9c0a58..6c742e2 100644 > --- a/tests/kms_render.c > +++ b/tests/kms_render.c > @@ -31,7 +31,6 @@ > #include > > #include "drmtest.h" > -#include "testdisplay.h" > #include "intel_bufmgr.h" > #include "intel_batchbuffer.h" > #include "intel_io.h" > -- > 1.9.2 > > ___ > Intel-gfx mailing list > Intel-gfx@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/intel-gfx -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - 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: Move plane helpers into drm_kms_helper.ko
On Tue, Jun 3, 2014 at 4:44 PM, Matt Roper wrote: > On Tue, Jun 03, 2014 at 03:38:56PM +0200, Daniel Vetter wrote: >> The drm core shouldn't depend upon any helpers, and we make sure this >> doesn't accidentally happen by moving them into the helper-only >> drm_kms_helper.ko module. >> >> Cc: Matt Roper >> Signed-off-by: Daniel Vetter > > Are there any KMS drivers that don't 'select DRM_KMS_HELPER' in their > Kconfig today? From a quick grep + cscope it looks like radeon and > vmwgfx don't select the helper library. > > Since drm_crtc_init() is part of the helper library now (since it > creates a helper-created primary plane), I think those drivers either > need to select the helper in their Kconfig to get a proper build, or > they need to be updated to provide their own primary planes and call > drm_crtc_init_with_planes(), right? Radeon definitely uses the crtc helpers, so should have the dependency somewhere. vmwgfx might indeed be broken now a bit. I'll wait for the 0-day kernel test build farm to confirm that ;-) -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - 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] configure: Don't link the driver against libX11
On Tue, Jun 03, 2014 at 10:26:46AM -0400, Adam Jackson wrote: > 78dc0c04745ad4485b994f67833f4a155749f01d added REQUIRED_MODULES to the > driver link line for... some reason. That pulled in the libs from the > XF86DRI check, which near as I can tell has always been wrong, all of > the other extension checks just look for the protocol module and > xextproto doesn't define dri1 protocol in any case. > > Signed-off-by: Adam Jackson Thanks, pushed. I then took it a step further and dropped xf86driproto from our `pkg-config $REQUIRED_MODULES` check and made it only required for DRI support with i810. -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] drm: Move plane helpers into drm_kms_helper.ko
On Tue, Jun 03, 2014 at 04:49:25PM +0200, Daniel Vetter wrote: > On Tue, Jun 3, 2014 at 4:44 PM, Matt Roper wrote: > > On Tue, Jun 03, 2014 at 03:38:56PM +0200, Daniel Vetter wrote: > >> The drm core shouldn't depend upon any helpers, and we make sure this > >> doesn't accidentally happen by moving them into the helper-only > >> drm_kms_helper.ko module. > >> > >> Cc: Matt Roper > >> Signed-off-by: Daniel Vetter > > > > Are there any KMS drivers that don't 'select DRM_KMS_HELPER' in their > > Kconfig today? From a quick grep + cscope it looks like radeon and > > vmwgfx don't select the helper library. > > > > Since drm_crtc_init() is part of the helper library now (since it > > creates a helper-created primary plane), I think those drivers either > > need to select the helper in their Kconfig to get a proper build, or > > they need to be updated to provide their own primary planes and call > > drm_crtc_init_with_planes(), right? > > Radeon definitely uses the crtc helpers, so should have the dependency > somewhere. vmwgfx might indeed be broken now a bit. I'll wait for the > 0-day kernel test build farm to confirm that ;-) > -Daniel Yeah, you're right; now that I look closer radeon pulls it in from the main drm directory Kconfig and only has ums stuff in its driver directory Kconfig. But I think vmwgfx probably still needs to select the helper library. If vmwgfx gets a kconfig update to pull in the helper library, then this is Reviewed-by: Matt Roper Matt > -- > Daniel Vetter > Software Engineer, Intel Corporation > +41 (0) 79 365 57 48 - http://blog.ffwll.ch -- Matt Roper Graphics Software Engineer IoTG Platform Enabling & Development Intel Corporation (916) 356-2795 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm: Move plane helpers into drm_kms_helper.ko
The drm core shouldn't depend upon any helpers, and we make sure this doesn't accidentally happen by moving them into the helper-only drm_kms_helper.ko module. v2: Don't break the build for vmwgfx, spotted by Matt. Cc: Matt Roper Cc: Thomas Hellstrom Signed-off-by: Daniel Vetter --- drivers/gpu/drm/Makefile | 6 +++--- drivers/gpu/drm/vmwgfx/Kconfig | 3 +++ 2 files changed, 6 insertions(+), 3 deletions(-) diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile index 48e38ba22783..863db8415c22 100644 --- a/drivers/gpu/drm/Makefile +++ b/drivers/gpu/drm/Makefile @@ -13,8 +13,7 @@ drm-y :=drm_auth.o drm_buffer.o drm_bufs.o drm_cache.o \ drm_crtc.o drm_modes.o drm_edid.o \ drm_info.o drm_debugfs.o drm_encoder_slave.o \ drm_trace_points.o drm_global.o drm_prime.o \ - drm_rect.o drm_vma_manager.o drm_flip_work.o \ - drm_plane_helper.o + drm_rect.o drm_vma_manager.o drm_flip_work.o drm-$(CONFIG_COMPAT) += drm_ioc32.o drm-$(CONFIG_DRM_GEM_CMA_HELPER) += drm_gem_cma_helper.o @@ -23,7 +22,8 @@ drm-$(CONFIG_DRM_PANEL) += drm_panel.o drm-usb-y := drm_usb.o -drm_kms_helper-y := drm_crtc_helper.o drm_dp_helper.o drm_probe_helper.o +drm_kms_helper-y := drm_crtc_helper.o drm_dp_helper.o drm_probe_helper.o \ + drm_plane_helper.o drm_kms_helper-$(CONFIG_DRM_LOAD_EDID_FIRMWARE) += drm_edid_load.o drm_kms_helper-$(CONFIG_DRM_KMS_FB_HELPER) += drm_fb_helper.o drm_kms_helper-$(CONFIG_DRM_KMS_CMA_HELPER) += drm_fb_cma_helper.o diff --git a/drivers/gpu/drm/vmwgfx/Kconfig b/drivers/gpu/drm/vmwgfx/Kconfig index b71bcd0bfbbf..653800e7bc7a 100644 --- a/drivers/gpu/drm/vmwgfx/Kconfig +++ b/drivers/gpu/drm/vmwgfx/Kconfig @@ -6,6 +6,9 @@ config DRM_VMWGFX select FB_CFB_COPYAREA select FB_CFB_IMAGEBLIT select DRM_TTM + # Only needed for the transitional use of drm_crtc_init - can be removed + # again once vmwgfx sets up the primary plane itself. + select DRM_KMS_HELPER help Choose this option if you would like to run 3D acceleration in a VMware virtual machine. -- 2.0.0 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] Breaking suspend/resume by the Pipe A quirk
Am 03.06.2014 16:45, schrieb Daniel Vetter: Yeah, both connectors use CRTC 0. Have you tried what happens if you: - disable DVI1 first (--off) - then enable it on crtc 1? Same difference, internal screen goes blank with --off, and stays blank after moving it to crtc 1 if I try to re-enable it with --auto or --mode. I'll try the above patch and then report again my findings, thanks! Greetings, Thomas ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] quick_dump: make autodetect the default option
On Tue, Jun 03, 2014 at 05:46:40PM +0300, Imre Deak wrote:
> Signed-off-by: Imre Deak
Very-much-wanted-by: Daniel Vetter
> ---
> tools/quick_dump/quick_dump.py | 5 +
> 1 file changed, 1 insertion(+), 4 deletions(-)
>
> diff --git a/tools/quick_dump/quick_dump.py b/tools/quick_dump/quick_dump.py
> index 523f675..2eb7724 100755
> --- a/tools/quick_dump/quick_dump.py
> +++ b/tools/quick_dump/quick_dump.py
> @@ -75,9 +75,6 @@ if __name__ == "__main__":
> parser.add_argument('-b', '--baseless',
> action='store_true', default=False,
> help='baseless mode, ignore files starting with base_')
> -parser.add_argument('-a', '--autodetect',
> -action='store_true', default=False,
> -help='autodetect chipset')
> parser.add_argument('-f', '--file',
> type=argparse.FileType('r'), default=None)
> parser.add_argument('profile', nargs='?',
> @@ -101,7 +98,7 @@ if __name__ == "__main__":
> if args.baseless == False:
> walk_base_files()
>
> -if args.autodetect:
> +if args.profile == None:
> args.profile = autodetect_chipset()
>
> if args.profile == None:
> --
> 1.8.4
>
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] Fwd: __i915_gem_shrink / mm_find_pmd hogging CPU, then out of memory
On Mon, Jun 02, 2014 at 02:18:14PM +0100, Sam Jansen wrote: >Hello intel-gfx, >I'm working on an application using VA-API for H264 encode+decode, and >JPEG decode on an Atom E3815. Unfortunately we've hit what I believe is a >kernel bug, and the "perf top" output is pointing at i915 DRM code. >After some amount of time running my application, the system will become >unresponsive (userspace applications get very little CPU, system CPU will >go up to 80+%), and sometimes the system will appear out of memory for a >period (the OOM killer is sometimes invoked), even though there is a lot >of free memory on the system. I noticed this first on kernel 3.14.5, so I >moved to "drm-intel-nightly", built on Friday (2014-05-30), from >[1]http://cgit.freedesktop.org/drm-intel. The results are the same. >Using "perf top", I have gathered the following traces showing high system >CPU at the time when the system was encountering this problem: It's a buffer leak in the userspace va-api application. The buffers appear as cached memory, they are not yet accounted against the applications that have a reference to them. Look at /sys/kernel/debug/dri/0/i915_gem_objects for a breakdown of users. -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] Breaking suspend/resume by the Pipe A quirk
On Tue, Jun 03, 2014 at 05:04:52PM +0200, Thomas Richter wrote: > Am 03.06.2014 16:45, schrieb Daniel Vetter: > > > > >Yeah, both connectors use CRTC 0. Have you tried what happens if you: > >- disable DVI1 first (--off) > >- then enable it on crtc 1? > > Same difference, internal screen goes blank with --off, and stays > blank after moving it to crtc 1 if I try to re-enable it with --auto > or --mode. The oddity in the config is that the LVDS is reported as disconnected. That should not be happening unless there is some sharing going on inside the DVO chip. -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] Breaking suspend/resume by the Pipe A quirk
Am 03.06.2014 17:14, schrieb Chris Wilson: On Tue, Jun 03, 2014 at 05:04:52PM +0200, Thomas Richter wrote: Am 03.06.2014 16:45, schrieb Daniel Vetter: Yeah, both connectors use CRTC 0. Have you tried what happens if you: - disable DVI1 first (--off) - then enable it on crtc 1? Same difference, internal screen goes blank with --off, and stays blank after moving it to crtc 1 if I try to re-enable it with --auto or --mode. The oddity in the config is that the LVDS is reported as disconnected. That should not be happening unless there is some sharing going on inside the DVO chip. Please note that on this specific notebook, the internal screen is connected via DVI, not via LVDS. I don't know what they did with the LVDS output, it's probably - as said - just disconnected. The R31 has its panel connected via LVDS, and here I can set resolutions independently just fine. Currently compiling the patch, takes a while on a 1GHhz/1GB P-3 machine. (-; Greetings, Thomas ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] quick_dump: make autodetect the default option
On Tue, 03 Jun 2014, Daniel Vetter wrote:
> On Tue, Jun 03, 2014 at 05:46:40PM +0300, Imre Deak wrote:
>> Signed-off-by: Imre Deak
>
> Very-much-wanted-by: Daniel Vetter
AOL'd-by: Jani Nikula
>> ---
>> tools/quick_dump/quick_dump.py | 5 +
>> 1 file changed, 1 insertion(+), 4 deletions(-)
>>
>> diff --git a/tools/quick_dump/quick_dump.py b/tools/quick_dump/quick_dump.py
>> index 523f675..2eb7724 100755
>> --- a/tools/quick_dump/quick_dump.py
>> +++ b/tools/quick_dump/quick_dump.py
>> @@ -75,9 +75,6 @@ if __name__ == "__main__":
>> parser.add_argument('-b', '--baseless',
>> action='store_true', default=False,
>> help='baseless mode, ignore files starting with base_')
>> -parser.add_argument('-a', '--autodetect',
>> -action='store_true', default=False,
>> -help='autodetect chipset')
>> parser.add_argument('-f', '--file',
>> type=argparse.FileType('r'), default=None)
>> parser.add_argument('profile', nargs='?',
>> @@ -101,7 +98,7 @@ if __name__ == "__main__":
>> if args.baseless == False:
>> walk_base_files()
>>
>> -if args.autodetect:
>> +if args.profile == None:
>> args.profile = autodetect_chipset()
>>
>> if args.profile == None:
>> --
>> 1.8.4
>>
>> ___
>> Intel-gfx mailing list
>> Intel-gfx@lists.freedesktop.org
>> http://lists.freedesktop.org/mailman/listinfo/intel-gfx
>
> --
> Daniel Vetter
> Software Engineer, Intel Corporation
> +41 (0) 79 365 57 48 - http://blog.ffwll.ch
> ___
> 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] Breaking suspend/resume by the Pipe A quirk
On Tue, Jun 03, 2014 at 05:19:26PM +0200, Thomas Richter wrote: > Am 03.06.2014 17:14, schrieb Chris Wilson: > >On Tue, Jun 03, 2014 at 05:04:52PM +0200, Thomas Richter wrote: > >>Am 03.06.2014 16:45, schrieb Daniel Vetter: > >> > >>> > >>>Yeah, both connectors use CRTC 0. Have you tried what happens if you: > >>>- disable DVI1 first (--off) > >>>- then enable it on crtc 1? > >> > >>Same difference, internal screen goes blank with --off, and stays > >>blank after moving it to crtc 1 if I try to re-enable it with --auto > >>or --mode. > > > >The oddity in the config is that the LVDS is reported as disconnected. > >That should not be happening unless there is some sharing going on > >inside the DVO chip. > > Please note that on this specific notebook, the internal screen is > connected via DVI, not via LVDS. I don't know what they did with the > LVDS output, it's probably - as said - just disconnected. I should have said VGA. Thinking about it, it is likely a shared DDC line so that only a single EDID can be read. -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] Breaking suspend/resume by the Pipe A quirk
Am 03.06.2014 17:26, schrieb Chris Wilson: I should have said VGA. Thinking about it, it is likely a shared DDC line so that only a single EDID can be read. Actually, it gets the EDID from the VGA panel just fine, also shows me the modes it supports. DVI1 has no edit, though it gets its allowable modes from the dvo_ds2501 module. I now tried to relocate VGA1 to crtc 1, with Daniel's patch. Results are even weirder. I can *set* the resolution to 1280x1024 on VGA1, just that it does not deliver this resolution. My monitor claims (and my vision confirms) that this is still the same 1024x768 mode as on the internal panel. I can again turn VGA off, relocate it to crtc 1, turn it on again, still says its a clone of DVI1 even though it's on a different crtc. Chipset (lspci) says its a 82830M/MG graphics controller, PCI id 8086:3577. This *should* be a true 830MG (specs agree), thus I *believe* it should have two display pipes. The R31 is built around the very same chipset and has no problems with independent output. Looks like they shared the VGA and DVI output,and left the other output just dangling. Weird. Screen 0: minimum 320 x 200, current 1280 x 1024, maximum 2048 x 2048 VGA1 connected 1280x1024+0+0 (0xa7) normal (normal left inverted right x axis y axis) 338mm x 270mm Identifier: 0x41 Timestamp: 504191 Subpixel: unknown Gamma: 1.0:1.0:1.0 Brightness: 1.0 Clones: DVI1 CRTC: 1 CRTCs: 0 1 Transform: 1.00 0.00 0.00 0.00 1.00 0.00 0.00 0.00 1.00 filter: EDID: 00004c2d1d0037314847 1a0c01030f221b8cea6f8ba25a4d9424 1a5156bfef8081806140454031400101 010101010101302a009851002a403070 1300520e111e00fd0038551e 510e000a20202020202000fc0053 796e634d61737465720a202000ff 0048344c543630343930380a20200054 1280x1024 (0xa7) 108.0MHz +HSync +VSync *current +preferred h: width 1280 start 1328 end 1440 total 1688 skew0 clock 64.0KHz v: height 1024 start 1025 end 1028 total 1066 clock 60.0Hz 1280x1024 (0xa8) 135.0MHz +HSync +VSync h: width 1280 start 1296 end 1440 total 1688 skew0 clock 80.0KHz v: height 1024 start 1025 end 1028 total 1066 clock 75.0Hz 1152x864 (0xa9) 108.0MHz +HSync +VSync h: width 1152 start 1216 end 1344 total 1600 skew0 clock 67.5KHz v: height 864 start 865 end 868 total 900 clock 75.0Hz 1024x768 (0xaa) 78.8MHz +HSync +VSync h: width 1024 start 1040 end 1136 total 1312 skew0 clock 60.1KHz v: height 768 start 769 end 772 total 800 clock 75.1Hz 1024x768 (0xab) 75.0MHz -HSync -VSync h: width 1024 start 1048 end 1184 total 1328 skew0 clock 56.5KHz v: height 768 start 771 end 777 total 806 clock 70.1Hz 1024x768 (0x43) 65.0MHz -HSync -VSync h: width 1024 start 1048 end 1184 total 1344 skew0 clock 48.4KHz v: height 768 start 771 end 777 total 806 clock 60.0Hz 832x624 (0xac) 57.3MHz -HSync -VSync h: width 832 start 864 end 928 total 1152 skew0 clock 49.7KHz v: height 624 start 625 end 628 total 667 clock 74.6Hz 800x600 (0xad) 50.0MHz +HSync +VSync h: width 800 start 856 end 976 total 1040 skew0 clock 48.1KHz v: height 600 start 637 end 643 total 666 clock 72.2Hz 800x600 (0xae) 49.5MHz +HSync +VSync h: width 800 start 816 end 896 total 1056 skew0 clock 46.9KHz v: height 600 start 601 end 604 total 625 clock 75.0Hz 800x600 (0x44) 40.0MHz +HSync +VSync h: width 800 start 840 end 968 total 1056 skew0 clock 37.9KHz v: height 600 start 601 end 605 total 628 clock 60.3Hz 800x600 (0x45) 36.0MHz +HSync +VSync h: width 800 start 824 end 896 total 1024 skew0 clock 35.2KHz v: height 600 start 601 end 603 total 625 clock 56.2Hz 640x480 (0xaf) 31.5MHz -HSync -VSync h: width 640 start 656 end 720 total 840 skew0 clock 37.5KHz v: height 480 start 481 end 484 total 500 clock 75.0Hz 640x480 (0xb0) 31.5MHz -HSync -VSync h: width 640 start 664 end 704 total 832 skew0 clock 37.9KHz v: height 480 start 489 end 491 total 520 clock 72.8Hz 640x480 (0xb1) 30.2MHz -HSync -VSync h: width 640 start 704 end 768 total 864 skew0 clock 35.0KHz v: height 480 start 483 end 486 total 525 clock 66.7Hz 640x480 (0xb2) 25.2MHz -HSync -VSync h: width
Re: [Intel-gfx] Breaking suspend/resume by the Pipe A quirk
On Tue, Jun 03, 2014 at 05:50:06PM +0200, Thomas Richter wrote: > Am 03.06.2014 17:26, schrieb Chris Wilson: > > > > >I should have said VGA. Thinking about it, it is likely a shared DDC line > >so that only a single EDID can be read. > > Actually, it gets the EDID from the VGA panel just fine, also shows > me the modes it supports. DVI1 has no edit, though it gets its > allowable modes from the dvo_ds2501 module. > > I now tried to relocate VGA1 to crtc 1, with Daniel's patch. Results > are even weirder. I can *set* the resolution to 1280x1024 on VGA1, > just that it does not deliver this resolution. My monitor claims > (and my vision confirms) that this is still the same 1024x768 mode > as on the internal panel. > > I can again turn VGA off, relocate it to crtc 1, turn it on again, > still says its a clone of DVI1 even though it's on a different crtc. > > Chipset (lspci) says its a 82830M/MG graphics controller, PCI id > 8086:3577. This *should* be a true 830MG (specs agree), thus I > *believe* it should have two display pipes. The R31 is built around > the very same chipset and has no problems with independent output. > Looks like they shared the VGA and DVI output,and left the other > output just dangling. Weird. > > Screen 0: minimum 320 x 200, current 1280 x 1024, maximum 2048 x 2048 > VGA1 connected 1280x1024+0+0 (0xa7) normal (normal left inverted > right x axis y axis) 338mm x 270mm > Identifier: 0x41 > Timestamp: 504191 > Subpixel: unknown > Gamma: 1.0:1.0:1.0 > Brightness: 1.0 > Clones: DVI1 ^ This is short for "Allowed Clones:", not "Active Clones:". > 1280x1024 (0xa7) 108.0MHz +HSync +VSync *current +preferred > h: width 1280 start 1328 end 1440 total 1688 skew0 > clock 64.0KHz > v: height 1024 start 1025 end 1028 total 1066 > clock 60.0Hz > DSPBCNTR: 0x9900 (enabled, pipe B) > DSPBSTRIDE: 0x2000 (8192 bytes) > DSPBPOS: 0x (0, 0) > DSPBSIZE: 0x0257031f (800, 600) > DSPBBASE: 0x04001000 > DSPBSURF: 0x > DSPBTILEOFF: 0x >PIPEBCONF: 0x8000 (enabled, single-wide) > PIPEBSRC: 0x031f0257 (800, 600) >PIPEBSTAT: 0x1206 (status: CRC_DONE_ENABLE > HTOTAL_B: 0x041f031f (800 active, 1056 total) > HBLANK_B: 0x041f031f (800 start, 1056 end) > HSYNC_B: 0x03c70347 (840 start, 968 end) > VTOTAL_B: 0x02730257 (600 active, 628 total) > VBLANK_B: 0x02730257 (600 start, 628 end) > VSYNC_B: 0x025c0258 (601 start, 605 end) It's even worse than you thought. Somewhere between userspace passing in the mode, and the kernel setting it, it got lost. > CRTC: 1 > CRTCs: 0 1 > Transform: 1.00 0.00 0.00 > 0.00 1.00 0.00 > 0.00 0.00 1.00 > filter: > 1280x1024 (0xa7) 108.0MHz +HSync +VSync *current +preferred > h: width 1280 start 1328 end 1440 total 1688 skew0 > clock 64.0KHz > v: height 1024 start 1025 end 1028 total 1066 > DVI1 connected 1280x1024+0+0 (0x43) normal (normal left inverted ^ This means you have configured the two outputs in a mirrored mode, both reading from the same portion of the framebuffer. So it just looks like a cloned setup, with upset displays. > right x axis y axis) 0mm x 0mm panning 1280x1024+0+0 > Identifier: 0x42 > Timestamp: 504191 > Subpixel: horizontal rgb > Gamma: 1.0:1.0:1.0 > Brightness: 1.0 > Clones: VGA1 > CRTC: 0 > CRTCs: 0 1 > Panning:1280x1024+0+0 > Tracking: 0x0+0+0 > Border: 0/0/0/0 > Transform: 1.00 0.00 0.00 > 0.00 1.00 0.00 > 0.00 0.00 1.00 > filter: > 1024x768 (0x43) 65.0MHz -HSync -VSync *current > h: width 1024 start 1048 end 1184 total 1344 skew0 > clock 48.4KHz > v: height 768 start 771 end 777 total 806 >PIPEASTAT: 0x1207 (status: CRC_DONE_ENABLE > DSPACNTR: 0x9800 (enabled, pipe A) > DSPASTRIDE: 0x2000 (8192 bytes) > DSPAPOS: 0x (0, 0) > DSPASIZE: 0x02ff03ff (1024, 768) > DSPABASE: 0x0400 > DSPASURF: 0x > DSPATILEOFF: 0x >PIPEACONF: 0x8000 (enabled, single-wide) > PIPEASRC: 0x03ff02ff (1024, 768) > HTOTAL_A: 0x051f03ff (1024 active, 1312 total) > HBLANK_A: 0x051f03ff (1024 start, 1312 end) > HSYNC_A: 0x046f040f (1040 start, 1136 end) > VTOTAL_A: 0x031f02ff (768 active, 800 total) > VBLANK_A: 0x031f02ff (768 start, 800 end) >
[Intel-gfx] [PATCH] drm/i915/vlv: T12 eDP panel timing enforcement during reboot.
From: Clint Taylor
The panel power sequencer on vlv doesn't appear to accept changes to its
T12 power down duration during warm reboots. This change forces a delay
for warm reboots to the T12 panel timing as defined in the VBT table for
the connected panel.
Ver2: removed redundant pr_crit(), commented magic value for pp_div_reg
Ver3: moved SYS_RESTART check earlier, new name for pp_div.
Ver4: Minor issue changes
Signed-off-by: Clint Taylor
---
drivers/gpu/drm/i915/intel_dp.c | 42 ++
drivers/gpu/drm/i915/intel_drv.h |2 ++
2 files changed, 44 insertions(+)
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 5ca68aa9..cede9bc 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -28,6 +28,8 @@
#include
#include
#include
+#include
+#include
#include
#include
#include
@@ -302,6 +304,38 @@ static u32 _pp_stat_reg(struct intel_dp *intel_dp)
return VLV_PIPE_PP_STATUS(vlv_power_sequencer_pipe(intel_dp));
}
+/* Reboot notifier handler to shutdown panel power to guarantee T12 timing */
+static int edp_notify_handler(struct notifier_block *this, unsigned long code,
+ void *unused)
+{
+ struct intel_dp *intel_dp = container_of(this, typeof(* intel_dp),
+edp_notifier);
+ struct intel_digital_port *intel_dig_port = dp_to_dig_port(intel_dp);
+ struct drm_device *dev = intel_dig_port->base.base.dev;
+ struct drm_i915_private *dev_priv = dev->dev_private;
+ u32 pp_div;
+ u32 pp_ctrl_reg, pp_div_reg;
+ enum pipe pipe = vlv_power_sequencer_pipe(intel_dp);
+
+ if (!is_edp(intel_dp) || code != SYS_RESTART )
+ return 0;
+
+ if (IS_VALLEYVIEW(dev)) {
+ pp_ctrl_reg = VLV_PIPE_PP_CONTROL(pipe);
+ pp_div_reg = VLV_PIPE_PP_DIVISOR(pipe);
+ pp_div = I915_READ(VLV_PIPE_PP_DIVISOR(pipe));
+ pp_div &= PP_REFERENCE_DIVIDER_MASK;
+
+ /* 0x1F write to PP_DIV_REG sets max cycle delay */
+ I915_WRITE(pp_div_reg, pp_div | 0x1F);
+ I915_WRITE(pp_ctrl_reg,
+ PANEL_UNLOCK_REGS | PANEL_POWER_OFF);
+ msleep(intel_dp->panel_power_cycle_delay);
+ }
+
+ return 0;
+}
+
static bool edp_have_panel_power(struct intel_dp *intel_dp)
{
struct drm_device *dev = intel_dp_to_dev(intel_dp);
@@ -3344,6 +3378,10 @@ void intel_dp_encoder_destroy(struct drm_encoder
*encoder)
mutex_lock(&dev->mode_config.mutex);
edp_panel_vdd_off_sync(intel_dp);
mutex_unlock(&dev->mode_config.mutex);
+ if (intel_dp->edp_notifier.notifier_call) {
+ unregister_reboot_notifier(&intel_dp->edp_notifier);
+ intel_dp->edp_notifier.notifier_call = NULL;
+ }
}
kfree(intel_dig_port);
}
@@ -3782,6 +3820,10 @@ intel_dp_init_connector(struct intel_digital_port
*intel_dig_port,
if (is_edp(intel_dp)) {
intel_dp_init_panel_power_timestamps(intel_dp);
intel_dp_init_panel_power_sequencer(dev, intel_dp, &power_seq);
+ if (IS_VALLEYVIEW(dev)) {
+ intel_dp->edp_notifier.notifier_call =
edp_notify_handler;
+ register_reboot_notifier(&intel_dp->edp_notifier);
+ }
}
intel_dp_aux_init(intel_dp, intel_connector);
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index 328b1a7..6d0d96e 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -510,6 +510,8 @@ struct intel_dp {
unsigned long last_power_on;
unsigned long last_backlight_off;
bool psr_setup_done;
+ struct notifier_block edp_notifier;
+
bool use_tps3;
struct intel_connector *attached_connector;
--
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 PATCH 2/2] drm/i915: respect the VBT minimum backlight brightness
On Tue, Apr 29, 2014 at 1:30 PM, Jani Nikula wrote:
> Historically we've exposed the full backlight PWM duty cycle range to
> the userspace, in the name of "mechanism, not policy". However, it turns
> out there are both panels and board designs where there is a minimum
> duty cycle that is required for proper operation. The minimum duty cycle
> is available in the VBT.
>
> The backlight class sysfs interface does not make any promises to the
> userspace about the physical meaning of the range
> 0..max_brightness. Specifically there is no guarantee that 0 means off;
> indeed for acpi_backlight 0 usually is not off, but the minimum
> acceptable value.
This is the part we've been relying on in Chrome OS (we assume that 0
means off). It seems to me that i915 would be the first, or one of the
first drivers to violate this rule (in particular you can find a lot
of backlight drivers trying hard to ensure that 0 means off in the
backlight drivers directory).
For context, we use backlight = 0 as a quick "turn the panel off"
function where possible. This allows us to avoid the panel off delay
where possible. Breaking this assumption means that we'd pay the panel
off delay penalty everywhere, not just with BYT.
Stéphane
>
> Respect the minimum backlight, and expose the range acceptable to the
> hardware as 0..max_brightness to the userspace via the backlight class
> device; 0 means the minimum acceptable enabled value. To switch off the
> backlight, the user must disable the encoder.
>
> As a side effect, make the backlight class device max brightness and
> physical PWM modulation frequency (i.e. max duty cycle) independent.
>
> Signed-off-by: Jani Nikula
>
> ---
>
> UNTESTED!
> ---
> drivers/gpu/drm/i915/i915_drv.h| 1 +
> drivers/gpu/drm/i915/intel_bios.c | 3 +-
> drivers/gpu/drm/i915/intel_drv.h | 1 +
> drivers/gpu/drm/i915/intel_panel.c | 97
> +++---
> 4 files changed, 85 insertions(+), 17 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index 50dfc3a1a9d1..d9dad3498b87 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -1164,6 +1164,7 @@ struct intel_vbt_data {
> u16 pwm_freq_hz;
> bool present;
> bool active_low_pwm;
> + u8 min_brightness; /* min_brightness/255 of max */
> } backlight;
>
> /* MIPI DSI */
> diff --git a/drivers/gpu/drm/i915/intel_bios.c
> b/drivers/gpu/drm/i915/intel_bios.c
> index 2945f57c53ee..1a3e172029b3 100644
> --- a/drivers/gpu/drm/i915/intel_bios.c
> +++ b/drivers/gpu/drm/i915/intel_bios.c
> @@ -339,11 +339,12 @@ parse_lfp_backlight(struct drm_i915_private *dev_priv,
> struct bdb_header *bdb)
>
> dev_priv->vbt.backlight.pwm_freq_hz = entry->pwm_freq_hz;
> dev_priv->vbt.backlight.active_low_pwm = entry->active_low_pwm;
> + dev_priv->vbt.backlight.min_brightness = entry->min_brightness;
> DRM_DEBUG_KMS("VBT backlight PWM modulation frequency %u Hz, "
> "active %s, min brightness %u, level %u\n",
> dev_priv->vbt.backlight.pwm_freq_hz,
> dev_priv->vbt.backlight.active_low_pwm ? "low" : "high",
> - entry->min_brightness,
> + dev_priv->vbt.backlight.min_brightness,
> backlight_data->level[panel_type]);
> }
>
> diff --git a/drivers/gpu/drm/i915/intel_drv.h
> b/drivers/gpu/drm/i915/intel_drv.h
> index d8b540b891d1..2af74dd03e31 100644
> --- a/drivers/gpu/drm/i915/intel_drv.h
> +++ b/drivers/gpu/drm/i915/intel_drv.h
> @@ -165,6 +165,7 @@ struct intel_panel {
> struct {
> bool present;
> u32 level;
> + u32 min;
> u32 max;
> bool enabled;
> bool combination_mode; /* gen 2/4 only */
> diff --git a/drivers/gpu/drm/i915/intel_panel.c
> b/drivers/gpu/drm/i915/intel_panel.c
> index 776249bab488..360ae203aacb 100644
> --- a/drivers/gpu/drm/i915/intel_panel.c
> +++ b/drivers/gpu/drm/i915/intel_panel.c
> @@ -398,6 +398,30 @@ intel_panel_detect(struct drm_device *dev)
> }
> }
>
> +/* Scale user_level in range [0..user_max] to [hw_min..hw_max]. */
> +static u32 scale_user_to_hw(struct intel_connector *connector,
> + u32 user_level, u32 user_max)
> +{
> + struct intel_panel *panel = &connector->panel;
> +
> + user_level = clamp(user_level, 0U, user_max);
> +
> + return panel->backlight.min + user_level *
> + (panel->backlight.max - panel->backlight.min) / user_max;
> +}
> +
> +/* Scale hw_level in range [hw_min..hw_max] to [0..user_max]. */
> +static u32 scale_hw_to_user(struct intel_connector *connector,
> + u32 hw_level, u32 user_max)
> +{
> + struct intel_panel *panel = &connector->panel;
> +
> + hw_level = clamp(hw_leve
[Intel-gfx] [PATCH] drm: Move plane helpers into drm_kms_helper.ko
The drm core shouldn't depend upon any helpers, and we make sure this doesn't accidentally happen by moving them into the helper-only drm_kms_helper.ko module. v2: Don't break the build for vmwgfx, spotted by Matt. v3: Unbreak the depency loop around CONFIG_FB (not actually a loop since it involves select). Reported by Chris. Cc: Matt Roper Cc: Thomas Hellstrom Cc: Chris Wilson Signed-off-by: Daniel Vetter --- drivers/gpu/drm/Makefile | 6 +++--- drivers/gpu/drm/vmwgfx/Kconfig | 7 +-- 2 files changed, 8 insertions(+), 5 deletions(-) diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile index 48e38ba22783..863db8415c22 100644 --- a/drivers/gpu/drm/Makefile +++ b/drivers/gpu/drm/Makefile @@ -13,8 +13,7 @@ drm-y :=drm_auth.o drm_buffer.o drm_bufs.o drm_cache.o \ drm_crtc.o drm_modes.o drm_edid.o \ drm_info.o drm_debugfs.o drm_encoder_slave.o \ drm_trace_points.o drm_global.o drm_prime.o \ - drm_rect.o drm_vma_manager.o drm_flip_work.o \ - drm_plane_helper.o + drm_rect.o drm_vma_manager.o drm_flip_work.o drm-$(CONFIG_COMPAT) += drm_ioc32.o drm-$(CONFIG_DRM_GEM_CMA_HELPER) += drm_gem_cma_helper.o @@ -23,7 +22,8 @@ drm-$(CONFIG_DRM_PANEL) += drm_panel.o drm-usb-y := drm_usb.o -drm_kms_helper-y := drm_crtc_helper.o drm_dp_helper.o drm_probe_helper.o +drm_kms_helper-y := drm_crtc_helper.o drm_dp_helper.o drm_probe_helper.o \ + drm_plane_helper.o drm_kms_helper-$(CONFIG_DRM_LOAD_EDID_FIRMWARE) += drm_edid_load.o drm_kms_helper-$(CONFIG_DRM_KMS_FB_HELPER) += drm_fb_helper.o drm_kms_helper-$(CONFIG_DRM_KMS_CMA_HELPER) += drm_fb_cma_helper.o diff --git a/drivers/gpu/drm/vmwgfx/Kconfig b/drivers/gpu/drm/vmwgfx/Kconfig index b71bcd0bfbbf..67720f70fe29 100644 --- a/drivers/gpu/drm/vmwgfx/Kconfig +++ b/drivers/gpu/drm/vmwgfx/Kconfig @@ -1,11 +1,14 @@ config DRM_VMWGFX tristate "DRM driver for VMware Virtual GPU" - depends on DRM && PCI && FB + depends on DRM && PCI select FB_DEFERRED_IO select FB_CFB_FILLRECT select FB_CFB_COPYAREA select FB_CFB_IMAGEBLIT select DRM_TTM + # Only needed for the transitional use of drm_crtc_init - can be removed + # again once vmwgfx sets up the primary plane itself. + select DRM_KMS_HELPER help Choose this option if you would like to run 3D acceleration in a VMware virtual machine. @@ -14,7 +17,7 @@ config DRM_VMWGFX The compiled module will be called "vmwgfx.ko". config DRM_VMWGFX_FBCON - depends on DRM_VMWGFX + depends on DRM_VMWGFX && FB bool "Enable framebuffer console under vmwgfx by default" help Choose this option if you are shipping a new vmwgfx -- 2.0.0 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2 07/16] drm/i915: Add vblank based delayed watermark update mechanism
2014-05-22 11:48 GMT-03:00 :
> From: Ville Syrjälä
>
> Add a mechanism by which you can queue up watermark update to happen
> after the vblank counter has reached a certain value. The vblank
> interrupt handler will schedule a work which will do the actual
> watermark programming in process context.
>
> v2: Rebase and s/intel_crtc/crtc/
>
> Signed-off-by: Ville Syrjälä
> ---
> drivers/gpu/drm/i915/i915_drv.h | 2 +
> drivers/gpu/drm/i915/i915_irq.c | 12 ++-
> drivers/gpu/drm/i915/intel_display.c | 1 +
> drivers/gpu/drm/i915/intel_drv.h | 27 +++
> drivers/gpu/drm/i915/intel_pm.c | 144
> +++
> 5 files changed, 183 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index a2302a7..c90d5ac 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -1541,6 +1541,8 @@ struct drm_i915_private {
> * state as well as the actual hardware registers
> */
> struct mutex mutex;
> +
> + struct work_struct work;
> } wm;
>
> struct i915_runtime_pm pm;
> diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
> index 304f86a..c680020 100644
> --- a/drivers/gpu/drm/i915/i915_irq.c
> +++ b/drivers/gpu/drm/i915/i915_irq.c
> @@ -2067,8 +2067,10 @@ static void ilk_display_irq_handler(struct drm_device
> *dev, u32 de_iir)
> DRM_ERROR("Poison interrupt\n");
>
> for_each_pipe(pipe) {
> - if (de_iir & DE_PIPE_VBLANK(pipe))
> + if (de_iir & DE_PIPE_VBLANK(pipe)) {
> intel_pipe_handle_vblank(dev, pipe);
> + ilk_update_pipe_wm(dev, pipe);
> + }
>
> if (de_iir & DE_PIPE_FIFO_UNDERRUN(pipe))
> if (intel_set_cpu_fifo_underrun_reporting(dev, pipe,
> false))
> @@ -2117,8 +2119,10 @@ static void ivb_display_irq_handler(struct drm_device
> *dev, u32 de_iir)
> intel_opregion_asle_intr(dev);
>
> for_each_pipe(pipe) {
> - if (de_iir & (DE_PIPE_VBLANK_IVB(pipe)))
> + if (de_iir & (DE_PIPE_VBLANK_IVB(pipe))) {
> intel_pipe_handle_vblank(dev, pipe);
> + ilk_update_pipe_wm(dev, pipe);
> + }
>
> /* plane/pipes map 1:1 on ilk+ */
> if (de_iir & DE_PLANE_FLIP_DONE_IVB(pipe)) {
> @@ -2260,8 +2264,10 @@ static irqreturn_t gen8_irq_handler(int irq, void *arg)
> continue;
>
> pipe_iir = I915_READ(GEN8_DE_PIPE_IIR(pipe));
> - if (pipe_iir & GEN8_PIPE_VBLANK)
> + if (pipe_iir & GEN8_PIPE_VBLANK) {
> intel_pipe_handle_vblank(dev, pipe);
> + ilk_update_pipe_wm(dev, pipe);
> + }
>
> if (pipe_iir & GEN8_PIPE_PRIMARY_FLIP_DONE) {
> intel_prepare_page_flip(dev, pipe);
> diff --git a/drivers/gpu/drm/i915/intel_display.c
> b/drivers/gpu/drm/i915/intel_display.c
> index a11bd78..408b238 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -10961,6 +10961,7 @@ static void intel_crtc_init(struct drm_device *dev,
> int pipe)
> intel_crtc->plane = !pipe;
> }
>
> + spin_lock_init(&intel_crtc->wm.lock);
> init_waitqueue_head(&intel_crtc->vbl_wait);
>
> BUG_ON(pipe >= ARRAY_SIZE(dev_priv->plane_to_crtc_mapping) ||
> diff --git a/drivers/gpu/drm/i915/intel_drv.h
> b/drivers/gpu/drm/i915/intel_drv.h
> index d75cc2b..72f01b1 100644
> --- a/drivers/gpu/drm/i915/intel_drv.h
> +++ b/drivers/gpu/drm/i915/intel_drv.h
> @@ -409,6 +409,32 @@ struct intel_crtc {
> * protected by dev_priv->wm.mutex
> */
> struct intel_pipe_wm active;
> + /*
> +* watermarks queued for next vblank
> +* protected by dev_priv->wm.mutex
> +*/
> + struct intel_pipe_wm pending;
> +
> + /*
> +* the vblank count after which we can switch over to
> 'pending'
> +* protected by intel_crtc->wm.lock
> +*/
> + u32 pending_vbl_count;
> + /*
> +* indicates that 'pending' contains changed watermarks
> +* protected by intel_crtc->wm.lock
> +*/
> + bool dirty;
> + /*
> +* watermark update has a vblank reference?
> +* protected by intel_crtc->wm.lock
> +*/
> + bool vblank;
I would rename this variable. Maybe has_vblank_ref?
> +
> + /*
> +* protects some intel_crtc->wm state
Please be more precise on what "some" actually mea
Re: [Intel-gfx] [PATCH v2 07/16] drm/i915: Add vblank based delayed watermark update mechanism
On Tue, Jun 03, 2014 at 03:50:12PM -0300, Paulo Zanoni wrote:
> 2014-05-22 11:48 GMT-03:00 :
> > From: Ville Syrjälä
> >
> > Add a mechanism by which you can queue up watermark update to happen
> > after the vblank counter has reached a certain value. The vblank
> > interrupt handler will schedule a work which will do the actual
> > watermark programming in process context.
> >
> > v2: Rebase and s/intel_crtc/crtc/
> >
> > Signed-off-by: Ville Syrjälä
> > ---
> > drivers/gpu/drm/i915/i915_drv.h | 2 +
> > drivers/gpu/drm/i915/i915_irq.c | 12 ++-
> > drivers/gpu/drm/i915/intel_display.c | 1 +
> > drivers/gpu/drm/i915/intel_drv.h | 27 +++
> > drivers/gpu/drm/i915/intel_pm.c | 144
> > +++
> > 5 files changed, 183 insertions(+), 3 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/i915_drv.h
> > b/drivers/gpu/drm/i915/i915_drv.h
> > index a2302a7..c90d5ac 100644
> > --- a/drivers/gpu/drm/i915/i915_drv.h
> > +++ b/drivers/gpu/drm/i915/i915_drv.h
> > @@ -1541,6 +1541,8 @@ struct drm_i915_private {
> > * state as well as the actual hardware registers
> > */
> > struct mutex mutex;
> > +
> > + struct work_struct work;
> > } wm;
> >
> > struct i915_runtime_pm pm;
> > diff --git a/drivers/gpu/drm/i915/i915_irq.c
> > b/drivers/gpu/drm/i915/i915_irq.c
> > index 304f86a..c680020 100644
> > --- a/drivers/gpu/drm/i915/i915_irq.c
> > +++ b/drivers/gpu/drm/i915/i915_irq.c
> > @@ -2067,8 +2067,10 @@ static void ilk_display_irq_handler(struct
> > drm_device *dev, u32 de_iir)
> > DRM_ERROR("Poison interrupt\n");
> >
> > for_each_pipe(pipe) {
> > - if (de_iir & DE_PIPE_VBLANK(pipe))
> > + if (de_iir & DE_PIPE_VBLANK(pipe)) {
> > intel_pipe_handle_vblank(dev, pipe);
> > + ilk_update_pipe_wm(dev, pipe);
> > + }
> >
> > if (de_iir & DE_PIPE_FIFO_UNDERRUN(pipe))
> > if (intel_set_cpu_fifo_underrun_reporting(dev,
> > pipe, false))
> > @@ -2117,8 +2119,10 @@ static void ivb_display_irq_handler(struct
> > drm_device *dev, u32 de_iir)
> > intel_opregion_asle_intr(dev);
> >
> > for_each_pipe(pipe) {
> > - if (de_iir & (DE_PIPE_VBLANK_IVB(pipe)))
> > + if (de_iir & (DE_PIPE_VBLANK_IVB(pipe))) {
> > intel_pipe_handle_vblank(dev, pipe);
> > + ilk_update_pipe_wm(dev, pipe);
> > + }
> >
> > /* plane/pipes map 1:1 on ilk+ */
> > if (de_iir & DE_PLANE_FLIP_DONE_IVB(pipe)) {
> > @@ -2260,8 +2264,10 @@ static irqreturn_t gen8_irq_handler(int irq, void
> > *arg)
> > continue;
> >
> > pipe_iir = I915_READ(GEN8_DE_PIPE_IIR(pipe));
> > - if (pipe_iir & GEN8_PIPE_VBLANK)
> > + if (pipe_iir & GEN8_PIPE_VBLANK) {
> > intel_pipe_handle_vblank(dev, pipe);
> > + ilk_update_pipe_wm(dev, pipe);
> > + }
> >
> > if (pipe_iir & GEN8_PIPE_PRIMARY_FLIP_DONE) {
> > intel_prepare_page_flip(dev, pipe);
> > diff --git a/drivers/gpu/drm/i915/intel_display.c
> > b/drivers/gpu/drm/i915/intel_display.c
> > index a11bd78..408b238 100644
> > --- a/drivers/gpu/drm/i915/intel_display.c
> > +++ b/drivers/gpu/drm/i915/intel_display.c
> > @@ -10961,6 +10961,7 @@ static void intel_crtc_init(struct drm_device *dev,
> > int pipe)
> > intel_crtc->plane = !pipe;
> > }
> >
> > + spin_lock_init(&intel_crtc->wm.lock);
> > init_waitqueue_head(&intel_crtc->vbl_wait);
> >
> > BUG_ON(pipe >= ARRAY_SIZE(dev_priv->plane_to_crtc_mapping) ||
> > diff --git a/drivers/gpu/drm/i915/intel_drv.h
> > b/drivers/gpu/drm/i915/intel_drv.h
> > index d75cc2b..72f01b1 100644
> > --- a/drivers/gpu/drm/i915/intel_drv.h
> > +++ b/drivers/gpu/drm/i915/intel_drv.h
> > @@ -409,6 +409,32 @@ struct intel_crtc {
> > * protected by dev_priv->wm.mutex
> > */
> > struct intel_pipe_wm active;
> > + /*
> > +* watermarks queued for next vblank
> > +* protected by dev_priv->wm.mutex
> > +*/
> > + struct intel_pipe_wm pending;
> > +
> > + /*
> > +* the vblank count after which we can switch over to
> > 'pending'
> > +* protected by intel_crtc->wm.lock
> > +*/
> > + u32 pending_vbl_count;
> > + /*
> > +* indicates that 'pending' contains changed watermarks
> > +* protected by intel_crtc->wm.lock
> > +*/
> > + bool dirty;
> > + /*
> > +* watermark update has a
Re: [Intel-gfx] [RFC PATCH 2/2] drm/i915: respect the VBT minimum backlight brightness
On Tue, Jun 3, 2014 at 6:40 PM, Stéphane Marchesin wrote: > On Tue, Apr 29, 2014 at 1:30 PM, Jani Nikula wrote: >> Historically we've exposed the full backlight PWM duty cycle range to >> the userspace, in the name of "mechanism, not policy". However, it turns >> out there are both panels and board designs where there is a minimum >> duty cycle that is required for proper operation. The minimum duty cycle >> is available in the VBT. >> >> The backlight class sysfs interface does not make any promises to the >> userspace about the physical meaning of the range >> 0..max_brightness. Specifically there is no guarantee that 0 means off; >> indeed for acpi_backlight 0 usually is not off, but the minimum >> acceptable value. > > This is the part we've been relying on in Chrome OS (we assume that 0 > means off). It seems to me that i915 would be the first, or one of the > first drivers to violate this rule (in particular you can find a lot > of backlight drivers trying hard to ensure that 0 means off in the > backlight drivers directory). > > For context, we use backlight = 0 as a quick "turn the panel off" > function where possible. This allows us to avoid the panel off delay > where possible. Breaking this assumption means that we'd pay the panel > off delay penalty everywhere, not just with BYT. Well kde is the opposite and I've had users yelling at me that they can't use their system, since acpi pretty much always leaves the backlight on when set to 0. And acpi kinda rules on intel platforms. So I think I'll merge this one since black screens trumps a slight functional degration and we didn't duct-tape over the kde assumptions either. Essentially you can't assume anything about backlight values besides that bigger values tends to mean brigther. Linearity, absolute values and endpoints are kinda all off. If we want to specifically expose an intermediate "panel off" level because the full link training is too expensive we imo should do this as an intermediate dpms level, e.g. dpms standby. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - 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 08/16] drm/i915: Split watermark programming into pre and post steps
2014-05-22 11:48 GMT-03:00 :
> From: Ville Syrjälä
>
> We need to perform watermark programming before and after changing the
> plane configuration. Add two new vfuncs to do that. The pre phase is
> supposed to switch over to the intermediate watermarks which are
> computed so that they can deal with both the old and new plane
> configurations. The post phase will arm the vblank based update
> systems to switch over to the optimal target watermarks after the
> plane configuration has for sure changed.
>
> v2: Pass around intel_crtc and s/intel_crtc/crtc/
>
> Signed-off-by: Ville Syrjälä
> ---
> drivers/gpu/drm/i915/i915_drv.h | 5 +++
> drivers/gpu/drm/i915/intel_drv.h | 11 +
> drivers/gpu/drm/i915/intel_pm.c | 88
>
> 3 files changed, 104 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index c90d5ac..d4f8ae8 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -407,6 +407,7 @@ struct intel_plane_config;
> struct intel_crtc;
> struct intel_limit;
> struct dpll;
> +struct intel_crtc_wm_config;
>
> struct drm_i915_display_funcs {
> bool (*fbc_enabled)(struct drm_device *dev);
> @@ -437,6 +438,10 @@ struct drm_i915_display_funcs {
> struct drm_crtc *crtc,
> uint32_t sprite_width, int pixel_size,
> bool enable, bool scaled);
> + void (*program_wm_pre)(struct intel_crtc *crtc,
> + const struct intel_crtc_wm_config *config);
> + void (*program_wm_post)(struct intel_crtc *crtc,
> + const struct intel_crtc_wm_config *config);
> void (*modeset_global_resources)(struct drm_device *dev);
> /* Returns the active state of the crtc, and if the crtc is active,
> * fills out the pipe-config with the hw state. */
> diff --git a/drivers/gpu/drm/i915/intel_drv.h
> b/drivers/gpu/drm/i915/intel_drv.h
> index 72f01b1..4b59be3 100644
> --- a/drivers/gpu/drm/i915/intel_drv.h
> +++ b/drivers/gpu/drm/i915/intel_drv.h
> @@ -358,6 +358,13 @@ struct intel_pipe_wm {
> bool sprites_scaled;
> };
>
> +struct intel_crtc_wm_config {
> + /* target watermarks for the pipe */
> + struct intel_pipe_wm target;
> + /* intermediate watermarks for pending/active->target transition */
> + struct intel_pipe_wm intm;
It seems you always prefer shorter names such as "intm", and I usually
prefer the longer ones like "intermediate". Looks like this is a
common topic for my bikesheddings on your patches. When I read "intm"
my brain parses it as "Int M" and then aborts execution =P
With or without that changed: Reviewed-by: Paulo Zanoni
> +};
> +
> struct intel_crtc {
> struct drm_crtc base;
> enum pipe pipe;
> @@ -1001,6 +1008,10 @@ void intel_init_runtime_pm(struct drm_i915_private
> *dev_priv);
> void intel_fini_runtime_pm(struct drm_i915_private *dev_priv);
> void ilk_wm_get_hw_state(struct drm_device *dev);
> void ilk_update_pipe_wm(struct drm_device *dev, enum pipe pipe);
> +void intel_program_watermarks_pre(struct intel_crtc *crtc,
> + const struct intel_crtc_wm_config *config);
> +void intel_program_watermarks_post(struct intel_crtc *crtc,
> + const struct intel_crtc_wm_config *config);
>
>
> /* intel_sdvo.c */
> diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
> index 6fc6416..ccf920a 100644
> --- a/drivers/gpu/drm/i915/intel_pm.c
> +++ b/drivers/gpu/drm/i915/intel_pm.c
> @@ -2950,6 +2950,20 @@ void ilk_update_pipe_wm(struct drm_device *dev, enum
> pipe pipe)
> spin_unlock(&crtc->wm.lock);
> }
>
> +static void ilk_wm_cancel(struct intel_crtc *crtc)
> +{
> + struct drm_device *dev = crtc->base.dev;
> +
> + assert_spin_locked(&crtc->wm.lock);
> +
> + crtc->wm.dirty = false;
> +
> + if (crtc->wm.vblank) {
> + drm_vblank_put(dev, crtc->pipe);
> + crtc->wm.vblank = false;
> + }
> +}
> +
> static void ilk_update_sprite_wm(struct drm_plane *plane,
> struct drm_crtc *crtc,
> uint32_t sprite_width, int pixel_size,
> @@ -3084,6 +3098,24 @@ void intel_update_sprite_watermarks(struct drm_plane
> *plane,
>pixel_size, enabled,
> scaled);
> }
>
> +void intel_program_watermarks_pre(struct intel_crtc *crtc,
> + const struct intel_crtc_wm_config *config)
> +{
> + struct drm_i915_private *dev_priv = crtc->base.dev->dev_private;
> +
> + if (dev_priv->display.program_wm_pre)
> + dev_priv->display.program_wm_pre(crtc, config);
> +}
> +
> +void intel_program_watermarks_post(struct intel_crtc *crtc,
> +
[Intel-gfx] [PATCH] rendercopy/gen8: Also emit 3DSTATE_WM_DEPTH_STENCIL.
rendercopy was failing to emit 3DSTATE_WM_DEPTH_STENCIL, which is a new
packet on Broadwell. Mesa emits this packet.
This appears to fix various tests on a fresh boot, when Mesa has never
run.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=78890
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=78891
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=78935
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=78936
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=78937
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=78938
Signed-off-by: Kenneth Graunke
Cc: Ben Widawsky
---
lib/gen8_render.h | 1 +
lib/rendercopy_gen8.c | 4
2 files changed, 5 insertions(+)
diff --git a/lib/gen8_render.h b/lib/gen8_render.h
index fffc100..0eec80c 100644
--- a/lib/gen8_render.h
+++ b/lib/gen8_render.h
@@ -48,6 +48,7 @@
GEN6_3D(3, 0, 0x21)
#define GEN8_3DSTATE_PS_BLEND GEN6_3D(3, 0, 0x4d)
# define GEN8_PS_BLEND_HAS_WRITEABLE_RT(1 << 30)
+#define GEN8_3DSTATE_WM_DEPTH_STENCIL GEN6_3D(3, 0, 0x4e)
#define GEN8_3DSTATE_PS_EXTRA GEN6_3D(3,0, 0x4f)
# define GEN8_PSX_PIXEL_SHADER_VALID (1 << 31)
# define GEN8_PSX_ATTRIBUTE_ENABLE (1 << 8)
diff --git a/lib/rendercopy_gen8.c b/lib/rendercopy_gen8.c
index 6f5a698..e7567d2 100644
--- a/lib/rendercopy_gen8.c
+++ b/lib/rendercopy_gen8.c
@@ -816,6 +816,10 @@ gen8_emit_ps(struct intel_batchbuffer *batch, uint32_t
kernel) {
static void
gen8_emit_depth(struct intel_batchbuffer *batch) {
+ OUT_BATCH(GEN8_3DSTATE_WM_DEPTH_STENCIL | (3 - 2));
+ OUT_BATCH(0);
+ OUT_BATCH(0);
+
OUT_BATCH(GEN7_3DSTATE_DEPTH_BUFFER | (8-2));
OUT_BATCH(0);
OUT_BATCH(0);
--
1.9.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] rendercopy/gen8: Also emit 3DSTATE_WM_DEPTH_STENCIL.
On Tue, Jun 03, 2014 at 02:52:30PM -0700, Kenneth Graunke wrote: > rendercopy was failing to emit 3DSTATE_WM_DEPTH_STENCIL, which is a new > packet on Broadwell. Mesa emits this packet. > > This appears to fix various tests on a fresh boot, when Mesa has never > run. > > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=78890 > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=78891 > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=78935 > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=78936 > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=78937 > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=78938 > Signed-off-by: Kenneth Graunke > Cc: Ben Widawsky I sat with Ken all day today (after a few days of debugging myself) and it does what it purport to do, and fixes a bunch of tests. Reviewed-by: Ben Widawsky FWIW: I don't think we need to update the null state in the kernel. It's actually kind of nice for finding userspace bugs. -- Ben Widawsky, 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 v2 09/16] drm/i915: Actually perform the watermark update in two phases
2014-05-22 11:48 GMT-03:00 :
> From: Ville Syrjälä
>
> Switch the code over to using the two phase watermark update. The steps
> generally follow this pattern:
>
> 1. Calculate new plane parameters for changed planes
> 2. Calculate new target and intermediate watermarks
> 3. Check that both the target and intermediate watermarks are valid
> 4. Program the hardware with the intermediate watermarks
> 5. Program the plane registers
> 6. Arm the vblank watermark update machinery for the next vblank
> 7. Program the hardware with the target watermarks (after vblank)
>
> v2: Rebased, pass intel_crtc around, s/intel_crtc/crtc/
>
> Signed-off-by: Ville Syrjälä
This patch is huge. If we bisect any regression to it, we will be
completely lost and hopeless. Also, my tiny little brain doesn't have
enough power to do a proper review of this patch with so many changes
happening all at the same place. I tried, but I gave up in the middle.
Please try to convert this patch into many smaller patches. I don't
know if the following idea is actually possible, but it is what I
could extract from what I read of your patch:
- I'd start with the way you update watermarks parameters. Start by
patching ilk_compute_wm_parameters() and making it directly call your
new update_xxx_params() functions. You can even do separate patches
for _pri, _cur and _spr patches since it seems the _spr code is
different for most of your patch due to the old
intel_update_sprite_watermarks() function.
- Then you change the way you use to set your parameters (there's a
comment below mentioning the specific line which I'm talking about
here)
- Then you can patch intel_display.c so you will only update the WM
params when you actually change the HW (the _hw_plane and
update_cursor functions). Again, you can even split _pri, _cur and
_spr on separate patches.
- Then you can introduce the update_cursor_wm() and
update_primary_wm() functions, but still make them call the old-style
intel_update_watermarks() or something similar.
- You can also add the functions to deal with intermediate watermarks,
but without using them. Or you could, for example, make the
intermediate watermarks just be the same as the "old" ones, so the
only real update will be the final one (which, I believe, will mean
the code still behaves as it does today, no regressions).
- Then you can add the final piece of the code that uses all the new
infrastructure to actually generate and use the intermediate
watermarks. And this would be a much smaller patch.
There are still some comments below:
> ---
> drivers/gpu/drm/i915/i915_drv.h | 14 ++-
> drivers/gpu/drm/i915/intel_display.c | 58 -
> drivers/gpu/drm/i915/intel_drv.h | 35 --
> drivers/gpu/drm/i915/intel_pm.c | 229
> +++
> drivers/gpu/drm/i915/intel_sprite.c | 119 --
> 5 files changed, 347 insertions(+), 108 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index d4f8ae8..5b1404e 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -405,9 +405,12 @@ struct intel_connector;
> struct intel_crtc_config;
> struct intel_plane_config;
> struct intel_crtc;
> +struct intel_plane;
> struct intel_limit;
> struct dpll;
> struct intel_crtc_wm_config;
> +struct intel_plane_wm_parameters;
> +struct intel_crtc_wm_config;
>
> struct drm_i915_display_funcs {
> bool (*fbc_enabled)(struct drm_device *dev);
> @@ -434,10 +437,13 @@ struct drm_i915_display_funcs {
> struct dpll *match_clock,
> struct dpll *best_clock);
> void (*update_wm)(struct drm_crtc *crtc);
> - void (*update_sprite_wm)(struct drm_plane *plane,
> -struct drm_crtc *crtc,
> -uint32_t sprite_width, int pixel_size,
> -bool enable, bool scaled);
> + int (*update_primary_wm)(struct intel_crtc *crtc,
> +struct intel_crtc_wm_config *config);
> + int (*update_cursor_wm)(struct intel_crtc *crtc,
> + struct intel_crtc_wm_config *config);
> + int (*update_sprite_wm)(struct intel_plane *plane,
> + struct intel_crtc *crtc,
> + struct intel_crtc_wm_config *config);
> void (*program_wm_pre)(struct intel_crtc *crtc,
>const struct intel_crtc_wm_config *config);
> void (*program_wm_post)(struct intel_crtc *crtc,
> diff --git a/drivers/gpu/drm/i915/intel_display.c
> b/drivers/gpu/drm/i915/intel_display.c
> index 408b238..5bf1633 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -2078,6 +2078,19 @@ void intel_flush_primary_plane(struct drm_i915_private
> *dev_priv,
> POSTING_READ(reg);
> }
>
> +static void update_pri
[Intel-gfx] [PATCH] drm/i915: Kick out vga console
From: Chris Wilson
Touching the VGA resources on an IVB EFI machine causes hard hangs when
we then kick out the efifb. Ouch.
Apparently this also prevents unclaimed register errors on hsw and
hard machine hangs on my i855gm when trying to unbind fbcon.
Also, we want this to make I915_FBDEV=n safe.
v2: Rebase and pimp commit message.
v3: We also need to unregister the vga console, otherwise the unbind
of the fb console before module unload might resurrect it again.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=67813
Cc: David Herrmann
Cc: Jean-Christophe Plagniol-Villard
Cc: Tomi Valkeinen
Cc: linux-fb...@vger.kernel.org
Signed-off-by: Chris Wilson (v1)
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/i915/i915_dma.c | 34 +-
drivers/video/console/dummycon.c | 1 +
drivers/video/console/vgacon.c | 1 +
3 files changed, 35 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/i915_dma.c b/drivers/gpu/drm/i915/i915_dma.c
index b9159ade5e85..a4df80740b37 100644
--- a/drivers/gpu/drm/i915/i915_dma.c
+++ b/drivers/gpu/drm/i915/i915_dma.c
@@ -36,6 +36,8 @@
#include "i915_drv.h"
#include "i915_trace.h"
#include
+#include
+#include
#include
#include
#include
@@ -1450,6 +1452,29 @@ static void i915_kick_out_firmware_fb(struct
drm_i915_private *dev_priv)
}
#endif
+static int i915_kick_out_vgacon(struct drm_i915_private *dev_priv)
+{
+#if !defined(CONFIG_VGA_CONSOLE)
+ return 0;
+#else
+ int ret;
+
+#if !defined(CONFIG_DUMMY_CONSOLE)
+ return -ENODEV;
+#endif
+
+ DRM_INFO("Replacing VGA console driver\n");
+
+ console_lock();
+ ret = do_take_over_console(&dummy_con, 0, MAX_NR_CONSOLES - 1, 1);
+ if (ret == 0)
+ ret = do_unregister_con_driver(&vga_con);
+ console_unlock();
+
+ return ret;
+#endif
+}
+
static void i915_dump_device_info(struct drm_i915_private *dev_priv)
{
const struct intel_device_info *info = &dev_priv->info;
@@ -1623,8 +1648,15 @@ int i915_driver_load(struct drm_device *dev, unsigned
long flags)
if (ret)
goto out_regs;
- if (drm_core_check_feature(dev, DRIVER_MODESET))
+ if (drm_core_check_feature(dev, DRIVER_MODESET)) {
+ ret = i915_kick_out_vgacon(dev_priv);
+ if (ret) {
+ DRM_ERROR("failed to remove conflicting VGA console\n");
+ goto out_gtt;
+ }
+
i915_kick_out_firmware_fb(dev_priv);
+ }
pci_set_master(dev->pdev);
diff --git a/drivers/video/console/dummycon.c b/drivers/video/console/dummycon.c
index b63860f7beab..40bec8d64b0a 100644
--- a/drivers/video/console/dummycon.c
+++ b/drivers/video/console/dummycon.c
@@ -77,3 +77,4 @@ const struct consw dummy_con = {
.con_set_palette = DUMMY,
.con_scrolldelta = DUMMY,
};
+EXPORT_SYMBOL_GPL(dummy_con);
diff --git a/drivers/video/console/vgacon.c b/drivers/video/console/vgacon.c
index 9d8feac67637..84acd6223dc5 100644
--- a/drivers/video/console/vgacon.c
+++ b/drivers/video/console/vgacon.c
@@ -1440,5 +1440,6 @@ const struct consw vga_con = {
.con_build_attr = vgacon_build_attr,
.con_invert_region = vgacon_invert_region,
};
+EXPORT_SYMBOL(vga_con);
MODULE_LICENSE("GPL");
--
1.8.1.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] igt_core: Add PCI ID to the test spew
makes sure the platform match what is expected.
Sample output:
bwidawsk@ironside ~/intel-gfx/intel-gpu-tools (master)$ sudo
./tests/gem_exec_nop
PCI ID: 0x0a16 IGT-Version: 1.6-g21bcc3f (x86_64) (Linux: 3.14.4-1-ARCH x86_64)
Signed-off-by: Ben Widawsky
---
lib/igt_core.c | 17 ++---
1 file changed, 14 insertions(+), 3 deletions(-)
diff --git a/lib/igt_core.c b/lib/igt_core.c
index 6e553cf..097ae62 100644
--- a/lib/igt_core.c
+++ b/lib/igt_core.c
@@ -254,18 +254,29 @@ static void check_igt_exit(int sig)
assert(sig != 0 || igt_exit_called);
}
+#define PCI_ID_PATH "/sys/devices/pci:00/:00:02.0/device"
static void print_version(void)
{
struct utsname uts;
+ char pci_id[] = "0x";
+ FILE *file;
if (list_subtests)
return;
uname(&uts);
- fprintf(stdout, "IGT-Version: %s-%s (%s) (%s: %s %s)\n",
PACKAGE_VERSION,
- IGT_GIT_SHA1, TARGET_CPU_PLATFORM,
- uts.sysname, uts.release, uts.machine);
+ file = fopen(PCI_ID_PATH, "r");
+ if (file != NULL) {
+ fgets(pci_id, strlen(pci_id) + 1, file);
+ fclose(file);
+ }
+
+ fprintf(stdout, "PCI ID: %s IGT-Version: %s-%s (%s) (%s: %s %s)\n",
+ pci_id,
+ PACKAGE_VERSION,
+ IGT_GIT_SHA1, TARGET_CPU_PLATFORM,
+ uts.sysname, uts.release, uts.machine);
}
static void print_usage(const char *command_str, const char *help_str,
--
2.0.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2 0/8] drm & drivers: kill drm_get_connector_name() and drm_get_encoder_name()
On 3 June 2014 21:56, Jani Nikula wrote: > Hi all, this is v2 of [1] to remove drm_get_connector_name() and > drm_get_encoder_name(), adding patch 1 for imx in staging and making > some dereferences less of an eye sore. This is based on Dave's drm-next > branch. > I pushed these, after regenerating a couple of bits for new radeon and edid code. Thanks, Dave. ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm: Move plane helpers into drm_kms_helper.ko
On 4 June 2014 03:30, Daniel Vetter wrote: > The drm core shouldn't depend upon any helpers, and we make sure this > doesn't accidentally happen by moving them into the helper-only > drm_kms_helper.ko module. > > v2: Don't break the build for vmwgfx, spotted by Matt. > > v3: Unbreak the depency loop around CONFIG_FB (not actually a loop > since it involves select). Reported by Chris. > > Cc: Matt Roper > Cc: Thomas Hellstrom > Cc: Chris Wilson > Signed-off-by: Daniel Vetter > --- > drivers/gpu/drm/Makefile | 6 +++--- > drivers/gpu/drm/vmwgfx/Kconfig | 7 +-- > 2 files changed, 8 insertions(+), 5 deletions(-) > > diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile > index 48e38ba22783..863db8415c22 100644 > --- a/drivers/gpu/drm/Makefile > +++ b/drivers/gpu/drm/Makefile > @@ -13,8 +13,7 @@ drm-y :=drm_auth.o drm_buffer.o drm_bufs.o > drm_cache.o \ > drm_crtc.o drm_modes.o drm_edid.o \ > drm_info.o drm_debugfs.o drm_encoder_slave.o \ > drm_trace_points.o drm_global.o drm_prime.o \ > - drm_rect.o drm_vma_manager.o drm_flip_work.o \ > - drm_plane_helper.o > + drm_rect.o drm_vma_manager.o drm_flip_work.o > > drm-$(CONFIG_COMPAT) += drm_ioc32.o > drm-$(CONFIG_DRM_GEM_CMA_HELPER) += drm_gem_cma_helper.o > @@ -23,7 +22,8 @@ drm-$(CONFIG_DRM_PANEL) += drm_panel.o > > drm-usb-y := drm_usb.o > > -drm_kms_helper-y := drm_crtc_helper.o drm_dp_helper.o drm_probe_helper.o > +drm_kms_helper-y := drm_crtc_helper.o drm_dp_helper.o drm_probe_helper.o \ > + drm_plane_helper.o > drm_kms_helper-$(CONFIG_DRM_LOAD_EDID_FIRMWARE) += drm_edid_load.o > drm_kms_helper-$(CONFIG_DRM_KMS_FB_HELPER) += drm_fb_helper.o > drm_kms_helper-$(CONFIG_DRM_KMS_CMA_HELPER) += drm_fb_cma_helper.o > diff --git a/drivers/gpu/drm/vmwgfx/Kconfig b/drivers/gpu/drm/vmwgfx/Kconfig > index b71bcd0bfbbf..67720f70fe29 100644 > --- a/drivers/gpu/drm/vmwgfx/Kconfig > +++ b/drivers/gpu/drm/vmwgfx/Kconfig > @@ -1,11 +1,14 @@ > config DRM_VMWGFX > tristate "DRM driver for VMware Virtual GPU" > - depends on DRM && PCI && FB > + depends on DRM && PCI > select FB_DEFERRED_IO > select FB_CFB_FILLRECT > select FB_CFB_COPYAREA > select FB_CFB_IMAGEBLIT > select DRM_TTM > + # Only needed for the transitional use of drm_crtc_init - can be > removed > + # again once vmwgfx sets up the primary plane itself. > + select DRM_KMS_HELPER > help > Choose this option if you would like to run 3D acceleration > in a VMware virtual machine. > @@ -14,7 +17,7 @@ config DRM_VMWGFX > The compiled module will be called "vmwgfx.ko". > > config DRM_VMWGFX_FBCON > - depends on DRM_VMWGFX > + depends on DRM_VMWGFX && FB > bool "Enable framebuffer console under vmwgfx by default" > help >Choose this option if you are shipping a new vmwgfx Applied thanks, Dave. ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v3] drm/i915: Added write-enable pte bit support
On Mon, 2014-06-02 at 10:19 +0200, Daniel Vetter wrote:
> On Sun, Jun 01, 2014 at 12:12:50PM +0530, Akash Goel wrote:
> > On Mon, 2014-05-19 at 13:03 +0530, Akash Goel wrote:
> > > On Mon, 2014-05-19 at 08:56 +0200, Daniel Vetter wrote:
> > > > On Sun, May 18, 2014 at 11:27:00AM +0530, Akash Goel wrote:
> > > > > On Wed, 2014-05-14 at 10:14 +0200, Daniel Vetter wrote:
> > > > > > On Tue, May 13, 2014 at 03:43:12PM -0700, Jesse Barnes wrote:
> > > > > > > On Wed, 14 May 2014 00:30:34 +0200
> > > > > > > Daniel Vetter wrote:
> > > > > > >
> > > > > > > > On Tue, May 13, 2014 at 03:05:24PM -0700, Jesse Barnes wrote:
> > > > > > > > > On Tue, 11 Feb 2014 14:19:03 +0530
> > > > > > > > > akash.g...@intel.com wrote:
> > > > > > > > >
> > > > > > > > > > @@ -810,6 +815,7 @@ static void
> > > > > > > > > > gen6_ppgtt_insert_entries(struct i915_address_space *vm,
> > > > > > > > > > pt_vaddr[act_pte] =
> > > > > > > > > >
> > > > > > > > > > vm->pte_encode(sg_page_iter_dma_address(&sg_iter),
> > > > > > > > > >cache_level, true);
> > > > > > > > > > +
> > > > > > > > > > if (++act_pte == I915_PPGTT_PT_ENTRIES) {
> > > > > > > > > > kunmap_atomic(pt_vaddr);
> > > > > > > > > > pt_vaddr = NULL;
> > > > > > > > >
> > > > > > > > > Some extra whitespace here.
> > > > >
> > > > > Thanks, will remove this.
> > > > >
> > > > > > > > >
> > > > > > > > > Otherwise:
> > > > > > > > > Reviewed-by: Jesse Barnes
> > > > > > > >
> > > > > > > > Hm, looking at the patch again encoding this into the
> > > > > > > > cache_level enum is
> > > > > > > > fraught with fun. And due to IS_VLV aliasing chv this will blow
> > > > > > > > up on chv
> > > > > > > > very likely. My old idea was to eventually add a pte_flags
> > > > > > > > param all over
> > > > > > > > for this stuff with additional bits.
> > > > > > >
> > > > > > > That works too; and yeah CHV is all different here isn't it. But
> > > > > > > won't
> > > > > > > it go through the gen8 paths anyway?
> > > > > >
> > > > > > Yes, but we have a switch on the cache_level in the gen8 pte encode
> > > > > > function. Since the bit31 gets or'ed in for VLV, it'll hit also chv
> > > > > > and
> > > > > > wreak havoc in that specific switch - we'll hit the default case
> > > > > > when we
> > > > > > don't expect to.
> > > > > >
> > > > > > cache_level = functional behaviour relevant for the kernel's
> > > > > > clflushing
> > > > > > code
> > > > > >
> > > > >
> > > > > As the 'IS_VALLEYVIEW' check will alias with CHV also, can I just
> > > > > update
> > > > > the condition here, to include 'GEN7' also (IS_GEN7) in the check.
> > > >
> > > > Adding new random bits to an enum which is used all over the place (and
> > > > not just in the pte encoding functions) makes the code much harder to
> > > > read. Also the code that deals with enum cache_level is all about cache
> > > > coherency, which has rather tricky logic.
> > > >
> > > > Hence I expect this choice to cause further bugs down the road, which is
> > > > why I don't really like it. My apologies for not spotting this earlier.
> > > > -Daniel
> > >
> > > Hi Daniel,
> > >
> > > I understand your concern, but actually (as of now) this bit is only VLV
> > > specific. As per an earlier suggestion from Chris, I decided to
> > > overload the cache_level enum itself, in lieu of adding a new parameter
> > > to all the respective 'xxx_insert_entries' & 'xxx_pte_encode' functions.
> > >
> > > And this is being done just before calling the 'xxx_insert_entries'
> > > function, which simply passes the flag as it is to 'xxx_pte_encode'
> > > function. So there may not be any risk here, if we use the appropriate
> > > VLV check.
> >
> > Please can you provide your inputs here.
>
> I guess you've run into a case where Chris&I disagree. I still think
> wiring up a flags parameter to all the pte encode functions is the sane
> option to pick here.
Hi Daniel,
Yes I just followed Chris's suggestion, which I also felt was
reasonable. But it's fine, will implement it as per your suggestion
only. I hope that will be acceptable to all.
Best regards
Akash
> -Daniel
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915: rework digital port IRQ handling
From: Dave Airlie
The digital ports from Ironlake and up have the ability to distinguish
between long and short HPD pulses. Displayport 1.1 only uses the short
form to request link retraining usually, so we haven't really needed
support for it until now.
However with DP 1.2 MST we need to handle the short irqs on their
own outside the modesetting locking the long hpd's involve. This
patch adds the framework to distinguish between short/long to the
current code base, to lay the basis for future DP 1.2 MST work.
This should mean we get better bisectability in case of regression
due to the new irq handling.
Signed-off-by: Dave Airlie
---
drivers/gpu/drm/i915/i915_drv.h | 5 ++
drivers/gpu/drm/i915/i915_irq.c | 138 ---
drivers/gpu/drm/i915/intel_ddi.c | 3 +
drivers/gpu/drm/i915/intel_dp.c | 22 +++
drivers/gpu/drm/i915/intel_drv.h | 2 +
5 files changed, 162 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 8f68678..5fd5bf3 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1551,6 +1551,11 @@ struct drm_i915_private {
struct i915_runtime_pm pm;
+ struct intel_digital_port *hpd_irq_port[I915_MAX_PORTS];
+ u32 long_hpd_port_mask;
+ u32 short_hpd_port_mask;
+ struct work_struct dig_port_work;
+
/* Old dri1 support infrastructure, beware the dragons ya fools entering
* here! */
struct i915_dri1_state dri1;
diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index cbf31cb..1817eaa 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -1096,6 +1096,53 @@ static bool intel_hpd_irq_event(struct drm_device *dev,
return true;
}
+static void i915_digport_work_func(struct work_struct *work)
+{
+ struct drm_i915_private *dev_priv =
+ container_of(work, struct drm_i915_private, dig_port_work);
+ unsigned long irqflags;
+ u32 long_port_mask, short_port_mask;
+ struct intel_digital_port *intel_dig_port;
+ int i, ret;
+ u32 old_bits = 0;
+
+ spin_lock_irqsave(&dev_priv->irq_lock, irqflags);
+ long_port_mask = dev_priv->long_hpd_port_mask;
+ dev_priv->long_hpd_port_mask = 0;
+ short_port_mask = dev_priv->short_hpd_port_mask;
+ dev_priv->short_hpd_port_mask = 0;
+ spin_unlock_irqrestore(&dev_priv->irq_lock, irqflags);
+
+ for (i = 0; i < I915_MAX_PORTS; i++) {
+ bool valid = false;
+ bool long_hpd = false;
+ intel_dig_port = dev_priv->hpd_irq_port[i];
+ if (!intel_dig_port || !intel_dig_port->hpd_pulse)
+ continue;
+
+ if (long_port_mask & (1 << i)) {
+ valid = true;
+ long_hpd = true;
+ } else if (short_port_mask & (1 << i))
+ valid = true;
+
+ if (valid) {
+ ret = intel_dig_port->hpd_pulse(intel_dig_port,
long_hpd);
+ if (ret == true) {
+ /* if we get true fallback to old school hpd */
+ old_bits |= (1 << intel_dig_port->base.hpd_pin);
+ }
+ }
+ }
+
+ if (old_bits) {
+ spin_lock_irqsave(&dev_priv->irq_lock, irqflags);
+ dev_priv->hpd_event_bits |= old_bits;
+ spin_unlock_irqrestore(&dev_priv->irq_lock, irqflags);
+ schedule_work(&dev_priv->hotplug_work);
+ }
+}
+
/*
* Handle hotplug events outside the interrupt handler proper.
*/
@@ -1520,23 +1567,82 @@ static irqreturn_t gen8_gt_irq_handler(struct
drm_device *dev,
#define HPD_STORM_DETECT_PERIOD 1000
#define HPD_STORM_THRESHOLD 5
+static int port_to_hotplug_shift(enum port port)
+{
+ switch (port) {
+ case PORT_A:
+ case PORT_E:
+ default:
+ return -1;
+ case PORT_B:
+ return 0;
+ case PORT_C:
+ return 8;
+ case PORT_D:
+ return 16;
+ }
+}
+
+static inline enum port get_port_from_pin(enum hpd_pin pin)
+{
+ switch (pin) {
+ case HPD_PORT_B:
+ return PORT_B;
+ case HPD_PORT_C:
+ return PORT_C;
+ case HPD_PORT_D:
+ return PORT_D;
+ default:
+ return PORT_A; /* no hpd */
+ }
+}
+
static inline void intel_hpd_irq_handler(struct drm_device *dev,
u32 hotplug_trigger,
+u32 dig_hotplug_reg,
const u32 *hpd)
{
struct drm_i915_private *dev_priv = dev->dev_private;
int i;
+ enum port port;
bool storm_detected = false;
+ bool queue_dig = false, queue_hp = fals
Re: [Intel-gfx] [PATCH v2 01/16] drm/i915: Keep vblank interrupts enabled while enabling/disabling planes
On Mon, May 26, 2014 at 7:26 PM, Daniel Vetter wrote: > On Thu, May 22, 2014 at 05:48:06PM +0300, ville.syrj...@linux.intel.com wrote: >> From: Ville Syrjälä >> >> Because of the upcoming vblank interrupt driven watermark update >> mechanism we will have use for vblank interrupts during plane >> enabling/disabling. So don't call drm_vblank_off() until planes >> are off, and call drm_vblank_on() just before we start to enable >> the planes. Since watermark and display control registers are double buffered both of them get updated on next blank and hence in sync. Can you let me know the need for vblank driven watermark updates? Thanks and Regards, Arun R Murthy --- ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] Patch "drm/i915: Disable self-refresh for untiled fbs on i915gm" has been added to the 3.14-stable tree
This is a note to let you know that I've just added the patch titled
drm/i915: Disable self-refresh for untiled fbs on i915gm
to the 3.14-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary
The filename of the patch is:
drm-i915-disable-self-refresh-for-untiled-fbs-on-i915gm.patch
and it can be found in the queue-3.14 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let know about it.
>From daniel.vet...@ffwll.ch Tue Jun 3 23:12:52 2014
From: Daniel Vetter
Date: Wed, 21 May 2014 11:07:22 +0200
Subject: drm/i915: Disable self-refresh for untiled fbs on i915gm
To: sta...@vger.kernel.org
Cc: Intel Graphics Development , Daniel Vetter
, Ville Syrjälä , Chris
Wilson , Krzysztof Mazur ,
Jani Nikula
Message-ID: <1400663245-15601-2-git-send-email-daniel.vet...@ffwll.ch>
From: Daniel Vetter
This is commit 2ab1bc9df01dbc19b55b2271100db7 upstream.
Apparently it doesn't work. X-tiled self-refresh works flawlessly
otoh. Apparently X still works correctly with linear framebuffers, so
might just be an issue with the initial modeset. It's unclear whether
this just borked wm setup from our side or a hw restriction, but just
disabling gets things going.
Note that this regression was only brought to light with
commit 3f2dc5ac05714711fc14f2bf0ee5e42d5c08c581
Author: Ville Syrjälä
Date: Fri Jan 10 14:06:47 2014 +0200
drm/i915: Fix 915GM self-refresh enable/disable
before that self-refresh for i915GM didn't work at all.
Kudos to Ville for spotting a little bug in the original patch I've
attached to the bug.
Cc: Ville Syrjälä
Cc: Chris Wilson
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=76103
Tested-by: Krzysztof Mazur
Cc: Krzysztof Mazur
Reviewed-by: Ville Syrjälä
Signed-off-by: Daniel Vetter
[Jani: rebase on top of drm-next with primary plane support.]
Signed-off-by: Jani Nikula
Signed-off-by: Greg Kroah-Hartman
---
drivers/gpu/drm/i915/intel_pm.c | 10 ++
1 file changed, 10 insertions(+)
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -1539,6 +1539,16 @@ static void i9xx_update_wm(struct drm_cr
DRM_DEBUG_KMS("FIFO watermarks - A: %d, B: %d\n", planea_wm, planeb_wm);
+ if (IS_I915GM(dev) && enabled) {
+ struct intel_framebuffer *fb;
+
+ fb = to_intel_framebuffer(enabled->fb);
+
+ /* self-refresh seems busted with untiled */
+ if (fb->obj->tiling_mode == I915_TILING_NONE)
+ enabled = NULL;
+ }
+
/*
* Overlay gets an aggressive default since video jitter is bad.
*/
Patches currently in stable-queue which might be from daniel.vet...@ffwll.ch are
queue-3.14/drm-i915-don-t-warn-nor-handle-unexpected-hpd-interrupts-on-gmch-platforms.patch
queue-3.14/drm-i915-fix-unsafe-loop-iteration-over-vma-whilst-unbinding-them.patch
queue-3.14/drm-i915-disable-self-refresh-for-untiled-fbs-on-i915gm.patch
queue-3.14/drm-i915-don-t-check-gmch-state-on-inherited-configs.patch
queue-3.14/drm-i915-break-encoder-crtc-link-separately-in-intel_sanitize_crtc.patch
queue-3.14/drm-i915-quirk-invert-brightness-for-acer-aspire-5336.patch
queue-3.14/drm-i915-move-power-domain-init-earlier-during-system-resume.patch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] Patch "drm/i915: quirk invert brightness for Acer Aspire 5336" has been added to the 3.14-stable tree
This is a note to let you know that I've just added the patch titled
drm/i915: quirk invert brightness for Acer Aspire 5336
to the 3.14-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary
The filename of the patch is:
drm-i915-quirk-invert-brightness-for-acer-aspire-5336.patch
and it can be found in the queue-3.14 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let know about it.
From daniel.vet...@ffwll.ch Tue Jun 3 23:14:20 2014
From: Daniel Vetter
Date: Wed, 21 May 2014 11:07:25 +0200
Subject: drm/i915: quirk invert brightness for Acer Aspire 5336
To: sta...@vger.kernel.org
Cc: Intel Graphics Development , Jani Nikula
, Daniel Vetter
Message-ID: <1400663245-15601-5-git-send-email-daniel.vet...@ffwll.ch>
From: Jani Nikula
This is commit 0f540c3a7cfb91c9d7a19eb0c95c24 upstream.
Since
commit ee1452d7458451a7508e0663553ce88d63958157
Author: Jani Nikula
Date: Fri Sep 20 15:05:30 2013 +0300
drm/i915: assume all GM45 Acer laptops use inverted backlight PWM
failed and was later reverted in
commit be505f643925e257087247b996cd8ece787c12af
Author: Alexander van Heukelum
Date: Sat Dec 28 21:00:39 2013 +0100
Revert "drm/i915: assume all GM45 Acer laptops use inverted backlight PWM"
fix the individual broken machine instead.
Note to backporters:
http://patchwork.freedesktop.org/patch/17837/
is the patch you want for 3.13 and older.
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=54171
Reference: http://mid.gmane.org/dub115-w7628c7c710ea51aa110cd4a5...@phx.gbl
Signed-off-by: Jani Nikula
Reviewed-by: Ville Syrjälä
[danvet: Patch mangling for 3.14 plus adding the link to the original
for 3.13.]
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/i915/intel_display.c |3 +++
1 file changed, 3 insertions(+)
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -10862,6 +10862,9 @@ static struct intel_quirk intel_quirks[]
/* Acer Aspire 4736Z */
{ 0x2a42, 0x1025, 0x0260, quirk_invert_brightness },
+ /* Acer Aspire 5336 */
+ { 0x2a42, 0x1025, 0x048a, quirk_invert_brightness },
+
/* Dell XPS13 HD Sandy Bridge */
{ 0x0116, 0x1028, 0x052e, quirk_no_pcm_pwm_enable },
/* Dell XPS13 HD and XPS13 FHD Ivy Bridge */
Patches currently in stable-queue which might be from daniel.vet...@ffwll.ch are
queue-3.14/drm-i915-don-t-warn-nor-handle-unexpected-hpd-interrupts-on-gmch-platforms.patch
queue-3.14/drm-i915-fix-unsafe-loop-iteration-over-vma-whilst-unbinding-them.patch
queue-3.14/drm-i915-disable-self-refresh-for-untiled-fbs-on-i915gm.patch
queue-3.14/drm-i915-don-t-check-gmch-state-on-inherited-configs.patch
queue-3.14/drm-i915-break-encoder-crtc-link-separately-in-intel_sanitize_crtc.patch
queue-3.14/drm-i915-quirk-invert-brightness-for-acer-aspire-5336.patch
queue-3.14/drm-i915-move-power-domain-init-earlier-during-system-resume.patch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] drm/i915 stable backports
On Wed, May 21, 2014 at 11:07:21AM +0200, Daniel Vetter wrote: > Hi Greg, > > This is a set of drm/i915 patches which didn't apply cleanly on for 3.14. All > absed on 3.14.4. I've left out the bdw patches for now and will sign up > someone > else for that task. Thanks for the patches, all now applied. greg k-h ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] Patch "drm/i915: Fix unsafe loop iteration over vma whilst unbinding them" has been added to the 3.14-stable tree
This is a note to let you know that I've just added the patch titled
drm/i915: Fix unsafe loop iteration over vma whilst unbinding them
to the 3.14-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary
The filename of the patch is:
drm-i915-fix-unsafe-loop-iteration-over-vma-whilst-unbinding-them.patch
and it can be found in the queue-3.14 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let know about it.
>From daniel.vet...@ffwll.ch Tue Jun 3 23:13:34 2014
From: Daniel Vetter
Date: Wed, 21 May 2014 11:07:24 +0200
Subject: drm/i915: Fix unsafe loop iteration over vma whilst unbinding them
To: sta...@vger.kernel.org
Cc: Intel Graphics Development , Chris Wilson
, Ben Widawsky , Daniel Vetter
Message-ID: <1400663245-15601-4-git-send-email-daniel.vet...@ffwll.ch>
From: Chris Wilson
This is commit df6f783a4ef6790780a67c491897ac upstream.
On non-LLC platforms, when changing the cache level of an object, we may
need to unbind it so that prefetching across page boundaries does not
cross into a different memory domain. This requires us to unbind
conflicting vma, but we did so iterating over the objects vma in an
unsafe manner (as the list was being modified as we iterated).
The regression was introduced in
commit 3089c6f239d7d2c4cb2dd5c353e8984cf79af1d7
Author: Ben Widawsky
Date: Wed Jul 31 17:00:03 2013 -0700
drm/i915: make caching operate on all address spaces
apparently as far back as v3.12-rc1, but it has only just begun to
trigger real world bug reports.
Reported-and-tested-by: Nikolay Martynov
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=76384
Signed-off-by: Chris Wilson
Cc: Ben Widawsky
Signed-off-by: Daniel Vetter
Signed-off-by: Greg Kroah-Hartman
---
drivers/gpu/drm/i915/i915_gem.c |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -3529,7 +3529,7 @@ int i915_gem_object_set_cache_level(stru
{
struct drm_device *dev = obj->base.dev;
drm_i915_private_t *dev_priv = dev->dev_private;
- struct i915_vma *vma;
+ struct i915_vma *vma, *next;
int ret;
if (obj->cache_level == cache_level)
@@ -3540,7 +3540,7 @@ int i915_gem_object_set_cache_level(stru
return -EBUSY;
}
- list_for_each_entry(vma, &obj->vma_list, vma_link) {
+ list_for_each_entry_safe(vma, next, &obj->vma_list, vma_link) {
if (!i915_gem_valid_gtt_space(dev, &vma->node, cache_level)) {
ret = i915_vma_unbind(vma);
if (ret)
Patches currently in stable-queue which might be from daniel.vet...@ffwll.ch are
queue-3.14/drm-i915-don-t-warn-nor-handle-unexpected-hpd-interrupts-on-gmch-platforms.patch
queue-3.14/drm-i915-fix-unsafe-loop-iteration-over-vma-whilst-unbinding-them.patch
queue-3.14/drm-i915-disable-self-refresh-for-untiled-fbs-on-i915gm.patch
queue-3.14/drm-i915-don-t-check-gmch-state-on-inherited-configs.patch
queue-3.14/drm-i915-break-encoder-crtc-link-separately-in-intel_sanitize_crtc.patch
queue-3.14/drm-i915-quirk-invert-brightness-for-acer-aspire-5336.patch
queue-3.14/drm-i915-move-power-domain-init-earlier-during-system-resume.patch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] Patch "drm/i915: move power domain init earlier during system resume" has been added to the 3.14-stable tree
This is a note to let you know that I've just added the patch titled
drm/i915: move power domain init earlier during system resume
to the 3.14-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary
The filename of the patch is:
drm-i915-move-power-domain-init-earlier-during-system-resume.patch
and it can be found in the queue-3.14 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let know about it.
>From daniel.vet...@ffwll.ch Tue Jun 3 23:13:18 2014
From: Daniel Vetter
Date: Wed, 21 May 2014 11:07:23 +0200
Subject: drm/i915: move power domain init earlier during system resume
To: sta...@vger.kernel.org
Cc: Intel Graphics Development , Imre Deak
, Daniel Vetter
Message-ID: <1400663245-15601-3-git-send-email-daniel.vet...@ffwll.ch>
From: Imre Deak
This is commit 76c4b250080fff6e4befaa36199424 upstream.
During resume the intel hda audio driver depends on the i915 driver
reinitializing the audio power domain. Since the order of calling the
i915 resume handler wrt. that of the audio driver is not guaranteed,
move the power domain reinitialization step to the resume_early
handler. This is guaranteed to run before the resume handler of any
other driver.
The power domain initialization in turn requires us to enable the i915
pci device first, so move that part earlier too.
Accordingly disabling of the i915 pci device should happen after the
audio suspend handler ran. So move the disabling later from the i915
resume handler to the resume_late handler.
v2:
- move intel_uncore_sanitize/early_sanitize earlier too, so they don't
get reordered wrt. intel_power_domains_init_hw()
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=76152
Signed-off-by: Imre Deak
Reviewed-by: Takashi Iwai
[danvet: Add cc: stable and loud comments that this is just a hack.]
[danvet: Fix "Should it be static?" sparse warning reported by Wu
Fengguang's kbuilder.]
Signed-off-by: Daniel Vetter
Signed-off-by: Greg Kroah-Hartman
---
drivers/gpu/drm/i915/i915_drv.c | 90 +---
1 file changed, 75 insertions(+), 15 deletions(-)
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -614,15 +614,20 @@ static void intel_resume_hotplug(struct
drm_helper_hpd_irq_event(dev);
}
+static int i915_drm_thaw_early(struct drm_device *dev)
+{
+ intel_uncore_early_sanitize(dev);
+ intel_uncore_sanitize(dev);
+ intel_power_domains_init_hw(dev);
+
+ return 0;
+}
+
static int __i915_drm_thaw(struct drm_device *dev, bool restore_gtt_mappings)
{
struct drm_i915_private *dev_priv = dev->dev_private;
int error = 0;
- intel_uncore_early_sanitize(dev);
-
- intel_uncore_sanitize(dev);
-
if (drm_core_check_feature(dev, DRIVER_MODESET) &&
restore_gtt_mappings) {
mutex_lock(&dev->struct_mutex);
@@ -630,8 +635,6 @@ static int __i915_drm_thaw(struct drm_de
mutex_unlock(&dev->struct_mutex);
}
- intel_power_domains_init_hw(dev);
-
i915_restore_state(dev);
intel_opregion_setup(dev);
@@ -700,19 +703,33 @@ static int i915_drm_thaw(struct drm_devi
return __i915_drm_thaw(dev, true);
}
-int i915_resume(struct drm_device *dev)
+static int i915_resume_early(struct drm_device *dev)
{
- struct drm_i915_private *dev_priv = dev->dev_private;
- int ret;
-
if (dev->switch_power_state == DRM_SWITCH_POWER_OFF)
return 0;
+ /*
+* We have a resume ordering issue with the snd-hda driver also
+* requiring our device to be power up. Due to the lack of a
+* parent/child relationship we currently solve this with an early
+* resume hook.
+*
+* FIXME: This should be solved with a special hdmi sink device or
+* similar so that power domains can be employed.
+*/
if (pci_enable_device(dev->pdev))
return -EIO;
pci_set_master(dev->pdev);
+ return i915_drm_thaw_early(dev);
+}
+
+int i915_resume(struct drm_device *dev)
+{
+ struct drm_i915_private *dev_priv = dev->dev_private;
+ int ret;
+
/*
* Platforms with opregion should have sane BIOS, older ones (gen3 and
* earlier) need to restore the GTT mappings since the BIOS might clear
@@ -726,6 +743,14 @@ int i915_resume(struct drm_device *dev)
return 0;
}
+static int i915_resume_legacy(struct drm_device *dev)
+{
+ i915_resume_early(dev);
+ i915_resume(dev);
+
+ return 0;
+}
+
/**
* i915_reset - reset chip after a hang
* @dev: drm device to reset
@@ -846,7 +871,6 @@ static int i915_pm_suspend(struct device
{
struct pci_dev *pdev = to_pci_dev(dev);
struct drm_device *drm_dev = pci_get_drvdata(pdev);
- int error;
if (!drm_dev || !drm_dev->dev_privat
