GPIO2_IO23 gpio_request always returns error value EBUSY(16)

[dilshad_alam]

I am using GPIO_IO23 for WL_RST_PIN pin which is used for Resetting the WLAN chip.

GPIO_IO23 is defined in imxdl-pinfunc.h

#define MX6QDL_PAD_SD4_DAT5__GPIO2_IO13             0x354 0x73c 0x000 0x5 0x0

Defined this pin in my dts file under Hog group.

  hog {

  pinctrl_hog_1: hoggrp-1 {

  fsl,pins = <

MX6QDL_PAD_SD4_DAT5__GPIO2_IO13 0x0f0b0 /* WIFI_ON (reset, active low) */

My Target is based on Wandboard design. So I refered Wandboard DT which has below configuration.

MX6QDL_PAD_EIM_A25__GPIO5_IO02 0x0f0b0 /* WIFI_ON (reset, active low) */

and changed GPIO5_IO02 to GPIO2_IO13.

Used this pin in rfkill node.

wifi-rst-n = <&gpio2 13 0>;

static int wand_rfkill_wifi_probe(struct device *dev,

  struct device_node *np,

  struct wand_rfkill_data *rfkill)

{

  int ret;

  int wl_rst_n;

  wl_rst_n = of_get_named_gpio(np, "wifi-rst-n", 0);

  if (!gpio_is_valid(wl_rst_n))

  pr_info("Dilshad %s incorrect wifi gpios\n",__func__);

  dev_info(dev, "initialize wifi chip\n");

  ret=gpio_request(wl_rst_n, "wl_rst_n");

  dev_info(dev, "gpio request return value %d\n", ret);

  gpio_direction_output(wl_rst_n, 0);

  msleep(11);

  gpio_set_value(wl_rst_n, 1);

I got below Kernel logs:

[    0.318338] wandboard-rfkill rfkill.30: initialize wifi chip

[    0.318352] wandboard-rfkill rfkill.30: gpio request return value -16

Error code 16 signifies to BUSY..

Also Let me know what does 0x0f0b0  signifies.

Please tell me if i am missing anything.

[dilshad_alam]

Request someone from Freescale to Look into this?

Prompt reply is appreciated.

[dilshad_alam]

Hi,

Can anyone from freescale reply to this thread?

[lategoodbye]

Hi Dilshad,

the error BUSY is usually caused by pinctrl because this pin is already used by another driver (possible with different muxing).

Please look at Linux/Documentation/devicetree/bindings/pinctrl/fsl,imx6dl-pinctrl.txt - Linux Cross Reference - Fre...

for the meaning of 0x0f0b0.

Stefan

[dilshad_alam]

Hi Stefan,

Thanks for your reply.

If you attempt assigned pins to one group in another node. Pinctrl throws error in begining only.

This error is reported when i enabled usdhc4 node as this node also uses muxed functionality SD4_DAT5

[  111.272406] imx6dl-pinctrl 20e0000.iomuxc: pin MX6DL_PAD_SD4_DAT5 already requested by 20e0000.iomuxc; cannot claim for 219c000.usdhc

[  111.284415] imx6dl-pinctrl 20e0000.iomuxc: pin-213 (219c000.usdhc) status -22

[  111.291558] imx6dl-pinctrl 20e0000.iomuxc: could not request pin 213 on device 20e0000.iomuxc

[  111.300090] sdhci-esdhc-imx 219c000.usdhc: Error applying setting, reverse things back

[  121.324833] mmc2: Timeout waiting for hardware interrupt.

Refered the datasheet found this pin can be used for three purpose.

SD4_DATA5 I am not using and UART2_RTSB also i have checked i am not using this functionality also. In that case GPIO2_IO13 should work.

Do you have nay other pointers?

[lategoodbye]

Have you tried to narrow down the problem in the GPIO driver with some pr_info messages ?

[dilshad_alam]

Sorry to say, I dont have much idea on Imx GPIO framework. Could you please suggest code place where I debug this?

[lategoodbye]

Try to start with gpio_request() from drivers/gpio/core.c

[dilshad_alam]

Hi Stefan,

There is no such files core.c under drivers/gpio.

gpio_request() function is defined in gpiolib.c

static int gpiod_request(struct gpio_desc *desc, const char *label)

{

  struct gpio_chip *chip;

  int status = -EPROBE_DEFER;

  unsigned long flags;

  if (!desc) {

  pr_warn("%s: invalid GPIO\n", __func__);

  return -EINVAL;

  }

  spin_lock_irqsave(&gpio_lock, flags);

  chip = desc->chip;

  if (chip == NULL)

  goto done;

  if (!try_module_get(chip->owner))

  goto done;

  /* NOTE:  gpio_request() can be called in early boot,

  * before IRQs are enabled, for non-sleeping (SOC) GPIOs.

  */

  if (test_and_set_bit(FLAG_REQUESTED, &desc->flags) == 0) {

  desc_set_label(desc, label ? : "?");

  status = 0;

  } else {

  status = -EBUSY;

  module_put(chip->owner);

  goto done;

  }

Code has gone into else part.  What we can conlude from here?

If GPIO pin is used by other drivers, Pincntrl throws an error and its easy to identify who is culprit?

But here in this case its simply returning value EBUSY?

As i mentioned in my previous replies, if i enable usdhc4 node which uses SD4_DATA5, Pincntrl framework throws error?

DO you suspect something from Uboot side ?

[lategoodbye]

Maybe you can look at Debugfs interface of pintrcl at /sys/kernel/debug/pinctrl ?

[dilshad_alam]

Hi Stefan,

Can you please try accessing the same pin with your hardware, whether you get same error or not.

Thanks,

Dilshad

[lategoodbye]

I'm sorry but i don't have a i.MX6 board.

Since this is a typical Linux problem, you could try the following mailing lists

http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies​

to figure out what makes GPIO pin EBUSY.