> -----Original Message-----
> From: Grant Likely [mailto:[email protected]]
> Sent: Wednesday, April 15, 2009 9:03 AM
> To: Stephen Neuendorffer
> Cc: John Linn; [email protected];
> [email protected]; linuxppc-
> [email protected]; [email protected]; [email protected]; 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
> <[email protected]> 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.
_______________________________________________
Linuxppc-dev mailing list
[email protected]
https://ozlabs.org/mailman/listinfo/linuxppc-dev
