Re: clock driver

[Guenter Roeck <linux-0h96xk9xTtrk1uMJSBkQmQ@public.gmane.org>]

On 05/27/2015 04:58 PM, andrey wrote:
>
>
> ---- On Wed, 27 May 2015 16:08:12 -0700 Guenter Roeck<linux-0h96xk9xTtrk1uMJSBkQmQ@public.gmane.org> wrote ----
>
>   > 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 scripts.
>   > >
>   > > 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.
>
> Guenter, I'm sorry for using "rich text" email settings.
>
>   >
>   > 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).
>
> I was trying to make it safer to use low-level functionality of the particular
> (and rather popular) clock chip and to avoid using SiLabs proprietary tools to
> generate required settings offline. Using just raw i2c would require to have
> large user space program to calculate valid settings for the device.
>
> I would consider this chip as both a generic clock device that can fit into
> a standard framework and simultaneously a unique device that offers specific
> functionality outside of the framework. I thought that sysfs (instead of
> "old-fashioned" ioctl I used in such cases before) can offer
> hardware developer-friendly solution as a supplement to in-framework
> basic functionality.
>
> Device driver for this chip makes it possible to avoid proprietary configuration
> software and calculate register settings at runtime, minimizing requirements to
> the user space software and so the time developers of the new embedded
> systems will need to (re-)implement these important chip-specific  features.
>

I think we are in violent agreement ;-). Only question was how to implement
sysfs (or user space access) support, where my preference would be a more
generic solution.

Thanks,
Guenter

> Andrey
>
>   >
>   > 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
>   >
>   >
>
>
>
>