summaryrefslogtreecommitdiff
path: root/drivers/phy/motorola/phy-mapphone-mdm6600.c
AgeCommit message (Collapse)Author
2018-12-12phy: mapphone-mdm6600: Improve phy related runtime PM callsTony Lindgren
I noticed that phy_pm_runtime_get_sync() and phy_pm_runtime_put() are not currently doing anything for phy-mapphone-mdm6600, only the sysfs interface for works for "auto" and "on". This is because of the shared GPIO pins between mdm6600 USB port and n_gsm port. We have not enabled runtime PM for the phy driver until after we've booted up mdm6600 properly to the USB mode. Otherwise phy_create() would have called pm_runtime_enable() and pm_runtime_no_callbacks() automatically on init. Let's fix this by registering the phy a bit later after we've powered up the mdm6600 USB port. And as the PM runtime support is only needed for the n_gsm mode and not for USB, we can allow the device to idle between phy_mdm6600_power_on() and phy_mdm6600_power_off(). Note that for suspend, runtime_pm is already disabled for the phy so we need to check for pm_runtime_enabled(). Cc: Johan Hovold <jhovold@gmail.com> Cc: Pavel Machek <pavel@ucw.cz> Cc: Sebastian Reichel <sre@kernel.org> Signed-off-by: Tony Lindgren <tony@atomide.com> Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
2018-09-13gpiolib: Pass array info to get/set array functionsJanusz Krzysztofik
In order to make use of array info obtained from gpiod_get_array() and speed up processing of arrays matching single GPIO chip layout, that information must be passed to get/set array functions. Extend the functions' API with that additional parameter and update all users. Pass NULL if a user builds an array itself from single GPIOs. Cc: Jonathan Corbet <corbet@lwn.net> Cc: Miguel Ojeda Sandonis <miguel.ojeda.sandonis@gmail.com> Cc: Geert Uytterhoeven <geert@linux-m68k.org> Cc: Sebastien Bourdelin <sebastien.bourdelin@savoirfairelinux.com> Cc: Lukas Wunner <lukas@wunner.de> Cc: Peter Korsgaard <peter.korsgaard@barco.com> Cc: Peter Rosin <peda@axentia.se> Cc: Andrew Lunn <andrew@lunn.ch> Cc: Florian Fainelli <f.fainelli@gmail.com> Cc: "David S. Miller" <davem@davemloft.net> Cc: Rojhalat Ibrahim <imr@rtschenk.de> Cc: Dominik Brodowski <linux@dominikbrodowski.net> Cc: Russell King <rmk+kernel@armlinux.org.uk> Cc: Kishon Vijay Abraham I <kishon@ti.com> Cc: Tony Lindgren <tony@atomide.com> Cc: Lars-Peter Clausen <lars@metafoo.de> Cc: Michael Hennerich <Michael.Hennerich@analog.com> Cc: Jonathan Cameron <jic23@kernel.org> Cc: Hartmut Knaack <knaack.h@gmx.de> Cc: Peter Meerwald-Stadler <pmeerw@pmeerw.net> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Cc: Jiri Slaby <jslaby@suse.com> Cc: Yegor Yefremov <yegorslists@googlemail.com> Cc: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Signed-off-by: Janusz Krzysztofik <jmkrzyszt@gmail.com> Acked-by: Ulf Hansson <ulf.hansson@linaro.org> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2018-09-13gpiolib: Pass bitmaps, not integer arrays, to get/set arrayJanusz Krzysztofik
Most users of get/set array functions iterate consecutive bits of data, usually a single integer, while processing array of results obtained from, or building an array of values to be passed to those functions. Save time wasted on those iterations by changing the functions' API to accept bitmaps. All current users are updated as well. More benefits from the change are expected as soon as planned support for accepting/passing those bitmaps directly from/to respective GPIO chip callbacks if applicable is implemented. Cc: Jonathan Corbet <corbet@lwn.net> Cc: Miguel Ojeda Sandonis <miguel.ojeda.sandonis@gmail.com> Cc: Sebastien Bourdelin <sebastien.bourdelin@savoirfairelinux.com> Cc: Lukas Wunner <lukas@wunner.de> Cc: Peter Korsgaard <peter.korsgaard@barco.com> Cc: Peter Rosin <peda@axentia.se> Cc: Andrew Lunn <andrew@lunn.ch> Cc: Florian Fainelli <f.fainelli@gmail.com> Cc: "David S. Miller" <davem@davemloft.net> Cc: Rojhalat Ibrahim <imr@rtschenk.de> Cc: Dominik Brodowski <linux@dominikbrodowski.net> Cc: Russell King <rmk+kernel@armlinux.org.uk> Cc: Kishon Vijay Abraham I <kishon@ti.com> Cc: Tony Lindgren <tony@atomide.com> Cc: Lars-Peter Clausen <lars@metafoo.de> Cc: Michael Hennerich <Michael.Hennerich@analog.com> Cc: Jonathan Cameron <jic23@kernel.org> Cc: Hartmut Knaack <knaack.h@gmx.de> Cc: Peter Meerwald-Stadler <pmeerw@pmeerw.net> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Cc: Jiri Slaby <jslaby@suse.com> Cc: Yegor Yefremov <yegorslists@googlemail.com> Cc: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Signed-off-by: Janusz Krzysztofik <jmkrzyszt@gmail.com> Acked-by: Ulf Hansson <ulf.hansson@linaro.org> Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be> Tested-by: Geert Uytterhoeven <geert+renesas@glider.be> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2018-06-29phy: mapphone-mdm6600: Fix wrong enum used for status linesTony Lindgren
Kbuilt test robot reported: drivers/phy/motorola/phy-mapphone-mdm6600.c:188:16: warning: is used uninitialized in this function [-Wuninitialized] val |= values[i] << i; ~~~~~~^~~ Looking at the phy_mdm6600_status() values does get initialized by gpiod_get_array_value_cansleep(), but we are using wrong enum in that function. Let's fix the use, both end up being three though so urgent rush on this one AFAIK. Fixes: 5d1ebbda0318 ("phy: mapphone-mdm6600: Add USB PHY driver for MDM6600 on Droid 4") Reported-by: kbuild test robot <lkp@intel.com> Signed-off-by: Tony Lindgren <tony@atomide.com> Reviewed-by: Pavel Machek <pavel@ucw.cz> Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
2018-05-20phy: mapphone-mdm6600: Add runtime PM support for n_gsm on USB suspendTony Lindgren
We can suspend the mdm6600 over USB via sysfs and then mdm6600 enters a low-power idle mode. In the low-power mode, mdm6600 radio and n_gsm uart are functional but we need to use USB mode0 GPIO pin to send a wake-up pulse to the modem to talk with it over n_gsm. As the GPIO mode0 line is dual purposed and and also needed by the USB PHY driver to boot mdm6600 into the correct USB mode, let's also manage the wake-up GPIO in the USB PHY driver. For the USB PHY idle, there does not anything specific we need to do for runtime PM after getting the PHY configured. The PHY framework already idles the USB PHY when not in use separately from the mdm6600 state. It seems that it takes about 100 - 200ms for mdm6600 to wake up from the low-power idle mode. And then mdm6600 stays awake about 1.2s until it needs to be kicked again. The mdm6600 status GPIO pins don't seem to change state when mdm6600 changes between normal and idle mode. Let's manage the mdm6600 mode with runtime PM. If phy-mapphone-mdm6600 sysfs entry for power/control is set to "on", we keep mdm6600 out of idle by kicking the GPIO line. If the entry is set to "auto" we let mdm6600 enter low-power state. Cc: Marcel Partap <mpartap@gmx.net> Cc: Merlijn Wajer <merlijn@wizzup.org> Cc: Michael Scott <hashcode0f@gmail.com> Cc: NeKit <nekit1000@gmail.com> Cc: Pavel Machek <pavel@ucw.cz> Cc: Sebastian Reichel <sre@kernel.org> Signed-off-by: Tony Lindgren <tony@atomide.com> Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
2018-03-16phy: mapphone-mdm6600: Add USB PHY driver for MDM6600 on Droid 4Tony Lindgren
Let's add support for the GPIO controlled USB PHY on the MDM6600 modem. It is used on some Motorola Mapphone series of phones and tablets such as Droid 4. The MDM6600 is hardwired to the first OHCI port in the Droid 4 case, and is controlled by several GPIOs. The USB PHY is integrated into the MDM6600 device it seems. We know this as we get L3 errors from omap-usb-host if trying to use the PHY before MDM6600 is configured. The GPIOs controlling MDM6600 are used to power device on and off, to configure the USB start-up mode (normal mode versus USB flashing), and they also tell the state of the MDM6600 device. The two start-up mode GPIOs are dual-purposed and used for out of band (OOB) wake-up for USB and TS 27.010 serial mux. But we need to configure the USB start-up mode first to get MDM6600 booted in the right mode to be usable in the first place. Note that the Motorola Mapphone Linux kernel tree has a "radio-ctrl" driver for modems. But it really does not control the radio at all, it just controls the modem power and start-up mode for USB. So I came to the conclusion that we're better off having this done in the USB PHY driver. For adding support for USB flashing mode, we can later on add a kernel module option for flash_mode=1 or something similar. Also note that currently there is no PM runtime support for the OHCI on omap variant SoCs. So for low(er) power idle states, currenty both ohci-platform and phy-mapphone-mdm6600 must be unloaded or unbound. For reference here is what I measured for total power consumption on an idle Droid 4 with and without USB related MDM6600 modules: idle lcd off phy-mapphone-mdm6600 ohci-platform 153mW 284mW 344mW So it seems that MDM6600 is currently not yet idling even with it's radio turned off, but that's something that is beyond the control of this USB PHY driver. This patch does get us to the point where modem data and GPS are usable with libqmi and ModemManager for example. Voice calls need more audio driver work. Cc: devicetree@vger.kernel.org Cc: Mark Rutland <mark.rutland@arm.com> Cc: Marcel Partap <mpartap@gmx.net> Cc: Michael Scott <michael.scott@linaro.org> Cc: Rob Herring <robh+dt@kernel.org> Reviewed-by: Rob Herring <robh@kernel.org> Signed-off-by: Tony Lindgren <tony@atomide.com> Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>