Re: [PATCH 1/5] dma-buf: remove fallback for !CONFIG_DMA_SHARED_BUFFER
On 10/01/2012 11:47 AM, Maarten Lankhorst wrote: Op 28-09-12 21:42, Thomas Hellstrom schreef: On 09/28/2012 04:14 PM, Maarten Lankhorst wrote: Hey, Op 28-09-12 14:41, Maarten Lankhorst schreef: Documentation says that code requiring dma-buf should add it to select, so inline fallbacks are not going to be used. A link error will make it obvious what went wrong, instead of silently doing nothing at runtime. The whole patch series is in my tree, I use stg so things might move around, do not use for merging currently: http://cgit.freedesktop.org/~mlankhorst/linux/log/?h=v10-wip It contains everything in here plus the patches for ttm to make it work, I use a old snapshot of drm-next + merge of nouveau as base. Description of what the parts do: Series to fix small api issues when moving over: drm/ttm: Remove cpu_writers related code drm/ttm: Add ttm_bo_is_reserved function drm/radeon: Use ttm_bo_is_reserved drm/vmwgfx: use ttm_bo_is_reserved drm/vmwgfx: remove use of fence_obj_args drm/ttm: remove sync_obj_arg drm/ttm: remove sync_obj_arg from ttm_bo_move_accel_cleanup drm/ttm: remove sync_arg entirely drm/nouveau: unpin buffers before releasing to prevent lockdep warnings drm/nouveau: add reservation to nouveau_bo_vma_del drm/nouveau: add reservation to nouveau_gem_ioctl_cpu_prep Hey great, now we only have one user left for fence waiting before reserving, lets fix that and remove fence lock: ttm_bo_cleanup_refs_or_queue and ttm_bo_cleanup_refs have to reserve before waiting, lets do it in the squash commit so we don't have to throw lock order around everywhere: drm/ttm: remove fence_lock -- Up to this point should be mergeable now Then we start working on lru_lock removal slightly, this means the lru list no longer is empty but can contain only reserved buffers: drm/ttm: do not check if list is empty in ttm_bo_force_list_clean drm/ttm: move reservations for ttm_bo_cleanup_refs -- Still mergeable up to this point, just fixes Patch series from this email: dma-buf: remove fallback for !CONFIG_DMA_SHARED_BUFFER fence: dma-buf cross-device synchronization (v9) seqno-fence: Hardware dma-buf implementation of fencing (v3) reservation: cross-device reservation support reservation: Add lockdep annotation and selftests Now hook it up to drm/ttm in a few steps: usage around reservations: drm/ttm: make ttm reservation calls behave like reservation calls drm/ttm: use dma_reservation api dma-buf: use reservations drm/ttm: allow drivers to pass custom dma_reservation_objects for a bo then kill off the lru lock around reservation: drm/ttm: remove lru_lock around ttm_bo_reserve drm/ttm: simplify ttm_eu_* The lru_lock removal patch removes the lock around lru_lock around the reservation, this will break the assumption that items on the lru list and swap list can always be reserved, and this gets patched up too. Is there any part in ttm you disagree with? I believe that this is all mergeable, the lru_lock removal patch could be moved to before the reservation parts, this might make merging easier, but I don't think there is any ttm part of the series that are wrong on a conceptual level. ~Maarten From another email As previously discussed, I'm unfortunately not prepared to accept removal of the reserve-lru atomicity into the TTM code at this point. The current code is based on this assumption and removing it will end up with efficiencies, breaking the delayed delete code and probably a locking nightmare when trying to write new TTM code. The lru lock removal patch fixed the delayed delete code, it really is not different from the current situation. In fact it is more clear without the guarantee what various parts are trying to protect. Nothing prevents you from holding the lru_lock while trylocking, [1] While this would not cause any deadlocks, Any decent lockdep code would establish lru->reserve as the locking order once a lru- reserve trylock succeeds, but the locking order is really reserve->lru for obvious reasons, which means we will get a lot of lockdep errors? Yes, there are a two reversals like these already in the TTM code, and I'm not very proud of them. I was doing a evil hack where I 'released' lru_lock to lockdep before doing the annotation for a blocking acquire, and left trylock annotations as they were. This made lockdep do the right thing. I've never looked into how lockdep works. Is this something that can be done permanently or just for testing purposes? Although not related to this, is it possible to do something similar to the trylock reversal in the fault() code where mmap_sem() and reserve() change order using a reserve trylock? And this is even before it starts to get interesting, like how you guarantee that when you release a buffer from the delayed delete list, you're the only process having a reference? l thought list_kref made sure of that? Even if not the only one with a reference, the list_empty check would make sure it would only run on
Re: [PATCH 1/2] of: add helper to parse display specs
On 10/1/2012 10:25 AM, Stephen Warren wrote:
> On 10/01/2012 01:16 PM, Mitch Bradley wrote:
>> On 10/1/2012 6:53 AM, Stephen Warren wrote:
>>> On 09/24/2012 09:35 AM, Steffen Trumtrar wrote:
Parse a display-node with timings and hardware-specs from devictree.
>>>
diff --git a/Documentation/devicetree/bindings/video/display
b/Documentation/devicetree/bindings/video/display
new file mode 100644
index 000..722766a
--- /dev/null
+++ b/Documentation/devicetree/bindings/video/display
>>>
>>> This should be display.txt.
>>>
@@ -0,0 +1,208 @@
+display bindings
+==
+
+display-node
+
>>>
>>> I'm not personally convinced about the direction this is going. While I
>>> think it's reasonable to define DT bindings for displays, and DT
>>> bindings for display modes, I'm not sure that it's reasonable to couple
>>> them together into a single binding.
>>>
>>> I think creating a well-defined timing binding first will be much
>>> simpler than doing so within the context of a display binding; the
>>> scope/content of a general display binding seems much less well-defined
>>> to me at least, for reasons I mentioned before.
>>>
+required properties:
+ - none
+
+optional properties:
+ - default-timing: the default timing value
+ - width-mm, height-mm: Display dimensions in mm
>>>
+ - hsync-active-high (bool): Hsync pulse is active high
+ - vsync-active-high (bool): Vsync pulse is active high
>>>
>>> At least those two properties should exist in the display timing instead
>>> (or perhaps as well). There are certainly cases where different similar
>>> display modes are differentiated by hsync/vsync polarity more than
>>> anything else. This is probably more likely with analog display
>>> connectors than digital, but I see no reason why a DT binding for
>>> display timing shouldn't cover both.
>>>
+ - de-active-high (bool): Data-Enable pulse is active high
+ - pixelclk-inverted (bool): pixelclock is inverted
>>>
+ - pixel-per-clk
>>>
>>> pixel-per-clk is probably something that should either be part of the
>>> timing definition, or something computed internally to the display
>>> driver based on rules for the signal type, rather than something
>>> represented in DT.
>>>
>>> The above comment assumes this property is intended to represent DVI's
>>> requirement for pixel clock doubling for low-pixel-clock-rate modes. If
>>> it's something to do with e.g. a single-data-rate vs. double-data-rate
>>> property of the underlying physical connection, that's most likely
>>> something that should be defined in a binding specific to e.g. LVDS,
>>> rather than something generic.
>>>
+ - link-width: number of channels (e.g. LVDS)
+ - bpp: bits-per-pixel
+
+timings-subnode
+---
+
+required properties:
+subnodes that specify
+ - hactive, vactive: Display resolution
+ - hfront-porch, hback-porch, hsync-len: Horizontal Display timing
parameters
+ in pixels
+ vfront-porch, vback-porch, vsync-len: Vertical display timing
parameters in
+ lines
+ - clock: displayclock in Hz
+
+There are different ways of describing a display and its capabilities.
The devicetree
+representation corresponds to the one commonly found in datasheets for
displays.
+The description of the display and its timing is split in two parts:
first the display
+properties like size in mm and (optionally) multiple subnodes with the
supported timings.
+If a display supports multiple signal timings, the default-timing can be
specified.
+
+Example:
+
+ display@0 {
+ width-mm = <800>;
+ height-mm = <480>;
+ default-timing = <&timing0>;
+ timings {
+ timing0: timing@0 {
>>>
>>> If you're going to use a unit address ("@0") to ensure that node names
>>> are unique (which is not mandatory), then each node also needs a reg
>>> property with matching value, and #address-cells/#size-cells in the
>>> parent. Instead, you could name the nodes something unique based on the
>>> mode name to avoid this, e.g. 1080p24 { ... }.
>>
>>
>> I'm concerned that numbered nodes are being misused as arrays.
>>
>> It's easy to make real arrays by including multiple cells in the value
>> of each timing parameter, and easy to choose a cell by saying the array
>> index instead of using the phandle.
>
> In this case though, arrays don't work out so well in my opinion:
>
> We want to describe a set of unrelated display modes that the display
> can handle. These are logically separate entities. I don't think
> combining the values that represent say 5 different modes into a single
> set of properties really makes sense here; a separate node or property
> per display mode really does make sense because they're sepa
Re: [PATCH 1/2] of: add helper to parse display specs
On 10/1/2012 6:53 AM, Stephen Warren wrote:
> On 09/24/2012 09:35 AM, Steffen Trumtrar wrote:
>> Parse a display-node with timings and hardware-specs from devictree.
>
>> diff --git a/Documentation/devicetree/bindings/video/display
>> b/Documentation/devicetree/bindings/video/display
>> new file mode 100644
>> index 000..722766a
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/video/display
>
> This should be display.txt.
>
>> @@ -0,0 +1,208 @@
>> +display bindings
>> +==
>> +
>> +display-node
>> +
>
> I'm not personally convinced about the direction this is going. While I
> think it's reasonable to define DT bindings for displays, and DT
> bindings for display modes, I'm not sure that it's reasonable to couple
> them together into a single binding.
>
> I think creating a well-defined timing binding first will be much
> simpler than doing so within the context of a display binding; the
> scope/content of a general display binding seems much less well-defined
> to me at least, for reasons I mentioned before.
>
>> +required properties:
>> + - none
>> +
>> +optional properties:
>> + - default-timing: the default timing value
>> + - width-mm, height-mm: Display dimensions in mm
>
>> + - hsync-active-high (bool): Hsync pulse is active high
>> + - vsync-active-high (bool): Vsync pulse is active high
>
> At least those two properties should exist in the display timing instead
> (or perhaps as well). There are certainly cases where different similar
> display modes are differentiated by hsync/vsync polarity more than
> anything else. This is probably more likely with analog display
> connectors than digital, but I see no reason why a DT binding for
> display timing shouldn't cover both.
>
>> + - de-active-high (bool): Data-Enable pulse is active high
>> + - pixelclk-inverted (bool): pixelclock is inverted
>
>> + - pixel-per-clk
>
> pixel-per-clk is probably something that should either be part of the
> timing definition, or something computed internally to the display
> driver based on rules for the signal type, rather than something
> represented in DT.
>
> The above comment assumes this property is intended to represent DVI's
> requirement for pixel clock doubling for low-pixel-clock-rate modes. If
> it's something to do with e.g. a single-data-rate vs. double-data-rate
> property of the underlying physical connection, that's most likely
> something that should be defined in a binding specific to e.g. LVDS,
> rather than something generic.
>
>> + - link-width: number of channels (e.g. LVDS)
>> + - bpp: bits-per-pixel
>> +
>> +timings-subnode
>> +---
>> +
>> +required properties:
>> +subnodes that specify
>> + - hactive, vactive: Display resolution
>> + - hfront-porch, hback-porch, hsync-len: Horizontal Display timing
>> parameters
>> + in pixels
>> + vfront-porch, vback-porch, vsync-len: Vertical display timing parameters
>> in
>> + lines
>> + - clock: displayclock in Hz
>> +
>> +There are different ways of describing a display and its capabilities. The
>> devicetree
>> +representation corresponds to the one commonly found in datasheets for
>> displays.
>> +The description of the display and its timing is split in two parts: first
>> the display
>> +properties like size in mm and (optionally) multiple subnodes with the
>> supported timings.
>> +If a display supports multiple signal timings, the default-timing can be
>> specified.
>> +
>> +Example:
>> +
>> +display@0 {
>> +width-mm = <800>;
>> +height-mm = <480>;
>> +default-timing = <&timing0>;
>> +timings {
>> +timing0: timing@0 {
>
> If you're going to use a unit address ("@0") to ensure that node names
> are unique (which is not mandatory), then each node also needs a reg
> property with matching value, and #address-cells/#size-cells in the
> parent. Instead, you could name the nodes something unique based on the
> mode name to avoid this, e.g. 1080p24 { ... }.
I'm concerned that numbered nodes are being misused as arrays.
It's easy to make real arrays by including multiple cells in the value
of each timing parameter, and easy to choose a cell by saying the array
index instead of using the phandle.
>
> ___
> devicetree-discuss mailing list
> devicetree-disc...@lists.ozlabs.org
> https://lists.ozlabs.org/listinfo/devicetree-discuss
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/2] of: add helper to parse display specs
On 10/01/2012 01:16 PM, Mitch Bradley wrote:
> On 10/1/2012 6:53 AM, Stephen Warren wrote:
>> On 09/24/2012 09:35 AM, Steffen Trumtrar wrote:
>>> Parse a display-node with timings and hardware-specs from devictree.
>>
>>> diff --git a/Documentation/devicetree/bindings/video/display
>>> b/Documentation/devicetree/bindings/video/display
>>> new file mode 100644
>>> index 000..722766a
>>> --- /dev/null
>>> +++ b/Documentation/devicetree/bindings/video/display
>>
>> This should be display.txt.
>>
>>> @@ -0,0 +1,208 @@
>>> +display bindings
>>> +==
>>> +
>>> +display-node
>>> +
>>
>> I'm not personally convinced about the direction this is going. While I
>> think it's reasonable to define DT bindings for displays, and DT
>> bindings for display modes, I'm not sure that it's reasonable to couple
>> them together into a single binding.
>>
>> I think creating a well-defined timing binding first will be much
>> simpler than doing so within the context of a display binding; the
>> scope/content of a general display binding seems much less well-defined
>> to me at least, for reasons I mentioned before.
>>
>>> +required properties:
>>> + - none
>>> +
>>> +optional properties:
>>> + - default-timing: the default timing value
>>> + - width-mm, height-mm: Display dimensions in mm
>>
>>> + - hsync-active-high (bool): Hsync pulse is active high
>>> + - vsync-active-high (bool): Vsync pulse is active high
>>
>> At least those two properties should exist in the display timing instead
>> (or perhaps as well). There are certainly cases where different similar
>> display modes are differentiated by hsync/vsync polarity more than
>> anything else. This is probably more likely with analog display
>> connectors than digital, but I see no reason why a DT binding for
>> display timing shouldn't cover both.
>>
>>> + - de-active-high (bool): Data-Enable pulse is active high
>>> + - pixelclk-inverted (bool): pixelclock is inverted
>>
>>> + - pixel-per-clk
>>
>> pixel-per-clk is probably something that should either be part of the
>> timing definition, or something computed internally to the display
>> driver based on rules for the signal type, rather than something
>> represented in DT.
>>
>> The above comment assumes this property is intended to represent DVI's
>> requirement for pixel clock doubling for low-pixel-clock-rate modes. If
>> it's something to do with e.g. a single-data-rate vs. double-data-rate
>> property of the underlying physical connection, that's most likely
>> something that should be defined in a binding specific to e.g. LVDS,
>> rather than something generic.
>>
>>> + - link-width: number of channels (e.g. LVDS)
>>> + - bpp: bits-per-pixel
>>> +
>>> +timings-subnode
>>> +---
>>> +
>>> +required properties:
>>> +subnodes that specify
>>> + - hactive, vactive: Display resolution
>>> + - hfront-porch, hback-porch, hsync-len: Horizontal Display timing
>>> parameters
>>> + in pixels
>>> + vfront-porch, vback-porch, vsync-len: Vertical display timing
>>> parameters in
>>> + lines
>>> + - clock: displayclock in Hz
>>> +
>>> +There are different ways of describing a display and its capabilities. The
>>> devicetree
>>> +representation corresponds to the one commonly found in datasheets for
>>> displays.
>>> +The description of the display and its timing is split in two parts: first
>>> the display
>>> +properties like size in mm and (optionally) multiple subnodes with the
>>> supported timings.
>>> +If a display supports multiple signal timings, the default-timing can be
>>> specified.
>>> +
>>> +Example:
>>> +
>>> + display@0 {
>>> + width-mm = <800>;
>>> + height-mm = <480>;
>>> + default-timing = <&timing0>;
>>> + timings {
>>> + timing0: timing@0 {
>>
>> If you're going to use a unit address ("@0") to ensure that node names
>> are unique (which is not mandatory), then each node also needs a reg
>> property with matching value, and #address-cells/#size-cells in the
>> parent. Instead, you could name the nodes something unique based on the
>> mode name to avoid this, e.g. 1080p24 { ... }.
>
>
> I'm concerned that numbered nodes are being misused as arrays.
>
> It's easy to make real arrays by including multiple cells in the value
> of each timing parameter, and easy to choose a cell by saying the array
> index instead of using the phandle.
In this case though, arrays don't work out so well in my opinion:
We want to describe a set of unrelated display modes that the display
can handle. These are logically separate entities. I don't think
combining the values that represent say 5 different modes into a single
set of properties really makes sense here; a separate node or property
per display mode really does make sense because they're separate objects.
Related, each display timing parameter (e.g. hsync length, position,
...) has a range, so min/typical/max values. These are already
represented as a 3-c
[Bug 49981] On HD6850, Power Profile doesn't change if 2 screen is attached.
https://bugs.freedesktop.org/show_bug.cgi?id=49981 --- Comment #13 from Alex Deucher --- I pushed a patch to handle this properly to my drm-next-3.7-wip branch: http://cgit.freedesktop.org/~agd5f/linux/log/?h=drm-next-3.7-wip -- 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/20121001/cc15669f/attachment-0001.html>
[Bug 49981] On HD6850, Power Profile doesn't change if 2 screen is attached.
https://bugs.freedesktop.org/show_bug.cgi?id=49981 --- Comment #12 from graham --- Created attachment 67953 --> https://bugs.freedesktop.org/attachment.cgi?id=67953&action=edit proposed patch Had a look round on google for some other profiles. Not entirely sure about cayman, as the idle is higher than on less powerful cards. -- 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/20121001/e78db8ce/attachment.html>
[Bug 55510] Incorrect rendering with unigine tropics
https://bugs.freedesktop.org/show_bug.cgi?id=55510 --- Comment #3 from Alex Deucher --- Make sure you install libtxc_dxtn and you may need to build mesa with the --enable-texture-float configure option. -- 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/20121001/f0949823/attachment.html>
[Bug 55510] Incorrect rendering with unigine tropics
https://bugs.freedesktop.org/show_bug.cgi?id=55510 maxijac at free.fr changed: What|Removed |Added Attachment #67943|0 |1 is obsolete|| --- Comment #2 from maxijac at free.fr --- Created attachment 67944 --> https://bugs.freedesktop.org/attachment.cgi?id=67944&action=edit rendering reattaching because it failed -- 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/20121001/10dba441/attachment.html>
[Bug 55510] Incorrect rendering with unigine tropics
https://bugs.freedesktop.org/show_bug.cgi?id=55510 --- Comment #1 from maxijac at free.fr --- Created attachment 67943 --> https://bugs.freedesktop.org/attachment.cgi?id=67943&action=edit screenshot bad rendering -- 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/20121001/b30fcca8/attachment.html>
[Bug 55510] New: Incorrect rendering with unigine tropics
https://bugs.freedesktop.org/show_bug.cgi?id=55510 Priority: medium Bug ID: 55510 Assignee: dri-devel at lists.freedesktop.org Summary: Incorrect rendering with unigine tropics Severity: normal Classification: Unclassified OS: All Reporter: maxijac at free.fr Hardware: All Status: NEW Version: unspecified Component: Drivers/Gallium/r600 Product: Mesa Created attachment 67942 --> https://bugs.freedesktop.org/attachment.cgi?id=67942&action=edit output of tropics Tropics has bad rendering, screenshot and output will be posted. using mesa git 8d9778589f4b3a174e884338adb0fe1bdeca5eb7 and ddx e8cb0b721e6ea251f85c799ca0563bfa59a2d37c linux 3.5. -- 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/20121001/b8691e59/attachment.html>
Re: [PATCH 00/14] drm: exynos: hdmi: add dt based support for exynos5 hdmi
To Mr. Shim, Can you check these patch series? Thank you, Kyungmin Park On 9/28/12, Rahul Sharma wrote: > This patch set adds the DT based support for Samsung's Exynos5250 in > DRM-HDMI. > It includes disabling of hdmi internal interrupt, suppport for platform > variants for hdmi and mixer, support to disable video processor based on > platform type and removal of drm common platform data. > > Rahul Sharma (9): > drm: exynos: remove drm hdmi platform data struct > drm: exynos: hdmi: add support for exynos5 ddc > drm: exynos: hdmi: add support for exynos5 hdmiphy > drm: exynos: hdmi: add support for platform variants for mixer > drm: exynos: hdmi: add support to disable video processor in mixer > drm: exynos: hdmi: add support for exynos5 mixer > drm: exynos: hdmi: replace is_v13 with version check in hdmi > drm: exynos: hdmi: add support for exynos5 hdmi > drm: exynos: hdmi: remove drm common hdmi platform data struct > > Tomasz Stanislawski (5): > media: s5p-hdmi: add HPD GPIO to platform data > drm: exynos: hdmi: support for platform variants > drm: exynos: hdmi: fix interrupt handling > drm: exynos: hdmi: use s5p-hdmi platform data > drm: exynos: hdmi: turn off HPD interrupt in HDMI chip > > drivers/gpu/drm/exynos/exynos_ddc.c | 22 +++- > drivers/gpu/drm/exynos/exynos_drm_hdmi.c | 51 > drivers/gpu/drm/exynos/exynos_drm_hdmi.h |2 + > drivers/gpu/drm/exynos/exynos_hdmi.c | 196 > --- > drivers/gpu/drm/exynos/exynos_hdmiphy.c | 12 ++- > drivers/gpu/drm/exynos/exynos_mixer.c| 219 > ++ > drivers/gpu/drm/exynos/regs-mixer.h |2 + > include/drm/exynos_drm.h | 27 > include/media/s5p_hdmi.h |2 + > 9 files changed, 369 insertions(+), 164 deletions(-) > > ___ > dri-devel mailing list > dri-devel@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/dri-devel > ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 55448] [ColorTiling2D] R600 BARTS radeon: The kernel rejected CS and graphical corruption with tropics
https://bugs.freedesktop.org/show_bug.cgi?id=55448 maxijac at free.fr changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |NOTABUG --- Comment #4 from maxijac at free.fr --- You were right... sorry about that, I did not realize tropics was x86. Now it works, with massive rendering glitches though. I'll report them if I don't find open bug reports. Thanks. -- 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/20121001/2ccd742e/attachment.html>
[Bug 49981] On HD6850, Power Profile doesn't change if 2 screen is attached.
https://bugs.freedesktop.org/show_bug.cgi?id=49981 --- Comment #11 from graham --- Created attachment 67937 --> https://bugs.freedesktop.org/attachment.cgi?id=67937&action=edit patch for barts and caicos mobility Tested on barts, not caicos. It's restricted to only the power state profiles that I have data on so far, and falls back to the r600 profile for everything else. The mobility profile assumes the laptop will be plugged in when in multi-monitor mode, and so it puts it in performance mode for mid and high. I want to sort out dynpm too, but dynpm seems to be a huge WIP at the moment, as it just disables it completely if there is more than one monitor. With a single monitor, NI is the same as r600, so it can use the same dynpm. -- 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/20121001/e4edbf3e/attachment.html>
[Bug 43405] Only horizontal lines (snow) display in google earth/glxgears using current r600g on RS780M
https://bugs.freedesktop.org/show_bug.cgi?id=43405 --- Comment #16 from idunham at lavabit.com --- On Mon, 01 Oct 2012 09:58:49 + bugzilla-daemon at freedesktop.org wrote: > --- Comment #15 from Paul Menzel --- > I do not see this with Debian Sid/unstable (Mesa 8.0.4) and HD 3200 (RS780). > > 01:05.0 VGA compatible controller: Advanced Micro Devices [AMD] nee ATI > RS780 [Radeon HD 3200] > > At least `glxgears` works fine. Any special prerequisites to run this with? At present, I'm suspecting that it's something to do with the Squeeze X stack (I'm using Squeeze with the stock Xorg, and I've updated only the minimum to satisfy configure). -- 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/20121001/a597ef7b/attachment-0001.html>
[Bug 49981] On HD6850, Power Profile doesn't change if 2 screen is attached.
https://bugs.freedesktop.org/show_bug.cgi?id=49981 --- Comment #13 from Alex Deucher --- I pushed a patch to handle this properly to my drm-next-3.7-wip branch: http://cgit.freedesktop.org/~agd5f/linux/log/?h=drm-next-3.7-wip -- You are receiving this mail because: You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 55416] [R600g] Torchlight gives GPU lockup
https://bugs.freedesktop.org/show_bug.cgi?id=55416 --- Comment #8 from Laurent carlier --- Created attachment 67933 --> https://bugs.freedesktop.org/attachment.cgi?id=67933&action=edit dumped shader with R600_DUMP_SHADERS=1 /usr/local/games/Torchlight/Torchlight.bin.x86_64 -- 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/20121001/70de1ef5/attachment.html>
[Bug 49981] On HD6850, Power Profile doesn't change if 2 screen is attached.
https://bugs.freedesktop.org/show_bug.cgi?id=49981 --- Comment #12 from graham --- Created attachment 67953 --> https://bugs.freedesktop.org/attachment.cgi?id=67953&action=edit proposed patch Had a look round on google for some other profiles. Not entirely sure about cayman, as the idle is higher than on less powerful cards. -- You are receiving this mail because: You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 1/2] of: add helper to parse display specs
On 10/01/2012 01:16 PM, Mitch Bradley wrote:
> On 10/1/2012 6:53 AM, Stephen Warren wrote:
>> On 09/24/2012 09:35 AM, Steffen Trumtrar wrote:
>>> Parse a display-node with timings and hardware-specs from devictree.
>>
>>> diff --git a/Documentation/devicetree/bindings/video/display
>>> b/Documentation/devicetree/bindings/video/display
>>> new file mode 100644
>>> index 000..722766a
>>> --- /dev/null
>>> +++ b/Documentation/devicetree/bindings/video/display
>>
>> This should be display.txt.
>>
>>> @@ -0,0 +1,208 @@
>>> +display bindings
>>> +==
>>> +
>>> +display-node
>>> +
>>
>> I'm not personally convinced about the direction this is going. While I
>> think it's reasonable to define DT bindings for displays, and DT
>> bindings for display modes, I'm not sure that it's reasonable to couple
>> them together into a single binding.
>>
>> I think creating a well-defined timing binding first will be much
>> simpler than doing so within the context of a display binding; the
>> scope/content of a general display binding seems much less well-defined
>> to me at least, for reasons I mentioned before.
>>
>>> +required properties:
>>> + - none
>>> +
>>> +optional properties:
>>> + - default-timing: the default timing value
>>> + - width-mm, height-mm: Display dimensions in mm
>>
>>> + - hsync-active-high (bool): Hsync pulse is active high
>>> + - vsync-active-high (bool): Vsync pulse is active high
>>
>> At least those two properties should exist in the display timing instead
>> (or perhaps as well). There are certainly cases where different similar
>> display modes are differentiated by hsync/vsync polarity more than
>> anything else. This is probably more likely with analog display
>> connectors than digital, but I see no reason why a DT binding for
>> display timing shouldn't cover both.
>>
>>> + - de-active-high (bool): Data-Enable pulse is active high
>>> + - pixelclk-inverted (bool): pixelclock is inverted
>>
>>> + - pixel-per-clk
>>
>> pixel-per-clk is probably something that should either be part of the
>> timing definition, or something computed internally to the display
>> driver based on rules for the signal type, rather than something
>> represented in DT.
>>
>> The above comment assumes this property is intended to represent DVI's
>> requirement for pixel clock doubling for low-pixel-clock-rate modes. If
>> it's something to do with e.g. a single-data-rate vs. double-data-rate
>> property of the underlying physical connection, that's most likely
>> something that should be defined in a binding specific to e.g. LVDS,
>> rather than something generic.
>>
>>> + - link-width: number of channels (e.g. LVDS)
>>> + - bpp: bits-per-pixel
>>> +
>>> +timings-subnode
>>> +---
>>> +
>>> +required properties:
>>> +subnodes that specify
>>> + - hactive, vactive: Display resolution
>>> + - hfront-porch, hback-porch, hsync-len: Horizontal Display timing
>>> parameters
>>> + in pixels
>>> + vfront-porch, vback-porch, vsync-len: Vertical display timing
>>> parameters in
>>> + lines
>>> + - clock: displayclock in Hz
>>> +
>>> +There are different ways of describing a display and its capabilities. The
>>> devicetree
>>> +representation corresponds to the one commonly found in datasheets for
>>> displays.
>>> +The description of the display and its timing is split in two parts: first
>>> the display
>>> +properties like size in mm and (optionally) multiple subnodes with the
>>> supported timings.
>>> +If a display supports multiple signal timings, the default-timing can be
>>> specified.
>>> +
>>> +Example:
>>> +
>>> + display at 0 {
>>> + width-mm = <800>;
>>> + height-mm = <480>;
>>> + default-timing = <&timing0>;
>>> + timings {
>>> + timing0: timing at 0 {
>>
>> If you're going to use a unit address ("@0") to ensure that node names
>> are unique (which is not mandatory), then each node also needs a reg
>> property with matching value, and #address-cells/#size-cells in the
>> parent. Instead, you could name the nodes something unique based on the
>> mode name to avoid this, e.g. 1080p24 { ... }.
>
>
> I'm concerned that numbered nodes are being misused as arrays.
>
> It's easy to make real arrays by including multiple cells in the value
> of each timing parameter, and easy to choose a cell by saying the array
> index instead of using the phandle.
In this case though, arrays don't work out so well in my opinion:
We want to describe a set of unrelated display modes that the display
can handle. These are logically separate entities. I don't think
combining the values that represent say 5 different modes into a single
set of properties really makes sense here; a separate node or property
per display mode really does make sense because they're separate objects.
Related, each display timing parameter (e.g. hsync length, position,
...) has a range, so min/typical/max values. These are already
represented as
[Bug 55445] Torchlight: crash due to texture error
https://bugs.freedesktop.org/show_bug.cgi?id=55445 Michel D?nzer changed: What|Removed |Added Assignee|dri-devel at lists.freedesktop |mesa-dev at lists.freedesktop. |.org|org Component|Drivers/Gallium/r600|Mesa core -- 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/20121001/44066b62/attachment.html>
[Bug 55510] Incorrect rendering with unigine tropics
https://bugs.freedesktop.org/show_bug.cgi?id=55510 --- Comment #3 from Alex Deucher --- Make sure you install libtxc_dxtn and you may need to build mesa with the --enable-texture-float configure option. -- You are receiving this mail because: You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 50149] Faulty shaders on RS600
https://bugs.freedesktop.org/show_bug.cgi?id=50149 --- Comment #23 from Roman ?makal --- Created attachment 67926 --> https://bugs.freedesktop.org/attachment.cgi?id=67926&action=edit Frets on Fire font bug Just noticed that frets on fire are bugged too. Not sure if its related to faulty shaders though. -- 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/20121001/094f439b/attachment.html>
[Bug 55510] Incorrect rendering with unigine tropics
https://bugs.freedesktop.org/show_bug.cgi?id=55510 maxi...@free.fr changed: What|Removed |Added Attachment #67943|0 |1 is obsolete|| --- Comment #2 from maxi...@free.fr --- Created attachment 67944 --> https://bugs.freedesktop.org/attachment.cgi?id=67944&action=edit rendering reattaching because it failed -- You are receiving this mail because: You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 55510] Incorrect rendering with unigine tropics
https://bugs.freedesktop.org/show_bug.cgi?id=55510 --- Comment #1 from maxi...@free.fr --- Created attachment 67943 --> https://bugs.freedesktop.org/attachment.cgi?id=67943&action=edit screenshot bad rendering -- You are receiving this mail because: You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 55510] New: Incorrect rendering with unigine tropics
https://bugs.freedesktop.org/show_bug.cgi?id=55510 Priority: medium Bug ID: 55510 Assignee: dri-devel@lists.freedesktop.org Summary: Incorrect rendering with unigine tropics Severity: normal Classification: Unclassified OS: All Reporter: maxi...@free.fr Hardware: All Status: NEW Version: unspecified Component: Drivers/Gallium/r600 Product: Mesa Created attachment 67942 --> https://bugs.freedesktop.org/attachment.cgi?id=67942&action=edit output of tropics Tropics has bad rendering, screenshot and output will be posted. using mesa git 8d9778589f4b3a174e884338adb0fe1bdeca5eb7 and ddx e8cb0b721e6ea251f85c799ca0563bfa59a2d37c linux 3.5. -- You are receiving this mail because: You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 55448] [ColorTiling2D] R600 BARTS radeon: The kernel rejected CS and graphical corruption with tropics
https://bugs.freedesktop.org/show_bug.cgi?id=55448 --- Comment #3 from Alex Deucher --- Are you running a 32-bit app on a 64-bit distro by any chance? If so, you may be using an old version of the 32-bit 3D driver. You'll need to build and install an updated version of the 32-bit 3D driver as well. -- 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/20121001/30ad8231/attachment.html>
[Bug 55448] [ColorTiling2D] R600 BARTS radeon: The kernel rejected CS and graphical corruption with tropics
https://bugs.freedesktop.org/show_bug.cgi?id=55448 maxi...@free.fr changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |NOTABUG --- Comment #4 from maxi...@free.fr --- You were right... sorry about that, I did not realize tropics was x86. Now it works, with massive rendering glitches though. I'll report them if I don't find open bug reports. Thanks. -- You are receiving this mail because: You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 1/5] dma-buf: remove fallback for !CONFIG_DMA_SHARED_BUFFER
Op 28-09-12 21:42, Thomas Hellstrom schreef: > On 09/28/2012 04:14 PM, Maarten Lankhorst wrote: >> Hey, >> >> Op 28-09-12 14:41, Maarten Lankhorst schreef: >>> Documentation says that code requiring dma-buf should add it to >>> select, so inline fallbacks are not going to be used. A link error >>> will make it obvious what went wrong, instead of silently doing >>> nothing at runtime. >>> >> >> >> The whole patch series is in my tree, I use stg so things might >> move around, do not use for merging currently: >> >> http://cgit.freedesktop.org/~mlankhorst/linux/log/?h=v10-wip >> >> It contains everything in here plus the patches for ttm to make >> it work, I use a old snapshot of drm-next + merge of nouveau as >> base. Description of what the parts do: >> >> Series to fix small api issues when moving over: >> >> drm/ttm: Remove cpu_writers related code >> drm/ttm: Add ttm_bo_is_reserved function >> drm/radeon: Use ttm_bo_is_reserved >> drm/vmwgfx: use ttm_bo_is_reserved >> >> drm/vmwgfx: remove use of fence_obj_args >> drm/ttm: remove sync_obj_arg >> drm/ttm: remove sync_obj_arg from ttm_bo_move_accel_cleanup >> drm/ttm: remove sync_arg entirely >> >> drm/nouveau: unpin buffers before releasing to prevent lockdep warnings >> drm/nouveau: add reservation to nouveau_bo_vma_del >> drm/nouveau: add reservation to nouveau_gem_ioctl_cpu_prep >> >> Hey great, now we only have one user left for fence waiting before reserving, >> lets fix that and remove fence lock: >> ttm_bo_cleanup_refs_or_queue and ttm_bo_cleanup_refs have to reserve before >> waiting, lets do it in the squash commit so we don't have to throw lock order >> around everywhere: >> >> drm/ttm: remove fence_lock >> >> -- Up to this point should be mergeable now >> >> Then we start working on lru_lock removal slightly, this means the lru >> list no longer is empty but can contain only reserved buffers: >> >> drm/ttm: do not check if list is empty in ttm_bo_force_list_clean >> drm/ttm: move reservations for ttm_bo_cleanup_refs >> >> -- Still mergeable up to this point, just fixes >> >> Patch series from this email: >> dma-buf: remove fallback for !CONFIG_DMA_SHARED_BUFFER >> fence: dma-buf cross-device synchronization (v9) >> seqno-fence: Hardware dma-buf implementation of fencing (v3) >> reservation: cross-device reservation support >> reservation: Add lockdep annotation and selftests >> >> Now hook it up to drm/ttm in a few steps: >> usage around reservations: >> drm/ttm: make ttm reservation calls behave like reservation calls >> drm/ttm: use dma_reservation api >> dma-buf: use reservations >> drm/ttm: allow drivers to pass custom dma_reservation_objects for a bo >> >> then kill off the lru lock around reservation: >> drm/ttm: remove lru_lock around ttm_bo_reserve >> drm/ttm: simplify ttm_eu_* >> >> The lru_lock removal patch removes the lock around lru_lock around the >> reservation, this will break the assumption that items on the lru list >> and swap list can always be reserved, and this gets patched up too. >> Is there any part in ttm you disagree with? I believe that this >> is all mergeable, the lru_lock removal patch could be moved to before >> the reservation parts, this might make merging easier, but I don't >> think there is any ttm part of the series that are wrong on a conceptual >> level. >> >> ~Maarten >> > From another email > >>> As previously discussed, I'm unfortunately not prepared to accept removal >>> of the reserve-lru atomicity >>> into the TTM code at this point. >>> The current code is based on this assumption and removing it will end up >>> with >>> efficiencies, breaking the delayed delete code and probably a locking >>> nightmare when trying to write >>> new TTM code. >> The lru lock removal patch fixed the delayed delete code, it really is not >> different from the current >> situation. In fact it is more clear without the guarantee what various parts >> are trying to protect. >> >> Nothing prevents you from holding the lru_lock while trylocking, > [1] > While this would not cause any deadlocks, Any decent lockdep code would > establish lru->reserve as the locking > order once a lru- reserve trylock succeeds, but the locking order is really > reserve->lru for obvious reasons, which > means we will get a lot of lockdep errors? Yes, there are a two reversals > like these already in the TTM code, and I'm > not very proud of them. I was doing a evil hack where I 'released' lru_lock to lockdep before doing the annotation for a blocking acquire, and left trylock annotations as they were. This made lockdep do the right thing. > And this is even before it starts to get interesting, like how you guarantee > that when you release a buffer from > the delayed delete list, you're the only process having a reference? l thought list_kref made sure of that? Even if not the only one with a reference, the list_empty check would make sure it would only run once. I'l fix it up again so it doesn't become a WARN_ON_ONCE, I
[PATCH 1/2] of: add helper to parse display specs
On 10/1/2012 10:25 AM, Stephen Warren wrote:
> On 10/01/2012 01:16 PM, Mitch Bradley wrote:
>> On 10/1/2012 6:53 AM, Stephen Warren wrote:
>>> On 09/24/2012 09:35 AM, Steffen Trumtrar wrote:
Parse a display-node with timings and hardware-specs from devictree.
>>>
diff --git a/Documentation/devicetree/bindings/video/display
b/Documentation/devicetree/bindings/video/display
new file mode 100644
index 000..722766a
--- /dev/null
+++ b/Documentation/devicetree/bindings/video/display
>>>
>>> This should be display.txt.
>>>
@@ -0,0 +1,208 @@
+display bindings
+==
+
+display-node
+
>>>
>>> I'm not personally convinced about the direction this is going. While I
>>> think it's reasonable to define DT bindings for displays, and DT
>>> bindings for display modes, I'm not sure that it's reasonable to couple
>>> them together into a single binding.
>>>
>>> I think creating a well-defined timing binding first will be much
>>> simpler than doing so within the context of a display binding; the
>>> scope/content of a general display binding seems much less well-defined
>>> to me at least, for reasons I mentioned before.
>>>
+required properties:
+ - none
+
+optional properties:
+ - default-timing: the default timing value
+ - width-mm, height-mm: Display dimensions in mm
>>>
+ - hsync-active-high (bool): Hsync pulse is active high
+ - vsync-active-high (bool): Vsync pulse is active high
>>>
>>> At least those two properties should exist in the display timing instead
>>> (or perhaps as well). There are certainly cases where different similar
>>> display modes are differentiated by hsync/vsync polarity more than
>>> anything else. This is probably more likely with analog display
>>> connectors than digital, but I see no reason why a DT binding for
>>> display timing shouldn't cover both.
>>>
+ - de-active-high (bool): Data-Enable pulse is active high
+ - pixelclk-inverted (bool): pixelclock is inverted
>>>
+ - pixel-per-clk
>>>
>>> pixel-per-clk is probably something that should either be part of the
>>> timing definition, or something computed internally to the display
>>> driver based on rules for the signal type, rather than something
>>> represented in DT.
>>>
>>> The above comment assumes this property is intended to represent DVI's
>>> requirement for pixel clock doubling for low-pixel-clock-rate modes. If
>>> it's something to do with e.g. a single-data-rate vs. double-data-rate
>>> property of the underlying physical connection, that's most likely
>>> something that should be defined in a binding specific to e.g. LVDS,
>>> rather than something generic.
>>>
+ - link-width: number of channels (e.g. LVDS)
+ - bpp: bits-per-pixel
+
+timings-subnode
+---
+
+required properties:
+subnodes that specify
+ - hactive, vactive: Display resolution
+ - hfront-porch, hback-porch, hsync-len: Horizontal Display timing
parameters
+ in pixels
+ vfront-porch, vback-porch, vsync-len: Vertical display timing
parameters in
+ lines
+ - clock: displayclock in Hz
+
+There are different ways of describing a display and its capabilities.
The devicetree
+representation corresponds to the one commonly found in datasheets for
displays.
+The description of the display and its timing is split in two parts:
first the display
+properties like size in mm and (optionally) multiple subnodes with the
supported timings.
+If a display supports multiple signal timings, the default-timing can be
specified.
+
+Example:
+
+ display at 0 {
+ width-mm = <800>;
+ height-mm = <480>;
+ default-timing = <&timing0>;
+ timings {
+ timing0: timing at 0 {
>>>
>>> If you're going to use a unit address ("@0") to ensure that node names
>>> are unique (which is not mandatory), then each node also needs a reg
>>> property with matching value, and #address-cells/#size-cells in the
>>> parent. Instead, you could name the nodes something unique based on the
>>> mode name to avoid this, e.g. 1080p24 { ... }.
>>
>>
>> I'm concerned that numbered nodes are being misused as arrays.
>>
>> It's easy to make real arrays by including multiple cells in the value
>> of each timing parameter, and easy to choose a cell by saying the array
>> index instead of using the phandle.
>
> In this case though, arrays don't work out so well in my opinion:
>
> We want to describe a set of unrelated display modes that the display
> can handle. These are logically separate entities. I don't think
> combining the values that represent say 5 different modes into a single
> set of properties really makes sense here; a separate node or property
> per display mode really does make sense because they'r
[PATCH V6 2/2] video: drm: exynos: Add device tree support
Hello Stephen Warren, The binding names that I use in my dts file should match with the names given in http://lists.freedesktop.org/archives/dri-devel/2012-July/024875.html right? I think that is the only thing I have to take care, and as I'm not using "struct drm_display_mode" in my driver its my wish whether to use the helper function or not. Please clarify me if I miss something. Best Regards, Leela Krishna Amudala. On Fri, Sep 21, 2012 at 10:44 AM, Stephen Warren wrote: > On 09/21/2012 05:22 AM, Leela Krishna Amudala wrote: >> This patch adds device tree based discovery support for exynos DRM-FIMD >> driver which includes driver modification to handle platform data in >> both the cases with DT and non-DT, Also adds the documentation for bindings. > >> diff --git a/Documentation/devicetree/bindings/drm/exynos/fimd.txt >> b/Documentation/devicetree/bindings/drm/exynos/fimd.txt > ... >> + - samsung,fimd-display: This property should specify the phandle of the >> + display device node which holds the video interface timing with the >> + below mentioned properties. >> + >> + - lcd-htiming: Specifies the horizontal timing for the overlay. The >> + horizontal timing includes four parameters in the following order. >> + >> + - horizontal back porch (in number of lcd clocks) >> + - horizontal front porch (in number of lcd clocks) >> + - hsync pulse width (in number of lcd clocks) >> + - Display panels X resolution. >> + >> + - lcd-vtiming: Specifies the vertical timing for the overlay. The >> + vertical timing includes four parameters in the following order. >> + >> + - vertical back porch (in number of lcd lines) >> + - vertical front porch (in number of lcd lines) >> + - vsync pulse width (in number of lcd clocks) >> + - Display panels Y resolution. > > Should this not use the new videomode timings that are under discussion at: > > http://lists.freedesktop.org/archives/dri-devel/2012-July/024875.html > -- > To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" > in > the body of a message to majordomo at vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/2] of: add helper to parse display specs
On 09/24/2012 09:35 AM, Steffen Trumtrar wrote:
> Parse a display-node with timings and hardware-specs from devictree.
> diff --git a/Documentation/devicetree/bindings/video/display
> b/Documentation/devicetree/bindings/video/display
> new file mode 100644
> index 000..722766a
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/video/display
This should be display.txt.
> @@ -0,0 +1,208 @@
> +display bindings
> +==
> +
> +display-node
> +
I'm not personally convinced about the direction this is going. While I
think it's reasonable to define DT bindings for displays, and DT
bindings for display modes, I'm not sure that it's reasonable to couple
them together into a single binding.
I think creating a well-defined timing binding first will be much
simpler than doing so within the context of a display binding; the
scope/content of a general display binding seems much less well-defined
to me at least, for reasons I mentioned before.
> +required properties:
> + - none
> +
> +optional properties:
> + - default-timing: the default timing value
> + - width-mm, height-mm: Display dimensions in mm
> + - hsync-active-high (bool): Hsync pulse is active high
> + - vsync-active-high (bool): Vsync pulse is active high
At least those two properties should exist in the display timing instead
(or perhaps as well). There are certainly cases where different similar
display modes are differentiated by hsync/vsync polarity more than
anything else. This is probably more likely with analog display
connectors than digital, but I see no reason why a DT binding for
display timing shouldn't cover both.
> + - de-active-high (bool): Data-Enable pulse is active high
> + - pixelclk-inverted (bool): pixelclock is inverted
> + - pixel-per-clk
pixel-per-clk is probably something that should either be part of the
timing definition, or something computed internally to the display
driver based on rules for the signal type, rather than something
represented in DT.
The above comment assumes this property is intended to represent DVI's
requirement for pixel clock doubling for low-pixel-clock-rate modes. If
it's something to do with e.g. a single-data-rate vs. double-data-rate
property of the underlying physical connection, that's most likely
something that should be defined in a binding specific to e.g. LVDS,
rather than something generic.
> + - link-width: number of channels (e.g. LVDS)
> + - bpp: bits-per-pixel
> +
> +timings-subnode
> +---
> +
> +required properties:
> +subnodes that specify
> + - hactive, vactive: Display resolution
> + - hfront-porch, hback-porch, hsync-len: Horizontal Display timing parameters
> + in pixels
> + vfront-porch, vback-porch, vsync-len: Vertical display timing parameters
> in
> + lines
> + - clock: displayclock in Hz
> +
> +There are different ways of describing a display and its capabilities. The
> devicetree
> +representation corresponds to the one commonly found in datasheets for
> displays.
> +The description of the display and its timing is split in two parts: first
> the display
> +properties like size in mm and (optionally) multiple subnodes with the
> supported timings.
> +If a display supports multiple signal timings, the default-timing can be
> specified.
> +
> +Example:
> +
> + display at 0 {
> + width-mm = <800>;
> + height-mm = <480>;
> + default-timing = <&timing0>;
> + timings {
> + timing0: timing at 0 {
If you're going to use a unit address ("@0") to ensure that node names
are unique (which is not mandatory), then each node also needs a reg
property with matching value, and #address-cells/#size-cells in the
parent. Instead, you could name the nodes something unique based on the
mode name to avoid this, e.g. 1080p24 { ... }.
[PATCH 1/5] dma-buf: remove fallback for !CONFIG_DMA_SHARED_BUFFER
On 09/29/2012 05:16 PM, Maarten Lankhorst wrote: > Op 28-09-12 22:10, Thomas Hellstrom schreef: >> On 09/28/2012 09:42 PM, Thomas Hellstrom wrote: >>> On 09/28/2012 04:14 PM, Maarten Lankhorst wrote: Hey, Op 28-09-12 14:41, Maarten Lankhorst schreef: > Documentation says that code requiring dma-buf should add it to > select, so inline fallbacks are not going to be used. A link error > will make it obvious what went wrong, instead of silently doing > nothing at runtime. > The whole patch series is in my tree, I use stg so things might move around, do not use for merging currently: http://cgit.freedesktop.org/~mlankhorst/linux/log/?h=v10-wip It contains everything in here plus the patches for ttm to make it work, I use a old snapshot of drm-next + merge of nouveau as base. Description of what the parts do: Series to fix small api issues when moving over: drm/ttm: Remove cpu_writers related code drm/ttm: Add ttm_bo_is_reserved function drm/radeon: Use ttm_bo_is_reserved drm/vmwgfx: use ttm_bo_is_reserved drm/vmwgfx: remove use of fence_obj_args drm/ttm: remove sync_obj_arg drm/ttm: remove sync_obj_arg from ttm_bo_move_accel_cleanup drm/ttm: remove sync_arg entirely drm/nouveau: unpin buffers before releasing to prevent lockdep warnings drm/nouveau: add reservation to nouveau_bo_vma_del drm/nouveau: add reservation to nouveau_gem_ioctl_cpu_prep Hey great, now we only have one user left for fence waiting before reserving, lets fix that and remove fence lock: ttm_bo_cleanup_refs_or_queue and ttm_bo_cleanup_refs have to reserve before waiting, lets do it in the squash commit so we don't have to throw lock order around everywhere: drm/ttm: remove fence_lock -- Up to this point should be mergeable now Then we start working on lru_lock removal slightly, this means the lru list no longer is empty but can contain only reserved buffers: drm/ttm: do not check if list is empty in ttm_bo_force_list_clean drm/ttm: move reservations for ttm_bo_cleanup_refs -- Still mergeable up to this point, just fixes Patch series from this email: dma-buf: remove fallback for !CONFIG_DMA_SHARED_BUFFER fence: dma-buf cross-device synchronization (v9) seqno-fence: Hardware dma-buf implementation of fencing (v3) reservation: cross-device reservation support reservation: Add lockdep annotation and selftests Now hook it up to drm/ttm in a few steps: usage around reservations: drm/ttm: make ttm reservation calls behave like reservation calls drm/ttm: use dma_reservation api dma-buf: use reservations drm/ttm: allow drivers to pass custom dma_reservation_objects for a bo then kill off the lru lock around reservation: drm/ttm: remove lru_lock around ttm_bo_reserve drm/ttm: simplify ttm_eu_* The lru_lock removal patch removes the lock around lru_lock around the reservation, this will break the assumption that items on the lru list and swap list can always be reserved, and this gets patched up too. Is there any part in ttm you disagree with? I believe that this is all mergeable, the lru_lock removal patch could be moved to before the reservation parts, this might make merging easier, but I don't think there is any ttm part of the series that are wrong on a conceptual level. ~Maarten >>> From another email >>> > As previously discussed, I'm unfortunately not prepared to accept removal > of the reserve-lru atomicity >into the TTM code at this point. > The current code is based on this assumption and removing it will end up > with > efficiencies, breaking the delayed delete code and probably a locking > nightmare when trying to write > new TTM code. The lru lock removal patch fixed the delayed delete code, it really is not different from the current situation. In fact it is more clear without the guarantee what various parts are trying to protect. Nothing prevents you from holding the lru_lock while trylocking, >>> [1] >>> While this would not cause any deadlocks, Any decent lockdep code would >>> establish lru->reserve as the locking >>> order once a lru- reserve trylock succeeds, but the locking order is really >>> reserve->lru for obvious reasons, which >>> means we will get a lot of lockdep errors? Yes, there are a two reversals >>> like these already in the TTM code, and I'm >>> not very proud of them. >>> >>> leaving that guarantee intact for that part. Can you really just review >>> the patch and tell me where it breaks and/or makes the code unreadable? >>> >>> OK. Now I'm looking at >>> http://cgit.freedesktop.org/~mlankhorst/linux/tree/drivers/gpu/drm/ttm/ttm_bo.
Re: [PATCH 1/2] of: add helper to parse display specs
On 09/24/2012 09:35 AM, Steffen Trumtrar wrote:
> Parse a display-node with timings and hardware-specs from devictree.
> diff --git a/Documentation/devicetree/bindings/video/display
> b/Documentation/devicetree/bindings/video/display
> new file mode 100644
> index 000..722766a
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/video/display
This should be display.txt.
> @@ -0,0 +1,208 @@
> +display bindings
> +==
> +
> +display-node
> +
I'm not personally convinced about the direction this is going. While I
think it's reasonable to define DT bindings for displays, and DT
bindings for display modes, I'm not sure that it's reasonable to couple
them together into a single binding.
I think creating a well-defined timing binding first will be much
simpler than doing so within the context of a display binding; the
scope/content of a general display binding seems much less well-defined
to me at least, for reasons I mentioned before.
> +required properties:
> + - none
> +
> +optional properties:
> + - default-timing: the default timing value
> + - width-mm, height-mm: Display dimensions in mm
> + - hsync-active-high (bool): Hsync pulse is active high
> + - vsync-active-high (bool): Vsync pulse is active high
At least those two properties should exist in the display timing instead
(or perhaps as well). There are certainly cases where different similar
display modes are differentiated by hsync/vsync polarity more than
anything else. This is probably more likely with analog display
connectors than digital, but I see no reason why a DT binding for
display timing shouldn't cover both.
> + - de-active-high (bool): Data-Enable pulse is active high
> + - pixelclk-inverted (bool): pixelclock is inverted
> + - pixel-per-clk
pixel-per-clk is probably something that should either be part of the
timing definition, or something computed internally to the display
driver based on rules for the signal type, rather than something
represented in DT.
The above comment assumes this property is intended to represent DVI's
requirement for pixel clock doubling for low-pixel-clock-rate modes. If
it's something to do with e.g. a single-data-rate vs. double-data-rate
property of the underlying physical connection, that's most likely
something that should be defined in a binding specific to e.g. LVDS,
rather than something generic.
> + - link-width: number of channels (e.g. LVDS)
> + - bpp: bits-per-pixel
> +
> +timings-subnode
> +---
> +
> +required properties:
> +subnodes that specify
> + - hactive, vactive: Display resolution
> + - hfront-porch, hback-porch, hsync-len: Horizontal Display timing parameters
> + in pixels
> + vfront-porch, vback-porch, vsync-len: Vertical display timing parameters
> in
> + lines
> + - clock: displayclock in Hz
> +
> +There are different ways of describing a display and its capabilities. The
> devicetree
> +representation corresponds to the one commonly found in datasheets for
> displays.
> +The description of the display and its timing is split in two parts: first
> the display
> +properties like size in mm and (optionally) multiple subnodes with the
> supported timings.
> +If a display supports multiple signal timings, the default-timing can be
> specified.
> +
> +Example:
> +
> + display@0 {
> + width-mm = <800>;
> + height-mm = <480>;
> + default-timing = <&timing0>;
> + timings {
> + timing0: timing@0 {
If you're going to use a unit address ("@0") to ensure that node names
are unique (which is not mandatory), then each node also needs a reg
property with matching value, and #address-cells/#size-cells in the
parent. Instead, you could name the nodes something unique based on the
mode name to avoid this, e.g. 1080p24 { ... }.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH V6 2/2] video: drm: exynos: Add device tree support
On 09/30/2012 11:29 PM, Leela Krishna Amudala wrote: > Hello Stephen Warren, > > The binding names that I use in my dts file should match with the > names given in > http://lists.freedesktop.org/archives/dri-devel/2012-July/024875.html > right? I don't think so; the binding in that link is for example: > + - xres, yres: Display resolution > + - left-margin, right-margin, hsync-len: Horizontal Display timing parameters > + in pixels > + upper-margin, lower-margin, vsync-len: Vertical display timing parameters > in > + lines > + - clock: displayclock in Hz i.e. a bunch of separate properties, one for each value needed to describe the display timing. However, your patch contains: >>> + - samsung,fimd-display: This property should specify the phandle of the >>> + display device node which holds the video interface timing with the >>> + below mentioned properties. >>> + >>> + - lcd-htiming: Specifies the horizontal timing for the overlay. The >>> + horizontal timing includes four parameters in the following order. >>> + >>> + - horizontal back porch (in number of lcd clocks) >>> + - horizontal front porch (in number of lcd clocks) >>> + - hsync pulse width (in number of lcd clocks) >>> + - Display panels X resolution. A single lcd-htiming property, which contains 4 values. (and a similar construct for the vertical timing). That seems entirely different to me... ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[3.2.y] drm/i915: add Ivy Bridge GT2 Server entries
Hi Ben, Please consider cc22a938fc1d drm/i915: add Ivy Bridge GT2 Server entries, 2012-03-29 for application to the 3.2.y tree. It adds a PCI id to the i915 driver, making kms work. It was applied during the 3.4-rc2 cycle, so newer stable kernels don't need it. Maik Zumstrull tried it[1] on top of 3.2.30 and found it to work ok (thanks!). Note that pre-2.4.34 versions of libdrm don't cope well with that card, with or without this patch: - without this patch, modern X errors out instead of starting, because the intel driver requires kms. (In a hypothetical better world, userspace would know to fall back to vesa or something.) - with this patch and with libdrm patch 2.4.34~22 (intel: add Ivy Bridge GT2 server variant, 2012-03-29), X should work great - with this patch, without libdrm 2.4.34~22, but with libdrm patch 2.4.38~10 (intel: Bail gracefully if we encounter an unknown Intel device, 2012-07-25) applied, X should error out instead of starting - with this patch, and with libdrm lacking 2.4.34~22 and 2.4.38~10, X freezes at startup. "No regressions" means you probably shouldn't take this patch without a safety to work around the old X userspace, unless you can shout enough in release notes to get people to apply 2.4.38~10 to libdrm and maintain sanity. ;) Hmm? Jonathan [1] http://bugs.debian.org/684767 ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/nouveau: fix crash regression
Work around a crash during boot if noaccel is set.
NB: still broken in 3.5 as well, used to work in 3.4. Why are people
ignoring this? It's a regression!
Signed-off-by: Ortwin Glück
---
diff --git a/drivers/gpu/drm/nouveau/nv50_display.c
b/drivers/gpu/drm/nouveau/nv50_display.c
index b244d99..c7ffa63 100644
--- a/drivers/gpu/drm/nouveau/nv50_display.c
+++ b/drivers/gpu/drm/nouveau/nv50_display.c
@@ -650,6 +650,12 @@ nv50_display_vblank_crtc_handler(struct drm_device
*dev, int crtc)
struct nouveau_software_priv *psw = nv_engine(dev, NVOBJ_ENGINE_SW);
struct nouveau_software_chan *pch, *tmp;
+if (!psw) {
+WARN_ON_ONCE(1);
+printk(KERN_ERR "NULL software engine\n");
+return;
+}
+
list_for_each_entry_safe(pch, tmp, &psw->vblank, vblank.list) {
if (pch->vblank.head != crtc)
continue;
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 49981] On HD6850, Power Profile doesn't change if 2 screen is attached.
https://bugs.freedesktop.org/show_bug.cgi?id=49981 --- Comment #11 from graham --- Created attachment 67937 --> https://bugs.freedesktop.org/attachment.cgi?id=67937&action=edit patch for barts and caicos mobility Tested on barts, not caicos. It's restricted to only the power state profiles that I have data on so far, and falls back to the r600 profile for everything else. The mobility profile assumes the laptop will be plugged in when in multi-monitor mode, and so it puts it in performance mode for mid and high. I want to sort out dynpm too, but dynpm seems to be a huge WIP at the moment, as it just disables it completely if there is more than one monitor. With a single monitor, NI is the same as r600, so it can use the same dynpm. -- You are receiving this mail because: You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH V6 2/2] video: drm: exynos: Add device tree support
On 09/30/2012 11:29 PM, Leela Krishna Amudala wrote: > Hello Stephen Warren, > > The binding names that I use in my dts file should match with the > names given in > http://lists.freedesktop.org/archives/dri-devel/2012-July/024875.html > right? I don't think so; the binding in that link is for example: > + - xres, yres: Display resolution > + - left-margin, right-margin, hsync-len: Horizontal Display timing parameters > + in pixels > + upper-margin, lower-margin, vsync-len: Vertical display timing parameters > in > + lines > + - clock: displayclock in Hz i.e. a bunch of separate properties, one for each value needed to describe the display timing. However, your patch contains: >>> + - samsung,fimd-display: This property should specify the phandle of the >>> + display device node which holds the video interface timing with the >>> + below mentioned properties. >>> + >>> + - lcd-htiming: Specifies the horizontal timing for the overlay. The >>> + horizontal timing includes four parameters in the following order. >>> + >>> + - horizontal back porch (in number of lcd clocks) >>> + - horizontal front porch (in number of lcd clocks) >>> + - hsync pulse width (in number of lcd clocks) >>> + - Display panels X resolution. A single lcd-htiming property, which contains 4 values. (and a similar construct for the vertical timing). That seems entirely different to me...
[PATCH] drm/nouveau: fix crash regression
Work around a crash during boot if noaccel is set.
NB: still broken in 3.5 as well, used to work in 3.4. Why are people
ignoring this? It's a regression!
Signed-off-by: Ortwin Gl?ck
---
diff --git a/drivers/gpu/drm/nouveau/nv50_display.c
b/drivers/gpu/drm/nouveau/nv50_display.c
index b244d99..c7ffa63 100644
--- a/drivers/gpu/drm/nouveau/nv50_display.c
+++ b/drivers/gpu/drm/nouveau/nv50_display.c
@@ -650,6 +650,12 @@ nv50_display_vblank_crtc_handler(struct drm_device
*dev, int crtc)
struct nouveau_software_priv *psw = nv_engine(dev, NVOBJ_ENGINE_SW);
struct nouveau_software_chan *pch, *tmp;
+if (!psw) {
+WARN_ON_ONCE(1);
+printk(KERN_ERR "NULL software engine\n");
+return;
+}
+
list_for_each_entry_safe(pch, tmp, &psw->vblank, vblank.list) {
if (pch->vblank.head != crtc)
continue;
[Bug 43405] Only horizontal lines (snow) display in google earth/glxgears using current r600g on RS780M
https://bugs.freedesktop.org/show_bug.cgi?id=43405 Paul Menzel changed: What|Removed |Added CC||paulepanter at users.sourcefor ||ge.net --- Comment #15 from Paul Menzel --- I do not see this with Debian Sid/unstable (Mesa 8.0.4) and HD 3200 (RS780). 01:05.0 VGA compatible controller: Advanced Micro Devices [AMD] nee ATI RS780 [Radeon HD 3200] At least `glxgears` works fine. Any special prerequisites to run this with? With debug message the following is written to `dmesg`. [ 9350.289921] [drm:drm_mode_addfb], [FB:39] [ 9350.289975] [drm:radeon_crtc_page_flip], flip-ioctl() cur_fbo = f6d77c00, cur_bbo = f72df800 [ 9350.334609] [drm:drm_mode_addfb], [FB:36] [ 9350.334646] [drm:radeon_crtc_page_flip], flip-ioctl() cur_fbo = f72df800, cur_bbo = f6d77c00 [ 9350.349981] [drm:drm_mode_addfb], [FB:39] [ 9350.350015] [drm:radeon_crtc_page_flip], flip-ioctl() cur_fbo = f6d77c00, cur_bbo = f72df800 [ 9350.366670] [drm:drm_mode_addfb], [FB:36] [ 9350.366701] [drm:radeon_crtc_page_flip], flip-ioctl() cur_fbo = f72df800, cur_bbo = f6d77c00 [ 9350.383145] [drm:drm_mode_addfb], [FB:39] [ 9350.383174] [drm:radeon_crtc_page_flip], flip-ioctl() cur_fbo = f6d77c00, cur_bbo = f72df800 [ 9350.400070] [drm:drm_mode_addfb], [FB:36] [ 9350.400104] [drm:radeon_crtc_page_flip], flip-ioctl() cur_fbo = f72df800, cur_bbo = f6d77c00 [ 9350.416752] [drm:drm_mode_addfb], [FB:39] [ 9350.416779] [drm:radeon_crtc_page_flip], flip-ioctl() cur_fbo = f6d77c00, cur_bbo = f72df800 [ 9350.433387] [drm:drm_mode_addfb], [FB:36] [ 9350.433418] [drm:radeon_crtc_page_flip], flip-ioctl() cur_fbo = f72df800, cur_bbo = f6d77c00 [ 9350.449614] [drm:drm_mode_addfb], [FB:39] [ 9350.449627] [drm:radeon_crtc_page_flip], flip-ioctl() cur_fbo = f6d77c00, cur_bbo = f72df800 [ 9350.466732] [drm:drm_mode_addfb], [FB:36] [ 9350.466766] [drm:radeon_crtc_page_flip], flip-ioctl() cur_fbo = f72df800, cur_bbo = f6d77c00 [ 9350.483430] [drm:drm_mode_addfb], [FB:39] [ 9350.483462] [drm:radeon_crtc_page_flip], flip-ioctl() cur_fbo = f6d77c00, cur_bbo = f72df800 [ 9350.500105] [drm:drm_mode_addfb], [FB:36] [ 9350.500134] [drm:radeon_crtc_page_flip], flip-ioctl() cur_fbo = f72df800, cur_bbo = f6d77c00 [ 9350.516427] [drm:drm_mode_addfb], [FB:39] [ 9350.516445] [drm:radeon_crtc_page_flip], flip-ioctl() cur_fbo = f6d77c00, cur_bbo = f72df800 [ 9350.533403] [drm:drm_mode_addfb], [FB:36] [ 9350.533433] [drm:radeon_crtc_page_flip], flip-ioctl() cur_fbo = f72df800, cur_bbo = f6d77c00 [?] -- 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/20121001/5b8f84ff/attachment.html>
[Bug 43405] Only horizontal lines (snow) display in google earth/glxgears using current r600g on RS780M
https://bugs.freedesktop.org/show_bug.cgi?id=43405 --- Comment #16 from idun...@lavabit.com --- On Mon, 01 Oct 2012 09:58:49 + bugzilla-dae...@freedesktop.org wrote: > --- Comment #15 from Paul Menzel --- > I do not see this with Debian Sid/unstable (Mesa 8.0.4) and HD 3200 (RS780). > > 01:05.0 VGA compatible controller: Advanced Micro Devices [AMD] nee ATI > RS780 [Radeon HD 3200] > > At least `glxgears` works fine. Any special prerequisites to run this with? At present, I'm suspecting that it's something to do with the Squeeze X stack (I'm using Squeeze with the stock Xorg, and I've updated only the minimum to satisfy configure). -- You are receiving this mail because: You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 43405] Only horizontal lines (snow) display in google earth/glxgears using current r600g on RS780M
https://bugs.freedesktop.org/show_bug.cgi?id=43405 --- Comment #14 from idunham at lavabit.com --- On Mon, 01 Oct 2012 07:20:49 + bugzilla-daemon at freedesktop.org wrote: > https://bugs.freedesktop.org/show_bug.cgi?id=43405 > > --- Comment #13 from Andreas Boll --- > (In reply to comment #12) > > Can you try git clean -fdx before autogen? > Before I got your message, I ran make -C src/glsl glsl_lexer.cc which generated the file After that, it built properly. I'm still getting the same snow display. I suspect it's an interaction with the Squeeze X stack, since I didn't get this with Precise (which has its own problems...) I hope to try later when I've updated to the backports.org X server. -- 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/20121001/5f6b25df/attachment.html>
[PATCH 1/2] of: add helper to parse display specs
On 10/1/2012 6:53 AM, Stephen Warren wrote:
> On 09/24/2012 09:35 AM, Steffen Trumtrar wrote:
>> Parse a display-node with timings and hardware-specs from devictree.
>
>> diff --git a/Documentation/devicetree/bindings/video/display
>> b/Documentation/devicetree/bindings/video/display
>> new file mode 100644
>> index 000..722766a
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/video/display
>
> This should be display.txt.
>
>> @@ -0,0 +1,208 @@
>> +display bindings
>> +==
>> +
>> +display-node
>> +
>
> I'm not personally convinced about the direction this is going. While I
> think it's reasonable to define DT bindings for displays, and DT
> bindings for display modes, I'm not sure that it's reasonable to couple
> them together into a single binding.
>
> I think creating a well-defined timing binding first will be much
> simpler than doing so within the context of a display binding; the
> scope/content of a general display binding seems much less well-defined
> to me at least, for reasons I mentioned before.
>
>> +required properties:
>> + - none
>> +
>> +optional properties:
>> + - default-timing: the default timing value
>> + - width-mm, height-mm: Display dimensions in mm
>
>> + - hsync-active-high (bool): Hsync pulse is active high
>> + - vsync-active-high (bool): Vsync pulse is active high
>
> At least those two properties should exist in the display timing instead
> (or perhaps as well). There are certainly cases where different similar
> display modes are differentiated by hsync/vsync polarity more than
> anything else. This is probably more likely with analog display
> connectors than digital, but I see no reason why a DT binding for
> display timing shouldn't cover both.
>
>> + - de-active-high (bool): Data-Enable pulse is active high
>> + - pixelclk-inverted (bool): pixelclock is inverted
>
>> + - pixel-per-clk
>
> pixel-per-clk is probably something that should either be part of the
> timing definition, or something computed internally to the display
> driver based on rules for the signal type, rather than something
> represented in DT.
>
> The above comment assumes this property is intended to represent DVI's
> requirement for pixel clock doubling for low-pixel-clock-rate modes. If
> it's something to do with e.g. a single-data-rate vs. double-data-rate
> property of the underlying physical connection, that's most likely
> something that should be defined in a binding specific to e.g. LVDS,
> rather than something generic.
>
>> + - link-width: number of channels (e.g. LVDS)
>> + - bpp: bits-per-pixel
>> +
>> +timings-subnode
>> +---
>> +
>> +required properties:
>> +subnodes that specify
>> + - hactive, vactive: Display resolution
>> + - hfront-porch, hback-porch, hsync-len: Horizontal Display timing
>> parameters
>> + in pixels
>> + vfront-porch, vback-porch, vsync-len: Vertical display timing parameters
>> in
>> + lines
>> + - clock: displayclock in Hz
>> +
>> +There are different ways of describing a display and its capabilities. The
>> devicetree
>> +representation corresponds to the one commonly found in datasheets for
>> displays.
>> +The description of the display and its timing is split in two parts: first
>> the display
>> +properties like size in mm and (optionally) multiple subnodes with the
>> supported timings.
>> +If a display supports multiple signal timings, the default-timing can be
>> specified.
>> +
>> +Example:
>> +
>> +display at 0 {
>> +width-mm = <800>;
>> +height-mm = <480>;
>> +default-timing = <&timing0>;
>> +timings {
>> +timing0: timing at 0 {
>
> If you're going to use a unit address ("@0") to ensure that node names
> are unique (which is not mandatory), then each node also needs a reg
> property with matching value, and #address-cells/#size-cells in the
> parent. Instead, you could name the nodes something unique based on the
> mode name to avoid this, e.g. 1080p24 { ... }.
I'm concerned that numbered nodes are being misused as arrays.
It's easy to make real arrays by including multiple cells in the value
of each timing parameter, and easy to choose a cell by saying the array
index instead of using the phandle.
>
> ___
> devicetree-discuss mailing list
> devicetree-discuss at lists.ozlabs.org
> https://lists.ozlabs.org/listinfo/devicetree-discuss
>
[Bug 55416] [R600g] Torchlight gives GPU lockup
https://bugs.freedesktop.org/show_bug.cgi?id=55416 --- Comment #8 from Laurent carlier --- Created attachment 67933 --> https://bugs.freedesktop.org/attachment.cgi?id=67933&action=edit dumped shader with R600_DUMP_SHADERS=1 /usr/local/games/Torchlight/Torchlight.bin.x86_64 -- You are receiving this mail because: You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 55448] [ColorTiling2D] R600 BARTS radeon: The kernel rejected CS and graphical corruption with tropics
https://bugs.freedesktop.org/show_bug.cgi?id=55448 Andreas Boll changed: What|Removed |Added Component|Drivers/DRI/R600|Drivers/Gallium/r600 -- 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/20121001/f38931e0/attachment.html>
[Bug 43405] Only horizontal lines (snow) display in google earth/glxgears using current r600g on RS780M
https://bugs.freedesktop.org/show_bug.cgi?id=43405 --- Comment #13 from Andreas Boll --- (In reply to comment #12) Can you try git clean -fdx before autogen? -- 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/20121001/b20fa086/attachment.html>
[Bug 55445] Torchlight: crash due to texture error
https://bugs.freedesktop.org/show_bug.cgi?id=55445 Michel Dänzer changed: What|Removed |Added Assignee|dri-devel@lists.freedesktop |mesa-dev@lists.freedesktop. |.org|org Component|Drivers/Gallium/r600|Mesa core -- You are receiving this mail because: You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 50149] Faulty shaders on RS600
https://bugs.freedesktop.org/show_bug.cgi?id=50149 --- Comment #23 from Roman Šmakal --- Created attachment 67926 --> https://bugs.freedesktop.org/attachment.cgi?id=67926&action=edit Frets on Fire font bug Just noticed that frets on fire are bugged too. Not sure if its related to faulty shaders though. -- You are receiving this mail because: You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 55448] [ColorTiling2D] R600 BARTS radeon: The kernel rejected CS and graphical corruption with tropics
https://bugs.freedesktop.org/show_bug.cgi?id=55448 --- Comment #3 from Alex Deucher --- Are you running a 32-bit app on a 64-bit distro by any chance? If so, you may be using an old version of the 32-bit 3D driver. You'll need to build and install an updated version of the 32-bit 3D driver as well. -- You are receiving this mail because: You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[3.2.y] drm/i915: add Ivy Bridge GT2 Server entries
Hi Ben, Please consider cc22a938fc1d drm/i915: add Ivy Bridge GT2 Server entries, 2012-03-29 for application to the 3.2.y tree. It adds a PCI id to the i915 driver, making kms work. It was applied during the 3.4-rc2 cycle, so newer stable kernels don't need it. Maik Zumstrull tried it[1] on top of 3.2.30 and found it to work ok (thanks!). Note that pre-2.4.34 versions of libdrm don't cope well with that card, with or without this patch: - without this patch, modern X errors out instead of starting, because the intel driver requires kms. (In a hypothetical better world, userspace would know to fall back to vesa or something.) - with this patch and with libdrm patch 2.4.34~22 (intel: add Ivy Bridge GT2 server variant, 2012-03-29), X should work great - with this patch, without libdrm 2.4.34~22, but with libdrm patch 2.4.38~10 (intel: Bail gracefully if we encounter an unknown Intel device, 2012-07-25) applied, X should error out instead of starting - with this patch, and with libdrm lacking 2.4.34~22 and 2.4.38~10, X freezes at startup. "No regressions" means you probably shouldn't take this patch without a safety to work around the old X userspace, unless you can shout enough in release notes to get people to apply 2.4.38~10 to libdrm and maintain sanity. ;) Hmm? Jonathan [1] http://bugs.debian.org/684767
[Bug 43405] Only horizontal lines (snow) display in google earth/glxgears using current r600g on RS780M
https://bugs.freedesktop.org/show_bug.cgi?id=43405 Paul Menzel changed: What|Removed |Added CC||paulepanter@users.sourcefor ||ge.net --- Comment #15 from Paul Menzel --- I do not see this with Debian Sid/unstable (Mesa 8.0.4) and HD 3200 (RS780). 01:05.0 VGA compatible controller: Advanced Micro Devices [AMD] nee ATI RS780 [Radeon HD 3200] At least `glxgears` works fine. Any special prerequisites to run this with? With debug message the following is written to `dmesg`. [ 9350.289921] [drm:drm_mode_addfb], [FB:39] [ 9350.289975] [drm:radeon_crtc_page_flip], flip-ioctl() cur_fbo = f6d77c00, cur_bbo = f72df800 [ 9350.334609] [drm:drm_mode_addfb], [FB:36] [ 9350.334646] [drm:radeon_crtc_page_flip], flip-ioctl() cur_fbo = f72df800, cur_bbo = f6d77c00 [ 9350.349981] [drm:drm_mode_addfb], [FB:39] [ 9350.350015] [drm:radeon_crtc_page_flip], flip-ioctl() cur_fbo = f6d77c00, cur_bbo = f72df800 [ 9350.366670] [drm:drm_mode_addfb], [FB:36] [ 9350.366701] [drm:radeon_crtc_page_flip], flip-ioctl() cur_fbo = f72df800, cur_bbo = f6d77c00 [ 9350.383145] [drm:drm_mode_addfb], [FB:39] [ 9350.383174] [drm:radeon_crtc_page_flip], flip-ioctl() cur_fbo = f6d77c00, cur_bbo = f72df800 [ 9350.400070] [drm:drm_mode_addfb], [FB:36] [ 9350.400104] [drm:radeon_crtc_page_flip], flip-ioctl() cur_fbo = f72df800, cur_bbo = f6d77c00 [ 9350.416752] [drm:drm_mode_addfb], [FB:39] [ 9350.416779] [drm:radeon_crtc_page_flip], flip-ioctl() cur_fbo = f6d77c00, cur_bbo = f72df800 [ 9350.433387] [drm:drm_mode_addfb], [FB:36] [ 9350.433418] [drm:radeon_crtc_page_flip], flip-ioctl() cur_fbo = f72df800, cur_bbo = f6d77c00 [ 9350.449614] [drm:drm_mode_addfb], [FB:39] [ 9350.449627] [drm:radeon_crtc_page_flip], flip-ioctl() cur_fbo = f6d77c00, cur_bbo = f72df800 [ 9350.466732] [drm:drm_mode_addfb], [FB:36] [ 9350.466766] [drm:radeon_crtc_page_flip], flip-ioctl() cur_fbo = f72df800, cur_bbo = f6d77c00 [ 9350.483430] [drm:drm_mode_addfb], [FB:39] [ 9350.483462] [drm:radeon_crtc_page_flip], flip-ioctl() cur_fbo = f6d77c00, cur_bbo = f72df800 [ 9350.500105] [drm:drm_mode_addfb], [FB:36] [ 9350.500134] [drm:radeon_crtc_page_flip], flip-ioctl() cur_fbo = f72df800, cur_bbo = f6d77c00 [ 9350.516427] [drm:drm_mode_addfb], [FB:39] [ 9350.516445] [drm:radeon_crtc_page_flip], flip-ioctl() cur_fbo = f6d77c00, cur_bbo = f72df800 [ 9350.533403] [drm:drm_mode_addfb], [FB:36] [ 9350.533433] [drm:radeon_crtc_page_flip], flip-ioctl() cur_fbo = f72df800, cur_bbo = f6d77c00 […] -- You are receiving this mail because: You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/5] dma-buf: remove fallback for !CONFIG_DMA_SHARED_BUFFER
Op 28-09-12 21:42, Thomas Hellstrom schreef: > On 09/28/2012 04:14 PM, Maarten Lankhorst wrote: >> Hey, >> >> Op 28-09-12 14:41, Maarten Lankhorst schreef: >>> Documentation says that code requiring dma-buf should add it to >>> select, so inline fallbacks are not going to be used. A link error >>> will make it obvious what went wrong, instead of silently doing >>> nothing at runtime. >>> >> >> >> The whole patch series is in my tree, I use stg so things might >> move around, do not use for merging currently: >> >> http://cgit.freedesktop.org/~mlankhorst/linux/log/?h=v10-wip >> >> It contains everything in here plus the patches for ttm to make >> it work, I use a old snapshot of drm-next + merge of nouveau as >> base. Description of what the parts do: >> >> Series to fix small api issues when moving over: >> >> drm/ttm: Remove cpu_writers related code >> drm/ttm: Add ttm_bo_is_reserved function >> drm/radeon: Use ttm_bo_is_reserved >> drm/vmwgfx: use ttm_bo_is_reserved >> >> drm/vmwgfx: remove use of fence_obj_args >> drm/ttm: remove sync_obj_arg >> drm/ttm: remove sync_obj_arg from ttm_bo_move_accel_cleanup >> drm/ttm: remove sync_arg entirely >> >> drm/nouveau: unpin buffers before releasing to prevent lockdep warnings >> drm/nouveau: add reservation to nouveau_bo_vma_del >> drm/nouveau: add reservation to nouveau_gem_ioctl_cpu_prep >> >> Hey great, now we only have one user left for fence waiting before reserving, >> lets fix that and remove fence lock: >> ttm_bo_cleanup_refs_or_queue and ttm_bo_cleanup_refs have to reserve before >> waiting, lets do it in the squash commit so we don't have to throw lock order >> around everywhere: >> >> drm/ttm: remove fence_lock >> >> -- Up to this point should be mergeable now >> >> Then we start working on lru_lock removal slightly, this means the lru >> list no longer is empty but can contain only reserved buffers: >> >> drm/ttm: do not check if list is empty in ttm_bo_force_list_clean >> drm/ttm: move reservations for ttm_bo_cleanup_refs >> >> -- Still mergeable up to this point, just fixes >> >> Patch series from this email: >> dma-buf: remove fallback for !CONFIG_DMA_SHARED_BUFFER >> fence: dma-buf cross-device synchronization (v9) >> seqno-fence: Hardware dma-buf implementation of fencing (v3) >> reservation: cross-device reservation support >> reservation: Add lockdep annotation and selftests >> >> Now hook it up to drm/ttm in a few steps: >> usage around reservations: >> drm/ttm: make ttm reservation calls behave like reservation calls >> drm/ttm: use dma_reservation api >> dma-buf: use reservations >> drm/ttm: allow drivers to pass custom dma_reservation_objects for a bo >> >> then kill off the lru lock around reservation: >> drm/ttm: remove lru_lock around ttm_bo_reserve >> drm/ttm: simplify ttm_eu_* >> >> The lru_lock removal patch removes the lock around lru_lock around the >> reservation, this will break the assumption that items on the lru list >> and swap list can always be reserved, and this gets patched up too. >> Is there any part in ttm you disagree with? I believe that this >> is all mergeable, the lru_lock removal patch could be moved to before >> the reservation parts, this might make merging easier, but I don't >> think there is any ttm part of the series that are wrong on a conceptual >> level. >> >> ~Maarten >> > From another email > >>> As previously discussed, I'm unfortunately not prepared to accept removal >>> of the reserve-lru atomicity >>> into the TTM code at this point. >>> The current code is based on this assumption and removing it will end up >>> with >>> efficiencies, breaking the delayed delete code and probably a locking >>> nightmare when trying to write >>> new TTM code. >> The lru lock removal patch fixed the delayed delete code, it really is not >> different from the current >> situation. In fact it is more clear without the guarantee what various parts >> are trying to protect. >> >> Nothing prevents you from holding the lru_lock while trylocking, > [1] > While this would not cause any deadlocks, Any decent lockdep code would > establish lru->reserve as the locking > order once a lru- reserve trylock succeeds, but the locking order is really > reserve->lru for obvious reasons, which > means we will get a lot of lockdep errors? Yes, there are a two reversals > like these already in the TTM code, and I'm > not very proud of them. I was doing a evil hack where I 'released' lru_lock to lockdep before doing the annotation for a blocking acquire, and left trylock annotations as they were. This made lockdep do the right thing. > And this is even before it starts to get interesting, like how you guarantee > that when you release a buffer from > the delayed delete list, you're the only process having a reference? l thought list_kref made sure of that? Even if not the only one with a reference, the list_empty check would make sure it would only run once. I'l fix it up again so it doesn't become a WARN_ON_ONCE, I
[Bug 43405] Only horizontal lines (snow) display in google earth/glxgears using current r600g on RS780M
https://bugs.freedesktop.org/show_bug.cgi?id=43405 --- Comment #14 from idun...@lavabit.com --- On Mon, 01 Oct 2012 07:20:49 + bugzilla-dae...@freedesktop.org wrote: > https://bugs.freedesktop.org/show_bug.cgi?id=43405 > > --- Comment #13 from Andreas Boll --- > (In reply to comment #12) > > Can you try git clean -fdx before autogen? > Before I got your message, I ran make -C src/glsl glsl_lexer.cc which generated the file After that, it built properly. I'm still getting the same snow display. I suspect it's an interaction with the Squeeze X stack, since I didn't get this with Precise (which has its own problems...) I hope to try later when I've updated to the backports.org X server. -- You are receiving this mail because: You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/5] dma-buf: remove fallback for !CONFIG_DMA_SHARED_BUFFER
On 09/29/2012 05:16 PM, Maarten Lankhorst wrote: Op 28-09-12 22:10, Thomas Hellstrom schreef: On 09/28/2012 09:42 PM, Thomas Hellstrom wrote: On 09/28/2012 04:14 PM, Maarten Lankhorst wrote: Hey, Op 28-09-12 14:41, Maarten Lankhorst schreef: Documentation says that code requiring dma-buf should add it to select, so inline fallbacks are not going to be used. A link error will make it obvious what went wrong, instead of silently doing nothing at runtime. The whole patch series is in my tree, I use stg so things might move around, do not use for merging currently: http://cgit.freedesktop.org/~mlankhorst/linux/log/?h=v10-wip It contains everything in here plus the patches for ttm to make it work, I use a old snapshot of drm-next + merge of nouveau as base. Description of what the parts do: Series to fix small api issues when moving over: drm/ttm: Remove cpu_writers related code drm/ttm: Add ttm_bo_is_reserved function drm/radeon: Use ttm_bo_is_reserved drm/vmwgfx: use ttm_bo_is_reserved drm/vmwgfx: remove use of fence_obj_args drm/ttm: remove sync_obj_arg drm/ttm: remove sync_obj_arg from ttm_bo_move_accel_cleanup drm/ttm: remove sync_arg entirely drm/nouveau: unpin buffers before releasing to prevent lockdep warnings drm/nouveau: add reservation to nouveau_bo_vma_del drm/nouveau: add reservation to nouveau_gem_ioctl_cpu_prep Hey great, now we only have one user left for fence waiting before reserving, lets fix that and remove fence lock: ttm_bo_cleanup_refs_or_queue and ttm_bo_cleanup_refs have to reserve before waiting, lets do it in the squash commit so we don't have to throw lock order around everywhere: drm/ttm: remove fence_lock -- Up to this point should be mergeable now Then we start working on lru_lock removal slightly, this means the lru list no longer is empty but can contain only reserved buffers: drm/ttm: do not check if list is empty in ttm_bo_force_list_clean drm/ttm: move reservations for ttm_bo_cleanup_refs -- Still mergeable up to this point, just fixes Patch series from this email: dma-buf: remove fallback for !CONFIG_DMA_SHARED_BUFFER fence: dma-buf cross-device synchronization (v9) seqno-fence: Hardware dma-buf implementation of fencing (v3) reservation: cross-device reservation support reservation: Add lockdep annotation and selftests Now hook it up to drm/ttm in a few steps: usage around reservations: drm/ttm: make ttm reservation calls behave like reservation calls drm/ttm: use dma_reservation api dma-buf: use reservations drm/ttm: allow drivers to pass custom dma_reservation_objects for a bo then kill off the lru lock around reservation: drm/ttm: remove lru_lock around ttm_bo_reserve drm/ttm: simplify ttm_eu_* The lru_lock removal patch removes the lock around lru_lock around the reservation, this will break the assumption that items on the lru list and swap list can always be reserved, and this gets patched up too. Is there any part in ttm you disagree with? I believe that this is all mergeable, the lru_lock removal patch could be moved to before the reservation parts, this might make merging easier, but I don't think there is any ttm part of the series that are wrong on a conceptual level. ~Maarten From another email As previously discussed, I'm unfortunately not prepared to accept removal of the reserve-lru atomicity into the TTM code at this point. The current code is based on this assumption and removing it will end up with efficiencies, breaking the delayed delete code and probably a locking nightmare when trying to write new TTM code. The lru lock removal patch fixed the delayed delete code, it really is not different from the current situation. In fact it is more clear without the guarantee what various parts are trying to protect. Nothing prevents you from holding the lru_lock while trylocking, [1] While this would not cause any deadlocks, Any decent lockdep code would establish lru->reserve as the locking order once a lru- reserve trylock succeeds, but the locking order is really reserve->lru for obvious reasons, which means we will get a lot of lockdep errors? Yes, there are a two reversals like these already in the TTM code, and I'm not very proud of them. leaving that guarantee intact for that part. Can you really just review the patch and tell me where it breaks and/or makes the code unreadable? OK. Now I'm looking at http://cgit.freedesktop.org/~mlankhorst/linux/tree/drivers/gpu/drm/ttm/ttm_bo.c?h=v10-wip&id=1436e2e64697c744d6e186618448e1e6354846bb And let's start with a function that's seen some change, ttm_mem_evict_first: *) Line 715: You're traversing a list using list_for_each() calling a function that may remove the list entry *) Line 722: You're unlocking the lock protecting the list in the middle of list traversal *) Line 507: WARN_ON_ONCE in a code path quite likely to get called? When will it get called? ttm_bo_delayed_delete calls it if it's already on delayed destroy list. ttm_mem_evict_first only cal
[Bug 55448] [ColorTiling2D] R600 BARTS radeon: The kernel rejected CS and graphical corruption with tropics
https://bugs.freedesktop.org/show_bug.cgi?id=55448 Andreas Boll changed: What|Removed |Added Component|Drivers/DRI/R600|Drivers/Gallium/r600 -- You are receiving this mail because: You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 43405] Only horizontal lines (snow) display in google earth/glxgears using current r600g on RS780M
https://bugs.freedesktop.org/show_bug.cgi?id=43405 --- Comment #12 from idunham at lavabit.com --- On Mon, 03 Sep 2012 12:22:38 + bugzilla-daemon at freedesktop.org wrote: > https://bugs.freedesktop.org/show_bug.cgi?id=43405 > Could you confirm that this issue is resolved on mesa git master > or mesa git 9.0 branch? Sorry to take so long replying; school's been keeping me busy. At present, I'm not getting mesa to build: #on master make distclean git pull /autogen.sh --prefix=/opt/mesa9 --enable-driglx=direct \ --enable-gallium --enable-texture-float \ --with-dri-driverdir=/opt/mesa9/lib --with-state-trackers=glx,dri \ --without-dri-drivers --with-gallium-drivers=r600 --disable-egl #succeeds make -j1 .. make[4]: *** No rule to make target `../../../src/glsl/glsl_lexer.cc', needed by `glsl_lexer.lo'. Stop. This is still Debian Squeeze plus several backports; I've updated the kernel to 3.4.11, xcb to 1.8.1, and libdrm/libkms to 2.4.39. Thanks, Isaac Dunham -- 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/20121001/aa8962ec/attachment.html>
[Bug 43405] Only horizontal lines (snow) display in google earth/glxgears using current r600g on RS780M
https://bugs.freedesktop.org/show_bug.cgi?id=43405 --- Comment #13 from Andreas Boll --- (In reply to comment #12) Can you try git clean -fdx before autogen? -- You are receiving this mail because: You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] dma-buf: might_sleep() in dma_buf_unmap_attachment()
On Friday 28 September 2012 01:09 PM, Maarten Lankhorst wrote:
Op 28-09-12 09:29, Rob Clark schreef:
From: Rob Clark
We never really clarified if unmap could be done in atomic context.
But since mapping might require sleeping, this implies mutex in use
to synchronize mapping/unmapping, so unmap could sleep as well. Add
a might_sleep() to clarify this.
Signed-off-by: Rob Clark
Acked-by: Daniel Vetter
---
drivers/base/dma-buf.c |2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/base/dma-buf.c b/drivers/base/dma-buf.c
index c30f3e1..877eacb 100644
--- a/drivers/base/dma-buf.c
+++ b/drivers/base/dma-buf.c
@@ -298,6 +298,8 @@ void dma_buf_unmap_attachment(struct dma_buf_attachment
*attach,
struct sg_table *sg_table,
enum dma_data_direction direction)
{
+ might_sleep();
+
if (WARN_ON(!attach || !attach->dmabuf || !sg_table))
return;
Looks good to me!
Reviewed-by: Maarten Lankhorst
Thanks Rob,
Applied to for-next.
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[ 192/262] drm: Add EDID_QUIRK_FORCE_REDUCED_BLANKING for ASUS VW222S
From: Greg KH
3.5-stable review patch. If anyone has any objections, please let me know.
--
From: Paul Menzel
commit 6f33814bd4d9cfe76033a31b1c0c76c960cd8e4b upstream.
Connecting an ASUS VW222S [1] over VGA a garbled screen is shown with
vertical stripes in the top half.
In commit bc42aabc [2]
commit bc42aabc6a01b92b0f961d65671564e0e1cd7592
Author: Adam Jackson
Date: Wed May 23 16:26:54 2012 -0400
drm/edid/quirks: ViewSonic VA2026w
Adam Jackson added the quirk `EDID_QUIRK_FORCE_REDUCED_BLANKING` which
is also needed for this ASUS monitor.
All log files and output from `xrandr` is included in the referenced
Bugzilla report #17629.
Please note that this monitor only has a VGA (D-Sub) connector [1].
[1] http://www.asus.com/Display/LCD_Monitors/VW222S/
[2]
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=commit;h=bc42aabc6a01b92b0f961d65671564e0e1cd7592
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=17629
Signed-off-by: Paul Menzel
Cc:
Cc: Adam Jackson
Cc: Ian Pilcher
Signed-off-by: Dave Airlie
Signed-off-by: Greg Kroah-Hartman
---
drivers/gpu/drm/drm_edid.c |3 +++
1 file changed, 3 insertions(+)
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -87,6 +87,9 @@ static struct edid_quirk {
int product_id;
u32 quirks;
} edid_quirk_list[] = {
+ /* ASUS VW222S */
+ { "ACI", 0x22a2, EDID_QUIRK_FORCE_REDUCED_BLANKING },
+
/* Acer AL1706 */
{ "ACR", 44358, EDID_QUIRK_PREFER_LARGE_60 },
/* Acer F51 */
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 49981] On HD6850, Power Profile doesn't change if 2 screen is attached.
https://bugs.freedesktop.org/show_bug.cgi?id=49981 --- Comment #10 from graham --- K, using AMD overdrive in windows it seems in single head mode it steps from 100Mhz to 777Mhz and then 900Mhz, but in dual head it idles at 300 Mhz, but switches back to 775Mhz and 900Mhz for mid and high. It doesn't seem to use 600 Mhz (ps3) at all, but it's a fairly safe bet that it's the idle state for triple head, eyefinity stuff. So the order should be; single-head: ps1/cm0, ps1/cm1, ps1/cm2 dual-head: ps2/cm(any), ps1/cm1, ps1/cm2 triple-head: ps3/cm(any), ps1/cm1, ps1/cm2 Thanks for the power states. Need cayman, caicos and turks still. Hopefully they are all the same though. -- 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/20121001/bd901721/attachment.html>
Re: [PATCH V6 2/2] video: drm: exynos: Add device tree support
Hello Stephen Warren, The binding names that I use in my dts file should match with the names given in http://lists.freedesktop.org/archives/dri-devel/2012-July/024875.html right? I think that is the only thing I have to take care, and as I'm not using "struct drm_display_mode" in my driver its my wish whether to use the helper function or not. Please clarify me if I miss something. Best Regards, Leela Krishna Amudala. On Fri, Sep 21, 2012 at 10:44 AM, Stephen Warren wrote: > On 09/21/2012 05:22 AM, Leela Krishna Amudala wrote: >> This patch adds device tree based discovery support for exynos DRM-FIMD >> driver which includes driver modification to handle platform data in >> both the cases with DT and non-DT, Also adds the documentation for bindings. > >> diff --git a/Documentation/devicetree/bindings/drm/exynos/fimd.txt >> b/Documentation/devicetree/bindings/drm/exynos/fimd.txt > ... >> + - samsung,fimd-display: This property should specify the phandle of the >> + display device node which holds the video interface timing with the >> + below mentioned properties. >> + >> + - lcd-htiming: Specifies the horizontal timing for the overlay. The >> + horizontal timing includes four parameters in the following order. >> + >> + - horizontal back porch (in number of lcd clocks) >> + - horizontal front porch (in number of lcd clocks) >> + - hsync pulse width (in number of lcd clocks) >> + - Display panels X resolution. >> + >> + - lcd-vtiming: Specifies the vertical timing for the overlay. The >> + vertical timing includes four parameters in the following order. >> + >> + - vertical back porch (in number of lcd lines) >> + - vertical front porch (in number of lcd lines) >> + - vsync pulse width (in number of lcd clocks) >> + - Display panels Y resolution. > > Should this not use the new videomode timings that are under discussion at: > > http://lists.freedesktop.org/archives/dri-devel/2012-July/024875.html > -- > To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" > in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
