From mboxrd@z Thu Jan 1 00:00:00 1970 From: Marc Dietich Subject: Re: [PATCH 4/5 V2] ARM: tegra: paz00: add clocks requiredforusboperation Date: Wed, 10 Aug 2011 12:50:47 +0200 Message-ID: <201108101250.48324.marvin24@gmx.de> References: <201108092126.28521.marvin24@gmx.de> <74CDBE0F657A3D45AFBB94109FB122FF04A06873BB@HQMAIL01.nvidia.com> <201108101024.57494.marvin24@gmx.de> Mime-Version: 1.0 Content-Type: Text/Plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <201108101024.57494.marvin24-Mmb7MZpHnFY@public.gmane.org> Sender: linux-tegra-owner-u79uwXL29TY76Z2rM5mHXA@public.gmane.org To: linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org Cc: Stephen Warren , Olof Johansson , "linux-tegra-u79uwXL29TY76Z2rM5mHXA@public.gmane.org" , Colin Cross List-Id: linux-tegra@vger.kernel.org > > Marc Dietrich wrote at Tuesday, August 09, 2011 1:26 PM: > > > On Tuesday 09 August 2011 20:35:45 you wrote: > > > > [...] > > > > Do you need the pll_p_out4 entry? What's that driving? Check in > > > > /sys/kernel/debug/clock/clock_tree (/sys/kernel/debug is debugfs). > > > > > > I think it is only required to setup the correct (non-standard?) > > > frequency. Seems all other boards use 108 MHz which cause one of the > > > ports to fail. Don't ask me for details ... > > > > ... > > > > > root@ac100:~# cat /sys/kernel/debug/clock/clock_tree > > > > > > clock state ref div rate > > > > > > -------------------------------------------------------------- > > > > > > clk_m on 9 12000000 > > > > ... > > > > > pll_p on 10 x18 216000000 > > > > ... > > > > > pll_p_out4 on 3 9 24000000 > > > > > > sclk on 2 24000000 > > > > > > avp.sclk off 0 24000000 > > > cop on 1 24000000 > > > hclk on 2 1 24000000 > > > > > > pclk on 2 2 12000000 > > > > > > apbdma on 1 1 12000000 > > > > Hmm. That's pretty odd. > > > > With the standard kernel the device ships with, what does the clock tree > > under pll_p_out4 look like? It'd be very interesting to compare that. If > > that setup is the same as what this patch sets up, the patch seems fine. > > unfortunately, there is no such think in .32 kernel (the kernel deliverd > with the device), and I don't think I can port it over. > > > As far as I know all the clocks there are both unrelated to USB, and > > internal to the device, so the board shouldn't have any effect. In > > particular, avp.sclk/cop are for the internal media CPU/DSP, hclk/pclk > > are the internal AHB/APB bus clocks, and apbdma is for an internal DMA > > engine, currently only used for audio in the mainline kernel at least. > > Does this mean that the internal busses you mentioned are also running at > low speed? Would this be a hugh performance penality? maybe this is why in the commit mentioned below sclk is bind to pll_c_out1 and set to 108 MHz again. But I cannot see this change in the current seaboard clock table (optimized away?). Maybe someone with a seaboard could check this. Marc > > I guess I'll ask a few people internally to see if they have a clue why > > your change might be necessary. > > Also take a look at seaboard, it has the same clock setting and especially > commit dfb625f934dd40baf29ee6c43e4f130b524411a1 in the chromeos kernel: > > commit dfb625f934dd40baf29ee6c43e4f130b524411a1 > Author: Vincent Palatin > Date: Wed Apr 13 07:26:08 2011 -0400 > > CHROMIUM: tegra: seaboard: fix ULPI transceiver clock > > On our seaboard-based platforms, pll_p_out4 is used to clock > (through DAP_MCLK2) the external USB ULPI transceiver between the USB2 > port to mini-PCIe modem. And it needs to be set at 24Mhz for the > tranceiver to work correctly. > Revert the sclk parent to pll_c out1 (as it was before the last change) > since it needs to stay clocked at 108MHz. > > Signed-off-by: Vincent Palatin > > BUG=chrome-os-partner:3167 > TEST=Check that the Gobi modem is appearing in lsusb listing > Use the kaen DVT for browsing and suspending > > Review URL: http://codereview.chromium.org/6825076 > > Change-Id: Ia9b1bbc7860da732fb8edbbcf0bce60e82d6d8ed > > > Thanks! > > Marc > > > For reference, here's Harmony on something roughly like linux-next: > > clk_m on 7 12000000 > > > > ... > > > > pll_p on 9 x18 216000000 > > > > ... > > > > pll_p_out4 on 2 2 108000000 > > > > sclk on 2 108000000 > > > > avp.sclk off 0 108000000 > > cop on 1 108000000 > > hclk on 2 1 108000000 > > > > pclk on 2 2 54000000 > > > > apbdma on 1 1 54000000