Searched refs:pile (Results 1 – 9 of 9) sorted by relevance
93 18. There's a pile of sink handling code, both for DP and HDMI where I didn't
96 # .. wait for traces to pile up ..
183 static int i40e_get_lump(struct i40e_pf *pf, struct i40e_lump_tracking *pile, in i40e_get_lump() argument189 if (!pile || needed == 0 || id >= I40E_PILE_VALID_BIT) { in i40e_get_lump()192 pile ? "<valid>" : "<null>", needed, id); in i40e_get_lump()197 i = pile->search_hint; in i40e_get_lump()198 while (i < pile->num_entries) { in i40e_get_lump()200 if (pile->list[i] & I40E_PILE_VALID_BIT) { in i40e_get_lump()206 for (j = 0; (j < needed) && ((i+j) < pile->num_entries); j++) { in i40e_get_lump()207 if (pile->list[i+j] & I40E_PILE_VALID_BIT) in i40e_get_lump()214 pile->list[i+j] = id | I40E_PILE_VALID_BIT; in i40e_get_lump()216 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
102 now, but there's still a pile of existing drivers that easily could be
255 managed to turn a big pile into a group of smaller piles. The work of
256 Each offset runs from 0 to N. It is perfectly fine to pile any number of
101 worse; the pile of changes waiting for the next merge window will grow
