GPIO port definition in devicetree

[Dmitry Kr]

Dear Nordic, 

Could you please help me to understand the concept of using the DTS files and board initialization sequence?

We have just one GPIO port to control some external ICs on the board. It should be set to HIGH state when the peripheral is on use and go to LOW when device is in low-power state.

For now, port is controlled by mockup code: 

const struct device *gpio_dev;

void pwrct_sf_init()
{
gpio_dev = device_get_binding("GPIO_1");
/* Set power control pin as output */
gpio_pin_configure(gpio_dev, 9, GPIO_OUTPUT_LOW | GPIO_ACTIVE_HIGH); //p1.09 == LDO_EN active high
}

#if 1

void pwrct_sf_on()
{
gpio_pin_set(gpio_dev, 9, 1); 
}

void pwrct_sf_off()
{
gpio_pin_set(gpio_dev, 9, 0); 
}

How we should define it in DTS (e.g. like leds section) to make it defined clearly (port & pin number, active state, label should be defined in DTS).

Is there a way to add calls to this port on / off to particular functions related to SPI init / deinit and QSPI init / deinit?

[Dmitry Kr]

Hi Sigurd, 

Checking that code: https://github.com/nrfconnect/sdk-zephyr/blob/e4f87fba1b8785dcdcd1a3872e592bd7f7b53039/tests/lib/onoff/src/main.c

I've found that there was reset_client() function called before the every call to regulator_enable().

That reset_client() function clears onoff_client structure and reinstalls callback binding. 

Is it a right way to use regulator_enable API function?

[Sigurd]

Dmitry Kr said:

Is it a right way to use regulator_enable API function?

 Looking at the description of sys_notify_init_callback: , 

 * On completion of the operation the client object must be
 * reinitialized before it can be re-used.

it seems like the client object must be reinitialized, yes.