[Letux-kernel] Lay common foundation to make PVR/SGX work without hacks on OMAP34xx, OMAP36xx, AM335x and potentially OMAP4, OMAP5

[H. Nikolaus Schaller]

> Am 12.02.2019 um 21:18 schrieb Tony Lindgren <tony at atomide.com>:
> 
> * H. Nikolaus Schaller <hns at goldelico.com> [190212 20:00]:
>>> Am 11.02.2019 um 16:18 schrieb Tony Lindgren <tony at atomide.com>:
>>> And just to add some notes I've already mentioned before, there's nothing
>>> stopping us from having a generic mainline kernel module for slow 2d
>>> acceleration based on what we already have for sgx540 in
>>> drivers/gpu/drm/gma500/psb_drv.c.
>>> 
>>> If anybody is interested in that, grep for PSB_RSGX32 and PSB_WSGX32
>>> in the mainline kernel tree. That way at least the generic parts for
>>> regulators, clocking, and interrupt handling could be upstreamed. I
>>> think only the SoC specific wrapper hardware is different, the SGX
>>> code should be generic.
>> 
>> Interesting. But to me it seems to be completely orthogonal to the
>> SGX DDK. And since it is an Intel GMA, there is probably much different
>> clock and register integration into an Intel processor than for OMAP or
>> other SoC.
> 
> To me it seems just the wrapper IP is different. If you look at
> drivers/gpu/drm/gma500/accel_2d.c it seems to be only accessing
> the sgx registers based on a quick glance. So it's already quite
> generic.

Hm. I have looked into it and it did not remain me of any bit of the
3D driver.

The 3D driver does not directly or obviously handle SGX registers.
It provides a wrapper around Linux API into some generic calls
doing dma setup, enabling clock, doing reset (not of SGX registers
but making the specific SoC toggle the internal Reset line going
to the SGX module).

> Also there's the rule of thumb requirement Tomi mentioned earlier.
> That is the driver must provide actual hardware acceleration and
> not just a way of enabling out-of-tree binary blobs if I recall.

So I think we are talking about two drivers and projects...

> So from that point of view a generic sgx 2d acceleration driver
> to drivers/gpu is probably a better place to start upstreaming
> rather than try to stuff vendor specific hacks on top of
> imagination hacks into drivers staging :)
> 
> Sure it won't help with the 3d parts except we then have the
> clocks and interrupts etc handled in a generic way.

That is what I do not yet see. Especially since there is no code
for 2d for other SoC than Intel. But there is working code
for OMAP3 and others. Basically we need to provide some
hw-mods, pdata-quirks, the missing DT nodes for clocks.

If I remember correctly that are ca. 10 already existing kernel
APIs which are just incomplete.

The patch set I have to get what seems to be needed is:

e0df0c9972d2 HACK: ARM: OMAP2+: omap_hwmod.c: keep am33xx+sgx CM_GFX_L3_CLKSTCTRL and CM_GFX_GFX_CLKCTRL enabled after deassert_reset.
be04c998efc2 Add sgx544 to omap5 device tree v2
2a7f3b0d186f ARM: dts: am43x: Add node for SGX
58c78f83dd91 ARM: DTS: OMAP3: add gfx node for omap34xx and omap36xx gpu
c401c3019d36 ARM: DTS: AM33xx: adjust gfx node for am33xx gpu
649de88b27c4 ARM: DTS: AM335x: Add SGX DT node
c295a42d06d4 Add sgx to omap54xx hwmod tables
d96b2e3eb15c ARM: OMAP2+: omap_hwmod_3xxx_data.c: we do not need the module_offs and module_bit
f3ef939270e5 ARM: OMAP2+: omap_hwmod_3xxx_data.c: add hwmods to make sgx working
c0a1c4f34c6b ARM: OMAP2+: pdata-quirks: add SGX support for OMAP3 and am33xx
15bf4d5f066b ARM: OMAP2+: pdata-quirks: add assert_reset to gfx for completeness
92c282f7db7e ARM: OMAP3: Clock: Add IDLEST definitions for SGX
fc59993666c3 ARM: OMAP2+: Use pdata-quirks for sgx deassert_hardreset

and they affect these files:

arch/arm/boot/dts/am33xx.dtsi
arch/arm/boot/dts/am4372.dtsi
arch/arm/boot/dts/omap3.dtsi
arch/arm/boot/dts/omap36xx.dtsi
arch/arm/boot/dts/omap5.dtsi
arch/arm/mach-omap2/cm-regbits-34xx.h
arch/arm/mach-omap2/omap_hwmod.c
arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
arch/arm/mach-omap2/omap_hwmod_54xx_data.c
arch/arm/mach-omap2/pdata-quirks.c
include/linux/platform_data/sgx-omap.h

So rewriting everything to sit on a not yet existing 2d setup
seems to be a very long deviation (for 3d) and I expect a nightmare
for debugging and getting it work.

> And then
> the 3d parts in theory should become generic too and with much
> less of a diffstat..

So my proposal is to keep 2d and 3d separated. And start to merge
only after we have both working - and better understand the code.

BR,
Nikolaus