From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail1.matrix-vision.com (mail1.matrix-vision.com [78.47.19.71]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "localhost", Issuer "localhost" (not verified)) by ozlabs.org (Postfix) with ESMTPS id 0C7E4B6EFE for ; Sat, 11 Sep 2010 04:14:52 +1000 (EST) Subject: Re: How to define an I2C-to-SPI bridge device ? From: =?ISO-8859-1?Q?Andr=E9?= Schwarz To: Grant Likely In-Reply-To: <20100910173706.GD11284@angua.secretlab.ca> References: <1283502979.17812.22.camel@swa-m460> <20100903120858.GA19380@oksana.dev.rtsoft.ru> <4C84D334.6060008@matrix-vision.de> <1284106293.2267.42.camel@swa-m460> <20100910173706.GD11284@angua.secretlab.ca> Content-Type: text/plain; charset="UTF-8" Date: Fri, 10 Sep 2010 20:14:44 +0200 Message-ID: <1284142484.2152.18.camel@swa-e6500> Mime-Version: 1.0 Cc: LinuxPPC List , DevTreeDiscuss List-Id: Linux on PowerPC Developers Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Grant, [snip] > > > > 1. > > The SC18IS602 is capable of generating interrupts which is *extremely* > > useful triggering on the end of the actual SPI transaction and not the > > end of I2C chip access. Since we need an IRQ_ACK over I2C (which takes > > loooong with IRQ being still asserted) I'm thinking about using an edge > > triggered interrupt. > > Since all transactions are in-order there's no risk of missing multiple > > edges ... what do you think about this ? Any known issues with edge > > triggered IRQs ? > > Does the device actually generate edge interrupts? Or is it a level > irq device? If it is a level irq device, then the correct way to > handle this is to disable the irq line so that the event can be > handled at non-irq context, and then reenable it when finished. The irq is level-low active. Will do it via disable/re-enable then. > > > 2. > > chips select generations is a little tricky. > > The device has up to four cs# lines with their assertion being encoded > > as subaddr representing a bitfield, i.e. Subaddr 0x01 generates cs0, > > 0x04 asserts cs3 and 0x07 asserts cs0-2. > > I'm really not sure what is tricky about this. The spi layer handles > multiple CS lines on a single bus just fine. huh - ok ... didn't know that, sorry. > > To start, how the CS lines are manipulated is only a hardware > implementation detail. The driver can and should do the work of > translate Linux CS line numbers into the format/bitfield expected by > the hardware. Other drivers do the same thing. ok - will do it. > > > At first I thought about registering 4 SPI busses representing the 4 cs# > > lines and hide the cs# generation from the user. This would make > > multiple cs# assertions for a single write impossible which is a very > > useful feature. > > The SPI subsystem doesn't directly support this use-case. If you want > to do this, then assign another chip select number for the purpose of > enabling multiple CS lines at once... and be careful which drivers you > allow to be bound to the oddball CS number. The in-kernel drivers > certainly don't support this use-case, and care must be taken to > ensure only one device is writing to the input line at a time. > > What specific hardware do you need this feature for? We have a board with multiple parallel video transmitters connected to an FPGA. Video timing and general parameters are always the same and there are quite a lot of settings to write during init/mode change. Doing this in parallel will speed things up significantly. Of course this is a write-only scenario, i.e. no combined reads. > > > Exposing the desired cs# setting for the next transaction via sysfs or > > libGPIO requires the user to serialize cs# config and actual SPI > > read/write. I also wouldn't know how to properly present the cs# lines > > from multiple chips to the user in a clear and unambiguous way. > > Exposing via sysfs or discrete GPIO manipulations is completely the > wrong thing to do. Thanks for pointing this out. BTW: would "drivers/misc" be a proper location ? Who's supposed to pick that driver up and on what list shall I post it for review ? Will try to get more spi knowledge before moving on and asking stupid questions. Thanks for your help so far. Regards, André MATRIX VISION GmbH, Talstrasse 16, DE-71570 Oppenweiler Registergericht: Amtsgericht Stuttgart, HRB 271090 Geschaeftsfuehrer: Gerhard Thullner, Werner Armingeon, Uwe Furtner From mboxrd@z Thu Jan 1 00:00:00 1970 From: =?ISO-8859-1?Q?Andr=E9?= Schwarz Subject: Re: How to define an I2C-to-SPI bridge device ? Date: Fri, 10 Sep 2010 20:14:44 +0200 Message-ID: <1284142484.2152.18.camel@swa-e6500> References: <1283502979.17812.22.camel@swa-m460> <20100903120858.GA19380@oksana.dev.rtsoft.ru> <4C84D334.6060008@matrix-vision.de> <1284106293.2267.42.camel@swa-m460> <20100910173706.GD11284@angua.secretlab.ca> Mime-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Return-path: In-Reply-To: <20100910173706.GD11284-MrY2KI0G/OVr83L8+7iqerDks+cytr/Z@public.gmane.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: devicetree-discuss-bounces+gldd-devicetree-discuss=m.gmane.org-uLR06cmDAlY/bJ5BZ2RsiQ@public.gmane.org Errors-To: devicetree-discuss-bounces+gldd-devicetree-discuss=m.gmane.org-uLR06cmDAlY/bJ5BZ2RsiQ@public.gmane.org To: Grant Likely Cc: LinuxPPC List , DevTreeDiscuss , Anton Vorontsov List-Id: devicetree@vger.kernel.org R3JhbnQsCgpbc25pcF0KPiA+IAo+ID4gMS4KPiA+IFRoZSBTQzE4SVM2MDIgaXMgY2FwYWJsZSBv ZiBnZW5lcmF0aW5nIGludGVycnVwdHMgd2hpY2ggaXMgKmV4dHJlbWVseSoKPiA+IHVzZWZ1bCB0 cmlnZ2VyaW5nIG9uIHRoZSBlbmQgb2YgdGhlIGFjdHVhbCBTUEkgdHJhbnNhY3Rpb24gYW5kIG5v dCB0aGUKPiA+IGVuZCBvZiBJMkMgY2hpcCBhY2Nlc3MuIFNpbmNlIHdlIG5lZWQgYW4gSVJRX0FD SyBvdmVyIEkyQyAod2hpY2ggdGFrZXMKPiA+IGxvb29vbmcgd2l0aCBJUlEgYmVpbmcgc3RpbGwg YXNzZXJ0ZWQpIEknbSB0aGlua2luZyBhYm91dCB1c2luZyBhbiBlZGdlCj4gPiB0cmlnZ2VyZWQg aW50ZXJydXB0Lgo+ID4gU2luY2UgYWxsIHRyYW5zYWN0aW9ucyBhcmUgaW4tb3JkZXIgdGhlcmUn cyBubyByaXNrIG9mIG1pc3NpbmcgbXVsdGlwbGUKPiA+IGVkZ2VzIC4uLiB3aGF0IGRvIHlvdSB0 aGluayBhYm91dCB0aGlzID8gQW55IGtub3duIGlzc3VlcyB3aXRoIGVkZ2UKPiA+IHRyaWdnZXJl ZCBJUlFzID8KPiAKPiBEb2VzIHRoZSBkZXZpY2UgYWN0dWFsbHkgZ2VuZXJhdGUgZWRnZSBpbnRl cnJ1cHRzPyAgT3IgaXMgaXQgYSBsZXZlbAo+IGlycSBkZXZpY2U/ICBJZiBpdCBpcyBhIGxldmVs IGlycSBkZXZpY2UsIHRoZW4gdGhlIGNvcnJlY3Qgd2F5IHRvCj4gaGFuZGxlIHRoaXMgaXMgdG8g ZGlzYWJsZSB0aGUgaXJxIGxpbmUgc28gdGhhdCB0aGUgZXZlbnQgY2FuIGJlCj4gaGFuZGxlZCBh dCBub24taXJxIGNvbnRleHQsIGFuZCB0aGVuIHJlZW5hYmxlIGl0IHdoZW4gZmluaXNoZWQuCgpU aGUgaXJxIGlzIGxldmVsLWxvdyBhY3RpdmUuCldpbGwgZG8gaXQgdmlhIGRpc2FibGUvcmUtZW5h YmxlIHRoZW4uCgo+IAo+ID4gMi4KPiA+IGNoaXBzIHNlbGVjdCBnZW5lcmF0aW9ucyBpcyBhIGxp dHRsZSB0cmlja3kuCj4gPiBUaGUgZGV2aWNlIGhhcyB1cCB0byBmb3VyIGNzIyBsaW5lcyB3aXRo IHRoZWlyIGFzc2VydGlvbiBiZWluZyBlbmNvZGVkCj4gPiBhcyBzdWJhZGRyIHJlcHJlc2VudGlu ZyBhIGJpdGZpZWxkLCBpLmUuIFN1YmFkZHIgMHgwMSBnZW5lcmF0ZXMgY3MwLAo+ID4gMHgwNCBh c3NlcnRzIGNzMyBhbmQgMHgwNyBhc3NlcnRzIGNzMC0yLgo+IAo+IEknbSByZWFsbHkgbm90IHN1 cmUgd2hhdCBpcyB0cmlja3kgYWJvdXQgdGhpcy4gIFRoZSBzcGkgbGF5ZXIgaGFuZGxlcwo+IG11 bHRpcGxlIENTIGxpbmVzIG9uIGEgc2luZ2xlIGJ1cyBqdXN0IGZpbmUuCgpodWggLSBvayAuLi4g ZGlkbid0IGtub3cgdGhhdCwgc29ycnkuCgo+IAo+IFRvIHN0YXJ0LCBob3cgdGhlIENTIGxpbmVz IGFyZSBtYW5pcHVsYXRlZCBpcyBvbmx5IGEgaGFyZHdhcmUKPiBpbXBsZW1lbnRhdGlvbiBkZXRh aWwuICBUaGUgZHJpdmVyIGNhbiBhbmQgc2hvdWxkIGRvIHRoZSB3b3JrIG9mCj4gdHJhbnNsYXRl IExpbnV4IENTIGxpbmUgbnVtYmVycyBpbnRvIHRoZSBmb3JtYXQvYml0ZmllbGQgZXhwZWN0ZWQg YnkKPiB0aGUgaGFyZHdhcmUuICBPdGhlciBkcml2ZXJzIGRvIHRoZSBzYW1lIHRoaW5nLgoKb2sg LSB3aWxsIGRvIGl0LgoKPiAKPiA+IEF0IGZpcnN0IEkgdGhvdWdodCBhYm91dCByZWdpc3Rlcmlu ZyA0IFNQSSBidXNzZXMgcmVwcmVzZW50aW5nIHRoZSA0IGNzIwo+ID4gbGluZXMgYW5kIGhpZGUg dGhlIGNzIyBnZW5lcmF0aW9uIGZyb20gdGhlIHVzZXIuIFRoaXMgd291bGQgbWFrZQo+ID4gbXVs dGlwbGUgY3MjIGFzc2VydGlvbnMgZm9yIGEgc2luZ2xlIHdyaXRlIGltcG9zc2libGUgd2hpY2gg aXMgYSB2ZXJ5Cj4gPiB1c2VmdWwgZmVhdHVyZS4KPiAKPiBUaGUgU1BJIHN1YnN5c3RlbSBkb2Vz bid0IGRpcmVjdGx5IHN1cHBvcnQgdGhpcyB1c2UtY2FzZS4gIElmIHlvdSB3YW50Cj4gdG8gZG8g dGhpcywgdGhlbiBhc3NpZ24gYW5vdGhlciBjaGlwIHNlbGVjdCBudW1iZXIgZm9yIHRoZSBwdXJw b3NlIG9mCj4gZW5hYmxpbmcgbXVsdGlwbGUgQ1MgbGluZXMgYXQgb25jZS4uLiBhbmQgYmUgY2Fy ZWZ1bCB3aGljaCBkcml2ZXJzIHlvdQo+IGFsbG93IHRvIGJlIGJvdW5kIHRvIHRoZSBvZGRiYWxs IENTIG51bWJlci4gIFRoZSBpbi1rZXJuZWwgZHJpdmVycwo+IGNlcnRhaW5seSBkb24ndCBzdXBw b3J0IHRoaXMgdXNlLWNhc2UsIGFuZCBjYXJlIG11c3QgYmUgdGFrZW4gdG8KPiBlbnN1cmUgb25s eSBvbmUgZGV2aWNlIGlzIHdyaXRpbmcgdG8gdGhlIGlucHV0IGxpbmUgYXQgYSB0aW1lLgo+IAo+ IFdoYXQgc3BlY2lmaWMgaGFyZHdhcmUgZG8geW91IG5lZWQgdGhpcyBmZWF0dXJlIGZvcj8KCldl IGhhdmUgYSBib2FyZCB3aXRoIG11bHRpcGxlIHBhcmFsbGVsIHZpZGVvIHRyYW5zbWl0dGVycyBj b25uZWN0ZWQgdG8KYW4gRlBHQS4gVmlkZW8gdGltaW5nIGFuZCBnZW5lcmFsIHBhcmFtZXRlcnMg YXJlIGFsd2F5cyB0aGUgc2FtZSBhbmQKdGhlcmUgYXJlIHF1aXRlIGEgbG90IG9mIHNldHRpbmdz IHRvIHdyaXRlIGR1cmluZyBpbml0L21vZGUgY2hhbmdlLgoKRG9pbmcgdGhpcyBpbiBwYXJhbGxl bCB3aWxsIHNwZWVkIHRoaW5ncyB1cCBzaWduaWZpY2FudGx5LgoKT2YgY291cnNlIHRoaXMgaXMg YSB3cml0ZS1vbmx5IHNjZW5hcmlvLCBpLmUuIG5vIGNvbWJpbmVkIHJlYWRzLgoKPiAKPiA+IEV4 cG9zaW5nIHRoZSBkZXNpcmVkIGNzIyBzZXR0aW5nIGZvciB0aGUgbmV4dCB0cmFuc2FjdGlvbiB2 aWEgc3lzZnMgb3IKPiA+IGxpYkdQSU8gcmVxdWlyZXMgdGhlIHVzZXIgdG8gc2VyaWFsaXplIGNz IyBjb25maWcgYW5kIGFjdHVhbCBTUEkKPiA+IHJlYWQvd3JpdGUuIEkgYWxzbyB3b3VsZG4ndCBr bm93IGhvdyB0byBwcm9wZXJseSBwcmVzZW50IHRoZSBjcyMgbGluZXMKPiA+IGZyb20gbXVsdGlw bGUgY2hpcHMgdG8gdGhlIHVzZXIgaW4gYSBjbGVhciBhbmQgdW5hbWJpZ3VvdXMgd2F5Lgo+IAo+ IEV4cG9zaW5nIHZpYSBzeXNmcyBvciBkaXNjcmV0ZSBHUElPIG1hbmlwdWxhdGlvbnMgaXMgY29t cGxldGVseSB0aGUKPiB3cm9uZyB0aGluZyB0byBkby4KClRoYW5rcyBmb3IgcG9pbnRpbmcgdGhp cyBvdXQuCgoKQlRXOiB3b3VsZCAiZHJpdmVycy9taXNjIiBiZSBhIHByb3BlciBsb2NhdGlvbiA/ CldobydzIHN1cHBvc2VkIHRvIHBpY2sgdGhhdCBkcml2ZXIgdXAgYW5kIG9uIHdoYXQgbGlzdCBz aGFsbCBJIHBvc3QgaXQKZm9yIHJldmlldyA/CgoKV2lsbCB0cnkgdG8gZ2V0IG1vcmUgc3BpIGtu b3dsZWRnZSBiZWZvcmUgbW92aW5nIG9uIGFuZCBhc2tpbmcgc3R1cGlkCnF1ZXN0aW9ucy4gVGhh bmtzIGZvciB5b3VyIGhlbHAgc28gZmFyLgoKClJlZ2FyZHMsCkFuZHLDqQoKCgpNQVRSSVggVklT SU9OIEdtYkgsIFRhbHN0cmFzc2UgMTYsIERFLTcxNTcwIE9wcGVud2VpbGVyClJlZ2lzdGVyZ2Vy aWNodDogQW10c2dlcmljaHQgU3R1dHRnYXJ0LCBIUkIgMjcxMDkwCkdlc2NoYWVmdHNmdWVocmVy OiBHZXJoYXJkIFRodWxsbmVyLCBXZXJuZXIgQXJtaW5nZW9uLCBVd2UgRnVydG5lcgpfX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwpkZXZpY2V0cmVlLWRpc2N1 c3MgbWFpbGluZyBsaXN0CmRldmljZXRyZWUtZGlzY3Vzc0BsaXN0cy5vemxhYnMub3JnCmh0dHBz Oi8vbGlzdHMub3psYWJzLm9yZy9saXN0aW5mby9kZXZpY2V0cmVlLWRpc2N1c3MK