2014-11-03 16:41 GMT+03:00 Linus Walleij <linus.walleij@xxxxxxxxxx>: > On Fri, Oct 31, 2014 at 10:54 AM, Dmitry Eremin-Solenikov > <dbaryshkov@xxxxxxxxx> wrote: >> 2014-10-31 10:42 GMT+03:00 Linus Walleij <linus.walleij@xxxxxxxxxx>: > >>> It seems some DAC handling is part of the MFD driver, and we recently >>> discussed that MFD should not be doing misc stuff but mainly act as >>> arbiter and switching station. >>> >>> Can you please move the DAC parts of the driver to >>> drivers/iio/dac? >>> >>> The IIO DAC subsystem will likely add other goodies to >>> the driver for free and give a nice API to consumers. >> >> I wanted this part to be as simple as possible. I will look into IIO >> DAC subsystem. >> The DAC is as simple 2 channel 8-bit i2c device connected to a separate i2c bus >> controlled through a register in LoCoMo device. One channel is used >> for backlight, >> other will be used for volume control. So (in theory) I can add the >> following device >> chain: locomo -> i2c-locomo -> m62332 -> IIO DAC client. However isn't that >> quite an overkill for just backlight & volume control? Please advice me on this. > > The point is still the same: no unrelated code in drivers/mfd, > then either use IIO DAC as a middle layer or sink the DAC handling > into respective subdriver, i.e. push it into the backlight or > volume directly then. The problem is that the DAC is equally used by backlight and by sound device (WIP). What about true i2c device driver sitting in drivers/misc and exporting a regmap of 2 8-bit registers? -- With best wishes Dmitry -- To unsubscribe from this list: send the line "unsubscribe linux-input" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
