[PATCH 00/22] new radeon info queries

[Siavash Eliasi]

Hello, are these patches merged yet? or are they on the queue for Linux 
kernel 3.19?

And how they (shader/memory clocks) should be queried?

Thanks!

[PATCH 08/28] gpu: drm: rockchip: drop owner assignment from platform_drivers

[Wolfram Sang]

This platform_driver does not need to set an owner, it will be populated by the
driver core.

Signed-off-by: Wolfram Sang 
---
Generated with coccinelle. SmPL file is in the introductory msg. The big
cleanup was pulled in this merge window. This series catches the bits fallen
through. The patches shall go in via the subsystem trees.

 drivers/gpu/drm/rockchip/rockchip_drm_drv.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_drv.c 
b/drivers/gpu/drm/rockchip/rockchip_drm_drv.c
index a798c7c71f91..771119311d73 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_drv.c
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_drv.c
@@ -537,7 +537,6 @@ static struct platform_driver rockchip_drm_platform_driver 
= {
.probe = rockchip_drm_platform_probe,
.remove = rockchip_drm_platform_remove,
.driver = {
-   .owner = THIS_MODULE,
.name = "rockchip-drm",
.of_match_table = rockchip_drm_dt_ids,
.pm = _drm_pm_ops,
-- 
2.1.3

[PATCH 00/28] remove .owner for most platform_drivers: the missing bits

[Wolfram Sang]

Generated with coccinelle. The big cleanup was pulled in this merge window.
This series catches the bits fallen through. The patches shall go in via the
subsystem trees. If possible for 3.19 to increase consistency I'd say, but you
decide, of course.

cocci-file used:

@match1@
declarer name module_platform_driver;
declarer name module_platform_driver_probe;
declarer name for_each_node_by_type;
identifier __driver;
@@
(
module_platform_driver(__driver);
|
module_platform_driver_probe(__driver, ...);
)

@fix1 depends on match1@
identifier match1.__driver;
@@
static struct platform_driver __driver = {
.driver = {
-   .owner = THIS_MODULE,
}
};

@match2@
identifier __driver;
@@
(
platform_driver_register(&__driver)
|
platform_driver_probe(&__driver, ...)
|
platform_create_bundle(&__driver, ...)
)

@fix2 depends on match2@
identifier match2.__driver;
@@
static struct platform_driver __driver = {
.driver = {
-   .owner = THIS_MODULE,
}
};

Thanks again to Julia Lawall for support. And hey, we fixed a coccinelle bug on
the way :)


Wolfram Sang (28):
  ARM: mach-exynos: drop owner assignment from platform_drivers
  mips: lantiq: xway: drop owner assignment from platform_drivers
  mips: pci: drop owner assignment from platform_drivers
  char: ipmi: drop owner assignment from platform_drivers
  cpufreq: drop owner assignment from platform_drivers
  dma: drop owner assignment from platform_drivers
  gpio: drop owner assignment from platform_drivers
  gpu: drm: rockchip: drop owner assignment from platform_drivers
  iommu: drop owner assignment from platform_drivers
  net: ethernet: stmicro: stmmac: drop owner assignment from
platform_drivers
  net: wireless: ath: ath5k: drop owner assignment from platform_drivers
  of: drop owner assignment from platform_drivers
  pci: host: drop owner assignment from platform_drivers
  phy: drop owner assignment from platform_drivers
  pinctrl: intel: drop owner assignment from platform_drivers
  rtc: drop owner assignment from platform_drivers
  scsi: drop owner assignment from platform_drivers
  thermal: drop owner assignment from platform_drivers
  thermal: int340x_thermal: drop owner assignment from platform_drivers
  tty: serial: 8250: drop owner assignment from platform_drivers
  usb: gadget: udc: bdc: drop owner assignment from platform_drivers
  watchdog: drop owner assignment from platform_drivers
  ASoC: intel: drop owner assignment from platform_drivers
  ASoC: intel: sst: drop owner assignment from platform_drivers
  ASoC: omap: drop owner assignment from platform_drivers
  ASoC: pxa: drop owner assignment from platform_drivers
  ASoC: samsung: drop owner assignment from platform_drivers
  macintosh: drop owner assignment from platform_drivers

 arch/arm/mach-exynos/pmu.c| 1 -
 arch/mips/lantiq/xway/vmmc.c  | 1 -
 arch/mips/pci/pci-ar2315.c| 1 -
 arch/mips/pci/pci-rt2880.c| 1 -
 drivers/char/ipmi/ipmi_powernv.c  | 1 -
 drivers/cpufreq/ls1x-cpufreq.c| 1 -
 drivers/dma/at_xdmac.c| 1 -
 drivers/gpio/gpio-vf610.c | 1 -
 drivers/gpu/drm/rockchip/rockchip_drm_drv.c   | 1 -
 drivers/iommu/rockchip-iommu.c| 1 -
 drivers/macintosh/windfarm_pm112.c| 1 -
 drivers/macintosh/windfarm_pm72.c | 1 -
 drivers/macintosh/windfarm_rm31.c | 1 -
 drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c | 1 -
 drivers/net/wireless/ath/ath5k/ahb.c  | 1 -
 drivers/of/unittest.c | 1 -
 drivers/pci/host/pci-layerscape.c | 1 -
 drivers/phy/phy-armada375-usb2.c  | 1 -
 drivers/phy/phy-berlin-usb.c  | 1 -
 drivers/phy/phy-miphy28lp.c   | 1 -
 drivers/pinctrl/intel/pinctrl-cherryview.c| 1 -
 drivers/rtc/rtc-opal.c| 1 -
 drivers/scsi/atari_scsi.c | 1 -
 drivers/scsi/mac_scsi.c   | 1 -
 drivers/scsi/sun3_scsi.c  | 1 -
 drivers/thermal/int340x_thermal/int3400_thermal.c | 1 -
 drivers/thermal/int340x_thermal/int3402_thermal.c | 1 -
 drivers/thermal/rockchip_thermal.c| 1 -
 drivers/tty/serial/8250/8250_omap.c   | 1 -
 drivers/usb/gadget/udc/bdc/bdc_core.c | 1 -
 drivers/watchdog/cadence_wdt.c| 1 -
 drivers/watchdog/meson_wdt.c  | 1 -
 sound/soc/intel/bytcr_dpcm_rt5640.c   | 1 -
 sound/soc/intel/cht_bsw_rt5672.c  | 1 -
 

[Bug 87568] WebGL can cause GPU reset

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

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

Bug ID: 87568
   Summary: WebGL can cause GPU reset
   Product: Mesa
   Version: 10.3
  Hardware: Other
OS: All
Status: NEW
  Severity: normal
  Priority: medium
 Component: Drivers/Gallium/r600
  Assignee: dri-devel at lists.freedesktop.org
  Reporter: aaalmosss at gmail.com

I was given this link: http://hunger.hu/webgl.html which was supposed to crash
any video driver, and it really did a hiccup. Fortunately, after 1 second the
kernel detected GPU lockup, and reinitialized everything just fine.

As far as I can tell that javascript doesn't do anything sinister, just tries
to render 200k triangles with a single glDrawElements() call. Shouldn't there
be a protection against such simple overflows somewhere?

-- 
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/20141221/a38483ec/attachment.html>

[Bug 85320] [RV630] and [RS880] GPU hangs using UVD hardware acceleration

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

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

Eugene  changed:

   What|Removed |Added

Summary|[RV630] and RS880 GPU hangs |[RV630] and [RS880] GPU
   |using UVD hardware  |hangs using UVD hardware
   |acceleration|acceleration

-- 
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/20141221/8de15b13/attachment.html>

[Bug 85320] [RV630] and RS880 GPU hangs using UVD hardware acceleration

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

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

--- Comment #26 from Eugene  ---
Linux 3.19RC1. Nothing's changed.

-- 
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/20141221/6ddd1805/attachment.html>

[PATCH] gpu: drm: radeon: radeon_device.c: Remove unused function

[Rickard Strandqvist]

Remove the function radeon_doorbell_free() that is not used anywhere.

This was partially found by using a static code analysis program called 
cppcheck.

Signed-off-by: Rickard Strandqvist 
---
 drivers/gpu/drm/radeon/radeon.h|1 -
 drivers/gpu/drm/radeon/radeon_device.c |   14 --
 2 files changed, 15 deletions(-)

diff --git a/drivers/gpu/drm/radeon/radeon.h b/drivers/gpu/drm/radeon/radeon.h
index a9717b3..93e7cfc 100644
--- a/drivers/gpu/drm/radeon/radeon.h
+++ b/drivers/gpu/drm/radeon/radeon.h
@@ -700,7 +700,6 @@ struct radeon_doorbell {
 };

 int radeon_doorbell_get(struct radeon_device *rdev, u32 *page);
-void radeon_doorbell_free(struct radeon_device *rdev, u32 doorbell);

 /*
  * IRQS.
diff --git a/drivers/gpu/drm/radeon/radeon_device.c 
b/drivers/gpu/drm/radeon/radeon_device.c
index ea26769..16a 100644
--- a/drivers/gpu/drm/radeon/radeon_device.c
+++ b/drivers/gpu/drm/radeon/radeon_device.c
@@ -363,20 +363,6 @@ int radeon_doorbell_get(struct radeon_device *rdev, u32 
*doorbell)
}
 }

-/**
- * radeon_doorbell_free - Free a doorbell entry
- *
- * @rdev: radeon_device pointer
- * @doorbell: doorbell index
- *
- * Free a doorbell allocated for use by the driver (all asics)
- */
-void radeon_doorbell_free(struct radeon_device *rdev, u32 doorbell)
-{
-   if (doorbell < rdev->doorbell.num_doorbells)
-   __clear_bit(doorbell, rdev->doorbell.used);
-}
-
 /*
  * radeon_wb_*()
  * Writeback is the the method by which the the GPU updates special pages
-- 
1.7.10.4

[PATCH 1/3] amdkfd: Don't clear *kfd2kgd on kfd_module_init

[Oded Gabbay]

On 12/21/2014 05:57 PM, Christian König wrote:
>> There should be, but when the modules are compiled in, they are loaded based 
>> on
>> link order only, if they are in the same group, and the groups are loaded by 
>> a
>> pre-defined order.
> Is that really still up to date? I've seen effort to change that something 
> like
> 10+ years ago when Rusty reworked the module system. And it is comming up on 
> the
> lists again from time to time.
 From what I can see in the Makefile rules, code and google, yes, that's still 
the situation. If someone will prove me wrong I will be more than happy to 
correct my code.
>
>> I don't want to move iommu before gpu, so I don't have a solution for the
>> order between amdkfd and amd_iommu_v2.
> Why not? That's still better than creating a kernel workqueue, scheduling one
> work item on it, rescheduling the task until everything is completed and you 
> can
> continue.
Because I don't know the consequences of moving an entire subsystem in front of 
another one. In addition, even if everyone agrees, I'm pretty sure that Linus 
won't be happy to do that in -rc stages. So maybe this is something to consider 
for 3.20 merge window, but I would still like to provide a solution for 3.19.

Oded
>
> Christian.
>
> Am 21.12.2014 um 14:24 schrieb Oded Gabbay:
>>
>>
>> On 12/21/2014 03:06 PM, Oded Gabbay wrote:
>>>
>>>
>>> On 12/21/2014 02:19 PM, Christian König wrote:
 Am 21.12.2014 um 12:34 schrieb Oded Gabbay:
>
>
> On 12/21/2014 01:27 PM, Christian König wrote:
>> Am 20.12.2014 um 21:46 schrieb Oded Gabbay:
>>> When amdkfd and radeon are compiled inside the kernel image (not as
>>> modules),
>>> radeon will load before amdkfd and will set *kfd2kgd to its interface
>>> structure. Therefore, we must not set *kfd2kgd to NULL when amdkfd is 
>>> loaded
>>> because it will override radeon's initialization and cause kernel BUG.
>>>
>>> Signed-off-by: Oded Gabbay 
>>
>> You should probably rather fix the dependency between the two modules to
>> get an
>> determined load order instead of doing such nasty workarounds.
>>
>> Christian.
>
> The problem is that when modules are compiled inside the kernel, there is 
> NO
> determined load order and there is no mechanism to enforce that. If there
> is/was such a mechanism, I would of course prefer to use it.

 There should be an determined order based on the symbol use, otherwise
 initializing most of the kernel modules wouldn't work as expected. For 
 example
 radeon depends on the drm module must be loaded before radeon is loaded.
>>> There should be, but when the modules are compiled in, they are loaded 
>>> based on
>>> link order only, if they are in the same group, and the groups are loaded 
>>> by a
>>> pre-defined order.
>>> The groups are: pure, core, postcore, arch, subsys, fs, device (which 
>>> represents
>>> all the modules) and late. See init.h
>>>
>>> So radeon, amdkfd and amd_iommu_v2 are all in device group, and in the group
>>> they are ordered by their link order.
>>>
>>> Yes, radeon loads after drm, because drm*.o are before radeon*.o in the
>>> Makefile. See
>>> http://stackoverflow.com/questions/5669647/linux-order-of-statically-linked-module-loading
>>>
>>>
>>
>> So I tried moving amdkfd inside the Makefile before radeon, and that made
>> amdkfd load before radeon did. This solves my first problem - order between
>> amdkfd and radeon. However, amd_iommu_v2 doesn't belong to the drm Makefile,
>> and I don't want to move iommu before gpu, so I don't have a solution for the
>> order between amdkfd and amd_iommu_v2.
>>
>> Oded
>>>
>>>

>
> Actually, I don't understand why the kernel doesn't enforce the order
> according to the use of exported symbols, like it does with modules.

 Yeah, that's indeed rather strange. There must be something in the amdkfd 
 code
 which broke that somehow.
>>> IMO, that's a far-fetched guess. Could you point to something more specific 
>>> ?
>>>

 As far as I understand you the desired init order is radeon and 
 amd_iommu_v2
 first and then amdkfd, right?
>>> Actually no. The preferred order is amd_iommu_v2, amdkfd and radeon last. 
>>> This
>>> is the order that happens when all three are built as modules. More 
>>> accurately,
>>> radeon inits, but its init triggers amdkfd init, which triggers amd_iommu_v2
>>> init. So before radeon reaches its probe stage, all the modules were
>>> initialized.
>>>
>>> So what happens when you boot with radeon,
 amd_iommu_v2 and amdkfd blacklisted for automatically load and only load 
 amdkfd
 manually?
>>> As said above, that's ok.

> There will always be dependencies between kgd (radeon) and amdkfd and 
> between
> amdkfd and amd_iommu_v2. I don't think I can eliminate those 
> dependencies, not
> without a very complex solution. And the fact 

[Bug 87489] GPU lockup - Sid Meyer's Beyond Earth

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

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

--- Comment #4 from Jacob  ---
After reading through the thread on the steam community page, a user reported
that he could play the game without blackscreens or kernel panics.
Link to post:
http://steamcommunity.com/app/65980/discussions/0/626329820749233064/?tscn=1419181869#c626329820924042305

I upgraded my current Mesa install with another one compiled with LLVM 3.6,
which got rid of the lockups

-- 
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/20141221/fd5ce20e/attachment.html>

[PATCH 2/3] omap: Do not BUG_ON(!spin_is_locked()) on UP

[Bruno Prémont]

On !SMP systems spinlocks do not exist. Thus checking of they
are active will always fail.

Use
  assert_spin_locked(lock);
instead of
  BUG_ON(!spin_is_locked(lock));
to not BUG() on all UP systems.

Signed-off-by: Bruno Prémont 
---
 drivers/gpu/drm/omapdrm/omap_irq.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/omapdrm/omap_irq.c 
b/drivers/gpu/drm/omapdrm/omap_irq.c
index f035d2b..6ca9253 100644
--- a/drivers/gpu/drm/omapdrm/omap_irq.c
+++ b/drivers/gpu/drm/omapdrm/omap_irq.c
@@ -34,7 +34,7 @@ static void omap_irq_update(struct drm_device *dev)
struct omap_drm_irq *irq;
uint32_t irqmask = priv->vblank_mask;

-   BUG_ON(!spin_is_locked(_lock));
+   assert_spin_locked(_lock));

list_for_each_entry(irq, >irq_list, node)
irqmask |= irq->irqmask;
-- 
1.8.1.5

[PATCH 3/3] msm: Do not BUG_ON(!spin_is_locked()) on UP

[Bruno Prémont]

On !SMP systems spinlocks do not exist. Thus checking of they
are active will always fail.

Use
  assert_spin_locked(lock);
instead of
  BUG_ON(!spin_is_locked(lock));
to not BUG() on all UP systems.

Signed-off-by: Bruno Prémont 
---
 drivers/gpu/drm/msm/mdp/mdp_kms.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/msm/mdp/mdp_kms.c 
b/drivers/gpu/drm/msm/mdp/mdp_kms.c
index 03455b6..f5e2173 100644
--- a/drivers/gpu/drm/msm/mdp/mdp_kms.c
+++ b/drivers/gpu/drm/msm/mdp/mdp_kms.c
@@ -34,7 +34,7 @@ static void update_irq(struct mdp_kms *mdp_kms)
struct mdp_irq *irq;
uint32_t irqmask = mdp_kms->vblank_mask;

-   BUG_ON(!spin_is_locked(_lock));
+   assert_spin_locked(_lock));

list_for_each_entry(irq, _kms->irq_list, node)
irqmask |= irq->irqmask;
-- 
1.8.1.5

[PATCH 1/3] nouveau: Do not BUG_ON(!spin_is_locked()) on UP

[Bruno Prémont]

On !SMP systems spinlocks do not exist. Thus checking of they
are active will always fail.

Use
  assert_spin_locked(lock);
instead of
  BUG_ON(!spin_is_locked(lock));
to not BUG() on all UP systems.

Signed-off-by: Bruno Prémont 
---
See also fdo bug #87552

 drivers/gpu/drm/nouveau/core/core/event.c  | 4 ++--
 drivers/gpu/drm/nouveau/core/core/notify.c | 2 +-
 2 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/nouveau/core/core/event.c 
b/drivers/gpu/drm/nouveau/core/core/event.c
index ff2b434..760947e 100644
--- a/drivers/gpu/drm/nouveau/core/core/event.c
+++ b/drivers/gpu/drm/nouveau/core/core/event.c
@@ -26,7 +26,7 @@
 void
 nvkm_event_put(struct nvkm_event *event, u32 types, int index)
 {
-   BUG_ON(!spin_is_locked(>refs_lock));
+   assert_spin_locked(>refs_lock);
while (types) {
int type = __ffs(types); types &= ~(1 << type);
if (--event->refs[index * event->types_nr + type] == 0) {
@@ -39,7 +39,7 @@ nvkm_event_put(struct nvkm_event *event, u32 types, int index)
 void
 nvkm_event_get(struct nvkm_event *event, u32 types, int index)
 {
-   BUG_ON(!spin_is_locked(>refs_lock));
+   assert_spin_locked(>refs_lock);
while (types) {
int type = __ffs(types); types &= ~(1 << type);
if (++event->refs[index * event->types_nr + type] == 1) {
diff --git a/drivers/gpu/drm/nouveau/core/core/notify.c 
b/drivers/gpu/drm/nouveau/core/core/notify.c
index d1bcde5..839a325 100644
--- a/drivers/gpu/drm/nouveau/core/core/notify.c
+++ b/drivers/gpu/drm/nouveau/core/core/notify.c
@@ -98,7 +98,7 @@ nvkm_notify_send(struct nvkm_notify *notify, void *data, u32 
size)
struct nvkm_event *event = notify->event;
unsigned long flags;

-   BUG_ON(!spin_is_locked(>list_lock));
+   assert_spin_locked(>list_lock);
BUG_ON(size != notify->size);

spin_lock_irqsave(>refs_lock, flags);
-- 
1.8.1.5

[PATCH 1/3] amdkfd: Don't clear *kfd2kgd on kfd_module_init

[Christian König]

Am 21.12.2014 um 17:03 schrieb Oded Gabbay:
>
>
> On 12/21/2014 05:57 PM, Christian König wrote:
>>> There should be, but when the modules are compiled in, they are 
>>> loaded based on
>>> link order only, if they are in the same group, and the groups are 
>>> loaded by a
>>> pre-defined order.
>> Is that really still up to date? I've seen effort to change that 
>> something like
>> 10+ years ago when Rusty reworked the module system. And it is 
>> comming up on the
>> lists again from time to time.
> From what I can see in the Makefile rules, code and google, yes, 
> that's still the situation. If someone will prove me wrong I will be 
> more than happy to correct my code.
>>
>>> I don't want to move iommu before gpu, so I don't have a solution 
>>> for the
>>> order between amdkfd and amd_iommu_v2.
>> Why not? That's still better than creating a kernel workqueue, 
>> scheduling one
>> work item on it, rescheduling the task until everything is completed 
>> and you can
>> continue.
> Because I don't know the consequences of moving an entire subsystem in 
> front of another one. In addition, even if everyone agrees, I'm pretty 
> sure that Linus won't be happy to do that in -rc stages. So maybe this 
> is something to consider for 3.20 merge window, but I would still like 
> to provide a solution for 3.19.

Yeah, true indeed. How about depending on everything being compiled as 
module for 3.19 then? Still better than having such a hack in the driver 
for as a temporary workaround for one release.

Christian.

>
> Oded
>>
>> Christian.
>>
>> Am 21.12.2014 um 14:24 schrieb Oded Gabbay:
>>>
>>>
>>> On 12/21/2014 03:06 PM, Oded Gabbay wrote:


 On 12/21/2014 02:19 PM, Christian König wrote:
> Am 21.12.2014 um 12:34 schrieb Oded Gabbay:
>>
>>
>> On 12/21/2014 01:27 PM, Christian König wrote:
>>> Am 20.12.2014 um 21:46 schrieb Oded Gabbay:
 When amdkfd and radeon are compiled inside the kernel image 
 (not as
 modules),
 radeon will load before amdkfd and will set *kfd2kgd to its 
 interface
 structure. Therefore, we must not set *kfd2kgd to NULL when 
 amdkfd is loaded
 because it will override radeon's initialization and cause 
 kernel BUG.

 Signed-off-by: Oded Gabbay 
>>>
>>> You should probably rather fix the dependency between the two 
>>> modules to
>>> get an
>>> determined load order instead of doing such nasty workarounds.
>>>
>>> Christian.
>>
>> The problem is that when modules are compiled inside the kernel, 
>> there is NO
>> determined load order and there is no mechanism to enforce that. 
>> If there
>> is/was such a mechanism, I would of course prefer to use it.
>
> There should be an determined order based on the symbol use, 
> otherwise
> initializing most of the kernel modules wouldn't work as expected. 
> For example
> radeon depends on the drm module must be loaded before radeon is 
> loaded.
 There should be, but when the modules are compiled in, they are 
 loaded based on
 link order only, if they are in the same group, and the groups are 
 loaded by a
 pre-defined order.
 The groups are: pure, core, postcore, arch, subsys, fs, device 
 (which represents
 all the modules) and late. See init.h

 So radeon, amdkfd and amd_iommu_v2 are all in device group, and in 
 the group
 they are ordered by their link order.

 Yes, radeon loads after drm, because drm*.o are before radeon*.o in 
 the
 Makefile. See
 http://stackoverflow.com/questions/5669647/linux-order-of-statically-linked-module-loading
  



>>>
>>> So I tried moving amdkfd inside the Makefile before radeon, and that 
>>> made
>>> amdkfd load before radeon did. This solves my first problem - order 
>>> between
>>> amdkfd and radeon. However, amd_iommu_v2 doesn't belong to the drm 
>>> Makefile,
>>> and I don't want to move iommu before gpu, so I don't have a 
>>> solution for the
>>> order between amdkfd and amd_iommu_v2.
>>>
>>> Oded


>
>>
>> Actually, I don't understand why the kernel doesn't enforce the 
>> order
>> according to the use of exported symbols, like it does with modules.
>
> Yeah, that's indeed rather strange. There must be something in the 
> amdkfd code
> which broke that somehow.
 IMO, that's a far-fetched guess. Could you point to something more 
 specific ?

>
> As far as I understand you the desired init order is radeon and 
> amd_iommu_v2
> first and then amdkfd, right?
 Actually no. The preferred order is amd_iommu_v2, amdkfd and radeon 
 last. This
 is the order that happens when all three are built as modules. More 
 accurately,
 radeon inits, but its init triggers amdkfd init, which triggers 
 amd_iommu_v2
 init. So 

[PATCH 1/3] amdkfd: Don't clear *kfd2kgd on kfd_module_init

[Christian König]

> There should be, but when the modules are compiled in, they are loaded 
> based on
> link order only, if they are in the same group, and the groups are 
> loaded by a
> pre-defined order. 
Is that really still up to date? I've seen effort to change that 
something like 10+ years ago when Rusty reworked the module system. And 
it is comming up on the lists again from time to time.

> I don't want to move iommu before gpu, so I don't have a solution for 
> the order between amdkfd and amd_iommu_v2. 
Why not? That's still better than creating a kernel workqueue, 
scheduling one work item on it, rescheduling the task until everything 
is completed and you can continue.

Christian.

Am 21.12.2014 um 14:24 schrieb Oded Gabbay:
>
>
> On 12/21/2014 03:06 PM, Oded Gabbay wrote:
>>
>>
>> On 12/21/2014 02:19 PM, Christian König wrote:
>>> Am 21.12.2014 um 12:34 schrieb Oded Gabbay:


 On 12/21/2014 01:27 PM, Christian König wrote:
> Am 20.12.2014 um 21:46 schrieb Oded Gabbay:
>> When amdkfd and radeon are compiled inside the kernel image (not 
>> as modules),
>> radeon will load before amdkfd and will set *kfd2kgd to its 
>> interface
>> structure. Therefore, we must not set *kfd2kgd to NULL when 
>> amdkfd is loaded
>> because it will override radeon's initialization and cause kernel 
>> BUG.
>>
>> Signed-off-by: Oded Gabbay 
>
> You should probably rather fix the dependency between the two 
> modules to get an
> determined load order instead of doing such nasty workarounds.
>
> Christian.

 The problem is that when modules are compiled inside the kernel, 
 there is NO
 determined load order and there is no mechanism to enforce that. If 
 there
 is/was such a mechanism, I would of course prefer to use it.
>>>
>>> There should be an determined order based on the symbol use, otherwise
>>> initializing most of the kernel modules wouldn't work as expected. 
>>> For example
>>> radeon depends on the drm module must be loaded before radeon is 
>>> loaded.
>> There should be, but when the modules are compiled in, they are 
>> loaded based on
>> link order only, if they are in the same group, and the groups are 
>> loaded by a
>> pre-defined order.
>> The groups are: pure, core, postcore, arch, subsys, fs, device (which 
>> represents
>> all the modules) and late. See init.h
>>
>> So radeon, amdkfd and amd_iommu_v2 are all in device group, and in 
>> the group
>> they are ordered by their link order.
>>
>> Yes, radeon loads after drm, because drm*.o are before radeon*.o in the
>> Makefile. See
>> http://stackoverflow.com/questions/5669647/linux-order-of-statically-linked-module-loading
>>  
>>
>>
>
> So I tried moving amdkfd inside the Makefile before radeon, and that 
> made amdkfd load before radeon did. This solves my first problem - 
> order between amdkfd and radeon. However, amd_iommu_v2 doesn't belong 
> to the drm Makefile, and I don't want to move iommu before gpu, so I 
> don't have a solution for the order between amdkfd and amd_iommu_v2.
>
> Oded
>>
>>
>>>

 Actually, I don't understand why the kernel doesn't enforce the order
 according to the use of exported symbols, like it does with modules.
>>>
>>> Yeah, that's indeed rather strange. There must be something in the 
>>> amdkfd code
>>> which broke that somehow.
>> IMO, that's a far-fetched guess. Could you point to something more 
>> specific ?
>>
>>>
>>> As far as I understand you the desired init order is radeon and 
>>> amd_iommu_v2
>>> first and then amdkfd, right?
>> Actually no. The preferred order is amd_iommu_v2, amdkfd and radeon 
>> last. This
>> is the order that happens when all three are built as modules. More 
>> accurately,
>> radeon inits, but its init triggers amdkfd init, which triggers 
>> amd_iommu_v2
>> init. So before radeon reaches its probe stage, all the modules were 
>> initialized.
>>
>> So what happens when you boot with radeon,
>>> amd_iommu_v2 and amdkfd blacklisted for automatically load and only 
>>> load amdkfd
>>> manually?
>> As said above, that's ok.
>>>
 There will always be dependencies between kgd (radeon) and amdkfd 
 and between
 amdkfd and amd_iommu_v2. I don't think I can eliminate those 
 dependencies, not
 without a very complex solution. And the fact that this complex 
 solution
 occurs only in a very specific use case (all modules compiled in), 
 makes me
 less inclined to do that.

 So I don't see it as a "nasty workaround". I would call it just a 
 "workaround"
 for a specific use case, which should be solved by a generic 
 solution to the
 kernel enforcing load orders.
>>>
>>> The normal kernel module handling already should provide the correct 
>>> init order,
>>> so I would still call this a rather nasty workaround because we 
>>> couldn't find
>>> the underlying problem.
>> Well, the normal kernel module handling doesn't 

[PATCH] imx-drm: core: handling of DI clock flags to ipu_crtc_mode_set()

[Russell King]

We do not need to track the state of the IPU DI's clock flags by having
each display bridge calling back into imx-drm-core, and then back out
into ipuv3-crtc.c.

ipuv3-crtc can instead just scan the list of encoders to retrieve their
type, and build up a picture of which types of encoders are attached.
We can then use this information to configure the IPU DI clocking mode
without any uncertainty - if we have multiple bridges connected to the
same DI, if one of them requires a synchronous DI clock, that's what we
must use.

Signed-off-by: Russell King 
---
This is a clean-up which I've had sitting around for some time, but
which I think would be useful to get into mainline at some point
(maybe 3.20?)

 drivers/gpu/drm/imx/imx-drm-core.c |  3 +--
 drivers/gpu/drm/imx/imx-drm.h  |  2 +-
 drivers/gpu/drm/imx/ipuv3-crtc.c   | 40 ++
 3 files changed, 25 insertions(+), 20 deletions(-)

diff --git a/drivers/gpu/drm/imx/imx-drm-core.c 
b/drivers/gpu/drm/imx/imx-drm-core.c
index b250130debc8..1a10d042070f 100644
--- a/drivers/gpu/drm/imx/imx-drm-core.c
+++ b/drivers/gpu/drm/imx/imx-drm-core.c
@@ -116,8 +116,7 @@ int imx_drm_panel_format_pins(struct drm_encoder *encoder,
helper = _crtc->imx_drm_helper_funcs;
if (helper->set_interface_pix_fmt)
return helper->set_interface_pix_fmt(encoder->crtc,
-   encoder->encoder_type, interface_pix_fmt,
-   hsync_pin, vsync_pin);
+   interface_pix_fmt, hsync_pin, vsync_pin);
return 0;
 }
 EXPORT_SYMBOL_GPL(imx_drm_panel_format_pins);
diff --git a/drivers/gpu/drm/imx/imx-drm.h b/drivers/gpu/drm/imx/imx-drm.h
index 7453ae00c412..3c559ccd6af0 100644
--- a/drivers/gpu/drm/imx/imx-drm.h
+++ b/drivers/gpu/drm/imx/imx-drm.h
@@ -17,7 +17,7 @@ int imx_drm_crtc_id(struct imx_drm_crtc *crtc);
 struct imx_drm_crtc_helper_funcs {
int (*enable_vblank)(struct drm_crtc *crtc);
void (*disable_vblank)(struct drm_crtc *crtc);
-   int (*set_interface_pix_fmt)(struct drm_crtc *crtc, u32 encoder_type,
+   int (*set_interface_pix_fmt)(struct drm_crtc *crtc,
u32 pix_fmt, int hsync_pin, int vsync_pin);
const struct drm_crtc_helper_funcs *crtc_helper_funcs;
const struct drm_crtc_funcs *crtc_funcs;
diff --git a/drivers/gpu/drm/imx/ipuv3-crtc.c b/drivers/gpu/drm/imx/ipuv3-crtc.c
index ebee59cb96d8..3f2c146620a8 100644
--- a/drivers/gpu/drm/imx/ipuv3-crtc.c
+++ b/drivers/gpu/drm/imx/ipuv3-crtc.c
@@ -46,7 +46,6 @@ struct ipu_crtc {
struct drm_framebuffer  *newfb;
int irq;
u32 interface_pix_fmt;
-   unsigned long   di_clkflags;
int di_hsync_pin;
int di_vsync_pin;
 };
@@ -141,16 +140,37 @@ static int ipu_crtc_mode_set(struct drm_crtc *crtc,
   int x, int y,
   struct drm_framebuffer *old_fb)
 {
+   struct drm_device *dev = crtc->dev;
+   struct drm_encoder *encoder;
struct ipu_crtc *ipu_crtc = to_ipu_crtc(crtc);
-   int ret;
struct ipu_di_signal_cfg sig_cfg = {};
+   unsigned long encoder_types = 0;
u32 out_pixel_fmt;
+   int ret;

dev_dbg(ipu_crtc->dev, "%s: mode->hdisplay: %d\n", __func__,
mode->hdisplay);
dev_dbg(ipu_crtc->dev, "%s: mode->vdisplay: %d\n", __func__,
mode->vdisplay);

+   list_for_each_entry(encoder, >mode_config.encoder_list, head)
+   if (encoder->crtc == crtc)
+   encoder_types |= BIT(encoder->encoder_type);
+
+   dev_dbg(ipu_crtc->dev, "%s: attached to encoder types 0x%lx\n",
+   __func__, encoder_types);
+
+   /*
+* If we have DAC, TVDAC or LDB, then we need the IPU DI clock
+* to be the same as the LDB DI clock.
+*/
+   if (encoder_types & (BIT(DRM_MODE_ENCODER_DAC) | 
+BIT(DRM_MODE_ENCODER_TVDAC) |
+BIT(DRM_MODE_ENCODER_LVDS)))
+   sig_cfg.clkflags = IPU_DI_CLKMODE_SYNC | IPU_DI_CLKMODE_EXT;
+   else
+   sig_cfg.clkflags = 0;
+
out_pixel_fmt = ipu_crtc->interface_pix_fmt;

if (mode->flags & DRM_MODE_FLAG_INTERLACE)
@@ -173,7 +193,6 @@ static int ipu_crtc_mode_set(struct drm_crtc *crtc,
sig_cfg.v_sync_width = mode->vsync_end - mode->vsync_start;
sig_cfg.v_end_width = mode->vsync_start - mode->vdisplay;
sig_cfg.pixelclock = mode->clock * 1000;
-   sig_cfg.clkflags = ipu_crtc->di_clkflags;

sig_cfg.v_to_h_sync = 0;

@@ -275,7 +294,7 @@ static void ipu_disable_vblank(struct drm_crtc *crtc)
ipu_crtc->newfb = NULL;
 }

-static int ipu_set_interface_pix_fmt(struct drm_crtc *crtc, u32 encoder_type,
+static int 

[PATCH 1/3] amdkfd: Don't clear *kfd2kgd on kfd_module_init

[Oded Gabbay]

On 12/21/2014 03:06 PM, Oded Gabbay wrote:
>
>
> On 12/21/2014 02:19 PM, Christian König wrote:
>> Am 21.12.2014 um 12:34 schrieb Oded Gabbay:
>>>
>>>
>>> On 12/21/2014 01:27 PM, Christian König wrote:
 Am 20.12.2014 um 21:46 schrieb Oded Gabbay:
> When amdkfd and radeon are compiled inside the kernel image (not as 
> modules),
> radeon will load before amdkfd and will set *kfd2kgd to its interface
> structure. Therefore, we must not set *kfd2kgd to NULL when amdkfd is 
> loaded
> because it will override radeon's initialization and cause kernel BUG.
>
> Signed-off-by: Oded Gabbay 

 You should probably rather fix the dependency between the two modules to 
 get an
 determined load order instead of doing such nasty workarounds.

 Christian.
>>>
>>> The problem is that when modules are compiled inside the kernel, there is NO
>>> determined load order and there is no mechanism to enforce that. If there
>>> is/was such a mechanism, I would of course prefer to use it.
>>
>> There should be an determined order based on the symbol use, otherwise
>> initializing most of the kernel modules wouldn't work as expected. For 
>> example
>> radeon depends on the drm module must be loaded before radeon is loaded.
> There should be, but when the modules are compiled in, they are loaded based 
> on
> link order only, if they are in the same group, and the groups are loaded by a
> pre-defined order.
> The groups are: pure, core, postcore, arch, subsys, fs, device (which 
> represents
> all the modules) and late. See init.h
>
> So radeon, amdkfd and amd_iommu_v2 are all in device group, and in the group
> they are ordered by their link order.
>
> Yes, radeon loads after drm, because drm*.o are before radeon*.o in the
> Makefile. See
> http://stackoverflow.com/questions/5669647/linux-order-of-statically-linked-module-loading
>

So I tried moving amdkfd inside the Makefile before radeon, and that made 
amdkfd 
load before radeon did. This solves my first problem - order between amdkfd and 
radeon. However, amd_iommu_v2 doesn't belong to the drm Makefile, and I don't 
want to move iommu before gpu, so I don't have a solution for the order between 
amdkfd and amd_iommu_v2.

Oded
>
>
>>
>>>
>>> Actually, I don't understand why the kernel doesn't enforce the order
>>> according to the use of exported symbols, like it does with modules.
>>
>> Yeah, that's indeed rather strange. There must be something in the amdkfd 
>> code
>> which broke that somehow.
> IMO, that's a far-fetched guess. Could you point to something more specific ?
>
>>
>> As far as I understand you the desired init order is radeon and amd_iommu_v2
>> first and then amdkfd, right?
> Actually no. The preferred order is amd_iommu_v2, amdkfd and radeon last. This
> is the order that happens when all three are built as modules. More 
> accurately,
> radeon inits, but its init triggers amdkfd init, which triggers amd_iommu_v2
> init. So before radeon reaches its probe stage, all the modules were 
> initialized.
>
> So what happens when you boot with radeon,
>> amd_iommu_v2 and amdkfd blacklisted for automatically load and only load 
>> amdkfd
>> manually?
> As said above, that's ok.
>>
>>> There will always be dependencies between kgd (radeon) and amdkfd and 
>>> between
>>> amdkfd and amd_iommu_v2. I don't think I can eliminate those dependencies, 
>>> not
>>> without a very complex solution. And the fact that this complex solution
>>> occurs only in a very specific use case (all modules compiled in), makes me
>>> less inclined to do that.
>>>
>>> So I don't see it as a "nasty workaround". I would call it just a 
>>> "workaround"
>>> for a specific use case, which should be solved by a generic solution to the
>>> kernel enforcing load orders.
>>
>> The normal kernel module handling already should provide the correct init 
>> order,
>> so I would still call this a rather nasty workaround because we couldn't find
>> the underlying problem.
> Well, the normal kernel module handling doesn't work when all modules are
> compiled in. I'm not a huge expert on this issue so I had Joerg Roedel help me
> analyze this (thanks Joerg) and he agreed that there is no enforcement of 
> order
> in this case.
>
>>
>> Christian.
>>
>>>
>>> Oded

> ---
>   drivers/gpu/drm/amd/amdkfd/kfd_module.c | 5 ++---
>   1 file changed, 2 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/amdkfd/kfd_module.c
> b/drivers/gpu/drm/amd/amdkfd/kfd_module.c
> index 95d5af1..236562f 100644
> --- a/drivers/gpu/drm/amd/amdkfd/kfd_module.c
> +++ b/drivers/gpu/drm/amd/amdkfd/kfd_module.c
> @@ -34,7 +34,7 @@
>   #define KFD_DRIVER_MINOR7
>   #define KFD_DRIVER_PATCHLEVEL0
> -const struct kfd2kgd_calls *kfd2kgd;
> +const struct kfd2kgd_calls *kfd2kgd = NULL;
>   static const struct kgd2kfd_calls kgd2kfd = {
>   .exit= kgd2kfd_exit,
>  

[PATCH 1/3] amdkfd: Don't clear *kfd2kgd on kfd_module_init

[Oded Gabbay]

On 12/21/2014 02:19 PM, Christian König wrote:
> Am 21.12.2014 um 12:34 schrieb Oded Gabbay:
>>
>>
>> On 12/21/2014 01:27 PM, Christian König wrote:
>>> Am 20.12.2014 um 21:46 schrieb Oded Gabbay:
 When amdkfd and radeon are compiled inside the kernel image (not as 
 modules),
 radeon will load before amdkfd and will set *kfd2kgd to its interface
 structure. Therefore, we must not set *kfd2kgd to NULL when amdkfd is 
 loaded
 because it will override radeon's initialization and cause kernel BUG.

 Signed-off-by: Oded Gabbay 
>>>
>>> You should probably rather fix the dependency between the two modules to 
>>> get an
>>> determined load order instead of doing such nasty workarounds.
>>>
>>> Christian.
>>
>> The problem is that when modules are compiled inside the kernel, there is NO
>> determined load order and there is no mechanism to enforce that. If there
>> is/was such a mechanism, I would of course prefer to use it.
>
> There should be an determined order based on the symbol use, otherwise
> initializing most of the kernel modules wouldn't work as expected. For example
> radeon depends on the drm module must be loaded before radeon is loaded.
There should be, but when the modules are compiled in, they are loaded based on 
link order only, if they are in the same group, and the groups are loaded by a 
pre-defined order.
The groups are: pure, core, postcore, arch, subsys, fs, device (which 
represents 
all the modules) and late. See init.h

So radeon, amdkfd and amd_iommu_v2 are all in device group, and in the group 
they are ordered by their link order.

Yes, radeon loads after drm, because drm*.o are before radeon*.o in the 
Makefile. See 
http://stackoverflow.com/questions/5669647/linux-order-of-statically-linked-module-loading


>
>>
>> Actually, I don't understand why the kernel doesn't enforce the order
>> according to the use of exported symbols, like it does with modules.
>
> Yeah, that's indeed rather strange. There must be something in the amdkfd code
> which broke that somehow.
IMO, that's a far-fetched guess. Could you point to something more specific ?

>
> As far as I understand you the desired init order is radeon and amd_iommu_v2
> first and then amdkfd, right?
Actually no. The preferred order is amd_iommu_v2, amdkfd and radeon last. This 
is the order that happens when all three are built as modules. More accurately, 
radeon inits, but its init triggers amdkfd init, which triggers amd_iommu_v2 
init. So before radeon reaches its probe stage, all the modules were 
initialized.

So what happens when you boot with radeon,
> amd_iommu_v2 and amdkfd blacklisted for automatically load and only load 
> amdkfd
> manually?
As said above, that's ok.
>
>> There will always be dependencies between kgd (radeon) and amdkfd and between
>> amdkfd and amd_iommu_v2. I don't think I can eliminate those dependencies, 
>> not
>> without a very complex solution. And the fact that this complex solution
>> occurs only in a very specific use case (all modules compiled in), makes me
>> less inclined to do that.
>>
>> So I don't see it as a "nasty workaround". I would call it just a 
>> "workaround"
>> for a specific use case, which should be solved by a generic solution to the
>> kernel enforcing load orders.
>
> The normal kernel module handling already should provide the correct init 
> order,
> so I would still call this a rather nasty workaround because we couldn't find
> the underlying problem.
Well, the normal kernel module handling doesn't work when all modules are 
compiled in. I'm not a huge expert on this issue so I had Joerg Roedel help me 
analyze this (thanks Joerg) and he agreed that there is no enforcement of order 
in this case.

>
> Christian.
>
>>
>> Oded
>>>
 ---
   drivers/gpu/drm/amd/amdkfd/kfd_module.c | 5 ++---
   1 file changed, 2 insertions(+), 3 deletions(-)

 diff --git a/drivers/gpu/drm/amd/amdkfd/kfd_module.c
 b/drivers/gpu/drm/amd/amdkfd/kfd_module.c
 index 95d5af1..236562f 100644
 --- a/drivers/gpu/drm/amd/amdkfd/kfd_module.c
 +++ b/drivers/gpu/drm/amd/amdkfd/kfd_module.c
 @@ -34,7 +34,7 @@
   #define KFD_DRIVER_MINOR7
   #define KFD_DRIVER_PATCHLEVEL0
 -const struct kfd2kgd_calls *kfd2kgd;
 +const struct kfd2kgd_calls *kfd2kgd = NULL;
   static const struct kgd2kfd_calls kgd2kfd = {
   .exit= kgd2kfd_exit,
   .probe= kgd2kfd_probe,
 @@ -84,14 +84,13 @@ EXPORT_SYMBOL(kgd2kfd_init);
   void kgd2kfd_exit(void)
   {
 +kfd2kgd = NULL;
   }
   static int __init kfd_module_init(void)
   {
   int err;
 -kfd2kgd = NULL;
 -
   /* Verify module parameters */
   if ((sched_policy < KFD_SCHED_POLICY_HWS) ||
   (sched_policy > KFD_SCHED_POLICY_NO_HWS)) {
>>>
>

[RFC PATCH v3 4/4] tests/drv_module_reload: add ipvr support

[Cheng, Yao]

> -Original Message-
> From: Daniel Vetter [mailto:daniel.vetter at ffwll.ch]
> Sent: Thursday, December 18, 2014 19:21
> To: Thierry Reding
> Cc: Cheng, Yao; intel-gfx at lists.freedesktop.org; dri-
> devel at lists.freedesktop.org; Kelley, Sean V; Chehab, John;
> emil.l.velikov at gmail.com; Jiang, Fei
> Subject: Re: [RFC PATCH v3 4/4] tests/drv_module_reload: add ipvr support
> 
> On Thu, Dec 18, 2014 at 11:04 AM, Thierry Reding 
> wrote:
> >> I double checked the symptom and found it was a deadlock on
> drm_global_mutex.
> >> When i915_driver_load() registers the platform device while ipvr module
> is in the system, ipvr's probe() function tries to lock drm_global_mutex which
> was already held by i915.
> >> I think either of the following 2 actions need to be moved to a bottom half
> e.g. a work queue:
> >>   platform_device_add () call in i915_ved.c (called during
> i915_driver_load())
> >>   drm_dev_register() call during ipvr's probe() Which one makes
> >> more sense? pls kindly advise (I personally prefer the former one.).
> >
> > Yes, that's somewhat ugly, but I don't see a way around that. I'd also
> > think that moving platform_device_add() to a workqueue would be the
> > best option here.
> 
> Or we simply kill drm_global_mutex for platform drivers that don't use the -
> >probe hook. It should work when they have a correct order betwen
> drm_dev_alloc and _register and all the code in between. So just ditch the -
> >load callback in teh ipvr driver and rework the load sequence as suggested
> somewhere else and this is fixed already. No need for bottom halfs I think.

Daniel, sorry I didn't quite understand "platform drivers that don't use the 
probe hook". For initialization, the ipvr platform driver's probe() is called 
in following 2 possible paths:
1. ipvr installed before i915. In this case, ipvr's probe() is called inside 
i915_driver_load() and falls into the drm_global_mutex dead lock.
2. i915 installed before ipvr. In this case, ipvr's probe() is called without 
drm_global_mutex held by i915 and no dead lock issue.
If we kill drm_global_mutex, will path 2 run into issue? And in your 
suggestion, how to rework the load sequence? Do you mean calling ipvr's load() 
callback directly during platform driver probe()?

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

[Bug 87553] system boot hangs at drm initialization

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

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

--- Comment #2 from d.lecardez at gmail.com ---
HP Laptop hp dv6 with ATI Mobility Radeon HD 5000 Series

When I boot fc21, 90% of the times, it hangs at screen mmessage:

[drm] Loading REDWOOD microcode

For the remaining 10% everything works fine.

This sympthom appeared in fc19 starting with kernels 3.10.X and has always been
present in fc20 inany versions.

One of the workaround is to boot in 'nomodeset' then manualy perform a
'modprobe radeon modeset=1'

Full trace as attachment.

Most of the time this solves the problem, but sometimes it also fails.
In this situation, as I'm already booted, I can get traces in /var/log/messages
ThiDec 19 20:05:19 localhost kernel: [  153.615554] Call Trace:
Dec 19 20:05:19 localhost kernel: [  153.615799]  [] ?
radeon_ring_lock+0x2e/0x50 [radeon]
Dec 19 20:05:19 localhost kernel: [  153.616047]  []
uvd_v1_0_ring_test+0x4e/0x150 [radeon]
Dec 19 20:05:19 localhost kernel: [  153.616272]  [] ?
__const_udelay+0x1e/0x20
Dec 19 20:05:19 localhost kernel: [  153.616520]  [] ?
uvd_v1_0_start+0x1ea/0x380 [radeon]
Dec 19 20:05:19 localhost kernel: [  153.616770]  []
uvd_v1_0_init+0x9a/0x190 [radeon]
Dec 19 20:05:19 localhost kernel: [  153.617024]  []
evergreen_startup+0x1b0e/0x1b20 [radeon]
Dec 19 20:05:19 localhost kernel: [  153.617278]  []
evergreen_init+0x1c5/0x370 [radeon]
Dec 19 20:05:19 localhost kernel: [  153.617525]  []
radeon_device_init+0x924/0xaf0 [radeon]
Dec 19 20:05:19 localhost kernel: [  153.617769]  [] ?
cail_mc_write+0x20/0x20 [radeon]
Dec 19 20:05:19 localhost kernel: [  153.618010]  []
radeon_driver_load_kms+0x8a/0x1f0 [radeon]
Dec 19 20:05:19 localhost kernel: [  153.618359]  []
drm_dev_register+0x8e/0xd0 [drm]
Dec 19 20:05:19 localhost kernel: [  153.618599]  []
drm_get_pci_dev+0x79/0x1c0 [drm]
Dec 19 20:05:19 localhost kernel: [  153.618821]  [] ?
kmem_cache_alloc_trace+0x195/0x1c0
Dec 19 20:05:19 localhost kernel: [  153.619068]  [] ?
radeon_pci_probe+0x6e/0xa0 [radeon]
Dec 19 20:05:19 localhost kernel: [  153.619309]  []
radeon_pci_probe+0x7c/0xa0 [radeon]
Dec 19 20:05:19 localhost kernel: [  153.619533]  []
pci_device_probe+0x6f/0xd0
Dec 19 20:05:19 localhost kernel: [  153.619755]  [] ?
sysfs_create_link+0x25/0x50
Dec 19 20:05:19 localhost kernel: [  153.619975]  []
driver_probe_device+0x93/0x3b0
Dec 19 20:05:19 localhost kernel: [  153.620198]  [] ?
sysfs_create_dir_ns+0x37/0x90
Dec 19 20:05:19 localhost kernel: [  153.620421]  [] ?
pci_match_device+0xc1/0xe0
Dec 19 20:05:19 localhost kernel: [  153.620638]  []
__driver_attach+0x79/0x80
Dec 19 20:05:19 localhost kernel: [  153.620859]  [] ?
__device_attach+0x40/0x40
Dec 19 20:05:19 localhost kernel: [  153.621075]  []
bus_for_each_dev+0x57/0xa0
Dec 19 20:05:19 localhost kernel: [  153.621322]  []
driver_attach+0x1e/0x20
Dec 19 20:05:19 localhost kernel: [  153.621548]  [] ?
__device_attach+0x40/0x40
Dec 19 20:05:19 localhost kernel: [  153.621769]  []
bus_add_driver+0x167/0x240
Dec 19 20:05:19 localhost kernel: [  153.621990]  [] ? 0xf9f92000
Dec 19 20:05:19 localhost kernel: [  153.622210]  [] ? 0xf9f92000
Dec 19 20:05:19 localhost kernel: [  153.622428]  []
driver_register+0x5d/0xf0
Dec 19 20:05:19 localhost kernel: [  153.622650]  []
__pci_register_driver+0x33/0x40
Dec 19 20:05:19 localhost kernel: [  153.622879]  []
drm_pci_init+0xed/0x110 [drm]
Dec 19 20:05:19 localhost kernel: [  153.623100]  [] ? 0xf9f92000
Dec 19 20:05:19 localhost kernel: [  153.623338]  []
radeon_init+0x8d/0xa8 [radeon]
Dec 19 20:05:19 localhost kernel: [  153.623555]  []
do_one_initcall+0xc6/0x200
Dec 19 20:05:19 localhost kernel: [  153.623778]  [] ? 0xf9f92000
Dec 19 20:05:19 localhost kernel: [  153.623996]  [] ?
lazy_max_pages+0x18/0x30
Dec 19 20:05:19 localhost kernel: [  153.624321]  [] ?
__vunmap+0xa5/0xf0
Dec 19 20:05:19 localhost kernel: [  153.624553]  [] ?
__vunmap+0xa5/0xf0
Dec 19 20:05:19 localhost kernel: [  153.624773]  []
load_module+0x1ebb/0x23f0
Dec 19 20:05:19 localhost kernel: [  153.624997]  []
SyS_init_module+0xaf/0x120
Dec 19 20:05:19 localhost kernel: [  153.625222]  []
sysenter_do_call+0x12/0x12
Dec 19 20:05:19 localhost kernel: [  153.630317] Code: 90 66 90 66 90 90 55 89
e5 56 53 83 ec 0c 66 66 66 66 90 89 c3 8b 40 2c 85 c0 7e 2a 8b 43 1c 8b 4b 04
8d 70 01 8d 04 81 89 73 1c <89> 10 8b 43 4c 83 6b 2c 01 21 43 1c 83 6b 28 01 83
c4 0c 5b 5e
Dec 19 20:05:19 localhost kernel: [  153.638171] EIP: []
radeon_ring_write+0x25/0x60 [radeon] SS:ESP 0068:f3ba5b50
Dec 19 20:05:19 localhost kernel: [  153.638744] CR2: ff846000
Dec 19 20:05:19 localhost kernel: [  153.638959] ---[ end trace
4f07e3ff097194e7 ]---
s is a kernel stack  extract of what happens after performing 'modprobe'

-- 
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/20141221/bb15024c/attachment-0001.html>

[Bug 87553] system boot hangs at drm initialization

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

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

--- Comment #1 from d.lecardez at gmail.com ---
Created attachment 08
  --> https://bugs.freedesktop.org/attachment.cgi?id=08=edit
full /var/log/messages

-- 
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/20141221/83aa312a/attachment.html>

[PATCH 1/3] amdkfd: Don't clear *kfd2kgd on kfd_module_init

[Oded Gabbay]

On 12/21/2014 01:27 PM, Christian König wrote:
> Am 20.12.2014 um 21:46 schrieb Oded Gabbay:
>> When amdkfd and radeon are compiled inside the kernel image (not as modules),
>> radeon will load before amdkfd and will set *kfd2kgd to its interface
>> structure. Therefore, we must not set *kfd2kgd to NULL when amdkfd is loaded
>> because it will override radeon's initialization and cause kernel BUG.
>>
>> Signed-off-by: Oded Gabbay 
>
> You should probably rather fix the dependency between the two modules to get 
> an
> determined load order instead of doing such nasty workarounds.
>
> Christian.

The problem is that when modules are compiled inside the kernel, there is NO 
determined load order and there is no mechanism to enforce that. If there 
is/was 
such a mechanism, I would of course prefer to use it.

Actually, I don't understand why the kernel doesn't enforce the order according 
to the use of exported symbols, like it does with modules.

There will always be dependencies between kgd (radeon) and amdkfd and between 
amdkfd and amd_iommu_v2. I don't think I can eliminate those dependencies, not 
without a very complex solution. And the fact that this complex solution occurs 
only in a very specific use case (all modules compiled in), makes me less 
inclined to do that.

So I don't see it as a "nasty workaround". I would call it just a "workaround" 
for a specific use case, which should be solved by a generic solution to the 
kernel enforcing load orders.

Oded
>
>> ---
>>   drivers/gpu/drm/amd/amdkfd/kfd_module.c | 5 ++---
>>   1 file changed, 2 insertions(+), 3 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/amd/amdkfd/kfd_module.c
>> b/drivers/gpu/drm/amd/amdkfd/kfd_module.c
>> index 95d5af1..236562f 100644
>> --- a/drivers/gpu/drm/amd/amdkfd/kfd_module.c
>> +++ b/drivers/gpu/drm/amd/amdkfd/kfd_module.c
>> @@ -34,7 +34,7 @@
>>   #define KFD_DRIVER_MINOR7
>>   #define KFD_DRIVER_PATCHLEVEL0
>> -const struct kfd2kgd_calls *kfd2kgd;
>> +const struct kfd2kgd_calls *kfd2kgd = NULL;
>>   static const struct kgd2kfd_calls kgd2kfd = {
>>   .exit= kgd2kfd_exit,
>>   .probe= kgd2kfd_probe,
>> @@ -84,14 +84,13 @@ EXPORT_SYMBOL(kgd2kfd_init);
>>   void kgd2kfd_exit(void)
>>   {
>> +kfd2kgd = NULL;
>>   }
>>   static int __init kfd_module_init(void)
>>   {
>>   int err;
>> -kfd2kgd = NULL;
>> -
>>   /* Verify module parameters */
>>   if ((sched_policy < KFD_SCHED_POLICY_HWS) ||
>>   (sched_policy > KFD_SCHED_POLICY_NO_HWS)) {
>

[PATCH 1/3] amdkfd: Don't clear *kfd2kgd on kfd_module_init

[Christian König]

Am 21.12.2014 um 12:34 schrieb Oded Gabbay:
>
>
> On 12/21/2014 01:27 PM, Christian König wrote:
>> Am 20.12.2014 um 21:46 schrieb Oded Gabbay:
>>> When amdkfd and radeon are compiled inside the kernel image (not as 
>>> modules),
>>> radeon will load before amdkfd and will set *kfd2kgd to its interface
>>> structure. Therefore, we must not set *kfd2kgd to NULL when amdkfd 
>>> is loaded
>>> because it will override radeon's initialization and cause kernel BUG.
>>>
>>> Signed-off-by: Oded Gabbay 
>>
>> You should probably rather fix the dependency between the two modules 
>> to get an
>> determined load order instead of doing such nasty workarounds.
>>
>> Christian.
>
> The problem is that when modules are compiled inside the kernel, there 
> is NO determined load order and there is no mechanism to enforce that. 
> If there is/was such a mechanism, I would of course prefer to use it.

There should be an determined order based on the symbol use, otherwise 
initializing most of the kernel modules wouldn't work as expected. For 
example radeon depends on the drm module must be loaded before radeon is 
loaded.

>
> Actually, I don't understand why the kernel doesn't enforce the order 
> according to the use of exported symbols, like it does with modules.

Yeah, that's indeed rather strange. There must be something in the 
amdkfd code which broke that somehow.

As far as I understand you the desired init order is radeon and 
amd_iommu_v2 first and then amdkfd, right? So what happens when you boot 
with radeon, amd_iommu_v2 and amdkfd blacklisted for automatically load 
and only load amdkfd manually?

> There will always be dependencies between kgd (radeon) and amdkfd and 
> between amdkfd and amd_iommu_v2. I don't think I can eliminate those 
> dependencies, not without a very complex solution. And the fact that 
> this complex solution occurs only in a very specific use case (all 
> modules compiled in), makes me less inclined to do that.
>
> So I don't see it as a "nasty workaround". I would call it just a 
> "workaround" for a specific use case, which should be solved by a 
> generic solution to the kernel enforcing load orders.

The normal kernel module handling already should provide the correct 
init order, so I would still call this a rather nasty workaround because 
we couldn't find the underlying problem.

Christian.

>
> Oded
>>
>>> ---
>>>   drivers/gpu/drm/amd/amdkfd/kfd_module.c | 5 ++---
>>>   1 file changed, 2 insertions(+), 3 deletions(-)
>>>
>>> diff --git a/drivers/gpu/drm/amd/amdkfd/kfd_module.c
>>> b/drivers/gpu/drm/amd/amdkfd/kfd_module.c
>>> index 95d5af1..236562f 100644
>>> --- a/drivers/gpu/drm/amd/amdkfd/kfd_module.c
>>> +++ b/drivers/gpu/drm/amd/amdkfd/kfd_module.c
>>> @@ -34,7 +34,7 @@
>>>   #define KFD_DRIVER_MINOR7
>>>   #define KFD_DRIVER_PATCHLEVEL0
>>> -const struct kfd2kgd_calls *kfd2kgd;
>>> +const struct kfd2kgd_calls *kfd2kgd = NULL;
>>>   static const struct kgd2kfd_calls kgd2kfd = {
>>>   .exit= kgd2kfd_exit,
>>>   .probe= kgd2kfd_probe,
>>> @@ -84,14 +84,13 @@ EXPORT_SYMBOL(kgd2kfd_init);
>>>   void kgd2kfd_exit(void)
>>>   {
>>> +kfd2kgd = NULL;
>>>   }
>>>   static int __init kfd_module_init(void)
>>>   {
>>>   int err;
>>> -kfd2kgd = NULL;
>>> -
>>>   /* Verify module parameters */
>>>   if ((sched_policy < KFD_SCHED_POLICY_HWS) ||
>>>   (sched_policy > KFD_SCHED_POLICY_NO_HWS)) {
>>

[PATCH 1/3] amdkfd: Don't clear *kfd2kgd on kfd_module_init

[Oded Gabbay]

On 12/20/2014 11:25 PM, Greg KH wrote:
> On Sat, Dec 20, 2014 at 10:46:12PM +0200, Oded Gabbay wrote:
>> When amdkfd and radeon are compiled inside the kernel image (not as modules),
>> radeon will load before amdkfd and will set *kfd2kgd to its interface
>> structure. Therefore, we must not set *kfd2kgd to NULL when amdkfd is loaded
>> because it will override radeon's initialization and cause kernel BUG.
>>
>> Signed-off-by: Oded Gabbay 
>> ---
>>   drivers/gpu/drm/amd/amdkfd/kfd_module.c | 5 ++---
>>   1 file changed, 2 insertions(+), 3 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/amd/amdkfd/kfd_module.c 
>> b/drivers/gpu/drm/amd/amdkfd/kfd_module.c
>> index 95d5af1..236562f 100644
>> --- a/drivers/gpu/drm/amd/amdkfd/kfd_module.c
>> +++ b/drivers/gpu/drm/amd/amdkfd/kfd_module.c
>> @@ -34,7 +34,7 @@
>>   #define KFD_DRIVER_MINOR   7
>>   #define KFD_DRIVER_PATCHLEVEL  0
>>
>> -const struct kfd2kgd_calls *kfd2kgd;
>> +const struct kfd2kgd_calls *kfd2kgd = NULL;
>
> This change does nothing, that is what the original code did already.
>
> thanks,
>
> greg k-h
Yeah. Sorry, I will remove it.

Oded
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
>

plugin-containe[…]: segfault in r600_dri.so[93c80000+812000]

[Paul Menzel]

x_main (argc=15, argv=0xbfcfe9d4, envp=0xb77b5b1c 
) at ../../dix/main.c:296
alwaysCheckForInput = {0, 1}
#23 0xb756dbca in main (argc=15, argv=0xbfcfe9d4, envp=0xbfcfea14) at 
../../dix/stubmain.c:34
No locals.
quit
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: This is a digitally signed message part
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20141221/0afa8e93/attachment-0001.sig>

[PATCH 1/3] amdkfd: Don't clear *kfd2kgd on kfd_module_init

[Christian König]

Am 20.12.2014 um 21:46 schrieb Oded Gabbay:
> When amdkfd and radeon are compiled inside the kernel image (not as modules),
> radeon will load before amdkfd and will set *kfd2kgd to its interface
> structure. Therefore, we must not set *kfd2kgd to NULL when amdkfd is loaded
> because it will override radeon's initialization and cause kernel BUG.
>
> Signed-off-by: Oded Gabbay 

You should probably rather fix the dependency between the two modules to 
get an determined load order instead of doing such nasty workarounds.

Christian.

> ---
>   drivers/gpu/drm/amd/amdkfd/kfd_module.c | 5 ++---
>   1 file changed, 2 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/amdkfd/kfd_module.c 
> b/drivers/gpu/drm/amd/amdkfd/kfd_module.c
> index 95d5af1..236562f 100644
> --- a/drivers/gpu/drm/amd/amdkfd/kfd_module.c
> +++ b/drivers/gpu/drm/amd/amdkfd/kfd_module.c
> @@ -34,7 +34,7 @@
>   #define KFD_DRIVER_MINOR7
>   #define KFD_DRIVER_PATCHLEVEL   0
>   
> -const struct kfd2kgd_calls *kfd2kgd;
> +const struct kfd2kgd_calls *kfd2kgd = NULL;
>   static const struct kgd2kfd_calls kgd2kfd = {
>   .exit   = kgd2kfd_exit,
>   .probe  = kgd2kfd_probe,
> @@ -84,14 +84,13 @@ EXPORT_SYMBOL(kgd2kfd_init);
>   
>   void kgd2kfd_exit(void)
>   {
> + kfd2kgd = NULL;
>   }
>   
>   static int __init kfd_module_init(void)
>   {
>   int err;
>   
> - kfd2kgd = NULL;
> -
>   /* Verify module parameters */
>   if ((sched_policy < KFD_SCHED_POLICY_HWS) ||
>   (sched_policy > KFD_SCHED_POLICY_NO_HWS)) {

[PATCH] gpu: drm: nouveau: core: subdev: clock: base.c: Remove unused function

[Rickard Strandqvist]

2014-12-21 3:46 GMT+01:00 Ben Skeggs :
> - Original Message -
>> From: "Rickard Strandqvist" 
>> To: "David Airlie" , "Ben Skeggs" > redhat.com>
>> Cc: "Rickard Strandqvist" , 
>> "Alexandre Courbot" , "Ilia
>> Mirkin" , dri-devel at lists.freedesktop.org, 
>> linux-kernel at vger.kernel.org
>> Sent: Sunday, 21 December, 2014 2:54:16 AM
>> Subject: [PATCH] gpu: drm: nouveau: core: subdev: clock: base.c:  Remove 
>> unused function
>>
>> Remove the function nouveau_clock_astate() that is not used anywhere.
> No, don't remove this.  It's only not used because noone got around to 
> finishing load-based reclocking yet.
>
> NVIDIA has an implementation for the GK20A in the works that uses it.
>
> Ben.
>
>>
>> This was partially found by using a static code analysis program called
>> cppcheck.
>>
>> Signed-off-by: Rickard Strandqvist > spectrumdigital.se>
>> ---
>>  drivers/gpu/drm/nouveau/core/include/subdev/clock.h |1 -
>>  drivers/gpu/drm/nouveau/core/subdev/clock/base.c|   10 --
>>  2 files changed, 11 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/nouveau/core/include/subdev/clock.h
>> b/drivers/gpu/drm/nouveau/core/include/subdev/clock.h
>> index 36ed035..8577945 100644
>> --- a/drivers/gpu/drm/nouveau/core/include/subdev/clock.h
>> +++ b/drivers/gpu/drm/nouveau/core/include/subdev/clock.h
>> @@ -159,7 +159,6 @@ int nva3_clock_pll_calc(struct nouveau_clock *, struct
>> nvbios_pll *,
>>   int clk, struct nouveau_pll_vals *);
>>
>>  int nouveau_clock_ustate(struct nouveau_clock *, int req, int pwr);
>> -int nouveau_clock_astate(struct nouveau_clock *, int req, int rel);
>>  int nouveau_clock_dstate(struct nouveau_clock *, int req, int rel);
>>  int nouveau_clock_tstate(struct nouveau_clock *, int req, int rel);
>>
>> diff --git a/drivers/gpu/drm/nouveau/core/subdev/clock/base.c
>> b/drivers/gpu/drm/nouveau/core/subdev/clock/base.c
>> index e51b72d..b2c852a 100644
>> --- a/drivers/gpu/drm/nouveau/core/subdev/clock/base.c
>> +++ b/drivers/gpu/drm/nouveau/core/subdev/clock/base.c
>> @@ -430,16 +430,6 @@ nouveau_clock_ustate(struct nouveau_clock *clk, int req,
>> int pwr)
>>  }
>>
>>  int
>> -nouveau_clock_astate(struct nouveau_clock *clk, int req, int rel)
>> -{
>> - if (!rel) clk->astate  = req;
>> - if ( rel) clk->astate += rel;
>> - clk->astate = min(clk->astate, clk->state_nr - 1);
>> - clk->astate = max(clk->astate, 0);
>> - return nouveau_pstate_calc(clk, true);
>> -}
>> -
>> -int
>>  nouveau_clock_tstate(struct nouveau_clock *clk, int req, int rel)
>>  {
>>   if (!rel) clk->tstate  = req;
>> --
>> 1.7.10.4
>>


Hi

Ok, sorry.
But maybe there should be a comment on the function.

Kind regards
Rickard Strandqvist

[Bug 87489] GPU lockup - Sid Meyer's Beyond Earth

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

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

Ernst Sjöstrand  changed:

   What|Removed |Added

 CC||ernstp at gmail.com

--- Comment #3 from Ernst Sjöstrand  ---
I can also reproduce this. Radeon 6850.

-- 
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/20141221/96fe0751/attachment.html>