On Thu, Oct 31, 2013 at 10:32:00AM -0500, Matt Sealey wrote: > On Wed, Oct 30, 2013 at 8:28 PM, Mark Brown <broonie@xxxxxxxxxx> wrote: > > Please consider prioritising this over writing e-mails; talking about > > device tree does often seem more popular than solving the harder > > problems. > If it doesn't get talked about, what happens is people copy paste crap ... > like writing any because it mostly already exists. Device trees aren't > something that appeared a year and a half ago and are new > technology.). These empty discussions aren't anything new either. If we just keep on endlessly going through the basics over and over again without any associated code this just reinforces the perception that people are more focused on talking than on actually accomplishing anything. Lengthy reiterations of design discussions won't move things forwards. This is why I keep asking you to review and engage with the prior discussion or to do concrete things to improve the situation. > Why some of those internal names don't match the manuals despite the > binding saying they do. It's because if you go through history of the Do you see any specific issues here? It sounds like you're perfectly aware of what the bindings are supposed to be doing with routing signals to and from CODECs and have found some errors but you haven't told us what those are. Like I keep saying, do concrete things to move things forwards. > All of which exist here. There are levels of indirection for a good > reason, I understand that, but in this implementation > card->set_bias_level calls functions which do purely codec-level > operations (set fll/mclk/sysclk), codec->set_bias_level does it's > obviously purely codec-level operations, and then > card->set_bias_level_post finishes up by doing some, again, > codec-level operations. To repeat myself yet again: what is done to the CODEC here is system dependent. This includes interaction with other components in the system.
Attachment:
signature.asc
Description: Digital signature
