public inbox for ecos-devel@sourceware.org
 help / color / mirror / Atom feed
From: Michael Bergandi <mbergandi@gmail.com>
To: eCos Developer List <ecos-devel@ecos.sourceware.org>
Subject: cyg_drv_dsr_lock usage
Date: Wed, 21 Sep 2011 00:43:00 -0000	[thread overview]
Message-ID: <CAOHvnTPHcDb5drmTpDH-imRxG5VRA8b1AkHKVykc4FhRkjCxhQ@mail.gmail.com> (raw)

Hi all,

I have recently written an eCos I2C driver for a Freescale mx27
processor. The driver is working. However, I have some questions
whether what I have done is the right way or if I have used some calls
incorrectly. cyg_drv_drs_lock and unlock are of particular interest. I
referenced the existing i2c_mcf52xx and i2c_lpc2xxx drivers as I was
developing mine.

The driver is pretty simple. It is probably most closely modeled after
the lpc2xxx driver in that I do most of my work in the ISR, which is
pretty minimal. Using a single byte TX as an example should give the
idea. The cyg_i2c_tx call is received by the driver with the usual
parameters. I2C module is setup and enabled with interrupts. The slave
address is shifted with the read/write bit set. Send the start signal.
Send the slave address. I2C module interrupts. In the ISR, if the
address was acked, I send the data byte, exit ISR. Get the next
interrupt from the ISR. Set the completion flag, signal the DSR to
notify the driver the transaction is finished.

After the transaction was kicked off by sending the address, the
driver then waits for the transaction to finish in this call:

static void wait_for_xfer_completion(cyg_mxc_i2c_extra_t *extra)
{
	/* lock the driver and dsr and wait for the transfer to complete */
	cyg_drv_mutex_lock(&extra->i2c_lock);
	cyg_drv_dsr_lock();
	cyg_drv_interrupt_unmask(extra->i2c_isrvec);
    while (!(extra->i2c_flag & (I2C_FLAG_XFER_COMPLETE | I2C_FLAG_ERROR))) {
        cyg_drv_cond_wait(&extra->i2c_wait);
    }
	cyg_drv_interrupt_mask(extra->i2c_isrvec);
	cyg_drv_dsr_unlock();
    cyg_drv_mutex_unlock(&extra->i2c_lock);
}

My questions are:
Does anyone see any problems with this?
Is the DSR lock really necessary?
Should this be ordered differently?

One more note that may affect responses. This driver is used to handle
both I2C buses with multiple devices on each bus.

Thank you for any information you can provide.

-- 
Mike

             reply	other threads:[~2011-09-21  0:43 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-09-21  0:43 Michael Bergandi [this message]
2011-10-06 16:53 ` Michael Bergandi
2011-10-11 19:42   ` Sergei Gavrikov

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=CAOHvnTPHcDb5drmTpDH-imRxG5VRA8b1AkHKVykc4FhRkjCxhQ@mail.gmail.com \
    --to=mbergandi@gmail.com \
    --cc=ecos-devel@ecos.sourceware.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).