public inbox for ecos-patches@sourceware.org
 help / color / mirror / Atom feed
From: Bart Veer <bartv@ecoscentric.com>
To: ecos-patches@sourceware.org
Subject: tidy STM32 SPI driver
Date: Tue, 10 Feb 2009 22:31:00 -0000	[thread overview]
Message-ID: <pneiy5exfx.fsf@delenn.bartv.net> (raw)

This SPI driver did not use linker garbage collection the way I
intended for SPI drivers. It created a C++ object in
src/spi_stm32_init.cxx which was places in libextras.a. Hence the C++
object was always part of any application link, and because of the
KEEP(*.ctors) in the linker script its constructor would never get
garbage-collected. Net result: all applications would end up with the
C++ object, the constructor, and the cyg_spi_cortexm_stm32_init()
function, even if SPI was never used.

This patch should fix this. src/spi_stm32_init.cxx is eliminated
completely. cyg_spi_cortexm_stm32_init() is declared as a prioritized
constructor, and made static because it is no longer accessed from the
outside the module.

  If the application does not make use of any SPI functions then there
  will be no references to any of the SPI bus objects and the linker
  will not pull in spi_stm32.o from libtarget.a. So the linker never
  sees any of the driver code, including the constructor, and there
  are no overheads.

  If the application does make use of SPI then it will reference one
  of the SPI bus objects and the linker will pull in spi_stm32.o from
  the library. The module is still subject to linker garbage
  collection, although that won't have much effect because of the
  table of function pointers. The init function is a constructor so
  the linker will keep it because of the KEEP(*.ctors). And everything
  should work as intended.

I also looked at moving the three SPI buses into separate modules,
built unconditionally. Again linker magic would ensure that only buses
actually used by the application would end up in the application, with
no need for developers to enable the relevant CDL components. This
does not look entirely feasible right now, there are too many per-bus
configuration options.

Bart

2009-02-10  Bart Veer  <bartv@ecoscentric.com>

	* src/spi_stm32.c (cyg_spi_cortexm_stm32_init): mark as
	prioritized constructor and rename.

	* cdl/spi_stm32.cdl: stop building spi_stm32_init.cxx

	* src/spi_stm32_init.cxx: removed, no longer needed.

Index: cdl/spi_stm32.cdl
===================================================================
RCS file: /cvs/ecos/ecos/packages/devs/spi/cortexm/stm32/current/cdl/spi_stm32.cdl,v
retrieving revision 1.2
diff -u -p -r1.2 spi_stm32.cdl
--- cdl/spi_stm32.cdl	10 Feb 2009 16:12:53 -0000	1.2
+++ cdl/spi_stm32.cdl	10 Feb 2009 22:29:42 -0000
@@ -59,7 +59,6 @@ cdl_package CYGPKG_DEVS_SPI_CORTEXM_STM3
     hardware
     include_dir   cyg/io
     compile       spi_stm32.c
-    compile       -library=libextras.a spi_stm32_init.cxx
 
 cdl_option CYGNUM_DEVS_SPI_CORTEXM_STM32_PIN_TOGGLE_RATE {
     display       "Pin toggle rate"
Index: src/spi_stm32.c
===================================================================
RCS file: /cvs/ecos/ecos/packages/devs/spi/cortexm/stm32/current/src/spi_stm32.c,v
retrieving revision 1.4
diff -u -p -r1.4 spi_stm32.c
--- src/spi_stm32.c	10 Feb 2009 16:12:54 -0000	1.4
+++ src/spi_stm32.c	10 Feb 2009 22:29:56 -0000
@@ -611,8 +611,8 @@ static void spi_transaction_dma 
 //-----------------------------------------------------------------------------
 // Initialise SPI interfaces on startup.
 
-void cyg_spi_cortexm_stm32_init 
-  (void)
+static void CYGBLD_ATTRIB_C_INIT_PRI(CYG_INIT_BUS_SPI)
+stm32_spi_init(void)
 {
 #if defined(CYGHWR_DEVS_SPI_CORTEXM_STM32_BUS3) && \
     defined(CYGHWR_DEVS_SPI_CORTEXM_STM32_BUS3_DISABLE_DEBUG_PORT)



             reply	other threads:[~2009-02-10 22:31 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-02-10 22:31 Bart Veer [this message]
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

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=pneiy5exfx.fsf@delenn.bartv.net \
    --to=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).