Russell King - ARM Linux <[email protected]> writes:
> On Fri, May 15, 2009 at 05:58:19PM -0700, Kevin Hilman wrote:
>> The idea is that the code for each SoC fills out a structure
>> with the correct information. The board-specific code then
>> calls the SoC init routine which in turn will call a common
>> init routine that makes a copy of the structure, maps in I/O
>> regions, etc.
>
> I really don't like machines going off and doing their own special
> ordering of initialisation independently of the rest of the ARM
> kernel. It can cause problems as things evolve.
>
> Please stick to using the proper callbacks into the machine support
> code for doing what they request and as far as possible only what
> they request.
>
> IOW, please ensure that .map_io is used to map all the static IO
> mappings for the machine.
We're not changing any ordering of machine callbacks and the map_io
hook is doing all static IO mapping, just with a little indirection
into common code that can work across all SoCs in the davinci family.
This patch makes it look like this:
<board>->map_io()
<soc>_init()
davinci_common_init(<soc_info>)
iotable_init(<SoC specific IO table>)
We did this so we would't have to write a map_io function for every
SoC, instead we can just use common code.
> So, what I'd expect to see is something like:
>
> static void __init dm355_map_io(void)
> {
> iotable_init(&dm355_io_desc, ARRAY_SIZE(dm355_io_desc));
> }
>
> and then have DM355-based boards calling this function from their
> .map_io initializer or other .map_io supporting function. Ditto
> for other boards.
>
>> After initialization, code can get a pointer to the structure
>> by calling davinci_get_soc_info(). Eventually, the common
>> init routine will make a copy of all of the data pointed to
>> by the structure so the original data can be made __init_data.
>> That way the data for SoC's that aren't being used won't consume
>> memory for the entire life of the kernel.
>
> The problem with this approach is that you end up having a pointer
> to a large structure, some of which points at discarded data, some
> of which remains live. That makes it much more difficult to check
> that discarded data isn't accidentally referenced.
OK, I'll drop this "Eventually..." comment from the description since
we're not doing it that way now. Then we can address this later
if/when necessary.
Thanks for the review,
Kevin
_______________________________________________
Davinci-linux-open-source mailing list
[email protected]
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
