Hi Marek, hi Jonathan, while trying to implement a battery charger driver for the mx28 platform I came across your posts. Sorry to stir up an old thread but it was running the same way. On Jun 27, 2012, at 2:00 PM, Marek Vasut wrote: Dear Jonathan Cameron, > >> On 6/26/2012 8:02 PM, Marek Vasut wrote: >>> Dear Juergen Beisert, >>>> I tried a little bit with your driver. The disadvantage I see is, its >>>> claims all the free AD channels. But a few of them can also act as a >>>> touchscreen controller. Shouldn't be the driver handle the channel usage >>>> dynamically? >>> >>> I wonder, I'd rather see this driver behave as a composite driver, what >>> do you think? >> >> Alternative (though it's still in development) would be to use IIO >> as the ADC layer and sit the other parts on top. I am currently trying to go this route, the idea is to use the consumer api to get the required battery management data to the battery driver. As a foundation I used the driver provided by Freescale which uses the lradc directly which I found rather bad in the system context. Maybe one could map all the driver muxing and use specific parameters in explicitly named iio channels? But this could lead to permanent reconfiguring of the LRADC and maybe quite difficult handling of the measurements that arrive asynchronously. Also I don't seem to quite get the usage of iio_map_array_register() which seems to enable the consumer api access to the device. I found only one use of it in an example in max1363.c which confused me even more. How do I correctly provide the iio_map struct? What is the consumer_dev_name used for and which "namespace" should used there, is it the name used in a platform_driver struct or the instances name (given there can only be one internal mxs battery charger at a time)? Best regards, Peter-- To unsubscribe from this list: send the line "unsubscribe linux-iio" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
