Re: [PATCH] ARM: dts: AM35xx: fix system control module clocks

2015-06-08 Thread Jeroen Hofstee
Hello Paul, +Menon (since you asked about the USB_OTG trap), On 08-06-15 04:38, Paul Walmsley wrote: Hi Jeroen, On Sun, 7 Jun 2015, Paul Walmsley wrote: On Sun, 7 Jun 2015, Jeroen Hofstee wrote: Turns out my suspicion was wrong. This is what I know at the moment, depending on the bootpins

Re: [PATCH] ARM: dts: AM35xx: fix system control module clocks

2015-06-08 Thread Jeroen Hofstee
Hello Paul, On 07-06-15 21:56, Paul Walmsley wrote: On Sun, 7 Jun 2015, Jeroen Hofstee wrote: Turns out my suspicion was wrong. This is what I know at the moment, depending on the bootpins, u-boot will trigger a bad access when loading a file over ethernet, but only the first time. Clearing

Re: [PATCH] ARM: dts: AM35xx: fix system control module clocks

2015-06-07 Thread Jeroen Hofstee
Hello Paul, On 05-06-15 10:04, Jeroen Hofstee wrote: On 05-06-15 10:01, Jeroen Hofstee wrote: On 01-06-15 19:44, Paul Walmsley wrote: The best way to make this work IMHO would be for us not to accept any new feature addition patches as long as there are warnings reported in the test

Re: [PATCH] ARM: dts: AM35xx: fix system control module clocks

2015-06-05 Thread Jeroen Hofstee
Hello Paul, On 01-06-15 19:44, Paul Walmsley wrote: The best way to make this work IMHO would be for us not to accept any new feature addition patches as long as there are warnings reported in the test results. The only real exception that I would foresee is if those warnings are due to

Re: [PATCH] ARM: dts: AM35xx: fix system control module clocks

2015-06-05 Thread Jeroen Hofstee
On 05-06-15 10:01, Jeroen Hofstee wrote: Hello Paul, On 01-06-15 19:44, Paul Walmsley wrote: The best way to make this work IMHO would be for us not to accept any new feature addition patches as long as there are warnings reported in the test results. The only real exception that I would

Re: [PATCH] ARM: dts: AM35xx: fix system control module clocks

2015-06-01 Thread Jeroen Hofstee
not caught earlier. Fixed by applying the proper offsets for the AM35xx scm clocks. Fixes: b8845074cf (ARM: dts: omap3: add minimal l4 bus layout with...) Signed-off-by: Tero Kristo t-kri...@ti.com Reported-by: Jeroen Hofstee linux-...@myspectrum.nl Cc: Paul Walmsley p...@pwsan.com Cc: Tony

Re: OMAP baseline test results for v4.1-rc5

2015-05-31 Thread Jeroen Hofstee
Hi, On 30-05-15 17:56, Jeroen Hofstee wrote: Hello Paul, On 30-05-15 17:50, Paul Walmsley wrote: Here are some basic OMAP test results for Linux v4.1-rc5. Logs and other details at: http://www.pwsan.com/omap/testlogs/test_v4.1-rc5/20150529162206/ The cmt3517 seems to have these some

Re: OMAP baseline test results for v4.1-rc5

2015-05-30 Thread Jeroen Hofstee
Hello Paul, On 30-05-15 17:50, Paul Walmsley wrote: Here are some basic OMAP test results for Linux v4.1-rc5. Logs and other details at: http://www.pwsan.com/omap/testlogs/test_v4.1-rc5/20150529162206/ The cmt3517 seems to have these some In-Band errors. Do you happen to know where

Re: [RESEND][PATCH] ARM errata, 430973: update the affected revisions

2015-04-14 Thread Jeroen Hofstee
Hello Russell, On 13-04-15 23:35, Russell King - ARM Linux wrote: On Mon, Apr 13, 2015 at 09:28:09AM -0700, Tony Lindgren wrote: * Tony Lindgren t...@atomide.com [150413 07:46]: If what Russell and I are saying is correct, with the above two patches your system should behave properly with