Hi all,
Today's linux-next merge of the drm-intel tree got a conflict in
drivers/gpu/drm/i915/intel_display.c between commit cc173961a680
("drm/i915: do not update cursor in crtc mode set") from the
drm-intel-fixes tree and commit e9fd1c02aca7 ("drm/i915: don't enable
DPLL for DSI") from the drm-i
2013/9/16 :
> From: Ville Syrjälä
>
> VGA registers live inside the power well on HSW, so in order to write
> the VGA MSR register we need the power well to be on.
>
> We really must write to the register to properly clear the
> VGA_MSR_MEM_EN enable bit, even if all VGA registers get zeroed when
Calculation is a little different than other platforms.
References: https://bugs.freedesktop.org/show_bug.cgi?id=67345
Signed-off-by: Jesse Barnes
---
drivers/gpu/drm/i915/intel_display.c | 30 +-
1 file changed, 29 insertions(+), 1 deletion(-)
diff --git a/drivers
2013/9/16 :
> From: Ville Syrjälä
>
> The init and resume codepaths want to handel the power well in slightly
s/handel/handle/
Patches 1-5: Reviewed-by: Paulo Zanoni
> different ways, so pull the power well init out from
> intel_modeset_init_hw() which gets called in both cases.
>
> Signed-o
2013/9/16 :
> From: Ville Syrjälä
>
> i915_restore_state() -> i915_restore_display() will attempt to
> re-disable VGA during resume. So the power well needs to be powered on
> before that.
>
> Signed-off-by: Ville Syrjälä
Needs a rebase, but looks correct.
> ---
> drivers/gpu/drm/i915/i915_dr
2013/9/16 :
> From: Ville Syrjälä
>
> We already restore planes during the modeset operation, so no need to do
> another loop over the planes and try to restore them again.
What about the call from intel_lid_notify()? It helps if you explain
on the commit message why/how we already restore thing
2013/9/16 :
> From: Ville Syrjälä
>
> The VGA plane needs to be disabled before we start doing any
> modeset operations on resume.
>
> This should also guarantee that the power well will be enabled
> when we call i915_redisable_vga() since it gets explicitly powered on
> during resume, and will g
2013/9/16 :
> From: Ville Syrjälä
>
> Call intel_uncore_early_sanitize() first thing during resume to prevent
> stale BIOS leftovers from being reported as unclaimed register access.
Just out of curiosity: do you actually need this patch to avoid error
messages? The change makes sense, but since
On Fri, Sep 20, 2013 at 7:13 AM, Paul Zimmerman
wrote:
>> From: Dave Airlie [mailto:airl...@gmail.com]
>> Sent: Thursday, September 19, 2013 1:15 PM
>>
>> On Fri, Sep 20, 2013 at 6:10 AM, Daniel Vetter wrote:
>> > On Thu, Sep 19, 2013 at 06:32:47PM +, Paul Zimmerman wrote:
>> >> > From: Paul
From: Paulo Zanoni
Linus recently complained about screen corruption when coming out of
DPMS on his Haswell machine, and he also mentioned there were no error
messages on the log. I think I can reproduce this problem, and when it
happens I get a "FIFO underrun" message, but since it's just
DRM_DE
From: Paulo Zanoni
This workaround is described in the mode set sequence documentation.
When enabling planes for the second pipe, we need to wait for 2
vblanks on the first pipe. This should solve "a flash of screen
corruption if planes are enabled on second/third pipe during the time
that big FI
From: Paulo Zanoni
At the end of haswell_crtc_enable we have an intel_wait_for_vblank
with a big comment, and the message suggests it's a workaround for
something we don't really understand. So I removed that wait and
started getting HW state readout error messages saying that the IPS
state is no
From: Paulo Zanoni
Make sure we write to IPS before we actually wait.
Signed-off-by: Paulo Zanoni
---
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 fc55570..78ff5ed 100
From: Paulo Zanoni
Hi
This series gets rid of those messages saying that the vblank wait timed out on
my Haswell machine. It saves 2 timeouts per pipe (one at mode_set, one at
crtc_enable), so it's 100ms we save per modeset.
The big idea exercised by this patch is that the pipe doesn't really s
From: Paulo Zanoni
Just simple things I spotted. I tested these patches on top of the 4 patches
that fix the Haswell underruns.
Paulo Zanoni (2):
drm/i915: POSTING_READ IPS_CTL before waiting for the vblank
drm/i915: wait for IPS_ENABLE when enabling IPS
drivers/gpu/drm/i915/intel_display.
On Thu, Sep 19, 2013 at 05:03:06PM -0300, Paulo Zanoni wrote:
> From: Paulo Zanoni
>
> At the end of haswell_crtc_enable we have an intel_wait_for_vblank
> with a big comment, and the message suggests it's a workaround for
> something we don't really understand. So I removed that wait and
> start
On Fri, Sep 20, 2013 at 6:10 AM, Daniel Vetter wrote:
> On Thu, Sep 19, 2013 at 06:32:47PM +, Paul Zimmerman wrote:
>> > From: Paul Zimmerman
>> > Sent: Thursday, September 19, 2013 11:21 AM
>> >
>> > > From: Dave Airlie [mailto:airl...@gmail.com]
>> > > Sent: Wednesday, September 18, 2013 7:4
On Thu, Sep 19, 2013 at 08:41:55PM +0200, Daniel Vetter wrote:
> On Thu, Sep 19, 2013 at 11:01:40AM -0700, Ben Widawsky wrote:
> > We'd only ever used this define to denote whether or not we have the
> > dynamic parity feature (DPF) and never to determine whether or not L3
> > exists. Baytrail is a
From: Paulo Zanoni
We currently disable the ERR_INT interrupts while running the IRQ
handler because we fear that if we do an unclaimed register access
from inside the IRQ handler we'll keep triggering the IRQ handler
forever.
The problem is that since we always disable the ERR_INT interrupts at
From: Ville Syrjälä
Refactor the plane enabling/disabling into helper functions and move
the calls to happen as the first thing during .crtc_disable, and the
last thing during .crtc_enable.
Those are the two clear points where we are sure that the pipe is
actually running regardless of the encod
From: Paulo Zanoni
Hi
After we solved the Haswell modeset hang, I started to see FIFO underruns. This
series addresses the problems I was able to spot and fix. I think these patches
may help solving the corruptions Linus reported.
Thanks,
Paulo
Paulo Zanoni (3):
drm/i915: promote FIFO underr
2013/9/19 Chris Wilson :
> On Thu, Sep 19, 2013 at 05:00:35PM -0300, Paulo Zanoni wrote:
>> From: Paulo Zanoni
>>
>> Linus recently complained about screen corruption when coming out of
>> DPMS on his Haswell machine, and he also mentioned there were no error
>> messages on the log. I think I can
Otherwise the pixel_multiplier may not be set, and who knows what else
in the future.
Signed-off-by: Jesse Barnes
---
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_dis
On Thu, Sep 19, 2013 at 05:00:35PM -0300, Paulo Zanoni wrote:
> From: Paulo Zanoni
>
> Linus recently complained about screen corruption when coming out of
> DPMS on his Haswell machine, and he also mentioned there were no error
> messages on the log. I think I can reproduce this problem, and whe
On Thu, Sep 19, 2013 at 05:07:29PM -0300, Paulo Zanoni wrote:
> From: Paulo Zanoni
>
> We call haswell_write_eld at mode_set time, not at crtc_enable time,
> so the pipes are stopped, and it doesn't really make sense to wait for
> a vblank: it just delays the modeset in 50ms.
>
> Leave the code
On Thu, Sep 19, 2013 at 06:32:47PM +, Paul Zimmerman wrote:
> > From: Paul Zimmerman
> > Sent: Thursday, September 19, 2013 11:21 AM
> >
> > > From: Dave Airlie [mailto:airl...@gmail.com]
> > > Sent: Wednesday, September 18, 2013 7:40 PM
> > >
> > > On Thu, Sep 19, 2013 at 12:02 PM, Paul Zimme
From: Paulo Zanoni
We call haswell_write_eld at mode_set time, not at crtc_enable time,
so the pipes are stopped, and it doesn't really make sense to wait for
a vblank: it just delays the modeset in 50ms.
Leave the code there (commented with FIXME) for now since maybe we
need a bigger rework.
S
From: Paulo Zanoni
Depending on the Gen and encoder, the pipe won't really start after we
enable PIPECONF, so waiting for the vblank inside intel_enable_pipe
doesn't really make sense for these cases. This patch removes the
vblank wait from intel_enable_pipe, but adds vblank waiting code after
ea
From: Paulo Zanoni
After the modeset rework this really shouldn't be happening, so
transform it into a WARN. A stuck pipe is a bad signal and is one of
the things that can lead to full machine hangs.
Signed-off-by: Paulo Zanoni
---
drivers/gpu/drm/i915/intel_display.c | 2 +-
1 file changed, 1
From: Paulo Zanoni
This function is called in a point where the pipe is not really
running (the fact that PIPECONF is enabled doesn't mean that the pipe
is actually running), so we pay the full 50ms timeout. Also, I
couldn't find a reason why this is needed, so just skip it.
I do have to notice
On Thu, Sep 19, 2013 at 05:00:36PM -0300, Paulo Zanoni wrote:
> From: Paulo Zanoni
>
> We currently disable the ERR_INT interrupts while running the IRQ
> handler because we fear that if we do an unclaimed register access
> from inside the IRQ handler we'll keep triggering the IRQ handler
> forev
On Thu, Sep 19, 2013 at 05:20:49PM -0300, Paulo Zanoni wrote:
> 2013/9/19 Chris Wilson :
> > On Thu, Sep 19, 2013 at 05:00:35PM -0300, Paulo Zanoni wrote:
> >> From: Paulo Zanoni
> >>
> >> Linus recently complained about screen corruption when coming out of
> >> DPMS on his Haswell machine, and he
On Thu, Sep 19, 2013 at 05:40:34PM +0100, Damien Lespiau wrote:
> Now that we ask to adjust the crtc timings for stereo modes, the correct
> pipe_src_w and pipe_src_h can be found in crtc_vdisplay and crtc_hdisplay.
>
> Signed-off-by: Damien Lespiau
> ---
> drivers/gpu/drm/i915/intel_display.c |
On Thu, Sep 19, 2013 at 11:01:40AM -0700, Ben Widawsky wrote:
> We'd only ever used this define to denote whether or not we have the
> dynamic parity feature (DPF) and never to determine whether or not L3
> exists. Baytrail is a good example of where L3 exists, and not DPF.
>
> This patch provides
We'd only ever used this define to denote whether or not we have the
dynamic parity feature (DPF) and never to determine whether or not L3
exists. Baytrail is a good example of where L3 exists, and not DPF.
This patch provides clarify in the code for future use cases which might
want to actually q
Certain HSW SKUs have a second bank of L3. This L3 remapping has a
separate register set, and interrupt from the first "slice". A slice is
simply a term to define some subset of the GPU's l3 cache. This patch
implements both the interrupt handler, and ability to communicate with
userspace about thi
On Tue, Sep 17, 2013 at 09:12:44PM -0700, Ben Widawsky wrote:
> Using LRI for setting the remapping registers allows us to stream l3
> remapping information. This is necessary to handle per context remaps as
> we'll see implemented in an upcoming patch.
>
> Using the ring also means we don't need
We'd only ever used this define to denote whether or not we have the
dynamic parity feature (DPF) and never to determine whether or not L3
exists. Baytrail is a good example of where L3 exists, and not DPF.
This patch provides clarify in the code for future use cases which might
want to actually q
On Thu, Sep 19, 2013 at 10:41:19AM -0700, Ben Widawsky wrote:
> On Thu, Sep 19, 2013 at 03:47:50PM +0100, Chris Wilson wrote:
> > On Thu, Sep 19, 2013 at 07:41:23AM -0700, Ben Widawsky wrote:
> > > diff --git a/drivers/gpu/drm/i915/i915_gem_execbuffer.c
> > > b/drivers/gpu/drm/i915/i915_gem_execbu
We want to dump the parameters given to the hardware, so let's use
crtc_clock here.
Signed-off-by: Damien Lespiau
---
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_displa
This field is unused. Garbage collect it.
Signed-off-by: Damien Lespiau
---
include/drm/drm_crtc.h | 1 -
1 file changed, 1 deletion(-)
diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
index 011baaa..8e9716e 100644
--- a/include/drm/drm_crtc.h
+++ b/include/drm/drm_crtc.h
@@ -156,7
Just like the various timings, make it possible to have a clock field
what we can tweak before giving it to hardware.
Signed-off-by: Damien Lespiau
---
drivers/gpu/drm/drm_modes.c | 1 +
include/drm/drm_crtc.h | 1 +
2 files changed, 2 insertions(+)
diff --git a/drivers/gpu/drm/drm_modes.c
When using the frame packing and a single big framebuffer, some hardware
requires that we do everything like if we were scanning out the big
buffer itself. Let's instrument drm_mode_set_crtcinfo() to be able to do
this adjustement if the driver is asking for it.
Suggested-by: Daniel Vetter
Signed
On Thu, Sep 19, 2013 at 03:47:50PM +0100, Chris Wilson wrote:
> On Thu, Sep 19, 2013 at 07:41:23AM -0700, Ben Widawsky wrote:
> > diff --git a/drivers/gpu/drm/i915/i915_gem_execbuffer.c
> > b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
> > index b26d979..e57837c 100644
> > --- a/drivers/gpu/drm/i91
This field was only accessed by the nouveau driver, but never set. So
concluded we can rid of this one.
Cc: Ben Skeggs
Signed-off-by: Damien Lespiau
---
drivers/gpu/drm/nouveau/dispnv04/crtc.c | 2 --
include/drm/drm_crtc.h | 1 -
2 files changed, 3 deletions(-)
diff --git a/d
Just like with interlaced or double scan modes, make stereo modes a
per-connector opt-in to give a chance to driver authors to make it work
before enabling it.
Suggested-by: Daniel Vetter
Signed-off-by: Damien Lespiau
---
drivers/gpu/drm/drm_crtc_helper.c | 8 +++-
include/drm/drm_crtc.h
Now that we ask to adjust the crtc timings for stereo modes, the correct
pipe_src_w and pipe_src_h can be found in crtc_vdisplay and crtc_hdisplay.
Signed-off-by: Damien Lespiau
---
drivers/gpu/drm/i915/intel_display.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/dri
When setting a stereo 3D mode, there can be only one bit set describing
the layout of the frambuffer(s). So reject invalid modes early.
Signed-off-by: Damien Lespiau
---
drivers/gpu/drm/drm_crtc.c | 4
1 file changed, 4 insertions(+)
diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/dr
When scanning out a 3D mode on HDMI, we need to send an HDMI infoframe
with the corresponding layout to the sink.
v2: Make s3d_structure_from_display_mode() less subtle (Ville Syrjälä)
Reviewed-by: Ville Syrjälä
Signed-off-by: Damien Lespiau
---
drivers/gpu/drm/drm_edid.c | 40
This allows to expose the alternate clock versions of the stereo modes.
Signed-off-by: Damien Lespiau
---
drivers/gpu/drm/drm_edid.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index 48f1746..c24af1d 100644
--- a/drivers/gpu/drm/
Signed-off-by: Damien Lespiau
---
drivers/gpu/drm/i915/intel_hdmi.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/i915/intel_hdmi.c
b/drivers/gpu/drm/i915/intel_hdmi.c
index f21a57f..0d4403e 100644
--- a/drivers/gpu/drm/i915/intel_hdmi.c
+++ b/drivers/gpu/drm/i915/intel_hdm
When scanning out a stereo mode, the AVI infoframe vic field has to be
the underlyng 2D VIC. Before that commit, we weren't matching the CEA
mode because of the extra stereo flag and then were setting the VIC
field in the AVI infoframe to 0.
Signed-off-by: Damien Lespiau
---
drivers/gpu/drm/drm_
This capability allows user space to control the delivery of modes with
the 3D flags set. This is to not play games with current user space
users not knowing anything about stereo 3D flags and that could try
to set a mode with one or several of those bits set.
So, the plan is to remove the stereo
When booting with i915.fastboot=1, we always take tha code path and end
up undoing what we're trying to do with adjusted_mode.
Hopefully, as the fastboot hardware readout code is using adjusted_mode
as well, it should be equivalent.
Signed-off-by: Damien Lespiau
---
drivers/gpu/drm/i915/intel_d
When scanning out big stereo buffers that are actually bigger that their
natural 2D counterpart, we need to blow up the crtc timings as well.
Not that this is only done for frame packing as this is the only stereo
mode currently exposed needing this kind of ajdustements.
Signed-off-by: Damien Les
struct drm_mode_display now has a separate crtc_ version of the clock to
be used when we're talking about the timings given to the harwadre (was
far as the mode is concerned).
This commit is really the result of a git grep adjusted_mode.*clock and
replacing those by adjusted_mode.crtc_clock. No fu
So we respect a nice design of having similar functions at the same
level, in this case:
do_hdmi_vsdb_modes()
- add_hdmi_mandatory_stereo_modes()
- add_hdmi_mode()
Signed-off-by: Damien Lespiau
---
drivers/gpu/drm/drm_edid.c | 36 +---
1 file changed, 21 inse
For now, let's just look at the 3D_present flag of the CEA HDMI vendor
block to detect if the sink supports a small list of then mandatory 3D
formats.
See the HDMI 1.4a 3D extraction for detail:
http://www.hdmi.org/manufacturer/specification.aspx
v2: Rename freq to vrefresh, make the mandatory
HDMI 1.4a defines a few layouts that we'd like to expose. This commits
add new modeinfo flags that can be used to list the supported stereo
layouts (when querying the list of modes) and to set a given stereo 3D
mode (when setting a mode).
v2: Add a drm_mode_is_stereo() helper
Signed-off-by: Damie
v4 was:
http://lists.freedesktop.org/archives/dri-devel/2013-September/045340.html
Changes from v4:
- The kernel is now in charge of adjusting the stereo mode timings.
- There is a per-connector opt-in boolean to expose stereo modes, letting
people enable stereo for each driver/connector.
This ioctl can be used to turn some knobs in a DRM driver. The client
can ask the DRM core for an alternate view of the reality: it can be
useful to be able to instruct the core that the DRM client can handle
new functionnality that would otherwise break current ABI.
v2: Rename to ioctl from SET_C
Disabling it isn't really an option on these platforms, but having it
available for power comparisons is useful.
Signed-off-by: Jesse Barnes
---
drivers/gpu/drm/i915/intel_pm.c |7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers
On Thu, Sep 19, 2013 at 07:41:23AM -0700, Ben Widawsky wrote:
> diff --git a/drivers/gpu/drm/i915/i915_gem_execbuffer.c
> b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
> index b26d979..e57837c 100644
> --- a/drivers/gpu/drm/i915/i915_gem_execbuffer.c
> +++ b/drivers/gpu/drm/i915/i915_gem_execbuffer
From: Ben Widawsky
Building on the last patch which created the new function pointers in
the VM for bind/unbind, here we actually put those new function pointers
to use.
Split out as a separate patch to aid in review. I'm fine with squashing
into the previous patch if people request it.
v2: Upd
From: Ben Widawsky
Building on the last patch which created the new function pointers in
the VM for bind/unbind, here we actually put those new function pointers
to use.
Split out as a separate patch to aid in review. I'm fine with squashing
into the previous patch if people request it.
v2: Upd
On Thu, Sep 19, 2013 at 07:15:47AM -0700, Ben Widawsky wrote:
> @@ -1117,8 +1109,24 @@ i915_gem_do_execbuffer(struct drm_device *dev, void
> *data,
>* batch" bit. Hence we need to pin secure batches into the global gtt.
>* hsw should have this fixed, but let's be paranoid and do it
From: Ben Widawsky
Building on the last patch which created the new function pointers in
the VM for bind/unbind, here we actually put those new function pointers
to use.
Split out as a separate patch to aid in review. I'm fine with squashing
into the previous patch if people request it.
v2: Upd
On Thu, Sep 19, 2013 at 03:35:02PM +0200, Daniel Vetter wrote:
> On Thu, Sep 19, 2013 at 02:13:38PM +0100, Damien Lespiau wrote:
> > On Thu, Sep 19, 2013 at 02:53:58PM +0200, Daniel Vetter wrote:
> > > I always get royally confused how a modeline with all zeros could
> > > possible pass the paranoi
On Thu, 19 Sep 2013, Daniel Vetter wrote:
> No buffer overflows here, but better safe than sorry.
>
> v2:
> - Fixup the sizeof conversion, I've missed the pointer deref (Jani).
> - Drop the redundant GFP_ZERO, kcalloc alreads memsets (Jani).
> - Use kmalloc_array for the execbuf fastpath to avoid
On Thu, Sep 19, 2013 at 02:13:38PM +0100, Damien Lespiau wrote:
> On Thu, Sep 19, 2013 at 02:53:58PM +0200, Daniel Vetter wrote:
> > I always get royally confused how a modeline with all zeros could
> > possible pass the paranoid pipe config checker. Until I realize again
> > that we only check the
On Thu, 19 Sep 2013, Daniel Vetter wrote:
> And the gratious overallocation of crtcs. Seems to go back to the ums
> days of yonder ...
>
> We also still need it to make the fbdev emulation happy, but I don't
> think there's really a need. Especially since the current fbdev
> emulation doesn't actu
On Thu, Sep 19, 2013 at 02:53:58PM +0200, Daniel Vetter wrote:
> I always get royally confused how a modeline with all zeros could
> possible pass the paranoid pipe config checker. Until I realize again
> that we only check the crtc timings. So dump the crtc timings for the
> adjusted mode.
>
> Th
On Thu, Sep 19, 2013 at 02:53:36PM +0200, Daniel Vetter wrote:
> There's actually no real risk since we already check for stricter
> constraints earlier (using UINT_MAX / sizeof (struct
> drm_i915_gem_exec_object2) as the limit). But in eb_create we use
> signed integers, which steals a factor of 2
On Thu, Sep 19, 2013 at 02:51:10PM +0200, Daniel Vetter wrote:
> On Thu, Sep 19, 2013 at 01:41:53PM +0100, Chris Wilson wrote:
> > On Thu, Sep 19, 2013 at 02:35:42PM +0200, Daniel Vetter wrote:
> > > On Thu, Sep 19, 2013 at 2:30 PM, Chris Wilson
> > > wrote:
> > > > On Thu, Sep 19, 2013 at 02:06:
I always get royally confused how a modeline with all zeros could
possible pass the paranoid pipe config checker. Until I realize again
that we only check the crtc timings. So dump the crtc timings for the
adjusted mode.
This will be even more important for 3D support where the crtc timings
are ma
There's actually no real risk since we already check for stricter
constraints earlier (using UINT_MAX / sizeof (struct
drm_i915_gem_exec_object2) as the limit). But in eb_create we use
signed integers, which steals a factor of 2. Luckily struct
drm_i915_gem_exec_object2 for this to not matter.
Sti
On Thu, Sep 19, 2013 at 01:41:53PM +0100, Chris Wilson wrote:
> On Thu, Sep 19, 2013 at 02:35:42PM +0200, Daniel Vetter wrote:
> > On Thu, Sep 19, 2013 at 2:30 PM, Chris Wilson
> > wrote:
> > > On Thu, Sep 19, 2013 at 02:06:39PM +0200, Daniel Vetter wrote:
> > >> No buffer overflows here, but bet
On Thu, Sep 19, 2013 at 02:35:42PM +0200, Daniel Vetter wrote:
> On Thu, Sep 19, 2013 at 2:30 PM, Chris Wilson
> wrote:
> > On Thu, Sep 19, 2013 at 02:06:39PM +0200, Daniel Vetter wrote:
> >> No buffer overflows here, but better safe than sorry.
> >>
> >> v2:
> >> - Fixup the sizeof conversion, I
On Thu, Sep 19, 2013 at 01:38:11PM +0100, Damien Lespiau wrote:
> On Wed, Sep 18, 2013 at 05:19:45PM +0300, Jani Nikula wrote:
> > Ville and I were wondering why his laptop was missing the
> > intel_backlight sysfs interface. Turns out we never register it when
> > CONFIG_BACKLIGHT_CLASS_DEVICE=m.
On Wed, Sep 18, 2013 at 05:19:45PM +0300, Jani Nikula wrote:
> Ville and I were wondering why his laptop was missing the
> intel_backlight sysfs interface. Turns out we never register it when
> CONFIG_BACKLIGHT_CLASS_DEVICE=m. This has been broken ever since the
> i915 native backlight interface wa
On Thu, Sep 19, 2013 at 2:30 PM, Chris Wilson wrote:
> On Thu, Sep 19, 2013 at 02:06:39PM +0200, Daniel Vetter wrote:
>> No buffer overflows here, but better safe than sorry.
>>
>> v2:
>> - Fixup the sizeof conversion, I've missed the pointer deref (Jani).
>> - Drop the redundant GFP_ZERO, kcalloc
On Thu, Sep 19, 2013 at 02:06:39PM +0200, Daniel Vetter wrote:
> No buffer overflows here, but better safe than sorry.
>
> v2:
> - Fixup the sizeof conversion, I've missed the pointer deref (Jani).
> - Drop the redundant GFP_ZERO, kcalloc alreads memsets (Jani).
> - Use kmalloc_array for the execb
On Thu, Sep 19, 2013 at 10:58:36AM +0100, Damien Lespiau wrote:
> On Tue, Sep 10, 2013 at 07:36:37PM -0300, Rodrigo Vivi wrote:
> > From: Paulo Zanoni
> >
> > You can't write it using the MCHBAR mirror, the write will just get
> > dropped.
> >
> > This should make us BSpec-compliant, but there's
On Tue, 17 Sep 2013, Kamal Mostafa wrote:
> On Wed, 2013-09-11 at 11:21 +0300, Jani Nikula wrote:
>> On Wed, 11 Sep 2013, Rodrigo Vivi wrote:
>> > From: Kamal Mostafa
>> >
>> > Boot params quirks_set and quirks_mask allow the user to enable or
>> > inhibit any dmi-matched quirks, overriding the
No buffer overflows here, but better safe than sorry.
v2:
- Fixup the sizeof conversion, I've missed the pointer deref (Jani).
- Drop the redundant GFP_ZERO, kcalloc alreads memsets (Jani).
- Use kmalloc_array for the execbuf fastpath to avoid the memset
(Chris). I've opted to leave all other co
And the gratious overallocation of crtcs. Seems to go back to the ums
days of yonder ...
We also still need it to make the fbdev emulation happy, but I don't
think there's really a need. Especially since the current fbdev
emulation doesn't actually support cloning.
v2: Use sizeof(*pointer) patter
There's actually no real risk since we already check for stricter
constraints earlier (using UINT_MAX / sizeof (struct
drm_i915_gem_exec_object2) as the limit). But in eb_create we use
signed integers, which steals a factor of 2. Luckily struct
drm_i915_gem_exec_object2 for this to not matter.
Sti
On Thu, Sep 19, 2013 at 11:46:55AM +0100, Chris Wilson wrote:
> On Thu, Sep 19, 2013 at 12:18:33PM +0200, Daniel Vetter wrote:
> > No buffer overflows here, but better safe than sorry.
>
> You are also introducing needless memsets.
Meh, somehow I've thought kcalloc won't zero. I'll drop the redun
On Thu, Sep 19, 2013 at 02:00:30PM +0300, Jani Nikula wrote:
> On Thu, 19 Sep 2013, Chris Wilson wrote:
> > On Thu, Sep 19, 2013 at 01:38:18PM +0300, Jani Nikula wrote:
> >> On Thu, 19 Sep 2013, Daniel Vetter wrote:
> >> > diff --git a/drivers/gpu/drm/i915/i915_gpu_error.c
> >> > b/drivers/gpu/d
On Thu, 19 Sep 2013, Chris Wilson wrote:
> On Thu, Sep 19, 2013 at 01:38:18PM +0300, Jani Nikula wrote:
>> On Thu, 19 Sep 2013, Daniel Vetter wrote:
>> > diff --git a/drivers/gpu/drm/i915/i915_gpu_error.c
>> > b/drivers/gpu/drm/i915/i915_gpu_error.c
>> > index c38d575..763283e 100644
>> > --- a/
On Thu, 19 Sep 2013, Daniel Vetter wrote:
> And the gratious overallocation of crtcs. Seems to go back to the ums
> days of yonder ...
>
> We also still need it to make the fbdev emulation happy, but I don't
> think there's really a need. Especially since the current fbdev
> emulation doesn't actu
On Thu, Sep 19, 2013 at 01:38:18PM +0300, Jani Nikula wrote:
> On Thu, 19 Sep 2013, Daniel Vetter wrote:
> > diff --git a/drivers/gpu/drm/i915/i915_gpu_error.c
> > b/drivers/gpu/drm/i915/i915_gpu_error.c
> > index c38d575..763283e 100644
> > --- a/drivers/gpu/drm/i915/i915_gpu_error.c
> > +++ b/d
On Thu, Sep 19, 2013 at 12:18:33PM +0200, Daniel Vetter wrote:
> No buffer overflows here, but better safe than sorry.
You are also introducing needless memsets.
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
___
Intel-gfx mailing list
Int
On Thu, Sep 19, 2013 at 12:18:36PM +0200, Daniel Vetter wrote:
> There's actually no real risk since we already check for stricter
> constraints earlier (using UINT_MAX / sizeof (struct
> drm_i915_gem_exec_object2) as the limit). But in eb_create we use
> signed integers, which steals a factor of 2
On Thu, 19 Sep 2013, Daniel Vetter wrote:
> There's actually no real risk since we already check for stricter
> constraints earlier (using UINT_MAX / sizeof (struct
> drm_i915_gem_exec_object2) as the limit). But in eb_create we use
> signed integers, which steals a factor of 2. Luckily struct
> d
On Thu, 19 Sep 2013, Daniel Vetter wrote:
> No buffer overflows here, but better safe than sorry.
>
> Signed-off-by: Daniel Vetter
> ---
> drivers/gpu/drm/i915/i915_gem_execbuffer.c | 5 +++--
> drivers/gpu/drm/i915/i915_gem_gtt.c| 8
> drivers/gpu/drm/i915/i915_gem_tiling.c
On Thu, 19 Sep 2013, Daniel Vetter wrote:
> Done while reviewing all our allocations for fubar. Also a few errant
> cases of lacking () for the sizeof operator - just a bit of OCD.
>
> I've left out all the conversions that also should use kcalloc from
> this patch (it's only 2).
Reviewed-by: Ja
There's actually no real risk since we already check for stricter
constraints earlier (using UINT_MAX / sizeof (struct
drm_i915_gem_exec_object2) as the limit). But in eb_create we use
signed integers, which steals a factor of 2. Luckily struct
drm_i915_gem_exec_object2 for this to not matter.
Sti
Pretty harmless since actually binding such a giant thing would be
really hard to pull off - it doesn't fit into the gtt of any shipping
gpu right now.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/i915/i915_gpu_error.c | 8 +++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git
And the gratious overallocation of crtcs. Seems to go back to the ums
days of yonder ...
We also still need it to make the fbdev emulation happy, but I don't
think there's really a need. Especially since the current fbdev
emulation doesn't actually support cloning.
Signed-off-by: Daniel Vetter
-
1 - 100 of 106 matches
Mail list logo
