linux-kernel - Re: [PATCH v2 5/6] arm64: dts: qcom: apq8016-sbc-d3-camera-mezzanine: Move default ov5640 to a standalone dts

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] [day] [month] [year] [list]

Date:   Thu, 10 Aug 2023 17:43:39 +0200
From:   Stephan Gerhold <stephan@...hold.net>
To:     Bryan O'Donoghue <bryan.odonoghue@...aro.org>
Cc:     agross@...nel.org, andersson@...nel.org, konrad.dybcio@...aro.org,
        robh+dt@...nel.org, krzysztof.kozlowski+dt@...aro.org,
        conor+dt@...nel.org, loic.poulain@...aro.org, rfoss@...nel.org,
        linux-arm-msm@...r.kernel.org, devicetree@...r.kernel.org,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH v2 5/6] arm64: dts: qcom:
 apq8016-sbc-d3-camera-mezzanine: Move default ov5640 to a standalone dts

On Thu, Aug 10, 2023 at 04:26:34PM +0100, Bryan O'Donoghue wrote:
> On 10/08/2023 16:11, Stephan Gerhold wrote:
> > Hi,
> > 
> > just some nitpicks. Some of them were present before already but maybe
> > you can prepend or append another cleanup patch while at it. :)
> > 
> > On Wed, Aug 09, 2023 at 09:23:42PM +0100, Bryan O'Donoghue wrote:
> > > At the moment we define a single ov5640 sensor in the apq8016-sbc and
> > > disable that sensor.
> > > 
> > > The sensor mezzanine for this is a D3 Engineering Dual ov5640 mezzanine
> > > card. Move the definition from the apq8016-sbc where it shouldn't be to a
> > > standalone dts.
> > > 
> > 
> > I wonder what would be required to implement this using a DT overlay,
> > rather than a standalone separate DT? Seems like there are some .dtso
> > files in upstream Linux.
> > 
> > I'm also fine with the separate DTB personally, though.
> 
> So, we've discussed that previously and its a good model, which I like and
> which works well for RPI as an example.
> 
> AFAIK though the runtime dtbo overlay is still missing at least one upstream
> commit and the state of dtbo in qcom bootloaders is variable, probably good
> in LK, good in u-boot and then I'd say nothing doing.
> 

AFAIU there is work going on (at Linaro?) to move the qcom RBs to use
U-Boot, so I guess that would be the easiest common base to work with.
There is an U-Boot port for DB410c as well.

> I'm hoping to transition the mezzanine dtb files to something "generic" for
> boards that support 96 boards interfaces.
> 
> Its a bit out of scope for this series as, all I really want to do here is
> fixup obvious errors as I find them in camss and its dtbs.
> 

Right, yeah I think it's fine to have the separate DTB for now. I was
always confused about the disabled camera parts in apq8016-sbc, having
it in a separate DTB is definitely less confusing. :)

> So anyway the idea would be to define labels in the core board dts files for
> stuff like "powerdown-gpios = <&tlmm 34 GPIO_ACTIVE_HIGH>;" I'm not sure
> that's really feasible until its tried though.

Handling the GPIOs sounds complicated... I think it would be also okay
to have board-specific mezzanine overlays as a first step though. (i.e.
one for DB410c, others for other compatible 96boards).

> 
> Basically any mezzanine board would ideally only be defined once, with
> 96boards supporting baseboards providing the necessary additional detail on
> pins and regulators for the mezzanine to consume..
> 
> Come to think of it though you'd have to #include "myboard.dts" so maybe,
> probably, that idea not feasible.
> 
> dtbo would be better still but like I say I'm not presupposing a decent
> bootloader that can apply the overlay.
> 
> I/we will look again at dtbo since its just a neater model really.
> 

Thanks, I'm looking forward to seeing what you come up with. :D
Stephan