On 8/14/07, Leonid <[EMAIL PROTECTED]> wrote: > I deem such approach is not very good one. I'm using precisely same IP > cores like GPIO, EMAC, SPI, CAN, etc... in Virtex and Spartan FPGAs > which means (OK, may be cores are different somewhat for different FPGAs > but low level Xilinx code is the same). That means at least 2 different > CPU architectures (PPC and Microblaze).
The driver code should all be in platform independent locations. Only the ppc405 support code lives in arch/ppc. For ublaze support, you need to look at the ublaze mailing list. > > You certainly gave thought to such an issue. What tree structure do you > suggest? There are 3 groups of Xilinx files to place in the Linux tree: > > - common .h files (like xbasic_types.h); Common include files go in include/linux. However, the xilinx os-independent files are a stopgap measure. They will probably never be merged into the mainline Linux source tree. > - common .c files, used by several cores (like all DMA stuff). I think we've agreed that drivers/misc is a suitable location. > - specific core .h/.c files (say xemac.h and xemac.c). Eth drivers go under drivers/net serial drivers go under drivers/serial i2c drivers go under drivers/i2c etc. > They all kind of "architecture independent" (at least 2 architectures > can be used - MB and PPC). Many of the drivers already are arch independent. A key feature of this is that xilinx ip drivers should *not* make use of xparameters.h directly. Which drivers are you having trouble with? > Of course, except tree structure there are several other (not completely > independent) questions to answer like: > > A How EDK project parameters get into Linux kernel? This is huge issue > which can be divided on several items. In arch/ppc (depreciated), via platform bus registrations. The platform bus is populated via arch/ppc/platforms/4xx/xparameters/xparameters.h In arch/powerpc, via a device tree blob. The device tree blob will be generated from the EDK project. in microblaze, I believe it is currently via platform bus registrations like in arch/ppc, but there is desire to move to using the arch/powerpc device tree also. > > A.1. Do you also suppose that some special type of BSP (.tcl script, > defined by OS parameter of MSS file) shall run or you assume that it > will be regular xaparameters.h file, prepared by standard standalone > BSP? In latter case xparamerts.h needs manual editing since it doesn't > have all parameters required by certain cores. > > A.2. There is also a question how these definitions get into .c and Make > files. Petalogix has interesting solution when they bump all XILINX > parameters to autoconf.h and .config files thus making them available > for both compiler and make. What's your approach? Just to reinforce my point: xilinx device drivers should *NEVER* use xparameters.h directly. The device driver binding code should either retrieve the device configuration from the platform bus or from the device tree. > > A.3. If .config is not prepared automatically, then all configuration > must be done via "make menuconfig" meaning Kconfig files shall be > modified. Do you intend having several FPGA flags like CONFIG_VIRTEX and > CONFIG_SPARTAN? Drivers' inclusion will depend on one of them. Yes, some of them even already exist! :-) There can also be some defconfigs for supported boards. > > A.4. Is it assumed that Xilinx low level code will stay intact as it is > supplied with EDK package or you are going to prepare special Linux > Xilinx set (mostly because of name convention)? No. The xilinx EDK drivers are not desirable for inclusion in mainline. Slowly the drivers are being replaced with Linux specific drivers. New uartlite, ns16550, xsysace and framebuffer drivers are already in mainline. > > B How drivers get registered - via platform devices structure in > virtex.c file or something different? Read up on 'platform bus' and 'of platform bus'. platform bus is what works now. of platform bus is how it will work when we migrate to arch/powerpc. > > All these questions have been discussed by the community but I somehow > missed a conclusion if any took place. Does anything (kind of memo or > readme) exist on these subjects? Unfortunately, no. -- Grant Likely, B.Sc., P.Eng. Secret Lab Technologies Ltd. [EMAIL PROTECTED] (403) 399-0195 _______________________________________________ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded