||
--
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/20140609/fa4a8032/attachment.html>
||
--
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/20140609/3eae404b/attachment.html>
the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140609/cfcca051/attachment.html>
ith the latest
software.
--
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/20140609/744885c4/attachment.html>
Hi Dave,
Some additional patches for radeon for 3.16 now that -fixes has been merged.
- Gart fix for all asics r6xx+
- Add some VM tuning parameters
- misc fixes
The following changes since commit 4c0dae57873edb1560b738c6519361c5ecd443ae:
drm/doc: Fix nouveau typo (2014-06-10 09:34:43 +1000)
On Mon, Jun 09, 2014 at 11:29:28AM -0300, Fabio Estevam wrote:
> On Mon, Jun 9, 2014 at 11:06 AM, Russell King - ARM Linux
> wrote:
>
> > Please check the status in /sys/class/drm/card0-HDMI-A-1/status. This
> > should report the current state of the hotplug detection.
>
> /sys/class/drm/card0-
On Mon, Jun 9, 2014 at 9:21 PM, Michel D?nzer wrote:
> From: Michel D?nzer
>
> Fixes WARN()s from the DRM core since the page flip rework.
>
> Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=77521
> Signed-off-by: Michel D?nzer
Applied. thanks!
Alex
> ---
> drivers/gpu/drm/radeon/rade
On Mon, Jun 09, 2014 at 03:47:46PM -0300, Fabio Estevam wrote:
> Also tested keeping LVDS parent as PLL5 and reverted this commit:
>
> commit 17b9b3b9e88ac6564689283a08034faf2c048fdb
> Author: Sascha Hauer
> Date: Mon Apr 14 16:20:39 2014 +0200
>
> ARM: imx6q: clk: Parent DI clocks to vide
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140609/4bb7aa44/attachment-0001.html>
xt part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140609/23d761bd/attachment.html>
xt part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140609/339313ee/attachment.html>
On Mon, Jun 09, 2014 at 03:38:55PM -0300, Fabio Estevam wrote:
> On Mon, Jun 9, 2014 at 3:15 PM, Fabio Estevam wrote:
> >> I wonder if the problem is that HDMI and LVDS are interfering with each
> >> other wrt the required pixel clock, and LVDS is winning. If we have
> >> HDMI enabled, many HDMI
On Mon, Jun 09, 2014 at 03:15:16PM -0300, Fabio Estevam wrote:
> With HDMI cable connected (no image is seen on HDMI, only on lvds cable):
>
> imx-drm display-subsystem.11: bound 12.hdmi (ops hdmi_ops)
> imx-hdmi 12.hdmi: EVENT=plugin
> imx-hdmi 12.hdmi: Non-CEA mode used in HDMI
> imx
On Mon, May 19, 2014 at 6:22 PM, Lucas Stach wrote:
> Am Montag, den 19.05.2014, 11:02 +0200 schrieb Thierry Reding:
>> On Mon, May 19, 2014 at 04:10:58PM +0900, Alexandre Courbot wrote:
>> > Some architectures (e.g. ARM) need the CPU buffers to be explicitely
>> > flushed for a memory write to ta
corrupted
image.
--
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/20140609/b9a7d070/attachment.html>
On Mon, Jun 09, 2014 at 11:29:28AM -0300, Fabio Estevam wrote:
> On Mon, Jun 9, 2014 at 11:06 AM, Russell King - ARM Linux
> wrote:
>
> > Please check the status in /sys/class/drm/card0-HDMI-A-1/status. This
> > should report the current state of the hotplug detection.
>
> /sys/class/drm/card0-
Patrik, Alan -
Should you add a MAINTAINERS entry for gma500 with one or both of you as
maintainers? What's the status?
BR,
Jani.
On Mon, 09 Jun 2014, Dan Carpenter wrote:
> The FB_REG09 define is cut and pasted twice so we can remove the second
> instance.
>
> Signed-off-by: Dan Carpenter
>
https://bugzilla.kernel.org/show_bug.cgi?id=51381
--- Comment #32 from Alex Deucher ---
Created attachment 138641
--> https://bugzilla.kernel.org/attachment.cgi?id=138641&action=edit
testing patch
Does this patch help? Note, this will probably break regular suspend/resume,
so just test it for
https://bugzilla.kernel.org/show_bug.cgi?id=51381
--- Comment #31 from Alex Deucher ---
Ok, it appears powering up the dGPU has never worked properly on your system.
As a workaround for now you can disable runpm by adding radeon.runpm=0. I can
add a quirk to the driver to disable runpm on your
The FB_REG09 define is cut and pasted twice so we can remove the second
instance.
Signed-off-by: Dan Carpenter
diff --git a/drivers/gpu/drm/gma500/mid_bios.c
b/drivers/gpu/drm/gma500/mid_bios.c
index a97e38e..d75ecb3 100644
--- a/drivers/gpu/drm/gma500/mid_bios.c
+++ b/drivers/gpu/drm/gma500/mi
https://bugzilla.kernel.org/show_bug.cgi?id=51381
--- Comment #30 from Teofilis Martisius ---
Created attachment 138631
--> https://bugzilla.kernel.org/attachment.cgi?id=138631&action=edit
dmesg output for 3.15-rc8 patched with delay of 200
--
You are receiving this mail because:
You are watc
https://bugzilla.kernel.org/show_bug.cgi?id=51381
--- Comment #29 from Teofilis Martisius ---
Created attachment 138621
--> https://bugzilla.kernel.org/attachment.cgi?id=138621&action=edit
dmesg output for 3.12.21 patched with delay of 200
--
You are receiving this mail because:
You are watch
https://bugzilla.kernel.org/show_bug.cgi?id=51381
--- Comment #28 from Teofilis Martisius ---
Hello,
Sorry for the delay, I had other plans for the weekend.
The patch did not help. I tried it with default delay of 20, and then I tried
it with delay set to 200 (200 what? milliseconds?). I tried
m(CL_BUILD_PROGRAM_FAILURE)
--
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/20140609/53373df8/attachment.html>
ight, 0, inodes);
--
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/20140609/bfaad6be/attachment.html>
Enable LCD related nodes and reference panel node in the hlcdc (High
LCD Controller) controller on sama5d3xek boards.
Signed-off-by: Boris BREZILLON
---
arch/arm/boot/dts/sama5d31ek.dts | 24
arch/arm/boot/dts/sama5d33ek.dts | 24
arch/arm/boot/d
Add LCD panel related nodes (backlight, regulators and panel) to the
sama5d3 Display Module dtsi.
Signed-off-by: Boris BREZILLON
---
arch/arm/boot/dts/sama5d3xdm.dtsi | 32
1 file changed, 32 insertions(+)
diff --git a/arch/arm/boot/dts/sama5d3xdm.dtsi
b/arch/a
Define the HLCDC (High LCD Controller) IP available on some sama5d3 SoCs
(i.e. sama5d31, sama5d33, sama5d34 and sama5d36).
Signed-off-by: Boris BREZILLON
---
arch/arm/boot/dts/sama5d3_lcd.dtsi | 26 ++
1 file changed, 26 insertions(+)
diff --git a/arch/arm/boot/dts/sama5
The HLCDC (High LCD Controller) IP supports 4 different output mode
(RGB444, RGB565, RGB666 and RGB888) and the pin muxing depends on the
chosen RGB mode.
Split the pin definition to be able to set the pin config according to the
selected mode.
Signed-off-by: Boris BREZILLON
---
arch/arm/boot/d
The Atmel HLCDC (High LCD Controller) IP available on some Atmel SoCs (i.e.
at91sam9n12, at91sam9x5 family or sama5d3 family) provides a display
controller device.
This display controller support at least one primary plane and might
provide several overlays and an hardware cursor depending on the
The HLCDC IP available in some Atmel SoCs (i.e. sam9x5i.e. at91sam9n12,
at91sam9x5 family or sama5d3 family) provide a PWM device.
This driver add support for this PWM device.
Signed-off-by: Boris BREZILLON
---
.../devicetree/bindings/pwm/atmel-hlcdc-pwm.txt| 40
drivers/pwm/Kconfig
The HLCDC IP available on some Atmel SoCs (i.e. at91sam9n12, at91sam9x5
family or sama5d3 family) exposes 2 subdevices:
- a display controller (controlled by a DRM driver)
- a PWM chip
Add support for the MFD device which will just retrieve HLCDC clocks and
create a regmap so that subdevices can a
Hello,
This patch series adds support for Atmel HLCDC (High LCD Controller)
available on some Atmel SoCs (i.e. the sama5d3 family).
The HLCDC actually provides a Display Controller and a PWM device, hence I
decided to declare an MFD device that exposes 2 subdevices: a display
controller and a PWM
On Mon, Jun 9, 2014 at 5:09 PM, Russell King - ARM Linux
wrote:
> Right, so the problem isn't at the HDMI level, but at the DI level... so
> that's where we need to debug what's being setup. I left some debugging
> in ipu-di.c - could you try enabling that please?
Sure, will capture the logs to
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140609/9d4ee611/attachment.html>
org/archives/dri-devel/attachments/20140609/e62d924f/attachment.html>
https://bugzilla.kernel.org/show_bug.cgi?id=77521
--- Comment #2 from Martin Andersson ---
(In reply to Michel D?nzer from comment #1)
> Created attachment 138561 [details]
> Move fb update from radeon_flip_work_func() to radeon_crtc_page_flip()
>
> This (untested) patch should fix at least the
non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140609/a75710e5/attachment-0001.sig>
the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140609/aeb9df01/attachment.html>
the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140609/c8e945db/attachment.html>
ceiving 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/20140609/27ce5733/attachment.html>
re the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140609/f49c46a2/attachment.html>
The patch disables non-enabled HW windows on applying
configuration, it will allow to clear windows enabled
by bootloader.
Signed-off-by: Andrzej Hajda
---
drivers/gpu/drm/exynos/exynos_drm_fimd.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
b/d
On Mon, Jun 9, 2014 at 3:38 PM, Fabio Estevam wrote:
> On Mon, Jun 9, 2014 at 3:15 PM, Fabio Estevam wrote:
>>> I wonder if the problem is that HDMI and LVDS are interfering with each
>>> other wrt the required pixel clock, and LVDS is winning. If we have
>>> HDMI enabled, many HDMI sinks will o
On Mon, Jun 9, 2014 at 3:15 PM, Fabio Estevam wrote:
>> I wonder if the problem is that HDMI and LVDS are interfering with each
>> other wrt the required pixel clock, and LVDS is winning. If we have
>> HDMI enabled, many HDMI sinks will only work if we set one of their
>> supported modes (with th
On Mon, Jun 9, 2014 at 2:49 PM, Russell King - ARM Linux
wrote:
> On Mon, Jun 09, 2014 at 11:29:28AM -0300, Fabio Estevam wrote:
>> On Mon, Jun 9, 2014 at 11:06 AM, Russell King - ARM Linux
>> wrote:
>>
>> > Please check the status in /sys/class/drm/card0-HDMI-A-1/status. This
>> > should report
On Mon, Jun 09, 2014 at 10:44:14AM -0300, Fabio Estevam wrote:
> Russell,
>
> On Fri, Jun 6, 2014 at 10:56 AM, Russell King
> wrote:
> > The initial state at boot is assumed to be disconnected, and we hope
> > to receive an interrupt to update the status. Let's be more explicit
> > about the cur
Signed-off-by: Damien Lespiau
---
Documentation/DocBook/drm.tmpl | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/Documentation/DocBook/drm.tmpl b/Documentation/DocBook/drm.tmpl
index efef637..0854aed 100644
--- a/Documentation/DocBook/drm.tmpl
+++ b/Documentation/DocBook/drm.t
It was reported that this comment was confusing, and indeed it is.
Signed-off-by: Damien Lespiau
---
include/uapi/drm/i915_drm.h | 8 ++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/include/uapi/drm/i915_drm.h b/include/uapi/drm/i915_drm.h
index ff57f07..eacd063 100644
---
DRM_COMMAND_END is 0xa0, so the last driver ioctl is 0x9f, not 0x99.
Signed-off-by: Damien Lespiau
---
include/uapi/drm/drm.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/include/uapi/drm/drm.h b/include/uapi/drm/drm.h
index 9abbeb9..b0b8556 100644
--- a/include/uapi/drm/d
I cannot see a need to provide a DRM_ version of ARRAY_SIZE(), only used
in a few places. I suspect its usage has been spread by copy & paste
rather than anything else.
Let's just remove it for plain ARRAY_SIZE().
Signed-off-by: Damien Lespiau
---
drivers/gpu/drm/armada/armada_drv.c | 2 +-
It was reported a long time ago the various comments about the DRM/driver
specific ioctl split were confusing. So tried to fix that.
Patch #1 is a bonus patch that removes DRM_ARRAY_SIZE().
--
Damien
Damien Lespiau (3):
drm: Remove DRM_ARRAY_SIZE() for ARRAY_SIZE()
drm: Driver-specific ioct
One small step after another, the never-ending crusade towards better
code continues.
Signed-off-by: Damien Lespiau
---
drivers/gpu/drm/ast/ast_post.c | 4 ++--
drivers/gpu/drm/exynos/exynos_dp_core.c | 2 +-
drivers/gpu/drm/exynos/exynos_drm_dpi.c |
Matt aded this plane property before we had a table giving a summary of
the properties. Add it there.
Cc: Matt Roper
Signed-off-by: Damien Lespiau
---
Documentation/DocBook/drm.tmpl | 10 +-
1 file changed, 9 insertions(+), 1 deletion(-)
diff --git a/Documentation/DocBook/drm.tmpl b/Do
On Mon, Jun 9, 2014 at 1:56 PM, Stephen Boyd wrote:
> On 06/06/14 07:03, Stephane Viau wrote:
>> The clock driver usually complains when a clock is being prepared
>> before setting its rate. It is the case here for "core_clk" which
>> needs to be set at 19.2 MHz before we attempt a prepare_enable(
On Mon, 2014-06-09 at 02:41 +, YC Chen wrote:
> Hi Benjamin,
> After confirm with our h/w designer, ast2400 did not support
> big-endian as you said. We support it in our previous product(PCI
> revision < 0x20) for frame buffer access. So, the possible solution is
> made in sw level for big-end
https://bugzilla.kernel.org/show_bug.cgi?id=76761
--- Comment #13 from Alex Deucher ---
(In reply to swoorupj from comment #12)
> Hi Alex,
>
> I have reported the same issue in bugs.freedesktop. I tried out the 3.15
> linux kernel in archlinux just today. And this issue is still prevalent to
> m
On 2014? 06? 02? 20:48, Andrzej Hajda wrote:
> On 06/02/2014 12:42 PM, Andrzej Hajda wrote:
>> On 06/02/2014 12:11 PM, Tomasz Figa wrote:
>>> Hi Rahul, Andrzej,
>>>
>>> On 02.06.2014 11:42, Rahul Sharma wrote:
On 2 June 2014 14:41, Andrzej Hajda wrote:
> Hi Rahul,
>
> On 05/28/201
ubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140609/c1ce3ac5/attachment.sig>
achments/20140609/15e39dff/attachment-0001.sig>
On Mon, Jun 9, 2014 at 11:33 AM, Shawn Guo wrote:
> On Mon, Jun 09, 2014 at 11:29:28AM -0300, Fabio Estevam wrote:
>> On Mon, Jun 9, 2014 at 11:06 AM, Russell King - ARM Linux
>> wrote:
>>
>> > Please check the status in /sys/class/drm/card0-HDMI-A-1/status. This
>> > should report the current s
On Mon, Jun 9, 2014 at 11:06 AM, Russell King - ARM Linux
wrote:
> Please check the status in /sys/class/drm/card0-HDMI-A-1/status. This
> should report the current state of the hotplug detection.
/sys/class/drm/card0-HDMI-A-1/status returns the correct state for
HDMI cable connection.
> Remem
On 06/06/14 07:03, Stephane Viau wrote:
> The clock driver usually complains when a clock is being prepared
> before setting its rate. It is the case here for "core_clk" which
> needs to be set at 19.2 MHz before we attempt a prepare_enable().
That's only true in the downstream vendor kernel. Upst
Russell,
On Fri, Jun 6, 2014 at 10:56 AM, Russell King
wrote:
> The initial state at boot is assumed to be disconnected, and we hope
> to receive an interrupt to update the status. Let's be more explicit
> about the current state - reading the PHY status register tells us
> the current level of
On Mon, Jun 9, 2014 at 9:40 AM, Damien Lespiau
wrote:
> Signed-off-by: Damien Lespiau
Reviewed-by: Alex Deucher
> ---
> Documentation/DocBook/drm.tmpl | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/Documentation/DocBook/drm.tmpl b/Documentation/DocBook/drm.tmpl
> in
On Mon, Jun 9, 2014 at 9:39 AM, Damien Lespiau
wrote:
> DRM_COMMAND_END is 0xa0, so the last driver ioctl is 0x9f, not 0x99.
>
> Signed-off-by: Damien Lespiau
Reviewed-by: Alex Deucher
> ---
> include/uapi/drm/drm.h | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/inc
for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140609/a3133c0a/attachment.html>
On Mon, Jun 9, 2014 at 9:39 AM, Damien Lespiau
wrote:
> I cannot see a need to provide a DRM_ version of ARRAY_SIZE(), only used
> in a few places. I suspect its usage has been spread by copy & paste
> rather than anything else.
>
> Let's just remove it for plain ARRAY_SIZE().
>
> Signed-off-by:
reedesktop.org/archives/dri-devel/attachments/20140609/7cceb3f6/attachment.html>
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140609/dc0109d4/attachment.html>
On Mon, Jun 09, 2014 at 02:20:22PM +0100, Damien Lespiau wrote:
> Matt aded this plane property before we had a table giving a summary of
> the properties. Add it there.
>
> Cc: Matt Roper
> Signed-off-by: Damien Lespiau
Reviewed-by: Matt Roper
> ---
> Documentation/DocBook/drm.tmpl | 10 +++
o and
/usr/lib/xorg/modules/extensions/libglx.so have debugging symbols.
--
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/
PRIME, or others?
BTW, just xcompmgr -a should be enough, no need for -c.
--
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/2014
https://bugzilla.kernel.org/show_bug.cgi?id=76761
swoorupj at gmail.com changed:
What|Removed |Added
CC||swoorupj at gmail.com
--- Comment
https://bugzilla.kernel.org/show_bug.cgi?id=77521
--- Comment #1 from Michel D?nzer ---
Created attachment 138561
--> https://bugzilla.kernel.org/attachment.cgi?id=138561&action=edit
Move fb update from radeon_flip_work_func() to radeon_crtc_page_flip()
This (untested) patch should fix at leas
part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140609/952b267a/attachment.html>
https://bugzilla.kernel.org/show_bug.cgi?id=77531
Alvaro Fernando Garc?a changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
Hi Benjamin,
After confirm with our h/w designer, ast2400 did not support big-endian as you
said. We support it in our previous product(PCI revision < 0x20) for frame
buffer access. So, the possible solution is made in sw level for big-endian
support. May we know the impact if we did not support
https://bugzilla.kernel.org/show_bug.cgi?id=77531
--- Comment #6 from Alvaro Fernando Garc?a
---
I've repoerted the bug to weston bugzilla.
Link: https://bugs.freedesktop.org/show_bug.cgi?id=79809
Thanks for answering!
--
You are receiving this mail because:
You are watching the assignee of
https://bugzilla.kernel.org/show_bug.cgi?id=77531
Alex Deucher changed:
What|Removed |Added
CC||alexdeucher at gmail.com
--- Comment #5 fr
it's likely to cause
problems.
--
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/20140609/4f044f54/attachment.html>
81 matches
Mail list logo
