Re: [PATCH V3] pci: exynos: split into two parts such as Synopsys part and Exynos part
Hi Arnd, On Thursday 26 September 2013 03:21 PM, Arnd Bergmann wrote: > On Thursday 26 September 2013, Kishon Vijay Abraham I wrote: >> On Wednesday 25 September 2013 02:53 AM, Arnd Bergmann wrote: >>> On Monday 23 September 2013, Kishon Vijay Abraham I wrote: Btw if we hadn't programmed inbound translation table, the address will go untranslated (according to the data book). I guess that's how it was working for Jingoo Han. ** 3.10.4 Inbound iATU Operation When there is no match, then the address is untranslated ** >>> >>> Well, that should work just as well, since you have a 1:1 translation >>> anyway. >>> Do you get the same error without the translation? >> >> Yes. I get the same non-fatal error interrupt in RC. > > Ok, then I guess the translation is actually not at fault here but something > else. I would recommend looking at the IOMMU as the potential culprit. Maybe > having it disabled means that no DMA is going through, rather than all DMA > going through untranslated. Another possibility is that the IOMMU is set up > so that when disabled, it maps DMA address 0 to the start of RAM, rather > than identity mapping DMA address 0x8000 there. If that's the case, > you either have to use the IOMMU, or set up the mapping in the root > complex to revert it. Thanks for your inputs. I'll check if that's the problem. Thanks Kishon -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH V3] pci: exynos: split into two parts such as Synopsys part and Exynos part
On Thursday 26 September 2013, Kishon Vijay Abraham I wrote: > On Wednesday 25 September 2013 02:53 AM, Arnd Bergmann wrote: > > On Monday 23 September 2013, Kishon Vijay Abraham I wrote: > >> Btw if we hadn't programmed inbound translation table, the address will go > >> untranslated (according to the data book). I guess that's how it was > >> working > >> for Jingoo Han. > >> > >> ** > >> 3.10.4 > >> Inbound iATU Operation > >> > >> When there is no match, then the address is untranslated > >> ** > >> > > > > Well, that should work just as well, since you have a 1:1 translation > > anyway. > > Do you get the same error without the translation? > > Yes. I get the same non-fatal error interrupt in RC. Ok, then I guess the translation is actually not at fault here but something else. I would recommend looking at the IOMMU as the potential culprit. Maybe having it disabled means that no DMA is going through, rather than all DMA going through untranslated. Another possibility is that the IOMMU is set up so that when disabled, it maps DMA address 0 to the start of RAM, rather than identity mapping DMA address 0x8000 there. If that's the case, you either have to use the IOMMU, or set up the mapping in the root complex to revert it. Arnd -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH V3] pci: exynos: split into two parts such as Synopsys part and Exynos part
On Thursday 26 September 2013, Kishon Vijay Abraham I wrote: On Wednesday 25 September 2013 02:53 AM, Arnd Bergmann wrote: On Monday 23 September 2013, Kishon Vijay Abraham I wrote: Btw if we hadn't programmed inbound translation table, the address will go untranslated (according to the data book). I guess that's how it was working for Jingoo Han. ** 3.10.4 Inbound iATU Operation When there is no match, then the address is untranslated ** Well, that should work just as well, since you have a 1:1 translation anyway. Do you get the same error without the translation? Yes. I get the same non-fatal error interrupt in RC. Ok, then I guess the translation is actually not at fault here but something else. I would recommend looking at the IOMMU as the potential culprit. Maybe having it disabled means that no DMA is going through, rather than all DMA going through untranslated. Another possibility is that the IOMMU is set up so that when disabled, it maps DMA address 0 to the start of RAM, rather than identity mapping DMA address 0x8000 there. If that's the case, you either have to use the IOMMU, or set up the mapping in the root complex to revert it. Arnd -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH V3] pci: exynos: split into two parts such as Synopsys part and Exynos part
Hi Arnd, On Thursday 26 September 2013 03:21 PM, Arnd Bergmann wrote: On Thursday 26 September 2013, Kishon Vijay Abraham I wrote: On Wednesday 25 September 2013 02:53 AM, Arnd Bergmann wrote: On Monday 23 September 2013, Kishon Vijay Abraham I wrote: Btw if we hadn't programmed inbound translation table, the address will go untranslated (according to the data book). I guess that's how it was working for Jingoo Han. ** 3.10.4 Inbound iATU Operation When there is no match, then the address is untranslated ** Well, that should work just as well, since you have a 1:1 translation anyway. Do you get the same error without the translation? Yes. I get the same non-fatal error interrupt in RC. Ok, then I guess the translation is actually not at fault here but something else. I would recommend looking at the IOMMU as the potential culprit. Maybe having it disabled means that no DMA is going through, rather than all DMA going through untranslated. Another possibility is that the IOMMU is set up so that when disabled, it maps DMA address 0 to the start of RAM, rather than identity mapping DMA address 0x8000 there. If that's the case, you either have to use the IOMMU, or set up the mapping in the root complex to revert it. Thanks for your inputs. I'll check if that's the problem. Thanks Kishon -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH V3] pci: exynos: split into two parts such as Synopsys part and Exynos part
On Wednesday 25 September 2013 02:53 AM, Arnd Bergmann wrote: > On Monday 23 September 2013, Kishon Vijay Abraham I wrote: >> Btw if we hadn't programmed inbound translation table, the address will go >> untranslated (according to the data book). I guess that's how it was working >> for Jingoo Han. >> >> ** >> 3.10.4 >> Inbound iATU Operation >> >> When there is no match, then the address is untranslated >> ** >> > > Well, that should work just as well, since you have a 1:1 translation anyway. > Do you get the same error without the translation? Yes. I get the same non-fatal error interrupt in RC. Thanks Kishon -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH V3] pci: exynos: split into two parts such as Synopsys part and Exynos part
On Wednesday 25 September 2013 02:53 AM, Arnd Bergmann wrote: On Monday 23 September 2013, Kishon Vijay Abraham I wrote: Btw if we hadn't programmed inbound translation table, the address will go untranslated (according to the data book). I guess that's how it was working for Jingoo Han. ** 3.10.4 Inbound iATU Operation When there is no match, then the address is untranslated ** Well, that should work just as well, since you have a 1:1 translation anyway. Do you get the same error without the translation? Yes. I get the same non-fatal error interrupt in RC. Thanks Kishon -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH V3] pci: exynos: split into two parts such as Synopsys part and Exynos part
On Monday 23 September 2013, Kishon Vijay Abraham I wrote: > Btw if we hadn't programmed inbound translation table, the address will go > untranslated (according to the data book). I guess that's how it was working > for Jingoo Han. > > ** > 3.10.4 > Inbound iATU Operation > > When there is no match, then the address is untranslated > ** > Well, that should work just as well, since you have a 1:1 translation anyway. Do you get the same error without the translation? Arnd -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH V3] pci: exynos: split into two parts such as Synopsys part and Exynos part
On Monday 23 September 2013, Kishon Vijay Abraham I wrote: Btw if we hadn't programmed inbound translation table, the address will go untranslated (according to the data book). I guess that's how it was working for Jingoo Han. ** 3.10.4 Inbound iATU Operation When there is no match, then the address is untranslated ** Well, that should work just as well, since you have a 1:1 translation anyway. Do you get the same error without the translation? Arnd -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH V3] pci: exynos: split into two parts such as Synopsys part and Exynos part
On Mon, Sep 23, 2013 at 01:32:54PM +0800, Kishon Vijay Abraham I wrote:
> Hi Pratyush,
>
> On Monday 23 September 2013 09:44 AM, Pratyush Anand wrote:
> > Hi Kishon,
> >
> >
> > On Sun, Sep 22, 2013 at 07:16:34PM +0800, Kishon Vijay Abraham I wrote:
> >> 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(0x8000, 0x5fff);
> >>>
> >>> 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, 0x8000, 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, 0x5FFF, dbi_base + PCIE_ATU_LIMIT);
> >
> > This is wrong. You should program here 0xBFFF.
>
> That dint help :-(
>
> Btw if we hadn't programmed inbound translation table, the address will go
> untranslated (according to the data book). I guess that's how it was working
> for Jingoo Han.
>
> **
> 3.10.4
> Inbound iATU Operation
>
> When there is no match, then the address is untranslated
> **
>
ok.. so it seems that you might not be getting non-fatal error because
of address translation. I am not working with PCIe for a long time,
but if I remember correctly other reason for getting this error were
unsupported read/write request size. Although, you have said that MRRS
is 512 for your RC. Can you cross check both programmed MPS and MRRS
in your RC as well as your EP (ethernet card). May be you can share
Content of PCIe Capability Device Control Register (Offset 08h) for
both RC and EP.
Regards
Pratyush
> >
> > Translation rule is as follows:
> >
> > Region between "Start Address" and "End Address" is translated to
> > "Target Address" with region size = "End Address" - "Start Address".
> > Where: Start Address = (PCIE_ATU_UPPER_BASE | PCIE_ATU_LOWER_BASE)
> > End Address = (PCIE_ATU_UPPER_BASE | PCIE_ATU_LIMIT)
> > Target Address = (PCIE_ATU_UPPER_TARGET | PCIE_ATU_LOWER_TARGET)
> >
> dw_pcie_writel_rc(pp, 0x8000, 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 (0x8000 to 0xBFFF). 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 0x8000 to 0xBFFF range and I program my
> >> inbound
> >> translation for this range. Not sure what is missing still :-(
> >
> > Hope, above modification helps. Let me know.
> >
> > Regards
> > Pratyush
> >>
> >> Thanks
> >> Kishon
>
> Thanks
> Kishon
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH V3] pci: exynos: split into two parts such as Synopsys part and Exynos part
On Mon, Sep 23, 2013 at 01:32:54PM +0800, Kishon Vijay Abraham I wrote:
Hi Pratyush,
On Monday 23 September 2013 09:44 AM, Pratyush Anand wrote:
Hi Kishon,
On Sun, Sep 22, 2013 at 07:16:34PM +0800, Kishon Vijay Abraham I wrote:
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(0x8000, 0x5fff);
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, 0x8000, 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, 0x5FFF, dbi_base + PCIE_ATU_LIMIT);
This is wrong. You should program here 0xBFFF.
That dint help :-(
Btw if we hadn't programmed inbound translation table, the address will go
untranslated (according to the data book). I guess that's how it was working
for Jingoo Han.
**
3.10.4
Inbound iATU Operation
When there is no match, then the address is untranslated
**
ok.. so it seems that you might not be getting non-fatal error because
of address translation. I am not working with PCIe for a long time,
but if I remember correctly other reason for getting this error were
unsupported read/write request size. Although, you have said that MRRS
is 512 for your RC. Can you cross check both programmed MPS and MRRS
in your RC as well as your EP (ethernet card). May be you can share
Content of PCIe Capability Device Control Register (Offset 08h) for
both RC and EP.
Regards
Pratyush
Translation rule is as follows:
Region between Start Address and End Address is translated to
Target Address with region size = End Address - Start Address.
Where: Start Address = (PCIE_ATU_UPPER_BASE | PCIE_ATU_LOWER_BASE)
End Address = (PCIE_ATU_UPPER_BASE | PCIE_ATU_LIMIT)
Target Address = (PCIE_ATU_UPPER_TARGET | PCIE_ATU_LOWER_TARGET)
dw_pcie_writel_rc(pp, 0x8000, 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 (0x8000 to 0xBFFF). 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 0x8000 to 0xBFFF range and I program my
inbound
translation for this range. Not sure what is missing still :-(
Hope, above modification helps. Let me know.
Regards
Pratyush
Thanks
Kishon
Thanks
Kishon
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH V3] pci: exynos: split into two parts such as Synopsys part and Exynos part
Hi Pratyush,
On Monday 23 September 2013 09:44 AM, Pratyush Anand wrote:
> Hi Kishon,
>
>
> On Sun, Sep 22, 2013 at 07:16:34PM +0800, Kishon Vijay Abraham I wrote:
>> 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(0x8000, 0x5fff);
>>>
>>> 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, 0x8000, 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, 0x5FFF, dbi_base + PCIE_ATU_LIMIT);
>
> This is wrong. You should program here 0xBFFF.
That dint help :-(
Btw if we hadn't programmed inbound translation table, the address will go
untranslated (according to the data book). I guess that's how it was working
for Jingoo Han.
**
3.10.4
Inbound iATU Operation
When there is no match, then the address is untranslated
**
>
> Translation rule is as follows:
>
> Region between "Start Address" and "End Address" is translated to
> "Target Address" with region size = "End Address" - "Start Address".
> Where: Start Address = (PCIE_ATU_UPPER_BASE | PCIE_ATU_LOWER_BASE)
> End Address = (PCIE_ATU_UPPER_BASE | PCIE_ATU_LIMIT)
> Target Address = (PCIE_ATU_UPPER_TARGET | PCIE_ATU_LOWER_TARGET)
>
dw_pcie_writel_rc(pp, 0x8000, 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 (0x8000 to 0xBFFF). 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 0x8000 to 0xBFFF range and I program my inbound
>> translation for this range. Not sure what is missing still :-(
>
> Hope, above modification helps. Let me know.
>
> Regards
> Pratyush
>>
>> Thanks
>> Kishon
Thanks
Kishon
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH V3] pci: exynos: split into two parts such as Synopsys part and Exynos part
Hi Kishon,
On Sun, Sep 22, 2013 at 07:16:34PM +0800, Kishon Vijay Abraham I wrote:
> 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(0x8000, 0x5fff);
> >
> > 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, 0x8000, 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, 0x5FFF, dbi_base + PCIE_ATU_LIMIT);
This is wrong. You should program here 0xBFFF.
Translation rule is as follows:
Region between "Start Address" and "End Address" is translated to
"Target Address" with region size = "End Address" - "Start Address".
Where: Start Address = (PCIE_ATU_UPPER_BASE | PCIE_ATU_LOWER_BASE)
End Address = (PCIE_ATU_UPPER_BASE | PCIE_ATU_LIMIT)
Target Address = (PCIE_ATU_UPPER_TARGET | PCIE_ATU_LOWER_TARGET)
> >> dw_pcie_writel_rc(pp, 0x8000, 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 (0x8000 to 0xBFFF). 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 0x8000 to 0xBFFF range and I program my inbound
> translation for this range. Not sure what is missing still :-(
Hope, above modification helps. Let me know.
Regards
Pratyush
>
> Thanks
> Kishon
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH V3] pci: exynos: split into two parts such as Synopsys part and Exynos part
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(0x8000, 0x5fff);
>
> 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, 0x8000, 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, 0x5FFF, dbi_base + PCIE_ATU_LIMIT);
>> dw_pcie_writel_rc(pp, 0x8000, 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 (0x8000 to 0xBFFF). 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 0x8000 to 0xBFFF 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 linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH V3] pci: exynos: split into two parts such as Synopsys part and Exynos part
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(0x8000, 0x5fff);
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, 0x8000, 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, 0x5FFF, dbi_base + PCIE_ATU_LIMIT);
dw_pcie_writel_rc(pp, 0x8000, 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 (0x8000 to 0xBFFF). 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 0x8000 to 0xBFFF 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 linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH V3] pci: exynos: split into two parts such as Synopsys part and Exynos part
Hi Kishon,
On Sun, Sep 22, 2013 at 07:16:34PM +0800, Kishon Vijay Abraham I wrote:
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(0x8000, 0x5fff);
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, 0x8000, 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, 0x5FFF, dbi_base + PCIE_ATU_LIMIT);
This is wrong. You should program here 0xBFFF.
Translation rule is as follows:
Region between Start Address and End Address is translated to
Target Address with region size = End Address - Start Address.
Where: Start Address = (PCIE_ATU_UPPER_BASE | PCIE_ATU_LOWER_BASE)
End Address = (PCIE_ATU_UPPER_BASE | PCIE_ATU_LIMIT)
Target Address = (PCIE_ATU_UPPER_TARGET | PCIE_ATU_LOWER_TARGET)
dw_pcie_writel_rc(pp, 0x8000, 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 (0x8000 to 0xBFFF). 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 0x8000 to 0xBFFF range and I program my inbound
translation for this range. Not sure what is missing still :-(
Hope, above modification helps. Let me know.
Regards
Pratyush
Thanks
Kishon
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH V3] pci: exynos: split into two parts such as Synopsys part and Exynos part
Hi Pratyush,
On Monday 23 September 2013 09:44 AM, Pratyush Anand wrote:
Hi Kishon,
On Sun, Sep 22, 2013 at 07:16:34PM +0800, Kishon Vijay Abraham I wrote:
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(0x8000, 0x5fff);
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, 0x8000, 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, 0x5FFF, dbi_base + PCIE_ATU_LIMIT);
This is wrong. You should program here 0xBFFF.
That dint help :-(
Btw if we hadn't programmed inbound translation table, the address will go
untranslated (according to the data book). I guess that's how it was working
for Jingoo Han.
**
3.10.4
Inbound iATU Operation
When there is no match, then the address is untranslated
**
Translation rule is as follows:
Region between Start Address and End Address is translated to
Target Address with region size = End Address - Start Address.
Where: Start Address = (PCIE_ATU_UPPER_BASE | PCIE_ATU_LOWER_BASE)
End Address = (PCIE_ATU_UPPER_BASE | PCIE_ATU_LIMIT)
Target Address = (PCIE_ATU_UPPER_TARGET | PCIE_ATU_LOWER_TARGET)
dw_pcie_writel_rc(pp, 0x8000, 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 (0x8000 to 0xBFFF). 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 0x8000 to 0xBFFF range and I program my inbound
translation for this range. Not sure what is missing still :-(
Hope, above modification helps. Let me know.
Regards
Pratyush
Thanks
Kishon
Thanks
Kishon
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH V3] pci: exynos: split into two parts such as Synopsys part and Exynos part
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(0x8000, 0x5fff);
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, 0x8000, 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, 0x5FFF, dbi_base + PCIE_ATU_LIMIT);
> dw_pcie_writel_rc(pp, 0x8000, 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,
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?
> I somehow starting to doubt the DMA address programmed in the ethernet card
> which is in my RAM address range (0x8000 to 0xBFFF). 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.
Arnd
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH V3] pci: exynos: split into two parts such as Synopsys part and Exynos part
Hi,
On Thursday 12 September 2013 04:16 PM, Pratyush Anand wrote:
> On Thu, Sep 12, 2013 at 03:48:03PM +0530, Pratyush Anand wrote:
>> On Thu, Sep 12, 2013 at 06:07:23PM +0800, Kishon Vijay Abraham I wrote:
>>> Hi,
>>>
>>> On Thursday 12 September 2013 03:22 PM, Pratyush Anand wrote:
Hi Kishon,
On Thu, Sep 12, 2013 at 05:43:40PM +0800, Kishon Vijay Abraham I wrote:
> Hi,
>
> On Thursday 12 September 2013 03:00 PM, Pratyush Anand wrote:
>> Hi Jingoo,
>>
>>
>> On Thu, Sep 12, 2013 at 03:15:04PM +0800, Jingoo Han wrote:
>>> On Tuesday 23 July 2013 12:30 PM, Kishon Vijay Abraham I wrote:
>> .
>> .
>>
>> [...]
>>
> when I do ifconfig eth0 up, I get *r8169 :01:00.0 eth0: link up.*
> But I dont receive any packets and ping also fails and the tx and rx
> packet
> count is also 0. Could it be related to inbound translation?
A PCIe analyser log would tell a definite cause. Most likely either
inbound translation is not working or INTx/MSI is not working.
>>>
>>> I have enabled only legacy interrupts. Whenever I connect or disconnect
>>> ethernet cable I get link up/link down message and also the interrupt count
>>> for
>>> eth0 increases. So I'm not doubting INTx interrupts as such.
>
> Just a question, what is the MRRS of your RC? if it is 128, can you
> try with passing pci=pcie_bus_peer2peer in your bootargs.
>
> Again, analyser will help a lot in diagnosing such issues.
>
> Regards
> Pratyush
>>>
>>> btw configuring inbound translation once in dw_pcie_host_init enough is it?
>>> I
>>> mean we use the same registers for configuring outbound translation also
>>> no? So
>>> doesn't the inbound configuration gets lost?
>>
>> No, you write at the same register, but you program direction as
>> inbound. There are different resources for each viewport in inbound
>> and outbound direction.
I did inbound translation programming like
static void dw_pcie_prog_viewport_mem_inbound(struct pcie_port *pp)
{
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(0x8000, 0x5fff);
dw_pcie_writel_rc(pp, 0x8000, 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, 0x5FFF, dbi_base + PCIE_ATU_LIMIT);
dw_pcie_writel_rc(pp, 0x8000, dbi_base + PCIE_ATU_LOWER_TARGET);
dw_pcie_writel_rc(pp, 0, dbi_base + PCIE_ATU_UPPER_TARGET);
dw_pcie_writel_rc(pp, PCIE_ATU_TYPE_MEM, dbi_base + PCIE_ATU_CR1);
val = PCIE_ATU_ENABLE;
dw_pcie_writel_rc(pp, val, dbi_base + PCIE_ATU_CR2);
}
I'm using Realtek Semiconductor Co., Ltd. RTL8111/8168B PCI Express
Gigabit Ethernet controller (TP-LINK TG-3468) (it uses r8169 driver).
whenever I do a ifconfig ethp up, I get a non fatal error interrupt (after
Transmitter/Receiver Enable in r8169 driver).
I somehow starting to doubt the DMA address programmed in the ethernet card
which is in my RAM address range (0x8000 to 0xBFFF). Should this
address be programmed in the BAR of the ethernet card? How should it be done?
My pcie dt data looks like this.
ranges = <0x0800 0 0x2000 0x2000 0 0x1000 /* configuration
space */
0x8100 0 0 0x20001000 0 0x0001 /* io */
0x8200 0 0x20011000 0x20011000 0 0x0ffef000>; /* memory */
Thanks
Kishon
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH V3] pci: exynos: split into two parts such as Synopsys part and Exynos part
Hi,
On Thursday 12 September 2013 04:16 PM, Pratyush Anand wrote:
On Thu, Sep 12, 2013 at 03:48:03PM +0530, Pratyush Anand wrote:
On Thu, Sep 12, 2013 at 06:07:23PM +0800, Kishon Vijay Abraham I wrote:
Hi,
On Thursday 12 September 2013 03:22 PM, Pratyush Anand wrote:
Hi Kishon,
On Thu, Sep 12, 2013 at 05:43:40PM +0800, Kishon Vijay Abraham I wrote:
Hi,
On Thursday 12 September 2013 03:00 PM, Pratyush Anand wrote:
Hi Jingoo,
On Thu, Sep 12, 2013 at 03:15:04PM +0800, Jingoo Han wrote:
On Tuesday 23 July 2013 12:30 PM, Kishon Vijay Abraham I wrote:
.
.
[...]
when I do ifconfig eth0 up, I get *r8169 :01:00.0 eth0: link up.*
But I dont receive any packets and ping also fails and the tx and rx
packet
count is also 0. Could it be related to inbound translation?
A PCIe analyser log would tell a definite cause. Most likely either
inbound translation is not working or INTx/MSI is not working.
I have enabled only legacy interrupts. Whenever I connect or disconnect
ethernet cable I get link up/link down message and also the interrupt count
for
eth0 increases. So I'm not doubting INTx interrupts as such.
Just a question, what is the MRRS of your RC? if it is 128, can you
try with passing pci=pcie_bus_peer2peer in your bootargs.
Again, analyser will help a lot in diagnosing such issues.
Regards
Pratyush
btw configuring inbound translation once in dw_pcie_host_init enough is it?
I
mean we use the same registers for configuring outbound translation also
no? So
doesn't the inbound configuration gets lost?
No, you write at the same register, but you program direction as
inbound. There are different resources for each viewport in inbound
and outbound direction.
I did inbound translation programming like
static void dw_pcie_prog_viewport_mem_inbound(struct pcie_port *pp)
{
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(0x8000, 0x5fff);
dw_pcie_writel_rc(pp, 0x8000, 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, 0x5FFF, dbi_base + PCIE_ATU_LIMIT);
dw_pcie_writel_rc(pp, 0x8000, dbi_base + PCIE_ATU_LOWER_TARGET);
dw_pcie_writel_rc(pp, 0, dbi_base + PCIE_ATU_UPPER_TARGET);
dw_pcie_writel_rc(pp, PCIE_ATU_TYPE_MEM, dbi_base + PCIE_ATU_CR1);
val = PCIE_ATU_ENABLE;
dw_pcie_writel_rc(pp, val, dbi_base + PCIE_ATU_CR2);
}
I'm using Realtek Semiconductor Co., Ltd. RTL8111/8168B PCI Express
Gigabit Ethernet controller (TP-LINK TG-3468) (it uses r8169 driver).
whenever I do a ifconfig ethp up, I get a non fatal error interrupt (after
Transmitter/Receiver Enable in r8169 driver).
I somehow starting to doubt the DMA address programmed in the ethernet card
which is in my RAM address range (0x8000 to 0xBFFF). Should this
address be programmed in the BAR of the ethernet card? How should it be done?
My pcie dt data looks like this.
ranges = 0x0800 0 0x2000 0x2000 0 0x1000 /* configuration
space */
0x8100 0 0 0x20001000 0 0x0001 /* io */
0x8200 0 0x20011000 0x20011000 0 0x0ffef000; /* memory */
Thanks
Kishon
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH V3] pci: exynos: split into two parts such as Synopsys part and Exynos part
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(0x8000, 0x5fff);
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, 0x8000, 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, 0x5FFF, dbi_base + PCIE_ATU_LIMIT);
dw_pcie_writel_rc(pp, 0x8000, 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,
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?
I somehow starting to doubt the DMA address programmed in the ethernet card
which is in my RAM address range (0x8000 to 0xBFFF). 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.
Arnd
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH V3] pci: exynos: split into two parts such as Synopsys part and Exynos part
On Thursday 12 September 2013 04:16 PM, Pratyush Anand wrote: > On Thu, Sep 12, 2013 at 03:48:03PM +0530, Pratyush Anand wrote: >> On Thu, Sep 12, 2013 at 06:07:23PM +0800, Kishon Vijay Abraham I wrote: >>> Hi, >>> >>> On Thursday 12 September 2013 03:22 PM, Pratyush Anand wrote: Hi Kishon, On Thu, Sep 12, 2013 at 05:43:40PM +0800, Kishon Vijay Abraham I wrote: > Hi, > > On Thursday 12 September 2013 03:00 PM, Pratyush Anand wrote: >> Hi Jingoo, >> >> >> On Thu, Sep 12, 2013 at 03:15:04PM +0800, Jingoo Han wrote: >>> On Tuesday 23 July 2013 12:30 PM, Kishon Vijay Abraham I wrote: >> . >> . >> >> [...] >> > when I do ifconfig eth0 up, I get *r8169 :01:00.0 eth0: link up.* > But I dont receive any packets and ping also fails and the tx and rx > packet > count is also 0. Could it be related to inbound translation? A PCIe analyser log would tell a definite cause. Most likely either inbound translation is not working or INTx/MSI is not working. >>> >>> I have enabled only legacy interrupts. Whenever I connect or disconnect >>> ethernet cable I get link up/link down message and also the interrupt count >>> for >>> eth0 increases. So I'm not doubting INTx interrupts as such. > > Just a question, what is the MRRS of your RC? if it is 128, can you it's 512. > try with passing pci=pcie_bus_peer2peer in your bootargs. > > Again, analyser will help a lot in diagnosing such issues. dont have a analyser here :-( Thanks Kishon -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH V3] pci: exynos: split into two parts such as Synopsys part and Exynos part
On Thu, Sep 12, 2013 at 03:48:03PM +0530, Pratyush Anand wrote: > On Thu, Sep 12, 2013 at 06:07:23PM +0800, Kishon Vijay Abraham I wrote: > > Hi, > > > > On Thursday 12 September 2013 03:22 PM, Pratyush Anand wrote: > > > Hi Kishon, > > > > > > On Thu, Sep 12, 2013 at 05:43:40PM +0800, Kishon Vijay Abraham I wrote: > > >> Hi, > > >> > > >> On Thursday 12 September 2013 03:00 PM, Pratyush Anand wrote: > > >>> Hi Jingoo, > > >>> > > >>> > > >>> On Thu, Sep 12, 2013 at 03:15:04PM +0800, Jingoo Han wrote: > > On Tuesday 23 July 2013 12:30 PM, Kishon Vijay Abraham I wrote: > > >>> . > > >>> . > > [...] > > > >> when I do ifconfig eth0 up, I get *r8169 :01:00.0 eth0: link up.* > > >> But I dont receive any packets and ping also fails and the tx and rx > > >> packet > > >> count is also 0. Could it be related to inbound translation? > > > > > > A PCIe analyser log would tell a definite cause. Most likely either > > > inbound translation is not working or INTx/MSI is not working. > > > > I have enabled only legacy interrupts. Whenever I connect or disconnect > > ethernet cable I get link up/link down message and also the interrupt count > > for > > eth0 increases. So I'm not doubting INTx interrupts as such. Just a question, what is the MRRS of your RC? if it is 128, can you try with passing pci=pcie_bus_peer2peer in your bootargs. Again, analyser will help a lot in diagnosing such issues. Regards Pratyush > > > > btw configuring inbound translation once in dw_pcie_host_init enough is it? > > I > > mean we use the same registers for configuring outbound translation also > > no? So > > doesn't the inbound configuration gets lost? > > No, you write at the same register, but you program direction as > inbound. There are different resources for each viewport in inbound > and outbound direction. > > Regards > Pratyush > > > > > Thanks > > Kishon -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH V3] pci: exynos: split into two parts such as Synopsys part and Exynos part
On Thursday, September 12, 2013 6:44 PM, Kishon Vijay Abraham I wrote: > On Thursday 12 September 2013 03:00 PM, Pratyush Anand wrote: > > > > From this conversation, It seems that you > > have tested this driver and it works fine without inbound translation > > function. I am sure that you would have tested a PCIe card with DMA > > capability such as PCIe2USB or PCIe2Ethernet. Since it worked, it > > means that by default your controller is supporting one to one mapping > > in case of inbound transaction even when address translation is enabled. > > btw, I'm testing Ethernet controller: Realtek Semiconductor Co., Ltd. > RTL8111/8168B PCI Express Gigabit Ethernet controller. > > when I do ifconfig eth0 up, I get *r8169 :01:00.0 eth0: link up.* > But I dont receive any packets and ping also fails and the tx and rx packet > count is also 0. Could it be related to inbound translation? > Hi Kishon, I have tested Ethernet controller: Intel Corporation 82574L PCI Express Gigabit Ethernet controller. Without inbound translation, it works properly with both legacy interrupt mode and MSI mode. Best regards, Jingoo Han -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH V3] pci: exynos: split into two parts such as Synopsys part and Exynos part
On Thu, Sep 12, 2013 at 06:07:23PM +0800, Kishon Vijay Abraham I wrote: > Hi, > > On Thursday 12 September 2013 03:22 PM, Pratyush Anand wrote: > > Hi Kishon, > > > > On Thu, Sep 12, 2013 at 05:43:40PM +0800, Kishon Vijay Abraham I wrote: > >> Hi, > >> > >> On Thursday 12 September 2013 03:00 PM, Pratyush Anand wrote: > >>> Hi Jingoo, > >>> > >>> > >>> On Thu, Sep 12, 2013 at 03:15:04PM +0800, Jingoo Han wrote: > On Tuesday 23 July 2013 12:30 PM, Kishon Vijay Abraham I wrote: > >>> . > >>> . [...] > >> when I do ifconfig eth0 up, I get *r8169 :01:00.0 eth0: link up.* > >> But I dont receive any packets and ping also fails and the tx and rx packet > >> count is also 0. Could it be related to inbound translation? > > > > A PCIe analyser log would tell a definite cause. Most likely either > > inbound translation is not working or INTx/MSI is not working. > > I have enabled only legacy interrupts. Whenever I connect or disconnect > ethernet cable I get link up/link down message and also the interrupt count > for > eth0 increases. So I'm not doubting INTx interrupts as such. > > btw configuring inbound translation once in dw_pcie_host_init enough is it? I > mean we use the same registers for configuring outbound translation also no? > So > doesn't the inbound configuration gets lost? No, you write at the same register, but you program direction as inbound. There are different resources for each viewport in inbound and outbound direction. Regards Pratyush > > Thanks > Kishon -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH V3] pci: exynos: split into two parts such as Synopsys part and Exynos part
Hi, On Thursday 12 September 2013 03:22 PM, Pratyush Anand wrote: > Hi Kishon, > > On Thu, Sep 12, 2013 at 05:43:40PM +0800, Kishon Vijay Abraham I wrote: >> Hi, >> >> On Thursday 12 September 2013 03:00 PM, Pratyush Anand wrote: >>> Hi Jingoo, >>> >>> >>> On Thu, Sep 12, 2013 at 03:15:04PM +0800, Jingoo Han wrote: On Tuesday 23 July 2013 12:30 PM, Kishon Vijay Abraham I wrote: >>> . >>> . >> +of_pci_range_to_resource(, np, >cfg); >> +pp->config.cfg0_size = >> resource_size(>cfg)/2; >> +pp->config.cfg1_size = >> resource_size(>cfg)/2; >> +} >> +} >> + >> +pp->dbi_base = devm_ioremap(pp->dev, pp->cfg.start, >> +resource_size(>cfg)); > > Why is configuraion space divided into two? Sorry, I don't know the exact reason. :( Pratyush Anand may know about this. Pratyush Anand, could you answer the question? Also, if you find some problems, please let me know. > > One more query.. > > Where is inbound translation configuration done in your driver? how > should it > be done? >>> >>> Yes, Kishon is right. Inbound translation configuration is missing in >>> your code and I think it should be implemented. >>> Hi Kishon, Sorry, I cannot understand your question exactly. However, the following thread would be helpful. http://www.spinics.net/lists/arm-kernel/msg252078.html https://lkml.org/lkml/2013/6/17/890 >>> >>> From this conversation, It seems that you >>> have tested this driver and it works fine without inbound translation >>> function. I am sure that you would have tested a PCIe card with DMA >>> capability such as PCIe2USB or PCIe2Ethernet. Since it worked, it >>> means that by default your controller is supporting one to one mapping >>> in case of inbound transaction even when address translation is enabled. >> >> btw, I'm testing Ethernet controller: Realtek Semiconductor Co., Ltd. >> RTL8111/8168B PCI Express Gigabit Ethernet controller. >> >> when I do ifconfig eth0 up, I get *r8169 :01:00.0 eth0: link up.* >> But I dont receive any packets and ping also fails and the tx and rx packet >> count is also 0. Could it be related to inbound translation? > > A PCIe analyser log would tell a definite cause. Most likely either > inbound translation is not working or INTx/MSI is not working. I have enabled only legacy interrupts. Whenever I connect or disconnect ethernet cable I get link up/link down message and also the interrupt count for eth0 increases. So I'm not doubting INTx interrupts as such. btw configuring inbound translation once in dw_pcie_host_init enough is it? I mean we use the same registers for configuring outbound translation also no? So doesn't the inbound configuration gets lost? Thanks Kishon -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH V3] pci: exynos: split into two parts such as Synopsys part and Exynos part
Hi Jingoo,
On Thu, Sep 12, 2013 at 03:15:04PM +0800, Jingoo Han wrote:
> On Tuesday 23 July 2013 12:30 PM, Kishon Vijay Abraham I wrote:
> > >> .
> > >> .
> > > + of_pci_range_to_resource(, np, >cfg);
> > > + pp->config.cfg0_size =
> > > resource_size(>cfg)/2;
> > > + pp->config.cfg1_size =
> > > resource_size(>cfg)/2;
> > > + }
> > > + }
> > > +
> > > + pp->dbi_base = devm_ioremap(pp->dev, pp->cfg.start,
> > > + resource_size(>cfg));
> >
> > Why is configuraion space divided into two?
> > >>>
> > >>> Sorry, I don't know the exact reason. :(
> > >>> Pratyush Anand may know about this.
> > >>> Pratyush Anand, could you answer the question?
> > >>>
> > >>> Also, if you find some problems, please let me know.
> >
> > One more query..
> >
> > Where is inbound translation configuration done in your driver? how should
> > it
> > be done?
>
Yes, Kishon is right. Inbound translation configuration is missing in
your code and I think it should be implemented.
> Hi Kishon,
>
> Sorry, I cannot understand your question exactly.
> However, the following thread would be helpful.
>
> http://www.spinics.net/lists/arm-kernel/msg252078.html
> https://lkml.org/lkml/2013/6/17/890
>From this conversation, It seems that you
have tested this driver and it works fine without inbound translation
function. I am sure that you would have tested a PCIe card with DMA
capability such as PCIe2USB or PCIe2Ethernet. Since it worked, it
means that by default your controller is supporting one to one mapping
in case of inbound transaction even when address translation is enabled.
In my opinion you should call a function like as follows from
dw_pcie_host_init in pcie-designware.c. It will insure one to one
mapping for any inbound request in memory range 0 to (in_mem_size -
1) for all dw implementation.
static void dw_pcie_prog_viewport_mem_inbound(struct pcie_port *pp)
{
u32 val;
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));
dw_pcie_writel_rc(pp, PCIE_ATU_TYPE_MEM, dbi_base + PCIE_ATU_CR1));
val = PCIE_ATU_ENABLE | PCIE_ATU_BAR_MODE_ENABLE;
dw_pcie_writel_rc(pp, val, dbi_base + PCIE_ATU_CR2));
dw_pcie_writel_rc(pp, 0, 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, pp->config.in_mem_size - 1, dbi_base +
PCIE_ATU_LIMIT));
dw_pcie_writel_rc(pp, 0, dbi_base + PCIE_ATU_LOWER_TARGET));
dw_pcie_writel_rc(pp, 0, dbi_base + PCIE_ATU_UPPER_TARGET));
}
Regards
Pratyush
>
> Best regards.
> Jingoo Han
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH V3] pci: exynos: split into two parts such as Synopsys part and Exynos part
Hi Kishon, On Thu, Sep 12, 2013 at 05:43:40PM +0800, Kishon Vijay Abraham I wrote: > Hi, > > On Thursday 12 September 2013 03:00 PM, Pratyush Anand wrote: > > Hi Jingoo, > > > > > > On Thu, Sep 12, 2013 at 03:15:04PM +0800, Jingoo Han wrote: > >> On Tuesday 23 July 2013 12:30 PM, Kishon Vijay Abraham I wrote: > > . > > . > +of_pci_range_to_resource(, np, >cfg); > +pp->config.cfg0_size = > resource_size(>cfg)/2; > +pp->config.cfg1_size = > resource_size(>cfg)/2; > +} > +} > + > +pp->dbi_base = devm_ioremap(pp->dev, pp->cfg.start, > +resource_size(>cfg)); > >>> > >>> Why is configuraion space divided into two? > >> > >> Sorry, I don't know the exact reason. :( > >> Pratyush Anand may know about this. > >> Pratyush Anand, could you answer the question? > >> > >> Also, if you find some problems, please let me know. > >>> > >>> One more query.. > >>> > >>> Where is inbound translation configuration done in your driver? how > >>> should it > >>> be done? > >> > > > > Yes, Kishon is right. Inbound translation configuration is missing in > > your code and I think it should be implemented. > > > >> Hi Kishon, > >> > >> Sorry, I cannot understand your question exactly. > >> However, the following thread would be helpful. > >> > >> http://www.spinics.net/lists/arm-kernel/msg252078.html > >> https://lkml.org/lkml/2013/6/17/890 > > > > From this conversation, It seems that you > > have tested this driver and it works fine without inbound translation > > function. I am sure that you would have tested a PCIe card with DMA > > capability such as PCIe2USB or PCIe2Ethernet. Since it worked, it > > means that by default your controller is supporting one to one mapping > > in case of inbound transaction even when address translation is enabled. > > btw, I'm testing Ethernet controller: Realtek Semiconductor Co., Ltd. > RTL8111/8168B PCI Express Gigabit Ethernet controller. > > when I do ifconfig eth0 up, I get *r8169 :01:00.0 eth0: link up.* > But I dont receive any packets and ping also fails and the tx and rx packet > count is also 0. Could it be related to inbound translation? A PCIe analyser log would tell a definite cause. Most likely either inbound translation is not working or INTx/MSI is not working. Regards Pratyush > > Thanks > Kishon -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH V3] pci: exynos: split into two parts such as Synopsys part and Exynos part
Hi, On Thursday 12 September 2013 03:00 PM, Pratyush Anand wrote: > Hi Jingoo, > > > On Thu, Sep 12, 2013 at 03:15:04PM +0800, Jingoo Han wrote: >> On Tuesday 23 July 2013 12:30 PM, Kishon Vijay Abraham I wrote: > . > . + of_pci_range_to_resource(, np, >cfg); + pp->config.cfg0_size = resource_size(>cfg)/2; + pp->config.cfg1_size = resource_size(>cfg)/2; + } + } + + pp->dbi_base = devm_ioremap(pp->dev, pp->cfg.start, + resource_size(>cfg)); >>> >>> Why is configuraion space divided into two? >> >> Sorry, I don't know the exact reason. :( >> Pratyush Anand may know about this. >> Pratyush Anand, could you answer the question? >> >> Also, if you find some problems, please let me know. >>> >>> One more query.. >>> >>> Where is inbound translation configuration done in your driver? how should >>> it >>> be done? >> > > Yes, Kishon is right. Inbound translation configuration is missing in > your code and I think it should be implemented. > >> Hi Kishon, >> >> Sorry, I cannot understand your question exactly. >> However, the following thread would be helpful. >> >> http://www.spinics.net/lists/arm-kernel/msg252078.html >> https://lkml.org/lkml/2013/6/17/890 > > From this conversation, It seems that you > have tested this driver and it works fine without inbound translation > function. I am sure that you would have tested a PCIe card with DMA > capability such as PCIe2USB or PCIe2Ethernet. Since it worked, it > means that by default your controller is supporting one to one mapping > in case of inbound transaction even when address translation is enabled. btw, I'm testing Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168B PCI Express Gigabit Ethernet controller. when I do ifconfig eth0 up, I get *r8169 :01:00.0 eth0: link up.* But I dont receive any packets and ping also fails and the tx and rx packet count is also 0. Could it be related to inbound translation? Thanks Kishon -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH V3] pci: exynos: split into two parts such as Synopsys part and Exynos part
On Tuesday 23 July 2013 12:30 PM, Kishon Vijay Abraham I wrote: > >> . > >> . > > + of_pci_range_to_resource(, np, >cfg); > > + pp->config.cfg0_size = > > resource_size(>cfg)/2; > > + pp->config.cfg1_size = > > resource_size(>cfg)/2; > > + } > > + } > > + > > + pp->dbi_base = devm_ioremap(pp->dev, pp->cfg.start, > > + resource_size(>cfg)); > > Why is configuraion space divided into two? > >>> > >>> Sorry, I don't know the exact reason. :( > >>> Pratyush Anand may know about this. > >>> Pratyush Anand, could you answer the question? > >>> > >>> Also, if you find some problems, please let me know. > > One more query.. > > Where is inbound translation configuration done in your driver? how should it > be done? Hi Kishon, Sorry, I cannot understand your question exactly. However, the following thread would be helpful. http://www.spinics.net/lists/arm-kernel/msg252078.html https://lkml.org/lkml/2013/6/17/890 Best regards. Jingoo Han -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH V3] pci: exynos: split into two parts such as Synopsys part and Exynos part
Hi Jingoo, On Tuesday 23 July 2013 12:30 PM, Jingoo Han wrote: > On Tuesday, July 23, 2013 3:30 PM, Kishon Vijay Abraham I wrote: >> On Tuesday 23 July 2013 06:44 AM, Jingoo Han wrote: >>> On Tuesday, July 23, 2013 12:04 AM, Kishon Vijay Abraham I wrote: On Thursday 18 July 2013 10:51 AM, Jingoo Han wrote: > Exynos PCIe IP consists of Synopsys specific part and Exynos > specific part. Only core block is a Synopsys designware part; > other parts are Exynos specific. > Also, the Synopsys designware part can be shared with other > platforms; thus, it can be split two parts such as Synopsys > designware part and Exynos specific part. some more queries and comments.. >>> >> . >> . >> >> . >> . > + of_pci_range_to_resource(, np, >cfg); > + pp->config.cfg0_size = resource_size(>cfg)/2; > + pp->config.cfg1_size = resource_size(>cfg)/2; > + } > + } > + > + pp->dbi_base = devm_ioremap(pp->dev, pp->cfg.start, > + resource_size(>cfg)); Why is configuraion space divided into two? >>> >>> Sorry, I don't know the exact reason. :( >>> Pratyush Anand may know about this. >>> Pratyush Anand, could you answer the question? >>> >>> Also, if you find some problems, please let me know. One more query.. Where is inbound translation configuration done in your driver? how should it be done? Thanks Kishon -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH V3] pci: exynos: split into two parts such as Synopsys part and Exynos part
Hi Jingoo, On Tuesday 23 July 2013 12:30 PM, Jingoo Han wrote: On Tuesday, July 23, 2013 3:30 PM, Kishon Vijay Abraham I wrote: On Tuesday 23 July 2013 06:44 AM, Jingoo Han wrote: On Tuesday, July 23, 2013 12:04 AM, Kishon Vijay Abraham I wrote: On Thursday 18 July 2013 10:51 AM, Jingoo Han wrote: Exynos PCIe IP consists of Synopsys specific part and Exynos specific part. Only core block is a Synopsys designware part; other parts are Exynos specific. Also, the Synopsys designware part can be shared with other platforms; thus, it can be split two parts such as Synopsys designware part and Exynos specific part. some more queries and comments.. . . snip . . + of_pci_range_to_resource(range, np, pp-cfg); + pp-config.cfg0_size = resource_size(pp-cfg)/2; + pp-config.cfg1_size = resource_size(pp-cfg)/2; + } + } + + pp-dbi_base = devm_ioremap(pp-dev, pp-cfg.start, + resource_size(pp-cfg)); Why is configuraion space divided into two? Sorry, I don't know the exact reason. :( Pratyush Anand may know about this. Pratyush Anand, could you answer the question? Also, if you find some problems, please let me know. One more query.. Where is inbound translation configuration done in your driver? how should it be done? Thanks Kishon -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH V3] pci: exynos: split into two parts such as Synopsys part and Exynos part
On Tuesday 23 July 2013 12:30 PM, Kishon Vijay Abraham I wrote: . . + of_pci_range_to_resource(range, np, pp-cfg); + pp-config.cfg0_size = resource_size(pp-cfg)/2; + pp-config.cfg1_size = resource_size(pp-cfg)/2; + } + } + + pp-dbi_base = devm_ioremap(pp-dev, pp-cfg.start, + resource_size(pp-cfg)); Why is configuraion space divided into two? Sorry, I don't know the exact reason. :( Pratyush Anand may know about this. Pratyush Anand, could you answer the question? Also, if you find some problems, please let me know. One more query.. Where is inbound translation configuration done in your driver? how should it be done? Hi Kishon, Sorry, I cannot understand your question exactly. However, the following thread would be helpful. http://www.spinics.net/lists/arm-kernel/msg252078.html https://lkml.org/lkml/2013/6/17/890 Best regards. Jingoo Han -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH V3] pci: exynos: split into two parts such as Synopsys part and Exynos part
Hi, On Thursday 12 September 2013 03:00 PM, Pratyush Anand wrote: Hi Jingoo, On Thu, Sep 12, 2013 at 03:15:04PM +0800, Jingoo Han wrote: On Tuesday 23 July 2013 12:30 PM, Kishon Vijay Abraham I wrote: . . + of_pci_range_to_resource(range, np, pp-cfg); + pp-config.cfg0_size = resource_size(pp-cfg)/2; + pp-config.cfg1_size = resource_size(pp-cfg)/2; + } + } + + pp-dbi_base = devm_ioremap(pp-dev, pp-cfg.start, + resource_size(pp-cfg)); Why is configuraion space divided into two? Sorry, I don't know the exact reason. :( Pratyush Anand may know about this. Pratyush Anand, could you answer the question? Also, if you find some problems, please let me know. One more query.. Where is inbound translation configuration done in your driver? how should it be done? Yes, Kishon is right. Inbound translation configuration is missing in your code and I think it should be implemented. Hi Kishon, Sorry, I cannot understand your question exactly. However, the following thread would be helpful. http://www.spinics.net/lists/arm-kernel/msg252078.html https://lkml.org/lkml/2013/6/17/890 From this conversation, It seems that you have tested this driver and it works fine without inbound translation function. I am sure that you would have tested a PCIe card with DMA capability such as PCIe2USB or PCIe2Ethernet. Since it worked, it means that by default your controller is supporting one to one mapping in case of inbound transaction even when address translation is enabled. btw, I'm testing Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168B PCI Express Gigabit Ethernet controller. when I do ifconfig eth0 up, I get *r8169 :01:00.0 eth0: link up.* But I dont receive any packets and ping also fails and the tx and rx packet count is also 0. Could it be related to inbound translation? Thanks Kishon -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH V3] pci: exynos: split into two parts such as Synopsys part and Exynos part
Hi Kishon, On Thu, Sep 12, 2013 at 05:43:40PM +0800, Kishon Vijay Abraham I wrote: Hi, On Thursday 12 September 2013 03:00 PM, Pratyush Anand wrote: Hi Jingoo, On Thu, Sep 12, 2013 at 03:15:04PM +0800, Jingoo Han wrote: On Tuesday 23 July 2013 12:30 PM, Kishon Vijay Abraham I wrote: . . +of_pci_range_to_resource(range, np, pp-cfg); +pp-config.cfg0_size = resource_size(pp-cfg)/2; +pp-config.cfg1_size = resource_size(pp-cfg)/2; +} +} + +pp-dbi_base = devm_ioremap(pp-dev, pp-cfg.start, +resource_size(pp-cfg)); Why is configuraion space divided into two? Sorry, I don't know the exact reason. :( Pratyush Anand may know about this. Pratyush Anand, could you answer the question? Also, if you find some problems, please let me know. One more query.. Where is inbound translation configuration done in your driver? how should it be done? Yes, Kishon is right. Inbound translation configuration is missing in your code and I think it should be implemented. Hi Kishon, Sorry, I cannot understand your question exactly. However, the following thread would be helpful. http://www.spinics.net/lists/arm-kernel/msg252078.html https://lkml.org/lkml/2013/6/17/890 From this conversation, It seems that you have tested this driver and it works fine without inbound translation function. I am sure that you would have tested a PCIe card with DMA capability such as PCIe2USB or PCIe2Ethernet. Since it worked, it means that by default your controller is supporting one to one mapping in case of inbound transaction even when address translation is enabled. btw, I'm testing Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168B PCI Express Gigabit Ethernet controller. when I do ifconfig eth0 up, I get *r8169 :01:00.0 eth0: link up.* But I dont receive any packets and ping also fails and the tx and rx packet count is also 0. Could it be related to inbound translation? A PCIe analyser log would tell a definite cause. Most likely either inbound translation is not working or INTx/MSI is not working. Regards Pratyush Thanks Kishon -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH V3] pci: exynos: split into two parts such as Synopsys part and Exynos part
Hi Jingoo,
On Thu, Sep 12, 2013 at 03:15:04PM +0800, Jingoo Han wrote:
On Tuesday 23 July 2013 12:30 PM, Kishon Vijay Abraham I wrote:
.
.
+ of_pci_range_to_resource(range, np, pp-cfg);
+ pp-config.cfg0_size =
resource_size(pp-cfg)/2;
+ pp-config.cfg1_size =
resource_size(pp-cfg)/2;
+ }
+ }
+
+ pp-dbi_base = devm_ioremap(pp-dev, pp-cfg.start,
+ resource_size(pp-cfg));
Why is configuraion space divided into two?
Sorry, I don't know the exact reason. :(
Pratyush Anand may know about this.
Pratyush Anand, could you answer the question?
Also, if you find some problems, please let me know.
One more query..
Where is inbound translation configuration done in your driver? how should
it
be done?
Yes, Kishon is right. Inbound translation configuration is missing in
your code and I think it should be implemented.
Hi Kishon,
Sorry, I cannot understand your question exactly.
However, the following thread would be helpful.
http://www.spinics.net/lists/arm-kernel/msg252078.html
https://lkml.org/lkml/2013/6/17/890
From this conversation, It seems that you
have tested this driver and it works fine without inbound translation
function. I am sure that you would have tested a PCIe card with DMA
capability such as PCIe2USB or PCIe2Ethernet. Since it worked, it
means that by default your controller is supporting one to one mapping
in case of inbound transaction even when address translation is enabled.
In my opinion you should call a function like as follows from
dw_pcie_host_init in pcie-designware.c. It will insure one to one
mapping for any inbound request in memory range 0 to (in_mem_size -
1) for all dw implementation.
static void dw_pcie_prog_viewport_mem_inbound(struct pcie_port *pp)
{
u32 val;
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));
dw_pcie_writel_rc(pp, PCIE_ATU_TYPE_MEM, dbi_base + PCIE_ATU_CR1));
val = PCIE_ATU_ENABLE | PCIE_ATU_BAR_MODE_ENABLE;
dw_pcie_writel_rc(pp, val, dbi_base + PCIE_ATU_CR2));
dw_pcie_writel_rc(pp, 0, 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, pp-config.in_mem_size - 1, dbi_base +
PCIE_ATU_LIMIT));
dw_pcie_writel_rc(pp, 0, dbi_base + PCIE_ATU_LOWER_TARGET));
dw_pcie_writel_rc(pp, 0, dbi_base + PCIE_ATU_UPPER_TARGET));
}
Regards
Pratyush
Best regards.
Jingoo Han
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH V3] pci: exynos: split into two parts such as Synopsys part and Exynos part
Hi, On Thursday 12 September 2013 03:22 PM, Pratyush Anand wrote: Hi Kishon, On Thu, Sep 12, 2013 at 05:43:40PM +0800, Kishon Vijay Abraham I wrote: Hi, On Thursday 12 September 2013 03:00 PM, Pratyush Anand wrote: Hi Jingoo, On Thu, Sep 12, 2013 at 03:15:04PM +0800, Jingoo Han wrote: On Tuesday 23 July 2013 12:30 PM, Kishon Vijay Abraham I wrote: . . +of_pci_range_to_resource(range, np, pp-cfg); +pp-config.cfg0_size = resource_size(pp-cfg)/2; +pp-config.cfg1_size = resource_size(pp-cfg)/2; +} +} + +pp-dbi_base = devm_ioremap(pp-dev, pp-cfg.start, +resource_size(pp-cfg)); Why is configuraion space divided into two? Sorry, I don't know the exact reason. :( Pratyush Anand may know about this. Pratyush Anand, could you answer the question? Also, if you find some problems, please let me know. One more query.. Where is inbound translation configuration done in your driver? how should it be done? Yes, Kishon is right. Inbound translation configuration is missing in your code and I think it should be implemented. Hi Kishon, Sorry, I cannot understand your question exactly. However, the following thread would be helpful. http://www.spinics.net/lists/arm-kernel/msg252078.html https://lkml.org/lkml/2013/6/17/890 From this conversation, It seems that you have tested this driver and it works fine without inbound translation function. I am sure that you would have tested a PCIe card with DMA capability such as PCIe2USB or PCIe2Ethernet. Since it worked, it means that by default your controller is supporting one to one mapping in case of inbound transaction even when address translation is enabled. btw, I'm testing Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168B PCI Express Gigabit Ethernet controller. when I do ifconfig eth0 up, I get *r8169 :01:00.0 eth0: link up.* But I dont receive any packets and ping also fails and the tx and rx packet count is also 0. Could it be related to inbound translation? A PCIe analyser log would tell a definite cause. Most likely either inbound translation is not working or INTx/MSI is not working. I have enabled only legacy interrupts. Whenever I connect or disconnect ethernet cable I get link up/link down message and also the interrupt count for eth0 increases. So I'm not doubting INTx interrupts as such. btw configuring inbound translation once in dw_pcie_host_init enough is it? I mean we use the same registers for configuring outbound translation also no? So doesn't the inbound configuration gets lost? Thanks Kishon -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH V3] pci: exynos: split into two parts such as Synopsys part and Exynos part
On Thu, Sep 12, 2013 at 06:07:23PM +0800, Kishon Vijay Abraham I wrote: Hi, On Thursday 12 September 2013 03:22 PM, Pratyush Anand wrote: Hi Kishon, On Thu, Sep 12, 2013 at 05:43:40PM +0800, Kishon Vijay Abraham I wrote: Hi, On Thursday 12 September 2013 03:00 PM, Pratyush Anand wrote: Hi Jingoo, On Thu, Sep 12, 2013 at 03:15:04PM +0800, Jingoo Han wrote: On Tuesday 23 July 2013 12:30 PM, Kishon Vijay Abraham I wrote: . . [...] when I do ifconfig eth0 up, I get *r8169 :01:00.0 eth0: link up.* But I dont receive any packets and ping also fails and the tx and rx packet count is also 0. Could it be related to inbound translation? A PCIe analyser log would tell a definite cause. Most likely either inbound translation is not working or INTx/MSI is not working. I have enabled only legacy interrupts. Whenever I connect or disconnect ethernet cable I get link up/link down message and also the interrupt count for eth0 increases. So I'm not doubting INTx interrupts as such. btw configuring inbound translation once in dw_pcie_host_init enough is it? I mean we use the same registers for configuring outbound translation also no? So doesn't the inbound configuration gets lost? No, you write at the same register, but you program direction as inbound. There are different resources for each viewport in inbound and outbound direction. Regards Pratyush Thanks Kishon -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH V3] pci: exynos: split into two parts such as Synopsys part and Exynos part
On Thursday, September 12, 2013 6:44 PM, Kishon Vijay Abraham I wrote: On Thursday 12 September 2013 03:00 PM, Pratyush Anand wrote: From this conversation, It seems that you have tested this driver and it works fine without inbound translation function. I am sure that you would have tested a PCIe card with DMA capability such as PCIe2USB or PCIe2Ethernet. Since it worked, it means that by default your controller is supporting one to one mapping in case of inbound transaction even when address translation is enabled. btw, I'm testing Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168B PCI Express Gigabit Ethernet controller. when I do ifconfig eth0 up, I get *r8169 :01:00.0 eth0: link up.* But I dont receive any packets and ping also fails and the tx and rx packet count is also 0. Could it be related to inbound translation? Hi Kishon, I have tested Ethernet controller: Intel Corporation 82574L PCI Express Gigabit Ethernet controller. Without inbound translation, it works properly with both legacy interrupt mode and MSI mode. Best regards, Jingoo Han -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH V3] pci: exynos: split into two parts such as Synopsys part and Exynos part
On Thu, Sep 12, 2013 at 03:48:03PM +0530, Pratyush Anand wrote: On Thu, Sep 12, 2013 at 06:07:23PM +0800, Kishon Vijay Abraham I wrote: Hi, On Thursday 12 September 2013 03:22 PM, Pratyush Anand wrote: Hi Kishon, On Thu, Sep 12, 2013 at 05:43:40PM +0800, Kishon Vijay Abraham I wrote: Hi, On Thursday 12 September 2013 03:00 PM, Pratyush Anand wrote: Hi Jingoo, On Thu, Sep 12, 2013 at 03:15:04PM +0800, Jingoo Han wrote: On Tuesday 23 July 2013 12:30 PM, Kishon Vijay Abraham I wrote: . . [...] when I do ifconfig eth0 up, I get *r8169 :01:00.0 eth0: link up.* But I dont receive any packets and ping also fails and the tx and rx packet count is also 0. Could it be related to inbound translation? A PCIe analyser log would tell a definite cause. Most likely either inbound translation is not working or INTx/MSI is not working. I have enabled only legacy interrupts. Whenever I connect or disconnect ethernet cable I get link up/link down message and also the interrupt count for eth0 increases. So I'm not doubting INTx interrupts as such. Just a question, what is the MRRS of your RC? if it is 128, can you try with passing pci=pcie_bus_peer2peer in your bootargs. Again, analyser will help a lot in diagnosing such issues. Regards Pratyush btw configuring inbound translation once in dw_pcie_host_init enough is it? I mean we use the same registers for configuring outbound translation also no? So doesn't the inbound configuration gets lost? No, you write at the same register, but you program direction as inbound. There are different resources for each viewport in inbound and outbound direction. Regards Pratyush Thanks Kishon -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH V3] pci: exynos: split into two parts such as Synopsys part and Exynos part
On Thursday 12 September 2013 04:16 PM, Pratyush Anand wrote: On Thu, Sep 12, 2013 at 03:48:03PM +0530, Pratyush Anand wrote: On Thu, Sep 12, 2013 at 06:07:23PM +0800, Kishon Vijay Abraham I wrote: Hi, On Thursday 12 September 2013 03:22 PM, Pratyush Anand wrote: Hi Kishon, On Thu, Sep 12, 2013 at 05:43:40PM +0800, Kishon Vijay Abraham I wrote: Hi, On Thursday 12 September 2013 03:00 PM, Pratyush Anand wrote: Hi Jingoo, On Thu, Sep 12, 2013 at 03:15:04PM +0800, Jingoo Han wrote: On Tuesday 23 July 2013 12:30 PM, Kishon Vijay Abraham I wrote: . . [...] when I do ifconfig eth0 up, I get *r8169 :01:00.0 eth0: link up.* But I dont receive any packets and ping also fails and the tx and rx packet count is also 0. Could it be related to inbound translation? A PCIe analyser log would tell a definite cause. Most likely either inbound translation is not working or INTx/MSI is not working. I have enabled only legacy interrupts. Whenever I connect or disconnect ethernet cable I get link up/link down message and also the interrupt count for eth0 increases. So I'm not doubting INTx interrupts as such. Just a question, what is the MRRS of your RC? if it is 128, can you it's 512. try with passing pci=pcie_bus_peer2peer in your bootargs. Again, analyser will help a lot in diagnosing such issues. dont have a analyser here :-( Thanks Kishon -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH V3] pci: exynos: split into two parts such as Synopsys part and Exynos part
On Tuesday 23 July 2013, Jingoo Han wrote: > > > > Also I have one more query. > > In your dt binding, your pci address and cpu address is the same. But the > > pci > > address should start at 0x and end at 0x (for 32bit). > > Shouldn't > > the cpu address map to something within this range of pci address? The size is limited by the window available (e.g. 0x8000-0x8FFF), it can never be the full 4GB on a 32 bit non-LPAE system. If you only care about memory space here (in practice you want at least also config space) that means you could either have an identity map <0x8200 0 0x8000 0x8000 0 0x1fff>; or use bus address 0 <0x8200 0 0 0x8000 0 0x1fff>; but the length is always limited by the upstream bus. > Sorry, I cannot answer it exactly. > DT binding was confirmed by Arnd Bergmann. > He will answer it exactly. Normally you want the pci and cpu addresses to be the same, i.e. identity mapped. This simplifies PCI bus master DMA as it ensures that there is no aliasing between PCI memory space and RAM addresses visible to the host. If you know that there is never any RAM at CPU address 0, you can also make the PCI memory space be mapped from bus address 0, which has the advantage of allowing access to low PCI addresses, e.g. for legacy VGA output using the 0xa-0xb range, but it's less common. In particular on x86 there is always an identity mapping. The driver should be able to handle any mapping that can be described by the binding and is physically possible to be programmed into the translation windows. Arnd -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH V3] pci: exynos: split into two parts such as Synopsys part and Exynos part
On Tuesday 23 July 2013, Jingoo Han wrote: Also I have one more query. In your dt binding, your pci address and cpu address is the same. But the pci address should start at 0x and end at 0x (for 32bit). Shouldn't the cpu address map to something within this range of pci address? The size is limited by the window available (e.g. 0x8000-0x8FFF), it can never be the full 4GB on a 32 bit non-LPAE system. If you only care about memory space here (in practice you want at least also config space) that means you could either have an identity map 0x8200 0 0x8000 0x8000 0 0x1fff; or use bus address 0 0x8200 0 0 0x8000 0 0x1fff; but the length is always limited by the upstream bus. Sorry, I cannot answer it exactly. DT binding was confirmed by Arnd Bergmann. He will answer it exactly. Normally you want the pci and cpu addresses to be the same, i.e. identity mapped. This simplifies PCI bus master DMA as it ensures that there is no aliasing between PCI memory space and RAM addresses visible to the host. If you know that there is never any RAM at CPU address 0, you can also make the PCI memory space be mapped from bus address 0, which has the advantage of allowing access to low PCI addresses, e.g. for legacy VGA output using the 0xa-0xb range, but it's less common. In particular on x86 there is always an identity mapping. The driver should be able to handle any mapping that can be described by the binding and is physically possible to be programmed into the translation windows. Arnd -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH V3] pci: exynos: split into two parts such as Synopsys part and Exynos part
On Tuesday, July 23, 2013 3:30 PM, Kishon Vijay Abraham I wrote:
> On Tuesday 23 July 2013 06:44 AM, Jingoo Han wrote:
> > On Tuesday, July 23, 2013 12:04 AM, Kishon Vijay Abraham I wrote:
> >> On Thursday 18 July 2013 10:51 AM, Jingoo Han wrote:
> >>> Exynos PCIe IP consists of Synopsys specific part and Exynos
> >>> specific part. Only core block is a Synopsys designware part;
> >>> other parts are Exynos specific.
> >>> Also, the Synopsys designware part can be shared with other
> >>> platforms; thus, it can be split two parts such as Synopsys
> >>> designware part and Exynos specific part.
> >>
> >> some more queries and comments..
> >
> .
> .
>
> .
> .
> >>> + of_pci_range_to_resource(, np, >cfg);
> >>> + pp->config.cfg0_size = resource_size(>cfg)/2;
> >>> + pp->config.cfg1_size = resource_size(>cfg)/2;
> >>> + }
> >>> + }
> >>> +
> >>> + pp->dbi_base = devm_ioremap(pp->dev, pp->cfg.start,
> >>> + resource_size(>cfg));
[.]
> >
> >> Why should it be same as dbi_base?
> >> AFAIK, jacinto6 has a dedicated configuration/io/memory space that is
> >> entirely
> >> different from dbi_base.
> >
> > According to the Synopsys designware PCIe datasheet,
> > in chapter 5.1.1 Register Space Layout,
> > 'Port Logic Registers' are placed between (config space 0x0 + 0x700)
> > and (config space 0x0 + 0xFFF).
> > 'dbi_base' is used for reading/writing 'Port Logic Registers'.
> > Exynos are using 'dbi_base' like this. Thus, the base addresses of
> > both 'dbi_base' and configuration/io/memory space are same.
> >
> > Just now, I looked at Spear PCIe driver.
> > However, in the case of Spear, the base address of configuration/io/memory
> > space is defined as 0x8000. The base address of 'Port Logic Registers'
> > is defined as 0xb100.
> > I think that the situation of 'jacinto6' is similar with Spear, right?
> >
> > Then, I will move pp->dbi_base mapping code from pcie-designware.c
> > to pci-exynos.c.
>
> I think you need not move this to exynos (since registers in dbi_base is
> common
> for all platforms) but modify the pcie-designware.c to use different address
> space for dbi_base. In your case, you'll duplicate the address space for
> dbi_base and configuration space.
>
I will map 'pp->dbi_base' as below:
Also, I referenced SPEAr PCIe patches made by Pratyush Anand.
(http://permalink.gmane.org/gmane.linux.kernel.pci/18400)
(http://permalink.gmane.org/gmane.linux.kernel.pci/18403)
1. The different addresses between dbi_base and configuration space
: SPEAr PCIe, OMAP PCIe
'pp->dbi_base' value is come from DT binding, then, 'pp->dbi_base' will
be mapped in spear_pcie_probe() in pci-spear.c
(arch/arm/boot/dts/spear13xx.dtsi)
pcie0@b100 {
reg = <0xb100 0x2000 <-- dbi register
0xb1002000 0x7fdfff <-- elbi register
(drivers/pci/host/pci-spear.c)
static int __init spear_pcie_probe(struct platform_device *pdev)
{
struct resource *dbi_base;
struct resource *elbi_base;
dbi_base = platform_get_resource(pdev, IORESOURCE_MEM, 0);
pp->dbi_base = devm_ioremap_resource(>dev, dbi_base);
elbi_base = platform_get_resource(pdev, IORESOURCE_MEM, 1);
spear_pcie->elbi_base = devm_ioremap_resource(>dev, elbi_base);
2. The same addresses between dbi_base and configuration space
: Exynos PCIe
'pp->dbi_base' will be mapped in dw_pcie_host_init() of pcie-designware.c.
(drivers/pci/host/pcie-exynos.c)
static int __init exynos_pcie_probe(struct platform_device *pdev)
{
struct resource *elbi_base;
elbi_base = platform_get_resource(pdev, IORESOURCE_MEM, 0);
exynos_pcie->elbi_base = devm_ioremap_resource(>dev, elbi_base);
(drivers/pci/host/pcie-designware.c)
int dw_pcie_host_init(struct pcie_port *pp)
{
if (!pp->dbi_base) {
pp->dbi_base = devm_ioremap(pp->dev, pp->cfg.start,
resource_size(>cfg));
if (!pp->dbi_base) {
dev_err(pp->dev, "error with ioremap\n");
return -ENOMEM;
}
}
Best regards,
Jingoo Han
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH V3] pci: exynos: split into two parts such as Synopsys part and Exynos part
On Tuesday, July 23, 2013 3:30 PM, Kishon Vijay Abraham I wrote: > On Tuesday 23 July 2013 06:44 AM, Jingoo Han wrote: > > On Tuesday, July 23, 2013 12:04 AM, Kishon Vijay Abraham I wrote: > >> On Thursday 18 July 2013 10:51 AM, Jingoo Han wrote: > >>> Exynos PCIe IP consists of Synopsys specific part and Exynos > >>> specific part. Only core block is a Synopsys designware part; > >>> other parts are Exynos specific. > >>> Also, the Synopsys designware part can be shared with other > >>> platforms; thus, it can be split two parts such as Synopsys > >>> designware part and Exynos specific part. > >> > >> some more queries and comments.. > > > . > . > > . > . > >>> + of_pci_range_to_resource(, np, >cfg); > >>> + pp->config.cfg0_size = resource_size(>cfg)/2; > >>> + pp->config.cfg1_size = resource_size(>cfg)/2; > >>> + } > >>> + } > >>> + > >>> + pp->dbi_base = devm_ioremap(pp->dev, pp->cfg.start, > >>> + resource_size(>cfg)); > >> > >> Why is configuraion space divided into two? > > > > Sorry, I don't know the exact reason. :( > > Pratyush Anand may know about this. > > Pratyush Anand, could you answer the question? > > > > Also, if you find some problems, please let me know. > > > > > >> Why should it be same as dbi_base? > >> AFAIK, jacinto6 has a dedicated configuration/io/memory space that is > >> entirely > >> different from dbi_base. > > > > According to the Synopsys designware PCIe datasheet, > > in chapter 5.1.1 Register Space Layout, > > 'Port Logic Registers' are placed between (config space 0x0 + 0x700) > > and (config space 0x0 + 0xFFF). > > 'dbi_base' is used for reading/writing 'Port Logic Registers'. > > Exynos are using 'dbi_base' like this. Thus, the base addresses of > > both 'dbi_base' and configuration/io/memory space are same. > > > > Just now, I looked at Spear PCIe driver. > > However, in the case of Spear, the base address of configuration/io/memory > > space is defined as 0x8000. The base address of 'Port Logic Registers' > > is defined as 0xb100. > > I think that the situation of 'jacinto6' is similar with Spear, right? > > > > Then, I will move pp->dbi_base mapping code from pcie-designware.c > > to pci-exynos.c. > > I think you need not move this to exynos (since registers in dbi_base is > common > for all platforms) but modify the pcie-designware.c to use different address > space for dbi_base. In your case, you'll duplicate the address space for > dbi_base and configuration space. I cannot understand fully what you said. Please, give a pseudo code. > > Also I have one more query. > In your dt binding, your pci address and cpu address is the same. But the pci > address should start at 0x and end at 0x (for 32bit). > Shouldn't > the cpu address map to something within this range of pci address? > Sorry, I cannot answer it exactly. DT binding was confirmed by Arnd Bergmann. He will answer it exactly. Best regards, Jingoo Han -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH V3] pci: exynos: split into two parts such as Synopsys part and Exynos part
Hi, On Tuesday 23 July 2013 06:44 AM, Jingoo Han wrote: > On Tuesday, July 23, 2013 12:04 AM, Kishon Vijay Abraham I wrote: >> On Thursday 18 July 2013 10:51 AM, Jingoo Han wrote: >>> Exynos PCIe IP consists of Synopsys specific part and Exynos >>> specific part. Only core block is a Synopsys designware part; >>> other parts are Exynos specific. >>> Also, the Synopsys designware part can be shared with other >>> platforms; thus, it can be split two parts such as Synopsys >>> designware part and Exynos specific part. >> >> some more queries and comments.. > . . . . >>> + of_pci_range_to_resource(, np, >cfg); >>> + pp->config.cfg0_size = resource_size(>cfg)/2; >>> + pp->config.cfg1_size = resource_size(>cfg)/2; >>> + } >>> + } >>> + >>> + pp->dbi_base = devm_ioremap(pp->dev, pp->cfg.start, >>> + resource_size(>cfg)); >> >> Why is configuraion space divided into two? > > Sorry, I don't know the exact reason. :( > Pratyush Anand may know about this. > Pratyush Anand, could you answer the question? > > Also, if you find some problems, please let me know. > > >> Why should it be same as dbi_base? >> AFAIK, jacinto6 has a dedicated configuration/io/memory space that is >> entirely >> different from dbi_base. > > According to the Synopsys designware PCIe datasheet, > in chapter 5.1.1 Register Space Layout, > 'Port Logic Registers' are placed between (config space 0x0 + 0x700) > and (config space 0x0 + 0xFFF). > 'dbi_base' is used for reading/writing 'Port Logic Registers'. > Exynos are using 'dbi_base' like this. Thus, the base addresses of > both 'dbi_base' and configuration/io/memory space are same. > > Just now, I looked at Spear PCIe driver. > However, in the case of Spear, the base address of configuration/io/memory > space is defined as 0x8000. The base address of 'Port Logic Registers' > is defined as 0xb100. > I think that the situation of 'jacinto6' is similar with Spear, right? > > Then, I will move pp->dbi_base mapping code from pcie-designware.c > to pci-exynos.c. I think you need not move this to exynos (since registers in dbi_base is common for all platforms) but modify the pcie-designware.c to use different address space for dbi_base. In your case, you'll duplicate the address space for dbi_base and configuration space. Also I have one more query. In your dt binding, your pci address and cpu address is the same. But the pci address should start at 0x and end at 0x (for 32bit). Shouldn't the cpu address map to something within this range of pci address? Thanks Kishon -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH V3] pci: exynos: split into two parts such as Synopsys part and Exynos part
Hi, On Tuesday 23 July 2013 06:44 AM, Jingoo Han wrote: On Tuesday, July 23, 2013 12:04 AM, Kishon Vijay Abraham I wrote: On Thursday 18 July 2013 10:51 AM, Jingoo Han wrote: Exynos PCIe IP consists of Synopsys specific part and Exynos specific part. Only core block is a Synopsys designware part; other parts are Exynos specific. Also, the Synopsys designware part can be shared with other platforms; thus, it can be split two parts such as Synopsys designware part and Exynos specific part. some more queries and comments.. . . snip . . + of_pci_range_to_resource(range, np, pp-cfg); + pp-config.cfg0_size = resource_size(pp-cfg)/2; + pp-config.cfg1_size = resource_size(pp-cfg)/2; + } + } + + pp-dbi_base = devm_ioremap(pp-dev, pp-cfg.start, + resource_size(pp-cfg)); Why is configuraion space divided into two? Sorry, I don't know the exact reason. :( Pratyush Anand may know about this. Pratyush Anand, could you answer the question? Also, if you find some problems, please let me know. Why should it be same as dbi_base? AFAIK, jacinto6 has a dedicated configuration/io/memory space that is entirely different from dbi_base. According to the Synopsys designware PCIe datasheet, in chapter 5.1.1 Register Space Layout, 'Port Logic Registers' are placed between (config space 0x0 + 0x700) and (config space 0x0 + 0xFFF). 'dbi_base' is used for reading/writing 'Port Logic Registers'. Exynos are using 'dbi_base' like this. Thus, the base addresses of both 'dbi_base' and configuration/io/memory space are same. Just now, I looked at Spear PCIe driver. However, in the case of Spear, the base address of configuration/io/memory space is defined as 0x8000. The base address of 'Port Logic Registers' is defined as 0xb100. I think that the situation of 'jacinto6' is similar with Spear, right? Then, I will move pp-dbi_base mapping code from pcie-designware.c to pci-exynos.c. I think you need not move this to exynos (since registers in dbi_base is common for all platforms) but modify the pcie-designware.c to use different address space for dbi_base. In your case, you'll duplicate the address space for dbi_base and configuration space. Also I have one more query. In your dt binding, your pci address and cpu address is the same. But the pci address should start at 0x and end at 0x (for 32bit). Shouldn't the cpu address map to something within this range of pci address? Thanks Kishon -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH V3] pci: exynos: split into two parts such as Synopsys part and Exynos part
On Tuesday, July 23, 2013 3:30 PM, Kishon Vijay Abraham I wrote: On Tuesday 23 July 2013 06:44 AM, Jingoo Han wrote: On Tuesday, July 23, 2013 12:04 AM, Kishon Vijay Abraham I wrote: On Thursday 18 July 2013 10:51 AM, Jingoo Han wrote: Exynos PCIe IP consists of Synopsys specific part and Exynos specific part. Only core block is a Synopsys designware part; other parts are Exynos specific. Also, the Synopsys designware part can be shared with other platforms; thus, it can be split two parts such as Synopsys designware part and Exynos specific part. some more queries and comments.. . . snip . . + of_pci_range_to_resource(range, np, pp-cfg); + pp-config.cfg0_size = resource_size(pp-cfg)/2; + pp-config.cfg1_size = resource_size(pp-cfg)/2; + } + } + + pp-dbi_base = devm_ioremap(pp-dev, pp-cfg.start, + resource_size(pp-cfg)); Why is configuraion space divided into two? Sorry, I don't know the exact reason. :( Pratyush Anand may know about this. Pratyush Anand, could you answer the question? Also, if you find some problems, please let me know. Why should it be same as dbi_base? AFAIK, jacinto6 has a dedicated configuration/io/memory space that is entirely different from dbi_base. According to the Synopsys designware PCIe datasheet, in chapter 5.1.1 Register Space Layout, 'Port Logic Registers' are placed between (config space 0x0 + 0x700) and (config space 0x0 + 0xFFF). 'dbi_base' is used for reading/writing 'Port Logic Registers'. Exynos are using 'dbi_base' like this. Thus, the base addresses of both 'dbi_base' and configuration/io/memory space are same. Just now, I looked at Spear PCIe driver. However, in the case of Spear, the base address of configuration/io/memory space is defined as 0x8000. The base address of 'Port Logic Registers' is defined as 0xb100. I think that the situation of 'jacinto6' is similar with Spear, right? Then, I will move pp-dbi_base mapping code from pcie-designware.c to pci-exynos.c. I think you need not move this to exynos (since registers in dbi_base is common for all platforms) but modify the pcie-designware.c to use different address space for dbi_base. In your case, you'll duplicate the address space for dbi_base and configuration space. I cannot understand fully what you said. Please, give a pseudo code. Also I have one more query. In your dt binding, your pci address and cpu address is the same. But the pci address should start at 0x and end at 0x (for 32bit). Shouldn't the cpu address map to something within this range of pci address? Sorry, I cannot answer it exactly. DT binding was confirmed by Arnd Bergmann. He will answer it exactly. Best regards, Jingoo Han -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH V3] pci: exynos: split into two parts such as Synopsys part and Exynos part
On Tuesday, July 23, 2013 3:30 PM, Kishon Vijay Abraham I wrote:
On Tuesday 23 July 2013 06:44 AM, Jingoo Han wrote:
On Tuesday, July 23, 2013 12:04 AM, Kishon Vijay Abraham I wrote:
On Thursday 18 July 2013 10:51 AM, Jingoo Han wrote:
Exynos PCIe IP consists of Synopsys specific part and Exynos
specific part. Only core block is a Synopsys designware part;
other parts are Exynos specific.
Also, the Synopsys designware part can be shared with other
platforms; thus, it can be split two parts such as Synopsys
designware part and Exynos specific part.
some more queries and comments..
.
.
snip
.
.
+ of_pci_range_to_resource(range, np, pp-cfg);
+ pp-config.cfg0_size = resource_size(pp-cfg)/2;
+ pp-config.cfg1_size = resource_size(pp-cfg)/2;
+ }
+ }
+
+ pp-dbi_base = devm_ioremap(pp-dev, pp-cfg.start,
+ resource_size(pp-cfg));
[.]
Why should it be same as dbi_base?
AFAIK, jacinto6 has a dedicated configuration/io/memory space that is
entirely
different from dbi_base.
According to the Synopsys designware PCIe datasheet,
in chapter 5.1.1 Register Space Layout,
'Port Logic Registers' are placed between (config space 0x0 + 0x700)
and (config space 0x0 + 0xFFF).
'dbi_base' is used for reading/writing 'Port Logic Registers'.
Exynos are using 'dbi_base' like this. Thus, the base addresses of
both 'dbi_base' and configuration/io/memory space are same.
Just now, I looked at Spear PCIe driver.
However, in the case of Spear, the base address of configuration/io/memory
space is defined as 0x8000. The base address of 'Port Logic Registers'
is defined as 0xb100.
I think that the situation of 'jacinto6' is similar with Spear, right?
Then, I will move pp-dbi_base mapping code from pcie-designware.c
to pci-exynos.c.
I think you need not move this to exynos (since registers in dbi_base is
common
for all platforms) but modify the pcie-designware.c to use different address
space for dbi_base. In your case, you'll duplicate the address space for
dbi_base and configuration space.
I will map 'pp-dbi_base' as below:
Also, I referenced SPEAr PCIe patches made by Pratyush Anand.
(http://permalink.gmane.org/gmane.linux.kernel.pci/18400)
(http://permalink.gmane.org/gmane.linux.kernel.pci/18403)
1. The different addresses between dbi_base and configuration space
: SPEAr PCIe, OMAP PCIe
'pp-dbi_base' value is come from DT binding, then, 'pp-dbi_base' will
be mapped in spear_pcie_probe() in pci-spear.c
(arch/arm/boot/dts/spear13xx.dtsi)
pcie0@b100 {
reg = 0xb100 0x2000 -- dbi register
0xb1002000 0x7fdfff -- elbi register
(drivers/pci/host/pci-spear.c)
static int __init spear_pcie_probe(struct platform_device *pdev)
{
struct resource *dbi_base;
struct resource *elbi_base;
dbi_base = platform_get_resource(pdev, IORESOURCE_MEM, 0);
pp-dbi_base = devm_ioremap_resource(pdev-dev, dbi_base);
elbi_base = platform_get_resource(pdev, IORESOURCE_MEM, 1);
spear_pcie-elbi_base = devm_ioremap_resource(pdev-dev, elbi_base);
2. The same addresses between dbi_base and configuration space
: Exynos PCIe
'pp-dbi_base' will be mapped in dw_pcie_host_init() of pcie-designware.c.
(drivers/pci/host/pcie-exynos.c)
static int __init exynos_pcie_probe(struct platform_device *pdev)
{
struct resource *elbi_base;
elbi_base = platform_get_resource(pdev, IORESOURCE_MEM, 0);
exynos_pcie-elbi_base = devm_ioremap_resource(pdev-dev, elbi_base);
(drivers/pci/host/pcie-designware.c)
int dw_pcie_host_init(struct pcie_port *pp)
{
if (!pp-dbi_base) {
pp-dbi_base = devm_ioremap(pp-dev, pp-cfg.start,
resource_size(pp-cfg));
if (!pp-dbi_base) {
dev_err(pp-dev, error with ioremap\n);
return -ENOMEM;
}
}
Best regards,
Jingoo Han
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH V3] pci: exynos: split into two parts such as Synopsys part and Exynos part
On 7/23/2013 6:44 AM, Jingoo Han wrote:
+ if (restype == IORESOURCE_MEM) {
> >+ of_pci_range_to_resource(, np, >mem);
> >+ pp->mem.name = "MEM";
> >+ pp->config.mem_size = resource_size(>mem);
> >+ pp->config.mem_bus_addr = range.pci_addr;
> >+ }
> >+ if (restype == 0) {
> >+ of_pci_range_to_resource(, np, >cfg);
> >+ pp->config.cfg0_size = resource_size(>cfg)/2;
> >+ pp->config.cfg1_size = resource_size(>cfg)/2;
> >+ }
> >+ }
> >+
> >+ pp->dbi_base = devm_ioremap(pp->dev, pp->cfg.start,
> >+ resource_size(>cfg));
>
>Why is configuraion space divided into two?
Sorry, I don't know the exact reason.:(
Pratyush Anand may know about this.
Pratyush Anand, could you answer the question?
CfgRd1 and CfgWr1 transactions are needed when an EP is not directly
connected to RC, rather connected through a bridge. For more detail see
PCIe specs.
Now, if we wish to generate a CfgRd/Wr1 transaction using SNPS
controller then we can not use same programmed viewport as that for
CfgRd/Wr0. However, a viewport can be reprogrammed using same physical
cfg address to generate either cfg0 or cfg1. So, in that case we can do
with only one cfg area and no reason to divide it into two.
Current code assumes that there are only 4 viewports available (2 in
outbound and 2 in inbound direction) and it always programs viewport
dynamically for cfg0/1 as per need. But same can not be true for all
implementations. There can be a case where hardware has sufficient
number of viewports and software does not need to reprogram it
dynamically. In that situation different physical memory area for each
type of TLP would make the execution faster.
Also, if you find some problems, please let me know.
>Why should it be same as dbi_base?
>AFAIK, jacinto6 has a dedicated configuration/io/memory space that is entirely
>different from dbi_base.
According to the Synopsys designware PCIe datasheet,
in chapter 5.1.1 Register Space Layout,
'Port Logic Registers' are placed between (config space 0x0 + 0x700)
and (config space 0x0 + 0xFFF).
'dbi_base' is used for reading/writing 'Port Logic Registers'.
Exynos are using 'dbi_base' like this. Thus, the base addresses of
both 'dbi_base' and configuration/io/memory space are same.
Yes address space are same, but at any moment they work either as dbi
space or as configuration/io/memory space depending on the dbi_enable
bit of application register. Similar functionality was there in one
older SPEAr implementation.
Just now, I looked at Spear PCIe driver.
However, in the case of Spear, the base address of configuration/io/memory
space is defined as 0x8000. The base address of 'Port Logic Registers'
is defined as 0xb100.
I think that the situation of 'jacinto6' is similar with Spear, right?
In SPEAr1340 PCIe memory layout is as follows:
DBI base (0xB100 to 0xB1001FFF): This space is used to read/write
own PCI Configuration Header, Capability and Port Logic(PL) Registers.
ELBI space (0xB1002000 to 0xB17F): These are completely SPEAr
specific application registers.
configuration/io/memory space(0x8000 to 0x8FFF): These can be
used in viewport programming to generate different type of outbound
transaction.
Regards
Pratyush
Then, I will move pp->dbi_base mapping code from pcie-designware.c
to pci-exynos.c.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH V3] pci: exynos: split into two parts such as Synopsys part and Exynos part
On Tuesday, July 23, 2013 12:04 AM, Kishon Vijay Abraham I wrote:
> On Thursday 18 July 2013 10:51 AM, Jingoo Han wrote:
> > Exynos PCIe IP consists of Synopsys specific part and Exynos
> > specific part. Only core block is a Synopsys designware part;
> > other parts are Exynos specific.
> > Also, the Synopsys designware part can be shared with other
> > platforms; thus, it can be split two parts such as Synopsys
> > designware part and Exynos specific part.
>
> some more queries and comments..
Hi Kishon,
Thank you for your comments. :)
Hi Pratyush Anand,
Please, answer one question mentioned below. :)
> >
> > Signed-off-by: Jingoo Han
> > Cc: Pratyush Anand
> > Cc: Mohit KUMAR
> > ---
> > Changes since v2:
> .
> .
>
> .
> .
> > +
> > +static struct pcie_host_ops exynos_pcie_host_ops = {
> > + .readl_rc = exynos_pcie_readl_rc,
> > + .writel_rc = exynos_pcie_writel_rc,
> > + .rd_own_conf = exynos_pcie_rd_own_conf,
> > + .wr_own_conf = exynos_pcie_wr_own_conf,
> > + .link_up = exynos_pcie_link_up,
> > + .host_init = exynos_pcie_host_init,
> > +};
> > +
> > +static int add_pcie_port(struct pcie_port *pp, struct platform_device
> > *pdev)
> > +{
> > + struct exynos_pcie *exynos_pcie = to_exynos_pcie(pp);
>
> We can move the exynos_pcie specific initialization to probe and leave only
> pcie_port initialization here.
OK, I will move the exynos_pcie specific initialization to probe
as you mentioned.
> > + struct resource *elbi_base;
> > + struct resource *phy_base;
> > + struct resource *block_base;
> > + int ret;
> > +
> > + elbi_base = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> > + if (!elbi_base) {
> > + dev_err(>dev, "couldn't get elbi base resource\n");
> > + return -EINVAL;
> > + }
> > + exynos_pcie->elbi_base = devm_ioremap_resource(>dev, elbi_base);
> > + if (IS_ERR(exynos_pcie->elbi_base))
> > + return PTR_ERR(exynos_pcie->elbi_base);
> > +
> > + phy_base = platform_get_resource(pdev, IORESOURCE_MEM, 1);
> > + if (!phy_base) {
> > + dev_err(>dev, "couldn't get phy base resource\n");
> > + return -EINVAL;
> > + }
> > + exynos_pcie->phy_base = devm_ioremap_resource(>dev, phy_base);
> > + if (IS_ERR(exynos_pcie->phy_base))
> > + return PTR_ERR(exynos_pcie->phy_base);
> > +
> > + block_base = platform_get_resource(pdev, IORESOURCE_MEM, 2);
> > + if (!block_base) {
> > + dev_err(>dev, "couldn't get block base resource\n");
> > + return -EINVAL;
> > + }
> > + exynos_pcie->block_base = devm_ioremap_resource(>dev, block_base);
> > + if (IS_ERR(exynos_pcie->block_base))
> > + return PTR_ERR(exynos_pcie->block_base);
>
> So all this till here can be moved to probe.
As above mentioned, I will move it to probe.
> > +
> > + pp->irq = platform_get_irq(pdev, 1);
> > + if (!pp->irq) {
> > + dev_err(>dev, "failed to get irq\n");
> > + return -ENODEV;
> > + }
> > + ret = devm_request_irq(>dev, pp->irq, exynos_pcie_irq_handler,
> > + IRQF_SHARED, "exynos-pcie", pp);
> > + if (ret) {
> > + dev_err(>dev, "failed to request irq\n");
> > + return ret;
> > + }
> > +
> > + pp->root_bus_nr = -1;
> > + pp->ops = _pcie_host_ops;
> > +
> > + spin_lock_init(>conf_lock);
> > + ret = dw_pcie_host_init(pp);
> > + if (ret) {
> > + dev_err(>dev, "failed to initialize host\n");
> > + return ret;
> > + }
> > +
> > + return 0;
> > +}
> > +
> > +static int __init exynos_pcie_probe(struct platform_device *pdev)
> > +{
> > + struct exynos_pcie *exynos_pcie;
> > + struct pcie_port *pp;
> > + struct device_node *np = pdev->dev.of_node;
> > + int ret;
> > +
> > + exynos_pcie = devm_kzalloc(>dev, sizeof(*exynos_pcie),
> > + GFP_KERNEL);
> > + if (!exynos_pcie) {
> > + dev_err(>dev, "no memory for exynos pcie\n");
> > + return -ENOMEM;
> > + }
> > +
> > + pp = _pcie->pp;
> > +
> > + pp->dev = >dev;
> > +
> > + exynos_pcie->reset_gpio = of_get_named_gpio(np, "reset-gpio", 0);
> > +
> > + exynos_pcie->clk = devm_clk_get(>dev, "pcie");
> > + if (IS_ERR(exynos_pcie->clk)) {
> > + dev_err(>dev, "Failed to get pcie rc clock\n");
> > + return PTR_ERR(exynos_pcie->clk);
> > + }
> > + ret = clk_prepare_enable(exynos_pcie->clk);
> > + if (ret)
> > + return ret;
> > +
> > + exynos_pcie->bus_clk = devm_clk_get(>dev, "pcie_bus");
> > + if (IS_ERR(exynos_pcie->bus_clk)) {
> > + dev_err(>dev, "Failed to get pcie bus clock\n");
> > + ret = PTR_ERR(exynos_pcie->bus_clk);
> > + goto fail_clk;
> > + }
> > + ret = clk_prepare_enable(exynos_pcie->bus_clk);
> > + if (ret)
> > + goto fail_clk;
> > +
> > + ret = add_pcie_port(pp, pdev);
> > + if (ret < 0)
> > + goto fail_bus_clk;
>
> I think we should move all the below code to
Re: [PATCH V3] pci: exynos: split into two parts such as Synopsys part and Exynos part
Hi,
On Thursday 18 July 2013 10:51 AM, Jingoo Han wrote:
> Exynos PCIe IP consists of Synopsys specific part and Exynos
> specific part. Only core block is a Synopsys designware part;
> other parts are Exynos specific.
> Also, the Synopsys designware part can be shared with other
> platforms; thus, it can be split two parts such as Synopsys
> designware part and Exynos specific part.
some more queries and comments..
>
> Signed-off-by: Jingoo Han
> Cc: Pratyush Anand
> Cc: Mohit KUMAR
> ---
> Changes since v2:
.
.
.
.
> +
> +static struct pcie_host_ops exynos_pcie_host_ops = {
> + .readl_rc = exynos_pcie_readl_rc,
> + .writel_rc = exynos_pcie_writel_rc,
> + .rd_own_conf = exynos_pcie_rd_own_conf,
> + .wr_own_conf = exynos_pcie_wr_own_conf,
> + .link_up = exynos_pcie_link_up,
> + .host_init = exynos_pcie_host_init,
> +};
> +
> +static int add_pcie_port(struct pcie_port *pp, struct platform_device *pdev)
> +{
> + struct exynos_pcie *exynos_pcie = to_exynos_pcie(pp);
We can move the exynos_pcie specific initialization to probe and leave only
pcie_port initialization here.
> + struct resource *elbi_base;
> + struct resource *phy_base;
> + struct resource *block_base;
> + int ret;
> +
> + elbi_base = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> + if (!elbi_base) {
> + dev_err(>dev, "couldn't get elbi base resource\n");
> + return -EINVAL;
> + }
> + exynos_pcie->elbi_base = devm_ioremap_resource(>dev, elbi_base);
> + if (IS_ERR(exynos_pcie->elbi_base))
> + return PTR_ERR(exynos_pcie->elbi_base);
> +
> + phy_base = platform_get_resource(pdev, IORESOURCE_MEM, 1);
> + if (!phy_base) {
> + dev_err(>dev, "couldn't get phy base resource\n");
> + return -EINVAL;
> + }
> + exynos_pcie->phy_base = devm_ioremap_resource(>dev, phy_base);
> + if (IS_ERR(exynos_pcie->phy_base))
> + return PTR_ERR(exynos_pcie->phy_base);
> +
> + block_base = platform_get_resource(pdev, IORESOURCE_MEM, 2);
> + if (!block_base) {
> + dev_err(>dev, "couldn't get block base resource\n");
> + return -EINVAL;
> + }
> + exynos_pcie->block_base = devm_ioremap_resource(>dev, block_base);
> + if (IS_ERR(exynos_pcie->block_base))
> + return PTR_ERR(exynos_pcie->block_base);
So all this till here can be moved to probe.
> +
> + pp->irq = platform_get_irq(pdev, 1);
> + if (!pp->irq) {
> + dev_err(>dev, "failed to get irq\n");
> + return -ENODEV;
> + }
> + ret = devm_request_irq(>dev, pp->irq, exynos_pcie_irq_handler,
> + IRQF_SHARED, "exynos-pcie", pp);
> + if (ret) {
> + dev_err(>dev, "failed to request irq\n");
> + return ret;
> + }
> +
> + pp->root_bus_nr = -1;
> + pp->ops = _pcie_host_ops;
> +
> + spin_lock_init(>conf_lock);
> + ret = dw_pcie_host_init(pp);
> + if (ret) {
> + dev_err(>dev, "failed to initialize host\n");
> + return ret;
> + }
> +
> + return 0;
> +}
> +
> +static int __init exynos_pcie_probe(struct platform_device *pdev)
> +{
> + struct exynos_pcie *exynos_pcie;
> + struct pcie_port *pp;
> + struct device_node *np = pdev->dev.of_node;
> + int ret;
> +
> + exynos_pcie = devm_kzalloc(>dev, sizeof(*exynos_pcie),
> + GFP_KERNEL);
> + if (!exynos_pcie) {
> + dev_err(>dev, "no memory for exynos pcie\n");
> + return -ENOMEM;
> + }
> +
> + pp = _pcie->pp;
> +
> + pp->dev = >dev;
> +
> + exynos_pcie->reset_gpio = of_get_named_gpio(np, "reset-gpio", 0);
> +
> + exynos_pcie->clk = devm_clk_get(>dev, "pcie");
> + if (IS_ERR(exynos_pcie->clk)) {
> + dev_err(>dev, "Failed to get pcie rc clock\n");
> + return PTR_ERR(exynos_pcie->clk);
> + }
> + ret = clk_prepare_enable(exynos_pcie->clk);
> + if (ret)
> + return ret;
> +
> + exynos_pcie->bus_clk = devm_clk_get(>dev, "pcie_bus");
> + if (IS_ERR(exynos_pcie->bus_clk)) {
> + dev_err(>dev, "Failed to get pcie bus clock\n");
> + ret = PTR_ERR(exynos_pcie->bus_clk);
> + goto fail_clk;
> + }
> + ret = clk_prepare_enable(exynos_pcie->bus_clk);
> + if (ret)
> + goto fail_clk;
> +
> + ret = add_pcie_port(pp, pdev);
> + if (ret < 0)
> + goto fail_bus_clk;
I think we should move all the below code to designware core file. IMO it
should be common everyone who use designware core.
> +
> + dw_pci.nr_controllers = 1;
> + dw_pci.private_data = (void **)
> +
> + pci_common_init(_pci);
> + pci_assign_unassigned_resources();
> +#ifdef CONFIG_PCI_DOMAINS
> + dw_pci.domain++;
> +#endif
> +
> + platform_set_drvdata(pdev, exynos_pcie);
> + return 0;
> +
> +fail_bus_clk:
> +
Re: [PATCH V3] pci: exynos: split into two parts such as Synopsys part and Exynos part
Hi,
On Thursday 18 July 2013 10:51 AM, Jingoo Han wrote:
Exynos PCIe IP consists of Synopsys specific part and Exynos
specific part. Only core block is a Synopsys designware part;
other parts are Exynos specific.
Also, the Synopsys designware part can be shared with other
platforms; thus, it can be split two parts such as Synopsys
designware part and Exynos specific part.
some more queries and comments..
Signed-off-by: Jingoo Han jg1@samsung.com
Cc: Pratyush Anand pratyush.an...@st.com
Cc: Mohit KUMAR mohit.ku...@st.com
---
Changes since v2:
.
.
snip
.
.
+
+static struct pcie_host_ops exynos_pcie_host_ops = {
+ .readl_rc = exynos_pcie_readl_rc,
+ .writel_rc = exynos_pcie_writel_rc,
+ .rd_own_conf = exynos_pcie_rd_own_conf,
+ .wr_own_conf = exynos_pcie_wr_own_conf,
+ .link_up = exynos_pcie_link_up,
+ .host_init = exynos_pcie_host_init,
+};
+
+static int add_pcie_port(struct pcie_port *pp, struct platform_device *pdev)
+{
+ struct exynos_pcie *exynos_pcie = to_exynos_pcie(pp);
We can move the exynos_pcie specific initialization to probe and leave only
pcie_port initialization here.
+ struct resource *elbi_base;
+ struct resource *phy_base;
+ struct resource *block_base;
+ int ret;
+
+ elbi_base = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+ if (!elbi_base) {
+ dev_err(pdev-dev, couldn't get elbi base resource\n);
+ return -EINVAL;
+ }
+ exynos_pcie-elbi_base = devm_ioremap_resource(pdev-dev, elbi_base);
+ if (IS_ERR(exynos_pcie-elbi_base))
+ return PTR_ERR(exynos_pcie-elbi_base);
+
+ phy_base = platform_get_resource(pdev, IORESOURCE_MEM, 1);
+ if (!phy_base) {
+ dev_err(pdev-dev, couldn't get phy base resource\n);
+ return -EINVAL;
+ }
+ exynos_pcie-phy_base = devm_ioremap_resource(pdev-dev, phy_base);
+ if (IS_ERR(exynos_pcie-phy_base))
+ return PTR_ERR(exynos_pcie-phy_base);
+
+ block_base = platform_get_resource(pdev, IORESOURCE_MEM, 2);
+ if (!block_base) {
+ dev_err(pdev-dev, couldn't get block base resource\n);
+ return -EINVAL;
+ }
+ exynos_pcie-block_base = devm_ioremap_resource(pdev-dev, block_base);
+ if (IS_ERR(exynos_pcie-block_base))
+ return PTR_ERR(exynos_pcie-block_base);
So all this till here can be moved to probe.
+
+ pp-irq = platform_get_irq(pdev, 1);
+ if (!pp-irq) {
+ dev_err(pdev-dev, failed to get irq\n);
+ return -ENODEV;
+ }
+ ret = devm_request_irq(pdev-dev, pp-irq, exynos_pcie_irq_handler,
+ IRQF_SHARED, exynos-pcie, pp);
+ if (ret) {
+ dev_err(pdev-dev, failed to request irq\n);
+ return ret;
+ }
+
+ pp-root_bus_nr = -1;
+ pp-ops = exynos_pcie_host_ops;
+
+ spin_lock_init(pp-conf_lock);
+ ret = dw_pcie_host_init(pp);
+ if (ret) {
+ dev_err(pdev-dev, failed to initialize host\n);
+ return ret;
+ }
+
+ return 0;
+}
+
+static int __init exynos_pcie_probe(struct platform_device *pdev)
+{
+ struct exynos_pcie *exynos_pcie;
+ struct pcie_port *pp;
+ struct device_node *np = pdev-dev.of_node;
+ int ret;
+
+ exynos_pcie = devm_kzalloc(pdev-dev, sizeof(*exynos_pcie),
+ GFP_KERNEL);
+ if (!exynos_pcie) {
+ dev_err(pdev-dev, no memory for exynos pcie\n);
+ return -ENOMEM;
+ }
+
+ pp = exynos_pcie-pp;
+
+ pp-dev = pdev-dev;
+
+ exynos_pcie-reset_gpio = of_get_named_gpio(np, reset-gpio, 0);
+
+ exynos_pcie-clk = devm_clk_get(pdev-dev, pcie);
+ if (IS_ERR(exynos_pcie-clk)) {
+ dev_err(pdev-dev, Failed to get pcie rc clock\n);
+ return PTR_ERR(exynos_pcie-clk);
+ }
+ ret = clk_prepare_enable(exynos_pcie-clk);
+ if (ret)
+ return ret;
+
+ exynos_pcie-bus_clk = devm_clk_get(pdev-dev, pcie_bus);
+ if (IS_ERR(exynos_pcie-bus_clk)) {
+ dev_err(pdev-dev, Failed to get pcie bus clock\n);
+ ret = PTR_ERR(exynos_pcie-bus_clk);
+ goto fail_clk;
+ }
+ ret = clk_prepare_enable(exynos_pcie-bus_clk);
+ if (ret)
+ goto fail_clk;
+
+ ret = add_pcie_port(pp, pdev);
+ if (ret 0)
+ goto fail_bus_clk;
I think we should move all the below code to designware core file. IMO it
should be common everyone who use designware core.
+
+ dw_pci.nr_controllers = 1;
+ dw_pci.private_data = (void **)pp;
+
+ pci_common_init(dw_pci);
+ pci_assign_unassigned_resources();
+#ifdef CONFIG_PCI_DOMAINS
+ dw_pci.domain++;
+#endif
+
+ platform_set_drvdata(pdev, exynos_pcie);
+ return 0;
+
+fail_bus_clk:
+ clk_disable_unprepare(exynos_pcie-bus_clk);
+fail_clk:
+
Re: [PATCH V3] pci: exynos: split into two parts such as Synopsys part and Exynos part
On Tuesday, July 23, 2013 12:04 AM, Kishon Vijay Abraham I wrote:
On Thursday 18 July 2013 10:51 AM, Jingoo Han wrote:
Exynos PCIe IP consists of Synopsys specific part and Exynos
specific part. Only core block is a Synopsys designware part;
other parts are Exynos specific.
Also, the Synopsys designware part can be shared with other
platforms; thus, it can be split two parts such as Synopsys
designware part and Exynos specific part.
some more queries and comments..
Hi Kishon,
Thank you for your comments. :)
Hi Pratyush Anand,
Please, answer one question mentioned below. :)
Signed-off-by: Jingoo Han jg1@samsung.com
Cc: Pratyush Anand pratyush.an...@st.com
Cc: Mohit KUMAR mohit.ku...@st.com
---
Changes since v2:
.
.
snip
.
.
+
+static struct pcie_host_ops exynos_pcie_host_ops = {
+ .readl_rc = exynos_pcie_readl_rc,
+ .writel_rc = exynos_pcie_writel_rc,
+ .rd_own_conf = exynos_pcie_rd_own_conf,
+ .wr_own_conf = exynos_pcie_wr_own_conf,
+ .link_up = exynos_pcie_link_up,
+ .host_init = exynos_pcie_host_init,
+};
+
+static int add_pcie_port(struct pcie_port *pp, struct platform_device
*pdev)
+{
+ struct exynos_pcie *exynos_pcie = to_exynos_pcie(pp);
We can move the exynos_pcie specific initialization to probe and leave only
pcie_port initialization here.
OK, I will move the exynos_pcie specific initialization to probe
as you mentioned.
+ struct resource *elbi_base;
+ struct resource *phy_base;
+ struct resource *block_base;
+ int ret;
+
+ elbi_base = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+ if (!elbi_base) {
+ dev_err(pdev-dev, couldn't get elbi base resource\n);
+ return -EINVAL;
+ }
+ exynos_pcie-elbi_base = devm_ioremap_resource(pdev-dev, elbi_base);
+ if (IS_ERR(exynos_pcie-elbi_base))
+ return PTR_ERR(exynos_pcie-elbi_base);
+
+ phy_base = platform_get_resource(pdev, IORESOURCE_MEM, 1);
+ if (!phy_base) {
+ dev_err(pdev-dev, couldn't get phy base resource\n);
+ return -EINVAL;
+ }
+ exynos_pcie-phy_base = devm_ioremap_resource(pdev-dev, phy_base);
+ if (IS_ERR(exynos_pcie-phy_base))
+ return PTR_ERR(exynos_pcie-phy_base);
+
+ block_base = platform_get_resource(pdev, IORESOURCE_MEM, 2);
+ if (!block_base) {
+ dev_err(pdev-dev, couldn't get block base resource\n);
+ return -EINVAL;
+ }
+ exynos_pcie-block_base = devm_ioremap_resource(pdev-dev, block_base);
+ if (IS_ERR(exynos_pcie-block_base))
+ return PTR_ERR(exynos_pcie-block_base);
So all this till here can be moved to probe.
As above mentioned, I will move it to probe.
+
+ pp-irq = platform_get_irq(pdev, 1);
+ if (!pp-irq) {
+ dev_err(pdev-dev, failed to get irq\n);
+ return -ENODEV;
+ }
+ ret = devm_request_irq(pdev-dev, pp-irq, exynos_pcie_irq_handler,
+ IRQF_SHARED, exynos-pcie, pp);
+ if (ret) {
+ dev_err(pdev-dev, failed to request irq\n);
+ return ret;
+ }
+
+ pp-root_bus_nr = -1;
+ pp-ops = exynos_pcie_host_ops;
+
+ spin_lock_init(pp-conf_lock);
+ ret = dw_pcie_host_init(pp);
+ if (ret) {
+ dev_err(pdev-dev, failed to initialize host\n);
+ return ret;
+ }
+
+ return 0;
+}
+
+static int __init exynos_pcie_probe(struct platform_device *pdev)
+{
+ struct exynos_pcie *exynos_pcie;
+ struct pcie_port *pp;
+ struct device_node *np = pdev-dev.of_node;
+ int ret;
+
+ exynos_pcie = devm_kzalloc(pdev-dev, sizeof(*exynos_pcie),
+ GFP_KERNEL);
+ if (!exynos_pcie) {
+ dev_err(pdev-dev, no memory for exynos pcie\n);
+ return -ENOMEM;
+ }
+
+ pp = exynos_pcie-pp;
+
+ pp-dev = pdev-dev;
+
+ exynos_pcie-reset_gpio = of_get_named_gpio(np, reset-gpio, 0);
+
+ exynos_pcie-clk = devm_clk_get(pdev-dev, pcie);
+ if (IS_ERR(exynos_pcie-clk)) {
+ dev_err(pdev-dev, Failed to get pcie rc clock\n);
+ return PTR_ERR(exynos_pcie-clk);
+ }
+ ret = clk_prepare_enable(exynos_pcie-clk);
+ if (ret)
+ return ret;
+
+ exynos_pcie-bus_clk = devm_clk_get(pdev-dev, pcie_bus);
+ if (IS_ERR(exynos_pcie-bus_clk)) {
+ dev_err(pdev-dev, Failed to get pcie bus clock\n);
+ ret = PTR_ERR(exynos_pcie-bus_clk);
+ goto fail_clk;
+ }
+ ret = clk_prepare_enable(exynos_pcie-bus_clk);
+ if (ret)
+ goto fail_clk;
+
+ ret = add_pcie_port(pp, pdev);
+ if (ret 0)
+ goto fail_bus_clk;
I think we should move all the below code to designware core file. IMO it
should be common everyone who use designware core.
OK, I will move the below code to dw_pcie_host_init() in pcie-designware.c
+
+
Re: [PATCH V3] pci: exynos: split into two parts such as Synopsys part and Exynos part
On 7/23/2013 6:44 AM, Jingoo Han wrote:
+ if (restype == IORESOURCE_MEM) {
+ of_pci_range_to_resource(range, np, pp-mem);
+ pp-mem.name = MEM;
+ pp-config.mem_size = resource_size(pp-mem);
+ pp-config.mem_bus_addr = range.pci_addr;
+ }
+ if (restype == 0) {
+ of_pci_range_to_resource(range, np, pp-cfg);
+ pp-config.cfg0_size = resource_size(pp-cfg)/2;
+ pp-config.cfg1_size = resource_size(pp-cfg)/2;
+ }
+ }
+
+ pp-dbi_base = devm_ioremap(pp-dev, pp-cfg.start,
+ resource_size(pp-cfg));
Why is configuraion space divided into two?
Sorry, I don't know the exact reason.:(
Pratyush Anand may know about this.
Pratyush Anand, could you answer the question?
CfgRd1 and CfgWr1 transactions are needed when an EP is not directly
connected to RC, rather connected through a bridge. For more detail see
PCIe specs.
Now, if we wish to generate a CfgRd/Wr1 transaction using SNPS
controller then we can not use same programmed viewport as that for
CfgRd/Wr0. However, a viewport can be reprogrammed using same physical
cfg address to generate either cfg0 or cfg1. So, in that case we can do
with only one cfg area and no reason to divide it into two.
Current code assumes that there are only 4 viewports available (2 in
outbound and 2 in inbound direction) and it always programs viewport
dynamically for cfg0/1 as per need. But same can not be true for all
implementations. There can be a case where hardware has sufficient
number of viewports and software does not need to reprogram it
dynamically. In that situation different physical memory area for each
type of TLP would make the execution faster.
Also, if you find some problems, please let me know.
Why should it be same as dbi_base?
AFAIK, jacinto6 has a dedicated configuration/io/memory space that is entirely
different from dbi_base.
According to the Synopsys designware PCIe datasheet,
in chapter 5.1.1 Register Space Layout,
'Port Logic Registers' are placed between (config space 0x0 + 0x700)
and (config space 0x0 + 0xFFF).
'dbi_base' is used for reading/writing 'Port Logic Registers'.
Exynos are using 'dbi_base' like this. Thus, the base addresses of
both 'dbi_base' and configuration/io/memory space are same.
Yes address space are same, but at any moment they work either as dbi
space or as configuration/io/memory space depending on the dbi_enable
bit of application register. Similar functionality was there in one
older SPEAr implementation.
Just now, I looked at Spear PCIe driver.
However, in the case of Spear, the base address of configuration/io/memory
space is defined as 0x8000. The base address of 'Port Logic Registers'
is defined as 0xb100.
I think that the situation of 'jacinto6' is similar with Spear, right?
In SPEAr1340 PCIe memory layout is as follows:
DBI base (0xB100 to 0xB1001FFF): This space is used to read/write
own PCI Configuration Header, Capability and Port Logic(PL) Registers.
ELBI space (0xB1002000 to 0xB17F): These are completely SPEAr
specific application registers.
configuration/io/memory space(0x8000 to 0x8FFF): These can be
used in viewport programming to generate different type of outbound
transaction.
Regards
Pratyush
Then, I will move pp-dbi_base mapping code from pcie-designware.c
to pci-exynos.c.
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
