[PATCH v2 3/7] dt-bindings: display: mxsfb: Add a bus-width endpoint property

Marek Vasut marex at denx.de
Tue Oct 13 07:03:39 EDT 2020


On 10/13/20 4:06 AM, Laurent Pinchart wrote:
> Hi Marek,
> 
> On Sat, Oct 10, 2020 at 10:47:05AM +0200, Marek Vasut wrote:
>> On 10/10/20 1:58 AM, Laurent Pinchart wrote:
>>> Hi Marek,
>>
>> Hi,
>>
>>> On Wed, Oct 07, 2020 at 10:40:26AM +0200, Marek Vasut wrote:
>>>> On 10/7/20 3:24 AM, Laurent Pinchart wrote:
>>>>
>>>> [...]
>>>>
>>>>> +          bus-width:
>>>>> +            enum: [16, 18, 24]
>>>>> +            description: |
>>>>> +              The output bus width. This value overrides the configuration
>>>>> +              derived from the connected device (encoder or panel). It should
>>>>> +              only be specified when PCB routing of the data signals require a
>>>>> +              different bus width on the LCDIF and the connected device. For
>>>>> +              instance, when a 18-bit RGB panel has its R[5:0], G[5:0] and
>>>>> +              B[5:0] signals connected to LCD_DATA[7:2], LCD_DATA[15:10] and
>>>>> +              LCD_DATA[23:18] instead of LCD_DATA[5:0], LCD_DATA[11:6] and
>>>>> +              LCD_DATA[17:12], bus-width should be set to 24.
>>>>
>>>> The iMX6 IPUv3 uses interface-pix-fmt which is a bit more flexible, but
>>>> I'm not sure whether it's the right way to go about this, see:
>>>> Documentation/devicetree/bindings/display/imx/fsl-imx-drm.txt
>>>
>>> I think specifying the bus with is better. It's a standard property, but
>>> more than that, a given bus width can carry different formats. For
>>> instance, a 24-bus could carry RGB666 data (with dithering for the
>>> LSBs).
>>
>> I think that's exactly what the interface-pix-fmt was trying to solve
>> for the IPUv3, there you could have e.g. both RGB666 and LVDS666 , which
>> were different.
> 
> My point is that the driver should support multiple formats that can be
> carried over a given bus width, with the actual format to be used
> queried from the sink (usually a panel) instead of being hardcoded in
> DT.

So, should the IPUv3 be fixed as well then ?



More information about the linux-arm-kernel mailing list