Hi Kieran
On 04/01/2021 15:13, Kieran Bingham wrote:
> 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.
Works for me
>>>> +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...
The endpoints need to have the data-lanes property which passes an array
of data lanes, but there may well be a better way of doing this. I'm
just using the lanes member of the ssdb data structure to tell the
property how many members of the array to look at:
+ sensor->cio2_properties[0] = PROPERTY_ENTRY_U32_ARRAY_LEN(
+ sensor->prop_names.data_lanes,
+ sensor->data_lanes,
+ sensor->ssdb.lanes);
So if sensor->ssdb.lanes is 2, even though it's passed a pointer to the
first member of an array of 4 members, the size calculation of that
macro limits it to just those in use. I.E. if sensor->ssdb.lanes is 2
then the property will be given the size 2 * sizeof(u32), and so when
its parsed only [1, 2] will be read.
