Skip to content

HDMI timing incorrect #9

Open
Open
HDMI timing incorrect#9
Assignees
joelagnel
Labels
bug
Milestone
Pre-release kernel

Description

@jadonk
jadonk
opened on Nov 30, 2012

I'm currently getting timings that my display doesn't support, despite EDID read reporting success.

Activity

  1. jadonk commented on Nov 30, 2012

    @jadonk
    jadonk
    on Nov 30, 2012
    SponsorMemberAuthor

    Is it possible to assign these issues to individual branches? This issue is on the 3.7 branch.

  2. koenkooi commented on Nov 30, 2012

    @koenkooi
    koenkooi
    on Nov 30, 2012
    Contributor

    I get "no signal" on my monitor with the current code.

  3. ghost assigned
    joelagnel
    on Nov 30, 2012

  4. koenkooi commented on Nov 30, 2012

    @koenkooi
    koenkooi
    on Nov 30, 2012
    Contributor

    root@bonelt:~# dmesg | grep -i hdmi
    [ 0.532761] capebus bone:0: Slot #1 id='NXP HDMI on CapeBus,00A1,Beagleboardtoys,Override Part#'
    [ 0.623097] bonegeneric bone-0:1: NXP HDMI on CapeBus: V=00A1 'bone-generic-cape'
    [ 0.646773] hdmitx(tda19989) 1.3.0 compiled: Nov 30 2012 11:44:35 -ioctl (2009-10-15)
    [ 0.876056] HDMI TX SW Version:5.3 compatibility:0
    [ 1.901595] hdmi EDID received
    [ 1.901621] tmdlHdmiTxGetEdidSourceAddress 3813

    root@bonelt:~# fbset

    mode "720x480-75"
    # D: 33.751 MHz, H: 39.475 kHz, V: 75.333 Hz
    geometry 720 480 720 480 16
    timings 29629 59 15 30 9 61 5
    rgba 5/11,6/5,5/0,0/0
    endmode

    root@bonelt:~# uname -a
    Linux bonelt 3.7.0-rc7 #320 SMP Fri Nov 30 11:44:41 CET 2012 armv7l GNU/Linux

  5. koenkooi commented on Nov 30, 2012

    @koenkooi
    koenkooi
    on Nov 30, 2012
    Contributor

    Still nothing with this one:

    [koen@Angstrom-F16-vm-rpm kernel]$ git show |
    commit 28f96c1bb4771247627e5fd0d0e4e1c5c9f39c3b
    Author: Joel A Fernandes joelagnel@ti.com
    Date: Fri Nov 30 10:29:29 2012 -0600

    da8xx-fb: hack to fix pixclk

Signed-off-by: Joel A Fernandes <joelagnel@ti.com>

    diff --git a/drivers/video/da8xx-fb.c b/drivers/video/da8xx-fb.c
    index 91061e6..39977b3 100644
    --- a/drivers/video/da8xx-fb.c
    +++ b/drivers/video/da8xx-fb.c
    @@ -771,7 +771,7 @@ static void lcd_calc_clk_divider(struct da8xx_fb_par *par)
    unsigned int lcd_clk, div;

        lcd_clk = clk_get_rate(par->lcdc_clk);

    •   div = lcd_clk / par->pxl_clk;

    •   div = 5;

    root@bonelt:~# fbset

    mode "720x480-75"
    # D: 33.751 MHz, H: 39.475 kHz, V: 75.333 Hz
    geometry 720 480 720 480 16
    timings 29629 59 15 30 9 61 5
    rgba 5/11,6/5,5/0,0/0
    endmode

    root@bonelt:# uname -a
    Linux bonelt 3.7.0-rc7 #321 SMP Fri Nov 30 17:47:33 CET 2012 armv7l GNU/Linux
    root@bonelt:    # dmesg | grep -i hdmi
    [ 0.536468] capebus bone:0: Slot #1 id='NXP HDMI on CapeBus,00A1,Beagleboardtoys,Override Part#'
    [ 0.626797] bonegeneric bone-0:1: NXP HDMI on CapeBus: V=00A1 'bone-generic-cape'
    [ 0.650437] hdmitx(tda19989) 1.3.0 compiled: Nov 30 2012 11:44:35 -ioctl (2009-10-15)
    [ 0.879745] HDMI TX SW Version:5.3 compatibility:0
    [ 1.905685] hdmi EDID received
    [ 1.905715] tmdlHdmiTxGetEdidSourceAddress 3813
    root@bonelt:# dmesg | grep -i tx
    [ 0.424911] musb-hdrc: ConfigData=0xde (UTMI-8, dyn FIFOs, bulk combine, bulk split, HB-ISO Rx, HB-ISO Tx, SoftConn)
    [ 0.425781] musb-hdrc: ConfigData=0xde (UTMI-8, dyn FIFOs, bulk combine, bulk split, HB-ISO Rx, HB-ISO Tx, SoftConn)
    [ 0.650437] hdmitx(tda19989) 1.3.0 compiled: Nov 30 2012 11:44:35 -ioctl (2009-10-15)
    [ 0.824088] Setting E_REG_P12_TX3_RW
    [ 0.879745] HDMI TX SW Version:5.3 compatibility:0
    [ 1.028087] Setting E_REG_P12_TX3_RW
    [ 1.905715] tmdlHdmiTxGetEdidSourceAddress 3813
    [ 1.905729] Invalid state for function returned in eventCallbackTx line 912
    root@bonelt:    #

  6. joelagnel commented on Nov 30, 2012

    @joelagnel
    joelagnel
    on Nov 30, 2012
    Collaborator

    I will send a da8xx-fb patch for clocks , which is a hack in a while. if
    you could test, would be nice

    On Fri, Nov 30, 2012 at 10:13 AM, Koen Kooi notifications@github.comwrote:

    I get "no signal" on my monitor with the current code.

    —
    Reply to this email directly or view it on GitHubhttps://github.com//issues/9#issuecomment-10894370.

  7. RobertCNelson commented on Nov 30, 2012

    @RobertCNelson
    RobertCNelson
    on Nov 30, 2012
    Member

    jadonk: the easiest i've found, just create a "3.7" milestone and just tag the bug report with that milestone...

  8. koenkooi commented on Dec 7, 2012

    @koenkooi
    koenkooi
    on Dec 7, 2012
    Contributor

    With the latest patches I still can't get it to work. In the DT:

                        disp-pll = <371000000>;
                    panel-type = "nxp-1280x720@60";

    In drivers/video/da8xx-fb.c:

                .name = "nxp-1280x720@60",
            .width = 1280,
            .height = 720,
            .hfp = 109, // 20
            .hbp = 219, // 54
            .hsw = 39,
            .vfp = 5,
            .vbp = 19,
            .vsw = 5,
            .pxl_clk = 74250000,

    In drivers/video/nxp/tda998x.c:

    static struct omap_video_timings video_1280x720at60Hz_panel_timings = {
    .x_res = 1280,
    .y_res = 720,
    .pixel_clock = 74250,
    #ifdef ZOOMII_PATCH
    .hfp = 70,
    .hbp = 260,
    #else
    .hfp = 110,
    .hbp = 220,
    #endif
    .hsw = 40,
    .vfp = 5,
    .vbp = 20,
    .vsw = 5,
    };

    So both the fb and the hdmi driver want a 74.25MHz pixclock, but the DT asks for a 37.1MHz clock. I compared it to the 1024x768 dvi cape DT:

                        disp-pll = <560000000>;
                    panel-type = "1024x768@60";

    And hooked that up to a scope. It shows a 56MHz pixclock. So I changed the hdmi DT to have:

                        disp-pll = <742500000>;

    And I get a nice 74.25MHz pixclock on the scope, fbset reports 720p60, but still the 'no signal' error on my monitor.

    To rule out testing difference: are you using the image that Jason told people to use in the shipment email? If not, could you please try that and replace /boot/uImage with on built from https://github.com/beagleboard/kernel/tree/3.7 using configs/beaglebone as .config?

  9. koenkooi commented on Dec 7, 2012

    @koenkooi
    koenkooi
    on Dec 7, 2012
    Contributor

    I redid the steps to update it to 74.25MHz and I don't get a nice 74.25MHz signal on my scope. I'm not sure what it is but looks awful :)

  10. koenkooi commented on Dec 7, 2012

    @koenkooi
    koenkooi
    on Dec 7, 2012
    Contributor

    Also, why are most of the timings off-by-one between da8xx and tda998x?

  11. joelagnel commented on Dec 7, 2012

    @joelagnel
    joelagnel
    on Dec 7, 2012
    Collaborator

    Hi Koen,

    disp-pll is not the same as pixclk, disp-pll is the input provided to the
    LCDC module from the PRCM. It is an internal PLL in the PRCM that is
    divided down by LCDC. So disp-pll has to be at that high value and we
    divide it down.

    These values were carefully calculated so changing them wont help, as the
    divded down clock has to be very accurate otherwise the NXP device doesn't
    show an image 74.25 cannot be 75.5, it is very particular about these
    values.

    You should see a 74.25MHz clock signal leaving the current disp-pll as it
    is. Can you dump what the 'div' value is in da8xx-fb.c after the divison is
    done? And then manually do the disp-pll / pixclk division yourself in a
    calculator, and see if the values match?

    Thank you for helping test this.

    On Fri, Dec 7, 2012 at 3:45 AM, Koen Kooi notifications@github.com wrote:

    000

  12. joelagnel commented on Dec 7, 2012

    @joelagnel
    joelagnel
    on Dec 7, 2012
    Collaborator

    Also, please share what board revision you're using. Old boards had
    hdmi connector mods done which shouldn't show any signal.

    Also, could you try another monitor?

    On Fri, Dec 7, 2012 at 2:30 PM, Joel A Fernandes agnel.joel@gmail.com wrote:

    Hi Koen,

    disp-pll is not the same as pixclk, disp-pll is the input provided to the
    LCDC module from the PRCM. It is an internal PLL in the PRCM that is divided
    down by LCDC. So disp-pll has to be at that high value and we divide it
    down.

    These values were carefully calculated so changing them wont help, as the
    divded down clock has to be very accurate otherwise the NXP device doesn't
    show an image 74.25 cannot be 75.5, it is very particular about these
    values.

    You should see a 74.25MHz clock signal leaving the current disp-pll as it
    is. Can you dump what the 'div' value is in da8xx-fb.c after the divison is
    done? And then manually do the disp-pll / pixclk division yourself in a
    calculator, and see if the values match?

    Thank you for helping test this.

    On Fri, Dec 7, 2012 at 3:45 AM, Koen Kooi notifications@github.com wrote:

    000

  13. koenkooi commented on Dec 11, 2012

    @koenkooi
    koenkooi
    on Dec 11, 2012
    Contributor

    Revision A1

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

Labels

bug

Type

No type

Projects

No projects

    Milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions