From: "Albrecht Dreß" <albrecht.dress@arcor.de>
To: Grant Likely <grant.likely@secretlab.ca>,
Linux PPC Development <linuxppc-dev@ozlabs.org>
Subject: Re: [PATCH/v2] powerpc/5200: make BestComm gen_bd microcode exchangeable
Date: Mon, 05 Oct 2009 21:42:13 +0200 [thread overview]
Message-ID: <1254771740.5503.2@antares> (raw)
In-Reply-To: <fa686aa40910051116l6439eef7xc9f75c6ac4368094@mail.gmail.com> (from grant.likely@secretlab.ca on Mon Oct 5 20:16:26 2009)
[-- Attachment #1: Type: text/plain, Size: 2385 bytes --]
Am 05.10.09 20:16 schrieb(en) Grant Likely:
> Hmmm. I've not been comfortable with this change, but it took me a while to put my finger on exactly why. In principle, I think it is a good idea. However, I don't want to merge it without any in-tree users.
I could provide my modified microcode (which differs in two words only), for the "standard" task, just with byte swapping for the LPB, but I wonder if it is of much use. No progress with crc32 calculation in BestComm so far... :-(
> The other concern is that I don't like that the patch is only applicable to gen_bd tasks.
IMHO the big difference between gen_bd on one hand and ATA and FEC on the other is that (afaik) we have *no* other choice than using the implemented tasks for the latter two, obviously using the Freescale's example microcode. Gen_bd can apparently be used for a plenty of purposes, including LPB (as shown in your driver), maybe PCI (there are examples in Freescale's code), PSC, etc. Thus, the FEC and ATA drivers should not have an option as to change the microcode, whereas it is just convenient for gen_bd.
> I've been thinking about this for a while, and I'm not exactly thrilled with the bestcomm layout which keeps the bestcomm firmware separate from the only driver that actually uses it (ie FEC firmware & support code is separate from the FEC driver. Same for ATA). I don't like the fact that code which is only ever used by the ATA driver is maintained completely separate from it.
That's a good point! The separate microcode files for ATA and FEC are somewhat confusing. I guess it's a result of simply copying the Freescale examples into separate files (and that might be a good reason for keeping the microcode separated). Maybe create new sub-folders below arch/powerpc/sysdev/bestcomm for fec, ata, and gen_bd? At least some documentation would be great.
> But I may be splitting hairs here and maybe I shouldn't be too concerned about it. Regardless, I'd think I'd rather see something that isn't totally gen_bd specific. Perhaps *microcode should be part of the bcom_task structure?
See above - I believe FEC and ATA are somewhat special as they need *exactly* the provided microcode. And if something cannot be changed without breaking the functionality, there should not be a chance to do so... ;-)
Just my €0.01, though...
Cheers, Albrecht.
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
next prev parent reply other threads:[~2009-10-05 19:42 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-10-05 17:41 [PATCH/v2] powerpc/5200: make BestComm gen_bd microcode exchangeable Albrecht Dreß
2009-10-05 18:16 ` Grant Likely
2009-10-05 19:42 ` Albrecht Dreß [this message]
2009-11-01 6:47 ` 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=1254771740.5503.2@antares \
--to=albrecht.dress@arcor.de \
--cc=grant.likely@secretlab.ca \
--cc=linuxppc-dev@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).