On Sat, Jul 07, 2007 at 07:12:49PM +0100, Adrian McMenamin wrote:
> On Sat, 2007-07-07 at 15:54 +0100, Adrian McMenamin wrote:
> > This is a bit of guesswork, but it does mean I get output - at least tux
> > sits in the top left hand corner of the screen... is it correct?
> >
> > Submitted by Adrian McMenamin <ad...@mc...>
> >
> >
> > diff -ruN a/pvr2fb.c b/pvr2fb.c
> > --- a/pvr2fb.c 2007-07-07 15:49:41.000000000 +0100
> > +++ b/pvr2fb.c 2007-07-07 15:48:49.000000000 +0100
> > @@ -192,7 +192,7 @@
> >
> > #ifdef CONFIG_SH_DMA
> > static unsigned int shdma = PVR2_CASCADE_CHAN;
> > -static unsigned int pvr2dma = ONCHIP_NR_DMA_CHANNELS;
> > +static unsigned int pvr2dma = PVR2_NR_DMA_CHANNELS;
> > #endif
> >
>
> I've looked at this a bit more and the above doesn't seem to be the fix
> - PVR_NR_DMA_CHANNELS is set 1 but setting pvr2dma to 2 also allows the
> display of tux (if nothing else - rest of the screen is blue lines)
>
There are a few things to be aware of here. First, the DMAC is only used
in the write path for user buffers, it's not used directly by the kernel,
so if you are having problems booting, this is another issue entirely.
pvr2dma in this context is the virtual channel number of the pvr2.
Traditionally we've done SH, G2, and PVR2 channels stacked on top of each
other, with the virtual channel being hardcoded. Obviously this is
something that we want to move off of, but I've put it off as this
requires quite a bit of driver model refactoring of the existing SH DMA
API if we want to do it cleanly.
You can add a bit of instrumentation at DMAC registration time to figure
out where the channels are being mapped, and make sure you have an
agreement in the pvr2dma case. The cascade channel is fixed in hardware,
but it's also 'virtual' in the sense that the ordering of DMAC
registration shouldn't even matter.
|
