public inbox for linux-sh@vger.kernel.org
 help / color / mirror / Atom feed
* Discussion about register definition header
@ 2010-05-02  9:10 Fabio Giovagnini
  2010-05-06  5:17 ` Paul Mundt
  0 siblings, 1 reply; 2+ messages in thread
From: Fabio Giovagnini @ 2010-05-02  9:10 UTC (permalink / raw)
  To: linux-sh

Hi all,
I'm not what you can sey a guru of linux embedded, but I have more than 10 
years of experience on embedded application without general porpouse operating 
system expecially (but not only) in the automotive environment.
I think that into include/asm dir shoud be a file containing ALL the mpu 
registers address definitions, for avoiding to have same definitions across 
different files and an high probability to write something wrong each time.
I think this has not already done beacuse it is a long work for testing. Is it 
the main reason?

All discussion is veri appreciated.

Regards
-- 
Fabio Giovagnini

Aurion s.r.l.
P.I e C.F.
00885711200
Tel. +39.051.594.78.24
Cell. +39.335.83.50.919

^ permalink raw reply	[flat|nested] 2+ messages in thread

* Re: Discussion about register definition header
  2010-05-02  9:10 Discussion about register definition header Fabio Giovagnini
@ 2010-05-06  5:17 ` Paul Mundt
  0 siblings, 0 replies; 2+ messages in thread
From: Paul Mundt @ 2010-05-06  5:17 UTC (permalink / raw)
  To: linux-sh

On Sun, May 02, 2010 at 11:10:21AM +0200, Fabio Giovagnini wrote:
> I think that into include/asm dir shoud be a file containing ALL the mpu 
> registers address definitions, for avoiding to have same definitions across 
> different files and an high probability to write something wrong each time.
> I think this has not already done beacuse it is a long work for testing. Is it 
> the main reason?
> 
The main reason is that there's simply no need for it. Many of the CPUs
in question have similar register definitions but just position the
blocks at different locations. This is the sort of change that should be
managed between the driver and the CPU setup code in charge of
registering the SoC's platform devices.

For the most part we've evolved beyond simple hardcoded register
definitions, and the few cases where we still have to put up with them
now are mostly for blocks that aren't handled through the driver model.
Also note that these days almost everything needs to be remapped (either
via the TLB or via the PMB) so it's no longer possible to simply permit
drivers to do absurd P1/P2 abuses.

If you want to see what a total mess having these sorts of headers
quickly turns in to, you don't have to dig very far through the
architecture tree to find them. ARM used to do this via an
all-encompassing asm/hardware.h and has likewise moved on.

^ permalink raw reply	[flat|nested] 2+ messages in thread

end of thread, other threads:[~2010-05-06  5:17 UTC | newest]

Thread overview: 2+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2010-05-02  9:10 Discussion about register definition header Fabio Giovagnini
2010-05-06  5:17 ` Paul Mundt

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox