Am 12.02.2019 um 21:18 schrieb Tony Lindgren tony@atomide.com:
- H. Nikolaus Schaller hns@goldelico.com [190212 20:00]:
Am 11.02.2019 um 16:18 schrieb Tony Lindgren tony@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