Messages in this thread | | | Subject | Re: [PATCH v4 15/15] ipu3-cio2: Add cio2-bridge to ipu3-cio2 driver | From | Kieran Bingham <> | Date | Mon, 4 Jan 2021 15:13:48 +0000 |
| |
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@ideasonboard.com> > Thanks very much!
-- Kieran
-- Regards -- Kieran
| |