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.

AM335x LCD 1bpp

Other Parts Discussed in Thread: DA8XX, AM3359, AM3352

Hi TI Team,

I would like to run lcd driver in 1bpp (MONOCHROME) mode on LCD 320x240 (PG320240WRF) with 4-bit output mode.

The driver is da8xx-fb with modifications for support DeviceTree and MONO01 for fb (fb_probe function):

if (da8xx_fb_info->var.bits_per_pixel == 1)
        da8xx_fb_info->fix.visual = FB_VISUAL_MONO01;

PWR pin is managed as gpio and enabled at the driver start.

I have fb settings: continuous memory for fb (32B + 9600B) as palette memory and data.

The palette configuration is as follow (fb_setcolreg function):

    switch (info->fix.visual)
    {
    case FB_VISUAL_MONO01:
        switch (info->var.bits_per_pixel) {
        case 1:
            if (regno > 15)
                return -EINVAL;
            if (regno == 0)
                pal = 0x0000;
            else if (regno == 1)
                pal = 0x000f;
            else
                pal = 0;

After configuration I have regs values:

----- regs -----
0x00 : 0x4f201000
0x04 : 0x0000ba01
0x28 : 0x00080003
0x2c : 0x00000270
0x30 : 0x000000ef
0x34 : 0x00000000
0x40 : 0x00000541
0x44 : 0x8f240020
0x48 : 0x8f24259c
0x4c : 0x8f240020
0x50 : 0x8f24259c
0x58 : 0x00000042
0x5c : 0x00000000
0x60 : 0x00000324
0x64 : 0x00000324
0x68 : 0x00000000
0x6c : 0x00000005
0x70 : 0x00000000

I can see palette values:

----- Memory dump: palette -----
[0xd0873000] 00000f00000000000000000000000000 00000000000000000000000000000000

and data (first bytes) for loaded raw file with "0xff 0xff 0xff 0xff" at the begin, rest of the fb is 0x00:

----- Memory dump: dma -----
[0xd0873020] FFFFFFFF000000000000000000000000 00000000000000000000000000000000
[0xd0873040] 00000000000000000000000000000000 00000000000000000000000000000000

Unfortunatelly, on oscilloscope I see only PCLK, VSYNC, HSYNC without any data for first 32 bits

and in magnification

What shoud I change for see proper view on LCD? What is wrong in configuration?

Thanks in advance,

Rafal

  • Hi,

    I will ask the software team to look at this, but as far as I know the Linux LCD driver supports only RGB32 format: processors.wiki.ti.com/.../Linux_Core_LCD_Controller_User_Guide
  • I have fixed MONO01 support inside my da8xx-fb driver. I dont use console on this fb. Palette settings are from end of function fb_probe(), mainly:
    {
    int i = 0;
    for (i=0; i<=15; i++)
    {
    fb_setcolreg(i, 0,0,0,0, da8xx_fb_info);
    }
    }
    So, palette seems to configured correctly.
    ----- Memory dump: palette -----
    [0xd0873000] 00000f00000000000000000000000000 00000000000000000000000000000000

    Based on TRM, am3359 should support 1bpp mono mode. I have correct configs for fb_0 base and ceiling, so lcdc inside cpu should handle 0xff at the begin on dma memory as 8 pixels ON (1bit -> pixel enabled).

    After few modifications I have regs:
    ----- regs -----
    0x00 : 0x4f201000
    0x04 : 0x0000ba01
    0x28 : 0x00280003
    0x2c : 0x00000530
    0x30 : 0x000004ef
    0x34 : 0x00000000
    0x40 : 0x00000541
    0x44 : 0x8f240020
    0x48 : 0x8f24259c
    0x4c : 0x8f240020
    0x50 : 0x8f24259c
    0x58 : 0x00000002
    0x5c : 0x00000000
    0x60 : 0x00000325
    0x64 : 0x00000325
    0x68 : 0x00000000
    0x6c : 0x00000005
    0x70 : 0x00000000

    So, my test looks like raw managing of am3359 cpu lcd driver in raster mode (without "real" usage of Linux fb driver).

    And with "FFFFFFFF" at the begin of dma memory (begin of fb) I see on osc. "1" on D0 and D1 on 1st clock, so first 2 pixels are enabled.
    But should be "1" on D0..D3 for 8 first clocks (enabled first 32 pixels on LCD).
  • Additional information:

    I try to view raw pixel bitmap (with 1bit=1pixel) on am3359. Mainly, I have binary file with bit map (file size 9600B) with "translation": 1 bit ->1pixel.

    I dont use console on fb.

    Function fb_setcolreg() is call from end of fb_probe() so palette is set by:

        {
            int i = 0;
            for (i=0; i<=15; i++)
            {
                fb_setcolreg(i, 0,0,0,0, da8xx_fb_info);
            }
        }

    Result:

    ----- Memory dump: palette -----
    [0xd0873000] 00000f00000000000000000000000000 00000000000000000000000000000000

     

    Based on TRM lcd gluer in cpu should push every bit from dma memory to D0..D3.

    After some changes inside da8xx-fb.c I see :

    ----- regs -----
    0x00 : 0x4f201000
    0x04 : 0x0000ba01
    0x28 : 0x00280003
    0x2c : 0x00000530
    0x30 : 0x000004ef
    0x34 : 0x00000000
    0x40 : 0x00000541
    0x44 : 0x8f240020
    0x48 : 0x8f24259c
    0x4c : 0x8f240020
    0x50 : 0x8f24259c
    0x58 : 0x00000002
    0x5c : 0x00000000
    0x60 : 0x00000325
    0x64 : 0x00000325
    0x68 : 0x00000000
    0x6c : 0x00000005
    0x70 : 0x00000000

    Test with 32bits:

    With FFFFFFFF at the begin of dma memory (fb begin) I see only "1" on D0 and D1 for first clock (only 2 first pixels on LCD are visible).

    But I should see 32 pixels on LCD.

    I know that Linux supports RGB32 mode, but my test seems to be a raw managing on am3359 lcd.

  • It will be nice to see reference driver (for Linux) for 1bpp in monochrome mode.
  • Hi,

    Have you enabled
    CONFIG_FB_DA8XX=y
    CONFIG_FB_DA8XX_TDA998X=y
    in your tisdk_am335x-evm_defconfig file? Also note that you must disable the DRM configs:
    CONFIG_DRM=n
    CONFIG_DRM_I2C_NXP_TDA998X=n
    CONFIG_DRM_TILCDC=n

    Can you share the relevant dts sections ?

    Best Regards,
    Yordan
  • I'm using Linux Kernel 3.14

    DA8XX is enabled, DRM - disabled (...) so DRM_I2C_NXP_TDA998X is also disabled

    Attached dtsi files for LCD

    dt.zip

    For panel, "compatible" mode is referenced to my da8xx-dt.c implementation, so I can change all paramenters with dtsi file usage (visible in regs).

    Last test shows that for data in dma memory:

    - pushed 1p.bin: "enables" 1 pixel (D0 is "1") - but 4th pixel on LCD is enabled.

    - pushed 2p.bin: "enables" 2 pixel (D1 is "1") - but as 3rd pixel on LCD

    - pushed 3p.bin: "enables" 3 pixel (D2 is "1") - but as 2nd pixel on LCD

    - pushed 4p.bin: "enables" 4 pixel (D3 is "1") - but as 1st pixel on LCD

    Data are pushed to fb0 (cat file_name.bin > /dev/fb0) as binary files created with hex editor (files attached).

    bin.zip

    All pixels were enabled for line 2, but on oscilloscope it was for 1st clock after VSYNC up (attached picture for 4p.bin - 4p.jpg)

    Based on palette configuration - am3359 should push data as described in TRM (spruh73m.pdf) Fig.13-13 in 4-bit output mode.

    But test shows that am3359 is not in 1bpp monochrome mode (....)

    Regs:

    ----- regs -----
    0x00 : 0x4f201000
    0x04 : 0x0000ba01
    0x28 : 0x00280003
    0x2c : 0x00000530
    0x30 : 0x000004ef
    0x34 : 0x00000000
    0x40 : 0x00000541
    0x44 : 0x8f23c020
    0x48 : 0x8f23e59c
    0x4c : 0x8f23c020
    0x50 : 0x8f23e59c
    0x58 : 0x00000002
    0x5c : 0x00000000
    0x60 : 0x00000325
    0x64 : 0x00000325
    0x68 : 0x00000000
    0x6c : 0x00000007
    0x70 : 0x00000000

    BR,

    Rafal

  • Any comments from TI Software Team?

  • Hi,

    Could you try with a different setting of your panel dts node. Currently I see, that you use
    compatible = "ti,da8xx_dt,panel";
    Could you change this to:
    compatible = "ti,tilcdc,panel";
    and give it a try?

    Also what happens if you hardcode the lcdc registers in da8xx-fb.c using __raw_writel() in the case where you want to set lcdc to 1bpp monochrome mode? Do the settings apply to device registers?

    Best Regards,
    Yordan
  • Hi,

    Thanks for fast response...
    Almost all configuration have beed checked by me, also with 'compatible = "ti,tilcdc,panel"' - without effect.
    The configuration 'compatible = "ti,da8xx_dt,panel"' means that I use my dt implementation for da8xx. And I see correctly set registers with my "dt" file.

    Based on infos above:
    Register 0x28 is equal 0x00280003, so: lcden=1, lcdbw=1, reqdly=0x80, palmode=0x20 (data loading only)
    It means that am3359 should work in monochrome mode.

    For fb & palette I have allocated continuous memory block (32B+9600B)
    Palette dump is equal: [0xd0873000] 00000f00000000000000000000000000 00000000000000000000000000000000 ("bye-by-byte" view).
    It means that 1st 16b word = 0x0000, 2nd 16b word = 0x000f.
    Based on TRM (spruh73m.pdf) 'Figure 13-6' and '13.3.6.2 Frame Buffer': for 1st palette word -> BPP=0x00, Mono(M)=0x00, for next -> Mono(M)=0x0f.
    Rest words = 0 ("1-BPP mode uses the first 2 entries in a palette while 2-BPP mode uses the first 4 entries. The remaining entries are not used and must be filled with 0.").
    It means that am3359 should work in 1bpp mode.

    DMA registers look OK (You can see 0x20 offset for palette, and size equal 9600B)
    0x44 : 0x8f23c020 (32B offset for palette)
    0x48 : 0x8f23e59c (fb size:9600B)
    0x4c : 0x8f23c020
    0x50 : 0x8f23e59c

    The am3359 should push data as described on Fig.13-13 in 4-bit output mode.

    With 0xffffffff inside fb, on oscilloscope I see only "1" on 2 lines for first clock (only 2 pixels on LCD are visible). But I should see 32 pixels !!!
    Of course "1" on D3 -> 1st pixel enabled, "1" on "D2" -> 2nd pixel and so on (based on LCD manual). Its OK.

    Next, I have implemented some translation layer inside fb (fb_write) with feature:
    for every bit "1" for input data (*buf) I set 0x000f inside fb memory, for every bit "0": 0x0000.
    So, I translate 1b->16b. Allocation of fb is equal 16*9600+32 (da8xx-fb.c).
    And with this I see proper view on my LCD. It means that am3359 still works in RGB mode, needs 2B for 1 pixel.

    Please, describe how should I set lcd registers, palette etc. to enable 1bpp for monochrome mode.
    It will be nice to see some reference C implementation.

    BR,
    Rafal
  • Even a short corrigendum - I use am3352 (...)

  • Rafal BARANSKI said:
    0x28 : 0x00280003

    RASTER_CTRL[21:20] PALMODE is programmed to a value of 2, which means "data only" and "no palette lookup".  It looks like the driver (drivers/video/fbdev/omap/lcdc.c) has code related to load_palette().  Have you verified that the palette is being loaded (i.e. that the code is executing and has the proper addresses programmed)? 

    I've spent quite a bit of time looking through all your registers and that's the only thing I have come up with that might remotely explain what you're seeing.  In particular, if the palette was not loaded properly then there would not be any palette lookup happening, and that would explain why you're not seeing one bit turned into many like you're expecting.

    Can you add a bit of instrumentation to dump out the registers before after you load the palette?  I think it's worth exploring that a little deeper.

  • Good news. We were able to get this working with the help of some of my colleagues. Key findings were:

    1. Continuous allocated memory for palette and data (32B+9600B) for 320x240 mono lcd (1bpp)
    2. dma_start=”start of memory”, dma_end=”end of memory”
    3. support for PALETTE_AND_DATA mode in ‘lcd_blit’ function (da8xx-fb.c)
    4. only PALETTE_AND_DATA mode used (during load palette and also data)
    5. fixed values for fb e.g. screen_base, fix.smem_start etc. as: dma_start+32

    Thanks for your patience in getting to resolution!