All of lore.kernel.org
 help / color / mirror / Atom feed
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.