iting with
bus errors when starting new ones (see attached log).
--
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/20130820/ed3a46ec/attachment.html>
Hi Philipp,
On Tuesday 13 August 2013 16:37:07 Philipp Zabel wrote:
> Hi Laurent,
>
> thanks for this update. I'm very happy about the move to the display entity
> model, given that the i.MX6 IPU has both drm/display and v4l2/capture ports
> in a single device - this will allow to use a unified d
Quoting Fabio Estevam (2013-08-20 08:40:52)
> On Tue, Aug 20, 2013 at 5:38 AM, Liu Ying wrote:
>
> > diff --git a/Documentation/devicetree/bindings/clock/imx6q-clock.txt
> > b/Documentation/devicetree/bindings/clock/imx6q-clock.txt
> > index 5a90a72..90e923e 100644
> > --- a/Documentation/device
I see lots of warning like this with 3.11-rc5 on my thinkpad t40.
[197481.739272] [drm:intel_pipe_config_compare] *ERROR* mismatch in
adjusted_mode.flags (expected 1, found 0)
[197481.739283] [ cut here ]
[197481.739352] WARNING: CPU: 0 PID: 556 at
drivers/gpu/drm/i915/in
On Tue, Aug 20, 2013 at 11:24 AM, Laurent Pinchart
wrote:
> Hi Rob,
>
> On Tuesday 13 August 2013 20:43:50 Rob Clark wrote:
>> On Fri, Aug 9, 2013 at 1:14 PM, Laurent Pinchart wrote:
>> > Hi everybody,
>> >
>> > Here's the third RFC of the Common Display Framework.
>> >
>> > I won't repeat all the
Hi Rob,
On Tuesday 13 August 2013 20:43:50 Rob Clark wrote:
> On Fri, Aug 9, 2013 at 1:14 PM, Laurent Pinchart wrote:
> > Hi everybody,
> >
> > Here's the third RFC of the Common Display Framework.
> >
> > I won't repeat all the background information from the versions one and
> > two here, you
Hi Rob,
On Tuesday 13 August 2013 20:52:15 Rob Clark wrote:
> On Fri, Aug 9, 2013 at 1:14 PM, Laurent Pinchart wrote:
> > MIPI DBI is a configurable-width parallel display bus that transmits
> > commands and data.
> >
> > Add a new DBI Linux bus type that implements the usual bus
> > infrastructu
https://bugzilla.kernel.org/show_bug.cgi?id=60231
--- Comment #5 from prettyvanilla at posteo.at ---
I am running a current mainline kernel until dpm stabilises, so I am on 3.11rc6
currently, which has the patch mentioned already applied. Sadly, no change in
behaviour.
I updated the dmesg output a
https://bugzilla.kernel.org/show_bug.cgi?id=60231
--- Comment #4 from prettyvanilla at posteo.at ---
Created attachment 107260
--> https://bugzilla.kernel.org/attachment.cgi?id=107260&action=edit
Xorg.0.log
--
You are receiving this mail because:
You are watching the assignee of the bug.
https://bugzilla.kernel.org/show_bug.cgi?id=60231
--- Comment #3 from prettyvanilla at posteo.at ---
Created attachment 107259
--> https://bugzilla.kernel.org/attachment.cgi?id=107259&action=edit
xrandr --verbose
--
You are receiving this mail because:
You are watching the assignee of the bug.
https://bugzilla.kernel.org/show_bug.cgi?id=60231
prettyvanilla at posteo.at changed:
What|Removed |Added
Attachment #106381|0 |1
is obsolete|
The irq flags state is already established by the outer
spin_lock_irqsave(); re-disabling irqs is redundant.
Signed-off-by: Peter Hurley
---
drivers/gpu/drm/drm_irq.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/drm_irq.c b/drivers/gpu/drm/drm_irq.c
i
https://bugzilla.kernel.org/show_bug.cgi?id=60775
--- Comment #1 from Ryan Letourneau ---
Just tried solution here
http://ewaldertl.blogspot.ca/2013/02/update-fedora-18-to-kernel-376-let-fail.html
but did not resolve issue
--
You are receiving this mail because:
You are watching the assignee o
On 08/20/2013 11:40 PM, Fabio Estevam wrote:
> On Tue, Aug 20, 2013 at 5:38 AM, Liu Ying wrote:
>
>> diff --git a/Documentation/devicetree/bindings/clock/imx6q-clock.txt
>> b/Documentation/devicetree/bindings/clock/imx6q-clock.txt
>> index 5a90a72..90e923e 100644
>> --- a/Documentation/devicetre
https://bugzilla.kernel.org/show_bug.cgi?id=60523
--- Comment #42 from Alex Deucher ---
I can reproduce it in Fedora 17 as well (gcc 4.7). So it seems to be something
about Fedora 16 (gcc 4.6).
--
You are receiving this mail because:
You are watching the assignee of the bug.
https://bugzilla.kernel.org/show_bug.cgi?id=60523
--- Comment #41 from Alex Deucher ---
Well, it helps a little, but I'm still able to reproduce it eventually even
with the patch. The same kernel source is working fine on a fedora 16 system
and now exhibits this problem on Fedora 19. So maybe i
https://bugzilla.kernel.org/show_bug.cgi?id=60523
--- Comment #40 from queryv+fd at gmail.com ---
(In reply to Alex Deucher from comment #39)
> Created attachment 107254 [details]
> fix for 3.11
>
> The attached patch seems to fix it for me.
That doesn't seem to fix it for me (6870). I first tri
On 08/21/2013 09:59 AM, Shawn Guo wrote:
> Hi Ying,
>
> On Tue, Aug 20, 2013 at 06:08:48PM +0800, Liu Ying wrote:
>>> While I admit to having introduced the combination of 1/3.5 fixed
>>> divider and configurable 1/1,1/2 divder clocks to describe this
>>> fractional divider for the reasons you sta
I see lots of warning like this with 3.11-rc5 on my thinkpad t40.
[197481.739272] [drm:intel_pipe_config_compare] *ERROR* mismatch in
adjusted_mode.flags (expected 1, found 0)
[197481.739283] [ cut here ]
[197481.739352] WARNING: CPU: 0 PID: 556 at
drivers/gpu/drm/i915/in
https://bugzilla.kernel.org/show_bug.cgi?id=60775
Bug ID: 60775
Summary: Installing NVIDIA proprietary drivers on kernel
3.10.7-100.fc18.x86_64 errors out . . . can't find
kernel source files
Product: Drivers
Vers
The irq flags state is already established by the outer
spin_lock_irqsave(); re-disabling irqs is redundant.
Signed-off-by: Peter Hurley
---
drivers/gpu/drm/drm_irq.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/drm_irq.c b/drivers/gpu/drm/drm_irq.c
i
Hi Ying,
On Tue, Aug 20, 2013 at 06:08:48PM +0800, Liu Ying wrote:
> > While I admit to having introduced the combination of 1/3.5 fixed
> > divider and configurable 1/1,1/2 divder clocks to describe this
> > fractional divider for the reasons you state, I think the correct
> > solution would be t
On Tue, Aug 20, 2013 at 02:18:27PM -0700, Mike Turquette wrote:
> Quoting Fabio Estevam (2013-08-20 08:40:52)
> > On Tue, Aug 20, 2013 at 5:38 AM, Liu Ying wrote:
> >
> > > diff --git a/Documentation/devicetree/bindings/clock/imx6q-clock.txt
> > > b/Documentation/devicetree/bindings/clock/imx6q-
d LCD record" error is different now and some lines in the end
are not in the new log.
--
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/
On 08/20/2013 05:43 PM, Philipp Zabel wrote:
> Am Dienstag, den 20.08.2013, 16:38 +0800 schrieb Liu Ying:
>> The ldb_di[0/1]_ipu_div clock dividers in the CSCMR2 register
>> of i.MX53, i.MX6Q and i.MX6DL SoCs can be configured to a 1/3.5
>> drivider or a 1/7 divider. The common clock framework cann
Ignore this patch for now. there are still problems with newer gcc
versions that aren't fixed yet.
Alex
On Tue, Aug 20, 2013 at 1:16 PM, Alex Deucher wrote:
> Newer versions of gcc seem to wander off into no-man's land
> when using variably sized arrays. Atombios tends to do things
> like:
>
>
On Mon, Aug 19, 2013 at 4:59 PM, Pali Rohár wrote:
> On Friday 16 August 2013 14:57:07 Pali Rohár wrote:
>> In commit 77145f1cbdf8d28b46ff8070ca749bad821e0774 was
>> introduced error which cause that reclocking on nv40 not
>> working anymore. There is missing assigment of return value
>> from pll_
Hi Rob,
On Tuesday 13 August 2013 20:43:50 Rob Clark wrote:
> On Fri, Aug 9, 2013 at 1:14 PM, Laurent Pinchart wrote:
> > Hi everybody,
> >
> > Here's the third RFC of the Common Display Framework.
> >
> > I won't repeat all the background information from the versions one and
> > two here, you
Hi
2013/8/19 Furquan Shaikh :
> Enables getting correct mode clock when reading pipe config
> This patch has been tested successfully on top of drm-intel-nightly tree
>
> Signed-off-by: Furquan Shaikh
> ---
> drivers/gpu/drm/i915/i915_reg.h | 6
> drivers/gpu/drm/i915/intel_ddi.c
On Tue, Aug 20, 2013 at 07:56:42AM -0700, Ian Romanick wrote:
> On 08/19/2013 04:53 PM, Damien Lespiau wrote:
> >It's only used in drm_platform.c.
> >
> >Signed-off-by: Damien Lespiau
> >---
> > drivers/gpu/drm/drm_platform.c | 7 +++
> > include/drm/drmP.h | 3 ---
> > 2 files ch
.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130820/92adecf1/attachment.html>
https://bugzilla.kernel.org/show_bug.cgi?id=60523
--- Comment #39 from Alex Deucher ---
Created attachment 107254
--> https://bugzilla.kernel.org/attachment.cgi?id=107254&action=edit
fix for 3.11
The attached patch seems to fix it for me.
--
You are receiving this mail because:
You are watch
In ldb split mode, the ldb_di[0/1]_ipu_div dividers should
be configured as clock dividers of 1/3.5, while in others
ldb modes of 1/7. This patch gets the di[0/1]_div_3_5,
di[0/1]_div_7 and di[0/1]_div_sel clocks and sets the
di[0/1]_div_3_5 or di[0/1]_div_7 clocks to be the parents of
di[0/1]_div_
This patch adds di[0/1]_div_3_5, di[0/1]_div_7 and di[0/1]_div_sel
clocks to the ldb nodes so that the ldb driver may use them to
setup the display clock trees.
Signed-off-by: Liu Ying
---
arch/arm/boot/dts/imx6dl.dtsi |8 ++--
arch/arm/boot/dts/imx6q.dtsi |8 ++--
2 files chang
The ldb_di[0/1]_ipu_div dividers may divide their parent clock
frequencies by either 3.5 or 7. The non-integral dividers cannot
be dealt with the common clock framework directly, so they cannot
be registered as common clock dividers. So this patch adds a fixed
factor clock of 1/7 and introduces ldb
The ldb_di[0/1]_ipu_div clock dividers in the CSCMR2 register
of i.MX53, i.MX6Q and i.MX6DL SoCs can be configured to a 1/3.5
drivider or a 1/7 divider. The common clock framework cannot
deal with the two dividers directly even with the divider table
which only supports integral dividers. So, the i
Hi Inki,
On Tuesday 20 of August 2013 14:45:10 Inki Dae wrote:
> This patch series fix pixel format setting according to
> drm_framebuffer's pixel_format, and check if a given window
> supports alpha channel or not.
>
> Inki Dae (2):
> drm/exynos: fix fimd pixel format setting
> drm/exynos: c
ing language version string: 1.30
--
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/20130820/8622e425/attachment.html>
https://bugs.freedesktop.org/show_bug.cgi?id=67994
--- Comment #11 from Timothée Ravier ---
Created attachment 84362
--> https://bugs.freedesktop.org/attachment.cgi?id=84362&action=edit
X server logs
Note: if I quickly kill the second mplayer right after the start of the video I
can avoid the
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130820/7579641f/attachment-0001.html>
Am 20.08.2013 15:21, schrieb Maarten Lankhorst:
> Op 20-08-13 11:51, Christian K?nig schreef:
>> Am 20.08.2013 11:36, schrieb Maarten Lankhorst:
>> [SNIP]
>>
>>> [SNIP]
>>> +/**
>>> + * radeon_fence_enable_signaling - enable signalling on fence
>>> + * @fence: fence
>>> + *
https://bugzilla.kernel.org/show_bug.cgi?id=60523
--- Comment #38 from Tobias Droste ---
I don't want to say that it's not a gcc bug, but I'm using gcc 4.7:
gcc version 4.7.2 20130108 [gcc-4_7-branch revision 195012] (SUSE Linux)
--
You are receiving this mail because:
You are watching the ass
Hi Rob,
On Tuesday 13 August 2013 20:52:15 Rob Clark wrote:
> On Fri, Aug 9, 2013 at 1:14 PM, Laurent Pinchart wrote:
> > MIPI DBI is a configurable-width parallel display bus that transmits
> > commands and data.
> >
> > Add a new DBI Linux bus type that implements the usual bus
> > infrastructu
On Tue, Aug 13, 2013 at 06:19:35PM +0900, Inki Dae wrote:
> This patch adds a buffer synchronization framework based on DMA BUF[1]
> and and based on ww-mutexes[2] for lock mechanism.
>
> The purpose of this framework is to provide not only buffer access control
> to CPU and DMA but also easy-to-u
Op 20-08-13 11:51, Christian K?nig schreef:
> Am 20.08.2013 11:36, schrieb Maarten Lankhorst:
> [SNIP]
>
>> [SNIP]
>> +/**
>> + * radeon_fence_enable_signaling - enable signalling on fence
>> + * @fence: fence
>> + *
>> + * This function is called with fence_queue lock held,
If the LCD table contains an EDID record, properly account
for the edid size when walking through the records.
This should fix error messages about unknown LCD records.
Signed-off-by: Alex Deucher
Cc: stable at vger.kernel.org
---
drivers/gpu/drm/radeon/radeon_atombios.c | 4 +++-
1 file change
From: Shobhit Kumar
Signed-off-by: Shobhit Kumar
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/drm_crtc.c |2 ++
include/uapi/drm/drm_mode.h |2 ++
2 files changed, 4 insertions(+)
diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
index a691764..dc279f4 100644
---
https://bugzilla.kernel.org/show_bug.cgi?id=60231
--- Comment #5 from prettyvani...@posteo.at ---
I am running a current mainline kernel until dpm stabilises, so I am on 3.11rc6
currently, which has the patch mentioned already applied. Sadly, no change in
behaviour.
I updated the dmesg output atta
https://bugzilla.kernel.org/show_bug.cgi?id=60231
--- Comment #4 from prettyvani...@posteo.at ---
Created attachment 107260
--> https://bugzilla.kernel.org/attachment.cgi?id=107260&action=edit
Xorg.0.log
--
You are receiving this mail because:
You are watching the assignee of the bug.
https://bugzilla.kernel.org/show_bug.cgi?id=60231
--- Comment #3 from prettyvani...@posteo.at ---
Created attachment 107259
--> https://bugzilla.kernel.org/attachment.cgi?id=107259&action=edit
xrandr --verbose
--
You are receiving this mail because:
You are watching the assignee of the bug.
__
https://bugzilla.kernel.org/show_bug.cgi?id=60231
prettyvani...@posteo.at changed:
What|Removed |Added
Attachment #106381|0 |1
is obsolete|
Ignore this patch for now. there are still problems with newer gcc
versions that aren't fixed yet.
Alex
On Tue, Aug 20, 2013 at 1:16 PM, Alex Deucher wrote:
> Newer versions of gcc seem to wander off into no-man's land
> when using variably sized arrays. Atombios tends to do things
> like:
>
>
This patch checks if a requested window supports alpha channel or not.
In case of s3c64xx, window 0 doesn't support alpha channel so if
the request pixel format is ARGB then change it to XRGB.
Signed-off-by: Inki Dae
Signed-off-by: Kyungmin Park
---
drivers/gpu/drm/exynos/exynos_drm_fi
This patch fixes wrong pixel format setting.
A pixel format is decided according to bpp and depth, or user-requested
format but fimd driver considered only bpp value to decide a proper pixel
format. So this patch makes a proper pixel format to be set according
to drm_framebuffer's pixel_format whi
This patch series fix pixel format setting according to
drm_framebuffer's pixel_format, and check if a given window
supports alpha channel or not.
Inki Dae (2):
drm/exynos: fix fimd pixel format setting
drm/exynos: check a pixel format to a particular window layer
drivers/gpu/drm/exynos/exyn
https://bugzilla.kernel.org/show_bug.cgi?id=60775
--- Comment #1 from Ryan Letourneau ---
Just tried solution here
http://ewaldertl.blogspot.ca/2013/02/update-fedora-18-to-kernel-376-let-fail.html
but did not resolve issue
--
You are receiving this mail because:
You are watching the assignee o
On Tue, Aug 20, 2013 at 11:24 AM, Laurent Pinchart
wrote:
> Hi Rob,
>
> On Tuesday 13 August 2013 20:43:50 Rob Clark wrote:
>> On Fri, Aug 9, 2013 at 1:14 PM, Laurent Pinchart wrote:
>> > Hi everybody,
>> >
>> > Here's the third RFC of the Common Display Framework.
>> >
>> > I won't repeat all the
https://bugzilla.kernel.org/show_bug.cgi?id=60523
--- Comment #37 from Alex Deucher ---
I was finally able to reproduce this, but only with gcc 4.8. Older versions of
gcc work fine. Looks like the gcc bug has struck again. See:
https://bugs.freedesktop.org/show_bug.cgi?id=66932
Now to find wha
https://bugzilla.kernel.org/show_bug.cgi?id=60523
--- Comment #42 from Alex Deucher ---
I can reproduce it in Fedora 17 as well (gcc 4.7). So it seems to be something
about Fedora 16 (gcc 4.6).
--
You are receiving this mail because:
You are watching the assignee of the bug.
__
On Tue, Aug 20, 2013 at 3:33 AM, Furquan Shaikh wrote:
> Enables getting correct mode clock when reading pipe config
> This patch has been tested successfully on top of drm-intel-nightly tree
>
> Signed-off-by: Furquan Shaikh
This is missing a hunk to enable the pipe_config consistency checks:
https://bugzilla.kernel.org/show_bug.cgi?id=60523
--- Comment #41 from Alex Deucher ---
Well, it helps a little, but I'm still able to reproduce it eventually even
with the patch. The same kernel source is working fine on a fedora 16 system
and now exhibits this problem on Fedora 19. So maybe i
https://bugzilla.kernel.org/show_bug.cgi?id=60523
--- Comment #40 from queryv...@gmail.com ---
(In reply to Alex Deucher from comment #39)
> Created attachment 107254 [details]
> fix for 3.11
>
> The attached patch seems to fix it for me.
That doesn't seem to fix it for me (6870). I first tried
Quoting Fabio Estevam (2013-08-20 08:40:52)
> On Tue, Aug 20, 2013 at 5:38 AM, Liu Ying wrote:
>
> > diff --git a/Documentation/devicetree/bindings/clock/imx6q-clock.txt
> > b/Documentation/devicetree/bindings/clock/imx6q-clock.txt
> > index 5a90a72..90e923e 100644
> > --- a/Documentation/device
https://bugzilla.kernel.org/show_bug.cgi?id=60775
Bug ID: 60775
Summary: Installing NVIDIA proprietary drivers on kernel
3.10.7-100.fc18.x86_64 errors out . . . can't find
kernel source files
Product: Drivers
Vers
Hi
2013/8/19 Furquan Shaikh :
> Enables getting correct mode clock when reading pipe config
> This patch has been tested successfully on top of drm-intel-nightly tree
>
> Signed-off-by: Furquan Shaikh
> ---
> drivers/gpu/drm/i915/i915_reg.h | 6
> drivers/gpu/drm/i915/intel_ddi.c
https://bugzilla.kernel.org/show_bug.cgi?id=60674
--- Comment #15 from Alex Deucher ---
(In reply to Dave from comment #14)
> (In reply to Michel D?nzer from comment #13)
>
> Michel you could well be 100% right.
While the symptoms may be similar, your issue is completely different, and not
kern
Newer versions of gcc seem to wander off into no-man's land
when using variably sized arrays. Atombios tends to do things
like:
struct object {
u8 version;
u8 num_elements;
u32 elements[1]; /* num_elements entries */
};
We then do things like the following in the driver code:
for (i
https://bugzilla.kernel.org/show_bug.cgi?id=60231
Alex Deucher changed:
What|Removed |Added
CC||alexdeucher at gmail.com
--- Comment #1 fr
Newer versions of gcc seem to wander off into no-man's land
when using variably sized arrays. Atombios tends to do things
like:
struct object {
u8 version;
u8 num_elements;
u32 elements[1]; /* num_elements entries */
};
We then do things like the following in the driver code:
for (i
On Tue, Aug 20, 2013 at 5:38 AM, Liu Ying wrote:
> diff --git a/Documentation/devicetree/bindings/clock/imx6q-clock.txt
> b/Documentation/devicetree/bindings/clock/imx6q-clock.txt
> index 5a90a72..90e923e 100644
> --- a/Documentation/devicetree/bindings/clock/imx6q-clock.txt
> +++ b/Documentatio
On Tue, Aug 13, 2013 at 06:19:35PM +0900, Inki Dae wrote:
> This patch adds a buffer synchronization framework based on DMA BUF[1]
> and and based on ww-mutexes[2] for lock mechanism.
>
> The purpose of this framework is to provide not only buffer access control
> to CPU and DMA but also easy-to-u
If the LCD table contains an EDID record, properly account
for the edid size when walking through the records.
This should fix error messages about unknown LCD records.
Signed-off-by: Alex Deucher
Cc: sta...@vger.kernel.org
---
drivers/gpu/drm/radeon/radeon_atombios.c | 4 +++-
1 file changed,
Am 20.08.2013 11:36, schrieb Maarten Lankhorst:
[SNIP]
> [SNIP]
> +/**
> + * radeon_fence_enable_signaling - enable signalling on fence
> + * @fence: fence
> + *
> + * This function is called with fence_queue lock held, and adds a
> callback
> + * to fence_queue th
Am Dienstag, den 20.08.2013, 16:38 +0800 schrieb Liu Ying:
> The ldb_di[0/1]_ipu_div clock dividers in the CSCMR2 register
> of i.MX53, i.MX6Q and i.MX6DL SoCs can be configured to a 1/3.5
> drivider or a 1/7 divider. The common clock framework cannot
> deal with the two dividers directly even with
Op 20-08-13 10:37, Christian K?nig schreef:
> Am 19.08.2013 21:37, schrieb Maarten Lankhorst:
>> Op 19-08-13 14:35, Christian K?nig schreef:
>>> Am 19.08.2013 12:17, schrieb Maarten Lankhorst:
[SNIP]
@@ -190,25 +225,24 @@ void radeon_fence_process(struct radeon_device
*rdev, int rin
https://bugs.freedesktop.org/show_bug.cgi?id=67994
Timothée Ravier changed:
What|Removed |Added
Attachment #84347|0 |1
is obsolete|
Am 19.08.2013 21:37, schrieb Maarten Lankhorst:
> Op 19-08-13 14:35, Christian K?nig schreef:
>> Am 19.08.2013 12:17, schrieb Maarten Lankhorst:
>>> [SNIP]
>>> @@ -190,25 +225,24 @@ void radeon_fence_process(struct radeon_device *rdev,
>>> int ring)
>>>}
>>>} while (atomic64_xc
Newer versions of gcc seem to wander off into no-man's land
when using variably sized arrays. Atombios tends to do things
like:
struct object {
u8 version;
u8 num_elements;
u32 elements[1]; /* num_elements entries */
};
We then do things like the following in the driver code:
for (i
On Mon, Aug 19, 2013 at 7:53 PM, Damien Lespiau
wrote:
> A small pass on drm headers to remove some stale prototypes/functions/defines
> and to make static a few functions.
For the series:
Reviewed-by: Alex Deucher
>
> drivers/gpu/drm/drm_crtc.c | 38
> +++---
Newer versions of gcc seem to wander off into no-man's land
when using variably sized arrays. Atombios tends to do things
like:
struct object {
u8 version;
u8 num_elements;
u32 elements[1]; /* num_elements entries */
};
We then do things like the following in the driver code:
for (i
https://bugs.freedesktop.org/show_bug.cgi?id=67994
--- Comment #9 from Alex Deucher ---
You might try this patch:
http://people.freedesktop.org/~agd5f/0001-drm-radeon-atombios-fix-variable-sized-arrays-for.patch
--
You are receiving this mail because:
You are the assignee for the bug.
_
https://bugzilla.kernel.org/show_bug.cgi?id=60523
--- Comment #39 from Alex Deucher ---
Created attachment 107254
--> https://bugzilla.kernel.org/attachment.cgi?id=107254&action=edit
fix for 3.11
The attached patch seems to fix it for me.
--
You are receiving this mail because:
You are watch
https://bugs.freedesktop.org/show_bug.cgi?id=67994
--- Comment #8 from Timothée Ravier ---
Look alike bug here: screen goes black and freeze for a while when playing the
second video using VDPAU with mplayer. Upon "screen return", the whole display
is corrupted and unusable, requiring reboot.
A
https://bugs.freedesktop.org/show_bug.cgi?id=67994
--- Comment #7 from Timothée Ravier ---
Created attachment 84347
--> https://bugs.freedesktop.org/attachment.cgi?id=84347&action=edit
dmesg log
--
You are receiving this mail because:
You are the assignee for the bug.
On Tue, Aug 20, 2013 at 07:56:42AM -0700, Ian Romanick wrote:
> On 08/19/2013 04:53 PM, Damien Lespiau wrote:
> >It's only used in drm_platform.c.
> >
> >Signed-off-by: Damien Lespiau
> >---
> > drivers/gpu/drm/drm_platform.c | 7 +++
> > include/drm/drmP.h | 3 ---
> > 2 files ch
https://bugzilla.kernel.org/show_bug.cgi?id=60523
--- Comment #38 from Tobias Droste ---
I don't want to say that it's not a gcc bug, but I'm using gcc 4.7:
gcc version 4.7.2 20130108 [gcc-4_7-branch revision 195012] (SUSE Linux)
--
You are receiving this mail because:
You are watching the ass
On Tue, Aug 20, 2013 at 5:38 AM, Liu Ying wrote:
> diff --git a/Documentation/devicetree/bindings/clock/imx6q-clock.txt
> b/Documentation/devicetree/bindings/clock/imx6q-clock.txt
> index 5a90a72..90e923e 100644
> --- a/Documentation/devicetree/bindings/clock/imx6q-clock.txt
> +++ b/Documentatio
On 08/19/2013 04:53 PM, Damien Lespiau wrote:
It's only used in drm_platform.c.
Signed-off-by: Damien Lespiau
---
drivers/gpu/drm/drm_platform.c | 7 +++
include/drm/drmP.h | 3 ---
2 files changed, 3 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/drm_platform.c
On 08/19/2013 04:53 PM, Damien Lespiau wrote:
> It's only used in drm_platform.c.
>
> Signed-off-by: Damien Lespiau
> ---
> drivers/gpu/drm/drm_platform.c | 7 +++
> include/drm/drmP.h | 3 ---
> 2 files changed, 3 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/gpu/drm/
https://bugzilla.kernel.org/show_bug.cgi?id=60523
--- Comment #37 from Alex Deucher ---
I was finally able to reproduce this, but only with gcc 4.8. Older versions of
gcc work fine. Looks like the gcc bug has struck again. See:
https://bugs.freedesktop.org/show_bug.cgi?id=66932
Now to find wha
Am 20.08.2013 15:21, schrieb Maarten Lankhorst:
Op 20-08-13 11:51, Christian König schreef:
Am 20.08.2013 11:36, schrieb Maarten Lankhorst:
[SNIP]
[SNIP]
+/**
+ * radeon_fence_enable_signaling - enable signalling on fence
+ * @fence: fence
+ *
+ * This function is called with fence_queue lock
Hi Dave,
New pile of stuff for -next:
- Cleanup of the old crtc helper callbacks, all encoders are now converted
to the i915 modeset infrastructure.
- Massive amount of wm patches from Ville for ilk, snb, ivb, hsw, this is
prep work to eventually get things going for nuclear pageflips where we
On Mon, Aug 19, 2013 at 7:53 PM, Damien Lespiau
wrote:
> A small pass on drm headers to remove some stale prototypes/functions/defines
> and to make static a few functions.
For the series:
Reviewed-by: Alex Deucher
>
> drivers/gpu/drm/drm_crtc.c | 38
> +++---
https://bugzilla.kernel.org/show_bug.cgi?id=60674
--- Comment #15 from Alex Deucher ---
(In reply to Dave from comment #14)
> (In reply to Michel Dänzer from comment #13)
>
> Michel you could well be 100% right.
While the symptoms may be similar, your issue is completely different, and not
kern
Op 20-08-13 11:51, Christian König schreef:
> Am 20.08.2013 11:36, schrieb Maarten Lankhorst:
> [SNIP]
>
>> [SNIP]
>> +/**
>> + * radeon_fence_enable_signaling - enable signalling on fence
>> + * @fence: fence
>> + *
>> + * This function is called with fence_queue lock held,
https://bugzilla.kernel.org/show_bug.cgi?id=60231
Alex Deucher changed:
What|Removed |Added
CC||alexdeuc...@gmail.com
--- Comment #1 from
On Tue, Aug 20, 2013 at 3:33 AM, Furquan Shaikh wrote:
> Enables getting correct mode clock when reading pipe config
> This patch has been tested successfully on top of drm-intel-nightly tree
>
> Signed-off-by: Furquan Shaikh
This is missing a hunk to enable the pipe_config consistency checks:
From: Shobhit Kumar
Signed-off-by: Shobhit Kumar
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/drm_crtc.c |2 ++
include/uapi/drm/drm_mode.h |2 ++
2 files changed, 4 insertions(+)
diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
index a691764..dc279f4 100644
---
On 08/20/2013 05:43 PM, Philipp Zabel wrote:
> Am Dienstag, den 20.08.2013, 16:38 +0800 schrieb Liu Ying:
>> The ldb_di[0/1]_ipu_div clock dividers in the CSCMR2 register
>> of i.MX53, i.MX6Q and i.MX6DL SoCs can be configured to a 1/3.5
>> drivider or a 1/7 divider. The common clock framework cann
Am 20.08.2013 11:36, schrieb Maarten Lankhorst:
[SNIP]
[SNIP]
+/**
+ * radeon_fence_enable_signaling - enable signalling on fence
+ * @fence: fence
+ *
+ * This function is called with fence_queue lock held, and adds a callback
+ * to fence_queue that checks if this fence is signaled, and if so
1 - 100 of 125 matches
Mail list logo
