From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 9830 invoked by alias); 14 Oct 2009 16:57:28 -0000 Received: (qmail 9816 invoked by uid 22791); 14 Oct 2009 16:57:27 -0000 X-SWARE-Spam-Status: No, hits=-2.0 required=5.0 tests=AWL,BAYES_00,UNPARSEABLE_RELAY X-Spam-Check-By: sourceware.org Received: from mx3.neotel.com.mk (HELO neomail.neotel.com.mk) (80.77.144.15) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Wed, 14 Oct 2009 16:57:24 +0000 Received: from dummy.name; Wed, 14 Oct 2009 18:57:24 +0200 Message-ID: <4AD602EC.8050503@siva.com.mk> Date: Wed, 14 Oct 2009 16:57:00 -0000 From: Ilija Stanislevik User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: Bart Veer , ecos-discuss@ecos.sourceware.org References: <4AD57670.9020705@siva.com.mk> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-IsSubscribed: yes Mailing-List: contact ecos-discuss-help@ecos.sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: ecos-discuss-owner@ecos.sourceware.org Subject: Re: [ECOS] Ethernet on top of SPI X-SW-Source: 2009-10/txt/msg00095.txt.bz2 Bart Veer wrote > The code which instantiates the cyg_spi_device object, typically the > platform HAL, should not care about how other code uses the device. > That other code may be your driver, some other driver, or application > code directly. It should simply make sure that the cyg_spi_device > object contains all the information needed by the SPI bus driver to > allow interaction with the physical device, i.e. polarity and phase > info, chip select wiring details, etc. > The details of this will depend > on the SPI bus driver. There should be no need to change any of these > settings by configury or at run-time. > > So, the way things are expected to work is that the platform HAL will > instantiate a cyg_spi_device object with a well-known name, e.g. > cyg_spi_enc424j600_0. All the hardware-specific details are encoded > inside that object. The ethernet driver will expect that something > else provides an object cyg_spi_enc424j600_0 If that expectation is > not met then you'll get a bunch of errors at compile-time. If you > prefer you can get the errors at configure-time by having a CDL > interface and constraints on that interface. The ethernet driver does > not need to worry about any of the hardware-specific details. > My idea is to produce an Ethernet-on-top-of-SPI driver which can be used on ANY particular SPI driver or, in other words, I wish if the low-level Ethernet driver does not care which SPI driver is below. This way I (or anyone) will be able to use the same low-level Ethernet driver with any SPI driver, without going into depths of specific SPI implementation. > If you take a look at devs/disk/generic/mmc, that code already works > along similar lines. The driver looks for a cyg_spi_device > cyg_spi_mmc_dev0. It is up to the platform HAL (usually) to > instantiate that object with the right settings. > > Bart > > Thank you for the comprehensive explanation and for directions. I find it very useful. Going to dig some code and manuals, Ilija Stanislevik SIvA doo Macedonia -- Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss