linux-mips
[Top] [All Lists]

Re: [PATCH 0/3] Alchemy: platform updates

To: Manuel Lauss <mano@roarinelk.homelinux.net>
Subject: Re: [PATCH 0/3] Alchemy: platform updates
From: Sergei Shtylyov <sshtylyov@ru.mvista.com>
Date: Mon, 30 Mar 2009 00:48:02 +0400
Cc: Linux-MIPS <linux-mips@linux-mips.org>
In-reply-to: <49CF71BE.2070109@ru.mvista.com>
Original-recipient: rfc822;linux-mips@linux-mips.org
References: <1238318822-4772-1-git-send-email-mano@roarinelk.homelinux.net> <49CF5CE6.1070003@ru.mvista.com> <20090329143802.0a09baca@scarran.roarinelk.net> <49CF71BE.2070109@ru.mvista.com>
Sender: linux-mips-bounce@linux-mips.org
User-agent: Thunderbird 2.0.0.21 (Windows/20090302)
Hello, I wrote:

Patch overview:

#1: eliminate alchemy/common/platform.c.  Add platform device
    registration to all boards instead.
I'm strongly voting against this, as it causes totally unneeded code duplication. Please don't apply.

I know it seems like a lot of unecessary duplication.  My reasons for
doing this are

a) I want to get rid of the various cpu-type specific config symbols,
   (i.e. I want one kernel binary to run on 2 or more Alchemy boards
   with different cpu models.  There's no technical reason this
   shouldn't work.  The OHCI block for instance has different addresses
   on pre-Au1200 silicon; the easiest solution to that (for me) is
to simply move device registration to the boards that need/want it.)

Well, then create several files (like arch/mips/alchemy/common/au1200.c) for SoC specific platfrom device sets variations but don't move all platform devices into the board files. This will be a cleaner solution.

Another solution would be "tuning up" the platform device resources depending on the detected SoC type.

    have a chance to get your approval on this, so I can stop wasting
    my and everybody else's time as soon as possible).
   (BTW, what do you think about this?  Please tell me now if I ever

 Single kernel binary? If it's at all possible, I am all for it.

That doesn't mean however that SoC type options need to go -- we could allow the user a flexibility (like is curretnly done on ARM DaVinci) of choosing an arbotrary set of supported SoCs, so that he could have the choice to exclude the code for the ones he doesn't need.

WBR, Sergei



<Prev in Thread] Current Thread [Next in Thread>