On Mon, May 19, 2014 at 05:36:38PM +0530, Tushar Behera wrote:
> Instead of setting the parent clock, setting the desired rate on
> XCLKOUT works for audio playback.
> Will it be okay to do a 'clk_set_rate(mclk, 2400)' in sound card
> driver or should we wait for Sylwester's patch to get
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 05/02/2014 10:26 PM, Mark Brown wrote:
> On Fri, May 02, 2014 at 10:26:08AM +0530, Tushar Behera wrote:
>> On 05/01/2014 10:10 PM, Mark Brown wrote:
>
>>> There's patches been posted by (IIRC) Sylvester Nawrocki for
>>> this which I think Mike was
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 05/02/2014 10:26 PM, Mark Brown wrote:
On Fri, May 02, 2014 at 10:26:08AM +0530, Tushar Behera wrote:
On 05/01/2014 10:10 PM, Mark Brown wrote:
There's patches been posted by (IIRC) Sylvester Nawrocki for
this which I think Mike was basically
On Mon, May 19, 2014 at 05:36:38PM +0530, Tushar Behera wrote:
Instead of setting the parent clock, setting the desired rate on
XCLKOUT works for audio playback.
Will it be okay to do a 'clk_set_rate(mclk, 2400)' in sound card
driver or should we wait for Sylwester's patch to get merged?
On Fri, May 02, 2014 at 10:26:08AM +0530, Tushar Behera wrote:
> On 05/01/2014 10:10 PM, Mark Brown wrote:
> > There's patches been posted by (IIRC) Sylvester Nawrocki for this which
> > I think Mike was basically happy with - I don't immediately see them in
> > -next though, but I may be looking
On Fri, May 02, 2014 at 10:26:08AM +0530, Tushar Behera wrote:
On 05/01/2014 10:10 PM, Mark Brown wrote:
There's patches been posted by (IIRC) Sylvester Nawrocki for this which
I think Mike was basically happy with - I don't immediately see them in
-next though, but I may be looking in the
On 05/01/2014 10:10 PM, Mark Brown wrote:
> On Thu, May 01, 2014 at 08:54:14AM -0700, Doug Anderson wrote:
>
>> This is exactly the thing (expected clock parenting) we agreed could
>> be put in the device tree I think. ...but I don't know that anyone
>> proposed exactly how that would work.
>
>
On Thu, May 01, 2014 at 08:54:14AM -0700, Doug Anderson wrote:
> This is exactly the thing (expected clock parenting) we agreed could
> be put in the device tree I think. ...but I don't know that anyone
> proposed exactly how that would work.
There's patches been posted by (IIRC) Sylvester
Hi,
On Thu, May 1, 2014 at 7:15 AM, Mark Brown wrote:
> On Thu, May 01, 2014 at 04:59:08PM +0530, Tushar Behera wrote:
>
>> Okay, I will extend the existing clock driver to support XCLKOUT.
>
> It may make more sense to add another clock driver for this clock
> depending on how things are done,
On Thu, May 01, 2014 at 04:59:08PM +0530, Tushar Behera wrote:
> Okay, I will extend the existing clock driver to support XCLKOUT.
It may make more sense to add another clock driver for this clock
depending on how things are done, I don't know.
> Of the many parents of XCLKOUT, we need to set
On 04/30/2014 11:33 PM, Mark Brown wrote:
> On Wed, Apr 30, 2014 at 05:30:39PM +0530, Tushar Behera wrote:
>
>> XCLKOUT mux register (0x10040a00) is not part of core clock SFR range,
>> rather it is part of pmu-system-controller node.
>
>> One option would be to add a clock provider for XCLKOUT.
On 04/30/2014 11:33 PM, Mark Brown wrote:
On Wed, Apr 30, 2014 at 05:30:39PM +0530, Tushar Behera wrote:
XCLKOUT mux register (0x10040a00) is not part of core clock SFR range,
rather it is part of pmu-system-controller node.
One option would be to add a clock provider for XCLKOUT. That
On Thu, May 01, 2014 at 04:59:08PM +0530, Tushar Behera wrote:
Okay, I will extend the existing clock driver to support XCLKOUT.
It may make more sense to add another clock driver for this clock
depending on how things are done, I don't know.
Of the many parents of XCLKOUT, we need to set
Hi,
On Thu, May 1, 2014 at 7:15 AM, Mark Brown broo...@kernel.org wrote:
On Thu, May 01, 2014 at 04:59:08PM +0530, Tushar Behera wrote:
Okay, I will extend the existing clock driver to support XCLKOUT.
It may make more sense to add another clock driver for this clock
depending on how things
On Thu, May 01, 2014 at 08:54:14AM -0700, Doug Anderson wrote:
This is exactly the thing (expected clock parenting) we agreed could
be put in the device tree I think. ...but I don't know that anyone
proposed exactly how that would work.
There's patches been posted by (IIRC) Sylvester
On 05/01/2014 10:10 PM, Mark Brown wrote:
On Thu, May 01, 2014 at 08:54:14AM -0700, Doug Anderson wrote:
This is exactly the thing (expected clock parenting) we agreed could
be put in the device tree I think. ...but I don't know that anyone
proposed exactly how that would work.
There's
On Wed, Apr 30, 2014 at 05:30:39PM +0530, Tushar Behera wrote:
> XCLKOUT mux register (0x10040a00) is not part of core clock SFR range,
> rather it is part of pmu-system-controller node.
> One option would be to add a clock provider for XCLKOUT. That would
> require me to extend current clock
On 04/30/2014 03:59 AM, Mark Brown wrote:
> On Fri, Apr 25, 2014 at 09:46:11AM +0530, Tushar Behera wrote:
>> On 04/24/2014 07:09 PM, Mark Brown wrote:
>
>>> defined. Why is that? Also, why is the secondary I2S playback stream
>>> not supported (this may be a reason to restrict to only the one
On 04/30/2014 03:59 AM, Mark Brown wrote:
On Fri, Apr 25, 2014 at 09:46:11AM +0530, Tushar Behera wrote:
On 04/24/2014 07:09 PM, Mark Brown wrote:
defined. Why is that? Also, why is the secondary I2S playback stream
not supported (this may be a reason to restrict to only the one I2S
On Wed, Apr 30, 2014 at 05:30:39PM +0530, Tushar Behera wrote:
XCLKOUT mux register (0x10040a00) is not part of core clock SFR range,
rather it is part of pmu-system-controller node.
One option would be to add a clock provider for XCLKOUT. That would
require me to extend current clock driver
On Fri, Apr 25, 2014 at 09:46:11AM +0530, Tushar Behera wrote:
> On 04/24/2014 07:09 PM, Mark Brown wrote:
> > defined. Why is that? Also, why is the secondary I2S playback stream
> > not supported (this may be a reason to restrict to only the one I2S
> > interface)?
> AFAICS, I2S driver
On Fri, Apr 25, 2014 at 09:46:11AM +0530, Tushar Behera wrote:
On 04/24/2014 07:09 PM, Mark Brown wrote:
defined. Why is that? Also, why is the secondary I2S playback stream
not supported (this may be a reason to restrict to only the one I2S
interface)?
AFAICS, I2S driver doesn't
On 04/24/2014 07:09 PM, Mark Brown wrote:
> On Wed, Apr 23, 2014 at 02:31:45PM +0530, Tushar Behera wrote:
>
>> +Required properties:
>> +- compatible : Can be one of the following,
>> +"google,snow-audio-max98090" or
>> +"google,snow-audio-max98095"
>> +-
On Wed, Apr 23, 2014 at 02:31:45PM +0530, Tushar Behera wrote:
> +Required properties:
> +- compatible : Can be one of the following,
> + "google,snow-audio-max98090" or
> + "google,snow-audio-max98095"
> +- samsung,i2s-controller: The phandle of the
On Wed, Apr 23, 2014 at 02:31:45PM +0530, Tushar Behera wrote:
+Required properties:
+- compatible : Can be one of the following,
+ google,snow-audio-max98090 or
+ google,snow-audio-max98095
+- samsung,i2s-controller: The phandle of the Samsung I2S0
On 04/24/2014 07:09 PM, Mark Brown wrote:
On Wed, Apr 23, 2014 at 02:31:45PM +0530, Tushar Behera wrote:
+Required properties:
+- compatible : Can be one of the following,
+google,snow-audio-max98090 or
+google,snow-audio-max98095
+-
Added machine driver to instantiate I2S based sound card on Snow
board. It has MAX98095 audio codec on board.
There are some other variants for Snow board which have MAX98090
audio codec. Hence support for MAX98090 is also added to this
driver.
Signed-off-by: Tushar Behera
---
Changes for V2:
Added machine driver to instantiate I2S based sound card on Snow
board. It has MAX98095 audio codec on board.
There are some other variants for Snow board which have MAX98090
audio codec. Hence support for MAX98090 is also added to this
driver.
Signed-off-by: Tushar Behera
28 matches
Mail list logo
