mali_probe fail

[sergey-suloev]

hi Maxime on my OrangePi PC mali probe is failing with -14. Here is dmesg:

[ 2663.165745] Inserting Mali v900 device driver. [ 2663.165753] Mali<2>: [ 2663.165761] Compiled: Nov 26 2017, time: 01:55:56. [ 2663.165764] Mali<2>: [ 2663.165770] Driver revision: r6p2-01rel0-e5261c5 [ 2663.165774] Mali<2>: [ 2663.165780] mali_module_init() registering device [ 2663.166580] mali-utgard: assigned reserved memory node linux,cma [ 2663.168105] Allwinner sunXi mali glue initialized [ 2663.168120] Mali<2>: [ 2663.168128] mali_module_init() registering driver [ 2663.168460] Mali<2>: [ 2663.168472] mali_probe(): Called for platform device mali-utgard [ 2663.168510] Mali<2>: [ 2663.168519] Continuing without Mali regulator control [ 2663.168530] Mali<3>: [ 2663.168535] OPP table not found [ 2663.168561] Mali<2>: [ 2663.168566] Init Mali devfreq [ 2663.168593] mali-utgard mali-utgard.0: dev_pm_opp_get_opp_count: OPP table not found (-19) [ 2663.168599] Mali<2>: [ 2663.168604] mali devfreq init failed [ 2663.168651] mali-utgard: probe of mali-utgard.0 failed with error -14 [ 2663.168839] Mali: [ 2663.168847] Mali device driver loaded

In bindings stated that opm device tree nodes are optional

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/devicetree/bindings/gpu/arm,mali-utgard.txt

but it makes mali_probe fail. Why is that ?

[giuliobenetti]

Recompile with BUILD=debug and insmod with mali_debug_level=5, this gives the source of the problem. Thank you

[sergey-suloev]

That's compiled with BUILD=debug and run with mali.mali_debug_level=5. But it is just a boot log. Later I will provide the log for running test app.

[mripard]

Please provide the changes you made.

[sergey-suloev]

Seems like using USING_DEVFREQ=1 results in building a part of code which will make mali_probe fail.

[giuliobenetti]

Do you mean when it complains on compiling driver like "You want to support DEVFREQ but kernel didn't support DEVFREQ." ? It happens to me too, but then driver works correctly

[sergey-suloev]

Hey Giulio, you want to say that failing mali_probe is not a problem at all ?

[giuliobenetti]

Hi Sergey,

can you provide your complete log? @mripard is this the right place to discuss this?

[sergey-suloev]

Hello guys

here is the full dmesg http://sprunge.us/fbeB

The error is in there.

---

[ 8.547231] mali-utgard mali-utgard.0: dev_pm_opp_get_opp_count: OPP table not found (-19) [ 8.547253] mali-utgard: probe of mali-utgard.0 failed with error -14

mali code used is taken from Maxime's "master"

Giulio, can you confirm that you have the same error on your device and Mali is still working ?

[mripard]

Can you please provide the changes you made and the kernel version you're running

[sergey-suloev]

hi Maxime I didn't make any changes to mali, i am using your "master", if you are asking about that. As for kernel, I am using "next" build of armbian, 4.13.16 with a lot patches from armbian team. I have mali , drm, and region device tree nodes, provided by the armbian patch.

ARMBIAN 5.35 user-built Debian GNU/Linux 9 (stretch) 4.13.16-sunxi

[mripard]

I have no idea what armbian changes did then. Please ask them for support

[sergey-suloev]

Maxime,

according to the error:

[ 2663.168593] mali-utgard mali-utgard.0: dev_pm_opp_get_opp_count: OPP table not found (-19) [ 2663.168599] Mali<2>: [ 2663.168604] mali devfreq init failed [ 2663.168651] mali-utgard: probe of mali-utgard.0 failed with error -14

what can be missing in armbian ? Seems like issue is in "mali_devfreq_init".. I think it needs more logging

Code is dropping from here:

https://github.com/mripard/sunxi-mali/blob/891299bac366d6e5ed5c480d0367276472177e3d/r6p2/src/devicedrv/mali/linux/mali_devfreq.c#L164

According to bindings

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/devicetree/bindings/gpu/arm,mali-utgard.txt#n51

the opp node is optional, but code is failing because it was not found.

[giuliobenetti]

Hi Sergey,

The error doesn’t depend on OPP table. You need to recompile with BUILD=debug inside build.sh. At that point driver will be more verbose.

[net147]

@sergey-suloev You can try changing USING_DVFS and USING_DEVFREQ to 0 in build.sh.

[sergey-suloev]

@net147 thanks for the advice. will I lose any functionality in mali driver when turn off this flag ?

[net147]

@sergey-suloev Mali will just run using a fixed clock rate.

[sergey-suloev]

@net147 I am just curious why it compiles successfully for other people who don't have opp node in mali node either...

[net147]

@sergey-suloev Not everyone uses build.sh. Some people may compile it using build systems like Buildroot and OpenEmbedded and not rely on build.sh.

[net147]

@giuliobenetti Could aba9f1aefada47c4a29840e423cb6ff8a7e7b990 have caused the Mali kernel module installed by build.sh to change from USING_DVFS/USING_DEVFREQ=0 to USING_DVFS/USING_DEVFREQ=1?

[sergey-suloev]

@giuliobenetti that's how it is. can we add a parameter to build.sh in a way similar to -r so that the one could switch on/off devfreq feature ?

[giuliobenetti]

Sure, I’ll add it do PR to Maxime

[giuliobenetti]

But before check if dvfs is the problem

[sergey-suloev]

@giuliobenetti Gonna do it today. But changing boot.sh the way above would be a big improvement no matter if devfreq is a problem or not. Currently boot.sh does not allow build customization with parameters.