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]
Date:	Thu, 22 Oct 2009 18:22:32 -0500
From:	Jon Hunter <jon-hunter@...com>
To:	Tony Lindgren <tony@...mide.com>
CC:	"linux-arm-kernel@...ts.infradead.org" 
	<linux-arm-kernel@...ts.infradead.org>,
	"linux-omap@...r.kernel.org" <linux-omap@...r.kernel.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	Janusz Krzysztofik <jkrzyszt@....icnet.pl>
Subject: Re: [PATCH 05/10] omap1: Fix DSP public peripherals support for ams-delta


Tony Lindgren wrote:
> From: Janusz Krzysztofik <jkrzyszt@....icnet.pl>
> 
> DSP public peripherals used to work on OMAP1510 based (or all OMAP1 class?)
> machines as long as old dspgateway code were present in the l-o tree. For
> several months it is no longer included, breaking support for McBSP1 based
> audio on Amstrad Delta, for example.
> 
> This patch, derived from the old dspgateway code, corrects the problem for the
> board by simply taking the DSP out of reset state, I guess. That way, things
> should not break when a new dsp code is added to the tree, and the change can
> be reverted then.

A minor comment/correction here. Although this bit is called "DSP_RST" 
this does not actually release the DSP from reset. This bit actually 
releases the reset for the "priority registers (TIPB module), EMIF 
configuration registers, and the MPUI control logic (partially) in the 
DSP", thus allowing you to access the DSP peripherals via the MPUI. Bit 
1 of the same register, called "DSP_EN", actually releases the DSP reset.

> If there are any reports on McBSP1 or other DSP public peripherals not working
> for other OMAP1 machines (I've not heard of any for now), I can prepare a more
> general patch providing an extra include file with a helper function defined.

This would be necessary for all OMAP15xx based devices that use McBSP1 
(or McBSP3 for that matter). However, I am not sure if it is common for 
other boards to use McBSP1 for audio.

Jon
--
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