Re: [PATCH 1/4] drm/tilcdc: Fix an incorrect condition

[Sachin Kamat]

On 24 April 2013 10:08, Dave Airlie  wrote:
> On Wed, Apr 24, 2013 at 2:21 PM, Sachin Kamat  wrote:
>> On 24 April 2013 09:47, Rob Clark  wrote:
>>> On Tue, Apr 23, 2013 at 11:52 PM, Sachin Kamat  
>>> wrote:
 Hi Rob,

 With the merge window for 3.10 about to open shortly, I was wondering
 if the tilcdc patches are lined up somewhere as I could not find them
 in linux-next yet.
>>>
>>> I don't have any other patches for tilcdc, so if this isn't going
>>> through a pull req from tomi then I think it would be fine if Dave
>>> takes it directly through the drm-next tree.  This patch has my s-o-b,
>>> it fixes an obvious typo.
>>
>> Thanks Rob.
>>
>> Dave,
>> Could you please pick these 4 patches? Or do I send them again?
>>
>
> All 4 are in drm-next now.

Thanks Dave.


-- 
With warm regards,
Sachin
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 1/4] drm/tilcdc: Fix an incorrect condition

[Sachin Kamat]

On 24 April 2013 09:47, Rob Clark  wrote:
> On Tue, Apr 23, 2013 at 11:52 PM, Sachin Kamat  
> wrote:
>> Hi Rob,
>>
>> With the merge window for 3.10 about to open shortly, I was wondering
>> if the tilcdc patches are lined up somewhere as I could not find them
>> in linux-next yet.
>
> I don't have any other patches for tilcdc, so if this isn't going
> through a pull req from tomi then I think it would be fine if Dave
> takes it directly through the drm-next tree.  This patch has my s-o-b,
> it fixes an obvious typo.

Thanks Rob.

Dave,
Could you please pick these 4 patches? Or do I send them again?



>> On 27 March 2013 11:53, Tomi Valkeinen  wrote:
>>> Hi,
>>>
>>> On 2013-03-25 15:36, Rob Clark wrote:
 sorry, was offline for a while (moving), and missed the last email..

 I would guess that Tomi would send pull-req for tilcdc and omapdrm.
 Well I suppose I could do it if Tomi can't, although my
 pandas/beagles/beaglebones are not unpacked yet..
>>>
>>> Well, I know nothing about tilcdc, I don't have a board to test it, it
>>> was merged even if I had objections, and I've got my hands full already...
>>>
>>> I think for the moment tilcdc is either maintained by Rob, or is
>>> unmaintained.
>>>
>>> I will try to handle omapdrm, though.
>>>
>>>  Tomi
>>>
>>>



-- 
With warm regards,
Sachin
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 1/4] drm/tilcdc: Fix an incorrect condition

[Sachin Kamat]

Hi Rob,

With the merge window for 3.10 about to open shortly, I was wondering
if the tilcdc patches are lined up somewhere as I could not find them
in linux-next yet.

Thanks and regards,
Sachin.

On 27 March 2013 11:53, Tomi Valkeinen  wrote:
> Hi,
>
> On 2013-03-25 15:36, Rob Clark wrote:
>> sorry, was offline for a while (moving), and missed the last email..
>>
>> I would guess that Tomi would send pull-req for tilcdc and omapdrm.
>> Well I suppose I could do it if Tomi can't, although my
>> pandas/beagles/beaglebones are not unpacked yet..
>
> Well, I know nothing about tilcdc, I don't have a board to test it, it
> was merged even if I had objections, and I've got my hands full already...
>
> I think for the moment tilcdc is either maintained by Rob, or is
> unmaintained.
>
> I will try to handle omapdrm, though.
>
>  Tomi
>
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: Radeon lockup on 3.8.5-201.fc18.x86_64

[Andy Lutomirski]

On Tue, Apr 23, 2013 at 10:15 AM, Michel Dänzer  wrote:
> On Die, 2013-04-23 at 10:08 -0700, Andy Lutomirski wrote:
>> On Mon, Apr 22, 2013 at 10:55 PM, Michel Dänzer  wrote:
>> > On Mon, 2013-04-22 at 16:19 -0700, Andy Lutomirski wrote:
>> >
>> >> I'm not convinced there's an actual hang.  40 seconds is a long time,
>> >> and I've only ever seen this when clicking something, and when this
>> >> happens, the screen goes blank immediately (not after a 40 second
>> >> delay).
>> >
>> > Hmm, now that you mention this, I notice in your original report it
>> > claims that the CP stalled for 'more than 5102593msec', which is clearly
>> > bogus. Looks like something's wrong with the lockup detection.
>> > Did this start after a kernel update or something like that?
>>
>> It's recent.  It may have been when F18 switched from 3.7 to 3.8.
>
> Can you reproduce it with an upstream kernel? Can you bisect? I realize
> it'll probably take a long time, but unless someone has an idea which
> change might have introduced the problem...

Yuck.  I can try, but it takes days to reproduce this, so it will take
forever (and may end up with a wrong answer if I get lucky and don't
crash).

>
>
>> I think there are bugs in the lockup detection and in the lockup
>> recovery.  Firefox, in particular, is *really* slow afterwards.  Are
>> interrupts possibly getting dropped or misconfigured during the reset?
>
> Let's not get ahead of ourselves and focus on the lockup detection issue
> for now.

I don't understand the r600_gpu_check_soft_reset code, but could this
be the sequence of events that triggers it?

1. radeon_ring_is_lockup is called just as the very last command on
the ring completes, so last_rptr gets set to the rptr.
2. Nothing happens for a while (i.e. > lockup_timeout).  rptr doesn't change.
3. A very slightly slow operation starts.
4. radeon_ring_is_lockup gets called before that command completes.

radeon_ring_test_lockup will not detect a jiffies wrap-around (because
there wasn't one), rptr will equal last_rptr (because there hasn't
been any progress since last time), and the elapsed time will be
really long, because the function hasn't been called for a long time.
So a lockup gets detected, even though nothing's wrong.

There's a comment above radeon_ring_test_lockup that says:

 * A possible false positivie is if we get call after while and last_cp_rptr ==
 * the current CP rptr, even if it's unlikely it might happen. To avoid this
 * if the elapsed time since last call is bigger than 2 second than we return
 * false and update the tracking information. Due to this the caller must call
 * radeon_ring_test_lockup several time in less than 2sec for lockup
to be reported
 * the fencing code should be cautious about that.

but the corresponding code doesn't appear to exist anywhere.

Also, and unrelatedly, I revoke my comment about gmail issues being
fixed with hyperz off.  Gmail still draws incorrectly.  This may or
may not have anything to do with the radeon driver.

--Andy
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

RE: Disabling polling in drm_helper

[Mike Verstegen]

> -Original Message-
> From: Daniel Vetter [mailto:daniel.vet...@ffwll.ch] On Behalf Of Daniel Vetter
> On Tue, Apr 23, 2013 at 01:16:16AM +, Mike Verstegen wrote:
> > I'm troubleshooting an interesting problem where the
> > i915_hotplug_work_func is eating up a lot of time in a couple of
> > kworker threads. The interesting part of the problem is that this only
> > happens with one particular model of monitor which I haven't gotten to
> > the bottom of yet. But that's not the problem I'm trying  to resolve.
> 
> This should be fixed in latest drm-next. Can you please test that?
> 
I'd be glad to test, but that may be a bit over my skill level.  How could I 
help with testing drm-next?
In my original message, I forgot to include that this is a Centos 6.4 system 
with a 3.5.3 kernel.

> > One band-aid for this trouble is to disable the polling in the
> > irq_event # echo "N" > /sys/module/drm_kms_helper/parameters/poll
> >
> > That quiets down the kworker threads. Good
> >
> > To make this survive across boots, I added the following to
> > /etc/modprobe/local.conf options drm_kms_helper poll=N
> >
> > On reboot, the poll is still enabled
> > [root@localhost ~]# cat /sys/module/drm_kms_helper/parameters/poll
> > Y
> > Questions:
> > - Am I using "options drm_kms_helper poll=N" correctly
> > - Is there a better way to have this option set to false on initialization?
> 
> You probably need to rebuild your initrd with your distro tools since
> drm_kms_helper is loaded really early.

Great suggestion and a good learning point for me. I rebuilt the initramfs and 
the option is now recognized at boot.

Thanks

Mike
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: Radeon lockup on 3.8.5-201.fc18.x86_64

[Andy Lutomirski]

On Mon, Apr 22, 2013 at 10:55 PM, Michel Dänzer  wrote:
> On Mon, 2013-04-22 at 16:19 -0700, Andy Lutomirski wrote:
>> On Thu, Apr 18, 2013 at 2:12 PM, Alex Deucher  wrote:
>> > On Thu, Apr 18, 2013 at 5:11 PM, Andy Lutomirski  
>> > wrote:
>> >> On Mon, Apr 8, 2013 at 7:01 AM, Alex Deucher  
>> >> wrote:
>> >>> On Fri, Apr 5, 2013 at 5:11 PM, Andy Lutomirski  
>> >>> wrote:
>>  Every day or so, I'll click something and my screens go blank for a
>>  second or two.  dmesg complains about a lockup, and afterwards
>>  everything is painfully slow.  (Even switching focus to other emacs
>>  windows takes a second or two.)  Once this happens, if I restart X, I
>>  get a blank screen, although the mouse still works and I can switch
>>  VTs and use the console.
>> >>>
>> >>> Try disabling hyperZ.  Set env var R600_HYPERZ=0 (mesa 9.1) or
>> >>> R600_DEBUG=nohyperz (mesa git).
>> >>
>> >> It lasted longer.  I have both of those environment variables set on
>> >> the Xorg process but not on clients.  Do  I need it everywhere?
>> >
>> > For anything that uses the 3D driver.
>>
>> This didn't appear to fix it, although it may have fixed some
>> graphical glitches in gmail's compose window.
>
> Seems rather unlikely that's directly related to HyperZ, but who knows.
>
>
>> [350788.530966] radeon :08:00.0: GPU lockup CP stall for more than 
>> 40769msec
>> [350788.530970] radeon :08:00.0: GPU lockup (waiting for
>> 0x178f last fence id 0x178e)
>> [350788.532047] radeon :08:00.0: Saved 103 dwords of commands on ring 0.
>> [350788.532051] radeon :08:00.0: GPU softreset: 0x0003
>> [350788.547792] radeon :08:00.0:   GRBM_STATUS   = 0xA0003828
>> [350788.547794] radeon :08:00.0:   GRBM_STATUS_SE0   = 0x0007
>> [350788.547797] radeon :08:00.0:   GRBM_STATUS_SE1   = 0x0007
>> [350788.547799] radeon :08:00.0:   SRBM_STATUS   = 0x20C0
>> [350788.547802] radeon :08:00.0:   R_008674_CP_STALLED_STAT1 = 0x
>> [350788.547805] radeon :08:00.0:   R_008678_CP_STALLED_STAT2 = 0x
>> [350788.547807] radeon :08:00.0:   R_00867C_CP_BUSY_STAT = 0x0004
>> [350788.547810] radeon :08:00.0:   R_008680_CP_STAT  = 0x80008647
>> [350788.547811] radeon :08:00.0:   GRBM_SOFT_RESET=0x7F6B
>> [350788.547866] radeon :08:00.0:   GRBM_STATUS   = 0x3828
>> [350788.547869] radeon :08:00.0:   GRBM_STATUS_SE0   = 0x0007
>> [350788.547872] radeon :08:00.0:   GRBM_STATUS_SE1   = 0x0007
>> [350788.547874] radeon :08:00.0:   SRBM_STATUS   = 0x20C0
>> [350788.547877] radeon :08:00.0:   R_008674_CP_STALLED_STAT1 = 0x
>> [350788.547879] radeon :08:00.0:   R_008678_CP_STALLED_STAT2 = 0x
>> [350788.547882] radeon :08:00.0:   R_00867C_CP_BUSY_STAT = 0x
>> [350788.547884] radeon :08:00.0:   R_008680_CP_STAT  = 0x
>> [350788.565361] radeon :08:00.0: GPU reset succeeded, trying to resume
>> [350788.583801] [drm] probing gen 2 caps for device 8086:1d1a = 2/0
>> [350788.583807] [drm] enabling PCIE gen 2 link speeds, disable with
>> radeon.pcie_gen2=0
>> [350788.590840] [drm] PCIE GART of 512M enabled (table at 
>> 0x0004).
>> [350788.590976] radeon :08:00.0: WB enabled
>> [350788.590978] radeon :08:00.0: fence driver on ring 0 use gpu
>> addr 0x4c00 and cpu addr 0x880442f58c00
>> [350788.590979] radeon :08:00.0: fence driver on ring 3 use gpu
>> addr 0x4c0c and cpu addr 0x880442f58c0c
>> [350788.607480] [drm] ring test on 0 succeeded in 2 usecs
>> [350788.607560] [drm] ring test on 3 succeeded in 1 usecs
>> [350788.615053] [drm] ib test on ring 0 succeeded in 0 usecs
>> [350788.615133] [drm] ib test on ring 3 succeeded in 1 usecs
>>
>> I'm not convinced there's an actual hang.  40 seconds is a long time,
>> and I've only ever seen this when clicking something, and when this
>> happens, the screen goes blank immediately (not after a 40 second
>> delay).
>
> Hmm, now that you mention this, I notice in your original report it
> claims that the CP stalled for 'more than 5102593msec', which is clearly
> bogus. Looks like something's wrong with the lockup detection.
> Did this start after a kernel update or something like that?

It's recent.  It may have been when F18 switched from 3.7 to 3.8.

I think there are bugs in the lockup detection and in the lockup
recovery.  Firefox, in particular, is *really* slow afterwards.  Are
interrupts possibly getting dropped or misconfigured during the reset?

--Andy
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

RE: [PATCH v4] drm/exynos: prepare FIMD clocks

[myungjoo.ham]

2013/4/22 Inki Dae
> 2013/4/22 Rafael J. Wysocki 
> > On Monday, April 22, 2013 12:37:36 PM Tomasz Figa wrote:
> > > On Monday 22 of April 2013 12:17:39 Sylwester Nawrocki wrote:
> > > > On 04/22/2013 12:03 PM, Inki Dae wrote:
> > > > > > Also looks good to me. But what if power domain was disabled
without
> > > > > > pm
> > > > > > runtime? In this case, you must enable the power domain at
machine
> > > > > > code or
> > > > > > bootloader somewhere. This way would not only need some hard
codes
> > > > > > to turn
> > > > > > the power domain on but also not manage power management
fully. This
> > > > > > is same as only the use of pm runtime interface(needing some
hard
> > > > > > codes without pm runtime) so I don't prefer to add
> > > > > > clk_enable/disable to fimd probe(). I quite tend to force
only the
> > > > > > use of pm runtime as possible. So please add the hard codes
to
> > > > > > machine code or bootloader like you did for power domain if
you
> > > > > > want to use drm fimd without pm runtime.
> > > > >
> > > > > That's not how the runtime PM, clock subsystems work:
> > > > >
> > > > > 1) When CONFIG_PM_RUNTIME is disabled, all the used hardware
must be
> > > > > kept
> > > > > powered on all the time.
> > > > >
> > > > > 2) Common Clock Framework will always gate all clocks that
have zero
> > > > > enable_count. Note that CCF support for Exynos is already
merged for
> > > > > 3.10 and it will be the only available clock support method
for
> > > > > Exynos.
> > > > >
> > > > > AFAIK, drivers must work correctly in both cases, with
> > > > > CONFIG_PM_RUNTIME
> > > > > enabled and disabled.
> > > > >
> > > > > Then is the driver worked correctly if the power domain to this
device was
> > > > > disabled at bootloader without CONFIG_PM_RUNTIME and with
clk_enable()?  I
> > > > > think, in this case, the device wouldn't be worked correctly
because the
> > > > > power of the device remains off. So you must enable the power
domain
> > > > > somewhere. What is the difference between these two cases?
> > > >
> > > > How about making the driver dependant on PM_RUNTIME and making it
always
> > > > use pm_runtime_* API, regardless if the platform actually implements
runtime
> > > > PM or not ? Is there any issue in using the Runtime PM core always,
rather
> > > > than coding any workarounds in drivers when PM_RUNTIME is disabled ?
> > >
> > > I don't think this is a good idea. This would mean that any user that
from
> > > some reasons don't want to use PM_RUNTIME, would not be able to use
the driver
> > > anymore.
> > >
> > > Rafael, Kevin, do you have any opinion on this?
> > I agree.
> > 
> > Drivers should work for CONFIG_PM_RUNTIME unset too and static inline
stubs for
> > all runtime PM helpers are available in that case.
> > 
> Hi Rafael,
> The embedded system, at least Exynos SoC case, has the power domain device
and this device could be enabled only by pm runtime interface. So the device
couldn't be worked correctly without turning the power domain on only
calling clk_enable(). In this case, the power domain must be enabled at
machine code or bootloader. And the machine without CONFIG_PM_RUNTIME would
assume that their own drivers always are enabled so the devices would be
worked correctly. Is there any my missing point?


- Power domain: not controlled if !CONFIG_PM_RUNTIME. Thus, we may
assume that every power domain is kept ON from boot time if
!CONFIG_PM_RUNTIME.
If power domain is kept OFF from boot time (machine init code or bootloader)
with !CONFIG_PM_RUNTIME, then it's simple a mistake at BSP writer.

- Yes, the clock is still controlled while !CONFIG_PM_RUNTIME.

My opinion is also to let probe do clk-enables though I don't want it
to have #ifdef or "clk_enable()" in the probe function.
Thus, implementing "power_on()"-like function in the driver and let probe()
and
runtime_pm_get callback call it seems appropriate to me.
(that "fimd_active(ctx, true)" is "power-on" to itself, right?)


Cheers,
MyungJoo


___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 1/4] drm/tilcdc: Fix an incorrect condition

[Dave Airlie]

On Wed, Apr 24, 2013 at 2:21 PM, Sachin Kamat  wrote:
> On 24 April 2013 09:47, Rob Clark  wrote:
>> On Tue, Apr 23, 2013 at 11:52 PM, Sachin Kamat  
>> wrote:
>>> Hi Rob,
>>>
>>> With the merge window for 3.10 about to open shortly, I was wondering
>>> if the tilcdc patches are lined up somewhere as I could not find them
>>> in linux-next yet.
>>
>> I don't have any other patches for tilcdc, so if this isn't going
>> through a pull req from tomi then I think it would be fine if Dave
>> takes it directly through the drm-next tree.  This patch has my s-o-b,
>> it fixes an obvious typo.
>
> Thanks Rob.
>
> Dave,
> Could you please pick these 4 patches? Or do I send them again?
>

All 4 are in drm-next now.

Future reference, Acked-by: if you aren't going to handle the patches,
I'm not saying
it will make me notice them any quicker though.

Dave.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 1/4] drm/tilcdc: Fix an incorrect condition

[Rob Clark]

On Tue, Apr 23, 2013 at 11:52 PM, Sachin Kamat  wrote:
> Hi Rob,
>
> With the merge window for 3.10 about to open shortly, I was wondering
> if the tilcdc patches are lined up somewhere as I could not find them
> in linux-next yet.

I don't have any other patches for tilcdc, so if this isn't going
through a pull req from tomi then I think it would be fine if Dave
takes it directly through the drm-next tree.  This patch has my s-o-b,
it fixes an obvious typo.

BR,
-R


> Thanks and regards,
> Sachin.
>
> On 27 March 2013 11:53, Tomi Valkeinen  wrote:
>> Hi,
>>
>> On 2013-03-25 15:36, Rob Clark wrote:
>>> sorry, was offline for a while (moving), and missed the last email..
>>>
>>> I would guess that Tomi would send pull-req for tilcdc and omapdrm.
>>> Well I suppose I could do it if Tomi can't, although my
>>> pandas/beagles/beaglebones are not unpacked yet..
>>
>> Well, I know nothing about tilcdc, I don't have a board to test it, it
>> was merged even if I had objections, and I've got my hands full already...
>>
>> I think for the moment tilcdc is either maintained by Rob, or is
>> unmaintained.
>>
>> I will try to handle omapdrm, though.
>>
>>  Tomi
>>
>>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v4] drm/exynos: prepare FIMD clocks

[Inki Dae]

2013/4/23 myungjoo.ham 

> 2013/4/22 Inki Dae
> > 2013/4/22 Rafael J. Wysocki 
> > > On Monday, April 22, 2013 12:37:36 PM Tomasz Figa wrote:
> > > > On Monday 22 of April 2013 12:17:39 Sylwester Nawrocki wrote:
> > > > > On 04/22/2013 12:03 PM, Inki Dae wrote:
> > > > > > > Also looks good to me. But what if power domain was
> disabled
> without
> > > > > > > pm
> > > > > > > runtime? In this case, you must enable the power domain at
> machine
> > > > > > > code or
> > > > > > > bootloader somewhere. This way would not only need some
> hard
> codes
> > > > > > > to turn
> > > > > > > the power domain on but also not manage power management
> fully. This
> > > > > > > is same as only the use of pm runtime interface(needing
> some
> hard
> > > > > > > codes without pm runtime) so I don't prefer to add
> > > > > > > clk_enable/disable to fimd probe(). I quite tend to force
> only the
> > > > > > > use of pm runtime as possible. So please add the hard codes
> to
> > > > > > > machine code or bootloader like you did for power domain if
> you
> > > > > > > want to use drm fimd without pm runtime.
> > > > > >
> > > > > > That's not how the runtime PM, clock subsystems work:
> > > > > >
> > > > > > 1) When CONFIG_PM_RUNTIME is disabled, all the used hardware
> must be
> > > > > > kept
> > > > > > powered on all the time.
> > > > > >
> > > > > > 2) Common Clock Framework will always gate all clocks that
> have zero
> > > > > > enable_count. Note that CCF support for Exynos is already
> merged for
> > > > > > 3.10 and it will be the only available clock support method
> for
> > > > > > Exynos.
> > > > > >
> > > > > > AFAIK, drivers must work correctly in both cases, with
> > > > > > CONFIG_PM_RUNTIME
> > > > > > enabled and disabled.
> > > > > >
> > > > > > Then is the driver worked correctly if the power domain to this
> device was
> > > > > > disabled at bootloader without CONFIG_PM_RUNTIME and with
> clk_enable()?  I
> > > > > > think, in this case, the device wouldn't be worked correctly
> because the
> > > > > > power of the device remains off. So you must enable the power
> domain
> > > > > > somewhere. What is the difference between these two cases?
> > > > >
> > > > > How about making the driver dependant on PM_RUNTIME and making it
> always
> > > > > use pm_runtime_* API, regardless if the platform actually
> implements
> runtime
> > > > > PM or not ? Is there any issue in using the Runtime PM core always,
> rather
> > > > > than coding any workarounds in drivers when PM_RUNTIME is disabled
> ?
> > > >
> > > > I don't think this is a good idea. This would mean that any user that
> from
> > > > some reasons don't want to use PM_RUNTIME, would not be able to use
> the driver
> > > > anymore.
> > > >
> > > > Rafael, Kevin, do you have any opinion on this?
> > > I agree.
> > >
> > > Drivers should work for CONFIG_PM_RUNTIME unset too and static inline
> stubs for
> > > all runtime PM helpers are available in that case.
> > >
> > Hi Rafael,
> > The embedded system, at least Exynos SoC case, has the power domain
> device
> and this device could be enabled only by pm runtime interface. So the
> device
> couldn't be worked correctly without turning the power domain on only
> calling clk_enable(). In this case, the power domain must be enabled at
> machine code or bootloader. And the machine without CONFIG_PM_RUNTIME would
> assume that their own drivers always are enabled so the devices would be
> worked correctly. Is there any my missing point?
>
>
> - Power domain: not controlled if !CONFIG_PM_RUNTIME. Thus, we may
> assume that every power domain is kept ON from boot time if
> !CONFIG_PM_RUNTIME.
> If power domain is kept OFF from boot time (machine init code or
> bootloader)
> with !CONFIG_PM_RUNTIME, then it's simple a mistake at BSP writer.
>
> - Yes, the clock is still controlled while !CONFIG_PM_RUNTIME.
>
> My opinion is also to let probe do clk-enables though I don't want it
> to have #ifdef or "clk_enable()" in the probe function.
> Thus, implementing "power_on()"-like function in the driver and let probe()
> and
> runtime_pm_get callback call it seems appropriate to me.
> (that "fimd_active(ctx, true)" is "power-on" to itself, right?)
>
>
I thought that it should assume the power domain and relevant clocks are
enabled without CONFIG_PM_RUNTIME. So could anyone please tell me about
that? If only the power domain , I think Tomasz's proposal is good solution.

Thanks,
Inki Dae


>
> Cheers,
> MyungJoo
>
>
> --
> To unsubscribe from this list: send the line "unsubscribe
> linux-samsung-soc" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130423/b78b28ed/attachment.html>

Disabling polling in drm_helper

[Daniel Vetter]

On Tue, Apr 23, 2013 at 8:47 PM, Mike Verstegen
 wrote:
>> -Original Message-
>> From: Daniel Vetter [mailto:daniel.vetter at ffwll.ch] On Behalf Of Daniel 
>> Vetter
>> On Tue, Apr 23, 2013 at 01:16:16AM +, Mike Verstegen wrote:
>> > I'm troubleshooting an interesting problem where the
>> > i915_hotplug_work_func is eating up a lot of time in a couple of
>> > kworker threads. The interesting part of the problem is that this only
>> > happens with one particular model of monitor which I haven't gotten to
>> > the bottom of yet. But that's not the problem I'm trying  to resolve.
>>
>> This should be fixed in latest drm-next. Can you please test that?
>>
> I'd be glad to test, but that may be a bit over my skill level.  How could I 
> help with testing drm-next?
> In my original message, I forgot to include that this is a Centos 6.4 system 
> with a 3.5.3 kernel.

Google a good howto for installing a kernel from source for your
distro (I suggest using something which creates a real rpm for easy
un-installing). Then check out the below howto for git:

http://blog.ffwll.ch/2012/05/git-for-bug-reporters.html

And use that to download&install the drm-next branch from
git://people.freedesktop.org/~airlied/linux

Cheers, Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch

[PATCH v4] drm/exynos: prepare FIMD clocks

[myungjoo.ham]

2013/4/22 Inki Dae
> 2013/4/22 Rafael J. Wysocki 
> > On Monday, April 22, 2013 12:37:36 PM Tomasz Figa wrote:
> > > On Monday 22 of April 2013 12:17:39 Sylwester Nawrocki wrote:
> > > > On 04/22/2013 12:03 PM, Inki Dae wrote:
> > > > > > Also looks good to me. But what if power domain was disabled
without
> > > > > > pm
> > > > > > runtime? In this case, you must enable the power domain at
machine
> > > > > > code or
> > > > > > bootloader somewhere. This way would not only need some hard
codes
> > > > > > to turn
> > > > > > the power domain on but also not manage power management
fully. This
> > > > > > is same as only the use of pm runtime interface(needing some
hard
> > > > > > codes without pm runtime) so I don't prefer to add
> > > > > > clk_enable/disable to fimd probe(). I quite tend to force
only the
> > > > > > use of pm runtime as possible. So please add the hard codes
to
> > > > > > machine code or bootloader like you did for power domain if
you
> > > > > > want to use drm fimd without pm runtime.
> > > > >
> > > > > That's not how the runtime PM, clock subsystems work:
> > > > >
> > > > > 1) When CONFIG_PM_RUNTIME is disabled, all the used hardware
must be
> > > > > kept
> > > > > powered on all the time.
> > > > >
> > > > > 2) Common Clock Framework will always gate all clocks that
have zero
> > > > > enable_count. Note that CCF support for Exynos is already
merged for
> > > > > 3.10 and it will be the only available clock support method
for
> > > > > Exynos.
> > > > >
> > > > > AFAIK, drivers must work correctly in both cases, with
> > > > > CONFIG_PM_RUNTIME
> > > > > enabled and disabled.
> > > > >
> > > > > Then is the driver worked correctly if the power domain to this
device was
> > > > > disabled at bootloader without CONFIG_PM_RUNTIME and with
clk_enable()?  I
> > > > > think, in this case, the device wouldn't be worked correctly
because the
> > > > > power of the device remains off. So you must enable the power
domain
> > > > > somewhere. What is the difference between these two cases?
> > > >
> > > > How about making the driver dependant on PM_RUNTIME and making it
always
> > > > use pm_runtime_* API, regardless if the platform actually implements
runtime
> > > > PM or not ? Is there any issue in using the Runtime PM core always,
rather
> > > > than coding any workarounds in drivers when PM_RUNTIME is disabled ?
> > >
> > > I don't think this is a good idea. This would mean that any user that
from
> > > some reasons don't want to use PM_RUNTIME, would not be able to use
the driver
> > > anymore.
> > >
> > > Rafael, Kevin, do you have any opinion on this?
> > I agree.
> > 
> > Drivers should work for CONFIG_PM_RUNTIME unset too and static inline
stubs for
> > all runtime PM helpers are available in that case.
> > 
> Hi Rafael,
> The embedded system, at least Exynos SoC case, has the power domain device
and this device could be enabled only by pm runtime interface. So the device
couldn't be worked correctly without turning the power domain on only
calling clk_enable(). In this case, the power domain must be enabled at
machine code or bootloader. And the machine without CONFIG_PM_RUNTIME would
assume that their own drivers always are enabled so the devices would be
worked correctly. Is there any my missing point?


- Power domain: not controlled if !CONFIG_PM_RUNTIME. Thus, we may
assume that every power domain is kept ON from boot time if
!CONFIG_PM_RUNTIME.
If power domain is kept OFF from boot time (machine init code or bootloader)
with !CONFIG_PM_RUNTIME, then it's simple a mistake at BSP writer.

- Yes, the clock is still controlled while !CONFIG_PM_RUNTIME.

My opinion is also to let probe do clk-enables though I don't want it
to have #ifdef or "clk_enable()" in the probe function.
Thus, implementing "power_on()"-like function in the driver and let probe()
and
runtime_pm_get callback call it seems appropriate to me.
(that "fimd_active(ctx, true)" is "power-on" to itself, right?)


Cheers,
MyungJoo

[Bug 63632] mesa +r600 llvm = segfault

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=63632

--- Comment #12 from Andy Furniss  ---
(In reply to comment #11)
> (In reply to comment #10)
> > (In reply to comment #8)
> > > (In reply to comment #7)
> > > 
> > > > The problem on my gentoo system was that I had removed --enable-shared 
> > > > from
> > > > my llvm configure script a few days ago, so I was still linking with an
> > > > older LLVM.
> > > > 
> > > > Can you check that you are passing --enable-shared when configuring 
> > > > LLVM?
> > > 
> > > I wasn't, but passing it does not prevent the segfault - will look into
> > > libelf.
> > 
> > Is it the same segfault?  If the problem is libelf you will see a segfault
> > in radeon_llvm_emit.cpp.  Are building mesa with --enable-opencl or
> > --with-llvm-shared-libs ?
> 
> It is the same segfault as comment1.
> 
> I was building mesa with neither option.
> 
> Have just tried --with-llvm-shared-libs but get the same segfault.

Just tried with the two elf patches you posted to the list and the segfault is
fixed.

-- 
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/20130423/6fa19cef/attachment.html>

[Bug 62959] r600g (HD 6950 Cayman) fails piglit tests and hangs system

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=62959

--- Comment #53 from Alexandre Demers  ---
(In reply to comment #52)
> W.r.t. bisecting I found the info at http://webchick.net/node/99.
> Next week I do not have to go to work so I could give it a try.
> Where do I get the sources from?
> And what sha1's refer to all radeon commits in 3.7-rc1??

You will get the source from git.kernel.org. The first sync will take a while.
Something like this should allow you to get the whole Linus linux tree into the
linux-git folder:
git clone git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
linux-git

Your link seems about how to use git seems good. However, I would skip to
bisecting since you already have a known good and a known bad versions. You'll
have to sync your tree to a known good or bad version (assuming you didn't
change the code or that you are willing to loose your changes):
git reset --hard v3.7.5

You are now ready to bisect:
git bisect start

Tag this known bad version as "bad":
git bisect bad
This will tag the current version in the git tree as bad OR you can use "git
bisect bad v3.7.5" to tag a specific tag. You can do the same with a specific
commit

Tag the known good version as "good":
git bisect good v3.6.11

Git will do its work and let you know how many iterations will be needed to
find the first bad commit. It will then sync to a new commit. You have to
compile this kernel, install it and test it. Each time you are sure a given
kernel is good or bad, you will have to tell git by using "git bisect good" or
"git bisect bad". Git will move to the next iteration and you will have to
configure, compile, install and test again until you end up identifying the
first bad commit. The nearer you will get to the end of bisection, the faster
it will be to configure and compile the kernel (less commits, thus less
changes).

Once you'll be done and you'll have reported the bad commit here, you'll have
to stop bisecting and get back to where you started bisecting:
git bisect reset

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 63632] mesa +r600 llvm = segfault

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=63632

--- Comment #11 from Andy Furniss  ---
(In reply to comment #10)
> (In reply to comment #8)
> > (In reply to comment #7)
> > 
> > > The problem on my gentoo system was that I had removed --enable-shared 
> > > from
> > > my llvm configure script a few days ago, so I was still linking with an
> > > older LLVM.
> > > 
> > > Can you check that you are passing --enable-shared when configuring LLVM?
> > 
> > I wasn't, but passing it does not prevent the segfault - will look into
> > libelf.
> 
> Is it the same segfault?  If the problem is libelf you will see a segfault
> in radeon_llvm_emit.cpp.  Are building mesa with --enable-opencl or
> --with-llvm-shared-libs ?

It is the same segfault as comment1.

I was building mesa with neither option.

Have just tried --with-llvm-shared-libs but get the same segfault.

-- 
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/20130423/080b56d5/attachment.html>

[Bug 63702] tiling2d in radeon trash vdpau UVD textures

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=63702

--- Comment #5 from Rafael Castillo  ---
you need any additional info or debug info on this issue (please include
instructions)??

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 63730] UVD broken on HD5470 by "drm/radeon: raise UVD clocks only on demand"

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=63730

--- Comment #16 from Johannes Hirte  ---
Looks good. System booted as expected, dmesg shows

[2.167883] radeon :01:00.0: WB enabled
[2.168038] radeon :01:00.0: fence driver on ring 0 use gpu addr
0x2c00 and cpu addr 0x88011a165c00
[2.168325] radeon :01:00.0: fence driver on ring 3 use gpu addr
0x2c0c and cpu addr 0x88011a165c0c
[2.168817] radeon :01:00.0: fence driver on ring 5 use gpu addr
0x0005c418 and cpu addr 0xc90001e9c418
[2.185378] [drm] ring test on 0 succeeded in 1 usecs
[2.185625] [drm] ring test on 3 succeeded in 1 usecs
[2.362042] [drm] ring test on 5 succeeded in 1 usecs
[2.362226] [drm] UVD initialized successfully.
[2.362489] [drm] ib test on ring 0 succeeded in 0 usecs
[2.362671] [drm] ib test on ring 3 succeeded in 0 usecs
[2.514356] [drm] ib test on ring 5 succeeded
[2.568759] [drm] radeon atom DIG backlight initialized
[2.568914] [drm] Radeon Display Connectors

and no errors, video playback with UVD (mplayer) works and no crashes with
chromium. Perhaps the crash with the last patch came from the flash plugin that
tried to use VDPAU/UVD? Anyhow, it works now. Feel free to add my tested-by.

-- 
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/20130423/2385aaf9/attachment.html>

Radeon lockup on 3.8.5-201.fc18.x86_64

[Michel Dänzer]

On Die, 2013-04-23 at 10:08 -0700, Andy Lutomirski wrote: 
> On Mon, Apr 22, 2013 at 10:55 PM, Michel D?nzer  wrote:
> > On Mon, 2013-04-22 at 16:19 -0700, Andy Lutomirski wrote:
> >
> >> I'm not convinced there's an actual hang.  40 seconds is a long time,
> >> and I've only ever seen this when clicking something, and when this
> >> happens, the screen goes blank immediately (not after a 40 second
> >> delay).
> >
> > Hmm, now that you mention this, I notice in your original report it
> > claims that the CP stalled for 'more than 5102593msec', which is clearly
> > bogus. Looks like something's wrong with the lockup detection.
> > Did this start after a kernel update or something like that?
> 
> It's recent.  It may have been when F18 switched from 3.7 to 3.8.

Can you reproduce it with an upstream kernel? Can you bisect? I realize
it'll probably take a long time, but unless someone has an idea which
change might have introduced the problem...


> I think there are bugs in the lockup detection and in the lockup
> recovery.  Firefox, in particular, is *really* slow afterwards.  Are
> interrupts possibly getting dropped or misconfigured during the reset?

Let's not get ahead of ourselves and focus on the lockup detection issue
for now.


-- 
Earthling Michel D?nzer   |   http://www.amd.com
Libre software enthusiast |  Debian, X and DRI developer

[Bug 63632] mesa +r600 llvm = segfault

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=63632

--- Comment #10 from Tom Stellard  ---
(In reply to comment #8)
> (In reply to comment #7)
> 
> > The problem on my gentoo system was that I had removed --enable-shared from
> > my llvm configure script a few days ago, so I was still linking with an
> > older LLVM.
> > 
> > Can you check that you are passing --enable-shared when configuring LLVM?
> 
> I wasn't, but passing it does not prevent the segfault - will look into
> libelf.

Is it the same segfault?  If the problem is libelf you will see a segfault in
radeon_llvm_emit.cpp.  Are building mesa with --enable-opencl or
--with-llvm-shared-libs ?

-- 
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/20130423/aeb1e6c1/attachment.html>

[Bug 63632] mesa +r600 llvm = segfault

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=63632

--- Comment #9 from Andy Furniss  ---
(In reply to comment #6)
> Which version of libelf is used in each case? I was running into problems
> with the one from http://www.mr511.de/software/ but the one from Fedora's
> elfutils works fine. Tom told me on IRC the former requires an additional
> initialization step.

On my old 32bit setup - haven't got a clue, it was ages ago :-)

On the 64 bit build I have only recently installed as it became required for
llvm - I used the source from debian sid. Have now tried vanilla and with
debian diff, but still segfault.

Will look in to Fedora version.

-- 
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/20130423/fed31415/attachment.html>

[Bug 63632] mesa +r600 llvm = segfault

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=63632

--- Comment #8 from Andy Furniss  ---
(In reply to comment #7)

> The problem on my gentoo system was that I had removed --enable-shared from
> my llvm configure script a few days ago, so I was still linking with an
> older LLVM.
> 
> Can you check that you are passing --enable-shared when configuring LLVM?

I wasn't, but passing it does not prevent the segfault - will look into libelf.

-- 
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/20130423/238cd91d/attachment.html>

Disabling polling in drm_helper

[Mike Verstegen]

> -Original Message-
> From: Daniel Vetter [mailto:daniel.vetter at ffwll.ch] On Behalf Of Daniel 
> Vetter
> On Tue, Apr 23, 2013 at 01:16:16AM +, Mike Verstegen wrote:
> > I'm troubleshooting an interesting problem where the
> > i915_hotplug_work_func is eating up a lot of time in a couple of
> > kworker threads. The interesting part of the problem is that this only
> > happens with one particular model of monitor which I haven't gotten to
> > the bottom of yet. But that's not the problem I'm trying  to resolve.
> 
> This should be fixed in latest drm-next. Can you please test that?
> 
I'd be glad to test, but that may be a bit over my skill level.  How could I 
help with testing drm-next?
In my original message, I forgot to include that this is a Centos 6.4 system 
with a 3.5.3 kernel.

> > One band-aid for this trouble is to disable the polling in the
> > irq_event # echo "N" > /sys/module/drm_kms_helper/parameters/poll
> >
> > That quiets down the kworker threads. Good
> >
> > To make this survive across boots, I added the following to
> > /etc/modprobe/local.conf options drm_kms_helper poll=N
> >
> > On reboot, the poll is still enabled
> > [root at localhost ~]# cat /sys/module/drm_kms_helper/parameters/poll
> > Y
> > Questions:
> > - Am I using "options drm_kms_helper poll=N" correctly
> > - Is there a better way to have this option set to false on initialization?
> 
> You probably need to rebuild your initrd with your distro tools since
> drm_kms_helper is loaded really early.

Great suggestion and a good learning point for me. I rebuilt the initramfs and 
the option is now recognized at boot.

Thanks

Mike

[pull] radeon drm-next-3.10-2

[alexdeuc...@gmail.com]

From: Alex Deucher 

Hi Dave,

A few more updates for 3.10.  Nothing too major here.  Mostly bug fixes.
The big changes are adding golden register init for 7xx and newer asics
and some audio cleanups.

The following changes since commit f9df7ea33c87291365d943828bec852874f15c2f:

  Merge tag 'drm/tegra/for-3.10' of git://anongit.freedesktop.org/tegra/linux 
into drm-next (2013-04-22 20:49:07 +1000)

are available in the git repository at:

  git://people.freedesktop.org/~agd5f/linux drm-next-3.10-2

Alex Deucher (20):
  drm/radeon: update wait_for_vblank for r1xx-r4xx
  drm/radeon: update wait_for_vblank for r5xx-r7xx
  drm/radeon: update wait_for_vblank for evergreen+
  drm/radeon: properly lock disp in mc_stop/resume for r5xx-r7xx
  drm/radeon: properly lock disp in mc_stop/resume for evergreen+
  drm/radeon: disable the crtcs in mc_stop (r5xx-r7xx) (v2)
  drm/radeon: disable the crtcs in mc_stop (evergreen+) (v2)
  drm/radeon: fix hdmi mode enable on RS600/RS690/RS740
  drm/radeon: disable audio format interrupts on Evergreen
  drm/radeon: clean up audio supported check
  drm/radeon: clean up audio dto programming
  drm/radeon: switch audio handling to use callbacks
  drm/radeon: fix typo in si_select_se_sh()
  drm/radeon: add helper function to support golden registers
  drm/radeon/7xx: add support for golden register init
  drm/radeon/evergreen: add support for golden register init
  drm/radeon/cayman,TN: add support for golden register init (v2)
  drm/radeon/si: add support for golden register init
  drm/radeon: fix up audio dto programming for DCE2
  drm/radeon: fix endian bugs in radeon_atom_get_clock_dividers() (v3)

Christian K?nig (6):
  drm/radeon: cleanup UVD address checks
  drm/radeon: fix alignment of UVD fence
  drm/radeon: put UVD PLLs in bypass mode
  drm/radeon: raise UVD clocks only on demand
  drm/radeon: raise UVD clocks on init v3
  drm/radeon: disable UVD advanced semaphore mode

Rafa? Mi?ecki (6):
  drm/radeon: add helpers for masking and setting bits in regs
  drm/radeon/evergreen: setup HDMI before enabling it
  drm/radeon/evergreen: reorder HDMI setup
  drm/radeon/evergreen: write default channel numbers
  drm: add drm_edid_to_eld helper extracting SADs from EDID (v2)
  drm/radeon/evergreen: set SAD registers

 drivers/gpu/drm/drm_edid.c |   59 ++
 drivers/gpu/drm/radeon/atombios.h  |2 +
 drivers/gpu/drm/radeon/atombios_encoders.c |   17 +-
 drivers/gpu/drm/radeon/evergreen.c |  986 +++-
 drivers/gpu/drm/radeon/evergreen_hdmi.c|  169 +-
 drivers/gpu/drm/radeon/evergreen_reg.h |2 +
 drivers/gpu/drm/radeon/evergreend.h|1 +
 drivers/gpu/drm/radeon/ni.c|  281 
 drivers/gpu/drm/radeon/r100.c  |   77 ++-
 drivers/gpu/drm/radeon/r500_reg.h  |2 +
 drivers/gpu/drm/radeon/r600.c  |   34 +-
 drivers/gpu/drm/radeon/r600_audio.c|   64 +--
 drivers/gpu/drm/radeon/r600_hdmi.c |  150 ++---
 drivers/gpu/drm/radeon/r600d.h |7 +-
 drivers/gpu/drm/radeon/radeon.h|   17 +-
 drivers/gpu/drm/radeon/radeon_asic.c   |   18 +
 drivers/gpu/drm/radeon/radeon_asic.h   |5 +-
 drivers/gpu/drm/radeon/radeon_atombios.c   |6 +-
 drivers/gpu/drm/radeon/radeon_cs.c |4 +
 drivers/gpu/drm/radeon/radeon_device.c |   36 +
 drivers/gpu/drm/radeon/radeon_fence.c  |7 +-
 drivers/gpu/drm/radeon/radeon_uvd.c|   58 ++-
 drivers/gpu/drm/radeon/rs600.c |   52 ++-
 drivers/gpu/drm/radeon/rv515.c |   54 ++
 drivers/gpu/drm/radeon/rv770.c |  672 +++-
 drivers/gpu/drm/radeon/si.c|  817 +++-
 include/drm/drm_edid.h |9 +
 27 files changed, 3332 insertions(+), 274 deletions(-)

[PATCH 11/21] drm/tilcdc: use only a single module device table

[Arnd Bergmann]

The tilcdc driver fails to be built as a module because of extraneous
MODULE_DEVICE_TABLE entries:

drivers/gpu/drm/tilcdc/tilcdc_slave.o:(.data+0x54): multiple definition of 
`__mod_of_device_table'
drivers/gpu/drm/tilcdc/tilcdc_tfp410.o:(.data+0x54): first defined here
drivers/gpu/drm/tilcdc/tilcdc_panel.o:(.data+0x54): multiple definition of 
`__mod_of_device_table'
drivers/gpu/drm/tilcdc/tilcdc_tfp410.o:(.data+0x54): first defined here
drivers/gpu/drm/tilcdc/tilcdc_drv.o:(.data+0x184): multiple definition of 
`__mod_of_device_table'
drivers/gpu/drm/tilcdc/tilcdc_tfp410.o:(.data+0x54): first defined here

Since the entire point of these entries is to make the module autoload
when one of the devices is present, it's enough to keep the one entry
for "ti,am33xx-tilcdc", which should always be there if any of the
others are.

Cc: Rob Clark 
Cc: Dave Airlie 
Cc: dri-devel at lists.freedesktop.org
Signed-off-by: Arnd Bergmann 
---
 drivers/gpu/drm/tilcdc/tilcdc_panel.c  | 1 -
 drivers/gpu/drm/tilcdc/tilcdc_slave.c  | 1 -
 drivers/gpu/drm/tilcdc/tilcdc_tfp410.c | 1 -
 3 files changed, 3 deletions(-)

diff --git a/drivers/gpu/drm/tilcdc/tilcdc_panel.c 
b/drivers/gpu/drm/tilcdc/tilcdc_panel.c
index 580b74e..eb99f42 100644
--- a/drivers/gpu/drm/tilcdc/tilcdc_panel.c
+++ b/drivers/gpu/drm/tilcdc/tilcdc_panel.c
@@ -413,7 +413,6 @@ static struct of_device_id panel_of_match[] = {
{ .compatible = "ti,tilcdc,panel", },
{ },
 };
-MODULE_DEVICE_TABLE(of, panel_of_match);

 struct platform_driver panel_driver = {
.probe = panel_probe,
diff --git a/drivers/gpu/drm/tilcdc/tilcdc_slave.c 
b/drivers/gpu/drm/tilcdc/tilcdc_slave.c
index 568dc1c..db1d2fc 100644
--- a/drivers/gpu/drm/tilcdc/tilcdc_slave.c
+++ b/drivers/gpu/drm/tilcdc/tilcdc_slave.c
@@ -353,7 +353,6 @@ static struct of_device_id slave_of_match[] = {
{ .compatible = "ti,tilcdc,slave", },
{ },
 };
-MODULE_DEVICE_TABLE(of, slave_of_match);

 struct platform_driver slave_driver = {
.probe = slave_probe,
diff --git a/drivers/gpu/drm/tilcdc/tilcdc_tfp410.c 
b/drivers/gpu/drm/tilcdc/tilcdc_tfp410.c
index 58d487b..a36788f 100644
--- a/drivers/gpu/drm/tilcdc/tilcdc_tfp410.c
+++ b/drivers/gpu/drm/tilcdc/tilcdc_tfp410.c
@@ -396,7 +396,6 @@ static struct of_device_id tfp410_of_match[] = {
{ .compatible = "ti,tilcdc,tfp410", },
{ },
 };
-MODULE_DEVICE_TABLE(of, tfp410_of_match);

 struct platform_driver tfp410_driver = {
.probe = tfp410_probe,
-- 
1.8.1.2

[PATCH 00/21] ARM build fixes for 3.10

[Arnd Bergmann]

Hi everyone,

This is a set of bug fixes for build errors and warnings I am
seeing in the various defconfigs and/or allmodconfig builds
on linux-next. The majority of these showed up because we now
include a lot more platforms in allmodconfig than we used to.

Please apply to appropriate maintainer trees or provide
feedback, I can take care of the rest sending those through
arm-soc that I get no feedback on.

Arnd

Arnd Bergmann (21):
  Turn off -Wmaybe-uninitialized when building with -Os
  ARM: compressed/head.S: work around new binutils warning
  ARM: use optimized do_div only for EABI
  ARM: kvm: define KVM_ARM_MAX_VCPUS unconditionally
  ARM: OMAP2+: add dependencies on ARCH_MULTI_V6/V7
  ARM: tegra: call cpu_do_idle from C code
  ARM: tegra: unify tegra_idle_device definitions
  ASoC: ux500: forward declare msp_i2s_platform_data
  spi/sirf: fix MODULE_DEVICE_TABLE
  ssb: fix alignment of struct bcma_device_id
  drm/tilcdc: use only a single module device table
  mmc: sdhci-tegra: fix MODULE_DEVICE_TABLE
  misc: mark spear13xx-pcie-gadget as broken
  staging: nvec: allow modular build
  staging: comedi/dawboard2000: use mdelay for large delays
  staging/zsmalloc: don't use pgtable-mapping from modules
  tty/serial/sirf: fix MODULE_DEVICE_TABLE
  usb: phy: tegra: don't call into tegra-ehci directly
  usb: phy: don't mark usb_bind_phy as __init
  MFD: ab8500: export ab8500_gpadc_sw_hw_convert properly
  mtd: omap2: allow bulding as a module

 Makefile  |  2 +-
 arch/arm/boot/compressed/Makefile |  2 +-
 arch/arm/boot/compressed/head.S   | 12 
 arch/arm/include/asm/div64.h  |  2 +-
 arch/arm/kvm/Kconfig  |  6 +++---
 arch/arm/mach-omap2/Kconfig   |  5 +
 arch/arm/mach-tegra/cpuidle-tegra114.c|  5 ++---
 arch/arm/mach-tegra/cpuidle-tegra20.c |  4 +---
 arch/arm/mach-tegra/cpuidle-tegra30.c |  4 +---
 arch/arm/mach-tegra/cpuidle.c |  2 ++
 arch/arm/mach-tegra/cpuidle.h |  4 
 arch/arm/mach-tegra/pm.c  |  5 +
 arch/arm/mach-tegra/sleep-tegra20.S   |  2 +-
 drivers/gpu/drm/tilcdc/tilcdc_panel.c |  1 -
 drivers/gpu/drm/tilcdc/tilcdc_slave.c |  1 -
 drivers/gpu/drm/tilcdc/tilcdc_tfp410.c|  1 -
 drivers/mfd/ab8500-gpadc.c|  2 +-
 drivers/misc/Kconfig  |  2 +-
 drivers/mmc/host/sdhci-tegra.c|  2 +-
 drivers/mtd/nand/Kconfig  |  2 +-
 drivers/spi/spi-sirf.c|  2 +-
 drivers/staging/comedi/drivers/daqboard2000.c | 14 +++---
 drivers/staging/nvec/Kconfig  | 10 +-
 drivers/staging/zsmalloc/zsmalloc-main.c  |  2 +-
 drivers/tty/serial/sirfsoc_uart.c |  2 +-
 drivers/usb/host/ehci-tegra.c | 10 +-
 drivers/usb/otg/otg.c |  2 +-
 drivers/usb/phy/tegra_usb_phy.c   | 13 +
 include/linux/mod_devicetable.h   |  5 +++--
 include/linux/usb/tegra_usb_phy.h | 10 +-
 sound/soc/ux500/ux500_msp_i2s.h   |  1 +
 31 files changed, 82 insertions(+), 55 deletions(-)

-- 
1.8.1.2

Cc: Alan Stern 
Cc: Artem Bityutskiy 
Cc: Chris Ball 
Cc: Dave Airlie 
Cc: David Woodhouse 
Cc: Felipe Balbi 
Cc: Grant Likely 
Cc: Greg Kroah-Hartman 
Cc: Mark Brown 
Cc: Russell King 
Cc: Samuel Ortiz 
Cc: Stephen Warren 
Cc: Tony Lindgren 
Cc: Viresh Kumar 
Cc: alsa-devel at alsa-project.org
Cc: dri-devel at lists.freedesktop.org
Cc: linux-mtd at lists.infradead.org
Cc: linux-usb at vger.kernel.org
Cc: spi-devel-general at lists.sourceforge.net

[Bug 61182] r600g causes KWin crashes with kernel 3.8

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=61182

--- Comment #47 from Fredrik H?glund  ---
(In reply to comment #46)
> (In reply to comment #43)
> > I've pushed a patch to the stable branch in KDE that should fix this issue.
> 
> Could you post a link to that patch?

http://quickgit.kde.org/?p=kde-workspace.git&a=commit&h=a021eacf

-- 
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/20130423/5b4158fa/attachment.html>

[PATCH] drm: enforce dumb allocation flags policy

[Dave Airlie]

From: Dave Airlie 

I thought you could be trusted people, looks like I was wrong, no flags
for you.

I propose possibly adding a cursor flag here since it might be useful for
some people.

Signed-off-by: Dave Airlie 
---
 drivers/gpu/drm/drm_crtc.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
index dd64a06..490d57a 100644
--- a/drivers/gpu/drm/drm_crtc.c
+++ b/drivers/gpu/drm/drm_crtc.c
@@ -3829,6 +3829,9 @@ int drm_mode_create_dumb_ioctl(struct drm_device *dev,
 
if (!dev->driver->dumb_create)
return -ENOSYS;
+   /* kernel doesn't understand any flags yet */
+   if (args->flags)
+   return -EINVAL;
return dev->driver->dumb_create(file_priv, dev, args);
 }
 
-- 
1.8.1.2

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

abuse of dumb ioctls in exynos

[Tom Cooksey]

> It appears exynos is passing the generic flags from the dumb ioctls
> straight into the the GEM creation code.
> 
> The dumb flags are NOT driver specific, and are NOT to be used in this
> fashion. Please remove this use of the flags from your driver.
> 
> I was going to add one new flag to the interface for SCANOUT vs CURSOR
> for some drivers.

Having a flag to indicate a dumb buffer allocation is to be used as a 
scan-out buffer would be useful for xf86-video-armsoc. We're trying to
keep that driver as generic as possible and currently the main device-
specific bits are what flags to pass to DRM_IOCTL_MODE_CREATE_DUMB for
scanout & non-scanout buffer allocations. If a generic scanout flag could
be added, it would simplify armsoc a fair bit and also allow the DRM
drivers we're using armsoc with to comply with the don't pass device-
specific flags to create dumb.

For reference, the device-specific bits of armsoc are currently abstracted
here:




Note: We are still using DRM_IOCTL_MODE_CREATE_DUMB to allocate pixmap
and DRI2 buffers and have not come across any issues with doing that.
Certainly both Mali-400 & Mali-T6xx render to linear RGBA buffers and
the display controller's in SoCs shipping Mali also seem to happily
scan-out linear RGB buffers. Getting armsoc to run on OMAP (again) might
need a device-specific allocation function to allocate the tiled format
used on OMAP, but only for efficient 90-degree rotations (if I understood
Rob correctly). So maybe we could also one day add a "this buffer will be
rotated 90 degrees" flag?


Cheers,

Tom

PS: I've stuck in a fd.o bugzilla ticket to move xf86-video-armsoc to
freedesktop.org infrastructure, so hopefully it will live in a more
appropriate place soon, not to mention have a mailing list, etc.!

[pull] radeon drm-next-3.10-2

[alexdeucher]

From: Alex Deucher 

Hi Dave,

A few more updates for 3.10.  Nothing too major here.  Mostly bug fixes.
The big changes are adding golden register init for 7xx and newer asics
and some audio cleanups.

The following changes since commit f9df7ea33c87291365d943828bec852874f15c2f:

  Merge tag 'drm/tegra/for-3.10' of git://anongit.freedesktop.org/tegra/linux 
into drm-next (2013-04-22 20:49:07 +1000)

are available in the git repository at:

  git://people.freedesktop.org/~agd5f/linux drm-next-3.10-2

Alex Deucher (20):
  drm/radeon: update wait_for_vblank for r1xx-r4xx
  drm/radeon: update wait_for_vblank for r5xx-r7xx
  drm/radeon: update wait_for_vblank for evergreen+
  drm/radeon: properly lock disp in mc_stop/resume for r5xx-r7xx
  drm/radeon: properly lock disp in mc_stop/resume for evergreen+
  drm/radeon: disable the crtcs in mc_stop (r5xx-r7xx) (v2)
  drm/radeon: disable the crtcs in mc_stop (evergreen+) (v2)
  drm/radeon: fix hdmi mode enable on RS600/RS690/RS740
  drm/radeon: disable audio format interrupts on Evergreen
  drm/radeon: clean up audio supported check
  drm/radeon: clean up audio dto programming
  drm/radeon: switch audio handling to use callbacks
  drm/radeon: fix typo in si_select_se_sh()
  drm/radeon: add helper function to support golden registers
  drm/radeon/7xx: add support for golden register init
  drm/radeon/evergreen: add support for golden register init
  drm/radeon/cayman,TN: add support for golden register init (v2)
  drm/radeon/si: add support for golden register init
  drm/radeon: fix up audio dto programming for DCE2
  drm/radeon: fix endian bugs in radeon_atom_get_clock_dividers() (v3)

Christian König (6):
  drm/radeon: cleanup UVD address checks
  drm/radeon: fix alignment of UVD fence
  drm/radeon: put UVD PLLs in bypass mode
  drm/radeon: raise UVD clocks only on demand
  drm/radeon: raise UVD clocks on init v3
  drm/radeon: disable UVD advanced semaphore mode

Rafał Miłecki (6):
  drm/radeon: add helpers for masking and setting bits in regs
  drm/radeon/evergreen: setup HDMI before enabling it
  drm/radeon/evergreen: reorder HDMI setup
  drm/radeon/evergreen: write default channel numbers
  drm: add drm_edid_to_eld helper extracting SADs from EDID (v2)
  drm/radeon/evergreen: set SAD registers

 drivers/gpu/drm/drm_edid.c |   59 ++
 drivers/gpu/drm/radeon/atombios.h  |2 +
 drivers/gpu/drm/radeon/atombios_encoders.c |   17 +-
 drivers/gpu/drm/radeon/evergreen.c |  986 +++-
 drivers/gpu/drm/radeon/evergreen_hdmi.c|  169 +-
 drivers/gpu/drm/radeon/evergreen_reg.h |2 +
 drivers/gpu/drm/radeon/evergreend.h|1 +
 drivers/gpu/drm/radeon/ni.c|  281 
 drivers/gpu/drm/radeon/r100.c  |   77 ++-
 drivers/gpu/drm/radeon/r500_reg.h  |2 +
 drivers/gpu/drm/radeon/r600.c  |   34 +-
 drivers/gpu/drm/radeon/r600_audio.c|   64 +--
 drivers/gpu/drm/radeon/r600_hdmi.c |  150 ++---
 drivers/gpu/drm/radeon/r600d.h |7 +-
 drivers/gpu/drm/radeon/radeon.h|   17 +-
 drivers/gpu/drm/radeon/radeon_asic.c   |   18 +
 drivers/gpu/drm/radeon/radeon_asic.h   |5 +-
 drivers/gpu/drm/radeon/radeon_atombios.c   |6 +-
 drivers/gpu/drm/radeon/radeon_cs.c |4 +
 drivers/gpu/drm/radeon/radeon_device.c |   36 +
 drivers/gpu/drm/radeon/radeon_fence.c  |7 +-
 drivers/gpu/drm/radeon/radeon_uvd.c|   58 ++-
 drivers/gpu/drm/radeon/rs600.c |   52 ++-
 drivers/gpu/drm/radeon/rv515.c |   54 ++
 drivers/gpu/drm/radeon/rv770.c |  672 +++-
 drivers/gpu/drm/radeon/si.c|  817 +++-
 include/drm/drm_edid.h |9 +
 27 files changed, 3332 insertions(+), 274 deletions(-)
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 63730] UVD broken on HD5470 by "drm/radeon: raise UVD clocks only on demand"

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=63730

Christian K?nig  changed:

   What|Removed |Added

  Attachment #78357|0   |1
is obsolete||

--- Comment #15 from Christian K?nig  ---
Created attachment 78377
  --> https://bugs.freedesktop.org/attachment.cgi?id=78377&action=edit
Possible fix

This one should do it, the problems indeed seems to be that the VCPU on
evergreen doesn't work with the lower clocks.

Please test.

-- 
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/20130423/2edd40cf/attachment.html>

[Bug 63730] UVD broken on HD5470 by "drm/radeon: raise UVD clocks only on demand"

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=63730

--- Comment #14 from Johannes Hirte  ---
(In reply to comment #13)
> I don't think that crashing X is related to a not working UVD ring, at least
> it shouldn't.

I can only say what I'm observing. with this patch X crashes as soon as I start
chromium. Without it doesn't.

> Anyway, I've got a good news: I was able to reproduce the problem with a
> HD5670, so a final patch fixing this is on the way.

Sounds good, I'm waiting for testing.

-- 
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/20130423/879fee6d/attachment-0001.html>

[Bug 63632] mesa +r600 llvm = segfault

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=63632

--- Comment #7 from Tom Stellard  ---
(In reply to comment #4)
> (In reply to comment #3)
> > (In reply to comment #2)
> > > I can't reproduce this with LLVM r179895 and Mesa
> > > 12eab7cc564a6928197f9b87ded9e368e56976f0
> > > 
> > > Have you done full rebuilds of both projects?
> > 
> > Yes, I always do make [dist]clean and git clean -dfx.
> > 
> > I have just deleted both trees and re-cloned to be sure, but the segfault is
> > still there.
> > 
> > When I was on my working commits moving either llvm or mesa to head while
> > keeping the other on "working" produced the segfault (which is why I didn't
> > do a proper bisect).
> > 
> > I always clean and rebuild mesa after llvm has changed.
> 
> I was able to reproduce this on my gentoo system, but not on either of my
> fedora systems.  I will investigate further, what distro are you using?

The problem on my gentoo system was that I had removed --enable-shared from my
llvm configure script a few days ago, so I was still linking with an older
LLVM.

Can you check that you are passing --enable-shared when configuring LLVM?

-- 
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/20130423/a2390def/attachment.html>

[PATCH] drm/exynos: added ipp device registration to drm driver

[Seung-Woo Kim]

This patch added exynos-drm-ipp platform device registration to the exynos drm
driver. When DT is enabled, platform devices need to be registered within the
driver code. This patch fits the requirement of both DT and Non DT based drm
drivers.

Signed-off-by: Seung-Woo Kim 
Signed-off-by: Donghwa Lee 
---
 drivers/gpu/drm/exynos/exynos_drm_drv.c |7 +++
 drivers/gpu/drm/exynos/exynos_drm_drv.h |   10 ++
 drivers/gpu/drm/exynos/exynos_drm_ipp.c |   27 +++
 3 files changed, 44 insertions(+), 0 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.c 
b/drivers/gpu/drm/exynos/exynos_drm_drv.c
index 3da5c2d..4ef6fa0 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_drv.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_drv.c
@@ -380,6 +380,10 @@ static int __init exynos_drm_init(void)
ret = platform_driver_register(&ipp_driver);
if (ret < 0)
goto out_ipp;
+
+   ret = exynos_platform_device_ipp_register();
+   if (ret < 0)
+   goto out_ipp_dev;
 #endif

ret = platform_driver_register(&exynos_drm_platform_driver);
@@ -400,6 +404,8 @@ out:

 out_drm:
 #ifdef CONFIG_DRM_EXYNOS_IPP
+   exynos_platform_device_ipp_unregister();
+out_ipp_dev:
platform_driver_unregister(&ipp_driver);
 out_ipp:
 #endif
@@ -456,6 +462,7 @@ static void __exit exynos_drm_exit(void)
platform_driver_unregister(&exynos_drm_platform_driver);

 #ifdef CONFIG_DRM_EXYNOS_IPP
+   exynos_platform_device_ipp_unregister();
platform_driver_unregister(&ipp_driver);
 #endif

diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.h 
b/drivers/gpu/drm/exynos/exynos_drm_drv.h
index 4606fac..b09ee2e 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_drv.h
+++ b/drivers/gpu/drm/exynos/exynos_drm_drv.h
@@ -329,6 +329,16 @@ extern int exynos_platform_device_hdmi_register(void);
  */
 void exynos_platform_device_hdmi_unregister(void);

+/*
+ * this function registers exynos drm ipp platform device.
+ */
+int exynos_platform_device_ipp_register(void);
+
+/*
+ * this function unregisters exynos drm ipp platform device if it exists.
+ */
+void exynos_platform_device_ipp_unregister(void);
+
 extern struct platform_driver fimd_driver;
 extern struct platform_driver hdmi_driver;
 extern struct platform_driver mixer_driver;
diff --git a/drivers/gpu/drm/exynos/exynos_drm_ipp.c 
b/drivers/gpu/drm/exynos/exynos_drm_ipp.c
index 1adce07..29d2ad3 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_ipp.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_ipp.c
@@ -47,6 +47,9 @@
 #define get_ipp_context(dev)   platform_get_drvdata(to_platform_device(dev))
 #define ipp_is_m2m_cmd(c)  (c == IPP_CMD_M2M)

+/* platform device pointer for ipp device. */
+static struct platform_device *exynos_drm_ipp_pdev;
+
 /*
  * A structure of event.
  *
@@ -102,6 +105,30 @@ static LIST_HEAD(exynos_drm_ippdrv_list);
 static DEFINE_MUTEX(exynos_drm_ippdrv_lock);
 static BLOCKING_NOTIFIER_HEAD(exynos_drm_ippnb_list);

+int exynos_platform_device_ipp_register(void)
+{
+   struct platform_device *pdev;
+
+   if (exynos_drm_ipp_pdev)
+   return -EEXIST;
+
+   pdev = platform_device_register_simple("exynos-drm-ipp", -1, NULL, 0);
+   if (IS_ERR(pdev))
+   return PTR_ERR(pdev);
+
+   exynos_drm_ipp_pdev = pdev;
+
+   return 0;
+}
+
+void exynos_platform_device_ipp_unregister(void)
+{
+   if (exynos_drm_ipp_pdev) {
+   platform_device_unregister(exynos_drm_ipp_pdev);
+   exynos_drm_ipp_pdev = NULL;
+   }
+}
+
 int exynos_drm_ippdrv_register(struct exynos_drm_ippdrv *ippdrv)
 {
DRM_DEBUG_KMS("%s\n", __func__);
-- 
1.7.4.1

[PATCH v3 3/3] drm/exynos: add device tree support for fimc ipp driver

[Sylwester Nawrocki]

This patch adds OF initialization support for the FIMC driver.
The binding documentation can be found at Documentation/devicetree/
bindings/media/samsung-fimc.txt.

The syscon regmap interface is used to serialize access to the
shared CAMBLK registers from within the V4L2 FIMC-IS and the DRM
FIMC drivers. The DRM driver uses this interface for setting up
the FIFO data link between FIMD and FIMC IP blocks, while the V4L2
one for setting up a data link between the camera ISP and FIMC for
camera capture. The CAMBLK registers are not accessed any more
through a statically mapped IO. Synchronized access to these
registers is required for simultaneous operation of the camera
ISP and the DRM IPP on Exynos4x12.

The driver data and driver_ids static data structures are removed
since Exynos4 is going to be a dt-only platform and there is
currently no board file in mainline that defines platform data
for the FIMC IPP, i.e. uses it.

Camera input signal polarities are not currently parsed from the
device tree.

Signed-off-by: Sylwester Nawrocki 
Signed-off-by: Kyungmin Park 
---
 drivers/gpu/drm/exynos/Kconfig   |2 +-
 drivers/gpu/drm/exynos/exynos_drm_fimc.c |  110 --
 drivers/gpu/drm/exynos/regs-fimc.h   |7 +-
 3 files changed, 62 insertions(+), 57 deletions(-)

diff --git a/drivers/gpu/drm/exynos/Kconfig b/drivers/gpu/drm/exynos/Kconfig
index 406f32a..5c4be2a 100644
--- a/drivers/gpu/drm/exynos/Kconfig
+++ b/drivers/gpu/drm/exynos/Kconfig
@@ -56,7 +56,7 @@ config DRM_EXYNOS_IPP

 config DRM_EXYNOS_FIMC
bool "Exynos DRM FIMC"
-   depends on DRM_EXYNOS_IPP
+   depends on DRM_EXYNOS_IPP && MFD_SYSCON && OF
help
  Choose this option if you want to use Exynos FIMC for DRM.

diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimc.c 
b/drivers/gpu/drm/exynos/exynos_drm_fimc.c
index 2cce97d..773f583 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_fimc.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_fimc.c
@@ -12,11 +12,12 @@
  *
  */
 #include 
+#include 
 #include 
 #include 
+#include 
 #include 
 #include 
-#include 

 #include 
 #include 
@@ -140,15 +141,6 @@ struct fimc_capability {
 };

 /*
- * A structure of fimc driver data.
- *
- * @parent_clk: name of parent clock.
- */
-struct fimc_driverdata {
-   char*parent_clk;
-};
-
-/*
  * A structure of fimc context.
  *
  * @ippdrv: prepare initialization using ippdrv.
@@ -157,6 +149,7 @@ struct fimc_driverdata {
  * @lock: locking of operations.
  * @clocks: fimc clocks.
  * @clk_frequency: LCLK clock frequency.
+ * @sysreg: handle to SYSREG block regmap.
  * @sc: scaler infomations.
  * @pol: porarity of writeback.
  * @id: fimc id.
@@ -170,8 +163,8 @@ struct fimc_context {
struct mutexlock;
struct clk  *clocks[FIMC_CLKS_MAX];
u32 clk_frequency;
+   struct regmap   *sysreg;
struct fimc_scaler  sc;
-   struct fimc_driverdata  *ddata;
struct exynos_drm_ipp_pol   pol;
int id;
int irq;
@@ -215,17 +208,13 @@ static void fimc_sw_reset(struct fimc_context *ctx)
fimc_write(0x0, EXYNOS_CIFCNTSEQ);
 }

-static void fimc_set_camblk_fimd0_wb(struct fimc_context *ctx)
+static int fimc_set_camblk_fimd0_wb(struct fimc_context *ctx)
 {
-   u32 camblk_cfg;
-
DRM_DEBUG_KMS("%s\n", __func__);

-   camblk_cfg = readl(SYSREG_CAMERA_BLK);
-   camblk_cfg &= ~(SYSREG_FIMD0WB_DEST_MASK);
-   camblk_cfg |= ctx->id << (SYSREG_FIMD0WB_DEST_SHIFT);
-
-   writel(camblk_cfg, SYSREG_CAMERA_BLK);
+   return regmap_update_bits(ctx->sysreg, SYSREG_CAMERA_BLK,
+ SYSREG_FIMD0WB_DEST_MASK,
+ ctx->id << SYSREG_FIMD0WB_DEST_SHIFT);
 }

 static void fimc_set_type_ctrl(struct fimc_context *ctx, enum fimc_wb wb)
@@ -1626,7 +1615,11 @@ static int fimc_ippdrv_start(struct device *dev, enum 
drm_exynos_ipp_cmd cmd)
fimc_handle_lastend(ctx, true);

/* setup FIMD */
-   fimc_set_camblk_fimd0_wb(ctx);
+   ret = fimc_set_camblk_fimd0_wb(ctx);
+   if (ret < 0) {
+   dev_err(dev, "camblk setup failed.\n");
+   return ret;
+   }

set_wb.enable = 1;
set_wb.refresh = property->refresh_rate;
@@ -1786,26 +1779,58 @@ e_clk_free:
return ret;
 }

+static int fimc_parse_dt(struct fimc_context *ctx)
+{
+   struct device_node *node = ctx->ippdrv.dev->of_node;
+
+   /* Handle only devices that support the LCD Writeback data path */
+   if (!of_property_read_bool(node, "samsung,lcd-wb"))
+   return -ENODEV;
+
+   if (of_property_read_u32(node, "clock-frequency",
+   &ctx->clk_frequency))
+   ctx->clk_frequency = FIMC_DEFAULT_LCLK_FREQUENCY;
+
+   ctx->id = of_alias_get_id(node, "fimc");
+
+   if (ctx->id < 0) {
+

[PATCH v3 2/3] drm/exynos: rework fimc clocks handling

[Sylwester Nawrocki]

The clocks handling is refactored and a "mux" clock handling is
added to account for changes in the clocks driver. After switching
to the common clock framework the sclk_fimc clock is now split
into two clocks: a gate and a mux clock. In order to retain the
exisiting functionality two additional consumer clocks are passed
to the driver from device tree: "mux" and "parent". Then the driver
sets "parent" clock as a parent clock of the "mux" clock. These two
additional clocks are optional, and should go away when there is a
standard way of setting up parent clocks on DT platforms.

Signed-off-by: Sylwester Nawrocki 
Signed-off-by: Kyungmin Park 
---
 drivers/gpu/drm/exynos/exynos_drm_fimc.c |  169 +-
 1 file changed, 99 insertions(+), 70 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimc.c 
b/drivers/gpu/drm/exynos/exynos_drm_fimc.c
index d812c57..2cce97d 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_fimc.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_fimc.c
@@ -76,6 +76,27 @@ enum fimc_wb {
FIMC_WB_B,
 };

+enum {
+   FIMC_CLK_LCLK,
+   FIMC_CLK_GATE,
+   FIMC_CLK_WB_A,
+   FIMC_CLK_WB_B,
+   FIMC_CLK_MUX,
+   FIMC_CLK_PARENT,
+   FIMC_CLKS_MAX
+};
+
+static const char * const fimc_clock_names[] = {
+   [FIMC_CLK_LCLK]   = "sclk_fimc",
+   [FIMC_CLK_GATE]   = "fimc",
+   [FIMC_CLK_WB_A]   = "pxl_async0",
+   [FIMC_CLK_WB_B]   = "pxl_async1",
+   [FIMC_CLK_MUX]= "mux",
+   [FIMC_CLK_PARENT] = "parent",
+};
+
+#define FIMC_DEFAULT_LCLK_FREQUENCY 13300UL
+
 /*
  * A structure of scaler.
  *
@@ -134,13 +155,9 @@ struct fimc_driverdata {
  * @regs_res: register resources.
  * @regs: memory mapped io registers.
  * @lock: locking of operations.
- * @sclk_fimc_clk: fimc source clock.
- * @fimc_clk: fimc clock.
- * @wb_clk: writeback a clock.
- * @wb_b_clk: writeback b clock.
+ * @clocks: fimc clocks.
+ * @clk_frequency: LCLK clock frequency.
  * @sc: scaler infomations.
- * @odr: ordering of YUV.
- * @ver: fimc version.
  * @pol: porarity of writeback.
  * @id: fimc id.
  * @irq: irq number.
@@ -151,10 +168,8 @@ struct fimc_context {
struct resource *regs_res;
void __iomem*regs;
struct mutexlock;
-   struct clk  *sclk_fimc_clk;
-   struct clk  *fimc_clk;
-   struct clk  *wb_clk;
-   struct clk  *wb_b_clk;
+   struct clk  *clocks[FIMC_CLKS_MAX];
+   u32 clk_frequency;
struct fimc_scaler  sc;
struct fimc_driverdata  *ddata;
struct exynos_drm_ipp_pol   pol;
@@ -1301,14 +1316,12 @@ static int fimc_clk_ctrl(struct fimc_context *ctx, bool 
enable)
DRM_DEBUG_KMS("%s:enable[%d]\n", __func__, enable);

if (enable) {
-   clk_enable(ctx->sclk_fimc_clk);
-   clk_enable(ctx->fimc_clk);
-   clk_enable(ctx->wb_clk);
+   clk_prepare_enable(ctx->clocks[FIMC_CLK_GATE]);
+   clk_prepare_enable(ctx->clocks[FIMC_CLK_WB_A]);
ctx->suspended = false;
} else {
-   clk_disable(ctx->sclk_fimc_clk);
-   clk_disable(ctx->fimc_clk);
-   clk_disable(ctx->wb_clk);
+   clk_disable_unprepare(ctx->clocks[FIMC_CLK_GATE]);
+   clk_disable_unprepare(ctx->clocks[FIMC_CLK_WB_A]);
ctx->suspended = true;
}

@@ -1713,11 +1726,70 @@ static void fimc_ippdrv_stop(struct device *dev, enum 
drm_exynos_ipp_cmd cmd)
fimc_write(cfg, EXYNOS_CIGCTRL);
 }

+static void fimc_put_clocks(struct fimc_context *ctx)
+{
+   int i;
+
+   for (i = 0; i < FIMC_CLKS_MAX; i++) {
+   if (IS_ERR(ctx->clocks[i]))
+   continue;
+   clk_put(ctx->clocks[i]);
+   ctx->clocks[i] = ERR_PTR(-EINVAL);
+   }
+}
+
+static int fimc_setup_clocks(struct fimc_context *ctx)
+{
+   struct device *fimc_dev = ctx->ippdrv.dev;
+   struct device *dev;
+   int ret, i;
+
+   for (i = 0; i < FIMC_CLKS_MAX; i++)
+   ctx->clocks[i] = ERR_PTR(-EINVAL);
+
+   for (i = 0; i < FIMC_CLKS_MAX; i++) {
+   if (i == FIMC_CLK_WB_A || i == FIMC_CLK_WB_B)
+   dev = fimc_dev->parent;
+   else
+   dev = fimc_dev;
+
+   ctx->clocks[i] = clk_get(dev, fimc_clock_names[i]);
+   if (IS_ERR(ctx->clocks[i])) {
+   if (i >= FIMC_CLK_MUX)
+   break;
+   ret = PTR_ERR(ctx->clocks[i]);
+   dev_err(fimc_dev, "failed to get clock: %s\n",
+   fimc_clock_names[i]);
+   goto e_clk_free;
+   }
+   }
+
+   /* Optional FIMC LCLK parent clock setting */
+   if (!IS_ERR(ctx->clocks[FIMC_CLK_PARENT])) {
+   ret = clk_set_parent(ctx->clocks[FIMC_CLK_MUX],
+   

[PATCH v3 1/3] drm/exynos: remove redundant devm_kfree()

[Sylwester Nawrocki]

There is no need for explicit calls of devm_kfree(), as
the allocated memory will be freed during driver's detach.
Remove the redundant devm_kfree() calls from probe() and
remove() callbacks.

Signed-off-by: Sylwester Nawrocki 
Signed-off-by: Kyungmin Park 
---
 drivers/gpu/drm/exynos/exynos_drm_fimc.c |2 --
 1 file changed, 2 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimc.c 
b/drivers/gpu/drm/exynos/exynos_drm_fimc.c
index 411f69b7..d812c57 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_fimc.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_fimc.c
@@ -1843,7 +1843,6 @@ static int fimc_probe(struct platform_device *pdev)
return 0;

 err_ippdrv_register:
-   devm_kfree(dev, ippdrv->prop_list);
pm_runtime_disable(dev);
 err_get_irq:
free_irq(ctx->irq, ctx);
@@ -1857,7 +1856,6 @@ static int fimc_remove(struct platform_device *pdev)
struct fimc_context *ctx = get_fimc_context(dev);
struct exynos_drm_ippdrv *ippdrv = &ctx->ippdrv;

-   devm_kfree(dev, ippdrv->prop_list);
exynos_drm_ippdrv_unregister(ippdrv);
mutex_destroy(&ctx->lock);

-- 
1.7.9.5

[PATCH v3 0/3] drm/exynos: Add device tree support for IPP driver

[Sylwester Nawrocki]

Hi,

This small patch series adds device tree support for the DRM FIMC driver.
The binding documentation can be found in -next at Documentation/devicetree/
bindings/media/samsung-fimc.txt.

Changes since v2:
 - dropped addition of 'dev' field to struct fimc_context,
 - added more error logs and comments,
 - fixed error paths in fimc_setup_clocks() function.

Changes since v1:
 - removed devm_kfree() that got erroneously re-added in patch 2/3 during
   rebase.

Thanks,
Sylwester

Sylwester Nawrocki (3):
  drm/exynos: remove redundant devm_kfree()
  drm/exynos: rework fimc clocks handling
  drm/exynos: add device tree support for fimc ipp driver

 drivers/gpu/drm/exynos/Kconfig   |2 +-
 drivers/gpu/drm/exynos/exynos_drm_fimc.c |  273 +-
 drivers/gpu/drm/exynos/regs-fimc.h   |7 +-
 3 files changed, 157 insertions(+), 125 deletions(-)

--
1.7.9.5

Re: abuse of dumb ioctls in exynos

[Dave Airlie]

>
> Having a flag to indicate a dumb buffer allocation is to be used as a
> scan-out buffer would be useful for xf86-video-armsoc. We're trying to
> keep that driver as generic as possible and currently the main device-
> specific bits are what flags to pass to DRM_IOCTL_MODE_CREATE_DUMB for
> scanout & non-scanout buffer allocations. If a generic scanout flag could
> be added, it would simplify armsoc a fair bit and also allow the DRM
> drivers we're using armsoc with to comply with the don't pass device-
> specific flags to create dumb.
>
> For reference, the device-specific bits of armsoc are currently abstracted
> here:
>
> Note: We are still using DRM_IOCTL_MODE_CREATE_DUMB to allocate pixmap
> and DRI2 buffers and have not come across any issues with doing that.
> Certainly both Mali-400 & Mali-T6xx render to linear RGBA buffers and
> the display controller's in SoCs shipping Mali also seem to happily
> scan-out linear RGB buffers. Getting armsoc to run on OMAP (again) might
> need a device-specific allocation function to allocate the tiled format
> used on OMAP, but only for efficient 90-degree rotations (if I understood
> Rob correctly). So maybe we could also one day add a "this buffer will be
> rotated 90 degrees" flag?

What part of don't use dumb buffer for acceleration is hard to understand?

Christ I called them DUMB. Lets try this again.

DON'T USE DUMB BUFFERS FOR ALLOCATING BUFFERS USED FOR ACCELERATION.

Now that we've cleared that up, armsoc is a big bag of shit, I've
spent a few hours on it in the last few weeks trying to get anything
to run on my chromebook and really armsoc needs to be put out of its
misery.

The only working long term strategy for ARM I see is to abstract the
common modesetting code into a new library, and write a per-GPU
driver.

What you are doing now is madness and needs to stop.

Dave.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 63632] mesa +r600 llvm = segfault

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=63632

--- Comment #12 from Andy Furniss  ---
(In reply to comment #11)
> (In reply to comment #10)
> > (In reply to comment #8)
> > > (In reply to comment #7)
> > > 
> > > > The problem on my gentoo system was that I had removed --enable-shared 
> > > > from
> > > > my llvm configure script a few days ago, so I was still linking with an
> > > > older LLVM.
> > > > 
> > > > Can you check that you are passing --enable-shared when configuring 
> > > > LLVM?
> > > 
> > > I wasn't, but passing it does not prevent the segfault - will look into
> > > libelf.
> > 
> > Is it the same segfault?  If the problem is libelf you will see a segfault
> > in radeon_llvm_emit.cpp.  Are building mesa with --enable-opencl or
> > --with-llvm-shared-libs ?
> 
> It is the same segfault as comment1.
> 
> I was building mesa with neither option.
> 
> Have just tried --with-llvm-shared-libs but get the same segfault.

Just tried with the two elf patches you posted to the list and the segfault is
fixed.

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

abuse of dumb ioctls in exynos

[Dave Airlie]

>
> Having a flag to indicate a dumb buffer allocation is to be used as a
> scan-out buffer would be useful for xf86-video-armsoc. We're trying to
> keep that driver as generic as possible and currently the main device-
> specific bits are what flags to pass to DRM_IOCTL_MODE_CREATE_DUMB for
> scanout & non-scanout buffer allocations. If a generic scanout flag could
> be added, it would simplify armsoc a fair bit and also allow the DRM
> drivers we're using armsoc with to comply with the don't pass device-
> specific flags to create dumb.
>
> For reference, the device-specific bits of armsoc are currently abstracted
> here:
>
> Note: We are still using DRM_IOCTL_MODE_CREATE_DUMB to allocate pixmap
> and DRI2 buffers and have not come across any issues with doing that.
> Certainly both Mali-400 & Mali-T6xx render to linear RGBA buffers and
> the display controller's in SoCs shipping Mali also seem to happily
> scan-out linear RGB buffers. Getting armsoc to run on OMAP (again) might
> need a device-specific allocation function to allocate the tiled format
> used on OMAP, but only for efficient 90-degree rotations (if I understood
> Rob correctly). So maybe we could also one day add a "this buffer will be
> rotated 90 degrees" flag?

What part of don't use dumb buffer for acceleration is hard to understand?

Christ I called them DUMB. Lets try this again.

DON'T USE DUMB BUFFERS FOR ALLOCATING BUFFERS USED FOR ACCELERATION.

Now that we've cleared that up, armsoc is a big bag of shit, I've
spent a few hours on it in the last few weeks trying to get anything
to run on my chromebook and really armsoc needs to be put out of its
misery.

The only working long term strategy for ARM I see is to abstract the
common modesetting code into a new library, and write a per-GPU
driver.

What you are doing now is madness and needs to stop.

Dave.

abuse of dumb ioctls in exynos

[Rob Clark]

On Tue, Apr 23, 2013 at 12:34 PM, Tom Cooksey  wrote:
>> It appears exynos is passing the generic flags from the dumb ioctls
>> straight into the the GEM creation code.
>>
>> The dumb flags are NOT driver specific, and are NOT to be used in this
>> fashion. Please remove this use of the flags from your driver.
>>
>> I was going to add one new flag to the interface for SCANOUT vs CURSOR
>> for some drivers.
>
> Having a flag to indicate a dumb buffer allocation is to be used as a
> scan-out buffer would be useful for xf86-video-armsoc. We're trying to
> keep that driver as generic as possible and currently the main device-
> specific bits are what flags to pass to DRM_IOCTL_MODE_CREATE_DUMB for
> scanout & non-scanout buffer allocations. If a generic scanout flag could
> be added, it would simplify armsoc a fair bit and also allow the DRM
> drivers we're using armsoc with to comply with the don't pass device-
> specific flags to create dumb.

well, by definition, *all* dumb buffers are scanout buffers ;-)

I don't really think directly using dumb buffers is such a great idea.
 It might more or less work on current drivers, but it really is a bit
of a misuse of the API.  I suppose one possibility would be to use
libkms, which will fallback to dumb scanout.  If some particular
platform needs something special, they could implement their own
libkms backend rather than using the dumb buffer fallback.

> For reference, the device-specific bits of armsoc are currently abstracted
> here:
>
> >
>
>
> Note: We are still using DRM_IOCTL_MODE_CREATE_DUMB to allocate pixmap
> and DRI2 buffers and have not come across any issues with doing that.
> Certainly both Mali-400 & Mali-T6xx render to linear RGBA buffers and
> the display controller's in SoCs shipping Mali also seem to happily
> scan-out linear RGB buffers. Getting armsoc to run on OMAP (again) might
> need a device-specific allocation function to allocate the tiled format
> used on OMAP, but only for efficient 90-degree rotations (if I understood
> Rob correctly). So maybe we could also one day add a "this buffer will be
> rotated 90 degrees" flag?

In omap ddx, it is a bit more complicated than that, since we do some
tricks to re-allocate the buffer if one or more of the crtcs is
rotated/mirrored.  (IIRC, that support might have been added after
your forked off of xf86-video-omap)

Ideal perfect DDX solution would, I think, look something like some
helpers for drmmode_display stuff, which a platform specific DDX could
choose to use all, part, or none of, depending on it's needs.  Whether
it makes sense to spend a lot of time on that, or instead spend the
effort on wayland, I'm not sure.  Living w/ some cut/paste code for a
year or two isn't such a big deal.

BR,
-R

>
> Cheers,
>
> Tom
>
> PS: I've stuck in a fd.o bugzilla ticket to move xf86-video-armsoc to
> freedesktop.org infrastructure, so hopefully it will live in a more
> appropriate place soon, not to mention have a mailing list, etc.!
>
>
>
>
>
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel

Radeon lockup on 3.8.5-201.fc18.x86_64

[Andy Lutomirski]

On Tue, Apr 23, 2013 at 10:15 AM, Michel D?nzer  wrote:
> On Die, 2013-04-23 at 10:08 -0700, Andy Lutomirski wrote:
>> On Mon, Apr 22, 2013 at 10:55 PM, Michel D?nzer  
>> wrote:
>> > On Mon, 2013-04-22 at 16:19 -0700, Andy Lutomirski wrote:
>> >
>> >> I'm not convinced there's an actual hang.  40 seconds is a long time,
>> >> and I've only ever seen this when clicking something, and when this
>> >> happens, the screen goes blank immediately (not after a 40 second
>> >> delay).
>> >
>> > Hmm, now that you mention this, I notice in your original report it
>> > claims that the CP stalled for 'more than 5102593msec', which is clearly
>> > bogus. Looks like something's wrong with the lockup detection.
>> > Did this start after a kernel update or something like that?
>>
>> It's recent.  It may have been when F18 switched from 3.7 to 3.8.
>
> Can you reproduce it with an upstream kernel? Can you bisect? I realize
> it'll probably take a long time, but unless someone has an idea which
> change might have introduced the problem...

Yuck.  I can try, but it takes days to reproduce this, so it will take
forever (and may end up with a wrong answer if I get lucky and don't
crash).

>
>
>> I think there are bugs in the lockup detection and in the lockup
>> recovery.  Firefox, in particular, is *really* slow afterwards.  Are
>> interrupts possibly getting dropped or misconfigured during the reset?
>
> Let's not get ahead of ourselves and focus on the lockup detection issue
> for now.

I don't understand the r600_gpu_check_soft_reset code, but could this
be the sequence of events that triggers it?

1. radeon_ring_is_lockup is called just as the very last command on
the ring completes, so last_rptr gets set to the rptr.
2. Nothing happens for a while (i.e. > lockup_timeout).  rptr doesn't change.
3. A very slightly slow operation starts.
4. radeon_ring_is_lockup gets called before that command completes.

radeon_ring_test_lockup will not detect a jiffies wrap-around (because
there wasn't one), rptr will equal last_rptr (because there hasn't
been any progress since last time), and the elapsed time will be
really long, because the function hasn't been called for a long time.
So a lockup gets detected, even though nothing's wrong.

There's a comment above radeon_ring_test_lockup that says:

 * A possible false positivie is if we get call after while and last_cp_rptr ==
 * the current CP rptr, even if it's unlikely it might happen. To avoid this
 * if the elapsed time since last call is bigger than 2 second than we return
 * false and update the tracking information. Due to this the caller must call
 * radeon_ring_test_lockup several time in less than 2sec for lockup
to be reported
 * the fencing code should be cautious about that.

but the corresponding code doesn't appear to exist anywhere.

Also, and unrelatedly, I revoke my comment about gmail issues being
fixed with hyperz off.  Gmail still draws incorrectly.  This may or
may not have anything to do with the radeon driver.

--Andy

[Bug 63632] mesa +r600 llvm = segfault

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=63632

--- Comment #11 from Andy Furniss  ---
(In reply to comment #10)
> (In reply to comment #8)
> > (In reply to comment #7)
> > 
> > > The problem on my gentoo system was that I had removed --enable-shared 
> > > from
> > > my llvm configure script a few days ago, so I was still linking with an
> > > older LLVM.
> > > 
> > > Can you check that you are passing --enable-shared when configuring LLVM?
> > 
> > I wasn't, but passing it does not prevent the segfault - will look into
> > libelf.
> 
> Is it the same segfault?  If the problem is libelf you will see a segfault
> in radeon_llvm_emit.cpp.  Are building mesa with --enable-opencl or
> --with-llvm-shared-libs ?

It is the same segfault as comment1.

I was building mesa with neither option.

Have just tried --with-llvm-shared-libs but get the same segfault.

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 63730] UVD broken on HD5470 by "drm/radeon: raise UVD clocks only on demand"

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=63730

--- Comment #16 from Johannes Hirte  ---
Looks good. System booted as expected, dmesg shows

[2.167883] radeon :01:00.0: WB enabled
[2.168038] radeon :01:00.0: fence driver on ring 0 use gpu addr
0x2c00 and cpu addr 0x88011a165c00
[2.168325] radeon :01:00.0: fence driver on ring 3 use gpu addr
0x2c0c and cpu addr 0x88011a165c0c
[2.168817] radeon :01:00.0: fence driver on ring 5 use gpu addr
0x0005c418 and cpu addr 0xc90001e9c418
[2.185378] [drm] ring test on 0 succeeded in 1 usecs
[2.185625] [drm] ring test on 3 succeeded in 1 usecs
[2.362042] [drm] ring test on 5 succeeded in 1 usecs
[2.362226] [drm] UVD initialized successfully.
[2.362489] [drm] ib test on ring 0 succeeded in 0 usecs
[2.362671] [drm] ib test on ring 3 succeeded in 0 usecs
[2.514356] [drm] ib test on ring 5 succeeded
[2.568759] [drm] radeon atom DIG backlight initialized
[2.568914] [drm] Radeon Display Connectors

and no errors, video playback with UVD (mplayer) works and no crashes with
chromium. Perhaps the crash with the last patch came from the flash plugin that
tried to use VDPAU/UVD? Anyhow, it works now. Feel free to add my tested-by.

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 63632] mesa +r600 llvm = segfault

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=63632

--- Comment #10 from Tom Stellard  ---
(In reply to comment #8)
> (In reply to comment #7)
> 
> > The problem on my gentoo system was that I had removed --enable-shared from
> > my llvm configure script a few days ago, so I was still linking with an
> > older LLVM.
> > 
> > Can you check that you are passing --enable-shared when configuring LLVM?
> 
> I wasn't, but passing it does not prevent the segfault - will look into
> libelf.

Is it the same segfault?  If the problem is libelf you will see a segfault in
radeon_llvm_emit.cpp.  Are building mesa with --enable-opencl or
--with-llvm-shared-libs ?

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 63730] UVD broken on HD5470 by "drm/radeon: raise UVD clocks only on demand"

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=63730

Christian K?nig  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED

--- Comment #13 from Christian K?nig  ---
I don't think that crashing X is related to a not working UVD ring, at least it
shouldn't.

Anyway, I've got a good news: I was able to reproduce the problem with a
HD5670, so a final patch fixing this is on the way.

-- 
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/20130423/856ea064/attachment.html>

[Bug 63632] mesa +r600 llvm = segfault

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=63632

--- Comment #9 from Andy Furniss  ---
(In reply to comment #6)
> Which version of libelf is used in each case? I was running into problems
> with the one from http://www.mr511.de/software/ but the one from Fedora's
> elfutils works fine. Tom told me on IRC the former requires an additional
> initialization step.

On my old 32bit setup - haven't got a clue, it was ages ago :-)

On the 64 bit build I have only recently installed as it became required for
llvm - I used the source from debian sid. Have now tried vanilla and with
debian diff, but still segfault.

Will look in to Fedora version.

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 63632] mesa +r600 llvm = segfault

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=63632

--- Comment #8 from Andy Furniss  ---
(In reply to comment #7)

> The problem on my gentoo system was that I had removed --enable-shared from
> my llvm configure script a few days ago, so I was still linking with an
> older LLVM.
> 
> Can you check that you are passing --enable-shared when configuring LLVM?

I wasn't, but passing it does not prevent the segfault - will look into libelf.

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: Disabling polling in drm_helper

[Daniel Vetter]

On Tue, Apr 23, 2013 at 8:47 PM, Mike Verstegen
 wrote:
>> -Original Message-
>> From: Daniel Vetter [mailto:daniel.vet...@ffwll.ch] On Behalf Of Daniel 
>> Vetter
>> On Tue, Apr 23, 2013 at 01:16:16AM +, Mike Verstegen wrote:
>> > I'm troubleshooting an interesting problem where the
>> > i915_hotplug_work_func is eating up a lot of time in a couple of
>> > kworker threads. The interesting part of the problem is that this only
>> > happens with one particular model of monitor which I haven't gotten to
>> > the bottom of yet. But that's not the problem I'm trying  to resolve.
>>
>> This should be fixed in latest drm-next. Can you please test that?
>>
> I'd be glad to test, but that may be a bit over my skill level.  How could I 
> help with testing drm-next?
> In my original message, I forgot to include that this is a Centos 6.4 system 
> with a 3.5.3 kernel.

Google a good howto for installing a kernel from source for your
distro (I suggest using something which creates a real rpm for easy
un-installing). Then check out the below howto for git:

http://blog.ffwll.ch/2012/05/git-for-bug-reporters.html

And use that to download&install the drm-next branch from
git://people.freedesktop.org/~airlied/linux

Cheers, Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 63730] UVD broken on HD5470 by "drm/radeon: raise UVD clocks only on demand"

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=63730

--- Comment #12 from Johannes Hirte  ---
It's related to the [PATCH] drm/radeon: raise UVD clocks while booting the VCPU
patch. With this applied, X crashes when starting chromium browser.

-- 
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/20130423/eaea0378/attachment.html>

[Bug 61182] r600g causes KWin crashes with kernel 3.8

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=61182

--- Comment #46 from boris64  ---
(In reply to comment #43)
> (In reply to comment #42)
> > As i said in comment 30 it's also a bug of kwin, kwin should not use msaa
> > visual for everything ...
> 
> I've pushed a patch to the stable branch in KDE that should fix this issue.

Could you post a link to that patch?
Thank you.

-- 
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/20130423/5ae76e03/attachment.html>

[Bug 63730] UVD broken on HD5470 by "drm/radeon: raise UVD clocks only on demand"

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=63730

--- Comment #11 from Michel D?nzer  ---
(In reply to comment #10)
> Caught signal 7 (Bus error). Server aborting

Could be bug 61182.

-- 
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/20130423/b72ba832/attachment-0001.html>

[Bug 63730] UVD broken on HD5470 by "drm/radeon: raise UVD clocks only on demand"

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=63730

--- Comment #10 from Johannes Hirte  ---
And I've had a X crash now. The output is from kdm.log since Xorg.log was
already overwritten:

(EE) 
(EE) Backtrace:
(EE) 0: /usr/bin/X (xorg_backtrace+0x3d) [0x59ed1d]
(EE) 1: /usr/bin/X (0x40+0x1a3409) [0x5a3409]
(EE) 2: /lib64/libpthread.so.0 (0x7f43cdf07000+0x10ed0) [0x7f43cdf17ed0]
(EE) 3: /lib64/libc.so.6 (0x7f43cd20c000+0x907bb) [0x7f43cd29c7bb]
(EE) 4: /usr/lib64/xorg/modules/drivers/radeon_drv.so (0x7f43ca808000+0x3e436)
[0x7f43ca846436]
(EE) 5: /usr/lib64/xorg/modules/libexa.so (0x7f43cea5a000+0x970c)
[0x7f43cea6370c]
(EE) 6: /usr/bin/X (0x40+0xdd521) [0x4dd521]
(EE) 7: /usr/bin/X (0x40+0xde2e5) [0x4de2e5]
(EE) 8: /usr/bin/X (0x40+0x3587f) [0x43587f]
(EE) 9: /usr/bin/X (0x40+0x23fed) [0x423fed]
(EE) 10: /lib64/libc.so.6 (__libc_start_main+0xf5) [0x7f43cd230c15]
(EE) 11: /usr/bin/X (0x40+0x23b09) [0x423b09]
(EE) 
(EE) Bus error at address 0x7f43bddca000

Fatal server error:
Caught signal 7 (Bus error). Server aborting

(EE) 
Please consult the The X.Org Foundation support 
 at http://wiki.x.org
 for help. 
(EE) Please also check the log file at "/var/log/Xorg.0.log" for additional
information.
(EE)

Don't know if this is related to the UVD problem.

-- 
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/20130423/0584ec54/attachment.html>

[Bug 63732] [KDE] - display switching problem with kwin_gles and radeon driver.

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=63732

--- Comment #5 from Michel D?nzer  ---
(In reply to comment #2)
> I must say that I don't have any problem with kwin (but kwin is too slow for
> me).

FWIW, there is no inherent reason why kwin using full OpenGL should be slower
than kwin_gles, but there is a kwin bug where it uses MSAA when it shouldn't.
Supposedly that's fixed in current current kwin snapshots.

-- 
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/20130423/43a48101/attachment.html>

[Bug 61182] r600g causes KWin crashes with kernel 3.8

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=61182

--- Comment #47 from Fredrik Höglund  ---
(In reply to comment #46)
> (In reply to comment #43)
> > I've pushed a patch to the stable branch in KDE that should fix this issue.
> 
> Could you post a link to that patch?

http://quickgit.kde.org/?p=kde-workspace.git&a=commit&h=a021eacf

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 63709] Desktop Effects on 3D desktop environments are jerky/stutter.

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=63709

--- Comment #5 from Michel D?nzer  ---
The KDE problem could be kwin using MSAA when it shouldn't. This is supposedly
fixed in current versions of kwin.

At least some of the other issues you're describing will be hard to eliminate
completely without (something like) Wayland.

-- 
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/20130423/779503b5/attachment.html>

[Bug 63730] UVD broken on HD5470 by "drm/radeon: raise UVD clocks only on demand"

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=63730

--- Comment #9 from Johannes Hirte  ---
with the latest patch I get the following output:

[2.137767] Linux agpgart interface v0.103
[2.138046] [drm] Initialized drm 1.1.0 20060810
[2.138309] [drm] radeon kernel modesetting enabled.
[2.138962] [drm] initializing kernel modesetting (CEDAR 0x1002:0x68E0
0x1025:0x0489).
[2.139136] [drm] register mmio base: 0xF210
[2.139284] [drm] register mmio size: 131072
[2.144757] ATOM BIOS: Acer
[2.145053] radeon :01:00.0: VRAM: 512M 0x -
0x1FFF (512M used)
[2.145343] radeon :01:00.0: GTT: 512M 0x2000 -
0x3FFF
[2.145722] [drm] Detected VRAM RAM=512M, BAR=256M
[2.145897] [drm] RAM width 64bits DDR
[2.146136] [TTM] Zone  kernel: Available graphics memory: 2022516 kiB
[2.146285] [TTM] Initializing pool allocator
[2.146436] [TTM] Initializing DMA pool allocator
[2.146621] [drm] radeon: 512M of VRAM memory ready
[2.146785] [drm] radeon: 512M of GTT memory ready.
[2.146949] [drm] Supports vblank timestamp caching Rev 1 (10.10.2010).
[2.149945] [drm] Driver supports precise vblank timestamp query.
[2.150136] radeon :01:00.0: irq 43 for MSI/MSI-X
[2.150147] radeon :01:00.0: radeon: using MSI.
[2.150325] [drm] radeon: irq initialized.
[2.152070] [drm] GART: num cpu pages 131072, num gpu pages 131072
[2.153407] [drm] probing gen 2 caps for device 1022:9603 = 300d02/0
[2.153596] [drm] enabling PCIE gen 2 link speeds, disable with
radeon.pcie_gen2=0
[2.153909] [drm] Loading CEDAR Microcode
[2.168856] [drm] PCIE GART of 512M enabled (table at 0x0025D000).
[2.169128] radeon :01:00.0: WB enabled
[2.169283] radeon :01:00.0: fence driver on ring 0 use gpu addr
0x2c00 and cpu addr 0x88011a174c00
[2.169570] radeon :01:00.0: fence driver on ring 3 use gpu addr
0x2c0c and cpu addr 0x88011a174c0c
[2.170039] radeon :01:00.0: fence driver on ring 5 use gpu addr
0x0005c418 and cpu addr 0xc90001e9c418
[2.186632] [drm] ring test on 0 succeeded in 1 usecs
[2.186878] [drm] ring test on 3 succeeded in 1 usecs
[2.363300] [drm] ring test on 5 succeeded in 1 usecs
[2.363484] [drm] UVD initialized successfully.
[2.363745] [drm] ib test on ring 0 succeeded in 0 usecs
[2.363927] [drm] ib test on ring 3 succeeded in 0 usecs
[2.744243] ACPI: Deprecated procfs I/F for battery is loaded, please retry
with CONFIG_ACPI_PROCFS_POWER cleared
[2.744539] ACPI: Battery Slot [BAT1] (battery present)
[3.046208] tsc: Refined TSC clocksource calibration: 2094.754 MHz
[3.046364] Switching to clocksource tsc
[   12.648332] radeon :01:00.0: GPU lockup CP stall for more than 1msec
[   12.648493] radeon :01:00.0: GPU lockup (waiting for 0x0002
last fence id 0x)
[   12.648781] [drm:r600_uvd_ib_test] *ERROR* radeon: fence wait failed (-35).
[   12.648932] [drm:radeon_ib_ring_tests] *ERROR* radeon: failed testing IB on
ring 5 (-35).
[   12.703326] [drm] radeon atom DIG backlight initialized
[   12.703481] [drm] Radeon Display Connectors
[   12.703630] [drm] Connector 0:
[   12.703777] [drm]   LVDS-1
[   12.703925] [drm]   DDC: 0x6560 0x6560 0x6564 0x6564 0x6568 0x6568 0x656c
0x656c
[   12.704074] [drm]   Encoders:
[   12.704221] [drm] LCD1: INTERNAL_UNIPHY
[   12.704374] [drm] Connector 1:
[   12.704522] [drm]   HDMI-A-1
[   12.704668] [drm]   HPD1
[   12.704815] [drm]   DDC: 0x6430 0x6430 0x6434 0x6434 0x6438 0x6438 0x643c
0x643c
[   12.704964] [drm]   Encoders:
[   12.705111] [drm] DFP1: INTERNAL_UNIPHY1
[   12.705260] [drm] Connector 2:
[   12.705408] [drm]   VGA-1
[   12.70] [drm]   DDC: 0x6460 0x6460 0x6464 0x6464 0x6468 0x6468 0x646c
0x646c
[   12.705703] [drm]   Encoders:
[   12.705851] [drm] CRT1: INTERNAL_KLDSCP_DAC1
[   12.706045] [drm] Internal thermal controller with fan control
[   12.706343] [drm] radeon: power management initialized
[   13.091252] [drm] fb mappable at 0xE0361000
[   13.091443] [drm] vram apper at 0xE000
[   13.091591] [drm] size 4325376
[   13.091738] [drm] fb depth is 24
[   13.091885] [drm]pitch is 5632
[   13.092233] fbcon: radeondrmfb (fb0) is primary device
[   13.685775] Console: switching to colour frame buffer device 170x48
[   13.690367] radeon :01:00.0: fb0: radeondrmfb frame buffer device
[   13.690403] radeon :01:00.0: registered panic notifier
[   13.690556] [drm] Initialized radeon 2.33.0 20080528 for :01:00.0 on
minor 0

-- 
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/20130423/26cecd69/attachment.html>

Re: Radeon lockup on 3.8.5-201.fc18.x86_64

[Michel Dänzer]

On Die, 2013-04-23 at 10:08 -0700, Andy Lutomirski wrote: 
> On Mon, Apr 22, 2013 at 10:55 PM, Michel Dänzer  wrote:
> > On Mon, 2013-04-22 at 16:19 -0700, Andy Lutomirski wrote:
> >
> >> I'm not convinced there's an actual hang.  40 seconds is a long time,
> >> and I've only ever seen this when clicking something, and when this
> >> happens, the screen goes blank immediately (not after a 40 second
> >> delay).
> >
> > Hmm, now that you mention this, I notice in your original report it
> > claims that the CP stalled for 'more than 5102593msec', which is clearly
> > bogus. Looks like something's wrong with the lockup detection.
> > Did this start after a kernel update or something like that?
> 
> It's recent.  It may have been when F18 switched from 3.7 to 3.8.

Can you reproduce it with an upstream kernel? Can you bisect? I realize
it'll probably take a long time, but unless someone has an idea which
change might have introduced the problem...


> I think there are bugs in the lockup detection and in the lockup
> recovery.  Firefox, in particular, is *really* slow afterwards.  Are
> interrupts possibly getting dropped or misconfigured during the reset?

Let's not get ahead of ourselves and focus on the lockup detection issue
for now.


-- 
Earthling Michel Dänzer   |   http://www.amd.com
Libre software enthusiast |  Debian, X and DRI developer
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: abuse of dumb ioctls in exynos

[Rob Clark]

On Tue, Apr 23, 2013 at 12:34 PM, Tom Cooksey  wrote:
>> It appears exynos is passing the generic flags from the dumb ioctls
>> straight into the the GEM creation code.
>>
>> The dumb flags are NOT driver specific, and are NOT to be used in this
>> fashion. Please remove this use of the flags from your driver.
>>
>> I was going to add one new flag to the interface for SCANOUT vs CURSOR
>> for some drivers.
>
> Having a flag to indicate a dumb buffer allocation is to be used as a
> scan-out buffer would be useful for xf86-video-armsoc. We're trying to
> keep that driver as generic as possible and currently the main device-
> specific bits are what flags to pass to DRM_IOCTL_MODE_CREATE_DUMB for
> scanout & non-scanout buffer allocations. If a generic scanout flag could
> be added, it would simplify armsoc a fair bit and also allow the DRM
> drivers we're using armsoc with to comply with the don't pass device-
> specific flags to create dumb.

well, by definition, *all* dumb buffers are scanout buffers ;-)

I don't really think directly using dumb buffers is such a great idea.
 It might more or less work on current drivers, but it really is a bit
of a misuse of the API.  I suppose one possibility would be to use
libkms, which will fallback to dumb scanout.  If some particular
platform needs something special, they could implement their own
libkms backend rather than using the dumb buffer fallback.

> For reference, the device-specific bits of armsoc are currently abstracted
> here:
>
> >
>
>
> Note: We are still using DRM_IOCTL_MODE_CREATE_DUMB to allocate pixmap
> and DRI2 buffers and have not come across any issues with doing that.
> Certainly both Mali-400 & Mali-T6xx render to linear RGBA buffers and
> the display controller's in SoCs shipping Mali also seem to happily
> scan-out linear RGB buffers. Getting armsoc to run on OMAP (again) might
> need a device-specific allocation function to allocate the tiled format
> used on OMAP, but only for efficient 90-degree rotations (if I understood
> Rob correctly). So maybe we could also one day add a "this buffer will be
> rotated 90 degrees" flag?

In omap ddx, it is a bit more complicated than that, since we do some
tricks to re-allocate the buffer if one or more of the crtcs is
rotated/mirrored.  (IIRC, that support might have been added after
your forked off of xf86-video-omap)

Ideal perfect DDX solution would, I think, look something like some
helpers for drmmode_display stuff, which a platform specific DDX could
choose to use all, part, or none of, depending on it's needs.  Whether
it makes sense to spend a lot of time on that, or instead spend the
effort on wayland, I'm not sure.  Living w/ some cut/paste code for a
year or two isn't such a big deal.

BR,
-R

>
> Cheers,
>
> Tom
>
> PS: I've stuck in a fd.o bugzilla ticket to move xf86-video-armsoc to
> freedesktop.org infrastructure, so hopefully it will live in a more
> appropriate place soon, not to mention have a mailing list, etc.!
>
>
>
>
>
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Radeon lockup on 3.8.5-201.fc18.x86_64

[Andy Lutomirski]

On Mon, Apr 22, 2013 at 10:55 PM, Michel D?nzer  wrote:
> On Mon, 2013-04-22 at 16:19 -0700, Andy Lutomirski wrote:
>> On Thu, Apr 18, 2013 at 2:12 PM, Alex Deucher  
>> wrote:
>> > On Thu, Apr 18, 2013 at 5:11 PM, Andy Lutomirski  
>> > wrote:
>> >> On Mon, Apr 8, 2013 at 7:01 AM, Alex Deucher  
>> >> wrote:
>> >>> On Fri, Apr 5, 2013 at 5:11 PM, Andy Lutomirski  
>> >>> wrote:
>>  Every day or so, I'll click something and my screens go blank for a
>>  second or two.  dmesg complains about a lockup, and afterwards
>>  everything is painfully slow.  (Even switching focus to other emacs
>>  windows takes a second or two.)  Once this happens, if I restart X, I
>>  get a blank screen, although the mouse still works and I can switch
>>  VTs and use the console.
>> >>>
>> >>> Try disabling hyperZ.  Set env var R600_HYPERZ=0 (mesa 9.1) or
>> >>> R600_DEBUG=nohyperz (mesa git).
>> >>
>> >> It lasted longer.  I have both of those environment variables set on
>> >> the Xorg process but not on clients.  Do  I need it everywhere?
>> >
>> > For anything that uses the 3D driver.
>>
>> This didn't appear to fix it, although it may have fixed some
>> graphical glitches in gmail's compose window.
>
> Seems rather unlikely that's directly related to HyperZ, but who knows.
>
>
>> [350788.530966] radeon :08:00.0: GPU lockup CP stall for more than 
>> 40769msec
>> [350788.530970] radeon :08:00.0: GPU lockup (waiting for
>> 0x178f last fence id 0x178e)
>> [350788.532047] radeon :08:00.0: Saved 103 dwords of commands on ring 0.
>> [350788.532051] radeon :08:00.0: GPU softreset: 0x0003
>> [350788.547792] radeon :08:00.0:   GRBM_STATUS   = 0xA0003828
>> [350788.547794] radeon :08:00.0:   GRBM_STATUS_SE0   = 0x0007
>> [350788.547797] radeon :08:00.0:   GRBM_STATUS_SE1   = 0x0007
>> [350788.547799] radeon :08:00.0:   SRBM_STATUS   = 0x20C0
>> [350788.547802] radeon :08:00.0:   R_008674_CP_STALLED_STAT1 = 0x
>> [350788.547805] radeon :08:00.0:   R_008678_CP_STALLED_STAT2 = 0x
>> [350788.547807] radeon :08:00.0:   R_00867C_CP_BUSY_STAT = 0x0004
>> [350788.547810] radeon :08:00.0:   R_008680_CP_STAT  = 0x80008647
>> [350788.547811] radeon :08:00.0:   GRBM_SOFT_RESET=0x7F6B
>> [350788.547866] radeon :08:00.0:   GRBM_STATUS   = 0x3828
>> [350788.547869] radeon :08:00.0:   GRBM_STATUS_SE0   = 0x0007
>> [350788.547872] radeon :08:00.0:   GRBM_STATUS_SE1   = 0x0007
>> [350788.547874] radeon :08:00.0:   SRBM_STATUS   = 0x20C0
>> [350788.547877] radeon :08:00.0:   R_008674_CP_STALLED_STAT1 = 0x
>> [350788.547879] radeon :08:00.0:   R_008678_CP_STALLED_STAT2 = 0x
>> [350788.547882] radeon :08:00.0:   R_00867C_CP_BUSY_STAT = 0x
>> [350788.547884] radeon :08:00.0:   R_008680_CP_STAT  = 0x
>> [350788.565361] radeon :08:00.0: GPU reset succeeded, trying to resume
>> [350788.583801] [drm] probing gen 2 caps for device 8086:1d1a = 2/0
>> [350788.583807] [drm] enabling PCIE gen 2 link speeds, disable with
>> radeon.pcie_gen2=0
>> [350788.590840] [drm] PCIE GART of 512M enabled (table at 
>> 0x0004).
>> [350788.590976] radeon :08:00.0: WB enabled
>> [350788.590978] radeon :08:00.0: fence driver on ring 0 use gpu
>> addr 0x4c00 and cpu addr 0x880442f58c00
>> [350788.590979] radeon :08:00.0: fence driver on ring 3 use gpu
>> addr 0x4c0c and cpu addr 0x880442f58c0c
>> [350788.607480] [drm] ring test on 0 succeeded in 2 usecs
>> [350788.607560] [drm] ring test on 3 succeeded in 1 usecs
>> [350788.615053] [drm] ib test on ring 0 succeeded in 0 usecs
>> [350788.615133] [drm] ib test on ring 3 succeeded in 1 usecs
>>
>> I'm not convinced there's an actual hang.  40 seconds is a long time,
>> and I've only ever seen this when clicking something, and when this
>> happens, the screen goes blank immediately (not after a 40 second
>> delay).
>
> Hmm, now that you mention this, I notice in your original report it
> claims that the CP stalled for 'more than 5102593msec', which is clearly
> bogus. Looks like something's wrong with the lockup detection.
> Did this start after a kernel update or something like that?

It's recent.  It may have been when F18 switched from 3.7 to 3.8.

I think there are bugs in the lockup detection and in the lockup
recovery.  Firefox, in particular, is *really* slow afterwards.  Are
interrupts possibly getting dropped or misconfigured during the reset?

--Andy

Disabling polling in drm_helper

[Daniel Vetter]

On Tue, Apr 23, 2013 at 01:16:16AM +, Mike Verstegen wrote:
> I'm troubleshooting an interesting problem where the
> i915_hotplug_work_func is eating up a lot of time in a couple of kworker
> threads. The interesting part of the problem is that this only happens
> with one particular model of monitor which I haven't gotten to the
> bottom of yet. But that's not the problem I'm trying  to resolve. 

This should be fixed in latest drm-next. Can you please test that?

> One band-aid for this trouble is to disable the polling in the irq_event
> # echo "N" > /sys/module/drm_kms_helper/parameters/poll
> 
> That quiets down the kworker threads. Good
> 
> To make this survive across boots, I added the following to 
> /etc/modprobe/local.conf
> options drm_kms_helper poll=N
> 
> On reboot, the poll is still enabled
> [root at localhost ~]# cat /sys/module/drm_kms_helper/parameters/poll
> Y
> 
> Looking at the drm_crtc_helper.c I see
> void drm_kms_helper_poll_init(struct drm_device *dev)
> {
> INIT_DELAYED_WORK(&dev->mode_config.output_poll_work, 
> output_poll_execute);
> dev->mode_config.poll_enabled = true;
> 
> drm_kms_helper_poll_enable(dev);
> }
> 
> If I'm reading that correctly, poll_enable is set to true on initialization 
> unconditionally.
> 
> Questions:
> - Am I using "options drm_kms_helper poll=N" correctly
> - Is there a better way to have this option set to false on initialization?

You probably need to rebuild your initrd with your distro tools since
drm_kms_helper is loaded really early.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch

RE: abuse of dumb ioctls in exynos

[Tom Cooksey]

> It appears exynos is passing the generic flags from the dumb ioctls
> straight into the the GEM creation code.
> 
> The dumb flags are NOT driver specific, and are NOT to be used in this
> fashion. Please remove this use of the flags from your driver.
> 
> I was going to add one new flag to the interface for SCANOUT vs CURSOR
> for some drivers.

Having a flag to indicate a dumb buffer allocation is to be used as a 
scan-out buffer would be useful for xf86-video-armsoc. We're trying to
keep that driver as generic as possible and currently the main device-
specific bits are what flags to pass to DRM_IOCTL_MODE_CREATE_DUMB for
scanout & non-scanout buffer allocations. If a generic scanout flag could
be added, it would simplify armsoc a fair bit and also allow the DRM
drivers we're using armsoc with to comply with the don't pass device-
specific flags to create dumb.

For reference, the device-specific bits of armsoc are currently abstracted
here:




Note: We are still using DRM_IOCTL_MODE_CREATE_DUMB to allocate pixmap
and DRI2 buffers and have not come across any issues with doing that.
Certainly both Mali-400 & Mali-T6xx render to linear RGBA buffers and
the display controller's in SoCs shipping Mali also seem to happily
scan-out linear RGB buffers. Getting armsoc to run on OMAP (again) might
need a device-specific allocation function to allocate the tiled format
used on OMAP, but only for efficient 90-degree rotations (if I understood
Rob correctly). So maybe we could also one day add a "this buffer will be
rotated 90 degrees" flag?


Cheers,

Tom

PS: I've stuck in a fd.o bugzilla ticket to move xf86-video-armsoc to
freedesktop.org infrastructure, so hopefully it will live in a more
appropriate place soon, not to mention have a mailing list, etc.!





___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 00/21] ARM build fixes for 3.10

[Arnd Bergmann]

Hi everyone,

This is a set of bug fixes for build errors and warnings I am
seeing in the various defconfigs and/or allmodconfig builds
on linux-next. The majority of these showed up because we now
include a lot more platforms in allmodconfig than we used to.

Please apply to appropriate maintainer trees or provide
feedback, I can take care of the rest sending those through
arm-soc that I get no feedback on.

Arnd

Arnd Bergmann (21):
  Turn off -Wmaybe-uninitialized when building with -Os
  ARM: compressed/head.S: work around new binutils warning
  ARM: use optimized do_div only for EABI
  ARM: kvm: define KVM_ARM_MAX_VCPUS unconditionally
  ARM: OMAP2+: add dependencies on ARCH_MULTI_V6/V7
  ARM: tegra: call cpu_do_idle from C code
  ARM: tegra: unify tegra_idle_device definitions
  ASoC: ux500: forward declare msp_i2s_platform_data
  spi/sirf: fix MODULE_DEVICE_TABLE
  ssb: fix alignment of struct bcma_device_id
  drm/tilcdc: use only a single module device table
  mmc: sdhci-tegra: fix MODULE_DEVICE_TABLE
  misc: mark spear13xx-pcie-gadget as broken
  staging: nvec: allow modular build
  staging: comedi/dawboard2000: use mdelay for large delays
  staging/zsmalloc: don't use pgtable-mapping from modules
  tty/serial/sirf: fix MODULE_DEVICE_TABLE
  usb: phy: tegra: don't call into tegra-ehci directly
  usb: phy: don't mark usb_bind_phy as __init
  MFD: ab8500: export ab8500_gpadc_sw_hw_convert properly
  mtd: omap2: allow bulding as a module

 Makefile  |  2 +-
 arch/arm/boot/compressed/Makefile |  2 +-
 arch/arm/boot/compressed/head.S   | 12 
 arch/arm/include/asm/div64.h  |  2 +-
 arch/arm/kvm/Kconfig  |  6 +++---
 arch/arm/mach-omap2/Kconfig   |  5 +
 arch/arm/mach-tegra/cpuidle-tegra114.c|  5 ++---
 arch/arm/mach-tegra/cpuidle-tegra20.c |  4 +---
 arch/arm/mach-tegra/cpuidle-tegra30.c |  4 +---
 arch/arm/mach-tegra/cpuidle.c |  2 ++
 arch/arm/mach-tegra/cpuidle.h |  4 
 arch/arm/mach-tegra/pm.c  |  5 +
 arch/arm/mach-tegra/sleep-tegra20.S   |  2 +-
 drivers/gpu/drm/tilcdc/tilcdc_panel.c |  1 -
 drivers/gpu/drm/tilcdc/tilcdc_slave.c |  1 -
 drivers/gpu/drm/tilcdc/tilcdc_tfp410.c|  1 -
 drivers/mfd/ab8500-gpadc.c|  2 +-
 drivers/misc/Kconfig  |  2 +-
 drivers/mmc/host/sdhci-tegra.c|  2 +-
 drivers/mtd/nand/Kconfig  |  2 +-
 drivers/spi/spi-sirf.c|  2 +-
 drivers/staging/comedi/drivers/daqboard2000.c | 14 +++---
 drivers/staging/nvec/Kconfig  | 10 +-
 drivers/staging/zsmalloc/zsmalloc-main.c  |  2 +-
 drivers/tty/serial/sirfsoc_uart.c |  2 +-
 drivers/usb/host/ehci-tegra.c | 10 +-
 drivers/usb/otg/otg.c |  2 +-
 drivers/usb/phy/tegra_usb_phy.c   | 13 +
 include/linux/mod_devicetable.h   |  5 +++--
 include/linux/usb/tegra_usb_phy.h | 10 +-
 sound/soc/ux500/ux500_msp_i2s.h   |  1 +
 31 files changed, 82 insertions(+), 55 deletions(-)

-- 
1.8.1.2

Cc: Alan Stern 
Cc: Artem Bityutskiy 
Cc: Chris Ball 
Cc: Dave Airlie 
Cc: David Woodhouse 
Cc: Felipe Balbi 
Cc: Grant Likely 
Cc: Greg Kroah-Hartman 
Cc: Mark Brown 
Cc: Russell King 
Cc: Samuel Ortiz 
Cc: Stephen Warren 
Cc: Tony Lindgren 
Cc: Viresh Kumar 
Cc: alsa-de...@alsa-project.org
Cc: dri-devel@lists.freedesktop.org
Cc: linux-...@lists.infradead.org
Cc: linux-...@vger.kernel.org
Cc: spi-devel-gene...@lists.sourceforge.net
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 11/21] drm/tilcdc: use only a single module device table

[Arnd Bergmann]

The tilcdc driver fails to be built as a module because of extraneous
MODULE_DEVICE_TABLE entries:

drivers/gpu/drm/tilcdc/tilcdc_slave.o:(.data+0x54): multiple definition of 
`__mod_of_device_table'
drivers/gpu/drm/tilcdc/tilcdc_tfp410.o:(.data+0x54): first defined here
drivers/gpu/drm/tilcdc/tilcdc_panel.o:(.data+0x54): multiple definition of 
`__mod_of_device_table'
drivers/gpu/drm/tilcdc/tilcdc_tfp410.o:(.data+0x54): first defined here
drivers/gpu/drm/tilcdc/tilcdc_drv.o:(.data+0x184): multiple definition of 
`__mod_of_device_table'
drivers/gpu/drm/tilcdc/tilcdc_tfp410.o:(.data+0x54): first defined here

Since the entire point of these entries is to make the module autoload
when one of the devices is present, it's enough to keep the one entry
for "ti,am33xx-tilcdc", which should always be there if any of the
others are.

Cc: Rob Clark 
Cc: Dave Airlie 
Cc: dri-devel@lists.freedesktop.org
Signed-off-by: Arnd Bergmann 
---
 drivers/gpu/drm/tilcdc/tilcdc_panel.c  | 1 -
 drivers/gpu/drm/tilcdc/tilcdc_slave.c  | 1 -
 drivers/gpu/drm/tilcdc/tilcdc_tfp410.c | 1 -
 3 files changed, 3 deletions(-)

diff --git a/drivers/gpu/drm/tilcdc/tilcdc_panel.c 
b/drivers/gpu/drm/tilcdc/tilcdc_panel.c
index 580b74e..eb99f42 100644
--- a/drivers/gpu/drm/tilcdc/tilcdc_panel.c
+++ b/drivers/gpu/drm/tilcdc/tilcdc_panel.c
@@ -413,7 +413,6 @@ static struct of_device_id panel_of_match[] = {
{ .compatible = "ti,tilcdc,panel", },
{ },
 };
-MODULE_DEVICE_TABLE(of, panel_of_match);
 
 struct platform_driver panel_driver = {
.probe = panel_probe,
diff --git a/drivers/gpu/drm/tilcdc/tilcdc_slave.c 
b/drivers/gpu/drm/tilcdc/tilcdc_slave.c
index 568dc1c..db1d2fc 100644
--- a/drivers/gpu/drm/tilcdc/tilcdc_slave.c
+++ b/drivers/gpu/drm/tilcdc/tilcdc_slave.c
@@ -353,7 +353,6 @@ static struct of_device_id slave_of_match[] = {
{ .compatible = "ti,tilcdc,slave", },
{ },
 };
-MODULE_DEVICE_TABLE(of, slave_of_match);
 
 struct platform_driver slave_driver = {
.probe = slave_probe,
diff --git a/drivers/gpu/drm/tilcdc/tilcdc_tfp410.c 
b/drivers/gpu/drm/tilcdc/tilcdc_tfp410.c
index 58d487b..a36788f 100644
--- a/drivers/gpu/drm/tilcdc/tilcdc_tfp410.c
+++ b/drivers/gpu/drm/tilcdc/tilcdc_tfp410.c
@@ -396,7 +396,6 @@ static struct of_device_id tfp410_of_match[] = {
{ .compatible = "ti,tilcdc,tfp410", },
{ },
 };
-MODULE_DEVICE_TABLE(of, tfp410_of_match);
 
 struct platform_driver tfp410_driver = {
.probe = tfp410_probe,
-- 
1.8.1.2

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 63632] mesa +r600 llvm = segfault

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=63632

--- Comment #6 from Michel D?nzer  ---
Which version of libelf is used in each case? I was running into problems with
the one from http://www.mr511.de/software/ but the one from Fedora's elfutils
works fine. Tom told me on IRC the former requires an additional initialization
step.

-- 
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/20130423/76e96c1e/attachment-0001.html>

[Bug 61182] r600g causes KWin crashes with kernel 3.8

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=61182

--- Comment #45 from Emil Velikov  ---
(In reply to comment #44)
> What version of cogl should I look for?  I can add something about this to
> the Fedora bug report.

commit: 93b7b4c850dd928bf21ee168a95641a8d631f713
Author: Jerome Glisse 

glx do not use multisample visual config for front or pixmap

There is no guaranty that glXGetFBConfigs will return fbconfig ordered
with non msaa config first. This patch make sure that non msaa config
get choose.

Present only in the master branch. Mind you I'm not a dev, but I've sent a
request[1] to pull it the 1.12, 1.14 branches. Hope they will pick it up soon

Emil

[1] http://lists.freedesktop.org/archives/cogl/2013-April/001090.html

-- 
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/20130423/a4ffdbaa/attachment.html>

[Bug 63730] UVD broken on HD5470 by "drm/radeon: raise UVD clocks only on demand"

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=63730

Christian K?nig  changed:

   What|Removed |Added

  Attachment #78323|0   |1
is obsolete||

--- Comment #8 from Christian K?nig  ---
Created attachment 78357
  --> https://bugs.freedesktop.org/attachment.cgi?id=78357&action=edit
Raise UVD clocks while booting the VCPU.

>I've already tested this by myself and can confirm that this fix the problem.

Ok then let's try to narrow this further down. The attached patch should tries
to only raise the clocks while the VCPU is booting.

Please test on your hardware.

-- 
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/20130423/6ce27644/attachment.html>

[Bug 63730] UVD broken on HD5470 by "drm/radeon: raise UVD clocks only on demand"

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=63730

Christian König  changed:

   What|Removed |Added

  Attachment #78357|0   |1
is obsolete||

--- Comment #15 from Christian König  ---
Created attachment 78377
  --> https://bugs.freedesktop.org/attachment.cgi?id=78377&action=edit
Possible fix

This one should do it, the problems indeed seems to be that the VCPU on
evergreen doesn't work with the lower clocks.

Please test.

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 63730] UVD broken on HD5470 by "drm/radeon: raise UVD clocks only on demand"

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=63730

--- Comment #14 from Johannes Hirte  ---
(In reply to comment #13)
> I don't think that crashing X is related to a not working UVD ring, at least
> it shouldn't.

I can only say what I'm observing. with this patch X crashes as soon as I start
chromium. Without it doesn't.

> Anyway, I've got a good news: I was able to reproduce the problem with a
> HD5670, so a final patch fixing this is on the way.

Sounds good, I'm waiting for testing.

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Radeon lockup on 3.8.5-201.fc18.x86_64

[Michel Dänzer]

On Mon, 2013-04-22 at 16:19 -0700, Andy Lutomirski wrote: 
> On Thu, Apr 18, 2013 at 2:12 PM, Alex Deucher  
> wrote:
> > On Thu, Apr 18, 2013 at 5:11 PM, Andy Lutomirski  
> > wrote:
> >> On Mon, Apr 8, 2013 at 7:01 AM, Alex Deucher  
> >> wrote:
> >>> On Fri, Apr 5, 2013 at 5:11 PM, Andy Lutomirski  
> >>> wrote:
>  Every day or so, I'll click something and my screens go blank for a
>  second or two.  dmesg complains about a lockup, and afterwards
>  everything is painfully slow.  (Even switching focus to other emacs
>  windows takes a second or two.)  Once this happens, if I restart X, I
>  get a blank screen, although the mouse still works and I can switch
>  VTs and use the console.
> >>>
> >>> Try disabling hyperZ.  Set env var R600_HYPERZ=0 (mesa 9.1) or
> >>> R600_DEBUG=nohyperz (mesa git).
> >>
> >> It lasted longer.  I have both of those environment variables set on
> >> the Xorg process but not on clients.  Do  I need it everywhere?
> >
> > For anything that uses the 3D driver.
> 
> This didn't appear to fix it, although it may have fixed some
> graphical glitches in gmail's compose window.

Seems rather unlikely that's directly related to HyperZ, but who knows.


> [350788.530966] radeon :08:00.0: GPU lockup CP stall for more than 
> 40769msec
> [350788.530970] radeon :08:00.0: GPU lockup (waiting for
> 0x178f last fence id 0x178e)
> [350788.532047] radeon :08:00.0: Saved 103 dwords of commands on ring 0.
> [350788.532051] radeon :08:00.0: GPU softreset: 0x0003
> [350788.547792] radeon :08:00.0:   GRBM_STATUS   = 0xA0003828
> [350788.547794] radeon :08:00.0:   GRBM_STATUS_SE0   = 0x0007
> [350788.547797] radeon :08:00.0:   GRBM_STATUS_SE1   = 0x0007
> [350788.547799] radeon :08:00.0:   SRBM_STATUS   = 0x20C0
> [350788.547802] radeon :08:00.0:   R_008674_CP_STALLED_STAT1 = 0x
> [350788.547805] radeon :08:00.0:   R_008678_CP_STALLED_STAT2 = 0x
> [350788.547807] radeon :08:00.0:   R_00867C_CP_BUSY_STAT = 0x0004
> [350788.547810] radeon :08:00.0:   R_008680_CP_STAT  = 0x80008647
> [350788.547811] radeon :08:00.0:   GRBM_SOFT_RESET=0x7F6B
> [350788.547866] radeon :08:00.0:   GRBM_STATUS   = 0x3828
> [350788.547869] radeon :08:00.0:   GRBM_STATUS_SE0   = 0x0007
> [350788.547872] radeon :08:00.0:   GRBM_STATUS_SE1   = 0x0007
> [350788.547874] radeon :08:00.0:   SRBM_STATUS   = 0x20C0
> [350788.547877] radeon :08:00.0:   R_008674_CP_STALLED_STAT1 = 0x
> [350788.547879] radeon :08:00.0:   R_008678_CP_STALLED_STAT2 = 0x
> [350788.547882] radeon :08:00.0:   R_00867C_CP_BUSY_STAT = 0x
> [350788.547884] radeon :08:00.0:   R_008680_CP_STAT  = 0x
> [350788.565361] radeon :08:00.0: GPU reset succeeded, trying to resume
> [350788.583801] [drm] probing gen 2 caps for device 8086:1d1a = 2/0
> [350788.583807] [drm] enabling PCIE gen 2 link speeds, disable with
> radeon.pcie_gen2=0
> [350788.590840] [drm] PCIE GART of 512M enabled (table at 0x0004).
> [350788.590976] radeon :08:00.0: WB enabled
> [350788.590978] radeon :08:00.0: fence driver on ring 0 use gpu
> addr 0x4c00 and cpu addr 0x880442f58c00
> [350788.590979] radeon :08:00.0: fence driver on ring 3 use gpu
> addr 0x4c0c and cpu addr 0x880442f58c0c
> [350788.607480] [drm] ring test on 0 succeeded in 2 usecs
> [350788.607560] [drm] ring test on 3 succeeded in 1 usecs
> [350788.615053] [drm] ib test on ring 0 succeeded in 0 usecs
> [350788.615133] [drm] ib test on ring 3 succeeded in 1 usecs
> 
> I'm not convinced there's an actual hang.  40 seconds is a long time,
> and I've only ever seen this when clicking something, and when this
> happens, the screen goes blank immediately (not after a 40 second
> delay).

Hmm, now that you mention this, I notice in your original report it
claims that the CP stalled for 'more than 5102593msec', which is clearly
bogus. Looks like something's wrong with the lockup detection. 
Did this start after a kernel update or something like that?


-- 
Earthling Michel D?nzer   |   http://www.amd.com
Libre software enthusiast |  Debian, X and DRI developer

[Bug 63632] mesa +r600 llvm = segfault

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=63632

--- Comment #7 from Tom Stellard  ---
(In reply to comment #4)
> (In reply to comment #3)
> > (In reply to comment #2)
> > > I can't reproduce this with LLVM r179895 and Mesa
> > > 12eab7cc564a6928197f9b87ded9e368e56976f0
> > > 
> > > Have you done full rebuilds of both projects?
> > 
> > Yes, I always do make [dist]clean and git clean -dfx.
> > 
> > I have just deleted both trees and re-cloned to be sure, but the segfault is
> > still there.
> > 
> > When I was on my working commits moving either llvm or mesa to head while
> > keeping the other on "working" produced the segfault (which is why I didn't
> > do a proper bisect).
> > 
> > I always clean and rebuild mesa after llvm has changed.
> 
> I was able to reproduce this on my gentoo system, but not on either of my
> fedora systems.  I will investigate further, what distro are you using?

The problem on my gentoo system was that I had removed --enable-shared from my
llvm configure script a few days ago, so I was still linking with an older
LLVM.

Can you check that you are passing --enable-shared when configuring LLVM?

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v4] drm/exynos: prepare FIMD clocks

[Inki Dae]

2013/4/23 myungjoo.ham 

> 2013/4/22 Inki Dae
> > 2013/4/22 Rafael J. Wysocki 
> > > On Monday, April 22, 2013 12:37:36 PM Tomasz Figa wrote:
> > > > On Monday 22 of April 2013 12:17:39 Sylwester Nawrocki wrote:
> > > > > On 04/22/2013 12:03 PM, Inki Dae wrote:
> > > > > > > Also looks good to me. But what if power domain was
> disabled
> without
> > > > > > > pm
> > > > > > > runtime? In this case, you must enable the power domain at
> machine
> > > > > > > code or
> > > > > > > bootloader somewhere. This way would not only need some
> hard
> codes
> > > > > > > to turn
> > > > > > > the power domain on but also not manage power management
> fully. This
> > > > > > > is same as only the use of pm runtime interface(needing
> some
> hard
> > > > > > > codes without pm runtime) so I don't prefer to add
> > > > > > > clk_enable/disable to fimd probe(). I quite tend to force
> only the
> > > > > > > use of pm runtime as possible. So please add the hard codes
> to
> > > > > > > machine code or bootloader like you did for power domain if
> you
> > > > > > > want to use drm fimd without pm runtime.
> > > > > >
> > > > > > That's not how the runtime PM, clock subsystems work:
> > > > > >
> > > > > > 1) When CONFIG_PM_RUNTIME is disabled, all the used hardware
> must be
> > > > > > kept
> > > > > > powered on all the time.
> > > > > >
> > > > > > 2) Common Clock Framework will always gate all clocks that
> have zero
> > > > > > enable_count. Note that CCF support for Exynos is already
> merged for
> > > > > > 3.10 and it will be the only available clock support method
> for
> > > > > > Exynos.
> > > > > >
> > > > > > AFAIK, drivers must work correctly in both cases, with
> > > > > > CONFIG_PM_RUNTIME
> > > > > > enabled and disabled.
> > > > > >
> > > > > > Then is the driver worked correctly if the power domain to this
> device was
> > > > > > disabled at bootloader without CONFIG_PM_RUNTIME and with
> clk_enable()?  I
> > > > > > think, in this case, the device wouldn't be worked correctly
> because the
> > > > > > power of the device remains off. So you must enable the power
> domain
> > > > > > somewhere. What is the difference between these two cases?
> > > > >
> > > > > How about making the driver dependant on PM_RUNTIME and making it
> always
> > > > > use pm_runtime_* API, regardless if the platform actually
> implements
> runtime
> > > > > PM or not ? Is there any issue in using the Runtime PM core always,
> rather
> > > > > than coding any workarounds in drivers when PM_RUNTIME is disabled
> ?
> > > >
> > > > I don't think this is a good idea. This would mean that any user that
> from
> > > > some reasons don't want to use PM_RUNTIME, would not be able to use
> the driver
> > > > anymore.
> > > >
> > > > Rafael, Kevin, do you have any opinion on this?
> > > I agree.
> > >
> > > Drivers should work for CONFIG_PM_RUNTIME unset too and static inline
> stubs for
> > > all runtime PM helpers are available in that case.
> > >
> > Hi Rafael,
> > The embedded system, at least Exynos SoC case, has the power domain
> device
> and this device could be enabled only by pm runtime interface. So the
> device
> couldn't be worked correctly without turning the power domain on only
> calling clk_enable(). In this case, the power domain must be enabled at
> machine code or bootloader. And the machine without CONFIG_PM_RUNTIME would
> assume that their own drivers always are enabled so the devices would be
> worked correctly. Is there any my missing point?
>
>
> - Power domain: not controlled if !CONFIG_PM_RUNTIME. Thus, we may
> assume that every power domain is kept ON from boot time if
> !CONFIG_PM_RUNTIME.
> If power domain is kept OFF from boot time (machine init code or
> bootloader)
> with !CONFIG_PM_RUNTIME, then it's simple a mistake at BSP writer.
>
> - Yes, the clock is still controlled while !CONFIG_PM_RUNTIME.
>
> My opinion is also to let probe do clk-enables though I don't want it
> to have #ifdef or "clk_enable()" in the probe function.
> Thus, implementing "power_on()"-like function in the driver and let probe()
> and
> runtime_pm_get callback call it seems appropriate to me.
> (that "fimd_active(ctx, true)" is "power-on" to itself, right?)
>
>
I thought that it should assume the power domain and relevant clocks are
enabled without CONFIG_PM_RUNTIME. So could anyone please tell me about
that? If only the power domain , I think Tomasz's proposal is good solution.

Thanks,
Inki Dae


>
> Cheers,
> MyungJoo
>
>
> --
> To unsubscribe from this list: send the line "unsubscribe
> linux-samsung-soc" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 63730] UVD broken on HD5470 by "drm/radeon: raise UVD clocks only on demand"

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=63730

Christian König  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED

--- Comment #13 from Christian König  ---
I don't think that crashing X is related to a not working UVD ring, at least it
shouldn't.

Anyway, I've got a good news: I was able to reproduce the problem with a
HD5670, so a final patch fixing this is on the way.

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 63730] UVD broken on HD5470 by "drm/radeon: raise UVD clocks only on demand"

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=63730

--- Comment #12 from Johannes Hirte  ---
It's related to the [PATCH] drm/radeon: raise UVD clocks while booting the VCPU
patch. With this applied, X crashes when starting chromium browser.

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v3 3/3] drm/exynos: add device tree support for fimc ipp driver

[Sylwester Nawrocki]

This patch adds OF initialization support for the FIMC driver.
The binding documentation can be found at Documentation/devicetree/
bindings/media/samsung-fimc.txt.

The syscon regmap interface is used to serialize access to the
shared CAMBLK registers from within the V4L2 FIMC-IS and the DRM
FIMC drivers. The DRM driver uses this interface for setting up
the FIFO data link between FIMD and FIMC IP blocks, while the V4L2
one for setting up a data link between the camera ISP and FIMC for
camera capture. The CAMBLK registers are not accessed any more
through a statically mapped IO. Synchronized access to these
registers is required for simultaneous operation of the camera
ISP and the DRM IPP on Exynos4x12.

The driver data and driver_ids static data structures are removed
since Exynos4 is going to be a dt-only platform and there is
currently no board file in mainline that defines platform data
for the FIMC IPP, i.e. uses it.

Camera input signal polarities are not currently parsed from the
device tree.

Signed-off-by: Sylwester Nawrocki 
Signed-off-by: Kyungmin Park 
---
 drivers/gpu/drm/exynos/Kconfig   |2 +-
 drivers/gpu/drm/exynos/exynos_drm_fimc.c |  110 --
 drivers/gpu/drm/exynos/regs-fimc.h   |7 +-
 3 files changed, 62 insertions(+), 57 deletions(-)

diff --git a/drivers/gpu/drm/exynos/Kconfig b/drivers/gpu/drm/exynos/Kconfig
index 406f32a..5c4be2a 100644
--- a/drivers/gpu/drm/exynos/Kconfig
+++ b/drivers/gpu/drm/exynos/Kconfig
@@ -56,7 +56,7 @@ config DRM_EXYNOS_IPP
 
 config DRM_EXYNOS_FIMC
bool "Exynos DRM FIMC"
-   depends on DRM_EXYNOS_IPP
+   depends on DRM_EXYNOS_IPP && MFD_SYSCON && OF
help
  Choose this option if you want to use Exynos FIMC for DRM.
 
diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimc.c 
b/drivers/gpu/drm/exynos/exynos_drm_fimc.c
index 2cce97d..773f583 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_fimc.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_fimc.c
@@ -12,11 +12,12 @@
  *
  */
 #include 
+#include 
 #include 
 #include 
+#include 
 #include 
 #include 
-#include 
 
 #include 
 #include 
@@ -140,15 +141,6 @@ struct fimc_capability {
 };
 
 /*
- * A structure of fimc driver data.
- *
- * @parent_clk: name of parent clock.
- */
-struct fimc_driverdata {
-   char*parent_clk;
-};
-
-/*
  * A structure of fimc context.
  *
  * @ippdrv: prepare initialization using ippdrv.
@@ -157,6 +149,7 @@ struct fimc_driverdata {
  * @lock: locking of operations.
  * @clocks: fimc clocks.
  * @clk_frequency: LCLK clock frequency.
+ * @sysreg: handle to SYSREG block regmap.
  * @sc: scaler infomations.
  * @pol: porarity of writeback.
  * @id: fimc id.
@@ -170,8 +163,8 @@ struct fimc_context {
struct mutexlock;
struct clk  *clocks[FIMC_CLKS_MAX];
u32 clk_frequency;
+   struct regmap   *sysreg;
struct fimc_scaler  sc;
-   struct fimc_driverdata  *ddata;
struct exynos_drm_ipp_pol   pol;
int id;
int irq;
@@ -215,17 +208,13 @@ static void fimc_sw_reset(struct fimc_context *ctx)
fimc_write(0x0, EXYNOS_CIFCNTSEQ);
 }
 
-static void fimc_set_camblk_fimd0_wb(struct fimc_context *ctx)
+static int fimc_set_camblk_fimd0_wb(struct fimc_context *ctx)
 {
-   u32 camblk_cfg;
-
DRM_DEBUG_KMS("%s\n", __func__);
 
-   camblk_cfg = readl(SYSREG_CAMERA_BLK);
-   camblk_cfg &= ~(SYSREG_FIMD0WB_DEST_MASK);
-   camblk_cfg |= ctx->id << (SYSREG_FIMD0WB_DEST_SHIFT);
-
-   writel(camblk_cfg, SYSREG_CAMERA_BLK);
+   return regmap_update_bits(ctx->sysreg, SYSREG_CAMERA_BLK,
+ SYSREG_FIMD0WB_DEST_MASK,
+ ctx->id << SYSREG_FIMD0WB_DEST_SHIFT);
 }
 
 static void fimc_set_type_ctrl(struct fimc_context *ctx, enum fimc_wb wb)
@@ -1626,7 +1615,11 @@ static int fimc_ippdrv_start(struct device *dev, enum 
drm_exynos_ipp_cmd cmd)
fimc_handle_lastend(ctx, true);
 
/* setup FIMD */
-   fimc_set_camblk_fimd0_wb(ctx);
+   ret = fimc_set_camblk_fimd0_wb(ctx);
+   if (ret < 0) {
+   dev_err(dev, "camblk setup failed.\n");
+   return ret;
+   }
 
set_wb.enable = 1;
set_wb.refresh = property->refresh_rate;
@@ -1786,26 +1779,58 @@ e_clk_free:
return ret;
 }
 
+static int fimc_parse_dt(struct fimc_context *ctx)
+{
+   struct device_node *node = ctx->ippdrv.dev->of_node;
+
+   /* Handle only devices that support the LCD Writeback data path */
+   if (!of_property_read_bool(node, "samsung,lcd-wb"))
+   return -ENODEV;
+
+   if (of_property_read_u32(node, "clock-frequency",
+   &ctx->clk_frequency))
+   ctx->clk_frequency = FIMC_DEFAULT_LCLK_FREQUENCY;
+
+   ctx->id = of_alias_get_id(node, "fimc");
+
+   if (ctx->id < 

[PATCH v3 2/3] drm/exynos: rework fimc clocks handling

[Sylwester Nawrocki]

The clocks handling is refactored and a "mux" clock handling is
added to account for changes in the clocks driver. After switching
to the common clock framework the sclk_fimc clock is now split
into two clocks: a gate and a mux clock. In order to retain the
exisiting functionality two additional consumer clocks are passed
to the driver from device tree: "mux" and "parent". Then the driver
sets "parent" clock as a parent clock of the "mux" clock. These two
additional clocks are optional, and should go away when there is a
standard way of setting up parent clocks on DT platforms.

Signed-off-by: Sylwester Nawrocki 
Signed-off-by: Kyungmin Park 
---
 drivers/gpu/drm/exynos/exynos_drm_fimc.c |  169 +-
 1 file changed, 99 insertions(+), 70 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimc.c 
b/drivers/gpu/drm/exynos/exynos_drm_fimc.c
index d812c57..2cce97d 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_fimc.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_fimc.c
@@ -76,6 +76,27 @@ enum fimc_wb {
FIMC_WB_B,
 };
 
+enum {
+   FIMC_CLK_LCLK,
+   FIMC_CLK_GATE,
+   FIMC_CLK_WB_A,
+   FIMC_CLK_WB_B,
+   FIMC_CLK_MUX,
+   FIMC_CLK_PARENT,
+   FIMC_CLKS_MAX
+};
+
+static const char * const fimc_clock_names[] = {
+   [FIMC_CLK_LCLK]   = "sclk_fimc",
+   [FIMC_CLK_GATE]   = "fimc",
+   [FIMC_CLK_WB_A]   = "pxl_async0",
+   [FIMC_CLK_WB_B]   = "pxl_async1",
+   [FIMC_CLK_MUX]= "mux",
+   [FIMC_CLK_PARENT] = "parent",
+};
+
+#define FIMC_DEFAULT_LCLK_FREQUENCY 13300UL
+
 /*
  * A structure of scaler.
  *
@@ -134,13 +155,9 @@ struct fimc_driverdata {
  * @regs_res: register resources.
  * @regs: memory mapped io registers.
  * @lock: locking of operations.
- * @sclk_fimc_clk: fimc source clock.
- * @fimc_clk: fimc clock.
- * @wb_clk: writeback a clock.
- * @wb_b_clk: writeback b clock.
+ * @clocks: fimc clocks.
+ * @clk_frequency: LCLK clock frequency.
  * @sc: scaler infomations.
- * @odr: ordering of YUV.
- * @ver: fimc version.
  * @pol: porarity of writeback.
  * @id: fimc id.
  * @irq: irq number.
@@ -151,10 +168,8 @@ struct fimc_context {
struct resource *regs_res;
void __iomem*regs;
struct mutexlock;
-   struct clk  *sclk_fimc_clk;
-   struct clk  *fimc_clk;
-   struct clk  *wb_clk;
-   struct clk  *wb_b_clk;
+   struct clk  *clocks[FIMC_CLKS_MAX];
+   u32 clk_frequency;
struct fimc_scaler  sc;
struct fimc_driverdata  *ddata;
struct exynos_drm_ipp_pol   pol;
@@ -1301,14 +1316,12 @@ static int fimc_clk_ctrl(struct fimc_context *ctx, bool 
enable)
DRM_DEBUG_KMS("%s:enable[%d]\n", __func__, enable);
 
if (enable) {
-   clk_enable(ctx->sclk_fimc_clk);
-   clk_enable(ctx->fimc_clk);
-   clk_enable(ctx->wb_clk);
+   clk_prepare_enable(ctx->clocks[FIMC_CLK_GATE]);
+   clk_prepare_enable(ctx->clocks[FIMC_CLK_WB_A]);
ctx->suspended = false;
} else {
-   clk_disable(ctx->sclk_fimc_clk);
-   clk_disable(ctx->fimc_clk);
-   clk_disable(ctx->wb_clk);
+   clk_disable_unprepare(ctx->clocks[FIMC_CLK_GATE]);
+   clk_disable_unprepare(ctx->clocks[FIMC_CLK_WB_A]);
ctx->suspended = true;
}
 
@@ -1713,11 +1726,70 @@ static void fimc_ippdrv_stop(struct device *dev, enum 
drm_exynos_ipp_cmd cmd)
fimc_write(cfg, EXYNOS_CIGCTRL);
 }
 
+static void fimc_put_clocks(struct fimc_context *ctx)
+{
+   int i;
+
+   for (i = 0; i < FIMC_CLKS_MAX; i++) {
+   if (IS_ERR(ctx->clocks[i]))
+   continue;
+   clk_put(ctx->clocks[i]);
+   ctx->clocks[i] = ERR_PTR(-EINVAL);
+   }
+}
+
+static int fimc_setup_clocks(struct fimc_context *ctx)
+{
+   struct device *fimc_dev = ctx->ippdrv.dev;
+   struct device *dev;
+   int ret, i;
+
+   for (i = 0; i < FIMC_CLKS_MAX; i++)
+   ctx->clocks[i] = ERR_PTR(-EINVAL);
+
+   for (i = 0; i < FIMC_CLKS_MAX; i++) {
+   if (i == FIMC_CLK_WB_A || i == FIMC_CLK_WB_B)
+   dev = fimc_dev->parent;
+   else
+   dev = fimc_dev;
+
+   ctx->clocks[i] = clk_get(dev, fimc_clock_names[i]);
+   if (IS_ERR(ctx->clocks[i])) {
+   if (i >= FIMC_CLK_MUX)
+   break;
+   ret = PTR_ERR(ctx->clocks[i]);
+   dev_err(fimc_dev, "failed to get clock: %s\n",
+   fimc_clock_names[i]);
+   goto e_clk_free;
+   }
+   }
+
+   /* Optional FIMC LCLK parent clock setting */
+   if (!IS_ERR(ctx->clocks[FIMC_CLK_PARENT])) {
+   ret = clk_set_parent(ctx->clocks[FIMC_CLK_MUX],
+   

[PATCH v3 1/3] drm/exynos: remove redundant devm_kfree()

[Sylwester Nawrocki]

There is no need for explicit calls of devm_kfree(), as
the allocated memory will be freed during driver's detach.
Remove the redundant devm_kfree() calls from probe() and
remove() callbacks.

Signed-off-by: Sylwester Nawrocki 
Signed-off-by: Kyungmin Park 
---
 drivers/gpu/drm/exynos/exynos_drm_fimc.c |2 --
 1 file changed, 2 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimc.c 
b/drivers/gpu/drm/exynos/exynos_drm_fimc.c
index 411f69b7..d812c57 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_fimc.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_fimc.c
@@ -1843,7 +1843,6 @@ static int fimc_probe(struct platform_device *pdev)
return 0;
 
 err_ippdrv_register:
-   devm_kfree(dev, ippdrv->prop_list);
pm_runtime_disable(dev);
 err_get_irq:
free_irq(ctx->irq, ctx);
@@ -1857,7 +1856,6 @@ static int fimc_remove(struct platform_device *pdev)
struct fimc_context *ctx = get_fimc_context(dev);
struct exynos_drm_ippdrv *ippdrv = &ctx->ippdrv;
 
-   devm_kfree(dev, ippdrv->prop_list);
exynos_drm_ippdrv_unregister(ippdrv);
mutex_destroy(&ctx->lock);
 
-- 
1.7.9.5

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v3 0/3] drm/exynos: Add device tree support for IPP driver

[Sylwester Nawrocki]

Hi,

This small patch series adds device tree support for the DRM FIMC driver.
The binding documentation can be found in -next at Documentation/devicetree/
bindings/media/samsung-fimc.txt.

Changes since v2:
 - dropped addition of 'dev' field to struct fimc_context,
 - added more error logs and comments,
 - fixed error paths in fimc_setup_clocks() function.

Changes since v1:
 - removed devm_kfree() that got erroneously re-added in patch 2/3 during
   rebase.

Thanks,
Sylwester

Sylwester Nawrocki (3):
  drm/exynos: remove redundant devm_kfree()
  drm/exynos: rework fimc clocks handling
  drm/exynos: add device tree support for fimc ipp driver

 drivers/gpu/drm/exynos/Kconfig   |2 +-
 drivers/gpu/drm/exynos/exynos_drm_fimc.c |  273 +-
 drivers/gpu/drm/exynos/regs-fimc.h   |7 +-
 3 files changed, 157 insertions(+), 125 deletions(-)

--
1.7.9.5

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 61182] r600g causes KWin crashes with kernel 3.8

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=61182

--- Comment #46 from boris64  ---
(In reply to comment #43)
> (In reply to comment #42)
> > As i said in comment 30 it's also a bug of kwin, kwin should not use msaa
> > visual for everything ...
> 
> I've pushed a patch to the stable branch in KDE that should fix this issue.

Could you post a link to that patch?
Thank you.

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 63730] UVD broken on HD5470 by "drm/radeon: raise UVD clocks only on demand"

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=63730

--- Comment #11 from Michel Dänzer  ---
(In reply to comment #10)
> Caught signal 7 (Bus error). Server aborting

Could be bug 61182.

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 63730] UVD broken on HD5470 by "drm/radeon: raise UVD clocks only on demand"

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=63730

--- Comment #10 from Johannes Hirte  ---
And I've had a X crash now. The output is from kdm.log since Xorg.log was
already overwritten:

(EE) 
(EE) Backtrace:
(EE) 0: /usr/bin/X (xorg_backtrace+0x3d) [0x59ed1d]
(EE) 1: /usr/bin/X (0x40+0x1a3409) [0x5a3409]
(EE) 2: /lib64/libpthread.so.0 (0x7f43cdf07000+0x10ed0) [0x7f43cdf17ed0]
(EE) 3: /lib64/libc.so.6 (0x7f43cd20c000+0x907bb) [0x7f43cd29c7bb]
(EE) 4: /usr/lib64/xorg/modules/drivers/radeon_drv.so (0x7f43ca808000+0x3e436)
[0x7f43ca846436]
(EE) 5: /usr/lib64/xorg/modules/libexa.so (0x7f43cea5a000+0x970c)
[0x7f43cea6370c]
(EE) 6: /usr/bin/X (0x40+0xdd521) [0x4dd521]
(EE) 7: /usr/bin/X (0x40+0xde2e5) [0x4de2e5]
(EE) 8: /usr/bin/X (0x40+0x3587f) [0x43587f]
(EE) 9: /usr/bin/X (0x40+0x23fed) [0x423fed]
(EE) 10: /lib64/libc.so.6 (__libc_start_main+0xf5) [0x7f43cd230c15]
(EE) 11: /usr/bin/X (0x40+0x23b09) [0x423b09]
(EE) 
(EE) Bus error at address 0x7f43bddca000

Fatal server error:
Caught signal 7 (Bus error). Server aborting

(EE) 
Please consult the The X.Org Foundation support 
 at http://wiki.x.org
 for help. 
(EE) Please also check the log file at "/var/log/Xorg.0.log" for additional
information.
(EE)

Don't know if this is related to the UVD problem.

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 63732] [KDE] - display switching problem with kwin_gles and radeon driver.

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=63732

--- Comment #5 from Michel Dänzer  ---
(In reply to comment #2)
> I must say that I don't have any problem with kwin (but kwin is too slow for
> me).

FWIW, there is no inherent reason why kwin using full OpenGL should be slower
than kwin_gles, but there is a kwin bug where it uses MSAA when it shouldn't.
Supposedly that's fixed in current current kwin snapshots.

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 63709] Desktop Effects on 3D desktop environments are jerky/stutter.

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=63709

--- Comment #5 from Michel Dänzer  ---
The KDE problem could be kwin using MSAA when it shouldn't. This is supposedly
fixed in current versions of kwin.

At least some of the other issues you're describing will be hard to eliminate
completely without (something like) Wayland.

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 63730] UVD broken on HD5470 by "drm/radeon: raise UVD clocks only on demand"

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=63730

--- Comment #9 from Johannes Hirte  ---
with the latest patch I get the following output:

[2.137767] Linux agpgart interface v0.103
[2.138046] [drm] Initialized drm 1.1.0 20060810
[2.138309] [drm] radeon kernel modesetting enabled.
[2.138962] [drm] initializing kernel modesetting (CEDAR 0x1002:0x68E0
0x1025:0x0489).
[2.139136] [drm] register mmio base: 0xF210
[2.139284] [drm] register mmio size: 131072
[2.144757] ATOM BIOS: Acer
[2.145053] radeon :01:00.0: VRAM: 512M 0x -
0x1FFF (512M used)
[2.145343] radeon :01:00.0: GTT: 512M 0x2000 -
0x3FFF
[2.145722] [drm] Detected VRAM RAM=512M, BAR=256M
[2.145897] [drm] RAM width 64bits DDR
[2.146136] [TTM] Zone  kernel: Available graphics memory: 2022516 kiB
[2.146285] [TTM] Initializing pool allocator
[2.146436] [TTM] Initializing DMA pool allocator
[2.146621] [drm] radeon: 512M of VRAM memory ready
[2.146785] [drm] radeon: 512M of GTT memory ready.
[2.146949] [drm] Supports vblank timestamp caching Rev 1 (10.10.2010).
[2.149945] [drm] Driver supports precise vblank timestamp query.
[2.150136] radeon :01:00.0: irq 43 for MSI/MSI-X
[2.150147] radeon :01:00.0: radeon: using MSI.
[2.150325] [drm] radeon: irq initialized.
[2.152070] [drm] GART: num cpu pages 131072, num gpu pages 131072
[2.153407] [drm] probing gen 2 caps for device 1022:9603 = 300d02/0
[2.153596] [drm] enabling PCIE gen 2 link speeds, disable with
radeon.pcie_gen2=0
[2.153909] [drm] Loading CEDAR Microcode
[2.168856] [drm] PCIE GART of 512M enabled (table at 0x0025D000).
[2.169128] radeon :01:00.0: WB enabled
[2.169283] radeon :01:00.0: fence driver on ring 0 use gpu addr
0x2c00 and cpu addr 0x88011a174c00
[2.169570] radeon :01:00.0: fence driver on ring 3 use gpu addr
0x2c0c and cpu addr 0x88011a174c0c
[2.170039] radeon :01:00.0: fence driver on ring 5 use gpu addr
0x0005c418 and cpu addr 0xc90001e9c418
[2.186632] [drm] ring test on 0 succeeded in 1 usecs
[2.186878] [drm] ring test on 3 succeeded in 1 usecs
[2.363300] [drm] ring test on 5 succeeded in 1 usecs
[2.363484] [drm] UVD initialized successfully.
[2.363745] [drm] ib test on ring 0 succeeded in 0 usecs
[2.363927] [drm] ib test on ring 3 succeeded in 0 usecs
[2.744243] ACPI: Deprecated procfs I/F for battery is loaded, please retry
with CONFIG_ACPI_PROCFS_POWER cleared
[2.744539] ACPI: Battery Slot [BAT1] (battery present)
[3.046208] tsc: Refined TSC clocksource calibration: 2094.754 MHz
[3.046364] Switching to clocksource tsc
[   12.648332] radeon :01:00.0: GPU lockup CP stall for more than 1msec
[   12.648493] radeon :01:00.0: GPU lockup (waiting for 0x0002
last fence id 0x)
[   12.648781] [drm:r600_uvd_ib_test] *ERROR* radeon: fence wait failed (-35).
[   12.648932] [drm:radeon_ib_ring_tests] *ERROR* radeon: failed testing IB on
ring 5 (-35).
[   12.703326] [drm] radeon atom DIG backlight initialized
[   12.703481] [drm] Radeon Display Connectors
[   12.703630] [drm] Connector 0:
[   12.703777] [drm]   LVDS-1
[   12.703925] [drm]   DDC: 0x6560 0x6560 0x6564 0x6564 0x6568 0x6568 0x656c
0x656c
[   12.704074] [drm]   Encoders:
[   12.704221] [drm] LCD1: INTERNAL_UNIPHY
[   12.704374] [drm] Connector 1:
[   12.704522] [drm]   HDMI-A-1
[   12.704668] [drm]   HPD1
[   12.704815] [drm]   DDC: 0x6430 0x6430 0x6434 0x6434 0x6438 0x6438 0x643c
0x643c
[   12.704964] [drm]   Encoders:
[   12.705111] [drm] DFP1: INTERNAL_UNIPHY1
[   12.705260] [drm] Connector 2:
[   12.705408] [drm]   VGA-1
[   12.70] [drm]   DDC: 0x6460 0x6460 0x6464 0x6464 0x6468 0x6468 0x646c
0x646c
[   12.705703] [drm]   Encoders:
[   12.705851] [drm] CRT1: INTERNAL_KLDSCP_DAC1
[   12.706045] [drm] Internal thermal controller with fan control
[   12.706343] [drm] radeon: power management initialized
[   13.091252] [drm] fb mappable at 0xE0361000
[   13.091443] [drm] vram apper at 0xE000
[   13.091591] [drm] size 4325376
[   13.091738] [drm] fb depth is 24
[   13.091885] [drm]pitch is 5632
[   13.092233] fbcon: radeondrmfb (fb0) is primary device
[   13.685775] Console: switching to colour frame buffer device 170x48
[   13.690367] radeon :01:00.0: fb0: radeondrmfb frame buffer device
[   13.690403] radeon :01:00.0: registered panic notifier
[   13.690556] [drm] Initialized radeon 2.33.0 20080528 for :01:00.0 on
minor 0

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 61182] r600g causes KWin crashes with kernel 3.8

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=61182

--- Comment #44 from D. Hugh Redelmeier  ---
Jerome Glisse in comment #30:
"Well this is also a kwin bug, kwin should not pick MSAA visual. I fixed cogl
so that it does not pick msaa visual for gnome-shell."

Thanks!

I am (even today) experiencing gnome-shell crashes like this on an up-to-date
fedora 18 (cogl-1.12.2-1.fc18.x86_64).  See my comment #18.  Also in Cinnamon
(untested since that report).

What version of cogl should I look for?  I can add something about this to the
Fedora bug report.

-- 
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/20130423/2840b333/attachment-0001.html>

[Bug 61182] r600g causes KWin crashes with kernel 3.8

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=61182

--- Comment #43 from Fredrik H?glund  ---
(In reply to comment #42)
> As i said in comment 30 it's also a bug of kwin, kwin should not use msaa
> visual for everything ...

I've pushed a patch to the stable branch in KDE that should fix this issue.

-- 
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/20130423/e7f08825/attachment.html>

[Bug 61182] r600g causes KWin crashes with kernel 3.8

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=61182

--- Comment #42 from Jerome Glisse  ---
As i said in comment 30 it's also a bug of kwin, kwin should not use msaa
visual for everything ...

-- 
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/20130423/fb479668/attachment.html>

[Bug 63632] mesa +r600 llvm = segfault

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=63632

--- Comment #6 from Michel Dänzer  ---
Which version of libelf is used in each case? I was running into problems with
the one from http://www.mr511.de/software/ but the one from Fedora's elfutils
works fine. Tom told me on IRC the former requires an additional initialization
step.

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 63762] Team fortress 2 intermittently freezes

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=63762

Pablo  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |INVALID

--- Comment #2 from Pablo  ---
thanks alex,

I have tried this conf by Oibaff ppa

OpenGL vendor string: X.Org
OpenGL renderer string: Gallium 0.4 on AMD RV730
OpenGL version string: 2.1 Mesa 9.2.0 (git-dbb6908 quantal-oibaf-ppa)
OpenGL shading language version string: 1.30

game runs very well... I can guess +30fps at 1680 x 1050.

I will close this case, thanks in advance

-- 
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/20130423/740d6de0/attachment.html>

[Bug 61182] r600g causes KWin crashes with kernel 3.8

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=61182

--- Comment #45 from Emil Velikov  ---
(In reply to comment #44)
> What version of cogl should I look for?  I can add something about this to
> the Fedora bug report.

commit: 93b7b4c850dd928bf21ee168a95641a8d631f713
Author: Jerome Glisse 

glx do not use multisample visual config for front or pixmap

There is no guaranty that glXGetFBConfigs will return fbconfig ordered
with non msaa config first. This patch make sure that non msaa config
get choose.

Present only in the master branch. Mind you I'm not a dev, but I've sent a
request[1] to pull it the 1.12, 1.14 branches. Hope they will pick it up soon

Emil

[1] http://lists.freedesktop.org/archives/cogl/2013-April/001090.html

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 63730] UVD broken on HD5470 by "drm/radeon: raise UVD clocks only on demand"

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=63730

Christian König  changed:

   What|Removed |Added

  Attachment #78323|0   |1
is obsolete||

--- Comment #8 from Christian König  ---
Created attachment 78357
  --> https://bugs.freedesktop.org/attachment.cgi?id=78357&action=edit
Raise UVD clocks while booting the VCPU.

>I've already tested this by myself and can confirm that this fix the problem.

Ok then let's try to narrow this further down. The attached patch should tries
to only raise the clocks while the VCPU is booting.

Please test on your hardware.

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Disabling polling in drm_helper

[Mike Verstegen]

I'm troubleshooting an interesting problem where the i915_hotplug_work_func is 
eating up a lot of time in a couple of kworker threads. The interesting part of 
the problem is that this only happens with one particular model of monitor 
which I haven't gotten to the bottom of yet. But that's not the problem I'm 
trying  to resolve. 

One band-aid for this trouble is to disable the polling in the irq_event
# echo "N" > /sys/module/drm_kms_helper/parameters/poll

That quiets down the kworker threads. Good

To make this survive across boots, I added the following to 
/etc/modprobe/local.conf
options drm_kms_helper poll=N

On reboot, the poll is still enabled
[root at localhost ~]# cat /sys/module/drm_kms_helper/parameters/poll
Y

Looking at the drm_crtc_helper.c I see
void drm_kms_helper_poll_init(struct drm_device *dev)
{
INIT_DELAYED_WORK(&dev->mode_config.output_poll_work, 
output_poll_execute);
dev->mode_config.poll_enabled = true;

drm_kms_helper_poll_enable(dev);
}

If I'm reading that correctly, poll_enable is set to true on initialization 
unconditionally.

Questions:
- Am I using "options drm_kms_helper poll=N" correctly
- Is there a better way to have this option set to false on initialization?

Thanks

Mike

Re: Disabling polling in drm_helper

[Daniel Vetter]

On Tue, Apr 23, 2013 at 01:16:16AM +, Mike Verstegen wrote:
> I'm troubleshooting an interesting problem where the
> i915_hotplug_work_func is eating up a lot of time in a couple of kworker
> threads. The interesting part of the problem is that this only happens
> with one particular model of monitor which I haven't gotten to the
> bottom of yet. But that's not the problem I'm trying  to resolve. 

This should be fixed in latest drm-next. Can you please test that?

> One band-aid for this trouble is to disable the polling in the irq_event
> # echo "N" > /sys/module/drm_kms_helper/parameters/poll
> 
> That quiets down the kworker threads. Good
> 
> To make this survive across boots, I added the following to 
> /etc/modprobe/local.conf
> options drm_kms_helper poll=N
> 
> On reboot, the poll is still enabled
> [root@localhost ~]# cat /sys/module/drm_kms_helper/parameters/poll
> Y
> 
> Looking at the drm_crtc_helper.c I see
> void drm_kms_helper_poll_init(struct drm_device *dev)
> {
> INIT_DELAYED_WORK(&dev->mode_config.output_poll_work, 
> output_poll_execute);
> dev->mode_config.poll_enabled = true;
> 
> drm_kms_helper_poll_enable(dev);
> }
> 
> If I'm reading that correctly, poll_enable is set to true on initialization 
> unconditionally.
> 
> Questions:
> - Am I using "options drm_kms_helper poll=N" correctly
> - Is there a better way to have this option set to false on initialization?

You probably need to rebuild your initrd with your distro tools since
drm_kms_helper is loaded really early.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Radeon UVD firmware missing from linux-firmware tree

[Chí-Thanh Christopher Nguyễn]

Carlos Corbacho  writes:

> Is the updated firmware for UVD support going to make its way at some
point to 
> the linux-firmware tree[0], as I believe this is what most distros currently 
> use to get the Radeon firmware?

It is already there. I think there is the usual caching problem with the
cgit interface.

https://git.kernel.org/cgit/linux/kernel/git/firmware/linux-firmware.git/
doesn't show it while
https://git.kernel.org/cgit/linux/kernel/git/firmware/linux-firmware.git
shows the radeon firmware commits.


Best regards,
Ch?-Thanh Christopher Nguy?n