Hi Tony, > Am 13.02.2019 um 16:08 schrieb Tony Lindgren <tony@xxxxxxxxxxx>: > > * H. Nikolaus Schaller <hns@xxxxxxxxxxxxx> [190213 14:52]: >>> Am 13.02.2019 um 15:35 schrieb Tony Lindgren <tony@xxxxxxxxxxx>: >>> 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. > > OK > >> 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 > ... >> I'd keep #2 and #3.2 together because they are compiled into a >> single driver.ko. > > OK let's see what makes most sense. Yes, we will need a lot of more discussions about optimal solutions. Do you have suggestions for a dedicated mailing list? Or a common git repo to use? As said, I'd prefer kernel.org/staging and linux-omap (because we seem to be the largest group) because it would make things simpler. And there is another aspect which came to my mind just now. Having a separate ML + GIT needs activities to draw attention of other developers while sitting on kernel.org would automatically make use of the existing Linux announcement channels. Some 5.x-rc1 would simply include it. ELIXIR will cross-reference it. Patchwork will archive discussions. LKML will present patches to all potential developers. So we would make use of the existing communication machinery besides a ML. Having it separated needs also some HOWTO for integration and getting it compiled. So I see a lot of benefits. But this would need to get Greg into the boat or at least accept what we are doing and providing resources. You likely know him better than me. How should we contact him? Just add him to cc: or forward this (or a new mail)? BR and thanks, Nikolaus
