> On Oct 23, 2023, at 8:08 PM, Jeff LaBundy <jeff@xxxxxxxxxxx> wrote: > >>>> Should the last two drivers live in drivers/mailbox? >>> >>> Adopting the mailbox framework seems like an excessive amount >>> of overhead for our requirements. >> >> MFD isn't a dumping a ground for miscellaneous functionality. >> >> MFD requests resources and registers devices. >> >> Mailbox functionality should live in drivers/mailbox. > > I think this is just a misnomer; the code uses the terms "mailbox" and > "mbox" throughout because the relevant registers are named as such in > the datasheet. > > Please correct me James, but I believe the datasheet uses this language > because both the host and the part itself have write access, meaning the > part may write a status code to the register after the host writes that > same register. There is no relation to IPC or the mbox subsystem. > > That being said, some of the functions currently placed in this MFD, > namely those related to haptic motor properties (e.g. f0 and ReDC), do > seem more appropriate for the input/FF child device. My understanding > is that those functions serve only momentary haptic click effects and > not the I2S streaming case; please let me know if I have misunderstood. > > I understand that no customer would ever build the to-be-added codec > driver _without_ the input driver, but the MFD must be generic enough > to support this case. Would a codec-only implementation use f0 and ReDC > estimation? If so, then these functions _do_ belong in the MFD, albeit > with some comments to explain their nature. Thank you for the clarifications, Jeff, and you are correct on all counts. I see that I spoke before having a good enough grasp on the mailbox framework. As regards the codec-only use case, they would not be used. So those functions do belong in the input driver.
