From mboxrd@z Thu Jan 1 00:00:00 1970 From: Charles Keepax Subject: Re: Fwd: [PATCH 1/1] SPI : spi-pxa2xx : fix spi init of WM510205 codec via ACPI (resend) Date: Wed, 26 Aug 2015 10:13:12 +0100 Message-ID: <20150826091312.GA19411@ck-lbox> References: <20150820115845.GF30005@lahna.fi.intel.com> <20150821074310.GM30005@lahna.fi.intel.com> <20150824085140.GA5647@ck-lbox> <20150825062157.GB27431@sirena.org.uk> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Cc: alsa-devel@alsa-project.org, Mika Westerberg , Pierre-Louis Bossart , Haojian Zhuang , linux-spi@vger.kernel.org, Mark Brown , jarkko.nikula@linux.intel.com, Daniel Mack , Robert Jarzmik , dan.carpenter@oracle.com To: Christian Hartmann Return-path: Content-Disposition: inline In-Reply-To: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: alsa-devel-bounces@alsa-project.org Sender: alsa-devel-bounces@alsa-project.org List-Id: linux-spi.vger.kernel.org On Wed, Aug 26, 2015 at 10:58:06AM +0200, Christian Hartmann wrote: > Hi at all, > > > the current logs shows me, that something else is missing here. > The spi irq is one of the issues I will try to solve today > > Looking at the read_regmap() where it reads its device id, > I do not understand why it gots only an ID of 0xffff ! I would probably focus on getting the device ID to read back first. The interrupts aren't that important until you can talk to the device and the interrupt setup won't have any effect on being able to talk to the device. > > I have (silly or not), added a case for 0xffff in the next switch > statements but anyway this seems not okay. > I do not know what else (other than the wrong or missing spi irq, > which is currently only -1) Yeah adding a case for 0xffff probably won't help much as this likely means that the device isn't responding at all when you are talking to it, so you can't really do anything meaningful when you get past reading the ID register anyway. Basically to be able to talk to the device you need the following things: 1) The supplies need to be applied. 2) The device needs to be out of reset. 3) The device needs to have the LDO enabled. 4) The chip select needs to be active. It seems very likely that 1) is already taken care of, so I probalby won't spend too much time worrying about that. It looks like we are getting a valid GPIO for the reset (2) and LDOENA (3), so it feels like those are probably ok. I guess this leaves the SPI config as the next place to investigate, are there other devices on the SPI that you can talk to that might at least verify the SPI is working? Also might be worth trying to look at how the chip selects are done perhaps that is not happening for some reason? Thanks, Charles