[PATCH RFC] clk: Introduce userspace clock driver
philip at balister.org
Thu May 16 10:44:16 EDT 2013
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
More information about the linux-arm-kernel