Re: [PATCH v4 16/16] ACPI / DSD: Document references, ports and endpoints

[Sakari Ailus <sakari.ailus-VuQAYsv1563Yd54FQh9/CA@public.gmane.org>]

Rafael J. Wysocki wrote:
> On Tue, Mar 14, 2017 at 10:16 PM, Sakari Ailus
> <sakari.ailus-VuQAYsv1563Yd54FQh9/CA@public.gmane.org> wrote:
>> Rafael J. Wysocki wrote:
>>>
>>> On Tue, Mar 14, 2017 at 6:54 PM, Sakari Ailus
>>> <sakari.ailus-VuQAYsv1563Yd54FQh9/CA@public.gmane.org> wrote:
>>>>
>>>> Hi Rafael,
>>>>
>>>> Rafael J. Wysocki wrote:
>>>>>
>>>>>
>>>>> On Tue, Mar 14, 2017 at 9:09 AM, Sakari Ailus
>>>>> <sakari.ailus-VuQAYsv1563Yd54FQh9/CA@public.gmane.org> wrote:
>>>>>>
>>>>>>
>>>>>> On 03/14/17 10:08, Sakari Ailus wrote:
>>>>>>>
>>>>>>>
>>>>>>> How about this instead:
>>>>>>>
>>>>>>> All port nodes are located under the device's "_DSD" node in the
>>>>>>> hierarchical data extension tree. The property extension related to
>>>>>>> each port node must contain the key "port" and an integer value which
>>>>>>> is the number of the port.
>>>>>>
>>>>>>
>>>>>>
>>>>>> So with matching strings instead of indices, this will change, too...
>>>>>
>>>>>
>>>>>
>>>>> It doesn't have to AFAICS, but the number is just redundant IMO.  You
>>>>> only need a boolean property saying "this is a port", so you know that
>>>>> you should expect a list of endpoints in that object.
>>>>
>>>>
>>>>
>>>> No, it's not redundant. It's the number of the physical port in the
>>>> device
>>>> --- this is how the driver gets to know where the connection has been
>>>> made.
>>>
>>>
>>> OK, but what exactly do you mean by "physical port"?
>>
>>
>> The device (or an IP block) has physical interfaces to the world outside.
>> There could be just one, but there may be more. For an ISP, there could be
>> e.g. four CSI-2 receivers to each of which you could connect a camera
>> sensor. So for an ISP device, that number tells which of the receivers a
>> given sensor is connected to.
>>
>> The mapping between this number and what the hardware datasheet refers to
>> needs to be documented per device.
>
> OK, so the number actually is an arbitrary piece of data associated
> with the key "port" and the interpretation of that piece of data
> depends on whoever asks for that value.
>
> IOW, the core doesn't care.
>
> With all due respect to whoever invented this on the DT side, this is
> just bad design to me, because it causes the "port" property to serve
> two different purposes at the same time.  First, it tells the core
> that this object is a port.  Second, it is expected to provide a piece
> of data of unspecified interpretation to somebody.  Which means that
> the "port" property is both general and device-specific at the same
> time and the sanity of that is quite questionable IMO.

DT uses a node called either "port" or "ports" to store the port nodes. 
The reg property tells the number of the port (see 
Documentation/devicetree/bindings/graph.txt). I'm no DT expert, but my 
understanding is that the node namespace is different from the property 
namespace.

If you're concerned of possible double meanings, it's entirely possible 
to put the port nodes under hierarchical data extension named e.g. 
"ports", and document that this is what the node must be called (single 
port node could be just called "port"). This way, it should be much more 
difficult to interpret a non-port node as a port node --- roughly 
equivalent of the DT ports node.

The drawback with this change is that the size of the data structure in 
ASL (and AML) will grow.

-- 
Sakari Ailus
sakari.ailus-VuQAYsv1563Yd54FQh9/CA@public.gmane.org
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html