linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Nicolas Saenz Julienne <nsaenzjulienne@suse.de>
To: bcm-kernel-feedback-list@broadcom.com,
	linux-rpi-kernel@lists.infradead.org,
	linux-arm-kernel@lists.infradead.org,
	linux-kernel@vger.kernel.org
Cc: kernel-list@raspberrypi.com, laurent.pinchart@ideasonboard.com,
	gregkh@linuxfoundation.org,
	Nicolas Saenz Julienne <nsaenzjulienne@suse.de>,
	devel@driverdev.osuosl.org
Subject: [RFC 20/50] staging: vc04_services: Get rid of vchi_cfg.h
Date: Wed, 27 May 2020 13:53:25 +0200	[thread overview]
Message-ID: <20200527115400.31391-21-nsaenzjulienne@suse.de> (raw)
In-Reply-To: <20200527115400.31391-1-nsaenzjulienne@suse.de>

Nothing in it is being used.

Signed-off-by: Nicolas Saenz Julienne <nsaenzjulienne@suse.de>
---
 .../vc04_services/interface/vchi/vchi.h       |   1 -
 .../vc04_services/interface/vchi/vchi_cfg.h   | 238 ------------------
 2 files changed, 239 deletions(-)
 delete mode 100644 drivers/staging/vc04_services/interface/vchi/vchi_cfg.h

diff --git a/drivers/staging/vc04_services/interface/vchi/vchi.h b/drivers/staging/vc04_services/interface/vchi/vchi.h
index bf0c7a496f5a..55e51e5a1fdc 100644
--- a/drivers/staging/vc04_services/interface/vchi/vchi.h
+++ b/drivers/staging/vc04_services/interface/vchi/vchi.h
@@ -4,7 +4,6 @@
 #ifndef VCHI_H_
 #define VCHI_H_
 
-#include "vchi_cfg.h"
 #include "vchi_common.h"
 
 /******************************************************************************
diff --git a/drivers/staging/vc04_services/interface/vchi/vchi_cfg.h b/drivers/staging/vc04_services/interface/vchi/vchi_cfg.h
deleted file mode 100644
index 138c36151a22..000000000000
--- a/drivers/staging/vc04_services/interface/vchi/vchi_cfg.h
+++ /dev/null
@@ -1,238 +0,0 @@
-/* SPDX-License-Identifier: GPL-2.0 OR BSD-3-Clause */
-/* Copyright (c) 2010-2012 Broadcom. All rights reserved. */
-
-#ifndef VCHI_CFG_H_
-#define VCHI_CFG_H_
-
-/*******************************************************************************
- * Defines in this first section are part of the VCHI API and may be examined by
- * VCHI services.
- ******************************************************************************/
-
-/*
- * Required alignment of base addresses for bulk transfer, if unaligned
- * transfers are not enabled
- * Really determined by the message driver, and should be available from
- * a run-time call.
- */
-#ifndef VCHI_BULK_ALIGN
-#   if __VCCOREVER__ >= 0x04000000
-#       define VCHI_BULK_ALIGN 32 // Allows for the need to do cache cleans
-#   else
-#       define VCHI_BULK_ALIGN 16
-#   endif
-#endif
-
-/*
- * Required length multiple for bulk transfers, if unaligned transfers are
- * not enabled
- * May be less than or greater than VCHI_BULK_ALIGN
- * Really determined by the message driver, and should be available from
- * a run-time call.
- */
-#ifndef VCHI_BULK_GRANULARITY
-#   if __VCCOREVER__ >= 0x04000000
-#       define VCHI_BULK_GRANULARITY 32 // Allows for the need to do cache cleans
-#   else
-#       define VCHI_BULK_GRANULARITY 16
-#   endif
-#endif
-
-/* The largest possible message to be queued with vchi_msg_queue. */
-#ifndef VCHI_MAX_MSG_SIZE
-#   if defined VCHI_LOCAL_HOST_PORT
-#       define VCHI_MAX_MSG_SIZE     16384         // makes file transfers fast, but should they be using bulk?
-#   else
-#       define VCHI_MAX_MSG_SIZE      4096 // NOTE: THIS MUST BE LARGER THAN OR EQUAL TO THE SIZE OF THE KHRONOS MERGE BUFFER!!
-#   endif
-#endif
-
-/******************************************************************************
- * Defines below are system configuration options, and should not be used by
- * VCHI services.
- ******************************************************************************/
-
-/*
- * How many connections can we support? A localhost implementation uses
- * 2 connections, 1 for host-app, 1 for VMCS, and these are hooked together
- * by a loopback MPHI VCFW  driver.
- */
-#ifndef VCHI_MAX_NUM_CONNECTIONS
-#   define VCHI_MAX_NUM_CONNECTIONS 3
-#endif
-
-/*
- * How many services can we open per connection? Extending this doesn't cost
- * processing time, just a small amount of static memory.
- */
-#ifndef VCHI_MAX_SERVICES_PER_CONNECTION
-#  define VCHI_MAX_SERVICES_PER_CONNECTION 36
-#endif
-
-/* Adjust if using a message driver that supports more logical TX channels */
-#ifndef VCHI_MAX_BULK_TX_CHANNELS_PER_CONNECTION
-#   define VCHI_MAX_BULK_TX_CHANNELS_PER_CONNECTION 9 // 1 MPHI + 8 CCP2 logical channels
-#endif
-
-/* Adjust if using a message driver that supports more logical RX channels */
-#ifndef VCHI_MAX_BULK_RX_CHANNELS_PER_CONNECTION
-#   define VCHI_MAX_BULK_RX_CHANNELS_PER_CONNECTION 1 // 1 MPHI
-#endif
-
-/*
- * How many receive slots do we use. This times VCHI_MAX_MSG_SIZE gives the
- * effective receive queue space, less message headers.
- */
-#ifndef VCHI_NUM_READ_SLOTS
-#  if defined(VCHI_LOCAL_HOST_PORT)
-#     define VCHI_NUM_READ_SLOTS 4
-#  else
-#     define VCHI_NUM_READ_SLOTS 48
-#  endif
-#endif
-
-/*
- * Do we utilise overrun facility for receive message slots? Can aid peer
- * transmit performance. Only define on VideoCore end, talking to host.
- */
-//#define VCHI_MSG_RX_OVERRUN
-
-/*
- * How many transmit slots do we use. Generally don't need many,
- * as the hardware driver underneath VCHI will usually have its own buffering.
- */
-#ifndef VCHI_NUM_WRITE_SLOTS
-#  define VCHI_NUM_WRITE_SLOTS 4
-#endif
-
-/*
- * If a service has held or queued received messages in VCHI_XOFF_THRESHOLD or
- * more slots, then it's taking up too much buffer space,
- * and the peer service will be told to stop transmitting with an XOFF message.
- * For this to be effective, the VCHI_NUM_READ_SLOTS needs to be considerably
- * bigger than VCHI_NUM_WRITE_SLOTS, or the transmit latency is too high.
- */
-#ifndef VCHI_XOFF_THRESHOLD
-#  define VCHI_XOFF_THRESHOLD (VCHI_NUM_READ_SLOTS / 2)
-#endif
-
-/*
- * After we've sent an XOFF, the peer will be told to resume transmission
- * once the local service has dequeued/released enough messages that it's now
- * occupying VCHI_XON_THRESHOLD slots or fewer.
- */
-#ifndef VCHI_XON_THRESHOLD
-#  define VCHI_XON_THRESHOLD (VCHI_NUM_READ_SLOTS / 4)
-#endif
-
-/*
- * A size below which a bulk transfer omits the handshake completely and always
- * goes via the message channel, if bulk auxiliary is being sent on that
- * service. (The user can guarantee this by enabling unaligned transmits).
- * Not API.
- */
-#ifndef VCHI_MIN_BULK_SIZE
-#  define VCHI_MIN_BULK_SIZE    (VCHI_MAX_MSG_SIZE / 2 < 4096 ? VCHI_MAX_MSG_SIZE / 2 : 4096)
-#endif
-
-/*
- * Maximum size of bulk transmission chunks, for each interface type.
- * A trade-off between speed and latency; the smaller the chunk size the better
- * change of messages and other bulk transmissions getting in when big bulk
- * transfers are happening. Set to 0 to not break transmissions into chunks.
- */
-#ifndef VCHI_MAX_BULK_CHUNK_SIZE_MPHI
-#  define VCHI_MAX_BULK_CHUNK_SIZE_MPHI (16 * 1024)
-#endif
-
-/*
- * NB Chunked CCP2 transmissions violate the letter of the CCP2 spec
- * by using "JPEG8" mode with multiple-line frames. Only use if the receiver
- * can cope.
- */
-#ifndef VCHI_MAX_BULK_CHUNK_SIZE_CCP2
-#  define VCHI_MAX_BULK_CHUNK_SIZE_CCP2 0
-#endif
-
-/*
- * How many TX messages can we have pending in our transmit slots.
- * Once exhausted, vchi_msg_queue will be blocked.
- */
-#ifndef VCHI_TX_MSG_QUEUE_SIZE
-#  define VCHI_TX_MSG_QUEUE_SIZE           256
-#endif
-
-/*
- * How many RX messages can we have parsed in the receive slots. Once exhausted,
- * parsing will be suspended until older messages are dequeued/released.
- */
-#ifndef VCHI_RX_MSG_QUEUE_SIZE
-#  define VCHI_RX_MSG_QUEUE_SIZE           256
-#endif
-
-/*
- * Really should be able to cope if we run out of received message descriptors,
- * by suspending parsing as the comment above says, but we don't.
- * This sweeps the issue under the carpet.
- */
-#if VCHI_RX_MSG_QUEUE_SIZE < (VCHI_MAX_MSG_SIZE / 16 + 1) * VCHI_NUM_READ_SLOTS
-#  undef VCHI_RX_MSG_QUEUE_SIZE
-#  define VCHI_RX_MSG_QUEUE_SIZE ((VCHI_MAX_MSG_SIZE / 16 + 1) * VCHI_NUM_READ_SLOTS)
-#endif
-
-/*
- * How many bulk transmits can we have pending. Once exhausted,
- * vchi_bulk_queue_transmit will be blocked.
- */
-#ifndef VCHI_TX_BULK_QUEUE_SIZE
-#  define VCHI_TX_BULK_QUEUE_SIZE           64
-#endif
-
-/*
- * How many bulk receives can we have pending. Once exhausted,
- *vchi_bulk_queue_receive will be blocked.
- */
-#ifndef VCHI_RX_BULK_QUEUE_SIZE
-#  define VCHI_RX_BULK_QUEUE_SIZE           64
-#endif
-
-/*
- * A limit on how many outstanding bulk requests we expect the peer to give us.
- * If the peer asks for more than this, VCHI will fail and assert.
- * The number is determined by the peer's hardware
- * - it's the number of outstanding requests that can be queued
- * on all bulk channels. VC3's MPHI peripheral allows 16.
- */
-#ifndef VCHI_MAX_PEER_BULK_REQUESTS
-#  define VCHI_MAX_PEER_BULK_REQUESTS       32
-#endif
-
-/*
- * Define VCHI_CCP2TX_MANUAL_POWER if the host tells us when to turn the CCP2
- * transmitter on and off.
- */
-/*#define VCHI_CCP2TX_MANUAL_POWER*/
-
-#ifndef VCHI_CCP2TX_MANUAL_POWER
-
-/*
- * Timeout (in milliseconds) for putting the CCP2TX interface into IDLE state.
- * Set negative for no IDLE.
- */
-#  ifndef VCHI_CCP2TX_IDLE_TIMEOUT
-#    define VCHI_CCP2TX_IDLE_TIMEOUT        5
-#  endif
-
-/*
- * Timeout (in milliseconds) for putting the CCP2TX interface into OFF state.
- * Set negative for no OFF.
- */
-#  ifndef VCHI_CCP2TX_OFF_TIMEOUT
-#    define VCHI_CCP2TX_OFF_TIMEOUT         1000
-#  endif
-
-#endif /* VCHI_CCP2TX_MANUAL_POWER */
-
-#endif /* VCHI_CFG_H_ */
-
-/****************************** End of file **********************************/
-- 
2.26.2


  parent reply	other threads:[~2020-05-27 11:57 UTC|newest]

Thread overview: 52+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-05-27 11:53 [RFC 00/50] staging: vchiq: Getting rid of the vchi/vchiq split Nicolas Saenz Julienne
2020-05-27 11:53 ` [RFC 01/50] staging: vchi: Get rid of vchi_service_destroy() Nicolas Saenz Julienne
2020-05-27 11:53 ` [RFC 02/50] staging: vchi: Get rid of vchi_queue_user_message() Nicolas Saenz Julienne
2020-05-27 11:53 ` [RFC 03/50] staging: vchiq: Move copy callback handling into vchiq Nicolas Saenz Julienne
2020-05-27 11:53 ` [RFC 04/50] staging: vchi: Merge vchi_msg_queue() into vchi_queue_kernel_message() Nicolas Saenz Julienne
2020-05-27 11:53 ` [RFC 05/50] staging: vchi: Get rid of vchi_service_set_option() Nicolas Saenz Julienne
2020-05-27 11:53 ` [RFC 06/50] staging: vchi: Get rid of vchiq_status_to_vchi() Nicolas Saenz Julienne
2020-05-27 11:53 ` [RFC 07/50] staging: vchi: Get rid of not implemented function declarations Nicolas Saenz Julienne
2020-05-27 11:53 ` [RFC 08/50] staging: vchi: Get rid of C++ guards Nicolas Saenz Julienne
2020-05-27 11:53 ` [RFC 09/50] staging: vchiq: move vchiq_release_message() into vchiq Nicolas Saenz Julienne
2020-05-27 11:53 ` [RFC 10/50] staging: vchiq: Get rid of VCHIQ_SERVICE_OPENEND callback reason Nicolas Saenz Julienne
2020-05-27 11:53 ` [RFC 11/50] staging: vchi: Get rid of all useless callback reasons Nicolas Saenz Julienne
2020-05-27 11:53 ` [RFC 12/50] staging: vchi: Get rid of vchi_msg_peek() Nicolas Saenz Julienne
2020-05-27 11:53 ` [RFC 13/50] staging: vchi: Get rid of struct vchi_instance_handle Nicolas Saenz Julienne
2020-05-27 11:53 ` [RFC 14/50] staging: vchi: Unify struct shim_service and struct vchi_service_handle Nicolas Saenz Julienne
2020-05-27 11:53 ` [RFC 15/50] staging: vc04_services: bcm2835-audio: Use vchi_msg_hold() Nicolas Saenz Julienne
2020-05-27 11:53 ` [RFC 16/50] staging: vchi: Get rid of vchi_msg_dequeue() Nicolas Saenz Julienne
2020-05-27 11:53 ` [RFC 17/50] staging: vchi_common: Get rid of all unused definitions Nicolas Saenz Julienne
2020-05-27 11:53 ` [RFC 18/50] staging: vc04_services: vc-sm-cma: Get rid of the multiple connections option Nicolas Saenz Julienne
2020-05-27 11:53 ` [RFC 19/50] staging: vchi: Get rid of unnecessary defines Nicolas Saenz Julienne
2020-05-27 11:53 ` Nicolas Saenz Julienne [this message]
2020-05-27 11:53 ` [RFC 21/50] staging: vchi: Get rid of flags argument in vchi_msg_hold() Nicolas Saenz Julienne
2020-05-27 11:53 ` [RFC 22/50] staging: vchi: Use enum vchiq_bulk_mode instead of vchi's transmission flags Nicolas Saenz Julienne
2020-05-27 11:53 ` [RFC 23/50] staging: vchi: Use vchiq's enum vchiq_reason Nicolas Saenz Julienne
2020-05-27 11:53 ` [RFC 24/50] staging: vchi: Get rid of effect less expression Nicolas Saenz Julienne
2020-05-27 11:53 ` [RFC 25/50] staging: vchiq: Introduce vchiq_validate_params() Nicolas Saenz Julienne
2020-05-27 11:53 ` [RFC 26/50] staging: vchiq: Move message queue into struct vchiq_service Nicolas Saenz Julienne
2020-05-27 11:53 ` [RFC 27/50] staging: vchiq: Get rid of vchiq_util.h Nicolas Saenz Julienne
2020-05-27 11:53 ` [RFC 28/50] staging: vchi: Expose struct vchi_service Nicolas Saenz Julienne
2020-05-27 11:53 ` [RFC 29/50] staging: vchiq: Export vchiq_get_service_userdata() Nicolas Saenz Julienne
2020-05-27 11:53 ` [RFC 30/50] staging: vchiq: Export vchiq_msg_queue_push Nicolas Saenz Julienne
2020-05-27 11:53 ` [RFC 31/50] staging: vchi: Get rid of vchiq_shim's message callback Nicolas Saenz Julienne
2020-05-27 11:53 ` [RFC 32/50] staging: vchiq: Don't use a typedef for vchiq_callback Nicolas Saenz Julienne
2020-05-27 11:53 ` [RFC 33/50] staging: vchi: Use struct vchiq_service_params Nicolas Saenz Julienne
2020-05-27 11:53 ` [RFC 34/50] staging: vchi: Get rid of struct vchi_service Nicolas Saenz Julienne
2020-05-27 11:53 ` [RFC 35/50] staging: vchiq: Pass vchiq's message when holding a message Nicolas Saenz Julienne
2020-05-27 11:53 ` [RFC 36/50] staging: vchi: Rework vchi_msg_hold() to match vchiq_msg_hold() Nicolas Saenz Julienne
2020-05-27 11:53 ` [RFC 37/50] staging: vchiq: Unify fourcc definition mechanisms Nicolas Saenz Julienne
2020-05-27 11:53 ` [RFC 38/50] staging: vchi: Get rid of struct vchiq_instance forward declaration Nicolas Saenz Julienne
2020-05-27 11:53 ` [RFC 39/50] staging: vchi: Don't include vchiq_core.h Nicolas Saenz Julienne
2020-05-27 11:53 ` [RFC 40/50] staging: vchiq: Get rid of unnecessary definitions in vchiq_if.h Nicolas Saenz Julienne
2020-05-27 11:53 ` [RFC 41/50] staging: vchiq: Make vchiq_add_service() local Nicolas Saenz Julienne
2020-05-27 11:53 ` [RFC 42/50] staging: vchiq: Move definitions only used by core into core header Nicolas Saenz Julienne
2020-05-27 11:53 ` [RFC 43/50] staging: vchi: Get rid of vchi_bulk_queue_receive() Nicolas Saenz Julienne
2020-05-27 11:53 ` [RFC 44/50] staging: vchi: Get rid of vchi_bulk_queue_transmit() Nicolas Saenz Julienne
2020-05-27 11:53 ` [RFC 45/50] staging: vchi: Move vchi_queue_kernel_message() into vchiq Nicolas Saenz Julienne
2020-05-27 11:53 ` [RFC 46/50] staging: vchiq: Get rid of vchi Nicolas Saenz Julienne
2020-05-27 11:53 ` [RFC 47/50] staging: vchiq: Move conditional barrier definition into vchiq_core.h Nicolas Saenz Julienne
2020-05-27 11:53 ` [RFC 48/50] staging: vchiq: Use vchiq.h as the main header file for services Nicolas Saenz Julienne
2020-05-27 11:53 ` [RFC 49/50] staging: vchiq: Move defines into core header Nicolas Saenz Julienne
2020-05-27 11:53 ` [RFC 50/50] staging: vchiq: Move vchiq.h into include directory Nicolas Saenz Julienne
2020-05-27 12:08 ` [RFC 00/50] staging: vchiq: Getting rid of the vchi/vchiq split Greg KH

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20200527115400.31391-21-nsaenzjulienne@suse.de \
    --to=nsaenzjulienne@suse.de \
    --cc=bcm-kernel-feedback-list@broadcom.com \
    --cc=devel@driverdev.osuosl.org \
    --cc=gregkh@linuxfoundation.org \
    --cc=kernel-list@raspberrypi.com \
    --cc=laurent.pinchart@ideasonboard.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-rpi-kernel@lists.infradead.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).