On Thu, 31 Jan 2019 13:17:23 +0100
Ulf Hansson <ulf.hansson@xxxxxxxxxx> wrote:
On Thu, 31 Jan 2019 at 09:20, Robin van der Gracht <robin@xxxxxxxxxxx> wrote:
On Mon, 28 Jan 2019 22:15:23 +0100
Ulf Hansson <ulf.hansson@xxxxxxxxxx> wrote:
BTW, you didn't really answer my earlier question about the TI WiFi
chip. Doesn't you need a special clock for WiFi chip as well? How do
you intend to manage that?
I used an external 32K oscillator (SLOW_CLK) for my wl1271. Other
clocks ware generated on the module.
Right. How do you control that clock? Did you model it as clock via
the common clock framework?
No I didn't. The slow clock (sleep clock) was always 'on'.
I had to supply a 'vmmc-supply' in your wl1271 devicetree node,
which will be used to power on/off the wlan module. The supply should
be a (delayed) GPIO controlled 'fixed-regulator' attached to the
wlan_en pin on the module.
Right, thanks for explaining.
1: Documentation/devicetree/bindings/net/wireless/ti,wlcore.txt
This sounds like a good fit for mmc pwrseq simple. There are already
similar users for it.
Have a look at: /drivers/mmc/core/pwrseq*
If the mmc host driver calls mmc_of_parse() during ->probe(), a pwrseq
instance will be hooked up to it. Once the mmc core tries to power up
the card it will make use of the attached pwrseq for the mmc host in
question.
In this way, you can control the clock and GPIO line, in more exact
ways that is needed by the WiFi chip.
Ack. Makes more sense than using a regulator (even without specifying
'clocks').
Here is a DT example (look for "mmc-pwrseq-simple"):
arch/arm/boot/dts/imx6qdl-sr-som-ti.dtsi
This should do the trick for you. On the other hand, I don't mind that
you still add regulator support to the driver, along the lines of what
$subject patch does, however it may not be exactly what you need for
the WiFi case.
@Martin; What do you think? Will you work this out with Ulf?
Since I can't test this.
Attachment:
smime.p7s
Description: S/MIME cryptographic signature