On Sat, 09 Nov 2013, Shobhit Kumar wrote:
> The values of these parameters will be different for differnet panel
> based on dsi rate, lane count, etc. Remove the hardcodings and make
> these as parameters whch will be initialized in panel specific
> sub-encoder implementaion.
>
> This will also fo
On Sat, 09 Nov 2013, Shobhit Kumar wrote:
> Pixel clock based calculation is recommended in the MIPI host controller
> documentation
>
> v2: Based on review comments from Jani and Ville
> - Use dsi_clk in KHz rather than converting in Hz and back to MHz
> - RR formula is retained though no
On Sat, 09 Nov 2013, Shobhit Kumar wrote:
> Basically check for both +ive and -ive deviation from target clock and
> pick the one with minimal error. If we get a direct match, break from
> loop to acheive some optimization.
>
> Signed-off-by: Vijayakumar Balakrishnan
> Signed-off-by: Shobhit Kuma
Some system's ACPI video backlight control interface is broken and the
native backlight control interface should be used by default. This patch
sets the use_native_backlight parameter to true for those systems so
that video backlight control interface will not be created. To be
specific, the ThinkP
If an object was bound in the ppgtt, and we do a GPU reset, but the
PPGTT was not brought back up on reset, trying to unbind the object
later will result in a NULL ptr. Ideally this (failed PPGTT) should
never happen, but it is allowed in the code, and therefore we should
prevent the OOPS.
Since B
On Thu, 14 Nov 2013 16:04:23 -0800
Jesse Barnes wrote:
> Read out the current plane configuration at init time into a new
> plane_config structure. This allows us to track any existing
> framebuffers attached to the plane and potentially re-use them in our
> fbdev code for a smooth handoff.
>
>
On Thu, Nov 14, 2013 at 04:04:24PM -0800, Jesse Barnes wrote:
> Retrieve current framebuffer config info from the regs and create an fb
> object for the buffer the BIOS or boot loader left us. This should
> allow for smooth transitions to userspace apps once we finish the
> initial configuration c
On Thu, Nov 14, 2013 at 04:04:23PM -0800, Jesse Barnes wrote:
> Read out the current plane configuration at init time into a new
> plane_config structure. This allows us to track any existing
> framebuffers attached to the plane and potentially re-use them in our
> fbdev code for a smooth handoff.
If we use a stolen buffer, our probe callback shouldn't allocate a new
buffer; we should re-use the one from the BIOS instead if possible.
v2: fix locking (Jesse)
Reviewed-by: Chris Wilson
Signed-off-by: Jesse Barnes
---
drivers/gpu/drm/i915/intel_fbdev.c | 62 -
Read out the current plane configuration at init time into a new
plane_config structure. This allows us to track any existing
framebuffers attached to the plane and potentially re-use them in our
fbdev code for a smooth handoff.
v2: update for new pitch_for_width function (Jesse)
comment how
Retrieve current framebuffer config info from the regs and create an fb
object for the buffer the BIOS or boot loader left us. This should
allow for smooth transitions to userspace apps once we finish the
initial configuration construction.
v2: check for non-native modes and adjust (Jesse)
fi
And move it up in the file for earlier usage.
v2: add pre-gen4 support as well (Chris)
Signed-off-by: Jesse Barnes
---
drivers/gpu/drm/i915/intel_display.c | 53 ++--
1 file changed, 38 insertions(+), 15 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_displ
We want to preserve the BIOS/bootloader contents for later.
Signed-off-by: Jesse Barnes
---
drivers/gpu/drm/i915/intel_fbdev.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/intel_fbdev.c
b/drivers/gpu/drm/i915/intel_fbdev.c
index 5ee5dc0..c7b1adf 10
On Thu, Nov 14, 2013 at 05:40:36PM -0200, Rodrigo Vivi wrote:
> On Thu, Nov 14, 2013 at 09:36:10AM -0800, Olof Johansson wrote:
> > On Thu, Nov 14, 2013 at 8:53 AM, Rodrigo Vivi
> > wrote:
> > > On Wed, Nov 13, 2013 at 05:59:43PM -0800, Olof Johansson wrote:
> > >> From: Duncan Laurie
> > >>
> >
From: Paulo Zanoni
When I submitted the first patch adding these force wake functions,
Chris Wilson observed that I was using the wrong functions, so I sent
a second version of the patch to correct this problem. The problem is
that v1 was merged instead of v2.
I was able to notice the problem wh
On Thu, Nov 14, 2013 at 09:36:10AM -0800, Olof Johansson wrote:
> On Thu, Nov 14, 2013 at 8:53 AM, Rodrigo Vivi wrote:
> > On Wed, Nov 13, 2013 at 05:59:43PM -0800, Olof Johansson wrote:
> >> From: Duncan Laurie
> >>
> >> We had been using a DMI table workaround to select the right
> >> frequency
Hi Daniel,
a couple of comments on your comments. (-;
with the text flown to align to 80 chars. vim will do this for you.
..which I ain't using. "Using" is not a word that goes along well with
"vim". (-; But no, let's not start an editor war here.
+ if (obj->tiling_mode != I915_TILI
On Thu, Nov 14, 2013 at 06:17:03PM +0100, Thomas Richter wrote:
> Dear Daniel, dear intel-experts,
>
> please find a patch for the dreadful pipe-A underruns on the i830
> attached that works at least in the linear framebuffer mode. As far
> as the tiling mode is concerned, I'm still scratching my
On Thu, Nov 14, 2013 at 07:15:52PM +0100, Thomas Richter wrote:
> On 14.11.2013 09:21, Daniel Vetter wrote:
>
> >On gen2/3 the fence registers make a tile range look linear to both
> >the gpu and the cpu. On gen4+ the fence registers are only for access
> >with the cpu, and everything else needs t
From: Duncan Laurie
We had been using a DMI table workaround to select the right
frequency for devices, but this is fragile and must be updated
with every new platform.
Instead the default case when VBT is missing is changed to use
120MHz clock for LVDS SSC for these generations.
The docs for 2
On Thu, Nov 14, 2013 at 8:53 AM, Rodrigo Vivi wrote:
> On Wed, Nov 13, 2013 at 05:59:43PM -0800, Olof Johansson wrote:
>> From: Duncan Laurie
>>
>> We had been using a DMI table workaround to select the right
>> frequency for devices, but this is fragile and must be updated
>> with every new plat
On 14.11.2013 09:21, Daniel Vetter wrote:
On gen2/3 the fence registers make a tile range look linear to both
the gpu and the cpu. On gen4+ the fence registers are only for access
with the cpu, and everything else needs to take tiling into account
explicitly (and there are bits in the registers
On Thu, Nov 14, 2013 at 04:11:38PM +0100, Daniel Vetter wrote:
> v2: Fix more.
>
> Cc: Ben Widawsky
> Signed-off-by: Daniel Vetter
> ---
> lib/intel_batchbuffer.c | 4 +++-
> tests/gem_cs_prefetch.c | 3 ---
> 2 files changed, 3 insertions(+), 4 deletions(-)
>
> diff --git a/lib/intel_batchbuf
Dear Daniel, dear intel-experts,
please find a patch for the dreadful pipe-A underruns on the i830
attached that works at least in the linear framebuffer mode. As far as
the tiling mode is concerned, I'm still scratching my head about it. It
as at this time unclear how precisely this works, bu
On Thu, Nov 14, 2013 at 02:54:10PM +0200, Mika Kuoppala wrote:
> ville.syrj...@linux.intel.com writes:
>
> > From: Ville Syrjälä
> >
> > On VLV GTFIFODBG has more bits. Just report them all.
> >
> > Signed-off-by: Ville Syrjälä
> > ---
> > drivers/gpu/drm/i915/i915_reg.h | 5 -
> > driv
On Wed, Nov 13, 2013 at 05:59:43PM -0800, Olof Johansson wrote:
> From: Duncan Laurie
>
> We had been using a DMI table workaround to select the right
> frequency for devices, but this is fragile and must be updated
> with every new platform.
>
> Instead the default case when VBT is missing is c
On Thu, 14 Nov 2013 15:06:59 +
Chris Wilson wrote:
> On Wed, Nov 13, 2013 at 10:20:45AM -0800, Jesse Barnes wrote:
> > Read out the current plane configuration at init time into a new
> > plane_config structure. This allows us to track any existing
> > framebuffers attached to the plane and
v2: Fix more.
Cc: Ben Widawsky
Signed-off-by: Daniel Vetter
---
lib/intel_batchbuffer.c | 4 +++-
tests/gem_cs_prefetch.c | 3 ---
2 files changed, 3 insertions(+), 4 deletions(-)
diff --git a/lib/intel_batchbuffer.c b/lib/intel_batchbuffer.c
index e284d4870cd6..06a543728579 100644
--- a/lib/i
Cc: Ben Widawsky
Signed-off-by: Daniel Vetter
---
tests/gem_cs_prefetch.c | 3 ---
1 file changed, 3 deletions(-)
diff --git a/tests/gem_cs_prefetch.c b/tests/gem_cs_prefetch.c
index 229a385a2fcd..eb515eadca2e 100644
--- a/tests/gem_cs_prefetch.c
+++ b/tests/gem_cs_prefetch.c
@@ -133,9 +133,6 @
On Wed, Nov 13, 2013 at 10:20:45AM -0800, Jesse Barnes wrote:
> Read out the current plane configuration at init time into a new
> plane_config structure. This allows us to track any existing
> framebuffers attached to the plane and potentially re-use them in our
> fbdev code for a smooth handoff.
We don't actually do anything with the information yet, but parse and
log what's in the VBT.
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/i915_drv.h |5 +
drivers/gpu/drm/i915/intel_bios.c | 29 +
drivers/gpu/drm/i915/intel_bios.h | 16 +++
Checkpatch tells me
WARNING: __packed is preferred over __attribute__((packed))
so switch over to __packed across the driver before adding new packed
structs.
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/intel_bios.h | 48
drivers/gpu/drm/i915/int
From: Deepak S
Added media/render/common well VLV force wake routines to help
bring up the WELLS before access the register
- Refactor current vlv_forcewake get/put and added MEDIA or
RENDER specific Forcewake.
- Added VLV Check to bring up MEDIA and RENDER WELL base
on the register accessed
In intel_display_capture_error_state we use HAS_POWER_WELL to check if
we are running on Haswell/Broadwell when accessing HSW_PWR_WELL_DRIVER
which is specific to these platforms. Future platforms with power wells
don't have this register, so HAS_POWER_WELL won't work there any more.
Use IS_HASWELL
So far we distinguished platforms without a dynamic power well with
the HAS_POWER_WELL macro and for such platforms we didn't call any power
domain functions. Instead of doing this check we can add an always-on
power well for these platforms and call the power domain functions
unconditionally. For
Add a debugfs entry showing the use-count for all power domains of each
power well.
Signed-off-by: Imre Deak
---
drivers/gpu/drm/i915/i915_debugfs.c | 69 +
drivers/gpu/drm/i915/i915_drv.h | 4 +++
drivers/gpu/drm/i915/intel_pm.c | 16 ++---
3 fil
This way the code is simpler and can also be used for other platforms
where the audio power domain->power well mapping is different.
Signed-off-by: Imre Deak
Reviewed-by: Paulo Zanoni
---
drivers/gpu/drm/i915/i915_drv.h | 1 +
drivers/gpu/drm/i915/intel_pm.c | 10 ++
2 files changed, 3
Instead of using a separate function to check whether a power domain is
is always on, add an always-on power well covering all these power
domains and do the usual get/put on these unconditionally. Since we
don't assign a .set handler for these the get/put won't have any effect
besides the adjusted
Signed-off-by: Imre Deak
---
drivers/gpu/drm/i915/intel_pm.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index ee5aeb1..d5eacd8 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -5912,
From: Jesse Barnes
This may need work if other platforms do the same thing, but in the
meantime we should avoid looking at HSW specific bits in this generic
function.
Signed-off-by: Jesse Barnes
Reviewed-by: Paulo Zanoni
[added IS_BROADWELL too as that needs the same handling (Imre)]
---
driv
This is just a rebase on the latest kernel and additional debug info on
domain use counts in patch 8.
Imre Deak (7):
drm/i915: add audio power domain
drm/i915: support for multiple power wells
drm/i915: add always-on power wells instead of special casing them
drm/i915: use IS_HASWELL/BROAD
HW generations so far had only one always-on power well and optionally
one dynamic power well. Upcoming HW gens may have multiple dynamic power
wells, so add some infrastructure to support them.
The idea is to keep the existing power domain API used by the rest of
the driver and create a mapping b
ville.syrj...@linux.intel.com writes:
> From: Ville Syrjälä
>
> On VLV GTFIFODBG has more bits. Just report them all.
>
> Signed-off-by: Ville Syrjälä
> ---
> drivers/gpu/drm/i915/i915_reg.h | 5 -
> drivers/gpu/drm/i915/intel_uncore.c | 5 ++---
> 2 files changed, 6 insertions(+), 4 de
On Thu, Nov 14, 2013 at 10:53:10AM +, Damien Lespiau wrote:
> On Thu, Nov 14, 2013 at 11:30:42AM +0100, Daniel Vetter wrote:
> > We have a nice macro, so use it.
> >
> > Signed-off-by: Daniel Vetter
>
> For both patches:
>
> Reviewed-by: Damien Lespiau
Thanks for the review, both merged t
On Wed, Nov 13, 2013 at 08:05:40PM +0200, Imre Deak wrote:
> On Wed, 2013-11-13 at 12:56 +0200, Jani Nikula wrote:
> > The backlight enable code now has the smarts to do the right thing. Only
> > do backlight register save/restore in UMS.
> >
> > Some VLV specific code gets dropped as UMS is not s
On Thu, Nov 14, 2013 at 11:30:42AM +0100, Daniel Vetter wrote:
> We have a nice macro, so use it.
>
> Signed-off-by: Daniel Vetter
For both patches:
Reviewed-by: Damien Lespiau
--
Damien
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
ht
We have a nice macro, so use it.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/i915/i915_debugfs.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
b/drivers/gpu/drm/i915/i915_debugfs.c
index 6875b7a0f0cd..09e7f7beeb61 100644
--- a
We don't init the lock nor set up all the other state. And it doesn't
make sense anyway.
This appeases lockdep when running the igt/drv_debugfs_reader test.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/i915/i915_debugfs.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/gpu/dr
On Thu, 2013-11-14 at 12:14 +0200, Jani Nikula wrote:
> The quirk was added as what I'd say was a stopgap measure in
>
> commit e85843bec6c2ea7c10ec61238396891cc2b753a9
> Author: Kamal Mostafa
> Date: Fri Jul 19 15:02:01 2013 -0700
>
> drm/i915: quirk no PCH_PWM_ENABLE for Dell XPS13 backl
On Thu, 2013-11-14 at 12:13 +0200, Jani Nikula wrote:
> We should now have all the information we need to do a full
> initialization of the backlight registers.
>
> v2: Keep QUIRK_NO_PCH_PWM_ENABLE for now (Imre).
>
> Signed-off-by: Jani Nikula
Looks ok:
Reviewed-by: Imre Deak
> ---
> driver
The quirk was added as what I'd say was a stopgap measure in
commit e85843bec6c2ea7c10ec61238396891cc2b753a9
Author: Kamal Mostafa
Date: Fri Jul 19 15:02:01 2013 -0700
drm/i915: quirk no PCH_PWM_ENABLE for Dell XPS13 backlight
without really digging into what was going on.
Also, as menti
We should now have all the information we need to do a full
initialization of the backlight registers.
v2: Keep QUIRK_NO_PCH_PWM_ENABLE for now (Imre).
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/intel_panel.c | 149 ++--
1 file changed, 93 insertions(+)
On Thu, 2013-11-14 at 07:43 +0200, Jani Nikula wrote:
> On Wed, 13 Nov 2013, Imre Deak wrote:
> > On Fri, 2013-11-08 at 16:49 +0200, Jani Nikula wrote:
> >> We should now have all the information we need to do a full
> >> initialization of the backlight registers.
> >>
> >> Signed-off-by: Jani Ni
On Thu, Nov 14, 2013 at 07:43:07AM +0200, Jani Nikula wrote:
> On Wed, 13 Nov 2013, Imre Deak wrote:
> > On Fri, 2013-11-08 at 16:49 +0200, Jani Nikula wrote:
> >> We should now have all the information we need to do a full
> >> initialization of the backlight registers.
> >>
> >> Signed-off-by:
On Thu, 2013-11-14 at 07:19 +0200, Jani Nikula wrote:
> On Wed, 13 Nov 2013, Imre Deak wrote:
> > On Fri, 2013-11-08 at 16:49 +0200, Jani Nikula wrote:
> >> Prepare for being able to use the information at enable.
> >>
> >> Signed-off-by: Jani Nikula
> >> ---
> >> drivers/gpu/drm/i915/intel_drv
On Thu, Nov 14, 2013 at 8:14 AM, Thomas Richter wrote:
> Are you *really sure* GEN2 does have tiling? Or could it be that this bit is
> used for something else and probably turns on some weird powersaving feature
> that creates some mischief with the FIFO? After all, a tile cannot always be
> 128
On Thu, Nov 14, 2013 at 8:29 AM, Aaron Lu wrote:
> On 11/14/2013 02:24 PM, Jani Nikula wrote:
>>
>> Hi Mario -
>>
>> On Wed, 13 Nov 2013, Mario Kleinsasser
>> wrote:
>>> In the last three weeks I've narrowed down the bug described in the
>>> subject through Ubuntu launchpad. My new Laptop (Acer
57 matches
Mail list logo
