Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Date:   Thu, 10 Aug 2023 17:43:39 +0200
From:   Stephan Gerhold <stephan@gerhold.net>
To:     Bryan O'Donoghue <bryan.odonoghue@linaro.org>
Cc:     agross@kernel.org, andersson@kernel.org, konrad.dybcio@linaro.org,
        robh+dt@kernel.org, krzysztof.kozlowski+dt@linaro.org,
        conor+dt@kernel.org, loic.poulain@linaro.org, rfoss@kernel.org,
        linux-arm-msm@vger.kernel.org, devicetree@vger.kernel.org,
        linux-kernel@vger.kernel.org
Subject: Re: [PATCH v2 5/6] arm64: dts: qcom:
 apq8016-sbc-d3-camera-mezzanine: Move default ov5640 to a standalone dts
Message-ID: <ZNUFq8CY5U0ei_Cj@gerhold.net>
References: <20230809202343.1098425-1-bryan.odonoghue@linaro.org>
 <20230809202343.1098425-6-bryan.odonoghue@linaro.org>
 <ZNT9nLaSBZvm1HNe@gerhold.net>
 <d839ef44-3427-88b8-513e-a84b24cc6929@linaro.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <d839ef44-3427-88b8-513e-a84b24cc6929@linaro.org>
Content-Transfer-Encoding: 7bit
Precedence: bulk

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