Why can't you use the regulator notify to get called back on power or voltage change options to plumb in the manipulation of the gpio. I can imagine you might need to add a notify call in core.c if you need to assert the gpio before power is applied ________________________________________ From: linux-mmc-owner@xxxxxxxxxxxxxxx [linux-mmc-owner@xxxxxxxxxxxxxxx] On Behalf Of Wei Ni [wni@xxxxxxxxxx] Sent: Sunday, June 17, 2012 11:20 PM To: 'Stephen Warren'; Rakesh Kumar Cc: Mark Brown; 'frankyl@xxxxxxxxxxxx'; Thierry Reding; Mursalin Akon; 'linux-mmc@xxxxxxxxxxxxxxx'; devicetree-discuss@xxxxxxxxxxxxxxxx; 'linux-wireless@xxxxxxxxxxxxxxx'; linux-tegra@xxxxxxxxxxxxxxx; linux-arm-kernel@xxxxxxxxxxxxxxxxxxx Subject: RE: Where to power on the wifi device before loading the driver. On Fri, Jun 15, 2012 at 23:49:10, Stephen Warren wrote: >> I talked with Franky, this power sequence is generally for 4329, so >> it mean this sequence can be put into the wifi driver. >> We can use the virtual platform device both for OOB and non OOB. >> I will send out patches later. > >Can you please expand on what a "virtual platform device" is; device tree typically represents real hardware rather than anything "virtual". The "virtual platform device" is created before the real wifi device, so that it can pass the gpios to the driver, and power up the device before calling sdio_register_driver. But as Franky said, this power sequence is only generally for 4329, not for the USB dongle chips. So it's not a good idea to add this "power up" in brcmfmac. > >Now if this means adding a child node under the SDIO controller to represent the attached device, and storing any settings required by that device in that child node, that's probably a reasonable basic approach. > >BTW, which GPIO is the power GPIO; is it WF_EN on the schematic? That seems reasonable to represent as a GPIO rather than a regulator since it connects directly into the WiFi device as a GPIO, and its use within the WiFi device can indeed be governed purely internally to the WiFi driver/HW. However, if this is some GPIO that controls the power to e.g. >VBAT3V3_IN_WF, VDDIO_WF, or other power supply to the WiFi card, then it'd be better represented as a regulator, since the control point is outside the WiFi device. I think Rakesh may can answer this. Wei. --- nvpublic -- To unsubscribe from this list: send the line "unsubscribe linux-mmc" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
