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: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20130725230533.GH24642@n2100.arm.linux.org.uk>
Date:	Fri, 26 Jul 2013 00:05:33 +0100
From:	Russell King - ARM Linux <linux@....linux.org.uk>
To:	Mark Brown <broonie@...nel.org>
Cc:	Jean-Francois Moine <moinejf@...e.fr>,
	Liam Girdwood <lgirdwood@...il.com>,
	Jaroslav Kysela <perex@...ex.cz>, Takashi Iwai <tiwai@...e.de>,
	Rob Herring <rob.herring@...xeda.com>,
	alsa-devel@...a-project.org, linux-kernel@...r.kernel.org,
	devicetree@...r.kernel.org
Subject: Re: [PATCH 4/4] ASoc: kirkwood: add DT support

On Thu, Jul 25, 2013 at 08:19:05PM +0100, Mark Brown wrote:
> On Thu, Jul 25, 2013 at 11:14:59AM +0200, Jean-Francois Moine wrote:
> 
> > +	if (np) {
> > +		priv->burst = 128;		/* might be 32 or 128 */
> > +	} else if (data) {
> 
> When you posted this before I queried how and why the value might vary -
> I see the code is the same and I don't recall a reply.

This is the DMA burst size, and can be either 32 or 128 bytes according
to the docs.  Everyone seems to pass this as 128 bytes in their platform
data to date, which I guess is why its ended up being hard coded as 128.

However, whether it needs to be configurable or not is debatable - obviously
the hardware allows it, but that doesn't mean it has to be exposed.  If
ALSA has some kind of way of specifying a "low latency" mode where 128
byte vs 32 byte fetches would make a significant difference, then it may
be something to look at.

I'll retract my previous comment on this (about it being a DT property) -
given what it does, it isn't describing the hardware capabilities as I
first thought it was.

> > -	priv->clk = devm_clk_get(&pdev->dev, NULL);
> > +	priv->clk = devm_clk_get(&pdev->dev, "internal");
> >  	if (IS_ERR(priv->clk)) {
> > -		dev_err(&pdev->dev, "no clock\n");
> > +		dev_err(&pdev->dev, "no internal clock\n");
> >  		return PTR_ERR(priv->clk);
> >  	}
> 
> Does the code providing it already name the clock?  If not are updates
> needed to do that?
> 
> > -	priv->extclk = clk_get(&pdev->dev, "extclk");
> > +	priv->extclk = clk_get(&pdev->dev, "external");
> 
> Is the clock actually called extclk in the datasheet and so on?  If so
> it seems better to stick with that name.  Do any boards need updates for
> the new name?

"AU_EXTCLK" is the exact name (pasted out of the documentation).
I don't see any purpose to this name changing.
--
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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ