From: Sylvain Munaut <tnt@246tNt•com>
To: Grant Likely <grant.likely@secretlab•ca>
Cc: linuxppc-embedded@ozlabs•org
Subject: Re: status of mpc52xx with arch=powerpc?
Date: Thu, 26 Oct 2006 22:48:20 +0200 [thread overview]
Message-ID: <45411F14.6020308@246tNt.com> (raw)
In-Reply-To: <528646bc0610261336i61521af3y3a5f134bb8c2f8da@mail.gmail.com>
Grant Likely wrote:
> On 10/26/06, John Rigby <jcrigby@gmail•com> wrote:
>> Does Bestcomm dma belong in here somewhere?
>
> I don't think so for embedded targets; but I may be wrong. Of course;
> I think the kernel should be responsible for setting up the bestcomm
> tasks. If a spec is defined for how firmware could preload bestcomm
> tasks, then maybe.
Yes, we discussed that on IRC.
For I got from it would be something like that :
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.
- Currently the task support code (the arch/ppc/syslib/fec.c for example in
the current code) does this :
struct sdma_task *tsk;
tsk = sdma_task_alloc(queue_len, sizeof(struct sdma_fec_bd));
if (!tsk)
return NULL;
To reuse the preloaded task, it would be changed to
tsk = sdma_task_find_by_name("fec", 0);
if (!tsk)
tsk = sdma_task_alloc("fec", 0, queue_len, sizeof(struct
sdma_fec_bd));
if (!tsk)
return NULL;
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.
Sylvain
next prev parent reply other threads:[~2006-10-26 20:50 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 [this message]
2006-10-27 22:39 ` Benjamin Herrenschmidt
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=45411F14.6020308@246tNt.com \
--to=tnt@246tnt$(echo .)com \
--cc=grant.likely@secretlab$(echo .)ca \
--cc=linuxppc-embedded@ozlabs$(echo .)org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
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