[alsa-devel] [PATCH 00/10] ASoC: sta32x: Add device tree binding

Thomas Niederprüm niederp at physik.uni-kl.de
Thu Jan 22 21:46:00 CET 2015


Am Thu, 22 Jan 2015 14:12:57 +0100
schrieb Daniel Mack <daniel at zonque.org>:

> On 01/22/2015 02:05 PM, Lars-Peter Clausen wrote:
> > On 01/22/2015 12:01 AM, Thomas Niederprüm wrote:
> >> This patchset is the result of comparing the sta32x driver with
> >> the sta350 driver with the goal to make the sta32x driver device
> >> tree capable. In the merging process the coding style of the
> >> sta350 driver was adopted since it seemed more up to date. I did
> >> my best to break up the changes in logical chunks. Additionally
> >> some small fixes were added.
> >>
> >> The comparison with the sta350 lead to the following changes:
> >> - Switch to direct usage of the regmap API
> >> - Use the kernel gpio framework to control the reset pin of the
> >> sta32x
> >> - adopt calculation of mlck divider and extrapolation ratio from
> >> sta350
> >> - add device tree bindings
> >> - Change the Codecs DAI name to be coherent with the sta350 driver
> >>
> >> Moreover some minor fixes were added:
> >> - Add the status register
> >> - Fix bit shift value for the IDE bit in the CONFF register
> >> - Add description for the driver and I2C dependency in Kconfig
> >>
> > 
> > Good stuff.
> 
> Jup, looks all good to me, too. Thanks for working on this.
> 
> > Do you think we can actually merge the the two drivers into one.
> > They seem to be 90% line-by-line identical.

Indeed! Creating this patch-set involved a lot of copy and paste

> 
> That could work, yes, but it's not straight forward. When I compared
> the register sets some months ago, they seem to resemble largely, but
> there were lots of subtle differences. All of them would need to be
> handled at runtime.

I agree on all points.

> 
> I think the only way to figure whether it's worth it is to do the
> merge and have a look :)
> 

I agree that it was sensible to get this merged first and then try to
see if the drivers can be combined.

> 
> Daniel
> 



More information about the Alsa-devel mailing list