Hi Matti,
On 07/11/2022 16:37, Vaittinen, Matti wrote:
I only had time to have a brief look at your code, but I have a few
quick questions.
I think it was Tomi who asked me the benefit of using MFD. In some cases
the digital interface towards pinctrl/GPIO or other functional blocks in
SER/DES is re-used from other products - or the blocks are re-used on
other products. Separating them in own platform-drivers is a nice way to
re-use drivers and avoid code duplication.
Is there anything that prevents us (or makes it difficult) from
refactoring a "monolithic" driver into an MFD later? If we see such IP
re-use, can we then move to an MFD?
I admit I have never written an MFD driver (but I have hacked with a few
years back). As I see it, the "subcomponents" in FPDLink ICs are more or
less tied to the FPDLink. It's not like they're independent. Compare to,
for example, a PMIC which provides regulators and GPIOs, and possibly
the only shared part between those two features are the pins.
So, I think I'm still wondering about the benefit...
In the current version I have the deser driver supporting UB960 and
UB9702. I guess I could split those into separate drivers, and using MFD
I could share lot of code between them. But I still can't see why that's
better than having both UB960 and UB9702 in the same driver (and, if the
amount of supported devices increases, perhaps dividing some parts to
separate files and using function points for a few things).
The benefit would be more obvious if there was some other type of IC
that uses the same IP subcomponents. Maybe the display side FPDLink
devices are such, but I have never done a deep dive in their
documentation. And, even then, I think I still have the question: can we
just move to an MFD later when the need comes?
Also, isn't the use or non-use of MFD strictly a driver private thing,
it should not affect any shared parts or shared designs? In other words,
if you have your ROHM hat on, why do you care how the UB9xx driver is
structured internally? ;)
Tomi
