public inbox for ecos-devel@sourceware.org
 help / color / mirror / Atom feed
* cyg_drv_dsr_lock usage
@ 2011-09-21  0:43 Michael Bergandi
  2011-10-06 16:53 ` Michael Bergandi
  0 siblings, 1 reply; 3+ messages in thread
From: Michael Bergandi @ 2011-09-21  0:43 UTC (permalink / raw)
  To: eCos Developer List

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

^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: cyg_drv_dsr_lock usage
  2011-09-21  0:43 cyg_drv_dsr_lock usage Michael Bergandi
@ 2011-10-06 16:53 ` Michael Bergandi
  2011-10-11 19:42   ` Sergei Gavrikov
  0 siblings, 1 reply; 3+ messages in thread
From: Michael Bergandi @ 2011-10-06 16:53 UTC (permalink / raw)
  To: eCos Developer List

Anyone?

-- 
Mike

^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: cyg_drv_dsr_lock usage
  2011-10-06 16:53 ` Michael Bergandi
@ 2011-10-11 19:42   ` Sergei Gavrikov
  0 siblings, 0 replies; 3+ messages in thread
From: Sergei Gavrikov @ 2011-10-11 19:42 UTC (permalink / raw)
  To: Michael Bergandi; +Cc: eCos Developer List

On Thu, 6 Oct 2011, Michael Bergandi wrote:

> Anyone?

[story entirely]
http://ecos.sourceware.org/ml/ecos-devel/2011-09/msg00003.html

That's what I+Google found. There was one expert explanation by the
topic in the ecos-discuss list

http://ecos.sourceware.org/ml/ecos-discuss/2003-03/msg00178.html

It seems to me that in some cases you would get more help (=hands)
through the eCos discuss list and ... search engines :-)

Thus, I found/saw no issues with in the posted snippet of the code.

Sergei

^ permalink raw reply	[flat|nested] 3+ messages in thread

end of thread, other threads:[~2011-10-11 19:42 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2011-09-21  0:43 cyg_drv_dsr_lock usage Michael Bergandi
2011-10-06 16:53 ` Michael Bergandi
2011-10-11 19:42   ` Sergei Gavrikov

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).