DMA Interrupts

Has anyone already programmed DMA Interrupts on PXA270?

It's been a while since I started doing that. I could easily transfer data
In or Out, With or Without the use of descriptors, but when i wanted to
enable some interrupt (I am mostly interested in DCSR_ENDINTR)
the system crashed at some point.

The following steps summarize the test procedure i use:

1) Allocate N descriptors and buffers
2) Set up the Descriptors
3) Start the transfer
4) Poll a global variable until the IST flags it or until the loop times
out.
5) Stop the transfer (it hopefully should be over anyway)
6) Deallocate everything
The IST simply counts the times and ENDINTR is fired.

Now if i don't enable the IRQs (and poll the STOPINTR flag instead)
everything
works fine. BUT! most of the time when i enable some IRQ the system crashes.

I tried BTUART and SPI. BTUART really can't help itself but on rare
occasions, SPI succeeded every now and then when it felt like it, instead.
It all seems so aleatory.

Besides, when a DMA IRQ is enabled the OS crashes even when i don't set up
an IST. So i guess it doesn't depend on the IST (unless DMA needs the IST to
reset the IRQ in any case)

Have any clue?

Steve
Thu Dec 29 12:04:30 CST 2005

Sounds like a bug in the ISR for the DMA. If you can poll for the bit and
things work but with a performance issue due to polling then the crash is
almost certainly due to improper ISR handling. (Possible not clearing the
interrupt correctly before returning the SYSINTR? Or maybe clearing the
wrong one? so that once the ISR returns it is still pending and thus
retriggered as soon as interrupts are re-enabled again.

--
Steve Maillet
EmbeddedFusion
www.EmbeddedFusion.com
smaillet at EmbeddedFusion dot com

bluesphere
Thu Dec 29 16:49:31 CST 2005

You could be right Steve,

but i'll give you more scenario:

DMA IRQ is certainly shared. The AC97 controller is pretty eager and
requests the interrupt first. So i'm left with only one choice, that is
loading an IISR.

I use GIISR and you know what it does. If i remember the code, GIISR.DLL
doesn't clear any interrupt, it just returns the SYSINTR correspondingly. I
clear the interrupt in the IST. Is it too late? The WAVEDEV driver example
in PB5 clears the DMA IRQ in the IST either. (INTEL's DOC talks about an
issue with the RUN bit, but i guess i managed that)

Anyway today i decided to get rid of the AC97 driver. The PXA270's "request
to channel mapping" registers show that only the sound driver uses DMA
transfers. (As in the MAINSTONEII code), the rest is a desert land.

Without the AC97, i guess i was in a non-shared situation. I handled the IRQ
without any ISR. It crashed again!



"Steve Maillet (eMVP)" <nospam1@EntelechyConsulting.com> wrote in message
news:O4abUJKDGHA.2356@tk2msftngp13.phx.gbl...
> Sounds like a bug in the ISR for the DMA. If you can poll for the bit and
> things work but with a performance issue due to polling then the crash is
> almost certainly due to improper ISR handling. (Possible not clearing the
> interrupt correctly before returning the SYSINTR? Or maybe clearing the
> wrong one? so that once the ISR returns it is still pending and thus
> retriggered as soon as interrupts are re-enabled again.
>
> --
> Steve Maillet
> EmbeddedFusion
> www.EmbeddedFusion.com
> smaillet at EmbeddedFusion dot com
>
>

bc
Thu Dec 29 23:47:49 CST 2005

I hope i can help to you.

I remeber that the BSP has a DMA driver. you don't need to check DMA IRQ,
you should get a system event from DMA driver.

DMA driver: dmawince.c function: DmacIntrThread

Besides, you don't need to clear IRQ too, when you call InterruptDone
function, the system will reenable it.



"bluesphere" <ads_box@hotmail.com> wrote in message
news:43b46831$0$1065$4fafbaef@reader2.news.tin.it...
> You could be right Steve,
>
> but i'll give you more scenario:
>
> DMA IRQ is certainly shared. The AC97 controller is pretty eager and
> requests the interrupt first. So i'm left with only one choice, that is
> loading an IISR.
>
> I use GIISR and you know what it does. If i remember the code, GIISR.DLL
> doesn't clear any interrupt, it just returns the SYSINTR correspondingly.
> I
> clear the interrupt in the IST. Is it too late? The WAVEDEV driver example
> in PB5 clears the DMA IRQ in the IST either. (INTEL's DOC talks about an
> issue with the RUN bit, but i guess i managed that)
>
> Anyway today i decided to get rid of the AC97 driver. The PXA270's
> "request
> to channel mapping" registers show that only the sound driver uses DMA
> transfers. (As in the MAINSTONEII code), the rest is a desert land.
>
> Without the AC97, i guess i was in a non-shared situation. I handled the
> IRQ
> without any ISR. It crashed again!
>
>
>
> "Steve Maillet (eMVP)" <nospam1@EntelechyConsulting.com> wrote in message
> news:O4abUJKDGHA.2356@tk2msftngp13.phx.gbl...
>> Sounds like a bug in the ISR for the DMA. If you can poll for the bit and
>> things work but with a performance issue due to polling then the crash is
>> almost certainly due to improper ISR handling. (Possible not clearing the
>> interrupt correctly before returning the SYSINTR? Or maybe clearing the
>> wrong one? so that once the ISR returns it is still pending and thus
>> retriggered as soon as interrupts are re-enabled again.
>>
>> --
>> Steve Maillet
>> EmbeddedFusion
>> www.EmbeddedFusion.com
>> smaillet at EmbeddedFusion dot com
>>
>>
>
>

bluesphere
Fri Dec 30 02:22:42 CST 2005

In which BSP is dmawince.c? I don't have that file.

If you could send me the files related to that driver you would do me a
favour. I could at least check the way it manages the DMA.

I don't clear the DMA IRQ, i clear the DCSR_XXXINTR flags.


"bc" <bc@bc.bc> wrote in message
news:u%237SLTQDGHA.312@TK2MSFTNGP09.phx.gbl...
> I hope i can help to you.
>
> I remeber that the BSP has a DMA driver. you don't need to check DMA IRQ,
> you should get a system event from DMA driver.
>
> DMA driver: dmawince.c function: DmacIntrThread
>
> Besides, you don't need to clear IRQ too, when you call InterruptDone
> function, the system will reenable it.
>
>
>
> "bluesphere" <ads_box@hotmail.com> wrote in message
> news:43b46831$0$1065$4fafbaef@reader2.news.tin.it...
> > You could be right Steve,
> >
> > but i'll give you more scenario:
> >
> > DMA IRQ is certainly shared. The AC97 controller is pretty eager and
> > requests the interrupt first. So i'm left with only one choice, that is
> > loading an IISR.
> >
> > I use GIISR and you know what it does. If i remember the code, GIISR.DLL
> > doesn't clear any interrupt, it just returns the SYSINTR
correspondingly.
> > I
> > clear the interrupt in the IST. Is it too late? The WAVEDEV driver
example
> > in PB5 clears the DMA IRQ in the IST either. (INTEL's DOC talks about an
> > issue with the RUN bit, but i guess i managed that)
> >
> > Anyway today i decided to get rid of the AC97 driver. The PXA270's
> > "request
> > to channel mapping" registers show that only the sound driver uses DMA
> > transfers. (As in the MAINSTONEII code), the rest is a desert land.
> >
> > Without the AC97, i guess i was in a non-shared situation. I handled the
> > IRQ
> > without any ISR. It crashed again!
> >
> >
> >
> > "Steve Maillet (eMVP)" <nospam1@EntelechyConsulting.com> wrote in
message
> > news:O4abUJKDGHA.2356@tk2msftngp13.phx.gbl...
> >> Sounds like a bug in the ISR for the DMA. If you can poll for the bit
and
> >> things work but with a performance issue due to polling then the crash
is
> >> almost certainly due to improper ISR handling. (Possible not clearing
the
> >> interrupt correctly before returning the SYSINTR? Or maybe clearing the
> >> wrong one? so that once the ISR returns it is still pending and thus
> >> retriggered as soon as interrupts are re-enabled again.
> >>
> >> --
> >> Steve Maillet
> >> EmbeddedFusion
> >> www.EmbeddedFusion.com
> >> smaillet at EmbeddedFusion dot com
> >>
> >>
> >
> >
>
>

bc
Fri Dec 30 02:43:13 CST 2005

BSP: BSP_WM_50_PPC_PXA27x_V3_01_037_V8_Beta2_LV

Do you work on this BSP?

ads_box@hotmail.com
Is this your email address?

"bluesphere" <ads_box@hotmail.com> wrote in message
news:43b4ee81$0$1069$4fafbaef@reader4.news.tin.it...
> In which BSP is dmawince.c? I don't have that file.
>
> If you could send me the files related to that driver you would do me a
> favour. I could at least check the way it manages the DMA.
>
> I don't clear the DMA IRQ, i clear the DCSR_XXXINTR flags.

K
Fri Dec 30 03:30:34 CST 2005

How do you install the GIISR??
We have shared the DMA irq by Audio, SD host, M-Sys DOC and other peripheral
with GIISR.dll.
You may need to use IOCTL_HAL_REQUEST_SYSINTR to request a SYSINTR for each
driver that need to share the DMA IRQ.

"bluesphere" <ads_box@hotmail.com> ¼¶¼g©ó¶l¥ó·s»D:43b46831$0$1065$4fafbaef@reader2.news.tin.it...
> You could be right Steve,
>
> but i'll give you more scenario:
>
> DMA IRQ is certainly shared. The AC97 controller is pretty eager and
> requests the interrupt first. So i'm left with only one choice, that is
> loading an IISR.
>
> I use GIISR and you know what it does. If i remember the code, GIISR.DLL
> doesn't clear any interrupt, it just returns the SYSINTR correspondingly.
> I
> clear the interrupt in the IST. Is it too late? The WAVEDEV driver example
> in PB5 clears the DMA IRQ in the IST either. (INTEL's DOC talks about an
> issue with the RUN bit, but i guess i managed that)
>
> Anyway today i decided to get rid of the AC97 driver. The PXA270's
> "request
> to channel mapping" registers show that only the sound driver uses DMA
> transfers. (As in the MAINSTONEII code), the rest is a desert land.
>
> Without the AC97, i guess i was in a non-shared situation. I handled the
> IRQ
> without any ISR. It crashed again!
>
>
>

bluesphere
Fri Dec 30 04:07:36 CST 2005


I don't have the BSP you say. Yes, ads_box@hotmail.com is my address.


"bc" <bc@bc.bc> wrote in message
news:%23Wr3L1RDGHA.2912@tk2msftngp13.phx.gbl...
> BSP: BSP_WM_50_PPC_PXA27x_V3_01_037_V8_Beta2_LV
>
> Do you work on this BSP?
>
> ads_box@hotmail.com
> Is this your email address?
>
> "bluesphere" <ads_box@hotmail.com> wrote in message
> news:43b4ee81$0$1069$4fafbaef@reader4.news.tin.it...
> > In which BSP is dmawince.c? I don't have that file.
> >
> > If you could send me the files related to that driver you would do me a
> > favour. I could at least check the way it manages the DMA.
> >
> > I don't clear the DMA IRQ, i clear the DCSR_XXXINTR flags.
>
>

bluesphere
Fri Dec 30 04:44:37 CST 2005


This is how install the GIISR
-----------------------------------------------------------------------
KernelIoControl(IOCTL_HAL_REQUEST_SYSINTR, &m_Irq, sizeof(DWORD),
&m_SysIntr, sizeof(DWORD), NULL)
...
m_IsrHandle = LoadIntChainHandler(m_IsrDll, m_IsrHandler, (BYTE)m_Irq);
/*
where:
m_IsrDll = L"\\Windows\\giisr.dll";
m_IsrHandler = L"ISRHandler";
*/
....
m_Info.SysIntr = m_SysIntr;
KernelLibIoControl(m_IsrHandle, IOCTL_GIISR_INFO, &m_Info, sizeof(m_Info),
NULL, 0, NULL)
----------------------------------------------------------------------

The interrupts work pretty well "every now and mostly then" so i don't think
it depends on GIISR


"K. S. Huang" <ksh_AT_bsquare_DOT_com> wrote in message
news:%23hVzxNSDGHA.3528@TK2MSFTNGP12.phx.gbl...
> How do you install the GIISR??
> We have shared the DMA irq by Audio, SD host, M-Sys DOC and other
peripheral
> with GIISR.dll.
> You may need to use IOCTL_HAL_REQUEST_SYSINTR to request a SYSINTR for
each
> driver that need to share the DMA IRQ.
>
> "bluesphere" <ads_box@hotmail.com>
¼¶¼g©ó¶l¥ó·s»D:43b46831$0$1065$4fafbaef@reader2.news.tin.it...
> > You could be right Steve,
> >
> > but i'll give you more scenario:
> >
> > DMA IRQ is certainly shared. The AC97 controller is pretty eager and
> > requests the interrupt first. So i'm left with only one choice, that is
> > loading an IISR.
> >
> > I use GIISR and you know what it does. If i remember the code, GIISR.DLL
> > doesn't clear any interrupt, it just returns the SYSINTR
correspondingly.
> > I
> > clear the interrupt in the IST. Is it too late? The WAVEDEV driver
example
> > in PB5 clears the DMA IRQ in the IST either. (INTEL's DOC talks about an
> > issue with the RUN bit, but i guess i managed that)
> >
> > Anyway today i decided to get rid of the AC97 driver. The PXA270's
> > "request
> > to channel mapping" registers show that only the sound driver uses DMA
> > transfers. (As in the MAINSTONEII code), the rest is a desert land.
> >
> > Without the AC97, i guess i was in a non-shared situation. I handled the
> > IRQ
> > without any ISR. It crashed again!
> >
> >
> >
>
>

gralp
Fri Dec 30 05:41:12 CST 2005


bluesphere wrote:
> DMA IRQ is certainly shared. The AC97 controller is pretty eager and
> requests the interrupt first. So i'm left with only one choice, that is
> loading an IISR.
>
> I use GIISR and you know what it does. If i remember the code, GIISR.DLL
> doesn't clear any interrupt, it just returns the SYSINTR correspondingly. I
> clear the interrupt in the IST. Is it too late? The WAVEDEV driver example
> in PB5 clears the DMA IRQ in the IST either. (INTEL's DOC talks about an
> issue with the RUN bit, but i guess i managed that)

The problem with GIISR is that although it reports the interrupt as
handled to the system (main) ISR, the latter does not clear the DMA
interrupt flag because it doesn't know which channel caused the event.
As in the case of any shared interrupt on PXA the signal must be
cleared at the source, in your case it can be e.g.
DCSR[channel].ENDINTR bit (write 1 to clear), if you set up ENDIRQEN in
that channel's descriptor. Trying to clear channel bit in DINT register
will not have any effect.

Because GIISR is too general to know such details, it cannot work
properly in this case.

best
pg

bluesphere
Fri Dec 30 06:14:50 CST 2005


Gralp,

I do that in the IST --->

---------------------------------------------
dwStatus = WaitForSingleObject(hevInterrupt, INFINITE);
...

if (dwStatus == WAIT_OBJECT_0)
{
dcsrtx = dma_reg->DCSR[chl];

if (dcsrtx & DCSR_ENDINTR)
{
DmaTx.IntrCount++;
set(dma_reg->DCSR[chl], DCSR_ENDINTR);
}
InterruptDone(SysIntr);
}
---------------------------------------------
I have the impression the the CPU doesn't even have a chance to get there

Is it up to an ISR to reset DCSR_ENDINTR?


"gralp" <gralp@poczta.onet.pl> wrote in message
news:1135942872.057441.287670@f14g2000cwb.googlegroups.com...
>
> bluesphere wrote:
> > DMA IRQ is certainly shared. The AC97 controller is pretty eager and
> > requests the interrupt first. So i'm left with only one choice, that is
> > loading an IISR.
> >
> > I use GIISR and you know what it does. If i remember the code, GIISR.DLL
> > doesn't clear any interrupt, it just returns the SYSINTR
correspondingly. I
> > clear the interrupt in the IST. Is it too late? The WAVEDEV driver
example
> > in PB5 clears the DMA IRQ in the IST either. (INTEL's DOC talks about an
> > issue with the RUN bit, but i guess i managed that)
>
> The problem with GIISR is that although it reports the interrupt as
> handled to the system (main) ISR, the latter does not clear the DMA
> interrupt flag because it doesn't know which channel caused the event.
> As in the case of any shared interrupt on PXA the signal must be
> cleared at the source, in your case it can be e.g.
> DCSR[channel].ENDINTR bit (write 1 to clear), if you set up ENDIRQEN in
> that channel's descriptor. Trying to clear channel bit in DINT register
> will not have any effect.
>
> Because GIISR is too general to know such details, it cannot work
> properly in this case.
>
> best
> pg
>

K
Fri Dec 30 08:14:31 CST 2005

what is the value of m_Info.Mask??
you may need to set a proper bitmask for the m_Info.Mask member so that ince
IRQ happened the GIISR.dll could reconized the IRQ event, then report a
valid SYSINTR
If the IRQ is *not* reconized by any installable ISR nor the static mapped
to some SYSINTR, the OAL will re-enable the IRQ source.
That might let the IRQ Handler enter again and agin...

"bluesphere" <ads_box@hotmail.com> ¼¶¼g©ó¶l¥ó·s»D:43b50fc2$0$1075$4fafbaef@reader3.news.tin.it...
>
> This is how install the GIISR
> -----------------------------------------------------------------------
> KernelIoControl(IOCTL_HAL_REQUEST_SYSINTR, &m_Irq, sizeof(DWORD),
> &m_SysIntr, sizeof(DWORD), NULL)
> ...
> m_IsrHandle = LoadIntChainHandler(m_IsrDll, m_IsrHandler, (BYTE)m_Irq);
> /*
> where:
> m_IsrDll = L"\\Windows\\giisr.dll";
> m_IsrHandler = L"ISRHandler";
> */
> ....
> m_Info.SysIntr = m_SysIntr;
> KernelLibIoControl(m_IsrHandle, IOCTL_GIISR_INFO, &m_Info, sizeof(m_Info),
> NULL, 0, NULL)
> ----------------------------------------------------------------------
>
> The interrupts work pretty well "every now and mostly then" so i don't
> think
> it depends on GIISR
>
>
> "K. S. Huang" <ksh_AT_bsquare_DOT_com> wrote in message
> news:%23hVzxNSDGHA.3528@TK2MSFTNGP12.phx.gbl...
>> How do you install the GIISR??
>> We have shared the DMA irq by Audio, SD host, M-Sys DOC and other
> peripheral
>> with GIISR.dll.
>> You may need to use IOCTL_HAL_REQUEST_SYSINTR to request a SYSINTR for
> each
>> driver that need to share the DMA IRQ.
>>
>> "bluesphere" <ads_box@hotmail.com>
> ¼¶¼g©ó¶l¥ó·s»D:43b46831$0$1065$4fafbaef@reader2.news.tin.it...
>> > You could be right Steve,
>> >
>> > but i'll give you more scenario:
>> >
>> > DMA IRQ is certainly shared. The AC97 controller is pretty eager and
>> > requests the interrupt first. So i'm left with only one choice, that is
>> > loading an IISR.
>> >
>> > I use GIISR and you know what it does. If i remember the code,
>> > GIISR.DLL
>> > doesn't clear any interrupt, it just returns the SYSINTR
> correspondingly.
>> > I
>> > clear the interrupt in the IST. Is it too late? The WAVEDEV driver
> example
>> > in PB5 clears the DMA IRQ in the IST either. (INTEL's DOC talks about
>> > an
>> > issue with the RUN bit, but i guess i managed that)
>> >
>> > Anyway today i decided to get rid of the AC97 driver. The PXA270's
>> > "request
>> > to channel mapping" registers show that only the sound driver uses DMA
>> > transfers. (As in the MAINSTONEII code), the rest is a desert land.
>> >
>> > Without the AC97, i guess i was in a non-shared situation. I handled
>> > the
>> > IRQ
>> > without any ISR. It crashed again!
>> >
>> >
>> >
>>
>>
>
>

gralp
Fri Dec 30 08:57:56 CST 2005

Your code looks OK, however, your suspicion that it's already too late
may be correct: The event is singnalled to IST with such a delay, that
in some circumstances (depending on your buffers' size) several ENDINTR
can occur in between, and some DMA buffers be left unprocessed as a
result.

Yet, that's probably not your most urgent problem right now, i guess.

Actually, i too wasted a lot of time trying to support AC97+DMA with
interrupts, and finally gave up. Maybe on WinCE5 the situation with
installable ISRs got improved (reading the WinCE5 code, it should) but
on WinCE3 and 4.2 it simply didn't work. Either the OEMInterruptHandler
does not bother about the NKCallIntChain function, or makes a
hard-coded support of some interrupts, including DMA, beforehand (like
in OpenWinCE). As a result, my ISR has never been called, let alone the
subsequent IST. The DMA interrupt was cleared and masked by some
internal ISR, without giving a chance to any installable ISRs.

It may also be that there's another ISR installed before yours, which
claims the DMA event. Because NKCallIntChain calls ISRs in order they
have been loaded, there's no room for overloading them, i.e. you cannot
gain priority to those ISRs that already run in your system.

BTW, least on my platform IOCTL_HAL_REQUEST_SYSINTR (and relatives) are
not implemented, so beware of using it without checking the return code
from KernelIoControl.

Steve
Fri Dec 30 10:35:46 CST 2005

IF and ONLY IF the OAL disables the first level interrupt for the DMA you
can clear the individual source interrupt flags in the IST. So you need to
check the OAL implementation for that particular interrupt. Doing that
REQUIRES the use of shared interrupts (and thus the OAL must also call
NKCallIntChain()) So all the drivers using DMA must request a SYSINTR for
the shared IRQ.

--
Steve Maillet
EmbeddedFusion
www.EmbeddedFusion.com
smaillet at EmbeddedFusion dot com

bluesphere
Fri Dec 30 16:26:24 CST 2005

Gralp,

Maybe it all depends on this lag. I can try and make the buffers larger for
testing purposes,
but i will likely write an ISR.
> Your code looks OK, however, your suspicion that it's already too late
> may be correct: The event is singnalled to IST with such a delay, that
> in some circumstances (depending on your buffers' size) several ENDINTR
> can occur in between, and some DMA buffers be left unprocessed as a
> result.

You should resume your DMA support in WinCE5 then. Even though i'm having
a hard time in finding the bug, i saw my test program working at least a
dozen times,
thus showing that now WinCE5.0 supports shared IRQs. Huang confirms that.
> Actually, i too wasted a lot of time trying to support AC97+DMA with
> interrupts, and finally gave up. Maybe on WinCE5 the situation with
> installable ISRs got improved (reading the WinCE5 code, it should) but
> on WinCE3 and 4.2 it simply didn't work.


No one seems to claim the DMA IRQ but the Audio driver (tx channel)
At least this is what the Request to Channel mappings show.
> It may also be that there's another ISR installed before yours, which
> claims the DMA event. Because NKCallIntChain calls ISRs in order they
> have been loaded, there's no room for overloading them, i.e. you cannot
> gain priority to those ISRs that already run in your system.


Actually all my "KernelIoControl"s are embedded into if statements. I just
did not
reported it in the code i showed. Thanks to an "if" i could find out that
IOCTL_HAL_RELEASE_SYSINTR always returns FALSE. WinCE5
sources confirms that.
> BTW, least on my platform IOCTL_HAL_REQUEST_SYSINTR (and relatives) are
> not implemented, so beware of using it without checking the return code
> from KernelIoControl.

bluesphere
Fri Dec 30 16:34:21 CST 2005

Let's say...

m_Irq = 25;
m_Info.PortAddr = (DWORD)&dma_reg->DINT;
m_Info.PortSize = sizeof(DWORD);
m_Info.Mask = (1 << chl);


"K. S. Huang" <ksh_AT_bsquare_DOT_com> wrote in message
news:OK9obsUDGHA.1124@TK2MSFTNGP10.phx.gbl...
> what is the value of m_Info.Mask??
> you may need to set a proper bitmask for the m_Info.Mask member so that
ince
> IRQ happened the GIISR.dll could reconized the IRQ event, then report a
> valid SYSINTR
> If the IRQ is *not* reconized by any installable ISR nor the static mapped
> to some SYSINTR, the OAL will re-enable the IRQ source.
> That might let the IRQ Handler enter again and agin...
>
> "bluesphere" <ads_box@hotmail.com>
¼¶¼g©ó¶l¥ó·s»D:43b50fc2$0$1075$4fafbaef@reader3.news.tin.it...
> >
> > This is how install the GIISR
> > -----------------------------------------------------------------------
> > KernelIoControl(IOCTL_HAL_REQUEST_SYSINTR, &m_Irq, sizeof(DWORD),
> > &m_SysIntr, sizeof(DWORD), NULL)
> > ...
> > m_IsrHandle = LoadIntChainHandler(m_IsrDll, m_IsrHandler, (BYTE)m_Irq);
> > /*
> > where:
> > m_IsrDll = L"\\Windows\\giisr.dll";
> > m_IsrHandler = L"ISRHandler";
> > */
> > ....
> > m_Info.SysIntr = m_SysIntr;
> > KernelLibIoControl(m_IsrHandle, IOCTL_GIISR_INFO, &m_Info,
sizeof(m_Info),
> > NULL, 0, NULL)
> > ----------------------------------------------------------------------
> >
> > The interrupts work pretty well "every now and mostly then" so i don't
> > think
> > it depends on GIISR
> >
> >
> > "K. S. Huang" <ksh_AT_bsquare_DOT_com> wrote in message
> > news:%23hVzxNSDGHA.3528@TK2MSFTNGP12.phx.gbl...
> >> How do you install the GIISR??
> >> We have shared the DMA irq by Audio, SD host, M-Sys DOC and other
> > peripheral
> >> with GIISR.dll.
> >> You may need to use IOCTL_HAL_REQUEST_SYSINTR to request a SYSINTR for
> > each
> >> driver that need to share the DMA IRQ.
> >>
> >> "bluesphere" <ads_box@hotmail.com>
> > ¼¶¼g©ó¶l¥ó·s»D:43b46831$0$1065$4fafbaef@reader2.news.tin.it...
> >> > You could be right Steve,
> >> >
> >> > but i'll give you more scenario:
> >> >
> >> > DMA IRQ is certainly shared. The AC97 controller is pretty eager and
> >> > requests the interrupt first. So i'm left with only one choice, that
is
> >> > loading an IISR.
> >> >
> >> > I use GIISR and you know what it does. If i remember the code,
> >> > GIISR.DLL
> >> > doesn't clear any interrupt, it just returns the SYSINTR
> > correspondingly.
> >> > I
> >> > clear the interrupt in the IST. Is it too late? The WAVEDEV driver
> > example
> >> > in PB5 clears the DMA IRQ in the IST either. (INTEL's DOC talks about
> >> > an
> >> > issue with the RUN bit, but i guess i managed that)
> >> >
> >> > Anyway today i decided to get rid of the AC97 driver. The PXA270's
> >> > "request
> >> > to channel mapping" registers show that only the sound driver uses
DMA
> >> > transfers. (As in the MAINSTONEII code), the rest is a desert land.
> >> >
> >> > Without the AC97, i guess i was in a non-shared situation. I handled
> >> > the
> >> > IRQ
> >> > without any ISR. It crashed again!
> >> >
> >> >
> >> >
> >>
> >>
> >
> >
>
>

K
Sat Dec 31 07:33:29 CST 2005

Is the dma_reg point to kernel space or not??
Have you use the BusTransBusAddrToStatic for translating the address into
kernel space??

"bluesphere" <ads_box@hotmail.com> ¼¶¼g©ó¶l¥ó·s»D:43b5b618$0$1063$4fafbaef@reader3.news.tin.it...
> Let's say...
>
> m_Irq = 25;
> m_Info.PortAddr = (DWORD)&dma_reg->DINT;
> m_Info.PortSize = sizeof(DWORD);
> m_Info.Mask = (1 << chl);
>
>
> "K. S. Huang" <ksh_AT_bsquare_DOT_com> wrote in message
> news:OK9obsUDGHA.1124@TK2MSFTNGP10.phx.gbl...
>> what is the value of m_Info.Mask??
>> you may need to set a proper bitmask for the m_Info.Mask member so that
> ince
>> IRQ happened the GIISR.dll could reconized the IRQ event, then report a
>> valid SYSINTR
>> If the IRQ is *not* reconized by any installable ISR nor the static
>> mapped
>> to some SYSINTR, the OAL will re-enable the IRQ source.
>> That might let the IRQ Handler enter again and agin...
>>
>> "bluesphere" <ads_box@hotmail.com>
> ¼¶¼g©ó¶l¥ó·s»D:43b50fc2$0$1075$4fafbaef@reader3.news.tin.it...
>> >
>> > This is how install the GIISR
>> > -----------------------------------------------------------------------
>> > KernelIoControl(IOCTL_HAL_REQUEST_SYSINTR, &m_Irq, sizeof(DWORD),
>> > &m_SysIntr, sizeof(DWORD), NULL)
>> > ...
>> > m_IsrHandle = LoadIntChainHandler(m_IsrDll, m_IsrHandler, (BYTE)m_Irq);
>> > /*
>> > where:
>> > m_IsrDll = L"\\Windows\\giisr.dll";
>> > m_IsrHandler = L"ISRHandler";
>> > */
>> > ....
>> > m_Info.SysIntr = m_SysIntr;
>> > KernelLibIoControl(m_IsrHandle, IOCTL_GIISR_INFO, &m_Info,
> sizeof(m_Info),
>> > NULL, 0, NULL)
>> > ----------------------------------------------------------------------
>> >
>> > The interrupts work pretty well "every now and mostly then" so i don't
>> > think
>> > it depends on GIISR
>> >
>> >
>> > "K. S. Huang" <ksh_AT_bsquare_DOT_com> wrote in message
>> > news:%23hVzxNSDGHA.3528@TK2MSFTNGP12.phx.gbl...
>> >> How do you install the GIISR??
>> >> We have shared the DMA irq by Audio, SD host, M-Sys DOC and other
>> > peripheral
>> >> with GIISR.dll.
>> >> You may need to use IOCTL_HAL_REQUEST_SYSINTR to request a SYSINTR for
>> > each
>> >> driver that need to share the DMA IRQ.
>> >>
>> >> "bluesphere" <ads_box@hotmail.com>
>> > ¼¶¼g©ó¶l¥ó·s»D:43b46831$0$1065$4fafbaef@reader2.news.tin.it...
>> >> > You could be right Steve,
>> >> >
>> >> > but i'll give you more scenario:
>> >> >
>> >> > DMA IRQ is certainly shared. The AC97 controller is pretty eager and
>> >> > requests the interrupt first. So i'm left with only one choice, that
> is
>> >> > loading an IISR.
>> >> >
>> >> > I use GIISR and you know what it does. If i remember the code,
>> >> > GIISR.DLL
>> >> > doesn't clear any interrupt, it just returns the SYSINTR
>> > correspondingly.
>> >> > I
>> >> > clear the interrupt in the IST. Is it too late? The WAVEDEV driver
>> > example
>> >> > in PB5 clears the DMA IRQ in the IST either. (INTEL's DOC talks
>> >> > about
>> >> > an
>> >> > issue with the RUN bit, but i guess i managed that)
>> >> >
>> >> > Anyway today i decided to get rid of the AC97 driver. The PXA270's
>> >> > "request
>> >> > to channel mapping" registers show that only the sound driver uses
> DMA
>> >> > transfers. (As in the MAINSTONEII code), the rest is a desert land.
>> >> >
>> >> > Without the AC97, i guess i was in a non-shared situation. I handled
>> >> > the
>> >> > IRQ
>> >> > without any ISR. It crashed again!
>> >> >
>> >> >
>> >> >
>> >>
>> >>
>> >
>> >
>>
>>
>
>

gralp
Sat Dec 31 08:52:15 CST 2005

> Maybe it all depends on this lag. I can try and make
> the buffers larger for testing purposes, but i will
> likely write an ISR.

Custom ISR seems to be the best solution in this case. However you may
still find that it is not called, as it was with the IST. It may be due
to other driver(s) which installed their ISRs prior to yours and
respond to DMA interrupt by signalling different event. In such
circumstances you may try to re-order the drivers either by removing
their registry from BuiltIn tree, or by adding "Order=2" or higher
entries, so that the Device Manager loads them after your own. That
should increase the chances that your ISR will be at the beginning of
the IntChain list rather than its tail.

> No one seems to claim the DMA IRQ but the Audio driver
> (tx channel) At least this is what the Request to Channel
> mappings show.

That the DMA channel maps are mostly empty (except 11 & 12) is no proof
that there's no other ISR which filters DMA interrupts.

bluesphere
Sat Dec 31 18:13:20 CST 2005

Huang,

BusTransBusAddrToStatic? That could be a good point.
When i saw the IISR example in PB5 doc i found this line:

--
TransBusAddrToStatic(PCIBus, 0, PortAddress, ulIoLen, &inIoSpace,
&PhysAddr))
--

I hoped it only had to do with PCI peripherals or something like that and
avoided it for a moment. I hoped MmMapIoSpace was enough.
When the shared IRQ seemed to work for a while, i forgot about
TransBusAddrToStatic, but when i had troubles i didn't remember i
left it out! Now TransBusAddrToStatic is obsolete and
BusTransBusAddrToStatic is suggested. I hope this solves my
issue.

But the "Bus" thing opens a new chapter to me.

The documentation doesn't say much about BusTransBusAddrToStatic,
it takes a lot of arguments, this is my guess:

------------------------------------------------------
InterfaceType is Internal
BusNumber is 0
BusAddress is DMA base phys-addr ??
Length is sizeof (DMA_REGS)
AddressSpace is 0
MappedAddress + some Offset is what i pass to GIISR
hBusAccess is ??
------------------------------------------------------
1) What about hBusAccess ?? Do i need to call CreateBusAccessHandle ??

2) CreateBusAccessHandle needs "Active registry path for the bus" what is
this key?? the "HKEY_LOCAL_MACHINE\Drivers\Active" key ??

3)When do i close the handle? Right after the call to
BusTransBusAddrToStatic?



"K. S. Huang" <ksh_AT_bsquare_DOT_com> wrote in message
news:uaeGQ7gDGHA.412@TK2MSFTNGP15.phx.gbl...
> Is the dma_reg point to kernel space or not??
> Have you use the BusTransBusAddrToStatic for translating the address into
> kernel space??

bluesphere
Sat Dec 31 18:13:20 CST 2005

Huang,

BusTransBusAddrToStatic? That could be a good point.
When i saw the IISR example in PB5 doc i found this line:

--
TransBusAddrToStatic(PCIBus, 0, PortAddress, ulIoLen, &inIoSpace,
&PhysAddr))
--

I hoped it only had to do with PCI peripherals or something like that and
avoided it for a moment. I hoped MmMapIoSpace was enough.
When the shared IRQ seemed to work for a while, i forgot about
TransBusAddrToStatic, but when i had troubles i didn't remember i
left it out! Now TransBusAddrToStatic is obsolete and
BusTransBusAddrToStatic is suggested. I hope this solves my
issue.

But the "Bus" thing opens a new chapter to me.

The documentation doesn't say much about BusTransBusAddrToStatic,
it takes a lot of arguments, this is my guess:

------------------------------------------------------
InterfaceType is Internal
BusNumber is 0
BusAddress is DMA base phys-addr ??
Length is sizeof (DMA_REGS)
AddressSpace is 0
MappedAddress + some Offset is what i pass to GIISR
hBusAccess is ??
------------------------------------------------------
1) What about hBusAccess ?? Do i need to call CreateBusAccessHandle ??

2) CreateBusAccessHandle needs "Active registry path for the bus" what is
this key?? the "HKEY_LOCAL_MACHINE\Drivers\Active" key ??

3)When do i close the handle? Right after the call to
BusTransBusAddrToStatic?



"K. S. Huang" <ksh_AT_bsquare_DOT_com> wrote in message
news:uaeGQ7gDGHA.412@TK2MSFTNGP15.phx.gbl...
> Is the dma_reg point to kernel space or not??
> Have you use the BusTransBusAddrToStatic for translating the address into
> kernel space??

bluesphere
Sat Dec 31 20:04:50 CST 2005

> Custom ISR seems to be the best solution in this case.

However i finally took a look at dmawince. It does handle the source flags
in an IST (DmacIntrThread). So i think i won't make an ISR. Huang noticed
that i haven't translated the dma regs into kernel space and i hope
BusTransBusAddrToStatic is the solution to my issue. I hope it is, because
at a first glance, i do everything else the way dmawince does. I'm still
surprised
that my program sometimes works and there's no translation.

>However you may still find that it is not called, as it was with the IST.
>It may be due
>to other driver(s) which installed their ISRs prior to yours and
>respond to DMA interrupt by signalling different event. In such
>circumstances you may try to re-order the drivers either by removing
>their registry from BuiltIn tree, or by adding "Order=2" or higher
>entries, so that the Device Manager loads them after your own. That
>should increase the chances that your ISR will be at the beginning of
>the IntChain list rather than its tail.

This might be a task for a "Shared Interrupt Manager". Maybe the Developers
are getting to that or to a policy or to some Info APIs to explore the
chain.
An IISR should declare its intentions.

gralp
Sun Jan 01 10:39:25 CST 2006

> Have you use the BusTransBusAddrToStatic for translating
> the address into kernel space??

In principle, this is the right way to do things, however in our case
the translated address will be the same as original, because we are
talking about an internal (not PCI) bus on PXA. See the code for
TransBusAddrToStatic and HalTranslateBusAddress in
%WINCE500%\public\common\oak\drivers\ceddk
directory.

bluesphere
Sun Jan 01 12:22:53 CST 2006


> In principle, this is the right way to do things, however in our case
> the translated address will be the same as original, because we are
> talking about an internal (not PCI) bus on PXA. See the code for
> TransBusAddrToStatic and HalTranslateBusAddress in
> %WINCE500%\public\common\oak\drivers\ceddk
> directory.


That's what i was hoping when i started. Now doing it in the right way
seems to work. I will keep on testing it while developing wrapper
functions or classes.

I took a look at some code yesterday (and by the way i could not find the
sources of BusTransBusAddrToStatic in CEDDK dir). Maybe it's the
"static" part (CreateStaticMapping) that makes the difference.

K
Sun Jan 01 23:48:44 CST 2006

Since we are using non-PCI based bus,
but the main purpose of invoking the TransBusAddrToStatic is to map a
Physical address into kernel space address!!
In a MMU-enabled system, no one coud access any physical address directly
unless the address mapping is one-to-one for the 4GB space. (some of the
RTOS dose so...)
"bluesphere" <ads_box@hotmail.com> ¼¶¼g©ó¶l¥ó·s»D:43b81e23$0$1064$4fafbaef@reader2.news.tin.it...
>
>> In principle, this is the right way to do things, however in our case
>> the translated address will be the same as original, because we are
>> talking about an internal (not PCI) bus on PXA. See the code for
>> TransBusAddrToStatic and HalTranslateBusAddress in
>> %WINCE500%\public\common\oak\drivers\ceddk
>> directory.
>
>
> That's what i was hoping when i started. Now doing it in the right way
> seems to work. I will keep on testing it while developing wrapper
> functions or classes.
>
> I took a look at some code yesterday (and by the way i could not find the
> sources of BusTransBusAddrToStatic in CEDDK dir). Maybe it's the
> "static" part (CreateStaticMapping) that makes the difference.
>
>
>