linux-pci.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Bjorn Helgaas <helgaas@kernel.org>
To: "Havalige, Thippeswamy" <thippeswamy.havalige@amd.com>
Cc: "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"robh+dt@kernel.org" <robh+dt@kernel.org>,
	"bhelgaas@google.com" <bhelgaas@google.com>,
	"linux-pci@vger.kernel.org" <linux-pci@vger.kernel.org>,
	"krzysztof.kozlowski@linaro.org" <krzysztof.kozlowski@linaro.org>,
	"lpieralisi@kernel.org" <lpieralisi@kernel.org>,
	"Gogada, Bharat Kumar" <bharat.kumar.gogada@amd.com>,
	"Simek, Michal" <michal.simek@amd.com>,
	"linux-arm-kernel@lists.infradead.org" 
	<linux-arm-kernel@lists.infradead.org>
Subject: Re: [PATCH] PCI: xilinx-nwl: Remove unnecessary code and updating ecam default value.
Date: Fri, 4 Aug 2023 14:58:27 -0500	[thread overview]
Message-ID: <20230804195827.GA159466@bhelgaas> (raw)
In-Reply-To: <SN7PR12MB72014E79448FE6C7A47718E28B09A@SN7PR12MB7201.namprd12.prod.outlook.com>

On Fri, Aug 04, 2023 at 07:05:30PM +0000, Havalige, Thippeswamy wrote:
> > -----Original Message-----
> > From: Bjorn Helgaas <helgaas@kernel.org>
> > On Thu, Aug 03, 2023 at 05:20:16PM +0530, Thippeswamy Havalige wrote:
> > > Remove reduntant code.
> > > Change NWL_ECAM_VALUE_DEFAULT to 16 to support maximum 256
> > > buses.
> > 
> > Remove period from subject line.
> > 
> > Please mention the most important part first in the subject -- the
> > ECAM change sounds more important than removing redundant code.
> > 
> > s/ecam/ECAM/
> > s/reduntant/redundant/
> > 
> > Please elaborate on why this code is redundant.  What makes it
> > redundant?  Apparently the bus number registers default to the correct
> > values or some other software programs them?
> 
>  - Yes, The  Primary,Secondary and sub-ordinate bus number registers
>  are programmed/updated as part of linux enumeration so updating
>  these registers are redundant.

Ah, so the Linux PCI core can handle updating these from whatever the
power-up values are.  Good material for the revised commit log.

> > "ECAM_VALUE" is not a very informative name.  I don't know what an
> > "ECAM value" would be.  How is the value 16 related to a maximum of
> > 256 buses?  We only need 8 bits to address 256 buses, so it must be
> > something else.  The bus number appears at bits 20-27
> > (PCIE_ECAM_BUS_SHIFT) in a standard ECAM address, so probably not the
> > bit location?
>
> Yes, Agreed I'll modify ECAM_VALUE as ECAM_SIZE here and it is not
> related to a maximum 256 buses.

Well, it sounds like this value *does* determine the size of the ECAM
region, which does constrain the number of buses you can address via
ECAM.

> > Does this fix a problem?
> 
> - Yes, It is fixing a problem. Our controller is expecting ECAM size
> to be programmed by software.  By programming
> "NWL_ECAM_VALUE_DEFAULT  12" controller can access upto 16MB ECAM
> region which is used to detect 16 buses so by updating
> "NWL_ECAM_VALUE_DEFAULT " to 16 controller can access upto 256 Mb
> ECAM region to detect 256 buses.
> 
> 2^(ecam_size_offset+ecam_size) 
> 
> Here (ecam_size_offset=12 and ecam_size=16) --> 256Mb

More good material for the commit log.  (1) Change in ECAM region
size, (2) previously could only address 16 buses, now can address 256
buses.

Is there any impact on DT from the address map change?

Bjorn

  reply	other threads:[~2023-08-04 19:58 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-08-03 11:50 [PATCH] PCI: xilinx-nwl: Remove unnecessary code and updating ecam default value Thippeswamy Havalige
2023-08-03 16:55 ` Bjorn Helgaas
2023-08-04 19:05   ` Havalige, Thippeswamy
2023-08-04 19:58     ` Bjorn Helgaas [this message]
2023-08-05 19:07       ` Havalige, Thippeswamy
2023-08-03 19:39 ` kernel test robot

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=20230804195827.GA159466@bhelgaas \
    --to=helgaas@kernel.org \
    --cc=bharat.kumar.gogada@amd.com \
    --cc=bhelgaas@google.com \
    --cc=krzysztof.kozlowski@linaro.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pci@vger.kernel.org \
    --cc=lpieralisi@kernel.org \
    --cc=michal.simek@amd.com \
    --cc=robh+dt@kernel.org \
    --cc=thippeswamy.havalige@amd.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).