Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
Date:   Fri, 8 May 2020 13:30:12 +0200
From:   Jorge Amoros-Argos <joramar76@gmail.com>
To:     Hauke Mehrtens <hauke@hauke-m.de>
Cc:     linux-kernel@vger.kernel.org, john@phrozen.org,
        martin.blumenstingl@googlemail.com, rahul.tanwar@intel.com,
        linux-clk@vger.kernel.org
Subject: Re: clk: Lantiq/Intel: XWAY CGU support
Message-ID: <20200508133012.000000f2@gmail.com>
In-Reply-To: <743865de-c69c-836c-a74f-f50ccaaed9b3@hauke-m.de>
References: <20200404105309.0000745d@gmail.com>
        <743865de-c69c-836c-a74f-f50ccaaed9b3@hauke-m.de>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

El Wed, 15 Apr 2020 00:00:20 +0200
Hauke Mehrtens <hauke@hauke-m.de> escribi=F3:
> On 4/4/20 10:53 AM, Jorge Amoros-Argos wrote:
> > Dear community,
> >=20
> > This is addresed to the Lantiq/Intel developers for the SoC's
> > VRX200 and XWAY in general.
> >=20
> > I'm trying to port the current sources to the common clock
> > framework for Openwrt. =20
>=20
> Thanks for looking into this. this SoC should really be converted to
> the common clock framework.
>=20
>=20
> > For this purpose, I'd need to have a good knowledge of both clock
> > providers and consumers in order to update the device tree and also
> > the drivers. This means hardware (how devices are connected) and
> > software (what registers do what?)
> >=20
> > There's no such low level detail after all my investigations, which
> > are shown here:
> >=20
> >      https://github.com/Mandrake-Lee/Lantiq_XWAY_CGU
> >=20
> > For instance, the full structure of PLL2 register remains a mistery
> > and also its output; OCP selector, is a kind of divider?; PCIe
> > generator is located where? PMU, is just a gate controller or a
> > provider itself?
> >=20
> > I'd really appreciate if you could share some details in order to
> > start the job. =20
>=20
> A common clock framework driver for the Lightning Mountain(LGM) SoC is
> currently being reviewed on the upstream mailling list:
> https://lkml.org/lkml/2020/3/24/4
> there could still be some similarities between the VRX200 and the LGM,
> but there are some generations in between and with the xrx500 many
> registers in the CGU block changed.
>=20
> Martin started to write a driver some years ago:
> https://github.com/xdarklight/linux/commits/lantiq-clk-20160620
> But this does not really models the clock tree.
>=20
> Be aware that the clock tree is not so simple, it has a lot of
> dividers.
>=20
> Hauke
>=20
>=20

Dear Hauke and friends,

Based on some forsaken sources for linux and uboot, I have managed to
re-create most of the clock layout of the Lantiq VR9.

With this information I've been able to modify the device tree
structure and create a minor set of drivers in order migrate to CCF.

The code is now available at:
	https://github.com/Mandrake-Lee/openwrt/tree/LTQ_PORTING_CLK_FRAMEWORK

Also, I've tried to gather all relevant information with references
here:
	https://github.com/Mandrake-Lee/Lantiq_XWAY_CGU

There's also a fancy schematic:
	https://github.com/Mandrake-Lee/Lantiq_XWAY_CGU/blob/master/VR9_CGU_v0_202=
00503.pdf

Unfortunately the status so far is UNSTABLE although I have the feeling
that we must be very close to the end.

The boot-up logging is mostly standard but right after kernel modules
are loaded and eth driver detects a link, the system hangs-up and
reboots after 30s roughly. There's no log message at all.

There're still some seconds where a terminal is operative though, so I
guess there's a module loading that crashes without trace.

So any help and comments are really appreciated.

In parallel, the only big "black box" that remains is the PCIe PLL
register meaning. I would appreciate if someone from Lantiq (now Intel)
could give a hand.

Best regards,
Jorge Amor=F3s-Argos