Re: [PATCH 5/5] DRM: Armada: add support for drm tda19988 driver
On Mon, Oct 07, 2013 at 06:08:12PM +0200, Sebastian Hesselbarth wrote: > True, I didn't mention TDM modes squeezing multiple channels into one > L/R frame. Neither Dove nor TDA998x support this, but thanks for the > clarification. Depending on how the DMA and so on is done you can sometimes still do it on the CPU side by lying to the CPU about the data format (eg, tell it that two 16 bit samples are actually a 32 bit one) though it gets messy for I2S since you need to be able to gather all the left samples and all the right samples. Though given that your CODEC doesn't support it it's still all moot anyway as you say. signature.asc Description: Digital signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 0/26] get_user_pages() cleanup
On Fri 04-10-13 16:42:19, KOSAKI Motohiro wrote: > (10/4/13 4:31 PM), KOSAKI Motohiro wrote: > >(10/2/13 4:29 PM), Jan Kara wrote: > >>On Wed 02-10-13 09:20:09, Christoph Hellwig wrote: > >>>On Wed, Oct 02, 2013 at 04:27:41PM +0200, Jan Kara wrote: > Hello, > > In my quest for changing locking around page faults to make things > easier for > filesystems I found out get_user_pages() users could use a cleanup. The > knowledge about necessary locking for get_user_pages() is in tons of > places in > drivers and quite a few of them actually get it wrong (don't have > mmap_sem when > calling get_user_pages() or hold mmap_sem when calling copy_from_user() > in the > surrounding code). Rather often this actually doesn't seem necessary. This > patch series converts lots of places to use either get_user_pages_fast() > or a new simple wrapper get_user_pages_unlocked() to remove the knowledge > of mmap_sem from the drivers. I'm still looking into converting a few > remaining > drivers (most notably v4l2) which are more complex. > >>> > >>>Even looking over the kerneldoc comment next to it I still fail to > >>>understand when you'd want to use get_user_pages_fast and when not. > >>AFAIU get_user_pages_fast() should be used > >>1) if you don't need any special get_user_pages() arguments (like calling > >> it for mm of a different process, forcing COW, or similar). > >>2) you don't expect pages to be unmapped (then get_user_pages_fast() is > >>actually somewhat slower because it walks page tables twice). > > > >If target page point to anon or private mapping pages, get_user_pages_fast() > >is fork unsafe. O_DIRECT man pages describe a bit about this. > > > > > >see http://man7.org/linux/man-pages/man2/open.2.html > > > >> O_DIRECT I/Os should never be run concurrently with the fork(2) > >> system call, if the memory buffer is a private mapping (i.e., any > >> mapping created with the mmap(2) MAP_PRIVATE flag; this includes > >> memory allocated on the heap and statically allocated buffers). Any > >> such I/Os, whether submitted via an asynchronous I/O interface or > >> from another thread in the process, should be completed before > >> fork(2) is called. Failure to do so can result in data corruption > >> and undefined behavior in parent and child processes. This > >> restriction does not apply when the memory buffer for the O_DIRECT > >> I/Os was created using shmat(2) or mmap(2) with the MAP_SHARED flag. > >> Nor does this restriction apply when the memory buffer has been > >> advised as MADV_DONTFORK with madvise(2), ensuring that it will not > >> be available to the child after fork(2). > > IMHO, get_user_pages_fast() should be renamed to get_user_pages_quirk(). Its > semantics is not equal to get_user_pages(). When someone simply substitute > get_user_pages() to get_user_pages_fast(), they might see huge trouble. I forgot about this speciality (and actually comments didn't remind me :(). But thinking about this some more get_user_pages_fast() seems as save as get_user_pages() in presence of threads sharing mm, doesn't it? Because while get_user_pages() are working, other thread can happilly trigger COW on some of the pages and thus get_user_pages() can return pages some of which are invisible in our mm by the time get_user_pages() returns. So although in practice I agree problems of get_user_pages_fast() with fork(2) are more visible, in essence they are still present with clone(2) and get_user_pages(). Honza -- Jan Kara SUSE Labs, CR ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 0/5] Armada DRM stuff
On 10/07/2013 12:07 AM, Russell King - ARM Linux wrote: The Armada DRM drivers again, along with the TDA998x HDMI output support, and an illustration to show how to add Armada 610 support (and others.) Rob has looked at this a couple of times since its last posting, and has provided additional useful feedback which has been incorporated. I believe all the major issues have been addressed now. Tested-by: Sebastian Hesselbarth on Marvell Armada 510, SolidRun CuBox with quick-hack DT support added. Let's please get this driver mainlined and start working on proper DT support for it. Thanks for driver and the patience to work out all issues! Sebastian ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm: nouveau: fix nvbe leakage
Free memory allocated to nvbe when returning NULL.
Signed-off-by: Geyslan G. Bem
---
drivers/gpu/drm/nouveau/nouveau_sgdma.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/gpu/drm/nouveau/nouveau_sgdma.c
b/drivers/gpu/drm/nouveau/nouveau_sgdma.c
index 0843ebc..af8b66d 100644
--- a/drivers/gpu/drm/nouveau/nouveau_sgdma.c
+++ b/drivers/gpu/drm/nouveau/nouveau_sgdma.c
@@ -105,6 +105,9 @@ nouveau_sgdma_create_ttm(struct ttm_bo_device *bdev,
nvbe->ttm.ttm.func = &nv50_sgdma_backend;
if (ttm_dma_tt_init(&nvbe->ttm, bdev, size, page_flags,
dummy_read_page))
+ {
+ kfree(nvbe);
return NULL;
+ }
return &nvbe->ttm.ttm;
}
--
1.8.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
i915 deadlock on laptop undock
Hi, I have a Lenovo T410s (Ironlake/Arrandale graphics) that I use docked and connected to an external DP monitor (laptop is closed so the only active display is the DP monitor). With 3.12-rc4 I reproducably hit a deadlock when I undock the laptop -- it seems to be a deadlock on dev->mode_confix.mutext between intel_crtc_wait_for_pending_flips (mutex held because of drm_modeset_lock_all in intel_lid_notify) and drm_mode_getconnector. See below for the kernel logging (there's no logging for more than 2 minutes before the hung task stuff) -- it seems that intel_crtc_wait_for_pending_flips is getting stuck, and then everything else piles up behind it: [ 241.009121] INFO: task kworker/0:1:70 blocked for more than 120 seconds. [ 241.009131] Tainted: GW3.12.0-999-generic #201310070425 [ 241.009133] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. [ 241.009137] kworker/0:1 D 070 2 0x [ 241.009152] Workqueue: kacpi_notify acpi_os_execute_deferred [ 241.009156] 88022b2c9ae8 0046 88022b2c9ab8 8e17de71 [ 241.009162] 88022b2c9fd8 88022b2c9fd8 88022b2c9fd8 000144c0 [ 241.009167] 81c144a0 88022b29 0286 88022ae7 [ 241.009173] Call Trace: [ 241.009186] [] schedule+0x29/0x70 [ 241.009247] [] intel_crtc_wait_for_pending_flips+0x8d/0x120 [i915] [ 241.009257] [] ? add_wait_queue+0x60/0x60 [ 241.009289] [] ironlake_crtc_disable+0x7f/0x2a0 [i915] [ 241.009318] [] intel_crtc_update_dpms+0x76/0xb0 [i915] [ 241.009347] [] intel_sanitize_crtc+0xd5/0x370 [i915] [ 241.009377] [] intel_modeset_setup_hw_state+0x17d/0x380 [i915] [ 241.009407] [] intel_lid_notify+0xc1/0x100 [i915] [ 241.009412] [] notifier_call_chain+0x4d/0x70 [ 241.009419] [] __blocking_notifier_call_chain+0x58/0x80 [ 241.009424] [] blocking_notifier_call_chain+0x16/0x20 [ 241.009431] [] acpi_lid_send_state+0x86/0xaf [ 241.009436] [] acpi_button_notify+0x3b/0xa2 [ 241.009442] [] acpi_device_notify+0x19/0x1b [ 241.009448] [] acpi_ev_notify_dispatch+0x41/0x5c [ 241.009453] [] acpi_os_execute_deferred+0x25/0x32 [ 241.009458] [] process_one_work+0x17f/0x4d0 [ 241.009463] [] worker_thread+0x11b/0x3d0 [ 241.009468] [] ? manage_workers.isra.20+0x1b0/0x1b0 [ 241.009473] [] kthread+0xc0/0xd0 [ 241.009479] [] ? flush_kthread_worker+0xb0/0xb0 [ 241.009484] [] ret_from_fork+0x7c/0xb0 [ 241.009489] [] ? flush_kthread_worker+0xb0/0xb0 [ 241.009525] INFO: task Xorg:1436 blocked for more than 120 seconds. [ 241.009528] Tainted: GW3.12.0-999-generic #201310070425 [ 241.009531] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. [ 241.009533] XorgD 0 1436 1410 0x0044 [ 241.009538] 88022ca1bc48 0082 88022ca1bc18 811a31a1 [ 241.009543] 88022ca1bfd8 88022ca1bfd8 88022ca1bfd8 000144c0 [ 241.009549] 880230198000 8800b06546e0 88022ca1bc28 8800363b8330 [ 241.009554] Call Trace: [ 241.009562] [] ? kmem_cache_free+0x121/0x180 [ 241.009568] [] schedule+0x29/0x70 [ 241.009574] [] schedule_preempt_disabled+0xe/0x10 [ 241.009580] [] __mutex_lock_slowpath+0x114/0x1b0 [ 241.009585] [] mutex_lock+0x23/0x40 [ 241.009613] [] drm_mode_getconnector+0xb2/0x430 [drm] [ 241.009633] [] drm_ioctl+0x4fa/0x620 [drm] [ 241.009656] [] ? drm_mode_getcrtc+0xe0/0xe0 [drm] [ 241.009663] [] do_vfs_ioctl+0x7a/0x2e0 [ 241.009668] [] ? vfs_read+0x111/0x180 [ 241.009673] [] SyS_ioctl+0x91/0xb0 [ 241.009678] [] ? SyS_read+0x70/0xa0 [ 241.009683] [] system_call_fastpath+0x1a/0x1f Detailed lspci info for my laptop: 00:00.0 Host bridge [0600]: Intel Corporation Core Processor DRAM Controller [8086:0044] (rev 02) 00:02.0 VGA compatible controller [0300]: Intel Corporation Core Processor Integrated Graphics Controller [8086:0046] (rev 02) 00:16.0 Communication controller [0780]: Intel Corporation 5 Series/3400 Series Chipset HECI Controller [8086:3b64] (rev 06) 00:19.0 Ethernet controller [0200]: Intel Corporation 82577LM Gigabit Network Connection [8086:10ea] (rev 06) 00:1a.0 USB controller [0c03]: Intel Corporation 5 Series/3400 Series Chipset USB2 Enhanced Host Controller [8086:3b3c] (rev 06) 00:1b.0 Audio device [0403]: Intel Corporation 5 Series/3400 Series Chipset High Definition Audio [8086:3b57] (rev 06) 00:1c.0 PCI bridge [0604]: Intel Corporation 5 Series/3400 Series Chipset PCI Express Root Port 1 [8086:3b42] (rev 06) 00:1c.1 PCI bridge [0604]: Intel Corporation 5 Series/3400 Series Chipset PCI Express Root Port 2 [8086:3b44] (rev 06) 00:1c.3 PCI bri
Re: [PATCH] drm: nouveau: fix nvbe leakage
Hi,
On Mon, Oct 7, 2013 at 7:35 PM, Ben Skeggs wrote:
> - Original Message -
>> From: "Geyslan G. Bem"
>> To: airl...@linux.ie, bske...@redhat.com, dri-devel@lists.freedesktop.org
>> Cc: linux-ker...@vger.kernel.org, kernel...@googlegroups.com, "Geyslan G.
>> Bem"
>> Sent: Tuesday, 8 October, 2013 8:14:26 AM
>> Subject: [PATCH] drm: nouveau: fix nvbe leakage
>>
>> Free memory allocated to nvbe when returning NULL.
>>
>> Signed-off-by: Geyslan G. Bem
> NACK. ttm_dma_tt_init() calls the destructor if it fails, which frees the
> memory.
>
> Ben.
>
But ttm_tt_destroy() just handles the ttm_tt part from nvbe, the nvbe
pointer itself is not being free'd.
>> ---
>> drivers/gpu/drm/nouveau/nouveau_sgdma.c | 3 +++
>> 1 file changed, 3 insertions(+)
>>
>> diff --git a/drivers/gpu/drm/nouveau/nouveau_sgdma.c
>> b/drivers/gpu/drm/nouveau/nouveau_sgdma.c
>> index 0843ebc..af8b66d 100644
>> --- a/drivers/gpu/drm/nouveau/nouveau_sgdma.c
>> +++ b/drivers/gpu/drm/nouveau/nouveau_sgdma.c
>> @@ -105,6 +105,9 @@ nouveau_sgdma_create_ttm(struct ttm_bo_device *bdev,
>> nvbe->ttm.ttm.func = &nv50_sgdma_backend;
>>
>> if (ttm_dma_tt_init(&nvbe->ttm, bdev, size, page_flags,
>> dummy_read_page))
>> + {
>> + kfree(nvbe);
>> return NULL;
>> + }
>> return &nvbe->ttm.ttm;
>> }
>> --
>> 1.8.4
>>
>>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
--
Regards,
Felipe Pena
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm: nouveau: fix nvbe leakage
Felipe, thank you too.
I realized this after a code review.
Ben, what do you think?
Geyslan Gregório Bem
hackingbits.com
2013/10/7 Felipe Pena :
> Hi,
>
> On Mon, Oct 7, 2013 at 7:35 PM, Ben Skeggs wrote:
>> - Original Message -
>>> From: "Geyslan G. Bem"
>>> To: airl...@linux.ie, bske...@redhat.com, dri-devel@lists.freedesktop.org
>>> Cc: linux-ker...@vger.kernel.org, kernel...@googlegroups.com, "Geyslan G.
>>> Bem"
>>> Sent: Tuesday, 8 October, 2013 8:14:26 AM
>>> Subject: [PATCH] drm: nouveau: fix nvbe leakage
>>>
>>> Free memory allocated to nvbe when returning NULL.
>>>
>>> Signed-off-by: Geyslan G. Bem
>> NACK. ttm_dma_tt_init() calls the destructor if it fails, which frees the
>> memory.
>>
>> Ben.
>>
>
> But ttm_tt_destroy() just handles the ttm_tt part from nvbe, the nvbe
> pointer itself is not being free'd.
>
>>> ---
>>> drivers/gpu/drm/nouveau/nouveau_sgdma.c | 3 +++
>>> 1 file changed, 3 insertions(+)
>>>
>>> diff --git a/drivers/gpu/drm/nouveau/nouveau_sgdma.c
>>> b/drivers/gpu/drm/nouveau/nouveau_sgdma.c
>>> index 0843ebc..af8b66d 100644
>>> --- a/drivers/gpu/drm/nouveau/nouveau_sgdma.c
>>> +++ b/drivers/gpu/drm/nouveau/nouveau_sgdma.c
>>> @@ -105,6 +105,9 @@ nouveau_sgdma_create_ttm(struct ttm_bo_device *bdev,
>>> nvbe->ttm.ttm.func = &nv50_sgdma_backend;
>>>
>>> if (ttm_dma_tt_init(&nvbe->ttm, bdev, size, page_flags,
>>> dummy_read_page))
>>> + {
>>> + kfree(nvbe);
>>> return NULL;
>>> + }
>>> return &nvbe->ttm.ttm;
>>> }
>>> --
>>> 1.8.4
>>>
>>>
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
>> the body of a message to majord...@vger.kernel.org
>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>> Please read the FAQ at http://www.tux.org/lkml/
>
>
>
> --
> Regards,
> Felipe Pena
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 0/26] get_user_pages() cleanup
(10/7/13 5:18 PM), Jan Kara wrote: On Fri 04-10-13 16:42:19, KOSAKI Motohiro wrote: (10/4/13 4:31 PM), KOSAKI Motohiro wrote: (10/2/13 4:29 PM), Jan Kara wrote: On Wed 02-10-13 09:20:09, Christoph Hellwig wrote: On Wed, Oct 02, 2013 at 04:27:41PM +0200, Jan Kara wrote: Hello, In my quest for changing locking around page faults to make things easier for filesystems I found out get_user_pages() users could use a cleanup. The knowledge about necessary locking for get_user_pages() is in tons of places in drivers and quite a few of them actually get it wrong (don't have mmap_sem when calling get_user_pages() or hold mmap_sem when calling copy_from_user() in the surrounding code). Rather often this actually doesn't seem necessary. This patch series converts lots of places to use either get_user_pages_fast() or a new simple wrapper get_user_pages_unlocked() to remove the knowledge of mmap_sem from the drivers. I'm still looking into converting a few remaining drivers (most notably v4l2) which are more complex. Even looking over the kerneldoc comment next to it I still fail to understand when you'd want to use get_user_pages_fast and when not. AFAIU get_user_pages_fast() should be used 1) if you don't need any special get_user_pages() arguments (like calling it for mm of a different process, forcing COW, or similar). 2) you don't expect pages to be unmapped (then get_user_pages_fast() is actually somewhat slower because it walks page tables twice). If target page point to anon or private mapping pages, get_user_pages_fast() is fork unsafe. O_DIRECT man pages describe a bit about this. see http://man7.org/linux/man-pages/man2/open.2.html O_DIRECT I/Os should never be run concurrently with the fork(2) system call, if the memory buffer is a private mapping (i.e., any mapping created with the mmap(2) MAP_PRIVATE flag; this includes memory allocated on the heap and statically allocated buffers). Any such I/Os, whether submitted via an asynchronous I/O interface or from another thread in the process, should be completed before fork(2) is called. Failure to do so can result in data corruption and undefined behavior in parent and child processes. This restriction does not apply when the memory buffer for the O_DIRECT I/Os was created using shmat(2) or mmap(2) with the MAP_SHARED flag. Nor does this restriction apply when the memory buffer has been advised as MADV_DONTFORK with madvise(2), ensuring that it will not be available to the child after fork(2). IMHO, get_user_pages_fast() should be renamed to get_user_pages_quirk(). Its semantics is not equal to get_user_pages(). When someone simply substitute get_user_pages() to get_user_pages_fast(), they might see huge trouble. I forgot about this speciality (and actually comments didn't remind me :(). But thinking about this some more get_user_pages_fast() seems as save as get_user_pages() in presence of threads sharing mm, doesn't it? It depends. If there is any guarantee that other threads don't touch the same page which retrieved get_user_pages(), get_user_pages_fast() give us brilliant fast way. Example, as far as I heard form IB guys, the userland library of the infiniband stack uses madvise(MADV_DONTFORK), and then they don't need to care COW issue and can choose fastest way. An another example is a futex. futex doesn't use the contents of the pages, it uses vaddr only for looking up key. Then, it also doesn't have COW issue. I don't know other cases. But as far as I know, everything is case-by-case. Because while get_user_pages() are working, other thread can happilly trigger COW on some of the pages and thus get_user_pages() can return pages some of which are invisible in our mm by the time get_user_pages() returns. If you are talking about get_user_pages() instead of get_user_pages_fast(), this can't be happen because page-fault takes mmap_sem too. I would say, mmap_sem has too fat responsibility really. So although in practice I agree problems of get_user_pages_fast() with fork(2) are more visible, in essence they are still present with clone(2) and get_user_pages(). Honza ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 0/26] get_user_pages() cleanup
On Mon 07-10-13 20:27:16, KOSAKI Motohiro wrote: > (10/7/13 5:18 PM), Jan Kara wrote: > >On Fri 04-10-13 16:42:19, KOSAKI Motohiro wrote: > >>(10/4/13 4:31 PM), KOSAKI Motohiro wrote: > >>>(10/2/13 4:29 PM), Jan Kara wrote: > On Wed 02-10-13 09:20:09, Christoph Hellwig wrote: > >On Wed, Oct 02, 2013 at 04:27:41PM +0200, Jan Kara wrote: > >>Hello, > >> > >>In my quest for changing locking around page faults to make things > >> easier for > >>filesystems I found out get_user_pages() users could use a cleanup. The > >>knowledge about necessary locking for get_user_pages() is in tons of > >>places in > >>drivers and quite a few of them actually get it wrong (don't have > >>mmap_sem when > >>calling get_user_pages() or hold mmap_sem when calling copy_from_user() > >>in the > >>surrounding code). Rather often this actually doesn't seem necessary. > >>This > >>patch series converts lots of places to use either get_user_pages_fast() > >>or a new simple wrapper get_user_pages_unlocked() to remove the > >>knowledge > >>of mmap_sem from the drivers. I'm still looking into converting a few > >>remaining > >>drivers (most notably v4l2) which are more complex. > > > >Even looking over the kerneldoc comment next to it I still fail to > >understand when you'd want to use get_user_pages_fast and when not. > AFAIU get_user_pages_fast() should be used > 1) if you don't need any special get_user_pages() arguments (like calling > it for mm of a different process, forcing COW, or similar). > 2) you don't expect pages to be unmapped (then get_user_pages_fast() is > actually somewhat slower because it walks page tables twice). > >>> > >>>If target page point to anon or private mapping pages, > >>>get_user_pages_fast() > >>>is fork unsafe. O_DIRECT man pages describe a bit about this. > >>> > >>> > >>>see http://man7.org/linux/man-pages/man2/open.2.html > >>> > O_DIRECT I/Os should never be run concurrently with the fork(2) > system call, if the memory buffer is a private mapping (i.e., any > mapping created with the mmap(2) MAP_PRIVATE flag; this includes > memory allocated on the heap and statically allocated buffers). > Any > such I/Os, whether submitted via an asynchronous I/O interface or > from another thread in the process, should be completed before > fork(2) is called. Failure to do so can result in data corruption > and undefined behavior in parent and child processes. This > restriction does not apply when the memory buffer for the O_DIRECT > I/Os was created using shmat(2) or mmap(2) with the MAP_SHARED > flag. > Nor does this restriction apply when the memory buffer has been > advised as MADV_DONTFORK with madvise(2), ensuring that it will not > be available to the child after fork(2). > >> > >>IMHO, get_user_pages_fast() should be renamed to get_user_pages_quirk(). Its > >>semantics is not equal to get_user_pages(). When someone simply substitute > >>get_user_pages() to get_user_pages_fast(), they might see huge trouble. > > I forgot about this speciality (and actually comments didn't remind me > >:(). But thinking about this some more get_user_pages_fast() seems as save > >as get_user_pages() in presence of threads sharing mm, doesn't it? > > It depends. > > If there is any guarantee that other threads don't touch the same page which > retrieved get_user_pages(), get_user_pages_fast() give us brilliant fast way. > Example, as far as I heard form IB guys, the userland library of the > infiniband > stack uses madvise(MADV_DONTFORK), and then they don't need to care COW issue > and can choose fastest way. An another example is a futex. futex doesn't use > the contents of the pages, it uses vaddr only for looking up key. Then, it > also doesn't have COW issue. > > I don't know other cases. But as far as I know, everything is case-by-case. > > >Because > >while get_user_pages() are working, other thread can happilly trigger COW > >on some of the pages and thus get_user_pages() can return pages some of > >which are invisible in our mm by the time get_user_pages() returns. > > If you are talking about get_user_pages() instead of get_user_pages_fast(), > this > can't be happen because page-fault takes mmap_sem too. But both take mmap_sem for reading, so they won't exclude each other... > I would say, mmap_sem has too fat responsibility really. I heartily agree with this. And that makes any changes to it really hard. I've once went through all the places in kernel which acquired mmap_sem. If I remember right, there were close to two hundreds of them! Basic use is the protection of vma tree but then we have less obvious stuff like protection of some other fields in mm_struct, fork exclusion, and god knows what...
[PATCH v4 0/4] Fix Win8 backlight issue
v4: Remove decleration and stub for acpi_video_unregister_backlight in video.h of patch 2/4 since that function doesn't exist anymore in v3. v3: 1 Add a new patch 4/4 to fix some problems in thinkpad-acpi module; 2 Remove unnecessary function acpi_video_unregister_backlight introduced in patch 2/4 as pointed out by Jani Nikula. v2: v1 has the subject of "Rework ACPI video driver" and is posted here: http://lkml.org/lkml/2013/9/9/74 Since the objective is really to fix Win8 backlight issues, I changed the subject in this version, sorry about that. This patchset has four patches, the first introduced a new API named backlight_device_registered in backlight layer that can be used for backlight interface provider module to check if a specific type backlight interface has been registered, see changelog for patch 1/4 for details. Then patch 2/4 does the cleanup to sepeate the backlight control and event delivery functionality in the ACPI video module and patch 3/4 solves some Win8 backlight control problems by avoiding register ACPI video's backlight interface if: 1 Kernel cmdline option acpi_backlight=video is not given; 2 This is a Win8 system; 3 Native backlight control interface exists. Patch 4/4 fixes some problems in thinkpad-acpi module. Technically, patch 2/4 is not required to fix the issue here. So if you think it is not necessary, I can remove it from the series. Aaron Lu (4): backlight: introduce backlight_device_registered ACPI / video: seperate backlight control and event interface ACPI / video: Do not register backlight if win8 and native interface exists thinkpad-acpi: fix handle locate for video and query of _BCL drivers/acpi/internal.h | 5 +- drivers/acpi/video.c | 442 --- drivers/acpi/video_detect.c | 14 +- drivers/platform/x86/thinkpad_acpi.c | 31 ++- drivers/video/backlight/backlight.c | 31 +++ include/linux/backlight.h| 4 + 6 files changed, 322 insertions(+), 205 deletions(-) -- 1.8.4.12.g2ea3df6 ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v4 1/4] backlight: introduce backlight_device_registered
Introduce a new API for modules to query if a specific type of backlight
device has been registered. This is useful for some backlight device
provider module(e.g. ACPI video) to know if a native control
interface(e.g. the interface created by i915) is available and then do
things accordingly(e.g. avoid register its own on Win8 systems).
Signed-off-by: Aaron Lu
Tested-by: Igor Gnatenko
Tested-by: Yves-Alexis Perez
Tested-by: Mika Westerberg
---
drivers/video/backlight/backlight.c | 31 +++
include/linux/backlight.h | 4
2 files changed, 35 insertions(+)
diff --git a/drivers/video/backlight/backlight.c
b/drivers/video/backlight/backlight.c
index 94a403a..bf2d71d 100644
--- a/drivers/video/backlight/backlight.c
+++ b/drivers/video/backlight/backlight.c
@@ -21,6 +21,9 @@
#include
#endif
+static struct list_head bd_list_head;
+static struct mutex bd_list_mutex;
+
static const char *const backlight_types[] = {
[BACKLIGHT_RAW] = "raw",
[BACKLIGHT_PLATFORM] = "platform",
@@ -349,10 +352,32 @@ struct backlight_device *backlight_device_register(const
char *name,
mutex_unlock(&pmac_backlight_mutex);
#endif
+ mutex_lock(&bd_list_mutex);
+ list_add(&new_bd->entry, &bd_list_head);
+ mutex_unlock(&bd_list_mutex);
+
return new_bd;
}
EXPORT_SYMBOL(backlight_device_register);
+bool backlight_device_registered(enum backlight_type type)
+{
+ bool found = false;
+ struct backlight_device *bd;
+
+ mutex_lock(&bd_list_mutex);
+ list_for_each_entry(bd, &bd_list_head, entry) {
+ if (bd->props.type == type) {
+ found = true;
+ break;
+ }
+ }
+ mutex_unlock(&bd_list_mutex);
+
+ return found;
+}
+EXPORT_SYMBOL(backlight_device_registered);
+
/**
* backlight_device_unregister - unregisters a backlight device object.
* @bd: the backlight device object to be unregistered and freed.
@@ -364,6 +389,10 @@ void backlight_device_unregister(struct backlight_device
*bd)
if (!bd)
return;
+ mutex_lock(&bd_list_mutex);
+ list_del(&bd->entry);
+ mutex_unlock(&bd_list_mutex);
+
#ifdef CONFIG_PMAC_BACKLIGHT
mutex_lock(&pmac_backlight_mutex);
if (pmac_backlight == bd)
@@ -499,6 +528,8 @@ static int __init backlight_class_init(void)
backlight_class->dev_groups = bl_device_groups;
backlight_class->pm = &backlight_class_dev_pm_ops;
+ INIT_LIST_HEAD(&bd_list_head);
+ mutex_init(&bd_list_mutex);
return 0;
}
diff --git a/include/linux/backlight.h b/include/linux/backlight.h
index 53b7794..5f9cd96 100644
--- a/include/linux/backlight.h
+++ b/include/linux/backlight.h
@@ -100,6 +100,9 @@ struct backlight_device {
/* The framebuffer notifier block */
struct notifier_block fb_notif;
+ /* list entry of all registered backlight devices */
+ struct list_head entry;
+
struct device dev;
};
@@ -123,6 +126,7 @@ extern void devm_backlight_device_unregister(struct device
*dev,
struct backlight_device *bd);
extern void backlight_force_update(struct backlight_device *bd,
enum backlight_update_reason reason);
+extern bool backlight_device_registered(enum backlight_type type);
#define to_backlight_device(obj) container_of(obj, struct backlight_device,
dev)
--
1.8.4.12.g2ea3df6
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v4 2/4] ACPI / video: seperate backlight control and event interface
The backlight control and event delivery functionality provided by ACPI
video module is mixed together and registered all during video device
enumeration time. As a result, the two functionality are also removed
together on module unload time or by the acpi_video_unregister function.
The two functionalities are actually independent and one may be useful
while the other one may be broken, so it is desirable to seperate the
two functionalities such that it is clear and easy to disable one
functionality without affecting the other one.
APIs to selectively remove backlight control interface and/or event
delivery functionality can be easily added once needed.
Signed-off-by: Aaron Lu
Tested-by: Igor Gnatenko
Tested-by: Yves-Alexis Perez
Tested-by: Mika Westerberg
---
drivers/acpi/video.c | 434 +--
1 file changed, 245 insertions(+), 189 deletions(-)
diff --git a/drivers/acpi/video.c b/drivers/acpi/video.c
index aebcf63..3bd1eaa 100644
--- a/drivers/acpi/video.c
+++ b/drivers/acpi/video.c
@@ -89,6 +89,8 @@ static bool use_bios_initial_backlight = 1;
module_param(use_bios_initial_backlight, bool, 0644);
static int register_count;
+static struct mutex video_list_lock;
+static struct list_head video_bus_head;
static int acpi_video_bus_add(struct acpi_device *device);
static int acpi_video_bus_remove(struct acpi_device *device);
static void acpi_video_bus_notify(struct acpi_device *device, u32 event);
@@ -157,6 +159,7 @@ struct acpi_video_bus {
struct acpi_video_bus_flags flags;
struct list_head video_device_list;
struct mutex device_list_lock; /* protects video_device_list */
+ struct list_head entry;
struct input_dev *input;
char phys[32]; /* for input device */
struct notifier_block pm_nb;
@@ -884,79 +887,6 @@ static void acpi_video_device_find_cap(struct
acpi_video_device *device)
if (acpi_has_method(device->dev->handle, "_DDC"))
device->cap._DDC = 1;
-
- if (acpi_video_backlight_support()) {
- struct backlight_properties props;
- struct pci_dev *pdev;
- acpi_handle acpi_parent;
- struct device *parent = NULL;
- int result;
- static int count;
- char *name;
-
- result = acpi_video_init_brightness(device);
- if (result)
- return;
- name = kasprintf(GFP_KERNEL, "acpi_video%d", count);
- if (!name)
- return;
- count++;
-
- acpi_get_parent(device->dev->handle, &acpi_parent);
-
- pdev = acpi_get_pci_dev(acpi_parent);
- if (pdev) {
- parent = &pdev->dev;
- pci_dev_put(pdev);
- }
-
- memset(&props, 0, sizeof(struct backlight_properties));
- props.type = BACKLIGHT_FIRMWARE;
- props.max_brightness = device->brightness->count - 3;
- device->backlight = backlight_device_register(name,
- parent,
- device,
-
&acpi_backlight_ops,
- &props);
- kfree(name);
- if (IS_ERR(device->backlight))
- return;
-
- /*
-* Save current brightness level in case we have to restore it
-* before acpi_video_device_lcd_set_level() is called next time.
-*/
- device->backlight->props.brightness =
- acpi_video_get_brightness(device->backlight);
-
- device->cooling_dev = thermal_cooling_device_register("LCD",
- device->dev, &video_cooling_ops);
- if (IS_ERR(device->cooling_dev)) {
- /*
-* Set cooling_dev to NULL so we don't crash trying to
-* free it.
-* Also, why the hell we are returning early and
-* not attempt to register video output if cooling
-* device registration failed?
-* -- dtor
-*/
- device->cooling_dev = NULL;
- return;
- }
-
- dev_info(&device->dev->dev, "registered as cooling_device%d\n",
-device->cooling_dev->id);
- result = sysfs_create_link(&device->dev->dev.kobj,
- &device->cooling_dev->device.kobj,
- "thermal_cooling");
- if (result)
- printk(KERN_ERR PREFIX "Create sysfs link\n"
[PATCH v4 3/4] ACPI / video: Do not register backlight if win8 and native interface exists
According to Matthew Garrett, "Windows 8 leaves backlight control up
to individual graphics drivers rather than making ACPI calls itself.
There's plenty of evidence to suggest that the Intel driver for
Windows [8] doesn't use the ACPI interface, including the fact that
it's broken on a bunch of machines when the OS claims to support
Windows 8. The simplest thing to do appears to be to disable the
ACPI backlight interface on these systems".
So for Win8 systems, if there is native backlight control interface
registered by GPU driver, ACPI video will not register its own. For
users who prefer to keep ACPI video's backlight interface, the existing
kernel cmdline option acpi_backlight=video can be used.
Signed-off-by: Aaron Lu
Tested-by: Igor Gnatenko
Tested-by: Yves-Alexis Perez
Tested-by: Mika Westerberg
---
drivers/acpi/internal.h | 5 ++---
drivers/acpi/video.c| 10 +-
drivers/acpi/video_detect.c | 14 --
3 files changed, 19 insertions(+), 10 deletions(-)
diff --git a/drivers/acpi/internal.h b/drivers/acpi/internal.h
index 20f4233..453ae8d 100644
--- a/drivers/acpi/internal.h
+++ b/drivers/acpi/internal.h
@@ -169,9 +169,8 @@ int acpi_create_platform_device(struct acpi_device *adev,
Video
-- */
#if defined(CONFIG_ACPI_VIDEO) || defined(CONFIG_ACPI_VIDEO_MODULE)
-bool acpi_video_backlight_quirks(void);
-#else
-static inline bool acpi_video_backlight_quirks(void) { return false; }
+bool acpi_osi_is_win8(void);
+bool acpi_video_verify_backlight_support(void);
#endif
#endif /* _ACPI_INTERNAL_H_ */
diff --git a/drivers/acpi/video.c b/drivers/acpi/video.c
index 3bd1eaa..343db59 100644
--- a/drivers/acpi/video.c
+++ b/drivers/acpi/video.c
@@ -1256,8 +1256,8 @@ acpi_video_switch_brightness(struct acpi_video_device
*device, int event)
unsigned long long level_current, level_next;
int result = -EINVAL;
- /* no warning message if acpi_backlight=vendor is used */
- if (!acpi_video_backlight_support())
+ /* no warning message if acpi_backlight=vendor or a quirk is used */
+ if (!acpi_video_verify_backlight_support())
return 0;
if (!device->brightness)
@@ -1386,13 +1386,13 @@ acpi_video_bus_get_devices(struct acpi_video_bus *video,
static int acpi_video_bus_start_devices(struct acpi_video_bus *video)
{
return acpi_video_bus_DOS(video, 0,
- acpi_video_backlight_quirks() ? 1 : 0);
+ acpi_osi_is_win8() ? 1 : 0);
}
static int acpi_video_bus_stop_devices(struct acpi_video_bus *video)
{
return acpi_video_bus_DOS(video, 0,
- acpi_video_backlight_quirks() ? 0 : 1);
+ acpi_osi_is_win8() ? 0 : 1);
}
static void acpi_video_bus_notify(struct acpi_device *device, u32 event)
@@ -1558,7 +1558,7 @@ acpi_video_bus_match(acpi_handle handle, u32 level, void
*context,
static void acpi_video_dev_register_backlight(struct acpi_video_device *device)
{
- if (acpi_video_backlight_support()) {
+ if (acpi_video_verify_backlight_support()) {
struct backlight_properties props;
struct pci_dev *pdev;
acpi_handle acpi_parent;
diff --git a/drivers/acpi/video_detect.c b/drivers/acpi/video_detect.c
index 940edbf..23d7d26 100644
--- a/drivers/acpi/video_detect.c
+++ b/drivers/acpi/video_detect.c
@@ -37,6 +37,7 @@
#include
#include
#include
+#include
#include "internal.h"
@@ -233,11 +234,11 @@ static void acpi_video_caps_check(void)
acpi_video_get_capabilities(NULL);
}
-bool acpi_video_backlight_quirks(void)
+bool acpi_osi_is_win8(void)
{
return acpi_gbl_osi_data >= ACPI_OSI_WIN_8;
}
-EXPORT_SYMBOL(acpi_video_backlight_quirks);
+EXPORT_SYMBOL(acpi_osi_is_win8);
/* Promote the vendor interface instead of the generic video module.
* This function allow DMI blacklists to be implemented by externals
@@ -283,6 +284,15 @@ int acpi_video_backlight_support(void)
}
EXPORT_SYMBOL(acpi_video_backlight_support);
+bool acpi_video_verify_backlight_support(void)
+{
+ if (!(acpi_video_support & ACPI_VIDEO_BACKLIGHT_FORCE_VIDEO) &&
+ acpi_osi_is_win8() && backlight_device_registered(BACKLIGHT_RAW))
+ return false;
+ return acpi_video_backlight_support();
+}
+EXPORT_SYMBOL(acpi_video_verify_backlight_support);
+
/*
* Use acpi_backlight=vendor/video to force that backlight switching
* is processed by vendor specific acpi drivers or video.ko driver.
--
1.8.4.12.g2ea3df6
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v4 4/4] thinkpad-acpi: fix handle locate for video and query of _BCL
The tpacpi_acpi_handle_locate function makes use of acpi_get_devices to
locate handle for ACPI video by HID, the problem is, ACPI video node
doesn't really have HID defined(i.e. no _HID control method is defined
for video device), so.. that function would fail. This can be solved by
enhancing the callback function for acpi_get_devices, where we can use
acpi_device_hid function to check if the ACPI node corresponds to a
video controller.
In addition to that, the _BCL control method only exists under a video
output device node, not a video controller device node. So to evaluate
_BCL, we need the handle of a video output device node, which is child
of the located video controller node from tpacpi_acpi_handle_locate.
The two fix are necessary for some Thinkpad models to emit notification
on backlight hotkey press as a result of evaluation of _BCL.
Signed-off-by: Aaron Lu
Tested-by: Igor Gnatenko
Acked-by: Henrique de Moraes Holschuh
---
drivers/platform/x86/thinkpad_acpi.c | 31 ---
1 file changed, 24 insertions(+), 7 deletions(-)
diff --git a/drivers/platform/x86/thinkpad_acpi.c
b/drivers/platform/x86/thinkpad_acpi.c
index 03ca6c1..170f278 100644
--- a/drivers/platform/x86/thinkpad_acpi.c
+++ b/drivers/platform/x86/thinkpad_acpi.c
@@ -700,6 +700,14 @@ static void __init drv_acpi_handle_init(const char *name,
static acpi_status __init tpacpi_acpi_handle_locate_callback(acpi_handle
handle,
u32 level, void *context, void **return_value)
{
+ struct acpi_device *dev;
+ if (!strcmp(context, "video")) {
+ if (acpi_bus_get_device(handle, &dev))
+ return AE_OK;
+ if (strcmp(ACPI_VIDEO_HID, acpi_device_hid(dev)))
+ return AE_OK;
+ }
+
*(acpi_handle *)return_value = handle;
return AE_CTRL_TERMINATE;
@@ -712,10 +720,10 @@ static void __init tpacpi_acpi_handle_locate(const char
*name,
acpi_status status;
acpi_handle device_found;
- BUG_ON(!name || !hid || !handle);
+ BUG_ON(!name || !handle);
vdbg_printk(TPACPI_DBG_INIT,
"trying to locate ACPI handle for %s, using HID %s\n",
- name, hid);
+ name, hid ? hid : "NULL");
memset(&device_found, 0, sizeof(device_found));
status = acpi_get_devices(hid, tpacpi_acpi_handle_locate_callback,
@@ -6090,19 +6098,28 @@ static int __init tpacpi_query_bcl_levels(acpi_handle
handle)
{
struct acpi_buffer buffer = { ACPI_ALLOCATE_BUFFER, NULL };
union acpi_object *obj;
+ struct acpi_device *device, *child;
int rc;
- if (ACPI_SUCCESS(acpi_evaluate_object(handle, "_BCL", NULL, &buffer))) {
+ if (acpi_bus_get_device(handle, &device))
+ return 0;
+
+ rc = 0;
+ list_for_each_entry(child, &device->children, node) {
+ acpi_status status = acpi_evaluate_object(child->handle, "_BCL",
+ NULL, &buffer);
+ if (ACPI_FAILURE(status))
+ continue;
+
obj = (union acpi_object *)buffer.pointer;
if (!obj || (obj->type != ACPI_TYPE_PACKAGE)) {
pr_err("Unknown _BCL data, please report this to %s\n",
- TPACPI_MAIL);
+ TPACPI_MAIL);
rc = 0;
} else {
rc = obj->package.count;
}
- } else {
- return 0;
+ break;
}
kfree(buffer.pointer);
@@ -6118,7 +6135,7 @@ static unsigned int __init
tpacpi_check_std_acpi_brightness_support(void)
acpi_handle video_device;
int bcl_levels = 0;
- tpacpi_acpi_handle_locate("video", ACPI_VIDEO_HID, &video_device);
+ tpacpi_acpi_handle_locate("video", NULL, &video_device);
if (video_device)
bcl_levels = tpacpi_query_bcl_levels(video_device);
--
1.8.4.12.g2ea3df6
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 70035] GPU Lockup on AMD RS880 HD4200
https://bugs.freedesktop.org/show_bug.cgi?id=70035 --- Comment #11 from Tasev --- Hi, Just to report dat i updated my system today to the latest deb's of the oibaff ppa from october 7th 9.3~git1310070927.cfbfb5+glvdpau~gd~p and the system is running ok for now 30 min of use. -- 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 70035] GPU Lockup on AMD RS880 HD4200
https://bugs.freedesktop.org/show_bug.cgi?id=70035 Michel Dänzer changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |DUPLICATE --- Comment #12 from Michel Dänzer --- *** This bug has been marked as a duplicate of bug 69983 *** -- 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 69983] [r600g, bisected] Screen corruption in Firefox, World of Warcraft and other apps
https://bugs.freedesktop.org/show_bug.cgi?id=69983 Michel Dänzer changed: What|Removed |Added CC||tasev.stefano...@skynet.be --- Comment #15 from Michel Dänzer --- *** Bug 70035 has been marked as a duplicate of this bug. *** -- 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 70163] `BUG: unable to handle kernel NULL pointer dereference at 00000064` with `tty_open()`
https://bugs.freedesktop.org/show_bug.cgi?id=70163 --- Comment #1 from Michel Dänzer --- The oops backtrace doesn't look (directly) related to the radeon driver. -- 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: [TIP] Catalyst / fglrx and DVI to HDMI adapters (audio)
Am 08.10.2013 00:14, schrieb Dieter Nützel: Am 07.10.2013 11:22, schrieb Christian König: Am 07.10.2013 10:58, schrieb Rafał Miłecki: 2013/10/7 Christian König : Why didn't you just asked me? I was told on #radeon you're on holidays ;) I was trying to catch you. I'm on vacation right now, but got back yesterday and now greping though my accumulated mails ;) I've figured this out over five years ago by applying brute force to one of the "magic" DVI->HDMI adapters that came with my original RV635. And it indeed contains an extra EEPROM on the I2C bus ;) Did you find any way to workaround this? So I can use my generic adapter with fglrx for audio? Not that I know of any, well those adapters where only used on the early RV6xx HDMI days. IIRC my later RV7xx worked well with the 10meters DVI->HDMI cable fglrx on RV6xx failed. Hello to both of you! Christian, is there any change to get HDMI audio out of my 2 x Dual-Link DVI RV730 AGP ports with one of those adapters (were can I get one) or is the poor little one which came with the gfx card (SAPPHIRE HD 4650 1GB DDR2 AGP) enough? Hi Dieter, for the open source driver you don't need any of those adapters. They are only used by fglrx to identify the "original" adapters that came with the board. So the poor little one which came with the gfx card should be sufficient, but if you want to use fglrx + some other adapter you might run into problems. Christian. Thanks, Dieter PS Rafał, with the right solution I can maybe help you with your investigation ;-) ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 5/5] DRM: Armada: add support for drm tda19988 driver
On Mon, 7 Oct 2013 10:59:39 -0400 Rob Clark wrote: > Jean-François, just as an aside, I really don't think code that can be > shared, like tda998x, should encode a DT requirement.. there are > plenty of platforms that don't use DT (arm isn't everything, and last > I heard aarch64 was going to be ACPI). > > Beyond that, it is a driver decision whether or not to support only-DT > or DT + other.. and as long as there is a common board which can use > the driver but which is not DT, there is probably a compelling reason > to still support the non-DT case. Rob, The Cubox is an open platform, and I use it just like a desktop PC. When its required drivers will be in the mainline, I will do the same as I do with PCs: I will not recompile a specific kernel each time there are kernel bugs or security issues. Instead, I will just upgrade my system from my distributor (Debian), and, in the packages, there will be a generic mvebu kernel as there is already one for Marvell Armada 370/xp, Freescale iMX5x/iMX6 (linux-image-3.10-3-armmp). But, for that, all the Cubox specific stuff must be described in a DT. -- Ken ar c'hentañ | ** Breizh ha Linux atav! ** Jef | http://moinejf.free.fr/ ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 69961] Regression: Xserver fails to start
https://bugs.freedesktop.org/show_bug.cgi?id=69961 --- Comment #6 from samit vats --- Adding gdb backtrace : #0 0x7ffb51141037 in raise () from /lib/x86_64-linux-gnu/libc.so.6 #1 0x7ffb51144698 in abort () from /lib/x86_64-linux-gnu/libc.so.6 #2 0x0056528e in OsAbort () at utils.c:1230 #3 0x0046e91c in ddxGiveUp (error=error@entry=EXIT_ERR_ABORT) at xf86Init.c:936 #4 0x0046e9d9 in AbortDDX (error=error@entry=EXIT_ERR_ABORT) at xf86Init.c:982 #5 0x00569e72 in AbortServer () at log.c:416 #6 0x0056a075 in FatalError (f=f@entry=0x58df90 "Caught signal %d (%s). Server aborting\n") at log.c:547 #7 0x0056320e in OsSigHandler (sip=, signo=11, unused=) at osinit.c:146 #8 OsSigHandler (signo=11, sip=, unused=) at osinit.c:108 #9 #10 0x7ffb4bd34715 in get_r600_target () at radeon_llvm_emit.c:71 #11 radeon_llvm_compile (M=M@entry=0x252b8e0, binary=binary@entry=0x7fff3bc7ff70, gpu_family=0x7ffb4c6e48bc "verde", dump=dump@entry=0) at radeon_llvm_emit.c:108 #12 0x7ffb4bd2553c in si_compile_llvm (rctx=rctx@entry=0x1c68ac0, shader=shader@entry=0x252a140, mod=0x252b8e0) at radeonsi_shader.c:1765 #13 0x7ffb4bd25cfc in si_pipe_shader_create (ctx=ctx@entry=0x1c68ac0, shader=shader@entry=0x252a140) at radeonsi_shader.c:1907 #14 0x7ffb4bd2d262 in si_shader_select (ctx=ctx@entry=0x1c68ac0, sel=sel@entry=0x252a000, dirty=dirty@entry=0x0) at si_state.c:2169 #15 0x7ffb4bd2d5b8 in si_create_shader_state (ctx=0x1c68ac0, state=0x2538f90, pipe_shader_type=1) at si_state.c:2211 #16 0x7ffb4bb7112e in st_translate_fragment_program (st=st@entry=0x1cd2610, stfp=stfp@entry=0x1e655a0, key=key@entry=0x7fff3bc89590) at ../../src/mesa/state_tracker/st_program.c:768 #17 0x7ffb4bb71c3e in st_get_fp_variant (st=0x1cd2610, stfp=0x1e655a0, key=0x7fff3bc89590) at ../../src/mesa/state_tracker/st_program.c:805 #18 0x7ffb4bb3f7e7 in update_fp (st=0x1cd2610) at ../../src/mesa/state_tracker/st_atom_shader.c:92 #19 0x7ffb4bb3c667 in st_validate_state (st=0x1cd2610) at ../../src/mesa/state_tracker/st_atom.c:221 #20 0x7ffb4bb4ff1d in st_draw_vbo (ctx=0x1cf7680, prims=0x7fff3bc896c0, nr_prims=1, ib=0x0, index_bounds_valid=, min_index=0, max_index=3, tfb_vertcount=0x0) at ../../src/mesa/state_tracker/st_draw.c:210 #21 0x7ffb4bb29004 in vbo_draw_arrays (ctx=0x1cf7680, mode=6, start=0, count=4, numInstances=1, baseInstance=) at ../../src/mesa/vbo/vbo_exec_array.c:660 #22 0x7ffb4f7aeccf in _glamor_solid_boxes (pixmap=pixmap@entry=0x2515e80, box=box@entry=0x7fff3bc898d0, nbox=, color=color@entry=0x7fff3bc89850) at glamor_fill.c:245 #23 0x7ffb4f7af215 in glamor_solid_boxes (pixmap=pixmap@entry=0x2515e80, box=box@entry=0x7fff3bc898d0, nbox=nbox@entry=1, fg_pixel=fg_pixel@entry=0) at glamor_fill.c:306 #24 0x7ffb4f7af7b3 in glamor_solid (pixmap=pixmap@entry=0x2515e80, x=x@entry=0, y=y@entry=1024, width=width@entry=1024, height=height@entry=32, alu=alu@entry=3 '\003', planemask=planemask@entry=4294967295, fg_pixel=fg_pixel@entry=0) at glamor_fill.c:348 #25 0x7ffb4f7b34be in clear_mask_cache (maskcache=0x25394f0) at glamor_glyphs.c:169 #26 glamor_realize_glyph_caches (pScreen=0x1d625f0) at glamor_glyphs.c:356 #27 glamor_glyphs_init (pScreen=0x1d625f0) at glamor_glyphs.c:377 #28 0x7ffb4d0d3c65 in radeon_glamor_create_screen_resources (screen=screen@entry=0x1d625f0) at radeon_glamor.c:64 #29 0x7ffb4d0ccec6 in RADEONCreateScreenResources_KMS (pScreen=0x1d625f0) at radeon_kms.c:248 #30 0x0049d867 in xf86CrtcCreateScreenResources (screen=0x1d625f0) at xf86Crtc.c:725 #31 0x00422fbc in main (argc=9, argv=0x7fff3bc89b68, envp=) at main.c:216 -- 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 v2 06/27] gpu: host1x: Cleanup includes
On Tue, Oct 08, 2013 at 08:59:58AM +0300, Terje Bergström wrote: > On 07.10.2013 11:34, Thierry Reding wrote: > > Most of the included files are either not required or already included > > by some other header file. > > What's the general policy? I personally feel that each source file > should #include all the header files it needs, and should not rely on > header files #including other header files. > > This way if header file A stops needing header file B, we don't need to > go and fix all users of header file A that assume B is included. > > I've been hit by this multiple times in Linux kernel - sometimes some > header files just assume another header file is #included and refuses to > compile it it isn't. Explicit includes are probably the safest route when dealing with headers from include/linux, which can be volatile. However, in this case any of the general header files are already included by driver private header files, which are not subject to the same volatility. Or when they change we'll see breakage immediately because pretty much everything about the driver will be rebuilt. It even has the advantage that if a file in include/linux or include/drm changes in a way that breaks compilation, we only have to change one of the driver private headers instead of all source files. Thierry pgpeO4C_MyRam.pgp Description: PGP signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 13/27] drm/tegra: Move subdevice infrastructure to host1x
On Tue, Oct 08, 2013 at 09:25:39AM +0300, Terje Bergström wrote: > On 07.10.2013 11:34, Thierry Reding wrote: > > The Tegra DRM driver currently uses some infrastructure to defer the DRM > > core initialization until all required devices have registered. The same > > infrastructure can potentially be used by any other driver that requires > > more than a single sub-device of the host1x module. > > > > Make the infrastructure more generic and keep only the DRM specific code > > in the DRM part of the driver. Eventually this will make it easy to move > > the DRM driver part back to the DRM subsystem. > > Do we need the host1x_client/tegra_drm_client concept outside DRM? You > separated the two in an earlier patch, but the whole structure is there > because of limitation in DRM. Shouldn't we keep management of drm > clients entirely inside drm? The DRM specific parts are still all managed within the DRM driver. However the host1x_client API, and specifically the method in which sub-devices can be registered (host1x_client to host1x_device) is completely subsystem agnostic. That part can be used subsequently by things such as a V4L2 driver to achieve the same thing we've done with Tegra DRM, namely to use several sub-devices collectively to provide the functionality of a "composite" device (VI/CSI). > Second, do we need an own drm_bus for host1x clients? Does it bring > something drm_platform doesn't? I couldn't see any immediate difference > between the two. The difference is in that we pass in a host1x_device, which is not a platform device, but really just a wrapped struct device. That in turn provides the whole composite device infrastructure. So, no, it can't be done with drm_platform. Thierry pgpktsf5bBusU.pgp Description: PGP signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] gpu: host1x: check relocs after all gathers are consumed
On 04.10.2013 23:18, Erik Faye-Lund wrote: > The num_relocs count are passed to the kernel per job, not per gather. > > For multi-gather jobs, we would previously fail if there were relocs in > other gathers aside from the first one. > > Fix this by simply moving the check until all gathers have been > consumed. > > Signed-off-by: Erik Faye-Lund > --- > drivers/gpu/host1x/job.c |8 > 1 file changed, 4 insertions(+), 4 deletions(-) > > diff --git a/drivers/gpu/host1x/job.c b/drivers/gpu/host1x/job.c > index c4e1050..c9ddff8 100644 > --- a/drivers/gpu/host1x/job.c > +++ b/drivers/gpu/host1x/job.c > @@ -436,10 +436,6 @@ static int validate(struct host1x_firewall *fw, struct > host1x_job_gather *g) > } > } > > - /* No relocs should remain at this point */ > - if (fw->num_relocs) > - err = -EINVAL; > - > out: > return err; > } > @@ -493,6 +489,10 @@ static inline int copy_gathers(struct host1x_job *job, > struct device *dev) > offset += g->words * sizeof(u32); > } > > + /* No relocs should remain at this point */ > + if (fw.num_relocs) > + return -EINVAL; > + > return 0; > } Good catch. Acked-By: Terje Bergstrom Terje ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 08/27] drm/tegra: gr2d: Miscellaneous cleanups
On Tue, Oct 8, 2013 at 7:48 AM, Terje Bergström wrote: > On 07.10.2013 16:02, Erik Faye-Lund wrote: >> So the question is really how the hardware treats writes to >> non-existent registers. My guess would be that they are simply not >> recorded, and if that's the case it doesn't matter what we do. And >> doing an unconditional AND is faster than doing a bit-test followed by >> a conditional branch. > > Hardware ignores writes to non-existent registers. Sometimes > non-existent registers are taken into use in future versions, though. Right. That might be a motivation to treat non-existent registers as errors. But then I start to wonder about "holes" in the pointer address space should be treated differently. For instance, from the TRM it looks like registers 0x3 - 0x8, 0xe, 0x15 and 0x42 are undefined for T20. If writes to registers beyond 0x4c fails, shouldn't these also fail? Or are somehow guaranteed that these holes will never be plugged? Are they simply missing from the TRM? I dunno... ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 70219] [radeon] Cannot restore video mode after vt switch or GPU lockup
https://bugs.freedesktop.org/show_bug.cgi?id=70219 --- Comment #2 from Sergej Pupykin --- Created attachment 87272 --> https://bugs.freedesktop.org/attachment.cgi?id=87272&action=edit dmesg -- 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 70219] [radeon] Cannot restore video mode after vt switch or GPU lockup
https://bugs.freedesktop.org/show_bug.cgi?id=70219 --- Comment #3 from Sergej Pupykin --- Created attachment 87273 --> https://bugs.freedesktop.org/attachment.cgi?id=87273&action=edit Xorg.log -- 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] gpu: host1x: check relocs after all gathers are consumed
On Fri, Oct 04, 2013 at 08:18:33PM +, Erik Faye-Lund wrote: > The num_relocs count are passed to the kernel per job, not per gather. > > For multi-gather jobs, we would previously fail if there were relocs in > other gathers aside from the first one. > > Fix this by simply moving the check until all gathers have been > consumed. > > Signed-off-by: Erik Faye-Lund > --- > drivers/gpu/host1x/job.c |8 > 1 file changed, 4 insertions(+), 4 deletions(-) Applied, thanks. Thierry pgpLuiB5DyILZ.pgp Description: PGP signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 5/5] DRM: Armada: add support for drm tda19988 driver
On Tue, Oct 8, 2013 at 5:19 AM, Jean-Francois Moine wrote: > On Mon, 7 Oct 2013 10:59:39 -0400 > Rob Clark wrote: > >> Jean-François, just as an aside, I really don't think code that can be >> shared, like tda998x, should encode a DT requirement.. there are >> plenty of platforms that don't use DT (arm isn't everything, and last >> I heard aarch64 was going to be ACPI). >> >> Beyond that, it is a driver decision whether or not to support only-DT >> or DT + other.. and as long as there is a common board which can use >> the driver but which is not DT, there is probably a compelling reason >> to still support the non-DT case. > > Rob, > > The Cubox is an open platform, and I use it just like a desktop PC. > When its required drivers will be in the mainline, I will do the same > as I do with PCs: I will not recompile a specific kernel each time > there are kernel bugs or security issues. Instead, I will just upgrade > my system from my distributor (Debian), and, in the packages, there > will be a generic mvebu kernel as there is already one for Marvell > Armada 370/xp, Freescale iMX5x/iMX6 (linux-image-3.10-3-armmp). > But, for that, all the Cubox specific stuff must be described in a DT. sure, I'm not saying *not* to support DT (send patches if need be). I'm just saying that it should be ok to also support non-DT case and that shared components (like tda998x) should also still work in non-DT case. BR, -R > -- > Ken ar c'hentañ | ** Breizh ha Linux atav! ** > Jef | http://moinejf.free.fr/ ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/exynos: fimd: clean up pm suspend/resume
This patch removes unnecessary runtime pm related function calls
from fimd_suspend and fimd_resume functions.
Signed-off-by: Inki Dae
Signed-off-by: Kyungmin Park
---
drivers/gpu/drm/exynos/exynos_drm_fimd.c | 38 +-
1 file changed, 11 insertions(+), 27 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
index 868a14d..81f3521 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
@@ -1003,41 +1003,25 @@ static int fimd_suspend(struct device *dev)
{
struct fimd_context *ctx = get_fimd_context(dev);
- /*
-* do not use pm_runtime_suspend(). if pm_runtime_suspend() is
-* called here, an error would be returned by that interface
-* because the usage_count of pm runtime is more than 1.
-*/
- if (!pm_runtime_suspended(dev))
- return fimd_activate(ctx, false);
-
- return 0;
+ return fimd_activate(ctx, false);
}
static int fimd_resume(struct device *dev)
{
struct fimd_context *ctx = get_fimd_context(dev);
+ int ret;
+
+ ret = fimd_activate(ctx, true);
+ if (ret < 0)
+ return ret;
/*
-* if entered to sleep when lcd panel was on, the usage_count
-* of pm runtime would still be 1 so in this case, fimd driver
-* should be on directly not drawing on pm runtime interface.
+* in case of dpms on(standby), fimd_apply function will
+* be called by encoder's dpms callback to update fimd's
+* registers but in case of sleep wakeup, it's not.
+* so fimd_apply function should be called at here.
*/
- if (!pm_runtime_suspended(dev)) {
- int ret;
-
- ret = fimd_activate(ctx, true);
- if (ret < 0)
- return ret;
-
- /*
-* in case of dpms on(standby), fimd_apply function will
-* be called by encoder's dpms callback to update fimd's
-* registers but in case of sleep wakeup, it's not.
-* so fimd_apply function should be called at here.
-*/
- fimd_apply(dev);
- }
+ fimd_apply(dev);
return 0;
}
--
1.7.9.5
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 62721] New: GPU lockup: radeon 0000:01:00.0: GPU lockup CP stall for more than 10000msec...
https://bugzilla.kernel.org/show_bug.cgi?id=62721 Bug ID: 62721 Summary: GPU lockup: radeon :01:00.0: GPU lockup CP stall for more than 1msec... Product: Drivers Version: 2.5 Kernel Version: 3.11.4 Hardware: All OS: Linux Tree: Mainline Status: NEW Severity: normal Priority: P1 Component: Video(DRI - non Intel) Assignee: drivers_video-...@kernel-bugs.osdl.org Reporter: egorov_e...@bk.ru Regression: No After update kernel to 3.11.4 my system randomize hands: Oct 08 19:09:32 localhost kernel: radeon :01:00.0: GPU lockup CP stall for more than 1msec Oct 08 19:09:32 localhost kernel: radeon :01:00.0: GPU lockup (waiting for 0xa2f1 last fence id 0xa2f0) Oct 08 19:09:32 localhost kernel: Failed to wait GUI idle while programming pipes. Bad things might happen. Oct 08 19:09:32 localhost kernel: radeon :01:00.0: Saved 27 dwords of commands on ring 0. Oct 08 19:09:33 localhost kernel: radeon :01:00.0: (rs600_asic_reset:401) RBBM_STATUS=0xD4110140 Oct 08 19:09:33 localhost kernel: radeon :01:00.0: (rs600_asic_reset:421) RBBM_STATUS=0x90010140 Oct 08 19:09:34 localhost kernel: radeon :01:00.0: (rs600_asic_reset:429) RBBM_STATUS=0x1140 Oct 08 19:09:34 localhost kernel: radeon :01:00.0: (rs600_asic_reset:437) RBBM_STATUS=0x1140 Oct 08 19:09:34 localhost kernel: radeon :01:00.0: GPU reset succeed Oct 08 19:09:34 localhost kernel: radeon :01:00.0: GPU reset succeeded, trying to resume Oct 08 19:09:34 localhost kernel: radeon :01:00.0: 880224f0f800 unpin not necessary Oct 08 19:09:39 localhost kernel: [drm:atom_op_jump] *ERROR* atombios stuck in loop for more than 5secs aborting Oct 08 19:09:39 localhost kernel: [drm:atom_execute_table_locked] *ERROR* atombios stuck executing BA17 (len 676, WS 4, PS 0) @ 0xBC1E Oct 08 19:09:39 localhost kernel: [drm:atom_execute_table_locked] *ERROR* atombios stuck executing B948 (len 200, WS 0, PS 8) @ 0xB950 Oct 08 19:09:39 localhost kernel: Failed to wait GUI idle while programming pipes. Bad things might happen. Oct 08 19:09:39 localhost kernel: [drm] radeon: 3 quad pipes, 1 z pipes initialized. Oct 08 19:09:40 localhost kernel: Failed to wait MC idle while programming pipes. Bad things might happen. Oct 08 19:09:40 localhost kernel: [drm] PCIE GART of 512M enabled (table at 0x0004). Oct 08 19:09:40 localhost kernel: radeon :01:00.0: WB enabled Oct 08 19:09:40 localhost kernel: radeon :01:00.0: fence driver on ring 0 use gpu addr 0x1000 and cpu addr 0x880224965000 Oct 08 19:09:40 localhost kernel: [drm] radeon: ring at 0x10001000 Oct 08 19:09:40 localhost kernel: [drm:r100_ring_test] *ERROR* radeon: ring test failed (scratch(0x15E8)=0xCAFEDEAD) Oct 08 19:09:40 localhost kernel: [drm:r100_cp_init] *ERROR* radeon: cp isn't working (-22). Oct 08 19:09:40 localhost kernel: radeon :01:00.0: failed initializing CP (-22). after revert commit cb51bb7107aa040f9779be931e3bd6a7b50e0f69 all works fine. -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 62721] GPU lockup: radeon 0000:01:00.0: GPU lockup CP stall for more than 10000msec...
https://bugzilla.kernel.org/show_bug.cgi?id=62721 --- Comment #1 from Egor Y. Egorov --- Created attachment 110451 --> https://bugzilla.kernel.org/attachment.cgi?id=110451&action=edit journalctl -a LC_ALL=C journalctl -a --since='2013-10-08 19:04:00' --until='2013-10-08 19:11:00' -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[RFC PATCH] drm/radeon: fixup locking inversion between mmap_sem and reservations
Allocate and copy all kernel memory before doing reservations. This prevents a
locking
inversion between mmap_sem and reservation_class, and allows us to drop the
trylocking
in ttm_bo_vm_fault without upsetting lockdep.
Signed-off-by: Maarten Lankhorst
---
diff --git a/drivers/gpu/drm/radeon/r600_cs.c b/drivers/gpu/drm/radeon/r600_cs.c
index 01a3ec8..efa9bca 100644
--- a/drivers/gpu/drm/radeon/r600_cs.c
+++ b/drivers/gpu/drm/radeon/r600_cs.c
@@ -2391,18 +2391,13 @@ int r600_cs_legacy(struct drm_device *dev, void *data,
struct drm_file *filp,
ib_chunk = &parser.chunks[parser.chunk_ib_idx];
parser.ib.length_dw = ib_chunk->length_dw;
*l = parser.ib.length_dw;
+ memcpy(ib, ib_chunk->kdata, ib_chunk->length_dw * 4);
r = r600_cs_parse(&parser);
if (r) {
DRM_ERROR("Invalid command stream !\n");
r600_cs_parser_fini(&parser, r);
return r;
}
- r = radeon_cs_finish_pages(&parser);
- if (r) {
- DRM_ERROR("Invalid command stream !\n");
- r600_cs_parser_fini(&parser, r);
- return r;
- }
r600_cs_parser_fini(&parser, r);
return r;
}
diff --git a/drivers/gpu/drm/radeon/radeon.h b/drivers/gpu/drm/radeon/radeon.h
index e067024..c52bb5e 100644
--- a/drivers/gpu/drm/radeon/radeon.h
+++ b/drivers/gpu/drm/radeon/radeon.h
@@ -983,12 +983,7 @@ struct radeon_cs_reloc {
struct radeon_cs_chunk {
uint32_tchunk_id;
uint32_tlength_dw;
- int kpage_idx[2];
- uint32_t*kpage[2];
uint32_t*kdata;
- void __user *user_ptr;
- int last_copied_page;
- int last_page_index;
};
struct radeon_cs_parser {
@@ -1027,8 +1022,13 @@ struct radeon_cs_parser {
struct radeon_sa_bo *cpu_sema;
};
-extern int radeon_cs_finish_pages(struct radeon_cs_parser *p);
-extern u32 radeon_get_ib_value(struct radeon_cs_parser *p, int idx);
+static inline u32 radeon_get_ib_value(struct radeon_cs_parser *p, int idx)
+{
+ struct radeon_cs_chunk *ibc = &p->chunks[p->chunk_ib_idx];
+
+ return ibc->kdata[idx];
+}
+
struct radeon_cs_packet {
unsignedidx;
diff --git a/drivers/gpu/drm/radeon/radeon_cs.c
b/drivers/gpu/drm/radeon/radeon_cs.c
index 7d7322e..98d8898 100644
--- a/drivers/gpu/drm/radeon/radeon_cs.c
+++ b/drivers/gpu/drm/radeon/radeon_cs.c
@@ -217,9 +217,7 @@ int radeon_cs_parser_init(struct radeon_cs_parser *p, void
*data)
return -EFAULT;
}
p->chunks[i].length_dw = user_chunk.length_dw;
- p->chunks[i].kdata = NULL;
p->chunks[i].chunk_id = user_chunk.chunk_id;
- p->chunks[i].user_ptr = (void __user *)(unsigned
long)user_chunk.chunk_data;
if (p->chunks[i].chunk_id == RADEON_CHUNK_ID_RELOCS) {
p->chunk_relocs_idx = i;
}
@@ -242,25 +240,22 @@ int radeon_cs_parser_init(struct radeon_cs_parser *p,
void *data)
return -EINVAL;
}
- cdata = (uint32_t *)(unsigned long)user_chunk.chunk_data;
- if ((p->chunks[i].chunk_id == RADEON_CHUNK_ID_RELOCS) ||
- (p->chunks[i].chunk_id == RADEON_CHUNK_ID_FLAGS)) {
- size = p->chunks[i].length_dw * sizeof(uint32_t);
- p->chunks[i].kdata = kmalloc(size, GFP_KERNEL);
- if (p->chunks[i].kdata == NULL) {
- return -ENOMEM;
- }
- if (DRM_COPY_FROM_USER(p->chunks[i].kdata,
- p->chunks[i].user_ptr, size)) {
- return -EFAULT;
- }
- if (p->chunks[i].chunk_id == RADEON_CHUNK_ID_FLAGS) {
- p->cs_flags = p->chunks[i].kdata[0];
- if (p->chunks[i].length_dw > 1)
- ring = p->chunks[i].kdata[1];
- if (p->chunks[i].length_dw > 2)
- priority = (s32)p->chunks[i].kdata[2];
- }
+ size = p->chunks[i].length_dw;
+ p->chunks[i].kdata = drm_malloc_ab(size, sizeof(uint32_t));
+ size *= sizeof(uint32_t);
+ if (p->chunks[i].kdata == NULL) {
+ return -ENOMEM;
+ }
+ cdata = (void __user *)(unsigned long)user_chunk.chunk_data;
+ if (DRM_COPY_FROM_USER(p->chunks[i].kdata, cdata, size)) {
+ return -EFAULT;
+ }
+ if (p->chunks[i].chunk_id == RADEON_CHUNK_ID_FLAGS) {
+ p->cs_flags = p->c
Re: [RFC PATCH] drm/radeon: fixup locking inversion between mmap_sem and reservations
On Tue, Oct 08, 2013 at 04:14:40PM +0200, Maarten Lankhorst wrote:
> Allocate and copy all kernel memory before doing reservations. This prevents
> a locking
> inversion between mmap_sem and reservation_class, and allows us to drop the
> trylocking
> in ttm_bo_vm_fault without upsetting lockdep.
>
> Signed-off-by: Maarten Lankhorst
I would say NAK. Current code only allocate temporary page in AGP case.
So AGP case is userspace -> temp page -> cs checker -> radeon ib.
Non AGP is directly memcpy to radeon IB.
Your patch allocate memory memcpy userspace to it and it will then be
memcpy to IB. Which means you introduce an extra memcpy in the process
not something we want.
Cheers,
Jerome
> ---
> diff --git a/drivers/gpu/drm/radeon/r600_cs.c
> b/drivers/gpu/drm/radeon/r600_cs.c
> index 01a3ec8..efa9bca 100644
> --- a/drivers/gpu/drm/radeon/r600_cs.c
> +++ b/drivers/gpu/drm/radeon/r600_cs.c
> @@ -2391,18 +2391,13 @@ int r600_cs_legacy(struct drm_device *dev, void
> *data, struct drm_file *filp,
> ib_chunk = &parser.chunks[parser.chunk_ib_idx];
> parser.ib.length_dw = ib_chunk->length_dw;
> *l = parser.ib.length_dw;
> + memcpy(ib, ib_chunk->kdata, ib_chunk->length_dw * 4);
> r = r600_cs_parse(&parser);
> if (r) {
> DRM_ERROR("Invalid command stream !\n");
> r600_cs_parser_fini(&parser, r);
> return r;
> }
> - r = radeon_cs_finish_pages(&parser);
> - if (r) {
> - DRM_ERROR("Invalid command stream !\n");
> - r600_cs_parser_fini(&parser, r);
> - return r;
> - }
> r600_cs_parser_fini(&parser, r);
> return r;
> }
> diff --git a/drivers/gpu/drm/radeon/radeon.h b/drivers/gpu/drm/radeon/radeon.h
> index e067024..c52bb5e 100644
> --- a/drivers/gpu/drm/radeon/radeon.h
> +++ b/drivers/gpu/drm/radeon/radeon.h
> @@ -983,12 +983,7 @@ struct radeon_cs_reloc {
> struct radeon_cs_chunk {
> uint32_tchunk_id;
> uint32_tlength_dw;
> - int kpage_idx[2];
> - uint32_t*kpage[2];
> uint32_t*kdata;
> - void __user *user_ptr;
> - int last_copied_page;
> - int last_page_index;
> };
>
> struct radeon_cs_parser {
> @@ -1027,8 +1022,13 @@ struct radeon_cs_parser {
> struct radeon_sa_bo *cpu_sema;
> };
>
> -extern int radeon_cs_finish_pages(struct radeon_cs_parser *p);
> -extern u32 radeon_get_ib_value(struct radeon_cs_parser *p, int idx);
> +static inline u32 radeon_get_ib_value(struct radeon_cs_parser *p, int idx)
> +{
> + struct radeon_cs_chunk *ibc = &p->chunks[p->chunk_ib_idx];
> +
> + return ibc->kdata[idx];
> +}
> +
>
> struct radeon_cs_packet {
> unsignedidx;
> diff --git a/drivers/gpu/drm/radeon/radeon_cs.c
> b/drivers/gpu/drm/radeon/radeon_cs.c
> index 7d7322e..98d8898 100644
> --- a/drivers/gpu/drm/radeon/radeon_cs.c
> +++ b/drivers/gpu/drm/radeon/radeon_cs.c
> @@ -217,9 +217,7 @@ int radeon_cs_parser_init(struct radeon_cs_parser *p,
> void *data)
> return -EFAULT;
> }
> p->chunks[i].length_dw = user_chunk.length_dw;
> - p->chunks[i].kdata = NULL;
> p->chunks[i].chunk_id = user_chunk.chunk_id;
> - p->chunks[i].user_ptr = (void __user *)(unsigned
> long)user_chunk.chunk_data;
> if (p->chunks[i].chunk_id == RADEON_CHUNK_ID_RELOCS) {
> p->chunk_relocs_idx = i;
> }
> @@ -242,25 +240,22 @@ int radeon_cs_parser_init(struct radeon_cs_parser *p,
> void *data)
> return -EINVAL;
> }
>
> - cdata = (uint32_t *)(unsigned long)user_chunk.chunk_data;
> - if ((p->chunks[i].chunk_id == RADEON_CHUNK_ID_RELOCS) ||
> - (p->chunks[i].chunk_id == RADEON_CHUNK_ID_FLAGS)) {
> - size = p->chunks[i].length_dw * sizeof(uint32_t);
> - p->chunks[i].kdata = kmalloc(size, GFP_KERNEL);
> - if (p->chunks[i].kdata == NULL) {
> - return -ENOMEM;
> - }
> - if (DRM_COPY_FROM_USER(p->chunks[i].kdata,
> -p->chunks[i].user_ptr, size)) {
> - return -EFAULT;
> - }
> - if (p->chunks[i].chunk_id == RADEON_CHUNK_ID_FLAGS) {
> - p->cs_flags = p->chunks[i].kdata[0];
> - if (p->chunks[i].length_dw > 1)
> - ring = p->chunks[i].kdata[1];
> - if (p->chunks[i].length_dw > 2)
> - priority = (s32)p->chunks[i].kdata[2];
> - }
> + size = p->chunks[i].length_dw;
> + p->ch
Re: [RFC PATCH] drm/radeon: fixup locking inversion between mmap_sem and reservations
Am 08.10.2013 16:33, schrieb Jerome Glisse:
On Tue, Oct 08, 2013 at 04:14:40PM +0200, Maarten Lankhorst wrote:
Allocate and copy all kernel memory before doing reservations. This prevents a
locking
inversion between mmap_sem and reservation_class, and allows us to drop the
trylocking
in ttm_bo_vm_fault without upsetting lockdep.
Signed-off-by: Maarten Lankhorst
I would say NAK. Current code only allocate temporary page in AGP case.
So AGP case is userspace -> temp page -> cs checker -> radeon ib.
Non AGP is directly memcpy to radeon IB.
Your patch allocate memory memcpy userspace to it and it will then be
memcpy to IB. Which means you introduce an extra memcpy in the process
not something we want.
Totally agree. Additional to that there is no good reason to provide
anything else than anonymous system memory to the CS ioctl, so the
dependency between the mmap_sem and reservations are not really clear to me.
Christian.
Cheers,
Jerome
---
diff --git a/drivers/gpu/drm/radeon/r600_cs.c b/drivers/gpu/drm/radeon/r600_cs.c
index 01a3ec8..efa9bca 100644
--- a/drivers/gpu/drm/radeon/r600_cs.c
+++ b/drivers/gpu/drm/radeon/r600_cs.c
@@ -2391,18 +2391,13 @@ int r600_cs_legacy(struct drm_device *dev, void *data,
struct drm_file *filp,
ib_chunk = &parser.chunks[parser.chunk_ib_idx];
parser.ib.length_dw = ib_chunk->length_dw;
*l = parser.ib.length_dw;
+ memcpy(ib, ib_chunk->kdata, ib_chunk->length_dw * 4);
r = r600_cs_parse(&parser);
if (r) {
DRM_ERROR("Invalid command stream !\n");
r600_cs_parser_fini(&parser, r);
return r;
}
- r = radeon_cs_finish_pages(&parser);
- if (r) {
- DRM_ERROR("Invalid command stream !\n");
- r600_cs_parser_fini(&parser, r);
- return r;
- }
r600_cs_parser_fini(&parser, r);
return r;
}
diff --git a/drivers/gpu/drm/radeon/radeon.h b/drivers/gpu/drm/radeon/radeon.h
index e067024..c52bb5e 100644
--- a/drivers/gpu/drm/radeon/radeon.h
+++ b/drivers/gpu/drm/radeon/radeon.h
@@ -983,12 +983,7 @@ struct radeon_cs_reloc {
struct radeon_cs_chunk {
uint32_tchunk_id;
uint32_tlength_dw;
- int kpage_idx[2];
- uint32_t*kpage[2];
uint32_t*kdata;
- void __user *user_ptr;
- int last_copied_page;
- int last_page_index;
};
struct radeon_cs_parser {
@@ -1027,8 +1022,13 @@ struct radeon_cs_parser {
struct radeon_sa_bo *cpu_sema;
};
-extern int radeon_cs_finish_pages(struct radeon_cs_parser *p);
-extern u32 radeon_get_ib_value(struct radeon_cs_parser *p, int idx);
+static inline u32 radeon_get_ib_value(struct radeon_cs_parser *p, int idx)
+{
+ struct radeon_cs_chunk *ibc = &p->chunks[p->chunk_ib_idx];
+
+ return ibc->kdata[idx];
+}
+
struct radeon_cs_packet {
unsignedidx;
diff --git a/drivers/gpu/drm/radeon/radeon_cs.c
b/drivers/gpu/drm/radeon/radeon_cs.c
index 7d7322e..98d8898 100644
--- a/drivers/gpu/drm/radeon/radeon_cs.c
+++ b/drivers/gpu/drm/radeon/radeon_cs.c
@@ -217,9 +217,7 @@ int radeon_cs_parser_init(struct radeon_cs_parser *p, void
*data)
return -EFAULT;
}
p->chunks[i].length_dw = user_chunk.length_dw;
- p->chunks[i].kdata = NULL;
p->chunks[i].chunk_id = user_chunk.chunk_id;
- p->chunks[i].user_ptr = (void __user *)(unsigned
long)user_chunk.chunk_data;
if (p->chunks[i].chunk_id == RADEON_CHUNK_ID_RELOCS) {
p->chunk_relocs_idx = i;
}
@@ -242,25 +240,22 @@ int radeon_cs_parser_init(struct radeon_cs_parser *p,
void *data)
return -EINVAL;
}
- cdata = (uint32_t *)(unsigned long)user_chunk.chunk_data;
- if ((p->chunks[i].chunk_id == RADEON_CHUNK_ID_RELOCS) ||
- (p->chunks[i].chunk_id == RADEON_CHUNK_ID_FLAGS)) {
- size = p->chunks[i].length_dw * sizeof(uint32_t);
- p->chunks[i].kdata = kmalloc(size, GFP_KERNEL);
- if (p->chunks[i].kdata == NULL) {
- return -ENOMEM;
- }
- if (DRM_COPY_FROM_USER(p->chunks[i].kdata,
- p->chunks[i].user_ptr, size)) {
- return -EFAULT;
- }
- if (p->chunks[i].chunk_id == RADEON_CHUNK_ID_FLAGS) {
- p->cs_flags = p->chunks[i].kdata[0];
- if (p->chunks[i].length_dw > 1)
- ring = p->chunks[i].kdata[1];
- if (p->chunks[i].lengt
Re: [RFC PATCH] drm/radeon: fixup locking inversion between mmap_sem and reservations
op 08-10-13 16:33, Jerome Glisse schreef: > On Tue, Oct 08, 2013 at 04:14:40PM +0200, Maarten Lankhorst wrote: >> Allocate and copy all kernel memory before doing reservations. This prevents >> a locking >> inversion between mmap_sem and reservation_class, and allows us to drop the >> trylocking >> in ttm_bo_vm_fault without upsetting lockdep. >> >> Signed-off-by: Maarten Lankhorst > I would say NAK. Current code only allocate temporary page in AGP case. > So AGP case is userspace -> temp page -> cs checker -> radeon ib. > > Non AGP is directly memcpy to radeon IB. > > Your patch allocate memory memcpy userspace to it and it will then be > memcpy to IB. Which means you introduce an extra memcpy in the process > not something we want. > Can we move up the call to radeon_ib_get then to be done before calling radeon_cs_parser_relocs? ~Maarten ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] SHMOBILE: DRM: Fix backlight_device register and unregister undefined errors.
Hi Majunath, Thank you for the patch. On Tuesday 08 October 2013 16:09:17 Majunath Goudar wrote: > This patch adds a BACKLIGHT_CLASS_DEVICE dependency to configure the > DRM_SHMOBILE. Without this patch, build system can lead to build failure. > This was observed during randconfig testing, in which DRM_SHMOBILE was > enabled w/o BACKLIGHT_CLASS_DEVICE being enabled. Following was the error: > > Building modules, stage 2. > MODPOST 516 modules > ERROR: "backlight_device_register" [drivers/gpu/drm/shmobile/shmob-drm.ko] > undefined! ERROR: "backlight_device_unregister" > [drivers/gpu/drm/shmobile/shmob-drm.ko] undefined! make[1]: *** [__modpost] > Error 1 > make: *** [modules] Error 2 > > Signed-off-by: Manjunath Goudar > Cc: David Airlie > Cc: Laurent Pinchart > Cc: Sascha Hauer > Cc: dri-devel@lists.freedesktop.org > Cc: linux-ker...@vger.kernel.org > --- > drivers/gpu/drm/shmobile/Kconfig |2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/gpu/drm/shmobile/Kconfig > b/drivers/gpu/drm/shmobile/Kconfig index ca498d1..eaf822e 100644 > --- a/drivers/gpu/drm/shmobile/Kconfig > +++ b/drivers/gpu/drm/shmobile/Kconfig > @@ -1,6 +1,6 @@ > config DRM_SHMOBILE > tristate "DRM Support for SH Mobile" > - depends on DRM && (ARM || SUPERH) > + depends on DRM && (ARM || SUPERH) && BACKLIGHT_CLASS_DEVICE What about select BACKLIGHT_CLASS_DEVICE instead ? That's what the i915, radeon, gma500, tilcdc and nouveau drivers do. > select DRM_KMS_HELPER > select DRM_KMS_CMA_HELPER > select DRM_GEM_CMA_HELPER -- Regards, Laurent Pinchart ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC PATCH] drm/radeon: fixup locking inversion between mmap_sem and reservations
On Tue, Oct 08, 2013 at 04:45:18PM +0200, Christian König wrote:
> Am 08.10.2013 16:33, schrieb Jerome Glisse:
> >On Tue, Oct 08, 2013 at 04:14:40PM +0200, Maarten Lankhorst wrote:
> >>Allocate and copy all kernel memory before doing reservations. This
> >>prevents a locking
> >>inversion between mmap_sem and reservation_class, and allows us to drop the
> >>trylocking
> >>in ttm_bo_vm_fault without upsetting lockdep.
> >>
> >>Signed-off-by: Maarten Lankhorst
> >I would say NAK. Current code only allocate temporary page in AGP case.
> >So AGP case is userspace -> temp page -> cs checker -> radeon ib.
> >
> >Non AGP is directly memcpy to radeon IB.
> >
> >Your patch allocate memory memcpy userspace to it and it will then be
> >memcpy to IB. Which means you introduce an extra memcpy in the process
> >not something we want.
>
> Totally agree. Additional to that there is no good reason to provide
> anything else than anonymous system memory to the CS ioctl, so the
> dependency between the mmap_sem and reservations are not really
> clear to me.
>
> Christian.
I think is that in other code path you take mmap_sem first then reserve
bo. But here we reserve bo and then we take mmap_sem because of copy
from user.
Cheers,
Jerome
>
> >Cheers,
> >Jerome
> >
> >>---
> >>diff --git a/drivers/gpu/drm/radeon/r600_cs.c
> >>b/drivers/gpu/drm/radeon/r600_cs.c
> >>index 01a3ec8..efa9bca 100644
> >>--- a/drivers/gpu/drm/radeon/r600_cs.c
> >>+++ b/drivers/gpu/drm/radeon/r600_cs.c
> >>@@ -2391,18 +2391,13 @@ int r600_cs_legacy(struct drm_device *dev, void
> >>*data, struct drm_file *filp,
> >>ib_chunk = &parser.chunks[parser.chunk_ib_idx];
> >>parser.ib.length_dw = ib_chunk->length_dw;
> >>*l = parser.ib.length_dw;
> >>+ memcpy(ib, ib_chunk->kdata, ib_chunk->length_dw * 4);
> >>r = r600_cs_parse(&parser);
> >>if (r) {
> >>DRM_ERROR("Invalid command stream !\n");
> >>r600_cs_parser_fini(&parser, r);
> >>return r;
> >>}
> >>- r = radeon_cs_finish_pages(&parser);
> >>- if (r) {
> >>- DRM_ERROR("Invalid command stream !\n");
> >>- r600_cs_parser_fini(&parser, r);
> >>- return r;
> >>- }
> >>r600_cs_parser_fini(&parser, r);
> >>return r;
> >> }
> >>diff --git a/drivers/gpu/drm/radeon/radeon.h
> >>b/drivers/gpu/drm/radeon/radeon.h
> >>index e067024..c52bb5e 100644
> >>--- a/drivers/gpu/drm/radeon/radeon.h
> >>+++ b/drivers/gpu/drm/radeon/radeon.h
> >>@@ -983,12 +983,7 @@ struct radeon_cs_reloc {
> >> struct radeon_cs_chunk {
> >>uint32_tchunk_id;
> >>uint32_tlength_dw;
> >>- int kpage_idx[2];
> >>- uint32_t*kpage[2];
> >>uint32_t*kdata;
> >>- void __user *user_ptr;
> >>- int last_copied_page;
> >>- int last_page_index;
> >> };
> >> struct radeon_cs_parser {
> >>@@ -1027,8 +1022,13 @@ struct radeon_cs_parser {
> >>struct radeon_sa_bo *cpu_sema;
> >> };
> >>-extern int radeon_cs_finish_pages(struct radeon_cs_parser *p);
> >>-extern u32 radeon_get_ib_value(struct radeon_cs_parser *p, int idx);
> >>+static inline u32 radeon_get_ib_value(struct radeon_cs_parser *p, int idx)
> >>+{
> >>+ struct radeon_cs_chunk *ibc = &p->chunks[p->chunk_ib_idx];
> >>+
> >>+ return ibc->kdata[idx];
> >>+}
> >>+
> >> struct radeon_cs_packet {
> >>unsignedidx;
> >>diff --git a/drivers/gpu/drm/radeon/radeon_cs.c
> >>b/drivers/gpu/drm/radeon/radeon_cs.c
> >>index 7d7322e..98d8898 100644
> >>--- a/drivers/gpu/drm/radeon/radeon_cs.c
> >>+++ b/drivers/gpu/drm/radeon/radeon_cs.c
> >>@@ -217,9 +217,7 @@ int radeon_cs_parser_init(struct radeon_cs_parser *p,
> >>void *data)
> >>return -EFAULT;
> >>}
> >>p->chunks[i].length_dw = user_chunk.length_dw;
> >>- p->chunks[i].kdata = NULL;
> >>p->chunks[i].chunk_id = user_chunk.chunk_id;
> >>- p->chunks[i].user_ptr = (void __user *)(unsigned
> >>long)user_chunk.chunk_data;
> >>if (p->chunks[i].chunk_id == RADEON_CHUNK_ID_RELOCS) {
> >>p->chunk_relocs_idx = i;
> >>}
> >>@@ -242,25 +240,22 @@ int radeon_cs_parser_init(struct radeon_cs_parser *p,
> >>void *data)
> >>return -EINVAL;
> >>}
> >>- cdata = (uint32_t *)(unsigned long)user_chunk.chunk_data;
> >>- if ((p->chunks[i].chunk_id == RADEON_CHUNK_ID_RELOCS) ||
> >>- (p->chunks[i].chunk_id == RADEON_CHUNK_ID_FLAGS)) {
> >>- size = p->chunks[i].length_dw * sizeof(uint32_t);
> >>- p->chunks[i].kdata = kmalloc(size, GFP_KERNEL);
> >>- if (p->chunks[i].kdata == NULL) {
> >>- return -ENOMEM;
> >>- }
> >>- if (DRM_COPY_FROM_USER(p->chunks[i].kdata,
> >>-
Re: [RFC PATCH] drm/radeon: fixup locking inversion between mmap_sem and reservations
On Tue, Oct 8, 2013 at 10:45 AM, Maarten Lankhorst < maarten.lankho...@canonical.com> wrote: > op 08-10-13 16:33, Jerome Glisse schreef: > > On Tue, Oct 08, 2013 at 04:14:40PM +0200, Maarten Lankhorst wrote: > >> Allocate and copy all kernel memory before doing reservations. This > prevents a locking > >> inversion between mmap_sem and reservation_class, and allows us to drop > the trylocking > >> in ttm_bo_vm_fault without upsetting lockdep. > >> > >> Signed-off-by: Maarten Lankhorst > > I would say NAK. Current code only allocate temporary page in AGP case. > > So AGP case is userspace -> temp page -> cs checker -> radeon ib. > > > > Non AGP is directly memcpy to radeon IB. > > > > Your patch allocate memory memcpy userspace to it and it will then be > > memcpy to IB. Which means you introduce an extra memcpy in the process > > not something we want. > > > Can we move up the call to radeon_ib_get then to be done before calling > radeon_cs_parser_relocs? > > ~Maarten > No won't work with the AGP case where we copy one page at a time while cs checker is processing. For AGP we could however go to the 2 memcpy and temp buffer case. For other, we don't know upfront the ib size or the number of ib we want. Cheers, Jerome ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 70286] New: X crashes when using Firefox with logout loop
https://bugs.freedesktop.org/show_bug.cgi?id=70286 Priority: medium Bug ID: 70286 Assignee: dri-devel@lists.freedesktop.org Summary: X crashes when using Firefox with logout loop Severity: major Classification: Unclassified OS: Linux (All) Reporter: xgt...@gmail.com Hardware: x86-64 (AMD64) Status: NEW Version: DRI CVS Component: DRM/Radeon Product: DRI Created attachment 87293 --> https://bugs.freedesktop.org/attachment.cgi?id=87293&action=edit syslog during crash Firefox 24, with hardware acceleration on, X crashes and the whole desktop enters a logout loop. Restarting is the only way out :(. I am running Ubunut 13.04 (linux mint 15) with Linux Kernel 3.11.4 with radeon.dpm=1 and oibaf ppa (mesa-9.3-git) and Xorg 1.13.4 Attached are my syslog and Xorg.0.log during the crash. Please let me know if I need to attach any further logs. Here are some error messages that I found in these logs : syslog : [ 1807.720765] [drm:radeon_crtc_page_flip] *ERROR* failed to pin new rbo buffer before flip [ 1810.600061] radeon :01:00.0: 88008c51ac00 pin failed from Xorg.0.log : [ 1839.182] (WW) RADEON(0): flip queue failed: Invalid argument [ 1839.182] (WW) RADEON(0): Page flip failed: Invalid argument -- 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 70286] X crashes when using Firefox with logout loop
https://bugs.freedesktop.org/show_bug.cgi?id=70286 --- Comment #1 from Ganesh Hegde --- Created attachment 87294 --> https://bugs.freedesktop.org/attachment.cgi?id=87294&action=edit Xorg.0.log attached xorg.0.log after crash -- 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] drm/i915: revert vga arbiter changes
Adding drm/i915 into the vga arbiter chain means that X (in a piece of
well-meant paranoia) will do a get/put on the vga decoding around
_every_ accel call down into the ddx. Which results in some nice
performance disasters [1].
Ville tried to come up with a Great Hack to fiddle the required VGA
I/O ops behind everyone's back using stop_machine, but that didn't
really work out [2]. Given that we're fairly late in the -rc stage for
such games let's just revert this all.
This reverts
commit 6e1b4fdad5157bb9e88777d525704aba24389bee
Author: Ville Syrjälä
Date: Thu Sep 5 20:40:52 2013 +0300
drm/i915: Delay disabling of VGA memory until vgacon->fbcon handoff is done
and
commit 81b5c7bc8de3e6f63419139c2fc91bf81dea8a7d
Author: Alex Williamson
Date: Wed Aug 28 09:39:08 2013 -0600
i915: Update VGA arbiter support for newer devices
One thing we might want to keep is to delay the disabling of the vga
decoding until the fbdev emulation and the fbcon screen is set up. If
we kill vga mem decoding beforehand fbcon can end up with a white
square in the top-left corner it tried to save from the vga memory for
a seamless transition. And we have bug reports on older platforms
which seem to match these symptoms.
But again that's something to play around with in -next.
References: [1]
http://lists.x.org/archives/xorg-devel/2013-September/037763.html
References: [2] http://www.spinics.net/lists/intel-gfx/msg34062.html
Cc: Alex Williamson
Cc: Ville Syrjälä
Cc: Chris Wilson
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/i915/i915_dma.c | 15 +++
drivers/gpu/drm/i915/intel_display.c | 30 --
drivers/gpu/drm/i915/intel_drv.h | 1 -
include/linux/vgaarb.h | 7 ---
4 files changed, 3 insertions(+), 50 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_dma.c b/drivers/gpu/drm/i915/i915_dma.c
index c27a210..d5c784d 100644
--- a/drivers/gpu/drm/i915/i915_dma.c
+++ b/drivers/gpu/drm/i915/i915_dma.c
@@ -1290,12 +1290,9 @@ static int i915_load_modeset_init(struct drm_device *dev)
* then we do not take part in VGA arbitration and the
* vga_client_register() fails with -ENODEV.
*/
- if (!HAS_PCH_SPLIT(dev)) {
- ret = vga_client_register(dev->pdev, dev, NULL,
- i915_vga_set_decode);
- if (ret && ret != -ENODEV)
- goto out;
- }
+ ret = vga_client_register(dev->pdev, dev, NULL, i915_vga_set_decode);
+ if (ret && ret != -ENODEV)
+ goto out;
intel_register_dsm_handler();
@@ -1351,12 +1348,6 @@ static int i915_load_modeset_init(struct drm_device *dev)
*/
intel_fbdev_initial_config(dev);
- /*
-* Must do this after fbcon init so that
-* vgacon_save_screen() works during the handover.
-*/
- i915_disable_vga_mem(dev);
-
/* Only enable hotplug handling once the fbdev is fully set up. */
dev_priv->enable_hotplug_processing = true;
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index c89abd3..581fb4b 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -10045,33 +10045,6 @@ static void i915_disable_vga(struct drm_device *dev)
POSTING_READ(vga_reg);
}
-static void i915_enable_vga_mem(struct drm_device *dev)
-{
- /* Enable VGA memory on Intel HD */
- if (HAS_PCH_SPLIT(dev)) {
- vga_get_uninterruptible(dev->pdev, VGA_RSRC_LEGACY_IO);
- outb(inb(VGA_MSR_READ) | VGA_MSR_MEM_EN, VGA_MSR_WRITE);
- vga_set_legacy_decoding(dev->pdev, VGA_RSRC_LEGACY_IO |
- VGA_RSRC_LEGACY_MEM |
- VGA_RSRC_NORMAL_IO |
- VGA_RSRC_NORMAL_MEM);
- vga_put(dev->pdev, VGA_RSRC_LEGACY_IO);
- }
-}
-
-void i915_disable_vga_mem(struct drm_device *dev)
-{
- /* Disable VGA memory on Intel HD */
- if (HAS_PCH_SPLIT(dev)) {
- vga_get_uninterruptible(dev->pdev, VGA_RSRC_LEGACY_IO);
- outb(inb(VGA_MSR_READ) & ~VGA_MSR_MEM_EN, VGA_MSR_WRITE);
- vga_set_legacy_decoding(dev->pdev, VGA_RSRC_LEGACY_IO |
- VGA_RSRC_NORMAL_IO |
- VGA_RSRC_NORMAL_MEM);
- vga_put(dev->pdev, VGA_RSRC_LEGACY_IO);
- }
-}
-
void intel_modeset_init_hw(struct drm_device *dev)
{
intel_init_power_well(dev);
@@ -10350,7 +10323,6 @@ void i915_redisable_vga(struct drm_device *dev)
if (I915_READ(vga_reg) != VGA_DISP_DISABLE) {
DRM_DEBUG_KMS("Something enabled VGA plane, disabling it\n");
i915_disable_vga(dev);
- i915_disable_vga_mem(dev);
}
}
@
Re: [PATCH 5/5] DRM: Armada: add support for drm tda19988 driver
On Tue, 8 Oct 2013 10:49:39 +0100 Russell King - ARM Linux wrote: > On Tue, Oct 08, 2013 at 11:19:13AM +0200, Jean-Francois Moine wrote: > > The Cubox is an open platform, and I use it just like a desktop PC. > > When its required drivers will be in the mainline, I will do the same > > as I do with PCs: I will not recompile a specific kernel each time > > there are kernel bugs or security issues. Instead, I will just upgrade > > my system from my distributor (Debian), and, in the packages, there > > will be a generic mvebu kernel as there is already one for Marvell > > Armada 370/xp, Freescale iMX5x/iMX6 (linux-image-3.10-3-armmp). > > But, for that, all the Cubox specific stuff must be described in a DT. > > Which scenario is better: > > 1. To have something in mainline which is capable of driving the hardware, >but may need some additional work to make it useful for DT based setups. > > or > > 2. To have nothing. > > Now, you may prefer to have nothing, but personally, I prefer there to be > forward progress. Forward progress means getting some kind of DRM driver > into mainline. Yes, it may not work with DT setups yet, but - as per > the discussions that have happened _endlessly_ on this topic, it's > something that can be resolved at a later date. > > We _still_ haven't worked out how to properly deal with the TDA998x > driver (or indeed any DRM based outputs) in a DT based setup, and all > the time that problem exists, it won't be possible to write a proper > stable DT binding for this. > > So please, get off your hobby horse about this and allow us to make some > modicum of progress. You forgot: 3. To have all patches ready for submission and have a working DT driven Cubox kernel. I will submit a patch to add DT to the tda998x driver as soon as I have checked the new audio properties we talked about yesterday. Normally, this should have no impact on your Armada drm driver, and, yes, I will add DT to your driver as soon as it will be accepted (sorry to not ack it now: I had no time yet to have a look at it). -- Ken ar c'hentañ | ** Breizh ha Linux atav! ** Jef | http://moinejf.free.fr/ ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/nouveau: suspend to D3hot, not to D3cold
In the autumn and winter it's considered bad form to set power state to D3cold, it might cause the device to freeze to death. This is also the case in the other seasons, so any device in the southern hemisphere is affected too. D3cold is not a valid state in a call to pci_set_power_state, only up to D3hot is allowed. Signed-off-by: Maarten Lankhorst --- diff --git a/drivers/gpu/drm/nouveau/nouveau_drm.c b/drivers/gpu/drm/nouveau/nouveau_drm.c index 89efeff..566e544 100644 --- a/drivers/gpu/drm/nouveau/nouveau_drm.c +++ b/drivers/gpu/drm/nouveau/nouveau_drm.c @@ -945,7 +945,7 @@ static int nouveau_pmops_runtime_suspend(struct device *dev) ret = nouveau_do_suspend(drm_dev); pci_save_state(pdev); pci_disable_device(pdev); - pci_set_power_state(pdev, PCI_D3cold); + pci_set_power_state(pdev, PCI_D3hot); drm_dev->switch_power_state = DRM_SWITCH_POWER_DYNAMIC_OFF; return ret; } ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 0/3] fbdev-less i915, take 2
Hi all, By popular demand (our embedded guys kept asking for this) I've resurrected my fbdev less patches. Now Rob's msm driver can be completely completely without CONFIG_FB stuff at all when disabling the fbdev helper support. Review highly welcome. Cheers, Daniel Daniel Vetter (3): drm: Add separate Kconfig option for fbdev helpers drm/i915: Kconfig option to disable the legacy fbdev support drm/i915: rename intel_fb.c to intel_fbdev.c drivers/gpu/drm/Kconfig | 69 ++-- drivers/gpu/drm/Makefile | 3 +- drivers/gpu/drm/ast/Kconfig | 1 + drivers/gpu/drm/cirrus/Kconfig | 1 + drivers/gpu/drm/drm_crtc_helper.c| 4 + drivers/gpu/drm/drm_fb_helper.c | 4 - drivers/gpu/drm/exynos/Kconfig | 1 + drivers/gpu/drm/gma500/Kconfig | 1 + drivers/gpu/drm/i915/Kconfig | 67 drivers/gpu/drm/i915/Makefile| 3 +- drivers/gpu/drm/i915/i915_debugfs.c | 9 +- drivers/gpu/drm/i915/i915_dma.c | 8 +- drivers/gpu/drm/i915/i915_drv.h | 2 + drivers/gpu/drm/i915/intel_display.c | 12 +- drivers/gpu/drm/i915/intel_drv.h | 36 +++- drivers/gpu/drm/i915/intel_fb.c | 323 --- drivers/gpu/drm/i915/intel_fbdev.c | 323 +++ drivers/gpu/drm/mgag200/Kconfig | 1 + drivers/gpu/drm/msm/Kconfig | 1 + drivers/gpu/drm/nouveau/Kconfig | 1 + drivers/gpu/drm/omapdrm/Kconfig | 1 + drivers/gpu/drm/qxl/Kconfig | 1 + drivers/gpu/drm/rcar-du/Kconfig | 1 + drivers/gpu/drm/shmobile/Kconfig | 1 + drivers/gpu/drm/tilcdc/Kconfig | 1 + drivers/gpu/drm/udl/Kconfig | 1 + drivers/gpu/host1x/drm/Kconfig | 1 + drivers/staging/imx-drm/Kconfig | 1 + 28 files changed, 477 insertions(+), 401 deletions(-) create mode 100644 drivers/gpu/drm/i915/Kconfig delete mode 100644 drivers/gpu/drm/i915/intel_fb.c create mode 100644 drivers/gpu/drm/i915/intel_fbdev.c -- 1.8.1.4 ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 1/3] drm: Add separate Kconfig option for fbdev helpers
For drivers which might want to disable fbdev legacy support.
Select the new option in all drivers for now, so this shouldn't result
in any change. Drivers need some work anyway to make fbdev support
optional (if they have it implemented, that is), so the recommended
way to expose this is by adding per-driver options. At least as long
as most drivers don't support disabling the fbdev support.
v2: Update for new drm drivers msm and rcar-du. Note that Rob's msm
driver can already take advantage of this, which allows us to build
msm without any fbdev depencies in the kernel!
v3: Move the MODULE_* stuff from the fbdev helper file to
drm_crtc_helper.c.
Cc: David Herrmann
Cc: Rob Clark
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/Kconfig | 11 ++-
drivers/gpu/drm/Makefile | 3 ++-
drivers/gpu/drm/ast/Kconfig | 1 +
drivers/gpu/drm/cirrus/Kconfig| 1 +
drivers/gpu/drm/drm_crtc_helper.c | 4
drivers/gpu/drm/drm_fb_helper.c | 4
drivers/gpu/drm/exynos/Kconfig| 1 +
drivers/gpu/drm/gma500/Kconfig| 1 +
drivers/gpu/drm/mgag200/Kconfig | 1 +
drivers/gpu/drm/msm/Kconfig | 1 +
drivers/gpu/drm/nouveau/Kconfig | 1 +
drivers/gpu/drm/omapdrm/Kconfig | 1 +
drivers/gpu/drm/qxl/Kconfig | 1 +
drivers/gpu/drm/rcar-du/Kconfig | 1 +
drivers/gpu/drm/shmobile/Kconfig | 1 +
drivers/gpu/drm/tilcdc/Kconfig| 1 +
drivers/gpu/drm/udl/Kconfig | 1 +
drivers/gpu/host1x/drm/Kconfig| 1 +
drivers/staging/imx-drm/Kconfig | 1 +
19 files changed, 31 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig
index 95d..3104b6d 100644
--- a/drivers/gpu/drm/Kconfig
+++ b/drivers/gpu/drm/Kconfig
@@ -29,11 +29,17 @@ config DRM_USB
config DRM_KMS_HELPER
tristate
depends on DRM
+ help
+ CRTC helpers for KMS drivers.
+
+config DRM_KMS_FB_HELPER
+ bool
+ depends on DRM_KMS_HELPER
select FB
select FRAMEBUFFER_CONSOLE if !EXPERT
select FRAMEBUFFER_CONSOLE_DETECT_PRIMARY if FRAMEBUFFER_CONSOLE
help
- FB and CRTC helpers for KMS drivers.
+ FBDEV helpers for KMS drivers.
config DRM_LOAD_EDID_FIRMWARE
bool "Allow to specify an EDID data set instead of probing for it"
@@ -64,6 +70,7 @@ config DRM_GEM_CMA_HELPER
config DRM_KMS_CMA_HELPER
bool
select DRM_GEM_CMA_HELPER
+ select DRM_KMS_FB_HELPER
select FB_SYS_FILLRECT
select FB_SYS_COPYAREA
select FB_SYS_IMAGEBLIT
@@ -96,6 +103,7 @@ config DRM_RADEON
select FB_CFB_IMAGEBLIT
select FW_LOADER
select DRM_KMS_HELPER
+ select DRM_KMS_FB_HELPER
select DRM_TTM
select POWER_SUPPLY
select HWMON
@@ -130,6 +138,7 @@ config DRM_I915
select SHMEM
select TMPFS
select DRM_KMS_HELPER
+ select DRM_KMS_FB_HELPER
select FB_CFB_FILLRECT
select FB_CFB_COPYAREA
select FB_CFB_IMAGEBLIT
diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile
index f089adf..5af240b 100644
--- a/drivers/gpu/drm/Makefile
+++ b/drivers/gpu/drm/Makefile
@@ -21,8 +21,9 @@ drm-$(CONFIG_PCI) += ati_pcigart.o
drm-usb-y := drm_usb.o
-drm_kms_helper-y := drm_fb_helper.o drm_crtc_helper.o drm_dp_helper.o
+drm_kms_helper-y := drm_crtc_helper.o drm_dp_helper.o
drm_kms_helper-$(CONFIG_DRM_LOAD_EDID_FIRMWARE) += drm_edid_load.o
+drm_kms_helper-$(CONFIG_DRM_KMS_FB_HELPER) += drm_fb_helper.o
drm_kms_helper-$(CONFIG_DRM_KMS_CMA_HELPER) += drm_fb_cma_helper.o
obj-$(CONFIG_DRM_KMS_HELPER) += drm_kms_helper.o
diff --git a/drivers/gpu/drm/ast/Kconfig b/drivers/gpu/drm/ast/Kconfig
index da4a51e..8a784c4 100644
--- a/drivers/gpu/drm/ast/Kconfig
+++ b/drivers/gpu/drm/ast/Kconfig
@@ -6,6 +6,7 @@ config DRM_AST
select FB_SYS_FILLRECT
select FB_SYS_IMAGEBLIT
select DRM_KMS_HELPER
+ select DRM_KMS_FB_HELPER
select DRM_TTM
help
Say yes for experimental AST GPU driver. Do not enable
diff --git a/drivers/gpu/drm/cirrus/Kconfig b/drivers/gpu/drm/cirrus/Kconfig
index bf67b22..9864559 100644
--- a/drivers/gpu/drm/cirrus/Kconfig
+++ b/drivers/gpu/drm/cirrus/Kconfig
@@ -5,6 +5,7 @@ config DRM_CIRRUS_QEMU
select FB_SYS_COPYAREA
select FB_SYS_IMAGEBLIT
select DRM_KMS_HELPER
+ select DRM_KMS_FB_HELPER
select DRM_TTM
help
This is a KMS driver for emulated cirrus device in qemu.
diff --git a/drivers/gpu/drm/drm_crtc_helper.c
b/drivers/gpu/drm/drm_crtc_helper.c
index 4280e37..c4bfd69 100644
--- a/drivers/gpu/drm/drm_crtc_helper.c
+++ b/drivers/gpu/drm/drm_crtc_helper.c
@@ -39,6 +39,10 @@
#include
#include
+MODULE_AUTHOR("David Airlie, Jesse Barnes");
+MODULE_DESCRIPTION("DRM KMS helper");
+MODULE_LICENSE("GPL and additional rights");
+
/**
* drm_helper_move_panel_connectors_to_head() - move panels to the front in the
*
[PATCH 2/3] drm/i915: Kconfig option to disable the legacy fbdev support
Boots Just Fine (tm)! The only glitch seems to be that at least on Fedora the boot splash gets confused and doesn't display much at all. And since there's no ugly console flickering anymore in between, the flicker while switching between X servers (VT support is still enabled) is even more jarring. Also, I'm unsure whether we don't need to somehow kick out vgacon, now that nothing else gets in the way. But stuff seems to work, so I don't care. Also everything still works as well with VGA_CONSOLE=n Also the #ifdef mess needs a bit of a cleanup, follow-up patches will do just that. To keep the Kconfig tidy, extract all the i915 options into its own file. v2: - Rebase on top of the preliminary hw support option and the intel_drv.h cleanup. - Shut up warnings in i915_debugfs.c Cc: David Herrmann Signed-off-by: Daniel Vetter --- drivers/gpu/drm/Kconfig | 60 +--- drivers/gpu/drm/i915/Kconfig | 67 drivers/gpu/drm/i915/Makefile| 3 +- drivers/gpu/drm/i915/i915_debugfs.c | 9 ++--- drivers/gpu/drm/i915/i915_dma.c | 6 drivers/gpu/drm/i915/i915_drv.h | 2 ++ drivers/gpu/drm/i915/intel_display.c | 10 ++ drivers/gpu/drm/i915/intel_drv.h | 36 +++ 8 files changed, 122 insertions(+), 71 deletions(-) create mode 100644 drivers/gpu/drm/i915/Kconfig diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig index 3104b6d..b4e4fc0 100644 --- a/drivers/gpu/drm/Kconfig +++ b/drivers/gpu/drm/Kconfig @@ -128,65 +128,7 @@ config DRM_I810 selected, the module will be called i810. AGP support is required for this driver to work. -config DRM_I915 - tristate "Intel 8xx/9xx/G3x/G4x/HD Graphics" - depends on DRM - depends on AGP - depends on AGP_INTEL - # we need shmfs for the swappable backing store, and in particular - # the shmem_readpage() which depends upon tmpfs - select SHMEM - select TMPFS - select DRM_KMS_HELPER - select DRM_KMS_FB_HELPER - select FB_CFB_FILLRECT - select FB_CFB_COPYAREA - select FB_CFB_IMAGEBLIT - # i915 depends on ACPI_VIDEO when ACPI is enabled - # but for select to work, need to select ACPI_VIDEO's dependencies, ick - select BACKLIGHT_LCD_SUPPORT if ACPI - select BACKLIGHT_CLASS_DEVICE if ACPI - select VIDEO_OUTPUT_CONTROL if ACPI - select INPUT if ACPI - select THERMAL if ACPI - select ACPI_VIDEO if ACPI - select ACPI_BUTTON if ACPI - help - Choose this option if you have a system that has "Intel Graphics - Media Accelerator" or "HD Graphics" integrated graphics, - including 830M, 845G, 852GM, 855GM, 865G, 915G, 945G, 965G, - G35, G41, G43, G45 chipsets and Celeron, Pentium, Core i3, - Core i5, Core i7 as well as Atom CPUs with integrated graphics. - If M is selected, the module will be called i915. AGP support - is required for this driver to work. This driver is used by - the Intel driver in X.org 6.8 and XFree86 4.4 and above. It - replaces the older i830 module that supported a subset of the - hardware in older X.org releases. - - Note that the older i810/i815 chipsets require the use of the - i810 driver instead, and the Atom z5xx series has an entirely - different implementation. - -config DRM_I915_KMS - bool "Enable modesetting on intel by default" - depends on DRM_I915 - help - Choose this option if you want kernel modesetting enabled by default, - and you have a new enough userspace to support this. Running old - userspaces with this enabled will cause pain. Note that this causes - the driver to bind to PCI devices, which precludes loading things - like intelfb. - -config DRM_I915_PRELIMINARY_HW_SUPPORT - bool "Enable preliminary support for prerelease Intel hardware by default" - depends on DRM_I915 - help - Choose this option if you have prerelease Intel hardware and want the - i915 driver to support it by default. You can enable such support at - runtime with the module option i915.preliminary_hw_support=1; this - option changes the default for that module option. - - If in doubt, say "N". +source "drivers/gpu/drm/i915/Kconfig" config DRM_MGA tristate "Matrox g200/g400" diff --git a/drivers/gpu/drm/i915/Kconfig b/drivers/gpu/drm/i915/Kconfig new file mode 100644 index 000..6199d0b --- /dev/null +++ b/drivers/gpu/drm/i915/Kconfig @@ -0,0 +1,67 @@ +config DRM_I915 + tristate "Intel 8xx/9xx/G3x/G4x/HD Graphics" + depends on DRM + depends on AGP + depends on AGP_INTEL + # we need shmfs for the swappable backing store, and in particular + # the shmem_readpage() which depends upon tmpfs + select SHMEM +
[PATCH 3/3] drm/i915: rename intel_fb.c to intel_fbdev.c
This file is all about the legacy fbdev support. If we want to extract
framebuffer functions, we better put those into a separate file.
Also rename functions accordingly, only two have used the intel_fb_
prefix anyway.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/i915/Makefile| 2 +-
drivers/gpu/drm/i915/i915_dma.c | 2 +-
drivers/gpu/drm/i915/intel_display.c | 4 +-
drivers/gpu/drm/i915/intel_drv.h | 8 +-
drivers/gpu/drm/i915/intel_fb.c | 323 ---
drivers/gpu/drm/i915/intel_fbdev.c | 323 +++
6 files changed, 331 insertions(+), 331 deletions(-)
delete mode 100644 drivers/gpu/drm/i915/intel_fb.c
create mode 100644 drivers/gpu/drm/i915/intel_fbdev.c
diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
index 45e14a8..41838ea 100644
--- a/drivers/gpu/drm/i915/Makefile
+++ b/drivers/gpu/drm/i915/Makefile
@@ -53,7 +53,7 @@ i915-$(CONFIG_COMPAT) += i915_ioc32.o
i915-$(CONFIG_ACPI)+= intel_acpi.o
-i915-$(CONFIG_DRM_I915_FBDEV) += intel_fb.o
+i915-$(CONFIG_DRM_I915_FBDEV) += intel_fbdev.o
obj-$(CONFIG_DRM_I915) += i915.o
diff --git a/drivers/gpu/drm/i915/i915_dma.c b/drivers/gpu/drm/i915/i915_dma.c
index 057ddeb..6744490 100644
--- a/drivers/gpu/drm/i915/i915_dma.c
+++ b/drivers/gpu/drm/i915/i915_dma.c
@@ -1865,7 +1865,7 @@ void i915_driver_lastclose(struct drm_device * dev)
return;
if (drm_core_check_feature(dev, DRIVER_MODESET)) {
- intel_fb_restore_mode(dev);
+ intel_fbdev_restore_mode(dev);
vga_switcheroo_process_delayed_switch();
return;
}
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 43e4e75..ac50539 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -10089,14 +10089,14 @@ intel_user_framebuffer_create(struct drm_device *dev,
}
#ifndef CONFIG_DRM_I915_FBDEV
-static inline void intel_fb_output_poll_changed(struct drm_device *dev)
+static inline void intel_fbdev_output_poll_changed(struct drm_device *dev)
{
}
#endif
static const struct drm_mode_config_funcs intel_mode_funcs = {
.fb_create = intel_user_framebuffer_create,
- .output_poll_changed = intel_fb_output_poll_changed,
+ .output_poll_changed = intel_fbdev_output_poll_changed,
};
/* Set up chip specific display functions */
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index 181d10b..6a8b027 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -716,14 +716,14 @@ bool intel_dsi_init(struct drm_device *dev);
void intel_dvo_init(struct drm_device *dev);
-/* legacy fbdev emulation in intel_fb.c */
+/* legacy fbdev emulation in intel_fbdev.c */
#ifdef CONFIG_DRM_I915_FBDEV
extern int intel_fbdev_init(struct drm_device *dev);
extern void intel_fbdev_initial_config(struct drm_device *dev);
extern void intel_fbdev_fini(struct drm_device *dev);
extern void intel_fbdev_set_suspend(struct drm_device *dev, int state);
-extern void intel_fb_output_poll_changed(struct drm_device *dev);
-extern void intel_fb_restore_mode(struct drm_device *dev);
+extern void intel_fbdev_output_poll_changed(struct drm_device *dev);
+extern void intel_fbdev_restore_mode(struct drm_device *dev);
#else
static inline int intel_fbdev_init(struct drm_device *dev)
{
@@ -742,7 +742,7 @@ static inline void intel_fbdev_set_suspend(struct
drm_device *dev, int state)
{
}
-static inline void intel_fb_restore_mode(struct drm_device *dev)
+static inline void intel_fbdev_restore_mode(struct drm_device *dev)
{
}
#endif
diff --git a/drivers/gpu/drm/i915/intel_fb.c b/drivers/gpu/drm/i915/intel_fb.c
deleted file mode 100644
index d883b77..000
--- a/drivers/gpu/drm/i915/intel_fb.c
+++ /dev/null
@@ -1,323 +0,0 @@
-/*
- * Copyright © 2007 David Airlie
- *
- * Permission is hereby granted, free of charge, to any person obtaining a
- * copy of this software and associated documentation files (the "Software"),
- * to deal in the Software without restriction, including without limitation
- * the rights to use, copy, modify, merge, publish, distribute, sublicense,
- * and/or sell copies of the Software, and to permit persons to whom the
- * Software is furnished to do so, subject to the following conditions:
- *
- * The above copyright notice and this permission notice (including the next
- * paragraph) shall be included in all copies or substantial portions of the
- * Software.
- *
- * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
- * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
- * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL
- * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
- * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARI
Re: [PATCH 0/3] fbdev-less i915, take 2
On Tue, Oct 08, 2013 at 05:44:46PM +0200, Daniel Vetter wrote: > Hi all, > > By popular demand (our embedded guys kept asking for this) I've resurrected my > fbdev less patches. Now Rob's msm driver can be completely completely without > CONFIG_FB stuff at all when disabling the fbdev helper support. > > Review highly welcome. I still think this is misleading. fbdev to me is /dev/fb not fbcon. They are related only by implementation. -Chris -- Chris Wilson, Intel Open Source Technology Centre ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/i915: revert vga arbiter changes
On Tue, Oct 08, 2013 at 05:27:28PM +0200, Daniel Vetter wrote: > Adding drm/i915 into the vga arbiter chain means that X (in a piece of > well-meant paranoia) will do a get/put on the vga decoding around > _every_ accel call down into the ddx. Which results in some nice > performance disasters [1]. And disables DRI for the system, interferring with the use of OpenGL compositors, playing games, PRIME, etc. This effect is not limited to users of i915, but any system with a dGPU and an igfx enabled Core CPU. I still think we are downplaying the complete and utter disaster caused by X and the patch, and why the revert is required. -Chris -- Chris Wilson, Intel Open Source Technology Centre ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/i915: revert vga arbiter changes
On Tue, 2013-10-08 at 17:08 +0100, Chris Wilson wrote: > On Tue, Oct 08, 2013 at 05:27:28PM +0200, Daniel Vetter wrote: > > Adding drm/i915 into the vga arbiter chain means that X (in a piece of > > well-meant paranoia) will do a get/put on the vga decoding around > > _every_ accel call down into the ddx. Which results in some nice > > performance disasters [1]. > > And disables DRI for the system, interferring with the use of OpenGL > compositors, playing games, PRIME, etc. This effect is not limited to > users of i915, but any system with a dGPU and an igfx enabled Core CPU. > > I still think we are downplaying the complete and utter disaster caused > by X and the patch, and why the revert is required. I'm failing to understand the disaster myself, can you explain? i915 is already attempting to make use of the VGA arbiter, but the code hadn't been updated so what it was doing was ineffective. The external difference I see is that before i915 incorrectly reported that it was not involved in VGA arbitration (even though it still claims VGA transactions). With the fixes, it opts-out of MMIO arbitration, but requires I/O port arbitration. I'm OK with reverting these and going back to the drawing board for v3.13, but what i915 is doing is still incorrect and precludes making use of a guest assigned VGA device (or separate display server requiring VGA), because we can't use the VGA arbiter for what it's designed to do, re-route VGA accesses. Thanks, Alex ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/radeon: signal all fences after lockup to avoid endless waiting in GEM_WAIT
Hi Marek, please try the attached patch as a replacement for your signaling all fences patch. I'm not 100% sure if it fixes all issues, but it's at least a start. Thanks, Christian. Am 07.10.2013 13:08, schrieb Christian König: First of all, I can't complain about the reliability of the hardware GPU reset. It's mostly the kernel driver that happens to run into a deadlock at the same time. Alex and I spend quite some time on making this reliable again after activating more rings and adding VM support. The main problem is that I couldn't figure out where the CPU deadlock comes from, cause I couldn't reliable reproduce the issue. What is the content of /proc//task/*/stack and sys/kernel/debug/dri/0/radeon_fence_info when the X server is stuck in the deadlock situation? I'm pretty sure that we nearly always have a problem when two threads are waiting for fences on one of them detects that we have a lockup while the other one keeps holding the exclusive lock. Signaling all fences might work around that problem, but it probably would be better to fix the underlying issue. Going to take a deeper look into it. Christian. Am 03.10.2013 02:45, schrieb Marek Olšák: First of all, I can't complain about the reliability of the hardware GPU reset. It's mostly the kernel driver that happens to run into a deadlock at the same time. Regarding the issue with fences, the problem is that the GPU reset completes successfully according to dmesg, but X doesn't respond. I can move the cursor on the screen, but I can't do anything else and the UI is frozen. gdb says that X is stuck in GEM_WAIT_IDLE. I can easily reproduce this, because it's the most common reason why a GPU lockup leads to frozen X. The GPU actually recovers, but X is hung. I can't tell whether the fences are just not signalled or whether there is actually a real CPU deadlock I can't see. This patch makes the problem go away and GPU resets are successful (except for extreme cases, see below). With a small enough lockup timeout, the lockups are just a minor annoyance and I thought I could get through a piglit run just with a few tens or hundreds of GPU resets... A different type of deadlock showed up, though it needs a lot of concurrently-running apps like piglit. What happened is that the kernel driver was stuck/deadlocked in radeon_cs_ioctl presumably due to a GPU hang while holding onto the exclusive lock, and another thread wanting to do the GPU reset was unable to acquire the lock. That said, I will use the patch locally, because it helps a lot. I got a few lockups while writing this email and I'm glad I didn't have to reboot. Marek On Wed, Oct 2, 2013 at 4:50 PM, Christian König wrote: Possible, but I would rather guess that this doesn't work because the IB test runs into a deadlock situation and so the GPU reset never fully completes. Can you reproduce the problem? If you want to make GPU resets more reliable I would rather suggest to remove the ring lock dependency. Then we should try to give all the fence wait functions a (reliable) timeout and move reset handling a layer up into the ioctl functions. But for this you need to rip out the old PM code first. Christian. Marek Olšák schrieb: I'm afraid signalling the fences with an IB test is not reliable. Marek On Wed, Oct 2, 2013 at 3:52 PM, Christian König wrote: NAK, after recovering from a lockup the first thing we do is signalling all remaining fences with an IB test. If we don't recover we indeed signal all fences manually. Signalling all fences regardless of the outcome of the reset creates problems with both types of partial resets. Christian. Marek Olšák schrieb: From: Marek Olšák After a lockup, fences are not signalled sometimes, causing the GEM_WAIT_IDLE ioctl to never return, which sometimes results in an X server freeze. This fixes only one of many deadlocks which can occur during a lockup. Signed-off-by: Marek Olšák --- drivers/gpu/drm/radeon/radeon_device.c | 5 + 1 file changed, 5 insertions(+) diff --git a/drivers/gpu/drm/radeon/radeon_device.c b/drivers/gpu/drm/radeon/radeon_device.c index 841d0e0..7b97baa 100644 --- a/drivers/gpu/drm/radeon/radeon_device.c +++ b/drivers/gpu/drm/radeon/radeon_device.c @@ -1552,6 +1552,11 @@ int radeon_gpu_reset(struct radeon_device *rdev) radeon_save_bios_scratch_regs(rdev); /* block TTM */ resched = ttm_bo_lock_delayed_workqueue(&rdev->mman.bdev); + + mutex_lock(&rdev->ring_lock); + radeon_fence_driver_force_completion(rdev); + mutex_unlock(&rdev->ring_lock); + radeon_pm_suspend(rdev); radeon_suspend(rdev); -- 1.8.1.2 ___ 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-dev
Re: [PATCH] drm/i915: revert vga arbiter changes
On Tue, Oct 08, 2013 at 10:18:54AM -0600, Alex Williamson wrote: > On Tue, 2013-10-08 at 17:08 +0100, Chris Wilson wrote: > > On Tue, Oct 08, 2013 at 05:27:28PM +0200, Daniel Vetter wrote: > > > Adding drm/i915 into the vga arbiter chain means that X (in a piece of > > > well-meant paranoia) will do a get/put on the vga decoding around > > > _every_ accel call down into the ddx. Which results in some nice > > > performance disasters [1]. > > > > And disables DRI for the system, interferring with the use of OpenGL > > compositors, playing games, PRIME, etc. This effect is not limited to > > users of i915, but any system with a dGPU and an igfx enabled Core CPU. > > > > I still think we are downplaying the complete and utter disaster caused > > by X and the patch, and why the revert is required. > > I'm failing to understand the disaster myself, can you explain? i915 is > already attempting to make use of the VGA arbiter, but the code hadn't > been updated so what it was doing was ineffective. The external > difference I see is that before i915 incorrectly reported that it was > not involved in VGA arbitration (even though it still claims VGA > transactions). With the fixes, it opts-out of MMIO arbitration, but > requires I/O port arbitration. I'm OK with reverting these and going > back to the drawing board for v3.13, but what i915 is doing is still > incorrect and precludes making use of a guest assigned VGA device (or > separate display server requiring VGA), because we can't use the VGA > arbiter for what it's designed to do, re-route VGA accesses. Thanks, The problem stems from the system reporting to X that there are two legacy vga IO capable devices, and then X disabling DRI and wrapping every operation with vga_get/vga_put. X will do this even if it is only using one of the devices and the other device is not being used by the system. We are not arguing that your fix isn't correct, it is just the rammifications it has to the existing install base outweighs improving a currently broken feature. -Chris -- Chris Wilson, Intel Open Source Technology Centre ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC PATCH] drm/radeon: fixup locking inversion between mmap_sem and reservations
On 10/08/2013 04:55 PM, Jerome Glisse wrote: On Tue, Oct 08, 2013 at 04:45:18PM +0200, Christian König wrote: Am 08.10.2013 16:33, schrieb Jerome Glisse: On Tue, Oct 08, 2013 at 04:14:40PM +0200, Maarten Lankhorst wrote: Allocate and copy all kernel memory before doing reservations. This prevents a locking inversion between mmap_sem and reservation_class, and allows us to drop the trylocking in ttm_bo_vm_fault without upsetting lockdep. Signed-off-by: Maarten Lankhorst I would say NAK. Current code only allocate temporary page in AGP case. So AGP case is userspace -> temp page -> cs checker -> radeon ib. Non AGP is directly memcpy to radeon IB. Your patch allocate memory memcpy userspace to it and it will then be memcpy to IB. Which means you introduce an extra memcpy in the process not something we want. Totally agree. Additional to that there is no good reason to provide anything else than anonymous system memory to the CS ioctl, so the dependency between the mmap_sem and reservations are not really clear to me. Christian. I think is that in other code path you take mmap_sem first then reserve bo. But here we reserve bo and then we take mmap_sem because of copy from user. Cheers, Jerome Actually the log message is a little confusing. I think the mmap_sem locking inversion problem is orthogonal to what's being fixed here. This patch fixes the possible recursive bo::reserve caused by malicious user-space handing a pointer to ttm memory so that the ttm fault handler is called when bos are already reserved. That may cause a (possibly interruptible) livelock. Once that is fixed, we are free to choose the mmap_sem -> bo::reserve locking order. Currently it's bo::reserve->mmap_sem(), but the hack required in the ttm fault handler is admittedly a bit ugly. The plan is to change the locking order to mmap_sem->bo::reserve I'm not sure if it applies to this particular case, but it should be possible to make sure that copy_from_user_inatomic() will always succeed, by making sure the pages are present using get_user_pages(), and release the pages after copy_from_user_inatomic() is done. That way there's no need for a double memcpy slowpath, but if the copied data is very fragmented I guess the resulting code may look ugly. The get_user_pages() function will return an error if it hits TTM pages. /Thomas ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCHv4 0/5] gpu: host1x: Add runtime pm support
On 10/08/2013 12:27 AM, Arto Merilainen wrote: > This series adds runtime pm support for host1x, gr2d and dc. It retains the > current behaviour if CONFIG_PM_RUNTIME is not enabled. > > The gr2d clock is enabled when a new job is submitted and disabled when > the work is done. Due to parent->child relations between host1x->gr2d, this > scheme enables and disables host1x clock. > > For dc, the clocks are enabled in .probe and disabled in .remove via runtime > pm instead of direct clock APIs. > > Mayuresh is unfortunately not available to continue with the series and hence > I will continue working on the patches. The series, briefly, Reviewed-by: Stephen Warren ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC PATCH] drm/radeon: fixup locking inversion between mmap_sem and reservations
On Tue, Oct 08, 2013 at 06:29:35PM +0200, Thomas Hellstrom wrote: > On 10/08/2013 04:55 PM, Jerome Glisse wrote: > >On Tue, Oct 08, 2013 at 04:45:18PM +0200, Christian König wrote: > >>Am 08.10.2013 16:33, schrieb Jerome Glisse: > >>>On Tue, Oct 08, 2013 at 04:14:40PM +0200, Maarten Lankhorst wrote: > Allocate and copy all kernel memory before doing reservations. This > prevents a locking > inversion between mmap_sem and reservation_class, and allows us to drop > the trylocking > in ttm_bo_vm_fault without upsetting lockdep. > > Signed-off-by: Maarten Lankhorst > >>>I would say NAK. Current code only allocate temporary page in AGP case. > >>>So AGP case is userspace -> temp page -> cs checker -> radeon ib. > >>> > >>>Non AGP is directly memcpy to radeon IB. > >>> > >>>Your patch allocate memory memcpy userspace to it and it will then be > >>>memcpy to IB. Which means you introduce an extra memcpy in the process > >>>not something we want. > >>Totally agree. Additional to that there is no good reason to provide > >>anything else than anonymous system memory to the CS ioctl, so the > >>dependency between the mmap_sem and reservations are not really > >>clear to me. > >> > >>Christian. > >I think is that in other code path you take mmap_sem first then reserve > >bo. But here we reserve bo and then we take mmap_sem because of copy > >from user. > > > >Cheers, > >Jerome > > > Actually the log message is a little confusing. I think the mmap_sem > locking inversion problem is orthogonal to what's being fixed here. > > This patch fixes the possible recursive bo::reserve caused by > malicious user-space handing a pointer to ttm memory so that the ttm > fault handler is called when bos are already reserved. That may > cause a (possibly interruptible) livelock. > > Once that is fixed, we are free to choose the mmap_sem -> > bo::reserve locking order. Currently it's bo::reserve->mmap_sem(), > but the hack required in the ttm fault handler is admittedly a bit > ugly. The plan is to change the locking order to > mmap_sem->bo::reserve > > I'm not sure if it applies to this particular case, but it should be > possible to make sure that copy_from_user_inatomic() will always > succeed, by making sure the pages are present using > get_user_pages(), and release the pages after > copy_from_user_inatomic() is done. That way there's no need for a > double memcpy slowpath, but if the copied data is very fragmented I > guess the resulting code may look ugly. The get_user_pages() > function will return an error if it hits TTM pages. > > /Thomas get_user_pages + copy_from_user_inatomic is overkill. We should just do get_user_pages which fails with ttm memory and then use copy_highpage helper. Cheers, Jerome ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 70286] X crashes when using Firefox with logout loop
https://bugs.freedesktop.org/show_bug.cgi?id=70286 Ganesh Hegde changed: What|Removed |Added Severity|major |critical Priority|medium |high -- 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/3] drm: Add separate Kconfig option for fbdev helpers
On Tue, Oct 8, 2013 at 11:44 AM, Daniel Vetter wrote: > For drivers which might want to disable fbdev legacy support. > > Select the new option in all drivers for now, so this shouldn't result > in any change. Drivers need some work anyway to make fbdev support > optional (if they have it implemented, that is), so the recommended > way to expose this is by adding per-driver options. At least as long > as most drivers don't support disabling the fbdev support. > > v2: Update for new drm drivers msm and rcar-du. Note that Rob's msm > driver can already take advantage of this, which allows us to build > msm without any fbdev depencies in the kernel! > > v3: Move the MODULE_* stuff from the fbdev helper file to > drm_crtc_helper.c. > > Cc: David Herrmann > Cc: Rob Clark > Signed-off-by: Daniel Vetter \o/-by: Rob Clark (and also: Reviewed-by: Rob Clark ) > --- > drivers/gpu/drm/Kconfig | 11 ++- > drivers/gpu/drm/Makefile | 3 ++- > drivers/gpu/drm/ast/Kconfig | 1 + > drivers/gpu/drm/cirrus/Kconfig| 1 + > drivers/gpu/drm/drm_crtc_helper.c | 4 > drivers/gpu/drm/drm_fb_helper.c | 4 > drivers/gpu/drm/exynos/Kconfig| 1 + > drivers/gpu/drm/gma500/Kconfig| 1 + > drivers/gpu/drm/mgag200/Kconfig | 1 + > drivers/gpu/drm/msm/Kconfig | 1 + > drivers/gpu/drm/nouveau/Kconfig | 1 + > drivers/gpu/drm/omapdrm/Kconfig | 1 + > drivers/gpu/drm/qxl/Kconfig | 1 + > drivers/gpu/drm/rcar-du/Kconfig | 1 + > drivers/gpu/drm/shmobile/Kconfig | 1 + > drivers/gpu/drm/tilcdc/Kconfig| 1 + > drivers/gpu/drm/udl/Kconfig | 1 + > drivers/gpu/host1x/drm/Kconfig| 1 + > drivers/staging/imx-drm/Kconfig | 1 + > 19 files changed, 31 insertions(+), 6 deletions(-) > > diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig > index 95d..3104b6d 100644 > --- a/drivers/gpu/drm/Kconfig > +++ b/drivers/gpu/drm/Kconfig > @@ -29,11 +29,17 @@ config DRM_USB > config DRM_KMS_HELPER > tristate > depends on DRM > + help > + CRTC helpers for KMS drivers. > + > +config DRM_KMS_FB_HELPER > + bool > + depends on DRM_KMS_HELPER > select FB > select FRAMEBUFFER_CONSOLE if !EXPERT > select FRAMEBUFFER_CONSOLE_DETECT_PRIMARY if FRAMEBUFFER_CONSOLE > help > - FB and CRTC helpers for KMS drivers. > + FBDEV helpers for KMS drivers. > > config DRM_LOAD_EDID_FIRMWARE > bool "Allow to specify an EDID data set instead of probing for it" > @@ -64,6 +70,7 @@ config DRM_GEM_CMA_HELPER > config DRM_KMS_CMA_HELPER > bool > select DRM_GEM_CMA_HELPER > + select DRM_KMS_FB_HELPER > select FB_SYS_FILLRECT > select FB_SYS_COPYAREA > select FB_SYS_IMAGEBLIT > @@ -96,6 +103,7 @@ config DRM_RADEON > select FB_CFB_IMAGEBLIT > select FW_LOADER > select DRM_KMS_HELPER > + select DRM_KMS_FB_HELPER > select DRM_TTM > select POWER_SUPPLY > select HWMON > @@ -130,6 +138,7 @@ config DRM_I915 > select SHMEM > select TMPFS > select DRM_KMS_HELPER > + select DRM_KMS_FB_HELPER > select FB_CFB_FILLRECT > select FB_CFB_COPYAREA > select FB_CFB_IMAGEBLIT > diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile > index f089adf..5af240b 100644 > --- a/drivers/gpu/drm/Makefile > +++ b/drivers/gpu/drm/Makefile > @@ -21,8 +21,9 @@ drm-$(CONFIG_PCI) += ati_pcigart.o > > drm-usb-y := drm_usb.o > > -drm_kms_helper-y := drm_fb_helper.o drm_crtc_helper.o drm_dp_helper.o > +drm_kms_helper-y := drm_crtc_helper.o drm_dp_helper.o > drm_kms_helper-$(CONFIG_DRM_LOAD_EDID_FIRMWARE) += drm_edid_load.o > +drm_kms_helper-$(CONFIG_DRM_KMS_FB_HELPER) += drm_fb_helper.o > drm_kms_helper-$(CONFIG_DRM_KMS_CMA_HELPER) += drm_fb_cma_helper.o > > obj-$(CONFIG_DRM_KMS_HELPER) += drm_kms_helper.o > diff --git a/drivers/gpu/drm/ast/Kconfig b/drivers/gpu/drm/ast/Kconfig > index da4a51e..8a784c4 100644 > --- a/drivers/gpu/drm/ast/Kconfig > +++ b/drivers/gpu/drm/ast/Kconfig > @@ -6,6 +6,7 @@ config DRM_AST > select FB_SYS_FILLRECT > select FB_SYS_IMAGEBLIT > select DRM_KMS_HELPER > + select DRM_KMS_FB_HELPER > select DRM_TTM > help > Say yes for experimental AST GPU driver. Do not enable > diff --git a/drivers/gpu/drm/cirrus/Kconfig b/drivers/gpu/drm/cirrus/Kconfig > index bf67b22..9864559 100644 > --- a/drivers/gpu/drm/cirrus/Kconfig > +++ b/drivers/gpu/drm/cirrus/Kconfig > @@ -5,6 +5,7 @@ config DRM_CIRRUS_QEMU > select FB_SYS_COPYAREA > select FB_SYS_IMAGEBLIT > select DRM_KMS_HELPER > + select DRM_KMS_FB_HELPER > select DRM_TTM > help > This is a KMS driver for emulated cirrus device in qemu. > diff --git a/drivers/gpu/drm/drm_crtc_helper.c > b/drivers/gpu/drm/drm_crtc_helper.c > index 4280e37..c4bfd69 100644 >
Re: [RFC PATCH] drm/radeon: fixup locking inversion between mmap_sem and reservations
On 10/08/2013 06:47 PM, Jerome Glisse wrote: On Tue, Oct 08, 2013 at 06:29:35PM +0200, Thomas Hellstrom wrote: On 10/08/2013 04:55 PM, Jerome Glisse wrote: On Tue, Oct 08, 2013 at 04:45:18PM +0200, Christian König wrote: Am 08.10.2013 16:33, schrieb Jerome Glisse: On Tue, Oct 08, 2013 at 04:14:40PM +0200, Maarten Lankhorst wrote: Allocate and copy all kernel memory before doing reservations. This prevents a locking inversion between mmap_sem and reservation_class, and allows us to drop the trylocking in ttm_bo_vm_fault without upsetting lockdep. Signed-off-by: Maarten Lankhorst I would say NAK. Current code only allocate temporary page in AGP case. So AGP case is userspace -> temp page -> cs checker -> radeon ib. Non AGP is directly memcpy to radeon IB. Your patch allocate memory memcpy userspace to it and it will then be memcpy to IB. Which means you introduce an extra memcpy in the process not something we want. Totally agree. Additional to that there is no good reason to provide anything else than anonymous system memory to the CS ioctl, so the dependency between the mmap_sem and reservations are not really clear to me. Christian. I think is that in other code path you take mmap_sem first then reserve bo. But here we reserve bo and then we take mmap_sem because of copy >from user. Cheers, Jerome Actually the log message is a little confusing. I think the mmap_sem locking inversion problem is orthogonal to what's being fixed here. This patch fixes the possible recursive bo::reserve caused by malicious user-space handing a pointer to ttm memory so that the ttm fault handler is called when bos are already reserved. That may cause a (possibly interruptible) livelock. Once that is fixed, we are free to choose the mmap_sem -> bo::reserve locking order. Currently it's bo::reserve->mmap_sem(), but the hack required in the ttm fault handler is admittedly a bit ugly. The plan is to change the locking order to mmap_sem->bo::reserve I'm not sure if it applies to this particular case, but it should be possible to make sure that copy_from_user_inatomic() will always succeed, by making sure the pages are present using get_user_pages(), and release the pages after copy_from_user_inatomic() is done. That way there's no need for a double memcpy slowpath, but if the copied data is very fragmented I guess the resulting code may look ugly. The get_user_pages() function will return an error if it hits TTM pages. /Thomas get_user_pages + copy_from_user_inatomic is overkill. We should just do get_user_pages which fails with ttm memory and then use copy_highpage helper. Cheers, Jerome Yeah, it may well be that that's the preferred solution. /Thomas ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/i915: revert vga arbiter changes
On Tue, 2013-10-08 at 17:29 +0100, Chris Wilson wrote: > On Tue, Oct 08, 2013 at 10:18:54AM -0600, Alex Williamson wrote: > > On Tue, 2013-10-08 at 17:08 +0100, Chris Wilson wrote: > > > On Tue, Oct 08, 2013 at 05:27:28PM +0200, Daniel Vetter wrote: > > > > Adding drm/i915 into the vga arbiter chain means that X (in a piece of > > > > well-meant paranoia) will do a get/put on the vga decoding around > > > > _every_ accel call down into the ddx. Which results in some nice > > > > performance disasters [1]. > > > > > > And disables DRI for the system, interferring with the use of OpenGL > > > compositors, playing games, PRIME, etc. This effect is not limited to > > > users of i915, but any system with a dGPU and an igfx enabled Core CPU. > > > > > > I still think we are downplaying the complete and utter disaster caused > > > by X and the patch, and why the revert is required. > > > > I'm failing to understand the disaster myself, can you explain? i915 is > > already attempting to make use of the VGA arbiter, but the code hadn't > > been updated so what it was doing was ineffective. The external > > difference I see is that before i915 incorrectly reported that it was > > not involved in VGA arbitration (even though it still claims VGA > > transactions). With the fixes, it opts-out of MMIO arbitration, but > > requires I/O port arbitration. I'm OK with reverting these and going > > back to the drawing board for v3.13, but what i915 is doing is still > > incorrect and precludes making use of a guest assigned VGA device (or > > separate display server requiring VGA), because we can't use the VGA > > arbiter for what it's designed to do, re-route VGA accesses. Thanks, > > The problem stems from the system reporting to X that there are two > legacy vga IO capable devices, and then X disabling DRI and wrapping > every operation with vga_get/vga_put. X will do this even if it is only > using one of the devices and the other device is not being used by the > system. > > We are not arguing that your fix isn't correct, it is just the > rammifications it has to the existing install base outweighs improving > a currently broken feature. Sure, my use case is not a priority. Do you have any thoughts on how we can redesign the interface? For my use for VM access, I'm pretty much resolved and OK with the fact that VGA access is slow. Without para-virtualizing VGA, I can't predict or batch accesses, so I take the arbiter lock for the appropriate resource around each individual access. If the lock is contended, VM boot can be painful, but eventually accelerated drivers take over and VGA access becomes rare. I know Ville was concerned about stopped processes holding the lock when i915 needs it. In my case, that can't happen because the VGA arbiter lock is handled within the VFIO interface. A read/write to the device file descriptor will grab and release the lock internally. It's hard to get around the benefits of knowing your access pattern and batching accesses within a lock, but I wonder if VGA arbiter's lazy switching would be sufficient to provide a general purpose legacy VGA file descriptor that X could open and use for all VGA accesses. For example, pci-sysfs will provide legacy I/O interfaces for some architectures, and I think X already makes use of these. What if they were provided on x86 and allowed read/write to VGA ranges wrapped in VGA arbiter locks? Thanks, Alex ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 68792] Problems during playback of h264 files using UVD and VLC on AMD E-350 CPU
https://bugs.freedesktop.org/show_bug.cgi?id=68792 --- Comment #2 from Grigori Goronzy --- Created attachment 87295 --> https://bugs.freedesktop.org/attachment.cgi?id=87295&action=edit Proposed fix for #2 This patch should fix issue #2 and probably fixes the stalling, too. I can play the "killa sample" without lag with CPU clock fixed to 800 MHz now. -- 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: [Linaro-mm-sig] thoughts of looking at android fences
On Wed, Oct 2, 2013 at 11:13 AM, Erik Gilling wrote: > On Wed, Oct 2, 2013 at 12:35 AM, Maarten Lankhorst > wrote: >> Depending on feedback I'll try reflashing my nexus 7 to stock android, and >> work on trying to convert android >> syncpoints to dma-fence, which I'll probably rename to syncpoints. > > I thought the plan decided at plumbers was to investigate backing > dma_buf with the android sync solution not the other way around. It > doesn't make sense to me to take a working, tested, end-to-end > solution with a released compositing system built around it, throw it > out, and replace it with new un-tested code to > support a system which is not yet built. Hey Erik, Thanks for the clarifying points in your email, your insights and feedback are critical, and I think having you and Maarten continue to work out the details here will make this productive. My recollection from the discussion was that Rob was ok with trying to pipe the sync arguments through the various interfaces in order to support the explicit sync, but I think he did suggest having it backed by the dma-buf fences underneath. I know this can be frustrating to watch things be reimplemented when you have a pre-baked solution, but some compromise will be needed to get things merged (and Maarten is taking the initiative here), but its important to keep discussing this so the *right* compromises are made that don't hurt performance, etc. My hope is Maarten's approach of getting the dma-fence core integrated, and then moving the existing Android sync interface over to the shared back-end, will allow for proper apples-to-apples comparisons of the same interface. And if the functionality isn't sufficient we can hold off on merging the sync interface conversion until that gets resolved. Does that sound reasonable? thanks -john ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 62721] GPU lockup: radeon 0000:01:00.0: GPU lockup CP stall for more than 10000msec...
https://bugzilla.kernel.org/show_bug.cgi?id=62721 Alex Deucher changed: What|Removed |Added CC||alexdeuc...@gmail.com --- Comment #2 from Alex Deucher --- Please attach your full dmesg output. What GPU is this? Are you sure cb51bb7107aa040f9779be931e3bd6a7b50e0f69 is the correct commit? That commit only affects the debugfs output. If you don't access those debugfs files, that code in question is never called. Did you also happen to update your userspace drivers (mesa or xf86-video-ati)? -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 70169] taskbar is white when using kwin GLES
https://bugs.freedesktop.org/show_bug.cgi?id=70169 Ian Romanick changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |NOTOURBUG --- Comment #2 from Ian Romanick --- It appears that kwin's shaders are incorrect. In 9.2 we fixed a deviation from the GLSL ES specification (that is followed by numerous other vendors) that we did not require precision qualifiers for float types in the fragment shader. They just need to add: precision float; the their fragment shaders. In OpenGL ES 3.0, highp must be supported, but in ES 2.0 it is optional. See the following commit: commit cabd45773b58d6aa48202da1cdd8cf1a6b856c53 Author: Ian Romanick Date: Fri Aug 9 15:17:18 2013 -0700 glsl: Track existence of default float precision in GLSL ES fragment shaders This is required by the spec, and it's a bit tricky because the default precision is scoped. As a result, I'm slightly abusing the symbol table. Fixes piglit no-default-float-precision.frag tests and the piglit default-precision-nested-scope-0[1234].frag tests that are currently on the piglit mailing list for review. On IRC I got confirmation from cwabbot that ARM (Mali T6xx and T400) enforces this requirement and from kusma that NVIDIA (Tegra2) enforces this requirement. We should be safe from regressing shipping applications. Signed-off-by: Ian Romanick Reviewed-by: Kenneth Graunke Cc: "9.2" -- 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: [RFCv1 11/12] drm: Atomic modeset ioctl
On Mon, Oct 07, 2013 at 05:18:02PM +0300, Ville Syrjälä wrote:
> On Mon, Oct 07, 2013 at 09:55:47AM -0400, Rob Clark wrote:
> > On Mon, Oct 7, 2013 at 9:28 AM, Ville Syrjälä
> > wrote:
> > > On Sat, Oct 05, 2013 at 08:45:49PM -0400, Rob Clark wrote:
...
> > >> +
> > >> + state = dev->driver->atomic_begin(dev, arg->flags);
> > >> + if (IS_ERR(state)) {
> > >> + ret = PTR_ERR(state);
> > >> + goto unlock;
> > >> + }
> > >> +
> > >> + for (i = 0; i < arg->count_objs; i++) {
> > >> + uint32_t obj_id, count_props;
> > >> + struct drm_mode_object *obj;
> > >> +
> > >> + if (get_user(obj_id, objs_ptr + copied_objs)) {
> > >> + ret = -EFAULT;
> > >> + goto out;
> > >> + }
> > >> +
> > >> + obj = drm_mode_object_find(dev, obj_id,
> > >> DRM_MODE_OBJECT_ANY);
> > >> + if (!obj || !obj->properties) {
> > >> + ret = -ENOENT;
> > >> + goto out;
> > >> + }
> > >> +
> > >> + if (arg->flags & DRM_MODE_ATOMIC_EVENT) {
> > >> + // XXX create atomic event instead..
> > >
> > > Some people are apparently more comfortable with a per-crtc event
> > > rather than the per-obj events I added. So I think we might want
> > > both in the end.
> >
> > yeah, sorting out events is a bit 'TODO' at the moment. I do kind of
> > like per-crtc event.. it seems easier to implement and I'm not really
> > sure what finer event granularity buys us.
>
> Mainly it gets you the old fb. If you limit youself to < vrefresh it's
> not a big deal, but going faster than that and you start to want that
> information.
Are there cases where userspace would really need this fb information
returned? I'm having trouble envisioning a case where userspace
wouldn't have its own bookkeeping to know which fb's are currently
displayed on each plane and which fb's are pending.
If you're running a compositor like Weston, the redraw of a display is
generally tied to completion events, so there's no real desire/potential
for > vrefresh submission in most cases. In this model, having a single
per-crtc "I'm done updating everything" event is easier to work with
than an event per object where you have to do some additional counting
to make sure you consume the right number of events before kicking off
the repaint.
>
> >
> > BR,
> > -R
> >
> >> + struct drm_pending_vblank_event *e =
> > >> + create_vblank_event(dev, file_priv,
> > >> arg->user_data);
> > >> + if (!e) {
> > >> + ret = -ENOMEM;
> > >> + goto out;
> > >> + }
> > >> + ret = dev->driver->atomic_set_event(dev, state,
> > >> obj, e);
> > >> + if (ret) {
> > >> + destroy_vblank_event(dev, file_priv, e);
> > >> + goto out;
> > >> + }
> > >> + }
Did you mean to use the drm_pending_atomic_event/drm_event_atomic you
declare farther down? It doesn't look like anything is actually using
them yet in this patch series.
> > >> +
> > >> + if (get_user(count_props, count_props_ptr + copied_objs)) {
> > >> + ret = -EFAULT;
> > >> + goto out;
> > >> + }
> > >> +
> > >> + copied_objs++;
> > >> +
> > >> + for (j = 0; j < count_props; j++) {
> > >> + uint32_t prop_id;
> > >> + uint64_t prop_value;
> > >> + struct drm_mode_object *prop_obj;
> > >> + struct drm_property *prop;
> > >> + void *blob_data = NULL;
> > >> +
> > >> + if (get_user(prop_id, props_ptr + copied_props)) {
> > >> + ret = -EFAULT;
> > >> + goto out;
> > >> + }
> > >> +
> > >> + if (!object_has_prop(obj, prop_id)) {
> > >> + ret = -EINVAL;
> > >> + goto out;
> > >> + }
> > >> +
> > >> + prop_obj = drm_mode_object_find(dev, prop_id,
> > >> + DRM_MODE_OBJECT_PROPERTY);
> > >> + if (!prop_obj) {
> > >> + ret = -ENOENT;
> > >> + goto out;
> > >> + }
> > >> + prop = obj_to_property(prop_obj);
> > >> +
> > >> + if (get_user(prop_value, prop_values_ptr +
> > >> copied_props)) {
> > >> + ret = -EFAULT;
> > >> + goto out;
> > >> + }
> > >> +
> > >> + if (!drm_property_change_is_valid(prop,
> > >> p
[Bug 68792] Problems during playback of h264 files using UVD and VLC on AMD E-350 CPU
https://bugs.freedesktop.org/show_bug.cgi?id=68792 --- Comment #3 from Christian König --- The patches look good to me. Have you already submitted them to the list? If not please do so. Christian. -- 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: [RFCv1 11/12] drm: Atomic modeset ioctl
On Tue, Oct 8, 2013 at 2:35 PM, Matt Roper wrote:
> On Mon, Oct 07, 2013 at 05:18:02PM +0300, Ville Syrjälä wrote:
>> On Mon, Oct 07, 2013 at 09:55:47AM -0400, Rob Clark wrote:
>> > On Mon, Oct 7, 2013 at 9:28 AM, Ville Syrjälä
>> > wrote:
>> > > On Sat, Oct 05, 2013 at 08:45:49PM -0400, Rob Clark wrote:
> ...
>> > >> +
>> > >> + state = dev->driver->atomic_begin(dev, arg->flags);
>> > >> + if (IS_ERR(state)) {
>> > >> + ret = PTR_ERR(state);
>> > >> + goto unlock;
>> > >> + }
>> > >> +
>> > >> + for (i = 0; i < arg->count_objs; i++) {
>> > >> + uint32_t obj_id, count_props;
>> > >> + struct drm_mode_object *obj;
>> > >> +
>> > >> + if (get_user(obj_id, objs_ptr + copied_objs)) {
>> > >> + ret = -EFAULT;
>> > >> + goto out;
>> > >> + }
>> > >> +
>> > >> + obj = drm_mode_object_find(dev, obj_id,
>> > >> DRM_MODE_OBJECT_ANY);
>> > >> + if (!obj || !obj->properties) {
>> > >> + ret = -ENOENT;
>> > >> + goto out;
>> > >> + }
>> > >> +
>> > >> + if (arg->flags & DRM_MODE_ATOMIC_EVENT) {
>> > >> + // XXX create atomic event instead..
>> > >
>> > > Some people are apparently more comfortable with a per-crtc event
>> > > rather than the per-obj events I added. So I think we might want
>> > > both in the end.
>> >
>> > yeah, sorting out events is a bit 'TODO' at the moment. I do kind of
>> > like per-crtc event.. it seems easier to implement and I'm not really
>> > sure what finer event granularity buys us.
>>
>> Mainly it gets you the old fb. If you limit youself to < vrefresh it's
>> not a big deal, but going faster than that and you start to want that
>> information.
>
> Are there cases where userspace would really need this fb information
> returned? I'm having trouble envisioning a case where userspace
> wouldn't have its own bookkeeping to know which fb's are currently
> displayed on each plane and which fb's are pending.
if you let userspace flip faster than vsync, then there is some
ambiguity about which buffer is being scanned out after the vblank..
but I think this shouldn't hold up atomic-modeset.. it should be safe
to spiff up the events as a later step.
> If you're running a compositor like Weston, the redraw of a display is
> generally tied to completion events, so there's no real desire/potential
> for > vrefresh submission in most cases. In this model, having a single
> per-crtc "I'm done updating everything" event is easier to work with
> than an event per object where you have to do some additional counting
> to make sure you consume the right number of events before kicking off
> the repaint.
>
>
>>
>> >
>> > BR,
>> > -R
>> >
>> >> + struct drm_pending_vblank_event *e =
>> > >> + create_vblank_event(dev, file_priv,
>> > >> arg->user_data);
>> > >> + if (!e) {
>> > >> + ret = -ENOMEM;
>> > >> + goto out;
>> > >> + }
>> > >> + ret = dev->driver->atomic_set_event(dev, state,
>> > >> obj, e);
>> > >> + if (ret) {
>> > >> + destroy_vblank_event(dev, file_priv, e);
>> > >> + goto out;
>> > >> + }
>> > >> + }
>
> Did you mean to use the drm_pending_atomic_event/drm_event_atomic you
> declare farther down? It doesn't look like anything is actually using
> them yet in this patch series.
right.. the event stuff is a bit messy at the moment as result of
merging of two different RFC patchsets about how to do atomic.
I think what I will end up doing is drop the atomic event, and fix up
the logic to only create/set vblank events for the crtc(s).
BR,
-R
>> > >> +
>> > >> + if (get_user(count_props, count_props_ptr + copied_objs))
>> > >> {
>> > >> + ret = -EFAULT;
>> > >> + goto out;
>> > >> + }
>> > >> +
>> > >> + copied_objs++;
>> > >> +
>> > >> + for (j = 0; j < count_props; j++) {
>> > >> + uint32_t prop_id;
>> > >> + uint64_t prop_value;
>> > >> + struct drm_mode_object *prop_obj;
>> > >> + struct drm_property *prop;
>> > >> + void *blob_data = NULL;
>> > >> +
>> > >> + if (get_user(prop_id, props_ptr + copied_props)) {
>> > >> + ret = -EFAULT;
>> > >> + goto out;
>> > >> + }
>> > >> +
>> > >> + if (!object_has_prop(obj, prop_id)) {
>> > >> + ret = -EINVAL;
>> > >> + goto out;
>> > >> + }
>> > >> +
>> > >> +
Re: [Linaro-mm-sig] thoughts of looking at android fences
On Wed, Oct 2, 2013 at 2:13 PM, Erik Gilling wrote: >> The lock is provided by the driver, which makes adding support for old >> hardware that has no reliable way of notifying completion of events easier. > > I'm a bit confused here how it's possible to implement sync on > hardware with "no reliable way of notifying completion of events." That > seems like a non-starter to me. I suspect Maarten meant "no reliable way of notifying completion *to the cpu*".. which isn't strictly needed for gpu<->gpu sharing. BR, -R ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Linaro-mm-sig] thoughts of looking at android fences
On Tue, Oct 8, 2013 at 1:37 PM, John Stultz wrote: > On Wed, Oct 2, 2013 at 11:13 AM, Erik Gilling wrote: >> On Wed, Oct 2, 2013 at 12:35 AM, Maarten Lankhorst >> wrote: >>> Depending on feedback I'll try reflashing my nexus 7 to stock android, and >>> work on trying to convert android >>> syncpoints to dma-fence, which I'll probably rename to syncpoints. >> >> I thought the plan decided at plumbers was to investigate backing >> dma_buf with the android sync solution not the other way around. It >> doesn't make sense to me to take a working, tested, end-to-end >> solution with a released compositing system built around it, throw it >> out, and replace it with new un-tested code to >> support a system which is not yet built. > > Hey Erik, > Thanks for the clarifying points in your email, your insights and > feedback are critical, and I think having you and Maarten continue to > work out the details here will make this productive. > > My recollection from the discussion was that Rob was ok with trying to > pipe the sync arguments through the various interfaces in order to > support the explicit sync, but I think he did suggest having it backed > by the dma-buf fences underneath. Yeah, my comment was mainly about userspace API for different driver subsystems. I'd rather add some extra parameter(s?) to drm and v4l ioctls, even if they are unused by linux userspace, vs having different ABI for android kernel vs linux kernel. We probably do however need the zero value to indicate unusued.. at least for adding new parameters to existing drm ioctls since drm_ioctl() will be zero'ing stuff out to deal w/ new userspace / old kernel, or old userspace / new kernel combos. For new ioctls (like 'atomic') we don't have this constraint. BR, -R > I know this can be frustrating to watch things be reimplemented when > you have a pre-baked solution, but some compromise will be needed to > get things merged (and Maarten is taking the initiative here), but its > important to keep discussing this so the *right* compromises are made > that don't hurt performance, etc. > > My hope is Maarten's approach of getting the dma-fence core > integrated, and then moving the existing Android sync interface over > to the shared back-end, will allow for proper apples-to-apples > comparisons of the same interface. And if the functionality isn't > sufficient we can hold off on merging the sync interface conversion > until that gets resolved. > > Does that sound reasonable? > > thanks > -john > ___ > 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
Re: [PATCH 7/9] drm/gma500: use gem get/put page helpers
On Wed, Aug 07, 2013 at 01:41:25PM -0400, Rob Clark wrote: > Signed-off-by: Rob Clark > --- > drivers/gpu/drm/gma500/gtt.c | 38 ++ > 1 file changed, 6 insertions(+), 32 deletions(-) > [ snip ] This is quite late to report, but I've just begun testing 3.12, and this patch makes my screen garbled when using the modesetting xorg driver. So far it looks like the buffer that the xorg driver gets is not the one that is actually mapped by the kernel. I'm currently trying to know what exactly causes the problem, but I don't know anything about the internals here... I doubt it will help, but the fbdev driver still works with this patch. - Guillaume ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: i915 deadlock on laptop undock
On Tue, Oct 8, 2013 at 6:08 PM, Roland Dreier wrote: > On Mon, Oct 7, 2013 at 11:10 PM, Daniel Vetter wrote: >> Can you please boot with drm.debug=0xe, reproduce the issue and then >> attach the dmesg. The additional debug spam should shed some light on how >> we managed to get into this peculiar situation ... > > Sure, here it is. As suspected a DP screen, and we disconnect right before a modeset sequence. The unexpected thing here is that the modeset santizer kicks in and wreaks utter havoc due to a lid event. Now we shouldn't hang the entire box fundamentally when we unplug the DP cable, and that's a bug in the DP code. It's also quite some work. But we also should be a bit less enthusiastic with wreaking havoc in the lid noifier, and I think that can be fixed quickly. I'll reply with some patch. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 7/9] drm/gma500: use gem get/put page helpers
On Tue, Oct 8, 2013 at 10:19 PM, Rob Clark wrote: > On Tue, Oct 8, 2013 at 3:57 PM, Guillaume CLÉMENT wrote: >> On Wed, Aug 07, 2013 at 01:41:25PM -0400, Rob Clark wrote: >>> Signed-off-by: Rob Clark >>> --- >>> drivers/gpu/drm/gma500/gtt.c | 38 ++ >>> 1 file changed, 6 insertions(+), 32 deletions(-) >>> [ snip ] >> >> This is quite late to report, but I've just begun testing 3.12, and this >> patch makes my screen garbled when using the modesetting xorg driver. >> >> So far it looks like the buffer that the xorg driver gets is >> not the one that is actually mapped by the kernel. >> >> I'm currently trying to know what exactly causes the problem, but I don't >> know anything about the internals here... >> > > could you try this small patch.. I think I missed something w/ my > original patch (sorry, no hw to test on here): > > -- > diff --git a/drivers/gpu/drm/gma500/gtt.c b/drivers/gpu/drm/gma500/gtt.c > index 92babac..2db731f 100644 > --- a/drivers/gpu/drm/gma500/gtt.c > +++ b/drivers/gpu/drm/gma500/gtt.c > @@ -204,6 +204,7 @@ static int psb_gtt_attach_pages(struct gtt_range *gt) > if (IS_ERR(pages)) > return PTR_ERR(pages); > > +gt->npage = gt->gem.size / PAGE_SIZE; > gt->pages = pages; > > return 0; > -- > Rob, if this works, can you please make sure it goes into Dave's tree. I'm currently travelling and I'll be away for at least one week. Thanks Patrik ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/gma500: fix things after get/put page helpers
Commit 8b9ba7a3 'drm/gma500: use gem get/put page helpers' was missing a line, which resulted in garbled screen. Signed-off-by: Rob Clark Tested-by: Guillaume CLÉMENT --- drivers/gpu/drm/gma500/gtt.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/gpu/drm/gma500/gtt.c b/drivers/gpu/drm/gma500/gtt.c index 92babac..2db731f 100644 --- a/drivers/gpu/drm/gma500/gtt.c +++ b/drivers/gpu/drm/gma500/gtt.c @@ -204,6 +204,7 @@ static int psb_gtt_attach_pages(struct gtt_range *gt) if (IS_ERR(pages)) return PTR_ERR(pages); + gt->npage = gt->gem.size / PAGE_SIZE; gt->pages = pages; return 0; -- 1.8.3.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 7/9] drm/gma500: use gem get/put page helpers
> This is quite late to report, but I've just begun testing 3.12, and this > patch makes my screen garbled when using the modesetting xorg driver. > Alright, after trying to notice what was different between the old and new code, I've found the culprit : - gt->npage = pages; There is no equivalent of this line with the new code. This must mess things up. By writing: gt->npage = gt->gem.size / PAGE_SIZE; after: gt->npage = pages; I don't experience the problem anymore. If this looks good to you, I'll create a patch for this. Thanks, - Guillaume ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 7/9] drm/gma500: use gem get/put page helpers
On Tue, Oct 8, 2013 at 3:57 PM, Guillaume CLÉMENT wrote: > On Wed, Aug 07, 2013 at 01:41:25PM -0400, Rob Clark wrote: >> Signed-off-by: Rob Clark >> --- >> drivers/gpu/drm/gma500/gtt.c | 38 ++ >> 1 file changed, 6 insertions(+), 32 deletions(-) >> [ snip ] > > This is quite late to report, but I've just begun testing 3.12, and this > patch makes my screen garbled when using the modesetting xorg driver. > > So far it looks like the buffer that the xorg driver gets is > not the one that is actually mapped by the kernel. > > I'm currently trying to know what exactly causes the problem, but I don't > know anything about the internals here... > could you try this small patch.. I think I missed something w/ my original patch (sorry, no hw to test on here): -- diff --git a/drivers/gpu/drm/gma500/gtt.c b/drivers/gpu/drm/gma500/gtt.c index 92babac..2db731f 100644 --- a/drivers/gpu/drm/gma500/gtt.c +++ b/drivers/gpu/drm/gma500/gtt.c @@ -204,6 +204,7 @@ static int psb_gtt_attach_pages(struct gtt_range *gt) if (IS_ERR(pages)) return PTR_ERR(pages); +gt->npage = gt->gem.size / PAGE_SIZE; gt->pages = pages; return 0; -- > > I doubt it will help, but the fbdev driver still works with this patch. > > > - Guillaume ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 69120] With dpm=1 vdpau is not usable
https://bugs.freedesktop.org/show_bug.cgi?id=69120 --- Comment #21 from Karl Miller --- Well it's still not working with my 6870. Sometimes the Video starts fine, but most of the time it stutters with dpm enabled, and most of the time one pause is enough for the video to start stuttering again. -- 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 69120] With dpm=1 vdpau is not usable
https://bugs.freedesktop.org/show_bug.cgi?id=69120 --- Comment #22 from Karl Miller --- Created attachment 87301 --> https://bugs.freedesktop.org/attachment.cgi?id=87301&action=edit Karl's vbios -- 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 69120] With dpm=1 vdpau is not usable
https://bugs.freedesktop.org/show_bug.cgi?id=69120 --- Comment #23 from Karl Miller --- Created attachment 87302 --> https://bugs.freedesktop.org/attachment.cgi?id=87302&action=edit Karl's dmesg -- 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 3/5] tty/vt: add con_bind and con_unbind functions
2013/10/1 Ville Syrjälä :
> On Thu, Sep 26, 2013 at 08:06:00PM -0300, Paulo Zanoni wrote:
>> From: Paulo Zanoni
>>
>> The consoles who need to do something when unbinding or binding can
>> optionally implement these functions.
>>
>> The current problem I'm trying to solve is that when i915+fbcon is
>> loaded on Haswell, if we disable the power well (to save power) the
>> VGA interface gets completely disabled, so when we unbind fbcon we
>> need to restore the VGA interface to allow vgacon to work.
>
> We don't need to make it work. No one else does, and in the general case
> it's even impossible since on some hardware that would definitely
> corrupt the state that the real driver is attempting to use. The only
> case where it might be nice to restore vgacon is on i915 unload, but no
> one else does that either AFAIK, so I would not waste any cycles on
> attempting that.
I don't understand your point. Without patches 3-4-5, module_reload
doesn't work at all if the power well is disabled: we need these
patches to fix it. The plan is not to restore everything to make
vgacon actually work, the plan is just to prevent it from breaking
module_reload.
>
>>
>> Signed-off-by: Paulo Zanoni
>> ---
>> drivers/tty/vt/vt.c | 6 ++
>> include/linux/console.h | 2 ++
>> 2 files changed, 8 insertions(+)
>>
>> diff --git a/drivers/tty/vt/vt.c b/drivers/tty/vt/vt.c
>> index 9a8e8c5..beb5986 100644
>> --- a/drivers/tty/vt/vt.c
>> +++ b/drivers/tty/vt/vt.c
>> @@ -3014,6 +3014,9 @@ static int do_bind_con_driver(const struct consw *csw,
>> int first, int last,
>> if (retval)
>> goto err;
>>
>> + if (csw->con_bind)
>> + csw->con_bind();
>> +
>> if (!(con_driver->flag & CON_DRIVER_FLAG_INIT)) {
>> csw->con_startup();
>> con_driver->flag |= CON_DRIVER_FLAG_INIT;
>> @@ -3152,6 +3155,9 @@ int do_unbind_con_driver(const struct consw *csw, int
>> first, int last, int deflt
>> if (!con_is_bound(csw))
>> goto err;
>>
>> + if (csw->con_unbind)
>> + csw->con_unbind();
>> +
>> first = max(first, con_driver->first);
>> last = min(last, con_driver->last);
>>
>> diff --git a/include/linux/console.h b/include/linux/console.h
>> index 7571a16..5cd2c35 100644
>> --- a/include/linux/console.h
>> +++ b/include/linux/console.h
>> @@ -65,6 +65,8 @@ struct consw {
>>* Restore the console to its pre-debug state as closely as possible.
>>*/
>> int (*con_debug_leave)(struct vc_data *);
>> + void(*con_bind)(void);
>> + void(*con_unbind)(void);
>> };
>>
>> extern const struct consw *conswitchp;
>> --
>> 1.8.3.1
>>
>> ___
>> dri-devel mailing list
>> dri-devel@lists.freedesktop.org
>> http://lists.freedesktop.org/mailman/listinfo/dri-devel
>
> --
> Ville Syrjälä
> Intel OTC
--
Paulo Zanoni
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Nouveau] [PATCH] drm/nouveau: suspend to D3hot, not to D3cold
On Wed, Oct 9, 2013 at 1:36 AM, Maarten Lankhorst wrote: > In the autumn and winter it's considered bad form to set power state to > D3cold, it might > cause the device to freeze to death. This is also the case in the other > seasons, so any > device in the southern hemisphere is affected too. > > D3cold is not a valid state in a call to pci_set_power_state, only up to > D3hot is allowed. NAK, pci_set_power_state calls pci_platform_pm->set_state, which should be acpi_pci_set_power_state, which clearly accepts D3cold as a parameter. The only reason the HDMI audio driver doesn't use D3cold is because it has no acpi handle for the device. Dave. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 63997] Artifacts using a HD7480D on a A4-5300 APU
https://bugs.freedesktop.org/show_bug.cgi?id=63997 --- Comment #19 from bgunte...@gmail.com --- what other information do you need??? -- 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 62721] GPU lockup: radeon 0000:01:00.0: GPU lockup CP stall for more than 10000msec...
https://bugzilla.kernel.org/show_bug.cgi?id=62721 --- Comment #3 from Egor Y. Egorov --- (In reply to Alex Deucher from comment #2) > Please attach your full dmesg output. Why "journalctl -a" not enough? If that need I'll post dmesg soon. > What GPU is this? RV570 > Are you sure cb51bb7107aa040f9779be931e3bd6a7b50e0f69 is the correct commit? > That commit only affects the debugfs output. If you don't access those > debugfs files, that code in question is never called. Perhaps the fault is not that commit, but 3.11.3 worked entirely without problems. After the upgrade to 3.11.4 similar problems began to arise. I tried to roll back this commit, and was able to work at a computer for long enough. In any case, I will test again. > Did you also happen to update your userspace drivers (mesa or xf86-video-ati)? xf86-video-ati and mesa has not been updated in my system for a long time. -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[DRM_CURRUS_QEMU/timer] WARNING: CPU: 0 PID: 1 at debug_print_object()
Hi all, It's this one config that triggers the oops: CONFIG_DRM_CIRRUS_QEMU Full kconfig is attached. CONFIG_DEBUG_LIST has been enabled. What's interesting is that parport_pc is showing up in the call traces. dmesg log for two kernel boots: % kvm-0day.sh arch/x86/boot/bzImage [0.00] Initializing cgroup subsys cpuset [0.00] Initializing cgroup subsys cpu [0.00] Linux version 3.11.0-rc2-00010-gc817a67-dirty (wfg at bee) (gcc version 4.6.3 (Debian 4.6.3-1) ) #21 SMP PREEMPT Tue Oct 8 12:13:02 CST 2013 [0.00] Command line: hung_task_panic=1 rcutree.rcu_cpu_stall_timeout=100 log_buf_len=8M debug sched_debug ignore_loglevel apic=debug dynamic_printk sysrq_always_enabled panic=10 prompt_ramdisk=0 console=ttyS0,115200 console=tty0 vga=normal root=/dev/ram0 rw [0.00] e820: BIOS-provided physical RAM map: [0.00] BIOS-e820: [mem 0x-0x0009fbff] usable [0.00] BIOS-e820: [mem 0x0009fc00-0x0009] reserved [0.00] BIOS-e820: [mem 0x000f-0x000f] reserved [0.00] BIOS-e820: [mem 0x0010-0x0fffdfff] usable [0.00] BIOS-e820: [mem 0x0fffe000-0x0fff] reserved [0.00] BIOS-e820: [mem 0xfeffc000-0xfeff] reserved [0.00] BIOS-e820: [mem 0xfffc-0x] reserved [0.00] debug: ignoring loglevel setting. [0.00] NX (Execute Disable) protection: active [0.00] Hypervisor detected: KVM [0.00] e820: update [mem 0x-0x0fff] usable ==> reserved [0.00] e820: remove [mem 0x000a-0x000f] usable [0.00] e820: last_pfn = 0xfffe max_arch_pfn = 0x4 [0.00] Scan for SMP in [mem 0x-0x03ff] [0.00] Scan for SMP in [mem 0x0009fc00-0x0009] [0.00] Scan for SMP in [mem 0x000f-0x000f] [0.00] found SMP MP-table at [mem 0x000f1840-0x000f184f] mapped at [880f1840] [0.00] mpc: f1850-f193c [0.00] Base memory trampoline at [88099000] 99000 size 24576 [0.00] init_memory_mapping: [mem 0x-0x000f] [0.00] [mem 0x-0x000f] page 4k [0.00] BRK [0x0287, 0x02870fff] PGTABLE [0.00] BRK [0x02871000, 0x02871fff] PGTABLE [0.00] BRK [0x02872000, 0x02872fff] PGTABLE [0.00] init_memory_mapping: [mem 0x0e60-0x0e7f] [0.00] [mem 0x0e60-0x0e7f] page 4k [0.00] BRK [0x02873000, 0x02873fff] PGTABLE [0.00] init_memory_mapping: [mem 0x0c00-0x0e5f] [0.00] [mem 0x0c00-0x0e5f] page 4k [0.00] BRK [0x02874000, 0x02874fff] PGTABLE [0.00] init_memory_mapping: [mem 0x0010-0x0bff] [0.00] [mem 0x0010-0x0bff] page 4k [0.00] init_memory_mapping: [mem 0x0e80-0x0fffdfff] [0.00] [mem 0x0e80-0x0fffdfff] page 4k [0.00] log_buf_len: 8388608 [0.00] early log buf free: 128344(97%) [0.00] RAMDISK: [mem 0x0e8d6000-0x0ffe] [0.00] ACPI: RSDP 000f16b0 00014 (v00 BOCHS ) [0.00] ACPI: RSDT 0fffe3f0 00034 (v01 BOCHS BXPCRSDT 0001 BXPC 0001) [0.00] ACPI: FACP 0f80 00074 (v01 BOCHS BXPCFACP 0001 BXPC 0001) [0.00] ACPI: DSDT 0fffe430 01137 (v01 BXPC BXDSDT 0001 INTL 20100528) [0.00] ACPI: FACS 0f40 00040 [0.00] ACPI: SSDT 06a0 00899 (v01 BOCHS BXPCSSDT 0001 BXPC 0001) [0.00] ACPI: APIC 05b0 00080 (v01 BOCHS BXPCAPIC 0001 BXPC 0001) [0.00] ACPI: HPET 0570 00038 (v01 BOCHS BXPCHPET 0001 BXPC 0001) [0.00] ACPI: Local APIC address 0xfee0 [0.00] mapped APIC to ff5bb000 (fee0) [0.00] kvm-clock: Using msrs 4b564d01 and 4b564d00 [0.00] kvm-clock: cpu 0, msr 0:e896001, boot clock [0.00] Zone ranges: [0.00] DMA32[mem 0x1000-0x] [0.00] Normal empty [0.00] Movable zone start for each node [0.00] Early memory node ranges [0.00] node 0: [mem 0x1000-0x0009efff] [0.00] node 0: [mem 0x0010-0x0fffdfff] [0.00] On node 0 totalpages: 65436 [0.00] DMA32 zone: 1024 pages used for memmap [0.00] DMA32 zone: 21 pages reserved [0.00] DMA32 zone: 65436 pages, LIFO batch:15 [0.00] ACPI: PM-Timer IO Port: 0xb008 [0.00] ACPI: Local APIC address 0xfee0 [0.00] mapped APIC to ff5bb000 (fee0) [0.00] ACPI: LAPIC (acpi_id[0x00] lapic_id[0x00] enabled) [0.00] ACPI: LAPIC (acpi_id[0x01] lapic_id[0x01] enabled) [0.00] ACPI: LAPIC_NMI (acpi_id[0xff] dfl dfl lint[0x1]) [0.00] ACPI: IOAPIC (id[0x00] address[0xfec0] gsi_base[0]) [0.00] I
i915 deadlock on laptop undock
On Mon, Oct 7, 2013 at 11:10 PM, Daniel Vetter wrote: > Can you please boot with drm.debug=0xe, reproduce the issue and then > attach the dmesg. The additional debug spam should shed some light on how > we managed to get into this peculiar situation ... Sure, here it is. Thanks, Roland -- next part -- [0.00] Initializing cgroup subsys cpuset [0.00] Initializing cgroup subsys cpu [0.00] Initializing cgroup subsys cpuacct [0.00] Linux version 3.12.0-999-generic (apw at gomeisa) (gcc version 4.6.3 (Ubuntu/Linaro 4.6.3-1ubuntu5) ) #201310070425 SMP Mon Oct 7 08:27:26 UTC 2013 [0.00] Command line: BOOT_IMAGE=/boot/vmlinuz-3.12.0-999-generic root=UUID=677292b2-a7ba-4d9e-8f1a-662c546b62ce ro intel_iommu=igfx_off plymouth:debug splash drm.debug=0xe log_buf_len=8388608 quiet [0.00] KERNEL supported cpus: [0.00] Intel GenuineIntel [0.00] AMD AuthenticAMD [0.00] Centaur CentaurHauls [0.00] e820: BIOS-provided physical RAM map: [0.00] BIOS-e820: [mem 0x-0x0009e7ff] usable [0.00] BIOS-e820: [mem 0x0009e800-0x0009] reserved [0.00] BIOS-e820: [mem 0x000d2000-0x000d3fff] reserved [0.00] BIOS-e820: [mem 0x000dc000-0x000f] reserved [0.00] BIOS-e820: [mem 0x0010-0xbb27bfff] usable [0.00] BIOS-e820: [mem 0xbb27c000-0xbb281fff] reserved [0.00] BIOS-e820: [mem 0xbb282000-0xbb35efff] usable [0.00] BIOS-e820: [mem 0xbb35f000-0xbb370fff] reserved [0.00] BIOS-e820: [mem 0xbb371000-0xbb3f1fff] ACPI NVS [0.00] BIOS-e820: [mem 0xbb3f2000-0xbb40efff] reserved [0.00] BIOS-e820: [mem 0xbb40f000-0xbb46efff] usable [0.00] BIOS-e820: [mem 0xbb46f000-0xbb667fff] reserved [0.00] BIOS-e820: [mem 0xbb668000-0xbb6e7fff] ACPI NVS [0.00] BIOS-e820: [mem 0xbb6e8000-0xbb70efff] reserved [0.00] BIOS-e820: [mem 0xbb70f000-0xbb716fff] usable [0.00] BIOS-e820: [mem 0xbb717000-0xbb71efff] reserved [0.00] BIOS-e820: [mem 0xbb71f000-0xbb76afff] usable [0.00] BIOS-e820: [mem 0xbb76b000-0xbb776fff] ACPI NVS [0.00] BIOS-e820: [mem 0xbb777000-0xbb779fff] ACPI data [0.00] BIOS-e820: [mem 0xbb77a000-0xbb780fff] ACPI NVS [0.00] BIOS-e820: [mem 0xbb781000-0xbb781fff] ACPI data [0.00] BIOS-e820: [mem 0xbb782000-0xbb78afff] ACPI NVS [0.00] BIOS-e820: [mem 0xbb78b000-0xbb78bfff] ACPI data [0.00] BIOS-e820: [mem 0xbb78c000-0xbb79efff] ACPI NVS [0.00] BIOS-e820: [mem 0xbb79f000-0xbb7fefff] ACPI data [0.00] BIOS-e820: [mem 0xbb7ff000-0xbb7f] usable [0.00] BIOS-e820: [mem 0xbb80-0xbfff] reserved [0.00] BIOS-e820: [mem 0xe000-0xefff] reserved [0.00] BIOS-e820: [mem 0xfeaff000-0xfeaf] reserved [0.00] BIOS-e820: [mem 0xfec0-0xfec0] reserved [0.00] BIOS-e820: [mem 0xfed0-0xfed003ff] reserved [0.00] BIOS-e820: [mem 0xfed1c000-0xfed8] reserved [0.00] BIOS-e820: [mem 0xfee0-0xfee00fff] reserved [0.00] BIOS-e820: [mem 0xff00-0x] reserved [0.00] BIOS-e820: [mem 0x0001-0x0001fbff] usable [0.00] BIOS-e820: [mem 0x0002-0x00023bff] usable [0.00] NX (Execute Disable) protection: active [0.00] SMBIOS 2.6 present. [0.00] DMI: LENOVO 2901CTO/2901CTO, BIOS 6UET68WW (1.48 ) 12/12/2011 [0.00] e820: update [mem 0x-0x0fff] usable ==> reserved [0.00] e820: remove [mem 0x000a-0x000f] usable [0.00] No AGP bridge found [0.00] e820: last_pfn = 0x23c000 max_arch_pfn = 0x4 [0.00] MTRR default type: uncachable [0.00] MTRR fixed ranges enabled: [0.00] 0-9 write-back [0.00] A-B uncachable [0.00] C-D3FFF write-protect [0.00] D4000-DBFFF uncachable [0.00] DC000-F write-protect [0.00] MTRR variable ranges enabled: [0.00] 0 disabled [0.00] 1 base 0 mask F8000 write-back [0.00] 2 base 08000 mask FC000 write-back [0.00] 3 base 1 mask F write-back [0.00] 4 base 2 mask FC000 write-back [0.00] 5 base 23C00 mask FFC00 uncachable [0.00] 6 base 0BC00 mask FFC000
