On 2/8/22 10:28, Tomi Valkeinen wrote: > I'm curious, why do you think using MFDs makes the driver so much > cleaner? The current fpdlink driver is in one file, but, say, if we > split it to multiple files, based on the function, while still keeping > it as a single driver, would that be so much different from an MFD > solution? Is there something in the MFD approach that makes the code > simpler? Fair question. I personally have two reasons - one technical which I could just throw here and hope everyone buys it :) But I think the main reason for me to initially think of MFD is not a technical one. Last few years I've spent working with PMICs/chargers - which were MFD to the bone. Before that I worked on a proprietary clocking/all-purpose FPGA as well as with ASIC routing RP3/RP301 links + providing timing facilities / clocks. Those were also MFD devices - and one of those used MFD drivers, the other didn't although it really should have. So the non technical reason for me is that I am used to seeing multi-function devices implemented as MFD devices - hence I immediately saw the SERDES as one too. One the technical benefit from MFD is that it (in many cases) allows one to use standard way to re-use code. Eg, it's not a rare case that same HW blocks are used in many projects. One can for example see three different PMICs, all having same RTC and clk blocks, while different regulators and GPIOs - or some just omitting one of those. MFD allows 'collecting' these IP blocks under different umbrellas by kicking same subdevices alive via different MFD devices in a standard way. The IP block (say GPIO controller) we are driving can be implemented on SER connected by FPDLINK III to DES - or it can be implemented in PMIC - the absolutely same standrd (mfd sub) platform GPIO driver can be used in both cases. Other than that, the use of MFD allows one to write pinctrl/gpio driver as any pinctrl/gpio platform device driver. It will be looking familiar to anyone who has worked with pinctrl/gpio - even if he has never seen media/v4l2 ;) This is where my thought of clarity came from. Rest is slightly offtopic - you can stop reading. I am not sure how TI does this and if you know whether same blocks can be used in other devices. I just have learned never to trust it when a HW engineer (in Nokia, Rohm or other company) tells me "this is the last IC using this technology". It may be my problem though as nor do I buy it if someone says me: "the next version will be just same to this previous - there is no software impact" :rolleyes: I for example once heard that when the "next product" maintained same register offsets for some functions - but did add new ones - and changed the registers from 16bit => 32bit and connecting bus from PCIe => I2C... I remember that project with a nicknames 're-estimate' 'reschedule' and 'panic-button' :) Yours -- Matti -- The Linux Kernel guy at ROHM Semiconductors Matti Vaittinen, Linux device drivers ROHM Semiconductors, Finland SWDC Kiviharjunlenkki 1E 90220 OULU FINLAND ~~ this year is the year of a signature writers block ~~
