Linux driver for MAX517/518/519

Jonathan Cameron jic23 at cam.ac.uk
Mon Jan 10 11:02:05 UTC 2011


On 01/10/11 09:27, Roland Stigge wrote:
> Hi,
> 
> On 01/09/2011 11:31 PM, Jonathan Cameron wrote:
>> Pretty clean and nice driver so it was an easy review and should
>> be trivial to fix up for a merge.
> 
> Thank you for your review - I will include the suggested changes in the
> next update.
> 
>> I don't think we have previously had a device that
>> allows setting multiple inputs together.
>> Two options come to mind that will generalize more
>> than your _both.
>>
>> output1&2_raw
>>
>> output_raw (suppress the index hence indicating that it sets both).
>>
>> What do you think is the clearest approach?
>> Which ever we pick it will also need proper documentation.  Whilst we
>> are here, please can you explain your use case?  From a datasheet
>> read I think the first channel is latched after the value byte is passed
>> then the second only after it's value has been passed over?
> 
> It's actually latched after the _complete_ transmission. See datasheet p.9:
> 
> "The data is transferred to the DAC’s output
> latch during the STOP condition following the transmis-
> sion. This allows both DACs of the MAX518/MAX519 to
> be updated simultaneously."
Ah, I missed that bit of text.  I guess the label (DAC0 INPUT LATCH set to full scale)
on figure 8b is just confusing then. Now you mention it, there is another
label at the stop condition saying the outputs change at the end. I'm not entirely
sure why they differentiate between DAC input latching and DAC output latching.
Surely people only care about the output.  Ah well, the delights of datasheet
interpretation.

Thanks for clearing that up! 
> 
> I will also document this in the driver to make it clearer.
Thanks,
> 
> That's also why I'm constructing the I2C transfer in this nonstandard
> way. Datasheet doesn't claim to support smbus, so I will change to the
> _ic2_ (non _smbus_) interface.
Good idea. If anyone really needs to get it to work on an smbus only adapter
we can put this back in, but until then readability is more important.
> 
> bye,
>   Roland
> 




More information about the devel mailing list