beaglebone audio hw notes

// McASP 0 has two IOSets on the BBB headers:
//
//	bbb	gpio	pin	f3		f4
//	P8.34	2.17	51	rx hclk		data 2
//	P8.35	0.08	52	rx clk		data 2
//	P8.33	0.09	53	rx fs		data 3
//	P8.32	0.11	55	tx hclk		data 3
//	P8.37	2.14	48	tx clk		-
//	P8.38	2.15	49	tx fs		-
//	P8.36	2.16	50	data 0		-
//	P8.31	0.10	54	data 1		-
//
// and
//
//	bbb	gpio	pin	f0		f2		f3
//	P9.28	3.17	103	rx hclk		data 2		-
//	P9.42	3.18	104	rx clk		data 2		asp 1 tx clk
//	P9.27	3.19	105	rx fs		data 3		asp 1 tx fs
//	P9.25	3.21	107	tx hclk (osc)	data 3		asp 1 data 1
//	P9.31	3.14	100	tx clk		-		-
//	P9.29	3.15	101	tx fs		-		-
//	P9.30	3.16	102	data 0		-		-
//	P9.41	3.20	106	data 1		-		asp 1 data 0
//
// As indicated, some pins in the second set can alternatively be used for
// McASP 1 instead.  McASP 1 has no other pinout on the BBB.
//
// An on-board 24.576 MHz oscillator can be optionally enabled to drive its
// signal onto pin 107 (P9.25) for use as audio master clock by McASP 0 and/or
// external components.
//
//
// Any set of synchronous signals with specific timing-relationship must come
// from the same IOSet, otherwise timings specified in datasheet are not
// guaranteed.  Note however that e.g. the delay from hclk input to clk is not
// specified, hence I see no reason to constrain hclk (if used) to to the same
// ioset as clk.
//
// McASP can operate with transmit and receive sections synchronized or they
// can be independent.  If independent, then different iosets can be used for
// the two sections of course.  If synchronized, the internal transmit clk/fs
// are also used as internal receive clk/fs.
//
// (CAUTION: the linux kernel driver currently only supports synchronized mode)
//
// Which signals are needed and what direction they have depend heavily on the
// extremely flexible configuration of McASP.  For example you could have fully
// asynchronous transmit and receive sections in I²S master mode with external
// reference clocks suited for 44.1 kHz input but 48 kHz output:
//
//	tx hclk	<-- master clock	(24 576 000 Hz)
//
//	tx clk	--> tx clk		( 3 072 000 Hz)
//	tx fs	--> tx fs		(    48 000 Hz)
//	data 0	--> tx data		( 2 × 32-bit )
//
//	rx hclk	<-- master clock	(11 289 600 Hz)
//
//	rx clk	--> rx clk		(   705 600 Hz)
//	rx fs	--> rx fs		(    44 100 Hz)
//	data 1	<-- rx data		( 2 × 16-bit )
//
//	(Note that clk is also known as bck (bit clock) and fs is also known as
//	lrck (left/right clock).  The official I²S terminology however is "sck"
//	for clk, "ws" (word select) for fs, and "sd" (serial data) for data.
//	This however conflicts with the common use of "sck" to denote system
//	clock, i.e. what McASP calls hclk (high-speed clock).
//
// Here's the other extreme, with tx/rx synchronized in slave mode on just a
// single clock line and the max amount of data crammed in both directions:
//
//	tx clk	<-- tx/rx clock		(49 152 000 Hz)
//	tx fs	<-- tx/rx frame sync	(    48 000 Hz)
//	data 0	--> tx channels 0-31	( 32 × 32-bit )
//	data 1	<-- rx channels 0-31	( 32 × 32-bit )
//	data 2	--> tx channels 32-63	( 32 × 32-bit )
//	data 3	<-- rx channels 32-63	( 32 × 32-bit )
//
// You can configure the direction of each data line, so you can trade number
// of inputs against number of outputs (in blocks of 32 channels), yielding
// the limit of max 128 in or out.  Beware that this configuration is barely
// within spec (max clock is 50 MHz), may not be supported by linux, and in
// general may be "fun" to get working reliably ;)
//
// Another example, with clk/fs going the same direction as the associated data,
// which helps to avoid any worries about timing closure.  It also gives more
// freedom of pin assignment since rx and tx can be in different iosets:
//
//	tx hclk	<-- master clock	(24 576 000 Hz)
//
//	tx clk	--> tx clk		(24 576 000 Hz)
//	tx fs	--> tx lrck		(    48 500 Hz)
//	data 0	--> tx ch 0-15		( 16 × 32-bit )
//	data 2	--> tx ch 16-31		( 16 × 32-bit )
//
//	rx clk  <-- rx clk		(24 576 000 Hz)
//	rx fs   <-- rx fs		(    48 000 Hz)
//	data 1	<-- rx ch 0-15		( 16 × 32-bit )
//	data 3	<-- rx ch 16-31		( 16 × 32-bit )
//
// If providing tx hclk is problematic you may need to sacrifice data 3 or just
// accept you're stuck with the 24 MHz main osc and e.g. a funky config like:
//
//	tx clk	--> tx clk		(24 000 000 Hz)
//	tx fs	--> tx lrck		(    62 500 Hz) or (    46 875 Hz)
//	data 0	--> tx ch 0-15		( 16 × 24-bit ) or ( 16 × 32-bit )
//	data 2	--> tx ch 16-31		( 16 × 24-bit ) or ( 16 × 32-bit )
//
// This may look weird but isn't always necessarily a problem, especially if an
// async sample rate converter is already somewhere in the chain.  (You can
// even get 48 kHz exactly by using 20-bit slots, 5 or 25 slots per frame.)
//
//
// Finally, the transmit section can be configured to directly produce output
// in S/PDIF or AES-3.  When enabled, it applies to all data lines configured
// for transmit, which will have two 20/24-bit channels each but all use the
// same metadata (channel status, user data, and validity information).  The
// receiver may still be used independently.
//
// For this mode clk must be 128 * fs and internally generated from hclk.  It
// cannot be supplied via the clk pin, though it could be output if you cared.
//
//	tx hclk	<-- master clock	(24 576 000 Hz)
//	data 0	--> tx ch 0-1		( S/PDIF or AES-3 )
//	data 1	--> tx ch 2-3		( S/PDIF or AES-3 )
//	data 2	--> tx ch 4-5		( S/PDIF or AES-3 )
//	data 3	--> tx ch 6-7		( S/PDIF or AES-3 )
//
// Using main osc instead of external master clock would yield 46 875 Hz.