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-i2c" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
