[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <9026519f-1f33-9df0-de18-0881069f7aaa@gmail.com>
Date: Mon, 4 Jan 2021 13:55:57 +0000
From: Daniel Scally <djrscally@...il.com>
To: kieran.bingham+renesas@...asonboard.com,
linux-kernel@...r.kernel.org, linux-acpi@...r.kernel.org,
linux-media@...r.kernel.org, devel@...ica.org,
gregkh@...uxfoundation.org, rjw@...ysocki.net,
sergey.senozhatsky@...il.com, mchehab@...nel.org
Cc: lenb@...nel.org, yong.zhi@...el.com, sakari.ailus@...ux.intel.com,
bingbu.cao@...el.com, tian.shu.qiu@...el.com,
robert.moore@...el.com, erik.kaneda@...el.com, pmladek@...e.com,
rostedt@...dmis.org, andriy.shevchenko@...ux.intel.com,
linux@...musvillemoes.dk,
laurent.pinchart+renesas@...asonboard.com,
jacopo+renesas@...ndi.org, hverkuil-cisco@...all.nl,
m.felsch@...gutronix.de, niklas.soderlund+renesas@...natech.se,
slongerbeam@...il.com, heikki.krogerus@...ux.intel.com,
linus.walleij@...aro.org,
Jordan Hand <jorhand@...ux.microsoft.com>,
Laurent Pinchart <laurent.pinchart@...asonboard.com>,
Andy Shevchenko <andy.shevchenko@...il.com>
Subject: Re: [PATCH v4 15/15] ipu3-cio2: Add cio2-bridge to ipu3-cio2 driver
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@...asonboard.com>
Thanks very much!
Powered by blists - more mailing lists