From: Ray Jui <rjui@broadcom.com>
To: Brian Norris <computersforpeace@gmail.com>,
Arnd Bergmann <arnd@arndb.de>
Cc: devicetree@vger.kernel.org,
"Florian Fainelli" <f.fainelli@gmail.com>,
"Scott Branden" <sbranden@broadcom.com>,
"Corneliu Doban" <cdoban@broadcom.com>,
"Kevin Cernekee" <cernekee@gmail.com>,
"Rafał Miłecki" <zajec5@gmail.com>,
linux-kernel@vger.kernel.org,
"Dan Ehrenberg" <dehrenberg@chromium.org>,
"Jonathan Richardson" <jonathar@broadcom.com>,
"Anatol Pomazao" <anatol@google.com>,
"Gregory Fong" <gregory.0xf0@gmail.com>,
bcm-kernel-feedback-list@broadcom.com,
linux-mtd@lists.infradead.org,
"Dmitry Torokhov" <dtor@google.com>
Subject: Re: [PATCH v3 03/10] mtd: nand: add NAND driver for Broadcom STB NAND controller
Date: Wed, 6 May 2015 14:18:47 -0700 [thread overview]
Message-ID: <554A8537.8050404@broadcom.com> (raw)
In-Reply-To: <20150506210534.GK32500@ld-irv-0074>
On 5/6/2015 2:05 PM, Brian Norris wrote:
> On Wed, May 06, 2015 at 09:17:36PM +0200, Arnd Bergmann wrote:
>> On Wednesday 06 May 2015 10:59:47 Brian Norris wrote:
>>> +
>>> +static inline u32 nand_readreg(struct brcmnand_controller *ctrl, u32 offs)
>>> +{
>>> + return __raw_readl(ctrl->nand_base + offs);
>>> +}
>>> +
>>> +static inline void nand_writereg(struct brcmnand_controller *ctrl, u32 offs,
>>> + u32 val)
>>> +{
>>> + __raw_writel(val, ctrl->nand_base + offs);
>>> +}
>>> +
>>>
>>
>> You had mentioned previously that there might be an endianess issue in this
>> driver.
>
> Might. I have a patch already, but I failed to boot a BE kernel, so I
> kept it out for now. If you don't mind, I'd prefer patching something
> like this once it's testable on ARM BE. This *is*, however, extensively
> tested on MIPS (LE and BE) and ARM (LE).
Correct, extensive test and pass all MTD test cases. We should
eventually be able to test this on a working ARM BE platform, within the
next couple months.
>
>> I think this won't work on big-endian architectures other than MIPS,
>> so it would be good to either list in the DT the endianess of the device
>> and use appropriate accessors here, or hardcode it based on the architecture
>> (using ioread32_be in big-endian mips, but readl elsewhere).
>
> I suspect we wouldn't need a DT property but could just special-case
> MIPS BE, as you note.
>
>> Using __raw_writel has another problem regarding the DMA capability of this
>> driver, as it will not flush any write buffers or synchronize caches before
>> sending data off to the device, so you risk data corruption.
>
> We use mb() before kicking off DMA or other commands.
>
>> Also, the
>> compiler can choose to split up the 32-bit word access into byte accesses,
>> which on most hardware does not do what you want.
>
> Huh? Wouldn't that break just about every driver in existence? And how
> is writel() any different than __raw_writel() in that regard? From
> include/asm-generic/io.h:
>
> static inline void writel(u32 value, volatile void __iomem *addr)
> {
> __raw_writel(__cpu_to_le32(value), addr);
> }
>
> And BTW, splitting isn't possible on ARM. From
> arch/arm/include/asm/io.h:
>
> static inline void __raw_writel(u32 val, volatile void __iomem *addr)
> {
> asm volatile("str %1, %0"
> : "+Qo" (*(volatile u32 __force *)addr)
> : "r" (val));
> }
>
> Brian
>
WARNING: multiple messages have this Message-ID (diff)
From: Ray Jui <rjui-dY08KVG/lbpWk0Htik3J/w@public.gmane.org>
To: Brian Norris
<computersforpeace-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>,
Arnd Bergmann <arnd-r2nGTMty4D4@public.gmane.org>
Cc: linux-mtd-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org,
"Dmitry Torokhov" <dtor-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org>,
"Anatol Pomazao" <anatol-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org>,
"Corneliu Doban" <cdoban-dY08KVG/lbpWk0Htik3J/w@public.gmane.org>,
"Jonathan Richardson"
<jonathar-dY08KVG/lbpWk0Htik3J/w@public.gmane.org>,
"Scott Branden"
<sbranden-dY08KVG/lbpWk0Htik3J/w@public.gmane.org>,
"Florian Fainelli"
<f.fainelli-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>,
"Rafał Miłecki" <zajec5-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>,
bcm-kernel-feedback-list-dY08KVG/lbpWk0Htik3J/w@public.gmane.org,
"Dan Ehrenberg"
<dehrenberg-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org>,
"Gregory Fong"
<gregory.0xf0-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
"Kevin Cernekee"
<cernekee-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Subject: Re: [PATCH v3 03/10] mtd: nand: add NAND driver for Broadcom STB NAND controller
Date: Wed, 6 May 2015 14:18:47 -0700 [thread overview]
Message-ID: <554A8537.8050404@broadcom.com> (raw)
In-Reply-To: <20150506210534.GK32500@ld-irv-0074>
On 5/6/2015 2:05 PM, Brian Norris wrote:
> On Wed, May 06, 2015 at 09:17:36PM +0200, Arnd Bergmann wrote:
>> On Wednesday 06 May 2015 10:59:47 Brian Norris wrote:
>>> +
>>> +static inline u32 nand_readreg(struct brcmnand_controller *ctrl, u32 offs)
>>> +{
>>> + return __raw_readl(ctrl->nand_base + offs);
>>> +}
>>> +
>>> +static inline void nand_writereg(struct brcmnand_controller *ctrl, u32 offs,
>>> + u32 val)
>>> +{
>>> + __raw_writel(val, ctrl->nand_base + offs);
>>> +}
>>> +
>>>
>>
>> You had mentioned previously that there might be an endianess issue in this
>> driver.
>
> Might. I have a patch already, but I failed to boot a BE kernel, so I
> kept it out for now. If you don't mind, I'd prefer patching something
> like this once it's testable on ARM BE. This *is*, however, extensively
> tested on MIPS (LE and BE) and ARM (LE).
Correct, extensive test and pass all MTD test cases. We should
eventually be able to test this on a working ARM BE platform, within the
next couple months.
>
>> I think this won't work on big-endian architectures other than MIPS,
>> so it would be good to either list in the DT the endianess of the device
>> and use appropriate accessors here, or hardcode it based on the architecture
>> (using ioread32_be in big-endian mips, but readl elsewhere).
>
> I suspect we wouldn't need a DT property but could just special-case
> MIPS BE, as you note.
>
>> Using __raw_writel has another problem regarding the DMA capability of this
>> driver, as it will not flush any write buffers or synchronize caches before
>> sending data off to the device, so you risk data corruption.
>
> We use mb() before kicking off DMA or other commands.
>
>> Also, the
>> compiler can choose to split up the 32-bit word access into byte accesses,
>> which on most hardware does not do what you want.
>
> Huh? Wouldn't that break just about every driver in existence? And how
> is writel() any different than __raw_writel() in that regard? From
> include/asm-generic/io.h:
>
> static inline void writel(u32 value, volatile void __iomem *addr)
> {
> __raw_writel(__cpu_to_le32(value), addr);
> }
>
> And BTW, splitting isn't possible on ARM. From
> arch/arm/include/asm/io.h:
>
> static inline void __raw_writel(u32 val, volatile void __iomem *addr)
> {
> asm volatile("str %1, %0"
> : "+Qo" (*(volatile u32 __force *)addr)
> : "r" (val));
> }
>
> Brian
>
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
WARNING: multiple messages have this Message-ID (diff)
From: Ray Jui <rjui@broadcom.com>
To: Brian Norris <computersforpeace@gmail.com>,
Arnd Bergmann <arnd@arndb.de>
Cc: linux-mtd@lists.infradead.org,
"Dmitry Torokhov" <dtor@google.com>,
"Anatol Pomazao" <anatol@google.com>,
"Corneliu Doban" <cdoban@broadcom.com>,
"Jonathan Richardson" <jonathar@broadcom.com>,
"Scott Branden" <sbranden@broadcom.com>,
"Florian Fainelli" <f.fainelli@gmail.com>,
"Rafał Miłecki" <zajec5@gmail.com>,
bcm-kernel-feedback-list@broadcom.com,
"Dan Ehrenberg" <dehrenberg@chromium.org>,
"Gregory Fong" <gregory.0xf0@gmail.com>,
devicetree@vger.kernel.org, linux-kernel@vger.kernel.org,
"Kevin Cernekee" <cernekee@gmail.com>
Subject: Re: [PATCH v3 03/10] mtd: nand: add NAND driver for Broadcom STB NAND controller
Date: Wed, 6 May 2015 14:18:47 -0700 [thread overview]
Message-ID: <554A8537.8050404@broadcom.com> (raw)
In-Reply-To: <20150506210534.GK32500@ld-irv-0074>
On 5/6/2015 2:05 PM, Brian Norris wrote:
> On Wed, May 06, 2015 at 09:17:36PM +0200, Arnd Bergmann wrote:
>> On Wednesday 06 May 2015 10:59:47 Brian Norris wrote:
>>> +
>>> +static inline u32 nand_readreg(struct brcmnand_controller *ctrl, u32 offs)
>>> +{
>>> + return __raw_readl(ctrl->nand_base + offs);
>>> +}
>>> +
>>> +static inline void nand_writereg(struct brcmnand_controller *ctrl, u32 offs,
>>> + u32 val)
>>> +{
>>> + __raw_writel(val, ctrl->nand_base + offs);
>>> +}
>>> +
>>>
>>
>> You had mentioned previously that there might be an endianess issue in this
>> driver.
>
> Might. I have a patch already, but I failed to boot a BE kernel, so I
> kept it out for now. If you don't mind, I'd prefer patching something
> like this once it's testable on ARM BE. This *is*, however, extensively
> tested on MIPS (LE and BE) and ARM (LE).
Correct, extensive test and pass all MTD test cases. We should
eventually be able to test this on a working ARM BE platform, within the
next couple months.
>
>> I think this won't work on big-endian architectures other than MIPS,
>> so it would be good to either list in the DT the endianess of the device
>> and use appropriate accessors here, or hardcode it based on the architecture
>> (using ioread32_be in big-endian mips, but readl elsewhere).
>
> I suspect we wouldn't need a DT property but could just special-case
> MIPS BE, as you note.
>
>> Using __raw_writel has another problem regarding the DMA capability of this
>> driver, as it will not flush any write buffers or synchronize caches before
>> sending data off to the device, so you risk data corruption.
>
> We use mb() before kicking off DMA or other commands.
>
>> Also, the
>> compiler can choose to split up the 32-bit word access into byte accesses,
>> which on most hardware does not do what you want.
>
> Huh? Wouldn't that break just about every driver in existence? And how
> is writel() any different than __raw_writel() in that regard? From
> include/asm-generic/io.h:
>
> static inline void writel(u32 value, volatile void __iomem *addr)
> {
> __raw_writel(__cpu_to_le32(value), addr);
> }
>
> And BTW, splitting isn't possible on ARM. From
> arch/arm/include/asm/io.h:
>
> static inline void __raw_writel(u32 val, volatile void __iomem *addr)
> {
> asm volatile("str %1, %0"
> : "+Qo" (*(volatile u32 __force *)addr)
> : "r" (val));
> }
>
> Brian
>
next prev parent reply other threads:[~2015-05-06 21:19 UTC|newest]
Thread overview: 89+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-05-06 17:59 [PATCH v3 00/10] mtd: nand: add Broadcom NAND controller support Brian Norris
2015-05-06 17:59 ` Brian Norris
2015-05-06 17:59 ` Brian Norris
2015-05-06 17:59 ` [PATCH v3 01/10] mtd: nand: add common DT init code Brian Norris
2015-05-06 17:59 ` Brian Norris
2015-05-06 17:59 ` Brian Norris
2015-05-11 23:25 ` Brian Norris
2015-05-11 23:25 ` Brian Norris
2015-05-06 17:59 ` [PATCH v3 02/10] Documentation: devicetree: add binding doc for Broadcom NAND controller Brian Norris
2015-05-06 17:59 ` Brian Norris
2015-05-06 17:59 ` Brian Norris
2015-05-06 17:59 ` [PATCH v3 03/10] mtd: nand: add NAND driver for Broadcom STB " Brian Norris
2015-05-06 17:59 ` Brian Norris
2015-05-06 17:59 ` Brian Norris
2015-05-06 19:17 ` Arnd Bergmann
2015-05-06 19:17 ` Arnd Bergmann
2015-05-06 21:05 ` Brian Norris
2015-05-06 21:05 ` Brian Norris
2015-05-06 21:18 ` Ray Jui [this message]
2015-05-06 21:18 ` Ray Jui
2015-05-06 21:18 ` Ray Jui
2015-05-07 9:25 ` Arnd Bergmann
2015-05-07 9:25 ` Arnd Bergmann
2015-05-07 18:52 ` Brian Norris
2015-05-07 18:52 ` Brian Norris
2015-05-08 8:18 ` Arnd Bergmann
2015-05-08 8:18 ` Arnd Bergmann
2015-05-08 2:01 ` Brian Norris
2015-05-08 2:01 ` Brian Norris
2015-05-08 8:19 ` Arnd Bergmann
2015-05-08 8:19 ` Arnd Bergmann
2015-05-08 8:19 ` Arnd Bergmann
2015-05-06 17:59 ` [PATCH v3 04/10] ARM: bcm7445: add NAND to DTS Brian Norris
2015-05-06 17:59 ` Brian Norris
2015-05-06 17:59 ` Brian Norris
2015-05-06 17:59 ` [PATCH v3 05/10] Documentation: devicetree: brcmstb_nand: add 'brcm, nand-soc' bindings Brian Norris
2015-05-06 17:59 ` [PATCH v3 05/10] Documentation: devicetree: brcmstb_nand: add 'brcm,nand-soc' bindings Brian Norris
2015-05-06 17:59 ` Brian Norris
2015-05-06 17:59 ` [PATCH v3 06/10] mtd: brcmstb_nand: add SoC-specific support Brian Norris
2015-05-06 17:59 ` Brian Norris
2015-05-06 17:59 ` Brian Norris
2015-05-06 19:12 ` Arnd Bergmann
2015-05-06 19:12 ` Arnd Bergmann
2015-05-06 20:49 ` Brian Norris
2015-05-06 20:49 ` Brian Norris
2015-05-06 21:00 ` nick
2015-05-06 21:00 ` nick
2015-05-07 10:01 ` Arnd Bergmann
2015-05-07 10:01 ` Arnd Bergmann
2015-05-07 18:42 ` Brian Norris
2015-05-07 18:42 ` Brian Norris
2015-05-07 18:48 ` Ray Jui
2015-05-07 18:48 ` Ray Jui
2015-05-07 18:48 ` Ray Jui
2015-05-08 13:41 ` Arnd Bergmann
2015-05-08 13:41 ` Arnd Bergmann
2015-05-08 13:41 ` Arnd Bergmann
2015-05-08 19:38 ` Brian Norris
2015-05-08 19:38 ` Brian Norris
2015-05-08 19:38 ` Brian Norris
2015-05-08 19:49 ` Arnd Bergmann
2015-05-08 19:49 ` Arnd Bergmann
2015-05-08 20:47 ` Brian Norris
2015-05-08 20:47 ` Brian Norris
2015-05-08 20:47 ` Brian Norris
2015-05-08 21:38 ` Arnd Bergmann
2015-05-08 21:38 ` Arnd Bergmann
2015-05-08 21:49 ` Brian Norris
2015-05-08 21:49 ` Brian Norris
2015-05-08 21:58 ` Ray Jui
2015-05-08 21:58 ` Ray Jui
2015-05-07 18:51 ` Florian Fainelli
2015-05-07 18:51 ` Florian Fainelli
2015-05-07 18:51 ` Florian Fainelli
2015-05-06 17:59 ` [PATCH v3 07/10] mtd: brcsmtb_nand_soc: add support for BCM63138 Brian Norris
2015-05-06 17:59 ` Brian Norris
2015-05-06 17:59 ` Brian Norris
2015-05-06 17:59 ` [PATCH v3 08/10] mtd: brcsmtb_nand_soc: add iProc support Brian Norris
2015-05-06 17:59 ` Brian Norris
2015-05-06 17:59 ` Brian Norris
2015-05-06 17:59 ` [PATCH v3 09/10] ARM: bcm63138: add NAND DT support Brian Norris
2015-05-06 17:59 ` Brian Norris
2015-05-06 17:59 ` Brian Norris
2015-05-06 17:59 ` [PATCH v3 10/10] ARM: dts: cygnus: Enable NAND support for Cygnus Brian Norris
2015-05-06 17:59 ` Brian Norris
2015-05-06 17:59 ` Brian Norris
2015-05-06 21:31 ` [PATCH v3 00/10] mtd: nand: add Broadcom NAND controller support Florian Fainelli
2015-05-06 21:31 ` Florian Fainelli
2015-05-06 21:31 ` Florian Fainelli
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=554A8537.8050404@broadcom.com \
--to=rjui@broadcom.com \
--cc=anatol@google.com \
--cc=arnd@arndb.de \
--cc=bcm-kernel-feedback-list@broadcom.com \
--cc=cdoban@broadcom.com \
--cc=cernekee@gmail.com \
--cc=computersforpeace@gmail.com \
--cc=dehrenberg@chromium.org \
--cc=devicetree@vger.kernel.org \
--cc=dtor@google.com \
--cc=f.fainelli@gmail.com \
--cc=gregory.0xf0@gmail.com \
--cc=jonathar@broadcom.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mtd@lists.infradead.org \
--cc=sbranden@broadcom.com \
--cc=zajec5@gmail.com \
/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.