Hi Rob,

On 5/22/2020 10:15 PM, Rob Herring wrote:

On Thu, May 21, 2020 at 5:35 AM Kishon Vijay Abraham I [off-list ref] wrote:

quoted

Hi Rob,

On 5/21/2020 3:04 AM, Rob Herring wrote:

quoted

On Wed, May 06, 2020 at 08:44:22PM +0530, Kishon Vijay Abraham I wrote:

quoted

Cadence driver uses "mem" memory resource to obtain the offset of
configuration space address region, memory space address region and
message space address region. The obtained offset is used to program
the Address Translation Unit (ATU). However certain platforms like TI's
J721E SoC require the absolute address to be programmed in the ATU and not
just the offset.

Once again, Cadence host binding is broken (or at least the example is).
The 'mem' region shouldn't even exist. It is overlapping the config
space and 'ranges':

            reg = <0x0 0xfb000000  0x0 0x01000000>,
                  <0x0 0x41000000  0x0 0x00001000>,
                  <0x0 0x40000000  0x0 0x04000000>;
            reg-names = "reg", "cfg", "mem";

            ranges = <0x02000000 0x0 0x42000000  0x0 0x42000000  0x0 0x1000000>,
                     <0x01000000 0x0 0x43000000  0x0 0x43000000  0x0 0x0010000>;


16M of registers looks a bit odd. I guess it doesn't matter
unless you have a 32-bit platform and care about your virtual
space. Probably should have been 3 regions for LM, RP, and AT looking
at the driver.

The "mem" region in never ioremapped. However $patch removes requiring to add
"mem" memory resource.

I was referring to ioremapping 'reg' region.

quoted

quoted

Whatever outbound address translation you need should be based on
'ranges'.

You mean we don't need to add "new *ops* for CPU addr fixup"?. The issue is
ranges provides CPU address and PCI address. The CPU will access whatever is
populated in ranges to access the PCI bus. However while programming the ATU,
we cannot use the CPU address provided in ranges directly (in some platforms)
because the controller does not see the full address and only the lower 28bits.

Okay, that is clearer as to what the difference is. I think this
should be 2 patches. One dropping 'mem' usage and using a mask and the
2nd making the mask per platform.

hmm okay.

Really, the parent node of the PCI controller should probably have
'ranges' and you could extract a mask from that. Looks like that is
what you had for DRA7... I'm not sure if ABI stability is important
for the Cadence platform. I'd assume that's just some IP eval system
and probably not?

Right TI's J721E should be the first HW platform to use Cadence in mainline.

Why do you need an ops here? All you need is a mask value.

So how do we get platform specific mask? Use a different binding to specify the
mask value?

quoted

This similar restriction was there with Designware (mostly an integration
issue) and we used *ops* to fixup the address that has to be programmed in ATU.
The Designware initially used a wrapper so that ranges property can be directly
used [1]. However this approach was later removed in [2]

[1] -> https://lore.kernel.org/patchwork/patch/468523/
[2] -> https://lkml.org/lkml/2015/10/16/232

So while you had the data for a mask in DT, the driver now hardcodes it?

Yes, that's correct. Which approach should we use for Cadence?

Thanks
Kishon

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel