[Intel-gfx] [PATCH 00/20] ILK+ interrupt improvements, v2

Daniel Vetter daniel at ffwll.ch
Wed Mar 26 22:35:38 CET 2014


On Wed, Mar 26, 2014 at 9:54 PM, Ben Widawsky <ben at bwidawsk.net> wrote:
>> >> Paulo's using "reset" functions/macros both in the preinstall hooks and in
>> >> the uninstall/disable code. We already use reset for stuff run before
>> >> init/enable code to get the hw in a state we expect it to, so I think
>> >> Paulo's naming choice is accurate and a plain "disable" more misleading.
>> >>
>> >
>> > I cannot disagree more. Every time I read "reset" it confuses me. But it
>> > seems like I am the minority.
>>
>> I understand "reset" may not be the best name, I was already expecting
>> to see suggestions on the naming here. IMHO "disable" is also usable,
>> and I could rename, but Daniel just called it "misleading". So how
>> about we rename it to "clear" instead?
>>
>> (let's see if I can make Ben and Daniel agree on something!)
>>
>> I'll leave discussion of the other topics to the other emails.
>>
>
> "clear" has a distinct definition, and in the case of the mask, you are
> not clearing. It's better than "reset"
>
> I still like, "disable"
> I can live with "disable_and_mask"

I still don't like "disable" really. Imo reset is totally ok, or
disable_and_clear (disable_and_mask_and_clear is a bit too much, and
disable_and_mask leaves out the important part that we clear the damn
thing).

Really, reset has imo clearly defined semantics of "clear to default,
quiescent state so that we can move on". Everything else is more
verbose and or falls short in conveying meaning imo. I know that Bspec
talks about "reset" all the time and means "clear to 0, but imo that
Bspec convention isn't the best choice really. At least it confuses me
to no end.

And since reset is what's in the patch, reset it is. Let's move on.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch



More information about the Intel-gfx mailing list