[Openpvrsgx-devgroup] [PATCH 1/2] drm: pvrsgx: pvr-drv: Fix OCP handling with ioremap and reg access

Ivaylo Dimitrov ivo.g.dimitrov.75 at gmail.com
Mon Nov 15 22:37:05 CET 2021


Hi Nikolaus,

On 31.10.21 г. 14:00 ч., H. Nikolaus Schaller wrote:
> Hi Ivo,
> 
> 
>> Am 31.10.2021 um 07:38 schrieb Ivaylo Dimitrov <ivo.g.dimitrov.75 at gmail.com>:
>>
>> Hi,
>>
>> On 23.10.21 г. 14:09 ч., H. Nikolaus Schaller wrote:
>>> Hi Tony,
>>>> Am 23.10.2021 um 12:12 schrieb Tony Lindgren <tony at atomide.com>:
>>>>
>>>> The OCP registers need to be configured for SGX on some omap variants
>>>> to route the SGX interrupt. However, this must not be done on omap34xx
>>>> as the OCP registers are not readable and reads will hang the system.
>>>> We currently have pvr-drv hang on omap3430 devices like n900 because of
>>>> trying read the OCP registers.
>>>>
>>>> We need to a combination of suitable ifdefs for each SoC for the OCP
>>>> regs, but that's not a nice solution. Let's just start getting rid of
>>>> the OCP related ifdefs and configure the OCP directly in the pvr-drv as
>>>> needed. We just need to reconfigure the OCP registers in the runtime PM
>>>> functions for now.
>>>>
>>>> Note that this still leaves SysClearInterrupts() doing a write to ack the
>>>> OCP interrupt. However looks like the write won't do anything on omap34xx
>>>> so we can leave it for now and remove it later when adding support for
>>>> interrupt handling to pvr-drv.
>>>>
>>>> Also sgx_jz4780 also configures OCP regs, but I suspect that code never
>>>> was enabled and was copied from earlier TI specific code. If sgx_jz4780
>>>> really uses the OCP regs, it needs at least the ocp_base configured.
>>>>
>>>> Let's also add pvr_sgx_readl() and pvr_sgx_writel() while at it to make
>>>> it easy to rewrite further features and make it clear that the OCP
>>>> register area is SoC specific and separate from the SGX registers.
>>>>
>>>> Reported-by: Ivaylo Dimitrov <ivo.g.dimitrov.75 at gmail.com>
>>>> Signed-off-by: Tony Lindgren <tony at atomide.com>
>>> looks good to me. Unfortunately I can't test the 1.17 setup any more.
>>> It looks as if the 1.17 user space code needs a libc version which
>>> only became available in Debian Bullseye but some other requirement
>>> needs something older that is no longer available in 11.1. So my SD
>>> card for the Pyra got broken after an apt-get upgrade. And I would have
>>> to look for backports or compiling older versions from source.
>>
>> Look at my other mail, you are now able to compile mesa with *proper* 1.17 pvr dri driver, so glibc 2.29 is no longer a requirement.
> 
> 
> Great work!!!
> 
> I hope I find time to look at it and find out how to make it work...
> 

actually there remains one blob (glslcompiler) that still needs 
glibc2.29, but, it is easy to by binary patches and turn that to a weak 
dependency, LMK and I'll provide the needed script if you want to try it.

> BTW: do you have access to an OMAP5 uEVM or OMAP5 Pyra?
> Would be interesting how well it works there (maybe combined with TILER HW rotation).
> 

No OMAP5 around, but results on droid4 (and even on Nokia N900) are more 
than promising, glmark2-es2 gives ~95 in landscape(TILER rotated) and 
~85 in portrait on droid4, glmark2-es2-drm - 37 on N900. Regarding OMAP5 
- AFAIK it has some issues with TILER so caching is disabled, but I 
don't know the details.

> Maybe then we could start another attempt to upstream at least the SGX glue for
> bindings and device tree.
> 

That would be great!

> Best regards and thanks for all your support,
> Nikolaus
> 

Thanks and regards,
Ivo


More information about the openpvrsgx-devgroup mailing list