https://bugs.freedesktop.org/show_bug.cgi?id=65274
Christian König changed:
What|Removed |Added
Status|RESOLVED|CLOSED
--- Comment #7 from Christian K
Alex Deucher wrote:
On Thu, Jun 27, 2013 at 9:12 AM, Andy Furniss wrote:
Alex Deucher wrote:
On Wed, Jun 26, 2013 at 9:21 AM, wrote:
From: Alex Deucher
These are the radeon patches for 3.11. Some of these patches
are huge so, it might be easier to review things here:
http://cgit.freede
Hi,
> Yes, this works on my rv790 games get high and using vdpau/gl for video
stays low (which is nice as the fan on my card is too noisy on high).
>
> One thing which I guess 99.999% of people won't notice is that doing any
thing with plain X + fluxbox (so no compositing) very briefly ramps up th
On Wed, Jun 26, 2013 at 10:42 AM, Jean-Francois Moine wrote:
> Do you know that there are 2 drm drivers for the Cubox? I posted mine
> (http://lists.infradead.org/pipermail/linux-arm-kernel/2013-May/168732.html)
> before Russell, but I got no return about it yet.
I thought there was some agreemen
On Fri, Jun 28, 2013 at 01:54:21PM -0600, Daniel Drake wrote:
> On Wed, Jun 26, 2013 at 10:42 AM, Jean-Francois Moine wrote:
> > Do you know that there are 2 drm drivers for the Cubox? I posted mine
> > (http://lists.infradead.org/pipermail/linux-arm-kernel/2013-May/168732.html)
> > before Russell
Hi Russell,
Thanks for pointing me to the most recent version of your driver.
Can you comment on the below patch for improved clock handling?
It is based on the approach in Jean-Francois Moine's driver, and would
serve for the basis of having clock info come from the DT. If you have
something else
On Fri, Jun 28, 2013 at 04:11:32PM -0400, Daniel Drake wrote:
> Hi Russell,
>
> Thanks for pointing me to the most recent version of your driver.
> Can you comment on the below patch for improved clock handling?
Sure... lets add some background info first: the big problem here is the
completely d
On Tue, Jun 25, 2013 at 04:47:26PM -0400, Daniel Drake wrote:
> I have tested it on OLPC XO-1.75 (MMP2 aka Armada610) and OLPC XO-4 (MMP3
> aka PXA2128). After a bit of fighting, I have it running. Could you share your
> X driver, or your methodology for testing hardware cursors? I'd like to test
>
On Fri, Jun 28, 2013 at 3:27 PM, Russell King - ARM Linux
wrote:
> On Tue, Jun 25, 2013 at 04:47:26PM -0400, Daniel Drake wrote:
>> I have tested it on OLPC XO-1.75 (MMP2 aka Armada610) and OLPC XO-4 (MMP3
>> aka PXA2128). After a bit of fighting, I have it running. Could you share
>> your
>> X d
On Fri, Jun 28, 2013 at 10:18:48PM +0100, Russell King - ARM Linux wrote:
> On Fri, Jun 28, 2013 at 04:11:32PM -0400, Daniel Drake wrote:
> > +int armada_drm_find_best_clock(struct armada_private *priv, long
> > needed_rate)
> > +{
> > + int i;
> > +
> > + /* check if any clock can meet this r
On Fri, Jun 28, 2013 at 03:36:37PM -0600, Daniel Drake wrote:
> On Fri, Jun 28, 2013 at 3:27 PM, Russell King - ARM Linux
> wrote:
> > On Tue, Jun 25, 2013 at 04:47:26PM -0400, Daniel Drake wrote:
> >> I have tested it on OLPC XO-1.75 (MMP2 aka Armada610) and OLPC XO-4 (MMP3
> >> aka PXA2128). Aft
[Daniel Vetter]
>> Sounds like. Please file a bug report against ACPI -> Video on
>> bugzilla.kernel.org.
>
> When you file that bug please add me and Jani Nikula to the cc
> list. We have a few other inverted brightness quirks all on similar
> machines. So this could all be due to the same strang
https://bugs.freedesktop.org/show_bug.cgi?id=64475
--- Comment #2 from commiethebeas...@gmail.com ---
Created attachment 81676
--> https://bugs.freedesktop.org/attachment.cgi?id=81676&action=edit
GALLIUM_HUD
--
You are receiving this mail because:
You are the assignee for the bug.
https://bugs.freedesktop.org/show_bug.cgi?id=64475
--- Comment #3 from commiethebeas...@gmail.com ---
Yes, governor is performance, power_profile is high.
--
You are receiving this mail because:
You are the assignee for the bug.
___
dri-devel mailing l
On 26.06.2013 23:57, Julian Wollrath wrote:
Hi,
I just tried the DPM support out on a E-450 APU (HD6320) and it did not
work like expected. In the terminal everything seemed ok but when I
started a display manager, the screen showed garbage and the system
basically locked up. The radeon and drm
On Sat, Jun 29, 2013 at 8:05 AM, Sergey Meirovich wrote:
>
> 3.10-rc7 doesn't compile for me
>
> rathamahata@piledriver /usr/local/src/linux-3.10-rc7 $ make -j1 bzImage
> modules
> make[1]: Nothing to be done for `all'.
> make[1]: Nothing to be done for `relocs'.
> CHK include/generated/uap
https://bugs.freedesktop.org/show_bug.cgi?id=63935
--- Comment #55 from Grigori Goronzy ---
Sorry for the noise, I am seeing a different issue related to DPM.
--
You are receiving this mail because:
You are the assignee for the bug.
___
dri-devel mail
https://bugs.freedesktop.org/show_bug.cgi?id=66384
Priority: medium
Bug ID: 66384
Assignee: dri-devel@lists.freedesktop.org
Summary: VDPAU playback hangs when moving window between xrandr
monitors
Severity: normal
Classif
https://bugs.freedesktop.org/show_bug.cgi?id=66384
Michał Górny changed:
What|Removed |Added
Hardware|Other |x86-64 (AMD64)
OS|All
https://bugzilla.kernel.org/show_bug.cgi?id=60231
Summary: DisplayPort monitor not detected on PowerColor Radeon
HD 4850
Product: Drivers
Version: 2.5
Kernel Version: 3.10
Platform: All
OS/Version: Linux
Tree:
On Sat, Jun 29, 2013 at 2:07 PM, Sergey Meirovich wrote:
>> (and possibly the
>> mkregtable binary) and trying again might fix it.
>
> Removing mkregtable has indeed the compile issue for me. Thanks!
Ok, so something failed at an earlier build. That error is probably
long gone, though, since the
On Sun, Jun 30, 2013 at 8:13 AM, Linus Torvalds
wrote:
> On Sat, Jun 29, 2013 at 2:07 PM, Sergey Meirovich
> wrote:
>>> (and possibly the
>>> mkregtable binary) and trying again might fix it.
>>
>> Removing mkregtable has indeed the compile issue for me. Thanks!
>
> Ok, so something failed at a
On Sat, Jun 29, 2013 at 05:58:26PM +0200, Sebastian Hesselbarth wrote:
> On 06/29/2013 05:06 PM, Daniel Drake wrote:
>> On Fri, Jun 28, 2013 at 3:18 PM, Russell King - ARM Linux
>> wrote:
>>> Sure... lets add some background info first: the big problem here is the
>>> completely different registe
Hi,
Thanks for all the clear comments and explanations - I'll address all
of that in the next patch.
On Fri, Jun 28, 2013 at 3:18 PM, Russell King - ARM Linux
wrote:
> Sure... lets add some background info first: the big problem here is the
> completely different register layouts for the clock r
On 06/29/2013 05:06 PM, Daniel Drake wrote:
On Fri, Jun 28, 2013 at 3:18 PM, Russell King - ARM Linux
wrote:
Sure... lets add some background info first: the big problem here is the
completely different register layouts for the clock register:
On Armada 510:
31:30 - select the clock input fro
On 06/29/2013 08:45 PM, Russell King - ARM Linux wrote:
On Sat, Jun 29, 2013 at 05:58:26PM +0200, Sebastian Hesselbarth wrote:
On 06/29/2013 05:06 PM, Daniel Drake wrote:
On Fri, Jun 28, 2013 at 3:18 PM, Russell King - ARM Linux
wrote:
Sure... lets add some background info first: the big pr
On Sat, Jun 29, 2013 at 09:06:47AM -0600, Daniel Drake wrote:
> MMP2 (Armada 610) and MMP3 (PXA2128, no Armada name) is even a bit
> more complex than that.
> On MMP2 the selectable clocks are written in bits 31:30 and are:
> 0 - AXI, 1 - LCD1, 2 - LCD2, 3 - HDMI
>
> On MMP3 the selectable clocks
On Sat, Jun 29, 2013 at 1:26 PM, Russell King - ARM Linux
wrote:
> So, I'd suggest that an initial approach would be something along the
> lines of:
> - if there is an external clock, can it generate the desired rate?
> if yes, use it.
> - otherwise, get the clock rate from the internal clocks a
Quite a number of things has changed since the last revision in the
core code - notably the move to use drm_plane for overlay, and the
limited and restricted use of dma_buf so that gem objects can be
passed to the GALCORE code and libbmm contiguous video frames can
be imported into DRM.
As I thoug
This patch adds ARGB hardware cursor support to the DRM driver for the
Marvell Armada SoCs. ARGB cursors are supported at either 32x64 or
64x32 resolutions.
Signed-off-by: Russell King
---
drivers/gpu/drm/armada/armada_510.c |1 +
drivers/gpu/drm/armada/armada_crtc.c | 244 +++
Support importing certain dma_bufs back into gem - notably those which
are either contiguous or are our own exports which do not use
dma_map_sg().
Signed-off-by: Russell King
---
drivers/gpu/drm/armada/armada_drv.c |4 +-
drivers/gpu/drm/armada/armada_fb.c |6 +++
drivers/gpu/drm/armada
On Sat, Jun 29, 2013 at 4:52 PM, Sergey Meirovich wrote:
>
> There was overheating issue, that caused forced power off in the
> middle of the first compile.
Ok, then the thing is easily explained by simply the filesystem being
shut down in an incomplete state. Sounds like the mkregtable binary
ha
From: Abbas Raza
DRM_INFO calls in the drm init routines are causing a large delay at boot time
due to which imx_drm_init call average takes around 26 ms. Changing DRM_INFO to
DRM_DEBUG reduces startup time to < 3ms.
Signed-off-by: Abbas Raza
CC: David Airlie
Acked-by: Dmitry Eremin-Solenikov
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130629/38b59634/attachment-0001.html>
successfully.
--
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/20130629/52a274b9/attachment.html>
chives/dri-devel/attachments/20130629/d893388a/attachment.html>
K?nig ---
Good, so we can probably close this bugreport.
--
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/20130629/fad9d
Alex Deucher wrote:
> On Thu, Jun 27, 2013 at 9:12 AM, Andy Furniss wrote:
>> Alex Deucher wrote:
>>>
>>> On Wed, Jun 26, 2013 at 9:21 AM, wrote:
From: Alex Deucher
These are the radeon patches for 3.11. Some of these patches
are huge so, it might be easier to review t
l
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130629/bfb7d15c/attachment-0001.html>
[Daniel Vetter]
>> Sounds like. Please file a bug report against ACPI -> Video on
>> bugzilla.kernel.org.
>
> When you file that bug please add me and Jani Nikula to the cc
> list. We have a few other inverted brightness quirks all on similar
> machines. So this could all be due to the same strang
the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130629/8bcd072d/attachment.html>
scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130629/44dc8bc2/attachment.html>
On 26.06.2013 23:57, Julian Wollrath wrote:
> Hi,
>
> I just tried the DPM support out on a E-450 APU (HD6320) and it did not
> work like expected. In the terminal everything seemed ok but when I
> started a display manager, the screen showed garbage and the system
> basically locked up. The radeon
On Sat, Jun 29, 2013 at 8:05 AM, Sergey Meirovich
wrote:
>
> 3.10-rc7 doesn't compile for me
>
> rathamahata at piledriver /usr/local/src/linux-3.10-rc7 $ make -j1 bzImage
> modules
> make[1]: Nothing to be done for `all'.
> make[1]: Nothing to be done for `relocs'.
> CHK include/generated
was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130629/f26502a5/attachment.html>
ack to the first monitor, it
again hangs after moving half of it.
--
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
vel/attachments/20130629/c4552ed6/attachment.html>
https://bugzilla.kernel.org/show_bug.cgi?id=60231
Summary: DisplayPort monitor not detected on PowerColor Radeon
HD 4850
Product: Drivers
Version: 2.5
Kernel Version: 3.10
Platform: All
OS/Version: Linux
Tree:
On Sat, Jun 29, 2013 at 2:07 PM, Sergey Meirovich
wrote:
>> (and possibly the
>> mkregtable binary) and trying again might fix it.
>
> Removing mkregtable has indeed the compile issue for me. Thanks!
Ok, so something failed at an earlier build. That error is probably
long gone, though, since th
On Sat, Jun 29, 2013 at 05:58:26PM +0200, Sebastian Hesselbarth wrote:
> On 06/29/2013 05:06 PM, Daniel Drake wrote:
>> On Fri, Jun 28, 2013 at 3:18 PM, Russell King - ARM Linux
>> wrote:
>>> Sure... lets add some background info first: the big problem here is the
>>> completely different registe
On Sat, Jun 29, 2013 at 09:06:47AM -0600, Daniel Drake wrote:
> MMP2 (Armada 610) and MMP3 (PXA2128, no Armada name) is even a bit
> more complex than that.
> On MMP2 the selectable clocks are written in bits 31:30 and are:
> 0 - AXI, 1 - LCD1, 2 - LCD2, 3 - HDMI
>
> On MMP3 the selectable clocks
Hi,
Thanks for all the clear comments and explanations - I'll address all
of that in the next patch.
On Fri, Jun 28, 2013 at 3:18 PM, Russell King - ARM Linux
wrote:
> Sure... lets add some background info first: the big problem here is the
> completely different register layouts for the clock r
On 06/29/2013 05:06 PM, Daniel Drake wrote:
> On Fri, Jun 28, 2013 at 3:18 PM, Russell King - ARM Linux
> wrote:
>> Sure... lets add some background info first: the big problem here is the
>> completely different register layouts for the clock register:
>>
>> On Armada 510:
>> 31:30 - select the
On 06/29/2013 08:45 PM, Russell King - ARM Linux wrote:
> On Sat, Jun 29, 2013 at 05:58:26PM +0200, Sebastian Hesselbarth wrote:
>> On 06/29/2013 05:06 PM, Daniel Drake wrote:
>>> On Fri, Jun 28, 2013 at 3:18 PM, Russell King - ARM Linux
>>>wrote:
Sure... lets add some background info firs
On Sat, Jun 29, 2013 at 1:26 PM, Russell King - ARM Linux
wrote:
> So, I'd suggest that an initial approach would be something along the
> lines of:
> - if there is an external clock, can it generate the desired rate?
> if yes, use it.
> - otherwise, get the clock rate from the internal clocks a
Quite a number of things has changed since the last revision in the
core code - notably the move to use drm_plane for overlay, and the
limited and restricted use of dma_buf so that gem objects can be
passed to the GALCORE code and libbmm contiguous video frames can
be imported into DRM.
As I thoug
This patch adds support for the pair of LCD controllers on the Marvell
Armada 510 SoCs. This driver supports:
- multiple contiguous scanout buffers for video and graphics
- shm backed cacheable buffer objects for X pixmaps for Vivante GPU
acceleration
- dual lcd0 and lcd1 crt operation
- video o
This patch adds ARGB hardware cursor support to the DRM driver for the
Marvell Armada SoCs. ARGB cursors are supported at either 32x64 or
64x32 resolutions.
Signed-off-by: Russell King
---
drivers/gpu/drm/armada/armada_510.c |1 +
drivers/gpu/drm/armada/armada_crtc.c | 244 +++
Support importing certain dma_bufs back into gem - notably those which
are either contiguous or are our own exports which do not use
dma_map_sg().
Signed-off-by: Russell King
---
drivers/gpu/drm/armada/armada_drv.c |4 +-
drivers/gpu/drm/armada/armada_fb.c |6 +++
drivers/gpu/drm/armada
On Sat, Jun 29, 2013 at 4:52 PM, Sergey Meirovich
wrote:
>
> There was overheating issue, that caused forced power off in the
> middle of the first compile.
Ok, then the thing is easily explained by simply the filesystem being
shut down in an incomplete state. Sounds like the mkregtable binary
h
60 matches
Mail list logo
