On Tue, Jan 21, 2014 at 02:08:53AM -0800, Insop Song wrote: > On Mon, Jan 20, 2014 at 10:06 AM, Greg KH <gre...@linuxfoundation.org> 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.
Fair enough, I'll queue it up after 3.14-rc1 is out. thanks, greg k-h _______________________________________________ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
