Re: [PATCH 1/4] iio: mxs-lradc: separate touchscreen and buffer virtual channels

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 18/01/15 02:19, Marek Vasut wrote:
> On Saturday, January 17, 2015 at 01:22:08 AM, Kristina Martšenko wrote:
> 
> Hi!

Hi!

> Good stuff, thank you! Just minor nitpicks below.
>
> [...]
> 
>> diff --git a/drivers/staging/iio/adc/mxs-lradc.c
>> b/drivers/staging/iio/adc/mxs-lradc.c index e0e91836eec1..fc65cd311be9
>> 100644
>> --- a/drivers/staging/iio/adc/mxs-lradc.c
>> +++ b/drivers/staging/iio/adc/mxs-lradc.c
>> @@ -214,11 +214,14 @@ struct mxs_lradc {
>>  	unsigned long		is_divided;
>>
>>  	/*
>> -	 * Touchscreen LRADC channels receives a private slot in the CTRL4
>> -	 * register, the slot #7. Therefore only 7 slots instead of 8 in the
>> -	 * CTRL4 register can be mapped to LRADC channels when using the
>> -	 * touchscreen.
>> -	 *
>> +	 * When the touchscreen is enabled, we give it two private virtual
>> +	 * channels: #6 and #7. This means that only 6 virtual channels (instead
>> +	 * of 8) will be available for buffered capture.
>> +	 */
>> +#define TS_VCH1		7
>> +#define TS_VCH2		6
> 
> Please use a bit more explicit name for the macro, it's really not clear what
> the macro represents from it's name. Something like TOUCHSCREEN_VCHANNEL1 might
> work better for example. What do you think ?

Sure, I tried to keep it short and similar to the TS_CH_YP (etc) macros,
but clearer is better, so I'll change it to TOUCHSCREEN_VCHANNEL1 in v2.

>> +
>> +	/*
>>  	 * Furthermore, certain LRADC channels are shared between touchscreen
>>  	 * and/or touch-buttons and generic LRADC block. Therefore when using
>>  	 * either of these, these channels are not available for the regular
> [...]
> 
> I also have a general question/idea here, it's explicitly not something I'd like
> to force upon you to implement. I see we have some kind of a hardware, which can
> sample up-to N inputs in parallel . Each input is muxed between M possible 
> sources . Is such a thing common in the ADC/DAC world ? Would it be worth to
> implement generic helper to handle this kind of a N:M mapping ? What do you all
> think please ?

Hmm, I don't know how other drivers do this, or if there's anything in
common. The IIO people will probably have a better idea, so I'll wait
for them to respond.

Kristina
_______________________________________________
devel mailing list
devel@xxxxxxxxxxxxxxxxxxxxxx
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel




[Index of Archives]     [Linux Driver Backports]     [DMA Engine]     [Linux GPIO]     [Linux SPI]     [Video for Linux]     [Linux USB Devel]     [Linux Coverity]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [Yosemite Backpacking]
  Powered by Linux