linux-kernel - Re: [PATCH v3] clk: add si5351 i2c common clock driver

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <5149E85E.90701@gmail.com>
Date:	Wed, 20 Mar 2013 17:48:30 +0100
From:	Daniel Mack <zonque@...il.com>
To:	michal.bachraty@...il.com
CC:	fa.linux.kernel@...glegroups.com,
	Mike Turquette <mturquette@...aro.org>,
	Grant Likely <grant.likely@...retlab.ca>,
	Rob Herring <rob.herring@...xeda.com>,
	Rob Landley <rob@...dley.net>,
	Stephen Warren <swarren@...dia.com>,
	Thierry Reding <thierry.reding@...onic-design.de>,
	Dom Cobley <popcornmix@...il.com>,
	Linus Walleij <linus.walleij@...aro.org>,
	Arnd Bergmann <arnd@...db.de>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Russell King - ARM Linux <linux@....linux.org.uk>,
	Rabeeh Khoury <rabeeh@...id-run.com>,
	Jean-Francois Moine <moinejf@...e.fr>,
	devicetree-discuss@...ts.ozlabs.org, linux-doc@...r.kernel.org,
	linux-kernel@...r.kernel.org, linux-arm-kernel@...ts.infradead.org
Subject: Re: [PATCH v3] clk: add si5351 i2c common clock driver

Hi Michal,

On 20.03.2013 14:55, michal.bachraty@...il.com wrote:
> Thanks for writing this driver! I have tested your si5351 clock 
> driver and his tuning capabilities. It works well, it generates 
> proper clock frequency, but when new frequency is generated, little 
> clock gap (1ms) is generated. Si5351 datasheet and WP claims, clock 
> tuning can be without gaps - 
> http://www.silabs.com/Support%20Documents/TechnicalDocs/Si5350-51-Frequency-Shifting-WP.pdf
>
> I made some tests with Si5351A chip and I found that when tuning touch
> only Multisynth registers, it can tune without gaps. There is no need
> for soft PLL reset. I found also, accessing Multisynth registers is not
> atomic, so there can be another frequency at output, while not all
> registers are written. Writing only to one register seems to be atomic.

Yeah, but limiting possible changes to the PLLs to one single register
also means that you cannot offer to generate all the frequencies any
more. What could probably be done is refine the algorithm so that it
stays 'as close as possible' to the former values, but I'm not sure how
much work that implies.

Can you provide a patch against Sebastian's v3 to do that? Then it can
be cleanly applied on top of the driver later.


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