search for: driver_own

...d 0->1 or 1->0 and this value is written to every descriptor DESC_WRAP until we reach the first descriptor again > >After writing down this explanation, I think the names aren't >great. > >Let me try an alternative explanation. > >--------------- >A two-bit field, DRIVER_OWNER, signals the buffer ownership. >It has 4 possible values: >values 0x1, 0x11 are written by driver >values 0x0, 0x10 are written by device The 0x prefix might add to the confusion here. It is really just two bits, no? >each time driver writes out a descriptor, it must make sure >t...

...d 0->1 or 1->0 and this value is written to every descriptor DESC_WRAP until we reach the first descriptor again > >After writing down this explanation, I think the names aren't >great. > >Let me try an alternative explanation. > >--------------- >A two-bit field, DRIVER_OWNER, signals the buffer ownership. >It has 4 possible values: >values 0x1, 0x11 are written by driver >values 0x0, 0x10 are written by device The 0x prefix might add to the confusion here. It is really just two bits, no? >each time driver writes out a descriptor, it must make sure >t...

Get it now. Please correct me if I missing something. Flags status hints, - DESC_DRIVER only: driver owns the descriptor w/o available info ready for device to use - DESC_DRIVER | DESC_WRAP: driver has prepared an available descriptor, device hasn't used it yet - None: device has used the descriptor, and write descriptor out - DESC_WRAP only: shall not happen, device make sure to clear

Get it now. Please correct me if I missing something. Flags status hints, - DESC_DRIVER only: driver owns the descriptor w/o available info ready for device to use - DESC_DRIVER | DESC_WRAP: driver has prepared an available descriptor, device hasn't used it yet - None: device has used the descriptor, and write descriptor out - DESC_WRAP only: shall not happen, device make sure to clear

...es this is what I tried to say. Can you suggest a better wording then? > > > > After writing down this explanation, I think the names aren't > > great. > > > > Let me try an alternative explanation. > > > > --------------- > > A two-bit field, DRIVER_OWNER, signals the buffer ownership. > > It has 4 possible values: > > values 0x1, 0x11 are written by driver > > values 0x0, 0x10 are written by device > > The 0x prefix might add to the confusion here. It is really just two > bits, no? Ouch. Yes I meant 0b. Thanks! >...

...then? The term of DESC_WRAP is fine to me. > > > > > > > After writing down this explanation, I think the names aren't great. > > > > > > Let me try an alternative explanation. > > > > > > --------------- > > > A two-bit field, DRIVER_OWNER, signals the buffer ownership. > > > It has 4 possible values: > > > values 0x1, 0x11 are written by driver values 0x0, 0x10 are written > > > by device > > > > The 0x prefix might add to the confusion here. It is really just two > > bits, no? > &g...

...then? The term of DESC_WRAP is fine to me. > > > > > > > After writing down this explanation, I think the names aren't great. > > > > > > Let me try an alternative explanation. > > > > > > --------------- > > > A two-bit field, DRIVER_OWNER, signals the buffer ownership. > > > It has 4 possible values: > > > values 0x1, 0x11 are written by driver values 0x0, 0x10 are written > > > by device > > > > The 0x prefix might add to the confusion here. It is really just two > > bits, no? > &g...

...t value internally (start value 1) and flip it every time you overwrite the first descriptor. Device leaves it intact when overwriting a descriptor. After writing down this explanation, I think the names aren't great. Let me try an alternative explanation. --------------- A two-bit field, DRIVER_OWNER, signals the buffer ownership. It has 4 possible values: values 0x1, 0x11 are written by driver values 0x0, 0x10 are written by device each time driver writes out a descriptor, it must make sure that the high bit in OWNER changes. each time device writes out a descriptor, it must make sure that...