From: "Albrecht Dreß" <albrecht.dress@arcor.de>
To: Grant Likely <grant.likely@secretlab.ca>
Cc: devicetree-discuss@ozlabs.org,
Wolfram Sang <w.sang@pengutronix.de>,
linuxppc-dev@ozlabs.org, linux-mtd@lists.infradead.org,
Ben Dooks <ben-linux@fluff.org>,
David Woodhouse <dwmw2@infradead.org>
Subject: Re: [PATCH V2 2/2] mtd/maps/mtd-ram: add an of-platform driver
Date: Tue, 16 Jun 2009 19:19:06 +0200 [thread overview]
Message-ID: <1245172753.3400.0@antares> (raw)
In-Reply-To: <fa686aa40906160553m2f0e7cc4n644c3893573845f@mail.gmail.com> (from grant.likely@secretlab.ca on Tue Jun 16 14:53:17 2009)
[-- Attachment #1: Type: text/plain, Size: 874 bytes --]
Am 16.06.09 14:53 schrieb(en) Grant Likely:
> I'm not happy about the use case though. It probably shouldn't
> appear in this binding, or if it does it should be tagged as an
> optional property.
I agree with you that the naming is really misleading - other devices
which are not mtd's may suffer from the same problem of the lpb (in my
case, I have an extra memory-mapped Ethernet chip which I didn't try to
access yet...).
As it is actually a chip select property, what about defining an
optional property like "cs-width = (8|16|32)" which defaults to 8 and
may be added to each 5200 lpb child?
> It is only in the 5200 localplus case that bank-width is needed to
> figure out how to apply the workaround.
Just out of curiosity: what about the "localbus" of other Freescale
chips (82xx? 83xx? Maybe others?)?
Thanks, Albrecht.
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
WARNING: multiple messages have this Message-ID (diff)
From: "Albrecht Dreß" <albrecht.dress@arcor.de>
To: Grant Likely <grant.likely@secretlab.ca>
Cc: devicetree-discuss@ozlabs.org, linuxppc-dev@ozlabs.org,
linux-mtd@lists.infradead.org, Ben Dooks <ben-linux@fluff.org>,
David Woodhouse <dwmw2@infradead.org>
Subject: Re: [PATCH V2 2/2] mtd/maps/mtd-ram: add an of-platform driver
Date: Tue, 16 Jun 2009 19:19:06 +0200 [thread overview]
Message-ID: <1245172753.3400.0@antares> (raw)
In-Reply-To: <fa686aa40906160553m2f0e7cc4n644c3893573845f@mail.gmail.com> (from grant.likely@secretlab.ca on Tue Jun 16 14:53:17 2009)
[-- Attachment #1: Type: text/plain, Size: 874 bytes --]
Am 16.06.09 14:53 schrieb(en) Grant Likely:
> I'm not happy about the use case though. It probably shouldn't
> appear in this binding, or if it does it should be tagged as an
> optional property.
I agree with you that the naming is really misleading - other devices
which are not mtd's may suffer from the same problem of the lpb (in my
case, I have an extra memory-mapped Ethernet chip which I didn't try to
access yet...).
As it is actually a chip select property, what about defining an
optional property like "cs-width = (8|16|32)" which defaults to 8 and
may be added to each 5200 lpb child?
> It is only in the 5200 localplus case that bank-width is needed to
> figure out how to apply the workaround.
Just out of curiosity: what about the "localbus" of other Freescale
chips (82xx? 83xx? Maybe others?)?
Thanks, Albrecht.
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
WARNING: multiple messages have this Message-ID (diff)
From: "Albrecht Dreß" <albrecht.dress-KvP5wT2u2U0@public.gmane.org>
To: Grant Likely <grant.likely-s3s/WqlpOiPyB63q8FvJNQ@public.gmane.org>
Cc: devicetree-discuss-mnsaURCQ41sdnm+yROfE0A@public.gmane.org,
linuxppc-dev-mnsaURCQ41sdnm+yROfE0A@public.gmane.org,
linux-mtd-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org,
Ben Dooks <ben-linux-elnMNo+KYs3YtjvyW6yDsg@public.gmane.org>,
David Woodhouse <dwmw2-wEGCiKHe2LqWVfeAwA7xHQ@public.gmane.org>
Subject: Re: [PATCH V2 2/2] mtd/maps/mtd-ram: add an of-platform driver
Date: Tue, 16 Jun 2009 19:19:06 +0200 [thread overview]
Message-ID: <1245172753.3400.0@antares> (raw)
In-Reply-To: <fa686aa40906160553m2f0e7cc4n644c3893573845f-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org> (from grant.likely-s3s/WqlpOiPyB63q8FvJNQ@public.gmane.org on Tue Jun 16 14:53:17 2009)
[-- Attachment #1.1: Type: text/plain, Size: 874 bytes --]
Am 16.06.09 14:53 schrieb(en) Grant Likely:
> I'm not happy about the use case though. It probably shouldn't
> appear in this binding, or if it does it should be tagged as an
> optional property.
I agree with you that the naming is really misleading - other devices
which are not mtd's may suffer from the same problem of the lpb (in my
case, I have an extra memory-mapped Ethernet chip which I didn't try to
access yet...).
As it is actually a chip select property, what about defining an
optional property like "cs-width = (8|16|32)" which defaults to 8 and
may be added to each 5200 lpb child?
> It is only in the 5200 localplus case that bank-width is needed to
> figure out how to apply the workaround.
Just out of curiosity: what about the "localbus" of other Freescale
chips (82xx? 83xx? Maybe others?)?
Thanks, Albrecht.
[-- Attachment #1.2: Type: application/pgp-signature, Size: 189 bytes --]
[-- Attachment #2: Type: text/plain, Size: 194 bytes --]
_______________________________________________
devicetree-discuss mailing list
devicetree-discuss-mnsaURCQ41sdnm+yROfE0A@public.gmane.org
https://ozlabs.org/mailman/listinfo/devicetree-discuss
next prev parent reply other threads:[~2009-06-16 17:19 UTC|newest]
Thread overview: 52+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-06-05 12:05 [PATCH V2 0/2] mtd/maps/mtd-ram: Make driver usable for the device tree Wolfram Sang
2009-06-05 12:05 ` Wolfram Sang
2009-06-05 12:05 ` Wolfram Sang
2009-06-05 12:05 ` [PATCH V2 1/2] mtd/maps/mtd-ram: refactor probe and remove Wolfram Sang
2009-06-05 12:05 ` Wolfram Sang
2009-06-05 12:05 ` Wolfram Sang
2009-06-05 12:05 ` [PATCH V2 2/2] mtd/maps/mtd-ram: add an of-platform driver Wolfram Sang
2009-06-05 12:05 ` Wolfram Sang
2009-06-05 12:05 ` Wolfram Sang
2009-06-05 15:53 ` Grant Likely
2009-06-05 15:53 ` Grant Likely
2009-06-05 15:53 ` Grant Likely
2009-06-05 16:22 ` Albrecht Dreß
2009-06-05 16:22 ` Albrecht Dreß
2009-06-06 8:14 ` David Woodhouse
2009-06-06 8:14 ` David Woodhouse
2009-06-06 8:14 ` David Woodhouse
2009-06-06 11:19 ` Wolfram Sang
2009-06-06 11:19 ` Wolfram Sang
2009-06-06 11:19 ` Wolfram Sang
2009-07-01 18:22 ` Ken MacLeod
2009-07-17 11:41 ` Wolfram Sang
2009-06-16 9:09 ` Wolfram Sang
2009-06-16 9:09 ` Wolfram Sang
2009-06-16 9:09 ` Wolfram Sang
2009-06-06 16:05 ` Grant Likely
2009-06-06 16:05 ` Grant Likely
2009-06-06 16:05 ` Grant Likely
2009-06-06 16:16 ` Albrecht Dreß
2009-06-06 16:16 ` Albrecht Dreß
2009-06-06 16:16 ` Albrecht Dreß
2009-06-08 16:35 ` Wolfram Sang
2009-06-08 16:35 ` Wolfram Sang
2009-06-08 17:30 ` Albrecht Dreß
2009-06-08 17:30 ` Albrecht Dreß
2009-06-08 17:30 ` Albrecht Dreß
2009-06-15 17:43 ` Albrecht Dreß
2009-06-15 17:43 ` Albrecht Dreß
2009-06-16 9:18 ` Wolfram Sang
2009-06-16 9:18 ` Wolfram Sang
2009-06-16 9:18 ` Wolfram Sang
2009-06-16 12:53 ` Grant Likely
2009-06-16 12:53 ` Grant Likely
2009-06-16 12:53 ` Grant Likely
2009-06-16 13:20 ` Wolfram Sang
2009-06-16 13:20 ` Wolfram Sang
[not found] ` <fa686aa40906160833g1d77466ekf8b8d4350ab32a24@mail.gmail.com>
2009-06-16 15:34 ` Grant Likely
2009-06-16 15:34 ` Grant Likely
2009-06-16 15:34 ` Grant Likely
2009-06-16 17:19 ` Albrecht Dreß [this message]
2009-06-16 17:19 ` Albrecht Dreß
2009-06-16 17:19 ` Albrecht Dreß
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=1245172753.3400.0@antares \
--to=albrecht.dress@arcor.de \
--cc=ben-linux@fluff.org \
--cc=devicetree-discuss@ozlabs.org \
--cc=dwmw2@infradead.org \
--cc=grant.likely@secretlab.ca \
--cc=linux-mtd@lists.infradead.org \
--cc=linuxppc-dev@ozlabs.org \
--cc=w.sang@pengutronix.de \
/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.