RE: [PATCH] ARM: OMAP: Clock: Remove CK_* flags
Hi Paul, -Original Message- From: Paul Walmsley [mailto:p...@pwsan.com] Sent: Tuesday, February 12, 2013 12:09 PM To: J, KEERTHY Cc: linux-omap@vger.kernel.org; linux-arm-ker...@lists.infradead.org Subject: RE: [PATCH] ARM: OMAP: Clock: Remove CK_* flags On Tue, 12 Feb 2013, J, KEERTHY wrote: -Original Message- From: Paul Walmsley [mailto:p...@pwsan.com] Sent: Monday, February 11, 2013 9:10 PM To: J, KEERTHY Cc: linux-omap@vger.kernel.org; linux-arm- ker...@lists.infradead.org Subject: RE: [PATCH] ARM: OMAP: Clock: Remove CK_* flags On Mon, 11 Feb 2013, J, KEERTHY wrote: Can I pull the other patches and rebase this patch on top of them? I need the branch where I can pull the other clock related patches. I will rebase this patch on top, Verify the PM suspend on OMAP4460 And post it. It's based on Tony's omap-for-v3.9/pm branch. I am on the above branch. I am not seeing retention with/without the patch. Sounds like you get to do some bisecting :-) Heh :-). It narrowed down to this patch: commit 17b7e7d33530e2bbd3bdc90f4db09b91cfdde2bb Author: Paul Walmsley p...@pwsan.com Date: Sat Jan 26 00:48:54 2013 -0700 ARM: OMAP4: clock/hwmod data: start to remove some IP block control clocks Remove some leaf clocks that are actually IP block idle control points, since these should now be handled by the hwmod code. There are still a few types of MODULEMODE clocks that need to be cleaned up: - those still in use by driver or integration code - those in DEFINE_CLK_OMAP_MUX_GATE() blocks; the gate portion of these should be removed A similar process may also be possible on OMAP2/3. Signed-off-by: Paul Walmsley p...@pwsan.com Cc: Benoît Cousson b-cous...@ti.com Cc: Mike Turquette mturque...@linaro.org - Paul Regards, Keerthy -- 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 10/13] mailbox: create dbx500 mailbox driver
Hello,
I have a few comments on the devicetree binding and the way it's parsed.
+static const struct of_device_id dbx500_mailbox_match[] = {
+ { .compatible = stericsson,db8500-mailbox,
+ .data = (void *)db8500_mboxes,
+ },
+ { .compatible = stericsson,db9540-mailbox,
+ .data = (void *)dbx540_mboxes,
+ },
+ { /* sentinel */}
+};
+
The binding for the compatible strings above and property parsing below should
be documented.
+static int dbx500_mbox_probe(struct platform_device *pdev)
+{
+ const struct platform_device_id *platid =
platform_get_device_id(pdev);
+ struct resource *mem;
+ int ret, i, legacy_offset = 0, upap_offset;
+ struct mailbox **list;
+ int irq;
+ struct dbx500_plat_data *pdata = dev_get_platdata(pdev-dev);
+ struct device_node *np = pdev-dev.of_node;
+
+ if (!pdata) {
+ if (np) {
+ of_property_read_u32(np, legacy-offset,
+ legacy_offset);
I see that legacy_offset is initialised to 0, and there's no check on the
return value of of_property_read_u32. Does that mean this is an optional
property? This needs to be documented.
+ of_property_read_u32(np, upap-offset, upap_offset);
However, upap_offset isn't initialised, but there's no check on the return
value. If upap-offset isn't defined in the dt, upap_offset won't have been
initialised.
Is there no basic sanity checking that could be done here? I assume there's a
maximum offset we expect that's less than 4GB?
Additionally, of_property_read_u32 takes a *u32, not *int. It would be nice to
be consistent with the interface.
I'm not familiar with the hardware. What's the difference between the legacy
and upap cases?
+ list = (struct mailbox **)of_match_device(
+ dbx500_mailbox_match,
pdev-dev)-data;
+ if (!list) {
+ /* No mailbox configuration */
+ dev_err(pdev-dev, No configuration
found\n);
+ return -ENODEV;
+ }
+ } else {
+ /* No mailbox configuration */
+ dev_err(pdev-dev, No configuration found\n);
+ return -ENODEV;
+ }
+ } else {
+ list = (struct mailbox **)platid-driver_data;
+ legacy_offset = pdata-legacy_offset;
+ upap_offset = pdata-upap_offset;
+ }
+
+ mem = platform_get_resource_byname(pdev, IORESOURCE_MEM, prcm_reg);
Does this work for dt? I wasn't aware we got anything more than anonymous
memory and interrupts.
+ mbox_base = devm_ioremap(pdev-dev, mem-start, resource_size(mem));
+ if (!mbox_base) {
+ ret = -ENOMEM;
+ goto out;
+ }
+
+ mem = platform_get_resource_byname(pdev, IORESOURCE_MEM,
prcmu_tcdm);
Same here.
Thanks,
Mark.
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] ARM: dts: omap3-devkit8000: Enable audio support
Add the needed sections to enable audio support and related pin mux on
Devkit8000 when booted with DT blob.
Signed-off-by: Anil Kumar anilk...@gmail.com
---
This patch is based on top of kernel 3.8-rc5 and
the following patches.
Peter Ujfalusi:-
ASoC: twl4030: Correct the support for Voice port
ASoC: twl4030: Convert MICBIAS to SUPPLY widget
ASoC: omap-twl4030: Add support for routing, voice port and jack detect
Anil Kumar:-
ARM: dts: add minimal DT support for DevKit8000
https://patchwork.kernel.org/patch/2122461/
-Tested for playback and capture on Devkit8000.
Test process:-
#amixer set 'PredriveR Mixer AudioR2' on
#amixer set 'PredriveL Mixer AudioL2' on
#amixer set PreDriv 100 unmute
#amixer set 'DAC2 Digital Fine' 100
#amixer cset numid=27 1
#arecord | aplay
:100644 100644 dc59272... 1e2c931... M arch/arm/boot/dts/omap3-devkit8000.dts
arch/arm/boot/dts/omap3-devkit8000.dts | 43 ---
1 files changed, 38 insertions(+), 5 deletions(-)
diff --git a/arch/arm/boot/dts/omap3-devkit8000.dts
b/arch/arm/boot/dts/omap3-devkit8000.dts
index dc59272..1e2c931 100644
--- a/arch/arm/boot/dts/omap3-devkit8000.dts
+++ b/arch/arm/boot/dts/omap3-devkit8000.dts
@@ -44,11 +44,27 @@
};
};
+
+ sound {
+ compatible = ti,omap-twl4030;
+ ti,model = devkit8000;
+
+ ti,mcbsp = mcbsp2;
+ ti,codec = twl_audio;
+ ti,audio-routing =
+ Ext Spk, PREDRIVEL,
+ Ext Spk, PREDRIVER,
+ MAINMIC, Main Mic,
+ Main Mic, Mic Bias 1;
+ };
};
omap3_pmx_core {
pinctrl-names = default;
- pinctrl-0 = i2c1_pins;
+ pinctrl-0 =
+ i2c1_pins
+ mcbsp2_pins
+ ;
leds_pins: pinmux_led_pins {
pinctrl-single,pins =
@@ -65,6 +81,21 @@
0x18c 0x118 /* I2C1_SDA */
;
};
+
+ mcbsp2_pins: pinmux_mcbsp2_pins {
+pinctrl-single,pins =
+ /*
+* MCBSP2_FSX, OMAP_MUX_MODE0 | OMAP_PIN_INPUT,
+* MCBSP2_CLKX, OMAP_MUX_MODE0 | OMAP_PIN_INPUT
+*/
+ 0x10c 0x01000100
+ /*
+* MCBSP2_DR, OMAP_MUX_MODE0 | OMAP_PIN_INPUT,
+* MCBSP2_DX, OMAP_MUX_MODE0 | OMAP_PIN_OUTPUT
+*/
+ 0x110 0x0100
+ ;
+ };
};
i2c1 {
@@ -74,6 +105,12 @@
reg = 0x48;
interrupts = 7; /* SYS_NIRQ cascaded to intc */
interrupt-parent = intc;
+
+ twl_audio: audio {
+ compatible = ti,twl4030-audio;
+ codec {
+ };
+ };
};
};
@@ -109,10 +146,6 @@
status = disabled;
};
-mcbsp2 {
- status = disabled;
-};
-
mcbsp3 {
status = disabled;
};
--
1.7.0.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: DT GPMC SRAM and NOR flash support ?
Hi Jon On Mon, Feb 11, 2013 at 7:21 PM, Jon Hunter jon-hun...@ti.com wrote: This is being call from the mach-omap2/board-generic.c file on boot. Where are you suggesting this is called from? I was suggesting this could be called in gpmc_probe_dt() in gpmc.c. Instead of using for_each_node_by_name() and initialize manually each node, it should be possibly (perhaps with some ugly hack) to use of_platform_populate() to initialize gpmc child devices. But I'm not exactly sure how this would work. -- Ezequiel -- 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/8] ARM: omap2: GPMC cleanup
This patchset is v2 of the small cleanup consisting in: * mark some functions as 'static' when appropriate * remove an unused function from gpmc.c * improve error messages when a CS request fails * migrate to dev_err and dev_warn Changelog from v1: * fix gpmc_cs_reserved to return a boolean instead of an integer error code * add a new patch to the patchset cleaning redundant checks It has been tested on a IGEP v2 board with OneNAND, which means the gpmc-nand patch is tested by compilation only. Altough these patchset is almost trivial, any feedback or testing is more than welcome. Ezequiel Garcia (8): ARM: omap2: gpmc: Mark local scoped functions static ARM: omap2: gpmc: Remove unused gpmc_round_ns_to_ticks() function ARM: omap2: gpmc: Fix gpmc_cs_reserved() return value ARM: omap2: gpmc-nand: Print something useful on CS request failure ARM: omap2: gpmc-onenand: Print something useful on CS request failure ARM: omap2: gpmc-onenand: Replace pr_err() with dev_err() ARM: omap2: gpmc-onenand: Replace printk KERN_ERR with dev_warn() ARM: omap2: gpmc: Remove redundant chip select out of range check arch/arm/mach-omap2/gpmc-nand.c|3 ++- arch/arm/mach-omap2/gpmc-onenand.c |8 +--- arch/arm/mach-omap2/gpmc.c | 27 ++- arch/arm/mach-omap2/gpmc.h |7 --- 4 files changed, 13 insertions(+), 32 deletions(-) -- 1.7.8.6 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: OMAP4: PM: Avoid expensive cpu_suspend() path for all CPU power states except off
Santosh Shilimkar santosh.shilim...@ti.com writes: On Saturday 09 February 2013 02:49 AM, Kevin Hilman wrote: Santosh Shilimkar santosh.shilim...@ti.com writes: Current CPU PM code code make use of common cpu_suspend() path for all the CPU power states which is not optimal. In fact cpu_suspend() path is needed only when we put CPU power domain to off state where the CPU context is lost. Update the code accordingly so that the expensive cpu_suspend() path can be avoided for the shallow CPU power states like CPU PD INA/CSWR. Cc: Kevin Hilman khil...@deeprootsystems.com Reported-by: Richard Woodruff r-woodru...@ti.com Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com Looks OK at first glance, but are you sure this is right for the various ways both clusters might idle using coupled CPUidle? Yes it is perfectly safe from all C-states. This patch has been part of the OMAP4/OMAP5 product port for some time. I forgot to send it upstream some how :( Some description of the testing would be helpful here. Sorry. Should have mentioned it in first place. Patch is being tested on OMAP4430 (idle/suspend) and OMAP5 with few out of tree patches. OK, please update changelog with a brief description of how it was tested, and on which platforms. Thanks, Kevin -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 1/8] ARM: omap2: gpmc: Mark local scoped functions static
This patch marks a bunch of functions that are local
to gpmc.c file only as static.
Signed-off-by: Ezequiel Garcia ezequiel.gar...@free-electrons.com
---
arch/arm/mach-omap2/gpmc.c | 14 +++---
arch/arm/mach-omap2/gpmc.h |7 ---
2 files changed, 7 insertions(+), 14 deletions(-)
diff --git a/arch/arm/mach-omap2/gpmc.c b/arch/arm/mach-omap2/gpmc.c
index 1e8bcb4..ffe3e1e 100644
--- a/arch/arm/mach-omap2/gpmc.c
+++ b/arch/arm/mach-omap2/gpmc.c
@@ -181,7 +181,7 @@ void gpmc_cs_write_reg(int cs, int idx, u32 val)
__raw_writel(val, reg_addr);
}
-u32 gpmc_cs_read_reg(int cs, int idx)
+static u32 gpmc_cs_read_reg(int cs, int idx)
{
void __iomem *reg_addr;
@@ -190,7 +190,7 @@ u32 gpmc_cs_read_reg(int cs, int idx)
}
/* TODO: Add support for gpmc_fck to clock framework and use it */
-unsigned long gpmc_get_fclk_period(void)
+static unsigned long gpmc_get_fclk_period(void)
{
unsigned long rate = clk_get_rate(gpmc_l3_clk);
@@ -205,7 +205,7 @@ unsigned long gpmc_get_fclk_period(void)
return rate;
}
-unsigned int gpmc_ns_to_ticks(unsigned int time_ns)
+static unsigned int gpmc_ns_to_ticks(unsigned int time_ns)
{
unsigned long tick_ps;
@@ -215,7 +215,7 @@ unsigned int gpmc_ns_to_ticks(unsigned int time_ns)
return (time_ns * 1000 + tick_ps - 1) / tick_ps;
}
-unsigned int gpmc_ps_to_ticks(unsigned int time_ps)
+static unsigned int gpmc_ps_to_ticks(unsigned int time_ps)
{
unsigned long tick_ps;
@@ -230,7 +230,7 @@ unsigned int gpmc_ticks_to_ns(unsigned int ticks)
return ticks * gpmc_get_fclk_period() / 1000;
}
-unsigned int gpmc_round_ns_to_ticks(unsigned int time_ns)
+static unsigned int gpmc_round_ns_to_ticks(unsigned int time_ns)
{
unsigned long ticks = gpmc_ns_to_ticks(time_ns);
@@ -448,7 +448,7 @@ static int gpmc_cs_mem_enabled(int cs)
return l GPMC_CONFIG7_CSVALID;
}
-int gpmc_cs_set_reserved(int cs, int reserved)
+static int gpmc_cs_set_reserved(int cs, int reserved)
{
if (cs GPMC_CS_NUM)
return -ENODEV;
@@ -459,7 +459,7 @@ int gpmc_cs_set_reserved(int cs, int reserved)
return 0;
}
-int gpmc_cs_reserved(int cs)
+static int gpmc_cs_reserved(int cs)
{
if (cs GPMC_CS_NUM)
return -ENODEV;
diff --git a/arch/arm/mach-omap2/gpmc.h b/arch/arm/mach-omap2/gpmc.h
index fe0a844..b79e35c 100644
--- a/arch/arm/mach-omap2/gpmc.h
+++ b/arch/arm/mach-omap2/gpmc.h
@@ -195,20 +195,13 @@ extern int gpmc_calc_timings(struct gpmc_timings *gpmc_t,
extern void gpmc_update_nand_reg(struct gpmc_nand_regs *reg, int cs);
extern int gpmc_get_client_irq(unsigned irq_config);
-extern unsigned int gpmc_ns_to_ticks(unsigned int time_ns);
-extern unsigned int gpmc_ps_to_ticks(unsigned int time_ps);
extern unsigned int gpmc_ticks_to_ns(unsigned int ticks);
-extern unsigned int gpmc_round_ns_to_ticks(unsigned int time_ns);
-extern unsigned long gpmc_get_fclk_period(void);
extern void gpmc_cs_write_reg(int cs, int idx, u32 val);
-extern u32 gpmc_cs_read_reg(int cs, int idx);
extern int gpmc_calc_divider(unsigned int sync_clk);
extern int gpmc_cs_set_timings(int cs, const struct gpmc_timings *t);
extern int gpmc_cs_request(int cs, unsigned long size, unsigned long *base);
extern void gpmc_cs_free(int cs);
-extern int gpmc_cs_set_reserved(int cs, int reserved);
-extern int gpmc_cs_reserved(int cs);
extern void omap3_gpmc_save_context(void);
extern void omap3_gpmc_restore_context(void);
extern int gpmc_cs_configure(int cs, int cmd, int wval);
--
1.7.8.6
--
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/8] ARM: omap2: gpmc: Remove unused gpmc_round_ns_to_ticks() function
Signed-off-by: Ezequiel Garcia ezequiel.gar...@free-electrons.com
---
arch/arm/mach-omap2/gpmc.c |7 ---
1 files changed, 0 insertions(+), 7 deletions(-)
diff --git a/arch/arm/mach-omap2/gpmc.c b/arch/arm/mach-omap2/gpmc.c
index ffe3e1e..bd3bc93 100644
--- a/arch/arm/mach-omap2/gpmc.c
+++ b/arch/arm/mach-omap2/gpmc.c
@@ -230,13 +230,6 @@ unsigned int gpmc_ticks_to_ns(unsigned int ticks)
return ticks * gpmc_get_fclk_period() / 1000;
}
-static unsigned int gpmc_round_ns_to_ticks(unsigned int time_ns)
-{
- unsigned long ticks = gpmc_ns_to_ticks(time_ns);
-
- return ticks * gpmc_get_fclk_period() / 1000;
-}
-
static unsigned int gpmc_ticks_to_ps(unsigned int ticks)
{
return ticks * gpmc_get_fclk_period();
--
1.7.8.6
--
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 4/8] ARM: omap2: gpmc-nand: Print something useful on CS request failure
If CS request fails the current error message is rather unhelpful.
Fix it by printing the failing chip select and the error code.
Signed-off-by: Ezequiel Garcia ezequiel.gar...@free-electrons.com
---
arch/arm/mach-omap2/gpmc-nand.c |3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-omap2/gpmc-nand.c b/arch/arm/mach-omap2/gpmc-nand.c
index afc1e8c..e50e438 100644
--- a/arch/arm/mach-omap2/gpmc-nand.c
+++ b/arch/arm/mach-omap2/gpmc-nand.c
@@ -122,7 +122,8 @@ int gpmc_nand_init(struct omap_nand_platform_data
*gpmc_nand_data,
err = gpmc_cs_request(gpmc_nand_data-cs, NAND_IO_SIZE,
(unsigned long *)gpmc_nand_resource[0].start);
if (err 0) {
- dev_err(dev, Cannot request GPMC CS\n);
+ dev_err(dev, Cannot request GPMC CS %d, error %d\n,
+ gpmc_nand_data-cs, err);
return err;
}
--
1.7.8.6
--
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/8] ARM: omap2: gpmc: Fix gpmc_cs_reserved() return value
Currently gpmc_cs_reserved() return value is somewhat inconsistent,
returning a negative value on an error condition, a positive value
if the chip select is reserved and zero if it's available.
Fix this by returning a boolean value as the function name suggests:
* true if the chip select is reserved,
* false if it's available
Suggested-by: Felipe Balbi ba...@ti.com
Signed-off-by: Ezequiel Garcia ezequiel.gar...@free-electrons.com
---
Changelog from v1:
* As suggested by Felipe Balbi, fix return code to a boolean
arch/arm/mach-omap2/gpmc.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach-omap2/gpmc.c b/arch/arm/mach-omap2/gpmc.c
index bd3bc93..fa4764f 100644
--- a/arch/arm/mach-omap2/gpmc.c
+++ b/arch/arm/mach-omap2/gpmc.c
@@ -452,10 +452,10 @@ static int gpmc_cs_set_reserved(int cs, int reserved)
return 0;
}
-static int gpmc_cs_reserved(int cs)
+static bool gpmc_cs_reserved(int cs)
{
if (cs GPMC_CS_NUM)
- return -ENODEV;
+ return true;
return gpmc_cs_map (1 cs);
}
--
1.7.8.6
--
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/8] ARM: omap2: gpmc-onenand: Print something useful on CS request failure
If CS request fails the current error message is rather unhelpful.
Fix it by printing the failing chip select and the error code.
Signed-off-by: Ezequiel Garcia ezequiel.gar...@free-electrons.com
---
arch/arm/mach-omap2/gpmc-onenand.c |3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-omap2/gpmc-onenand.c
b/arch/arm/mach-omap2/gpmc-onenand.c
index fadd8743..0ee5317 100644
--- a/arch/arm/mach-omap2/gpmc-onenand.c
+++ b/arch/arm/mach-omap2/gpmc-onenand.c
@@ -379,7 +379,8 @@ void gpmc_onenand_init(struct omap_onenand_platform_data
*_onenand_data)
err = gpmc_cs_request(gpmc_onenand_data-cs, ONENAND_IO_SIZE,
(unsigned long *)gpmc_onenand_resource.start);
if (err 0) {
- pr_err(%s: Cannot request GPMC CS\n, __func__);
+ pr_err(%s: Cannot request GPMC CS %d, error %d\n,
+ __func__, gpmc_onenand_data-cs, err);
return;
}
--
1.7.8.6
--
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/8] ARM: omap2: gpmc-onenand: Replace pr_err() with dev_err()
Signed-off-by: Ezequiel Garcia ezequiel.gar...@free-electrons.com
---
arch/arm/mach-omap2/gpmc-onenand.c |7 ---
1 files changed, 4 insertions(+), 3 deletions(-)
diff --git a/arch/arm/mach-omap2/gpmc-onenand.c
b/arch/arm/mach-omap2/gpmc-onenand.c
index 0ee5317..4771945 100644
--- a/arch/arm/mach-omap2/gpmc-onenand.c
+++ b/arch/arm/mach-omap2/gpmc-onenand.c
@@ -359,6 +359,7 @@ static int gpmc_onenand_setup(void __iomem *onenand_base,
int *freq_ptr)
void gpmc_onenand_init(struct omap_onenand_platform_data *_onenand_data)
{
int err;
+ struct device *dev = gpmc_onenand_device.dev;
gpmc_onenand_data = _onenand_data;
gpmc_onenand_data-onenand_setup = gpmc_onenand_setup;
@@ -379,8 +380,8 @@ void gpmc_onenand_init(struct omap_onenand_platform_data
*_onenand_data)
err = gpmc_cs_request(gpmc_onenand_data-cs, ONENAND_IO_SIZE,
(unsigned long *)gpmc_onenand_resource.start);
if (err 0) {
- pr_err(%s: Cannot request GPMC CS %d, error %d\n,
- __func__, gpmc_onenand_data-cs, err);
+ dev_err(dev, Cannot request GPMC CS %d, error %d\n,
+ gpmc_onenand_data-cs, err);
return;
}
@@ -388,7 +389,7 @@ void gpmc_onenand_init(struct omap_onenand_platform_data
*_onenand_data)
ONENAND_IO_SIZE - 1;
if (platform_device_register(gpmc_onenand_device) 0) {
- pr_err(%s: Unable to register OneNAND device\n, __func__);
+ dev_err(dev, Unable to register OneNAND device\n);
gpmc_cs_free(gpmc_onenand_data-cs);
return;
}
--
1.7.8.6
--
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 7/8] ARM: omap2: gpmc-onenand: Replace printk KERN_ERR with dev_warn()
Since the condition is not an error but a warning, replace
printk KERN_ERR with dev_warn.
Signed-off-by: Ezequiel Garcia ezequiel.gar...@free-electrons.com
---
arch/arm/mach-omap2/gpmc-onenand.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-omap2/gpmc-onenand.c
b/arch/arm/mach-omap2/gpmc-onenand.c
index 4771945..fd6e35b 100644
--- a/arch/arm/mach-omap2/gpmc-onenand.c
+++ b/arch/arm/mach-omap2/gpmc-onenand.c
@@ -367,7 +367,7 @@ void gpmc_onenand_init(struct omap_onenand_platform_data
*_onenand_data)
if (cpu_is_omap24xx()
(gpmc_onenand_data-flags ONENAND_SYNC_READWRITE)) {
- printk(KERN_ERR Onenand using only SYNC_READ on 24xx\n);
+ dev_warn(dev, OneNAND using only SYNC_READ on 24xx\n);
gpmc_onenand_data-flags = ~ONENAND_SYNC_READWRITE;
gpmc_onenand_data-flags |= ONENAND_SYNC_READ;
}
--
1.7.8.6
--
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 8/8] ARM: omap2: gpmc: Remove redundant chip select out of range check
This check is done before the call to gpmc_cs_reserved() and
gpmc_cs_set_reserved() and it's redundant to do it again in each
function. This simplifies the code a bit.
Signed-off-by: Ezequiel Garcia ezequiel.gar...@free-electrons.com
---
arch/arm/mach-omap2/gpmc.c | 10 +-
1 files changed, 1 insertions(+), 9 deletions(-)
diff --git a/arch/arm/mach-omap2/gpmc.c b/arch/arm/mach-omap2/gpmc.c
index fa4764f..0201ea9 100644
--- a/arch/arm/mach-omap2/gpmc.c
+++ b/arch/arm/mach-omap2/gpmc.c
@@ -441,22 +441,14 @@ static int gpmc_cs_mem_enabled(int cs)
return l GPMC_CONFIG7_CSVALID;
}
-static int gpmc_cs_set_reserved(int cs, int reserved)
+static void gpmc_cs_set_reserved(int cs, int reserved)
{
- if (cs GPMC_CS_NUM)
- return -ENODEV;
-
gpmc_cs_map = ~(1 cs);
gpmc_cs_map |= (reserved ? 1 : 0) cs;
-
- return 0;
}
static bool gpmc_cs_reserved(int cs)
{
- if (cs GPMC_CS_NUM)
- return true;
-
return gpmc_cs_map (1 cs);
}
--
1.7.8.6
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/3] ARM: OMAP2xxx: PM: enter WFI via inline asm if CORE stays active
Paul Walmsley p...@pwsan.com writes:
On Sun, 30 Dec 2012, Paul Walmsley wrote:
There shouldn't be any need to jump to SRAM code if the OMAP CORE
clockdomain (and consequently the SDRAM controller and CORE PLL) stays
active during MPU WFI. The SRAM code should only be needed when the RAM
enters self-refresh. So in the case where CORE stays active, just call
WFI directly from the mach-omap2/pm24xx.c code. This removes some
unnecessary SRAM code.
Signed-off-by: Paul Walmsley p...@pwsan.com
Cc: Richard Woodruff r-woodru...@ti.com
Cc: Kevin Hilman khil...@deeprootsystems.com
Here's an updated version of this one.
- Paul
From: Paul Walmsley p...@pwsan.com
Date: Sun, 30 Dec 2012 10:15:48 -0700
Subject: [PATCH] ARM: OMAP2xxx: PM: enter WFI via inline asm if CORE stays
active
There shouldn't be any need to jump to SRAM code if the OMAP CORE
clockdomain (and consequently the SDRAM controller and CORE PLL) stays
active during MPU WFI. The SRAM code should only be needed when the RAM
enters self-refresh. So in the case where CORE stays active, just call
WFI directly from the mach-omap2/pm24xx.c code. This removes some
unnecessary SRAM code.
This second version replaces the inline WFI with the corresponding
coprocessor register call, using tlbflush.h as an example. This is
because the assembler doesn't recognize WFI as a valid ARMv6
instruction.
Signed-off-by: Paul Walmsley p...@pwsan.com
Cc: Richard Woodruff r-woodru...@ti.com
Cc: Kevin Hilman khil...@deeprootsystems.com
Acked-by: Kevin Hilman khil...@linaro.org
---
arch/arm/mach-omap2/pm24xx.c| 12 ++--
arch/arm/mach-omap2/sleep24xx.S | 19 ---
2 files changed, 6 insertions(+), 25 deletions(-)
diff --git a/arch/arm/mach-omap2/pm24xx.c b/arch/arm/mach-omap2/pm24xx.c
index c333fa6..8914b9e 100644
--- a/arch/arm/mach-omap2/pm24xx.c
+++ b/arch/arm/mach-omap2/pm24xx.c
@@ -54,7 +54,6 @@
#include powerdomain.h
#include clockdomain.h
-static void (*omap2_sram_idle)(void);
static void (*omap2_sram_suspend)(u32 dllctrl, void __iomem *sdrc_dlla_ctrl,
void __iomem *sdrc_power);
@@ -172,6 +171,8 @@ static int omap2_allow_mpu_retention(void)
static void omap2_enter_mpu_retention(void)
{
+ const int zero = 0;
+
/* Putting MPU into the WFI state while a transfer is active
* seems to cause the I2C block to timeout. Why? Good question. */
if (omap2_i2c_active())
@@ -196,7 +197,8 @@ static void omap2_enter_mpu_retention(void)
OMAP2_PM_PWSTCTRL);
}
- omap2_sram_idle();
+ /* WFI */
+ asm(mcr p15, 0, %0, c7, c0, 4 : : r (zero) : memory, cc);
}
static int omap2_can_sleep(void)
@@ -356,11 +358,9 @@ int __init omap2_pm_init(void)
/*
* We copy the assembler sleep/wakeup routines to SRAM.
* These routines need to be in SRAM as that's the only
- * memory the MPU can see when it wakes up.
+ * memory the MPU can see when it wakes up after the entire
+ * chip enters idle.
*/
- omap2_sram_idle = omap_sram_push(omap24xx_idle_loop_suspend,
- omap24xx_idle_loop_suspend_sz);
-
omap2_sram_suspend = omap_sram_push(omap24xx_cpu_suspend,
omap24xx_cpu_suspend_sz);
diff --git a/arch/arm/mach-omap2/sleep24xx.S b/arch/arm/mach-omap2/sleep24xx.S
index ce0ccd2..1d3cb25 100644
--- a/arch/arm/mach-omap2/sleep24xx.S
+++ b/arch/arm/mach-omap2/sleep24xx.S
@@ -37,25 +37,6 @@
.text
/*
- * Forces OMAP into idle state
- *
- * omap24xx_idle_loop_suspend() - This bit of code just executes the WFI
- * for normal idles.
- *
- * Note: This code get's copied to internal SRAM at boot. When the OMAP
- *wakes up it continues execution at the point it went to sleep.
- */
- .align 3
-ENTRY(omap24xx_idle_loop_suspend)
- stmfd sp!, {r0, lr} @ save registers on stack
- mov r0, #0 @ clear for mcr setup
- mcr p15, 0, r0, c7, c0, 4 @ wait for interrupt
- ldmfd sp!, {r0, pc} @ restore regs and return
-
-ENTRY(omap24xx_idle_loop_suspend_sz)
- .word . - omap24xx_idle_loop_suspend
-
-/*
* omap24xx_cpu_suspend() - Forces OMAP into deep sleep state by completing
* SDRC shutdown then ARM shutdown. Upon wake MPU is back on so just restore
* SDRC.
--
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 09/11] mfd: twl-core: Collect global variables behind one private structure (global)
On 02/12/2013 01:26 AM, Peter Ujfalusi wrote: On 02/11/2013 09:22 PM, Jon Hunter wrote: Good point. I just noticed that none of my omap2+ board were booting and on omap3/4 I was the panic in the twl code. I can't say that I checked the panic on omap2, so may be that was another problem? Do you have insights on the code path leading to a crash on OMAP3/4? I have been running this code on several boards (BeagleBoard, Zoom2, PandaBoard, Blaze) and have not seen a crash. Here is the panic log ... [2.286132] Unable to handle kernel NULL pointer dereference at virtual address [2.294738] pgd = c0004000 [2.297576] [] *pgd= [2.301361] Internal error: Oops: 5 [#1] SMP ARM [2.306243] Modules linked in: [2.309448] CPU: 0Not tainted (3.8.0-rc6-next-20130207-00016-g735c237 #35) [2.317169] PC is at twl_i2c_read+0x3c/0xec [2.321563] LR is at twl_i2c_read+0x1c/0xec [2.325988] pc : [c0333950]lr : [c0333930]psr: 8153 [2.325988] sp : c702fed0 ip : fp : [2.338043] r10: c702e000 r9 : c06e84e8 r8 : c06e51c8 [2.343536] r7 : 0001 r6 : 0006 r5 : c702fef6 r4 : 0004 [2.350402] r3 : c129508c r2 : 0006 r1 : c702fef6 r0 : 000e [2.357269] Flags: Nzcv IRQs on FIQs off Mode SVC_32 ISA ARM Segment kernel [2.365051] Control: 10c5387d Table: 80004019 DAC: 0017 [2.371093] Process swapper/0 (pid: 1, stack limit = 0xc702e240) [2.377410] Stack: (0xc702fed0 to 0xc703) [2.382019] fec0: c0d42180 c0d429d0 c70a7640 c07354c4 [2.390624] fee0: 0001 c0719798 c0d42180 c06f2cc0 c04e76cc c06ee1ac c07354c4 [2.399230] ff00: 0007 c06f2d64 0017 c06fb308 c06f07a4 c0cb8580 c06edee0 [2.407836] ff20: c06eded4 c06e8504 c0d42180 c0008768 009e c00611b4 0001 [2.416442] ff40: c061994c c06b7548 0007 0007 c07354c4 0007 c0719798 [2.425048] ff60: c0d42180 c06e51c8 c07197a0 009e c06e590c 0007 0007 [2.433654] ff80: c06e51c8 c04d26ec [2.442260] ffa0: c04d26f4 c00137b0 [2.450866] ffc0: [2.459472] ffe0: 0013 80fb6c10 71bbcd20 [2.468078] [c0333950] (twl_i2c_read+0x3c/0xec) from [c06f2cc0] (omap3_twl_set_sr_bit+0x3c/0xb4) [2.477722] [c06f2cc0] (omap3_twl_set_sr_bit+0x3c/0xb4) from [c06f2d64] (omap3_twl_init+0x2c/0x70) [2.487518] [c06f2d64] (omap3_twl_init+0x2c/0x70) from [c06fb308] (omap_pmic_late_init+0x18/0x24) [2.497222] [c06fb308] (omap_pmic_late_init+0x18/0x24) from [c06f07a4] (omap2_common_pm_late_init+0x18/0xd0) [2.507934] [c06f07a4] (omap2_common_pm_late_init+0x18/0xd0) from [c06edee0] (omap3_init_late+0xc/0x18) [2.518188] [c06edee0] (omap3_init_late+0xc/0x18) from [c06e8504] (init_machine_late+0x1c/0x28) [2.527740] [c06e8504] (init_machine_late+0x1c/0x28) from [c0008768] (do_one_initcall+0x100/0x16c) [2.537536] [c0008768] (do_one_initcall+0x100/0x16c) from [c06e590c] (kernel_init_freeable+0xfc/0x1c8) [2.547698] [c06e590c] (kernel_init_freeable+0xfc/0x1c8) from [c04d26f4] (kernel_init+0x8/0xe4) [2.557250] [c04d26f4] (kernel_init+0x8/0xe4) from [c00137b0] (ret_from_fork+0x14/0x24) But the fix is valid. Thanks. I saw this on linux-next earlier this week, but now I am not seeing it and the fix I posted is not there. So I am not sure what changed to cause this to occur earlier this week but the problem appears to be gone again. However, at least the fix will prevent such panics if someone is calling twl_i2c_read/write too early. Cheers Jon -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: OMAP3+: Fix kernel panic on boot
On 02/12/2013 04:07 AM, Samuel Ortiz wrote: Hi Jon, On Mon, Feb 11, 2013 at 02:26:19PM -0600, Jon Hunter wrote: Commit 8a6aaa3 (mfd: twl-core: Collect global variables behind one private structure (global)) removed the variable inuse that is used to determine if the device has been initialised and now use the twl_priv structure instead. This is causing the kernel to panic on OMAP3+ devices using the twl driver, because we try to access the twl_priv-ready member before checking if twl_priv is initialised. Fix this and move this test to the beginning of the twl_i2c_read/write function because twl_get_last_module() also uses the twl_priv structure. Signed-off-by: Jon Hunter jon-hun...@ti.com Acked-by: Peter Ujfalusi peter.ujfal...@ti.com --- drivers/mfd/twl-core.c | 16 1 file changed, 8 insertions(+), 8 deletions(-) Patch applied, thanks. I fixed the subject as it's codewise not ARM or OMAP3 related, but rather mfd and twl-core. Good point! Thanks Jon -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 0/8] ARM: omap2: GPMC cleanup
On 02/12/2013 09:18 AM, Ezequiel Garcia wrote: This patchset is v2 of the small cleanup consisting in: * mark some functions as 'static' when appropriate * remove an unused function from gpmc.c * improve error messages when a CS request fails * migrate to dev_err and dev_warn Changelog from v1: * fix gpmc_cs_reserved to return a boolean instead of an integer error code * add a new patch to the patchset cleaning redundant checks It has been tested on a IGEP v2 board with OneNAND, which means the gpmc-nand patch is tested by compilation only. Altough these patchset is almost trivial, any feedback or testing is more than welcome. Ezequiel Garcia (8): ARM: omap2: gpmc: Mark local scoped functions static ARM: omap2: gpmc: Remove unused gpmc_round_ns_to_ticks() function ARM: omap2: gpmc: Fix gpmc_cs_reserved() return value ARM: omap2: gpmc-nand: Print something useful on CS request failure ARM: omap2: gpmc-onenand: Print something useful on CS request failure ARM: omap2: gpmc-onenand: Replace pr_err() with dev_err() ARM: omap2: gpmc-onenand: Replace printk KERN_ERR with dev_warn() ARM: omap2: gpmc: Remove redundant chip select out of range check arch/arm/mach-omap2/gpmc-nand.c|3 ++- arch/arm/mach-omap2/gpmc-onenand.c |8 +--- arch/arm/mach-omap2/gpmc.c | 27 ++- arch/arm/mach-omap2/gpmc.h |7 --- 4 files changed, 13 insertions(+), 32 deletions(-) Looks good to me. I noticed that for some patches there is no changelog and I understand that that is because they are some what trivial clean-ups and the subject explains the patch. However, typically it is good to have a changelog in the patch no matter how trivial it is. Tony may ask you to add a changelog. Otherwise ... Reviewed-by: Jon Hunter jon-hun...@ti.com Cheers Jon -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: omap: board-h4: remove warning for is_gpmc_muxed
* Olof Johansson o...@lixom.net [130211 19:51]:
If the ethernet driver is not selected, you otherwise get:
arch/arm/mach-omap2/board-h4.c:237:12: warning: 'is_gpmc_muxed' defined but
not used [-Wunused-function]
I guess it could be argued that the device setup should/could always
be done even if the driver isn't enabled, but hopefully the board files
will all go away some day so let's stick to the smaller delta.
Looks right to me. The only thing stopping us from removing board-h4.c
is the GPMC + smc91x DT binding for NFS root. I doubt anybody is using
H4 for anything else.
Acked-by: Tony Lindgren t...@atomide.com
Signed-off-by: Olof Johansson o...@lixom.net
---
arch/arm/mach-omap2/board-h4.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach-omap2/board-h4.c b/arch/arm/mach-omap2/board-h4.c
index 812c829..e34541d 100644
--- a/arch/arm/mach-omap2/board-h4.c
+++ b/arch/arm/mach-omap2/board-h4.c
@@ -229,6 +229,8 @@ static u32 get_sysboot_value(void)
OMAP2_SYSBOOT_1_MASK | OMAP2_SYSBOOT_0_MASK));
}
+#if defined(CONFIG_SMC91X) || defined(CONFIG_SMC91x_MODULE)
+
/* H4-2420's always used muxed mode, H4-2422's always use non-muxed
*
* Note: OMAP-GIT doesn't correctly do is_cpu_omap2422 and is_cpu_omap2423
@@ -246,8 +248,6 @@ static u32 is_gpmc_muxed(void)
return 0;
}
-#if defined(CONFIG_SMC91X) || defined(CONFIG_SMC91x_MODULE)
-
static struct omap_smc91x_platform_data board_smc91x_data = {
.cs = 1,
.gpio_irq = 92,
--
1.8.1.192.gc4361b8
--
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 v7 07/10] dmaengine: add dma_request_slave_channel_compat()
On Fri, Feb 01, 2013 at 01:22:52PM -0500, Matt Porter wrote:
Adds a dma_request_slave_channel_compat() wrapper which accepts
both the arguments from dma_request_channel() and
dma_request_slave_channel(). Based on whether the driver is
instantiated via DT, the appropriate channel request call will be
made.
This allows for a much cleaner migration of drivers to the
dmaengine DT API as platforms continue to be mixed between those
that boot using DT and those that do not.
Suggested-by: Tony Lindgren t...@atomide.com
Signed-off-by: Matt Porter mpor...@ti.com
Acked-by: Tony Lindgren t...@atomide.com
Acked-by: Arnd Bergmann a...@arndb.de
Acked-by: Vinod Koul vinod.k...@intel.com
---
include/linux/dmaengine.h | 16
1 file changed, 16 insertions(+)
diff --git a/include/linux/dmaengine.h b/include/linux/dmaengine.h
index bfcdecb..17d8ffd 100644
--- a/include/linux/dmaengine.h
+++ b/include/linux/dmaengine.h
@@ -1001,6 +1001,22 @@ void dma_run_dependencies(struct
dma_async_tx_descriptor *tx);
struct dma_chan *dma_find_channel(enum dma_transaction_type tx_type);
struct dma_chan *net_dma_find_channel(void);
#define dma_request_channel(mask, x, y) __dma_request_channel((mask), x, y)
+#define dma_request_slave_channel_compat(mask, x, y, dev, name) \
+ __dma_request_slave_channel_compat((mask), x, y, dev, name)
+
+static inline struct dma_chan
+*__dma_request_slave_channel_compat(dma_cap_mask_t *mask, dma_filter_fn fn,
+ void *fn_param, struct device *dev,
+ char *name)
+{
+ struct dma_chan *chan;
+
+ chan = dma_request_slave_channel(dev, name);
+ if (chan)
+ return chan;
+
+ return __dma_request_channel(mask, fn, fn_param);
+}
/* --- Helper iov-locking functions --- */
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: OMAP2+: fix some omap_device_build() calls that aren't compiled by default
* Paul Walmsley p...@pwsan.com [130211 20:02]: Commit c1d1cd597fc77af3086470f8627d77f52f7f8b6c (ARM: OMAP2+: omap_device: remove obsolete pm_lats and early_device code) missed a few omap_device_build() calls that aren't included as part of the default OMAP2+ Kconfig, omap2plus_defconfig. Ideally, all devices that are present on the SoC should be created by default, and only the corresponding device driver should be configured or deconfigured in Kconfig. This allows drivers to be built as modules and loaded later, even if they weren't part of the original kernel build. Unfortunately, we're not quite there yet. Thanks to Tony Lindgren for reporting this, found during his randconfig tests. Thanks, I'll apply this into omap-for-v3.9/pm-wfi as the breaking commit is already in arm-soc/for-next. 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/8] ARM: omap2: GPMC cleanup
* Jon Hunter jon-hun...@ti.com [130212 08:36]: On 02/12/2013 09:18 AM, Ezequiel Garcia wrote: This patchset is v2 of the small cleanup consisting in: * mark some functions as 'static' when appropriate * remove an unused function from gpmc.c * improve error messages when a CS request fails * migrate to dev_err and dev_warn Changelog from v1: * fix gpmc_cs_reserved to return a boolean instead of an integer error code * add a new patch to the patchset cleaning redundant checks It has been tested on a IGEP v2 board with OneNAND, which means the gpmc-nand patch is tested by compilation only. Altough these patchset is almost trivial, any feedback or testing is more than welcome. Ezequiel Garcia (8): ARM: omap2: gpmc: Mark local scoped functions static ARM: omap2: gpmc: Remove unused gpmc_round_ns_to_ticks() function ARM: omap2: gpmc: Fix gpmc_cs_reserved() return value ARM: omap2: gpmc-nand: Print something useful on CS request failure ARM: omap2: gpmc-onenand: Print something useful on CS request failure ARM: omap2: gpmc-onenand: Replace pr_err() with dev_err() ARM: omap2: gpmc-onenand: Replace printk KERN_ERR with dev_warn() ARM: omap2: gpmc: Remove redundant chip select out of range check arch/arm/mach-omap2/gpmc-nand.c|3 ++- arch/arm/mach-omap2/gpmc-onenand.c |8 +--- arch/arm/mach-omap2/gpmc.c | 27 ++- arch/arm/mach-omap2/gpmc.h |7 --- 4 files changed, 13 insertions(+), 32 deletions(-) Looks good to me. I noticed that for some patches there is no changelog and I understand that that is because they are some what trivial clean-ups and the subject explains the patch. However, typically it is good to have a changelog in the patch no matter how trivial it is. Tony may ask you to add a changelog. Otherwise ... Reviewed-by: Jon Hunter jon-hun...@ti.com Yes please add a changelog. 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: OMAP2+: fix some omap_device_build() calls that aren't compiled by default
On Tue, 12 Feb 2013, Tony Lindgren wrote: Thanks, I'll apply this into omap-for-v3.9/pm-wfi as the breaking commit is already in arm-soc/for-next. OK thanks. Looks like I'll have one more fix for one of the commits in arm-soc/for-next; working on it now. - 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
[GIT PULL 1/5] omap SoC related late changes for v3.9 merge window
The following changes since commit 88b62b915b0b7e25870eb0604ed9a92ba4bfc9f7: Linux 3.8-rc6 (2013-02-01 12:08:14 +1100) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap tags/omap-for-v3.9/soc-signed for you to fetch changes up to 5af044f472501c8e9bd6bb274fb3d71d07a038cd: ARM: OMAP2: AM33XX: id: Add support for AM335x PG2.0 (2013-02-01 14:53:39 -0800) am33xx specific updates for restart and revision detection. Also get rid of OMAP_32K_TIMER_HZ as that no longer is needed. AnilKumar Ch (1): ARM: OMAP2: AM33XX: id: Add support for AM335x PG2.0 Jean-Sebastien A. Beaudry (1): ARM: OMAP2+: AM33xx: Add SoC specific restart hook Santosh Shilimkar (1): ARM: OMAP2+: Get rid of custom OMAP_32K_TIMER_HZ arch/arm/Kconfig| 1 - arch/arm/mach-omap2/Makefile| 1 + arch/arm/mach-omap2/am33xx-restart.c| 34 + arch/arm/mach-omap2/board-generic.c | 1 + arch/arm/mach-omap2/common.h| 8 arch/arm/mach-omap2/id.c| 14 -- arch/arm/mach-omap2/soc.h | 1 + arch/arm/plat-omap/Kconfig | 9 - arch/arm/plat-omap/include/plat/timex.h | 8 9 files changed, 57 insertions(+), 20 deletions(-) create mode 100644 arch/arm/mach-omap2/am33xx-restart.c -- 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/8] ARM: omap2: GPMC cleanup
On Tue, Feb 12, 2013 at 09:12:53AM -0800, Tony Lindgren wrote: * Jon Hunter jon-hun...@ti.com [130212 08:36]: On 02/12/2013 09:18 AM, Ezequiel Garcia wrote: This patchset is v2 of the small cleanup consisting in: * mark some functions as 'static' when appropriate * remove an unused function from gpmc.c * improve error messages when a CS request fails * migrate to dev_err and dev_warn Changelog from v1: * fix gpmc_cs_reserved to return a boolean instead of an integer error code * add a new patch to the patchset cleaning redundant checks It has been tested on a IGEP v2 board with OneNAND, which means the gpmc-nand patch is tested by compilation only. Altough these patchset is almost trivial, any feedback or testing is more than welcome. Ezequiel Garcia (8): ARM: omap2: gpmc: Mark local scoped functions static ARM: omap2: gpmc: Remove unused gpmc_round_ns_to_ticks() function ARM: omap2: gpmc: Fix gpmc_cs_reserved() return value ARM: omap2: gpmc-nand: Print something useful on CS request failure ARM: omap2: gpmc-onenand: Print something useful on CS request failure ARM: omap2: gpmc-onenand: Replace pr_err() with dev_err() ARM: omap2: gpmc-onenand: Replace printk KERN_ERR with dev_warn() ARM: omap2: gpmc: Remove redundant chip select out of range check arch/arm/mach-omap2/gpmc-nand.c|3 ++- arch/arm/mach-omap2/gpmc-onenand.c |8 +--- arch/arm/mach-omap2/gpmc.c | 27 ++- arch/arm/mach-omap2/gpmc.h |7 --- 4 files changed, 13 insertions(+), 32 deletions(-) Looks good to me. I noticed that for some patches there is no changelog and I understand that that is because they are some what trivial clean-ups and the subject explains the patch. However, typically it is good to have a changelog in the patch no matter how trivial it is. Tony may ask you to add a changelog. Otherwise ... Reviewed-by: Jon Hunter jon-hun...@ti.com Yes please add a changelog. Patches with no changelog have no changelog ;-) My usual workflow is to re-send a whole series, and only add a changelog to the ones that actually change. For instance, for this patchset, the only one that actually changed is ARM: omap2: gpmc: Fix gpmc_cs_reserved() return value. The rest is just the same it was in v1. I like to do it this way, because I think it keeps the patches together, and I hope I make maintainers life easier; of course, I might be wrong. So, should I use a different workflow and send only the patches that change with new versions? Thanks, -- Ezequiel García, Free Electrons Embedded Linux, Kernel and Android Engineering http://free-electrons.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 v2 0/8] ARM: omap2: GPMC cleanup
* Ezequiel Garcia ezequiel.gar...@free-electrons.com [130212 10:29]: On Tue, Feb 12, 2013 at 09:12:53AM -0800, Tony Lindgren wrote: * Jon Hunter jon-hun...@ti.com [130212 08:36]: On 02/12/2013 09:18 AM, Ezequiel Garcia wrote: This patchset is v2 of the small cleanup consisting in: * mark some functions as 'static' when appropriate * remove an unused function from gpmc.c * improve error messages when a CS request fails * migrate to dev_err and dev_warn Changelog from v1: * fix gpmc_cs_reserved to return a boolean instead of an integer error code * add a new patch to the patchset cleaning redundant checks It has been tested on a IGEP v2 board with OneNAND, which means the gpmc-nand patch is tested by compilation only. Altough these patchset is almost trivial, any feedback or testing is more than welcome. Ezequiel Garcia (8): ARM: omap2: gpmc: Mark local scoped functions static ARM: omap2: gpmc: Remove unused gpmc_round_ns_to_ticks() function ARM: omap2: gpmc: Fix gpmc_cs_reserved() return value ARM: omap2: gpmc-nand: Print something useful on CS request failure ARM: omap2: gpmc-onenand: Print something useful on CS request failure ARM: omap2: gpmc-onenand: Replace pr_err() with dev_err() ARM: omap2: gpmc-onenand: Replace printk KERN_ERR with dev_warn() ARM: omap2: gpmc: Remove redundant chip select out of range check arch/arm/mach-omap2/gpmc-nand.c|3 ++- arch/arm/mach-omap2/gpmc-onenand.c |8 +--- arch/arm/mach-omap2/gpmc.c | 27 ++- arch/arm/mach-omap2/gpmc.h |7 --- 4 files changed, 13 insertions(+), 32 deletions(-) Looks good to me. I noticed that for some patches there is no changelog and I understand that that is because they are some what trivial clean-ups and the subject explains the patch. However, typically it is good to have a changelog in the patch no matter how trivial it is. Tony may ask you to add a changelog. Otherwise ... Reviewed-by: Jon Hunter jon-hun...@ti.com Yes please add a changelog. Patches with no changelog have no changelog ;-) My usual workflow is to re-send a whole series, and only add a changelog to the ones that actually change. For instance, for this patchset, the only one that actually changed is ARM: omap2: gpmc: Fix gpmc_cs_reserved() return value. The rest is just the same it was in v1. I like to do it this way, because I think it keeps the patches together, and I hope I make maintainers life easier; of course, I might be wrong. So, should I use a different workflow and send only the patches that change with new versions? Sorry I think there's a misunderstanding here.. Jon and I mean that each patch should have a description in addition to the Subject line even if a trival 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: [PATCH v2 0/8] ARM: omap2: GPMC cleanup
On Tue, Feb 12, 2013 at 10:43:25AM -0800, Tony Lindgren wrote: * Ezequiel Garcia ezequiel.gar...@free-electrons.com [130212 10:29]: On Tue, Feb 12, 2013 at 09:12:53AM -0800, Tony Lindgren wrote: * Jon Hunter jon-hun...@ti.com [130212 08:36]: On 02/12/2013 09:18 AM, Ezequiel Garcia wrote: This patchset is v2 of the small cleanup consisting in: * mark some functions as 'static' when appropriate * remove an unused function from gpmc.c * improve error messages when a CS request fails * migrate to dev_err and dev_warn Changelog from v1: * fix gpmc_cs_reserved to return a boolean instead of an integer error code * add a new patch to the patchset cleaning redundant checks It has been tested on a IGEP v2 board with OneNAND, which means the gpmc-nand patch is tested by compilation only. Altough these patchset is almost trivial, any feedback or testing is more than welcome. Ezequiel Garcia (8): ARM: omap2: gpmc: Mark local scoped functions static ARM: omap2: gpmc: Remove unused gpmc_round_ns_to_ticks() function ARM: omap2: gpmc: Fix gpmc_cs_reserved() return value ARM: omap2: gpmc-nand: Print something useful on CS request failure ARM: omap2: gpmc-onenand: Print something useful on CS request failure ARM: omap2: gpmc-onenand: Replace pr_err() with dev_err() ARM: omap2: gpmc-onenand: Replace printk KERN_ERR with dev_warn() ARM: omap2: gpmc: Remove redundant chip select out of range check arch/arm/mach-omap2/gpmc-nand.c|3 ++- arch/arm/mach-omap2/gpmc-onenand.c |8 +--- arch/arm/mach-omap2/gpmc.c | 27 ++- arch/arm/mach-omap2/gpmc.h |7 --- 4 files changed, 13 insertions(+), 32 deletions(-) Looks good to me. I noticed that for some patches there is no changelog and I understand that that is because they are some what trivial clean-ups and the subject explains the patch. However, typically it is good to have a changelog in the patch no matter how trivial it is. Tony may ask you to add a changelog. Otherwise ... Reviewed-by: Jon Hunter jon-hun...@ti.com Yes please add a changelog. Patches with no changelog have no changelog ;-) My usual workflow is to re-send a whole series, and only add a changelog to the ones that actually change. For instance, for this patchset, the only one that actually changed is ARM: omap2: gpmc: Fix gpmc_cs_reserved() return value. The rest is just the same it was in v1. I like to do it this way, because I think it keeps the patches together, and I hope I make maintainers life easier; of course, I might be wrong. So, should I use a different workflow and send only the patches that change with new versions? Sorry I think there's a misunderstanding here.. Jon and I mean that each patch should have a description in addition to the Subject line even if a trival patch :) Oops, my bad! I'll re-send adding a description to each patch. -- Ezequiel García, Free Electrons Embedded Linux, Kernel and Android Engineering http://free-electrons.com -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3 0/8] ARM: omap2: GPMC cleanup
This patchset is v3 of the small cleanup consisting in: * mark some functions as 'static' when appropriate * remove an unused function from gpmc.c * improve error messages when a CS request fails * migrate to dev_err and dev_warn Changes from v2: * add a commit message to some trivial patches, that omitted it due to author's laziness. Changes from v1: * fix gpmc_cs_reserved to return a boolean instead of an integer error code * add a new patch to the patchset cleaning redundant checks It has been tested on a IGEP v2 board with OneNAND, which means the gpmc-nand patch is tested by compilation only. Altough this patchset is almost trivial, any feedback or testing is more than welcome. Thanks to Jon Hunter for his kind review! Ezequiel Garcia (8): ARM: omap2: gpmc: Mark local scoped functions static ARM: omap2: gpmc: Remove unused gpmc_round_ns_to_ticks() function ARM: omap2: gpmc: Fix gpmc_cs_reserved() return value ARM: omap2: gpmc-nand: Print something useful on CS request failure ARM: omap2: gpmc-onenand: Print something useful on CS request failure ARM: omap2: gpmc-onenand: Replace pr_err() with dev_err() ARM: omap2: gpmc-onenand: Replace printk KERN_ERR with dev_warn() ARM: omap2: gpmc: Remove redundant chip select out of range check arch/arm/mach-omap2/gpmc-nand.c|3 ++- arch/arm/mach-omap2/gpmc-onenand.c |8 +--- arch/arm/mach-omap2/gpmc.c | 27 ++- arch/arm/mach-omap2/gpmc.h |7 --- 4 files changed, 13 insertions(+), 32 deletions(-) -- 1.7.8.6 -- 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/8] ARM: omap2: gpmc: Mark local scoped functions static
This patch marks a bunch of functions that are local
to gpmc.c file only as static.
Signed-off-by: Ezequiel Garcia ezequiel.gar...@free-electrons.com
Reviewed-by: Jon Hunter jon-hun...@ti.com
---
arch/arm/mach-omap2/gpmc.c | 14 +++---
arch/arm/mach-omap2/gpmc.h |7 ---
2 files changed, 7 insertions(+), 14 deletions(-)
diff --git a/arch/arm/mach-omap2/gpmc.c b/arch/arm/mach-omap2/gpmc.c
index 1e8bcb4..ffe3e1e 100644
--- a/arch/arm/mach-omap2/gpmc.c
+++ b/arch/arm/mach-omap2/gpmc.c
@@ -181,7 +181,7 @@ void gpmc_cs_write_reg(int cs, int idx, u32 val)
__raw_writel(val, reg_addr);
}
-u32 gpmc_cs_read_reg(int cs, int idx)
+static u32 gpmc_cs_read_reg(int cs, int idx)
{
void __iomem *reg_addr;
@@ -190,7 +190,7 @@ u32 gpmc_cs_read_reg(int cs, int idx)
}
/* TODO: Add support for gpmc_fck to clock framework and use it */
-unsigned long gpmc_get_fclk_period(void)
+static unsigned long gpmc_get_fclk_period(void)
{
unsigned long rate = clk_get_rate(gpmc_l3_clk);
@@ -205,7 +205,7 @@ unsigned long gpmc_get_fclk_period(void)
return rate;
}
-unsigned int gpmc_ns_to_ticks(unsigned int time_ns)
+static unsigned int gpmc_ns_to_ticks(unsigned int time_ns)
{
unsigned long tick_ps;
@@ -215,7 +215,7 @@ unsigned int gpmc_ns_to_ticks(unsigned int time_ns)
return (time_ns * 1000 + tick_ps - 1) / tick_ps;
}
-unsigned int gpmc_ps_to_ticks(unsigned int time_ps)
+static unsigned int gpmc_ps_to_ticks(unsigned int time_ps)
{
unsigned long tick_ps;
@@ -230,7 +230,7 @@ unsigned int gpmc_ticks_to_ns(unsigned int ticks)
return ticks * gpmc_get_fclk_period() / 1000;
}
-unsigned int gpmc_round_ns_to_ticks(unsigned int time_ns)
+static unsigned int gpmc_round_ns_to_ticks(unsigned int time_ns)
{
unsigned long ticks = gpmc_ns_to_ticks(time_ns);
@@ -448,7 +448,7 @@ static int gpmc_cs_mem_enabled(int cs)
return l GPMC_CONFIG7_CSVALID;
}
-int gpmc_cs_set_reserved(int cs, int reserved)
+static int gpmc_cs_set_reserved(int cs, int reserved)
{
if (cs GPMC_CS_NUM)
return -ENODEV;
@@ -459,7 +459,7 @@ int gpmc_cs_set_reserved(int cs, int reserved)
return 0;
}
-int gpmc_cs_reserved(int cs)
+static int gpmc_cs_reserved(int cs)
{
if (cs GPMC_CS_NUM)
return -ENODEV;
diff --git a/arch/arm/mach-omap2/gpmc.h b/arch/arm/mach-omap2/gpmc.h
index fe0a844..b79e35c 100644
--- a/arch/arm/mach-omap2/gpmc.h
+++ b/arch/arm/mach-omap2/gpmc.h
@@ -195,20 +195,13 @@ extern int gpmc_calc_timings(struct gpmc_timings *gpmc_t,
extern void gpmc_update_nand_reg(struct gpmc_nand_regs *reg, int cs);
extern int gpmc_get_client_irq(unsigned irq_config);
-extern unsigned int gpmc_ns_to_ticks(unsigned int time_ns);
-extern unsigned int gpmc_ps_to_ticks(unsigned int time_ps);
extern unsigned int gpmc_ticks_to_ns(unsigned int ticks);
-extern unsigned int gpmc_round_ns_to_ticks(unsigned int time_ns);
-extern unsigned long gpmc_get_fclk_period(void);
extern void gpmc_cs_write_reg(int cs, int idx, u32 val);
-extern u32 gpmc_cs_read_reg(int cs, int idx);
extern int gpmc_calc_divider(unsigned int sync_clk);
extern int gpmc_cs_set_timings(int cs, const struct gpmc_timings *t);
extern int gpmc_cs_request(int cs, unsigned long size, unsigned long *base);
extern void gpmc_cs_free(int cs);
-extern int gpmc_cs_set_reserved(int cs, int reserved);
-extern int gpmc_cs_reserved(int cs);
extern void omap3_gpmc_save_context(void);
extern void omap3_gpmc_restore_context(void);
extern int gpmc_cs_configure(int cs, int cmd, int wval);
--
1.7.8.6
--
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/8] ARM: omap2: gpmc: Remove unused gpmc_round_ns_to_ticks() function
This function is not used anywhere, so it's safe to remove it.
This means less code to maintain.
Signed-off-by: Ezequiel Garcia ezequiel.gar...@free-electrons.com
Reviewed-by: Jon Hunter jon-hun...@ti.com
---
arch/arm/mach-omap2/gpmc.c |7 ---
1 files changed, 0 insertions(+), 7 deletions(-)
diff --git a/arch/arm/mach-omap2/gpmc.c b/arch/arm/mach-omap2/gpmc.c
index ffe3e1e..bd3bc93 100644
--- a/arch/arm/mach-omap2/gpmc.c
+++ b/arch/arm/mach-omap2/gpmc.c
@@ -230,13 +230,6 @@ unsigned int gpmc_ticks_to_ns(unsigned int ticks)
return ticks * gpmc_get_fclk_period() / 1000;
}
-static unsigned int gpmc_round_ns_to_ticks(unsigned int time_ns)
-{
- unsigned long ticks = gpmc_ns_to_ticks(time_ns);
-
- return ticks * gpmc_get_fclk_period() / 1000;
-}
-
static unsigned int gpmc_ticks_to_ps(unsigned int ticks)
{
return ticks * gpmc_get_fclk_period();
--
1.7.8.6
--
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 3/8] ARM: omap2: gpmc: Fix gpmc_cs_reserved() return value
Currently gpmc_cs_reserved() return value is somewhat inconsistent,
returning a negative value on an error condition, a positive value
if the chip select is reserved and zero if it's available.
Fix this by returning a boolean value as the function name suggests:
* true if the chip select is reserved,
* false if it's available
Suggested-by: Felipe Balbi ba...@ti.com
Signed-off-by: Ezequiel Garcia ezequiel.gar...@free-electrons.com
Reviewed-by: Jon Hunter jon-hun...@ti.com
---
Changelog from v1:
* As suggested by Felipe Balbi, fix return code to a boolean
arch/arm/mach-omap2/gpmc.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach-omap2/gpmc.c b/arch/arm/mach-omap2/gpmc.c
index bd3bc93..fa4764f 100644
--- a/arch/arm/mach-omap2/gpmc.c
+++ b/arch/arm/mach-omap2/gpmc.c
@@ -452,10 +452,10 @@ static int gpmc_cs_set_reserved(int cs, int reserved)
return 0;
}
-static int gpmc_cs_reserved(int cs)
+static bool gpmc_cs_reserved(int cs)
{
if (cs GPMC_CS_NUM)
- return -ENODEV;
+ return true;
return gpmc_cs_map (1 cs);
}
--
1.7.8.6
--
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 4/8] ARM: omap2: gpmc-nand: Print something useful on CS request failure
If CS request fails the current error message is rather unhelpful.
Fix it by printing the failing chip select and the error code.
Signed-off-by: Ezequiel Garcia ezequiel.gar...@free-electrons.com
Reviewed-by: Jon Hunter jon-hun...@ti.com
---
arch/arm/mach-omap2/gpmc-nand.c |3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-omap2/gpmc-nand.c b/arch/arm/mach-omap2/gpmc-nand.c
index afc1e8c..e50e438 100644
--- a/arch/arm/mach-omap2/gpmc-nand.c
+++ b/arch/arm/mach-omap2/gpmc-nand.c
@@ -122,7 +122,8 @@ int gpmc_nand_init(struct omap_nand_platform_data
*gpmc_nand_data,
err = gpmc_cs_request(gpmc_nand_data-cs, NAND_IO_SIZE,
(unsigned long *)gpmc_nand_resource[0].start);
if (err 0) {
- dev_err(dev, Cannot request GPMC CS\n);
+ dev_err(dev, Cannot request GPMC CS %d, error %d\n,
+ gpmc_nand_data-cs, err);
return err;
}
--
1.7.8.6
--
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 5/8] ARM: omap2: gpmc-onenand: Print something useful on CS request failure
If CS request fails the current error message is rather unhelpful.
Fix it by printing the failing chip select and the error code.
Signed-off-by: Ezequiel Garcia ezequiel.gar...@free-electrons.com
Reviewed-by: Jon Hunter jon-hun...@ti.com
---
arch/arm/mach-omap2/gpmc-onenand.c |3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-omap2/gpmc-onenand.c
b/arch/arm/mach-omap2/gpmc-onenand.c
index fadd8743..0ee5317 100644
--- a/arch/arm/mach-omap2/gpmc-onenand.c
+++ b/arch/arm/mach-omap2/gpmc-onenand.c
@@ -379,7 +379,8 @@ void gpmc_onenand_init(struct omap_onenand_platform_data
*_onenand_data)
err = gpmc_cs_request(gpmc_onenand_data-cs, ONENAND_IO_SIZE,
(unsigned long *)gpmc_onenand_resource.start);
if (err 0) {
- pr_err(%s: Cannot request GPMC CS\n, __func__);
+ pr_err(%s: Cannot request GPMC CS %d, error %d\n,
+ __func__, gpmc_onenand_data-cs, err);
return;
}
--
1.7.8.6
--
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 6/8] ARM: omap2: gpmc-onenand: Replace pr_err() with dev_err()
Do this becasue dev_err() is preferred over pr_err() and because
it will match gpmc-nand, thus the code shows looks more consistent.
Signed-off-by: Ezequiel Garcia ezequiel.gar...@free-electrons.com
Reviewed-by: Jon Hunter jon-hun...@ti.com
---
arch/arm/mach-omap2/gpmc-onenand.c |7 ---
1 files changed, 4 insertions(+), 3 deletions(-)
diff --git a/arch/arm/mach-omap2/gpmc-onenand.c
b/arch/arm/mach-omap2/gpmc-onenand.c
index 0ee5317..4771945 100644
--- a/arch/arm/mach-omap2/gpmc-onenand.c
+++ b/arch/arm/mach-omap2/gpmc-onenand.c
@@ -359,6 +359,7 @@ static int gpmc_onenand_setup(void __iomem *onenand_base,
int *freq_ptr)
void gpmc_onenand_init(struct omap_onenand_platform_data *_onenand_data)
{
int err;
+ struct device *dev = gpmc_onenand_device.dev;
gpmc_onenand_data = _onenand_data;
gpmc_onenand_data-onenand_setup = gpmc_onenand_setup;
@@ -379,8 +380,8 @@ void gpmc_onenand_init(struct omap_onenand_platform_data
*_onenand_data)
err = gpmc_cs_request(gpmc_onenand_data-cs, ONENAND_IO_SIZE,
(unsigned long *)gpmc_onenand_resource.start);
if (err 0) {
- pr_err(%s: Cannot request GPMC CS %d, error %d\n,
- __func__, gpmc_onenand_data-cs, err);
+ dev_err(dev, Cannot request GPMC CS %d, error %d\n,
+ gpmc_onenand_data-cs, err);
return;
}
@@ -388,7 +389,7 @@ void gpmc_onenand_init(struct omap_onenand_platform_data
*_onenand_data)
ONENAND_IO_SIZE - 1;
if (platform_device_register(gpmc_onenand_device) 0) {
- pr_err(%s: Unable to register OneNAND device\n, __func__);
+ dev_err(dev, Unable to register OneNAND device\n);
gpmc_cs_free(gpmc_onenand_data-cs);
return;
}
--
1.7.8.6
--
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 7/8] ARM: omap2: gpmc-onenand: Replace printk KERN_ERR with dev_warn()
Since the condition is not an error but a warning, replace
printk KERN_ERR with dev_warn.
Signed-off-by: Ezequiel Garcia ezequiel.gar...@free-electrons.com
Reviewed-by: Jon Hunter jon-hun...@ti.com
---
arch/arm/mach-omap2/gpmc-onenand.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-omap2/gpmc-onenand.c
b/arch/arm/mach-omap2/gpmc-onenand.c
index 4771945..fd6e35b 100644
--- a/arch/arm/mach-omap2/gpmc-onenand.c
+++ b/arch/arm/mach-omap2/gpmc-onenand.c
@@ -367,7 +367,7 @@ void gpmc_onenand_init(struct omap_onenand_platform_data
*_onenand_data)
if (cpu_is_omap24xx()
(gpmc_onenand_data-flags ONENAND_SYNC_READWRITE)) {
- printk(KERN_ERR Onenand using only SYNC_READ on 24xx\n);
+ dev_warn(dev, OneNAND using only SYNC_READ on 24xx\n);
gpmc_onenand_data-flags = ~ONENAND_SYNC_READWRITE;
gpmc_onenand_data-flags |= ONENAND_SYNC_READ;
}
--
1.7.8.6
--
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 8/8] ARM: omap2: gpmc: Remove redundant chip select out of range check
This check is done before the call to gpmc_cs_reserved() and
gpmc_cs_set_reserved() and it's redundant to do it again in each
function. This simplifies the code a bit.
Signed-off-by: Ezequiel Garcia ezequiel.gar...@free-electrons.com
Reviewed-by: Jon Hunter jon-hun...@ti.com
---
arch/arm/mach-omap2/gpmc.c | 10 +-
1 files changed, 1 insertions(+), 9 deletions(-)
diff --git a/arch/arm/mach-omap2/gpmc.c b/arch/arm/mach-omap2/gpmc.c
index fa4764f..0201ea9 100644
--- a/arch/arm/mach-omap2/gpmc.c
+++ b/arch/arm/mach-omap2/gpmc.c
@@ -441,22 +441,14 @@ static int gpmc_cs_mem_enabled(int cs)
return l GPMC_CONFIG7_CSVALID;
}
-static int gpmc_cs_set_reserved(int cs, int reserved)
+static void gpmc_cs_set_reserved(int cs, int reserved)
{
- if (cs GPMC_CS_NUM)
- return -ENODEV;
-
gpmc_cs_map = ~(1 cs);
gpmc_cs_map |= (reserved ? 1 : 0) cs;
-
- return 0;
}
static bool gpmc_cs_reserved(int cs)
{
- if (cs GPMC_CS_NUM)
- return true;
-
return gpmc_cs_map (1 cs);
}
--
1.7.8.6
--
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 10/13] mailbox: create dbx500 mailbox driver
Hi Mark,
Thanks for your comments.
On 02/12/2013 11:39 AM, Mark Rutland wrote:
Hello,
I have a few comments on the devicetree binding and the way it's parsed.
+static const struct of_device_id dbx500_mailbox_match[] = {
+ { .compatible = stericsson,db8500-mailbox,
+ .data = (void *)db8500_mboxes,
+ },
+ { .compatible = stericsson,db9540-mailbox,
+ .data = (void *)dbx540_mboxes,
+ },
+ { /* sentinel */}
+};
+
The binding for the compatible strings above and property parsing below should
be documented.
Yes you're right. I will add a description in
Documentation/devicetree/bindings/mailbox/...
+static int dbx500_mbox_probe(struct platform_device *pdev)
+{
+ const struct platform_device_id *platid =
platform_get_device_id(pdev);
+ struct resource *mem;
+ int ret, i, legacy_offset = 0, upap_offset;
+ struct mailbox **list;
+ int irq;
+ struct dbx500_plat_data *pdata = dev_get_platdata(pdev-dev);
+ struct device_node *np = pdev-dev.of_node;
+
+ if (!pdata) {
+ if (np) {
+ of_property_read_u32(np, legacy-offset,
+legacy_offset);
I see that legacy_offset is initialised to 0, and there's no check on the
return value of of_property_read_u32. Does that mean this is an optional
property? This needs to be documented.
Correct, I'll add a check. This offset must be compared to shared memory
size.
+ of_property_read_u32(np, upap-offset,upap_offset);
However, upap_offset isn't initialised, but there's no check on the return
value. If upap-offset isn't defined in the dt, upap_offset won't have been
initialised.
Should be documented too. upap_offset is optional since not supported by
all STE platforms.
Anyway, value must be checked when used.
Is there no basic sanity checking that could be done here? I assume there's a
maximum offset we expect that's less than 4GB?
Additionally, of_property_read_u32 takes a *u32, not *int. It would be nice to
be consistent with the interface.
OK
I'm not familiar with the hardware. What's the difference between the legacy
and upap cases?
Same HW, but different way to access and manage shared memory.
Link to coprocessor firmware version.
+ list = (struct mailbox **)of_match_device(
+
dbx500_mailbox_match,pdev-dev)-data;
+ if (!list) {
+ /* No mailbox configuration */
+ dev_err(pdev-dev, No configuration
found\n);
+ return -ENODEV;
+ }
+ } else {
+ /* No mailbox configuration */
+ dev_err(pdev-dev, No configuration found\n);
+ return -ENODEV;
+ }
+ } else {
+ list = (struct mailbox **)platid-driver_data;
+ legacy_offset = pdata-legacy_offset;
+ upap_offset = pdata-upap_offset;
+ }
+
+ mem = platform_get_resource_byname(pdev, IORESOURCE_MEM, prcm_reg);
Does this work for dt? I wasn't aware we got anything more than anonymous
memory and interrupts.
Yes this is working with and without dt.
dt declaration will be the following
mailbox {
compatible = stericsson,db8500-mailbox;
reg = 0x80157000 0x1000, 0x801B8000 0x2000;
reg-names = prcm-reg, prcmu-tcdm;
interrupts = 0 47 0x4;
interrupt-names = irq;
legacy-offset = 0xdd4;
};
+ mbox_base = devm_ioremap(pdev-dev, mem-start, resource_size(mem));
+ if (!mbox_base) {
+ ret = -ENOMEM;
+ goto out;
+ }
+
+ mem = platform_get_resource_byname(pdev, IORESOURCE_MEM,
prcmu_tcdm);
Same here.
Thanks,
Mark.
Regards,
Loic--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] ARM: OMAP4: PM: fix PM regression introduced by recent clock cleanup
Commit 17b7e7d33530e2bbd3bdc90f4db09b91cfdde2bb (ARM: OMAP4:
clock/hwmod data: start to remove some IP block control clocks)
introduced a regression preventing the L3INIT clockdomain of OMAP4
systems from entering idle. This in turn prevented these systems from
entering full chip clock-stop.
The regression was caused by the incorrect removal of a so-called
optional functional clock from the OMAP4 clock data. This wasn't
caught for two reasons. First, I missed the retention entry failure
in the branch test logs:
http://www.pwsan.com/omap/testlogs/cleanup_a_3.9/20130126014242/pm/4460pandaes/4460pandaes_log.txt
Second, the integration data for the OCP2SCP PHY IP block, added by
commit 0c6688753f9912c6a7013549ec31c8844020bbc1 (ARM: OMAP4: hwmod
data: add remaining USB-related IP blocks), should have associated this
clock with the IP block, but did not.
Fix by adding back the so-called optional functional clock to the
clock data, and by linking that clock to the OCP2SCP PHY IP block
integration hwmod data.
The problem patch was discovered by J, Keerthy j-keer...@ti.com.
Cc: Keerthy j-keer...@ti.com
Cc: Benoît Cousson b-cous...@ti.com
Signed-off-by: Paul Walmsley p...@pwsan.com
---
It'd be nice, but certainly not necessary, to get this in for the v3.9
merge window. Otherwise, will send it for -rc1.
arch/arm/mach-omap2/cclock44xx_data.c |5 +
arch/arm/mach-omap2/omap_hwmod_44xx_data.c |6 ++
2 files changed, 11 insertions(+)
diff --git a/arch/arm/mach-omap2/cclock44xx_data.c
b/arch/arm/mach-omap2/cclock44xx_data.c
index cebe2b3..54ebb89 100644
--- a/arch/arm/mach-omap2/cclock44xx_data.c
+++ b/arch/arm/mach-omap2/cclock44xx_data.c
@@ -1000,6 +1000,10 @@ DEFINE_CLK_OMAP_MUX(hsmmc2_fclk, l3_init_clkdm,
hsmmc1_fclk_sel,
OMAP4430_CM_L3INIT_MMC2_CLKCTRL, OMAP4430_CLKSEL_MASK,
hsmmc1_fclk_parents, func_dmic_abe_gfclk_ops);
+DEFINE_CLK_GATE(ocp2scp_usb_phy_phy_48m, func_48m_fclk, func_48m_fclk, 0x0,
+ OMAP4430_CM_L3INIT_USBPHYOCP2SCP_CLKCTRL,
+ OMAP4430_OPTFCLKEN_PHY_48M_SHIFT, 0x0, NULL);
+
DEFINE_CLK_GATE(sha2md5_fck, l3_div_ck, l3_div_ck, 0x0,
OMAP4430_CM_L4SEC_SHA2MD51_CLKCTRL,
OMAP4430_MODULEMODE_SWCTRL_SHIFT, 0x0, NULL);
@@ -1527,6 +1531,7 @@ static struct omap_clk omap44xx_clks[] = {
CLK(NULL, per_mcbsp4_gfclk,
per_mcbsp4_gfclk, CK_443X),
CLK(NULL, hsmmc1_fclk, hsmmc1_fclk,
CK_443X),
CLK(NULL, hsmmc2_fclk, hsmmc2_fclk,
CK_443X),
+ CLK(NULL, ocp2scp_usb_phy_phy_48m,
ocp2scp_usb_phy_phy_48m, CK_443X),
CLK(NULL, sha2md5_fck, sha2md5_fck,
CK_443X),
CLK(NULL, slimbus1_fclk_1, slimbus1_fclk_1,
CK_443X),
CLK(NULL, slimbus1_fclk_0, slimbus1_fclk_0,
CK_443X),
diff --git a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
index a1849a8..d55c769 100644
--- a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
@@ -2720,6 +2720,10 @@ static struct omap_ocp2scp_dev ocp2scp_dev_attr[] = {
{ }
};
+static struct omap_hwmod_opt_clk ocp2scp_usb_phy_opt_clks[] = {
+ { .role = 48mhz, .clk = ocp2scp_usb_phy_phy_48m },
+};
+
/* ocp2scp_usb_phy */
static struct omap_hwmod omap44xx_ocp2scp_usb_phy_hwmod = {
.name = ocp2scp_usb_phy,
@@ -2734,6 +2738,8 @@ static struct omap_hwmod omap44xx_ocp2scp_usb_phy_hwmod =
{
},
},
.dev_attr = ocp2scp_dev_attr,
+ .opt_clks = ocp2scp_usb_phy_opt_clks,
+ .opt_clks_cnt = ARRAY_SIZE(ocp2scp_usb_phy_opt_clks),
};
/*
--
1.7.10.4
RE: [PATCH] ARM: OMAP: Clock: Remove CK_* flags
On Tue, 12 Feb 2013, J, KEERTHY wrote: Heh :-). It narrowed down to this patch: commit 17b7e7d33530e2bbd3bdc90f4db09b91cfdde2bb Author: Paul Walmsley p...@pwsan.com Date: Sat Jan 26 00:48:54 2013 -0700 ARM: OMAP4: clock/hwmod data: start to remove some IP block control clocks Thanks, this fixes it: http://marc.info/?l=linux-omapm=136070089529743w=2 But at this point, I've rescheduled your patch to the 3.10-cleanup time frame, since we're pretty close to the 3.9 merge window. - 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
Re: [PATCH] usb: musb: fix context save over suspend.
NeilBrown ne...@suse.de writes: On Mon, 21 Jan 2013 13:38:59 +0200 Igor Grinberg grinb...@compulab.co.il wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi Neil, On 01/21/13 11:28, NeilBrown wrote: The standard suspend sequence involves runtime_resuming devices before suspending the system. So just saving context in runtime_suspend and restoring it in runtime resume isn't enough. We must also save in suspend and restore in resume. Without this patch, and OMAP3 system with off_mode enabled will find the musb port non-functional after suspend/resume. With the patch it works perfectly. Hmmm... Some time ago, this has been removed in 5d193ce8 (usb: musb: PM: fix context save/restore in suspend/resume path) Am I missing something? Or things changed and now this patch is correct? Hi Igor, thanks for alerting me to that patch does anyone else get the feeling that power management to too complex to be understood by a mere human? Yes. ;) That commit (5d193ce8) suggests that the musb-hdrc device is an 'omap_device', or maybe has a PM domain set to something else. However it isn't/doesn't. dev-pm_domain is NULL. So no PM domain layer will ever call the musb_core musb_runtime_suspend/resume. The parent device - musb-omap2430 - is an omap device, does have pm_domain set, and does have its omap2430_runtime_suspend/resume called for system suspend and so the context for that device is saved and restored. However that doesn't help the context for musb-hdrc. Whether musb ever was an omap_device is beyond my archaeological skills to determine. Kevin: Was musb-hdrc ever a device with a pm_domain? or was it only ever the various possible parents that had domains? Are you able to defend your earlier patch in today's kernel? It certainly causes my device not to work properly. Sorry for the delay here, I'm back to a place where I can test this on real hardware. My patch was fixing a real hang when musb was built-in (or loaded), in host-mode (mini-A cable attached) but no devices attached. I just tried to reproduce this, and with your patch, the system hangs during suspend. That being said, your description makes sense why this context save/restore is needed. Perhaps your patch needs to add a check whether the device is runtime suspended (I gather this is what Ruslan's patch is doing.) Kevin -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/3] Dual EMAC mode implementation of CPSW
From: Mugunthan V N mugunthan...@ti.com Date: Tue, 12 Feb 2013 01:22:17 +0530 This patch series implements Dual EMAC mode implementation of CPSW which acts as two standalone EMAC by segregating the switch using VIDs and port VLAN Mugunthan V N (3): driver: net: ethernet: davinci_cpdma: add support for directed packet and source port detection driver: net: ethernet: cpsw: make cpts as pointer driver: net: ethernet: cpsw: dual emac interface implementation Series applied. -- 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+: SmartReflex: soc.h is needed for omap initcalls
commit aa4f99638b (ARM: OMAP2+: Use omap initcalls) converted
the initcalls here, but did not #include soc.h where the omap
inicalls are defined.
To fix, #include soc.h
Signed-off-by: Kevin Hilman khil...@linaro.org
---
Tony, the patch that broke this was introduced in your
omap-for-v3.9/multiplatform-enable-signed branch, and this problem was
found only when compiling with PM (specifically, SmartReflex) enabled.
arch/arm/mach-omap2/smartreflex-class3.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm/mach-omap2/smartreflex-class3.c
b/arch/arm/mach-omap2/smartreflex-class3.c
index 80f3acb..b2dcbd3 100644
--- a/arch/arm/mach-omap2/smartreflex-class3.c
+++ b/arch/arm/mach-omap2/smartreflex-class3.c
@@ -13,6 +13,7 @@
#include linux/power/smartreflex.h
#include voltage.h
+#include soc.h
static int sr_class3_enable(struct omap_sr *sr)
{
--
1.8.1.2
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: OMAP1: fix USB host on 1710
Hi, On Fri, Jan 25, 2013 at 08:10:05AM +, Paul Walmsley wrote: On Fri, 25 Jan 2013, Aaro Koskinen wrote: There is a long-standing bug that OHCI USB host controller does not respond on 1710, because of wrong clock definitions. See e.g. http://marc.info/?l=linux-omapm=119634441229321w=2. All register reads return just zeroes: Thanks, queued for v3.8-rc fixes. What happened to this patch? Will it go to 3.9? A. -- 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 1/5] omap SoC related late changes for v3.9 merge window
On Tue, Feb 12, 2013 at 10:11:01AM -0800, Tony Lindgren wrote: The following changes since commit 88b62b915b0b7e25870eb0604ed9a92ba4bfc9f7: Linux 3.8-rc6 (2013-02-01 12:08:14 +1100) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap tags/omap-for-v3.9/soc-signed Pulled 1-5 into a late/omap branch. As usual with late branches, there's no commitment that we'll be able to merge it, but we'll do best-effort depending on how the merge window turns out. -Olof -- 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: OMAP1: fix USB host on 1710
Hi Aaro, Tony, On Wed, 13 Feb 2013, Aaro Koskinen wrote: On Fri, Jan 25, 2013 at 08:10:05AM +, Paul Walmsley wrote: On Fri, 25 Jan 2013, Aaro Koskinen wrote: There is a long-standing bug that OHCI USB host controller does not respond on 1710, because of wrong clock definitions. See e.g. http://marc.info/?l=linux-omapm=119634441229321w=2. All register reads return just zeroes: Thanks, queued for v3.8-rc fixes. What happened to this patch? I didn't send any more v3.8-rc fixes after you posted your patch, due to: http://www.spinics.net/lists/arm-kernel/msg221817.html Will it go to 3.9? Yep, it's queued for early v3.9-rc. - 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
Re: [PATCH] ARM: OMAP1: fix USB host on 1710
On Tue, Feb 12, 2013 at 11:54:36PM +, Paul Walmsley wrote: I didn't send any more v3.8-rc fixes after you posted your patch, due to: http://www.spinics.net/lists/arm-kernel/msg221817.html Will it go to 3.9? Yep, it's queued for early v3.9-rc. Great, thanks, A. -- 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] usb: musb: fix context save over suspend.
On Tue, 12 Feb 2013 13:03:36 -0800 Kevin Hilman khil...@linaro.org wrote: NeilBrown ne...@suse.de writes: On Mon, 21 Jan 2013 13:38:59 +0200 Igor Grinberg grinb...@compulab.co.il wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi Neil, On 01/21/13 11:28, NeilBrown wrote: The standard suspend sequence involves runtime_resuming devices before suspending the system. So just saving context in runtime_suspend and restoring it in runtime resume isn't enough. We must also save in suspend and restore in resume. Without this patch, and OMAP3 system with off_mode enabled will find the musb port non-functional after suspend/resume. With the patch it works perfectly. Hmmm... Some time ago, this has been removed in 5d193ce8 (usb: musb: PM: fix context save/restore in suspend/resume path) Am I missing something? Or things changed and now this patch is correct? Hi Igor, thanks for alerting me to that patch does anyone else get the feeling that power management to too complex to be understood by a mere human? Yes. ;) That commit (5d193ce8) suggests that the musb-hdrc device is an 'omap_device', or maybe has a PM domain set to something else. However it isn't/doesn't. dev-pm_domain is NULL. So no PM domain layer will ever call the musb_core musb_runtime_suspend/resume. The parent device - musb-omap2430 - is an omap device, does have pm_domain set, and does have its omap2430_runtime_suspend/resume called for system suspend and so the context for that device is saved and restored. However that doesn't help the context for musb-hdrc. Whether musb ever was an omap_device is beyond my archaeological skills to determine. Kevin: Was musb-hdrc ever a device with a pm_domain? or was it only ever the various possible parents that had domains? Are you able to defend your earlier patch in today's kernel? It certainly causes my device not to work properly. Sorry for the delay here, I'm back to a place where I can test this on real hardware. My patch was fixing a real hang when musb was built-in (or loaded), in host-mode (mini-A cable attached) but no devices attached. I just tried to reproduce this, and with your patch, the system hangs during suspend. Odd. I plug in a mini-A cable, note that the 'mode' file holds 'a_idle' (sometimes just plugging in the cable isn't enough to trigger that, but sometimes it is) and suspend/resume work perfectly. Though after resume it is back to b_idle. unplug/replug and it is back to a_idle. suspend/resume and back to b_idle. That being said, your description makes sense why this context save/restore is needed. Perhaps your patch needs to add a check whether the device is runtime suspended (I gather this is what Ruslan's patch is doing.) I'm not sure it is possible for the device to be runtime suspended at this point. Certainly my device never is, even if it was just before the suspend sequence started. Something is waking it up... (instruments the code). Ahh - usb_suspend() calls choose_wakeup() which might call pm_runtime_resume() if the could be a need to reprogram the wakeup setting. As that is a 'might', the device might not be runtime-awake when 'suspend' runs. Can you see if this, on top of my previous patch, does any better on your hardware? Thanks, NeilBrown diff --git a/drivers/usb/musb/musb_core.c b/drivers/usb/musb/musb_core.c index 956db0e..00deb94 100644 --- a/drivers/usb/musb/musb_core.c +++ b/drivers/usb/musb/musb_core.c @@ -2278,7 +2278,8 @@ static int musb_suspend(struct device *dev) } spin_unlock_irqrestore(musb-lock, flags); - musb_save_context(musb); + if (!pm_runtime_status_suspended(dev)) + musb_save_context(musb); return 0; } @@ -2289,7 +2290,8 @@ static int musb_resume_noirq(struct device *dev) * module got reset through the PSC (vs just being disabled). */ struct musb *musb = dev_to_musb(dev); - musb_restore_context(musb); + if (!pm_runtime_status_suspended(dev)) + musb_restore_context(musb); return 0; } signature.asc Description: PGP signature
Re: [GIT PULL 1/5] omap SoC related late changes for v3.9 merge window
* Olof Johansson o...@lixom.net [130212 15:40]: On Tue, Feb 12, 2013 at 10:11:01AM -0800, Tony Lindgren wrote: The following changes since commit 88b62b915b0b7e25870eb0604ed9a92ba4bfc9f7: Linux 3.8-rc6 (2013-02-01 12:08:14 +1100) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap tags/omap-for-v3.9/soc-signed Pulled 1-5 into a late/omap branch. As usual with late branches, there's no commitment that we'll be able to merge it, but we'll do best-effort depending on how the merge window turns out. Thanks yes totally understood. 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: OMAP2+: SmartReflex: soc.h is needed for omap initcalls
* Kevin Hilman khil...@linaro.org [130212 14:27]:
commit aa4f99638b (ARM: OMAP2+: Use omap initcalls) converted
the initcalls here, but did not #include soc.h where the omap
inicalls are defined.
To fix, #include soc.h
Thanks, this should be already fixed in arm-soc/for-next. I might
have forgotten to merge these into omap-for-v3.9/tmp-merge though.
Regards,
Tony
Signed-off-by: Kevin Hilman khil...@linaro.org
---
Tony, the patch that broke this was introduced in your
omap-for-v3.9/multiplatform-enable-signed branch, and this problem was
found only when compiling with PM (specifically, SmartReflex) enabled.
arch/arm/mach-omap2/smartreflex-class3.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm/mach-omap2/smartreflex-class3.c
b/arch/arm/mach-omap2/smartreflex-class3.c
index 80f3acb..b2dcbd3 100644
--- a/arch/arm/mach-omap2/smartreflex-class3.c
+++ b/arch/arm/mach-omap2/smartreflex-class3.c
@@ -13,6 +13,7 @@
#include linux/power/smartreflex.h
#include voltage.h
+#include soc.h
static int sr_class3_enable(struct omap_sr *sr)
{
--
1.8.1.2
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] usb: musb: fix context save over suspend.
NeilBrown ne...@suse.de writes: On Tue, 12 Feb 2013 13:03:36 -0800 Kevin Hilman khil...@linaro.org wrote: NeilBrown ne...@suse.de writes: [...] My patch was fixing a real hang when musb was built-in (or loaded), in host-mode (mini-A cable attached) but no devices attached. I just tried to reproduce this, and with your patch, the system hangs during suspend. Odd. I plug in a mini-A cable, note that the 'mode' file holds 'a_idle' (sometimes just plugging in the cable isn't enough to trigger that, but sometimes it is) and suspend/resume work perfectly. Though after resume it is back to b_idle. unplug/replug and it is back to a_idle. suspend/resume and back to b_idle. That being said, your description makes sense why this context save/restore is needed. Perhaps your patch needs to add a check whether the device is runtime suspended (I gather this is what Ruslan's patch is doing.) I'm not sure it is possible for the device to be runtime suspended at this point. Certainly my device never is, even if it was just before the suspend sequence started. Something is waking it up... (instruments the code). Ahh - usb_suspend() calls choose_wakeup() which might call pm_runtime_resume() if the could be a need to reprogram the wakeup setting. As that is a 'might', the device might not be runtime-awake when 'suspend' runs. Can you see if this, on top of my previous patch, does any better on your hardware? Yes, this patch adding the check on top of your previous one makes things work just fine on my hardware (3530/Overo). Kevin Thanks, NeilBrown diff --git a/drivers/usb/musb/musb_core.c b/drivers/usb/musb/musb_core.c index 956db0e..00deb94 100644 --- a/drivers/usb/musb/musb_core.c +++ b/drivers/usb/musb/musb_core.c @@ -2278,7 +2278,8 @@ static int musb_suspend(struct device *dev) } spin_unlock_irqrestore(musb-lock, flags); - musb_save_context(musb); + if (!pm_runtime_status_suspended(dev)) + musb_save_context(musb); return 0; } @@ -2289,7 +2290,8 @@ static int musb_resume_noirq(struct device *dev) * module got reset through the PSC (vs just being disabled). */ struct musb *musb = dev_to_musb(dev); - musb_restore_context(musb); + if (!pm_runtime_status_suspended(dev)) + musb_restore_context(musb); 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
RE: [PATCH] ARM: OMAP: Clock: Remove CK_* flags
-Original Message- From: Paul Walmsley [mailto:p...@pwsan.com] Sent: Wednesday, February 13, 2013 2:19 AM To: J, KEERTHY Cc: linux-omap@vger.kernel.org; linux-arm-ker...@lists.infradead.org Subject: RE: [PATCH] ARM: OMAP: Clock: Remove CK_* flags On Tue, 12 Feb 2013, J, KEERTHY wrote: Heh :-). It narrowed down to this patch: commit 17b7e7d33530e2bbd3bdc90f4db09b91cfdde2bb Author: Paul Walmsley p...@pwsan.com Date: Sat Jan 26 00:48:54 2013 -0700 ARM: OMAP4: clock/hwmod data: start to remove some IP block control clocks Thanks, this fixes it: http://marc.info/?l=linux-omapm=136070089529743w=2 Ok. Cool. But at this point, I've rescheduled your patch to the 3.10-cleanup time frame, since we're pretty close to the 3.9 merge window. So the patch needs to be rebased after 3.9 right? - 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
Re: [PATCH] ARM: OMAP4: PM: Avoid expensive cpu_suspend() path for all CPU power states except off
On Tuesday 12 February 2013 08:48 PM, Kevin Hilman wrote: Santosh Shilimkar santosh.shilim...@ti.com writes: On Saturday 09 February 2013 02:49 AM, Kevin Hilman wrote: Santosh Shilimkar santosh.shilim...@ti.com writes: Current CPU PM code code make use of common cpu_suspend() path for all the CPU power states which is not optimal. In fact cpu_suspend() path is needed only when we put CPU power domain to off state where the CPU context is lost. Update the code accordingly so that the expensive cpu_suspend() path can be avoided for the shallow CPU power states like CPU PD INA/CSWR. Cc: Kevin Hilman khil...@deeprootsystems.com Reported-by: Richard Woodruff r-woodru...@ti.com Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com Looks OK at first glance, but are you sure this is right for the various ways both clusters might idle using coupled CPUidle? Yes it is perfectly safe from all C-states. This patch has been part of the OMAP4/OMAP5 product port for some time. I forgot to send it upstream some how :( Some description of the testing would be helpful here. Sorry. Should have mentioned it in first place. Patch is being tested on OMAP4430 (idle/suspend) and OMAP5 with few out of tree patches. OK, please update changelog with a brief description of how it was tested, and on which platforms. Will update the changelog and post it 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
[PATCH] ASoC: omap-mcpdm: Clean up with devm_* function
Clean up McPDM driver with devm_ function.
Signed-off-by: Sebastien Guiriec s-guir...@ti.com
---
sound/soc/omap/omap-mcpdm.c | 14 +-
1 file changed, 5 insertions(+), 9 deletions(-)
diff --git a/sound/soc/omap/omap-mcpdm.c b/sound/soc/omap/omap-mcpdm.c
index 5ca11bd..079f277 100644
--- a/sound/soc/omap/omap-mcpdm.c
+++ b/sound/soc/omap/omap-mcpdm.c
@@ -369,7 +369,7 @@ static int omap_mcpdm_probe(struct snd_soc_dai *dai)
pm_runtime_get_sync(mcpdm-dev);
omap_mcpdm_write(mcpdm, MCPDM_REG_CTRL, 0x00);
- ret = request_irq(mcpdm-irq, omap_mcpdm_irq_handler,
+ ret = devm_request_irq(mcpdm-dev, mcpdm-irq, omap_mcpdm_irq_handler,
0, McPDM, (void *)mcpdm);
pm_runtime_put_sync(mcpdm-dev);
@@ -389,7 +389,6 @@ static int omap_mcpdm_remove(struct snd_soc_dai *dai)
{
struct omap_mcpdm *mcpdm = snd_soc_dai_get_drvdata(dai);
- free_irq(mcpdm-irq, (void *)mcpdm);
pm_runtime_disable(mcpdm-dev);
return 0;
@@ -465,14 +464,11 @@ static int asoc_mcpdm_probe(struct platform_device *pdev)
if (res == NULL)
return -ENOMEM;
- if (!devm_request_mem_region(pdev-dev, res-start,
-resource_size(res), McPDM))
- return -EBUSY;
-
- mcpdm-io_base = devm_ioremap(pdev-dev, res-start,
- resource_size(res));
- if (!mcpdm-io_base)
+ mcpdm-io_base = devm_request_and_ioremap(pdev-dev, res);
+ if (!mcpdm-io_base) {
+ dev_err(pdev-dev, cannot remap\n);
return -ENOMEM;
+ }
mcpdm-irq = platform_get_irq(pdev, 0);
if (mcpdm-irq 0)
--
1.7.10.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] ASoC: omap-dmic: Clean up with devm_request_and_ioremap
Clean up dmic code with devm_request_and_ioremap function.
Signed-off-by: Sebastien Guiriec s-guir...@ti.com
---
sound/soc/omap/omap-dmic.c | 11 ++-
1 file changed, 2 insertions(+), 9 deletions(-)
diff --git a/sound/soc/omap/omap-dmic.c b/sound/soc/omap/omap-dmic.c
index ba49ccd..77e9e7e 100644
--- a/sound/soc/omap/omap-dmic.c
+++ b/sound/soc/omap/omap-dmic.c
@@ -493,16 +493,9 @@ static int asoc_dmic_probe(struct platform_device *pdev)
goto err_put_clk;
}
- if (!devm_request_mem_region(pdev-dev, res-start,
-resource_size(res), pdev-name)) {
- dev_err(dmic-dev, memory region already claimed\n);
- ret = -ENODEV;
- goto err_put_clk;
- }
-
- dmic-io_base = devm_ioremap(pdev-dev, res-start,
-resource_size(res));
+ dmic-io_base = devm_request_and_ioremap(pdev-dev, res);
if (!dmic-io_base) {
+ dev_err(pdev-dev, cannot remap\n);
ret = -ENOMEM;
goto err_put_clk;
}
--
1.7.10.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
