* Re: [PATCH 4/5 V2] ARM: tegra: paz00: add clocks required for usboperation
@ 2011-08-09 19:26 Marc Dietrich
[not found] ` <201108092126.28521.marvin24-Mmb7MZpHnFY@public.gmane.org>
0 siblings, 1 reply; 15+ messages in thread
From: Marc Dietrich @ 2011-08-09 19:26 UTC (permalink / raw)
To: linux-tegra-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
Cc: Colin Cross, Olof Johansson
On Tuesday 09 August 2011 20:35:45 you wrote:
> Marc Dietrich wrote at Tuesday, August 09, 2011 12:29 PM:
> > These clocks are required for usb operation.
> > ---
> >
> > arch/arm/mach-tegra/board-paz00.c | 6 ++++++
> > 1 files changed, 6 insertions(+), 0 deletions(-)
> >
> > diff --git a/arch/arm/mach-tegra/board-paz00.c
> > b/arch/arm/mach-tegra/board-paz00.c index 45111f6..89a3dda 100644
> > --- a/arch/arm/mach-tegra/board-paz00.c
> > +++ b/arch/arm/mach-tegra/board-paz00.c
> > @@ -145,6 +145,12 @@ static __initdata struct tegra_clk_init_table
> > paz00_clk_init_table[] = {
> >
> > /* name parent rate enabled */
> > { "uarta", "pll_p", 216000000, true },
> > { "uartd", "pll_p", 216000000, true },
> >
> > +
> > + { "pll_p_out4", "pll_p", 24000000, true },
>
> 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 ...
Here is the clock tree (as it is for 3.1):
root@ac100:~# cat /sys/kernel/debug/clock/clock_tree
clock state ref div rate
--------------------------------------------------------------
cdev2 on 1 26000000
*cdev1 off 0 26000000
clk_m on 9 12000000
*pcie_xclk off 0 1 12000000
*afi off 0 1 12000000
*pex off 0 1 12000000
*csus off 0 1 12000000
*isp off 0 1 12000000
usb3 on 1 1 12000000
usb2 on 2 1 12000000
usbd on 1 1 12000000
*disp2 off 0 1 12000000
*tvdac off 0 1 12000000
*hdmi off 0 1 12000000
*tvo off 0 1 12000000
*cve off 0 1 12000000
*uarte off 0 1 12000000
*uartc off 0 1 12000000
*uartb off 0 1 12000000
dvc off 0 4 3000000
*i2c3 on 0 15 800000
i2c2 off 0 4 3000000
i2c1 off 0 4 3000000
*mipi off 0 1 12000000
*nor off 0 1 12000000
*owr off 0 1 12000000
*la off 0 1 12000000
*bsev off 0 1 12000000
*bsea off 0 1 12000000
*vcp off 0 1 12000000
*sdmmc3 off 0 1 12000000
*sdmmc2 off 0 1 12000000
sdmmc1 on 1 1 12000000
*vfir off 0 1 12000000
*ndflash off 0 1 12000000
*ide off 0 1 12000000
*sbc4 off 0 1 12000000
*sbc3 off 0 1 12000000
*sbc2 off 0 1 12000000
*sbc1 off 0 1 12000000
*twc off 0 1 12000000
*xio off 0 1 12000000
*spi off 0 1 12000000
*spdif_out off 0 1 12000000
*i2s2 off 0 1 12000000
*i2s1 off 0 1 12000000
timer on 1 1 12000000
*clk_d on 0 x2 24000000
*pll_e off 0 x100 1200000000
pll_x off 0 x26 312000000
pll_u on 2 x40 480000000
*pll_d off 0 12 1000000
*dsi off 0 1 1000000
*pll_d_out0 off 0 2 500000
pll_p on 10 x18 216000000
*disp1 on 0 1 216000000
*host1x off 0 2 108000000
uartd on 1 1 216000000
uarta on 1 1 216000000
csite on 1 1.5 144000000
sdmmc4 on 1 4.5 48000000
*pwm on 0 128.5 1680933
*spdif_in off 0 6 36000000
cclk on 1 216000000
cpu on 3 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
pll_p_out3 on 4 3 72000000
*csi off 0 1 72000000
dvc_i2c on 1 1 72000000
*i2c3_i2c on 0 1 72000000
i2c2_i2c on 1 1 72000000
i2c1_i2c on 1 1 72000000
pll_p_out2 on 1 4.5 48000000
pll_p_out1 on 1 7.5 28800000
*pll_a on 0 x1.9.. 56448000
*pll_a_out0 on 0 5 11289600
*audio on 0 11289600
*audio_2x off 0 x2 22579200
*pll_c on 0 x50 600000000
*vde off 0 2.5 240000000
*pll_c_out1 on 0 2.5 240000000
pll_m on 1 x55.5 666000000
*mpe off 0 6 111000000
*epp off 0 6 111000000
*vi_sensor off 0 6 111000000
*vi off 0 6 111000000
*2d off 0 6 111000000
*3d off 0 6 111000000
emc on 3 1 666000000
usb3.emc off 0 666000000
usb2.emc on 1 666000000
usb1.emc off 0 666000000
usbd.emc off 0 666000000
host.emc off 0 666000000
hdmi.emc off 0 666000000
disp2.emc off 0 666000000
disp1.emc off 0 666000000
cpu.emc on 2 666000000
avp.emc off 0 666000000
*pll_m_out1 on 0 3 222000000
clk_32k on 2 32768
rtc on 1 1 32768
*blink off 0 393208 0
*pll_s off 0 1 32768
^ permalink raw reply [flat|nested] 15+ messages in thread
* RE: [PATCH 4/5 V2] ARM: tegra: paz00: add clocks required for usboperation
2011-08-09 19:26 [PATCH 4/5 V2] ARM: tegra: paz00: add clocks required for usboperation Marc Dietrich
@ 2011-08-09 21:40 ` Stephen Warren
0 siblings, 0 replies; 15+ messages in thread
From: Stephen Warren @ 2011-08-09 21:40 UTC (permalink / raw)
To: Marc Dietrich
Cc: Colin Cross, Olof Johansson, linux-tegra-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
Marc Dietrich wrote at Tuesday, August 09, 2011 1:26 PM:
> On Tuesday 09 August 2011 20:35:45 you wrote:
> > Marc Dietrich wrote at Tuesday, August 09, 2011 12:29 PM:
> > > These clocks are required for usb operation.
> > > ---
> > >
> > > arch/arm/mach-tegra/board-paz00.c | 6 ++++++
> > > 1 files changed, 6 insertions(+), 0 deletions(-)
> > >
> > > diff --git a/arch/arm/mach-tegra/board-paz00.c
> > > b/arch/arm/mach-tegra/board-paz00.c index 45111f6..89a3dda 100644
> > > --- a/arch/arm/mach-tegra/board-paz00.c
> > > +++ b/arch/arm/mach-tegra/board-paz00.c
> > > @@ -145,6 +145,12 @@ static __initdata struct tegra_clk_init_table
> > > paz00_clk_init_table[] = {
> > >
> > > /* name parent rate enabled */
> > > { "uarta", "pll_p", 216000000, true },
> > > { "uartd", "pll_p", 216000000, true },
> > >
> > > +
> > > + { "pll_p_out4", "pll_p", 24000000, true },
> >
> > 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.
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.
I guess I'll ask a few people internally to see if they have a clue why
your change might be necessary.
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
--
nvpublic
^ permalink raw reply [flat|nested] 15+ messages in thread
* [PATCH 4/5 V2] ARM: tegra: paz00: add clocks required for usboperation
@ 2011-08-09 21:40 ` Stephen Warren
0 siblings, 0 replies; 15+ messages in thread
From: Stephen Warren @ 2011-08-09 21:40 UTC (permalink / raw)
To: linux-arm-kernel
Marc Dietrich wrote at Tuesday, August 09, 2011 1:26 PM:
> On Tuesday 09 August 2011 20:35:45 you wrote:
> > Marc Dietrich wrote at Tuesday, August 09, 2011 12:29 PM:
> > > These clocks are required for usb operation.
> > > ---
> > >
> > > arch/arm/mach-tegra/board-paz00.c | 6 ++++++
> > > 1 files changed, 6 insertions(+), 0 deletions(-)
> > >
> > > diff --git a/arch/arm/mach-tegra/board-paz00.c
> > > b/arch/arm/mach-tegra/board-paz00.c index 45111f6..89a3dda 100644
> > > --- a/arch/arm/mach-tegra/board-paz00.c
> > > +++ b/arch/arm/mach-tegra/board-paz00.c
> > > @@ -145,6 +145,12 @@ static __initdata struct tegra_clk_init_table
> > > paz00_clk_init_table[] = {
> > >
> > > /* name parent rate enabled */
> > > { "uarta", "pll_p", 216000000, true },
> > > { "uartd", "pll_p", 216000000, true },
> > >
> > > +
> > > + { "pll_p_out4", "pll_p", 24000000, true },
> >
> > 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 at 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.
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.
I guess I'll ask a few people internally to see if they have a clue why
your change might be necessary.
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
--
nvpublic
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [PATCH 4/5 V2] ARM: tegra: paz00: add clocks required forusboperation
2011-08-09 21:40 ` Stephen Warren
@ 2011-08-10 8:24 ` Marc Dietich
-1 siblings, 0 replies; 15+ messages in thread
From: Marc Dietich @ 2011-08-10 8:24 UTC (permalink / raw)
To: Stephen Warren
Cc: Colin Cross, Olof Johansson, linux-tegra-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
Hi Stephen,
> 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?
>
> 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 <vpalatin-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org>
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 <vpalatin-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org>
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
^ permalink raw reply [flat|nested] 15+ messages in thread
* [PATCH 4/5 V2] ARM: tegra: paz00: add clocks required forusboperation
@ 2011-08-10 8:24 ` Marc Dietich
0 siblings, 0 replies; 15+ messages in thread
From: Marc Dietich @ 2011-08-10 8:24 UTC (permalink / raw)
To: linux-arm-kernel
Hi Stephen,
> 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 at 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?
>
> 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 <vpalatin@chromium.org>
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 <vpalatin@chromium.org>
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
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [PATCH 4/5 V2] ARM: tegra: paz00: add clocks requiredforusboperation
2011-08-10 8:24 ` Marc Dietich
@ 2011-08-10 10:50 ` Marc Dietich
-1 siblings, 0 replies; 15+ messages in thread
From: Marc Dietich @ 2011-08-10 10:50 UTC (permalink / raw)
To: linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
Cc: Stephen Warren, Olof Johansson,
linux-tegra-u79uwXL29TY76Z2rM5mHXA, Colin Cross
> > 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 <vpalatin-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org>
> 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 <vpalatin-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org>
>
> 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
^ permalink raw reply [flat|nested] 15+ messages in thread
* [PATCH 4/5 V2] ARM: tegra: paz00: add clocks requiredforusboperation
@ 2011-08-10 10:50 ` Marc Dietich
0 siblings, 0 replies; 15+ messages in thread
From: Marc Dietich @ 2011-08-10 10:50 UTC (permalink / raw)
To: linux-arm-kernel
> > 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 at 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 <vpalatin@chromium.org>
> 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 <vpalatin@chromium.org>
>
> 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
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [PATCH 4/5 V2] ARM: tegra: paz00: add clocks requiredforusboperation
2011-08-10 10:50 ` Marc Dietich
@ 2011-08-10 10:59 ` Olof Johansson
-1 siblings, 0 replies; 15+ messages in thread
From: Olof Johansson @ 2011-08-10 10:59 UTC (permalink / raw)
To: Marc Dietich
Cc: linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
Stephen Warren, linux-tegra-u79uwXL29TY76Z2rM5mHXA, Colin Cross
On Wed, Aug 10, 2011 at 3:50 AM, Marc Dietich <marvin24-Mmb7MZpHnFY@public.gmane.org> wrote:
>> > 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.
We moved some of this to common.c, and should be posting those patches
in a while. It doesn't make sense to run sclk on pll_m, since that one
scales with memory clock scaling.
-Olof
^ permalink raw reply [flat|nested] 15+ messages in thread
* [PATCH 4/5 V2] ARM: tegra: paz00: add clocks requiredforusboperation
@ 2011-08-10 10:59 ` Olof Johansson
0 siblings, 0 replies; 15+ messages in thread
From: Olof Johansson @ 2011-08-10 10:59 UTC (permalink / raw)
To: linux-arm-kernel
On Wed, Aug 10, 2011 at 3:50 AM, Marc Dietich <marvin24@gmx.de> wrote:
>> > 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 at 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.
We moved some of this to common.c, and should be posting those patches
in a while. It doesn't make sense to run sclk on pll_m, since that one
scales with memory clock scaling.
-Olof
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [PATCH 4/5 V2] ARM: tegra: paz00: add clocks requiredforusboperation
2011-08-10 10:59 ` Olof Johansson
@ 2011-08-10 11:20 ` Marc Dietich
-1 siblings, 0 replies; 15+ messages in thread
From: Marc Dietich @ 2011-08-10 11:20 UTC (permalink / raw)
To: Olof Johansson
Cc: linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
Stephen Warren, linux-tegra-u79uwXL29TY76Z2rM5mHXA, Colin Cross
> On Wed, Aug 10, 2011 at 3:50 AM, Marc Dietich <marvin24-Mmb7MZpHnFY@public.gmane.org> wrote:
> >> > 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.
>
> We moved some of this to common.c, and should be posting those patches
> in a while. It doesn't make sense to run sclk on pll_m, since that one
> scales with memory clock scaling.
Olof,
ok, I see. In .38 sclk is bound to pll_c_out1 running at 120 MHz. So we need no
further change, just wait for the patch to arrive.
Thanks!
Marc
^ permalink raw reply [flat|nested] 15+ messages in thread
* [PATCH 4/5 V2] ARM: tegra: paz00: add clocks requiredforusboperation
@ 2011-08-10 11:20 ` Marc Dietich
0 siblings, 0 replies; 15+ messages in thread
From: Marc Dietich @ 2011-08-10 11:20 UTC (permalink / raw)
To: linux-arm-kernel
> On Wed, Aug 10, 2011 at 3:50 AM, Marc Dietich <marvin24@gmx.de> wrote:
> >> > 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 at 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.
>
> We moved some of this to common.c, and should be posting those patches
> in a while. It doesn't make sense to run sclk on pll_m, since that one
> scales with memory clock scaling.
Olof,
ok, I see. In .38 sclk is bound to pll_c_out1 running at 120 MHz. So we need no
further change, just wait for the patch to arrive.
Thanks!
Marc
^ permalink raw reply [flat|nested] 15+ messages in thread
* RE: [PATCH 4/5 V2] ARM: tegra: paz00: add clocks required forusboperation
2011-08-10 8:24 ` Marc Dietich
@ 2011-08-10 15:24 ` Stephen Warren
-1 siblings, 0 replies; 15+ messages in thread
From: Stephen Warren @ 2011-08-10 15:24 UTC (permalink / raw)
To: Marc Dietich
Cc: Colin Cross, Olof Johansson, linux-tegra-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
Marc Dietich wrote at Wednesday, August 10, 2011 2:25 AM:
> Hi Stephen,
>
> > 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 ...
...
> > 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?
Yes, I think this will cause a lower bus speed. I don't know how much
performance impact this will have; probably mainly just peripheral register
accesses, so not too much of a big deal.
> > 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:
Ah yes, DAP_MCLK1/2 don't show up in the clock table. That certainly
explains everything. So, I withdraw any objections to this patch. Do
you want to follow it up with one that reparents sclk? I can test that
on Harmony, Seaboard, and TrimSlice if you want. If not, I'll see if I
can work on that a little later...
> commit dfb625f934dd40baf29ee6c43e4f130b524411a1
> Author: Vincent Palatin <vpalatin-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org>
> 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 <vpalatin-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org>
>
> 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
--
nvpublic
^ permalink raw reply [flat|nested] 15+ messages in thread
* [PATCH 4/5 V2] ARM: tegra: paz00: add clocks required forusboperation
@ 2011-08-10 15:24 ` Stephen Warren
0 siblings, 0 replies; 15+ messages in thread
From: Stephen Warren @ 2011-08-10 15:24 UTC (permalink / raw)
To: linux-arm-kernel
Marc Dietich wrote at Wednesday, August 10, 2011 2:25 AM:
> Hi Stephen,
>
> > 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 ...
...
> > 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?
Yes, I think this will cause a lower bus speed. I don't know how much
performance impact this will have; probably mainly just peripheral register
accesses, so not too much of a big deal.
> > 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:
Ah yes, DAP_MCLK1/2 don't show up in the clock table. That certainly
explains everything. So, I withdraw any objections to this patch. Do
you want to follow it up with one that reparents sclk? I can test that
on Harmony, Seaboard, and TrimSlice if you want. If not, I'll see if I
can work on that a little later...
> commit dfb625f934dd40baf29ee6c43e4f130b524411a1
> Author: Vincent Palatin <vpalatin@chromium.org>
> 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 <vpalatin@chromium.org>
>
> 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
--
nvpublic
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [PATCH 4/5 V2] ARM: tegra: paz00: add clocks requiredforusboperation
2011-08-10 15:24 ` Stephen Warren
@ 2011-08-10 17:26 ` Marc Dietrich
-1 siblings, 0 replies; 15+ messages in thread
From: Marc Dietrich @ 2011-08-10 17:26 UTC (permalink / raw)
To: Stephen Warren
Cc: Colin Cross, Olof Johansson, linux-tegra-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
On Wednesday 10 August 2011 17:24:46 Stephen Warren wrote:
> Marc Dietich wrote at Wednesday, August 10, 2011 2:25 AM:
> > Hi Stephen,
> >
> > > 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 ...
>
> ...
>
> > > 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?
>
> Yes, I think this will cause a lower bus speed. I don't know how much
> performance impact this will have; probably mainly just peripheral register
> accesses, so not too much of a big deal.
>
> > > 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:
> Ah yes, DAP_MCLK1/2 don't show up in the clock table. That certainly
> explains everything. So, I withdraw any objections to this patch. Do
> you want to follow it up with one that reparents sclk? I can test that
> on Harmony, Seaboard, and TrimSlice if you want. If not, I'll see if I
> can work on that a little later...
Stephen,
I think Olof will send a patch later on regarding the sclk change in common.c (see his last comment), so we can test it when it arrives. In the mean time I posted V4 which should be really the final version.
Thanks!
Marc
> > commit dfb625f934dd40baf29ee6c43e4f130b524411a1
> > Author: Vincent Palatin <vpalatin-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org>
> > 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 <vpalatin-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org>
> >
> > 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
^ permalink raw reply [flat|nested] 15+ messages in thread
* [PATCH 4/5 V2] ARM: tegra: paz00: add clocks requiredforusboperation
@ 2011-08-10 17:26 ` Marc Dietrich
0 siblings, 0 replies; 15+ messages in thread
From: Marc Dietrich @ 2011-08-10 17:26 UTC (permalink / raw)
To: linux-arm-kernel
On Wednesday 10 August 2011 17:24:46 Stephen Warren wrote:
> Marc Dietich wrote at Wednesday, August 10, 2011 2:25 AM:
> > Hi Stephen,
> >
> > > 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 ...
>
> ...
>
> > > 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?
>
> Yes, I think this will cause a lower bus speed. I don't know how much
> performance impact this will have; probably mainly just peripheral register
> accesses, so not too much of a big deal.
>
> > > 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:
> Ah yes, DAP_MCLK1/2 don't show up in the clock table. That certainly
> explains everything. So, I withdraw any objections to this patch. Do
> you want to follow it up with one that reparents sclk? I can test that
> on Harmony, Seaboard, and TrimSlice if you want. If not, I'll see if I
> can work on that a little later...
Stephen,
I think Olof will send a patch later on regarding the sclk change in common.c (see his last comment), so we can test it when it arrives. In the mean time I posted V4 which should be really the final version.
Thanks!
Marc
> > commit dfb625f934dd40baf29ee6c43e4f130b524411a1
> > Author: Vincent Palatin <vpalatin@chromium.org>
> > 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 <vpalatin@chromium.org>
> >
> > 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
^ permalink raw reply [flat|nested] 15+ messages in thread
end of thread, other threads:[~2011-08-10 17:26 UTC | newest]
Thread overview: 15+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2011-08-09 19:26 [PATCH 4/5 V2] ARM: tegra: paz00: add clocks required for usboperation Marc Dietrich
[not found] ` <201108092126.28521.marvin24-Mmb7MZpHnFY@public.gmane.org>
2011-08-09 21:40 ` Stephen Warren
2011-08-09 21:40 ` Stephen Warren
[not found] ` <74CDBE0F657A3D45AFBB94109FB122FF04A06873BB-C7FfzLzN0UxDw2glCA4ptUEOCMrvLtNR@public.gmane.org>
2011-08-10 8:24 ` [PATCH 4/5 V2] ARM: tegra: paz00: add clocks required forusboperation Marc Dietich
2011-08-10 8:24 ` Marc Dietich
[not found] ` <201108101024.57494.marvin24-Mmb7MZpHnFY@public.gmane.org>
2011-08-10 10:50 ` [PATCH 4/5 V2] ARM: tegra: paz00: add clocks requiredforusboperation Marc Dietich
2011-08-10 10:50 ` Marc Dietich
[not found] ` <201108101250.48324.marvin24-Mmb7MZpHnFY@public.gmane.org>
2011-08-10 10:59 ` Olof Johansson
2011-08-10 10:59 ` Olof Johansson
[not found] ` <CAOesGMjmkchniG5Nd2M3wW8_RXQbSQQzspMVGGvbmF5Naf94SA-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2011-08-10 11:20 ` Marc Dietich
2011-08-10 11:20 ` Marc Dietich
2011-08-10 15:24 ` [PATCH 4/5 V2] ARM: tegra: paz00: add clocks required forusboperation Stephen Warren
2011-08-10 15:24 ` Stephen Warren
[not found] ` <74CDBE0F657A3D45AFBB94109FB122FF04A0687486-C7FfzLzN0UxDw2glCA4ptUEOCMrvLtNR@public.gmane.org>
2011-08-10 17:26 ` [PATCH 4/5 V2] ARM: tegra: paz00: add clocks requiredforusboperation Marc Dietrich
2011-08-10 17:26 ` Marc Dietrich
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.