Lines Matching refs:segments

86       * It is divided into 256 segments of equal size.  A table in the chip
99     more segments.
111 	has 256 segments; however, there is no table for mapping a segment
126     trick, to match to those giant segments.
135     - We cannot "group" segments in HW, so if a device ends up using more
144       PEs" that are used for the remaining M64 segments.
179     equally-sized segments.  The finest granularity possible is a 256MB
180     window with 1MB segments.  VF BARs that are 1MB or larger could be
186     BARs span several segments.
192     like the M32 window, but the segments can't be individually mapped to
198     equally-sized segments, and the segment number is the PE#.  But if we
201     and a 32MB BAR, we could use one M64 window to assign 1MB segments and
202     another M64 window to assign 32MB segments.
206   effectively reserve the entire 256 segments (256 * VF BAR size) and
208   segments/PEs inside that M64 window.
214   divided into 256 segments, with each segment corresponding to one PE.
220   than the number of M64 window segments, so if we map one VF BAR directly
224   IODA supports 256 PEs, so segmented windows contain 256 segments, so if
226   segments [total_VFs, 255] of the M64 window may map to some MMIO range on
245   Our current solution is to allocate 256 segments even if the VF(n) BAR
268   respond to segments [0, total_VFs - 1].  There's nothing in hardware that
269   responds to segments [total_VFs, 255].
277 window, we can set the PE# by updating the table that translates segments
294 allocate 256 segments, there are (256 - numVFs) choices for the PE# of VF0.
297 segments to cover a VF BAR, and a VF will be in several PEs.  This is
299 choices because instead of consuming only numVFs segments, the VF(n) BAR
300 space will consume (numVFs * n) segments.  That means there aren't as many
301 available segments for adjusting base of the VF(n) BAR space.