On Wed, Dec 05, 2012 at 05:34:30PM +0100, Daniel Vetter wrote:
> On Wed, Dec 5, 2012 at 2:28 PM, Thierry Reding
> wrote:
> >> Imo that's worse, since now drm manages even more of the driver->hw
> >> binding process. In my dream world the drm driver just registers a
> >> normal driver at module loa
https://bugs.freedesktop.org/show_bug.cgi?id=55919
Tomasz P. changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://bugs.freedesktop.org/show_bug.cgi?id=35446
Tomasz P. changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://bugs.freedesktop.org/show_bug.cgi?id=57888
--- Comment #10 from Tomasz P. ---
Created attachment 71054
--> https://bugs.freedesktop.org/attachment.cgi?id=71054&action=edit
fishbowl screenshot
--
You are receiving this mail because:
You are the assignee for the bug.
___
https://bugs.freedesktop.org/show_bug.cgi?id=57888
--- Comment #11 from Tomasz P. ---
(In reply to comment #5)
> Created attachment 71019 [details] [review]
> Possible fix
>
> Does this patch help?
The patch fixes compiler warning that there is too many ALU instructions and
textures are visible
https://bugs.freedesktop.org/show_bug.cgi?id=57888
--- Comment #12 from Tomasz P. ---
Ok I have got better screenshots from "Amnesia". Mesa-git.png shows that there
are textures missing but light is ok.
with-patch.png shows textures but light is corrupted.
--
You are receiving this mail becaus
https://bugs.freedesktop.org/show_bug.cgi?id=57888
--- Comment #13 from Tomasz P. ---
Created attachment 71059
--> https://bugs.freedesktop.org/attachment.cgi?id=71059&action=edit
before patch
--
You are receiving this mail because:
You are the assignee for the bug.
__
https://bugs.freedesktop.org/show_bug.cgi?id=57888
--- Comment #14 from Tomasz P. ---
Created attachment 71060
--> https://bugs.freedesktop.org/attachment.cgi?id=71060&action=edit
with-patch
--
You are receiving this mail because:
You are the assignee for the bug.
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()
error: potential null dereference 'connector->edid_blob_ptr'.
(dr
On Fri, Nov 30, 2012 at 7:11 AM, Maarten Lankhorst
wrote:
> With all the previous patches there shouldn't be anything lying on the
> reservations being atomic
> with removal of the bo's from the lru lists any more.
>
> As such we can finally fix the locking primitives and make it act like normal
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 lockdep annotations for
> reservations.
>
> Signed-of
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 hold. Only when we succeed,
> we try to get back o
On Wed, Dec 5, 2012 at 8:15 PM, Jerome Glisse wrote:
> On Fri, Nov 30, 2012 at 7:11 AM, Maarten Lankhorst
> wrote:
>> With all the previous patches there shouldn't be anything lying on the
>> reservations being atomic
>> with removal of the bo's from the lru lists any more.
>>
>> As such we can
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
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 map each buffer to target hardware to get a
> > d
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 patch series, comes in pretty handy. Thanks :)
>
>
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
Am Donnerstag, den 06.12.2012, 15:49 +0800 schrieb Mark Zhang:
> 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 comma
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 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
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
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
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
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
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 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 Thu, Dec 06, 2012 at 03:16:31PM +0100, Daniel Vetter wrote:
> 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/
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
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
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 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
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)
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
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
On Thu, Dec 06, 2012 at 03:09:00PM +0100, Daniel Vetter wrote:
> On Wed, Dec 05, 2012 at 05:45:42PM +0100, Thierry Reding wrote:
[...]
> > diff --git a/drivers/gpu/drm/drm_hdmi.c b/drivers/gpu/drm/drm_hdmi.c
> > new file mode 100644
> > index 000..821ca56
> > --- /dev/null
> > +++ b/drivers/gpu
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 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 mmap
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
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_
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 les
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"
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 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
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 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, sea
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 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()
> err
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_
https://bugs.freedesktop.org/show_bug.cgi?id=57875
--- Comment #4 from Stefan Dösinger ---
I'll have a look at it once I find a download for this app.
--
You are receiving this mail because:
You are the assignee for the bug.
___
dri-devel mailing list
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
On Thu, Dec 06, 2012 at 04:57:27PM +0100, Daniel Vetter wrote:
> 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, &
On Thu, Dec 06, 2012 at 04:44:38PM +0100, Daniel Vetter wrote:
> 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 &
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
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
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
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.fr
https://bugs.freedesktop.org/show_bug.cgi?id=57875
--- Comment #5 from Piero Finizio ---
http://sldev.free.fr/
The stable branch Linux: CoolVLViewer-1.26.4.XX works with r300,
the CoolVLViewer-1.26.5.XX doesn't because it derives from Second Life
official viewer series 3 and so suffers from th
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
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
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
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
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:
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_
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
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
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
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
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 ++---
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
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.
__
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
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 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
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 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_
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
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
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
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/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
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
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/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 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)
>>>
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
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
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
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 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 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 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 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 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
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 map each buffer to target hardware to get a
> > d
rrect value for
this is?
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/9078e564/attachment.pgp>
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
Am Donnerstag, den 06.12.2012, 15:49 +0800 schrieb Mark Zhang:
> 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 comma
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 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
1 - 100 of 161 matches
Mail list logo
