Date:	Wed, 27 May 2015 16:08:12 -0700
From:	Guenter Roeck <linux@...ck-us.net>
To:	andrey <andrey@...hel.com>,
	Michael Turquette <mturquette@...aro.org>,
	linux-i2c@...r.kernel.org, linux-kernel@...r.kernel.org,
	lee.jones@...aro.org, sebastian.hesselbarth@...il.com,
	rabeeh@...id-run.com, York Sun <yorksun@...escale.com>
Subject: Re: clock driver

On 05/27/2015 12:44 PM, andrey wrote:
> Hello all,
> Let me add a comment on using sysfs to simplify user space access to the clock features as opposed to controlling them from a driver that uses the clock chip driver.
>
> It is common to use such advanced clock chips with the FPGA devices (as me and York do), and a lot of development (HDL code) is done before a fancy higher-level driver is even started. And it is not just a temporary stage needed by a small minority of developers - as HDL coding gets more to the the core of many new devices running Linux kernel, it makes sense to create the chip drivers more developer-friendly, not just for the final use in a higher level device driver - modification of the HDL code (most modern FPGA are programmed at runtime) makes it a new device that may need a new driver.
> I'm sure that it is not just for me, when it starts with the chip driver that supports low-level functionality exposing it to the user space, and then working on the HDL code using Python scripts at that stage. And only later in the development designing the higher level device drivers that may not need all of the chip functionality. And such higher level driver will work for our systems, but other developers who work on their embedded systems will again need access to low level chip functionality, and will have to redo the same work all over again. This I believe is a rationale of exposing such chip-specific hardware features (not all of them are probably easy to fit into a specific standard model) to the user space scrtipts.
>
> I wrote the initial driver code for our system ( https://github.com/Elphel/linux-elphel/blob/master/src/drivers/misc/si5338.c ) and being very far from being a kernel developer myself (I'm more of a hardware guy) I didn't even try to satisfy the required coding style and submit it, so I'm very thankful to York who re-wrote the code and is trying to make it usable to others.
>

Line wraps at ~75 columns would make this a bet easier to read.

A more generic solution to your problem might be to implement a driver
similar to i2c-dev, which exports raw i2c device information to user space.
In your case, you would export information about the clocks in the system,
possibly through sysfs (i2c-dev uses ioctl which is a bit old-fashioned).

This would be a driver independent solution, and work for all clock drivers.
It might still not be accepted by Mike and Stephen, due to the risk, but it
might be worth a try. After all, using i2c-dev to access i2c devices directly
is just as risky.

In my opinion, it is always better to have a driver in the upstream kernel,
if possible one that uses a standard framework. That makes it much easier
to support going forward.

Guenter

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists