From: Ben Warren <bwarren@qstreams.com>
To: Vitaly Bordug <vbordug@ru.mvista.com>
Cc: linuxppc-dev@ozlabs.org, Paul Mackerras <paulus@samba.org>
Subject: Re: [PATCH 10/11] Add MPC8360EMDS board support
Date: Wed, 27 Sep 2006 09:09:16 -0400 [thread overview]
Message-ID: <1159362556.5555.30.camel@saruman.qstreams.net> (raw)
In-Reply-To: <20060927165556.04c8d5d7@vitb.ru.mvista.com>
On Wed, 2006-09-27 at 16:55 +0400, Vitaly Bordug wrote:
>
> I though about that approach, but saw somewhere a reference that we should not summon new node types without utter necessity, and utilized memory because bcsr is memory-mapped stuff. I can hardly imagine bcsr as a device (which would require respective spec inclusion btw).
>
> hence let's open a discussion what others think about that. The problem seems common (and for some boards
> is called somewhat else apparently), but at this point we should come to some conclusion, document it, and use it.
>
Since "memory" is not quite specific enough, but "board-control" is a
little bit Freescale and application-centric, how about
"memmapped-device", or something like that. This could encompass FPGAs,
ASICs, CPLDs or anything else that is memory mapped. Many custom
embedded boards have lots of such devices and could benefit from this
approach.
regards,
Ben
next prev parent reply other threads:[~2006-09-27 13:29 UTC|newest]
Thread overview: 37+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-09-21 12:20 [PATCH 10/11] Add MPC8360EMDS board support Li Yang
2006-09-27 6:39 ` Paul Mackerras
2006-09-27 11:56 ` Vitaly Bordug
2006-09-27 12:02 ` Li Yang-r58472
2006-09-27 12:55 ` Vitaly Bordug
2006-09-27 13:09 ` Ben Warren [this message]
2006-09-27 13:20 ` Li Yang-r58472
2006-09-27 13:33 ` Kumar Gala
2006-09-28 6:12 ` Li Yang-r58472
2006-09-30 0:49 ` Paul Mackerras
2006-09-27 14:14 ` Jon Loeliger
2006-09-28 6:38 ` Li Yang-r58472
2006-09-27 14:42 ` Dan Malek
2006-09-27 16:22 ` Olof Johansson
2006-09-28 4:10 ` Dan Malek
2006-09-30 15:56 ` Li Yang
2006-10-04 0:40 ` Paul Mackerras
2006-10-04 13:53 ` Dan Malek
2006-10-04 17:28 ` Tim Bird
2006-10-05 0:27 ` Paul Mackerras
2006-10-05 6:29 ` Eugene Surovegin
2006-10-04 6:08 ` Benjamin Herrenschmidt
2006-10-04 14:48 ` Dan Malek
2006-10-04 23:36 ` Benjamin Herrenschmidt
2006-10-05 0:03 ` Paul Mackerras
2006-10-05 0:08 ` Benjamin Herrenschmidt
2006-10-05 0:16 ` Vitaly Bordug
2006-10-05 6:21 ` Eugene Surovegin
2006-10-05 6:26 ` Benjamin Herrenschmidt
2006-10-05 6:31 ` Eugene Surovegin
2006-10-05 6:33 ` Eugene Surovegin
2006-10-05 6:51 ` Benjamin Herrenschmidt
2006-10-04 5:52 ` Benjamin Herrenschmidt
2006-10-04 14:57 ` Dan Malek
2006-10-04 16:05 ` Jerry Van Baren
2006-09-27 14:57 ` Sergei Shtylyov
-- strict thread matches above, loose matches on Subject: below --
2006-09-27 13:54 Joakim Tjernlund
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=1159362556.5555.30.camel@saruman.qstreams.net \
--to=bwarren@qstreams.com \
--cc=linuxppc-dev@ozlabs.org \
--cc=paulus@samba.org \
--cc=vbordug@ru.mvista.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).