From: Jeff Garzik <jgarzik@pobox.com>
To: Marcelo Tosatti <marcelo.tosatti@cyclades.com>
Cc: Russell King <rmk+lkml@arm.linux.org.uk>,
linux-kernel@vger.kernel.org,
linux-ppc-embedded <linuxppc-embedded@ozlabs.org>
Subject: Re: [PATCH] MPC8xx PCMCIA driver
Date: Tue, 30 Aug 2005 00:33:00 -0400 [thread overview]
Message-ID: <4313E17C.4040401@pobox.com> (raw)
In-Reply-To: <20050830035338.GA5755@dmt.cnet>
Marcelo Tosatti wrote:
> On Mon, Aug 29, 2005 at 11:39:02PM -0400, Jeff Garzik wrote:
>
>>Marcelo Tosatti wrote:
>>
>>>+static int voltage_set(int slot, int vcc, int vpp)
>>>+{
>>>+ u_int reg = 0;
>>>+
>>>+ switch(vcc) {
>>>+ case 0: break;
>>>+ case 33:
>>>+ reg |= BCSR1_PCVCTL4;
>>>+ break;
>>>+ case 50:
>>>+ reg |= BCSR1_PCVCTL5;
>>>+ break;
>>>+ default:
>>>+ return 1;
>>>+ }
>>>+
>>>+ switch(vpp) {
>>>+ case 0: break;
>>>+ case 33:
>>>+ case 50:
>>>+ if(vcc == vpp)
>>>+ reg |= BCSR1_PCVCTL6;
>>>+ else
>>>+ return 1;
>>>+ break;
>>>+ case 120:
>>>+ reg |= BCSR1_PCVCTL7;
>>>+ default:
>>>+ return 1;
>>>+ }
>>>+
>>>+ if(!((vcc == 50) || (vcc == 0)))
>>>+ return 1;
>>>+
>>>+ /* first, turn off all power */
>>>+
>>>+ *((uint *)RPX_CSR_ADDR) &= ~(BCSR1_PCVCTL4 | BCSR1_PCVCTL5
>>>+ | BCSR1_PCVCTL6 | BCSR1_PCVCTL7);
>>>+
>>>+ /* enable new powersettings */
>>>+
>>>+ *((uint *)RPX_CSR_ADDR) |= reg;
>>
>>Should use bus read/write functions, such as foo_readl() or iowrite32().
>
>
> The memory map structure which contains device configuration/registers
> is _always_ directly mapped with pte's (the 8xx is a chip with builtin
> UART/network/etc functionality).
>
> I don't think there is a need to use read/write acessors.
There are multiple reasons:
* Easier reviewing. One cannot easily distinguish between writing to
normal kernel virtual memory and "magic" memory that produces magicaly
side effects such as initiating DMA of a net packet.
* Compiler safety. As the code is written now, you have no guarantees
that the compiler won't combine two stores to the same location, etc.
Accessor macros are a convenient place to add compiler barriers or
'volatile' notations that the MPC8xx code lacks.
* Maintainable. foo_read[bwl] or foo_read{8,16,32} are preferred
because that's the way other bus accessors look like -- yes even
embedded SoC buses benefit from these code patterns. You want your
driver to look like other drivers as much as possible.
* Convenience. The accessors can be a zero overhead memory read/write
at a minimum. But they can also be convenient places to use special
memory read/write instructions that specify uncached memop, compiler
barriers, memory barriers, etc.
Regards,
Jeff
WARNING: multiple messages have this Message-ID (diff)
From: Jeff Garzik <jgarzik@pobox.com>
To: Marcelo Tosatti <marcelo.tosatti@cyclades.com>
Cc: linux-ppc-embedded <linuxppc-embedded@ozlabs.org>,
linux-kernel@vger.kernel.org,
Russell King <rmk+lkml@arm.linux.org.uk>,
Dan Malek <dan@embeddededge.com>,
Pantelis Antoniou <panto@intracom.gr>
Subject: Re: [PATCH] MPC8xx PCMCIA driver
Date: Tue, 30 Aug 2005 00:33:00 -0400 [thread overview]
Message-ID: <4313E17C.4040401@pobox.com> (raw)
In-Reply-To: <20050830035338.GA5755@dmt.cnet>
Marcelo Tosatti wrote:
> On Mon, Aug 29, 2005 at 11:39:02PM -0400, Jeff Garzik wrote:
>
>>Marcelo Tosatti wrote:
>>
>>>+static int voltage_set(int slot, int vcc, int vpp)
>>>+{
>>>+ u_int reg = 0;
>>>+
>>>+ switch(vcc) {
>>>+ case 0: break;
>>>+ case 33:
>>>+ reg |= BCSR1_PCVCTL4;
>>>+ break;
>>>+ case 50:
>>>+ reg |= BCSR1_PCVCTL5;
>>>+ break;
>>>+ default:
>>>+ return 1;
>>>+ }
>>>+
>>>+ switch(vpp) {
>>>+ case 0: break;
>>>+ case 33:
>>>+ case 50:
>>>+ if(vcc == vpp)
>>>+ reg |= BCSR1_PCVCTL6;
>>>+ else
>>>+ return 1;
>>>+ break;
>>>+ case 120:
>>>+ reg |= BCSR1_PCVCTL7;
>>>+ default:
>>>+ return 1;
>>>+ }
>>>+
>>>+ if(!((vcc == 50) || (vcc == 0)))
>>>+ return 1;
>>>+
>>>+ /* first, turn off all power */
>>>+
>>>+ *((uint *)RPX_CSR_ADDR) &= ~(BCSR1_PCVCTL4 | BCSR1_PCVCTL5
>>>+ | BCSR1_PCVCTL6 | BCSR1_PCVCTL7);
>>>+
>>>+ /* enable new powersettings */
>>>+
>>>+ *((uint *)RPX_CSR_ADDR) |= reg;
>>
>>Should use bus read/write functions, such as foo_readl() or iowrite32().
>
>
> The memory map structure which contains device configuration/registers
> is _always_ directly mapped with pte's (the 8xx is a chip with builtin
> UART/network/etc functionality).
>
> I don't think there is a need to use read/write acessors.
There are multiple reasons:
* Easier reviewing. One cannot easily distinguish between writing to
normal kernel virtual memory and "magic" memory that produces magicaly
side effects such as initiating DMA of a net packet.
* Compiler safety. As the code is written now, you have no guarantees
that the compiler won't combine two stores to the same location, etc.
Accessor macros are a convenient place to add compiler barriers or
'volatile' notations that the MPC8xx code lacks.
* Maintainable. foo_read[bwl] or foo_read{8,16,32} are preferred
because that's the way other bus accessors look like -- yes even
embedded SoC buses benefit from these code patterns. You want your
driver to look like other drivers as much as possible.
* Convenience. The accessors can be a zero overhead memory read/write
at a minimum. But they can also be convenient places to use special
memory read/write instructions that specify uncached memop, compiler
barriers, memory barriers, etc.
Regards,
Jeff
next prev parent reply other threads:[~2005-08-30 4:33 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-08-30 2:48 [PATCH] MPC8xx PCMCIA driver Marcelo Tosatti
2005-08-30 2:48 ` Marcelo Tosatti
2005-08-30 3:39 ` Jeff Garzik
2005-08-30 3:39 ` Jeff Garzik
2005-08-30 3:53 ` Marcelo Tosatti
2005-08-30 3:53 ` Marcelo Tosatti
2005-08-30 4:32 ` Paul Mackerras
2005-08-30 4:32 ` Paul Mackerras
2005-08-30 15:07 ` Marcelo Tosatti
2005-08-30 15:07 ` Marcelo Tosatti
2005-08-30 4:33 ` Jeff Garzik [this message]
2005-08-30 4:33 ` Jeff Garzik
2005-08-30 7:06 ` Russell King
2005-08-30 7:06 ` Russell King
2005-09-01 8:53 ` Dominik Brodowski
2005-09-01 8:53 ` Dominik Brodowski
2005-09-01 11:44 ` Magnus Damm
2005-09-01 11:44 ` Magnus Damm
2005-09-01 14:51 ` Marcelo Tosatti
2005-09-14 14:11 ` Marcelo Tosatti
2005-09-14 14:27 ` Dominik Brodowski
2005-09-14 14:27 ` Dominik Brodowski
2005-09-14 18:21 ` Marcelo Tosatti
2005-09-14 18:21 ` Marcelo Tosatti
2005-09-14 18:46 ` Jeff Garzik
2005-09-14 18:46 ` Jeff Garzik
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=4313E17C.4040401@pobox.com \
--to=jgarzik@pobox.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linuxppc-embedded@ozlabs.org \
--cc=marcelo.tosatti@cyclades.com \
--cc=rmk+lkml@arm.linux.org.uk \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.