Re: [PATCH 08/11] PCI/IDE: Add IDE establishment helpers

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Aneesh Kumar K.V wrote:
> Dan Williams <dan.j.williams@xxxxxxxxx> writes:
> 
> > Aneesh Kumar K.V wrote:
> > [..]
> >>
> >> Also wondering should the stream id be unique at the rootport level? ie
> >> for a config like below
> >>
> >> # pwd
> >> /sys/devices/platform/40000000.pci/pci0000:00
> >> # ls
> >> 0000:00:01.0              available_secure_streams  power
> >> 0000:00:02.0              pci_bus                   uevent
> >> # lspci
> >> 00:01.0 PCI bridge: ARM Device 0def
> >> 00:02.0 PCI bridge: ARM Device 0def
> >> 01:00.0 Unassigned class [ff00]: ARM Device ff80
> >> 02:00.0 SATA controller: Device 0abc:aced (rev 01)
> >> #
> >> # lspci -t
> >> -[0000:00]-+-01.0-[01]----00.0
> >>            \-02.0-[02]----00.0
> >> #
> >>
> >>
> >> I should be able to use the same stream id to program both the rootports?
> >
> > For all the IDE capable platforms I know of the stream id allocation
> > pool is segmented per host-bridge. Do you have a use case where root
> > ports that share a host-bridge each have access to a distinct pool of
> > IDE stream ids?
> 
> I am using FVP simulator for my development. Hence no real device. The spec states:
> "
> All IDE TLPs must be associated with an IDE Stream, identified via an IDE Stream ID.
> ◦ Software must assign IDE Stream IDs such that two Partner Ports use the same value for a given IDE
> Stream.
> ◦ Software must assign IDE Stream IDs such that every enabled IDE Stream associated with a given
> terminal Port is assigned a unique Stream ID value at that Port
> ◦ It is permitted for a platform to further restrict the assignment of Stream IDs.
> "
> 
> If I understand correctly, the stream ID allocation pool per host bridge
> qualifies as an additional platform restriction? If so, why is Linux
> enforcing it? Wouldn’t it be more appropriate for the platform code to
> handle this instead?

Ah, ok, yes, the Stream ID itself only needs to be unique within a given
port pair so it is reasonable for 2 root ports to alias Stream IDs.

It turns out I was overloading "Stream ID" and in practice there are
three separate resources to consider:

- Stream ID: 256 Stream IDs within a port pair (can alias across Root
             Ports): TSM allocated

- Stream instance: Up to 16 Selective Streams Per port: Linux allocated

- Stream resource: Platform specific number of supported streams, likely
                   per-host bridge: Linux allocation constraint

That last one may be a small number like 4 given the relative expense of
link encryption hardware.

The motivation for registering streams as a sysfs object is mainly for
an administrator to manage that last number as the tightest constrained
resource. However Linux can also keep the TSM honest that it is not
violating allocation expectations within a port pair.




[Index of Archives]     [DMA Engine]     [Linux Coverity]     [Linux USB]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [Greybus]

  Powered by Linux