Re: [PATCH v4 15/15] ipu3-cio2: Add cio2-bridge to ipu3-cio2 driver

[Kieran Bingham]

Hi Dan,

On 04/01/2021 13:55, Daniel Scally wrote:
> 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?

I might put the whole vendor name in, and no need to prefix 'Sensor' IMO.

+	/* Omnivision OV5693 */
+	CIO2_SENSOR_CONFIG("INT33BE", 0),
+	/* Omnivision OV2680 */
+	CIO2_SENSOR_CONFIG("OVTI2680", 0),

but otherwise, yes a comment the line before works for me, as you are
right - at the end would not be practical.


>>> +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

So is this needed? Or is it some future compatibility thing?

I haven't seen where it's used yet, but I'm not too worried about it
though, just not sure what value an array of [1, 2, 3, 4] gives if it's
constant...


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

--
Kieran




-- 
Regards
--
Kieran