lkml.org 
[lkml]   [2018]   [Nov]   [1]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
Date
SubjectRe: [RFC PATCH 7/7] arm64: allwinner: h6: orangepi-liet2: Enable AP6356S WiFi support
On Thu, Nov 1, 2018 at 5:08 PM Jagan Teki <jagan@amarulasolutions.com> wrote:
>
> On Thu, Nov 1, 2018 at 1:28 PM Chen-Yu Tsai <wens@csie.org> wrote:
> >
> > On Thu, Nov 1, 2018 at 3:35 PM Jagan Teki <jagan@amarulasolutions.com> wrote:
> > >
> > > On Thu, Nov 1, 2018 at 12:07 AM Jagan Teki <jagan@amarulasolutions.com> wrote:
> > > >
> > > > From: Jagan Teki <jagan@openedev.com>
> > > >
> > > > Enable AP6356S WiFi/BT combo chip on Orangepi Lite2 board:
> > > > - WiFi SDIO interface is connected to MMC1
> > > > - WiFi WL-PMU-EN pin connected to gpio PM3: attach to mmc-pwrseq
> > > > - WiFi WL-WAKE-AP pin connected to gpio PM0
> > > > - 32kHz external oscillator gate clock from RTC
> >
> > You never specified a clock rate for it, so it might actually be wrong.
> > The default clock rate would be something "around" 32 kHz, but not very
> > accurate. Meanwhile the WiFi module would have very specific requirements
> > on frequency and accuracy of this clock. The WiFi part doesn't seem to
> > care that much, but the Bluetooth part cares very much. It doesn't work
> > or it would seem to work but you don't get anything off the radio if the
> > frequency is off (as in off-frequency).
>
> True, but why it's not 32K which is stated in manual and schematics do
> we need to measure the actual rate with oscilloscope?

I suppose it's just shorthand. The datasheet describes the actual requirements
for both oscillators, where it clearly states the 32K one should be 32768 Hz.
A scope shouldn't be needed as we expect the board design to at least conform
to constraints outlined in datasheets.

On the side, the LOSC be _around_ 32kHz if you clocked it from the internal
RC oscillator, which is not very stable. This is actually the hardware default.
But the WiFi module (and also the RTC) needs 32.768K, a slight difference,
but enough to throw off calculations for other clocks. When the RTC module
isn't clocked from the external crystal, the RTC clock will drift. This has
been reported and is why we have

/* Switch to the external, more precise, oscillator */
writel(SUN6I_LOSC_CTRL_KEY | SUN6I_LOSC_CTRL_EXT_OSC,
rtc->base + SUN6I_LOSC_CTRL);

in the RTC driver's clock probe function. See these two patches:

fb61bb82cb46 rtc: sun6i: Switch to the external oscillator
3855c2c3e546 rtc: sun6i: Expose the 32kHz oscillator

Note the commit message for the second patch is incorrect. We actually force
the RTC module to use the external crystal regardless of the "clocks" property.

I actually forgot about this. So even without assigning clock rates your patch
would work fine. Hope this doesn't confuse you more than it already has.

ChenYu

> > > > Signed-off-by: Jagan Teki <jagan@openedev.com>
> > > > ---
> > > > Note:
> > > > - chip detected, but failed to connect
> > > > [ 129.084504] brcmfmac: brcmf_sdio_hostmail: mailbox indicates firmware halted
> > > > [ 135.906409] brcmfmac: brcmf_sdio_bus_rxctl: resumed on timeout
> > >
> > > This got fixed. Will send next version.
> >
> > Could you wait until I get my RTC changes out? I also have some Bluetooth
> > patches for AP621x, which is what started all this RTC work, which you might
> > find interesting.
>
> Yes, my intention is the same.

\
 
 \ /
  Last update: 2018-11-01 10:49    [W:0.056 / U:1.008 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site