From: martinwguy@gmail.com (Martin Guy)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH v2 2/3] ep93xx: added chip revision reading function
Date: Sat, 20 Mar 2010 18:07:50 +0000 [thread overview]
Message-ID: <56d259a01003201107s758b420bmafa154714a8a8fee@mail.gmail.com> (raw)
In-Reply-To: <c222c3df9c94d9ec919817f640a953e4f45ae99b.1268930557.git.mika.westerberg@iki.fi>
On 3/18/10, Mika Westerberg <mika.westerberg@iki.fi> wrote:
> Added a new function: ep93xx_chip_revision() which reads chip revision from the
> sysconfig register.
>
> diff --git a/arch/arm/mach-ep93xx/core.c b/arch/arm/mach-ep93xx/core.c
> index 90fb591..07572bb 100644
> --- a/arch/arm/mach-ep93xx/core.c
> +++ b/arch/arm/mach-ep93xx/core.c
> @@ -222,6 +222,20 @@ void ep93xx_devcfg_set_clear(unsigned int set_bits, unsigned int clear_bits)
> }
> EXPORT_SYMBOL(ep93xx_devcfg_set_clear);
>
> +/**
> + * ep93xx_chip_revision() - returns the EP93xx chip revision
> + *
> + * See <mach/platform.h> for more information.
> + */
> +unsigned int ep93xx_chip_revision(void)
> +{
> + unsigned int v;
> +
> + v = __raw_readl(EP93XX_SYSCON_SYSCFG);
> + v &= EP93XX_SYSCON_SYSCFG_REV_MASK;
> + v >>= EP93XX_SYSCON_SYSCFG_REV_SHIFT;
> + return v;
> +}
The chip revision is normally placed in the global unsigned int
"system_rev", which is also reported by /proc/cpuinfo.
It normally seems to be set from the atags passed by the bootloader
but uboot on this platform doesn't provide that, so it remains 0.
The same applies to the very similar variables system_serial_low and
system_serial_high (which also remain 0 on this u-boot platform).
Shall we also set these from the hardware on ep93xx during thus giving
them non-zero values in /proc/cpuinfo too?
As to where...? The other platforms that set these variables from
hardware queries do it in the board-specific files' MACHINE_START
function, but we'd have to do this in every board file, or have some
comon routine and modify every mach-ep93xx board file. The only common
routine all ep93xx board inits seem to have is ep93xx_init_devices.
This seems the least-resistance place to do this, but has nothing to
do with initlalizing devices of course. Is making another function in
toe core file and modifying every board's init function preferable?
Also, I have the simpler
system_rev = *((unsigned int *)EP93XX_SYSCON_CHIP_ID) >> 28;
system_serial_low = *((unsigned int *)EP93XX_SECURITY_UNIQID);
but maybe explicit readl and use of long defines are preferable.
Sorry, I'm not familiar with linux kernel best practice...
M
next prev parent reply other threads:[~2010-03-20 18:07 UTC|newest]
Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-03-18 16:59 [PATCH v2 0/3] spi: driver for Cirrus EP93xx SPI controller Mika Westerberg
2010-03-18 17:00 ` [PATCH v2 1/3] spi: implemented " Mika Westerberg
2010-03-18 17:00 ` [PATCH v2 2/3] ep93xx: added chip revision reading function Mika Westerberg
2010-03-18 17:00 ` [PATCH v2 3/3] ep93xx: SPI driver platform support code Mika Westerberg
2010-03-18 17:27 ` [spi-devel-general] [PATCH v2 2/3] ep93xx: added chip revision reading function H Hartley Sweeten
2010-03-25 9:06 ` Mika Westerberg
2010-03-25 17:20 ` H Hartley Sweeten
2010-03-26 15:40 ` Martin Guy
2010-03-20 18:07 ` Martin Guy [this message]
2010-03-20 18:25 ` Daniel Mack
2010-03-20 18:40 ` Martin Guy
2010-03-20 19:31 ` H Hartley Sweeten
2010-03-20 19:48 ` Martin Guy
2010-03-20 18:31 ` Mika Westerberg
2010-03-20 19:42 ` H Hartley Sweeten
2010-03-21 18:45 ` Mika Westerberg
2010-03-25 13:49 ` [PATCH v2 1/3] spi: implemented driver for Cirrus EP93xx SPI controller Martin Guy
2010-03-25 18:43 ` Mika Westerberg
2010-04-01 0:15 ` Martin Guy
2010-04-01 3:00 ` Ryan Mallon
2010-04-01 6:26 ` Mika Westerberg
2010-04-06 5:44 ` Mika Westerberg
2010-04-06 12:50 ` Martin Guy
2010-04-06 18:18 ` Mika Westerberg
2010-04-06 21:28 ` Martin Guy
2010-04-09 17:56 ` Martin Guy
2010-04-09 18:08 ` Martin Guy
2010-04-10 15:54 ` Mika Westerberg
2010-04-11 14:24 ` Martin Guy
2010-04-12 10:03 ` Martin Guy
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=56d259a01003201107s758b420bmafa154714a8a8fee@mail.gmail.com \
--to=martinwguy@gmail.com \
--cc=linux-arm-kernel@lists.infradead.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).