On 10/14/2024 4:55 AM, Dmitry Baryshkov wrote:
On Sat, Oct 12, 2024 at 06:13:34PM +0530, Manivannan Sadhasivam wrote:
On Fri, Oct 11, 2024 at 05:24:29PM +0530, Krishna Chaitanya Chundru wrote:
[...]
The logic here is that the fixed endpoints in the switch will get an unique SID
and the devices getting attached to slots will share the same SID of the bus
(this is the usual case with all Qcom SoCs).
But I guess we would need 'iommu-map-mask' as well. Hope this addresses your
concern.
Yes, thank you!
Hi dimitry & mani,
This particular board variant doesn't expose any open slots to connect
a different endpoints like another switch(which might have BDF unknown
to us) so static table should be fine for this board variant.
I tries to add iommu-map-mask property, the issue with that property is
that the driver is applying the mask to the bdf before searching for the
entry in the table. If I use a mask value which satisfies all the
entries in the table ( mask as 0x718) and if a new bdf is enumerated
lets say 0x600 due to mask 0x718 its value is again 0x600 only.
Can we skip iommu-map-mask property and use only static table for this
board as we know this board doesn't expose any open slots.
Hmm, I was not aware that it doesn't have open slots. Fine with me then.
It doesn't feature open slots, but it has two PCIe connections on HS2 /
HS3. Users might attach external PCIe devices.
Krishna, could you please clarify, how those two connections are routed?
For this qps615 board to one of the downstream port (pcie to usb) usb
hub is connected and to the other downstream port NVMe will be
connected.
- Krishna Chaitanya.
