On 01/10/2017 10:31 AM, Ramesh Shanmugasundaram wrote:
> Hi Laurent,
>
>>>>>> On Wednesday 21 Dec 2016 08:10:37 Ramesh Shanmugasundaram wrote:
>>>>>>> Add binding documentation for Renesas R-Car Digital Radio
>>>>>>> Interface
>>>>>>> (DRIF) controller.
>>>>>>>
>>>>>>> Signed-off-by: Ramesh Shanmugasundaram
>>>>>>> <[email protected]> ---
>>>>>>>
>>>>>>> .../devicetree/bindings/media/renesas,drif.txt | 202
>> +++++++++++++
>>>>>>> 1 file changed, 202 insertions(+) create mode 100644
>>>>>>>
>>>>>>> Documentation/devicetree/bindings/media/renesas,drif.txt
>>>>>>>
>>>>>>> diff --git
>>>>>>> a/Documentation/devicetree/bindings/media/renesas,drif.txt
>>>>>>> b/Documentation/devicetree/bindings/media/renesas,drif.txt new
>>>>>>> file mode 100644 index 0000000..1f3feaf
>>>>>>> --- /dev/null
>>>>>>> +++ b/Documentation/devicetree/bindings/media/renesas,drif.txt
>>>>>>>
>>>>>>> +Optional properties of an internal channel when:
>>>>>>> + - It is the only enabled channel of the bond (or)
>>>>>>> + - If it acts as primary among enabled bonds
>>>>>>> +--------------------------------------------------------
>>>>>>> +- renesas,syncmd : sync mode
>>>>>>> + 0 (Frame start sync pulse mode. 1-bit
>>>>>>> +width
>>>>>>> pulse
>>>>>>> + indicates start of a frame)
>>>>>>> + 1 (L/R sync or I2S mode) (default)
>>>>>>> +- renesas,lsb-first : empty property indicates lsb bit is
>> received
>>>>>>> first.
>>>>>>> + When not defined msb bit is received first
>>>>>>> +(default)
>>>>>>> +- renesas,syncac-active: Indicates sync signal polarity, 0/1 for
>>>>>>> low/high
>>>
>>> Shouldn't this be 'renesas,sync-active' instead of syncac-active?
>>>
>>> I'm not sure if syncac is intended or if it is a typo.
>>>
>>>>>>> + respectively. The default is 1 (active high)
>>>>>>> +- renesas,dtdl : delay between sync signal and start of
>>>>>>> reception.
>>>>>>> + The possible values are represented in 0.5
>> clock
>>>>>>> + cycle units and the range is 0 to 4. The
>> default
>>>>>>> + value is 2 (i.e.) 1 clock cycle delay.
>>>>>>> +- renesas,syncdl : delay between end of reception and sync
>>>>>>> signal edge.
>>>>>>> + The possible values are represented in 0.5
>> clock
>>>>>>> + cycle units and the range is 0 to 4 & 6.
>>>>>>> + The
>>>>>>> default
>>>>>>> + value is 0 (i.e.) no delay.
Are these properties actually going to be used by anyone? Just curious.
>>>>>>
>>>>>> Most of these properties are pretty similar to the video bus
>>>>>> properties defined at the endpoint level in
>>>>>> Documentation/devicetree/bindings/media/video-interfaces.txt. I
>>>>>> believe it would make sense to use OF graph and try to standardize
>>>>>> these properties similarly.
>>>
>>> Other than sync-active, is there really anything else that is similar?
>>> And even the sync-active isn't a good fit since here there is only one
>>> sync signal instead of two for video (h and vsync).
>>
>> That's why I said similar, not identical :-) My point is that, if we
>> consider that we could connect multiple sources to the DRIF, using OF
>> graph would make sense, and the above properties should then be defined
>> per endpoint.
>
> Thanks for the clarifications. I have some questions.
>
> - Assuming two devices are interfaced with DRIF and they are represented
> using two endpoints, the control signal related properties of DRIF might
> still need to be same for both endpoints? For e.g. syncac-active cannot be
> different in both endpoints?
Usually that's the case, but HW designers are weird :-)
>
> - I suppose "lsb-first", "dtdl" & "syncdl" may be defined per endpoint.
> However, h/w manual says same register values needs to be programmed for both
> the internal channels of a channel. Same with "syncmd" property.
>
> We could still define them as per endpoint property with a note that they
> need to be same. But I am not sure if that is what you intended?
>
> If we define them per endpoint we should then also try
>> standardize the ones that are not really Renesas-specific (that's at least
>> syncac-active).
>
> OK. I will call it "sync-active".
That's better, yes.
>
> For the syncmd and lsb-first properties, it could also
>> make sense to query them from the connected subdev at runtime, as they're
>> similar in purpose to formats and media bus configuration (struct
>> v4l2_mbus_config).
I consider this unlikely. I wouldn't spend time on that as this can always be
done later.
> May I know in bit more detail about what you had in mind? Please correct me
> if my understanding is wrong here but when I looked at the code
>
> 1) mbus_config is part of subdev_video_ops only. I assume we don't want to
> support this as part of tuner subdev. The next closest is pad_ops with
> "struct v4l2_mbus_framefmt" but it is fully video specific config unless I
> come up with new MEDIA_BUS_FMT_xxxx in media-bus-format.h and use the code
> field? For e.g.
>
> #define MEDIA_BUS_FMT_SDR_I2S_PADHI_BE 0x7001
> #define MEDIA_BUS_FMT_SDR_I2S_PADHI_LE 0x7002
>
> 2) The framework does not seem to mandate pad ops for all subdev. As the
> tuner can be any third party subdev, is it fair to assume that these
> properties can be queried from subdev?
>
> 3) Assuming pad ops is not available on the subdev shouldn't we still need a
> way to define these properties on DRIF DT?
>
>>
>> I'm not an SDR expert, so I'd like to have your opinion on this.
Neither am I :-)
I think using the endpoint idea does make sense since this helps in describing
the
routing. I am not sure what properties to put in there, though.
Can you describe a bit more which properties belong to which syncmd mode? That
will
help me make a decision.
Regards,
Hans
>>
>>>>> Note that the last two properties match the those in
>>>>> Documentation/devicetree/bindings/spi/sh-msiof.txt.
>>>>> We may want to use one DRIF channel as a plain SPI slave with the
>>>>> (modified) MSIOF driver in the future.
>>>>
>>>> Should I leave it as it is or modify these as in video-interfaces.txt?
>>>> Shall we conclude on this please?
>>
>
> Thanks,
> Ramesh
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-media" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
