[PATCH] [V3] Xilinx : Framebuffer Driver: Add PLB support and cleanup DCR

[Stephen Neuendorffer]

> -----Original Message-----
> From: Grant Likely [mailto:grant.likely at secretlab.ca]
> Sent: Wednesday, April 15, 2009 9:03 AM
> To: Stephen Neuendorffer
> Cc: John Linn; jwboyer at linux.vnet.ibm.com; linux-fbdev-devel at lists.sourceforge.net; linuxppc-
> dev at ozlabs.org; akonovalov at ru.mvista.com; adaplas at gmail.com; Suneel Garapati
> Subject: Re: [PATCH] [V3] Xilinx : Framebuffer Driver: Add PLB support and cleanup DCR
> 
> On Wed, Apr 15, 2009 at 9:58 AM, Stephen Neuendorffer
> <stephen.neuendorffer at xilinx.com> wrote:
> >> > -       rc = of_address_to_resource(op->node, 0, &res);
> >> > -       if (rc) {
> >> > -               dev_err(&op->dev, "invalid address\n");
> >> > -               return rc;
> >> > +       /*
> >> > +        * To check whether the core is connected directly to DCR or PLB
> >> > +        * interface and initialize the tft_access accordingly.
> >> > +        */
> >> > +       p = (u32 *)of_get_property(op->node, "xlnx,dcr-splb-slave-if", NULL);
> >>
> >> Hmmm.  This binding is undocumented.  It would be better to make the
> >> decision on the presence/absence of the dcr-reg and/or reg properties.
> >
> > For backward compatibility with the 'old' way, the device tree generator for this core has both
> dcr-reg and reg properties (where the reg has been translated back through the bridge).
> 
> So, what is in the regs and dcr-regs properties when DCR is used?
> 
> How about when MMIO is used?
> 

Currently:
Core has DCR access, connected DCR bus:
	device tree contains dcr-reg property.
Core has DCR access, accessed through plb->dcr bridge:
	device tree contains dcr-reg property, AND for backward compatibility with the 
	old driver, a reg property which contains the apparent registers on the bus.
Core has PLB access: 
	device tree contains reg property only.

So, I guess it really doesn't matter... The only interesting case is the second one where (because the way the reg property is published), either method will work...  So, nevermind, the device tree question is completely independent and I agree with your comment that there's probably not a need for a separate binding.

What I do think would be nice (at some point in the future maybe) is perhaps a bit of DCR_or_PLB abstraction for this core and the ll_temac driver to share which would avoid duplicating the code in each driver as to whether it uses DCR or PLB access...

Steve


This email and any attachments are intended for the sole use of the named recipient(s) and contain(s) confidential information that may be proprietary, privileged or copyrighted under applicable law. If you are not the intended recipient, do not read, copy, or forward this email message or any attachments. Delete this email message and any attachments immediately.