Linux-ARM-Kernel Archive on lore.kernel.org
 help / color / Atom feed
From: Honghui Zhang <honghui.zhang@mediatek.com>
To: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
Cc: youlin.pei@mediatek.com, ryder.lee@mediatek.com,
	poza@codeaurora.org, fred@fredlawl.com,
	linux-pci@vger.kernel.org, rafael.j.wysocki@intel.com,
	linux-kernel@vger.kernel.org, jianjun.wang@mediatek.com,
	linux-mediatek@lists.infradead.org, bhelgaas@google.com,
	linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH v3 2/2] PCI: mediatek: Enlarge PCIe2AHB window size to support 4GB DRAM
Date: Fri, 1 Mar 2019 09:58:26 +0800
Message-ID: <1551405506.32061.18.camel@mhfsdcap03> (raw)
In-Reply-To: <20190228174257.GA26501@e107981-ln.cambridge.arm.com>

On Thu, 2019-02-28 at 17:42 +0000, Lorenzo Pieralisi wrote:
> On Fri, Feb 01, 2019 at 01:36:07PM +0800, honghui.zhang@mediatek.com wrote:
> > From: Honghui Zhang <honghui.zhang@mediatek.com>
> > 
> > The PCIE_AXI_WINDOW0 defines the translate window size for the request
> > from EP side. Request outside of this window will be treated as
> > unsupported request.
> > 
> > Enlarge this window size from fls(0xffffffff) to 2^33 to support 8GB
> > translate address range then EP DMA is capable of fully access 4GB
> > DRAM range(physical DRAM is start from 0x40000000).
> 
> I have rewritten both patches logs with the aim of merging them even if
> it is quite late in the cycle, first you have to explain something to
> me.
> 

Thanks very much for this.

> fls(0xffffffff) = 0x1f, which by your logic -> 2^31
> 
> What does it mean given what you say above ? That PCI devices can't
> do _any_ DMA in the current setting (given the DRAM start address) ?
> 

I'm afraid so.
From the HW datasheet I got from our HW designer, the description for
this pcie2axi_win_size filed is
" Possible values are 12 to 36 which means 2^12 to 2^36 bytes, leaving
this filed to 0 causes window to be disabled."

Current setting set the window size as 2^31, which means the request
from EP side could only access the address range from 0 to 0x8000_0000.
Considering the DRAM start from 0x4000_0000, that means only the first
1GB(0x4000_0000 ~ 0x8000_0000) could be accessed by EP side DMA.

This has not run into an error for our current usage, I guess because
MT2712 and MT7622 have several type boards, most of are only have 2GB
physical memory, and our test sample is not bigger enough to cover the
case that EP DMA will access fully DRAM. Or most EP device does not have
an built-in DMA engine, they may relay on the host side's MMIO(memory
mapped IO) operations.
 
Take MT2712 as example, in arch/arm64/boot/dts/mediatek/mt2712-evb.dts,
the physical memory size is defined as 0x80000000 and is described by
below node:

memory@400000000 {
	device_type = "memory";
	reg = <0 0x400000000 0 0x800000000>
}

Thanks.

> Lorenzo
> 
> > Reported-by: Bjorn Helgaas <bhelgaas@google.com>
> > Signed-off-by: Honghui Zhang <honghui.zhang@mediatek.com>
> > ---
> >  drivers/pci/controller/pcie-mediatek.c | 8 +++++++-
> >  1 file changed, 7 insertions(+), 1 deletion(-)
> > 
> > diff --git a/drivers/pci/controller/pcie-mediatek.c b/drivers/pci/controller/pcie-mediatek.c
> > index c42fe5c..0b6c728 100644
> > --- a/drivers/pci/controller/pcie-mediatek.c
> > +++ b/drivers/pci/controller/pcie-mediatek.c
> > @@ -90,6 +90,12 @@
> >  #define AHB2PCIE_SIZE(x)	((x) & GENMASK(4, 0))
> >  #define PCIE_AXI_WINDOW0	0x448
> >  #define WIN_ENABLE		BIT(7)
> > +/*
> > + * Define PCIe to AHB window size as 2^33 to support max 8GB address space
> > + * translate, support least 4GB DRAM size access from EP DMA(physical DRAM
> > + * start from 0x40000000).
> > + */
> > +#define PCIE2AHB_SIZE	0x21
> >  
> >  /* PCIe V2 configuration transaction header */
> >  #define PCIE_CFG_HEADER0	0x460
> > @@ -713,7 +719,7 @@ static int mtk_pcie_startup_port_v2(struct mtk_pcie_port *port)
> >  	writel(val, port->base + PCIE_AHB_TRANS_BASE0_H);
> >  
> >  	/* Set PCIe to AXI translation memory space.*/
> > -	val = fls(0xffffffff) | WIN_ENABLE;
> > +	val = PCIE2AHB_SIZE | WIN_ENABLE;
> >  	writel(val, port->base + PCIE_AXI_WINDOW0);
> >  
> >  	return 0;
> > -- 
> > 2.6.4
> > 



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

  reply index

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-02-01  5:36 [PATCH v3 0/2] PCI: mediatek: enable whole MMIO range and enlarge the PCIe2AHB window size honghui.zhang
2019-02-01  5:36 ` [PATCH v3 1/2] PCI: mediatek: Enable the whole memory mapped IO range honghui.zhang
2019-02-01  5:36 ` [PATCH v3 2/2] PCI: mediatek: Enlarge PCIe2AHB window size to support 4GB DRAM honghui.zhang
2019-02-28 17:42   ` Lorenzo Pieralisi
2019-03-01  1:58     ` Honghui Zhang [this message]
2019-02-12  3:32 ` [SPAM][PATCH v3 0/2] PCI: mediatek: enable whole MMIO range and enlarge the PCIe2AHB window size Ryder Lee
2019-03-01 11:30 ` [PATCH " Lorenzo Pieralisi

Reply instructions:

You may reply publically to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1551405506.32061.18.camel@mhfsdcap03 \
    --to=honghui.zhang@mediatek.com \
    --cc=bhelgaas@google.com \
    --cc=fred@fredlawl.com \
    --cc=jianjun.wang@mediatek.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mediatek@lists.infradead.org \
    --cc=linux-pci@vger.kernel.org \
    --cc=lorenzo.pieralisi@arm.com \
    --cc=poza@codeaurora.org \
    --cc=rafael.j.wysocki@intel.com \
    --cc=ryder.lee@mediatek.com \
    --cc=youlin.pei@mediatek.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

Linux-ARM-Kernel Archive on lore.kernel.org

Archives are clonable:
	git clone --mirror https://lore.kernel.org/linux-arm-kernel/0 linux-arm-kernel/git/0.git
	git clone --mirror https://lore.kernel.org/linux-arm-kernel/1 linux-arm-kernel/git/1.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 linux-arm-kernel linux-arm-kernel/ https://lore.kernel.org/linux-arm-kernel \
		linux-arm-kernel@lists.infradead.org
	public-inbox-index linux-arm-kernel

Example config snippet for mirrors

Newsgroup available over NNTP:
	nntp://nntp.lore.kernel.org/org.infradead.lists.linux-arm-kernel


AGPL code for this site: git clone https://public-inbox.org/public-inbox.git