This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

[参考译文] Linux/processor-SDK-AM335X:LVDS 视频问题

Guru**** 2560240 points
Other Parts Discussed in Thread: DS90C385A

请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

https://e2e.ti.com/support/processors-group/processors/f/processors-forum/601230/linux-processor-sdk-am335x-lvds-video-issues

器件型号:PROCESSOR-SDK-AM335X
主题中讨论的其他器件:DS90C385A

工具/软件:Linux

LVDS 视频工作时出现问题。

背景:我们有一个支持 LVDS 和 HDMI 视频输出的定制 AM335x 板(注:我们根据电路板所放置的产品,一次只使用这两个视频输出中的一个–无需在输出之间切换;编辑: 使用 LVDS 时、器件树中甚至没有 HDMI 配置)。 我们已经让 HDMI 工作了一段时间,现在正在尝试让 LVDS 工作。

CPU 的 LCD 视频引脚连接到三个多路复用器芯片(一个用于红色引脚和视频控制信号,例如 VSYNC),一个用于绿色引脚,一个用于蓝色引脚), 然后、多路复用器被切换为将视频信号发送到 LVDS 发送器芯片或 HDMI 发送器芯片。 其结果是、对于 HDMI 和 LVDS、从 CPU 流出的 LCD 引脚映射是相同的。

问题:在设备树中显示计时设置正确–我为测试显示的简单 QT GUI 稳定且位置正确–但我似乎有颜色问题。 更具体地说:

  • 交换红色和蓝色。
  • LVDS 显示屏需要 RGB888、CPU 和 LVDS 显示屏之间的数据路径为此布线。 我已经将一些打印稿放入 DRM 和 TILCDC 代码中,它报告的像素格式为 DRM_MODE_RGB888。 但是、不仅交换了红色和蓝色、似乎已将某项设置为6位色深(可能是 RGB565?)。

我知道以上内容是因为 使用我的测试 GUI、我将 Qt 斜升窗口背景的红色通道从0-255、但我看到的不是稳定闪烁的红色、而是当值从0–63阶跃时、我看到一个蓝色、 然后以64的频率变为黑色、亮度上升到127、以128的频率变为黑色、以191为斜升、以192为黑色、然后以255为斜升。

 此时,我应该指出,我知道使用24bpp 时交换的红色和蓝色引脚的 AM335x LCD 引脚勘误表(请参阅 https://tinyurl.com/y8y48dk9上的 AM335x 勘误表文档,第8页) 我们的板已按照文档中的说明交换了红色和蓝色引脚、以支持 HDMI 显示屏上的 RGB888。 鉴于发送到 HDMI 显示屏的视频显示正常、我认为交换操作已正确完成(我们的原理图显示了这一点)。

我花了几天时间处理此问题,可以提供任何响应者可能需要的各种信息,但我将从以下内容开始。

设备树:

相关设备树节点。

       面板{

                      兼容="ti、tilcdc、panel ";

       pinctrl-names ="default"、"sleep";

       pinctrl-0 =<&LCD_PINS_DEFAULT>;

       /*pinctrl-1 =<&LCD_PINS_SLEEP>;*/

                      状态="正常";

                      面板信息{

                                     交流偏置          =<255>;

                                     AC-BIAS-INtrpt   =<0>;

                                     dma-burse-SZ     =<16>;

                                     bpp              =<24>;

                                     FDD              =<0x80>;

                                     同步边沿        =<0>;

                                     SYNC-Ctrl        =<1>;

                                     栅格顺序     =<0>;

                                     FIFO-TH          =<0>;

                      };

 

                      显示时序{

                                    800x600{

                                                    时钟频率=<40000000>;

                                                    hactive =<800>;

                                                    Vactive =<600>;

                                                    前沿=<40>;

                                                    后沿=<88>;

                                                    HSYNC-LEN =<128>;

                                                    后沿=<23>;

                                                    垂直前沿=<1>;

                                                    vsync-len =<4>;

                                                    HSYNC-ACTIVE =<1>;

                                                    vsync-active =<1>;

               停用=<1>;

               像素时钟激活=<1>;

                                     };

                      };

       };

 

LCDC{

       状态="正常";

};

 注:我省略了 pinctrl 映射。

 我还尝试将器件树中的 bpp 设置为16、仅用于 giggles、并且在行为上没有差别。

 

莫代特:

另一件事是,在我至少运行一次模式检测之前,LVDS 显示屏根本不会显示任何视频。 在使用 HDMI 显示屏时不需要这样做。

说到 motetest,我还使用它来显示其色条测试图像。 这在使用 HDMI 显示屏时显示正常、 但是,使用 LVDS 显示时,不仅颜色会关闭(根据我看到的其他颜色问题的预期),而且色条会偏移到屏幕底部,只显示一小部分。 这意味着显示分辨率或时序可能不正确、但当我显示专为显示屏设置大小的 Qt 测试 GUI 时、所有内容都显示在正确的位置。

还有一些我可能涉及的其他信息–我在驱动程序打印中看到的一些对我来说并不重要的内容,但我完全不熟悉 DRM 视频子系统, 因此,我不知道我认为的错误是否真的是错误的,现在我将继续讨论这一问题。

如果有任何帮助,将不胜感激。

  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。
    尊敬的 Jeff:

    鉴于 HDMI 上的一切工作正常、这听起来更像是硬件问题。 是否确定 LVDS 发送器已正确连接到 LCD 信号? 您可以使用此 wiki 作为参考: processors.wiki.ti.com/.../LCD_connectivity
  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

    感谢 Biser 的快速响应。

    不确定我们是否已看到该 wiki 页面、因此我们将阅读该页面、然后再次检查引脚映射。 我会告诉你。

    最棒的
    Jeff

  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

    高 Biser -

    再次感谢您访问 wiki 页面。 我已阅读它。 正如该页面所讨论的、我们的显示屏确实能够支持18位或24位 RGB、并且就我们所能知、我们将使引脚置为有效、使其处于24位模式。

    对于我们的板载视频连接、我们匹配标有"连接到24位 LCD 格式2"的图、但请注意以下几点:

    • 我们使用 的是 DS90C385AMT LVDS 发送器、而不是 LVDS83B 发送器。 不过、我们发送器的输入都标记为与 LVDS83B 相同的编号、我们的引脚映射如图所示。
    • 我们没有从 AM335x 直接连接到发送器(如我的 OP 中所述、每个彩色通道都通过多路复用器)。
    • wiki 页面上格式2图片中的 OMAP DSS 引脚看起来没有排列、因为它们在 AM335x 上。 这可以在勘误文档中看到(如我的 OP 中所链接的):

    OMAP 引脚:

    DSS 0-7 =蓝色0-7

    DSS 8 - 15 =绿色0-7

    DSS 16-23 =红色0-7

    AMM335X 已更正勘误表:

    LCD_DATA 引脚:23   22  21  20  19  18   17  16   5-11  10 - 5  4 - 0

                    B[0] G[0] R[0] B[1] G[1] R[1] B[2] R[2] B[7:3] G[7:2]  R[7:3]  

    我需要注意的是、即使没有勘误表校正(请参阅我们在电路板上实施的文档)、R、G 和 B 似乎映射到 AM335x LCD_DATA 引脚的方式与链接页面图片中的 OMAP DSS 引脚的方式不同。

    无论如何、I 和原始电路板设计人员都已经使用我们的电路板和 LVDS 电缆原理图以及多路复用器、LVDS 发送器和 LCD 显示屏数据表 (同样、只要我们能够确定)多次验证像素连接、 现在、我 使用 wiki 页面、再浏览一次多路复用器和发送器之间的连接。

    我们很确定我们的连接是否正确、但不能在这些连接上设置示波器。

    我还想知道为什么我需要运行 modetest 命令才能获得任何视频。 我还想知道、是否将驱动程序置于某种6位模式、而不是我们所需的8位模式?   据我所知、DRM/TILCDC 驱动程序不支持 RGB666、但它可能会进入565模式?  

    再次感谢!
    Jeff

  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

    [引用 user="Jeff Fuller">我们使用 的是 DS90C385AMT LVDS 发送器、而不是 LVDS83B 发送器。 不过、我们发送器的输入均标有与 LVDS83B 相同的编号、并且我们的引脚映射如图所示。

    此处重要的是 LVDS 发送器定序、即并行信号在串行侧的映射方式。 您能否比较两个发送器以查看它们是否使用相同的 LVDS 格式?

    [引用 user="Jeff Fuller"> Wiki 页面上格式2图片中的 OMAP DSS 引脚似乎未按 AM335x 上的顺序排列。 [/报价]

    这是正确的、您应该忽略它。 只需确保您的并行信号与勘误表中给出的 AM335x 排列相匹配。

  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

    您好、Biser、

    是的、我们已经将 wiki 页面(LVDS83B)中的发送器数据与我们使用的发送器(DS90C385AMT)进行了比较、并且并行到串行映射是相同的:

    (请注意、这两个图按相反的顺序列出了串行线路)。

    还有其他建议吗?

    谢谢!

  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

    Jeff:

    您能否确认 PCLK 是多路复用还是直接连接到 LVDS 和 HDMI 发送器器件?

    如果您碰巧能够访问 PCLK (来自 SOC)或 板上 LVDS 发送器器件的 TXCLKIN 引脚、您能否在示波器上检查它、以查看切换到 LVDS 发送器时时时时钟信号是否清晰?

    此致

    Jian

  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

    感谢您的回答、Jian。

    实际上、PCLK 是多路复用的。 是的、我们可以尝试将其范围缩小。 实际上、我们也需要对某些像素行进行范围划分、因为坦率地说、我已经很困惑、如下所述。

    我将器件树改回其 HDMI 配置、并使用 DRM 驱动程序中的 prints、fbset 工具中的输出以及帧缓冲器本身的内容转储(通过/dev/fb0)来检查 使用 HDMI 时 DRM 驱动程序所处的颜色深度/像素顺序。 令人惊讶的是、所有这些都指向驱动器处于 RGB565模式。 这让我很震惊、因为我一直假设驱动程序将在用于 HDMI 的 RGB888中、 因为我们将通过多路复用器发送所有24个 LCD_DATA 引脚并将其输出到 HDMI 发送器。 由于使用 HDMI 时的驱动程序视频模式是根据 EDID 信息设置的、而不是器件树、并且视频刚刚工作、因此我从未有理由真正检查驱动程序处于哪种模式。

    问题在于:如果在使用 HDMI 时、驱动程序实际上是在 RGB565中、而不是在 RGB888中、 然后、正如 我们在 LVDS 上看到的那样、红色和蓝色应该被交换用于 HDMI、这是因为根据我们的电路板原理图、我们已经为 RGB888的 LCD_DATA 引脚接线、如 AM335x 勘误表的图2所示。 如勘误表所示、如果驱动器配置为 RGB565、并以该方式连接引脚、则应交换红色和蓝色。 但在使用 HDMI 时不会交换这些颜色(我认为使用 HDMI 时 DRM 驱动程序处于 RGB888模式的另一个原因)。 这是令人困惑的。

    现在、回到 LVDS:我已经将面板器件树节点(该节点仅用于 LVDS)中的 bpp 字段设置为24 (同样、基于我们已连接所有24个 LCD_DATA 引脚的事实)、 这确实 会将驱动程序置于 RGB888模式下(通过 fbset、帧缓冲区内容和驱动程序 printks 确认、 与上述内容相同)。 当然、如果我们实际连接的是勘误表文档中的图3、那么是的、对于 RGB888模式下的驱动程序、我们可以看到红色和蓝色互换、 此外、我们只有6位颜色(如我的原始文章中所述)、我的测试程序在0 - 255范围内斜升红色或蓝色的平坦区域时、结果为0、64、128、192、最亮的颜色为63、127、191、 和255、就像我们每种颜色使用6位一样)。

    现在、我们的 LVDS 显示屏恰好能够支持 RGB666和 RGB888。 我已经尝试将显示屏置于该模式、并将器件树中的 bpp 字段设置为16、虽然这确实将 DRM 驱动程序置于 RGB565模式、但在我执行此操作时、显示屏会显示垃圾。

    是否有人知道、假设所有信号都正确连接、显示屏的 RGB666模式是否与 DRM 驱动程序的 RGB565模式兼容? 我希望 用于红色[0]和蓝色[0]的 LCD_DATA 引脚将只包含0、因此如果我们正确连接了硬件、我们的显示屏将工作吗?

    此外、根据我发布的内容、是否有人认为我们在阅读勘误表文档时出现了错误?

    我们将在此处尝试一些操作:

    • 如上所述对各种信号进行范围界定
    • 按照 LVDS 数据路径从 CPU 引脚通过电缆输出、尝试确保、如果出于某种原因(原理图不正确?) 根据勘误文档中的图3进行连线、显示屏将在 RGB666模式下工作。 我们的电缆可能需要交换一些引脚。

    任何人的想法都将不胜感激。

    谢谢、

    Jeff

  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。
    Jeff:

    感谢您的详细描述。 我认为有几个方面:
    1.为什么在 HDMI 显示屏通过 EDID 将 LCDC 设置为 RGB656模式时未交换 R/B 颜色
    2.为什么在 LVDS 显示屏上换用颜色
    3.为什么我们需要运行一次 modetest 才能看到 LVDS 显示
    我将与驾驶员团队核实 EDID 条件、假设有通过 HDMI 的 EDID、但 LVDS 没有。 还将确认我们看到与勘误表相反的原因。

    我在平均时间内还有几个问题要问您:
    1.我阅读了 DS90C385A 规范,不支持 RGB666模式。 因此、即使该面板确实支持 RGB666 (我们可以将 RGB565连接到 RGB666)、DS90C385A 也会导致垃圾。 实际上、RGB666只使用三个数据通道而不是4个、因此串行数据打包方式非常不同。 我怀疑该面板忽略了第4个数据通道、仅解释了3个数据通道。
    2.能否确认您是否可以将 HDMI 显示器设置为 RGB888模式? 希望这将触发 EDID 并将驱动器置于正确的模式。

    此致
    Jian
  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。
    尊敬的 Jian:

    感谢您的快速回复-我同意您的商品列表。 感谢您指出 LVDS 发送器不支持 RGB666 -这说明了我看到垃圾的原因。

    我在使用 HDMI 时尝试将东西放入 RGB888中-认为它将提供进一步的证据来确定 LCD_DATA 引脚的布线方式。 我已经尝试了一些操作、但我不确定如何强制它进入该模式(默认为 RGB666)。 我使用 modetest 转储 EDID 显示支持的各种模式、 但是、modetst 输出中没有颜色顺序或位深度信息(至少不是我可以看到的)、只有分辨率和显示时间、因此我不确定是否可以使用 modetest 来实现它。

    我还尝试黑客攻击 DRM 驱动程序以强制 RGB888、但在启动期间挂起内核(我确实收到了错误消息、因此我知道驱动程序中它在哪里死了)。

    您是否知道在使用 HDMI 时如何强制使用 RGB888?
  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。
    Jeff:

    我向驾驶员团队提出了同样的问题、没有强制使用 HDMI。 回答时将回帖。 因为他在欧洲时区、所以可能会在这里过夜。

    在 HDMI 显示屏上、您能否确认您尝试显示的分辨率是多少? 如果是标准高清显示器、我猜显示器会返回支持的模式、AM335x 选择了较低的分辨率设置(因为它不支持高清)、并且选择有限。

    Jian
  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

    好的、谢谢 Jian。

    驱动器选择1280x800模式、这实际上是显示器的原生分辨率(对于医疗设备而言、这是一个小显示屏)。 不过、仍然不知道为什么它默认为 RGB565而不是 RGB888。 发送器和显示屏都能够实现这一功能、尽管我应该说、我听说我的显示屏数据表不是很好-这是我们的第三方定制、 与 HDMI 接收器/LCD 显示特性相反、更侧重于机械和低电平电气信号。

    如果需要、我可以尝试让我们的制造人员从第三方获取更好的数据表。

    编辑后添加:

    如果驾驶员想知道我是如何确定 显示屏所处的模式的、我已经用三种不同的方法来完成此操作(以下结果适用于 HDMI、而 LVDS 显示 RGB888):

    • DRM 驱动程序的 DRM_fb_get_bpp_depth 函数的 printk 输出显示如下:  

    保持当前像素顺序/每像素位数的 int = DRM_FORMAT_RGB565 = RG16小端字节序(0x36314752)
    深度= 16
    bpp = 16

    • fbset -v -i 显示:

    RGBA 5/11,6/5,5/0.0/0

    •  当我转储将 R G 和 B 像素设置为可识别的8位十六进制值的帧缓冲器(dev/fb)时(例如、通过 Qt 调用在测试 GUI 中将 R 设置为0xAA、G=0xcc、G=0xdd)、我在帧缓冲器中看不到这些值 (我在 RGB 24运行 LVDS 显示时执行此操作)、我认为这是因为它们已被截断或以某种方式封装以适应 RGB565。

  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。
    Jeff:
    感谢您提供详细信息。 我认为这对驾驶员团队来说已经足够好了、可以阅读。 我明天会向您提供最新信息。
    Jian
  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

    Jeff:

    查看我向驾驶员团队提出的问题和答案。  

    您能否使用我们正在使用的内核进行检查?

    谢谢

    Jian

    1. AM335x LCD 上有一个有效的勘误表、说明如果 LCD 处于 RGB888模式、彩色引脚将被交换。 http://www.ti.com/lit/er/sprz360i/sprz360i.pdf。但客户看到相反的行为。 问题是“驱动程序是否自动交换红色和蓝色数据?”                

    [a]不同的内核版本以不同的方式处理了硬件勘误表。 较新的内核可以正确地实现这一点:在器件树数据中、您需要定义电路板是否交换了色线。 这会影响 DRM 驱动程序支持的像素格式:RGB565 + BGR888或 BGR565 + RGB888。 请注意、有许多应用程序不支持 BGR 格式、因此即使驱动程序表示支持 BGR888、用户空间也可能拒绝使用它。 在之前的内核中、如果我回忆得对、驱动程序刚才说它支持 RGB565和 RGB888、即使另一个内核实际上是 BGR。

    2.对于 HDMI 显示、他们为 RGB888配置了器件树、但 EDID 改写了配置并将驱动程序放置到 RGB565。 这是预期的吗? 我们可以禁用 EDID 覆盖吗?      

    [A] EDID 不会影响像素格式、因此无法"覆盖"它。

    3.与上面的#2相关,对于 LVDS 显示,他们必须先运行“最小”,然后才能看到 LVDS 视频。 实际驱动程序中是否有未初始化的参数?

    [a]我不知道导致这种情况的原因是什么。 如果启用了 fbconsole、则在加载显示驱动程序时、它们应在 LVDS 显示屏上获得图像。

    我建议查看主线内核以及 AM3 BeagleBone 和 AM3 EVM 的工作原理。 如果我回忆一下、BeagleBone 在 rgb565设置中具有 HDMI、而 AM3 EVM 在 rgb888设置中具有 LCD。

  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。
    Jeff:

    有关 HDMI 驱动器行为的进一步 QA,提出了一些问题,以便从驱动器团队获得确认/澄清:

    1)。 驱动器将通过 EDID 自动选择分辨率和帧速率?
    [A]驱动器通常不会自动执行任何操作。 应由应用程序决定要执行的操作。 也就是说、有帧缓冲控制台、由内核基于 EDID 创建(如果 EDID 可用)。 但应用程序通常不使用该 fb、它主要用于引导消息等。

    2)。 EDID 将覆盖分辨率和帧速率的器件树规格?
    [A]这是 HDMI 编码器驱动程序。 但是、如果它支持 EDID、我发现它还支持从器件树获取数据、这是奇怪的。

    3)。 像素格式、例如 bpp、将不会由 EDID 确定。 而是在设备树中指定。
    [a]像素格式未在器件树中定义、应由应用程序根据其要使用的像素格式来分配缓冲区(当然、受驱动程序支持的格式的限制)。

    Jian
  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

    Jian、我对你们两篇文章的回答都是蓝色的。

    [引用用户="jian35385"]

    1. AM335x LCD 上有一个有效的勘误表、说明如果 LCD 处于 RGB888模式、彩色引脚将被交换。 http://www.ti.com/lit/er/sprz360i/sprz360i.pdf。但客户看到相反的行为。 问题是“驱动程序是否自动交换红色和蓝色数据?”                

    [a]不同的内核版本以不同的方式处理了硬件勘误表。 较新的内核可以正确地实现这一点:在器件树数据中、您需要定义电路板是否交换了色线。 这会影响 DRM 驱动程序支持的像素格式:RGB565 + BGR888或 BGR565 + RGB888。 请注意、有许多应用程序不支持 BGR 格式、因此即使驱动程序表示支持 BGR888、用户空间也可能拒绝使用它。 在之前的内核中、如果我回忆得对、驱动程序刚才说它支持 RGB565和 RGB888、即使另一个内核实际上是 BGR。

    [/报价]

    我实际上在第二天在线向设备树和驱动程序提供了此修补程序: https://patchwork.kernel.org/patch/9308611/

    这是他们讨论的内容吗? 我将尝试应用补丁作为实验、但遗憾的是、我们的内核看起来是旧版本、不能与补丁一同使用、因为补丁修改了我们的驱动程序版本中不存在的特定函数。 我们目前位于 AM335x 处理器 SDK 2.00.00.00 (以下是"uname -a "输出: Linux DRXC-12 4.1.6-g52c4aa7 #44 Wed Jun 7 11:00:47 EDT 2017 armv7l GNU/Linux)

    他们是否同意此内核太旧而无法支持此修补程序?

    [引用用户="jian35385"]

    2.对于 HDMI 显示、他们为 RGB888配置了器件树、但 EDID 改写了配置并将驱动程序放置到 RGB565。 这是预期的吗? 我们可以禁用 EDID 覆盖吗?      

    [A] EDID 不会影响像素格式、因此无法"覆盖"它。

    [/报价]

    好的-抱歉、如果我不清楚这一点、但在使用 HDMI 时、设备树不支持设置每像素位数。

    [引用用户="jian35385"]

    3.与上面的#2相关,对于 LVDS 显示,他们必须先运行“最小”,然后才能看到 LVDS 视频。 实际驱动程序中是否有未初始化的参数?

    [a]我不知道导致这种情况的原因是什么。 如果启用了 fbconsole、则在加载显示驱动程序时、它们应在 LVDS 显示屏上获得图像。

    我建议查看主线内核以及 AM3 BeagleBone 和 AM3 EVM 的工作原理。 如果我回忆一下、BeagleBone 在 rgb565设置中具有 HDMI、而 AM3 EVM 在 rgb888设置中具有 LCD。

    [/报价]

    我不确定什么是 fbconsole -我将对此进行研究、但如果他们能告诉我如何启用它、那会很有帮助。

    我确实将 LVDS 的器件树条目建立在 EVM 器件树上(或者可能是状态机套件 EVM)。  


    1)。 驱动器将通过 EDID 自动选择分辨率和帧速率?

    [A]驱动器通常不会自动执行任何操作。 应由应用程序决定要执行的操作。 也就是说、有帧缓冲控制台、由内核基于 EDID 创建(如果 EDID 可用)。 但应用程序通常不使用该 fb、它主要用于引导消息等

    因此、我们将在启动期间使用闪屏、然后在启动后使用 Qt GUI 应用。 我不完全熟悉我们的 GUI 应用、但不知道、但我们在启动 GUI 之前设置了以下 Qt 环境变量:

    导出 QWS_SIZE=1280x800 (这适用于 HDMI;而800x600适用于 LVDS)

    导出 QWS_DISPLAY="LinuxFb"

    我们将-display LinuxFb 作为参数传递给 GUI (并将其传递给 Qt 应用程序类)。

    我不认为在使用 HDMI 时、我们的应用要求任何特定的帧速率或每像素位数-我们只是在使用默认选择的驱动程序...  再说一次、我对 fbconsole 并不熟悉 -坦率地说、我从未需要深入研究 Linux 视频子系统-当我们在2年前开始使用 HDMI 时、它在我们为它配置了器件树后就能正常工作。 非常感谢您对我的支持。

    2)。 EDID 将覆盖分辨率和帧速率的器件树规格?
    [A]这是 HDMI 编码器驱动程序。 但是、如果它支持 EDID、我发现它还支持从器件树获取数据、这是奇怪的。

    是的、正确。 使用 HDMI 时、我们的器件树不会执行任何操作来指定分辨率、帧速率、显示时序或 bpp。 只有在使用 LVDS 时、器件树才包含此信息。

    3)。 像素格式、例如 bpp、将不会由 EDID 确定。 而是在设备树中指定。
    [a]像素格式未在器件树中定义、应由应用程序根据其要使用的像素格式来分配缓冲区(当然、受驱动程序支持的格式的限制)。

    好的、当 HDMI 接入 RGB888时、这听起来就像是问题的关键所在。 如上所述、我们使用的是 Qt、因此根据该答案、Qt 似乎必须要求 RGB565? 他们是否知道如何使用 Qt 请求 RGB888模式?  

    现在、我只想重申一下问题、让我们保持专注:我们有兴趣让 HDMI 进入 RGB888仅用于测试目的。 我们的原理图似乎显示我们已按照勘误表中的图2连接了 LCD_DATA 引脚、这意味着在 RGB565中使用 HDMI 时、应交换红色和蓝色。 但这不是、因此将 HDMI 输入 RGB888的原因是要查看它是否换为红色和蓝色。

    对于 LVDS、我们必须在 RGB888中使用它、因为发送器不支持 RGB565。 但当它处于 RGB888中时、红色和蓝色被交换、我们只获得6位像素范围、而不是8位。  

    因此、我将研究如何在使用 HDMI 时使用 Qt 设置 RGB888的颜色模式、以便我们可以查看是否交换了红色和蓝色。 我们还必须考虑如何将 LVDS 接入 BGR888、因为它看起来可能是这里的最终解决方案。 是否需要该驱动程序补丁? 如果是、我们是否需要最新的 TISDK 版本? Qt 甚至支持这样做吗?

    再次感谢您和驾驶员团队。

    Jeff

  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

    [引用用户="Jeff Fuller"]

    我们目前位于 AM335x 处理器 SDK 2.00.00.00 (以下是"uname -a "输出: Linux DRXC-12 4.1.6-g52c4aa7 #44 Wed Jun 7 11:00:47 EDT 2017 armv7l GNU/Linux)

    他们是否同意此内核太旧而无法支持此修补程序?

    [/报价]

    是的、此 PSDK 版本太旧了。 我们建议迁移到最新的 PSDK (版本3.3)以获得更好的支持。 PSDK 2.0版本不支持通过 DTS 文件配置 RGB 模式。  

  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

    大家好、Manisha、

    好的、那么我想说清楚。 移动到3.3将允许我们在使用 LVDS 时将驱动程序放置在 BGR888中、这将修复红色/蓝色的交换问题?

    使用 LVDS 时、我们也遇到了一个问题、即尽管驱动器处于888模式、但我们的动态范围似乎只有每种颜色6位。 如果在更新 SDK 并切换到 BGR888后仍然存在这种情况、我们仍然会遇到颜色问题。 我们是否希望更新到 SDK 3.3也能解决此问题?

    最后、您是否建议我们继续进行更新、并且不要同时执行涉及在使用 HDMI 时尝试将驱动程序接入 RGB888的进一步测试

    谢谢!

    Jeff

    后期编辑:

    另一个问题与我们的视频问题无关。 我相信 SDK3.3中包含 Qt 5.6。 大家是否知道是否/何时发布具有 Qt 5.8或5.9 (5.9是我们更喜欢的 Qt 版本)的 SDK? 即使时间安排很短也会很有帮助。谢谢!

  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

    [引用用户="Jeff Fuller">好的、我想说清楚。 移动到3.3将允许我们在使用 LVDS 时将驱动程序放置在 BGR888中、这将修复红色/蓝色?[/引号]的交换问题

    移动到3.3将使您能够控制向驾驶员指示布线方案。 除非问题是错误的驱动程序说明、否则我无法评论它是否可以解决问题。  

    [引用 user="Jeff Fuller">使用 LVDS 时、我们也遇到了一个问题、即尽管驱动器处于888模式、但我们的动态范围似乎只有每种颜色6位。 如果在更新 SDK 并切换到 BGR888后仍然存在这种情况、我们仍然会遇到颜色问题。 我们是否希望更新到 SDK 3.3也可以解决此问题?

    我会说、请检查 QT 应用程序、它使用什么颜色方案进行渲染。  

    [引用 user="Jeff Fuller"]最后,您是否建议我们继续更新,并且不要同时执行涉及在使用 HDMI 时尝试将驱动程序插入 RGB888的进一步测试

    由你决定。 如果您的用例不需要 RGB888用于 HDMI、则可以跳过测试。  

    [引用 user="Jeff Fuller">您的另一个问题,与我们的视频问题无关。 我相信 SDK3.3中包含 Qt 5.6。 大家是否知道是否/何时发布具有 Qt 5.8或5.9 (5.9是我们更喜欢的 Qt 版本)的 SDK? 即使是一个很短的时间范围也会很有帮助。谢谢![/引述]

    我们将于2018年第2季度迁移到 QT 5.9。 您可以使用 OE/Yocto 的主分支并使用 那里最新的版本。  主电流具有 Qt 5.8、即将切换到 Qt 5.9  

  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

    好的、谢谢。 我们将降低3.3伏。 SDK。 我将在我们启动并运行后再发布。

    最棒的

    Jeff

  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

    我已将我们的项目迁移到 TI 处理器 SDK v3.03.00.04。

    通过将蓝色和红色接线=“交叉”放置到设备树中,我们的蓝色和红色不再切换。 很棒! 感谢您的推荐。

    遗憾的是、我们似乎仍然只有6位的颜色范围、而不是8位。

    我在前面的帖子中描述的64位边界处的 R、G 和 B 平坦字段的斜升和重置仍在发生–似乎我们失去了每种颜色的两个 MSB。

    以下是我收集的一些信息,这些信息可能对我有所帮助,也可能对我没有帮助。 在我的帖子结束时,我将讨论我看到的另一个错误。

    从驱动程序报告的 DRM_MODE:

    我在 DRM_fb_get_Bpp_depth 中有一个 printk。 将设备树中的 bpp 设置为24,并将蓝线和红线设置为“交叉”,DRM_MODE 报告为 XRGB888。 我原本希望它是 RGB888、但我认为 X 只是每个像素存储在中的32位字的未使用字节?

    Modetest 将支持的模式列为 BG16 RG24 XR24

    请注意、我最初是从蓝色和红色接线设置为"直线"、bpp 设置为24–这导致了 DRM 模式 RG16;这也交换了我们的红色和蓝色通道、正如预期的那样、Modetest 将支持的模式列为:RG16 BG24 XB24

    莫代特:

    说到 modetest、在 LVDS 显示屏上观看视频之前、我不再需要运行 modetest、但这可能是因为 Weston 在启动时运行。 我还没有弄清楚如何禁用 Weston 的自动启动(现在,我在启动后将其取消,尽管无论我是否杀死 Weston 都会丢失两位颜色)。 请注意,我在启动时看到 printk 输出中的 XRGB888,然后 Weston 才能运行,因此,不是 Weston,或者至少不是仅 Weston,而是将驱动程序放在 XRGB 而不是 RGB 中。

    设备树:

    tilcdc 的器件树绑定帮助文件(…/Documentation/devicetree/bindings)已与 SDK V2中的文件不同。 我没有尝试更新设备树(除了添加蓝线和红线接线字段)以匹配这些更改;这些字段相同,只是一些包含的节点发生了更改。 我不知道这是否与6位问题有关,但树中的所有其它内容似乎都正常工作,并且显示的计时设置正确,等等…。

    上述情况的一个例外。 在启动过程中,我遇到了以前没有遇到过的 pinmux 错误。 不确定如何解释,因为我没有以任何方式修改 SDK V3的设备树(同样,除了蓝色和红色接线字段),而且我得到的错误与任何 tilcdc 节点无关,而是与这些节点使用的 LCD 引脚有关。

    错误如下:

      [1.056359] pinctrl-single 44e10800.pinmux:面板已请求引脚44e108a0.0;无法索赔4830e000.lpdc

    [1.067074]   pinctrl-single 44e10800.pinmux:引脚-40 (4830e000.LCDC)状态-22

    [1.074258]   pinctrl-single 44e10800.pinmux:无法从 器件 pinctre 上的 LCD_PINS_DEFAULT 组中请求引脚40 (44e108a0.0)

    [1.086492]   tilcdc 4830e000.lcdc:应用设置时出错,反向    

    我不确定如何准确确定 LCD_PINS_DEFAULT 引脚节点中的哪个引脚此错误消息是指的。 我可以尝试在驱动程序中打印更多的打印内容,但如果你们能为我提供有关这方面的指导,我会很感激。

    谢谢、

    Jeff

  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。
    Jeff、

    冲突似乎是在 LCD_Data0引脚上发生的(请参阅 TRM 控制模块寄存器偏移8A0h)。 我没有使用 SDK 2和 SDK3版本来比较条目、但我认为在新 SDK 中、LCD 的 pinmux 已经配置、因此您的引脚控制条目与默认值相矛盾

    此致
    Michael
  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

    最后、我们回顾一下当今唯一的6位颜色范围问题。 已在 LVDS 连接器引脚上放置示波器、并注意到两个引脚损坏。 切换到不同的板、现在颜色正确。

    总之、我们需要版本3 SDK 来修复红色/蓝色换用、但6位颜色问题是由于电路板 损坏造成的。 下一次、我将检查电池上的引脚。

    感谢大家的帮助。

    Jeff

  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

    感谢您的更新。  很高兴知道您的问题现已解决。