[v2,0/7] Add dts for mt8183 GPU (and misc panfrost patches)
mbox series

Message ID 20200108052337.65916-1-drinkcat@chromium.org
Headers show
Series
  • Add dts for mt8183 GPU (and misc panfrost patches)
Related show

Message

Nicolas Boichat Jan. 8, 2020, 5:23 a.m. UTC
Hi!

Sorry for the long delay since https://patchwork.kernel.org/patch/11132381/,
finally got around to give this a real try.

The main purpose of this series is to upstream the dts change and the binding
document, but I wanted to see how far I could probe the GPU, to check that the
binding is indeed correct. The rest of the patches are RFC/work-in-progress, but
I think some of them could already be picked up.

So this is tested on MT8183 with a chromeos-4.19 kernel, and a ton of
backports to get the latest panfrost driver (I should probably try on
linux-next at some point but this was the path of least resistance).

I tested it as a module as it's more challenging (originally probing would
work built-in, on boot, but not as a module, as I didn't have the power
domain changes, and all power domains are on by default during boot).

Probing logs looks like this, currently:
[  221.867726] panfrost 13040000.gpu: clock rate = 511999970
[  221.867929] panfrost 13040000.gpu: Linked as a consumer to regulator.14
[  221.868600] panfrost 13040000.gpu: Linked as a consumer to regulator.31
[  221.870586] panfrost 13040000.gpu: Linked as a consumer to genpd:0:13040000.gpu
[  221.871492] panfrost 13040000.gpu: Linked as a consumer to genpd:1:13040000.gpu
[  221.871866] panfrost 13040000.gpu: Linked as a consumer to genpd:2:13040000.gpu
[  221.872427] panfrost 13040000.gpu: mali-g72 id 0x6221 major 0x0 minor 0x3 status 0x0
[  221.872439] panfrost 13040000.gpu: features: 00000000,13de77ff, issues: 00000000,00000400
[  221.872445] panfrost 13040000.gpu: Features: L2:0x07120206 Shader:0x00000000 Tiler:0x00000809 Mem:0x1 MMU:0x00002830 AS:0xff JS:0x7
[  221.872449] panfrost 13040000.gpu: shader_present=0x7 l2_present=0x1
[  221.873526] panfrost 13040000.gpu: error powering up gpu stack
[  221.878088] [drm] Initialized panfrost 1.1.0 20180908 for 13040000.gpu on minor 2
[  221.940817] panfrost 13040000.gpu: error powering up gpu stack
[  222.018233] panfrost 13040000.gpu: error powering up gpu stack
(repeated)

So the GPU is probed, but there's an issue when powering up the STACK, not
quite sure why, I'll try to have a deeper look, at some point.

Thanks!

Nicolas

v2:
 - Use sram instead of mali_sram as SRAM supply name.
 - Rename mali@ to gpu@.
 - Add dt-bindings changes
 - Stacking patches after the device tree change that allow basic
   probing (still incomplete and broken).

Nicolas Boichat (7):
  dt-bindings: gpu: mali-bifrost: Add Mediatek MT8183
  arm64: dts: mt8183: Add node for the Mali GPU
  drm/panfrost: Improve error reporting in panfrost_gpu_power_on
  drm/panfrost: Add support for a second regulator for the GPU
  drm/panfrost: Add support for multiple power domain support
  RFC: drm/panfrost: Add bifrost compatible string
  RFC: drm/panfrost: devfreq: Add support for 2 regulators

 .../bindings/gpu/arm,mali-bifrost.yaml        |  20 ++++
 arch/arm64/boot/dts/mediatek/mt8183-evb.dts   |   7 ++
 arch/arm64/boot/dts/mediatek/mt8183.dtsi      | 104 +++++++++++++++++
 drivers/gpu/drm/panfrost/panfrost_devfreq.c   |  18 +++
 drivers/gpu/drm/panfrost/panfrost_device.c    | 108 ++++++++++++++++--
 drivers/gpu/drm/panfrost/panfrost_device.h    |   7 ++
 drivers/gpu/drm/panfrost/panfrost_drv.c       |   1 +
 drivers/gpu/drm/panfrost/panfrost_gpu.c       |  15 ++-
 8 files changed, 267 insertions(+), 13 deletions(-)

Comments

Alyssa Rosenzweig Jan. 8, 2020, 12:56 p.m. UTC | #1
Patches 1,2,3,6 are:

	Reviewed-by: Alyssa Rosenzweig <alyssa.rosenzweig@collabora.com>

The remaining patches in the series are Acked-by.

Reportedly the kernel should work on certain Bifrost boards more or less
as-is, but I'm not positive about the details. It's possible some of
these are G72-specific or MT-specific issues; Robin and Stephen will
know more.

Very nice work so far!

Alyssa

On Wed, Jan 08, 2020 at 01:23:30PM +0800, Nicolas Boichat wrote:
> Hi!
> 
> Sorry for the long delay since https://patchwork.kernel.org/patch/11132381/,
> finally got around to give this a real try.
> 
> The main purpose of this series is to upstream the dts change and the binding
> document, but I wanted to see how far I could probe the GPU, to check that the
> binding is indeed correct. The rest of the patches are RFC/work-in-progress, but
> I think some of them could already be picked up.
> 
> So this is tested on MT8183 with a chromeos-4.19 kernel, and a ton of
> backports to get the latest panfrost driver (I should probably try on
> linux-next at some point but this was the path of least resistance).
> 
> I tested it as a module as it's more challenging (originally probing would
> work built-in, on boot, but not as a module, as I didn't have the power
> domain changes, and all power domains are on by default during boot).
> 
> Probing logs looks like this, currently:
> [  221.867726] panfrost 13040000.gpu: clock rate = 511999970
> [  221.867929] panfrost 13040000.gpu: Linked as a consumer to regulator.14
> [  221.868600] panfrost 13040000.gpu: Linked as a consumer to regulator.31
> [  221.870586] panfrost 13040000.gpu: Linked as a consumer to genpd:0:13040000.gpu
> [  221.871492] panfrost 13040000.gpu: Linked as a consumer to genpd:1:13040000.gpu
> [  221.871866] panfrost 13040000.gpu: Linked as a consumer to genpd:2:13040000.gpu
> [  221.872427] panfrost 13040000.gpu: mali-g72 id 0x6221 major 0x0 minor 0x3 status 0x0
> [  221.872439] panfrost 13040000.gpu: features: 00000000,13de77ff, issues: 00000000,00000400
> [  221.872445] panfrost 13040000.gpu: Features: L2:0x07120206 Shader:0x00000000 Tiler:0x00000809 Mem:0x1 MMU:0x00002830 AS:0xff JS:0x7
> [  221.872449] panfrost 13040000.gpu: shader_present=0x7 l2_present=0x1
> [  221.873526] panfrost 13040000.gpu: error powering up gpu stack
> [  221.878088] [drm] Initialized panfrost 1.1.0 20180908 for 13040000.gpu on minor 2
> [  221.940817] panfrost 13040000.gpu: error powering up gpu stack
> [  222.018233] panfrost 13040000.gpu: error powering up gpu stack
> (repeated)
> 
> So the GPU is probed, but there's an issue when powering up the STACK, not
> quite sure why, I'll try to have a deeper look, at some point.
> 
> Thanks!
> 
> Nicolas
> 
> v2:
>  - Use sram instead of mali_sram as SRAM supply name.
>  - Rename mali@ to gpu@.
>  - Add dt-bindings changes
>  - Stacking patches after the device tree change that allow basic
>    probing (still incomplete and broken).
> 
> Nicolas Boichat (7):
>   dt-bindings: gpu: mali-bifrost: Add Mediatek MT8183
>   arm64: dts: mt8183: Add node for the Mali GPU
>   drm/panfrost: Improve error reporting in panfrost_gpu_power_on
>   drm/panfrost: Add support for a second regulator for the GPU
>   drm/panfrost: Add support for multiple power domain support
>   RFC: drm/panfrost: Add bifrost compatible string
>   RFC: drm/panfrost: devfreq: Add support for 2 regulators
> 
>  .../bindings/gpu/arm,mali-bifrost.yaml        |  20 ++++
>  arch/arm64/boot/dts/mediatek/mt8183-evb.dts   |   7 ++
>  arch/arm64/boot/dts/mediatek/mt8183.dtsi      | 104 +++++++++++++++++
>  drivers/gpu/drm/panfrost/panfrost_devfreq.c   |  18 +++
>  drivers/gpu/drm/panfrost/panfrost_device.c    | 108 ++++++++++++++++--
>  drivers/gpu/drm/panfrost/panfrost_device.h    |   7 ++
>  drivers/gpu/drm/panfrost/panfrost_drv.c       |   1 +
>  drivers/gpu/drm/panfrost/panfrost_gpu.c       |  15 ++-
>  8 files changed, 267 insertions(+), 13 deletions(-)
> 
> -- 
> 2.24.1.735.g03f4e72817-goog
>
Nicolas Boichat Jan. 9, 2020, 9:08 a.m. UTC | #2
On Wed, Jan 8, 2020 at 1:23 PM Nicolas Boichat <drinkcat@chromium.org> wrote:
>
> Hi!
>
> Sorry for the long delay since https://patchwork.kernel.org/patch/11132381/,
> finally got around to give this a real try.
>
> The main purpose of this series is to upstream the dts change and the binding
> document, but I wanted to see how far I could probe the GPU, to check that the
> binding is indeed correct. The rest of the patches are RFC/work-in-progress, but
> I think some of them could already be picked up.
>
> So this is tested on MT8183 with a chromeos-4.19 kernel, and a ton of
> backports to get the latest panfrost driver (I should probably try on
> linux-next at some point but this was the path of least resistance).
>
> I tested it as a module as it's more challenging (originally probing would
> work built-in, on boot, but not as a module, as I didn't have the power
> domain changes, and all power domains are on by default during boot).
>
> Probing logs looks like this, currently:
> [  221.867726] panfrost 13040000.gpu: clock rate = 511999970
> [  221.867929] panfrost 13040000.gpu: Linked as a consumer to regulator.14
> [  221.868600] panfrost 13040000.gpu: Linked as a consumer to regulator.31
> [  221.870586] panfrost 13040000.gpu: Linked as a consumer to genpd:0:13040000.gpu
> [  221.871492] panfrost 13040000.gpu: Linked as a consumer to genpd:1:13040000.gpu
> [  221.871866] panfrost 13040000.gpu: Linked as a consumer to genpd:2:13040000.gpu
> [  221.872427] panfrost 13040000.gpu: mali-g72 id 0x6221 major 0x0 minor 0x3 status 0x0
> [  221.872439] panfrost 13040000.gpu: features: 00000000,13de77ff, issues: 00000000,00000400
> [  221.872445] panfrost 13040000.gpu: Features: L2:0x07120206 Shader:0x00000000 Tiler:0x00000809 Mem:0x1 MMU:0x00002830 AS:0xff JS:0x7
> [  221.872449] panfrost 13040000.gpu: shader_present=0x7 l2_present=0x1
> [  221.873526] panfrost 13040000.gpu: error powering up gpu stack
> [  221.878088] [drm] Initialized panfrost 1.1.0 20180908 for 13040000.gpu on minor 2
> [  221.940817] panfrost 13040000.gpu: error powering up gpu stack
> [  222.018233] panfrost 13040000.gpu: error powering up gpu stack
> (repeated)
>
> So the GPU is probed, but there's an issue when powering up the STACK, not
> quite sure why, I'll try to have a deeper look, at some point.

Just as a follow-up to that one. stack_present=0x00000007 on my GPU.

However, the ARM-provided driver I use on this platform doesn't have
CONFIG_MALI_CORESTACK enabled so the "stack" is never turned on.
https://chromium.googlesource.com/chromiumos/third_party/kernel/+/chromeos-4.19/drivers/gpu/arm/midgard/Kconfig#101
. So possibly this does not need to be done on Bifrost GPUs (and the
error should be harmless).

> Thanks!
>
> Nicolas
>
> v2:
>  - Use sram instead of mali_sram as SRAM supply name.
>  - Rename mali@ to gpu@.
>  - Add dt-bindings changes
>  - Stacking patches after the device tree change that allow basic
>    probing (still incomplete and broken).
>
> Nicolas Boichat (7):
>   dt-bindings: gpu: mali-bifrost: Add Mediatek MT8183
>   arm64: dts: mt8183: Add node for the Mali GPU
>   drm/panfrost: Improve error reporting in panfrost_gpu_power_on
>   drm/panfrost: Add support for a second regulator for the GPU
>   drm/panfrost: Add support for multiple power domain support
>   RFC: drm/panfrost: Add bifrost compatible string
>   RFC: drm/panfrost: devfreq: Add support for 2 regulators
>
>  .../bindings/gpu/arm,mali-bifrost.yaml        |  20 ++++
>  arch/arm64/boot/dts/mediatek/mt8183-evb.dts   |   7 ++
>  arch/arm64/boot/dts/mediatek/mt8183.dtsi      | 104 +++++++++++++++++
>  drivers/gpu/drm/panfrost/panfrost_devfreq.c   |  18 +++
>  drivers/gpu/drm/panfrost/panfrost_device.c    | 108 ++++++++++++++++--
>  drivers/gpu/drm/panfrost/panfrost_device.h    |   7 ++
>  drivers/gpu/drm/panfrost/panfrost_drv.c       |   1 +
>  drivers/gpu/drm/panfrost/panfrost_gpu.c       |  15 ++-
>  8 files changed, 267 insertions(+), 13 deletions(-)
>
> --
> 2.24.1.735.g03f4e72817-goog
>
Steven Price Jan. 9, 2020, 12:01 p.m. UTC | #3
On 08/01/2020 05:23, Nicolas Boichat wrote:
> Hi!
> 
> Sorry for the long delay since https://patchwork.kernel.org/patch/11132381/,
> finally got around to give this a real try.
> 
> The main purpose of this series is to upstream the dts change and the binding
> document, but I wanted to see how far I could probe the GPU, to check that the
> binding is indeed correct. The rest of the patches are RFC/work-in-progress, but
> I think some of them could already be picked up.
> 
> So this is tested on MT8183 with a chromeos-4.19 kernel, and a ton of
> backports to get the latest panfrost driver (I should probably try on
> linux-next at some point but this was the path of least resistance).
> 
> I tested it as a module as it's more challenging (originally probing would
> work built-in, on boot, but not as a module, as I didn't have the power
> domain changes, and all power domains are on by default during boot).
> 
> Probing logs looks like this, currently:
> [  221.867726] panfrost 13040000.gpu: clock rate = 511999970
> [  221.867929] panfrost 13040000.gpu: Linked as a consumer to regulator.14
> [  221.868600] panfrost 13040000.gpu: Linked as a consumer to regulator.31
> [  221.870586] panfrost 13040000.gpu: Linked as a consumer to genpd:0:13040000.gpu
> [  221.871492] panfrost 13040000.gpu: Linked as a consumer to genpd:1:13040000.gpu
> [  221.871866] panfrost 13040000.gpu: Linked as a consumer to genpd:2:13040000.gpu
> [  221.872427] panfrost 13040000.gpu: mali-g72 id 0x6221 major 0x0 minor 0x3 status 0x0
> [  221.872439] panfrost 13040000.gpu: features: 00000000,13de77ff, issues: 00000000,00000400
> [  221.872445] panfrost 13040000.gpu: Features: L2:0x07120206 Shader:0x00000000 Tiler:0x00000809 Mem:0x1 MMU:0x00002830 AS:0xff JS:0x7
> [  221.872449] panfrost 13040000.gpu: shader_present=0x7 l2_present=0x1
> [  221.873526] panfrost 13040000.gpu: error powering up gpu stack
> [  221.878088] [drm] Initialized panfrost 1.1.0 20180908 for 13040000.gpu on minor 2
> [  221.940817] panfrost 13040000.gpu: error powering up gpu stack
> [  222.018233] panfrost 13040000.gpu: error powering up gpu stack
> (repeated)

It's interesting that it's only the stack that is failing. In hardware there's a dependency: L2->stack->shader - so in theory the shader cores shouldn't be able to power up either. There are some known hardware bugs here though[1]:

	MODULE_PARM_DESC(corestack_driver_control,
			"Let the driver power on/off the GPU core stack independently "
			"without involving the Power Domain Controller. This should "
			"only be enabled on platforms for which integration of the PDC "
			"to the Mali GPU is known to be problematic.");

[1] https://github.com/ianmacd/d2s/blob/master/drivers/gpu/arm/b_r16p0/backend/gpu/mali_kbase_pm_driver.c#L57

It might be worth just dropping the code for powering up/down stacks and let the GPU's own dependency management handle it.

Steve

> 
> So the GPU is probed, but there's an issue when powering up the STACK, not
> quite sure why, I'll try to have a deeper look, at some point.
> 
> Thanks!
> 
> Nicolas
> 
> v2:
>   - Use sram instead of mali_sram as SRAM supply name.
>   - Rename mali@ to gpu@.
>   - Add dt-bindings changes
>   - Stacking patches after the device tree change that allow basic
>     probing (still incomplete and broken).
> 
> Nicolas Boichat (7):
>    dt-bindings: gpu: mali-bifrost: Add Mediatek MT8183
>    arm64: dts: mt8183: Add node for the Mali GPU
>    drm/panfrost: Improve error reporting in panfrost_gpu_power_on
>    drm/panfrost: Add support for a second regulator for the GPU
>    drm/panfrost: Add support for multiple power domain support
>    RFC: drm/panfrost: Add bifrost compatible string
>    RFC: drm/panfrost: devfreq: Add support for 2 regulators
> 
>   .../bindings/gpu/arm,mali-bifrost.yaml        |  20 ++++
>   arch/arm64/boot/dts/mediatek/mt8183-evb.dts   |   7 ++
>   arch/arm64/boot/dts/mediatek/mt8183.dtsi      | 104 +++++++++++++++++
>   drivers/gpu/drm/panfrost/panfrost_devfreq.c   |  18 +++
>   drivers/gpu/drm/panfrost/panfrost_device.c    | 108 ++++++++++++++++--
>   drivers/gpu/drm/panfrost/panfrost_device.h    |   7 ++
>   drivers/gpu/drm/panfrost/panfrost_drv.c       |   1 +
>   drivers/gpu/drm/panfrost/panfrost_gpu.c       |  15 ++-
>   8 files changed, 267 insertions(+), 13 deletions(-)
>
Robin Murphy Jan. 9, 2020, 1:10 p.m. UTC | #4
On 09/01/2020 12:01 pm, Steven Price wrote:
> On 08/01/2020 05:23, Nicolas Boichat wrote:
>> Hi!
>>
>> Sorry for the long delay since 
>> https://patchwork.kernel.org/patch/11132381/,
>> finally got around to give this a real try.
>>
>> The main purpose of this series is to upstream the dts change and the 
>> binding
>> document, but I wanted to see how far I could probe the GPU, to check 
>> that the
>> binding is indeed correct. The rest of the patches are 
>> RFC/work-in-progress, but
>> I think some of them could already be picked up.
>>
>> So this is tested on MT8183 with a chromeos-4.19 kernel, and a ton of
>> backports to get the latest panfrost driver (I should probably try on
>> linux-next at some point but this was the path of least resistance).
>>
>> I tested it as a module as it's more challenging (originally probing 
>> would
>> work built-in, on boot, but not as a module, as I didn't have the power
>> domain changes, and all power domains are on by default during boot).
>>
>> Probing logs looks like this, currently:
>> [  221.867726] panfrost 13040000.gpu: clock rate = 511999970
>> [  221.867929] panfrost 13040000.gpu: Linked as a consumer to 
>> regulator.14
>> [  221.868600] panfrost 13040000.gpu: Linked as a consumer to 
>> regulator.31
>> [  221.870586] panfrost 13040000.gpu: Linked as a consumer to 
>> genpd:0:13040000.gpu
>> [  221.871492] panfrost 13040000.gpu: Linked as a consumer to 
>> genpd:1:13040000.gpu
>> [  221.871866] panfrost 13040000.gpu: Linked as a consumer to 
>> genpd:2:13040000.gpu
>> [  221.872427] panfrost 13040000.gpu: mali-g72 id 0x6221 major 0x0 
>> minor 0x3 status 0x0
>> [  221.872439] panfrost 13040000.gpu: features: 00000000,13de77ff, 
>> issues: 00000000,00000400
>> [  221.872445] panfrost 13040000.gpu: Features: L2:0x07120206 
>> Shader:0x00000000 Tiler:0x00000809 Mem:0x1 MMU:0x00002830 AS:0xff JS:0x7
>> [  221.872449] panfrost 13040000.gpu: shader_present=0x7 l2_present=0x1
>> [  221.873526] panfrost 13040000.gpu: error powering up gpu stack
>> [  221.878088] [drm] Initialized panfrost 1.1.0 20180908 for 
>> 13040000.gpu on minor 2
>> [  221.940817] panfrost 13040000.gpu: error powering up gpu stack
>> [  222.018233] panfrost 13040000.gpu: error powering up gpu stack
>> (repeated)
> 
> It's interesting that it's only the stack that is failing. In hardware 
> there's a dependency: L2->stack->shader - so in theory the shader cores 
> shouldn't be able to power up either. There are some known hardware bugs 
> here though[1]:
> 
>      MODULE_PARM_DESC(corestack_driver_control,
>              "Let the driver power on/off the GPU core stack 
> independently "
>              "without involving the Power Domain Controller. This should "
>              "only be enabled on platforms for which integration of the 
> PDC "
>              "to the Mali GPU is known to be problematic.");
> 
> [1] 
> https://github.com/ianmacd/d2s/blob/master/drivers/gpu/arm/b_r16p0/backend/gpu/mali_kbase_pm_driver.c#L57 
> 
> 
> It might be worth just dropping the code for powering up/down stacks and 
> let the GPU's own dependency management handle it.

FWIW I remember digging into that same message a while back (although 
I've forgotten which particular GPU I was playing with at the time), and 
concluded that the STACK_PWRON/STACK_READY registers might just not be 
implemented on some GPUs, and/or this easy-to-overlook register bit 
could be some kind of enable for the functionality:

https://github.com/ianmacd/d2s/blob/master/drivers/gpu/arm/b_r16p0/backend/gpu/mali_kbase_pm_driver.c#L1631

Since even in kbase this is all behind an 'expert' config option, I'm 
inclined to agree that just dropping it from panfrost unless and until 
it proves necessary is probably preferable to adding more logic and 
inscrutable register-magic.

Robin.

> 
> Steve
> 
>>
>> So the GPU is probed, but there's an issue when powering up the STACK, 
>> not
>> quite sure why, I'll try to have a deeper look, at some point.
>>
>> Thanks!
>>
>> Nicolas
>>
>> v2:
>>   - Use sram instead of mali_sram as SRAM supply name.
>>   - Rename mali@ to gpu@.
>>   - Add dt-bindings changes
>>   - Stacking patches after the device tree change that allow basic
>>     probing (still incomplete and broken).
>>
>> Nicolas Boichat (7):
>>    dt-bindings: gpu: mali-bifrost: Add Mediatek MT8183
>>    arm64: dts: mt8183: Add node for the Mali GPU
>>    drm/panfrost: Improve error reporting in panfrost_gpu_power_on
>>    drm/panfrost: Add support for a second regulator for the GPU
>>    drm/panfrost: Add support for multiple power domain support
>>    RFC: drm/panfrost: Add bifrost compatible string
>>    RFC: drm/panfrost: devfreq: Add support for 2 regulators
>>
>>   .../bindings/gpu/arm,mali-bifrost.yaml        |  20 ++++
>>   arch/arm64/boot/dts/mediatek/mt8183-evb.dts   |   7 ++
>>   arch/arm64/boot/dts/mediatek/mt8183.dtsi      | 104 +++++++++++++++++
>>   drivers/gpu/drm/panfrost/panfrost_devfreq.c   |  18 +++
>>   drivers/gpu/drm/panfrost/panfrost_device.c    | 108 ++++++++++++++++--
>>   drivers/gpu/drm/panfrost/panfrost_device.h    |   7 ++
>>   drivers/gpu/drm/panfrost/panfrost_drv.c       |   1 +
>>   drivers/gpu/drm/panfrost/panfrost_gpu.c       |  15 ++-
>>   8 files changed, 267 insertions(+), 13 deletions(-)
>>
> 
> _______________________________________________
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
Steven Price Jan. 9, 2020, 1:29 p.m. UTC | #5
On Thu, Jan 09, 2020 at 01:10:33PM +0000, Robin Murphy wrote:
> On 09/01/2020 12:01 pm, Steven Price wrote:
> > On 08/01/2020 05:23, Nicolas Boichat wrote:
> >> Hi!
> >>
> >> Sorry for the long delay since 
> >> https://patchwork.kernel.org/patch/11132381/,
> >> finally got around to give this a real try.
> >>
> >> The main purpose of this series is to upstream the dts change and the 
> >> binding
> >> document, but I wanted to see how far I could probe the GPU, to check 
> >> that the
> >> binding is indeed correct. The rest of the patches are 
> >> RFC/work-in-progress, but
> >> I think some of them could already be picked up.
> >>
> >> So this is tested on MT8183 with a chromeos-4.19 kernel, and a ton of
> >> backports to get the latest panfrost driver (I should probably try on
> >> linux-next at some point but this was the path of least resistance).
> >>
> >> I tested it as a module as it's more challenging (originally probing 
> >> would
> >> work built-in, on boot, but not as a module, as I didn't have the power
> >> domain changes, and all power domains are on by default during boot).
> >>
> >> Probing logs looks like this, currently:
> >> [  221.867726] panfrost 13040000.gpu: clock rate = 511999970
> >> [  221.867929] panfrost 13040000.gpu: Linked as a consumer to 
> >> regulator.14
> >> [  221.868600] panfrost 13040000.gpu: Linked as a consumer to 
> >> regulator.31
> >> [  221.870586] panfrost 13040000.gpu: Linked as a consumer to 
> >> genpd:0:13040000.gpu
> >> [  221.871492] panfrost 13040000.gpu: Linked as a consumer to 
> >> genpd:1:13040000.gpu
> >> [  221.871866] panfrost 13040000.gpu: Linked as a consumer to 
> >> genpd:2:13040000.gpu
> >> [  221.872427] panfrost 13040000.gpu: mali-g72 id 0x6221 major 0x0 
> >> minor 0x3 status 0x0
> >> [  221.872439] panfrost 13040000.gpu: features: 00000000,13de77ff, 
> >> issues: 00000000,00000400
> >> [  221.872445] panfrost 13040000.gpu: Features: L2:0x07120206 
> >> Shader:0x00000000 Tiler:0x00000809 Mem:0x1 MMU:0x00002830 AS:0xff JS:0x7
> >> [  221.872449] panfrost 13040000.gpu: shader_present=0x7 l2_present=0x1
> >> [  221.873526] panfrost 13040000.gpu: error powering up gpu stack
> >> [  221.878088] [drm] Initialized panfrost 1.1.0 20180908 for 
> >> 13040000.gpu on minor 2
> >> [  221.940817] panfrost 13040000.gpu: error powering up gpu stack
> >> [  222.018233] panfrost 13040000.gpu: error powering up gpu stack
> >> (repeated)
> > 
> > It's interesting that it's only the stack that is failing. In hardware 
> > there's a dependency: L2->stack->shader - so in theory the shader cores 
> > shouldn't be able to power up either. There are some known hardware bugs 
> > here though[1]:
> > 
> >      MODULE_PARM_DESC(corestack_driver_control,
> >              "Let the driver power on/off the GPU core stack 
> > independently "
> >              "without involving the Power Domain Controller. This should "
> >              "only be enabled on platforms for which integration of the 
> > PDC "
> >              "to the Mali GPU is known to be problematic.");
> > 
> > [1] 
> > https://github.com/ianmacd/d2s/blob/master/drivers/gpu/arm/b_r16p0/backend/gpu/mali_kbase_pm_driver.c#L57 
> > 
> > 
> > It might be worth just dropping the code for powering up/down stacks and 
> > let the GPU's own dependency management handle it.
> 
> FWIW I remember digging into that same message a while back (although 
> I've forgotten which particular GPU I was playing with at the time), and 
> concluded that the STACK_PWRON/STACK_READY registers might just not be 
> implemented on some GPUs,

They are indeed not implemented on some GPUs. Specifically none of the
Midgard GPUs. I believe G71 also doesn't have it. However the register
addresses were picked so that on these older GPUs they should
read-as-zero and write-ignore so this shouldn't actually cause any
problems.

> and/or this easy-to-overlook register bit 
> could be some kind of enable for the functionality:
> 
> https://github.com/ianmacd/d2s/blob/master/drivers/gpu/arm/b_r16p0/backend/gpu/mali_kbase_pm_driver.c#L1631
> 
> Since even in kbase this is all behind an 'expert' config option, I'm 
> inclined to agree that just dropping it from panfrost unless and until 
> it proves necessary is probably preferable to adding more logic and 
> inscrutable register-magic.

Indeed - I'll post a patch removing it.

Thanks,

Steve

> Robin.
> 
> > 
> > Steve
> > 
> >>
> >> So the GPU is probed, but there's an issue when powering up the STACK, 
> >> not
> >> quite sure why, I'll try to have a deeper look, at some point.
> >>
> >> Thanks!
> >>
> >> Nicolas
> >>
> >> v2:
> >>   - Use sram instead of mali_sram as SRAM supply name.
> >>   - Rename mali@ to gpu@.
> >>   - Add dt-bindings changes
> >>   - Stacking patches after the device tree change that allow basic
> >>     probing (still incomplete and broken).
> >>
> >> Nicolas Boichat (7):
> >>    dt-bindings: gpu: mali-bifrost: Add Mediatek MT8183
> >>    arm64: dts: mt8183: Add node for the Mali GPU
> >>    drm/panfrost: Improve error reporting in panfrost_gpu_power_on
> >>    drm/panfrost: Add support for a second regulator for the GPU
> >>    drm/panfrost: Add support for multiple power domain support
> >>    RFC: drm/panfrost: Add bifrost compatible string
> >>    RFC: drm/panfrost: devfreq: Add support for 2 regulators
> >>
> >>   .../bindings/gpu/arm,mali-bifrost.yaml        |  20 ++++
> >>   arch/arm64/boot/dts/mediatek/mt8183-evb.dts   |   7 ++
> >>   arch/arm64/boot/dts/mediatek/mt8183.dtsi      | 104 +++++++++++++++++
> >>   drivers/gpu/drm/panfrost/panfrost_devfreq.c   |  18 +++
> >>   drivers/gpu/drm/panfrost/panfrost_device.c    | 108 ++++++++++++++++--
> >>   drivers/gpu/drm/panfrost/panfrost_device.h    |   7 ++
> >>   drivers/gpu/drm/panfrost/panfrost_drv.c       |   1 +
> >>   drivers/gpu/drm/panfrost/panfrost_gpu.c       |  15 ++-
> >>   8 files changed, 267 insertions(+), 13 deletions(-)
> >>
> > 
> > _______________________________________________
> > dri-devel mailing list
> > dri-devel@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/dri-devel