[Openpvrsgx-devgroup] [PATCH 1/2] drm: pvrsgx: pvr-drv: Fix OCP handling with ioremap and reg access
ivo.g.dimitrov.75 at gmail.com
Mon Nov 15 22:37:05 CET 2021
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>:
>> 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,
Thanks and regards,
More information about the openpvrsgx-devgroup