From: Jeroen Hofstee <jeroen@myspectrum.nl>
To: Paul Walmsley <paul@pwsan.com>
Cc: Tom Rini <trini@konsulko.com>, Tony Lindgren <tony@atomide.com>,
Tero Kristo <t-kristo@ti.com>,
linux-omap@vger.kernel.org, linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH] ARM: dts: AM35xx: fix system control module clocks
Date: Mon, 08 Jun 2015 23:43:29 +0200 [thread overview]
Message-ID: <55760C81.3020602@myspectrum.nl> (raw)
In-Reply-To: <alpine.DEB.2.02.1506071952490.15153@utopia.booyaka.com>
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 the pending interrupt
>> before booting linux make the "USB_OTG address hole seen" go away.
> Oh, too bad. I had been hoping that you were right and that I was wrong
> ;-) I'll try this on the CM-T3517 here.
>
> I'd like to solicit your opinion on what to do here. I wonder if, in the
> L3 bus drivers, we should simply report, in a line or two, if any bus
> errors were logged before the kernel starts? That would help discriminate
> between problems that the kernel is responsible for, vs. problems that
> occur earlier in the boot process. Any thoughts?
>
I am not sure this can be easily done in a general manner. Since in general
linux doesn't know the bootloader, it can't rely on what peripherals are
setup,
so I doubt it is in general possible to store a copy of the interrupt
registers
really early. Besides that, when not hacking around, I guess during the
really
early boot stage it is unknown what the interrupt registers are in the
first place
and which clocks are needed. And even if it could be done, if there is a
bug in
that code, it would lead to bigger problems than it is trying to solve
(a bit weird
backlogs).
I guess it would be easier to check these flags in u-boot right before
the jump
to linux (there is a cleanup_before_linux() or something name like
that). [ Or fake
the boot and run the check as a separate command]. Unfortunately u-boot does
not have a complete driver model, so a implementation of that in todays
u-boot
will lead to a complete #ifdef CONFIG_foo mesh.
So, if you ask me, no don't add it to linux, but to u-boot instead. But
likely as feature
for a later release which can query all drivers. (and doubt this should
be limited to
interrupt flags, runtime_test() could be called on all of them e.g. when
entering a
command like runtime_test).
Regards,
Jeroen
prev parent reply other threads:[~2015-06-08 21:43 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-05-30 15:50 OMAP baseline test results for v4.1-rc5 Paul Walmsley
2015-05-30 15:56 ` Jeroen Hofstee
2015-05-31 22:15 ` Jeroen Hofstee
2015-06-01 5:49 ` Paul Walmsley
2015-06-01 15:29 ` Tero Kristo
2015-06-01 15:30 ` [PATCH] ARM: dts: AM35xx: fix system control module clocks Tero Kristo
2015-06-01 16:56 ` Jeroen Hofstee
2015-06-01 17:31 ` Tony Lindgren
2015-06-01 17:44 ` Paul Walmsley
2015-06-01 18:04 ` Tony Lindgren
2015-06-01 18:06 ` Tony Lindgren
2015-06-01 21:26 ` Paul Walmsley
2015-06-02 7:15 ` Tero Kristo
2015-06-01 21:21 ` Paul Walmsley
2015-06-01 18:04 ` Tero Kristo
2015-06-05 8:01 ` Jeroen Hofstee
2015-06-05 8:04 ` Jeroen Hofstee
2015-06-07 9:41 ` Jeroen Hofstee
2015-06-07 19:56 ` Paul Walmsley
2015-06-08 2:38 ` Paul Walmsley
2015-06-08 22:00 ` Jeroen Hofstee
2015-06-08 21:43 ` Jeroen Hofstee [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=55760C81.3020602@myspectrum.nl \
--to=jeroen@myspectrum.nl \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-omap@vger.kernel.org \
--cc=paul@pwsan.com \
--cc=t-kristo@ti.com \
--cc=tony@atomide.com \
--cc=trini@konsulko.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).