On 07/01/2013 11:37 PM, Hiremath, Vaibhav wrote:
-----Original Message-----
From: Balbi, Felipe
Sent: Friday, June 28, 2013 4:24 PM
To: Hiremath, Vaibhav
Cc: Menon, Nishanth; Peter Korsgaard; Kevin Hilman; Balbi, Felipe; Paul
Walmsley; linux-omap@vger.kernel.org; Tony Lindgren; Sebastian Andrzej
Siewior
Subject: Re: reset handling in am335x hwmod data
Hi,
On Mon, May 20, 2013 at 08:20:29PM +0200, Hiremath, Vaibhav wrote:
-----Original Message-----
From: Menon, Nishanth
Sent: Monday, May 20, 2013 11:34 PM
To: Hiremath, Vaibhav
Cc: Peter Korsgaard; Kevin Hilman; Balbi, Felipe; Paul Walmsley;
linux-
o...@vger.kernel.org; Tony Lindgren
Subject: Re: reset handling in am335x hwmod data
On 12:47-20130520, Hiremath, Vaibhav wrote:
[...]
On 20:10-20130517, Peter Korsgaard wrote:
"Kevin" == Kevin Hilman <khil...@linaro.org>
writes:
>> In this case, we cannot reset that bank, otherwise
Starter
Kit
will
>> never boot in mainline. Bad PCB design, I know, but
it's
not
something
>> we can change now :-)
Kevin> FWIW, we've seen this before (GPIO connected to
PMIC
reset
is
a
Kevin> fun one), and this is why we have
omap_hwmod_no_setup_reset().
Yes, but there's no dts bindings for this, and from a
quick
test
the
reset handling happens before the device tree is
probed.
I have the same issue with TPS62361 on Palmas -> GPIO
controls
the
voltage register supplying MPU, without any driver
setting
things
up,
GPIO gets reset and obviously voltage value switches to
an
voltage
where
device does not function.
Solution I am working on to solve this is [1]: snippet is
part of
a
patch that I am working on atm.
This is the right way to do it IMHO. Will allow the
driver to
exist
when
HWMOD will be eventually replaced by some other
framework.
[1]: http://pastebin.com/XPmAB1Zb
Both seems to be different to me. What we need is to
Avoid reset of whole GPIO bank during kernel boot.
Yes - that is what the above does - as long as the GPIO is
requested
and
set to the right level by the relevant driver, it is not
"unused"
and
hence not reset at late_init.
May be I am missing something here,
Isn't _setup_reset() function asserts ocp_reset? And it is
core_initcall.
Hmm.. You are right, I missed that :(
I am a little unclear as to why this needs to have anything to
do
with
the precise under-lying mechanism (hwmod or something else).
May be
"both seem to be different to me" needs a little further
elaboration?
GPIO is connected to the DDR VTT control pin, and we have
observed
that
Due to GPIO bank reset as part of hwmod init during bootup.
Is this because there is no need for an EMIF driver to handle
DDR?
and
reset of the GPIO will occur as EMIF is configured at
bootloader
and
there is no need to do that in kernel, correspondingly there is
no
"driver" to hold the gpio?
Ideally, it would have been much better if drivers starts
handling
Idle, ocp reset and standby on their own (killing
dependency on
hwmod
init layer).
But looking at current state,
I agree we need to use DT property here, so how about
Adding DT property to GPIO node itself. But we have to
parse
I believe you mean at OMAP specific DT property for hwmod?
something like ti,hwmod-no-init-reset?
That’s the idea.
It early during hwmod init stage. We should read all DT
nodes
Inside function __setup() function, that way can get rid of
HWMOD_INIT_NO_RESET flag completely. Also, this will handle
Both ocp_reset and domain reset.
Forgot to mention,
Since this is kernel boot failure issue, I think,
By the time we reach to conclusion, another approach is to
set "HWMOD_INIT_NO_RESET" flag For GPIO0 bank.
a) if the GPIO gets moved over to some other GPIO bank on
another
platform,
this wont work
Yes that’s true, but such schematic interface is not recommended.
And we have not seen any known side-effect of not resetting GPIO0
bank.
unless you mark the GPIO as taken, another driver could in-
adverantly
take over the GPIO and set it to a wrong level (we had a similar
story
with LED gpio between Panda Vs Panda-ES).
b) for platforms that dont use gpio to hold DDR power, maybe
this
is
not
even relevant and the GPIO bank can safely be reset?
As I mentioned, there is no known side-effect of not resetting
GPIO
bank 0.
It should depend on the platform.
There are other uses for hwmod-no-reset -> Eg. boot logo displayed
by
bootloader - if there is a reset of DSS block and re-configuration,
we'd
notice a blank-out, which is not desirable either. There could be a
few
other usage based on no-reset.
In all cases, you'd prefer to make this:
a) platform dependent (board dts)
b) reserve GPIO as well so that no other driver'd take it - if they
attempt ther'd at least be some form of warning.
Completely agree with you on both the points, and my point and all my
comments
Were more related to option 'a' above.
so, what happened here ? Will we not have AM335x-SK working in mainline
just because of the GPIO block being reset ?
Nishant started implementing on this, not sure what state it is in.
Nope. I am not working on this.
--
Regards,
Nishanth Menon
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
