[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date: Sun, 12 Dec 2010 15:17:20 +0000
From: Will Newton <will.newton@...il.com>
To: Russell King - ARM Linux <linux@....linux.org.uk>
Cc: Chris Ball <cjb@...top.org>, Matt Fleming <matt@...sole-pimps.org>,
linux-mmc@...r.kernel.org,
Linux Kernel list <linux-kernel@...r.kernel.org>,
linux-arm-kernel@...ts.infradead.org
Subject: Re: [PATCH] dw_mmc: Add Synopsys DesignWare mmc host driver.
On Sun, Dec 12, 2010 at 2:47 PM, Russell King - ARM Linux
<linux@....linux.org.uk> wrote:
> On Sun, Dec 12, 2010 at 02:31:40PM +0000, Will Newton wrote:
>> On Sun, Dec 12, 2010 at 2:11 PM, Russell King - ARM Linux
>> <linux@....linux.org.uk> wrote:
>> > Maybe invent CONFIG_HAVE_MMIO_64BIT which architectures can select as
>> > appropriate?
>>
>> Wouldn't it be simpler to have a fallback readq/writeq implementation
>> like the below?
>>
>> static inline u64 __raw_readq(const volatile void __iomem *addr)
>> {
>> return *(const volatile u64 __force *) addr;
>> }
>>
>> It won't break any existing hardware (if your SoC bus does not support
>> 64bit accesses you are unlikely to have peripherals that require it)
>> and would avoid a number of #ifdefs and/or Kconfig dependencies.
>
> Firstly, why, then, are we discussing fixing dw_mmc.c so it builds on ARM?
It's a configurable IP block, so one would assume that if it was
configured with a 64bit FIFO width on ARM then your SoC integration
engineers dropped the ball.
Even on architectures that can do 64bit MMIO, I would expect there to
be systems where that is not safe in practice (e.g. 32bit bus fabric
that will translate a 64bit access into 2 32bit accesses) so I don't
know if it's ideal to make this an architecture level config symbol.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists