linuxsh-dev

[HP6XX] Pcmcia problems

[Kristoffer E. <kri...@gm...>]

Greetings,

Thoughts appreciated.

IRQ 36 is main hd64461 IRQ (all IRQ between 64->80 ends up here)
IRQ 78 is setup to be used as a pcmcia_bridge. 
IRQ 79 is aquired to handle PCMCIA events.

A demux is put in place to take 78 IRQ's (since that is basicly the only thing that will happen) and transform them
into 79 IF interrupt was generated by pcmcia change.

extracts from code:
note. irq = 78, io_irq = 79, irq_flags = IRQF_DISABLED

request_irq(irq, hd64461_interrupt, irq_flags, "hd64461_ss-irq",sp))
irq_desc[io_irq].chip = &hd64461_ss_irq_type;
hd64461_register_irq_demux(sp->irq, hd64461_pcmcia_irq_demux, sp);

Now whenever I insert a pcmcia card I get:
'unexpected IRQ trap at vector 4f'
'irq 79, desc:8d2b8a20, depth 1, count: 0, unhandled: 0'
'handle_irq(): 8d031180, handle_bad_irq+0x0/0x2d0'
'chip(): 9d2e2af8, 0x8d2e2af8'
'action() : 00000000'
'IRQ_DISABLED set'

Due to printk's I can see that it did run through the hd64461_pcmcia_irq_demux and there quite correctly made 78 -> 79.

/Kristoffer

Re: Problem with IRQ0 in SH7705

[Cmmn Ml <cm...@ya...>]

Hello Paul,
   
  Thanks for pointing me where the problem is, I found my problem with the return value and got it fixed. Thanks again for your kind reply.
   
  Cmmn Ml
  

Paul Mundt <le...@li...> wrote:
  On Wed, Oct 03, 2007 at 07:32:39AM -0700, Cmmn Ml wrote:
> I'm working on SH 7705 Solution Engine board, my kernel is linux 2.6.16
> (after applying the SH linux stable patch relavant to this kernel
> version sh--stable--2.6.16). Currently I'm developing a driver which
> hanldes interrupt coming from IRQ0 processor pin. When I try to
> register the interrupt handler, I get an error message saying "irq
> event 32: bogus return value 7". The way I try to register the
> interrupt is
>
> When this code is executed, request_irq returns with 0 indicating
> success, but then it gives up the message ""irq event 32: bogus return
> value 7". When the interrupt comes, the execution goes into the
> interrupt handler as well.
> 
There are a couple of reasons you might get this message, and it all
relates to your IRQ handler. Your IRQ handler needs to return one of
IRQ_NONE (if it's not handling it) or IRQ_HANDLED, this printk gets
triggered if either a) your irqreturn_t is some bogus value, or b) the
IRQ is stuck.

As you didn't post the backtrace after that printk, it's difficult to
determine what the originating call path was. In the event that the IRQ
is stuck (ie, "99,900 of the previous 100,000 interrupts have not been
handled"), this will also trigger. So you might also have an issue with
the IRQ not being acked properly.


       
---------------------------------
 Check out  the hottest 2008 models today at Yahoo! Autos.

Re: QEMU - Current SuperH support

[Magnus D. <mag...@gm...>]

Hi Kristoffer,

On 10/5/07, Kristoffer Ericson <kri...@gm...> wrote:
> Greetings,
>
> Been meaning to ask you magnus, has there been any Qemu updates concerning SuperH?

Yes, the latest CVS of QEMU contains system emulation code that is
enough to start executing a certain SH kernel. It's quite primitive
still - no interrupts are delivered to the processor yet. I'm
currently working on fixing that up, expect to see more code posted in
the near future.

Have a look here for more information:

http://lists.gnu.org/archive/html/qemu-devel/2007-09/msg00530.html
http://lists.gnu.org/archive/html/qemu-devel/2007-10/msg00090.html

Regarding the user space emulator - it is possible to run a statically
linked busybox application using the sh4 emulator. The emulator
unfortunately still includes some bug which makes dynamically linked
apps crash.

Cheers,

/ magnus

QEMU - Current SuperH support

[Kristoffer E. <kri...@gm...>]

Greetings,

Been meaning to ask you magnus, has there been any Qemu updates concerning SuperH?

Best wishes
Kristoffer Ericson

Re: A bug?

[Adrian M. <ad...@ne...>]

On Thu, October 4, 2007 11:17 am, Paul Mundt wrote:

>
> You may just want to disable some of the lockdep related debug options to
> get it booting in the interim. Also, if you could post your .config, it
> would be helpful, as I've not seen this particular badness anywhere.
>

Hmmm, this was some time ago and I'd forgotten all about it. I will see if
I can recreate it (as you suggest i simply turned off the debug options
and got on with it)

Re: [PATCH] Fix SH DMAC code to handle PVR2 cascade

[Adrian M. <ad...@ne...>]

On Thu, October 4, 2007 11:01 am, Paul Mundt wrote:
> So for PVR2 cascade, what does the CHCR value work out to? Both
> CHCR_TS_MASK and CHCR_TS_SHIFT haven't changed for SH7750, so this
> suggests that either the CHCR value is just wrong or we've had a
> long-standing bug with the CHCR.TS mask.
>
> Either way, we are not going to hardcode a ts_shift value when the CHCR
> has all of the information encoded in it!
>

There *is* a long standing bug in CHCR_TS_MASK. It is meant to mask out
all but bits 6:4 but in fact only masks bits 5 and 4. If it is set to 0x70
and not 0x30 this should work - though as usual I cannot make a patch to
check this out at the moment.

Re: Debugging memory allocation

[Paul M. <le...@li...>]

On Wed, Sep 12, 2007 at 08:50:33PM +0100, Adrian McMenamin wrote:
> I don't know if this is just G2 flakiness, but if I start playing sound
> and then start hotplugging devices then I will sometimes get this sort
> of oops (these don't down the system but they can make it unstable) -
> any clues as to what might be the issue (these are now quite old -rc2?
> kernels...)... just wondering if anybody can see anything obvious?
> 
> [   95.916012] Maple bus detaching at (0, 2)
> [   96.208858] Unable to handle kernel paging request at virtual address
> dfff0800
> [   96.215707] pc = 8c00e480
> [   96.218317] *pde = 00000000
> [   96.221194] Oops: 0001 [#1]
> [   96.224005] Modules linked in: snd_aica snd_pcm_oss snd_pcm snd_timer
> snd_page_alloc snd_mixer_oss snd soundcore maple_keyb
> [   96.235500] 
> [   96.237035] Pid : 1842, Comm:                    [
> [   96.241993] PC is at __copy_user_page+0x28/0x54

You've faulted on a fixmap slot, perhaps you've hit a race with the page
colouring code. Can you try with write-through caching enabled?

Re: A bug?

[Paul M. <le...@li...>]

On Sat, Sep 15, 2007 at 12:19:07AM +0100, Adrian McMenamin wrote:
> I have just turned on a whole host of debugging stuff in my kernel and
> now it won't boot because of the issue below - is this anything I need
> to formally file?
> 
> [    0.186328] ------------[ cut here ]------------
> [    0.191626] Badness at kernel/fork.c:1000
> [    0.196220] 
> [    0.197930] Pid : 0, Comm:              swapper
> [    0.203140] PC is at copy_process+0x13d2/0x1bc0
> [    0.208336] PC  : 8c017012 SP  : 8c2d9e78 SR  : 40008101 TEA :
> 00000000    Not tainted

Ho hum. So according to SR, hardirqs _are_ enabled, but the lockdep
accounting is confused:

> [    0.284087] [<8c03d860>] trace_hardirqs_off+0x0/0xa0

in that they're implied off here. So there's at least something slightly
broken with the irqflags tracing, it's also broken on SH-2 (in a
different path completely) whilst attempting to do lock correctness
proving, so it will need a bit more debugging.

You may just want to disable some of the lockdep related debug options to
get it booting in the interim. Also, if you could post your .config, it
would be helpful, as I've not seen this particular badness anywhere.

Re: [PATCH] Fix SH DMAC code to handle PVR2 cascade

[Paul M. <le...@li...>]

On Wed, Oct 03, 2007 at 04:41:37PM +0100, Adrian McMenamin wrote:
> On Wed, October 3, 2007 7:18 am, Paul Mundt wrote:
> > On Tue, Oct 02, 2007 at 10:09:27PM +0100, Adrian McMenamin wrote:
> >> Fix SH DMAC code to correctly handle PVR2 cascade DMA.
> >>
> >> This updates http://lkml.org/lkml/2007/10/2/276
> >>
> >> (I decided it was better to have the true size of the transfer put in
> >> via the API and refactor this here. And calc_xmit_shift(chan) should
> >> return 5 but only returns 3 so I've not used it here)
> >>
> > It would be helpful to know why calc_xmit_shift() is broken here rather
> > than just coding around it, as this will have implications for the other
> > DMA channels on SH7091/SH7750.
> 
> 
> >From include/asm-sh/cpu-sh4/dma.h
> 
> 53 /*
> 54  * The DMA count is defined as the number of bytes to transfer.
> 55  */
> 56 static unsigned int ts_shift[] __maybe_unused = {
> 57         [XMIT_SZ_64BIT]         = 3,
> 58         [XMIT_SZ_8BIT]          = 0,
> 59         [XMIT_SZ_16BIT]         = 1,
> 60         [XMIT_SZ_32BIT]         = 2,
> 61         [XMIT_SZ_256BIT]        = 5,
> 62 };
> 63 #endif
> 
> ie ts_shift returns the number of bytes per transfer, but is then used as
> a bit shift:
> 
Er, no it doesn't, try again. ts_shift returns the transfer size _shift_.
The comment refers to the DMA count, which is a different matter. Your
32-byte transfer where you want the >> 5 shift == ts_shift[XMIT_SZ_256BIT],
and there's nothing wrong with that. So the issue becomes why you don't
get a ts_shift[] offset of XMIT_SZ_256BIT for that channel, and that's
the bug that has to be fixed.

> 45 /*
> 46  * We determine the correct shift size based off of the CHCR transmit size
> 47  * for the given channel. Since we know that it will take:
> 48  *
> 49  *      info->count >> ts_shift[transmit_size]
> 50  *
> 51  * iterations to complete the transfer.
> 52  */
> 53 static inline unsigned int calc_xmit_shift(struct dma_channel *chan)
> 54 {
> 55         u32 chcr = ctrl_inl(CHCR[chan->chan]);
> 56
> 57         return ts_shift[(chcr & CHCR_TS_MASK)>>CHCR_TS_SHIFT];
> 58 }
> 
So for PVR2 cascade, what does the CHCR value work out to? Both
CHCR_TS_MASK and CHCR_TS_SHIFT haven't changed for SH7750, so this
suggests that either the CHCR value is just wrong or we've had a
long-standing bug with the CHCR.TS mask.

Either way, we are not going to hardcode a ts_shift value when the CHCR
has all of the information encoded in it!

Re: Requesting specific memory adress

[Paul M. <le...@li...>]

On Wed, Oct 03, 2007 at 09:38:44PM -0700, Kristoffer Ericson wrote:
> We are testing a new way of doing suspend on the hp6xx (&hp7xx) but in
> order for this to work I need to set aside a certain adress where
> suspend->return adress is stored. Now, is it possible to grab this
> memory specificly?
> 
Set it up as a resource and flag it as IORESOURCE_MEM | IORESOURCE_BUSY.
This will prevent anything else from accidentally mapping over it.

Re: Problem with IRQ0 in SH7705

[Paul M. <le...@li...>]

On Wed, Oct 03, 2007 at 07:32:39AM -0700, Cmmn Ml wrote:
>    I'm working on SH 7705 Solution Engine board, my kernel is linux 2.6.16
>    (after applying the SH linux stable patch relavant to this kernel
>    version sh--stable--2.6.16). Currently I'm developing a driver which
>    hanldes interrupt coming from IRQ0 processor pin. When I try to
>    register the interrupt handler, I get an error message saying "irq
>    event 32: bogus return value 7". The way I try to register the
>    interrupt is
>
>    When this code is executed, request_irq returns with 0 indicating
>    success, but then it gives up the message ""irq event 32: bogus return
>    value 7". When the interrupt comes, the execution goes into the
>    interrupt handler as well.
> 
There are a couple of reasons you might get this message, and it all
relates to your IRQ handler. Your IRQ handler needs to return one of
IRQ_NONE (if it's not handling it) or IRQ_HANDLED, this printk gets
triggered if either a) your irqreturn_t is some bogus value, or b) the
IRQ is stuck.

As you didn't post the backtrace after that printk, it's difficult to
determine what the originating call path was. In the event that the IRQ
is stuck (ie, "99,900 of the previous 100,000 interrupts have not been
handled"), this will also trigger. So you might also have an issue with
the IRQ not being acked properly.

Requesting specific memory adress

[Kristoffer E. <kri...@gm...>]

Greetings,

We are testing a new way of doing suspend on the hp6xx (&hp7xx) but in order for this to work I need to set aside a certain adress where suspend->return adress is stored. Now, is it possible to grab this memory specificly?

/Kristoffer

Re: [PATCH] Fix SH DMAC code to handle PVR2 cascade

[Adrian M. <ad...@ne...>]

On Wed, October 3, 2007 7:18 am, Paul Mundt wrote:
> On Tue, Oct 02, 2007 at 10:09:27PM +0100, Adrian McMenamin wrote:
>> Fix SH DMAC code to correctly handle PVR2 cascade DMA.
>>
>> This updates http://lkml.org/lkml/2007/10/2/276
>>
>> (I decided it was better to have the true size of the transfer put in
>> via the API and refactor this here. And calc_xmit_shift(chan) should
>> return 5 but only returns 3 so I've not used it here)
>>
> It would be helpful to know why calc_xmit_shift() is broken here rather
> than just coding around it, as this will have implications for the other
> DMA channels on SH7091/SH7750.


>From include/asm-sh/cpu-sh4/dma.h

53 /*
54  * The DMA count is defined as the number of bytes to transfer.
55  */
56 static unsigned int ts_shift[] __maybe_unused = {
57         [XMIT_SZ_64BIT]         = 3,
58         [XMIT_SZ_8BIT]          = 0,
59         [XMIT_SZ_16BIT]         = 1,
60         [XMIT_SZ_32BIT]         = 2,
61         [XMIT_SZ_256BIT]        = 5,
62 };
63 #endif

ie ts_shift returns the number of bytes per transfer, but is then used as
a bit shift:

45 /*
46  * We determine the correct shift size based off of the CHCR transmit size
47  * for the given channel. Since we know that it will take:
48  *
49  *      info->count >> ts_shift[transmit_size]
50  *
51  * iterations to complete the transfer.
52  */
53 static inline unsigned int calc_xmit_shift(struct dma_channel *chan)
54 {
55         u32 chcr = ctrl_inl(CHCR[chan->chan]);
56
57         return ts_shift[(chcr & CHCR_TS_MASK)>>CHCR_TS_SHIFT];
58 }


(From arch/sh/drivers/dma/dma-sh.c)

I'm not anywhere where I can fix this at the moment, but i am sure it
could be patched quite trivally.

Problem with IRQ0 in SH7705

[Cmmn Ml <cm...@ya...>]

Hello,
   
  This may not be something interesting to the general community, because SH7705 is not now widley used. But if someone can give some thoughts, it will be a great help for me.
  
I'm working on SH 7705 Solution Engine board, my kernel is linux 2.6.16 (after applying the SH linux stable patch relavant to this kernel version sh--stable--2.6.16). Currently I'm developing a driver which hanldes interrupt coming from IRQ0 processor pin. When I try to register the interrupt handler, I get an error message saying "irq event 32: bogus return value 7". The way I try to register the interrupt is 
   
   if(request_irq(32, interrupt_handler, SA_INTERRUPT, "IRQ0_INT", NULL) == 0)
 {
         printk("interrupt_handler registered\r\n"); 
  }
   
  When this code is executed, request_irq returns with 0 indicating success, but then it gives up the message ""irq event 32: bogus return value 7". When the interrupt comes, the execution goes into the interrupt handler as well.
   
  The value 32 is the irq number I'm requesting (which is relevent to IRQ0) and I don't know what is 7. FYI : I'm setting the priority of IRQ0 as 7 in IPRC register.
   
  Were there any known problems in 2.6.16 kernel with IRQ0 in 7705, If anyone can give some thoughts on this, it'll be a great.
   
  Thanks in advance.
   
  Cmmn Ml

       
---------------------------------
Moody friends. Drama queens. Your life? Nope! - their life, your story.
 Play Sims Stories at Yahoo! Games. 

Re: [PATCH] Fix SH DMAC code to handle PVR2 cascade

[Paul M. <le...@li...>]

On Tue, Oct 02, 2007 at 10:09:27PM +0100, Adrian McMenamin wrote:
> Fix SH DMAC code to correctly handle PVR2 cascade DMA.
> 
> This updates http://lkml.org/lkml/2007/10/2/276
> 
> (I decided it was better to have the true size of the transfer put in
> via the API and refactor this here. And calc_xmit_shift(chan) should
> return 5 but only returns 3 so I've not used it here)
> 
It would be helpful to know why calc_xmit_shift() is broken here rather
than just coding around it, as this will have implications for the other
DMA channels on SH7091/SH7750.

Now that you've completely bypassed the rest of the SH-DMAC ->xfer_dma()
op, it's clear that the existing infrastructure needs a bit of rework for
dealing with the cascaded DMACs (especially for single-address mode only,
unidirectionally). It would be nice to get the mach-specific kludges for
cascade out of dma-sh entirely.

This can certainly be fixed for 2.6.24, though a larger overhaul is
2.6.25 material at this point.

[PATCH] Fix SH DMAC code to handle PVR2 cascade

[Adrian M. <ad...@ne...>]

Fix SH DMAC code to correctly handle PVR2 cascade DMA.

This updates http://lkml.org/lkml/2007/10/2/276

(I decided it was better to have the true size of the transfer put in
via the API and refactor this here. And calc_xmit_shift(chan) should
return 5 but only returns 3 so I've not used it here)


--- arch/sh/drivers/dma/dma-sh.c	2007/09/22 18:34:42	1.1
+++ arch/sh/drivers/dma/dma-sh.c	2007/10/02 20:53:49	1.3
@@ -150,6 +150,13 @@ static void sh_dmac_disable_dma(struct d
 
 static int sh_dmac_xfer_dma(struct dma_channel *chan)
 {
+	/* Handle Dreamcast PVR cascade */
+	if (mach_is_dreamcast() && chan->chan == PVR2_CASCADE_CHAN) {
+		ctrl_outl(chan->sar, SAR[chan->chan]);
+		/* Transfer in 32 byte blocks */
+		ctrl_outl((chan->count) >> 5, DMATCR[chan->chan]);
+		return 0;
+	}
 	/*
 	 * If we haven't pre-configured the channel with special flags, use
 	 * the defaults.
@@ -159,26 +166,9 @@ static int sh_dmac_xfer_dma(struct dma_c
 
 	sh_dmac_disable_dma(chan);
 
-	/*
-	 * Single-address mode usage note!
-	 *
-	 * It's important that we don't accidentally write any value to SAR/DAR
-	 * (this includes 0) that hasn't been directly specified by the user if
-	 * we're in single-address mode.
-	 *
-	 * In this case, only one address can be defined, anything else will
-	 * result in a DMA address error interrupt (at least on the SH-4),
-	 * which will subsequently halt the transfer.
-	 *
-	 * Channel 2 on the Dreamcast is a special case, as this is used for
-	 * cascading to the PVR2 DMAC. In this case, we still need to write
-	 * SAR and DAR, regardless of value, in order for cascading to work.
-	 */
-	if (chan->sar || (mach_is_dreamcast() &&
-			  chan->chan == PVR2_CASCADE_CHAN))
+	if (chan->sar)
 		ctrl_outl(chan->sar, SAR[chan->chan]);
-	if (chan->dar || (mach_is_dreamcast() &&
-			  chan->chan == PVR2_CASCADE_CHAN))
+	if (chan->dar)
 		ctrl_outl(chan->dar, DAR[chan->chan]);
 
 	ctrl_outl(chan->count >> calc_xmit_shift(chan), DMATCR[chan->chan]);

Re: [PATCH] Fix SH DMA API so it works with PVR cascade

[Mike F. <va...@ge...>]

T24gVHVlc2RheSAwMiBPY3RvYmVyIDIwMDcsIEFkcmlhbiBNY01lbmFtaW4gd3JvdGU6Cj4gK6Cg
oKCgoKAvKiBIYW5kbGUgRHJlYW1jYXN0IFBWUiBjYXNjYWRlICovCj4gK6CgoKCgoKBpZiAobWFj
aF9pc19kcmVhbWNhc3QoKSAmJiBjaGFuLT5jaGFuID09IFBWUjJfQ0FTQ0FERV9DSEFOKQo+ICug
oKCgoKCgewo+ICugoKCgoKCgoKCgoKCgoKBjdHJsX291dGwoY2hhbi0+c2FyLCBTQVJbY2hhbi0+
Y2hhbl0pOwoKY3VkZGxlIHRoYXQgeyBwbGVhc2UKLW1pa2UK

[PATCH] Fix up SH DMAC code to correctly handle PVR DMA

[Adrian M. <ad...@ne...>]

This patch fixes up SH DMAC code to correctly handle channel 2 DMA on
the Dreamcast.

Points to note:

* Currently the comments say that dar must be set - this appears to be
incorrect
* Currently the code uses calc_xmit_shift(chan) though that fuction does
not appear to work - this code relies on a division by 32 before the
xfer function is called
* Currently the code supports reading and writing, but the hardware only
supports writing

Signed-off by Adrian McMenamin <ad...@mc...>

--- arch/sh/drivers/dma/dma-sh.c	2007/09/22 18:34:42	1.1
+++ arch/sh/drivers/dma/dma-sh.c	2007/09/22 18:37:28	1.2
@@ -150,6 +150,13 @@ static void sh_dmac_disable_dma(struct d
 
 static int sh_dmac_xfer_dma(struct dma_channel *chan)
 {
+	/* Handle Dreamcast PVR cascade */
+	if (mach_is_dreamcast() && chan->chan == PVR2_CASCADE_CHAN)
+	{
+		ctrl_outl(chan->sar, SAR[chan->chan]);
+		ctrl_outl(chan->count, DMATCR[chan->chan]);
+		return 0;
+	}
 	/*
 	 * If we haven't pre-configured the channel with special flags, use
 	 * the defaults.
@@ -159,26 +166,9 @@ static int sh_dmac_xfer_dma(struct dma_c
 
 	sh_dmac_disable_dma(chan);
 
-	/*
-	 * Single-address mode usage note!
-	 *
-	 * It's important that we don't accidentally write any value to SAR/DAR
-	 * (this includes 0) that hasn't been directly specified by the user if
-	 * we're in single-address mode.
-	 *
-	 * In this case, only one address can be defined, anything else will
-	 * result in a DMA address error interrupt (at least on the SH-4),
-	 * which will subsequently halt the transfer.
-	 *
-	 * Channel 2 on the Dreamcast is a special case, as this is used for
-	 * cascading to the PVR2 DMAC. In this case, we still need to write
-	 * SAR and DAR, regardless of value, in order for cascading to work.
-	 */
-	if (chan->sar || (mach_is_dreamcast() &&
-			  chan->chan == PVR2_CASCADE_CHAN))
+	if (chan->sar)
 		ctrl_outl(chan->sar, SAR[chan->chan]);
-	if (chan->dar || (mach_is_dreamcast() &&
-			  chan->chan == PVR2_CASCADE_CHAN))
+	if (chan->dar)
 		ctrl_outl(chan->dar, DAR[chan->chan]);
 
 	ctrl_outl(chan->count >> calc_xmit_shift(chan), DMATCR[chan->chan]);

[PATCH] Fix SH DMA API so it works with PVR cascade

[Adrian M. <ad...@ne...>]

This patch - hope it is not too late for 2.6.24 queue - gets the SH DMA
API to work properly for the PVR2 DMA cascade.

Currently the comment suggests that dar should not be set for the write
DMA but the API forces a set. This code fixes that. Furthermore there is
no read on the PVR2 CASCADE DMA (at least for the PVR) so that code is
removed.

Submitted-by: Adrian McMenamin <ad...@mc...>

--- arch/sh/drivers/dma/dma-sh.c	2007/09/22 18:34:42	1.1
+++ arch/sh/drivers/dma/dma-sh.c	2007/09/22 18:37:28	1.2
@@ -150,6 +150,13 @@ static void sh_dmac_disable_dma(struct d
 
 static int sh_dmac_xfer_dma(struct dma_channel *chan)
 {
+	/* Handle Dreamcast PVR cascade */
+	if (mach_is_dreamcast() && chan->chan == PVR2_CASCADE_CHAN)
+	{
+		ctrl_outl(chan->sar, SAR[chan->chan]);
+		ctrl_outl(chan->count, DMATCR[chan->chan]);
+		return 0;
+	}
 	/*
 	 * If we haven't pre-configured the channel with special flags, use
 	 * the defaults.
@@ -159,26 +166,9 @@ static int sh_dmac_xfer_dma(struct dma_c
 
 	sh_dmac_disable_dma(chan);
 
-	/*
-	 * Single-address mode usage note!
-	 *
-	 * It's important that we don't accidentally write any value to SAR/DAR
-	 * (this includes 0) that hasn't been directly specified by the user if
-	 * we're in single-address mode.
-	 *
-	 * In this case, only one address can be defined, anything else will
-	 * result in a DMA address error interrupt (at least on the SH-4),
-	 * which will subsequently halt the transfer.
-	 *
-	 * Channel 2 on the Dreamcast is a special case, as this is used for
-	 * cascading to the PVR2 DMAC. In this case, we still need to write
-	 * SAR and DAR, regardless of value, in order for cascading to work.
-	 */
-	if (chan->sar || (mach_is_dreamcast() &&
-			  chan->chan == PVR2_CASCADE_CHAN))
+	if (chan->sar)
 		ctrl_outl(chan->sar, SAR[chan->chan]);
-	if (chan->dar || (mach_is_dreamcast() &&
-			  chan->chan == PVR2_CASCADE_CHAN))
+	if (chan->dar)
 		ctrl_outl(chan->dar, DAR[chan->chan]);
 
 	ctrl_outl(chan->count >> calc_xmit_shift(chan), DMATCR[chan->chan]);

Re: sh64: unmaintained sh64 MAkefile's...

[Paul M. <le...@li...>]

On Sun, Sep 30, 2007 at 08:34:19PM +0200, Sam Ravnborg wrote:
> Could someone take a look at the following files:
> arch/sh64/mach-harp/Makefile 
> arch/sh64/mach-romram/Makefile 
> arch/sh64/mach-sim/Makefile
> 
> I notice they still include Rules.make and used O_TARGET.
> Both items have vanished looong time ago from kbuild and
> I assume this is rather unmaintained code.
> Could someone either fix it or kill it.
> 
These were from platforms that existed internally but never really made
it out in the wild. At least mach-sim is worth fixing up, I'll take a
look at that and the others and queue something up for 2.6.24.

Re: [PATCH] Add TV (RGB) support to Dreamcast PVR driver

[Paul M. <le...@li...>]

On Fri, Sep 28, 2007 at 12:22:04PM +0100, Adrian McMenamin wrote:
> Add support for RGB output to the Dreamcast PVR2 frame buffer driver.
> 
> Signed-off by Adrian McMenamin <ad...@mc...>
> 
Looks fine, I'll add it to my 2.6.24 queue, thanks.

[PATCH] Add TV (RGB) support to Dreamcast PVR driver

[Adrian M. <lkm...@gm...>]

Add support for RGB output to the Dreamcast PVR2 frame buffer driver.

Signed-off by Adrian McMenamin <ad...@mc...>


--- drivers/video/pvr2fb.c	2007/09/22 18:34:42	1.6
+++ drivers/video/pvr2fb.c	2007/09/23 00:04:31	1.7
@@ -667,6 +667,8 @@ static int pvr2_init_cable(void)
 	  related */
 	if (cable_type == CT_COMPOSITE)
 		fb_writel(3 << 8, VOUTC);
+	else if (cable_type == CT_RGB)
+		fb_writel(1 << 9, VOUTC);
 	else
 		fb_writel(0, VOUTC);

[patch 6/7] Use extended crashkernel command line on sh

[Bernhard W. <bw...@su...>]

This patch removes the crashkernel parsing from arch/sh/kernel/machine_kexec.c
and calls the generic function, introduced in the generic patch, in
setup_bootmem_allocator().

This is necessary because the amount of System RAM must be known in this
function now because of the new syntax.

NOTE: Due to the lack of a SH processor, this patch is untested (and
uncompiled). Because the code in that area is quite similar as i386/x86_64
(contrary to PPC and IA64), it should compile and work. However, if someone of
the SH people could test for me and provide feedback, that would be very nice.


Signed-off-by: Bernhard Walle <bw...@su...>
Acked-by: Paul Mundt <le...@li...>

---
 arch/sh/kernel/machine_kexec.c |   21 ---------------------
 arch/sh/kernel/setup.c         |   38 +++++++++++++++++++++++++++++++++-----
 2 files changed, 33 insertions(+), 26 deletions(-)

--- a/arch/sh/kernel/machine_kexec.c
+++ b/arch/sh/kernel/machine_kexec.c
@@ -104,24 +104,3 @@ NORET_TYPE void machine_kexec(struct kim
 	(*rnk)(page_list, reboot_code_buffer, image->start, vbr_reg);
 }
 
-/* crashkernel=size@addr specifies the location to reserve for
- * a crash kernel.  By reserving this memory we guarantee
- * that linux never sets it up as a DMA target.
- * Useful for holding code to do something appropriate
- * after a kernel panic.
- */
-static int __init parse_crashkernel(char *arg)
-{
-	unsigned long size, base;
-	size = memparse(arg, &arg);
-	if (*arg == '@') {
-		base = memparse(arg+1, &arg);
-		/* FIXME: Do I want a sanity check
-		 * to validate the memory range?
-		 */
-		crashk_res.start = base;
-		crashk_res.end   = base + size - 1;
-	}
-	return 0;
-}
-early_param("crashkernel", parse_crashkernel);
--- a/arch/sh/kernel/setup.c
+++ b/arch/sh/kernel/setup.c
@@ -128,6 +128,37 @@ static void __init register_bootmem_low_
 	free_bootmem(PFN_PHYS(curr_pfn), PFN_PHYS(pages));
 }
 
+#ifdef CONFIG_KEXEC
+static void __init reserve_crashkernel(void)
+{
+	unsigned long long free_mem;
+	unsigned long long crash_size, crash_base;
+	int ret;
+
+	free_mem = ((unsigned long long)max_low_pfn - min_low_pfn) << PAGE_SHIFT;
+
+	ret = parse_crashkernel(boot_command_line, free_mem,
+			&crash_size, &crash_base);
+	if (ret == 0 && crash_size) {
+		if (crash_base > 0) {
+			printk(KERN_INFO "Reserving %ldMB of memory at %ldMB "
+					"for crashkernel (System RAM: %ldMB)\n",
+					(unsigned long)(crash_size >> 20),
+					(unsigned long)(crash_base >> 20),
+					(unsigned long)(free_mem >> 20));
+			crashk_res.start = crash_base;
+			crashk_res.end   = crash_base + crash_size - 1;
+			reserve_bootmem(crash_base, crash_size);
+		} else
+			printk(KERN_INFO "crashkernel reservation failed - "
+					"you have to specify a base address\n");
+	}
+}
+#else
+static inline void __init reserve_crashkernel(void)
+{}
+#endif
+
 void __init setup_bootmem_allocator(unsigned long free_pfn)
 {
 	unsigned long bootmap_size;
@@ -189,11 +220,8 @@ void __init setup_bootmem_allocator(unsi
 		}
 	}
 #endif
-#ifdef CONFIG_KEXEC
-	if (crashk_res.start != crashk_res.end)
-		reserve_bootmem(crashk_res.start,
-			crashk_res.end - crashk_res.start + 1);
-#endif
+
+	reserve_crashkernel();
 }
 
 #ifndef CONFIG_NEED_MULTIPLE_NODES

-- 

Re: [PATCH/RFC] PVR2 DMA fix

[Adrian M. <ad...@ne...>]

On Sun, 2007-09-23 at 16:21 +0900, Paul Mundt wrote:
> On Sat, Sep 22, 2007 at 02:16:30PM +0100, Adrian McMenamin wrote:
> > The code for PVR2 DMA in the kernel is currently completely broken at
> > both hardware handling and algorithmic levels and more than likely to
> > cash a fatal crash if used.
> > 
> "Completely" is a bit of an overstatement. I had writes working with it
> without using the TA and had the PVR2 DMAC completion IRQ firing in the
> ->write() path without any difficulty. The main issue is that it was very
> sensitive, and would immediately stop working if something on the SH DMAC
> cascade side was misconfigured.


I'm at a loss to see how it worked at all! It was true that the first
transfer would work if it was less than a page long, but no susbsequent
transfer would and the contiguity check ought to have blown up every
time because of an out-by-one fault in checking the number of pages.

Also the code slept in the interrupt context but I know you knew that
because it was a debugging message :)

> 
> > This patch fixes the code and it seems to work well. I know it is not up
> > to the standards required to go to mainline yet, but any commentary on
> > it would be helpful.
> > 
> It's certainly a good start, there's obviously more information to go on
> these days then there was back when this was initially written, and it's
> good to see that someone is actually carrying it forward :-)
> 
> I suppose the main thing to note is that the ->write() path is really a
> useless place to do DMA. Most applications mmap() the framebuffer and
> dirty pages all over the place, which this simply won't catch. The idea
> behind the ->write() path was just to have something we could trivially
> test via things like cat /dev/urandom > /dev/fb0 and so on.
> 
> Ideally this should be plugged in via the fb deferred I/O, now that we
> can build scatterlists of dirtied pages in the mmap() path and submit 
> those back in one shot. hecubafb currently uses this, but not for DMA.
> The DMA work should be submitted by the ->deferred_io() callback, which
> you can probably just rip out of the write path for better utilization.
> This is really the way we want to go for fb DMA in general.


I have got a patch now that handles all this using the SH DMA API but...

What I now understand (or think I do) is that "texture" (which is what
you are really transferring) isn't the same as a bitmap and you have to
give the TA commands to handle how it is rendered. Not really versed in
the ways of 3D graphics so this is slow going.

I am away for a few days now but if anybody has a burning desire to mess
with the code they can look here:
http://newgolddream.dyndns.info/cgi-bin/cvsweb/aica/pvr2/

Re: [PATCH/RFC] PVR2 DMA fix

[Paul M. <le...@li...>]

On Sat, Sep 22, 2007 at 02:16:30PM +0100, Adrian McMenamin wrote:
> The code for PVR2 DMA in the kernel is currently completely broken at
> both hardware handling and algorithmic levels and more than likely to
> cash a fatal crash if used.
> 
"Completely" is a bit of an overstatement. I had writes working with it
without using the TA and had the PVR2 DMAC completion IRQ firing in the
->write() path without any difficulty. The main issue is that it was very
sensitive, and would immediately stop working if something on the SH DMAC
cascade side was misconfigured.

> This patch fixes the code and it seems to work well. I know it is not up
> to the standards required to go to mainline yet, but any commentary on
> it would be helpful.
> 
It's certainly a good start, there's obviously more information to go on
these days then there was back when this was initially written, and it's
good to see that someone is actually carrying it forward :-)

I suppose the main thing to note is that the ->write() path is really a
useless place to do DMA. Most applications mmap() the framebuffer and
dirty pages all over the place, which this simply won't catch. The idea
behind the ->write() path was just to have something we could trivially
test via things like cat /dev/urandom > /dev/fb0 and so on.

Ideally this should be plugged in via the fb deferred I/O, now that we
can build scatterlists of dirtied pages in the mmap() path and submit 
those back in one shot. hecubafb currently uses this, but not for DMA.
The DMA work should be submitted by the ->deferred_io() callback, which
you can probably just rip out of the write path for better utilization.
This is really the way we want to go for fb DMA in general.