From: Stephen Warren <swarren@wwwdotorg.org>
To: u-boot@lists.denx.de
Subject: [U-Boot] [PATCH v2 5/7] tegra: Implement gpio_early_init() on Tamonten
Date: Tue, 29 May 2012 10:06:50 -0600 [thread overview]
Message-ID: <4FC4F41A.5010804@wwwdotorg.org> (raw)
In-Reply-To: <20120529145712.GA4422@avionic-0098.mockup.avionic-design.de>
On 05/29/2012 08:57 AM, Thierry Reding wrote:
> * Kai Poggensee wrote:
>>
>> Hi Thierry,
>>
>> On 25.05.2012 19:40, Thierry Reding wrote:
>>> * Stephen Warren wrote:
>>>> On 05/25/2012 07:46 AM, Thierry Reding wrote:
>>>>> The PI4 GPIO is used on Tamonten to reset carrier board
>>>>> peripherals. Power sequencing hardware on the carrier pulls
>>>>> the reset low before powering up the Tegra, and the CPU is
>>>>> supposed to signal readiness, and therefore bring
>>>>> peripherals out of reset by pulling PI4 high.
>>>>
>>>>> +void gpio_early_init(void) +{ + gpio_request(GPIO_PI4,
>>>>> NULL); + gpio_direction_output(GPIO_PI4, 1); +
>>>>> gpio_free(GPIO_PI4); +}
>>>>
>>>> Do you really mean to free the GPIO here?
>>>>
>>>> While gpio_free() does not do this at present, it seems
>>>> perfectly reasonable for someone to modify gpio_free() so
>>>> that instead of leaving the HW in some random state when
>>>> free, it actively reprograms the pin to be an input instead,
>>>> since that's the most conflict-free setting when the pin is
>>>> actively unused.
>>>
>>> I believe that even a pulse would be enough for the undelying
>>> mechanisms to take effect, but I'll have to check with our
>>> hardware engineers to be sure.
>>
>> As an aside: A pulse wont be enough in this specific case as a
>> pull-down on the carrier would lead to the nRST going low thus
>> resetting the baseboard peripherals.
>>
>> Plus there is a status LED on the Tamonten Evaluation carrier
>> that would then indicate the red "system not up".
>
> So this means we'll have to hand this over to the kernel somehow.
> Stephen, I'm not aware of any mechanism to pass static GPIO
> configuration via the FDT. Are there any plans to add something
> like it? The problem I see is that the pinmux binding might
> reconfigure the corresponding pin and therefore reset the
> peripherals.
The pinctrl and GPIO drivers will only reconfigure groups/pins they're
asked to, so I don't believe there will be any problem here, assuming
the DT contains tables that are correct.
next prev parent reply other threads:[~2012-05-29 16:06 UTC|newest]
Thread overview: 29+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-05-25 13:46 [U-Boot] [PATCH v2 1/7] tegra: Rework Tamonten support Thierry Reding
2012-05-25 13:46 ` [U-Boot] [PATCH v2 2/7] tegra: medcom: Add device tree support Thierry Reding
2012-05-25 13:46 ` [U-Boot] [PATCH v2 3/7] tegra: plutux: " Thierry Reding
2012-05-25 13:46 ` [U-Boot] [PATCH v2 4/7] tegra: Allow boards to perform early GPIO setup Thierry Reding
2012-05-25 16:24 ` Stephen Warren
2012-05-25 17:31 ` Thierry Reding
2012-05-25 17:59 ` Thierry Reding
2012-05-31 20:35 ` Tom Warren
2012-06-04 6:09 ` Thierry Reding
2012-06-04 16:47 ` Tom Warren
2012-05-25 13:46 ` [U-Boot] [PATCH v2 5/7] tegra: Implement gpio_early_init() on Tamonten Thierry Reding
2012-05-25 16:27 ` Stephen Warren
2012-05-25 17:40 ` Thierry Reding
2012-05-25 18:56 ` Kai Poggensee
2012-05-29 14:57 ` Thierry Reding
2012-05-29 16:06 ` Stephen Warren [this message]
2012-05-25 13:46 ` [U-Boot] [PATCH v2 6/7] tegra: Use SD write-protect GPIO " Thierry Reding
2012-05-25 13:46 ` [U-Boot] [PATCH v2 7/7] tegra: Add Tamonten Evaluation Carrier support Thierry Reding
2012-05-25 16:31 ` Stephen Warren
2012-06-08 20:01 ` [U-Boot] [PATCH v2 1/7] tegra: Rework Tamonten support Allen Martin
2012-06-08 21:07 ` Stephen Warren
2012-06-08 21:27 ` Allen Martin
2012-06-09 5:28 ` Stephen Warren
2012-06-09 6:25 ` Allen Martin
2012-06-09 16:18 ` Stephen Warren
2012-06-11 9:29 ` Thierry Reding
2012-06-11 17:59 ` Allen Martin
2012-06-11 18:07 ` Thierry Reding
2012-06-11 18:03 ` Allen Martin
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=4FC4F41A.5010804@wwwdotorg.org \
--to=swarren@wwwdotorg.org \
--cc=u-boot@lists.denx.de \
/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