From: Franck JULLIEN <franck.jullien@gmail.com>
To: barebox <barebox@lists.infradead.org>
Subject: Fwd: [RFC PATCH 2/3] spi: add more spi transfer functions
Date: Fri, 24 Jun 2011 15:43:02 +0200 [thread overview]
Message-ID: <BANLkTin8MBGK+jfP63AHj_OMmy==BTjsiQ@mail.gmail.com> (raw)
In-Reply-To: <BANLkTin9gmGY+CApY98wEX_qTkoAgKcU6A@mail.gmail.com>
[-- Attachment #1.1: Type: text/plain, Size: 1648 bytes --]
Hi Hubert,
2011/6/24 Hubert Feurstein <h.feurstein@gmail.com>
> Hi Franck,
>
> 2011/6/23 Franck JULLIEN <franck.jullien@gmail.com>:
> > Hello, I have a question regarding the SPI spi_write_then_read function.
> >
> [snip]
> >> +int spi_write_then_read(struct spi_device *spi,
> >> + const void *txbuf, unsigned n_tx,
> >
> > Could you explain me why const is used here ?
> Because this function will *not* write to the data of txbuf. With the
> const here, this is
> ensured at least at syntax level.
>
OK.
>
> [snip]
> >
> > Then we call spi_sync then master->transfer. In this last function we
> have:
> > list_for_each_entry (t, &mesg->transfers, transfer_list) {
> > const u32 *txbuf = t->tx_buf; <--- point to zero when x[1] right ?????
> > u32 *rxbuf = t->rx_buf; <--- point to zero when x[0] right ?????
> > int i = 0;
> > while(i < t->len >> 2) {
> > rxbuf[i] = imx->xchg_single(imx, txbuf[i]);
> > i++;
> > }
> > }
> > What am I missing ???
> Your transfer function has to handle this correctly:
> while(i < t->len >> 2) {
> u32 txval = txbuf ? txbuf[i] : 0
> u32 rxval = imx->xchg_single(imx, txval);
> if (rxbuf)
> rxbuf[i] = rxval;
> i++;
> }
>
That's what I was thinking about. The code above is from imx_spi.c. I am
currently
writing an Altera spi driver that's why I was looking at this...
> If no txbuf is available then simply transfer 0, if no rxbuf is
> available then throw away the result.
> BTW, I'm not sure if the above transfer-handler is able to handle 8bit
> transfers correctly (because of len >> 2).
>
>
I agree.
> Hope this helps.
>
> Best Regards
> Hubert
>
Thanks,
Franck.
[-- Attachment #1.2: Type: text/html, Size: 2921 bytes --]
[-- Attachment #2: Type: text/plain, Size: 149 bytes --]
_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox
next prev parent reply other threads:[~2011-06-24 13:43 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-06-20 21:46 [RFC PATCH 1/3] spi: add platform_data pointer to spi_board_info Hubert Feurstein
2011-06-20 21:46 ` [RFC PATCH 2/3] spi: add more spi transfer functions Hubert Feurstein
2011-06-23 19:47 ` Franck JULLIEN
2011-06-24 13:12 ` Hubert Feurstein
[not found] ` <BANLkTin9gmGY+CApY98wEX_qTkoAgKcU6A@mail.gmail.com>
2011-06-24 13:43 ` Franck JULLIEN [this message]
2011-06-20 21:46 ` [RFC PATCH 3/3] eeprom: add at25 eeprom driver Hubert Feurstein
2011-06-21 11:57 ` [RFC PATCH 1/3] spi: add platform_data pointer to spi_board_info Sascha Hauer
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='BANLkTin8MBGK+jfP63AHj_OMmy==BTjsiQ@mail.gmail.com' \
--to=franck.jullien@gmail.com \
--cc=barebox@lists.infradead.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