• State Resolved
  • Locked Locked
  • Replies 4 replies
  • Subscribers 97 subscribers
  • Views 784 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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.

bsp_padcfg, OAL and request/configure mechanism in the AM35x_BSP

Hannes Brockmann
Prodigy 90 points
Other Parts Discussed in Thread: AM3517

Hi,

I have a question related to the request/configure mechanism in the AM35x_BSP.

Our am3517 system has 2 screens ( DVI,LCD ) driven from the DSS video Interface.
Switching between the screens shuld be done by several gpios.

I use an animated logo in eboot, so I have made the required changes in lcd_support.c an lcd_vga.c

That is already working fine.

While further booting screen flickers.

So far I located the problem in OALLIB\init.c -> configure pin mux
Here are the calls
1.) ConfigurePadArray(BSPGetAllPadsInfo());
and
2.) ConfigurePadArray(BSPGetDevicePadInfo(OMAP_DEVICE_DSS));

in bsp_padcfg.h I found:
#define ALL_ALLOWED_PADS \ ... PAD_ENTRY(DSS_DATAxx,RELEASED_PAD_DEFAULT_CONFIG) \
and
#define DSS_PADS  \ ... PAD_ENTRY(DSS_DATAxx,INPUT_DISABLED| MUXMODE(0)) \

With the first  call data lines are switched back into input state,
so data signalling to the screens is stopped.

With the second call data lines are switched back into the correct state,
so data signalling will go on.

So it must flicker.

Now the questions:
------------------

- Can some one explain to me what means "ALL_ALLOWED_PADS" in bsp_padcfg.h
  ( for me it's like most safe mux configuration? )

- If I use a pad as a GPIO only - has it to be defined in the #define GPIO_PADS group
  or ( because it is used for display control ) in the #define DSS_PADS group?

- I know the Backlight is ON (signal must be 1)

  Trying to debug the GPIO-state at the end of OEMinit:
    g_hGPIO = GPIOOpen();
    RETAILMSG(1,(TEXT("LCD_BACK_ON=%d\r\n"),GPIOGetBit(g_hGPIO,LCD_BACK_ON)));
    GPIOClose(g_hGPIO);
  I got
    LCD_BACK_ON=0

  So what could be wrong?

advanced thanks,

Hannes


 

  • 0
    Mastermind 9310 points

    To reply to your questions one by one:

    - ALL_ALLOWED_PADS is indeed the default safe configuration for all pins. It is also checked whenever one make a call to the PAD requesting functions, that will first check the pad is defined in this list before operating any configuration on it. Requesting a pad not defined in ALL_ALLOWED_PADS will have pad request mechanism return FALSE.

    - The GPIO_PADS list is indeed intended to host pads that are only used as GPIOs and don't belong to any specific controller. Note that their pad configuration will be done at OAL initialization under OEMInit

    - I guess you double checked your pad configuration for this pin (don't forget INPUT_ENABLE), but there could be another reason for that. If you configured your GPIO as an output (did you call GPIOSetMode?), then you might not be able to use GpioGetBit to read data from this pin. Indeed the GpioGetBit function will read the DATAIN register which is only relevant to GPIO configured as inputs, DATAOUT being the equivalent to read the state of the output. To workaround this limitation in your case, you might need to rewrite the GPIO library or direcly read DATAOUT for your pin instead of using GpioGetBit

  • 0 in reply to Adeneo Embedded support team
    Prodigy 90 points

    Thank You for Your answer.

    So that means, if I use a GPIO for video output control ( turn on/off LCD backlight ) only, I have to declare it together wit the DSS-pads in the DSS_PADS group?

    And one other related quesstion:

    If I already have configured the pinmux and default values of these pins at the bootloader level -  do I have to do that once again in OEMinit -

    OALGPIOSetDefaultValues()?

    Hannes

     

  • 0 in reply to Hannes Brockmann
    Mastermind 9310 points

    If your GPIO is intended to work with you video output, then it might make sense to define it in DSS_PADS. However the mux configuration for DSS_PADS will only be done at initialization of the display driver, which means you should not be able to use your GPIO beforehand.

    If you already configured the pinmux in the bootloader, you might indeed not need to to do it again in the kernel. However this framework also implements a request mechanism that would prevent any other driver from requesting the same pads you already requested. This helps a lot with avoiding pad conflicts between drivers.