On Tue, Jun 19, 2012 at 09:23:35, Philip Rakity wrote: >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 Yes, we can use the regulator notify, but the Tegra30 support is via device tree, I think there have no special board file to run the call back. > > >________________________________________ >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-wireless" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
