From mboxrd@z Thu Jan 1 00:00:00 1970 From: Stephen Warren Subject: Re: Active low GPIOs (was [PATCH v1 1/4] i2c: mux: Add i2c-arbitrator 'mux' driver) Date: Fri, 15 Feb 2013 13:42:16 -0700 Message-ID: <511E9DA8.70207@wwwdotorg.org> References: <511D7EF7.9000803@wwwdotorg.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: devicetree-discuss-bounces+gldd-devicetree-discuss=m.gmane.org-uLR06cmDAlY/bJ5BZ2RsiQ@public.gmane.org Sender: "devicetree-discuss" To: Linus Walleij Cc: linux-doc-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, Daniel Kurtz , Wolfram Sang , "linux-i2c-u79uwXL29TY76Z2rM5mHXA@public.gmane.org" , Lee Jones , Guenter Roeck , Stephen Warren , Ben Dooks , u.kleine-koenig-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org, Chris Ball , Grant Grundler , devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ@public.gmane.org, Rob Herring , Jean Delvare , Alexandre Courbot , "Ben Dooks (embedded platforms)" , Girish Shivananjappa , "bhushan.r" , Naveen Krishna Chatradhi , "sreekumar.c" , Mark Brown , linux-kernel-u79uwXL29Tb/PtFMR13I2A@public.gmane.org List-Id: devicetree@vger.kernel.org On 02/15/2013 01:34 PM, Linus Walleij wrote: > On Fri, Feb 15, 2013 at 1:19 AM, Stephen Warren wrote: >> On 02/14/2013 05:02 PM, Linus Walleij wrote: >>> On Thu, Feb 14, 2013 at 6:05 PM, Doug Anderson wrote: >> ... >>>> One argument for keeping "cd-inverted" too is >>>> for controllers that don't use a GPIO for card detect. >>>> In this case >>>> you could imagine a MMC controller that has a "card detect" on >>>> special-purpose pin and accessible via a status register. >>> >>> This is actually the case with Integrator/CP and Versatile/AB. >> >> In this case, I assume that the driver for the HW has custom code to >> read the MMC controller's CD register bit, and hence it knows whether >> the HW inverts it, and hence we don't need a property in DT to say so; >> the driver will simply read the bit, invert it, and return it all >> transparently? After all, the inversion isn't board-specific but IP >> block specific. > > No that's not how it works ... heh. > > It calls back to the platform: > > include/linux/amba/mmci.h > * @status: if no GPIO read function was given to the block in > * gpio_wp (below) this function will be called to determine > * whether a card is present in the MMC slot or not > (...) > struct mmci_platform_data { > (...) > unsigned int (*status)(struct device *); > (...) > bool cd_invert; > > So the flag tells whether that signal should be interpreted > as inverted or not. The same flag is used for GPIO > insertion detection. > > The code reading the status will read a certain register > like this (arch/arm/mach-integrator_cp.c): > > static unsigned int mmc_status(struct device *dev) > { > unsigned int status = readl(__io_address(0xca000000 + 4)); > writel(8, intcp_con_base + 8); > > return status & 8; > } > > 0xca000000 + 4 is just the second 32bit word in the system > controller. This address range and that very word is used > for various stuff, so it's not like a general-purpose GPIO > or anything, it's just that one pin being readable throgh that > very bit. Surely a GPIO is exactly what that is... It might be annoying to create a GPIO controller driver for just that, but that seems like the simplest way to implement that HW from a device tree perspective. With DT, it'd be painful to plug in that board callback into the platform data there.