linux-kernel - Re: [PATCH 08/14] media: sunxi: Add support for the A31 MIPI CSI-2 controller

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <f74e4d59-a391-36ab-74aa-8e02aca1b0bc@collabora.com>
Date:   Wed, 4 Nov 2020 13:38:08 -0300
From:   Helen Koike <helen.koike@...labora.com>
To:     Paul Kocialkowski <paul.kocialkowski@...tlin.com>,
        Maxime Ripard <maxime@...no.tech>
Cc:     linux-media@...r.kernel.org, devicetree@...r.kernel.org,
        linux-arm-kernel@...ts.infradead.org, linux-kernel@...r.kernel.org,
        devel@...verdev.osuosl.org, linux-sunxi@...glegroups.com,
        Mauro Carvalho Chehab <mchehab@...nel.org>,
        Rob Herring <robh+dt@...nel.org>, Chen-Yu Tsai <wens@...e.org>,
        Yong Deng <yong.deng@...ewell.com>,
        Kishon Vijay Abraham I <kishon@...com>,
        Vinod Koul <vkoul@...nel.org>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        Philipp Zabel <p.zabel@...gutronix.de>,
        Hans Verkuil <hans.verkuil@...co.com>,
        Sakari Ailus <sakari.ailus@...ux.intel.com>,
        Thomas Petazzoni <thomas.petazzoni@...tlin.com>,
        Hans Verkuil <hverkuil@...all.nl>, kevin.lhopital@...mail.com
Subject: Re: [PATCH 08/14] media: sunxi: Add support for the A31 MIPI CSI-2
 controller



On 11/4/20 8:17 AM, Paul Kocialkowski wrote:
> Hi,
> 
> On Mon 02 Nov 20, 10:21, Maxime Ripard wrote:
>> On Fri, Oct 30, 2020 at 07:45:18PM -0300, Helen Koike wrote:
>>> On 10/23/20 2:45 PM, Paul Kocialkowski wrote:
>>>> The A31 MIPI CSI-2 controller is a dedicated MIPI CSI-2 controller
>>>> found on Allwinner SoCs such as the A31 and V3/V3s.
>>>>
>>>> It is a standalone block, connected to the CSI controller on one side
>>>> and to the MIPI D-PHY block on the other. It has a dedicated address
>>>> space, interrupt line and clock.
>>>>
>>>> Currently, the MIPI CSI-2 controller is hard-tied to a specific CSI
>>>> controller (CSI0) but newer SoCs (such as the V5) may allow switching
>>>> MIPI CSI-2 controllers between CSI controllers.
>>>>
>>>> It is represented as a V4L2 subdev to the CSI controller and takes a
>>>> MIPI CSI-2 sensor as its own subdev, all using the fwnode graph and
>>>> media controller API.
>>>
>>> Maybe this is a bad idea, but I was thinking:
>>> This driver basically just turn on/off and catch some interrupts for errors,
>>> and all the rest of v4l2 config you just forward to the next subdevice
>>> on the pipeline.
>>>
>>> So instead of exposing it as a subdevice, I was wondering if modeling
>>> this driver also through the phy subsystem wouldn't be cleaner, so
>>> you won't need all the v4l2 subdevice/topology boilerplate code that
>>> it seems you are not using (unless you have plans to add controls or
>>> some specific configuration on this node later).
>>>
>>> But this would require changes on the sun6i-csi driver.
>>>
>>> What do you think?
>>
>> Eventually we'll need to filter the virtual channels / datatypes I
>> guess, so it's definitely valuable to have it in v4l2

Which kind of datatypes? I ask to know if this shouldn't be configured
through the video node instead of subdevice.

Regarding channels, we had a discussion to implement it through the video
node (and not subdevice) [1]. But we discussed about blitters and multi-scalers,
so now I'm wondering if we could use the same API for mipi-csi virtual channels
in the video entity device, or if it doesn't apply and we need another API
for that in a subdevice instead.

[1] https://patchwork.linuxtv.org/project/linux-media/cover/20200717115435.2632623-1-helen.koike@collabora.com/

> 
> Agreed and like I mentionned in the discussion on 00/14 I don't think it
> would be a cleaner way to expose things.
> 
> There's also the fact that newer SoCs like the V5 seem to allow connecting
> any MIPI CSI-2 controller to any CSI controller, so the graph representation
> is definitely welcome here.

I'm not sure this is an advantage in userspace pov, because it means we'll
have different topologies for basically the same end result to userspace.

But as I mentioned, I don't mind keeping it in the media topology.
Helen

> 
> Paul
>