All of lore.kernel.org
 help / color / mirror / Atom feed
From: Shuah Khan <skhan@linuxfoundation.org>
To: Helen Koike <helen.koike@collabora.com>,
	mchehab@kernel.org, hverkuil@xs4all.nl,
	laurent.pinchart@ideasonboard.com, andrealmeid@collabora.com
Cc: linux-kernel@vger.kernel.org, linux-media@vger.kernel.org,
	Shuah Khan <skhan@linuxfoundation.org>
Subject: Re: [PATCH v2 0/2] Collapse vimc into single monolithic driver
Date: Mon, 19 Aug 2019 12:00:22 -0600	[thread overview]
Message-ID: <fb822995-747c-b2a1-e1d3-7d62512a4700@linuxfoundation.org> (raw)
In-Reply-To: <ce727478-1aa5-c6c0-9aee-911b6ac1efb1@collabora.com>

On 8/16/19 2:03 PM, Helen Koike wrote:
> Hi Shuah,
> 
> Thanks for the patches.
> 
> On 8/15/19 4:42 PM, Shuah Khan wrote:
>> vimc uses Component API to split the driver into functional components.
>> The real hardware resembles a monolith structure than component and
>> component structure added a level of complexity making it hard to
>> maintain without adding any real benefit.
>>
>> The sensor is one vimc component that would makes sense to be a separate
>> module to closely align with the real hardware. It would be easier to
>> collapse vimc into single monolithic driver first and then split the
>> sensor off as a separate module.
>>
>> This patch series removes the component API and makes minimal changes to
>> the code base preserving the functional division of the code structure.
>> Preserving the functional structure allows us to split the sensor off
>> as a separate module in the future.
>>
>> Major design elements in this change are:
>>      - Use existing struct vimc_ent_config and struct vimc_pipeline_config
>>        to drive the initialization of the functional components.
>>      - Make vimc_device and vimc_ent_config global by moving them to
>>        vimc-common.h
>>      - Add two new hooks add and rm to initialize and register, unregister
>>        and free subdevs.
>>      - All component API is now gone and bind and unbind hooks are modified
>>        to do "add" and "rm" with minimal changes to just add and rm subdevs.
>>      - vimc-core's bind and unbind are now register and unregister.
>>      - vimc-core invokes "add" hooks from its vimc_register_devices().
>>        The "add" hooks remain the same and register subdevs. They don't
>>        create platform devices of their own and use vimc's pdev.dev as
>>        their reference device. The "add" hooks save their vimc_ent_device(s)
>>        in the corresponding vimc_ent_config.
>>      - vimc-core invokes "rm" hooks from its unregister to unregister
>>        subdevs and cleanup.
>>      - vimc-core invokes "add" and "rm" hooks with pointer to struct
>>        vimc_device and the corresponding struct vimc_ent_config pointer.
>>
>> The following configure and stream test works on all devices.
>>
>>      media-ctl -d platform:vimc -V '"Sensor A":0[fmt:SBGGR8_1X8/640x480]'
>>      media-ctl -d platform:vimc -V '"Debayer A":0[fmt:SBGGR8_1X8/640x480]'
>>      media-ctl -d platform:vimc -V '"Sensor B":0[fmt:SBGGR8_1X8/640x480]'
>>      media-ctl -d platform:vimc -V '"Debayer B":0[fmt:SBGGR8_1X8/640x480]'
>>
>>      v4l2-ctl -z platform:vimc -d "RGB/YUV Capture" -v width=1920,height=1440
>>      v4l2-ctl -z platform:vimc -d "Raw Capture 0" -v pixelformat=BA81
>>      v4l2-ctl -z platform:vimc -d "Raw Capture 1" -v pixelformat=BA81
>>
>>      v4l2-ctl --stream-mmap --stream-count=100 -d /dev/video1
>>      v4l2-ctl --stream-mmap --stream-count=100 -d /dev/video2
>>      v4l2-ctl --stream-mmap --stream-count=100 -d /dev/video3
>>
>> The second patch in the series fixes a general protection fault found
>> when rmmod is done while stream is active.
>>
>> - rmmod while streaming returns vimc is in use
>> - rmmod without active stream works correctly
>>
>> Changes since v1:
>> Patch 1 & 2: (patch 1 in this series)
>> - Collapsed the two patches into one
>> - Added common defines (vimc_device and vimc_ent_config) to vimc-common.h
>>    based on our discussion.
>> - Addressed review comments from Helen and Laurent
>> - Use vimc-common.h instead of creating a new file.
>> - Other minor comments from Helen on int vs. unsigned int and
>>    not needing to initialize ret in vimc_add_subdevs()
>> Patch 3 (patch 2 in this series):
>> - The second patch is the fix for gpf. Updated the patch after looking
>>    at the test results from Andre and Helen. This problem is in a common
>>    code and impacts all subdevs. The fix addresses the core problem and
>>    fixes it. Fix removes pads release from v4l2_device_unregister_subdev()
>>    and pads are now released from the sd release handler with all other
>>    resources.
>>
>> Outstanding:
>> - Update documentation with the correct topology.
>> - There is one outstanding gpf remaining in the unbind path. I will
>>    fix that in a separate patch. This is an existing problem and will
>>    be easier to fix on top of this patch series.
>>
>> vimc_print_dot (--print-dot) topology after this change: (no change
>> compared to media master)
>> digraph board {
>>          rankdir=TB
>>          n00000001 [label="{{} | Sensor A\n/dev/v4l-subdev0 | {<port0> 0}}", shape=Mrecord, style=filled, fillcolor=green]
>>          n00000001:port0 -> n00000005:port0 [style=bold]
>>          n00000001:port0 -> n0000000b [style=bold]
>>          n00000003 [label="{{} | Sensor B\n/dev/v4l-subdev1 | {<port0> 0}}", shape=Mrecord, style=filled, fillcolor=green]
>>          n00000003:port0 -> n00000008:port0 [style=bold]
>>          n00000003:port0 -> n0000000f [style=bold]
>>          n00000005 [label="{{<port0> 0} | Debayer A\n/dev/v4l-subdev2 | {<port1> 1}}", shape=Mrecord, style=filled, fillcolor=green]
>>          n00000005:port1 -> n00000015:port0
>>          n00000008 [label="{{<port0> 0} | Debayer B\n/dev/v4l-subdev3 | {<port1> 1}}", shape=Mrecord, style=filled, fillcolor=green]
>>          n00000008:port1 -> n00000015:port0 [style=dashed]
>>          n0000000b [label="Raw Capture 0\n/dev/video1", shape=box, style=filled, fillcolor=yellow]
>>          n0000000f [label="Raw Capture 1\n/dev/video2", shape=box, style=filled, fillcolor=yellow]
>>          n00000013 [label="{{} | RGB/YUV Input\n/dev/v4l-subdev4 | {<port0> 0}}", shape=Mrecord, style=filled, fillcolor=green]
>>          n00000013:port0 -> n00000015:port0 [style=dashed]
>>          n00000015 [label="{{<port0> 0} | Scaler\n/dev/v4l-subdev5 | {<port1> 1}}", shape=Mrecord, style=filled, fillcolor=green]
>>          n00000015:port1 -> n00000018 [style=bold]
>>          n00000018 [label="RGB/YUV Capture\n/dev/video3", shape=box, style=filled, fillcolor=yellow]
>>
>> Shuah Khan (2):
>>    media: vimc: Collapse component structure into a single monolithic
>>      driver
>>    media: vimc: Fix gpf in rmmod path when stream is active
> 
> I couldn't apply those on top of media/master, I think they are
> conflicting with the two "Reverts" commits in vimc.
> 

Sorry for the delay. I was out backpacking for a couple of days.

I knew I have to rebase after the reverts go in. I will do that
and address your comments on patch 1/2 and resend the series.

Thanks for the review. Your comments on naming make sense.

thanks,
-- Shuah



      reply	other threads:[~2019-08-19 18:00 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-08-15 19:42 [PATCH v2 0/2] Collapse vimc into single monolithic driver Shuah Khan
2019-08-15 19:42 ` [PATCH v2 1/2] media: vimc: Collapse component structure into a " Shuah Khan
2019-08-16 20:35   ` Helen Koike
2019-08-15 19:42 ` [PATCH v2 2/2] media: vimc: Fix gpf in rmmod path when stream is active Shuah Khan
2019-08-16 20:03 ` [PATCH v2 0/2] Collapse vimc into single monolithic driver Helen Koike
2019-08-19 18:00   ` Shuah Khan [this message]

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=fb822995-747c-b2a1-e1d3-7d62512a4700@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
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.