On Fri, Nov 6, 2015 at 5:38 AM, Chris Wilson wrote:
> On Thu, Nov 05, 2015 at 10:17:56AM -0800, Jesse Barnes wrote:
>> On 11/05/2015 09:51 AM, Kristian Høgsberg wrote:
>> > On Tue, Oct 6, 2015 at 3:53 AM, Chris Wilson
>> > wrote:
>> >> Userspace can pass in an offset that it presumes the object
On 11/06/2015 02:09 PM, Chris Wilson wrote:
On Fri, Nov 06, 2015 at 01:56:59PM -0800, yu@intel.com wrote:
> From: Alex Dai
>
> Can't immediately free LRC context (neither unpin it) even all
> its referenced requests are completed, because HW still need a
> short period of time to save data
While comparing the B-Spec with the code I noticed that several
values in these tables have been updated in the spec, so I
changed the code to match..
Cc: Rodrigo Vivi
Signed-off-by: Jim Bride
---
drivers/gpu/drm/i915/intel_ddi.c | 22 +++---
1 file changed, 11 insertions(+), 11
On 11/06/2015 02:07 PM, Chris Wilson wrote:
On Fri, Nov 06, 2015 at 01:55:27PM -0800, yu@intel.com wrote:
> From: Alex Dai
>
> We keep a copy of GuC fw in a GEM obj. However its content is lost
> if the GEM obj is evicted (igt/gem_evict_*). Therefore, the later
> fw loading during GPU rese
On 3 November 2015 at 22:31, Patrik Jakobsson
wrote:
> We need DC5/DC6 to be disabled around modesets to prevent confusing the
> DMC. Also, we've run out of bits in the 32 bit power domain mask so now
> it's a 64 bit mask.
>
It was bad enough the original code used unsigned long so was
different
On Fri, Nov 06, 2015 at 10:00:19PM +, Chris Wilson wrote:
> On Thu, Aug 13, 2015 at 04:11:00PM +0300, Mika Kuoppala wrote:
> > Fix
> >
> > commit 59cdc16b1a6f069f944ff17851a59edf8f72d45d
> > Author: Arun Siluvery
> > Date: Fri Jul 31 16:27:07 2015 +0100
> >
> > tools/null_state/gen9: S
Hi Alex,
[auto build test WARNING on drm-intel/for-linux-next]
[also build test WARNING on next-20151106]
[cannot apply to v4.3]
url:
https://github.com/0day-ci/linux/commits/yu-dai-intel-com/drm-i915-guc-Defer-LRC-context-unpin-or-release/20151107-060016
base: git
On Fri, Nov 06, 2015 at 01:56:59PM -0800, yu@intel.com wrote:
> From: Alex Dai
>
> Can't immediately free LRC context (neither unpin it) even all
> its referenced requests are completed, because HW still need a
> short period of time to save data to LRC status page. It is safe
> to free LRC w
On Fri, Nov 06, 2015 at 01:55:27PM -0800, yu@intel.com wrote:
> From: Alex Dai
>
> We keep a copy of GuC fw in a GEM obj. However its content is lost
> if the GEM obj is evicted (igt/gem_evict_*). Therefore, the later
> fw loading during GPU reset will fail.
No, it's not. The bug is in sg_co
Sorry for wrong patch. Please forget about his one. Another one will be
submitted.
Alex
On 11/06/2015 01:56 PM, yu@intel.com wrote:
From: Alex Dai
Can't immediately free LRC context (neither unpin it) even all
its referenced requests are completed, because HW still need a
short period of
From: Alex Dai
Can't immediately free LRC (neither unpin it) even all its
referenced requests are completed, because HW still need a short
period of time to save data to LRC status page. It is safe to free
LRC when HW completes a request from a different LRC.
Introduce a new function intel_lr_co
From: Alex Dai
We keep a copy of GuC fw in a GEM obj. However its content is lost
if the GEM obj is evicted (igt/gem_evict_*). Therefore, the later
fw loading during GPU reset will fail.
Now we keep the copy in a memory block rather than a GEM objet.
During fw loading, we will wrap up a GEM obj
On Thu, Aug 13, 2015 at 04:11:00PM +0300, Mika Kuoppala wrote:
> Fix
>
> commit 59cdc16b1a6f069f944ff17851a59edf8f72d45d
> Author: Arun Siluvery
> Date: Fri Jul 31 16:27:07 2015 +0100
>
> tools/null_state/gen9: Send atleast one valid component in VF state
>
> to honor the Reviewed-by, sen
From: Alex Dai
Can't immediately free LRC context (neither unpin it) even all
its referenced requests are completed, because HW still need a
short period of time to save data to LRC status page. It is safe
to free LRC when HW completes a request from a different LRC.
Move LRC to ring->last_unpin
On Fri, Nov 06, 2015 at 09:47:16PM +0200, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä
>
> Add 'u32 offset' to the uncore register access functions. For now
> it's the same as 'reg', but once type safety gets added 'reg' will be
> the type safe register variable and 'offset' the raw
2015-10-27 15:14 GMT-02:00 Rodrigo Vivi :
> Let's introduce ULT and ULX Kabylake definitions and start
> using it for a propper DDI buffer translation.
>
> Signed-off-by: Rodrigo Vivi
> ---
> drivers/gpu/drm/i915/i915_drv.h | 8
> drivers/gpu/drm/i915/intel_ddi.c | 10 +-
> 2 f
From: Ville Syrjälä
Add 'u32 offset' to the uncore register access functions. For now
it's the same as 'reg', but once type safety gets added 'reg' will be
the type safe register variable and 'offset' the raw offset.
v2: s/uint32_t/u32/ (Chris)
Cc: Chris Wilson
Signed-off-by: Ville Syrjälä
--
Hi,
On 6 November 2015 at 13:53, Daniel Stone wrote:
> On 5 November 2015 at 17:12, Patrik Jakobsson
> wrote:
>> On Thu, Nov 5, 2015 at 4:02 PM, Daniel Stone wrote:
>>> On 3 November 2015 at 12:31, Patrik Jakobsson
>>> wrote:
We need DC5/DC6 to be disabled around modesets to prevent confu
From: Ville Syrjälä
Add defines for the upper halves of the registers used by the cmd
parser. Getting rid of the arithmetic with the register offset
will help in making registers type safe.
v2: s/_HI/_UDW/ (Chris)
Signed-off-by: Ville Syrjälä
Reviewed-by: Chris Wilson
---
drivers/gpu/drm/i91
From: Ville Syrjälä
Store the upper dword of the register offset in the whitelist as well.
This would allow it to read register where the two halves aren't sitting
right next to each other, and it'll make it easier to make register
access type safe.
While at it change the register offsets to u32
From: Ville Syrjälä
Replace the is_sdvob bool and some sdvo_reg checks with enum port. This
makes the SDVO code look more modern, and gets rid of explicit register
offset checks in the code which will hamper register type checking.
v2: Add assert_sdvo_port_valid() (Chris)
Signed-off-by: Ville S
On 10/29/2015 10:22 AM, Rodrigo Vivi wrote:
GuC has no version for KBL published yet and it is not recommended
to load the Skylake one, so let's avoid loading this for now while
we don't have the proper GuC firmware for Kabylake.
Signed-off-by: Rodrigo Vivi
---
drivers/gpu/drm/i915/i915_drv
On 11/06/2015 05:08 AM, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä
>
> Reading the driver load/unload code leaves one confused as there's
> an async_schedule() in the load, but not async_synchronize_full()
> in sight. In fact it's hidden inside intel_fbdev.c. So let's move the
> a
On 11/06/2015 05:38 AM, Chris Wilson wrote:
> On Thu, Nov 05, 2015 at 10:17:56AM -0800, Jesse Barnes wrote:
>> On 11/05/2015 09:51 AM, Kristian Høgsberg wrote:
>>> On Tue, Oct 6, 2015 at 3:53 AM, Chris Wilson
>>> wrote:
Userspace can pass in an offset that it presumes the object is located
>
Add Skylake Intel Graphics GT4 PCI IDs.
Signed-off-by: Mika Kuoppala
---
lib/intel_chipset.h | 12 +++-
1 file changed, 11 insertions(+), 1 deletion(-)
diff --git a/lib/intel_chipset.h b/lib/intel_chipset.h
index 6fcc244..93bf565 100644
--- a/lib/intel_chipset.h
+++ b/lib/intel_chipset.
Hi,
On 6 November 2015 at 14:17, Imre Deak wrote:
> On pe, 2015-11-06 at 13:53 +, Daniel Stone wrote:
>> On 5 November 2015 at 17:12, Patrik Jakobsson
>> wrote:
>> > Ah yes, we carry the mask around there as well. Thanks for catching
>> > that. I like the move of POWER_DOMAIN_MODESET into pu
On pe, 2015-11-06 at 13:53 +, Daniel Stone wrote:
> Hi,
>
> On 5 November 2015 at 17:12, Patrik Jakobsson
> wrote:
> > On Thu, Nov 5, 2015 at 4:02 PM, Daniel Stone
> > wrote:
> > > On 3 November 2015 at 12:31, Patrik Jakobsson
> > > wrote:
> > > > We need DC5/DC6 to be disabled around modes
On Fri, Nov 06, 2015 at 03:08:32PM +0200, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä
>
> We set up fbdev last during load, so doing the fbdev cleanup should be
> first.
>
> We weren't supposed to drop the init power during driver load, but since
Hi,
On 5 November 2015 at 17:12, Patrik Jakobsson
wrote:
> On Thu, Nov 5, 2015 at 4:02 PM, Daniel Stone wrote:
>> On 3 November 2015 at 12:31, Patrik Jakobsson
>> wrote:
>>> We need DC5/DC6 to be disabled around modesets to prevent confusing the
>>> DMC. Also, we've run out of bits in the 32 bi
Hi all,
I have various devices where I can control the backlight via "vbetool dpms
off" and "vbetool dpms on" (basically terminals with industrial
motherboards from Congatec or Advantech).
The context is some hardware test after manufacturing, so I'm running in
the text console. No X11 is (or has
On 11/04/2015 02:13 PM, Jesse Barnes wrote:
On 11/04/2015 11:10 AM, Paulo Zanoni wrote:
From our maintainer Daniel Vetter a few days ago:
"Oh dear this is dead code. kdbg uses the fbcon, which always uses
untiled, which means fbc will never be enabled. Also we have 0 users
and 0 test c
On Fri, Nov 06, 2015 at 01:25:19PM +, Chris Wilson wrote:
> On Wed, Nov 04, 2015 at 11:19:52PM +0200, ville.syrj...@linux.intel.com wrote:
> > From: Ville Syrjälä
> >
> > v2: Keep some MISSING_CASE() stuff (Jani)
> > s/-1/-PIPE_B/ in the register macro
> > Fix typo in patch subject
>
Hi Dave -
Here's a handful of i915 fixes for drm-next/v4.4. Imre's commit alone
should address the remaining warnings galore you experienced on
Skylake. Almost all of the rest are also fixes against user or QA
reported bugs, with references.
Without going into specifics, please know that we're a
On Thu, Nov 05, 2015 at 10:17:56AM -0800, Jesse Barnes wrote:
> On 11/05/2015 09:51 AM, Kristian Høgsberg wrote:
> > On Tue, Oct 6, 2015 at 3:53 AM, Chris Wilson
> > wrote:
> >> Userspace can pass in an offset that it presumes the object is located
> >> at. The kernel will then do its utmost to f
On Fri, Nov 06, 2015 at 01:14:33PM +, Chris Wilson wrote:
> On Wed, Nov 04, 2015 at 11:20:15PM +0200, ville.syrj...@linux.intel.com wrote:
> > From: Ville Syrjälä
> >
> > No idea if we might want these. Perhaps there is a "keep your paws off
> > my GPU" bit in there somewhere to avoid BIOS cr
On Fri, Nov 06, 2015 at 03:08:32PM +0200, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä
>
> We set up fbdev last during load, so doing the fbdev cleanup should be
> first.
>
> We weren't supposed to drop the init power during driver load, but since
> the fbdev teardown happened afte
On Fri, Nov 06, 2015 at 03:08:33PM +0200, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä
>
> Reading the driver load/unload code leaves one confused as there's
> an async_schedule() in the load, but not async_synchronize_full()
> in sight. In fact it's hidden inside intel_fbdev.c. So
On Wed, Nov 04, 2015 at 11:19:52PM +0200, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä
>
> v2: Keep some MISSING_CASE() stuff (Jani)
> s/-1/-PIPE_B/ in the register macro
> Fix typo in patch subject
> v3: Use PORT_B registers for invalid ports in g4x_aux_ctl_reg() (Jani)
>
On Wed, Nov 04, 2015 at 11:19:54PM +0200, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä
>
> Rather than computing on demand, store also the aux data reg
> offsets under intel_dp.
>
> v2: Duplicate some code to make things less magic (Jani)
> v3: Use PORT_B registers for invalid port
On Wed, Nov 04, 2015 at 11:19:50PM +0200, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä
>
> Currently we determine the location of the AUX registers in a confusing
> way. First we assume the PCH registers are used always, but then we
> override it for everything but HSW/BDW to use DP
On Wed, Nov 04, 2015 at 11:20:15PM +0200, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä
>
> No idea if we might want these. Perhaps there is a "keep your paws off
> my GPU" bit in there somewhere to avoid BIOS crap?
Hmm. "These registers are used as scratch pad data storage space an
On Fri, 06 Nov 2015, SF Markus Elfring wrote:
>>> The pwm_put() function tests whether its argument is NULL and then
>>> returns immediately. Thus the test around the call is not needed.
>>
>> The compiler doesn't need it, but IMO it's useful documentation for humans.
>
> How do you think about t
From: Ville Syrjälä
Reading the driver load/unload code leaves one confused as there's
an async_schedule() in the load, but not async_synchronize_full()
in sight. In fact it's hidden inside intel_fbdev.c. So let's move the
async_schedule() into intel_fbdev.c as well so that it's next to the
async
From: Ville Syrjälä
intel_runtime_pm_disable() takes an extra rpm reference which combined
with the one we leak from intel_display_set_init_power() leaves the
usage count at +1 after the driver has been unloaded.
The original ref is dropped explicitly in intel_runtime_pm_enable().
So the next tim
From: Ville Syrjälä
This series fixes an rpm leak during driver unload, and reorganizes the fbdev
init/cleanup to make a bit more sense.
Ville Syrjälä (3):
drm/i915: Kill intel_runtime_pm_disable()
drm/i915: Do fbdev fini first during unload
drm/i915: Move the fbdev async_schedule() into i
From: Ville Syrjälä
We set up fbdev last during load, so doing the fbdev cleanup should be
first.
We weren't supposed to drop the init power during driver load, but since
the fbdev teardown happened after intel_power_domains_fini() that could
have happened due in one of two ways. First it could
>> The pwm_put() function tests whether its argument is NULL and then
>> returns immediately. Thus the test around the call is not needed.
>
> The compiler doesn't need it, but IMO it's useful documentation for humans.
How do you think about to extend the explicit documentation for
the affected p
From: Markus Elfring
Date: Fri, 6 Nov 2015 13:38:22 +0100
The pwm_put() function tests whether its argument is NULL and then
returns immediately. Thus the test around the call is not needed.
This issue was detected by using the Coccinelle software.
Signed-off-by: Markus Elfring
---
drivers/gp
On Fri, 06 Nov 2015, SF Markus Elfring wrote:
> From: Markus Elfring
> Date: Fri, 6 Nov 2015 13:38:22 +0100
>
> The pwm_put() function tests whether its argument is NULL and then
> returns immediately. Thus the test around the call is not needed.
The compiler doesn't need it, but IMO it's useful
On Fri, 06 Nov 2015, Ville Syrjälä wrote:
> On Thu, Nov 05, 2015 at 11:04:11PM +0200, Imre Deak wrote:
>> The display power well support on this platform is in a somewhat broken
>> state atm, so disable it by default.
>>
>> This in effect will get rid of incorrect assert WARNs about the CSR/DMC
>
Current DP detection has DPCD operations split across
intel_dp_hpd_pulse and intel_dp_detect which contains
duplicates as well. Also intel_dp_detect is called
during modes enumeration as well which will result
in multiple dpcd operations. So this patch tries
to solve both these by bringing all DPCD
This patch set cleans up DP detection logic to bring all DPCD
operations at one place and to create a clear demarcation
between handling of long and short pulses. This simplifies
fixing of sink count related detection for DP panels.
Patches:
1. First two patches clean up intel_dp_detect and form a
This patch checks for changes in sink count between short pulse
hpds and forces full detect when there is a change.
This will allow both detection of hotplug and unplug of panels
through dongles that give only short pulse for such events.
v2: changed variable type from u8 to bool (Jani)
retur
Sink count can change between short pulse hpd hence this patch
adds a member variable to intel_dp so we can track any changes
between short pulse interrupts.
Signed-off-by: Sivakumar Thulasimani
Signed-off-by: Shubhangi Shrivastava
---
drivers/gpu/drm/i915/intel_dp.c | 7 +++
drivers/gpu/d
This patch reads sink_count dpcd always and removes its
read operation based on values in downstream port dpcd.
SINK_COUNT dpcd is not dependent on DOWNSTREAM_PORT_PRESENT dpcd.
SINK_COUNT denotes if a display is attached, while
DOWNSTREAM_PORT_PRESET indicates how many ports are available
in the
The link retraining part when EQ is not correct is
retained to intel_dp_check_link_status whereas other
operations are handled as part of intel_dp_short_pulse.
This change is required to avoid performing all DPCD
related operations on performing link retraining.
Signed-off-by: Sivakumar Thulasiman
This patch moves probing for panel, DPCD read etc to another
function intel_dp_long_pulse, while intel_dp_detect returns
the status as connected or disconnected depending on
whether the edid is available or not.
This change will be required by further patches in the series
to avoid performing multi
From: Mika Kuoppala
Add Skylake Intel Graphics GT4 PCI IDs
v2: Rebase
Signed-off-by: Mika Kuoppala
---
drivers/gpu/drm/i915/i915_drv.c | 1 +
include/drm/i915_pciids.h | 13 ++---
2 files changed, 11 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.c b/
On Thu, Nov 05, 2015 at 11:04:11PM +0200, Imre Deak wrote:
> The display power well support on this platform is in a somewhat broken
> state atm, so disable it by default.
>
> This in effect will get rid of incorrect assert WARNs about the CSR/DMC
> firmware not being loaded during power well togg
Hi,
On 06-11-15 11:19, Jani Nikula wrote:
On Thu, 05 Nov 2015, Hans de Goede wrote:
Hi,
As discussed in the past, the i915 opregion code does not do the
right thing wrt the CADL field when there are more then 8 outputs,
this is causing issues on many different types of Asus laptops.
This thr
On Thu, 05 Nov 2015, Hans de Goede wrote:
> Hi,
>
> As discussed in the past, the i915 opregion code does not do the
> right thing wrt the CADL field when there are more then 8 outputs,
> this is causing issues on many different types of Asus laptops.
>
> This thread has details and a number of at
On Thu, 05 Nov 2015, Jesse Barnes wrote:
> On 11/03/2015 04:44 AM, Maarten Lankhorst wrote:
>> Hey,
>>
>> Op 03-11-15 om 12:32 schreef Jani Nikula:
>>> On Tue, 03 Nov 2015, Ville Syrjälä wrote:
On Tue, Nov 03, 2015 at 08:31:41AM +0100, Maarten Lankhorst wrote:
> Those platforms have the
Hi Libin,
[auto build test WARNING on drm/drm-next]
[also build test WARNING on v4.3 next-20151106]
[cannot apply to drm-intel/for-linux-next]
url:
https://github.com/0day-ci/linux/commits/libin-yang-linux-intel-com/drm-i915-DP-MST-audio-support-in-i915/20151106-163857
base: git
On Fri, Nov 06, 2015 at 12:57:35AM +0200, Imre Deak wrote:
> On Thu, 2015-11-05 at 11:56 +, Chris Wilson wrote:
> > On Thu, Nov 05, 2015 at 01:28:32PM +0200, Imre Deak wrote:
> > > On ke, 2015-11-04 at 20:57 +, Chris Wilson wrote:
> > > > On Wed, Nov 04, 2015 at 09:25:32PM +0200, Imre Deak
From: Libin Yang
These patches add support for DP MST audio in i915 driver.
Patches have been tested on BDW and the result show it won't
impact the DP SST and HDMI audio.
These patches are ported from Dave's patches.
Please check Dave's git tree for original patches:
git://people.freedesktop.org
From: Libin Yang
This adds code to initialise the SDP streams
for a sink in the simplest ordering.
I've no idea how you'd want to control the
ordering at this level, so don't bother
until someone comes up with a use case.
Signed-off-by: Libin Yang
Signed-off-by: Dave Airlie
---
drivers/gpu/d
From: Libin Yang
This patch adds support for DP MST audio in i915.
Enable audio codec when DP MST is enabled if has_audio flag is set.
Disable audio codec when DP MST is disabled if has_audio flag is set.
Signed-off-by: Libin Yang
Signed-off-by: Dave Airlie
---
drivers/gpu/drm/i915/i915_debu
67 matches
Mail list logo
