[U-Boot-Users] [PATCH] Move conditional compilation of MPC8XXX SPI driver to Makefile

[Haavard Skinnemoen]

Wolfgang Denk <wd at denx.de> wrote:
> In message <20080527100426.0f40544e at hskinnemo-gx745.norway.atmel.com> you wrote:
> >
> > > If we define CONFIG_HARD_SPI, then I don't see why CONFIG_MPC8XXX_SPI
> > > is needed at all if we're on a MPC8XXX system - that seems  redundant
> > > to  me.  On the other hand, if you want to use CONFIG_MPC8XXX_SPI and
> > > this implies that CONFIG_HARD_SPI must be set, too,  then  it  should
> > > automatically  set  this  variable  instead of causing the compile to
> > > fail.
> > 
> > Sounds to me like you're asking for Kconfig. I can't think of any way
> > to meet those requirements with the current infrastructure...
> 
> No? Uuups... what's wrong with
> 
> 	#ifdef CONFIG_MPC8XXX_SPI
> 	# ifndef CONFIG_HARD_SPI
> 	#  define CONFIG_HARD_SPI
> 	# endif
> 	#endif
> 
> Not exactly beautiful, but should work, shouldn't it?

Sure, but I was mostly wondering about _where_ one would put something
like that...which you answered below.

> > To be more specific:
> >   * Which part of the system is responsible for figuring out that when
> >     CONFIG_HARD_SPI is set _and_ we're on a MPC8XXX system, the
> >     mpx8xxx_spi driver should be compiled?
> 
> The Makefile?
> 
> Yes, you ill have to use a conditional in the Makefile as long as you
> ask for separate CONFIG_ options. That's one reason why I'm asking why
> we need several.

Ah...but I'm _also_ wondering why we need several :-)

> >   * Which part of the system is responsible for automatically selecting
> >     CONFIG_HARD_SPI when CONFIG_MPC8XXX_SPI is set?
> 
> include/spi.h ?

Makes sense.

> > On the other hand, it looks like everyone but powerpc is getting away
> > with not using CONFIG_HARD_SPI at all. Is it really necessary to have
> > two defines for essentially the same thing?
> 
> Bingo! That was exactly my question.

I guess I misunderstood then.

What I'm trying to say is that it makes sense to have one config symbol
per driver so that the board config header can specify exactly what it
wants instead of having something else try to figure it out
automatically.

So maybe we should try to get rid of the CONFIG_HARD_SPI define? I
don't think there's any fundamental difference between soft and hard
SPI anymore, at least not at the interface level.

> > > This assumes that we use only one SPI  controller  (built-in  on  the
> > > CPU/SOC).  We  should  also  keep  in  mind what happens when you use
> > > CONFIG_SOFT_SPI, eventually even simultaneously.
> > 
> > The current infrastructure doesn't allow multiple SPI controllers.
> 
> Yes, I know. But we should keep in mind that one day  such  a  system
> may  have  to be supported, and we should try not to make support for
> such systems more difficult than necessary.

Agree.

> > The new infrastructure that I posted yesterday supports multiple SPI
> > controllers of the same type, but not different ones. I asked whether
> > supporting multiple different SPI controllers would be necessary but
> > got no response, so I assumed no.
> 
> I think that's a valid assumption, at least for now. I cannot imagine
> why multiple different SPI controllers might be needed, but then  I'm
> surprised  again  and again what hardware designers can come up with.
> So we should try not to build barriers that can be avoided.

Sure, and I think my SPI patches brings us closer to the goal of
supporting multiple types of SPI hardware. But I don't want to take the
final step before we know for certain that we want it because it makes
the SPI layer more expensive in terms of code size and RAM usage.

I suspect that if we do want something like that, it will probably be
about combining hardware and software SPI (i.e. we want more SPI busses
than the chip can provide in hardware.)

Haavard