Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752637AbcDULHq (ORCPT ); Thu, 21 Apr 2016 07:07:46 -0400 Received: from comal.ext.ti.com ([198.47.26.152]:53989 "EHLO comal.ext.ti.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751555AbcDULHn (ORCPT ); Thu, 21 Apr 2016 07:07:43 -0400 From: "Reizer, Eyal" To: Mark Brown CC: "kvalo@codeaurora.org" , =?utf-8?B?77+977+977+977+9IO+/ve+/ve+/ve+/ve+/vQ==?= , "linux-wireless@vger.kernel.org" , "netdev@vger.kernel.org" , "linux-kernel@vger.kernel.org" , "devicetree@vger.kernel.org" , "linux-spi@vger.kernel.org" Subject: RE: [PATCHv2] wlcore: spi: add wl18xx support Thread-Topic: [PATCHv2] wlcore: spi: add wl18xx support Thread-Index: AQHRkvs3tFwJpRa2nU+to3p0n+8ju5+C0KzggAvWT4CAAJzFUIAAeeSAgAFQdyCAAGfBgIAAI90S///gLACAACSWE///4vEAgAAki0f//+oagABYav5Q Date: Thu, 21 Apr 2016 11:07:37 +0000 Message-ID: <8665E2433BC68541A24DFFCA87B70F5B360C2E14@DFRE01.ent.ti.com> References: <14313437.cDJIgY3kzo@wuerfel> <8665E2433BC68541A24DFFCA87B70F5B360BF614@DFRE01.ent.ti.com> <1463330011.BhWEcYYuGD@wuerfel> <8665E2433BC68541A24DFFCA87B70F5B360C0745@DFRE01.ent.ti.com> <20160419171239.GC3217@sirena.org.uk> <20160419172706.GD3217@sirena.org.uk> <20160419175402.GE3217@sirena.org.uk> <20160419184627.GG3217@sirena.org.uk> In-Reply-To: <20160419184627.GG3217@sirena.org.uk> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.167.188.42] x-exclaimer-md-config: f9c360f5-3d1e-4c3c-8703-f45bf52eff6b Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by mail.home.local id u3LB7n1E008721 Content-Length: 1490 Lines: 33 > > > Thanks! Glad the illustration helped. > > I will try it out again as if i recall cotrectly, i did try that l, and it didnt produce > the correct waveform, but perhaps i didnt understand the usage of > .cs_change correctly. > > Will double check anyway. > > It could also be a bug in your controller driver, it's common for them to not > handle cs_change correctly (at least those that open code the message loop, > obviously modern ones just factor this out into the core). Tried looking into using cs_change and not sure I understand how it would do what I need. According to, include/linux/spi/spi.h: * All SPI transfers start with the relevant chipselect active. Normally * it stays selected until after the last transfer in a message. Drivers * can affect the chipselect signal using cs_change. * * (i) If the transfer isn't the last one in the message, this flag is * used to make the chipselect briefly go inactive in the middle of the * message. Toggling chipselect in this way may be needed to terminate * a chip command, letting a single spi_message perform all of group of * chip transactions together. Now, in my case I need the CS pin to go inactive and stay inactive during the transfer of the next byte for completing the SPI init correctly (sending the extra clock cycles while CS is inactive) If I read the above correctly, CS will only briefly go inactive but will when the next byte is sent it will be active again. What am I missing? Best Regards, Eyal