Removes some functions that are not used anywhere:
vlv_flisdsi_read() vlv_gps_core_write() vlv_gps_core_read()
vlv_ccu_write() vlv_ccu_read() vlv_gpio_nc_read()
This was partially found by using a static code analysis program called
cppcheck.
Signed-off-by: Rickard Strandqvist
---
drivers/gpu/
Remove the function intel_dp_set_drrs_state() that is not used anywhere.
This was partially found by using a static code analysis program called
cppcheck.
Signed-off-by: Rickard Strandqvist
---
drivers/gpu/drm/i915/intel_dp.c | 89 --
drivers/gpu/drm/i915
Remove the function intel_output_name() that is not used anywhere.
This was partially found by using a static code analysis program called
cppcheck.
Signed-off-by: Rickard Strandqvist
---
drivers/gpu/drm/i915/intel_display.c | 22 --
drivers/gpu/drm/i915/intel_drv.h |
Hi Julia,
On Mon, Dec 8, 2014 at 6:20 AM, Julia Lawall wrote:
> These patches replace what appears to be a reference to the name of the
> current function but is misspelled in some way by either the name of the
> function itself, or by %s and then __func__ in an argument list.
Would there be any
Remove the function dsi_rr_formula() that is not used anywhere.
This was partially found by using a static code analysis program called
cppcheck.
Signed-off-by: Rickard Strandqvist
---
drivers/gpu/drm/i915/intel_dsi_pll.c | 83 +-
1 file changed, 1 insertion(+
well on my arch machine with an intel gma 4 graphics card using
xfree86-video-intel im seeing lots of graphics corruption i can
give images it it would help
--
Fennec
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop
Remove the function dsi_hs_mode_enable() that is not used anywhere.
This was partially found by using a static code analysis program called
cppcheck.
Signed-off-by: Rickard Strandqvist
---
drivers/gpu/drm/i915/intel_dsi_cmd.c | 21 -
drivers/gpu/drm/i915/intel_dsi_cmd.h |
On Fri, Dec 05, 2014 at 11:29:09PM -0600, Fennec Fox wrote:
> well on my arch machine with an intel gma 4 graphics card using
> xfree86-video-intel im seeing lots of graphics corruption i can
> give images it it would help
I presume you filed https://bugs.freedesktop.org/show_bug.cgi?id=87065
a
On Sun, Dec 07, 2014 at 07:29:17PM +0100, Rickard Strandqvist wrote:
> Remove the function intel_output_name() that is not used anywhere.
>
> This was partially found by using a static code analysis program called
> cppcheck.
>
> Signed-off-by: Rickard Strandqvist
Queued for 3.20, thanks for t
On Fri, Dec 05, 2014 at 08:14:24PM -0500, Rodrigo Vivi wrote:
> Sink CRC is the most reliable way to test PSR. However in some platforms
> apparently auto generated packages force panel to keep calculating CRC
> invalidating
> our current sink crc check over debugfs.
>
> So, this manual test help
On Fri, Dec 05, 2014 at 08:40:42PM -0500, Rodrigo Vivi wrote:
> Since active function on VLV immediately activate PSR let's give more
> time for idleness.
>
> v2: Rebase over intel_psr.c and fix typo.
> v3: Revival: Manual tests indicated that this is needed. With a short delay
> there is a huge
On Mon, Dec 08, 2014 at 01:23:37PM +1000, Dave Airlie wrote:
> From: Dave Airlie
>
> Otherwise the MST resume paths can hit DPMS paths
> which hit state checker paths, which hit WARN_ON,
> because the state checker is inconsistent with the
> hw.
>
> This fixes a bunch of WARN_ON's on resume afte
On Mon, Dec 08, 2014 at 10:44:54AM +0100, Daniel Vetter wrote:
> On Mon, Dec 08, 2014 at 01:23:37PM +1000, Dave Airlie wrote:
> > From: Dave Airlie
> >
> > Otherwise the MST resume paths can hit DPMS paths
> > which hit state checker paths, which hit WARN_ON,
> > because the state checker is inco
On Sa, 2014-12-06 at 12:17 +0800, Jike Song wrote:
> On 12/05/2014 04:50 PM, Gerd Hoffmann wrote:
> > A few comments on the kernel stuff (brief look so far, also
> > compile-tested only, intel gfx on my test machine is too old).
> >
> > * Noticed the kernel bits don't even compile when configured
On Sun, 07 Dec 2014, Rickard Strandqvist
wrote:
> Removes some functions that are not used anywhere:
> vlv_flisdsi_read() vlv_gps_core_write() vlv_gps_core_read()
> vlv_ccu_write() vlv_ccu_read() vlv_gpio_nc_read()
I'd let them be.
BR,
Jani.
>
> This was partially found by using a static code
On Mon, Dec 08, 2014 at 10:55:01AM +0100, Gerd Hoffmann wrote:
> On Sa, 2014-12-06 at 12:17 +0800, Jike Song wrote:
> > I don't know that is exactly needed, we also need to have Windows
> > driver considered. However, I'm quite confident that, if things gonna
> > work for IGD passthrough, it gonna
On Sun, 07 Dec 2014, Julia Lawall wrote:
> Replace a misspelled function name by %s and then __func__.
>
> This was done using Coccinelle, including the use of Levenshtein distance,
> as proposed by Rasmus Villemoes.
>
> Signed-off-by: Julia Lawall
>
> ---
> The semantic patch is difficult to sum
On Sun, 07 Dec 2014, Rickard Strandqvist
wrote:
> Remove the function dsi_hs_mode_enable() that is not used anywhere.
Please don't.
BR,
Jani.
>
> This was partially found by using a static code analysis program called
> cppcheck.
>
> Signed-off-by: Rickard Strandqvist
> ---
> drivers/gpu/dr
On Mon, 08 Dec 2014, Rickard Strandqvist
wrote:
> Remove the function dsi_rr_formula() that is not used anywhere.
Please don't.
BR,
Jani.
>
> This was partially found by using a static code analysis program called
> cppcheck.
>
> Signed-off-by: Rickard Strandqvist
> ---
> drivers/gpu/drm/i9
On Sun, Dec 07, 2014 at 10:36:10PM +0100, Rickard Strandqvist wrote:
> Remove the function intel_dp_set_drrs_state() that is not used anywhere.
>
> This was partially found by using a static code analysis program called
> cppcheck.
>
> Signed-off-by: Rickard Strandqvist
Ok I've merged one of t
On Mon, 08 Dec 2014, Aaron Lu wrote:
> We have a new bug report that has the same problem:
> https://bugzilla.kernel.org/show_bug.cgi?id=88941
>
> The posted patch solves the problem. I know it's not perfect, but it
> doesn't seem it would do any harm to existing systems so should be safe.
>
> Bet
On Mon, 08 Dec 2014, Jani Nikula wrote:
> On Mon, 08 Dec 2014, Aaron Lu wrote:
>> We have a new bug report that has the same problem:
>> https://bugzilla.kernel.org/show_bug.cgi?id=88941
>>
>> The posted patch solves the problem. I know it's not perfect, but it
>> doesn't seem it would do any har
On Sun, 07 Dec 2014, Gaurav K Singh wrote:
> DSI Pll1 is used for enabling DSI on Port C.
>
> Signed-off-by: Gaurav K Singh
> ---
> drivers/gpu/drm/i915/intel_dsi_pll.c |7 +--
> 1 file changed, 5 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_dsi_pll.c
> b/dr
On Sun, 07 Dec 2014, Gaurav K Singh wrote:
> Due to some hardware limitations, MIPI Port C DPI Enable bit
> does not get set. To check whether DSI Port C was enabled in BIOS,
> check the Pipe B enable bit for DSI Port C. In hardware, DSI Port C
> is linked with Pipe B.
"due to some hardware limit
2014-12-08 6:42 GMT-02:00 Daniel Vetter :
> On Sun, Dec 07, 2014 at 07:29:17PM +0100, Rickard Strandqvist wrote:
>> Remove the function intel_output_name() that is not used anywhere.
>>
>> This was partially found by using a static code analysis program called
>> cppcheck.
>>
>> Signed-off-by: Ric
On Sat, 06 Dec 2014, Damien Lespiau wrote:
> I was playing with clang and oh surprise! a warning trigerred by
> -Wshift-overflow (gcc doesn't have this one):
>
> WA_SET_BIT_MASKED(GEN7_GT_MODE,
> GEN6_WIZ_HASHING_MASK | GEN6_WIZ_HASHING_16x4);
>
> drivers/gpu/drm/i915
On Mon, 08 Dec 2014, Daniel Vetter wrote:
> On Mon, Dec 08, 2014 at 01:23:37PM +1000, Dave Airlie wrote:
>> From: Dave Airlie
>>
>> Otherwise the MST resume paths can hit DPMS paths
>> which hit state checker paths, which hit WARN_ON,
>> because the state checker is inconsistent with the
>> hw.
On Thu, 04 Dec 2014, Daniel Vetter wrote:
> We've lost the +1 required for correct timeouts in
>
> commit 5ed0bdf21a85d78e04f89f15ccf227562177cbd9
> Author: Thomas Gleixner
> Date: Wed Jul 16 21:05:06 2014 +
>
> drm: i915: Use nsec based interfaces
>
> Use ktime_get_raw_ns() and get
On Fri, 28 Nov 2014, Daniel Vetter wrote:
> So apparently jiffies<->nsec<->ktime isn't accurate or something. At
> elast if we timeout there's occasionally still a few hundred us left
> (in a 2 second timeout).
>
> Stuff I've tried and thrown out again:
> - Sampling the before timestamp before jif
On Fri, 05 Dec 2014, Daniel Vetter wrote:
> On Thu, Dec 04, 2014 at 12:59:07PM -0800, Jesse Barnes wrote:
>> On Mon, 1 Dec 2014 09:54:28 -0800
>> Jesse Barnes wrote:
>>
>> > Partial revert of
>> >
>> > commit 206645910b9796bff13fcdb67bdca166b724ba62
>> > Author: Jesse Barnes
>> > Date: Wed
On Fri, 05 Dec 2014, Daniel Vetter wrote:
> On Fri, Dec 05, 2014 at 10:30:47AM -0800, Jesse Barnes wrote:
>> On Fri, 11 Apr 2014 15:55:17 +0200
>> Daniel Vetter wrote:
>>
>> > Apparently stuff works that way on those machines.
>> >
>> > I agree with Chris' concern that this is a bit risky but i
On 12/8/2014 5:07 PM, Jani Nikula wrote:
On Sun, 07 Dec 2014, Gaurav K Singh wrote:
Due to some hardware limitations, MIPI Port C DPI Enable bit
does not get set. To check whether DSI Port C was enabled in BIOS,
check the Pipe B enable bit for DSI Port C. In hardware, DSI Port C
is linked with
On Mon, 08 Dec 2014, "Singh, Gaurav K" wrote:
> On 12/8/2014 5:07 PM, Jani Nikula wrote:
>> On Sun, 07 Dec 2014, Gaurav K Singh wrote:
>>> Due to some hardware limitations, MIPI Port C DPI Enable bit
>>> does not get set. To check whether DSI Port C was enabled in BIOS,
>>> check the Pipe B enabl
On 02/12/14 15:19, Daniel Vetter wrote:
> Similar to a patch from Thomas Daniel for lrc contexts. This keeps
> both sides somewhat in sync and should make Dave Gordon happy.
>
> Note that both the wa and the golden context init code suffer a bit
> from an inssuficient split into driver load and hw
On Mon, Dec 08, 2014 at 02:33:57PM +0200, Jani Nikula wrote:
> > #define _MASKED_BIT_ENABLE(a) (((a) << 16) | (a))
> > #define _MASKED_BIT_DISABLE(a) ((a) << 16)
> > +#define _MASKED_FIELD(value, mask) (((mask) << 16) | (value))
>
> Obligatory bikeshed, wouldn't you say _MASKED_BIT_{ENABLE,DISAB
On Mon, Dec 08, 2014 at 12:24:27PM +0200, Jani Nikula wrote:
> On Sun, 07 Dec 2014, Julia Lawall wrote:
> > Replace a misspelled function name by %s and then __func__.
> >
> > This was done using Coccinelle, including the use of Levenshtein distance,
> > as proposed by Rasmus Villemoes.
> >
> > Si
On Mon, Dec 08, 2014 at 10:32:49AM -0200, Paulo Zanoni wrote:
> 2014-12-08 6:42 GMT-02:00 Daniel Vetter :
> > On Sun, Dec 07, 2014 at 07:29:17PM +0100, Rickard Strandqvist wrote:
> >> Remove the function intel_output_name() that is not used anywhere.
> >>
> >> This was partially found by using a st
On Mon, Dec 08, 2014 at 01:51:01PM +, Dave Gordon wrote:
> On 02/12/14 15:19, Daniel Vetter wrote:
> > Similar to a patch from Thomas Daniel for lrc contexts. This keeps
> > both sides somewhat in sync and should make Dave Gordon happy.
> >
> > Note that both the wa and the golden context init
On 08/12/14 13:59, Damien Lespiau wrote:
> On Mon, Dec 08, 2014 at 02:33:57PM +0200, Jani Nikula wrote:
>>> #define _MASKED_BIT_ENABLE(a) (((a) << 16) | (a))
>>> #define _MASKED_BIT_DISABLE(a) ((a) << 16)
>>> +#define _MASKED_FIELD(value, mask) (((mask) << 16) | (value))
>>
>> Obligatory bikeshed
On Mon, Dec 08, 2014 at 01:59:50PM +, Damien Lespiau wrote:
> On Mon, Dec 08, 2014 at 02:33:57PM +0200, Jani Nikula wrote:
> > > #define _MASKED_BIT_ENABLE(a) (((a) << 16) | (a))
> > > #define _MASKED_BIT_DISABLE(a) ((a) << 16)
> > > +#define _MASKED_FIELD(value, mask) (((mask) << 16) | (valu
On Mon, Dec 08, 2014 at 03:21:02PM +0100, Daniel Vetter wrote:
> On Mon, Dec 08, 2014 at 01:59:50PM +, Damien Lespiau wrote:
> > On Mon, Dec 08, 2014 at 02:33:57PM +0200, Jani Nikula wrote:
> > > > #define _MASKED_BIT_ENABLE(a) (((a) << 16) | (a))
> > > > #define _MASKED_BIT_DISABLE(a) ((a) <
On Mon, Dec 08, 2014 at 03:23:49PM +0100, Daniel Vetter wrote:
> > #define _MASKED_BIT_ENABLE(a) _MASKED_FIELD(a, a)
> > #define _MASKED_BIT_DISABLE(a) _MASKED_FIELD(a, 0)
>
> Ok and I right away screwed up the argument ordering in the DISABLE one
> because the bits we set are before the mask. All
On Mon, Dec 08, 2014 at 02:17:45PM +, Dave Gordon wrote:
> On 08/12/14 13:59, Damien Lespiau wrote:
> > On Mon, Dec 08, 2014 at 02:33:57PM +0200, Jani Nikula wrote:
> >>> #define _MASKED_BIT_ENABLE(a) (((a) << 16) | (a))
> >>> #define _MASKED_BIT_DISABLE(a) ((a) << 16)
> >>> +#define _MASKED_
On 05/12/14 12:51, Ville Syrjälä wrote:
> On Fri, Nov 14, 2014 at 06:16:56PM +0200, ville.syrj...@linux.intel.com wrote:
>> From: Ville Syrjälä
>>
>> MI_STORE_DWORD_IMM length has been the same ever since gen4. Rename
>> the define to avoid potential confusion if someone tries to use this
>> on pr
After a bit of irc discussion we've concluded that it would be prudent
to check that callers use the mask/enable paramters correctly. So add
a WARN_ON.
Now most callers have static parameters, so even better would be if we
could bug at compile-time. Hence improve the i915 WARN_ON to
BUILD_BUG_ON i
On Mon, Dec 08, 2014 at 04:00:29PM +0100, Daniel Vetter wrote:
> After a bit of irc discussion we've concluded that it would be prudent
> to check that callers use the mask/enable paramters correctly. So add
> a WARN_ON.
>
> Now most callers have static parameters, so even better would be if we
>
On Mon, 08 Dec 2014, Daniel Vetter wrote:
> After a bit of irc discussion we've concluded that it would be prudent
> to check that callers use the mask/enable paramters correctly. So add
> a WARN_ON.
>
> Now most callers have static parameters, so even better would be if we
> could bug at compile-
On Mon, Dec 8, 2014 at 4:14 PM, Damien Lespiau wrote:
> On Mon, Dec 08, 2014 at 04:00:29PM +0100, Daniel Vetter wrote:
>> After a bit of irc discussion we've concluded that it would be prudent
>> to check that callers use the mask/enable paramters correctly. So add
>> a WARN_ON.
>>
>> Now most cal
On Mon, Dec 8, 2014 at 4:18 PM, Jani Nikula wrote:
> On Mon, 08 Dec 2014, Daniel Vetter wrote:
>> After a bit of irc discussion we've concluded that it would be prudent
>> to check that callers use the mask/enable paramters correctly. So add
>> a WARN_ON.
>>
>> Now most callers have static parame
In function that define a local pipe_config variable to point to
crtc->config, replace remaining references to crtc->config with
the local variable. This makes the code more consistent and easier
to change in an automated manner.
---
drivers/gpu/drm/i915/intel_display.c | 6 +++---
1 file changed,
This reduces the number of direct users of crtc->new_config. At some
point we'll be able to get rid of that pointer altogether, in favor
of drm core state structs.
---
drivers/gpu/drm/i915/i915_drv.h | 3 +-
drivers/gpu/drm/i915/intel_ddi.c | 29
drivers/gpu/drm/i915/intel_dis
So that we can get rid of the new_config pointer later.
---
drivers/gpu/drm/i915/intel_display.c | 30 ++
1 file changed, 22 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index da5af23..a9f3034 1
There are no more users of that pointer since the new config is now
passed down the call chain during mode set. Also, when the switch to
atomic happens, the right config (state) should be derived from an
atomic state structure.
---
drivers/gpu/drm/i915/intel_display.c | 46
So that atomic operations will reference the right crtc state.
---
drivers/gpu/drm/i915/intel_display.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 462f22a..20b9e9b 100644
--- a/drivers/gpu/drm/i915/intel_di
To match the semantics of drm_crtc->state, which this will eventually
become. Following coccinelle script did most of the work.
@@ struct intel_crtc *crtc; @@
-&crtc->config
+crtc->config
@@ struct intel_crtc *crtc; identifier member; @@
-crtc->config.member
+crtc->config->member
@@ struct drm_crt
The objective is to make this structure usable with the atomic helpers,
so let's start with the rename. Patch generated with coccinelle:
@@ @@
-struct intel_crtc_config
+struct intel_crtc_state
---
drivers/gpu/drm/i915/i915_drv.h | 4 +-
drivers/gpu/drm/i915/intel_crt.c | 6 +--
driv
> -Original Message-
> From: Nguyen, Michael H
> Sent: Wednesday, November 26, 2014 9:54 PM
> To: intel-gfx@lists.freedesktop.org
> Cc: Bloomfield, Jon; Volkin, Bradley D
> Subject: [PATCH v5 1/7] drm/i915: Implement a framework for batch buffer
> pools
>
> From: Brad Volkin
>
> This add
When we implement atomic support, we'll need to keep a crtc current
state in the drm_crtc->state pointer, and save the new config into
a separate state object passed down the call chain. This series moves
in that direction by making struct intel_crtc_config the state struct
for our driver, and by g
And get rid of the duplicate mode structures. The bulk of the patch
was generated with the following semantic patch.
@@ struct intel_crtc_state *state; @@
-state->adjusted_mode
+state->base.adjusted_mode
@@ struct intel_crtc_state *state; @@
-state->requested_mode
+state->base.mode
@@ struct intel
After a bit of irc discussion we've concluded that it would be prudent
to check that callers use the mask/enable paramters correctly. So add
a WARN_ON.
Spurred by Damien's bugfix which added _MASKED_FIELD.
v2: We use WARN_ON(1) a lot to catch default cases in switch blocks
which should always be
On Mon, 08 Dec 2014, Daniel Vetter wrote:
> After a bit of irc discussion we've concluded that it would be prudent
> to check that callers use the mask/enable paramters correctly. So add
> a WARN_ON.
>
> Spurred by Damien's bugfix which added _MASKED_FIELD.
>
> v2: We use WARN_ON(1) a lot to catch
Faster feedback to errors is always better. This is inspired by the
addition to WARN_ONs to mask/enable helpers for registers to make sure
callers have the arguments ordered correctly: Pretty much always the
arguments are static.
We use WARN_ON(1) a lot in default switch statements though where we
On Mon, Dec 08, 2014 at 02:57:31PM +, Dave Gordon wrote:
> On 05/12/14 12:51, Ville Syrjälä wrote:
> > On Fri, Nov 14, 2014 at 06:16:56PM +0200, ville.syrj...@linux.intel.com
> > wrote:
> >> From: Ville Syrjälä
> >>
> >> MI_STORE_DWORD_IMM length has been the same ever since gen4. Rename
> >>
From: Paulo Zanoni
This may save a few picoseconds on !HAS_FBC platforms. And it also
satisfies my OCD.
Signed-off-by: Paulo Zanoni
---
drivers/gpu/drm/i915/intel_fbc.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_fbc.c b/drivers/gpu/drm/i
From: Paulo Zanoni
Hi
This series does some minor fixes to the FBC code and also ports it to use the
new front buffer tracking infrastructure.
Patches 1-2 are the transition from intel_pm.c to intel_fbc.c. Rodrigo's point
is that it's better to move to intel_fbc.c first because then it's going
From: Paulo Zanoni
.. because it would be a waste of time, so move the place where the
check is done. Also, with this we won't risk printing "more than one
pipe active, disabling compression" or "no output, disabling" when FBC
is actually disabled.
This patch also represents a small behavior dif
From: Rodrigo Vivi
No functional changes.
v2 (Paulo): Rebase.
Signed-off-by: Rodrigo Vivi
Signed-off-by: Paulo Zanoni
---
Documentation/DocBook/drm.tmpl | 5
drivers/gpu/drm/i915/intel_fbc.c | 57 ++--
2 files changed, 54 insertions(+), 8 deletions
From: Rodrigo Vivi
No functional changes. This is just the begin of a FBC rework.
v2 (Paulo):
- Revert intel_fbc_init() changed parameter.
- Revert set_no_fbc_reason() rename.
- Rebase.
Cc: Paulo Zanoni
Signed-off-by: Rodrigo Vivi
Signed-off-by: Paulo Zanoni
---
drivers/gpu/drm/i915/M
From: Paulo Zanoni
We want to port FBC to the frontbuffer tracking infrastructure, but
for that we need to know what caused the object invalidation/flush so
we can react accordingly: CPU mmaps need manual, GTT mmaps and
flips don't need handling and ring rendering needs nukes.
Signed-off-by: Pau
From: Paulo Zanoni
I want to make this code a little more complicated, so let's extract
the function first.
Signed-off-by: Paulo Zanoni
---
drivers/gpu/drm/i915/intel_fbc.c | 46 +---
1 file changed, 29 insertions(+), 17 deletions(-)
diff --git a/drivers/gp
From: Paulo Zanoni
So add code to consider this case.
Signed-off-by: Paulo Zanoni
---
drivers/gpu/drm/i915/intel_fbc.c | 20
1 file changed, 16 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_fbc.c b/drivers/gpu/drm/i915/intel_fbc.c
index 450d0be..e8
From: Paulo Zanoni
Since the mapping from CRTCs to planes is fixed, looking at the CRTC
is essentially the same as looking at the plane. Also, the next
patches wil start using the frontbuffer_bits macros, and they take the
pipe as the parameter instead of the plane, and this could differ on
gens
From: Paulo Zanoni
Kill the blt/render tracking we currently have and use the frontbuffer
tracking infrastructure.
Don't enable things by default yet.
Signed-off-by: Paulo Zanoni
---
drivers/gpu/drm/i915/i915_drv.h | 9 +--
drivers/gpu/drm/i915/intel_drv.h | 6 +-
drivers
From: Paulo Zanoni
We need this for FBC, and possibly for PSR too.
Signed-off-by: Paulo Zanoni
---
drivers/gpu/drm/i915/i915_gem.c | 4
1 file changed, 4 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 7ef12e8..b8c906e 100644
--- a/drive
From: Paulo Zanoni
So allow it.
Signed-off-by: Paulo Zanoni
---
drivers/gpu/drm/i915/intel_fbc.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_fbc.c b/drivers/gpu/drm/i915/intel_fbc.c
index e8dc1d5..1c22922 100644
--- a/drivers/gpu/drm/i91
From: Paulo Zanoni
Just a little helper for code that needs to wait for a certain
condition to happen. It has the nice advantage that it can survive the
signal helper.
Despite the callers added in this patch, there is another that will go
in a separate patch, and another in a new IGT test file t
From: Paulo Zanoni
The code has a common pattern of "wait 300ms, then check if FBC is
enabled". Most of the time FBC is enabled in either 50ms or 0ms, so
introduce wait_for_fbc_enabled(), which can return much earlier if FBC
is actually enabled before the 300ms timeout.
Signed-off-by: Paulo Zano
From: Paulo Zanoni
When we're doing the context subtest, at the end of prepare_test() we
exec a single nop batch on the front buffer, which invalidates FBC.
With the new frontbuffer tracking scheme it may take a while for FBC
to be reenabled, so we end up failing the first fbc_enabled()
assertion
From: Paulo Zanoni
The way kms_fbc_crc works is that it does an operation that may
trigger/invalidate/update FBC, then it sleeps for 300ms to wait for
FBC to kick in again, then it calls "igt_assert(fbc_enabled())".
This was causing problems where the BLT test would eventually fail in
the fbc_ea
On Mon, Dec 08, 2014 at 05:06:34PM +0100, Daniel Vetter wrote:
> Faster feedback to errors is always better. This is inspired by the
> addition to WARN_ONs to mask/enable helpers for registers to make sure
> callers have the arguments ordered correctly: Pretty much always the
> arguments are static
2014-12-08 12:17 GMT-02:00 Daniel Vetter :
> On Mon, Dec 08, 2014 at 10:32:49AM -0200, Paulo Zanoni wrote:
>> 2014-12-08 6:42 GMT-02:00 Daniel Vetter :
>> > On Sun, Dec 07, 2014 at 07:29:17PM +0100, Rickard Strandqvist wrote:
>> >> Remove the function intel_output_name() that is not used anywhere.
Faster feedback to errors is always better. This is inspired by the
addition to WARN_ONs to mask/enable helpers for registers to make sure
callers have the arguments ordered correctly: Pretty much always the
arguments are static.
We use WARN_ON(1) a lot in default switch statements though where we
I was playing with clang and oh surprise! a warning trigerred by
-Wshift-overflow (gcc doesn't have this one):
WA_SET_BIT_MASKED(GEN7_GT_MODE,
GEN6_WIZ_HASHING_MASK | GEN6_WIZ_HASHING_16x4);
drivers/gpu/drm/i915/intel_ringbuffer.c:786:2: warning: signed shift result
On Mon, 08 Dec 2014, Jani Nikula wrote:
> On Mon, 08 Dec 2014, Daniel Vetter wrote:
>> After a bit of irc discussion we've concluded that it would be prudent
>> to check that callers use the mask/enable paramters correctly. So add
>> a WARN_ON.
>>
>> Spurred by Damien's bugfix which added _MASKED
On Mon, Dec 08, 2014 at 04:22:27PM +, Damien Lespiau wrote:
> I was playing with clang and oh surprise! a warning trigerred by
> -Wshift-overflow (gcc doesn't have this one):
>
> WA_SET_BIT_MASKED(GEN7_GT_MODE,
> GEN6_WIZ_HASHING_MASK | GEN6_WIZ_HASHING_16x4);
>
>
On Mon, Dec 08, 2014 at 05:21:04PM +0200, Ander Conselvan de Oliveira wrote:
> This reduces the number of direct users of crtc->new_config. At some
> point we'll be able to get rid of that pointer altogether, in favor
> of drm core state structs.
Just an aside: If we want to use drm_obj->state ins
On Mon, Dec 08, 2014 at 05:21:07PM +0200, Ander Conselvan de Oliveira wrote:
> There are no more users of that pointer since the new config is now
> passed down the call chain during mode set. Also, when the switch to
> atomic happens, the right config (state) should be derived from an
> atomic sta
On Mon, Dec 08, 2014 at 02:12:41PM -0200, Paulo Zanoni wrote:
> From: Paulo Zanoni
>
> Just a little helper for code that needs to wait for a certain
> condition to happen. It has the nice advantage that it can survive the
> signal helper.
>
> Despite the callers added in this patch, there is an
The current hda/i915 interface to enable/disable power wells and query
the CD clock rate is based on looking up the relevant i915 module
symbols from the hda driver. By using the component framework we can get
rid of some global state tracking in the i915 driver and pave the way to
fully decouple t
After switching to using the component interface this API isn't needed
any more.
Signed-off-by: Imre Deak
---
drivers/gpu/drm/i915/intel_runtime_pm.c | 56 -
include/drm/i915_powerwell.h| 37 --
2 files changed, 93 deletions(-)
del
chip is already passed to most of the i915 interface functions, unify
things by passing it also to the rest. This will be needed by an
upcoming patch adding component support.
No functional change.
Signed-off-by: Imre Deak
---
sound/pci/hda/hda_i915.c | 6 +++---
sound/pci/hda/hda_i915.h | 1
This will be needed by later patches, so factor it out.
No functional change.
Signed-off-by: Imre Deak
---
drivers/gpu/drm/i915/i915_drv.c | 15 ++-
drivers/gpu/drm/i915/intel_drv.h | 8
2 files changed, 14 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/i915/
On Mon, Dec 08, 2014 at 02:09:15PM -0200, Paulo Zanoni wrote:
> From: Paulo Zanoni
>
> We want to port FBC to the frontbuffer tracking infrastructure, but
> for that we need to know what caused the object invalidation/flush so
> we can react accordingly: CPU mmaps need manual, GTT mmaps and
> fli
On 08/12/14 16:27, Daniel Vetter wrote:
> On Mon, Dec 08, 2014 at 04:22:27PM +, Damien Lespiau wrote:
>> I was playing with clang and oh surprise! a warning trigerred by
>> -Wshift-overflow (gcc doesn't have this one):
[snip]
>> diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.c
>> b/drive
On Mon, Dec 08, 2014 at 02:09:16PM -0200, Paulo Zanoni wrote:
> From: Paulo Zanoni
>
> We need this for FBC, and possibly for PSR too.
>
> Signed-off-by: Paulo Zanoni
Hm, this might fix some cursor update failures if userspace only pwrites
and doesn't follow suite with a cursor ioctl update ca
Register a component master to be used to interface with the
snd_hda_intel driver. This is meant to replace the same interface that
is currently based on module symbol lookup.
Signed-off-by: Imre Deak
---
drivers/gpu/drm/i915/i915_dma.c | 80 +
include/drm
Register a component to be used to interface with the i915 driver. This
is meant to replace the current interface which is based on module
symbol lookups.
Note that currently we keep the existing behavior and pin the i915
module while the hda driver is loaded. Using the component interface
allows
On Mon, Dec 08, 2014 at 04:50:13PM +, Dave Gordon wrote:
> On 08/12/14 16:27, Daniel Vetter wrote:
> > On Mon, Dec 08, 2014 at 04:22:27PM +, Damien Lespiau wrote:
> >> I was playing with clang and oh surprise! a warning trigerred by
> >> -Wshift-overflow (gcc doesn't have this one):
>
> [s
On 08/12/14 16:22, Damien Lespiau wrote:
> I was playing with clang and oh surprise! a warning trigerred by
> -Wshift-overflow (gcc doesn't have this one):
>
> WA_SET_BIT_MASKED(GEN7_GT_MODE,
> GEN6_WIZ_HASHING_MASK | GEN6_WIZ_HASHING_16x4);
>
> drivers/gpu/drm/i915/
On Mon, Dec 08, 2014 at 02:09:11PM -0200, Paulo Zanoni wrote:
> From: Rodrigo Vivi
>
> No functional changes.
>
> v2 (Paulo): Rebase.
>
> Signed-off-by: Rodrigo Vivi
> Signed-off-by: Paulo Zanoni
Some suggestions to polish the documentation a bit below. I've merged
patch 1 right away to avoi
1 - 100 of 149 matches
Mail list logo
