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>

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;