Searched refs:pile (Results 1 – 9 of 9) sorted by relevance
95 # .. wait for traces to pile up ..
93 18. There's a pile of sink handling code, both for DP and HDMI where I didn't
192 static int i40e_get_lump(struct i40e_pf *pf, struct i40e_lump_tracking *pile, in i40e_get_lump() argument198 if (!pile || needed == 0 || id >= I40E_PILE_VALID_BIT) { in i40e_get_lump()201 pile ? "<valid>" : "<null>", needed, id); in i40e_get_lump()206 i = pile->search_hint; in i40e_get_lump()207 while (i < pile->num_entries) { in i40e_get_lump()209 if (pile->list[i] & I40E_PILE_VALID_BIT) { in i40e_get_lump()215 for (j = 0; (j < needed) && ((i+j) < pile->num_entries); j++) { in i40e_get_lump()216 if (pile->list[i+j] & I40E_PILE_VALID_BIT) in i40e_get_lump()223 pile->list[i+j] = id | I40E_PILE_VALID_BIT; in i40e_get_lump()225 pile->search_hint = i + j; in i40e_get_lump()[all …]
25 * There's a big pile of helpers for handling outputs. First the generic bridge
265 - An atomic update is assembled and validated as an entirely free-standing pile
58 now, but there's still a pile of existing drivers that easily could be
256 Each offset runs from 0 to N. It is perfectly fine to pile any number of
100 worse; the pile of changes waiting for the next merge window will grow
4002 plus a pile of warnings.
