Re: [PATCH v2 3/3] drm/panfrost: Add initial panfrost driver

From: Robin Murphy
Date: Fri Apr 05 2019 - 08:57:32 EST


On 03/04/2019 05:57, Rob Herring wrote:
[...]
+static int panfrost_clk_init(struct panfrost_device *pfdev)
+{
+ int err;
+ unsigned long rate;
+
+ pfdev->clock = devm_clk_get(pfdev->dev, NULL);
+ if (IS_ERR(pfdev->clock)) {

The DT binding says clocks are optional, but this doesn't treat them as
such.

Hum, I would think effectively clocks are always there and necessary
for thermal reasons.

Should the binding be updated to move clocks from "optional" to "required" then? Juno does actually have a GPU clock for DVFS, but the clk-scmi driver didn't seem to want to play nicely with either mali_kbase or panfrost DRM, so I've just been leaving it out of my DT for now (and mali_kbase was perfectly happy without).

+ spin_lock_init(&pfdev->mm_lock);
+
+ /* 4G enough for now. can be 48-bit */
+ drm_mm_init(&pfdev->mm, SZ_32M >> PAGE_SHIFT, SZ_4G);

You probably want a dma_set_mask_and_coherent() call for your 'real'
output address size somewhere - the default 32-bit mask works out OK for
RK3399, but on systems with RAM above 4GB io-pgtable will get very
unhappy about DMA bounce-buffering.

Yes, I have a todo for figuring out the # of physaddr bits in the mmu
setup (as this call is just relevant to the input address side).
Though maybe just calling dma_set_mask_and_coherent() is enough and I
don't need to know the exact number of output bits for the io-pgtable
setup?

True, io-pgtable itself only really depends on the input size, but in order for non-coherent pagtables to work correctly in general, the DMA mask does need to be set appropriately, at which point it may as well also be propagated into OAS for completeness (as we do in arm-smmu*).

FWIW I'm just gonna leave this quote here...

gpu_props->mmu.va_bits = KBASE_UBFX32(raw->mmu_features, 0U, 8);
gpu_props->mmu.pa_bits = KBASE_UBFX32(raw->mmu_features, 8U, 8);


Robin.