> We would use the API we worked earlier on (Dale, Andrey, John, ...). > To add support of fw preloaded task : > - The bestcomm.ko module would be used when bestcomm is completely > controlled by the kernel > - A different module but with the same exported function would be used > when the fw has a part to play in the init. That allows to customize a bunch > of the sdma init / sram mapping ... > - All the other code (task helpers / the .h / the driver api) would be > exactly > the same.
No. Two different modules is the wrong approach. I want to be able to build everything in the kernel (no modules) and still boot machines with both types. There should be a single implementation. I know bestcomm is fucked by design but still. > So the bestcomm modules maintain a list with all task loaded with a name and > a index attribute. (The index would be used when there is multiple > device with > the same name, like "psc". We could use names like "psc1", "psc2". But that > would imply string manipulation to "create" the name string ;) > > In the case of the "classic" (kernel handles it all), the table of task > is just > initially empty. But for the "custom" case, it's filled with whatever > the fw has > passed as infos. A single module should handle all cases though. If, for some reasons, it looks like that will cause a lot of additional code, them it can be internally split and we can have config options to enable only one way, but it should be possible to enable both. Ben. _______________________________________________ Linuxppc-embedded mailing list [email protected] https://ozlabs.org/mailman/listinfo/linuxppc-embedded
