* [PATCH v4 0/4] ARM: OMAP2+: AM33XX: VDD CORE OPP50 support
@ 2013-08-13 22:20 ` Russ Dill
0 siblings, 0 replies; 84+ messages in thread
From: Russ Dill @ 2013-08-13 22:20 UTC (permalink / raw)
To: linux-omap; +Cc: devicetree, Kevin Hilman, linux-arm-kernel, devicetree-discuss
This is v4 of the OPP50 (VDD CORE 0.95V during suspend) patch set.
Adjusting voltages to this lower operating point during suspend saves
additional power. This operating point can only be reached when SDRAM is
in self refresh and certain DPLLs have been put into bypass mode. This
means that the code to change the regulator to run at the correct voltage
must be run from either SRAM or the Cortex-M3 (CM3) PM co-processor must
perform the action.
As different boards will power VDD CORE through different methods, the
necessary steps must be contained within the device tree. In order to
accommodate this, additional device tree properties have been created that
can be placed in I2C bus nodes. The properties give a sequence of I2C
commands that should be run at suspend and resume time.
The purpose and method of executing these sequences is left up to each
platform. In the case of the am33xx, the CM3 firmware writes out the
simple I2C sequences.
Each sequence is a series of I2C write commands. The first byte is the
length of the write, the second byte the I2C device to address, and the
following bytes are the message.
Example:
i2c0: i2c@44e0b000 {
pinctrl-names = "default";
pinctrl-0 = <&i2c0_pins>;
status = "okay";
clock-frequency = <400000>;
/* Set OPP50 (0.95V) for VDD core */
sleep_sequence = /bits/ 8 <
0x02 0x2d 0x25 0x1f /* Set VDD2 to 0.95V */
>;
/* Set OPP100 (1.10V) for VDD core */
wake_sequence = /bits/ 8 <
0x02 0x2d 0x25 0x2b /* Set VDD2 to 1.1V */
>;
tps: tps@2d {
reg = <0x2d>;
};
};
In the above example, the sequence "0x25 0x1f" is written to the I2C
device at address 0x2d (the TPS65910 PMIC). The PMIC interprets that as
a write to a register at address 0x25.
I'd really like to get some feedback on the devicetree bindings.
The patch set depends on the latest am335x suspend resume patch set from Dave
Gerlach[1], which also depends on the latest Mailbox patch set from Suman
Anna[2], and the latest CM3 firmware[3].
Changes since v1:
* Rebased onto new am335x PM branch
* Changed to use 5th param register
Changes since v2:
* Pass bus speed in kHz to M3 firmware
Changes since v3:
* Rebase to Dave Gerlach's am335x suspend/resume patch set
* Add device tree documentation
* Add dts changes for evmsk and gp evm
[1] http://comments.gmane.org/gmane.linux.ports.arm.omap/102561
[2] http://comments.gmane.org/gmane.linux.ports.arm.kernel/258196
[3] http://arago-project.org/git/projects/?p=am33x-cm3.git;a=shortlog;h=refs/heads/next2
Russ Dill (4):
ARM: OMAP2+: AM33XX: I2C Sleep/wake sequence support
ARM: dts: add AM33XX vdd core opp50 suspend for Beaglebone.
ARM: dts: add AM33XX vdd core opp50 suspend for AM335X GP EVM.
ARM: dts: AM33XX vdd core opp50 suspend for EVM-SK
.../devicetree/bindings/i2c/i2c-suspend-resume.txt | 44 +++++++++++
arch/arm/boot/dts/am335x-bone.dts | 25 +++++-
arch/arm/boot/dts/am335x-evm.dts | 10 +++
arch/arm/boot/dts/am335x-evmsk.dts | 10 +++
arch/arm/mach-omap2/control.c | 1 +
arch/arm/mach-omap2/pm33xx.c | 89 ++++++++++++++++++++++
arch/arm/mach-omap2/pm33xx.h | 2 +
arch/arm/mach-omap2/wkup_m3.c | 57 ++++++++++++--
8 files changed, 230 insertions(+), 8 deletions(-)
create mode 100644 Documentation/devicetree/bindings/i2c/i2c-suspend-resume.txt
--
1.8.3.2
^ permalink raw reply [flat|nested] 84+ messages in thread* [PATCH v4 0/4] ARM: OMAP2+: AM33XX: VDD CORE OPP50 support @ 2013-08-13 22:20 ` Russ Dill 0 siblings, 0 replies; 84+ messages in thread From: Russ Dill @ 2013-08-13 22:20 UTC (permalink / raw) To: linux-arm-kernel This is v4 of the OPP50 (VDD CORE 0.95V during suspend) patch set. Adjusting voltages to this lower operating point during suspend saves additional power. This operating point can only be reached when SDRAM is in self refresh and certain DPLLs have been put into bypass mode. This means that the code to change the regulator to run at the correct voltage must be run from either SRAM or the Cortex-M3 (CM3) PM co-processor must perform the action. As different boards will power VDD CORE through different methods, the necessary steps must be contained within the device tree. In order to accommodate this, additional device tree properties have been created that can be placed in I2C bus nodes. The properties give a sequence of I2C commands that should be run at suspend and resume time. The purpose and method of executing these sequences is left up to each platform. In the case of the am33xx, the CM3 firmware writes out the simple I2C sequences. Each sequence is a series of I2C write commands. The first byte is the length of the write, the second byte the I2C device to address, and the following bytes are the message. Example: i2c0: i2c at 44e0b000 { pinctrl-names = "default"; pinctrl-0 = <&i2c0_pins>; status = "okay"; clock-frequency = <400000>; /* Set OPP50 (0.95V) for VDD core */ sleep_sequence = /bits/ 8 < 0x02 0x2d 0x25 0x1f /* Set VDD2 to 0.95V */ >; /* Set OPP100 (1.10V) for VDD core */ wake_sequence = /bits/ 8 < 0x02 0x2d 0x25 0x2b /* Set VDD2 to 1.1V */ >; tps: tps at 2d { reg = <0x2d>; }; }; In the above example, the sequence "0x25 0x1f" is written to the I2C device at address 0x2d (the TPS65910 PMIC). The PMIC interprets that as a write to a register at address 0x25. I'd really like to get some feedback on the devicetree bindings. The patch set depends on the latest am335x suspend resume patch set from Dave Gerlach[1], which also depends on the latest Mailbox patch set from Suman Anna[2], and the latest CM3 firmware[3]. Changes since v1: * Rebased onto new am335x PM branch * Changed to use 5th param register Changes since v2: * Pass bus speed in kHz to M3 firmware Changes since v3: * Rebase to Dave Gerlach's am335x suspend/resume patch set * Add device tree documentation * Add dts changes for evmsk and gp evm [1] http://comments.gmane.org/gmane.linux.ports.arm.omap/102561 [2] http://comments.gmane.org/gmane.linux.ports.arm.kernel/258196 [3] http://arago-project.org/git/projects/?p=am33x-cm3.git;a=shortlog;h=refs/heads/next2 Russ Dill (4): ARM: OMAP2+: AM33XX: I2C Sleep/wake sequence support ARM: dts: add AM33XX vdd core opp50 suspend for Beaglebone. ARM: dts: add AM33XX vdd core opp50 suspend for AM335X GP EVM. ARM: dts: AM33XX vdd core opp50 suspend for EVM-SK .../devicetree/bindings/i2c/i2c-suspend-resume.txt | 44 +++++++++++ arch/arm/boot/dts/am335x-bone.dts | 25 +++++- arch/arm/boot/dts/am335x-evm.dts | 10 +++ arch/arm/boot/dts/am335x-evmsk.dts | 10 +++ arch/arm/mach-omap2/control.c | 1 + arch/arm/mach-omap2/pm33xx.c | 89 ++++++++++++++++++++++ arch/arm/mach-omap2/pm33xx.h | 2 + arch/arm/mach-omap2/wkup_m3.c | 57 ++++++++++++-- 8 files changed, 230 insertions(+), 8 deletions(-) create mode 100644 Documentation/devicetree/bindings/i2c/i2c-suspend-resume.txt -- 1.8.3.2 ^ permalink raw reply [flat|nested] 84+ messages in thread
* [PATCH v4 1/4] ARM: OMAP2+: AM33XX: I2C Sleep/wake sequence support 2013-08-13 22:20 ` Russ Dill @ 2013-08-13 22:20 ` Russ Dill -1 siblings, 0 replies; 84+ messages in thread From: Russ Dill @ 2013-08-13 22:20 UTC (permalink / raw) To: linux-omap; +Cc: devicetree, Kevin Hilman, linux-arm-kernel, devicetree-discuss Changes since v1: * Rebased onto new am335x PM branch * Changed to use 5th param register Changes since v2: * Passes I2C bus speed in kHz to M3 firmware Changes since v3: * Rebased to 3.11-rc3, moves some functionality to wkup_m3.c * Additional comments * Added device-tree binding documentation This patch adds the ability to pass an I2C sleep sequence and wake sequence to the Cortex-M3. This is useful for adjusting voltages during sleep that cannot be lowered while SDRAM is active. A modified M3 firmware with I2C support is required. Each sequence is a series of I2C transfers in the form: u8 length | u8 chip address | u8 byte0/reg address | u8 byte 1 | u8 byte n ... The length indicates the number of bytes to transfer, including the register address. The length of each transfer is limited by the I2C buffer size of 32 bytes. The sequences are taken from the i2c1 node in the device tree. The property name for the sleep sequence is "sleep_sequence" and the property name for the wake sequence is "wake_sequence". Each property should be an array of bytes. No actions are performed if the properties are not present in the device tree. Signed-off-by: Russ Dill <Russ.Dill@ti.com> --- .../devicetree/bindings/i2c/i2c-suspend-resume.txt | 44 +++++++++++ arch/arm/mach-omap2/control.c | 1 + arch/arm/mach-omap2/pm33xx.c | 89 ++++++++++++++++++++++ arch/arm/mach-omap2/pm33xx.h | 2 + arch/arm/mach-omap2/wkup_m3.c | 57 ++++++++++++-- 5 files changed, 186 insertions(+), 7 deletions(-) create mode 100644 Documentation/devicetree/bindings/i2c/i2c-suspend-resume.txt diff --git a/Documentation/devicetree/bindings/i2c/i2c-suspend-resume.txt b/Documentation/devicetree/bindings/i2c/i2c-suspend-resume.txt new file mode 100644 index 0000000..af19372 --- /dev/null +++ b/Documentation/devicetree/bindings/i2c/i2c-suspend-resume.txt @@ -0,0 +1,44 @@ +I2C suspend/resume sequences + +This provides the ability for a simple I2C sequence to be written at +suspend time and resume time. This is for sequences that cannot be written +by the I2C bus driver for reasons such as needing to be run from SRAM +or needing to be written by firmware. + +The sequence is composed of messages. Each message contains a length byte, +an address byte, and then the message. + +Optional properties: +- sleep_sequence + I2C sequence to write during suspend + +- wake_sequence + I2C sequence to write during wake + +Examples : + +i2c0: i2c@0 { + /* Set OPP50 (0.95V) for VDD core */ + sleep_sequence = /bits/ 8 < + 0x02 0x24 0x0b 0x6d /* Password unlock 1 */ + 0x02 0x24 0x10 0x02 /* Set DCDC3 to 0.95V */ + 0x02 0x24 0x0b 0x6d /* Password unlock 2 */ + 0x02 0x24 0x10 0x02 /* Set DCDC3 to 0.95V */ + 0x02 0x24 0x0b 0x6c /* Password unlock 1 */ + 0x02 0x24 0x11 0x86 /* Apply DCDC changes */ + 0x02 0x24 0x0b 0x6c /* Password unlock 2 */ + 0x02 0x24 0x11 0x86 /* Apply DCDC changes */ + >; + + /* Set OPP100 (1.10V) for VDD core */ + wake_sequence = /bits/ 8 < + 0x02 0x24 0x0b 0x6d /* Password unlock 1 */ + 0x02 0x24 0x10 0x08 /* Set DCDC3 to 1.1V */ + 0x02 0x24 0x0b 0x6d /* Password unlock 2 */ + 0x02 0x24 0x10 0x08 /* Set DCDC3 to 1.1V */ + 0x02 0x24 0x0b 0x6c /* Password unlock 1 */ + 0x02 0x24 0x11 0x86 /* Apply DCDC changes */ + 0x02 0x24 0x0b 0x6c /* Password unlock 2 */ + 0x02 0x24 0x11 0x86 /* Apply DCDC changes */ + >; +} diff --git a/arch/arm/mach-omap2/control.c b/arch/arm/mach-omap2/control.c index 934041a..dfbd5f0 100644 --- a/arch/arm/mach-omap2/control.c +++ b/arch/arm/mach-omap2/control.c @@ -639,6 +639,7 @@ void am33xx_pm_ipc_cmd(struct am33xx_ipc_data *data) omap_ctrl_writel(data->param1, AM33XX_CONTROL_IPC_MSG_REG2); omap_ctrl_writel(data->param2, AM33XX_CONTROL_IPC_MSG_REG3); omap_ctrl_writel(data->param3, AM33XX_CONTROL_IPC_MSG_REG4); + omap_ctrl_writel(data->param4, AM33XX_CONTROL_IPC_MSG_REG5); } int am33xx_pm_status(void) diff --git a/arch/arm/mach-omap2/pm33xx.c b/arch/arm/mach-omap2/pm33xx.c index d291c76..8880da3 100644 --- a/arch/arm/mach-omap2/pm33xx.c +++ b/arch/arm/mach-omap2/pm33xx.c @@ -29,6 +29,7 @@ #include <linux/ti_emif.h> #include <linux/omap-mailbox.h> +#include <asm/unaligned.h> #include <asm/suspend.h> #include <asm/proc-fns.h> #include <asm/sizes.h> @@ -50,6 +51,10 @@ static void __iomem *am33xx_emif_base; static struct powerdomain *cefuse_pwrdm, *gfx_pwrdm, *per_pwrdm, *mpu_pwrdm; static struct clockdomain *gfx_l4ls_clkdm; +static char *am33xx_i2c_sleep_sequence; +static char *am33xx_i2c_wake_sequence; +static size_t i2c_sleep_sequence_sz; +static size_t i2c_wake_sequence_sz; struct wakeup_src wakeups[] = { {.irq_nr = 35, .src = "USB0_PHY"}, @@ -232,12 +237,34 @@ static void am33xx_m3_state_machine_reset(void) static int am33xx_pm_begin(suspend_state_t state) { int i; + unsigned long param4; + int pos; cpu_idle_poll_ctrl(true); + param4 = DS_IPC_DEFAULT; + + wkup_m3_reset_data_pos(); + if (am33xx_i2c_sleep_sequence) { + pos = wkup_m3_copy_data(am33xx_i2c_sleep_sequence, + i2c_sleep_sequence_sz); + /* Lower 16 bits stores offset to sleep sequence */ + param4 &= ~0xffff; + param4 |= pos; + } + + if (am33xx_i2c_wake_sequence) { + pos = wkup_m3_copy_data(am33xx_i2c_wake_sequence, + i2c_wake_sequence_sz); + /* Upper 16 bits stores offset to wake sequence */ + param4 &= ~0xffff0000; + param4 |= pos << 16; + } + am33xx_pm->ipc.sleep_mode = IPC_CMD_DS0; am33xx_pm->ipc.param1 = DS_IPC_DEFAULT; am33xx_pm->ipc.param2 = DS_IPC_DEFAULT; + am33xx_pm->ipc.param4 = param4; am33xx_pm_ipc_cmd(&am33xx_pm->ipc); @@ -386,6 +413,62 @@ static int __init am33xx_map_emif(void) return 0; } +static int __init am33xx_setup_sleep_sequence(void) +{ + int ret; + int sz; + const void *prop; + struct device *dev; + u32 freq_hz = 100000; + unsigned short freq_khz; + + /* + * We put the device tree node in the I2C controller that will + * be sending the sequence. i2c1 is the only controller that can + * be accessed by the firmware as it is the only controller in the + * WKUP domain. + */ + dev = omap_device_get_by_hwmod_name("i2c1"); + if (IS_ERR(dev)) + return PTR_ERR(dev); + + of_property_read_u32(dev->of_node, "clock-frequency", &freq_hz); + freq_khz = freq_hz / 1000; + + prop = of_get_property(dev->of_node, "sleep_sequence", &sz); + if (prop) { + /* + * Length is sequence length + 2 bytes for freq_khz, and 1 + * byte for terminator. + */ + am33xx_i2c_sleep_sequence = kzalloc(sz + 3, GFP_KERNEL); + if (!am33xx_i2c_sleep_sequence) + return -ENOMEM; + put_unaligned_le16(freq_khz, am33xx_i2c_sleep_sequence); + memcpy(am33xx_i2c_sleep_sequence + 2, prop, sz); + i2c_sleep_sequence_sz = sz + 3; + } + + prop = of_get_property(dev->of_node, "wake_sequence", &sz); + if (prop) { + am33xx_i2c_wake_sequence = kzalloc(sz + 3, GFP_KERNEL); + if (!am33xx_i2c_wake_sequence) { + ret = -ENOMEM; + goto cleanup_sleep; + } + put_unaligned_le16(freq_khz, am33xx_i2c_sleep_sequence); + memcpy(am33xx_i2c_wake_sequence + 2, prop, sz); + i2c_wake_sequence_sz = sz + 3; + } + + return 0; + +cleanup_sleep: + kfree(am33xx_i2c_sleep_sequence); + am33xx_i2c_sleep_sequence = NULL; + return ret; +} + int __init am33xx_pm_init(void) { int ret; @@ -451,6 +534,12 @@ int __init am33xx_pm_init(void) } } + ret = am33xx_setup_sleep_sequence(); + if (ret) { + pr_err("Error fetching I2C sleep/wake sequence\n"); + goto err; + } + (void) clkdm_for_each(omap_pm_clkdms_setup, NULL); /* CEFUSE domain can be turned off post bootup */ diff --git a/arch/arm/mach-omap2/pm33xx.h b/arch/arm/mach-omap2/pm33xx.h index befdd11..d0f08a5 100644 --- a/arch/arm/mach-omap2/pm33xx.h +++ b/arch/arm/mach-omap2/pm33xx.h @@ -52,6 +52,8 @@ struct forced_standby_module { }; int wkup_m3_copy_code(const u8 *data, size_t size); +void wkup_m3_reset_data_pos(void); +int wkup_m3_copy_data(const u8 *data, size_t size); int wkup_m3_prepare(void); void wkup_m3_register_txev_handler(void (*txev_handler)(void)); diff --git a/arch/arm/mach-omap2/wkup_m3.c b/arch/arm/mach-omap2/wkup_m3.c index 8eaa7f3..a541de9 100644 --- a/arch/arm/mach-omap2/wkup_m3.c +++ b/arch/arm/mach-omap2/wkup_m3.c @@ -35,6 +35,9 @@ struct wkup_m3_context { struct device *dev; void __iomem *code; + void __iomem *data; + void __iomem *data_end; + size_t data_size; void (*txev_handler)(void); }; @@ -50,6 +53,30 @@ int wkup_m3_copy_code(const u8 *data, size_t size) return 0; } +/* + * This pair of functions allows data to be stuffed into the end of the + * CM3 data memory. This is currently used for passing the I2C sleep/wake + * sequences to the firmware. + */ + +/* Clear out the pointer for data stored at the end of DMEM */ +void wkup_m3_reset_data_pos(void) +{ + wkup_m3->data_end = wkup_m3->data + wkup_m3->data_size; +} + +/* + * Store a block of data at the end of DMEM, return the offset within DMEM + * that the data is stored at, or -ENOMEM if the data did not fit + */ +int wkup_m3_copy_data(const u8 *data, size_t size) +{ + if (wkup_m3->data + size > wkup_m3->data_end) + return -ENOMEM; + wkup_m3->data_end -= size; + memcpy_toio(wkup_m3->data_end, data, size); + return wkup_m3->data_end - wkup_m3->data; +} void wkup_m3_register_txev_handler(void (*txev_handler)(void)) { @@ -83,7 +110,7 @@ int wkup_m3_prepare(void) static int wkup_m3_probe(struct platform_device *pdev) { int irq, ret = 0; - struct resource *mem; + struct resource *umem, *dmem; pm_runtime_enable(&pdev->dev); @@ -95,14 +122,21 @@ static int wkup_m3_probe(struct platform_device *pdev) irq = platform_get_irq(pdev, 0); if (!irq) { - dev_err(wkup_m3->dev, "no irq resource\n"); + dev_err(&pdev->dev, "no irq resource\n"); + ret = -ENXIO; + goto err; + } + + umem = platform_get_resource(pdev, IORESOURCE_MEM, 0); + if (!umem) { + dev_err(&pdev->dev, "no UMEM resource\n"); ret = -ENXIO; goto err; } - mem = platform_get_resource(pdev, IORESOURCE_MEM, 0); - if (!mem) { - dev_err(wkup_m3->dev, "no memory resource\n"); + dmem = platform_get_resource(pdev, IORESOURCE_MEM, 1); + if (!dmem) { + dev_err(&pdev->dev, "no DMEM resource\n"); ret = -ENXIO; goto err; } @@ -116,12 +150,21 @@ static int wkup_m3_probe(struct platform_device *pdev) wkup_m3->dev = &pdev->dev; - wkup_m3->code = devm_request_and_ioremap(wkup_m3->dev, mem); + wkup_m3->code = devm_request_and_ioremap(wkup_m3->dev, umem); + if (!wkup_m3->code) { + dev_err(wkup_m3->dev, "could not ioremap UMEM\n"); + ret = -EADDRNOTAVAIL; + goto err; + } + + wkup_m3->data = devm_request_and_ioremap(wkup_m3->dev, dmem); if (!wkup_m3->code) { - dev_err(wkup_m3->dev, "could not ioremap\n"); + dev_err(wkup_m3->dev, "could not ioremap DMEM\n"); ret = -EADDRNOTAVAIL; goto err; } + wkup_m3->data_size = resource_size(dmem); + wkup_m3_reset_data_pos(); ret = devm_request_irq(wkup_m3->dev, irq, wkup_m3_txev_handler, IRQF_DISABLED, "wkup_m3_txev", NULL); -- 1.8.3.2 ^ permalink raw reply related [flat|nested] 84+ messages in thread
* [PATCH v4 1/4] ARM: OMAP2+: AM33XX: I2C Sleep/wake sequence support @ 2013-08-13 22:20 ` Russ Dill 0 siblings, 0 replies; 84+ messages in thread From: Russ Dill @ 2013-08-13 22:20 UTC (permalink / raw) To: linux-arm-kernel Changes since v1: * Rebased onto new am335x PM branch * Changed to use 5th param register Changes since v2: * Passes I2C bus speed in kHz to M3 firmware Changes since v3: * Rebased to 3.11-rc3, moves some functionality to wkup_m3.c * Additional comments * Added device-tree binding documentation This patch adds the ability to pass an I2C sleep sequence and wake sequence to the Cortex-M3. This is useful for adjusting voltages during sleep that cannot be lowered while SDRAM is active. A modified M3 firmware with I2C support is required. Each sequence is a series of I2C transfers in the form: u8 length | u8 chip address | u8 byte0/reg address | u8 byte 1 | u8 byte n ... The length indicates the number of bytes to transfer, including the register address. The length of each transfer is limited by the I2C buffer size of 32 bytes. The sequences are taken from the i2c1 node in the device tree. The property name for the sleep sequence is "sleep_sequence" and the property name for the wake sequence is "wake_sequence". Each property should be an array of bytes. No actions are performed if the properties are not present in the device tree. Signed-off-by: Russ Dill <Russ.Dill@ti.com> --- .../devicetree/bindings/i2c/i2c-suspend-resume.txt | 44 +++++++++++ arch/arm/mach-omap2/control.c | 1 + arch/arm/mach-omap2/pm33xx.c | 89 ++++++++++++++++++++++ arch/arm/mach-omap2/pm33xx.h | 2 + arch/arm/mach-omap2/wkup_m3.c | 57 ++++++++++++-- 5 files changed, 186 insertions(+), 7 deletions(-) create mode 100644 Documentation/devicetree/bindings/i2c/i2c-suspend-resume.txt diff --git a/Documentation/devicetree/bindings/i2c/i2c-suspend-resume.txt b/Documentation/devicetree/bindings/i2c/i2c-suspend-resume.txt new file mode 100644 index 0000000..af19372 --- /dev/null +++ b/Documentation/devicetree/bindings/i2c/i2c-suspend-resume.txt @@ -0,0 +1,44 @@ +I2C suspend/resume sequences + +This provides the ability for a simple I2C sequence to be written at +suspend time and resume time. This is for sequences that cannot be written +by the I2C bus driver for reasons such as needing to be run from SRAM +or needing to be written by firmware. + +The sequence is composed of messages. Each message contains a length byte, +an address byte, and then the message. + +Optional properties: +- sleep_sequence + I2C sequence to write during suspend + +- wake_sequence + I2C sequence to write during wake + +Examples : + +i2c0: i2c at 0 { + /* Set OPP50 (0.95V) for VDD core */ + sleep_sequence = /bits/ 8 < + 0x02 0x24 0x0b 0x6d /* Password unlock 1 */ + 0x02 0x24 0x10 0x02 /* Set DCDC3 to 0.95V */ + 0x02 0x24 0x0b 0x6d /* Password unlock 2 */ + 0x02 0x24 0x10 0x02 /* Set DCDC3 to 0.95V */ + 0x02 0x24 0x0b 0x6c /* Password unlock 1 */ + 0x02 0x24 0x11 0x86 /* Apply DCDC changes */ + 0x02 0x24 0x0b 0x6c /* Password unlock 2 */ + 0x02 0x24 0x11 0x86 /* Apply DCDC changes */ + >; + + /* Set OPP100 (1.10V) for VDD core */ + wake_sequence = /bits/ 8 < + 0x02 0x24 0x0b 0x6d /* Password unlock 1 */ + 0x02 0x24 0x10 0x08 /* Set DCDC3 to 1.1V */ + 0x02 0x24 0x0b 0x6d /* Password unlock 2 */ + 0x02 0x24 0x10 0x08 /* Set DCDC3 to 1.1V */ + 0x02 0x24 0x0b 0x6c /* Password unlock 1 */ + 0x02 0x24 0x11 0x86 /* Apply DCDC changes */ + 0x02 0x24 0x0b 0x6c /* Password unlock 2 */ + 0x02 0x24 0x11 0x86 /* Apply DCDC changes */ + >; +} diff --git a/arch/arm/mach-omap2/control.c b/arch/arm/mach-omap2/control.c index 934041a..dfbd5f0 100644 --- a/arch/arm/mach-omap2/control.c +++ b/arch/arm/mach-omap2/control.c @@ -639,6 +639,7 @@ void am33xx_pm_ipc_cmd(struct am33xx_ipc_data *data) omap_ctrl_writel(data->param1, AM33XX_CONTROL_IPC_MSG_REG2); omap_ctrl_writel(data->param2, AM33XX_CONTROL_IPC_MSG_REG3); omap_ctrl_writel(data->param3, AM33XX_CONTROL_IPC_MSG_REG4); + omap_ctrl_writel(data->param4, AM33XX_CONTROL_IPC_MSG_REG5); } int am33xx_pm_status(void) diff --git a/arch/arm/mach-omap2/pm33xx.c b/arch/arm/mach-omap2/pm33xx.c index d291c76..8880da3 100644 --- a/arch/arm/mach-omap2/pm33xx.c +++ b/arch/arm/mach-omap2/pm33xx.c @@ -29,6 +29,7 @@ #include <linux/ti_emif.h> #include <linux/omap-mailbox.h> +#include <asm/unaligned.h> #include <asm/suspend.h> #include <asm/proc-fns.h> #include <asm/sizes.h> @@ -50,6 +51,10 @@ static void __iomem *am33xx_emif_base; static struct powerdomain *cefuse_pwrdm, *gfx_pwrdm, *per_pwrdm, *mpu_pwrdm; static struct clockdomain *gfx_l4ls_clkdm; +static char *am33xx_i2c_sleep_sequence; +static char *am33xx_i2c_wake_sequence; +static size_t i2c_sleep_sequence_sz; +static size_t i2c_wake_sequence_sz; struct wakeup_src wakeups[] = { {.irq_nr = 35, .src = "USB0_PHY"}, @@ -232,12 +237,34 @@ static void am33xx_m3_state_machine_reset(void) static int am33xx_pm_begin(suspend_state_t state) { int i; + unsigned long param4; + int pos; cpu_idle_poll_ctrl(true); + param4 = DS_IPC_DEFAULT; + + wkup_m3_reset_data_pos(); + if (am33xx_i2c_sleep_sequence) { + pos = wkup_m3_copy_data(am33xx_i2c_sleep_sequence, + i2c_sleep_sequence_sz); + /* Lower 16 bits stores offset to sleep sequence */ + param4 &= ~0xffff; + param4 |= pos; + } + + if (am33xx_i2c_wake_sequence) { + pos = wkup_m3_copy_data(am33xx_i2c_wake_sequence, + i2c_wake_sequence_sz); + /* Upper 16 bits stores offset to wake sequence */ + param4 &= ~0xffff0000; + param4 |= pos << 16; + } + am33xx_pm->ipc.sleep_mode = IPC_CMD_DS0; am33xx_pm->ipc.param1 = DS_IPC_DEFAULT; am33xx_pm->ipc.param2 = DS_IPC_DEFAULT; + am33xx_pm->ipc.param4 = param4; am33xx_pm_ipc_cmd(&am33xx_pm->ipc); @@ -386,6 +413,62 @@ static int __init am33xx_map_emif(void) return 0; } +static int __init am33xx_setup_sleep_sequence(void) +{ + int ret; + int sz; + const void *prop; + struct device *dev; + u32 freq_hz = 100000; + unsigned short freq_khz; + + /* + * We put the device tree node in the I2C controller that will + * be sending the sequence. i2c1 is the only controller that can + * be accessed by the firmware as it is the only controller in the + * WKUP domain. + */ + dev = omap_device_get_by_hwmod_name("i2c1"); + if (IS_ERR(dev)) + return PTR_ERR(dev); + + of_property_read_u32(dev->of_node, "clock-frequency", &freq_hz); + freq_khz = freq_hz / 1000; + + prop = of_get_property(dev->of_node, "sleep_sequence", &sz); + if (prop) { + /* + * Length is sequence length + 2 bytes for freq_khz, and 1 + * byte for terminator. + */ + am33xx_i2c_sleep_sequence = kzalloc(sz + 3, GFP_KERNEL); + if (!am33xx_i2c_sleep_sequence) + return -ENOMEM; + put_unaligned_le16(freq_khz, am33xx_i2c_sleep_sequence); + memcpy(am33xx_i2c_sleep_sequence + 2, prop, sz); + i2c_sleep_sequence_sz = sz + 3; + } + + prop = of_get_property(dev->of_node, "wake_sequence", &sz); + if (prop) { + am33xx_i2c_wake_sequence = kzalloc(sz + 3, GFP_KERNEL); + if (!am33xx_i2c_wake_sequence) { + ret = -ENOMEM; + goto cleanup_sleep; + } + put_unaligned_le16(freq_khz, am33xx_i2c_sleep_sequence); + memcpy(am33xx_i2c_wake_sequence + 2, prop, sz); + i2c_wake_sequence_sz = sz + 3; + } + + return 0; + +cleanup_sleep: + kfree(am33xx_i2c_sleep_sequence); + am33xx_i2c_sleep_sequence = NULL; + return ret; +} + int __init am33xx_pm_init(void) { int ret; @@ -451,6 +534,12 @@ int __init am33xx_pm_init(void) } } + ret = am33xx_setup_sleep_sequence(); + if (ret) { + pr_err("Error fetching I2C sleep/wake sequence\n"); + goto err; + } + (void) clkdm_for_each(omap_pm_clkdms_setup, NULL); /* CEFUSE domain can be turned off post bootup */ diff --git a/arch/arm/mach-omap2/pm33xx.h b/arch/arm/mach-omap2/pm33xx.h index befdd11..d0f08a5 100644 --- a/arch/arm/mach-omap2/pm33xx.h +++ b/arch/arm/mach-omap2/pm33xx.h @@ -52,6 +52,8 @@ struct forced_standby_module { }; int wkup_m3_copy_code(const u8 *data, size_t size); +void wkup_m3_reset_data_pos(void); +int wkup_m3_copy_data(const u8 *data, size_t size); int wkup_m3_prepare(void); void wkup_m3_register_txev_handler(void (*txev_handler)(void)); diff --git a/arch/arm/mach-omap2/wkup_m3.c b/arch/arm/mach-omap2/wkup_m3.c index 8eaa7f3..a541de9 100644 --- a/arch/arm/mach-omap2/wkup_m3.c +++ b/arch/arm/mach-omap2/wkup_m3.c @@ -35,6 +35,9 @@ struct wkup_m3_context { struct device *dev; void __iomem *code; + void __iomem *data; + void __iomem *data_end; + size_t data_size; void (*txev_handler)(void); }; @@ -50,6 +53,30 @@ int wkup_m3_copy_code(const u8 *data, size_t size) return 0; } +/* + * This pair of functions allows data to be stuffed into the end of the + * CM3 data memory. This is currently used for passing the I2C sleep/wake + * sequences to the firmware. + */ + +/* Clear out the pointer for data stored at the end of DMEM */ +void wkup_m3_reset_data_pos(void) +{ + wkup_m3->data_end = wkup_m3->data + wkup_m3->data_size; +} + +/* + * Store a block of data at the end of DMEM, return the offset within DMEM + * that the data is stored at, or -ENOMEM if the data did not fit + */ +int wkup_m3_copy_data(const u8 *data, size_t size) +{ + if (wkup_m3->data + size > wkup_m3->data_end) + return -ENOMEM; + wkup_m3->data_end -= size; + memcpy_toio(wkup_m3->data_end, data, size); + return wkup_m3->data_end - wkup_m3->data; +} void wkup_m3_register_txev_handler(void (*txev_handler)(void)) { @@ -83,7 +110,7 @@ int wkup_m3_prepare(void) static int wkup_m3_probe(struct platform_device *pdev) { int irq, ret = 0; - struct resource *mem; + struct resource *umem, *dmem; pm_runtime_enable(&pdev->dev); @@ -95,14 +122,21 @@ static int wkup_m3_probe(struct platform_device *pdev) irq = platform_get_irq(pdev, 0); if (!irq) { - dev_err(wkup_m3->dev, "no irq resource\n"); + dev_err(&pdev->dev, "no irq resource\n"); + ret = -ENXIO; + goto err; + } + + umem = platform_get_resource(pdev, IORESOURCE_MEM, 0); + if (!umem) { + dev_err(&pdev->dev, "no UMEM resource\n"); ret = -ENXIO; goto err; } - mem = platform_get_resource(pdev, IORESOURCE_MEM, 0); - if (!mem) { - dev_err(wkup_m3->dev, "no memory resource\n"); + dmem = platform_get_resource(pdev, IORESOURCE_MEM, 1); + if (!dmem) { + dev_err(&pdev->dev, "no DMEM resource\n"); ret = -ENXIO; goto err; } @@ -116,12 +150,21 @@ static int wkup_m3_probe(struct platform_device *pdev) wkup_m3->dev = &pdev->dev; - wkup_m3->code = devm_request_and_ioremap(wkup_m3->dev, mem); + wkup_m3->code = devm_request_and_ioremap(wkup_m3->dev, umem); + if (!wkup_m3->code) { + dev_err(wkup_m3->dev, "could not ioremap UMEM\n"); + ret = -EADDRNOTAVAIL; + goto err; + } + + wkup_m3->data = devm_request_and_ioremap(wkup_m3->dev, dmem); if (!wkup_m3->code) { - dev_err(wkup_m3->dev, "could not ioremap\n"); + dev_err(wkup_m3->dev, "could not ioremap DMEM\n"); ret = -EADDRNOTAVAIL; goto err; } + wkup_m3->data_size = resource_size(dmem); + wkup_m3_reset_data_pos(); ret = devm_request_irq(wkup_m3->dev, irq, wkup_m3_txev_handler, IRQF_DISABLED, "wkup_m3_txev", NULL); -- 1.8.3.2 ^ permalink raw reply related [flat|nested] 84+ messages in thread
* Re: [PATCH v4 1/4] ARM: OMAP2+: AM33XX: I2C Sleep/wake sequence support 2013-08-13 22:20 ` Russ Dill @ 2013-08-14 10:18 ` Gururaja Hebbar -1 siblings, 0 replies; 84+ messages in thread From: Gururaja Hebbar @ 2013-08-14 10:18 UTC (permalink / raw) To: Russ Dill Cc: linux-omap, devicetree, Kevin Hilman, linux-arm-kernel, devicetree-discuss On 8/14/2013 3:50 AM, Russ Dill wrote: > Changes since v1: > * Rebased onto new am335x PM branch > * Changed to use 5th param register > > Changes since v2: > * Passes I2C bus speed in kHz to M3 firmware > > Changes since v3: > * Rebased to 3.11-rc3, moves some functionality to wkup_m3.c > * Additional comments > * Added device-tree binding documentation AFAIK, Change logs should come below scissors line (---). However there was some discussion to keep it in the commit message. Don't know what happened to it finally. But till date, all revision patch set has the change log under the scissor line. > > This patch adds the ability to pass an I2C sleep sequence and wake sequence > to the Cortex-M3. This is useful for adjusting voltages during sleep that > cannot be lowered while SDRAM is active. A modified M3 firmware with I2C > support is required. > > Each sequence is a series of I2C transfers in the form: > > u8 length | u8 chip address | u8 byte0/reg address | u8 byte 1 | u8 byte n ... > > The length indicates the number of bytes to transfer, including the register > address. The length of each transfer is limited by the I2C buffer size of > 32 bytes. > > The sequences are taken from the i2c1 node in the device tree. The property > name for the sleep sequence is "sleep_sequence" and the property name for > the wake sequence is "wake_sequence". Each property should be an array of > bytes. > > No actions are performed if the properties are not present in the device > tree. > > Signed-off-by: Russ Dill <Russ.Dill@ti.com> > --- > .../devicetree/bindings/i2c/i2c-suspend-resume.txt | 44 +++++++++++ > arch/arm/mach-omap2/control.c | 1 + > arch/arm/mach-omap2/pm33xx.c | 89 ++++++++++++++++++++++ > arch/arm/mach-omap2/pm33xx.h | 2 + > arch/arm/mach-omap2/wkup_m3.c | 57 ++++++++++++-- > 5 files changed, 186 insertions(+), 7 deletions(-) > create mode 100644 Documentation/devicetree/bindings/i2c/i2c-suspend-resume.txt > > diff --git a/Documentation/devicetree/bindings/i2c/i2c-suspend-resume.txt b/Documentation/devicetree/bindings/i2c/i2c-suspend-resume.txt > new file mode 100644 > index 0000000..af19372 > --- /dev/null > +++ b/Documentation/devicetree/bindings/i2c/i2c-suspend-resume.txt > @@ -0,0 +1,44 @@ > +I2C suspend/resume sequences > + > +This provides the ability for a simple I2C sequence to be written at > +suspend time and resume time. This is for sequences that cannot be written > +by the I2C bus driver for reasons such as needing to be run from SRAM > +or needing to be written by firmware. > + > +The sequence is composed of messages. Each message contains a length byte, > +an address byte, and then the message. > + > +Optional properties: > +- sleep_sequence > + I2C sequence to write during suspend > + > +- wake_sequence > + I2C sequence to write during wake > + > +Examples : > + > +i2c0: i2c@0 { > + /* Set OPP50 (0.95V) for VDD core */ > + sleep_sequence = /bits/ 8 < > + 0x02 0x24 0x0b 0x6d /* Password unlock 1 */ > + 0x02 0x24 0x10 0x02 /* Set DCDC3 to 0.95V */ > + 0x02 0x24 0x0b 0x6d /* Password unlock 2 */ > + 0x02 0x24 0x10 0x02 /* Set DCDC3 to 0.95V */ > + 0x02 0x24 0x0b 0x6c /* Password unlock 1 */ > + 0x02 0x24 0x11 0x86 /* Apply DCDC changes */ > + 0x02 0x24 0x0b 0x6c /* Password unlock 2 */ > + 0x02 0x24 0x11 0x86 /* Apply DCDC changes */ > + >; This data is not related to i2c. Right? Then why is it under i2c dt node? There is already a wakeup node (wkup_m3) and a pmic node (pmic node for respective boards). Can't these details go under those nodes? > + > + /* Set OPP100 (1.10V) for VDD core */ > + wake_sequence = /bits/ 8 < > + 0x02 0x24 0x0b 0x6d /* Password unlock 1 */ > + 0x02 0x24 0x10 0x08 /* Set DCDC3 to 1.1V */ > + 0x02 0x24 0x0b 0x6d /* Password unlock 2 */ > + 0x02 0x24 0x10 0x08 /* Set DCDC3 to 1.1V */ > + 0x02 0x24 0x0b 0x6c /* Password unlock 1 */ > + 0x02 0x24 0x11 0x86 /* Apply DCDC changes */ > + 0x02 0x24 0x0b 0x6c /* Password unlock 2 */ > + 0x02 0x24 0x11 0x86 /* Apply DCDC changes */ > + >; > +} > diff --git a/arch/arm/mach-omap2/control.c b/arch/arm/mach-omap2/control.c > index 934041a..dfbd5f0 100644 > --- a/arch/arm/mach-omap2/control.c > +++ b/arch/arm/mach-omap2/control.c > @@ -639,6 +639,7 @@ void am33xx_pm_ipc_cmd(struct am33xx_ipc_data *data) > omap_ctrl_writel(data->param1, AM33XX_CONTROL_IPC_MSG_REG2); > omap_ctrl_writel(data->param2, AM33XX_CONTROL_IPC_MSG_REG3); > omap_ctrl_writel(data->param3, AM33XX_CONTROL_IPC_MSG_REG4); > + omap_ctrl_writel(data->param4, AM33XX_CONTROL_IPC_MSG_REG5); > } > > int am33xx_pm_status(void) > diff --git a/arch/arm/mach-omap2/pm33xx.c b/arch/arm/mach-omap2/pm33xx.c > index d291c76..8880da3 100644 > --- a/arch/arm/mach-omap2/pm33xx.c > +++ b/arch/arm/mach-omap2/pm33xx.c > @@ -29,6 +29,7 @@ > #include <linux/ti_emif.h> > #include <linux/omap-mailbox.h> > > +#include <asm/unaligned.h> > #include <asm/suspend.h> > #include <asm/proc-fns.h> > #include <asm/sizes.h> > @@ -50,6 +51,10 @@ > static void __iomem *am33xx_emif_base; > static struct powerdomain *cefuse_pwrdm, *gfx_pwrdm, *per_pwrdm, *mpu_pwrdm; > static struct clockdomain *gfx_l4ls_clkdm; > +static char *am33xx_i2c_sleep_sequence; > +static char *am33xx_i2c_wake_sequence; > +static size_t i2c_sleep_sequence_sz; > +static size_t i2c_wake_sequence_sz; > > struct wakeup_src wakeups[] = { > {.irq_nr = 35, .src = "USB0_PHY"}, > @@ -232,12 +237,34 @@ static void am33xx_m3_state_machine_reset(void) > static int am33xx_pm_begin(suspend_state_t state) > { > int i; > + unsigned long param4; > + int pos; > > cpu_idle_poll_ctrl(true); > > + param4 = DS_IPC_DEFAULT; > + > + wkup_m3_reset_data_pos(); > + if (am33xx_i2c_sleep_sequence) { > + pos = wkup_m3_copy_data(am33xx_i2c_sleep_sequence, > + i2c_sleep_sequence_sz); Why do we need to copy this data (same constant data) on every iteration? > + /* Lower 16 bits stores offset to sleep sequence */ > + param4 &= ~0xffff; > + param4 |= pos; > + } > + > + if (am33xx_i2c_wake_sequence) { > + pos = wkup_m3_copy_data(am33xx_i2c_wake_sequence, > + i2c_wake_sequence_sz); > + /* Upper 16 bits stores offset to wake sequence */ > + param4 &= ~0xffff0000; > + param4 |= pos << 16; > + } > + Seems above entire change can be done only once. > am33xx_pm->ipc.sleep_mode = IPC_CMD_DS0; > am33xx_pm->ipc.param1 = DS_IPC_DEFAULT; > am33xx_pm->ipc.param2 = DS_IPC_DEFAULT; > + am33xx_pm->ipc.param4 = param4; > > am33xx_pm_ipc_cmd(&am33xx_pm->ipc); > > @@ -386,6 +413,62 @@ static int __init am33xx_map_emif(void) > return 0; > } > > +static int __init am33xx_setup_sleep_sequence(void) > +{ > + int ret; > + int sz; > + const void *prop; > + struct device *dev; > + u32 freq_hz = 100000; Magic number? > + unsigned short freq_khz; > + > + /* > + * We put the device tree node in the I2C controller that will > + * be sending the sequence. i2c1 is the only controller that can > + * be accessed by the firmware as it is the only controller in the > + * WKUP domain. and on which the PMIC sits I believe? > + */ > + dev = omap_device_get_by_hwmod_name("i2c1"); > + if (IS_ERR(dev)) > + return PTR_ERR(dev); > + > + of_property_read_u32(dev->of_node, "clock-frequency", &freq_hz); > + freq_khz = freq_hz / 1000; Magic number? > + > + prop = of_get_property(dev->of_node, "sleep_sequence", &sz); > + if (prop) { > + /* > + * Length is sequence length + 2 bytes for freq_khz, and 1 > + * byte for terminator. > + */ > + am33xx_i2c_sleep_sequence = kzalloc(sz + 3, GFP_KERNEL); > + if (!am33xx_i2c_sleep_sequence) > + return -ENOMEM; > + put_unaligned_le16(freq_khz, am33xx_i2c_sleep_sequence); > + memcpy(am33xx_i2c_sleep_sequence + 2, prop, sz); so, looking at entire code, it seems there is 3 memory space for same data (or 1 original + 2 copy) 1. in DT 2. in am33xx_i2c_[sleep/wake]_sequence 3. in SRAm by call to wkup_m3_copy_data() why not directly copy to SRAM from DT? > + i2c_sleep_sequence_sz = sz + 3; > + } > + > + prop = of_get_property(dev->of_node, "wake_sequence", &sz); > + if (prop) { > + am33xx_i2c_wake_sequence = kzalloc(sz + 3, GFP_KERNEL); > + if (!am33xx_i2c_wake_sequence) { > + ret = -ENOMEM; > + goto cleanup_sleep; > + } > + put_unaligned_le16(freq_khz, am33xx_i2c_sleep_sequence); > + memcpy(am33xx_i2c_wake_sequence + 2, prop, sz); > + i2c_wake_sequence_sz = sz + 3; > + } > + > + return 0; > + > +cleanup_sleep: > + kfree(am33xx_i2c_sleep_sequence); > + am33xx_i2c_sleep_sequence = NULL; > + return ret; > +} > + > int __init am33xx_pm_init(void) > { > int ret; > @@ -451,6 +534,12 @@ int __init am33xx_pm_init(void) > } > } > > + ret = am33xx_setup_sleep_sequence(); > + if (ret) { > + pr_err("Error fetching I2C sleep/wake sequence\n"); > + goto err; > + } > + > (void) clkdm_for_each(omap_pm_clkdms_setup, NULL); > > /* CEFUSE domain can be turned off post bootup */ > diff --git a/arch/arm/mach-omap2/pm33xx.h b/arch/arm/mach-omap2/pm33xx.h > index befdd11..d0f08a5 100644 > --- a/arch/arm/mach-omap2/pm33xx.h > +++ b/arch/arm/mach-omap2/pm33xx.h > @@ -52,6 +52,8 @@ struct forced_standby_module { > }; > > int wkup_m3_copy_code(const u8 *data, size_t size); > +void wkup_m3_reset_data_pos(void); > +int wkup_m3_copy_data(const u8 *data, size_t size); > int wkup_m3_prepare(void); > void wkup_m3_register_txev_handler(void (*txev_handler)(void)); > > diff --git a/arch/arm/mach-omap2/wkup_m3.c b/arch/arm/mach-omap2/wkup_m3.c > index 8eaa7f3..a541de9 100644 > --- a/arch/arm/mach-omap2/wkup_m3.c > +++ b/arch/arm/mach-omap2/wkup_m3.c > @@ -35,6 +35,9 @@ > struct wkup_m3_context { > struct device *dev; > void __iomem *code; > + void __iomem *data; > + void __iomem *data_end; > + size_t data_size; > void (*txev_handler)(void); > }; > > @@ -50,6 +53,30 @@ int wkup_m3_copy_code(const u8 *data, size_t size) > return 0; > } > > +/* > + * This pair of functions allows data to be stuffed into the end of the > + * CM3 data memory. This is currently used for passing the I2C sleep/wake > + * sequences to the firmware. > + */ > + > +/* Clear out the pointer for data stored at the end of DMEM */ > +void wkup_m3_reset_data_pos(void) > +{ > + wkup_m3->data_end = wkup_m3->data + wkup_m3->data_size; > +} > + > +/* > + * Store a block of data at the end of DMEM, return the offset within DMEM > + * that the data is stored at, or -ENOMEM if the data did not fit > + */ > +int wkup_m3_copy_data(const u8 *data, size_t size) > +{ > + if (wkup_m3->data + size > wkup_m3->data_end) > + return -ENOMEM; > + wkup_m3->data_end -= size; > + memcpy_toio(wkup_m3->data_end, data, size); > + return wkup_m3->data_end - wkup_m3->data; > +} > > void wkup_m3_register_txev_handler(void (*txev_handler)(void)) > { > @@ -83,7 +110,7 @@ int wkup_m3_prepare(void) > static int wkup_m3_probe(struct platform_device *pdev) > { > int irq, ret = 0; > - struct resource *mem; > + struct resource *umem, *dmem; > > pm_runtime_enable(&pdev->dev); > > @@ -95,14 +122,21 @@ static int wkup_m3_probe(struct platform_device *pdev) > > irq = platform_get_irq(pdev, 0); > if (!irq) { > - dev_err(wkup_m3->dev, "no irq resource\n"); > + dev_err(&pdev->dev, "no irq resource\n"); unrelated change?. Better to mention this as code cleanup in commit. > + ret = -ENXIO; > + goto err; > + } > + > + umem = platform_get_resource(pdev, IORESOURCE_MEM, 0); > + if (!umem) { > + dev_err(&pdev->dev, "no UMEM resource\n"); > ret = -ENXIO; > goto err; > } > > - mem = platform_get_resource(pdev, IORESOURCE_MEM, 0); > - if (!mem) { > - dev_err(wkup_m3->dev, "no memory resource\n"); > + dmem = platform_get_resource(pdev, IORESOURCE_MEM, 1); > + if (!dmem) { > + dev_err(&pdev->dev, "no DMEM resource\n"); > ret = -ENXIO; > goto err; > } > @@ -116,12 +150,21 @@ static int wkup_m3_probe(struct platform_device *pdev) > > wkup_m3->dev = &pdev->dev; > > - wkup_m3->code = devm_request_and_ioremap(wkup_m3->dev, mem); > + wkup_m3->code = devm_request_and_ioremap(wkup_m3->dev, umem); > + if (!wkup_m3->code) { > + dev_err(wkup_m3->dev, "could not ioremap UMEM\n"); why not use "pdev->dev" here? > + ret = -EADDRNOTAVAIL; > + goto err; > + } > + > + wkup_m3->data = devm_request_and_ioremap(wkup_m3->dev, dmem); > if (!wkup_m3->code) { I believe this is just a copy/paste error. s/code/data > - dev_err(wkup_m3->dev, "could not ioremap\n"); > + dev_err(wkup_m3->dev, "could not ioremap DMEM\n"); same as above. > ret = -EADDRNOTAVAIL; > goto err; > } > + wkup_m3->data_size = resource_size(dmem); > + wkup_m3_reset_data_pos(); > > ret = devm_request_irq(wkup_m3->dev, irq, wkup_m3_txev_handler, > IRQF_DISABLED, "wkup_m3_txev", NULL); > -- 1.8.3.2 -- To unsubscribe from this list: send the line "unsubscribe > linux-omap" in the body of a message to majordomo@vger.kernel.org More > majordomo info at http://vger.kernel.org/majordomo-info.html > ^ permalink raw reply [flat|nested] 84+ messages in thread
* [PATCH v4 1/4] ARM: OMAP2+: AM33XX: I2C Sleep/wake sequence support @ 2013-08-14 10:18 ` Gururaja Hebbar 0 siblings, 0 replies; 84+ messages in thread From: Gururaja Hebbar @ 2013-08-14 10:18 UTC (permalink / raw) To: linux-arm-kernel On 8/14/2013 3:50 AM, Russ Dill wrote: > Changes since v1: > * Rebased onto new am335x PM branch > * Changed to use 5th param register > > Changes since v2: > * Passes I2C bus speed in kHz to M3 firmware > > Changes since v3: > * Rebased to 3.11-rc3, moves some functionality to wkup_m3.c > * Additional comments > * Added device-tree binding documentation AFAIK, Change logs should come below scissors line (---). However there was some discussion to keep it in the commit message. Don't know what happened to it finally. But till date, all revision patch set has the change log under the scissor line. > > This patch adds the ability to pass an I2C sleep sequence and wake sequence > to the Cortex-M3. This is useful for adjusting voltages during sleep that > cannot be lowered while SDRAM is active. A modified M3 firmware with I2C > support is required. > > Each sequence is a series of I2C transfers in the form: > > u8 length | u8 chip address | u8 byte0/reg address | u8 byte 1 | u8 byte n ... > > The length indicates the number of bytes to transfer, including the register > address. The length of each transfer is limited by the I2C buffer size of > 32 bytes. > > The sequences are taken from the i2c1 node in the device tree. The property > name for the sleep sequence is "sleep_sequence" and the property name for > the wake sequence is "wake_sequence". Each property should be an array of > bytes. > > No actions are performed if the properties are not present in the device > tree. > > Signed-off-by: Russ Dill <Russ.Dill@ti.com> > --- > .../devicetree/bindings/i2c/i2c-suspend-resume.txt | 44 +++++++++++ > arch/arm/mach-omap2/control.c | 1 + > arch/arm/mach-omap2/pm33xx.c | 89 ++++++++++++++++++++++ > arch/arm/mach-omap2/pm33xx.h | 2 + > arch/arm/mach-omap2/wkup_m3.c | 57 ++++++++++++-- > 5 files changed, 186 insertions(+), 7 deletions(-) > create mode 100644 Documentation/devicetree/bindings/i2c/i2c-suspend-resume.txt > > diff --git a/Documentation/devicetree/bindings/i2c/i2c-suspend-resume.txt b/Documentation/devicetree/bindings/i2c/i2c-suspend-resume.txt > new file mode 100644 > index 0000000..af19372 > --- /dev/null > +++ b/Documentation/devicetree/bindings/i2c/i2c-suspend-resume.txt > @@ -0,0 +1,44 @@ > +I2C suspend/resume sequences > + > +This provides the ability for a simple I2C sequence to be written at > +suspend time and resume time. This is for sequences that cannot be written > +by the I2C bus driver for reasons such as needing to be run from SRAM > +or needing to be written by firmware. > + > +The sequence is composed of messages. Each message contains a length byte, > +an address byte, and then the message. > + > +Optional properties: > +- sleep_sequence > + I2C sequence to write during suspend > + > +- wake_sequence > + I2C sequence to write during wake > + > +Examples : > + > +i2c0: i2c at 0 { > + /* Set OPP50 (0.95V) for VDD core */ > + sleep_sequence = /bits/ 8 < > + 0x02 0x24 0x0b 0x6d /* Password unlock 1 */ > + 0x02 0x24 0x10 0x02 /* Set DCDC3 to 0.95V */ > + 0x02 0x24 0x0b 0x6d /* Password unlock 2 */ > + 0x02 0x24 0x10 0x02 /* Set DCDC3 to 0.95V */ > + 0x02 0x24 0x0b 0x6c /* Password unlock 1 */ > + 0x02 0x24 0x11 0x86 /* Apply DCDC changes */ > + 0x02 0x24 0x0b 0x6c /* Password unlock 2 */ > + 0x02 0x24 0x11 0x86 /* Apply DCDC changes */ > + >; This data is not related to i2c. Right? Then why is it under i2c dt node? There is already a wakeup node (wkup_m3) and a pmic node (pmic node for respective boards). Can't these details go under those nodes? > + > + /* Set OPP100 (1.10V) for VDD core */ > + wake_sequence = /bits/ 8 < > + 0x02 0x24 0x0b 0x6d /* Password unlock 1 */ > + 0x02 0x24 0x10 0x08 /* Set DCDC3 to 1.1V */ > + 0x02 0x24 0x0b 0x6d /* Password unlock 2 */ > + 0x02 0x24 0x10 0x08 /* Set DCDC3 to 1.1V */ > + 0x02 0x24 0x0b 0x6c /* Password unlock 1 */ > + 0x02 0x24 0x11 0x86 /* Apply DCDC changes */ > + 0x02 0x24 0x0b 0x6c /* Password unlock 2 */ > + 0x02 0x24 0x11 0x86 /* Apply DCDC changes */ > + >; > +} > diff --git a/arch/arm/mach-omap2/control.c b/arch/arm/mach-omap2/control.c > index 934041a..dfbd5f0 100644 > --- a/arch/arm/mach-omap2/control.c > +++ b/arch/arm/mach-omap2/control.c > @@ -639,6 +639,7 @@ void am33xx_pm_ipc_cmd(struct am33xx_ipc_data *data) > omap_ctrl_writel(data->param1, AM33XX_CONTROL_IPC_MSG_REG2); > omap_ctrl_writel(data->param2, AM33XX_CONTROL_IPC_MSG_REG3); > omap_ctrl_writel(data->param3, AM33XX_CONTROL_IPC_MSG_REG4); > + omap_ctrl_writel(data->param4, AM33XX_CONTROL_IPC_MSG_REG5); > } > > int am33xx_pm_status(void) > diff --git a/arch/arm/mach-omap2/pm33xx.c b/arch/arm/mach-omap2/pm33xx.c > index d291c76..8880da3 100644 > --- a/arch/arm/mach-omap2/pm33xx.c > +++ b/arch/arm/mach-omap2/pm33xx.c > @@ -29,6 +29,7 @@ > #include <linux/ti_emif.h> > #include <linux/omap-mailbox.h> > > +#include <asm/unaligned.h> > #include <asm/suspend.h> > #include <asm/proc-fns.h> > #include <asm/sizes.h> > @@ -50,6 +51,10 @@ > static void __iomem *am33xx_emif_base; > static struct powerdomain *cefuse_pwrdm, *gfx_pwrdm, *per_pwrdm, *mpu_pwrdm; > static struct clockdomain *gfx_l4ls_clkdm; > +static char *am33xx_i2c_sleep_sequence; > +static char *am33xx_i2c_wake_sequence; > +static size_t i2c_sleep_sequence_sz; > +static size_t i2c_wake_sequence_sz; > > struct wakeup_src wakeups[] = { > {.irq_nr = 35, .src = "USB0_PHY"}, > @@ -232,12 +237,34 @@ static void am33xx_m3_state_machine_reset(void) > static int am33xx_pm_begin(suspend_state_t state) > { > int i; > + unsigned long param4; > + int pos; > > cpu_idle_poll_ctrl(true); > > + param4 = DS_IPC_DEFAULT; > + > + wkup_m3_reset_data_pos(); > + if (am33xx_i2c_sleep_sequence) { > + pos = wkup_m3_copy_data(am33xx_i2c_sleep_sequence, > + i2c_sleep_sequence_sz); Why do we need to copy this data (same constant data) on every iteration? > + /* Lower 16 bits stores offset to sleep sequence */ > + param4 &= ~0xffff; > + param4 |= pos; > + } > + > + if (am33xx_i2c_wake_sequence) { > + pos = wkup_m3_copy_data(am33xx_i2c_wake_sequence, > + i2c_wake_sequence_sz); > + /* Upper 16 bits stores offset to wake sequence */ > + param4 &= ~0xffff0000; > + param4 |= pos << 16; > + } > + Seems above entire change can be done only once. > am33xx_pm->ipc.sleep_mode = IPC_CMD_DS0; > am33xx_pm->ipc.param1 = DS_IPC_DEFAULT; > am33xx_pm->ipc.param2 = DS_IPC_DEFAULT; > + am33xx_pm->ipc.param4 = param4; > > am33xx_pm_ipc_cmd(&am33xx_pm->ipc); > > @@ -386,6 +413,62 @@ static int __init am33xx_map_emif(void) > return 0; > } > > +static int __init am33xx_setup_sleep_sequence(void) > +{ > + int ret; > + int sz; > + const void *prop; > + struct device *dev; > + u32 freq_hz = 100000; Magic number? > + unsigned short freq_khz; > + > + /* > + * We put the device tree node in the I2C controller that will > + * be sending the sequence. i2c1 is the only controller that can > + * be accessed by the firmware as it is the only controller in the > + * WKUP domain. and on which the PMIC sits I believe? > + */ > + dev = omap_device_get_by_hwmod_name("i2c1"); > + if (IS_ERR(dev)) > + return PTR_ERR(dev); > + > + of_property_read_u32(dev->of_node, "clock-frequency", &freq_hz); > + freq_khz = freq_hz / 1000; Magic number? > + > + prop = of_get_property(dev->of_node, "sleep_sequence", &sz); > + if (prop) { > + /* > + * Length is sequence length + 2 bytes for freq_khz, and 1 > + * byte for terminator. > + */ > + am33xx_i2c_sleep_sequence = kzalloc(sz + 3, GFP_KERNEL); > + if (!am33xx_i2c_sleep_sequence) > + return -ENOMEM; > + put_unaligned_le16(freq_khz, am33xx_i2c_sleep_sequence); > + memcpy(am33xx_i2c_sleep_sequence + 2, prop, sz); so, looking at entire code, it seems there is 3 memory space for same data (or 1 original + 2 copy) 1. in DT 2. in am33xx_i2c_[sleep/wake]_sequence 3. in SRAm by call to wkup_m3_copy_data() why not directly copy to SRAM from DT? > + i2c_sleep_sequence_sz = sz + 3; > + } > + > + prop = of_get_property(dev->of_node, "wake_sequence", &sz); > + if (prop) { > + am33xx_i2c_wake_sequence = kzalloc(sz + 3, GFP_KERNEL); > + if (!am33xx_i2c_wake_sequence) { > + ret = -ENOMEM; > + goto cleanup_sleep; > + } > + put_unaligned_le16(freq_khz, am33xx_i2c_sleep_sequence); > + memcpy(am33xx_i2c_wake_sequence + 2, prop, sz); > + i2c_wake_sequence_sz = sz + 3; > + } > + > + return 0; > + > +cleanup_sleep: > + kfree(am33xx_i2c_sleep_sequence); > + am33xx_i2c_sleep_sequence = NULL; > + return ret; > +} > + > int __init am33xx_pm_init(void) > { > int ret; > @@ -451,6 +534,12 @@ int __init am33xx_pm_init(void) > } > } > > + ret = am33xx_setup_sleep_sequence(); > + if (ret) { > + pr_err("Error fetching I2C sleep/wake sequence\n"); > + goto err; > + } > + > (void) clkdm_for_each(omap_pm_clkdms_setup, NULL); > > /* CEFUSE domain can be turned off post bootup */ > diff --git a/arch/arm/mach-omap2/pm33xx.h b/arch/arm/mach-omap2/pm33xx.h > index befdd11..d0f08a5 100644 > --- a/arch/arm/mach-omap2/pm33xx.h > +++ b/arch/arm/mach-omap2/pm33xx.h > @@ -52,6 +52,8 @@ struct forced_standby_module { > }; > > int wkup_m3_copy_code(const u8 *data, size_t size); > +void wkup_m3_reset_data_pos(void); > +int wkup_m3_copy_data(const u8 *data, size_t size); > int wkup_m3_prepare(void); > void wkup_m3_register_txev_handler(void (*txev_handler)(void)); > > diff --git a/arch/arm/mach-omap2/wkup_m3.c b/arch/arm/mach-omap2/wkup_m3.c > index 8eaa7f3..a541de9 100644 > --- a/arch/arm/mach-omap2/wkup_m3.c > +++ b/arch/arm/mach-omap2/wkup_m3.c > @@ -35,6 +35,9 @@ > struct wkup_m3_context { > struct device *dev; > void __iomem *code; > + void __iomem *data; > + void __iomem *data_end; > + size_t data_size; > void (*txev_handler)(void); > }; > > @@ -50,6 +53,30 @@ int wkup_m3_copy_code(const u8 *data, size_t size) > return 0; > } > > +/* > + * This pair of functions allows data to be stuffed into the end of the > + * CM3 data memory. This is currently used for passing the I2C sleep/wake > + * sequences to the firmware. > + */ > + > +/* Clear out the pointer for data stored at the end of DMEM */ > +void wkup_m3_reset_data_pos(void) > +{ > + wkup_m3->data_end = wkup_m3->data + wkup_m3->data_size; > +} > + > +/* > + * Store a block of data at the end of DMEM, return the offset within DMEM > + * that the data is stored at, or -ENOMEM if the data did not fit > + */ > +int wkup_m3_copy_data(const u8 *data, size_t size) > +{ > + if (wkup_m3->data + size > wkup_m3->data_end) > + return -ENOMEM; > + wkup_m3->data_end -= size; > + memcpy_toio(wkup_m3->data_end, data, size); > + return wkup_m3->data_end - wkup_m3->data; > +} > > void wkup_m3_register_txev_handler(void (*txev_handler)(void)) > { > @@ -83,7 +110,7 @@ int wkup_m3_prepare(void) > static int wkup_m3_probe(struct platform_device *pdev) > { > int irq, ret = 0; > - struct resource *mem; > + struct resource *umem, *dmem; > > pm_runtime_enable(&pdev->dev); > > @@ -95,14 +122,21 @@ static int wkup_m3_probe(struct platform_device *pdev) > > irq = platform_get_irq(pdev, 0); > if (!irq) { > - dev_err(wkup_m3->dev, "no irq resource\n"); > + dev_err(&pdev->dev, "no irq resource\n"); unrelated change?. Better to mention this as code cleanup in commit. > + ret = -ENXIO; > + goto err; > + } > + > + umem = platform_get_resource(pdev, IORESOURCE_MEM, 0); > + if (!umem) { > + dev_err(&pdev->dev, "no UMEM resource\n"); > ret = -ENXIO; > goto err; > } > > - mem = platform_get_resource(pdev, IORESOURCE_MEM, 0); > - if (!mem) { > - dev_err(wkup_m3->dev, "no memory resource\n"); > + dmem = platform_get_resource(pdev, IORESOURCE_MEM, 1); > + if (!dmem) { > + dev_err(&pdev->dev, "no DMEM resource\n"); > ret = -ENXIO; > goto err; > } > @@ -116,12 +150,21 @@ static int wkup_m3_probe(struct platform_device *pdev) > > wkup_m3->dev = &pdev->dev; > > - wkup_m3->code = devm_request_and_ioremap(wkup_m3->dev, mem); > + wkup_m3->code = devm_request_and_ioremap(wkup_m3->dev, umem); > + if (!wkup_m3->code) { > + dev_err(wkup_m3->dev, "could not ioremap UMEM\n"); why not use "pdev->dev" here? > + ret = -EADDRNOTAVAIL; > + goto err; > + } > + > + wkup_m3->data = devm_request_and_ioremap(wkup_m3->dev, dmem); > if (!wkup_m3->code) { I believe this is just a copy/paste error. s/code/data > - dev_err(wkup_m3->dev, "could not ioremap\n"); > + dev_err(wkup_m3->dev, "could not ioremap DMEM\n"); same as above. > ret = -EADDRNOTAVAIL; > goto err; > } > + wkup_m3->data_size = resource_size(dmem); > + wkup_m3_reset_data_pos(); > > ret = devm_request_irq(wkup_m3->dev, irq, wkup_m3_txev_handler, > IRQF_DISABLED, "wkup_m3_txev", NULL); > -- 1.8.3.2 -- To unsubscribe from this list: send the line "unsubscribe > linux-omap" in the body of a message to majordomo at vger.kernel.org More > majordomo info at http://vger.kernel.org/majordomo-info.html > ^ permalink raw reply [flat|nested] 84+ messages in thread
* Re: [PATCH v4 1/4] ARM: OMAP2+: AM33XX: I2C Sleep/wake sequence support 2013-08-14 10:18 ` Gururaja Hebbar @ 2013-08-14 22:34 ` Russ Dill -1 siblings, 0 replies; 84+ messages in thread From: Russ Dill @ 2013-08-14 22:34 UTC (permalink / raw) To: Gururaja Hebbar Cc: Kevin Hilman, devicetree, devicetree-discuss, linux-omap, linux-arm-kernel On Wed, Aug 14, 2013 at 3:18 AM, Gururaja Hebbar <gururaja.hebbar@ti.com> wrote: > On 8/14/2013 3:50 AM, Russ Dill wrote: >> Changes since v1: >> * Rebased onto new am335x PM branch >> * Changed to use 5th param register >> >> Changes since v2: >> * Passes I2C bus speed in kHz to M3 firmware >> >> Changes since v3: >> * Rebased to 3.11-rc3, moves some functionality to wkup_m3.c >> * Additional comments >> * Added device-tree binding documentation > > AFAIK, Change logs should come below scissors line (---). > However there was some discussion to keep it in the commit message. > Don't know what happened to it finally. But till date, all revision > patch set has the change log under the scissor line. Will fix is v2. >> >> This patch adds the ability to pass an I2C sleep sequence and wake sequence >> to the Cortex-M3. This is useful for adjusting voltages during sleep that >> cannot be lowered while SDRAM is active. A modified M3 firmware with I2C >> support is required. >> >> Each sequence is a series of I2C transfers in the form: >> >> u8 length | u8 chip address | u8 byte0/reg address | u8 byte 1 | u8 byte n ... >> >> The length indicates the number of bytes to transfer, including the register >> address. The length of each transfer is limited by the I2C buffer size of >> 32 bytes. >> >> The sequences are taken from the i2c1 node in the device tree. The property >> name for the sleep sequence is "sleep_sequence" and the property name for >> the wake sequence is "wake_sequence". Each property should be an array of >> bytes. >> >> No actions are performed if the properties are not present in the device >> tree. >> >> Signed-off-by: Russ Dill <Russ.Dill@ti.com> >> --- >> .../devicetree/bindings/i2c/i2c-suspend-resume.txt | 44 +++++++++++ >> arch/arm/mach-omap2/control.c | 1 + >> arch/arm/mach-omap2/pm33xx.c | 89 ++++++++++++++++++++++ >> arch/arm/mach-omap2/pm33xx.h | 2 + >> arch/arm/mach-omap2/wkup_m3.c | 57 ++++++++++++-- >> 5 files changed, 186 insertions(+), 7 deletions(-) >> create mode 100644 Documentation/devicetree/bindings/i2c/i2c-suspend-resume.txt >> >> diff --git a/Documentation/devicetree/bindings/i2c/i2c-suspend-resume.txt b/Documentation/devicetree/bindings/i2c/i2c-suspend-resume.txt >> new file mode 100644 >> index 0000000..af19372 >> --- /dev/null >> +++ b/Documentation/devicetree/bindings/i2c/i2c-suspend-resume.txt >> @@ -0,0 +1,44 @@ >> +I2C suspend/resume sequences >> + >> +This provides the ability for a simple I2C sequence to be written at >> +suspend time and resume time. This is for sequences that cannot be written >> +by the I2C bus driver for reasons such as needing to be run from SRAM >> +or needing to be written by firmware. >> + >> +The sequence is composed of messages. Each message contains a length byte, >> +an address byte, and then the message. >> + >> +Optional properties: >> +- sleep_sequence >> + I2C sequence to write during suspend >> + >> +- wake_sequence >> + I2C sequence to write during wake >> + >> +Examples : >> + >> +i2c0: i2c@0 { >> + /* Set OPP50 (0.95V) for VDD core */ >> + sleep_sequence = /bits/ 8 < >> + 0x02 0x24 0x0b 0x6d /* Password unlock 1 */ >> + 0x02 0x24 0x10 0x02 /* Set DCDC3 to 0.95V */ >> + 0x02 0x24 0x0b 0x6d /* Password unlock 2 */ >> + 0x02 0x24 0x10 0x02 /* Set DCDC3 to 0.95V */ >> + 0x02 0x24 0x0b 0x6c /* Password unlock 1 */ >> + 0x02 0x24 0x11 0x86 /* Apply DCDC changes */ >> + 0x02 0x24 0x0b 0x6c /* Password unlock 2 */ >> + 0x02 0x24 0x11 0x86 /* Apply DCDC changes */ >> + >; > > This data is not related to i2c. Right? Then why is it under i2c dt node? > > There is already a wakeup node (wkup_m3) and a pmic node (pmic node for > respective boards). Can't these details go under those nodes? The i2c node was chosen for several reasons. First that the bus speed is included in the message to the CM3 firmware. The bus speed and sequence can then be read from the same device tree node. Second so it's clear which I2C bus this is being sent out on. Including it under the PMIC node would mean that the code would have to search each child of the I2C bus for a sequence and if multiple children had sequences, it would not know in which order to send those sequences out. >> + >> + /* Set OPP100 (1.10V) for VDD core */ >> + wake_sequence = /bits/ 8 < >> + 0x02 0x24 0x0b 0x6d /* Password unlock 1 */ >> + 0x02 0x24 0x10 0x08 /* Set DCDC3 to 1.1V */ >> + 0x02 0x24 0x0b 0x6d /* Password unlock 2 */ >> + 0x02 0x24 0x10 0x08 /* Set DCDC3 to 1.1V */ >> + 0x02 0x24 0x0b 0x6c /* Password unlock 1 */ >> + 0x02 0x24 0x11 0x86 /* Apply DCDC changes */ >> + 0x02 0x24 0x0b 0x6c /* Password unlock 2 */ >> + 0x02 0x24 0x11 0x86 /* Apply DCDC changes */ >> + >; >> +} >> diff --git a/arch/arm/mach-omap2/control.c b/arch/arm/mach-omap2/control.c >> index 934041a..dfbd5f0 100644 >> --- a/arch/arm/mach-omap2/control.c >> +++ b/arch/arm/mach-omap2/control.c >> @@ -639,6 +639,7 @@ void am33xx_pm_ipc_cmd(struct am33xx_ipc_data *data) >> omap_ctrl_writel(data->param1, AM33XX_CONTROL_IPC_MSG_REG2); >> omap_ctrl_writel(data->param2, AM33XX_CONTROL_IPC_MSG_REG3); >> omap_ctrl_writel(data->param3, AM33XX_CONTROL_IPC_MSG_REG4); >> + omap_ctrl_writel(data->param4, AM33XX_CONTROL_IPC_MSG_REG5); >> } >> >> int am33xx_pm_status(void) >> diff --git a/arch/arm/mach-omap2/pm33xx.c b/arch/arm/mach-omap2/pm33xx.c >> index d291c76..8880da3 100644 >> --- a/arch/arm/mach-omap2/pm33xx.c >> +++ b/arch/arm/mach-omap2/pm33xx.c >> @@ -29,6 +29,7 @@ >> #include <linux/ti_emif.h> >> #include <linux/omap-mailbox.h> >> >> +#include <asm/unaligned.h> >> #include <asm/suspend.h> >> #include <asm/proc-fns.h> >> #include <asm/sizes.h> >> @@ -50,6 +51,10 @@ >> static void __iomem *am33xx_emif_base; >> static struct powerdomain *cefuse_pwrdm, *gfx_pwrdm, *per_pwrdm, *mpu_pwrdm; >> static struct clockdomain *gfx_l4ls_clkdm; >> +static char *am33xx_i2c_sleep_sequence; >> +static char *am33xx_i2c_wake_sequence; >> +static size_t i2c_sleep_sequence_sz; >> +static size_t i2c_wake_sequence_sz; >> >> struct wakeup_src wakeups[] = { >> {.irq_nr = 35, .src = "USB0_PHY"}, >> @@ -232,12 +237,34 @@ static void am33xx_m3_state_machine_reset(void) >> static int am33xx_pm_begin(suspend_state_t state) >> { >> int i; >> + unsigned long param4; >> + int pos; >> >> cpu_idle_poll_ctrl(true); >> >> + param4 = DS_IPC_DEFAULT; >> + >> + wkup_m3_reset_data_pos(); >> + if (am33xx_i2c_sleep_sequence) { >> + pos = wkup_m3_copy_data(am33xx_i2c_sleep_sequence, >> + i2c_sleep_sequence_sz); > > Why do we need to copy this data (same constant data) on every iteration? Because the CM3 firmware is reset after each suspend/resume cycle. The firmware reset handler reinitializes the DMEM. >> + /* Lower 16 bits stores offset to sleep sequence */ >> + param4 &= ~0xffff; >> + param4 |= pos; >> + } >> + >> + if (am33xx_i2c_wake_sequence) { >> + pos = wkup_m3_copy_data(am33xx_i2c_wake_sequence, >> + i2c_wake_sequence_sz); >> + /* Upper 16 bits stores offset to wake sequence */ >> + param4 &= ~0xffff0000; >> + param4 |= pos << 16; >> + } >> + > > Seems above entire change can be done only once. > >> am33xx_pm->ipc.sleep_mode = IPC_CMD_DS0; >> am33xx_pm->ipc.param1 = DS_IPC_DEFAULT; >> am33xx_pm->ipc.param2 = DS_IPC_DEFAULT; >> + am33xx_pm->ipc.param4 = param4; >> >> am33xx_pm_ipc_cmd(&am33xx_pm->ipc); >> >> @@ -386,6 +413,62 @@ static int __init am33xx_map_emif(void) >> return 0; >> } >> >> +static int __init am33xx_setup_sleep_sequence(void) >> +{ >> + int ret; >> + int sz; >> + const void *prop; >> + struct device *dev; >> + u32 freq_hz = 100000; > > Magic number? It's taken from drivers/i2c/busses/i2c-omap.c u32 freq = 100000; /* default to 100000 Hz */ I'll add a comment to that effect. >> + unsigned short freq_khz; >> + >> + /* >> + * We put the device tree node in the I2C controller that will >> + * be sending the sequence. i2c1 is the only controller that can >> + * be accessed by the firmware as it is the only controller in the >> + * WKUP domain. > > and on which the PMIC sits I believe? Yes, but this code is designed not to be PMIC specific as one could chose to regulate VDD_CORE with any PMIC, or even with a standalone I2C controlled regulator. >> + */ >> + dev = omap_device_get_by_hwmod_name("i2c1"); >> + if (IS_ERR(dev)) >> + return PTR_ERR(dev); >> + >> + of_property_read_u32(dev->of_node, "clock-frequency", &freq_hz); >> + freq_khz = freq_hz / 1000; > > Magic number? Nah, converting between metric prefixes this way is pretty common in the kernel. >> + >> + prop = of_get_property(dev->of_node, "sleep_sequence", &sz); >> + if (prop) { >> + /* >> + * Length is sequence length + 2 bytes for freq_khz, and 1 >> + * byte for terminator. >> + */ >> + am33xx_i2c_sleep_sequence = kzalloc(sz + 3, GFP_KERNEL); >> + if (!am33xx_i2c_sleep_sequence) >> + return -ENOMEM; >> + put_unaligned_le16(freq_khz, am33xx_i2c_sleep_sequence); >> + memcpy(am33xx_i2c_sleep_sequence + 2, prop, sz); > > so, looking at entire code, it seems there is 3 memory space for same > data (or 1 original + 2 copy) > > 1. in DT > 2. in am33xx_i2c_[sleep/wake]_sequence > 3. in SRAm by call to wkup_m3_copy_data() > > why not directly copy to SRAM from DT? As pointed out above, the firmware reset handler would wipe it out. >> + i2c_sleep_sequence_sz = sz + 3; >> + } >> + >> + prop = of_get_property(dev->of_node, "wake_sequence", &sz); >> + if (prop) { >> + am33xx_i2c_wake_sequence = kzalloc(sz + 3, GFP_KERNEL); >> + if (!am33xx_i2c_wake_sequence) { >> + ret = -ENOMEM; >> + goto cleanup_sleep; >> + } >> + put_unaligned_le16(freq_khz, am33xx_i2c_sleep_sequence); >> + memcpy(am33xx_i2c_wake_sequence + 2, prop, sz); >> + i2c_wake_sequence_sz = sz + 3; >> + } >> + >> + return 0; >> + >> +cleanup_sleep: >> + kfree(am33xx_i2c_sleep_sequence); >> + am33xx_i2c_sleep_sequence = NULL; >> + return ret; >> +} >> + >> int __init am33xx_pm_init(void) >> { >> int ret; >> @@ -451,6 +534,12 @@ int __init am33xx_pm_init(void) >> } >> } >> >> + ret = am33xx_setup_sleep_sequence(); >> + if (ret) { >> + pr_err("Error fetching I2C sleep/wake sequence\n"); >> + goto err; >> + } >> + >> (void) clkdm_for_each(omap_pm_clkdms_setup, NULL); >> >> /* CEFUSE domain can be turned off post bootup */ >> diff --git a/arch/arm/mach-omap2/pm33xx.h b/arch/arm/mach-omap2/pm33xx.h >> index befdd11..d0f08a5 100644 >> --- a/arch/arm/mach-omap2/pm33xx.h >> +++ b/arch/arm/mach-omap2/pm33xx.h >> @@ -52,6 +52,8 @@ struct forced_standby_module { >> }; >> >> int wkup_m3_copy_code(const u8 *data, size_t size); >> +void wkup_m3_reset_data_pos(void); >> +int wkup_m3_copy_data(const u8 *data, size_t size); >> int wkup_m3_prepare(void); >> void wkup_m3_register_txev_handler(void (*txev_handler)(void)); >> >> diff --git a/arch/arm/mach-omap2/wkup_m3.c b/arch/arm/mach-omap2/wkup_m3.c >> index 8eaa7f3..a541de9 100644 >> --- a/arch/arm/mach-omap2/wkup_m3.c >> +++ b/arch/arm/mach-omap2/wkup_m3.c >> @@ -35,6 +35,9 @@ >> struct wkup_m3_context { >> struct device *dev; >> void __iomem *code; >> + void __iomem *data; >> + void __iomem *data_end; >> + size_t data_size; >> void (*txev_handler)(void); >> }; >> >> @@ -50,6 +53,30 @@ int wkup_m3_copy_code(const u8 *data, size_t size) >> return 0; >> } >> >> +/* >> + * This pair of functions allows data to be stuffed into the end of the >> + * CM3 data memory. This is currently used for passing the I2C sleep/wake >> + * sequences to the firmware. >> + */ >> + >> +/* Clear out the pointer for data stored at the end of DMEM */ >> +void wkup_m3_reset_data_pos(void) >> +{ >> + wkup_m3->data_end = wkup_m3->data + wkup_m3->data_size; >> +} >> + >> +/* >> + * Store a block of data at the end of DMEM, return the offset within DMEM >> + * that the data is stored at, or -ENOMEM if the data did not fit >> + */ >> +int wkup_m3_copy_data(const u8 *data, size_t size) >> +{ >> + if (wkup_m3->data + size > wkup_m3->data_end) >> + return -ENOMEM; >> + wkup_m3->data_end -= size; >> + memcpy_toio(wkup_m3->data_end, data, size); >> + return wkup_m3->data_end - wkup_m3->data; >> +} >> >> void wkup_m3_register_txev_handler(void (*txev_handler)(void)) >> { >> @@ -83,7 +110,7 @@ int wkup_m3_prepare(void) >> static int wkup_m3_probe(struct platform_device *pdev) >> { >> int irq, ret = 0; >> - struct resource *mem; >> + struct resource *umem, *dmem; >> >> pm_runtime_enable(&pdev->dev); >> >> @@ -95,14 +122,21 @@ static int wkup_m3_probe(struct platform_device *pdev) >> >> irq = platform_get_irq(pdev, 0); >> if (!irq) { >> - dev_err(wkup_m3->dev, "no irq resource\n"); >> + dev_err(&pdev->dev, "no irq resource\n"); > > unrelated change?. Better to mention this as code cleanup in commit. Will add a comment to that effect, the underlying error should be fixed in the next suspend/resume patch though. >> + ret = -ENXIO; >> + goto err; >> + } >> + >> + umem = platform_get_resource(pdev, IORESOURCE_MEM, 0); >> + if (!umem) { >> + dev_err(&pdev->dev, "no UMEM resource\n"); >> ret = -ENXIO; >> goto err; >> } >> >> - mem = platform_get_resource(pdev, IORESOURCE_MEM, 0); >> - if (!mem) { >> - dev_err(wkup_m3->dev, "no memory resource\n"); >> + dmem = platform_get_resource(pdev, IORESOURCE_MEM, 1); >> + if (!dmem) { >> + dev_err(&pdev->dev, "no DMEM resource\n"); >> ret = -ENXIO; >> goto err; >> } >> @@ -116,12 +150,21 @@ static int wkup_m3_probe(struct platform_device *pdev) >> >> wkup_m3->dev = &pdev->dev; >> >> - wkup_m3->code = devm_request_and_ioremap(wkup_m3->dev, mem); >> + wkup_m3->code = devm_request_and_ioremap(wkup_m3->dev, umem); >> + if (!wkup_m3->code) { >> + dev_err(wkup_m3->dev, "could not ioremap UMEM\n"); > > why not use "pdev->dev" here? Either one works >> + ret = -EADDRNOTAVAIL; >> + goto err; >> + } >> + >> + wkup_m3->data = devm_request_and_ioremap(wkup_m3->dev, dmem); >> if (!wkup_m3->code) { > > I believe this is just a copy/paste error. s/code/data Doh, thanks! >> - dev_err(wkup_m3->dev, "could not ioremap\n"); >> + dev_err(wkup_m3->dev, "could not ioremap DMEM\n"); > > same as above. > >> ret = -EADDRNOTAVAIL; >> goto err; >> } >> + wkup_m3->data_size = resource_size(dmem); >> + wkup_m3_reset_data_pos(); >> >> ret = devm_request_irq(wkup_m3->dev, irq, wkup_m3_txev_handler, >> IRQF_DISABLED, "wkup_m3_txev", NULL); >> -- 1.8.3.2 -- To unsubscribe from this list: send the line "unsubscribe >> linux-omap" in the body of a message to majordomo@vger.kernel.org More >> majordomo info at http://vger.kernel.org/majordomo-info.html >> > > > _______________________________________________ > linux-arm-kernel mailing list > linux-arm-kernel@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 84+ messages in thread
* [PATCH v4 1/4] ARM: OMAP2+: AM33XX: I2C Sleep/wake sequence support @ 2013-08-14 22:34 ` Russ Dill 0 siblings, 0 replies; 84+ messages in thread From: Russ Dill @ 2013-08-14 22:34 UTC (permalink / raw) To: linux-arm-kernel On Wed, Aug 14, 2013 at 3:18 AM, Gururaja Hebbar <gururaja.hebbar@ti.com> wrote: > On 8/14/2013 3:50 AM, Russ Dill wrote: >> Changes since v1: >> * Rebased onto new am335x PM branch >> * Changed to use 5th param register >> >> Changes since v2: >> * Passes I2C bus speed in kHz to M3 firmware >> >> Changes since v3: >> * Rebased to 3.11-rc3, moves some functionality to wkup_m3.c >> * Additional comments >> * Added device-tree binding documentation > > AFAIK, Change logs should come below scissors line (---). > However there was some discussion to keep it in the commit message. > Don't know what happened to it finally. But till date, all revision > patch set has the change log under the scissor line. Will fix is v2. >> >> This patch adds the ability to pass an I2C sleep sequence and wake sequence >> to the Cortex-M3. This is useful for adjusting voltages during sleep that >> cannot be lowered while SDRAM is active. A modified M3 firmware with I2C >> support is required. >> >> Each sequence is a series of I2C transfers in the form: >> >> u8 length | u8 chip address | u8 byte0/reg address | u8 byte 1 | u8 byte n ... >> >> The length indicates the number of bytes to transfer, including the register >> address. The length of each transfer is limited by the I2C buffer size of >> 32 bytes. >> >> The sequences are taken from the i2c1 node in the device tree. The property >> name for the sleep sequence is "sleep_sequence" and the property name for >> the wake sequence is "wake_sequence". Each property should be an array of >> bytes. >> >> No actions are performed if the properties are not present in the device >> tree. >> >> Signed-off-by: Russ Dill <Russ.Dill@ti.com> >> --- >> .../devicetree/bindings/i2c/i2c-suspend-resume.txt | 44 +++++++++++ >> arch/arm/mach-omap2/control.c | 1 + >> arch/arm/mach-omap2/pm33xx.c | 89 ++++++++++++++++++++++ >> arch/arm/mach-omap2/pm33xx.h | 2 + >> arch/arm/mach-omap2/wkup_m3.c | 57 ++++++++++++-- >> 5 files changed, 186 insertions(+), 7 deletions(-) >> create mode 100644 Documentation/devicetree/bindings/i2c/i2c-suspend-resume.txt >> >> diff --git a/Documentation/devicetree/bindings/i2c/i2c-suspend-resume.txt b/Documentation/devicetree/bindings/i2c/i2c-suspend-resume.txt >> new file mode 100644 >> index 0000000..af19372 >> --- /dev/null >> +++ b/Documentation/devicetree/bindings/i2c/i2c-suspend-resume.txt >> @@ -0,0 +1,44 @@ >> +I2C suspend/resume sequences >> + >> +This provides the ability for a simple I2C sequence to be written at >> +suspend time and resume time. This is for sequences that cannot be written >> +by the I2C bus driver for reasons such as needing to be run from SRAM >> +or needing to be written by firmware. >> + >> +The sequence is composed of messages. Each message contains a length byte, >> +an address byte, and then the message. >> + >> +Optional properties: >> +- sleep_sequence >> + I2C sequence to write during suspend >> + >> +- wake_sequence >> + I2C sequence to write during wake >> + >> +Examples : >> + >> +i2c0: i2c at 0 { >> + /* Set OPP50 (0.95V) for VDD core */ >> + sleep_sequence = /bits/ 8 < >> + 0x02 0x24 0x0b 0x6d /* Password unlock 1 */ >> + 0x02 0x24 0x10 0x02 /* Set DCDC3 to 0.95V */ >> + 0x02 0x24 0x0b 0x6d /* Password unlock 2 */ >> + 0x02 0x24 0x10 0x02 /* Set DCDC3 to 0.95V */ >> + 0x02 0x24 0x0b 0x6c /* Password unlock 1 */ >> + 0x02 0x24 0x11 0x86 /* Apply DCDC changes */ >> + 0x02 0x24 0x0b 0x6c /* Password unlock 2 */ >> + 0x02 0x24 0x11 0x86 /* Apply DCDC changes */ >> + >; > > This data is not related to i2c. Right? Then why is it under i2c dt node? > > There is already a wakeup node (wkup_m3) and a pmic node (pmic node for > respective boards). Can't these details go under those nodes? The i2c node was chosen for several reasons. First that the bus speed is included in the message to the CM3 firmware. The bus speed and sequence can then be read from the same device tree node. Second so it's clear which I2C bus this is being sent out on. Including it under the PMIC node would mean that the code would have to search each child of the I2C bus for a sequence and if multiple children had sequences, it would not know in which order to send those sequences out. >> + >> + /* Set OPP100 (1.10V) for VDD core */ >> + wake_sequence = /bits/ 8 < >> + 0x02 0x24 0x0b 0x6d /* Password unlock 1 */ >> + 0x02 0x24 0x10 0x08 /* Set DCDC3 to 1.1V */ >> + 0x02 0x24 0x0b 0x6d /* Password unlock 2 */ >> + 0x02 0x24 0x10 0x08 /* Set DCDC3 to 1.1V */ >> + 0x02 0x24 0x0b 0x6c /* Password unlock 1 */ >> + 0x02 0x24 0x11 0x86 /* Apply DCDC changes */ >> + 0x02 0x24 0x0b 0x6c /* Password unlock 2 */ >> + 0x02 0x24 0x11 0x86 /* Apply DCDC changes */ >> + >; >> +} >> diff --git a/arch/arm/mach-omap2/control.c b/arch/arm/mach-omap2/control.c >> index 934041a..dfbd5f0 100644 >> --- a/arch/arm/mach-omap2/control.c >> +++ b/arch/arm/mach-omap2/control.c >> @@ -639,6 +639,7 @@ void am33xx_pm_ipc_cmd(struct am33xx_ipc_data *data) >> omap_ctrl_writel(data->param1, AM33XX_CONTROL_IPC_MSG_REG2); >> omap_ctrl_writel(data->param2, AM33XX_CONTROL_IPC_MSG_REG3); >> omap_ctrl_writel(data->param3, AM33XX_CONTROL_IPC_MSG_REG4); >> + omap_ctrl_writel(data->param4, AM33XX_CONTROL_IPC_MSG_REG5); >> } >> >> int am33xx_pm_status(void) >> diff --git a/arch/arm/mach-omap2/pm33xx.c b/arch/arm/mach-omap2/pm33xx.c >> index d291c76..8880da3 100644 >> --- a/arch/arm/mach-omap2/pm33xx.c >> +++ b/arch/arm/mach-omap2/pm33xx.c >> @@ -29,6 +29,7 @@ >> #include <linux/ti_emif.h> >> #include <linux/omap-mailbox.h> >> >> +#include <asm/unaligned.h> >> #include <asm/suspend.h> >> #include <asm/proc-fns.h> >> #include <asm/sizes.h> >> @@ -50,6 +51,10 @@ >> static void __iomem *am33xx_emif_base; >> static struct powerdomain *cefuse_pwrdm, *gfx_pwrdm, *per_pwrdm, *mpu_pwrdm; >> static struct clockdomain *gfx_l4ls_clkdm; >> +static char *am33xx_i2c_sleep_sequence; >> +static char *am33xx_i2c_wake_sequence; >> +static size_t i2c_sleep_sequence_sz; >> +static size_t i2c_wake_sequence_sz; >> >> struct wakeup_src wakeups[] = { >> {.irq_nr = 35, .src = "USB0_PHY"}, >> @@ -232,12 +237,34 @@ static void am33xx_m3_state_machine_reset(void) >> static int am33xx_pm_begin(suspend_state_t state) >> { >> int i; >> + unsigned long param4; >> + int pos; >> >> cpu_idle_poll_ctrl(true); >> >> + param4 = DS_IPC_DEFAULT; >> + >> + wkup_m3_reset_data_pos(); >> + if (am33xx_i2c_sleep_sequence) { >> + pos = wkup_m3_copy_data(am33xx_i2c_sleep_sequence, >> + i2c_sleep_sequence_sz); > > Why do we need to copy this data (same constant data) on every iteration? Because the CM3 firmware is reset after each suspend/resume cycle. The firmware reset handler reinitializes the DMEM. >> + /* Lower 16 bits stores offset to sleep sequence */ >> + param4 &= ~0xffff; >> + param4 |= pos; >> + } >> + >> + if (am33xx_i2c_wake_sequence) { >> + pos = wkup_m3_copy_data(am33xx_i2c_wake_sequence, >> + i2c_wake_sequence_sz); >> + /* Upper 16 bits stores offset to wake sequence */ >> + param4 &= ~0xffff0000; >> + param4 |= pos << 16; >> + } >> + > > Seems above entire change can be done only once. > >> am33xx_pm->ipc.sleep_mode = IPC_CMD_DS0; >> am33xx_pm->ipc.param1 = DS_IPC_DEFAULT; >> am33xx_pm->ipc.param2 = DS_IPC_DEFAULT; >> + am33xx_pm->ipc.param4 = param4; >> >> am33xx_pm_ipc_cmd(&am33xx_pm->ipc); >> >> @@ -386,6 +413,62 @@ static int __init am33xx_map_emif(void) >> return 0; >> } >> >> +static int __init am33xx_setup_sleep_sequence(void) >> +{ >> + int ret; >> + int sz; >> + const void *prop; >> + struct device *dev; >> + u32 freq_hz = 100000; > > Magic number? It's taken from drivers/i2c/busses/i2c-omap.c u32 freq = 100000; /* default to 100000 Hz */ I'll add a comment to that effect. >> + unsigned short freq_khz; >> + >> + /* >> + * We put the device tree node in the I2C controller that will >> + * be sending the sequence. i2c1 is the only controller that can >> + * be accessed by the firmware as it is the only controller in the >> + * WKUP domain. > > and on which the PMIC sits I believe? Yes, but this code is designed not to be PMIC specific as one could chose to regulate VDD_CORE with any PMIC, or even with a standalone I2C controlled regulator. >> + */ >> + dev = omap_device_get_by_hwmod_name("i2c1"); >> + if (IS_ERR(dev)) >> + return PTR_ERR(dev); >> + >> + of_property_read_u32(dev->of_node, "clock-frequency", &freq_hz); >> + freq_khz = freq_hz / 1000; > > Magic number? Nah, converting between metric prefixes this way is pretty common in the kernel. >> + >> + prop = of_get_property(dev->of_node, "sleep_sequence", &sz); >> + if (prop) { >> + /* >> + * Length is sequence length + 2 bytes for freq_khz, and 1 >> + * byte for terminator. >> + */ >> + am33xx_i2c_sleep_sequence = kzalloc(sz + 3, GFP_KERNEL); >> + if (!am33xx_i2c_sleep_sequence) >> + return -ENOMEM; >> + put_unaligned_le16(freq_khz, am33xx_i2c_sleep_sequence); >> + memcpy(am33xx_i2c_sleep_sequence + 2, prop, sz); > > so, looking at entire code, it seems there is 3 memory space for same > data (or 1 original + 2 copy) > > 1. in DT > 2. in am33xx_i2c_[sleep/wake]_sequence > 3. in SRAm by call to wkup_m3_copy_data() > > why not directly copy to SRAM from DT? As pointed out above, the firmware reset handler would wipe it out. >> + i2c_sleep_sequence_sz = sz + 3; >> + } >> + >> + prop = of_get_property(dev->of_node, "wake_sequence", &sz); >> + if (prop) { >> + am33xx_i2c_wake_sequence = kzalloc(sz + 3, GFP_KERNEL); >> + if (!am33xx_i2c_wake_sequence) { >> + ret = -ENOMEM; >> + goto cleanup_sleep; >> + } >> + put_unaligned_le16(freq_khz, am33xx_i2c_sleep_sequence); >> + memcpy(am33xx_i2c_wake_sequence + 2, prop, sz); >> + i2c_wake_sequence_sz = sz + 3; >> + } >> + >> + return 0; >> + >> +cleanup_sleep: >> + kfree(am33xx_i2c_sleep_sequence); >> + am33xx_i2c_sleep_sequence = NULL; >> + return ret; >> +} >> + >> int __init am33xx_pm_init(void) >> { >> int ret; >> @@ -451,6 +534,12 @@ int __init am33xx_pm_init(void) >> } >> } >> >> + ret = am33xx_setup_sleep_sequence(); >> + if (ret) { >> + pr_err("Error fetching I2C sleep/wake sequence\n"); >> + goto err; >> + } >> + >> (void) clkdm_for_each(omap_pm_clkdms_setup, NULL); >> >> /* CEFUSE domain can be turned off post bootup */ >> diff --git a/arch/arm/mach-omap2/pm33xx.h b/arch/arm/mach-omap2/pm33xx.h >> index befdd11..d0f08a5 100644 >> --- a/arch/arm/mach-omap2/pm33xx.h >> +++ b/arch/arm/mach-omap2/pm33xx.h >> @@ -52,6 +52,8 @@ struct forced_standby_module { >> }; >> >> int wkup_m3_copy_code(const u8 *data, size_t size); >> +void wkup_m3_reset_data_pos(void); >> +int wkup_m3_copy_data(const u8 *data, size_t size); >> int wkup_m3_prepare(void); >> void wkup_m3_register_txev_handler(void (*txev_handler)(void)); >> >> diff --git a/arch/arm/mach-omap2/wkup_m3.c b/arch/arm/mach-omap2/wkup_m3.c >> index 8eaa7f3..a541de9 100644 >> --- a/arch/arm/mach-omap2/wkup_m3.c >> +++ b/arch/arm/mach-omap2/wkup_m3.c >> @@ -35,6 +35,9 @@ >> struct wkup_m3_context { >> struct device *dev; >> void __iomem *code; >> + void __iomem *data; >> + void __iomem *data_end; >> + size_t data_size; >> void (*txev_handler)(void); >> }; >> >> @@ -50,6 +53,30 @@ int wkup_m3_copy_code(const u8 *data, size_t size) >> return 0; >> } >> >> +/* >> + * This pair of functions allows data to be stuffed into the end of the >> + * CM3 data memory. This is currently used for passing the I2C sleep/wake >> + * sequences to the firmware. >> + */ >> + >> +/* Clear out the pointer for data stored at the end of DMEM */ >> +void wkup_m3_reset_data_pos(void) >> +{ >> + wkup_m3->data_end = wkup_m3->data + wkup_m3->data_size; >> +} >> + >> +/* >> + * Store a block of data at the end of DMEM, return the offset within DMEM >> + * that the data is stored at, or -ENOMEM if the data did not fit >> + */ >> +int wkup_m3_copy_data(const u8 *data, size_t size) >> +{ >> + if (wkup_m3->data + size > wkup_m3->data_end) >> + return -ENOMEM; >> + wkup_m3->data_end -= size; >> + memcpy_toio(wkup_m3->data_end, data, size); >> + return wkup_m3->data_end - wkup_m3->data; >> +} >> >> void wkup_m3_register_txev_handler(void (*txev_handler)(void)) >> { >> @@ -83,7 +110,7 @@ int wkup_m3_prepare(void) >> static int wkup_m3_probe(struct platform_device *pdev) >> { >> int irq, ret = 0; >> - struct resource *mem; >> + struct resource *umem, *dmem; >> >> pm_runtime_enable(&pdev->dev); >> >> @@ -95,14 +122,21 @@ static int wkup_m3_probe(struct platform_device *pdev) >> >> irq = platform_get_irq(pdev, 0); >> if (!irq) { >> - dev_err(wkup_m3->dev, "no irq resource\n"); >> + dev_err(&pdev->dev, "no irq resource\n"); > > unrelated change?. Better to mention this as code cleanup in commit. Will add a comment to that effect, the underlying error should be fixed in the next suspend/resume patch though. >> + ret = -ENXIO; >> + goto err; >> + } >> + >> + umem = platform_get_resource(pdev, IORESOURCE_MEM, 0); >> + if (!umem) { >> + dev_err(&pdev->dev, "no UMEM resource\n"); >> ret = -ENXIO; >> goto err; >> } >> >> - mem = platform_get_resource(pdev, IORESOURCE_MEM, 0); >> - if (!mem) { >> - dev_err(wkup_m3->dev, "no memory resource\n"); >> + dmem = platform_get_resource(pdev, IORESOURCE_MEM, 1); >> + if (!dmem) { >> + dev_err(&pdev->dev, "no DMEM resource\n"); >> ret = -ENXIO; >> goto err; >> } >> @@ -116,12 +150,21 @@ static int wkup_m3_probe(struct platform_device *pdev) >> >> wkup_m3->dev = &pdev->dev; >> >> - wkup_m3->code = devm_request_and_ioremap(wkup_m3->dev, mem); >> + wkup_m3->code = devm_request_and_ioremap(wkup_m3->dev, umem); >> + if (!wkup_m3->code) { >> + dev_err(wkup_m3->dev, "could not ioremap UMEM\n"); > > why not use "pdev->dev" here? Either one works >> + ret = -EADDRNOTAVAIL; >> + goto err; >> + } >> + >> + wkup_m3->data = devm_request_and_ioremap(wkup_m3->dev, dmem); >> if (!wkup_m3->code) { > > I believe this is just a copy/paste error. s/code/data Doh, thanks! >> - dev_err(wkup_m3->dev, "could not ioremap\n"); >> + dev_err(wkup_m3->dev, "could not ioremap DMEM\n"); > > same as above. > >> ret = -EADDRNOTAVAIL; >> goto err; >> } >> + wkup_m3->data_size = resource_size(dmem); >> + wkup_m3_reset_data_pos(); >> >> ret = devm_request_irq(wkup_m3->dev, irq, wkup_m3_txev_handler, >> IRQF_DISABLED, "wkup_m3_txev", NULL); >> -- 1.8.3.2 -- To unsubscribe from this list: send the line "unsubscribe >> linux-omap" in the body of a message to majordomo at vger.kernel.org More >> majordomo info at http://vger.kernel.org/majordomo-info.html >> > > > _______________________________________________ > linux-arm-kernel mailing list > linux-arm-kernel at lists.infradead.org > http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 84+ messages in thread
* Re: [PATCH v4 1/4] ARM: OMAP2+: AM33XX: I2C Sleep/wake sequence support 2013-08-14 22:34 ` Russ Dill @ 2013-08-16 7:16 ` Gururaja Hebbar -1 siblings, 0 replies; 84+ messages in thread From: Gururaja Hebbar @ 2013-08-16 7:16 UTC (permalink / raw) To: Russ Dill Cc: Kevin Hilman, devicetree, devicetree-discuss, linux-omap, linux-arm-kernel On 8/15/2013 4:04 AM, Russ Dill wrote: > On Wed, Aug 14, 2013 at 3:18 AM, Gururaja Hebbar <gururaja.hebbar@ti.com> wrote: >> On 8/14/2013 3:50 AM, Russ Dill wrote: >>> Changes since v1: >>> * Rebased onto new am335x PM branch >>> * Changed to use 5th param register >>> >>> Changes since v2: >>> * Passes I2C bus speed in kHz to M3 firmware >>> >>> Changes since v3: >>> * Rebased to 3.11-rc3, moves some functionality to wkup_m3.c >>> * Additional comments >>> * Added device-tree binding documentation >> >> AFAIK, Change logs should come below scissors line (---). >> However there was some discussion to keep it in the commit message. >> Don't know what happened to it finally. But till date, all revision >> patch set has the change log under the scissor line. > > Will fix is v2. > >>> >>> This patch adds the ability to pass an I2C sleep sequence and wake sequence >>> to the Cortex-M3. This is useful for adjusting voltages during sleep that >>> cannot be lowered while SDRAM is active. A modified M3 firmware with I2C >>> support is required. >>> >>> Each sequence is a series of I2C transfers in the form: >>> >>> u8 length | u8 chip address | u8 byte0/reg address | u8 byte 1 | u8 byte n ... >>> >>> The length indicates the number of bytes to transfer, including the register >>> address. The length of each transfer is limited by the I2C buffer size of >>> 32 bytes. >>> >>> The sequences are taken from the i2c1 node in the device tree. The property >>> name for the sleep sequence is "sleep_sequence" and the property name for >>> the wake sequence is "wake_sequence". Each property should be an array of >>> bytes. >>> >>> No actions are performed if the properties are not present in the device >>> tree. >>> >>> Signed-off-by: Russ Dill <Russ.Dill@ti.com> >>> --- >>> .../devicetree/bindings/i2c/i2c-suspend-resume.txt | 44 +++++++++++ >>> arch/arm/mach-omap2/control.c | 1 + >>> arch/arm/mach-omap2/pm33xx.c | 89 ++++++++++++++++++++++ >>> arch/arm/mach-omap2/pm33xx.h | 2 + >>> arch/arm/mach-omap2/wkup_m3.c | 57 ++++++++++++-- >>> 5 files changed, 186 insertions(+), 7 deletions(-) >>> create mode 100644 Documentation/devicetree/bindings/i2c/i2c-suspend-resume.txt >>> >>> diff --git a/Documentation/devicetree/bindings/i2c/i2c-suspend-resume.txt b/Documentation/devicetree/bindings/i2c/i2c-suspend-resume.txt >>> new file mode 100644 >>> index 0000000..af19372 >>> --- /dev/null >>> +++ b/Documentation/devicetree/bindings/i2c/i2c-suspend-resume.txt >>> @@ -0,0 +1,44 @@ >>> +I2C suspend/resume sequences >>> + >>> +This provides the ability for a simple I2C sequence to be written at >>> +suspend time and resume time. This is for sequences that cannot be written >>> +by the I2C bus driver for reasons such as needing to be run from SRAM >>> +or needing to be written by firmware. >>> + >>> +The sequence is composed of messages. Each message contains a length byte, >>> +an address byte, and then the message. >>> + >>> +Optional properties: >>> +- sleep_sequence >>> + I2C sequence to write during suspend >>> + >>> +- wake_sequence >>> + I2C sequence to write during wake >>> + >>> +Examples : >>> + >>> +i2c0: i2c@0 { >>> + /* Set OPP50 (0.95V) for VDD core */ >>> + sleep_sequence = /bits/ 8 < >>> + 0x02 0x24 0x0b 0x6d /* Password unlock 1 */ >>> + 0x02 0x24 0x10 0x02 /* Set DCDC3 to 0.95V */ >>> + 0x02 0x24 0x0b 0x6d /* Password unlock 2 */ >>> + 0x02 0x24 0x10 0x02 /* Set DCDC3 to 0.95V */ >>> + 0x02 0x24 0x0b 0x6c /* Password unlock 1 */ >>> + 0x02 0x24 0x11 0x86 /* Apply DCDC changes */ >>> + 0x02 0x24 0x0b 0x6c /* Password unlock 2 */ >>> + 0x02 0x24 0x11 0x86 /* Apply DCDC changes */ >>> + >; >> >> This data is not related to i2c. Right? Then why is it under i2c dt node? >> >> There is already a wakeup node (wkup_m3) and a pmic node (pmic node for >> respective boards). Can't these details go under those nodes? > > The i2c node was chosen for several reasons. First that the bus speed > is included in the message to the CM3 firmware. The bus speed and > sequence can then be read from the same device tree node. Second so > it's clear which I2C bus this is being sent out on. Including it under > the PMIC node would mean that the code would have to search each child > of the I2C bus for a sequence and if multiple children had sequences, > it would not know in which order to send those sequences out. Agreed > >>> + >>> + /* Set OPP100 (1.10V) for VDD core */ >>> + wake_sequence = /bits/ 8 < >>> + 0x02 0x24 0x0b 0x6d /* Password unlock 1 */ >>> + 0x02 0x24 0x10 0x08 /* Set DCDC3 to 1.1V */ >>> + 0x02 0x24 0x0b 0x6d /* Password unlock 2 */ >>> + 0x02 0x24 0x10 0x08 /* Set DCDC3 to 1.1V */ >>> + 0x02 0x24 0x0b 0x6c /* Password unlock 1 */ >>> + 0x02 0x24 0x11 0x86 /* Apply DCDC changes */ >>> + 0x02 0x24 0x0b 0x6c /* Password unlock 2 */ >>> + 0x02 0x24 0x11 0x86 /* Apply DCDC changes */ >>> + >; >>> +} >>> diff --git a/arch/arm/mach-omap2/control.c b/arch/arm/mach-omap2/control.c >>> index 934041a..dfbd5f0 100644 >>> --- a/arch/arm/mach-omap2/control.c >>> +++ b/arch/arm/mach-omap2/control.c >>> @@ -639,6 +639,7 @@ void am33xx_pm_ipc_cmd(struct am33xx_ipc_data *data) >>> omap_ctrl_writel(data->param1, AM33XX_CONTROL_IPC_MSG_REG2); >>> omap_ctrl_writel(data->param2, AM33XX_CONTROL_IPC_MSG_REG3); >>> omap_ctrl_writel(data->param3, AM33XX_CONTROL_IPC_MSG_REG4); >>> + omap_ctrl_writel(data->param4, AM33XX_CONTROL_IPC_MSG_REG5); >>> } >>> >>> int am33xx_pm_status(void) >>> diff --git a/arch/arm/mach-omap2/pm33xx.c b/arch/arm/mach-omap2/pm33xx.c >>> index d291c76..8880da3 100644 >>> --- a/arch/arm/mach-omap2/pm33xx.c >>> +++ b/arch/arm/mach-omap2/pm33xx.c >>> @@ -29,6 +29,7 @@ >>> #include <linux/ti_emif.h> >>> #include <linux/omap-mailbox.h> >>> >>> +#include <asm/unaligned.h> >>> #include <asm/suspend.h> >>> #include <asm/proc-fns.h> >>> #include <asm/sizes.h> >>> @@ -50,6 +51,10 @@ >>> static void __iomem *am33xx_emif_base; >>> static struct powerdomain *cefuse_pwrdm, *gfx_pwrdm, *per_pwrdm, *mpu_pwrdm; >>> static struct clockdomain *gfx_l4ls_clkdm; >>> +static char *am33xx_i2c_sleep_sequence; >>> +static char *am33xx_i2c_wake_sequence; >>> +static size_t i2c_sleep_sequence_sz; >>> +static size_t i2c_wake_sequence_sz; >>> >>> struct wakeup_src wakeups[] = { >>> {.irq_nr = 35, .src = "USB0_PHY"}, >>> @@ -232,12 +237,34 @@ static void am33xx_m3_state_machine_reset(void) >>> static int am33xx_pm_begin(suspend_state_t state) >>> { >>> int i; >>> + unsigned long param4; >>> + int pos; >>> >>> cpu_idle_poll_ctrl(true); >>> >>> + param4 = DS_IPC_DEFAULT; >>> + >>> + wkup_m3_reset_data_pos(); >>> + if (am33xx_i2c_sleep_sequence) { >>> + pos = wkup_m3_copy_data(am33xx_i2c_sleep_sequence, >>> + i2c_sleep_sequence_sz); >> >> Why do we need to copy this data (same constant data) on every iteration? > > Because the CM3 firmware is reset after each suspend/resume cycle. The > firmware reset handler reinitializes the DMEM. Is it. Do you have any more information about the same? Even then, you can copy from DT to CM3 and remove 2nd temp storage. Right? > >>> + /* Lower 16 bits stores offset to sleep sequence */ >>> + param4 &= ~0xffff; >>> + param4 |= pos; >>> + } >>> + >>> + if (am33xx_i2c_wake_sequence) { >>> + pos = wkup_m3_copy_data(am33xx_i2c_wake_sequence, >>> + i2c_wake_sequence_sz); >>> + /* Upper 16 bits stores offset to wake sequence */ >>> + param4 &= ~0xffff0000; >>> + param4 |= pos << 16; >>> + } >>> + >> >> Seems above entire change can be done only once. >> >>> am33xx_pm->ipc.sleep_mode = IPC_CMD_DS0; >>> am33xx_pm->ipc.param1 = DS_IPC_DEFAULT; >>> am33xx_pm->ipc.param2 = DS_IPC_DEFAULT; >>> + am33xx_pm->ipc.param4 = param4; >>> >>> am33xx_pm_ipc_cmd(&am33xx_pm->ipc); >>> >>> @@ -386,6 +413,62 @@ static int __init am33xx_map_emif(void) >>> return 0; >>> } >>> >>> +static int __init am33xx_setup_sleep_sequence(void) >>> +{ >>> + int ret; >>> + int sz; >>> + const void *prop; >>> + struct device *dev; >>> + u32 freq_hz = 100000; >> >> Magic number? > > It's taken from drivers/i2c/busses/i2c-omap.c > > u32 freq = 100000; /* default to 100000 Hz */ > > I'll add a comment to that effect. > >>> + unsigned short freq_khz; >>> + >>> + /* >>> + * We put the device tree node in the I2C controller that will >>> + * be sending the sequence. i2c1 is the only controller that can >>> + * be accessed by the firmware as it is the only controller in the >>> + * WKUP domain. >> >> and on which the PMIC sits I believe? > > Yes, but this code is designed not to be PMIC specific as one could > chose to regulate VDD_CORE with any PMIC, or even with a standalone > I2C controlled regulator. > >>> + */ >>> + dev = omap_device_get_by_hwmod_name("i2c1"); >>> + if (IS_ERR(dev)) >>> + return PTR_ERR(dev); >>> + >>> + of_property_read_u32(dev->of_node, "clock-frequency", &freq_hz); >>> + freq_khz = freq_hz / 1000; >> >> Magic number? > > Nah, converting between metric prefixes this way is pretty common in the kernel. oh. Correct. > >>> + >>> + prop = of_get_property(dev->of_node, "sleep_sequence", &sz); >>> + if (prop) { >>> + /* >>> + * Length is sequence length + 2 bytes for freq_khz, and 1 >>> + * byte for terminator. >>> + */ >>> + am33xx_i2c_sleep_sequence = kzalloc(sz + 3, GFP_KERNEL); >>> + if (!am33xx_i2c_sleep_sequence) >>> + return -ENOMEM; >>> + put_unaligned_le16(freq_khz, am33xx_i2c_sleep_sequence); >>> + memcpy(am33xx_i2c_sleep_sequence + 2, prop, sz); >> >> so, looking at entire code, it seems there is 3 memory space for same >> data (or 1 original + 2 copy) >> >> 1. in DT >> 2. in am33xx_i2c_[sleep/wake]_sequence >> 3. in SRAm by call to wkup_m3_copy_data() >> >> why not directly copy to SRAM from DT? > > As pointed out above, the firmware reset handler would wipe it out. i have update my comment above. > >>> + i2c_sleep_sequence_sz = sz + 3; >>> + } >>> + >>> + prop = of_get_property(dev->of_node, "wake_sequence", &sz); >>> + if (prop) { >>> + am33xx_i2c_wake_sequence = kzalloc(sz + 3, GFP_KERNEL); >>> + if (!am33xx_i2c_wake_sequence) { >>> + ret = -ENOMEM; >>> + goto cleanup_sleep; >>> + } >>> + put_unaligned_le16(freq_khz, am33xx_i2c_sleep_sequence); >>> + memcpy(am33xx_i2c_wake_sequence + 2, prop, sz); >>> + i2c_wake_sequence_sz = sz + 3; >>> + } >>> + >>> + return 0; >>> + >>> +cleanup_sleep: >>> + kfree(am33xx_i2c_sleep_sequence); >>> + am33xx_i2c_sleep_sequence = NULL; >>> + return ret; >>> +} >>> + >>> int __init am33xx_pm_init(void) >>> { >>> int ret; >>> @@ -451,6 +534,12 @@ int __init am33xx_pm_init(void) >>> } >>> } >>> >>> + ret = am33xx_setup_sleep_sequence(); >>> + if (ret) { >>> + pr_err("Error fetching I2C sleep/wake sequence\n"); >>> + goto err; >>> + } >>> + >>> (void) clkdm_for_each(omap_pm_clkdms_setup, NULL); >>> >>> /* CEFUSE domain can be turned off post bootup */ >>> diff --git a/arch/arm/mach-omap2/pm33xx.h b/arch/arm/mach-omap2/pm33xx.h >>> index befdd11..d0f08a5 100644 >>> --- a/arch/arm/mach-omap2/pm33xx.h >>> +++ b/arch/arm/mach-omap2/pm33xx.h >>> @@ -52,6 +52,8 @@ struct forced_standby_module { >>> }; >>> >>> int wkup_m3_copy_code(const u8 *data, size_t size); >>> +void wkup_m3_reset_data_pos(void); >>> +int wkup_m3_copy_data(const u8 *data, size_t size); >>> int wkup_m3_prepare(void); >>> void wkup_m3_register_txev_handler(void (*txev_handler)(void)); >>> >>> diff --git a/arch/arm/mach-omap2/wkup_m3.c b/arch/arm/mach-omap2/wkup_m3.c >>> index 8eaa7f3..a541de9 100644 >>> --- a/arch/arm/mach-omap2/wkup_m3.c >>> +++ b/arch/arm/mach-omap2/wkup_m3.c >>> @@ -35,6 +35,9 @@ >>> struct wkup_m3_context { >>> struct device *dev; >>> void __iomem *code; >>> + void __iomem *data; >>> + void __iomem *data_end; >>> + size_t data_size; >>> void (*txev_handler)(void); >>> }; >>> >>> @@ -50,6 +53,30 @@ int wkup_m3_copy_code(const u8 *data, size_t size) >>> return 0; >>> } >>> >>> +/* >>> + * This pair of functions allows data to be stuffed into the end of the >>> + * CM3 data memory. This is currently used for passing the I2C sleep/wake >>> + * sequences to the firmware. >>> + */ >>> + >>> +/* Clear out the pointer for data stored at the end of DMEM */ >>> +void wkup_m3_reset_data_pos(void) >>> +{ >>> + wkup_m3->data_end = wkup_m3->data + wkup_m3->data_size; >>> +} >>> + >>> +/* >>> + * Store a block of data at the end of DMEM, return the offset within DMEM >>> + * that the data is stored at, or -ENOMEM if the data did not fit >>> + */ >>> +int wkup_m3_copy_data(const u8 *data, size_t size) >>> +{ >>> + if (wkup_m3->data + size > wkup_m3->data_end) >>> + return -ENOMEM; >>> + wkup_m3->data_end -= size; >>> + memcpy_toio(wkup_m3->data_end, data, size); >>> + return wkup_m3->data_end - wkup_m3->data; >>> +} >>> >>> void wkup_m3_register_txev_handler(void (*txev_handler)(void)) >>> { >>> @@ -83,7 +110,7 @@ int wkup_m3_prepare(void) >>> static int wkup_m3_probe(struct platform_device *pdev) >>> { >>> int irq, ret = 0; >>> - struct resource *mem; >>> + struct resource *umem, *dmem; >>> >>> pm_runtime_enable(&pdev->dev); >>> >>> @@ -95,14 +122,21 @@ static int wkup_m3_probe(struct platform_device *pdev) >>> >>> irq = platform_get_irq(pdev, 0); >>> if (!irq) { >>> - dev_err(wkup_m3->dev, "no irq resource\n"); >>> + dev_err(&pdev->dev, "no irq resource\n"); >> >> unrelated change?. Better to mention this as code cleanup in commit. > > Will add a comment to that effect, the underlying error should be > fixed in the next suspend/resume patch though. > >>> + ret = -ENXIO; >>> + goto err; >>> + } >>> + >>> + umem = platform_get_resource(pdev, IORESOURCE_MEM, 0); >>> + if (!umem) { >>> + dev_err(&pdev->dev, "no UMEM resource\n"); >>> ret = -ENXIO; >>> goto err; >>> } >>> >>> - mem = platform_get_resource(pdev, IORESOURCE_MEM, 0); >>> - if (!mem) { >>> - dev_err(wkup_m3->dev, "no memory resource\n"); >>> + dmem = platform_get_resource(pdev, IORESOURCE_MEM, 1); >>> + if (!dmem) { >>> + dev_err(&pdev->dev, "no DMEM resource\n"); >>> ret = -ENXIO; >>> goto err; >>> } >>> @@ -116,12 +150,21 @@ static int wkup_m3_probe(struct platform_device *pdev) >>> >>> wkup_m3->dev = &pdev->dev; >>> >>> - wkup_m3->code = devm_request_and_ioremap(wkup_m3->dev, mem); >>> + wkup_m3->code = devm_request_and_ioremap(wkup_m3->dev, umem); >>> + if (!wkup_m3->code) { >>> + dev_err(wkup_m3->dev, "could not ioremap UMEM\n"); >> >> why not use "pdev->dev" here? > > Either one works just for consistency. > >>> + ret = -EADDRNOTAVAIL; >>> + goto err; >>> + } >>> + >>> + wkup_m3->data = devm_request_and_ioremap(wkup_m3->dev, dmem); >>> if (!wkup_m3->code) { >> >> I believe this is just a copy/paste error. s/code/data > > Doh, thanks! > >>> - dev_err(wkup_m3->dev, "could not ioremap\n"); >>> + dev_err(wkup_m3->dev, "could not ioremap DMEM\n"); >> >> same as above. >> >>> ret = -EADDRNOTAVAIL; >>> goto err; >>> } >>> + wkup_m3->data_size = resource_size(dmem); >>> + wkup_m3_reset_data_pos(); >>> >>> ret = devm_request_irq(wkup_m3->dev, irq, wkup_m3_txev_handler, >>> IRQF_DISABLED, "wkup_m3_txev", NULL); >>> -- 1.8.3.2 -- To unsubscribe from this list: send the line "unsubscribe >>> linux-omap" in the body of a message to majordomo@vger.kernel.org More >>> majordomo info at http://vger.kernel.org/majordomo-info.html >>> >> >> >> _______________________________________________ >> linux-arm-kernel mailing list >> linux-arm-kernel@lists.infradead.org >> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 84+ messages in thread
* [PATCH v4 1/4] ARM: OMAP2+: AM33XX: I2C Sleep/wake sequence support @ 2013-08-16 7:16 ` Gururaja Hebbar 0 siblings, 0 replies; 84+ messages in thread From: Gururaja Hebbar @ 2013-08-16 7:16 UTC (permalink / raw) To: linux-arm-kernel On 8/15/2013 4:04 AM, Russ Dill wrote: > On Wed, Aug 14, 2013 at 3:18 AM, Gururaja Hebbar <gururaja.hebbar@ti.com> wrote: >> On 8/14/2013 3:50 AM, Russ Dill wrote: >>> Changes since v1: >>> * Rebased onto new am335x PM branch >>> * Changed to use 5th param register >>> >>> Changes since v2: >>> * Passes I2C bus speed in kHz to M3 firmware >>> >>> Changes since v3: >>> * Rebased to 3.11-rc3, moves some functionality to wkup_m3.c >>> * Additional comments >>> * Added device-tree binding documentation >> >> AFAIK, Change logs should come below scissors line (---). >> However there was some discussion to keep it in the commit message. >> Don't know what happened to it finally. But till date, all revision >> patch set has the change log under the scissor line. > > Will fix is v2. > >>> >>> This patch adds the ability to pass an I2C sleep sequence and wake sequence >>> to the Cortex-M3. This is useful for adjusting voltages during sleep that >>> cannot be lowered while SDRAM is active. A modified M3 firmware with I2C >>> support is required. >>> >>> Each sequence is a series of I2C transfers in the form: >>> >>> u8 length | u8 chip address | u8 byte0/reg address | u8 byte 1 | u8 byte n ... >>> >>> The length indicates the number of bytes to transfer, including the register >>> address. The length of each transfer is limited by the I2C buffer size of >>> 32 bytes. >>> >>> The sequences are taken from the i2c1 node in the device tree. The property >>> name for the sleep sequence is "sleep_sequence" and the property name for >>> the wake sequence is "wake_sequence". Each property should be an array of >>> bytes. >>> >>> No actions are performed if the properties are not present in the device >>> tree. >>> >>> Signed-off-by: Russ Dill <Russ.Dill@ti.com> >>> --- >>> .../devicetree/bindings/i2c/i2c-suspend-resume.txt | 44 +++++++++++ >>> arch/arm/mach-omap2/control.c | 1 + >>> arch/arm/mach-omap2/pm33xx.c | 89 ++++++++++++++++++++++ >>> arch/arm/mach-omap2/pm33xx.h | 2 + >>> arch/arm/mach-omap2/wkup_m3.c | 57 ++++++++++++-- >>> 5 files changed, 186 insertions(+), 7 deletions(-) >>> create mode 100644 Documentation/devicetree/bindings/i2c/i2c-suspend-resume.txt >>> >>> diff --git a/Documentation/devicetree/bindings/i2c/i2c-suspend-resume.txt b/Documentation/devicetree/bindings/i2c/i2c-suspend-resume.txt >>> new file mode 100644 >>> index 0000000..af19372 >>> --- /dev/null >>> +++ b/Documentation/devicetree/bindings/i2c/i2c-suspend-resume.txt >>> @@ -0,0 +1,44 @@ >>> +I2C suspend/resume sequences >>> + >>> +This provides the ability for a simple I2C sequence to be written at >>> +suspend time and resume time. This is for sequences that cannot be written >>> +by the I2C bus driver for reasons such as needing to be run from SRAM >>> +or needing to be written by firmware. >>> + >>> +The sequence is composed of messages. Each message contains a length byte, >>> +an address byte, and then the message. >>> + >>> +Optional properties: >>> +- sleep_sequence >>> + I2C sequence to write during suspend >>> + >>> +- wake_sequence >>> + I2C sequence to write during wake >>> + >>> +Examples : >>> + >>> +i2c0: i2c at 0 { >>> + /* Set OPP50 (0.95V) for VDD core */ >>> + sleep_sequence = /bits/ 8 < >>> + 0x02 0x24 0x0b 0x6d /* Password unlock 1 */ >>> + 0x02 0x24 0x10 0x02 /* Set DCDC3 to 0.95V */ >>> + 0x02 0x24 0x0b 0x6d /* Password unlock 2 */ >>> + 0x02 0x24 0x10 0x02 /* Set DCDC3 to 0.95V */ >>> + 0x02 0x24 0x0b 0x6c /* Password unlock 1 */ >>> + 0x02 0x24 0x11 0x86 /* Apply DCDC changes */ >>> + 0x02 0x24 0x0b 0x6c /* Password unlock 2 */ >>> + 0x02 0x24 0x11 0x86 /* Apply DCDC changes */ >>> + >; >> >> This data is not related to i2c. Right? Then why is it under i2c dt node? >> >> There is already a wakeup node (wkup_m3) and a pmic node (pmic node for >> respective boards). Can't these details go under those nodes? > > The i2c node was chosen for several reasons. First that the bus speed > is included in the message to the CM3 firmware. The bus speed and > sequence can then be read from the same device tree node. Second so > it's clear which I2C bus this is being sent out on. Including it under > the PMIC node would mean that the code would have to search each child > of the I2C bus for a sequence and if multiple children had sequences, > it would not know in which order to send those sequences out. Agreed > >>> + >>> + /* Set OPP100 (1.10V) for VDD core */ >>> + wake_sequence = /bits/ 8 < >>> + 0x02 0x24 0x0b 0x6d /* Password unlock 1 */ >>> + 0x02 0x24 0x10 0x08 /* Set DCDC3 to 1.1V */ >>> + 0x02 0x24 0x0b 0x6d /* Password unlock 2 */ >>> + 0x02 0x24 0x10 0x08 /* Set DCDC3 to 1.1V */ >>> + 0x02 0x24 0x0b 0x6c /* Password unlock 1 */ >>> + 0x02 0x24 0x11 0x86 /* Apply DCDC changes */ >>> + 0x02 0x24 0x0b 0x6c /* Password unlock 2 */ >>> + 0x02 0x24 0x11 0x86 /* Apply DCDC changes */ >>> + >; >>> +} >>> diff --git a/arch/arm/mach-omap2/control.c b/arch/arm/mach-omap2/control.c >>> index 934041a..dfbd5f0 100644 >>> --- a/arch/arm/mach-omap2/control.c >>> +++ b/arch/arm/mach-omap2/control.c >>> @@ -639,6 +639,7 @@ void am33xx_pm_ipc_cmd(struct am33xx_ipc_data *data) >>> omap_ctrl_writel(data->param1, AM33XX_CONTROL_IPC_MSG_REG2); >>> omap_ctrl_writel(data->param2, AM33XX_CONTROL_IPC_MSG_REG3); >>> omap_ctrl_writel(data->param3, AM33XX_CONTROL_IPC_MSG_REG4); >>> + omap_ctrl_writel(data->param4, AM33XX_CONTROL_IPC_MSG_REG5); >>> } >>> >>> int am33xx_pm_status(void) >>> diff --git a/arch/arm/mach-omap2/pm33xx.c b/arch/arm/mach-omap2/pm33xx.c >>> index d291c76..8880da3 100644 >>> --- a/arch/arm/mach-omap2/pm33xx.c >>> +++ b/arch/arm/mach-omap2/pm33xx.c >>> @@ -29,6 +29,7 @@ >>> #include <linux/ti_emif.h> >>> #include <linux/omap-mailbox.h> >>> >>> +#include <asm/unaligned.h> >>> #include <asm/suspend.h> >>> #include <asm/proc-fns.h> >>> #include <asm/sizes.h> >>> @@ -50,6 +51,10 @@ >>> static void __iomem *am33xx_emif_base; >>> static struct powerdomain *cefuse_pwrdm, *gfx_pwrdm, *per_pwrdm, *mpu_pwrdm; >>> static struct clockdomain *gfx_l4ls_clkdm; >>> +static char *am33xx_i2c_sleep_sequence; >>> +static char *am33xx_i2c_wake_sequence; >>> +static size_t i2c_sleep_sequence_sz; >>> +static size_t i2c_wake_sequence_sz; >>> >>> struct wakeup_src wakeups[] = { >>> {.irq_nr = 35, .src = "USB0_PHY"}, >>> @@ -232,12 +237,34 @@ static void am33xx_m3_state_machine_reset(void) >>> static int am33xx_pm_begin(suspend_state_t state) >>> { >>> int i; >>> + unsigned long param4; >>> + int pos; >>> >>> cpu_idle_poll_ctrl(true); >>> >>> + param4 = DS_IPC_DEFAULT; >>> + >>> + wkup_m3_reset_data_pos(); >>> + if (am33xx_i2c_sleep_sequence) { >>> + pos = wkup_m3_copy_data(am33xx_i2c_sleep_sequence, >>> + i2c_sleep_sequence_sz); >> >> Why do we need to copy this data (same constant data) on every iteration? > > Because the CM3 firmware is reset after each suspend/resume cycle. The > firmware reset handler reinitializes the DMEM. Is it. Do you have any more information about the same? Even then, you can copy from DT to CM3 and remove 2nd temp storage. Right? > >>> + /* Lower 16 bits stores offset to sleep sequence */ >>> + param4 &= ~0xffff; >>> + param4 |= pos; >>> + } >>> + >>> + if (am33xx_i2c_wake_sequence) { >>> + pos = wkup_m3_copy_data(am33xx_i2c_wake_sequence, >>> + i2c_wake_sequence_sz); >>> + /* Upper 16 bits stores offset to wake sequence */ >>> + param4 &= ~0xffff0000; >>> + param4 |= pos << 16; >>> + } >>> + >> >> Seems above entire change can be done only once. >> >>> am33xx_pm->ipc.sleep_mode = IPC_CMD_DS0; >>> am33xx_pm->ipc.param1 = DS_IPC_DEFAULT; >>> am33xx_pm->ipc.param2 = DS_IPC_DEFAULT; >>> + am33xx_pm->ipc.param4 = param4; >>> >>> am33xx_pm_ipc_cmd(&am33xx_pm->ipc); >>> >>> @@ -386,6 +413,62 @@ static int __init am33xx_map_emif(void) >>> return 0; >>> } >>> >>> +static int __init am33xx_setup_sleep_sequence(void) >>> +{ >>> + int ret; >>> + int sz; >>> + const void *prop; >>> + struct device *dev; >>> + u32 freq_hz = 100000; >> >> Magic number? > > It's taken from drivers/i2c/busses/i2c-omap.c > > u32 freq = 100000; /* default to 100000 Hz */ > > I'll add a comment to that effect. > >>> + unsigned short freq_khz; >>> + >>> + /* >>> + * We put the device tree node in the I2C controller that will >>> + * be sending the sequence. i2c1 is the only controller that can >>> + * be accessed by the firmware as it is the only controller in the >>> + * WKUP domain. >> >> and on which the PMIC sits I believe? > > Yes, but this code is designed not to be PMIC specific as one could > chose to regulate VDD_CORE with any PMIC, or even with a standalone > I2C controlled regulator. > >>> + */ >>> + dev = omap_device_get_by_hwmod_name("i2c1"); >>> + if (IS_ERR(dev)) >>> + return PTR_ERR(dev); >>> + >>> + of_property_read_u32(dev->of_node, "clock-frequency", &freq_hz); >>> + freq_khz = freq_hz / 1000; >> >> Magic number? > > Nah, converting between metric prefixes this way is pretty common in the kernel. oh. Correct. > >>> + >>> + prop = of_get_property(dev->of_node, "sleep_sequence", &sz); >>> + if (prop) { >>> + /* >>> + * Length is sequence length + 2 bytes for freq_khz, and 1 >>> + * byte for terminator. >>> + */ >>> + am33xx_i2c_sleep_sequence = kzalloc(sz + 3, GFP_KERNEL); >>> + if (!am33xx_i2c_sleep_sequence) >>> + return -ENOMEM; >>> + put_unaligned_le16(freq_khz, am33xx_i2c_sleep_sequence); >>> + memcpy(am33xx_i2c_sleep_sequence + 2, prop, sz); >> >> so, looking at entire code, it seems there is 3 memory space for same >> data (or 1 original + 2 copy) >> >> 1. in DT >> 2. in am33xx_i2c_[sleep/wake]_sequence >> 3. in SRAm by call to wkup_m3_copy_data() >> >> why not directly copy to SRAM from DT? > > As pointed out above, the firmware reset handler would wipe it out. i have update my comment above. > >>> + i2c_sleep_sequence_sz = sz + 3; >>> + } >>> + >>> + prop = of_get_property(dev->of_node, "wake_sequence", &sz); >>> + if (prop) { >>> + am33xx_i2c_wake_sequence = kzalloc(sz + 3, GFP_KERNEL); >>> + if (!am33xx_i2c_wake_sequence) { >>> + ret = -ENOMEM; >>> + goto cleanup_sleep; >>> + } >>> + put_unaligned_le16(freq_khz, am33xx_i2c_sleep_sequence); >>> + memcpy(am33xx_i2c_wake_sequence + 2, prop, sz); >>> + i2c_wake_sequence_sz = sz + 3; >>> + } >>> + >>> + return 0; >>> + >>> +cleanup_sleep: >>> + kfree(am33xx_i2c_sleep_sequence); >>> + am33xx_i2c_sleep_sequence = NULL; >>> + return ret; >>> +} >>> + >>> int __init am33xx_pm_init(void) >>> { >>> int ret; >>> @@ -451,6 +534,12 @@ int __init am33xx_pm_init(void) >>> } >>> } >>> >>> + ret = am33xx_setup_sleep_sequence(); >>> + if (ret) { >>> + pr_err("Error fetching I2C sleep/wake sequence\n"); >>> + goto err; >>> + } >>> + >>> (void) clkdm_for_each(omap_pm_clkdms_setup, NULL); >>> >>> /* CEFUSE domain can be turned off post bootup */ >>> diff --git a/arch/arm/mach-omap2/pm33xx.h b/arch/arm/mach-omap2/pm33xx.h >>> index befdd11..d0f08a5 100644 >>> --- a/arch/arm/mach-omap2/pm33xx.h >>> +++ b/arch/arm/mach-omap2/pm33xx.h >>> @@ -52,6 +52,8 @@ struct forced_standby_module { >>> }; >>> >>> int wkup_m3_copy_code(const u8 *data, size_t size); >>> +void wkup_m3_reset_data_pos(void); >>> +int wkup_m3_copy_data(const u8 *data, size_t size); >>> int wkup_m3_prepare(void); >>> void wkup_m3_register_txev_handler(void (*txev_handler)(void)); >>> >>> diff --git a/arch/arm/mach-omap2/wkup_m3.c b/arch/arm/mach-omap2/wkup_m3.c >>> index 8eaa7f3..a541de9 100644 >>> --- a/arch/arm/mach-omap2/wkup_m3.c >>> +++ b/arch/arm/mach-omap2/wkup_m3.c >>> @@ -35,6 +35,9 @@ >>> struct wkup_m3_context { >>> struct device *dev; >>> void __iomem *code; >>> + void __iomem *data; >>> + void __iomem *data_end; >>> + size_t data_size; >>> void (*txev_handler)(void); >>> }; >>> >>> @@ -50,6 +53,30 @@ int wkup_m3_copy_code(const u8 *data, size_t size) >>> return 0; >>> } >>> >>> +/* >>> + * This pair of functions allows data to be stuffed into the end of the >>> + * CM3 data memory. This is currently used for passing the I2C sleep/wake >>> + * sequences to the firmware. >>> + */ >>> + >>> +/* Clear out the pointer for data stored at the end of DMEM */ >>> +void wkup_m3_reset_data_pos(void) >>> +{ >>> + wkup_m3->data_end = wkup_m3->data + wkup_m3->data_size; >>> +} >>> + >>> +/* >>> + * Store a block of data at the end of DMEM, return the offset within DMEM >>> + * that the data is stored at, or -ENOMEM if the data did not fit >>> + */ >>> +int wkup_m3_copy_data(const u8 *data, size_t size) >>> +{ >>> + if (wkup_m3->data + size > wkup_m3->data_end) >>> + return -ENOMEM; >>> + wkup_m3->data_end -= size; >>> + memcpy_toio(wkup_m3->data_end, data, size); >>> + return wkup_m3->data_end - wkup_m3->data; >>> +} >>> >>> void wkup_m3_register_txev_handler(void (*txev_handler)(void)) >>> { >>> @@ -83,7 +110,7 @@ int wkup_m3_prepare(void) >>> static int wkup_m3_probe(struct platform_device *pdev) >>> { >>> int irq, ret = 0; >>> - struct resource *mem; >>> + struct resource *umem, *dmem; >>> >>> pm_runtime_enable(&pdev->dev); >>> >>> @@ -95,14 +122,21 @@ static int wkup_m3_probe(struct platform_device *pdev) >>> >>> irq = platform_get_irq(pdev, 0); >>> if (!irq) { >>> - dev_err(wkup_m3->dev, "no irq resource\n"); >>> + dev_err(&pdev->dev, "no irq resource\n"); >> >> unrelated change?. Better to mention this as code cleanup in commit. > > Will add a comment to that effect, the underlying error should be > fixed in the next suspend/resume patch though. > >>> + ret = -ENXIO; >>> + goto err; >>> + } >>> + >>> + umem = platform_get_resource(pdev, IORESOURCE_MEM, 0); >>> + if (!umem) { >>> + dev_err(&pdev->dev, "no UMEM resource\n"); >>> ret = -ENXIO; >>> goto err; >>> } >>> >>> - mem = platform_get_resource(pdev, IORESOURCE_MEM, 0); >>> - if (!mem) { >>> - dev_err(wkup_m3->dev, "no memory resource\n"); >>> + dmem = platform_get_resource(pdev, IORESOURCE_MEM, 1); >>> + if (!dmem) { >>> + dev_err(&pdev->dev, "no DMEM resource\n"); >>> ret = -ENXIO; >>> goto err; >>> } >>> @@ -116,12 +150,21 @@ static int wkup_m3_probe(struct platform_device *pdev) >>> >>> wkup_m3->dev = &pdev->dev; >>> >>> - wkup_m3->code = devm_request_and_ioremap(wkup_m3->dev, mem); >>> + wkup_m3->code = devm_request_and_ioremap(wkup_m3->dev, umem); >>> + if (!wkup_m3->code) { >>> + dev_err(wkup_m3->dev, "could not ioremap UMEM\n"); >> >> why not use "pdev->dev" here? > > Either one works just for consistency. > >>> + ret = -EADDRNOTAVAIL; >>> + goto err; >>> + } >>> + >>> + wkup_m3->data = devm_request_and_ioremap(wkup_m3->dev, dmem); >>> if (!wkup_m3->code) { >> >> I believe this is just a copy/paste error. s/code/data > > Doh, thanks! > >>> - dev_err(wkup_m3->dev, "could not ioremap\n"); >>> + dev_err(wkup_m3->dev, "could not ioremap DMEM\n"); >> >> same as above. >> >>> ret = -EADDRNOTAVAIL; >>> goto err; >>> } >>> + wkup_m3->data_size = resource_size(dmem); >>> + wkup_m3_reset_data_pos(); >>> >>> ret = devm_request_irq(wkup_m3->dev, irq, wkup_m3_txev_handler, >>> IRQF_DISABLED, "wkup_m3_txev", NULL); >>> -- 1.8.3.2 -- To unsubscribe from this list: send the line "unsubscribe >>> linux-omap" in the body of a message to majordomo at vger.kernel.org More >>> majordomo info at http://vger.kernel.org/majordomo-info.html >>> >> >> >> _______________________________________________ >> linux-arm-kernel mailing list >> linux-arm-kernel at lists.infradead.org >> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 84+ messages in thread
* Re: [PATCH v4 1/4] ARM: OMAP2+: AM33XX: I2C Sleep/wake sequence support 2013-08-14 22:34 ` Russ Dill @ 2013-08-19 5:49 ` Gururaja Hebbar -1 siblings, 0 replies; 84+ messages in thread From: Gururaja Hebbar @ 2013-08-19 5:49 UTC (permalink / raw) To: Russ Dill Cc: Kevin Hilman, devicetree, devicetree-discuss, linux-omap, linux-arm-kernel On 8/15/2013 4:04 AM, Russ Dill wrote: > On Wed, Aug 14, 2013 at 3:18 AM, Gururaja Hebbar <gururaja.hebbar@ti.com> wrote: >> On 8/14/2013 3:50 AM, Russ Dill wrote: >>> Changes since v1: >>> * Rebased onto new am335x PM branch >>> * Changed to use 5th param register >> [snip] [snip] >>> + >>> + wkup_m3_reset_data_pos(); >>> + if (am33xx_i2c_sleep_sequence) { >>> + pos = wkup_m3_copy_data(am33xx_i2c_sleep_sequence, >>> + i2c_sleep_sequence_sz); >> >> Why do we need to copy this data (same constant data) on every iteration? > > Because the CM3 firmware is reset after each suspend/resume cycle. The > firmware reset handler reinitializes the DMEM. Well in that why can't the i2c payload be copied to UMEM? Thanks & regards Gururaja > >>> + /* Lower 16 bits stores offset to sleep sequence */ >>> + param4 &= ~0xffff; >>> + param4 |= pos; >>> + } >>> + >>> + if (am33xx_i2c_wake_sequence) { >>> + pos = wkup_m3_copy_data(am33xx_i2c_wake_sequence, >>> + i2c_wake_sequence_sz); >>> + /* Upper 16 bits stores offset to wake sequence */ >>> + param4 &= ~0xffff0000; >>> + param4 |= pos << 16; >>> + } >>> + >> >> Seems above entire change can be done only once. >> >>> am33xx_pm->ipc.sleep_mode = IPC_CMD_DS0; >>> am33xx_pm->ipc.param1 = DS_IPC_DEFAULT; >>> am33xx_pm->ipc.param2 = DS_IPC_DEFAULT; >>> + am33xx_pm->ipc.param4 = param4; >>> >>> am33xx_pm_ipc_cmd(&am33xx_pm->ipc); >>> >>> @@ -386,6 +413,62 @@ static int __init am33xx_map_emif(void) >>> return 0; >>> } >>> >>> +static int __init am33xx_setup_sleep_sequence(void) >>> +{ >>> + int ret; >>> + int sz; >>> + const void *prop; >>> + struct device *dev; >>> + u32 freq_hz = 100000; >> >> Magic number? > > It's taken from drivers/i2c/busses/i2c-omap.c > > u32 freq = 100000; /* default to 100000 Hz */ > > I'll add a comment to that effect. > >>> + unsigned short freq_khz; >>> + >>> + /* >>> + * We put the device tree node in the I2C controller that will >>> + * be sending the sequence. i2c1 is the only controller that can >>> + * be accessed by the firmware as it is the only controller in the >>> + * WKUP domain. >> >> and on which the PMIC sits I believe? > > Yes, but this code is designed not to be PMIC specific as one could > chose to regulate VDD_CORE with any PMIC, or even with a standalone > I2C controlled regulator. > >>> + */ >>> + dev = omap_device_get_by_hwmod_name("i2c1"); >>> + if (IS_ERR(dev)) >>> + return PTR_ERR(dev); >>> + >>> + of_property_read_u32(dev->of_node, "clock-frequency", &freq_hz); >>> + freq_khz = freq_hz / 1000; >> >> Magic number? > > Nah, converting between metric prefixes this way is pretty common in the kernel. > >>> + >>> + prop = of_get_property(dev->of_node, "sleep_sequence", &sz); >>> + if (prop) { >>> + /* >>> + * Length is sequence length + 2 bytes for freq_khz, and 1 >>> + * byte for terminator. >>> + */ >>> + am33xx_i2c_sleep_sequence = kzalloc(sz + 3, GFP_KERNEL); >>> + if (!am33xx_i2c_sleep_sequence) >>> + return -ENOMEM; >>> + put_unaligned_le16(freq_khz, am33xx_i2c_sleep_sequence); >>> + memcpy(am33xx_i2c_sleep_sequence + 2, prop, sz); >> >> so, looking at entire code, it seems there is 3 memory space for same >> data (or 1 original + 2 copy) >> >> 1. in DT >> 2. in am33xx_i2c_[sleep/wake]_sequence >> 3. in SRAm by call to wkup_m3_copy_data() >> >> why not directly copy to SRAM from DT? > > As pointed out above, the firmware reset handler would wipe it out. > >>> + i2c_sleep_sequence_sz = sz + 3; >>> + } >>> + >>> + prop = of_get_property(dev->of_node, "wake_sequence", &sz); >>> + if (prop) { >>> + am33xx_i2c_wake_sequence = kzalloc(sz + 3, GFP_KERNEL); >>> + if (!am33xx_i2c_wake_sequence) { >>> + ret = -ENOMEM; >>> + goto cleanup_sleep; >>> + } >>> + put_unaligned_le16(freq_khz, am33xx_i2c_sleep_sequence); >>> + memcpy(am33xx_i2c_wake_sequence + 2, prop, sz); >>> + i2c_wake_sequence_sz = sz + 3; >>> + } >>> + >>> + return 0; >>> + >>> +cleanup_sleep: >>> + kfree(am33xx_i2c_sleep_sequence); >>> + am33xx_i2c_sleep_sequence = NULL; >>> + return ret; >>> +} >>> + >>> int __init am33xx_pm_init(void) >>> { >>> int ret; >>> @@ -451,6 +534,12 @@ int __init am33xx_pm_init(void) >>> } >>> } >>> >>> + ret = am33xx_setup_sleep_sequence(); >>> + if (ret) { >>> + pr_err("Error fetching I2C sleep/wake sequence\n"); >>> + goto err; >>> + } >>> + >>> (void) clkdm_for_each(omap_pm_clkdms_setup, NULL); >>> >>> /* CEFUSE domain can be turned off post bootup */ >>> diff --git a/arch/arm/mach-omap2/pm33xx.h b/arch/arm/mach-omap2/pm33xx.h >>> index befdd11..d0f08a5 100644 >>> --- a/arch/arm/mach-omap2/pm33xx.h >>> +++ b/arch/arm/mach-omap2/pm33xx.h >>> @@ -52,6 +52,8 @@ struct forced_standby_module { >>> }; >>> >>> int wkup_m3_copy_code(const u8 *data, size_t size); >>> +void wkup_m3_reset_data_pos(void); >>> +int wkup_m3_copy_data(const u8 *data, size_t size); >>> int wkup_m3_prepare(void); >>> void wkup_m3_register_txev_handler(void (*txev_handler)(void)); >>> >>> diff --git a/arch/arm/mach-omap2/wkup_m3.c b/arch/arm/mach-omap2/wkup_m3.c >>> index 8eaa7f3..a541de9 100644 >>> --- a/arch/arm/mach-omap2/wkup_m3.c >>> +++ b/arch/arm/mach-omap2/wkup_m3.c >>> @@ -35,6 +35,9 @@ >>> struct wkup_m3_context { >>> struct device *dev; >>> void __iomem *code; >>> + void __iomem *data; >>> + void __iomem *data_end; >>> + size_t data_size; >>> void (*txev_handler)(void); >>> }; >>> >>> @@ -50,6 +53,30 @@ int wkup_m3_copy_code(const u8 *data, size_t size) >>> return 0; >>> } >>> >>> +/* >>> + * This pair of functions allows data to be stuffed into the end of the >>> + * CM3 data memory. This is currently used for passing the I2C sleep/wake >>> + * sequences to the firmware. >>> + */ >>> + >>> +/* Clear out the pointer for data stored at the end of DMEM */ >>> +void wkup_m3_reset_data_pos(void) >>> +{ >>> + wkup_m3->data_end = wkup_m3->data + wkup_m3->data_size; >>> +} >>> + >>> +/* >>> + * Store a block of data at the end of DMEM, return the offset within DMEM >>> + * that the data is stored at, or -ENOMEM if the data did not fit >>> + */ >>> +int wkup_m3_copy_data(const u8 *data, size_t size) >>> +{ >>> + if (wkup_m3->data + size > wkup_m3->data_end) >>> + return -ENOMEM; >>> + wkup_m3->data_end -= size; >>> + memcpy_toio(wkup_m3->data_end, data, size); >>> + return wkup_m3->data_end - wkup_m3->data; >>> +} >>> >>> void wkup_m3_register_txev_handler(void (*txev_handler)(void)) >>> { >>> @@ -83,7 +110,7 @@ int wkup_m3_prepare(void) >>> static int wkup_m3_probe(struct platform_device *pdev) >>> { >>> int irq, ret = 0; >>> - struct resource *mem; >>> + struct resource *umem, *dmem; >>> >>> pm_runtime_enable(&pdev->dev); >>> >>> @@ -95,14 +122,21 @@ static int wkup_m3_probe(struct platform_device *pdev) >>> >>> irq = platform_get_irq(pdev, 0); >>> if (!irq) { >>> - dev_err(wkup_m3->dev, "no irq resource\n"); >>> + dev_err(&pdev->dev, "no irq resource\n"); >> >> unrelated change?. Better to mention this as code cleanup in commit. > > Will add a comment to that effect, the underlying error should be > fixed in the next suspend/resume patch though. > >>> + ret = -ENXIO; >>> + goto err; >>> + } >>> + >>> + umem = platform_get_resource(pdev, IORESOURCE_MEM, 0); >>> + if (!umem) { >>> + dev_err(&pdev->dev, "no UMEM resource\n"); >>> ret = -ENXIO; >>> goto err; >>> } >>> >>> - mem = platform_get_resource(pdev, IORESOURCE_MEM, 0); >>> - if (!mem) { >>> - dev_err(wkup_m3->dev, "no memory resource\n"); >>> + dmem = platform_get_resource(pdev, IORESOURCE_MEM, 1); >>> + if (!dmem) { >>> + dev_err(&pdev->dev, "no DMEM resource\n"); >>> ret = -ENXIO; >>> goto err; >>> } >>> @@ -116,12 +150,21 @@ static int wkup_m3_probe(struct platform_device *pdev) >>> >>> wkup_m3->dev = &pdev->dev; >>> >>> - wkup_m3->code = devm_request_and_ioremap(wkup_m3->dev, mem); >>> + wkup_m3->code = devm_request_and_ioremap(wkup_m3->dev, umem); >>> + if (!wkup_m3->code) { >>> + dev_err(wkup_m3->dev, "could not ioremap UMEM\n"); >> >> why not use "pdev->dev" here? > > Either one works > >>> + ret = -EADDRNOTAVAIL; >>> + goto err; >>> + } >>> + >>> + wkup_m3->data = devm_request_and_ioremap(wkup_m3->dev, dmem); >>> if (!wkup_m3->code) { >> >> I believe this is just a copy/paste error. s/code/data > > Doh, thanks! > >>> - dev_err(wkup_m3->dev, "could not ioremap\n"); >>> + dev_err(wkup_m3->dev, "could not ioremap DMEM\n"); >> >> same as above. >> >>> ret = -EADDRNOTAVAIL; >>> goto err; >>> } >>> + wkup_m3->data_size = resource_size(dmem); >>> + wkup_m3_reset_data_pos(); >>> >>> ret = devm_request_irq(wkup_m3->dev, irq, wkup_m3_txev_handler, >>> IRQF_DISABLED, "wkup_m3_txev", NULL); >>> -- 1.8.3.2 -- To unsubscribe from this list: send the line "unsubscribe >>> linux-omap" in the body of a message to majordomo@vger.kernel.org More >>> majordomo info at http://vger.kernel.org/majordomo-info.html >>> >> >> >> _______________________________________________ >> linux-arm-kernel mailing list >> linux-arm-kernel@lists.infradead.org >> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 84+ messages in thread
* [PATCH v4 1/4] ARM: OMAP2+: AM33XX: I2C Sleep/wake sequence support @ 2013-08-19 5:49 ` Gururaja Hebbar 0 siblings, 0 replies; 84+ messages in thread From: Gururaja Hebbar @ 2013-08-19 5:49 UTC (permalink / raw) To: linux-arm-kernel On 8/15/2013 4:04 AM, Russ Dill wrote: > On Wed, Aug 14, 2013 at 3:18 AM, Gururaja Hebbar <gururaja.hebbar@ti.com> wrote: >> On 8/14/2013 3:50 AM, Russ Dill wrote: >>> Changes since v1: >>> * Rebased onto new am335x PM branch >>> * Changed to use 5th param register >> [snip] [snip] >>> + >>> + wkup_m3_reset_data_pos(); >>> + if (am33xx_i2c_sleep_sequence) { >>> + pos = wkup_m3_copy_data(am33xx_i2c_sleep_sequence, >>> + i2c_sleep_sequence_sz); >> >> Why do we need to copy this data (same constant data) on every iteration? > > Because the CM3 firmware is reset after each suspend/resume cycle. The > firmware reset handler reinitializes the DMEM. Well in that why can't the i2c payload be copied to UMEM? Thanks & regards Gururaja > >>> + /* Lower 16 bits stores offset to sleep sequence */ >>> + param4 &= ~0xffff; >>> + param4 |= pos; >>> + } >>> + >>> + if (am33xx_i2c_wake_sequence) { >>> + pos = wkup_m3_copy_data(am33xx_i2c_wake_sequence, >>> + i2c_wake_sequence_sz); >>> + /* Upper 16 bits stores offset to wake sequence */ >>> + param4 &= ~0xffff0000; >>> + param4 |= pos << 16; >>> + } >>> + >> >> Seems above entire change can be done only once. >> >>> am33xx_pm->ipc.sleep_mode = IPC_CMD_DS0; >>> am33xx_pm->ipc.param1 = DS_IPC_DEFAULT; >>> am33xx_pm->ipc.param2 = DS_IPC_DEFAULT; >>> + am33xx_pm->ipc.param4 = param4; >>> >>> am33xx_pm_ipc_cmd(&am33xx_pm->ipc); >>> >>> @@ -386,6 +413,62 @@ static int __init am33xx_map_emif(void) >>> return 0; >>> } >>> >>> +static int __init am33xx_setup_sleep_sequence(void) >>> +{ >>> + int ret; >>> + int sz; >>> + const void *prop; >>> + struct device *dev; >>> + u32 freq_hz = 100000; >> >> Magic number? > > It's taken from drivers/i2c/busses/i2c-omap.c > > u32 freq = 100000; /* default to 100000 Hz */ > > I'll add a comment to that effect. > >>> + unsigned short freq_khz; >>> + >>> + /* >>> + * We put the device tree node in the I2C controller that will >>> + * be sending the sequence. i2c1 is the only controller that can >>> + * be accessed by the firmware as it is the only controller in the >>> + * WKUP domain. >> >> and on which the PMIC sits I believe? > > Yes, but this code is designed not to be PMIC specific as one could > chose to regulate VDD_CORE with any PMIC, or even with a standalone > I2C controlled regulator. > >>> + */ >>> + dev = omap_device_get_by_hwmod_name("i2c1"); >>> + if (IS_ERR(dev)) >>> + return PTR_ERR(dev); >>> + >>> + of_property_read_u32(dev->of_node, "clock-frequency", &freq_hz); >>> + freq_khz = freq_hz / 1000; >> >> Magic number? > > Nah, converting between metric prefixes this way is pretty common in the kernel. > >>> + >>> + prop = of_get_property(dev->of_node, "sleep_sequence", &sz); >>> + if (prop) { >>> + /* >>> + * Length is sequence length + 2 bytes for freq_khz, and 1 >>> + * byte for terminator. >>> + */ >>> + am33xx_i2c_sleep_sequence = kzalloc(sz + 3, GFP_KERNEL); >>> + if (!am33xx_i2c_sleep_sequence) >>> + return -ENOMEM; >>> + put_unaligned_le16(freq_khz, am33xx_i2c_sleep_sequence); >>> + memcpy(am33xx_i2c_sleep_sequence + 2, prop, sz); >> >> so, looking at entire code, it seems there is 3 memory space for same >> data (or 1 original + 2 copy) >> >> 1. in DT >> 2. in am33xx_i2c_[sleep/wake]_sequence >> 3. in SRAm by call to wkup_m3_copy_data() >> >> why not directly copy to SRAM from DT? > > As pointed out above, the firmware reset handler would wipe it out. > >>> + i2c_sleep_sequence_sz = sz + 3; >>> + } >>> + >>> + prop = of_get_property(dev->of_node, "wake_sequence", &sz); >>> + if (prop) { >>> + am33xx_i2c_wake_sequence = kzalloc(sz + 3, GFP_KERNEL); >>> + if (!am33xx_i2c_wake_sequence) { >>> + ret = -ENOMEM; >>> + goto cleanup_sleep; >>> + } >>> + put_unaligned_le16(freq_khz, am33xx_i2c_sleep_sequence); >>> + memcpy(am33xx_i2c_wake_sequence + 2, prop, sz); >>> + i2c_wake_sequence_sz = sz + 3; >>> + } >>> + >>> + return 0; >>> + >>> +cleanup_sleep: >>> + kfree(am33xx_i2c_sleep_sequence); >>> + am33xx_i2c_sleep_sequence = NULL; >>> + return ret; >>> +} >>> + >>> int __init am33xx_pm_init(void) >>> { >>> int ret; >>> @@ -451,6 +534,12 @@ int __init am33xx_pm_init(void) >>> } >>> } >>> >>> + ret = am33xx_setup_sleep_sequence(); >>> + if (ret) { >>> + pr_err("Error fetching I2C sleep/wake sequence\n"); >>> + goto err; >>> + } >>> + >>> (void) clkdm_for_each(omap_pm_clkdms_setup, NULL); >>> >>> /* CEFUSE domain can be turned off post bootup */ >>> diff --git a/arch/arm/mach-omap2/pm33xx.h b/arch/arm/mach-omap2/pm33xx.h >>> index befdd11..d0f08a5 100644 >>> --- a/arch/arm/mach-omap2/pm33xx.h >>> +++ b/arch/arm/mach-omap2/pm33xx.h >>> @@ -52,6 +52,8 @@ struct forced_standby_module { >>> }; >>> >>> int wkup_m3_copy_code(const u8 *data, size_t size); >>> +void wkup_m3_reset_data_pos(void); >>> +int wkup_m3_copy_data(const u8 *data, size_t size); >>> int wkup_m3_prepare(void); >>> void wkup_m3_register_txev_handler(void (*txev_handler)(void)); >>> >>> diff --git a/arch/arm/mach-omap2/wkup_m3.c b/arch/arm/mach-omap2/wkup_m3.c >>> index 8eaa7f3..a541de9 100644 >>> --- a/arch/arm/mach-omap2/wkup_m3.c >>> +++ b/arch/arm/mach-omap2/wkup_m3.c >>> @@ -35,6 +35,9 @@ >>> struct wkup_m3_context { >>> struct device *dev; >>> void __iomem *code; >>> + void __iomem *data; >>> + void __iomem *data_end; >>> + size_t data_size; >>> void (*txev_handler)(void); >>> }; >>> >>> @@ -50,6 +53,30 @@ int wkup_m3_copy_code(const u8 *data, size_t size) >>> return 0; >>> } >>> >>> +/* >>> + * This pair of functions allows data to be stuffed into the end of the >>> + * CM3 data memory. This is currently used for passing the I2C sleep/wake >>> + * sequences to the firmware. >>> + */ >>> + >>> +/* Clear out the pointer for data stored at the end of DMEM */ >>> +void wkup_m3_reset_data_pos(void) >>> +{ >>> + wkup_m3->data_end = wkup_m3->data + wkup_m3->data_size; >>> +} >>> + >>> +/* >>> + * Store a block of data at the end of DMEM, return the offset within DMEM >>> + * that the data is stored at, or -ENOMEM if the data did not fit >>> + */ >>> +int wkup_m3_copy_data(const u8 *data, size_t size) >>> +{ >>> + if (wkup_m3->data + size > wkup_m3->data_end) >>> + return -ENOMEM; >>> + wkup_m3->data_end -= size; >>> + memcpy_toio(wkup_m3->data_end, data, size); >>> + return wkup_m3->data_end - wkup_m3->data; >>> +} >>> >>> void wkup_m3_register_txev_handler(void (*txev_handler)(void)) >>> { >>> @@ -83,7 +110,7 @@ int wkup_m3_prepare(void) >>> static int wkup_m3_probe(struct platform_device *pdev) >>> { >>> int irq, ret = 0; >>> - struct resource *mem; >>> + struct resource *umem, *dmem; >>> >>> pm_runtime_enable(&pdev->dev); >>> >>> @@ -95,14 +122,21 @@ static int wkup_m3_probe(struct platform_device *pdev) >>> >>> irq = platform_get_irq(pdev, 0); >>> if (!irq) { >>> - dev_err(wkup_m3->dev, "no irq resource\n"); >>> + dev_err(&pdev->dev, "no irq resource\n"); >> >> unrelated change?. Better to mention this as code cleanup in commit. > > Will add a comment to that effect, the underlying error should be > fixed in the next suspend/resume patch though. > >>> + ret = -ENXIO; >>> + goto err; >>> + } >>> + >>> + umem = platform_get_resource(pdev, IORESOURCE_MEM, 0); >>> + if (!umem) { >>> + dev_err(&pdev->dev, "no UMEM resource\n"); >>> ret = -ENXIO; >>> goto err; >>> } >>> >>> - mem = platform_get_resource(pdev, IORESOURCE_MEM, 0); >>> - if (!mem) { >>> - dev_err(wkup_m3->dev, "no memory resource\n"); >>> + dmem = platform_get_resource(pdev, IORESOURCE_MEM, 1); >>> + if (!dmem) { >>> + dev_err(&pdev->dev, "no DMEM resource\n"); >>> ret = -ENXIO; >>> goto err; >>> } >>> @@ -116,12 +150,21 @@ static int wkup_m3_probe(struct platform_device *pdev) >>> >>> wkup_m3->dev = &pdev->dev; >>> >>> - wkup_m3->code = devm_request_and_ioremap(wkup_m3->dev, mem); >>> + wkup_m3->code = devm_request_and_ioremap(wkup_m3->dev, umem); >>> + if (!wkup_m3->code) { >>> + dev_err(wkup_m3->dev, "could not ioremap UMEM\n"); >> >> why not use "pdev->dev" here? > > Either one works > >>> + ret = -EADDRNOTAVAIL; >>> + goto err; >>> + } >>> + >>> + wkup_m3->data = devm_request_and_ioremap(wkup_m3->dev, dmem); >>> if (!wkup_m3->code) { >> >> I believe this is just a copy/paste error. s/code/data > > Doh, thanks! > >>> - dev_err(wkup_m3->dev, "could not ioremap\n"); >>> + dev_err(wkup_m3->dev, "could not ioremap DMEM\n"); >> >> same as above. >> >>> ret = -EADDRNOTAVAIL; >>> goto err; >>> } >>> + wkup_m3->data_size = resource_size(dmem); >>> + wkup_m3_reset_data_pos(); >>> >>> ret = devm_request_irq(wkup_m3->dev, irq, wkup_m3_txev_handler, >>> IRQF_DISABLED, "wkup_m3_txev", NULL); >>> -- 1.8.3.2 -- To unsubscribe from this list: send the line "unsubscribe >>> linux-omap" in the body of a message to majordomo at vger.kernel.org More >>> majordomo info at http://vger.kernel.org/majordomo-info.html >>> >> >> >> _______________________________________________ >> linux-arm-kernel mailing list >> linux-arm-kernel at lists.infradead.org >> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 84+ messages in thread
* Re: [PATCH v4 1/4] ARM: OMAP2+: AM33XX: I2C Sleep/wake sequence support 2013-08-19 5:49 ` Gururaja Hebbar @ 2013-08-20 16:33 ` Russ Dill -1 siblings, 0 replies; 84+ messages in thread From: Russ Dill @ 2013-08-20 16:33 UTC (permalink / raw) To: Gururaja Hebbar Cc: Kevin Hilman, devicetree, Devicetree Discuss, linux-omap, Linux ARM Kernel List On Sun, Aug 18, 2013 at 10:49 PM, Gururaja Hebbar <gururaja.hebbar@ti.com> wrote: > > On 8/15/2013 4:04 AM, Russ Dill wrote: > > On Wed, Aug 14, 2013 at 3:18 AM, Gururaja Hebbar <gururaja.hebbar@ti.com> wrote: > >> On 8/14/2013 3:50 AM, Russ Dill wrote: > >>> Changes since v1: > >>> * Rebased onto new am335x PM branch > >>> * Changed to use 5th param register > > >> > > [snip] > [snip] > > >>> + > >>> + wkup_m3_reset_data_pos(); > >>> + if (am33xx_i2c_sleep_sequence) { > >>> + pos = wkup_m3_copy_data(am33xx_i2c_sleep_sequence, > >>> + i2c_sleep_sequence_sz); > >> > >> Why do we need to copy this data (same constant data) on every iteration? > > > > Because the CM3 firmware is reset after each suspend/resume cycle. The > > firmware reset handler reinitializes the DMEM. > > Well in that why can't the i2c payload be copied to UMEM? > > Thanks & regards > Gururaja > I've given this some thought, and gone back and forth a bit. UMEM is a bit more complicated because the linker decides what should go where. Also, it may be that in the future, either the PM for am335x or am43xx will be writing different sequences depending on the suspend mode/options. Is there a specific aspect of copying the data each suspend cycle that you are trying to fix? Is it just that the data could only be copied once? Or is it the latency of the copy? Thanks! ^ permalink raw reply [flat|nested] 84+ messages in thread
* [PATCH v4 1/4] ARM: OMAP2+: AM33XX: I2C Sleep/wake sequence support @ 2013-08-20 16:33 ` Russ Dill 0 siblings, 0 replies; 84+ messages in thread From: Russ Dill @ 2013-08-20 16:33 UTC (permalink / raw) To: linux-arm-kernel On Sun, Aug 18, 2013 at 10:49 PM, Gururaja Hebbar <gururaja.hebbar@ti.com> wrote: > > On 8/15/2013 4:04 AM, Russ Dill wrote: > > On Wed, Aug 14, 2013 at 3:18 AM, Gururaja Hebbar <gururaja.hebbar@ti.com> wrote: > >> On 8/14/2013 3:50 AM, Russ Dill wrote: > >>> Changes since v1: > >>> * Rebased onto new am335x PM branch > >>> * Changed to use 5th param register > > >> > > [snip] > [snip] > > >>> + > >>> + wkup_m3_reset_data_pos(); > >>> + if (am33xx_i2c_sleep_sequence) { > >>> + pos = wkup_m3_copy_data(am33xx_i2c_sleep_sequence, > >>> + i2c_sleep_sequence_sz); > >> > >> Why do we need to copy this data (same constant data) on every iteration? > > > > Because the CM3 firmware is reset after each suspend/resume cycle. The > > firmware reset handler reinitializes the DMEM. > > Well in that why can't the i2c payload be copied to UMEM? > > Thanks & regards > Gururaja > I've given this some thought, and gone back and forth a bit. UMEM is a bit more complicated because the linker decides what should go where. Also, it may be that in the future, either the PM for am335x or am43xx will be writing different sequences depending on the suspend mode/options. Is there a specific aspect of copying the data each suspend cycle that you are trying to fix? Is it just that the data could only be copied once? Or is it the latency of the copy? Thanks! ^ permalink raw reply [flat|nested] 84+ messages in thread
* Re: [PATCH v4 1/4] ARM: OMAP2+: AM33XX: I2C Sleep/wake sequence support 2013-08-20 16:33 ` Russ Dill @ 2013-08-21 8:29 ` Gururaja Hebbar -1 siblings, 0 replies; 84+ messages in thread From: Gururaja Hebbar @ 2013-08-21 8:29 UTC (permalink / raw) To: Russ Dill Cc: Kevin Hilman, devicetree, Devicetree Discuss, linux-omap, Linux ARM Kernel List On 8/20/2013 10:03 PM, Russ Dill wrote: > On Sun, Aug 18, 2013 at 10:49 PM, Gururaja Hebbar > <gururaja.hebbar@ti.com> wrote: >> >> On 8/15/2013 4:04 AM, Russ Dill wrote: >>> On Wed, Aug 14, 2013 at 3:18 AM, Gururaja Hebbar <gururaja.hebbar@ti.com> wrote: >>>> On 8/14/2013 3:50 AM, Russ Dill wrote: >>>>> Changes since v1: >>>>> * Rebased onto new am335x PM branch >>>>> * Changed to use 5th param register >> >>>> >> >> [snip] >> [snip] >> >>>>> + >>>>> + wkup_m3_reset_data_pos(); >>>>> + if (am33xx_i2c_sleep_sequence) { >>>>> + pos = wkup_m3_copy_data(am33xx_i2c_sleep_sequence, >>>>> + i2c_sleep_sequence_sz); >>>> >>>> Why do we need to copy this data (same constant data) on every iteration? >>> >>> Because the CM3 firmware is reset after each suspend/resume cycle. The >>> firmware reset handler reinitializes the DMEM. >> >> Well in that why can't the i2c payload be copied to UMEM? >> >> Thanks & regards >> Gururaja >> > > I've given this some thought, and gone back and forth a bit. UMEM is a > bit more complicated because the linker decides what should go where. but linker doesn't know about the copy and the location we are doing at runtime. > Also, it may be that in the future, either the PM for am335x or am43xx > will be writing different sequences depending on the suspend > mode/options. still these info will be coming from DT and can be copied to UMEM. only issue could be space. > > Is there a specific aspect of copying the data each suspend cycle that > you are trying to fix? Is it just that the data could only be copied > once? Or is it the latency of the copy? Copy latency on every iterations is what worries me. it will surely add a delay for suspend. > > Thanks! > ^ permalink raw reply [flat|nested] 84+ messages in thread
* [PATCH v4 1/4] ARM: OMAP2+: AM33XX: I2C Sleep/wake sequence support @ 2013-08-21 8:29 ` Gururaja Hebbar 0 siblings, 0 replies; 84+ messages in thread From: Gururaja Hebbar @ 2013-08-21 8:29 UTC (permalink / raw) To: linux-arm-kernel On 8/20/2013 10:03 PM, Russ Dill wrote: > On Sun, Aug 18, 2013 at 10:49 PM, Gururaja Hebbar > <gururaja.hebbar@ti.com> wrote: >> >> On 8/15/2013 4:04 AM, Russ Dill wrote: >>> On Wed, Aug 14, 2013 at 3:18 AM, Gururaja Hebbar <gururaja.hebbar@ti.com> wrote: >>>> On 8/14/2013 3:50 AM, Russ Dill wrote: >>>>> Changes since v1: >>>>> * Rebased onto new am335x PM branch >>>>> * Changed to use 5th param register >> >>>> >> >> [snip] >> [snip] >> >>>>> + >>>>> + wkup_m3_reset_data_pos(); >>>>> + if (am33xx_i2c_sleep_sequence) { >>>>> + pos = wkup_m3_copy_data(am33xx_i2c_sleep_sequence, >>>>> + i2c_sleep_sequence_sz); >>>> >>>> Why do we need to copy this data (same constant data) on every iteration? >>> >>> Because the CM3 firmware is reset after each suspend/resume cycle. The >>> firmware reset handler reinitializes the DMEM. >> >> Well in that why can't the i2c payload be copied to UMEM? >> >> Thanks & regards >> Gururaja >> > > I've given this some thought, and gone back and forth a bit. UMEM is a > bit more complicated because the linker decides what should go where. but linker doesn't know about the copy and the location we are doing at runtime. > Also, it may be that in the future, either the PM for am335x or am43xx > will be writing different sequences depending on the suspend > mode/options. still these info will be coming from DT and can be copied to UMEM. only issue could be space. > > Is there a specific aspect of copying the data each suspend cycle that > you are trying to fix? Is it just that the data could only be copied > once? Or is it the latency of the copy? Copy latency on every iterations is what worries me. it will surely add a delay for suspend. > > Thanks! > ^ permalink raw reply [flat|nested] 84+ messages in thread
* [PATCH v4 2/4] ARM: dts: add AM33XX vdd core opp50 suspend for Beaglebone. 2013-08-13 22:20 ` Russ Dill @ 2013-08-13 22:20 ` Russ Dill -1 siblings, 0 replies; 84+ messages in thread From: Russ Dill @ 2013-08-13 22:20 UTC (permalink / raw) To: linux-omap; +Cc: devicetree, Kevin Hilman, linux-arm-kernel, devicetree-discuss Changes since v1: * Rebased onto new am335x PM branch This adds a sleep and wake sequence to set the VDD core voltage to the OPP50 level, 0.950V. This saves power during suspend. The sequences are specific to the Beaglebone layout and PMIC, the TPS65217. The sequences are written out by the Cortex-M3. Signed-off-by: Russ Dill <Russ.Dill@ti.com> --- arch/arm/boot/dts/am335x-bone.dts | 25 ++++++++++++++++++++++++- 1 file changed, 24 insertions(+), 1 deletion(-) diff --git a/arch/arm/boot/dts/am335x-bone.dts b/arch/arm/boot/dts/am335x-bone.dts index 444b4ed..3f6528d 100644 --- a/arch/arm/boot/dts/am335x-bone.dts +++ b/arch/arm/boot/dts/am335x-bone.dts @@ -127,10 +127,33 @@ status = "okay"; clock-frequency = <400000>; + /* Set OPP50 (0.95V) for VDD core */ + sleep_sequence = /bits/ 8 < + 0x02 0x24 0x0b 0x6d /* Password unlock 1 */ + 0x02 0x24 0x10 0x02 /* Set DCDC3 to 0.95V */ + 0x02 0x24 0x0b 0x6d /* Password unlock 2 */ + 0x02 0x24 0x10 0x02 /* Set DCDC3 to 0.95V */ + 0x02 0x24 0x0b 0x6c /* Password unlock 1 */ + 0x02 0x24 0x11 0x86 /* Apply DCDC changes */ + 0x02 0x24 0x0b 0x6c /* Password unlock 2 */ + 0x02 0x24 0x11 0x86 /* Apply DCDC changes */ + >; + + /* Set OPP100 (1.10V) for VDD core */ + wake_sequence = /bits/ 8 < + 0x02 0x24 0x0b 0x6d /* Password unlock 1 */ + 0x02 0x24 0x10 0x08 /* Set DCDC3 to 1.1V */ + 0x02 0x24 0x0b 0x6d /* Password unlock 2 */ + 0x02 0x24 0x10 0x08 /* Set DCDC3 to 1.1V */ + 0x02 0x24 0x0b 0x6c /* Password unlock 1 */ + 0x02 0x24 0x11 0x86 /* Apply DCDC changes */ + 0x02 0x24 0x0b 0x6c /* Password unlock 2 */ + 0x02 0x24 0x11 0x86 /* Apply DCDC changes */ + >; + tps: tps@24 { reg = <0x24>; }; - }; }; -- 1.8.3.2 ^ permalink raw reply related [flat|nested] 84+ messages in thread
* [PATCH v4 2/4] ARM: dts: add AM33XX vdd core opp50 suspend for Beaglebone. @ 2013-08-13 22:20 ` Russ Dill 0 siblings, 0 replies; 84+ messages in thread From: Russ Dill @ 2013-08-13 22:20 UTC (permalink / raw) To: linux-arm-kernel Changes since v1: * Rebased onto new am335x PM branch This adds a sleep and wake sequence to set the VDD core voltage to the OPP50 level, 0.950V. This saves power during suspend. The sequences are specific to the Beaglebone layout and PMIC, the TPS65217. The sequences are written out by the Cortex-M3. Signed-off-by: Russ Dill <Russ.Dill@ti.com> --- arch/arm/boot/dts/am335x-bone.dts | 25 ++++++++++++++++++++++++- 1 file changed, 24 insertions(+), 1 deletion(-) diff --git a/arch/arm/boot/dts/am335x-bone.dts b/arch/arm/boot/dts/am335x-bone.dts index 444b4ed..3f6528d 100644 --- a/arch/arm/boot/dts/am335x-bone.dts +++ b/arch/arm/boot/dts/am335x-bone.dts @@ -127,10 +127,33 @@ status = "okay"; clock-frequency = <400000>; + /* Set OPP50 (0.95V) for VDD core */ + sleep_sequence = /bits/ 8 < + 0x02 0x24 0x0b 0x6d /* Password unlock 1 */ + 0x02 0x24 0x10 0x02 /* Set DCDC3 to 0.95V */ + 0x02 0x24 0x0b 0x6d /* Password unlock 2 */ + 0x02 0x24 0x10 0x02 /* Set DCDC3 to 0.95V */ + 0x02 0x24 0x0b 0x6c /* Password unlock 1 */ + 0x02 0x24 0x11 0x86 /* Apply DCDC changes */ + 0x02 0x24 0x0b 0x6c /* Password unlock 2 */ + 0x02 0x24 0x11 0x86 /* Apply DCDC changes */ + >; + + /* Set OPP100 (1.10V) for VDD core */ + wake_sequence = /bits/ 8 < + 0x02 0x24 0x0b 0x6d /* Password unlock 1 */ + 0x02 0x24 0x10 0x08 /* Set DCDC3 to 1.1V */ + 0x02 0x24 0x0b 0x6d /* Password unlock 2 */ + 0x02 0x24 0x10 0x08 /* Set DCDC3 to 1.1V */ + 0x02 0x24 0x0b 0x6c /* Password unlock 1 */ + 0x02 0x24 0x11 0x86 /* Apply DCDC changes */ + 0x02 0x24 0x0b 0x6c /* Password unlock 2 */ + 0x02 0x24 0x11 0x86 /* Apply DCDC changes */ + >; + tps: tps at 24 { reg = <0x24>; }; - }; }; -- 1.8.3.2 ^ permalink raw reply related [flat|nested] 84+ messages in thread
* Re: [PATCH v4 2/4] ARM: dts: add AM33XX vdd core opp50 suspend for Beaglebone. 2013-08-13 22:20 ` Russ Dill @ 2013-08-14 8:59 ` Gururaja Hebbar -1 siblings, 0 replies; 84+ messages in thread From: Gururaja Hebbar @ 2013-08-14 8:59 UTC (permalink / raw) To: Russ Dill Cc: Kevin Hilman, devicetree, devicetree-discuss, linux-omap, linux-arm-kernel On 8/14/2013 3:50 AM, Russ Dill wrote: > Changes since v1: > * Rebased onto new am335x PM branch > > This adds a sleep and wake sequence to set the VDD core voltage to the > OPP50 level, 0.950V. This saves power during suspend. The sequences are > specific to the Beaglebone layout and PMIC, the TPS65217. The sequences > are written out by the Cortex-M3. > > Signed-off-by: Russ Dill <Russ.Dill@ti.com> > --- > arch/arm/boot/dts/am335x-bone.dts | 25 ++++++++++++++++++++++++- > 1 file changed, 24 insertions(+), 1 deletion(-) > > diff --git a/arch/arm/boot/dts/am335x-bone.dts b/arch/arm/boot/dts/am335x-bone.dts > index 444b4ed..3f6528d 100644 > --- a/arch/arm/boot/dts/am335x-bone.dts > +++ b/arch/arm/boot/dts/am335x-bone.dts > @@ -127,10 +127,33 @@ > status = "okay"; > clock-frequency = <400000>; > > + /* Set OPP50 (0.95V) for VDD core */ > + sleep_sequence = /bits/ 8 < For user readability, can you mention the PMIC used here as a comment? > + 0x02 0x24 0x0b 0x6d /* Password unlock 1 */ > + 0x02 0x24 0x10 0x02 /* Set DCDC3 to 0.95V */ > + 0x02 0x24 0x0b 0x6d /* Password unlock 2 */ > + 0x02 0x24 0x10 0x02 /* Set DCDC3 to 0.95V */ > + 0x02 0x24 0x0b 0x6c /* Password unlock 1 */ > + 0x02 0x24 0x11 0x86 /* Apply DCDC changes */ > + 0x02 0x24 0x0b 0x6c /* Password unlock 2 */ > + 0x02 0x24 0x11 0x86 /* Apply DCDC changes */ > + >; > + > + /* Set OPP100 (1.10V) for VDD core */ > + wake_sequence = /bits/ 8 < > + 0x02 0x24 0x0b 0x6d /* Password unlock 1 */ > + 0x02 0x24 0x10 0x08 /* Set DCDC3 to 1.1V */ > + 0x02 0x24 0x0b 0x6d /* Password unlock 2 */ > + 0x02 0x24 0x10 0x08 /* Set DCDC3 to 1.1V */ > + 0x02 0x24 0x0b 0x6c /* Password unlock 1 */ > + 0x02 0x24 0x11 0x86 /* Apply DCDC changes */ > + 0x02 0x24 0x0b 0x6c /* Password unlock 2 */ > + 0x02 0x24 0x11 0x86 /* Apply DCDC changes */ > + >; > + > tps: tps@24 { > reg = <0x24>; > }; > - > }; > }; > > ^ permalink raw reply [flat|nested] 84+ messages in thread
* [PATCH v4 2/4] ARM: dts: add AM33XX vdd core opp50 suspend for Beaglebone. @ 2013-08-14 8:59 ` Gururaja Hebbar 0 siblings, 0 replies; 84+ messages in thread From: Gururaja Hebbar @ 2013-08-14 8:59 UTC (permalink / raw) To: linux-arm-kernel On 8/14/2013 3:50 AM, Russ Dill wrote: > Changes since v1: > * Rebased onto new am335x PM branch > > This adds a sleep and wake sequence to set the VDD core voltage to the > OPP50 level, 0.950V. This saves power during suspend. The sequences are > specific to the Beaglebone layout and PMIC, the TPS65217. The sequences > are written out by the Cortex-M3. > > Signed-off-by: Russ Dill <Russ.Dill@ti.com> > --- > arch/arm/boot/dts/am335x-bone.dts | 25 ++++++++++++++++++++++++- > 1 file changed, 24 insertions(+), 1 deletion(-) > > diff --git a/arch/arm/boot/dts/am335x-bone.dts b/arch/arm/boot/dts/am335x-bone.dts > index 444b4ed..3f6528d 100644 > --- a/arch/arm/boot/dts/am335x-bone.dts > +++ b/arch/arm/boot/dts/am335x-bone.dts > @@ -127,10 +127,33 @@ > status = "okay"; > clock-frequency = <400000>; > > + /* Set OPP50 (0.95V) for VDD core */ > + sleep_sequence = /bits/ 8 < For user readability, can you mention the PMIC used here as a comment? > + 0x02 0x24 0x0b 0x6d /* Password unlock 1 */ > + 0x02 0x24 0x10 0x02 /* Set DCDC3 to 0.95V */ > + 0x02 0x24 0x0b 0x6d /* Password unlock 2 */ > + 0x02 0x24 0x10 0x02 /* Set DCDC3 to 0.95V */ > + 0x02 0x24 0x0b 0x6c /* Password unlock 1 */ > + 0x02 0x24 0x11 0x86 /* Apply DCDC changes */ > + 0x02 0x24 0x0b 0x6c /* Password unlock 2 */ > + 0x02 0x24 0x11 0x86 /* Apply DCDC changes */ > + >; > + > + /* Set OPP100 (1.10V) for VDD core */ > + wake_sequence = /bits/ 8 < > + 0x02 0x24 0x0b 0x6d /* Password unlock 1 */ > + 0x02 0x24 0x10 0x08 /* Set DCDC3 to 1.1V */ > + 0x02 0x24 0x0b 0x6d /* Password unlock 2 */ > + 0x02 0x24 0x10 0x08 /* Set DCDC3 to 1.1V */ > + 0x02 0x24 0x0b 0x6c /* Password unlock 1 */ > + 0x02 0x24 0x11 0x86 /* Apply DCDC changes */ > + 0x02 0x24 0x0b 0x6c /* Password unlock 2 */ > + 0x02 0x24 0x11 0x86 /* Apply DCDC changes */ > + >; > + > tps: tps at 24 { > reg = <0x24>; > }; > - > }; > }; > > ^ permalink raw reply [flat|nested] 84+ messages in thread
* Re: [PATCH v4 2/4] ARM: dts: add AM33XX vdd core opp50 suspend for Beaglebone. 2013-08-14 8:59 ` Gururaja Hebbar @ 2013-08-14 22:21 ` Russ Dill -1 siblings, 0 replies; 84+ messages in thread From: Russ Dill @ 2013-08-14 22:21 UTC (permalink / raw) To: Gururaja Hebbar Cc: Kevin Hilman, devicetree, devicetree-discuss, linux-omap, linux-arm-kernel On Wed, Aug 14, 2013 at 1:59 AM, Gururaja Hebbar <gururaja.hebbar@ti.com> wrote: > On 8/14/2013 3:50 AM, Russ Dill wrote: >> Changes since v1: >> * Rebased onto new am335x PM branch >> >> This adds a sleep and wake sequence to set the VDD core voltage to the >> OPP50 level, 0.950V. This saves power during suspend. The sequences are >> specific to the Beaglebone layout and PMIC, the TPS65217. The sequences >> are written out by the Cortex-M3. >> >> Signed-off-by: Russ Dill <Russ.Dill@ti.com> >> --- >> arch/arm/boot/dts/am335x-bone.dts | 25 ++++++++++++++++++++++++- >> 1 file changed, 24 insertions(+), 1 deletion(-) >> >> diff --git a/arch/arm/boot/dts/am335x-bone.dts b/arch/arm/boot/dts/am335x-bone.dts >> index 444b4ed..3f6528d 100644 >> --- a/arch/arm/boot/dts/am335x-bone.dts >> +++ b/arch/arm/boot/dts/am335x-bone.dts >> @@ -127,10 +127,33 @@ >> status = "okay"; >> clock-frequency = <400000>; >> >> + /* Set OPP50 (0.95V) for VDD core */ >> + sleep_sequence = /bits/ 8 < > > For user readability, can you mention the PMIC used here as a comment? Sounds like a good modification, will do. >> + 0x02 0x24 0x0b 0x6d /* Password unlock 1 */ >> + 0x02 0x24 0x10 0x02 /* Set DCDC3 to 0.95V */ >> + 0x02 0x24 0x0b 0x6d /* Password unlock 2 */ >> + 0x02 0x24 0x10 0x02 /* Set DCDC3 to 0.95V */ >> + 0x02 0x24 0x0b 0x6c /* Password unlock 1 */ >> + 0x02 0x24 0x11 0x86 /* Apply DCDC changes */ >> + 0x02 0x24 0x0b 0x6c /* Password unlock 2 */ >> + 0x02 0x24 0x11 0x86 /* Apply DCDC changes */ >> + >; >> + >> + /* Set OPP100 (1.10V) for VDD core */ >> + wake_sequence = /bits/ 8 < >> + 0x02 0x24 0x0b 0x6d /* Password unlock 1 */ >> + 0x02 0x24 0x10 0x08 /* Set DCDC3 to 1.1V */ >> + 0x02 0x24 0x0b 0x6d /* Password unlock 2 */ >> + 0x02 0x24 0x10 0x08 /* Set DCDC3 to 1.1V */ >> + 0x02 0x24 0x0b 0x6c /* Password unlock 1 */ >> + 0x02 0x24 0x11 0x86 /* Apply DCDC changes */ >> + 0x02 0x24 0x0b 0x6c /* Password unlock 2 */ >> + 0x02 0x24 0x11 0x86 /* Apply DCDC changes */ >> + >; >> + >> tps: tps@24 { >> reg = <0x24>; >> }; >> - >> }; >> }; >> >> > > > _______________________________________________ > linux-arm-kernel mailing list > linux-arm-kernel@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 84+ messages in thread
* [PATCH v4 2/4] ARM: dts: add AM33XX vdd core opp50 suspend for Beaglebone. @ 2013-08-14 22:21 ` Russ Dill 0 siblings, 0 replies; 84+ messages in thread From: Russ Dill @ 2013-08-14 22:21 UTC (permalink / raw) To: linux-arm-kernel On Wed, Aug 14, 2013 at 1:59 AM, Gururaja Hebbar <gururaja.hebbar@ti.com> wrote: > On 8/14/2013 3:50 AM, Russ Dill wrote: >> Changes since v1: >> * Rebased onto new am335x PM branch >> >> This adds a sleep and wake sequence to set the VDD core voltage to the >> OPP50 level, 0.950V. This saves power during suspend. The sequences are >> specific to the Beaglebone layout and PMIC, the TPS65217. The sequences >> are written out by the Cortex-M3. >> >> Signed-off-by: Russ Dill <Russ.Dill@ti.com> >> --- >> arch/arm/boot/dts/am335x-bone.dts | 25 ++++++++++++++++++++++++- >> 1 file changed, 24 insertions(+), 1 deletion(-) >> >> diff --git a/arch/arm/boot/dts/am335x-bone.dts b/arch/arm/boot/dts/am335x-bone.dts >> index 444b4ed..3f6528d 100644 >> --- a/arch/arm/boot/dts/am335x-bone.dts >> +++ b/arch/arm/boot/dts/am335x-bone.dts >> @@ -127,10 +127,33 @@ >> status = "okay"; >> clock-frequency = <400000>; >> >> + /* Set OPP50 (0.95V) for VDD core */ >> + sleep_sequence = /bits/ 8 < > > For user readability, can you mention the PMIC used here as a comment? Sounds like a good modification, will do. >> + 0x02 0x24 0x0b 0x6d /* Password unlock 1 */ >> + 0x02 0x24 0x10 0x02 /* Set DCDC3 to 0.95V */ >> + 0x02 0x24 0x0b 0x6d /* Password unlock 2 */ >> + 0x02 0x24 0x10 0x02 /* Set DCDC3 to 0.95V */ >> + 0x02 0x24 0x0b 0x6c /* Password unlock 1 */ >> + 0x02 0x24 0x11 0x86 /* Apply DCDC changes */ >> + 0x02 0x24 0x0b 0x6c /* Password unlock 2 */ >> + 0x02 0x24 0x11 0x86 /* Apply DCDC changes */ >> + >; >> + >> + /* Set OPP100 (1.10V) for VDD core */ >> + wake_sequence = /bits/ 8 < >> + 0x02 0x24 0x0b 0x6d /* Password unlock 1 */ >> + 0x02 0x24 0x10 0x08 /* Set DCDC3 to 1.1V */ >> + 0x02 0x24 0x0b 0x6d /* Password unlock 2 */ >> + 0x02 0x24 0x10 0x08 /* Set DCDC3 to 1.1V */ >> + 0x02 0x24 0x0b 0x6c /* Password unlock 1 */ >> + 0x02 0x24 0x11 0x86 /* Apply DCDC changes */ >> + 0x02 0x24 0x0b 0x6c /* Password unlock 2 */ >> + 0x02 0x24 0x11 0x86 /* Apply DCDC changes */ >> + >; >> + >> tps: tps at 24 { >> reg = <0x24>; >> }; >> - >> }; >> }; >> >> > > > _______________________________________________ > linux-arm-kernel mailing list > linux-arm-kernel at lists.infradead.org > http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 84+ messages in thread
* [PATCH v4 3/4] ARM: dts: add AM33XX vdd core opp50 suspend for AM335X GP EVM. 2013-08-13 22:20 ` Russ Dill @ 2013-08-13 22:20 ` Russ Dill -1 siblings, 0 replies; 84+ messages in thread From: Russ Dill @ 2013-08-13 22:20 UTC (permalink / raw) To: linux-omap; +Cc: devicetree, Kevin Hilman, linux-arm-kernel, devicetree-discuss From: Hebbar, Gururaja <gururaja.hebbar@ti.com> This adds a sleep and wake sequence to set the VDD core voltage to the OPP50 level, 0.950V. This saves power during suspend. The sequences are specific to the EVM layout and PMIC, the TPS65910. The sequences are written out by the Cortex-M3. Signed-off-by: Hebbar, Gururaja <gururaja.hebbar@ti.com> Signed-off-by: Russ Dill <Russ.Dill@ti.com> --- arch/arm/boot/dts/am335x-evm.dts | 10 ++++++++++ 1 file changed, 10 insertions(+) diff --git a/arch/arm/boot/dts/am335x-evm.dts b/arch/arm/boot/dts/am335x-evm.dts index 3aee1a4..81ce169 100644 --- a/arch/arm/boot/dts/am335x-evm.dts +++ b/arch/arm/boot/dts/am335x-evm.dts @@ -166,6 +166,16 @@ status = "okay"; clock-frequency = <400000>; + /* Set OPP50 (0.95V) for VDD core */ + sleep_sequence = /bits/ 8 < + 0x02 0x2d 0x25 0x1f /* Set VDD2 to 0.95V */ + >; + + /* Set OPP100 (1.10V) for VDD core */ + wake_sequence = /bits/ 8 < + 0x02 0x2d 0x25 0x2b /* Set VDD2 to 1.1V */ + >; + tps: tps@2d { reg = <0x2d>; }; -- 1.8.3.2 ^ permalink raw reply related [flat|nested] 84+ messages in thread
* [PATCH v4 3/4] ARM: dts: add AM33XX vdd core opp50 suspend for AM335X GP EVM. @ 2013-08-13 22:20 ` Russ Dill 0 siblings, 0 replies; 84+ messages in thread From: Russ Dill @ 2013-08-13 22:20 UTC (permalink / raw) To: linux-arm-kernel From: Hebbar, Gururaja <gururaja.hebbar@ti.com> This adds a sleep and wake sequence to set the VDD core voltage to the OPP50 level, 0.950V. This saves power during suspend. The sequences are specific to the EVM layout and PMIC, the TPS65910. The sequences are written out by the Cortex-M3. Signed-off-by: Hebbar, Gururaja <gururaja.hebbar@ti.com> Signed-off-by: Russ Dill <Russ.Dill@ti.com> --- arch/arm/boot/dts/am335x-evm.dts | 10 ++++++++++ 1 file changed, 10 insertions(+) diff --git a/arch/arm/boot/dts/am335x-evm.dts b/arch/arm/boot/dts/am335x-evm.dts index 3aee1a4..81ce169 100644 --- a/arch/arm/boot/dts/am335x-evm.dts +++ b/arch/arm/boot/dts/am335x-evm.dts @@ -166,6 +166,16 @@ status = "okay"; clock-frequency = <400000>; + /* Set OPP50 (0.95V) for VDD core */ + sleep_sequence = /bits/ 8 < + 0x02 0x2d 0x25 0x1f /* Set VDD2 to 0.95V */ + >; + + /* Set OPP100 (1.10V) for VDD core */ + wake_sequence = /bits/ 8 < + 0x02 0x2d 0x25 0x2b /* Set VDD2 to 1.1V */ + >; + tps: tps at 2d { reg = <0x2d>; }; -- 1.8.3.2 ^ permalink raw reply related [flat|nested] 84+ messages in thread
* [PATCH v4 4/4] ARM: dts: AM33XX vdd core opp50 suspend for EVM-SK 2013-08-13 22:20 ` Russ Dill @ 2013-08-13 22:20 ` Russ Dill -1 siblings, 0 replies; 84+ messages in thread From: Russ Dill @ 2013-08-13 22:20 UTC (permalink / raw) To: linux-omap; +Cc: devicetree, Kevin Hilman, linux-arm-kernel, devicetree-discuss From: Hebbar, Gururaja <gururaja.hebbar@ti.com> This adds a sleep and wake sequence to set the VDD core voltage to the OPP50 level, 0.950V. This saves power during suspend. The sequences are specific to the EVM-SK layout and PMIC, the TPS65910. The sequences are written out by the Cortex-M3. Signed-off-by: Hebbar, Gururaja <gururaja.hebbar@ti.com> Signed-off-by: Russ Dill <Russ.Dill@ti.com> --- arch/arm/boot/dts/am335x-evmsk.dts | 10 ++++++++++ 1 file changed, 10 insertions(+) diff --git a/arch/arm/boot/dts/am335x-evmsk.dts b/arch/arm/boot/dts/am335x-evmsk.dts index 0c8ad17..704bbb3 100644 --- a/arch/arm/boot/dts/am335x-evmsk.dts +++ b/arch/arm/boot/dts/am335x-evmsk.dts @@ -174,6 +174,16 @@ status = "okay"; clock-frequency = <400000>; + /* Set OPP50 (0.95V) for VDD core */ + sleep_sequence = /bits/ 8 < + 0x02 0x2d 0x25 0x1f /* Set VDD2 to 0.95V */ + >; + + /* Set OPP100 (1.10V) for VDD core */ + wake_sequence = /bits/ 8 < + 0x02 0x2d 0x25 0x2b /* Set VDD2 to 1.1V */ + >; + tps: tps@2d { reg = <0x2d>; }; -- 1.8.3.2 ^ permalink raw reply related [flat|nested] 84+ messages in thread
* [PATCH v4 4/4] ARM: dts: AM33XX vdd core opp50 suspend for EVM-SK @ 2013-08-13 22:20 ` Russ Dill 0 siblings, 0 replies; 84+ messages in thread From: Russ Dill @ 2013-08-13 22:20 UTC (permalink / raw) To: linux-arm-kernel From: Hebbar, Gururaja <gururaja.hebbar@ti.com> This adds a sleep and wake sequence to set the VDD core voltage to the OPP50 level, 0.950V. This saves power during suspend. The sequences are specific to the EVM-SK layout and PMIC, the TPS65910. The sequences are written out by the Cortex-M3. Signed-off-by: Hebbar, Gururaja <gururaja.hebbar@ti.com> Signed-off-by: Russ Dill <Russ.Dill@ti.com> --- arch/arm/boot/dts/am335x-evmsk.dts | 10 ++++++++++ 1 file changed, 10 insertions(+) diff --git a/arch/arm/boot/dts/am335x-evmsk.dts b/arch/arm/boot/dts/am335x-evmsk.dts index 0c8ad17..704bbb3 100644 --- a/arch/arm/boot/dts/am335x-evmsk.dts +++ b/arch/arm/boot/dts/am335x-evmsk.dts @@ -174,6 +174,16 @@ status = "okay"; clock-frequency = <400000>; + /* Set OPP50 (0.95V) for VDD core */ + sleep_sequence = /bits/ 8 < + 0x02 0x2d 0x25 0x1f /* Set VDD2 to 0.95V */ + >; + + /* Set OPP100 (1.10V) for VDD core */ + wake_sequence = /bits/ 8 < + 0x02 0x2d 0x25 0x2b /* Set VDD2 to 1.1V */ + >; + tps: tps at 2d { reg = <0x2d>; }; -- 1.8.3.2 ^ permalink raw reply related [flat|nested] 84+ messages in thread
* Re: [PATCH v4 0/4] ARM: OMAP2+: AM33XX: VDD CORE OPP50 support 2013-08-13 22:20 ` Russ Dill @ 2013-08-14 13:38 ` Jan Lübbe -1 siblings, 0 replies; 84+ messages in thread From: Jan Lübbe @ 2013-08-14 13:38 UTC (permalink / raw) To: Russ Dill Cc: Kevin Hilman, devicetree, devicetree-discuss, linux-omap, linux-arm-kernel On Tue, 2013-08-13 at 15:20 -0700, Russ Dill wrote: > The purpose and method of executing these sequences is left up to each > platform. In the case of the am33xx, the CM3 firmware writes out the > simple I2C sequences. > > Each sequence is a series of I2C write commands. The first byte is the > length of the write, the second byte the I2C device to address, and > the following bytes are the message. > /* Set OPP100 (1.10V) for VDD core */ > wake_sequence = /bits/ 8 < > 0x02 0x2d 0x25 0x2b /* Set VDD2 to 1.1V */ > >; > > tps: tps@2d { > reg = <0x2d>; > }; > In the above example, the sequence "0x25 0x1f" is written to the I2C > device at address 0x2d (the TPS65910 PMIC). The PMIC interprets that > as a write to a register at address 0x25. > I'd really like to get some feedback on the devicetree bindings. Shouldn't the TPS driver know how to generate this sequence? It seems fragile to do voltage adjustments behind the back of the regulator framework and the TPS driver. The wake-sequence values should match the (in-memory) regulator configuration on resume (which may have been changed by DVFS). The CM3 driver needs to figure out where the core regulator is connected using using either DT or the regulator framework and ask the TPS (via a new interface) for register writes for sleep/wake sequences. Then those sequences will actually match the correct voltages configured using DT/DVFS. Regards, Jan -- Pengutronix e.K. | | Industrial Linux Solutions | http://www.pengutronix.de/ | Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 | Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 | ^ permalink raw reply [flat|nested] 84+ messages in thread
* [PATCH v4 0/4] ARM: OMAP2+: AM33XX: VDD CORE OPP50 support @ 2013-08-14 13:38 ` Jan Lübbe 0 siblings, 0 replies; 84+ messages in thread From: Jan Lübbe @ 2013-08-14 13:38 UTC (permalink / raw) To: linux-arm-kernel On Tue, 2013-08-13 at 15:20 -0700, Russ Dill wrote: > The purpose and method of executing these sequences is left up to each > platform. In the case of the am33xx, the CM3 firmware writes out the > simple I2C sequences. > > Each sequence is a series of I2C write commands. The first byte is the > length of the write, the second byte the I2C device to address, and > the following bytes are the message. > /* Set OPP100 (1.10V) for VDD core */ > wake_sequence = /bits/ 8 < > 0x02 0x2d 0x25 0x2b /* Set VDD2 to 1.1V */ > >; > > tps: tps at 2d { > reg = <0x2d>; > }; > In the above example, the sequence "0x25 0x1f" is written to the I2C > device at address 0x2d (the TPS65910 PMIC). The PMIC interprets that > as a write to a register at address 0x25. > I'd really like to get some feedback on the devicetree bindings. Shouldn't the TPS driver know how to generate this sequence? It seems fragile to do voltage adjustments behind the back of the regulator framework and the TPS driver. The wake-sequence values should match the (in-memory) regulator configuration on resume (which may have been changed by DVFS). The CM3 driver needs to figure out where the core regulator is connected using using either DT or the regulator framework and ask the TPS (via a new interface) for register writes for sleep/wake sequences. Then those sequences will actually match the correct voltages configured using DT/DVFS. Regards, Jan -- Pengutronix e.K. | | Industrial Linux Solutions | http://www.pengutronix.de/ | Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 | Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 | ^ permalink raw reply [flat|nested] 84+ messages in thread
* Re: [PATCH v4 0/4] ARM: OMAP2+: AM33XX: VDD CORE OPP50 support 2013-08-14 13:38 ` Jan Lübbe @ 2013-08-14 22:21 ` Russ Dill -1 siblings, 0 replies; 84+ messages in thread From: Russ Dill @ 2013-08-14 22:21 UTC (permalink / raw) To: Jan Lübbe Cc: Kevin Hilman, devicetree, devicetree-discuss, linux-omap, linux-arm-kernel On Wed, Aug 14, 2013 at 6:38 AM, Jan Lübbe <jlu@pengutronix.de> wrote: > On Tue, 2013-08-13 at 15:20 -0700, Russ Dill wrote: >> The purpose and method of executing these sequences is left up to each >> platform. In the case of the am33xx, the CM3 firmware writes out the >> simple I2C sequences. >> >> Each sequence is a series of I2C write commands. The first byte is the >> length of the write, the second byte the I2C device to address, and >> the following bytes are the message. > >> /* Set OPP100 (1.10V) for VDD core */ >> wake_sequence = /bits/ 8 < >> 0x02 0x2d 0x25 0x2b /* Set VDD2 to 1.1V */ >> >; >> >> tps: tps@2d { >> reg = <0x2d>; >> }; > >> In the above example, the sequence "0x25 0x1f" is written to the I2C >> device at address 0x2d (the TPS65910 PMIC). The PMIC interprets that >> as a write to a register at address 0x25. > >> I'd really like to get some feedback on the devicetree bindings. > > Shouldn't the TPS driver know how to generate this sequence? It seems > fragile to do voltage adjustments behind the back of the regulator > framework and the TPS driver. The wake-sequence values should match the > (in-memory) regulator configuration on resume (which may have been > changed by DVFS). The sequence is both PMIC specific and board specific. Additionally, the PMICs used aren't am335x specific. It would be nice to have the regulator framework and the driver write all this out, but the sequence is written out by the Cortex-M3 processor running some PM firmware. Even if the code was changed to run on the A8, it'd have to run from a small piece of SRAM. As far as DVFS, I'm not aware of any DVFS implementations that muck with VDD CORE. > The CM3 driver needs to figure out where the core regulator is connected > using using either DT or the regulator framework and ask the TPS (via a > new interface) for register writes for sleep/wake sequences. Then those > sequences will actually match the correct voltages configured using > DT/DVFS. That seems like it'd add a lot of complexity to the regulator subsystem, as well as all the PMIC and other I2C regulators that any users of these device tree properties may end up using for not a lot of gain. There would be two separate code paths for any used I2C regulator or PMIC for setting voltages. > Regards, > Jan > -- > Pengutronix e.K. | | > Industrial Linux Solutions | http://www.pengutronix.de/ | > Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 | > Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 | > > > _______________________________________________ > linux-arm-kernel mailing list > linux-arm-kernel@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/linux-arm-kernel -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 84+ messages in thread
* [PATCH v4 0/4] ARM: OMAP2+: AM33XX: VDD CORE OPP50 support @ 2013-08-14 22:21 ` Russ Dill 0 siblings, 0 replies; 84+ messages in thread From: Russ Dill @ 2013-08-14 22:21 UTC (permalink / raw) To: linux-arm-kernel On Wed, Aug 14, 2013 at 6:38 AM, Jan L?bbe <jlu@pengutronix.de> wrote: > On Tue, 2013-08-13 at 15:20 -0700, Russ Dill wrote: >> The purpose and method of executing these sequences is left up to each >> platform. In the case of the am33xx, the CM3 firmware writes out the >> simple I2C sequences. >> >> Each sequence is a series of I2C write commands. The first byte is the >> length of the write, the second byte the I2C device to address, and >> the following bytes are the message. > >> /* Set OPP100 (1.10V) for VDD core */ >> wake_sequence = /bits/ 8 < >> 0x02 0x2d 0x25 0x2b /* Set VDD2 to 1.1V */ >> >; >> >> tps: tps at 2d { >> reg = <0x2d>; >> }; > >> In the above example, the sequence "0x25 0x1f" is written to the I2C >> device at address 0x2d (the TPS65910 PMIC). The PMIC interprets that >> as a write to a register at address 0x25. > >> I'd really like to get some feedback on the devicetree bindings. > > Shouldn't the TPS driver know how to generate this sequence? It seems > fragile to do voltage adjustments behind the back of the regulator > framework and the TPS driver. The wake-sequence values should match the > (in-memory) regulator configuration on resume (which may have been > changed by DVFS). The sequence is both PMIC specific and board specific. Additionally, the PMICs used aren't am335x specific. It would be nice to have the regulator framework and the driver write all this out, but the sequence is written out by the Cortex-M3 processor running some PM firmware. Even if the code was changed to run on the A8, it'd have to run from a small piece of SRAM. As far as DVFS, I'm not aware of any DVFS implementations that muck with VDD CORE. > The CM3 driver needs to figure out where the core regulator is connected > using using either DT or the regulator framework and ask the TPS (via a > new interface) for register writes for sleep/wake sequences. Then those > sequences will actually match the correct voltages configured using > DT/DVFS. That seems like it'd add a lot of complexity to the regulator subsystem, as well as all the PMIC and other I2C regulators that any users of these device tree properties may end up using for not a lot of gain. There would be two separate code paths for any used I2C regulator or PMIC for setting voltages. > Regards, > Jan > -- > Pengutronix e.K. | | > Industrial Linux Solutions | http://www.pengutronix.de/ | > Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 | > Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 | > > > _______________________________________________ > linux-arm-kernel mailing list > linux-arm-kernel at lists.infradead.org > http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 84+ messages in thread
* Re: [PATCH v4 0/4] ARM: OMAP2+: AM33XX: VDD CORE OPP50 support 2013-08-14 22:21 ` Russ Dill @ 2013-08-15 8:00 ` Jan Lübbe -1 siblings, 0 replies; 84+ messages in thread From: Jan Lübbe @ 2013-08-15 8:00 UTC (permalink / raw) To: Russ Dill Cc: Kevin Hilman, devicetree, devicetree-discuss, linux-omap, linux-arm-kernel On Wed, 2013-08-14 at 15:21 -0700, Russ Dill wrote: > > The CM3 driver needs to figure out where the core regulator is connected > > using using either DT or the regulator framework and ask the TPS (via a > > new interface) for register writes for sleep/wake sequences. Then those > > sequences will actually match the correct voltages configured using > > DT/DVFS. > > That seems like it'd add a lot of complexity to the regulator > subsystem, as well as all the PMIC and other I2C regulators that any > users of these device tree properties may end up using for not a lot > of gain. There would be two separate code paths for any used > I2C regulator or PMIC for setting voltages. Yes, it would be additional complexity, but it would avoid duplicating information which is already in the DT (location&address of the PMIC, type of pmic) and in the kernel (how to program voltages for a given regulator). As DT is supposed to describe the hardware, duplicate information should be unnecessary. One different way to look at this is that the CM3 firmware is a separate consumer of the DT. DT being OS-indepentent, the CM3 firmware should be able to get all the information it needs from the DT (maybe with help from the CM3 driver). Regards, Jan -- Pengutronix e.K. | | Industrial Linux Solutions | http://www.pengutronix.de/ | Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 | Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 | ^ permalink raw reply [flat|nested] 84+ messages in thread
* [PATCH v4 0/4] ARM: OMAP2+: AM33XX: VDD CORE OPP50 support @ 2013-08-15 8:00 ` Jan Lübbe 0 siblings, 0 replies; 84+ messages in thread From: Jan Lübbe @ 2013-08-15 8:00 UTC (permalink / raw) To: linux-arm-kernel On Wed, 2013-08-14 at 15:21 -0700, Russ Dill wrote: > > The CM3 driver needs to figure out where the core regulator is connected > > using using either DT or the regulator framework and ask the TPS (via a > > new interface) for register writes for sleep/wake sequences. Then those > > sequences will actually match the correct voltages configured using > > DT/DVFS. > > That seems like it'd add a lot of complexity to the regulator > subsystem, as well as all the PMIC and other I2C regulators that any > users of these device tree properties may end up using for not a lot > of gain. There would be two separate code paths for any used > I2C regulator or PMIC for setting voltages. Yes, it would be additional complexity, but it would avoid duplicating information which is already in the DT (location&address of the PMIC, type of pmic) and in the kernel (how to program voltages for a given regulator). As DT is supposed to describe the hardware, duplicate information should be unnecessary. One different way to look at this is that the CM3 firmware is a separate consumer of the DT. DT being OS-indepentent, the CM3 firmware should be able to get all the information it needs from the DT (maybe with help from the CM3 driver). Regards, Jan -- Pengutronix e.K. | | Industrial Linux Solutions | http://www.pengutronix.de/ | Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 | Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 | ^ permalink raw reply [flat|nested] 84+ messages in thread
* Re: [PATCH v4 0/4] ARM: OMAP2+: AM33XX: VDD CORE OPP50 support 2013-08-14 22:21 ` Russ Dill @ 2013-08-27 22:44 ` Kevin Hilman -1 siblings, 0 replies; 84+ messages in thread From: Kevin Hilman @ 2013-08-27 22:44 UTC (permalink / raw) To: Russ Dill Cc: Jan Lübbe, devicetree, devicetree-discuss, linux-omap, linux-arm-kernel, Mark Brown [+Mark Brown for regulator suspend sequence ideas] Russ Dill <Russ.Dill@ti.com> writes: > On Wed, Aug 14, 2013 at 6:38 AM, Jan Lübbe <jlu@pengutronix.de> wrote: >> On Tue, 2013-08-13 at 15:20 -0700, Russ Dill wrote: >>> The purpose and method of executing these sequences is left up to each >>> platform. In the case of the am33xx, the CM3 firmware writes out the >>> simple I2C sequences. >>> >>> Each sequence is a series of I2C write commands. The first byte is the >>> length of the write, the second byte the I2C device to address, and >>> the following bytes are the message. >> >>> /* Set OPP100 (1.10V) for VDD core */ >>> wake_sequence = /bits/ 8 < >>> 0x02 0x2d 0x25 0x2b /* Set VDD2 to 1.1V */ >>> >; >>> >>> tps: tps@2d { >>> reg = <0x2d>; >>> }; >> >>> In the above example, the sequence "0x25 0x1f" is written to the I2C >>> device at address 0x2d (the TPS65910 PMIC). The PMIC interprets that >>> as a write to a register at address 0x25. >> >>> I'd really like to get some feedback on the devicetree bindings. Well the first comment (also made by others) is that the DT should be describing the hardware, and by that rule, the wake/sleep sequences are not properties of the i2c node but rather properties of the pmic. You've pointed out the inconveniences caused by that, but I'm not sure that those are enough to break the basic DT rules there. I'll leave it to the DT reviewers to make that decision. >> Shouldn't the TPS driver know how to generate this sequence? It seems >> fragile to do voltage adjustments behind the back of the regulator >> framework and the TPS driver. The wake-sequence values should match the >> (in-memory) regulator configuration on resume (which may have been >> changed by DVFS). > > The sequence is both PMIC specific and board specific. Additionally, > the PMICs used aren't am335x specific. It would be nice to have the > regulator framework and the driver write all this out, but the > sequence is written out by the Cortex-M3 processor running some PM > firmware. Even if the code was changed to run on the A8, it'd have to > run from a small piece of SRAM. So, why/how was the decision made to use the M3 instead of the MPU running from SRAM? As a firmware minimalist, I obviously prefer to do this from the MPU side. But also, because the M3 is reset every suspend sequence, this becomes rather heavy to do from the M3. Currently voltage scaling is only being proposed for suspend in this series, but in theory it's possible from idle as well. Doing this from the MPU/SRAM seems much better suited for idle. > As far as DVFS, I'm not aware of any DVFS implementations that muck > with VDD CORE. > >> The CM3 driver needs to figure out where the core regulator is connected >> using using either DT or the regulator framework and ask the TPS (via a >> new interface) for register writes for sleep/wake sequences. Then those >> sequences will actually match the correct voltages configured using >> DT/DVFS. > > That seems like it'd add a lot of complexity to the regulator > subsystem, as well as all the PMIC and other I2C regulators that any > users of these device tree properties may end up using for not a lot > of gain. There would be two separate code paths for any used > I2C regulator or PMIC for setting voltages. Added Mark for his thoughts on this, but seems like complexity that the regulator framework might need to grow anyways. The framework already has a concept of suspend voltage, suspend mode etc. Maybe it needs some generalizing so low-level platform code could query the framework for the sequence so it can be done late in platform idle/suspend paths. Especially for regmap drivers, this seems feasible. Kevin -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 84+ messages in thread
* [PATCH v4 0/4] ARM: OMAP2+: AM33XX: VDD CORE OPP50 support @ 2013-08-27 22:44 ` Kevin Hilman 0 siblings, 0 replies; 84+ messages in thread From: Kevin Hilman @ 2013-08-27 22:44 UTC (permalink / raw) To: linux-arm-kernel [+Mark Brown for regulator suspend sequence ideas] Russ Dill <Russ.Dill@ti.com> writes: > On Wed, Aug 14, 2013 at 6:38 AM, Jan L?bbe <jlu@pengutronix.de> wrote: >> On Tue, 2013-08-13 at 15:20 -0700, Russ Dill wrote: >>> The purpose and method of executing these sequences is left up to each >>> platform. In the case of the am33xx, the CM3 firmware writes out the >>> simple I2C sequences. >>> >>> Each sequence is a series of I2C write commands. The first byte is the >>> length of the write, the second byte the I2C device to address, and >>> the following bytes are the message. >> >>> /* Set OPP100 (1.10V) for VDD core */ >>> wake_sequence = /bits/ 8 < >>> 0x02 0x2d 0x25 0x2b /* Set VDD2 to 1.1V */ >>> >; >>> >>> tps: tps at 2d { >>> reg = <0x2d>; >>> }; >> >>> In the above example, the sequence "0x25 0x1f" is written to the I2C >>> device at address 0x2d (the TPS65910 PMIC). The PMIC interprets that >>> as a write to a register at address 0x25. >> >>> I'd really like to get some feedback on the devicetree bindings. Well the first comment (also made by others) is that the DT should be describing the hardware, and by that rule, the wake/sleep sequences are not properties of the i2c node but rather properties of the pmic. You've pointed out the inconveniences caused by that, but I'm not sure that those are enough to break the basic DT rules there. I'll leave it to the DT reviewers to make that decision. >> Shouldn't the TPS driver know how to generate this sequence? It seems >> fragile to do voltage adjustments behind the back of the regulator >> framework and the TPS driver. The wake-sequence values should match the >> (in-memory) regulator configuration on resume (which may have been >> changed by DVFS). > > The sequence is both PMIC specific and board specific. Additionally, > the PMICs used aren't am335x specific. It would be nice to have the > regulator framework and the driver write all this out, but the > sequence is written out by the Cortex-M3 processor running some PM > firmware. Even if the code was changed to run on the A8, it'd have to > run from a small piece of SRAM. So, why/how was the decision made to use the M3 instead of the MPU running from SRAM? As a firmware minimalist, I obviously prefer to do this from the MPU side. But also, because the M3 is reset every suspend sequence, this becomes rather heavy to do from the M3. Currently voltage scaling is only being proposed for suspend in this series, but in theory it's possible from idle as well. Doing this from the MPU/SRAM seems much better suited for idle. > As far as DVFS, I'm not aware of any DVFS implementations that muck > with VDD CORE. > >> The CM3 driver needs to figure out where the core regulator is connected >> using using either DT or the regulator framework and ask the TPS (via a >> new interface) for register writes for sleep/wake sequences. Then those >> sequences will actually match the correct voltages configured using >> DT/DVFS. > > That seems like it'd add a lot of complexity to the regulator > subsystem, as well as all the PMIC and other I2C regulators that any > users of these device tree properties may end up using for not a lot > of gain. There would be two separate code paths for any used > I2C regulator or PMIC for setting voltages. Added Mark for his thoughts on this, but seems like complexity that the regulator framework might need to grow anyways. The framework already has a concept of suspend voltage, suspend mode etc. Maybe it needs some generalizing so low-level platform code could query the framework for the sequence so it can be done late in platform idle/suspend paths. Especially for regmap drivers, this seems feasible. Kevin ^ permalink raw reply [flat|nested] 84+ messages in thread
* Re: [PATCH v4 0/4] ARM: OMAP2+: AM33XX: VDD CORE OPP50 support 2013-08-27 22:44 ` Kevin Hilman @ 2013-08-28 1:05 ` Russ Dill -1 siblings, 0 replies; 84+ messages in thread From: Russ Dill @ 2013-08-28 1:05 UTC (permalink / raw) To: Kevin Hilman Cc: Jan Lübbe, devicetree, linux-omap, Linux ARM Kernel List, Mark Brown On Tue, Aug 27, 2013 at 3:44 PM, Kevin Hilman <khilman@linaro.org> wrote: > [+Mark Brown for regulator suspend sequence ideas] > > Russ Dill <Russ.Dill@ti.com> writes: > >> On Wed, Aug 14, 2013 at 6:38 AM, Jan Lübbe <jlu@pengutronix.de> wrote: >>> On Tue, 2013-08-13 at 15:20 -0700, Russ Dill wrote: [snip] >>> Shouldn't the TPS driver know how to generate this sequence? It seems >>> fragile to do voltage adjustments behind the back of the regulator >>> framework and the TPS driver. The wake-sequence values should match the >>> (in-memory) regulator configuration on resume (which may have been >>> changed by DVFS). >> >> The sequence is both PMIC specific and board specific. Additionally, >> the PMICs used aren't am335x specific. It would be nice to have the >> regulator framework and the driver write all this out, but the >> sequence is written out by the Cortex-M3 processor running some PM >> firmware. Even if the code was changed to run on the A8, it'd have to >> run from a small piece of SRAM. > > So, why/how was the decision made to use the M3 instead of the MPU > running from SRAM? > > As a firmware minimalist, I obviously prefer to do this from the MPU > side. But also, because the M3 is reset every suspend sequence, this > becomes rather heavy to do from the M3. After the feedback Vaibhav Bedia received on v2 of his suspend/resume patchset for am335x, he decided to move many of the operations from sleep33xx.S into the M3 firmware. See the commit message here: http://arago-project.org/git/projects/?p=am33x-cm3.git;a=commit;h=a972ce2f6 I need to wait until after the PLLs are put into bypass, which is now done in the M3 firmware. It also ends up being a lot easier to write the I2C writer code there in C rather than in assembly in sleep33xx.S. > Currently voltage scaling is only being proposed for suspend in this > series, but in theory it's possible from idle as well. Doing this from > the MPU/SRAM seems much better suited for idle. The M3 firmware will also handle any cpuidle modes deeper than just putting SDRAM into self refresh. This is actually the only way of doing things like turning the MPU domain off on am335x. >> As far as DVFS, I'm not aware of any DVFS implementations that muck >> with VDD CORE. >> >>> The CM3 driver needs to figure out where the core regulator is connected >>> using using either DT or the regulator framework and ask the TPS (via a >>> new interface) for register writes for sleep/wake sequences. Then those >>> sequences will actually match the correct voltages configured using >>> DT/DVFS. >> >> That seems like it'd add a lot of complexity to the regulator >> subsystem, as well as all the PMIC and other I2C regulators that any >> users of these device tree properties may end up using for not a lot >> of gain. There would be two separate code paths for any used >> I2C regulator or PMIC for setting voltages. > > Added Mark for his thoughts on this, but seems like complexity that the > regulator framework might need to grow anyways. > > The framework already has a concept of suspend voltage, suspend mode > etc. Maybe it needs some generalizing so low-level platform code could > query the framework for the sequence so it can be done late in platform > idle/suspend paths. Especially for regmap drivers, this seems feasible. Yes, my main hesitation for going down this path is possible lack of support for such an interface upstream. > Kevin > -- > To unsubscribe from this list: send the line "unsubscribe linux-omap" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 84+ messages in thread
* [PATCH v4 0/4] ARM: OMAP2+: AM33XX: VDD CORE OPP50 support @ 2013-08-28 1:05 ` Russ Dill 0 siblings, 0 replies; 84+ messages in thread From: Russ Dill @ 2013-08-28 1:05 UTC (permalink / raw) To: linux-arm-kernel On Tue, Aug 27, 2013 at 3:44 PM, Kevin Hilman <khilman@linaro.org> wrote: > [+Mark Brown for regulator suspend sequence ideas] > > Russ Dill <Russ.Dill@ti.com> writes: > >> On Wed, Aug 14, 2013 at 6:38 AM, Jan L?bbe <jlu@pengutronix.de> wrote: >>> On Tue, 2013-08-13 at 15:20 -0700, Russ Dill wrote: [snip] >>> Shouldn't the TPS driver know how to generate this sequence? It seems >>> fragile to do voltage adjustments behind the back of the regulator >>> framework and the TPS driver. The wake-sequence values should match the >>> (in-memory) regulator configuration on resume (which may have been >>> changed by DVFS). >> >> The sequence is both PMIC specific and board specific. Additionally, >> the PMICs used aren't am335x specific. It would be nice to have the >> regulator framework and the driver write all this out, but the >> sequence is written out by the Cortex-M3 processor running some PM >> firmware. Even if the code was changed to run on the A8, it'd have to >> run from a small piece of SRAM. > > So, why/how was the decision made to use the M3 instead of the MPU > running from SRAM? > > As a firmware minimalist, I obviously prefer to do this from the MPU > side. But also, because the M3 is reset every suspend sequence, this > becomes rather heavy to do from the M3. After the feedback Vaibhav Bedia received on v2 of his suspend/resume patchset for am335x, he decided to move many of the operations from sleep33xx.S into the M3 firmware. See the commit message here: http://arago-project.org/git/projects/?p=am33x-cm3.git;a=commit;h=a972ce2f6 I need to wait until after the PLLs are put into bypass, which is now done in the M3 firmware. It also ends up being a lot easier to write the I2C writer code there in C rather than in assembly in sleep33xx.S. > Currently voltage scaling is only being proposed for suspend in this > series, but in theory it's possible from idle as well. Doing this from > the MPU/SRAM seems much better suited for idle. The M3 firmware will also handle any cpuidle modes deeper than just putting SDRAM into self refresh. This is actually the only way of doing things like turning the MPU domain off on am335x. >> As far as DVFS, I'm not aware of any DVFS implementations that muck >> with VDD CORE. >> >>> The CM3 driver needs to figure out where the core regulator is connected >>> using using either DT or the regulator framework and ask the TPS (via a >>> new interface) for register writes for sleep/wake sequences. Then those >>> sequences will actually match the correct voltages configured using >>> DT/DVFS. >> >> That seems like it'd add a lot of complexity to the regulator >> subsystem, as well as all the PMIC and other I2C regulators that any >> users of these device tree properties may end up using for not a lot >> of gain. There would be two separate code paths for any used >> I2C regulator or PMIC for setting voltages. > > Added Mark for his thoughts on this, but seems like complexity that the > regulator framework might need to grow anyways. > > The framework already has a concept of suspend voltage, suspend mode > etc. Maybe it needs some generalizing so low-level platform code could > query the framework for the sequence so it can be done late in platform > idle/suspend paths. Especially for regmap drivers, this seems feasible. Yes, my main hesitation for going down this path is possible lack of support for such an interface upstream. > Kevin > -- > To unsubscribe from this list: send the line "unsubscribe linux-omap" in > the body of a message to majordomo at vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 84+ messages in thread
* Re: [PATCH v4 0/4] ARM: OMAP2+: AM33XX: VDD CORE OPP50 support 2013-08-28 1:05 ` Russ Dill @ 2013-08-29 11:05 ` Mark Brown -1 siblings, 0 replies; 84+ messages in thread From: Mark Brown @ 2013-08-29 11:05 UTC (permalink / raw) To: Russ Dill Cc: Kevin Hilman, Jan Lübbe, devicetree, linux-omap, Linux ARM Kernel List [-- Attachment #1: Type: text/plain, Size: 1093 bytes --] On Tue, Aug 27, 2013 at 06:05:34PM -0700, Russ Dill wrote: > On Tue, Aug 27, 2013 at 3:44 PM, Kevin Hilman <khilman@linaro.org> wrote: > > The framework already has a concept of suspend voltage, suspend mode > > etc. Maybe it needs some generalizing so low-level platform code could > > query the framework for the sequence so it can be done late in platform > > idle/suspend paths. Especially for regmap drivers, this seems feasible. > Yes, my main hesitation for going down this path is possible lack of > support for such an interface upstream. Someone is going to have to walk me through the context for me to fully understand what this is all about - what's the problem? Generally for suspend if the sequencing is being done by the processor it's been handled by the drivers for the components in question. For sequencing beyond that you're into hardware features which aren't all that regular sadly and often aren't controllable either. It sounds like this is the latter case but the thing that manages some of the late power down stages does so using a firmware we can rewrite? [-- Attachment #2: Digital signature --] [-- Type: application/pgp-signature, Size: 836 bytes --] ^ permalink raw reply [flat|nested] 84+ messages in thread
* [PATCH v4 0/4] ARM: OMAP2+: AM33XX: VDD CORE OPP50 support @ 2013-08-29 11:05 ` Mark Brown 0 siblings, 0 replies; 84+ messages in thread From: Mark Brown @ 2013-08-29 11:05 UTC (permalink / raw) To: linux-arm-kernel On Tue, Aug 27, 2013 at 06:05:34PM -0700, Russ Dill wrote: > On Tue, Aug 27, 2013 at 3:44 PM, Kevin Hilman <khilman@linaro.org> wrote: > > The framework already has a concept of suspend voltage, suspend mode > > etc. Maybe it needs some generalizing so low-level platform code could > > query the framework for the sequence so it can be done late in platform > > idle/suspend paths. Especially for regmap drivers, this seems feasible. > Yes, my main hesitation for going down this path is possible lack of > support for such an interface upstream. Someone is going to have to walk me through the context for me to fully understand what this is all about - what's the problem? Generally for suspend if the sequencing is being done by the processor it's been handled by the drivers for the components in question. For sequencing beyond that you're into hardware features which aren't all that regular sadly and often aren't controllable either. It sounds like this is the latter case but the thing that manages some of the late power down stages does so using a firmware we can rewrite? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: Digital signature URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20130829/03182f12/attachment.sig> ^ permalink raw reply [flat|nested] 84+ messages in thread
* Re: [PATCH v4 0/4] ARM: OMAP2+: AM33XX: VDD CORE OPP50 support 2013-08-29 11:05 ` Mark Brown @ 2013-08-29 15:29 ` Kevin Hilman -1 siblings, 0 replies; 84+ messages in thread From: Kevin Hilman @ 2013-08-29 15:29 UTC (permalink / raw) To: Mark Brown Cc: Russ Dill, Jan Lübbe, devicetree, linux-omap, Linux ARM Kernel List On Thu, Aug 29, 2013 at 4:05 AM, Mark Brown <broonie@kernel.org> wrote: > On Tue, Aug 27, 2013 at 06:05:34PM -0700, Russ Dill wrote: >> On Tue, Aug 27, 2013 at 3:44 PM, Kevin Hilman <khilman@linaro.org> wrote: > >> > The framework already has a concept of suspend voltage, suspend mode >> > etc. Maybe it needs some generalizing so low-level platform code could >> > query the framework for the sequence so it can be done late in platform >> > idle/suspend paths. Especially for regmap drivers, this seems feasible. > >> Yes, my main hesitation for going down this path is possible lack of >> support for such an interface upstream. > > Someone is going to have to walk me through the context for me to fully > understand what this is all about - what's the problem? The basic problem is how to have low-level platform code (or possibly firmware) send commands to a regulator to scale voltage. This has to happen *very* late in the suspend process, so having the drivers do it themselves is not feasible. The proposal in this series is to define the i2c commands sequence to be sent to the regulator in the i2c node of the DT. The platform-specific code then reads the sequence from the DT and sends the commands (or in in the case of the current series, passes the sequence to some firmware on a microcontroller which does the sequence.) > Generally for suspend if the sequencing is being done by the processor > it's been handled by the drivers for the components in question. For > sequencing beyond that you're into hardware features which aren't all > that regular sadly and often aren't controllable either. It sounds like > this is the latter case but the thing that manages some of the late > power down stages does so using a firmware we can rewrite? For the TI AM335x, the source for M3 firmware is available and configurable[1]. However, I'd still rather see this done by the low-level platform code in linux, not offloaded to the firmware, but the linux vs. firmware decision orthogonal to how to define/probe the sequences that need to be sent to the regulator. Kevin [1] git://arago-project.org/git/projects/am33x-cm3.git ^ permalink raw reply [flat|nested] 84+ messages in thread
* [PATCH v4 0/4] ARM: OMAP2+: AM33XX: VDD CORE OPP50 support @ 2013-08-29 15:29 ` Kevin Hilman 0 siblings, 0 replies; 84+ messages in thread From: Kevin Hilman @ 2013-08-29 15:29 UTC (permalink / raw) To: linux-arm-kernel On Thu, Aug 29, 2013 at 4:05 AM, Mark Brown <broonie@kernel.org> wrote: > On Tue, Aug 27, 2013 at 06:05:34PM -0700, Russ Dill wrote: >> On Tue, Aug 27, 2013 at 3:44 PM, Kevin Hilman <khilman@linaro.org> wrote: > >> > The framework already has a concept of suspend voltage, suspend mode >> > etc. Maybe it needs some generalizing so low-level platform code could >> > query the framework for the sequence so it can be done late in platform >> > idle/suspend paths. Especially for regmap drivers, this seems feasible. > >> Yes, my main hesitation for going down this path is possible lack of >> support for such an interface upstream. > > Someone is going to have to walk me through the context for me to fully > understand what this is all about - what's the problem? The basic problem is how to have low-level platform code (or possibly firmware) send commands to a regulator to scale voltage. This has to happen *very* late in the suspend process, so having the drivers do it themselves is not feasible. The proposal in this series is to define the i2c commands sequence to be sent to the regulator in the i2c node of the DT. The platform-specific code then reads the sequence from the DT and sends the commands (or in in the case of the current series, passes the sequence to some firmware on a microcontroller which does the sequence.) > Generally for suspend if the sequencing is being done by the processor > it's been handled by the drivers for the components in question. For > sequencing beyond that you're into hardware features which aren't all > that regular sadly and often aren't controllable either. It sounds like > this is the latter case but the thing that manages some of the late > power down stages does so using a firmware we can rewrite? For the TI AM335x, the source for M3 firmware is available and configurable[1]. However, I'd still rather see this done by the low-level platform code in linux, not offloaded to the firmware, but the linux vs. firmware decision orthogonal to how to define/probe the sequences that need to be sent to the regulator. Kevin [1] git://arago-project.org/git/projects/am33x-cm3.git ^ permalink raw reply [flat|nested] 84+ messages in thread
* Re: [PATCH v4 0/4] ARM: OMAP2+: AM33XX: VDD CORE OPP50 support 2013-08-29 15:29 ` Kevin Hilman @ 2013-08-29 15:49 ` Mark Brown -1 siblings, 0 replies; 84+ messages in thread From: Mark Brown @ 2013-08-29 15:49 UTC (permalink / raw) To: Kevin Hilman Cc: Russ Dill, Jan Lübbe, devicetree, linux-omap, Linux ARM Kernel List [-- Attachment #1: Type: text/plain, Size: 1352 bytes --] On Thu, Aug 29, 2013 at 08:29:37AM -0700, Kevin Hilman wrote: > On Thu, Aug 29, 2013 at 4:05 AM, Mark Brown <broonie@kernel.org> wrote: > > Someone is going to have to walk me through the context for me to fully > > understand what this is all about - what's the problem? > The basic problem is how to have low-level platform code (or possibly > firmware) send commands to a regulator to scale voltage. This has to > happen *very* late in the suspend process, so having the drivers do it > themselves is not feasible. Why does it have to happen this late and are the sequences definitely fixed ones not ones that could depend on the system state at the time we suspend? It'd help to know what exactly is being controlled here... > The proposal in this series is to define the i2c commands sequence to > be sent to the regulator in the i2c node of the DT. The > platform-specific code then reads the sequence from the DT and sends > the commands (or in in the case of the current series, passes the > sequence to some firmware on a microcontroller which does the > sequence.) Surely specifying things in terms of the actual sequence would be better than trying to specify the I2C commands if you want this to be done from Linux? If the firmware has to cope directly then this would require the firmware to understand what it's doing of course. [-- Attachment #2: Digital signature --] [-- Type: application/pgp-signature, Size: 836 bytes --] ^ permalink raw reply [flat|nested] 84+ messages in thread
* [PATCH v4 0/4] ARM: OMAP2+: AM33XX: VDD CORE OPP50 support @ 2013-08-29 15:49 ` Mark Brown 0 siblings, 0 replies; 84+ messages in thread From: Mark Brown @ 2013-08-29 15:49 UTC (permalink / raw) To: linux-arm-kernel On Thu, Aug 29, 2013 at 08:29:37AM -0700, Kevin Hilman wrote: > On Thu, Aug 29, 2013 at 4:05 AM, Mark Brown <broonie@kernel.org> wrote: > > Someone is going to have to walk me through the context for me to fully > > understand what this is all about - what's the problem? > The basic problem is how to have low-level platform code (or possibly > firmware) send commands to a regulator to scale voltage. This has to > happen *very* late in the suspend process, so having the drivers do it > themselves is not feasible. Why does it have to happen this late and are the sequences definitely fixed ones not ones that could depend on the system state at the time we suspend? It'd help to know what exactly is being controlled here... > The proposal in this series is to define the i2c commands sequence to > be sent to the regulator in the i2c node of the DT. The > platform-specific code then reads the sequence from the DT and sends > the commands (or in in the case of the current series, passes the > sequence to some firmware on a microcontroller which does the > sequence.) Surely specifying things in terms of the actual sequence would be better than trying to specify the I2C commands if you want this to be done from Linux? If the firmware has to cope directly then this would require the firmware to understand what it's doing of course. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: Digital signature URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20130829/36460f8a/attachment.sig> ^ permalink raw reply [flat|nested] 84+ messages in thread
* Re: [PATCH v4 0/4] ARM: OMAP2+: AM33XX: VDD CORE OPP50 support 2013-08-29 15:49 ` Mark Brown @ 2013-08-29 16:31 ` Russ Dill -1 siblings, 0 replies; 84+ messages in thread From: Russ Dill @ 2013-08-29 16:31 UTC (permalink / raw) To: Mark Brown Cc: Kevin Hilman, devicetree, linux-omap, Jan Lübbe, Linux ARM Kernel List On Thu, Aug 29, 2013 at 8:49 AM, Mark Brown <broonie@kernel.org> wrote: > On Thu, Aug 29, 2013 at 08:29:37AM -0700, Kevin Hilman wrote: >> On Thu, Aug 29, 2013 at 4:05 AM, Mark Brown <broonie@kernel.org> wrote: > >> > Someone is going to have to walk me through the context for me to fully >> > understand what this is all about - what's the problem? > >> The basic problem is how to have low-level platform code (or possibly >> firmware) send commands to a regulator to scale voltage. This has to >> happen *very* late in the suspend process, so having the drivers do it >> themselves is not feasible. > > Why does it have to happen this late and are the sequences definitely > fixed ones not ones that could depend on the system state at the time > we suspend? It'd help to know what exactly is being controlled here... On all am335x platforms, the lower operating point for core voltage cannot be reached without first disabling the DDR controller, and programming it into a lower power mode. For DDR3 platforms, no such lower power mode is available and the lower operating point for core voltage can only be reached with the memory controller disabled. It certainly is possible that some bizarre I2C regulator may mix in regulator voltage and some other state into one I2C register. In the case of such a platform, setting the lower operating point would not be supported. >> The proposal in this series is to define the i2c commands sequence to >> be sent to the regulator in the i2c node of the DT. The >> platform-specific code then reads the sequence from the DT and sends >> the commands (or in in the case of the current series, passes the >> sequence to some firmware on a microcontroller which does the >> sequence.) > > Surely specifying things in terms of the actual sequence would be better > than trying to specify the I2C commands if you want this to be done from > Linux? If the firmware has to cope directly then this would require the > firmware to understand what it's doing of course. I'm not sure what you mean by "actual sequence". Maybe if I show you a couple examples, it will be more clear: This is for the AM335X-EVM which has a TPS65910. The first byte is the number of bytes to write, the second byte is the I2C device to write those bytes to, the third byte happens to be a register address on the TPS65910, and the 4th byte happens to be the value for 0.95V and 1.1V respectively. /* Set OPP50 (0.95V) for VDD core on TPS65910 */ sleep_sequence = /bits/ 8 < 0x02 0x2d 0x25 0x1f /* Set VDD2 to 0.95V */ >; /* Set OPP100 (1.10V) for VDD core on TPS65910 */ wake_sequence = /bits/ 8 < 0x02 0x2d 0x25 0x2b /* Set VDD2 to 1.1V */ >; These next sequences are for the Beaglebone which has a different PMIC. The format is the same, but the PMIC requires an unlock sequence to be performed for certain registers and it also requires an additional step to apply DCDC changes: /* Set OPP50 (0.95V) for VDD core on TPS65217 */ sleep_sequence = /bits/ 8 < 0x02 0x24 0x0b 0x6d /* Password unlock 1 */ 0x02 0x24 0x10 0x02 /* Set DCDC3 to 0.95V */ 0x02 0x24 0x0b 0x6d /* Password unlock 2 */ 0x02 0x24 0x10 0x02 /* Set DCDC3 to 0.95V */ 0x02 0x24 0x0b 0x6c /* Password unlock 1 */ 0x02 0x24 0x11 0x86 /* Apply DCDC changes */ 0x02 0x24 0x0b 0x6c /* Password unlock 2 */ 0x02 0x24 0x11 0x86 /* Apply DCDC changes */ >; /* Set OPP100 (1.10V) for VDD core on TPS65217 */ wake_sequence = /bits/ 8 < 0x02 0x24 0x0b 0x6d /* Password unlock 1 */ 0x02 0x24 0x10 0x08 /* Set DCDC3 to 1.1V */ 0x02 0x24 0x0b 0x6d /* Password unlock 2 */ 0x02 0x24 0x10 0x08 /* Set DCDC3 to 1.1V */ 0x02 0x24 0x0b 0x6c /* Password unlock 1 */ 0x02 0x24 0x11 0x86 /* Apply DCDC changes */ 0x02 0x24 0x0b 0x6c /* Password unlock 2 */ 0x02 0x24 0x11 0x86 /* Apply DCDC changes */ >; ^ permalink raw reply [flat|nested] 84+ messages in thread
* [PATCH v4 0/4] ARM: OMAP2+: AM33XX: VDD CORE OPP50 support @ 2013-08-29 16:31 ` Russ Dill 0 siblings, 0 replies; 84+ messages in thread From: Russ Dill @ 2013-08-29 16:31 UTC (permalink / raw) To: linux-arm-kernel On Thu, Aug 29, 2013 at 8:49 AM, Mark Brown <broonie@kernel.org> wrote: > On Thu, Aug 29, 2013 at 08:29:37AM -0700, Kevin Hilman wrote: >> On Thu, Aug 29, 2013 at 4:05 AM, Mark Brown <broonie@kernel.org> wrote: > >> > Someone is going to have to walk me through the context for me to fully >> > understand what this is all about - what's the problem? > >> The basic problem is how to have low-level platform code (or possibly >> firmware) send commands to a regulator to scale voltage. This has to >> happen *very* late in the suspend process, so having the drivers do it >> themselves is not feasible. > > Why does it have to happen this late and are the sequences definitely > fixed ones not ones that could depend on the system state at the time > we suspend? It'd help to know what exactly is being controlled here... On all am335x platforms, the lower operating point for core voltage cannot be reached without first disabling the DDR controller, and programming it into a lower power mode. For DDR3 platforms, no such lower power mode is available and the lower operating point for core voltage can only be reached with the memory controller disabled. It certainly is possible that some bizarre I2C regulator may mix in regulator voltage and some other state into one I2C register. In the case of such a platform, setting the lower operating point would not be supported. >> The proposal in this series is to define the i2c commands sequence to >> be sent to the regulator in the i2c node of the DT. The >> platform-specific code then reads the sequence from the DT and sends >> the commands (or in in the case of the current series, passes the >> sequence to some firmware on a microcontroller which does the >> sequence.) > > Surely specifying things in terms of the actual sequence would be better > than trying to specify the I2C commands if you want this to be done from > Linux? If the firmware has to cope directly then this would require the > firmware to understand what it's doing of course. I'm not sure what you mean by "actual sequence". Maybe if I show you a couple examples, it will be more clear: This is for the AM335X-EVM which has a TPS65910. The first byte is the number of bytes to write, the second byte is the I2C device to write those bytes to, the third byte happens to be a register address on the TPS65910, and the 4th byte happens to be the value for 0.95V and 1.1V respectively. /* Set OPP50 (0.95V) for VDD core on TPS65910 */ sleep_sequence = /bits/ 8 < 0x02 0x2d 0x25 0x1f /* Set VDD2 to 0.95V */ >; /* Set OPP100 (1.10V) for VDD core on TPS65910 */ wake_sequence = /bits/ 8 < 0x02 0x2d 0x25 0x2b /* Set VDD2 to 1.1V */ >; These next sequences are for the Beaglebone which has a different PMIC. The format is the same, but the PMIC requires an unlock sequence to be performed for certain registers and it also requires an additional step to apply DCDC changes: /* Set OPP50 (0.95V) for VDD core on TPS65217 */ sleep_sequence = /bits/ 8 < 0x02 0x24 0x0b 0x6d /* Password unlock 1 */ 0x02 0x24 0x10 0x02 /* Set DCDC3 to 0.95V */ 0x02 0x24 0x0b 0x6d /* Password unlock 2 */ 0x02 0x24 0x10 0x02 /* Set DCDC3 to 0.95V */ 0x02 0x24 0x0b 0x6c /* Password unlock 1 */ 0x02 0x24 0x11 0x86 /* Apply DCDC changes */ 0x02 0x24 0x0b 0x6c /* Password unlock 2 */ 0x02 0x24 0x11 0x86 /* Apply DCDC changes */ >; /* Set OPP100 (1.10V) for VDD core on TPS65217 */ wake_sequence = /bits/ 8 < 0x02 0x24 0x0b 0x6d /* Password unlock 1 */ 0x02 0x24 0x10 0x08 /* Set DCDC3 to 1.1V */ 0x02 0x24 0x0b 0x6d /* Password unlock 2 */ 0x02 0x24 0x10 0x08 /* Set DCDC3 to 1.1V */ 0x02 0x24 0x0b 0x6c /* Password unlock 1 */ 0x02 0x24 0x11 0x86 /* Apply DCDC changes */ 0x02 0x24 0x0b 0x6c /* Password unlock 2 */ 0x02 0x24 0x11 0x86 /* Apply DCDC changes */ >; ^ permalink raw reply [flat|nested] 84+ messages in thread
* Re: [PATCH v4 0/4] ARM: OMAP2+: AM33XX: VDD CORE OPP50 support 2013-08-29 16:31 ` Russ Dill @ 2013-08-29 17:30 ` Mark Brown -1 siblings, 0 replies; 84+ messages in thread From: Mark Brown @ 2013-08-29 17:30 UTC (permalink / raw) To: Russ Dill Cc: Kevin Hilman, devicetree, linux-omap, Jan Lübbe, Linux ARM Kernel List [-- Attachment #1: Type: text/plain, Size: 1842 bytes --] On Thu, Aug 29, 2013 at 09:31:55AM -0700, Russ Dill wrote: > On Thu, Aug 29, 2013 at 8:49 AM, Mark Brown <broonie@kernel.org> wrote: > > Why does it have to happen this late and are the sequences definitely > > fixed ones not ones that could depend on the system state at the time > > we suspend? It'd help to know what exactly is being controlled here... > On all am335x platforms, the lower operating point for core voltage > cannot be reached without first disabling the DDR controller, and > programming it into a lower power mode. For DDR3 platforms, no such > lower power mode is available and the lower operating point for core > voltage can only be reached with the memory controller disabled. So this is done from cpuidle rather than system suspend. > It certainly is possible that some bizarre I2C regulator may mix in > regulator voltage and some other state into one I2C register. In the > case of such a platform, setting the lower operating point would not > be supported. This isn't particularly bizzare, there is no technical reason why a register in the PMIC has to be given over completely to setting the voltage and indeed there are PMICs in mainline right now which don't do that - if you've got 16 bit registers it's probably not going to take the entire 16 bits to encode the voltage range. > > Surely specifying things in terms of the actual sequence would be better > > than trying to specify the I2C commands if you want this to be done from > > Linux? If the firmware has to cope directly then this would require the > > firmware to understand what it's doing of course. > I'm not sure what you mean by "actual sequence". Maybe if I show you a > couple examples, it will be more clear: I mean describe the intended sequence of events in the system rather than the raw register commands to accomplish them. [-- Attachment #2: Digital signature --] [-- Type: application/pgp-signature, Size: 836 bytes --] ^ permalink raw reply [flat|nested] 84+ messages in thread
* [PATCH v4 0/4] ARM: OMAP2+: AM33XX: VDD CORE OPP50 support @ 2013-08-29 17:30 ` Mark Brown 0 siblings, 0 replies; 84+ messages in thread From: Mark Brown @ 2013-08-29 17:30 UTC (permalink / raw) To: linux-arm-kernel On Thu, Aug 29, 2013 at 09:31:55AM -0700, Russ Dill wrote: > On Thu, Aug 29, 2013 at 8:49 AM, Mark Brown <broonie@kernel.org> wrote: > > Why does it have to happen this late and are the sequences definitely > > fixed ones not ones that could depend on the system state at the time > > we suspend? It'd help to know what exactly is being controlled here... > On all am335x platforms, the lower operating point for core voltage > cannot be reached without first disabling the DDR controller, and > programming it into a lower power mode. For DDR3 platforms, no such > lower power mode is available and the lower operating point for core > voltage can only be reached with the memory controller disabled. So this is done from cpuidle rather than system suspend. > It certainly is possible that some bizarre I2C regulator may mix in > regulator voltage and some other state into one I2C register. In the > case of such a platform, setting the lower operating point would not > be supported. This isn't particularly bizzare, there is no technical reason why a register in the PMIC has to be given over completely to setting the voltage and indeed there are PMICs in mainline right now which don't do that - if you've got 16 bit registers it's probably not going to take the entire 16 bits to encode the voltage range. > > Surely specifying things in terms of the actual sequence would be better > > than trying to specify the I2C commands if you want this to be done from > > Linux? If the firmware has to cope directly then this would require the > > firmware to understand what it's doing of course. > I'm not sure what you mean by "actual sequence". Maybe if I show you a > couple examples, it will be more clear: I mean describe the intended sequence of events in the system rather than the raw register commands to accomplish them. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: Digital signature URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20130829/10787a1f/attachment.sig> ^ permalink raw reply [flat|nested] 84+ messages in thread
* Re: [PATCH v4 0/4] ARM: OMAP2+: AM33XX: VDD CORE OPP50 support 2013-08-29 17:30 ` Mark Brown @ 2013-08-29 17:47 ` Russ Dill -1 siblings, 0 replies; 84+ messages in thread From: Russ Dill @ 2013-08-29 17:47 UTC (permalink / raw) To: Mark Brown Cc: devicetree, linux-omap, Kevin Hilman, Jan Lübbe, Linux ARM Kernel List On Thu, Aug 29, 2013 at 10:30 AM, Mark Brown <broonie@kernel.org> wrote: > On Thu, Aug 29, 2013 at 09:31:55AM -0700, Russ Dill wrote: >> On Thu, Aug 29, 2013 at 8:49 AM, Mark Brown <broonie@kernel.org> wrote: > >> > Why does it have to happen this late and are the sequences definitely >> > fixed ones not ones that could depend on the system state at the time >> > we suspend? It'd help to know what exactly is being controlled here... > >> On all am335x platforms, the lower operating point for core voltage >> cannot be reached without first disabling the DDR controller, and >> programming it into a lower power mode. For DDR3 platforms, no such >> lower power mode is available and the lower operating point for core >> voltage can only be reached with the memory controller disabled. > > So this is done from cpuidle rather than system suspend. It is done for system suspend. It isn't possible to do this in a cpuidle use case as the memory controller would need to come out of idle automatically to service DMA requests. >> It certainly is possible that some bizarre I2C regulator may mix in >> regulator voltage and some other state into one I2C register. In the >> case of such a platform, setting the lower operating point would not >> be supported. > > This isn't particularly bizzare, there is no technical reason why a > register in the PMIC has to be given over completely to setting the > voltage and indeed there are PMICs in mainline right now which don't do > that - if you've got 16 bit registers it's probably not going to take > the entire 16 bits to encode the voltage range. > >> > Surely specifying things in terms of the actual sequence would be better >> > than trying to specify the I2C commands if you want this to be done from >> > Linux? If the firmware has to cope directly then this would require the >> > firmware to understand what it's doing of course. > >> I'm not sure what you mean by "actual sequence". Maybe if I show you a >> couple examples, it will be more clear: > > I mean describe the intended sequence of events in the system rather > than the raw register commands to accomplish them. I'm still not sure what you mean. > _______________________________________________ > linux-arm-kernel mailing list > linux-arm-kernel@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/linux-arm-kernel > ^ permalink raw reply [flat|nested] 84+ messages in thread
* [PATCH v4 0/4] ARM: OMAP2+: AM33XX: VDD CORE OPP50 support @ 2013-08-29 17:47 ` Russ Dill 0 siblings, 0 replies; 84+ messages in thread From: Russ Dill @ 2013-08-29 17:47 UTC (permalink / raw) To: linux-arm-kernel On Thu, Aug 29, 2013 at 10:30 AM, Mark Brown <broonie@kernel.org> wrote: > On Thu, Aug 29, 2013 at 09:31:55AM -0700, Russ Dill wrote: >> On Thu, Aug 29, 2013 at 8:49 AM, Mark Brown <broonie@kernel.org> wrote: > >> > Why does it have to happen this late and are the sequences definitely >> > fixed ones not ones that could depend on the system state at the time >> > we suspend? It'd help to know what exactly is being controlled here... > >> On all am335x platforms, the lower operating point for core voltage >> cannot be reached without first disabling the DDR controller, and >> programming it into a lower power mode. For DDR3 platforms, no such >> lower power mode is available and the lower operating point for core >> voltage can only be reached with the memory controller disabled. > > So this is done from cpuidle rather than system suspend. It is done for system suspend. It isn't possible to do this in a cpuidle use case as the memory controller would need to come out of idle automatically to service DMA requests. >> It certainly is possible that some bizarre I2C regulator may mix in >> regulator voltage and some other state into one I2C register. In the >> case of such a platform, setting the lower operating point would not >> be supported. > > This isn't particularly bizzare, there is no technical reason why a > register in the PMIC has to be given over completely to setting the > voltage and indeed there are PMICs in mainline right now which don't do > that - if you've got 16 bit registers it's probably not going to take > the entire 16 bits to encode the voltage range. > >> > Surely specifying things in terms of the actual sequence would be better >> > than trying to specify the I2C commands if you want this to be done from >> > Linux? If the firmware has to cope directly then this would require the >> > firmware to understand what it's doing of course. > >> I'm not sure what you mean by "actual sequence". Maybe if I show you a >> couple examples, it will be more clear: > > I mean describe the intended sequence of events in the system rather > than the raw register commands to accomplish them. I'm still not sure what you mean. > _______________________________________________ > linux-arm-kernel mailing list > linux-arm-kernel at lists.infradead.org > http://lists.infradead.org/mailman/listinfo/linux-arm-kernel > ^ permalink raw reply [flat|nested] 84+ messages in thread
* Re: [PATCH v4 0/4] ARM: OMAP2+: AM33XX: VDD CORE OPP50 support 2013-08-29 17:47 ` Russ Dill @ 2013-08-29 18:03 ` Mark Brown -1 siblings, 0 replies; 84+ messages in thread From: Mark Brown @ 2013-08-29 18:03 UTC (permalink / raw) To: Russ Dill Cc: devicetree, linux-omap, Kevin Hilman, Jan Lübbe, Linux ARM Kernel List [-- Attachment #1: Type: text/plain, Size: 831 bytes --] On Thu, Aug 29, 2013 at 10:47:04AM -0700, Russ Dill wrote: > On Thu, Aug 29, 2013 at 10:30 AM, Mark Brown <broonie@kernel.org> wrote: > > So this is done from cpuidle rather than system suspend. > It is done for system suspend. It isn't possible to do this in a > cpuidle use case as the memory controller would need to come out of > idle automatically to service DMA requests. OK, so it's all part of the core power down sequence for the SoC? I'm not sure that makes a big difference but it at least means that there are fewer runtime interactions to worry about. > > I mean describe the intended sequence of events in the system rather > > than the raw register commands to accomplish them. > I'm still not sure what you mean. Say "set voltage X" or even "regulator X supplies Y" not "send this bytestream to the device". [-- Attachment #2: Digital signature --] [-- Type: application/pgp-signature, Size: 836 bytes --] ^ permalink raw reply [flat|nested] 84+ messages in thread
* [PATCH v4 0/4] ARM: OMAP2+: AM33XX: VDD CORE OPP50 support @ 2013-08-29 18:03 ` Mark Brown 0 siblings, 0 replies; 84+ messages in thread From: Mark Brown @ 2013-08-29 18:03 UTC (permalink / raw) To: linux-arm-kernel On Thu, Aug 29, 2013 at 10:47:04AM -0700, Russ Dill wrote: > On Thu, Aug 29, 2013 at 10:30 AM, Mark Brown <broonie@kernel.org> wrote: > > So this is done from cpuidle rather than system suspend. > It is done for system suspend. It isn't possible to do this in a > cpuidle use case as the memory controller would need to come out of > idle automatically to service DMA requests. OK, so it's all part of the core power down sequence for the SoC? I'm not sure that makes a big difference but it at least means that there are fewer runtime interactions to worry about. > > I mean describe the intended sequence of events in the system rather > > than the raw register commands to accomplish them. > I'm still not sure what you mean. Say "set voltage X" or even "regulator X supplies Y" not "send this bytestream to the device". -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: Digital signature URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20130829/047e1eca/attachment.sig> ^ permalink raw reply [flat|nested] 84+ messages in thread
* Re: [PATCH v4 0/4] ARM: OMAP2+: AM33XX: VDD CORE OPP50 support 2013-08-29 18:03 ` Mark Brown @ 2013-08-29 18:28 ` Russ Dill -1 siblings, 0 replies; 84+ messages in thread From: Russ Dill @ 2013-08-29 18:28 UTC (permalink / raw) To: Mark Brown Cc: Linux ARM Kernel List, devicetree, linux-omap, Jan Lübbe, Kevin Hilman On Thu, Aug 29, 2013 at 11:03 AM, Mark Brown <broonie@kernel.org> wrote: > On Thu, Aug 29, 2013 at 10:47:04AM -0700, Russ Dill wrote: >> On Thu, Aug 29, 2013 at 10:30 AM, Mark Brown <broonie@kernel.org> wrote: > >> > So this is done from cpuidle rather than system suspend. > >> It is done for system suspend. It isn't possible to do this in a >> cpuidle use case as the memory controller would need to come out of >> idle automatically to service DMA requests. > > OK, so it's all part of the core power down sequence for the SoC? I'm > not sure that makes a big difference but it at least means that there > are fewer runtime interactions to worry about. Well, core suspend sequence for the SoC. >> > I mean describe the intended sequence of events in the system rather >> > than the raw register commands to accomplish them. > >> I'm still not sure what you mean. > > Say "set voltage X" or even "regulator X supplies Y" not "send this > bytestream to the device". That's already known at the SoC level, "set the vdd core regulator to 0.95V". What isn't known is how to do that for each board. > _______________________________________________ > linux-arm-kernel mailing list > linux-arm-kernel@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/linux-arm-kernel > ^ permalink raw reply [flat|nested] 84+ messages in thread
* [PATCH v4 0/4] ARM: OMAP2+: AM33XX: VDD CORE OPP50 support @ 2013-08-29 18:28 ` Russ Dill 0 siblings, 0 replies; 84+ messages in thread From: Russ Dill @ 2013-08-29 18:28 UTC (permalink / raw) To: linux-arm-kernel On Thu, Aug 29, 2013 at 11:03 AM, Mark Brown <broonie@kernel.org> wrote: > On Thu, Aug 29, 2013 at 10:47:04AM -0700, Russ Dill wrote: >> On Thu, Aug 29, 2013 at 10:30 AM, Mark Brown <broonie@kernel.org> wrote: > >> > So this is done from cpuidle rather than system suspend. > >> It is done for system suspend. It isn't possible to do this in a >> cpuidle use case as the memory controller would need to come out of >> idle automatically to service DMA requests. > > OK, so it's all part of the core power down sequence for the SoC? I'm > not sure that makes a big difference but it at least means that there > are fewer runtime interactions to worry about. Well, core suspend sequence for the SoC. >> > I mean describe the intended sequence of events in the system rather >> > than the raw register commands to accomplish them. > >> I'm still not sure what you mean. > > Say "set voltage X" or even "regulator X supplies Y" not "send this > bytestream to the device". That's already known at the SoC level, "set the vdd core regulator to 0.95V". What isn't known is how to do that for each board. > _______________________________________________ > linux-arm-kernel mailing list > linux-arm-kernel at lists.infradead.org > http://lists.infradead.org/mailman/listinfo/linux-arm-kernel > ^ permalink raw reply [flat|nested] 84+ messages in thread
* Re: [PATCH v4 0/4] ARM: OMAP2+: AM33XX: VDD CORE OPP50 support 2013-08-29 11:05 ` Mark Brown @ 2013-08-29 15:42 ` Russ Dill -1 siblings, 0 replies; 84+ messages in thread From: Russ Dill @ 2013-08-29 15:42 UTC (permalink / raw) To: Mark Brown Cc: devicetree, linux-omap, Kevin Hilman, Jan Lübbe, Linux ARM Kernel List On Thu, Aug 29, 2013 at 4:05 AM, Mark Brown <broonie@kernel.org> wrote: > On Tue, Aug 27, 2013 at 06:05:34PM -0700, Russ Dill wrote: >> On Tue, Aug 27, 2013 at 3:44 PM, Kevin Hilman <khilman@linaro.org> wrote: > >> > The framework already has a concept of suspend voltage, suspend mode >> > etc. Maybe it needs some generalizing so low-level platform code could >> > query the framework for the sequence so it can be done late in platform >> > idle/suspend paths. Especially for regmap drivers, this seems feasible. > >> Yes, my main hesitation for going down this path is possible lack of >> support for such an interface upstream. > > Someone is going to have to walk me through the context for me to fully > understand what this is all about - what's the problem? > > Generally for suspend if the sequencing is being done by the processor > it's been handled by the drivers for the components in question. For > sequencing beyond that you're into hardware features which aren't all > that regular sadly and often aren't controllable either. It sounds like > this is the latter case but the thing that manages some of the late > power down stages does so using a firmware we can rewrite? So the AM335X processor has a small M3 coprocessor attached to it. The M3 coprocessor is in charge of performing many of the sleep and resume transition steps. It has a 16k code space for firmware. The CM3 coprocessor has access to most of the same registers the primary AM335X processor has access to (PM registers, clock registers, I2C controller, etc). For the deepest sleep modes, the core power supply can have its voltage reduced, but only after several steps by the CM3 coprocessor have been performed. The core power supply voltage must be reduced by the CM3 coprocessor. The core regulator is controlled by I2C on all the AM335X platforms that I am aware of, but different platforms have different I2C regulators. The path I'm taking in this patchset is to just put the board specific I2C sequences necessary for the CM3 coprocessor to write out into the devicetree. I've made it as generic as I can so that other platforms with similar issues can reuse the bindings. Because of the limitations of the firmware size and the desire not to have some sort of byte code, this is a write only sequence. Kevin Hilman is suggesting some way to query the regulator framework for this sequence. There would be some call to the regulator framework that would return a series of I2C commands that would be necessary to program a regulator to a specific voltage. It would be called twice, once for the suspend voltage, once for the resume voltage. The regulator framework would then call into the driver that sets that voltage, and by some method query the driver for the necessary I2C sequence, either by some special new call, or some regmap magic. ^ permalink raw reply [flat|nested] 84+ messages in thread
* [PATCH v4 0/4] ARM: OMAP2+: AM33XX: VDD CORE OPP50 support @ 2013-08-29 15:42 ` Russ Dill 0 siblings, 0 replies; 84+ messages in thread From: Russ Dill @ 2013-08-29 15:42 UTC (permalink / raw) To: linux-arm-kernel On Thu, Aug 29, 2013 at 4:05 AM, Mark Brown <broonie@kernel.org> wrote: > On Tue, Aug 27, 2013 at 06:05:34PM -0700, Russ Dill wrote: >> On Tue, Aug 27, 2013 at 3:44 PM, Kevin Hilman <khilman@linaro.org> wrote: > >> > The framework already has a concept of suspend voltage, suspend mode >> > etc. Maybe it needs some generalizing so low-level platform code could >> > query the framework for the sequence so it can be done late in platform >> > idle/suspend paths. Especially for regmap drivers, this seems feasible. > >> Yes, my main hesitation for going down this path is possible lack of >> support for such an interface upstream. > > Someone is going to have to walk me through the context for me to fully > understand what this is all about - what's the problem? > > Generally for suspend if the sequencing is being done by the processor > it's been handled by the drivers for the components in question. For > sequencing beyond that you're into hardware features which aren't all > that regular sadly and often aren't controllable either. It sounds like > this is the latter case but the thing that manages some of the late > power down stages does so using a firmware we can rewrite? So the AM335X processor has a small M3 coprocessor attached to it. The M3 coprocessor is in charge of performing many of the sleep and resume transition steps. It has a 16k code space for firmware. The CM3 coprocessor has access to most of the same registers the primary AM335X processor has access to (PM registers, clock registers, I2C controller, etc). For the deepest sleep modes, the core power supply can have its voltage reduced, but only after several steps by the CM3 coprocessor have been performed. The core power supply voltage must be reduced by the CM3 coprocessor. The core regulator is controlled by I2C on all the AM335X platforms that I am aware of, but different platforms have different I2C regulators. The path I'm taking in this patchset is to just put the board specific I2C sequences necessary for the CM3 coprocessor to write out into the devicetree. I've made it as generic as I can so that other platforms with similar issues can reuse the bindings. Because of the limitations of the firmware size and the desire not to have some sort of byte code, this is a write only sequence. Kevin Hilman is suggesting some way to query the regulator framework for this sequence. There would be some call to the regulator framework that would return a series of I2C commands that would be necessary to program a regulator to a specific voltage. It would be called twice, once for the suspend voltage, once for the resume voltage. The regulator framework would then call into the driver that sets that voltage, and by some method query the driver for the necessary I2C sequence, either by some special new call, or some regmap magic. ^ permalink raw reply [flat|nested] 84+ messages in thread
* Re: [PATCH v4 0/4] ARM: OMAP2+: AM33XX: VDD CORE OPP50 support 2013-08-29 15:42 ` Russ Dill @ 2013-08-29 18:01 ` Mark Brown -1 siblings, 0 replies; 84+ messages in thread From: Mark Brown @ 2013-08-29 18:01 UTC (permalink / raw) To: Russ Dill Cc: Linux ARM Kernel List, devicetree, linux-omap, Jan Lübbe, Kevin Hilman [-- Attachment #1.1: Type: text/plain, Size: 1582 bytes --] On Thu, Aug 29, 2013 at 08:42:11AM -0700, Russ Dill wrote: > The path I'm taking in this patchset is to just put the board specific > I2C sequences necessary for the CM3 coprocessor to write out into the > devicetree. I've made it as generic as I can so that other platforms > with similar issues can reuse the bindings. Because of the limitations > of the firmware size and the desire not to have some sort of byte > code, this is a write only sequence. Making it write only seems to be a mistake - like I said in my other mail I'd expect you'd want bitfield updates here. The read and modify could be done earlier by Linux though. > Kevin Hilman is suggesting some way to query the regulator framework > for this sequence. There would be some call to the regulator framework > that would return a series of I2C commands that would be necessary to > program a regulator to a specific voltage. It would be called twice, > once for the suspend voltage, once for the resume voltage. The > regulator framework would then call into the driver that sets that > voltage, and by some method query the driver for the necessary I2C > sequence, either by some special new call, or some regmap magic. If it's just setting a single voltage then extracting the bitfield to update shouldn't be too hard for regmap based regulators. Off the top of my head I'd expect either the driver for the M3 or the cpuidle driver that talks to it to be a consumer of the regulator and then go from there. Just putting the sequence directly into the device tree doesn't feel like the right abstraction. [-- Attachment #1.2: Digital signature --] [-- Type: application/pgp-signature, Size: 836 bytes --] [-- Attachment #2: Type: text/plain, Size: 176 bytes --] _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 84+ messages in thread
* [PATCH v4 0/4] ARM: OMAP2+: AM33XX: VDD CORE OPP50 support @ 2013-08-29 18:01 ` Mark Brown 0 siblings, 0 replies; 84+ messages in thread From: Mark Brown @ 2013-08-29 18:01 UTC (permalink / raw) To: linux-arm-kernel On Thu, Aug 29, 2013 at 08:42:11AM -0700, Russ Dill wrote: > The path I'm taking in this patchset is to just put the board specific > I2C sequences necessary for the CM3 coprocessor to write out into the > devicetree. I've made it as generic as I can so that other platforms > with similar issues can reuse the bindings. Because of the limitations > of the firmware size and the desire not to have some sort of byte > code, this is a write only sequence. Making it write only seems to be a mistake - like I said in my other mail I'd expect you'd want bitfield updates here. The read and modify could be done earlier by Linux though. > Kevin Hilman is suggesting some way to query the regulator framework > for this sequence. There would be some call to the regulator framework > that would return a series of I2C commands that would be necessary to > program a regulator to a specific voltage. It would be called twice, > once for the suspend voltage, once for the resume voltage. The > regulator framework would then call into the driver that sets that > voltage, and by some method query the driver for the necessary I2C > sequence, either by some special new call, or some regmap magic. If it's just setting a single voltage then extracting the bitfield to update shouldn't be too hard for regmap based regulators. Off the top of my head I'd expect either the driver for the M3 or the cpuidle driver that talks to it to be a consumer of the regulator and then go from there. Just putting the sequence directly into the device tree doesn't feel like the right abstraction. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: Digital signature URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20130829/c308dfaa/attachment.sig> ^ permalink raw reply [flat|nested] 84+ messages in thread
* Re: [PATCH v4 0/4] ARM: OMAP2+: AM33XX: VDD CORE OPP50 support 2013-08-29 18:01 ` Mark Brown @ 2013-08-29 18:25 ` Russ Dill -1 siblings, 0 replies; 84+ messages in thread From: Russ Dill @ 2013-08-29 18:25 UTC (permalink / raw) To: Mark Brown Cc: Linux ARM Kernel List, devicetree, linux-omap, Jan Lübbe, Kevin Hilman On Thu, Aug 29, 2013 at 11:01 AM, Mark Brown <broonie@kernel.org> wrote: > On Thu, Aug 29, 2013 at 08:42:11AM -0700, Russ Dill wrote: > >> The path I'm taking in this patchset is to just put the board specific >> I2C sequences necessary for the CM3 coprocessor to write out into the >> devicetree. I've made it as generic as I can so that other platforms >> with similar issues can reuse the bindings. Because of the limitations >> of the firmware size and the desire not to have some sort of byte >> code, this is a write only sequence. > > Making it write only seems to be a mistake - like I said in my other > mail I'd expect you'd want bitfield updates here. The read and modify > could be done earlier by Linux though. Updating bitfields in memory is pretty basic, but with I2C, each device has its own register sizes and methods of accessing registers. The first byte of an I2C sequence being a register address is pretty common though. You'd need a method of defining in the device tree piece how to modify bitfields. >> Kevin Hilman is suggesting some way to query the regulator framework >> for this sequence. There would be some call to the regulator framework >> that would return a series of I2C commands that would be necessary to >> program a regulator to a specific voltage. It would be called twice, >> once for the suspend voltage, once for the resume voltage. The >> regulator framework would then call into the driver that sets that >> voltage, and by some method query the driver for the necessary I2C >> sequence, either by some special new call, or some regmap magic. > > If it's just setting a single voltage then extracting the bitfield to > update shouldn't be too hard for regmap based regulators. Off the top > of my head I'd expect either the driver for the M3 or the cpuidle driver > that talks to it to be a consumer of the regulator and then go from > there. It'd be a list of bitfields. So are you suggesting a regulator_ops call that would return a list of bitfield updates along with an I2C controller, an I2C device address, I2C register addressing scheme (8 bit, 16 bit, or other) and the info for each bitfield (register size)? And then each regulator driver would be updated as needed with this code. Would this be a way forward? Would regmap actually tie into this at all? This is VDD core, so its not related to cpuidle or the M3. > Just putting the sequence directly into the device tree doesn't feel > like the right abstraction. > > _______________________________________________ > linux-arm-kernel mailing list > linux-arm-kernel@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/linux-arm-kernel > ^ permalink raw reply [flat|nested] 84+ messages in thread
* [PATCH v4 0/4] ARM: OMAP2+: AM33XX: VDD CORE OPP50 support @ 2013-08-29 18:25 ` Russ Dill 0 siblings, 0 replies; 84+ messages in thread From: Russ Dill @ 2013-08-29 18:25 UTC (permalink / raw) To: linux-arm-kernel On Thu, Aug 29, 2013 at 11:01 AM, Mark Brown <broonie@kernel.org> wrote: > On Thu, Aug 29, 2013 at 08:42:11AM -0700, Russ Dill wrote: > >> The path I'm taking in this patchset is to just put the board specific >> I2C sequences necessary for the CM3 coprocessor to write out into the >> devicetree. I've made it as generic as I can so that other platforms >> with similar issues can reuse the bindings. Because of the limitations >> of the firmware size and the desire not to have some sort of byte >> code, this is a write only sequence. > > Making it write only seems to be a mistake - like I said in my other > mail I'd expect you'd want bitfield updates here. The read and modify > could be done earlier by Linux though. Updating bitfields in memory is pretty basic, but with I2C, each device has its own register sizes and methods of accessing registers. The first byte of an I2C sequence being a register address is pretty common though. You'd need a method of defining in the device tree piece how to modify bitfields. >> Kevin Hilman is suggesting some way to query the regulator framework >> for this sequence. There would be some call to the regulator framework >> that would return a series of I2C commands that would be necessary to >> program a regulator to a specific voltage. It would be called twice, >> once for the suspend voltage, once for the resume voltage. The >> regulator framework would then call into the driver that sets that >> voltage, and by some method query the driver for the necessary I2C >> sequence, either by some special new call, or some regmap magic. > > If it's just setting a single voltage then extracting the bitfield to > update shouldn't be too hard for regmap based regulators. Off the top > of my head I'd expect either the driver for the M3 or the cpuidle driver > that talks to it to be a consumer of the regulator and then go from > there. It'd be a list of bitfields. So are you suggesting a regulator_ops call that would return a list of bitfield updates along with an I2C controller, an I2C device address, I2C register addressing scheme (8 bit, 16 bit, or other) and the info for each bitfield (register size)? And then each regulator driver would be updated as needed with this code. Would this be a way forward? Would regmap actually tie into this at all? This is VDD core, so its not related to cpuidle or the M3. > Just putting the sequence directly into the device tree doesn't feel > like the right abstraction. > > _______________________________________________ > linux-arm-kernel mailing list > linux-arm-kernel at lists.infradead.org > http://lists.infradead.org/mailman/listinfo/linux-arm-kernel > ^ permalink raw reply [flat|nested] 84+ messages in thread
* Re: [PATCH v4 0/4] ARM: OMAP2+: AM33XX: VDD CORE OPP50 support 2013-08-29 18:25 ` Russ Dill @ 2013-08-29 19:10 ` Mark Brown -1 siblings, 0 replies; 84+ messages in thread From: Mark Brown @ 2013-08-29 19:10 UTC (permalink / raw) To: Russ Dill Cc: devicetree, Kevin Hilman, linux-omap, Jan Lübbe, Linux ARM Kernel List [-- Attachment #1.1: Type: text/plain, Size: 2579 bytes --] On Thu, Aug 29, 2013 at 11:25:43AM -0700, Russ Dill wrote: > On Thu, Aug 29, 2013 at 11:01 AM, Mark Brown <broonie@kernel.org> wrote: > > Making it write only seems to be a mistake - like I said in my other > > mail I'd expect you'd want bitfield updates here. The read and modify > > could be done earlier by Linux though. > Updating bitfields in memory is pretty basic, but with I2C, each > device has its own register sizes and methods of accessing registers. > The first byte of an I2C sequence being a register address is pretty > common though. You'd need a method of defining in the device tree > piece how to modify bitfields. I'd not assume byte based addressing for a PMIC, it's very common but not universal. The difficulties here assume putting this in the device tree as explicit register I/O - I do tend to agree with Kevin that this doesn't seem like the right abstraction. > > If it's just setting a single voltage then extracting the bitfield to > > update shouldn't be too hard for regmap based regulators. Off the top > > of my head I'd expect either the driver for the M3 or the cpuidle driver > > that talks to it to be a consumer of the regulator and then go from > > there. > It'd be a list of bitfields. So are you suggesting a regulator_ops > call that would return a list of bitfield updates along with an I2C > controller, an I2C device address, I2C register addressing scheme (8 > bit, 16 bit, or other) and the info for each bitfield (register size)? > And then each regulator driver would be updated as needed with this > code. Would this be a way forward? Would regmap actually tie into this > at all? I was thinking about the majority of regulators where setting a voltage would be a single bitfield update (plus ramp delay, which is going to need to be accounted for in the power on case). If we need to do longer sequences things get a bit more tricky in terms of interface but it seems doable. regmap would tie in in that it already has a way of describing the format for interactions with the device so we could just reuse the same description, and with some work we can probably reuse the code that generates the bitstreams for sending to the devices too (though I don't immediately see a nice way of doing that). Not sure if this is worth the effort or not though, but then there's the whole DT as ABI thing to worry about... > This is VDD core, so its not related to cpuidle or the M3. It's related to the M3 if the M3 is managing it; you can have multiple consumers for a regulator so it doesn't need to be one or the other. [-- Attachment #1.2: Digital signature --] [-- Type: application/pgp-signature, Size: 836 bytes --] [-- Attachment #2: Type: text/plain, Size: 176 bytes --] _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 84+ messages in thread
* [PATCH v4 0/4] ARM: OMAP2+: AM33XX: VDD CORE OPP50 support @ 2013-08-29 19:10 ` Mark Brown 0 siblings, 0 replies; 84+ messages in thread From: Mark Brown @ 2013-08-29 19:10 UTC (permalink / raw) To: linux-arm-kernel On Thu, Aug 29, 2013 at 11:25:43AM -0700, Russ Dill wrote: > On Thu, Aug 29, 2013 at 11:01 AM, Mark Brown <broonie@kernel.org> wrote: > > Making it write only seems to be a mistake - like I said in my other > > mail I'd expect you'd want bitfield updates here. The read and modify > > could be done earlier by Linux though. > Updating bitfields in memory is pretty basic, but with I2C, each > device has its own register sizes and methods of accessing registers. > The first byte of an I2C sequence being a register address is pretty > common though. You'd need a method of defining in the device tree > piece how to modify bitfields. I'd not assume byte based addressing for a PMIC, it's very common but not universal. The difficulties here assume putting this in the device tree as explicit register I/O - I do tend to agree with Kevin that this doesn't seem like the right abstraction. > > If it's just setting a single voltage then extracting the bitfield to > > update shouldn't be too hard for regmap based regulators. Off the top > > of my head I'd expect either the driver for the M3 or the cpuidle driver > > that talks to it to be a consumer of the regulator and then go from > > there. > It'd be a list of bitfields. So are you suggesting a regulator_ops > call that would return a list of bitfield updates along with an I2C > controller, an I2C device address, I2C register addressing scheme (8 > bit, 16 bit, or other) and the info for each bitfield (register size)? > And then each regulator driver would be updated as needed with this > code. Would this be a way forward? Would regmap actually tie into this > at all? I was thinking about the majority of regulators where setting a voltage would be a single bitfield update (plus ramp delay, which is going to need to be accounted for in the power on case). If we need to do longer sequences things get a bit more tricky in terms of interface but it seems doable. regmap would tie in in that it already has a way of describing the format for interactions with the device so we could just reuse the same description, and with some work we can probably reuse the code that generates the bitstreams for sending to the devices too (though I don't immediately see a nice way of doing that). Not sure if this is worth the effort or not though, but then there's the whole DT as ABI thing to worry about... > This is VDD core, so its not related to cpuidle or the M3. It's related to the M3 if the M3 is managing it; you can have multiple consumers for a regulator so it doesn't need to be one or the other. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: Digital signature URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20130829/606d058c/attachment.sig> ^ permalink raw reply [flat|nested] 84+ messages in thread
* Re: [PATCH v4 0/4] ARM: OMAP2+: AM33XX: VDD CORE OPP50 support 2013-08-29 19:10 ` Mark Brown @ 2013-09-03 14:06 ` Russ Dill -1 siblings, 0 replies; 84+ messages in thread From: Russ Dill @ 2013-09-03 14:06 UTC (permalink / raw) To: Mark Brown Cc: devicetree, Kevin Hilman, linux-omap, Jan Lübbe, Linux ARM Kernel List On Thu, Aug 29, 2013 at 12:10 PM, Mark Brown <broonie@kernel.org> wrote: > On Thu, Aug 29, 2013 at 11:25:43AM -0700, Russ Dill wrote: >> On Thu, Aug 29, 2013 at 11:01 AM, Mark Brown <broonie@kernel.org> wrote: > >> > Making it write only seems to be a mistake - like I said in my other >> > mail I'd expect you'd want bitfield updates here. The read and modify >> > could be done earlier by Linux though. > >> Updating bitfields in memory is pretty basic, but with I2C, each >> device has its own register sizes and methods of accessing registers. >> The first byte of an I2C sequence being a register address is pretty >> common though. You'd need a method of defining in the device tree >> piece how to modify bitfields. > > I'd not assume byte based addressing for a PMIC, it's very common but > not universal. The difficulties here assume putting this in the device > tree as explicit register I/O - I do tend to agree with Kevin that this > doesn't seem like the right abstraction. > >> > If it's just setting a single voltage then extracting the bitfield to >> > update shouldn't be too hard for regmap based regulators. Off the top >> > of my head I'd expect either the driver for the M3 or the cpuidle driver >> > that talks to it to be a consumer of the regulator and then go from >> > there. > >> It'd be a list of bitfields. So are you suggesting a regulator_ops >> call that would return a list of bitfield updates along with an I2C >> controller, an I2C device address, I2C register addressing scheme (8 >> bit, 16 bit, or other) and the info for each bitfield (register size)? >> And then each regulator driver would be updated as needed with this >> code. Would this be a way forward? Would regmap actually tie into this >> at all? > > I was thinking about the majority of regulators where setting a voltage > would be a single bitfield update (plus ramp delay, which is going to > need to be accounted for in the power on case). If we need to do longer > sequences things get a bit more tricky in terms of interface but it > seems doable. The sequence for TPS65217 on beaglebone is rather long, it's 8 register writes. It has to write the new value to the DCDC3 register and the apply bit to the DCDC register, but both registers are password locked registers. The password sequence is to write the password register, then the register, then the password register again, then the register again. > regmap would tie in in that it already has a way of describing the > format for interactions with the device so we could just reuse the same > description, and with some work we can probably reuse the code that > generates the bitstreams for sending to the devices too (though I don't > immediately see a nice way of doing that). > > Not sure if this is worth the effort or not though, but then there's the > whole DT as ABI thing to worry about... > >> This is VDD core, so its not related to cpuidle or the M3. > > It's related to the M3 if the M3 is managing it; you can have multiple > consumers for a regulator so it doesn't need to be one or the other. Ah. > _______________________________________________ > linux-arm-kernel mailing list > linux-arm-kernel@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/linux-arm-kernel > ^ permalink raw reply [flat|nested] 84+ messages in thread
* [PATCH v4 0/4] ARM: OMAP2+: AM33XX: VDD CORE OPP50 support @ 2013-09-03 14:06 ` Russ Dill 0 siblings, 0 replies; 84+ messages in thread From: Russ Dill @ 2013-09-03 14:06 UTC (permalink / raw) To: linux-arm-kernel On Thu, Aug 29, 2013 at 12:10 PM, Mark Brown <broonie@kernel.org> wrote: > On Thu, Aug 29, 2013 at 11:25:43AM -0700, Russ Dill wrote: >> On Thu, Aug 29, 2013 at 11:01 AM, Mark Brown <broonie@kernel.org> wrote: > >> > Making it write only seems to be a mistake - like I said in my other >> > mail I'd expect you'd want bitfield updates here. The read and modify >> > could be done earlier by Linux though. > >> Updating bitfields in memory is pretty basic, but with I2C, each >> device has its own register sizes and methods of accessing registers. >> The first byte of an I2C sequence being a register address is pretty >> common though. You'd need a method of defining in the device tree >> piece how to modify bitfields. > > I'd not assume byte based addressing for a PMIC, it's very common but > not universal. The difficulties here assume putting this in the device > tree as explicit register I/O - I do tend to agree with Kevin that this > doesn't seem like the right abstraction. > >> > If it's just setting a single voltage then extracting the bitfield to >> > update shouldn't be too hard for regmap based regulators. Off the top >> > of my head I'd expect either the driver for the M3 or the cpuidle driver >> > that talks to it to be a consumer of the regulator and then go from >> > there. > >> It'd be a list of bitfields. So are you suggesting a regulator_ops >> call that would return a list of bitfield updates along with an I2C >> controller, an I2C device address, I2C register addressing scheme (8 >> bit, 16 bit, or other) and the info for each bitfield (register size)? >> And then each regulator driver would be updated as needed with this >> code. Would this be a way forward? Would regmap actually tie into this >> at all? > > I was thinking about the majority of regulators where setting a voltage > would be a single bitfield update (plus ramp delay, which is going to > need to be accounted for in the power on case). If we need to do longer > sequences things get a bit more tricky in terms of interface but it > seems doable. The sequence for TPS65217 on beaglebone is rather long, it's 8 register writes. It has to write the new value to the DCDC3 register and the apply bit to the DCDC register, but both registers are password locked registers. The password sequence is to write the password register, then the register, then the password register again, then the register again. > regmap would tie in in that it already has a way of describing the > format for interactions with the device so we could just reuse the same > description, and with some work we can probably reuse the code that > generates the bitstreams for sending to the devices too (though I don't > immediately see a nice way of doing that). > > Not sure if this is worth the effort or not though, but then there's the > whole DT as ABI thing to worry about... > >> This is VDD core, so its not related to cpuidle or the M3. > > It's related to the M3 if the M3 is managing it; you can have multiple > consumers for a regulator so it doesn't need to be one or the other. Ah. > _______________________________________________ > linux-arm-kernel mailing list > linux-arm-kernel at lists.infradead.org > http://lists.infradead.org/mailman/listinfo/linux-arm-kernel > ^ permalink raw reply [flat|nested] 84+ messages in thread
* Re: [PATCH v4 0/4] ARM: OMAP2+: AM33XX: VDD CORE OPP50 support 2013-09-03 14:06 ` Russ Dill @ 2013-09-03 14:39 ` Mark Brown -1 siblings, 0 replies; 84+ messages in thread From: Mark Brown @ 2013-09-03 14:39 UTC (permalink / raw) To: Russ Dill Cc: devicetree, Kevin Hilman, linux-omap, Jan Lübbe, Linux ARM Kernel List [-- Attachment #1: Type: text/plain, Size: 965 bytes --] On Tue, Sep 03, 2013 at 07:06:01AM -0700, Russ Dill wrote: > On Thu, Aug 29, 2013 at 12:10 PM, Mark Brown <broonie@kernel.org> wrote: > > I was thinking about the majority of regulators where setting a voltage > > would be a single bitfield update (plus ramp delay, which is going to > > need to be accounted for in the power on case). If we need to do longer > > sequences things get a bit more tricky in terms of interface but it > > seems doable. > The sequence for TPS65217 on beaglebone is rather long, it's 8 > register writes. It has to write the new value to the DCDC3 register > and the apply bit to the DCDC register, but both registers are > password locked registers. The password sequence is to write the > password register, then the register, then the password register > again, then the register again. Oh dear, that's a bit annoying. It's doable obviously if people decide to go down that route but it's work and this is a very common system. [-- Attachment #2: Digital signature --] [-- Type: application/pgp-signature, Size: 836 bytes --] ^ permalink raw reply [flat|nested] 84+ messages in thread
* [PATCH v4 0/4] ARM: OMAP2+: AM33XX: VDD CORE OPP50 support @ 2013-09-03 14:39 ` Mark Brown 0 siblings, 0 replies; 84+ messages in thread From: Mark Brown @ 2013-09-03 14:39 UTC (permalink / raw) To: linux-arm-kernel On Tue, Sep 03, 2013 at 07:06:01AM -0700, Russ Dill wrote: > On Thu, Aug 29, 2013 at 12:10 PM, Mark Brown <broonie@kernel.org> wrote: > > I was thinking about the majority of regulators where setting a voltage > > would be a single bitfield update (plus ramp delay, which is going to > > need to be accounted for in the power on case). If we need to do longer > > sequences things get a bit more tricky in terms of interface but it > > seems doable. > The sequence for TPS65217 on beaglebone is rather long, it's 8 > register writes. It has to write the new value to the DCDC3 register > and the apply bit to the DCDC register, but both registers are > password locked registers. The password sequence is to write the > password register, then the register, then the password register > again, then the register again. Oh dear, that's a bit annoying. It's doable obviously if people decide to go down that route but it's work and this is a very common system. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: Digital signature URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20130903/76f33bcf/attachment-0001.sig> ^ permalink raw reply [flat|nested] 84+ messages in thread
* Re: [PATCH v4 0/4] ARM: OMAP2+: AM33XX: VDD CORE OPP50 support 2013-08-28 1:05 ` Russ Dill @ 2013-08-29 15:17 ` Kevin Hilman -1 siblings, 0 replies; 84+ messages in thread From: Kevin Hilman @ 2013-08-29 15:17 UTC (permalink / raw) To: Russ Dill Cc: Jan Lübbe, devicetree, linux-omap, Linux ARM Kernel List, Mark Brown Russ Dill <Russ.Dill@ti.com> writes: > On Tue, Aug 27, 2013 at 3:44 PM, Kevin Hilman <khilman@linaro.org> wrote: >> [+Mark Brown for regulator suspend sequence ideas] >> >> Russ Dill <Russ.Dill@ti.com> writes: >> >>> On Wed, Aug 14, 2013 at 6:38 AM, Jan Lübbe <jlu@pengutronix.de> wrote: >>>> On Tue, 2013-08-13 at 15:20 -0700, Russ Dill wrote: > [snip] >>>> Shouldn't the TPS driver know how to generate this sequence? It seems >>>> fragile to do voltage adjustments behind the back of the regulator >>>> framework and the TPS driver. The wake-sequence values should match the >>>> (in-memory) regulator configuration on resume (which may have been >>>> changed by DVFS). >>> >>> The sequence is both PMIC specific and board specific. Additionally, >>> the PMICs used aren't am335x specific. It would be nice to have the >>> regulator framework and the driver write all this out, but the >>> sequence is written out by the Cortex-M3 processor running some PM >>> firmware. Even if the code was changed to run on the A8, it'd have to >>> run from a small piece of SRAM. >> >> So, why/how was the decision made to use the M3 instead of the MPU >> running from SRAM? >> >> As a firmware minimalist, I obviously prefer to do this from the MPU >> side. But also, because the M3 is reset every suspend sequence, this >> becomes rather heavy to do from the M3. > > After the feedback Vaibhav Bedia received on v2 of his suspend/resume > patchset for am335x, he decided to move many of the operations from > sleep33xx.S into the M3 firmware. > > See the commit message here: > http://arago-project.org/git/projects/?p=am33x-cm3.git;a=commit;h=a972ce2f6 Was this feedback on the public lists? That patch has never been posted to linux-omap AFAICT. > I need to wait until after the PLLs are put into bypass, which is now > done in the M3 firmware. It also ends up being a lot easier to write > the I2C writer code there in C rather than in assembly in sleep33xx.S. hmm, (carefully) written functions in C can still be copied to SRAM. I dont' see that as an obstacle. >> Currently voltage scaling is only being proposed for suspend in this >> series, but in theory it's possible from idle as well. Doing this from >> the MPU/SRAM seems much better suited for idle. > > The M3 firmware will also handle any cpuidle modes deeper than just > putting SDRAM into self refresh. This is actually the only way of > doing things like turning the MPU domain off on am335x. Yes, it will have to handle the MPU/interconnect off parts but other than that, that's the only thing it *has* to do (well, and handle wakeup from the deep state.) The rest of the stuff being piled into the M3 is a result of software/firmware design decisions AFAICT. As I predicted when I first saw this SoC design, the firmware is getting bigger and bigger. Initially it was argued that it would be tiny, and only handle the things it had to do. Now it's growing due to "convenience". IMO, this is a bad trend, and one that will make this code more and more difficult to maintain upstream (assuming that's a goal.) Kevin -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 84+ messages in thread
* [PATCH v4 0/4] ARM: OMAP2+: AM33XX: VDD CORE OPP50 support @ 2013-08-29 15:17 ` Kevin Hilman 0 siblings, 0 replies; 84+ messages in thread From: Kevin Hilman @ 2013-08-29 15:17 UTC (permalink / raw) To: linux-arm-kernel Russ Dill <Russ.Dill@ti.com> writes: > On Tue, Aug 27, 2013 at 3:44 PM, Kevin Hilman <khilman@linaro.org> wrote: >> [+Mark Brown for regulator suspend sequence ideas] >> >> Russ Dill <Russ.Dill@ti.com> writes: >> >>> On Wed, Aug 14, 2013 at 6:38 AM, Jan L?bbe <jlu@pengutronix.de> wrote: >>>> On Tue, 2013-08-13 at 15:20 -0700, Russ Dill wrote: > [snip] >>>> Shouldn't the TPS driver know how to generate this sequence? It seems >>>> fragile to do voltage adjustments behind the back of the regulator >>>> framework and the TPS driver. The wake-sequence values should match the >>>> (in-memory) regulator configuration on resume (which may have been >>>> changed by DVFS). >>> >>> The sequence is both PMIC specific and board specific. Additionally, >>> the PMICs used aren't am335x specific. It would be nice to have the >>> regulator framework and the driver write all this out, but the >>> sequence is written out by the Cortex-M3 processor running some PM >>> firmware. Even if the code was changed to run on the A8, it'd have to >>> run from a small piece of SRAM. >> >> So, why/how was the decision made to use the M3 instead of the MPU >> running from SRAM? >> >> As a firmware minimalist, I obviously prefer to do this from the MPU >> side. But also, because the M3 is reset every suspend sequence, this >> becomes rather heavy to do from the M3. > > After the feedback Vaibhav Bedia received on v2 of his suspend/resume > patchset for am335x, he decided to move many of the operations from > sleep33xx.S into the M3 firmware. > > See the commit message here: > http://arago-project.org/git/projects/?p=am33x-cm3.git;a=commit;h=a972ce2f6 Was this feedback on the public lists? That patch has never been posted to linux-omap AFAICT. > I need to wait until after the PLLs are put into bypass, which is now > done in the M3 firmware. It also ends up being a lot easier to write > the I2C writer code there in C rather than in assembly in sleep33xx.S. hmm, (carefully) written functions in C can still be copied to SRAM. I dont' see that as an obstacle. >> Currently voltage scaling is only being proposed for suspend in this >> series, but in theory it's possible from idle as well. Doing this from >> the MPU/SRAM seems much better suited for idle. > > The M3 firmware will also handle any cpuidle modes deeper than just > putting SDRAM into self refresh. This is actually the only way of > doing things like turning the MPU domain off on am335x. Yes, it will have to handle the MPU/interconnect off parts but other than that, that's the only thing it *has* to do (well, and handle wakeup from the deep state.) The rest of the stuff being piled into the M3 is a result of software/firmware design decisions AFAICT. As I predicted when I first saw this SoC design, the firmware is getting bigger and bigger. Initially it was argued that it would be tiny, and only handle the things it had to do. Now it's growing due to "convenience". IMO, this is a bad trend, and one that will make this code more and more difficult to maintain upstream (assuming that's a goal.) Kevin ^ permalink raw reply [flat|nested] 84+ messages in thread
* Re: [PATCH v4 0/4] ARM: OMAP2+: AM33XX: VDD CORE OPP50 support 2013-08-29 15:17 ` Kevin Hilman @ 2013-08-29 16:10 ` Russ Dill -1 siblings, 0 replies; 84+ messages in thread From: Russ Dill @ 2013-08-29 16:10 UTC (permalink / raw) To: Kevin Hilman Cc: devicetree, Mark Brown, linux-omap, Jan Lübbe, Linux ARM Kernel List On Thu, Aug 29, 2013 at 8:17 AM, Kevin Hilman <khilman@linaro.org> wrote: > Russ Dill <Russ.Dill@ti.com> writes: > >> On Tue, Aug 27, 2013 at 3:44 PM, Kevin Hilman <khilman@linaro.org> wrote: >>> [+Mark Brown for regulator suspend sequence ideas] >>> >>> Russ Dill <Russ.Dill@ti.com> writes: >>> >>>> On Wed, Aug 14, 2013 at 6:38 AM, Jan Lübbe <jlu@pengutronix.de> wrote: >>>>> On Tue, 2013-08-13 at 15:20 -0700, Russ Dill wrote: >> [snip] >>>>> Shouldn't the TPS driver know how to generate this sequence? It seems >>>>> fragile to do voltage adjustments behind the back of the regulator >>>>> framework and the TPS driver. The wake-sequence values should match the >>>>> (in-memory) regulator configuration on resume (which may have been >>>>> changed by DVFS). >>>> >>>> The sequence is both PMIC specific and board specific. Additionally, >>>> the PMICs used aren't am335x specific. It would be nice to have the >>>> regulator framework and the driver write all this out, but the >>>> sequence is written out by the Cortex-M3 processor running some PM >>>> firmware. Even if the code was changed to run on the A8, it'd have to >>>> run from a small piece of SRAM. >>> >>> So, why/how was the decision made to use the M3 instead of the MPU >>> running from SRAM? >>> >>> As a firmware minimalist, I obviously prefer to do this from the MPU >>> side. But also, because the M3 is reset every suspend sequence, this >>> becomes rather heavy to do from the M3. >> >> After the feedback Vaibhav Bedia received on v2 of his suspend/resume >> patchset for am335x, he decided to move many of the operations from >> sleep33xx.S into the M3 firmware. >> >> See the commit message here: >> http://arago-project.org/git/projects/?p=am33x-cm3.git;a=commit;h=a972ce2f6 > > Was this feedback on the public lists? That patch has never been posted > to linux-omap AFAICT. > >> I need to wait until after the PLLs are put into bypass, which is now >> done in the M3 firmware. It also ends up being a lot easier to write >> the I2C writer code there in C rather than in assembly in sleep33xx.S. > > hmm, (carefully) written functions in C can still be copied to SRAM. I > dont' see that as an obstacle. > >>> Currently voltage scaling is only being proposed for suspend in this >>> series, but in theory it's possible from idle as well. Doing this from >>> the MPU/SRAM seems much better suited for idle. >> >> The M3 firmware will also handle any cpuidle modes deeper than just >> putting SDRAM into self refresh. This is actually the only way of >> doing things like turning the MPU domain off on am335x. > > Yes, it will have to handle the MPU/interconnect off parts but other > than that, that's the only thing it *has* to do (well, and handle wakeup > from the deep state.) The rest of the stuff being piled into the M3 is > a result of software/firmware design decisions AFAICT. As I predicted > when I first saw this SoC design, the firmware is getting bigger and > bigger. Initially it was argued that it would be tiny, and only handle > the things it had to do. Now it's growing due to "convenience". IMO, > this is a bad trend, and one that will make this code more and more > difficult to maintain upstream (assuming that's a goal.) Do you mean upstream as in the firmware upstream, or upstream as in the kernel upstream? Upstream kernel is really easy to maintain because sleep33xx.S just puts the SDRAM into self-refresh. The code to perform these transitions is going to exist, either in kernel or in firmware. If you are looking for this to be maintainable C code that is copied into SRAM, it will need to be built much like a firmware, with it's elf sections being copied into SRAM properly. I'm not sure how much it complicates things, but the code needs to be able to run with the MMU on and MMU off. The C code would be a minimalized duplication of much of what is already in mach-omap2. Because you are proposing to split this up between A8 and M3, much of that code would then be duplicated again within the M3 firmware. And don't forget that am335x is just the first platform with such a PM scheme. Because the M3 firmware already has to manage power domains, hwmods, plls, and clockdomains, adding or removing which ones it handles doesn't really change the size or complexity of the firmware. In fact, because so much of the code is common code, moving this into kernel would just mean making two copies of the firmware with different steps to be run, one for the A8 SRAM, one for the M3. -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 84+ messages in thread
* [PATCH v4 0/4] ARM: OMAP2+: AM33XX: VDD CORE OPP50 support @ 2013-08-29 16:10 ` Russ Dill 0 siblings, 0 replies; 84+ messages in thread From: Russ Dill @ 2013-08-29 16:10 UTC (permalink / raw) To: linux-arm-kernel On Thu, Aug 29, 2013 at 8:17 AM, Kevin Hilman <khilman@linaro.org> wrote: > Russ Dill <Russ.Dill@ti.com> writes: > >> On Tue, Aug 27, 2013 at 3:44 PM, Kevin Hilman <khilman@linaro.org> wrote: >>> [+Mark Brown for regulator suspend sequence ideas] >>> >>> Russ Dill <Russ.Dill@ti.com> writes: >>> >>>> On Wed, Aug 14, 2013 at 6:38 AM, Jan L?bbe <jlu@pengutronix.de> wrote: >>>>> On Tue, 2013-08-13 at 15:20 -0700, Russ Dill wrote: >> [snip] >>>>> Shouldn't the TPS driver know how to generate this sequence? It seems >>>>> fragile to do voltage adjustments behind the back of the regulator >>>>> framework and the TPS driver. The wake-sequence values should match the >>>>> (in-memory) regulator configuration on resume (which may have been >>>>> changed by DVFS). >>>> >>>> The sequence is both PMIC specific and board specific. Additionally, >>>> the PMICs used aren't am335x specific. It would be nice to have the >>>> regulator framework and the driver write all this out, but the >>>> sequence is written out by the Cortex-M3 processor running some PM >>>> firmware. Even if the code was changed to run on the A8, it'd have to >>>> run from a small piece of SRAM. >>> >>> So, why/how was the decision made to use the M3 instead of the MPU >>> running from SRAM? >>> >>> As a firmware minimalist, I obviously prefer to do this from the MPU >>> side. But also, because the M3 is reset every suspend sequence, this >>> becomes rather heavy to do from the M3. >> >> After the feedback Vaibhav Bedia received on v2 of his suspend/resume >> patchset for am335x, he decided to move many of the operations from >> sleep33xx.S into the M3 firmware. >> >> See the commit message here: >> http://arago-project.org/git/projects/?p=am33x-cm3.git;a=commit;h=a972ce2f6 > > Was this feedback on the public lists? That patch has never been posted > to linux-omap AFAICT. > >> I need to wait until after the PLLs are put into bypass, which is now >> done in the M3 firmware. It also ends up being a lot easier to write >> the I2C writer code there in C rather than in assembly in sleep33xx.S. > > hmm, (carefully) written functions in C can still be copied to SRAM. I > dont' see that as an obstacle. > >>> Currently voltage scaling is only being proposed for suspend in this >>> series, but in theory it's possible from idle as well. Doing this from >>> the MPU/SRAM seems much better suited for idle. >> >> The M3 firmware will also handle any cpuidle modes deeper than just >> putting SDRAM into self refresh. This is actually the only way of >> doing things like turning the MPU domain off on am335x. > > Yes, it will have to handle the MPU/interconnect off parts but other > than that, that's the only thing it *has* to do (well, and handle wakeup > from the deep state.) The rest of the stuff being piled into the M3 is > a result of software/firmware design decisions AFAICT. As I predicted > when I first saw this SoC design, the firmware is getting bigger and > bigger. Initially it was argued that it would be tiny, and only handle > the things it had to do. Now it's growing due to "convenience". IMO, > this is a bad trend, and one that will make this code more and more > difficult to maintain upstream (assuming that's a goal.) Do you mean upstream as in the firmware upstream, or upstream as in the kernel upstream? Upstream kernel is really easy to maintain because sleep33xx.S just puts the SDRAM into self-refresh. The code to perform these transitions is going to exist, either in kernel or in firmware. If you are looking for this to be maintainable C code that is copied into SRAM, it will need to be built much like a firmware, with it's elf sections being copied into SRAM properly. I'm not sure how much it complicates things, but the code needs to be able to run with the MMU on and MMU off. The C code would be a minimalized duplication of much of what is already in mach-omap2. Because you are proposing to split this up between A8 and M3, much of that code would then be duplicated again within the M3 firmware. And don't forget that am335x is just the first platform with such a PM scheme. Because the M3 firmware already has to manage power domains, hwmods, plls, and clockdomains, adding or removing which ones it handles doesn't really change the size or complexity of the firmware. In fact, because so much of the code is common code, moving this into kernel would just mean making two copies of the firmware with different steps to be run, one for the A8 SRAM, one for the M3. ^ permalink raw reply [flat|nested] 84+ messages in thread
* Re: [PATCH v4 0/4] ARM: OMAP2+: AM33XX: VDD CORE OPP50 support 2013-08-29 16:10 ` Russ Dill @ 2013-08-29 19:11 ` Kevin Hilman -1 siblings, 0 replies; 84+ messages in thread From: Kevin Hilman @ 2013-08-29 19:11 UTC (permalink / raw) To: Russ Dill Cc: devicetree, Mark Brown, linux-omap, Jan Lübbe, Linux ARM Kernel List Russ Dill <Russ.Dill@ti.com> writes: > On Thu, Aug 29, 2013 at 8:17 AM, Kevin Hilman <khilman@linaro.org> wrote: >> Russ Dill <Russ.Dill@ti.com> writes: >> >>> On Tue, Aug 27, 2013 at 3:44 PM, Kevin Hilman <khilman@linaro.org> wrote: >>>> [+Mark Brown for regulator suspend sequence ideas] >>>> >>>> Russ Dill <Russ.Dill@ti.com> writes: >>>> >>>>> On Wed, Aug 14, 2013 at 6:38 AM, Jan Lübbe <jlu@pengutronix.de> wrote: >>>>>> On Tue, 2013-08-13 at 15:20 -0700, Russ Dill wrote: >>> [snip] >>>>>> Shouldn't the TPS driver know how to generate this sequence? It seems >>>>>> fragile to do voltage adjustments behind the back of the regulator >>>>>> framework and the TPS driver. The wake-sequence values should match the >>>>>> (in-memory) regulator configuration on resume (which may have been >>>>>> changed by DVFS). >>>>> >>>>> The sequence is both PMIC specific and board specific. Additionally, >>>>> the PMICs used aren't am335x specific. It would be nice to have the >>>>> regulator framework and the driver write all this out, but the >>>>> sequence is written out by the Cortex-M3 processor running some PM >>>>> firmware. Even if the code was changed to run on the A8, it'd have to >>>>> run from a small piece of SRAM. >>>> >>>> So, why/how was the decision made to use the M3 instead of the MPU >>>> running from SRAM? >>>> >>>> As a firmware minimalist, I obviously prefer to do this from the MPU >>>> side. But also, because the M3 is reset every suspend sequence, this >>>> becomes rather heavy to do from the M3. >>> >>> After the feedback Vaibhav Bedia received on v2 of his suspend/resume >>> patchset for am335x, he decided to move many of the operations from >>> sleep33xx.S into the M3 firmware. >>> >>> See the commit message here: >>> http://arago-project.org/git/projects/?p=am33x-cm3.git;a=commit;h=a972ce2f6 >> >> Was this feedback on the public lists? That patch has never been posted >> to linux-omap AFAICT. >> >>> I need to wait until after the PLLs are put into bypass, which is now >>> done in the M3 firmware. It also ends up being a lot easier to write >>> the I2C writer code there in C rather than in assembly in sleep33xx.S. >> >> hmm, (carefully) written functions in C can still be copied to SRAM. I >> dont' see that as an obstacle. >> >>>> Currently voltage scaling is only being proposed for suspend in this >>>> series, but in theory it's possible from idle as well. Doing this from >>>> the MPU/SRAM seems much better suited for idle. >>> >>> The M3 firmware will also handle any cpuidle modes deeper than just >>> putting SDRAM into self refresh. This is actually the only way of >>> doing things like turning the MPU domain off on am335x. >> >> Yes, it will have to handle the MPU/interconnect off parts but other >> than that, that's the only thing it *has* to do (well, and handle wakeup >> from the deep state.) The rest of the stuff being piled into the M3 is >> a result of software/firmware design decisions AFAICT. As I predicted >> when I first saw this SoC design, the firmware is getting bigger and >> bigger. Initially it was argued that it would be tiny, and only handle >> the things it had to do. Now it's growing due to "convenience". IMO, >> this is a bad trend, and one that will make this code more and more >> difficult to maintain upstream (assuming that's a goal.) > > Do you mean upstream as in the firmware upstream, or upstream as in > the kernel upstream? Upstream kernel is really easy to maintain > because sleep33xx.S just puts the SDRAM into self-refresh. I mean making the kernel "simple" at the price of more complicated (and much less reviewed) firmware code is a bad trend. I understand the desire to move this stuff into firmware and bypass the kernel review process, but I predict it will backfire. > The code to perform these transitions is going to exist, either in > kernel or in firmware. If you are looking for this to be maintainable > C code that is copied into SRAM, it will need to be built much like a > firmware, with it's elf sections being copied into SRAM properly. You're making it too complicated. No need for ELF, etc. So the argument for moving much of the stuff from the kernel (in the patch you referenced above) was that the "assembly code is quite big and folks have found it hard to review and fixup issues in this dense piece of code." (interestingly, it was moved to firmware where it will see even less review, but that's off topic.) My idea was that if reviewing assembly is the issue, why not carefully write a self-contained C function that can be copied to SRAM. It might need a little stub in SRAM to setup the stack etc., but it should be quite doable. That eliminates the problem cited as the reason for the move to M3. > I'm not sure how much it complicates things, but the code needs to be > able to run with the MMU on and MMU off. The C code would be a > minimalized duplication of much of what is already in > mach-omap2. Because you are proposing to split this up between A8 and > M3, much of that code would then be duplicated again within the M3 > firmware. > > And don't forget that am335x is just the first platform with such a PM scheme. IMO, all the more reason to handle it in Linux, not in platform-specific firmware. > Because the M3 firmware already has to manage power domains, hwmods, > plls, and clockdomains, adding or removing which ones it handles > doesn't really change the size or complexity of the firmware. No, but it significantly complicates its interaction with Linux, which also has to know about all these things already. IMO, as I've stated from the very beginning of this SoC, there should be a very clean split. M3 should only handle the minimum, what the MPU simply cannot do (MPU/interconnect off, wakeup). MPU/Linux should handle the rest. > In fact, because so much of the code is common code, moving this into > kernel would just mean making two copies of the firmware with > different steps to be run, one for the A8 SRAM, one for the M3. Maybe I'm getting confused, but the more you talk about the linux and the firmware doing the same code, the more I think the firmware is (trying) to do too much. If this is going to be understandable (and maintainable), there needs to be a clean split of roles between the MPU and the M3. Kevin -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 84+ messages in thread
* [PATCH v4 0/4] ARM: OMAP2+: AM33XX: VDD CORE OPP50 support @ 2013-08-29 19:11 ` Kevin Hilman 0 siblings, 0 replies; 84+ messages in thread From: Kevin Hilman @ 2013-08-29 19:11 UTC (permalink / raw) To: linux-arm-kernel Russ Dill <Russ.Dill@ti.com> writes: > On Thu, Aug 29, 2013 at 8:17 AM, Kevin Hilman <khilman@linaro.org> wrote: >> Russ Dill <Russ.Dill@ti.com> writes: >> >>> On Tue, Aug 27, 2013 at 3:44 PM, Kevin Hilman <khilman@linaro.org> wrote: >>>> [+Mark Brown for regulator suspend sequence ideas] >>>> >>>> Russ Dill <Russ.Dill@ti.com> writes: >>>> >>>>> On Wed, Aug 14, 2013 at 6:38 AM, Jan L?bbe <jlu@pengutronix.de> wrote: >>>>>> On Tue, 2013-08-13 at 15:20 -0700, Russ Dill wrote: >>> [snip] >>>>>> Shouldn't the TPS driver know how to generate this sequence? It seems >>>>>> fragile to do voltage adjustments behind the back of the regulator >>>>>> framework and the TPS driver. The wake-sequence values should match the >>>>>> (in-memory) regulator configuration on resume (which may have been >>>>>> changed by DVFS). >>>>> >>>>> The sequence is both PMIC specific and board specific. Additionally, >>>>> the PMICs used aren't am335x specific. It would be nice to have the >>>>> regulator framework and the driver write all this out, but the >>>>> sequence is written out by the Cortex-M3 processor running some PM >>>>> firmware. Even if the code was changed to run on the A8, it'd have to >>>>> run from a small piece of SRAM. >>>> >>>> So, why/how was the decision made to use the M3 instead of the MPU >>>> running from SRAM? >>>> >>>> As a firmware minimalist, I obviously prefer to do this from the MPU >>>> side. But also, because the M3 is reset every suspend sequence, this >>>> becomes rather heavy to do from the M3. >>> >>> After the feedback Vaibhav Bedia received on v2 of his suspend/resume >>> patchset for am335x, he decided to move many of the operations from >>> sleep33xx.S into the M3 firmware. >>> >>> See the commit message here: >>> http://arago-project.org/git/projects/?p=am33x-cm3.git;a=commit;h=a972ce2f6 >> >> Was this feedback on the public lists? That patch has never been posted >> to linux-omap AFAICT. >> >>> I need to wait until after the PLLs are put into bypass, which is now >>> done in the M3 firmware. It also ends up being a lot easier to write >>> the I2C writer code there in C rather than in assembly in sleep33xx.S. >> >> hmm, (carefully) written functions in C can still be copied to SRAM. I >> dont' see that as an obstacle. >> >>>> Currently voltage scaling is only being proposed for suspend in this >>>> series, but in theory it's possible from idle as well. Doing this from >>>> the MPU/SRAM seems much better suited for idle. >>> >>> The M3 firmware will also handle any cpuidle modes deeper than just >>> putting SDRAM into self refresh. This is actually the only way of >>> doing things like turning the MPU domain off on am335x. >> >> Yes, it will have to handle the MPU/interconnect off parts but other >> than that, that's the only thing it *has* to do (well, and handle wakeup >> from the deep state.) The rest of the stuff being piled into the M3 is >> a result of software/firmware design decisions AFAICT. As I predicted >> when I first saw this SoC design, the firmware is getting bigger and >> bigger. Initially it was argued that it would be tiny, and only handle >> the things it had to do. Now it's growing due to "convenience". IMO, >> this is a bad trend, and one that will make this code more and more >> difficult to maintain upstream (assuming that's a goal.) > > Do you mean upstream as in the firmware upstream, or upstream as in > the kernel upstream? Upstream kernel is really easy to maintain > because sleep33xx.S just puts the SDRAM into self-refresh. I mean making the kernel "simple" at the price of more complicated (and much less reviewed) firmware code is a bad trend. I understand the desire to move this stuff into firmware and bypass the kernel review process, but I predict it will backfire. > The code to perform these transitions is going to exist, either in > kernel or in firmware. If you are looking for this to be maintainable > C code that is copied into SRAM, it will need to be built much like a > firmware, with it's elf sections being copied into SRAM properly. You're making it too complicated. No need for ELF, etc. So the argument for moving much of the stuff from the kernel (in the patch you referenced above) was that the "assembly code is quite big and folks have found it hard to review and fixup issues in this dense piece of code." (interestingly, it was moved to firmware where it will see even less review, but that's off topic.) My idea was that if reviewing assembly is the issue, why not carefully write a self-contained C function that can be copied to SRAM. It might need a little stub in SRAM to setup the stack etc., but it should be quite doable. That eliminates the problem cited as the reason for the move to M3. > I'm not sure how much it complicates things, but the code needs to be > able to run with the MMU on and MMU off. The C code would be a > minimalized duplication of much of what is already in > mach-omap2. Because you are proposing to split this up between A8 and > M3, much of that code would then be duplicated again within the M3 > firmware. > > And don't forget that am335x is just the first platform with such a PM scheme. IMO, all the more reason to handle it in Linux, not in platform-specific firmware. > Because the M3 firmware already has to manage power domains, hwmods, > plls, and clockdomains, adding or removing which ones it handles > doesn't really change the size or complexity of the firmware. No, but it significantly complicates its interaction with Linux, which also has to know about all these things already. IMO, as I've stated from the very beginning of this SoC, there should be a very clean split. M3 should only handle the minimum, what the MPU simply cannot do (MPU/interconnect off, wakeup). MPU/Linux should handle the rest. > In fact, because so much of the code is common code, moving this into > kernel would just mean making two copies of the firmware with > different steps to be run, one for the A8 SRAM, one for the M3. Maybe I'm getting confused, but the more you talk about the linux and the firmware doing the same code, the more I think the firmware is (trying) to do too much. If this is going to be understandable (and maintainable), there needs to be a clean split of roles between the MPU and the M3. Kevin ^ permalink raw reply [flat|nested] 84+ messages in thread
* Re: [PATCH v4 0/4] ARM: OMAP2+: AM33XX: VDD CORE OPP50 support 2013-08-29 19:11 ` Kevin Hilman @ 2013-08-29 20:09 ` Vaibhav Bedia -1 siblings, 0 replies; 84+ messages in thread From: Vaibhav Bedia @ 2013-08-29 20:09 UTC (permalink / raw) To: Kevin Hilman Cc: Russ Dill, devicetree, linux-omap, Mark Brown, Jan Lübbe, Linux ARM Kernel List On Thu, Aug 29, 2013 at 3:11 PM, Kevin Hilman <khilman@linaro.org> wrote: [...] First of all, apologies for jumping in here. Now that i am not actively involved in AM335x/AM437x stuff i wasn't actively following all the discussion here. Looking at the lists now i just wanted to mention a few things so that we can agree on the approach to be taken here. >>>>> >>>>> So, why/how was the decision made to use the M3 instead of the MPU >>>>> running from SRAM? >>>>> >>>>> As a firmware minimalist, I obviously prefer to do this from the MPU >>>>> side. But also, because the M3 is reset every suspend sequence, this >>>>> becomes rather heavy to do from the M3. >>>> >>>> After the feedback Vaibhav Bedia received on v2 of his suspend/resume >>>> patchset for am335x, he decided to move many of the operations from >>>> sleep33xx.S into the M3 firmware. >>>> >>>> See the commit message here: >>>> http://arago-project.org/git/projects/?p=am33x-cm3.git;a=commit;h=a972ce2f6 >>> >>> Was this feedback on the public lists? That patch has never been posted >>> to linux-omap AFAICT. >>> >>>> I need to wait until after the PLLs are put into bypass, which is now >>>> done in the M3 firmware. It also ends up being a lot easier to write >>>> the I2C writer code there in C rather than in assembly in sleep33xx.S. >>> >>> hmm, (carefully) written functions in C can still be copied to SRAM. I >>> dont' see that as an obstacle. >>> >>>>> Currently voltage scaling is only being proposed for suspend in this >>>>> series, but in theory it's possible from idle as well. Doing this from >>>>> the MPU/SRAM seems much better suited for idle. >>>> >>>> The M3 firmware will also handle any cpuidle modes deeper than just >>>> putting SDRAM into self refresh. This is actually the only way of >>>> doing things like turning the MPU domain off on am335x. >>> >>> Yes, it will have to handle the MPU/interconnect off parts but other >>> than that, that's the only thing it *has* to do (well, and handle wakeup >>> from the deep state.) The rest of the stuff being piled into the M3 is >>> a result of software/firmware design decisions AFAICT. As I predicted >>> when I first saw this SoC design, the firmware is getting bigger and >>> bigger. Initially it was argued that it would be tiny, and only handle >>> the things it had to do. Now it's growing due to "convenience". IMO, >>> this is a bad trend, and one that will make this code more and more >>> difficult to maintain upstream (assuming that's a goal.) >> >> Do you mean upstream as in the firmware upstream, or upstream as in >> the kernel upstream? Upstream kernel is really easy to maintain >> because sleep33xx.S just puts the SDRAM into self-refresh. > > I mean making the kernel "simple" at the price of more complicated (and > much less reviewed) firmware code is a bad trend. I understand the > desire to move this stuff into firmware and bypass the kernel review > process, but I predict it will backfire. > >> The code to perform these transitions is going to exist, either in >> kernel or in firmware. If you are looking for this to be maintainable >> C code that is copied into SRAM, it will need to be built much like a >> firmware, with it's elf sections being copied into SRAM properly. > > You're making it too complicated. No need for ELF, etc. > > So the argument for moving much of the stuff from the kernel (in the > patch you referenced above) was that the "assembly code is quite big and > folks have found it hard to review and fixup issues in this dense piece > of code." (interestingly, it was moved to firmware where it will see > even less review, but that's off topic.) > > My idea was that if reviewing assembly is the issue, why not carefully > write a self-contained C function that can be copied to SRAM. It might > need a little stub in SRAM to setup the stack etc., but it should be > quite doable. That eliminates the problem cited as the reason for the > move to M3. > >> I'm not sure how much it complicates things, but the code needs to be >> able to run with the MMU on and MMU off. The C code would be a >> minimalized duplication of much of what is already in >> mach-omap2. Because you are proposing to split this up between A8 and >> M3, much of that code would then be duplicated again within the M3 >> firmware. >> >> And don't forget that am335x is just the first platform with such a PM scheme. > > IMO, all the more reason to handle it in Linux, not in platform-specific firmware. > >> Because the M3 firmware already has to manage power domains, hwmods, >> plls, and clockdomains, adding or removing which ones it handles >> doesn't really change the size or complexity of the firmware. > > No, but it significantly complicates its interaction with Linux, which > also has to know about all these things already. IMO, as I've stated > from the very beginning of this SoC, there should be a very clean split. > M3 should only handle the minimum, what the MPU simply cannot do > (MPU/interconnect off, wakeup). MPU/Linux should handle the rest. > >> In fact, because so much of the code is common code, moving this into >> kernel would just mean making two copies of the firmware with >> different steps to be run, one for the A8 SRAM, one for the M3. > > Maybe I'm getting confused, but the more you talk about the linux and > the firmware doing the same code, the more I think the firmware is > (trying) to do too much. If this is going to be understandable (and > maintainable), there needs to be a clean split of roles between the MPU > and the M3. > In the past i tried to keep the firmware as minimal as possible and pushed back all efforts to push unnecessary stuff in there. Like Kevin, i too was of the opinion that we need to do whatever's possible in the kernel. Sadly, things just got a point where it made much more sense (technically as well as non-technically) to just put the low level stuff in the M3. 1. In addition to the Linux support, we have non-OS based code for AM335x (and AM437x) which in the past just had to duplicate whatever was done in the Linux. Being a different codebase the non-OS guys have their own set of challenges and we had to at times sit through and debug issues in one codebase while the other was working fine. Ideally these things should never come up but sadly they do and we need to solve them. We also have people trying to implement this thing on different sort of OS environments and they also end up debugging the same set of issues. With only a handful of folks able to spend time debugging issues 'do everything in Linux and expect others to copy it' model doesn't scale up. Keeping things in the firmware with the code available online helps do away with the 'developer scalability' problem and if one looks at things differently enables code-reuse at the same time. Moreover, when the code was finally moved to M3, AFAICT we had validated all supported combinations (DDR2, DDR3, DDR3 with VTT, DDR3 without VTT control) that TI hardware guys could throw at us.Yes there could be stupid bugs lurking in the code since it wasn't reviewed as much as i would have liked but we have something which proves the functionality to be used as the base. 2. As has been already been pointed out by Russ, on AM335x this step needs to be done very late in the suspend process (the last stage actually). On the next SoC there are other complications related to security which enforce this step must be done from the M3. So trying to keep it in M3 for both AM335x and AM437x helps avoid the code churn that will happen if we were to do this differently on two SoCs which have similar PM architectures. Morevoer, all the suggestions on how to keep the code in Linux working around the complications due to the main memory not being accessible will need to be replicated on the non-Linux s/w stacks and that's just make it more difficult for them. 3. Moving this to M3 leaves the option open to try out some crazy stuff for power optimizations wherein the CORE voltage is lowered even below OPP50. This is yet to be proved in h/w so one can ignore this for now but yes it's a possibility. Regards, Vaibhav [1] http://www.ti.com/tool/starterware-sitara ^ permalink raw reply [flat|nested] 84+ messages in thread
* [PATCH v4 0/4] ARM: OMAP2+: AM33XX: VDD CORE OPP50 support @ 2013-08-29 20:09 ` Vaibhav Bedia 0 siblings, 0 replies; 84+ messages in thread From: Vaibhav Bedia @ 2013-08-29 20:09 UTC (permalink / raw) To: linux-arm-kernel On Thu, Aug 29, 2013 at 3:11 PM, Kevin Hilman <khilman@linaro.org> wrote: [...] First of all, apologies for jumping in here. Now that i am not actively involved in AM335x/AM437x stuff i wasn't actively following all the discussion here. Looking at the lists now i just wanted to mention a few things so that we can agree on the approach to be taken here. >>>>> >>>>> So, why/how was the decision made to use the M3 instead of the MPU >>>>> running from SRAM? >>>>> >>>>> As a firmware minimalist, I obviously prefer to do this from the MPU >>>>> side. But also, because the M3 is reset every suspend sequence, this >>>>> becomes rather heavy to do from the M3. >>>> >>>> After the feedback Vaibhav Bedia received on v2 of his suspend/resume >>>> patchset for am335x, he decided to move many of the operations from >>>> sleep33xx.S into the M3 firmware. >>>> >>>> See the commit message here: >>>> http://arago-project.org/git/projects/?p=am33x-cm3.git;a=commit;h=a972ce2f6 >>> >>> Was this feedback on the public lists? That patch has never been posted >>> to linux-omap AFAICT. >>> >>>> I need to wait until after the PLLs are put into bypass, which is now >>>> done in the M3 firmware. It also ends up being a lot easier to write >>>> the I2C writer code there in C rather than in assembly in sleep33xx.S. >>> >>> hmm, (carefully) written functions in C can still be copied to SRAM. I >>> dont' see that as an obstacle. >>> >>>>> Currently voltage scaling is only being proposed for suspend in this >>>>> series, but in theory it's possible from idle as well. Doing this from >>>>> the MPU/SRAM seems much better suited for idle. >>>> >>>> The M3 firmware will also handle any cpuidle modes deeper than just >>>> putting SDRAM into self refresh. This is actually the only way of >>>> doing things like turning the MPU domain off on am335x. >>> >>> Yes, it will have to handle the MPU/interconnect off parts but other >>> than that, that's the only thing it *has* to do (well, and handle wakeup >>> from the deep state.) The rest of the stuff being piled into the M3 is >>> a result of software/firmware design decisions AFAICT. As I predicted >>> when I first saw this SoC design, the firmware is getting bigger and >>> bigger. Initially it was argued that it would be tiny, and only handle >>> the things it had to do. Now it's growing due to "convenience". IMO, >>> this is a bad trend, and one that will make this code more and more >>> difficult to maintain upstream (assuming that's a goal.) >> >> Do you mean upstream as in the firmware upstream, or upstream as in >> the kernel upstream? Upstream kernel is really easy to maintain >> because sleep33xx.S just puts the SDRAM into self-refresh. > > I mean making the kernel "simple" at the price of more complicated (and > much less reviewed) firmware code is a bad trend. I understand the > desire to move this stuff into firmware and bypass the kernel review > process, but I predict it will backfire. > >> The code to perform these transitions is going to exist, either in >> kernel or in firmware. If you are looking for this to be maintainable >> C code that is copied into SRAM, it will need to be built much like a >> firmware, with it's elf sections being copied into SRAM properly. > > You're making it too complicated. No need for ELF, etc. > > So the argument for moving much of the stuff from the kernel (in the > patch you referenced above) was that the "assembly code is quite big and > folks have found it hard to review and fixup issues in this dense piece > of code." (interestingly, it was moved to firmware where it will see > even less review, but that's off topic.) > > My idea was that if reviewing assembly is the issue, why not carefully > write a self-contained C function that can be copied to SRAM. It might > need a little stub in SRAM to setup the stack etc., but it should be > quite doable. That eliminates the problem cited as the reason for the > move to M3. > >> I'm not sure how much it complicates things, but the code needs to be >> able to run with the MMU on and MMU off. The C code would be a >> minimalized duplication of much of what is already in >> mach-omap2. Because you are proposing to split this up between A8 and >> M3, much of that code would then be duplicated again within the M3 >> firmware. >> >> And don't forget that am335x is just the first platform with such a PM scheme. > > IMO, all the more reason to handle it in Linux, not in platform-specific firmware. > >> Because the M3 firmware already has to manage power domains, hwmods, >> plls, and clockdomains, adding or removing which ones it handles >> doesn't really change the size or complexity of the firmware. > > No, but it significantly complicates its interaction with Linux, which > also has to know about all these things already. IMO, as I've stated > from the very beginning of this SoC, there should be a very clean split. > M3 should only handle the minimum, what the MPU simply cannot do > (MPU/interconnect off, wakeup). MPU/Linux should handle the rest. > >> In fact, because so much of the code is common code, moving this into >> kernel would just mean making two copies of the firmware with >> different steps to be run, one for the A8 SRAM, one for the M3. > > Maybe I'm getting confused, but the more you talk about the linux and > the firmware doing the same code, the more I think the firmware is > (trying) to do too much. If this is going to be understandable (and > maintainable), there needs to be a clean split of roles between the MPU > and the M3. > In the past i tried to keep the firmware as minimal as possible and pushed back all efforts to push unnecessary stuff in there. Like Kevin, i too was of the opinion that we need to do whatever's possible in the kernel. Sadly, things just got a point where it made much more sense (technically as well as non-technically) to just put the low level stuff in the M3. 1. In addition to the Linux support, we have non-OS based code for AM335x (and AM437x) which in the past just had to duplicate whatever was done in the Linux. Being a different codebase the non-OS guys have their own set of challenges and we had to at times sit through and debug issues in one codebase while the other was working fine. Ideally these things should never come up but sadly they do and we need to solve them. We also have people trying to implement this thing on different sort of OS environments and they also end up debugging the same set of issues. With only a handful of folks able to spend time debugging issues 'do everything in Linux and expect others to copy it' model doesn't scale up. Keeping things in the firmware with the code available online helps do away with the 'developer scalability' problem and if one looks at things differently enables code-reuse at the same time. Moreover, when the code was finally moved to M3, AFAICT we had validated all supported combinations (DDR2, DDR3, DDR3 with VTT, DDR3 without VTT control) that TI hardware guys could throw at us.Yes there could be stupid bugs lurking in the code since it wasn't reviewed as much as i would have liked but we have something which proves the functionality to be used as the base. 2. As has been already been pointed out by Russ, on AM335x this step needs to be done very late in the suspend process (the last stage actually). On the next SoC there are other complications related to security which enforce this step must be done from the M3. So trying to keep it in M3 for both AM335x and AM437x helps avoid the code churn that will happen if we were to do this differently on two SoCs which have similar PM architectures. Morevoer, all the suggestions on how to keep the code in Linux working around the complications due to the main memory not being accessible will need to be replicated on the non-Linux s/w stacks and that's just make it more difficult for them. 3. Moving this to M3 leaves the option open to try out some crazy stuff for power optimizations wherein the CORE voltage is lowered even below OPP50. This is yet to be proved in h/w so one can ignore this for now but yes it's a possibility. Regards, Vaibhav [1] http://www.ti.com/tool/starterware-sitara ^ permalink raw reply [flat|nested] 84+ messages in thread
* Re: [PATCH v4 0/4] ARM: OMAP2+: AM33XX: VDD CORE OPP50 support 2013-08-29 20:09 ` Vaibhav Bedia @ 2013-08-29 21:33 ` Kevin Hilman -1 siblings, 0 replies; 84+ messages in thread From: Kevin Hilman @ 2013-08-29 21:33 UTC (permalink / raw) To: Vaibhav Bedia Cc: Russ Dill, devicetree, linux-omap, Mark Brown, Jan Lübbe, Linux ARM Kernel List Vaibhav Bedia <vaibhav.bedia@gmail.com> writes: > On Thu, Aug 29, 2013 at 3:11 PM, Kevin Hilman <khilman@linaro.org> wrote: > [...] > > First of all, apologies for jumping in here. Now that i am not > actively involved in AM335x/AM437x stuff i wasn't actively following > all the discussion here. No apologies needed, I was hoping you would jump in here. Thanks for sharing your experience and insight. > Looking at the lists now i just wanted to mention a few things so that we can > agree on the approach to be taken here. > >>>>>> >>>>>> So, why/how was the decision made to use the M3 instead of the MPU >>>>>> running from SRAM? >>>>>> >>>>>> As a firmware minimalist, I obviously prefer to do this from the MPU >>>>>> side. But also, because the M3 is reset every suspend sequence, this >>>>>> becomes rather heavy to do from the M3. >>>>> >>>>> After the feedback Vaibhav Bedia received on v2 of his suspend/resume >>>>> patchset for am335x, he decided to move many of the operations from >>>>> sleep33xx.S into the M3 firmware. >>>>> >>>>> See the commit message here: >>>>> http://arago-project.org/git/projects/?p=am33x-cm3.git;a=commit;h=a972ce2f6 >>>> >>>> Was this feedback on the public lists? That patch has never been posted >>>> to linux-omap AFAICT. >>>> >>>>> I need to wait until after the PLLs are put into bypass, which is now >>>>> done in the M3 firmware. It also ends up being a lot easier to write >>>>> the I2C writer code there in C rather than in assembly in sleep33xx.S. >>>> >>>> hmm, (carefully) written functions in C can still be copied to SRAM. I >>>> dont' see that as an obstacle. >>>> >>>>>> Currently voltage scaling is only being proposed for suspend in this >>>>>> series, but in theory it's possible from idle as well. Doing this from >>>>>> the MPU/SRAM seems much better suited for idle. >>>>> >>>>> The M3 firmware will also handle any cpuidle modes deeper than just >>>>> putting SDRAM into self refresh. This is actually the only way of >>>>> doing things like turning the MPU domain off on am335x. >>>> >>>> Yes, it will have to handle the MPU/interconnect off parts but other >>>> than that, that's the only thing it *has* to do (well, and handle wakeup >>>> from the deep state.) The rest of the stuff being piled into the M3 is >>>> a result of software/firmware design decisions AFAICT. As I predicted >>>> when I first saw this SoC design, the firmware is getting bigger and >>>> bigger. Initially it was argued that it would be tiny, and only handle >>>> the things it had to do. Now it's growing due to "convenience". IMO, >>>> this is a bad trend, and one that will make this code more and more >>>> difficult to maintain upstream (assuming that's a goal.) >>> >>> Do you mean upstream as in the firmware upstream, or upstream as in >>> the kernel upstream? Upstream kernel is really easy to maintain >>> because sleep33xx.S just puts the SDRAM into self-refresh. >> >> I mean making the kernel "simple" at the price of more complicated (and >> much less reviewed) firmware code is a bad trend. I understand the >> desire to move this stuff into firmware and bypass the kernel review >> process, but I predict it will backfire. >> >>> The code to perform these transitions is going to exist, either in >>> kernel or in firmware. If you are looking for this to be maintainable >>> C code that is copied into SRAM, it will need to be built much like a >>> firmware, with it's elf sections being copied into SRAM properly. >> >> You're making it too complicated. No need for ELF, etc. >> >> So the argument for moving much of the stuff from the kernel (in the >> patch you referenced above) was that the "assembly code is quite big and >> folks have found it hard to review and fixup issues in this dense piece >> of code." (interestingly, it was moved to firmware where it will see >> even less review, but that's off topic.) >> >> My idea was that if reviewing assembly is the issue, why not carefully >> write a self-contained C function that can be copied to SRAM. It might >> need a little stub in SRAM to setup the stack etc., but it should be >> quite doable. That eliminates the problem cited as the reason for the >> move to M3. >> >>> I'm not sure how much it complicates things, but the code needs to be >>> able to run with the MMU on and MMU off. The C code would be a >>> minimalized duplication of much of what is already in >>> mach-omap2. Because you are proposing to split this up between A8 and >>> M3, much of that code would then be duplicated again within the M3 >>> firmware. >>> >>> And don't forget that am335x is just the first platform with such a PM scheme. >> >> IMO, all the more reason to handle it in Linux, not in platform-specific firmware. >> >>> Because the M3 firmware already has to manage power domains, hwmods, >>> plls, and clockdomains, adding or removing which ones it handles >>> doesn't really change the size or complexity of the firmware. >> >> No, but it significantly complicates its interaction with Linux, which >> also has to know about all these things already. IMO, as I've stated >> from the very beginning of this SoC, there should be a very clean split. >> M3 should only handle the minimum, what the MPU simply cannot do >> (MPU/interconnect off, wakeup). MPU/Linux should handle the rest. >> >>> In fact, because so much of the code is common code, moving this into >>> kernel would just mean making two copies of the firmware with >>> different steps to be run, one for the A8 SRAM, one for the M3. >> >> Maybe I'm getting confused, but the more you talk about the linux and >> the firmware doing the same code, the more I think the firmware is >> (trying) to do too much. If this is going to be understandable (and >> maintainable), there needs to be a clean split of roles between the MPU >> and the M3. >> > > In the past i tried to keep the firmware as minimal as possible and pushed > back all efforts to push unnecessary stuff in there. Like Kevin, i too was of > the opinion that we need to do whatever's possible in the kernel. > > Sadly, things just got a point where it made much more sense (technically > as well as non-technically) to just put the low level stuff in the M3. > > 1. In addition to the Linux support, we have non-OS based code for AM335x > (and AM437x) which in the past just had to duplicate whatever was done > in the Linux. Being a different codebase the non-OS guys have their own > set of challenges and we had to at times sit through and debug issues in > one codebase while the other was working fine. Ideally these things should > never come up but sadly they do and we need to solve them. > > We also have people trying to implement this thing on different sort of > OS environments and they also end up debugging the same set of issues. > > With only a handful of folks able to spend time debugging issues 'do everything > in Linux and expect others to copy it' model doesn't scale up. Keeping > things in the > firmware with the code available online helps do away with the > 'developer scalability' > problem and if one looks at things differently enables code-reuse at > the same time. Yes, yes, this is the classic argument for a HAL, and making that case has always gone over well in the kernel. ;) > Moreover, when the code was finally moved to M3, AFAICT we had validated > all supported combinations (DDR2, DDR3, DDR3 with VTT, DDR3 without VTT > control) that TI hardware guys could throw at us.Yes there could be stupid bugs > lurking in the code since it wasn't reviewed as much as i would have > liked but we > have something which proves the functionality to be used as the base. I don't follow the argument here. You mean it was validated *before* moving it to the M3, or after? Either way, I'm how that makes a case for moving it to the M3. Surely if it was on the MPU, it would also have been validated, no? > 2. As has been already been pointed out by Russ, on AM335x this step needs > to be done very late in the suspend process (the last stage > actually). late, yes. But *technically*, it can still be done from the MPU. > On the next SoC there are other complications related to security > which enforce this step must be done from the M3. Aha! So far, the first technical reason I've seen. Can you elaborate? Exactly which step has to be done from the M3, and why can't the MPU do it? And could it be done more simply by putting *only* the parts needed on the M3 and not letting it snowball into a pile of stuff? > So trying to keep it in M3 for both AM335x and AM437x helps avoid the > code churn that will happen if we were to do this differently on two > SoCs which have similar PM architectures. I'm not conviced it has to be done so differently between the two. Let's have some more details about the security differences before making that decision. > Morevoer, all the suggestions on how to keep the code in Linux working > around the complications due to the main memory not being accessible > will need to be replicated on the non-Linux s/w stacks and that's just > make it more difficult for them. The linux code has to be very self-contained (in assembler or C), so I'm not sure how it's difficult to replicated in any other OS (or non-OS.) > 3. Moving this to M3 leaves the option open to try out some crazy stuff for > power optimizations wherein the CORE voltage is lowered even below OPP50. > This is yet to be proved in h/w so one can ignore this for now but yes it's a > possibility. All interesting reasons, but other than the security one, all boil down to non-technical arguments about what's easier. But as you well know, "the easy way" usually isn't the same thing as "the right way" when it comes to getting things into the upstream linux kernel. Kevin ^ permalink raw reply [flat|nested] 84+ messages in thread
* [PATCH v4 0/4] ARM: OMAP2+: AM33XX: VDD CORE OPP50 support @ 2013-08-29 21:33 ` Kevin Hilman 0 siblings, 0 replies; 84+ messages in thread From: Kevin Hilman @ 2013-08-29 21:33 UTC (permalink / raw) To: linux-arm-kernel Vaibhav Bedia <vaibhav.bedia@gmail.com> writes: > On Thu, Aug 29, 2013 at 3:11 PM, Kevin Hilman <khilman@linaro.org> wrote: > [...] > > First of all, apologies for jumping in here. Now that i am not > actively involved in AM335x/AM437x stuff i wasn't actively following > all the discussion here. No apologies needed, I was hoping you would jump in here. Thanks for sharing your experience and insight. > Looking at the lists now i just wanted to mention a few things so that we can > agree on the approach to be taken here. > >>>>>> >>>>>> So, why/how was the decision made to use the M3 instead of the MPU >>>>>> running from SRAM? >>>>>> >>>>>> As a firmware minimalist, I obviously prefer to do this from the MPU >>>>>> side. But also, because the M3 is reset every suspend sequence, this >>>>>> becomes rather heavy to do from the M3. >>>>> >>>>> After the feedback Vaibhav Bedia received on v2 of his suspend/resume >>>>> patchset for am335x, he decided to move many of the operations from >>>>> sleep33xx.S into the M3 firmware. >>>>> >>>>> See the commit message here: >>>>> http://arago-project.org/git/projects/?p=am33x-cm3.git;a=commit;h=a972ce2f6 >>>> >>>> Was this feedback on the public lists? That patch has never been posted >>>> to linux-omap AFAICT. >>>> >>>>> I need to wait until after the PLLs are put into bypass, which is now >>>>> done in the M3 firmware. It also ends up being a lot easier to write >>>>> the I2C writer code there in C rather than in assembly in sleep33xx.S. >>>> >>>> hmm, (carefully) written functions in C can still be copied to SRAM. I >>>> dont' see that as an obstacle. >>>> >>>>>> Currently voltage scaling is only being proposed for suspend in this >>>>>> series, but in theory it's possible from idle as well. Doing this from >>>>>> the MPU/SRAM seems much better suited for idle. >>>>> >>>>> The M3 firmware will also handle any cpuidle modes deeper than just >>>>> putting SDRAM into self refresh. This is actually the only way of >>>>> doing things like turning the MPU domain off on am335x. >>>> >>>> Yes, it will have to handle the MPU/interconnect off parts but other >>>> than that, that's the only thing it *has* to do (well, and handle wakeup >>>> from the deep state.) The rest of the stuff being piled into the M3 is >>>> a result of software/firmware design decisions AFAICT. As I predicted >>>> when I first saw this SoC design, the firmware is getting bigger and >>>> bigger. Initially it was argued that it would be tiny, and only handle >>>> the things it had to do. Now it's growing due to "convenience". IMO, >>>> this is a bad trend, and one that will make this code more and more >>>> difficult to maintain upstream (assuming that's a goal.) >>> >>> Do you mean upstream as in the firmware upstream, or upstream as in >>> the kernel upstream? Upstream kernel is really easy to maintain >>> because sleep33xx.S just puts the SDRAM into self-refresh. >> >> I mean making the kernel "simple" at the price of more complicated (and >> much less reviewed) firmware code is a bad trend. I understand the >> desire to move this stuff into firmware and bypass the kernel review >> process, but I predict it will backfire. >> >>> The code to perform these transitions is going to exist, either in >>> kernel or in firmware. If you are looking for this to be maintainable >>> C code that is copied into SRAM, it will need to be built much like a >>> firmware, with it's elf sections being copied into SRAM properly. >> >> You're making it too complicated. No need for ELF, etc. >> >> So the argument for moving much of the stuff from the kernel (in the >> patch you referenced above) was that the "assembly code is quite big and >> folks have found it hard to review and fixup issues in this dense piece >> of code." (interestingly, it was moved to firmware where it will see >> even less review, but that's off topic.) >> >> My idea was that if reviewing assembly is the issue, why not carefully >> write a self-contained C function that can be copied to SRAM. It might >> need a little stub in SRAM to setup the stack etc., but it should be >> quite doable. That eliminates the problem cited as the reason for the >> move to M3. >> >>> I'm not sure how much it complicates things, but the code needs to be >>> able to run with the MMU on and MMU off. The C code would be a >>> minimalized duplication of much of what is already in >>> mach-omap2. Because you are proposing to split this up between A8 and >>> M3, much of that code would then be duplicated again within the M3 >>> firmware. >>> >>> And don't forget that am335x is just the first platform with such a PM scheme. >> >> IMO, all the more reason to handle it in Linux, not in platform-specific firmware. >> >>> Because the M3 firmware already has to manage power domains, hwmods, >>> plls, and clockdomains, adding or removing which ones it handles >>> doesn't really change the size or complexity of the firmware. >> >> No, but it significantly complicates its interaction with Linux, which >> also has to know about all these things already. IMO, as I've stated >> from the very beginning of this SoC, there should be a very clean split. >> M3 should only handle the minimum, what the MPU simply cannot do >> (MPU/interconnect off, wakeup). MPU/Linux should handle the rest. >> >>> In fact, because so much of the code is common code, moving this into >>> kernel would just mean making two copies of the firmware with >>> different steps to be run, one for the A8 SRAM, one for the M3. >> >> Maybe I'm getting confused, but the more you talk about the linux and >> the firmware doing the same code, the more I think the firmware is >> (trying) to do too much. If this is going to be understandable (and >> maintainable), there needs to be a clean split of roles between the MPU >> and the M3. >> > > In the past i tried to keep the firmware as minimal as possible and pushed > back all efforts to push unnecessary stuff in there. Like Kevin, i too was of > the opinion that we need to do whatever's possible in the kernel. > > Sadly, things just got a point where it made much more sense (technically > as well as non-technically) to just put the low level stuff in the M3. > > 1. In addition to the Linux support, we have non-OS based code for AM335x > (and AM437x) which in the past just had to duplicate whatever was done > in the Linux. Being a different codebase the non-OS guys have their own > set of challenges and we had to at times sit through and debug issues in > one codebase while the other was working fine. Ideally these things should > never come up but sadly they do and we need to solve them. > > We also have people trying to implement this thing on different sort of > OS environments and they also end up debugging the same set of issues. > > With only a handful of folks able to spend time debugging issues 'do everything > in Linux and expect others to copy it' model doesn't scale up. Keeping > things in the > firmware with the code available online helps do away with the > 'developer scalability' > problem and if one looks at things differently enables code-reuse at > the same time. Yes, yes, this is the classic argument for a HAL, and making that case has always gone over well in the kernel. ;) > Moreover, when the code was finally moved to M3, AFAICT we had validated > all supported combinations (DDR2, DDR3, DDR3 with VTT, DDR3 without VTT > control) that TI hardware guys could throw at us.Yes there could be stupid bugs > lurking in the code since it wasn't reviewed as much as i would have > liked but we > have something which proves the functionality to be used as the base. I don't follow the argument here. You mean it was validated *before* moving it to the M3, or after? Either way, I'm how that makes a case for moving it to the M3. Surely if it was on the MPU, it would also have been validated, no? > 2. As has been already been pointed out by Russ, on AM335x this step needs > to be done very late in the suspend process (the last stage > actually). late, yes. But *technically*, it can still be done from the MPU. > On the next SoC there are other complications related to security > which enforce this step must be done from the M3. Aha! So far, the first technical reason I've seen. Can you elaborate? Exactly which step has to be done from the M3, and why can't the MPU do it? And could it be done more simply by putting *only* the parts needed on the M3 and not letting it snowball into a pile of stuff? > So trying to keep it in M3 for both AM335x and AM437x helps avoid the > code churn that will happen if we were to do this differently on two > SoCs which have similar PM architectures. I'm not conviced it has to be done so differently between the two. Let's have some more details about the security differences before making that decision. > Morevoer, all the suggestions on how to keep the code in Linux working > around the complications due to the main memory not being accessible > will need to be replicated on the non-Linux s/w stacks and that's just > make it more difficult for them. The linux code has to be very self-contained (in assembler or C), so I'm not sure how it's difficult to replicated in any other OS (or non-OS.) > 3. Moving this to M3 leaves the option open to try out some crazy stuff for > power optimizations wherein the CORE voltage is lowered even below OPP50. > This is yet to be proved in h/w so one can ignore this for now but yes it's a > possibility. All interesting reasons, but other than the security one, all boil down to non-technical arguments about what's easier. But as you well know, "the easy way" usually isn't the same thing as "the right way" when it comes to getting things into the upstream linux kernel. Kevin ^ permalink raw reply [flat|nested] 84+ messages in thread
* Re: [PATCH v4 0/4] ARM: OMAP2+: AM33XX: VDD CORE OPP50 support 2013-08-29 21:33 ` Kevin Hilman @ 2013-08-30 0:25 ` Russ Dill -1 siblings, 0 replies; 84+ messages in thread From: Russ Dill @ 2013-08-30 0:25 UTC (permalink / raw) To: Kevin Hilman Cc: Vaibhav Bedia, devicetree, Jan Lübbe, Mark Brown, linux-omap, Linux ARM Kernel List On Thu, Aug 29, 2013 at 2:33 PM, Kevin Hilman <khilman@linaro.org> wrote: > Vaibhav Bedia <vaibhav.bedia@gmail.com> writes: [snip] >> Morevoer, all the suggestions on how to keep the code in Linux working >> around the complications due to the main memory not being accessible >> will need to be replicated on the non-Linux s/w stacks and that's just >> make it more difficult for them. > > The linux code has to be very self-contained (in assembler or C), so I'm > not sure how it's difficult to replicated in any other OS (or non-OS.) Let me pull on this thread a little bit. Would this involve defining a bunch of different sections for each arch so that I could do: void __sram_am33xx am33xx_some_pm_function(args....) { } static struct am33xx_foo_dyn *blargity __sramdata_am33xx = { ...}; static const struct am33xx_foo_const *blarg __sramconst_am33xx = { ... }; The sram push code could then push these sections into sram. There would then be a set of inlines or macros for converting addresses within these sections to SRAM addresses, maybe also inlines or macros for calling code that has been pushed into sram by wrapping the original function pointer. The macros or inlines that call SRAM code could perform the trampoline as well. Would there be much general interest in a scheme like this? Is there already I scheme like this I haven't noticed. Would such an explosion of sections be a problem if all platforms started using this for SRAM code? ^ permalink raw reply [flat|nested] 84+ messages in thread
* [PATCH v4 0/4] ARM: OMAP2+: AM33XX: VDD CORE OPP50 support @ 2013-08-30 0:25 ` Russ Dill 0 siblings, 0 replies; 84+ messages in thread From: Russ Dill @ 2013-08-30 0:25 UTC (permalink / raw) To: linux-arm-kernel On Thu, Aug 29, 2013 at 2:33 PM, Kevin Hilman <khilman@linaro.org> wrote: > Vaibhav Bedia <vaibhav.bedia@gmail.com> writes: [snip] >> Morevoer, all the suggestions on how to keep the code in Linux working >> around the complications due to the main memory not being accessible >> will need to be replicated on the non-Linux s/w stacks and that's just >> make it more difficult for them. > > The linux code has to be very self-contained (in assembler or C), so I'm > not sure how it's difficult to replicated in any other OS (or non-OS.) Let me pull on this thread a little bit. Would this involve defining a bunch of different sections for each arch so that I could do: void __sram_am33xx am33xx_some_pm_function(args....) { } static struct am33xx_foo_dyn *blargity __sramdata_am33xx = { ...}; static const struct am33xx_foo_const *blarg __sramconst_am33xx = { ... }; The sram push code could then push these sections into sram. There would then be a set of inlines or macros for converting addresses within these sections to SRAM addresses, maybe also inlines or macros for calling code that has been pushed into sram by wrapping the original function pointer. The macros or inlines that call SRAM code could perform the trampoline as well. Would there be much general interest in a scheme like this? Is there already I scheme like this I haven't noticed. Would such an explosion of sections be a problem if all platforms started using this for SRAM code? ^ permalink raw reply [flat|nested] 84+ messages in thread
* Re: [PATCH v4 0/4] ARM: OMAP2+: AM33XX: VDD CORE OPP50 support 2013-08-30 0:25 ` Russ Dill @ 2013-08-30 16:06 ` Kevin Hilman -1 siblings, 0 replies; 84+ messages in thread From: Kevin Hilman @ 2013-08-30 16:06 UTC (permalink / raw) To: Russ Dill Cc: Vaibhav Bedia, devicetree, Jan Lübbe, Mark Brown, linux-omap, Linux ARM Kernel List Russ Dill <Russ.Dill@ti.com> writes: > On Thu, Aug 29, 2013 at 2:33 PM, Kevin Hilman <khilman@linaro.org> wrote: >> Vaibhav Bedia <vaibhav.bedia@gmail.com> writes: > [snip] >>> Morevoer, all the suggestions on how to keep the code in Linux working >>> around the complications due to the main memory not being accessible >>> will need to be replicated on the non-Linux s/w stacks and that's just >>> make it more difficult for them. >> >> The linux code has to be very self-contained (in assembler or C), so I'm >> not sure how it's difficult to replicated in any other OS (or non-OS.) > > Let me pull on this thread a little bit. Would this involve defining a > bunch of different sections for each arch so that I could do: > > void __sram_am33xx am33xx_some_pm_function(args....) > { > } > > static struct am33xx_foo_dyn *blargity __sramdata_am33xx = { ...}; > > static const struct am33xx_foo_const *blarg __sramconst_am33xx = { ... }; > > The sram push code could then push these sections into sram. There > would then be a set of inlines or macros for converting addresses > within these sections to SRAM addresses, maybe also inlines or macros > for calling code that has been pushed into sram by wrapping the > original function pointer. The macros or inlines that call SRAM code > could perform the trampoline as well. Well, I was thinking of something much dumber. I was thinking about just _carefully_ writing a single, self-contained C function, with all of its data on the stack (and consts as #defines). Think of it is a step up in readability from straight assembly (which was the stated reason for moving the code to the M3 in the first place.) Kevin ^ permalink raw reply [flat|nested] 84+ messages in thread
* [PATCH v4 0/4] ARM: OMAP2+: AM33XX: VDD CORE OPP50 support @ 2013-08-30 16:06 ` Kevin Hilman 0 siblings, 0 replies; 84+ messages in thread From: Kevin Hilman @ 2013-08-30 16:06 UTC (permalink / raw) To: linux-arm-kernel Russ Dill <Russ.Dill@ti.com> writes: > On Thu, Aug 29, 2013 at 2:33 PM, Kevin Hilman <khilman@linaro.org> wrote: >> Vaibhav Bedia <vaibhav.bedia@gmail.com> writes: > [snip] >>> Morevoer, all the suggestions on how to keep the code in Linux working >>> around the complications due to the main memory not being accessible >>> will need to be replicated on the non-Linux s/w stacks and that's just >>> make it more difficult for them. >> >> The linux code has to be very self-contained (in assembler or C), so I'm >> not sure how it's difficult to replicated in any other OS (or non-OS.) > > Let me pull on this thread a little bit. Would this involve defining a > bunch of different sections for each arch so that I could do: > > void __sram_am33xx am33xx_some_pm_function(args....) > { > } > > static struct am33xx_foo_dyn *blargity __sramdata_am33xx = { ...}; > > static const struct am33xx_foo_const *blarg __sramconst_am33xx = { ... }; > > The sram push code could then push these sections into sram. There > would then be a set of inlines or macros for converting addresses > within these sections to SRAM addresses, maybe also inlines or macros > for calling code that has been pushed into sram by wrapping the > original function pointer. The macros or inlines that call SRAM code > could perform the trampoline as well. Well, I was thinking of something much dumber. I was thinking about just _carefully_ writing a single, self-contained C function, with all of its data on the stack (and consts as #defines). Think of it is a step up in readability from straight assembly (which was the stated reason for moving the code to the M3 in the first place.) Kevin ^ permalink raw reply [flat|nested] 84+ messages in thread
* Re: [PATCH v4 0/4] ARM: OMAP2+: AM33XX: VDD CORE OPP50 support 2013-08-30 16:06 ` Kevin Hilman @ 2013-09-03 18:55 ` Russ Dill -1 siblings, 0 replies; 84+ messages in thread From: Russ Dill @ 2013-09-03 18:55 UTC (permalink / raw) To: Kevin Hilman Cc: devicetree, Jan Lübbe, Mark Brown, Vaibhav Bedia, linux-omap, Linux ARM Kernel List On Fri, Aug 30, 2013 at 9:06 AM, Kevin Hilman <khilman@linaro.org> wrote: > Well, I was thinking of something much dumber. > > I was thinking about just _carefully_ writing a single, self-contained C > function, with all of its data on the stack (and consts as #defines). > Think of it is a step up in readability from straight assembly (which > was the stated reason for moving the code to the M3 in the first place.) > > Kevin That can only give you your suspend function. You need a resume function to undo everything before calling cpu_resume, and the resume function needs access to the data that was in the suspend function. ^ permalink raw reply [flat|nested] 84+ messages in thread
* [PATCH v4 0/4] ARM: OMAP2+: AM33XX: VDD CORE OPP50 support @ 2013-09-03 18:55 ` Russ Dill 0 siblings, 0 replies; 84+ messages in thread From: Russ Dill @ 2013-09-03 18:55 UTC (permalink / raw) To: linux-arm-kernel On Fri, Aug 30, 2013 at 9:06 AM, Kevin Hilman <khilman@linaro.org> wrote: > Well, I was thinking of something much dumber. > > I was thinking about just _carefully_ writing a single, self-contained C > function, with all of its data on the stack (and consts as #defines). > Think of it is a step up in readability from straight assembly (which > was the stated reason for moving the code to the M3 in the first place.) > > Kevin That can only give you your suspend function. You need a resume function to undo everything before calling cpu_resume, and the resume function needs access to the data that was in the suspend function. ^ permalink raw reply [flat|nested] 84+ messages in thread
* Re: [PATCH v4 0/4] ARM: OMAP2+: AM33XX: VDD CORE OPP50 support 2013-09-03 18:55 ` Russ Dill @ 2013-09-03 19:07 ` Kevin Hilman -1 siblings, 0 replies; 84+ messages in thread From: Kevin Hilman @ 2013-09-03 19:07 UTC (permalink / raw) To: Russ Dill Cc: devicetree, Jan Lübbe, Mark Brown, Vaibhav Bedia, linux-omap, Linux ARM Kernel List On Tue, Sep 3, 2013 at 11:55 AM, Russ Dill <Russ.Dill@ti.com> wrote: > On Fri, Aug 30, 2013 at 9:06 AM, Kevin Hilman <khilman@linaro.org> wrote: >> Well, I was thinking of something much dumber. >> >> I was thinking about just _carefully_ writing a single, self-contained C >> function, with all of its data on the stack (and consts as #defines). >> Think of it is a step up in readability from straight assembly (which >> was the stated reason for moving the code to the M3 in the first place.) >> >> Kevin > > That can only give you your suspend function. You need a resume > function to undo everything before calling cpu_resume, and the resume > function needs access to the data that was in the suspend function. Well, it can be done (and I've seen it done) with various hacks, but I agree it's not pretty, but it is at least slightly prettier than piles of asm. That being said, I saw you posted a more generic solution that looks like a real solution that can scale. I'll have a closer look at that. Thanks for working on it. Kevin ^ permalink raw reply [flat|nested] 84+ messages in thread
* [PATCH v4 0/4] ARM: OMAP2+: AM33XX: VDD CORE OPP50 support @ 2013-09-03 19:07 ` Kevin Hilman 0 siblings, 0 replies; 84+ messages in thread From: Kevin Hilman @ 2013-09-03 19:07 UTC (permalink / raw) To: linux-arm-kernel On Tue, Sep 3, 2013 at 11:55 AM, Russ Dill <Russ.Dill@ti.com> wrote: > On Fri, Aug 30, 2013 at 9:06 AM, Kevin Hilman <khilman@linaro.org> wrote: >> Well, I was thinking of something much dumber. >> >> I was thinking about just _carefully_ writing a single, self-contained C >> function, with all of its data on the stack (and consts as #defines). >> Think of it is a step up in readability from straight assembly (which >> was the stated reason for moving the code to the M3 in the first place.) >> >> Kevin > > That can only give you your suspend function. You need a resume > function to undo everything before calling cpu_resume, and the resume > function needs access to the data that was in the suspend function. Well, it can be done (and I've seen it done) with various hacks, but I agree it's not pretty, but it is at least slightly prettier than piles of asm. That being said, I saw you posted a more generic solution that looks like a real solution that can scale. I'll have a closer look at that. Thanks for working on it. Kevin ^ permalink raw reply [flat|nested] 84+ messages in thread
* Re: [PATCH v4 0/4] ARM: OMAP2+: AM33XX: VDD CORE OPP50 support 2013-08-29 21:33 ` Kevin Hilman @ 2013-08-30 17:57 ` Vaibhav Bedia -1 siblings, 0 replies; 84+ messages in thread From: Vaibhav Bedia @ 2013-08-30 17:57 UTC (permalink / raw) To: Kevin Hilman Cc: Russ Dill, devicetree, linux-omap, Mark Brown, Jan Lübbe, Linux ARM Kernel List On Thu, Aug 29, 2013 at 5:33 PM, Kevin Hilman <khilman@linaro.org> wrote: [...] >>> >>> Maybe I'm getting confused, but the more you talk about the linux and >>> the firmware doing the same code, the more I think the firmware is >>> (trying) to do too much. If this is going to be understandable (and >>> maintainable), there needs to be a clean split of roles between the MPU >>> and the M3. >>> >> >> In the past i tried to keep the firmware as minimal as possible and pushed >> back all efforts to push unnecessary stuff in there. Like Kevin, i too was of >> the opinion that we need to do whatever's possible in the kernel. >> >> Sadly, things just got a point where it made much more sense (technically >> as well as non-technically) to just put the low level stuff in the M3. >> >> 1. In addition to the Linux support, we have non-OS based code for AM335x >> (and AM437x) which in the past just had to duplicate whatever was done >> in the Linux. Being a different codebase the non-OS guys have their own >> set of challenges and we had to at times sit through and debug issues in >> one codebase while the other was working fine. Ideally these things should >> never come up but sadly they do and we need to solve them. >> >> We also have people trying to implement this thing on different sort of >> OS environments and they also end up debugging the same set of issues. >> >> With only a handful of folks able to spend time debugging issues 'do everything >> in Linux and expect others to copy it' model doesn't scale up. Keeping >> things in the >> firmware with the code available online helps do away with the >> 'developer scalability' >> problem and if one looks at things differently enables code-reuse at >> the same time. > > Yes, yes, this is the classic argument for a HAL, and making that case has always > gone over well in the kernel. ;) > If the carefully crafted C code with a bit of linker magic thrown in works, that's great but for anyone without the generic Linux code in general and the Linux community to go to with queries will have a tough time getting it done. TI non-OS code has been implemented from scratch and one of the purposes is to keep things as simple as possible for folks. I know it's all non-technical stuff and most likely i am a bit biased but just a different POV from someone who spent hours debugging 'this works and that doesn't' kind of issues. Trying to wrap your head around random s/w stacks and figuring out what needs to be changed is not pretty IMHO :\ >> Moreover, when the code was finally moved to M3, AFAICT we had validated >> all supported combinations (DDR2, DDR3, DDR3 with VTT, DDR3 without VTT >> control) that TI hardware guys could throw at us.Yes there could be stupid bugs >> lurking in the code since it wasn't reviewed as much as i would have >> liked but we >> have something which proves the functionality to be used as the base. > > I don't follow the argument here. You mean it was validated *before* > moving it to the M3, or after? Either way, I'm how that makes a case > for moving it to the M3. Surely if it was on the MPU, it would also > have been validated, no? > At least i did all the validation without the VDD_CORE changes. The point i was trying to make is that we are not trying to hide bugs in there, if that's one of the concerns. Just trying to make it simple (subjective, i know) for others to use. >> 2. As has been already been pointed out by Russ, on AM335x this step needs >> to be done very late in the suspend process (the last stage >> actually). > > late, yes. But *technically*, it can still be done from the MPU. > >> On the next SoC there are other complications related to security >> which enforce this step must be done from the M3. > > Aha! So far, the first technical reason I've seen. Can you elaborate? > Exactly which step has to be done from the M3, and why can't the MPU do > it? And could it be done more simply by putting *only* the parts needed > on the M3 and not letting it snowball into a pile of stuff? > Sent out another mail for this. Regards, Vaibhav ^ permalink raw reply [flat|nested] 84+ messages in thread
* [PATCH v4 0/4] ARM: OMAP2+: AM33XX: VDD CORE OPP50 support @ 2013-08-30 17:57 ` Vaibhav Bedia 0 siblings, 0 replies; 84+ messages in thread From: Vaibhav Bedia @ 2013-08-30 17:57 UTC (permalink / raw) To: linux-arm-kernel On Thu, Aug 29, 2013 at 5:33 PM, Kevin Hilman <khilman@linaro.org> wrote: [...] >>> >>> Maybe I'm getting confused, but the more you talk about the linux and >>> the firmware doing the same code, the more I think the firmware is >>> (trying) to do too much. If this is going to be understandable (and >>> maintainable), there needs to be a clean split of roles between the MPU >>> and the M3. >>> >> >> In the past i tried to keep the firmware as minimal as possible and pushed >> back all efforts to push unnecessary stuff in there. Like Kevin, i too was of >> the opinion that we need to do whatever's possible in the kernel. >> >> Sadly, things just got a point where it made much more sense (technically >> as well as non-technically) to just put the low level stuff in the M3. >> >> 1. In addition to the Linux support, we have non-OS based code for AM335x >> (and AM437x) which in the past just had to duplicate whatever was done >> in the Linux. Being a different codebase the non-OS guys have their own >> set of challenges and we had to at times sit through and debug issues in >> one codebase while the other was working fine. Ideally these things should >> never come up but sadly they do and we need to solve them. >> >> We also have people trying to implement this thing on different sort of >> OS environments and they also end up debugging the same set of issues. >> >> With only a handful of folks able to spend time debugging issues 'do everything >> in Linux and expect others to copy it' model doesn't scale up. Keeping >> things in the >> firmware with the code available online helps do away with the >> 'developer scalability' >> problem and if one looks at things differently enables code-reuse at >> the same time. > > Yes, yes, this is the classic argument for a HAL, and making that case has always > gone over well in the kernel. ;) > If the carefully crafted C code with a bit of linker magic thrown in works, that's great but for anyone without the generic Linux code in general and the Linux community to go to with queries will have a tough time getting it done. TI non-OS code has been implemented from scratch and one of the purposes is to keep things as simple as possible for folks. I know it's all non-technical stuff and most likely i am a bit biased but just a different POV from someone who spent hours debugging 'this works and that doesn't' kind of issues. Trying to wrap your head around random s/w stacks and figuring out what needs to be changed is not pretty IMHO :\ >> Moreover, when the code was finally moved to M3, AFAICT we had validated >> all supported combinations (DDR2, DDR3, DDR3 with VTT, DDR3 without VTT >> control) that TI hardware guys could throw at us.Yes there could be stupid bugs >> lurking in the code since it wasn't reviewed as much as i would have >> liked but we >> have something which proves the functionality to be used as the base. > > I don't follow the argument here. You mean it was validated *before* > moving it to the M3, or after? Either way, I'm how that makes a case > for moving it to the M3. Surely if it was on the MPU, it would also > have been validated, no? > At least i did all the validation without the VDD_CORE changes. The point i was trying to make is that we are not trying to hide bugs in there, if that's one of the concerns. Just trying to make it simple (subjective, i know) for others to use. >> 2. As has been already been pointed out by Russ, on AM335x this step needs >> to be done very late in the suspend process (the last stage >> actually). > > late, yes. But *technically*, it can still be done from the MPU. > >> On the next SoC there are other complications related to security >> which enforce this step must be done from the M3. > > Aha! So far, the first technical reason I've seen. Can you elaborate? > Exactly which step has to be done from the M3, and why can't the MPU do > it? And could it be done more simply by putting *only* the parts needed > on the M3 and not letting it snowball into a pile of stuff? > Sent out another mail for this. Regards, Vaibhav ^ permalink raw reply [flat|nested] 84+ messages in thread
end of thread, other threads:[~2013-09-03 19:07 UTC | newest] Thread overview: 84+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2013-08-13 22:20 [PATCH v4 0/4] ARM: OMAP2+: AM33XX: VDD CORE OPP50 support Russ Dill 2013-08-13 22:20 ` Russ Dill 2013-08-13 22:20 ` [PATCH v4 1/4] ARM: OMAP2+: AM33XX: I2C Sleep/wake sequence support Russ Dill 2013-08-13 22:20 ` Russ Dill 2013-08-14 10:18 ` Gururaja Hebbar 2013-08-14 10:18 ` Gururaja Hebbar 2013-08-14 22:34 ` Russ Dill 2013-08-14 22:34 ` Russ Dill 2013-08-16 7:16 ` Gururaja Hebbar 2013-08-16 7:16 ` Gururaja Hebbar 2013-08-19 5:49 ` Gururaja Hebbar 2013-08-19 5:49 ` Gururaja Hebbar 2013-08-20 16:33 ` Russ Dill 2013-08-20 16:33 ` Russ Dill 2013-08-21 8:29 ` Gururaja Hebbar 2013-08-21 8:29 ` Gururaja Hebbar 2013-08-13 22:20 ` [PATCH v4 2/4] ARM: dts: add AM33XX vdd core opp50 suspend for Beaglebone Russ Dill 2013-08-13 22:20 ` Russ Dill 2013-08-14 8:59 ` Gururaja Hebbar 2013-08-14 8:59 ` Gururaja Hebbar 2013-08-14 22:21 ` Russ Dill 2013-08-14 22:21 ` Russ Dill 2013-08-13 22:20 ` [PATCH v4 3/4] ARM: dts: add AM33XX vdd core opp50 suspend for AM335X GP EVM Russ Dill 2013-08-13 22:20 ` Russ Dill 2013-08-13 22:20 ` [PATCH v4 4/4] ARM: dts: AM33XX vdd core opp50 suspend for EVM-SK Russ Dill 2013-08-13 22:20 ` Russ Dill 2013-08-14 13:38 ` [PATCH v4 0/4] ARM: OMAP2+: AM33XX: VDD CORE OPP50 support Jan Lübbe 2013-08-14 13:38 ` Jan Lübbe 2013-08-14 22:21 ` Russ Dill 2013-08-14 22:21 ` Russ Dill 2013-08-15 8:00 ` Jan Lübbe 2013-08-15 8:00 ` Jan Lübbe 2013-08-27 22:44 ` Kevin Hilman 2013-08-27 22:44 ` Kevin Hilman 2013-08-28 1:05 ` Russ Dill 2013-08-28 1:05 ` Russ Dill 2013-08-29 11:05 ` Mark Brown 2013-08-29 11:05 ` Mark Brown 2013-08-29 15:29 ` Kevin Hilman 2013-08-29 15:29 ` Kevin Hilman 2013-08-29 15:49 ` Mark Brown 2013-08-29 15:49 ` Mark Brown 2013-08-29 16:31 ` Russ Dill 2013-08-29 16:31 ` Russ Dill 2013-08-29 17:30 ` Mark Brown 2013-08-29 17:30 ` Mark Brown 2013-08-29 17:47 ` Russ Dill 2013-08-29 17:47 ` Russ Dill 2013-08-29 18:03 ` Mark Brown 2013-08-29 18:03 ` Mark Brown 2013-08-29 18:28 ` Russ Dill 2013-08-29 18:28 ` Russ Dill 2013-08-29 15:42 ` Russ Dill 2013-08-29 15:42 ` Russ Dill 2013-08-29 18:01 ` Mark Brown 2013-08-29 18:01 ` Mark Brown 2013-08-29 18:25 ` Russ Dill 2013-08-29 18:25 ` Russ Dill 2013-08-29 19:10 ` Mark Brown 2013-08-29 19:10 ` Mark Brown 2013-09-03 14:06 ` Russ Dill 2013-09-03 14:06 ` Russ Dill 2013-09-03 14:39 ` Mark Brown 2013-09-03 14:39 ` Mark Brown 2013-08-29 15:17 ` Kevin Hilman 2013-08-29 15:17 ` Kevin Hilman 2013-08-29 16:10 ` Russ Dill 2013-08-29 16:10 ` Russ Dill 2013-08-29 19:11 ` Kevin Hilman 2013-08-29 19:11 ` Kevin Hilman 2013-08-29 20:09 ` Vaibhav Bedia 2013-08-29 20:09 ` Vaibhav Bedia 2013-08-29 21:33 ` Kevin Hilman 2013-08-29 21:33 ` Kevin Hilman 2013-08-30 0:25 ` Russ Dill 2013-08-30 0:25 ` Russ Dill 2013-08-30 16:06 ` Kevin Hilman 2013-08-30 16:06 ` Kevin Hilman 2013-09-03 18:55 ` Russ Dill 2013-09-03 18:55 ` Russ Dill 2013-09-03 19:07 ` Kevin Hilman 2013-09-03 19:07 ` Kevin Hilman 2013-08-30 17:57 ` Vaibhav Bedia 2013-08-30 17:57 ` Vaibhav Bedia
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.