[PATCH] OMAPDSS: DSI: Support command mode interleaving during video mode blanking periods
DSI supports interleaving of command mode packets during the HSA, HFP, HBP and
BLLP blanking intervals in a video mode stream. This is useful as a user may
want to read or change the configuration of a panel without stopping the video
stream.
On OMAP DSI, we can queue HS or LP command mode packets in the TX FIFO, and
the DSI HW takes care of interleaving this data during the one of the blanking
intervals. The DSI HW needs to be programmed with the maximum amount of data
that can be interleaved in a particular blanking period. A blanking period
cannot be used to send command mode data for it's complete duration, there is
some amount of time required for the DSI data and clock lanes to transition
to the desired LP or HS state.
Based on the state of the lanes at the beginning and end of the blanking period,
we have different scenarios, with each scenario having a different value of time
required to transition to HS or LP. Refer to the section 'Interleaving Mode' in
OMAP TRM for more info on the scenarios and the equations to calculate the time
required for HS or LP transitions.
We use the scenarios which takes the maximum time for HS or LP transition, this
gives us the minimum amount of time that can be used to interleave command mode
data. The amount of data that can be sent during this minimum time is calculated
for command mode packets both in LP and HS. These are written to the registers
DSI_VM_TIMING4 to DSI_VM_TIMING6.
The calculations don't take into account the time required of transmitting BTA
when doing a DSI read, or verifying if a DSI write went through correctly. Until
these latencies aren't considered, the behaviour of DSI is unpredictable when
a BTA is interleaved during a blanking period. Enhancement of these calculations
is a TODO item.
The calculations are derived from DSI parameter calculation tools written by
Sebastien Fagard s-fag...@ti.com
Signed-off-by: Archit Taneja arc...@ti.com
---
Note:
- Tested on Blaze tablet and OMAP5 SEVM
- Reference tree with testing intelrevaing of commands on blaze tablet:
g...@gitorious.org:~boddob/linux-omap-dss2/archit-dss2-clone.git
dsi_interleave
drivers/video/omap2/dss/dsi.c | 181 +
1 files changed, 181 insertions(+), 0 deletions(-)
diff --git a/drivers/video/omap2/dss/dsi.c b/drivers/video/omap2/dss/dsi.c
index 95bc996..53228c9 100644
--- a/drivers/video/omap2/dss/dsi.c
+++ b/drivers/video/omap2/dss/dsi.c
@@ -3763,6 +3763,186 @@ static void dsi_config_blanking_modes(struct
omap_dss_device *dssdev)
dsi_write_reg(dsidev, DSI_CTRL, r);
}
+/*
+ * According to section 'HS Command Mode Interleaving' in OMAP TRM, Scenario 3
+ * results in maximum transition time for data and clock lanes to enter and
+ * exit HS mode. Hence, this is the scenario where the least amount of command
+ * mode data can be interleaved. We program the minimum amount of TXBYTECLKHS
+ * clock cycles that can be used to interleave command mode data in HS so that
+ * all scenarios are satisfied.
+ */
+static int dsi_compute_interleave_hs(int blank, bool ddr_alwon, int enter_hs,
+ int exit_hs, int exiths_clk, int ddr_pre, int ddr_post)
+{
+ int transition;
+
+ /*
+* If DDR_CLK_ALWAYS_ON is set, we need to consider HS mode transition
+* time of data lanes only, if it isn't set, we need to consider HS
+* transition time of both data and clock lanes. HS transition time
+* of Scenario 3 is considered.
+*/
+ if (ddr_alwon) {
+ transition = enter_hs + exit_hs + max(enter_hs, 2) + 1;
+ } else {
+ int trans1, trans2;
+ trans1 = ddr_pre + enter_hs + exit_hs + max(enter_hs, 2) + 1;
+ trans2 = ddr_pre + enter_hs + exiths_clk + ddr_post + ddr_pre +
+ enter_hs + 1;
+ transition = max(trans1, trans2);
+ }
+
+ return blank transition ? blank - transition : 0;
+}
+
+/*
+ * According to section 'LP Command Mode Interleaving' in OMAP TRM, Scenario 1
+ * results in maximum transition time for data lanes to enter and exit LP mode.
+ * Hence, this is the scenario where the least amount of command mode data can
+ * be interleaved. We program the minimum amount of bytes that can be
+ * interleaved in LP so that all scenarios are satisfied.
+ */
+static int dsi_compute_interleave_lp(int blank, int enter_hs, int exit_hs,
+ int lp_clk_div, int tdsi_fclk)
+{
+ int trans_lp; /* time required for a LP transition, in TXBYTECLKHS */
+ int tlp_avail; /* time left for interleaving commands, in CLKIN4DDR */
+ int ttxclkesc; /* period of LP transmit escape clock, in CLKIN4DDR */
+ int thsbyte_clk = 16; /* Period of TXBYTECLKHS clock, in CLKIN4DDR */
+ int lp_inter; /* cmd mode data that can be interleaved, in bytes */
+
+ /* maximum LP transition time according to Scenario 1 */
+ trans_lp = exit_hs +
RE: [GIT PULL] ARM: OMAP2+: Add AM335x and AM3517/05 EVM DT support
On Sat, May 12, 2012 at 22:45:04, Tony Lindgren wrote: * Hiremath, Vaibhav hvaib...@ti.com [120512 01:26]: On Sat, May 12, 2012 at 01:26:20, Tony Lindgren wrote: Hi, * Cousson, Benoit b-cous...@ti.com [120511 05:51]: Hi Tony, Here are some remaining DT patches I was not able to push at 3.4 due to some missing dependency. It applies now fine on top of lo/dt branch. It seems that there are still patches being discussed for those SoCs and we're pretty much done for this merge window. So unless things drag on to -rc8, I'd say we just need to postpone merging new things and merge them early around -rc2. Oops... It seems like I missed this merge window as well... We can still queue these into linux-omap for testing as soon as the patches are ready. In general, for anything more intrusive we want to have the patches sitting in linux-omap master branch and then in linux-next for at least a week. Then merging them into mainline tree is usually safe to do. The reason for this is that mainline kernel is our stable tree, not our development tree. We just need to queue most of things between -rc2 and -rc4 into the arm-soc tree, and have any issues fixed up before the merge window. Trying to cram development branches in around -rc6 just causes us a huge maintenance nightmare trying to fix up things in the mainline tree between -rc1 and -rc4. Understood Tony... This time I will try to follow up closely and will make sure that we have everything (especially new development) by rc2-rc4 window. Thanks, Vaibhav -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/4] REGULATOR: regulator driver for Palmas series chips
On 14/05/12 17:52, Mark Brown wrote:
On Mon, May 14, 2012 at 10:58:31AM +0900, Graeme Gregory wrote:
Looks good, quite a few of the things below are updates for very
recently introduced APIs.
+static int palmas_smps_read(struct palmas *palmas, unsigned int reg,
+unsigned int *dest)
+{
+int slave;
+unsigned int addr;
+
+slave = PALMAS_BASE_TO_SLAVE(PALMAS_SMPS_BASE);
+addr = PALMAS_BASE_TO_REG(PALMAS_SMPS_BASE, reg);
+
+return regmap_read(palmas-regmap[slave], addr, dest);
+}
Looks like the LDO and SPMS regulators both use the same regmap?
Yes have tidied this up a little in latest version.
+.get_voltage= palmas_get_voltage_smps,
Why not get_voltage_sel?
Mild amnesia is my excuse, is fixed now!
+.set_voltage_sel= palmas_set_voltage_smps_sel,
+.list_voltage = palmas_list_voltage_smps,
Implementing map_voltage() too would be nice.
I have implemented it for smps.
+static int palmas_is_enabled_smps10(struct regulator_dev *dev)
+{
+struct palmas_pmic *pmic = rdev_get_drvdata(dev);
+unsigned int reg;
+
+palmas_smps_read(pmic-palmas, PALMAS_SMPS10_STATUS, reg);
+
+reg = SMPS10_BOOST_EN;
+
Should be able to use regulator_is_enabled_regmap() and friends.
Has been converted thanks!
+static int palmas_list_voltage_smps10(struct regulator_dev *dev,
+unsigned selector)
+{
+if (selector)
+return 500;
+
+return 375;
This could be written a little more transparently!
Have re-written it hopefully clearer.
+static int palmas_get_voltage_smps10(struct regulator_dev *dev)
+{
+struct palmas_pmic *pmic = rdev_get_drvdata(dev);
+int selector;
+unsigned int reg;
+
+palmas_smps_read(pmic-palmas, PALMAS_SMPS10_CTRL, reg);
+
+selector = (reg SMPS10_VSEL) 3;
+
+return palmas_list_voltage_smps10(dev, selector);
Should be get_voltage_sel() really, or beter still should be using
regulator_set_voltage_sel_regmap(). Similarly for the set (which is
already using _sel()).
I have implemented it using the regmap functions thanks for tip!
+static int palmas_enable_ldo(struct regulator_dev *dev)
+{
+struct palmas_pmic *pmic = rdev_get_drvdata(dev);
+int id = rdev_get_id(dev);
+unsigned int reg;
+
+palmas_ldo_read(pmic-palmas, palmas_regs_info[id].ctrl_addr, reg);
+
+reg |= LDO1_CTRL_MODE_ACTIVE;
+
+palmas_ldo_write(pmic-palmas, palmas_regs_info[id].ctrl_addr, reg);
Could use the core regmap stuff for the LDOs too.
Enable/Disable now use regmap but is_enabled cant as it reads from a
different bitmask.
+/* Adjust selector to match list_voltage ranges */
+if (selector 49)
+selector = 49;
+
+return palmas_list_voltage_ldo(dev, selector);
get_voltage_sel().
Has been fixed!
+if (!pdata)
+return -EINVAL;
+if (!pdata-reg_data)
+return -EINVAL;
I'd expect the driver to be able to register the regulators with no
platform data at all.
Ok, I misunderstood how the pdata was used, hopefully I have got it
correct in the new version.
+pmic = kzalloc(sizeof(*pmic), GFP_KERNEL);
+if (!pmic)
+return -ENOMEM;
devm_kzalloc()
Fixed!
+pmic-desc = kcalloc(PALMAS_NUM_REGS,
+sizeof(struct regulator_desc), GFP_KERNEL);
+if (!pmic-desc) {
+ret = -ENOMEM;
+goto err_free_pmic;
+}
Just embed this in the pmic struct? It's always the same size.
Have embedded, this was a left over from when I was originally planning
the muxing handling.
+pmic-rdev = kcalloc(PALMAS_NUM_REGS,
+sizeof(struct regulator_dev *), GFP_KERNEL);
Similarly heere.
Same as above.
Thanks for taking time to review. Am sending v2 patches soon.
Graeme
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v4 04/39] ARM: OMAP2+: gpmc: Acquire NAND CS value
Hello Afzal, On 05/14/12 12:33, Mohammed, Afzal wrote: Hi All, On Thu, May 03, 2012 at 14:12:11, Mohammed, Afzal wrote: Some boards depend on bootloader to update chip select value for NAND. It is felt that Kernel should not depend on bootloader to get CS, as for a particular board CS is hardwired and is fixed, hence this can directly be updated in Kernel. But as CS value for boards that depend on this behaviour is not available, educate gpmc driver to acquire chip select value for NAND. this ideally should be removed once CS for those boards are available. Do you know how many boards require this? If so which are those boards? devkit8000, beagle board, omap3touchbook, overo. Beagle board, found out to be zero. I need a help. Can someone familiar with boards - devkit8000, omap3touchbook, overo boards, let me know GPMC CS on which NAND is connected. On Devkit8000 the NAND is connected to CS0. I thought that all NAND devices for booting are connected to CS0, because of ROM code? According to spruf98w.pdf: 25.4.7.4 NAND ... * The device is connected to CS0. ... Regards, Thomas Hi Tony, I am planning to provide actual CS # used for NAND on above boards instead of finding the value at runtime. Is there any reason that NAND CS# is found out at runtime ? (hence remove necessity of omap_nand_flash_init()). Presence of this also causes an additional dependency of bootloader. As CS # depends on wiring on the board, my understanding is that it will be fixed for a given board. Are you ok if acquiring NAND CS # is removed ? Removal of this helps in simplifying gpmc driver (undergoing conversion). Regards Afzal -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH v4 04/39] ARM: OMAP2+: gpmc: Acquire NAND CS value
Hi Thomas, On Tue, May 15, 2012 at 12:00:32, Thomas Weber wrote: I need a help. Can someone familiar with boards - devkit8000, omap3touchbook, overo boards, let me know GPMC CS on which NAND is connected. On Devkit8000 the NAND is connected to CS0. Thanks for the information I thought that all NAND devices for booting are connected to CS0, because of ROM code? According to spruf98w.pdf: 25.4.7.4 NAND ... * The device is connected to CS0. Yes, expecting they should be, looking for confirmation. Regards Afzal -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCHv2 0/4] Adding support for Palmas PMIC
This is the MFD and regulator parts for the Palmas family of chips from Texas Instruments. It has been decided to use the Palmas name in the driver instead of the various marketing names the family will be avilable with to avoid confusion. The driver will in the future determine the exact product from the OTP information and adapt accordingly. Currently the driver will handle the twl6035 and twl6037 varients. Changes since v1 Attended to review items from Mark Brown Converted to use regmap_irq_chip Converted to using some regulator_xxx_regmap functions in pmic driver Removed some excess stuff from header file. Graeme -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCHv2 2/4] MFD: palmas PMIC device support Kconfig
Add the new palmas MFD to Kconfig and Makefile Signed-off-by: Graeme Gregory g...@slimlogic.co.uk --- drivers/mfd/Kconfig | 10 ++ drivers/mfd/Makefile |1 + 2 files changed, 11 insertions(+) diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig index 9846424..8565658 100644 --- a/drivers/mfd/Kconfig +++ b/drivers/mfd/Kconfig @@ -909,6 +909,16 @@ config MFD_ANATOP MFD controller. This controller embeds regulator and thermal devices for Freescale i.MX platforms. +config MFD_PALMAS + bool Support for the TI Palmas series chips + select MFD_CORE + select REGMAP_I2C + select REGMAP_IRQ + depends on I2C=y + help + If you say yes here you get support for the Palmas + series of PMIC chips from Texas Instruments. + endmenu endif diff --git a/drivers/mfd/Makefile b/drivers/mfd/Makefile index acc888d..9ab5e37 100644 --- a/drivers/mfd/Makefile +++ b/drivers/mfd/Makefile @@ -118,3 +118,4 @@ obj-$(CONFIG_MFD_RC5T583) += rc5t583.o rc5t583-irq.o obj-$(CONFIG_MFD_S5M_CORE) += s5m-core.o s5m-irq.o obj-$(CONFIG_MFD_ANATOP) += anatop-mfd.o obj-$(CONFIG_MFD_LM3533) += lm3533-core.o lm3533-ctrlbank.o +obj-$(CONFIG_MFD_PALMAS) += palmas.o -- 1.7.9.5 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCHv2 4/4] REGULATOR: regulator for Palmas Kconfig
Add the Kconfig/Makefile stuff for the palmas regulator driver Signed-off-by: Graeme Gregory g...@slimlogic.co.uk --- drivers/regulator/Kconfig | 12 drivers/regulator/Makefile |1 + 2 files changed, 13 insertions(+) diff --git a/drivers/regulator/Kconfig b/drivers/regulator/Kconfig index 4ad4e8d..c86b886 100644 --- a/drivers/regulator/Kconfig +++ b/drivers/regulator/Kconfig @@ -268,6 +268,18 @@ config REGULATOR_DB8500_PRCMU This driver supports the voltage domain regulators controlled by the DB8500 PRCMU +config REGULATOR_PALMAS + tristate TI Palmas PMIC Regulators + depends on MFD_PALMAS + help + If you wish to control the regulators on the Palmas series of + chips say Y here. This will enable support for all the software + controllable SMPS/LDO regulators. + + The regulators available on Palmas series chips vary depending + on the muxing. This is handled automatically in the driver by + reading the mux info from OTP. + config REGULATOR_TPS6105X tristate TI TPS6105X Power regulators depends on TPS6105X diff --git a/drivers/regulator/Makefile b/drivers/regulator/Makefile index dcc56dc..977fd46 100644 --- a/drivers/regulator/Makefile +++ b/drivers/regulator/Makefile @@ -33,6 +33,7 @@ obj-$(CONFIG_REGULATOR_MAX8998) += max8998.o obj-$(CONFIG_REGULATOR_MC13783) += mc13783-regulator.o obj-$(CONFIG_REGULATOR_MC13892) += mc13892-regulator.o obj-$(CONFIG_REGULATOR_MC13XXX_CORE) += mc13xxx-regulator-core.o +obj-$(CONFIG_REGULATOR_PALMAS) += palmas-regulator.o obj-$(CONFIG_REGULATOR_PCAP) += pcap-regulator.o obj-$(CONFIG_REGULATOR_PCF50633) += pcf50633-regulator.o obj-$(CONFIG_REGULATOR_RC5T583) += rc5t583-regulator.o -- 1.7.9.5 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCHv2 3/4] REGULATOR: regulator driver for Palmas series chips
Palmas has both Switched Mode (SMPS) and Linear (LDO) regulators in it.
This regulator driver allows software control of these regulators.
The regulators available on Palmas series chips vary depending on the muxing.
This is handled automatically in the driver by reading the mux info from OTP.
Signed-off-by: Graeme Gregory g...@slimlogic.co.uk
---
drivers/regulator/palmas-regulator.c | 822 ++
include/linux/mfd/palmas.h | 125 ++
2 files changed, 947 insertions(+)
create mode 100644 drivers/regulator/palmas-regulator.c
diff --git a/drivers/regulator/palmas-regulator.c
b/drivers/regulator/palmas-regulator.c
new file mode 100644
index 000..c4435f6
--- /dev/null
+++ b/drivers/regulator/palmas-regulator.c
@@ -0,0 +1,822 @@
+/*
+ * Driver for Regulator part of Palmas PMIC Chips
+ *
+ * Copyright 2011-2012 Texas Instruments Inc.
+ *
+ * Author: Graeme Gregory g...@slimlogic.co.uk
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License as published by the
+ * Free Software Foundation; either version 2 of the License, or (at your
+ * option) any later version.
+ *
+ */
+
+#include linux/kernel.h
+#include linux/module.h
+#include linux/init.h
+#include linux/err.h
+#include linux/platform_device.h
+#include linux/regulator/driver.h
+#include linux/regulator/machine.h
+#include linux/slab.h
+#include linux/regmap.h
+#include linux/mfd/palmas.h
+
+struct regs_info {
+ char*name;
+ u8 vsel_addr;
+ u8 ctrl_addr;
+ u8 tstep_addr;
+};
+
+static const struct regs_info palmas_regs_info[] = {
+ {
+ .name = SMPS12,
+ .vsel_addr = PALMAS_SMPS12_VOLTAGE,
+ .ctrl_addr = PALMAS_SMPS12_CTRL,
+ .tstep_addr = PALMAS_SMPS12_TSTEP,
+ },
+ {
+ .name = SMPS123,
+ .vsel_addr = PALMAS_SMPS12_VOLTAGE,
+ .ctrl_addr = PALMAS_SMPS12_CTRL,
+ .tstep_addr = PALMAS_SMPS12_TSTEP,
+ },
+ {
+ .name = SMPS3,
+ .vsel_addr = PALMAS_SMPS3_VOLTAGE,
+ .ctrl_addr = PALMAS_SMPS3_CTRL,
+ },
+ {
+ .name = SMPS45,
+ .vsel_addr = PALMAS_SMPS45_VOLTAGE,
+ .ctrl_addr = PALMAS_SMPS45_CTRL,
+ .tstep_addr = PALMAS_SMPS45_TSTEP,
+ },
+ {
+ .name = SMPS457,
+ .vsel_addr = PALMAS_SMPS45_VOLTAGE,
+ .ctrl_addr = PALMAS_SMPS45_CTRL,
+ .tstep_addr = PALMAS_SMPS45_TSTEP,
+ },
+ {
+ .name = SMPS6,
+ .vsel_addr = PALMAS_SMPS6_VOLTAGE,
+ .ctrl_addr = PALMAS_SMPS6_CTRL,
+ .tstep_addr = PALMAS_SMPS6_TSTEP,
+ },
+ {
+ .name = SMPS7,
+ .vsel_addr = PALMAS_SMPS7_VOLTAGE,
+ .ctrl_addr = PALMAS_SMPS7_CTRL,
+ },
+ {
+ .name = SMPS8,
+ .vsel_addr = PALMAS_SMPS8_VOLTAGE,
+ .ctrl_addr = PALMAS_SMPS8_CTRL,
+ .tstep_addr = PALMAS_SMPS8_TSTEP,
+ },
+ {
+ .name = SMPS9,
+ .vsel_addr = PALMAS_SMPS9_VOLTAGE,
+ .ctrl_addr = PALMAS_SMPS9_CTRL,
+ },
+ {
+ .name = SMPS10,
+ },
+ {
+ .name = LDO1,
+ .vsel_addr = PALMAS_LDO1_VOLTAGE,
+ .ctrl_addr = PALMAS_LDO1_CTRL,
+ },
+ {
+ .name = LDO2,
+ .vsel_addr = PALMAS_LDO2_VOLTAGE,
+ .ctrl_addr = PALMAS_LDO2_CTRL,
+ },
+ {
+ .name = LDO3,
+ .vsel_addr = PALMAS_LDO3_VOLTAGE,
+ .ctrl_addr = PALMAS_LDO3_CTRL,
+ },
+ {
+ .name = LDO4,
+ .vsel_addr = PALMAS_LDO4_VOLTAGE,
+ .ctrl_addr = PALMAS_LDO4_CTRL,
+ },
+ {
+ .name = LDO5,
+ .vsel_addr = PALMAS_LDO5_VOLTAGE,
+ .ctrl_addr = PALMAS_LDO5_CTRL,
+ },
+ {
+ .name = LDO6,
+ .vsel_addr = PALMAS_LDO6_VOLTAGE,
+ .ctrl_addr = PALMAS_LDO6_CTRL,
+ },
+ {
+ .name = LDO7,
+ .vsel_addr = PALMAS_LDO7_VOLTAGE,
+ .ctrl_addr = PALMAS_LDO7_CTRL,
+ },
+ {
+ .name = LDO8,
+ .vsel_addr = PALMAS_LDO8_VOLTAGE,
+ .ctrl_addr = PALMAS_LDO8_CTRL,
+ },
+ {
+
Re: [PATCH 1/3] ARM: OMAP2+: gpmc: update nand register helper
On Fri, May 11, 2012 at 09:02:14PM +0100, Tony Lindgren wrote:
* Afzal Mohammed af...@ti.com [120511 08:48]:
Provide helper function for updating NAND register details for
the necessary chip select. NAND drivers platform data can be
updated with this information so that NAND driver can handle
GPMC NAND operations by itself.
Hmm this seems that it might be a more future proof path.
OK, I'll try to rewrite my patch on top of these.
Best Regards,
--
Ivan
Tony
Signed-off-by: Afzal Mohammed af...@ti.com
---
arch/arm/mach-omap2/gpmc.c | 21 +
arch/arm/plat-omap/include/plat/gpmc.h | 18 ++
2 files changed, 39 insertions(+)
diff --git a/arch/arm/mach-omap2/gpmc.c b/arch/arm/mach-omap2/gpmc.c
index 46b09da..a409a3e 100644
--- a/arch/arm/mach-omap2/gpmc.c
+++ b/arch/arm/mach-omap2/gpmc.c
@@ -49,6 +49,7 @@
#define GPMC_ECC_CONTROL 0x1f8
#define GPMC_ECC_SIZE_CONFIG 0x1fc
#define GPMC_ECC1_RESULT0x200
+#define GPMC_ECC_BCH_RESULT_0 0x240
/* GPMC ECC control settings */
#define GPMC_ECC_CTRL_ECCCLEAR 0x100
@@ -681,6 +682,26 @@ int gpmc_prefetch_reset(int cs)
}
EXPORT_SYMBOL(gpmc_prefetch_reset);
+void gpmc_update_nand_reg(struct gpmc_nand_regs *reg, int cs)
+{
+ reg-gpmc_status = gpmc_base + GPMC_STATUS;
+ reg-gpmc_nand_command = gpmc_base + GPMC_CS0_OFFSET +
+ GPMC_CS_NAND_COMMAND + GPMC_CS_SIZE * cs;
+ reg-gpmc_nand_address = gpmc_base + GPMC_CS0_OFFSET +
+ GPMC_CS_NAND_ADDRESS + GPMC_CS_SIZE * cs;
+ reg-gpmc_nand_data = gpmc_base + GPMC_CS0_OFFSET +
+ GPMC_CS_NAND_DATA + GPMC_CS_SIZE * cs;
+ reg-gpmc_prefetch_config1 = gpmc_base + GPMC_PREFETCH_CONFIG1;
+ reg-gpmc_prefetch_config2 = gpmc_base + GPMC_PREFETCH_CONFIG2;
+ reg-gpmc_prefetch_control = gpmc_base + GPMC_PREFETCH_CONTROL;
+ reg-gpmc_prefetch_status = gpmc_base + GPMC_PREFETCH_STATUS;
+ reg-gpmc_ecc_config = gpmc_base + GPMC_ECC_CONFIG;
+ reg-gpmc_ecc_control = gpmc_base + GPMC_ECC_CONTROL;
+ reg-gpmc_ecc_size_config = gpmc_base + GPMC_ECC_SIZE_CONFIG;
+ reg-gpmc_ecc1_result = gpmc_base + GPMC_ECC1_RESULT;
+ reg-gpmc_bch_result0 = gpmc_base + GPMC_ECC_BCH_RESULT_0;
+}
+
static void __init gpmc_mem_init(void)
{
int cs;
diff --git a/arch/arm/plat-omap/include/plat/gpmc.h
b/arch/arm/plat-omap/include/plat/gpmc.h
index 1527929..6a8078e 100644
--- a/arch/arm/plat-omap/include/plat/gpmc.h
+++ b/arch/arm/plat-omap/include/plat/gpmc.h
@@ -131,6 +131,24 @@ struct gpmc_timings {
u16 wr_data_mux_bus;/* WRDATAONADMUXBUS */
};
+struct gpmc_nand_regs {
+ void __iomem*gpmc_status;
+ void __iomem*gpmc_nand_command;
+ void __iomem*gpmc_nand_address;
+ void __iomem*gpmc_nand_data;
+ void __iomem*gpmc_prefetch_config1;
+ void __iomem*gpmc_prefetch_config2;
+ void __iomem*gpmc_prefetch_control;
+ void __iomem*gpmc_prefetch_status;
+ void __iomem*gpmc_ecc_config;
+ void __iomem*gpmc_ecc_control;
+ void __iomem*gpmc_ecc_size_config;
+ void __iomem*gpmc_ecc1_result;
+ void __iomem*gpmc_bch_result0;
+};
+
+extern void gpmc_update_nand_reg(struct gpmc_nand_regs *reg, int cs);
+
extern unsigned int gpmc_ns_to_ticks(unsigned int time_ns);
extern unsigned int gpmc_ps_to_ticks(unsigned int time_ps);
extern unsigned int gpmc_ticks_to_ns(unsigned int ticks);
--
1.7.10
--
Ivan Djelic
Operating System Team Manager
tel + 33 01 48 03 70 16
-
Parrot
174, Quai de Jemmapes
75010 Paris, France
tel + 33 01 48 03 60 60
fax + 33 01 48 03 70 08
-
http://www.parrot.com
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: v3.4-rc4 DSS PM problem (Was: Re: Problems with 3.4-rc5)
On Mon, 2012-05-14 at 15:48 -0700, Kevin Hilman wrote: Tomi Valkeinen tomi.valkei...@ti.com writes: On Mon, 2012-05-14 at 08:36 +0100, Joe Woodward wrote: Any news on this? This thread seems to have gone a little quiet... Hi, I've been doing testing to understand the problem, but so far I don't have any idea why things go wrong. I haven't found out any logic in which configuration works and which doesn't. Looks to me that for some reason the PM prevents DSS from getting data fast enough with certain fifo thresholds. I have two ways to avoid the problem, but I've been reluctant to make patches for those because I feel it's just hiding the problem. One way is to change DISPC SIDLEMODE or MIDLEMODE to disallow idle/standby. The other is to use certain fifo threshold values, which just seem to work for unknown reasons. Considering that we already have a SIDLEMODE hack in DSS for omap3 when using DSI, I wonder if the omap3 PM + DSS combination is just plain broken, and we should disallow idle. I'm not quite sure what are the implications of that. I'd appreciate comments from the PM people =). Unfortunately, without the bandwidth to dig into this deeply myself, I don't have much to add. Yes, that's understandable. However, can you shed some light about the PM in OMAP3. What is it that happens here regarding PM, which does not happen is USB gadget driver is compiled in? Or when I set DSS to no-idle or no-standby? Something about L3/core/memory going into idle state? I tried to look at the debugfs/pm_debug/ files, but I couldn't see a difference between working and non-working cases. At least the OFF/RET/ON/etc states were not affected. Are there some other debug files to look at? Are there power saving features that are not observable via debug files? As we know, it's not unheard of for various IPs to have bugs in smart-idle mode ;) The one thing I can say is that the reason it probably worked on earlier kernels was because the UART driver was not actually idling, so you were probably never hitting low power states. There is also a change in the DSS fifos, which probably triggered this. I think I can fall back to the old behavior. Tomi signature.asc Description: This is a digitally signed message part
Re: [RFC 00/12] OMAP DMA engine conversion
On Tue, May 15, 2012 at 09:49:24AM +0530, Vinod Koul wrote: On Mon, 2012-04-23 at 17:04 +0100, Russell King - ARM Linux wrote: For the full text, please see http://lists.arm.linux.org.uk/lurker/message/20120418.100954.7fa7acf8.en.html This version contains updates for some of the comments received from the previous round, and adds the OMAP1/2 MMC and SPI drivers to the conversion. I've also added a note to feature-removal noting that the existing APIs will be removed around 2013 - I'm planning January for that at the moment. Having drivers around which are unconverted blocks further work on the DMA engine conversion, so it's actually important that we get as many drivers converted as soon as possible. Anything which isn't converted will probably have its DMA code removed, or if that results in the driver not being usable, the driver itself will be removed. This series is still in RFC mode... Hi Russell, What is the state of this series, would be good to have this merged in upcoming merge window. It's not ready for merging. While it allows some of the OMAP drivers to be converted, there's others which need changes to omap-dma.c. So, I'm _not_ planning to see this in for the upcoming merge window. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] arm: omap3: am35x: Set proper powerdomain states
Hi Mark,
On Mon, Apr 30, 2012 at 11:26 PM, Mark A. Greer mgr...@animalcreek.com wrote:
From: Mark A. Greer mgr...@animalcreek.com
The am35x family of SoCs only support the PWRSTS_ON
state so create a new set of powerdomain structures
that ensure that only the ON state is entered.
Signed-off-by: Mark A. Greer mgr...@animalcreek.com
---
These patches apply on top of Kevin's patch series,
[PATCH/RFT 0/8] ARM: OMAP: remove IP checks from SoC family detection
Tested on an am3517 evm and am37x evm.
arch/arm/mach-omap2/powerdomains3xxx_data.c | 136
---
1 file changed, 124 insertions(+), 12 deletions(-)
diff --git a/arch/arm/mach-omap2/powerdomains3xxx_data.c
b/arch/arm/mach-omap2/powerdomains3xxx_data.c
index fb0a0a6..6ec06ad 100644
--- a/arch/arm/mach-omap2/powerdomains3xxx_data.c
+++ b/arch/arm/mach-omap2/powerdomains3xxx_data.c
@@ -71,6 +71,22 @@ static struct powerdomain mpu_3xxx_pwrdm = {
.voltdm = { .name = mpu_iva },
};
+static struct powerdomain mpu_am35x_pwrdm = {
+ .name = mpu_pwrdm,
+ .prcm_offs = MPU_MOD,
+ .pwrsts = PWRSTS_ON,
+ .pwrsts_logic_ret = PWRSTS_ON,
+ .flags = PWRDM_HAS_MPU_QUIRK,
+ .banks = 1,
+ .pwrsts_mem_ret = {
+ [0] = PWRSTS_ON,
+ },
+ .pwrsts_mem_on = {
+ [0] = PWRSTS_ON,
+ },
+ .voltdm = { .name = mpu_iva },
+};
+
/*
* The USBTLL Save-and-Restore mechanism is broken on
* 3430s up to ES3.0 and 3630ES1.0. Hence this feature
@@ -120,6 +136,23 @@ static struct powerdomain core_3xxx_es3_1_pwrdm = {
.voltdm = { .name = core },
};
+static struct powerdomain core_am35x_pwrdm = {
+ .name = core_pwrdm,
+ .prcm_offs = CORE_MOD,
+ .pwrsts = PWRSTS_ON,
+ .pwrsts_logic_ret = PWRSTS_ON,
+ .banks = 2,
+ .pwrsts_mem_ret = {
+ [0] = PWRSTS_ON, /* MEM1RETSTATE */
+ [1] = PWRSTS_ON, /* MEM2RETSTATE */
+ },
+ .pwrsts_mem_on = {
+ [0] = PWRSTS_ON, /* MEM1ONSTATE */
+ [1] = PWRSTS_ON, /* MEM2ONSTATE */
+ },
+ .voltdm = { .name = core },
+};
+
static struct powerdomain dss_pwrdm = {
.name = dss_pwrdm,
.prcm_offs = OMAP3430_DSS_MOD,
@@ -135,6 +168,21 @@ static struct powerdomain dss_pwrdm = {
.voltdm = { .name = core },
};
+static struct powerdomain dss_am35x_pwrdm = {
+ .name = dss_pwrdm,
+ .prcm_offs = OMAP3430_DSS_MOD,
+ .pwrsts = PWRSTS_ON,
+ .pwrsts_logic_ret = PWRSTS_ON,
+ .banks = 1,
+ .pwrsts_mem_ret = {
+ [0] = PWRSTS_ON, /* MEMRETSTATE */
+ },
+ .pwrsts_mem_on = {
+ [0] = PWRSTS_ON, /* MEMONSTATE */
+ },
+ .voltdm = { .name = core },
+};
+
/*
* Although the 34XX TRM Rev K Table 4-371 notes that retention is a
* possible SGX powerstate, the SGX device itself does not support
@@ -156,6 +204,21 @@ static struct powerdomain sgx_pwrdm = {
.voltdm = { .name = core },
};
+static struct powerdomain sgx_am35x_pwrdm = {
+ .name = sgx_pwrdm,
+ .prcm_offs = OMAP3430ES2_SGX_MOD,
+ .pwrsts = PWRSTS_ON,
+ .pwrsts_logic_ret = PWRSTS_ON,
+ .banks = 1,
+ .pwrsts_mem_ret = {
+ [0] = PWRSTS_ON, /* MEMRETSTATE */
+ },
+ .pwrsts_mem_on = {
+ [0] = PWRSTS_ON, /* MEMONSTATE */
+ },
+ .voltdm = { .name = core },
+};
+
static struct powerdomain cam_pwrdm = {
.name = cam_pwrdm,
.prcm_offs = OMAP3430_CAM_MOD,
@@ -186,6 +249,21 @@ static struct powerdomain per_pwrdm = {
.voltdm = { .name = core },
};
+static struct powerdomain per_am35x_pwrdm = {
+ .name = per_pwrdm,
+ .prcm_offs = OMAP3430_PER_MOD,
+ .pwrsts = PWRSTS_ON,
+ .pwrsts_logic_ret = PWRSTS_ON,
+ .banks = 1,
+ .pwrsts_mem_ret = {
+ [0] = PWRSTS_ON, /* MEMRETSTATE */
+ },
+ .pwrsts_mem_on = {
+ [0] = PWRSTS_ON, /* MEMONSTATE */
+ },
+ .voltdm = { .name = core },
+};
+
static struct powerdomain emu_pwrdm = {
.name = emu_pwrdm,
.prcm_offs = OMAP3430_EMU_MOD,
@@ -200,6 +278,14 @@ static struct powerdomain neon_pwrdm = {
.voltdm = { .name = mpu_iva },
};
+static struct powerdomain neon_am35x_pwrdm = {
+ .name = neon_pwrdm,
+ .prcm_offs = OMAP3430_NEON_MOD,
+ .pwrsts = PWRSTS_ON,
[PATCH] OMAPDSS: DISPC: Update Accumulator configuration for chroma plane
DISPC has two accumulator registers DISPC_VIDp_ACCU_0 and DISPC_VIDp_ACCU_1 each
with horizontal and vertical bit fields. The bit fields can take values in the
range of -1024 to 1023. Based on bit field values DISPC decides on which one out
of 8 phases the filtering starts. DISPC_VIDp_ACCU_0 is used for progressive
output and for interlaced output both DISPC_VIDp_ACCU_0 and DISPC_VIDp_ACCU_1
are used.
The current accumulator values in DISPC scaling logic for chroma plane takes
default values for all color modes and rotation types. So, the horizontal and
vertical up and downsampling accumulator bit field values have been updated for
better performance.
Signed-off-by: Chandrabhanu Mahapatra cmahapa...@ti.com
---
drivers/video/omap2/dss/dispc.c | 92 +-
1 files changed, 89 insertions(+), 3 deletions(-)
diff --git a/drivers/video/omap2/dss/dispc.c b/drivers/video/omap2/dss/dispc.c
index ee30937..ad779d9 100644
--- a/drivers/video/omap2/dss/dispc.c
+++ b/drivers/video/omap2/dss/dispc.c
@@ -1185,6 +1185,92 @@ static void dispc_ovl_set_scale_param(enum omap_plane
plane,
dispc_ovl_set_fir(plane, fir_hinc, fir_vinc, color_comp);
}
+static void dispc_ovl_set_accu_uv(enum omap_plane plane,
+ u16 orig_width, u16 orig_height, u16 out_width, u16 out_height,
+ bool ilace, enum omap_color_mode color_mode, u8 rotation)
+{
+ int h_accu2_0, h_accu2_1;
+ int v_accu2_0, v_accu2_1;
+ int chroma_hinc, chroma_vinc;
+ int idx;
+
+ struct accu {
+ s8 h0_m, h0_n;
+ s8 h1_m, h1_n;
+ s8 v0_m, v0_n;
+ s8 v1_m, v1_n;
+ };
+
+ const struct accu *accu_table;
+ const struct accu *accu_val;
+
+ static const struct accu accu_nv12[4] = {
+ { 0, 1, 0, 1 , -1, 2, 0, 1 },
+ { 1, 2, -3, 4 , 0, 1, 0, 1 },
+ { -1, 1, 0, 1 , -1, 2, 0, 1 },
+ { -1, 2, -1, 2 , -1, 1, 0, 1 },
+ };
+
+ static const struct accu accu_nv12_ilace[4] = {
+ { 0, 1, 0, 1 , -3, 4, -1, 4 },
+ { -1, 4, -3, 4 , 0, 1, 0, 1 },
+ { -1, 1, 0, 1 , -1, 4, -3, 4 },
+ { -3, 4, -3, 4 , -1, 1, 0, 1 },
+ };
+
+ static const struct accu accu_yuv[4] = {
+ { 0, 1, 0, 1, 0, 1, 0, 1 },
+ { 0, 1, 0, 1, 0, 1, 0, 1 },
+ { -1, 1, 0, 1, 0, 1, 0, 1 },
+ { 0, 1, 0, 1, -1, 1, 0, 1 },
+ };
+
+ switch (rotation) {
+ case OMAP_DSS_ROT_0:
+ idx = 0;
+ break;
+ case OMAP_DSS_ROT_90:
+ idx = 1;
+ break;
+ case OMAP_DSS_ROT_180:
+ idx = 2;
+ break;
+ case OMAP_DSS_ROT_270:
+ idx = 3;
+ break;
+ default:
+ BUG();
+ }
+
+ switch (color_mode) {
+ case OMAP_DSS_COLOR_NV12:
+ if (ilace)
+ accu_table = accu_nv12_ilace;
+ else
+ accu_table = accu_nv12;
+ break;
+ case OMAP_DSS_COLOR_YUV2:
+ case OMAP_DSS_COLOR_UYVY:
+ accu_table = accu_yuv;
+ break;
+ default:
+ BUG();
+ }
+
+ accu_val = accu_table[idx];
+
+ chroma_hinc = 1024 * orig_width / out_width;
+ chroma_vinc = 1024 * orig_height / out_height;
+
+ h_accu2_0 = (accu_val-h0_m * chroma_hinc / accu_val-h0_n) % 1024;
+ h_accu2_1 = (accu_val-h1_m * chroma_hinc / accu_val-h1_n) % 1024;
+ v_accu2_0 = (accu_val-v0_m * chroma_vinc / accu_val-v0_n) % 1024;
+ v_accu2_1 = (accu_val-v1_m * chroma_vinc / accu_val-v1_n) % 1024;
+
+ dispc_ovl_set_vid_accu2_0(plane, h_accu2_0, v_accu2_0);
+ dispc_ovl_set_vid_accu2_1(plane, h_accu2_1, v_accu2_1);
+}
+
static void dispc_ovl_set_scaling_common(enum omap_plane plane,
u16 orig_width, u16 orig_height,
u16 out_width, u16 out_height,
@@ -1249,6 +1335,9 @@ static void dispc_ovl_set_scaling_uv(enum omap_plane
plane,
int scale_x = out_width != orig_width;
int scale_y = out_height != orig_height;
+ dispc_ovl_set_accu_uv(plane, orig_width, orig_height, out_width,
+ out_height, ilace, color_mode, rotation);
+
if (!dss_has_feature(FEAT_HANDLE_UV_SEPARATE))
return;
if ((color_mode != OMAP_DSS_COLOR_YUV2
@@ -1297,9 +1386,6 @@ static void dispc_ovl_set_scaling_uv(enum omap_plane
plane,
REG_FLD_MOD(DISPC_OVL_ATTRIBUTES(plane), scale_x ? 1 : 0, 5, 5);
/* set V scaling */
REG_FLD_MOD(DISPC_OVL_ATTRIBUTES(plane), scale_y ? 1 : 0, 6, 6);
-
- dispc_ovl_set_vid_accu2_0(plane, 0x80, 0);
- dispc_ovl_set_vid_accu2_1(plane, 0x80, 0);
}
static void dispc_ovl_set_scaling(enum omap_plane plane,
--
1.7.1
--
To unsubscribe from
Re: [RFC 00/12] OMAP DMA engine conversion
On Tue, 2012-05-15 at 08:41 +0100, Russell King - ARM Linux wrote: On Tue, May 15, 2012 at 09:49:24AM +0530, Vinod Koul wrote: On Mon, 2012-04-23 at 17:04 +0100, Russell King - ARM Linux wrote: For the full text, please see http://lists.arm.linux.org.uk/lurker/message/20120418.100954.7fa7acf8.en.html This version contains updates for some of the comments received from the previous round, and adds the OMAP1/2 MMC and SPI drivers to the conversion. I've also added a note to feature-removal noting that the existing APIs will be removed around 2013 - I'm planning January for that at the moment. Having drivers around which are unconverted blocks further work on the DMA engine conversion, so it's actually important that we get as many drivers converted as soon as possible. Anything which isn't converted will probably have its DMA code removed, or if that results in the driver not being usable, the driver itself will be removed. This series is still in RFC mode... Hi Russell, What is the state of this series, would be good to have this merged in upcoming merge window. It's not ready for merging. While it allows some of the OMAP drivers to be converted, there's others which need changes to omap-dma.c. So, I'm _not_ planning to see this in for the upcoming merge window. Okay, Thanks for the update. I am waiting for the virtual channel support in this series. -- ~Vinod -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC 00/12] OMAP DMA engine conversion
On Tue, May 15, 2012 at 02:29:27PM +0530, Vinod Koul wrote: On Tue, 2012-05-15 at 08:41 +0100, Russell King - ARM Linux wrote: It's not ready for merging. While it allows some of the OMAP drivers to be converted, there's others which need changes to omap-dma.c. So, I'm _not_ planning to see this in for the upcoming merge window. Okay, Thanks for the update. I am waiting for the virtual channel support in this series. It's changed a little since the last post to allow it to support the tx_status semantics we discussed, and has some rudimentary and untested cyclic support. As we're in the final week before the merge window, and this stuff has not had any time in linux-next, it's rather late to think about putting it in for v3.5. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] OMAP4: Adding ID for OMAP4460 ES1.1
Hi Tony,
Could you please take this patch.
Its absence raises some issues like Errata maintenance.
Thanks,
_vr
On Thu, Apr 19, 2012 at 10:23 AM, Roger Quadros rog...@ti.com wrote:
Hi,
On 04/18/2012 07:50 PM, Tony Lindgren wrote:
Hi,
* Roger Quadros rog...@ti.com [120403 02:50]:
Hi Tony,
Could you please take this patch for the next merge? Thanks.
Yes, it seems that this is not needed as a fix for the -rc cycle?
Right, it is not needed for this -rc cycle.
If it's needed as a fix, please let me know and also describe
what breaks.
It does not fix anything but is just for the sake of correctness.
regards,
-roger
On 04/02/2012 11:59 AM, Roger Quadros wrote:
From: Chris Lalancette clalance...@gmail.com
Signed-off-by: Chris Lalancette clalance...@gmail.com
Signed-off-by: Roger Quadros rog...@ti.com
---
arch/arm/mach-omap2/id.c | 5 -
arch/arm/plat-omap/include/plat/cpu.h | 1 +
2 files changed, 5 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-omap2/id.c b/arch/arm/mach-omap2/id.c
index 0e79b7b..f139817 100644
--- a/arch/arm/mach-omap2/id.c
+++ b/arch/arm/mach-omap2/id.c
@@ -478,9 +478,12 @@ void __init omap4xxx_check_revision(void)
case 0xb94e:
switch (rev) {
case 0:
- default:
omap_revision = OMAP4460_REV_ES1_0;
break;
+ case 2:
+ default:
+ omap_revision = OMAP4460_REV_ES1_1;
+ break;
}
break;
case 0xb975:
diff --git a/arch/arm/plat-omap/include/plat/cpu.h
b/arch/arm/plat-omap/include/plat/cpu.h
index dc6a86b..4bdf14e 100644
--- a/arch/arm/plat-omap/include/plat/cpu.h
+++ b/arch/arm/plat-omap/include/plat/cpu.h
@@ -445,6 +445,7 @@ IS_OMAP_TYPE(3517, 0x3517)
#define OMAP446X_CLASS 0x44600044
#define OMAP4460_REV_ES1_0 (OMAP446X_CLASS | (0x10 8))
+#define OMAP4460_REV_ES1_1 (OMAP446X_CLASS | (0x11 8))
#define OMAP447X_CLASS 0x44700044
#define OMAP4470_REV_ES1_0 (OMAP447X_CLASS | (0x10 8))
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
~~~
Best regards,
Riazantsev Volodymyr | OMAP4 Platform | GlobalLogic Ukr.
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] ARM: OMAP4: PM: Keep static dep between MPUSS and ABE clockdomain
Commit 68523f4233de5f233478dde0a63047b4efb710b8 (ARM: OMAP4:
Workaround the OCP synchronisation issue with 32K synctimer)
does not include GP Timers in ABE domain. Since synchronization
issue is applicable to all GPTIMER[1-12], we also need to set
static dependency of MPUSS with abe_clkdm and l4_per_clkdm.
Dependency with l4_per_clkdm timers is already set in commit
12f27826bdaf56b01cbdfc8bdeb577ebc106dee3 (ARM: OMAP4: PM: Keep
static dep between MPUSS-EMIF and MPUSS-L3/L4 and DUCATI-L3).
Therefore, set static dependency of MPUSS with abe_clkdm.
Cc: Kevin Hilman khil...@ti.com
Cc: Tony Lindgren t...@atomide.com
Cc: Russell King li...@arm.linux.org.uk
Signed-off-by: Tarun Kanti DebBarma tarun.ka...@ti.com
---
arch/arm/mach-omap2/pm44xx.c |6 +-
1 files changed, 5 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-omap2/pm44xx.c b/arch/arm/mach-omap2/pm44xx.c
index 8856253..f788e98 100644
--- a/arch/arm/mach-omap2/pm44xx.c
+++ b/arch/arm/mach-omap2/pm44xx.c
@@ -146,6 +146,7 @@ static int __init omap4_pm_init(void)
int ret;
struct clockdomain *emif_clkdm, *mpuss_clkdm, *l3_1_clkdm, *l4wkup;
struct clockdomain *ducati_clkdm, *l3_2_clkdm, *l4_per_clkdm;
+ struct clockdomain *abe_clkdm;
if (!cpu_is_omap44xx())
return -ENODEV;
@@ -180,8 +181,10 @@ static int __init omap4_pm_init(void)
l4_per_clkdm = clkdm_lookup(l4_per_clkdm);
l4wkup = clkdm_lookup(l4_wkup_clkdm);
ducati_clkdm = clkdm_lookup(ducati_clkdm);
+ abe_clkdm = clkdm_lookup(abe_clkdm);
if ((!mpuss_clkdm) || (!emif_clkdm) || (!l3_1_clkdm) || (!l4wkup) ||
- (!l3_2_clkdm) || (!ducati_clkdm) || (!l4_per_clkdm))
+ (!l3_2_clkdm) || (!ducati_clkdm) || (!l4_per_clkdm) ||
+ (!abe_clkdm))
goto err2;
ret = clkdm_add_wkdep(mpuss_clkdm, emif_clkdm);
@@ -191,6 +194,7 @@ static int __init omap4_pm_init(void)
ret |= clkdm_add_wkdep(mpuss_clkdm, l4wkup);
ret |= clkdm_add_wkdep(ducati_clkdm, l3_1_clkdm);
ret |= clkdm_add_wkdep(ducati_clkdm, l3_2_clkdm);
+ ret |= clkdm_add_wkdep(mpuss_clkdm, abe_clkdm);
if (ret) {
pr_err(Failed to add MPUSS - L3/EMIF/L4PER, DUCATI - L3
wakeup dependency\n);
--
1.7.0.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: PATCH: add small infrastructure and definitions to export debugfs files for OMAP powerdomain attributes
Eric,
This looks interesting, but I'll add the linux-omap list to CC so
someone can verify if there isn't already a patch to export this.
On Tue, May 15, 2012 at 2:57 AM, eric van tassell evt...@gmail.com wrote:
- These changes make OMAP power state register fields available as
attributes per field in debugfs decoded as text with the hex value
- pwrdm_read_reg_field() might replace a lot of the explicit functions
for reading register fields and clean up the existing OMAP code a bit.
- the changes are usable via debugfs standalone or with the patch
coming for powerdebug
- I've only implemented the support for the MPU PD
- to support additional the other powerdomains all that's needed is to
add the register_def_t's and field_def_t's
Have you looked at other ARM platforms to see if they have similar
information that could be exported using in the same way? It would be
useful to export this information through a single interface to
powerdebug like in the case of regulators and clocks.
here's a screenshot:
./powerdebug -P -d
failed to initialize sensors
Power Domain Information:
***
mpu_pwrdm
context
lostcontext_dff 0:false
lostmem_l1 0:false
lostmem_l2 0:false
lostmem_ram 0:false
rstst
emulation_rst 0:false
pwrstctl
powerstate 3:on-active
logicretstate 1:whole
lowpowerstatechange 0:false
l1_retstate 1:retention
l2_retstate 1:retention
ram_retstate 1:retention
l1_onstate 3:on-active
l2_onstate 3:on-active
ram_onstate 3:on-active
pwrst
powerstatest 3:on-active
logicstatest 1:on
l1_statest 3:on-active
l2_statest 3:on-active
ram_statest 3:on-active
intransition 0:false
lastpowerstateentered 3:on-active
and the patch against Linaro 12.04 kernel is:
From 4b762379805848eebd3454d6bb344a50012069d4 Mon Sep 17 00:00:00 2001
From: Eric van Tassell evt@evtM17x.(none)
Date: Sat, 5 May 2012 15:05:48 -0500
Subject: [PATCH] + basic infrastructure for creating powerdomain attribute
files in debugfs + definitions to create the attributes for
mpu power domain
---
arch/arm/mach-omap2/pm-debug.c | 4 ++
arch/arm/mach-omap2/pm44xx.c | 3 +-
arch/arm/mach-omap2/powerdomain.c | 89
+++
arch/arm/mach-omap2/powerdomain.h | 46 +-
arch/arm/mach-omap2/powerdomain44xx.c | 23 +++
arch/arm/mach-omap2/powerdomains44xx_data.c | 85 +
arch/arm/mach-omap2/prm44xx.h | 1 +
8 files changed, 254 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach-omap2/pm-debug.c b/arch/arm/mach-omap2/pm-debug.c
index 4411163..2e365e3 100644
--- a/arch/arm/mach-omap2/pm-debug.c
+++ b/arch/arm/mach-omap2/pm-debug.c
@@ -224,6 +224,10 @@ static int __init pwrdms_setup(struct powerdomain
*pwrdm, void *dir)
(void) debugfs_create_file(suspend, S_IRUGO|S_IWUSR, d,
(void *)pwrdm, pwrdm_suspend_fops);
+#ifdef CONFIG_PM_DEBUG
+ if (d)
+ pwrdm_create_register_dirs(pwrdm, d);
+#endif // CONFIG_PM_DEBUG
return 0;
}
diff --git a/arch/arm/mach-omap2/pm44xx.c b/arch/arm/mach-omap2/pm44xx.c
index 4ab9b9d..f5c189e 100644
--- a/arch/arm/mach-omap2/pm44xx.c
+++ b/arch/arm/mach-omap2/pm44xx.c
@@ -155,7 +155,7 @@ static int __init clkdms_setup(struct clockdomain
*clkdm, void *unused)
}
-static int __init pwrdms_setup(struct powerdomain *pwrdm, void *unused)
+static int __init pwrdms_setup(struct powerdomain *pwrdm, void *arg)
{
struct power_state *pwrst;
@@ -365,6 +365,7 @@ static int __init omap4_pm_init(void)
OMAP44XX_IRQ_PRCM);
goto err2;
}
+
ret = pwrdm_for_each(pwrdms_setup, NULL);
if (ret) {
pr_err(Failed to setup powerdomains\n);
diff --git a/arch/arm/mach-omap2/powerdomain.c
b/arch/arm/mach-omap2/powerdomain.c
index 8a18d1b..b392760 100644
--- a/arch/arm/mach-omap2/powerdomain.c
+++ b/arch/arm/mach-omap2/powerdomain.c
@@ -37,6 +37,11 @@
#define PWRDM_TRACE_STATES_FLAG (131)
+#ifdef CONFIG_PM_DEBUG
+#include prm-regbits-44xx.h
+#include linux/debugfs.h
+#endif // CONFIG_PM_DEBUG
+
enum {
PWRDM_STATE_NOW = 0,
PWRDM_STATE_PREV,
@@ -201,6 +206,90 @@ static int _pwrdm_post_transition_cb(struct
powerdomain *pwrdm, void *unused)
/* Public functions */
+#ifdef CONFIG_PM_DEBUG
+/
+int pwrdm_read_reg_field(field_def_t *f)
+{
+ int
Re: [PATCH 0/2] arm: omap3: am35x: Convert emac to hwmod disable hlt when open
Hi Kevin, On 5/15/2012 4:58 AM, Kevin Hilman wrote: +Sekhar, Mark A. Greer mgr...@animalcreek.com writes: From: Mark A. Greer mgr...@animalcreek.com Paul, Kevin, These patches convert the davinci emac support for the am35x SoC to use hwmod and add enable_hlt()/disable_hlt() calls to the pm_runtime hooks for that driver. Great. I didn't look closely at the hwmod data, but the approach is right here, IMO. I have converted the davinci_emac driver to use pm_runtime but I can't formally submit it yet since it requires some changes on the mach-davinci side that haven't happened yet. I will send it as an RFC in a reply to this thread. Sekhar, are you planning to add runtime PM core support to davinci? Yes, Vaibhav is going to be working on this and will start very soon. I recommend looking at the simple OMAP1 layer that implements a basic clocks-only runtime PM layer. Thanks. I have CCed Vaibhav on this mail for his information. Regards, Sekhar -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/2] arm: omap3: am35x: Disable hlt when using Davinci EMAC
On 05/15/12 00:32, Kevin Hilman wrote:
Mark A. Greer mgr...@animalcreek.com writes:
On Mon, May 14, 2012 at 11:20:58AM +0300, Igor Grinberg wrote:
Hi Mark,
Hi Igor.
Thanks for the great work!
On 05/12/12 00:12, Mark A. Greer wrote:
From: Mark A. Greer mgr...@animalcreek.com
The am35x family of SoCs has a Davinci EMAC ethernet
controller on-chip. Unfortunately, the EMAC is unable
to wake the PRCM when there is network activity which
leads to a hung or extremely slow system when the MPU
has executed a 'wfi' instruction (because of pm_idle
or CPUidle). To prevent this, add hooks to the EMAC
pm_runtime suspend/resume calls so that hlt is disabled
whenever the EMAC is in use.
Signed-off-by: Mark A. Greer mgr...@animalcreek.com
---
arch/arm/mach-omap2/am35xx-emac.c | 44
+
arch/arm/mach-omap2/am35xx-emac.h | 16 +---
arch/arm/mach-omap2/board-am3517evm.c |3 ++-
arch/arm/mach-omap2/board-cm-t3517.c |3 ++-
4 files changed, 56 insertions(+), 10 deletions(-)
diff --git a/arch/arm/mach-omap2/am35xx-emac.c
b/arch/arm/mach-omap2/am35xx-emac.c
index 3bb5cb3..22ff968 100644
--- a/arch/arm/mach-omap2/am35xx-emac.c
+++ b/arch/arm/mach-omap2/am35xx-emac.c
@@ -23,6 +23,37 @@
#include control.h
#include am35xx-emac.h
+/*
+ * Default pm_lats for the am35x.
+ * The net effect of using am35xx_emac_pm_lats[] is that
+ * pm_idle or CPUidle won't be called while the emac
+ * interface is open. This is required because the
+ * EMAC can't wake up PRCM so if the MPU is executing
+ * a 'wfi' instruction (e.g., from pm_idle or CPUidle),
+ * it won't break out of it due to emac activity.
+ */
+static int am35xx_emac_deactivate_func(struct omap_device *od)
+{
+ enable_hlt();
+ return omap_device_idle_hwmods(od);
+}
+
+static int am35xx_emac_activate_func(struct omap_device *od)
+{
+ disable_hlt();
+ return omap_device_enable_hwmods(od);
+}
+
+struct omap_device_pm_latency am35xx_emac_pm_lats[] = {
+ {
+ .deactivate_func= am35xx_emac_deactivate_func,
+ .activate_func = am35xx_emac_activate_func,
+ .flags = OMAP_DEVICE_LATENCY_AUTO_ADJUST,
+ },
+};
+
+int am35xx_emac_pm_lats_size = ARRAY_SIZE(am35xx_emac_pm_lats);
+
static void am35xx_enable_emac_int(void)
{
u32 regval;
@@ -61,12 +92,13 @@ static struct emac_platform_data am35xx_emac_pdata = {
static struct mdio_platform_data am35xx_mdio_pdata;
static int __init omap_davinci_emac_dev_init(struct omap_hwmod *oh,
- void *pdata, int pdata_len)
+ void *pdata, int pdata_len,
+ struct omap_device_pm_latency *pm_lats, int pm_lats_size)
{
struct platform_device *pdev;
pdev = omap_device_build(oh-class-name, 0, oh, pdata, pdata_len,
- NULL, 0, false);
+ pm_lats, pm_lats_size, false);
if (IS_ERR(pdev)) {
WARN(1, Can't build omap_device for %s:%s.\n,
oh-class-name, oh-name);
@@ -76,7 +108,8 @@ static int __init omap_davinci_emac_dev_init(struct
omap_hwmod *oh,
return 0;
}
-void __init am35xx_emac_init(unsigned long mdio_bus_freq, u8 rmii_en)
+void __init am35xx_emac_init(unsigned long mdio_bus_freq, u8 rmii_en,
+ struct omap_device_pm_latency *pm_lats, int pm_lats_size)
{
struct omap_hwmod *oh;
u32 regval;
@@ -91,7 +124,7 @@ void __init am35xx_emac_init(unsigned long
mdio_bus_freq, u8 rmii_en)
am35xx_mdio_pdata.bus_freq = mdio_bus_freq;
ret = omap_davinci_emac_dev_init(oh, am35xx_mdio_pdata,
- sizeof(am35xx_mdio_pdata));
+ sizeof(am35xx_mdio_pdata), NULL, 0);
if (ret) {
pr_err(Could not build davinci_mdio hwmod device\n);
return;
@@ -106,7 +139,8 @@ void __init am35xx_emac_init(unsigned long
mdio_bus_freq, u8 rmii_en)
am35xx_emac_pdata.rmii_en = rmii_en;
ret = omap_davinci_emac_dev_init(oh, am35xx_emac_pdata,
- sizeof(am35xx_emac_pdata));
+ sizeof(am35xx_emac_pdata),
+ pm_lats, pm_lats_size);
if (ret) {
pr_err(Could not build davinci_emac hwmod device\n);
return;
diff --git a/arch/arm/mach-omap2/am35xx-emac.h
b/arch/arm/mach-omap2/am35xx-emac.h
index 15c6f9c..7c23808 100644
--- a/arch/arm/mach-omap2/am35xx-emac.h
+++ b/arch/arm/mach-omap2/am35xx-emac.h
@@ -6,10 +6,20 @@
* published by the Free Software Foundation.
*/
+#include plat/omap_device.h
+
#define AM35XX_DEFAULT_MDIO_FREQUENCY 100
-#if defined(CONFIG_TI_DAVINCI_EMAC) ||
defined(CONFIG_TI_DAVINCI_EMAC_MODULE)
-void am35xx_emac_init(unsigned long mdio_bus_freq, u8 rmii_en);
+#if IS_ENABLED(CONFIG_TI_DAVINCI_EMAC)
+extern struct omap_device_pm_latency
Re: [PATCH] OMAPDSS: DISPC: Update Accumulator configuration for chroma plane
On Tue, 2012-05-15 at 13:34 +0530, Chandrabhanu Mahapatra wrote:
DISPC has two accumulator registers DISPC_VIDp_ACCU_0 and DISPC_VIDp_ACCU_1
each
with horizontal and vertical bit fields. The bit fields can take values in the
range of -1024 to 1023. Based on bit field values DISPC decides on which one
out
of 8 phases the filtering starts. DISPC_VIDp_ACCU_0 is used for progressive
output and for interlaced output both DISPC_VIDp_ACCU_0 and DISPC_VIDp_ACCU_1
are used.
The current accumulator values in DISPC scaling logic for chroma plane takes
default values for all color modes and rotation types. So, the horizontal and
vertical up and downsampling accumulator bit field values have been updated
for
better performance.
Signed-off-by: Chandrabhanu Mahapatra cmahapa...@ti.com
---
@@ -1249,6 +1335,9 @@ static void dispc_ovl_set_scaling_uv(enum omap_plane
plane,
int scale_x = out_width != orig_width;
int scale_y = out_height != orig_height;
+ dispc_ovl_set_accu_uv(plane, orig_width, orig_height, out_width,
+ out_height, ilace, color_mode, rotation);
+
if (!dss_has_feature(FEAT_HANDLE_UV_SEPARATE))
return;
if ((color_mode != OMAP_DSS_COLOR_YUV2
This crashes if color mode is not yuv or nv.
Should the set_accu_uv call be a bit later, after these lines:
if (!dss_has_feature(FEAT_HANDLE_UV_SEPARATE))
return;
if ((color_mode != OMAP_DSS_COLOR_YUV2
color_mode != OMAP_DSS_COLOR_UYVY
color_mode != OMAP_DSS_COLOR_NV12)) {
/* reset chroma resampling for RGB formats */
REG_FLD_MOD(DISPC_OVL_ATTRIBUTES2(plane), 0, 8, 8);
return;
}
Tomi
signature.asc
Description: This is a digitally signed message part
Re: oprofile and ARM A9 hardware counter
On Sat, May 12, 2012 at 12:51:00AM +0100, Jon Hunter wrote: On 05/11/2012 11:38 AM, Will Deacon wrote: Excellent, that works for me. Once we've worked out the problem with my .config you can have my tested-by. Great! I have been looking at your .config, but I have not been able to figure out the problem so far. Do you recall what your config is based upon? I seems quite different to mine and the omap2plus_defconfig has not changed much in the last few kernel releases. Hmm, I'm honestly not sure -- it was just lying around in my home directory. Given that I know very little about OMAP, I would suspect that it's either based on the defconfig or I inherited a working kernel image from somebody else and used /proc/config.gz to build my own. Will -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: OMAP4: PM: Keep static dep between MPUSS and ABE clockdomain
+ Paul Hi Tarun, On 5/15/2012 1:42 PM, Tarun Kanti DebBarma wrote: Commit 68523f4233de5f233478dde0a63047b4efb710b8 (ARM: OMAP4: Workaround the OCP synchronisation issue with 32K synctimer) does not include GP Timers in ABE domain. Since synchronization issue is applicable to all GPTIMER[1-12], we also need to set static dependency of MPUSS with abe_clkdm and l4_per_clkdm. Dependency with l4_per_clkdm timers is already set in commit 12f27826bdaf56b01cbdfc8bdeb577ebc106dee3 (ARM: OMAP4: PM: Keep static dep between MPUSS-EMIF and MPUSS-L3/L4 and DUCATI-L3). Therefore, set static dependency of MPUSS with abe_clkdm. It seems to me that these various static dep workaround patches are more and more confusing and should require some further investigation / explanation. If we keep doing that we will end up having every clock domains always ON each time the CPU is active. This is a very brute force approach not really acceptable for mainline and for PM point of view. Here we are forcing the ABE domain to be ON each time the MPU is ON even if we do not have any timer used inside the domain. It was mostly OK to do that for the wakeup domain due to the small power impact, but doing that on the L4_PER and ABE seems a little bit too much. The fix assumes as well that the MPU is the only user of that timer. What if either DSP or IPU uses it as well? Moreover the previous 68523f4233de5f2 commit did add tons of deps that does not seems to be really justified by any HW errata AFAIK. That does not mean they are not needed, but I think we should either remove them or add some more explanation. + /* +* The dynamic dependency between MPUSS - MEMIF and +* MPUSS - L4_PER/L3_* and DUCATI - L3_* doesn't work as +* expected. The hardware recommendation is to enable static +* dependencies for these to avoid system lock ups or random crashes. +*/ + mpuss_clkdm = clkdm_lookup(mpuss_clkdm); + emif_clkdm = clkdm_lookup(l3_emif_clkdm); + l3_1_clkdm = clkdm_lookup(l3_1_clkdm); + l3_2_clkdm = clkdm_lookup(l3_2_clkdm); + l4_per_clkdm = clkdm_lookup(l4_per_clkdm); + ducati_clkdm = clkdm_lookup(ducati_clkdm); + if ((!mpuss_clkdm) || (!emif_clkdm) || (!l3_1_clkdm) || + (!l3_2_clkdm) || (!ducati_clkdm) || (!l4_per_clkdm)) + goto err2; + + ret = clkdm_add_wkdep(mpuss_clkdm, emif_clkdm); AFAIK, this one is the only one covered by an errata. It might be good to add a comment to explained the issue. + ret |= clkdm_add_wkdep(mpuss_clkdm, l3_1_clkdm); + ret |= clkdm_add_wkdep(mpuss_clkdm, l3_2_clkdm); + ret |= clkdm_add_wkdep(mpuss_clkdm, l4_per_clkdm); + ret |= clkdm_add_wkdep(ducati_clkdm, l3_1_clkdm); + ret |= clkdm_add_wkdep(ducati_clkdm, l3_2_clkdm); Do we have errata for any of these ones? There is as well a confusion in the way the dep is explained. The dep is from a domain to a other one. Just saying a dep between domains is thus confusing. We do not know what is the initiator and what is the source. To add on top of that confusion, the API seems to explain the reverse dep. * clkdm_add_wkdep - add a wakeup dependency from clkdm2 to clkdm1 * @clkdm1: wake this struct clockdomain * up (dependent) * @clkdm2: when this struct clockdomain * wakes up (source) Reading that you are implementing a dep from ABE to MPU. + ret |= clkdm_add_wkdep(mpuss_clkdm, abe_clkdm); Which is clearly not what is done, since the HW setting is correct at the end. The API is setting the CM_MPU_STATICDEP.ABE_STATDEP bit. Meaning a dep from MPU domain toward target ABE domain. I guess the kerneldoc has to be updated. Paul, That sounds like an OMAP3 legacy stuff, isn't it? OMAP4 does not have these separate wkup / sleep dep anymore but only domain dep. Regards, Benoit -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 5/6] ARM: OMAP4: CLKDM: Update supported transition modes
Hi Santosh, Benoit, On 05/10/2012 01:54 AM, Santosh Shilimkar wrote: On Thursday 10 May 2012 03:06 AM, Jon Hunter wrote: From: Jon Hunter jon-hun...@ti.com For OMAP3+ devices, the clock domains (CLKDMs) support one or more of the following transition modes ... NO_SLEEP (0x0) - A clock domain sleep transition is never initiated, irrespective of the hardware conditions. SW_SLEEP (0x1) - A software-forced sleep transition. The transition is initiated when the associated hardware conditions are satisfied SW_WKUP (0x2) - A software-forced clock domain wake-up transition is initiated, irrespective of the hardware conditions. HW_AUTO (0x3) - Hardware-controlled automatic sleep and wake-up transition is initiated by the PRCM module when the associated hardware conditions are satisfied. For OMAP4 devices, SW_SLEEP is equivalent to HW_AUTO and NO_SLEEP is equivalent to SW_WKUP. For OMAP4 devices, all CLKDMs support HW_AUTO and therefore we can place the CLKDMs in the HW_AUTO state instead of the SW_SLEEP mode. Hence, we do not need to use the SW_SLEEP mode. With regard to NO_SLEEP and SW_WKUP it is preferred to use SW_WKUP mode if the CLKDM supports it and so use this mode instead of NO_SLEEP where possible. For a software perspective the above 4 modes are represented by the following flags to indicate what modes are supported by each of the CLKDMs. CLKDM_CAN_DISABLE_AUTO -- NO_SLEEP CLKDM_CAN_ENABLE_AUTO-- HW_AUTO CLKDM_CAN_FORCE_SLEEP-- SW_SLEEP CLKDM_CAN_FORCE_WAKEUP -- SW_WKUP By eliminating the SW_SLEEP mode the the mapping of the flags for OMAP4 devices can becomes ... CLKDM_CAN_DISABLE_AUTO -- NO_SLEEP CLKDM_CAN_ENABLE_AUTO-- HW_AUTO CLKDM_CAN_FORCE_SLEEP-- HW_AUTO Not sure if this can be entirely correct for OMAP4. Because HW_AUTO = Sleep and wakeup transition are based upon hardware conditions Where as SW_SLEEP = Start a software forced sleep transition on the domain. I will reply on the the thread where this is being discussed. Given that feedback we received that the only difference between HW_AUTO and SW_SLEEP is that the PRM_IRQSTATUS_MPU.TRANSITION_ST interrupt status is set in case of SW_SLEEP transition, and not set in case of HW_AUTO transition. Are you ok with this change? If so can you sign-off on this? I can update the series with all the comments and re-post this week. Cheers Jon -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 4/6] ARM: OMAP4: PMU: Add runtime PM support
Hi Ming, On 05/14/2012 11:53 PM, Ming Lei wrote: On Thu, May 10, 2012 at 5:35 AM, Jon Hunter jon-hun...@ti.com wrote: From: Jon Hunter jon-hun...@ti.com This patch is based upon Ming Lei's patch to add runtime PM support for OMAP4 [1]. In Ming's original patch the CTI interrupts were being enabled during runtime when the PMU was used but they were only configured once during init. Therefore move the configuration of the CTI interrupts to the runtime PM functions. As Shilimkar pointed out, you need to give the reason why the change is introduced in the patch. Yes will do. I have been waiting to get some feedback on HW_AUTO versus SW_SLEEP from design before posting a V2. I will enhance the changelog. Cheers Jon -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 5/6] ARM: OMAP4: CLKDM: Update supported transition modes
Hi Jon, On 5/15/2012 4:33 PM, Jon Hunter wrote: Hi Santosh, Benoit, On 05/10/2012 01:54 AM, Santosh Shilimkar wrote: On Thursday 10 May 2012 03:06 AM, Jon Hunter wrote: From: Jon Hunterjon-hun...@ti.com For OMAP3+ devices, the clock domains (CLKDMs) support one or more of the following transition modes ... NO_SLEEP (0x0) - A clock domain sleep transition is never initiated, irrespective of the hardware conditions. SW_SLEEP (0x1) - A software-forced sleep transition. The transition is initiated when the associated hardware conditions are satisfied SW_WKUP (0x2) - A software-forced clock domain wake-up transition is initiated, irrespective of the hardware conditions. HW_AUTO (0x3) - Hardware-controlled automatic sleep and wake-up transition is initiated by the PRCM module when the associated hardware conditions are satisfied. For OMAP4 devices, SW_SLEEP is equivalent to HW_AUTO and NO_SLEEP is equivalent to SW_WKUP. For OMAP4 devices, all CLKDMs support HW_AUTO and therefore we can place the CLKDMs in the HW_AUTO state instead of the SW_SLEEP mode. Hence, we do not need to use the SW_SLEEP mode. With regard to NO_SLEEP and SW_WKUP it is preferred to use SW_WKUP mode if the CLKDM supports it and so use this mode instead of NO_SLEEP where possible. For a software perspective the above 4 modes are represented by the following flags to indicate what modes are supported by each of the CLKDMs. CLKDM_CAN_DISABLE_AUTO -- NO_SLEEP CLKDM_CAN_ENABLE_AUTO -- HW_AUTO CLKDM_CAN_FORCE_SLEEP -- SW_SLEEP CLKDM_CAN_FORCE_WAKEUP -- SW_WKUP By eliminating the SW_SLEEP mode the the mapping of the flags for OMAP4 devices can becomes ... CLKDM_CAN_DISABLE_AUTO -- NO_SLEEP CLKDM_CAN_ENABLE_AUTO -- HW_AUTO CLKDM_CAN_FORCE_SLEEP -- HW_AUTO Not sure if this can be entirely correct for OMAP4. Because HW_AUTO = Sleep and wakeup transition are based upon hardware conditions Where as SW_SLEEP = Start a software forced sleep transition on the domain. I will reply on the the thread where this is being discussed. Given that feedback we received that the only difference between HW_AUTO and SW_SLEEP is that the PRM_IRQSTATUS_MPU.TRANSITION_ST interrupt status is set in case of SW_SLEEP transition, and not set in case of HW_AUTO transition. Are you ok with this change? If so can you sign-off on this? Yep I'm OK with that, but Paul is the only one who can sign-off this patch. Reviewed-by: Benoit Cousson b-cous...@ti.com Regards, Benoit -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 5/6] ARM: OMAP4: CLKDM: Update supported transition modes
On Tue, May 15, 2012 at 8:10 PM, Cousson, Benoit b-cous...@ti.com wrote: Hi Jon, On 5/15/2012 4:33 PM, Jon Hunter wrote: Hi Santosh, Benoit, On 05/10/2012 01:54 AM, Santosh Shilimkar wrote: On Thursday 10 May 2012 03:06 AM, Jon Hunter wrote: From: Jon Hunterjon-hun...@ti.com For OMAP3+ devices, the clock domains (CLKDMs) support one or more of the following transition modes ... NO_SLEEP (0x0) - A clock domain sleep transition is never initiated, irrespective of the hardware conditions. SW_SLEEP (0x1) - A software-forced sleep transition. The transition is initiated when the associated hardware conditions are satisfied SW_WKUP (0x2) - A software-forced clock domain wake-up transition is initiated, irrespective of the hardware conditions. HW_AUTO (0x3) - Hardware-controlled automatic sleep and wake-up transition is initiated by the PRCM module when the associated hardware conditions are satisfied. For OMAP4 devices, SW_SLEEP is equivalent to HW_AUTO and NO_SLEEP is equivalent to SW_WKUP. For OMAP4 devices, all CLKDMs support HW_AUTO and therefore we can place the CLKDMs in the HW_AUTO state instead of the SW_SLEEP mode. Hence, we do not need to use the SW_SLEEP mode. With regard to NO_SLEEP and SW_WKUP it is preferred to use SW_WKUP mode if the CLKDM supports it and so use this mode instead of NO_SLEEP where possible. For a software perspective the above 4 modes are represented by the following flags to indicate what modes are supported by each of the CLKDMs. CLKDM_CAN_DISABLE_AUTO -- NO_SLEEP CLKDM_CAN_ENABLE_AUTO -- HW_AUTO CLKDM_CAN_FORCE_SLEEP -- SW_SLEEP CLKDM_CAN_FORCE_WAKEUP -- SW_WKUP By eliminating the SW_SLEEP mode the the mapping of the flags for OMAP4 devices can becomes ... CLKDM_CAN_DISABLE_AUTO -- NO_SLEEP CLKDM_CAN_ENABLE_AUTO -- HW_AUTO CLKDM_CAN_FORCE_SLEEP -- HW_AUTO Not sure if this can be entirely correct for OMAP4. Because HW_AUTO = Sleep and wakeup transition are based upon hardware conditions Where as SW_SLEEP = Start a software forced sleep transition on the domain. I will reply on the the thread where this is being discussed. Given that feedback we received that the only difference between HW_AUTO and SW_SLEEP is that the PRM_IRQSTATUS_MPU.TRANSITION_ST interrupt status is set in case of SW_SLEEP transition, and not set in case of HW_AUTO transition. Are you ok with this change? If so can you sign-off on this? Yep I'm OK with that, but Paul is the only one who can sign-off this patch. Reviewed-by: Benoit Cousson b-cous...@ti.com Am OK as well. Reviewed-by: Santosh Shilimkar santosh.shilim...@ti.com -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 0/3] GPMC NAND isr using standard API
Hi Tony, Artem, This series creates a fictitious GPMC interrupt chip and provide the clients with interrupts that could be handled using standard APIs. This helps in removing the requirement of driver of peripheral connected to GPMC having the knowledge about GPMC. The only user is OMAP NAND driver, it has also been modified to use interrupts provided by imaginary GPMC chip. This series has a dependency on [2], while [2] has a trivial dependency on [1]. With this series plus [1,2], GPMC driver conversion which is going to happen shortly will not create noticable effect outside of arch/arm/*omap*/. If this series along with [1,2] can be taken in for 3.5, ripples felt by MTD drivers upon GPMC driver conversion would be minimal. Regards Afzal [1] http://www.mail-archive.com/linux-omap@vger.kernel.org/msg68581.html [2] http://www.mail-archive.com/linux-omap@vger.kernel.org/msg68652.html Afzal Mohammed (3): ARM: OMAP2+: gpmc: Modify interrupt handling ARM: OMAP2+: gpmc-nand: Modify Interrupt handling mtd: nand: omap2: use gpmc provided irqs arch/arm/mach-omap2/gpmc-nand.c| 28 +-- arch/arm/mach-omap2/gpmc.c | 137 arch/arm/plat-omap/include/plat/gpmc.h |1 + drivers/mtd/nand/omap2.c | 70 +--- 4 files changed, 185 insertions(+), 51 deletions(-) -- 1.7.10 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/3] ARM: OMAP2+: gpmc: Modify interrupt handling
Modify interrupt handling such that interrupts can be handled by GPMC
client drivers using standard interrupt APIs rather than requiring
the drivers to have knowledge about GPMC interrupt handling. Currently
only NAND related interrupts has been considered (which is the case
even without this change) as the only user of GPMC interrupt is NAND.
This helps in smooth migration of GPMC to driver.
Signed-off-by: Afzal Mohammed af...@ti.com
---
arch/arm/mach-omap2/gpmc.c | 137
arch/arm/plat-omap/include/plat/gpmc.h |1 +
2 files changed, 121 insertions(+), 17 deletions(-)
diff --git a/arch/arm/mach-omap2/gpmc.c b/arch/arm/mach-omap2/gpmc.c
index a409a3e..2b9aad1 100644
--- a/arch/arm/mach-omap2/gpmc.c
+++ b/arch/arm/mach-omap2/gpmc.c
@@ -78,6 +78,20 @@
#define ENABLE_PREFETCH(0x1 7)
#define DMA_MPU_MODE 2
+/* TODO: Handle waitpin interrupts also. Present boards make use of only NAND
+ * interrupts, hence only NAND interrupts has been considered
+ */
+#defineGPMC_NR_IRQ 2
+
+struct gpmc_client_irq {
+ unsignedirq;
+ u32 bitmask;
+};
+
+static struct gpmc_client_irq gpmc_client_irq[GPMC_NR_IRQ];
+static struct irq_chip gpmc_irq_chip;
+static unsigned gpmc_irq_start;
+
/* Structure to save gpmc cs context */
struct gpmc_cs_config {
u32 config1;
@@ -702,6 +716,97 @@ void gpmc_update_nand_reg(struct gpmc_nand_regs *reg, int
cs)
reg-gpmc_bch_result0 = gpmc_base + GPMC_ECC_BCH_RESULT_0;
}
+int gpmc_get_client_irq(unsigned irq_config)
+{
+ int i;
+
+ if (hweight32(irq_config) 1)
+ return 0;
+
+ for (i = 0; i GPMC_NR_IRQ; i++)
+ if (gpmc_client_irq[i].bitmask irq_config)
+ return gpmc_client_irq[i].irq;
+
+ return 0;
+}
+
+static int gpmc_irq_endis(unsigned irq, bool endis)
+{
+ int i;
+ u32 regval;
+
+ for (i = 0; i GPMC_NR_IRQ; i++)
+ if (irq == gpmc_client_irq[i].irq) {
+ regval = gpmc_read_reg(GPMC_IRQENABLE);
+ if (endis)
+ regval |= gpmc_client_irq[i].bitmask;
+ else
+ regval = ~gpmc_client_irq[i].bitmask;
+ gpmc_write_reg(GPMC_IRQENABLE, regval);
+ break;
+ }
+
+ return 0;
+}
+
+static void gpmc_irq_disable(struct irq_data *p)
+{
+ gpmc_irq_endis(p-irq, false);
+}
+
+static void gpmc_irq_enable(struct irq_data *p)
+{
+ gpmc_irq_endis(p-irq, true);
+}
+
+static void gpmc_irq_noop(struct irq_data *data) { }
+
+static unsigned int gpmc_irq_noop_ret(struct irq_data *data) { return 0; }
+
+static int gpmc_setup_irq(int gpmc_irq)
+{
+ int i;
+ u32 regval;
+
+ if (!gpmc_irq)
+ return -EINVAL;
+
+ gpmc_irq_start = irq_alloc_descs(-1, 0, GPMC_NR_IRQ, 0);
+ if (IS_ERR_VALUE(gpmc_irq_start)) {
+ pr_err(irq_alloc_descs failed\n);
+ return gpmc_irq_start;
+ }
+
+ gpmc_irq_chip.name = gpmc;
+ gpmc_irq_chip.irq_startup = gpmc_irq_noop_ret;
+ gpmc_irq_chip.irq_enable = gpmc_irq_enable;
+ gpmc_irq_chip.irq_disable = gpmc_irq_disable;
+ gpmc_irq_chip.irq_shutdown = gpmc_irq_noop;
+ gpmc_irq_chip.irq_ack = gpmc_irq_noop;
+ gpmc_irq_chip.irq_mask = gpmc_irq_noop;
+ gpmc_irq_chip.irq_unmask = gpmc_irq_noop;
+
+ gpmc_client_irq[0].bitmask = GPMC_IRQ_FIFOEVENTENABLE;
+ gpmc_client_irq[1].bitmask = GPMC_IRQ_COUNT_EVENT;
+
+ for (i = 0; i GPMC_NR_IRQ; i++) {
+ gpmc_client_irq[i].irq = gpmc_irq_start + i;
+ irq_set_chip_and_handler(gpmc_client_irq[i].irq,
+ gpmc_irq_chip, handle_simple_irq);
+ set_irq_flags(gpmc_client_irq[i].irq,
+ IRQF_VALID | IRQF_NOAUTOEN);
+ }
+
+ /* Disable interrupts */
+ gpmc_write_reg(GPMC_IRQENABLE, 0);
+
+ /* clear interrupts */
+ regval = gpmc_read_reg(GPMC_IRQSTATUS);
+ gpmc_write_reg(GPMC_IRQSTATUS, regval);
+
+ return request_irq(gpmc_irq, gpmc_handle_irq, 0, gpmc, NULL);
+}
+
static void __init gpmc_mem_init(void)
{
int cs;
@@ -731,8 +836,8 @@ static void __init gpmc_mem_init(void)
static int __init gpmc_init(void)
{
- u32 l, irq;
- int cs, ret = -EINVAL;
+ u32 l;
+ int ret = -EINVAL;
int gpmc_irq;
char *ck = NULL;
@@ -780,16 +885,7 @@ static int __init gpmc_init(void)
gpmc_write_reg(GPMC_SYSCONFIG, l);
gpmc_mem_init();
- /* initalize the irq_chained */
- irq = OMAP_GPMC_IRQ_BASE;
- for (cs = 0; cs GPMC_CS_NUM; cs++) {
- irq_set_chip_and_handler(irq, dummy_irq_chip,
-
[PATCH 2/3] ARM: OMAP2+: gpmc-nand: Modify Interrupt handling
Now GPMC provides its client with interrupts that can be handled
using the standard interrupt API. Modify GPMC NAND setup to work
with it.
Also disable write protect in GPMC code, so that NAND driver can
be ignorant of GPMC configuration.
This helps in smooth migration of GPMC to driver.
Signed-off-by: Afzal Mohammed af...@ti.com
---
arch/arm/mach-omap2/gpmc-nand.c | 28 ++--
1 file changed, 22 insertions(+), 6 deletions(-)
diff --git a/arch/arm/mach-omap2/gpmc-nand.c b/arch/arm/mach-omap2/gpmc-nand.c
index c0320d2..e58f450 100644
--- a/arch/arm/mach-omap2/gpmc-nand.c
+++ b/arch/arm/mach-omap2/gpmc-nand.c
@@ -21,15 +21,25 @@
#include plat/board.h
#include plat/gpmc.h
-static struct resource gpmc_nand_resource = {
- .flags = IORESOURCE_MEM,
+static struct resource gpmc_nand_resource[] = {
+ {
+ .flags = IORESOURCE_MEM,
+ },
+ {
+ .name = fifoevent,
+ .flags = IORESOURCE_IRQ,
+ },
+ {
+ .name = terminalcount,
+ .flags = IORESOURCE_IRQ,
+ },
};
static struct platform_device gpmc_nand_device = {
.name = omap2-nand,
.id = 0,
- .num_resources = 1,
- .resource = gpmc_nand_resource,
+ .num_resources = ARRAY_SIZE(gpmc_nand_resource),
+ .resource = gpmc_nand_resource,
};
static int omap2_nand_gpmc_retime(struct omap_nand_platform_data
*gpmc_nand_data)
@@ -75,6 +85,7 @@ static int omap2_nand_gpmc_retime(struct
omap_nand_platform_data *gpmc_nand_data
gpmc_cs_configure(gpmc_nand_data-cs, GPMC_CONFIG_DEV_SIZE, 0);
gpmc_cs_configure(gpmc_nand_data-cs,
GPMC_CONFIG_DEV_TYPE, GPMC_DEVICETYPE_NAND);
+ gpmc_cs_configure(gpmc_nand_data-cs, GPMC_CONFIG_WP, 0);
err = gpmc_cs_set_timings(gpmc_nand_data-cs, t);
if (err)
return err;
@@ -90,14 +101,19 @@ int __init gpmc_nand_init(struct omap_nand_platform_data
*gpmc_nand_data)
gpmc_nand_device.dev.platform_data = gpmc_nand_data;
err = gpmc_cs_request(gpmc_nand_data-cs, NAND_IO_SIZE,
- (unsigned long *)gpmc_nand_resource.start);
+ (unsigned long *)gpmc_nand_resource[0].start);
if (err 0) {
dev_err(dev, Cannot request GPMC CS\n);
return err;
}
- gpmc_nand_resource.end = gpmc_nand_resource.start + NAND_IO_SIZE - 1;
+ gpmc_nand_resource[0].end = gpmc_nand_resource[0].start +
+ NAND_IO_SIZE - 1;
+ gpmc_nand_resource[1].start =
+ gpmc_get_client_irq(GPMC_IRQ_FIFOEVENTENABLE);
+ gpmc_nand_resource[2].start =
+ gpmc_get_client_irq(GPMC_IRQ_COUNT_EVENT);
/* Set timings in GPMC */
err = omap2_nand_gpmc_retime(gpmc_nand_data);
if (err 0) {
--
1.7.10
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 3/3] mtd: nand: omap2: use gpmc provided irqs
GPMC driver provides it's clients with interrupts that can be used
through struct resource. Make use of it for irq mode functionality.
Also now write protect disable is done by GPMC code, hence remove it.
Signed-off-by: Afzal Mohammed af...@ti.com
---
drivers/mtd/nand/omap2.c | 70 +++---
1 file changed, 42 insertions(+), 28 deletions(-)
diff --git a/drivers/mtd/nand/omap2.c b/drivers/mtd/nand/omap2.c
index f69ecc1..2eac7d9 100644
--- a/drivers/mtd/nand/omap2.c
+++ b/drivers/mtd/nand/omap2.c
@@ -131,7 +131,8 @@ struct omap_nand_info {
unsigned long mem_size;
struct completion comp;
int dma_ch;
- int gpmc_irq;
+ int gpmc_irq_fifo;
+ int gpmc_irq_count;
enum {
OMAP_NAND_IO_READ = 0, /* read */
OMAP_NAND_IO_WRITE, /* write */
@@ -556,14 +557,12 @@ static irqreturn_t omap_nand_irq(int this_irq, void *dev)
{
struct omap_nand_info *info = (struct omap_nand_info *) dev;
u32 bytes;
- u32 irq_stat;
- irq_stat = gpmc_read_status(GPMC_GET_IRQ_STATUS);
bytes = readl(info-reg.gpmc_prefetch_status);
bytes = GPMC_PREFETCH_STATUS_FIFO_CNT(bytes);
bytes = bytes 0xFFFC; /* io in multiple of 4 bytes */
if (info-iomode == OMAP_NAND_IO_WRITE) { /* checks for write io */
- if (irq_stat 0x2)
+ if (this_irq == info-gpmc_irq_count)
goto done;
if (info-buf_len (info-buf_len bytes))
@@ -580,20 +579,17 @@ static irqreturn_t omap_nand_irq(int this_irq, void *dev)
(u32 *)info-buf, bytes 2);
info-buf = info-buf + bytes;
- if (irq_stat 0x2)
+ if (this_irq == info-gpmc_irq_count)
goto done;
}
- gpmc_cs_configure(info-gpmc_cs, GPMC_SET_IRQ_STATUS, irq_stat);
return IRQ_HANDLED;
done:
complete(info-comp);
- /* disable irq */
- gpmc_cs_configure(info-gpmc_cs, GPMC_ENABLE_IRQ, 0);
- /* clear status */
- gpmc_cs_configure(info-gpmc_cs, GPMC_SET_IRQ_STATUS, irq_stat);
+ disable_irq_nosync(info-gpmc_irq_fifo);
+ disable_irq_nosync(info-gpmc_irq_count);
return IRQ_HANDLED;
}
@@ -627,9 +623,9 @@ static void omap_read_buf_irq_pref(struct mtd_info *mtd,
u_char *buf, int len)
goto out_copy;
info-buf_len = len;
- /* enable irq */
- gpmc_cs_configure(info-gpmc_cs, GPMC_ENABLE_IRQ,
- (GPMC_IRQ_FIFOEVENTENABLE | GPMC_IRQ_COUNT_EVENT));
+
+ enable_irq(info-gpmc_irq_count);
+ enable_irq(info-gpmc_irq_fifo);
/* waiting for read to complete */
wait_for_completion(info-comp);
@@ -677,12 +673,13 @@ static void omap_write_buf_irq_pref(struct mtd_info *mtd,
goto out_copy;
info-buf_len = len;
- /* enable irq */
- gpmc_cs_configure(info-gpmc_cs, GPMC_ENABLE_IRQ,
- (GPMC_IRQ_FIFOEVENTENABLE | GPMC_IRQ_COUNT_EVENT));
+
+ enable_irq(info-gpmc_irq_count);
+ enable_irq(info-gpmc_irq_fifo);
/* waiting for write to complete */
wait_for_completion(info-comp);
+
/* wait for data to flushed-out before reset the prefetch */
tim = 0;
limit = (loops_per_jiffy * msecs_to_jiffies(OMAP_NAND_TIMEOUT_MS));
@@ -1079,9 +1076,6 @@ static int __devinit omap_nand_probe(struct
platform_device *pdev)
info-nand.options = pdata-devsize;
info-nand.options |= NAND_SKIP_BBTSCAN;
- /* NAND write protect off */
- gpmc_cs_configure(info-gpmc_cs, GPMC_CONFIG_WP, 0);
-
res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
if (res == NULL) {
err = -EINVAL;
@@ -1104,6 +1098,14 @@ static int __devinit omap_nand_probe(struct
platform_device *pdev)
goto out_release_mem_region;
}
+ info-gpmc_irq_fifo = platform_get_irq_byname(pdev, fifoevent);
+ if (info-gpmc_irq_fifo == -ENXIO)
+ dev_warn(pdev-dev, error getting FIFO IRQ\n);
+
+ info-gpmc_irq_count = platform_get_irq_byname(pdev, terminalcount);
+ if (info-gpmc_irq_count == -ENXIO)
+ dev_warn(pdev-dev, error getting TERMINALCOUNT IRQ\n);
+
info-nand.controller = info-controller;
info-nand.IO_ADDR_W = info-nand.IO_ADDR_R;
@@ -1159,17 +1161,24 @@ static int __devinit omap_nand_probe(struct
platform_device *pdev)
break;
case NAND_OMAP_PREFETCH_IRQ:
- err = request_irq(pdata-gpmc_irq,
- omap_nand_irq, IRQF_SHARED, gpmc-nand, info);
+ err = request_irq(info-gpmc_irq_fifo, omap_nand_irq,
+
Re: [PATCH] ARM: OMAP4: PM: Keep static dep between MPUSS and ABE clockdomain
On Tue, May 15, 2012 at 8:02 PM, Cousson, Benoit b-cous...@ti.com wrote: + Paul Hi Tarun, On 5/15/2012 1:42 PM, Tarun Kanti DebBarma wrote: Commit 68523f4233de5f233478dde0a63047b4efb710b8 (ARM: OMAP4: Workaround the OCP synchronisation issue with 32K synctimer) does not include GP Timers in ABE domain. Since synchronization issue is applicable to all GPTIMER[1-12], we also need to set static dependency of MPUSS with abe_clkdm and l4_per_clkdm. Dependency with l4_per_clkdm timers is already set in commit 12f27826bdaf56b01cbdfc8bdeb577ebc106dee3 (ARM: OMAP4: PM: Keep static dep between MPUSS-EMIF and MPUSS-L3/L4 and DUCATI-L3). Therefore, set static dependency of MPUSS with abe_clkdm. It seems to me that these various static dep workaround patches are more and more confusing and should require some further investigation / explanation. This is a new BUG which has not made it to errata list yet. It will make it eventually. If we keep doing that we will end up having every clock domains always ON each time the CPU is active. This is a very brute force approach not really acceptable for mainline and for PM point of view. Indeed. Here we are forcing the ABE domain to be ON each time the MPU is ON even if we do not have any timer used inside the domain. Actually the BUG is really related to timers running on 32KHz and only in that case such a WA is needed. BTW, the WA is suggested by hardware team. It was mostly OK to do that for the wakeup domain due to the small power impact, but doing that on the L4_PER and ABE seems a little bit too much. L4PER and ABE should not be set default The fix assumes as well that the MPU is the only user of that timer. What if either DSP or IPU uses it as well? Moreover the previous 68523f4233de5f2 commit did add tons of deps that does not seems to be really justified by any HW errata AFAIK. That does not mean they are not needed, but I think we should either remove them or add some more explanation. EMIF and L3 are covered as part of the errata's. Most if these static deps issues never worked properly and people ended up hacking like disable L3 when display ON etc etc. + /* + * The dynamic dependency between MPUSS - MEMIF and + * MPUSS - L4_PER/L3_* and DUCATI - L3_* doesn't work as + * expected. The hardware recommendation is to enable static + * dependencies for these to avoid system lock ups or random crashes. + */ + mpuss_clkdm = clkdm_lookup(mpuss_clkdm); + emif_clkdm = clkdm_lookup(l3_emif_clkdm); + l3_1_clkdm = clkdm_lookup(l3_1_clkdm); + l3_2_clkdm = clkdm_lookup(l3_2_clkdm); + l4_per_clkdm = clkdm_lookup(l4_per_clkdm); + ducati_clkdm = clkdm_lookup(ducati_clkdm); + if ((!mpuss_clkdm) || (!emif_clkdm) || (!l3_1_clkdm) || + (!l3_2_clkdm) || (!ducati_clkdm) || (!l4_per_clkdm)) + goto err2; + + ret = clkdm_add_wkdep(mpuss_clkdm, emif_clkdm); AFAIK, this one is the only one covered by an errata. It might be good to add a comment to explained the issue. + ret |= clkdm_add_wkdep(mpuss_clkdm, l3_1_clkdm); + ret |= clkdm_add_wkdep(mpuss_clkdm, l3_2_clkdm); + ret |= clkdm_add_wkdep(mpuss_clkdm, l4_per_clkdm); + ret |= clkdm_add_wkdep(ducati_clkdm, l3_1_clkdm); + ret |= clkdm_add_wkdep(ducati_clkdm, l3_2_clkdm); Do we have errata for any of these ones? If we forget about the latest timer issues doing the round only EMIF and L3 deps with different initiators were needed. L4PER was because of UART idle mode issue which I fixed recently. At least with that fix, L4PER should be killed. Will be good to take the latest findings on the static deps issues and update above list. These timer OCP sync issue has really created a big mess again... Timer is 3 domains. AON, ABE and L4pER and the WA suggested is static dep as if it is free. There is no other WA. Regards Santosh -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 1/3] ARM: OMAP2+: gpmc: Modify interrupt handling
Hi Tony, On Tue, May 15, 2012 at 20:08:34, Mohammed, Afzal wrote: Modify interrupt handling such that interrupts can be handled by GPMC client drivers using standard interrupt APIs rather than requiring the drivers to have knowledge about GPMC interrupt handling. Currently only NAND related interrupts has been considered (which is the case even without this change) as the only user of GPMC interrupt is NAND. : - ret = request_irq(gpmc_irq, gpmc_handle_irq, IRQF_SHARED, gpmc, NULL); If this series could not be considered for 3.5, to prevent failure of request_irq, either, 355f8ee ARM: OMAP2+: GPMC: resolve type-conversion warning from sparse, should be avoided, or diff [1] would be required, as shared irq needs dev-id. Regards Afzal [1] diff --git a/arch/arm/mach-omap2/gpmc.c b/arch/arm/mach-omap2/gpmc.c index 46b09da..9e1b726 100644 --- a/arch/arm/mach-omap2/gpmc.c +++ b/arch/arm/mach-omap2/gpmc.c @@ -768,7 +768,7 @@ static int __init gpmc_init(void) irq++; } - ret = request_irq(gpmc_irq, gpmc_handle_irq, IRQF_SHARED, gpmc, NULL); + ret = request_irq(gpmc_irq, gpmc_handle_irq, 0, gpmc, NULL); if (ret) pr_err(gpmc: irq-%d could not claim: err %d\n, gpmc_irq, ret); -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/2] arm: omap3: am35x: Disable hlt when using Davinci EMAC
On Tue, May 15, 2012 at 03:42:09PM +0300, Igor Grinberg wrote:
On 05/15/12 00:32, Kevin Hilman wrote:
Mark A. Greer mgr...@animalcreek.com writes:
On Mon, May 14, 2012 at 11:20:58AM +0300, Igor Grinberg wrote:
Hi Mark,
Hi Igor.
Thanks for the great work!
On 05/12/12 00:12, Mark A. Greer wrote:
From: Mark A. Greer mgr...@animalcreek.com
The am35x family of SoCs has a Davinci EMAC ethernet
controller on-chip. Unfortunately, the EMAC is unable
to wake the PRCM when there is network activity which
leads to a hung or extremely slow system when the MPU
has executed a 'wfi' instruction (because of pm_idle
or CPUidle). To prevent this, add hooks to the EMAC
pm_runtime suspend/resume calls so that hlt is disabled
whenever the EMAC is in use.
Signed-off-by: Mark A. Greer mgr...@animalcreek.com
---
arch/arm/mach-omap2/am35xx-emac.c | 44
+
arch/arm/mach-omap2/am35xx-emac.h | 16 +---
arch/arm/mach-omap2/board-am3517evm.c |3 ++-
arch/arm/mach-omap2/board-cm-t3517.c |3 ++-
4 files changed, 56 insertions(+), 10 deletions(-)
diff --git a/arch/arm/mach-omap2/am35xx-emac.c
b/arch/arm/mach-omap2/am35xx-emac.c
index 3bb5cb3..22ff968 100644
--- a/arch/arm/mach-omap2/am35xx-emac.c
+++ b/arch/arm/mach-omap2/am35xx-emac.c
@@ -23,6 +23,37 @@
#include control.h
#include am35xx-emac.h
+/*
+ * Default pm_lats for the am35x.
+ * The net effect of using am35xx_emac_pm_lats[] is that
+ * pm_idle or CPUidle won't be called while the emac
+ * interface is open. This is required because the
+ * EMAC can't wake up PRCM so if the MPU is executing
+ * a 'wfi' instruction (e.g., from pm_idle or CPUidle),
+ * it won't break out of it due to emac activity.
+ */
+static int am35xx_emac_deactivate_func(struct omap_device *od)
+{
+enable_hlt();
+return omap_device_idle_hwmods(od);
+}
+
+static int am35xx_emac_activate_func(struct omap_device *od)
+{
+disable_hlt();
+return omap_device_enable_hwmods(od);
+}
+
+struct omap_device_pm_latency am35xx_emac_pm_lats[] = {
+{
+.deactivate_func= am35xx_emac_deactivate_func,
+.activate_func = am35xx_emac_activate_func,
+.flags =
OMAP_DEVICE_LATENCY_AUTO_ADJUST,
+},
+};
+
+int am35xx_emac_pm_lats_size = ARRAY_SIZE(am35xx_emac_pm_lats);
+
static void am35xx_enable_emac_int(void)
{
u32 regval;
@@ -61,12 +92,13 @@ static struct emac_platform_data am35xx_emac_pdata =
{
static struct mdio_platform_data am35xx_mdio_pdata;
static int __init omap_davinci_emac_dev_init(struct omap_hwmod *oh,
-void *pdata, int pdata_len)
+void *pdata, int pdata_len,
+struct omap_device_pm_latency *pm_lats, int
pm_lats_size)
{
struct platform_device *pdev;
pdev = omap_device_build(oh-class-name, 0, oh, pdata,
pdata_len,
-NULL, 0, false);
+pm_lats, pm_lats_size, false);
if (IS_ERR(pdev)) {
WARN(1, Can't build omap_device for %s:%s.\n,
oh-class-name, oh-name);
@@ -76,7 +108,8 @@ static int __init omap_davinci_emac_dev_init(struct
omap_hwmod *oh,
return 0;
}
-void __init am35xx_emac_init(unsigned long mdio_bus_freq, u8 rmii_en)
+void __init am35xx_emac_init(unsigned long mdio_bus_freq, u8 rmii_en,
+struct omap_device_pm_latency *pm_lats, int
pm_lats_size)
{
struct omap_hwmod *oh;
u32 regval;
@@ -91,7 +124,7 @@ void __init am35xx_emac_init(unsigned long
mdio_bus_freq, u8 rmii_en)
am35xx_mdio_pdata.bus_freq = mdio_bus_freq;
ret = omap_davinci_emac_dev_init(oh, am35xx_mdio_pdata,
- sizeof(am35xx_mdio_pdata));
+ sizeof(am35xx_mdio_pdata),
NULL, 0);
if (ret) {
pr_err(Could not build davinci_mdio hwmod device\n);
return;
@@ -106,7 +139,8 @@ void __init am35xx_emac_init(unsigned long
mdio_bus_freq, u8 rmii_en)
am35xx_emac_pdata.rmii_en = rmii_en;
ret = omap_davinci_emac_dev_init(oh, am35xx_emac_pdata,
- sizeof(am35xx_emac_pdata));
+ sizeof(am35xx_emac_pdata),
+ pm_lats, pm_lats_size);
if (ret) {
pr_err(Could not build davinci_emac hwmod device\n);
return;
diff --git a/arch/arm/mach-omap2/am35xx-emac.h
b/arch/arm/mach-omap2/am35xx-emac.h
index 15c6f9c..7c23808 100644
--- a/arch/arm/mach-omap2/am35xx-emac.h
+++
Re: [PATCH] ARM: OMAP4: PM: Keep static dep between MPUSS and ABE clockdomain
On 5/15/2012 5:00 PM, Shilimkar, Santosh wrote: On Tue, May 15, 2012 at 8:02 PM, Cousson, Benoitb-cous...@ti.com wrote: + Paul Hi Tarun, On 5/15/2012 1:42 PM, Tarun Kanti DebBarma wrote: Commit 68523f4233de5f233478dde0a63047b4efb710b8 (ARM: OMAP4: Workaround the OCP synchronisation issue with 32K synctimer) does not include GP Timers in ABE domain. Since synchronization issue is applicable to all GPTIMER[1-12], we also need to set static dependency of MPUSS with abe_clkdm and l4_per_clkdm. Dependency with l4_per_clkdm timers is already set in commit 12f27826bdaf56b01cbdfc8bdeb577ebc106dee3 (ARM: OMAP4: PM: Keep static dep between MPUSS-EMIF and MPUSS-L3/L4 and DUCATI-L3). Therefore, set static dependency of MPUSS with abe_clkdm. It seems to me that these various static dep workaround patches are more and more confusing and should require some further investigation / explanation. This is a new BUG which has not made it to errata list yet. It will make it eventually. If we keep doing that we will end up having every clock domains always ON each time the CPU is active. This is a very brute force approach not really acceptable for mainline and for PM point of view. Indeed. Here we are forcing the ABE domain to be ON each time the MPU is ON even if we do not have any timer used inside the domain. Actually the BUG is really related to timers running on 32KHz and only in that case such a WA is needed. BTW, the WA is suggested by hardware team. That does not mean we have to implement it that way, or there is no other WA. HW team tends to stop investigating as soon as one WA is found. It was mostly OK to do that for the wakeup domain due to the small power impact, but doing that on the L4_PER and ABE seems a little bit too much. L4PER and ABE should not be set default Indeed. The fix assumes as well that the MPU is the only user of that timer. What if either DSP or IPU uses it as well? Moreover the previous 68523f4233de5f2 commit did add tons of deps that does not seems to be really justified by any HW errata AFAIK. That does not mean they are not needed, but I think we should either remove them or add some more explanation. EMIF and L3 are covered as part of the errata's. Most if these static deps issues never worked properly and people ended up hacking like disable L3 when display ON etc etc. Yeah, that's why we have to be more explicit because some of them were already investigated further since last year, and as you said some are already deprecated. + /* +* The dynamic dependency between MPUSS - MEMIF and +* MPUSS - L4_PER/L3_* and DUCATI - L3_* doesn't work as +* expected. The hardware recommendation is to enable static +* dependencies for these to avoid system lock ups or random crashes. +*/ + mpuss_clkdm = clkdm_lookup(mpuss_clkdm); + emif_clkdm = clkdm_lookup(l3_emif_clkdm); + l3_1_clkdm = clkdm_lookup(l3_1_clkdm); + l3_2_clkdm = clkdm_lookup(l3_2_clkdm); + l4_per_clkdm = clkdm_lookup(l4_per_clkdm); + ducati_clkdm = clkdm_lookup(ducati_clkdm); + if ((!mpuss_clkdm) || (!emif_clkdm) || (!l3_1_clkdm) || + (!l3_2_clkdm) || (!ducati_clkdm) || (!l4_per_clkdm)) + goto err2; + + ret = clkdm_add_wkdep(mpuss_clkdm, emif_clkdm); AFAIK, this one is the only one covered by an errata. It might be good to add a comment to explained the issue. + ret |= clkdm_add_wkdep(mpuss_clkdm, l3_1_clkdm); + ret |= clkdm_add_wkdep(mpuss_clkdm, l3_2_clkdm); + ret |= clkdm_add_wkdep(mpuss_clkdm, l4_per_clkdm); + ret |= clkdm_add_wkdep(ducati_clkdm, l3_1_clkdm); + ret |= clkdm_add_wkdep(ducati_clkdm, l3_2_clkdm); Do we have errata for any of these ones? If we forget about the latest timer issues doing the round only EMIF and L3 deps with different initiators were needed. Is there an errata for these ones? L4PER was because of UART idle mode issue which I fixed recently. At least with that fix, L4PER should be killed. Will be good to take the latest findings on the static deps issues and update above list. Yes, that was my point. We have to reduce that list if possible and potentially add some details to understand why these deps are needed. These timer OCP sync issue has really created a big mess again... Timer is 3 domains. AON, ABE and L4pER and the WA suggested is static dep as if it is free. There is no other WA. There is always other WA. Playing with global clock domain settings to prevent clock transition at IP level is always the easy but worst WA. A much better approach is to play with IP local idle management. At least that will ensure that the WA is applied only if the module is in use. Another one will be to read until the timer has changed its value. OK, that one will generate a huge delay that might be un-acceptable for a timer using a 32k clock, but might be doable for a one at sys_clk,
Re: v3.4-rc4 DSS PM problem (Was: Re: Problems with 3.4-rc5)
Tomi Valkeinen tomi.valkei...@ti.com writes:
On Mon, 2012-05-14 at 15:48 -0700, Kevin Hilman wrote:
Tomi Valkeinen tomi.valkei...@ti.com writes:
On Mon, 2012-05-14 at 08:36 +0100, Joe Woodward wrote:
Any news on this?
This thread seems to have gone a little quiet...
Hi,
I've been doing testing to understand the problem, but so far I don't
have any idea why things go wrong. I haven't found out any logic in
which configuration works and which doesn't. Looks to me that for some
reason the PM prevents DSS from getting data fast enough with certain
fifo thresholds.
I have two ways to avoid the problem, but I've been reluctant to make
patches for those because I feel it's just hiding the problem. One way
is to change DISPC SIDLEMODE or MIDLEMODE to disallow idle/standby. The
other is to use certain fifo threshold values, which just seem to work
for unknown reasons.
Considering that we already have a SIDLEMODE hack in DSS for omap3 when
using DSI, I wonder if the omap3 PM + DSS combination is just plain
broken, and we should disallow idle. I'm not quite sure what are the
implications of that.
I'd appreciate comments from the PM people =).
Unfortunately, without the bandwidth to dig into this deeply myself, I
don't have much to add.
Yes, that's understandable.
However, can you shed some light about the PM in OMAP3. What is it that
happens here regarding PM, which does not happen is USB gadget driver is
compiled in? Or when I set DSS to no-idle or no-standby? Something about
L3/core/memory going into idle state?
My first guess would have been that in those two cases, CORE was
prevented from going into retention, but based on what you said earlier,
it sounds like CORE is always staying on.
Just to clarify: by USB gadget, I assume you mean MUSB? (a.k.a USB OTG,
or HS USB in the TRM)? I'm a bit confused because earlier you mentioned
keeping usbhost_pwrdm active, but USB host is separate IP in its own
powerdomain, whereas USB OTG is an IP in the CORE powerdomain.
I tried to look at the debugfs/pm_debug/ files, but I couldn't see a
difference between working and non-working cases. At least the
OFF/RET/ON/etc states were not affected. Are there some other debug
files to look at? Are there power saving features that are not
observable via debug files?
There may not be a difference in the actual states being hit, but there
may be subtle differences in latencies to enter/exit the various states.
An interesting experiment would be to disable the deeper C-states in
CPUidle and see if the problem still exists. Here's a little shell
snippet to do this via sysfs:
# CPUidle: disable everything but C1
cd /sys/devices/system/cpu/cpu0/cpuidle
for state in state[1-6]*; do
if [ -e ${state} ]; then
echo 1 ${state}/disable
fi
done
As we know, it's not unheard of for various IPs to have bugs in
smart-idle mode ;)
The one thing I can say is that the reason it probably worked on earlier
kernels was because the UART driver was not actually idling, so you were
probably never hitting low power states.
There is also a change in the DSS fifos, which probably triggered this.
I think I can fall back to the old behavior.
Because of the current boot defaults, the only pwrdm that is actively
transitioning during idle is the MPU pwrdm.
So if preventing the MPU pwrdm from hitting idle makes the problem go
away, we'd need to better understand this wakeup latency constraint and
possibly code it in the DSS driver.
Kevin
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: PATCH: add small infrastructure and definitions to export debugfs files for OMAP powerdomain attributes
Hi Amit, Eric, Amit Kucheria amit.kuche...@linaro.org writes: Eric, This looks interesting, but I'll add the linux-omap list to CC so someone can verify if there isn't already a patch to export this. We used to have similar PM debug code in the kernel, but as the one who maintained it, I decided to remove it. This kind of thing is obviously very SoC specific, and therefore a major pain to maintain in the kernel for all the SoCs we support in linux-omap. In my view, this kind of raw register dump/analysis does not belong in the kernel, but rather in userspace tools. What we have been moving towards is using tracepoints in the clock/clockdomain/powerdomain layers to track state transitions in all of these layers. By analyzing the trace you can similarily see the state of each of the clocks and powerdomains. We currently don't have all of the low-level details (like context loss, logic mem state, etc.) but that is not difficult to add with some new tracepoints. I removed the in-kernel register dumping in the hope that folks would start using userspace tools perf/ftrace to do the same. Kevin -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: v3.4-rc4 DSS PM problem (Was: Re: Problems with 3.4-rc5)
Hello Tomi, On Mon, 14 May 2012, Tomi Valkeinen wrote: I've been doing testing to understand the problem, but so far I don't have any idea why things go wrong. I haven't found out any logic in which configuration works and which doesn't. Looks to me that for some reason the PM prevents DSS from getting data fast enough with certain fifo thresholds. I have two ways to avoid the problem, but I've been reluctant to make patches for those because I feel it's just hiding the problem. One way is to change DISPC SIDLEMODE or MIDLEMODE to disallow idle/standby. The other is to use certain fifo threshold values, which just seem to work for unknown reasons. Considering that we already have a SIDLEMODE hack in DSS for omap3 when using DSI, I wonder if the omap3 PM + DSS combination is just plain broken, and we should disallow idle. I'm not quite sure what are the implications of that. I'd appreciate comments from the PM people =). This may be caused by one of the DPLLs going into autoidle. This can involve a significant wakeup latency. I'd suggest looking at DPLL3, which provides the DSS interface clock, and DPLL4, which can provide the DSS functional clock. Could you try: 1. applying something like the patch at the bottom of this message and seeing if it makes any difference? 2. if #1 does not work, changing the dpll3 in the patch to dpll4 ? 3. if #2 does not work, disabling autoidle on both dpll3 and dpll4? I regret that I haven't been able to focus more on DSS issues - - Paul Date: Wed, 14 Mar 2012 17:49:43 -0600 (MDT) From: Paul Walmsley p...@pwsan.com Subject: Patch that should disable DPLL3 autoidle Test patch to disable DPLL3 autoidle. --- arch/arm/plat-omap/clock.c |7 +++ 1 files changed, 7 insertions(+), 0 deletions(-) diff --git a/arch/arm/plat-omap/clock.c b/arch/arm/plat-omap/clock.c index 567e4b5..4b02b35 100644 --- a/arch/arm/plat-omap/clock.c +++ b/arch/arm/plat-omap/clock.c @@ -351,6 +351,13 @@ int omap_clk_enable_autoidle_all(void) if (c-ops-allow_idle) c-ops-allow_idle(c); + c = clk_get(NULL, dpll3_ck); + if (c c-ops-deny_idle) + c-ops-deny_idle(c); + else + WARN(1, Cannot disable autoidle on DPLL3\n); + clk_put(c); + spin_unlock_irqrestore(clockfw_lock, flags); return 0; -- 1.7.9.1 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/4] REGULATOR: regulator driver for Palmas series chips
On Tue, May 15, 2012 at 03:12:45PM +0900, Graeme Gregory wrote: On 14/05/12 17:52, Mark Brown wrote: On Mon, May 14, 2012 at 10:58:31AM +0900, Graeme Gregory wrote: + + palmas_ldo_write(pmic-palmas, palmas_regs_info[id].ctrl_addr, reg); Could use the core regmap stuff for the LDOs too. Enable/Disable now use regmap but is_enabled cant as it reads from a different bitmask. Yeah, I did notice that and actually meant to go back and say that really your current is_enabled() ought to be get_status(). The former is supposed to return what the driver request to the hardware is, the latter is supposed to return what the physical status is. Not super critical though. signature.asc Description: Digital signature
Re: [RESEND PATCH 1/2] ARM: OMAP2+: nand: Make board_onenand_init() visible to board code
Tony Lindgren t...@atomide.com writes:
* Javier Martinez Canillas jav...@dowhile0.org [120427 02:33]:
On Wed, Apr 25, 2012 at 9:59 AM, Enric Balletbò i Serra
eballe...@gmail.com wrote:
Tony, as this is a fix ,may be included ?
Acked-by: Enric Balletbo i Serra eballe...@gmail.com
Tested-by: Enric Balletbo i Serra eballe...@gmail.com
Cheers,
Enric
Hi Tony, Russel:
This patch is a requirement for patch:
[RESEND PATCH 2/2] OMAP3: igep0020: Add support for Micron NAND Flash
storage memory
which is really important since newer IGEPv2 boards have changed their
flash memory from OneNAND to NAND.
This patch-set is necessary to make the board work, otherwise it
doesn't even boot.
Could we please include these patches?
Thanks for the patience, applying now into board branch finally.
This patch breaks the build for platforms that don't use ONENAND.
Using omap2plus_defconfig, set CONFIG_MTD_ONENAND_OMAP2=n and you'll get
the build error below[1]
By removing the static, there is now duplicate definitions in the .c and
.h files.
The solution is to remove the dummy definition from the .c file.
Tony, feel free to fold the diff below[2] into the original patch to fix
this compile problem.
Kevin
[1]
/work/kernel/omap/dev/arch/arm/mach-omap2/board-flash.c:102:111: error:
redefinition of 'board_onenand_init'
/work/kernel/omap/dev/arch/arm/mach-omap2/board-flash.h:56:51: note: previous
definition of 'board_onenand_init' was here
make[2]: *** [arch/arm/mach-omap2/board-flash.o] Error 1
make[2]: *** Waiting for unfinished jobs
make[1]: *** [arch/arm/mach-omap2] Error 2
make: *** [sub-make] Error 2
[2]
diff --git a/arch/arm/mach-omap2/board-flash.c
b/arch/arm/mach-omap2/board-flash.c
index 70a81f9..53c39d2 100644
--- a/arch/arm/mach-omap2/board-flash.c
+++ b/arch/arm/mach-omap2/board-flash.c
@@ -97,11 +97,6 @@ __init board_onenand_init(struct mtd_partition
*onenand_parts,
gpmc_onenand_init(board_onenand_data);
}
-#else
-void
-__init board_onenand_init(struct mtd_partition *nor_parts, u8 nr_parts, u8 cs)
-{
-}
#endif /* CONFIG_MTD_ONENAND_OMAP2 || CONFIG_MTD_ONENAND_OMAP2_MODULE */
#if defined(CONFIG_MTD_NAND_OMAP2) || \
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 0/2] arm: omap3: am35x: Convert emac to hwmod disable hlt when open
From: Mark A. Greer mgr...@animalcreek.com These patches convert the davinci emac support for the am35x SoC to use hwmod and add enable_hlt()/disable_hlt() calls to the pm_runtime hooks for that driver. I have converted the davinci_emac driver to use pm_runtime but I can't formally submit it yet since it requires some changes on the mach-davinci side that haven't happened yet. I will send it as an RFC in a reply to this thread. The patches are based on: git://git.pwsan.com/linux-2.6 am35xx_hwmod_data_fixes_a_3.5 Changes from v1: - patch 1/2, arm: omap3: am35x: Add Davinci EMAC/MDIO hwmod support is unchanged - patch 2/2, arm: omap3: am35x: Disable hlt when using Davinci EMAC has been reworked to keep the code as simple as possible per http://www.spinics.net/lists/linux-omap/msg70354.html Mark -- Mark A. Greer (2): arm: omap3: am35x: Add Davinci EMAC/MDIO hwmod support arm: omap3: am35x: Disable hlt when using Davinci EMAC arch/arm/mach-omap2/am35xx-emac.c | 116 ++-- arch/arm/mach-omap2/clock3xxx_data.c |2 +- arch/arm/mach-omap2/include/mach/am35xx.h |2 + arch/arm/mach-omap2/omap_hwmod_3xxx_data.c | 85 4 files changed, 163 insertions(+), 42 deletions(-) -- 1.7.9.4 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv2 1/4] MFD: palmas PMIC device support
On Tue, May 15, 2012 at 03:48:56PM +0900, Graeme Gregory wrote: Palmas is a PMIC from Texas Instruments and this is the MFD part of the driver for this chip. The PMIC has SMPS and LDO regulators, a general purpose ADC, GPIO, USB OTG mode detection, watchdog and RTC features. Reviwed-by: Mark Brown broo...@opensource.wolfsonmicro.com however this depends on some new regmap-irq changes that Graeme posted a couple of days ago and are only on regmap at the minute - Samuel, if you're OK with this I guess the easiest thing is if I apply there? signature.asc Description: Digital signature
[PATCH v2 1/2] arm: omap3: am35x: Add Davinci EMAC/MDIO hwmod support
From: Mark A. Greer mgr...@animalcreek.com
Add hwmod support for the EMAC (and MDIO)
ethernet controller that's on the am35x
family of SoC's.
Signed-off-by: Mark A. Greer mgr...@animalcreek.com
---
arch/arm/mach-omap2/am35xx-emac.c | 92 ++--
arch/arm/mach-omap2/clock3xxx_data.c |2 +-
arch/arm/mach-omap2/include/mach/am35xx.h |2 +
arch/arm/mach-omap2/omap_hwmod_3xxx_data.c | 85 +
4 files changed, 135 insertions(+), 46 deletions(-)
diff --git a/arch/arm/mach-omap2/am35xx-emac.c
b/arch/arm/mach-omap2/am35xx-emac.c
index 1f97e74..3bb5cb3 100644
--- a/arch/arm/mach-omap2/am35xx-emac.c
+++ b/arch/arm/mach-omap2/am35xx-emac.c
@@ -15,27 +15,13 @@
* General Public License for more details.
*/
-#include linux/clk.h
+#include linux/err.h
#include linux/davinci_emac.h
-#include linux/platform_device.h
-#include plat/irqs.h
+#include asm/system.h
+#include plat/omap_device.h
#include mach/am35xx.h
-
#include control.h
-
-static struct mdio_platform_data am35xx_emac_mdio_pdata;
-
-static struct resource am35xx_emac_mdio_resources[] = {
- DEFINE_RES_MEM(AM35XX_IPSS_EMAC_BASE + AM35XX_EMAC_MDIO_OFFSET, SZ_4K),
-};
-
-static struct platform_device am35xx_emac_mdio_device = {
- .name = davinci_mdio,
- .id = 0,
- .num_resources = ARRAY_SIZE(am35xx_emac_mdio_resources),
- .resource = am35xx_emac_mdio_resources,
- .dev.platform_data = am35xx_emac_mdio_pdata,
-};
+#include am35xx-emac.h
static void am35xx_enable_emac_int(void)
{
@@ -72,41 +58,57 @@ static struct emac_platform_data am35xx_emac_pdata = {
.interrupt_disable = am35xx_disable_emac_int,
};
-static struct resource am35xx_emac_resources[] = {
- DEFINE_RES_MEM(AM35XX_IPSS_EMAC_BASE, 0x3),
- DEFINE_RES_IRQ(INT_35XX_EMAC_C0_RXTHRESH_IRQ),
- DEFINE_RES_IRQ(INT_35XX_EMAC_C0_RX_PULSE_IRQ),
- DEFINE_RES_IRQ(INT_35XX_EMAC_C0_TX_PULSE_IRQ),
- DEFINE_RES_IRQ(INT_35XX_EMAC_C0_MISC_PULSE_IRQ),
-};
+static struct mdio_platform_data am35xx_mdio_pdata;
-static struct platform_device am35xx_emac_device = {
- .name = davinci_emac,
- .id = -1,
- .num_resources = ARRAY_SIZE(am35xx_emac_resources),
- .resource = am35xx_emac_resources,
- .dev= {
- .platform_data = am35xx_emac_pdata,
- },
-};
+static int __init omap_davinci_emac_dev_init(struct omap_hwmod *oh,
+ void *pdata, int pdata_len)
+{
+ struct platform_device *pdev;
+
+ pdev = omap_device_build(oh-class-name, 0, oh, pdata, pdata_len,
+ NULL, 0, false);
+ if (IS_ERR(pdev)) {
+ WARN(1, Can't build omap_device for %s:%s.\n,
+ oh-class-name, oh-name);
+ return PTR_ERR(pdev);
+ }
+
+ return 0;
+}
void __init am35xx_emac_init(unsigned long mdio_bus_freq, u8 rmii_en)
{
- unsigned int regval;
- int err;
+ struct omap_hwmod *oh;
+ u32 regval;
+ int ret;
- am35xx_emac_pdata.rmii_en = rmii_en;
- am35xx_emac_mdio_pdata.bus_freq = mdio_bus_freq;
- err = platform_device_register(am35xx_emac_device);
- if (err) {
- pr_err(AM35x: failed registering EMAC device: %d\n, err);
+ oh = omap_hwmod_lookup(davinci_mdio);
+ if (!oh) {
+ pr_err(Could not find davinci_mdio hwmod\n);
+ return;
+ }
+
+ am35xx_mdio_pdata.bus_freq = mdio_bus_freq;
+
+ ret = omap_davinci_emac_dev_init(oh, am35xx_mdio_pdata,
+sizeof(am35xx_mdio_pdata));
+ if (ret) {
+ pr_err(Could not build davinci_mdio hwmod device\n);
return;
}
- err = platform_device_register(am35xx_emac_mdio_device);
- if (err) {
- pr_err(AM35x: failed registering EMAC MDIO device: %d\n, err);
- platform_device_unregister(am35xx_emac_device);
+ oh = omap_hwmod_lookup(davinci_emac);
+ if (!oh) {
+ pr_err(Could not find davinci_emac hwmod\n);
+ return;
+ }
+
+ am35xx_emac_pdata.rmii_en = rmii_en;
+
+ ret = omap_davinci_emac_dev_init(oh, am35xx_emac_pdata,
+sizeof(am35xx_emac_pdata));
+ if (ret) {
+ pr_err(Could not build davinci_emac hwmod device\n);
return;
}
diff --git a/arch/arm/mach-omap2/clock3xxx_data.c
b/arch/arm/mach-omap2/clock3xxx_data.c
index 12c64db..f2f422e 100644
--- a/arch/arm/mach-omap2/clock3xxx_data.c
+++ b/arch/arm/mach-omap2/clock3xxx_data.c
@@ -3478,7 +3478,7 @@ static struct omap_clk omap3xxx_clks[] = {
CLK(NULL, ipss_ick, ipss_ick, CK_AM35XX),
CLK(NULL, rmii_ck, rmii_ck, CK_AM35XX),
CLK(NULL, pclk_ck,
[PATCH v2 2/2] arm: omap3: am35x: Disable hlt when using Davinci EMAC
From: Mark A. Greer mgr...@animalcreek.com
The am35x family of SoCs has a Davinci EMAC ethernet
controller on-chip. Unfortunately, the EMAC is unable
to wake the PRCM when there is network activity which
leads to a hung or extremely slow system when the MPU
has executed a 'wfi' instruction (because of pm_idle
or CPUidle). To prevent this, add hooks to the EMAC
pm_runtime suspend/resume calls so that hlt is disabled
whenever the EMAC is in use.
Signed-off-by: Mark A. Greer mgr...@animalcreek.com
---
arch/arm/mach-omap2/am35xx-emac.c | 40 +
1 file changed, 36 insertions(+), 4 deletions(-)
diff --git a/arch/arm/mach-omap2/am35xx-emac.c
b/arch/arm/mach-omap2/am35xx-emac.c
index 3bb5cb3..887a057 100644
--- a/arch/arm/mach-omap2/am35xx-emac.c
+++ b/arch/arm/mach-omap2/am35xx-emac.c
@@ -23,6 +23,35 @@
#include control.h
#include am35xx-emac.h
+/*
+ * Default pm_lats for the am35x.
+ * The net effect of using am35xx_emac_pm_lats[] is that
+ * pm_idle or CPUidle won't be called while the emac
+ * interface is open. This is required because the
+ * EMAC can't wake up PRCM so if the MPU is executing
+ * a 'wfi' instruction (e.g., from pm_idle or CPUidle),
+ * it won't break out of it due to emac activity.
+ */
+static int am35xx_emac_deactivate_func(struct omap_device *od)
+{
+ enable_hlt();
+ return omap_device_idle_hwmods(od);
+}
+
+static int am35xx_emac_activate_func(struct omap_device *od)
+{
+ disable_hlt();
+ return omap_device_enable_hwmods(od);
+}
+
+static struct omap_device_pm_latency am35xx_emac_pm_lats[] = {
+ {
+ .deactivate_func= am35xx_emac_deactivate_func,
+ .activate_func = am35xx_emac_activate_func,
+ .flags = OMAP_DEVICE_LATENCY_AUTO_ADJUST,
+ },
+};
+
static void am35xx_enable_emac_int(void)
{
u32 regval;
@@ -61,12 +90,13 @@ static struct emac_platform_data am35xx_emac_pdata = {
static struct mdio_platform_data am35xx_mdio_pdata;
static int __init omap_davinci_emac_dev_init(struct omap_hwmod *oh,
- void *pdata, int pdata_len)
+ void *pdata, int pdata_len,
+ struct omap_device_pm_latency *pm_lats, int pm_lats_size)
{
struct platform_device *pdev;
pdev = omap_device_build(oh-class-name, 0, oh, pdata, pdata_len,
- NULL, 0, false);
+ pm_lats, pm_lats_size, false);
if (IS_ERR(pdev)) {
WARN(1, Can't build omap_device for %s:%s.\n,
oh-class-name, oh-name);
@@ -91,7 +121,7 @@ void __init am35xx_emac_init(unsigned long mdio_bus_freq, u8
rmii_en)
am35xx_mdio_pdata.bus_freq = mdio_bus_freq;
ret = omap_davinci_emac_dev_init(oh, am35xx_mdio_pdata,
-sizeof(am35xx_mdio_pdata));
+sizeof(am35xx_mdio_pdata), NULL, 0);
if (ret) {
pr_err(Could not build davinci_mdio hwmod device\n);
return;
@@ -106,7 +136,9 @@ void __init am35xx_emac_init(unsigned long mdio_bus_freq,
u8 rmii_en)
am35xx_emac_pdata.rmii_en = rmii_en;
ret = omap_davinci_emac_dev_init(oh, am35xx_emac_pdata,
-sizeof(am35xx_emac_pdata));
+sizeof(am35xx_emac_pdata),
+am35xx_emac_pm_lats,
+ARRAY_SIZE(am35xx_emac_pm_lats));
if (ret) {
pr_err(Could not build davinci_emac hwmod device\n);
return;
--
1.7.9.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv2 3/4] REGULATOR: regulator driver for Palmas series chips
On Tue, May 15, 2012 at 03:48:58PM +0900, Graeme Gregory wrote: Palmas has both Switched Mode (SMPS) and Linear (LDO) regulators in it. This regulator driver allows software control of these regulators. The regulators available on Palmas series chips vary depending on the muxing. This is handled automatically in the driver by reading the mux info from OTP. This all looks good modulo the thing with is_enabled() that I mentioned which I think we can deal with incrementally - I'd apply but it depends on the MFD header :/ If Samuel is OK with me applying the MFD I'll work it out in my trees (probably by squashing the pdata into the mfd commit. signature.asc Description: Digital signature
Re: [PATCH] arm: omap3: am35x: Set proper powerdomain states
On Tue, May 15, 2012 at 09:43:52AM +0200, Jean Pihet wrote:
Hi Mark,
Hi Jean.
On Mon, Apr 30, 2012 at 11:26 PM, Mark A. Greer mgr...@animalcreek.com
wrote:
From: Mark A. Greer mgr...@animalcreek.com
The am35x family of SoCs only support the PWRSTS_ON
state so create a new set of powerdomain structures
that ensure that only the ON state is entered.
Signed-off-by: Mark A. Greer mgr...@animalcreek.com
---
void __init omap3xxx_powerdomains_init(void)
{
unsigned int rev;
@@ -301,21 +403,31 @@ void __init omap3xxx_powerdomains_init(void)
return;
pwrdm_register_platform_funcs(omap3_pwrdm_operations);
- pwrdm_register_pwrdms(powerdomains_omap3430_common);
rev = omap_rev();
- if (rev == OMAP3430_REV_ES1_0)
- pwrdm_register_pwrdms(powerdomains_omap3430es1);
- else if (rev == OMAP3430_REV_ES2_0 || rev == OMAP3430_REV_ES2_1 ||
- rev == OMAP3430_REV_ES3_0 || rev == OMAP3630_REV_ES1_0)
- pwrdm_register_pwrdms(powerdomains_omap3430es2_es3_0);
- else if (rev == OMAP3430_REV_ES3_1 || rev == OMAP3430_REV_ES3_1_2 ||
- rev == AM35XX_REV_ES1_0 || rev == AM35XX_REV_ES1_1 ||
- rev == OMAP3630_REV_ES1_1 || rev == OMAP3630_REV_ES1_2)
- pwrdm_register_pwrdms(powerdomains_omap3430es3_1plus);
- else
- WARN(1, OMAP3 powerdomain init: unknown chip type\n);
+ if (rev == AM35XX_REV_ES1_0 || rev == AM35XX_REV_ES1_1) {
+ pwrdm_register_pwrdms(powerdomains_am35x);
+ } else {
+ pwrdm_register_pwrdms(powerdomains_omap3430_common);
Is there a way to avoid the big 'if else' here and have the code
organized per chipset revision? A mutliple if-else or -even better
IMO- a switch-case would make the code more readable.
We can't avoid it completely because we have to register
powerdomains_am35x[] [exclusive] OR (powerdomains_omap3430_common[] +
extras). What I can do is leave the outside 'if' and turn the code
inside the 'else' into a switch stmt which should look nicer.
Good idea, thanks. :)
I will submit v2 in a bit.
Mark
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] arm: omap3: am35x: Set proper powerdomain states
On Tue, May 15, 2012 at 11:35:27AM -0700, Mark A. Greer wrote:
On Tue, May 15, 2012 at 09:43:52AM +0200, Jean Pihet wrote:
Hi Mark,
Hi Jean.
On Mon, Apr 30, 2012 at 11:26 PM, Mark A. Greer mgr...@animalcreek.com
wrote:
From: Mark A. Greer mgr...@animalcreek.com
The am35x family of SoCs only support the PWRSTS_ON
state so create a new set of powerdomain structures
that ensure that only the ON state is entered.
Signed-off-by: Mark A. Greer mgr...@animalcreek.com
---
void __init omap3xxx_powerdomains_init(void)
{
unsigned int rev;
@@ -301,21 +403,31 @@ void __init omap3xxx_powerdomains_init(void)
return;
pwrdm_register_platform_funcs(omap3_pwrdm_operations);
- pwrdm_register_pwrdms(powerdomains_omap3430_common);
rev = omap_rev();
- if (rev == OMAP3430_REV_ES1_0)
- pwrdm_register_pwrdms(powerdomains_omap3430es1);
- else if (rev == OMAP3430_REV_ES2_0 || rev == OMAP3430_REV_ES2_1 ||
- rev == OMAP3430_REV_ES3_0 || rev == OMAP3630_REV_ES1_0)
- pwrdm_register_pwrdms(powerdomains_omap3430es2_es3_0);
- else if (rev == OMAP3430_REV_ES3_1 || rev == OMAP3430_REV_ES3_1_2
||
- rev == AM35XX_REV_ES1_0 || rev == AM35XX_REV_ES1_1 ||
- rev == OMAP3630_REV_ES1_1 || rev == OMAP3630_REV_ES1_2)
- pwrdm_register_pwrdms(powerdomains_omap3430es3_1plus);
- else
- WARN(1, OMAP3 powerdomain init: unknown chip type\n);
+ if (rev == AM35XX_REV_ES1_0 || rev == AM35XX_REV_ES1_1) {
+ pwrdm_register_pwrdms(powerdomains_am35x);
+ } else {
+ pwrdm_register_pwrdms(powerdomains_omap3430_common);
Is there a way to avoid the big 'if else' here and have the code
organized per chipset revision? A mutliple if-else or -even better
IMO- a switch-case would make the code more readable.
We can't avoid it completely because we have to register
powerdomains_am35x[] [exclusive] OR (powerdomains_omap3430_common[] +
extras). What I can do is leave the outside 'if' and turn the code
inside the 'else' into a switch stmt which should look nicer.
Actually, I had a bug in this version where some domains weren't being
added as they should be for the am35x. I'll fix that in v2.
Mark
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: decompressor: Fix mmu mapping for non-DRAM address space.
On Wed, May 9, 2012 at 4:40 PM, Russell King - ARM Linux li...@arm.linux.org.uk wrote: On Wed, May 09, 2012 at 03:44:08PM -0500, Buckley, Bryan wrote: On Wed, May 9, 2012 at 10:48 AM, Russell King - ARM Linux li...@arm.linux.org.uk wrote: On Wed, May 09, 2012 at 06:00:10PM +0530, Shilimkar, Santosh wrote: On Wed, May 9, 2012 at 5:53 PM, Russell King - ARM Linux li...@arm.linux.org.uk wrote: On Wed, May 09, 2012 at 02:20:28PM +0530, Shilimkar, Santosh wrote: The only change done common code is clearing 'XN' bit for DRAM region in page table entries. The other change of setting the DACR register is done in ARMv7 specific code. Yes, XN is an ARMv6+ thing. Before ARMv5, it was implementation defined. Some implementations used the bit to mean allow writes to update the cache. Other implementations labelled this bit as should be zero while others labelled it as should be one. Good to know. The upshot of this is, we know that having this bit as '1' means that all the CPUs we support today work. I would be _very_ concerned to change this bit to zero as we _really_ don't know how the pre-ARMv6 CPUs would react. I agree. The solution to this is pretty simple - if ARMv6+ needs a different base section mapping value, then we need to extract that from the code and pass in the base section mapping value. I'll sort out a patch later today for this. Great. This works for my 4430SDP board. I haven't booted it on anything else yet. Please can you check that this solves the issue for you? Thanks. Solves the issue for OMAP5. Thanks Russel and company. Can I add this attributation for this patch: Tested-by: Bryan Buckley bryan.buck...@ti.com ? If still applicable, yes that is fine. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2] arm: omap3: am35x: Set proper powerdomain states
From: Mark A. Greer mgr...@animalcreek.com
The am35x family of SoCs only support the PWRSTS_ON
state so create a new set of powerdomain structures
that ensure that only the ON state is entered.
Signed-off-by: Mark A. Greer mgr...@animalcreek.com
---
This patch has been reworked as per Jean Pihet's suggestion
here: http://www.spinics.net/lists/linux-omap/msg70376.html.
The inner 'if' statement has been converted to a switch stmt.
I also removed AM35XX_REV_ES1_0 AM35XX_REV_ES1_1 from the
if/switch stmt since they shouldn't have been there in v1.
arch/arm/mach-omap2/powerdomains3xxx_data.c | 139 ---
1 file changed, 127 insertions(+), 12 deletions(-)
diff --git a/arch/arm/mach-omap2/powerdomains3xxx_data.c
b/arch/arm/mach-omap2/powerdomains3xxx_data.c
index fb0a0a6..bb883e4 100644
--- a/arch/arm/mach-omap2/powerdomains3xxx_data.c
+++ b/arch/arm/mach-omap2/powerdomains3xxx_data.c
@@ -71,6 +71,22 @@ static struct powerdomain mpu_3xxx_pwrdm = {
.voltdm = { .name = mpu_iva },
};
+static struct powerdomain mpu_am35x_pwrdm = {
+ .name = mpu_pwrdm,
+ .prcm_offs= MPU_MOD,
+ .pwrsts = PWRSTS_ON,
+ .pwrsts_logic_ret = PWRSTS_ON,
+ .flags= PWRDM_HAS_MPU_QUIRK,
+ .banks= 1,
+ .pwrsts_mem_ret = {
+ [0] = PWRSTS_ON,
+ },
+ .pwrsts_mem_on= {
+ [0] = PWRSTS_ON,
+ },
+ .voltdm = { .name = mpu_iva },
+};
+
/*
* The USBTLL Save-and-Restore mechanism is broken on
* 3430s up to ES3.0 and 3630ES1.0. Hence this feature
@@ -120,6 +136,23 @@ static struct powerdomain core_3xxx_es3_1_pwrdm = {
.voltdm = { .name = core },
};
+static struct powerdomain core_am35x_pwrdm = {
+ .name = core_pwrdm,
+ .prcm_offs= CORE_MOD,
+ .pwrsts = PWRSTS_ON,
+ .pwrsts_logic_ret = PWRSTS_ON,
+ .banks= 2,
+ .pwrsts_mem_ret = {
+ [0] = PWRSTS_ON, /* MEM1RETSTATE */
+ [1] = PWRSTS_ON, /* MEM2RETSTATE */
+ },
+ .pwrsts_mem_on= {
+ [0] = PWRSTS_ON, /* MEM1ONSTATE */
+ [1] = PWRSTS_ON, /* MEM2ONSTATE */
+ },
+ .voltdm = { .name = core },
+};
+
static struct powerdomain dss_pwrdm = {
.name = dss_pwrdm,
.prcm_offs= OMAP3430_DSS_MOD,
@@ -135,6 +168,21 @@ static struct powerdomain dss_pwrdm = {
.voltdm = { .name = core },
};
+static struct powerdomain dss_am35x_pwrdm = {
+ .name = dss_pwrdm,
+ .prcm_offs= OMAP3430_DSS_MOD,
+ .pwrsts = PWRSTS_ON,
+ .pwrsts_logic_ret = PWRSTS_ON,
+ .banks= 1,
+ .pwrsts_mem_ret = {
+ [0] = PWRSTS_ON, /* MEMRETSTATE */
+ },
+ .pwrsts_mem_on= {
+ [0] = PWRSTS_ON, /* MEMONSTATE */
+ },
+ .voltdm = { .name = core },
+};
+
/*
* Although the 34XX TRM Rev K Table 4-371 notes that retention is a
* possible SGX powerstate, the SGX device itself does not support
@@ -156,6 +204,21 @@ static struct powerdomain sgx_pwrdm = {
.voltdm = { .name = core },
};
+static struct powerdomain sgx_am35x_pwrdm = {
+ .name = sgx_pwrdm,
+ .prcm_offs= OMAP3430ES2_SGX_MOD,
+ .pwrsts = PWRSTS_ON,
+ .pwrsts_logic_ret = PWRSTS_ON,
+ .banks= 1,
+ .pwrsts_mem_ret = {
+ [0] = PWRSTS_ON, /* MEMRETSTATE */
+ },
+ .pwrsts_mem_on= {
+ [0] = PWRSTS_ON, /* MEMONSTATE */
+ },
+ .voltdm = { .name = core },
+};
+
static struct powerdomain cam_pwrdm = {
.name = cam_pwrdm,
.prcm_offs= OMAP3430_CAM_MOD,
@@ -186,6 +249,21 @@ static struct powerdomain per_pwrdm = {
.voltdm = { .name = core },
};
+static struct powerdomain per_am35x_pwrdm = {
+ .name = per_pwrdm,
+ .prcm_offs= OMAP3430_PER_MOD,
+ .pwrsts = PWRSTS_ON,
+ .pwrsts_logic_ret = PWRSTS_ON,
+ .banks= 1,
+ .pwrsts_mem_ret = {
+ [0] = PWRSTS_ON, /* MEMRETSTATE */
+ },
+ .pwrsts_mem_on= {
+ [0] = PWRSTS_ON, /* MEMONSTATE */
+ },
+ .voltdm = { .name = core },
+};
+
static struct powerdomain emu_pwrdm = {
.name = emu_pwrdm,
.prcm_offs = OMAP3430_EMU_MOD,
@@ -200,6 +278,14 @@ static struct powerdomain neon_pwrdm = {
.voltdm = { .name = mpu_iva },
};
+static struct powerdomain neon_am35x_pwrdm = {
+ .name = neon_pwrdm,
+ .prcm_offs= OMAP3430_NEON_MOD,
+ .pwrsts = PWRSTS_ON,
+ .pwrsts_logic_ret = PWRSTS_ON,
+ .voltdm
Re: [PATCHv5 1/8] ARM: OMAP4: suspend: Program all domains to retention
Tero Kristo t-kri...@ti.com writes: From: Rajendra Nayak rna...@ti.com Remove the FIXME's in the suspend sequence since we now intend to support system level RET support. minor: this should probably go at the end of the series, after retention is supported. Otherwise, ending up with only this patch applied (e.g. during a git bisect) will lead to a broken boot I suspect. Kevin Signed-off-by: Rajendra Nayak rna...@ti.com Signed-off-by: Tero Kristo t-kri...@ti.com Reviewed-by: Santosh Shilimkar santosh.shilim...@ti.com --- arch/arm/mach-omap2/pm44xx.c |6 -- 1 files changed, 0 insertions(+), 6 deletions(-) diff --git a/arch/arm/mach-omap2/pm44xx.c b/arch/arm/mach-omap2/pm44xx.c index 8856253..31990d5 100644 --- a/arch/arm/mach-omap2/pm44xx.c +++ b/arch/arm/mach-omap2/pm44xx.c @@ -101,12 +101,6 @@ static int __init pwrdms_setup(struct powerdomain *pwrdm, void *unused) if (!strncmp(pwrdm-name, cpu, 3)) return 0; - /* - * FIXME: Remove this check when core retention is supported - * Only MPUSS power domain is added in the list. - */ - if (strcmp(pwrdm-name, mpu_pwrdm)) - return 0; pwrst = kmalloc(sizeof(struct power_state), GFP_ATOMIC); if (!pwrst) -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RESEND PATCH 1/2] ARM: OMAP2+: nand: Make board_onenand_init() visible to board code
* Kevin Hilman khil...@ti.com [120515 11:17]:
Tony Lindgren t...@atomide.com writes:
* Javier Martinez Canillas jav...@dowhile0.org [120427 02:33]:
On Wed, Apr 25, 2012 at 9:59 AM, Enric Balletbò i Serra
eballe...@gmail.com wrote:
Tony, as this is a fix ,may be included ?
Acked-by: Enric Balletbo i Serra eballe...@gmail.com
Tested-by: Enric Balletbo i Serra eballe...@gmail.com
Cheers,
Enric
Hi Tony, Russel:
This patch is a requirement for patch:
[RESEND PATCH 2/2] OMAP3: igep0020: Add support for Micron NAND Flash
storage memory
which is really important since newer IGEPv2 boards have changed their
flash memory from OneNAND to NAND.
This patch-set is necessary to make the board work, otherwise it
doesn't even boot.
Could we please include these patches?
Thanks for the patience, applying now into board branch finally.
This patch breaks the build for platforms that don't use ONENAND.
Using omap2plus_defconfig, set CONFIG_MTD_ONENAND_OMAP2=n and you'll get
the build error below[1]
Thanks for catching that.
By removing the static, there is now duplicate definitions in the .c and
.h files.
The solution is to remove the dummy definition from the .c file.
Tony, feel free to fold the diff below[2] into the original patch to fix
this compile problem.
That's already merged as 8259573b (ARM: OMAP2+: nand: Make board_onenand_init()
visible to board code) so we need to apply it as a fix.
Can you do a fix with your Signed-off-by or at least reply with that
so I can apply it?
Thanks,
Tony
[1]
/work/kernel/omap/dev/arch/arm/mach-omap2/board-flash.c:102:111: error:
redefinition of 'board_onenand_init'
/work/kernel/omap/dev/arch/arm/mach-omap2/board-flash.h:56:51: note: previous
definition of 'board_onenand_init' was here
make[2]: *** [arch/arm/mach-omap2/board-flash.o] Error 1
make[2]: *** Waiting for unfinished jobs
make[1]: *** [arch/arm/mach-omap2] Error 2
make: *** [sub-make] Error 2
[2]
diff --git a/arch/arm/mach-omap2/board-flash.c
b/arch/arm/mach-omap2/board-flash.c
index 70a81f9..53c39d2 100644
--- a/arch/arm/mach-omap2/board-flash.c
+++ b/arch/arm/mach-omap2/board-flash.c
@@ -97,11 +97,6 @@ __init board_onenand_init(struct mtd_partition
*onenand_parts,
gpmc_onenand_init(board_onenand_data);
}
-#else
-void
-__init board_onenand_init(struct mtd_partition *nor_parts, u8 nr_parts, u8
cs)
-{
-}
#endif /* CONFIG_MTD_ONENAND_OMAP2 || CONFIG_MTD_ONENAND_OMAP2_MODULE */
#if defined(CONFIG_MTD_NAND_OMAP2) || \
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] pinctrl: Add generic pinctrl-simple driver that supports omap2+ padconf
* Stephen Warren swar...@wwwdotorg.org [120514 11:42]: On 05/12/2012 05:49 PM, Linus Walleij wrote: On Thu, May 10, 2012 at 7:05 PM, Stephen Warren swar...@wwwdotorg.org wrote: Also, were you intending pinctrl-simple to actually be the GPIO controller itself? That'd be another case that one might consider fairly simple, but then extends to being gpio-simple as well as pinctrl-simple... We have some pinctrl drivers implementing gpiolib too already, and it's unavoidable I think, as some recent discussion about matcing struct gpio_chip and pinctrl GPIO ranges shows. I strongly believe we should only do this when the exact same HW module is both pinctrl and GPIO. When there are separate HW modules, we should have separate drivers. The fact that the two drivers need to co-ordinate with each-other isn't a good argument to make them one driver. And irrespective of how the drivers are structured, if there are two HW modules, we really need two separate nodes in DT to describe them, since the SW architecture (1 vs. 2 drivers) shouldn't influence the DT representation unduly. Yes. Maybe -simple isn't such a good name for this thing. Noone thinks any kind of pin control is simple in any sense of the word anyway :-D Tony, would pinctrl-dt-only.c be a better name perhaps? That might be OK for the filename, but it doesn't seem like a useful change for the DT compatible value. Yeah let's see if we can come up with some better name. Regards, Tony -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RESEND PATCH 1/2] ARM: OMAP2+: nand: Make board_onenand_init() visible to board code
Tony Lindgren t...@atomide.com writes:
[...]
That's already merged as 8259573b (ARM: OMAP2+: nand: Make
board_onenand_init()
visible to board code) so we need to apply it as a fix.
Can you do a fix with your Signed-off-by or at least reply with that
so I can apply it?
Here you go. Applies to your 'board' branch.
Kevin
From f4f2c35de0e67e3b8185059ffd78be67f7096d8a Mon Sep 17 00:00:00 2001
From: Kevin Hilman khil...@ti.com
Date: Tue, 15 May 2012 13:07:20 -0700
Subject: [PATCH] ARM: OMAP2+: nand: fix build error when
CONFIG_MTD_ONENAND_OMAP2=n
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
commit 8259573b (ARM: OMAP2+: nand: Make board_onenand_init() visible
to board code) broke the build for configs with OneNAND disabled. By
removing the static in the header file, it created a duplicate definition
in the .c and the .h files, resuling in a build error:
/work/kernel/omap/dev/arch/arm/mach-omap2/board-flash.c:102:111: error:
redefinition of 'board_onenand_init'
/work/kernel/omap/dev/arch/arm/mach-omap2/board-flash.h:56:51: note: previous
definition of 'board_onenand_init' was here
make[2]: *** [arch/arm/mach-omap2/board-flash.o] Error 1
make[2]: *** Waiting for unfinished jobs
make[1]: *** [arch/arm/mach-omap2] Error 2
make: *** [sub-make] Error 2
Fix this by removing the duplicate dummy entry from the C file.
Cc: Enric Balletbò i Serra eballe...@gmail.com
Cc: Javier Martinez Canillas jav...@dowhile0.org
Signed-off-by: Kevin Hilman khil...@ti.com
---
arch/arm/mach-omap2/board-flash.c |5 -
1 file changed, 5 deletions(-)
diff --git a/arch/arm/mach-omap2/board-flash.c
b/arch/arm/mach-omap2/board-flash.c
index 70a81f9..53c39d2 100644
--- a/arch/arm/mach-omap2/board-flash.c
+++ b/arch/arm/mach-omap2/board-flash.c
@@ -97,11 +97,6 @@ __init board_onenand_init(struct mtd_partition
*onenand_parts,
gpmc_onenand_init(board_onenand_data);
}
-#else
-void
-__init board_onenand_init(struct mtd_partition *nor_parts, u8 nr_parts, u8 cs)
-{
-}
#endif /* CONFIG_MTD_ONENAND_OMAP2 || CONFIG_MTD_ONENAND_OMAP2_MODULE */
#if defined(CONFIG_MTD_NAND_OMAP2) || \
--
1.7.9.2
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Panda: USB crash with today's linux-next
* Felipe Balbi ba...@ti.com [120514 12:41]: On Mon, May 14, 2012 at 11:37:43AM -0700, Tony Lindgren wrote: * Tony Lindgren t...@atomide.com [120514 11:19]: * Felipe Balbi ba...@ti.com [120514 11:04]: That whole MMC card detection is also pretty screwed up. Balaji/Venkat, can you guys look into that ? Probably making something generic using a threaded IRQ handler ? I mean, all the MMC core should need is an IRQ number (through GPIOs or not doesn't/shouldn't matter) and it should be able to use a threaded IRQ handler to kick the card detection/initialization. That's mostly done.. Just need to update the patches for it. Mostly done meaning all the MMC core should need is an IRQ number part that is :) but you've done it for omap_hsmmc.c, right ? What I meant is that the whole card detection should be done at the MMC framework level. Yes what I did was just try to start gettting rid of the platform callbacks. I mean, if we tell MMC core what's the card detect IRQ number, it should be able to implement a generic version of omap_hsmmc_detect(). All that thing does is read the current gpio status number and call mmc_detect_change(). mmc_detect_change() then kicks a delayed work, which shouldn't be needed because omap_hsmmc_detect() (or the generic of it) is already using a threaded IRQ. Yeah maybe it's doable.. The MMC driver needs to read the status of the card insert, but maybe that should be just just gpio_get_value(). Then ideally the MMC driver would not have any knowledge how the GPIO is handled as it can come from whatever gpiochip using internal GPIO or TWL GPIO. Regards, Tony -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RESEND PATCH 1/2] ARM: OMAP2+: nand: Make board_onenand_init() visible to board code
* Kevin Hilman khil...@ti.com [120515 13:17]: Tony Lindgren t...@atomide.com writes: [...] That's already merged as 8259573b (ARM: OMAP2+: nand: Make board_onenand_init() visible to board code) so we need to apply it as a fix. Can you do a fix with your Signed-off-by or at least reply with that so I can apply it? Here you go. Applies to your 'board' branch. Thanks applying into fixes-board branch. Tony -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2] omap: dma: Clear status registers on enable/disable irq.
Use omap_disable_channel_irq() function instead of directly accessing CICR.
The omap_disable_chanel_irq() function clears pending interrupts
and disables interrupt on channel.
Functions omap2_enable_irq_lch()/omap2_disable_irq_lch() clear interrupt
status register.
Signed-off-by: Oleg Matcovschi oleg.matcovs...@ti.com
---
v1 initial revision
v2 Review by Tony Lindgren
---
arch/arm/plat-omap/dma.c | 59 +
1 files changed, 28 insertions(+), 31 deletions(-)
diff --git a/arch/arm/plat-omap/dma.c b/arch/arm/plat-omap/dma.c
index 3ec7ec5..3d5d593 100644
--- a/arch/arm/plat-omap/dma.c
+++ b/arch/arm/plat-omap/dma.c
@@ -563,22 +563,25 @@ EXPORT_SYMBOL(omap_set_dma_dest_burst_mode);
static inline void omap_enable_channel_irq(int lch)
{
- u32 status;
-
/* Clear CSR */
if (cpu_class_is_omap1())
- status = p-dma_read(CSR, lch);
- else if (cpu_class_is_omap2())
+ p-dma_read(CSR, lch);
+ else
p-dma_write(OMAP2_DMA_CSR_CLEAR_MASK, CSR, lch);
/* Enable some nice interrupts. */
p-dma_write(dma_chan[lch].enabled_irqs, CICR, lch);
}
-static void omap_disable_channel_irq(int lch)
+static inline void omap_disable_channel_irq(int lch)
{
- if (cpu_class_is_omap2())
- p-dma_write(0, CICR, lch);
+ /* disable channel interrupts */
+ p-dma_write(0, CICR, lch);
+ /* Clear CSR */
+ if (cpu_class_is_omap1())
+ p-dma_read(CSR, lch);
+ else
+ p-dma_write(OMAP2_DMA_CSR_CLEAR_MASK, CSR, lch);
}
void omap_enable_dma_irq(int lch, u16 bits)
@@ -622,14 +625,14 @@ static inline void disable_lnk(int lch)
l = p-dma_read(CLNK_CTRL, lch);
/* Disable interrupts */
+ omap_disable_channel_irq(lch);
+
if (cpu_class_is_omap1()) {
- p-dma_write(0, CICR, lch);
/* Set the STOP_LNK bit */
l |= 1 14;
}
if (cpu_class_is_omap2()) {
- omap_disable_channel_irq(lch);
/* Clear the ENABLE_LNK bit */
l = ~(1 15);
}
@@ -647,6 +650,9 @@ static inline void omap2_enable_irq_lch(int lch)
return;
spin_lock_irqsave(dma_chan_lock, flags);
+ /* clear IRQ STATUS */
+ p-dma_write(1 lch, IRQSTATUS_L0, lch);
+ /* Enable interrupt */
val = p-dma_read(IRQENABLE_L0, lch);
val |= 1 lch;
p-dma_write(val, IRQENABLE_L0, lch);
@@ -662,9 +668,12 @@ static inline void omap2_disable_irq_lch(int lch)
return;
spin_lock_irqsave(dma_chan_lock, flags);
+ /* Disable interrupt */
val = p-dma_read(IRQENABLE_L0, lch);
val = ~(1 lch);
p-dma_write(val, IRQENABLE_L0, lch);
+ /* clear IRQ STATUS */
+ p-dma_write(1 lch, IRQSTATUS_L0, lch);
spin_unlock_irqrestore(dma_chan_lock, flags);
}
@@ -735,11 +744,8 @@ int omap_request_dma(int dev_id, const char *dev_name,
}
if (cpu_class_is_omap2()) {
- omap2_enable_irq_lch(free_ch);
omap_enable_channel_irq(free_ch);
- /* Clear the CSR register and IRQ status register */
- p-dma_write(OMAP2_DMA_CSR_CLEAR_MASK, CSR, free_ch);
- p-dma_write(1 free_ch, IRQSTATUS_L0, 0);
+ omap2_enable_irq_lch(free_ch);
}
*dma_ch_out = free_ch;
@@ -758,27 +764,19 @@ void omap_free_dma(int lch)
return;
}
- if (cpu_class_is_omap1()) {
- /* Disable all DMA interrupts for the channel. */
- p-dma_write(0, CICR, lch);
- /* Make sure the DMA transfer is stopped. */
- p-dma_write(0, CCR, lch);
- }
-
- if (cpu_class_is_omap2()) {
+ /* Disable interrupt for logical channel */
+ if (cpu_class_is_omap2())
omap2_disable_irq_lch(lch);
- /* Clear the CSR register and IRQ status register */
- p-dma_write(OMAP2_DMA_CSR_CLEAR_MASK, CSR, lch);
- p-dma_write(1 lch, IRQSTATUS_L0, lch);
+ /* Disable all DMA interrupts for the channel. */
+ omap_disable_channel_irq(lch);
- /* Disable all DMA interrupts for the channel. */
- p-dma_write(0, CICR, lch);
+ /* Make sure the DMA transfer is stopped. */
+ p-dma_write(0, CCR, lch);
- /* Make sure the DMA transfer is stopped. */
- p-dma_write(0, CCR, lch);
+ /* Clear registers */
+ if (cpu_class_is_omap2())
omap_clear_dma(lch);
- }
spin_lock_irqsave(dma_chan_lock, flags);
dma_chan[lch].dev_id = -1;
@@ -926,8 +924,7 @@ void omap_stop_dma(int lch)
u32 l;
/* Disable all interrupts on the channel */
- if (cpu_class_is_omap1())
- p-dma_write(0, CICR, lch);
+
Re: [PATCHv4 4/8] ARM: OMAP4: hwmod: flag hwmods/modules supporting module level context status
Cousson, Benoit b-cous...@ti.com writes: On 4/24/2012 4:46 PM, Tero Kristo wrote: On Mon, 2012-04-23 at 10:52 -0500, Jon Hunter wrote: Hi Tero, On 04/20/2012 04:19 AM, Tero Kristo wrote: From: Rajendra Nayakrna...@ti.com On OMAP4 most modules/hwmods support module level context status. On OMAP3 and earlier, we relyed on the power domain level context status. Identify all such modules using a 'HWMOD_CONTEXT_REG' flag, all such hwmods already have a valid 'context_offs' populated in .prcm structure. Is it necessary to add another flag? Can't we just check if context_offs is non-zero? Would save adding a lot more lines to an already large file :-) Actually one of the older versions of this patch was just checking against a non-zero value, but it was decided to be changed as potentially the context_offs can be zero even if it is a valid offset. Potentially? Is that the case on OMAP4/5 today? I don't see any for OMAP4 in mainline. If zero really is a valid offset somewhere (where?), then we could use -1 (or USHRT_MAX in this case.) Yeah, but still, every OMAP4 IPs are supporting that except two of them I guess, so it is a pity to add that to every IPs. We'd better add a HWMOD_NO_CONTEXT_REG to the few IPs that are not supporting that. Since OMAP 2 3 does not have this feature at all, we can check on the cpu revision. I think the issue raised by Rajendra was about AM35xx that looks like an OMAP3 variant but does have these registers like an OMAP4 variant:-( If AM335x is missing it for *all* IPs, that's easy enough to solve without bloating the data file: just set .context_offs field (or flag) to the magic value for all IPs during hwmod registration. Paul/Benoit should make the call whether to use a special value in the .context_offs field (0 or -1) or add a new flag. If a flag is chosen, I agree with Benoit that it should indicate the *lack* of the feature, since having the feature is the norm. Kevin -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv5 6/8] ARM: OMAP4: pwrdm: add support for reading prev logic and mem states
Tero Kristo t-kri...@ti.com writes:
On OMAP4, there is no support to read previous logic state
or previous memory state achieved when a power domain transitions
to RET. Instead there are module level context registers.
In order to support the powerdomain level logic/mem_off_counters
on OMAP4, instead use the previous power state achieved (RET) and
the *programmed* logic/mem RET state to derive if a powerdomain lost
logic or did not.
If the powerdomain is programmed to enter RET state and lose logic
in RET state, knowing that the powerdomain entered RET is good enough
to derive that the logic was lost as well, in such cases.
Signed-off-by: Tero Kristo t-kri...@ti.com
Looks OK, but these new functions need some kerneldoc to describe the
decision making.
Kevin
---
arch/arm/mach-omap2/powerdomain44xx.c | 32
1 files changed, 32 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/powerdomain44xx.c
b/arch/arm/mach-omap2/powerdomain44xx.c
index 601325b..ab00736 100644
--- a/arch/arm/mach-omap2/powerdomain44xx.c
+++ b/arch/arm/mach-omap2/powerdomain44xx.c
@@ -151,6 +151,21 @@ static int omap4_pwrdm_read_logic_retst(struct
powerdomain *pwrdm)
return v;
}
+static int omap4_pwrdm_read_prev_logic_pwrst(struct powerdomain *pwrdm)
+{
+ int state;
+
+ state = omap4_pwrdm_read_prev_pwrst(pwrdm);
+
+ if (state == PWRDM_POWER_OFF)
+ return PWRDM_POWER_OFF;
+
+ if (state != PWRDM_POWER_RET)
+ return PWRDM_POWER_ON;
+
+ return omap4_pwrdm_read_logic_retst(pwrdm);
+}
+
static int omap4_pwrdm_read_mem_pwrst(struct powerdomain *pwrdm, u8 bank)
{
u32 m, v;
@@ -179,6 +194,21 @@ static int omap4_pwrdm_read_mem_retst(struct powerdomain
*pwrdm, u8 bank)
return v;
}
+static int omap4_pwrdm_read_prev_mem_pwrst(struct powerdomain *pwrdm, u8
bank)
+{
+ int state;
+
+ state = omap4_pwrdm_read_prev_pwrst(pwrdm);
+
+ if (state == PWRDM_POWER_OFF)
+ return PWRDM_POWER_OFF;
+
+ if (state != PWRDM_POWER_RET)
+ return PWRDM_POWER_ON;
+
+ return omap4_pwrdm_read_mem_retst(pwrdm, bank);
+}
+
static int omap4_pwrdm_wait_transition(struct powerdomain *pwrdm)
{
u32 c = 0;
@@ -217,9 +247,11 @@ struct pwrdm_ops omap4_pwrdm_operations = {
.pwrdm_clear_all_prev_pwrst = omap4_pwrdm_clear_all_prev_pwrst,
.pwrdm_set_logic_retst = omap4_pwrdm_set_logic_retst,
.pwrdm_read_logic_pwrst = omap4_pwrdm_read_logic_pwrst,
+ .pwrdm_read_prev_logic_pwrst= omap4_pwrdm_read_prev_logic_pwrst,
.pwrdm_read_logic_retst = omap4_pwrdm_read_logic_retst,
.pwrdm_read_mem_pwrst = omap4_pwrdm_read_mem_pwrst,
.pwrdm_read_mem_retst = omap4_pwrdm_read_mem_retst,
+ .pwrdm_read_prev_mem_pwrst = omap4_pwrdm_read_prev_mem_pwrst,
.pwrdm_set_mem_onst = omap4_pwrdm_set_mem_onst,
.pwrdm_set_mem_retst= omap4_pwrdm_set_mem_retst,
.pwrdm_wait_transition = omap4_pwrdm_wait_transition,
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv5 8/8] ARM: OMAP4: PM: Added option for enabling OSWR
Tero Kristo t-kri...@ti.com writes:
PM debug now contains a file that can be used to control OSWR support
enable / disable on OMAP4. Also removed the off_mode_enable file for
the same platform as it is unsupported.
Signed-off-by: Tero Kristo t-kri...@ti.com
I'll gladly take a patch that makes enable_off_mode OMAP3-only, but I am
not interested managing another new flag for OSWR.
For OMAP4, this should just be the default, and any drivers that are
broken just need to be fixed either by implementing context save/restore
or by using constraints.
Kevin
---
arch/arm/mach-omap2/pm-debug.c | 20
arch/arm/mach-omap2/pm.h |1 +
arch/arm/mach-omap2/pm44xx.c | 16
3 files changed, 33 insertions(+), 4 deletions(-)
diff --git a/arch/arm/mach-omap2/pm-debug.c b/arch/arm/mach-omap2/pm-debug.c
index 814bcd9..d9a8e42 100644
--- a/arch/arm/mach-omap2/pm-debug.c
+++ b/arch/arm/mach-omap2/pm-debug.c
@@ -39,6 +39,7 @@
#include pm.h
u32 enable_off_mode;
+static u32 enable_oswr_mode;
#ifdef CONFIG_DEBUG_FS
#include linux/debugfs.h
@@ -247,10 +248,13 @@ static int option_set(void *data, u64 val)
omap_pm_enable_off_mode();
else
omap_pm_disable_off_mode();
- if (cpu_is_omap34xx())
- omap3_pm_off_mode_enable(val);
+
+ omap3_pm_off_mode_enable(val);
}
+ if (option == enable_oswr_mode)
+ omap4_pm_oswr_mode_enable(val);
+
return 0;
}
@@ -274,8 +278,16 @@ static int __init pm_dbg_init(void)
pwrdm_for_each(pwrdms_setup, (void *)d);
- (void) debugfs_create_file(enable_off_mode, S_IRUGO | S_IWUSR, d,
-enable_off_mode, pm_dbg_option_fops);
+ if (cpu_is_omap34xx())
+ (void) debugfs_create_file(enable_off_mode,
+ S_IRUGO | S_IWUSR, d, enable_off_mode,
+ pm_dbg_option_fops);
+
+ if (cpu_is_omap44xx())
+ (void) debugfs_create_file(enable_oswr_mode,
+ S_IRUGO | S_IWUSR, d, enable_oswr_mode,
+ pm_dbg_option_fops);
+
pm_dbg_init_done = 1;
return 0;
diff --git a/arch/arm/mach-omap2/pm.h b/arch/arm/mach-omap2/pm.h
index 36fa90b..c36ab63 100644
--- a/arch/arm/mach-omap2/pm.h
+++ b/arch/arm/mach-omap2/pm.h
@@ -17,6 +17,7 @@
extern void *omap3_secure_ram_storage;
extern void omap3_pm_off_mode_enable(int);
+extern void omap4_pm_oswr_mode_enable(int);
extern void omap_sram_idle(void);
extern int omap_set_pwrdm_state(struct powerdomain *pwrdm, u32 state);
extern int omap3_idle_init(void);
diff --git a/arch/arm/mach-omap2/pm44xx.c b/arch/arm/mach-omap2/pm44xx.c
index cc85576..07ac0d3 100644
--- a/arch/arm/mach-omap2/pm44xx.c
+++ b/arch/arm/mach-omap2/pm44xx.c
@@ -115,6 +115,22 @@ static int __init pwrdms_setup(struct powerdomain
*pwrdm, void *unused)
return omap_set_pwrdm_state(pwrst-pwrdm, pwrst-next_state);
}
+void omap4_pm_oswr_mode_enable(int enable)
+{
+ u32 next_logic_state;
+ struct power_state *pwrst;
+
+ if (enable)
+ next_logic_state = PWRDM_POWER_OFF;
+ else
+ next_logic_state = PWRDM_POWER_RET;
+
+ list_for_each_entry(pwrst, pwrst_list, node) {
+ pwrst-next_logic_state = next_logic_state;
+ pwrdm_set_logic_retst(pwrst-pwrdm, pwrst-next_logic_state);
+ }
+}
+
/**
* omap_default_idle - OMAP4 default ilde routine.'
*
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 0/9] ARM: OMAP: DMTIMER clean-up in preparation for device-tree
From: Jon Hunter jon-hun...@ti.com
In order to migrate the dmtimer driver to support device-tree I found that it
was first necessary to clean-up the timer platform data. The goal of this
series is to simplify the timer platform data structure from ...
struct dmtimer_platform_data {
int (*set_timer_src)(struct platform_device *pdev, int source);
int timer_ip_version;
u32 needs_manual_reset:1;
bool reserved;
bool loses_context;
int (*get_context_loss_count)(struct device *dev);
};
to ...
struct dmtimer_platform_data {
int (*set_timer_src)(struct platform_device *pdev, int source);
u32 timer_capability;
};
... where timer_capability is a bit mask that indicates the timer features
supported and uses the HWMOD timer capabilities flags described in
plat/dmtimer.h. For OMAP2+ devices this allows us to read the timer
capabilities from the HWMOD data and for OMAP1 devices the flags are simply
populated by the timer initialisation code. Eventually, the aim is to read the
timer capabilities from the device tree blob.
This series includes some fixes as well as clean-up. If it is preferred to split
the series into fixes and clean-up I can do that, but wanted to get some
feedback on this approach.
This series is based upon the current linux-omap master branch. I have built
both omap1 and omap2plus configurations as well as booted the respective kernels
on the omap5912 OSK (omap1), omap2430 SDP, OMAP3430 Beagle and OMAP4460 PANDA.
Jon Hunter (9):
ARM: OMAP: Remove unnecessary clk structure
ARM: OMAP2+: Remove unused max number of timers definition
ARM: OMAP2+: Add dmtimer platform function to reserve systimers
ARM: OMAP: Represent timer features using HWMOD flags
ARM: OMAP2+: HWMOD: Correct timer device attributes
ARM: OMAP2+: Fix external clock support for dmtimers
ARM: OMAP: Remove loses_context variable from timer platform data
ARM: OMAP: Remove timer function pointer for context loss counter
ARM: OMAP: Add flag to indicate if a timer needs a manual reset
arch/arm/mach-omap1/timer.c|3 +-
arch/arm/mach-omap2/omap_hwmod_2xxx_ipblock_data.c | 24 ++
arch/arm/mach-omap2/omap_hwmod_3xxx_data.c | 10 +
arch/arm/mach-omap2/omap_hwmod_44xx_data.c |6 --
arch/arm/mach-omap2/timer.c| 22 ++---
arch/arm/plat-omap/dmtimer.c | 49
arch/arm/plat-omap/include/plat/dmtimer.h | 21 ++--
7 files changed, 57 insertions(+), 78 deletions(-)
--
1.7.5.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/9] ARM: OMAP: Remove unnecessary clk structure
From: Jon Hunter jon-hun...@ti.com
In the plat/dmtimer.h there is a structure named clk declared. This structure
is not used and appears to be left over from previous code. Hence, remove this
unused structure.
Verified that both omap1 and omap2plus kernel configurations build with this
change.
Signed-off-by: Jon Hunter jon-hun...@ti.com
---
arch/arm/plat-omap/include/plat/dmtimer.h |1 -
1 files changed, 0 insertions(+), 1 deletions(-)
diff --git a/arch/arm/plat-omap/include/plat/dmtimer.h
b/arch/arm/plat-omap/include/plat/dmtimer.h
index 5da7356..5fdfaa4 100644
--- a/arch/arm/plat-omap/include/plat/dmtimer.h
+++ b/arch/arm/plat-omap/include/plat/dmtimer.h
@@ -71,7 +71,6 @@ struct omap_timer_capability_dev_attr {
};
struct omap_dm_timer;
-struct clk;
struct timer_regs {
u32 tidr;
--
1.7.5.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/9] ARM: OMAP2+: Remove unused max number of timers definition
From: Jon Hunter jon-hun...@ti.com The OMAP2+ timer code has a definition for the maximum number of timers that OMAP2+ devices have. This defintion is not used anywhere in the code and appears to be left over. Furthermore the definition is not accurate for OMAP4 devices that only have 11 timers available because the 12th timer is reserved as a secure timer. Therefore, remove this definition. Signed-off-by: Jon Hunter jon-hun...@ti.com --- arch/arm/mach-omap2/timer.c |3 --- 1 files changed, 0 insertions(+), 3 deletions(-) diff --git a/arch/arm/mach-omap2/timer.c b/arch/arm/mach-omap2/timer.c index 840929b..c030dfe 100644 --- a/arch/arm/mach-omap2/timer.c +++ b/arch/arm/mach-omap2/timer.c @@ -69,9 +69,6 @@ #define OMAP3_SECURE_TIMER 1 #endif -/* MAX_GPTIMER_ID: number of GPTIMERs on the chip */ -#define MAX_GPTIMER_ID 12 - static u32 sys_timer_reserved; /* Clockevent code */ -- 1.7.5.4 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 3/9] ARM: OMAP2+: Add dmtimer platform function to reserve systimers
From: Jon Hunter jon-hun...@ti.com
During early boot, two timers are reserved by the kernel as system timers (for
clocksource and clockevents). These timers are marked as reserved and the
dmtimer driver is notified which timers have been reserved via the platform
data information.
For OMAP2+ devices the timers reserved may vary depending on device and compile
flags. Therefore, it is not easy to assume which timers we be reserved for the
system timers. In order to migrate the dmtimer driver to support device-tree we
need a way to pass the timers reserved for system timers to the dmtimer driver.
Using the platform data structure will not work in the same way as it is
currently used because the platform data structure will be stored statically in
the dmtimer itself and the platform data will be selected via the device-tree
match device function (of_match_device).
There are a couple ways to workaround this. One option is to store the system
timers reserved for the kernel in the device-tree and query them on boot.
The downside of this approach is that it adds some delay to parse the DT blob
to search for the system timers. Secondly, for OMAP3 devices we have a
dependency on compile time flags and the device-tree would not be aware of that
kernel compile flags and so we would need to address that.
The second option is to add a function to the dmtimer code to reserved the
system timers during boot and so the dmtimer knows exactly which timers are
being used for system timers. This also allows us to remove the reserved
member from the timer platform data. This seemed like the simpler approach and
so was implemented here.
Signed-off-by: Jon Hunter jon-hun...@ti.com
---
arch/arm/mach-omap2/timer.c |9 ++---
arch/arm/plat-omap/dmtimer.c | 18 +-
arch/arm/plat-omap/include/plat/dmtimer.h |3 +--
3 files changed, 20 insertions(+), 10 deletions(-)
diff --git a/arch/arm/mach-omap2/timer.c b/arch/arm/mach-omap2/timer.c
index c030dfe..b0b2080 100644
--- a/arch/arm/mach-omap2/timer.c
+++ b/arch/arm/mach-omap2/timer.c
@@ -69,8 +69,6 @@
#define OMAP3_SECURE_TIMER 1
#endif
-static u32 sys_timer_reserved;
-
/* Clockevent code */
static struct omap_dm_timer clkev;
@@ -177,7 +175,8 @@ static int __init omap_dm_timer_init_one(struct
omap_dm_timer *timer,
omap_hwmod_enable(oh);
- sys_timer_reserved |= (1 (gptimer_id - 1));
+ if (omap_dm_timer_reserve_systimer(gptimer_id))
+ return -ENODEV;
if (gptimer_id != 12) {
struct clk *src;
@@ -501,10 +500,6 @@ static int __init omap_timer_init(struct omap_hwmod *oh,
void *unused)
pdata-set_timer_src = omap2_dm_timer_set_src;
pdata-timer_ip_version = oh-class-rev;
- /* Mark clocksource and clockevent timers as reserved */
- if ((sys_timer_reserved (id - 1)) 0x1)
- pdata-reserved = 1;
-
pwrdm = omap_hwmod_get_pwrdm(oh);
pdata-loses_context = pwrdm_can_ever_lose_context(pwrdm);
#ifdef CONFIG_PM
diff --git a/arch/arm/plat-omap/dmtimer.c b/arch/arm/plat-omap/dmtimer.c
index 3b0cfeb..f5b5c89 100644
--- a/arch/arm/plat-omap/dmtimer.c
+++ b/arch/arm/plat-omap/dmtimer.c
@@ -45,6 +45,7 @@
#include mach/hardware.h
+static u32 omap_reserved_systimers;
static LIST_HEAD(omap_timer_list);
static DEFINE_SPINLOCK(dm_timer_lock);
@@ -152,6 +153,21 @@ int omap_dm_timer_prepare(struct omap_dm_timer *timer)
return ret;
}
+static inline u32 omap_dm_timer_reserved_systimer(int id)
+{
+ return (omap_reserved_systimers (1 (id - 1))) ? 1 : 0;
+}
+
+int omap_dm_timer_reserve_systimer(int id)
+{
+ if (omap_dm_timer_reserved_systimer(id))
+ return -ENODEV;
+
+ omap_reserved_systimers |= (1 (id - 1));
+
+ return 0;
+}
+
struct omap_dm_timer *omap_dm_timer_request(void)
{
struct omap_dm_timer *timer = NULL, *t;
@@ -674,7 +690,7 @@ static int __devinit omap_dm_timer_probe(struct
platform_device *pdev)
timer-id = pdev-id;
timer-irq = irq-start;
- timer-reserved = pdata-reserved;
+ timer-reserved = omap_dm_timer_reserved_systimer(timer-id);
timer-pdev = pdev;
timer-loses_context = pdata-loses_context;
timer-get_context_loss_count = pdata-get_context_loss_count;
diff --git a/arch/arm/plat-omap/include/plat/dmtimer.h
b/arch/arm/plat-omap/include/plat/dmtimer.h
index 5fdfaa4..1e5ce5d 100644
--- a/arch/arm/plat-omap/include/plat/dmtimer.h
+++ b/arch/arm/plat-omap/include/plat/dmtimer.h
@@ -98,13 +98,12 @@ struct dmtimer_platform_data {
int (*set_timer_src)(struct platform_device *pdev, int source);
int timer_ip_version;
u32 needs_manual_reset:1;
- bool reserved;
-
bool loses_context;
int (*get_context_loss_count)(struct device *dev);
};
+int omap_dm_timer_reserve_systimer(int id);
struct omap_dm_timer *omap_dm_timer_request(void);
struct
[PATCH 4/9] ARM: OMAP: Represent timer features using HWMOD flags
From: Jon Hunter jon-hun...@ti.com
Although the OMAP timers share a common hardware design, there are some
differences between the timer instances in a given device. For example, a timer
maybe in a power domain that can be powered-of, so can lose its logic state and
need restoring where as another may be in power domain that is always be on.
Another example, is a timer may support different clock sources to drive the
timer. This information is passed to the dmtimer via the following platform data
structure.
struct dmtimer_platform_data {
int (*set_timer_src)(struct platform_device *pdev, int source);
int timer_ip_version;
u32 needs_manual_reset:1;
bool loses_context;
int (*get_context_loss_count)(struct device *dev);
};
The above structure uses multiple variables to represent the timer features.
HWMOD also stores the timer capabilities using a bit-mask that represents the
features supported. By using the same format for representing the timer
features in the platform data as used by HWMOD, we can ...
1. Use the flags defined in the plat/dmtimer.h to represent the features
supported.
2. For devices using HWMOD, we can retrieve the features supported from HWMOD.
3. Eventually, simplify the platform data structure to be ...
struct dmtimer_platform_data {
int (*set_timer_src)(struct platform_device *pdev, int source);
u32 timer_capability;
}
Another benefit from doing this, is that it will simplify the migration of the
dmtimer driver to device-tree. For example, in the current OMAP2+ timer code the
loses_context variable is configured at runtime by calling an architecture
specific function. For device tree this creates a problem, because we would need
to call the architecture specific function from within the dmtimer driver.
However, such attributes do not need to be queried at runtime and we can look up
the attributes via HWMOD or device-tree.
Signed-off-by: Jon Hunter jon-hun...@ti.com
---
arch/arm/mach-omap2/timer.c |3 +++
arch/arm/plat-omap/dmtimer.c |1 +
arch/arm/plat-omap/include/plat/dmtimer.h |2 ++
3 files changed, 6 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/timer.c b/arch/arm/mach-omap2/timer.c
index b0b2080..d8a5dc3 100644
--- a/arch/arm/mach-omap2/timer.c
+++ b/arch/arm/mach-omap2/timer.c
@@ -500,6 +500,9 @@ static int __init omap_timer_init(struct omap_hwmod *oh,
void *unused)
pdata-set_timer_src = omap2_dm_timer_set_src;
pdata-timer_ip_version = oh-class-rev;
+ if (timer_dev_attr)
+ pdata-timer_capability = timer_dev_attr-timer_capability;
+
pwrdm = omap_hwmod_get_pwrdm(oh);
pdata-loses_context = pwrdm_can_ever_lose_context(pwrdm);
#ifdef CONFIG_PM
diff --git a/arch/arm/plat-omap/dmtimer.c b/arch/arm/plat-omap/dmtimer.c
index f5b5c89..30742d8e6 100644
--- a/arch/arm/plat-omap/dmtimer.c
+++ b/arch/arm/plat-omap/dmtimer.c
@@ -694,6 +694,7 @@ static int __devinit omap_dm_timer_probe(struct
platform_device *pdev)
timer-pdev = pdev;
timer-loses_context = pdata-loses_context;
timer-get_context_loss_count = pdata-get_context_loss_count;
+ timer-capability = pdata-timer_capability;
/* Skip pm_runtime_enable for OMAP1 */
if (!pdata-needs_manual_reset) {
diff --git a/arch/arm/plat-omap/include/plat/dmtimer.h
b/arch/arm/plat-omap/include/plat/dmtimer.h
index 1e5ce5d..48e54ca 100644
--- a/arch/arm/plat-omap/include/plat/dmtimer.h
+++ b/arch/arm/plat-omap/include/plat/dmtimer.h
@@ -101,6 +101,7 @@ struct dmtimer_platform_data {
bool loses_context;
int (*get_context_loss_count)(struct device *dev);
+ u32 timer_capability;
};
int omap_dm_timer_reserve_systimer(int id);
@@ -273,6 +274,7 @@ struct omap_dm_timer {
bool loses_context;
int ctx_loss_count;
int revision;
+ u32 capability;
struct platform_device *pdev;
struct list_head node;
--
1.7.5.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 5/9] ARM: OMAP2+: HWMOD: Correct timer device attributes
From: Jon Hunter jon-hun...@ti.com
Fix the following issues with the timer device attributes for OMAP2+ devices:
1. For OMAP24xx devices, timers 2-8 have the ALWAYS-ON attribute indicating
that these timers are in an ALWAYS-ON power domain. This is not the case
only timer1 is in an ALWAYS-ON power domain.
2. For OMAP3xxx devices, timers 2-7 have the ALWAYS-ON attribute indicating
that these timers are in an ALWAYS-ON power domain. This is not the case
only timer1 and timer12 are in an ALWAYS-ON power domain.
3. For OMAP3xxx devices, timer12 does not have the ALWAYS-ON attribute but is
in an always-on power domain.
Finally, for OMAP24xx devices the timers are be clocked by an external clock
connected to the sys_altclk pin. So add a new attribute to indicate that this.
This will allow us to simplify the code that determines if a timer can use an
external clock source.
Signed-off-by: Jon Hunter jon-hun...@ti.com
---
arch/arm/mach-omap2/omap_hwmod_2xxx_ipblock_data.c | 23 ---
arch/arm/mach-omap2/omap_hwmod_3xxx_data.c |8 +--
arch/arm/mach-omap2/omap_hwmod_44xx_data.c |6 -
arch/arm/plat-omap/include/plat/dmtimer.h |1 +
4 files changed, 16 insertions(+), 22 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod_2xxx_ipblock_data.c
b/arch/arm/mach-omap2/omap_hwmod_2xxx_ipblock_data.c
index 83eafd9..4ecb2e8 100644
--- a/arch/arm/mach-omap2/omap_hwmod_2xxx_ipblock_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_2xxx_ipblock_data.c
@@ -213,14 +213,19 @@ struct omap_hwmod omap2xxx_iva_hwmod = {
.class = iva_hwmod_class,
};
+/* timers dev attribute */
+static struct omap_timer_capability_dev_attr capability_dev_attr = {
+ .timer_capability = OMAP_TIMER_HAS_ALTCLK,
+};
+
/* always-on timers dev attribute */
static struct omap_timer_capability_dev_attr capability_alwon_dev_attr = {
- .timer_capability = OMAP_TIMER_ALWON,
+ .timer_capability = OMAP_TIMER_ALWON | OMAP_TIMER_HAS_ALTCLK,
};
/* pwm timers dev attribute */
static struct omap_timer_capability_dev_attr capability_pwm_dev_attr = {
- .timer_capability = OMAP_TIMER_HAS_PWM,
+ .timer_capability = OMAP_TIMER_HAS_PWM | OMAP_TIMER_HAS_ALTCLK,
};
/* timer1 */
@@ -257,7 +262,7 @@ struct omap_hwmod omap2xxx_timer2_hwmod = {
.idlest_idle_bit = OMAP24XX_ST_GPT2_SHIFT,
},
},
- .dev_attr = capability_alwon_dev_attr,
+ .dev_attr = capability_dev_attr,
.class = omap2xxx_timer_hwmod_class,
};
@@ -276,7 +281,7 @@ struct omap_hwmod omap2xxx_timer3_hwmod = {
.idlest_idle_bit = OMAP24XX_ST_GPT3_SHIFT,
},
},
- .dev_attr = capability_alwon_dev_attr,
+ .dev_attr = capability_dev_attr,
.class = omap2xxx_timer_hwmod_class,
};
@@ -295,7 +300,7 @@ struct omap_hwmod omap2xxx_timer4_hwmod = {
.idlest_idle_bit = OMAP24XX_ST_GPT4_SHIFT,
},
},
- .dev_attr = capability_alwon_dev_attr,
+ .dev_attr = capability_dev_attr,
.class = omap2xxx_timer_hwmod_class,
};
@@ -314,7 +319,7 @@ struct omap_hwmod omap2xxx_timer5_hwmod = {
.idlest_idle_bit = OMAP24XX_ST_GPT5_SHIFT,
},
},
- .dev_attr = capability_alwon_dev_attr,
+ .dev_attr = capability_dev_attr,
.class = omap2xxx_timer_hwmod_class,
};
@@ -333,7 +338,7 @@ struct omap_hwmod omap2xxx_timer6_hwmod = {
.idlest_idle_bit = OMAP24XX_ST_GPT6_SHIFT,
},
},
- .dev_attr = capability_alwon_dev_attr,
+ .dev_attr = capability_dev_attr,
.class = omap2xxx_timer_hwmod_class,
};
@@ -352,7 +357,7 @@ struct omap_hwmod omap2xxx_timer7_hwmod = {
.idlest_idle_bit = OMAP24XX_ST_GPT7_SHIFT,
},
},
- .dev_attr = capability_alwon_dev_attr,
+ .dev_attr = capability_dev_attr,
.class = omap2xxx_timer_hwmod_class,
};
@@ -371,7 +376,7 @@ struct omap_hwmod omap2xxx_timer8_hwmod = {
.idlest_idle_bit = OMAP24XX_ST_GPT8_SHIFT,
},
},
- .dev_attr = capability_alwon_dev_attr,
+ .dev_attr = capability_dev_attr,
.class = omap2xxx_timer_hwmod_class,
};
diff --git a/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
b/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
index b26d3c9..7b33094 100644
--- a/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
@@ -150,7 +150,7 @@ static struct omap_hwmod_class omap3xxx_timer_hwmod_class =
{
/* secure timers dev attribute */
static struct omap_timer_capability_dev_attr capability_secure_dev_attr = {
-
[PATCH 7/9] ARM: OMAP: Remove loses_context variable from timer platform data
From: Jon Hunter jon-hun...@ti.com
The platform data variable loses_context is used to determine if the timer may
lose its logic state during power transitions and so needs to be restored. This
information is also provided in the HWMOD device attributes for OMAP2+ devices
via the OMAP_TIMER_ALWON flag. When this flag is set the timer will not lose
context. So use the HWMOD device attributes to determine this.
For OMAP1 devices, loses_context is never set and so set the OMAP_TIMER_ALWON
flag for OMAP1 timers to ensure that code is equivalent.
Signed-off-by: Jon Hunter jon-hun...@ti.com
---
arch/arm/mach-omap1/timer.c |1 +
arch/arm/mach-omap2/timer.c |3 ---
arch/arm/plat-omap/dmtimer.c |8
arch/arm/plat-omap/include/plat/dmtimer.h |3 ---
4 files changed, 5 insertions(+), 10 deletions(-)
diff --git a/arch/arm/mach-omap1/timer.c b/arch/arm/mach-omap1/timer.c
index 64c65bc..b4bf48c 100644
--- a/arch/arm/mach-omap1/timer.c
+++ b/arch/arm/mach-omap1/timer.c
@@ -141,6 +141,7 @@ static int __init omap1_dm_timer_init(void)
pdata-set_timer_src = omap1_dm_timer_set_src;
pdata-needs_manual_reset = 1;
+ pdata-timer_capability = OMAP_TIMER_ALWON;
ret = platform_device_add_data(pdev, pdata, sizeof(*pdata));
if (ret) {
diff --git a/arch/arm/mach-omap2/timer.c b/arch/arm/mach-omap2/timer.c
index cfc5781..638c8df 100644
--- a/arch/arm/mach-omap2/timer.c
+++ b/arch/arm/mach-omap2/timer.c
@@ -469,7 +469,6 @@ static int __init omap_timer_init(struct omap_hwmod *oh,
void *unused)
struct dmtimer_platform_data *pdata;
struct platform_device *pdev;
struct omap_timer_capability_dev_attr *timer_dev_attr;
- struct powerdomain *pwrdm;
pr_debug(%s: %s\n, __func__, oh-name);
@@ -502,8 +501,6 @@ static int __init omap_timer_init(struct omap_hwmod *oh,
void *unused)
if (timer_dev_attr)
pdata-timer_capability = timer_dev_attr-timer_capability;
- pwrdm = omap_hwmod_get_pwrdm(oh);
- pdata-loses_context = pwrdm_can_ever_lose_context(pwrdm);
#ifdef CONFIG_PM
pdata-get_context_loss_count = omap_pm_get_dev_context_loss_count;
#endif
diff --git a/arch/arm/plat-omap/dmtimer.c b/arch/arm/plat-omap/dmtimer.c
index 30742d8e6..7aa1278 100644
--- a/arch/arm/plat-omap/dmtimer.c
+++ b/arch/arm/plat-omap/dmtimer.c
@@ -341,7 +341,7 @@ int omap_dm_timer_start(struct omap_dm_timer *timer)
omap_dm_timer_enable(timer);
- if (timer-loses_context) {
+ if (!(timer-capability OMAP_TIMER_ALWON)) {
u32 ctx_loss_cnt_after =
timer-get_context_loss_count(timer-pdev-dev);
if (ctx_loss_cnt_after != timer-ctx_loss_count)
@@ -374,7 +374,8 @@ int omap_dm_timer_stop(struct omap_dm_timer *timer)
__omap_dm_timer_stop(timer, timer-posted, rate);
- if (timer-loses_context timer-get_context_loss_count)
+ if (!(timer-capability OMAP_TIMER_ALWON)
+ timer-get_context_loss_count)
timer-ctx_loss_count =
timer-get_context_loss_count(timer-pdev-dev);
@@ -447,7 +448,7 @@ int omap_dm_timer_set_load_start(struct omap_dm_timer
*timer, int autoreload,
omap_dm_timer_enable(timer);
- if (timer-loses_context) {
+ if (!(timer-capability OMAP_TIMER_ALWON)) {
u32 ctx_loss_cnt_after =
timer-get_context_loss_count(timer-pdev-dev);
if (ctx_loss_cnt_after != timer-ctx_loss_count)
@@ -692,7 +693,6 @@ static int __devinit omap_dm_timer_probe(struct
platform_device *pdev)
timer-irq = irq-start;
timer-reserved = omap_dm_timer_reserved_systimer(timer-id);
timer-pdev = pdev;
- timer-loses_context = pdata-loses_context;
timer-get_context_loss_count = pdata-get_context_loss_count;
timer-capability = pdata-timer_capability;
diff --git a/arch/arm/plat-omap/include/plat/dmtimer.h
b/arch/arm/plat-omap/include/plat/dmtimer.h
index 2c5c155..e62208e 100644
--- a/arch/arm/plat-omap/include/plat/dmtimer.h
+++ b/arch/arm/plat-omap/include/plat/dmtimer.h
@@ -92,8 +92,6 @@ struct timer_regs {
struct dmtimer_platform_data {
int (*set_timer_src)(struct platform_device *pdev, int source);
u32 needs_manual_reset:1;
- bool loses_context;
-
int (*get_context_loss_count)(struct device *dev);
u32 timer_capability;
};
@@ -265,7 +263,6 @@ struct omap_dm_timer {
unsigned reserved:1;
unsigned posted:1;
struct timer_regs context;
- bool loses_context;
int ctx_loss_count;
int revision;
u32 capability;
--
1.7.5.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at
[PATCH 8/9] ARM: OMAP: Remove timer function pointer for context loss counter
From: Jon Hunter jon-hun...@ti.com
For OMAP2+ devices, a function pointer that returns the number of times a timer
power domain has lost context is passed to the dmtimer driver. This function
pointer is only populated for OMAP2+ devices and it is pointing to a platform
function. Given that this is a platform function, we can simplify the code by
removing the function pointer and referencing the function directly. We can use
the OMAP_TIMER_ALWON flag to determine if we need to call this function for
OMAP1 and OMAP2+ devices.
The benefit of this change is the we can remove the function pointer from the
platform data and simplifies the dmtimer migration to device-tree.
Signed-off-by: Jon Hunter jon-hun...@ti.com
---
arch/arm/mach-omap2/timer.c |3 ---
arch/arm/plat-omap/dmtimer.c | 17 +++--
arch/arm/plat-omap/include/plat/dmtimer.h |3 ---
3 files changed, 7 insertions(+), 16 deletions(-)
diff --git a/arch/arm/mach-omap2/timer.c b/arch/arm/mach-omap2/timer.c
index 638c8df..52bc4c4 100644
--- a/arch/arm/mach-omap2/timer.c
+++ b/arch/arm/mach-omap2/timer.c
@@ -501,9 +501,6 @@ static int __init omap_timer_init(struct omap_hwmod *oh,
void *unused)
if (timer_dev_attr)
pdata-timer_capability = timer_dev_attr-timer_capability;
-#ifdef CONFIG_PM
- pdata-get_context_loss_count = omap_pm_get_dev_context_loss_count;
-#endif
pdev = omap_device_build(name, id, oh, pdata, sizeof(*pdata),
NULL, 0, 0);
diff --git a/arch/arm/plat-omap/dmtimer.c b/arch/arm/plat-omap/dmtimer.c
index 7aa1278..7875eef 100644
--- a/arch/arm/plat-omap/dmtimer.c
+++ b/arch/arm/plat-omap/dmtimer.c
@@ -42,6 +42,7 @@
#include linux/pm_runtime.h
#include plat/dmtimer.h
+#include plat/omap-pm.h
#include mach/hardware.h
@@ -342,9 +343,8 @@ int omap_dm_timer_start(struct omap_dm_timer *timer)
omap_dm_timer_enable(timer);
if (!(timer-capability OMAP_TIMER_ALWON)) {
- u32 ctx_loss_cnt_after =
- timer-get_context_loss_count(timer-pdev-dev);
- if (ctx_loss_cnt_after != timer-ctx_loss_count)
+ if (omap_pm_get_dev_context_loss_count(timer-pdev-dev) !=
+ timer-ctx_loss_count)
omap_timer_restore_context(timer);
}
@@ -374,10 +374,9 @@ int omap_dm_timer_stop(struct omap_dm_timer *timer)
__omap_dm_timer_stop(timer, timer-posted, rate);
- if (!(timer-capability OMAP_TIMER_ALWON)
- timer-get_context_loss_count)
+ if (!(timer-capability OMAP_TIMER_ALWON))
timer-ctx_loss_count =
- timer-get_context_loss_count(timer-pdev-dev);
+ omap_pm_get_dev_context_loss_count(timer-pdev-dev);
/*
* Since the register values are computed and written within
@@ -449,9 +448,8 @@ int omap_dm_timer_set_load_start(struct omap_dm_timer
*timer, int autoreload,
omap_dm_timer_enable(timer);
if (!(timer-capability OMAP_TIMER_ALWON)) {
- u32 ctx_loss_cnt_after =
- timer-get_context_loss_count(timer-pdev-dev);
- if (ctx_loss_cnt_after != timer-ctx_loss_count)
+ if (omap_pm_get_dev_context_loss_count(timer-pdev-dev) !=
+ timer-ctx_loss_count)
omap_timer_restore_context(timer);
}
@@ -693,7 +691,6 @@ static int __devinit omap_dm_timer_probe(struct
platform_device *pdev)
timer-irq = irq-start;
timer-reserved = omap_dm_timer_reserved_systimer(timer-id);
timer-pdev = pdev;
- timer-get_context_loss_count = pdata-get_context_loss_count;
timer-capability = pdata-timer_capability;
/* Skip pm_runtime_enable for OMAP1 */
diff --git a/arch/arm/plat-omap/include/plat/dmtimer.h
b/arch/arm/plat-omap/include/plat/dmtimer.h
index e62208e..1828b04 100644
--- a/arch/arm/plat-omap/include/plat/dmtimer.h
+++ b/arch/arm/plat-omap/include/plat/dmtimer.h
@@ -92,7 +92,6 @@ struct timer_regs {
struct dmtimer_platform_data {
int (*set_timer_src)(struct platform_device *pdev, int source);
u32 needs_manual_reset:1;
- int (*get_context_loss_count)(struct device *dev);
u32 timer_capability;
};
@@ -268,8 +267,6 @@ struct omap_dm_timer {
u32 capability;
struct platform_device *pdev;
struct list_head node;
-
- int (*get_context_loss_count)(struct device *dev);
};
int omap_dm_timer_prepare(struct omap_dm_timer *timer);
--
1.7.5.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 9/9] ARM: OMAP: Add flag to indicate if a timer needs a manual reset
From: Jon Hunter jon-hun...@ti.com
For OMAP1 devices, it is necessary to perform a manual reset of the timer.
Currently, this is indicating by setting the needs_manual_reset variable in
the platform data. Instead of using an extra variable to indicate this add a new
timer capabilities flag to indicate this and remove the needs_manual_reset
member from the platform data.
Signed-off-by: Jon Hunter jon-hun...@ti.com
---
arch/arm/mach-omap1/timer.c |4 ++--
arch/arm/plat-omap/dmtimer.c |9 +++--
arch/arm/plat-omap/include/plat/dmtimer.h |1 +
3 files changed, 6 insertions(+), 8 deletions(-)
diff --git a/arch/arm/mach-omap1/timer.c b/arch/arm/mach-omap1/timer.c
index b4bf48c..aa81593 100644
--- a/arch/arm/mach-omap1/timer.c
+++ b/arch/arm/mach-omap1/timer.c
@@ -140,8 +140,8 @@ static int __init omap1_dm_timer_init(void)
}
pdata-set_timer_src = omap1_dm_timer_set_src;
- pdata-needs_manual_reset = 1;
- pdata-timer_capability = OMAP_TIMER_ALWON;
+ pdata-timer_capability = OMAP_TIMER_ALWON |
+ OMAP_TIMER_NEEDS_RESET;
ret = platform_device_add_data(pdev, pdata, sizeof(*pdata));
if (ret) {
diff --git a/arch/arm/plat-omap/dmtimer.c b/arch/arm/plat-omap/dmtimer.c
index 7875eef..e3e22b3 100644
--- a/arch/arm/plat-omap/dmtimer.c
+++ b/arch/arm/plat-omap/dmtimer.c
@@ -135,7 +135,6 @@ static void omap_dm_timer_reset(struct omap_dm_timer *timer)
int omap_dm_timer_prepare(struct omap_dm_timer *timer)
{
- struct dmtimer_platform_data *pdata = timer-pdev-dev.platform_data;
int ret;
timer-fclk = clk_get(timer-pdev-dev, fck);
@@ -145,7 +144,7 @@ int omap_dm_timer_prepare(struct omap_dm_timer *timer)
return -EINVAL;
}
- if (pdata-needs_manual_reset)
+ if (timer-capability OMAP_TIMER_NEEDS_RESET)
omap_dm_timer_reset(timer);
ret = omap_dm_timer_set_source(timer, OMAP_TIMER_SRC_32_KHZ);
@@ -363,13 +362,11 @@ EXPORT_SYMBOL_GPL(omap_dm_timer_start);
int omap_dm_timer_stop(struct omap_dm_timer *timer)
{
unsigned long rate = 0;
- struct dmtimer_platform_data *pdata;
if (unlikely(!timer))
return -EINVAL;
- pdata = timer-pdev-dev.platform_data;
- if (!pdata-needs_manual_reset)
+ if (!(timer-capability OMAP_TIMER_NEEDS_RESET))
rate = clk_get_rate(timer-fclk);
__omap_dm_timer_stop(timer, timer-posted, rate);
@@ -694,7 +691,7 @@ static int __devinit omap_dm_timer_probe(struct
platform_device *pdev)
timer-capability = pdata-timer_capability;
/* Skip pm_runtime_enable for OMAP1 */
- if (!pdata-needs_manual_reset) {
+ if (!(timer-capability OMAP_TIMER_NEEDS_RESET)) {
pm_runtime_enable(pdev-dev);
pm_runtime_irq_safe(pdev-dev);
}
diff --git a/arch/arm/plat-omap/include/plat/dmtimer.h
b/arch/arm/plat-omap/include/plat/dmtimer.h
index 1828b04..a2abd0e 100644
--- a/arch/arm/plat-omap/include/plat/dmtimer.h
+++ b/arch/arm/plat-omap/include/plat/dmtimer.h
@@ -60,6 +60,7 @@
#define OMAP_TIMER_ALWON 0x4000
#define OMAP_TIMER_HAS_PWM 0x2000
#define OMAP_TIMER_HAS_ALTCLK 0x1000
+#define OMAP_TIMER_NEEDS_RESET 0x0800
struct omap_timer_capability_dev_attr {
u32 timer_capability;
--
1.7.5.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 6/9] ARM: OMAP2+: Fix external clock support for dmtimers
From: Jon Hunter jon-hun...@ti.com
Currently, the dmtimer determines whether an timer can support an external
clock source (sys_altclk) for driving the timer by the IP version. Only
OMAP24xx devices can support an external clock source, but the IP version
between OMAP24xx and OMAP3xxx is common and so this incorrectly indicates
that OMAP3 devices can use an external clock source.
Rather than use the IP version, use the OMAP_TIMER_HAS_ALTCLK flag added
to the HWMOD timer device attributes. By doing this, this allows us to
eliminate the timer_ip_version variable passed as part of the platform data.
We can also remove the timer IP version from the HWMOD data because the dmtimer
driver uses the TIDR register to determine the IP version.
Signed-off-by: Jon Hunter jon-hun...@ti.com
---
arch/arm/mach-omap2/omap_hwmod_2xxx_ipblock_data.c |1 -
arch/arm/mach-omap2/omap_hwmod_3xxx_data.c |2 --
arch/arm/mach-omap2/timer.c|3 +--
arch/arm/plat-omap/include/plat/dmtimer.h |7 ---
4 files changed, 1 insertions(+), 12 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod_2xxx_ipblock_data.c
b/arch/arm/mach-omap2/omap_hwmod_2xxx_ipblock_data.c
index 4ecb2e8..de8442c 100644
--- a/arch/arm/mach-omap2/omap_hwmod_2xxx_ipblock_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_2xxx_ipblock_data.c
@@ -68,7 +68,6 @@ static struct omap_hwmod_class_sysconfig omap2xxx_timer_sysc
= {
struct omap_hwmod_class omap2xxx_timer_hwmod_class = {
.name = timer,
.sysc = omap2xxx_timer_sysc,
- .rev= OMAP_TIMER_IP_VERSION_1,
};
/*
diff --git a/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
b/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
index 7b33094..0ea53bc 100644
--- a/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
@@ -129,7 +129,6 @@ static struct omap_hwmod_class_sysconfig
omap3xxx_timer_1ms_sysc = {
static struct omap_hwmod_class omap3xxx_timer_1ms_hwmod_class = {
.name = timer,
.sysc = omap3xxx_timer_1ms_sysc,
- .rev = OMAP_TIMER_IP_VERSION_1,
};
static struct omap_hwmod_class_sysconfig omap3xxx_timer_sysc = {
@@ -145,7 +144,6 @@ static struct omap_hwmod_class_sysconfig
omap3xxx_timer_sysc = {
static struct omap_hwmod_class omap3xxx_timer_hwmod_class = {
.name = timer,
.sysc = omap3xxx_timer_sysc,
- .rev = OMAP_TIMER_IP_VERSION_1,
};
/* secure timers dev attribute */
diff --git a/arch/arm/mach-omap2/timer.c b/arch/arm/mach-omap2/timer.c
index d8a5dc3..cfc5781 100644
--- a/arch/arm/mach-omap2/timer.c
+++ b/arch/arm/mach-omap2/timer.c
@@ -418,7 +418,7 @@ static int omap2_dm_timer_set_src(struct platform_device
*pdev, int source)
break;
case OMAP_TIMER_SRC_EXT_CLK:
- if (pdata-timer_ip_version == OMAP_TIMER_IP_VERSION_1) {
+ if (pdata-timer_capability OMAP_TIMER_HAS_ALTCLK) {
parent_name = alt_ck;
break;
}
@@ -498,7 +498,6 @@ static int __init omap_timer_init(struct omap_hwmod *oh,
void *unused)
sscanf(oh-name, timer%2d, id);
pdata-set_timer_src = omap2_dm_timer_set_src;
- pdata-timer_ip_version = oh-class-rev;
if (timer_dev_attr)
pdata-timer_capability = timer_dev_attr-timer_capability;
diff --git a/arch/arm/plat-omap/include/plat/dmtimer.h
b/arch/arm/plat-omap/include/plat/dmtimer.h
index 2ce1e4a..2c5c155 100644
--- a/arch/arm/plat-omap/include/plat/dmtimer.h
+++ b/arch/arm/plat-omap/include/plat/dmtimer.h
@@ -55,12 +55,6 @@
#define OMAP_TIMER_TRIGGER_OVERFLOW0x01
#define OMAP_TIMER_TRIGGER_OVERFLOW_AND_COMPARE0x02
-/*
- * IP revision identifier so that Highlander IP
- * in OMAP4 can be distinguished.
- */
-#define OMAP_TIMER_IP_VERSION_10x1
-
/* timer capabilities used in hwmod database */
#define OMAP_TIMER_SECURE 0x8000
#define OMAP_TIMER_ALWON 0x4000
@@ -97,7 +91,6 @@ struct timer_regs {
struct dmtimer_platform_data {
int (*set_timer_src)(struct platform_device *pdev, int source);
- int timer_ip_version;
u32 needs_manual_reset:1;
bool loses_context;
--
1.7.5.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH V3 1/2] of: Add generic device tree DMA helpers
Hi Jassi,
On 05/12/2012 08:40 AM, Jassi Brar wrote:
On 12 May 2012 05:21, Stephen Warren swar...@wwwdotorg.org wrote:
On 05/11/2012 03:06 PM, Jassi Brar wrote:
On 12 May 2012 00:58, Stephen Warren swar...@wwwdotorg.org wrote:
On 05/10/2012 01:59 PM, Jassi Brar wrote:
...
client0: i2s {
/* has 2 DMA request output signals: 0, 1 */
};
client1: spdif {
/* has 2 DMA request signals: 0, 1 */
};
Do we also need to somehow tag these signals for the client to
differentiate between TX and RX channel ?
Yes, the client's DT binding would certainly need to describe how many
DMA request signals its HW generates, and give a unique ID to each. The
driver would need to request a DMA channel for a specific one of its DMA
requests.
Did I read give a unique ID to each correctly ?
It'd be unique relative to that individual device or DT node, not at any
larger scope.
OK.
Could you please take some time out to jot down an example of how a
typical client's dma specifier should look.
With this proposal, I'm not sure that the client DT node would need any
DMA information at all, at least nothing that identifies which DMA
controllers, channels, or requests are required to service this
node/device's DMA requests - that routing information is all represented
in the DMA controller itself.
(I think Arnd made the following point earlier in this thread):
If you did need to put any other information in DT, then that probably
would go in the DMA client node, since it'd presumably be the same
irrespective of which DMA controller got used. However, that information
presumably wouldn't be needed in DT at all, since the driver would know
it, since it'd be a facet of the HW.
Note: I'm thinking things like DMA physical address (presumably an
offset from the reg property), DMA access size (presumably a fixed
property of the HW), DMA burst size (presumably a property of the HW,
although at least some HW can be programmed to raise the DMA request
signal with a varying number of FIFO entries free, so not fixed), etc.
Yeah, neither did I think a client node should tell more than IDs of
its channels
- which we now decide to simply mention in its binding.
How do I know if you or someone is interested in reworking the patchset
or want me to give it a try?
Sorry for not participating more in the discussion here, but I got tied
up. I was planning on a V4 on the patch-set last week, but it did not
happen. So I was planning for it this week. The V4 I had in mind was a
more generic version of what I previously submitted, using xlate
function to permit different DT tree formats. However, there would be a
couple default xlate functions for people to use.
I am concerned that this implementation may not address all your
concerns. So if you have something to propose then please feel free to
do so.
By the way, what it unclear to me, if you have a client that could use
more than one channel of multiple controllers, how is the handled? Who
makes the decision on which to use?
The TI DMAs are somewhat inflexible and simple in this manner that you
don't have a choice :-)
Cheers
Jon
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH V3 1/2] of: Add generic device tree DMA helpers
Hi Jassi,
On 05/04/2012 02:01 PM, Jassi Brar wrote:
On 4 May 2012 20:47, Jon Hunter jon-hun...@ti.com wrote:
Hi Jassi,
On 05/04/2012 01:56 AM, Jassi Brar wrote:
On 1 May 2012 02:47, Jon Hunter jon-hun...@ti.com wrote:
From: Jon Hunter jon-hun...@ti.com
This is based upon the work by Benoit Cousson [1] and Nicolas Ferre [2]
to add some basic helpers to retrieve a DMA controller device_node and the
DMA request/channel information.
Aim of DMA helpers
- The purpose of device-tree (as far as I understand), is to describe the
capabilites of the hardware. Thinking about DMA controllers purely from
the
context of the hardware to begin with, we can describe a device in terms
of
a DMA controller as follows ...
1. Number of DMA controllers
2. Number of channels (maybe physical or logical)
3. Mapping of DMA requests signals to DMA controller
4. Number of DMA interrupts
5. Mapping of DMA interrupts to channels
- With the above in mind the aim of the DT DMA helper functions is to
extract
the above information from the DT and provide to the appropriate driver.
However, due to the vast number of DMA controllers and not all are using a
common driver (such as DMA Engine) it has been seen that this is not a
trivial task.
Sorry for being slow, but so far I thought DT is only to provide _h/w_
specific info
to the _controller_ drivers. It was not supposed to provide any info
pertaining to
some API (dmaengine in this case).
And I believe this is one of few situations where we are better off
not generalizing
the interface - pass controller specific info in the controller
driver's specified format.
Generalizing only seems to complicate things here, when we anyway have
machine
specific dtb, which could always have clients requesting and the
controllers given
dma's info in controller driver's specific format.
Perhaps I am overlooking the need to generalize. If you think so, please
help me
understand by pointing out some use case for it.
No not really, your points are valid. From reading the previous
discussions one of the items that was clearly lacking was the ability to
represent and identify a device having more than one DMA controller. In
other words, when you request the DMA resource, how do you identify
which DMA controller in the system that resource belongs too. With DMA
engine there are ways we can do this.
Well, if we really can't have dmac drivers make 'intelligent' runtime decision
of request mapping on more than one capable controllers, we still can
make it simpler than the proposed scheme.
+ i2c1: i2c@1 {
+ ...
+ dma = sdma 2 1 sdma 3 2;
+ ...
+ };
I see this requires a client driver to specify a particular req_line on a
particular dma controller. I am not sure if this is most optimal.
Actually, no. The phandle in the DT specifies the DMA controller to use.
Then the client simply asks for a channel with a particular property,
for example, DMA_MEM_TO_DEV (ie. TX) and the channel information is return.
I think such client-req_line map should be provided to the dmac controller
driver via its dt node in some format. The dmac driver could then populate
a dma_chan, or similar, only for that req_line and not for the unused one
which otherwise could also have served the same client.
Ideally the I2C driver should simply ask, say, a channel for TX and another
for RX, everything else should already be setup via dmac's dt nodes.
Yes that is the intention here.
Cheers
Jon
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/3] OMAP: control: bootaddr and bootmod APIs
On 2 May 2012 21:11, Omar Ramirez Luna omar.l...@linaro.org wrote: Recently a patch went in for tidspbridge code, to ioremap SCM registers and solve a build break[1]. However it has been pointed out before that this is a layer violation given that control module should handle its own registers, this series is an attempt to create APIs for the users of these registers. With some adaptations this patch might also make use of it: http://www.mail-archive.com/linux-omap@vger.kernel.org/msg66491.html Patch: staging: tidspbridge: use scm functions to set boot address and mode, will be sent separately to staging tree. Tested on OMAP3 Beagleboard. [1] http://www.mail-archive.com/devel@linuxdriverproject.org/msg18762.html Omar Ramirez Luna (3): OMAP2+: control: new APIs to configure boot address and mode OMAP: dsp: interface to control module functions staging: tidspbridge: use scm functions to set boot address and mode Ping. It seems that I unconsciously copied the previous concept, recently I dug this thread to explain the reasoning of these patches: http://www.mail-archive.com/linux-omap@vger.kernel.org/msg38015.html These were provided by Paul, one of them acked by Kevin, somehow they were not included and I forgot about them. My set also includes OMAP4 check, which I heard recently was tested with the dsp on pandaboard. If needed I can go back to Paul's version and re-spin them, with minor changes. Please let me know. Regards, Omar -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv4 4/8] ARM: OMAP4: hwmod: flag hwmods/modules supporting module level context status
On Wednesday 16 May 2012 03:52 AM, Kevin Hilman wrote: Cousson, Benoitb-cous...@ti.com writes: On 4/24/2012 4:46 PM, Tero Kristo wrote: On Mon, 2012-04-23 at 10:52 -0500, Jon Hunter wrote: Hi Tero, On 04/20/2012 04:19 AM, Tero Kristo wrote: From: Rajendra Nayakrna...@ti.com On OMAP4 most modules/hwmods support module level context status. On OMAP3 and earlier, we relyed on the power domain level context status. Identify all such modules using a 'HWMOD_CONTEXT_REG' flag, all such hwmods already have a valid 'context_offs' populated in .prcm structure. Is it necessary to add another flag? Can't we just check if context_offs is non-zero? Would save adding a lot more lines to an already large file :-) Actually one of the older versions of this patch was just checking against a non-zero value, but it was decided to be changed as potentially the context_offs can be zero even if it is a valid offset. Potentially? Is that the case on OMAP4/5 today? I don't see any for OMAP4 in mainline. No, we don;t have any such cases today in either OMAP4 or OMAP5. If zero really is a valid offset somewhere (where?), then we could use -1 (or USHRT_MAX in this case.) This makes sense for OMAP4 and beyond (and same with having a flag to indicate the *lack* of having the feature) as it will mean just adding a few entries in hwmod data files to indicate IP blocks (very few) which do not support this feature. However since none of OMAP2/3 varients (except I guess the AM family) support this, it would also mean we mark *most* blocks in OMAP2/3 to indicate they *lack* this feature, which would mean bloating the OMAP2/3 data files, but your comment below about doing it for all IPs during hwmod registration makes sense at least for OMAP2 since *all* blocks can be marked at registration. OMAP3 would probably need more data files to be updated to indicate which ones support and which ones don't. Having said that I also see 'context_reg' being defined inside omap_hwmod_omap4_prcm would need to be fixed if we have to support this for SoCs which fall as OMAP3 varients. Yeah, but still, every OMAP4 IPs are supporting that except two of them I guess, so it is a pity to add that to every IPs. We'd better add a HWMOD_NO_CONTEXT_REG to the few IPs that are not supporting that. Since OMAP 2 3 does not have this feature at all, we can check on the cpu revision. I think the issue raised by Rajendra was about AM35xx that looks like an OMAP3 variant but does have these registers like an OMAP4 variant:-( If AM335x is missing it for *all* IPs, that's easy enough to solve without bloating the data file: just set .context_offs field (or flag) to the magic value for all IPs during hwmod registration. Paul/Benoit should make the call whether to use a special value in the .context_offs field (0 or -1) or add a new flag. If a flag is chosen, I agree with Benoit that it should indicate the *lack* of the feature, since having the feature is the norm. Kevin -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv4 4/8] ARM: OMAP4: hwmod: flag hwmods/modules supporting module level context status
On Wednesday 16 May 2012 10:54 AM, Rajendra Nayak wrote: On Wednesday 16 May 2012 03:52 AM, Kevin Hilman wrote: Cousson, Benoitb-cous...@ti.com writes: On 4/24/2012 4:46 PM, Tero Kristo wrote: On Mon, 2012-04-23 at 10:52 -0500, Jon Hunter wrote: Hi Tero, On 04/20/2012 04:19 AM, Tero Kristo wrote: From: Rajendra Nayakrna...@ti.com On OMAP4 most modules/hwmods support module level context status. On OMAP3 and earlier, we relyed on the power domain level context status. Identify all such modules using a 'HWMOD_CONTEXT_REG' flag, all such hwmods already have a valid 'context_offs' populated in .prcm structure. Is it necessary to add another flag? Can't we just check if context_offs is non-zero? Would save adding a lot more lines to an already large file :-) Actually one of the older versions of this patch was just checking against a non-zero value, but it was decided to be changed as potentially the context_offs can be zero even if it is a valid offset. Potentially? Is that the case on OMAP4/5 today? I don't see any for OMAP4 in mainline. No, we don;t have any such cases today in either OMAP4 or OMAP5. If zero really is a valid offset somewhere (where?), then we could use -1 (or USHRT_MAX in this case.) This makes sense for OMAP4 and beyond (and same with having a flag to indicate the *lack* of having the feature) as it will mean just adding a few entries in hwmod data files to indicate IP blocks (very few) which do not support this feature. However since none of OMAP2/3 varients (except I guess the AM family) support this, it would also mean we mark *most* blocks in OMAP2/3 to indicate they *lack* this feature, which would mean bloating the OMAP2/3 data files, but your comment below about doing it for all IPs during hwmod registration makes sense at least for OMAP2 since *all* blocks can be marked at registration. OMAP3 would probably need more data files to be updated to indicate which ones support and which ones don't. Having said that I also see 'context_reg' being defined inside omap_hwmod_omap4_prcm would need to be fixed if we have to support this for SoCs which fall as OMAP3 varients. I just went back and looked at Vaibhavs patch which adds am33xx hwmod data and I think none of what I said above is a problem. I think we can safely mark the few blocks on OMAP4 which do not have a valid context_reg with -1 or USHRT_MAX as you suggested and mark all OMAP2/3 blocks with this at registration. Benoit/Paul, does that sound good? Yeah, but still, every OMAP4 IPs are supporting that except two of them I guess, so it is a pity to add that to every IPs. We'd better add a HWMOD_NO_CONTEXT_REG to the few IPs that are not supporting that. Since OMAP 2 3 does not have this feature at all, we can check on the cpu revision. I think the issue raised by Rajendra was about AM35xx that looks like an OMAP3 variant but does have these registers like an OMAP4 variant:-( If AM335x is missing it for *all* IPs, that's easy enough to solve without bloating the data file: just set .context_offs field (or flag) to the magic value for all IPs during hwmod registration. Paul/Benoit should make the call whether to use a special value in the .context_offs field (0 or -1) or add a new flag. If a flag is chosen, I agree with Benoit that it should indicate the *lack* of the feature, since having the feature is the norm. Kevin -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
