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: <20160428144607.191a29f2@bbrezillon>
Date:	Thu, 28 Apr 2016 14:46:07 +0200
From:	Boris Brezillon <boris.brezillon@...e-electrons.com>
To:	Jean-Jacques Hiblot <jjhiblot@...phandler.com>,
	Nicolas Ferre <nicolas.ferre@...el.com>,
	Rob Herring <robh+dt@...nel.org>,
	Alexandre Belloni <alexandre.belloni@...e-electrons.com>,
	Kumar Gala <galak@...eaurora.org>,
	Jean-Christophe Plagniol-Villard <plagnioj@...osoft.com>
Cc:	Mark Rutland <mark.rutland@....com>,
	devicetree <devicetree@...r.kernel.org>,
	Arnd Bergmann <arnd@...db.de>, Pawel Moll <pawel.moll@....com>,
	Ian Campbell <ijc+devicetree@...lion.org.uk>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	"linux-arm-kernel@...ts.infradead.org" 
	<linux-arm-kernel@...ts.infradead.org>
Subject: Re: [PATCH v6 2/2] memory: atmel-ebi: add DT bindings documentation

On Thu, 28 Apr 2016 14:18:25 +0200
Jean-Jacques Hiblot <jjhiblot@...phandler.com> wrote:
> >> > +
> >> > +- atmel,ncs-rd-setup-ns
> >> > +- atmel,nrd-setup-ns
> >> > +- atmel,ncs-wr-setup-ns
> >> > +- atmel,nwe-setup-ns
> >> > +- atmel,ncs-rd-pulse-ns
> >> > +- atmel,nrd-pulse-ns
> >> > +- atmel,ncs-wr-pulse-ns
> >> > +- atmel,nwe-pulse-ns
> >> > +- atmel,nwe-cycle-ns
> >> > +- atmel,nrd-cycle-ns
> >> > +- atmel,tdf-ns  
> >>
> >> One thought about the configuration in 'ns' unit: Some devices may
> >> have requirements expressed in clock cycles (I'm thinking of FPGA
> >> here). At  a fixed frequency one can always convert manually from 'ns'
> >> to 'clocks' but it's a bit tedious and prone to rounding errors. And
> >> It 'll  break when the EBI frequency is changed  
> >
> > If you don't mind, I'd like to first get this version accepted, and
> > we'll extend it with timings expressed in clock cycles afterward.
> >
> > BTW, could you describe a real use case where timings should be
> > expressed in clock cycles? I mean, usually the devices have some timing
> > constraints (tXX_min = Y ns), and I don't see why it would differ for
> > FPGA interfaces, but I'm clearly not an FPGA expert.  
> 
> I'm not either, I only toyed with FPGA. That's just what experienced
> FPGA designer told me.
> I guess that it boils down to: FPGA are more suited for a synchronous
> design than an asynchronous one.

The thing is, all the timings are based on the master clock, and,
AFAICS, this clk signal is not exposed, so you're basing your clk-cycle
based timings on something that can change depending on how the
bootstrap/bootloader decided to configure the master clk.

One option would be to define one of the timing as the reference,
define this one in nanosecond, and define the other ones as multiple of
the reference timing. But I'm not sure it's easier to do that than
defining all the timings directly in nanoseconds.

-- 
Boris Brezillon, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ