Dear Peter Turczak, > 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. We have some basic LRADC driver in upstream already, you should use that. See drivers/staging/iio/adc/mxs-lradc.c > 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 Best regards, Marek Vasut -- 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
