== Series Details ==
Series: GET_PLANE2 w/ i915 implementation (rev3)
URL : https://patchwork.freedesktop.org/series/17873/
State : failure
== Summary ==
CC [M] drivers/gpu/drm/i915/gvt/cmd_parser.o
CC [M] drivers/gpu/drm/i915/gvt/sched_policy.o
CC [M] drivers/gpu/drm/i915/intel_lpe_a
== Series Details ==
Series: drm/i915: make i915_stolen_to_physical() return phys_addr_t
URL : https://patchwork.freedesktop.org/series/18640/
State : success
== Summary ==
Series 18640v1 drm/i915: make i915_stolen_to_physical() return phys_addr_t
https://patchwork.freedesktop.org/api/1.0/seri
== Series Details ==
Series: DisplayPort Audio on Cherrytrail
URL : https://patchwork.freedesktop.org/series/18639/
State : failure
== Summary ==
Series 18639v1 DisplayPort Audio on Cherrytrail
https://patchwork.freedesktop.org/api/1.0/series/18639/revisions/1/mbox/
Test gem_close_race:
On Thu 26 Jan 2017, Chris Wilson wrote:
> On Wed, Jan 25, 2017 at 12:38:32PM -0800, Chad Versace wrote:
> > On Mon 14 Nov 2016, Chris Wilson wrote:
> > > Userspace is faced with a dilemma. The kernel requires implicit fencing
> > > to manage resource usage (we always must wait for the GPU to finish
On Thu 26 Jan 2017, Chad Versace wrote:
> On Thu 26 Jan 2017, Chris Wilson wrote:
> > Since the workaround bo is used strictly as a write-only buffer, we need
> > only allocate one per screen and use the same one from all contexts.
> >
> > (The caveat here is during extension initialisation, where
== Series Details ==
Series: drm/i915: Introduce intel_cdclk_state (rev8)
URL : https://patchwork.freedesktop.org/series/16994/
State : warning
== Summary ==
Series 16994v8 drm/i915: Introduce intel_cdclk_state
https://patchwork.freedesktop.org/api/1.0/series/16994/revisions/8/mbox/
Test gem_
On Thu 26 Jan 2017, Chris Wilson wrote:
> On Thu, Jan 26, 2017 at 09:39:51AM -0800, Chad Versace wrote:
> > On Thu 26 Jan 2017, Chris Wilson wrote:
> > > Since the workaround bo is used strictly as a write-only buffer, we need
> > > only allocate one per screen and use the same one from all context
Originally based off of a patch by Kristian.
This new ioctl extends DRM_IOCTL_MODE_GETPLANE, by returning information
about the modifiers that will work with each format.
It's modified from Kristian's patch in that the modifiers and formats
are setup by the driver, and then a callback is used to
== Series Details ==
Series: series starting with [1/3] drm/i915: Make intel_detect_preproduction_hw
easier to extend
URL : https://patchwork.freedesktop.org/series/18604/
State : warning
== Summary ==
Series 18604v1 Series without cover letter
https://patchwork.freedesktop.org/api/1.0/series
On Thu, Jan 26, 2017 at 06:19:07PM -0200, Paulo Zanoni wrote:
> The i915_stolen_to_physical() function has 'unsigned long' as its
> return type but it returns the 'base' variable, which is of type
> 'u32'. The only place where this function is called assigns the
> returned value to dev_priv->mm.sto
On 01/25/2017 07:38 AM, Daniel Vetter wrote:
> On Wed, Jan 25, 2017 at 07:20:45AM -0800, Dave Hansen wrote:
>> On 01/24/2017 10:21 PM, Daniel Vetter wrote:
>>> Hi Dave,
>>>
>>> Still waiting for your testing results on this one here ...
>>
>> It's definitely stable with that patch applied. No more
The i915_stolen_to_physical() function has 'unsigned long' as its
return type but it returns the 'base' variable, which is of type
'u32'. The only place where this function is called assigns the
returned value to dev_priv->mm.stolen_base, which is of type
'phys_addr_t'. The return value is actually
Somehow the configuration register that the audio driver needs to use
depends on the port/pipe combination.
Adding the pipe information to the notify() call isn't helping, the
pipe value is -1 (illegal).
FIXME: does this require a change in the pdata or a handshake with i915?
Signed-off-by: Pierre
If DisplayPort is detected, pass flag and link rate to audio driver
Signed-off-by: Pierre-Louis Bossart
---
drivers/gpu/drm/i915/i915_drv.h| 3 ++-
drivers/gpu/drm/i915/intel_audio.c | 19 +++
drivers/gpu/drm/i915/intel_lpe_audio.c | 7 ++-
include/drm/intel_lpe
These bits were set in legacy and not in upstream code, and are
apparently tested for when writing a config in DP mode
FIXME: is this even needed?
Signed-off-by: Pierre-Louis Bossart
---
sound/x86/intel_hdmi_audio.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/sound/x86/intel_hdmi_audi
Enable chicken bit on LPE mode setup and unmute amp on
notification
FIXME: should these two phases done somewhere else?
Signed-off-by: Pierre-Louis Bossart
---
drivers/gpu/drm/i915/i915_reg.h| 12
drivers/gpu/drm/i915/intel_lpe_audio.c | 27 +++
2 fi
Imported from legacy patches
Note: the new code doesn't assume a modified ELD but
an explicit notification that DP is present. It appears
that the i915 code does change the ELD so we could use
the ELD-based tests to check for DP audio
Signed-off-by: Pierre-Louis Bossart
---
sound/x86/intel_hdmi
The following patches enable DisplayPort Audio on Cherrytrail machines
when applied on top of Takashi's topic/intel-lpe-audio branch (tested
on Zotac PI330)
There are a couple of opens where I could use some help:
- is it necessary to set a valid_bit which is used only for DP audio?
- is the seq
From: Ville Syrjälä
Move the vlv_program_pfi_credits() into vlv_set_cdclk() and
chv_set_cdclk() so that we can neuter vlv_modeset_commit_cdclk().
v2: Do the PFI programming after cdclk readout since it currently
depends on the readout to fill dev_priv->cdclk.hw
Signed-off-by: Ville Syrjälä
From: Ville Syrjälä
With the cdclk state, all the .modeset_commit_cdclk() hooks are
now pointless wrappers. Let's replace them with just a .set_cdclk()
function pointer. However let's wrap that in a small helper that
does the state comparison and prints a unified debug message across
all platform
From: Ville Syrjälä
Rename the .get_display_clock_speed() hook to .get_cdclk().
.get_cdclk() is more specific (which clock) and it's much
shorter.
v2: Deal with IS_GEN9_BC()
Signed-off-by: Ville Syrjälä
Reviewed-by: Ander Conselvan de Oliveira
---
drivers/gpu/drm/i915/i915_drv.h | 2
From: Ville Syrjälä
Rather than recomputing the pipe pixel rate on demand everywhere, let's
just stick the precomputed value into the crtc state.
v2: Rebase due to min_pixclk[] code movement
Document the new pixel_rate struct member (Ander)
Combine vlv/chv with bdw+ in intel_modeset_read
This is what we have the readb and writeb variants for. Do some minor
return value and variable cleanup while at it.
Cc: Manasi Navare
Cc: Ville Syrjälä
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/intel_dp.c | 37 +
1 file changed, 17 insertions(+),
These are the theoretical maximums common for source and sink. These are
the maximums we should start with. They may be degraded in case of link
training failures, and the dynamic link values are stored separately.
Cc: Manasi Navare
Cc: Ville Syrjälä
Signed-off-by: Jani Nikula
---
drivers/gpu/
In link training fallback, we're trying to find a rate that we know is
in a sorted array of common link rates. We don't need to limit the array
using the max rate. For test request, the DP CTS doesn't say we should
limit the rate based on earlier fallback.
Cc: Manasi Navare
Cc: Ville Syrjälä
Sig
The source might not support as many lanes as the sink, or the link
training might have failed at higher lane counts. Take these into
account.
Cc: Dhinakaran Pandiyan
Cc: Manasi Navare
Cc: Ville Syrjälä
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/intel_dp.c | 2 +-
drivers/gpu/drm
If we modify these on the fly depending on the link conditions, don't
pretend they are sink properties.
Some link vs. sink confusion still remains, but we'll take care of them
in follow-up patches.
Cc: Manasi Navare
Cc: Ville Syrjälä
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/intel_d
There is some conflation related to sink rates, making this change more
complicated than it would otherwise have to be. There are three changes
here that are rather difficult to split up:
1) Use the intel_dp->sink_rates array for all DP, not just eDP 1.4. We
initialize it from DPCD on eDP 1.4 l
We need the source rates array so often that it makes sense to set it
once at init. This reduces function calls when we need the rates, making
the code easier to follow.
Cc: Manasi Navare
Cc: Ville Syrjälä
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/intel_dp.c | 35 +++
Looking at DPCD DP_MAX_LINK_RATE may be completely bogus for eDP 1.4
which is allowed to use link rate select method and have 0 in max link
rate. With this change, it makes sense to store the max rate as the
actual rate rather than as a bw code.
Cc: Manasi Navare
Cc: Ville Syrjälä
Signed-off-by:
We shouldn't silently use the first element if we can't find the rate
we're looking for. Make rate_to_index() more generally useful, and
fallback to the first element in the caller, with a big warning.
Cc: Manasi Navare
Cc: Ville Syrjälä
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/inte
Localize link_rate_index to the if block, and rename to just index to
reduce indent.
Cc: Manasi Navare
Cc: Ville Syrjälä
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/intel_dp.c | 13 +++--
1 file changed, 7 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_d
Now that source rates are static and sink rates are updated whenever
DPCD is updated, we can do and cache the intersection of them whenever
sink rates are updated. This reduces code complexity, as we don't have
to keep calling the functions to intersect. We also get rid of several
common rates arra
Rename the function, move it at the top, and reuse in
intel_dp_link_rate_index(). If there was a reason in the past to use
reverse search order here, there isn't now.
Cc: Manasi Navare
Cc: Ville Syrjälä
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/intel_dp.c | 33 ++-
I can't think of a real world bug this could cause now, but this will be
required in follow-up work. While at it, change the parameter order to
be slightly more sensible.
Cc: Manasi Navare
Cc: Ville Syrjälä
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/intel_dp.c | 11 ++-
1 file
This is kind of version 1½ of [1], basically just rebased on current git
(including Manasi's test automation patches) and a couple of more
cleanups slammed on top.
BR,
Jani.
[1] cover.1485015599.git.jani.nikula@intel.com">http://mid.mail-archive.com/cover.1485015599.git.jani.nikula@intel.com
J
On Thu, Jan 26, 2017 at 10:55:51AM +0100, Maarten Lankhorst wrote:
> Op 25-01-17 om 19:05 schreef Sinclair Yeh:
> > On Wed, Jan 25, 2017 at 09:36:36AM +0100, Maarten Lankhorst wrote:
> >> Op 25-01-17 om 09:09 schreef Thomas Hellstrom:
> >>> On 01/25/2017 05:54 AM, Daniel Vetter wrote:
> On Tue
On Wed, Jan 11, 2017 at 02:57:20PM +0200, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä
>
> While reading the HDMI 2.0 spec I noticed some new things related to
> the RGB quantization range stuff, and after cross checking with
> CEA-861-F I spotted a some other things as well. So I f
On Thu, Jan 26, 2017 at 09:39:51AM -0800, Chad Versace wrote:
> On Thu 26 Jan 2017, Chris Wilson wrote:
> > Since the workaround bo is used strictly as a write-only buffer, we need
> > only allocate one per screen and use the same one from all contexts.
> >
> > (The caveat here is during extension
On Mon, Jan 09, 2017 at 06:06:57PM +0100, Maarten Lankhorst wrote:
> We're protected by the connection_mutex lock against blocking modesets,
> but nonblocking modesets are performed without any locking. This is
> causing WARN in drm_wait_for_vblank and in general it's better to wait
> before modese
On Mon, Jan 09, 2017 at 06:06:56PM +0100, Maarten Lankhorst wrote:
> This will allow i915 to perform a wait on pending modeset using the
> same code.
I don't like commit messages that refer to the subject like this. I
can't even see the subject when I'm replying so I have approximately
zero idea w
On Thu, Jan 26, 2017 at 09:39:51AM -0800, Chad Versace wrote:
> On Thu 26 Jan 2017, Chris Wilson wrote:
> > Since the workaround bo is used strictly as a write-only buffer, we need
> > only allocate one per screen and use the same one from all contexts.
> >
> > (The caveat here is during extension
On Thu 26 Jan 2017, Chris Wilson wrote:
> Since the workaround bo is used strictly as a write-only buffer, we need
> only allocate one per screen and use the same one from all contexts.
>
> (The caveat here is during extension initialisation, where we write into
> and read back register values fro
> It sucks, but I guess this is better than dead machines. I'd say let's
> wait another 1-2 weeks for tested-bys to trickle in, and if it does fix
> the problem then let's apply it. rps keeps on sucking, that's
> unfortunately not news at all.
>
> Acked-by: Daniel Vetter
I have 3 machines that I
On Thu, Jan 26, 2017 at 04:59:21PM +0100, Maarten Lankhorst wrote:
> When writing some testcases for nonblocking modesets. I found out that the
> infinite wait on the old fb was causing issues.
>
> A nonblocking modeset with a hang on the old fb, followed by a blocking
> update was enough to trigg
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/i915/intel_display.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 7c19b3c7a4ee..35d25e58a37e 100644
--- a/drivers/gpu/drm/i915/intel_displ
With the atomic helper for pageflips there are no CS flips when
that require resetting, so on most platforms we can completely
skip the locking.
Because we may end up reverting the page_flip patch add an explicit
function pointer check so that if someone reverts the page flip patch
there will not
When writing some testcases for nonblocking modesets. I found out that the
infinite wait on the old fb was causing issues.
A nonblocking modeset with a hang on the old fb, followed by a blocking
update was enough to trigger it.
For old platforms patch 2 is needed else
kms_busy.extended-modeset-ha
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/drm_atomic_helper.c | 12
1 file changed, 8 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/drm_atomic_helper.c
b/drivers/gpu/drm/drm_atomic_helper.c
index b535f782b2c0..34338678db26 100644
--- a/drivers/gpu/drm/drm_at
From: ramibh
This is atomic modesetting acceptance tests added to feat_profile.json. Wating
for your feedback.
---
tests/feat_profile.json | 8 +++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/tests/feat_profile.json b/tests/feat_profile.json
index 251dfd9..bba4b3c 100644
On Thu, Jan 26, 2017 at 05:32:11PM +0300, Andrey Ryabinin wrote:
> page_flip_completed() dereferences 'work' variable after executing
> queue_work(). This is not safe as the 'work' item might be already freed
> by queued work:
>
> BUG: KASAN: use-after-free in page_flip_completed+0x3ff/0x490 a
On Thu, Jan 26, 2017 at 04:25:25PM +0200, Mika Kuoppala wrote:
> Chris Wilson writes:
>
> > Since obj->active_count is only updated upon retirement, if we see an
> > active object in the batch pool, double check that is still active
> > before deciding to allocate a new object.
> >
> > Signed-off
Chris Wilson writes:
> Since obj->active_count is only updated upon retirement, if we see an
> active object in the batch pool, double check that is still active
> before deciding to allocate a new object.
>
> Signed-off-by: Chris Wilson
> ---
> drivers/gpu/drm/i915/i915_gem_batch_pool.c | 29 +
On Thu, Jan 26, 2017 at 01:24:24PM +0200, Ander Conselvan de Oliveira wrote:
> The gamma tables in Geminilake were changed. There is no split-gamma
> mode. Instead, there is a dedicated degamma table that is enabled
> whenever pipe CSC is enabled.
>
> The dedicated gamma table has 16 bit precision
On Thu, 26 Jan 2017 14:58:55 +0100,
Ville Syrjälä wrote:
>
> On Wed, Jan 25, 2017 at 01:56:35PM +0100, Takashi Iwai wrote:
> > Hi,
> >
> > we've got a bug report about the blank monitor on Cherry Trail
> > machines. And, Intel team (Cc'ed) spotted out that this seems
> > triggered by DPMS transi
On Sat, 21 Jan 2017, Manasi Navare wrote:
> This patch series addresses all the review comments from the previous series:
> https://patchwork.freedesktop.org/series/18256/
>
> On top of that it also adds a fix for CRC mismatches seen during
> 18bpp video pattern compliance testing. This is done by
On Wed, Jan 25, 2017 at 01:56:35PM +0100, Takashi Iwai wrote:
> Hi,
>
> we've got a bug report about the blank monitor on Cherry Trail
> machines. And, Intel team (Cc'ed) spotted out that this seems
> triggered by DPMS transition. A patch like below actually fixes the
> problem.
>
> Of course i
On Thu, 26 Jan 2017, Chris Wilson wrote:
> On Thu, Jan 26, 2017 at 03:18:28PM +0200, Jani Nikula wrote:
>> On Thu, 26 Jan 2017, Chris Wilson wrote:
>> > As we add new generations, we should keep detecting new system
>> > development platforms that were temporarily enabled (via
>> > "i915.alpha_su
On Thu, Jan 26, 2017 at 03:18:28PM +0200, Jani Nikula wrote:
> On Thu, 26 Jan 2017, Chris Wilson wrote:
> > As we add new generations, we should keep detecting new system
> > development platforms that were temporarily enabled (via
> > "i915.alpha_support") and now superseded by production systems
Chris Wilson writes:
> As the previous punit i/o may have failed, the contents of the PDATA are
> undefined. Always clear it to 0 prior to sending the command.
>
> Signed-off-by: Chris Wilson
Reviewed-by: Mika Kuoppala
> Cc: Mika Kuoppala
> ---
> drivers/gpu/drm/i915/intel_sideband.c | 4 +-
On Thu, 26 Jan 2017, Chris Wilson wrote:
> Preproduction sdv are not supported beyond the release of production
> hardware, and continued use is ill-advised. Mark the kernel as tainted
> to reinforce the error.
>
> Signed-off-by: Chris Wilson
> Cc: "Zanoni, Paulo R"
> Cc: Rodrigo Vivi
> Cc: Jan
Chris Wilson writes:
> The write to the punit may fail, so propagate the error code back to its
> callers. Of particular interest are the RPS writes, so add appropriate
> user error codes and logging.
>
> v2: Add DEBUG for failed frequency changes during RPS.
>
> Signed-off-by: Chris Wilson
Rev
On Thu, Jan 26, 2017 at 01:16:03PM +, Chris Wilson wrote:
> On Thu, Jan 26, 2017 at 03:02:14PM +0200, Ville Syrjälä wrote:
> > On Thu, Jan 26, 2017 at 12:50:28PM +, Chris Wilson wrote:
> > > As we add new generations, we should keep detecting new system
> > > development platforms that were
On Thu, 26 Jan 2017, Chris Wilson wrote:
> As we add new generations, we should keep detecting new system
> development platforms that were temporarily enabled (via
> "i915.alpha_support") and now superseded by production systems. To make
> it easier to add more platforms, split the if into a seri
On Thu, Jan 26, 2017 at 03:02:14PM +0200, Ville Syrjälä wrote:
> On Thu, Jan 26, 2017 at 12:50:28PM +, Chris Wilson wrote:
> > As we add new generations, we should keep detecting new system
> > development platforms that were temporarily enabled (via
> > "i915.alpha_support") and now superseded
Em Qui, 2017-01-26 às 15:02 +0200, Ville Syrjälä escreveu:
> On Thu, Jan 26, 2017 at 12:50:28PM +, Chris Wilson wrote:
> >
> > As we add new generations, we should keep detecting new system
> > development platforms that were temporarily enabled (via
> > "i915.alpha_support") and now supersede
On Thu, Jan 26, 2017 at 01:24:23PM +0200, Ander Conselvan de Oliveira wrote:
> Split the logic for progamming each LUT out of broadwell_load_luts(), so
> we can reuse part of it for geminilake.
>
> Cc: Ville Syrjälä
> Signed-off-by: Ander Conselvan de Oliveira
>
Reviewed-by: Ville Syrjälä
>
On Thu, Jan 26, 2017 at 12:50:28PM +, Chris Wilson wrote:
> As we add new generations, we should keep detecting new system
> development platforms that were temporarily enabled (via
> "i915.alpha_support") and now superseded by production systems. To make
> it easier to add more platforms, spli
== Series Details ==
Series: Geminilake pipe CSC
URL : https://patchwork.freedesktop.org/series/18596/
State : success
== Summary ==
Series 18596v1 Geminilake pipe CSC
https://patchwork.freedesktop.org/api/1.0/series/18596/revisions/1/mbox/
fi-bdw-5557u total:247 pass:233 dwarn:0 dfa
Preproduction sdv are not supported beyond the release of production
hardware, and continued use is ill-advised. Mark the kernel as tainted
to reinforce the error.
Signed-off-by: Chris Wilson
Cc: "Zanoni, Paulo R"
Cc: Rodrigo Vivi
Cc: Jani Nikula
Cc: Ville Syrjälä
---
drivers/gpu/drm/i915/i9
As we add new generations, we should keep detecting new system
development platforms that were temporarily enabled (via
"i915.alpha_support") and now superseded by production systems. To make
it easier to add more platforms, split the if into a series of logical
operations.
Signed-off-by: Chris Wi
Extend intel_detect_preproduction_hw() to include BXT A and B steppings.
Signed-off-by: Chris Wilson
Cc: "Zanoni, Paulo R"
Cc: Rodrigo Vivi
Cc: Jani Nikula
Cc: Ville Syrjälä
---
drivers/gpu/drm/i915/i915_drv.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/i915/i915_drv.
Em Qua, 2017-01-25 às 17:26 +, Chris Wilson escreveu:
> Remove WaGsvDisableTurbo and WaRsUseTimeoutMode as these were only
> for
> pre-production Broxton devices, and this code is now defunct.
Can you please also patch intel_detect_preproduction_hw()?
Thanks,
Paulo
>
> Signed-off-by: Chris
Since obj->active_count is only updated upon retirement, if we see an
active object in the batch pool, double check that is still active
before deciding to allocate a new object.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_gem_batch_pool.c | 29 ++---
1 file
== Series Details ==
Series: series starting with [v2] drm/i915: Report the failure to write to the
punit (rev2)
URL : https://patchwork.freedesktop.org/series/18549/
State : success
== Summary ==
Series 18549v2 Series without cover letter
https://patchwork.freedesktop.org/api/1.0/series/1854
On Thu, Jan 26, 2017 at 11:16:58AM +0200, Ander Conselvan de Oliveira wrote:
> Apply workarounds to Geminilake, and annotate those that are applied
> unconditionally when they apply to GLK based on the workaround database.
>
> v2: Fix commit message typos. (David)
> v3: Rebase.
> Cc: David Weineha
== Series Details ==
Series: series starting with [1/3] drm/i915: Add name for
WaDisablePWMClockGating workaround (rev3)
URL : https://patchwork.freedesktop.org/series/17904/
State : success
== Summary ==
Series 17904v3 Series without cover letter
https://patchwork.freedesktop.org/api/1.0/ser
Reviewed-by: Mika Kahola
On Tue, 2017-01-24 at 18:34 -0500, Robert Foss wrote:
> Due to the dyn n_planes implementation some attributes and functions
> were made obsolete and cand be removed.
>
> However to keep all of the tests building the obsolete code is
> removed after all of the tests have
On Thu, Jan 26, 2017 at 01:24:22PM +0200, Ander Conselvan de Oliveira wrote:
> In Geminilake, the bits for enabling pipe csc, pipe gamma and plane
> gamma moved to a new register. So update the plane update functions
> to set the right bits.
>
> Pipe CSC is kept disabled though, since enabling tha
Reviewed-by: Mika Kahola
On Tue, 2017-01-24 at 18:33 -0500, Robert Foss wrote:
> Add changes reflecting the new support for dynamic number of planes
> per pipe.
>
> Signed-off-by: Robert Foss
> ---
> tests/kms_plane_lowres.c | 27 +--
> 1 file changed, 21 insertions(+),
Reviewed-by: Mika Kahola
On Tue, 2017-01-24 at 18:33 -0500, Robert Foss wrote:
> Add changes reflecting the new support for dynamic number of planes
> per pipe.
>
> Signed-off-by: Robert Foss
> ---
> tests/kms_ccs.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/
Reviewed-by: Mika Kahola
On Tue, 2017-01-24 at 18:33 -0500, Robert Foss wrote:
> Add changes reflecting the new support for dynamic number of planes
> per pipe.
>
> Signed-off-by: Robert Foss
> ---
> tests/prime_mmap_kms.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git
tree: git://anongit.freedesktop.org/drm-intel drm-intel-nightly
head: 3778ca36c6b4e894b581d4f56abe6bbafe927e96
commit: 196cd5d3758cbf587fc0254cae7132d95993461e [1414/1425] drm:
s/drm_crtc_get_hv_timings/drm_mode_get_hv_timings/
config: i386-defconfig (attached as .config)
compiler: gcc-6 (Debi
The gamma tables in Geminilake were changed. There is no split-gamma
mode. Instead, there is a dedicated degamma table that is enabled
whenever pipe CSC is enabled.
The dedicated gamma table has 16 bit precision but doesn't support
separate channels. Since that doesn't match the per-channel format
Now that the pre-csc degamma table is set up correctly in Geminilake,
pipe CSC can be enabled without causing a black screen.
v2: Rebase.
Signed-off-by: Ander Conselvan de Oliveira
---
drivers/gpu/drm/i915/intel_display.c | 1 +
drivers/gpu/drm/i915/intel_sprite.c | 1 +
2 files changed, 2 ins
Reviewed-by: Mika Kahola
On Tue, 2017-01-24 at 18:33 -0500, Robert Foss wrote:
> Add changes reflecting the new support for dynamic number of planes
> per pipe.
>
> Signed-off-by: Robert Foss
> ---
> tests/kms_vblank.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git
Split the logic for progamming each LUT out of broadwell_load_luts(), so
we can reuse part of it for geminilake.
Cc: Ville Syrjälä
Signed-off-by: Ander Conselvan de Oliveira
---
drivers/gpu/drm/i915/i915_reg.h| 1 +
drivers/gpu/drm/i915/intel_color.c | 43 -
The plane gamma tables are never programmed, so just disable it, like it
is done for the primary plane.
Signed-off-by: Ander Conselvan de Oliveira
Reviewed-by: Ville Syrjälä
---
drivers/gpu/drm/i915/intel_sprite.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/i915/intel_s
In Geminilake, the bits for enabling pipe csc, pipe gamma and plane
gamma moved to a new register. So update the plane update functions
to set the right bits.
Pipe CSC is kept disabled though, since enabling that also enables the
dedicated degamma table, and that is not properly programmed yet,
le
Ander Conselvan de Oliveira (5):
drm/i915: Disable plane gamma in SKL+ sprite planes
drm/i915/glk: Plane color correction register changes
drm/i915: Split broadwell_load_luts() into smaller functions
drm/i915/glk: Program pipe gamma and degamma tables
drm/i915/glk: Enable pipe CSC
drive
Reviewed-by: Mika Kahola
On Tue, 2017-01-24 at 18:33 -0500, Robert Foss wrote:
> Add changes reflecting the new support for dynamic number of planes
> per pipe.
>
> Signed-off-by: Robert Foss
> ---
> tests/kms_universal_plane.c | 18 +-
> 1 file changed, 9 insertions(+), 9 dele
Reviewed-by: Mika Kahola
On Tue, 2017-01-24 at 18:33 -0500, Robert Foss wrote:
> Add changes reflecting the new support for dynamic number of planes
> per pipe.
>
> Signed-off-by: Robert Foss
> ---
> tests/kms_rotation_crc.c | 63
>
> 1 file ch
Reviewed-by: Mika Kahola
On Tue, 2017-01-24 at 18:33 -0500, Robert Foss wrote:
> Add changes reflecting the new support for dynamic number of planes
> per pipe.
>
> Signed-off-by: Robert Foss
> ---
> tests/kms_sink_crc_basic.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff -
On Thu, 26 Jan 2017, Daniel Vetter wrote:
> - Remove branch overview, instead link to drm-intel and drm-misc
> pages.
>
> - Move quickstart to the top, to make it easier to find.
>
> - Make quickstart generic, we use dim for other stuff than drm-intel
> now.
>
> - s/drm-intel-rerere/drm-rerere
Reviewed-by: Mika Kahola
On Tue, 2017-01-24 at 18:33 -0500, Robert Foss wrote:
> Add changes reflecting the new support for dynamic number of planes
> per pipe.
>
> Signed-off-by: Robert Foss
> ---
> tests/kms_rmfb.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/tes
Reviewed-by: Mika Kahola
On Tue, 2017-01-24 at 18:33 -0500, Robert Foss wrote:
> Add changes reflecting the new support for dynamic number of planes
> per pipe.
>
> Signed-off-by: Robert Foss
> ---
> tests/kms_pwrite_crc.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git
Since the workaround bo is used strictly as a write-only buffer, we need
only allocate one per screen and use the same one from all contexts.
(The caveat here is during extension initialisation, where we write into
and read back register values from the buffer, but that is performed only
once for
Reviewed-by: Mika Kahola
On Tue, 2017-01-24 at 18:33 -0500, Robert Foss wrote:
> Add changes reflecting the new support for dynamic number of planes
> per pipe.
>
> Signed-off-by: Robert Foss
> ---
> tests/kms_psr_sink_crc.c | 52 +-
> --
> 1 file ch
Reviewed-by: Mika Kahola
On Tue, 2017-01-24 at 18:33 -0500, Robert Foss wrote:
> Add changes reflecting the new support for dynamic number of planes
> per pipe.
>
> Signed-off-by: Robert Foss
> ---
> tests/kms_properties.c | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff
Reviewed-by: Mika Kahola
On Tue, 2017-01-24 at 18:33 -0500, Robert Foss wrote:
> Add changes reflecting the new support for dynamic number of planes
> per pipe.
>
> Signed-off-by: Robert Foss
> ---
> tests/kms_plane_scaling.c | 14 +++---
> 1 file changed, 7 insertions(+), 7 deletions(
1 - 100 of 137 matches
Mail list logo
