diff options
author | Rafał Miłecki <rafal@milecki.pl> | 2017-03-22 21:09:00 +0100 |
---|---|---|
committer | Rafał Miłecki <rafal@milecki.pl> | 2017-03-24 08:06:35 +0100 |
commit | fce21ae4ccfcee0c28fb18f5507e145fb0b02dec (patch) | |
tree | 6c29b7c1f65945991d0cae13af012e6c14adc713 /target/linux/brcm2708/patches-4.9/950-0098-vchiq_arm-Add-completion-records-under-the-mutex.patch | |
parent | 46e390322a58bdc632ee43fdf9d14115dac26e7a (diff) | |
download | upstream-fce21ae4ccfcee0c28fb18f5507e145fb0b02dec.tar.gz upstream-fce21ae4ccfcee0c28fb18f5507e145fb0b02dec.tar.bz2 upstream-fce21ae4ccfcee0c28fb18f5507e145fb0b02dec.zip |
brcm2708: rename all patches from raspberrypi git tree to use 950 prefix
Right now all brcm2708 patches are extracted from the non-mainline
raspberrypi/linux git tree. Many of them are hacks and/or are unneeded
in LEDE. Raspberry Pi is getting better and better mainline support so
it would be nice to finally start maintaining patches in a cleaner way:
1) Backport patches accepted in upstream tree
2) Start using upstream drivers
3) Pick only these patches that are needed for more complete support
Handling above tasks requires grouping patches - ideally using the same
prefixes as generic ones. It means we should rename existing patches to
use some high prefix. This will allow e.g. use 0xx for backported code.
Signed-off-by: Rafał Miłecki <rafal@milecki.pl>
Acked-by: Florian Fainelli <f.fainelli@gmail.com>
Acked-by: Stijn Tintel <stijn@linux-ipv6.be>
Diffstat (limited to 'target/linux/brcm2708/patches-4.9/950-0098-vchiq_arm-Add-completion-records-under-the-mutex.patch')
-rw-r--r-- | target/linux/brcm2708/patches-4.9/950-0098-vchiq_arm-Add-completion-records-under-the-mutex.patch | 63 |
1 files changed, 63 insertions, 0 deletions
diff --git a/target/linux/brcm2708/patches-4.9/950-0098-vchiq_arm-Add-completion-records-under-the-mutex.patch b/target/linux/brcm2708/patches-4.9/950-0098-vchiq_arm-Add-completion-records-under-the-mutex.patch new file mode 100644 index 0000000000..1b8647e86a --- /dev/null +++ b/target/linux/brcm2708/patches-4.9/950-0098-vchiq_arm-Add-completion-records-under-the-mutex.patch @@ -0,0 +1,63 @@ +From 152fc9447942bad4e2c6c1e6b86fd252689cc596 Mon Sep 17 00:00:00 2001 +From: Phil Elwell <phil@raspberrypi.org> +Date: Thu, 21 Apr 2016 13:49:32 +0100 +Subject: [PATCH] vchiq_arm: Add completion records under the mutex + +An issue was observed when flushing openmax components +which generate a large number of messages returning +buffers to host. + +We occasionally found a duplicate message from 16 +messages prior, resulting in a buffer returned twice. + +While only one thread adds completions, without the +mutex you don't get the protection of the automatic +memory barrier you get with synchronisation objects. + +Signed-off-by: Phil Elwell <phil@raspberrypi.org> +--- + .../staging/vc04_services/interface/vchiq_arm/vchiq_arm.c | 13 ++++++++++++- + 1 file changed, 12 insertions(+), 1 deletion(-) + +--- a/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_arm.c ++++ b/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_arm.c +@@ -210,6 +210,8 @@ add_completion(VCHIQ_INSTANCE_T instance + VCHIQ_COMPLETION_DATA_T *completion; + DEBUG_INITIALISE(g_state.local) + ++ mutex_lock(&instance->completion_mutex); ++ + while (instance->completion_insert == + (instance->completion_remove + MAX_COMPLETIONS)) { + /* Out of space - wait for the client */ +@@ -217,11 +219,17 @@ add_completion(VCHIQ_INSTANCE_T instance + vchiq_log_trace(vchiq_arm_log_level, + "add_completion - completion queue full"); + DEBUG_COUNT(COMPLETION_QUEUE_FULL_COUNT); ++ ++ mutex_unlock(&instance->completion_mutex); + if (down_interruptible(&instance->remove_event) != 0) { + vchiq_log_info(vchiq_arm_log_level, + "service_callback interrupted"); + return VCHIQ_RETRY; +- } else if (instance->closing) { ++ } ++ ++ mutex_lock(&instance->completion_mutex); ++ if (instance->closing) { ++ mutex_unlock(&instance->completion_mutex); + vchiq_log_info(vchiq_arm_log_level, + "service_callback closing"); + return VCHIQ_SUCCESS; +@@ -254,8 +262,11 @@ add_completion(VCHIQ_INSTANCE_T instance + if (reason == VCHIQ_MESSAGE_AVAILABLE) + user_service->message_available_pos = + instance->completion_insert; ++ + instance->completion_insert++; + ++ mutex_unlock(&instance->completion_mutex); ++ + up(&instance->insert_event); + + return VCHIQ_SUCCESS; |