Date: Sun, 09 Feb 2014 22:17:23 +0100 From: Steven Lawrance <stl@koffein.net> To: Ian Lepore <ian@freebsd.org> Cc: freebsd-arm <freebsd-arm@freebsd.org> Subject: Re: i.MX6 on-die temperature sensor Message-ID: <1391979228-sup-7658@luwak.koffein.net> In-Reply-To: <1391897489.1196.60.camel@revolution.hippie.lan> References: <1391893231-sup-6174@luwak.koffein.net> <1391897489.1196.60.camel@revolution.hippie.lan>
next in thread | previous in thread | raw e-mail | index | archive | help
Excerpts from Ian Lepore's message of 2014-02-08 23:11:29 +0100: > On Sat, 2014-02-08 at 22:32 +0100, Steven Lawrance wrote: > > For the OCOTP (on-chip one-time-programmable memory) side of things, = I > > just followed the pattern in imx6_anatop.c, which is to provide publi= c > > methods for accessing its memory space. But it feels a bit dirty -- = I > > imagine there could be cases where you would have two similar blocks > > and things would fall apart. >=20 > The thing I did with anatop was a quick hack to get things going becaus= e > I have no idea what services that conglomeration of hardware needs to > provide to other entities (yet). ocotp is another thing I haven't > looked at much, but it might be easier to come up with a clean API it > can provide for other imx drivers. Well, without actually developing a product based on this SoC, I can't really foresee a need to write anything to the OTP memory, and, according to the docs, "all shadow registers are always readable through the APB bus except some secret keys regions" so there's probably no real urgency to implement reading directly from the fuses, either. I haven't had a good look to see if anything else interesting is written in there in production. --=20 Steven Lawrance stl@koffein.net
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1391979228-sup-7658>