[PATCH 1/7] powerpc: Add mpc8360epb platform support
Andy Fleming
afleming at freescale.com
Fri Jun 30 04:03:23 EST 2006
On Jun 29, 2006, at 04:28, Li Yang-r58472 wrote:
>>> +config MPC8360E_PB
>>> + bool "Freescale MPC8360E PB"
>>> + select DEFAULT_UIMAGE
>>> + select QUICC_ENGINE
>>> + help
>>> + This option enables support for the MPC836x EMDS Processor
>>> Board.
>>> +
>>> endchoice
>>
>> I don't think this is really required option. I guess 836x +
>> QUICC_ENGINE should
>> be enough (with a proviso that 8360 won't boot without qe.
>
> We select a board and the board implies cpu family and soc
> feature. That will be better for users rather than expecting them
> to know the very detail.
Yeah, this seems fine to me. In order to eliminate this option, we'd
need to merge 8360 PB support with the existing board support for
83xx. A laudable goal, but not what the 83xx maintainer has
currently requested.
>>> diff --git a/arch/powerpc/platforms/83xx/mpc8360e_pb.c
>> b/arch/powerpc/platforms/83xx/mpc8360e_pb.c
>>> new file mode 100644
>>> index 0000000..b4ddb0a
>>> --- /dev/null
>>> +++ b/arch/powerpc/platforms/83xx/mpc8360e_pb.c
>>> @@ -0,0 +1,213 @@
>>> +/*
>>> + * Copyright (C) Freescale Semicondutor, Inc. 2006. All rights
>>> reserved.
>>> + *
>>> + * Author: Li Yang <LeoLi at freescale.com>
>>> + * Yin Olivia <Hong-hua.Yin at freescale.com>
>>> + *
>>> + * Description:
>>> + * MPC8360E MDS PB board specific routines.
>>> + *
>>> + * Changelog:
>>> + * Jun 21, 2006 Initial version
>>> + *
>> No changelog entries for new files please... git tracks it good
>> enough.
>
> This is Freescale protocol. If it is not welcomed, we will change it.
Yeah, this is one of the problems with the protocol.
>>> +#ifdef CONFIG_QUICC_ENGINE
>>> + qe_reset();
>>> +
>>> + for (np = NULL; (np = of_find_node_by_name(np, "ucc")) != NULL;)
>>> + par_io_of_config(np);
>>> +
>>> + /* Reset the Ethernet PHY */
>>> + bcsr_regs = (u8 *) ioremap(BCSR_PHYS_ADDR, BCSR_SIZE);
>>> + bcsr_regs[9] &= ~0x20;
>>> + udelay(1000);
>>> + bcsr_regs[9] |= 0x20;
>>> + iounmap(bcsr_regs);
>>> +
>> And if we have a design, which do not contain real ethernet UCC
>> usage? Or UCC
>> geth is disabled somehow explicitly? Stuff like that normally goes
>> to the
>> callback that is going to be triggered upon Etherbet init.
> I will move it.
Wait...no. I don't understand Vitaly's objection. If someone
creates a board with an 8360 that doesn't use the UCC ethernet, they
can create a separate board file. This is the board-specific code,
and it is perfectly acceptable for it to reset the PHY like this.
What ethernet callback could be used?
Andy
More information about the Linuxppc-dev
mailing list