mail archive of the barebox mailing list
 help / color / mirror / Atom feed
From: Antony Pavlov <antonynpavlov@gmail.com>
To: Johannes Stezenbach <js@sig21.net>
Cc: barebox <barebox@lists.infradead.org>
Subject: Re: SPI chip select problem
Date: Mon, 25 Jun 2012 14:07:34 +0400	[thread overview]
Message-ID: <CAA4bVAHqT37AuMbBUia4FGSdayQXvSYJ63hok_fYSaZpZHQK6A@mail.gmail.com> (raw)
In-Reply-To: <20120625085323.GA10406@sig21.net>

On 25 June 2012 12:53, Johannes Stezenbach <js@sig21.net> wrote:
> Hi,
>
> On Mon, Jun 25, 2012 at 11:45:06AM +0400, Antony Pavlov wrote:
>> I have added spi controller driver for one of my MIPS boards and
>> found, that there is a problem with chip select.
>>
>> During initialisation we call *_spi_setup() method. It switch chip
>> select and frequency for every probing spi slave chip.
>> But after initialisation __we never__ call this method. So if I have
>> more than 1 spi slave chip, I can use only last of them.
>>
>> There is the 'cs_change' flag for *_spi_transfer() method, but this
>> flag does not used at all!
>
> altera_spi.c and mic_spi.c use it, but often this is not needed (e.g. for
> SPI flashes) so to keep the code simple and small it might be better
> to not implement cs_change handling.

But I have not found any common code where cs_change is managed.

>
>> I have made quick-and-dirty patch:
>>
>> --- a/drivers/spi/spi.c
>> +++ b/drivers/spi/spi.c
>> @@ -196,6 +196,8 @@ EXPORT_SYMBOL(spi_register_master);
>>
>>  int spi_sync(struct spi_device *spi, struct spi_message *message)
>>  {
>> +       spi->master->setup(spi);
>> +
>>         return spi->master->transfer(spi, message);
>>  }
>
> I noticed this issue, too, but since barebox spi code is similar
> to linux code I'd like to point out linux drivers must not modify the
> chip select in ->setup().  Since bare box only does synchronous transfers
> it isn't an issue, but in linux ->setup() is called when
> a new message is queued, at this time the previous message
> might still be transferring.  Thus the only purpose of ->setup()
> is to do error checking on the provided parameters.
> Chip select, frequency etc. must be set in ->transfer().
> In the interest of portability/similarity barebox drivers should
> do the same as linux.
>
> That said, your proposed patch still looks OK.
> BTW, ->cleanup() is also never called, but so far no driver needs it...
>
>
> Johannes



-- 
Best regards,
  Antony Pavlov

_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox

  reply	other threads:[~2012-06-25 10:07 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-06-25  7:45 Antony Pavlov
2012-06-25  8:53 ` Johannes Stezenbach
2012-06-25 10:07   ` Antony Pavlov [this message]
2012-06-25 10:48     ` Johannes Stezenbach

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=CAA4bVAHqT37AuMbBUia4FGSdayQXvSYJ63hok_fYSaZpZHQK6A@mail.gmail.com \
    --to=antonynpavlov@gmail.com \
    --cc=barebox@lists.infradead.org \
    --cc=js@sig21.net \
    /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