Bluedroid_pm pins in M.2 E

Hi,

This is the question for PINMUX setting for bluedroid_pm pins if I want to disable bluedroid_pm. I originally posted my question in the topic of other user here:

But @WayneWWW told me to file a new topic for my issue. Therefore, I am creating a new topic here.

I am designing my own carrier for Xavier, I want to disable bluedroid_pm. I have commented out the bluedroid_pm node in device-tree. But how should I set the pinmux for reset-gpio, host-wake-gpio, and ext-wake-gpio in pinmux table? (Note that I copied the devkit schematic for M.2 E key exactly which means those bluedroid_pm pins are copied from devkit schematic as well.)

  1. reset-gpio connects to W_DISABLE2# (pin 54) of M.2 E. I think it is for enabling BT function of wireless chip on that M.2 E, correct? So, I should set pinmux in GPIO output “drive 1” state, correct?
  2. ext-wake-gpio connects to VENDOR_DEFINED (pin 38) of M.2 E. Is it for Xavier to wake the wireless chip? Should I set pinmux in GPIO output “drive 1” state? Note that the current Xavier devkit pinmux table already sets it to output “drive 1” state.
  3. host-wake-gpio connects to UART_WAKE# (pin 20) of M.2 E. Is it for wireless chip to wake Xavier from deep sleep mode? Should I set pinmux in GPIO input with Pull-up state?
  4. Are most of M.2 E wireless chips compatible with this pin setting on M.2 E? Especially, for ext-wake where it is connected to VENDOR_DEFINED pin on M.2 E, which seems has high chance of vendor dependency.
  5. I briefly went thru kernel/nvidia/drivers/misc/bluedroid_pm.c driver. Is it in standard upstream linux kernel? Or it is something specific in L4T kernel? I couldn’t find the bluedroid_pm driver in upstream kernel. I even couldn’t find the device-tree binding in upstream kernel.

Regards.

Hi,

If you want to set the status of each gpio, you need to write gpio-hog as below case in device tree. Under gpio@c2f0000.
This was one of a patch to control W_DISABLE2 on NX. You can write similar things for Xavier case.

+		w-disable1 {
+			gpio-hog;
+			output-high;
+			gpios = <TEGRA194_AON_GPIO(CC, 2) GPIO_ACTIVE_LOW>;
+			label = "w-disable1";
+			status = "okay";
+		};
+		w-disable2 {
+			gpio-hog;
+			output-high;
+			gpios = <TEGRA194_AON_GPIO(CC, 0) GPIO_ACTIVE_LOW>;
+			label = "w-disable2";
+			status = "okay";
+		};

Hi,

Thanks for your reply.

I can see that gpio-hog enables wifi and bluetooth. And it enables BT by set reset-gpio to 1 which confirms my question “1”.

But How about the ext-wake-gpio and host-wake-gpio pins? Shall I set ext-wake-gpio GPIO to output drive 1? And host-wake-gpio to GPIO input with PU? Can you please confirm this?

Also, would setting the MB1 pinmux table good enough for setting the default state of pins, if I don’t have the pin referenced in device-tree? For example, if I set GPIO11 in GPIO mode and output “drive 1” state in pinmux and NOT have it referenced/used in device-tree. Will GPIO11 keep in output “drive 1” state after linux boot up? Or it will be reset to some default state (input or output drive 0) by kernel? I think it shouldn’t be touched/changed by kernel because there it no device-tree reference to that GPIO. So, kernel even doesn’t know that GPIO is there. Unless, tegra GPIO driver resets all GPIOs to some default state (e.g. input or output 0)!

Regards.

Just keep default pinmux setting on ext-wake-gpio and host-wake-gpio pins.

Hi,

  1. Default pinmux setting for ext-wake-gpio is output “drive 1” which makes sense. However, the default pinmux setting for host-wake-gpio (pin F55) is unused which make no sense. Shall I set it to GPIO input with PU in pinmux?
  2. Can you please confirm that setting the pinmux is good enough for setting the GPIO state? For example, if I have a GPIO set as output “drive 1” state in pinmux table, and there is NO device-tree binding for that GPIO, that GPIO will be kept in output “drive 1” state after Linux started, until shutdown, correct?

Thanks.

I think you can just give it a try. If the gpio state is not correct, do as I said to hog it in device tree.