06 Dec, 2018

2 commits


28 Nov, 2018

1 commit


23 Nov, 2018

7 commits


15 Nov, 2018

1 commit


14 Nov, 2018

8 commits


13 Nov, 2018

7 commits


09 Nov, 2018

10 commits


08 Nov, 2018

1 commit


03 Nov, 2018

3 commits

  • Update SCFW API to the following commit:
    "
    ("430d1e3646fbe75e339e18abf2330565eac906e0")
    Author: Chuck Cannon
    Date: Fri Nov 2 15:25:45 2018 -0500

    SCF-105: RN updates.
    "

    Signed-off-by: Ranjani Vaidyanathan

    Ranjani Vaidyanathan
     
  • Implemented system suspend resume functions to call hwvad enable/disable
    then do runtime_force_suspend/resume.
    Since hwvad can run independently, when user calls enable/disable, we
    will have to increment/decrement usage counter by calling
    runtime_*_sync but to avoid doing this when disable/enable is called
    from system_suspend/resume since we called pm_runtime functions - this
    is why we have added the sync parameter in enable/disable_hwvad.
    However, we ignore the busy flag because the module wasn't designed to
    work with arecord and hwvad in parralel and we only print a warning.
    Since hwvad and recording share the same clock and initialization
    procedures require module to be disabled, the busy flag will be set
    when having both features enabled.

    Signed-off-by: Cosmin-Gabriel Samoila
    Reviewed-by: Daniel Baluta

    Cosmin-Gabriel Samoila
     
  • We must find a way to no longer touch resources after they are
    cleand up.

    Now, after a stress test we get the following crash:

    [ 2156.863772] fsl-dsp 596e8000.dsp: xf_pool_alloc failed
    [ 2156.869337] Unable to handle kernel NULL pointer dereference at
    virtual address 00000060
    [ 2157.148594] [] _raw_spin_lock+0x14/0x48
    [ 2157.153995] [] xf_cmd_send_recv_complete+0x40/0xf0
    [ 2157.160354] [] xf_close+0x40/0x88
    [ 2157.165239] [] xaf_comp_delete+0x5c/0x70
    [ 2157.170730] [] dsp_platform_compr_free+0xa0/0xe8
    [ 2157.176917] [] soc_compr_free_fe+0x144/0x1a0
    [ 2157.182754] [] snd_compr_free+0x64/0x98

    This happens because:

    1) dsp_platform_process work handler waits in a loop for
    messages to arrive.
    2) when cplay process finishes it cleans up most of the
    resources.
    3) when another cplay process starts it reinitializes the
    resources including queues for example.
    4) a message will be generated and kernel will crash because
    dsp_platform_process uses the older queues.

    A solution for this is to make sure dsp_platform_process work loop
    is stopped at cleanup time.

    We use is_active state and signal dsp_platform_process handler to
    finish because we are on the cleanup path.

    While at it replace cancel_work with cancel_work sync to be sure
    that work handler ends before going on with the rest of the cleanup.

    Reviewed-by: Cosmin-Gabriel Samoila
    Signed-off-by: Daniel Baluta

    Daniel Baluta