On Tue, May 27, 2014 at 11:17 PM, Imre Deak wrote:
> On Tue, 2014-05-27 at 22:58 +0200, Daniel Vetter wrote:
>> Looks like work for Imre or someone else from the runtime pm gang.
>>
>> Cc: Imre Deak
>> Signed-off-by: Daniel Vetter
>> ---
>> drivers/gpu/drm/i915/i915_irq.c | 4
>> 1 file ch
On 05/19 14:48, Matt Roper wrote:
> Intel hardware allows the primary plane to be disabled independently of
> the CRTC. Provide custom primary plane handling to allow this.
>
> v8:
> - Pin/unpin properly when clipping causes the primary plane to be
>disabled when it has previously been enabl
Signed-off-by: Rodrigo Vivi
---
src/intel_module.c | 10 ++
1 file changed, 10 insertions(+)
diff --git a/src/intel_module.c b/src/intel_module.c
index 223ea81..668c45e 100644
--- a/src/intel_module.c
+++ b/src/intel_module.c
@@ -224,6 +224,16 @@ static const SymTabRec intel_chipsets[] =
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
Some registers set during setup might not be persistent after suspend/resume.
This was causing bugs for some people that was unable to get PSR entry state
after resume cycle.
v2: Adding some comments and better commit message explaining why this is
needed.
Signed-off-by: Rodrigo Vivi
---
drive
After the split-out of crtc locks from the big mode_config.mutex
there's still two major areas it protects:
- Various connector probe states, like connector->status, EDID
properties, probed mode lists and similar information.
- The links from connector->encoder and encoder->crtc and other
modes
On Tue, 2014-05-27 at 22:58 +0200, Daniel Vetter wrote:
> Looks like work for Imre or someone else from the runtime pm gang.
>
> Cc: Imre Deak
> Signed-off-by: Daniel Vetter
> ---
> drivers/gpu/drm/i915/i915_irq.c | 4
> 1 file changed, 4 insertions(+)
>
> diff --git a/drivers/gpu/drm/i91
Looks like work for Imre or someone else from the runtime pm gang.
Cc: Imre Deak
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/i915/i915_irq.c | 4
1 file changed, 4 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index 4ef642348450..4dbdd3b
On Tue, May 27, 2014 at 10:32:47PM +0300, Ville Syrjälä wrote:
> On Fri, May 23, 2014 at 01:16:40PM -0700, Jesse Barnes wrote:
> > This is a bit like the CMN reset de-assert we do in DPIO_CTL, except
> > that it resets the whole common lane section of the PHY. This is
> > required on machines wher
On Fri, May 23, 2014 at 01:16:43PM -0700, Jesse Barnes wrote:
> There may be a dependency here.
>
> Signed-off-by: Jesse Barnes
Hm, this implicit ordering is a bit funky imo ... If this increase in
complexity in furture platforms I think we should switch to epxlicit
depencies and grab references
On Fri, May 23, 2014 at 01:16:40PM -0700, Jesse Barnes wrote:
> This is a bit like the CMN reset de-assert we do in DPIO_CTL, except
> that it resets the whole common lane section of the PHY. This is
> required on machines where the BIOS doesn't do this for us on boot or
> resume to properly re-ca
From: Ville Syrjälä
During a GPU reset we need to get pending page flip cleared out
since the ring contents are gone and flip will never complete
on its own. This used to work until the mmio vs. CS flip race
detection came about. That piece of code is looking for a
specific surface address in the
From: Ville Syrjälä
Make sure DSPSURF will change during the panning operation
in flip-vs-panning-vs-hang.
This will now test agains bugs between the kernel's mmio vs.
CS flip race handling and GPU resets. If the kernel is buggy
if will fail to notice that the panning operation changed the
base
The always-on power well pixel path on haswell is routed such that it
bypasses the panel fitter when we use is. Which means the pfit CRC
source won't work in that configuration.
Add a new disallow-bypass flags to the pfit pipe config state and set
it when we want to use the pf CRC. Results in a bi
On Tue, 27 May 2014, Daniel Vetter wrote:
> On Tue, May 27, 2014 at 07:24:12PM +0300, Jani Nikula wrote:
>> If both KMS is disabled (by i915.modeset=0 or nomodeset parameters) and
>> UMS is disabled (by CONFIG_DRM_I915_UMS=n, the default), the user might
>> not be aware his setup is not supported.
On Tue, May 27, 2014 at 06:37:20PM +0100, Damien Lespiau wrote:
> On Tue, May 27, 2014 at 10:12:07AM +0200, Daniel Vetter wrote:
> > diff --git a/drivers/gpu/drm/i915/intel_drv.h
> > b/drivers/gpu/drm/i915/intel_drv.h
> > index 0542de982260..6d86820d350b 100644
> > --- a/drivers/gpu/drm/i915/intel
On Tue, May 27, 2014 at 10:31:43AM -0700, Jesse Barnes wrote:
> On Thu, 22 May 2014 23:57:02 +0200
> Daniel Vetter wrote:
>
> > On Thu, May 22, 2014 at 05:28:05PM -0300, Paulo Zanoni wrote:
> > > 2014-04-24 18:55 GMT-03:00 Daniel Vetter :
> > > > The pch encoder case really isn't anything generic
On Tue, May 27, 2014 at 10:12:07AM +0200, Daniel Vetter wrote:
> diff --git a/drivers/gpu/drm/i915/intel_drv.h
> b/drivers/gpu/drm/i915/intel_drv.h
> index 0542de982260..6d86820d350b 100644
> --- a/drivers/gpu/drm/i915/intel_drv.h
> +++ b/drivers/gpu/drm/i915/intel_drv.h
> @@ -327,6 +327,7 @@ stru
On Thu, 22 May 2014 23:57:02 +0200
Daniel Vetter wrote:
> On Thu, May 22, 2014 at 05:28:05PM -0300, Paulo Zanoni wrote:
> > 2014-04-24 18:55 GMT-03:00 Daniel Vetter :
> > > The pch encoder case really isn't anything generic on hsw:
> > > - It's for the vga port only and
> > > - the vga port does
On Tue, May 27, 2014 at 07:24:12PM +0300, Jani Nikula wrote:
> If both KMS is disabled (by i915.modeset=0 or nomodeset parameters) and
> UMS is disabled (by CONFIG_DRM_I915_UMS=n, the default), the user might
> not be aware his setup is not supported. Inform the users (and, by
> extension, the poor
On Tue, May 27, 2014 at 04:45:24PM +0100, tim.g...@intel.com wrote:
> From: Tim Gore
>
> The kms_mmio_vs_cs_flip test uses igt_kms.c which in turn
> uses cairo. So in Android.mk add this test to the skip list
> if we dont have cairo
>
> Signed-off-by: Tim Gore
Merged.
-Daniel
> ---
> tests/A
On Tue, May 27, 2014 at 07:33:59PM +0530, Shobhit Kumar wrote:
> It seems by default the VBT has MIPI configuration block as well. The
> Generic driver will assume always MIPI if MIPI configuration block is found.
> This is causing probelm when actually there is eDP. Fix this by looking
> into gene
Hi Dave -
Fixes from Chris, all cc: stable.
BR,
Jani.
The following changes since commit c7208164e66f63e3ec1759b98087849286410741:
Linux 3.15-rc7 (2014-05-25 16:06:00 -0700)
are available in the git repository at:
git://anongit.freedesktop.org/drm-intel tags/drm-intel-fixes-2014-05-27
On Tue, May 27, 2014 at 03:35:44PM +0100, Damien Lespiau wrote:
> On Tue, May 27, 2014 at 05:31:42PM +0300, Ville Syrjälä wrote:
> > On Tue, May 27, 2014 at 03:17:15PM +0100, Damien Lespiau wrote:
> > > Sorry to be such a bore but:
> > >
> > > On Tue, May 27, 2014 at 07:33:59PM +0530, Shobhit Kuma
On Tue, May 27, 2014 at 03:39:37PM +0100, Damien Lespiau wrote:
> On Tue, May 27, 2014 at 08:04:43PM +0530, Kumar, Shobhit wrote:
> > On 5/27/2014 7:49 PM, Damien Lespiau wrote:
> > >On Tue, May 27, 2014 at 07:23:46PM +0530, Shobhit Kumar wrote:
> > >>Fix warnings introduced by the following commit
On Wed, Apr 09, 2014 at 08:18:03PM +0100, Damien Lespiau wrote:
> On Wed, Apr 09, 2014 at 01:29:08PM +0300, ville.syrj...@linux.intel.com wrote:
> > From: Ville Syrjälä
> >
> > These are just single registers so wasting space for the pipe offsets
> > seems a bit pointless. So just use the _PIPE3(
On Tue, May 27, 2014 at 03:27:23PM +0100, Damien Lespiau wrote:
> On Mon, Mar 24, 2014 at 11:00:07PM +0530, sourab.gu...@intel.com wrote:
> > From: Akash Goel
> >
> > For disabling L3 clock gating we need to set bit 25 of MMIO
> > register 940c. Earlier this was being done by just writing 1
> > i
On 5/27/2014 9:30 PM, Imre Deak wrote:
If we disable first the port (by disabling DPI) and only then the
display pipe the pipe-off flag will never be set, possibly leading to a
hanged pipe state at the next modeset-enable.
Note that according to the VLV2 display cluster HAS, we should disable
th
If both KMS is disabled (by i915.modeset=0 or nomodeset parameters) and
UMS is disabled (by CONFIG_DRM_I915_UMS=n, the default), the user might
not be aware his setup is not supported. Inform the users (and, by
extension, the poor i915 developers having to read their dmesgs in bug
reports) why thei
If we disable first the port (by disabling DPI) and only then the
display pipe the pipe-off flag will never be set, possibly leading to a
hanged pipe state at the next modeset-enable.
Note that according to the VLV2 display cluster HAS, we should disable
the port before the pipe. This doesn't seem
Hello i try to get help in this channel or something to do, a ¿next step?...
i fill some bug reports on ubuntu launchpad:
- https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1307797
- https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-intel
/+bug/1313378
But none of these a
On Tue, 2014-05-27 at 21:04 +0530, Kumar, Shobhit wrote:
> On 5/27/2014 8:42 PM, Imre Deak wrote:
> > On Tue, 2014-05-27 at 19:45 +0530, Kumar, Shobhit wrote:
> >> On 5/27/2014 6:45 PM, Imre Deak wrote:
> >>> If we disable first the port (by disabling DPI) and only then the
> >>> display pipe the p
From: Tim Gore
The kms_mmio_vs_cs_flip test uses igt_kms.c which in turn
uses cairo. So in Android.mk add this test to the skip list
if we dont have cairo
Signed-off-by: Tim Gore
---
tests/Android.mk | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/tests/Android.mk b/tests
On Mon, May 26, 2014 at 9:52 AM, Daniel Vetter wrote:
> On Mon, May 26, 2014 at 04:35:39PM +0300, Jani Nikula wrote:
>> As requested by David [1],[2].
>>
>> These are on top of drm-intel-nightly which carries the required core
>> patches adding ->name field to drm_connector and drm_encoder. The i9
On 5/27/2014 8:42 PM, Imre Deak wrote:
On Tue, 2014-05-27 at 19:45 +0530, Kumar, Shobhit wrote:
On 5/27/2014 6:45 PM, Imre Deak wrote:
If we disable first the port (by disabling DPI) and only then the
display pipe the pipe-off flag will never be set, possibly leading to a
hanged pipe state at t
On Tue, 2014-05-27 at 19:45 +0530, Kumar, Shobhit wrote:
> On 5/27/2014 6:45 PM, Imre Deak wrote:
> > If we disable first the port (by disabling DPI) and only then the
> > display pipe the pipe-off flag will never be set, possibly leading to a
> > hanged pipe state at the next modeset-enable.
> >
>
On Mon, May 26, 2014 at 9:35 AM, Jani Nikula wrote:
> Generated using semantic patch:
>
> @@
> expression E;
> @@
>
> - drm_get_connector_name(E)
> + E->name
>
> Signed-off-by: Jani Nikula
> ---
> drivers/gpu/drm/nouveau/dispnv04/dac.c | 2 +-
> drivers/gpu/drm/nouveau/dispnv04/dfp.c |
On Tue, May 27, 2014 at 08:04:43PM +0530, Kumar, Shobhit wrote:
> On 5/27/2014 7:49 PM, Damien Lespiau wrote:
> >On Tue, May 27, 2014 at 07:23:46PM +0530, Shobhit Kumar wrote:
> >>Fix warnings introduced by the following commit -
> >>
> >>commit 9c92da2c7c17eea79b6321b37592df0a002d24df
> >>Author:
On Tue, May 27, 2014 at 03:17:15PM +0100, Damien Lespiau wrote:
> Sorry to be such a bore but:
>
> On Tue, May 27, 2014 at 07:33:59PM +0530, Shobhit Kumar wrote:
> > --- a/drivers/gpu/drm/i915/intel_dsi.c
> > +++ b/drivers/gpu/drm/i915/intel_dsi.c
> > @@ -660,6 +660,10 @@ bool intel_dsi_init(struc
On Tue, May 27, 2014 at 05:31:42PM +0300, Ville Syrjälä wrote:
> On Tue, May 27, 2014 at 03:17:15PM +0100, Damien Lespiau wrote:
> > Sorry to be such a bore but:
> >
> > On Tue, May 27, 2014 at 07:33:59PM +0530, Shobhit Kumar wrote:
> > > --- a/drivers/gpu/drm/i915/intel_dsi.c
> > > +++ b/drivers/
On 5/27/2014 7:49 PM, Damien Lespiau wrote:
On Tue, May 27, 2014 at 07:23:46PM +0530, Shobhit Kumar wrote:
Fix warnings introduced by the following commit -
commit 9c92da2c7c17eea79b6321b37592df0a002d24df
Author: Shobhit Kumar
Date: Fri May 23 21:35:27 2014 +0530
drm/i915: Add support
On 5/27/2014 7:47 PM, Damien Lespiau wrote:
Sorry to be such a bore but:
On Tue, May 27, 2014 at 07:33:59PM +0530, Shobhit Kumar wrote:
--- a/drivers/gpu/drm/i915/intel_dsi.c
+++ b/drivers/gpu/drm/i915/intel_dsi.c
@@ -660,6 +660,10 @@ bool intel_dsi_init(struct drm_device *dev)
DRM_DEB
On Mon, Mar 24, 2014 at 11:00:07PM +0530, sourab.gu...@intel.com wrote:
> From: Akash Goel
>
> For disabling L3 clock gating we need to set bit 25 of MMIO
> register 940c. Earlier this was being done by just writing 1
> into bit 25 and resetting all other bits.
> This patch modifies the routine t
On Tue, May 27, 2014 at 07:23:46PM +0530, Shobhit Kumar wrote:
> Fix warnings introduced by the following commit -
>
> commit 9c92da2c7c17eea79b6321b37592df0a002d24df
> Author: Shobhit Kumar
> Date: Fri May 23 21:35:27 2014 +0530
>
> drm/i915: Add support for Generic MIPI panel driver
>
>
Sorry to be such a bore but:
On Tue, May 27, 2014 at 07:33:59PM +0530, Shobhit Kumar wrote:
> --- a/drivers/gpu/drm/i915/intel_dsi.c
> +++ b/drivers/gpu/drm/i915/intel_dsi.c
> @@ -660,6 +660,10 @@ bool intel_dsi_init(struct drm_device *dev)
>
> DRM_DEBUG_KMS("\n");
>
> + /* There is
On 5/27/2014 6:45 PM, Imre Deak wrote:
If we disable first the port (by disabling DPI) and only then the
display pipe the pipe-off flag will never be set, possibly leading to a
hanged pipe state at the next modeset-enable.
Note that according to the VLV2 display cluster HAS, we should disable
th
It seems by default the VBT has MIPI configuration block as well. The
Generic driver will assume always MIPI if MIPI configuration block is found.
This is causing probelm when actually there is eDP. Fix this by looking
into general definition block which will have device configurations. From here
w
Fix warnings introduced by the following commit -
commit 9c92da2c7c17eea79b6321b37592df0a002d24df
Author: Shobhit Kumar
Date: Fri May 23 21:35:27 2014 +0530
drm/i915: Add support for Generic MIPI panel driver
Fixed all except the DRM logging which go beyond line 80
Signed-off-by: Shobhit
ville.syrj...@linux.intel.com writes:
> From: Ville Syrjälä
>
> Try to force the PHY clock buffer enables to make the clock routing
> work.
>
> v2: Fix the pipe B case to actually enable CH0 clock buffers
>
> Signed-off-by: Ville Syrjälä
Reviewed-by: Mika Kuoppala
> ---
> drivers/gpu/drm/i91
ville.syrj...@linux.intel.com writes:
> From: Ville Syrjälä
>
> Now that we forced the clock buffers on in .pre_pll_enable() we
> should probably undo the damage after we've turned the PLL off.
>
> We do the clock buffer force enable in the .pre_pll_enable() hook
> as we need to know which port i
ville.syrj...@linux.intel.com writes:
> From: Ville Syrjälä
>
> These should make it possible to feed port C from pipe A or port B from
> pipe B. Didn't quite seem to work though.
>
> Signed-off-by: Ville Syrjälä
Reviewed-by: Mika Kuoppala
> ---
> drivers/gpu/drm/i915/i915_reg.h | 7 +
From: Ville Syrjälä
Now that we forced the clock buffers on in .pre_pll_enable() we
should probably undo the damage after we've turned the PLL off.
We do the clock buffer force enable in the .pre_pll_enable() hook
as we need to know which port is going to be used, but in the disable
case we don'
From: Ville Syrjälä
Try to force the PHY clock buffer enables to make the clock routing
work.
v2: Fix the pipe B case to actually enable CH0 clock buffers
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/i915_reg.h | 18 ++
drivers/gpu/drm/i915/intel_dp.c | 19 +++
On Tue, May 27, 2014 at 06:26:22PM +0530, Shobhit Kumar wrote:
> It seems by default the VBT has MIPI configuration block as well. The
> Generic driver will assume always MIPI if MIPI configuration block is found.
> This is causing probelm when actually there is eDP. Fix this by looking
> into gene
If we disable first the port (by disabling DPI) and only then the
display pipe the pipe-off flag will never be set, possibly leading to a
hanged pipe state at the next modeset-enable.
Note that according to the VLV2 display cluster HAS, we should disable
the port before the pipe. This doesn't seem
On Tue, May 27, 2014 at 03:52:55PM +0300, Ville Syrjälä wrote:
> On Thu, May 22, 2014 at 08:06:31PM +0530, sourab.gu...@intel.com wrote:
> > From: Sourab Gupta
> >
> > Using MMIO based flips on Gen5+. The MMIO flips are useful for the Media
> > power
> > well residency optimization. These maybe
Mika Kuoppala writes:
> ville.syrj...@linux.intel.com writes:
>
>> From: Ville Syrjälä
>>
>> These should make it possible to feed port C from pipe A or port B from
>> pipe B. Didn't quite seem to work though.
>>
>> Signed-off-by: Ville Syrjälä
>> ---
>> drivers/gpu/drm/i915/i915_reg.h | 7
It seems by default the VBT has MIPI configuration block as well. The
Generic driver will assume always MIPI if MIPI configuration block is found.
This is causing probelm when actually there is eDP. Fix this by looking
into general definition block which will have device configurations. From here
w
On Thu, May 22, 2014 at 08:06:31PM +0530, sourab.gu...@intel.com wrote:
> From: Sourab Gupta
>
> Using MMIO based flips on Gen5+. The MMIO flips are useful for the Media power
> well residency optimization. These maybe enabled on architectures where
> Render and Blitter engines reside in differen
ville.syrj...@linux.intel.com writes:
> From: Ville Syrjälä
>
> These should make it possible to feed port C from pipe A or port B from
> pipe B. Didn't quite seem to work though.
>
> Signed-off-by: Ville Syrjälä
> ---
> drivers/gpu/drm/i915/i915_reg.h | 7 ++
> drivers/gpu/drm/i915/inte
On Tue, May 27, 2014 at 05:40:23PM +0530, Kumar, Shobhit wrote:
> >>struct {
> >>+ u16 port;
> >
> >We store the port but never use it, is it needed?
>
> Just wanted to store as we might want to use later while enabling.
> Shouldn't harm ? In fact we have a need to enable PORT C inte
On Tue, May 27, 2014 at 01:51:22PM +0200, Daniel Vetter wrote:
> > Hmm, I will check my vim config and be more careful next time. Thanks for
> > pointing out. Have you taken care of these or I will push another patch to
> > fix the alignment issues ?
>
> Yeah, a quick fixup patch would be pretty.
On Tuesday 27 May 2014 05:12 PM, Daniel Vetter wrote:
On Mon, May 26, 2014 at 06:19:07PM +0300, Mika Kuoppala wrote:
deepa...@linux.intel.com writes:
From: Deepak S
Signed-off-by: Deepak S
[vsyrjala: Fix merge fubmle where the code ended up in
g4x_disable_trickle_feed() instead of cherryvi
On Tuesday 27 May 2014 05:29 PM, Ville Syrjälä wrote:
On Tue, May 27, 2014 at 01:42:50PM +0200, Daniel Vetter wrote:
On Mon, May 26, 2014 at 06:19:07PM +0300, Mika Kuoppala wrote:
deepa...@linux.intel.com writes:
From: Deepak S
Signed-off-by: Deepak S
[vsyrjala: Fix merge fubmle where the
On 5/27/2014 5:02 PM, Damien Lespiau wrote:
On Fri, May 23, 2014 at 09:39:28PM +0530, Shobhit Kumar wrote:
It seems by default the VBT has MIPI configuration block as well. The
Generic driver will assume always MIPI if MIPI configuration block is found.
This is causing probelm when actually ther
On Tue, May 27, 2014 at 01:42:50PM +0200, Daniel Vetter wrote:
> On Mon, May 26, 2014 at 06:19:07PM +0300, Mika Kuoppala wrote:
> > deepa...@linux.intel.com writes:
> >
> > > From: Deepak S
> > >
> > > Signed-off-by: Deepak S
> > > [vsyrjala: Fix merge fubmle where the code ended up in
> > > g4x
On Tue, May 27, 2014 at 1:42 PM, Kumar, Shobhit wrote:
> On 5/27/2014 5:09 PM, Daniel Vetter wrote:
>>
>> On Tue, May 27, 2014 at 04:51:55PM +0530, Kumar, Shobhit wrote:
>>>
>>> On 5/27/2014 4:32 PM, Damien Lespiau wrote:
On Fri, May 23, 2014 at 09:35:27PM +0530, Shobhit Kumar wrote:
>>>
On Tue, May 27, 2014 at 01:45:59PM +0300, Mika Kuoppala wrote:
> deepa...@linux.intel.com writes:
>
> > From: Deepak S
> >
> > v2: Disable media turbo and Add DOWN_IDLE_AVG support (Ville)
> >
> > v3: Mass rename of the dev_priv->rps variables in upstream.
> >
> > v4: Rebase against latest code.
On 5/27/2014 5:10 PM, Daniel Vetter wrote:
On Fri, May 23, 2014 at 09:39:28PM +0530, Shobhit Kumar wrote:
It seems by default the VBT has MIPI configuration block as well. The
Generic driver will assume always MIPI if MIPI configuration block is found.
This is causing probelm when actually there
On 5/27/2014 5:09 PM, Daniel Vetter wrote:
On Tue, May 27, 2014 at 04:51:55PM +0530, Kumar, Shobhit wrote:
On 5/27/2014 4:32 PM, Damien Lespiau wrote:
On Fri, May 23, 2014 at 09:35:27PM +0530, Shobhit Kumar wrote:
This driver makes use of the generic panel information from the VBT.
Panel infor
On Mon, May 26, 2014 at 06:19:07PM +0300, Mika Kuoppala wrote:
> deepa...@linux.intel.com writes:
>
> > From: Deepak S
> >
> > Signed-off-by: Deepak S
> > [vsyrjala: Fix merge fubmle where the code ended up in
> > g4x_disable_trickle_feed() instead of cherryview_init_clock_gating()]
> > Signed-o
On Fri, May 23, 2014 at 09:39:28PM +0530, Shobhit Kumar wrote:
> It seems by default the VBT has MIPI configuration block as well. The
> Generic driver will assume always MIPI if MIPI configuration block is found.
> This is causing probelm when actually there is eDP. Fix this by looking
> into gene
On Tue, May 27, 2014 at 04:51:55PM +0530, Kumar, Shobhit wrote:
> On 5/27/2014 4:32 PM, Damien Lespiau wrote:
> >On Fri, May 23, 2014 at 09:35:27PM +0530, Shobhit Kumar wrote:
> >>This driver makes use of the generic panel information from the VBT.
> >>Panel information is classified into two - pan
On Tue, May 27, 2014 at 04:51:55PM +0530, Kumar, Shobhit wrote:
> On 5/27/2014 4:32 PM, Damien Lespiau wrote:
> >On Fri, May 23, 2014 at 09:35:27PM +0530, Shobhit Kumar wrote:
> >>This driver makes use of the generic panel information from the VBT.
> >>Panel information is classified into two - pan
On Fri, May 23, 2014 at 09:39:28PM +0530, Shobhit Kumar wrote:
> It seems by default the VBT has MIPI configuration block as well. The
> Generic driver will assume always MIPI if MIPI configuration block is found.
> This is causing probelm when actually there is eDP. Fix this by looking
> into gene
On 5/27/2014 4:32 PM, Damien Lespiau wrote:
On Fri, May 23, 2014 at 09:35:27PM +0530, Shobhit Kumar wrote:
This driver makes use of the generic panel information from the VBT.
Panel information is classified into two - panel configuration and panel
power sequence which is unique to each panel. T
On Fri, May 23, 2014 at 09:35:27PM +0530, Shobhit Kumar wrote:
> This driver makes use of the generic panel information from the VBT.
> Panel information is classified into two - panel configuration and panel
> power sequence which is unique to each panel. The generic driver uses the
> panel config
deepa...@linux.intel.com writes:
> From: Deepak S
>
> v2: Disable media turbo and Add DOWN_IDLE_AVG support (Ville)
>
> v3: Mass rename of the dev_priv->rps variables in upstream.
>
> v4: Rebase against latest code. (Deepak)
>
> v5: Rebase against latest nightly code. (Deepak)
>
> v6: Rename the
From: Deepak S
v2: Disable media turbo and Add DOWN_IDLE_AVG support (Ville)
v3: Mass rename of the dev_priv->rps variables in upstream.
v4: Rebase against latest code. (Deepak)
v5: Rebase against latest nightly code. (Deepak)
v6: Rename the variables to match the spec (Mika)
v7: change min/
The always-on power well pixel path on haswell is routed such that it
bypasses the panel fitter when we use is. Which means the pfit CRC
source won't work in that configuration.
Add a new disallow-bypass flags to the pfit pipe config state and set
it when we want to use the pf CRC. Results in a bi
On Sat, 17 May 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 tabl
On Mon, May 26, 2014 at 9:44 PM, Pedro Ribeiro wrote:
> Kern.log is attached, but as you can see it does not contain the same
> verbose drm debug information as dmesg... Should I just keep piping
> dmesg to a file and then cat it all together?
> I never really understood why there are so many logs
82 matches
Mail list logo
