status of mpc52xx with arch=powerpc?
Sylvain Munaut
tnt at 246tNt.com
Fri Oct 27 06:48:20 EST 2006
Grant Likely wrote:
> On 10/26/06, John Rigby <jcrigby at 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
More information about the Linuxppc-embedded
mailing list