On 19.09.2013 08:57, Daniel Vetter wrote:
On Wed, Sep 18, 2013 at 10:38 PM, Dave Chinner wrote:
No, that's wrong. ->count_objects should never ass SHRINK_STOP.
Indeed, it should always return a count of objects in the cache,
regardless of the context.
SHRINK_STOP is for ->scan_objects to tell
Hi Dave,
Looks like I'm just a bit late with my -fixes pull request. Some more
dealock fixes around pageflips and gpu hangs, fixes for hsw hangs when
doing modesets/dpms. And a few minor things to rectify issues with our
modeset state tracking which the checker spotted.
Nothing yet for the vgaarb
Some omapdss panels are connected to outputs/encoders(HDMI/DSI/DPI) that require
regulators. The output's connect op tries to get a regulator which may not exist
yet because it might get registered later in the kernel boot.
omapdrm currently ignores those panels which return a non zero value when
omapdrm established connections for omap_dss_device devices when probed. It
should also be responsible to disconnect the devices. Keeping the devices
connected can prevent the panel driver modules from unloading, it can also
cause problems when omapdrm is re-inserted.
Signed-off-by: Archit Taneja
On Wed, Sep 18, 2013 at 12:38:23PM +0200, Knut Petersen wrote:
> On 18.09.2013 11:10, Daniel Vetter wrote:
>
> Just now I prepared a patch changing the same function in vmscan.c
> >Also, this needs to be rebased to the new shrinker api in 3.12, I
> >simply haven't rolled my trees forward yet.
>
>
[my keyboard my be on the fritz - it's not typing what I'm thinking...]
On Thu, Sep 19, 2013 at 06:38:22AM +1000, Dave Chinner wrote:
> On Wed, Sep 18, 2013 at 12:38:23PM +0200, Knut Petersen wrote:
> > On 18.09.2013 11:10, Daniel Vetter wrote:
> >
> > Just now I prepared a patch changing the sam
Fixed a trivial typo.
Signed-off-by: Sachin Kamat
---
drivers/gpu/drm/exynos/exynos_drm_fimd.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
index 868a14d..5d5b97d 100644
--- a/drivers/g
Hi Andrzej,
Thanks for your quick response.
Removing display-timings::clock-frequency property from
arch/arm/boot/dts/exynos4210-origen.dts
fixed this issue. However, I also had to remove the same from
drivers/video/of_display_timing.c as
shown below, else probe fails. I will send a patch to fix t
Hi,
You can just set this property to zero.
of_parse_display_timing will not complain and
you will have default settings.
Regards
Andrzej
On 09/18/2013 10:15 AM, Sachin Kamat wrote:
> Hi Andrzej,
>
> Thanks for your quick response.
> Removing display-timings::clock-frequency property from
> arch
Hi Laurent,
On 6 September 2013 20:07, Laurent Pinchart
wrote:
> Hi Vikas,
>
> On Wednesday 04 September 2013 16:20:59 Vikas Sajjan wrote:
>> On 9 August 2013 22:44, Laurent Pinchart wrote:
>> > MIPI DBI is a configurable-width parallel display bus that transmits
>> > commands and data.
>> >
>> >
On 09/18/2013 02:30 PM, Igor Gnatenko wrote:
> On Wed, 2013-09-18 at 09:03 +0800, Aaron Lu wrote:
>> On 09/17/2013 09:34 PM, Igor Gnatenko wrote:
>>>
>>> Aaron, how about fix indicator on ThinkPads ?
>>
>> Can you please describe the problem in detail, is it that when you
>> adjust brightness level
On Wed, 2013-09-18 at 20:31 +0800, Aaron Lu wrote:
> On 09/18/2013 02:30 PM, Igor Gnatenko wrote:
> > On Wed, 2013-09-18 at 09:03 +0800, Aaron Lu wrote:
> >> On 09/17/2013 09:34 PM, Igor Gnatenko wrote:
> >>>
> >>> Aaron, how about fix indicator on ThinkPads ?
> >>
> >> Can you please describe the
On 18/09/13 16:17, Archit Taneja wrote:
> On Wednesday 18 September 2013 06:11 PM, Tomi Valkeinen wrote:
>> On 18/09/13 14:08, Archit Taneja wrote:
>>> Some omapdss panels are connected to outputs/encoders(HDMI/DSI/DPI)
>>> that require
>>> regulators. The output's connect op tries to get a regulat
On Thu, Sep 19, 2013 at 08:57:04AM +0200, Daniel Vetter wrote:
> On Wed, Sep 18, 2013 at 10:38 PM, Dave Chinner wrote:
> > No, that's wrong. ->count_objects should never ass SHRINK_STOP.
> > Indeed, it should always return a count of objects in the cache,
> > regardless of the context.
> >
> > SHR
https://bugs.freedesktop.org/show_bug.cgi?id=60182
--- Comment #31 from Michel Dänzer ---
(In reply to comment #30)
> This, plus the patch in comment 6, fixed it for me [...]
Thanks, but please try without that other patch. If it's still necessary,
something is still wrong.
--
You are receivin
https://bugs.freedesktop.org/show_bug.cgi?id=69081
Michel Dänzer changed:
What|Removed |Added
Attachment #86100|0 |1
is obsolete|
https://bugs.freedesktop.org/show_bug.cgi?id=69081
Michel Dänzer changed:
What|Removed |Added
Attachment #86101|0 |1
is obsolete|
https://bugs.freedesktop.org/show_bug.cgi?id=69081
--- Comment #16 from Michel Dänzer ---
(In reply to comment #9)
> KF still shows the same problem, so it is probable that both problems were
> unrelated.
Yes, so the KF problem should be tracked separately.
For CK II, there are no shader compil
https://bugs.freedesktop.org/show_bug.cgi?id=60182
--- Comment #32 from Michel Dänzer ---
Actually, just let us know if you still get any 'Attempted to destroy
previously destroyed buffer.' messages.
--
You are receiving this mail because:
You are the assignee for the bug.
_
Hi,
On Thursday 19 September 2013 03:38 PM, Tomi Valkeinen wrote:
On 19/09/13 11:49, Archit Taneja wrote:
omapdrm established connections for omap_dss_device devices when probed. It
should also be responsible to disconnect the devices. Keeping the devices
connected can prevent the panel driver
https://bugs.freedesktop.org/show_bug.cgi?id=61269
Christoph Egger changed:
What|Removed |Added
Attachment #75299|0 |1
is obsolete|
https://bugs.freedesktop.org/show_bug.cgi?id=69463
--- Comment #5 from samit vats ---
The Debug output is :
(II) [KMS] Kernel modesetting enabled.
libEGL debug: Native platform type: drm (environment overwrite)
libEGL debug: ignore EGL_DRIVERS_PATH for setuid/setgid binaries
libEGL debug: EGL se
This fixes VM protection faults.
I have a new piglit test which can iterate over all possible widths, heights,
and depths (including NPOT) and tests mipmapping with various texture targets.
After this is committed, I'll make a new release of libdrm and bump
the libdrm version requirement in Mesa.
https://bugs.freedesktop.org/show_bug.cgi?id=68235
--- Comment #40 from Alexandre Demers ---
Should I continu to see what value I can reach?
--
You are receiving this mail because:
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel
https://bugs.freedesktop.org/show_bug.cgi?id=69463
--- Comment #6 from Michel Dänzer ---
(In reply to comment #5)
> libEGL debug: Native platform type: drm (environment overwrite)
So you set EGL_PLATFORM=drm? Would be interesting to see the debugging output
without that as well.
> libEGL debug
On Don, 2013-09-19 at 14:33 +0200, Marek Olšák wrote:
> This fixes VM protection faults.
>
> I have a new piglit test which can iterate over all possible widths, heights,
> and depths (including NPOT) and tests mipmapping with various texture targets.
>
> After this is committed, I'll make a new
https://bugs.freedesktop.org/show_bug.cgi?id=68235
--- Comment #41 from Alex Deucher ---
Created attachment 86147
--> https://bugs.freedesktop.org/attachment.cgi?id=86147&action=edit
mclk debugging pll debugging output
Can you attach the dmesg output with this patch applied? I want to make su
https://bugs.freedesktop.org/show_bug.cgi?id=68235
--- Comment #42 from Alexandre Demers ---
(In reply to comment #41)
> Created attachment 86147 [details] [review]
> mclk debugging pll debugging output
>
> Can you attach the dmesg output with this patch applied? I want to make
> sure the mclk
On Thu, Sep 19, 2013 at 4:41 PM, Michel Dänzer wrote:
> On Don, 2013-09-19 at 14:33 +0200, Marek Olšák wrote:
>> This fixes VM protection faults.
>>
>> I have a new piglit test which can iterate over all possible widths, heights,
>> and depths (including NPOT) and tests mipmapping with various tex
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
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
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 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
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
https://bugs.freedesktop.org/show_bug.cgi?id=64600
--- Comment #11 from darkbasic ---
Created attachment 86166
--> https://bugs.freedesktop.org/attachment.cgi?id=86166&action=edit
debug radeonsi nopatch
I here my
RADEON_DUMP_SHADERS=1 pyrit benchmark 2> debug.txt
with radeonsi (HD 7950) with
https://bugs.freedesktop.org/show_bug.cgi?id=64201
--- Comment #52 from darkbasic ---
Created attachment 86167
--> https://bugs.freedesktop.org/attachment.cgi?id=86167&action=edit
debug radeonsi nopatch
With the patch there are no shaders in the output, so here is the output
without the patch.
https://bugs.freedesktop.org/show_bug.cgi?id=60182
--- Comment #33 from Jose P. ---
(In reply to comment #32)
> Actually, just let us know if you still get any 'Attempted to destroy
> previously destroyed buffer.' messages.
None at all.
I only get 'XIO: fatal IO error 11 (Resource temporarily
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
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
https://bugs.freedesktop.org/show_bug.cgi?id=49603
Sven Arvidsson changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
BTW, the intuitive explanation of the fix is that we have to minify
the pitch (or POT width) instead of the NPOT width.
Marek
On Thu, Sep 19, 2013 at 6:37 PM, Marek Olšák wrote:
> On Thu, Sep 19, 2013 at 4:41 PM, Michel Dänzer wrote:
>> On Don, 2013-09-19 at 14:33 +0200, Marek Olšák wrote:
>>>
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
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
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
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
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 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
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
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 |
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
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
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 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/
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
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
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
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
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
https://bugs.freedesktop.org/show_bug.cgi?id=43341
Sven Arvidsson changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://bugs.freedesktop.org/show_bug.cgi?id=68235
--- Comment #43 from Alexandre Demers ---
Created attachment 86168
--> https://bugs.freedesktop.org/attachment.cgi?id=86168&action=edit
dmesg with 86147
--
You are receiving this mail because:
You are the assignee for the bug.
___
On Fri, Sep 20, 2013 at 2:40 AM, Damien Lespiau
wrote:
> 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
Acked-by: Ben Skeggs
> ---
> drivers/gpu/drm/nouveau/dispnv04/crtc.c | 2 --
>
https://bugs.freedesktop.org/show_bug.cgi?id=64810
Johannes Obermayr changed:
What|Removed |Added
Attachment #86034|0 |1
is obsolete|
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
https://bugs.freedesktop.org/show_bug.cgi?id=68451
--- Comment #20 from Peter Kraus ---
Hello,
I wont be able to test it until October. Will update then, unless someone else
can test it instead.
Peter
--
You are receiving this mail because:
You are the assignee for the bug.
> 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 Zimmerman
> > wrote:
> > > I have an ASUS P6X58D-Premium mobo with a GeForce 9400G
hment was scrubbed...
Name: dmesg-good.log
Type: application/octet-stream
Size: 94912 bytes
Desc: dmesg-good.log
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130919/28b8dda0/attachment-0001.obj>
/PFIFO_WRITE/IN reason: PAGE_NOT_PRESENT
> >
> > I will try next with the patch series you sent to Linus yesterday, to
> > see if that happens to fix this.
>
> Nope, with your patch series from yesterday the problem still exists.
For the bad boot, I found some boot messages in /var/log/messages.
Truncated version attached.
--
Paul
-- next part --
A non-text attachment was scrubbed...
Name: messages-bad.log
Type: application/octet-stream
Size: 96871 bytes
Desc: messages-bad.log
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130919/19827837/attachment-0001.obj>
68 matches
Mail list logo
