On Fri, Dec 7, 2012 at 1:04 PM, Prathyush K wrote:
>
>
>
> On Fri, Dec 7, 2012 at 10:37 AM, Inki Dae wrote:
>
>>
>>
>> 2012/12/6 Prathyush K
>>
>>> When fimd is turned off, we disable the clocks which will stop
>>> the dma. Now if we remove the current framebuffer, we cannot
>>> disable the ove
On Fri, Dec 7, 2012 at 10:37 AM, Inki Dae wrote:
>
>
> 2012/12/6 Prathyush K
>
>> When fimd is turned off, we disable the clocks which will stop
>> the dma. Now if we remove the current framebuffer, we cannot
>> disable the overlay but the current framebuffer will still be freed.
>>
>
> I think
On Thu, Dec 06, 2012 at 02:55:23PM -0200, Paulo Zanoni wrote:
> Hi
>
> 2012/12/6 Paulo Zanoni :
> > Hi
> >
> > 2012/12/5 Thierry Reding :
> >> Use the generic HDMI infoframe helpers to get rid of the duplicate
> >> implementation in the i915 driver.
> >
> > A few comments:
> >
> > - I've compiled
On Thu, Dec 06, 2012 at 02:11:00PM -0200, Paulo Zanoni wrote:
> Hi
>
> 2012/12/5 Thierry Reding :
> > Use the generic HDMI infoframe helpers to get rid of the duplicate
> > implementation in the i915 driver.
>
> A few comments:
>
> - I've compiled your patches and now "intel_infoframes -d" tells
On 12/07/2012 02:44 PM, Terje Bergström wrote:
> On 07.12.2012 07:38, Mark Zhang wrote:
>> On 12/06/2012 07:36 PM, Terje Bergström wrote:
>>> This is about the hardware, and the correct verb is "copy". HOST1X
>>> hardware pre-fetches opcodes from push buffer and contents of GATHERs to
>>> a FIFO to
On 07.12.2012 07:38, Mark Zhang wrote:
> On 12/06/2012 07:36 PM, Terje Bergström wrote:
>> This is about the hardware, and the correct verb is "copy". HOST1X
>> hardware pre-fetches opcodes from push buffer and contents of GATHERs to
>> a FIFO to overcome memory latencies. The execution happens fro
This is taken care inside fimd and mixer with the clearing windows in dpms
off patch itself.
I've added a check inside win_disable function (for both fimd/mixer) where
we set the 'resume' flag to zero and return.
So the "drm/exynos: do not disable crtc if already off" patch is not
required.
Rega
Hi,
CCing media guys.
I agree with you but we should consider one issue released to v4l2.
As you may know, V4L2-based driver uses vb2 as buffer manager and the vb2
includes dmabuf feature>(import and export) And v4l2 uses streaming
concept>(qbuf and dqbuf)
With dmabuf and iommu, generally qbuf i
is packed in the Z component of the vectors in
pipe_viewport_state, which is applied after clipping and converts coordinates
from the clip space to the window space.
--
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachme
On Fri, Dec 7, 2012 at 9:05 AM, Tim Gardner wrote:
> On 12/06/2012 03:46 PM, Dave Airlie wrote:
>
>>>
>>> ttm_page_pool_init_locked(&_manager->wc_pool, GFP_HIGHUSER,
>>> "wc");
>>>
>>> @@ -817,6 +821,7 @@ int ttm_page_alloc_init(struct ttm_mem_global *glob,
>>> unsigned max_pages)
>>>
On 12/07/2012 02:46 AM, Stephen Warren wrote:
> On 12/06/2012 01:13 AM, Mark Zhang wrote:
[...]
>>
>> Yes, I think this is what I mean. No dummy information in the command
>> stream, userspace just fills the address which it uses(actually this is
>> cpu address of the buffer) in the command stream,
On 12/06/2012 07:36 PM, Terje Bergström wrote:
> On 06.12.2012 09:06, Mark Zhang wrote:
>> Thank you for the doc. So here I have questions:
>>
>> Push buffer contains a lot of opcodes for this channel. So when multiple
>> userspace processes submit jobs to this channel, all these jobs will be
>> sa
On 12/06/2012 07:17 PM, Lucas Stach wrote:
> Am Donnerstag, den 06.12.2012, 16:13 +0800 schrieb Mark Zhang:
>> On 12/06/2012 04:00 PM, Lucas Stach wrote:
> [...]
>>>
>>> Or maybe I'm misunderstanding you and you mean it the other way around.
>>> You don't let userspace dictate the addresses, the re
2012/12/5 Rob Clark
> On Wed, Dec 5, 2012 at 12:55 AM, Inki Dae wrote:
> > Hi
> >
> > 2012/12/5 Prathyush K
> >>
> >> Hi,
> >>
> >> Please check the reference counts for framebuffers: This is for one
> >> modetest (without flipping)
> >>
> >> Bootup:
> >> [2.31] KP: drm_framebuffer_init
2012/12/6 Prathyush K
> When fimd is turned off, we disable the clocks which will stop
> the dma. Now if we remove the current framebuffer, we cannot
> disable the overlay but the current framebuffer will still be freed.
>
I think that if fimd was turned off by dpms operation (off only clock and
2012/12/6 Prathyush K
> When fimd is turned off, we disable the clocks which will stop
> the dma. Now if we remove the current framebuffer, we cannot
> disable the overlay but the current framebuffer will still be freed.
> When fimd resumes, the dma will continue from where it left off
> and will
On Thu, Dec 06, 2012 at 10:46:30PM +0100, Daniel Vetter wrote:
> On Thu, Dec 06, 2012 at 10:07:48AM -0800, Aaron Plattner wrote:
> > Instead of reimplementing all of the dma_buf functionality in every driver,
> > create helpers drm_prime_import and drm_prime_export that implement them in
> > terms
On Thu, Dec 06, 2012 at 10:07:48AM -0800, Aaron Plattner wrote:
> Instead of reimplementing all of the dma_buf functionality in every driver,
> create helpers drm_prime_import and drm_prime_export that implement them in
> terms of new, lower-level hook functions:
>
> gem_prime_pin: callback when
On Thu, Dec 6, 2012 at 4:20 PM, Tim Gardner
wrote:
> Memory for _manager is allocated using kzalloc() but the result is not
> checked.
>
> Free _manager on error lest memory become orphaned.
>
> I was led to scrutinize ttm_page_alloc_init() from a smatch warning:
>
> drivers/gpu/drm/ttm/ttm_page
t.
--
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20121206/2b607d28/attachment.html>
2012/12/6 Prathyush K
> This patchset fixes the various issues which result in getting a PAGE FAULT
> while using fimd and hdmi in exynos drm.
>
> Changelog v2:
> Seperated patches into drm framework and fimd/mixer patches.
> Not using patch drm/exynos: do not disable crtc if already off
> Added
--
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20121206/67939f7d/attachment.html>
When fimd is turned off, we disable the clocks which will stop
the dma. Now if we remove the current framebuffer, we cannot
disable the overlay but the current framebuffer will still be freed.
When fimd resumes, the dma will continue from where it left off
and will throw a PAGE FAULT since the memo
When mixer is turned off, we disable the clocks which will stop
the dma. Now if we remove the current framebuffer, we cannot
disable the overlay but the current framebuffer will still be freed.
When mixer resumes, the dma will continue from where it left off
and will throw a PAGE FAULT since the me
It is more optimium to use wait queues while waiting for vsync so
that the current task is put to sleep. This way, the task wont
hog the CPU while waiting. We use wait_event_timeout and not
an interruptible function since we dont want the function to exit
when a signal is pending (e.g. drm release)
It is more optimium to use wait queues while waiting for vsync so
that the current task is put to sleep. This way, the task wont
hog the CPU while waiting. We use wait_event_timeout and not
an interruptible function since we dont want the function to exit
when a signal is pending (e.g. drm release)
The wait for vblank callback is moved from overlay_ops to
manager_ops for fimd.
Signed-off-by: Prathyush K
---
drivers/gpu/drm/exynos/exynos_drm_fimd.c | 24
1 files changed, 12 insertions(+), 12 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
b/dr
The wait_for_vblank callback of hdmi and mixer is now moved from
overlay_ops to manager_ops.
Signed-off-by: Prathyush K
---
drivers/gpu/drm/exynos/exynos_drm_hdmi.c | 22 +++---
drivers/gpu/drm/exynos/exynos_drm_hdmi.h |2 +-
drivers/gpu/drm/exynos/exynos_mixer.c| 26
The wait_for_vblank callback is moved from overlay ops to manager ops
of exynos drm driver. Also, the check for DPMS OFF of encoder is
removed before calling wait_for_vblank.
Signed-off-by: Prathyush K
---
drivers/gpu/drm/exynos/exynos_drm_drv.h |6 +++---
drivers/gpu/drm/exynos/exynos_d
This patchset fixes the various issues which result in getting a PAGE FAULT
while using fimd and hdmi in exynos drm.
Changelog v2:
Seperated patches into drm framework and fimd/mixer patches.
Not using patch drm/exynos: do not disable crtc if already off
Added two new patches for clearing windows
On 06.12.2012, Heinz Diehl wrote:
[]
Ok, the last one for today. After extensive testing with heavy load
and I/O while watching HD videos, I can almost safely conclude with
the following:
1.) The hang does *never* occur with 3.6.9 vanilla
2.) The hang does *always* occur with 3.7-rc8+ /
--
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20121206/65855b7e/attachment.html>
ame
ARB_depth_clamp. Claming the Z value in the fragment shader would be easier,
but I think won't work as the geometry would be clipped before it reaches the
fragment stage.
--
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
s scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20121206/b10db43e/attachment-0001.html>
sts on r5xx asics. R3xx and r4xx don't have that bit.
--
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20121206/30d1df43/attachment.html>
From: "R. Chandrasekar"
Adding driver for the Mobile Image Enhancement (MIE)
module of exynos SoC. This cl scope is limited to dithereing.
mie dithering function is enabled from fimd
Signed-off-by: R. Chandrasekar
Change-Id: I05be2a2a5484719ff7bdeff722d95223191b077f
---
drivers/gpu/drm/exynos
From: "R. Chandrasekar"
mie provides the dithereing functionality, fimd need to call the
mie dithering function is required when panel uses lesser
bits per pixel (bpp) of fimd.
This cl adds the functions to add the mie plugin, and calls the
mie dithereing function.
Signed-off-by: R. Chandraseka
From: "R. Chandrasekar"
adding device tree support for mobile image enhancement (mie)
module of exynos SoC. driver fetches the base address of mie
from the device tree.
Signed-off-by: R. Chandrasekar
---
arch/arm/boot/dts/exynos5250.dtsi |7 ++-
1 file changed, 6 insertions(+), 1 delet
From: "R. Chandrasekar"
this patch set adds the driver support for the dithering functionality of the
mobile image enhancement (mie) module.
device tree support is added for mie.
fimd adds the mie module as plugin and calls the dithering function. dithere is
required when the panels bpp is less
On 06.12.2012, Heinz Diehl wrote:
[]
Here are some more error-logs, inkl. dmesg after booting with drm
debug options turned on:
http://www.fritha.org/i915/gpu-hang.tar.bz2
the variable "ret" might be uninitialized in the "default" branch of "switch"
Signed-off-by: Cong Ding
---
drivers/gpu/drm/nouveau/core/engine/disp/dacnv50.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/core/engine/disp/dacnv50.c
b/drivers/gp
e the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20121206/24f9fc9f/attachment.html>
next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20121206/9639690c/attachment.html>
erry
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20121206/512f7495/attachment-0001.pgp>
ecided it wasn't worth the trouble. But there's always the possibility
that I've broken things horribly here since the patch is rather messy,
so it's good that you look closely and some testing will certainly be
good to validate that things still work as before.
Thierry
---
On Thu, Dec 6, 2012 at 3:23 PM, Thierry Reding
wrote:
>> > - /* sdvo spec says that the ecc is handled by the hw, and it looks like
>> > -* we must not send the ecc field, either. */
>> > - memcpy(sdvo_data, &avi_if, 3);
>> > - sdvo_data[3] = avi_if.checksum;
>>
>> This difference betwee
from the aforementioned bug 39251.
--
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20121206/8e7ec90e/attachment.html>
On Thu, Dec 6, 2012 at 3:28 PM, Thierry Reding
wrote:
>> Note that the intel avi infoframe in intel_hdmi_set_avi_infoframe also
>> sets the pixel repeat for double clocked modes with:
>>
>> if (adjusted_mode->flags & DRM_MODE_FLAG_DBLCLK)
>> avi_if.body.avi.YQ_CN_PR |= DIP_AVI_
On Thu, Dec 6, 2012 at 4:25 PM, Daniel Vetter wrote:
> On Thu, Dec 6, 2012 at 3:54 PM, Chris Wilson
> wrote:
>> As the shrinker may be invoked for the allocation, and it may reap
>> neighbouring objects in the offset range mm, we need to be careful in
>> the order in which we allocate the node,
On Thu, Dec 6, 2012 at 3:54 PM, Chris Wilson
wrote:
> As the shrinker may be invoked for the allocation, and it may reap
> neighbouring objects in the offset range mm, we need to be careful in
> the order in which we allocate the node, search for free space and then
> insert the node into the mma
On 12/06/2012 04:00 PM, Lucas Stach wrote:
> Am Donnerstag, den 06.12.2012, 15:49 +0800 schrieb Mark Zhang:
[...]
>>
>> OK. So these relocation addresses are used to let userspace tells kernel
>> which buffers mentioned in the command should be relocated to addresses
>> which host1x clients able to
On 12/06/2012 03:46 PM, Dave Airlie wrote:
>>
>> ttm_page_pool_init_locked(&_manager->wc_pool, GFP_HIGHUSER, "wc");
>>
>> @@ -817,6 +821,7 @@ int ttm_page_alloc_init(struct ttm_mem_global *glob,
>> unsigned max_pages)
>> &glob->kobj, "pool");
>>
t was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20121206/c89b9b1b/attachment.html>
On 12/06/2012 03:20 PM, Lucas Stach wrote:
> Am Donnerstag, den 06.12.2012, 15:06 +0800 schrieb Mark Zhang:
> [...]
>>> First action taken is taking a reference to all buffers in the command
>>> stream. This includes the command stream buffers themselves, but also
>>> the target buffers. We also ma
https://bugs.freedesktop.org/show_bug.cgi?id=57875
--- Comment #14 from Marek Olšák ---
(In reply to comment #10)
> > That bit only exists on r5xx asics. R3xx and r4xx don't have that bit.
> I'd say it's related to floating point depth buffer support. I don't know
> about the capabilities of the
mi_set_avi_infoframe also
> sets the pixel repeat for double clocked modes with:
>
> if (adjusted_mode->flags & DRM_MODE_FLAG_DBLCLK)
> avi_if.body.avi.YQ_CN_PR |= DIP_AVI_PR_2;
I left that in place in the Intel driver, but I suppose we can just as
well move it to the infoframe helpers since it should be a generic
option.
Thierry
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20121206/0362c588/attachment.pgp>
, which is
at byte 3 and therefore matches the previous code.
Thierry
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20121206/93e93366/attachment.pgp>
On Wed, Dec 05, 2012 at 05:45:44PM +0100, Thierry Reding wrote:
> Use the generic HDMI infoframe helpers to get rid of the duplicate
> implementation in the i915 driver.
>
> Signed-off-by: Thierry Reding
> diff --git a/drivers/gpu/drm/i915/intel_sdvo.c
> b/drivers/gpu/drm/i915/intel_sdvo.c
> in
On Wed, Dec 05, 2012 at 05:45:42PM +0100, Thierry Reding wrote:
> Add a generic helper to fill in an HDMI AVI infoframe with data
> extracted from a DRM display mode.
>
> Signed-off-by: Thierry Reding
A few quick comments below.
> ---
> Changes in v2:
> - reuse CEA modes defined in drm_edid_mod
On 12/05/2012 05:47 PM, Terje Bergstr?m wrote:
> Hi,
>
[...]
>
> Channels
>
>
> Channel is a push buffer containing HOST1X opcodes. The push buffer
> boundaries are defined with `HOST1X_CHANNEL_DMASTART_0` and
> `HOST1X_CHANNEL_DMAEND_0`. `HOST1X_CHANNEL_DMAGET_0` indicates the next
> p
Hi
2012/12/6 Paulo Zanoni :
> Hi
>
> 2012/12/5 Thierry Reding :
>> Use the generic HDMI infoframe helpers to get rid of the duplicate
>> implementation in the i915 driver.
>
> A few comments:
>
> - I've compiled your patches and now "intel_infoframes -d" tells my my
> infoframes are full of zeroes
As the shrinker may be invoked for the allocation, and it may reap
neighbouring objects in the offset range mm, we need to be careful in
the order in which we allocate the node, search for free space and then
insert the node into the mmap offset range manager.
Signed-off-by: Chris Wilson
Cc: Dave
On Thu, Dec 6, 2012 at 4:20 PM, Tim Gardner wrote:
> Memory for _manager is allocated using kzalloc() but the result is not
> checked.
>
> Free _manager on error lest memory become orphaned.
>
> I was led to scrutinize ttm_page_alloc_init() from a smatch warning:
>
> drivers/gpu/drm/ttm/ttm_page_
Hi
2012/12/5 Thierry Reding :
> Use the generic HDMI infoframe helpers to get rid of the duplicate
> implementation in the i915 driver.
A few comments:
- I've compiled your patches and now "intel_infoframes -d" tells my my
infoframes are full of zeroes. So there's a bug somewhere... I have to
sa
https://bugs.freedesktop.org/show_bug.cgi?id=57875
--- Comment #13 from Stefan Dösinger ---
I think a new extension is the way to go. We could probably call it
GL_MESA_depth_clip_disable or GL_MESA_depth_clamp_d3d.
One could try to combine the CLIP_DISABLE register with clamping gl_FragDepth
ins
On Thu, Dec 06, 2012 at 10:46:30PM +0100, Daniel Vetter wrote:
> On Thu, Dec 06, 2012 at 10:07:48AM -0800, Aaron Plattner wrote:
> > Instead of reimplementing all of the dma_buf functionality in every driver,
> > create helpers drm_prime_import and drm_prime_export that implement them in
> > terms
On Thu, Dec 06, 2012 at 10:07:48AM -0800, Aaron Plattner wrote:
> Instead of reimplementing all of the dma_buf functionality in every driver,
> create helpers drm_prime_import and drm_prime_export that implement them in
> terms of new, lower-level hook functions:
>
> gem_prime_pin: callback when
On 04.12.2012, Daniel Vetter wrote:
> Yeah, if anyone can somewhat reliably reproduce this
While writing a big file with dd and watching high resolution videos
on youtube, I've managed to reproduce the hang. Unfortunately, it
doesn't occur within seconds. Some playing around is neccessary, and
i
On 06.12.2012 09:06, Mark Zhang wrote:
> Thank you for the doc. So here I have questions:
>
> Push buffer contains a lot of opcodes for this channel. So when multiple
> userspace processes submit jobs to this channel, all these jobs will be
> saved in the push buffer and return, right? I mean, nvh
https://bugs.freedesktop.org/show_bug.cgi?id=57875
--- Comment #12 from Henri Verbeet ---
(In reply to comment #9)
> 1) Wine shouldn't use ARB_depth_clamp, but instead it should use an
> extension that exposes CLIP_DISABLE as defined by D3D9 to the user. The
> problem is such an extension doesn't
Am Donnerstag, den 06.12.2012, 16:13 +0800 schrieb Mark Zhang:
> On 12/06/2012 04:00 PM, Lucas Stach wrote:
[...]
> >
> > Or maybe I'm misunderstanding you and you mean it the other way around.
> > You don't let userspace dictate the addresses, the relocation
> > information just tells the kernel
Op 06-12-12 02:36, Jerome Glisse schreef:
> On Fri, Nov 30, 2012 at 7:12 AM, Maarten Lankhorst
> wrote:
>> This requires re-use of the seqno, which increases fairness slightly.
>> Instead of spinning with a new seqno every time we keep the current one,
>> but still drop all other reservations we h
On 12/06/2012 01:13 AM, Mark Zhang wrote:
> On 12/06/2012 04:00 PM, Lucas Stach wrote:
>> Am Donnerstag, den 06.12.2012, 15:49 +0800 schrieb Mark Zhang:
> [...]
>>>
>>> OK. So these relocation addresses are used to let userspace tells kernel
>>> which buffers mentioned in the command should be relo
https://bugs.freedesktop.org/show_bug.cgi?id=57875
--- Comment #11 from Stefan Dösinger ---
I found the r500 register docs, and yeah, the Z_EXTENDED bit sounds less useful
now...
--
You are receiving this mail because:
You are the assignee for the bug.
__
Op 06-12-12 02:19, Jerome Glisse schreef:
> On Fri, Nov 30, 2012 at 7:12 AM, Maarten Lankhorst
> wrote:
>> There should no longer be assumptions that reserve will always succeed
>> with the lru lock held, so we can safely break the whole atomic
>> reserve/lru thing. As a bonus this fixes most lock
https://bugs.freedesktop.org/show_bug.cgi?id=57875
--- Comment #10 from Stefan Dösinger ---
(In reply to comment #8)
> That bit only exists on r5xx asics. R3xx and r4xx don't have that bit.
I'd say it's related to floating point depth buffer support. I don't know about
the capabilities of the GP
Simplify the Exynos prime implementation by using the default behavior provided
by drm_gem_prime_import and drm_gem_prime_export.
Signed-off-by: Aaron Plattner
---
v2: fix dumb mistakes now that I have a toolchain that can compile-test this
drivers/gpu/drm/exynos/exynos_drm_dmabuf.c | 156 ++---
Simplify the Exynos prime implementation by using the default behavior provided
by drm_gem_prime_import and drm_gem_prime_export.
Signed-off-by: Aaron Plattner
---
v2: fix dumb mistakes now that I have a toolchain that can compile-test this
drivers/gpu/drm/exynos/exynos_drm_dmabuf.c | 156 ++---
On 12/06/2012 01:13 AM, Mark Zhang wrote:
> On 12/06/2012 04:00 PM, Lucas Stach wrote:
>> Am Donnerstag, den 06.12.2012, 15:49 +0800 schrieb Mark Zhang:
> [...]
>>>
>>> OK. So these relocation addresses are used to let userspace tells kernel
>>> which buffers mentioned in the command should be relo
smatch warning:
drivers/gpu/drm/i915/intel_display.c:7019 intel_set_mode() warn: function puts
500 bytes on stack
Refactor so that saved_mode and saved_hwmode are dynamically allocated as
opposed
to being automatic variables. 500 bytes seems like it could run the potential
for blowing
the kerne
On Wed, Dec 5, 2012 at 2:00 PM, Tim Gardner
wrote:
> The result of drm_property_create_blob() is not checked for success
> which could lead to a NULL pointer dereference.
>
> I was led to this by a smatch warning:
>
> drivers/gpu/drm/drm_crtc.c:3186 drm_mode_connector_update_edid_property()
> er
On Thu, Dec 6, 2012 at 5:52 AM, Maarten Lankhorst
wrote:
> Op 06-12-12 02:36, Jerome Glisse schreef:
>> On Fri, Nov 30, 2012 at 7:12 AM, Maarten Lankhorst
>> wrote:
>>> This requires re-use of the seqno, which increases fairness slightly.
>>> Instead of spinning with a new seqno every time we kee
On 05.12.2012, Daniel Vetter wrote:
> Nope, we could only reproduce quickly with rc6 enabled :(
Could reproduce it today this way:
dd if=/dev/zero of=deleteme bs=1M count=5
while watching several HD videos on Youtube. Just tried once, so I'm
not shure if this will work all the way. Will tr
https://bugs.freedesktop.org/show_bug.cgi?id=57875
--- Comment #9 from Marek Olšák ---
I don't remember having anything useful besides some quick hacks and I don't
have them anymore. I came to the conclusion ARB_depth_clamp is not
implementable on r300-r500. I don't think the extended range [-2,2
https://bugs.freedesktop.org/show_bug.cgi?id=57875
--- Comment #8 from Alex Deucher ---
(In reply to comment #7)
> Aw, of course thr R3xx_3D_Registers.pdf document doesn't document bit 24 of
> R300_GB_TILE_CONFIG, which supposedly contains the Z_EXTENDED flag...
That bit only exists on r5xx asic
Simplify the Exynos prime implementation by using the default behavior provided
by drm_gem_prime_import and drm_gem_prime_export.
Signed-off-by: Aaron Plattner
---
I still need to find a system to test this.
drivers/gpu/drm/exynos/exynos_drm_dmabuf.c | 151 ++---
drivers
Simplify the Nouveau prime implementation by using the default behavior provided
by drm_gem_prime_import and drm_gem_prime_export.
Signed-off-by: Aaron Plattner
---
drivers/gpu/drm/nouveau/nouveau_bo.h| 1 -
drivers/gpu/drm/nouveau/nouveau_drm.c | 9 +-
drivers/gpu/drm/nouveau/nouveau_
Simplify the Radeon prime implementation by using the default behavior provided
by drm_gem_prime_import and drm_gem_prime_export.
Signed-off-by: Aaron Plattner
---
drivers/gpu/drm/radeon/radeon_drv.c | 17 ++--
drivers/gpu/drm/radeon/radeon_prime.c | 169 +-
2
Instead of reimplementing all of the dma_buf functionality in every driver,
create helpers drm_prime_import and drm_prime_export that implement them in
terms of new, lower-level hook functions:
gem_prime_pin: callback when a buffer is created, used to pin buffers into GTT
gem_prime_get_pages:
This series adds helper functions that abstract the core parts of
.gem_prime_import and .gem_prime_export so that drivers don't have to worry
about the low-level details. These helpers are optional. A driver can use them
by plugging in drm_gem_prime_import and drm_gem_prime_export into the drm_dr
Simplify the Exynos prime implementation by using the default behavior provided
by drm_gem_prime_import and drm_gem_prime_export.
Signed-off-by: Aaron Plattner
---
I still need to find a system to test this.
drivers/gpu/drm/exynos/exynos_drm_dmabuf.c | 151 ++---
drivers
Simplify the Radeon prime implementation by using the default behavior provided
by drm_gem_prime_import and drm_gem_prime_export.
Signed-off-by: Aaron Plattner
---
drivers/gpu/drm/radeon/radeon_drv.c | 17 ++--
drivers/gpu/drm/radeon/radeon_prime.c | 169 +-
2
Simplify the Nouveau prime implementation by using the default behavior provided
by drm_gem_prime_import and drm_gem_prime_export.
Signed-off-by: Aaron Plattner
---
drivers/gpu/drm/nouveau/nouveau_bo.h| 1 -
drivers/gpu/drm/nouveau/nouveau_drm.c | 9 +-
drivers/gpu/drm/nouveau/nouveau_
Instead of reimplementing all of the dma_buf functionality in every driver,
create helpers drm_prime_import and drm_prime_export that implement them in
terms of new, lower-level hook functions:
gem_prime_pin: callback when a buffer is created, used to pin buffers into GTT
gem_prime_get_pages:
This series adds helper functions that abstract the core parts of
.gem_prime_import and .gem_prime_export so that drivers don't have to worry
about the low-level details. These helpers are optional. A driver can use them
by plugging in drm_gem_prime_import and drm_gem_prime_export into the drm_dr
On Mon, 26 Nov 2012 16:39:58 +0100, Steffen Trumtrar wrote:
> On Mon, Nov 26, 2012 at 02:37:26PM +0200, Tomi Valkeinen wrote:
> > On 2012-11-26 11:07, Steffen Trumtrar wrote:
> >
> > > +/*
> > > + * Subsystem independent description of a videomode.
> > > + * Can be generated from struct display_t
On 12/06/2012 08:28 AM, Thierry Reding wrote:
> On Wed, Dec 05, 2012 at 06:51:20PM +0100, Lars-Peter Clausen wrote:
>> On 12/05/2012 05:45 PM, Thierry Reding wrote:
>>> Add a generic helper to fill in an HDMI AVI infoframe with data
>>> extracted from a DRM display mode.
>>
>> That's a very nice pa
Memory for _manager is allocated using kzalloc() but the result is not checked.
Free _manager on error lest memory become orphaned.
I was led to scrutinize ttm_page_alloc_init() from a smatch warning:
drivers/gpu/drm/ttm/ttm_page_alloc.c:799 ttm_page_alloc_init() error: potential
null dereferen
https://bugs.freedesktop.org/show_bug.cgi?id=57875
--- Comment #7 from Stefan Dösinger ---
Aw, of course thr R3xx_3D_Registers.pdf document doesn't document bit 24 of
R300_GB_TILE_CONFIG, which supposedly contains the Z_EXTENDED flag...
--
You are receiving this mail because:
You are the assign
https://bugs.freedesktop.org/show_bug.cgi?id=57875
--- Comment #6 from Stefan Dösinger ---
I can reproduce the bug, and after a quick investigation it seems to be a
legitimate problem how depth clamping is handled. The application enables it,
it enables it only if the extension is available and i
1 - 100 of 161 matches
Mail list logo
