On Fri, 5 Nov 2021 11:51:48 +0000 Machnikowski, Maciej wrote:
quoted
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.