[PATCH 0/7] staging: vc04_services: Some dead code removal

[PATCH 0/7] staging: vc04_services: Some dead code removal

[Tuomas Tynkkynen]

Drop various pieces of dead code from here and there to get rid of
the remaining users of VCHI_CONNECTION_T. After that we get to drop
entire header files worth of unused code.

I've tested on a Raspberry Pi Model B (bcm2835_defconfig) that
snd-bcm2835 can still play analog audio just fine.

Tuomas Tynkkynen (7):
  staging: vc04_services: Drop pointless stub functions
  staging: vc04_services: Drop 'connection' field from
    SERVICE_CREATION_T
  staging: vc04_services: Drop trivially unused fields from
    SERVICE_CREATION_T
  staging: vc04_services: Drop declaration of vchi_crc_control()
  staging: vc04_services: Drop VCHI_SERVICE_INIT and SERVICE_INFO_T
  staging: vc04_services: Drop unused parameters from vchi_connect()
  staging: vc04_services: Drop no longer needed headers

 .../bcm2835-audio/bcm2835-vchiq.c             |  10 +-
 .../vc04_services/bcm2835-audio/bcm2835.h     |   1 -
 .../vc04_services/bcm2835-camera/mmal-vchiq.c |   9 +-
 .../interface/vchi/connections/connection.h   | 324 ------------------
 .../interface/vchi/message_drivers/message.h  | 196 -----------
 .../vc04_services/interface/vchi/vchi.h       |  41 +--
 .../interface/vchi/vchi_cfg_internal.h        |  71 ----
 .../interface/vchiq_arm/vchiq_shim.c          |  38 +-
 8 files changed, 5 insertions(+), 685 deletions(-)
 delete mode 100644 drivers/staging/vc04_services/interface/vchi/connections/connection.h
 delete mode 100644 drivers/staging/vc04_services/interface/vchi/message_drivers/message.h
 delete mode 100644 drivers/staging/vc04_services/interface/vchi/vchi_cfg_internal.h

-- 
2.18.0

[PATCH 1/7] staging: vc04_services: Drop pointless stub functions

[Tuomas Tynkkynen]

These functions do nothing besides returning NULL and are unused.
Just drop them.

Signed-off-by: Tuomas Tynkkynen <tuomas.tynkkynen@iki.fi>
---
 .../vc04_services/interface/vchi/vchi.h       | 11 --------
 .../interface/vchiq_arm/vchiq_shim.c          | 27 -------------------
 2 files changed, 38 deletions(-)

diff --git a/drivers/staging/vc04_services/interface/vchi/vchi.h b/drivers/staging/vc04_services/interface/vchi/vchi.h
index 3fe19d72b3ab..392c78200e9d 100644
--- a/drivers/staging/vc04_services/interface/vchi/vchi.h
+++ b/drivers/staging/vc04_services/interface/vchi/vchi.h
@@ -116,9 +116,6 @@ typedef struct service_info_tag {
 extern "C" {
 #endif
 
-extern /*@observer@*/ VCHI_CONNECTION_T *vchi_create_connection(const VCHI_CONNECTION_API_T *function_table,
-								 const VCHI_MESSAGE_DRIVER_T *low_level);
-
 // Routine used to initialise the vchi on both local + remote connections
 extern int32_t vchi_initialise(VCHI_INSTANCE_T *instance_handle);
 
@@ -292,14 +289,6 @@ extern int32_t vchi_bulk_queue_transmit(VCHI_SERVICE_HANDLE_T handle,
  Configuration plumbing
  *****************************************************************************/
 
-// function prototypes for the different mid layers (the state info gives the different physical connections)
-extern const VCHI_CONNECTION_API_T *single_get_func_table(void);
-//extern const VCHI_CONNECTION_API_T *local_server_get_func_table(void);
-//extern const VCHI_CONNECTION_API_T *local_client_get_func_table(void);
-
-// declare all message drivers here
-const VCHI_MESSAGE_DRIVER_T *vchi_mphi_message_driver_func_table(void);
-
 #ifdef __cplusplus
 }
 #endif
diff --git a/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_shim.c b/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_shim.c
index dddc828390d0..9235a974dae4 100644
--- a/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_shim.c
+++ b/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_shim.c
@@ -50,33 +50,6 @@ struct shim_service {
 	void *callback_param;
 };
 
-/* ----------------------------------------------------------------------
- * return pointer to the mphi message driver function table
- * -------------------------------------------------------------------- */
-const VCHI_MESSAGE_DRIVER_T *
-vchi_mphi_message_driver_func_table(void)
-{
-	return NULL;
-}
-
-/* ----------------------------------------------------------------------
- * return a pointer to the 'single' connection driver fops
- * -------------------------------------------------------------------- */
-const VCHI_CONNECTION_API_T *
-single_get_func_table(void)
-{
-	return NULL;
-}
-
-VCHI_CONNECTION_T *vchi_create_connection(
-	const VCHI_CONNECTION_API_T *function_table,
-	const VCHI_MESSAGE_DRIVER_T *low_level)
-{
-	(void)function_table;
-	(void)low_level;
-	return NULL;
-}
-
 /***********************************************************
  * Name: vchi_msg_peek
  *
-- 
2.18.0

[PATCH 2/7] staging: vc04_services: Drop 'connection' field from SERVICE_CREATION_T

[Tuomas Tynkkynen]

The connection field of SERVICE_CREATION_T is assigned to but its value
is never read. Drop the field and the resulting no longer needed code
from bcm2835-audio and bcm2835-camera.

Signed-off-by: Tuomas Tynkkynen <tuomas.tynkkynen@iki.fi>
---
 drivers/staging/vc04_services/bcm2835-audio/bcm2835-vchiq.c | 3 ---
 drivers/staging/vc04_services/bcm2835-audio/bcm2835.h       | 1 -
 drivers/staging/vc04_services/bcm2835-camera/mmal-vchiq.c   | 2 --
 drivers/staging/vc04_services/interface/vchi/vchi.h         | 1 -
 4 files changed, 7 deletions(-)

diff --git a/drivers/staging/vc04_services/bcm2835-audio/bcm2835-vchiq.c b/drivers/staging/vc04_services/bcm2835-audio/bcm2835-vchiq.c
index 0bdaea1fdd77..6ec15e44d7e2 100644
--- a/drivers/staging/vc04_services/bcm2835-audio/bcm2835-vchiq.c
+++ b/drivers/staging/vc04_services/bcm2835-audio/bcm2835-vchiq.c
@@ -125,13 +125,11 @@ static void audio_vchi_callback(void *param,
 
 static int
 vc_vchi_audio_init(VCHI_INSTANCE_T vchi_instance,
-		   VCHI_CONNECTION_T *vchi_connection,
 		   struct bcm2835_audio_instance *instance)
 {
 	SERVICE_CREATION_T params = {
 		.version		= VCHI_VERSION_EX(VC_AUDIOSERV_VER, VC_AUDIOSERV_MIN_VER),
 		.service_id		= VC_AUDIO_SERVER_NAME,
-		.connection		= vchi_connection,
 		.rx_fifo_size		= 0,
 		.tx_fifo_size		= 0,
 		.callback		= audio_vchi_callback,
@@ -228,7 +226,6 @@ int bcm2835_audio_open(struct bcm2835_alsa_stream *alsa_stream)
 	alsa_stream->instance = instance;
 
 	err = vc_vchi_audio_init(vchi_ctx->vchi_instance,
-				 vchi_ctx->vchi_connection,
 				 instance);
 	if (err < 0)
 		goto free_instance;
diff --git a/drivers/staging/vc04_services/bcm2835-audio/bcm2835.h b/drivers/staging/vc04_services/bcm2835-audio/bcm2835.h
index e13435d1c205..34a0125ce646 100644
--- a/drivers/staging/vc04_services/bcm2835-audio/bcm2835.h
+++ b/drivers/staging/vc04_services/bcm2835-audio/bcm2835.h
@@ -45,7 +45,6 @@ enum snd_bcm2835_ctrl {
 
 struct bcm2835_vchi_ctx {
 	VCHI_INSTANCE_T vchi_instance;
-	VCHI_CONNECTION_T *vchi_connection;
 };
 
 /* definition of the chip-specific record */
diff --git a/drivers/staging/vc04_services/bcm2835-camera/mmal-vchiq.c b/drivers/staging/vc04_services/bcm2835-camera/mmal-vchiq.c
index 6e5c1d4ee122..e234b95b61c0 100644
--- a/drivers/staging/vc04_services/bcm2835-camera/mmal-vchiq.c
+++ b/drivers/staging/vc04_services/bcm2835-camera/mmal-vchiq.c
@@ -1802,12 +1802,10 @@ int vchiq_mmal_init(struct vchiq_mmal_instance **out_instance)
 {
 	int status;
 	struct vchiq_mmal_instance *instance;
-	static VCHI_CONNECTION_T *vchi_connection;
 	static VCHI_INSTANCE_T vchi_instance;
 	SERVICE_CREATION_T params = {
 		.version		= VCHI_VERSION_EX(VC_MMAL_VER, VC_MMAL_MIN_VER),
 		.service_id		= VC_MMAL_SERVER_NAME,
-		.connection		= vchi_connection,
 		.rx_fifo_size		= 0,
 		.tx_fifo_size		= 0,
 		.callback		= service_callback,
diff --git a/drivers/staging/vc04_services/interface/vchi/vchi.h b/drivers/staging/vc04_services/interface/vchi/vchi.h
index 392c78200e9d..1ea997c658f9 100644
--- a/drivers/staging/vc04_services/interface/vchi/vchi.h
+++ b/drivers/staging/vc04_services/interface/vchi/vchi.h
@@ -77,7 +77,6 @@ typedef struct {
 typedef struct {
 	struct vchi_version version;
 	int32_t service_id;
-	VCHI_CONNECTION_T *connection;
 	uint32_t rx_fifo_size;
 	uint32_t tx_fifo_size;
 	VCHI_CALLBACK_T callback;
-- 
2.18.0

[PATCH 3/7] staging: vc04_services: Drop trivially unused fields from SERVICE_CREATION_T

[Tuomas Tynkkynen]

These fields are only initialized with constants and never read. Drop
them.

Signed-off-by: Tuomas Tynkkynen <tuomas.tynkkynen@iki.fi>
---
 .../vc04_services/bcm2835-audio/bcm2835-vchiq.c       |  5 -----
 .../staging/vc04_services/bcm2835-camera/mmal-vchiq.c |  5 -----
 drivers/staging/vc04_services/interface/vchi/vchi.h   | 11 -----------
 3 files changed, 21 deletions(-)

diff --git a/drivers/staging/vc04_services/bcm2835-audio/bcm2835-vchiq.c b/drivers/staging/vc04_services/bcm2835-audio/bcm2835-vchiq.c
index 6ec15e44d7e2..bc48a74a6be6 100644
--- a/drivers/staging/vc04_services/bcm2835-audio/bcm2835-vchiq.c
+++ b/drivers/staging/vc04_services/bcm2835-audio/bcm2835-vchiq.c
@@ -130,13 +130,8 @@ vc_vchi_audio_init(VCHI_INSTANCE_T vchi_instance,
 	SERVICE_CREATION_T params = {
 		.version		= VCHI_VERSION_EX(VC_AUDIOSERV_VER, VC_AUDIOSERV_MIN_VER),
 		.service_id		= VC_AUDIO_SERVER_NAME,
-		.rx_fifo_size		= 0,
-		.tx_fifo_size		= 0,
 		.callback		= audio_vchi_callback,
 		.callback_param		= instance,
-		.want_unaligned_bulk_rx = 1, //TODO: remove VCOS_FALSE
-		.want_unaligned_bulk_tx = 1, //TODO: remove VCOS_FALSE
-		.want_crc		= 0
 	};
 	int status;
 
diff --git a/drivers/staging/vc04_services/bcm2835-camera/mmal-vchiq.c b/drivers/staging/vc04_services/bcm2835-camera/mmal-vchiq.c
index e234b95b61c0..074a4acc196d 100644
--- a/drivers/staging/vc04_services/bcm2835-camera/mmal-vchiq.c
+++ b/drivers/staging/vc04_services/bcm2835-camera/mmal-vchiq.c
@@ -1806,13 +1806,8 @@ int vchiq_mmal_init(struct vchiq_mmal_instance **out_instance)
 	SERVICE_CREATION_T params = {
 		.version		= VCHI_VERSION_EX(VC_MMAL_VER, VC_MMAL_MIN_VER),
 		.service_id		= VC_MMAL_SERVER_NAME,
-		.rx_fifo_size		= 0,
-		.tx_fifo_size		= 0,
 		.callback		= service_callback,
 		.callback_param		= NULL,
-		.want_unaligned_bulk_rx = 1,
-		.want_unaligned_bulk_tx = 1,
-		.want_crc		= 0
 	};
 
 	/* compile time checks to ensure structure size as they are
diff --git a/drivers/staging/vc04_services/interface/vchi/vchi.h b/drivers/staging/vc04_services/interface/vchi/vchi.h
index 1ea997c658f9..347825329ea4 100644
--- a/drivers/staging/vc04_services/interface/vchi/vchi.h
+++ b/drivers/staging/vc04_services/interface/vchi/vchi.h
@@ -77,19 +77,8 @@ typedef struct {
 typedef struct {
 	struct vchi_version version;
 	int32_t service_id;
-	uint32_t rx_fifo_size;
-	uint32_t tx_fifo_size;
 	VCHI_CALLBACK_T callback;
 	void *callback_param;
-	/* client intends to receive bulk transfers of
-		odd lengths or into unaligned buffers */
-	int32_t want_unaligned_bulk_rx;
-	/* client intends to transmit bulk transfers of
-		odd lengths or out of unaligned buffers */
-	int32_t want_unaligned_bulk_tx;
-	/* client wants to check CRCs on (bulk) xfers.
-		Only needs to be set at 1 end - will do both directions. */
-	int32_t want_crc;
 } SERVICE_CREATION_T;
 
 // Opaque handle for a VCHI instance
-- 
2.18.0

[PATCH 4/7] staging: vc04_services: Drop declaration of vchi_crc_control()

[Tuomas Tynkkynen]

There is no definition for this unused function, so drop its prototype.

Signed-off-by: Tuomas Tynkkynen <tuomas.tynkkynen@iki.fi>
---
 drivers/staging/vc04_services/interface/vchi/vchi.h | 4 ----
 1 file changed, 4 deletions(-)

diff --git a/drivers/staging/vc04_services/interface/vchi/vchi.h b/drivers/staging/vc04_services/interface/vchi/vchi.h
index 347825329ea4..103d67024335 100644
--- a/drivers/staging/vc04_services/interface/vchi/vchi.h
+++ b/drivers/staging/vc04_services/interface/vchi/vchi.h
@@ -117,10 +117,6 @@ extern int32_t vchi_connect(VCHI_CONNECTION_T **connections,
 //Bulk transfers can remain 'queued'
 extern int32_t vchi_disconnect(VCHI_INSTANCE_T instance_handle);
 
-// Global control over bulk CRC checking
-extern int32_t vchi_crc_control(VCHI_CONNECTION_T *connection,
-				VCHI_CRC_CONTROL_T control);
-
 // helper functions
 extern void *vchi_allocate_buffer(VCHI_SERVICE_HANDLE_T handle, uint32_t *length);
 extern void vchi_free_buffer(VCHI_SERVICE_HANDLE_T handle, void *address);
-- 
2.18.0

[PATCH 5/7] staging: vc04_services: Drop VCHI_SERVICE_INIT and SERVICE_INFO_T

[Tuomas Tynkkynen]

These types are not used anywhere, remove them.

Signed-off-by: Tuomas Tynkkynen <tuomas.tynkkynen@iki.fi>
---
 drivers/staging/vc04_services/interface/vchi/vchi.h | 9 ---------
 1 file changed, 9 deletions(-)

diff --git a/drivers/staging/vc04_services/interface/vchi/vchi.h b/drivers/staging/vc04_services/interface/vchi/vchi.h
index 103d67024335..5c5bb6ddd9ce 100644
--- a/drivers/staging/vc04_services/interface/vchi/vchi.h
+++ b/drivers/staging/vc04_services/interface/vchi/vchi.h
@@ -87,15 +87,6 @@ typedef struct opaque_vchi_instance_handle_t *VCHI_INSTANCE_T;
 // Opaque handle for a server or client
 typedef struct opaque_vchi_service_handle_t *VCHI_SERVICE_HANDLE_T;
 
-// Service registration & startup
-typedef void (*VCHI_SERVICE_INIT)(VCHI_INSTANCE_T initialise_instance, VCHI_CONNECTION_T **connections, uint32_t num_connections);
-
-typedef struct service_info_tag {
-   const char * const vll_filename; /* VLL to load to start this service. This is an empty string if VLL is "static" */
-   VCHI_SERVICE_INIT init;          /* Service initialisation function */
-   void *vll_handle;                /* VLL handle; NULL when unloaded or a "static VLL" in build */
-} SERVICE_INFO_T;
-
 /******************************************************************************
  Global funcs - implementation is specific to which side you are on (local / remote)
  *****************************************************************************/
-- 
2.18.0

[PATCH 6/7] staging: vc04_services: Drop unused parameters from vchi_connect()

[Tuomas Tynkkynen]

Remove two parameters which are never used and all where all callers
just pass in dummy values anyway.

Signed-off-by: Tuomas Tynkkynen <tuomas.tynkkynen@iki.fi>
---
 .../vc04_services/bcm2835-audio/bcm2835-vchiq.c       |  2 +-
 .../staging/vc04_services/bcm2835-camera/mmal-vchiq.c |  2 +-
 drivers/staging/vc04_services/interface/vchi/vchi.h   |  4 +---
 .../vc04_services/interface/vchiq_arm/vchiq_shim.c    | 11 ++---------
 4 files changed, 5 insertions(+), 14 deletions(-)

diff --git a/drivers/staging/vc04_services/bcm2835-audio/bcm2835-vchiq.c b/drivers/staging/vc04_services/bcm2835-audio/bcm2835-vchiq.c
index bc48a74a6be6..781754f36da7 100644
--- a/drivers/staging/vc04_services/bcm2835-audio/bcm2835-vchiq.c
+++ b/drivers/staging/vc04_services/bcm2835-audio/bcm2835-vchiq.c
@@ -183,7 +183,7 @@ int bcm2835_new_vchi_ctx(struct device *dev, struct bcm2835_vchi_ctx *vchi_ctx)
 		return -EIO;
 	}
 
-	ret = vchi_connect(NULL, 0, vchi_ctx->vchi_instance);
+	ret = vchi_connect(vchi_ctx->vchi_instance);
 	if (ret) {
 		dev_dbg(dev, "failed to connect VCHI instance (ret=%d)\n",
 			ret);
diff --git a/drivers/staging/vc04_services/bcm2835-camera/mmal-vchiq.c b/drivers/staging/vc04_services/bcm2835-camera/mmal-vchiq.c
index 074a4acc196d..cc2d9933b969 100644
--- a/drivers/staging/vc04_services/bcm2835-camera/mmal-vchiq.c
+++ b/drivers/staging/vc04_services/bcm2835-camera/mmal-vchiq.c
@@ -1831,7 +1831,7 @@ int vchiq_mmal_init(struct vchiq_mmal_instance **out_instance)
 		return -EIO;
 	}
 
-	status = vchi_connect(NULL, 0, vchi_instance);
+	status = vchi_connect(vchi_instance);
 	if (status) {
 		pr_err("Failed to connect VCHI instance (status=%d)\n", status);
 		return -EIO;
diff --git a/drivers/staging/vc04_services/interface/vchi/vchi.h b/drivers/staging/vc04_services/interface/vchi/vchi.h
index 5c5bb6ddd9ce..95d9da078f46 100644
--- a/drivers/staging/vc04_services/interface/vchi/vchi.h
+++ b/drivers/staging/vc04_services/interface/vchi/vchi.h
@@ -100,9 +100,7 @@ extern int32_t vchi_initialise(VCHI_INSTANCE_T *instance_handle);
 
 extern int32_t vchi_exit(void);
 
-extern int32_t vchi_connect(VCHI_CONNECTION_T **connections,
-			    const uint32_t num_connections,
-			    VCHI_INSTANCE_T instance_handle);
+extern int32_t vchi_connect(VCHI_INSTANCE_T instance_handle);
 
 //When this is called, ensure that all services have no data pending.
 //Bulk transfers can remain 'queued'
diff --git a/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_shim.c b/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_shim.c
index 9235a974dae4..c3223fcdaf87 100644
--- a/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_shim.c
+++ b/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_shim.c
@@ -490,9 +490,7 @@ EXPORT_SYMBOL(vchi_initialise);
 /***********************************************************
  * Name: vchi_connect
  *
- * Arguments: VCHI_CONNECTION_T **connections
- *            const uint32_t num_connections
- *            VCHI_INSTANCE_T instance_handle)
+ * Arguments: VCHI_INSTANCE_T instance_handle
  *
  * Description: Starts the command service on each connection,
  *              causing INIT messages to be pinged back and forth
@@ -500,15 +498,10 @@ EXPORT_SYMBOL(vchi_initialise);
  * Returns: 0 if successful, failure otherwise
  *
  ***********************************************************/
-int32_t vchi_connect(VCHI_CONNECTION_T **connections,
-	const uint32_t num_connections,
-	VCHI_INSTANCE_T instance_handle)
+int32_t vchi_connect(VCHI_INSTANCE_T instance_handle)
 {
 	VCHIQ_INSTANCE_T instance = (VCHIQ_INSTANCE_T)instance_handle;
 
-	(void)connections;
-	(void)num_connections;
-
 	return vchiq_connect(instance);
 }
 EXPORT_SYMBOL(vchi_connect);
-- 
2.18.0

[PATCH 7/7] staging: vc04_services: Drop no longer needed headers

[Tuomas Tynkkynen]

Previously, connection.h was only required for the definition of
VCHI_CONNECTION_T, but now all usages of it are gone. Remove this unused
header.

After connection.h is gone, message.h and vchi_cfg_internal.h are no
longer referenced by anything either. Drop them as well.

Signed-off-by: Tuomas Tynkkynen <tuomas.tynkkynen@iki.fi>
---
 .../interface/vchi/connections/connection.h   | 324 ------------------
 .../interface/vchi/message_drivers/message.h  | 196 -----------
 .../vc04_services/interface/vchi/vchi.h       |   1 -
 .../interface/vchi/vchi_cfg_internal.h        |  71 ----
 4 files changed, 592 deletions(-)
 delete mode 100644 drivers/staging/vc04_services/interface/vchi/connections/connection.h
 delete mode 100644 drivers/staging/vc04_services/interface/vchi/message_drivers/message.h
 delete mode 100644 drivers/staging/vc04_services/interface/vchi/vchi_cfg_internal.h

diff --git a/drivers/staging/vc04_services/interface/vchi/connections/connection.h b/drivers/staging/vc04_services/interface/vchi/connections/connection.h
deleted file mode 100644
index 67c84386c65a..000000000000
--- a/drivers/staging/vc04_services/interface/vchi/connections/connection.h
+++ /dev/null
@@ -1,324 +0,0 @@
-/**
- * Copyright (c) 2010-2012 Broadcom. All rights reserved.
- *
- * Redistribution and use in source and binary forms, with or without
- * modification, are permitted provided that the following conditions
- * are met:
- * 1. Redistributions of source code must retain the above copyright
- *    notice, this list of conditions, and the following disclaimer,
- *    without modification.
- * 2. Redistributions in binary form must reproduce the above copyright
- *    notice, this list of conditions and the following disclaimer in the
- *    documentation and/or other materials provided with the distribution.
- * 3. The names of the above-listed copyright holders may not be used
- *    to endorse or promote products derived from this software without
- *    specific prior written permission.
- *
- * ALTERNATIVELY, this software may be distributed under the terms of the
- * GNU General Public License ("GPL") version 2, as published by the Free
- * Software Foundation.
- *
- * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS
- * IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO,
- * THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR
- * PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR
- * CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL,
- * EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO,
- * PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR
- * PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF
- * LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING
- * NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS
- * SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
- */
-
-#ifndef CONNECTION_H_
-#define CONNECTION_H_
-
-#include <linux/kernel.h>
-#include <linux/types.h>
-#include <linux/semaphore.h>
-
-#include "interface/vchi/vchi_cfg_internal.h"
-#include "interface/vchi/vchi_common.h"
-#include "interface/vchi/message_drivers/message.h"
-
-/******************************************************************************
- Global defs
- *****************************************************************************/
-
-// Opaque handle for a connection / service pair
-typedef struct opaque_vchi_connection_connected_service_handle_t *VCHI_CONNECTION_SERVICE_HANDLE_T;
-
-// opaque handle to the connection state information
-typedef struct opaque_vchi_connection_info_t VCHI_CONNECTION_STATE_T;
-
-typedef struct vchi_connection_t VCHI_CONNECTION_T;
-
-/******************************************************************************
- API
- *****************************************************************************/
-
-// Routine to init a connection with a particular low level driver
-typedef VCHI_CONNECTION_STATE_T * (*VCHI_CONNECTION_INIT_T)( struct vchi_connection_t * connection,
-                                                             const VCHI_MESSAGE_DRIVER_T * driver );
-
-// Routine to control CRC enabling at a connection level
-typedef int32_t (*VCHI_CONNECTION_CRC_CONTROL_T)( VCHI_CONNECTION_STATE_T *state_handle,
-                                                  VCHI_CRC_CONTROL_T control );
-
-// Routine to create a service
-typedef int32_t (*VCHI_CONNECTION_SERVICE_CONNECT_T)( VCHI_CONNECTION_STATE_T *state_handle,
-                                                      int32_t service_id,
-                                                      uint32_t rx_fifo_size,
-                                                      uint32_t tx_fifo_size,
-                                                      int server,
-                                                      VCHI_CALLBACK_T callback,
-                                                      void *callback_param,
-                                                      int32_t want_crc,
-                                                      int32_t want_unaligned_bulk_rx,
-                                                      int32_t want_unaligned_bulk_tx,
-                                                      VCHI_CONNECTION_SERVICE_HANDLE_T *service_handle );
-
-// Routine to close a service
-typedef int32_t (*VCHI_CONNECTION_SERVICE_DISCONNECT_T)( VCHI_CONNECTION_SERVICE_HANDLE_T service_handle );
-
-// Routine to queue a message
-typedef int32_t (*VCHI_CONNECTION_SERVICE_QUEUE_MESSAGE_T)( VCHI_CONNECTION_SERVICE_HANDLE_T service_handle,
-                                                            const void *data,
-                                                            uint32_t data_size,
-                                                            VCHI_FLAGS_T flags,
-                                                            void *msg_handle );
-
-// scatter-gather (vector) message queueing
-typedef int32_t (*VCHI_CONNECTION_SERVICE_QUEUE_MESSAGEV_T)( VCHI_CONNECTION_SERVICE_HANDLE_T service_handle,
-                                                             VCHI_MSG_VECTOR_T *vector,
-                                                             uint32_t count,
-                                                             VCHI_FLAGS_T flags,
-                                                             void *msg_handle );
-
-// Routine to dequeue a message
-typedef int32_t (*VCHI_CONNECTION_SERVICE_DEQUEUE_MESSAGE_T)( VCHI_CONNECTION_SERVICE_HANDLE_T service_handle,
-                                                              void *data,
-                                                              uint32_t max_data_size_to_read,
-                                                              uint32_t *actual_msg_size,
-                                                              VCHI_FLAGS_T flags );
-
-// Routine to peek at a message
-typedef int32_t (*VCHI_CONNECTION_SERVICE_PEEK_MESSAGE_T)( VCHI_CONNECTION_SERVICE_HANDLE_T service_handle,
-                                                           void **data,
-                                                           uint32_t *msg_size,
-                                                           VCHI_FLAGS_T flags );
-
-// Routine to hold a message
-typedef int32_t (*VCHI_CONNECTION_SERVICE_HOLD_MESSAGE_T)( VCHI_CONNECTION_SERVICE_HANDLE_T service_handle,
-                                                           void **data,
-                                                           uint32_t *msg_size,
-                                                           VCHI_FLAGS_T flags,
-                                                           void **message_handle );
-
-// Routine to initialise a received message iterator
-typedef int32_t (*VCHI_CONNECTION_SERVICE_LOOKAHEAD_MESSAGE_T)( VCHI_CONNECTION_SERVICE_HANDLE_T service_handle,
-                                                                VCHI_MSG_ITER_T *iter,
-                                                                VCHI_FLAGS_T flags );
-
-// Routine to release a held message
-typedef int32_t (*VCHI_CONNECTION_HELD_MSG_RELEASE_T)( VCHI_CONNECTION_SERVICE_HANDLE_T service_handle,
-                                                       void *message_handle );
-
-// Routine to get info on a held message
-typedef int32_t (*VCHI_CONNECTION_HELD_MSG_INFO_T)( VCHI_CONNECTION_SERVICE_HANDLE_T service_handle,
-                                                    void *message_handle,
-                                                    void **data,
-                                                    int32_t *msg_size,
-                                                    uint32_t *tx_timestamp,
-                                                    uint32_t *rx_timestamp );
-
-// Routine to check whether the iterator has a next message
-typedef int32_t (*VCHI_CONNECTION_MSG_ITER_HAS_NEXT_T)( VCHI_CONNECTION_SERVICE_HANDLE_T service,
-                                                       const VCHI_MSG_ITER_T *iter );
-
-// Routine to advance the iterator
-typedef int32_t (*VCHI_CONNECTION_MSG_ITER_NEXT_T)( VCHI_CONNECTION_SERVICE_HANDLE_T service,
-                                                    VCHI_MSG_ITER_T *iter,
-                                                    void **data,
-                                                    uint32_t *msg_size );
-
-// Routine to remove the last message returned by the iterator
-typedef int32_t (*VCHI_CONNECTION_MSG_ITER_REMOVE_T)( VCHI_CONNECTION_SERVICE_HANDLE_T service,
-                                                      VCHI_MSG_ITER_T *iter );
-
-// Routine to hold the last message returned by the iterator
-typedef int32_t (*VCHI_CONNECTION_MSG_ITER_HOLD_T)( VCHI_CONNECTION_SERVICE_HANDLE_T service,
-                                                    VCHI_MSG_ITER_T *iter,
-                                                    void **msg_handle );
-
-// Routine to transmit bulk data
-typedef int32_t (*VCHI_CONNECTION_BULK_QUEUE_TRANSMIT_T)( VCHI_CONNECTION_SERVICE_HANDLE_T service_handle,
-                                                          const void *data_src,
-                                                          uint32_t data_size,
-                                                          VCHI_FLAGS_T flags,
-                                                          void *bulk_handle );
-
-// Routine to receive data
-typedef int32_t (*VCHI_CONNECTION_BULK_QUEUE_RECEIVE_T)( VCHI_CONNECTION_SERVICE_HANDLE_T service_handle,
-                                                         void *data_dst,
-                                                         uint32_t data_size,
-                                                         VCHI_FLAGS_T flags,
-                                                         void *bulk_handle );
-
-// Routine to report if a server is available
-typedef int32_t (*VCHI_CONNECTION_SERVER_PRESENT)( VCHI_CONNECTION_STATE_T *state, int32_t service_id, int32_t peer_flags );
-
-// Routine to report the number of RX slots available
-typedef int (*VCHI_CONNECTION_RX_SLOTS_AVAILABLE)( const VCHI_CONNECTION_STATE_T *state );
-
-// Routine to report the RX slot size
-typedef uint32_t (*VCHI_CONNECTION_RX_SLOT_SIZE)( const VCHI_CONNECTION_STATE_T *state );
-
-// Callback to indicate that the other side has added a buffer to the rx bulk DMA FIFO
-typedef void (*VCHI_CONNECTION_RX_BULK_BUFFER_ADDED)(VCHI_CONNECTION_STATE_T *state,
-                                                     int32_t service,
-                                                     uint32_t length,
-                                                     MESSAGE_TX_CHANNEL_T channel,
-                                                     uint32_t channel_params,
-                                                     uint32_t data_length,
-                                                     uint32_t data_offset);
-
-// Callback to inform a service that a Xon or Xoff message has been received
-typedef void (*VCHI_CONNECTION_FLOW_CONTROL)(VCHI_CONNECTION_STATE_T *state, int32_t service_id, int32_t xoff);
-
-// Callback to inform a service that a server available reply message has been received
-typedef void (*VCHI_CONNECTION_SERVER_AVAILABLE_REPLY)(VCHI_CONNECTION_STATE_T *state, int32_t service_id, uint32_t flags);
-
-// Callback to indicate that bulk auxiliary messages have arrived
-typedef void (*VCHI_CONNECTION_BULK_AUX_RECEIVED)(VCHI_CONNECTION_STATE_T *state);
-
-// Callback to indicate that bulk auxiliary messages have arrived
-typedef void (*VCHI_CONNECTION_BULK_AUX_TRANSMITTED)(VCHI_CONNECTION_STATE_T *state, void *handle);
-
-// Callback with all the connection info you require
-typedef void (*VCHI_CONNECTION_INFO)(VCHI_CONNECTION_STATE_T *state, uint32_t protocol_version, uint32_t slot_size, uint32_t num_slots, uint32_t min_bulk_size);
-
-// Callback to inform of a disconnect
-typedef void (*VCHI_CONNECTION_DISCONNECT)(VCHI_CONNECTION_STATE_T *state, uint32_t flags);
-
-// Callback to inform of a power control request
-typedef void (*VCHI_CONNECTION_POWER_CONTROL)(VCHI_CONNECTION_STATE_T *state, MESSAGE_TX_CHANNEL_T channel, int32_t enable);
-
-// allocate memory suitably aligned for this connection
-typedef void * (*VCHI_BUFFER_ALLOCATE)(VCHI_CONNECTION_SERVICE_HANDLE_T service_handle, uint32_t * length);
-
-// free memory allocated by buffer_allocate
-typedef void   (*VCHI_BUFFER_FREE)(VCHI_CONNECTION_SERVICE_HANDLE_T service_handle, void * address);
-
-/******************************************************************************
- System driver struct
- *****************************************************************************/
-
-struct opaque_vchi_connection_api_t {
-   // Routine to init the connection
-   VCHI_CONNECTION_INIT_T                      init;
-
-   // Connection-level CRC control
-   VCHI_CONNECTION_CRC_CONTROL_T               crc_control;
-
-   // Routine to connect to or create service
-   VCHI_CONNECTION_SERVICE_CONNECT_T           service_connect;
-
-   // Routine to disconnect from a service
-   VCHI_CONNECTION_SERVICE_DISCONNECT_T        service_disconnect;
-
-   // Routine to queue a message
-   VCHI_CONNECTION_SERVICE_QUEUE_MESSAGE_T     service_queue_msg;
-
-   // scatter-gather (vector) message queue
-   VCHI_CONNECTION_SERVICE_QUEUE_MESSAGEV_T    service_queue_msgv;
-
-   // Routine to dequeue a message
-   VCHI_CONNECTION_SERVICE_DEQUEUE_MESSAGE_T   service_dequeue_msg;
-
-   // Routine to peek at a message
-   VCHI_CONNECTION_SERVICE_PEEK_MESSAGE_T      service_peek_msg;
-
-   // Routine to hold a message
-   VCHI_CONNECTION_SERVICE_HOLD_MESSAGE_T      service_hold_msg;
-
-   // Routine to initialise a received message iterator
-   VCHI_CONNECTION_SERVICE_LOOKAHEAD_MESSAGE_T service_look_ahead_msg;
-
-   // Routine to release a message
-   VCHI_CONNECTION_HELD_MSG_RELEASE_T          held_msg_release;
-
-   // Routine to get information on a held message
-   VCHI_CONNECTION_HELD_MSG_INFO_T             held_msg_info;
-
-   // Routine to check for next message on iterator
-   VCHI_CONNECTION_MSG_ITER_HAS_NEXT_T         msg_iter_has_next;
-
-   // Routine to get next message on iterator
-   VCHI_CONNECTION_MSG_ITER_NEXT_T             msg_iter_next;
-
-   // Routine to remove the last message returned by iterator
-   VCHI_CONNECTION_MSG_ITER_REMOVE_T           msg_iter_remove;
-
-   // Routine to hold the last message returned by iterator
-   VCHI_CONNECTION_MSG_ITER_HOLD_T             msg_iter_hold;
-
-   // Routine to transmit bulk data
-   VCHI_CONNECTION_BULK_QUEUE_TRANSMIT_T       bulk_queue_transmit;
-
-   // Routine to receive data
-   VCHI_CONNECTION_BULK_QUEUE_RECEIVE_T        bulk_queue_receive;
-
-   // Routine to report the available servers
-   VCHI_CONNECTION_SERVER_PRESENT              server_present;
-
-   // Routine to report the number of RX slots available
-   VCHI_CONNECTION_RX_SLOTS_AVAILABLE          connection_rx_slots_available;
-
-   // Routine to report the RX slot size
-   VCHI_CONNECTION_RX_SLOT_SIZE                connection_rx_slot_size;
-
-   // Callback to indicate that the other side has added a buffer to the rx bulk DMA FIFO
-   VCHI_CONNECTION_RX_BULK_BUFFER_ADDED        rx_bulk_buffer_added;
-
-   // Callback to inform a service that a Xon or Xoff message has been received
-   VCHI_CONNECTION_FLOW_CONTROL                flow_control;
-
-   // Callback to inform a service that a server available reply message has been received
-   VCHI_CONNECTION_SERVER_AVAILABLE_REPLY      server_available_reply;
-
-   // Callback to indicate that bulk auxiliary messages have arrived
-   VCHI_CONNECTION_BULK_AUX_RECEIVED           bulk_aux_received;
-
-   // Callback to indicate that a bulk auxiliary message has been transmitted
-   VCHI_CONNECTION_BULK_AUX_TRANSMITTED        bulk_aux_transmitted;
-
-   // Callback to provide information about the connection
-   VCHI_CONNECTION_INFO                        connection_info;
-
-   // Callback to notify that peer has requested disconnect
-   VCHI_CONNECTION_DISCONNECT                  disconnect;
-
-   // Callback to notify that peer has requested power change
-   VCHI_CONNECTION_POWER_CONTROL               power_control;
-
-   // allocate memory suitably aligned for this connection
-   VCHI_BUFFER_ALLOCATE                        buffer_allocate;
-
-   // free memory allocated by buffer_allocate
-   VCHI_BUFFER_FREE                            buffer_free;
-
-};
-
-struct vchi_connection_t {
-   const VCHI_CONNECTION_API_T *api;
-   VCHI_CONNECTION_STATE_T     *state;
-#ifdef VCHI_COARSE_LOCKING
-   struct semaphore             sem;
-#endif
-};
-
-#endif /* CONNECTION_H_ */
-
-/****************************** End of file **********************************/
diff --git a/drivers/staging/vc04_services/interface/vchi/message_drivers/message.h b/drivers/staging/vc04_services/interface/vchi/message_drivers/message.h
deleted file mode 100644
index 834263f278cf..000000000000
--- a/drivers/staging/vc04_services/interface/vchi/message_drivers/message.h
+++ /dev/null
@@ -1,196 +0,0 @@
-/**
- * Copyright (c) 2010-2012 Broadcom. All rights reserved.
- *
- * Redistribution and use in source and binary forms, with or without
- * modification, are permitted provided that the following conditions
- * are met:
- * 1. Redistributions of source code must retain the above copyright
- *    notice, this list of conditions, and the following disclaimer,
- *    without modification.
- * 2. Redistributions in binary form must reproduce the above copyright
- *    notice, this list of conditions and the following disclaimer in the
- *    documentation and/or other materials provided with the distribution.
- * 3. The names of the above-listed copyright holders may not be used
- *    to endorse or promote products derived from this software without
- *    specific prior written permission.
- *
- * ALTERNATIVELY, this software may be distributed under the terms of the
- * GNU General Public License ("GPL") version 2, as published by the Free
- * Software Foundation.
- *
- * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS
- * IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO,
- * THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR
- * PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR
- * CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL,
- * EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO,
- * PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR
- * PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF
- * LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING
- * NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS
- * SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
- */
-
-#ifndef _VCHI_MESSAGE_H_
-#define _VCHI_MESSAGE_H_
-
-#include <linux/kernel.h>
-#include <linux/types.h>
-#include <linux/semaphore.h>
-
-#include "interface/vchi/vchi_cfg_internal.h"
-#include "interface/vchi/vchi_common.h"
-
-typedef enum message_event_type {
-   MESSAGE_EVENT_NONE,
-   MESSAGE_EVENT_NOP,
-   MESSAGE_EVENT_MESSAGE,
-   MESSAGE_EVENT_SLOT_COMPLETE,
-   MESSAGE_EVENT_RX_BULK_PAUSED,
-   MESSAGE_EVENT_RX_BULK_COMPLETE,
-   MESSAGE_EVENT_TX_COMPLETE,
-   MESSAGE_EVENT_MSG_DISCARDED
-} MESSAGE_EVENT_TYPE_T;
-
-typedef enum vchi_msg_flags {
-   VCHI_MSG_FLAGS_NONE                  = 0x0,
-   VCHI_MSG_FLAGS_TERMINATE_DMA         = 0x1
-} VCHI_MSG_FLAGS_T;
-
-typedef enum message_tx_channel {
-   MESSAGE_TX_CHANNEL_MESSAGE           = 0,
-   MESSAGE_TX_CHANNEL_BULK              = 1 // drivers may provide multiple bulk channels, from 1 upwards
-} MESSAGE_TX_CHANNEL_T;
-
-// Macros used for cycling through bulk channels
-#define MESSAGE_TX_CHANNEL_BULK_PREV(c) (MESSAGE_TX_CHANNEL_BULK+((c)-MESSAGE_TX_CHANNEL_BULK+VCHI_MAX_BULK_TX_CHANNELS_PER_CONNECTION-1)%VCHI_MAX_BULK_TX_CHANNELS_PER_CONNECTION)
-#define MESSAGE_TX_CHANNEL_BULK_NEXT(c) (MESSAGE_TX_CHANNEL_BULK+((c)-MESSAGE_TX_CHANNEL_BULK+1)%VCHI_MAX_BULK_TX_CHANNELS_PER_CONNECTION)
-
-typedef enum message_rx_channel {
-   MESSAGE_RX_CHANNEL_MESSAGE           = 0,
-   MESSAGE_RX_CHANNEL_BULK              = 1 // drivers may provide multiple bulk channels, from 1 upwards
-} MESSAGE_RX_CHANNEL_T;
-
-// Message receive slot information
-typedef struct rx_msg_slot_info {
-
-   struct rx_msg_slot_info *next;
-   //struct slot_info *prev;
-#if !defined VCHI_COARSE_LOCKING
-   struct semaphore   sem;
-#endif
-
-   uint8_t           *addr;               // base address of slot
-   uint32_t           len;                // length of slot in bytes
-
-   uint32_t           write_ptr;          // hardware causes this to advance
-   uint32_t           read_ptr;           // this module does the reading
-   int                active;             // is this slot in the hardware dma fifo?
-   uint32_t           msgs_parsed;        // count how many messages are in this slot
-   uint32_t           msgs_released;      // how many messages have been released
-   void              *state;              // connection state information
-   uint8_t            ref_count[VCHI_MAX_SERVICES_PER_CONNECTION];          // reference count for slots held by services
-} RX_MSG_SLOTINFO_T;
-
-// The message driver no longer needs to know about the fields of RX_BULK_SLOTINFO_T - sort this out.
-// In particular, it mustn't use addr and len - they're the client buffer, but the message
-// driver will be tasked with sending the aligned core section.
-typedef struct rx_bulk_slotinfo_t {
-   struct rx_bulk_slotinfo_t *next;
-
-   struct semaphore *blocking;
-
-   // needed by DMA
-   void        *addr;
-   uint32_t     len;
-
-   // needed for the callback
-   void        *service;
-   void        *handle;
-   VCHI_FLAGS_T flags;
-} RX_BULK_SLOTINFO_T;
-
-/* ----------------------------------------------------------------------
- * each connection driver will have a pool of the following struct.
- *
- * the pool will be managed by vchi_qman_*
- * this means there will be multiple queues (single linked lists)
- * a given struct message_info will be on exactly one of these queues
- * at any one time
- * -------------------------------------------------------------------- */
-typedef struct rx_message_info {
-
-   struct message_info *next;
-   //struct message_info *prev;
-
-   uint8_t    *addr;
-   uint32_t   len;
-   RX_MSG_SLOTINFO_T *slot; // points to whichever slot contains this message
-   uint32_t   tx_timestamp;
-   uint32_t   rx_timestamp;
-
-} RX_MESSAGE_INFO_T;
-
-typedef struct {
-   MESSAGE_EVENT_TYPE_T type;
-
-   struct {
-      // for messages
-      void    *addr;           // address of message
-      uint16_t slot_delta;     // whether this message indicated slot delta
-      uint32_t len;            // length of message
-      RX_MSG_SLOTINFO_T *slot; // slot this message is in
-      int32_t  service;   // service id this message is destined for
-      uint32_t tx_timestamp;   // timestamp from the header
-      uint32_t rx_timestamp;   // timestamp when we parsed it
-   } message;
-
-   // FIXME: cleanup slot reporting...
-   RX_MSG_SLOTINFO_T *rx_msg;
-   RX_BULK_SLOTINFO_T *rx_bulk;
-   void *tx_handle;
-   MESSAGE_TX_CHANNEL_T tx_channel;
-
-} MESSAGE_EVENT_T;
-
-// callbacks
-typedef void VCHI_MESSAGE_DRIVER_EVENT_CALLBACK_T( void *state );
-
-typedef struct {
-   VCHI_MESSAGE_DRIVER_EVENT_CALLBACK_T *event_callback;
-} VCHI_MESSAGE_DRIVER_OPEN_T;
-
-// handle to this instance of message driver (as returned by ->open)
-typedef struct opaque_mhandle_t *VCHI_MDRIVER_HANDLE_T;
-
-struct opaque_vchi_message_driver_t {
-   VCHI_MDRIVER_HANDLE_T *(*open)( VCHI_MESSAGE_DRIVER_OPEN_T *params, void *state );
-   int32_t (*suspending)( VCHI_MDRIVER_HANDLE_T *handle );
-   int32_t (*resumed)( VCHI_MDRIVER_HANDLE_T *handle );
-   int32_t (*power_control)( VCHI_MDRIVER_HANDLE_T *handle, MESSAGE_TX_CHANNEL_T, int32_t enable );
-   int32_t (*add_msg_rx_slot)( VCHI_MDRIVER_HANDLE_T *handle, RX_MSG_SLOTINFO_T *slot );      // rx message
-   int32_t (*add_bulk_rx)( VCHI_MDRIVER_HANDLE_T *handle, void *data, uint32_t len, RX_BULK_SLOTINFO_T *slot );  // rx data (bulk)
-   int32_t (*send)( VCHI_MDRIVER_HANDLE_T *handle, MESSAGE_TX_CHANNEL_T channel, const void *data, uint32_t len, VCHI_MSG_FLAGS_T flags, void *send_handle );      // tx (message & bulk)
-   void    (*next_event)( VCHI_MDRIVER_HANDLE_T *handle, MESSAGE_EVENT_T *event );     // get the next event from message_driver
-   int32_t (*enable)( VCHI_MDRIVER_HANDLE_T *handle );
-   int32_t (*form_message)( VCHI_MDRIVER_HANDLE_T *handle, int32_t service_id, VCHI_MSG_VECTOR_T *vector, uint32_t count, void
-                            *address, uint32_t length_avail, uint32_t max_total_length, int32_t pad_to_fill, int32_t allow_partial );
-
-   int32_t (*update_message)( VCHI_MDRIVER_HANDLE_T *handle, void *dest, int16_t *slot_count );
-   int32_t (*buffer_aligned)( VCHI_MDRIVER_HANDLE_T *handle, int tx, int uncached, const void *address, const uint32_t length );
-   void *  (*allocate_buffer)( VCHI_MDRIVER_HANDLE_T *handle, uint32_t *length );
-   void    (*free_buffer)( VCHI_MDRIVER_HANDLE_T *handle, void *address );
-   int     (*rx_slot_size)( VCHI_MDRIVER_HANDLE_T *handle, int msg_size );
-   int     (*tx_slot_size)( VCHI_MDRIVER_HANDLE_T *handle, int msg_size );
-
-   int32_t  (*tx_supports_terminate)( const VCHI_MDRIVER_HANDLE_T *handle, MESSAGE_TX_CHANNEL_T channel );
-   uint32_t (*tx_bulk_chunk_size)( const VCHI_MDRIVER_HANDLE_T *handle, MESSAGE_TX_CHANNEL_T channel );
-   int     (*tx_alignment)( const VCHI_MDRIVER_HANDLE_T *handle, MESSAGE_TX_CHANNEL_T channel );
-   int     (*rx_alignment)( const VCHI_MDRIVER_HANDLE_T *handle, MESSAGE_RX_CHANNEL_T channel );
-   void    (*form_bulk_aux)( VCHI_MDRIVER_HANDLE_T *handle, MESSAGE_TX_CHANNEL_T channel, const void *data, uint32_t len, uint32_t chunk_size, const void **aux_data, int32_t *aux_len );
-   void    (*debug)( VCHI_MDRIVER_HANDLE_T *handle );
-};
-
-#endif // _VCHI_MESSAGE_H_
-
-/****************************** End of file ***********************************/
diff --git a/drivers/staging/vc04_services/interface/vchi/vchi.h b/drivers/staging/vc04_services/interface/vchi/vchi.h
index 95d9da078f46..01381904775d 100644
--- a/drivers/staging/vc04_services/interface/vchi/vchi.h
+++ b/drivers/staging/vc04_services/interface/vchi/vchi.h
@@ -36,7 +36,6 @@
 
 #include "interface/vchi/vchi_cfg.h"
 #include "interface/vchi/vchi_common.h"
-#include "interface/vchi/connections/connection.h"
 #include "vchi_mh.h"
 
 /******************************************************************************
diff --git a/drivers/staging/vc04_services/interface/vchi/vchi_cfg_internal.h b/drivers/staging/vc04_services/interface/vchi/vchi_cfg_internal.h
deleted file mode 100644
index 35dcba4837d4..000000000000
--- a/drivers/staging/vc04_services/interface/vchi/vchi_cfg_internal.h
+++ /dev/null
@@ -1,71 +0,0 @@
-/**
- * Copyright (c) 2010-2012 Broadcom. All rights reserved.
- *
- * Redistribution and use in source and binary forms, with or without
- * modification, are permitted provided that the following conditions
- * are met:
- * 1. Redistributions of source code must retain the above copyright
- *    notice, this list of conditions, and the following disclaimer,
- *    without modification.
- * 2. Redistributions in binary form must reproduce the above copyright
- *    notice, this list of conditions and the following disclaimer in the
- *    documentation and/or other materials provided with the distribution.
- * 3. The names of the above-listed copyright holders may not be used
- *    to endorse or promote products derived from this software without
- *    specific prior written permission.
- *
- * ALTERNATIVELY, this software may be distributed under the terms of the
- * GNU General Public License ("GPL") version 2, as published by the Free
- * Software Foundation.
- *
- * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS
- * IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO,
- * THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR
- * PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR
- * CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL,
- * EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO,
- * PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR
- * PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF
- * LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING
- * NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS
- * SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
- */
-
-#ifndef VCHI_CFG_INTERNAL_H_
-#define VCHI_CFG_INTERNAL_H_
-
-/****************************************************************************************
- * Control optimisation attempts.
- ***************************************************************************************/
-
-// Don't use lots of short-term locks - use great long ones, reducing the overall locks-per-second
-#define VCHI_COARSE_LOCKING
-
-// Avoid lock then unlock on exit from blocking queue operations (msg tx, bulk rx/tx)
-// (only relevant if VCHI_COARSE_LOCKING)
-#define VCHI_ELIDE_BLOCK_EXIT_LOCK
-
-// Avoid lock on non-blocking peek
-// (only relevant if VCHI_COARSE_LOCKING)
-#define VCHI_AVOID_PEEK_LOCK
-
-// Use one slot-handler thread per connection, rather than 1 thread dealing with all connections in rotation.
-#define VCHI_MULTIPLE_HANDLER_THREADS
-
-// Put free descriptors onto the head of the free queue, rather than the tail, so that we don't thrash
-// our way through the pool of descriptors.
-#define VCHI_PUSH_FREE_DESCRIPTORS_ONTO_HEAD
-
-// Don't issue a MSG_AVAILABLE callback for every single message. Possibly only safe if VCHI_COARSE_LOCKING.
-#define VCHI_FEWER_MSG_AVAILABLE_CALLBACKS
-
-// Don't use message descriptors for TX messages that don't need them
-#define VCHI_MINIMISE_TX_MSG_DESCRIPTORS
-
-// Nano-locks for multiqueue
-//#define VCHI_MQUEUE_NANOLOCKS
-
-// Lock-free(er) dequeuing
-//#define VCHI_RX_NANOLOCKS
-
-#endif /*VCHI_CFG_INTERNAL_H_*/
-- 
2.18.0

Re: [PATCH 0/7] staging: vc04_services: Some dead code removal

[Stefan Wahren]

Hi Tuomas,

> Tuomas Tynkkynen <tuomas.tynkkynen@iki.fi> hat am 4. Oktober 2018 um 11:37 geschrieben:
> 
> 
> Drop various pieces of dead code from here and there to get rid of
> the remaining users of VCHI_CONNECTION_T. After that we get to drop
> entire header files worth of unused code.
> 
> I've tested on a Raspberry Pi Model B (bcm2835_defconfig) that
> snd-bcm2835 can still play analog audio just fine.
> 

thanks and i'm fine with your patch series:

Acked-by: Stefan Wahren <stefan.wahren@i2se.com>

Unfortunately this would break compilation of the downstream vchi drivers like vcsm [1]. Personally i don't want to maintain another one, because i cannot see the gain of the resulting effort.

[1] - https://github.com/raspberrypi/linux/tree/rpi-4.14.y/drivers/char/broadcom/vc_sm

Re: [PATCH 0/7] staging: vc04_services: Some dead code removal

[Eric Anholt]

[-- Attachment #1: Type: text/plain, Size: 1149 bytes --]

Stefan Wahren <stefan.wahren@i2se.com> writes:

> Hi Tuomas,
>
>> Tuomas Tynkkynen <tuomas.tynkkynen@iki.fi> hat am 4. Oktober 2018 um 11:37 geschrieben:
>> 
>> 
>> Drop various pieces of dead code from here and there to get rid of
>> the remaining users of VCHI_CONNECTION_T. After that we get to drop
>> entire header files worth of unused code.
>> 
>> I've tested on a Raspberry Pi Model B (bcm2835_defconfig) that
>> snd-bcm2835 can still play analog audio just fine.
>> 
>
> thanks and i'm fine with your patch series:
>
> Acked-by: Stefan Wahren <stefan.wahren@i2se.com>
>
> Unfortunately this would break compilation of the downstream vchi
> drivers like vcsm [1]. Personally i don't want to maintain another
> one, because i cannot see the gain of the resulting effort.
>
> [1] - https://github.com/raspberrypi/linux/tree/rpi-4.14.y/drivers/char/broadcom/vc_sm

I think the main concern would be if we removed things necessary for
6by9's new vcsm (the one that will let us do dma-buf sharing between
media decode and DRM).

On the other hand, git revert is a thing, so it's not like we actually
lose anything.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 832 bytes --]

Re: [PATCH 0/7] staging: vc04_services: Some dead code removal

[Dave Stevenson]

On Mon, 15 Oct 2018 at 17:27, Eric Anholt <eric@anholt.net> wrote:
>
> Stefan Wahren <stefan.wahren@i2se.com> writes:
>
> > Hi Tuomas,
> >
> >> Tuomas Tynkkynen <tuomas.tynkkynen@iki.fi> hat am 4. Oktober 2018 um 11:37 geschrieben:
> >>
> >>
> >> Drop various pieces of dead code from here and there to get rid of
> >> the remaining users of VCHI_CONNECTION_T. After that we get to drop
> >> entire header files worth of unused code.
> >>
> >> I've tested on a Raspberry Pi Model B (bcm2835_defconfig) that
> >> snd-bcm2835 can still play analog audio just fine.
> >>
> >
> > thanks and i'm fine with your patch series:
> >
> > Acked-by: Stefan Wahren <stefan.wahren@i2se.com>
> >
> > Unfortunately this would break compilation of the downstream vchi
> > drivers like vcsm [1]. Personally i don't want to maintain another
> > one, because i cannot see the gain of the resulting effort.
> >
> > [1] - https://github.com/raspberrypi/linux/tree/rpi-4.14.y/drivers/char/broadcom/vc_sm

I'm happy enough to work around these changes. Once the change is in a
released kernel we can merge a modified version of vc_sm into the
downstream kernel branch. It's not as if it requires big changes.

> I think the main concern would be if we removed things necessary for
> 6by9's new vcsm (the one that will let us do dma-buf sharing between
> media decode and DRM).

The new vcsm uses the same VCHI service as the existing downstream vc_sm driver.
The video codec driver don't use any VCHI functionality over and above
the camera. It goes via a slightly extended version of the
mmal-vchiq.c, which I have split out into a shared module.

> On the other hand, git revert is a thing, so it's not like we actually
> lose anything.

:-)

  Dave

Re: [PATCH 0/7] staging: vc04_services: Some dead code removal

[Dan Carpenter]

On Sat, Oct 06, 2018 at 12:18:38PM +0200, Stefan Wahren wrote:
> Hi Tuomas,
> 
> > Tuomas Tynkkynen <tuomas.tynkkynen@iki.fi> hat am 4. Oktober 2018 um 11:37 geschrieben:
> > 
> > 
> > Drop various pieces of dead code from here and there to get rid of
> > the remaining users of VCHI_CONNECTION_T. After that we get to drop
> > entire header files worth of unused code.
> > 
> > I've tested on a Raspberry Pi Model B (bcm2835_defconfig) that
> > snd-bcm2835 can still play analog audio just fine.
> > 
> 
> thanks and i'm fine with your patch series:
> 
> Acked-by: Stefan Wahren <stefan.wahren@i2se.com>
> 
> Unfortunately this would break compilation of the downstream vchi
> drivers like vcsm [1]. Personally i don't want to maintain another
> one, because i cannot see the gain of the resulting effort.
> 
> [1] - https://github.com/raspberrypi/linux/tree/rpi-4.14.y/drivers/char/broadcom/vc_sm


I feel like everyone else already knows the answer but why don't we just
merge that code into staging?

regards,
dan carpenter

Re: [PATCH 0/7] staging: vc04_services: Some dead code removal

[Stefan Wahren]

Hi,

Am 17.10.2018 um 11:55 schrieb Dave Stevenson:
> On Mon, 15 Oct 2018 at 17:27, Eric Anholt <eric@anholt.net> wrote:
>> Stefan Wahren <stefan.wahren@i2se.com> writes:
>>
>>> Hi Tuomas,
>>>
>>>> Tuomas Tynkkynen <tuomas.tynkkynen@iki.fi> hat am 4. Oktober 2018 um 11:37 geschrieben:
>>>>
>>>>
>>>> Drop various pieces of dead code from here and there to get rid of
>>>> the remaining users of VCHI_CONNECTION_T. After that we get to drop
>>>> entire header files worth of unused code.
>>>>
>>>> I've tested on a Raspberry Pi Model B (bcm2835_defconfig) that
>>>> snd-bcm2835 can still play analog audio just fine.
>>>>
>>> thanks and i'm fine with your patch series:
>>>
>>> Acked-by: Stefan Wahren <stefan.wahren@i2se.com>
>>>
>>> Unfortunately this would break compilation of the downstream vchi
>>> drivers like vcsm [1]. Personally i don't want to maintain another
>>> one, because i cannot see the gain of the resulting effort.
>>>
>>> [1] - https://github.com/raspberrypi/linux/tree/rpi-4.14.y/drivers/char/broadcom/vc_sm
> I'm happy enough to work around these changes. Once the change is in a
> released kernel we can merge a modified version of vc_sm into the
> downstream kernel branch. It's not as if it requires big changes.
>
>> I think the main concern would be if we removed things necessary for
>> 6by9's new vcsm (the one that will let us do dma-buf sharing between
>> media decode and DRM).
> The new vcsm uses the same VCHI service as the existing downstream vc_sm driver.
> The video codec driver don't use any VCHI functionality over and above
> the camera. It goes via a slightly extended version of the
> mmal-vchiq.c, which I have split out into a shared module.

my statement about the old vc_sm based on assumption there wont be a
user of this driver.

In case the camera driver would use the new vc_sm driver, i would be
happier to see this merged in staging than in downstream.

Stefan

>
>> On the other hand, git revert is a thing, so it's not like we actually
>> lose anything.
> :-)
>
>   Dave

Re: [PATCH 0/7] staging: vc04_services: Some dead code removal

[Eric Anholt]

[-- Attachment #1: Type: text/plain, Size: 1968 bytes --]

Dan Carpenter <dan.carpenter@oracle.com> writes:

> On Sat, Oct 06, 2018 at 12:18:38PM +0200, Stefan Wahren wrote:
>> Hi Tuomas,
>> 
>> > Tuomas Tynkkynen <tuomas.tynkkynen@iki.fi> hat am 4. Oktober 2018 um 11:37 geschrieben:
>> > 
>> > 
>> > Drop various pieces of dead code from here and there to get rid of
>> > the remaining users of VCHI_CONNECTION_T. After that we get to drop
>> > entire header files worth of unused code.
>> > 
>> > I've tested on a Raspberry Pi Model B (bcm2835_defconfig) that
>> > snd-bcm2835 can still play analog audio just fine.
>> > 
>> 
>> thanks and i'm fine with your patch series:
>> 
>> Acked-by: Stefan Wahren <stefan.wahren@i2se.com>
>> 
>> Unfortunately this would break compilation of the downstream vchi
>> drivers like vcsm [1]. Personally i don't want to maintain another
>> one, because i cannot see the gain of the resulting effort.
>> 
>> [1] - https://github.com/raspberrypi/linux/tree/rpi-4.14.y/drivers/char/broadcom/vc_sm
>
>
> I feel like everyone else already knows the answer but why don't we just
> merge that code into staging?

Dave's been working on a new VCSM service where the firmware can call
back into Linux to allocate (instead of just having a permanent carveout
of system memory that the firmware allocates from), and lets us make
dma-bufs out of those buffers.  That driver makes a no-copies v4l2 media
decode driver possible, which would then let Kodi and similar projects
switch from downstream kernels with closed graphics to upstream kernels
with open graphics.

Given that the new VCSM service is a rewrite, it's not clear to me that
importing the old VCSM driver is a win.  But maybe we should go raid
https://github.com/6by9/linux/tree/rpi-4.14.y-codecs-push-pt2a and grab
the new drivers.  Upstreaming the VCHI audio driver to staging has
clearly been a win for it, so maybe other eyes on the new v4l2 codec
could help Dave along in stabilizing it.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 832 bytes --]

Re: [PATCH 0/7] staging: vc04_services: Some dead code removal

[Peter Robinson]

> >> > Drop various pieces of dead code from here and there to get rid of
> >> > the remaining users of VCHI_CONNECTION_T. After that we get to drop
> >> > entire header files worth of unused code.
> >> >
> >> > I've tested on a Raspberry Pi Model B (bcm2835_defconfig) that
> >> > snd-bcm2835 can still play analog audio just fine.
> >> >
> >>
> >> thanks and i'm fine with your patch series:
> >>
> >> Acked-by: Stefan Wahren <stefan.wahren@i2se.com>
> >>
> >> Unfortunately this would break compilation of the downstream vchi
> >> drivers like vcsm [1]. Personally i don't want to maintain another
> >> one, because i cannot see the gain of the resulting effort.
> >>
> >> [1] - https://github.com/raspberrypi/linux/tree/rpi-4.14.y/drivers/char/broadcom/vc_sm
> >
> >
> > I feel like everyone else already knows the answer but why don't we just
> > merge that code into staging?
>
> Dave's been working on a new VCSM service where the firmware can call
> back into Linux to allocate (instead of just having a permanent carveout
> of system memory that the firmware allocates from), and lets us make
> dma-bufs out of those buffers.  That driver makes a no-copies v4l2 media
> decode driver possible, which would then let Kodi and similar projects
> switch from downstream kernels with closed graphics to upstream kernels
> with open graphics.
>
> Given that the new VCSM service is a rewrite, it's not clear to me that
> importing the old VCSM driver is a win.  But maybe we should go raid
> https://github.com/6by9/linux/tree/rpi-4.14.y-codecs-push-pt2a and grab
> the new drivers.  Upstreaming the VCHI audio driver to staging has
> clearly been a win for it, so maybe other eyes on the new v4l2 codec
> could help Dave along in stabilizing it.

I think that makes sense as long as the firmware side changes are in
place so it can actually be used.

Peter

Re: [PATCH 0/7] staging: vc04_services: Some dead code removal

[Dave Stevenson]

On Wed, 17 Oct 2018 at 17:51, Peter Robinson <pbrobinson@gmail.com> wrote:
>
> > >> > Drop various pieces of dead code from here and there to get rid of
> > >> > the remaining users of VCHI_CONNECTION_T. After that we get to drop
> > >> > entire header files worth of unused code.
> > >> >
> > >> > I've tested on a Raspberry Pi Model B (bcm2835_defconfig) that
> > >> > snd-bcm2835 can still play analog audio just fine.
> > >> >
> > >>
> > >> thanks and i'm fine with your patch series:
> > >>
> > >> Acked-by: Stefan Wahren <stefan.wahren@i2se.com>
> > >>
> > >> Unfortunately this would break compilation of the downstream vchi
> > >> drivers like vcsm [1]. Personally i don't want to maintain another
> > >> one, because i cannot see the gain of the resulting effort.
> > >>
> > >> [1] - https://github.com/raspberrypi/linux/tree/rpi-4.14.y/drivers/char/broadcom/vc_sm
> > >
> > >
> > > I feel like everyone else already knows the answer but why don't we just
> > > merge that code into staging?
> >
> > Dave's been working on a new VCSM service where the firmware can call
> > back into Linux to allocate (instead of just having a permanent carveout
> > of system memory that the firmware allocates from), and lets us make
> > dma-bufs out of those buffers.  That driver makes a no-copies v4l2 media
> > decode driver possible, which would then let Kodi and similar projects
> > switch from downstream kernels with closed graphics to upstream kernels
> > with open graphics.
> >
> > Given that the new VCSM service is a rewrite, it's not clear to me that
> > importing the old VCSM driver is a win.  But maybe we should go raid
> > https://github.com/6by9/linux/tree/rpi-4.14.y-codecs-push-pt2a and grab
> > the new drivers.  Upstreaming the VCHI audio driver to staging has
> > clearly been a win for it, so maybe other eyes on the new v4l2 codec
> > could help Dave along in stabilizing it.
>
> I think that makes sense as long as the firmware side changes are in
> place so it can actually be used.

The firmware has supported the necessary for dmabuf import since Sept 2017.

The new vcsm driver currently only supports importing from other
kernel modules as I cut it back to the bare minimum to ease
upstreaming. To be a complete replacement of the existing then it
needs to support userspace alloc/free/import/mmap. I did have most of
that working, but will add it in stages.
The codec code is working for decode but something is off for setting
formats on encode.
Both drivers are loading through DT at the moment as I couldn't get
Eric's platform driver stuff working. IIRC A combination of modules
not getting loaded and getting the appropriate coherent DMA mask set
(being under soc in DT gives the correct mappings, but being a
platform driver didn't).

I'm fire-fighting a networking issue at the moment, but hope to be
back on codecs next week.
Could you hold off raiding my trees until say Fri 26th Oct so I can
ensure they are fully up to date? If I get a chance then I'll start
the work of porting into staging before then.

  Dave

Re: [PATCH 0/7] staging: vc04_services: Some dead code removal

[Stefan Wahren]

Am 18.10.2018 um 11:22 schrieb Dave Stevenson:
> On Wed, 17 Oct 2018 at 17:51, Peter Robinson <pbrobinson@gmail.com> wrote:
>>>>>> Drop various pieces of dead code from here and there to get rid of
>>>>>> the remaining users of VCHI_CONNECTION_T. After that we get to drop
>>>>>> entire header files worth of unused code.
>>>>>>
>>>>>> I've tested on a Raspberry Pi Model B (bcm2835_defconfig) that
>>>>>> snd-bcm2835 can still play analog audio just fine.
>>>>>>
>>>>> thanks and i'm fine with your patch series:
>>>>>
>>>>> Acked-by: Stefan Wahren <stefan.wahren@i2se.com>
>>>>>
>>>>> Unfortunately this would break compilation of the downstream vchi
>>>>> drivers like vcsm [1]. Personally i don't want to maintain another
>>>>> one, because i cannot see the gain of the resulting effort.
>>>>>
>>>>> [1] - https://github.com/raspberrypi/linux/tree/rpi-4.14.y/drivers/char/broadcom/vc_sm
>>>>
>>>> I feel like everyone else already knows the answer but why don't we just
>>>> merge that code into staging?
>>> Dave's been working on a new VCSM service where the firmware can call
>>> back into Linux to allocate (instead of just having a permanent carveout
>>> of system memory that the firmware allocates from), and lets us make
>>> dma-bufs out of those buffers.  That driver makes a no-copies v4l2 media
>>> decode driver possible, which would then let Kodi and similar projects
>>> switch from downstream kernels with closed graphics to upstream kernels
>>> with open graphics.
>>>
>>> Given that the new VCSM service is a rewrite, it's not clear to me that
>>> importing the old VCSM driver is a win.  But maybe we should go raid
>>> https://github.com/6by9/linux/tree/rpi-4.14.y-codecs-push-pt2a and grab
>>> the new drivers.  Upstreaming the VCHI audio driver to staging has
>>> clearly been a win for it, so maybe other eyes on the new v4l2 codec
>>> could help Dave along in stabilizing it.
>> I think that makes sense as long as the firmware side changes are in
>> place so it can actually be used.
> The firmware has supported the necessary for dmabuf import since Sept 2017.
>
> The new vcsm driver currently only supports importing from other
> kernel modules as I cut it back to the bare minimum to ease
> upstreaming. To be a complete replacement of the existing then it
> needs to support userspace alloc/free/import/mmap. I did have most of
> that working, but will add it in stages.
> The codec code is working for decode but something is off for setting
> formats on encode.
> Both drivers are loading through DT at the moment as I couldn't get
> Eric's platform driver stuff working. IIRC A combination of modules
> not getting loaded and getting the appropriate coherent DMA mask set
> (being under soc in DT gives the correct mappings, but being a
> platform driver didn't).

I'm working on these issues and i will post a proper solution soon.

In case you need a hack in order to test your stuff, i can prepare a
branch for you.

>
> I'm fire-fighting a networking issue at the moment, but hope to be
> back on codecs next week.
> Could you hold off raiding my trees until say Fri 26th Oct so I can
> ensure they are fully up to date? If I get a chance then I'll start
> the work of porting into staging before then.

The merge window will open soon, so i don't see the need to hurry.

Thanks
Stefan

>
>   Dave
>
> _______________________________________________
> linux-rpi-kernel mailing list
> linux-rpi-kernel@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-rpi-kernel

Re: [PATCH 0/7] staging: vc04_services: Some dead code removal

[Dave Stevenson]

On Thu, 18 Oct 2018 at 10:38, Stefan Wahren <stefan.wahren@i2se.com> wrote:
>
> Am 18.10.2018 um 11:22 schrieb Dave Stevenson:
> > On Wed, 17 Oct 2018 at 17:51, Peter Robinson <pbrobinson@gmail.com> wrote:
> >>>>>> Drop various pieces of dead code from here and there to get rid of
> >>>>>> the remaining users of VCHI_CONNECTION_T. After that we get to drop
> >>>>>> entire header files worth of unused code.
> >>>>>>
> >>>>>> I've tested on a Raspberry Pi Model B (bcm2835_defconfig) that
> >>>>>> snd-bcm2835 can still play analog audio just fine.
> >>>>>>
> >>>>> thanks and i'm fine with your patch series:
> >>>>>
> >>>>> Acked-by: Stefan Wahren <stefan.wahren@i2se.com>
> >>>>>
> >>>>> Unfortunately this would break compilation of the downstream vchi
> >>>>> drivers like vcsm [1]. Personally i don't want to maintain another
> >>>>> one, because i cannot see the gain of the resulting effort.
> >>>>>
> >>>>> [1] - https://github.com/raspberrypi/linux/tree/rpi-4.14.y/drivers/char/broadcom/vc_sm
> >>>>
> >>>> I feel like everyone else already knows the answer but why don't we just
> >>>> merge that code into staging?
> >>> Dave's been working on a new VCSM service where the firmware can call
> >>> back into Linux to allocate (instead of just having a permanent carveout
> >>> of system memory that the firmware allocates from), and lets us make
> >>> dma-bufs out of those buffers.  That driver makes a no-copies v4l2 media
> >>> decode driver possible, which would then let Kodi and similar projects
> >>> switch from downstream kernels with closed graphics to upstream kernels
> >>> with open graphics.
> >>>
> >>> Given that the new VCSM service is a rewrite, it's not clear to me that
> >>> importing the old VCSM driver is a win.  But maybe we should go raid
> >>> https://github.com/6by9/linux/tree/rpi-4.14.y-codecs-push-pt2a and grab
> >>> the new drivers.  Upstreaming the VCHI audio driver to staging has
> >>> clearly been a win for it, so maybe other eyes on the new v4l2 codec
> >>> could help Dave along in stabilizing it.
> >> I think that makes sense as long as the firmware side changes are in
> >> place so it can actually be used.
> > The firmware has supported the necessary for dmabuf import since Sept 2017.
> >
> > The new vcsm driver currently only supports importing from other
> > kernel modules as I cut it back to the bare minimum to ease
> > upstreaming. To be a complete replacement of the existing then it
> > needs to support userspace alloc/free/import/mmap. I did have most of
> > that working, but will add it in stages.
> > The codec code is working for decode but something is off for setting
> > formats on encode.
> > Both drivers are loading through DT at the moment as I couldn't get
> > Eric's platform driver stuff working. IIRC A combination of modules
> > not getting loaded and getting the appropriate coherent DMA mask set
> > (being under soc in DT gives the correct mappings, but being a
> > platform driver didn't).
>
> I'm working on these issues and i will post a proper solution soon.
>
> In case you need a hack in order to test your stuff, i can prepare a
> branch for you.

Thanks Stefan.
I've picked up your latest patches which mean I can get the driver
loaded via the (almost) approved method.
I do seem to still have issues with not getting the expected address
ranges, so the driver/VPU was trying to map cached alias memory. As
your patches only came through yesterday I haven't had a chance to dig
through why yet. I've done a temporary hack to ensure we always map
the uncached alias, but that can't persist.

> >
> > I'm fire-fighting a networking issue at the moment, but hope to be
> > back on codecs next week.
> > Could you hold off raiding my trees until say Fri 26th Oct so I can
> > ensure they are fully up to date? If I get a chance then I'll start
> > the work of porting into staging before then.
>
> The merge window will open soon, so i don't see the need to hurry.

The networking issue has been resolved :-)

I've pushed where I've got to to
https://github.com/6by9/linux/tree/rpi-4.14.y-codecs-push-pt2b
It's a touch messy due to integrating in your patches in the last 24
hours. It needs a full rebase so that my changes are on top of yours
rather than haphazard.
As we're moving to 4.19 fairly soon I may well abandon my 4.14 tree
and jump to either that or directly on staging. I'll see where I get
to early next week.

  Dave

Re: [PATCH 0/7] staging: vc04_services: Some dead code removal

[Stefan Wahren]

Hi Dave,

> Dave Stevenson <dave.stevenson@raspberrypi.org> hat am 26. Oktober 2018 um 19:15 geschrieben:
> 
> 
> Thanks Stefan.
> I've picked up your latest patches which mean I can get the driver
> loaded via the (almost) approved method.
> I do seem to still have issues with not getting the expected address
> ranges, so the driver/VPU was trying to map cached alias memory. As
> your patches only came through yesterday I haven't had a chance to dig
> through why yet. I've done a temporary hack to ensure we always map
> the uncached alias, but that can't persist.

does it mean with DT probing it worked before and with platform change it's broken?
Or anything else cause this regression in 4.19?

> The networking issue has been resolved :-)
> 
> I've pushed where I've got to to
> https://github.com/6by9/linux/tree/rpi-4.14.y-codecs-push-pt2b
> It's a touch messy due to integrating in your patches in the last 24
> hours. It needs a full rebase so that my changes are on top of yours
> rather than haphazard.
> As we're moving to 4.19 fairly soon I may well abandon my 4.14 tree
> and jump to either that or directly on staging. I'll see where I get
> to early next week.

Sorry, but there is no need for a quick shot against a downstream 4.14. I assumed you make your changes against upstream linux-next + Phil's and my patches.

You can use https://github.com/anholt/linux/commits/bcm2835-audio until 4.20-rc1 is out.
Using 4.14 or 4.19 doesn't make any sense to me.

Regards
Stefan

> 
>   Dave

Re: [PATCH 0/7] staging: vc04_services: Some dead code removal

[Dave Stevenson]

Hi Stefan

On Sun, 28 Oct 2018 at 08:31, Stefan Wahren <stefan.wahren@i2se.com> wrote:
>
> Hi Dave,
>
> > Dave Stevenson <dave.stevenson@raspberrypi.org> hat am 26. Oktober 2018 um 19:15 geschrieben:
> >
> >
> > Thanks Stefan.
> > I've picked up your latest patches which mean I can get the driver
> > loaded via the (almost) approved method.
> > I do seem to still have issues with not getting the expected address
> > ranges, so the driver/VPU was trying to map cached alias memory. As
> > your patches only came through yesterday I haven't had a chance to dig
> > through why yet. I've done a temporary hack to ensure we always map
> > the uncached alias, but that can't persist.
>
> does it mean with DT probing it worked before and with platform change it's broken?
> Or anything else cause this regression in 4.19?

Yes, probing via DT with the node under soc gave me the correct DMA
addresses (uncached alias). With the platform changes I get the cached
alias.
Both were under 4.14. I'll try again on a later branch.

> > The networking issue has been resolved :-)
> >
> > I've pushed where I've got to to
> > https://github.com/6by9/linux/tree/rpi-4.14.y-codecs-push-pt2b
> > It's a touch messy due to integrating in your patches in the last 24
> > hours. It needs a full rebase so that my changes are on top of yours
> > rather than haphazard.
> > As we're moving to 4.19 fairly soon I may well abandon my 4.14 tree
> > and jump to either that or directly on staging. I'll see where I get
> > to early next week.
>
> Sorry, but there is no need for a quick shot against a downstream 4.14. I assumed you make your changes against upstream linux-next + Phil's and my patches.
>
> You can use https://github.com/anholt/linux/commits/bcm2835-audio until 4.20-rc1 is out.
> Using 4.14 or 4.19 doesn't make any sense to me.

As an employee of Raspberry Pi Trading my first responsibilty is to
them, and that means LTS releases feeding in to the downstream kernel.
If these drivers can be pushed upstream then that's a win as it avoids
divergence, but it is not my main goal. At least 4.19 and 4.20 aren't
far apart so there are likely to be fewer differences.

I had it all working on 4.14, therefore it made sense to see whether
your changes allowed me to load as a platform driver. It did, but with
this little niggle over cache aliases. I'll try again on a later
kernel and try to get some more info.

  Dave