On Mon, Jan 20, 2014 at 10:06 AM, Greg KH <gregkh@xxxxxxxxxxxxxxxxxxx> wrote: > On Mon, Jan 20, 2014 at 09:16:08AM -0800, Insop Song wrote: >> >> >> >> On the FPGA side, there are dedicated pins for programming, and >> >> through these you cannot get meaningful information (again unless you >> >> are JTAG capable) >> >> Such as these on the FPGA side, PROGRAM_B, INIT_B, CCLK, D[0:7], and DONE. >> >> On a process side, we use gpio pin to connect to the above pins. >> >> It's GPIO pins that we do the bit banging as defined for programming >> >> guide from Xilinx. >> > >> > Yes, but where do you learn about how those pins are hooked up to the >> > CPU so that the driver can control them? >> > >> This is hard coded. > > Really? Shouldn't they be in a board file or device tree attribute > somewhere? What happens in the next board that is created with this > chip and the memory locations are in a different place? > I think the same, as I put in "TODO" file is alluding that. +TODO: + - get bus width input instead of hardcoded bus width I said "bus width," but this includes fpga programming method (bus width and pin configuration, gpio or any other types) can be either "insmod" parameter or device tree (as you suggested). Give me some time to think about this, meanwhile I might hear from other people as well soon as this driver is parked in upstream staging area. Thank you again, ISS _______________________________________________ devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxx http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
