Home
last modified time | relevance | path

Searched hist:"0 b741b82" (Results 1 – 5 of 5) sorted by relevance

/openbmc/linux/drivers/soc/bcm/brcmstb/
H A DKconfig0b741b82 Thu Jun 15 14:37:31 CDT 2017 Brian Norris <computersforpeace@gmail.com> soc: bcm: brcmstb: Add support for S2/S3/S5 suspend states (ARM)

This commit adds support for the Broadcom STB S2/S3/S5 suspend states on
ARM based SoCs.

This requires quite a lot of code in order to deal with the different HW
blocks that need to be quiesced during suspend:

- DDR PHY SHIM
- DDR memory controller and sequencer
- control processor

The final steps of the suspend execute in an on-chip SRAM and there is a
little bit of assembly code in order to shut down the DDR PHY PLL and
then go into a wfi loop until a wake-up even occurs. Conversely the
resume part involves waiting for the DDR PHY PLL to come back up and
resume executions where we left.

For S3, because of our memory hashing (actual hashing code not included
for simplicity, and is bypassed) we need to relocate the writable
variables (stack) into SRAM shortly before suspending in order to leave
the DRAM untouched and create a reliable hash of its contents.

This code has been contributed by Brian Norris initially and has been
incrementally fixed and updated to support new chips by a lot of people.

Signed-off-by: Brian Norris <computersforpeace@gmail.com>
Signed-off-by: Markus Mayer <mmayer@broadcom.com>
Signed-off-by: Justin Chen <justinpopo6@gmail.com>
Signed-off-by: Gareth Powell <gpowell@broadcom.com>
Signed-off-by: Doug Berger <opendmb@gmail.com>
Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
0b741b82 Thu Jun 15 14:37:31 CDT 2017 Brian Norris <computersforpeace@gmail.com> soc: bcm: brcmstb: Add support for S2/S3/S5 suspend states (ARM)

This commit adds support for the Broadcom STB S2/S3/S5 suspend states on
ARM based SoCs.

This requires quite a lot of code in order to deal with the different HW
blocks that need to be quiesced during suspend:

- DDR PHY SHIM
- DDR memory controller and sequencer
- control processor

The final steps of the suspend execute in an on-chip SRAM and there is a
little bit of assembly code in order to shut down the DDR PHY PLL and
then go into a wfi loop until a wake-up even occurs. Conversely the
resume part involves waiting for the DDR PHY PLL to come back up and
resume executions where we left.

For S3, because of our memory hashing (actual hashing code not included
for simplicity, and is bypassed) we need to relocate the writable
variables (stack) into SRAM shortly before suspending in order to leave
the DRAM untouched and create a reliable hash of its contents.

This code has been contributed by Brian Norris initially and has been
incrementally fixed and updated to support new chips by a lot of people.

Signed-off-by: Brian Norris <computersforpeace@gmail.com>
Signed-off-by: Markus Mayer <mmayer@broadcom.com>
Signed-off-by: Justin Chen <justinpopo6@gmail.com>
Signed-off-by: Gareth Powell <gpowell@broadcom.com>
Signed-off-by: Doug Berger <opendmb@gmail.com>
Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
H A DMakefile0b741b82 Thu Jun 15 14:37:31 CDT 2017 Brian Norris <computersforpeace@gmail.com> soc: bcm: brcmstb: Add support for S2/S3/S5 suspend states (ARM)

This commit adds support for the Broadcom STB S2/S3/S5 suspend states on
ARM based SoCs.

This requires quite a lot of code in order to deal with the different HW
blocks that need to be quiesced during suspend:

- DDR PHY SHIM
- DDR memory controller and sequencer
- control processor

The final steps of the suspend execute in an on-chip SRAM and there is a
little bit of assembly code in order to shut down the DDR PHY PLL and
then go into a wfi loop until a wake-up even occurs. Conversely the
resume part involves waiting for the DDR PHY PLL to come back up and
resume executions where we left.

For S3, because of our memory hashing (actual hashing code not included
for simplicity, and is bypassed) we need to relocate the writable
variables (stack) into SRAM shortly before suspending in order to leave
the DRAM untouched and create a reliable hash of its contents.

This code has been contributed by Brian Norris initially and has been
incrementally fixed and updated to support new chips by a lot of people.

Signed-off-by: Brian Norris <computersforpeace@gmail.com>
Signed-off-by: Markus Mayer <mmayer@broadcom.com>
Signed-off-by: Justin Chen <justinpopo6@gmail.com>
Signed-off-by: Gareth Powell <gpowell@broadcom.com>
Signed-off-by: Doug Berger <opendmb@gmail.com>
Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
0b741b82 Thu Jun 15 14:37:31 CDT 2017 Brian Norris <computersforpeace@gmail.com> soc: bcm: brcmstb: Add support for S2/S3/S5 suspend states (ARM)

This commit adds support for the Broadcom STB S2/S3/S5 suspend states on
ARM based SoCs.

This requires quite a lot of code in order to deal with the different HW
blocks that need to be quiesced during suspend:

- DDR PHY SHIM
- DDR memory controller and sequencer
- control processor

The final steps of the suspend execute in an on-chip SRAM and there is a
little bit of assembly code in order to shut down the DDR PHY PLL and
then go into a wfi loop until a wake-up even occurs. Conversely the
resume part involves waiting for the DDR PHY PLL to come back up and
resume executions where we left.

For S3, because of our memory hashing (actual hashing code not included
for simplicity, and is bypassed) we need to relocate the writable
variables (stack) into SRAM shortly before suspending in order to leave
the DRAM untouched and create a reliable hash of its contents.

This code has been contributed by Brian Norris initially and has been
incrementally fixed and updated to support new chips by a lot of people.

Signed-off-by: Brian Norris <computersforpeace@gmail.com>
Signed-off-by: Markus Mayer <mmayer@broadcom.com>
Signed-off-by: Justin Chen <justinpopo6@gmail.com>
Signed-off-by: Gareth Powell <gpowell@broadcom.com>
Signed-off-by: Doug Berger <opendmb@gmail.com>
Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
/openbmc/linux/drivers/soc/bcm/brcmstb/pm/
H A DMakefile0b741b82 Thu Jun 15 14:37:31 CDT 2017 Brian Norris <computersforpeace@gmail.com> soc: bcm: brcmstb: Add support for S2/S3/S5 suspend states (ARM)

This commit adds support for the Broadcom STB S2/S3/S5 suspend states on
ARM based SoCs.

This requires quite a lot of code in order to deal with the different HW
blocks that need to be quiesced during suspend:

- DDR PHY SHIM
- DDR memory controller and sequencer
- control processor

The final steps of the suspend execute in an on-chip SRAM and there is a
little bit of assembly code in order to shut down the DDR PHY PLL and
then go into a wfi loop until a wake-up even occurs. Conversely the
resume part involves waiting for the DDR PHY PLL to come back up and
resume executions where we left.

For S3, because of our memory hashing (actual hashing code not included
for simplicity, and is bypassed) we need to relocate the writable
variables (stack) into SRAM shortly before suspending in order to leave
the DRAM untouched and create a reliable hash of its contents.

This code has been contributed by Brian Norris initially and has been
incrementally fixed and updated to support new chips by a lot of people.

Signed-off-by: Brian Norris <computersforpeace@gmail.com>
Signed-off-by: Markus Mayer <mmayer@broadcom.com>
Signed-off-by: Justin Chen <justinpopo6@gmail.com>
Signed-off-by: Gareth Powell <gpowell@broadcom.com>
Signed-off-by: Doug Berger <opendmb@gmail.com>
Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
0b741b82 Thu Jun 15 14:37:31 CDT 2017 Brian Norris <computersforpeace@gmail.com> soc: bcm: brcmstb: Add support for S2/S3/S5 suspend states (ARM)

This commit adds support for the Broadcom STB S2/S3/S5 suspend states on
ARM based SoCs.

This requires quite a lot of code in order to deal with the different HW
blocks that need to be quiesced during suspend:

- DDR PHY SHIM
- DDR memory controller and sequencer
- control processor

The final steps of the suspend execute in an on-chip SRAM and there is a
little bit of assembly code in order to shut down the DDR PHY PLL and
then go into a wfi loop until a wake-up even occurs. Conversely the
resume part involves waiting for the DDR PHY PLL to come back up and
resume executions where we left.

For S3, because of our memory hashing (actual hashing code not included
for simplicity, and is bypassed) we need to relocate the writable
variables (stack) into SRAM shortly before suspending in order to leave
the DRAM untouched and create a reliable hash of its contents.

This code has been contributed by Brian Norris initially and has been
incrementally fixed and updated to support new chips by a lot of people.

Signed-off-by: Brian Norris <computersforpeace@gmail.com>
Signed-off-by: Markus Mayer <mmayer@broadcom.com>
Signed-off-by: Justin Chen <justinpopo6@gmail.com>
Signed-off-by: Gareth Powell <gpowell@broadcom.com>
Signed-off-by: Doug Berger <opendmb@gmail.com>
Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
H A Dpm.h0b741b82 Thu Jun 15 14:37:31 CDT 2017 Brian Norris <computersforpeace@gmail.com> soc: bcm: brcmstb: Add support for S2/S3/S5 suspend states (ARM)

This commit adds support for the Broadcom STB S2/S3/S5 suspend states on
ARM based SoCs.

This requires quite a lot of code in order to deal with the different HW
blocks that need to be quiesced during suspend:

- DDR PHY SHIM
- DDR memory controller and sequencer
- control processor

The final steps of the suspend execute in an on-chip SRAM and there is a
little bit of assembly code in order to shut down the DDR PHY PLL and
then go into a wfi loop until a wake-up even occurs. Conversely the
resume part involves waiting for the DDR PHY PLL to come back up and
resume executions where we left.

For S3, because of our memory hashing (actual hashing code not included
for simplicity, and is bypassed) we need to relocate the writable
variables (stack) into SRAM shortly before suspending in order to leave
the DRAM untouched and create a reliable hash of its contents.

This code has been contributed by Brian Norris initially and has been
incrementally fixed and updated to support new chips by a lot of people.

Signed-off-by: Brian Norris <computersforpeace@gmail.com>
Signed-off-by: Markus Mayer <mmayer@broadcom.com>
Signed-off-by: Justin Chen <justinpopo6@gmail.com>
Signed-off-by: Gareth Powell <gpowell@broadcom.com>
Signed-off-by: Doug Berger <opendmb@gmail.com>
Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
0b741b82 Thu Jun 15 14:37:31 CDT 2017 Brian Norris <computersforpeace@gmail.com> soc: bcm: brcmstb: Add support for S2/S3/S5 suspend states (ARM)

This commit adds support for the Broadcom STB S2/S3/S5 suspend states on
ARM based SoCs.

This requires quite a lot of code in order to deal with the different HW
blocks that need to be quiesced during suspend:

- DDR PHY SHIM
- DDR memory controller and sequencer
- control processor

The final steps of the suspend execute in an on-chip SRAM and there is a
little bit of assembly code in order to shut down the DDR PHY PLL and
then go into a wfi loop until a wake-up even occurs. Conversely the
resume part involves waiting for the DDR PHY PLL to come back up and
resume executions where we left.

For S3, because of our memory hashing (actual hashing code not included
for simplicity, and is bypassed) we need to relocate the writable
variables (stack) into SRAM shortly before suspending in order to leave
the DRAM untouched and create a reliable hash of its contents.

This code has been contributed by Brian Norris initially and has been
incrementally fixed and updated to support new chips by a lot of people.

Signed-off-by: Brian Norris <computersforpeace@gmail.com>
Signed-off-by: Markus Mayer <mmayer@broadcom.com>
Signed-off-by: Justin Chen <justinpopo6@gmail.com>
Signed-off-by: Gareth Powell <gpowell@broadcom.com>
Signed-off-by: Doug Berger <opendmb@gmail.com>
Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
/openbmc/linux/drivers/soc/bcm/
H A DKconfig0b741b82 Thu Jun 15 14:37:31 CDT 2017 Brian Norris <computersforpeace@gmail.com> soc: bcm: brcmstb: Add support for S2/S3/S5 suspend states (ARM)

This commit adds support for the Broadcom STB S2/S3/S5 suspend states on
ARM based SoCs.

This requires quite a lot of code in order to deal with the different HW
blocks that need to be quiesced during suspend:

- DDR PHY SHIM
- DDR memory controller and sequencer
- control processor

The final steps of the suspend execute in an on-chip SRAM and there is a
little bit of assembly code in order to shut down the DDR PHY PLL and
then go into a wfi loop until a wake-up even occurs. Conversely the
resume part involves waiting for the DDR PHY PLL to come back up and
resume executions where we left.

For S3, because of our memory hashing (actual hashing code not included
for simplicity, and is bypassed) we need to relocate the writable
variables (stack) into SRAM shortly before suspending in order to leave
the DRAM untouched and create a reliable hash of its contents.

This code has been contributed by Brian Norris initially and has been
incrementally fixed and updated to support new chips by a lot of people.

Signed-off-by: Brian Norris <computersforpeace@gmail.com>
Signed-off-by: Markus Mayer <mmayer@broadcom.com>
Signed-off-by: Justin Chen <justinpopo6@gmail.com>
Signed-off-by: Gareth Powell <gpowell@broadcom.com>
Signed-off-by: Doug Berger <opendmb@gmail.com>
Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
0b741b82 Thu Jun 15 14:37:31 CDT 2017 Brian Norris <computersforpeace@gmail.com> soc: bcm: brcmstb: Add support for S2/S3/S5 suspend states (ARM)

This commit adds support for the Broadcom STB S2/S3/S5 suspend states on
ARM based SoCs.

This requires quite a lot of code in order to deal with the different HW
blocks that need to be quiesced during suspend:

- DDR PHY SHIM
- DDR memory controller and sequencer
- control processor

The final steps of the suspend execute in an on-chip SRAM and there is a
little bit of assembly code in order to shut down the DDR PHY PLL and
then go into a wfi loop until a wake-up even occurs. Conversely the
resume part involves waiting for the DDR PHY PLL to come back up and
resume executions where we left.

For S3, because of our memory hashing (actual hashing code not included
for simplicity, and is bypassed) we need to relocate the writable
variables (stack) into SRAM shortly before suspending in order to leave
the DRAM untouched and create a reliable hash of its contents.

This code has been contributed by Brian Norris initially and has been
incrementally fixed and updated to support new chips by a lot of people.

Signed-off-by: Brian Norris <computersforpeace@gmail.com>
Signed-off-by: Markus Mayer <mmayer@broadcom.com>
Signed-off-by: Justin Chen <justinpopo6@gmail.com>
Signed-off-by: Gareth Powell <gpowell@broadcom.com>
Signed-off-by: Doug Berger <opendmb@gmail.com>
Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>