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]
Date:	Thu, 26 Jun 2014 11:40:02 +0530
From:	Kishon Vijay Abraham I <kishon@...com>
To:	Pratyush Anand <pratyush.anand@...il.com>
CC:	"devicetree@...r.kernel.org" <devicetree@...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>, <grant.likely@...aro.org>,
	Jason Gunthorpe <jgunthorpe@...idianresearch.com>,
	Marek Vasut <marex@...x.de>, Arnd Bergmann <arnd@...db.de>,
	Pratyush ANAND <pratyush.anand@...com>
Subject: Re: [PATCH 2/3] PCI: designware: use untranslated address while programming
 ATU

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.

Thanks
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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ