From mboxrd@z Thu Jan 1 00:00:00 1970 From: Stephen Warren Date: Tue, 29 May 2012 10:06:50 -0600 Subject: [U-Boot] [PATCH v2 5/7] tegra: Implement gpio_early_init() on Tamonten In-Reply-To: <20120529145712.GA4422@avionic-0098.mockup.avionic-design.de> References: <1337953588-20696-1-git-send-email-thierry.reding@avionic-design.de> <1337953588-20696-5-git-send-email-thierry.reding@avionic-design.de> <4FBFB2D6.1040602@wwwdotorg.org> <20120525174003.GC18894@avionic-0098.adnet.avionic-design.de> <4FBFD5C9.4040605@avionic-design.de> <20120529145712.GA4422@avionic-0098.mockup.avionic-design.de> Message-ID: <4FC4F41A.5010804@wwwdotorg.org> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.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.