2017-11-07 13:58:41 +00:00
|
|
|
// SPDX-License-Identifier: GPL-2.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
|
|
|
/*
|
2015-12-16 10:59:18 +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.
|
|
|
|
*/
|
|
|
|
|
2015-12-16 10:59:17 +00:00
|
|
|
#include <linux/clk.h>
|
2016-01-11 12:11:24 +00:00
|
|
|
#include <linux/delay.h>
|
2019-01-14 14:58:59 +00:00
|
|
|
#include <linux/gpio/consumer.h>
|
2016-01-11 05:59:17 +00:00
|
|
|
#include <linux/init.h>
|
|
|
|
#include <linux/module.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>
|
2016-01-11 05:59:17 +00:00
|
|
|
#include <linux/platform_device.h>
|
|
|
|
#include <linux/pm.h>
|
2016-02-24 23:07:36 +00:00
|
|
|
#include <linux/interrupt.h>
|
|
|
|
#include <linux/irq.h>
|
2016-04-15 19:45:15 +00:00
|
|
|
#include <linux/suspend.h>
|
2016-02-24 23:07:36 +00:00
|
|
|
#include <linux/time.h>
|
2019-08-25 05:54:27 +00:00
|
|
|
#include <linux/greybus.h>
|
2015-12-30 21:38:33 +00:00
|
|
|
#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
|
|
|
|
2017-05-16 08:01:39 +00:00
|
|
|
#if IS_ENABLED(CONFIG_USB_HSIC_USB3613)
|
greybus: arche-platform: Control usb3613 from arche-platform
USB3613 hub driver exports control function, which allows caller
to switch the mode of operation of hub device.
As we know that, we have dependency between HUB3613 and APB's where,
HUB supposed to enter into HUB only after APB's brought out of reset.
Until now, we had all userspace driver sequences to control this,
but now since we are moving all resource management strictly to the
driver, it makes sense (even though it looks hacky) to enable control
of hub3613 from arche-platform driver.
Note that, there is another discussion where, the hub.connect IO pin may
get interfaced with MSM gpio, at that time, we can get rid of this hack
and replace it with gpio control.
Testing Done: Tested on EVT1.2 and DB3.5 platform.
Signed-off-by: Vaibhav Hiremath <vaibhav.hiremath@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
2016-02-12 20:34:20 +00:00
|
|
|
#include <linux/usb/usb3613.h>
|
2017-05-16 08:01:39 +00:00
|
|
|
#else
|
|
|
|
static inline int usb3613_hub_mode_ctrl(bool unused)
|
|
|
|
{
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
#endif
|
greybus: arche-platform: Control usb3613 from arche-platform
USB3613 hub driver exports control function, which allows caller
to switch the mode of operation of hub device.
As we know that, we have dependency between HUB3613 and APB's where,
HUB supposed to enter into HUB only after APB's brought out of reset.
Until now, we had all userspace driver sequences to control this,
but now since we are moving all resource management strictly to the
driver, it makes sense (even though it looks hacky) to enable control
of hub3613 from arche-platform driver.
Note that, there is another discussion where, the hub.connect IO pin may
get interfaced with MSM gpio, at that time, we can get rid of this hack
and replace it with gpio control.
Testing Done: Tested on EVT1.2 and DB3.5 platform.
Signed-off-by: Vaibhav Hiremath <vaibhav.hiremath@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
2016-02-12 20:34:20 +00:00
|
|
|
|
2016-02-24 23:07:36 +00:00
|
|
|
#define WD_COLDBOOT_PULSE_WIDTH_MS 30
|
|
|
|
|
2016-02-24 23:07:35 +00:00
|
|
|
enum svc_wakedetect_state {
|
|
|
|
WD_STATE_IDLE, /* Default state = pulled high/low */
|
|
|
|
WD_STATE_BOOT_INIT, /* WD = falling edge (low) */
|
|
|
|
WD_STATE_COLDBOOT_TRIG, /* WD = rising edge (high), > 30msec */
|
|
|
|
WD_STATE_STANDBYBOOT_TRIG, /* As of now not used ?? */
|
|
|
|
WD_STATE_COLDBOOT_START, /* Cold boot process started */
|
|
|
|
WD_STATE_STANDBYBOOT_START, /* Not used */
|
|
|
|
};
|
|
|
|
|
2015-12-16 10:59:18 +00:00
|
|
|
struct arche_platform_drvdata {
|
2015-12-16 10:59:17 +00:00
|
|
|
/* Control GPIO signals to and from AP <=> SVC */
|
2019-01-14 14:58:59 +00:00
|
|
|
struct gpio_desc *svc_reset;
|
2015-12-16 10:59:17 +00:00
|
|
|
bool is_reset_act_hi;
|
2019-01-14 14:58:59 +00:00
|
|
|
struct gpio_desc *svc_sysboot;
|
|
|
|
struct gpio_desc *wake_detect; /* 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
|
|
|
|
2016-02-12 20:34:05 +00:00
|
|
|
enum arche_platform_state state;
|
|
|
|
|
2019-01-14 14:58:59 +00:00
|
|
|
struct gpio_desc *svc_refclk_req;
|
2015-12-16 10:59:17 +00:00
|
|
|
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;
|
|
|
|
|
2015-12-16 10:59:17 +00:00
|
|
|
int num_apbs;
|
2016-01-11 12:11:24 +00:00
|
|
|
|
2016-02-24 23:07:35 +00:00
|
|
|
enum svc_wakedetect_state wake_detect_state;
|
2016-02-24 23:07:36 +00:00
|
|
|
int wake_detect_irq;
|
2016-05-05 14:34:58 +00:00
|
|
|
spinlock_t wake_lock; /* Protect wake_detect_state */
|
|
|
|
struct mutex platform_state_mutex; /* Protect state */
|
2016-02-24 23:07:36 +00:00
|
|
|
unsigned long wake_detect_start;
|
2016-04-15 19:45:15 +00:00
|
|
|
struct notifier_block pm_notifier;
|
2016-02-24 23:07:35 +00:00
|
|
|
|
2016-01-11 12:11:24 +00:00
|
|
|
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
|
|
|
};
|
|
|
|
|
2016-06-05 13:03:26 +00:00
|
|
|
/* Requires calling context to hold arche_pdata->platform_state_mutex */
|
2016-05-05 14:34:59 +00:00
|
|
|
static void arche_platform_set_state(struct arche_platform_drvdata *arche_pdata,
|
|
|
|
enum arche_platform_state state)
|
|
|
|
{
|
|
|
|
arche_pdata->state = state;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* Requires arche_pdata->wake_lock is held by calling context */
|
2021-04-01 09:07:54 +00:00
|
|
|
static void arche_platform_set_wake_detect_state(struct arche_platform_drvdata *arche_pdata,
|
|
|
|
enum svc_wakedetect_state state)
|
2016-05-05 14:34:59 +00:00
|
|
|
{
|
|
|
|
arche_pdata->wake_detect_state = state;
|
|
|
|
}
|
|
|
|
|
2019-01-14 14:58:59 +00:00
|
|
|
static inline void svc_reset_onoff(struct gpio_desc *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
|
|
|
{
|
2019-01-14 14:58:59 +00:00
|
|
|
gpiod_set_raw_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
|
|
|
}
|
|
|
|
|
2016-02-24 23:07:36 +00:00
|
|
|
static int apb_cold_boot(struct device *dev, void *data)
|
|
|
|
{
|
|
|
|
int ret;
|
|
|
|
|
|
|
|
ret = apb_ctrl_coldboot(dev);
|
|
|
|
if (ret)
|
|
|
|
dev_warn(dev, "failed to coldboot\n");
|
|
|
|
|
|
|
|
/*Child nodes are independent, so do not exit coldboot operation */
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
greybus: arche-platform: Fix boot, poweroff and fw_flashing seq with APBs
Now SVC driver has an access to APBs operational functions
(coldboot, standby_boot, fw_flashing and poweroff), SVC driver
can control APB's as per below rules,
- If SVC goes down (poweroff state), it will also power off APBs
and vice a versa for all operational states.
- On boot, SVC will probe/populate APB device, but will not coldboot
it. APBs will coldboot only after handshaking with SVC over
wake/detect line.
Note that, both APBs share same wake/detect line.
So from user/developer perspective, it is highly recommended that
they should use arche-platform interfaces, instead of individual
apb interface,
# echo [off/active/standby/fw_flashing] > /sys/devices/arche_platform.*/state
Note: 'standby' mode is not supported as of now.
Testing Done: Testd on EVT1.2 and DB3.5 platform.
Signed-off-by: Vaibhav Hiremath <vaibhav.hiremath@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
2016-02-12 20:34:17 +00:00
|
|
|
static int apb_poweroff(struct device *dev, void *data)
|
|
|
|
{
|
|
|
|
apb_ctrl_poweroff(dev);
|
|
|
|
|
2016-02-25 11:15:45 +00:00
|
|
|
/* Enable HUB3613 into HUB mode. */
|
|
|
|
if (usb3613_hub_mode_ctrl(false))
|
|
|
|
dev_warn(dev, "failed to control hub device\n");
|
|
|
|
|
greybus: arche-platform: Fix boot, poweroff and fw_flashing seq with APBs
Now SVC driver has an access to APBs operational functions
(coldboot, standby_boot, fw_flashing and poweroff), SVC driver
can control APB's as per below rules,
- If SVC goes down (poweroff state), it will also power off APBs
and vice a versa for all operational states.
- On boot, SVC will probe/populate APB device, but will not coldboot
it. APBs will coldboot only after handshaking with SVC over
wake/detect line.
Note that, both APBs share same wake/detect line.
So from user/developer perspective, it is highly recommended that
they should use arche-platform interfaces, instead of individual
apb interface,
# echo [off/active/standby/fw_flashing] > /sys/devices/arche_platform.*/state
Note: 'standby' mode is not supported as of now.
Testing Done: Testd on EVT1.2 and DB3.5 platform.
Signed-off-by: Vaibhav Hiremath <vaibhav.hiremath@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
2016-02-12 20:34:17 +00:00
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2016-05-17 17:09:47 +00:00
|
|
|
static void arche_platform_wd_irq_en(struct arche_platform_drvdata *arche_pdata)
|
2016-02-24 23:07:37 +00:00
|
|
|
{
|
|
|
|
/* Enable interrupt here, to read event back from SVC */
|
|
|
|
enable_irq(arche_pdata->wake_detect_irq);
|
|
|
|
}
|
|
|
|
|
2016-02-24 23:07:36 +00:00
|
|
|
static irqreturn_t arche_platform_wd_irq_thread(int irq, void *devid)
|
|
|
|
{
|
|
|
|
struct arche_platform_drvdata *arche_pdata = devid;
|
|
|
|
unsigned long flags;
|
|
|
|
|
2016-05-05 14:34:57 +00:00
|
|
|
spin_lock_irqsave(&arche_pdata->wake_lock, flags);
|
2016-02-24 23:07:36 +00:00
|
|
|
if (arche_pdata->wake_detect_state != WD_STATE_COLDBOOT_TRIG) {
|
|
|
|
/* Something is wrong */
|
2016-05-05 14:34:57 +00:00
|
|
|
spin_unlock_irqrestore(&arche_pdata->wake_lock, flags);
|
2016-02-24 23:07:36 +00:00
|
|
|
return IRQ_HANDLED;
|
|
|
|
}
|
|
|
|
|
2016-05-05 14:34:59 +00:00
|
|
|
arche_platform_set_wake_detect_state(arche_pdata,
|
|
|
|
WD_STATE_COLDBOOT_START);
|
2016-05-05 14:34:57 +00:00
|
|
|
spin_unlock_irqrestore(&arche_pdata->wake_lock, flags);
|
2016-02-24 23:07:36 +00:00
|
|
|
|
2016-02-25 11:15:44 +00:00
|
|
|
/* It should complete power cycle, so first make sure it is poweroff */
|
|
|
|
device_for_each_child(arche_pdata->dev, NULL, apb_poweroff);
|
2016-02-25 11:15:45 +00:00
|
|
|
|
2016-02-24 23:07:36 +00:00
|
|
|
/* Bring APB out of reset: cold boot sequence */
|
|
|
|
device_for_each_child(arche_pdata->dev, NULL, apb_cold_boot);
|
|
|
|
|
2016-04-12 11:48:47 +00:00
|
|
|
/* Enable HUB3613 into HUB mode. */
|
|
|
|
if (usb3613_hub_mode_ctrl(true))
|
|
|
|
dev_warn(arche_pdata->dev, "failed to control hub device\n");
|
|
|
|
|
2016-05-05 14:34:57 +00:00
|
|
|
spin_lock_irqsave(&arche_pdata->wake_lock, flags);
|
2016-05-05 14:34:59 +00:00
|
|
|
arche_platform_set_wake_detect_state(arche_pdata, WD_STATE_IDLE);
|
2016-05-05 14:34:57 +00:00
|
|
|
spin_unlock_irqrestore(&arche_pdata->wake_lock, flags);
|
2016-02-24 23:07:36 +00:00
|
|
|
|
|
|
|
return IRQ_HANDLED;
|
|
|
|
}
|
|
|
|
|
|
|
|
static irqreturn_t arche_platform_wd_irq(int irq, void *devid)
|
|
|
|
{
|
|
|
|
struct arche_platform_drvdata *arche_pdata = devid;
|
|
|
|
unsigned long flags;
|
|
|
|
|
2016-05-05 14:34:57 +00:00
|
|
|
spin_lock_irqsave(&arche_pdata->wake_lock, flags);
|
2016-02-24 23:07:36 +00:00
|
|
|
|
2019-01-14 14:58:59 +00:00
|
|
|
if (gpiod_get_value(arche_pdata->wake_detect)) {
|
2016-02-24 23:07:36 +00:00
|
|
|
/* wake/detect rising */
|
|
|
|
|
|
|
|
/*
|
|
|
|
* If wake/detect line goes high after low, within less than
|
|
|
|
* 30msec, then standby boot sequence is initiated, which is not
|
|
|
|
* supported/implemented as of now. So ignore it.
|
|
|
|
*/
|
|
|
|
if (arche_pdata->wake_detect_state == WD_STATE_BOOT_INIT) {
|
|
|
|
if (time_before(jiffies,
|
|
|
|
arche_pdata->wake_detect_start +
|
|
|
|
msecs_to_jiffies(WD_COLDBOOT_PULSE_WIDTH_MS))) {
|
2016-05-05 14:34:59 +00:00
|
|
|
arche_platform_set_wake_detect_state(arche_pdata,
|
|
|
|
WD_STATE_IDLE);
|
2016-02-24 23:07:36 +00:00
|
|
|
} else {
|
2017-07-11 03:14:44 +00:00
|
|
|
/*
|
|
|
|
* Check we are not in middle of irq thread
|
|
|
|
* already
|
|
|
|
*/
|
2016-02-24 23:07:36 +00:00
|
|
|
if (arche_pdata->wake_detect_state !=
|
|
|
|
WD_STATE_COLDBOOT_START) {
|
2016-05-05 14:34:59 +00:00
|
|
|
arche_platform_set_wake_detect_state(arche_pdata,
|
|
|
|
WD_STATE_COLDBOOT_TRIG);
|
2021-04-01 09:07:54 +00:00
|
|
|
spin_unlock_irqrestore(&arche_pdata->wake_lock,
|
|
|
|
flags);
|
2016-02-24 23:07:36 +00:00
|
|
|
return IRQ_WAKE_THREAD;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
} else {
|
|
|
|
/* wake/detect falling */
|
|
|
|
if (arche_pdata->wake_detect_state == WD_STATE_IDLE) {
|
|
|
|
arche_pdata->wake_detect_start = jiffies;
|
|
|
|
/*
|
2017-08-21 22:11:37 +00:00
|
|
|
* In the beginning, when wake/detect goes low
|
2017-02-09 16:30:11 +00:00
|
|
|
* (first time), we assume it is meant for coldboot
|
|
|
|
* and set the flag. If wake/detect line stays low
|
|
|
|
* beyond 30msec, then it is coldboot else fallback
|
|
|
|
* to standby boot.
|
2016-02-24 23:07:36 +00:00
|
|
|
*/
|
2016-05-05 14:34:59 +00:00
|
|
|
arche_platform_set_wake_detect_state(arche_pdata,
|
|
|
|
WD_STATE_BOOT_INIT);
|
2016-02-24 23:07:36 +00:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2016-05-05 14:34:57 +00:00
|
|
|
spin_unlock_irqrestore(&arche_pdata->wake_lock, flags);
|
2016-02-24 23:07:36 +00:00
|
|
|
|
|
|
|
return IRQ_HANDLED;
|
|
|
|
}
|
|
|
|
|
2016-05-05 14:34:58 +00:00
|
|
|
/*
|
|
|
|
* Requires arche_pdata->platform_state_mutex to be held
|
|
|
|
*/
|
2017-02-09 16:30:11 +00:00
|
|
|
static int
|
|
|
|
arche_platform_coldboot_seq(struct arche_platform_drvdata *arche_pdata)
|
2016-02-12 20:34:03 +00:00
|
|
|
{
|
|
|
|
int ret;
|
|
|
|
|
2016-02-22 11:57:24 +00:00
|
|
|
if (arche_pdata->state == ARCHE_PLATFORM_STATE_ACTIVE)
|
|
|
|
return 0;
|
|
|
|
|
2016-02-12 20:34:03 +00:00
|
|
|
dev_info(arche_pdata->dev, "Booting from cold boot state\n");
|
|
|
|
|
2019-01-14 14:58:59 +00:00
|
|
|
svc_reset_onoff(arche_pdata->svc_reset, arche_pdata->is_reset_act_hi);
|
2016-02-12 20:34:03 +00:00
|
|
|
|
2019-01-14 14:58:59 +00:00
|
|
|
gpiod_set_value(arche_pdata->svc_sysboot, 0);
|
2016-02-12 20:34:03 +00:00
|
|
|
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",
|
2017-12-17 17:56:27 +00:00
|
|
|
ret);
|
2016-02-12 20:34:03 +00:00
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* bring SVC out of reset */
|
2019-01-14 14:58:59 +00:00
|
|
|
svc_reset_onoff(arche_pdata->svc_reset, !arche_pdata->is_reset_act_hi);
|
2016-02-12 20:34:03 +00:00
|
|
|
|
2016-05-05 14:34:59 +00:00
|
|
|
arche_platform_set_state(arche_pdata, ARCHE_PLATFORM_STATE_ACTIVE);
|
2016-02-12 20:34:05 +00:00
|
|
|
|
2016-02-12 20:34:03 +00:00
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2016-05-05 14:34:58 +00:00
|
|
|
/*
|
|
|
|
* Requires arche_pdata->platform_state_mutex to be held
|
|
|
|
*/
|
2017-02-09 16:30:11 +00:00
|
|
|
static int
|
|
|
|
arche_platform_fw_flashing_seq(struct arche_platform_drvdata *arche_pdata)
|
2016-02-12 20:34:08 +00:00
|
|
|
{
|
greybus: arche-platform: Enable SVC clock during FW_FLASHING state
The issue is, as part of kernel-only build we started seeing
failures in SVC FW flashing. It was reproducible easily in kernel-only
build, but never observed on Android build.
During debugging, there were couple of observations,
1. If SVC clock enabled and disables (which is REFCLK_MAIN), then SVC FW
flashing works.
2. If we do not switch SVC to HSE (external clock source) it works.
Recently, SVC code has been updated to switch HSE clock, so removing
it (remove/skip rcc_switch_ara_pll() fn) would use internal clock only.
As per STM32 spec, for flashing through USART we do not need
to enable HSE, but the above observation contradicts with it.
There is still something missing in terms of understanding of how STM32
device functions as far as Flashing is concerned. There is something
hidden in HW, which probably still need to identify.
So as a interim solution we will enable clock for FW_FLASHING state,
which seems to be fixing the issue here.
Testing Done: Tested on EVT1.5 with arche6.0 and kernel-only build.
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-05-24 13:02:04 +00:00
|
|
|
int ret;
|
|
|
|
|
2016-02-22 11:57:24 +00:00
|
|
|
if (arche_pdata->state == ARCHE_PLATFORM_STATE_FW_FLASHING)
|
2016-05-24 13:02:02 +00:00
|
|
|
return 0;
|
2016-02-22 11:57:24 +00:00
|
|
|
|
2016-02-12 20:34:08 +00:00
|
|
|
dev_info(arche_pdata->dev, "Switching to FW flashing state\n");
|
|
|
|
|
2019-01-14 14:58:59 +00:00
|
|
|
svc_reset_onoff(arche_pdata->svc_reset, arche_pdata->is_reset_act_hi);
|
2016-02-12 20:34:08 +00:00
|
|
|
|
2019-01-14 14:58:59 +00:00
|
|
|
gpiod_set_value(arche_pdata->svc_sysboot, 1);
|
2016-02-12 20:34:08 +00:00
|
|
|
|
|
|
|
usleep_range(100, 200);
|
greybus: arche-platform: Enable SVC clock during FW_FLASHING state
The issue is, as part of kernel-only build we started seeing
failures in SVC FW flashing. It was reproducible easily in kernel-only
build, but never observed on Android build.
During debugging, there were couple of observations,
1. If SVC clock enabled and disables (which is REFCLK_MAIN), then SVC FW
flashing works.
2. If we do not switch SVC to HSE (external clock source) it works.
Recently, SVC code has been updated to switch HSE clock, so removing
it (remove/skip rcc_switch_ara_pll() fn) would use internal clock only.
As per STM32 spec, for flashing through USART we do not need
to enable HSE, but the above observation contradicts with it.
There is still something missing in terms of understanding of how STM32
device functions as far as Flashing is concerned. There is something
hidden in HW, which probably still need to identify.
So as a interim solution we will enable clock for FW_FLASHING state,
which seems to be fixing the issue here.
Testing Done: Tested on EVT1.5 with arche6.0 and kernel-only build.
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-05-24 13:02:04 +00:00
|
|
|
|
|
|
|
ret = clk_prepare_enable(arche_pdata->svc_ref_clk);
|
|
|
|
if (ret) {
|
|
|
|
dev_err(arche_pdata->dev, "failed to enable svc_ref_clk: %d\n",
|
2017-12-17 17:56:27 +00:00
|
|
|
ret);
|
greybus: arche-platform: Enable SVC clock during FW_FLASHING state
The issue is, as part of kernel-only build we started seeing
failures in SVC FW flashing. It was reproducible easily in kernel-only
build, but never observed on Android build.
During debugging, there were couple of observations,
1. If SVC clock enabled and disables (which is REFCLK_MAIN), then SVC FW
flashing works.
2. If we do not switch SVC to HSE (external clock source) it works.
Recently, SVC code has been updated to switch HSE clock, so removing
it (remove/skip rcc_switch_ara_pll() fn) would use internal clock only.
As per STM32 spec, for flashing through USART we do not need
to enable HSE, but the above observation contradicts with it.
There is still something missing in terms of understanding of how STM32
device functions as far as Flashing is concerned. There is something
hidden in HW, which probably still need to identify.
So as a interim solution we will enable clock for FW_FLASHING state,
which seems to be fixing the issue here.
Testing Done: Tested on EVT1.5 with arche6.0 and kernel-only build.
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-05-24 13:02:04 +00:00
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
|
2019-01-14 14:58:59 +00:00
|
|
|
svc_reset_onoff(arche_pdata->svc_reset, !arche_pdata->is_reset_act_hi);
|
2016-02-12 20:34:08 +00:00
|
|
|
|
2016-05-05 14:34:59 +00:00
|
|
|
arche_platform_set_state(arche_pdata, ARCHE_PLATFORM_STATE_FW_FLASHING);
|
2016-02-12 20:34:08 +00:00
|
|
|
|
2016-05-24 13:02:02 +00:00
|
|
|
return 0;
|
2016-02-12 20:34:08 +00:00
|
|
|
}
|
|
|
|
|
2016-05-05 14:34:58 +00:00
|
|
|
/*
|
|
|
|
* Requires arche_pdata->platform_state_mutex to be held
|
|
|
|
*/
|
2017-02-09 16:30:11 +00:00
|
|
|
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
|
|
|
{
|
2016-02-24 23:07:36 +00:00
|
|
|
unsigned long flags;
|
|
|
|
|
2016-02-22 11:57:24 +00:00
|
|
|
if (arche_pdata->state == ARCHE_PLATFORM_STATE_OFF)
|
|
|
|
return;
|
|
|
|
|
2016-02-22 11:57:25 +00:00
|
|
|
/* If in fw_flashing mode, then no need to repeate things again */
|
|
|
|
if (arche_pdata->state != ARCHE_PLATFORM_STATE_FW_FLASHING) {
|
2016-02-24 23:07:39 +00:00
|
|
|
disable_irq(arche_pdata->wake_detect_irq);
|
2016-05-17 17:09:46 +00:00
|
|
|
|
2016-05-05 14:34:57 +00:00
|
|
|
spin_lock_irqsave(&arche_pdata->wake_lock, flags);
|
2016-05-05 14:34:59 +00:00
|
|
|
arche_platform_set_wake_detect_state(arche_pdata,
|
|
|
|
WD_STATE_IDLE);
|
2016-05-05 14:34:57 +00:00
|
|
|
spin_unlock_irqrestore(&arche_pdata->wake_lock, flags);
|
2016-02-22 11:57:25 +00:00
|
|
|
}
|
2016-02-12 20:34:06 +00:00
|
|
|
|
greybus: arche-platform: Enable SVC clock during FW_FLASHING state
The issue is, as part of kernel-only build we started seeing
failures in SVC FW flashing. It was reproducible easily in kernel-only
build, but never observed on Android build.
During debugging, there were couple of observations,
1. If SVC clock enabled and disables (which is REFCLK_MAIN), then SVC FW
flashing works.
2. If we do not switch SVC to HSE (external clock source) it works.
Recently, SVC code has been updated to switch HSE clock, so removing
it (remove/skip rcc_switch_ara_pll() fn) would use internal clock only.
As per STM32 spec, for flashing through USART we do not need
to enable HSE, but the above observation contradicts with it.
There is still something missing in terms of understanding of how STM32
device functions as far as Flashing is concerned. There is something
hidden in HW, which probably still need to identify.
So as a interim solution we will enable clock for FW_FLASHING state,
which seems to be fixing the issue here.
Testing Done: Tested on EVT1.5 with arche6.0 and kernel-only build.
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-05-24 13:02:04 +00:00
|
|
|
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 */
|
2019-01-14 14:58:59 +00:00
|
|
|
svc_reset_onoff(arche_pdata->svc_reset, arche_pdata->is_reset_act_hi);
|
2016-02-12 20:34:05 +00:00
|
|
|
|
2016-05-05 14:34:59 +00:00
|
|
|
arche_platform_set_state(arche_pdata, 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
|
|
|
}
|
|
|
|
|
2016-02-12 20:34:07 +00:00
|
|
|
static ssize_t state_store(struct device *dev,
|
2017-12-17 17:56:27 +00:00
|
|
|
struct device_attribute *attr,
|
|
|
|
const char *buf, size_t count)
|
2016-02-12 20:34:07 +00:00
|
|
|
{
|
2018-04-19 14:06:17 +00:00
|
|
|
struct arche_platform_drvdata *arche_pdata = dev_get_drvdata(dev);
|
2016-02-12 20:34:07 +00:00
|
|
|
int ret = 0;
|
|
|
|
|
2016-05-05 14:34:58 +00:00
|
|
|
mutex_lock(&arche_pdata->platform_state_mutex);
|
|
|
|
|
2016-02-12 20:34:07 +00:00
|
|
|
if (sysfs_streq(buf, "off")) {
|
|
|
|
if (arche_pdata->state == ARCHE_PLATFORM_STATE_OFF)
|
2016-05-05 14:34:58 +00:00
|
|
|
goto exit;
|
2016-02-12 20:34:07 +00:00
|
|
|
|
greybus: arche-platform: Fix boot, poweroff and fw_flashing seq with APBs
Now SVC driver has an access to APBs operational functions
(coldboot, standby_boot, fw_flashing and poweroff), SVC driver
can control APB's as per below rules,
- If SVC goes down (poweroff state), it will also power off APBs
and vice a versa for all operational states.
- On boot, SVC will probe/populate APB device, but will not coldboot
it. APBs will coldboot only after handshaking with SVC over
wake/detect line.
Note that, both APBs share same wake/detect line.
So from user/developer perspective, it is highly recommended that
they should use arche-platform interfaces, instead of individual
apb interface,
# echo [off/active/standby/fw_flashing] > /sys/devices/arche_platform.*/state
Note: 'standby' mode is not supported as of now.
Testing Done: Testd on EVT1.2 and DB3.5 platform.
Signed-off-by: Vaibhav Hiremath <vaibhav.hiremath@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
2016-02-12 20:34:17 +00:00
|
|
|
/* If SVC goes down, bring down APB's as well */
|
|
|
|
device_for_each_child(arche_pdata->dev, NULL, apb_poweroff);
|
|
|
|
|
2016-02-12 20:34:07 +00:00
|
|
|
arche_platform_poweroff_seq(arche_pdata);
|
greybus: arche-platform: Control usb3613 from arche-platform
USB3613 hub driver exports control function, which allows caller
to switch the mode of operation of hub device.
As we know that, we have dependency between HUB3613 and APB's where,
HUB supposed to enter into HUB only after APB's brought out of reset.
Until now, we had all userspace driver sequences to control this,
but now since we are moving all resource management strictly to the
driver, it makes sense (even though it looks hacky) to enable control
of hub3613 from arche-platform driver.
Note that, there is another discussion where, the hub.connect IO pin may
get interfaced with MSM gpio, at that time, we can get rid of this hack
and replace it with gpio control.
Testing Done: Tested on EVT1.2 and DB3.5 platform.
Signed-off-by: Vaibhav Hiremath <vaibhav.hiremath@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
2016-02-12 20:34:20 +00:00
|
|
|
|
2016-02-12 20:34:07 +00:00
|
|
|
} else if (sysfs_streq(buf, "active")) {
|
|
|
|
if (arche_pdata->state == ARCHE_PLATFORM_STATE_ACTIVE)
|
2016-05-05 14:34:58 +00:00
|
|
|
goto exit;
|
2016-02-12 20:34:07 +00:00
|
|
|
|
2016-05-24 13:02:03 +00:00
|
|
|
/* First we want to make sure we power off everything
|
2016-10-12 17:16:34 +00:00
|
|
|
* and then activate back again
|
|
|
|
*/
|
2016-05-24 13:02:03 +00:00
|
|
|
device_for_each_child(arche_pdata->dev, NULL, apb_poweroff);
|
|
|
|
arche_platform_poweroff_seq(arche_pdata);
|
|
|
|
|
2016-05-17 17:09:47 +00:00
|
|
|
arche_platform_wd_irq_en(arche_pdata);
|
2016-02-12 20:34:07 +00:00
|
|
|
ret = arche_platform_coldboot_seq(arche_pdata);
|
2016-05-24 13:02:03 +00:00
|
|
|
if (ret)
|
|
|
|
goto exit;
|
2016-02-24 23:07:37 +00:00
|
|
|
|
2016-02-12 20:34:07 +00:00
|
|
|
} else if (sysfs_streq(buf, "standby")) {
|
|
|
|
if (arche_pdata->state == ARCHE_PLATFORM_STATE_STANDBY)
|
2016-05-05 14:34:58 +00:00
|
|
|
goto exit;
|
2016-02-12 20:34:07 +00:00
|
|
|
|
|
|
|
dev_warn(arche_pdata->dev, "standby state not supported\n");
|
2016-02-12 20:34:08 +00:00
|
|
|
} else if (sysfs_streq(buf, "fw_flashing")) {
|
|
|
|
if (arche_pdata->state == ARCHE_PLATFORM_STATE_FW_FLASHING)
|
2016-05-05 14:34:58 +00:00
|
|
|
goto exit;
|
2016-02-12 20:34:08 +00:00
|
|
|
|
greybus: arche-platform: Add support for SPI bus sharing for Mihi
In case of Mihi, SPI bus is shared between APB1 and APB2
SPI ROMs, so their FW flashing must be sequential and
arche-platform driver should make sure that they are mutual
exclusive in nature.
So this patch adds certain restrictions to the user of the
arche-platform driver,
- User can no longer flash APB1 and APB2 SPI ROM in parallel
- SPI bus becomes an resource, so user must claim it by moving
respective APB device into FW_FLASHING mode and release it
by exiting FW_FLASHING mode. User can exit FW_FLASHING mode by
switching to any other modes (ACTIVE, OFF, STANDBY).
- If APB1 is in FW_FLASHING mode, APB2 can no longer enter into
FW_FLASHING mode. User will get -EBUSY.
Having said that, while APB1 is into FW_FLASHING mode,
APB2 can independently boot from its own SPI ROM.
Testing Done: Tested by simulating usecase on EVT2.
- Made sure that APB1 and APB2 FW_FLASHING mode is mutual exclusive
in nature. Confirmed that an attempt on second device return -EBUSY.
- Added simulating code, where printed state of dummy gpio for
spi-en and verified that it shows right pin status for both APBs
Signed-off-by: Vaibhav Hiremath <vaibhav.hiremath@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
2016-07-28 08:17:37 +00:00
|
|
|
/*
|
|
|
|
* Here we only control SVC.
|
|
|
|
*
|
|
|
|
* In case of FW_FLASHING mode we do not want to control
|
|
|
|
* APBs, as in case of V2, SPI bus is shared between both
|
|
|
|
* the APBs. So let user chose which APB he wants to flash.
|
|
|
|
*/
|
2016-02-12 20:34:08 +00:00
|
|
|
arche_platform_poweroff_seq(arche_pdata);
|
greybus: arche-platform: Fix boot, poweroff and fw_flashing seq with APBs
Now SVC driver has an access to APBs operational functions
(coldboot, standby_boot, fw_flashing and poweroff), SVC driver
can control APB's as per below rules,
- If SVC goes down (poweroff state), it will also power off APBs
and vice a versa for all operational states.
- On boot, SVC will probe/populate APB device, but will not coldboot
it. APBs will coldboot only after handshaking with SVC over
wake/detect line.
Note that, both APBs share same wake/detect line.
So from user/developer perspective, it is highly recommended that
they should use arche-platform interfaces, instead of individual
apb interface,
# echo [off/active/standby/fw_flashing] > /sys/devices/arche_platform.*/state
Note: 'standby' mode is not supported as of now.
Testing Done: Testd on EVT1.2 and DB3.5 platform.
Signed-off-by: Vaibhav Hiremath <vaibhav.hiremath@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
2016-02-12 20:34:17 +00:00
|
|
|
|
2016-05-24 13:02:02 +00:00
|
|
|
ret = arche_platform_fw_flashing_seq(arche_pdata);
|
|
|
|
if (ret)
|
|
|
|
goto exit;
|
2016-02-12 20:34:07 +00:00
|
|
|
} else {
|
|
|
|
dev_err(arche_pdata->dev, "unknown state\n");
|
|
|
|
ret = -EINVAL;
|
|
|
|
}
|
|
|
|
|
2016-05-05 14:34:58 +00:00
|
|
|
exit:
|
|
|
|
mutex_unlock(&arche_pdata->platform_state_mutex);
|
2016-02-12 20:34:07 +00:00
|
|
|
return ret ? ret : count;
|
|
|
|
}
|
|
|
|
|
|
|
|
static ssize_t state_show(struct device *dev,
|
2017-12-17 17:56:27 +00:00
|
|
|
struct device_attribute *attr, char *buf)
|
2016-02-12 20:34:07 +00:00
|
|
|
{
|
|
|
|
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");
|
2016-02-12 20:34:08 +00:00
|
|
|
case ARCHE_PLATFORM_STATE_FW_FLASHING:
|
|
|
|
return sprintf(buf, "fw_flashing\n");
|
2016-02-12 20:34:07 +00:00
|
|
|
default:
|
|
|
|
return sprintf(buf, "unknown state\n");
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
static DEVICE_ATTR_RW(state);
|
|
|
|
|
2016-04-15 19:45:15 +00:00
|
|
|
static int arche_platform_pm_notifier(struct notifier_block *notifier,
|
|
|
|
unsigned long pm_event, void *unused)
|
|
|
|
{
|
|
|
|
struct arche_platform_drvdata *arche_pdata =
|
|
|
|
container_of(notifier, struct arche_platform_drvdata,
|
|
|
|
pm_notifier);
|
2016-05-05 14:34:58 +00:00
|
|
|
int ret = NOTIFY_DONE;
|
2016-04-15 19:45:15 +00:00
|
|
|
|
2016-05-05 14:34:58 +00:00
|
|
|
mutex_lock(&arche_pdata->platform_state_mutex);
|
2016-04-15 19:45:15 +00:00
|
|
|
switch (pm_event) {
|
|
|
|
case PM_SUSPEND_PREPARE:
|
2016-05-05 14:34:58 +00:00
|
|
|
if (arche_pdata->state != ARCHE_PLATFORM_STATE_ACTIVE) {
|
|
|
|
ret = NOTIFY_STOP;
|
|
|
|
break;
|
|
|
|
}
|
2016-04-15 19:45:15 +00:00
|
|
|
device_for_each_child(arche_pdata->dev, NULL, apb_poweroff);
|
|
|
|
arche_platform_poweroff_seq(arche_pdata);
|
|
|
|
break;
|
|
|
|
case PM_POST_SUSPEND:
|
greybus: arche-platform: Reset SVC & APB only if turned off by SUSPEND_PREPARE
There is possible race condition in arche platform driver for
maintaining of ->state field, when shared with timesync driver.
Assume device booted fine, all connected modules have been enumerated
correctly. As part of suspend-resume operation we have pm_notifier
callback, where we turn off SVC & APB and coldboot on resume.
In the process of resume, all modules gets enumerated again, and
timesync driver does come into picture everytime.
So when timesync driver requests arche-platform to change the state
to TIMESYNC and in the middle of sync operation, if suspend gets
triggered, then execution lands into arche-platform->pm_notifier callback,
leading to race condition in the driver, where it checks for (state != ACTIVE)
in PM_SUSPEND_PREPARE and returns, but in PM_POST_SUSPEND it just simply
coldboots SVC & APB, which would inbalance all resources (including IRQ).
So we need a add check in PM_POST_SUSPEND, to make sure that, we only
coldboot devices if they are in to off state,
i.e. if (state != OFF) then return.
Testing Done: Done regressive suspend/resume testing on EVT2 platform.
Note that, I some time hit issue.
Signed-off-by: Vaibhav Hiremath <vaibhav.hiremath@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
2016-08-03 11:45:38 +00:00
|
|
|
if (arche_pdata->state != ARCHE_PLATFORM_STATE_OFF)
|
|
|
|
break;
|
|
|
|
|
2016-05-17 17:09:47 +00:00
|
|
|
arche_platform_wd_irq_en(arche_pdata);
|
2016-05-17 17:09:46 +00:00
|
|
|
arche_platform_coldboot_seq(arche_pdata);
|
2016-04-15 19:45:15 +00:00
|
|
|
break;
|
|
|
|
default:
|
|
|
|
break;
|
|
|
|
}
|
2016-05-05 14:34:58 +00:00
|
|
|
mutex_unlock(&arche_pdata->platform_state_mutex);
|
2016-04-15 19:45:15 +00:00
|
|
|
|
2016-05-05 14:34:58 +00:00
|
|
|
return ret;
|
2016-04-15 19:45:15 +00:00
|
|
|
}
|
|
|
|
|
2015-12-16 10:59:18 +00:00
|
|
|
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
|
|
|
{
|
2015-12-16 10:59:18 +00:00
|
|
|
struct arche_platform_drvdata *arche_pdata;
|
2015-12-16 10:59:17 +00:00
|
|
|
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;
|
2019-01-14 14:58:59 +00:00
|
|
|
unsigned int flags;
|
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
|
|
|
|
2017-02-09 16:30:11 +00:00
|
|
|
arche_pdata = devm_kzalloc(&pdev->dev, sizeof(*arche_pdata),
|
|
|
|
GFP_KERNEL);
|
2015-12-16 10:59:18 +00:00
|
|
|
if (!arche_pdata)
|
2015-12-16 10:59:17 +00:00
|
|
|
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
|
|
|
|
2015-12-16 10:59:17 +00:00
|
|
|
/* setup svc reset gpio */
|
2015-12-16 10:59:18 +00:00
|
|
|
arche_pdata->is_reset_act_hi = of_property_read_bool(np,
|
2017-12-17 17:56:27 +00:00
|
|
|
"svc,reset-active-high");
|
2019-01-14 14:58:59 +00:00
|
|
|
if (arche_pdata->is_reset_act_hi)
|
|
|
|
flags = GPIOD_OUT_HIGH;
|
|
|
|
else
|
|
|
|
flags = GPIOD_OUT_LOW;
|
|
|
|
|
|
|
|
arche_pdata->svc_reset = devm_gpiod_get(dev, "svc,reset", flags);
|
|
|
|
if (IS_ERR(arche_pdata->svc_reset)) {
|
|
|
|
ret = PTR_ERR(arche_pdata->svc_reset);
|
|
|
|
dev_err(dev, "failed to request svc-reset GPIO: %d\n", ret);
|
2015-12-16 10:59:17 +00:00
|
|
|
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
|
|
|
}
|
2016-05-05 14:34:59 +00:00
|
|
|
arche_platform_set_state(arche_pdata, 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
|
|
|
|
2019-01-14 14:58:59 +00:00
|
|
|
arche_pdata->svc_sysboot = devm_gpiod_get(dev, "svc,sysboot",
|
|
|
|
GPIOD_OUT_LOW);
|
|
|
|
if (IS_ERR(arche_pdata->svc_sysboot)) {
|
|
|
|
ret = PTR_ERR(arche_pdata->svc_sysboot);
|
|
|
|
dev_err(dev, "failed to request sysboot0 GPIO: %d\n", ret);
|
2015-12-16 10:59:17 +00:00
|
|
|
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
|
|
|
}
|
|
|
|
|
2015-12-16 10:59:17 +00:00
|
|
|
/* setup the clock request gpio first */
|
2019-01-14 14:58:59 +00:00
|
|
|
arche_pdata->svc_refclk_req = devm_gpiod_get(dev, "svc,refclk-req",
|
|
|
|
GPIOD_IN);
|
|
|
|
if (IS_ERR(arche_pdata->svc_refclk_req)) {
|
|
|
|
ret = PTR_ERR(arche_pdata->svc_refclk_req);
|
|
|
|
dev_err(dev, "failed to request svc-clk-req 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;
|
|
|
|
}
|
|
|
|
|
2015-12-16 10:59:17 +00:00
|
|
|
/* setup refclk2 to follow the pin */
|
2015-12-16 10:59:18 +00:00
|
|
|
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);
|
2015-12-16 10:59:17 +00:00
|
|
|
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
|
|
|
|
2015-12-16 10:59:18 +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
|
|
|
|
2015-12-16 10:59:18 +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
|
|
|
|
2019-01-14 14:58:59 +00:00
|
|
|
arche_pdata->wake_detect = devm_gpiod_get(dev, "svc,wake-detect",
|
|
|
|
GPIOD_IN);
|
|
|
|
if (IS_ERR(arche_pdata->wake_detect)) {
|
|
|
|
ret = PTR_ERR(arche_pdata->wake_detect);
|
|
|
|
dev_err(dev, "Failed requesting wake_detect GPIO: %d\n", ret);
|
2016-02-12 20:34:03 +00:00
|
|
|
return ret;
|
2016-01-11 05:59:05 +00:00
|
|
|
}
|
2016-05-17 17:09:46 +00:00
|
|
|
|
2016-05-05 14:34:59 +00:00
|
|
|
arche_platform_set_wake_detect_state(arche_pdata, WD_STATE_IDLE);
|
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
|
|
|
|
2016-01-11 12:11:24 +00:00
|
|
|
arche_pdata->dev = &pdev->dev;
|
|
|
|
|
2016-05-05 14:34:57 +00:00
|
|
|
spin_lock_init(&arche_pdata->wake_lock);
|
2016-05-05 14:34:58 +00:00
|
|
|
mutex_init(&arche_pdata->platform_state_mutex);
|
2016-02-24 23:07:36 +00:00
|
|
|
arche_pdata->wake_detect_irq =
|
2019-01-14 14:58:59 +00:00
|
|
|
gpiod_to_irq(arche_pdata->wake_detect);
|
2016-02-24 23:07:36 +00:00
|
|
|
|
|
|
|
ret = devm_request_threaded_irq(dev, arche_pdata->wake_detect_irq,
|
2017-02-09 16:30:11 +00:00
|
|
|
arche_platform_wd_irq,
|
|
|
|
arche_platform_wd_irq_thread,
|
|
|
|
IRQF_TRIGGER_FALLING |
|
|
|
|
IRQF_TRIGGER_RISING | IRQF_ONESHOT,
|
|
|
|
dev_name(dev), arche_pdata);
|
2016-02-24 23:07:36 +00:00
|
|
|
if (ret) {
|
|
|
|
dev_err(dev, "failed to request wake detect IRQ %d\n", ret);
|
|
|
|
return ret;
|
|
|
|
}
|
2016-07-19 08:01:46 +00:00
|
|
|
disable_irq(arche_pdata->wake_detect_irq);
|
2016-02-24 23:07:36 +00:00
|
|
|
|
2016-02-12 20:34:07 +00:00
|
|
|
ret = device_create_file(dev, &dev_attr_state);
|
|
|
|
if (ret) {
|
|
|
|
dev_err(dev, "failed to create state file in sysfs\n");
|
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
|
greybus: arche-platform: Fix boot, poweroff and fw_flashing seq with APBs
Now SVC driver has an access to APBs operational functions
(coldboot, standby_boot, fw_flashing and poweroff), SVC driver
can control APB's as per below rules,
- If SVC goes down (poweroff state), it will also power off APBs
and vice a versa for all operational states.
- On boot, SVC will probe/populate APB device, but will not coldboot
it. APBs will coldboot only after handshaking with SVC over
wake/detect line.
Note that, both APBs share same wake/detect line.
So from user/developer perspective, it is highly recommended that
they should use arche-platform interfaces, instead of individual
apb interface,
# echo [off/active/standby/fw_flashing] > /sys/devices/arche_platform.*/state
Note: 'standby' mode is not supported as of now.
Testing Done: Testd on EVT1.2 and DB3.5 platform.
Signed-off-by: Vaibhav Hiremath <vaibhav.hiremath@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
2016-02-12 20:34:17 +00:00
|
|
|
ret = of_platform_populate(np, NULL, NULL, dev);
|
|
|
|
if (ret) {
|
|
|
|
dev_err(dev, "failed to populate child nodes %d\n", ret);
|
2016-07-19 08:01:46 +00:00
|
|
|
goto err_device_remove;
|
greybus: arche-platform: Fix boot, poweroff and fw_flashing seq with APBs
Now SVC driver has an access to APBs operational functions
(coldboot, standby_boot, fw_flashing and poweroff), SVC driver
can control APB's as per below rules,
- If SVC goes down (poweroff state), it will also power off APBs
and vice a versa for all operational states.
- On boot, SVC will probe/populate APB device, but will not coldboot
it. APBs will coldboot only after handshaking with SVC over
wake/detect line.
Note that, both APBs share same wake/detect line.
So from user/developer perspective, it is highly recommended that
they should use arche-platform interfaces, instead of individual
apb interface,
# echo [off/active/standby/fw_flashing] > /sys/devices/arche_platform.*/state
Note: 'standby' mode is not supported as of now.
Testing Done: Testd on EVT1.2 and DB3.5 platform.
Signed-off-by: Vaibhav Hiremath <vaibhav.hiremath@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
2016-02-12 20:34:17 +00:00
|
|
|
}
|
|
|
|
|
2016-04-15 19:45:15 +00:00
|
|
|
arche_pdata->pm_notifier.notifier_call = arche_platform_pm_notifier;
|
|
|
|
ret = register_pm_notifier(&arche_pdata->pm_notifier);
|
2016-05-05 14:34:58 +00:00
|
|
|
|
2016-04-15 19:45:15 +00:00
|
|
|
if (ret) {
|
|
|
|
dev_err(dev, "failed to register pm notifier %d\n", ret);
|
2016-07-19 08:01:46 +00:00
|
|
|
goto err_device_remove;
|
2016-04-15 19:45:15 +00:00
|
|
|
}
|
|
|
|
|
2016-07-19 08:01:46 +00:00
|
|
|
/* Explicitly power off if requested */
|
|
|
|
if (!of_property_read_bool(pdev->dev.of_node, "arche,init-off")) {
|
|
|
|
mutex_lock(&arche_pdata->platform_state_mutex);
|
|
|
|
ret = arche_platform_coldboot_seq(arche_pdata);
|
|
|
|
if (ret) {
|
|
|
|
dev_err(dev, "Failed to cold boot svc %d\n", ret);
|
|
|
|
goto err_coldboot;
|
|
|
|
}
|
|
|
|
arche_platform_wd_irq_en(arche_pdata);
|
|
|
|
mutex_unlock(&arche_pdata->platform_state_mutex);
|
|
|
|
}
|
|
|
|
|
2015-12-16 10:59:17 +00:00
|
|
|
dev_info(dev, "Device registered successfully\n");
|
2016-01-11 05:59:05 +00:00
|
|
|
return 0;
|
2016-02-24 20:57:36 +00:00
|
|
|
|
|
|
|
err_coldboot:
|
2016-05-05 14:34:58 +00:00
|
|
|
mutex_unlock(&arche_pdata->platform_state_mutex);
|
2016-07-19 08:01:46 +00:00
|
|
|
err_device_remove:
|
2016-02-24 20:57:36 +00:00
|
|
|
device_remove_file(&pdev->dev, &dev_attr_state);
|
|
|
|
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
|
|
|
}
|
|
|
|
|
2015-12-28 14:36:32 +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;
|
|
|
|
}
|
|
|
|
|
2023-04-03 15:39:55 +00:00
|
|
|
static void 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
|
|
|
{
|
2015-12-16 10:59:18 +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
|
|
|
|
2016-04-15 19:45:15 +00:00
|
|
|
unregister_pm_notifier(&arche_pdata->pm_notifier);
|
2016-02-12 20:34:07 +00:00
|
|
|
device_remove_file(&pdev->dev, &dev_attr_state);
|
2015-12-28 14:36:32 +00:00
|
|
|
device_for_each_child(&pdev->dev, NULL, arche_remove_child);
|
2016-02-12 20:34:04 +00:00
|
|
|
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
|
|
|
|
greybus: arche-platform: Control usb3613 from arche-platform
USB3613 hub driver exports control function, which allows caller
to switch the mode of operation of hub device.
As we know that, we have dependency between HUB3613 and APB's where,
HUB supposed to enter into HUB only after APB's brought out of reset.
Until now, we had all userspace driver sequences to control this,
but now since we are moving all resource management strictly to the
driver, it makes sense (even though it looks hacky) to enable control
of hub3613 from arche-platform driver.
Note that, there is another discussion where, the hub.connect IO pin may
get interfaced with MSM gpio, at that time, we can get rid of this hack
and replace it with gpio control.
Testing Done: Tested on EVT1.2 and DB3.5 platform.
Signed-off-by: Vaibhav Hiremath <vaibhav.hiremath@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
2016-02-12 20:34:20 +00:00
|
|
|
if (usb3613_hub_mode_ctrl(false))
|
|
|
|
dev_warn(arche_pdata->dev, "failed to control hub device\n");
|
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
|
|
|
}
|
|
|
|
|
2017-05-18 13:28:00 +00:00
|
|
|
static __maybe_unused 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;
|
|
|
|
}
|
|
|
|
|
2017-05-18 13:28:00 +00:00
|
|
|
static __maybe_unused 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
|
|
|
{
|
|
|
|
/*
|
2022-04-30 23:01:39 +00:00
|
|
|
* At least for ES2 we have to meet the delay requirement between
|
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
|
|
|
* 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;
|
|
|
|
}
|
|
|
|
|
2016-07-13 00:41:21 +00:00
|
|
|
static void arche_platform_shutdown(struct platform_device *pdev)
|
|
|
|
{
|
|
|
|
struct arche_platform_drvdata *arche_pdata = platform_get_drvdata(pdev);
|
|
|
|
|
|
|
|
arche_platform_poweroff_seq(arche_pdata);
|
|
|
|
|
|
|
|
usb3613_hub_mode_ctrl(false);
|
|
|
|
}
|
|
|
|
|
2015-12-16 10:59:18 +00:00
|
|
|
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
|
|
|
|
2016-09-22 15:33:34 +00:00
|
|
|
static const struct of_device_id arche_platform_of_match[] = {
|
2017-07-11 03:14:44 +00:00
|
|
|
/* Use PID/VID of SVC device */
|
|
|
|
{ .compatible = "google,arche-platform", },
|
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
|
|
|
{ },
|
|
|
|
};
|
2015-12-30 21:38:33 +00:00
|
|
|
|
2016-09-22 15:33:34 +00:00
|
|
|
static const struct of_device_id arche_combined_id[] = {
|
2017-07-11 03:14:44 +00:00
|
|
|
/* Use PID/VID of SVC device */
|
|
|
|
{ .compatible = "google,arche-platform", },
|
2015-12-30 21:38:33 +00:00
|
|
|
{ .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
|
|
|
|
2015-12-16 10:59:18 +00:00
|
|
|
static struct platform_driver arche_platform_device_driver = {
|
|
|
|
.probe = arche_platform_probe,
|
2023-04-03 15:39:55 +00:00
|
|
|
.remove_new = arche_platform_remove,
|
2016-07-13 00:41:21 +00:00
|
|
|
.shutdown = arche_platform_shutdown,
|
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 = {
|
2015-12-16 10:59:18 +00:00
|
|
|
.name = "arche-platform-ctrl",
|
|
|
|
.pm = &arche_platform_pm_ops,
|
2015-12-30 21:38:33 +00:00
|
|
|
.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
|
|
|
}
|
|
|
|
};
|
|
|
|
|
2015-12-30 21:38:33 +00:00
|
|
|
static int __init arche_init(void)
|
|
|
|
{
|
|
|
|
int retval;
|
|
|
|
|
|
|
|
retval = platform_driver_register(&arche_platform_device_driver);
|
|
|
|
if (retval)
|
|
|
|
return retval;
|
|
|
|
|
2016-04-20 06:18:37 +00:00
|
|
|
retval = arche_apb_init();
|
2015-12-30 21:38:33 +00:00
|
|
|
if (retval)
|
|
|
|
platform_driver_unregister(&arche_platform_device_driver);
|
|
|
|
|
|
|
|
return retval;
|
|
|
|
}
|
|
|
|
module_init(arche_init);
|
|
|
|
|
|
|
|
static void __exit arche_exit(void)
|
|
|
|
{
|
2016-04-20 06:18:37 +00:00
|
|
|
arche_apb_exit();
|
2015-12-30 21:38:33 +00:00
|
|
|
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
|
|
|
|
2016-05-13 19:00:56 +00:00
|
|
|
MODULE_LICENSE("GPL v2");
|
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_AUTHOR("Vaibhav Hiremath <vaibhav.hiremath@linaro.org>");
|
2015-12-16 10:59:18 +00:00
|
|
|
MODULE_DESCRIPTION("Arche Platform Driver");
|