From: Peter Ryser <peter.ryser@xilinx.com>
To: Grant Likely <grant.likely@secretlab.ca>
Cc: Andrei Konovalov <akonovalov@mvista.com>,
Grant Likely <grant@secretlab.ca>,
Rick Moleres <Rick.Moleres@xilinx.com>,
linuxppc-embedded <linuxppc-embedded@ozlabs.org>
Subject: Re: [PATCH 00/10] Updated ML300 & ML403 patches
Date: Tue, 17 Jan 2006 09:06:20 -0800 [thread overview]
Message-ID: <43CD240C.2050907@xilinx.com> (raw)
In-Reply-To: <43CD1021.7080205@secretlab.ca>
> I don't understand what you mean. It sounds like your suggesting I do
> exactly opposite what you're arguing; hand modify one of the
> xparameters_*.h files. Are you saying that edk can't generate Linux
> redefines for the ml403 at the moment?
Yes, it can. It looks they are not present in the xparameters_ml403.h
that you submitted as part of your patch. I'll send you the
automatically generated file in a seperate email.
> I do *not* think I should replace the edk-generated
> xparameters_ml403.h with a hacked xparameters_ml300.h file. I'd
> rather use the generated _ml403 file and change the infrastructure
> when the Linux redefines are ready.
See above. BTW, I'm not sure how familiar you are with the process in
EDK. Let me know if I can help you step through it.
>> That's not a recommended flow. It's very easy to create an EDK design
>> with the proper settings and since it is very likely that things
>> change during the design process of the FPGA the small investment
>> into making the proper settings in the tool will save a lot of time
>> in the end.
>
>
> I understand that it's not *recommended*; I'm just saying it's not
> always *reality* :p
Yeah, that's true for user projects. However, I hope that we can get the
default included in the Linux 2.6 kernel right.
> Yes; but I already said that I'll change the patch to use the Xilinx
> redefines. My argument is simply that *if* changes are required,
> there is a way for the user to do it. In the normal (recommended)
> case; nothing will need to be done. (think Larry Wall's quote: "easy
> things easy; hard things possible)
>
> When it is needed; the fixups will be in xparameters.h; not
> xparameters_*.h; and they'll be for a specific port. The fixups will
> only need to be done once per project (most likely).
I'm not sure that I follow your argument here.
> My point is that the Linux redefines are useful to more than just
> Linux ports. Don't you think standalone apps could also benefit from
> a sane-set of defines for peripherals? In other words; shouldn't the
> Linux redefines be always available (and called something more generic)?
I see what you mean and I tend to agree.
> okay, I'll change the patch to use those names.
Great. Thanks.
- Peter
next prev parent reply other threads:[~2006-01-17 17:07 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-01-14 9:46 [PATCH 00/10] Updated ML300 & ML403 patches Grant Likely
[not found] ` <43CC5453.3060702@xilinx.com>
2006-01-17 7:39 ` Grant Likely
2006-01-17 12:52 ` Peter Ryser
2006-01-17 15:41 ` Grant Likely
2006-01-17 17:06 ` Peter Ryser [this message]
2006-01-17 17:30 ` Grant Likely
2006-01-17 19:31 ` Grant Likely
2006-01-18 23:26 ` Peter Ryser
2006-01-19 5:11 ` Grant Likely
2006-01-19 0:27 ` David H. Lynch Jr.
2006-01-19 7:14 ` jeffer
2006-01-19 7:29 ` Peter Ryser
-- strict thread matches above, loose matches on Subject: below --
2006-01-17 18:10 John Bonesio
2006-01-17 18:31 ` Grant Likely
[not found] <mailman.134.1137523561.17753.linuxppc-embedded@ozlabs.org>
2006-01-17 20:12 ` T Ziomek
2006-01-17 20:19 ` Grant Likely
2006-01-17 20:23 ` T Ziomek
2006-01-17 20:37 ` Grant Likely
2006-01-27 12:01 Paula Saameño
2006-01-27 16:37 ` Grant Likely
2006-02-09 7:57 S. Egbert
2006-02-09 14:51 ` Grant Likely
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=43CD240C.2050907@xilinx.com \
--to=peter.ryser@xilinx.com \
--cc=Rick.Moleres@xilinx.com \
--cc=akonovalov@mvista.com \
--cc=grant.likely@secretlab.ca \
--cc=grant@secretlab.ca \
--cc=linuxppc-embedded@ozlabs.org \
/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).