On Fri, Dec 20, 2013 at 07:05:10AM +0100, Daniel Vetter wrote:
> On Fri, Dec 20, 2013 at 12:22 AM, Ben Widawsky
> wrote:
> > ctx = i915_gem_context_get(file->driver_priv, args->ctx_id);
> > - if (IS_ERR(ctx)) {
> > + if (IS_ERR_OR_NULL(ctx)) {
>
> We now have half the callers
On Thu, 19 Dec 2013, Paulo Zanoni wrote:
> From: Paulo Zanoni
>
> Depending on the HW gen and the connector type, the pipe won't start
> running right after we call intel_enable_pipe, so that
> intel_wait_for_vblank call we currently have will just sit there for
> the full 50ms timeout. So this p
On Thu, Dec 05, 2013 at 08:50:21AM +0100, Daniel Vetter wrote:
> On Thu, Dec 5, 2013 at 3:32 AM, Matthew Garrett wrote:
> > We had problems with the Intel backlight driver the last time we tried
> > this, so let's push this through their tree for testing first? Cc:ed
> > intel-gfx and Daniel Vette
On Fri, Dec 20, 2013 at 12:22 AM, Ben Widawsky
wrote:
> ctx = i915_gem_context_get(file->driver_priv, args->ctx_id);
> - if (IS_ERR(ctx)) {
> + if (IS_ERR_OR_NULL(ctx)) {
We now have half the callers check for IS_ERR and the others not.
Afaics i915_gem_context_get can only ret
On Dec-19-2013 5:21 PM, Jani Nikula wrote:
> On Tue, 17 Dec 2013, Vandana Kannan wrote:
>> From: Pradeep Bhat
>>
>> This patch and finds out the lowest refresh rate supported for the resolution
>> same as the fixed_mode, based on the implementaion find_panel_downclock.
>> It also checks the VBT f
If we look up an invalid context ID, the idr will return NULL. The ptr
is unconditionally dereferenced afterwards causing a problem.
Note that if the context does not exist, we still return success. This
appears to be the behavior desired by gem_reset_stats --subtest ban
Introduced in v3 of
commi
2013/12/19 Daniel Vetter :
> On Thu, Dec 19, 2013 at 7:30 PM, Jesse Barnes
> wrote:
>> So we have these runtime_pm_get/put calls all over now. Is the plan to
>> convert those to specific wells as we add support for new platforms so
>> we can have fine grained well control rather than just global
On Thu, Dec 19, 2013 at 7:30 PM, Jesse Barnes wrote:
> So we have these runtime_pm_get/put calls all over now. Is the plan to
> convert those to specific wells as we add support for new platforms so
> we can have fine grained well control rather than just global control?
> I guess I need to dig o
On Thu, Dec 19, 2013 at 10:12 PM, Paulo Zanoni wrote:
> From: Paulo Zanoni
>
> When I forked haswell_crtc_enable I copied all the code from
> ironlake_crtc_enable. The last piece of the function contains a big
> comment with a call to intel_wait_for_vblank. After this fork, we
> rearranged the Ha
From: Paulo Zanoni
When I forked haswell_crtc_enable I copied all the code from
ironlake_crtc_enable. The last piece of the function contains a big
comment with a call to intel_wait_for_vblank. After this fork, we
rearranged the Haswell code so that it enables the planes as the very
last step of
From: Paulo Zanoni
Because on Haswell, the pipe is never running at this point, so we hit
the 50ms timeout waiting for nothing. We already have two other places
where we wait for vblanks on haswell_crtc_enable, so we're safe.
This gets us rid of one instance of "vblank wait timed out" for each
m
From: Paulo Zanoni
Depending on the HW gen and the connector type, the pipe won't start
running right after we call intel_enable_pipe, so that
intel_wait_for_vblank call we currently have will just sit there for
the full 50ms timeout. So this patch adds an argument that will allow
us to avoid the
When fastbooting, we read out the pipe timings early on, and then in a
panel fitted config, disable the fitter later. But we weren't updating
the pipe src h/w, which meant the mouse cursor was clipped to the
pfitted size rather than the native size set later. Fix that up so the
cursor is visible
On Thu, 19 Dec 2013 09:38:45 -0800
Jesse Barnes wrote:
> On Thu, 19 Dec 2013 14:29:43 -0200
> Paulo Zanoni wrote:
>
> > From: Paulo Zanoni
> >
> > Function ironlake_wait_panel_off should just wait for the power off
> > delay, while function ironlake_wait_panel_power_cycle should wait for
> >
Hi Daniel,
Quick shot in the dark: Can you please try the below diff?
If that doesn't work please remove the locking in that function completely
(i.e. remove the calls to drm_modset_lock|unlock_all).
If that doesn't help please compile a pristine -nightly with lockdep
(CONFIG_PROVE_LOCKING) re
On Thu, 19 Dec 2013 11:54:52 -0200
Paulo Zanoni wrote:
> From: Paulo Zanoni
>
> We'll need this when we merge PC8 and Runtime PM: the PC8
> enable/disable functions need that lock.
>
> Also, it's good practice to not hold a lock for longer than strictly
> needed.
>
> Signed-off-by: Paulo Zano
On Thu, 19 Dec 2013 14:29:44 -0200
Paulo Zanoni wrote:
> From: Paulo Zanoni
>
> Because we already do the wait in software: see
> ironlake_wait_backlight_on and ironlake_edp_wait_backlight_off.
>
> For the "backlight on" delay, even BSpec says we need to program 0x1
> to PP_ON_DELAYS 12:0.
>
On Thu, 19 Dec 2013 14:29:43 -0200
Paulo Zanoni wrote:
> From: Paulo Zanoni
>
> Function ironlake_wait_panel_off should just wait for the power off
> delay, while function ironlake_wait_panel_power_cycle should wait for
> the panel cycle (that's required after we turn the panel off, before
> we
On Thu, 19 Dec 2013 14:29:42 -0200
Paulo Zanoni wrote:
> From: Paulo Zanoni
>
> I like how the macros are nicely column-aligned, so we can properly
> compare what each macro waits for, but a column full of zeroes doesn't
> really help anything: it just makes the lines bigger, and they're
> alre
On Thu, 19 Dec 2013 14:29:41 -0200
Paulo Zanoni wrote:
> + * Reset everything, otherwise when suspend/resume gets very fast, we
> + * delay the resume based on the values that were set when we were still
> + * suspending.
> + */
> + intel_dp->last_power_on = tmp_jiffies -
On Thu, 19 Dec 2013 14:29:40 -0200
Paulo Zanoni wrote:
> From: Paulo Zanoni
>
> The eDP spec defines some points where after you do action A, you have
> to wait some time before action B. The thing is that in our driver
> action B does not happen exactly after action A, but we still use
> mslee
On Thu, 19 Dec 2013 14:29:39 -0200
Paulo Zanoni wrote:
> From: Paulo Zanoni
>
> Our driver has two different ways of waiting for panel power
> sequencing delays. One of these ways is through
> ironlake_wait_panel_status, which implicitly uses the values written
> to our registers. The other way
From: Paulo Zanoni
Hi
These patches save a lot of time on our eDP panel power sequencing times. We
were doing a lot of needless waits, so now our load times should be much
shorter.
This series should improve a little bit our driver load time, and it should
greatly improve our suspend time. The
From: Paulo Zanoni
The eDP code records a few timestamps containing the last time we took
some actions, because we need to wait before doing some other actions.
The problem is that if we store a timestamp when suspending and then
look at it when resuming, we'll ignore the unknown amount of time w
From: Paulo Zanoni
I like how the macros are nicely column-aligned, so we can properly
compare what each macro waits for, but a column full of zeroes doesn't
really help anything: it just makes the lines bigger, and they're
already way past 80 columns. I imagine this column was used in the
past,
From: Paulo Zanoni
The eDP spec defines some points where after you do action A, you have
to wait some time before action B. The thing is that in our driver
action B does not happen exactly after action A, but we still use
msleep() calls directly. What this patch does is that we record the
timest
From: Paulo Zanoni
Function ironlake_wait_panel_off should just wait for the power off
delay, while function ironlake_wait_panel_power_cycle should wait for
the panel cycle (that's required after we turn the panel off, before
we enable it again).
The problem is that, currently, ironlake_wait_pan
From: Paulo Zanoni
Because we already do the wait in software: see
ironlake_wait_backlight_on and ironlake_edp_wait_backlight_off.
For the "backlight on" delay, even BSpec says we need to program 0x1
to PP_ON_DELAYS 12:0.
For the "backlight off" delay, if we don't do the same thing, when we
cal
From: Paulo Zanoni
Our driver has two different ways of waiting for panel power
sequencing delays. One of these ways is through
ironlake_wait_panel_status, which implicitly uses the values written
to our registers. The other way is through the functions that call
intel_wait_until_after, and on th
On Thu, Dec 19, 2013 at 04:46:17PM +0100, Daniel Vetter wrote:
> On Thu, Dec 19, 2013 at 04:07:35PM +0100, Thomas Richter wrote:
> > Hi Daniel, hi folks,
> >
> > here is more debug output from the blank screen/hang on the i830
> > based laptop:
>
> Quick shot in the dark: Can you please try the b
On Thu, Dec 19, 2013 at 04:07:35PM +0100, Thomas Richter wrote:
> Hi Daniel, hi folks,
>
> here is more debug output from the blank screen/hang on the i830
> based laptop:
Quick shot in the dark: Can you please try the below diff?
If that doesn't work please remove the locking in that function c
Hi Daniel, hi folks,
here is more debug output from the blank screen/hang on the i830 based
laptop:
Dec 19 15:48:19 tyleet kernel: [ 10.919155] [drm:drm_pci_init],
Dec 19 15:48:19 tyleet kernel: [ 11.317545] lib80211_crypt: registered
algorithm 'NULL'
Dec 19 15:48:19 tyleet kernel: [ 1
Hi Daniel, hi folks,
back from a couple of business trips, so finally some time to look into
the i830 support on this old laptop.
Sorry to say that the current drm-nightly does not work at all. It just
generates a hang, resulting in a black screen and nothing else. All you
can do there is to
From: Paulo Zanoni
We already get runtime PM references, and PC8 is now part of runtime
PM, so this is enough.
Signed-off-by: Paulo Zanoni
---
drivers/gpu/drm/i915/i915_drv.c | 5 -
1 file changed, 5 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv
From: Paulo Zanoni
After we removed all the intermediate abstractions, we can rename
these functions to just hsw_{en,dis}able_pc8.
Signed-off-by: Paulo Zanoni
---
drivers/gpu/drm/i915/i915_drv.c | 4 ++--
drivers/gpu/drm/i915/intel_display.c | 4 ++--
drivers/gpu/drm/i915/intel_drv.h
From: Paulo Zanoni
Because we already get/put runtime PM every time we get/put any power
domain, and now PC8 and runtime PM are the same thing.
With this, we can also now kill the hsw_{en,dis}able_package_c8
functions.
Signed-off-by: Paulo Zanoni
---
drivers/gpu/drm/i915/intel_display.c | 20
From: Paulo Zanoni
When other platforms add runtime PM support they will also need to
disable interrupts, so move the variable to the runtime PM struct.
Signed-off-by: Paulo Zanoni
---
drivers/gpu/drm/i915/i915_debugfs.c | 6
drivers/gpu/drm/i915/i915_drv.h | 14 -
drivers/
From: Paulo Zanoni
Function intel_init_runtime_pm is supposed to start allowing runtime
PM from that point, but it's called very late on the driver
initialization code, to prevent the driver from trying to suspend
while still initializing. The problem is that variables are accessed
earlier than t
From: Paulo Zanoni
The only remaining field of the struct was the lock, which was unused.
Signed-off-by: Paulo Zanoni
---
drivers/gpu/drm/i915/i915_drv.h | 6 --
drivers/gpu/drm/i915/intel_pm.c | 1 -
2 files changed, 7 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/g
From: Paulo Zanoni
After the latest changes, the indirection is useless.
Signed-off-by: Paulo Zanoni
---
drivers/gpu/drm/i915/intel_display.c | 16 ++--
1 file changed, 2 insertions(+), 14 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel
From: Paulo Zanoni
It was just being used on debugfs and on a WARN inside
hsw_set_power_well. But now that we PC8 is part of runtime PM and we
get/put runtime PM when we get/put any power domain, we shouldn't need
the WARN anymore.
Signed-off-by: Paulo Zanoni
---
drivers/gpu/drm/i915/i915_debu
From: Paulo Zanoni
When we merge PC8 and runtime PM, these new functions are going to be
called by the runtime suspend/resume functions, and their callers are
going to be removed.
Signed-off-by: Paulo Zanoni
---
drivers/gpu/drm/i915/intel_display.c | 64 +---
1
From: Paulo Zanoni
We had these intel_aux_display_runtime_{get,put} abstractions that
would just get/put PC8 references, but now that runtime PM and PC8
are the same stuff, we just need the runtime PM references, so just
get/put runtime PM directly, because that's what the rest of our code
does.
From: Paulo Zanoni
Now that PC8 got much simpler, there are less things to document.
Also, runtime PM already has a nice documentation, so we don't need to
re-explain it on our driver.
Signed-off-by: Paulo Zanoni
---
drivers/gpu/drm/i915/i915_drv.h | 56 +++
From: Paulo Zanoni
Since after the latest patches it's only being used to prevent
getting/putting the runtime PM refcount.
Signed-off-by: Paulo Zanoni
---
drivers/gpu/drm/i915/i915_debugfs.c | 1 -
drivers/gpu/drm/i915/i915_drv.h | 1 -
drivers/gpu/drm/i915/intel_display.c | 14 ---
From: Paulo Zanoni
Hi
This patch series makes the PC8 feature become part of the runtime PM feature.
They won't be 2 separate features anymore, but just one. You can find some good
arguments for this in the commit message of patch 5.
- Patch 1 is just a bikeshed that can be discarded if neede
From: Paulo Zanoni
Any power domain will require the HW to be in PCI D0 state, so just do
the simple thing.
Signed-off-by: Paulo Zanoni
---
drivers/gpu/drm/i915/intel_pm.c | 4
1 file changed, 4 insertions(+)
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
From: Paulo Zanoni
To modeset_update_crtc_power_domains, since this function is
responsible for updating all the power domains of all CRTCs after a
modeset. In the future we should also run this function on all
platforms, not just Haswell.
Signed-off-by: Paulo Zanoni
---
drivers/gpu/drm/i915/i
From: Paulo Zanoni
Because PC8 is part of runtime PM, and platforms without PC8 will need
gpu_idle for runtime PM support.
Signed-off-by: Paulo Zanoni
---
drivers/gpu/drm/i915/i915_debugfs.c | 1 -
drivers/gpu/drm/i915/i915_drv.h | 3 ++-
drivers/gpu/drm/i915/intel_display.c | 32 +
From: Paulo Zanoni
We'll need this when we merge PC8 and Runtime PM: the PC8
enable/disable functions need that lock.
Also, it's good practice to not hold a lock for longer than strictly
needed.
Signed-off-by: Paulo Zanoni
---
drivers/gpu/drm/i915/i915_debugfs.c | 12 +++-
1 file chan
From: Paulo Zanoni
Currently, when our driver becomes idle for i915_pc8_timeout (default:
5s) we enable PC8, so we save some power, but not everything we can.
Then, while PC8 is enabled, if we stay idle for more
autosuspend_delay_ms (default: 10s) we'll enter runtime PM and put the
graphics devic
From: Paulo Zanoni
To solve a chicken-and-egg problem. Currently when we get/put
forcewake we also get/put runtime PM and this works fine because the
runtime PM code doesn't need forcewake. But we're going to merge PC8
and runtime PM into a single feature, and the PC8 code (the LCPLL
code) does n
From: Paulo Zanoni
The requirements_met variable was used to track two things: enabled
CRTCs and the power well. After the latest chagnes, we get a runtime
PM reference whenever we get any of the power domains, and we get
power domains when we enable CRTCs or the power well, so we should
already
On Thu, Dec 19, 2013 at 5:04 AM, Vandana Kannan
wrote:
> Adding picture aspect ratio for CEA modes based on CEA-861D Table 3 or
> CEA-861E Table 4. This is useful for filling up the detail in AVI
> infoframe.
>
> v2: Ville's review comments incorporated
> Added picture aspect ratio as part of edid
Use helper functions to simplify _DSM related code in i915 driver.
Function intel_dsm() is used to check functions supported by ACPI _DSM
method, but it has strange check for special value 0x8002. After
digging into nouveau driver, I think the check is copied from nouveau
driver and is useless
Copying the appropriate mailing list. Thanks for the report!
> From: Patrick McMunn [mailto:doctorwho...@gmail.com]
> Sent: Thursday, December 19, 2013 7:59 AM
> To: Zanoni, Paulo R
> Subject: Minor bug in intel-gpu-tools
>
> I noticed that if I run "./configure --enable-shader-debugger", the co
On Tue, 17 Dec 2013, Vandana Kannan wrote:
> From: Pradeep Bhat
>
> This patch and finds out the lowest refresh rate supported for the resolution
> same as the fixed_mode, based on the implementaion find_panel_downclock.
> It also checks the VBT fields to see if panel supports seamless DRRS or no
Adding picture aspect ratio for CEA modes based on CEA-861D Table 3 or
CEA-861E Table 4. This is useful for filling up the detail in AVI
infoframe.
v2: Ville's review comments incorporated
Added picture aspect ratio as part of edid_cea_modes instead of DRM_MODE
Signed-off-by: Vandana Kannan
Revi
Adding support to detect display idleness by tracking page flip from
user space. Switch to low refresh rate is triggered after 2 seconds of
idleness. The delay is configurable. If there is a page flip or call to
update the plane, then high refresh rate is applied.
The feature is not used in dual-di
From: Pradeep Bhat
This patch computes and stored 2nd M/N/TU for switching to different
refresh rate dynamically. PIPECONF_EDP_RR_MODE_SWITCH bit helps toggle
between alternate refresh rates programmed in 2nd M/N/TU registers.
v2: Daniel's review comments
Computing M2/N2 in compute_config and st
From: Pradeep Bhat
This patch reads the DRRS support and Mode type from VBT fields.
The read information will be stored in VBT struct during BIOS
parsing. The above functionality is needed for decision making
whether DRRS feature is supported in i915 driver for eDP panels.
This information helps
Dynamic Refresh Rate Switching (DRRS) is a power conservation feature which
enabled swtiching between low and high refresh rates based on the usage
scenario. This feature is applciable for internal eDP panel. Indication that
the panel supports DRRS is given by the panel EDID, whic
For Broadwell, there is one instance of Transcoder MN values per transcoder.
For dynamic switching between multiple refreshr rates, M/N values may be
reprogrammed on the fly. Link N programming triggers update of all data and
link M & N registers and the new M/N values will be used in the next fram
From: Pradeep Bhat
This patch and finds out the lowest refresh rate supported for the resolution
same as the fixed_mode, based on the implementaion find_panel_downclock.
It also checks the VBT fields to see if panel supports seamless DRRS or not.
Based on above data it marks whether eDP panel sup
64 matches
Mail list logo
