OK. Thanks. I'm marking this case approved.
- Garrett
Wesley Shao wrote:
> I have no objection to that.
>
> Thanks,
>
> Wes
>
> Garrett D'Amore wrote:
>> Okay, it sounds like what you're requesting is really a change of
>> additional things, outside the scope of this case.
>>
>> Can I suggest we go forward with 8 for now, and if you're going to do
>> some additional changes to error handling, bridges, or other things,
>> you run another case to make those changes? (And you can push audio
>> down to 7 at that time, if you need to.)
>>
>> Also, not *all* audio devices are DMA. There are several audio
>> devices which are PIO driven.
>>
>> The nice thing about this case is, once its done, we can remove the
>> interrupt-priorities override property from the driver.conf files, so
>> that if you want to adjust the priorities later, you can do so in the
>> nexus code, and not have to touch a gazillion different .conf files.
>>
>> -- Garrett
>>
>> Wesley Shao wrote:
>>> Today, 7 or 8 doesn't make much difference since practically no one is
>>> using 7 or 8. Some bus controllers are defaulted to use 9 because they
>>> could be proxy-ing interrupts on other devices behalf, but that is
>>> just the original intent and isn't known for sure.
>>>
>>> Going forward, for DMA devices, we need to push them as low as they
>>> can.
>>> As long as audio is above 6, we shouldn't be breaking any relative
>>> priority (thus causing performance differentiations, or video goes out
>>> of sync with audio).
>>>
>>> On a side note, we should move the rest of the 9 crowd (bridges,
>>> etc) to
>>> 8 and leave 9 for error handling. Currently error handling is above
>>> lock
>>> level and we are having major issues with it. That would be a different
>>> case though.
>>>
>>> In short, I think 7 is a better fit for audio.
>>>
>>> Wes
>>>
>>> Garrett D'Amore wrote:
>>>> Resending, since I forgot to add the CC to PSARC! Doh!
>>>>
>>>> ------------------------------------------------------------------------
>>>>
>>>>
>>>> Subject:
>>>> Re: PCI Multimedia Class Interrupt Priorities [PSARC/2008/343
>>>> FastTrack timeout 06/03/2008]
>>>> From:
>>>> Garrett D'Amore <gdamore at sun.com>
>>>> Date:
>>>> Wed, 28 May 2008 13:04:06 -0700
>>>> To:
>>>> Wesley Shao <Wesley.Shao at Sun.COM>
>>>>
>>>> To:
>>>> Wesley Shao <Wesley.Shao at Sun.COM>
>>>>
>>>>
>>>> Wesley Shao wrote:
>>>>> I can't think of reasons for below audio and above networking. Modern
>>>>> audio devices (especially the HD ones) are all DMA based, interrupt
>>>>> priority becomes relatively less important. I would like to push
>>>>> for 7
>>>>> if we can.
>>>> Why? (I can't think of reasons either, but then again I can't think
>>>> of reasons for between audio and lock level.)
>>>>
>>>> Put another way, I'm not sure we buy anything by further reducing
>>>> the level below 8.
>>>>
>>>> I can definitely think of good reasons why even with DMA,
>>>> interrupts needs to be serviced in a timely fashion.
>>>> (Synchronization of audio with video, games, etc. as one example.
>>>> Certain kinds of low latency applications such as echo
>>>> cancellation, and VoIP processing, are other examples where one
>>>> wants to make sure that the processing latency is as low as we can
>>>> easily make it.)
>>>>
>>>> Btw, I'm putting PSARC back on the distribution list for this, as
>>>> this discussion really needs to be recorded in the case log.
>>>>
>>>> At ARC today, this case was approved for level 8. Its probably a
>>>> minor update if we think we should move to level 7, but I am a bit
>>>> more hesitant there, given the need for audio drivers to get
>>>> serviced promptly.
>>>>
>>>> -- Garrett
>>>>>
>>>>> Wes
>>>>>
>>>>> Garrett D'Amore wrote:
>>>>>> Wesley Shao wrote:
>>>>>>> Why not making it even lower, like 7 or 8? There are virtually
>>>>>>> no drivers
>>>>>>> using 7 or higher. That will give some breathing room in case we
>>>>>>> have to
>>>>>>> debug some drivers and want to put them between audio and 10.
>>>>>>
>>>>>> I'm open to this idea. Level 9 was what was already in use, and
>>>>>> seemed to be well tested, which is why I proposed it. But I'd be
>>>>>> happy to use 8, as well. I don't think audio drivers have any
>>>>>> dependencies on any other drivers/devices, apart from typical
>>>>>> lock-oriented dependencies upon the system timer.
>>>>>>
>>>>>> Using 8 allows 7 to be used for things that are "just below"
>>>>>> audio, and 9 to be used for things that are "just above". (I
>>>>>> can't think of any examples of either one of those... but maybe
>>>>>> someday someone else will.)
>>>>>>
>>>>>> Does anyone else have any thoughts?
>>>>>>
>>>>>> -- Garrett
>>>>>>>
>>>>>>> Wes
>>>>>>>
>>>>>>> Garrett D'Amore - sun microsystems wrote:
>>>>>>>> I'm submitting this fast-track case on my own behalf. It
>>>>>>>> probably could
>>>>>>>> qualify for self-review, but I want to give any interested
>>>>>>>> parties a chance
>>>>>>>> to comment.
>>>>>>>>
>>>>>>>> Requested binding is Patch on the basis that no real interfaces
>>>>>>>> are changing,
>>>>>>>> although realistically there is probaby little chance that
>>>>>>>> we'll backport this
>>>>>>>> to S10.
>>>>>>>>
>>>>>>>> Template Version: @(#)sac_nextcase 1.66 04/17/08 SMI
>>>>>>>> This information is Copyright 2008 Sun Microsystems
>>>>>>>> 1. Introduction
>>>>>>>> 1.1. Project/Component Working Name:
>>>>>>>> PCI Multimedia Class Interrupt Priorities
>>>>>>>> 1.2. Name of Document Author/Supplier:
>>>>>>>> Author: Garrett D'Amore
>>>>>>>> 1.3 Date of This Document:
>>>>>>>> 27 May, 2008
>>>>>>>> 4. Technical Description
>>>>>>>>
>>>>>>>> Fast-track: PCI Multimedia Class Interrupt Priorities
>>>>>>>> Requested Binding: Patch
>>>>>>>>
>>>>>>>> Problem
>>>>>>>> -------
>>>>>>>>
>>>>>>>> The current Solaris PCI nexus logic assigns high level
>>>>>>>> interrupts (level 12)
>>>>>>>> to devices that are in PCI class 4 (multimedia class). This
>>>>>>>> includes all
>>>>>>>> audio devices. (Most of which are either subclass 1 for legacy
>>>>>>>> audio
>>>>>>>> devices, or 3 for newer hdaudio compliant devices.)
>>>>>>>>
>>>>>>>> However, none of the current Solaris device drivers can operate
>>>>>>>> with such
>>>>>>>> high interrupt priorities. All of the audio drivers in Solaris
>>>>>>>> wind up
>>>>>>>> reassigning an interrupt priority of 9 using the undocumented
>>>>>>>> property
>>>>>>>> "interrupt-priorities" in their driver.conf(4) to overcome this
>>>>>>>> problem.
>>>>>>>>
>>>>>>>> (Recall that priority 10 is "lock level", the level above which
>>>>>>>> device drivers
>>>>>>>> must not use locks or other constructs which could result in
>>>>>>>> putting a thread
>>>>>>>> to sleep.)
>>>>>>>>
>>>>>>>> The project team is unaware of device drivers for any hardware
>>>>>>>> in the
>>>>>>>> multimedia class *other* than audio devices.
>>>>>>>>
>>>>>>>> The new audio framework proposed in PSARC 2008/318 will also be
>>>>>>>> unable to
>>>>>>>> function with high-level interrupts.
>>>>>>>>
>>>>>>>> Solution
>>>>>>>> --------
>>>>>>>>
>>>>>>>> We propose to change the default interrupt-priority for all
>>>>>>>> devices in the
>>>>>>>> multimedia class (PCI class 4) to 9. Experience has shown that
>>>>>>>> this
>>>>>>>> level is sufficiently high to meet the needs of low-latency
>>>>>>>> audio devices,
>>>>>>>> without requiring extraordinary measures normally required when
>>>>>>>> dealing with
>>>>>>>> high-level interrupts.
>>>>>>>>
>>>>>>>> As indicated, we are unaware of any devices supported by
>>>>>>>> Solaris that are in
>>>>>>>> the multimedia class other than those associated with audio
>>>>>>>> support.
>>>>>>>>
>>>>>>>> 6. Resources and Schedule
>>>>>>>> 6.4. Steering Committee requested information
>>>>>>>> 6.4.1. Consolidation C-team Name:
>>>>>>>> ON
>>>>>>>> 6.5. ARC review type: FastTrack
>>>>>>>> 6.6. ARC Exposure: open
>>>>>>>>
>>>>>>>>
>>>>>>
>>>>
>>>>
>>>
>>
