From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from gate.crashing.org (gate.crashing.org [63.228.1.57]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by ozlabs.org (Postfix) with ESMTP id D6DE267B54 for ; Sat, 17 Jun 2006 08:13:28 +1000 (EST) Subject: Re: MSI support on Linux PCI implementation for Ocotea From: Benjamin Herrenschmidt To: Shawn Jin In-Reply-To: References: <1150413771.7725.20.camel@localhost.localdomain> Content-Type: text/plain Date: Sat, 17 Jun 2006 08:13:17 +1000 Message-Id: <1150495997.23600.52.camel@localhost.localdomain> Mime-Version: 1.0 Cc: ppcdev List-Id: Linux on PowerPC Developers Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , On Fri, 2006-06-16 at 14:45 -0700, Shawn Jin wrote: > Hi Ben, > > > Now, regarding MSI, as you have noticed, the situation isn't great. I'm > > currently in the middle of reworking our interrupt management (and > > interrupt numbers allocation layer) and Michael Ellermann is looking at > > the MSI issue in parallel. > > Just one point about MSI(-X) message address and data format. I think > it should be the platform that defines the content. That's an obvious requirement :) > Current > implementation doesn't have this flexibility. We have a design where > MSI mode uses message data to carry vector number info while MSI-X > mode uses message address to carry this info. Although it seems > strange, but I think it's allowed by the spec. The current implementation is bad :) There are some patches for altix that are in -mm that add some platform hooks that make the situation a little bit better, but it's still far from perfect. Ben.