On Fri, 5 Nov 2021 11:51:48 +0000 Machnikowski, Maciej wrote: > > I'm still struggling to understand your reasoning around not making > > EEC its own object. "We can do this later" seems like trading > > relatively little effort now for extra work for driver and application > > developers for ever. > > That's not the case. We need EEC and the other subsystem we wanted > to make is the DPLL subsystem. While EEC can be a DPLL - it doesn't have > to, and it's also the other way round - the DPLL can have numerous different > usages. We wanted to create a DPLL object to the extent that as a SW guy I don't understand the difference between that and an EEC. Whatever category of *PLL etc. objects EEC is, that's what we want to model. > When we add the DPLL subsystem support the future work will be as simple > as routing the EEC state read function to the DPLL subsystem. But if someone > decides to use a different HW implementation he will still be able to > implement his own version of API to handle it without a bigger DPLL block All we want is something that's not a port to hang whatever attributes exist in RTM_GETEECSTATE.
