This patch removes a unused struct psb_intel_connector
Sparse gives a warning:
drivers/gpu/drm/gma500/cdv_intel_hdmi.c:142:30: warning:
unused variable ?psb_intel_connector? [-Wunused-variable]
Signed-off-by: Emil Goode
---
drivers/gpu/drm/gma500/cdv_intel_hdmi.c |2 --
1 file chang
> Well, you cant use the pre_install/post_install hooks the drm_irq code
> provides,
> but yes, just do the request_irq in your driver code at the right time, with
> the
> right parameters. Much easier than adding code to a part of the drm core
> fraught with backwards-compat stuff no one really
> For a kms drm driver (and tbh, doing a non-kms driver today is not a great
> idea),
> there's no reason to use the drm_irq_install/_unistall helpers.
>
Can not understand well, I found many GPU drivers are using drm_irq helpers'
function, including ours:)
_
> This possibly ought to be submitted in parallel with the code that uses it so
> that
> the whole proposal can be evaluated as one thing ?
>
> Alan
Patch is here, thanks.
From: liu chuansheng
Subject: [PATCH] drm_irq: Introducing the irq_thread support
For some GPUs, the irq handler need >1m
This patch removes a unused struct psb_intel_connector
Sparse gives a warning:
drivers/gpu/drm/gma500/cdv_intel_hdmi.c:142:30: warning:
unused variable ‘psb_intel_connector’ [-Wunused-variable]
Signed-off-by: Emil Goode
---
drivers/gpu/drm/gma500/cdv_intel_hdmi.c |2 --
1 file chang
> On Wed, Sep 5, 2012 at 12:39 AM, Brad Campbell wrote:
>> On 28/07/12 04:32, j.gli...@gmail.com wrote:
>>>
>>> From: Jerome Glisse
>>>
>>> It seems we can not update the crtc scanout address. After disabling
>>> crtc, update to base address do not take effect after crtc being
>>> reenable le
Hi Vetter:
Do you mean we can just not use drm_irq_install, and make request_irq in
our kernel driver pre-install or post-install interface?
Best Regards.
Yang Shi
PSI,System Integration, SH
E-mail:yang.a@intel.com
Tel:88215666-4239
-Original Message-
From: Daniel Vetter
Signed-off-by: Andy Shevchenko
---
drivers/gpu/drm/nouveau/nouveau_dp.c |4 +---
drivers/gpu/drm/radeon/atombios_dp.c |4 +---
drivers/gpu/drm/udl/udl_main.c |7 ++-
3 files changed, 4 insertions(+), 11 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/nouveau_dp.c
b/drive
Add device tree based discovery support for DRM-FIMD driver.
Signed-off-by: Leela Krishna Amudala
---
Documentation/devicetree/bindings/fb/drm-fimd.txt | 80 +
drivers/gpu/drm/exynos/exynos_drm_fimd.c | 95 -
2 files changed, 173 insertions(+), 2
The name of the exynos drm fimd device is renamed to exynos-drm-fimd
and two device ids are created for exynos4-fb and exynos5-fb.
Also, added driver data for exynos4 and exynos5 to pick the timing base address
at runtime to write data into appropriate register address.
Signed-off-by: Leela Krishn
This patch set adds device tree support for DRM-FIMD for Samsung's Exynos5250.
It includes parsing platform data from dts file. Also, adds the driver data
for exynos4 and exynos5 devices.
This patchset is based and tested on top of v3.6-rc4
Also depends on below patchset
http://lists.freedesktop.o
Hi Tomasz,
Please find the inline comments.
Will post the next version today.
Thanks.
Leela Krishna Amudala.
--- Original Message ---
Sender : Tomasz Figa Junior Software Engineer/SPRC-Linux
Platform (SSD)/Samsung Electronics
Date : Sep 05, 2012 13:22 (GMT+05:30)
Title : Re: [PATCH V3 1/2
Hi Leela,
See my comments inline.
On Thursday 16 of August 2012 12:08:08 Leela Krishna Amudala wrote:
> +enum fimd_version_type {
> + VERSION_8, /* FIMD_VERSION8 */
> +};
> +
> +struct drm_fimd_driver_data {
> + enum fimd_version_type fimd_ver;
> +};
> +
> +struct drm_fimd_driver_data exy
Hi Rob,
On Thu, Sep 6, 2012 at 3:18 AM, Rob Clark wrote:
> From: Rob Clark
>
> 'struct omap_video_timings' was updated w/ a 'bool interlaced'. Without
> a matching update in omap_connector, this field could have undefined
> values from the stack, which isn't quite ideal.
>
> Update the fxns to c
Hi,
On Thu, Sep 6, 2012 at 12:39 AM, Leela Krishna Amudala
wrote:
> Add device tree based discovery support for DRM-FIMD driver.
>
> Signed-off-by: Leela Krishna Amudala
> ---
> Documentation/devicetree/bindings/fb/drm-fimd.txt | 80 +
> drivers/gpu/drm/exynos/exynos_drm_fimd.
Add device tree based discovery support for DRM-FIMD driver.
Signed-off-by: Leela Krishna Amudala
---
Documentation/devicetree/bindings/fb/drm-fimd.txt | 80 +
drivers/gpu/drm/exynos/exynos_drm_fimd.c | 95 -
2 files changed, 173 insertions(+), 2
The name of the exynos drm fimd device is renamed to exynos-drm-fimd
and two device ids are created for exynos4-fb and exynos5-fb.
Also, added driver data for exynos4 and exynos5 to pick the timing base address
at runtime to write data into appropriate register address.
Signed-off-by: Leela Krishn
This patch set adds device tree support for DRM-FIMD for Samsung's Exynos5250.
It includes parsing platform data from dts file. Also, adds the driver data
for exynos4 and exynos5 devices.
This patchset is based and tested on top of v3.6-rc4
Also depends on below patchset
http://lists.freedesktop.o
https://bugs.freedesktop.org/show_bug.cgi?id=41265
Florian Mickler changed:
What|Removed |Added
CC||florian at mickler.org
--- Comment #52
https://bugs.freedesktop.org/show_bug.cgi?id=26891
Florian Mickler changed:
What|Removed |Added
CC||florian at mickler.org
--- Comment #37
Hi,
2012/9/6 Mandeep Singh Baines :
> The double invocations are incorrect but seem to be safe so I don't
> think this will fix any bugs.
>
> Before:
>
> [7.639366] drm_prime_init_file ee3675d0
> [7.639377] drm_prime_init_file ee3675d0
> [7.639507] drm_prime_destroy_file ee3675d0
> [
From: Tomasz Stanislawski
This patch adds a stub function for DMABUF mmap.
This allows to export a DMABUF.
Signed-off-by: Tomasz Stanislawski
Signed-off-by: Kyungmin Park
Signed-off-by: Inki Dae
---
drivers/gpu/drm/exynos/exynos_drm_dmabuf.c |7 +++
1 files changed, 7 insertions(+),
Hi Mandeep,
On 2012년 09월 06일 06:47, Mandeep Singh Baines wrote:
> The double invocations are incorrect but seem to be safe so I don't
> think this will fix any bugs.
>
> Before:
>
> [7.639366] drm_prime_init_file ee3675d0
> [7.639377] drm_prime_init_file ee3675d0
> [7.639507] drm_pri
https://bugs.freedesktop.org/show_bug.cgi?id=42490
--- Comment #31 from Alex Deucher 2012-09-05 18:34:56 UTC
---
Please try my 3.6 fixes tree (should show up in 3.6.0rc4+ and eventually stable
kernels).
http://cgit.freedesktop.org/~agd5f/linux/log/?h=drm-fixes-3.6
--
Configure bugmail: https:/
On Thu, Sep 6, 2012 at 11:15 AM, Linus Torvalds
wrote:
> [ This got dropped somehow - it's in my draft folder. The bisection
> may be irrelevant now: does it work with current git, since we've had
> some nouveau changes? ]
>
> On Tue, Aug 28, 2012 at 8:26 AM, Alexey Dobriyan wrote:
>> Ping!
>>
>>
https://bugs.freedesktop.org/show_bug.cgi?id=42490
lukenshiro at ngi.it changed:
What|Removed |Added
CC||lukenshiro at ngi.it
--- Comment #
[ This got dropped somehow - it's in my draft folder. The bisection
may be irrelevant now: does it work with current git, since we've had
some nouveau changes? ]
On Tue, Aug 28, 2012 at 8:26 AM, Alexey Dobriyan wrote:
> Ping!
>
> No X for me with 3.6-rc2.
Can you possibly bisect it, at least par
[ This got dropped somehow - it's in my draft folder. The bisection
may be irrelevant now: does it work with current git, since we've had
some nouveau changes? ]
On Tue, Aug 28, 2012 at 8:26 AM, Alexey Dobriyan wrote:
> Ping!
>
> No X for me with 3.6-rc2.
Can you possibly bisect it, at least par
On Wed, Sep 05, 2012 at 03:12:39PM +, Shi, Yang A wrote:
> Hi Vetter:
>
> Do you mean we can just not use drm_irq_install, and make
> request_irq in our kernel driver pre-install or post-install
> interface?
Well, you cant use the pre_install/post_install hooks the drm_irq code
pr
https://bugs.freedesktop.org/show_bug.cgi?id=52997
--- Comment #6 from mailbox.tec at gmail.com 2012-09-05 17:30:02 UTC ---
Created attachment 66689
--> https://bugs.freedesktop.org/attachment.cgi?id=66689
X.org server varlog
--
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab
https://bugs.freedesktop.org/show_bug.cgi?id=52997
--- Comment #5 from mailbox.tec at gmail.com 2012-09-05 17:22:26 UTC ---
Created attachment 66688
--> https://bugs.freedesktop.org/attachment.cgi?id=66688
Messages from dmesg after running BGMain.exe in fullscreen.
Hello
I am experiencing the
From: Rob Clark
'struct omap_video_timings' was updated w/ a 'bool interlaced'. Without
a matching update in omap_connector, this field could have undefined
values from the stack, which isn't quite ideal.
Update the fxns to convert omapdss<->drm timings structs, and zero-init
'struct omap_video
From: Rob Clark
This simplifies drm fb lifetime, and if the crtc/plane needs to hold
a ref to the fb when disabling a pipe until the next vblank, this
avoids the need to make disabling an overlay synchronous. This is a
problem that shows up when userspace is using a drm plane to
implement a hw c
On Wed, Sep 5, 2012 at 1:17 PM, Rob Clark wrote:
> From: Rob Clark
>
> This simplifies drm fb lifetime, and if the crtc/plane needs to hold
> a ref to the fb when disabling a pipe until the next vblank, this
> avoids the need to make disabling an overlay synchronous. This is a
> problem that sho
https://bugs.freedesktop.org/show_bug.cgi?id=54527
--- Comment #2 from Bryan Quigley 2012-09-05
15:43:07 UTC ---
Just tested with 3.6-rc4. It is indeed fixed (gnibbles still crashes but just
the program ~ I think that's it's fault)
Should I mark as fixed or wait until 3.6 releases?
--
Config
On Wed, Sep 05, 2012 at 01:53:44AM +, Liu, Chuansheng wrote:
> This patch is for introducing the irq thread support in drm_irq.
>
> Why we need irq thread in drm_irq code?
> In our GPU system, the gpu interrupt handler need some time even > 1ms to
> finish,
> in that case, the whole system wi
Hi Vetter:
Do you mean we can just not use drm_irq_install, and make request_irq in
our kernel driver pre-install or post-install interface?
Best Regards.
Yang Shi
PSI,System Integration, SH
E-mail:yang.a.shi at intel.com
Tel:88215666-4239
-Original Message-
From: Daniel Vett
Signed-off-by: Andy Shevchenko
---
drivers/gpu/drm/nouveau/nouveau_dp.c |4 +---
drivers/gpu/drm/radeon/atombios_dp.c |4 +---
drivers/gpu/drm/udl/udl_main.c |7 ++-
3 files changed, 4 insertions(+), 11 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/nouveau_dp.c
b/drive
From: Rob Clark
'struct omap_video_timings' was updated w/ a 'bool interlaced'. Without
a matching update in omap_connector, this field could have undefined
values from the stack, which isn't quite ideal.
Update the fxns to convert omapdss<->drm timings structs, and zero-init
'struct omap_video
From: Rob Clark
This simplifies drm fb lifetime, and if the crtc/plane needs to hold
a ref to the fb when disabling a pipe until the next vblank, this
avoids the need to make disabling an overlay synchronous. This is a
problem that shows up when userspace is using a drm plane to
implement a hw c
The double invocations are incorrect but seem to be safe so I don't
think this will fix any bugs.
Before:
[7.639366] drm_prime_init_file ee3675d0
[7.639377] drm_prime_init_file ee3675d0
[7.639507] drm_prime_destroy_file ee3675d0
[7.639518] drm_prime_destroy_file ee3675d0
[7.63
The double invocations are incorrect but seem to be safe so I don't
think this will fix any bugs.
Before:
[7.639366] drm_prime_init_file ee3675d0
[7.639377] drm_prime_init_file ee3675d0
[7.639507] drm_prime_destroy_file ee3675d0
[7.639518] drm_prime_destroy_file ee3675d0
[7.63
From: Ander Conselvan de Oliveira
linux_sysfs_create() checked for a driver named "intel" while the intel
driver is called "i915". This went unnoticed because in kernels 2.6.39
and after this code path was never reached because of the dumb buffer
interface. On earlier kernels, kms_create() would
On Wed, Sep 5, 2012 at 1:17 PM, Rob Clark wrote:
> From: Rob Clark
>
> This simplifies drm fb lifetime, and if the crtc/plane needs to hold
> a ref to the fb when disabling a pipe until the next vblank, this
> avoids the need to make disabling an overlay synchronous. This is a
> problem that sho
On Wed, 5 Sep 2012 01:53:44 +
"Liu, Chuansheng" wrote:
> This patch is for introducing the irq thread support in drm_irq.
>
> Why we need irq thread in drm_irq code?
> In our GPU system, the gpu interrupt handler need some time even > 1ms to
> finish,
> in that case, the whole system will s
https://bugs.freedesktop.org/show_bug.cgi?id=41265
Florian Mickler changed:
What|Removed |Added
CC||flor...@mickler.org
--- Comment #52 fr
https://bugs.freedesktop.org/show_bug.cgi?id=26891
Florian Mickler changed:
What|Removed |Added
CC||flor...@mickler.org
--- Comment #37 fr
From: Rob Clark
This simplifies drm fb lifetime, and if the crtc/plane needs to hold
a ref to the fb when disabling a pipe until the next vblank, this
avoids the need to make disabling an overlay synchronous. This is a
problem that shows up when userspace is using a drm plane to
implement a hw c
On 28/07/12 04:32, j.glisse at gmail.com wrote:
> From: Jerome Glisse
>
> It seems we can not update the crtc scanout address. After disabling
> crtc, update to base address do not take effect after crtc being
> reenable leading to at least frame being scanout from the old crtc
> base address. Dis
https://bugs.freedesktop.org/show_bug.cgi?id=42490
--- Comment #31 from Alex Deucher 2012-09-05 18:34:56 UTC ---
Please try my 3.6 fixes tree (should show up in 3.6.0rc4+ and eventually stable
kernels).
http://cgit.freedesktop.org/~agd5f/linux/log/?h=drm-fixes-3.6
--
Configure bugmail: https://
https://bugs.freedesktop.org/show_bug.cgi?id=42490
lukensh...@ngi.it changed:
What|Removed |Added
CC||lukensh...@ngi.it
--- Comment #30 fro
From: Rob Clark
This simplifies drm fb lifetime, and if the crtc/plane needs to hold
a ref to the fb when disabling a pipe until the next vblank, this
avoids the need to make disabling an overlay synchronous. This is a
problem that shows up when userspace is using a drm plane to
implement a hw c
On Tue, Sep 04, 2012 at 06:10:04PM -0500, Rob Clark wrote:
> From: Rob Clark
>
> This simplifies drm fb lifetime, and if the crtc/plane needs to hold
> a ref to the fb when disabling a pipe until the next vblank, this
> avoids the need to make disabling an overlay synchronous. This is a
> proble
On Tue, Sep 04, 2012 at 05:32:21PM -0500, Rob Clark wrote:
> Dave, I just noticed that I still have this patch locally, but don't
> see it in drm-next.. so just checking that it didn't get forgotten
My locking fixes blew up :(
-Daniel
>
> BR,
> -R
>
> On Tue, Jul 24, 2012 at 3:05 AM, Daniel Ve
On Wed, Sep 5, 2012 at 8:27 AM, Daniel Vetter wrote:
> On Wed, Sep 05, 2012 at 01:53:44AM +, Liu, Chuansheng wrote:
>> This patch is for introducing the irq thread support in drm_irq.
>>
>> Why we need irq thread in drm_irq code?
>> In our GPU system, the gpu interrupt handler need some time e
https://bugs.freedesktop.org/show_bug.cgi?id=52997
--- Comment #6 from mailbox@gmail.com 2012-09-05 17:30:02 UTC ---
Created attachment 66689
--> https://bugs.freedesktop.org/attachment.cgi?id=66689
X.org server varlog
--
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=em
On Wed, Sep 5, 2012 at 12:39 AM, Brad Campbell wrote:
> On 28/07/12 04:32, j.glisse at gmail.com wrote:
>>
>> From: Jerome Glisse
>>
>> It seems we can not update the crtc scanout address. After disabling
>> crtc, update to base address do not take effect after crtc being
>> reenable leading to a
https://bugs.freedesktop.org/show_bug.cgi?id=52997
--- Comment #5 from mailbox@gmail.com 2012-09-05 17:22:26 UTC ---
Created attachment 66688
--> https://bugs.freedesktop.org/attachment.cgi?id=66688
Messages from dmesg after running BGMain.exe in fullscreen.
Hello
I am experiencing the sam
Hi Leela,
See my comments inline.
On Thursday 16 of August 2012 12:08:08 Leela Krishna Amudala wrote:
> +enum fimd_version_type {
> + VERSION_8, /* FIMD_VERSION8 */
> +};
> +
> +struct drm_fimd_driver_data {
> + enum fimd_version_type fimd_ver;
> +};
> +
> +struct drm_fimd_driver_data exy
Hi Tomasz,
Please find the inline comments.
Will post the next version today.
Thanks.
Leela Krishna Amudala.
--- Original Message ---
Sender : Tomasz Figa Junior Software Engineer/SPRC-Linux
Platform (SSD)/Samsung Electronics
Date : Sep 05, 2012 13:22 (GMT+05:30)
Title : Re: [PATCH V3 1/2
On Wed, Sep 5, 2012 at 8:27 AM, Daniel Vetter wrote:
> On Wed, Sep 05, 2012 at 01:53:44AM +, Liu, Chuansheng wrote:
>> This patch is for introducing the irq thread support in drm_irq.
>>
>> Why we need irq thread in drm_irq code?
>> In our GPU system, the gpu interrupt handler need some time e
https://bugs.freedesktop.org/show_bug.cgi?id=54527
--- Comment #2 from Bryan Quigley 2012-09-05 15:43:07
UTC ---
Just tested with 3.6-rc4. It is indeed fixed (gnibbles still crashes but just
the program ~ I think that's it's fault)
Should I mark as fixed or wait until 3.6 releases?
--
Config
On Wed, Sep 05, 2012 at 03:12:39PM +, Shi, Yang A wrote:
> Hi Vetter:
>
> Do you mean we can just not use drm_irq_install, and make
> request_irq in our kernel driver pre-install or post-install
> interface?
Well, you cant use the pre_install/post_install hooks the drm_irq code
pr
https://bugs.freedesktop.org/show_bug.cgi?id=54527
--- Comment #1 from Michel D?nzer 2012-09-05 08:24:39
UTC ---
Likely fixed by
https://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=676bc2e1e4f9072f7a640d5b7c99ffdf9709a6e7
, which should be on its way to the 3.5 stabl
https://bugs.freedesktop.org/show_bug.cgi?id=54527
Michel D?nzer changed:
What|Removed |Added
Attachment #66652|application/octet-stream|text/plain
mime type|
On Wed, Sep 5, 2012 at 12:39 AM, Brad Campbell wrote:
> On 28/07/12 04:32, j.gli...@gmail.com wrote:
>>
>> From: Jerome Glisse
>>
>> It seems we can not update the crtc scanout address. After disabling
>> crtc, update to base address do not take effect after crtc being
>> reenable leading to at l
On Wed, Sep 5, 2012 at 4:02 AM, Daniel Vetter wrote:
> On Tue, Sep 04, 2012 at 05:32:21PM -0500, Rob Clark wrote:
>> Dave, I just noticed that I still have this patch locally, but don't
>> see it in drm-next.. so just checking that it didn't get forgotten
>
> My locking fixes blew up :(
oh, ok..
On Wed, Sep 05, 2012 at 01:53:44AM +, Liu, Chuansheng wrote:
> This patch is for introducing the irq thread support in drm_irq.
>
> Why we need irq thread in drm_irq code?
> In our GPU system, the gpu interrupt handler need some time even > 1ms to
> finish,
> in that case, the whole system wi
On Wed, 5 Sep 2012 01:53:44 +
"Liu, Chuansheng" wrote:
> This patch is for introducing the irq thread support in drm_irq.
>
> Why we need irq thread in drm_irq code?
> In our GPU system, the gpu interrupt handler need some time even > 1ms to
> finish,
> in that case, the whole system will s
Hi,
On Thu, Sep 6, 2012 at 12:39 AM, Leela Krishna Amudala
wrote:
> Add device tree based discovery support for DRM-FIMD driver.
>
> Signed-off-by: Leela Krishna Amudala
> ---
> Documentation/devicetree/bindings/fb/drm-fimd.txt | 80 +
> drivers/gpu/drm/exynos/exynos_drm_fimd.
On Wed, Sep 5, 2012 at 4:02 AM, Daniel Vetter wrote:
> On Tue, Sep 04, 2012 at 05:32:21PM -0500, Rob Clark wrote:
>> Dave, I just noticed that I still have this patch locally, but don't
>> see it in drm-next.. so just checking that it didn't get forgotten
>
> My locking fixes blew up :(
oh, ok..
https://bugs.freedesktop.org/show_bug.cgi?id=54527
Bug #: 54527
Summary: Crash, kernel BUG ttm/ttm_bo.c:1659!, when running
gnibbles
Classification: Unclassified
Product: DRI
Version: XOrg CVS
Platform: Other
From: Ander Conselvan de Oliveira
linux_sysfs_create() checked for a driver named "intel" while the intel
driver is called "i915". This went unnoticed because in kernels 2.6.39
and after this code path was never reached because of the dumb buffer
interface. On earlier kernels, kms_create() would
From: Tomasz Stanislawski
This patch adds a stub function for DMABUF mmap.
This allows to export a DMABUF.
Signed-off-by: Tomasz Stanislawski
Signed-off-by: Kyungmin Park
Signed-off-by: Inki Dae
---
drivers/gpu/drm/exynos/exynos_drm_dmabuf.c |7 +++
1 files changed, 7 insertions(+),
On Tue, Sep 04, 2012 at 06:10:04PM -0500, Rob Clark wrote:
> From: Rob Clark
>
> This simplifies drm fb lifetime, and if the crtc/plane needs to hold
> a ref to the fb when disabling a pipe until the next vblank, this
> avoids the need to make disabling an overlay synchronous. This is a
> proble
On Tue, Sep 04, 2012 at 05:32:21PM -0500, Rob Clark wrote:
> Dave, I just noticed that I still have this patch locally, but don't
> see it in drm-next.. so just checking that it didn't get forgotten
My locking fixes blew up :(
-Daniel
>
> BR,
> -R
>
> On Tue, Jul 24, 2012 at 3:05 AM, Daniel Ve
From: liu chuansheng
Subject: [PATCH] drm_irq: Introducing the irq_thread support
For some GPUs, the irq handler need >1ms to handle the irq action.
And it will delay the whole system irq handler.
This patch is adding the irq thread support, it will make the drm_irq
interface more flexible.
The
This patch is for introducing the irq thread support in drm_irq.
Why we need irq thread in drm_irq code?
In our GPU system, the gpu interrupt handler need some time even > 1ms to
finish,
in that case, the whole system will stay in irq disable status. One case is:
when audio is playing, it sometim
https://bugs.freedesktop.org/show_bug.cgi?id=54527
--- Comment #1 from Michel Dänzer 2012-09-05 08:24:39 UTC
---
Likely fixed by
https://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=676bc2e1e4f9072f7a640d5b7c99ffdf9709a6e7
, which should be on its way to the 3.5 stabl
https://bugs.freedesktop.org/show_bug.cgi?id=54527
Michel Dänzer changed:
What|Removed |Added
Attachment #66652|application/octet-stream|text/plain
mime type|
On 28/07/12 04:32, j.gli...@gmail.com wrote:
From: Jerome Glisse
It seems we can not update the crtc scanout address. After disabling
crtc, update to base address do not take effect after crtc being
reenable leading to at least frame being scanout from the old crtc
base address. Disabling crtc
From: liu chuansheng
Subject: [PATCH] drm_irq: Introducing the irq_thread support
For some GPUs, the irq handler need >1ms to handle the irq action.
And it will delay the whole system irq handler.
This patch is adding the irq thread support, it will make the drm_irq
interface more flexible.
The
This patch is for introducing the irq thread support in drm_irq.
Why we need irq thread in drm_irq code?
In our GPU system, the gpu interrupt handler need some time even > 1ms to
finish,
in that case, the whole system will stay in irq disable status. One case is:
when audio is playing, it sometim
On 09/04/2012 02:00 PM, Guenter Roeck wrote:
> On Tue, Sep 04, 2012 at 01:19:12PM -0600, Stephen Warren wrote:
>> With respect to the following commits:
>>
>> df0b344 drm/usb: select USB_SUPPORT in Kconfig
>> 8f057d7 gpu/mfd/usb: Fix USB randconfig problems
>>
>> ... which end up with the following
On 08/31/2012 08:00 PM, Dave Airlie wrote:
object interface, so that Optimus-based laptops can use our driver to drive
the discrete GPU and display on the integrated GPU. The good news is that
I've got a proof of concept working.
Don't suppose you'll be interested in adding the other method at
With respect to the following commits:
df0b344 drm/usb: select USB_SUPPORT in Kconfig
8f057d7 gpu/mfd/usb: Fix USB randconfig problems
... which end up with the following in next-20120904:
config DRM_USB
depends on DRM
depends on USB_ARCH_HAS_HCD
select USB
select
On Tue, Sep 04, 2012 at 01:19:12PM -0600, Stephen Warren wrote:
> With respect to the following commits:
>
> df0b344 drm/usb: select USB_SUPPORT in Kconfig
> 8f057d7 gpu/mfd/usb: Fix USB randconfig problems
>
> ... which end up with the following in next-20120904:
>
> config DRM_USB
> de
87 matches
Mail list logo
