Linux-Media Archive on lore.kernel.org
 help / color / Atom feed
From: Shuah Khan <skhan@linuxfoundation.org>
To: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Cc: helen.koike@collabora.com,
	"André Almeida" <andrealmeid@collabora.com>,
	mchehab@kernel.org, hverkuil@xs4all.nl,
	linux-kernel@vger.kernel.org, linux-media@vger.kernel.org,
	"skh >> Shuah Khan" <skhan@linuxfoundation.org>
Subject: Re: [PATCH 1/3] media: vimc: move private defines to a common header
Date: Mon, 12 Aug 2019 08:27:32 -0600
Message-ID: <8e5206fe-240e-e5d3-c675-255aa0df7d57@linuxfoundation.org> (raw)
In-Reply-To: <20190812142447.GF5006@pendragon.ideasonboard.com>

On 8/12/19 8:24 AM, Laurent Pinchart wrote:
> Hi Shua,
> 
> On Mon, Aug 12, 2019 at 08:19:27AM -0600, Shuah Khan wrote:
>> On 8/10/19 8:14 AM, Laurent Pinchart wrote:
>>> On Fri, Aug 09, 2019 at 03:45:41PM -0600, Shuah Khan wrote:
>>>> In preparation for collapsing the component driver structure into
>>>> a monolith, move private device structure defines to a new common
>>>> header file.
>>>
>>> Apart from the vimc_device structure, this doesn't seem to be needed.
>>> I'd rather keep each structure private to the .c file that handles it,
>>> and only share vimc_device globally.
>>
>> Right. I initially thought that I needed these global. Once I completed
>> the patches without needing these as global, I overlooked updating the
>> patches.
>>
>> I will take care of that. Any thoughts on vimc.h vs. adding vimc_device
>> struct to existing vimc-common.h
>>
>> As I explained to Helen in response to her comment about:
>>
>> "My thinking is that vimc-common.h is common for all the subdevs and
>> putting vimc-core defines and structures it shares it with the subdev
>> files can be in a separate file.
>>
>> It is more of design choice to keep structures and defined organized.
>> Originally I was thinking all the subdev device structires need to be
>> global, and my patch set I sent out as such doesn't need that. I just
>> overlooked that when I sent the patches out.
>>
>> This reduces the number of things that need to be common, I don't really
>> have any strong reasons for either choice of adding common defines to
>> vimc-common.h vs vimc.h - maybe with a slight tilt towards vimc.h"
> 
> The vimc_device structure fits nicely in vimc-common.h in my opinion, as
> it's used by every component. I don't care much either way.
> 

Sounds good to me.

thanks,
-- Shuah

  reply index

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-08-09 21:45 [PATCH 0/3] Collapse vimc into single monolithic driver Shuah Khan
2019-08-09 21:45 ` [PATCH 1/3] media: vimc: move private defines to a common header Shuah Khan
2019-08-10  3:15   ` Helen Koike
2019-08-12 14:03     ` Shuah Khan
2019-08-10 14:14   ` Laurent Pinchart
2019-08-12 14:19     ` Shuah Khan
2019-08-12 14:24       ` Laurent Pinchart
2019-08-12 14:27         ` Shuah Khan [this message]
2019-08-09 21:45 ` [PATCH 2/3] media: vimc: Collapse component structure into a single monolithic driver Shuah Khan
2019-08-10  4:12   ` Helen Koike
2019-08-12 14:12     ` Shuah Khan
2019-08-09 21:45 ` [PATCH 3/3] media: vimc: Fix gpf in rmmod path when stream is active Shuah Khan
2019-08-09 23:52 ` [PATCH 0/3] Collapse vimc into single monolithic driver André Almeida
2019-08-10  0:17   ` Shuah Khan
2019-08-10  0:24     ` André Almeida
2019-08-10  0:48       ` Shuah Khan
2019-08-10  3:51       ` Helen Koike
2019-08-12 14:08         ` Shuah Khan
2019-08-12 18:52           ` André Almeida
2019-08-12 19:10             ` Shuah Khan
2019-08-12 22:14               ` Shuah Khan
2019-08-12 23:41                 ` Helen Koike
2019-08-13  0:58                   ` Shuah Khan
2019-08-13  9:56                   ` Laurent Pinchart
2019-08-13 12:25                     ` Helen Koike
2019-08-13 12:36                       ` Laurent Pinchart
2019-08-13 23:22                         ` Shuah Khan

Reply instructions:

You may reply publically 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=8e5206fe-240e-e5d3-c675-255aa0df7d57@linuxfoundation.org \
    --to=skhan@linuxfoundation.org \
    --cc=andrealmeid@collabora.com \
    --cc=helen.koike@collabora.com \
    --cc=hverkuil@xs4all.nl \
    --cc=laurent.pinchart@ideasonboard.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-media@vger.kernel.org \
    --cc=mchehab@kernel.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

Linux-Media Archive on lore.kernel.org

Archives are clonable:
	git clone --mirror https://lore.kernel.org/linux-media/0 linux-media/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 linux-media linux-media/ https://lore.kernel.org/linux-media \
		linux-media@vger.kernel.org linux-media@archiver.kernel.org
	public-inbox-index linux-media

Example config snippet for mirrors

Newsgroup available over NNTP:
	nntp://nntp.lore.kernel.org/org.kernel.vger.linux-media


AGPL code for this site: git clone https://public-inbox.org/ public-inbox