remove cast for kzalloc return value.
Signed-off-by: Zhang Yanfei
Cc: Andrew Morton
Cc: David Airlie
Cc: dri-devel@lists.freedesktop.org
---
drivers/gpu/drm/i915/intel_sdvo.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_sdvo.c
b/drivers/
This replaces the open-coded divisions in the debugfs code by calls
to do_div().
Signed-off-by: Kees Cook
Cc: Daniel Vetter
---
drivers/gpu/drm/i915/i915_debugfs.c | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
b/drivers/g
On Mon, Mar 11, 2013 at 9:22 PM, Stephen Rothwell wrote:
> Hi all,
>
> After merging the final tree, today's linux-next build (i386 defconfig)
> failed like this:
>
> drivers/built-in.o: In function `i915_min_freq_set':
> i915_debugfs.c:(.text+0xb1adc): undefined reference to `__udivdi3'
> drivers
NAK! I removed this on purpose some time ago, the IB pool is in GART
memory, which essential is system memory.
So we don't need to unlock/unpin the IB pool on suspend.
Ontop of this it is quite dangerous to do so in a case of a GPU reset,
cause then there still might be IBs in the fly and if y
Am 11.03.2013 22:06, schrieb alexdeuc...@gmail.com:
From: Alex Deucher
We weren't properly tearing down the VM sub-alloctor
on suspend leading to bogus VM PTs on resume.
Fixes:
https://bugs.freedesktop.org/show_bug.cgi?id=60439
Tested-by: Dmitry Cherkasov
Signed-off-by: Alex Deucher
Cc: sta
On Mon, Mar 11, 2013 at 05:31:45PM -0700, Kees Cook wrote:
> It is possible to wrap the counter used to allocate the buffer for
> relocation copies. This could lead to heap writing overflows.
>
> CVE-2013-0913
>
> v3: collapse test, improve comment
> v2: move check into validate_exec_list
>
> Si
https://bugzilla.kernel.org/show_bug.cgi?id=54581
Alexander Mezin changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|
Signed-off-by: Jianpeng Ma
---
drivers/gpu/drm/drm_edid.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index c194f4e..05aa33a 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -1081,6 +1081,7 @@ drm_do_get_
On Tue, Mar 12, 2013 at 6:46 AM, Kees Cook wrote:
> On Mon, Mar 11, 2013 at 9:22 PM, Stephen Rothwell
> wrote:
>> Hi all,
>>
>> After merging the final tree, today's linux-next build (i386 defconfig)
>> failed like this:
>>
>> drivers/built-in.o: In function `i915_min_freq_set':
>> i915_debugfs.
This patch simplifies videomode related Kconfig and Makefile. After this
patch, there's only one non-user selectable Kconfig option left,
VIDEOMODE_HELPERS. The reasons for the change:
* Videomode helper functions are not something that should be shown in
the kernel configuration options. The re
Both videomode and display_timing contain flags describing the modes.
These are stored in dmt_flags and data_flags. There's no need to
separate these flags, and having separate fields just makes the flags
more difficult to use.
This patch combines the fields and renames VESA_DMT_* flags to
DISPLAY
Instead of having plain defines for the videomode's flags, add an enum
for the flags. This makes the flags clearer to use, as the enum tells
which values can be used with the flags field.
Signed-off-by: Tomi Valkeinen
Cc: Steffen Trumtrar
---
include/video/display_timing.h | 28 ++
Structs videomode and display_timing have rather long field names for
the timing values. Nothing wrong with that as such, but this patch
changes them to abbreviations for the following reasons:
* The timing values often need to be used in calculations, and long
field names makes their direct use
Display timing's fields have minimum, typical and maximum values. These
can be accessed by using timing_entry_index enum, and
display_timing_get_value() function.
There's no real need for this extra complexity. The values can be
accessed more easily by just using the min/typ/max fields.
Signed-of
On 2013-03-12 08:07, Archit Taneja wrote:
> On Monday 11 March 2013 05:58 PM, Tomi Valkeinen wrote:
>> On 2013-03-05 16:17, Archit Taneja wrote:
>>> The support outputs struct for overlay managers is incorrect for
>>> OMAP4. Make
>>> these changes:
>>>
>>> - DPI isn't supported via the LCD1 overlay
No.
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
https://bugs.freedesktop.org/show_bug.cgi?id=60439
--- Comment #15 from Harald Judt ---
Created attachment 76397
--> https://bugs.freedesktop.org/attachment.cgi?id=76397&action=edit
ogv video showing corruption (1.4MiB)
I confirm it fixes the problem, thanks for the patch.
However, it still d
https://bugs.freedesktop.org/show_bug.cgi?id=44772
--- Comment #9 from Harald Judt ---
Still reproducible with 3.8.0.
--
You are receiving this mail because:
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://bugs.freedesktop.org/show_bug.cgi?id=60439
--- Comment #16 from Alex Deucher ---
(In reply to comment #15)
> Further, corruption of the compiz splash screen is not fixed with this patch
> (as expected of course). It appears scrambled in some checkerboard fashion,
> see the attached ogv I
https://bugs.freedesktop.org/show_bug.cgi?id=62226
Priority: medium
Bug ID: 62226
Assignee: dri-devel@lists.freedesktop.org
Summary: Build Fails with LLVM
Severity: normal
Classification: Unclassified
OS: All
Report
https://bugs.freedesktop.org/show_bug.cgi?id=62226
--- Comment #1 from Serkan Hosca ---
llvm build config:
./configure \
--prefix=/usr \
--libdir=/usr/lib/llvm \
--sysconfdir=/etc \
--enable-shared \
--enable-libffi \
--enable-targets=all \
--enable-optimized \
-
On Tuesday 12 March 2013 04:08 PM, Tomi Valkeinen wrote:
On 2013-03-12 08:07, Archit Taneja wrote:
On Monday 11 March 2013 05:58 PM, Tomi Valkeinen wrote:
On 2013-03-05 16:17, Archit Taneja wrote:
The support outputs struct for overlay managers is incorrect for
OMAP4. Make
these changes:
- DP
The omapdrm driver requires omapdss panel drivers to expose ops like detect,
set_timings and check_timings. These can be NULL for fixed panel DPI, DBI, DSI
and SDI drivers. At some places, there are no checks to see if the panel driver
has these ops or not, and that leads to a crash.
The following
Hi Tomi,
Thanks for the patch.
On Tuesday 12 March 2013 12:19:34 Tomi Valkeinen wrote:
> This patch simplifies videomode related Kconfig and Makefile. After this
> patch, there's only one non-user selectable Kconfig option left,
> VIDEOMODE_HELPERS. The reasons for the change:
>
> * Videomode he
Hi Tomi,
Thanks for the patch.
On Tuesday 12 March 2013 12:19:38 Tomi Valkeinen wrote:
> Structs videomode and display_timing have rather long field names for
> the timing values. Nothing wrong with that as such, but this patch
> changes them to abbreviations for the following reasons:
>
> * The
On Tue, Mar 12, 2013 at 12:19:38PM +0200, Tomi Valkeinen wrote:
> Structs videomode and display_timing have rather long field names for
> the timing values. Nothing wrong with that as such, but this patch
> changes them to abbreviations for the following reasons:
>
> * The timing values often need
On Tuesday 12 March 2013 07:07 PM, Tomi Valkeinen wrote:
On 2013-03-12 14:57, Archit Taneja wrote:
We could also use the recommended channel way for omapdrm, I can't
figure out what's the better approach at the moment.
Hmm, I think it'd be safer to use the recommended channel from omapdss
for
On Tuesday 12 March 2013 07:36 PM, Tomi Valkeinen wrote:
On 2013-03-12 15:06, Archit Taneja wrote:
The omapdrm driver requires omapdss panel drivers to expose ops like detect,
set_timings and check_timings. These can be NULL for fixed panel DPI, DBI, DSI
and SDI drivers. At some places, there ar
On Tuesday 12 March 2013 07:59 PM, Tomi Valkeinen wrote:
On 2013-03-12 16:01, Archit Taneja wrote:
On Tuesday 12 March 2013 07:07 PM, Tomi Valkeinen wrote:
So, I don't disagree with you. But I don't quite understand why we could
not use the fixed channels for now? They should work in all the
https://bugs.freedesktop.org/show_bug.cgi?id=61182
--- Comment #7 from Eugene Shalygin ---
it is quite interesting to note that the crash happens only using 1920x1080 and
higher screen resolution. If the resolution is lower, kwin works fine.
--
You are receiving this mail because:
You are the a
https://bugs.freedesktop.org/show_bug.cgi?id=60439
--- Comment #17 from Alexandre Demers ---
(In reply to comment #16)
> (In reply to comment #15)
> > Further, corruption of the compiz splash screen is not fixed with this patch
> > (as expected of course). It appears scrambled in some checkerboar
https://bugs.freedesktop.org/show_bug.cgi?id=62239
Priority: medium
Bug ID: 62239
Assignee: dri-devel@lists.freedesktop.org
Summary: radeon drm oops with benchmark=1 on Radeon 7950
Severity: minor
Classification: Unclassified
Let's add some more people to CC.
On Tue, Mar 12, 2013 at 05:02:49PM +0100, felix-linuxker...@fefe.de wrote:
> The radeon driver does not work on my laptop.
> I sent a bug report here a week ago, but got no responses.
> What is the right place to send bug reports for the radeon driver?
>
> The bu
https://bugs.freedesktop.org/show_bug.cgi?id=62244
Priority: medium
Bug ID: 62244
Assignee: dri-devel@lists.freedesktop.org
Summary: SIGFPE with cogl GL client in wayland
Severity: normal
Classification: Unclassified
OS: All
https://bugs.freedesktop.org/show_bug.cgi?id=62244
Bastien Nocera changed:
What|Removed |Added
Version|unspecified |9.0
--
You are receiving this mail bec
On Tue, Mar 12, 2013 at 12:06 PM, Borislav Petkov wrote:
> Let's add some more people to CC.
>
> On Tue, Mar 12, 2013 at 05:02:49PM +0100, felix-linuxker...@fefe.de wrote:
>> The radeon driver does not work on my laptop.
>> I sent a bug report here a week ago, but got no responses.
>> What is the
https://bugs.freedesktop.org/show_bug.cgi?id=62244
Michel Dänzer changed:
What|Removed |Added
Component|Drivers/DRI/R600|Drivers/Gallium/r600
--
You are receivi
https://bugs.freedesktop.org/show_bug.cgi?id=62246
Priority: medium
Bug ID: 62246
Assignee: dri-devel@lists.freedesktop.org
Summary: LVDS screen mode switching fails
Severity: major
Classification: Unclassified
OS: Linux (All
https://bugs.freedesktop.org/show_bug.cgi?id=62246
--- Comment #1 from Alex Deucher ---
Please make sure your kernel has this patch:
http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=43a23aa450cc19fe8996caf09e7e21ae5f6e56e8
--
You are receiving this mail because:
You are
https://bugs.freedesktop.org/show_bug.cgi?id=62246
--- Comment #2 from Alex Deucher ---
Sounds like vgaswitcheroo is not switching the displays from the intel to the
radeon chip.
--
You are receiving this mail because:
You are the assignee for the bug.
__
https://bugs.freedesktop.org/show_bug.cgi?id=62246
--- Comment #3 from Felix von Leitner ---
The patch is on both kernels I tried, 3.9.0-rc1 and the git kernel.
I agree it sounds like vgaswitcheroo does not actually switch.
Are there any knobs for vgaswitcheroo that I could try?
For switching,
On 2013-03-12 15:06, Archit Taneja wrote:
> The omapdrm driver requires omapdss panel drivers to expose ops like detect,
> set_timings and check_timings. These can be NULL for fixed panel DPI, DBI, DSI
> and SDI drivers. At some places, there are no checks to see if the panel
> driver
> has these
On 2013-03-12 14:57, Archit Taneja wrote:
>>> We could also use the recommended channel way for omapdrm, I can't
>>> figure out what's the better approach at the moment.
>>
>> Hmm, I think it'd be safer to use the recommended channel from omapdss
>> for now. The current omapdss code doesn't really
Hi,
On 2013-03-12 15:37, Laurent Pinchart wrote:
> Hi Tomi,
>
> Thanks for the patch.
>
> On Tuesday 12 March 2013 12:19:38 Tomi Valkeinen wrote:
>> Structs videomode and display_timing have rather long field names for
>> the timing values. Nothing wrong with that as such, but this patch
>> chan
On 2013-03-12 16:01, Archit Taneja wrote:
> On Tuesday 12 March 2013 07:07 PM, Tomi Valkeinen wrote:
>> So, I don't disagree with you. But I don't quite understand why we could
>> not use the fixed channels for now? They should work in all the boards
>> we have, right? Or is there something with D
Property blob objects need to be destroyed when cleaning up to avoid
memory leaks. Go through the list of all blobs in the
drm_mode_config_cleanup() function and destroy them.
The drm_mode_config_cleanup() function needs to be moved after the
drm_property_destroy_blob() declaration. Move drm_mode_
The page flip handler stores the page flip event pointer and then calls
drm_vblank_get() to enable the vblank interrupt. Due to the vblank off
delay, the vblank interrupt can be enabled in the hardware at that
point, even if the vblank reference count is equal to 0. If a vblank
interrupt is trigger
Hello,
This two patches add support for GEM CMA objects import and export as dma-buf
file handles.
There's not much to be added about the patches themselves, they're pretty
self-explicit. The code is based on the Exynos DRM DMA-BUF implementation.
The exporter role has been successfully tested w
This allows creating a GEM CMA object without an associated DMA memory
buffer, and will be used to implement DRM PRIME support.
Signed-off-by: Laurent Pinchart
---
drivers/gpu/drm/drm_gem_cma_helper.c | 83 +---
1 file changed, 48 insertions(+), 35 deletions(-)
d
Signed-off-by: Laurent Pinchart
---
drivers/gpu/drm/drm_gem_cma_helper.c | 311 ++-
include/drm/drm_gem_cma_helper.h | 9 +
2 files changed, 317 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/drm_gem_cma_helper.c
b/drivers/gpu/drm/drm_gem_cma_he
On 2013-03-12 16:38, Archit Taneja wrote:
>> memcmp on two structs is often not a good idea. There could be padding
>> bytes there, with uninitialized data. I'm not sure if that's the case
>> here, though, but it could well change any time (perhaps even depending
>> on compiler version).
>
> I sa
https://bugs.freedesktop.org/show_bug.cgi?id=62239
--- Comment #1 from Alex Deucher ---
Created attachment 76410
--> https://bugs.freedesktop.org/attachment.cgi?id=76410&action=edit
possible fix
This patch should fix the issue.
--
You are receiving this mail because:
You are the assignee for
https://bugs.freedesktop.org/show_bug.cgi?id=62239
--- Comment #2 from Michal Babej ---
Built 3.8.2 with the patch, verified its working. Thanks!
--
You are receiving this mail because:
You are the assignee for the bug.
___
dri-devel mailing list
dri-
If ddx does not support swap, don't advertise it. We might also be
able to get rid of the vmwgfx check (I'm not quite sure the purpose of
that check vs. just checking dri2Minor.
Signed-off-by: Rob Clark
---
src/glx/dri2_glx.c | 12
1 file changed, 8 insertions(+), 4 deletions(-)
d
On 11/03/2013 13:38, Konrad Rzeszutek Wilk wrote:
>> With that I am still getting the issues (even with an insance delay of 100
>> seconds).
>> Here is the serial log with various runs.
> Any thoughts?
Sorry for taking so long to answer but I got a one-week flu and still
had to do my research dut
On Sun, Mar 10, 2013 at 02:10:06PM -0700, Kees Cook wrote:
> This replaces the manual read/write routines in debugfs with the common
> simple attribute helpers. Doing this gets rid of repeated copy/pasting
> of copy_from_user and value formatting code.
>
> Signed-off-by: Kees Cook
> Cc: Daniel Ve
On Mon, Mar 11, 2013 at 02:37:35PM -0700, Kees Cook wrote:
> This clarifies the comment above the access_ok check so a missing
> VERIFY_READ doesn't alarm anyone.
>
> Signed-off-by: Kees Cook
> Cc: Daniel Vetter
> ---
> v2:
> - rewrote comment, thanks to Chris Wilson
Queued for -next, thanks f
On Mon, Mar 11, 2013 at 12:25:19PM -0700, Kees Cook wrote:
> Masks kernel address info-leak in object dumps with the %pK suffix,
> so they cannot be used to target kernel memory corruption attacks if
> the kptr_restrict sysctl is set.
>
> Signed-off-by: Kees Cook
> Cc: stable at vger.kernel.org
P
Good point.
Acked-by: Seung-Woo Kim
On 2013? 03? 12? 04:25, Alexandru Gheorghiu wrote:
> Replaced calls to kzalloc followed by memcpy with call to kmemdup.
> Patch found using coccinelle.
>
> Signed-off-by: Alexandru Gheorghiu
> ---
> drivers/gpu/drm/exynos/exynos_drm_vidi.c |6 ++
>
Applied.
Thanks,
Inki Dae
2013/3/12 Alexandru Gheorghiu :
> Replaced calls to kzalloc followed by memcpy with call to kmemdup.
> Patch found using coccinelle.
>
> Signed-off-by: Alexandru Gheorghiu
> ---
> drivers/gpu/drm/exynos/exynos_drm_vidi.c |6 ++
> 1 file changed, 2 insertions(+)
uug.org.au
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130312/3efb2f3c/attachment.pgp>
Hey guys,
I've been writing dynamic power management code for the secondary
GPUs, however a lot of these GPUs have audio codecs as a subfunction
PCI device.
So we get 01:00.0 as the GPU and 01:00.1 as the HDMI audio device.
Now we have a single power switch for these devices, and generally the
p
On Monday 11 March 2013 05:58 PM, Tomi Valkeinen wrote:
> On 2013-03-05 16:17, Archit Taneja wrote:
>> The support outputs struct for overlay managers is incorrect for OMAP4. Make
>> these changes:
>>
>> - DPI isn't supported via the LCD1 overlay manager, remove DPI as a supported
>>output.
>>
Hi Linus,
this is just nouveau fixes from Ben, one fixes a nasty oops that some
Fedora people have been seeing, so I'd like to get it out of the way.
Dave.
The following changes since commit f6161aa153581da4a3867a2d1a7caf4be19b6ec9:
Linux 3.9-rc2 (2013-03-10 16:54:19 -0700)
are available i
At Tue, 12 Mar 2013 16:05:26 +1000,
Dave Airlie wrote:
>
> Hey guys,
>
> I've been writing dynamic power management code for the secondary
> GPUs, however a lot of these GPUs have audio codecs as a subfunction
> PCI device.
>
> So we get 01:00.0 as the GPU and 01:00.1 as the HDMI audio device.
>
next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130312/734cdc86/attachment.pgp>
? 2013?03?11? 22:02, Rob Clark ??:
> On Sun, Mar 10, 2013 at 12:04 AM, Chen Gang wrote:
>> >
>> > When make with EXTRA_CFLAGS=-W, it will report error.
>> > so give a check in Makefile.
>> >
>> > Signed-off-by: Chen Gang
>> > Signed-off-by: Vladimir Kondratiev
> Signed-off-by: Rob Clark
>
remove cast for kzalloc return value.
Signed-off-by: Zhang Yanfei
Cc: Andrew Morton
Cc: David Airlie
Cc: dri-devel at lists.freedesktop.org
---
drivers/gpu/drm/i915/intel_sdvo.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_sdvo.c
b/drive
NAK! I removed this on purpose some time ago, the IB pool is in GART
memory, which essential is system memory.
So we don't need to unlock/unpin the IB pool on suspend.
Ontop of this it is quite dangerous to do so in a case of a GPU reset,
cause then there still might be IBs in the fly and if yo
Am 11.03.2013 22:06, schrieb alexdeucher at gmail.com:
> From: Alex Deucher
>
> We weren't properly tearing down the VM sub-alloctor
> on suspend leading to bogus VM PTs on resume.
>
> Fixes:
> https://bugs.freedesktop.org/show_bug.cgi?id=60439
>
> Tested-by: Dmitry Cherkasov
> Signed-off-by: Ale
On Mon, Mar 11, 2013 at 05:31:45PM -0700, Kees Cook wrote:
> It is possible to wrap the counter used to allocate the buffer for
> relocation copies. This could lead to heap writing overflows.
>
> CVE-2013-0913
>
> v3: collapse test, improve comment
> v2: move check into validate_exec_list
>
> Si
https://bugzilla.kernel.org/show_bug.cgi?id=54581
Alexander Mezin changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|
On Mon, Mar 4, 2013 at 7:35 PM, Rahul Sharma wrote:
> Thanks Sean,
>
> On Wed, Feb 27, 2013 at 9:47 PM, Sean Paul wrote:
>> On Wed, Feb 27, 2013 at 8:22 AM, Rahul Sharma
>> wrote:
>>> Right now hdmiphy operations and configs are kept inside hdmi driver.
>>> hdmiphy related
>>> code is tightly
Signed-off-by: Jianpeng Ma
---
drivers/gpu/drm/drm_edid.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index c194f4e..05aa33a 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -1081,6 +1081,7 @@ drm_do_get_
On Tue, Mar 12, 2013 at 6:46 AM, Kees Cook wrote:
> On Mon, Mar 11, 2013 at 9:22 PM, Stephen Rothwell
> wrote:
>> Hi all,
>>
>> After merging the final tree, today's linux-next build (i386 defconfig)
>> failed like this:
>>
>> drivers/built-in.o: In function `i915_min_freq_set':
>> i915_debugfs.
This patch simplifies videomode related Kconfig and Makefile. After this
patch, there's only one non-user selectable Kconfig option left,
VIDEOMODE_HELPERS. The reasons for the change:
* Videomode helper functions are not something that should be shown in
the kernel configuration options. The re
Both videomode and display_timing contain flags describing the modes.
These are stored in dmt_flags and data_flags. There's no need to
separate these flags, and having separate fields just makes the flags
more difficult to use.
This patch combines the fields and renames VESA_DMT_* flags to
DISPLAY
Instead of having plain defines for the videomode's flags, add an enum
for the flags. This makes the flags clearer to use, as the enum tells
which values can be used with the flags field.
Signed-off-by: Tomi Valkeinen
Cc: Steffen Trumtrar
---
include/video/display_timing.h | 28 ++
Structs videomode and display_timing have rather long field names for
the timing values. Nothing wrong with that as such, but this patch
changes them to abbreviations for the following reasons:
* The timing values often need to be used in calculations, and long
field names makes their direct use
Display timing's fields have minimum, typical and maximum values. These
can be accessed by using timing_entry_index enum, and
display_timing_get_value() function.
There's no real need for this extra complexity. The values can be
accessed more easily by just using the min/typ/max fields.
Signed-of
fer to use the recommended channel from omapdss
for now. The current omapdss code doesn't really let you use any other
channel than the recommended one (which was thus renamed to
dispc_channel in my later version).
Or does your patch do a better job at selecting the outputs (I'm mostly
thinking about OMAP5 here, which has a bit more conflicts with the mgrs
and outputs than earlier omaps).
But at some point I think we should fix those issues, and let omapdrm
decide how to connect the managers and outputs.
Tomi
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 899 bytes
Desc: OpenPGP digital signature
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130312/8008b142/attachment.pgp>
No.
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
2013/3/12 Rahul Sharma :
> On Mon, Mar 4, 2013 at 7:35 PM, Rahul Sharma wrote:
>> Thanks Sean,
>>
>> On Wed, Feb 27, 2013 at 9:47 PM, Sean Paul wrote:
>>> On Wed, Feb 27, 2013 at 8:22 AM, Rahul Sharma
>>> wrote:
Right now hdmiphy operations and configs are kept inside hdmi driver.
hd
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130312/328dbc22/attachment.html>
ttp://lists.freedesktop.org/archives/dri-devel/attachments/20130312/707aa9f9/attachment.html>
nee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130312/121198b4/attachment.html>
ppens in make install
--
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/20130312/52bafd1d/attachment.html>
ttp://lists.freedesktop.org/archives/dri-devel/attachments/20130312/038af384/attachment.html>
On Tuesday 12 March 2013 04:08 PM, Tomi Valkeinen wrote:
> On 2013-03-12 08:07, Archit Taneja wrote:
>> On Monday 11 March 2013 05:58 PM, Tomi Valkeinen wrote:
>>> On 2013-03-05 16:17, Archit Taneja wrote:
The support outputs struct for overlay managers is incorrect for
OMAP4. Make
t
The omapdrm driver requires omapdss panel drivers to expose ops like detect,
set_timings and check_timings. These can be NULL for fixed panel DPI, DBI, DSI
and SDI drivers. At some places, there are no checks to see if the panel driver
has these ops or not, and that leads to a crash.
The following
Hi Tomi,
Thanks for the patch.
On Tuesday 12 March 2013 12:19:34 Tomi Valkeinen wrote:
> This patch simplifies videomode related Kconfig and Makefile. After this
> patch, there's only one non-user selectable Kconfig option left,
> VIDEOMODE_HELPERS. The reasons for the change:
>
> * Videomode he
Hi Tomi,
Thanks for the patch.
On Tuesday 12 March 2013 12:19:38 Tomi Valkeinen wrote:
> Structs videomode and display_timing have rather long field names for
> the timing values. Nothing wrong with that as such, but this patch
> changes them to abbreviations for the following reasons:
>
> * The
On Tue, Mar 12, 2013 at 12:19:38PM +0200, Tomi Valkeinen wrote:
> Structs videomode and display_timing have rather long field names for
> the timing values. Nothing wrong with that as such, but this patch
> changes them to abbreviations for the following reasons:
>
> * The timing values often need
On Tuesday 12 March 2013 07:07 PM, Tomi Valkeinen wrote:
> On 2013-03-12 14:57, Archit Taneja wrote:
>
We could also use the recommended channel way for omapdrm, I can't
figure out what's the better approach at the moment.
>>>
>>> Hmm, I think it'd be safer to use the recommended channel
On Tuesday 12 March 2013 07:36 PM, Tomi Valkeinen wrote:
> On 2013-03-12 15:06, Archit Taneja wrote:
>> The omapdrm driver requires omapdss panel drivers to expose ops like detect,
>> set_timings and check_timings. These can be NULL for fixed panel DPI, DBI,
>> DSI
>> and SDI drivers. At some plac
On Tuesday 12 March 2013 07:59 PM, Tomi Valkeinen wrote:
> On 2013-03-12 16:01, Archit Taneja wrote:
>> On Tuesday 12 March 2013 07:07 PM, Tomi Valkeinen wrote:
>
>>> So, I don't disagree with you. But I don't quite understand why we could
>>> not use the fixed channels for now? They should work in
assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130312/fce540fb/attachment.html>
ubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130312/2b8386c9/attachment.html>
ttach+0x1e/0x20
Mar 12 15:51:01 yennork kernel: [2.699230] []
bus_add_driver+0x1a0/0x290
--
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-deve
Let's add some more people to CC.
On Tue, Mar 12, 2013 at 05:02:49PM +0100, felix-linuxkernel at fefe.de wrote:
> The radeon driver does not work on my laptop.
> I sent a bug report here a week ago, but got no responses.
> What is the right place to send bug reports for the radeon driver?
>
> The
1 - 100 of 121 matches
Mail list logo
