Message-ID: <14d97ec12ae.121e65c4b780118.1307005790953163680@elphel.com>
Date:	Wed, 27 May 2015 17:29:00 -0700
From:	andrey <andrey@...hel.com>
To:	Guenter Roeck <linux@...ck-us.net>
Cc:	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 Wed, 27 May 2015 17:10:06 -0700 Guenter Roeck<linux@...ck-us.net> wrote ---- 
 > On 05/27/2015 04:58 PM, andrey wrote: 
 > > 
 > > 
 > > ---- On Wed, 27 May 2015 16:08:12 -0700 Guenter Roeck<linux@...ck-us.net> 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. 

Guenter,

I just considered this chip as a "frontier" device, not yet a member of an established
class of similar ones. It may be possible to generalize later, extracting common
functionality to a more abstract interface. But we just need this device support now,
and when this one will become a member of some generic class - "frontier" will again
move a step farther, new devices will emerge that stick out of the nice frameworks.

Andrey

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


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