Hi Dan,
On 04/01/2021 22:02, Daniel Scally wrote:
>>>>> 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.
>>
>>
>> Aha, I see, ok - so we are populating an array of [1, 2, 3, 4] for each
>> sensor that we add.
>>
>> What about creating the data_lanes once as a const static array and
>> mapping to that?
>>
>> /*
>> * Map the lane arrangement, which is fixed for the IPU3.
>> */
>> static const int data_lanes[CIO2_MAX_LANES] = { 1, 2, 3, 4 };
>
>
> Can't do exactly this; the bridge needs to store everything on heap
> incase the module is unloaded, but I could move the data_lanes array to
> the struct cio2_bridge instead of against each sensor and then we're
> only doing it once.
Ahh, yes I remember reading about that already.
It maybe worth adding a comment about that in this file, to prevent
other people from 'optimising' things out in 5 years ...
It probably doesn't make much difference in that case if it's per sensor
or per bridge. But indeed at least in the bridge it's only created once.
--
Kieran
>
>> ...
>>
>> sensor->cio2_properties[0] = PROPERTY_ENTRY_U32_ARRAY_LEN(
>> sensor->prop_names.data_lanes,
>> data_lanes,
>> sensor->ssdb.lanes);
>> ...
>>
>> Then we don't need the loop to populate the array for each sensor
>> anymore, or the data_lanes in the sensor struct?
>>
>
--
Regards
--
Kieran
