Re: [PATCH v2 2/2] ARM: dts: am33xx: Move wkup_m3 node to soc node and add ranges

[Tony Lindgren]

* Suman Anna <s-anna@xxxxxx> [150311 10:18]:
> On 03/11/2015 11:26 AM, Tony Lindgren wrote:
> > * Dave Gerlach <d-gerlach@xxxxxx> [150310 12:55]:
> >> Suman and I have been looking at this together, so I can comment here. An
> >> implementation like this is what Suman is referring to:
> >>
> >> +               l4_wkup: l4_wkup@44c00000 {
> >> +                       compatible = "am335-l4-wkup", "simple-bus";
> >> +                       #address-cells = <2>;
> >> +                       #size-cells = <1>;
> >> +                       ranges = <0 0           0x44c00000 0x100000>,
> >> +                                <1 0x0         0x44d00000 0x4000>,
> >> +                                <2 0x80000     0x44d80000 0x2000>;
> 
> Actually, this would be slightly different, something like
>  +                       ranges = <0 0    0x44c00000 0x100000>,
>  +                                <1 0    0x44d00000 0x100000>,
>  +                                <2 0    0x44e00000 0x4000>,
>  +				  <3 0    0x44e10000 0x2000>;
> 
> and the M3 DMEM entry below will be adjusted as <1 0x80000 0x2000>.
> 
> >> +
> >> +                       wkup_m3: wkup_m3@1,0 {
> >> +                               compatible = "ti,am3353-wkup-m3";
> >> +                               reg = <1 0x0     0x4000>,       /* M3 UMEM */
> >> +                                     <2 0x80000 0x2000>;       /* M3 DMEM */
> >> +
> >> +                               ti,hwmods = "wkup_m3";
> >> +                               ti,pm-firmware = "am335x-pm-firmware.elf";
> >> +                       };
> >> +               };
> >> +
> >>
> >> The of_* layer automatically translates everything so the pdata-quirks can still
> >> match based on wkup_m3@44d00000. The existing wkup_m3_rproc driver works almost
> >> entirely as is with this, all cpu addresses are read and mapped correctly but
> >> the driver no longer will read the actual device addresses correctly which we
> >> need for understanding where to load the firmware sections.
> > 
> > OK. I still don't quite understand how these additional ranges make sense
> > for other drivers connected to the l4_wkup. For wkup_m3, it makes sense if
> > it allows you to translate directly to the m3 address space, but is that
> > really the case here? Maybe you should have the ranges in wkup_m3 instead
> > if you want addresses for the m3?
> 
> The idea is to introduce an additional address element (first cell in
> ranges) so that the immediate child nodes bus address is referenced as 0
> (second cell) for translation for their child nodes. This is the
> approach used by the current scm node in Tero's series for OMAP4+. This
> will work tomorrow if we move the prcm, scrm node under l4_wkup with
> changes only in those nodes, and have their child nodes reg properties
> unchanged. I guess you can see the difference between the following two
> patches from Tero's PRCM series,
> https://patchwork.kernel.org/patch/5882831/ &
> https://patchwork.kernel.org/patch/5882841/

Well I just commented on Tero on that regarding the dra7 patch. I think
we need to have separate scm instances for scm_device, scm_core and
scm_wkup instead of doing multiple ranges. This based on looking at for
example 5432 TRM "Figure 18-1. Control Module Overview".

But here I think it's a different issue. You want to use ranges for getting
the m3 address space for the firmware? I'm not convinced we should
complicate the ranges for all l4_wkup drivers because of that.

Regards,

Tony
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/