[RFC PATCH v1 1/1] powerpc/85xx: Add support for Emerson/Artesyn MVME2500.

[Alessio Igor Bogani]

Hi Scott,

On 2 December 2014 at 06:03, Scott Wood <scottwood at freescale.com> wrote:
[...]
> I was referring to the final ranges entry:
>
>> +                         0x5 0x0 0x0 0xffdf0000 0x00001000>;
>
> The localbus ranges should reflect what was programmed into BRn/ORn.
> The smallest size that can be programmed into ORn is 32 KiB.

Sorry I'll use 0x8000 instead of 0x1000.

>> The pq3-gpio-0.dtsi defines an gpio controller in this way:
>>
>> gpio-controller at f000 {
>>      reg = <0xf000 0x100>;
>>      [...]
>>
>> But MVME2500 board requires a slightly different definition:
>>
>>      reg = <0xfc00 0x100>;
>
> The GPIO CCSR registers on a P2010 don't change based on what board you
> put it on.  It looks like pq3-gpio-0.dtsi is just wrong, for all chips
> that use it.  It should be fixed there.

I have to admit that I'm not using GPIO at the moment so a typo into
board's manufacturer manual is more probable.

>> > Better still would be if we could have address map tweaks be kconfig
>> > fragments that get mixed in by the user, with merge_config.sh.
>>
>> Personally I would prefer see something more simple like this:
>>
>> %_defconfig: scripts/kconfig/conf
>>    # Grab the platform generic config file (for a SoC family)
>>    $(Q)$< --defconfig=arch/$(SRCARCH)/configs/mpc$(shell dirname
>> $@)_defconfig Kconfig
>
> What is the dirname here trying to do?

Extract string "85xx" from "make 85xx/mvme2500_defconfig" command.

So the above mentioned Makefile snip grabs
arch/powerpc/configs/mpc85xx_defconfig and applies (using
merge_config.sh) options present in
arch/powerpc/configs/85xx/mvme2500_defconfig.

It should reduces the size of the board specific defconfig without
using any other fragments and without change anything in user habits.

In my humble opinion that hardware is so rigid that flexibility given
by config fragments don't seem very useful.

Using this approach the mvme2500_defconfig file could looks like this:

CONFIG_MVME2500=y
CONFIG_PCIEPORTBUS=y
CONFIG_PCIEAER=y
# CONFIG_PCIEASPM is not set
CONFIG_SERIAL_8250_NR_UARTS=6
CONFIG_SERIAL_8250_RUNTIME_UARTS=6
CONFIG_BROADCOM_PHY=y
CONFIG_MTD_SPI_NOR=y
CONFIG_MTD_M25P80=y
CONFIG_HWMON=m
CONFIG_SENSORS_LM90=m
CONFIG_EDAC_MPC85XX=y
CONFIG_ADVANCED_OPTIONS=y
CONFIG_LOWMEM_SIZE_BOOL=y
CONFIG_LOWMEM_SIZE=0x40000000
CONFIG_PAGE_OFFSET_BOOL=y
CONFIG_PAGE_OFFSET=0x80000000
CONFIG_KERNEL_START_BOOL=y
CONFIG_TASK_SIZE_BOOL=y
CONFIG_TASK_SIZE=0x80000000
CONFIG_STAGING=y
CONFIG_VME_BUS=y
CONFIG_VME_TSI148=y
CONFIG_VME_USER=y

I know it is a very stupid idea so feel free to ignore me on this point :)

>> > I gues the point here is to avoid using highmem just for the last 256
>> > MiB?
>>
>> Yes. Can you suggest me a better solution, please?
>
> Not if the performance benefit from getting rid of highmem is worth
> carrying this around...  But it would still be good if the board support
> were build in the standard defconfig as well.  It's unlikely to get much
> build coverage (by people who don't use this board) in a board-specific
> defconfig.

Ok I changed mpc85xx_defconfig and it works with few addiction. So we
have two possibilities: use mpc85xx_defconfig (but without VME_USER
and Highmem tweak) or add mvme2500_defconfig: Which do you prefer? I
would prefer the mvme2500_defconfig but I think that my vote doesn't
count (rightly).

What do you think about move board setup code from
platform/85xx/mvme2500.c to platform/platforms/85xx/mpc85xx_ds.c?

Thank you very much.

Ciao,
Alessio