public inbox for ecos-patches@sourceware.org
 help / color / mirror / Atom feed
From: Chris Holgate <chris@zynaptic.com>
To: Bart Veer <bartv@ecoscentric.com>
Cc: ecos-patches@sourceware.org
Subject: Re: tidy STM32 SPI driver
Date: Wed, 11 Feb 2009 15:37:00 -0000	[thread overview]
Message-ID: <4992F0C5.7010905@zynaptic.com> (raw)
In-Reply-To: <pnbpt9dovy.fsf@delenn.bartv.net>

Bart Veer wrote:
> 
> For the chip select handling, if I understand the code correctly then
> currently the SPI driver is responsible for both setting up the GPIO
> pins and for driving them. There are other ways of handling this. One
> approach is for the platform HAL to set up all the pins early on
> during initialization, before the static constructors, on the theory
> that the platform HAL author knows what devices are attached to which
> pins. That saves having to do pin setup in each driver, so saves a bit
> more code.

Possibly, although the STM32E-EVAL board has a lot of flexibility in
terms of how it can be configured.  It would be quite difficult to
second-guess how a 'typical' developer would want to set it up.

> A more flexible approach is used in the coldfire HALs, see the mcf5272
> processor HAL's gpio.cdl and CYGHWR_HAL_M68K_MCF5272_BOARD_PINS in the
> m5272c3 platform HAL. That exposes all the pin settings to the
> configuration system, with the platform HAL providing default
> settings. The approach makes it possible to support boards with
> expansion connectors etc., where the platform HAL author does not
> necessarily know exactly what hardware will be used. It offers a lot
> of flexibility, and involves very little target-side code or data, but
> at the cost of significant programming effort.

If chip select setup is to be done in the HAL I suspect that something
like this would probably be required.  I'm not volunteering - I really
need to get cracking with my application!

> If pin setup can be left to the platform HAL then the SPI driver only
> needs to worry about driving the chip select pins. That can be
> handled by putting the pin id into the SPI device structure instead of
> the bus structure. That should save more code and data.

Now you come to mention it, the device structure is the most logical
place to put the chip select pin ID.  The only reason it's not there is
because of the requirement to set up the pin during initialisation.

Given that the CYG_DEVS_SPI_CORTEXM_STM32_DEVICE macro is already used
to hide all the bus attachment and type aliasing, it would also be
possible for that macro to automatically generate a static
initialisation function to set up the chip select pin.  That way there
is no need for the SPI bus data structure to hold any information about
chip selects and that configuration option can be discarded.

Chris.

  parent reply	other threads:[~2009-02-11 15:37 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-02-11 11:29 Chris Holgate
2009-02-11 14:33 ` Bart Veer
2009-02-11 15:23   ` Nick Garnett
2009-02-11 15:37   ` Chris Holgate [this message]
  -- strict thread matches above, loose matches on Subject: below --
2009-02-10 22:31 Bart Veer

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=4992F0C5.7010905@zynaptic.com \
    --to=chris@zynaptic.com \
    --cc=bartv@ecoscentric.com \
    --cc=ecos-patches@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).