linux-kernel - Re: [RFC PATCH v10 6/9] media: tegra: Add Tegra210 Video input driver

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]

Date:   Sat, 25 Apr 2020 19:19:13 -0700
From:   Sowjanya Komatineni <skomatineni@...dia.com>
To:     Dmitry Osipenko <digetx@...il.com>,
        Hans Verkuil <hverkuil@...all.nl>, <thierry.reding@...il.com>,
        <jonathanh@...dia.com>, <frankc@...dia.com>, <sakari.ailus@....fi>,
        <helen.koike@...labora.com>
CC:     <sboyd@...nel.org>, <linux-media@...r.kernel.org>,
        <devicetree@...r.kernel.org>, <linux-clk@...r.kernel.org>,
        <linux-tegra@...r.kernel.org>, <linux-kernel@...r.kernel.org>
Subject: Re: [RFC PATCH v10 6/9] media: tegra: Add Tegra210 Video input driver


On 4/25/20 7:10 PM, Dmitry Osipenko wrote:
> External email: Use caution opening links or attachments
>
>
> 26.04.2020 04:43, Sowjanya Komatineni пишет:
> ...
>>> It looks to me that at least all those hardcoded HW format IDs do not
>>> match the older SoCs.
>> TPG hard coded formats are supported on prior Tegra.
>>
>> Other supported formats are SoC dependent and  part of soc data in the
>> driver already.
> But I don't see where that SoC-dependent definition is made in
> terga210.c. That tegra_image_format enum looks T210-specific, isn't it?
>
> ...

Video formats which are SoC variants are made soc specific in driver 
already tegra_vi_soc structure member video_formats

tegra_image_format enum is same for T210 and T186

For T194, enums will be diff and will have diff TEGRA194_VIDEO_FORMAT 
using corresponding Tegra194 video format enums

>>> The driver will need to have a bit better separation if it's supposed to
>>> have a common core for all SoCs. Each incompatible VI/CSI hardware
>>> version should have its own kernel module.
>> currently other Tegra host1x driver (drm) also does similar. Single
>> module for all Tegra SoCs.
> DRM driver has a proper separation of the sub-drivers where sub-driver
> won't load on unsupported hardware. The tegra-video driver should do the
> same, i.e. VI and CSI should be individual drivers (and not OPS). There
> could be a some common core, but for now it's not obvious to me what
> that core should be, maybe just the video.c.
>
>> With current tegra-video, all the v4l2 related common part of
>> implementation is same for all tegra's and only
>> tegra210.c/tegra186.c/tegra194.c will have corresponding tegra soc
>> specific vi/csi programming sequence.
> This code shouldn't be shared within the same driver module, IMO.
>
>
>>> The tegra-video should be okay, although the "video" part sounds a bit
>>> too broad since video could mean a lot of things. I think downstream
>>> kernel uses (or at least used) the tegra-camera name for the driver,
>>> perhaps it could be a reasonable variant as well.
>> prior feedback suggests not to use camera variant instead to use video
> Alright, then the tegra-video should be fine.