#11471 HIGH 1.75-so: Crash in mmp2_pcm_open and related code

[Zarro Boogs per Child]

#11471: Crash in mmp2_pcm_open and related code
---------------------------------+------------------------------------------
           Reporter:  greenfeld  |       Owner:  saadia                           
               Type:  defect     |      Status:  new                              
           Priority:  high       |   Milestone:  1.75-software                    
          Component:  kernel     |     Version:  Development build as of this date
         Resolution:             |    Keywords:                                   
        Next_action:  diagnose   |    Verified:  0                                
Deployment_affected:             |   Blockedby:                                   
           Blocking:             |  
---------------------------------+------------------------------------------

Comment(by corbet):

 OK.  The spurious interrupt is coming from the second audio device - the
 one that is not used at all in the OLPC configuration.  I can make the
 problem go away entirely by just masking that device once at
 initialization time.

 I'll need to ponder a bit on the right fix for this one.  Since that
 device is never instantiated in the OLPC kernel, there is no driver that
 is supposed to know about where its registers are.  I could put an ugly
 hack into the OLPC startup code, I guess; it would have to be somewhere
 OLPC-specific in any case.

 The alternative is to simply instantiate that device; then (with my
 previous patch) it will get properly masked by default.  That, of course,
 will conflict with the "use all 32K of the ADMA space for the first
 device" hack.  The best (most general) solution might well be to revert
 that hack out of the OLPC tree and do things this way.

 That said, it would sure be nice to know what is provoking the second
 device to start interrupting the system.  That IRQ is not asserted at
 power-on time, so *something* is causing it to show up later on.  I can't
 find anything in mmp2-pcm.c that should be reaching into the second
 device's MMIO space.  It could be a stray MMIO write from anywhere in the
 kernel, or it could just be that the device needs to be explicitly masked
 at boot or it will start crying for attention eventually.  The kernel has
 a nice mmiotrace feature that would catch stray writes handily, but, alas,
 it doesn't work on ARM...

 I'll try to come up with an alternative or two later today.

-- 
Ticket URL: <http://dev.laptop.org/ticket/11471#comment:8>
One Laptop Per Child <http://laptop.org/>
OLPC bug tracking system