From: Stephen Warren <hidden> Date: 2012-06-14 15:54:22
On 06/14/2012 06:12 AM, Mark Brown wrote:
On Thu, Jun 14, 2012 at 08:31:20AM +0200, Thierry Reding wrote:
quoted
On Wed, Jun 13, 2012 at 03:17:06PM -0600, Stephen Warren wrote:
quoted
quoted
The core of the issue is that:
quoted
quoted
* Tegra30 support is via device tree. * We have an SDIO bus,
and the WiFi device attached to that bus is enumerable. * Since
the WiFi device is enumerable, no node exists in the DT to
represent it. * However, the driver for the WiFi device needs
certain information, such as the reset GPIO ID and perhaps
power GPIO.
quoted
PCI devices are also enumerable and yet they can be matched up
with nodes in the device tree. Perhaps something similar could be
added for the SDIO bus?
This seems to make the most sense - pushing this through the
regulator API is just a bodge.
Yes, that seems reasonable.
Presumably the power GPIO should be a fixed regulator though, since it
is a power control not just a plain old GPIO? That said, the current
driver apparently deals with this as a GPIO already.
The reset GPIO can separately/directly controlled by the WiFi driver
though.
On Thu, Jun 14, 2012 at 23:54:22, Stephen Warren wrote:
quoted
quoted
quoted
The core of the issue is that:
quoted
quoted
* Tegra30 support is via device tree. * We have an SDIO bus, and
the WiFi device attached to that bus is enumerable. * Since the
WiFi device is enumerable, no node exists in the DT to represent
it. * However, the driver for the WiFi device needs certain
information, such as the reset GPIO ID and perhaps power GPIO.
quoted
PCI devices are also enumerable and yet they can be matched up with
nodes in the device tree. Perhaps something similar could be added
for the SDIO bus?
This seems to make the most sense - pushing this through the
regulator API is just a bodge.
Yes, that seems reasonable.
Presumably the power GPIO should be a fixed regulator though, since it
is a power control not just a plain old GPIO? That said, the current driver apparently deals with this as a GPIO already.
The reset GPIO can separately/directly controlled by the WiFi driver though.
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.
---
nvpublic
From: Stephen Warren <hidden> Date: 2012-06-15 15:49:10
On 06/15/2012 12:09 AM, Wei Ni wrote:
On Thu, Jun 14, 2012 at 23:54:22, Stephen Warren wrote:
quoted
quoted
quoted
quoted
The core of the issue is that:
quoted
quoted
* Tegra30 support is via device tree. * We have an SDIO bus, and
the WiFi device attached to that bus is enumerable. * Since the
WiFi device is enumerable, no node exists in the DT to represent
it. * However, the driver for the WiFi device needs certain
information, such as the reset GPIO ID and perhaps power GPIO.
quoted
PCI devices are also enumerable and yet they can be matched up with
nodes in the device tree. Perhaps something similar could be added
for the SDIO bus?
This seems to make the most sense - pushing this through the
regulator API is just a bodge.
Yes, that seems reasonable.
Presumably the power GPIO should be a fixed regulator though, since it
is a power control not just a plain old GPIO? That said, the current driver apparently deals with this as a GPIO already.
The reset GPIO can separately/directly controlled by the WiFi driver though.
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".
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.
From: Franky Lin <hidden> Date: 2012-06-15 16:24:41
On 06/14/2012 11:09 PM, Wei Ni wrote:
I talked with Franky, this power sequence is generally for 4329, so it mean this sequence can be put into the wifi driver.
Hold on. It's generally for 4329. But fullmac supports 4329/4330 along
with USB dongle chips. Also more chips are incoming. I dont think it's a
good idea to add *this* power sequence into brcmfmac.
Franky
On Sat, Jun 16, 2012 at 00:24:41, Franky Lin wrote:
On 06/14/2012 11:09 PM, Wei Ni wrote:
quoted
I talked with Franky, this power sequence is generally for 4329, so it mean this sequence can be put into the wifi driver.
Hold on. It's generally for 4329. But fullmac supports 4329/4330 along
with USB dongle chips. Also more chips are incoming. I dont think it's a good idea to add *this* power sequence into brcmfmac.
Ok we need find other ways for it. Thanks for your comments.
Wei
---
nvpublic