Mark, please see below... On Fri, May 13, 2016 at 12:55:40PM +0100, Mark Brown wrote: > On Tue, Apr 26, 2016 at 01:01:05PM -0500, Andreas Dannenberg wrote: > > On Tue, Apr 26, 2016 at 06:29:36PM +0100, Mark Brown wrote: > > > > Is the device actually going to mess up if someone sends it something > > > else or is it just going to ignore the extra bits (given that it's doing > > > autodetection anyway). > > > well in any of the left-justified modes (which are the only ones the > > driver supports) the device takes and processes as many bits as it can > > given the clock and divider settings. Any extra bits provided will get > > ignored, and the next sync happens on the frame sync signal and not by > > counting bits so there is no downside also as confirmed by some bench > > testing I did feeding in 32-bit long frames for one channel. This seems > > like a case of preferring tolerance over strictly enforcing > > datasheet-advertised bit-widths. Will take out the check code. > > OK, accepting extra bits is fine. You should set sig_bits in the DAI so > userspace can see what's going on if it cares. I just had a quick look to see what sig_bits does, yes this is a good addition. Will post a follow-up patch based on the driver that you already accepted into your tree. (Btw I'm working on another codec driver and I don't stop getting positively surprised how flexible and powerful the overall ASoC framework is). Regards, Andreas > > Along these lines, earlier as I was rummaging through the existing > > drivers looking for a solution I could model after I noticed that > > most(?) ASoC codec drivers don't have any type of HW fault checking, at > > at least whatever drivers I looked at. Not sure why this is but given > > this discussion this seems like a general opportunity to make > > improvements. > > There are some with over temperature handling (eg, wm8962) but it's > relatively uncommon for observable protection features to be implemented > in silicon and even rarer for the interrupts to be hooked up (and hence > useful to support in software) unless there is also accessory detection > in the device. On older devices the required digital logic was often > excessively expensive and realistically only relatively high power > speaker drivers have much risk of something going wrong - things like > headphone outputs or smaller speaker drivers end up with protection from > their supplies collapsing well before the device is in physical danger. -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
