Hi Len,
On Wednesday 17 December 2014 02:38 AM, Lennart Sorensen wrote:
Errata i856 for the AM572x (DRA7xx) points out that the 32.768KHz external
crystal is not enabled at power up. Instead the CPU falls back to using
an emulation for the 32KHz clock which is SYSCLK1/610. SYSCLK1 is usually
Tony,
As the IOMMU stuff was merged last night, which removed a really quite
horrid conflict resolution, I updated my nightly build tree from its
previous state last Thursday.
Now, SDP4430 seems to be really quite broken.
ti_dt_clocks_register: failed to lookup clock node dss_fck
Am Dienstag, den 16.12.2014, 22:25 + schrieb Paul Walmsley:
+ p...@pwsan.com (I prefer not having to deal with MS Exchange when
possible :-) )
On Tue, 16 Dec 2014, Russell King - ARM Linux wrote:
On Tue, Dec 16, 2014 at 08:45:25PM +, Paul Walmsley wrote:
On Tue, 16 Dec 2014,
On 12/17/2014 11:52 AM, Lucas Stach wrote:
Am Dienstag, den 16.12.2014, 22:25 + schrieb Paul Walmsley:
+ p...@pwsan.com (I prefer not having to deal with MS Exchange when
possible :-) )
On Tue, 16 Dec 2014, Russell King - ARM Linux wrote:
On Tue, Dec 16, 2014 at 08:45:25PM +, Paul
On 12/16/2014 04:58 PM, Nishanth Menon wrote:
On 17:05-20141216, Lokesh Vutla wrote:
[...]
@@ -545,6 +546,16 @@ static void __init realtime_counter_init(void)
break;
}
+ if (soc_is_dra7xx()) {
+ reg = omap_ctrl_readl(DRA7_CTRL_CORE_BOOTSTRAP);
+
On Wed, Dec 17, 2014 at 03:21:27PM +0200, Tero Kristo wrote:
Yea I think the 32k clock node should be fixed based on this.
Something like this:
--- a/arch/arm/boot/dts/dra7xx-clocks.dtsi
+++ b/arch/arm/boot/dts/dra7xx-clocks.dtsi
@@ -100,8 +100,10 @@
sys_32k_ck: sys_32k_ck {
On 09:55-20141217, Lennart Sorensen wrote:
On Wed, Dec 17, 2014 at 03:21:27PM +0200, Tero Kristo wrote:
Yea I think the 32k clock node should be fixed based on this.
Something like this:
--- a/arch/arm/boot/dts/dra7xx-clocks.dtsi
+++ b/arch/arm/boot/dts/dra7xx-clocks.dtsi
@@ -100,8
On Wed, Dec 17, 2014 at 09:22:25AM -0600, Nishanth Menon wrote:
A clock mux might do the job?
value 1, 2 , 3 will imply sysclk1 / 610
value of 0 implies fixed 32768
soemthing like
sys_clk32_crystal {
compatible = fixed-clock;
clock-frequency = 32768;
}
On 14:06-20141217, Lokesh Vutla wrote:
Hi Len,
On Wednesday 17 December 2014 02:38 AM, Lennart Sorensen wrote:
Errata i856 for the AM572x (DRA7xx) points out that the 32.768KHz external
crystal is not enabled at power up. Instead the CPU falls back to using
an emulation for the 32KHz
On 09:37-20141217, Viresh Kumar wrote:
On 17 December 2014 at 02:33, Nishanth Menon n...@ti.com wrote:
http://storage.armcloud.us/kernel-ci/next/next-20141216/arm-multi_v7_defconfig/lab-khilman/boot-omap5-uevm.html
[2.071996] [ cut here ]
[2.076831] kernel
On 12/17/2014 05:27 PM, Lennart Sorensen wrote:
On Wed, Dec 17, 2014 at 09:22:25AM -0600, Nishanth Menon wrote:
A clock mux might do the job?
value 1, 2 , 3 will imply sysclk1 / 610
value of 0 implies fixed 32768
soemthing like
sys_clk32_crystal {
compatible = fixed-clock;
On Wednesday 17 December 2014 23:33:02 Sneeker. Yeh wrote:
No need for playing games with child devices, just see how the other drivers
do
it.
I am wondering if this is what you mentioned here? :
Hcd21: f_usb20ho {
compatible = fujitsu,f_usb20ho;
...
Ehci {
On Wed, Dec 17, 2014 at 05:45:05PM +0200, Tero Kristo wrote:
Yea clock mux can be used. However, we don't have support for DRA7
control module clocks in the DT yet. I have posted patches with
support towards this a couple of weeks back, but they need some
revising.
Thus, we maybe need to
On 17:45-20141217, Tero Kristo wrote:
On 12/17/2014 05:27 PM, Lennart Sorensen wrote:
On Wed, Dec 17, 2014 at 09:22:25AM -0600, Nishanth Menon wrote:
A clock mux might do the job?
value 1, 2 , 3 will imply sysclk1 / 610
value of 0 implies fixed 32768
soemthing like
sys_clk32_crystal
On 12/17/2014 05:53 PM, Nishanth Menon wrote:
On 17:45-20141217, Tero Kristo wrote:
On 12/17/2014 05:27 PM, Lennart Sorensen wrote:
On Wed, Dec 17, 2014 at 09:22:25AM -0600, Nishanth Menon wrote:
A clock mux might do the job?
value 1, 2 , 3 will imply sysclk1 / 610
value of 0 implies fixed
On 17 December 2014 at 20:58, Nishanth Menon n...@ti.com wrote:
I still do not see the need to crash the entire system - OK, fine
cpufreq is broke, but the remaining part of the system can easily
function. That BUG does look like a ugly point and lack of proper
cleanup logic - cpufreq should
On Wed, Dec 17, 2014 at 10:27 AM, Viresh Kumar viresh.ku...@linaro.org wrote:
On 17 December 2014 at 20:58, Nishanth Menon n...@ti.com wrote:
I still do not see the need to crash the entire system - OK, fine
cpufreq is broke, but the remaining part of the system can easily
function. That BUG
[+ Tero]
On Tue, Dec 16, 2014 at 8:07 PM, Viresh Kumar viresh.ku...@linaro.org wrote:
On 17 December 2014 at 02:33, Nishanth Menon n...@ti.com wrote:
http://storage.armcloud.us/kernel-ci/next/next-20141216/arm-multi_v7_defconfig/lab-khilman/boot-omap5-uevm.html
[2.071996] [ cut
Hi,
* Russell King - ARM Linux li...@arm.linux.org.uk [141217 01:55]:
Tony,
As the IOMMU stuff was merged last night, which removed a really quite
horrid conflict resolution, I updated my nightly build tree from its
previous state last Thursday.
Now, SDP4430 seems to be really quite
On Wed, Dec 17, 2014 at 11:23 AM, Tony Lindgren t...@atomide.com wrote:
twl: not initialized
twl6030_uv_to_vsel:OUT OF RANGE! non mapped vsel for 1375000 Vs max 1316660
twl6030_uv_to_vsel:OUT OF RANGE! non mapped vsel for 1375000 Vs max 1316660
twl6030_uv_to_vsel:OUT OF RANGE! non mapped vsel
* Nishanth Menon n...@ti.com [141217 09:35]:
On Wed, Dec 17, 2014 at 11:23 AM, Tony Lindgren t...@atomide.com wrote:
twl: not initialized
twl6030_uv_to_vsel:OUT OF RANGE! non mapped vsel for 1375000 Vs max 1316660
twl6030_uv_to_vsel:OUT OF RANGE! non mapped vsel for 1375000 Vs max 1316660
On Wed, Dec 17, 2014 at 09:23:33AM -0800, Tony Lindgren wrote:
Hi,
* Russell King - ARM Linux li...@arm.linux.org.uk [141217 01:55]:
Tony,
As the IOMMU stuff was merged last night, which removed a really quite
horrid conflict resolution, I updated my nightly build tree from its
On Wed, Dec 17, 2014 at 9:16 AM, Kevin Hilman khil...@kernel.org wrote:
[...]
So the BUG() itself isn't the problem with this regression. There's
been a fair amount of changes in the OMAP clk driver (including some
other regressions), so I suspect the culprit to be lying somewhere in
the
* Russell King - ARM Linux li...@arm.linux.org.uk [141217 10:54]:
On Wed, Dec 17, 2014 at 09:23:33AM -0800, Tony Lindgren wrote:
Hi,
* Russell King - ARM Linux li...@arm.linux.org.uk [141217 01:55]:
Tony,
As the IOMMU stuff was merged last night, which removed a really quite
* Tony Lindgren t...@atomide.com [141217 11:14]:
Also, in your 3430-LDP logs, the DMA setup_irq related In-band Error
is a mystery. I'm not seeing that with omap2plus_defconfig, but can
reproduce it here with your LDP .config file. Got any ideas on that one?
Hmm it looks like that's some
rcu_sched stall messages.
I tried booting my 4460 Panda - which is the closest thing to 4430SDP
that I've got - on next-20141217, but I could not get it to the point
where the omap-abe-twl6040 probed. It probably is the problem you are
talking about as the hang does not happen if I disable ASoC ABE
On 17 December 2014 at 22:13, Nishanth Menon n...@ti.com wrote:
I do realize that i did have different opinion given bootloader screw
ups. Given that we have discovered a potentially bad configuration (in
this case for some reason almost ALL TI platforms have bad
configuration - could be due
On 17 December 2014 at 22:46, Kevin Hilman khil...@kernel.org wrote:
So this looks like a bug that has been hiding, but just exposed
because cpufreq-cpu0 (now cpufreq-dt) was not getting built-in since
before v3.18.
On omap4-panda-es, v3.18 with multi_v7_defconfig + CPUFREQ_DT enabled,
I see
On Tuesday 16 December 2014 02:20 AM, Nishanth Menon wrote:
On 12/12/2014 02:06 AM, Kishon Vijay Abraham I wrote:
The reset values for all the PCF lines are high and hence on shutdown
we should drive all the lines high in order to bring it to the reset state.
This is actually required since
29 matches
Mail list logo