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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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.



[Index of Archives]     [Device Tree Compilter]     [Device Tree Spec]     [Linux Driver Backports]     [Video for Linux]     [Linux USB Devel]     [Linux PCI Devel]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [XFree86]     [Yosemite Backpacking]


  Powered by Linux