Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
Subject: Re: [PATCH v4 15/15] ipu3-cio2: Add cio2-bridge to ipu3-cio2 driver
To:     kieran.bingham+renesas@ideasonboard.com,
        linux-kernel@vger.kernel.org, linux-acpi@vger.kernel.org,
        linux-media@vger.kernel.org, devel@acpica.org,
        gregkh@linuxfoundation.org, rjw@rjwysocki.net,
        sergey.senozhatsky@gmail.com, mchehab@kernel.org
Cc:     lenb@kernel.org, yong.zhi@intel.com, sakari.ailus@linux.intel.com,
        bingbu.cao@intel.com, tian.shu.qiu@intel.com,
        robert.moore@intel.com, erik.kaneda@intel.com, pmladek@suse.com,
        rostedt@goodmis.org, andriy.shevchenko@linux.intel.com,
        linux@rasmusvillemoes.dk,
        laurent.pinchart+renesas@ideasonboard.com,
        jacopo+renesas@jmondi.org, hverkuil-cisco@xs4all.nl,
        m.felsch@pengutronix.de, niklas.soderlund+renesas@ragnatech.se,
        slongerbeam@gmail.com, heikki.krogerus@linux.intel.com,
        linus.walleij@linaro.org,
        Jordan Hand <jorhand@linux.microsoft.com>,
        Laurent Pinchart <laurent.pinchart@ideasonboard.com>,
        Andy Shevchenko <andy.shevchenko@gmail.com>
References: <20210103231235.792999-1-djrscally@gmail.com>
 <20210103231235.792999-16-djrscally@gmail.com>
 <3d881e2b-747f-dcd7-a0cf-e7309419914b@ideasonboard.com>
From:   Daniel Scally <djrscally@gmail.com>
Message-ID: <9026519f-1f33-9df0-de18-0881069f7aaa@gmail.com>
Date:   Mon, 4 Jan 2021 13:55:57 +0000
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101
 Thunderbird/68.10.0
MIME-Version: 1.0
In-Reply-To: <3d881e2b-747f-dcd7-a0cf-e7309419914b@ideasonboard.com>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
Content-Language: en-US
Precedence: bulk

Hi Kieran

On 04/01/2021 13:35, Kieran Bingham wrote:
>> +/*
>> + * Extend this array with ACPI Hardware IDs of devices known to be working
>> + * plus the number of link-frequencies expected by their drivers, along with
>> + * the frequency values in hertz. This is somewhat opportunistic way of adding
>> + * support for this for now in the hopes of a better source for the information
>> + * (possibly some encoded value in the SSDB buffer that we're unaware of)
>> + * becoming apparent in the future.
>> + *
>> + * Do not add an entry for a sensor that is not actually supported.
>> + */
>> +static const struct cio2_sensor_config cio2_supported_sensors[] = {
>> +	CIO2_SENSOR_CONFIG("INT33BE", 0),
>> +	CIO2_SENSOR_CONFIG("OVTI2680", 0),
> I don't know if these are expressed anywhere else but would it be
> helpful to add a comment, or indicator as to what the actual sensor is
> that is represented by this HID?
>
> I can make an assumption about what an OVTI2680 might be, but the
> INT33BE is quite opaque. It's not clear what support that adds.
>
> Unless no one cares what the sensor is that is, but I would anticipate
> anyone looking here to add a new sensor might want to investigate what
> was already in the table?

Yeah good point. I'll probably alternate comment and entry then, like:


+static const struct cio2_sensor_config cio2_supported_sensors[] = {
+	/* Sensor OVTI5693 */
+	CIO2_SENSOR_CONFIG("INT33BE", 0),
+	/* Sensor OVTI2680 */
+	CIO2_SENSOR_CONFIG("OVTI2680", 0),

As an inline comment won't fit for the sensors that we know link-frequencies for. That sound ok?

>> +static void cio2_bridge_create_fwnode_properties(
>> +	struct cio2_sensor *sensor,
>> +	const struct cio2_sensor_config *cfg)
>> +{
>> +	unsigned int i;
>> +
>> +	sensor->prop_names = prop_names;
>> +
>> +	for (i = 0; i < CIO2_MAX_LANES; i++)
>> +		sensor->data_lanes[i] = i + 1;
> Does something support lane swapping somewhere?
> I assume this is just mapping each lane directly through.

I think Sakari said remapping isn't supported in the CIO2 - so yeah this
is just mapping them directly

> Otherwise, I'm quite looking forwards to all of this ;-)
>
> Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
Thanks very much!