From: krishna <krishna.c@globaledgesoft.com>
To: Linux Kernel <linux-kernel@vger.kernel.org>
Subject: generating bus read cycles.
Date: Mon, 14 Feb 2005 11:27:27 +0530 [thread overview]
Message-ID: <42103DC7.1090107@globaledgesoft.com> (raw)
Hi all,
Can anyone explain that, how can (void)*reg_addr; generate a read cycle
on the bus.
And Is there any source which clearly explains about setup of DMA and
How to do DMA transfers.
Regards,
Krishna Chaitanya
/*
* The codec register read operation requires 3 read cycles on PXA250 in
order
* to guarrantee that good read data can be returned.
* _ _ _ _
*sync: _____| |_addr______| |_data1______| |__data2___| |__data_n__
*SDONE:__ _ _ _______________
* |_addr1____| |__addr2_____| |__addr_n____|
* ^
* First read begins
* ^ SDONE usually goes true in the latter half of AC
link frame
* ^ Second read begins, but data from codec hasn't
arrived yet!
* ^ second read ends, from 1 to 3
frames AFTER frame
* in which the address goes out!
* ^ Third read begins from one to 3
frames after theR
* initial frame, data from codec
guarranteed to bee
* available by this time.
* ^ read cycle ends.
* Note how reads can be pipelined, possibly useful for reading touch panel
* control registers or rapid sampling of codec gpio lines.
*/
static struct completion CAR_completion;
static DECLARE_MUTEX(CAR_mutex);
static u16 pxa_ac97_read(struct ac97_codec *codec, u8 reg)
{
u16 val = -1;
down(&CAR_mutex);
if (!(CAR & CAR_CAIP)) {
volatile u32 *reg_addr = (u32 *)&PAC_REG_BASE + (reg >> 1);
init_completion(&CAR_completion);
(void)*reg_addr;
wait_for_completion(&CAR_completion);
init_completion(&CAR_completion);
(void)*reg_addr; // This initiates second read cycle,
but codec data isnn't here yet...
wait_for_completion(&CAR_completion);
if (GSR & GSR_RDCS) {
GSR |= GSR_RDCS;
printk(KERN_CRIT __FUNCTION__": read codec
register timeout.\n"))
;
}
init_completion(&CAR_completion);
val = *reg_addr; // ahh, that's better. But we've just
started another cycle...
wait_for_completion(&CAR_completion); //this, along
with trailing delayy
, avoids hassle with CAR_CAIP bit
udelay(20); //don't come back too soon...
} else {
printk(KERN_CRIT __FUNCTION__": CAR_CAIP already set\n");
}
up(&CAR_mutex);
//printk("%s(0x%02x) = 0x%04x\n", __FUNCTION__, reg, val);
return val;
}
reply other threads:[~2005-02-14 5:59 UTC|newest]
Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=42103DC7.1090107@globaledgesoft.com \
--to=krishna.c@globaledgesoft.com \
--cc=linux-kernel@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.