linuxppc-dev.lists.ozlabs.org archive mirror
 help / color / mirror / Atom feed
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

  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).