[PATCH] cpufreq: OMAP: specify range for voltage scaling
Specify voltage in ranges for regulator. Range
used is tolerance specified for OPP.
This helps to achieve DVFS with a wider range of
regulators.
Cc: Kevin Hilman khil...@ti.com
Cc: Sekhar Nori nsek...@ti.com
Signed-off-by: Afzal Mohammed af...@ti.com
---
Hi,
Tolerance specified here is that of AM335X, least value
of tolerance that I could find so far for OMAP family
This applies on top of Kevin Hilman's patch (v2),
cpufreq: OMAP: scale voltage along with frequency
http://www.spinics.net/lists/linux-omap/msg65002.html
Regards
Afzal
drivers/cpufreq/omap-cpufreq.c | 10 +++---
1 files changed, 7 insertions(+), 3 deletions(-)
diff --git a/drivers/cpufreq/omap-cpufreq.c b/drivers/cpufreq/omap-cpufreq.c
index 10b8e23..3cea51b 100644
--- a/drivers/cpufreq/omap-cpufreq.c
+++ b/drivers/cpufreq/omap-cpufreq.c
@@ -38,6 +38,9 @@
#include mach/hardware.h
+/* OPP tolerance in percentage */
+#defineOPP_TOLERANCE 4
+
#ifdef CONFIG_SMP
struct lpj_info {
unsigned long ref;
@@ -81,7 +84,7 @@ static int omap_target(struct cpufreq_policy *policy,
int r, ret = 0;
struct cpufreq_freqs freqs;
struct opp *opp;
- unsigned long freq, volt = 0, volt_old = 0;
+ unsigned long freq, volt = 0, volt_old = 0, tol = 0;
if (!freq_table) {
dev_err(mpu_dev, %s: cpu%d: no freq table!\n, __func__,
@@ -125,6 +128,7 @@ static int omap_target(struct cpufreq_policy *policy,
return -EINVAL;
}
volt = opp_get_voltage(opp);
+ tol = volt * OPP_TOLERANCE / 100;
volt_old = regulator_get_voltage(mpu_reg);
}
@@ -134,7 +138,7 @@ static int omap_target(struct cpufreq_policy *policy,
/* scaling up? scale voltage before frequency */
if (mpu_reg (freqs.new freqs.old)) {
- r = regulator_set_voltage(mpu_reg, volt, volt);
+ r = regulator_set_voltage(mpu_reg, volt - tol, volt + tol);
if (r 0) {
dev_warn(mpu_dev, %s: unable to scale voltage up.\n,
__func__);
@@ -147,7 +151,7 @@ static int omap_target(struct cpufreq_policy *policy,
/* scaling down? scale voltage after frequency */
if (mpu_reg (freqs.new freqs.old)) {
- r = regulator_set_voltage(mpu_reg, volt, volt);
+ r = regulator_set_voltage(mpu_reg, volt - tol, volt + tol);
if (r 0) {
dev_warn(mpu_dev, %s: unable to scale voltage down.\n,
__func__);
--
1.7.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
[PATCH v3] ARM: OMAP2+: gpmc-smsc911x: add required smsc911x regulators
This fixes smsc911x support on platforms using gpmc_smsc911x_init().
Commit c7e963f616 (net/smsc911x: Add regulator support) added
the requirement that platforms provide vdd33a and vddvario supplies.
Signed-off-by: Matt Porter mpor...@ti.com
---
Changes for v2:
- temporary fix to avoid platform device id conflicts
- add commit summary from the smsc911x regulator support commit
- incorporate platform device registration error cause reporting
Changes for v3:
- remove unneeded local variable err
arch/arm/mach-omap2/gpmc-smsc911x.c | 52 +++
1 files changed, 52 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/gpmc-smsc911x.c
b/arch/arm/mach-omap2/gpmc-smsc911x.c
index 9970331..bbb870c 100644
--- a/arch/arm/mach-omap2/gpmc-smsc911x.c
+++ b/arch/arm/mach-omap2/gpmc-smsc911x.c
@@ -19,6 +19,8 @@
#include linux/interrupt.h
#include linux/io.h
#include linux/smsc911x.h
+#include linux/regulator/fixed.h
+#include linux/regulator/machine.h
#include plat/board.h
#include plat/gpmc.h
@@ -42,6 +44,50 @@ static struct smsc911x_platform_config gpmc_smsc911x_config
= {
.flags = SMSC911X_USE_16BIT,
};
+static struct regulator_consumer_supply gpmc_smsc911x_supply[] = {
+ REGULATOR_SUPPLY(vddvario, smsc911x.0),
+ REGULATOR_SUPPLY(vdd33a, smsc911x.0),
+};
+
+/* Generic regulator definition to satisfy smsc911x */
+static struct regulator_init_data gpmc_smsc911x_reg_init_data = {
+ .constraints = {
+ .min_uV = 330,
+ .max_uV = 330,
+ .valid_modes_mask = REGULATOR_MODE_NORMAL
+ | REGULATOR_MODE_STANDBY,
+ .valid_ops_mask = REGULATOR_CHANGE_MODE
+ | REGULATOR_CHANGE_STATUS,
+ },
+ .num_consumer_supplies = ARRAY_SIZE(gpmc_smsc911x_supply),
+ .consumer_supplies = gpmc_smsc911x_supply,
+};
+
+static struct fixed_voltage_config gpmc_smsc911x_fixed_reg_data = {
+ .supply_name= gpmc_smsc911x,
+ .microvolts = 330,
+ .gpio = -EINVAL,
+ .startup_delay = 0,
+ .enable_high= 0,
+ .enabled_at_boot= 1,
+ .init_data = gpmc_smsc911x_reg_init_data,
+};
+
+/*
+ * Platform device id of 42 is a temporary fix to avoid conflicts
+ * with other reg-fixed-voltage devices. The real fix should
+ * involve the driver core providing a way of dynamically
+ * assigning a unique id on registration for platform devices
+ * in the same name space.
+ */
+static struct platform_device gpmc_smsc911x_regulator = {
+ .name = reg-fixed-voltage,
+ .id = 42,
+ .dev = {
+ .platform_data = gpmc_smsc911x_fixed_reg_data,
+ },
+};
+
/*
* Initialize smsc911x device connected to the GPMC. Note that we
* assume that pin multiplexing is done in the board-*.c file,
@@ -55,6 +101,12 @@ void __init gpmc_smsc911x_init(struct
omap_smsc911x_platform_data *board_data)
gpmc_cfg = board_data;
+ ret = platform_device_register(gpmc_smsc911x_regulator);
+ if (ret 0) {
+ pr_err(Unable to register smsc911x regulators: %d\n, ret);
+ return;
+ }
+
if (gpmc_cs_request(gpmc_cfg-cs, SZ_16M, cs_mem_base) 0) {
pr_err(Failed to request GPMC mem region\n);
return;
--
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 v2] ARM: OMAP2+: gpmc-smsc911x: add required smsc911x regulators
On Thu, Feb 23, 2012 at 12:08:34PM +, Hiremath, Vaibhav wrote:
On Wed, Feb 22, 2012 at 22:15:03, Porter, Matt wrote:
/*
* Initialize smsc911x device connected to the GPMC. Note that we
* assume that pin multiplexing is done in the board-*.c file,
@@ -51,10 +97,16 @@ void __init gpmc_smsc911x_init(struct
omap_smsc911x_platform_data *board_data)
{
struct platform_device *pdev;
unsigned long cs_mem_base;
- int ret;
+ int ret, err;
Do you really need another variable here? Can't you use ret here?
No we don't, thanks for catching this. I posted a v3 that addresses it.
Tony: can you revert v2 for v3 that I just posted which addresses
Vaibhav's comment?
-Matt
--
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 v2 5/7] ARM: OMAP2+: Split omap2_hsmmc_init() to properly support I2C GPIO pins
Hi Tony, Rajendra,
On 02/23/12 13:40, Rajendra Nayak wrote:
From: Tony Lindgren t...@atomide.com
Otherwise omap_device_build() and omap_mux related functions
can't be marked as __init when twl is build as a module.
If a board is using GPIO pins or regulators configured by an
external chip, such as TWL PMIC on I2C bus, the board must
mark those MMC controllers as deferred. Additionally both
omap_hsmmc_init() and omap_hsmmc_deferred_add() must be called
by the board.
For MMC controllers using internal GPIO pins for card
detect and regulators the slots don't need to be marked
deferred. In this case calling omap_hsmmc_init() is sufficient.
Note that this patch does not change the behaviour for
board-4430sdp.c board-omap4panda.c. These boards wrongly
rely on the omap_hsmmc.c init function callback to configure
the PMIC GPIO interrupt lines on external chip. If the PMIC
interrupt lines are not configured during init, they will
fail.
Reported-by: Russell King rmk+ker...@arm.linux.org.uk
Signed-off-by: Tony Lindgren t...@atomide.com
Signed-off-by: Rajendra Nayak rna...@ti.com
---
arch/arm/mach-omap2/board-2430sdp.c |2 +-
arch/arm/mach-omap2/board-3430sdp.c | 12 ++--
arch/arm/mach-omap2/board-4430sdp.c |4 +-
arch/arm/mach-omap2/board-am3517evm.c|2 +-
arch/arm/mach-omap2/board-cm-t35.c | 10 +-
arch/arm/mach-omap2/board-devkit8000.c |7 +-
arch/arm/mach-omap2/board-igep0020.c | 11 ++-
arch/arm/mach-omap2/board-ldp.c |2 +-
arch/arm/mach-omap2/board-omap3beagle.c |7 +-
arch/arm/mach-omap2/board-omap3evm.c |9 +-
arch/arm/mach-omap2/board-omap3logic.c |2 +-
arch/arm/mach-omap2/board-omap3pandora.c | 13 ++--
arch/arm/mach-omap2/board-omap3stalker.c | 14 ++--
arch/arm/mach-omap2/board-omap3touchbook.c |7 +-
arch/arm/mach-omap2/board-omap4panda.c |4 +-
arch/arm/mach-omap2/board-overo.c|5 +-
arch/arm/mach-omap2/board-rm680.c|2 +-
arch/arm/mach-omap2/board-rx51-peripherals.c |2 +-
arch/arm/mach-omap2/board-zoom-peripherals.c |9 ++-
arch/arm/mach-omap2/hsmmc.c | 117
+++---
arch/arm/mach-omap2/hsmmc.h | 13 ++-
21 files changed, 165 insertions(+), 89 deletions(-)
[...]
diff --git a/arch/arm/mach-omap2/board-cm-t35.c
b/arch/arm/mach-omap2/board-cm-t35.c
index d73316e..14df109 100644
--- a/arch/arm/mach-omap2/board-cm-t35.c
+++ b/arch/arm/mach-omap2/board-cm-t35.c
@@ -411,9 +411,9 @@ static struct omap2_hsmmc_info mmc[] = {
{
.mmc= 1,
.caps = MMC_CAP_4_BIT_DATA,
- .gpio_cd= -EINVAL,
+ .gpio_cd= OMAP_MAX_GPIO_LINES + 0,
.gpio_wp= -EINVAL,
-
+ .deferred = true,
},
{
.mmc= 2,
@@ -422,6 +422,7 @@ static struct omap2_hsmmc_info mmc[] = {
.gpio_cd= -EINVAL,
.gpio_wp= -EINVAL,
.ocr_mask = 0x0010, /* 3.3V */
+ .deferred = true,
Why do you defer this one?
It does not use external GPIO chip, in fact it does not use CD/WP at all.
},
{} /* Terminator */
};
@@ -469,9 +470,7 @@ static int cm_t35_twl_gpio_setup(struct device *dev,
unsigned gpio,
pr_err(CM-T35: could not obtain gpio for WiFi reset\n);
}
- /* gpio + 0 is mmc0_cd (input/IRQ) */
- mmc[0].gpio_cd = gpio + 0;
- omap2_hsmmc_init(mmc);
+ omap_hsmmc_deferred_add(mmc);
return 0;
}
@@ -639,6 +638,7 @@ static void __init cm_t3x_common_init(void)
omap_serial_init();
omap_sdrc_init(mt46h32m32lf6_sdrc_params,
mt46h32m32lf6_sdrc_params);
+ omap_hsmmc_init(mmc);
cm_t35_init_i2c();
omap_ads7846_init(1, CM_T35_GPIO_PENDOWN, 0, NULL);
cm_t35_init_ethernet();
Other then the comment above, looks fine.
I will probably be able to test this on Sunday.
[...]
diff --git a/arch/arm/mach-omap2/board-igep0020.c
b/arch/arm/mach-omap2/board-igep0020.c
index a59ace0..11a6aa4 100644
--- a/arch/arm/mach-omap2/board-igep0020.c
+++ b/arch/arm/mach-omap2/board-igep0020.c
@@ -293,8 +293,9 @@ static struct omap2_hsmmc_info mmc[] = {
{
.mmc= 1,
.caps = MMC_CAP_4_BIT_DATA,
- .gpio_cd= -EINVAL,
+ .gpio_cd= OMAP_MAX_GPIO_LINES + 0,
.gpio_wp= -EINVAL,
+ .deferred = true,
},
#if defined(CONFIG_LIBERTAS_SDIO) || defined(CONFIG_LIBERTAS_SDIO_MODULE)
{
@@ -302,6 +303,7 @@ static struct omap2_hsmmc_info mmc[] = {
.caps = MMC_CAP_4_BIT_DATA,
.gpio_cd=
Re: [GIT PULL] adding rpmsg and remoteproc to 3.4
On Wednesday 22 February 2012, Ohad Ben-Cohen wrote: Hi Arnd, Please pull: git://git.kernel.org/pub/scm/linux/kernel/git/ohad/remoteproc.git rpmsg-for-3.4 To get the very basic rpmsg+remoteproc core functionality for 3.4. This is basically the same stuff I sent for 3.3, with an additional fix and cleanup which were reported by Grant (and of course the two patches that fixed the 3.3 merge conflicts). This entire patch set has been sitting in linux-next for quite some time. I'm not sure if it'd conflict with your tree when you pull it, but I can of course ask Stephen to remove my tree if things look ok to you. Hi Ohad, I've looked at the code again now and pulled it into the arm-soc tree as the next/rpmsg branch, queued for submission to Linus in the 3.4 merge window. There won't be any conflicts in linux-next because the commits are identical, so it doesn't matter whether you leave your branch in linux-next or now. If you have updates on top of this branch, I can apply them directly here. Let's see how things go after v3.4-rc1 before we decide whether you want to keep sending patches to arm-soc for v3.5 as well or whether you just use your own branch then. Arnd -- 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: [GIT PULL] adding rpmsg and remoteproc to 3.4
On Thu, Feb 23, 2012 at 4:31 PM, Arnd Bergmann a...@arndb.de wrote: I've looked at the code again now and pulled it into the arm-soc tree as the next/rpmsg branch, queued for submission to Linus in the 3.4 merge window. There won't be any conflicts in linux-next because the commits are identical, so it doesn't matter whether you leave your branch in linux-next or now. If you have updates on top of this branch, I can apply them directly here. Let's see how things go after v3.4-rc1 before we decide whether you want to keep sending patches to arm-soc for v3.5 as well or whether you just use your own branch then. Thanks! Ohad. -- 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 v2 6/7] ARM: OMAP3: Use .teardown of twl4030-gpio to clean board requests
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi Rajendra,
On 02/23/12 13:40, Rajendra Nayak wrote:
All OMAP3 boards which register a .setup function with twl4030
gpio driver do not seem to have a .teardown hook implemented.
.setup mainly requests a few gpios and also in most cases
does a omap_hsmmc_deferred_add(). Have a .teardown do a gpio_free()
and of the requested gpios and also do a omap_hsmmc_deferred_del().
This helps in case the twl4030 gpio driver is built as a module and
added and removed multiple times. Without the .teardown a multiple
insmod/rmmod can result in gpio request failues and also WARN messages
stating addition of already registered mmc devices.
Reported-by: Russell King rmk+ker...@arm.linux.org.uk
Signed-off-by: Rajendra Nayak rna...@ti.com
---
arch/arm/mach-omap2/board-3430sdp.c | 10 ++
arch/arm/mach-omap2/board-cm-t35.c |8
arch/arm/mach-omap2/board-devkit8000.c | 10 ++
arch/arm/mach-omap2/board-igep0020.c | 14 ++
arch/arm/mach-omap2/board-ldp.c |9 +
arch/arm/mach-omap2/board-omap3beagle.c | 12
arch/arm/mach-omap2/board-omap3evm.c | 10 ++
arch/arm/mach-omap2/board-omap3pandora.c |9 +
arch/arm/mach-omap2/board-omap3stalker.c | 11 +++
arch/arm/mach-omap2/board-omap3touchbook.c | 10 ++
arch/arm/mach-omap2/board-overo.c|8
arch/arm/mach-omap2/board-rx51-peripherals.c |8
arch/arm/mach-omap2/board-zoom-peripherals.c |9 +
arch/arm/mach-omap2/hsmmc.c | 11 +++
arch/arm/mach-omap2/hsmmc.h |4
15 files changed, 143 insertions(+), 0 deletions(-)
[...]
diff --git a/arch/arm/mach-omap2/board-cm-t35.c
b/arch/arm/mach-omap2/board-cm-t35.c
index 14df109..55e0180 100644
--- a/arch/arm/mach-omap2/board-cm-t35.c
+++ b/arch/arm/mach-omap2/board-cm-t35.c
@@ -475,11 +475,19 @@ static int cm_t35_twl_gpio_setup(struct device *dev,
unsigned gpio,
return 0;
}
+static int cm_t35_twl_gpio_teardown(struct device *dev, unsigned gpio,
+ unsigned ngpio)
+{
+ omap_hsmmc_deferred_del(mmc);
+ gpio_free(gpio + 2);
+ return 0;
+}
Can we have an empty line here?
static struct twl4030_gpio_platform_data cm_t35_gpio_data = {
.gpio_base = OMAP_MAX_GPIO_LINES,
.irq_base = TWL4030_GPIO_IRQ_BASE,
.irq_end= TWL4030_GPIO_IRQ_END,
.setup = cm_t35_twl_gpio_setup,
+ .teardown = cm_t35_twl_gpio_teardown,
};
static struct twl4030_platform_data cm_t35_twldata = {
[...]
diff --git a/arch/arm/mach-omap2/board-igep0020.c
b/arch/arm/mach-omap2/board-igep0020.c
index 11a6aa4..1d0850f 100644
--- a/arch/arm/mach-omap2/board-igep0020.c
+++ b/arch/arm/mach-omap2/board-igep0020.c
@@ -435,12 +435,26 @@ static int igep_twl_gpio_setup(struct device *dev,
return 0;
};
+static int igep_twl_gpio_teardown(struct device *dev,
+ unsigned gpio, unsigned ngpio)
+{
+ omap_hsmmc_deferred_del(mmc);
+ gpio_free(gpio + TWL4030_GPIO_MAX + 1);
+ if (machine_is_igep0030())
+ return 0;
+
+ gpio_free(gpio + 1);
+ gpio_free(gpio + TWL4030_GPIO_MAX);
gpio_free_array()?
+ return 0;
+}
+
static struct twl4030_gpio_platform_data igep_twl4030_gpio_pdata = {
.gpio_base = OMAP_MAX_GPIO_LINES,
.irq_base = TWL4030_GPIO_IRQ_BASE,
.irq_end= TWL4030_GPIO_IRQ_END,
.use_leds = true,
.setup = igep_twl_gpio_setup,
+ .teardown = igep_twl_gpio_teardown,
};
static int igep2_enable_dvi(struct omap_dss_device *dssdev)
[...]
diff --git a/arch/arm/mach-omap2/board-overo.c
b/arch/arm/mach-omap2/board-overo.c
index 8b6065b..e1f496d 100644
--- a/arch/arm/mach-omap2/board-overo.c
+++ b/arch/arm/mach-omap2/board-overo.c
@@ -419,12 +419,20 @@ static int overo_twl_gpio_setup(struct device *dev,
return 0;
}
+static int overo_twl_gpio_teardown(struct device *dev,
+ unsigned gpio, unsigned ngpio)
+{
+ omap_hsmmc_deferred_del(mmc);
If Overo will not have omap_hsmmc_deferred_add() (as for my comment to
the previous patch), then no need for the omap_hsmmc_deferred_del().
+ return 0;
+}
+
static struct twl4030_gpio_platform_data overo_gpio_data = {
.gpio_base = OMAP_MAX_GPIO_LINES,
.irq_base = TWL4030_GPIO_IRQ_BASE,
.irq_end= TWL4030_GPIO_IRQ_END,
.use_leds = true,
.setup = overo_twl_gpio_setup,
+ .teardown = overo_twl_gpio_teardown,
};
static struct regulator_init_data overo_vmmc1 = {
[...]
diff --git a/arch/arm/mach-omap2/hsmmc.c b/arch/arm/mach-omap2/hsmmc.c
index 51e3a2d..0f256ca 100644
---
Re: [PATCHv5 03/14] arm: omap3+: voltage: parameter segregation
On Thu, Feb 23, 2012 at 03:08, Tero Kristo t-kri...@ti.com wrote:
On Wed, 2012-02-22 at 19:37 -0600, Menon, Nishanth wrote:
On Tue, Feb 21, 2012 at 08:04, Tero Kristo t-kri...@ti.com wrote:
[...]
diff --git a/arch/arm/mach-omap2/voltage.h b/arch/arm/mach-omap2/voltage.h
index 949938d..940a0d6 100644
--- a/arch/arm/mach-omap2/voltage.h
+++ b/arch/arm/mach-omap2/voltage.h
[...]
@@ -171,6 +169,18 @@ struct omap_voltdm_pmic {
u8 (*uv_to_vsel) (unsigned long uV);
};
+struct omap_vp_param {
+ u32 vddmax;
+ u32 vddmin;
+};
+
Thinking a little deeper about this(SoC level vdd min and max) on a
slightly different angle- core of the question that intend to answer
are:
- what is the least voltage we want to allow in active transtion? it
should not be lower than retention voltage.
I think this is a fair assumption, so we could init the vddmin to be the
same as the retention voltage for the domain (or even drop the
parameter.)
- what is the max voltage we want to allow in active transition? it
should be the max Nom voltage of all the OPPs for that domain.
Isn't it higher? I guess smartreflex can scale voltages even up from the
nominal level if we have a really old and/or bad silicon. Limiting this
to max opp would be bad, no? Maybe we could use max opp voltage + some
margin though... but what would be a safe margin here?
Vnom voltage definition tends to be a variant - yep. at least OMAP3,4 have
intended to have Vnom as the max voltage for the worst corner lot sample
at end of life - aka worst possible voltage for that OPP. But with newer process
technologies of the future SoCs, this definition might turn out to become the
start voltage.
OK, it is safer to have vnom max at max SoC supported voltage i guess to prevent
code churn in the future and maintain compatibility with current SoCs.
Regards,
Nishanth Menon
--
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: OMAP: enable Bluetooth on the PandaBoard
On Thursday 23 February 2012, Mircea Gherzan wrote:
The PandaBoard features a Texas Instruments WiLink7 Bluetooth
chip, supported by the btwilink driver.
Signed-off-by: Mircea Gherzan mgher...@gmail.com
No objections to the patch, but please send it to the maintainer,
not to me. You also misspelled the address of the linux-omap
list, so Tony probably didn't get it there either.
Arnd
diff --git a/arch/arm/mach-omap2/board-omap4panda.c
b/arch/arm/mach-omap2/board-omap4panda.c
index 28fc271..b1d74d6 100644
--- a/arch/arm/mach-omap2/board-omap4panda.c
+++ b/arch/arm/mach-omap2/board-omap4panda.c
@@ -91,9 +91,15 @@ static struct platform_device leds_gpio = {
},
};
+static struct platform_device btwilink_device = {
+ .name = btwilink,
+ .id = -1,
+};
+
static struct platform_device *panda_devices[] __initdata = {
leds_gpio,
wl1271_device,
+ btwilink_device,
};
static const struct usbhs_omap_board_data usbhs_bdata __initconst = {
--
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/7] MFD: twl-core: regulator configuration for twl6030 V1V8, V2V1 SMPS
Hi Peter, On Fri, Feb 10, 2012 at 12:05:12PM +0200, Peter Ujfalusi wrote: To be able to attach consumers to these supplies from board files we need to have regulator_init_data for them. If I understand correctly, this should also go through Liam's tree. If that's so, please add my: Acked-by: Samuel Ortiz sa...@linux.intel.com Cheers, Samuel. -- Intel Open Source Technology Centre http://oss.intel.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: [PATCH v3 1/2] regulator: twl: adapt twl-regulator driver to dt
On Thu, Feb 23, 2012 at 05:05:53PM +0530, Rajendra Nayak wrote: Modify the twl regulator driver to extract the regulator_init_data from device tree when passed, instead of getting it through platform_data structures (on non-DT builds) This doesn't apply to current -next, I expect because of the SMPS regulator changes which went in. Please always submit patches against -next. There's also a patch from Tero adding support for some additional regulators which is floating around and would conflict with this. Could you guys please coordinate with each other on this? signature.asc Description: Digital signature
Re: [PATCH] regulator: twl6030: add support for vdd1, vdd2 and vdd3 regulators
On Thu, Feb 23, 2012 at 01:05:09PM +0200, Tero Kristo wrote:
+static int twl6030coresmps_set_voltage(struct regulator_dev *rdev, int
min_uV,
+ int max_uV, unsigned *selector)
+{
+ struct twlreg_info *info = rdev_get_drvdata(rdev);
+
+ if (info-set_voltage)
+ return info-set_voltage(info-data, min_uV);
+
+ return 0;
+}
This should be returning an error if it failed to set the voltage.
Since you're using min_uV as the register value you probably ought to
be returning that as the selector too and supplying a list_voltage()
which just passes the selector back in case something tries to use it
and gets confused.
+static int twl6030coresmps_get_voltage(struct regulator_dev *rdev)
+{
+ struct twlreg_info *info = rdev_get_drvdata(rdev);
+
+ if (info-get_voltage)
+ return info-get_voltage(info-data);
+
+ return 0;
Similarly here.
signature.asc
Description: Digital signature
Re: [PATCH 0/2] mfd: omap-usb-host: Minor omap-usb host fixes
Hi Govindraj, On Wed, Feb 15, 2012 at 03:53:32PM +0530, Govindraj.R wrote: From: Govindraj.R govindraj.r...@ti.com Minor fixes, boot tested on panda with ehci enabled. Patches based on 3.3-rc3 Govindraj.R (2): mfd: omap-usb-host: Remove magic numbers for dev dma mask mfd: omap-usb-host: Move usbhs init before allocing child dev Both patches applied (v2 for the first one). Cheers, Samuel. -- Intel Open Source Technology Centre http://oss.intel.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: [RFC PATCH 1/2] of: Add generic device tree DMA helpers
On 02/23/2012 11:03 AM, Cousson, Benoit :
Salut Nico,
Coucou Benoit ;-)
On 2/22/2012 11:59 AM, Nicolas Ferre wrote:
On 01/27/2012 06:29 PM, Cousson, Benoit :
Add some basic helpers to retrieve a DMA controller device_node
and the DMA request line number.
For legacy reason another API will export the DMA request number
into a Linux resource of type IORESOURCE_DMA.
This API is usable only on system with an unique DMA controller.
Hi,
I followed that discussion and I like very much the biding that Benoit
is proposing. It will help me a lot with my current work on Atmel DMA
controller.
If I understand correctly, some rework is needed before it can be
integrated in a stable git tree (I mean before we can base our work on
top of it). So, in the meantime, what should I do to help and make
things go forward? to be quite frank, I would be interested to have a
working DMA enabled device soon ;-)
Me too, but unfortunately, I was busy trying to add irq_domain and
fixing issues with SPARSE_IRQ on OMAP :-(
Been there, loved that ;-)
Do you think that 3.4 is out of reach?
Maybe not, from the comments, it looks like we should add a .xlate
callback to allow any custom parsing of the DMA nodes attributes.
I'll be more than happy, if you can finalize that patch :-)
I will try to figure out what I can understand from the irq mechanism of
.xlate and try to see if I can implement it on top of your patch.
I will keep you informed...
Bye,
Best regards,
Signed-off-by: Benoit Coussonb-cous...@ti.com
Cc: Grant Likelygrant.lik...@secretlab.ca
Cc: Rob Herringrob.herr...@calxeda.com
---
Documentation/devicetree/bindings/dma/dma.txt | 44 +
drivers/of/Kconfig|5 +
drivers/of/Makefile |1 +
drivers/of/dma.c | 130
+
include/linux/of_dma.h| 49 +
5 files changed, 229 insertions(+), 0 deletions(-)
create mode 100644 Documentation/devicetree/bindings/dma/dma.txt
create mode 100644 drivers/of/dma.c
create mode 100644 include/linux/of_dma.h
diff --git a/Documentation/devicetree/bindings/dma/dma.txt
b/Documentation/devicetree/bindings/dma/dma.txt
new file mode 100644
index 000..7f2a301
--- /dev/null
+++ b/Documentation/devicetree/bindings/dma/dma.txt
@@ -0,0 +1,44 @@
+* Generic DMA Controller and DMA request bindings
+
+Generic binding to provide a way for a driver to retrieve the
+DMA request line that goes from an IP to a DMA controller.
+
+
+* DMA controller
+
+Required properties:
+- dma-controller: Mark the device as a DMA controller
+- #dma-cells: Number of cell for each DMA line, must be one.
+
+
+Example:
+
+sdma: dma-controller@4800 {
+compatible = ti,sdma-omap4
+reg =0x4800 0x1000;
+interrupts =12;
+dma-controller;
+#dma-cells =1;
+};
+
+
+
+* DMA client
+
+Client drivers should specify the DMA request numbers using a
phandle to
+the controller + the DMA request number on that controller.
+
+Required properties:
+- dma-request: List of pair phandle + dma-request per line
+- dma-request-names: list of strings in the same order as the
dma-request
+ in the dma-request property.
+
+
+Example:
+
+i2c1: i2c@1 {
+...
+dma-request =sdma 2sdma 3;
+dma-request-names = tx, rx;
+...
+};
diff --git a/drivers/of/Kconfig b/drivers/of/Kconfig
index 268163d..7d1f06b 100644
--- a/drivers/of/Kconfig
+++ b/drivers/of/Kconfig
@@ -90,4 +90,9 @@ config OF_PCI_IRQ
help
OpenFirmware PCI IRQ routing helpers
+config OF_DMA
+def_bool y
+help
+ Device Tree DMA routing helpers
+
endmenu # OF
diff --git a/drivers/of/Makefile b/drivers/of/Makefile
index a73f5a5..d08443b 100644
--- a/drivers/of/Makefile
+++ b/drivers/of/Makefile
@@ -12,3 +12,4 @@ obj-$(CONFIG_OF_SELFTEST) += selftest.o
obj-$(CONFIG_OF_MDIO)+= of_mdio.o
obj-$(CONFIG_OF_PCI)+= of_pci.o
obj-$(CONFIG_OF_PCI_IRQ) += of_pci_irq.o
+obj-$(CONFIG_OF_DMA) += dma.o
diff --git a/drivers/of/dma.c b/drivers/of/dma.c
new file mode 100644
index 000..d4927e2
--- /dev/null
+++ b/drivers/of/dma.c
@@ -0,0 +1,130 @@
+/*
+ * Device tree helpers for DMA request / controller
+ *
+ * Based on of_gpio.c
+ *
+ * Copyright (C) 2012 Texas Instruments Incorporated -
http://www.ti.com/
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#includelinux/device.h
+#includelinux/err.h
+#includelinux/module.h
+#includelinux/of.h
+#includelinux/of_dma.h
+
+/**
+ * of_get_dma_request() - Get a DMA request number and
dma-controller node
+ * @np:device node to get DMA request from
+ *
Re: [RFC PATCH 1/2] of: Add generic device tree DMA helpers
On 2/23/2012 4:51 PM, Nicolas Ferre wrote: On 02/23/2012 11:03 AM, Cousson, Benoit : Salut Nico, Coucou Benoit ;-) On 2/22/2012 11:59 AM, Nicolas Ferre wrote: On 01/27/2012 06:29 PM, Cousson, Benoit : Add some basic helpers to retrieve a DMA controller device_node and the DMA request line number. For legacy reason another API will export the DMA request number into a Linux resource of type IORESOURCE_DMA. This API is usable only on system with an unique DMA controller. Hi, I followed that discussion and I like very much the biding that Benoit is proposing. It will help me a lot with my current work on Atmel DMA controller. If I understand correctly, some rework is needed before it can be integrated in a stable git tree (I mean before we can base our work on top of it). So, in the meantime, what should I do to help and make things go forward? to be quite frank, I would be interested to have a working DMA enabled device soon ;-) Me too, but unfortunately, I was busy trying to add irq_domain and fixing issues with SPARSE_IRQ on OMAP :-( Been there, loved that ;-) Do you think that 3.4 is out of reach? Maybe not, from the comments, it looks like we should add a .xlate callback to allow any custom parsing of the DMA nodes attributes. I'll be more than happy, if you can finalize that patch :-) I will try to figure out what I can understand from the irq mechanism of .xlate and try to see if I can implement it on top of your patch. In fact that dma code is a big copy/paste of the of/gpio one and gpio was already managing .xlate function. I removed it because I thought it was useless for the DMA :-) You might just have to copy the original code... I will keep you informed... Thanks for the help, 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 2/6] ARM: OMAP4 PM: Add IO Daisychain support
Hi Kristo,
I think you must also add a omap_test_timeout() check after the Trigger WUCLKIN
disable, to verify WUCLK_STATUS has come back to 0.
This is needed because the IO daisy chain will not be ready until the WUCLKIN
falling edge has propagated.
+ /* Trigger WUCLKIN disable */
+ omap4_prm_rmw_inst_reg_bits(OMAP4430_WUCLK_CTRL_MASK, 0x0,
+ OMAP4430_PRM_DEVICE_INST, OMAP4_PRM_IO_PMCTRL_OFFSET);
+ return;
+ omap_test_timeout(
+ (((omap4_prm_read_inst_reg(OMAP4430_PRM_DEVICE_INST,
+ OMAP4_PRM_IO_PMCTRL_OFFSET)
+ OMAP4430_WUCLK_STATUS_MASK)
+ OMAP4430_WUCLK_STATUS_SHIFT) == 0),
+ MAX_IOPAD_LATCH_TIME, i);
Best regards
Djamil ELAÏDI
+33 4 97 27 50 97
Software Systems Engineer
OMAP Platform Business Unit - PSI Modem Integration
Texas Instruments
Texas Instruments France SA, 821 Avenue Jack Kilby, 06270 Villeneuve Loubet.
036 420 040 R.C.S Antibes. Capital de EUR 753.920
-Original Message-
From: linux-omap-ow...@vger.kernel.org
[mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of Kristo, Tero
Sent: jeudi 23 février 2012 14:22
To: linux-omap@vger.kernel.org; Hilman, Kevin
Cc: linux-arm-ker...@lists.infradead.org; Nayak, Rajendra; Sripathy, Vishwanath
Subject: [PATCH 2/6] ARM: OMAP4 PM: Add IO Daisychain support
From: Rajendra Nayak rna...@ti.com
patch adds IO Daisychain support for OMAP4 as per section 3.9.4 in OMAP4430
Public TRM.
Signed-off-by: Rajendra Nayak rna...@ti.com
Signed-off-by: Vishwanath BS vishwanath...@ti.com
Signed-off-by: Tero Kristo t-kri...@ti.com
---
arch/arm/mach-omap2/prm44xx.c | 32
arch/arm/mach-omap2/prm44xx.h |1 +
2 files changed, 33 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/prm44xx.c b/arch/arm/mach-omap2/prm44xx.c
index 33dd655..1557647 100644
--- a/arch/arm/mach-omap2/prm44xx.c
+++ b/arch/arm/mach-omap2/prm44xx.c
@@ -230,6 +230,41 @@ void omap44xx_prm_restore_irqen(u32 *saved_mask)
OMAP4_PRM_IRQENABLE_MPU_2_OFFSET);
}
+/**
+ * Maximum time(us) it takes to output the signal WUCLKOUT of the last pad of
+ * the I/O ring after asserting WUCLKIN high
+ */
+#define MAX_IOPAD_LATCH_TIME 1000
+
+/* OMAP4 IO Daisychain trigger sequence */
+void omap4_trigger_wuclk_ctrl(void)
+{
+ int i = 0;
+
+ /* Enable GLOBAL_WUEN */
+ if (!(omap4_prm_read_inst_reg(OMAP4430_PRM_DEVICE_INST,
+ OMAP4_PRM_IO_PMCTRL_OFFSET) OMAP4430_GLOBAL_WUEN_MASK))
+ omap4_prm_rmw_inst_reg_bits(OMAP4430_GLOBAL_WUEN_MASK,
+ OMAP4430_GLOBAL_WUEN_MASK, OMAP4430_PRM_DEVICE_INST,
+ OMAP4_PRM_IO_PMCTRL_OFFSET);
+
+ /* Trigger WUCLKIN enable */
+ omap4_prm_rmw_inst_reg_bits(OMAP4430_WUCLK_CTRL_MASK,
+ OMAP4430_WUCLK_CTRL_MASK, OMAP4430_PRM_DEVICE_INST,
+ OMAP4_PRM_IO_PMCTRL_OFFSET);
+ omap_test_timeout(
+ (((omap4_prm_read_inst_reg(OMAP4430_PRM_DEVICE_INST,
+ OMAP4_PRM_IO_PMCTRL_OFFSET)
+ OMAP4430_WUCLK_STATUS_MASK)
+ OMAP4430_WUCLK_STATUS_SHIFT) == 1),
+ MAX_IOPAD_LATCH_TIME, i);
+
+ /* Trigger WUCLKIN disable */
+ omap4_prm_rmw_inst_reg_bits(OMAP4430_WUCLK_CTRL_MASK, 0x0,
+ OMAP4430_PRM_DEVICE_INST, OMAP4_PRM_IO_PMCTRL_OFFSET);
+ return;
+}
+
static int __init omap4xxx_prcm_init(void)
{
if (cpu_is_omap44xx())
diff --git a/arch/arm/mach-omap2/prm44xx.h b/arch/arm/mach-omap2/prm44xx.h
index 7978092..a840f0f 100644
--- a/arch/arm/mach-omap2/prm44xx.h
+++ b/arch/arm/mach-omap2/prm44xx.h
@@ -762,6 +762,7 @@ void omap4_prm_vp_clear_txdone(u8 vp_id);
extern u32 omap4_prm_vcvp_read(u8 offset);
extern void omap4_prm_vcvp_write(u32 val, u8 offset);
extern u32 omap4_prm_vcvp_rmw(u32 mask, u32 bits, u8 offset);
+extern void omap4_trigger_wuclk_ctrl(void);
/* PRM interrupt-related functions */
extern void omap44xx_prm_read_pending_irqs(unsigned long *events);
--
1.7.4.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
--
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 v2 2/2] iommu/omap: fix NULL pointer dereference
I guess these patches are 3.3 material? How about tagging them for
stable too?
On Wed, Feb 22, 2012 at 11:14:46AM +0200, Ohad Ben-Cohen wrote:
Fix this:
root@omap4430-panda:~# cat /debug/iommu/ducati/mem
[ 62.725708] Unable to handle kernel NULL pointer dereference at virtual
addre
ss 001c
[ 62.725708] pgd = e624
[ 62.737091] [001c] *pgd=a7168831, *pte=, *ppte=
[ 62.743682] Internal error: Oops: 17 [#1] SMP
[ 62.743682] Modules linked in: omap_iommu_debug omap_iovmm
virtio_rpmsg_bus o
map_remoteproc remoteproc virtio_ring virtio mailbox_mach mailbox
[ 62.743682] CPU: 0Not tainted (3.3.0-rc1-00265-g382f84e-dirty #682)
[ 62.743682] PC is at debug_read_mem+0x5c/0xac [omap_iommu_debug]
[ 62.743682] LR is at 0x1004
[ 62.777832] pc : [bf033178]lr : [1004]psr: 6013
[ 62.777832] sp : e72c7f40 ip : c0763c00 fp : 0001
[ 62.777832] r10: r9 : r8 : e72c7f80
[ 62.777832] r7 : e6ffdc08 r6 : bed1ac78 r5 : 1000 r4 : e7276000
[ 62.777832] r3 : e60f3460 r2 : r1 : e60f38c0 r0 :
[ 62.777832] Flags: nZCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment
user
[ 62.816375] Control: 10c53c7d Table: a624004a DAC: 0015
[ 62.816375] Process cat (pid: 1176, stack limit = 0xe72c62f8)
[ 62.828369] Stack: (0xe72c7f40 to 0xe72c8000)
...
[ 62.884185] [bf033178] (debug_read_mem+0x5c/0xac [omap_iommu_debug])
from [
c010e354] (vfs_read+0xac/0x130)
[ 62.884185] [c010e354] (vfs_read+0xac/0x130) from [c010e4a8]
(sys_read+0x
40/0x70)
[ 62.884185] [c010e4a8] (sys_read+0x40/0x70) from [c0014a00]
(ret_fast_sys
call+0x0/0x3c)
Fix also its 'echo bla /debug/iommu/ducati/mem' Oops sibling, too.
Signed-off-by: Ohad Ben-Cohen o...@wizery.com
Cc: Tony Lindgren t...@atomide.com
Cc: Hiroshi Doyu hd...@nvidia.com
Cc: Laurent Pinchart laurent.pinch...@ideasonboard.com
Cc: Russell King li...@arm.linux.org.uk
Cc: Joerg Roedel joerg.roe...@amd.com
---
v2: omap_find_iovm_area only returns NULL for errors. thanks, rmk.
drivers/iommu/omap-iommu-debug.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/iommu/omap-iommu-debug.c
b/drivers/iommu/omap-iommu-debug.c
index bad9f9d..103dbd9 100644
--- a/drivers/iommu/omap-iommu-debug.c
+++ b/drivers/iommu/omap-iommu-debug.c
@@ -274,7 +274,7 @@ static ssize_t debug_read_mem(struct file *file, char
__user *userbuf,
mutex_lock(iommu_debug_lock);
area = omap_find_iovm_area(dev, (u32)ppos);
- if (IS_ERR(area)) {
+ if (!area) {
bytes = -EINVAL;
goto err_out;
}
@@ -311,7 +311,7 @@ static ssize_t debug_write_mem(struct file *file, const
char __user *userbuf,
}
area = omap_find_iovm_area(dev, (u32)ppos);
- if (IS_ERR(area)) {
+ if (!area) {
count = -EINVAL;
goto err_out;
}
--
1.7.5.4
--
AMD Operating System Research Center
Advanced Micro Devices GmbH Einsteinring 24 85609 Dornach
General Managers: Alberto Bozzo
Registration: Dornach, Landkr. Muenchen; Registerger. Muenchen, HRB Nr. 43632
--
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 v2 2/2] iommu/omap: fix NULL pointer dereference
On Thu, Feb 23, 2012 at 6:11 PM, Joerg Roedel joerg.roe...@amd.com wrote: I guess these patches are 3.3 material? Yes. How about tagging them for stable too? Good point. But it's only relevant for this 2nd patch (the NULL pointer dereference fix), as the first one is a 3.3 regression. Let me know if you want me to resend the 2nd one with the stable tag. Thanks, Ohad. -- 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 v2 2/2] iommu/omap: fix NULL pointer dereference
On Thu, Feb 23, 2012 at 06:16:59PM +0200, Ohad Ben-Cohen wrote: On Thu, Feb 23, 2012 at 6:11 PM, Joerg Roedel joerg.roe...@amd.com wrote: I guess these patches are 3.3 material? Yes. How about tagging them for stable too? Good point. But it's only relevant for this 2nd patch (the NULL pointer dereference fix), as the first one is a 3.3 regression. Let me know if you want me to resend the 2nd one with the stable tag. Not necessary. I'll add it when I apply the patch. Thanks, Joerg -- AMD Operating System Research Center Advanced Micro Devices GmbH Einsteinring 24 85609 Dornach General Managers: Alberto Bozzo Registration: Dornach, Landkr. Muenchen; Registerger. Muenchen, HRB Nr. 43632 -- 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: OMAP2: fix mailbox init code
Hi,
On Thu, Feb 23, 2012 at 3:18 AM, Bedia, Vaibhav vaibhav.be...@ti.com wrote:
On Thu, Feb 23, 2012 at 14:23:35, Ohad Ben-Cohen wrote:
[...]
Which happens on CONFIG_ARCH_OMAP2 !CONFIG_SOC_OMAP2420, due to
missing omap2_mboxes declaration.
[...]
-struct omap_mbox *omap2_mboxes[] = { mbox_dsp_info, mbox_iva_info, NULL };
+#ifdef CONFIG_ARCH_OMAP2
+struct omap_mbox *omap2_mboxes[] = {
+ mbox_dsp_info,
+#ifdef CONFIG_SOC_OMAP2420
+ mbox_iva_info,
+#endif
+ NULL
+};
#endif
#if defined(CONFIG_ARCH_OMAP4)
Instead of adding more #ifs can they be completely removed please?
I'll rebase/repost this series:
[PATCH 0/7] OMAP: mailbox: removing static declarations
http://comments.gmane.org/gmane.linux.ports.arm.omap/59620
In the meantime I would appreciate comments.
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: [PATCH] ARM: OMAP2: fix mailbox init code
On Thu, Feb 23, 2012 at 11:18 AM, Bedia, Vaibhav vaibhav.be...@ti.com wrote: Instead of adding more #ifs can they be completely removed please? Care to propose something specific (which is viable for the -rc cycle) ? Thanks, Ohad. -- 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 RESEND] ARM: OMAP: enable Bluetooth on the PandaBoard
The PandaBoard features a Texas Instruments WiLink7 Bluetooth
chip, supported by the btwilink driver.
Signed-off-by: Mircea Gherzan mgher...@gmail.com
---
arch/arm/mach-omap2/board-omap4panda.c |6 ++
1 files changed, 6 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/board-omap4panda.c
b/arch/arm/mach-omap2/board-omap4panda.c
index 28fc271..b1d74d6 100644
--- a/arch/arm/mach-omap2/board-omap4panda.c
+++ b/arch/arm/mach-omap2/board-omap4panda.c
@@ -91,9 +91,15 @@ static struct platform_device leds_gpio = {
},
};
+static struct platform_device btwilink_device = {
+ .name = btwilink,
+ .id = -1,
+};
+
static struct platform_device *panda_devices[] __initdata = {
leds_gpio,
wl1271_device,
+ btwilink_device,
};
static const struct usbhs_omap_board_data usbhs_bdata __initconst = {
--
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 v2 5/7] ARM: OMAP2+: Split omap2_hsmmc_init() to properly support I2C GPIO pins
* Igor Grinberg grinb...@compulab.co.il [120223 05:56]:
--- a/arch/arm/mach-omap2/board-cm-t35.c
+++ b/arch/arm/mach-omap2/board-cm-t35.c
@@ -411,9 +411,9 @@ static struct omap2_hsmmc_info mmc[] = {
{
.mmc= 1,
.caps = MMC_CAP_4_BIT_DATA,
- .gpio_cd= -EINVAL,
+ .gpio_cd= OMAP_MAX_GPIO_LINES + 0,
.gpio_wp= -EINVAL,
I don't have these changes, in my second revision of the patch.
It's best not to hardcode the values here.
-
+ .deferred = true,
},
{
.mmc= 2,
@@ -422,6 +422,7 @@ static struct omap2_hsmmc_info mmc[] = {
.gpio_cd= -EINVAL,
.gpio_wp= -EINVAL,
.ocr_mask = 0x0010, /* 3.3V */
+ .deferred = true,
Why do you defer this one?
It does not use external GPIO chip, in fact it does not use CD/WP at all.
Why do you have the following then to set gpio_cd?
},
{} /* Terminator */
};
@@ -469,9 +470,7 @@ static int cm_t35_twl_gpio_setup(struct device *dev,
unsigned gpio,
pr_err(CM-T35: could not obtain gpio for WiFi reset\n);
}
- /* gpio + 0 is mmc0_cd (input/IRQ) */
- mmc[0].gpio_cd = gpio + 0;
- omap2_hsmmc_init(mmc);
+ omap_hsmmc_deferred_add(mmc);
return 0;
}
Hmm I don't have omap_hsmmc_deferred_add() in my second version
of the patch either.
Rajendra, please do the patches on that, now it's impossible to
see what else you've changed. That's the version posted here:
http://www.spinics.net/lists/linux-omap/msg64884.html
@@ -639,6 +638,7 @@ static void __init cm_t3x_common_init(void)
omap_serial_init();
omap_sdrc_init(mt46h32m32lf6_sdrc_params,
mt46h32m32lf6_sdrc_params);
+ omap_hsmmc_init(mmc);
cm_t35_init_i2c();
omap_ads7846_init(1, CM_T35_GPIO_PENDOWN, 0, NULL);
cm_t35_init_ethernet();
Other then the comment above, looks fine.
I will probably be able to test this on Sunday.
OK
diff --git a/arch/arm/mach-omap2/board-igep0020.c
b/arch/arm/mach-omap2/board-igep0020.c
index a59ace0..11a6aa4 100644
--- a/arch/arm/mach-omap2/board-igep0020.c
+++ b/arch/arm/mach-omap2/board-igep0020.c
@@ -293,8 +293,9 @@ static struct omap2_hsmmc_info mmc[] = {
{
.mmc= 1,
.caps = MMC_CAP_4_BIT_DATA,
- .gpio_cd= -EINVAL,
+ .gpio_cd= OMAP_MAX_GPIO_LINES + 0,
.gpio_wp= -EINVAL,
+ .deferred = true,
},
#if defined(CONFIG_LIBERTAS_SDIO) || defined(CONFIG_LIBERTAS_SDIO_MODULE)
{
@@ -302,6 +303,7 @@ static struct omap2_hsmmc_info mmc[] = {
.caps = MMC_CAP_4_BIT_DATA,
.gpio_cd= -EINVAL,
.gpio_wp= -EINVAL,
+ .deferred = true,
same here, why defer it?
Because it too sets gpio_cd in the callback.
ditto
ditto, that too sets gpio_cd..
},
#endif
{} /* Terminator */
@@ -360,10 +362,8 @@ static int omap3evm_twl_gpio_setup(struct device *dev,
{
int r, lcd_bl_en;
- /* gpio + 0 is mmc0_cd (input/IRQ) */
omap_mux_init_gpio(63, OMAP_PIN_INPUT);
- mmc[0].gpio_cd = gpio + 0;
..here. Same for the others. So maybe check is some are wrong?
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: [PATCH v2 0/7] omap hsmmc init cleanup and section warning fixes for v3.4 merge window
* Rajendra Nayak rna...@ti.com [120223 03:09]: Re-sending as these patches did not make it to the lists due to issues with my 'git send-email' Hi Tony, This is a re-spin of your series to fix up the section mismatch warnings noted by Russell with omap2_hsmmc_init(). The previous series had an issue around multiple insmod/rmmod of the twl4030 gpio driver when built as a module as reported by Russell again. OK, can you please rebase your patches on hsmmc branch in linux-omap at commit 0e91c8ddf0e0932da59ec1d116e34049791b0e73? Note that at least the hardcoded GPIO numbers are no longer needed. There were 2 issues, one with gpio_requests failing as they were never freed on the module unload/unbind. The other was with the mmc devices being registered again. I have fixed both these issues in this series, mainly by having a .teardown hook for twl4030 gpio driver populated from all OMAP3 board files, which release all the requested gpios and also unregister the mmc omap/platform device. Yes that's great. 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: [PATCH v2 4/4] arm/dts: OMAP3: Add mmc controller nodes and board data
--- a/arch/arm/boot/dts/omap3.dtsi
+++ b/arch/arm/boot/dts/omap3.dtsi
@@ -113,5 +113,31 @@
#size-cells = 0;
ti,hwmods = i2c3;
};
+
+ mmc1: mmc@1 {
+ compatible = ti,omap2-hsmmc;
+ ti,hwmods = mmc1;
+ ti,dual-volt;
+ };
+
+ mmc2: mmc@2 {
+ compatible = ti,omap2-hsmmc;
+ ti,hwmods = mmc2;
+ };
+
+ mmc3: mmc@3 {
+ compatible = ti,omap2-hsmmc;
+ ti,hwmods = mmc3;
+ };
+
+ mmc4: mmc@4 {
+ compatible = ti,omap2-hsmmc;
+ ti,hwmods = mmc4;
+ };
+
+ mmc5: mmc@5 {
+ compatible = ti,omap2-hsmmc;
+ ti,hwmods = mmc5;
+ };
};
};
These all should all be ti,omap3-hsmmc I guess?
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: [PATCH] ARM: OMAP: enable Bluetooth on the PandaBoard
* Arnd Bergmann a...@arndb.de [120223 06:41]:
On Thursday 23 February 2012, Mircea Gherzan wrote:
The PandaBoard features a Texas Instruments WiLink7 Bluetooth
chip, supported by the btwilink driver.
Signed-off-by: Mircea Gherzan mgher...@gmail.com
No objections to the patch, but please send it to the maintainer,
not to me. You also misspelled the address of the linux-omap
list, so Tony probably didn't get it there either.
Thanks, seeing the repost now. Will queue it.
Tony
diff --git a/arch/arm/mach-omap2/board-omap4panda.c
b/arch/arm/mach-omap2/board-omap4panda.c
index 28fc271..b1d74d6 100644
--- a/arch/arm/mach-omap2/board-omap4panda.c
+++ b/arch/arm/mach-omap2/board-omap4panda.c
@@ -91,9 +91,15 @@ static struct platform_device leds_gpio = {
},
};
+static struct platform_device btwilink_device = {
+ .name = btwilink,
+ .id = -1,
+};
+
static struct platform_device *panda_devices[] __initdata = {
leds_gpio,
wl1271_device,
+ btwilink_device,
};
static const struct usbhs_omap_board_data usbhs_bdata __initconst = {
--
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
--
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: OMAP2: fix mailbox init code
* Ohad Ben-Cohen o...@wizery.com [120223 08:32]: On Thu, Feb 23, 2012 at 11:18 AM, Bedia, Vaibhav vaibhav.be...@ti.com wrote: Instead of adding more #ifs can they be completely removed please? Care to propose something specific (which is viable for the -rc cycle) ? This is pretty much the minimal change for -rc cycle so I'll apply this into fixes. 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: [PATCH 5/6] ARM: OMAP4: suspend: Do not get dsp/tesla out of reset
On 2/23/2012 2:56 PM, Shilimkar, Santosh wrote: $Subject s/dsp/DSP s/tesla/TESLA Even better... remove tesla :-) This is an internal codename that at some point should be removed from the clkdm name. I just did not have the time to do that for OMAP4, but it will not exist anymore on OMAP5. Nit: The subject should be: ARM: OMAP4: hwmod data: Do not get DSP out of reset at boot time Regards, Benoit On Thu, Feb 23, 2012 at 6:51 PM, Tero Kristot-kri...@ti.com wrote: From: Rajendra Nayakrna...@ti.com With no driver handling DSP/TESLA, if brought out of reset, it stays active and does not assert standby. Which lead to IVHA PD not transitiong and hence gating CHIP retention. You may want to add these bits as well. Signed-off-by: Rajendra Nayakrna...@ti.com Signed-off-by: Tero Kristot-kri...@ti.com --- Patch is fine though script needs to be updated I guess 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 -- 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: OMAP2+: Set Kconfig dependencies for PROC_DEVICETREE
Otherwise we get: warning: (ARCH_OMAP2PLUS) selects PROC_DEVICETREE which has unmet direct dependencies (OF PROC_FS !SPARC) Signed-off-by: Tony Lindgren t...@atomide.com --- Looks like this is needed for what we have queued in the omap dt branch. --- a/arch/arm/plat-omap/Kconfig +++ b/arch/arm/plat-omap/Kconfig @@ -26,7 +26,7 @@ config ARCH_OMAP2PLUS select GENERIC_IRQ_CHIP select OMAP_DM_TIMER select USE_OF - select PROC_DEVICETREE + select PROC_DEVICETREE if PROC_FS help Systems based on OMAP2, OMAP3 or OMAP4 -- 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/5] ARM: OMAP: Fix SPARSE_IRQ on OMAP4 - Episode I
Hi Tony, Here is a first, and incomplete, attempt to make OMAP4 SPARSE_IRQ friendly. GPIO is still broken, and will be fixed later. It is still not clear how we can get rid of the board IRQ configuration properly without device tree. So the complete SPARSE_IRQ migration might be achievable only when DT convertion will be done :-( I started removing as well the IRQs definition header to start tracking the bad drivers that still need to be cleaned or hwmod or DT adapted. Regards, Benoit Benoit Cousson (5): ARM: OMAP2+: l3_noc: Remove references to static IRQ defines ARM: OMAP: irqs: Delete irqs-44xx.h file ARM: OMAP2+: wakeupgen: Fix wrong array size for irq_target_cpu ARM: OMAP2+: gpmc: Use irq_alloc_descs instead of static IRQ range ARM: OMAP: irqs: Set NR_IRQS to NR_IRQS_LEGACY for CONFIG_SPARSE_IRQ arch/arm/mach-omap2/gpmc.c | 22 +++-- arch/arm/mach-omap2/omap-wakeupgen.c|4 +- arch/arm/mach-omap2/omap_l3_noc.c |6 +- arch/arm/plat-omap/include/plat/irqs-44xx.h | 144 --- arch/arm/plat-omap/include/plat/irqs.h | 19 +++- 5 files changed, 35 insertions(+), 160 deletions(-) delete mode 100644 arch/arm/plat-omap/include/plat/irqs-44xx.h -- 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/5] ARM: OMAP2+: l3_noc: Remove references to static IRQ defines
The irq numbers are retrieved dynamically but the error logging
is still referring to the OMAP44XX_IRQ_XXX defines instead of the
irq number returned by platform_get_irq.
Remove this reference to allow deletion of the irqs-44xx.h files.
Clean the message and replace the pr_ macro by the dev_ equivalent.
Signed-off-by: Benoit Cousson b-cous...@ti.com
Cc: Santosh Shilimkar santosh.shilim...@ti.com
---
arch/arm/mach-omap2/omap_l3_noc.c |6 ++
1 files changed, 2 insertions(+), 4 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_l3_noc.c
b/arch/arm/mach-omap2/omap_l3_noc.c
index d15225f..46e44f4 100644
--- a/arch/arm/mach-omap2/omap_l3_noc.c
+++ b/arch/arm/mach-omap2/omap_l3_noc.c
@@ -189,8 +189,7 @@ static int __devinit omap4_l3_probe(struct platform_device
*pdev)
l3_interrupt_handler,
IRQF_DISABLED, l3-dbg-irq, l3);
if (ret) {
- pr_crit(L3: request_irq failed to register for 0x%x\n,
- OMAP44XX_IRQ_L3_DBG);
+ dev_crit(pdev-dev, Request IRQ %d failed\n, l3-debug_irq);
goto err3;
}
@@ -199,8 +198,7 @@ static int __devinit omap4_l3_probe(struct platform_device
*pdev)
l3_interrupt_handler,
IRQF_DISABLED, l3-app-irq, l3);
if (ret) {
- pr_crit(L3: request_irq failed to register for 0x%x\n,
- OMAP44XX_IRQ_L3_APP);
+ dev_crit(pdev-dev, Request IRQ %d failed\n, l3-app_irq);
goto err4;
}
--
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
[PATCH 2/5] ARM: OMAP: irqs: Delete irqs-44xx.h file
Since all IRQs should be retrieved using hwmod for the moment and then device tree in the future, there is no need to keep a file defining all the IRQ numbers. Delete the file and copy the 4 entries that are still used directly by the board / driver until the code is properly cleaned. Signed-off-by: Benoit Cousson b-cous...@ti.com --- arch/arm/plat-omap/include/plat/irqs-44xx.h | 144 --- arch/arm/plat-omap/include/plat/irqs.h | 15 +++- 2 files changed, 12 insertions(+), 147 deletions(-) delete mode 100644 arch/arm/plat-omap/include/plat/irqs-44xx.h diff --git a/arch/arm/plat-omap/include/plat/irqs-44xx.h b/arch/arm/plat-omap/include/plat/irqs-44xx.h deleted file mode 100644 index 518322c..000 --- a/arch/arm/plat-omap/include/plat/irqs-44xx.h +++ /dev/null @@ -1,144 +0,0 @@ -/* - * OMAP4 Interrupt lines definitions - * - * Copyright (C) 2009-2010 Texas Instruments, Inc. - * - * Santosh Shilimkar (santosh.shilim...@ti.com) - * Benoit Cousson (b-cous...@ti.com) - * - * This file is automatically generated from the OMAP hardware databases. - * We respectfully ask that any modifications to this file be coordinated - * with the public linux-omap@vger.kernel.org mailing list and the - * authors above to ensure that the autogeneration scripts are kept - * up-to-date with the file contents. - * - * This program is free software; you can redistribute it and/or modify - * it under the terms of the GNU General Public License version 2 as - * published by the Free Software Foundation. - */ - -#ifndef __ARCH_ARM_MACH_OMAP2_OMAP44XX_IRQS_H -#define __ARCH_ARM_MACH_OMAP2_OMAP44XX_IRQS_H - -/* OMAP44XX IRQs numbers definitions */ -#define OMAP44XX_IRQ_LOCALTIMER29 -#define OMAP44XX_IRQ_LOCALWDT 30 - -#define OMAP44XX_IRQ_GIC_START 32 - -#define OMAP44XX_IRQ_PL310 (0 + OMAP44XX_IRQ_GIC_START) -#define OMAP44XX_IRQ_CTI0 (1 + OMAP44XX_IRQ_GIC_START) -#define OMAP44XX_IRQ_CTI1 (2 + OMAP44XX_IRQ_GIC_START) -#define OMAP44XX_IRQ_ELM (4 + OMAP44XX_IRQ_GIC_START) -#define OMAP44XX_IRQ_SYS_1N(7 + OMAP44XX_IRQ_GIC_START) -#define OMAP44XX_IRQ_SECURITY_EVENTS (8 + OMAP44XX_IRQ_GIC_START) -#define OMAP44XX_IRQ_L3_DBG(9 + OMAP44XX_IRQ_GIC_START) -#define OMAP44XX_IRQ_L3_APP(10 + OMAP44XX_IRQ_GIC_START) -#define OMAP44XX_IRQ_PRCM (11 + OMAP44XX_IRQ_GIC_START) -#define OMAP44XX_IRQ_SDMA_0(12 + OMAP44XX_IRQ_GIC_START) -#define OMAP44XX_IRQ_SDMA_1(13 + OMAP44XX_IRQ_GIC_START) -#define OMAP44XX_IRQ_SDMA_2(14 + OMAP44XX_IRQ_GIC_START) -#define OMAP44XX_IRQ_SDMA_3(15 + OMAP44XX_IRQ_GIC_START) -#define OMAP44XX_IRQ_MCBSP4(16 + OMAP44XX_IRQ_GIC_START) -#define OMAP44XX_IRQ_MCBSP1(17 + OMAP44XX_IRQ_GIC_START) -#define OMAP44XX_IRQ_SR_MCU(18 + OMAP44XX_IRQ_GIC_START) -#define OMAP44XX_IRQ_SR_CORE (19 + OMAP44XX_IRQ_GIC_START) -#define OMAP44XX_IRQ_GPMC (20 + OMAP44XX_IRQ_GIC_START) -#define OMAP44XX_IRQ_GFX (21 + OMAP44XX_IRQ_GIC_START) -#define OMAP44XX_IRQ_MCBSP2(22 + OMAP44XX_IRQ_GIC_START) -#define OMAP44XX_IRQ_MCBSP3(23 + OMAP44XX_IRQ_GIC_START) -#define OMAP44XX_IRQ_ISS_5 (24 + OMAP44XX_IRQ_GIC_START) -#define OMAP44XX_IRQ_DSS_DISPC (25 + OMAP44XX_IRQ_GIC_START) -#define OMAP44XX_IRQ_MAIL_U0 (26 + OMAP44XX_IRQ_GIC_START) -#define OMAP44XX_IRQ_C2C_SSCM_0(27 + OMAP44XX_IRQ_GIC_START) -#define OMAP44XX_IRQ_TESLA_MMU (28 + OMAP44XX_IRQ_GIC_START) -#define OMAP44XX_IRQ_GPIO1 (29 + OMAP44XX_IRQ_GIC_START) -#define OMAP44XX_IRQ_GPIO2 (30 + OMAP44XX_IRQ_GIC_START) -#define OMAP44XX_IRQ_GPIO3 (31 + OMAP44XX_IRQ_GIC_START) -#define OMAP44XX_IRQ_GPIO4 (32 + OMAP44XX_IRQ_GIC_START) -#define OMAP44XX_IRQ_GPIO5 (33 + OMAP44XX_IRQ_GIC_START) -#define OMAP44XX_IRQ_GPIO6 (34 + OMAP44XX_IRQ_GIC_START) -#define OMAP44XX_IRQ_USIM (35 + OMAP44XX_IRQ_GIC_START) -#define OMAP44XX_IRQ_WDT3 (36 + OMAP44XX_IRQ_GIC_START) -#define OMAP44XX_IRQ_GPT1 (37 + OMAP44XX_IRQ_GIC_START) -#define OMAP44XX_IRQ_GPT2 (38 + OMAP44XX_IRQ_GIC_START) -#define OMAP44XX_IRQ_GPT3 (39 + OMAP44XX_IRQ_GIC_START) -#define OMAP44XX_IRQ_GPT4 (40 + OMAP44XX_IRQ_GIC_START) -#define OMAP44XX_IRQ_GPT5 (41 + OMAP44XX_IRQ_GIC_START) -#define OMAP44XX_IRQ_GPT6 (42 + OMAP44XX_IRQ_GIC_START) -#define OMAP44XX_IRQ_GPT7
[PATCH 4/5] ARM: OMAP2+: gpmc: Use irq_alloc_descs instead of static IRQ range
The gpmc code is still not a proper driver and is still using the bad old
static way of declaring its IRQ range for the various CS it can handle (8).
Use irq_alloc_descs to get dynamically a set of IRQ descriptors.
Clean some bad line wrapping here and there.
Please note that this code is still not a real driver after this fix, and
will require a massive cleanup...
Signed-off-by: Benoit Cousson b-cous...@ti.com
---
arch/arm/mach-omap2/gpmc.c | 22 +++---
1 files changed, 15 insertions(+), 7 deletions(-)
diff --git a/arch/arm/mach-omap2/gpmc.c b/arch/arm/mach-omap2/gpmc.c
index dfffbbf..95ea50a 100644
--- a/arch/arm/mach-omap2/gpmc.c
+++ b/arch/arm/mach-omap2/gpmc.c
@@ -103,6 +103,8 @@ static struct clk *gpmc_l3_clk;
static irqreturn_t gpmc_handle_irq(int irq, void *dev);
+static int irq_base;
+
static void gpmc_write_reg(int idx, u32 val)
{
__raw_writel(val, gpmc_base + idx);
@@ -747,7 +749,13 @@ static int __init gpmc_init(void)
gpmc_mem_init();
/* initalize the irq_chained */
- irq = OMAP_GPMC_IRQ_BASE;
+ irq_base = irq_alloc_descs(-1, 0, GPMC_CS_NUM, 0);
+ if (irq_base 0) {
+ pr_err(%s() Couldn't allocate IRQs\n, __func__);
+ return -ENODEV;
+ }
+
+ irq = irq_base;
for (cs = 0; cs GPMC_CS_NUM; cs++) {
irq_set_chip_and_handler(irq, dummy_irq_chip,
handle_simple_irq);
@@ -755,11 +763,11 @@ static int __init gpmc_init(void)
irq++;
}
- ret = request_irq(gpmc_irq,
- gpmc_handle_irq, IRQF_SHARED, gpmc, gpmc_base);
+ ret = request_irq(gpmc_irq, gpmc_handle_irq, IRQF_SHARED, gpmc,
+ gpmc_base);
if (ret)
- pr_err(gpmc: irq-%d could not claim: err %d\n,
- gpmc_irq, ret);
+ pr_err(gpmc: irq-%d could not claim: err %d\n, gpmc_irq, ret);
+
return ret;
}
postcore_initcall(gpmc_init);
@@ -770,8 +778,8 @@ static irqreturn_t gpmc_handle_irq(int irq, void *dev)
/* check cs to invoke the irq */
cs = ((gpmc_read_reg(GPMC_PREFETCH_CONFIG1)) CS_NUM_SHIFT) 0x7;
- if (OMAP_GPMC_IRQ_BASE+cs = OMAP_GPMC_IRQ_END)
- generic_handle_irq(OMAP_GPMC_IRQ_BASE+cs);
+ if (cs = GPMC_CS_NUM)
+ generic_handle_irq(irq_base + cs);
return IRQ_HANDLED;
}
--
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
[PATCH 3/5] ARM: OMAP2+: wakeupgen: Fix wrong array size for irq_target_cpu
The wakeupgen was wrongly allocating an array based on the NR_IRQS value (410 on OMAP4) whereas it is just capable of handling 128 entries. Moreover with SPARSE_IRQ, the NR_IRQS number might be 16, and thus cannot handle the proper number of entries. It will generate an oops as soon a driver will request an IRQ 16. Allocate the array using the fixed MAX_IRQS value (128). Signed-off-by: Benoit Cousson b-cous...@ti.com Cc: Santosh Shilimkar santosh.shilim...@ti.com --- arch/arm/mach-omap2/omap-wakeupgen.c |4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/arch/arm/mach-omap2/omap-wakeupgen.c b/arch/arm/mach-omap2/omap-wakeupgen.c index d3d8971..bec55e1 100644 --- a/arch/arm/mach-omap2/omap-wakeupgen.c +++ b/arch/arm/mach-omap2/omap-wakeupgen.c @@ -45,7 +45,7 @@ static void __iomem *wakeupgen_base; static void __iomem *sar_base; static DEFINE_PER_CPU(u32 [NR_REG_BANKS], irqmasks); static DEFINE_SPINLOCK(wakeupgen_lock); -static unsigned int irq_target_cpu[NR_IRQS]; +static unsigned int irq_target_cpu[MAX_IRQS]; /* * Static helper functions. @@ -379,7 +379,7 @@ int __init omap_wakeupgen_init(void) */ /* Associate all the IRQs to boot CPU like GIC init does. */ - for (i = 0; i NR_IRQS; i++) + for (i = 0; i MAX_IRQS; i++) irq_target_cpu[i] = boot_cpu; irq_hotplug_init(); -- 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
[PATCH 5/5] ARM: OMAP: irqs: Set NR_IRQS to NR_IRQS_LEGACY for CONFIG_SPARSE_IRQ
If CONFIG_SPARSE_IRQ is set, the irqdescs will be allocated with NR_IRQS entries at boot time and thus will shift all the entries allocated dynamically by irq_alloc_descs for nothing. Set NR_IRQS to NR_IRQS_LEGACY if CONFIG_SPARSE_IRQ is set. Signed-off-by: Benoit Cousson b-cous...@ti.com --- arch/arm/plat-omap/include/plat/irqs.h |4 1 files changed, 4 insertions(+), 0 deletions(-) diff --git a/arch/arm/plat-omap/include/plat/irqs.h b/arch/arm/plat-omap/include/plat/irqs.h index 3d41a65..acc1ac8 100644 --- a/arch/arm/plat-omap/include/plat/irqs.h +++ b/arch/arm/plat-omap/include/plat/irqs.h @@ -438,7 +438,11 @@ #define OMAP_GPMC_IRQ_END (OMAP_GPMC_IRQ_BASE + OMAP_GPMC_NR_IRQS) +#ifdef CONFIG_SPARSE_IRQ +#define NR_IRQSNR_IRQS_LEGACY +#else #define NR_IRQSOMAP_GPMC_IRQ_END +#endif #define OMAP_IRQ_BIT(irq) (1 ((irq) % 32)) -- 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
[RFC PATCH] gpio/omap: Fix IRQ handling for SPARSE_IRQ
The GPIO driver is still relying on internal OMAP IRQ defines that
are not relevant anymore if OMAP is built with SPARSE_IRQ.
Replace the defines with the proper IRQ base number.
Clean some comment style issue.
Remove some hidden and ugly cpu_class_is_omap1() inside the
gpio header.
XXX: That fix might be broken for OMAP1 MPUIO case.
Signed-off-by: Benoit Cousson b-cous...@ti.com
---
Hi Tony,
Please note that this patch is still RFC, because I do not know how to fix
properly the ugly cpu_class_is_omap1 and the dependency with IH_MPUIO_BASE to
detect a MPUIO.
I'm still sending it, because it is needed to have SPARSE_IRQ working on OMAP4
with the previous series I've just sent.
Regards,
Benoit
arch/arm/plat-omap/include/plat/gpio.h | 22 ++--
drivers/gpio/gpio-omap.c | 33 ---
2 files changed, 20 insertions(+), 35 deletions(-)
diff --git a/arch/arm/plat-omap/include/plat/gpio.h
b/arch/arm/plat-omap/include/plat/gpio.h
index cb75b65..b8a96c6 100644
--- a/arch/arm/plat-omap/include/plat/gpio.h
+++ b/arch/arm/plat-omap/include/plat/gpio.h
@@ -218,30 +218,14 @@ extern void omap_set_gpio_debounce(int gpio, int enable);
extern void omap_set_gpio_debounce_time(int gpio, int enable);
/*-*/
-/* Wrappers for new style GPIO calls, using the new infrastructure
+/*
+ * Wrappers for new style GPIO calls, using the new infrastructure
* which lets us plug in FPGA, I2C, and other implementations.
- * *
+ *
* The original OMAP-specific calls should eventually be removed.
*/
#include linux/errno.h
#include asm-generic/gpio.h
-static inline int irq_to_gpio(unsigned irq)
-{
- int tmp;
-
- /* omap1 SOC mpuio */
- if (cpu_class_is_omap1() (irq (IH_MPUIO_BASE + 16)))
- return (irq - IH_MPUIO_BASE) + OMAP_MAX_GPIO_LINES;
-
- /* SOC gpio */
- tmp = irq - IH_GPIO_BASE;
- if (tmp OMAP_MAX_GPIO_LINES)
- return tmp;
-
- /* we don't supply reverse mappings for non-SOC gpios */
- return -EIO;
-}
-
#endif
diff --git a/drivers/gpio/gpio-omap.c b/drivers/gpio/gpio-omap.c
index bc2bd69..afef0f7 100644
--- a/drivers/gpio/gpio-omap.c
+++ b/drivers/gpio/gpio-omap.c
@@ -93,6 +93,11 @@ struct gpio_bank {
#define GPIO_BIT(bank, gpio) (1 GPIO_INDEX(bank, gpio))
#define GPIO_MOD_CTRL_BIT BIT(0)
+static int irq_to_gpio(struct gpio_bank *bank, unsigned int gpio_irq)
+{
+ return gpio_irq - bank-irq_base + bank-chip.base;
+}
+
static void _set_gpio_direction(struct gpio_bank *bank, int gpio, int is_input)
{
void __iomem *reg = bank-base;
@@ -369,7 +374,7 @@ static int _set_gpio_triggering(struct gpio_bank *bank, int
gpio, int trigger)
static int gpio_irq_type(struct irq_data *d, unsigned type)
{
- struct gpio_bank *bank;
+ struct gpio_bank *bank = irq_data_get_irq_chip_data(d);
unsigned gpio;
int retval;
unsigned long flags;
@@ -377,13 +382,11 @@ static int gpio_irq_type(struct irq_data *d, unsigned
type)
if (!cpu_class_is_omap2() d-irq IH_MPUIO_BASE)
gpio = OMAP_MPUIO(d-irq - IH_MPUIO_BASE);
else
- gpio = d-irq - IH_GPIO_BASE;
+ gpio = irq_to_gpio(bank, d-irq);
if (type ~IRQ_TYPE_SENSE_MASK)
return -EINVAL;
- bank = irq_data_get_irq_chip_data(d);
-
if (!bank-regs-leveldetect0
(type (IRQ_TYPE_LEVEL_LOW|IRQ_TYPE_LEVEL_HIGH)))
return -EINVAL;
@@ -524,14 +527,10 @@ static void _reset_gpio(struct gpio_bank *bank, int gpio)
/* Use disable_irq_wake() and enable_irq_wake() functions from drivers */
static int gpio_wake_enable(struct irq_data *d, unsigned int enable)
{
- unsigned int gpio = d-irq - IH_GPIO_BASE;
- struct gpio_bank *bank;
- int retval;
-
- bank = irq_data_get_irq_chip_data(d);
- retval = _set_gpio_wakeup(bank, gpio, enable);
+ struct gpio_bank *bank = irq_data_get_irq_chip_data(d);
+ unsigned int gpio = irq_to_gpio(bank, d-irq);
- return retval;
+ return _set_gpio_wakeup(bank, gpio, enable);
}
static int omap_gpio_request(struct gpio_chip *chip, unsigned offset)
@@ -675,11 +674,13 @@ static void gpio_irq_handler(unsigned int irq, struct
irq_desc *desc)
gpio_irq = bank-irq_base;
for (; isr != 0; isr = 1, gpio_irq++) {
- gpio_index = GPIO_INDEX(bank, irq_to_gpio(gpio_irq));
+ int gpio = irq_to_gpio(bank, gpio_irq);
if (!(isr 1))
continue;
+ gpio_index = GPIO_INDEX(bank, gpio);
+
/*
* Some chips can't respond to both rising and falling
* at the same time. If this irq was requested with
@@ -705,8 +706,8 @@ exit:
Re: [RFC PATCH] gpio/omap: Fix IRQ handling for SPARSE_IRQ
* Cousson, Benoit b-cous...@ti.com [120223 14:14]: The GPIO driver is still relying on internal OMAP IRQ defines that are not relevant anymore if OMAP is built with SPARSE_IRQ. Great :) Please note that this patch is still RFC, because I do not know how to fix properly the ugly cpu_class_is_omap1 and the dependency with IH_MPUIO_BASE to detect a MPUIO. Sounds like gpio_to_irq() needs to be set in the arch/arm/*omap*/gpio*.c then. 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
[GIT PULL] omap fixes for v3.3-rc4
Hi Arnd Olof, Please pull omap fixes from: git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap fixes This contains a fix for omap4 to call memblck_steal() from .reserve like it should be, and fixes a regression for smsc911x using boards as they now require regulators. Also included are fixes for errors that show up if the TWL PMIC is compiled as a module. Note that the top two patches are from today: The smsc911x patch was updated for to remove an unnecessary variable, and the mailbox compile fix I applied earlier today. Regards, Tony The following changes since commit b01543dfe67bb1d191998e90d20534dc354de059: Linus Torvalds (1): Linux 3.3-rc4 are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap fixes Arnout Vandecappelle (Essensium/Mind) (1): OMAP3 EVM: remove out-of-bounds array access of gpio_leds Felipe Balbi (1): ARM: OMAP2+: usb-host: fix compile warning Matt Porter (1): ARM: OMAP2+: gpmc-smsc911x: add required smsc911x regulators NeilBrown (1): ARM: OMAP: add RCU locking to omap2_set_init_voltage. Ohad Ben-Cohen (1): ARM: OMAP2: fix mailbox init code Santosh Shilimkar (2): ARM: OMAP4: cpuidle: Fix the C-state reporting to cpuidle governor. ARM: OMAP4: Move the barrier memboclk_steal() as part of reserve callback Tony Lindgren (5): Merge branch 'for_3.3/fixes/pm' of git://git.kernel.org/.../khilman/linux-omap-pm into fixes ARM: OMAP: Fix kernel panic with HSMMC when twl4030_gpio is a module ARM: OMAP: Fix build error when mmc_omap is built as module Merge branch 'fixes-mmc' into fixes ARM: OMAP1: Fix out-of-bounds array access for Innovator arch/arm/mach-omap1/board-innovator.c |4 +- arch/arm/mach-omap2/Kconfig |4 +- arch/arm/mach-omap2/board-n8x0.c |4 ++ arch/arm/mach-omap2/board-omap3evm.c |2 +- arch/arm/mach-omap2/common.h |1 + arch/arm/mach-omap2/cpuidle44xx.c |5 +- arch/arm/mach-omap2/gpmc-smsc911x.c | 52 + arch/arm/mach-omap2/hsmmc.c |6 +++ arch/arm/mach-omap2/io.c |1 + arch/arm/mach-omap2/mailbox.c | 10 - arch/arm/mach-omap2/mux.c |2 +- arch/arm/mach-omap2/omap4-common.c| 25 arch/arm/mach-omap2/pm.c |3 + arch/arm/mach-omap2/usb-host.c|6 +- arch/arm/plat-omap/common.c |1 + arch/arm/plat-omap/include/plat/omap-secure.h |6 +++ 16 files changed, 110 insertions(+), 22 deletions(-) -- 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/8] ARM: OMAP1: Move 16xx GPIO system clock to platform init code
* Tony Lindgren t...@atomide.com [120221 15:09]:
This way we can remove omap_read/write call from the GPIO driver
and remove include to linux/io.h.
...
--- a/drivers/gpio/gpio-omap.c
+++ b/drivers/gpio/gpio-omap.c
@@ -18,7 +18,6 @@
#include linux/syscore_ops.h
#include linux/err.h
#include linux/clk.h
-#include linux/io.h
#include linux/slab.h
#include linux/pm_runtime.h
I'll drop this hunk, it causes a conflict with Kevin's
GPIO runtime PM series and it's not really related to
this patch or actually needed. Updated patch below.
Regards,
Tony
From: Tony Lindgren t...@atomide.com
Date: Wed, 22 Feb 2012 14:52:38 -0800
Subject: [PATCH] ARM: OMAP1: Move 16xx GPIO system clock to platform init code
This way we can remove omap_read/write call from the GPIO driver
and remove include to linux/io.h.
Cc: Grant Likely grant.lik...@secretlab.ca
Signed-off-by: Tony Lindgren t...@atomide.com
--- a/arch/arm/mach-omap1/gpio16xx.c
+++ b/arch/arm/mach-omap1/gpio16xx.c
@@ -218,6 +218,13 @@ static int __init omap16xx_gpio_init(void)
if (!cpu_is_omap16xx())
return -EINVAL;
+ /*
+* Enable system clock for GPIO module.
+* The CAM_CLK_CTRL *is* really the right place.
+*/
+ omap_writel(omap_readl(ULPD_CAM_CLK_CTRL) | 0x04,
+ ULPD_CAM_CLK_CTRL);
+
for (i = 0; i ARRAY_SIZE(omap16xx_gpio_dev); i++)
platform_device_register(omap16xx_gpio_dev[i]);
diff --git a/drivers/gpio/gpio-omap.c b/drivers/gpio/gpio-omap.c
index 0b05629..5b7b164 100644
--- a/drivers/gpio/gpio-omap.c
+++ b/drivers/gpio/gpio-omap.c
@@ -1064,13 +1064,6 @@ static void omap_gpio_mod_init(struct gpio_bank *bank,
int id)
+ OMAP1610_GPIO_IRQSTATUS1);
__raw_writew(0x0014, bank-base
+ OMAP1610_GPIO_SYSCONFIG);
-
- /*
-* Enable system clock for GPIO module.
-* The CAM_CLK_CTRL *is* really the right place.
-*/
- omap_writel(omap_readl(ULPD_CAM_CLK_CTRL) | 0x04,
- ULPD_CAM_CLK_CTRL);
}
if (cpu_is_omap7xx() bank-method == METHOD_GPIO_7XX) {
__raw_writel(0x, bank-base
--
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/8] ARM: OMAP1: Move most of plat/io.h into local iomap.h
* Tony Lindgren t...@atomide.com [120221 15:09]:
There's no need to have these in plat/io.h.
While at it, clean up the includes to group them
like they typically are grouped.
...
diff --git a/arch/arm/mach-omap1/iomap.h b/arch/arm/mach-omap1/iomap.h
new file mode 100644
index 000..c2cdf71
--- /dev/null
+++ b/arch/arm/mach-omap1/iomap.h
@@ -0,0 +1,18 @@
+#ifdef __ASSEMBLER__
+#define IOMEM(x) (x)
+#else
+#define IOMEM(x) ((void __force __iomem *)(x))
+#endif
+
+#define OMAP1_IO_OFFSET 0x0100 /* Virtual IO =
0xfefb */
+#define OMAP1_IO_ADDRESS(pa) IOMEM((pa) - OMAP1_IO_OFFSET)
+
+/*
+ *
+ * Omap1 specific IO mapping
+ *
+ */
+
+#define OMAP1_IO_PHYS0xFFFB
+#define OMAP1_IO_SIZE0x4
+#define OMAP1_IO_VIRT(OMAP1_IO_PHYS - OMAP1_IO_OFFSET)
Looks like the iomap.h is missing license, so updated patch below.
Regards,
Tony
From: Tony Lindgren t...@atomide.com
Date: Wed, 22 Feb 2012 14:52:39 -0800
Subject: [PATCH] ARM: OMAP1: Move most of plat/io.h into local iomap.h
There's no need to have these in plat/io.h.
While at it, clean up the includes to group them
like they typically are grouped.
Signed-off-by: Tony Lindgren t...@atomide.com
diff --git a/arch/arm/mach-omap1/ams-delta-fiq-handler.S
b/arch/arm/mach-omap1/ams-delta-fiq-handler.S
index c1c5fb6..399c4c4 100644
--- a/arch/arm/mach-omap1/ams-delta-fiq-handler.S
+++ b/arch/arm/mach-omap1/ams-delta-fiq-handler.S
@@ -15,11 +15,12 @@
#include linux/linkage.h
-#include plat/io.h
#include plat/board-ams-delta.h
#include mach/ams-delta-fiq.h
+#include iomap.h
+
/*
* GPIO related definitions, copied from arch/arm/plat-omap/gpio.c.
* Unfortunately, those were not placed in a separate header file.
diff --git a/arch/arm/mach-omap1/ams-delta-fiq.c
b/arch/arm/mach-omap1/ams-delta-fiq.c
index 152b32c..fcce7ff 100644
--- a/arch/arm/mach-omap1/ams-delta-fiq.c
+++ b/arch/arm/mach-omap1/ams-delta-fiq.c
@@ -22,6 +22,7 @@
#include plat/board-ams-delta.h
#include asm/fiq.h
+
#include mach/ams-delta-fiq.h
static struct fiq_handler fh = {
diff --git a/arch/arm/mach-omap1/board-ams-delta.c
b/arch/arm/mach-omap1/board-ams-delta.c
index 88909cc..ac65d7d 100644
--- a/arch/arm/mach-omap1/board-ams-delta.c
+++ b/arch/arm/mach-omap1/board-ams-delta.c
@@ -20,25 +20,27 @@
#include linux/platform_device.h
#include linux/serial_8250.h
#include linux/export.h
+#include linux/io.h
#include media/soc_camera.h
#include asm/serial.h
-#include mach/hardware.h
#include asm/mach-types.h
#include asm/mach/arch.h
#include asm/mach/map.h
-#include plat/io.h
#include plat/board-ams-delta.h
#include plat/keypad.h
#include plat/mux.h
#include plat/usb.h
#include plat/board.h
-#include common.h
-#include mach/camera.h
+#include mach/hardware.h
#include mach/ams-delta-fiq.h
+#include mach/camera.h
+
+#include iomap.h
+#include common.h
static u8 ams_delta_latch1_reg;
static u16 ams_delta_latch2_reg;
diff --git a/arch/arm/mach-omap1/board-fsample.c
b/arch/arm/mach-omap1/board-fsample.c
index 0b9464b..079292c 100644
--- a/arch/arm/mach-omap1/board-fsample.c
+++ b/arch/arm/mach-omap1/board-fsample.c
@@ -22,7 +22,6 @@
#include linux/input.h
#include linux/smc91x.h
-#include mach/hardware.h
#include asm/mach-types.h
#include asm/mach/arch.h
#include asm/mach/map.h
@@ -32,9 +31,13 @@
#include plat/flash.h
#include plat/fpga.h
#include plat/keypad.h
-#include common.h
#include plat/board.h
+#include mach/hardware.h
+
+#include iomap.h
+#include common.h
+
/* fsample is pretty close to p2-sample */
#define fsample_cpld_read(reg) __raw_readb(reg)
diff --git a/arch/arm/mach-omap1/board-h2.c b/arch/arm/mach-omap1/board-h2.c
index 00ad6b2..03e0050 100644
--- a/arch/arm/mach-omap1/board-h2.c
+++ b/arch/arm/mach-omap1/board-h2.c
@@ -31,8 +31,6 @@
#include linux/i2c/tps65010.h
#include linux/smc91x.h
-#include mach/hardware.h
-
#include asm/mach-types.h
#include asm/mach/arch.h
#include asm/mach/map.h
@@ -43,9 +41,11 @@
#include plat/irda.h
#include plat/usb.h
#include plat/keypad.h
-#include common.h
#include plat/flash.h
+#include mach/hardware.h
+
+#include common.h
#include board-h2.h
/* At OMAP1610 Innovator the Ethernet is directly connected to CS1 */
diff --git a/arch/arm/mach-omap1/board-h3.c b/arch/arm/mach-omap1/board-h3.c
index 4a7f251..f304fe2 100644
--- a/arch/arm/mach-omap1/board-h3.c
+++ b/arch/arm/mach-omap1/board-h3.c
@@ -33,21 +33,21 @@
#include asm/setup.h
#include asm/page.h
-#include mach/hardware.h
-
#include asm/mach-types.h
#include asm/mach/arch.h
#include asm/mach/map.h
-#include mach/irqs.h
#include plat/mux.h
#include plat/tc.h
#include plat/usb.h
#include plat/keypad.h
#include plat/dma.h
Re: [PATCH 6/8] ARM: OMAP2+: Move most of plat/io.h into local iomap.h
* Tony Lindgren t...@atomide.com [120221 15:09]: There's no need to have these defines in plat/io.h. Note that we now need to ifdef omap_read/write calls as they will be available for omap1 only. While at it, clean up the includes to group them like they typically are grouped. This one updated with the license too for iomap.h and added include iomap.h for emu.c that may cause errors with some .config files otherwise. Regards, Tony From: Tony Lindgren t...@atomide.com Date: Wed, 22 Feb 2012 14:52:40 -0800 Subject: [PATCH] ARM: OMAP2+: Move most of plat/io.h into local iomap.h There's no need to have these defines in plat/io.h. Note that we now need to ifdef omap_read/write calls as they will be available for omap1 only. While at it, clean up the includes to group them like they typically are grouped. Signed-off-by: Tony Lindgren t...@atomide.com diff --git a/arch/arm/mach-omap2/clock2420_data.c b/arch/arm/mach-omap2/clock2420_data.c index 61ad385..b1f3e7c 100644 --- a/arch/arm/mach-omap2/clock2420_data.c +++ b/arch/arm/mach-omap2/clock2420_data.c @@ -19,6 +19,7 @@ #include plat/clkdev_omap.h +#include iomap.h #include clock.h #include clock2xxx.h #include opp2xxx.h diff --git a/arch/arm/mach-omap2/clock2430.c b/arch/arm/mach-omap2/clock2430.c index d87bc9c..0caf792 100644 --- a/arch/arm/mach-omap2/clock2430.c +++ b/arch/arm/mach-omap2/clock2430.c @@ -23,6 +23,7 @@ #include plat/clock.h +#include iomap.h #include clock.h #include clock2xxx.h #include cm2xxx_3xxx.h diff --git a/arch/arm/mach-omap2/clock2430_data.c b/arch/arm/mach-omap2/clock2430_data.c index 0cc1287..9a061ff 100644 --- a/arch/arm/mach-omap2/clock2430_data.c +++ b/arch/arm/mach-omap2/clock2430_data.c @@ -19,6 +19,7 @@ #include plat/clkdev_omap.h +#include iomap.h #include clock.h #include clock2xxx.h #include opp2xxx.h diff --git a/arch/arm/mach-omap2/clock3xxx_data.c b/arch/arm/mach-omap2/clock3xxx_data.c index d75e5f6..981b9f9 100644 --- a/arch/arm/mach-omap2/clock3xxx_data.c +++ b/arch/arm/mach-omap2/clock3xxx_data.c @@ -20,14 +20,15 @@ #include linux/clk.h #include linux/list.h +#include plat/hardware.h #include plat/clkdev_omap.h +#include iomap.h #include clock.h #include clock3xxx.h #include clock34xx.h #include clock36xx.h #include clock3517.h - #include cm2xxx_3xxx.h #include cm-regbits-34xx.h #include prm2xxx_3xxx.h diff --git a/arch/arm/mach-omap2/clock44xx_data.c b/arch/arm/mach-omap2/clock44xx_data.c index 08e86d7..79b98f2 100644 --- a/arch/arm/mach-omap2/clock44xx_data.c +++ b/arch/arm/mach-omap2/clock44xx_data.c @@ -26,8 +26,11 @@ #include linux/kernel.h #include linux/list.h #include linux/clk.h + +#include plat/hardware.h #include plat/clkdev_omap.h +#include iomap.h #include clock.h #include clock44xx.h #include cm1_44xx.h diff --git a/arch/arm/mach-omap2/cm2xxx_3xxx.c b/arch/arm/mach-omap2/cm2xxx_3xxx.c index 04d39cd..c79ed63 100644 --- a/arch/arm/mach-omap2/cm2xxx_3xxx.c +++ b/arch/arm/mach-omap2/cm2xxx_3xxx.c @@ -18,8 +18,8 @@ #include linux/err.h #include linux/io.h +#include iomap.h #include common.h - #include cm.h #include cm2xxx_3xxx.h #include cm-regbits-24xx.h diff --git a/arch/arm/mach-omap2/cm44xx.c b/arch/arm/mach-omap2/cm44xx.c index 6a83630..535d66e 100644 --- a/arch/arm/mach-omap2/cm44xx.c +++ b/arch/arm/mach-omap2/cm44xx.c @@ -18,8 +18,8 @@ #include linux/err.h #include linux/io.h +#include iomap.h #include common.h - #include cm.h #include cm1_44xx.h #include cm2_44xx.h diff --git a/arch/arm/mach-omap2/cminst44xx.c b/arch/arm/mach-omap2/cminst44xx.c index 6204dea..bd8810c 100644 --- a/arch/arm/mach-omap2/cminst44xx.c +++ b/arch/arm/mach-omap2/cminst44xx.c @@ -20,8 +20,8 @@ #include linux/err.h #include linux/io.h +#include iomap.h #include common.h - #include cm.h #include cm1_44xx.h #include cm2_44xx.h diff --git a/arch/arm/mach-omap2/common.c b/arch/arm/mach-omap2/common.c index aaf4211..93419de 100644 --- a/arch/arm/mach-omap2/common.c +++ b/arch/arm/mach-omap2/common.c @@ -17,12 +17,12 @@ #include linux/clk.h #include linux/io.h -#include common.h #include plat/board.h #include plat/mux.h - #include plat/clock.h +#include iomap.h +#include common.h #include sdrc.h #include control.h diff --git a/arch/arm/mach-omap2/control.c b/arch/arm/mach-omap2/control.c index 114c037..2fd5fd1 100644 --- a/arch/arm/mach-omap2/control.c +++ b/arch/arm/mach-omap2/control.c @@ -15,9 +15,10 @@ #include linux/kernel.h #include linux/io.h -#include common.h #include plat/sdrc.h +#include iomap.h +#include common.h #include cm-regbits-34xx.h #include prm-regbits-34xx.h #include prm2xxx_3xxx.h diff --git a/arch/arm/mach-omap2/control.h b/arch/arm/mach-omap2/control.h index 0ba68d3..03149de 100644 --- a/arch/arm/mach-omap2/control.h +++ b/arch/arm/mach-omap2/control.h @@ -16,7 +16,6 @@ #ifndef __ARCH_ARM_MACH_OMAP2_CONTROL_H #define __ARCH_ARM_MACH_OMAP2_CONTROL_H -#include mach/io.h #include
Re: [PATCH 7/8] ARM: OMAP: Remove plat/io.h by moving it into mach/io.h
* Rob Herring robherri...@gmail.com [120221 17:53]: On 02/21/2012 05:40 PM, Tony Lindgren wrote: This is needed so we can eventually remove mach/io.h for omap2+. ... -#include plat/io.h +#ifndef __ASM_ARM_ARCH_IO_H +#define __ASM_ARM_ARCH_IO_H + +#include mach/hardware.h This shouldn't be needed. Good catch, will update things for that. + +#define IO_SPACE_LIMIT 0x + +/* + * We don't actually have real ISA nor PCI buses, but there is so many + * drivers out there that might just work if we fake them... + */ +#define __io(a)__typesafe_io(a) +#define __mem_pci(a) (a) + +/* + * + * I/O mapping + * + */ + +#ifdef __ASSEMBLER__ +#define IOMEM(x) (x) +#else +#define IOMEM(x) ((void __force __iomem *)(x)) +#endif + This can't be moved to iomap.h? I did that for other platforms. Well I was thinking we should define these somewhere for everybody, so I was trying to avoid adding yet another copy.. But I can move it and then we can clean it up later to avoid more dependencies here. +/* + * + * Omap specific register access + * + */ + +#ifndef __ASSEMBLER__ + +/* + * NOTE: Please use ioremap + __raw_read/write where possible instead of these + */ + +extern u8 omap_readb(u32 pa); +extern u16 omap_readw(u32 pa); +extern u32 omap_readl(u32 pa); +extern void omap_writeb(u8 v, u32 pa); +extern void omap_writew(u16 v, u32 pa); +extern void omap_writel(u32 v, u32 pa); These can't be moved to common.h like omap2? Not for omap1 currently because a bunch of legacy drivers are using them :( Anyways, that should be OK for now as omap1 requires v5 flags and it currently does not make sense to try to compile into a common zImage. At least the USB driver already needs to be cleaned up for that, so eventually omap1 io.h can disappear too. Same comments on omap2 io.h. Thanks, will post an updated patch. 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: [GIT PULL] OMAP PM EMU fix for v3.3
Hi On Thu, 23 Feb 2012, madhusudhan.go...@elektrobit.com wrote: [Gowda] I found this BUG in the CM code while trying to use both SDTI as well as requirement of enabling Hardware supervised transition CLKTRCTRL_EMU to 0x3. SDTI requires the softwre supervised transition to keep connected, by enabling Hardware supervised transition SDTI does not like it so Jouni had commented out the HW supervised transtion. Which I agree it is fine on SDTI part. .flags = /* CLKDM_CAN_ENABLE_AUTO | */CLKDM_CAN_SWSUP, But my point here is when I set the HW supervised transition, across MPU OFF the register loses its previous value and changes to reset value 0x2 (SW supervised) is not correct. So I submitted this patch for fixing this general CM code bug. Okay, that's a little more clear. So this patch does not affect the SDTI functionality with your driver? Your patch description reads: Embedded trace debug tools like Serial Trace Interface(sti) using EMU domain loses connection across MPU OFF. The patch fixes this issue But it sounds like that's not the case? At least, if the reset value for CM_CLKSTCTRL_EMU is 0x2, I don't understand how this patch could fix it. About the patch - I'm fine with the basic underlying idea, but so far it looks like this is material for 3.4 rather than 3.3-rc, since it's not a regression? Please let me know if my comments answers your question. Well I was hoping that you might answer my earlier questions about whether the driver you're using calls into the OMAP infrastructure via pm_runtime*(), and whether its clocks and hwmod data are defined. - Paul -- 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/7] More omap2+ randconfig fixes
Hi all, Here are some more omap2+ randconfig related fixes for review. Regards, Tony --- Tony Lindgren (7): ARM: OMAP2+: Fix Kconfig dependencies for USB_ARCH_HAS_EHCI ARM: OMAP2+: Fix OMAP_HDQ_BASE build error ARM: OMAP2+: Fix board_mux section type conflict when OMAP_MUX is not set ARM: OMAP2+: Fix zoom LCD backlight if TWL_CORE is not selected ARM: OMAP2+: Fix devexit for smartreflex when CONFIG_HOTPLUG is not set ARM: OMAP: Fix devexit for dma when CONFIG_HOTPLUG is not set ARM: OMAP2+: Fix multiple randconfig errors with SOC_OMAP and SOC_OMAP_NOOP arch/arm/Makefile|4 +- arch/arm/mach-omap2/Kconfig | 55 -- arch/arm/mach-omap2/board-zoom-display.c |6 +++ arch/arm/mach-omap2/devices.c|7 ++-- arch/arm/mach-omap2/mux.h|2 + arch/arm/mach-omap2/smartreflex.c|2 + arch/arm/plat-omap/dma.c |2 + 7 files changed, 50 insertions(+), 28 deletions(-) -- Signature -- 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/7] ARM: OMAP2+: Fix Kconfig dependencies for USB_ARCH_HAS_EHCI
Otherwise we get: warning: (ARCH_OMAP3 ARCH_OMAP4) selects USB_ARCH_HAS_EHCI which has unmet direct dependencies (USB_SUPPORT) Signed-off-by: Tony Lindgren t...@atomide.com --- arch/arm/mach-omap2/Kconfig |4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig index d965da4..337f98d 100644 --- a/arch/arm/mach-omap2/Kconfig +++ b/arch/arm/mach-omap2/Kconfig @@ -32,7 +32,7 @@ config ARCH_OMAP3 depends on ARCH_OMAP2PLUS default y select CPU_V7 - select USB_ARCH_HAS_EHCI + select USB_ARCH_HAS_EHCI if USB_SUPPORT select ARCH_HAS_OPP select PM_OPP if PM select ARM_CPU_SUSPEND if PM @@ -52,7 +52,7 @@ config ARCH_OMAP4 select ARM_ERRATA_720789 select ARCH_HAS_OPP select PM_OPP if PM - select USB_ARCH_HAS_EHCI + select USB_ARCH_HAS_EHCI if USB_SUPPORT select ARM_CPU_SUSPEND if PM comment OMAP Core Type -- 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/7] ARM: OMAP2+: Fix OMAP_HDQ_BASE build error
If CONFIG_SOC_OMAP3430 is not set and CONFIG_HDQ_MASTER_OMAP
is selected for w1 driver we get the following error:
arch/arm/mach-omap2/devices.c:662:13: error:
'OMAP_HDQ_BASE' undeclared here (not in a function)
Looks like OMAP_HDQ_BASE is valid for all omaps except
2420, so we can remove the ifdef and not register
the device on 2420.
Signed-off-by: Tony Lindgren t...@atomide.com
---
arch/arm/mach-omap2/devices.c |7 ---
1 files changed, 4 insertions(+), 3 deletions(-)
diff --git a/arch/arm/mach-omap2/devices.c b/arch/arm/mach-omap2/devices.c
index 283d11e..3ffefe2 100644
--- a/arch/arm/mach-omap2/devices.c
+++ b/arch/arm/mach-omap2/devices.c
@@ -654,9 +654,7 @@ void __init omap242x_init_mmc(struct omap_mmc_platform_data
**mmc_data)
/*-*/
#if defined(CONFIG_HDQ_MASTER_OMAP) || defined(CONFIG_HDQ_MASTER_OMAP_MODULE)
-#if defined(CONFIG_SOC_OMAP2430) || defined(CONFIG_SOC_OMAP3430)
#define OMAP_HDQ_BASE 0x480B2000
-#endif
static struct resource omap_hdq_resources[] = {
{
.start = OMAP_HDQ_BASE,
@@ -679,7 +677,10 @@ static struct platform_device omap_hdq_dev = {
};
static inline void omap_hdq_init(void)
{
- (void) platform_device_register(omap_hdq_dev);
+ if (cpu_is_omap2420())
+ return;
+
+ platform_device_register(omap_hdq_dev);
}
#else
static inline void omap_hdq_init(void) {}
--
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/7] ARM: OMAP2+: Fix board_mux section type conflict when OMAP_MUX is not set
Otherwise we can get:
arch/arm/mach-omap2/mux.h:249:31: error: board_mux causes a section type
conflict
Signed-off-by: Tony Lindgren t...@atomide.com
---
arch/arm/mach-omap2/mux.h |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-omap2/mux.h b/arch/arm/mach-omap2/mux.h
index 2132308..69fe060 100644
--- a/arch/arm/mach-omap2/mux.h
+++ b/arch/arm/mach-omap2/mux.h
@@ -246,7 +246,7 @@ static inline void omap_hwmod_mux(struct
omap_hwmod_mux_info *hmux, u8 state)
{
}
-static struct omap_board_mux *board_mux __initdata __maybe_unused;
+static struct omap_board_mux *board_mux __maybe_unused;
#endif
--
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 4/7] ARM: OMAP2+: Fix zoom LCD backlight if TWL_CORE is not selected
Otherwise we get:
arch/arm/mach-omap2/board-zoom-display.c:64: undefined reference to
`twl_i2c_read_u8'
arch/arm/mach-omap2/board-zoom-display.c:65: undefined reference to
`twl_i2c_read_u8'
arch/arm/mach-omap2/board-zoom-display.c:84: undefined reference to
`twl_i2c_write_u8'
arch/arm/mach-omap2/board-zoom-display.c:86: undefined reference to
`twl_i2c_write_u8'
arch/arm/mach-omap2/board-zoom-display.c:91: undefined reference to
`twl_i2c_write_u8'
arch/arm/mach-omap2/board-zoom-display.c:92: undefined reference to
`twl_i2c_write_u8'
arch/arm/mach-omap2/board-zoom-display.c:72: undefined reference to
`twl_i2c_write_u8'
Signed-off-by: Tony Lindgren t...@atomide.com
---
arch/arm/mach-omap2/board-zoom-display.c |6 ++
1 files changed, 6 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/board-zoom-display.c
b/arch/arm/mach-omap2/board-zoom-display.c
index d4683ba..7f75fcd 100644
--- a/arch/arm/mach-omap2/board-zoom-display.c
+++ b/arch/arm/mach-omap2/board-zoom-display.c
@@ -53,8 +53,11 @@ static void zoom_panel_disable_lcd(struct omap_dss_device
*dssdev)
#define TWL_LED_PWMON 0x0
#define TWL_LED_PWMOFF 0x1
+
static int zoom_set_bl_intensity(struct omap_dss_device *dssdev, int level)
{
+
+#ifdef CONFIG_TWL4030_CORE
unsigned char c;
u8 mux_pwm, enb_pwm;
@@ -90,6 +93,9 @@ static int zoom_set_bl_intensity(struct omap_dss_device
*dssdev, int level)
c = ((50 * (100 - level)) / 100) + 1;
twl_i2c_write_u8(TWL4030_MODULE_PWM1, 0x7F, TWL_LED_PWMOFF);
twl_i2c_write_u8(TWL4030_MODULE_PWM1, c, TWL_LED_PWMON);
+#else
+ pr_warn(Backlight not enabled\n);
+#endif
return 0;
}
--
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/7] ARM: OMAP2+: Fix devexit for smartreflex when CONFIG_HOTPLUG is not set
Otherwise we get:
`omap_sr_remove' referenced in section `.data' of
arch/arm/mach-omap2/built-in.o:
defined in discarded section `.devexit.text' of arch/arm/mach-omap2/built-in.o
Signed-off-by: Tony Lindgren t...@atomide.com
---
arch/arm/mach-omap2/smartreflex.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-omap2/smartreflex.c
b/arch/arm/mach-omap2/smartreflex.c
index 7e755bb..47c77a1 100644
--- a/arch/arm/mach-omap2/smartreflex.c
+++ b/arch/arm/mach-omap2/smartreflex.c
@@ -1012,7 +1012,7 @@ static int __devexit omap_sr_remove(struct
platform_device *pdev)
}
static struct platform_driver smartreflex_driver = {
- .remove = omap_sr_remove,
+ .remove = __devexit_p(omap_sr_remove),
.driver = {
.name = smartreflex,
},
--
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/7] ARM: OMAP: Fix devexit for dma when CONFIG_HOTPLUG is not set
Otherwise we get:
`omap_system_dma_remove' referenced in section `.data' of
arch/arm/plat-omap/built-in.o:
defined in discarded section `.devexit.text' of arch/arm/plat-omap/built-in.o
Signed-off-by: Tony Lindgren t...@atomide.com
---
arch/arm/plat-omap/dma.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/arch/arm/plat-omap/dma.c b/arch/arm/plat-omap/dma.c
index 002fb4d..cb856fe 100644
--- a/arch/arm/plat-omap/dma.c
+++ b/arch/arm/plat-omap/dma.c
@@ -2125,7 +2125,7 @@ static int __devexit omap_system_dma_remove(struct
platform_device *pdev)
static struct platform_driver omap_system_dma_driver = {
.probe = omap_system_dma_probe,
- .remove = omap_system_dma_remove,
+ .remove = __devexit_p(omap_system_dma_remove),
.driver = {
.name = omap_dma_system
},
--
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 7/7] ARM: OMAP2+: Fix multiple randconfig errors with SOC_OMAP and SOC_OMAP_NOOP
If we don't have ARCH_OMAP2, 3 or 4 selected randconfig will always fail with multiple errors as the CPU and MACHINE are not set. Fix this by changing arch/arm/Makefile to build mach-omap2 based on ARCH_OMAP2PLUS. And let's introduce SOC_OMAP and SOC_OMAP_NOOP that allow randconfig to generate buildable .config files. Note that we can also remove few uncecssary ARCH_OMAP2PLUS lines as they are all within if ARCH_OMAP2PLUS block. Cc: Russell King rmk+ker...@arm.linux.org.uk Signed-off-by: Tony Lindgren t...@atomide.com --- arch/arm/Makefile |4 +-- arch/arm/mach-omap2/Kconfig | 51 +-- 2 files changed, 35 insertions(+), 20 deletions(-) diff --git a/arch/arm/Makefile b/arch/arm/Makefile index 1683bfb..ea69448 100644 --- a/arch/arm/Makefile +++ b/arch/arm/Makefile @@ -164,9 +164,7 @@ machine-$(CONFIG_ARCH_MXS) := mxs machine-$(CONFIG_ARCH_NETX):= netx machine-$(CONFIG_ARCH_NOMADIK) := nomadik machine-$(CONFIG_ARCH_OMAP1) := omap1 -machine-$(CONFIG_ARCH_OMAP2) := omap2 -machine-$(CONFIG_ARCH_OMAP3) := omap2 -machine-$(CONFIG_ARCH_OMAP4) := omap2 +machine-$(CONFIG_ARCH_OMAP2PLUS) := omap2 machine-$(CONFIG_ARCH_ORION5X) := orion5x machine-$(CONFIG_ARCH_PICOXCELL) := picoxcell machine-$(CONFIG_ARCH_PNX4008) := pnx4008 diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig index 337f98d..c4ae0a7 100644 --- a/arch/arm/mach-omap2/Kconfig +++ b/arch/arm/mach-omap2/Kconfig @@ -21,16 +21,12 @@ config ARCH_OMAP2PLUS_TYPICAL Compile a kernel suitable for booting most boards config ARCH_OMAP2 - bool TI OMAP2 - depends on ARCH_OMAP2PLUS - default y + bool select CPU_V6 select MULTI_IRQ_HANDLER config ARCH_OMAP3 - bool TI OMAP3 - depends on ARCH_OMAP2PLUS - default y + bool select CPU_V7 select USB_ARCH_HAS_EHCI if USB_SUPPORT select ARCH_HAS_OPP @@ -39,9 +35,7 @@ config ARCH_OMAP3 select MULTI_IRQ_HANDLER config ARCH_OMAP4 - bool TI OMAP4 - default y - depends on ARCH_OMAP2PLUS + bool select CACHE_L2X0 select CPU_V7 select ARM_GIC @@ -56,36 +50,58 @@ config ARCH_OMAP4 select ARM_CPU_SUSPEND if PM comment OMAP Core Type - depends on ARCH_OMAP2 + +config SOC_OMAP + bool config SOC_OMAP2420 bool OMAP2420 support - depends on ARCH_OMAP2 default y + select SOC_OMAP + select ARCH_OMAP2 select OMAP_DM_TIMER select ARCH_OMAP_OTG config SOC_OMAP2430 bool OMAP2430 support - depends on ARCH_OMAP2 default y + select SOC_OMAP + select ARCH_OMAP2 select ARCH_OMAP_OTG config SOC_OMAP3430 bool OMAP3430 support - depends on ARCH_OMAP3 default y + select SOC_OMAP + select ARCH_OMAP3 select ARCH_OMAP_OTG config SOC_OMAPTI81XX bool TI81XX support - depends on ARCH_OMAP3 default y + select SOC_OMAP + select ARCH_OMAP3 config SOC_OMAPAM33XX bool AM33XX support - depends on ARCH_OMAP3 default y + select SOC_OMAP + select ARCH_OMAP3 + +config SOC_OMAP44XX + bool OMAP44XX support + default y + select SOC_OMAP + select ARCH_OMAP4 + +config SOC_OMAP_NOOP + bool + depends on !SOC_OMAP + default y + select ARCH_OMAP2 + select ARCH_OMAP3 + select ARCH_OMAP4 + select MACH_OMAP_GENERIC config OMAP_PACKAGE_ZAF bool @@ -112,17 +128,17 @@ config OMAP_PACKAGE_CBS bool comment OMAP Board Type - depends on ARCH_OMAP2PLUS config MACH_OMAP_GENERIC bool Generic OMAP2+ board - depends on ARCH_OMAP2PLUS select USE_OF default y help Support for generic TI OMAP2+ boards using Flattened Device Tree. More information at Documentation/devicetree +if SOC_OMAP + config MACH_OMAP2_TUSB6010 bool depends on ARCH_OMAP2 SOC_OMAP2420 @@ -343,6 +359,7 @@ config MACH_OMAP4_PANDA select OMAP_PACKAGE_CBS select REGULATOR_FIXED_VOLTAGE if REGULATOR +endif config OMAP3_EMU bool OMAP3 debugging peripherals depends on ARCH_OMAP3 -- 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 v2 5/7] ARM: OMAP2+: Split omap2_hsmmc_init() to properly support I2C GPIO pins
On Thursday 23 February 2012 07:58 PM, Igor Grinberg wrote:
Hi Tony, Rajendra,
On 02/23/12 13:40, Rajendra Nayak wrote:
From: Tony Lindgrent...@atomide.com
Otherwise omap_device_build() and omap_mux related functions
can't be marked as __init when twl is build as a module.
If a board is using GPIO pins or regulators configured by an
external chip, such as TWL PMIC on I2C bus, the board must
mark those MMC controllers as deferred. Additionally both
omap_hsmmc_init() and omap_hsmmc_deferred_add() must be called
by the board.
For MMC controllers using internal GPIO pins for card
detect and regulators the slots don't need to be marked
deferred. In this case calling omap_hsmmc_init() is sufficient.
Note that this patch does not change the behaviour for
board-4430sdp.c board-omap4panda.c. These boards wrongly
rely on the omap_hsmmc.c init function callback to configure
the PMIC GPIO interrupt lines on external chip. If the PMIC
interrupt lines are not configured during init, they will
fail.
Reported-by: Russell Kingrmk+ker...@arm.linux.org.uk
Signed-off-by: Tony Lindgrent...@atomide.com
Signed-off-by: Rajendra Nayakrna...@ti.com
---
arch/arm/mach-omap2/board-2430sdp.c |2 +-
arch/arm/mach-omap2/board-3430sdp.c | 12 ++--
arch/arm/mach-omap2/board-4430sdp.c |4 +-
arch/arm/mach-omap2/board-am3517evm.c|2 +-
arch/arm/mach-omap2/board-cm-t35.c | 10 +-
arch/arm/mach-omap2/board-devkit8000.c |7 +-
arch/arm/mach-omap2/board-igep0020.c | 11 ++-
arch/arm/mach-omap2/board-ldp.c |2 +-
arch/arm/mach-omap2/board-omap3beagle.c |7 +-
arch/arm/mach-omap2/board-omap3evm.c |9 +-
arch/arm/mach-omap2/board-omap3logic.c |2 +-
arch/arm/mach-omap2/board-omap3pandora.c | 13 ++--
arch/arm/mach-omap2/board-omap3stalker.c | 14 ++--
arch/arm/mach-omap2/board-omap3touchbook.c |7 +-
arch/arm/mach-omap2/board-omap4panda.c |4 +-
arch/arm/mach-omap2/board-overo.c|5 +-
arch/arm/mach-omap2/board-rm680.c|2 +-
arch/arm/mach-omap2/board-rx51-peripherals.c |2 +-
arch/arm/mach-omap2/board-zoom-peripherals.c |9 ++-
arch/arm/mach-omap2/hsmmc.c | 117
+++---
arch/arm/mach-omap2/hsmmc.h | 13 ++-
21 files changed, 165 insertions(+), 89 deletions(-)
[...]
diff --git a/arch/arm/mach-omap2/board-cm-t35.c
b/arch/arm/mach-omap2/board-cm-t35.c
index d73316e..14df109 100644
--- a/arch/arm/mach-omap2/board-cm-t35.c
+++ b/arch/arm/mach-omap2/board-cm-t35.c
@@ -411,9 +411,9 @@ static struct omap2_hsmmc_info mmc[] = {
{
.mmc= 1,
.caps = MMC_CAP_4_BIT_DATA,
- .gpio_cd= -EINVAL,
+ .gpio_cd= OMAP_MAX_GPIO_LINES + 0,
.gpio_wp= -EINVAL,
-
+ .deferred = true,
},
{
.mmc= 2,
@@ -422,6 +422,7 @@ static struct omap2_hsmmc_info mmc[] = {
.gpio_cd= -EINVAL,
.gpio_wp= -EINVAL,
.ocr_mask = 0x0010, /* 3.3V */
+ .deferred = true,
Why do you defer this one?
It does not use external GPIO chip, in fact it does not use CD/WP at all.
I thought so too, but kept it that way since Tony's original patch
deferred it.
Tony, any reason you deferred the mmc devices which *do not* have card
detect via twl4030 gpio too?
},
{} /* Terminator */
};
@@ -469,9 +470,7 @@ static int cm_t35_twl_gpio_setup(struct device *dev,
unsigned gpio,
pr_err(CM-T35: could not obtain gpio for WiFi reset\n);
}
- /* gpio + 0 is mmc0_cd (input/IRQ) */
- mmc[0].gpio_cd = gpio + 0;
- omap2_hsmmc_init(mmc);
+ omap_hsmmc_deferred_add(mmc);
return 0;
}
@@ -639,6 +638,7 @@ static void __init cm_t3x_common_init(void)
omap_serial_init();
omap_sdrc_init(mt46h32m32lf6_sdrc_params,
mt46h32m32lf6_sdrc_params);
+ omap_hsmmc_init(mmc);
cm_t35_init_i2c();
omap_ads7846_init(1, CM_T35_GPIO_PENDOWN, 0, NULL);
cm_t35_init_ethernet();
Other then the comment above, looks fine.
I will probably be able to test this on Sunday.
Great, thanks.
--
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 v2 6/7] ARM: OMAP3: Use .teardown of twl4030-gpio to clean board requests
Igor,
On Thursday 23 February 2012 08:25 PM, Igor Grinberg wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi Rajendra,
On 02/23/12 13:40, Rajendra Nayak wrote:
All OMAP3 boards which register a .setup function with twl4030
gpio driver do not seem to have a .teardown hook implemented.
.setup mainly requests a few gpios and also in most cases
does a omap_hsmmc_deferred_add(). Have a .teardown do a gpio_free()
and of the requested gpios and also do a omap_hsmmc_deferred_del().
This helps in case the twl4030 gpio driver is built as a module and
added and removed multiple times. Without the .teardown a multiple
insmod/rmmod can result in gpio request failues and also WARN messages
stating addition of already registered mmc devices.
Thanks for the review. I'll take care of all your comments in the next
spin.
regards,
Rajendra
Reported-by: Russell Kingrmk+ker...@arm.linux.org.uk
Signed-off-by: Rajendra Nayakrna...@ti.com
---
arch/arm/mach-omap2/board-3430sdp.c | 10 ++
arch/arm/mach-omap2/board-cm-t35.c |8
arch/arm/mach-omap2/board-devkit8000.c | 10 ++
arch/arm/mach-omap2/board-igep0020.c | 14 ++
arch/arm/mach-omap2/board-ldp.c |9 +
arch/arm/mach-omap2/board-omap3beagle.c | 12
arch/arm/mach-omap2/board-omap3evm.c | 10 ++
arch/arm/mach-omap2/board-omap3pandora.c |9 +
arch/arm/mach-omap2/board-omap3stalker.c | 11 +++
arch/arm/mach-omap2/board-omap3touchbook.c | 10 ++
arch/arm/mach-omap2/board-overo.c|8
arch/arm/mach-omap2/board-rx51-peripherals.c |8
arch/arm/mach-omap2/board-zoom-peripherals.c |9 +
arch/arm/mach-omap2/hsmmc.c | 11 +++
arch/arm/mach-omap2/hsmmc.h |4
15 files changed, 143 insertions(+), 0 deletions(-)
[...]
diff --git a/arch/arm/mach-omap2/board-cm-t35.c
b/arch/arm/mach-omap2/board-cm-t35.c
index 14df109..55e0180 100644
--- a/arch/arm/mach-omap2/board-cm-t35.c
+++ b/arch/arm/mach-omap2/board-cm-t35.c
@@ -475,11 +475,19 @@ static int cm_t35_twl_gpio_setup(struct device *dev,
unsigned gpio,
return 0;
}
+static int cm_t35_twl_gpio_teardown(struct device *dev, unsigned gpio,
+unsigned ngpio)
+{
+ omap_hsmmc_deferred_del(mmc);
+ gpio_free(gpio + 2);
+ return 0;
+}
Can we have an empty line here?
static struct twl4030_gpio_platform_data cm_t35_gpio_data = {
.gpio_base = OMAP_MAX_GPIO_LINES,
.irq_base = TWL4030_GPIO_IRQ_BASE,
.irq_end= TWL4030_GPIO_IRQ_END,
.setup = cm_t35_twl_gpio_setup,
+ .teardown = cm_t35_twl_gpio_teardown,
};
static struct twl4030_platform_data cm_t35_twldata = {
[...]
diff --git a/arch/arm/mach-omap2/board-igep0020.c
b/arch/arm/mach-omap2/board-igep0020.c
index 11a6aa4..1d0850f 100644
--- a/arch/arm/mach-omap2/board-igep0020.c
+++ b/arch/arm/mach-omap2/board-igep0020.c
@@ -435,12 +435,26 @@ static int igep_twl_gpio_setup(struct device *dev,
return 0;
};
+static int igep_twl_gpio_teardown(struct device *dev,
+ unsigned gpio, unsigned ngpio)
+{
+ omap_hsmmc_deferred_del(mmc);
+ gpio_free(gpio + TWL4030_GPIO_MAX + 1);
+ if (machine_is_igep0030())
+ return 0;
+
+ gpio_free(gpio + 1);
+ gpio_free(gpio + TWL4030_GPIO_MAX);
gpio_free_array()?
+ return 0;
+}
+
static struct twl4030_gpio_platform_data igep_twl4030_gpio_pdata = {
.gpio_base = OMAP_MAX_GPIO_LINES,
.irq_base = TWL4030_GPIO_IRQ_BASE,
.irq_end= TWL4030_GPIO_IRQ_END,
.use_leds = true,
.setup = igep_twl_gpio_setup,
+ .teardown = igep_twl_gpio_teardown,
};
static int igep2_enable_dvi(struct omap_dss_device *dssdev)
[...]
diff --git a/arch/arm/mach-omap2/board-overo.c
b/arch/arm/mach-omap2/board-overo.c
index 8b6065b..e1f496d 100644
--- a/arch/arm/mach-omap2/board-overo.c
+++ b/arch/arm/mach-omap2/board-overo.c
@@ -419,12 +419,20 @@ static int overo_twl_gpio_setup(struct device *dev,
return 0;
}
+static int overo_twl_gpio_teardown(struct device *dev,
+ unsigned gpio, unsigned ngpio)
+{
+ omap_hsmmc_deferred_del(mmc);
If Overo will not have omap_hsmmc_deferred_add() (as for my comment to
the previous patch), then no need for the omap_hsmmc_deferred_del().
+ return 0;
+}
+
static struct twl4030_gpio_platform_data overo_gpio_data = {
.gpio_base = OMAP_MAX_GPIO_LINES,
.irq_base = TWL4030_GPIO_IRQ_BASE,
.irq_end= TWL4030_GPIO_IRQ_END,
.use_leds = true,
.setup = overo_twl_gpio_setup,
+ .teardown = overo_twl_gpio_teardown,
};
static struct
Re: [PATCH v3 1/2] regulator: twl: adapt twl-regulator driver to dt
On Thursday 23 February 2012 09:01 PM, Mark Brown wrote: On Thu, Feb 23, 2012 at 05:05:53PM +0530, Rajendra Nayak wrote: Modify the twl regulator driver to extract the regulator_init_data from device tree when passed, instead of getting it through platform_data structures (on non-DT builds) This doesn't apply to current -next, I expect because of the SMPS regulator changes which went in. Please always submit patches against -next. There's also a patch from Tero adding support for some additional regulators which is floating around and would conflict with this. Could you guys please coordinate with each other on this? Sure, I will co-ordinate with Tero and post my patches against -next. -- 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 v2 4/4] arm/dts: OMAP3: Add mmc controller nodes and board data
On Friday 24 February 2012 12:27 AM, Tony Lindgren wrote:
--- a/arch/arm/boot/dts/omap3.dtsi
+++ b/arch/arm/boot/dts/omap3.dtsi
@@ -113,5 +113,31 @@
#size-cells =0;
ti,hwmods = i2c3;
};
+
+ mmc1: mmc@1 {
+ compatible = ti,omap2-hsmmc;
+ ti,hwmods = mmc1;
+ ti,dual-volt;
+ };
+
+ mmc2: mmc@2 {
+ compatible = ti,omap2-hsmmc;
+ ti,hwmods = mmc2;
+ };
+
+ mmc3: mmc@3 {
+ compatible = ti,omap2-hsmmc;
+ ti,hwmods = mmc3;
+ };
+
+ mmc4: mmc@4 {
+ compatible = ti,omap2-hsmmc;
+ ti,hwmods = mmc4;
+ };
+
+ mmc5: mmc@5 {
+ compatible = ti,omap2-hsmmc;
+ ti,hwmods = mmc5;
+ };
};
};
These all should all be ti,omap3-hsmmc I guess?
Well, I defined the binding such that both omap2 and omap3
can use the same compatible ti,omap2-hsmmc since there is
no difference in the way they are defined or handled. If thats
confusing, I can have separate compatibles.
Btw, I guess we do the same with a few other re-used IPs as well,
I just checked and mcpsi does the same.
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: [PATCH v2 5/7] ARM: OMAP2+: Split omap2_hsmmc_init() to properly support I2C GPIO pins
On Friday 24 February 2012 12:17 AM, Tony Lindgren wrote:
* Igor Grinberggrinb...@compulab.co.il [120223 05:56]:
--- a/arch/arm/mach-omap2/board-cm-t35.c
+++ b/arch/arm/mach-omap2/board-cm-t35.c
@@ -411,9 +411,9 @@ static struct omap2_hsmmc_info mmc[] = {
{
.mmc= 1,
.caps = MMC_CAP_4_BIT_DATA,
- .gpio_cd= -EINVAL,
+ .gpio_cd= OMAP_MAX_GPIO_LINES + 0,
.gpio_wp= -EINVAL,
I don't have these changes, in my second revision of the patch.
It's best not to hardcode the values here.
Ok, I just though doing it the other way is more round about
hardcoding where in the board passes a hardcoded value to
twl4030 gpio driver and the driver passes the *same* hardcoded
value back to the board callback, which is then populated in
mmc pdata. The board could as well directly hardcode it in the
mmc pdata. That makes it much more readable than this round about
hardcoding.
But I'll go back to the old way if you think thats how we should
handle this.
-
+ .deferred = true,
},
{
.mmc= 2,
@@ -422,6 +422,7 @@ static struct omap2_hsmmc_info mmc[] = {
.gpio_cd= -EINVAL,
.gpio_wp= -EINVAL,
.ocr_mask = 0x0010, /* 3.3V */
+ .deferred = true,
Why do you defer this one?
It does not use external GPIO chip, in fact it does not use CD/WP at all.
Why do you have the following then to set gpio_cd?
There is only one instance of gpio_cd being populated for the
first element in the array mmc[], which is already deferred.
- mmc[0].gpio_cd = gpio + 0;
Igor was asking about the second element in the array which never
has gpio_cd populated. Its just initialized to -EINVAL and stays
that way.
},
{} /* Terminator */
};
@@ -469,9 +470,7 @@ static int cm_t35_twl_gpio_setup(struct device *dev,
unsigned gpio,
pr_err(CM-T35: could not obtain gpio for WiFi reset\n);
}
- /* gpio + 0 is mmc0_cd (input/IRQ) */
- mmc[0].gpio_cd = gpio + 0;
- omap2_hsmmc_init(mmc);
+ omap_hsmmc_deferred_add(mmc);
return 0;
}
Hmm I don't have omap_hsmmc_deferred_add() in my second version
of the patch either.
Rajendra, please do the patches on that, now it's impossible to
see what else you've changed. That's the version posted here:
http://www.spinics.net/lists/linux-omap/msg64884.html
Sorry for the mess up. I will make sure I have taken all changes/fixes
from your reposts.
regards,
Rajendra
@@ -639,6 +638,7 @@ static void __init cm_t3x_common_init(void)
omap_serial_init();
omap_sdrc_init(mt46h32m32lf6_sdrc_params,
mt46h32m32lf6_sdrc_params);
+ omap_hsmmc_init(mmc);
cm_t35_init_i2c();
omap_ads7846_init(1, CM_T35_GPIO_PENDOWN, 0, NULL);
cm_t35_init_ethernet();
Other then the comment above, looks fine.
I will probably be able to test this on Sunday.
OK
diff --git a/arch/arm/mach-omap2/board-igep0020.c
b/arch/arm/mach-omap2/board-igep0020.c
index a59ace0..11a6aa4 100644
--- a/arch/arm/mach-omap2/board-igep0020.c
+++ b/arch/arm/mach-omap2/board-igep0020.c
@@ -293,8 +293,9 @@ static struct omap2_hsmmc_info mmc[] = {
{
.mmc= 1,
.caps = MMC_CAP_4_BIT_DATA,
- .gpio_cd= -EINVAL,
+ .gpio_cd= OMAP_MAX_GPIO_LINES + 0,
.gpio_wp= -EINVAL,
+ .deferred = true,
},
#if defined(CONFIG_LIBERTAS_SDIO) || defined(CONFIG_LIBERTAS_SDIO_MODULE)
{
@@ -302,6 +303,7 @@ static struct omap2_hsmmc_info mmc[] = {
.caps = MMC_CAP_4_BIT_DATA,
.gpio_cd= -EINVAL,
.gpio_wp= -EINVAL,
+ .deferred = true,
same here, why defer it?
Because it too sets gpio_cd in the callback.
ditto
ditto, that too sets gpio_cd..
},
#endif
{} /* Terminator */
@@ -360,10 +362,8 @@ static int omap3evm_twl_gpio_setup(struct device *dev,
{
int r, lcd_bl_en;
- /* gpio + 0 is mmc0_cd (input/IRQ) */
omap_mux_init_gpio(63, OMAP_PIN_INPUT);
- mmc[0].gpio_cd = gpio + 0;
..here. Same for the others. So maybe check is some are wrong?
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: [PATCH v2 0/7] omap hsmmc init cleanup and section warning fixes for v3.4 merge window
On Friday 24 February 2012 12:22 AM, Tony Lindgren wrote: * Rajendra Nayakrna...@ti.com [120223 03:09]: Re-sending as these patches did not make it to the lists due to issues with my 'git send-email' Hi Tony, This is a re-spin of your series to fix up the section mismatch warnings noted by Russell with omap2_hsmmc_init(). The previous series had an issue around multiple insmod/rmmod of the twl4030 gpio driver when built as a module as reported by Russell again. OK, can you please rebase your patches on hsmmc branch in linux-omap at commit 0e91c8ddf0e0932da59ec1d116e34049791b0e73? Ok, will do. Note that at least the hardcoded GPIO numbers are no longer needed. Ok, I explained my rational in the other mail thread. Its always been hardcoded GPIO numbers and this will change only with DT as Benoit mentioned. I was just trying to make the hard-coding more readable. Will remove it and do it how it was done earlier, which is populate it in the callback. There were 2 issues, one with gpio_requests failing as they were never freed on the module unload/unbind. The other was with the mmc devices being registered again. I have fixed both these issues in this series, mainly by having a .teardown hook for twl4030 gpio driver populated from all OMAP3 board files, which release all the requested gpios and also unregister the mmc omap/platform device. Yes that's great. 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: [PATCH 1/5] ARM: OMAP2+: l3_noc: Remove references to static IRQ defines
On Fri, Feb 24, 2012 at 3:53 AM, Benoit Cousson b-cous...@ti.com wrote: The irq numbers are retrieved dynamically but the error logging is still referring to the OMAP44XX_IRQ_XXX defines instead of the irq number returned by platform_get_irq. Remove this reference to allow deletion of the irqs-44xx.h files. Clean the message and replace the pr_ macro by the dev_ equivalent. Signed-off-by: Benoit Cousson b-cous...@ti.com Cc: Santosh Shilimkar santosh.shilim...@ti.com --- Thanks Benoit. Patch looks good to me Acked-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
Re: [PATCH 3/5] ARM: OMAP2+: wakeupgen: Fix wrong array size for irq_target_cpu
On Fri, Feb 24, 2012 at 3:53 AM, Benoit Cousson b-cous...@ti.com wrote: The wakeupgen was wrongly allocating an array based on the NR_IRQS value (410 on OMAP4) whereas it is just capable of handling 128 entries. Moreover with SPARSE_IRQ, the NR_IRQS number might be 16, and thus cannot handle the proper number of entries. It will generate an oops as soon a driver will request an IRQ 16. Allocate the array using the fixed MAX_IRQS value (128). Signed-off-by: Benoit Cousson b-cous...@ti.com Cc: Santosh Shilimkar santosh.shilim...@ti.com --- arch/arm/mach-omap2/omap-wakeupgen.c | 4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) Right. Acked-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
Re: [PATCH 2/5] ARM: OMAP: irqs: Delete irqs-44xx.h file
On Fri, Feb 24, 2012 at 3:53 AM, Benoit Cousson b-cous...@ti.com wrote: Since all IRQs should be retrieved using hwmod for the moment and then device tree in the future, there is no need to keep a file defining all the IRQ numbers. Delete the file and copy the 4 entries that are still used directly by the board / driver until the code is properly cleaned. Signed-off-by: Benoit Cousson b-cous...@ti.com --- arch/arm/plat-omap/include/plat/irqs-44xx.h | 144 --- arch/arm/plat-omap/include/plat/irqs.h | 15 +++- 2 files changed, 12 insertions(+), 147 deletions(-) delete mode 100644 arch/arm/plat-omap/include/plat/irqs-44xx.h Nice. -144 :) Acked-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
Re: [PATCH 4/5] ARM: OMAP2+: gpmc: Use irq_alloc_descs instead of static IRQ range
On Fri, Feb 24, 2012 at 3:53 AM, Benoit Cousson b-cous...@ti.com wrote: The gpmc code is still not a proper driver and is still using the bad old static way of declaring its IRQ range for the various CS it can handle (8). Use irq_alloc_descs to get dynamically a set of IRQ descriptors. Clean some bad line wrapping here and there. Please note that this code is still not a real driver after this fix, and will require a massive cleanup... Agree. Signed-off-by: Benoit Cousson b-cous...@ti.com --- arch/arm/mach-omap2/gpmc.c | 22 +++--- 1 files changed, 15 insertions(+), 7 deletions(-) For the patch, Acked-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
Re: [PATCH 2/6] ARM: OMAP4 PM: Add IO Daisychain support
Djamil,
On Thursday 23 February 2012 09:28 PM, Elaidi, Djamil wrote:
Hi Kristo,
I think you must also add a omap_test_timeout() check after the Trigger WUCLKIN
disable, to verify WUCLK_STATUS has come back to 0.
This is needed because the IO daisy chain will not be ready until the WUCLKIN
falling edge has propagated.
You are right, this was missed and needs to be added.
Thanks for the review.
regards,
Rajendra
+ /* Trigger WUCLKIN disable */
+ omap4_prm_rmw_inst_reg_bits(OMAP4430_WUCLK_CTRL_MASK, 0x0,
+ OMAP4430_PRM_DEVICE_INST, OMAP4_PRM_IO_PMCTRL_OFFSET);
+ return;
+ omap_test_timeout(
+ (((omap4_prm_read_inst_reg(OMAP4430_PRM_DEVICE_INST,
+ OMAP4_PRM_IO_PMCTRL_OFFSET)
+ OMAP4430_WUCLK_STATUS_MASK)
+ OMAP4430_WUCLK_STATUS_SHIFT) == 0),
+ MAX_IOPAD_LATCH_TIME, i);
Best regards
Djamil ELAÏDI
+33 4 97 27 50 97
Software Systems Engineer
OMAP Platform Business Unit - PSI Modem Integration
Texas Instruments
-Original Message-
From: linux-omap-ow...@vger.kernel.org
[mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of Kristo, Tero
Sent: jeudi 23 février 2012 14:22
To: linux-omap@vger.kernel.org; Hilman, Kevin
Cc: linux-arm-ker...@lists.infradead.org; Nayak, Rajendra; Sripathy, Vishwanath
Subject: [PATCH 2/6] ARM: OMAP4 PM: Add IO Daisychain support
From: Rajendra Nayakrna...@ti.com
patch adds IO Daisychain support for OMAP4 as per section 3.9.4 in OMAP4430
Public TRM.
Signed-off-by: Rajendra Nayakrna...@ti.com
Signed-off-by: Vishwanath BSvishwanath...@ti.com
Signed-off-by: Tero Kristot-kri...@ti.com
---
arch/arm/mach-omap2/prm44xx.c | 32
arch/arm/mach-omap2/prm44xx.h |1 +
2 files changed, 33 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/prm44xx.c b/arch/arm/mach-omap2/prm44xx.c
index 33dd655..1557647 100644
--- a/arch/arm/mach-omap2/prm44xx.c
+++ b/arch/arm/mach-omap2/prm44xx.c
@@ -230,6 +230,41 @@ void omap44xx_prm_restore_irqen(u32 *saved_mask)
OMAP4_PRM_IRQENABLE_MPU_2_OFFSET);
}
+/**
+ * Maximum time(us) it takes to output the signal WUCLKOUT of the last pad of
+ * the I/O ring after asserting WUCLKIN high
+ */
+#define MAX_IOPAD_LATCH_TIME 1000
+
+/* OMAP4 IO Daisychain trigger sequence */
+void omap4_trigger_wuclk_ctrl(void)
+{
+ int i = 0;
+
+ /* Enable GLOBAL_WUEN */
+ if (!(omap4_prm_read_inst_reg(OMAP4430_PRM_DEVICE_INST,
+ OMAP4_PRM_IO_PMCTRL_OFFSET) OMAP4430_GLOBAL_WUEN_MASK))
+ omap4_prm_rmw_inst_reg_bits(OMAP4430_GLOBAL_WUEN_MASK,
+ OMAP4430_GLOBAL_WUEN_MASK, OMAP4430_PRM_DEVICE_INST,
+ OMAP4_PRM_IO_PMCTRL_OFFSET);
+
+ /* Trigger WUCLKIN enable */
+ omap4_prm_rmw_inst_reg_bits(OMAP4430_WUCLK_CTRL_MASK,
+ OMAP4430_WUCLK_CTRL_MASK, OMAP4430_PRM_DEVICE_INST,
+ OMAP4_PRM_IO_PMCTRL_OFFSET);
+ omap_test_timeout(
+ (((omap4_prm_read_inst_reg(OMAP4430_PRM_DEVICE_INST,
+ OMAP4_PRM_IO_PMCTRL_OFFSET)
+ OMAP4430_WUCLK_STATUS_MASK)
+ OMAP4430_WUCLK_STATUS_SHIFT) == 1),
+ MAX_IOPAD_LATCH_TIME, i);
+
+ /* Trigger WUCLKIN disable */
+ omap4_prm_rmw_inst_reg_bits(OMAP4430_WUCLK_CTRL_MASK, 0x0,
+ OMAP4430_PRM_DEVICE_INST, OMAP4_PRM_IO_PMCTRL_OFFSET);
+ return;
+}
+
static int __init omap4xxx_prcm_init(void)
{
if (cpu_is_omap44xx())
diff --git a/arch/arm/mach-omap2/prm44xx.h b/arch/arm/mach-omap2/prm44xx.h
index 7978092..a840f0f 100644
--- a/arch/arm/mach-omap2/prm44xx.h
+++ b/arch/arm/mach-omap2/prm44xx.h
@@ -762,6 +762,7 @@ void omap4_prm_vp_clear_txdone(u8 vp_id);
extern u32 omap4_prm_vcvp_read(u8 offset);
extern void omap4_prm_vcvp_write(u32 val, u8 offset);
extern u32 omap4_prm_vcvp_rmw(u32 mask, u32 bits, u8 offset);
+extern void omap4_trigger_wuclk_ctrl(void);
/* PRM interrupt-related functions */
extern void omap44xx_prm_read_pending_irqs(unsigned long *events);
--
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/6] ARM: OMAP4 PM: Add IO Daisychain support
On Thursday 23 February 2012 07:18 PM, Shilimkar, Santosh wrote: On Thu, Feb 23, 2012 at 6:51 PM, Tero Kristot-kri...@ti.com wrote: [..] +/** + * Maximum time(us) it takes to output the signal WUCLKOUT of the last pad of + * the I/O ring after asserting WUCLKIN high + */ +#define MAX_IOPAD_LATCH_TIME 1000 + Is the 1000 us/ms ? 1000 us. Is that documented or arbitrary chosen ? looks like it was arbitrarily chosen as there's no documentation on the worst case delay. I spoke to Nilesh (copied) and he suggested using a value close to 100us instead which should be quite safe. 1000us according to him is really very high. however there does not seem to be any documented value available for this in any of the specs. Rest of the change looks good to me. 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 v2 5/7] ARM: OMAP2+: Split omap2_hsmmc_init() to properly support I2C GPIO pins
On 02/24/12 06:11, Rajendra Nayak wrote:
On Friday 24 February 2012 12:17 AM, Tony Lindgren wrote:
* Igor Grinberggrinb...@compulab.co.il [120223 05:56]:
--- a/arch/arm/mach-omap2/board-cm-t35.c
+++ b/arch/arm/mach-omap2/board-cm-t35.c
@@ -411,9 +411,9 @@ static struct omap2_hsmmc_info mmc[] = {
{
.mmc= 1,
.caps= MMC_CAP_4_BIT_DATA,
-.gpio_cd= -EINVAL,
+.gpio_cd= OMAP_MAX_GPIO_LINES + 0,
.gpio_wp= -EINVAL,
I don't have these changes, in my second revision of the patch.
It's best not to hardcode the values here.
Ok, I just though doing it the other way is more round about
hardcoding where in the board passes a hardcoded value to
twl4030 gpio driver and the driver passes the *same* hardcoded
value back to the board callback, which is then populated in
mmc pdata. The board could as well directly hardcode it in the
mmc pdata.
That makes it much more readable than this round about
hardcoding.
But I'll go back to the old way if you think thats how we should
handle this.
The old way is preferable. Thanks.
-
+.deferred= true,
},
{
.mmc= 2,
@@ -422,6 +422,7 @@ static struct omap2_hsmmc_info mmc[] = {
.gpio_cd= -EINVAL,
.gpio_wp= -EINVAL,
.ocr_mask= 0x0010,/* 3.3V */
+.deferred= true,
Why do you defer this one?
It does not use external GPIO chip, in fact it does not use CD/WP at all.
Why do you have the following then to set gpio_cd?
There is only one instance of gpio_cd being populated for the
first element in the array mmc[], which is already deferred.
-mmc[0].gpio_cd = gpio + 0;
Igor was asking about the second element in the array which never
has gpio_cd populated. Its just initialized to -EINVAL and stays
that way.
Exactly.
},
{}/* Terminator */
};
@@ -469,9 +470,7 @@ static int cm_t35_twl_gpio_setup(struct device *dev,
unsigned gpio,
pr_err(CM-T35: could not obtain gpio for WiFi reset\n);
}
-/* gpio + 0 is mmc0_cd (input/IRQ) */
-mmc[0].gpio_cd = gpio + 0;
-omap2_hsmmc_init(mmc);
+omap_hsmmc_deferred_add(mmc);
return 0;
}
Hmm I don't have omap_hsmmc_deferred_add() in my second version
of the patch either.
Rajendra, please do the patches on that, now it's impossible to
see what else you've changed. That's the version posted here:
http://www.spinics.net/lists/linux-omap/msg64884.html
Sorry for the mess up. I will make sure I have taken all changes/fixes
from your reposts.
regards,
Rajendra
@@ -639,6 +638,7 @@ static void __init cm_t3x_common_init(void)
omap_serial_init();
omap_sdrc_init(mt46h32m32lf6_sdrc_params,
mt46h32m32lf6_sdrc_params);
+omap_hsmmc_init(mmc);
cm_t35_init_i2c();
omap_ads7846_init(1, CM_T35_GPIO_PENDOWN, 0, NULL);
cm_t35_init_ethernet();
Other then the comment above, looks fine.
I will probably be able to test this on Sunday.
OK
diff --git a/arch/arm/mach-omap2/board-igep0020.c
b/arch/arm/mach-omap2/board-igep0020.c
index a59ace0..11a6aa4 100644
--- a/arch/arm/mach-omap2/board-igep0020.c
+++ b/arch/arm/mach-omap2/board-igep0020.c
@@ -293,8 +293,9 @@ static struct omap2_hsmmc_info mmc[] = {
{
.mmc= 1,
.caps= MMC_CAP_4_BIT_DATA,
-.gpio_cd= -EINVAL,
+.gpio_cd= OMAP_MAX_GPIO_LINES + 0,
.gpio_wp= -EINVAL,
+.deferred= true,
},
#if defined(CONFIG_LIBERTAS_SDIO) || defined(CONFIG_LIBERTAS_SDIO_MODULE)
{
@@ -302,6 +303,7 @@ static struct omap2_hsmmc_info mmc[] = {
.caps= MMC_CAP_4_BIT_DATA,
.gpio_cd= -EINVAL,
.gpio_wp= -EINVAL,
+.deferred= true,
same here, why defer it?
Because it too sets gpio_cd in the callback.
Well, not this array element...
ditto
ditto, that too sets gpio_cd..
Nope... ditto ;)
},
#endif
{}/* Terminator */
@@ -360,10 +362,8 @@ static int omap3evm_twl_gpio_setup(struct device *dev,
{
int r, lcd_bl_en;
-/* gpio + 0 is mmc0_cd (input/IRQ) */
omap_mux_init_gpio(63, OMAP_PIN_INPUT);
-mmc[0].gpio_cd = gpio + 0;
..here. Same for the others. So maybe check is some are wrong?
I failed parsing the question...
Here only the first array element gets the gpio_cd value set.
--
Regards,
Igor.
--
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: Latest OMAP randconfig build error
On Thu, Feb 23, 2012 at 12:56 AM, Tony Lindgren t...@atomide.com wrote: Care to post an updated patch for me to apply into fixes? Coming right up! -- 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: OMAP: Fix section mismatch warning for platform_cpu_die()
2012/2/23 Uwe Kleine-König u.kleine-koe...@pengutronix.de:
Hello,
On Thu, Feb 23, 2012 at 12:28:30PM +0530, Santosh Shilimkar wrote:
WARNING: vmlinux.o(.text+0x226d0):
Section mismatch in reference from the function
platform_cpu_die() to the function .cpuinit.text:omap4_hotplug_cpu()
The function platform_cpu_die() references
the function __cpuinit omap4_hotplug_cpu().
This is often because platform_cpu_die lacks a __cpuinit
annotation or the annotation of omap4_hotplug_cpu is wrong.
Thanks to Russell King for suggesting __ref annotation trick
just like it's parent function for this warning becasue __cupinit
s/it's/its/; s/becasue/because/; s/cup/cpu/
Having said that I think the grammar is broken, too. Maybe:
Thanks to Russell King for suggesting to use __ref instead of
the initial (and wrong) approach to use __cpuinit.
(But note I'm not a native speaker, too)
Thanks for fixing the grammar. :)
Updated patch below with comments corrected as per
your suggestion.
Regards
Santosh
From a53dd2d822dc9c9894c2f2f3d239af341c66d891 Mon Sep 17 00:00:00 2001
From: Santosh Shilimkar santosh.shilim...@ti.com
Date: Wed, 22 Feb 2012 16:10:04 +0530
Subject: [PATCH 2/2] ARM: OMAP: Fix section mismatch warning for
platform_cpu_die()
WARNING: vmlinux.o(.text+0x226d0):
Section mismatch in reference from the function
platform_cpu_die() to the function .cpuinit.text:omap4_hotplug_cpu()
The function platform_cpu_die() references
the function __cpuinit omap4_hotplug_cpu().
This is often because platform_cpu_die lacks a __cpuinit
annotation or the annotation of omap4_hotplug_cpu is wrong.
Thanks to Russell King for suggesting to use __ref instead of
the initial (and wrong) approach to use __cpuinit.
Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com
---
arch/arm/mach-omap2/omap-hotplug.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-omap2/omap-hotplug.c
b/arch/arm/mach-omap2/omap-hotplug.c
index adbe4d8..56c345b 100644
--- a/arch/arm/mach-omap2/omap-hotplug.c
+++ b/arch/arm/mach-omap2/omap-hotplug.c
@@ -33,7 +33,7 @@ int platform_cpu_kill(unsigned int cpu)
* platform-specific code to shutdown a CPU
* Called with IRQs disabled
*/
-void platform_cpu_die(unsigned int cpu)
+void __ref platform_cpu_die(unsigned int cpu)
{
unsigned int this_cpu;
--
1.7.4.1
0002-ARM-OMAP-Fix-section-mismatch-warning-for-platform_c.patch
Description: Binary data
Re: [PATCH] OMAP4: dma: Correct CPU version check for dma_common_ch_end
On Thu, Feb 23, 2012 at 12:59 PM, Peter Ujfalusi peter.ujfal...@ti.com wrote: Hi Tony, On 02/23/2012 01:07 AM, Tony Lindgren wrote: * Peter Ujfalusi peter.ujfal...@ti.com [120217 00:54]: CCDN is the last common channel register in all OMAP4 versions. Use cpu_is_omap44xx() instead of the cpu_is_omap4430() - which is anyway not doing what it supposed to do. This is a bit unclear.. Which is not doing what is supposed to do? DMA driver? Or one of the cpu_is_omap? The cpu_is_omap4430() returns 0 unconditionally. Because of this the dma_common_ch_end is wrongly configured on OMAP4 (even on OMAP4430). If this should be queued as a fix, then we need some kind of description here what breaks. I will resend the patch with a better commit message. This is a bug for sure, but I'm not sure how severe it is. At best we are not clearing the registers between CCFN, and CCDN on OMAP4. The bug is not severe. Infact these registers are needed for descriptor loading sDMA feature which never made it to mainline :) So nothing should get impacted. 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] cbus: Fix lines for Nokia 770
Hi,
On Wed, Feb 22, 2012 at 02:09:37PM -0800, Tony Lindgren wrote:
From 54c4785b8d274f8d282b4243945ae0b17edf4686 Mon Sep 17 00:00:00 2001
From: Tony Lindgren t...@atomide.com
Date: Wed, 22 Feb 2012 13:03:07 -0800
Subject: [PATCH] cbus: Fix lines for Nokia 770
This makes retu and tahvo work again on Nokia 770 so it
stays running.
Signed-off-by: Tony Lindgren t...@atomide.com
---
I applied this into cbus branch as it seems to fix retu
watchdog for Nokia 770.
--- a/arch/arm/mach-omap1/board-nokia770.c
+++ b/arch/arm/mach-omap1/board-nokia770.c
@@ -87,9 +87,9 @@ static struct platform_device nokia770_kp_device = {
#if defined(CONFIG_CBUS) || defined(CONFIG_CBUS_MODULE)
static struct cbus_host_platform_data nokia770_cbus_data = {
- .clk_gpio = OMAP_MPUIO(11),
+ .clk_gpio = OMAP_MPUIO(9),
.dat_gpio = OMAP_MPUIO(10),
- .sel_gpio = OMAP_MPUIO(9),
+ .sel_gpio = OMAP_MPUIO(11),
};
static struct platform_device nokia770_cbus_device = {
Has this been wrong since the beginning ? Looking at commit d64193bd, I
just moved whatever was on cbus.c to respective board-files.
Look at these snippets:
commit d64193bd89bad6a1dab55a62940808789d68ecc2
Author: Felipe Balbi felipe.ba...@nokia.com
Date: Tue Aug 3 12:09:59 2010 +0300
cbus: add platform_data to pass gpios
also add the platform_data to the related
board files.
Signed-off-by: Felipe Balbi felipe.ba...@nokia.com
Signed-off-by: Tony Lindgren t...@atomide.com
diff --git a/arch/arm/mach-omap1/board-nokia770.c
b/arch/arm/mach-omap1/board-nokia770.c
index 6423671..ce23990 100644
--- a/arch/arm/mach-omap1/board-nokia770.c
+++ b/arch/arm/mach-omap1/board-nokia770.c
[snip]
@@ -95,9 +96,18 @@ static struct platform_device nokia770_kp_device = {
.resource = nokia770_kp_resources,
};
+static struct cbus_host_platform_data nokia770_cbus_data = {
+ .clk_gpio = OMAP_MPUIO(11),
+ .dat_gpio = OMAP_MPUIO(10),
+ .sel_gpio = OMAP_MPUIO(9),
+};
+
static struct platform_device nokia770_cbus_device = {
.name = cbus,
.id = -1,
+ .dev= {
+ .platform_data = nokia770_cbus_data,
+ },
};
static struct platform_device *nokia770_devices[] __initdata = {
[snip]
diff --git a/drivers/cbus/cbus.c b/drivers/cbus/cbus.c
index a35941e..00c3c32 100644
--- a/drivers/cbus/cbus.c
+++ b/drivers/cbus/cbus.c
[ snip]
@@ -234,31 +236,9 @@ static int __init cbus_bus_probe(struct platform_device
*pdev)
spin_lock_init(chost-lock);
- /* REVISIT: Pass these from board-*.c files in platform_data */
- if (machine_is_nokia770()) {
- chost-clk_gpio = OMAP_MPUIO(11);
- chost-dat_gpio = OMAP_MPUIO(10);
- chost-sel_gpio = OMAP_MPUIO(9);
- } else if (machine_is_nokia_n800() || machine_is_nokia_n810() ||
- machine_is_nokia_n810_wimax()) {
- chost-clk_gpio = 66;
- chost-dat_gpio = 65;
- chost-sel_gpio = 64;
- } else {
- printk(KERN_ERR cbus: Unsupported board\n);
- ret = -ENODEV;
- goto exit1;
- }
-
-#ifdef CONFIG_ARCH_OMAP1
- if (!OMAP_GPIO_IS_MPUIO(chost-clk_gpio) ||
- !OMAP_GPIO_IS_MPUIO(chost-dat_gpio) ||
- !OMAP_GPIO_IS_MPUIO(chost-sel_gpio)) {
- printk(KERN_ERR cbus: Only MPUIO pins supported\n);
- ret = -ENODEV;
- goto exit1;
- }
-#endif
+ chost-clk_gpio = pdata-clk_gpio;
+ chost-dat_gpio = pdata-dat_gpio;
+ chost-sel_gpio = pdata-sel_gpio;
if ((ret = gpio_request(chost-clk_gpio, CBUS clk)) 0)
goto exit1;
--
balbi
signature.asc
Description: Digital signature
[PATCH] ARM: OMAP2: fix mailbox init code
Fix this:
arch/arm/mach-omap2/mailbox.c: In function 'omap2_mbox_probe':
arch/arm/mach-omap2/mailbox.c:354: error: 'omap2_mboxes' undeclared (first use
in this function)
arch/arm/mach-omap2/mailbox.c:354: error: (Each undeclared identifier is
reported only once
arch/arm/mach-omap2/mailbox.c:354: error: for each function it appears in.)
Which happens on CONFIG_ARCH_OMAP2 !CONFIG_SOC_OMAP2420, due to
missing omap2_mboxes declaration.
In addition, make sure we declare the right mailbox instances for 2430.
Reported-by: Russell King li...@arm.linux.org.uk
Signed-off-by: Ohad Ben-Cohen o...@wizery.com
Cc: Tony Lindgren t...@atomide.com
Cc: Hiroshi Doyu hd...@nvidia.com
Cc: Omar Ramirez Luna omar.rami...@ti.com
---
arch/arm/mach-omap2/mailbox.c | 10 +-
1 files changed, 9 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-omap2/mailbox.c b/arch/arm/mach-omap2/mailbox.c
index 609ea2d..415a6f1 100644
--- a/arch/arm/mach-omap2/mailbox.c
+++ b/arch/arm/mach-omap2/mailbox.c
@@ -281,8 +281,16 @@ static struct omap_mbox mbox_iva_info = {
.ops= omap2_mbox_ops,
.priv = omap2_mbox_iva_priv,
};
+#endif
-struct omap_mbox *omap2_mboxes[] = { mbox_dsp_info, mbox_iva_info, NULL };
+#ifdef CONFIG_ARCH_OMAP2
+struct omap_mbox *omap2_mboxes[] = {
+ mbox_dsp_info,
+#ifdef CONFIG_SOC_OMAP2420
+ mbox_iva_info,
+#endif
+ NULL
+};
#endif
#if defined(CONFIG_ARCH_OMAP4)
--
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: [PATCHv2 8/8] arm: omap3: prevent per_clkdm from attempting manual domain transitions
On Wed, 2012-02-22 at 14:37 -0800, Kevin Hilman wrote:
Tero Kristo t-kri...@ti.com writes:
On Thu, 2012-02-16 at 09:31 -0800, Kevin Hilman wrote:
Tero Kristo t-kri...@ti.com writes:
On Thu, 2012-02-16 at 21:15 +0530, Shilimkar, Santosh wrote:
On Thu, Feb 16, 2012 at 8:53 PM, Tero Kristo t-kri...@ti.com wrote:
On Thu, 2012-02-16 at 15:15 +0200, Tero Kristo wrote:
On Thu, 2012-02-16 at 15:27 +0530, Shilimkar, Santosh wrote:
On Thu, Feb 16, 2012 at 2:27 PM, Tero Kristo t-kri...@ti.com
wrote:
On Wed, 2012-02-15 at 11:37 -0800, Kevin Hilman wrote:
Tero Kristo t-kri...@ti.com writes:
Attempting this will cause problems especially with off-mode
enabled.
Please be more verbose about the problems seen, and the root
cause(s).
I was actually looking forward for some help with this commit
message,
as I am still not quite sure what is going on in here. :) Here
is the
log for suspend (btw, cam_pwrdm does not go to off in mainline
yet, but
I think that is probably fixed by the patch from Paul,
omap_set_pwrdm_state() does not work properly.) The warning
comes out
after wakeup from off-mode, and it is triggered by the disabling
of
autodeps before off-mode entry.
This mostly indicates that one of the per clock-domain module
clock turning ON seems to be not working well with auto deps
disabled. This leads to interconnect violation.
if not tried already, can you put the per_clockdomain in SW_WKUP
in the low power code early resume path and see if this
error goes away.
This seems to get rid of the dump also. It looks like some driver
resume
is not behaving nicely, I am trying to pinpoint the culprit currently
and see whether it can provide more info.
Okay, I have some more info about this now.
What happens is that when entering off-mode, PER domain remains OFF
even
during the execution of the exit phase from omap_sram_idle. Adding a
manual SW_WKUP it comes up and there are no issues. If autodeps are
enabled on the domain, it comes back from off mode as active.
Looking further in the code, we have this at the end of
omap_sram_idle:
if (per_next_state PWRDM_POWER_ON) {
per_prev_state = pwrdm_read_prev_pwrst(per_pwrdm);
omap2_gpio_resume_after_idle();
wake_per();
if (per_prev_state == PWRDM_POWER_OFF)
omap3_per_restore_context();
}
... which seems to assume that per domain is on. Gpio code does not
control any clocks currently, as it only requires the interface clock
to
be on, and as this is autoidled
Any comments how we should handle this? Shall we just keep these two
patches for handling this or add some different hackery for the gpio
issue?
Good. I thought too that issue will disappear.
The issue is pretty clear. Technically every driver pm_runtime() code
should
be able to manage a clock-clockdomain-power domain power up/down
sequence. That should work without auto deps.
Do you narrowed down which driver resume is creating the dump ?
UART , GPIO ?
It is the gpio base stuff called from omap_sram_idle(), basically the
restore context part. If I force enable per domain before the code
snippet before, there is no dump, but if it is done after, I get the
dump.
The thing is that gpio driver doesn't currently have this kind of
mechanism for the restore context part, at least not on omap3 due to
above clocking issue (only autoidled interface clock is used.)
I'm not sure if it fully addresses this, but Tarun's series converts
GPIO to runtime PM.
Can you try with Tarun's series. See the for_3.4/gpio_cleanup_fixes_v9
branch here:
git://gitorious.org/~tarunkanti/omap-sw-develoment/tarunkantis-linux-omap-dev.git
It does something for the issue, but I still get this during suspend to
off:
[ 11.284973] PM: Syncing filesystems ... done.
[ 11.379241] Freezing user space processes ... (elapsed 0.02 seconds)
done.
[ 11.408233] Freezing remaining freezable tasks ... (elapsed 0.02
seconds) don
e.
[ 11.439239] Suspending console(s) (use no_console_suspend to debug)
[ 11.564178] PM: suspend of devices complete after 115.506 msecs
[ 11.567382] PM: late suspend of devices complete after 3.204 msecs
[ 11.567443] Disabling non-boot CPUs ...
[ 12.004089] Powerdomain (cam_pwrdm) didn't enter target state 0
[ 12.004119] Could not enter target state in pm_suspend
[ 12.009368] PM: early resume of devices complete after 4.944 msecs
[ 12.436645] PM: resume of devices complete after 426.086 msecs
[ 12.480285] Restarting tasks ... done.
/sys/kernel/debu[ 12.488433]
Re: [PATCH] OMAP4: dma: Correct CPU version check for dma_common_ch_end
On 02/23/2012 10:42 AM, Shilimkar, Santosh wrote: The bug is not severe. Infact these registers are needed for descriptor loading sDMA feature which never made it to mainline :) So nothing should get impacted. Yes, this is my understanding as well. -- Péter -- 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 03/14] arm: omap3+: voltage: parameter segregation
On Wed, 2012-02-22 at 19:37 -0600, Menon, Nishanth wrote:
On Tue, Feb 21, 2012 at 08:04, Tero Kristo t-kri...@ti.com wrote:
[...]
diff --git a/arch/arm/mach-omap2/voltage.h b/arch/arm/mach-omap2/voltage.h
index 949938d..940a0d6 100644
--- a/arch/arm/mach-omap2/voltage.h
+++ b/arch/arm/mach-omap2/voltage.h
[...]
@@ -171,6 +169,18 @@ struct omap_voltdm_pmic {
u8 (*uv_to_vsel) (unsigned long uV);
};
+struct omap_vp_param {
+ u32 vddmax;
+ u32 vddmin;
+};
+
Thinking a little deeper about this(SoC level vdd min and max) on a
slightly different angle- core of the question that intend to answer
are:
- what is the least voltage we want to allow in active transtion? it
should not be lower than retention voltage.
I think this is a fair assumption, so we could init the vddmin to be the
same as the retention voltage for the domain (or even drop the
parameter.)
- what is the max voltage we want to allow in active transition? it
should be the max Nom voltage of all the OPPs for that domain.
Isn't it higher? I guess smartreflex can scale voltages even up from the
nominal level if we have a really old and/or bad silicon. Limiting this
to max opp would be bad, no? Maybe we could use max opp voltage + some
margin though... but what would be a safe margin here?
In effect, why do we even need to register
voltdm-vp_param-vdd[min|max]? We already have that info - right?
On the other hand it might be safer to do this way to handle quirks in
future SoCs.. but thought I'd spit it out anyways..
+struct omap_vc_param {
and elsewhere - please add kernel-doc struct documentation as well
when new structs are introduced?
Yea, I can add those for next version.
+ u32 on;
+ u32 onlp;
+ u32 ret;
+ u32 off;
+};
+
[...]
Regards,
Nishanth Menon
--
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: OMAP2: fix mailbox init code
On Thu, Feb 23, 2012 at 14:23:35, Ohad Ben-Cohen wrote:
[...]
Which happens on CONFIG_ARCH_OMAP2 !CONFIG_SOC_OMAP2420, due to
missing omap2_mboxes declaration.
[...]
-struct omap_mbox *omap2_mboxes[] = { mbox_dsp_info, mbox_iva_info, NULL };
+#ifdef CONFIG_ARCH_OMAP2
+struct omap_mbox *omap2_mboxes[] = {
+ mbox_dsp_info,
+#ifdef CONFIG_SOC_OMAP2420
+ mbox_iva_info,
+#endif
+ NULL
+};
#endif
#if defined(CONFIG_ARCH_OMAP4)
Instead of adding more #ifs can they be completely removed please?
--
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
[GIT PULL] OMAP DSS fixes for 3.3-rc
Hi Florian, Two fixes for OMAP DSS for 3.3: First one gets the HDMI output working again. Managing the clocks for OMAP4 is not very simple, and this patch circumvents the problems we have in the clock framework. It's a clean but rather hacky fix, but it shouldn't cause any side-effects. The issue will hopefully be fixed properly with DT when we'll get proper parent-child hierarchy for DSS HW submodules. The second one is a simple fix for HDMI hotplug detection, which I missed when I wrote the HDMI PHY fix (c49d005b6cc8491fad5b24f82805be2d6bcbd3dd). Tomi The following changes since commit d65b4e98d7ea3038b767b70fe8be959b2913f16d: Linux 3.3-rc3 (2012-02-08 19:21:53 -0800) are available in the git repository at: git://gitorious.org/linux-omap-dss2/linux.git for-3.3-rc Archit Taneja (1): OMAPDSS: HACK: Ensure DSS clock domain gets out of idle when HDMI is enabled Rob Clark (1): OMAPDSS: HDMI: hot plug detect fix drivers/video/omap2/dss/hdmi.c| 24 +++- drivers/video/omap2/dss/ti_hdmi_4xxx_ip.c |9 + 2 files changed, 24 insertions(+), 9 deletions(-) signature.asc Description: This is a digitally signed message part
RE: [GIT PULL] OMAP PM EMU fix for v3.3
Hi Paul, Please find my comments inlined. Thanks Gowda -Original Message- From: linux-arm-kernel-boun...@lists.infradead.org [mailto:linux-arm-kernel-boun...@lists.infradead.org] On Behalf Of Paul Walmsley Sent: 23 February 2012 06:09 To: Gowda Madhusudhan Cc: khil...@ti.com; t...@atomide.com; linux-omap@vger.kernel.org; linux-arm-ker...@lists.infradead.org Subject: RE: [GIT PULL] OMAP PM EMU fix for v3.3 Hello Gowda, A few questions... On Wed, 22 Feb 2012, madhusudhan.go...@elektrobit.com wrote: I have tested this on beagle board as well as on OMAP3630 based propriatory phone using SDTI serial trace interface. What driver are you using for SDTI? Does it use pm_runtime* or call clk_enable() on some clock when it is in use? Are you defining a hwmod for it? I don't see an SDTI driver in mainline, but maybe I am just missing it. If it's not there, could you please post it or post a link to it so we can take a look at what it's doing? Also you can test it by just observing the CM_EMU (48005100) clkstctrl register 48 = 0001 Across MPU OFF alone [root@beagleboard /]# echo 0 /sys/kernel/debug/pm_debug/neon_pwrdm/suspend [root@beagleboard /]# echo 0 /sys/kernel/debug/pm_debug/mpu_pwrdm/suspend [root@beagleboard /]# echo 1 /sys/kernel/debug/pm_debug/core_pwrdm/suspend [root@beagleboard /]# echo 1 /sys/kernel/debug/pm_debug/per_pwrdm/suspend [root@beagleboard /]# echo mem /sys/power/state [ 59.694671] PM: Syncing filesystems ... done. [ 59.758209] Freezing user space processes ... (elapsed 0.02 seconds) done. [ 59.789947] Freezing remaining freezable tasks ... (elapsed 0.02 seconds) done. [ 59.820709] Suspending console(s) (use no_console_suspend to debug) [ 60.055816] PM: suspend of devices complete after 212.493 msecs [ 60.059661] PM: late suspend of devices complete after 3.784 msecs [ 60.059753] Disabling non-boot CPUs ... [ 64.299865] Successfully put all powerdomains to target state [ 64.302551] PM: early resume of devices complete after 2.319 msecs [ 64.636444] PM: resume of devices complete after 332.336 msecs [ 64.688446] Restarting tasks ... done. [root@beagleboard /]# And then print again the CM_EMU (48005100) clkstctrl register offset 48 this will have the reset value and PRM_EMU (48307100) offset e4 = 0100 register confirms the domain wakeup reset from OFF. At this moment the SDTI serial trace interface looses connection. With my patch applied the CM_EMU (48005100) clkstctrl register restores it initial setting across MPU OFF. Maybe you can walk through these thoughts with me and see if it makes sense to you. When the PM code initializes, it will put the EMU clockdomain to software-supervised sleep. (Ideally it would put it to hardware-supervised idle, but Jouni turned this off a long time ago, apparently due to some PRCM usecounting problem with it -- which may simply have been some software problem on our part?) That accounts for CM_CLKSTCTRL_EMU being set to 0x1 before MPU OFF. Does the SDTI work for you when CM_CLKSTCTRL_EMU is set to 0x1? There's no FCLKEN/ICLKEN bit for the PRCM to use-count, it seems :-( Although maybe this is done through the SDTI_WINCTRL register? I observe the same phenomenon that you do, that when MPU comes back from OFF, CM_CLKSTCTRL_EMU is set to 0x2. From reading the TRM, it's not clear to me what is causing that, although I'd agree with your conclusion that it's related to the MPU's reset line. But here's the part that's unclear to me about your description: according to the TRM, 0x2 means software-supervised wakeup. So the EMU clockdomain should be awake at that point. That shouldn't prevent the SDTI from working; in fact quite the opposite. So I don't really understand how your patch would fix anything in this regard. Any thoughts? My suspicion, by the way, is that the underlying problem may be with the SDTI driver that you're using. My guess would be that it's not integrated with the OMAP power management infrastructure (via pm_runtime* calls), and that's what's causing the problem. [Gowda] I found this BUG in the CM code while trying to use both SDTI as well as requirement of enabling Hardware supervised transition CLKTRCTRL_EMU to 0x3. SDTI requires the softwre supervised transition to keep connected, by enabling Hardware supervised transition SDTI does not like it so Jouni had commented out the HW supervised transtion. Which I agree it is fine on SDTI part. .flags = /* CLKDM_CAN_ENABLE_AUTO | */CLKDM_CAN_SWSUP, But my point here is when I set the HW supervised transition, across MPU OFF the register loses its previous value and changes to reset value 0x2 (SW supervised) is not correct. So I submitted this patch for fixing this general CM code bug. Please let me know if my comments answers your question. - Paul ___ linux-arm-kernel mailing list linux-arm-ker...@lists.infradead.org
Re: [RFC PATCH 1/2] of: Add generic device tree DMA helpers
Salut Nico,
On 2/22/2012 11:59 AM, Nicolas Ferre wrote:
On 01/27/2012 06:29 PM, Cousson, Benoit :
Add some basic helpers to retrieve a DMA controller device_node
and the DMA request line number.
For legacy reason another API will export the DMA request number
into a Linux resource of type IORESOURCE_DMA.
This API is usable only on system with an unique DMA controller.
Hi,
I followed that discussion and I like very much the biding that Benoit
is proposing. It will help me a lot with my current work on Atmel DMA
controller.
If I understand correctly, some rework is needed before it can be
integrated in a stable git tree (I mean before we can base our work on
top of it). So, in the meantime, what should I do to help and make
things go forward? to be quite frank, I would be interested to have a
working DMA enabled device soon ;-)
Me too, but unfortunately, I was busy trying to add irq_domain and
fixing issues with SPARSE_IRQ on OMAP :-(
Do you think that 3.4 is out of reach?
Maybe not, from the comments, it looks like we should add a .xlate
callback to allow any custom parsing of the DMA nodes attributes.
I'll be more than happy, if you can finalize that patch :-)
Thanks,
Benoit
Best regards,
Signed-off-by: Benoit Coussonb-cous...@ti.com
Cc: Grant Likelygrant.lik...@secretlab.ca
Cc: Rob Herringrob.herr...@calxeda.com
---
Documentation/devicetree/bindings/dma/dma.txt | 44 +
drivers/of/Kconfig|5 +
drivers/of/Makefile |1 +
drivers/of/dma.c | 130 +
include/linux/of_dma.h| 49 +
5 files changed, 229 insertions(+), 0 deletions(-)
create mode 100644 Documentation/devicetree/bindings/dma/dma.txt
create mode 100644 drivers/of/dma.c
create mode 100644 include/linux/of_dma.h
diff --git a/Documentation/devicetree/bindings/dma/dma.txt
b/Documentation/devicetree/bindings/dma/dma.txt
new file mode 100644
index 000..7f2a301
--- /dev/null
+++ b/Documentation/devicetree/bindings/dma/dma.txt
@@ -0,0 +1,44 @@
+* Generic DMA Controller and DMA request bindings
+
+Generic binding to provide a way for a driver to retrieve the
+DMA request line that goes from an IP to a DMA controller.
+
+
+* DMA controller
+
+Required properties:
+- dma-controller: Mark the device as a DMA controller
+- #dma-cells: Number of cell for each DMA line, must be one.
+
+
+Example:
+
+ sdma: dma-controller@4800 {
+ compatible = ti,sdma-omap4
+ reg =0x4800 0x1000;
+ interrupts =12;
+dma-controller;
+ #dma-cells =1;
+ };
+
+
+
+* DMA client
+
+Client drivers should specify the DMA request numbers using a phandle to
+the controller + the DMA request number on that controller.
+
+Required properties:
+- dma-request: List of pair phandle + dma-request per line
+- dma-request-names: list of strings in the same order as the dma-request
+ in the dma-request property.
+
+
+Example:
+
+i2c1: i2c@1 {
+...
+dma-request =sdma 2sdma 3;
+dma-request-names = tx, rx;
+...
+};
diff --git a/drivers/of/Kconfig b/drivers/of/Kconfig
index 268163d..7d1f06b 100644
--- a/drivers/of/Kconfig
+++ b/drivers/of/Kconfig
@@ -90,4 +90,9 @@ config OF_PCI_IRQ
help
OpenFirmware PCI IRQ routing helpers
+config OF_DMA
+ def_bool y
+ help
+ Device Tree DMA routing helpers
+
endmenu # OF
diff --git a/drivers/of/Makefile b/drivers/of/Makefile
index a73f5a5..d08443b 100644
--- a/drivers/of/Makefile
+++ b/drivers/of/Makefile
@@ -12,3 +12,4 @@ obj-$(CONFIG_OF_SELFTEST) += selftest.o
obj-$(CONFIG_OF_MDIO) += of_mdio.o
obj-$(CONFIG_OF_PCI) += of_pci.o
obj-$(CONFIG_OF_PCI_IRQ) += of_pci_irq.o
+obj-$(CONFIG_OF_DMA) += dma.o
diff --git a/drivers/of/dma.c b/drivers/of/dma.c
new file mode 100644
index 000..d4927e2
--- /dev/null
+++ b/drivers/of/dma.c
@@ -0,0 +1,130 @@
+/*
+ * Device tree helpers for DMA request / controller
+ *
+ * Based on of_gpio.c
+ *
+ * Copyright (C) 2012 Texas Instruments Incorporated - http://www.ti.com/
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#includelinux/device.h
+#includelinux/err.h
+#includelinux/module.h
+#includelinux/of.h
+#includelinux/of_dma.h
+
+/**
+ * of_get_dma_request() - Get a DMA request number and dma-controller node
+ * @np:device node to get DMA request from
+ * @propname: property name containing DMA specifier(s)
+ * @index: index of the DMA request
+ * @ctrl_np: a device_node pointer to fill in
+ *
+ * Returns DMA number along to the dma controller node, or one of the errno
+ * value on the error condition. If @ctrl_np is not NULL the function also
+ * fills in the DMA
Re: [PATCH] dwc3: linux/module.h included twice
Hi, On Wed, Feb 15, 2012 at 06:55:51PM +0100, Danny Kukawka wrote: drivers/usb/dwc3/core.c and drivers/usb/dwc3/dwc3-omap.c included 'linux/module.h' twice, remove the duplicates. Signed-off-by: Danny Kukawka danny.kuka...@bisect.de applied, thanks -- balbi signature.asc Description: Digital signature
Re: help: BeagleBoard xM RevC ethernet port
On 22/02/12 22:00, Kevin Hilman wrote:
Peter Ujfalusi peter.ujfal...@ti.com writes:
Hi,
I hoped that time will solve this, but so far no luck. I just can not
get the ethernet port (along with the USB host ports) working on my xM RevC.
What is the trick to get it working on 3.3-rc3?
There seams to be some configuration issue:
[1.437530] ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver
[1.444671] ehci_hcd: block sizes: qh 64 qtd 96 itd 160 sitd 96
[1.451354] ehci-omap ehci-omap.0: failed to get ehci port0 regulator
[1.458282] ehci-omap ehci-omap.0: failed to get ehci port1 regulator
The first thing I try when I see these regulator failures is to add
CONFIG_REGULATOR_DUMMY=y to the .config to see if that helps. If so,
then the board file needs some help configuring the right regulators.
Kevin
--
Apologies for the malformed patch, but I don't have time to clean it up
this morning (or test it in its cleaned state); however, the following
fixes the problem for me.
It used to be masked because u-boot turns the regulator on to activate
ethernet on Beagle xM and no-one ever turns it off again, but some versions
of u-boot don't identify xM rev C correctly, so never turn it on ..
Anyway, it's neater for the kernel to know what it's doing. And removes
a whole two lines of kernel startup output :-)
Richard.
---
commit 39d26ad563023ac06e8aaaf154378c373187
Author: Richard Watts r...@kynesim.co.uk
Date: Fri Jan 20 12:27:59 2012 +
Turn on the USB regulator on Beagle xM explicitly, when the USB
subsystem asks for it, rather than relying on u-boot to do it.
diff --git a/arch/arm/mach-omap2/board-omap3beagle.c
b/arch/arm/mach-omap2/board-omap3beagle.c
index 4a71cb7..69ed6a0 100644
--- a/arch/arm/mach-omap2/board-omap3beagle.c
+++ b/arch/arm/mach-omap2/board-omap3beagle.c
@@ -362,11 +362,32 @@ static struct regulator_init_data beagle_vsim = {
.consumer_supplies = beagle_vsim_supply,
};
+static struct regulator_consumer_supply beagle_usb_supply[] = {
+REGULATOR_SUPPLY(hsusb0, ehci-omap.0),
+REGULATOR_SUPPLY(hsusb1, ehci-omap.0)
+};
+
+static struct regulator_init_data usb_power = {
+.constraints = {
+.min_uV = 180,
+.max_uV = 180,
+.valid_modes_mask = REGULATOR_MODE_NORMAL,
+.valid_ops_mask = REGULATOR_CHANGE_VOLTAGE
+| REGULATOR_CHANGE_MODE
+| REGULATOR_CHANGE_STATUS,
+},
+.num_consumer_supplies = ARRAY_SIZE(beagle_usb_supply),
+.consumer_supplies = beagle_usb_supply
+};
+
+
+
static struct twl4030_platform_data beagle_twldata = {
/* platform_data for children goes here */
.gpio = beagle_gpio_data,
.vmmc1 = beagle_vmmc1,
.vsim = beagle_vsim,
+.vaux2 = usb_power,
};
static struct i2c_board_info __initdata beagle_i2c_eeprom[] =
--
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] regulator: twl6030: add support for vdd1, vdd2 and vdd3 regulators
vdd1 and vdd2 are now common regulators for twl4030 and twl6030. Also
added vdd3 as a new regulator for twl6030. twl6030 vdd1...vdd3 smps
regulator voltages can only be controlled through the smartreflex
voltage channel, thus the support for the voltage_get and set is
minimal and requires external controller.
Signed-off-by: Tero Kristo t-kri...@ti.com
Cc: Mark Brown broo...@opensource.wolfsonmicro.com
Cc: Liam Girdwood l...@ti.com
Cc: Samuel Ortiz sa...@linux.intel.com
Cc: Kevin Hilman khil...@ti.com
---
drivers/mfd/twl-core.c| 15 ++
drivers/regulator/twl-regulator.c | 39 +
include/linux/i2c/twl.h |5 ++-
3 files changed, 57 insertions(+), 2 deletions(-)
diff --git a/drivers/mfd/twl-core.c b/drivers/mfd/twl-core.c
index fae5f76..c788e36 100644
--- a/drivers/mfd/twl-core.c
+++ b/drivers/mfd/twl-core.c
@@ -949,6 +949,21 @@ add_children(struct twl4030_platform_data *pdata, unsigned
long features)
/* twl6030 regulators */
if (twl_has_regulator() twl_class_is_6030()
!(features TWL6025_SUBCLASS)) {
+ child = add_regulator(TWL6030_REG_VDD1, pdata-vdd1,
+ features);
+ if (IS_ERR(child))
+ return PTR_ERR(child);
+
+ child = add_regulator(TWL6030_REG_VDD2, pdata-vdd2,
+ features);
+ if (IS_ERR(child))
+ return PTR_ERR(child);
+
+ child = add_regulator(TWL6030_REG_VDD3, pdata-vdd3,
+ features);
+ if (IS_ERR(child))
+ return PTR_ERR(child);
+
child = add_regulator(TWL6030_REG_VMMC, pdata-vmmc,
features);
if (IS_ERR(child))
diff --git a/drivers/regulator/twl-regulator.c
b/drivers/regulator/twl-regulator.c
index 0afc9e1a..55a0e4d 100644
--- a/drivers/regulator/twl-regulator.c
+++ b/drivers/regulator/twl-regulator.c
@@ -561,6 +561,32 @@ static struct regulator_ops twl4030smps_ops = {
.get_voltage= twl4030smps_get_voltage,
};
+static int twl6030coresmps_set_voltage(struct regulator_dev *rdev, int min_uV,
+ int max_uV, unsigned *selector)
+{
+ struct twlreg_info *info = rdev_get_drvdata(rdev);
+
+ if (info-set_voltage)
+ return info-set_voltage(info-data, min_uV);
+
+ return 0;
+}
+
+static int twl6030coresmps_get_voltage(struct regulator_dev *rdev)
+{
+ struct twlreg_info *info = rdev_get_drvdata(rdev);
+
+ if (info-get_voltage)
+ return info-get_voltage(info-data);
+
+ return 0;
+}
+
+static struct regulator_ops twl6030coresmps_ops = {
+ .set_voltage= twl6030coresmps_set_voltage,
+ .get_voltage= twl6030coresmps_get_voltage,
+};
+
static int twl6030ldo_list_voltage(struct regulator_dev *rdev, unsigned index)
{
struct twlreg_info *info = rdev_get_drvdata(rdev);
@@ -918,6 +944,16 @@ static struct regulator_ops twlsmps_ops = {
}, \
}
+#define TWL6030_ADJUSTABLE_SMPS(label) { \
+ .desc = { \
+ .name = #label, \
+ .id = TWL6030_REG_##label, \
+ .ops = twl6030coresmps_ops, \
+ .type = REGULATOR_VOLTAGE, \
+ .owner = THIS_MODULE, \
+ }, \
+ }
+
#define TWL6030_ADJUSTABLE_LDO(label, offset, min_mVolts, max_mVolts) { \
.base = offset, \
.min_mV = min_mVolts, \
@@ -1019,6 +1055,9 @@ static struct twlreg_info twl_regs[] = {
/* 6030 REG with base as PMC Slave Misc : 0x0030 */
/* Turnon-delay and remap configuration values for 6030 are not
verified since the specification is not public */
+ TWL6030_ADJUSTABLE_SMPS(VDD1),
+ TWL6030_ADJUSTABLE_SMPS(VDD2),
+ TWL6030_ADJUSTABLE_SMPS(VDD3),
TWL6030_ADJUSTABLE_LDO(VAUX1_6030, 0x54, 1000, 3300),
TWL6030_ADJUSTABLE_LDO(VAUX2_6030, 0x58, 1000, 3300),
TWL6030_ADJUSTABLE_LDO(VAUX3_6030, 0x5c, 1000, 3300),
diff --git a/include/linux/i2c/twl.h b/include/linux/i2c/twl.h
index 08a82d3..f66c031 100644
--- a/include/linux/i2c/twl.h
+++ b/include/linux/i2c/twl.h
@@ -712,6 +712,9 @@ struct twl4030_platform_data {
struct regulator_init_data *vaux1;
struct regulator_init_data *vaux2;
struct regulator_init_data *vaux3;
+ struct regulator_init_data *vdd1;
+ struct regulator_init_data *vdd2;
+ struct regulator_init_data *vdd3;
/* TWL4030 LDO regulators */
struct regulator_init_data *vpll1;
struct regulator_init_data *vpll2;
@@ -720,8 +723,6 @@ struct twl4030_platform_data {
struct regulator_init_data *vsim;
struct regulator_init_data
Re: [RFC v4 PATCH 0/4] dt: device tree support for TI EMIF driver
On Saturday 04 February 2012 06:12 PM, Aneesh V wrote: This series adds device tree support for TI EMIF SDRAM controller driver. For this, a binding has been added for representing AC timing parameters and other details of LPDDR2 memories. Ping! Any comments on this series? br, Aneesh -- 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 6/6] mmc: omap_hsmmc: Don't expect MMC1 to always have vmmc supply
MMC1 is not the only instance that can be used/wired for SD.
So remove this assumption from the driver.
Now that all the mmc id based usage is removed, get rid
of all the DEVID defines and also the 'id' field from the
omap_hsmmc_host structure.
Signed-off-by: Rajendra Nayak rna...@ti.com
Tested-by: Venkatraman S svenk...@ti.com
Tested-by: Balaji T K balaj...@ti.com
---
drivers/mmc/host/omap_hsmmc.c | 31 ++-
1 files changed, 2 insertions(+), 29 deletions(-)
diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
index 17e264b..e3eb9d4 100644
--- a/drivers/mmc/host/omap_hsmmc.c
+++ b/drivers/mmc/host/omap_hsmmc.c
@@ -106,17 +106,6 @@
#define SOFTRESET (1 1)
#define RESETDONE (1 0)
-/*
- * FIXME: Most likely all the data using these _DEVID defines should come
- * from the platform_data, or implemented in controller and slot specific
- * functions.
- */
-#define OMAP_MMC1_DEVID0
-#define OMAP_MMC2_DEVID1
-#define OMAP_MMC3_DEVID2
-#define OMAP_MMC4_DEVID3
-#define OMAP_MMC5_DEVID4
-
#define MMC_AUTOSUSPEND_DELAY 100
#define MMC_TIMEOUT_MS 20
#define OMAP_MMC_MIN_CLOCK 40
@@ -164,7 +153,6 @@ struct omap_hsmmc_host {
void__iomem *base;
resource_size_t mapbase;
spinlock_t irq_lock; /* Prevent races with irq handler */
- unsigned intid;
unsigned intdma_len;
unsigned intdma_sg_idx;
unsigned char bus_mode;
@@ -300,7 +288,6 @@ static int omap_hsmmc_set_power(struct device *dev, int
slot, int power_on,
static int omap_hsmmc_reg_get(struct omap_hsmmc_host *host)
{
struct regulator *reg;
- int ret = 0;
int ocr_value = 0;
mmc_slot(host).set_power = omap_hsmmc_set_power;
@@ -308,15 +295,6 @@ static int omap_hsmmc_reg_get(struct omap_hsmmc_host *host)
reg = regulator_get(host-dev, vmmc);
if (IS_ERR(reg)) {
dev_dbg(host-dev, vmmc regulator missing\n);
- /*
- * HACK: until fixed.c regulator is usable,
- * we don't require a main regulator
- * for MMC2 or MMC3
- */
- if (host-id == OMAP_MMC1_DEVID) {
- ret = PTR_ERR(reg);
- goto err;
- }
} else {
host-vcc = reg;
ocr_value = mmc_regulator_get_ocrmask(reg);
@@ -324,8 +302,8 @@ static int omap_hsmmc_reg_get(struct omap_hsmmc_host *host)
mmc_slot(host).ocr_mask = ocr_value;
} else {
if (!(mmc_slot(host).ocr_mask ocr_value)) {
- pr_err(MMC%d ocrmask %x is not supported\n,
- host-id, mmc_slot(host).ocr_mask);
+ pr_err(MMC ocrmask %x is not supported\n,
+ mmc_slot(host).ocr_mask);
mmc_slot(host).ocr_mask = 0;
return -EINVAL;
}
@@ -358,10 +336,6 @@ static int omap_hsmmc_reg_get(struct omap_hsmmc_host *host)
}
return 0;
-
-err:
- mmc_slot(host).set_power = NULL;
- return ret;
}
static void omap_hsmmc_reg_put(struct omap_hsmmc_host *host)
@@ -1791,7 +1765,6 @@ static int __init omap_hsmmc_probe(struct platform_device
*pdev)
host-dev-dma_mask = pdata-dma_mask;
host-dma_ch= -1;
host-irq = irq;
- host-id= pdev-id;
host-slot_id = 0;
host-mapbase = res-start;
host-base = ioremap(host-mapbase, SZ_4K);
--
1.7.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
[PATCH v2 2/6] mmc: omap_hsmmc: remove unused .set_sleep function
From: Balaji T K balaj...@ti.com
set_sleep seems to be unused in omap_hsmmc driver. so get rid of it.
Signed-off-by: Balaji T K balaj...@ti.com
Signed-off-by: Rajendra Nayak rna...@ti.com
Tested-by: Venkatraman S svenk...@ti.com
---
arch/arm/plat-omap/include/plat/mmc.h |2 -
drivers/mmc/host/omap_hsmmc.c | 60 -
2 files changed, 0 insertions(+), 62 deletions(-)
diff --git a/arch/arm/plat-omap/include/plat/mmc.h
b/arch/arm/plat-omap/include/plat/mmc.h
index f75946c..7a38750 100644
--- a/arch/arm/plat-omap/include/plat/mmc.h
+++ b/arch/arm/plat-omap/include/plat/mmc.h
@@ -137,8 +137,6 @@ struct omap_mmc_platform_data {
int (*set_power)(struct device *dev, int slot,
int power_on, int vdd);
int (*get_ro)(struct device *dev, int slot);
- int (*set_sleep)(struct device *dev, int slot, int sleep,
-int vdd, int cardsleep);
void (*remux)(struct device *dev, int slot, int power_on);
/* Call back before enabling / disabling regulators */
void (*before_set_reg)(struct device *dev, int slot,
diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
index 2a660ab..9955aee 100644
--- a/drivers/mmc/host/omap_hsmmc.c
+++ b/drivers/mmc/host/omap_hsmmc.c
@@ -324,61 +324,6 @@ static int omap_hsmmc_4_set_power(struct device *dev, int
slot, int power_on,
return 0;
}
-static int omap_hsmmc_1_set_sleep(struct device *dev, int slot, int sleep,
- int vdd, int cardsleep)
-{
- struct omap_hsmmc_host *host =
- platform_get_drvdata(to_platform_device(dev));
- int mode = sleep ? REGULATOR_MODE_STANDBY : REGULATOR_MODE_NORMAL;
-
- return regulator_set_mode(host-vcc, mode);
-}
-
-static int omap_hsmmc_235_set_sleep(struct device *dev, int slot, int sleep,
- int vdd, int cardsleep)
-{
- struct omap_hsmmc_host *host =
- platform_get_drvdata(to_platform_device(dev));
- int err, mode;
-
- /*
-* If we don't see a Vcc regulator, assume it's a fixed
-* voltage always-on regulator.
-*/
- if (!host-vcc)
- return 0;
-
- mode = sleep ? REGULATOR_MODE_STANDBY : REGULATOR_MODE_NORMAL;
-
- if (!host-vcc_aux)
- return regulator_set_mode(host-vcc, mode);
-
- if (cardsleep) {
- /* VCC can be turned off if card is asleep */
- if (sleep)
- err = mmc_regulator_set_ocr(host-mmc, host-vcc, 0);
- else
- err = mmc_regulator_set_ocr(host-mmc, host-vcc, vdd);
- } else
- err = regulator_set_mode(host-vcc, mode);
- if (err)
- return err;
-
- if (!mmc_slot(host).vcc_aux_disable_is_sleep)
- return regulator_set_mode(host-vcc_aux, mode);
-
- if (sleep)
- return regulator_disable(host-vcc_aux);
- else
- return regulator_enable(host-vcc_aux);
-}
-
-static int omap_hsmmc_4_set_sleep(struct device *dev, int slot, int sleep,
- int vdd, int cardsleep)
-{
- return 0;
-}
-
static int omap_hsmmc_reg_get(struct omap_hsmmc_host *host)
{
struct regulator *reg;
@@ -389,18 +334,15 @@ static int omap_hsmmc_reg_get(struct omap_hsmmc_host
*host)
case OMAP_MMC1_DEVID:
/* On-chip level shifting via PBIAS0/PBIAS1 */
mmc_slot(host).set_power = omap_hsmmc_1_set_power;
- mmc_slot(host).set_sleep = omap_hsmmc_1_set_sleep;
break;
case OMAP_MMC2_DEVID:
case OMAP_MMC3_DEVID:
case OMAP_MMC5_DEVID:
/* Off-chip level shifting, or none */
mmc_slot(host).set_power = omap_hsmmc_235_set_power;
- mmc_slot(host).set_sleep = omap_hsmmc_235_set_sleep;
break;
case OMAP_MMC4_DEVID:
mmc_slot(host).set_power = omap_hsmmc_4_set_power;
- mmc_slot(host).set_sleep = omap_hsmmc_4_set_sleep;
default:
pr_err(MMC%d configuration not supported!\n, host-id);
return -EINVAL;
@@ -462,7 +404,6 @@ static int omap_hsmmc_reg_get(struct omap_hsmmc_host *host)
err:
mmc_slot(host).set_power = NULL;
- mmc_slot(host).set_sleep = NULL;
return ret;
}
@@ -471,7 +412,6 @@ static void omap_hsmmc_reg_put(struct omap_hsmmc_host *host)
regulator_put(host-vcc);
regulator_put(host-vcc_aux);
mmc_slot(host).set_power = NULL;
- mmc_slot(host).set_sleep = NULL;
}
static inline int omap_hsmmc_have_reg(void)
--
1.7.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
[PATCH v2 4/6] mmc: omap_hsmmc: Get rid of omap_hsmmc_1_set_power function
Use omap_hsmmc_235_set_poweri() (now renamed as omap_hsmmc_set_power())
for MMC1 instance as well and get rid of omap_hsmmc_1_set_power()
completely.
omap_hsmmc_235_set_power() seems to implemented as a superset of
omap_hsmmc_1_set_power() with additonal functionality implemented
based on additional checks and hence should just work for MMC1
as well.
Signed-off-by: Rajendra Nayak rna...@ti.com
Tested-by: Venkatraman S svenk...@ti.com
Tested-by: Balaji T K balaj...@ti.com
---
drivers/mmc/host/omap_hsmmc.c | 30 +++---
1 files changed, 3 insertions(+), 27 deletions(-)
diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
index 91faf42..f98c599 100644
--- a/drivers/mmc/host/omap_hsmmc.c
+++ b/drivers/mmc/host/omap_hsmmc.c
@@ -241,28 +241,7 @@ static int omap_hsmmc_resume_cdirq(struct device *dev, int
slot)
#ifdef CONFIG_REGULATOR
-static int omap_hsmmc_1_set_power(struct device *dev, int slot, int power_on,
- int vdd)
-{
- struct omap_hsmmc_host *host =
- platform_get_drvdata(to_platform_device(dev));
- int ret;
-
- if (mmc_slot(host).before_set_reg)
- mmc_slot(host).before_set_reg(dev, slot, power_on, vdd);
-
- if (power_on)
- ret = mmc_regulator_set_ocr(host-mmc, host-vcc, vdd);
- else
- ret = mmc_regulator_set_ocr(host-mmc, host-vcc, 0);
-
- if (mmc_slot(host).after_set_reg)
- mmc_slot(host).after_set_reg(dev, slot, power_on, vdd);
-
- return ret;
-}
-
-static int omap_hsmmc_235_set_power(struct device *dev, int slot, int power_on,
+static int omap_hsmmc_set_power(struct device *dev, int slot, int power_on,
int vdd)
{
struct omap_hsmmc_host *host =
@@ -332,14 +311,11 @@ static int omap_hsmmc_reg_get(struct omap_hsmmc_host
*host)
switch (host-id) {
case OMAP_MMC1_DEVID:
- /* On-chip level shifting via PBIAS0/PBIAS1 */
- mmc_slot(host).set_power = omap_hsmmc_1_set_power;
- break;
case OMAP_MMC2_DEVID:
case OMAP_MMC3_DEVID:
case OMAP_MMC5_DEVID:
- /* Off-chip level shifting, or none */
- mmc_slot(host).set_power = omap_hsmmc_235_set_power;
+ /* On-chip level shifting via PBIAS0/PBIAS1 */
+ mmc_slot(host).set_power = omap_hsmmc_set_power;
break;
case OMAP_MMC4_DEVID:
mmc_slot(host).set_power = omap_hsmmc_4_set_power;
--
1.7.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
[PATCH v2 0/6] mmc: omap_hsmmc: Clean up use/abuse of pdev-id
Re-sending as these patches did not make it to the lists due to issues with my 'git send-email' This series mainly cleans up all instances of hardcoding's in the driver based on pdev-id. This is cleanup leading to the DT adaptation of omap_hsmmc driver. v2 mainly has some minor changes to get rid of a debug print which was still using host-id and getting rid of 'id' field entirely from omap_hsmmc_host struct. The series is tested on OMAP4SDP, OMAP4panda, OMAP3beagle and OMAP2430SDP boards. regards, Rajendra Balaji T K (3): mmc: omap_hsmmc: use platform_get_resource_byname for tx/rx DMA channels mmc: omap_hsmmc: remove unused .set_sleep function mmc: omap_hsmmc: Use OMAP_HSMMC_SUPPORTS_DUAL_VOLT flag to remove host-id based hardcoding Rajendra Nayak (3): mmc: omap_hsmmc: Get rid of omap_hsmmc_1_set_power function mmc: omap_hsmmc: Get rid of omap_hsmmc_4_set_power function mmc: omap_hsmmc: Don't expect MMC1 to always have vmmc supply arch/arm/plat-omap/include/plat/mmc.h |2 - drivers/mmc/host/omap_hsmmc.c | 175 +++-- 2 files changed, 16 insertions(+), 161 deletions(-) -- 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 1/6] mmc: omap_hsmmc: use platform_get_resource_byname for tx/rx DMA channels
From: Balaji T K balaj...@ti.com
Git rid of hardcoded tx/rx DMA channels based on pdev-id
and use platform_get_resource_byname() to retrieve them
instead.
Signed-off-by: Balaji T K balaj...@ti.com
Signed-off-by: Rajendra Nayak rna...@ti.com
Tested-by: Venkatraman S svenk...@ti.com
---
drivers/mmc/host/omap_hsmmc.c | 35 +++
1 files changed, 11 insertions(+), 24 deletions(-)
diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
index fd0c661..2a660ab 100644
--- a/drivers/mmc/host/omap_hsmmc.c
+++ b/drivers/mmc/host/omap_hsmmc.c
@@ -1977,32 +1977,19 @@ static int __init omap_hsmmc_probe(struct
platform_device *pdev)
omap_hsmmc_conf_bus_power(host);
- /* Select DMA lines */
- switch (host-id) {
- case OMAP_MMC1_DEVID:
- host-dma_line_tx = OMAP24XX_DMA_MMC1_TX;
- host-dma_line_rx = OMAP24XX_DMA_MMC1_RX;
- break;
- case OMAP_MMC2_DEVID:
- host-dma_line_tx = OMAP24XX_DMA_MMC2_TX;
- host-dma_line_rx = OMAP24XX_DMA_MMC2_RX;
- break;
- case OMAP_MMC3_DEVID:
- host-dma_line_tx = OMAP34XX_DMA_MMC3_TX;
- host-dma_line_rx = OMAP34XX_DMA_MMC3_RX;
- break;
- case OMAP_MMC4_DEVID:
- host-dma_line_tx = OMAP44XX_DMA_MMC4_TX;
- host-dma_line_rx = OMAP44XX_DMA_MMC4_RX;
- break;
- case OMAP_MMC5_DEVID:
- host-dma_line_tx = OMAP44XX_DMA_MMC5_TX;
- host-dma_line_rx = OMAP44XX_DMA_MMC5_RX;
- break;
- default:
- dev_err(mmc_dev(host-mmc), Invalid MMC id\n);
+ res = platform_get_resource_byname(pdev, IORESOURCE_DMA, tx);
+ if (!res) {
+ dev_err(mmc_dev(host-mmc), cannot get DMA TX channel\n);
+ goto err_irq;
+ }
+ host-dma_line_tx = res-start;
+
+ res = platform_get_resource_byname(pdev, IORESOURCE_DMA, rx);
+ if (!res) {
+ dev_err(mmc_dev(host-mmc), cannot get DMA RX channel\n);
goto err_irq;
}
+ host-dma_line_rx = res-start;
/* Request IRQ for MMC operations */
ret = request_irq(host-irq, omap_hsmmc_irq, 0,
--
1.7.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
[PATCH v2 5/6] mmc: omap_hsmmc: Get rid of omap_hsmmc_4_set_power function
Now that omap_hsmmc_set_power() already has a check to return 0
if !host-vcc, it seems like it can be used even on MMC4 instead
of the dummy omap_hsmmc_4_set_power().
This also helps get rid of all the host-id based check to
populate the right function for on-chip/external level
shifting and use omap_hsmmc_set_power() for all MMC modules.
Signed-off-by: Rajendra Nayak rna...@ti.com
Tested-by: Venkatraman S svenk...@ti.com
Tested-by: Balaji T K balaj...@ti.com
---
drivers/mmc/host/omap_hsmmc.c | 21 +
1 files changed, 1 insertions(+), 20 deletions(-)
diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
index f98c599..17e264b 100644
--- a/drivers/mmc/host/omap_hsmmc.c
+++ b/drivers/mmc/host/omap_hsmmc.c
@@ -297,32 +297,13 @@ static int omap_hsmmc_set_power(struct device *dev, int
slot, int power_on,
return ret;
}
-static int omap_hsmmc_4_set_power(struct device *dev, int slot, int power_on,
- int vdd)
-{
- return 0;
-}
-
static int omap_hsmmc_reg_get(struct omap_hsmmc_host *host)
{
struct regulator *reg;
int ret = 0;
int ocr_value = 0;
- switch (host-id) {
- case OMAP_MMC1_DEVID:
- case OMAP_MMC2_DEVID:
- case OMAP_MMC3_DEVID:
- case OMAP_MMC5_DEVID:
- /* On-chip level shifting via PBIAS0/PBIAS1 */
- mmc_slot(host).set_power = omap_hsmmc_set_power;
- break;
- case OMAP_MMC4_DEVID:
- mmc_slot(host).set_power = omap_hsmmc_4_set_power;
- default:
- pr_err(MMC%d configuration not supported!\n, host-id);
- return -EINVAL;
- }
+ mmc_slot(host).set_power = omap_hsmmc_set_power;
reg = regulator_get(host-dev, vmmc);
if (IS_ERR(reg)) {
--
1.7.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
[PATCH v2 3/6] mmc: omap_hsmmc: Use OMAP_HSMMC_SUPPORTS_DUAL_VOLT flag to remove host-id based hardcoding
From: Balaji T K balaj...@ti.com
Use OMAP_HSMMC_SUPPORTS_DUAL_VOLT flag instead of host-id
for identifying SD bus voltage capabilities.
Signed-off-by: Balaji T K balaj...@ti.com
Signed-off-by: Rajendra Nayak rna...@ti.com
Tested-by: Venkatraman S svenk...@ti.com
---
drivers/mmc/host/omap_hsmmc.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
index 9955aee..91faf42 100644
--- a/drivers/mmc/host/omap_hsmmc.c
+++ b/drivers/mmc/host/omap_hsmmc.c
@@ -650,7 +650,7 @@ static int omap_hsmmc_context_restore(struct
omap_hsmmc_host *host)
OMAP_HSMMC_WRITE(host-base, SYSCONFIG,
OMAP_HSMMC_READ(host-base, SYSCONFIG) | AUTOIDLE);
- if (host-id == OMAP_MMC1_DEVID) {
+ if (host-pdata-controller_flags OMAP_HSMMC_SUPPORTS_DUAL_VOLT) {
if (host-power_mode != MMC_POWER_OFF
(1 ios-vdd) = MMC_VDD_23_24)
hctl = SDVS18;
--
1.7.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
[PATCH] mmc: omap_hsmmc: convert all pr_* to dev_*
Convert all instances of pr_* prints within the driver
to instead use dev_* prints.
Reported-by: Russell King rmk+ker...@arm.linux.org.uk
Signed-off-by: Rajendra Nayak rna...@ti.com
---
Re-sending as this patch did not make it to the lists due to
issues with my 'git send-email'
drivers/mmc/host/omap_hsmmc.c |8
1 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
index e3eb9d4..35f6dc1 100644
--- a/drivers/mmc/host/omap_hsmmc.c
+++ b/drivers/mmc/host/omap_hsmmc.c
@@ -302,7 +302,7 @@ static int omap_hsmmc_reg_get(struct omap_hsmmc_host *host)
mmc_slot(host).ocr_mask = ocr_value;
} else {
if (!(mmc_slot(host).ocr_mask ocr_value)) {
- pr_err(MMC ocrmask %x is not supported\n,
+ dev_err(host-dev, ocrmask %x is not
supported\n,
mmc_slot(host).ocr_mask);
mmc_slot(host).ocr_mask = 0;
return -EINVAL;
@@ -1132,14 +1132,14 @@ static void omap_hsmmc_protect_card(struct
omap_hsmmc_host *host)
host-reqs_blocked = 0;
if (mmc_slot(host).get_cover_state(host-dev, host-slot_id)) {
if (host-protect_card) {
- pr_info(%s: cover is closed,
+ dev_info(host-dev, %s: cover is closed,
card is now accessible\n,
mmc_hostname(host-mmc));
host-protect_card = 0;
}
} else {
if (!host-protect_card) {
- pr_info(%s: cover is open,
+ dev_info(host-dev, %s: cover is open,
card is now inaccessible\n,
mmc_hostname(host-mmc));
host-protect_card = 1;
@@ -1276,7 +1276,7 @@ static int omap_hsmmc_pre_dma_transfer(struct
omap_hsmmc_host *host,
if (!next data-host_cookie
data-host_cookie != host-next_data.cookie) {
- pr_warning([%s] invalid cookie: data-host_cookie %d
+ dev_warn(host-dev, [%s] invalid cookie: data-host_cookie %d
host-next_data.cookie %d\n,
__func__, data-host_cookie, host-next_data.cookie);
data-host_cookie = 0;
--
1.7.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
[PATCH v3 2/2] arm/dts: twl: Pass regulator data from dt
Pass all the voltage regulator information for
twl6030/twl4030 PMIC from device tree.
Signed-off-by: Rajendra Nayak rna...@ti.com
Signed-off-by: Benoit Cousson b-cous...@ti.com
---
arch/arm/boot/dts/omap3-beagle.dts |6 +++
arch/arm/boot/dts/twl4030.dtsi | 18 +++
arch/arm/boot/dts/twl6030.dtsi | 60
3 files changed, 84 insertions(+), 0 deletions(-)
diff --git a/arch/arm/boot/dts/omap3-beagle.dts
b/arch/arm/boot/dts/omap3-beagle.dts
index 714ba5d..54556b1 100644
--- a/arch/arm/boot/dts/omap3-beagle.dts
+++ b/arch/arm/boot/dts/omap3-beagle.dts
@@ -26,6 +26,12 @@
reg = 0x48;
interrupts = 7; /* SYS_NIRQ cascaded to intc */
interrupt-parent = intc;
+
+ vsim: regulator@10 {
+ compatible = ti,twl4030-vsim;
+ regulator-min-microvolt = 180;
+ regulator-max-microvolt = 300;
+ };
};
};
diff --git a/arch/arm/boot/dts/twl4030.dtsi b/arch/arm/boot/dts/twl4030.dtsi
index 8be5223..a94654c 100644
--- a/arch/arm/boot/dts/twl4030.dtsi
+++ b/arch/arm/boot/dts/twl4030.dtsi
@@ -18,4 +18,22 @@
compatible = ti,twl4030-rtc;
interrupts = 11;
};
+
+ vdac: regulator@0 {
+ compatible = ti,twl4030-vdac;
+ regulator-min-microvolt = 180;
+ regulator-max-microvolt = 180;
+ };
+
+ vpll2: regulator@1 {
+ compatible = ti,twl4030-vpll2;
+ regulator-min-microvolt = 180;
+ regulator-max-microvolt = 180;
+ };
+
+ vmmc1: regulator@2 {
+ compatible = ti,twl4030-vmmc1;
+ regulator-min-microvolt = 185;
+ regulator-max-microvolt = 315;
+ };
};
diff --git a/arch/arm/boot/dts/twl6030.dtsi b/arch/arm/boot/dts/twl6030.dtsi
index b7b4e5e..efa19e8 100644
--- a/arch/arm/boot/dts/twl6030.dtsi
+++ b/arch/arm/boot/dts/twl6030.dtsi
@@ -19,4 +19,64 @@
compatible = ti,twl4030-rtc;
interrupts = 11;
};
+
+ vaux1: regulator@0 {
+ compatible = ti,twl6030-vaux1;
+ regulator-min-microvolt = 100;
+ regulator-max-microvolt = 300;
+ };
+
+ vaux2: regulator@1 {
+ compatible = ti,twl6030-vaux2;
+ regulator-min-microvolt = 120;
+ regulator-max-microvolt = 280;
+ };
+
+ vaux3: regulator@2 {
+ compatible = ti,twl6030-vaux3;
+ regulator-min-microvolt = 100;
+ regulator-max-microvolt = 300;
+ };
+
+ vmmc: regulator@3 {
+ compatible = ti,twl6030-vmmc;
+ regulator-min-microvolt = 120;
+ regulator-max-microvolt = 300;
+ };
+
+ vpp: regulator@4 {
+ compatible = ti,twl6030-vpp;
+ regulator-min-microvolt = 180;
+ regulator-max-microvolt = 250;
+ };
+
+ vusim: regulator@5 {
+ compatible = ti,twl6030-vusim;
+ regulator-min-microvolt = 120;
+ regulator-max-microvolt = 290;
+ };
+
+ vdac: regulator@6 {
+ compatible = ti,twl6030-vdac;
+ };
+
+ vana: regulator@7 {
+ compatible = ti,twl6030-vana;
+ };
+
+ vcxio: regulator@8 {
+ compatible = ti,twl6030-vcxio;
+ };
+
+ vusb: regulator@9 {
+ compatible = ti,twl6030-vusb;
+ };
+
+ vusb: regulator@9 {
+ compatible = ti,twl6030-vusb;
+ };
+
+ clk32kg: regulator@10 {
+ compatible = ti,twl6030-clk32kg;
+ };
};
--
1.7.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
[PATCH v3 0/2] Device tree support for TWL regulators
Re-sending as these patches did not make it to the lists due to
issues with my 'git send-email'
v3 has mainly 2 differences from v2
-1- TWL driver now uses just one table for both dt and
non-dt based lookup for driver data.
-2- All common regulator nodes for twl4030 and twl6030 are
now defined in the twl4030.dtsi and twl6030.dtsi instead of
repeating the nodes in all board files, which also means
the patch ('arm/dts: twl: Pass regulator data from dt')
has a dependency with the series from Benoit which adds the
twl4030.dtsi and twl6030.dtsi files[1].
I have tested the patches on omap4panda and omap3beagle boards.
[1] git://git.kernel.org/pub/scm/linux/kernel/git/bcousson/linux-omap-dt.git
for_3.4/dt_i2c_twl
Rajendra Nayak (2):
regulator: twl: adapt twl-regulator driver to dt
arm/dts: twl: Pass regulator data from dt
.../bindings/regulator/twl-regulator.txt | 63 ++
arch/arm/boot/dts/omap3-beagle.dts |6 +
arch/arm/boot/dts/twl4030.dtsi | 18 ++
arch/arm/boot/dts/twl6030.dtsi | 60 +
drivers/regulator/twl-regulator.c | 227 +---
5 files changed, 301 insertions(+), 73 deletions(-)
create mode 100644
Documentation/devicetree/bindings/regulator/twl-regulator.txt
--
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 v3 1/2] regulator: twl: adapt twl-regulator driver to dt
Modify the twl regulator driver to extract the regulator_init_data from
device tree when passed, instead of getting it through platform_data
structures (on non-DT builds)
Also add documentation for TWL regulator specific bindings.
Signed-off-by: Rajendra Nayak rna...@ti.com
---
.../bindings/regulator/twl-regulator.txt | 63 ++
drivers/regulator/twl-regulator.c | 227 +---
2 files changed, 217 insertions(+), 73 deletions(-)
create mode 100644
Documentation/devicetree/bindings/regulator/twl-regulator.txt
diff --git a/Documentation/devicetree/bindings/regulator/twl-regulator.txt
b/Documentation/devicetree/bindings/regulator/twl-regulator.txt
new file mode 100644
index 000..074e344
--- /dev/null
+++ b/Documentation/devicetree/bindings/regulator/twl-regulator.txt
@@ -0,0 +1,63 @@
+TWL family of regulators
+
+Required properties:
+For twl6030 regulators/LDOs
+- compatible:
+ - ti,twl6030-vaux1 for VAUX1 LDO
+ - ti,twl6030-vaux2 for VAUX2 LDO
+ - ti,twl6030-vaux3 for VAUX3 LDO
+ - ti,twl6030-vmmc for VMMC LDO
+ - ti,twl6030-vpp for VPP LDO
+ - ti,twl6030-vusim for VUSIM LDO
+ - ti,twl6030-vana for VANA LDO
+ - ti,twl6030-vcxio for VCXIO LDO
+ - ti,twl6030-vdac for VDAC LDO
+ - ti,twl6030-vusb for VUSB LDO
+ - ti,twl6030-clk32kg for CLK32KG LDO
+For twl6025 regulators/LDOs
+- compatible:
+ - ti,twl6025-ldo1 for LDO1 LDO
+ - ti,twl6025-ldo2 for LDO2 LDO
+ - ti,twl6025-ldo3 for LDO3 LDO
+ - ti,twl6025-ldo4 for LDO4 LDO
+ - ti,twl6025-ldo5 for LDO5 LDO
+ - ti,twl6025-ldo6 for LDO6 LDO
+ - ti,twl6025-ldo7 for LDO7 LDO
+ - ti,twl6025-ldoln for LDOLN LDO
+ - ti,twl6025-ldousb for LDOUSB LDO
+ - ti,twl6025-smps3 for SMPS3 LDO
+ - ti,twl6025-smps4 for SMPS4 LDO
+ - ti,twl6025-vio for VIO LDO
+For twl4030 regulators/LDOs
+- compatible:
+ - ti,twl4030-vaux1 for VAUX1 LDO
+ - ti,twl4030-vaux2 for VAUX2 LDO
+ - ti,twl5030-vaux2 for VAUX2 LDO
+ - ti,twl4030-vaux3 for VAUX3 LDO
+ - ti,twl4030-vaux4 for VAUX4 LDO
+ - ti,twl4030-vmmc1 for VMMC1 LDO
+ - ti,twl4030-vmmc2 for VMMC2 LDO
+ - ti,twl4030-vpll1 for VPLL1 LDO
+ - ti,twl4030-vpll2 for VPLL2 LDO
+ - ti,twl4030-vsim for VSIM LDO
+ - ti,twl4030-vdac for VDAC LDO
+ - ti,twl4030-vintana2 for VINTANA2 LDO
+ - ti,twl4030-vio for VIO LDO
+ - ti,twl4030-vdd1 for VDD1 LDO
+ - ti,twl4030-vdd2 for VDD2 LDO
+ - ti,twl4030-vintana1 for VINTANA1 LDO
+ - ti,twl4030-vintdig for VINTDIG LDO
+ - ti,twl4030-vusb1v5 for VUSB1V5 LDO
+ - ti,twl4030-vusb1v8 for VUSB1V8 LDO
+ - ti,twl4030-vusb3v1 for VUSB3V1 LDO
+
+Optional properties:
+- Any optional property defined in bindings/regulator/regulator.txt
+
+Example:
+
+ xyz: regulator@0 {
+ compatible = ti,twl6030-vaux1;
+ regulator-min-microvolt = 100;
+ regulator-max-microvolt = 300;
+ };
diff --git a/drivers/regulator/twl-regulator.c
b/drivers/regulator/twl-regulator.c
index 181a2cf..77808c7 100644
--- a/drivers/regulator/twl-regulator.c
+++ b/drivers/regulator/twl-regulator.c
@@ -14,8 +14,11 @@
#include linux/err.h
#include linux/delay.h
#include linux/platform_device.h
+#include linux/of.h
+#include linux/of_device.h
#include linux/regulator/driver.h
#include linux/regulator/machine.h
+#include linux/regulator/of_regulator.h
#include linux/i2c/twl.h
@@ -866,7 +869,8 @@ static struct regulator_ops twlsmps_ops = {
TWL_FIXED_LDO(label, offset, mVolts, 0x0, turnon_delay, \
0x0, TWL6030, twl6030fixed_ops)
-#define TWL4030_ADJUSTABLE_LDO(label, offset, num, turnon_delay, remap_conf) {
\
+#define TWL4030_ADJUSTABLE_LDO(label, offset, num, turnon_delay, remap_conf) \
+static struct twlreg_info TWL4030_INFO_##label = { \
.base = offset, \
.id = num, \
.table_len = ARRAY_SIZE(label##_VSEL_table), \
@@ -884,7 +888,7 @@ static struct regulator_ops twlsmps_ops = {
}
#define TWL4030_ADJUSTABLE_SMPS(label, offset, num, turnon_delay, remap_conf) \
- { \
+static struct twlreg_info TWL4030_INFO_##label = { \
.base = offset, \
.id = num, \
.delay = turnon_delay, \
@@ -898,7 +902,8 @@ static struct regulator_ops twlsmps_ops = {
}, \
}
-#define TWL6030_ADJUSTABLE_LDO(label, offset, min_mVolts, max_mVolts) { \
+#define TWL6030_ADJUSTABLE_LDO(label, offset, min_mVolts, max_mVolts) \
+static struct twlreg_info TWL6030_INFO_##label = { \
.base = offset, \
.min_mV = min_mVolts, \
.max_mV = max_mVolts, \
@@ -912,7 +917,8 @@ static struct regulator_ops twlsmps_ops = {
}, \
}
-#define TWL6025_ADJUSTABLE_LDO(label, offset, min_mVolts, max_mVolts) { \
+#define TWL6025_ADJUSTABLE_LDO(label, offset, min_mVolts, max_mVolts) \
+static struct twlreg_info TWL6025_INFO_##label = { \
.base = offset, \
.min_mV = min_mVolts, \
.max_mV = max_mVolts, \
@@ -927,7 +933,8 @@ static struct regulator_ops
[PATCH v2 0/7] omap hsmmc init cleanup and section warning fixes for v3.4 merge window
Re-sending as these patches did not make it to the lists due to
issues with my 'git send-email'
Hi Tony,
This is a re-spin of your series to fix up the section
mismatch warnings noted by Russell with omap2_hsmmc_init().
The previous series had an issue around multiple insmod/rmmod
of the twl4030 gpio driver when built as a module as reported
by Russell again.
There were 2 issues, one with gpio_requests failing as they were
never freed on the module unload/unbind. The other was with the
mmc devices being registered again. I have fixed both these issues
in this series, mainly by having a .teardown hook for twl4030 gpio
driver populated from all OMAP3 board files, which release all the
requested gpios and also unregister the mmc omap/platform device.
regards,
Rajendra
Ohad Ben-Cohen (1):
ARM: OMAP: omap_device: Expose omap_device_{alloc, delete, register}
Rajendra Nayak (4):
ARM: OMAP: omap_device: Add omap_device_unregister()
mmc: omap_hsmmc: Make the driver support hotpluggable devices
mmc: omap_hsmmc: If probe fails, give our error messages
ARM: OMAP3: Use .teardown of twl4030-gpio to clean board requests
Tony Lindgren (2):
ARM: OMAP2+: Split omap2_hsmmc_init() to properly support I2C GPIO
pins
ARM: OMAP2+: Mark omap_hsmmc_init and omap_mux related functions as
__init
arch/arm/mach-omap2/board-2430sdp.c |2 +-
arch/arm/mach-omap2/board-3430sdp.c | 22 +++-
arch/arm/mach-omap2/board-4430sdp.c |4 +-
arch/arm/mach-omap2/board-am3517evm.c |2 +-
arch/arm/mach-omap2/board-cm-t35.c| 18 +++-
arch/arm/mach-omap2/board-devkit8000.c| 17 +++-
arch/arm/mach-omap2/board-flash.c |2 +-
arch/arm/mach-omap2/board-igep0020.c | 25 -
arch/arm/mach-omap2/board-ldp.c | 11 ++-
arch/arm/mach-omap2/board-omap3beagle.c | 25 -
arch/arm/mach-omap2/board-omap3evm.c | 22 +++-
arch/arm/mach-omap2/board-omap3logic.c|2 +-
arch/arm/mach-omap2/board-omap3pandora.c | 22 +++-
arch/arm/mach-omap2/board-omap3stalker.c | 28 --
arch/arm/mach-omap2/board-omap3touchbook.c| 30 --
arch/arm/mach-omap2/board-omap4panda.c|6 +-
arch/arm/mach-omap2/board-overo.c | 13 +++-
arch/arm/mach-omap2/board-rm680.c |2 +-
arch/arm/mach-omap2/board-rx51-peripherals.c | 10 ++-
arch/arm/mach-omap2/board-zoom-peripherals.c | 18 +++-
arch/arm/mach-omap2/display.c |8 +-
arch/arm/mach-omap2/hsmmc.c | 130 +++--
arch/arm/mach-omap2/hsmmc.h | 17 +++-
arch/arm/mach-omap2/mux.c | 14 ++--
arch/arm/plat-omap/include/plat/omap_device.h |8 ++
arch/arm/plat-omap/omap_device.c | 33 ---
drivers/mmc/host/omap_hsmmc.c | 11 +-
27 files changed, 372 insertions(+), 130 deletions(-)
--
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 1/7] ARM: OMAP: omap_device: Expose omap_device_{alloc, delete, register}
From: Ohad Ben-Cohen o...@wizery.com
Expose omap_device_{alloc, delete, register} so we can use them outside
of omap_device.c.
This approach allows users, which need to manipulate an archdata member
of a device before it is registered, to do so. This is also useful
for users who have their devices created very early so they can be used
at -reserve() time to reserve CMA memory.
The immediate use case for this is to set the private iommu archdata
member, which binds a device to its associated iommu controller.
This way, generic code will be able to attach omap devices to their
iommus, without calling any omap-specific API.
With this in hand, we can further clean the existing mainline OMAP iommu
driver and its mainline users, and focus on generic IOMMU approaches
for future users (rpmsg/remoteproc and the upcoming generic DMA API).
This patch is still considered an interim solution until DT fully materializes
for omap; at that point, this functionality will be removed as DT will
take care of creating the devices and configuring them correctly.
Tested on OMAP4 with a generic rpmsg/remoteproc that doesn't use any
omap-specific IOMMU API anymore.
Signed-off-by: Ohad Ben-Cohen o...@wizery.com
Signed-off-by: Kevin Hilman khil...@ti.com
Signed-off-by: Tony Lindgren t...@atomide.com
Signed-off-by: Rajendra Nayak rna...@ti.com
---
arch/arm/plat-omap/include/plat/omap_device.h |7 +++
arch/arm/plat-omap/omap_device.c | 13 +++--
2 files changed, 10 insertions(+), 10 deletions(-)
diff --git a/arch/arm/plat-omap/include/plat/omap_device.h
b/arch/arm/plat-omap/include/plat/omap_device.h
index 51423d2..05f7615 100644
--- a/arch/arm/plat-omap/include/plat/omap_device.h
+++ b/arch/arm/plat-omap/include/plat/omap_device.h
@@ -100,6 +100,13 @@ struct platform_device *omap_device_build_ss(const char
*pdev_name, int pdev_id,
struct omap_device_pm_latency *pm_lats,
int pm_lats_cnt, int is_early_device);
+struct omap_device *omap_device_alloc(struct platform_device *pdev,
+ struct omap_hwmod **ohs, int oh_cnt,
+ struct omap_device_pm_latency *pm_lats,
+ int pm_lats_cnt);
+void omap_device_delete(struct omap_device *od);
+int omap_device_register(struct platform_device *pdev);
+
void __iomem *omap_device_get_rt_va(struct omap_device *od);
struct device *omap_device_get_by_hwmod_name(const char *oh_name);
diff --git a/arch/arm/plat-omap/omap_device.c b/arch/arm/plat-omap/omap_device.c
index e8d9869..f72fafc 100644
--- a/arch/arm/plat-omap/omap_device.c
+++ b/arch/arm/plat-omap/omap_device.c
@@ -97,14 +97,7 @@
#define USE_WAKEUP_LAT 0
#define IGNORE_WAKEUP_LAT 1
-static int omap_device_register(struct platform_device *pdev);
static int omap_early_device_register(struct platform_device *pdev);
-static struct omap_device *omap_device_alloc(struct platform_device *pdev,
- struct omap_hwmod **ohs, int oh_cnt,
- struct omap_device_pm_latency *pm_lats,
- int pm_lats_cnt);
-static void omap_device_delete(struct omap_device *od);
-
static struct omap_device_pm_latency omap_default_latency[] = {
{
@@ -509,7 +502,7 @@ static int omap_device_fill_resources(struct omap_device
*od,
*
* Returns an struct omap_device pointer or ERR_PTR() on error;
*/
-static struct omap_device *omap_device_alloc(struct platform_device *pdev,
+struct omap_device *omap_device_alloc(struct platform_device *pdev,
struct omap_hwmod **ohs, int oh_cnt,
struct omap_device_pm_latency *pm_lats,
int pm_lats_cnt)
@@ -591,7 +584,7 @@ oda_exit1:
return ERR_PTR(ret);
}
-static void omap_device_delete(struct omap_device *od)
+void omap_device_delete(struct omap_device *od)
{
if (!od)
return;
@@ -817,7 +810,7 @@ static struct dev_pm_domain omap_device_pm_domain = {
* platform_device_register() on the underlying platform_device.
* Returns the return value of platform_device_register().
*/
-static int omap_device_register(struct platform_device *pdev)
+int omap_device_register(struct platform_device *pdev)
{
pr_debug(omap_device: %s: registering\n, pdev-name);
--
1.7.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
[PATCH v2 3/7] mmc: omap_hsmmc: Make the driver support hotpluggable devices
Make the hsmmc driver register the driver using platform_driver_register()
so it can support hotpluggable devices.
This is needed, for instance, in case of OMAP3, wherein some of the mmc
devices might get added and removed dynamically based on dependent modules
like twl4030-gpio.
Signed-off-by: Rajendra Nayak rna...@ti.com
Cc: Chris Ball c...@laptop.org
Cc: linux-...@vger.kernel.org
---
drivers/mmc/host/omap_hsmmc.c |5 +++--
1 files changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
index fd0c661..21b8afa 100644
--- a/drivers/mmc/host/omap_hsmmc.c
+++ b/drivers/mmc/host/omap_hsmmc.c
@@ -1847,7 +1847,7 @@ static void omap_hsmmc_debugfs(struct mmc_host *mmc)
#endif
-static int __init omap_hsmmc_probe(struct platform_device *pdev)
+static int omap_hsmmc_probe(struct platform_device *pdev)
{
struct omap_mmc_platform_data *pdata = pdev-dev.platform_data;
struct mmc_host *mmc;
@@ -2264,6 +2264,7 @@ static struct dev_pm_ops omap_hsmmc_dev_pm_ops = {
};
static struct platform_driver omap_hsmmc_driver = {
+ .probe = omap_hsmmc_probe,
.remove = omap_hsmmc_remove,
.driver = {
.name = DRIVER_NAME,
@@ -2275,7 +2276,7 @@ static struct platform_driver omap_hsmmc_driver = {
static int __init omap_hsmmc_init(void)
{
/* Register the MMC driver */
- return platform_driver_probe(omap_hsmmc_driver, omap_hsmmc_probe);
+ return platform_driver_register(omap_hsmmc_driver);
}
static void __exit omap_hsmmc_cleanup(void)
--
1.7.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
[PATCH v2 2/7] ARM: OMAP: omap_device: Add omap_device_unregister()
Add support to unregister an omap_device using
omap_device_unregister api.
While here, also fix the kerneldoc comments for
omap_device_register.
Signed-off-by: Rajendra Nayak rna...@ti.com
Cc: Kevin Hilman khil...@ti.com
---
arch/arm/plat-omap/include/plat/omap_device.h |1 +
arch/arm/plat-omap/omap_device.c | 20 ++--
2 files changed, 19 insertions(+), 2 deletions(-)
diff --git a/arch/arm/plat-omap/include/plat/omap_device.h
b/arch/arm/plat-omap/include/plat/omap_device.h
index 05f7615..ce0dc86 100644
--- a/arch/arm/plat-omap/include/plat/omap_device.h
+++ b/arch/arm/plat-omap/include/plat/omap_device.h
@@ -106,6 +106,7 @@ struct omap_device *omap_device_alloc(struct
platform_device *pdev,
int pm_lats_cnt);
void omap_device_delete(struct omap_device *od);
int omap_device_register(struct platform_device *pdev);
+void omap_device_unregister(struct platform_device *pdev);
void __iomem *omap_device_get_rt_va(struct omap_device *od);
struct device *omap_device_get_by_hwmod_name(const char *oh_name);
diff --git a/arch/arm/plat-omap/omap_device.c b/arch/arm/plat-omap/omap_device.c
index f72fafc..ae7f055 100644
--- a/arch/arm/plat-omap/omap_device.c
+++ b/arch/arm/plat-omap/omap_device.c
@@ -807,8 +807,8 @@ static struct dev_pm_domain omap_device_pm_domain = {
* @od: struct omap_device * to register
*
* Register the omap_device structure. This currently just calls
- * platform_device_register() on the underlying platform_device.
- * Returns the return value of platform_device_register().
+ * platform_device_add() on the underlying platform_device.
+ * Returns the return value of platform_device_add().
*/
int omap_device_register(struct platform_device *pdev)
{
@@ -819,6 +819,22 @@ int omap_device_register(struct platform_device *pdev)
return platform_device_add(pdev);
}
+/**
+ * omap_device_unregister - unregister an omap_device with one omap_hwmod
+ * @od: struct omap_device * to unregister
+ *
+ * Unregister the omap_device structure. This currently just calls
+ * platform_device_del() on the underlying platform_device.
+ * No return value.
+ */
+void omap_device_unregister(struct platform_device *pdev)
+{
+ pr_debug(omap_device: %s: unregistering\n, pdev-name);
+
+ pdev-dev.parent = omap_device_parent;
+ pdev-dev.pm_domain = omap_device_pm_domain;
+ platform_device_del(pdev);
+}
/* Public functions for use by device drivers through struct platform_data */
--
1.7.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
[PATCH v2 6/7] ARM: OMAP3: Use .teardown of twl4030-gpio to clean board requests
All OMAP3 boards which register a .setup function with twl4030
gpio driver do not seem to have a .teardown hook implemented.
.setup mainly requests a few gpios and also in most cases
does a omap_hsmmc_deferred_add(). Have a .teardown do a gpio_free()
and of the requested gpios and also do a omap_hsmmc_deferred_del().
This helps in case the twl4030 gpio driver is built as a module and
added and removed multiple times. Without the .teardown a multiple
insmod/rmmod can result in gpio request failues and also WARN messages
stating addition of already registered mmc devices.
Reported-by: Russell King rmk+ker...@arm.linux.org.uk
Signed-off-by: Rajendra Nayak rna...@ti.com
---
arch/arm/mach-omap2/board-3430sdp.c | 10 ++
arch/arm/mach-omap2/board-cm-t35.c |8
arch/arm/mach-omap2/board-devkit8000.c | 10 ++
arch/arm/mach-omap2/board-igep0020.c | 14 ++
arch/arm/mach-omap2/board-ldp.c |9 +
arch/arm/mach-omap2/board-omap3beagle.c | 12
arch/arm/mach-omap2/board-omap3evm.c | 10 ++
arch/arm/mach-omap2/board-omap3pandora.c |9 +
arch/arm/mach-omap2/board-omap3stalker.c | 11 +++
arch/arm/mach-omap2/board-omap3touchbook.c | 10 ++
arch/arm/mach-omap2/board-overo.c|8
arch/arm/mach-omap2/board-rx51-peripherals.c |8
arch/arm/mach-omap2/board-zoom-peripherals.c |9 +
arch/arm/mach-omap2/hsmmc.c | 11 +++
arch/arm/mach-omap2/hsmmc.h |4
15 files changed, 143 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/board-3430sdp.c
b/arch/arm/mach-omap2/board-3430sdp.c
index f93bb84..c1ddbb7 100644
--- a/arch/arm/mach-omap2/board-3430sdp.c
+++ b/arch/arm/mach-omap2/board-3430sdp.c
@@ -259,6 +259,15 @@ static int sdp3430_twl_gpio_setup(struct device *dev,
return 0;
}
+static int sdp3430_twl_gpio_teardown(struct device *dev,
+ unsigned gpio, unsigned ngpio)
+{
+ omap_hsmmc_deferred_del(mmc);
+ gpio_free(gpio + 7);
+ gpio_free(gpio + 15);
+ return 0;
+}
+
static struct twl4030_gpio_platform_data sdp3430_gpio_data = {
.gpio_base = OMAP_MAX_GPIO_LINES,
.irq_base = TWL4030_GPIO_IRQ_BASE,
@@ -266,6 +275,7 @@ static struct twl4030_gpio_platform_data sdp3430_gpio_data
= {
.pulldowns = BIT(2) | BIT(6) | BIT(8) | BIT(13)
| BIT(16) | BIT(17),
.setup = sdp3430_twl_gpio_setup,
+ .teardown = sdp3430_twl_gpio_teardown,
};
/* regulator consumer mappings */
diff --git a/arch/arm/mach-omap2/board-cm-t35.c
b/arch/arm/mach-omap2/board-cm-t35.c
index 14df109..55e0180 100644
--- a/arch/arm/mach-omap2/board-cm-t35.c
+++ b/arch/arm/mach-omap2/board-cm-t35.c
@@ -475,11 +475,19 @@ static int cm_t35_twl_gpio_setup(struct device *dev,
unsigned gpio,
return 0;
}
+static int cm_t35_twl_gpio_teardown(struct device *dev, unsigned gpio,
+unsigned ngpio)
+{
+ omap_hsmmc_deferred_del(mmc);
+ gpio_free(gpio + 2);
+ return 0;
+}
static struct twl4030_gpio_platform_data cm_t35_gpio_data = {
.gpio_base = OMAP_MAX_GPIO_LINES,
.irq_base = TWL4030_GPIO_IRQ_BASE,
.irq_end= TWL4030_GPIO_IRQ_END,
.setup = cm_t35_twl_gpio_setup,
+ .teardown = cm_t35_twl_gpio_teardown,
};
static struct twl4030_platform_data cm_t35_twldata = {
diff --git a/arch/arm/mach-omap2/board-devkit8000.c
b/arch/arm/mach-omap2/board-devkit8000.c
index 6b99a5e..2903dd1 100644
--- a/arch/arm/mach-omap2/board-devkit8000.c
+++ b/arch/arm/mach-omap2/board-devkit8000.c
@@ -254,6 +254,15 @@ static int devkit8000_twl_gpio_setup(struct device *dev,
return 0;
}
+static int devkit8000_twl_gpio_teardown(struct device *dev,
+ unsigned gpio, unsigned ngpio)
+{
+ omap_hsmmc_deferred_del(mmc);
+ gpio_free(gpio + TWL4030_GPIO_MAX + 0);
+ gpio_free(gpio + 7);
+ return 0;
+}
+
static struct twl4030_gpio_platform_data devkit8000_gpio_data = {
.gpio_base = OMAP_MAX_GPIO_LINES,
.irq_base = TWL4030_GPIO_IRQ_BASE,
@@ -262,6 +271,7 @@ static struct twl4030_gpio_platform_data
devkit8000_gpio_data = {
.pulldowns = BIT(1) | BIT(2) | BIT(6) | BIT(8) | BIT(13)
| BIT(15) | BIT(16) | BIT(17),
.setup = devkit8000_twl_gpio_setup,
+ .teardown = devkit8000_twl_gpio_teardown,
};
static struct regulator_consumer_supply devkit8000_vpll1_supplies[] = {
diff --git a/arch/arm/mach-omap2/board-igep0020.c
b/arch/arm/mach-omap2/board-igep0020.c
index 11a6aa4..1d0850f 100644
--- a/arch/arm/mach-omap2/board-igep0020.c
+++ b/arch/arm/mach-omap2/board-igep0020.c
@@ -435,12 +435,26 @@ static int
[PATCH v2 4/7] mmc: omap_hsmmc: If probe fails, give our error messages
Giving our debug messages even in case of probe failure seems
not very useful. Make them error messages instead.
Signed-off-by: Rajendra Nayak rna...@ti.com
Cc: Chris Ball c...@laptop.org
Cc: linux-...@vger.kernel.org
---
drivers/mmc/host/omap_hsmmc.c |6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
index 21b8afa..653ffee 100644
--- a/drivers/mmc/host/omap_hsmmc.c
+++ b/drivers/mmc/host/omap_hsmmc.c
@@ -2008,13 +2008,13 @@ static int omap_hsmmc_probe(struct platform_device
*pdev)
ret = request_irq(host-irq, omap_hsmmc_irq, 0,
mmc_hostname(mmc), host);
if (ret) {
- dev_dbg(mmc_dev(host-mmc), Unable to grab HSMMC IRQ\n);
+ dev_err(mmc_dev(host-mmc), Unable to grab HSMMC IRQ\n);
goto err_irq;
}
if (pdata-init != NULL) {
if (pdata-init(pdev-dev) != 0) {
- dev_dbg(mmc_dev(host-mmc),
+ dev_err(mmc_dev(host-mmc),
Unable to configure MMC IRQs\n);
goto err_irq_cd_init;
}
@@ -2037,7 +2037,7 @@ static int omap_hsmmc_probe(struct platform_device *pdev)
IRQF_TRIGGER_RISING |
IRQF_TRIGGER_FALLING,
mmc_hostname(mmc), host);
if (ret) {
- dev_dbg(mmc_dev(host-mmc),
+ dev_err(mmc_dev(host-mmc),
Unable to grab MMC CD IRQ\n);
goto err_irq_cd;
}
--
1.7.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
[PATCH v2 5/7] ARM: OMAP2+: Split omap2_hsmmc_init() to properly support I2C GPIO pins
From: Tony Lindgren t...@atomide.com
Otherwise omap_device_build() and omap_mux related functions
can't be marked as __init when twl is build as a module.
If a board is using GPIO pins or regulators configured by an
external chip, such as TWL PMIC on I2C bus, the board must
mark those MMC controllers as deferred. Additionally both
omap_hsmmc_init() and omap_hsmmc_deferred_add() must be called
by the board.
For MMC controllers using internal GPIO pins for card
detect and regulators the slots don't need to be marked
deferred. In this case calling omap_hsmmc_init() is sufficient.
Note that this patch does not change the behaviour for
board-4430sdp.c board-omap4panda.c. These boards wrongly
rely on the omap_hsmmc.c init function callback to configure
the PMIC GPIO interrupt lines on external chip. If the PMIC
interrupt lines are not configured during init, they will
fail.
Reported-by: Russell King rmk+ker...@arm.linux.org.uk
Signed-off-by: Tony Lindgren t...@atomide.com
Signed-off-by: Rajendra Nayak rna...@ti.com
---
arch/arm/mach-omap2/board-2430sdp.c |2 +-
arch/arm/mach-omap2/board-3430sdp.c | 12 ++--
arch/arm/mach-omap2/board-4430sdp.c |4 +-
arch/arm/mach-omap2/board-am3517evm.c|2 +-
arch/arm/mach-omap2/board-cm-t35.c | 10 +-
arch/arm/mach-omap2/board-devkit8000.c |7 +-
arch/arm/mach-omap2/board-igep0020.c | 11 ++-
arch/arm/mach-omap2/board-ldp.c |2 +-
arch/arm/mach-omap2/board-omap3beagle.c |7 +-
arch/arm/mach-omap2/board-omap3evm.c |9 +-
arch/arm/mach-omap2/board-omap3logic.c |2 +-
arch/arm/mach-omap2/board-omap3pandora.c | 13 ++--
arch/arm/mach-omap2/board-omap3stalker.c | 14 ++--
arch/arm/mach-omap2/board-omap3touchbook.c |7 +-
arch/arm/mach-omap2/board-omap4panda.c |4 +-
arch/arm/mach-omap2/board-overo.c|5 +-
arch/arm/mach-omap2/board-rm680.c|2 +-
arch/arm/mach-omap2/board-rx51-peripherals.c |2 +-
arch/arm/mach-omap2/board-zoom-peripherals.c |9 ++-
arch/arm/mach-omap2/hsmmc.c | 117 +++---
arch/arm/mach-omap2/hsmmc.h | 13 ++-
21 files changed, 165 insertions(+), 89 deletions(-)
diff --git a/arch/arm/mach-omap2/board-2430sdp.c
b/arch/arm/mach-omap2/board-2430sdp.c
index 7370983..c8bda62 100644
--- a/arch/arm/mach-omap2/board-2430sdp.c
+++ b/arch/arm/mach-omap2/board-2430sdp.c
@@ -279,7 +279,7 @@ static void __init omap_2430sdp_init(void)
platform_add_devices(sdp2430_devices, ARRAY_SIZE(sdp2430_devices));
omap_serial_init();
omap_sdrc_init(NULL, NULL);
- omap2_hsmmc_init(mmc);
+ omap_hsmmc_init(mmc);
omap2_usbfs_init(sdp2430_usb_config);
omap_mux_init_signal(usb0hs_stp, OMAP_PULL_ENA | OMAP_PULL_UP);
diff --git a/arch/arm/mach-omap2/board-3430sdp.c
b/arch/arm/mach-omap2/board-3430sdp.c
index 383717b..f93bb84 100644
--- a/arch/arm/mach-omap2/board-3430sdp.c
+++ b/arch/arm/mach-omap2/board-3430sdp.c
@@ -232,11 +232,15 @@ static struct omap2_hsmmc_info mmc[] = {
*/
.caps = MMC_CAP_4_BIT_DATA | MMC_CAP_8_BIT_DATA,
.gpio_wp= 4,
+ .gpio_cd= OMAP_MAX_GPIO_LINES + 0,
+ .deferred = true,
},
{
.mmc= 2,
.caps = MMC_CAP_4_BIT_DATA | MMC_CAP_8_BIT_DATA,
.gpio_wp= 7,
+ .gpio_cd= OMAP_MAX_GPIO_LINES + 1,
+ .deferred = true,
},
{} /* Terminator */
};
@@ -244,12 +248,7 @@ static struct omap2_hsmmc_info mmc[] = {
static int sdp3430_twl_gpio_setup(struct device *dev,
unsigned gpio, unsigned ngpio)
{
- /* gpio + 0 is mmc0_cd (input/IRQ),
-* gpio + 1 is mmc1_cd (input/IRQ)
-*/
- mmc[0].gpio_cd = gpio + 0;
- mmc[1].gpio_cd = gpio + 1;
- omap2_hsmmc_init(mmc);
+ omap_hsmmc_deferred_add(mmc);
/* gpio + 7 is sub_lcd_en_bkl (output/PWM1) */
gpio_request_one(gpio + 7, GPIOF_OUT_INIT_LOW, sub_lcd_en_bkl);
@@ -606,6 +605,7 @@ static void __init omap_3430sdp_init(void)
omap3_mux_init(board_mux, OMAP_PACKAGE_CBB);
omap_board_config = sdp3430_config;
omap_board_config_size = ARRAY_SIZE(sdp3430_config);
+ omap_hsmmc_init(mmc);
omap3430_i2c_init();
omap_display_init(sdp3430_dss_data);
if (omap_rev() OMAP3430_REV_ES1_0)
diff --git a/arch/arm/mach-omap2/board-4430sdp.c
b/arch/arm/mach-omap2/board-4430sdp.c
index 4e90715..09ae257 100644
--- a/arch/arm/mach-omap2/board-4430sdp.c
+++ b/arch/arm/mach-omap2/board-4430sdp.c
@@ -491,9 +491,9 @@ static int __init omap4_twl6030_hsmmc_init(struct
omap2_hsmmc_info *controllers)
{
struct omap2_hsmmc_info *c;
- omap2_hsmmc_init(controllers);
+
[PATCH v2 7/7] ARM: OMAP2+: Mark omap_hsmmc_init and omap_mux related functions as __init
From: Tony Lindgren t...@atomide.com
Now that omap hsmmc init is split into two functions, it's safe
to mark omap_hsmmc_init and omap_mux related functions to __init.
This basically reverts the following fixes for the case where
TWL was compiled as a module:
a98f77b (ARM: omap: fix section mismatch warning for sdp3430_twl_gpio_setup())
8930b4e (ARM: omap: fix section mismatch warnings in mux.c caused by hsmmc.c)
Additionally it fixes up the remaining section warnings for
all callers of omap_mux functions.
Cc: Russell King rmk+ker...@arm.linux.org.uk
Signed-off-by: Tony Lindgren t...@atomide.com
Signed-off-by: Rajendra Nayak rna...@ti.com
---
arch/arm/mach-omap2/board-flash.c |2 +-
arch/arm/mach-omap2/board-omap3beagle.c|6 --
arch/arm/mach-omap2/board-omap3evm.c |3 ++-
arch/arm/mach-omap2/board-omap3stalker.c |3 ++-
arch/arm/mach-omap2/board-omap3touchbook.c | 13 +++--
arch/arm/mach-omap2/board-omap4panda.c |2 +-
arch/arm/mach-omap2/display.c |8
arch/arm/mach-omap2/hsmmc.c|4 ++--
arch/arm/mach-omap2/mux.c | 14 +++---
9 files changed, 30 insertions(+), 25 deletions(-)
diff --git a/arch/arm/mach-omap2/board-flash.c
b/arch/arm/mach-omap2/board-flash.c
index 30a6f52..0349fd2 100644
--- a/arch/arm/mach-omap2/board-flash.c
+++ b/arch/arm/mach-omap2/board-flash.c
@@ -189,7 +189,7 @@ unmap:
*
* @return - void.
*/
-void board_flash_init(struct flash_partitions partition_info[],
+void __init board_flash_init(struct flash_partitions partition_info[],
char chip_sel_board[][GPMC_CS_NUM], int nand_type)
{
u8 cs = 0;
diff --git a/arch/arm/mach-omap2/board-omap3beagle.c
b/arch/arm/mach-omap2/board-omap3beagle.c
index 08749a5..916167e 100644
--- a/arch/arm/mach-omap2/board-omap3beagle.c
+++ b/arch/arm/mach-omap2/board-omap3beagle.c
@@ -274,8 +274,6 @@ static int beagle_twl_gpio_setup(struct device *dev,
{
int r;
- if (beagle_config.mmc1_gpio_wp != -EINVAL)
- omap_mux_init_gpio(beagle_config.mmc1_gpio_wp, OMAP_PIN_INPUT);
mmc[0].gpio_wp = beagle_config.mmc1_gpio_wp;
omap_hsmmc_deferred_add(mmc);
@@ -533,7 +531,11 @@ static void __init omap3_beagle_init(void)
{
omap3_mux_init(board_mux, OMAP_PACKAGE_CBB);
omap3_beagle_init_rev();
+
+ if (beagle_config.mmc1_gpio_wp != -EINVAL)
+ omap_mux_init_gpio(beagle_config.mmc1_gpio_wp, OMAP_PIN_INPUT);
omap_hsmmc_init(mmc);
+
omap3_beagle_i2c_init();
gpio_buttons[0].gpio = beagle_config.usr_button_gpio;
diff --git a/arch/arm/mach-omap2/board-omap3evm.c
b/arch/arm/mach-omap2/board-omap3evm.c
index 2fa7d06..47336c2 100644
--- a/arch/arm/mach-omap2/board-omap3evm.c
+++ b/arch/arm/mach-omap2/board-omap3evm.c
@@ -362,7 +362,6 @@ static int omap3evm_twl_gpio_setup(struct device *dev,
{
int r, lcd_bl_en;
- omap_mux_init_gpio(63, OMAP_PIN_INPUT);
omap_hsmmc_deferred_add(mmc);
/*
@@ -654,7 +653,9 @@ static void __init omap3_evm_init(void)
omap_board_config = omap3_evm_config;
omap_board_config_size = ARRAY_SIZE(omap3_evm_config);
+ omap_mux_init_gpio(63, OMAP_PIN_INPUT);
omap_hsmmc_init(mmc);
+
omap3_evm_i2c_init();
omap_display_init(omap3_evm_dss_data);
diff --git a/arch/arm/mach-omap2/board-omap3stalker.c
b/arch/arm/mach-omap2/board-omap3stalker.c
index c6bab9a..b11700d 100644
--- a/arch/arm/mach-omap2/board-omap3stalker.c
+++ b/arch/arm/mach-omap2/board-omap3stalker.c
@@ -282,7 +282,6 @@ static int
omap3stalker_twl_gpio_setup(struct device *dev,
unsigned gpio, unsigned ngpio)
{
- omap_mux_init_gpio(23, OMAP_PIN_INPUT);
omap_hsmmc_deferred_add(mmc);
/*
@@ -435,7 +434,9 @@ static void __init omap3_stalker_init(void)
omap_board_config = omap3_stalker_config;
omap_board_config_size = ARRAY_SIZE(omap3_stalker_config);
+ omap_mux_init_gpio(23, OMAP_PIN_INPUT);
omap_hsmmc_init(mmc);
+
omap3_stalker_i2c_init();
platform_add_devices(omap3_stalker_devices,
diff --git a/arch/arm/mach-omap2/board-omap3touchbook.c
b/arch/arm/mach-omap2/board-omap3touchbook.c
index 02c0a78..a66e592 100644
--- a/arch/arm/mach-omap2/board-omap3touchbook.c
+++ b/arch/arm/mach-omap2/board-omap3touchbook.c
@@ -119,12 +119,6 @@ static struct gpio_led gpio_leds[];
static int touchbook_twl_gpio_setup(struct device *dev,
unsigned gpio, unsigned ngpio)
{
- if (system_rev = 0x20 system_rev = 0x34301000) {
- omap_mux_init_gpio(23, OMAP_PIN_INPUT);
- mmc[0].gpio_wp = 23;
- } else {
- omap_mux_init_gpio(29, OMAP_PIN_INPUT);
- }
omap_hsmmc_deferred_add(mmc);
/* REVISIT: need ehci-omap hooks for external VBUS
@@ -361,7 +355,14 @@ static void
Re: Questions about DSS device tree adaptation
Hi Tomi,
On 2/22/2012 1:07 PM, Tomi Valkeinen wrote:
Hi,
I'd like to get some feedback for the DSS DT work.
I have currently this in omap4.dtsi, under ocp. It's still a hack, for
example there's sdi for testing even though omap4 doesn't have SDI
output.
dss {
compatible = ti,omap4-dss;
ti,hwmods = dss_core;
dispc {
compatible = ti,omap4-dispc;
ti,hwmods = dss_dispc;
};
dpi: dpi {
compatible = ti,omap4-dpi;
};
sdi: sdi {
compatible = ti,omap3-sdi;
};
dsi1: dsi@1 {
compatible = ti,omap4-dsi;
ti,hwmods = dss_dsi1;
id =0;
Fixed id should be avoided. In theory you should not need that, and if
it is needed like for the UART because Linux is expecting a ttyid, you
should create an alias to map the node to the numbered alias. Just check
what was done for UART.
vdds_dsi-supply =vcxio;
};
dsi2: dsi@2 {
compatible = ti,omap4-dsi;
ti,hwmods = dss_dsi2;
id =1;
vdds_dsi-supply =vcxio;
};
hdmi {
compatible = ti,omap4-hdmi;
ti,hwmods = dss_hdmi;
hpd_gpio =0;
ls_oe =0;
};
rfbi: rfbi {
compatible = ti,omap4-rfbi;
ti,hwmods = dss_rfbi;
};
venc {
compatible = ti,omap4-venc;
ti,hwmods = dss_venc;
};
};
And in omap4-panda.dtsi I have:
dpi {
dvi {
compatible = ti,tfp410;
data-lines =24;
channel =2;
enable-gpio =0;
ddc =dviddc;
};
};
A few notes/questions about the above:
dispc is not an output interface (so it won't have any children), it
doesn't have anything to customize in the dt data, and it's present on
all OMAPs. Should it still be present in the DT data, or should the
device be created dynamically in platform code?
For consistency, it is still better to have it. You will then be able to
use the DT compatible mechanism to identify properly the various DISPC
version if needed.
Don't you have a functional dependency between the DISPC and some other
nodes like DSI, SDI, DPI?
At some point most OMAP devices will probably be created using DT just
to avoid having two different device creation mechanisms.
It is true that the main priority today is to expose the ones that are
configurable at board level.
dpi and sdi are not hwmods as the rest of the nodes. They are, from HW
point of view, more or less parts of DSS or perhaps DISPC.
This is fine, hwmod is really needed only for the IP under PRCM control
mostly. Other device can then be regular platform_device.
I even think that I will get rid of the other hwmod as soon as the clock
binding will be there in DT. Because for the PRCM point of view, there
is only one DSS node. The other ones were created artificially to expose
the clocks to the proper device. They should not be there.
dsi nodes have the id property, which is used by the driver to choose
between DSI1 and DSI2 HW modules. Is there a better way to do this than
a custom property?
Yes, as explained before.
Who/where/when should the devices for dss submodules be created? The
device for dss-node is created automatically by the of-platform code(?),
but the rest of the submodules need to be handled by me somehow.
Yes.
I'm currently using of_platform_populate() in the probe of ti,omap4-dss
driver to create the subdevices, but this approach doesn't feel right.
Shouldn't the devices be created already at the boot time by platform
code, not by the driver code?
No, this is correct thing to do. It is even much more inlined with the
regular way of creating device dynamically in a x86 platform after based
on bus enumeration. This is that whole static platform_device that was
*wrong* so far.
In this case, it will allow you to have different definition of the DSS
and to rely on the sub nodes to discover what are the sub IPs in your
DSS. Whereas today you have to build an array that contains the
definition of the DSS for OMAP2, OMAP3 and OMAP4.
Is the simple-bus, that ocp node also uses, something that I could use
here? If I define the dss node to be compatible with simple-bus also,
does it mean that the of-platform code creates the submodules for me?
Are there any side-effects?
You should not use simple_bus if you already have a driver to probe that
device, otherwise the is the main DT core iterator that will create the
device, and you might not want to do that if you have something to do
during probe like enabling the clock in order to access the sub modules.
How about the actual panel devices. Above there's the ti,tfp410
device. The panel devices are not plain platform devices, so I need to
handle those
