All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Sven Peter" <sven@svenpeter.dev>
To: "Bjorn Helgaas" <helgaas@kernel.org>,
	"Manivannan Sadhasivam" <manivannan.sadhasivam@linaro.org>
Cc: "Lorenzo Pieralisi" <lorenzo.pieralisi@arm.com>,
	"Bjorn Helgaas" <bhelgaas@google.com>,
	svarbanov@mm-sol.com, bjorn.andersson@linaro.org,
	"Rob Herring" <robh@kernel.org>,
	linux-pci@vger.kernel.org, linux-arm-msm@vger.kernel.org,
	linux-kernel@vger.kernel.org, "kernel test robot" <lkp@intel.com>,
	"Marc Zyngier" <maz@kernel.org>,
	"Alyssa Rosenzweig" <alyssa@rosenzweig.io>
Subject: Re: [PATCH] PCI: qcom: Fix warning generated due to the incorrect data type
Date: Tue, 30 Nov 2021 17:35:16 +0100	[thread overview]
Message-ID: <0f3c9f9e-caf9-462a-ba8d-882266d4c7c4@www.fastmail.com> (raw)
In-Reply-To: <20211130160338.GA2739234@bhelgaas>

Hi,

On Tue, Nov 30, 2021, at 17:03, Bjorn Helgaas wrote:
> [+cc Marc, Alyssa, Sven for RID-to-SID mapping insight.  The patch at
> https://lore.kernel.org/all/20211130062137.GD205712@thinkpad/ merely
> fixes a warning.  My meta-question is about the qcom BDF-to-SID
> mapping.]
>
> On Tue, Nov 30, 2021 at 11:51:37AM +0530, Manivannan Sadhasivam wrote:
>> On Mon, Nov 29, 2021 at 09:36:14PM -0600, Bjorn Helgaas wrote:
>> > ...
>> > I'm also curious why pcie-qcom.c is the only driver that does this.
>> > "iommu-map" is not specific to qcom, but no other drivers do similar
>> > things with it.
>> 
>> Yes, on the recent qcom platforms starting from sm8250 we need to program
>> the BDF to SID mapping in the controller and that's the reason we are
>> extracting the "iommu-map" property in DT.
>
> This sounds like something that may not really be specific to sm8250.

So a single IOMMU can possibly differentiate between N different devices [1].
Each device [1] is identified by some number which is called sid (stream id?
security id? who knows.) on Apple hardware (and apparently also on qcom).
Now I don't know much about PCI but the way I understand it is that the
bus/device/function tuple can be used to uniquely identify a single device on the bus.
All iommu-map does is to provide the mapping between those two different spaces [2].

For most iommus this seems to be just a static mapping that's hardwired in silicon
and I think that's why almost no PCI driver needs to care about it: The iommu
core will just use it to convert the PCI requester ID to a number the iommu
driver understands.

Apple's frankenchip however allows to configure this mapping from software
after a device has been attached and that's why we need that special code inside
the PCI driver: We have to make sure that whatever is configured inside iommu-map
(and used by the iommu core to match PCI devices to iommu groups) matches to what
the HW does.

I can only assume that qcom does something similar. It looks like the qcom HW can be
fully configured during probe time though while we really have to wait until a device
is attached for the Apple chip (mostly because we only have 16 slots there).


Hope that helps.


Best,

Sven



[1] Technically the smallest unit are iommu groups which can contain multiple
devices but we can just ignore that. The iommu code will do the correct thing
if it gets told that two PCI devices have the same identification number.

[2] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/iommu/of_iommu.c#n53

  reply	other threads:[~2021-11-30 16:36 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-11-24 14:04 [PATCH] PCI: qcom: Fix warning generated due to the incorrect data type Manivannan Sadhasivam
2021-11-30  3:36 ` Bjorn Helgaas
2021-11-30  6:21   ` Manivannan Sadhasivam
2021-11-30 16:03     ` Bjorn Helgaas
2021-11-30 16:35       ` Sven Peter [this message]
2021-11-30 18:35       ` Marc Zyngier

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=0f3c9f9e-caf9-462a-ba8d-882266d4c7c4@www.fastmail.com \
    --to=sven@svenpeter.dev \
    --cc=alyssa@rosenzweig.io \
    --cc=bhelgaas@google.com \
    --cc=bjorn.andersson@linaro.org \
    --cc=helgaas@kernel.org \
    --cc=linux-arm-msm@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pci@vger.kernel.org \
    --cc=lkp@intel.com \
    --cc=lorenzo.pieralisi@arm.com \
    --cc=manivannan.sadhasivam@linaro.org \
    --cc=maz@kernel.org \
    --cc=robh@kernel.org \
    --cc=svarbanov@mm-sol.com \
    /path/to/YOUR_REPLY

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

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.