Hi Afzal,
On Mon, Jan 07, 2013 at 06:10:13AM +, Mohammed, Afzal wrote:
> Hi Steffen,
>
> On Tue, Dec 18, 2012 at 22:34:14, Steffen Trumtrar wrote:
> > Add helper to get fb_videomode from devicetree.
>
> > drivers/video/fbmon.c | 42 ++
> > include/l
On 04.01.2013 22:25, Stephen Warren wrote:
> On 01/04/2013 03:09 AM, Terje Bergström wrote:
> ...
>> I think we have now two ways to go forward with cons and pros:
>> 1) Keep host1x and tegra-drm as separate driver
>>+ Code almost done
>>- we need dummy device and dummy driver
>>- extr
https://bugs.freedesktop.org/show_bug.cgi?id=58840
--- Comment #7 from almos ---
(In reply to comment #6)
> (In reply to comment #5)
> > Couldn't set 1280x960 OpenGL video mode: Couldn't find matching GLX visual
> > on the next startup.
>
> If you want MSAA GLX visuals, you must *install* the ga
Op 06-01-13 20:01, Konstantin Belousov schreef:
> In ttm_write_lock(), for the interruptible sleep, the __ttm_write_lock()
> is used as the sleep predicate. On the other hand, for the
> uninterruptible case, __ttm_read_lock() is evaluated. It seems that
> the code was not changed since the initial
https://bugzilla.kernel.org/show_bug.cgi?id=49021
Niels Ole Salscheider changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|
vga-switcheroo with apple-gmux does not switch correctly on my system. The PCI
configuration space is not restored correctly, resulting in MSI not working
after switch.
Only useful item in dmesg is:
[ 33.922807] radeon :01:00.0: Refused to change power state, currently in
D3
I did some t
On Mon, Jan 7, 2013 at 9:18 AM, Maarten Lankhorst
wrote:
> vga-switcheroo with apple-gmux does not switch correctly on my system. The PCI
> configuration space is not restored correctly, resulting in MSI not working
> after switch.
>
> Only useful item in dmesg is:
>
> [ 33.922807] radeon :
On Sun, Jan 6, 2013 at 7:59 AM, Eldad Zack wrote:
>
> Hi Alex,
>
> Commit 0ecebb9e0d14e9948e0b1529883a776758117d6f "drm/radeon: switch to a
> finer grained reset for evergreen" introduced a hard system lockup to my
> setup. I found it after bisecting, and confirmed it by reverting it on
> the late
https://bugs.freedesktop.org/show_bug.cgi?id=57875
--- Comment #19 from Stefan Dösinger ---
Are there any comments on the 2nd extension spec? If it looks good to you I'll
do some tests with the r200 and r500 GPUs I have to see how unclipped Z values
behave in fragment processing to make sure the
Hi Steffen,
On Mon, Jan 07, 2013 at 13:36:48, Steffen Trumtrar wrote:
> On Mon, Jan 07, 2013 at 06:10:13AM +, Mohammed, Afzal wrote:
> > This breaks DaVinci (da8xx_omapl_defconfig), following change was
> > required to get it build if OF_VIDEOMODE or/and FB_MODE_HELPERS
> > is not defined. Th
Trivial comment fix. Since drm_exit() was removed in 2.6.39 (commit 8410ea3b ).
As such the comment
is incorrect. drm_put_dev() is now called from drm_platform_exit() or when the
pci device is "unplugged".
Signed-off-by: Philippe De Swert
---
drivers/gpu/drm/drm_stub.c |2 +-
1 file change
https://bugs.freedesktop.org/show_bug.cgi?id=57875
--- Comment #20 from Marek Olšák ---
FWIW, the extension specification looks good to me.
--
You are receiving this mail because:
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@
> We will be waiting a until one kernel is released before activating fan
> management by default.
So these fan stuff will be merged into 3.9?
--
Ozan Çağlayan
Research Assistant
Galatasaray University - Computer Engineering Dept.
http://www.ozancaglayan.com
___
On 01/07/2013 01:20 AM, Terje Bergström wrote:
> On 04.01.2013 22:25, Stephen Warren wrote:
>> On 01/04/2013 03:09 AM, Terje Bergström wrote:
>> ...
>>> I think we have now two ways to go forward with cons and pros:
>>> 1) Keep host1x and tegra-drm as separate driver
>>>+ Code almost done
>>>
From: Alex Deucher
Hi Dave,
A few more fixes for DMA and a mac quick.
The following changes since commit eda85d6ad490923152544fba0473798b6cc0edf6:
drm/nouveau: fix init with agpgart-uninorth (2013-01-04 16:04:33 +1000)
are available in the git repository at:
git://people.freedesktop.or
https://bugs.freedesktop.org/show_bug.cgi?id=41265
--- Comment #54 from Michel Dänzer ---
(In reply to comment #53)
Gerald, we can only support the open source drivers here. For fglrx issues
you'll have to turn to fglrx support resources.
--
You are receiving this mail because:
You are the ass
On Mon, Jan 7, 2013 at 2:46 AM, Mohammed, Afzal wrote:
> Hi Steffen,
>
> On Mon, Jan 07, 2013 at 13:36:48, Steffen Trumtrar wrote:
>> On Mon, Jan 07, 2013 at 06:10:13AM +, Mohammed, Afzal wrote:
>
>> > This breaks DaVinci (da8xx_omapl_defconfig), following change was
>> > required to get it bu
https://bugs.freedesktop.org/show_bug.cgi?id=58667
--- Comment #30 from Alex Deucher ---
Should be fixed with this mesa commit:
http://cgit.freedesktop.org/mesa/mesa/commit/?id=4332f6fc185f968e7563e748b8c949021937c935
--
You are receiving this mail because:
You are the assignee for the bug.
___
https://bugs.freedesktop.org/show_bug.cgi?id=59089
--- Comment #1 from Alex Deucher ---
Should be fixed with this mesa commit:
http://cgit.freedesktop.org/mesa/mesa/commit/?id=4332f6fc185f968e7563e748b8c949021937c935
--
You are receiving this mail because:
You are the assignee for the bug.
Add a property to the hdmi node so we can specify the HDMI version in
the device tree instead of just defaulting to v1.4 with the existence of
the dt node.
Signed-off-by: Sean Paul
---
.../devicetree/bindings/drm/exynos/hdmi.txt|3 +++
drivers/gpu/drm/exynos/exynos_hdmi.c
On Wed, Dec 19, 2012 at 04:51:06PM +, Chris Wilson wrote:
> Avoid clobbering adjacent blocks if they happen to expire earlier and
> amalgamate together to form the requested hole.
>
> In passing this fixes a regression from
> commit ea7b1dd44867e9cd6bac67e7c9fc3f128b5b255c
> Author: Daniel Vet
On Mon, Jan 7, 2013 at 3:54 PM, Mitch Bradley wrote:
> On 1/7/2013 10:43 AM, Sean Paul wrote:
>> Add a property to the hdmi node so we can specify the HDMI version in
>> the device tree instead of just defaulting to v1.4 with the existence of
>> the dt node.
>>
>> Signed-off-by: Sean Paul
>> ---
On Mon, Jan 7, 2013 at 4:33 PM, Eldad Zack wrote:
>
> On Mon, 7 Jan 2013, Alex Deucher wrote:
>> On Sun, Jan 6, 2013 at 7:59 AM, Eldad Zack wrote:
>> >
>> > Hi Alex,
>> >
>> > Commit 0ecebb9e0d14e9948e0b1529883a776758117d6f "drm/radeon: switch to a
>> > finer grained reset for evergreen" introduc
On 01/07/2013 01:43 PM, Sean Paul wrote:
> Add a property to the hdmi node so we can specify the HDMI version in
> the device tree instead of just defaulting to v1.4 with the existence of
> the dt node.
> diff --git a/Documentation/devicetree/bindings/drm/exynos/hdmi.txt
> b/Documentation/devicet
On Wed, Dec 26, 2012 at 3:27 AM, Prathyush K wrote:
> The wait_for_vblank interface is modified to the complete_scanout
> function in fimd. This patch adds the fimd_complete_scanout function
>
With this series, you have a race if the rmfb happens before the flip
has completed.
Why not just use r
tree: git://people.freedesktop.org/~danvet/drm-intel.git drm-intel-fixes
head: 42f26597f4631137336315798461cd3d554e120c
commit: 42f26597f4631137336315798461cd3d554e120c [4/4] drm: Only evict the
blocks required to create the requested hole
config: make ARCH=x86_64 allyesconfig
All error/warni
On Fri, 4 Jan 2013, Alex Deucher wrote:
R6xx and r7xx are really all you need to worry about in this case.
R1xx-r5xx UMS uses a different kernel interface for command submission
and evergreen and later don't have UMS drm support. UMS r6xx/r7xx
support used the same kernel interface for comman
On Jan 7, 2013 5:32 PM, "Stephen Warren" wrote:
>
> On 01/07/2013 01:43 PM, Sean Paul wrote:
> > Add a property to the hdmi node so we can specify the HDMI version in
> > the device tree instead of just defaulting to v1.4 with the existence of
> > the dt node.
>
> > diff --git a/Documentation/devi
At Dave's request I ran some regression tests on my CS-refactoring
patches [1] against old UMS userspace. The tests have revealed
that the current kernel can be provoked into crashing in UMS mode
(and the problem is unrelated to refactoring of CS code; it has
been here before).
The following patch
In UMS mode parser->rdev is NULL, so dereferencing
will cause an oops.
Signed-off-by: Ilija Hadzic
---
drivers/gpu/drm/radeon/radeon_cs.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/radeon/radeon_cs.c
b/drivers/gpu/drm/radeon/radeon_cs.c
index 396bab
parser->chunks[.].kpage[.] is not always kmalloc-ed
by the parser initialization, so parser_fini should
not try to kfree it if it didn't allocate it.
This patch fixes a kernel oops that can be provoked
in UMS mode.
Signed-off-by: Ilija Hadzic
---
drivers/gpu/drm/radeon/r600_cs.c | 6 --
1 f
Index into chunks[] array doesn't look right.
Signed-off-by: Ilija Hadzic
---
drivers/gpu/drm/radeon/radeon_cs.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/radeon/radeon_cs.c
b/drivers/gpu/drm/radeon/radeon_cs.c
index 45151c4..469661f 100644
--- a/dr
On Tue, Jan 8, 2013 at 12:09 AM, Ilija Hadzic
wrote:
>
>
> On Fri, 4 Jan 2013, Alex Deucher wrote:
>
>> R6xx and r7xx are really all you need to worry about in this case.
>> R1xx-r5xx UMS uses a different kernel interface for command submission
>> and evergreen and later don't have UMS drm support
On Mon, Jan 7, 2013 at 7:21 PM, Marek Olšák wrote:
>
> IIRC, the radeon gallium drivers call abort() if they encounter an
> unsupported DRM version (that is UMS).
>
I am not familiar enough to comment, but my observation was that as
soon as I backed out to classic, the segfault went away. So I as
https://bugs.freedesktop.org/show_bug.cgi?id=59089
--- Comment #2 from Alexandre Demers ---
Seems good now.
--
You are receiving this mail because:
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lis
https://bugs.freedesktop.org/show_bug.cgi?id=59089
Alexandre Demers changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
Hi Dave,
This patch set adds bug fixes and code cleanups and also
includes previous pull request you missed.
http://www.spinics.net/lists/dri-devel/msg32253.html
Summary:
- change exynos file license
. Most of exynos files had been copied from some randome
file and not updated corre
From: Dave Airlie
this tells the drivers when the mux is switch to/from it, can be used
to report outputs as disconnected to userspace etc.
Signed-off-by: Dave Airlie
---
drivers/gpu/vga/vga_switcheroo.c | 19 +++
include/linux/vga_switcheroo.h | 1 +
2 files changed, 20 ins
From: Dave Airlie
otherwise userspace can get very confused
---
drivers/gpu/drm/radeon/radeon_connectors.c | 4
drivers/gpu/drm/radeon/radeon_device.c | 14 ++
drivers/gpu/drm/radeon/radeon_mode.h | 2 ++
3 files changed, 20 insertions(+)
diff --git a/drivers/gpu/dr
https://bugs.freedesktop.org/show_bug.cgi?id=59089
Thomas Rohloff changed:
What|Removed |Added
Status|RESOLVED|REOPENED
Resolution|FIXED
https://bugs.freedesktop.org/show_bug.cgi?id=58667
--- Comment #31 from Thomas Rohloff ---
(In reply to comment #30)
> Should be fixed with this mesa commit:
> http://cgit.freedesktop.org/mesa/mesa/commit/
> ?id=4332f6fc185f968e7563e748b8c949021937c935
Sadly it isn't.
--
You are receiving this
https://bugs.freedesktop.org/show_bug.cgi?id=59089
--- Comment #4 from Alexandre Demers ---
(In reply to comment #3)
> I don't want to play the bad guy but for me this is not fixed, just reduced.
Well, I closed it because I don't have the continuous GPU fault flood happening
anymore. However, I
https://bugs.freedesktop.org/show_bug.cgi?id=58354
--- Comment #12 from Alexandre Demers ---
Just to let you know, commit
http://cgit.freedesktop.org/mesa/mesa/commit/?id=4332f6fc185f968e7563e748b8c949021937c935
didn't solve the issue for this bug.
--
You are receiving this mail because:
You ar
On 1/7/2013 10:43 AM, Sean Paul wrote:
> Add a property to the hdmi node so we can specify the HDMI version in
> the device tree instead of just defaulting to v1.4 with the existence of
> the dt node.
>
> Signed-off-by: Sean Paul
> ---
> .../devicetree/bindings/drm/exynos/hdmi.txt|3
On Mon, 7 Jan 2013, Alex Deucher wrote:
> On Sun, Jan 6, 2013 at 7:59 AM, Eldad Zack wrote:
> >
> > Hi Alex,
> >
> > Commit 0ecebb9e0d14e9948e0b1529883a776758117d6f "drm/radeon: switch to a
> > finer grained reset for evergreen" introduced a hard system lockup to my
> > setup. I found it after bi
Hi Rob,
On Tue, Jan 08, 2013 at 01:36:50, Rob Clark wrote:
> On Mon, Jan 7, 2013 at 2:46 AM, Mohammed, Afzal wrote:
> > On Mon, Jan 07, 2013 at 13:36:48, Steffen Trumtrar wrote:
> >> I just did a quick "make da8xx_omapl_defconfig && make" and it builds just
> >> fine.
> >> On what version did y
and restart
the X server for it to pick up the visuals.
--
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130107/466cf179/attachment-0001.html>
2012/12/27 Prathyush K :
> If fimd is runtime suspended (by DPMS OFF), fimd_suspend does not
> call fimd_activate(false) and just returns. Similarily the check in
Right and that is our intension. pm suspend should be ignored because
fimd already became off.
And if we want for fimd to be pm suspend
Applied.
Thanks,
Inki Dae
2013/1/3 Rahul Sharma :
> This patch implements the exynos_drm_crtc_finish_pageflip in
> exynos_drm_crtc.c. This avoids the duplication of same code
> in mixer, fimd and vidi.
>
> Signed-off-by: Rahul Sharma
> Signed-off-by: Stephane Marchesin
> ---
> This patch is bas
This patch set adds support for more resolutions and refresh rates to Samsung
Exynos5 SoC series which contains hdmi transmitter (hdmi v1.4a compliant).
Given resolution will be supported or not, is decided by two factors:
1) Corresponding pixel clock is supported by hdmi PHY.
2) Mixer supports th
This patch adds the display mode check operation to exynos_mixer_ops
in drm-common-hdmi. In Exynos SoCs, mixer IP can put certain restrictions
on the proposed display modes. These restriction needs to be considered
during mode negotiation, which happens immediately after edid parsing.
Both, mixer
This patch adds the implementation of check_timing callback in the mixer
driver. Based on the mixer version, correct set of restrictions will be
exposed by the mixer driver. A resolution will be acceptable only if passes
the criteria set by mixer and hdmi IPs.
Signed-off-by: Rahul Sharma
Signed-o
With this patch, mixer driver find the correct resolution mode for
the range of resolutions, upto 1080 vertical lines. Resolution will
be categorized to NTSC SD, PAL SD or HD and the correct mode is
set to the mixer configuration register.
Signed-off-by: Rahul Sharma
Signed-off-by: Sean Paul
---
From: Sean Paul
This patch programs the core and timing generator registers using the
timing data provided in drm_display_mode and not using hard-coded
configurations.
Additional PHY configs has been added. This allows us to support more
permissible resolutions and refresh rates.
Signed-off-by:
Hi Steffen,
On Tue, Dec 18, 2012 at 22:34:14, Steffen Trumtrar wrote:
> Add helper to get fb_videomode from devicetree.
> drivers/video/fbmon.c | 42 ++
> include/linux/fb.h|4
This breaks DaVinci (da8xx_omapl_defconfig), following change wa
Hi Steffen,
On Tue, Dec 18, 2012 at 22:34:09, Steffen Trumtrar wrote:
> Finally, right in time before the end of the world on friday, v16 of the
> display helpers.
After another big bang, your series in the previous world was tried ;)
This series has been tested on DA850 EVM, AM335x EVM, EVM-SK
On Mon, Jan 07, 2013 at 06:23:54AM +, Mohammed, Afzal wrote:
> Hi Steffen,
>
> On Tue, Dec 18, 2012 at 22:34:09, Steffen Trumtrar wrote:
>
> > Finally, right in time before the end of the world on friday, v16 of the
> > display helpers.
>
> After another big bang, your series in the previous
Hi Afzal,
On Mon, Jan 07, 2013 at 06:10:13AM +, Mohammed, Afzal wrote:
> Hi Steffen,
>
> On Tue, Dec 18, 2012 at 22:34:14, Steffen Trumtrar wrote:
> > Add helper to get fb_videomode from devicetree.
>
> > drivers/video/fbmon.c | 42 ++
> > include/l
On 04.01.2013 22:25, Stephen Warren wrote:
> On 01/04/2013 03:09 AM, Terje Bergstr?m wrote:
> ...
>> I think we have now two ways to go forward with cons and pros:
>> 1) Keep host1x and tegra-drm as separate driver
>>+ Code almost done
>>- we need dummy device and dummy driver
>>- extr
the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130107/331778f6/attachment.html>
Op 06-01-13 20:01, Konstantin Belousov schreef:
> In ttm_write_lock(), for the interruptible sleep, the __ttm_write_lock()
> is used as the sleep predicate. On the other hand, for the
> uninterruptible case, __ttm_read_lock() is evaluated. It seems that
> the code was not changed since the initial
https://bugzilla.kernel.org/show_bug.cgi?id=49021
Niels Ole Salscheider changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|
vga-switcheroo with apple-gmux does not switch correctly on my system. The PCI
configuration space is not restored correctly, resulting in MSI not working
after switch.
Only useful item in dmesg is:
[ 33.922807] radeon :01:00.0: Refused to change power state, currently in
D3
I did some t
On Mon, Jan 7, 2013 at 9:18 AM, Maarten Lankhorst
wrote:
> vga-switcheroo with apple-gmux does not switch correctly on my system. The PCI
> configuration space is not restored correctly, resulting in MSI not working
> after switch.
>
> Only useful item in dmesg is:
>
> [ 33.922807] radeon :
On Sun, Jan 6, 2013 at 7:59 AM, Eldad Zack wrote:
>
> Hi Alex,
>
> Commit 0ecebb9e0d14e9948e0b1529883a776758117d6f "drm/radeon: switch to a
> finer grained reset for evergreen" introduced a hard system lockup to my
> setup. I found it after bisecting, and confirmed it by reverting it on
> the late
e the extension doesn't guarantee
anything the HW cannot provide.
--
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/2013
Hi Steffen,
On Mon, Jan 07, 2013 at 13:36:48, Steffen Trumtrar wrote:
> On Mon, Jan 07, 2013 at 06:10:13AM +, Mohammed, Afzal wrote:
> > This breaks DaVinci (da8xx_omapl_defconfig), following change was
> > required to get it build if OF_VIDEOMODE or/and FB_MODE_HELPERS
> > is not defined. Th
Trivial comment fix. Since drm_exit() was removed in 2.6.39 (commit 8410ea3b ).
As such the comment
is incorrect. drm_put_dev() is now called from drm_platform_exit() or when the
pci device is "unplugged".
Signed-off-by: Philippe De Swert
---
drivers/gpu/drm/drm_stub.c |2 +-
1 file change
:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130107/61070061/attachment.html>
> We will be waiting a until one kernel is released before activating fan
> management by default.
So these fan stuff will be merged into 3.9?
--
Ozan ?a?layan
Research Assistant
Galatasaray University - Computer Engineering Dept.
http://www.ozancaglayan.com
On 01/07/2013 01:20 AM, Terje Bergstr?m wrote:
> On 04.01.2013 22:25, Stephen Warren wrote:
>> On 01/04/2013 03:09 AM, Terje Bergstr?m wrote:
>> ...
>>> I think we have now two ways to go forward with cons and pros:
>>> 1) Keep host1x and tegra-drm as separate driver
>>>+ Code almost done
>>>
From: Alex Deucher
Hi Dave,
A few more fixes for DMA and a mac quick.
The following changes since commit eda85d6ad490923152544fba0473798b6cc0edf6:
drm/nouveau: fix init with agpgart-uninorth (2013-01-04 16:04:33 +1000)
are available in the git repository at:
git://people.freedesktop.or
e the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130107/3f9f5d84/attachment.html>
On Mon, Jan 7, 2013 at 2:46 AM, Mohammed, Afzal wrote:
> Hi Steffen,
>
> On Mon, Jan 07, 2013 at 13:36:48, Steffen Trumtrar wrote:
>> On Mon, Jan 07, 2013 at 06:10:13AM +, Mohammed, Afzal wrote:
>
>> > This breaks DaVinci (da8xx_omapl_defconfig), following change was
>> > required to get it bu
.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130107/d8879463/attachment.html>
.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130107/63add791/attachment.html>
Add a property to the hdmi node so we can specify the HDMI version in
the device tree instead of just defaulting to v1.4 with the existence of
the dt node.
Signed-off-by: Sean Paul
---
.../devicetree/bindings/drm/exynos/hdmi.txt|3 +++
drivers/gpu/drm/exynos/exynos_hdmi.c
On Wed, Dec 19, 2012 at 04:51:06PM +, Chris Wilson wrote:
> Avoid clobbering adjacent blocks if they happen to expire earlier and
> amalgamate together to form the requested hole.
>
> In passing this fixes a regression from
> commit ea7b1dd44867e9cd6bac67e7c9fc3f128b5b255c
> Author: Daniel Vet
On Mon, Jan 7, 2013 at 3:54 PM, Mitch Bradley wrote:
> On 1/7/2013 10:43 AM, Sean Paul wrote:
>> Add a property to the hdmi node so we can specify the HDMI version in
>> the device tree instead of just defaulting to v1.4 with the existence of
>> the dt node.
>>
>> Signed-off-by: Sean Paul
>> ---
On Mon, Jan 7, 2013 at 4:33 PM, Eldad Zack wrote:
>
> On Mon, 7 Jan 2013, Alex Deucher wrote:
>> On Sun, Jan 6, 2013 at 7:59 AM, Eldad Zack wrote:
>> >
>> > Hi Alex,
>> >
>> > Commit 0ecebb9e0d14e9948e0b1529883a776758117d6f "drm/radeon: switch to a
>> > finer grained reset for evergreen" introduc
On 01/07/2013 01:43 PM, Sean Paul wrote:
> Add a property to the hdmi node so we can specify the HDMI version in
> the device tree instead of just defaulting to v1.4 with the existence of
> the dt node.
> diff --git a/Documentation/devicetree/bindings/drm/exynos/hdmi.txt
> b/Documentation/devicet
On Wed, Dec 26, 2012 at 3:27 AM, Prathyush K wrote:
> The wait_for_vblank interface is modified to the complete_scanout
> function in fimd. This patch adds the fimd_complete_scanout function
>
With this series, you have a race if the rmfb happens before the flip
has completed.
Why not just use r
On Fri, 4 Jan 2013, Alex Deucher wrote:
> R6xx and r7xx are really all you need to worry about in this case.
> R1xx-r5xx UMS uses a different kernel interface for command submission
> and evergreen and later don't have UMS drm support. UMS r6xx/r7xx
> support used the same kernel interface for
s what it supports in the EDID, so there shouldn't
> be a need to duplicate this in the device tree (besides, how can you
> know what the user plugged in without parsing the EDID?)
-- next part ------
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130107/2c5c4a84/attachment.html>
At Dave's request I ran some regression tests on my CS-refactoring
patches [1] against old UMS userspace. The tests have revealed
that the current kernel can be provoked into crashing in UMS mode
(and the problem is unrelated to refactoring of CS code; it has
been here before).
The following patch
In UMS mode parser->rdev is NULL, so dereferencing
will cause an oops.
Signed-off-by: Ilija Hadzic
---
drivers/gpu/drm/radeon/radeon_cs.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/radeon/radeon_cs.c
b/drivers/gpu/drm/radeon/radeon_cs.c
index 396bab
parser->chunks[.].kpage[.] is not always kmalloc-ed
by the parser initialization, so parser_fini should
not try to kfree it if it didn't allocate it.
This patch fixes a kernel oops that can be provoked
in UMS mode.
Signed-off-by: Ilija Hadzic
---
drivers/gpu/drm/radeon/r600_cs.c | 6 --
1 f
Index into chunks[] array doesn't look right.
Signed-off-by: Ilija Hadzic
---
drivers/gpu/drm/radeon/radeon_cs.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/radeon/radeon_cs.c
b/drivers/gpu/drm/radeon/radeon_cs.c
index 45151c4..469661f 100644
--- a/dr
On Mon, Jan 7, 2013 at 7:21 PM, Marek Ol??k wrote:
>
> IIRC, the radeon gallium drivers call abort() if they encounter an
> unsupported DRM version (that is UMS).
>
I am not familiar enough to comment, but my observation was that as
soon as I backed out to classic, the segfault went away. So I as
On 1/7/2013 10:43 AM, Sean Paul wrote:
> Add a property to the hdmi node so we can specify the HDMI version in
> the device tree instead of just defaulting to v1.4 with the existence of
> the dt node.
>
> Signed-off-by: Sean Paul
> ---
> .../devicetree/bindings/drm/exynos/hdmi.txt|3
On Mon, 7 Jan 2013, Alex Deucher wrote:
> On Sun, Jan 6, 2013 at 7:59 AM, Eldad Zack wrote:
> >
> > Hi Alex,
> >
> > Commit 0ecebb9e0d14e9948e0b1529883a776758117d6f "drm/radeon: switch to a
> > finer grained reset for evergreen" introduced a hard system lockup to my
> > setup. I found it after bi
91 matches
Mail list logo
