AM57x GPIO Driver configuration flag raises the GPIO number

Tim,

Thanks for the feddback! Let us say you want to configure GPIO port A, pin B. In the Linux driver, this is already configured. So in your RTOS DSP code, you used "GPIO_DO_NOT_CONFIG" to avoid the reconfiguration.

I looked at the driver code fro AM57x GPIO, it calls into GPIO_init_v1(), then there is a check:

if ((GPIO_v1_config.pinConfigs[i] & GPIO_DO_NOT_CONFIG) !=

GPIO_DO_NOT_CONFIG) {

GPIO_setConfig_v1(i, GPIO_v1_config.pinConfigs[i]);

}

If above is true, then GPIO_setConfig_v1 is called and pinNum is extracted from pinConfigs and used, there is no pinNum increments.

If above is false (your skip case), the GPIO_setConfig_v1 is not called. There is no operation to change pinNum.

Can you explain how do you find " raise of the pin number by one"? The pinNum is provided to the driver from application by the GPIO_v1_config.pinConfigs structure, how it increases by one?

Regards, Eric

Hi Eric,

  there is no conditionally executed code that raises the pin number, its the GPIO_DO_NOT_CONFIG 'flag' itself that raises it - at least if the pin number is even.

The mask for the pin number is 0x000000FF, the GPIO_DO_NOT_CONFIG 'flag' is 0x7FFF0001. So by setting GPIO_DO_NOT_CONFIG the LSB in the pin field is set. If the pin number was even it is now raised by one.

Sorry for the sloppy description.

Best,

       Tim

Eric,

  thanks for clarifying that! Then it's maybe more of a documentation issue.

From the in-code comment:

'Use this GPIO_PinConfig definition to inform GPIO_init() NOT to configure the corresponding pin'.

I assumed 'the corresponding pin' meant an already configured port/pin combination and the macro has to be ORed into the pinconfig. In regard to your explanation this wording is IMHO a bit misleading.

The scenario I had in mind was when you want to initialize the gpio driver with a certain set of pin configs for later use but you don't want to interfere with it's output states at driver initialization time. This can  be useful in multicore systems where the hardware initialization is already done by some other core, for example the one that was booted first.

I like the Idea to have the initialization of the driver and its data structures and the initialization of the underlying hardware independently controllable. Maybe pinwise and/or globally. That wouldn't need another init function, a flag set at init time would be enough. Just my 2cents.

But there is another problem with that explanation. If the bit combination 0x7FFF0001 results to a pinconfig with invalid port (0) the then valid port number 8 would result in a out of bounds write into the portCfgDone array. It's on the stack and if it's compiled with no optimization it would result in a unintended write into pinConfig. But if it is compiled with optimization anything can happen. 

Another problem arises if following your advice GPIO_DO_NOT_CONFIG is used as sole content of a pinconfig. It would result in an attempt to call GPIOModuleEnable() (GPIO_v1.c:289) with an invalid base address.

Thanks again for clarifying,

             Tim

Eric,

  thanks for the ACK and sorry for being annoying ;). I'm new to the RTOS SYS/BIOS world and normaly we have a grip of the whole code down to the hardware. So I think I take more often a look under the hood than the average user...

Regarding the ticket - am I right assuming your bug tracker is an internal one and the forum is the standard way to escalate a bug? Or is there a shortcut so I don't have to bother you?

Best,

       Tim

Tim,

You looked details into our driver code and found those issues! Thanks very much! Yes, the ticket is internal by default in our tracking system and E2E forum is where you report issues.

Regards, Eric