linux-stable/drivers/staging/greybus/arche-platform.c

436 lines
12 KiB
C
Raw Normal View History

greybus: platform: Add platform driver for DB3 AP bridge With DB3, we now have AP as a master as far as AP bridges are concerned. SVC will talk only to AP and AP will control bridges; unlike other module interfaces. So AP supposed to manage/control bridges in all power states including power on reset. During power on reset AP should follow below sequence - Sequence (treated as a Cold Boot) Stage-1 ======= AP: - Power On (Power up from PMIC to AP) - AP start booting Since power to AP bridges are controlled through gpio, power is gated to APB1 & 2 No ref_clk to APB available (under SVC's control) - AP configures USB hub to enable HSIC interface to APB - As part of platform driver probe, AP follow below sequence - Set the pinctrl in default state - Hold APBs in reset by pulling down reset pin - Enable power to APB by enabling regulator and switches - De-assert (set 'low') 'boot_ret' signal - AP will assert (set 'high') the wake_detect signal, triggering connect/detect event to the SVC - AP waits for wake pulse from SVC SVC: - Power On (power up from PMIC to SVC) - SVC starts booting - SVC will de-assert reset signal to unipro switch - Switch starts booting - SVC confirms switch boot status using SPI (or something) - SVC waits for 300 msec (ES2 known issue) - SVC waits for detect/connect event from AP Stage-2 ======= SVC: - ON connect/detect event, SVC send back wake pulse (cold boot) to AP over wake_detect pin, if SVC boot is completed. AP: - On wake pulse from SVC (for cold boot), AP de-asserts (set high') reset signal to APB 1 and/or 2 - Bridges starts booting - Eventually Unipro linkup occurs Testing: - Build tested against Helium kernel - Due to unavailability of MSM and DB3 platform, only minimal testing has been done. - Code has been modified for validation on Helium + SDB platform. Mostly dts changes for gpio numbers And debug messages to check gpio values - On Helium + SDB platform, with addition of debug messages validated the sequence. TODO list: - Currently _only_ supports power on sequence (cold boot). Both warm and cold boot support. Cold and Warm boot is differentiated based on pulse width of wake_detect signal >=5 msec = Cold boot else Warm boot - No support for Power management So the "power-down", "power-off", "wake_in" and "wake_out" signals are not explored/implemented. - Support for Work thread repetitive wake signal if no response from peer May required for PM support, as we have delays in the sequences - pinctrl states, specially to make sure we enable right pullup or pulldown when we set wake_detect pin to input - Convert gpio list into an array, and associated xxx-gpio-name property Signed-off-by: Vaibhav Hiremath <vaibhav.hiremath@linaro.org> Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
2015-10-21 11:20:20 +00:00
/*
* Arche Platform driver to enable Unipro link.
greybus: platform: Add platform driver for DB3 AP bridge With DB3, we now have AP as a master as far as AP bridges are concerned. SVC will talk only to AP and AP will control bridges; unlike other module interfaces. So AP supposed to manage/control bridges in all power states including power on reset. During power on reset AP should follow below sequence - Sequence (treated as a Cold Boot) Stage-1 ======= AP: - Power On (Power up from PMIC to AP) - AP start booting Since power to AP bridges are controlled through gpio, power is gated to APB1 & 2 No ref_clk to APB available (under SVC's control) - AP configures USB hub to enable HSIC interface to APB - As part of platform driver probe, AP follow below sequence - Set the pinctrl in default state - Hold APBs in reset by pulling down reset pin - Enable power to APB by enabling regulator and switches - De-assert (set 'low') 'boot_ret' signal - AP will assert (set 'high') the wake_detect signal, triggering connect/detect event to the SVC - AP waits for wake pulse from SVC SVC: - Power On (power up from PMIC to SVC) - SVC starts booting - SVC will de-assert reset signal to unipro switch - Switch starts booting - SVC confirms switch boot status using SPI (or something) - SVC waits for 300 msec (ES2 known issue) - SVC waits for detect/connect event from AP Stage-2 ======= SVC: - ON connect/detect event, SVC send back wake pulse (cold boot) to AP over wake_detect pin, if SVC boot is completed. AP: - On wake pulse from SVC (for cold boot), AP de-asserts (set high') reset signal to APB 1 and/or 2 - Bridges starts booting - Eventually Unipro linkup occurs Testing: - Build tested against Helium kernel - Due to unavailability of MSM and DB3 platform, only minimal testing has been done. - Code has been modified for validation on Helium + SDB platform. Mostly dts changes for gpio numbers And debug messages to check gpio values - On Helium + SDB platform, with addition of debug messages validated the sequence. TODO list: - Currently _only_ supports power on sequence (cold boot). Both warm and cold boot support. Cold and Warm boot is differentiated based on pulse width of wake_detect signal >=5 msec = Cold boot else Warm boot - No support for Power management So the "power-down", "power-off", "wake_in" and "wake_out" signals are not explored/implemented. - Support for Work thread repetitive wake signal if no response from peer May required for PM support, as we have delays in the sequences - pinctrl states, specially to make sure we enable right pullup or pulldown when we set wake_detect pin to input - Convert gpio list into an array, and associated xxx-gpio-name property Signed-off-by: Vaibhav Hiremath <vaibhav.hiremath@linaro.org> Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
2015-10-21 11:20:20 +00:00
*
* Copyright 2014-2015 Google Inc.
* Copyright 2014-2015 Linaro Ltd.
*
* Released under the GPLv2 only.
*/
#include <linux/clk.h>
greybus: arche-platform: Add wake/detect support along with handshaking with AP Add wake_detect support to arche-platform driver which is responsible for SVC control. This patch also adds code for handshaking between AP <=> SVC. The sequence is, 1. AP boots To keep compatibility between DB3 and EVT platform, SVC will be help in reset and AP driver would release it at appropriate time. wake/detect pin (WD8A) = Low reset (SVC/APB1/APB2) = Asserted (as per polarity) 2. AP Driver gets inserted 2.1. AP will deassert reset to SVC (following power on sequence) 2.2. SVC allows 360 milliseconds to elapse after switch boots to work around bug described in ENG-330. 2.3. AP asserts wake/detect pin (WD8A = HIGH) 3. SVC detects assertion of wake/detect pin, and sends "wake out" signal to AP 4. AP receives "wake out" signal, takes AP Bridges through their power on reset sequence as defined in the bridge ASIC reference manuals 5. AP takes USB3613 through its power on reset sequence 6. AP should enumerates AP Bridges Note: ISR has been deliberately removed (not merged) as we are still not sure how it will be used, in runtime usage context. Driver as such doesn't do anything for runtime assert-n-deassert of reset to SVC/APB's, it just simply offloads it to user by exporting required gpio's. The exported gpio's are required for FW flashing from user space. When it comes to usersace manipulated control sequence, user has to manage. Signed-off-by: Vaibhav Hiremath <vaibhav.hiremath@linaro.org> Tested-by: Michael Scott <michael.scott@linaro.org> Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
2016-01-11 12:11:24 +00:00
#include <linux/delay.h>
#include <linux/gpio.h>
#include <linux/init.h>
#include <linux/module.h>
greybus: platform: Add platform driver for DB3 AP bridge With DB3, we now have AP as a master as far as AP bridges are concerned. SVC will talk only to AP and AP will control bridges; unlike other module interfaces. So AP supposed to manage/control bridges in all power states including power on reset. During power on reset AP should follow below sequence - Sequence (treated as a Cold Boot) Stage-1 ======= AP: - Power On (Power up from PMIC to AP) - AP start booting Since power to AP bridges are controlled through gpio, power is gated to APB1 & 2 No ref_clk to APB available (under SVC's control) - AP configures USB hub to enable HSIC interface to APB - As part of platform driver probe, AP follow below sequence - Set the pinctrl in default state - Hold APBs in reset by pulling down reset pin - Enable power to APB by enabling regulator and switches - De-assert (set 'low') 'boot_ret' signal - AP will assert (set 'high') the wake_detect signal, triggering connect/detect event to the SVC - AP waits for wake pulse from SVC SVC: - Power On (power up from PMIC to SVC) - SVC starts booting - SVC will de-assert reset signal to unipro switch - Switch starts booting - SVC confirms switch boot status using SPI (or something) - SVC waits for 300 msec (ES2 known issue) - SVC waits for detect/connect event from AP Stage-2 ======= SVC: - ON connect/detect event, SVC send back wake pulse (cold boot) to AP over wake_detect pin, if SVC boot is completed. AP: - On wake pulse from SVC (for cold boot), AP de-asserts (set high') reset signal to APB 1 and/or 2 - Bridges starts booting - Eventually Unipro linkup occurs Testing: - Build tested against Helium kernel - Due to unavailability of MSM and DB3 platform, only minimal testing has been done. - Code has been modified for validation on Helium + SDB platform. Mostly dts changes for gpio numbers And debug messages to check gpio values - On Helium + SDB platform, with addition of debug messages validated the sequence. TODO list: - Currently _only_ supports power on sequence (cold boot). Both warm and cold boot support. Cold and Warm boot is differentiated based on pulse width of wake_detect signal >=5 msec = Cold boot else Warm boot - No support for Power management So the "power-down", "power-off", "wake_in" and "wake_out" signals are not explored/implemented. - Support for Work thread repetitive wake signal if no response from peer May required for PM support, as we have delays in the sequences - pinctrl states, specially to make sure we enable right pullup or pulldown when we set wake_detect pin to input - Convert gpio list into an array, and associated xxx-gpio-name property Signed-off-by: Vaibhav Hiremath <vaibhav.hiremath@linaro.org> Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
2015-10-21 11:20:20 +00:00
#include <linux/of_gpio.h>
#include <linux/of_platform.h>
greybus: platform: Add platform driver for DB3 AP bridge With DB3, we now have AP as a master as far as AP bridges are concerned. SVC will talk only to AP and AP will control bridges; unlike other module interfaces. So AP supposed to manage/control bridges in all power states including power on reset. During power on reset AP should follow below sequence - Sequence (treated as a Cold Boot) Stage-1 ======= AP: - Power On (Power up from PMIC to AP) - AP start booting Since power to AP bridges are controlled through gpio, power is gated to APB1 & 2 No ref_clk to APB available (under SVC's control) - AP configures USB hub to enable HSIC interface to APB - As part of platform driver probe, AP follow below sequence - Set the pinctrl in default state - Hold APBs in reset by pulling down reset pin - Enable power to APB by enabling regulator and switches - De-assert (set 'low') 'boot_ret' signal - AP will assert (set 'high') the wake_detect signal, triggering connect/detect event to the SVC - AP waits for wake pulse from SVC SVC: - Power On (power up from PMIC to SVC) - SVC starts booting - SVC will de-assert reset signal to unipro switch - Switch starts booting - SVC confirms switch boot status using SPI (or something) - SVC waits for 300 msec (ES2 known issue) - SVC waits for detect/connect event from AP Stage-2 ======= SVC: - ON connect/detect event, SVC send back wake pulse (cold boot) to AP over wake_detect pin, if SVC boot is completed. AP: - On wake pulse from SVC (for cold boot), AP de-asserts (set high') reset signal to APB 1 and/or 2 - Bridges starts booting - Eventually Unipro linkup occurs Testing: - Build tested against Helium kernel - Due to unavailability of MSM and DB3 platform, only minimal testing has been done. - Code has been modified for validation on Helium + SDB platform. Mostly dts changes for gpio numbers And debug messages to check gpio values - On Helium + SDB platform, with addition of debug messages validated the sequence. TODO list: - Currently _only_ supports power on sequence (cold boot). Both warm and cold boot support. Cold and Warm boot is differentiated based on pulse width of wake_detect signal >=5 msec = Cold boot else Warm boot - No support for Power management So the "power-down", "power-off", "wake_in" and "wake_out" signals are not explored/implemented. - Support for Work thread repetitive wake signal if no response from peer May required for PM support, as we have delays in the sequences - pinctrl states, specially to make sure we enable right pullup or pulldown when we set wake_detect pin to input - Convert gpio list into an array, and associated xxx-gpio-name property Signed-off-by: Vaibhav Hiremath <vaibhav.hiremath@linaro.org> Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
2015-10-21 11:20:20 +00:00
#include <linux/pinctrl/consumer.h>
#include <linux/platform_device.h>
#include <linux/pm.h>
#include "arche_platform.h"
greybus: platform: Add platform driver for DB3 AP bridge With DB3, we now have AP as a master as far as AP bridges are concerned. SVC will talk only to AP and AP will control bridges; unlike other module interfaces. So AP supposed to manage/control bridges in all power states including power on reset. During power on reset AP should follow below sequence - Sequence (treated as a Cold Boot) Stage-1 ======= AP: - Power On (Power up from PMIC to AP) - AP start booting Since power to AP bridges are controlled through gpio, power is gated to APB1 & 2 No ref_clk to APB available (under SVC's control) - AP configures USB hub to enable HSIC interface to APB - As part of platform driver probe, AP follow below sequence - Set the pinctrl in default state - Hold APBs in reset by pulling down reset pin - Enable power to APB by enabling regulator and switches - De-assert (set 'low') 'boot_ret' signal - AP will assert (set 'high') the wake_detect signal, triggering connect/detect event to the SVC - AP waits for wake pulse from SVC SVC: - Power On (power up from PMIC to SVC) - SVC starts booting - SVC will de-assert reset signal to unipro switch - Switch starts booting - SVC confirms switch boot status using SPI (or something) - SVC waits for 300 msec (ES2 known issue) - SVC waits for detect/connect event from AP Stage-2 ======= SVC: - ON connect/detect event, SVC send back wake pulse (cold boot) to AP over wake_detect pin, if SVC boot is completed. AP: - On wake pulse from SVC (for cold boot), AP de-asserts (set high') reset signal to APB 1 and/or 2 - Bridges starts booting - Eventually Unipro linkup occurs Testing: - Build tested against Helium kernel - Due to unavailability of MSM and DB3 platform, only minimal testing has been done. - Code has been modified for validation on Helium + SDB platform. Mostly dts changes for gpio numbers And debug messages to check gpio values - On Helium + SDB platform, with addition of debug messages validated the sequence. TODO list: - Currently _only_ supports power on sequence (cold boot). Both warm and cold boot support. Cold and Warm boot is differentiated based on pulse width of wake_detect signal >=5 msec = Cold boot else Warm boot - No support for Power management So the "power-down", "power-off", "wake_in" and "wake_out" signals are not explored/implemented. - Support for Work thread repetitive wake signal if no response from peer May required for PM support, as we have delays in the sequences - pinctrl states, specially to make sure we enable right pullup or pulldown when we set wake_detect pin to input - Convert gpio list into an array, and associated xxx-gpio-name property Signed-off-by: Vaibhav Hiremath <vaibhav.hiremath@linaro.org> Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
2015-10-21 11:20:20 +00:00
struct arche_platform_drvdata {
/* Control GPIO signals to and from AP <=> SVC */
int svc_reset_gpio;
bool is_reset_act_hi;
int svc_sysboot_gpio;
greybus: arche-platform: Add wake/detect support along with handshaking with AP Add wake_detect support to arche-platform driver which is responsible for SVC control. This patch also adds code for handshaking between AP <=> SVC. The sequence is, 1. AP boots To keep compatibility between DB3 and EVT platform, SVC will be help in reset and AP driver would release it at appropriate time. wake/detect pin (WD8A) = Low reset (SVC/APB1/APB2) = Asserted (as per polarity) 2. AP Driver gets inserted 2.1. AP will deassert reset to SVC (following power on sequence) 2.2. SVC allows 360 milliseconds to elapse after switch boots to work around bug described in ENG-330. 2.3. AP asserts wake/detect pin (WD8A = HIGH) 3. SVC detects assertion of wake/detect pin, and sends "wake out" signal to AP 4. AP receives "wake out" signal, takes AP Bridges through their power on reset sequence as defined in the bridge ASIC reference manuals 5. AP takes USB3613 through its power on reset sequence 6. AP should enumerates AP Bridges Note: ISR has been deliberately removed (not merged) as we are still not sure how it will be used, in runtime usage context. Driver as such doesn't do anything for runtime assert-n-deassert of reset to SVC/APB's, it just simply offloads it to user by exporting required gpio's. The exported gpio's are required for FW flashing from user space. When it comes to usersace manipulated control sequence, user has to manage. Signed-off-by: Vaibhav Hiremath <vaibhav.hiremath@linaro.org> Tested-by: Michael Scott <michael.scott@linaro.org> Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
2016-01-11 12:11:24 +00:00
int wake_detect_gpio; /* bi-dir,maps to WAKE_MOD & WAKE_FRAME signals */
greybus: platform: Add platform driver for DB3 AP bridge With DB3, we now have AP as a master as far as AP bridges are concerned. SVC will talk only to AP and AP will control bridges; unlike other module interfaces. So AP supposed to manage/control bridges in all power states including power on reset. During power on reset AP should follow below sequence - Sequence (treated as a Cold Boot) Stage-1 ======= AP: - Power On (Power up from PMIC to AP) - AP start booting Since power to AP bridges are controlled through gpio, power is gated to APB1 & 2 No ref_clk to APB available (under SVC's control) - AP configures USB hub to enable HSIC interface to APB - As part of platform driver probe, AP follow below sequence - Set the pinctrl in default state - Hold APBs in reset by pulling down reset pin - Enable power to APB by enabling regulator and switches - De-assert (set 'low') 'boot_ret' signal - AP will assert (set 'high') the wake_detect signal, triggering connect/detect event to the SVC - AP waits for wake pulse from SVC SVC: - Power On (power up from PMIC to SVC) - SVC starts booting - SVC will de-assert reset signal to unipro switch - Switch starts booting - SVC confirms switch boot status using SPI (or something) - SVC waits for 300 msec (ES2 known issue) - SVC waits for detect/connect event from AP Stage-2 ======= SVC: - ON connect/detect event, SVC send back wake pulse (cold boot) to AP over wake_detect pin, if SVC boot is completed. AP: - On wake pulse from SVC (for cold boot), AP de-asserts (set high') reset signal to APB 1 and/or 2 - Bridges starts booting - Eventually Unipro linkup occurs Testing: - Build tested against Helium kernel - Due to unavailability of MSM and DB3 platform, only minimal testing has been done. - Code has been modified for validation on Helium + SDB platform. Mostly dts changes for gpio numbers And debug messages to check gpio values - On Helium + SDB platform, with addition of debug messages validated the sequence. TODO list: - Currently _only_ supports power on sequence (cold boot). Both warm and cold boot support. Cold and Warm boot is differentiated based on pulse width of wake_detect signal >=5 msec = Cold boot else Warm boot - No support for Power management So the "power-down", "power-off", "wake_in" and "wake_out" signals are not explored/implemented. - Support for Work thread repetitive wake signal if no response from peer May required for PM support, as we have delays in the sequences - pinctrl states, specially to make sure we enable right pullup or pulldown when we set wake_detect pin to input - Convert gpio list into an array, and associated xxx-gpio-name property Signed-off-by: Vaibhav Hiremath <vaibhav.hiremath@linaro.org> Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
2015-10-21 11:20:20 +00:00
enum arche_platform_state state;
unsigned int svc_refclk_req;
struct clk *svc_ref_clk;
greybus: platform: Add platform driver for DB3 AP bridge With DB3, we now have AP as a master as far as AP bridges are concerned. SVC will talk only to AP and AP will control bridges; unlike other module interfaces. So AP supposed to manage/control bridges in all power states including power on reset. During power on reset AP should follow below sequence - Sequence (treated as a Cold Boot) Stage-1 ======= AP: - Power On (Power up from PMIC to AP) - AP start booting Since power to AP bridges are controlled through gpio, power is gated to APB1 & 2 No ref_clk to APB available (under SVC's control) - AP configures USB hub to enable HSIC interface to APB - As part of platform driver probe, AP follow below sequence - Set the pinctrl in default state - Hold APBs in reset by pulling down reset pin - Enable power to APB by enabling regulator and switches - De-assert (set 'low') 'boot_ret' signal - AP will assert (set 'high') the wake_detect signal, triggering connect/detect event to the SVC - AP waits for wake pulse from SVC SVC: - Power On (power up from PMIC to SVC) - SVC starts booting - SVC will de-assert reset signal to unipro switch - Switch starts booting - SVC confirms switch boot status using SPI (or something) - SVC waits for 300 msec (ES2 known issue) - SVC waits for detect/connect event from AP Stage-2 ======= SVC: - ON connect/detect event, SVC send back wake pulse (cold boot) to AP over wake_detect pin, if SVC boot is completed. AP: - On wake pulse from SVC (for cold boot), AP de-asserts (set high') reset signal to APB 1 and/or 2 - Bridges starts booting - Eventually Unipro linkup occurs Testing: - Build tested against Helium kernel - Due to unavailability of MSM and DB3 platform, only minimal testing has been done. - Code has been modified for validation on Helium + SDB platform. Mostly dts changes for gpio numbers And debug messages to check gpio values - On Helium + SDB platform, with addition of debug messages validated the sequence. TODO list: - Currently _only_ supports power on sequence (cold boot). Both warm and cold boot support. Cold and Warm boot is differentiated based on pulse width of wake_detect signal >=5 msec = Cold boot else Warm boot - No support for Power management So the "power-down", "power-off", "wake_in" and "wake_out" signals are not explored/implemented. - Support for Work thread repetitive wake signal if no response from peer May required for PM support, as we have delays in the sequences - pinctrl states, specially to make sure we enable right pullup or pulldown when we set wake_detect pin to input - Convert gpio list into an array, and associated xxx-gpio-name property Signed-off-by: Vaibhav Hiremath <vaibhav.hiremath@linaro.org> Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
2015-10-21 11:20:20 +00:00
struct pinctrl *pinctrl;
struct pinctrl_state *pin_default;
int num_apbs;
greybus: arche-platform: Add wake/detect support along with handshaking with AP Add wake_detect support to arche-platform driver which is responsible for SVC control. This patch also adds code for handshaking between AP <=> SVC. The sequence is, 1. AP boots To keep compatibility between DB3 and EVT platform, SVC will be help in reset and AP driver would release it at appropriate time. wake/detect pin (WD8A) = Low reset (SVC/APB1/APB2) = Asserted (as per polarity) 2. AP Driver gets inserted 2.1. AP will deassert reset to SVC (following power on sequence) 2.2. SVC allows 360 milliseconds to elapse after switch boots to work around bug described in ENG-330. 2.3. AP asserts wake/detect pin (WD8A = HIGH) 3. SVC detects assertion of wake/detect pin, and sends "wake out" signal to AP 4. AP receives "wake out" signal, takes AP Bridges through their power on reset sequence as defined in the bridge ASIC reference manuals 5. AP takes USB3613 through its power on reset sequence 6. AP should enumerates AP Bridges Note: ISR has been deliberately removed (not merged) as we are still not sure how it will be used, in runtime usage context. Driver as such doesn't do anything for runtime assert-n-deassert of reset to SVC/APB's, it just simply offloads it to user by exporting required gpio's. The exported gpio's are required for FW flashing from user space. When it comes to usersace manipulated control sequence, user has to manage. Signed-off-by: Vaibhav Hiremath <vaibhav.hiremath@linaro.org> Tested-by: Michael Scott <michael.scott@linaro.org> Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
2016-01-11 12:11:24 +00:00
struct delayed_work delayed_work;
struct device *dev;
greybus: platform: Add platform driver for DB3 AP bridge With DB3, we now have AP as a master as far as AP bridges are concerned. SVC will talk only to AP and AP will control bridges; unlike other module interfaces. So AP supposed to manage/control bridges in all power states including power on reset. During power on reset AP should follow below sequence - Sequence (treated as a Cold Boot) Stage-1 ======= AP: - Power On (Power up from PMIC to AP) - AP start booting Since power to AP bridges are controlled through gpio, power is gated to APB1 & 2 No ref_clk to APB available (under SVC's control) - AP configures USB hub to enable HSIC interface to APB - As part of platform driver probe, AP follow below sequence - Set the pinctrl in default state - Hold APBs in reset by pulling down reset pin - Enable power to APB by enabling regulator and switches - De-assert (set 'low') 'boot_ret' signal - AP will assert (set 'high') the wake_detect signal, triggering connect/detect event to the SVC - AP waits for wake pulse from SVC SVC: - Power On (power up from PMIC to SVC) - SVC starts booting - SVC will de-assert reset signal to unipro switch - Switch starts booting - SVC confirms switch boot status using SPI (or something) - SVC waits for 300 msec (ES2 known issue) - SVC waits for detect/connect event from AP Stage-2 ======= SVC: - ON connect/detect event, SVC send back wake pulse (cold boot) to AP over wake_detect pin, if SVC boot is completed. AP: - On wake pulse from SVC (for cold boot), AP de-asserts (set high') reset signal to APB 1 and/or 2 - Bridges starts booting - Eventually Unipro linkup occurs Testing: - Build tested against Helium kernel - Due to unavailability of MSM and DB3 platform, only minimal testing has been done. - Code has been modified for validation on Helium + SDB platform. Mostly dts changes for gpio numbers And debug messages to check gpio values - On Helium + SDB platform, with addition of debug messages validated the sequence. TODO list: - Currently _only_ supports power on sequence (cold boot). Both warm and cold boot support. Cold and Warm boot is differentiated based on pulse width of wake_detect signal >=5 msec = Cold boot else Warm boot - No support for Power management So the "power-down", "power-off", "wake_in" and "wake_out" signals are not explored/implemented. - Support for Work thread repetitive wake signal if no response from peer May required for PM support, as we have delays in the sequences - pinctrl states, specially to make sure we enable right pullup or pulldown when we set wake_detect pin to input - Convert gpio list into an array, and associated xxx-gpio-name property Signed-off-by: Vaibhav Hiremath <vaibhav.hiremath@linaro.org> Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
2015-10-21 11:20:20 +00:00
};
static inline void svc_reset_onoff(unsigned int gpio, bool onoff)
greybus: platform: Add platform driver for DB3 AP bridge With DB3, we now have AP as a master as far as AP bridges are concerned. SVC will talk only to AP and AP will control bridges; unlike other module interfaces. So AP supposed to manage/control bridges in all power states including power on reset. During power on reset AP should follow below sequence - Sequence (treated as a Cold Boot) Stage-1 ======= AP: - Power On (Power up from PMIC to AP) - AP start booting Since power to AP bridges are controlled through gpio, power is gated to APB1 & 2 No ref_clk to APB available (under SVC's control) - AP configures USB hub to enable HSIC interface to APB - As part of platform driver probe, AP follow below sequence - Set the pinctrl in default state - Hold APBs in reset by pulling down reset pin - Enable power to APB by enabling regulator and switches - De-assert (set 'low') 'boot_ret' signal - AP will assert (set 'high') the wake_detect signal, triggering connect/detect event to the SVC - AP waits for wake pulse from SVC SVC: - Power On (power up from PMIC to SVC) - SVC starts booting - SVC will de-assert reset signal to unipro switch - Switch starts booting - SVC confirms switch boot status using SPI (or something) - SVC waits for 300 msec (ES2 known issue) - SVC waits for detect/connect event from AP Stage-2 ======= SVC: - ON connect/detect event, SVC send back wake pulse (cold boot) to AP over wake_detect pin, if SVC boot is completed. AP: - On wake pulse from SVC (for cold boot), AP de-asserts (set high') reset signal to APB 1 and/or 2 - Bridges starts booting - Eventually Unipro linkup occurs Testing: - Build tested against Helium kernel - Due to unavailability of MSM and DB3 platform, only minimal testing has been done. - Code has been modified for validation on Helium + SDB platform. Mostly dts changes for gpio numbers And debug messages to check gpio values - On Helium + SDB platform, with addition of debug messages validated the sequence. TODO list: - Currently _only_ supports power on sequence (cold boot). Both warm and cold boot support. Cold and Warm boot is differentiated based on pulse width of wake_detect signal >=5 msec = Cold boot else Warm boot - No support for Power management So the "power-down", "power-off", "wake_in" and "wake_out" signals are not explored/implemented. - Support for Work thread repetitive wake signal if no response from peer May required for PM support, as we have delays in the sequences - pinctrl states, specially to make sure we enable right pullup or pulldown when we set wake_detect pin to input - Convert gpio list into an array, and associated xxx-gpio-name property Signed-off-by: Vaibhav Hiremath <vaibhav.hiremath@linaro.org> Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
2015-10-21 11:20:20 +00:00
{
gpio_set_value(gpio, onoff);
greybus: platform: Add platform driver for DB3 AP bridge With DB3, we now have AP as a master as far as AP bridges are concerned. SVC will talk only to AP and AP will control bridges; unlike other module interfaces. So AP supposed to manage/control bridges in all power states including power on reset. During power on reset AP should follow below sequence - Sequence (treated as a Cold Boot) Stage-1 ======= AP: - Power On (Power up from PMIC to AP) - AP start booting Since power to AP bridges are controlled through gpio, power is gated to APB1 & 2 No ref_clk to APB available (under SVC's control) - AP configures USB hub to enable HSIC interface to APB - As part of platform driver probe, AP follow below sequence - Set the pinctrl in default state - Hold APBs in reset by pulling down reset pin - Enable power to APB by enabling regulator and switches - De-assert (set 'low') 'boot_ret' signal - AP will assert (set 'high') the wake_detect signal, triggering connect/detect event to the SVC - AP waits for wake pulse from SVC SVC: - Power On (power up from PMIC to SVC) - SVC starts booting - SVC will de-assert reset signal to unipro switch - Switch starts booting - SVC confirms switch boot status using SPI (or something) - SVC waits for 300 msec (ES2 known issue) - SVC waits for detect/connect event from AP Stage-2 ======= SVC: - ON connect/detect event, SVC send back wake pulse (cold boot) to AP over wake_detect pin, if SVC boot is completed. AP: - On wake pulse from SVC (for cold boot), AP de-asserts (set high') reset signal to APB 1 and/or 2 - Bridges starts booting - Eventually Unipro linkup occurs Testing: - Build tested against Helium kernel - Due to unavailability of MSM and DB3 platform, only minimal testing has been done. - Code has been modified for validation on Helium + SDB platform. Mostly dts changes for gpio numbers And debug messages to check gpio values - On Helium + SDB platform, with addition of debug messages validated the sequence. TODO list: - Currently _only_ supports power on sequence (cold boot). Both warm and cold boot support. Cold and Warm boot is differentiated based on pulse width of wake_detect signal >=5 msec = Cold boot else Warm boot - No support for Power management So the "power-down", "power-off", "wake_in" and "wake_out" signals are not explored/implemented. - Support for Work thread repetitive wake signal if no response from peer May required for PM support, as we have delays in the sequences - pinctrl states, specially to make sure we enable right pullup or pulldown when we set wake_detect pin to input - Convert gpio list into an array, and associated xxx-gpio-name property Signed-off-by: Vaibhav Hiremath <vaibhav.hiremath@linaro.org> Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
2015-10-21 11:20:20 +00:00
}
greybus: arche-platform: Add wake/detect support along with handshaking with AP Add wake_detect support to arche-platform driver which is responsible for SVC control. This patch also adds code for handshaking between AP <=> SVC. The sequence is, 1. AP boots To keep compatibility between DB3 and EVT platform, SVC will be help in reset and AP driver would release it at appropriate time. wake/detect pin (WD8A) = Low reset (SVC/APB1/APB2) = Asserted (as per polarity) 2. AP Driver gets inserted 2.1. AP will deassert reset to SVC (following power on sequence) 2.2. SVC allows 360 milliseconds to elapse after switch boots to work around bug described in ENG-330. 2.3. AP asserts wake/detect pin (WD8A = HIGH) 3. SVC detects assertion of wake/detect pin, and sends "wake out" signal to AP 4. AP receives "wake out" signal, takes AP Bridges through their power on reset sequence as defined in the bridge ASIC reference manuals 5. AP takes USB3613 through its power on reset sequence 6. AP should enumerates AP Bridges Note: ISR has been deliberately removed (not merged) as we are still not sure how it will be used, in runtime usage context. Driver as such doesn't do anything for runtime assert-n-deassert of reset to SVC/APB's, it just simply offloads it to user by exporting required gpio's. The exported gpio's are required for FW flashing from user space. When it comes to usersace manipulated control sequence, user has to manage. Signed-off-by: Vaibhav Hiremath <vaibhav.hiremath@linaro.org> Tested-by: Michael Scott <michael.scott@linaro.org> Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
2016-01-11 12:11:24 +00:00
/**
* svc_delayed_work - Time to give SVC to boot.
*/
static void svc_delayed_work(struct work_struct *work)
{
struct arche_platform_drvdata *arche_pdata =
container_of(work, struct arche_platform_drvdata, delayed_work.work);
struct device *dev = arche_pdata->dev;
struct device_node *np = dev->of_node;
int timeout = 50;
greybus: arche-platform: Add wake/detect support along with handshaking with AP Add wake_detect support to arche-platform driver which is responsible for SVC control. This patch also adds code for handshaking between AP <=> SVC. The sequence is, 1. AP boots To keep compatibility between DB3 and EVT platform, SVC will be help in reset and AP driver would release it at appropriate time. wake/detect pin (WD8A) = Low reset (SVC/APB1/APB2) = Asserted (as per polarity) 2. AP Driver gets inserted 2.1. AP will deassert reset to SVC (following power on sequence) 2.2. SVC allows 360 milliseconds to elapse after switch boots to work around bug described in ENG-330. 2.3. AP asserts wake/detect pin (WD8A = HIGH) 3. SVC detects assertion of wake/detect pin, and sends "wake out" signal to AP 4. AP receives "wake out" signal, takes AP Bridges through their power on reset sequence as defined in the bridge ASIC reference manuals 5. AP takes USB3613 through its power on reset sequence 6. AP should enumerates AP Bridges Note: ISR has been deliberately removed (not merged) as we are still not sure how it will be used, in runtime usage context. Driver as such doesn't do anything for runtime assert-n-deassert of reset to SVC/APB's, it just simply offloads it to user by exporting required gpio's. The exported gpio's are required for FW flashing from user space. When it comes to usersace manipulated control sequence, user has to manage. Signed-off-by: Vaibhav Hiremath <vaibhav.hiremath@linaro.org> Tested-by: Michael Scott <michael.scott@linaro.org> Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
2016-01-11 12:11:24 +00:00
int ret;
/*
* 1. SVC and AP boot independently, with AP<-->SVC wake/detect pin
* deasserted (LOW in this case)
* 2.1. SVC allows 360 milliseconds to elapse after switch boots to work
* around bug described in ENG-330.
* 2.2. AP asserts wake/detect pin (HIGH) (this can proceed in parallel with 2.1)
* 3. SVC detects assertion of wake/detect pin, and sends "wake out" signal to AP
* 4. AP receives "wake out" signal, takes AP Bridges through their power
* on reset sequence as defined in the bridge ASIC reference manuals
* 5. AP takes USB3613 through its power on reset sequence
* 6. AP enumerates AP Bridges
*/
gpio_set_value(arche_pdata->wake_detect_gpio, 1);
gpio_direction_input(arche_pdata->wake_detect_gpio);
do {
/* Read the wake_detect GPIO, for WAKE_OUT event from SVC */
if (gpio_get_value(arche_pdata->wake_detect_gpio) == 0)
break;
msleep(100);
greybus: arche-platform: Add wake/detect support along with handshaking with AP Add wake_detect support to arche-platform driver which is responsible for SVC control. This patch also adds code for handshaking between AP <=> SVC. The sequence is, 1. AP boots To keep compatibility between DB3 and EVT platform, SVC will be help in reset and AP driver would release it at appropriate time. wake/detect pin (WD8A) = Low reset (SVC/APB1/APB2) = Asserted (as per polarity) 2. AP Driver gets inserted 2.1. AP will deassert reset to SVC (following power on sequence) 2.2. SVC allows 360 milliseconds to elapse after switch boots to work around bug described in ENG-330. 2.3. AP asserts wake/detect pin (WD8A = HIGH) 3. SVC detects assertion of wake/detect pin, and sends "wake out" signal to AP 4. AP receives "wake out" signal, takes AP Bridges through their power on reset sequence as defined in the bridge ASIC reference manuals 5. AP takes USB3613 through its power on reset sequence 6. AP should enumerates AP Bridges Note: ISR has been deliberately removed (not merged) as we are still not sure how it will be used, in runtime usage context. Driver as such doesn't do anything for runtime assert-n-deassert of reset to SVC/APB's, it just simply offloads it to user by exporting required gpio's. The exported gpio's are required for FW flashing from user space. When it comes to usersace manipulated control sequence, user has to manage. Signed-off-by: Vaibhav Hiremath <vaibhav.hiremath@linaro.org> Tested-by: Michael Scott <michael.scott@linaro.org> Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
2016-01-11 12:11:24 +00:00
} while(timeout--);
if (timeout >= 0) {
ret = of_platform_populate(np, NULL, NULL, dev);
if (!ret) {
/* re-assert wake_detect to confirm SVC WAKE_OUT */
gpio_direction_output(arche_pdata->wake_detect_gpio, 1);
greybus: arche-platform: Add wake/detect support along with handshaking with AP Add wake_detect support to arche-platform driver which is responsible for SVC control. This patch also adds code for handshaking between AP <=> SVC. The sequence is, 1. AP boots To keep compatibility between DB3 and EVT platform, SVC will be help in reset and AP driver would release it at appropriate time. wake/detect pin (WD8A) = Low reset (SVC/APB1/APB2) = Asserted (as per polarity) 2. AP Driver gets inserted 2.1. AP will deassert reset to SVC (following power on sequence) 2.2. SVC allows 360 milliseconds to elapse after switch boots to work around bug described in ENG-330. 2.3. AP asserts wake/detect pin (WD8A = HIGH) 3. SVC detects assertion of wake/detect pin, and sends "wake out" signal to AP 4. AP receives "wake out" signal, takes AP Bridges through their power on reset sequence as defined in the bridge ASIC reference manuals 5. AP takes USB3613 through its power on reset sequence 6. AP should enumerates AP Bridges Note: ISR has been deliberately removed (not merged) as we are still not sure how it will be used, in runtime usage context. Driver as such doesn't do anything for runtime assert-n-deassert of reset to SVC/APB's, it just simply offloads it to user by exporting required gpio's. The exported gpio's are required for FW flashing from user space. When it comes to usersace manipulated control sequence, user has to manage. Signed-off-by: Vaibhav Hiremath <vaibhav.hiremath@linaro.org> Tested-by: Michael Scott <michael.scott@linaro.org> Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
2016-01-11 12:11:24 +00:00
return;
}
greybus: arche-platform: Add wake/detect support along with handshaking with AP Add wake_detect support to arche-platform driver which is responsible for SVC control. This patch also adds code for handshaking between AP <=> SVC. The sequence is, 1. AP boots To keep compatibility between DB3 and EVT platform, SVC will be help in reset and AP driver would release it at appropriate time. wake/detect pin (WD8A) = Low reset (SVC/APB1/APB2) = Asserted (as per polarity) 2. AP Driver gets inserted 2.1. AP will deassert reset to SVC (following power on sequence) 2.2. SVC allows 360 milliseconds to elapse after switch boots to work around bug described in ENG-330. 2.3. AP asserts wake/detect pin (WD8A = HIGH) 3. SVC detects assertion of wake/detect pin, and sends "wake out" signal to AP 4. AP receives "wake out" signal, takes AP Bridges through their power on reset sequence as defined in the bridge ASIC reference manuals 5. AP takes USB3613 through its power on reset sequence 6. AP should enumerates AP Bridges Note: ISR has been deliberately removed (not merged) as we are still not sure how it will be used, in runtime usage context. Driver as such doesn't do anything for runtime assert-n-deassert of reset to SVC/APB's, it just simply offloads it to user by exporting required gpio's. The exported gpio's are required for FW flashing from user space. When it comes to usersace manipulated control sequence, user has to manage. Signed-off-by: Vaibhav Hiremath <vaibhav.hiremath@linaro.org> Tested-by: Michael Scott <michael.scott@linaro.org> Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
2016-01-11 12:11:24 +00:00
}
/* FIXME: We may want to limit retries here */
gpio_direction_output(arche_pdata->wake_detect_gpio, 0);
schedule_delayed_work(&arche_pdata->delayed_work, msecs_to_jiffies(2000));
}
/* Export gpio's to user space */
static void export_gpios(struct arche_platform_drvdata *arche_pdata)
{
gpio_export(arche_pdata->svc_reset_gpio, false);
gpio_export(arche_pdata->svc_sysboot_gpio, false);
}
static void unexport_gpios(struct arche_platform_drvdata *arche_pdata)
{
gpio_unexport(arche_pdata->svc_reset_gpio);
gpio_unexport(arche_pdata->svc_sysboot_gpio);
}
static int arche_platform_coldboot_seq(struct arche_platform_drvdata *arche_pdata)
{
int ret;
dev_info(arche_pdata->dev, "Booting from cold boot state\n");
svc_reset_onoff(arche_pdata->svc_reset_gpio,
arche_pdata->is_reset_act_hi);
gpio_set_value(arche_pdata->svc_sysboot_gpio, 0);
usleep_range(100, 200);
ret = clk_prepare_enable(arche_pdata->svc_ref_clk);
if (ret) {
dev_err(arche_pdata->dev, "failed to enable svc_ref_clk: %d\n",
ret);
return ret;
}
/* bring SVC out of reset */
svc_reset_onoff(arche_pdata->svc_reset_gpio,
!arche_pdata->is_reset_act_hi);
arche_pdata->state = ARCHE_PLATFORM_STATE_ACTIVE;
return 0;
}
static void arche_platform_poweroff_seq(struct arche_platform_drvdata *arche_pdata)
greybus: platform: Add platform driver for DB3 AP bridge With DB3, we now have AP as a master as far as AP bridges are concerned. SVC will talk only to AP and AP will control bridges; unlike other module interfaces. So AP supposed to manage/control bridges in all power states including power on reset. During power on reset AP should follow below sequence - Sequence (treated as a Cold Boot) Stage-1 ======= AP: - Power On (Power up from PMIC to AP) - AP start booting Since power to AP bridges are controlled through gpio, power is gated to APB1 & 2 No ref_clk to APB available (under SVC's control) - AP configures USB hub to enable HSIC interface to APB - As part of platform driver probe, AP follow below sequence - Set the pinctrl in default state - Hold APBs in reset by pulling down reset pin - Enable power to APB by enabling regulator and switches - De-assert (set 'low') 'boot_ret' signal - AP will assert (set 'high') the wake_detect signal, triggering connect/detect event to the SVC - AP waits for wake pulse from SVC SVC: - Power On (power up from PMIC to SVC) - SVC starts booting - SVC will de-assert reset signal to unipro switch - Switch starts booting - SVC confirms switch boot status using SPI (or something) - SVC waits for 300 msec (ES2 known issue) - SVC waits for detect/connect event from AP Stage-2 ======= SVC: - ON connect/detect event, SVC send back wake pulse (cold boot) to AP over wake_detect pin, if SVC boot is completed. AP: - On wake pulse from SVC (for cold boot), AP de-asserts (set high') reset signal to APB 1 and/or 2 - Bridges starts booting - Eventually Unipro linkup occurs Testing: - Build tested against Helium kernel - Due to unavailability of MSM and DB3 platform, only minimal testing has been done. - Code has been modified for validation on Helium + SDB platform. Mostly dts changes for gpio numbers And debug messages to check gpio values - On Helium + SDB platform, with addition of debug messages validated the sequence. TODO list: - Currently _only_ supports power on sequence (cold boot). Both warm and cold boot support. Cold and Warm boot is differentiated based on pulse width of wake_detect signal >=5 msec = Cold boot else Warm boot - No support for Power management So the "power-down", "power-off", "wake_in" and "wake_out" signals are not explored/implemented. - Support for Work thread repetitive wake signal if no response from peer May required for PM support, as we have delays in the sequences - pinctrl states, specially to make sure we enable right pullup or pulldown when we set wake_detect pin to input - Convert gpio list into an array, and associated xxx-gpio-name property Signed-off-by: Vaibhav Hiremath <vaibhav.hiremath@linaro.org> Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
2015-10-21 11:20:20 +00:00
{
/* Send disconnect/detach event to SVC */
gpio_set_value(arche_pdata->wake_detect_gpio, 0);
usleep_range(100, 200);
clk_disable_unprepare(arche_pdata->svc_ref_clk);
greybus: platform: Add platform driver for DB3 AP bridge With DB3, we now have AP as a master as far as AP bridges are concerned. SVC will talk only to AP and AP will control bridges; unlike other module interfaces. So AP supposed to manage/control bridges in all power states including power on reset. During power on reset AP should follow below sequence - Sequence (treated as a Cold Boot) Stage-1 ======= AP: - Power On (Power up from PMIC to AP) - AP start booting Since power to AP bridges are controlled through gpio, power is gated to APB1 & 2 No ref_clk to APB available (under SVC's control) - AP configures USB hub to enable HSIC interface to APB - As part of platform driver probe, AP follow below sequence - Set the pinctrl in default state - Hold APBs in reset by pulling down reset pin - Enable power to APB by enabling regulator and switches - De-assert (set 'low') 'boot_ret' signal - AP will assert (set 'high') the wake_detect signal, triggering connect/detect event to the SVC - AP waits for wake pulse from SVC SVC: - Power On (power up from PMIC to SVC) - SVC starts booting - SVC will de-assert reset signal to unipro switch - Switch starts booting - SVC confirms switch boot status using SPI (or something) - SVC waits for 300 msec (ES2 known issue) - SVC waits for detect/connect event from AP Stage-2 ======= SVC: - ON connect/detect event, SVC send back wake pulse (cold boot) to AP over wake_detect pin, if SVC boot is completed. AP: - On wake pulse from SVC (for cold boot), AP de-asserts (set high') reset signal to APB 1 and/or 2 - Bridges starts booting - Eventually Unipro linkup occurs Testing: - Build tested against Helium kernel - Due to unavailability of MSM and DB3 platform, only minimal testing has been done. - Code has been modified for validation on Helium + SDB platform. Mostly dts changes for gpio numbers And debug messages to check gpio values - On Helium + SDB platform, with addition of debug messages validated the sequence. TODO list: - Currently _only_ supports power on sequence (cold boot). Both warm and cold boot support. Cold and Warm boot is differentiated based on pulse width of wake_detect signal >=5 msec = Cold boot else Warm boot - No support for Power management So the "power-down", "power-off", "wake_in" and "wake_out" signals are not explored/implemented. - Support for Work thread repetitive wake signal if no response from peer May required for PM support, as we have delays in the sequences - pinctrl states, specially to make sure we enable right pullup or pulldown when we set wake_detect pin to input - Convert gpio list into an array, and associated xxx-gpio-name property Signed-off-by: Vaibhav Hiremath <vaibhav.hiremath@linaro.org> Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
2015-10-21 11:20:20 +00:00
/* As part of exit, put APB back in reset state */
svc_reset_onoff(arche_pdata->svc_reset_gpio,
arche_pdata->is_reset_act_hi);
arche_pdata->state = ARCHE_PLATFORM_STATE_OFF;
greybus: platform: Add platform driver for DB3 AP bridge With DB3, we now have AP as a master as far as AP bridges are concerned. SVC will talk only to AP and AP will control bridges; unlike other module interfaces. So AP supposed to manage/control bridges in all power states including power on reset. During power on reset AP should follow below sequence - Sequence (treated as a Cold Boot) Stage-1 ======= AP: - Power On (Power up from PMIC to AP) - AP start booting Since power to AP bridges are controlled through gpio, power is gated to APB1 & 2 No ref_clk to APB available (under SVC's control) - AP configures USB hub to enable HSIC interface to APB - As part of platform driver probe, AP follow below sequence - Set the pinctrl in default state - Hold APBs in reset by pulling down reset pin - Enable power to APB by enabling regulator and switches - De-assert (set 'low') 'boot_ret' signal - AP will assert (set 'high') the wake_detect signal, triggering connect/detect event to the SVC - AP waits for wake pulse from SVC SVC: - Power On (power up from PMIC to SVC) - SVC starts booting - SVC will de-assert reset signal to unipro switch - Switch starts booting - SVC confirms switch boot status using SPI (or something) - SVC waits for 300 msec (ES2 known issue) - SVC waits for detect/connect event from AP Stage-2 ======= SVC: - ON connect/detect event, SVC send back wake pulse (cold boot) to AP over wake_detect pin, if SVC boot is completed. AP: - On wake pulse from SVC (for cold boot), AP de-asserts (set high') reset signal to APB 1 and/or 2 - Bridges starts booting - Eventually Unipro linkup occurs Testing: - Build tested against Helium kernel - Due to unavailability of MSM and DB3 platform, only minimal testing has been done. - Code has been modified for validation on Helium + SDB platform. Mostly dts changes for gpio numbers And debug messages to check gpio values - On Helium + SDB platform, with addition of debug messages validated the sequence. TODO list: - Currently _only_ supports power on sequence (cold boot). Both warm and cold boot support. Cold and Warm boot is differentiated based on pulse width of wake_detect signal >=5 msec = Cold boot else Warm boot - No support for Power management So the "power-down", "power-off", "wake_in" and "wake_out" signals are not explored/implemented. - Support for Work thread repetitive wake signal if no response from peer May required for PM support, as we have delays in the sequences - pinctrl states, specially to make sure we enable right pullup or pulldown when we set wake_detect pin to input - Convert gpio list into an array, and associated xxx-gpio-name property Signed-off-by: Vaibhav Hiremath <vaibhav.hiremath@linaro.org> Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
2015-10-21 11:20:20 +00:00
}
static ssize_t state_store(struct device *dev,
struct device_attribute *attr, const char *buf, size_t count)
{
struct platform_device *pdev = to_platform_device(dev);
struct arche_platform_drvdata *arche_pdata = platform_get_drvdata(pdev);
int ret = 0;
if (sysfs_streq(buf, "off")) {
if (arche_pdata->state == ARCHE_PLATFORM_STATE_OFF)
return count;
arche_platform_poweroff_seq(arche_pdata);
} else if (sysfs_streq(buf, "active")) {
if (arche_pdata->state == ARCHE_PLATFORM_STATE_ACTIVE)
return count;
ret = arche_platform_coldboot_seq(arche_pdata);
} else if (sysfs_streq(buf, "standby")) {
if (arche_pdata->state == ARCHE_PLATFORM_STATE_STANDBY)
return count;
dev_warn(arche_pdata->dev, "standby state not supported\n");
} else {
dev_err(arche_pdata->dev, "unknown state\n");
ret = -EINVAL;
}
return ret ? ret : count;
}
static ssize_t state_show(struct device *dev,
struct device_attribute *attr, char *buf)
{
struct arche_platform_drvdata *arche_pdata = dev_get_drvdata(dev);
switch (arche_pdata->state) {
case ARCHE_PLATFORM_STATE_OFF:
return sprintf(buf, "off\n");
case ARCHE_PLATFORM_STATE_ACTIVE:
return sprintf(buf, "active\n");
case ARCHE_PLATFORM_STATE_STANDBY:
return sprintf(buf, "standby\n");
default:
return sprintf(buf, "unknown state\n");
}
}
static DEVICE_ATTR_RW(state);
static int arche_platform_probe(struct platform_device *pdev)
greybus: platform: Add platform driver for DB3 AP bridge With DB3, we now have AP as a master as far as AP bridges are concerned. SVC will talk only to AP and AP will control bridges; unlike other module interfaces. So AP supposed to manage/control bridges in all power states including power on reset. During power on reset AP should follow below sequence - Sequence (treated as a Cold Boot) Stage-1 ======= AP: - Power On (Power up from PMIC to AP) - AP start booting Since power to AP bridges are controlled through gpio, power is gated to APB1 & 2 No ref_clk to APB available (under SVC's control) - AP configures USB hub to enable HSIC interface to APB - As part of platform driver probe, AP follow below sequence - Set the pinctrl in default state - Hold APBs in reset by pulling down reset pin - Enable power to APB by enabling regulator and switches - De-assert (set 'low') 'boot_ret' signal - AP will assert (set 'high') the wake_detect signal, triggering connect/detect event to the SVC - AP waits for wake pulse from SVC SVC: - Power On (power up from PMIC to SVC) - SVC starts booting - SVC will de-assert reset signal to unipro switch - Switch starts booting - SVC confirms switch boot status using SPI (or something) - SVC waits for 300 msec (ES2 known issue) - SVC waits for detect/connect event from AP Stage-2 ======= SVC: - ON connect/detect event, SVC send back wake pulse (cold boot) to AP over wake_detect pin, if SVC boot is completed. AP: - On wake pulse from SVC (for cold boot), AP de-asserts (set high') reset signal to APB 1 and/or 2 - Bridges starts booting - Eventually Unipro linkup occurs Testing: - Build tested against Helium kernel - Due to unavailability of MSM and DB3 platform, only minimal testing has been done. - Code has been modified for validation on Helium + SDB platform. Mostly dts changes for gpio numbers And debug messages to check gpio values - On Helium + SDB platform, with addition of debug messages validated the sequence. TODO list: - Currently _only_ supports power on sequence (cold boot). Both warm and cold boot support. Cold and Warm boot is differentiated based on pulse width of wake_detect signal >=5 msec = Cold boot else Warm boot - No support for Power management So the "power-down", "power-off", "wake_in" and "wake_out" signals are not explored/implemented. - Support for Work thread repetitive wake signal if no response from peer May required for PM support, as we have delays in the sequences - pinctrl states, specially to make sure we enable right pullup or pulldown when we set wake_detect pin to input - Convert gpio list into an array, and associated xxx-gpio-name property Signed-off-by: Vaibhav Hiremath <vaibhav.hiremath@linaro.org> Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
2015-10-21 11:20:20 +00:00
{
struct arche_platform_drvdata *arche_pdata;
struct device *dev = &pdev->dev;
struct device_node *np = dev->of_node;
greybus: platform: Add platform driver for DB3 AP bridge With DB3, we now have AP as a master as far as AP bridges are concerned. SVC will talk only to AP and AP will control bridges; unlike other module interfaces. So AP supposed to manage/control bridges in all power states including power on reset. During power on reset AP should follow below sequence - Sequence (treated as a Cold Boot) Stage-1 ======= AP: - Power On (Power up from PMIC to AP) - AP start booting Since power to AP bridges are controlled through gpio, power is gated to APB1 & 2 No ref_clk to APB available (under SVC's control) - AP configures USB hub to enable HSIC interface to APB - As part of platform driver probe, AP follow below sequence - Set the pinctrl in default state - Hold APBs in reset by pulling down reset pin - Enable power to APB by enabling regulator and switches - De-assert (set 'low') 'boot_ret' signal - AP will assert (set 'high') the wake_detect signal, triggering connect/detect event to the SVC - AP waits for wake pulse from SVC SVC: - Power On (power up from PMIC to SVC) - SVC starts booting - SVC will de-assert reset signal to unipro switch - Switch starts booting - SVC confirms switch boot status using SPI (or something) - SVC waits for 300 msec (ES2 known issue) - SVC waits for detect/connect event from AP Stage-2 ======= SVC: - ON connect/detect event, SVC send back wake pulse (cold boot) to AP over wake_detect pin, if SVC boot is completed. AP: - On wake pulse from SVC (for cold boot), AP de-asserts (set high') reset signal to APB 1 and/or 2 - Bridges starts booting - Eventually Unipro linkup occurs Testing: - Build tested against Helium kernel - Due to unavailability of MSM and DB3 platform, only minimal testing has been done. - Code has been modified for validation on Helium + SDB platform. Mostly dts changes for gpio numbers And debug messages to check gpio values - On Helium + SDB platform, with addition of debug messages validated the sequence. TODO list: - Currently _only_ supports power on sequence (cold boot). Both warm and cold boot support. Cold and Warm boot is differentiated based on pulse width of wake_detect signal >=5 msec = Cold boot else Warm boot - No support for Power management So the "power-down", "power-off", "wake_in" and "wake_out" signals are not explored/implemented. - Support for Work thread repetitive wake signal if no response from peer May required for PM support, as we have delays in the sequences - pinctrl states, specially to make sure we enable right pullup or pulldown when we set wake_detect pin to input - Convert gpio list into an array, and associated xxx-gpio-name property Signed-off-by: Vaibhav Hiremath <vaibhav.hiremath@linaro.org> Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
2015-10-21 11:20:20 +00:00
int ret;
arche_pdata = devm_kzalloc(&pdev->dev, sizeof(*arche_pdata), GFP_KERNEL);
if (!arche_pdata)
return -ENOMEM;
greybus: platform: Add platform driver for DB3 AP bridge With DB3, we now have AP as a master as far as AP bridges are concerned. SVC will talk only to AP and AP will control bridges; unlike other module interfaces. So AP supposed to manage/control bridges in all power states including power on reset. During power on reset AP should follow below sequence - Sequence (treated as a Cold Boot) Stage-1 ======= AP: - Power On (Power up from PMIC to AP) - AP start booting Since power to AP bridges are controlled through gpio, power is gated to APB1 & 2 No ref_clk to APB available (under SVC's control) - AP configures USB hub to enable HSIC interface to APB - As part of platform driver probe, AP follow below sequence - Set the pinctrl in default state - Hold APBs in reset by pulling down reset pin - Enable power to APB by enabling regulator and switches - De-assert (set 'low') 'boot_ret' signal - AP will assert (set 'high') the wake_detect signal, triggering connect/detect event to the SVC - AP waits for wake pulse from SVC SVC: - Power On (power up from PMIC to SVC) - SVC starts booting - SVC will de-assert reset signal to unipro switch - Switch starts booting - SVC confirms switch boot status using SPI (or something) - SVC waits for 300 msec (ES2 known issue) - SVC waits for detect/connect event from AP Stage-2 ======= SVC: - ON connect/detect event, SVC send back wake pulse (cold boot) to AP over wake_detect pin, if SVC boot is completed. AP: - On wake pulse from SVC (for cold boot), AP de-asserts (set high') reset signal to APB 1 and/or 2 - Bridges starts booting - Eventually Unipro linkup occurs Testing: - Build tested against Helium kernel - Due to unavailability of MSM and DB3 platform, only minimal testing has been done. - Code has been modified for validation on Helium + SDB platform. Mostly dts changes for gpio numbers And debug messages to check gpio values - On Helium + SDB platform, with addition of debug messages validated the sequence. TODO list: - Currently _only_ supports power on sequence (cold boot). Both warm and cold boot support. Cold and Warm boot is differentiated based on pulse width of wake_detect signal >=5 msec = Cold boot else Warm boot - No support for Power management So the "power-down", "power-off", "wake_in" and "wake_out" signals are not explored/implemented. - Support for Work thread repetitive wake signal if no response from peer May required for PM support, as we have delays in the sequences - pinctrl states, specially to make sure we enable right pullup or pulldown when we set wake_detect pin to input - Convert gpio list into an array, and associated xxx-gpio-name property Signed-off-by: Vaibhav Hiremath <vaibhav.hiremath@linaro.org> Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
2015-10-21 11:20:20 +00:00
/* setup svc reset gpio */
arche_pdata->is_reset_act_hi = of_property_read_bool(np,
"svc,reset-active-high");
arche_pdata->svc_reset_gpio = of_get_named_gpio(np, "svc,reset-gpio", 0);
if (arche_pdata->svc_reset_gpio < 0) {
dev_err(dev, "failed to get reset-gpio\n");
return arche_pdata->svc_reset_gpio;
greybus: platform: Add platform driver for DB3 AP bridge With DB3, we now have AP as a master as far as AP bridges are concerned. SVC will talk only to AP and AP will control bridges; unlike other module interfaces. So AP supposed to manage/control bridges in all power states including power on reset. During power on reset AP should follow below sequence - Sequence (treated as a Cold Boot) Stage-1 ======= AP: - Power On (Power up from PMIC to AP) - AP start booting Since power to AP bridges are controlled through gpio, power is gated to APB1 & 2 No ref_clk to APB available (under SVC's control) - AP configures USB hub to enable HSIC interface to APB - As part of platform driver probe, AP follow below sequence - Set the pinctrl in default state - Hold APBs in reset by pulling down reset pin - Enable power to APB by enabling regulator and switches - De-assert (set 'low') 'boot_ret' signal - AP will assert (set 'high') the wake_detect signal, triggering connect/detect event to the SVC - AP waits for wake pulse from SVC SVC: - Power On (power up from PMIC to SVC) - SVC starts booting - SVC will de-assert reset signal to unipro switch - Switch starts booting - SVC confirms switch boot status using SPI (or something) - SVC waits for 300 msec (ES2 known issue) - SVC waits for detect/connect event from AP Stage-2 ======= SVC: - ON connect/detect event, SVC send back wake pulse (cold boot) to AP over wake_detect pin, if SVC boot is completed. AP: - On wake pulse from SVC (for cold boot), AP de-asserts (set high') reset signal to APB 1 and/or 2 - Bridges starts booting - Eventually Unipro linkup occurs Testing: - Build tested against Helium kernel - Due to unavailability of MSM and DB3 platform, only minimal testing has been done. - Code has been modified for validation on Helium + SDB platform. Mostly dts changes for gpio numbers And debug messages to check gpio values - On Helium + SDB platform, with addition of debug messages validated the sequence. TODO list: - Currently _only_ supports power on sequence (cold boot). Both warm and cold boot support. Cold and Warm boot is differentiated based on pulse width of wake_detect signal >=5 msec = Cold boot else Warm boot - No support for Power management So the "power-down", "power-off", "wake_in" and "wake_out" signals are not explored/implemented. - Support for Work thread repetitive wake signal if no response from peer May required for PM support, as we have delays in the sequences - pinctrl states, specially to make sure we enable right pullup or pulldown when we set wake_detect pin to input - Convert gpio list into an array, and associated xxx-gpio-name property Signed-off-by: Vaibhav Hiremath <vaibhav.hiremath@linaro.org> Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
2015-10-21 11:20:20 +00:00
}
ret = devm_gpio_request(dev, arche_pdata->svc_reset_gpio, "svc-reset");
greybus: platform: Add platform driver for DB3 AP bridge With DB3, we now have AP as a master as far as AP bridges are concerned. SVC will talk only to AP and AP will control bridges; unlike other module interfaces. So AP supposed to manage/control bridges in all power states including power on reset. During power on reset AP should follow below sequence - Sequence (treated as a Cold Boot) Stage-1 ======= AP: - Power On (Power up from PMIC to AP) - AP start booting Since power to AP bridges are controlled through gpio, power is gated to APB1 & 2 No ref_clk to APB available (under SVC's control) - AP configures USB hub to enable HSIC interface to APB - As part of platform driver probe, AP follow below sequence - Set the pinctrl in default state - Hold APBs in reset by pulling down reset pin - Enable power to APB by enabling regulator and switches - De-assert (set 'low') 'boot_ret' signal - AP will assert (set 'high') the wake_detect signal, triggering connect/detect event to the SVC - AP waits for wake pulse from SVC SVC: - Power On (power up from PMIC to SVC) - SVC starts booting - SVC will de-assert reset signal to unipro switch - Switch starts booting - SVC confirms switch boot status using SPI (or something) - SVC waits for 300 msec (ES2 known issue) - SVC waits for detect/connect event from AP Stage-2 ======= SVC: - ON connect/detect event, SVC send back wake pulse (cold boot) to AP over wake_detect pin, if SVC boot is completed. AP: - On wake pulse from SVC (for cold boot), AP de-asserts (set high') reset signal to APB 1 and/or 2 - Bridges starts booting - Eventually Unipro linkup occurs Testing: - Build tested against Helium kernel - Due to unavailability of MSM and DB3 platform, only minimal testing has been done. - Code has been modified for validation on Helium + SDB platform. Mostly dts changes for gpio numbers And debug messages to check gpio values - On Helium + SDB platform, with addition of debug messages validated the sequence. TODO list: - Currently _only_ supports power on sequence (cold boot). Both warm and cold boot support. Cold and Warm boot is differentiated based on pulse width of wake_detect signal >=5 msec = Cold boot else Warm boot - No support for Power management So the "power-down", "power-off", "wake_in" and "wake_out" signals are not explored/implemented. - Support for Work thread repetitive wake signal if no response from peer May required for PM support, as we have delays in the sequences - pinctrl states, specially to make sure we enable right pullup or pulldown when we set wake_detect pin to input - Convert gpio list into an array, and associated xxx-gpio-name property Signed-off-by: Vaibhav Hiremath <vaibhav.hiremath@linaro.org> Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
2015-10-21 11:20:20 +00:00
if (ret) {
dev_err(dev, "failed to request svc-reset gpio:%d\n", ret);
greybus: platform: Add platform driver for DB3 AP bridge With DB3, we now have AP as a master as far as AP bridges are concerned. SVC will talk only to AP and AP will control bridges; unlike other module interfaces. So AP supposed to manage/control bridges in all power states including power on reset. During power on reset AP should follow below sequence - Sequence (treated as a Cold Boot) Stage-1 ======= AP: - Power On (Power up from PMIC to AP) - AP start booting Since power to AP bridges are controlled through gpio, power is gated to APB1 & 2 No ref_clk to APB available (under SVC's control) - AP configures USB hub to enable HSIC interface to APB - As part of platform driver probe, AP follow below sequence - Set the pinctrl in default state - Hold APBs in reset by pulling down reset pin - Enable power to APB by enabling regulator and switches - De-assert (set 'low') 'boot_ret' signal - AP will assert (set 'high') the wake_detect signal, triggering connect/detect event to the SVC - AP waits for wake pulse from SVC SVC: - Power On (power up from PMIC to SVC) - SVC starts booting - SVC will de-assert reset signal to unipro switch - Switch starts booting - SVC confirms switch boot status using SPI (or something) - SVC waits for 300 msec (ES2 known issue) - SVC waits for detect/connect event from AP Stage-2 ======= SVC: - ON connect/detect event, SVC send back wake pulse (cold boot) to AP over wake_detect pin, if SVC boot is completed. AP: - On wake pulse from SVC (for cold boot), AP de-asserts (set high') reset signal to APB 1 and/or 2 - Bridges starts booting - Eventually Unipro linkup occurs Testing: - Build tested against Helium kernel - Due to unavailability of MSM and DB3 platform, only minimal testing has been done. - Code has been modified for validation on Helium + SDB platform. Mostly dts changes for gpio numbers And debug messages to check gpio values - On Helium + SDB platform, with addition of debug messages validated the sequence. TODO list: - Currently _only_ supports power on sequence (cold boot). Both warm and cold boot support. Cold and Warm boot is differentiated based on pulse width of wake_detect signal >=5 msec = Cold boot else Warm boot - No support for Power management So the "power-down", "power-off", "wake_in" and "wake_out" signals are not explored/implemented. - Support for Work thread repetitive wake signal if no response from peer May required for PM support, as we have delays in the sequences - pinctrl states, specially to make sure we enable right pullup or pulldown when we set wake_detect pin to input - Convert gpio list into an array, and associated xxx-gpio-name property Signed-off-by: Vaibhav Hiremath <vaibhav.hiremath@linaro.org> Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
2015-10-21 11:20:20 +00:00
return ret;
}
ret = gpio_direction_output(arche_pdata->svc_reset_gpio,
arche_pdata->is_reset_act_hi);
if (ret) {
dev_err(dev, "failed to set svc-reset gpio dir:%d\n", ret);
return ret;
greybus: platform: Add platform driver for DB3 AP bridge With DB3, we now have AP as a master as far as AP bridges are concerned. SVC will talk only to AP and AP will control bridges; unlike other module interfaces. So AP supposed to manage/control bridges in all power states including power on reset. During power on reset AP should follow below sequence - Sequence (treated as a Cold Boot) Stage-1 ======= AP: - Power On (Power up from PMIC to AP) - AP start booting Since power to AP bridges are controlled through gpio, power is gated to APB1 & 2 No ref_clk to APB available (under SVC's control) - AP configures USB hub to enable HSIC interface to APB - As part of platform driver probe, AP follow below sequence - Set the pinctrl in default state - Hold APBs in reset by pulling down reset pin - Enable power to APB by enabling regulator and switches - De-assert (set 'low') 'boot_ret' signal - AP will assert (set 'high') the wake_detect signal, triggering connect/detect event to the SVC - AP waits for wake pulse from SVC SVC: - Power On (power up from PMIC to SVC) - SVC starts booting - SVC will de-assert reset signal to unipro switch - Switch starts booting - SVC confirms switch boot status using SPI (or something) - SVC waits for 300 msec (ES2 known issue) - SVC waits for detect/connect event from AP Stage-2 ======= SVC: - ON connect/detect event, SVC send back wake pulse (cold boot) to AP over wake_detect pin, if SVC boot is completed. AP: - On wake pulse from SVC (for cold boot), AP de-asserts (set high') reset signal to APB 1 and/or 2 - Bridges starts booting - Eventually Unipro linkup occurs Testing: - Build tested against Helium kernel - Due to unavailability of MSM and DB3 platform, only minimal testing has been done. - Code has been modified for validation on Helium + SDB platform. Mostly dts changes for gpio numbers And debug messages to check gpio values - On Helium + SDB platform, with addition of debug messages validated the sequence. TODO list: - Currently _only_ supports power on sequence (cold boot). Both warm and cold boot support. Cold and Warm boot is differentiated based on pulse width of wake_detect signal >=5 msec = Cold boot else Warm boot - No support for Power management So the "power-down", "power-off", "wake_in" and "wake_out" signals are not explored/implemented. - Support for Work thread repetitive wake signal if no response from peer May required for PM support, as we have delays in the sequences - pinctrl states, specially to make sure we enable right pullup or pulldown when we set wake_detect pin to input - Convert gpio list into an array, and associated xxx-gpio-name property Signed-off-by: Vaibhav Hiremath <vaibhav.hiremath@linaro.org> Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
2015-10-21 11:20:20 +00:00
}
arche_pdata->state = ARCHE_PLATFORM_STATE_OFF;
greybus: platform: Add platform driver for DB3 AP bridge With DB3, we now have AP as a master as far as AP bridges are concerned. SVC will talk only to AP and AP will control bridges; unlike other module interfaces. So AP supposed to manage/control bridges in all power states including power on reset. During power on reset AP should follow below sequence - Sequence (treated as a Cold Boot) Stage-1 ======= AP: - Power On (Power up from PMIC to AP) - AP start booting Since power to AP bridges are controlled through gpio, power is gated to APB1 & 2 No ref_clk to APB available (under SVC's control) - AP configures USB hub to enable HSIC interface to APB - As part of platform driver probe, AP follow below sequence - Set the pinctrl in default state - Hold APBs in reset by pulling down reset pin - Enable power to APB by enabling regulator and switches - De-assert (set 'low') 'boot_ret' signal - AP will assert (set 'high') the wake_detect signal, triggering connect/detect event to the SVC - AP waits for wake pulse from SVC SVC: - Power On (power up from PMIC to SVC) - SVC starts booting - SVC will de-assert reset signal to unipro switch - Switch starts booting - SVC confirms switch boot status using SPI (or something) - SVC waits for 300 msec (ES2 known issue) - SVC waits for detect/connect event from AP Stage-2 ======= SVC: - ON connect/detect event, SVC send back wake pulse (cold boot) to AP over wake_detect pin, if SVC boot is completed. AP: - On wake pulse from SVC (for cold boot), AP de-asserts (set high') reset signal to APB 1 and/or 2 - Bridges starts booting - Eventually Unipro linkup occurs Testing: - Build tested against Helium kernel - Due to unavailability of MSM and DB3 platform, only minimal testing has been done. - Code has been modified for validation on Helium + SDB platform. Mostly dts changes for gpio numbers And debug messages to check gpio values - On Helium + SDB platform, with addition of debug messages validated the sequence. TODO list: - Currently _only_ supports power on sequence (cold boot). Both warm and cold boot support. Cold and Warm boot is differentiated based on pulse width of wake_detect signal >=5 msec = Cold boot else Warm boot - No support for Power management So the "power-down", "power-off", "wake_in" and "wake_out" signals are not explored/implemented. - Support for Work thread repetitive wake signal if no response from peer May required for PM support, as we have delays in the sequences - pinctrl states, specially to make sure we enable right pullup or pulldown when we set wake_detect pin to input - Convert gpio list into an array, and associated xxx-gpio-name property Signed-off-by: Vaibhav Hiremath <vaibhav.hiremath@linaro.org> Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
2015-10-21 11:20:20 +00:00
arche_pdata->svc_sysboot_gpio = of_get_named_gpio(np,
"svc,sysboot-gpio", 0);
if (arche_pdata->svc_sysboot_gpio < 0) {
dev_err(dev, "failed to get sysboot gpio\n");
return arche_pdata->svc_sysboot_gpio;
greybus: platform: Add platform driver for DB3 AP bridge With DB3, we now have AP as a master as far as AP bridges are concerned. SVC will talk only to AP and AP will control bridges; unlike other module interfaces. So AP supposed to manage/control bridges in all power states including power on reset. During power on reset AP should follow below sequence - Sequence (treated as a Cold Boot) Stage-1 ======= AP: - Power On (Power up from PMIC to AP) - AP start booting Since power to AP bridges are controlled through gpio, power is gated to APB1 & 2 No ref_clk to APB available (under SVC's control) - AP configures USB hub to enable HSIC interface to APB - As part of platform driver probe, AP follow below sequence - Set the pinctrl in default state - Hold APBs in reset by pulling down reset pin - Enable power to APB by enabling regulator and switches - De-assert (set 'low') 'boot_ret' signal - AP will assert (set 'high') the wake_detect signal, triggering connect/detect event to the SVC - AP waits for wake pulse from SVC SVC: - Power On (power up from PMIC to SVC) - SVC starts booting - SVC will de-assert reset signal to unipro switch - Switch starts booting - SVC confirms switch boot status using SPI (or something) - SVC waits for 300 msec (ES2 known issue) - SVC waits for detect/connect event from AP Stage-2 ======= SVC: - ON connect/detect event, SVC send back wake pulse (cold boot) to AP over wake_detect pin, if SVC boot is completed. AP: - On wake pulse from SVC (for cold boot), AP de-asserts (set high') reset signal to APB 1 and/or 2 - Bridges starts booting - Eventually Unipro linkup occurs Testing: - Build tested against Helium kernel - Due to unavailability of MSM and DB3 platform, only minimal testing has been done. - Code has been modified for validation on Helium + SDB platform. Mostly dts changes for gpio numbers And debug messages to check gpio values - On Helium + SDB platform, with addition of debug messages validated the sequence. TODO list: - Currently _only_ supports power on sequence (cold boot). Both warm and cold boot support. Cold and Warm boot is differentiated based on pulse width of wake_detect signal >=5 msec = Cold boot else Warm boot - No support for Power management So the "power-down", "power-off", "wake_in" and "wake_out" signals are not explored/implemented. - Support for Work thread repetitive wake signal if no response from peer May required for PM support, as we have delays in the sequences - pinctrl states, specially to make sure we enable right pullup or pulldown when we set wake_detect pin to input - Convert gpio list into an array, and associated xxx-gpio-name property Signed-off-by: Vaibhav Hiremath <vaibhav.hiremath@linaro.org> Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
2015-10-21 11:20:20 +00:00
}
ret = devm_gpio_request(dev, arche_pdata->svc_sysboot_gpio, "sysboot0");
if (ret) {
dev_err(dev, "failed to request sysboot0 gpio:%d\n", ret);
return ret;
greybus: platform: Add platform driver for DB3 AP bridge With DB3, we now have AP as a master as far as AP bridges are concerned. SVC will talk only to AP and AP will control bridges; unlike other module interfaces. So AP supposed to manage/control bridges in all power states including power on reset. During power on reset AP should follow below sequence - Sequence (treated as a Cold Boot) Stage-1 ======= AP: - Power On (Power up from PMIC to AP) - AP start booting Since power to AP bridges are controlled through gpio, power is gated to APB1 & 2 No ref_clk to APB available (under SVC's control) - AP configures USB hub to enable HSIC interface to APB - As part of platform driver probe, AP follow below sequence - Set the pinctrl in default state - Hold APBs in reset by pulling down reset pin - Enable power to APB by enabling regulator and switches - De-assert (set 'low') 'boot_ret' signal - AP will assert (set 'high') the wake_detect signal, triggering connect/detect event to the SVC - AP waits for wake pulse from SVC SVC: - Power On (power up from PMIC to SVC) - SVC starts booting - SVC will de-assert reset signal to unipro switch - Switch starts booting - SVC confirms switch boot status using SPI (or something) - SVC waits for 300 msec (ES2 known issue) - SVC waits for detect/connect event from AP Stage-2 ======= SVC: - ON connect/detect event, SVC send back wake pulse (cold boot) to AP over wake_detect pin, if SVC boot is completed. AP: - On wake pulse from SVC (for cold boot), AP de-asserts (set high') reset signal to APB 1 and/or 2 - Bridges starts booting - Eventually Unipro linkup occurs Testing: - Build tested against Helium kernel - Due to unavailability of MSM and DB3 platform, only minimal testing has been done. - Code has been modified for validation on Helium + SDB platform. Mostly dts changes for gpio numbers And debug messages to check gpio values - On Helium + SDB platform, with addition of debug messages validated the sequence. TODO list: - Currently _only_ supports power on sequence (cold boot). Both warm and cold boot support. Cold and Warm boot is differentiated based on pulse width of wake_detect signal >=5 msec = Cold boot else Warm boot - No support for Power management So the "power-down", "power-off", "wake_in" and "wake_out" signals are not explored/implemented. - Support for Work thread repetitive wake signal if no response from peer May required for PM support, as we have delays in the sequences - pinctrl states, specially to make sure we enable right pullup or pulldown when we set wake_detect pin to input - Convert gpio list into an array, and associated xxx-gpio-name property Signed-off-by: Vaibhav Hiremath <vaibhav.hiremath@linaro.org> Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
2015-10-21 11:20:20 +00:00
}
ret = gpio_direction_output(arche_pdata->svc_sysboot_gpio, 0);
if (ret) {
dev_err(dev, "failed to set svc-reset gpio dir:%d\n", ret);
return ret;
greybus: platform: Add platform driver for DB3 AP bridge With DB3, we now have AP as a master as far as AP bridges are concerned. SVC will talk only to AP and AP will control bridges; unlike other module interfaces. So AP supposed to manage/control bridges in all power states including power on reset. During power on reset AP should follow below sequence - Sequence (treated as a Cold Boot) Stage-1 ======= AP: - Power On (Power up from PMIC to AP) - AP start booting Since power to AP bridges are controlled through gpio, power is gated to APB1 & 2 No ref_clk to APB available (under SVC's control) - AP configures USB hub to enable HSIC interface to APB - As part of platform driver probe, AP follow below sequence - Set the pinctrl in default state - Hold APBs in reset by pulling down reset pin - Enable power to APB by enabling regulator and switches - De-assert (set 'low') 'boot_ret' signal - AP will assert (set 'high') the wake_detect signal, triggering connect/detect event to the SVC - AP waits for wake pulse from SVC SVC: - Power On (power up from PMIC to SVC) - SVC starts booting - SVC will de-assert reset signal to unipro switch - Switch starts booting - SVC confirms switch boot status using SPI (or something) - SVC waits for 300 msec (ES2 known issue) - SVC waits for detect/connect event from AP Stage-2 ======= SVC: - ON connect/detect event, SVC send back wake pulse (cold boot) to AP over wake_detect pin, if SVC boot is completed. AP: - On wake pulse from SVC (for cold boot), AP de-asserts (set high') reset signal to APB 1 and/or 2 - Bridges starts booting - Eventually Unipro linkup occurs Testing: - Build tested against Helium kernel - Due to unavailability of MSM and DB3 platform, only minimal testing has been done. - Code has been modified for validation on Helium + SDB platform. Mostly dts changes for gpio numbers And debug messages to check gpio values - On Helium + SDB platform, with addition of debug messages validated the sequence. TODO list: - Currently _only_ supports power on sequence (cold boot). Both warm and cold boot support. Cold and Warm boot is differentiated based on pulse width of wake_detect signal >=5 msec = Cold boot else Warm boot - No support for Power management So the "power-down", "power-off", "wake_in" and "wake_out" signals are not explored/implemented. - Support for Work thread repetitive wake signal if no response from peer May required for PM support, as we have delays in the sequences - pinctrl states, specially to make sure we enable right pullup or pulldown when we set wake_detect pin to input - Convert gpio list into an array, and associated xxx-gpio-name property Signed-off-by: Vaibhav Hiremath <vaibhav.hiremath@linaro.org> Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
2015-10-21 11:20:20 +00:00
}
/* setup the clock request gpio first */
arche_pdata->svc_refclk_req = of_get_named_gpio(np,
"svc,refclk-req-gpio", 0);
if (arche_pdata->svc_refclk_req < 0) {
dev_err(dev, "failed to get svc clock-req gpio\n");
return arche_pdata->svc_refclk_req;
greybus: platform: Add platform driver for DB3 AP bridge With DB3, we now have AP as a master as far as AP bridges are concerned. SVC will talk only to AP and AP will control bridges; unlike other module interfaces. So AP supposed to manage/control bridges in all power states including power on reset. During power on reset AP should follow below sequence - Sequence (treated as a Cold Boot) Stage-1 ======= AP: - Power On (Power up from PMIC to AP) - AP start booting Since power to AP bridges are controlled through gpio, power is gated to APB1 & 2 No ref_clk to APB available (under SVC's control) - AP configures USB hub to enable HSIC interface to APB - As part of platform driver probe, AP follow below sequence - Set the pinctrl in default state - Hold APBs in reset by pulling down reset pin - Enable power to APB by enabling regulator and switches - De-assert (set 'low') 'boot_ret' signal - AP will assert (set 'high') the wake_detect signal, triggering connect/detect event to the SVC - AP waits for wake pulse from SVC SVC: - Power On (power up from PMIC to SVC) - SVC starts booting - SVC will de-assert reset signal to unipro switch - Switch starts booting - SVC confirms switch boot status using SPI (or something) - SVC waits for 300 msec (ES2 known issue) - SVC waits for detect/connect event from AP Stage-2 ======= SVC: - ON connect/detect event, SVC send back wake pulse (cold boot) to AP over wake_detect pin, if SVC boot is completed. AP: - On wake pulse from SVC (for cold boot), AP de-asserts (set high') reset signal to APB 1 and/or 2 - Bridges starts booting - Eventually Unipro linkup occurs Testing: - Build tested against Helium kernel - Due to unavailability of MSM and DB3 platform, only minimal testing has been done. - Code has been modified for validation on Helium + SDB platform. Mostly dts changes for gpio numbers And debug messages to check gpio values - On Helium + SDB platform, with addition of debug messages validated the sequence. TODO list: - Currently _only_ supports power on sequence (cold boot). Both warm and cold boot support. Cold and Warm boot is differentiated based on pulse width of wake_detect signal >=5 msec = Cold boot else Warm boot - No support for Power management So the "power-down", "power-off", "wake_in" and "wake_out" signals are not explored/implemented. - Support for Work thread repetitive wake signal if no response from peer May required for PM support, as we have delays in the sequences - pinctrl states, specially to make sure we enable right pullup or pulldown when we set wake_detect pin to input - Convert gpio list into an array, and associated xxx-gpio-name property Signed-off-by: Vaibhav Hiremath <vaibhav.hiremath@linaro.org> Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
2015-10-21 11:20:20 +00:00
}
ret = devm_gpio_request(dev, arche_pdata->svc_refclk_req, "svc-clk-req");
if (ret) {
dev_err(dev, "failed to request svc-clk-req gpio: %d\n", ret);
return ret;
greybus: platform: Add platform driver for DB3 AP bridge With DB3, we now have AP as a master as far as AP bridges are concerned. SVC will talk only to AP and AP will control bridges; unlike other module interfaces. So AP supposed to manage/control bridges in all power states including power on reset. During power on reset AP should follow below sequence - Sequence (treated as a Cold Boot) Stage-1 ======= AP: - Power On (Power up from PMIC to AP) - AP start booting Since power to AP bridges are controlled through gpio, power is gated to APB1 & 2 No ref_clk to APB available (under SVC's control) - AP configures USB hub to enable HSIC interface to APB - As part of platform driver probe, AP follow below sequence - Set the pinctrl in default state - Hold APBs in reset by pulling down reset pin - Enable power to APB by enabling regulator and switches - De-assert (set 'low') 'boot_ret' signal - AP will assert (set 'high') the wake_detect signal, triggering connect/detect event to the SVC - AP waits for wake pulse from SVC SVC: - Power On (power up from PMIC to SVC) - SVC starts booting - SVC will de-assert reset signal to unipro switch - Switch starts booting - SVC confirms switch boot status using SPI (or something) - SVC waits for 300 msec (ES2 known issue) - SVC waits for detect/connect event from AP Stage-2 ======= SVC: - ON connect/detect event, SVC send back wake pulse (cold boot) to AP over wake_detect pin, if SVC boot is completed. AP: - On wake pulse from SVC (for cold boot), AP de-asserts (set high') reset signal to APB 1 and/or 2 - Bridges starts booting - Eventually Unipro linkup occurs Testing: - Build tested against Helium kernel - Due to unavailability of MSM and DB3 platform, only minimal testing has been done. - Code has been modified for validation on Helium + SDB platform. Mostly dts changes for gpio numbers And debug messages to check gpio values - On Helium + SDB platform, with addition of debug messages validated the sequence. TODO list: - Currently _only_ supports power on sequence (cold boot). Both warm and cold boot support. Cold and Warm boot is differentiated based on pulse width of wake_detect signal >=5 msec = Cold boot else Warm boot - No support for Power management So the "power-down", "power-off", "wake_in" and "wake_out" signals are not explored/implemented. - Support for Work thread repetitive wake signal if no response from peer May required for PM support, as we have delays in the sequences - pinctrl states, specially to make sure we enable right pullup or pulldown when we set wake_detect pin to input - Convert gpio list into an array, and associated xxx-gpio-name property Signed-off-by: Vaibhav Hiremath <vaibhav.hiremath@linaro.org> Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
2015-10-21 11:20:20 +00:00
}
ret = gpio_direction_input(arche_pdata->svc_refclk_req);
greybus: platform: Add platform driver for DB3 AP bridge With DB3, we now have AP as a master as far as AP bridges are concerned. SVC will talk only to AP and AP will control bridges; unlike other module interfaces. So AP supposed to manage/control bridges in all power states including power on reset. During power on reset AP should follow below sequence - Sequence (treated as a Cold Boot) Stage-1 ======= AP: - Power On (Power up from PMIC to AP) - AP start booting Since power to AP bridges are controlled through gpio, power is gated to APB1 & 2 No ref_clk to APB available (under SVC's control) - AP configures USB hub to enable HSIC interface to APB - As part of platform driver probe, AP follow below sequence - Set the pinctrl in default state - Hold APBs in reset by pulling down reset pin - Enable power to APB by enabling regulator and switches - De-assert (set 'low') 'boot_ret' signal - AP will assert (set 'high') the wake_detect signal, triggering connect/detect event to the SVC - AP waits for wake pulse from SVC SVC: - Power On (power up from PMIC to SVC) - SVC starts booting - SVC will de-assert reset signal to unipro switch - Switch starts booting - SVC confirms switch boot status using SPI (or something) - SVC waits for 300 msec (ES2 known issue) - SVC waits for detect/connect event from AP Stage-2 ======= SVC: - ON connect/detect event, SVC send back wake pulse (cold boot) to AP over wake_detect pin, if SVC boot is completed. AP: - On wake pulse from SVC (for cold boot), AP de-asserts (set high') reset signal to APB 1 and/or 2 - Bridges starts booting - Eventually Unipro linkup occurs Testing: - Build tested against Helium kernel - Due to unavailability of MSM and DB3 platform, only minimal testing has been done. - Code has been modified for validation on Helium + SDB platform. Mostly dts changes for gpio numbers And debug messages to check gpio values - On Helium + SDB platform, with addition of debug messages validated the sequence. TODO list: - Currently _only_ supports power on sequence (cold boot). Both warm and cold boot support. Cold and Warm boot is differentiated based on pulse width of wake_detect signal >=5 msec = Cold boot else Warm boot - No support for Power management So the "power-down", "power-off", "wake_in" and "wake_out" signals are not explored/implemented. - Support for Work thread repetitive wake signal if no response from peer May required for PM support, as we have delays in the sequences - pinctrl states, specially to make sure we enable right pullup or pulldown when we set wake_detect pin to input - Convert gpio list into an array, and associated xxx-gpio-name property Signed-off-by: Vaibhav Hiremath <vaibhav.hiremath@linaro.org> Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
2015-10-21 11:20:20 +00:00
if (ret) {
dev_err(dev, "failed to set svc-clk-req gpio dir :%d\n", ret);
greybus: platform: Add platform driver for DB3 AP bridge With DB3, we now have AP as a master as far as AP bridges are concerned. SVC will talk only to AP and AP will control bridges; unlike other module interfaces. So AP supposed to manage/control bridges in all power states including power on reset. During power on reset AP should follow below sequence - Sequence (treated as a Cold Boot) Stage-1 ======= AP: - Power On (Power up from PMIC to AP) - AP start booting Since power to AP bridges are controlled through gpio, power is gated to APB1 & 2 No ref_clk to APB available (under SVC's control) - AP configures USB hub to enable HSIC interface to APB - As part of platform driver probe, AP follow below sequence - Set the pinctrl in default state - Hold APBs in reset by pulling down reset pin - Enable power to APB by enabling regulator and switches - De-assert (set 'low') 'boot_ret' signal - AP will assert (set 'high') the wake_detect signal, triggering connect/detect event to the SVC - AP waits for wake pulse from SVC SVC: - Power On (power up from PMIC to SVC) - SVC starts booting - SVC will de-assert reset signal to unipro switch - Switch starts booting - SVC confirms switch boot status using SPI (or something) - SVC waits for 300 msec (ES2 known issue) - SVC waits for detect/connect event from AP Stage-2 ======= SVC: - ON connect/detect event, SVC send back wake pulse (cold boot) to AP over wake_detect pin, if SVC boot is completed. AP: - On wake pulse from SVC (for cold boot), AP de-asserts (set high') reset signal to APB 1 and/or 2 - Bridges starts booting - Eventually Unipro linkup occurs Testing: - Build tested against Helium kernel - Due to unavailability of MSM and DB3 platform, only minimal testing has been done. - Code has been modified for validation on Helium + SDB platform. Mostly dts changes for gpio numbers And debug messages to check gpio values - On Helium + SDB platform, with addition of debug messages validated the sequence. TODO list: - Currently _only_ supports power on sequence (cold boot). Both warm and cold boot support. Cold and Warm boot is differentiated based on pulse width of wake_detect signal >=5 msec = Cold boot else Warm boot - No support for Power management So the "power-down", "power-off", "wake_in" and "wake_out" signals are not explored/implemented. - Support for Work thread repetitive wake signal if no response from peer May required for PM support, as we have delays in the sequences - pinctrl states, specially to make sure we enable right pullup or pulldown when we set wake_detect pin to input - Convert gpio list into an array, and associated xxx-gpio-name property Signed-off-by: Vaibhav Hiremath <vaibhav.hiremath@linaro.org> Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
2015-10-21 11:20:20 +00:00
return ret;
}
/* setup refclk2 to follow the pin */
arche_pdata->svc_ref_clk = devm_clk_get(dev, "svc_ref_clk");
if (IS_ERR(arche_pdata->svc_ref_clk)) {
ret = PTR_ERR(arche_pdata->svc_ref_clk);
dev_err(dev, "failed to get svc_ref_clk: %d\n", ret);
return ret;
}
greybus: platform: Add platform driver for DB3 AP bridge With DB3, we now have AP as a master as far as AP bridges are concerned. SVC will talk only to AP and AP will control bridges; unlike other module interfaces. So AP supposed to manage/control bridges in all power states including power on reset. During power on reset AP should follow below sequence - Sequence (treated as a Cold Boot) Stage-1 ======= AP: - Power On (Power up from PMIC to AP) - AP start booting Since power to AP bridges are controlled through gpio, power is gated to APB1 & 2 No ref_clk to APB available (under SVC's control) - AP configures USB hub to enable HSIC interface to APB - As part of platform driver probe, AP follow below sequence - Set the pinctrl in default state - Hold APBs in reset by pulling down reset pin - Enable power to APB by enabling regulator and switches - De-assert (set 'low') 'boot_ret' signal - AP will assert (set 'high') the wake_detect signal, triggering connect/detect event to the SVC - AP waits for wake pulse from SVC SVC: - Power On (power up from PMIC to SVC) - SVC starts booting - SVC will de-assert reset signal to unipro switch - Switch starts booting - SVC confirms switch boot status using SPI (or something) - SVC waits for 300 msec (ES2 known issue) - SVC waits for detect/connect event from AP Stage-2 ======= SVC: - ON connect/detect event, SVC send back wake pulse (cold boot) to AP over wake_detect pin, if SVC boot is completed. AP: - On wake pulse from SVC (for cold boot), AP de-asserts (set high') reset signal to APB 1 and/or 2 - Bridges starts booting - Eventually Unipro linkup occurs Testing: - Build tested against Helium kernel - Due to unavailability of MSM and DB3 platform, only minimal testing has been done. - Code has been modified for validation on Helium + SDB platform. Mostly dts changes for gpio numbers And debug messages to check gpio values - On Helium + SDB platform, with addition of debug messages validated the sequence. TODO list: - Currently _only_ supports power on sequence (cold boot). Both warm and cold boot support. Cold and Warm boot is differentiated based on pulse width of wake_detect signal >=5 msec = Cold boot else Warm boot - No support for Power management So the "power-down", "power-off", "wake_in" and "wake_out" signals are not explored/implemented. - Support for Work thread repetitive wake signal if no response from peer May required for PM support, as we have delays in the sequences - pinctrl states, specially to make sure we enable right pullup or pulldown when we set wake_detect pin to input - Convert gpio list into an array, and associated xxx-gpio-name property Signed-off-by: Vaibhav Hiremath <vaibhav.hiremath@linaro.org> Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
2015-10-21 11:20:20 +00:00
platform_set_drvdata(pdev, arche_pdata);
greybus: platform: Add platform driver for DB3 AP bridge With DB3, we now have AP as a master as far as AP bridges are concerned. SVC will talk only to AP and AP will control bridges; unlike other module interfaces. So AP supposed to manage/control bridges in all power states including power on reset. During power on reset AP should follow below sequence - Sequence (treated as a Cold Boot) Stage-1 ======= AP: - Power On (Power up from PMIC to AP) - AP start booting Since power to AP bridges are controlled through gpio, power is gated to APB1 & 2 No ref_clk to APB available (under SVC's control) - AP configures USB hub to enable HSIC interface to APB - As part of platform driver probe, AP follow below sequence - Set the pinctrl in default state - Hold APBs in reset by pulling down reset pin - Enable power to APB by enabling regulator and switches - De-assert (set 'low') 'boot_ret' signal - AP will assert (set 'high') the wake_detect signal, triggering connect/detect event to the SVC - AP waits for wake pulse from SVC SVC: - Power On (power up from PMIC to SVC) - SVC starts booting - SVC will de-assert reset signal to unipro switch - Switch starts booting - SVC confirms switch boot status using SPI (or something) - SVC waits for 300 msec (ES2 known issue) - SVC waits for detect/connect event from AP Stage-2 ======= SVC: - ON connect/detect event, SVC send back wake pulse (cold boot) to AP over wake_detect pin, if SVC boot is completed. AP: - On wake pulse from SVC (for cold boot), AP de-asserts (set high') reset signal to APB 1 and/or 2 - Bridges starts booting - Eventually Unipro linkup occurs Testing: - Build tested against Helium kernel - Due to unavailability of MSM and DB3 platform, only minimal testing has been done. - Code has been modified for validation on Helium + SDB platform. Mostly dts changes for gpio numbers And debug messages to check gpio values - On Helium + SDB platform, with addition of debug messages validated the sequence. TODO list: - Currently _only_ supports power on sequence (cold boot). Both warm and cold boot support. Cold and Warm boot is differentiated based on pulse width of wake_detect signal >=5 msec = Cold boot else Warm boot - No support for Power management So the "power-down", "power-off", "wake_in" and "wake_out" signals are not explored/implemented. - Support for Work thread repetitive wake signal if no response from peer May required for PM support, as we have delays in the sequences - pinctrl states, specially to make sure we enable right pullup or pulldown when we set wake_detect pin to input - Convert gpio list into an array, and associated xxx-gpio-name property Signed-off-by: Vaibhav Hiremath <vaibhav.hiremath@linaro.org> Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
2015-10-21 11:20:20 +00:00
arche_pdata->num_apbs = of_get_child_count(np);
dev_dbg(dev, "Number of APB's available - %d\n", arche_pdata->num_apbs);
greybus: platform: Add platform driver for DB3 AP bridge With DB3, we now have AP as a master as far as AP bridges are concerned. SVC will talk only to AP and AP will control bridges; unlike other module interfaces. So AP supposed to manage/control bridges in all power states including power on reset. During power on reset AP should follow below sequence - Sequence (treated as a Cold Boot) Stage-1 ======= AP: - Power On (Power up from PMIC to AP) - AP start booting Since power to AP bridges are controlled through gpio, power is gated to APB1 & 2 No ref_clk to APB available (under SVC's control) - AP configures USB hub to enable HSIC interface to APB - As part of platform driver probe, AP follow below sequence - Set the pinctrl in default state - Hold APBs in reset by pulling down reset pin - Enable power to APB by enabling regulator and switches - De-assert (set 'low') 'boot_ret' signal - AP will assert (set 'high') the wake_detect signal, triggering connect/detect event to the SVC - AP waits for wake pulse from SVC SVC: - Power On (power up from PMIC to SVC) - SVC starts booting - SVC will de-assert reset signal to unipro switch - Switch starts booting - SVC confirms switch boot status using SPI (or something) - SVC waits for 300 msec (ES2 known issue) - SVC waits for detect/connect event from AP Stage-2 ======= SVC: - ON connect/detect event, SVC send back wake pulse (cold boot) to AP over wake_detect pin, if SVC boot is completed. AP: - On wake pulse from SVC (for cold boot), AP de-asserts (set high') reset signal to APB 1 and/or 2 - Bridges starts booting - Eventually Unipro linkup occurs Testing: - Build tested against Helium kernel - Due to unavailability of MSM and DB3 platform, only minimal testing has been done. - Code has been modified for validation on Helium + SDB platform. Mostly dts changes for gpio numbers And debug messages to check gpio values - On Helium + SDB platform, with addition of debug messages validated the sequence. TODO list: - Currently _only_ supports power on sequence (cold boot). Both warm and cold boot support. Cold and Warm boot is differentiated based on pulse width of wake_detect signal >=5 msec = Cold boot else Warm boot - No support for Power management So the "power-down", "power-off", "wake_in" and "wake_out" signals are not explored/implemented. - Support for Work thread repetitive wake signal if no response from peer May required for PM support, as we have delays in the sequences - pinctrl states, specially to make sure we enable right pullup or pulldown when we set wake_detect pin to input - Convert gpio list into an array, and associated xxx-gpio-name property Signed-off-by: Vaibhav Hiremath <vaibhav.hiremath@linaro.org> Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
2015-10-21 11:20:20 +00:00
greybus: arche-platform: Add wake/detect support along with handshaking with AP Add wake_detect support to arche-platform driver which is responsible for SVC control. This patch also adds code for handshaking between AP <=> SVC. The sequence is, 1. AP boots To keep compatibility between DB3 and EVT platform, SVC will be help in reset and AP driver would release it at appropriate time. wake/detect pin (WD8A) = Low reset (SVC/APB1/APB2) = Asserted (as per polarity) 2. AP Driver gets inserted 2.1. AP will deassert reset to SVC (following power on sequence) 2.2. SVC allows 360 milliseconds to elapse after switch boots to work around bug described in ENG-330. 2.3. AP asserts wake/detect pin (WD8A = HIGH) 3. SVC detects assertion of wake/detect pin, and sends "wake out" signal to AP 4. AP receives "wake out" signal, takes AP Bridges through their power on reset sequence as defined in the bridge ASIC reference manuals 5. AP takes USB3613 through its power on reset sequence 6. AP should enumerates AP Bridges Note: ISR has been deliberately removed (not merged) as we are still not sure how it will be used, in runtime usage context. Driver as such doesn't do anything for runtime assert-n-deassert of reset to SVC/APB's, it just simply offloads it to user by exporting required gpio's. The exported gpio's are required for FW flashing from user space. When it comes to usersace manipulated control sequence, user has to manage. Signed-off-by: Vaibhav Hiremath <vaibhav.hiremath@linaro.org> Tested-by: Michael Scott <michael.scott@linaro.org> Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
2016-01-11 12:11:24 +00:00
arche_pdata->wake_detect_gpio = of_get_named_gpio(np, "svc,wake-detect-gpio", 0);
if (arche_pdata->wake_detect_gpio < 0) {
dev_err(dev, "failed to get wake detect gpio\n");
ret = arche_pdata->wake_detect_gpio;
return ret;
greybus: arche-platform: Add wake/detect support along with handshaking with AP Add wake_detect support to arche-platform driver which is responsible for SVC control. This patch also adds code for handshaking between AP <=> SVC. The sequence is, 1. AP boots To keep compatibility between DB3 and EVT platform, SVC will be help in reset and AP driver would release it at appropriate time. wake/detect pin (WD8A) = Low reset (SVC/APB1/APB2) = Asserted (as per polarity) 2. AP Driver gets inserted 2.1. AP will deassert reset to SVC (following power on sequence) 2.2. SVC allows 360 milliseconds to elapse after switch boots to work around bug described in ENG-330. 2.3. AP asserts wake/detect pin (WD8A = HIGH) 3. SVC detects assertion of wake/detect pin, and sends "wake out" signal to AP 4. AP receives "wake out" signal, takes AP Bridges through their power on reset sequence as defined in the bridge ASIC reference manuals 5. AP takes USB3613 through its power on reset sequence 6. AP should enumerates AP Bridges Note: ISR has been deliberately removed (not merged) as we are still not sure how it will be used, in runtime usage context. Driver as such doesn't do anything for runtime assert-n-deassert of reset to SVC/APB's, it just simply offloads it to user by exporting required gpio's. The exported gpio's are required for FW flashing from user space. When it comes to usersace manipulated control sequence, user has to manage. Signed-off-by: Vaibhav Hiremath <vaibhav.hiremath@linaro.org> Tested-by: Michael Scott <michael.scott@linaro.org> Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
2016-01-11 12:11:24 +00:00
}
ret = devm_gpio_request(dev, arche_pdata->wake_detect_gpio, "wake detect");
if (ret) {
greybus: arche-platform: Add wake/detect support along with handshaking with AP Add wake_detect support to arche-platform driver which is responsible for SVC control. This patch also adds code for handshaking between AP <=> SVC. The sequence is, 1. AP boots To keep compatibility between DB3 and EVT platform, SVC will be help in reset and AP driver would release it at appropriate time. wake/detect pin (WD8A) = Low reset (SVC/APB1/APB2) = Asserted (as per polarity) 2. AP Driver gets inserted 2.1. AP will deassert reset to SVC (following power on sequence) 2.2. SVC allows 360 milliseconds to elapse after switch boots to work around bug described in ENG-330. 2.3. AP asserts wake/detect pin (WD8A = HIGH) 3. SVC detects assertion of wake/detect pin, and sends "wake out" signal to AP 4. AP receives "wake out" signal, takes AP Bridges through their power on reset sequence as defined in the bridge ASIC reference manuals 5. AP takes USB3613 through its power on reset sequence 6. AP should enumerates AP Bridges Note: ISR has been deliberately removed (not merged) as we are still not sure how it will be used, in runtime usage context. Driver as such doesn't do anything for runtime assert-n-deassert of reset to SVC/APB's, it just simply offloads it to user by exporting required gpio's. The exported gpio's are required for FW flashing from user space. When it comes to usersace manipulated control sequence, user has to manage. Signed-off-by: Vaibhav Hiremath <vaibhav.hiremath@linaro.org> Tested-by: Michael Scott <michael.scott@linaro.org> Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
2016-01-11 12:11:24 +00:00
dev_err(dev, "Failed requesting wake_detect gpio %d\n",
arche_pdata->wake_detect_gpio);
return ret;
}
/* deassert wake detect */
gpio_direction_output(arche_pdata->wake_detect_gpio, 0);
greybus: platform: Add platform driver for DB3 AP bridge With DB3, we now have AP as a master as far as AP bridges are concerned. SVC will talk only to AP and AP will control bridges; unlike other module interfaces. So AP supposed to manage/control bridges in all power states including power on reset. During power on reset AP should follow below sequence - Sequence (treated as a Cold Boot) Stage-1 ======= AP: - Power On (Power up from PMIC to AP) - AP start booting Since power to AP bridges are controlled through gpio, power is gated to APB1 & 2 No ref_clk to APB available (under SVC's control) - AP configures USB hub to enable HSIC interface to APB - As part of platform driver probe, AP follow below sequence - Set the pinctrl in default state - Hold APBs in reset by pulling down reset pin - Enable power to APB by enabling regulator and switches - De-assert (set 'low') 'boot_ret' signal - AP will assert (set 'high') the wake_detect signal, triggering connect/detect event to the SVC - AP waits for wake pulse from SVC SVC: - Power On (power up from PMIC to SVC) - SVC starts booting - SVC will de-assert reset signal to unipro switch - Switch starts booting - SVC confirms switch boot status using SPI (or something) - SVC waits for 300 msec (ES2 known issue) - SVC waits for detect/connect event from AP Stage-2 ======= SVC: - ON connect/detect event, SVC send back wake pulse (cold boot) to AP over wake_detect pin, if SVC boot is completed. AP: - On wake pulse from SVC (for cold boot), AP de-asserts (set high') reset signal to APB 1 and/or 2 - Bridges starts booting - Eventually Unipro linkup occurs Testing: - Build tested against Helium kernel - Due to unavailability of MSM and DB3 platform, only minimal testing has been done. - Code has been modified for validation on Helium + SDB platform. Mostly dts changes for gpio numbers And debug messages to check gpio values - On Helium + SDB platform, with addition of debug messages validated the sequence. TODO list: - Currently _only_ supports power on sequence (cold boot). Both warm and cold boot support. Cold and Warm boot is differentiated based on pulse width of wake_detect signal >=5 msec = Cold boot else Warm boot - No support for Power management So the "power-down", "power-off", "wake_in" and "wake_out" signals are not explored/implemented. - Support for Work thread repetitive wake signal if no response from peer May required for PM support, as we have delays in the sequences - pinctrl states, specially to make sure we enable right pullup or pulldown when we set wake_detect pin to input - Convert gpio list into an array, and associated xxx-gpio-name property Signed-off-by: Vaibhav Hiremath <vaibhav.hiremath@linaro.org> Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
2015-10-21 11:20:20 +00:00
greybus: arche-platform: Add wake/detect support along with handshaking with AP Add wake_detect support to arche-platform driver which is responsible for SVC control. This patch also adds code for handshaking between AP <=> SVC. The sequence is, 1. AP boots To keep compatibility between DB3 and EVT platform, SVC will be help in reset and AP driver would release it at appropriate time. wake/detect pin (WD8A) = Low reset (SVC/APB1/APB2) = Asserted (as per polarity) 2. AP Driver gets inserted 2.1. AP will deassert reset to SVC (following power on sequence) 2.2. SVC allows 360 milliseconds to elapse after switch boots to work around bug described in ENG-330. 2.3. AP asserts wake/detect pin (WD8A = HIGH) 3. SVC detects assertion of wake/detect pin, and sends "wake out" signal to AP 4. AP receives "wake out" signal, takes AP Bridges through their power on reset sequence as defined in the bridge ASIC reference manuals 5. AP takes USB3613 through its power on reset sequence 6. AP should enumerates AP Bridges Note: ISR has been deliberately removed (not merged) as we are still not sure how it will be used, in runtime usage context. Driver as such doesn't do anything for runtime assert-n-deassert of reset to SVC/APB's, it just simply offloads it to user by exporting required gpio's. The exported gpio's are required for FW flashing from user space. When it comes to usersace manipulated control sequence, user has to manage. Signed-off-by: Vaibhav Hiremath <vaibhav.hiremath@linaro.org> Tested-by: Michael Scott <michael.scott@linaro.org> Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
2016-01-11 12:11:24 +00:00
arche_pdata->dev = &pdev->dev;
INIT_DELAYED_WORK(&arche_pdata->delayed_work, svc_delayed_work);
schedule_delayed_work(&arche_pdata->delayed_work, msecs_to_jiffies(2000));
ret = device_create_file(dev, &dev_attr_state);
if (ret) {
dev_err(dev, "failed to create state file in sysfs\n");
return ret;
}
ret = arche_platform_coldboot_seq(arche_pdata);
if (ret) {
dev_err(dev, "Failed to cold boot svc %d\n", ret);
return ret;
}
export_gpios(arche_pdata);
dev_info(dev, "Device registered successfully\n");
return 0;
greybus: platform: Add platform driver for DB3 AP bridge With DB3, we now have AP as a master as far as AP bridges are concerned. SVC will talk only to AP and AP will control bridges; unlike other module interfaces. So AP supposed to manage/control bridges in all power states including power on reset. During power on reset AP should follow below sequence - Sequence (treated as a Cold Boot) Stage-1 ======= AP: - Power On (Power up from PMIC to AP) - AP start booting Since power to AP bridges are controlled through gpio, power is gated to APB1 & 2 No ref_clk to APB available (under SVC's control) - AP configures USB hub to enable HSIC interface to APB - As part of platform driver probe, AP follow below sequence - Set the pinctrl in default state - Hold APBs in reset by pulling down reset pin - Enable power to APB by enabling regulator and switches - De-assert (set 'low') 'boot_ret' signal - AP will assert (set 'high') the wake_detect signal, triggering connect/detect event to the SVC - AP waits for wake pulse from SVC SVC: - Power On (power up from PMIC to SVC) - SVC starts booting - SVC will de-assert reset signal to unipro switch - Switch starts booting - SVC confirms switch boot status using SPI (or something) - SVC waits for 300 msec (ES2 known issue) - SVC waits for detect/connect event from AP Stage-2 ======= SVC: - ON connect/detect event, SVC send back wake pulse (cold boot) to AP over wake_detect pin, if SVC boot is completed. AP: - On wake pulse from SVC (for cold boot), AP de-asserts (set high') reset signal to APB 1 and/or 2 - Bridges starts booting - Eventually Unipro linkup occurs Testing: - Build tested against Helium kernel - Due to unavailability of MSM and DB3 platform, only minimal testing has been done. - Code has been modified for validation on Helium + SDB platform. Mostly dts changes for gpio numbers And debug messages to check gpio values - On Helium + SDB platform, with addition of debug messages validated the sequence. TODO list: - Currently _only_ supports power on sequence (cold boot). Both warm and cold boot support. Cold and Warm boot is differentiated based on pulse width of wake_detect signal >=5 msec = Cold boot else Warm boot - No support for Power management So the "power-down", "power-off", "wake_in" and "wake_out" signals are not explored/implemented. - Support for Work thread repetitive wake signal if no response from peer May required for PM support, as we have delays in the sequences - pinctrl states, specially to make sure we enable right pullup or pulldown when we set wake_detect pin to input - Convert gpio list into an array, and associated xxx-gpio-name property Signed-off-by: Vaibhav Hiremath <vaibhav.hiremath@linaro.org> Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
2015-10-21 11:20:20 +00:00
}
static int arche_remove_child(struct device *dev, void *unused)
{
struct platform_device *pdev = to_platform_device(dev);
platform_device_unregister(pdev);
return 0;
}
static int arche_platform_remove(struct platform_device *pdev)
greybus: platform: Add platform driver for DB3 AP bridge With DB3, we now have AP as a master as far as AP bridges are concerned. SVC will talk only to AP and AP will control bridges; unlike other module interfaces. So AP supposed to manage/control bridges in all power states including power on reset. During power on reset AP should follow below sequence - Sequence (treated as a Cold Boot) Stage-1 ======= AP: - Power On (Power up from PMIC to AP) - AP start booting Since power to AP bridges are controlled through gpio, power is gated to APB1 & 2 No ref_clk to APB available (under SVC's control) - AP configures USB hub to enable HSIC interface to APB - As part of platform driver probe, AP follow below sequence - Set the pinctrl in default state - Hold APBs in reset by pulling down reset pin - Enable power to APB by enabling regulator and switches - De-assert (set 'low') 'boot_ret' signal - AP will assert (set 'high') the wake_detect signal, triggering connect/detect event to the SVC - AP waits for wake pulse from SVC SVC: - Power On (power up from PMIC to SVC) - SVC starts booting - SVC will de-assert reset signal to unipro switch - Switch starts booting - SVC confirms switch boot status using SPI (or something) - SVC waits for 300 msec (ES2 known issue) - SVC waits for detect/connect event from AP Stage-2 ======= SVC: - ON connect/detect event, SVC send back wake pulse (cold boot) to AP over wake_detect pin, if SVC boot is completed. AP: - On wake pulse from SVC (for cold boot), AP de-asserts (set high') reset signal to APB 1 and/or 2 - Bridges starts booting - Eventually Unipro linkup occurs Testing: - Build tested against Helium kernel - Due to unavailability of MSM and DB3 platform, only minimal testing has been done. - Code has been modified for validation on Helium + SDB platform. Mostly dts changes for gpio numbers And debug messages to check gpio values - On Helium + SDB platform, with addition of debug messages validated the sequence. TODO list: - Currently _only_ supports power on sequence (cold boot). Both warm and cold boot support. Cold and Warm boot is differentiated based on pulse width of wake_detect signal >=5 msec = Cold boot else Warm boot - No support for Power management So the "power-down", "power-off", "wake_in" and "wake_out" signals are not explored/implemented. - Support for Work thread repetitive wake signal if no response from peer May required for PM support, as we have delays in the sequences - pinctrl states, specially to make sure we enable right pullup or pulldown when we set wake_detect pin to input - Convert gpio list into an array, and associated xxx-gpio-name property Signed-off-by: Vaibhav Hiremath <vaibhav.hiremath@linaro.org> Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
2015-10-21 11:20:20 +00:00
{
struct arche_platform_drvdata *arche_pdata = platform_get_drvdata(pdev);
greybus: platform: Add platform driver for DB3 AP bridge With DB3, we now have AP as a master as far as AP bridges are concerned. SVC will talk only to AP and AP will control bridges; unlike other module interfaces. So AP supposed to manage/control bridges in all power states including power on reset. During power on reset AP should follow below sequence - Sequence (treated as a Cold Boot) Stage-1 ======= AP: - Power On (Power up from PMIC to AP) - AP start booting Since power to AP bridges are controlled through gpio, power is gated to APB1 & 2 No ref_clk to APB available (under SVC's control) - AP configures USB hub to enable HSIC interface to APB - As part of platform driver probe, AP follow below sequence - Set the pinctrl in default state - Hold APBs in reset by pulling down reset pin - Enable power to APB by enabling regulator and switches - De-assert (set 'low') 'boot_ret' signal - AP will assert (set 'high') the wake_detect signal, triggering connect/detect event to the SVC - AP waits for wake pulse from SVC SVC: - Power On (power up from PMIC to SVC) - SVC starts booting - SVC will de-assert reset signal to unipro switch - Switch starts booting - SVC confirms switch boot status using SPI (or something) - SVC waits for 300 msec (ES2 known issue) - SVC waits for detect/connect event from AP Stage-2 ======= SVC: - ON connect/detect event, SVC send back wake pulse (cold boot) to AP over wake_detect pin, if SVC boot is completed. AP: - On wake pulse from SVC (for cold boot), AP de-asserts (set high') reset signal to APB 1 and/or 2 - Bridges starts booting - Eventually Unipro linkup occurs Testing: - Build tested against Helium kernel - Due to unavailability of MSM and DB3 platform, only minimal testing has been done. - Code has been modified for validation on Helium + SDB platform. Mostly dts changes for gpio numbers And debug messages to check gpio values - On Helium + SDB platform, with addition of debug messages validated the sequence. TODO list: - Currently _only_ supports power on sequence (cold boot). Both warm and cold boot support. Cold and Warm boot is differentiated based on pulse width of wake_detect signal >=5 msec = Cold boot else Warm boot - No support for Power management So the "power-down", "power-off", "wake_in" and "wake_out" signals are not explored/implemented. - Support for Work thread repetitive wake signal if no response from peer May required for PM support, as we have delays in the sequences - pinctrl states, specially to make sure we enable right pullup or pulldown when we set wake_detect pin to input - Convert gpio list into an array, and associated xxx-gpio-name property Signed-off-by: Vaibhav Hiremath <vaibhav.hiremath@linaro.org> Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
2015-10-21 11:20:20 +00:00
device_remove_file(&pdev->dev, &dev_attr_state);
cancel_delayed_work_sync(&arche_pdata->delayed_work);
device_for_each_child(&pdev->dev, NULL, arche_remove_child);
arche_platform_poweroff_seq(arche_pdata);
greybus: platform: Add platform driver for DB3 AP bridge With DB3, we now have AP as a master as far as AP bridges are concerned. SVC will talk only to AP and AP will control bridges; unlike other module interfaces. So AP supposed to manage/control bridges in all power states including power on reset. During power on reset AP should follow below sequence - Sequence (treated as a Cold Boot) Stage-1 ======= AP: - Power On (Power up from PMIC to AP) - AP start booting Since power to AP bridges are controlled through gpio, power is gated to APB1 & 2 No ref_clk to APB available (under SVC's control) - AP configures USB hub to enable HSIC interface to APB - As part of platform driver probe, AP follow below sequence - Set the pinctrl in default state - Hold APBs in reset by pulling down reset pin - Enable power to APB by enabling regulator and switches - De-assert (set 'low') 'boot_ret' signal - AP will assert (set 'high') the wake_detect signal, triggering connect/detect event to the SVC - AP waits for wake pulse from SVC SVC: - Power On (power up from PMIC to SVC) - SVC starts booting - SVC will de-assert reset signal to unipro switch - Switch starts booting - SVC confirms switch boot status using SPI (or something) - SVC waits for 300 msec (ES2 known issue) - SVC waits for detect/connect event from AP Stage-2 ======= SVC: - ON connect/detect event, SVC send back wake pulse (cold boot) to AP over wake_detect pin, if SVC boot is completed. AP: - On wake pulse from SVC (for cold boot), AP de-asserts (set high') reset signal to APB 1 and/or 2 - Bridges starts booting - Eventually Unipro linkup occurs Testing: - Build tested against Helium kernel - Due to unavailability of MSM and DB3 platform, only minimal testing has been done. - Code has been modified for validation on Helium + SDB platform. Mostly dts changes for gpio numbers And debug messages to check gpio values - On Helium + SDB platform, with addition of debug messages validated the sequence. TODO list: - Currently _only_ supports power on sequence (cold boot). Both warm and cold boot support. Cold and Warm boot is differentiated based on pulse width of wake_detect signal >=5 msec = Cold boot else Warm boot - No support for Power management So the "power-down", "power-off", "wake_in" and "wake_out" signals are not explored/implemented. - Support for Work thread repetitive wake signal if no response from peer May required for PM support, as we have delays in the sequences - pinctrl states, specially to make sure we enable right pullup or pulldown when we set wake_detect pin to input - Convert gpio list into an array, and associated xxx-gpio-name property Signed-off-by: Vaibhav Hiremath <vaibhav.hiremath@linaro.org> Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
2015-10-21 11:20:20 +00:00
platform_set_drvdata(pdev, NULL);
unexport_gpios(arche_pdata);
greybus: platform: Add platform driver for DB3 AP bridge With DB3, we now have AP as a master as far as AP bridges are concerned. SVC will talk only to AP and AP will control bridges; unlike other module interfaces. So AP supposed to manage/control bridges in all power states including power on reset. During power on reset AP should follow below sequence - Sequence (treated as a Cold Boot) Stage-1 ======= AP: - Power On (Power up from PMIC to AP) - AP start booting Since power to AP bridges are controlled through gpio, power is gated to APB1 & 2 No ref_clk to APB available (under SVC's control) - AP configures USB hub to enable HSIC interface to APB - As part of platform driver probe, AP follow below sequence - Set the pinctrl in default state - Hold APBs in reset by pulling down reset pin - Enable power to APB by enabling regulator and switches - De-assert (set 'low') 'boot_ret' signal - AP will assert (set 'high') the wake_detect signal, triggering connect/detect event to the SVC - AP waits for wake pulse from SVC SVC: - Power On (power up from PMIC to SVC) - SVC starts booting - SVC will de-assert reset signal to unipro switch - Switch starts booting - SVC confirms switch boot status using SPI (or something) - SVC waits for 300 msec (ES2 known issue) - SVC waits for detect/connect event from AP Stage-2 ======= SVC: - ON connect/detect event, SVC send back wake pulse (cold boot) to AP over wake_detect pin, if SVC boot is completed. AP: - On wake pulse from SVC (for cold boot), AP de-asserts (set high') reset signal to APB 1 and/or 2 - Bridges starts booting - Eventually Unipro linkup occurs Testing: - Build tested against Helium kernel - Due to unavailability of MSM and DB3 platform, only minimal testing has been done. - Code has been modified for validation on Helium + SDB platform. Mostly dts changes for gpio numbers And debug messages to check gpio values - On Helium + SDB platform, with addition of debug messages validated the sequence. TODO list: - Currently _only_ supports power on sequence (cold boot). Both warm and cold boot support. Cold and Warm boot is differentiated based on pulse width of wake_detect signal >=5 msec = Cold boot else Warm boot - No support for Power management So the "power-down", "power-off", "wake_in" and "wake_out" signals are not explored/implemented. - Support for Work thread repetitive wake signal if no response from peer May required for PM support, as we have delays in the sequences - pinctrl states, specially to make sure we enable right pullup or pulldown when we set wake_detect pin to input - Convert gpio list into an array, and associated xxx-gpio-name property Signed-off-by: Vaibhav Hiremath <vaibhav.hiremath@linaro.org> Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
2015-10-21 11:20:20 +00:00
return 0;
}
static int arche_platform_suspend(struct device *dev)
greybus: platform: Add platform driver for DB3 AP bridge With DB3, we now have AP as a master as far as AP bridges are concerned. SVC will talk only to AP and AP will control bridges; unlike other module interfaces. So AP supposed to manage/control bridges in all power states including power on reset. During power on reset AP should follow below sequence - Sequence (treated as a Cold Boot) Stage-1 ======= AP: - Power On (Power up from PMIC to AP) - AP start booting Since power to AP bridges are controlled through gpio, power is gated to APB1 & 2 No ref_clk to APB available (under SVC's control) - AP configures USB hub to enable HSIC interface to APB - As part of platform driver probe, AP follow below sequence - Set the pinctrl in default state - Hold APBs in reset by pulling down reset pin - Enable power to APB by enabling regulator and switches - De-assert (set 'low') 'boot_ret' signal - AP will assert (set 'high') the wake_detect signal, triggering connect/detect event to the SVC - AP waits for wake pulse from SVC SVC: - Power On (power up from PMIC to SVC) - SVC starts booting - SVC will de-assert reset signal to unipro switch - Switch starts booting - SVC confirms switch boot status using SPI (or something) - SVC waits for 300 msec (ES2 known issue) - SVC waits for detect/connect event from AP Stage-2 ======= SVC: - ON connect/detect event, SVC send back wake pulse (cold boot) to AP over wake_detect pin, if SVC boot is completed. AP: - On wake pulse from SVC (for cold boot), AP de-asserts (set high') reset signal to APB 1 and/or 2 - Bridges starts booting - Eventually Unipro linkup occurs Testing: - Build tested against Helium kernel - Due to unavailability of MSM and DB3 platform, only minimal testing has been done. - Code has been modified for validation on Helium + SDB platform. Mostly dts changes for gpio numbers And debug messages to check gpio values - On Helium + SDB platform, with addition of debug messages validated the sequence. TODO list: - Currently _only_ supports power on sequence (cold boot). Both warm and cold boot support. Cold and Warm boot is differentiated based on pulse width of wake_detect signal >=5 msec = Cold boot else Warm boot - No support for Power management So the "power-down", "power-off", "wake_in" and "wake_out" signals are not explored/implemented. - Support for Work thread repetitive wake signal if no response from peer May required for PM support, as we have delays in the sequences - pinctrl states, specially to make sure we enable right pullup or pulldown when we set wake_detect pin to input - Convert gpio list into an array, and associated xxx-gpio-name property Signed-off-by: Vaibhav Hiremath <vaibhav.hiremath@linaro.org> Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
2015-10-21 11:20:20 +00:00
{
/*
* If timing profile premits, we may shutdown bridge
* completely
*
* TODO: sequence ??
*
* Also, need to make sure we meet precondition for unipro suspend
* Precondition: Definition ???
*/
return 0;
}
static int arche_platform_resume(struct device *dev)
greybus: platform: Add platform driver for DB3 AP bridge With DB3, we now have AP as a master as far as AP bridges are concerned. SVC will talk only to AP and AP will control bridges; unlike other module interfaces. So AP supposed to manage/control bridges in all power states including power on reset. During power on reset AP should follow below sequence - Sequence (treated as a Cold Boot) Stage-1 ======= AP: - Power On (Power up from PMIC to AP) - AP start booting Since power to AP bridges are controlled through gpio, power is gated to APB1 & 2 No ref_clk to APB available (under SVC's control) - AP configures USB hub to enable HSIC interface to APB - As part of platform driver probe, AP follow below sequence - Set the pinctrl in default state - Hold APBs in reset by pulling down reset pin - Enable power to APB by enabling regulator and switches - De-assert (set 'low') 'boot_ret' signal - AP will assert (set 'high') the wake_detect signal, triggering connect/detect event to the SVC - AP waits for wake pulse from SVC SVC: - Power On (power up from PMIC to SVC) - SVC starts booting - SVC will de-assert reset signal to unipro switch - Switch starts booting - SVC confirms switch boot status using SPI (or something) - SVC waits for 300 msec (ES2 known issue) - SVC waits for detect/connect event from AP Stage-2 ======= SVC: - ON connect/detect event, SVC send back wake pulse (cold boot) to AP over wake_detect pin, if SVC boot is completed. AP: - On wake pulse from SVC (for cold boot), AP de-asserts (set high') reset signal to APB 1 and/or 2 - Bridges starts booting - Eventually Unipro linkup occurs Testing: - Build tested against Helium kernel - Due to unavailability of MSM and DB3 platform, only minimal testing has been done. - Code has been modified for validation on Helium + SDB platform. Mostly dts changes for gpio numbers And debug messages to check gpio values - On Helium + SDB platform, with addition of debug messages validated the sequence. TODO list: - Currently _only_ supports power on sequence (cold boot). Both warm and cold boot support. Cold and Warm boot is differentiated based on pulse width of wake_detect signal >=5 msec = Cold boot else Warm boot - No support for Power management So the "power-down", "power-off", "wake_in" and "wake_out" signals are not explored/implemented. - Support for Work thread repetitive wake signal if no response from peer May required for PM support, as we have delays in the sequences - pinctrl states, specially to make sure we enable right pullup or pulldown when we set wake_detect pin to input - Convert gpio list into an array, and associated xxx-gpio-name property Signed-off-by: Vaibhav Hiremath <vaibhav.hiremath@linaro.org> Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
2015-10-21 11:20:20 +00:00
{
/*
* Atleast for ES2 we have to meet the delay requirement between
* unipro switch and AP bridge init, depending on whether bridge is in
* OFF state or standby state.
*
* Based on whether bridge is in standby or OFF state we may have to
* assert multiple signals. Please refer to WDM spec, for more info.
*
*/
return 0;
}
static SIMPLE_DEV_PM_OPS(arche_platform_pm_ops,
arche_platform_suspend,
arche_platform_resume);
greybus: platform: Add platform driver for DB3 AP bridge With DB3, we now have AP as a master as far as AP bridges are concerned. SVC will talk only to AP and AP will control bridges; unlike other module interfaces. So AP supposed to manage/control bridges in all power states including power on reset. During power on reset AP should follow below sequence - Sequence (treated as a Cold Boot) Stage-1 ======= AP: - Power On (Power up from PMIC to AP) - AP start booting Since power to AP bridges are controlled through gpio, power is gated to APB1 & 2 No ref_clk to APB available (under SVC's control) - AP configures USB hub to enable HSIC interface to APB - As part of platform driver probe, AP follow below sequence - Set the pinctrl in default state - Hold APBs in reset by pulling down reset pin - Enable power to APB by enabling regulator and switches - De-assert (set 'low') 'boot_ret' signal - AP will assert (set 'high') the wake_detect signal, triggering connect/detect event to the SVC - AP waits for wake pulse from SVC SVC: - Power On (power up from PMIC to SVC) - SVC starts booting - SVC will de-assert reset signal to unipro switch - Switch starts booting - SVC confirms switch boot status using SPI (or something) - SVC waits for 300 msec (ES2 known issue) - SVC waits for detect/connect event from AP Stage-2 ======= SVC: - ON connect/detect event, SVC send back wake pulse (cold boot) to AP over wake_detect pin, if SVC boot is completed. AP: - On wake pulse from SVC (for cold boot), AP de-asserts (set high') reset signal to APB 1 and/or 2 - Bridges starts booting - Eventually Unipro linkup occurs Testing: - Build tested against Helium kernel - Due to unavailability of MSM and DB3 platform, only minimal testing has been done. - Code has been modified for validation on Helium + SDB platform. Mostly dts changes for gpio numbers And debug messages to check gpio values - On Helium + SDB platform, with addition of debug messages validated the sequence. TODO list: - Currently _only_ supports power on sequence (cold boot). Both warm and cold boot support. Cold and Warm boot is differentiated based on pulse width of wake_detect signal >=5 msec = Cold boot else Warm boot - No support for Power management So the "power-down", "power-off", "wake_in" and "wake_out" signals are not explored/implemented. - Support for Work thread repetitive wake signal if no response from peer May required for PM support, as we have delays in the sequences - pinctrl states, specially to make sure we enable right pullup or pulldown when we set wake_detect pin to input - Convert gpio list into an array, and associated xxx-gpio-name property Signed-off-by: Vaibhav Hiremath <vaibhav.hiremath@linaro.org> Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
2015-10-21 11:20:20 +00:00
static struct of_device_id arche_platform_of_match[] = {
{ .compatible = "google,arche-platform", }, /* Use PID/VID of SVC device */
greybus: platform: Add platform driver for DB3 AP bridge With DB3, we now have AP as a master as far as AP bridges are concerned. SVC will talk only to AP and AP will control bridges; unlike other module interfaces. So AP supposed to manage/control bridges in all power states including power on reset. During power on reset AP should follow below sequence - Sequence (treated as a Cold Boot) Stage-1 ======= AP: - Power On (Power up from PMIC to AP) - AP start booting Since power to AP bridges are controlled through gpio, power is gated to APB1 & 2 No ref_clk to APB available (under SVC's control) - AP configures USB hub to enable HSIC interface to APB - As part of platform driver probe, AP follow below sequence - Set the pinctrl in default state - Hold APBs in reset by pulling down reset pin - Enable power to APB by enabling regulator and switches - De-assert (set 'low') 'boot_ret' signal - AP will assert (set 'high') the wake_detect signal, triggering connect/detect event to the SVC - AP waits for wake pulse from SVC SVC: - Power On (power up from PMIC to SVC) - SVC starts booting - SVC will de-assert reset signal to unipro switch - Switch starts booting - SVC confirms switch boot status using SPI (or something) - SVC waits for 300 msec (ES2 known issue) - SVC waits for detect/connect event from AP Stage-2 ======= SVC: - ON connect/detect event, SVC send back wake pulse (cold boot) to AP over wake_detect pin, if SVC boot is completed. AP: - On wake pulse from SVC (for cold boot), AP de-asserts (set high') reset signal to APB 1 and/or 2 - Bridges starts booting - Eventually Unipro linkup occurs Testing: - Build tested against Helium kernel - Due to unavailability of MSM and DB3 platform, only minimal testing has been done. - Code has been modified for validation on Helium + SDB platform. Mostly dts changes for gpio numbers And debug messages to check gpio values - On Helium + SDB platform, with addition of debug messages validated the sequence. TODO list: - Currently _only_ supports power on sequence (cold boot). Both warm and cold boot support. Cold and Warm boot is differentiated based on pulse width of wake_detect signal >=5 msec = Cold boot else Warm boot - No support for Power management So the "power-down", "power-off", "wake_in" and "wake_out" signals are not explored/implemented. - Support for Work thread repetitive wake signal if no response from peer May required for PM support, as we have delays in the sequences - pinctrl states, specially to make sure we enable right pullup or pulldown when we set wake_detect pin to input - Convert gpio list into an array, and associated xxx-gpio-name property Signed-off-by: Vaibhav Hiremath <vaibhav.hiremath@linaro.org> Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
2015-10-21 11:20:20 +00:00
{ },
};
static struct of_device_id arche_apb_ctrl_of_match[] = {
{ .compatible = "usbffff,2", },
{ },
};
static struct of_device_id arche_combined_id[] = {
{ .compatible = "google,arche-platform", }, /* Use PID/VID of SVC device */
{ .compatible = "usbffff,2", },
{ },
};
MODULE_DEVICE_TABLE(of, arche_combined_id);
greybus: platform: Add platform driver for DB3 AP bridge With DB3, we now have AP as a master as far as AP bridges are concerned. SVC will talk only to AP and AP will control bridges; unlike other module interfaces. So AP supposed to manage/control bridges in all power states including power on reset. During power on reset AP should follow below sequence - Sequence (treated as a Cold Boot) Stage-1 ======= AP: - Power On (Power up from PMIC to AP) - AP start booting Since power to AP bridges are controlled through gpio, power is gated to APB1 & 2 No ref_clk to APB available (under SVC's control) - AP configures USB hub to enable HSIC interface to APB - As part of platform driver probe, AP follow below sequence - Set the pinctrl in default state - Hold APBs in reset by pulling down reset pin - Enable power to APB by enabling regulator and switches - De-assert (set 'low') 'boot_ret' signal - AP will assert (set 'high') the wake_detect signal, triggering connect/detect event to the SVC - AP waits for wake pulse from SVC SVC: - Power On (power up from PMIC to SVC) - SVC starts booting - SVC will de-assert reset signal to unipro switch - Switch starts booting - SVC confirms switch boot status using SPI (or something) - SVC waits for 300 msec (ES2 known issue) - SVC waits for detect/connect event from AP Stage-2 ======= SVC: - ON connect/detect event, SVC send back wake pulse (cold boot) to AP over wake_detect pin, if SVC boot is completed. AP: - On wake pulse from SVC (for cold boot), AP de-asserts (set high') reset signal to APB 1 and/or 2 - Bridges starts booting - Eventually Unipro linkup occurs Testing: - Build tested against Helium kernel - Due to unavailability of MSM and DB3 platform, only minimal testing has been done. - Code has been modified for validation on Helium + SDB platform. Mostly dts changes for gpio numbers And debug messages to check gpio values - On Helium + SDB platform, with addition of debug messages validated the sequence. TODO list: - Currently _only_ supports power on sequence (cold boot). Both warm and cold boot support. Cold and Warm boot is differentiated based on pulse width of wake_detect signal >=5 msec = Cold boot else Warm boot - No support for Power management So the "power-down", "power-off", "wake_in" and "wake_out" signals are not explored/implemented. - Support for Work thread repetitive wake signal if no response from peer May required for PM support, as we have delays in the sequences - pinctrl states, specially to make sure we enable right pullup or pulldown when we set wake_detect pin to input - Convert gpio list into an array, and associated xxx-gpio-name property Signed-off-by: Vaibhav Hiremath <vaibhav.hiremath@linaro.org> Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
2015-10-21 11:20:20 +00:00
static struct platform_driver arche_platform_device_driver = {
.probe = arche_platform_probe,
.remove = arche_platform_remove,
greybus: platform: Add platform driver for DB3 AP bridge With DB3, we now have AP as a master as far as AP bridges are concerned. SVC will talk only to AP and AP will control bridges; unlike other module interfaces. So AP supposed to manage/control bridges in all power states including power on reset. During power on reset AP should follow below sequence - Sequence (treated as a Cold Boot) Stage-1 ======= AP: - Power On (Power up from PMIC to AP) - AP start booting Since power to AP bridges are controlled through gpio, power is gated to APB1 & 2 No ref_clk to APB available (under SVC's control) - AP configures USB hub to enable HSIC interface to APB - As part of platform driver probe, AP follow below sequence - Set the pinctrl in default state - Hold APBs in reset by pulling down reset pin - Enable power to APB by enabling regulator and switches - De-assert (set 'low') 'boot_ret' signal - AP will assert (set 'high') the wake_detect signal, triggering connect/detect event to the SVC - AP waits for wake pulse from SVC SVC: - Power On (power up from PMIC to SVC) - SVC starts booting - SVC will de-assert reset signal to unipro switch - Switch starts booting - SVC confirms switch boot status using SPI (or something) - SVC waits for 300 msec (ES2 known issue) - SVC waits for detect/connect event from AP Stage-2 ======= SVC: - ON connect/detect event, SVC send back wake pulse (cold boot) to AP over wake_detect pin, if SVC boot is completed. AP: - On wake pulse from SVC (for cold boot), AP de-asserts (set high') reset signal to APB 1 and/or 2 - Bridges starts booting - Eventually Unipro linkup occurs Testing: - Build tested against Helium kernel - Due to unavailability of MSM and DB3 platform, only minimal testing has been done. - Code has been modified for validation on Helium + SDB platform. Mostly dts changes for gpio numbers And debug messages to check gpio values - On Helium + SDB platform, with addition of debug messages validated the sequence. TODO list: - Currently _only_ supports power on sequence (cold boot). Both warm and cold boot support. Cold and Warm boot is differentiated based on pulse width of wake_detect signal >=5 msec = Cold boot else Warm boot - No support for Power management So the "power-down", "power-off", "wake_in" and "wake_out" signals are not explored/implemented. - Support for Work thread repetitive wake signal if no response from peer May required for PM support, as we have delays in the sequences - pinctrl states, specially to make sure we enable right pullup or pulldown when we set wake_detect pin to input - Convert gpio list into an array, and associated xxx-gpio-name property Signed-off-by: Vaibhav Hiremath <vaibhav.hiremath@linaro.org> Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
2015-10-21 11:20:20 +00:00
.driver = {
.name = "arche-platform-ctrl",
.pm = &arche_platform_pm_ops,
.of_match_table = arche_platform_of_match,
greybus: platform: Add platform driver for DB3 AP bridge With DB3, we now have AP as a master as far as AP bridges are concerned. SVC will talk only to AP and AP will control bridges; unlike other module interfaces. So AP supposed to manage/control bridges in all power states including power on reset. During power on reset AP should follow below sequence - Sequence (treated as a Cold Boot) Stage-1 ======= AP: - Power On (Power up from PMIC to AP) - AP start booting Since power to AP bridges are controlled through gpio, power is gated to APB1 & 2 No ref_clk to APB available (under SVC's control) - AP configures USB hub to enable HSIC interface to APB - As part of platform driver probe, AP follow below sequence - Set the pinctrl in default state - Hold APBs in reset by pulling down reset pin - Enable power to APB by enabling regulator and switches - De-assert (set 'low') 'boot_ret' signal - AP will assert (set 'high') the wake_detect signal, triggering connect/detect event to the SVC - AP waits for wake pulse from SVC SVC: - Power On (power up from PMIC to SVC) - SVC starts booting - SVC will de-assert reset signal to unipro switch - Switch starts booting - SVC confirms switch boot status using SPI (or something) - SVC waits for 300 msec (ES2 known issue) - SVC waits for detect/connect event from AP Stage-2 ======= SVC: - ON connect/detect event, SVC send back wake pulse (cold boot) to AP over wake_detect pin, if SVC boot is completed. AP: - On wake pulse from SVC (for cold boot), AP de-asserts (set high') reset signal to APB 1 and/or 2 - Bridges starts booting - Eventually Unipro linkup occurs Testing: - Build tested against Helium kernel - Due to unavailability of MSM and DB3 platform, only minimal testing has been done. - Code has been modified for validation on Helium + SDB platform. Mostly dts changes for gpio numbers And debug messages to check gpio values - On Helium + SDB platform, with addition of debug messages validated the sequence. TODO list: - Currently _only_ supports power on sequence (cold boot). Both warm and cold boot support. Cold and Warm boot is differentiated based on pulse width of wake_detect signal >=5 msec = Cold boot else Warm boot - No support for Power management So the "power-down", "power-off", "wake_in" and "wake_out" signals are not explored/implemented. - Support for Work thread repetitive wake signal if no response from peer May required for PM support, as we have delays in the sequences - pinctrl states, specially to make sure we enable right pullup or pulldown when we set wake_detect pin to input - Convert gpio list into an array, and associated xxx-gpio-name property Signed-off-by: Vaibhav Hiremath <vaibhav.hiremath@linaro.org> Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
2015-10-21 11:20:20 +00:00
}
};
static struct platform_driver arche_apb_ctrl_device_driver = {
.probe = arche_apb_ctrl_probe,
.remove = arche_apb_ctrl_remove,
.driver = {
.name = "arche-apb-ctrl",
.pm = &arche_apb_ctrl_pm_ops,
.of_match_table = arche_apb_ctrl_of_match,
}
};
static int __init arche_init(void)
{
int retval;
retval = platform_driver_register(&arche_platform_device_driver);
if (retval)
return retval;
retval = platform_driver_register(&arche_apb_ctrl_device_driver);
if (retval)
platform_driver_unregister(&arche_platform_device_driver);
return retval;
}
module_init(arche_init);
static void __exit arche_exit(void)
{
platform_driver_unregister(&arche_apb_ctrl_device_driver);
platform_driver_unregister(&arche_platform_device_driver);
}
module_exit(arche_exit);
greybus: platform: Add platform driver for DB3 AP bridge With DB3, we now have AP as a master as far as AP bridges are concerned. SVC will talk only to AP and AP will control bridges; unlike other module interfaces. So AP supposed to manage/control bridges in all power states including power on reset. During power on reset AP should follow below sequence - Sequence (treated as a Cold Boot) Stage-1 ======= AP: - Power On (Power up from PMIC to AP) - AP start booting Since power to AP bridges are controlled through gpio, power is gated to APB1 & 2 No ref_clk to APB available (under SVC's control) - AP configures USB hub to enable HSIC interface to APB - As part of platform driver probe, AP follow below sequence - Set the pinctrl in default state - Hold APBs in reset by pulling down reset pin - Enable power to APB by enabling regulator and switches - De-assert (set 'low') 'boot_ret' signal - AP will assert (set 'high') the wake_detect signal, triggering connect/detect event to the SVC - AP waits for wake pulse from SVC SVC: - Power On (power up from PMIC to SVC) - SVC starts booting - SVC will de-assert reset signal to unipro switch - Switch starts booting - SVC confirms switch boot status using SPI (or something) - SVC waits for 300 msec (ES2 known issue) - SVC waits for detect/connect event from AP Stage-2 ======= SVC: - ON connect/detect event, SVC send back wake pulse (cold boot) to AP over wake_detect pin, if SVC boot is completed. AP: - On wake pulse from SVC (for cold boot), AP de-asserts (set high') reset signal to APB 1 and/or 2 - Bridges starts booting - Eventually Unipro linkup occurs Testing: - Build tested against Helium kernel - Due to unavailability of MSM and DB3 platform, only minimal testing has been done. - Code has been modified for validation on Helium + SDB platform. Mostly dts changes for gpio numbers And debug messages to check gpio values - On Helium + SDB platform, with addition of debug messages validated the sequence. TODO list: - Currently _only_ supports power on sequence (cold boot). Both warm and cold boot support. Cold and Warm boot is differentiated based on pulse width of wake_detect signal >=5 msec = Cold boot else Warm boot - No support for Power management So the "power-down", "power-off", "wake_in" and "wake_out" signals are not explored/implemented. - Support for Work thread repetitive wake signal if no response from peer May required for PM support, as we have delays in the sequences - pinctrl states, specially to make sure we enable right pullup or pulldown when we set wake_detect pin to input - Convert gpio list into an array, and associated xxx-gpio-name property Signed-off-by: Vaibhav Hiremath <vaibhav.hiremath@linaro.org> Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
2015-10-21 11:20:20 +00:00
MODULE_LICENSE("GPL");
MODULE_AUTHOR("Vaibhav Hiremath <vaibhav.hiremath@linaro.org>");
MODULE_DESCRIPTION("Arche Platform Driver");