[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