Another pile of regressions for Jairo to track ...
On Sat, Oct 10, 2015 at 11:46:29AM +0200, Takashi Iwai wrote:
> Hi,
>
> I noticed that a HSW laptop gets a few new warnings since 4.2-rc
> kernels. One error messages pops at each boot time:
>
> Console: switching to colour dummy device 80x25
On Sat, 10 Oct 2015, Darren Hart wrote:
> The Debian 3.16.0 kernel does not emit the error, but I have not attempted a
> bisection.
>
> The warning was added by:
> 38cc46d drm/i915/bdw: Ack interrupts before handling them (GEN8)
> 2014-06-18 (1 year, 4 months ago), Oscar Mateo
But we don't star
Another regression for Jairo to track.
-Daniel
On Sat, Oct 10, 2015 at 12:08:43PM -0700, Darren Hart wrote:
> The Debian 3.16.0 kernel does not emit the error, but I have not attempted a
> bisection.
>
> The warning was added by:
> 38cc46d drm/i915/bdw: Ack interrupts before handling them (GEN8)
To make kernel-doc happy, the i915_audio_component_audio_ops struct
cannot be nested.
Signed-off-by: David Henningsson
---
Documentation/DocBook/drm.tmpl | 1 +
include/drm/i915_component.h | 92 ++
2 files changed, 67 insertions(+), 26 deletions(-)
di
On 2015-10-12 10:07, David Henningsson wrote:
To make kernel-doc happy, the i915_audio_component_audio_ops struct
cannot be nested.
Signed-off-by: David Henningsson
---
Changes since v1:
* Added a notice about when pin_eld_notify is called
* Uses new inline struct member style
Verified
On Sat, Oct 10, 2015 at 4:17 PM, David Woodhouse wrote:
>
> On Fri, 2015-10-09 at 00:50 +0100, David Woodhouse wrote:
> > This patch set enables PASID support for the Intel IOMMU, along with
> > page request support.
> >
> > Like its AMD counterpart, it exposes an IOMMU-specific API. I believe
> >
The Debian 3.16.0 kernel does not emit the error, but I have not attempted a
bisection.
The warning was added by:
38cc46d drm/i915/bdw: Ack interrupts before handling them (GEN8)
2014-06-18 (1 year, 4 months ago), Oscar Mateo
Follows: v3.15-rc8
Preceedes: 3.17-rc1
This is not present in v3.16,
On 09/10/15 18:26, Chris Wilson wrote:
On Fri, Oct 09, 2015 at 07:14:02PM +0200, Daniel Vetter wrote:
On Fri, Oct 09, 2015 at 10:03:14AM +0100, Tvrtko Ursulin wrote:
On 09/10/15 09:55, Daniel Vetter wrote:
On Fri, Oct 09, 2015 at 09:40:53AM +0100, Chris Wilson wrote:
On Fri, Oct 09, 2015 at
On Mon, Oct 12, 2015 at 10:06:23AM +0100, Tvrtko Ursulin wrote:
>
> On 09/10/15 18:26, Chris Wilson wrote:
> >On Fri, Oct 09, 2015 at 07:14:02PM +0200, Daniel Vetter wrote:
> >>On Fri, Oct 09, 2015 at 10:03:14AM +0100, Tvrtko Ursulin wrote:
> >>>
> >>>On 09/10/15 09:55, Daniel Vetter wrote:
>
On Mon, Oct 12, 2015 at 10:31:35AM +0100, Chris Wilson wrote:
> We basically need to clone the obj, move the pages and vma over and so
> as the vma die the pages are unreferenced. All new use will be forced to
> call gup and be fine.
>
> Ok, that smells ok, I'll see how doable that is.
Hmm. If we
Some registers are, naturally, lost in gpu reset/suspend cycle.
And some registers, for example in display domain, are not subject
to gpu reset so they retain their contents.
As hang recovery triggers a reset, recoverable gpu hang can currently
flush out essential workarounds and cause havoc later
On Mon, Oct 12, 2015 at 01:20:59PM +0300, Mika Kuoppala wrote:
> Some registers are, naturally, lost in gpu reset/suspend cycle.
> And some registers, for example in display domain, are not subject
> to gpu reset so they retain their contents.
>
> As hang recovery triggers a reset, recoverable gpu
We were debugging this issue, and we could find the root cause:
In function:
Intel_hpd_init()
|
encoder->hotplug()
|
display_power_get()
|
Intel_powe_well_enable()
|
power_well->ops->enable()
|
chv_pipe_power_well_enable()
|
vlv_display_power_well_ini
On Mon, 12 Oct 2015 09:04:20 +0200,
Daniel Vetter wrote:
>
> Another pile of regressions for Jairo to track ...
>
> On Sat, Oct 10, 2015 at 11:46:29AM +0200, Takashi Iwai wrote:
> > Hi,
> >
> > I noticed that a HSW laptop gets a few new warnings since 4.2-rc
> > kernels. One error messages pops
On Mon, 12 Oct 2015 14:29:19 +0200,
Takashi Iwai wrote:
>
> > > Then a warning when I start powertop:
> > >
> > > WARNING: CPU: 1 PID: 1674 at drivers/gpu/drm/drm_atomic.c:889
> > > drm_atomic_get_property+0x232/0x2b0 [drm]()
> > > CPU: 1 PID: 1674 Comm: powertop Tainted: GW
> >
On 12/10/15 11:10, Chris Wilson wrote:
On Mon, Oct 12, 2015 at 10:31:35AM +0100, Chris Wilson wrote:
We basically need to clone the obj, move the pages and vma over and so
as the vma die the pages are unreferenced. All new use will be forced to
call gup and be fine.
Ok, that smells ok, I'll se
On ma, 2015-08-03 at 21:55 +0530, Animesh Manna wrote:
> Mmio register access after dc6/dc5 entry is not allowed when
> DC6 power states are enabled according to bspec (bspec-id 0527),
> so enabling dc6 as the last call in suspend flow.
The MMIO range BSpec-ID 0527 refers to is the DMC MMIO range.
On ma, 2015-08-03 at 21:55 +0530, Animesh Manna wrote:
> While display engine entering into low power state no need to disable
> cdclk pll as CSR firmware of dmc will take care. If pll is already
> enabled firmware execution sequence will be blocked. This is one
> of the criteria for dmc to work pr
On ma, 2015-08-03 at 21:55 +0530, Animesh Manna wrote:
> Another interesting criteria to work dmc as expected is pw1 to be
> enabled by driver and dmc will shut it off in its execution
> sequence. If already disabled by driver dmc will get confuse and
> behave differently than expected found during
On ma, 2015-08-03 at 21:55 +0530, Animesh Manna wrote:
> As csr firmware is taking care of loading the firmware,
> so no need for driver to load again.
I'd think that it's some other (PUnit, PCode) firmware that would take
care of reprogramming the CSR(DMC) firmware, rather than the CSR
firmware i
On ma, 2015-10-12 at 16:37 +0300, Imre Deak wrote:
> On ma, 2015-08-03 at 21:55 +0530, Animesh Manna wrote:
> > While display engine entering into low power state no need to disable
> > cdclk pll as CSR firmware of dmc will take care. If pll is already
> > enabled firmware execution sequence will b
On Fri, 09 Oct 2015, Doug Smythies wrote:
> This started somewhere between Kernel 4.2 and 4.3-rc1,
> but I only noticed it a day ago.
Thanks for the report, please let's follow up at [1].
Thanks,
Jani.
[1] https://bugs.freedesktop.org/show_bug.cgi?id=92414
--
Jani Nikula, Intel Open Source
On Mon, Oct 12, 2015 at 05:07:13PM +0300, Imre Deak wrote:
> On ma, 2015-10-12 at 16:37 +0300, Imre Deak wrote:
> > On ma, 2015-08-03 at 21:55 +0530, Animesh Manna wrote:
> > > While display engine entering into low power state no need to disable
> > > cdclk pll as CSR firmware of dmc will take car
On ma, 2015-10-12 at 16:46 +0200, Patrik Jakobsson wrote:
> On Mon, Oct 12, 2015 at 05:07:13PM +0300, Imre Deak wrote:
> > On ma, 2015-10-12 at 16:37 +0300, Imre Deak wrote:
> > > On ma, 2015-08-03 at 21:55 +0530, Animesh Manna wrote:
> > > > While display engine entering into low power state no ne
There is an intermitent RAM corruption happening with DMC
micro-controler when in DC6 transitioning to PC9/10. So
the recoomendation is to use DC5 as the deeper DC state
for now until this issue is being investigated at firmware
level.
This macros must be re-worked in order to allow us to use
modu
On 09/18/2015 10:03 AM, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä
>
> Signed-off-by: Ville Syrjälä
> ---
> drivers/gpu/drm/i915/i915_reg.h | 16
> drivers/gpu/drm/i915/intel_hdmi.c | 26 ++
> drivers/gpu/drm/i915/intel_psr.c | 18
On 09/18/2015 10:03 AM, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä
>
> Signed-off-by: Ville Syrjälä
> ---
> drivers/gpu/drm/i915/i915_reg.h | 12 -
> drivers/gpu/drm/i915/intel_i2c.c | 54
> +---
> 2 files changed, 29 insertions(+),
On 09/18/2015 10:03 AM, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä
>
> Always put parens around macro argument evaluations.
>
> Signed-off-by: Ville Syrjälä
> ---
> drivers/gpu/drm/i915/i915_reg.h | 92
> -
> 1 file changed, 46 insertion
On 09/18/2015 10:03 AM, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä
>
> A few register mask defines were missing the '0x' from hex numbers. Or
> at least I assume those were meant to be hex numbers. Put the '0x' in
> place.
>
> Signed-off-by: Ville Syrjälä
> ---
> drivers/gpu/dr
On 09/18/2015 10:03 AM, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä
>
> Signed-off-by: Ville Syrjälä
> ---
> drivers/gpu/drm/i915/i915_irq.c | 31 +--
> 1 file changed, 17 insertions(+), 14 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_irq.c
On 09/18/2015 10:03 AM, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä
>
> The PIPE_FRMCOUNT_GM45 and PIPE_FLIPCOUNT_GM45 names have bothered me
> for a long time. The work equally well for ELK and onwards, so let's
> s/GM45/G4X/.
>
> Signed-off-by: Ville Syrjälä
> ---
> drivers/gp
On 09/18/2015 10:03 AM, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä
>
> Parametrize the SWF registers. This also fixes the register offsets,
> which were mostly garbage in the old defines.
>
> Also save/restore only as many SWF registers that each platform has.
>
> Signed-off-by:
On 09/22/2015 09:50 AM, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä
>
> Drop some useless 'reg' variables when we only use them once.
>
> v2: A few more, including a few variable moves
>
> Signed-off-by: Ville Syrjälä
> ---
> drivers/gpu/drm/i915/i915_irq.c | 3 +-
> driv
On 09/18/2015 10:03 AM, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä
>
> Keep single 'lvds_reg' and 'lvds' variable around in
> intel_lvds_init(), and read it just once at the start.
>
> Also intel_lvds_get_config() doesn't need to figure out which reg to use
> since it can just co
On 09/18/2015 10:03 AM, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä
>
> Signed-off-by: Ville Syrjälä
> ---
> drivers/gpu/drm/i915/intel_uncore.c | 16
> 1 file changed, 8 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_uncore.c
> b/dri
On Mon, Oct 12, 2015 at 08:54:56AM -0700, Jesse Barnes wrote:
> On 09/18/2015 10:03 AM, ville.syrj...@linux.intel.com wrote:
> > From: Ville Syrjälä
> >
> > Signed-off-by: Ville Syrjälä
> > ---
> > drivers/gpu/drm/i915/i915_reg.h | 16
> > drivers/gpu/drm/i915/intel_hdmi.c |
On Mon, Oct 12, 2015 at 09:07:17AM -0700, Jesse Barnes wrote:
> On 09/18/2015 10:03 AM, ville.syrj...@linux.intel.com wrote:
> > From: Ville Syrjälä
> >
> > Parametrize the SWF registers. This also fixes the register offsets,
> > which were mostly garbage in the old defines.
> >
> > Also save/re
From: Ville Syrjälä
v2: Keep using the same registers (PCH_*) instead of accidentally
starting to use the other ones (BXT_*)2) (Jesse)
Reviewed-by: Jesse Barnes
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/i915_reg.h | 8
1 file changed, 4 insertions(+), 4 deletions(-)
On Sat, 2015-10-10 at 00:59 +0530, Shashank Sharma wrote:
> BDW/SKL/BXT support Color Space Conversion (CSC) using a 3x3 matrix
> that needs to be programmed into respective CSC registers.
>
> This patch does the following:
> 1. Adds the core function to program CSC correction values for
>BDW/
This patch series adds handling for getting mode and timing parameters
for BXT DSI.
MIPI DSI for BXT uses a separate trasncoder, hence special handling is
needed to address this.
Floating version 1 of the patches to get the feedback and address the
BXT DSI HW devaition and corresponding SW desig
During bootup, mipi display was blanking in BXT. This is because during
driver load, though encoder, connector were active but crtc returned
inactive. This caused sanitize function to disable the DSI panel. In AOS,
this is fine since HWC will do a modeset and crtc, connector, encoder
mapping will b
Fixed dsi crtc state. Updated the get config function
and handled the DSI and DDI encoder cases.
BXT DSI have to be handled differently from rest of the encoders.
Reading the port control register to determine if DSI is enabled.
Generalizing it for all existing platforms.
Signed-off-by: Uma Shank
For BXT DSI, vtotal, vactive, hactive registers are different.
Making changes to intel_crtc_mode_get() and get_pipe_timings(),
to read the correct registers for BXT DSI.
Signed-off-by: Uma Shankar
Signed-off-by: Vandana Kannan
---
drivers/gpu/drm/i915/intel_display.c | 48
On Mon, Oct 12, 2015 at 10:55:02PM +0530, Uma Shankar wrote:
> For BXT DSI, vtotal, vactive, hactive registers are different.
> Making changes to intel_crtc_mode_get() and get_pipe_timings(),
> to read the correct registers for BXT DSI.
>
> Signed-off-by: Uma Shankar
> Signed-off-by: Vandana Kann
On Sat, 2015-10-10 at 00:59 +0530, Shashank Sharma wrote:
> BDW/SKL/BXT supports Degamma color correction feature, which
> linearizes the non-linearity due to gamma encoded color values.
> This will be applied before Color Transformation.
>
> This patch does the following:
> 1. Adds the core funct
On Sat, 2015-10-10 at 00:59 +0530, Shashank Sharma wrote:
> BDW/SKL/BXT platforms support various Gamma correction modes
> which are:
> 1. Legacy 8-bit mode
> 2. 10-bit Split Gamma mode
> 3. 12-bit mode
>
> This patch does the following:
> 1. Adds the core function to program Gamma correction valu
On Sat, 2015-10-10 at 00:59 +0530, Shashank Sharma wrote:
> I915 color manager registers pipe degamma correction as palette
> correction before CTM, DRM property.
>
> This patch adds the no of coefficients(65) for degamma correction
> as "num_samples_before_ctm" parameter in device info structures
What's the next step on this patch?
Gavin Hindman
Senior Program Manager
SSG/OTC – Open Source Technology Center
-Original Message-
From: Intel-gfx [mailto:intel-gfx-boun...@lists.freedesktop.org] On Behalf Of
Ville Syrjälä
Sent: Thursday, September 24, 2015 10:10 AM
To: Zanoni, Paulo R
On Mon, Oct 12, 2015 at 06:19:52PM +, Hindman, Gavin wrote:
> What's the next step on this patch?
I think my branch is nearing usable state. But I haven't actually tested
on SKL yet, which means not tested 90/270 rotation either. That's pretty
much the next thing on my list.
>
> Gavin Hindma
On Mon, 2015-10-12 at 09:01 +0200, Daniel Vetter wrote:
> On Fri, Oct 09, 2015 at 06:16:25PM -0400, Dan Williams wrote:
> > i915 expects the OpRegion to be cached (i.e. not __iomem), so explicitly
> > map it with memremap rather than the implied cache setting of
> > acpi_os_ioremap().
> >
> > Cc:
The current DC6 functionality is stable enough for development and is badly
needed for working down other platform power issues. I'm fine if you want to
disable it by default, but please only do so in conjunction with i915 kernel
override flags to reenable it at runtime.
Gavin Hindman
Senior P
On Thu, 2015-10-08 at 12:02 +0100, Chris Wilson wrote:
> On Thu, Oct 08, 2015 at 11:54:29AM +0530, ankitprasad.r.sha...@intel.com
> wrote:
> > + /* stolen objects are already pinned to prevent shrinkage */
> > + memset(&node, 0, sizeof(node));
> > + ret = drm_mm_insert_node_in_range_generic(
52 matches
Mail list logo
