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
>>>>>>
>>>>>>
>>>>
>>
>>
>
