Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

camera: Allow to use boottime as timestamp reference #1

Open
wants to merge 1 commit into
base: frico-release
Choose a base branch
from
Open

camera: Allow to use boottime as timestamp reference #1

wants to merge 1 commit into from

Conversation

venom-stark
Copy link

  • Some /mad/ HALs use boottime clock without reporting
    timestamp source as realtime
    -> Add a flag to force boottime offset calculation

[SebaUbuntu] Edit for Soong conditional

Change-Id: I56b623a1c2b58ca8a6287783d938fb665de201df

* Some /mad/ HALs use boottime clock without reporting
  timestamp source as realtime
  -> Add a flag to force boottime offset calculation

[SebaUbuntu] Edit for Soong conditional

Change-Id: I56b623a1c2b58ca8a6287783d938fb665de201df
SahilSonar pushed a commit that referenced this pull request Apr 15, 2023
Do not hold lock when IPC call is expected from HAL.

C2SurfaceSyncObj is shared lock between framework and HAL. HAL process
can have only one thread to handle IPC from HAL to framework.
Therefore Holding C2SurfaceSyncObj from HAL during IPC call could
trigger deadlock. The exact scenario is as follows.

Thread #1:(HAL -> framework IPC) HIDL call onInputBuffersReleased()
            calls to feedInputBufferIfAvailable(). Since this is using
            HAL IPC thread, this will block Thread #3. This is waiting
            for mOuput mutex which is held by Thread #2.
Thread #2:(framework) discardBuffer() holds mOutput mutex which blocks
            Thread #1. But this is waiting for C2SurfaceSyncObj which is
            held by Thread #3.
Thread #3:(HAL) Dtor of C2BufferQueueBlockPoolData is holding
            C2SurfaceSyncObj, therefore this will block #2. This thread
            is waiting for HIDL IPC thread to be free in order for
            'igbp->cancel()', but HIDL IPC thread is already occupied by
            Thread #1.

Bug: 246707566
Test: atest android.media.decoder.cts.AdaptivePlaybackTest
Test: atest android.media.decoder.cts.DecoderTest
Change-Id: I6a9540d3b4d03806cd40bb4f89a234a6b77758a9
Merged-In: I6a9540d3b4d03806cd40bb4f89a234a6b77758a9
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants