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

[H. Nikolaus Schaller]

Hi,

> Am 13.02.2019 um 15:35 schrieb Tony Lindgren <tony at atomide.com>:
> 
> * H. Nikolaus Schaller <hns at goldelico.com> [190213 05:50]:
>>> Am 12.02.2019 um 21:18 schrieb Tony Lindgren <tony at atomide.com>:
>>> 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.
> 
> Hmm.
> 
>> 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).
> 
> So maybe we need the following hierarchy for the kernel driver:
> 
> 1. SoC glue device (power, clocks, dma maybe)
>    2. SGX glue device for shared resources
>       3.1 2d accelerated driver
>       3.2 3d sgx blob driver

Well, yes, but I am not sure if 2d and 3d have anything in common or
need the same basis.

If we just take out #3.1 for the moment we have

#1 patches for arch/arm
#2 the linux wrapper of the IMG/TI code in srvkm/env/linux and system/$DEVICE
#3.2 the IMG driver core everything else in srvkm

> 
>>> 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...
> 
> Well yeah :) We should concentrate first on parts #1, #2 and
> try to get a generic kernel driver into mergeable shape for
> various SoCs, right?

I'd keep #2 and #3.2 together because they are compiled into a
single driver.ko.

> 
> That is while keeping part #3.2 working.. But for merging stuff
> into the mainline kernel, it seems we should have parts #1, #2,
> and #3.1 working.

#2 already exists for 3d provided by TI and IMG. And the DDK 1.14
code supports other platforms in system/$DEVICE

> 
>>> 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.
> 
> Right part #3.1 is missing :)
> 
>> 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
> 
> OK so that's part #1 SoC glue layer, this we can merge separately for
> sure. There is still a hwmod and padata-quirks dependency because of the
> reset driver parts missing and clockdomain autoidle blocking missing.
> But that can be changed later and will not affect the sgx driver parts.
> 
> Maybe you should start posting those SoC glue layer parts for
> review after v5.1-rc1?

Yes, good idea. At least for the omap3 specific things I can do this.

> 
>> 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.
> 
> Well let's try to keep things working :)
> 
>>> 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.
> 
> OK sure. If the 2d parts are separate from the sgx core driver it
> makes sense.

As far asI know they are separate things. Maybe there is some connection
when trying to use both.

BR,
Nikolaus