Messages in this thread | | | Date | Thu, 16 May 2013 10:44:16 -0400 | From | Philip Balister <> | Subject | Re: [PATCH RFC] clk: Introduce userspace clock driver |
| |
On 05/16/2013 12:28 AM, Saravana Kannan wrote: > On 05/14/2013 09:46 PM, Mark Brown wrote: >> On Tue, May 14, 2013 at 02:09:47PM -0400, Philip Balister wrote: >> >>> First of all, the driver that loads the bitstream into the fpga >>> fabric does not know ANYTHING about what the bitstream does. So it >>> cannot do any setup based on the contents of the file that is >>> loaded. (And this can also be loaded during the SoC bootup, >>> bypassing this driver completely) >> >> This is a problem that is going to need to be fixed - there will be some >> things going on the FPGAs that do need drivers and so there needs to be >> some way to instantiate a driver for a FPGA image. Things like adding >> extra DT blobs along with the FPGA image have been talked about >> >>> Second, there are four clocks that feed the FPGA fabric. We will >>> want to set these clocks from user space somehow. It is perfectly >>> valid to use a uio driver to interface with logic in the fpga. If we >>> take the approach of using such general purpose techniques to >>> interface with fpga logic, we must have ways for the user to control >>> the fpga clocks. >> >> Right, and if the specific device is being controlled by UIO then having >> UIO create some clocks makes sense but then that should be integrated >> into the UIO instantiation rather than done as a separate thing. > > Agreed. I was about to reply with exactly the same point. I haven't done > any UIO coding, but that device file will eventually have to be opened. > Turn on the clocks in the open and turn them off at close. > > Rate to request can be a DT property.
But you are assuming each device implemented in the fpga uses one clock. This assumption is clearly not valid since devices will ahve to share clocks.
Philip
| |