Hi
>
> Older GC300 revisions have their power registers at an offset of 0x200
> rather than 0x100.
>
> Signed-off-by: Doug Brown <doug@xxxxxxxxxxxxx>
> ---
> drivers/gpu/drm/etnaviv/etnaviv_gpu.h | 16 ++++++++++++++--
> 1 file changed, 14 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/etnaviv/etnaviv_gpu.h b/drivers/gpu/drm/etnaviv/etnaviv_gpu.h
> index 85eddd492774..b375612df862 100644
> --- a/drivers/gpu/drm/etnaviv/etnaviv_gpu.h
> +++ b/drivers/gpu/drm/etnaviv/etnaviv_gpu.h
> @@ -10,6 +10,8 @@
> #include "etnaviv_gem.h"
> #include "etnaviv_mmu.h"
> #include "etnaviv_drv.h"
> +#include "common.xml.h"
> +#include "state_hi.xml.h"
>
> struct etnaviv_gem_submit;
> struct etnaviv_vram_mapping;
> @@ -149,14 +151,24 @@ struct etnaviv_gpu {
> unsigned long base_rate_shader;
> };
>
> +static inline u32 gpu_fix_reg_address(struct etnaviv_gpu *gpu, u32 reg)
> +{
> + /* Power registers in GC300 < 2.0 are offset by 0x100 */
> + if (reg >= VIVS_PM_POWER_CONTROLS && reg <= VIVS_PM_PULSE_EATER &&
> + gpu->identity.model == chipModel_GC300 &&
> + gpu->identity.revision < 0x2000)
> + reg += 0x100;
> + return reg;
> +}
> +
> static inline void gpu_write(struct etnaviv_gpu *gpu, u32 reg, u32 data)
> {
> - writel(data, gpu->mmio + reg);
> + writel(data, gpu->mmio + gpu_fix_reg_address(gpu, reg));
> }
>
> static inline u32 gpu_read(struct etnaviv_gpu *gpu, u32 reg)
> {
> - return readl(gpu->mmio + reg);
> + return readl(gpu->mmio + gpu_fix_reg_address(gpu, reg));
> }
>
I had a quick look at what vivantes kernel driver did. It uses a per
gpu instance variable powerBaseAddress
that gets set accordingly. I am not sure if I really like the
gpu_fix_reg_address(..) idea, as it gets called on every
register read and write. For me I see two other possible solutions:
1) Add two seperate helpers ala gpu_read_power() and gpu_write_power()
where we do the if beast.
2) Add a power register offset variable to etnaviv_gpu and explicitly
use it on for reads and writes - like the Vivante driver does.
But that's just my personal opinion. Can't wait to hear what Lucas thinks.
--
greets
--
Christian Gmeiner, MSc
https://christian-gmeiner.info/privacypolicy
