From: Kishon Vijay Abraham I <kishon@ti.com>
To: Arnd Bergmann <arnd@arndb.de>
Cc: Pratyush Anand <pratyush.anand@st.com>,
Jingoo Han <jg1.han@samsung.com>,
"'Bjorn Helgaas'" <bhelgaas@google.com>,
"linux-pci@vger.kernel.org" <linux-pci@vger.kernel.org>,
"linux-samsung-soc@vger.kernel.org"
<linux-samsung-soc@vger.kernel.org>,
"'Kukjin Kim'" <kgene.kim@samsung.com>,
Mohit KUMAR DCG <Mohit.KUMAR@st.com>,
"'Sean Cross'" <xobs@kosagi.com>,
"'Thierry Reding'" <thierry.reding@gmail.com>,
"'SRIKANTH TUMKUR SHIVANAND'" <ts.srikanth@samsung.com>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"devicetree@vger.kernel.org" <devicetree@vger.kernel.org>
Subject: Re: [PATCH V3] pci: exynos: split into two parts such as Synopsys part and Exynos part
Date: Sun, 22 Sep 2013 16:46:34 +0530 [thread overview]
Message-ID: <523ED192.901@ti.com> (raw)
In-Reply-To: <201309220003.34732.arnd@arndb.de>
Hi Arnd,
Thanks for replying :-)
On Sunday 22 September 2013 03:33 AM, Arnd Bergmann wrote:
> On Saturday 21 September 2013, Kishon Vijay Abraham I wrote:
>> {
>> u32 val;
>> void __iomem *val1;
>> void __iomem *dbi_base = pp->dbi_base;
>>
>> /* Program viewport 0 : INBOUND : MEMORY*/
>> val = PCIE_ATU_REGION_INBOUND | (0 & 0xF);
>> dw_pcie_writel_rc(pp, val, dbi_base + PCIE_ATU_VIEWPORT);
>> val1 = ioremap(0x80000000, 0x5fffffff);
>
> The ioremap here makes no sense at all, and I suspect it will fail anyway,
> because you exhaust the vmalloc area size, but since the value is not
> used anywhere, it won't matter.
>
>> dw_pcie_writel_rc(pp, 0x80000000, dbi_base + PCIE_ATU_LOWER_BASE);
>> dw_pcie_writel_rc(pp, 0, dbi_base + PCIE_ATU_UPPER_BASE);
>> /* in_mem_size must be in power of 2 */
>> dw_pcie_writel_rc(pp, 0x5FFFFFFF, dbi_base + PCIE_ATU_LIMIT);
>> dw_pcie_writel_rc(pp, 0x80000000, dbi_base + PCIE_ATU_LOWER_TARGET);
>> dw_pcie_writel_rc(pp, 0, dbi_base + PCIE_ATU_UPPER_TARGET);
>
> These numbers need to come from somewhere, you shouldn't just hardcode them,
right. I'm still in the process of getting it work ;-)
>
> I guess you should either program an inbound window covering the entire 64-bit
> address space, or you should look at the top-level "memory" nodes to find
> the location of physical RAM.
>
> I can't see anything wrong with the way it's set up though, unless you have
> an IOMMU. Can you confirm that there is no IOMMU (aka SMMU) in your system
> that handles the PCIe root complex?
There is a MMU for PCIe root complex but that's disabled.
>
>> I somehow starting to doubt the DMA address programmed in the ethernet card
>> which is in my RAM address range (0x80000000 to 0xBFFFFFFF). Should this
>> address be programmed in the BAR of the ethernet card? How should it be done?
>
> No, it should not be in the BAR. The ethernet device driver calls dma_map_*
> or pci_map_* interfaces to get a valid token that can be passed into the
> device registers that are starting the DMA. You have to ensure that the
> dma_map_ops for the device return the value that is set up in the translation.
>
> The normal case is an identity mapping between device DMA space and host
> memory space, i.e. PCIE_ATU_LOWER_TARGET == PCIE_ATU_LOWER_BASE, so
> in the dma_map_single implementation, phys_addr_t == dma_addr_t.
>
> If you set up the dma_addr_t space to start at 0 instead, you have to add
> the offset in the dma_map_ops.
My DMA address is in 0x80000000 to 0xBFFFFFFF range and I program my inbound
translation for this range. Not sure what is missing still :-(
Thanks
Kishon
WARNING: multiple messages have this Message-ID (diff)
From: Kishon Vijay Abraham I <kishon-l0cyMroinI0@public.gmane.org>
To: Arnd Bergmann <arnd-r2nGTMty4D4@public.gmane.org>
Cc: Pratyush Anand <pratyush.anand-qxv4g6HH51o@public.gmane.org>,
Jingoo Han <jg1.han-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org>,
'Bjorn Helgaas'
<bhelgaas-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org>,
"linux-pci-u79uwXL29TY76Z2rM5mHXA@public.gmane.org"
<linux-pci-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
"linux-samsung-soc-u79uwXL29TY76Z2rM5mHXA@public.gmane.org"
<linux-samsung-soc-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
'Kukjin Kim' <kgene.kim-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org>,
Mohit KUMAR DCG <Mohit.KUMAR-qxv4g6HH51o@public.gmane.org>,
'Sean Cross' <xobs-nXMMniAx+RbQT0dZR+AlfA@public.gmane.org>,
'Thierry Reding'
<thierry.reding-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>,
'SRIKANTH TUMKUR SHIVANAND'
<ts.srikanth-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org>,
"linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org"
<linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
"devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org"
<devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>
Subject: Re: [PATCH V3] pci: exynos: split into two parts such as Synopsys part and Exynos part
Date: Sun, 22 Sep 2013 16:46:34 +0530 [thread overview]
Message-ID: <523ED192.901@ti.com> (raw)
In-Reply-To: <201309220003.34732.arnd-r2nGTMty4D4@public.gmane.org>
Hi Arnd,
Thanks for replying :-)
On Sunday 22 September 2013 03:33 AM, Arnd Bergmann wrote:
> On Saturday 21 September 2013, Kishon Vijay Abraham I wrote:
>> {
>> u32 val;
>> void __iomem *val1;
>> void __iomem *dbi_base = pp->dbi_base;
>>
>> /* Program viewport 0 : INBOUND : MEMORY*/
>> val = PCIE_ATU_REGION_INBOUND | (0 & 0xF);
>> dw_pcie_writel_rc(pp, val, dbi_base + PCIE_ATU_VIEWPORT);
>> val1 = ioremap(0x80000000, 0x5fffffff);
>
> The ioremap here makes no sense at all, and I suspect it will fail anyway,
> because you exhaust the vmalloc area size, but since the value is not
> used anywhere, it won't matter.
>
>> dw_pcie_writel_rc(pp, 0x80000000, dbi_base + PCIE_ATU_LOWER_BASE);
>> dw_pcie_writel_rc(pp, 0, dbi_base + PCIE_ATU_UPPER_BASE);
>> /* in_mem_size must be in power of 2 */
>> dw_pcie_writel_rc(pp, 0x5FFFFFFF, dbi_base + PCIE_ATU_LIMIT);
>> dw_pcie_writel_rc(pp, 0x80000000, dbi_base + PCIE_ATU_LOWER_TARGET);
>> dw_pcie_writel_rc(pp, 0, dbi_base + PCIE_ATU_UPPER_TARGET);
>
> These numbers need to come from somewhere, you shouldn't just hardcode them,
right. I'm still in the process of getting it work ;-)
>
> I guess you should either program an inbound window covering the entire 64-bit
> address space, or you should look at the top-level "memory" nodes to find
> the location of physical RAM.
>
> I can't see anything wrong with the way it's set up though, unless you have
> an IOMMU. Can you confirm that there is no IOMMU (aka SMMU) in your system
> that handles the PCIe root complex?
There is a MMU for PCIe root complex but that's disabled.
>
>> I somehow starting to doubt the DMA address programmed in the ethernet card
>> which is in my RAM address range (0x80000000 to 0xBFFFFFFF). Should this
>> address be programmed in the BAR of the ethernet card? How should it be done?
>
> No, it should not be in the BAR. The ethernet device driver calls dma_map_*
> or pci_map_* interfaces to get a valid token that can be passed into the
> device registers that are starting the DMA. You have to ensure that the
> dma_map_ops for the device return the value that is set up in the translation.
>
> The normal case is an identity mapping between device DMA space and host
> memory space, i.e. PCIE_ATU_LOWER_TARGET == PCIE_ATU_LOWER_BASE, so
> in the dma_map_single implementation, phys_addr_t == dma_addr_t.
>
> If you set up the dma_addr_t space to start at 0 instead, you have to add
> the offset in the dma_map_ops.
My DMA address is in 0x80000000 to 0xBFFFFFFF range and I program my inbound
translation for this range. Not sure what is missing still :-(
Thanks
Kishon
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
next prev parent reply other threads:[~2013-09-22 11:16 UTC|newest]
Thread overview: 37+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-07-18 5:21 [PATCH V3] pci: exynos: split into two parts such as Synopsys part and Exynos part Jingoo Han
2013-07-18 5:21 ` Jingoo Han
2013-07-22 15:03 ` Kishon Vijay Abraham I
2013-07-22 15:03 ` Kishon Vijay Abraham I
2013-07-23 1:14 ` Jingoo Han
2013-07-23 4:49 ` Pratyush Anand
2013-07-23 6:29 ` Kishon Vijay Abraham I
2013-07-23 6:29 ` Kishon Vijay Abraham I
2013-07-23 7:00 ` Jingoo Han
2013-07-24 21:02 ` Arnd Bergmann
2013-09-12 6:34 ` Kishon Vijay Abraham I
2013-09-12 6:34 ` Kishon Vijay Abraham I
2013-09-12 7:15 ` Jingoo Han
2013-09-12 9:30 ` Pratyush Anand
2013-09-12 9:43 ` Kishon Vijay Abraham I
2013-09-12 9:52 ` Pratyush Anand
2013-09-12 10:07 ` Kishon Vijay Abraham I
2013-09-12 10:18 ` Pratyush Anand
2013-09-12 10:46 ` Pratyush Anand
2013-09-12 11:14 ` Kishon Vijay Abraham I
2013-09-21 14:56 ` Kishon Vijay Abraham I
2013-09-21 22:03 ` Arnd Bergmann
2013-09-21 22:03 ` Arnd Bergmann
2013-09-22 11:16 ` Kishon Vijay Abraham I [this message]
2013-09-22 11:16 ` Kishon Vijay Abraham I
2013-09-23 4:14 ` Pratyush Anand
2013-09-23 5:32 ` Kishon Vijay Abraham I
2013-09-23 5:32 ` Kishon Vijay Abraham I
2013-09-23 6:50 ` Pratyush Anand
2013-09-23 6:50 ` Pratyush Anand
2013-09-24 21:23 ` Arnd Bergmann
2013-09-26 5:06 ` Kishon Vijay Abraham I
2013-09-26 9:51 ` Arnd Bergmann
2013-09-26 10:12 ` Kishon Vijay Abraham I
2013-09-26 10:12 ` Kishon Vijay Abraham I
2013-09-12 10:25 ` Jingoo Han
2013-07-23 8:42 ` Jingoo Han
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=523ED192.901@ti.com \
--to=kishon@ti.com \
--cc=Mohit.KUMAR@st.com \
--cc=arnd@arndb.de \
--cc=bhelgaas@google.com \
--cc=devicetree@vger.kernel.org \
--cc=jg1.han@samsung.com \
--cc=kgene.kim@samsung.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pci@vger.kernel.org \
--cc=linux-samsung-soc@vger.kernel.org \
--cc=pratyush.anand@st.com \
--cc=thierry.reding@gmail.com \
--cc=ts.srikanth@samsung.com \
--cc=xobs@kosagi.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.