From: Benjamin Herrenschmidt <benh@kernel.crashing.org>
To: Sylvain Munaut <tnt@246tNt.com>
Cc: linuxppc-embedded@ozlabs.org
Subject: Re: status of mpc52xx with arch=powerpc?
Date: Sat, 28 Oct 2006 08:39:25 +1000 [thread overview]
Message-ID: <1161988765.25682.99.camel@localhost.localdomain> (raw)
In-Reply-To: <45411F14.6020308@246tNt.com>
> We would use the API we worked earlier on (Dale, Andrey, John, ...).
> To add support of fw preloaded task :
> - The bestcomm.ko module would be used when bestcomm is completely
> controlled by the kernel
> - A different module but with the same exported function would be used
> when the fw has a part to play in the init. That allows to customize a bunch
> of the sdma init / sram mapping ...
> - All the other code (task helpers / the .h / the driver api) would be
> exactly
> the same.
No. Two different modules is the wrong approach. I want to be able to
build everything in the kernel (no modules) and still boot machines with
both types.
There should be a single implementation. I know bestcomm is fucked by
design but still.
> So the bestcomm modules maintain a list with all task loaded with a name and
> a index attribute. (The index would be used when there is multiple
> device with
> the same name, like "psc". We could use names like "psc1", "psc2". But that
> would imply string manipulation to "create" the name string ;)
>
> In the case of the "classic" (kernel handles it all), the table of task
> is just
> initially empty. But for the "custom" case, it's filled with whatever
> the fw has
> passed as infos.
A single module should handle all cases though. If, for some reasons, it
looks like that will cause a lot of additional code, them it can be
internally split and we can have config options to enable only one way,
but it should be possible to enable both.
Ben.
prev parent reply other threads:[~2006-10-27 22:39 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-10-18 13:06 status of mpc52xx with arch=powerpc? Sascha Hauer
2006-10-18 13:52 ` Grant Likely
2006-10-19 8:13 ` Sascha Hauer
2006-10-19 9:49 ` Roman Fietze
2006-10-19 14:17 ` Sascha Hauer
2006-10-19 14:46 ` Grant Likely
2006-10-19 17:21 ` John Rigby
2006-10-25 1:46 ` Benjamin Herrenschmidt
2006-10-25 6:25 ` Grant Likely
2006-10-26 20:07 ` John Rigby
2006-10-26 20:36 ` Grant Likely
2006-10-26 20:48 ` Sylvain Munaut
2006-10-27 22:39 ` Benjamin Herrenschmidt [this message]
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=1161988765.25682.99.camel@localhost.localdomain \
--to=benh@kernel.crashing.org \
--cc=linuxppc-embedded@ozlabs.org \
--cc=tnt@246tNt.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).