[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20190424093015.rcr5auamfccxf6ei@vireshk-i7>
Date: Wed, 24 Apr 2019 15:00:15 +0530
From: Viresh Kumar <viresh.kumar@...aro.org>
To: Gregory CLEMENT <gregory.clement@...tlin.com>,
Ilias Apalodimas <ilias.apalodimas@...aro.org>
Cc: Christian Neubert <christian.neubert.86@...il.com>,
Stephen Boyd <sboyd@...eaurora.org>,
Mike Turquette <mturquette@...libre.com>,
linux-clk@...r.kernel.org, linux-kernel@...r.kernel.org,
"Rafael J. Wysocki" <rjw@...ysocki.net>, linux-pm@...r.kernel.org,
Vincent Guittot <vincent.guittot@...aro.org>,
Jason Cooper <jason@...edaemon.net>,
Andrew Lunn <andrew@...n.ch>,
Sebastian Hesselbarth <sebastian.hesselbarth@...il.com>,
Thomas Petazzoni <thomas.petazzoni@...tlin.com>,
linux-arm-kernel@...ts.infradead.org,
Antoine Tenart <antoine.tenart@...tlin.com>,
Miquèl Raynal <miquel.raynal@...tlin.com>,
Maxime Chevallier <maxime.chevallier@...tlin.com>,
stable@...r.kernel.org
Subject: Re: [PATCH] clk: mvebu: armada-37xx-periph: Fix initialization for
cpu clocks
On 18-03-19, 14:21, Ilias Apalodimas wrote:
> Hi Gregory,
>
> > >>
> > > [ 14.909524] clk_pm_cpu_set_parent old=28004840 -> val=0x6000000 load_level=0
> > > [ 14.916424] clk_pm_cpu_set_parent old=2E004840 -> val=0x600 load_level=1
> > > [ 14.923315] clk_pm_cpu_set_parent old=8880A8C0 -> val=0x6000000 load_level=2
> > > [ 14.930572] clk_pm_cpu_set_parent old=8E80A8C0 -> val=0x600 load_level=3
> > >
> > >
> > > Let me know if you need anything else
> >
> > Could you show me the output of "cat /sys/kernel/debug/clk/clk_summary"
> >
> root@...alhost ~ # cat /sys/kernel/debug/clk/clk_summary
> enable prepare protect duty
> clock count count count rate accuracy phase cycle
> ---------------------------------------------------------------------------------------------
> xtal 2 3 0 25000000 0 0 50000
> i2c_1 0 0 0 25000000 0 0 50000
> i2c_2 0 0 0 25000000 0 0 50000
> avs 0 0 0 25000000 0 0 50000
> TBG-B-S 2 2 0 1000000000 0 0 50000
> cpu 0 0 0 200000000 0 0 50000
> usb32_ss_sys 1 1 0 125000000 0 0 50000
> usb32_usb2_sys 0 0 0 100000000 0 0 50000
> gbe_125 0 0 0 125000000 0 0 50000
> gbe0_125 0 0 0 125000000 0 0 50000
> gbe1_125 0 0 0 125000000 0 0 50000
> gbe_core 1 1 0 250000000 0 0 50000
> gbe_bm 0 0 0 250000000 0 0 50000
> gbe0_core 1 1 0 250000000 0 0 50000
> gbe1_core 0 0 0 250000000 0 0 50000
> eip97 0 0 0 500000000 0 0 50000
> trace 0 0 0 1000000000 0 0 50000
> ddr_fclk 0 0 0 125000000 0 0 50000
> pwm 0 0 0 50000000 0 0 50000
> tscem_tmx 0 0 0 1000000000 0 0 50000
> sec_dap 0 0 0 100000000 0 0 50000
> sec_at 0 0 0 200000000 0 0 50000
> TBG-A-S 0 0 0 1600000000 0 0 50000
> sdio 0 0 0 400000000 0 0 50000
> ddr_phy 0 0 0 400000000 0 0 50000
> mmc 0 0 0 400000000 0 0 50000
> TBG-B-P 0 0 0 500000000 0 0 50000
> gbe_50 0 0 0 50000000 0 0 50000
> gbe0_50 0 0 0 50000000 0 0 50000
> gbe1_50 0 0 0 50000000 0 0 50000
> TBG-A-P 0 1 0 800000000 0 0 50000
> counter 0 0 0 160000000 0 0 50000
> sqf 0 1 0 200000000 0 0 50000
> tscem 0 0 0 200000000 0 0 50000
> sata_host 0 0 0 200000000 0 0 50000
> root@...alhost ~ #
>
> > Also, during this week-end, Christian suggested that the issue might
> > come from the AVS support.
> >
> > Could you disable it and check you still have the issue?
> >
> > For this, you just have to remove the avs node in
> > arch/arm64/boot/dts/marvell/armada-37xx.dtsi and rebuild the dtb.
> Sure. You'll have to wait for a week though. Currently on a trip. I'll run that
> once i return
@Ilias: Can you please try this now and confirm to Gregory ?
--
viresh
Powered by blists - more mailing lists