linux-kernel - Re: [alsa-devel] [PATCH v3] ARM: kirkwood: extend the kirkwood i2s driver for DT usage

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20130723151956.GX24642@n2100.arm.linux.org.uk>
Date:	Tue, 23 Jul 2013 16:19:56 +0100
From:	Russell King - ARM Linux <linux@....linux.org.uk>
To:	Mark Brown <broonie@...nel.org>
Cc:	Sebastian Hesselbarth <sebastian.hesselbarth@...il.com>,
	Jean-Francois Moine <moinejf@...e.fr>,
	alsa-devel@...a-project.org, Takashi Iwai <tiwai@...e.de>,
	linux-kernel@...r.kernel.org, Liam Girdwood <lgirdwood@...il.com>,
	Rob Herring <rob.herring@...xeda.com>,
	devicetree-discuss@...r.kernel.org
Subject: Re: [alsa-devel] [PATCH v3] ARM: kirkwood: extend the kirkwood i2s
	driver for DT usage

On Tue, Jul 23, 2013 at 04:01:50PM +0100, Mark Brown wrote:
> On Tue, Jul 23, 2013 at 03:30:57PM +0200, Sebastian Hesselbarth wrote:
> > On 07/23/13 15:20, Mark Brown wrote:
> 
> > >Why would this be required?  The driver is already asking for multiple
> > >clocks...
> 
> > The driver is asking for multiple *DT based* clocks. Legacy
> > platform_data has never been updated to reflect that. Mainly because
> > multiple clocks are only supported on Dove, which has no active non-DT
> > board in mainline.
> 
> Why would platform data have anything to do with this?  To repeat again
> the way the clocks are mapped should be totally transparent to the
> driver requesting them, if it isn't then the driver is not using the API
> properly.

Total rubbish.  Of course the driver needs to know what the clocks are,
so that it can program its hardware accordingly.

What you have here is an audio block which has two clock inputs.  One
clock is the system clock, whose rate can be adjusted but has a massive
impact on the rest of the system.  The other clock input is via an
external pin.

Internally, in one of the audio blocks registers is a set of control bits
which select which clock is to be used to generate the internal timing
for the block, and a divisor on that input.

>From that description, anyone can see that it is absolutely required for
the driver to know which clock is which, so it can program the clock
input selection bit appropriately.

In this case, it has always been the rule with the clock API that it
shall be used as:

	clk_get(device, "internal");

to get the internal clock, and:

	clk_get(device, "external");

to get the external clock - or whatever names are appropriate to name the
clock _inputs_.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/