Gilles Chanteperdrix wrote:
 > Gregory CLEMENT wrote:
 >  > > >  #ifdef CONFIG_IPIPE
 >  > > > -#define AT91_VA_BASE_TCB0       AT91_IO_P2V(AT91RM9200_BASE_TCB0)
 >  > > > +#if defined(CONFIG_ARCH_AT91RM9200)
 >  > > > +     #define AT91_VA_BASE_TCB0       
 > AT91_IO_P2V(AT91RM9200_BASE_TCB0)
 >  > > > +#elif defined(CONFIG_ARCH_AT91SAM9260)
 >  > > > +     #define AT91_VA_BASE_TCB0       
 > AT91_IO_P2V(AT91SAM9260_BASE_TCB0)
 >  > > > +#elif defined(CONFIG_ARCH_AT91SAM9261)
 >  > > > +     #define AT91_VA_BASE_TCB0       
 > AT91_IO_P2V(AT91SAM9261_BASE_TCB0)
 >  > > > +#else
 >  > > > +#error "Unsupported AT91 processor"
 >  > > > +#endif
 >  > > >  #endif /* CONFIG_IPIPE */
 >  > >
 >  > > To reduce the ifdef hell, can not we define a unique AT91_BASE_TCB0 ?
 >  > 
 >  > Sure it would be better, but unfortunately the mainteners of AT91
 >  > choose to produce a define per architecture even if the register are
 >  > the same.
 > 
 > As far as I know, the AT91RM9200_BASE_TCB0 define is provided by the
 > I-pipe patch, so we may name it how we want.

No, it is not provided by the I-pipe patch.

 > 
 > 
 >  > We keep this line :
 >  > #define AT91_VA_BASE_TCB0       AT91_IO_P2V(AT91RM9200_BASE_TCB0)
 >  > and it will work I don't like having an AT91RM9200 define for chip
 >  > which are not AT91RM9200. It adds confusion.
 >  > 
 >  > We also could define AT91_BASE_TCB0 as you suggest, but it mean we add
 >  > a new register definition just for ipipe and it adds a little
 >  > confusion also.
 >  > 
 >  > Choose the solution you prefer, or an other if you have a better idea.
 > 
 > I do not have a better idea, but I understood why the defines are
 > different: the CONFIG_ARCH_AT91RM9200, CONFIG_ARCH_AT91SAM9260 and
 > CONFIG_ARCH_AT91SAM9261 are not mutually exclusive, it is possible to
 > build a kernel that works for the three machines. So, this code can not
 > remain as is. Please, at least, forbid in Kconfig selecting several
 > machines when IPIPE is enabled.

On 2.6.20, the options ARE mutually exclusive.

-- 


                                            Gilles Chanteperdrix.

_______________________________________________
Adeos-main mailing list
[email protected]
https://mail.gna.org/listinfo/adeos-main

Reply via email to