* H. Nikolaus Schaller hns@goldelico.com [190213 05:50]:
Am 12.02.2019 um 21:18 schrieb Tony Lindgren tony@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
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?
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.
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?
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.
Regards,
Tony