linux-pci.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Ray Jui <ray.jui@broadcom.com>
To: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>,
	Srinath Mannam <srinath.mannam@broadcom.com>
Cc: Bjorn Helgaas <bhelgaas@google.com>, Ray Jui <rjui@broadcom.com>,
	Scott Branden <sbranden@broadcom.com>,
	BCM Kernel Feedback <bcm-kernel-feedback-list@broadcom.com>,
	linux-pci@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	Abhishek Shah <abhishek.shah@broadcom.com>
Subject: Re: [PATCH v4 2/2] PCI: iproc: Add outbound configuration for 32-bit I/O region
Date: Mon, 1 Apr 2019 15:03:37 -0700	[thread overview]
Message-ID: <e7d3e5a1-db5c-8438-f10f-81b87aba0e03@broadcom.com> (raw)
In-Reply-To: <20190401164416.GA8616@e107981-ln.cambridge.arm.com>

Hi Lorenzo/Srinath,

I look at the commit message again and indeed it looks quite confusing.

I'll add my comment inline in the code section. I hope that will help to
make it more clear.

On 4/1/2019 9:44 AM, Lorenzo Pieralisi wrote:
> On Mon, Apr 01, 2019 at 11:04:48AM +0530, Srinath Mannam wrote:
>> Hi Lorenzo,
>>
>> Please see my reply below,
>>
>> On Fri, Mar 29, 2019 at 11:06 PM Lorenzo Pieralisi
>> <lorenzo.pieralisi@arm.com> wrote:
>>>
>>> On Fri, Mar 01, 2019 at 10:22:16AM +0530, Srinath Mannam wrote:
>>>> In the present driver outbound window configuration is done to map above
>>>> 32-bit address I/O regions with corresponding PCI memory range given in
>>>> ranges DT property.
>>>>
>>>> This patch add outbound window configuration to map below 32-bit I/O range
>>>> with corresponding PCI memory, which helps to access I/O region in ARM
>>>> 32-bit and one to one mapping of I/O region to PCI memory.
>>>>
>>>> Ex:
>>>> 1. ranges DT property given for current driver is,
>>>>     ranges = <0x83000000 0x0 0x40000000 0x4 0x00000000 0 0x40000000>;
>>>>     I/O region address is 0x400000000
>>>> 2. ranges DT property can be given after this patch,
>>>>     ranges = <0x83000000 0x0 0x42000000 0x0 0x42000000 0 0x2000000>;
>>>>     I/O region address is 0x42000000
>>>
>>> I was applying this patch but I don't understand the commit log and
>>> how it matches the code, please explain it to me and I will reword
>>> it.
>> Iproc PCIe host controller supports outbound address translation
>> feature to translate AXI address to PCI bus address.
>> IO address ranges (AXI and PCI) given through ranges DT property have
>> to program to controller outbound window registers.
>> Present driver has the support for only 64bit AXI address. so that
>> ranges DT property has given as 64bit AXI address and 32 bit
>> PCI bus address.
>> But with this patch 32-bit AXI address also could be programmed to
>> Iproc host controller outbound window registers. so that ranges
>> DT property can have 32bit AXI address which can map to 32-bit PCI bus address.
> 
> The code change seems to add a check for the window size, I see no
> notion of 64 vs 32 bit addressing there so I am pretty sure there is
> something you are not telling me that is implicit in the IProc outbound
> window configuration, for instance why is the lowest index window
> considered for 32-bit.
> 
> AFAICS you are adding code to allow a window whose size is < than
> the lowest index in the ob_map array. How this relates to 64 vs
> 32 bit addresses is not clear but it should be.
> 
> When I read your commit log it is impossible to understand how it
> correlates to the code you are changing - I still have not figured it
> out myself.
> 
> Please explain in detail to me how this works, forget DT changes I
> want to understand how HW works.
> 
> Lorenzo
> 
>> Example given in commit log is describing ranges DT property changes
>> with and without this patch.
>> In the case, without this patch AXI address is more than 32bit
>> "0x400000000". and with this patch AXI address is 32-bit "0x42000000".
>> PCI bus address is 32 bit address in both the cases "0x40000000" and 0x42000000.
>>
>> Regards,
>> Srinath.
>>> Thanks,
>>> Lorenzo
>>>
>>>> Signed-off-by: Srinath Mannam <srinath.mannam@broadcom.com>
>>>> Signed-off-by: Abhishek Shah <abhishek.shah@broadcom.com>
>>>> Signed-off-by: Ray Jui <ray.jui@broadcom.com>
>>>> ---
>>>>  drivers/pci/controller/pcie-iproc.c | 21 +++++++++++++++++++--
>>>>  1 file changed, 19 insertions(+), 2 deletions(-)
>>>>
>>>> diff --git a/drivers/pci/controller/pcie-iproc.c b/drivers/pci/controller/pcie-iproc.c
>>>> index b882255..080f142 100644
>>>> --- a/drivers/pci/controller/pcie-iproc.c
>>>> +++ b/drivers/pci/controller/pcie-iproc.c
>>>> @@ -955,8 +955,25 @@ static int iproc_pcie_setup_ob(struct iproc_pcie *pcie, u64 axi_addr,
>>>>                       resource_size_t window_size =
>>>>                               ob_map->window_sizes[size_idx] * SZ_1M;
>>>>
>>>> -                     if (size < window_size)
>>>> -                             continue;
>>>> +                     /*
>>>> +                      * Keep iterating until we reach the last window and
>>>> +                      * with the minimal window size at index zero. In this
>>>> +                      * case, we take a compromise by mapping it using the
>>>> +                      * minimum window size that can be supported
>>>> +                      */

I think the code comment above is much more clear than the commit
message. It looks like the commit message was to describe a particular
use case that prompts the code change. However, if I remember correctly,
during our internal review, I already made some modification to the code
to make the change much more generic than dealing with a special use
case. This patch contains the generic change I made.

Basically, 'size' is the intended outbound mapping size (from DT or ACPI
or whatever, it does not really matter). 'window_size' is a specific
mapping window size our PCIe controller can support. Our PCIe controller
supports a fixed set of outbound mapping window sizes. I don't think
this is much different from some other PCIe controllers.

It looks like, there are cases where one cannot find an exact match
between 'size' and 'window_size'. In this case, and when we know we have
already exhausted all possible mapping windows, i.e., 'size_idx' == 0
AND 'window_idx' == 0, we take a compromise by programming the outbound
mapping by using a window size that's actually larger than the 'size'.

Srinath, please correct me if I'm wrong. But I carefully reviewed the
code again and I believe this is essentially what it is.

If so, then the commit message is quite misleading and can be changed to
above descriptions.

>>>> +                     if (size < window_size) {
>>>> +                             if (size_idx > 0 || window_idx > 0)
>>>> +                                     continue;
>>>> +
>>>> +                             /*
>>>> +                              * For the corner case of reaching the minimal
>>>> +                              * window size that can be supported on the
>>>> +                              * last window
>>>> +                              */
>>>> +                             axi_addr = ALIGN_DOWN(axi_addr, window_size);
>>>> +                             pci_addr = ALIGN_DOWN(pci_addr, window_size);
>>>> +                             size = window_size;
>>>> +                     }
>>>>
>>>>                       if (!IS_ALIGNED(axi_addr, window_size) ||
>>>>                           !IS_ALIGNED(pci_addr, window_size)) {
>>>> --
>>>> 2.7.4
>>>>

  reply	other threads:[~2019-04-01 22:03 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-03-01  4:52 [PATCH v4 0/2] Add IPROC PCIe new features Srinath Mannam
2019-03-01  4:52 ` [PATCH v4 1/2] PCI: iproc: Add CRS check in config read Srinath Mannam
2019-03-01  4:52 ` [PATCH v4 2/2] PCI: iproc: Add outbound configuration for 32-bit I/O region Srinath Mannam
2019-03-29 17:35   ` Lorenzo Pieralisi
2019-04-01  5:34     ` Srinath Mannam
2019-04-01 16:44       ` Lorenzo Pieralisi
2019-04-01 22:03         ` Ray Jui [this message]
2019-04-02  9:50           ` Srinath Mannam
2019-04-02 10:26             ` Lorenzo Pieralisi
2019-04-02 10:46               ` Srinath Mannam
2019-04-02 13:38                 ` Lorenzo Pieralisi
2019-04-03  3:11                   ` Srinath Mannam
2019-04-03 11:31                     ` Lorenzo Pieralisi
2019-04-04  5:41                       ` Srinath Mannam
2019-04-04 17:48                       ` Ray Jui
2019-03-27  8:38 ` [PATCH v4 0/2] Add IPROC PCIe new features Srinath Mannam
2019-03-27 12:31   ` Lorenzo Pieralisi
2019-03-27 15:15     ` Srinath Mannam
2019-03-29 16:51 ` Lorenzo Pieralisi
2019-03-29 17:03   ` Scott Branden

Reply instructions:

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

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

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

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

  git send-email \
    --in-reply-to=e7d3e5a1-db5c-8438-f10f-81b87aba0e03@broadcom.com \
    --to=ray.jui@broadcom.com \
    --cc=abhishek.shah@broadcom.com \
    --cc=bcm-kernel-feedback-list@broadcom.com \
    --cc=bhelgaas@google.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pci@vger.kernel.org \
    --cc=lorenzo.pieralisi@arm.com \
    --cc=rjui@broadcom.com \
    --cc=sbranden@broadcom.com \
    --cc=srinath.mannam@broadcom.com \
    /path/to/YOUR_REPLY

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

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).