On Fri, Nov 09, 2012 at 05:09:51PM -0700, Stephen Warren wrote:
> On 11/09/2012 06:59 AM, Thierry Reding wrote:
> > This commit adds a KMS driver for the Tegra20 SoC. This includes basic
> > support for host1x and the two display controllers found on the Tegra20
> > SoC. Each display controller can
https://bugs.freedesktop.org/show_bug.cgi?id=56936
--- Comment #4 from maxi...@free.fr ---
What do you mean about make clean ? between each git bisect I did a git clean
-fdx ant full rebuild.
Both are native x64 apps.
And I'm using LLVM compiler.
--
You are receiving this mail because:
You are
https://bugs.freedesktop.org/show_bug.cgi?id=56936
--- Comment #5 from Alex Deucher ---
(In reply to comment #4)
> And I'm using LLVM compiler.
You'll need to use the old compiler for now. Disable the llvm compiler or set
R600_LLVM=0.
--
You are receiving this mail because:
You are the assign
https://bugs.freedesktop.org/show_bug.cgi?id=56936
--- Comment #6 from maxi...@free.fr ---
Indeed, disabling the llvm compiler fixes the issue I'm facing.
--
You are receiving this mail because:
You are the assignee for the bug.
___
dri-devel mailing l
https://bugs.freedesktop.org/show_bug.cgi?id=56966
Priority: medium
Bug ID: 56966
Keywords: regression
CC: mar...@gmail.com
Assignee: dri-devel@lists.freedesktop.org
Summary: [r300g, bisected] multiple piglit tests crash in
https://bugs.freedesktop.org/show_bug.cgi?id=56966
--- Comment #1 from Pavel Ondračka ---
Created attachment 69881
--> https://bugs.freedesktop.org/attachment.cgi?id=69881&action=edit
better backtrace
--
You are receiving this mail because:
You are the assignee for the bug.
__
On Fri, Nov 09, 2012 at 05:00:54PM +0100, Christian König wrote:
> On 09.11.2012 16:45, Rafał Miłecki wrote:
> >2012/11/9 Thierry Reding :
> >>+/* all fields little endian */
> >>+struct hdmi_audio_infoframe {
> >>+ /* PB0 */
> >>+ u8 csum;
> >>+
> >>+ /* PB1 */
> >>+ unsign
On Sat, Nov 10, 2012 at 10:01:18PM +0100, Thierry Reding wrote:
> On Fri, Nov 09, 2012 at 05:00:54PM +0100, Christian König wrote:
> > On 09.11.2012 16:45, Rafał Miłecki wrote:
> > >2012/11/9 Thierry Reding :
> > >>+/* all fields little endian */
> > >>+struct hdmi_audio_infoframe {
> > >>+ /
age flip hasn't occured yet.
> And that means the fb.crtc pointer is entirely pointless.
>
>
I don't think so. let's see it again. below is my idea AND the reason I
posted this patch.
Original codes,
gem alloc(gem0);
-> gem0 refcount = 1
gem0 mmap
-> gem0 refcount = 2
gem alloc(gem1);
-> gem1 refcount =1
gem1 mmap
-> gem1 refcount =2
addfb(fb0, gem0);
-> gem0 refcount=3
addfb(fb1,gem1);
-> gem1 refcount = 3
setcrtc(fb0, crtc0)
-> crtc0.fb = fb0
pageflip(crtc0, fb1);
-> crtc0.fb = fb1.
and pageflip is repeated
close(gem0)
-> gem0 refcount = 2
close(gem1)
->gem1 refcount = 2
munmap(gem0)
->gem0 refcount = 1
munmap(gem1)
->gem1 refcount = 1
close(drm)
1. fb release
-> check if crtc->fb is same as fb0 but current crtc is pointing to fb1
2. so free fb0 without disabling current crtc.
-> gem0 refcount = 0 so released. At this time, dma access invalid memory
region unfortunately* *if the dma is accessing gem0.
With my patch,
...
setcrtc(fb0, crtc0)
-> crtc0.fb = fb0, fb0.crtc = crtc0
pageflip(crtc0, fb1);
-> crtc0.fb = fb1, fb1.crtc = crtc0.
and pageflip is repeated
close(gem0)
-> gem0 refcount = 2
close(gem1)
->gem1 refcount = 2
munmap(gem0)
->gem0 refcount = 1
munmap(gem1)
->gem1 refcount = 1
close(drm)
1. fb release
-> fb0->crtc is same as crtc so disable crtc (dma stop)
2. and free fb0.
-> gem0 refcount = 0 so released. We can avoid invalid memory access
because the dma was stopped.
In addition, one thing you pointed should be considered like below,
1. When rmfb is called, if fb is last one then it sets fb->crtc to NULL.
- the fb is cleaned up with disabling crtc.
That's all and the issue I faced with.
I'd happy to give me any comments, opinions.
Thanks,
Inki Dae
> --
> Ville Syrj?l?
> Intel OTC
> ___
> 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/20121110/977f5970/attachment.html>
refcount;
> > struct list_head head;
> > struct drm_mode_object base;
> > + struct drm_crtc *crtc;
> > const struct drm_framebuffer_funcs *funcs;
> > unsigned int pitches[4];
> > unsigned int offsets[4];
> > --
> > 1.7.4.1
> >
> > ___
> > 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/20121110/c3f49ec2/attachment-0001.html>
2012. 11. 10. ?? 2:10 Rob Clark ??:
> On Fri, Nov 9, 2012 at 1:39 AM, Inki Dae wrote:
>> diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
>> index 3fa18b7..92889be 100644
>> --- a/include/drm/drm_crtc.h
>> +++ b/include/drm/drm_crtc.h
>> @@ -256,6 +256,7 @@ struct drm_framebuffer
hat is exactly the same behaviour we have today, so you still get
> > > the invalid memory access to fb0 if the page flip hasn't occured yet.
> > > And that means the fb.crtc pointer is entirely pointless.
> > >
> > >
> > I don't think so. let's see it again. below is my idea AND the reason I
> > posted this patch.
> > Original codes,
> > gem alloc(gem0);
> > -> gem0 refcount = 1
> > gem0 mmap
> > -> gem0 refcount = 2
> > gem alloc(gem1);
> > -> gem1 refcount =1
> > gem1 mmap
> > -> gem1 refcount =2
> > addfb(fb0, gem0);
> > -> gem0 refcount=3
> > addfb(fb1,gem1);
> > -> gem1 refcount = 3
> > setcrtc(fb0, crtc0)
> > -> crtc0.fb = fb0
> > pageflip(crtc0, fb1);
> > -> crtc0.fb = fb1.
> > and pageflip is repeated
> >
> > close(gem0)
> > -> gem0 refcount = 2
> > close(gem1)
> > ->gem1 refcount = 2
> > munmap(gem0)
> > ->gem0 refcount = 1
> > munmap(gem1)
> > ->gem1 refcount = 1
> >
> > close(drm)
> > 1. fb release
> > -> check if crtc->fb is same as fb0 but current crtc is pointing to fb1
> > 2. so free fb0 without disabling current crtc.
> > -> gem0 refcount = 0 so released. At this time, dma access invalid memory
> > region unfortunately* *if the dma is accessing gem0.
> >
> >
> >
> > With my patch,
> > ...
> > setcrtc(fb0, crtc0)
> > -> crtc0.fb = fb0, fb0.crtc = crtc0
> > pageflip(crtc0, fb1);
> > -> crtc0.fb = fb1, fb1.crtc = crtc0.
> > and pageflip is repeated
> >
> > close(gem0)
> > -> gem0 refcount = 2
> > close(gem1)
> > ->gem1 refcount = 2
> > munmap(gem0)
> > ->gem0 refcount = 1
> > munmap(gem1)
> > ->gem1 refcount = 1
> > close(drm)
> > 1. fb release
> > -> fb0->crtc is same as crtc so disable crtc (dma stop)
>
> No, that's wrong. The current fb is fb1, so destroying fb0 must not
> disable the crtc.
>
>
Do you think this is wrong that when fb0 is destroyed, the crtc also is
disabled and crtc is pointing to fb1? And in case of Exynos driver,
disabling the crtc would disable hardware overlay so other overlays would
be holded on as is. This is just Exynos case so I don't know how other SoCs
are operated. Could you explain how Desktop side is operated? Maybe there
is my missing point here.
Thanks,
Inki Dae
> > 2. and free fb0.
> > -> gem0 refcount = 0 so released. We can avoid invalid memory access
> > because the dma was stopped.
> > In addition, one thing you pointed should be considered like below,
> > 1. When rmfb is called, if fb is last one then it sets fb->crtc to NULL.
> > - the fb is cleaned up with disabling crtc.
> >
> > That's all and the issue I faced with.
> >
> > I'd happy to give me any comments, opinions.
> >
> > Thanks,
> > Inki Dae
>
> --
> Ville Syrj?l?
> Intel OTC
> ___
> 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/20121110/9b08bfe0/attachment-0001.html>
t; drivers/gpu/drm/tegra/output.c:272:20: error: 'struct tegra_output' has no
> > member named 'display'
>
> Does this depend on something not in linux-next?
It looks like I missed some changes when I split the patches up and then
forgot to check that the patches actua
:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20121110/ae2d0377/attachment.html>
:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20121110/a4ec4d74/attachment.html>
t was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20121110/61c03fa7/attachment.html>
was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20121110/6a713967/attachment.html>
the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20121110/97851d12/attachment.html>
tweak the
fields in the structure if the want or need to and call the packing
function to obtain a buffer that they can write to the controller.
Does that sound at all reasonable?
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/20121110/4cd6f4db/attachment.pgp>
void *buffer, size_t size);
>
> Such a scheme would allow DRM drivers to call the helper and tweak the
> fields in the structure if the want or need to and call the packing
> function to obtain a buffer that they can write to the controller.
>
> Does that sound at all reasonable?
And I forgot, maybe this shouldn't be included in the drivers/gpu/drm
subdirectory, but rather in a more generic location such as
drivers/video since other subsystems (V4L2) may want to use the same
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/20121110/ae73b6b0/attachment-0001.pgp>
On 09.11.2012 23:03, Thierry Reding wrote:
> On Fri, Nov 09, 2012 at 10:26:27AM -0600, Rob Clark wrote:
>> hmm, are these values defined by the hw? They look like register
>> offsets into the DC block?
> I don't think they are defined by the hardware. From what I gather these
> can arbitrarily be
21 matches
Mail list logo
