[Top] [All Lists]

Re: [PATCH 06/36] Add Cavium OCTEON processor CSR definitions

To: Ralf Baechle <>
Subject: Re: [PATCH 06/36] Add Cavium OCTEON processor CSR definitions
From: Chad Reese <>
Date: Thu, 30 Oct 2008 11:45:39 -0700
Cc: David Daney <>, Christoph Hellwig <>,, Tomaso Paoletti <>
In-reply-to: <>
Original-recipient: rfc822;
References: <> <> <> <> <> <> <> <> <> <>
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv: Gecko/20070505 Iceape/1.0.9 (Debian-1.0.13~pre080323b-0etch3)
Ralf Baechle wrote:
> You see, everything was defined twice.  And gcc even recent gccs tend to
> do silly stuff with bitfields when combined with volatile:

Nobody should be using volatile anyway. It doesn't supply anywhere close
to the needed control for a register access. C would be a better
language if the volatile keyword was removed.

> The Linux programming programming model relies on accessor functions like
> readl, ioread32 etc.  Those take addresses as arguments - but bitfields
> don't have addresses in C ...

It is not valid on Octeon to access parts of CSR registers. You must do
a 64bit access, change whatever fields you want, and store the new
value. For this model bitfields work very well. GCC converts the
bitfield operations into bit insert and extract for mips64r2. It also
automatically combines multiple field sets into a single immediate load.

> So exec summary: bitfields bad for such low-level stuff.

Having spent a few years programming Octeon in various ways, bitfields
work really well for it.


<Prev in Thread] Current Thread [Next in Thread>