2012/12/7 Prathyush K
>
>
>
> 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
On Fri, Dec 7, 2012 at 7:36 AM, Inki Dae wrote:
> Thus, I'm not sure that your common set could cover all the cases including
> other frameworks. Please give me any opinions.
I don't think that's required - as long as it is fairly useable by
many drivers a helper library is good enough. And since
On Fri, Dec 7, 2012 at 8:28 AM, Thierry Reding
wrote:
> On Thu, Dec 06, 2012 at 02:55:23PM -0200, Paulo Zanoni wrote:
>> 2012/12/6 Paulo Zanoni :
>> For the changes inside intel_hdmi.c, I'd really like your patch to not
>> touch any of the "write_infoframe" or "set_infoframes" callbacks. I
>> thin
With this patch, When dma_buf_unmap_attachment is called,
the pages of sgt aren't unmapped from iommu table.
Instead, when dma_buf_detach is called, that would be done.
And also removes exynos_get_sgt function used to get clone sgt
and uses attachment's sgt instead. This patch would resolve
perfor
https://bugs.freedesktop.org/show_bug.cgi?id=57977
Priority: medium
Bug ID: 57977
Assignee: dri-devel@lists.freedesktop.org
Summary: Crash after multiple resolution change
Severity: normal
Classification: Unclassified
OS: Lin
On Fri, Dec 07, 2012 at 09:30:34AM +0100, Daniel Vetter wrote:
> On Fri, Dec 7, 2012 at 8:28 AM, Thierry Reding
> wrote:
> > On Thu, Dec 06, 2012 at 02:55:23PM -0200, Paulo Zanoni wrote:
> >> 2012/12/6 Paulo Zanoni :
> >> For the changes inside intel_hdmi.c, I'd really like your patch to not
> >>
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
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 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+ /
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");
if (unlikely(r
https://bugs.freedesktop.org/show_bug.cgi?id=57977
--- Comment #1 from David ---
The gdb output from using upstream's binaries of the game is a little bit
different, but it still crashes and it looks like it's inside of r300_dri.so.
david@Miho:~/temp/supertuxkart-0.7.3-linux-glibc2.11-i386/bi
When gem allocation is requested, kernel space mapping isn't needed.
But if need, such as console framebuffer, the physical pages would be
mapped with kernel space though vmap function.
Signed-off-by: Inki Dae
Signed-off-by: Kyungmin Park
---
drivers/gpu/drm/exynos/exynos_drm_buf.c | 28 +++
This patch releases allocated resources correctly.
Signed-off-by: Inki Dae
Signed-off-by: Kyungmin Park
---
drivers/gpu/drm/exynos/exynos_drm_fbdev.c | 24 +---
1 files changed, 17 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_fbdev.c
b/dri
https://bugs.freedesktop.org/show_bug.cgi?id=57977
--- Comment #2 from Michel Dänzer ---
Running supertuxkart in valgrind might yield more information about the double
free or memory corruption.
--
You are receiving this mail because:
You are the assignee for the bug.
__
https://bugs.freedesktop.org/show_bug.cgi?id=57977
Andreas Boll changed:
What|Removed |Added
Component|Drivers/DRI/r300|Drivers/Gallium/r300
--
You are receivin
https://bugzilla.kernel.org/show_bug.cgi?id=51381
Summary: [drm:atom_op_jump] *ERROR* atombios stuck in loop for
more than 5secs aborting, when disabled via
vgaswitcheroo
Product: Drivers
Version: 2.5
Kernel Version: Linu
On Thu, 06 Dec 2012, Tim Gardner wrote:
> 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 seem
On Fri, 07 Dec 2012 13:47:46 +0200, Jani Nikula
wrote:
>
> On Thu, 06 Dec 2012, Tim Gardner wrote:
> > + if (!saved_mode) {
> > + pr_err("i915: Could not allocate saved display mode.\n");
>
> Please use DRM_ERROR().
Truthfully neither, but join the growing petition to get real err
On Fri, 07 Dec 2012, Chris Wilson wrote:
> On Fri, 07 Dec 2012 13:47:46 +0200, Jani Nikula
> wrote:
>>
>> On Thu, 06 Dec 2012, Tim Gardner wrote:
>> > + if (!saved_mode) {
>> > + pr_err("i915: Could not allocate saved display mode.\n");
>>
>> Please use DRM_ERROR().
>
> Truthfully n
https://bugs.freedesktop.org/show_bug.cgi?id=57977
--- Comment #3 from David ---
Created attachment 71127
--> https://bugs.freedesktop.org/attachment.cgi?id=71127&action=edit
First run of Valgrind, it looks like Valgrind crashed with the app?
First run of Valgrind, it looks like Valgrind crash
https://bugs.freedesktop.org/show_bug.cgi?id=57977
--- Comment #4 from David ---
Created attachment 71128
--> https://bugs.freedesktop.org/attachment.cgi?id=71128&action=edit
Second run of Valgrind, it didn't crash.
--
You are receiving this mail because:
You are the assignee for the bug.
___
Op 06-12-12 22:50, Daniel Vetter schreef:
> 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_p
https://bugs.freedesktop.org/show_bug.cgi?id=57982
Priority: medium
Bug ID: 57982
Assignee: dri-devel@lists.freedesktop.org
Summary: Desktop corruption observed on Enabling Output
Severity: major
Classification: Unclassified
https://bugs.freedesktop.org/show_bug.cgi?id=57982
--- Comment #1 from samit vats ---
Created attachment 71130
--> https://bugs.freedesktop.org/attachment.cgi?id=71130&action=edit
xorg.log
--
You are receiving this mail because:
You are the assignee for the bug.
__
https://bugs.freedesktop.org/show_bug.cgi?id=57982
--- Comment #2 from samit vats ---
Created attachment 71131
--> https://bugs.freedesktop.org/attachment.cgi?id=71131&action=edit
dmesg
--
You are receiving this mail because:
You are the assignee for the bug.
_
https://bugzilla.kernel.org/show_bug.cgi?id=51381
Alex Deucher changed:
What|Removed |Added
CC||alexdeuc...@gmail.com
--- Comment #1 f
https://bugs.freedesktop.org/show_bug.cgi?id=57982
Alex Deucher changed:
What|Removed |Added
Attachment #71129|text/plain |image/png
mime type|
2012/12/5 Thierry Reding :
> Add generic helpers to pack HDMI infoframes into binary buffers.
>
> Signed-off-by: Thierry Reding
> ---
> Changes in v2:
> - add support for audio, vendor-specific and SPD infoframes
> - add various validity checks on infoframes
> - factor out checksum computation
>
>
From: Paulo Zanoni
Use the generic HDMI infoframe helpers to get rid of the duplicate
implementation in the i915 driver.
This patch is based on the initial patch by Thierry Reding, but with a
different approach.
TODO:
- The SDVO part is totally untested. I am not sure if the buffer
size o
Hi Paulo,
On Fri, Dec 7, 2012 at 4:11 PM, Paulo Zanoni wrote:
> From: Paulo Zanoni
>
> Use the generic HDMI infoframe helpers to get rid of the duplicate
> implementation in the i915 driver.
>
> This patch is based on the initial patch by Thierry Reding, but with a
> different approach.
>
> TODO
https://bugs.freedesktop.org/show_bug.cgi?id=57984
Priority: medium
Bug ID: 57984
Assignee: dri-devel@lists.freedesktop.org
Summary: r300g: blend sfactor=GL_DST_COLOR fails with FBOs
Severity: normal
Classification: Unclassified
https://bugs.freedesktop.org/show_bug.cgi?id=57977
Michel Dänzer changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://bugs.freedesktop.org/show_bug.cgi?id=57984
--- Comment #1 from Stefan Dösinger ---
I dug through the optimizations in r300_create_blend_state, and the problem is
the "Disable reading if SRC_ALPHA == 0" optimization. It is not correct if the
source factor is DEST_COLOR. I'm checking if any
https://bugzilla.kernel.org/show_bug.cgi?id=51381
--- Comment #2 from a...@anrd.net 2012-12-07 16:18:48 ---
Since this is a regression (everything worked like a charm in 3.6.6) i would
guess the logic is in place and that this is just a side effect of some other
fix. But that's only a guess a
https://bugzilla.kernel.org/show_bug.cgi?id=51381
--- Comment #3 from Alex Deucher 2012-12-07 16:22:31
---
Can you bisect?
--
Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are watching the assignee of the bu
https://bugzilla.kernel.org/show_bug.cgi?id=51381
Alan changed:
What|Removed |Added
CC||a...@lxorguk.ukuu.org.uk
Kernel Version|Linux
https://bugs.freedesktop.org/show_bug.cgi?id=57984
--- Comment #2 from Marek Olšák ---
(In reply to comment #1)
> I dug through the optimizations in r300_create_blend_state, and the problem
> is the "Disable reading if SRC_ALPHA == 0" optimization. It is not correct
> if the source factor is DEST
https://bugs.freedesktop.org/show_bug.cgi?id=57990
Priority: medium
Bug ID: 57990
Assignee: dri-devel@lists.freedesktop.org
Summary: xf86-video-ati Causes black stripes (RadeonHD4890 -
r770)
Severity: critical
Classificat
https://bugs.freedesktop.org/show_bug.cgi?id=57990
--- Comment #1 from Alex Deucher ---
Please attach your xorg log and dmesg output. What package(s) did you update
that caused the problem?
--
You are receiving this mail because:
You are the assignee for the bug.
__
https://bugs.freedesktop.org/show_bug.cgi?id=57990
--- Comment #2 from Rubén Reina ---
I had to format the system because I didn't know how to go back to an older
version. I'm using this ppa
https://launchpad.net/~oibaf/+archive/graphics-drivers/. Maybe here you can see
the problem, I think the p
https://bugs.freedesktop.org/show_bug.cgi?id=57990
Alex Deucher changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://bugs.freedesktop.org/show_bug.cgi?id=57990
--- Comment #4 from Rubén Reina ---
Yes, with that ppa mesa is updated too :/
--
You are receiving this mail because:
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freed
https://bugs.freedesktop.org/show_bug.cgi?id=57984
Andreas Boll changed:
What|Removed |Added
Attachment #71134|text/plain |image/png
mime type|
https://bugzilla.kernel.org/show_bug.cgi?id=51381
--- Comment #4 from a...@anrd.net 2012-12-07 17:34:31 ---
There's a lot of commits between 3.6.6 and 3.6.9, but I will see what I can do.
--
Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email
--- You are receiving thi
https://bugs.freedesktop.org/show_bug.cgi?id=57984
Alex Deucher changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://bugs.freedesktop.org/show_bug.cgi?id=57990
Andreas Boll changed:
What|Removed |Added
Status|RESOLVED|REOPENED
Resolution|NOTABUG
On 12/06/2012 10:36 PM, Inki Dae wrote:
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 dqb
On 12/06/2012 01:46 PM, 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 of new, lower-level hook func
On Fri, Dec 07, 2012 at 09:58:38AM -0800, Aaron Plattner wrote:
> On 12/06/2012 01:46 PM, Daniel Vetter wrote:
[snip]
> >- Just an idea for all the essential noop cpu helpers: Maybe just call
> > them dma_buf*noop and shovel them as convenience helpers into the
> > dma-buf.c code in the core,
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
> +/**
> + * drm_hdmi_avi_infoframe_from_display_mode() - fill an HDMI AVI infoframe
> with
>
On 12/07/2012 10:48 AM, Daniel Vetter wrote:
On Fri, Dec 07, 2012 at 09:58:38AM -0800, Aaron Plattner wrote:
On 12/06/2012 01:46 PM, Daniel Vetter wrote:
- To make it a first-class helper and remove any and all midlayer stints
from this (I truly loath midlayers ...) maybe shovel this into a
Required by i915 in order to avoid the allocation in the middle of
manipulating the drm_mm lists.
Use a pair of stubs to preserve the existing EXPORT_SYMBOLs for
backporting; to be removed later.
Cc: Dave Airlie
Cc: dri-devel@lists.freedesktop.org
Signed-off-by: Chris Wilson
---
drivers/gpu/dr
On Fri, Dec 7, 2012 at 9:44 PM, Heinz Diehl wrote:
> On 07.12.2012, Daniel Vetter wrote:
>> > I think I can reliably reproduce the hang on my machine now. I have to
>> > try some HD-videos on Youtube while writing a big file with dd. The
>> > hang often occurs withing max. 5 min.
>
>> That sounds
On Fri, Dec 7, 2012 at 9:33 PM, Aaron Plattner wrote:
> Ah, I see what you mean. This would also need either a pointer to the drv
> directly so the helpers can lock drv->struct_mutex, or a helper function to
> convert from a drm_prime_helper_obj* to a gem_buffer_object* in a
> driver-specific way
On Fri, 7 Dec 2012 22:08:13 +0100, Daniel Vetter wrote:
> ilk with rc6 disabled, and the two hangs you've attached both die on
> the MI_FLUSH in between a 3D primitive and a 2D blit, like all the
> other non-rc6 hangs we've seen thus far that indicate that 3.7
> regressed. This A looks _very_ good
On 12/07/2012 01:38 PM, Daniel Vetter wrote:
On Fri, Dec 7, 2012 at 9:33 PM, Aaron Plattner wrote:
Ah, I see what you mean. This would also need either a pointer to the drv
directly so the helpers can lock drv->struct_mutex, or a helper function to
convert from a drm_prime_helper_obj* to a gem
From: Alex Deucher
Pretty minor -next pull request. We some additional new bits waiting
internally for release. Hopefully Monday we can get at least some of
them out. The others will probably take a few more weeks.
Highlights of the current request:
- ELD registers for passing audio informati
https://bugs.freedesktop.org/show_bug.cgi?id=42373
--- Comment #41 from Kunal ---
Hi,
Any update on this bug?
As I mentioned in my previous comment c#37, v3.7-rc5 has been no better.
Anything more that I can try?
Any clue if and where can I find the documentation for the chip? (RV730, IIRC)
Ju
; drivers/gpu/drm/exynos/exynos_mixer.c | 240
> +--
> 6 files changed, 239 insertions(+), 127 deletions(-)
>
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
>
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20121207/1c82306a/attachment.html>
> + fimd_window_resume(dev);
> } else {
> + fimd_window_suspend(dev);
> +
> fimd_clock(ctx, false);
> ctx->suspended = true;
> }
> --
> 1.7.0.4
>
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
>
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20121207/f0333488/attachment.html>
fimd_enable_vblank(dev);
> +
> + fimd_window_resume(dev);
> } else {
> + fimd_window_suspend(dev);
> +
> fimd_clock(ctx, false);
> ctx->suspended = true;
> }
> --
> 1.7.0.4
>
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
>
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20121207/22e0eca4/attachment-0001.html>
iving a dump of all the fb's and
> gem objects in omapdrm has been quite useful in testing for and
> debugging memory leaks
>
>
>
Thanks for information. I looked into your driver and it seems useful to
us. Actually we have been using similar way and that includes other memory
relevant things also.
Thanks,
Inki Dae
BR,
> -R
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
>
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20121207/53f72da5/attachment.html>
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)
>>>
NULL
> #endif
> #endif
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.c
> b/drivers/gpu/drm/exynos/exynos_drm_drv.c
> index 2b287d2..2a04e97 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_drv.c
> +++ b/drivers/gpu/drm/exynos/exynos_drm_drv.c
> @@ -283,6 +283,8 @@ static struct drm_driver exynos_drm_driver = {
> .prime_fd_to_handle = drm_gem_prime_fd_to_handle,
> .gem_prime_export = exynos_dmabuf_prime_export,
> .gem_prime_import = exynos_dmabuf_prime_import,
> + .gem_prime_get_pages= exynos_gem_prime_get_pages,
> + .gem_prime_import_sg= exynos_gem_prime_import_sg,
> .ioctls = exynos_ioctls,
> .fops = &exynos_drm_driver_fops,
> .name = DRIVER_NAME,
> --
> 1.8.0.1
>
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
>
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20121207/cb11826c/attachment-0001.html>
exynos/exynos_drm_hdmi.c| 22 ++--
>> drivers/gpu/drm/exynos/exynos_drm_hdmi.h|2 +-
>> drivers/gpu/drm/exynos/exynos_mixer.c | 240
>> +--
>> 6 files changed, 239 insertions(+), 127 deletions(-)
>>
>> ___
>> d
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
en though I don't see the point as I already explained above.
Packing on the other hand is a very generic operation and none of the
drivers in the kernel need to pack the data in any different way. Some
hardware may required the packed data to be written to the registers in
some slighly different ways, but as I also already explained I think
that kind of code belongs in the drivers.
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/20121207/1fb0407a/attachment-0001.pgp>
pose of this patch series. Furthermore the functions that
write the infoframes to the hardware themselves could use some
refactoring of their own. There is a lot of duplication there.
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/20121207/153fa2cd/attachment.pgp>
fimd_enable_vblank(dev);
>> +
>> + fimd_window_resume(dev);
>> } else {
>> + fimd_window_suspend(dev);
>> +
>> fimd_clock(ctx, false);
>> ctx->suspended = true;
>> }
>> --
>> 1.7.0.4
>>
>> ___
>> dri-devel mailing list
>> dri-devel at lists.freedesktop.org
>> http://lists.freedesktop.org/mailman/listinfo/dri-devel
>>
>
>
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
>
>
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20121207/a9925fe6/attachment.html>
e *dev = ctx->subdrv.dev;
>>> if (enable) {
>>> int ret;
>>> - struct device *dev = ctx->subdrv.dev;
>>>
>>> ret = fimd_clock(ctx, true);
>>> if (ret < 0)
>>> @@ -824,7 +858,11 @@ static int fimd_activate(struct fimd_context *ctx,
>>> bool enable)
>>> /* if vblank was enabled status, enable it again. */
>>> if (test_and_clear_bit(0, &ctx->irq_flags))
>>> fimd_enable_vblank(dev);
>>> +
>>> + fimd_window_resume(dev);
>>> } else {
>>> + fimd_window_suspend(dev);
>>> +
>>> fimd_clock(ctx, false);
>>> ctx->suspended = true;
>>> }
>>> --
>>> 1.7.0.4
>>>
>>> ___
>>> dri-devel mailing list
>>> dri-devel at lists.freedesktop.org
>>> http://lists.freedesktop.org/mailman/listinfo/dri-devel
>>>
>>
>>
>> ___
>> dri-devel mailing list
>> dri-devel at lists.freedesktop.org
>> http://lists.freedesktop.org/mailman/listinfo/dri-devel
>>
>>
>
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20121207/1c2acc90/attachment-0001.html>
t;> + }
>>>> +}
>>>> +
>>>> static int fimd_activate(struct fimd_context *ctx, bool enable)
>>>> {
>>>> + struct device *dev = ctx->subdrv.dev;
>>>> if (enable) {
>>>> int ret;
>>>> - struct device *dev = ctx->subdrv.dev;
>>>>
>>>> ret = fimd_clock(ctx, true);
>>>> if (ret < 0)
>>>> @@ -824,7 +858,11 @@ static int fimd_activate(struct fimd_context *ctx,
>>>> bool enable)
>>>> /* if vblank was enabled status, enable it again. */
>>>> if (test_and_clear_bit(0, &ctx->irq_flags))
>>>> fimd_enable_vblank(dev);
>>>> +
>>>> + fimd_window_resume(dev);
>>>> } else {
>>>> + fimd_window_suspend(dev);
>>>> +
>>>> fimd_clock(ctx, false);
>>>> ctx->suspended = true;
>>>> }
>>>> --
>>>> 1.7.0.4
>>>>
>>>> ___
>>>> dri-devel mailing list
>>>> dri-devel at lists.freedesktop.org
>>>> http://lists.freedesktop.org/mailman/listinfo/dri-devel
>>>>
>>>
>>>
>>> ___
>>> dri-devel mailing list
>>> dri-devel at lists.freedesktop.org
>>> http://lists.freedesktop.org/mailman/listinfo/dri-devel
>>>
>>>
>>
>
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
>
>
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20121207/d154755e/attachment.html>
On Fri, Dec 7, 2012 at 7:36 AM, Inki Dae wrote:
> Thus, I'm not sure that your common set could cover all the cases including
> other frameworks. Please give me any opinions.
I don't think that's required - as long as it is fairly useable by
many drivers a helper library is good enough. And since
On Fri, Dec 7, 2012 at 8:28 AM, Thierry Reding
wrote:
> On Thu, Dec 06, 2012 at 02:55:23PM -0200, Paulo Zanoni wrote:
>> 2012/12/6 Paulo Zanoni :
>> For the changes inside intel_hdmi.c, I'd really like your patch to not
>> touch any of the "write_infoframe" or "set_infoframes" callbacks. I
>> thin
With this patch, When dma_buf_unmap_attachment is called,
the pages of sgt aren't unmapped from iommu table.
Instead, when dma_buf_detach is called, that would be done.
And also removes exynos_get_sgt function used to get clone sgt
and uses attachment's sgt instead. This patch would resolve
perfor
to
continue, or q to quit---
}, }, _M_p = 0xa7da32c
"/usr/share/games/supertuxkart/data/models//materials.xml"}}
(gdb)
--
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/20121207/8df36bbb/attachment.html>
the old
code. I used a #ifdef HDMI_GENERIC to easily switch between both code
paths and added some debug output to the register writes so that I could
compare both at the register level. If we do the same for Intel hardware
we should be able to fix this properly.
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/20121207/f6661041/attachment-0001.pgp>
) y
david at Miho:~/temp/supertuxkart-0.7.3-linux-glibc2.11-i386/bin$
--
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/20121207/be59f4ad/attachment-0001.html>
When gem allocation is requested, kernel space mapping isn't needed.
But if need, such as console framebuffer, the physical pages would be
mapped with kernel space though vmap function.
Signed-off-by: Inki Dae
Signed-off-by: Kyungmin Park
---
drivers/gpu/drm/exynos/exynos_drm_buf.c | 28 +++
This patch releases allocated resources correctly.
Signed-off-by: Inki Dae
Signed-off-by: Kyungmin Park
---
drivers/gpu/drm/exynos/exynos_drm_fbdev.c | 24 +---
1 files changed, 17 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_fbdev.c
b/dri
--
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20121207/be286cc5/attachment.html>
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/20121207/8b953c98/attachment.html>
On Wednesday 05 December 2012 01:29 AM, Rob Clark wrote:
> This patch changes the omapdrm KMS to bypass the omapdss "compat"
> layer and use the core omapdss API directly. This solves some layering
> issues that would cause unpin confusion vs GO bit status, because we
> would not know whether a pa
https://bugzilla.kernel.org/show_bug.cgi?id=51381
Summary: [drm:atom_op_jump] *ERROR* atombios stuck in loop for
more than 5secs aborting, when disabled via
vgaswitcheroo
Product: Drivers
Version: 2.5
Kernel Version: Linu
On Thu, 06 Dec 2012, Tim Gardner wrote:
> 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 seem
On Fri, 07 Dec 2012 13:47:46 +0200, Jani Nikula wrote:
>
> On Thu, 06 Dec 2012, Tim Gardner wrote:
> > + if (!saved_mode) {
> > + pr_err("i915: Could not allocate saved display mode.\n");
>
> Please use DRM_ERROR().
Truthfully neither, but join the growing petition to get real erro
On Fri, 07 Dec 2012, Chris Wilson wrote:
> On Fri, 07 Dec 2012 13:47:46 +0200, Jani Nikula linux.intel.com> wrote:
>>
>> On Thu, 06 Dec 2012, Tim Gardner wrote:
>> > + if (!saved_mode) {
>> > + pr_err("i915: Could not allocate saved display mode.\n");
>>
>> Please use DRM_ERROR().
>
algrind crashed with the app?
--
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/20121207/9a4794c4/attachment.html>
for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20121207/e4d3a739/attachment.html>
Op 06-12-12 22:50, Daniel Vetter schreef:
> 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_p
rved on Enabling Output (Screenshot
attached)
=
--
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/20121207/39f320a9/attac
xt part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20121207/0fa2e3c2/attachment.html>
xt part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20121207/b5ccef11/attachment.html>
https://bugzilla.kernel.org/show_bug.cgi?id=51381
Alex Deucher changed:
What|Removed |Added
CC||alexdeucher at gmail.com
--- Comment #
||
--
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/20121207/7490ec7f/attachment.html>
2012/12/5 Thierry Reding :
> Add generic helpers to pack HDMI infoframes into binary buffers.
>
> Signed-off-by: Thierry Reding
> ---
> Changes in v2:
> - add support for audio, vendor-specific and SPD infoframes
> - add various validity checks on infoframes
> - factor out checksum computation
>
>
From: Paulo Zanoni
Use the generic HDMI infoframe helpers to get rid of the duplicate
implementation in the i915 driver.
This patch is based on the initial patch by Thierry Reding, but with a
different approach.
TODO:
- The SDVO part is totally untested. I am not sure if the buffer
size o
1 - 100 of 135 matches
Mail list logo
