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

IGB AVB support #1

Open
wants to merge 2 commits into
base: rcar-gen3
Choose a base branch
from

Conversation

twischer
Copy link

This pull request is depending on

It introduces the required modification to support Intel Gigabit Network cards by this avb-mse implementation

Signed-off-by: Andreas Pape <apape@de.adit-jv.com>
as it might be needed in streaming driver.
The 'standard' streaming driver (RCAR ravb_streaming) does not touch the
packet content and thus the DMA address is sufficient.
Other streaming drivers (e.g. the upcoming igb_streaming driver for intel
igb card) need to copy/modify packet content which makes it necessary
to also pass the virtual buffer address to the streaming driver.

Signed-off-by: Andreas Pape <apape@de.adit-jv.com>
@aditpape
Copy link
Contributor

Please note:
-IGB streaming driver was in POC status
-ADITJ faced some problems with the IGB driver when patch was applied (was not analyzed further)
-adapting IPG was missing (clean solution in MSE is required )

mnagai pushed a commit that referenced this pull request Jul 26, 2021
refs #326355

mse_work_start_transmission_common() and mse_start_transmission() deal with,
among others, two spin locks: lock_buf_list and lock_state.
It's possible that these two locks will be acquired in opposite orders in two
parallel threads, potentially resulting in a deadlock. Do not try to acquire
lock_state lock while holding lock_buf_list to avoid this situation.

Example command to trigger the warning:
$ speaker-test -r 48000 -t sine -c 2 -F S16_BE -p 16000 -Dhw:ravbmse,1
Reproduction rate: 100%.

LOCKDEP warning:

[   34.776517] mse_packetq/2167 is trying to acquire lock:
[   34.783138]  (&instance->lock_state){....}, at: [<ffff000000b8bbd8>] mse_work_start_transmission_common+0xc8/0x428 [mse_core]
[   34.795864]
[   34.795864] but task is already holding lock:
[   34.801957]  (&(&instance->lock_buf_list)->rlock){....}, at: [<ffff000000b8bb70>] mse_work_start_transmission_common+0x60/0x428 [mse_core]
[   34.814572]
[   34.814572] which lock already depends on the new lock.
[   34.814572]
[   34.822833]
[   34.822833] the existing dependency chain (in reverse order) is:
[   34.830396]
[   34.830396] -> #1 (&(&instance->lock_buf_list)->rlock){....}:
[   34.837722]        _raw_spin_lock_irqsave+0x58/0x98
[   34.842732]        mse_start_transmission+0x178/0x2e8 [mse_core]
[   34.848826]        mse_adapter_alsa_trigger+0x100/0x1cc [mse_adapter_alsa]
[   34.855788]        snd_pcm_do_start+0x28/0x38
[   34.860211]        snd_pcm_action_single+0x44/0x7c
[   34.865071]        snd_pcm_action+0x24/0xf8
[   34.869324]        snd_pcm_start+0x20/0x28
[   34.873488]        __snd_pcm_lib_xfer+0x588/0x624
[   34.878261]        snd_pcm_common_ioctl+0x484/0x1024
[   34.883296]        snd_pcm_ioctl+0x28/0x3c
[   34.887465]        vfs_ioctl+0x24/0x40
[   34.891278]        do_vfs_ioctl+0xa4/0x890
[   34.895439]        SyS_ioctl+0x5c/0xd0
[   34.899257]        el0_svc_naked+0x34/0x38
[   34.903416]
[   34.903416] -> #0 (&instance->lock_state){....}:
[   34.909593]        lock_acquire+0x22c/0x25c
[   34.913842]        _raw_read_lock_irqsave+0x58/0x98
[   34.918871]        mse_work_start_transmission_common+0xc8/0x428 [mse_core]
[   34.925983]        mse_work_start_transmission+0x14c/0x150 [mse_core]
[   34.932508]        kthread_worker_fn+0x110/0x188
[   34.937194]        kthread+0x11c/0x12c
[   34.941010]        ret_from_fork+0x10/0x18
[   34.945170]
[   34.945170] other info that might help us debug this:
[   34.945170]
[   34.953256]  Possible unsafe locking scenario:
[   34.953256]
[   34.959249]        CPU0                    CPU1
[   34.963844]        ----                    ----
[   34.968438]   lock(&(&instance->lock_buf_list)->rlock);
[   34.973733]                                lock(&instance->lock_state);
[   34.980422]                                lock(&(&instance->lock_buf_list)->rlock);
[   34.988248]   lock(&instance->lock_state);
[   34.992408]
[   34.992408]  *** DEADLOCK ***

Signed-off-by: Yan Yankovskyi <yyankovskyi@de.adit-jv.com>
Signed-off-by: Masaru Nagai <masaru.nagai.vx@renesas.com>
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