From mboxrd@z Thu Jan 1 00:00:00 1970 From: Mark Brown Subject: Re: [PATCH 1/1] spi: intel_mid_ssp_spi: new SPI driver for intel Medfield platform Date: Thu, 3 Feb 2011 15:06:24 +0000 Message-ID: <20110203150624.GA23123@sirena.org.uk> References: <1296680512-2758-2-git-send-email-russ.gorby@intel.com> <20110202224054.7916e7af@lxorguk.ukuu.org.uk> <20110203132800.GA17825@sirena.org.uk> <20110203150432.40cd74c4@lxorguk.ukuu.org.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Russ Gorby , David Brownell , Grant Likely , "open list:SPI SUBSYSTEM" , open list To: Alan Cox Return-path: Content-Disposition: inline In-Reply-To: <20110203150432.40cd74c4@lxorguk.ukuu.org.uk> Sender: linux-kernel-owner@vger.kernel.org List-Id: linux-spi.vger.kernel.org On Thu, Feb 03, 2011 at 03:04:32PM +0000, Alan Cox wrote: > Mark Brown wrote: > > I've got the same question here as I had with Russ' patch: it looks like > > there's some overlap with the SSP ports used for audio (it's just a > > generic programmable serial port so even if it's not normally used for > > audio that's a possiblity), how is that handled? > The SSP has PCI configuration indicating how it is being assigned, which > is in vendor capability byte 6. The low 3 bits indicte the mode, where > mode 1 is an SPI master/slave, and in that case bit 6 is set for a slave. OK, cool - just checking as it's a common issue for these generic serial ports.