Re: [PATCH v3] powerpc/85xx: Add P2020DS board support

2009-04-22 Thread Scott Wood
On Tue, Apr 21, 2009 at 10:31:45PM -0500, Kumar Gala wrote:
 + local...@ffe05000 {
 + #address-cells = 2;
 + #size-cells = 1;
 + compatible = fsl,elbc, simple-bus;

If this has an elbc more recent than 1.0 (looks like it), we should
indicate that here.

 + reg = 0 0xffe0 0 0x1000;  // CCSRBAR  soc regs, remove 
 once parse code for immrbase fixed

The immrbase code was fixed a long time ago -- this can go away.

 +static int __init p2020_ds_probe(void)
 +{
 + unsigned long root = of_get_flat_dt_root();
 +
 + if (of_flat_dt_is_compatible(root, fsl,P2020DS)) {
 +#ifdef CONFIG_PCI
 + primary_phb_addr = 0x9000;
 +#endif
 + return 1;
 + } else {
 + return 0;
 + }
 +}

Unnecessary else.

-Scott
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev


Re: [PATCH v3] powerpc/85xx: Add P2020DS board support

2009-04-22 Thread Kumar Gala


On Apr 22, 2009, at 11:44 AM, Scott Wood wrote:


On Tue, Apr 21, 2009 at 10:31:45PM -0500, Kumar Gala wrote:

+   local...@ffe05000 {
+   #address-cells = 2;
+   #size-cells = 1;
+   compatible = fsl,elbc, simple-bus;


If this has an elbc more recent than 1.0 (looks like it), we should
indicate that here.


that might be the case, but I leave it to u-boot to do that.

+		reg = 0 0xffe0 0 0x1000;	// CCSRBAR  soc regs, remove  
once parse code for immrbase fixed


The immrbase code was fixed a long time ago -- this can go away.


will remove


+static int __init p2020_ds_probe(void)
+{
+   unsigned long root = of_get_flat_dt_root();
+
+   if (of_flat_dt_is_compatible(root, fsl,P2020DS)) {
+#ifdef CONFIG_PCI
+   primary_phb_addr = 0x9000;
+#endif
+   return 1;
+   } else {
+   return 0;
+   }
+}


Unnecessary else.


will fix this and the 2 other cases it shows up on.

- k
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev


Re: [PATCH v3] powerpc/85xx: Add P2020DS board support

2009-04-22 Thread Scott Wood

Kumar Gala wrote:

If this has an elbc more recent than 1.0 (looks like it), we should
indicate that here.


that might be the case, but I leave it to u-boot to do that.


Why?  There's no p2020 with an older eLBC, and there's no block version 
register.


-Scott
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev


Re: [PATCH v3] powerpc/85xx: Add P2020DS board support

2009-04-22 Thread Kumar Gala


On Apr 22, 2009, at 12:04 PM, Scott Wood wrote:


Kumar Gala wrote:

If this has an elbc more recent than 1.0 (looks like it), we should
indicate that here.

that might be the case, but I leave it to u-boot to do that.


Why?  There's no p2020 with an older eLBC, and there's no block  
version register.


But there might be a p2020 w/a newer eLBC version in the future.

- k
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev


Re: [PATCH v3] powerpc/85xx: Add P2020DS board support

2009-04-22 Thread Scott Wood

Kumar Gala wrote:


On Apr 22, 2009, at 12:04 PM, Scott Wood wrote:


Kumar Gala wrote:

If this has an elbc more recent than 1.0 (looks like it), we should
indicate that here.

that might be the case, but I leave it to u-boot to do that.


Why?  There's no p2020 with an older eLBC, and there's no block 
version register.


But there might be a p2020 w/a newer eLBC version in the future.


At which point we can add something to u-boot -- but magic SVR tables 
seem a step backward from the dts except where needed to avoid the 
creation of extra dts files.


-Scott
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev


Re: [PATCH v3] powerpc/85xx: Add P2020DS board support

2009-04-22 Thread Kumar Gala


On Apr 22, 2009, at 12:16 PM, Scott Wood wrote:


Kumar Gala wrote:

On Apr 22, 2009, at 12:04 PM, Scott Wood wrote:

Kumar Gala wrote:
If this has an elbc more recent than 1.0 (looks like it), we  
should

indicate that here.

that might be the case, but I leave it to u-boot to do that.


Why?  There's no p2020 with an older eLBC, and there's no block  
version register.

But there might be a p2020 w/a newer eLBC version in the future.


At which point we can add something to u-boot -- but magic SVR  
tables seem a step backward from the dts except where needed to  
avoid the creation of extra dts files.


I don't see the value of complicating u-boot to have to parse and  
fixup the compatible instead of just having to prepend to it.   
Especially since I don't believe there is anything specific we care  
about in the 1.2 version of elbc at this point.


- k
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev


Re: [PATCH v3] powerpc/85xx: Add P2020DS board support

2009-04-22 Thread Scott Wood

Kumar Gala wrote:


On Apr 22, 2009, at 12:16 PM, Scott Wood wrote:


Kumar Gala wrote:

On Apr 22, 2009, at 12:04 PM, Scott Wood wrote:

Kumar Gala wrote:

If this has an elbc more recent than 1.0 (looks like it), we should
indicate that here.

that might be the case, but I leave it to u-boot to do that.


Why?  There's no p2020 with an older eLBC, and there's no block 
version register.

But there might be a p2020 w/a newer eLBC version in the future.


At which point we can add something to u-boot -- but magic SVR tables 
seem a step backward from the dts except where needed to avoid the 
creation of extra dts files.


I don't see the value of complicating u-boot


But complicating u-boot is just what you're suggesting.  Put it in the 
dts, and u-boot has *zero* code to deal with this unless we find 
ourselves wanting to share the dts with another board rev with a newer 
chip with a newer elbc.


to have to parse and 
fixup the compatible instead of just having to prepend to it.  
Especially since I don't believe there is anything specific we care 
about in the 1.2 version of elbc at this point.


If the new elbc is compatible with the current one, then you will still 
just be prepending.  If it is not, then it very likely isn't compatible 
with 1.0 either, so you'll have to remove fsl,elbc anyway.


What we care about at this point is irrelevant, given the PITA it 
would be to change the device trees (or u-boot) that are already in use 
once we do begin to care.


-Scott
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev


Re: [PATCH v3] powerpc/85xx: Add P2020DS board support

2009-04-22 Thread Kumar Gala


On Apr 22, 2009, at 12:38 PM, Scott Wood wrote:


Kumar Gala wrote:

On Apr 22, 2009, at 12:16 PM, Scott Wood wrote:

Kumar Gala wrote:

On Apr 22, 2009, at 12:04 PM, Scott Wood wrote:

Kumar Gala wrote:
If this has an elbc more recent than 1.0 (looks like it), we  
should

indicate that here.

that might be the case, but I leave it to u-boot to do that.


Why?  There's no p2020 with an older eLBC, and there's no block  
version register.

But there might be a p2020 w/a newer eLBC version in the future.


At which point we can add something to u-boot -- but magic SVR  
tables seem a step backward from the dts except where needed to  
avoid the creation of extra dts files.

I don't see the value of complicating u-boot


But complicating u-boot is just what you're suggesting.  Put it in  
the dts, and u-boot has *zero* code to deal with this unless we find  
ourselves wanting to share the dts with another board rev with a  
newer chip with a newer elbc.


to have to parse and fixup the compatible instead of just having  
to prepend to it.  Especially since I don't believe there is  
anything specific we care about in the 1.2 version of elbc at this  
point.


If the new elbc is compatible with the current one, then you will  
still just be prepending.  If it is not, then it very likely isn't  
compatible with 1.0 either, so you'll have to remove fsl,elbc anyway.


What we care about at this point is irrelevant, given the PITA it  
would be to change the device trees (or u-boot) that are already in  
use once we do begin to care.


Which is exactly why I didn't put it in the .dts right now.  Today we  
know NO code exists that cares about fsl,elbc-1.2. Once someone adds  
such code they can also update the .dts to match it.


- k
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev


Re: [PATCH v3] powerpc/85xx: Add P2020DS board support

2009-04-22 Thread Kumar Gala


On Apr 22, 2009, at 1:16 PM, Scott Wood wrote:


Kumar Gala wrote:
What we care about at this point is irrelevant, given the PITA  
it would be to change the device trees (or u-boot) that are  
already in use once we do begin to care.

Which is exactly why I didn't put it in the .dts right now.


???

Today we know NO code exists that cares about fsl,elbc-1.2. Once  
someone adds such code they can also update the .dts to match it.


DTS files and firmware are *MUCH* harder to update once they're out  
there than the kernel.  Why such opposition to using an appropriate  
compatible?


Because I want to avoid make the decision right now.  We are on rev1.x  
silicon and I want to avoid greatly having to spawn a new .dts just  
for fsl,elbc-1.2.1 that has some errata fix in it.  If dtc was  
smarter and I had less duplication between the 40-50 .dts we have for  
our various parts I wouldn't care that match.


Is there anything in the p2020ds u-boot patches to set the elbc  
version, or was that just a brush-off?


I was hoping that Poonam would look at doing that, but there isn't  
anything right now.


I can put out some code for u-boot to address the specific elbc issue  
if that will resolve this.


- k
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev


RE: [PATCH v3] powerpc/85xx: Add P2020DS board support

2009-04-21 Thread Liu Dave-R63238
 + L2: l2-cache-control...@2 {
 + compatible = fsl,p2020-l2-cache-controller;
 + reg = 0x2 0x1000;
 + cache-line-size = 32; // 32 bytes
 + cache-size = 0x10; // L2, 1M
 + interrupt-parent = mpic;
 + interrupts = 16 2;
 + };

One nit --here should be 512KB L2 cache

 + u...@22000 {
 + #address-cells = 1;
 + #size-cells = 0;
 + compatible = fsl-usb2-mph;
 + reg = 0x22000 0x1000;
 + interrupt-parent = mpic;
 + interrupts = 28 0x2;
 + phy_type = ulpi;
 + };

It should be fsl-usb2-dr
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev