From mboxrd@z Thu Jan 1 00:00:00 1970 From: Przemyslaw Marczak Date: Thu, 19 Feb 2015 13:11:08 +0100 Subject: [U-Boot] [PATCH 1/4] dm: gpio: extend gpio api by dm_gpio_set_pull() In-Reply-To: <54E4C02A.3030905@wwwdotorg.org> References: <1424178544-28632-1-git-send-email-p.marczak@samsung.com> <1424178544-28632-2-git-send-email-p.marczak@samsung.com> <54E4C02A.3030905@wwwdotorg.org> Message-ID: <54E5D2DC.1080508@samsung.com> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de Hello, On 02/18/2015 05:39 PM, Stephen Warren wrote: > On 02/17/2015 10:01 PM, Simon Glass wrote: >> +Stephen who might have an opinion on this. >> >> Hi Przemyslaw, >> >> On 17 February 2015 at 06:09, Przemyslaw Marczak >> wrote: >>> This commits extends: >>> - dm gpio ops by: 'set_pull' call >>> - dm gpio uclass by: dm_gpio_set_pull() function >>> >>> The pull mode is not defined so should be driver specific. >> >> It's good to implement this, but I think you should try to have a >> standard interface. You could define the options you want to support >> and pass in a standard value. >> >> Otherwise we are not really providing a driver abstraction, only an >> interface. > > I don't think that pull is a GPIO-related function/property. At least on > Tegra, the GPIO controller allows you to set the pin direction and the > output value and that's it. Configuring pull-up/down and other IO > related properties is done in the pinmux controller instead. I don't > think we want a standard API that has to touch both HW modules at once. > What common code needs to manipulate a GPIO's pull-up/down setting? As > precedent observe that pull-up/down isn't part of the Linux kernel's > GPIO API, but rather that's part of the SoC-specific pinctrl driver, > which controls pinmuxing etc. > This is a quite different than in the Exynos, where all the gpio functions and properties can be set by few registers within range of each gpio port base address. So in this case we don't touch another hardware module, we modify one of available gpio related registers. Anyway, if we want to have a single and common gpio API in the future, then I think it is better to add pull option. And the driver will implement what is required, instead of provide common and private api for each driver. For the various devices it is unclear, what should be pinmux and what should be gpio driver. Moreover in my opinion from the single external pin point of view the pull up/down is the property of that pin. Actually for Exynos, the pinmux is an abstraction and uses only GPIO driver api in U-Boot. Do we need pinmux class? Best regards, -- Przemyslaw Marczak Samsung R&D Institute Poland Samsung Electronics p.marczak at samsung.com