[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20160227015143.GV18327@sirena.org.uk>
Date: Sat, 27 Feb 2016 10:51:43 +0900
From: Mark Brown <broonie@...nel.org>
To: Pierre-Louis Bossart <pierre-louis.bossart@...ux.intel.com>
Cc: Mark Rutland <mark.rutland@....com>,
Oder Chiou <oder_chiou@...ltek.com>,
alsa-devel@...a-project.org, Heiko Stuebner <heiko@...ech.de>,
Pawel Moll <pawel.moll@....com>,
Ian Campbell <ijc+devicetree@...lion.org.uk>,
linux-kernel@...r.kernel.org, Liam Girdwood <lgirdwood@...il.com>,
Takashi Iwai <tiwai@...e.com>,
Sugar Zhang <sugar.zhang@...k-chips.com>,
devicetree@...r.kernel.org, Rob Herring <robh+dt@...nel.org>,
Kumar Gala <galak@...eaurora.org>,
Bard Liao <bardliao@...ltek.com>
Subject: Re: [alsa-devel] [PATCH] ASoC: rt5640: add master clock handling for
rt5640
On Fri, Feb 26, 2016 at 09:43:15AM -0600, Pierre-Louis Bossart wrote:
> Yes there are documentation and helpers I looked into, but to the best of my
> limited knowledge not for the gate + dual-rate case. Then you jump to
> complicated configurations combining multiple base clocks that don't really
> make sense here. After one frustrating day of trying to wrap 100 lines of
> code into the clock framework I gave up and kept the simple custom driver.
> There is a single client for this clock so I don't quite see the
> benefits/ROI of mapping a simple piece of hardware with a complex model.
If the helpers aren't fitting your needs then surely just writing a
simple driver with set rate and enable callbacks isn't going to be too
hard? The wm831x driver was pretty trivial to write and seems to be on
a similar order of complexity to this.
Download attachment "signature.asc" of type "application/pgp-signature" (474 bytes)
Powered by blists - more mailing lists