Lines Matching refs:segments

95       * It is divided into 256 segments of equal size.  A table in the chip
108     more segments.
120 	has 256 segments; however, there is no table for mapping a segment
135     trick, to match to those giant segments.
144     - We cannot "group" segments in HW, so if a device ends up using more
153       PEs" that are used for the remaining M64 segments.
189     equally-sized segments.  The finest granularity possible is a 256MB
190     window with 1MB segments.  VF BARs that are 1MB or larger could be
196     BARs span several segments.
202     like the M32 window, but the segments can't be individually mapped to
208     equally-sized segments, and the segment number is the PE#.  But if we
211     and a 32MB BAR, we could use one M64 window to assign 1MB segments and
212     another M64 window to assign 32MB segments.
216   effectively reserve the entire 256 segments (256 * VF BAR size) and
218   segments/PEs inside that M64 window.
224   divided into 256 segments, with each segment corresponding to one PE.
230   than the number of M64 window segments, so if we map one VF BAR directly
234   IODA supports 256 PEs, so segmented windows contain 256 segments, so if
236   segments [total_VFs, 255] of the M64 window may map to some MMIO range on
255   Our current solution is to allocate 256 segments even if the VF(n) BAR
278   respond to segments [0, total_VFs - 1].  There's nothing in hardware that
279   responds to segments [total_VFs, 255].
288 window, we can set the PE# by updating the table that translates segments
305 allocate 256 segments, there are (256 - numVFs) choices for the PE# of VF0.
308 segments to cover a VF BAR, and a VF will be in several PEs.  This is
310 choices because instead of consuming only numVFs segments, the VF(n) BAR
311 space will consume (numVFs * n) segments.  That means there aren't as many
312 available segments for adjusting base of the VF(n) BAR space.