All of lore.kernel.org
 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 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.