1. 28 Feb, 2010 1 commit
    • Jeffrey Lee's avatar
      Fix the 'Module_VectorCode' IRQ handler to preserve R14_svc before calling any SWIs · 9da527e2
      Jeffrey Lee authored
        s/Sound0 - Module_VectorCode, which is currently used to respond to FIFO underflows in the OMAP3 sound driver, wasn't saving R14_svc before calling a SWI from IRQ mode, potentially leading to malfunction if the CPU was in SVC mode at the time of the interrupt. This has been fixed.
        Tested on rev C2 beagleboard
      Version 1.67. Tagged as 'Sound0HAL-1_67'
  2. 16 Jan, 2010 2 commits
    • Jeffrey Lee's avatar
      Minor sSound0HAL update to ensure correct behaviour of devif device does not provide an IRQ · dacc4219
      Jeffrey Lee authored
      Version 1.66. Tagged as 'Sound0HAL-1_66'
    • Jeffrey Lee's avatar
      Add initial version of new SoundDMA module, 'Sound0HAL' · 4adc5cfd
      Jeffrey Lee authored
        Based on the Sound0Trid source code, this version of SoundDMA makes use of a new version of the audio controller HAL device API. Briefly:
        * DMA is handled by the HALified DMAManager
        * The DMASync callback is used to trigger audio buffer filling
        * The set of available sample rates is dictated by the audio controller device
        * Basic support for resetting the audio when an error occurs (e.g. FIFO under/overflow causing stereo channels to be swapped)
        * Module is now ARMv6/7-safe, due to use of LDR(S)H instead of unaligned loads. This comes at the cost of losing RiscPC compatability. Can be disabled if needed via setting UseLDRSH to false.
        * To keep the code simple, it only accepts devices which use the new API version.
        * Sound0Enable now enables IRQs for most of its execution, to allow for supporting slow devices (e.g. IIC communications with the TPS65950). The PRMs describe Sound_Enable as having undefined reentrancy & IRQ state, so this should be OK with regards to code compatability.
        * The stereo reverse code still needs to be made ARMv6/v7-safe, as well as (preferably) being something that can be selectively enabled at runtime, depending on the audio controller in use
        * The oversampling code is disabled, much as it was in Sound0Trid.
        * The pipelining of sample rate changes that Sound0Trid performed is gone - partly to keep the code simple, and partly because it wouldn't work too well with the TPS65950 (due to the intermediate FIFO that the samples pass through, and the fact that the TPS audio codec must be turned off to change the sample rate)
        Tested on rev C2 beagleboard.
      Version 1.65. Tagged as 'Sound0HAL-1_65'