LKML Archive on lore.kernel.org
help / color / mirror / Atom feed
From: Eric Anholt <eric@anholt.net>
To: Stefan Wahren <stefan.wahren@i2se.com>,
	linux-rpi-kernel@lists.infradead.org,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	devel@driverdev.osuosl.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] staging: bcm2835-camera: Replace open-coded idr with a struct idr.
Date: Thu, 10 May 2018 17:41:09 -0700	[thread overview]
Message-ID: <87efij3ty2.fsf@anholt.net> (raw)
In-Reply-To: <1544770503.215491.1525995621129@email.1und1.de>


[-- Attachment #1.1: Type: text/plain, Size: 5497 bytes --]

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

> Hi Eric,
>
>> Eric Anholt <eric@anholt.net> hat am 11. Mai 2018 um 01:31 geschrieben:
>> 
>> 
>> We just need some integer handles that can map back to our message
>> struct when we're handling a reply, which struct idr is perfect for.
>> 
>> Signed-off-by: Eric Anholt <eric@anholt.net>
>> ---
>>  .../vc04_services/bcm2835-camera/mmal-vchiq.c | 135 ++++--------------
>>  1 file changed, 31 insertions(+), 104 deletions(-)
>> 
>> diff --git a/drivers/staging/vc04_services/bcm2835-camera/mmal-vchiq.c b/drivers/staging/vc04_services/bcm2835-camera/mmal-vchiq.c
>> index 3a3b843fc122..f0dac6440cfb 100644
>> --- a/drivers/staging/vc04_services/bcm2835-camera/mmal-vchiq.c
>> +++ b/drivers/staging/vc04_services/bcm2835-camera/mmal-vchiq.c
>> @@ -21,7 +21,6 @@
>>  #include <linux/slab.h>
>>  #include <linux/completion.h>
>>  #include <linux/vmalloc.h>
>> -#include <linux/btree.h>
>>  #include <asm/cacheflush.h>
>>  #include <media/videobuf2-vmalloc.h>
>>  
>> @@ -111,7 +110,11 @@ struct vchiq_mmal_instance;
>>  /* normal message context */
>>  struct mmal_msg_context {
>>  	struct vchiq_mmal_instance *instance;
>> -	u32 handle;
>> +
>> +	/* Index in the context_map idr so that we can find the
>> +	 * mmal_msg_context again when servicing the VCHI reply.
>> +	 */
>> +	int handle;
>>  
>>  	union {
>>  		struct {
>> @@ -149,13 +152,6 @@ struct mmal_msg_context {
>>  
>>  };
>>  
>> -struct vchiq_mmal_context_map {
>> -	/* ensure serialized access to the btree(contention should be low) */
>> -	struct mutex lock;
>> -	struct btree_head32 btree_head;
>> -	u32 last_handle;
>> -};
>> -
>>  struct vchiq_mmal_instance {
>>  	VCHI_SERVICE_HANDLE_T handle;
>>  
>> @@ -165,92 +161,19 @@ struct vchiq_mmal_instance {
>>  	/* vmalloc page to receive scratch bulk xfers into */
>>  	void *bulk_scratch;
>>  
>> -	/* mapping table between context handles and mmal_msg_contexts */
>> -	struct vchiq_mmal_context_map context_map;
>> +	struct idr context_map;
>> +	spinlock_t context_map_lock;
>>  
>>  	/* component to use next */
>>  	int component_idx;
>>  	struct vchiq_mmal_component component[VCHIQ_MMAL_MAX_COMPONENTS];
>>  };
>>  
>> -static int __must_check
>> -mmal_context_map_init(struct vchiq_mmal_context_map *context_map)
>> -{
>> -	mutex_init(&context_map->lock);
>> -	context_map->last_handle = 0;
>> -	return btree_init32(&context_map->btree_head);
>> -}
>> -
>> -static void mmal_context_map_destroy(struct vchiq_mmal_context_map *context_map)
>> -{
>> -	mutex_lock(&context_map->lock);
>> -	btree_destroy32(&context_map->btree_head);
>> -	mutex_unlock(&context_map->lock);
>> -}
>> -
>> -static u32
>> -mmal_context_map_create_handle(struct vchiq_mmal_context_map *context_map,
>> -			       struct mmal_msg_context *msg_context,
>> -			       gfp_t gfp)
>> -{
>> -	u32 handle;
>> -
>> -	mutex_lock(&context_map->lock);
>> -
>> -	while (1) {
>> -		/* just use a simple count for handles, but do not use 0 */
>> -		context_map->last_handle++;
>> -		if (!context_map->last_handle)
>> -			context_map->last_handle++;
>> -
>> -		handle = context_map->last_handle;
>> -
>> -		/* check if the handle is already in use */
>> -		if (!btree_lookup32(&context_map->btree_head, handle))
>> -			break;
>> -	}
>> -
>> -	if (btree_insert32(&context_map->btree_head, handle,
>> -			   msg_context, gfp)) {
>> -		/* probably out of memory */
>> -		mutex_unlock(&context_map->lock);
>> -		return 0;
>> -	}
>> -
>> -	mutex_unlock(&context_map->lock);
>> -	return handle;
>> -}
>> -
>> -static struct mmal_msg_context *
>> -mmal_context_map_lookup_handle(struct vchiq_mmal_context_map *context_map,
>> -			       u32 handle)
>> -{
>> -	struct mmal_msg_context *msg_context;
>> -
>> -	if (!handle)
>> -		return NULL;
>> -
>> -	mutex_lock(&context_map->lock);
>> -
>> -	msg_context = btree_lookup32(&context_map->btree_head, handle);
>> -
>> -	mutex_unlock(&context_map->lock);
>> -	return msg_context;
>> -}
>> -
>> -static void
>> -mmal_context_map_destroy_handle(struct vchiq_mmal_context_map *context_map,
>> -				u32 handle)
>> -{
>> -	mutex_lock(&context_map->lock);
>> -	btree_remove32(&context_map->btree_head, handle);
>> -	mutex_unlock(&context_map->lock);
>> -}
>> -
>>  static struct mmal_msg_context *
>>  get_msg_context(struct vchiq_mmal_instance *instance)
>>  {
>>  	struct mmal_msg_context *msg_context;
>> +	int handle;
>>  
>>  	/* todo: should this be allocated from a pool to avoid kzalloc */
>>  	msg_context = kzalloc(sizeof(*msg_context), GFP_KERNEL);
>> @@ -258,32 +181,40 @@ get_msg_context(struct vchiq_mmal_instance *instance)
>>  	if (!msg_context)
>>  		return ERR_PTR(-ENOMEM);
>>  
>> -	msg_context->instance = instance;
>> -	msg_context->handle =
>> -		mmal_context_map_create_handle(&instance->context_map,
>> -					       msg_context,
>> -					       GFP_KERNEL);
>> +	/* Create an ID that will be passed along with our message so
>> +	 * that when we service the VCHI reply, we can look up what
>> +	 * message is being replied to.
>> +	 */
>> +	spin_lock(&instance->context_map_lock);
>> +	handle = idr_alloc(&instance->context_map, msg_context,
>> +			   0, 0, GFP_KERNEL);
>> +	spin_unlock(&instance->context_map_lock);
>>  
>> -	if (!msg_context->handle) {
>> +	if (msg_context->handle < 0) {
>
> handle < 0 ?

You're right, thanks!

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

[-- Attachment #2: Type: text/plain, Size: 169 bytes --]

_______________________________________________
devel mailing list
devel@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

  reply	other threads:[~2018-05-11  0:41 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-05-10 23:31 Eric Anholt
2018-05-10 23:40 ` Stefan Wahren
2018-05-11  0:41   ` Eric Anholt [this message]
2018-05-15 12:04 ` Dan Carpenter
2018-05-15 13:46   ` Eric Anholt

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=87efij3ty2.fsf@anholt.net \
    --to=eric@anholt.net \
    --cc=devel@driverdev.osuosl.org \
    --cc=gregkh@linuxfoundation.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-rpi-kernel@lists.infradead.org \
    --cc=stefan.wahren@i2se.com \
    --subject='Re: [PATCH] staging: bcm2835-camera: Replace open-coded idr with a struct idr.' \
    /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

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).