linux-kernel - Re: [PATCH 2/3] PCI: designware: use untranslated address while programming ATU

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <53ABD8B8.5030200@ti.com>
Date:	Thu, 26 Jun 2014 13:54:24 +0530
From:	Kishon Vijay Abraham I <kishon@...com>
To:	Pratyush Anand <pratyush.anand@...com>
CC:	Pratyush Anand <pratyush.anand@...il.com>,
	"devicetree@...r.kernel.org" <devicetree@...r.kernel.org>,
	"linux-doc@...r.kernel.org" <linux-doc@...r.kernel.org>,
	"linux-pci@...r.kernel.org" <linux-pci@...r.kernel.org>,
	Jingoo Han <jg1.han@...sung.com>,
	Bjorn Helgaas <bhelgaas@...gle.com>,
	Mohit KUMAR DCG <Mohit.KUMAR@...com>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"grant.likely@...aro.org" <grant.likely@...aro.org>,
	Jason Gunthorpe <jgunthorpe@...idianresearch.com>,
	Marek Vasut <marex@...x.de>, Arnd Bergmann <arnd@...db.de>
Subject: Re: [PATCH 2/3] PCI: designware: use untranslated address while programming
 ATU

Hi Pratyush,

On Thursday 26 June 2014 12:03 PM, Pratyush Anand wrote:
> Hi Kishon,
> 
> On Thu, Jun 26, 2014 at 02:10:02PM +0800, Kishon Vijay Abraham I wrote:
>> Hi Pratyush,
>>
>> On Thursday 26 June 2014 11:07 AM, Pratyush Anand wrote:
>>> Hi Kishon,
>>>
>>>  Few things, if you can help me to understand:
>>>
>>> On Wed, Jun 25, 2014 at 11:26 PM, Kishon Vijay Abraham I <kishon@...com> wrote:
>>>> In DRA7, the cpu sees 32bit address, but the pcie controller can see only 28bit
>>>> address. So whenever the cpu issues a read/write request, the 4 most
>>>> significant bits are used by L3 to determine the target controller.
>>>> For example, the cpu reserves 0x2000_0000 - 0x2FFF_FFFF for PCIe controller but
>>>> the PCIe controller will see only (0x000_0000 - 0xFFF_FFF). So for programming
>>>> the outbound translation window the *base* should be programmed as 0x000_0000.
>>>> Whenever we try to write to say 0x2000_0000, it will be translated to whatever
>>>> we have programmed in the translation window with base as 0x000_0000.
>>>>
>>>> This is needed when the dt node is modelled something like below
>>>> axi {
>>>>         compatible = "simple-bus";
>>>>         #size-cells = <1>;
>>>>         #address-cells = <1>;
>>>>         ranges = <0x0        0x20000000 0x10000000 // 28-bit bus
>>>>                   0x51000000 0x51000000 0x3000>;
>>>>         pcie@...00000 {
>>>>                 reg = <0x1000 0x2000>, <0x51002000 0x14c>, <0x51000000 0x2000>;
>>>>                 reg-names = "config", "ti_conf", "rc_dbics";
>>>
>>> So for DRA7, config base which will be coming from reg property should
>>> be 0x1000 and size 0x2000, no?
>>
>> right. The first element in 'reg' and 'reg-names' specify exactly that.
>>>
>>>>                 #address-cells = <3>;
>>>>                 #size-cells = <2>;
>>>>                 ranges = <0x81000000 0 0          0x03000 0 0x00010000
>>>
>>> range type 0x81000000 tells that it is IO
>>>
>>>>                           0x82000000 0 0x20013000 0x13000 0 0xffed000>;
>>>
>>> range type 0x81000000 tells that it is mem
>>>
>>>
>>>>         };
>>>> };
>>>>
>>>> Here the CPU address for configuration space is 0x20013000 and the controller
>>>> address for configuration space is 0x13000. The controller address should
>>> be
>>>
>>> If above understanding is correct then:
>>>
>>> Aren't these addresses(0x20013000  and 0x13000) from mem space
>>> instead of configuration space.
>>
>> Sorry. I didn't get you. Configuration space is different from mem space and IO
>> space. We specify only the configuration space in "reg", the IO space and
>> memory space should be specified in ranges.
>>
>> In my case
>> configuration space range: 0x20001000 - 0x20002fff
>> IO space range:            0x20003000 - 0x20012fff
>> Mem space range:           0x20013000 - 0x2fffffff
>>
>> Here only the configuration space is obtained from 'reg' and 'IO' and 'MEM'
>> space is obtained from ranges.
>>>
>>> If yes, then how can you get two addresses (CPU and Controller address)
>>> from reg property for configuration space?
>>
>> I used platform_get_resource_byname() to get CPU address and of_get_address()
>> to get the untranslated controller address.
> 
> This is what I am not able to understand that how does
> platform_get_resource_byname gives correct CPU address from reg =
> <0x1000 0x2000>?
> 
> cfg_res = platform_get_resource_byname(pdev, IORESOURCE_MEM, "config");
> 
> how cfg_res->start is now 0x20001000? Shouldn't cfg_res->start be
> 0x1000?
> 
> What am I missing?

IIUC, converting to the cpu address happens long back when the platform device
is created from dt node.

See if the following makes sense to you.

starting from drivers/of/platform.c
of_device_alloc() -> of_address_to_resource() -> __of_address_to_resource() ->
of_translate_address() -> __of_translate_address() -> of_translate_one() ->
of_bus_default_translate()

So the 'resource' in 'struct platform_device' already holds the translated
address. platform_get_resource_byname() just returns the resource from this
platform device.

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