All of lore.kernel.org
 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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.