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:   Mon, 3 Jul 2023 01:28:03 +0300
From:   Laurent Pinchart <laurent.pinchart@ideasonboard.com>
To:     Sakari Ailus <sakari.ailus@iki.fi>
Cc:     Jean-Michel Hautbois <jeanmichel.hautbois@ideasonboard.com>,
        dave.stevenson@raspberrypi.com, devicetree@vger.kernel.org,
        kernel-list@raspberrypi.com, linux-arm-kernel@lists.infradead.org,
        linux-kernel@vger.kernel.org, linux-media@vger.kernel.org,
        linux-rpi-kernel@lists.infradead.org, lukasz@jany.st,
        mchehab@kernel.org, naush@raspberrypi.com, robh@kernel.org,
        tomi.valkeinen@ideasonboard.com,
        bcm-kernel-feedback-list@broadcom.com, stefan.wahren@i2se.com
Subject: Re: [PATCH v5 04/11] media: bcm2835-unicam: Add support for
 CCP2/CSI2 camera interface
Message-ID: <20230702222803.GF9285@pendragon.ideasonboard.com>
References: <20220208155027.891055-1-jeanmichel.hautbois@ideasonboard.com>
 <20220208155027.891055-5-jeanmichel.hautbois@ideasonboard.com>
 <YhihbncnSlmvrn/D@valkosipuli.retiisi.eu>
 <20230702152356.GA16995@pendragon.ideasonboard.com>
 <ZKG/bej80eL13Qqp@valkosipuli.retiisi.eu>
 <20230702214505.GB16995@pendragon.ideasonboard.com>
 <20230702214711.GC16995@pendragon.ideasonboard.com>
 <ZKHye/4kARSHqsIJ@valkosipuli.retiisi.eu>
 <20230702220138.GE9285@pendragon.ideasonboard.com>
 <ZKH4LXKHX8G1WK7a@valkosipuli.retiisi.eu>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
In-Reply-To: <ZKH4LXKHX8G1WK7a@valkosipuli.retiisi.eu>
Precedence: bulk

On Sun, Jul 02, 2023 at 10:20:29PM +0000, Sakari Ailus wrote:
> On Mon, Jul 03, 2023 at 01:01:38AM +0300, Laurent Pinchart wrote:
> > > > > > > > If the hardware doesn't support lane remapping for CCP2, then that should
> > > > > > > > be reflected in DT bindings, i.e. data-lanes isn't relevant. There's no
> > > > > > > > need to check that here.
> > > > > > > 
> > > > > > > Should the above check for CSI-2 be dropped as well then ?
> > > > > > 
> > > > > > Same for CSI-2, too: if there's nothing to configure there (lane remapping)
> > > > > > there's no need to validate that part of the DT either.
> > > > > 
> > > > > OK, I'll drop that.
> > > > 
> > > > Actually, I'm wondering if it would make sense to tell the parsing
> > > > functions whether lane reordering is supported or not. The checks could
> > > > then be moved to the framework. What do you think ?
> > > 
> > > I'm not sure how useful this check would be in the first place: if you have
> > > hardware that can reorder the lanes, the framework doesn't know what to
> > > check there (if anything) and otherwise there's little point in the
> > > entire check.
> > 
> > Isn't it good to tell users that something is wrong instead of accepting
> > the invalid configuration and let them wonder why the device isn't
> > working ? Users in this case would be system integrators, not end
> > users, but we have lots of debugging information in the kernel aimed for
> > them already.
> 
> In which of the two cases above the framework could do something useful
> there? For devices where you can reorder the lanes or for those where you
> can't?

For devices where you can't, to detect DT that reorders lanes.

-- 
Regards,

Laurent Pinchart