public inbox for u-boot@lists.denx.de
 help / color / mirror / Atom feed
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.

  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