[PATCH 1/2] mtd:nand:omap2: clean-up BCHx_HW and BCHx_SW ECC configurations in device_probe
From: "Gupta, Pekon"
ECC scheme on NAND devices can be implemented in multiple ways.Some using
Software algorithm, while others using in-build Hardware engines.
omap2-nand driver currently supports following flavours of ECC schemes.
+---+---+---+
| ECC scheme|ECC calculation|Error detection|
+---+---+---+
|OMAP_ECC_HAMMING_CODE_DEFAULT |S/W|S/W|
|OMAP_ECC_HAMMING_CODE_HW |H/W (GPMC) |S/W|
|OMAP_ECC_HAMMING_CODE_HW_ROMCODE |H/W (GPMC) |S/W|
+---+---+---+
|(requires CONFIG_MTD_NAND_ECC_BCH) | | |
|OMAP_ECC_BCH8_CODE_HW_DETECTION_SW |H/W (GPMC) |S/W|
+---+---+---+
|(requires CONFIG_MTD_NAND_OMAP_BCH)| | |
|OMAP_ECC_BCH8_CODE_HW |H/W (GPMC) |H/W (ELM) |
+---+---+---+
This patch
- separates the configurations for various ECC schemes.
- fixes dependency issues based on Kconfig options.
- cleans up redundant code
Signed-off-by: Gupta, Pekon
---
drivers/mtd/nand/omap2.c | 432 +--
include/linux/platform_data/elm.h| 4 +
include/linux/platform_data/mtd-nand-omap2.h | 22 +-
3 files changed, 224 insertions(+), 234 deletions(-)
diff --git a/drivers/mtd/nand/omap2.c b/drivers/mtd/nand/omap2.c
index 8e820dd..167f8d4 100644
--- a/drivers/mtd/nand/omap2.c
+++ b/drivers/mtd/nand/omap2.c
@@ -25,8 +25,10 @@
#include
#include
-#ifdef CONFIG_MTD_NAND_OMAP_BCH
+#ifdef CONFIG_MTD_NAND_ECC_BCH
#include
+#endif
+#ifdef CONFIG_MTD_NAND_OMAP_BCH
#include
#endif
@@ -141,6 +143,9 @@
#define BCH_ECC_SIZE0 0x0 /* ecc_size0 = 0, no oob protection */
#define BCH_ECC_SIZE1 0x20/* ecc_size1 = 32 */
+#define BADBLOCK_MARKER_LENGTH 0x2
+#define OMAP_ECC_BCH8_POLYNOMIAL 0x201b
+
#ifdef CONFIG_MTD_NAND_OMAP_BCH
static u_char bch8_vector[] = {0xf3, 0xdb, 0x14, 0x16, 0x8b, 0xd2, 0xbe, 0xcc,
0xac, 0x6b, 0xff, 0x99, 0x7b};
@@ -182,14 +187,11 @@ struct omap_nand_info {
u_char *buf;
int buf_len;
struct gpmc_nand_regs reg;
-
-#ifdef CONFIG_MTD_NAND_OMAP_BCH
- struct bch_control *bch;
- struct nand_ecclayout ecclayout;
+ /* fields specific for BCHx_HW ECC scheme */
+ struct bch_control *bch;
boolis_elm_used;
struct device *elm_dev;
struct device_node *of_node;
-#endif
};
/**
@@ -1058,8 +1060,6 @@ static int omap_dev_ready(struct mtd_info *mtd)
}
}
-#ifdef CONFIG_MTD_NAND_OMAP_BCH
-
/**
* omap3_enable_hwecc_bch - Program OMAP3 GPMC to perform BCH ECC correction
* @mtd: MTD device structure
@@ -1141,6 +1141,7 @@ static void omap3_enable_hwecc_bch(struct mtd_info *mtd,
int mode)
writel(ECCCLEAR | ECC1, info->reg.gpmc_ecc_control);
}
+#ifdef CONFIG_MTD_NAND_ECC_BCH
/**
* omap3_calculate_ecc_bch4 - Generate 7 bytes of ECC bytes
* @mtd: MTD device structure
@@ -1227,6 +1228,62 @@ static int omap3_calculate_ecc_bch8(struct mtd_info
*mtd, const u_char *dat,
}
/**
+ * omap3_correct_data_bch - Decode received data and correct errors
+ * @mtd: MTD device structure
+ * @data: page data
+ * @read_ecc: ecc read from nand flash
+ * @calc_ecc: ecc read from HW ECC registers
+ */
+static int omap3_correct_data_bch(struct mtd_info *mtd, u_char *data,
+ u_char *read_ecc, u_char *calc_ecc)
+{
+ int i, count;
+ /* cannot correct more than 8 errors */
+ unsigned int errloc[8];
+ struct omap_nand_info *info = container_of(mtd, struct omap_nand_info,
+ mtd);
+
+ count = decode_bch(info->bch, NULL, 512, read_ecc, calc_ecc, NULL,
+ errloc);
+ if (count > 0) {
+ /* correct errors */
+ for (i = 0; i < count; i++) {
+ /* correct data only, not ecc bytes */
+ if (errloc[i] < 8*512)
+ data[errloc[i]/8] ^= 1 << (errloc[i] & 7);
+ pr_debug("corrected bitflip %u\n", errloc[i]);
+ }
+ } else if (count < 0) {
+ pr_err("ecc unrecoverable error\n");
+ }
+ return count;
+}
+
+/**
+ * omap3_free_bch - Release BCH ecc resources
+ * @mtd: MTD device structure
+ */
+static void omap3_free_bch(struct mtd_info *mtd)
+{
+ struct omap_nand_info *info = container_of(mt
[PATCH 2/2] ARM: OMAP2+: cleaned-up DT support of various ECC schemes
From: "Gupta, Pekon"
ECC scheme on NAND devices can be implemented in multiple ways.Some using
Software algorithm, while others using in-build Hardware engines.
omap2-nand driver currently supports following flavours of ECC schemes,
selectable via DTB.
+---+---+---+
| ECC scheme|ECC calculation|Error detection|
+---+---+---+
|OMAP_ECC_HAMMING_CODE_DEFAULT |S/W|S/W|
|OMAP_ECC_HAMMING_CODE_HW |H/W (GPMC) |S/W|
|OMAP_ECC_HAMMING_CODE_HW_ROMCODE |H/W (GPMC) |S/W|
+---+---+---+
|(requires CONFIG_MTD_NAND_ECC_BCH) | | |
|OMAP_ECC_BCH8_CODE_HW_DETECTION_SW |H/W (GPMC) |S/W|
+---+---+---+
|(requires CONFIG_MTD_NAND_OMAP_BCH)| | |
|OMAP_ECC_BCH8_CODE_HW |H/W (GPMC) |H/W (ELM) |
+---+---+---+
Selection of some ECC schemes also require enabling following Kconfig options.
This was done to optimize footprint of omap2-nand driver.
-Kconfig:CONFIG_MTD_NAND_ECC_BCHenables S/W based BCH ECC algorithm
-Kconfig:CONFIG_MTD_NAND_OMAP_BCH enables H/W based BCH ECC algorithm
Signed-off-by: Gupta, Pekon
---
.../devicetree/bindings/mtd/gpmc-nand.txt | 37 +++---
arch/arm/boot/dts/am335x-evm.dts | 2 +-
arch/arm/mach-omap2/gpmc.c | 12 ---
3 files changed, 34 insertions(+), 17 deletions(-)
diff --git a/Documentation/devicetree/bindings/mtd/gpmc-nand.txt
b/Documentation/devicetree/bindings/mtd/gpmc-nand.txt
index e7f8d7e..de180be 100644
--- a/Documentation/devicetree/bindings/mtd/gpmc-nand.txt
+++ b/Documentation/devicetree/bindings/mtd/gpmc-nand.txt
@@ -17,20 +17,35 @@ Required properties:
Optional properties:
- - nand-bus-width: Set this numeric value to 16 if the hardware
- is wired that way. If not specified, a bus
- width of 8 is assumed.
+ - nand-bus-width: Determines data-width of the connected device
+ x16 = "16"
+ x8 = "8" (default)
- - ti,nand-ecc-opt:A string setting the ECC layout to use. One of:
- "sw"Software method (default)
- "hw"Hardware method
- "hw-romcode"gpmc hamming mode method & romcode layout
- "bch4" 4-bit BCH ecc code
- "bch8" 8-bit BCH ecc code
+ - ti,nand-ecc-opt:Determines the ECC scheme used by driver.
+ It can be any of the following strings:
+
+ "hamming_sw"1-bit Hamming ECC using software
+
+ "hamming_hw"1-bit Hamming ECC using hardware
+
+ "hamming_hw_romcode"1-bit Hamming ECC using hardware
+ - ECC layout compatible to ROM code
+
+ "bch8_hw_detection_sw" 8-bit BCH with ECC calculation in hardware
+ and error detection in software
+ - requires Kconfig CONFIG_MTD_NAND_ECC_BCH
+
+ "bch8_hw" 8-bit BCH with ECC calculation in hardware
+ and error detection in hardware
+ - requires to be specified
+ - requires Kconfig CONFIG_MTD_NAND_OMAP_BCH
+
+
+
+ - elm_id: Specifies elm device node. This is required to
+ support some BCH ECC schemes mentioned above.
- - elm_id: Specifies elm device node. This is required to support BCH
- error correction using ELM module.
For inline partiton table parsing (optional):
diff --git a/arch/arm/boot/dts/am335x-evm.dts b/arch/arm/boot/dts/am335x-evm.dts
index 0b8f161..60e8f59 100644
--- a/arch/arm/boot/dts/am335x-evm.dts
+++ b/arch/arm/boot/dts/am335x-evm.dts
@@ -135,7 +135,7 @@
nand@0,0 {
reg = <0 0 0>; /* CS0, offset 0 */
nand-bus-width = <8>;
- ti,nand-ecc-opt = "bch8";
+ ti,nand-ecc-opt = "bch8_hw";
gpmc,sync-clk = <0>;
gpmc,cs-on = <0>;
diff --git a/arch/arm/mach-omap2/gpmc.c b/arch/arm/mach-omap2/gpmc.c
index 410e1ba..03b8027 100644
--- a/arch/arm/mach-omap2/gpmc.c
+++ b/arch/arm/mach-omap2/gpmc.c
@@ -1205,11 +1205,13 @@ static void __maybe_unused gpmc_read_timings_dt(struct
device_node *np,
#ifdef CONFIG_MTD_
[PATCH 0/2] mtd:nand:omap2: ECC support clean-up for omap2-nand driver
From: "Gupta, Pekon" This patch series makes ECC scheme selection for omap2-nand driver more user-friendly.It also adds scalability for large page-sized NAND devices, and adding new ECC schemes in future. [PATCH 1/2] - clean-up and optimization for supported ECC schemes. - added checks for Kconfigs required by specific ECC schemes. [PATCH 2/2] - add DT options for selecting supported ECC scheme. Gupta, Pekon (2): mtd:nand:omap2: clean-up BCHx_HW and BCHx_SW ECC configurations in device_probe ARM: OMAP2+: cleaned-up DT support of various ECC schemes .../devicetree/bindings/mtd/gpmc-nand.txt | 37 +- arch/arm/boot/dts/am335x-evm.dts | 2 +- arch/arm/mach-omap2/gpmc.c | 12 +- drivers/mtd/nand/omap2.c | 432 ++--- include/linux/platform_data/elm.h | 4 + include/linux/platform_data/mtd-nand-omap2.h | 22 +- 6 files changed, 258 insertions(+), 251 deletions(-) -- 1.8.1 -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: v3.10-rc1: backlight brightness after boot on N900
On 15/05/13 20:18, Aaro Koskinen wrote: > Hi, > > Is it expected that after boot you get 0 brightness i.e. a seemingly > blank display on N900 with 3.10-rc1? > > First thought after seeing a blank display was that the probe > issues are still there, but everything was fine and after setting > /sys/class/backlight/acx565akm/brightness you get a picture. > > Just wondering how the initial brightness is determined anyway? There were some small changes merged in v3.10 related to acx's backlight, but they were removing dead code so I don't see how those could affect... Looking at the driver, the bl is initialized: if (md->has_bc) brightness = acx565akm_get_actual_brightness(md); else brightness = 0; And has_bc is set only if the model is detected as MIPID_VER_ACX565AKM (that's the panel in final N900, isn't it?). So what comes to my mind is that either the model is detected wrong, or the acx565akm_get_actual_brightness() which reads the current BL from the panel happens to return 0, either because of an error, or because the bootloader has set the BL to 0. But why either of those would've changed with v3.10... No idea... Can you add debug prints to see which code paths are taken there (drivers/video/omap2/displays/panel-acx565akm.c, around line 580). The panel model should also be printed with "omapfb: %s rev %02x LCD detected". Tomi signature.asc Description: OpenPGP digital signature
Re: [PATCHv2 3/3] arm: dts: add bandgap entry for OMAP4460 devices
On 12:36 Wed 15 May , Eduardo Valentin wrote:
> On 15-05-2013 11:23, Benoit Cousson wrote:
> > Hi Eduardo,
> >
> > On 05/15/2013 04:58 PM, Eduardo Valentin wrote:
> >> Include bandgap devices for OMAP4460 devices.
> >>
> >> Cc: "Benoît Cousson"
> >> Cc: Tony Lindgren
> >> Cc: Russell King
> >> Cc: linux-omap@vger.kernel.org
> >> Cc: devicetree-disc...@lists.ozlabs.org
> >> Cc: linux-arm-ker...@lists.infradead.org
> >> Cc: linux-ker...@vger.kernel.org
> >> Signed-off-by: Eduardo Valentin
> >> ---
> >> arch/arm/boot/dts/omap4460.dtsi | 9 +
> >> 1 file changed, 9 insertions(+)
> >>
> >> diff --git a/arch/arm/boot/dts/omap4460.dtsi
> >> b/arch/arm/boot/dts/omap4460.dtsi
> >> index 2cf227c..e5bfbfe 100644
> >> --- a/arch/arm/boot/dts/omap4460.dtsi
> >> +++ b/arch/arm/boot/dts/omap4460.dtsi
> >> @@ -29,4 +29,13 @@
> >> <0 55 0x4>;
> >>ti,hwmods = "debugss";
> >>};
> >> +
> >> + bandgap {
> >> + reg = <0x4a002260 0x4
> >> + 0x4a00232C 0x4
> >> + 0x4a002378 0x18>;
> >> + compatible = "ti,omap4460-bandgap";
> >> + interrupts = <0 126 4>; /* talert */
> >> + ti,tshut-gpio = <86>;
>
>
>
> >
> > Why do you need a custom attribute for GPIO? Cannot you use the standard
> > one?
>
> I believe it was by your suggestion :-), during the first attempts to
> send this driver. But could not find the thread link :-( sorry.
>
>
> I guess the reasoning to mark it as a ti specific is because it will be
> used as IRQ line to treat thermal shutdown (in SW).
so use interrup-parent
>
> >
> > Where is the gpio controller phandle?
> >
> > Usually it looks like this:
> >
> > gpios = <&gpio1 8 0>;
> >
> >
> > Regards,
> > Benoit
> >
> >
> >
>
>
> ___
> linux-arm-kernel mailing list
> linux-arm-ker...@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: OMAP3: Fix iva2_pwrdm settings for 3703
On Wed, May 15, 2013 at 10:07:35AM -0700, Tony Lindgren wrote: > * Mark A. Greer [130514 18:57]: > > On Tue, May 14, 2013 at 05:25:37PM -0700, Tony Lindgren wrote: > > > Commit a819c4f1 (ARM: OMAP3: PM: Only access IVA if one exists) > > > changed PM to not access IVA registers on omaps that don't have > > > them. Turns out we still need to idle iva2 as otherwise iva2_pwrdm > > > will stay on and block deeper idle states. > > > > > > Signed-off-by: Tony Lindgren > > > > > > --- > > > > > > Paul & Kevin, do you have better ideas for fixing this? > > > > > > --- a/arch/arm/mach-omap2/pm34xx.c > > > +++ b/arch/arm/mach-omap2/pm34xx.c > > > @@ -546,8 +546,10 @@ static void __init prcm_setup_regs(void) > > > /* Clear any pending PRCM interrupts */ > > > omap2_prm_write_mod_reg(0, OCP_MOD, OMAP3_PRM_IRQSTATUS_MPU_OFFSET); > > > > > > - if (omap3_has_iva()) > > > - omap3_iva_idle(); > > > + /* > > > + * We need to idle iva2_pwrdm even on am3703 with no iva2. > > > + */ > > > + omap3_iva_idle(); > > > > > > omap3_d2d_idle(); > > > } > > > > [Kevin, Paul, some background: Tony discovered that the am3703 needs > > to have omap3_iva_idle() called even though its not supposed to have > > an IVA.] > > > > This is potentially bad for other SoC's that don't have an IVA so I don't > > think its the way to go. My preference would be to set the OMAP3_HAS_IVA > > flag for the am3703 only since its the one with the bug. Maybe something > > in id.c:omap3xxx_check_features() but I don't see any existing way to check > > for an am3703 vs. other am37xx SoCs. Any ideas? > > > > Another option, I suppose, is a dts entry but I don't like that at all. > > It seems that iva2_pwrdm is there for all omap3 even if OMAP3_HAS_IVA > flag is unset. And if that's the case, iva2 clocks still need to be idled > in all cases. Ahh, this takes us to the "Great TI Docs Mystery" :) -- its basically impossible to tell because despite what their docs may say, the hardware can be quite different. I'm not sure how to proceed other than trial & error with as many different SoCs as we can find. > It's possible that not all steps in omap3_iva_idle() are needed though. > I can debug further to see which part of the omap3_iva_idle() are needed. > > Mark, do you have some omap3 with no iva (other than am3703) to test the > idle states with? I have an am35xx which isn't supposed to have an IVA so I can test with it (although, I'm not sure how well the kernel works on the am35xx these days). I'm a bit busy today but I'll try booting the am35xx tomorrow and if it comes up, see what I can figure out. 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
v3.10-rc1: backlight brightness after boot on N900
Hi, Is it expected that after boot you get 0 brightness i.e. a seemingly blank display on N900 with 3.10-rc1? First thought after seeing a blank display was that the probe issues are still there, but everything was fine and after setting /sys/class/backlight/acx565akm/brightness you get a picture. Just wondering how the initial brightness is determined anyway? 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] ARM: OMAP3: Fix iva2_pwrdm settings for 3703
* Mark A. Greer [130514 18:57]: > On Tue, May 14, 2013 at 05:25:37PM -0700, Tony Lindgren wrote: > > Commit a819c4f1 (ARM: OMAP3: PM: Only access IVA if one exists) > > changed PM to not access IVA registers on omaps that don't have > > them. Turns out we still need to idle iva2 as otherwise iva2_pwrdm > > will stay on and block deeper idle states. > > > > Signed-off-by: Tony Lindgren > > > > --- > > > > Paul & Kevin, do you have better ideas for fixing this? > > > > --- a/arch/arm/mach-omap2/pm34xx.c > > +++ b/arch/arm/mach-omap2/pm34xx.c > > @@ -546,8 +546,10 @@ static void __init prcm_setup_regs(void) > > /* Clear any pending PRCM interrupts */ > > omap2_prm_write_mod_reg(0, OCP_MOD, OMAP3_PRM_IRQSTATUS_MPU_OFFSET); > > > > - if (omap3_has_iva()) > > - omap3_iva_idle(); > > + /* > > +* We need to idle iva2_pwrdm even on am3703 with no iva2. > > +*/ > > + omap3_iva_idle(); > > > > omap3_d2d_idle(); > > } > > [Kevin, Paul, some background: Tony discovered that the am3703 needs > to have omap3_iva_idle() called even though its not supposed to have > an IVA.] > > This is potentially bad for other SoC's that don't have an IVA so I don't > think its the way to go. My preference would be to set the OMAP3_HAS_IVA > flag for the am3703 only since its the one with the bug. Maybe something > in id.c:omap3xxx_check_features() but I don't see any existing way to check > for an am3703 vs. other am37xx SoCs. Any ideas? > > Another option, I suppose, is a dts entry but I don't like that at all. It seems that iva2_pwrdm is there for all omap3 even if OMAP3_HAS_IVA flag is unset. And if that's the case, iva2 clocks still need to be idled in all cases. It's possible that not all steps in omap3_iva_idle() are needed though. I can debug further to see which part of the omap3_iva_idle() are needed. Mark, do you have some omap3 with no iva (other than am3703) to test the idle states with? 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 v4] ARM:dts:omap4-panda: Update the LED support for the panda DTS
On 11:46-20130515, Dan Murphy wrote:
> The GPIO for LED D1 on the omap4-panda a1-a3 rev and the omap4-panda-es
> are different.
>
> A1-A3 = gpio_wk7
> ES = gpio_110
>
> There is no change to LED D2
>
> Abstract away the pinmux and the LED definitions for the two boards into
> the respective DTS files.
>
> Signed-off-by: Dan Murphy
> ---
nit: Giving patch history is a nice practise.
> arch/arm/boot/dts/omap4-panda-common.dtsi | 16 +++-
> arch/arm/boot/dts/omap4-panda-es.dts | 40
> +
> 2 files changed, 55 insertions(+), 1 deletions(-)
>
> diff --git a/arch/arm/boot/dts/omap4-panda-common.dtsi
> b/arch/arm/boot/dts/omap4-panda-common.dtsi
> index 03bd60d..2b516af 100644
> --- a/arch/arm/boot/dts/omap4-panda-common.dtsi
> +++ b/arch/arm/boot/dts/omap4-panda-common.dtsi
> @@ -16,7 +16,7 @@
> reg = <0x8000 0x4000>; /* 1 GB */
> };
>
> - leds {
> + leds: leds {
> compatible = "gpio-leds";
> heartbeat {
> label = "pandaboard::status1";
> @@ -137,6 +137,20 @@
I missed noticing this previously, Apologies on the same.
Considering that drivers/leds/leds-gpio.c has ability to handle pinctrl,
One better option might be to provide pinctrl phandle with leds -
Couple of reasons why this might be good:
a) one gets the following warning at boot:
"leds-gpio leds.8: pins are not configured from the driver"
b) you donot need to setup the pins by default at boot - it is not
mandatory for the system functionality, instead we do it *if* the driver
is enabled.
Further, optionally, all you'd have to do in panda-es.dts is the following
&led_wkgpio_pins {
pinctrl-single,pins = <
0x1c 0x3/* gpio_wk8 OUTPUT | MODE 3 */
>;
}
Similarly for gpios override for panda-es.
> };
> };
>
> +&omap4_pmx_wkup {
> + pinctrl-names = "default";
> + pinctrl-0 = <
> + &led_wkgpio_pins
> + >;
> +
> + led_wkgpio_pins: pinmux_leds_wkpins {
> + pinctrl-single,pins = <
> + 0x1a 0x3/* gpio_wk7 OUTPUT | MODE 3 */
> + 0x1c 0x3/* gpio_wk8 OUTPUT | MODE 3 */
> + >;
> + };
> +};
> +
> &i2c1 {
> pinctrl-names = "default";
> pinctrl-0 = <&i2c1_pins>;
> diff --git a/arch/arm/boot/dts/omap4-panda-es.dts
> b/arch/arm/boot/dts/omap4-panda-es.dts
> index f1d8c21..e6f696d 100644
> --- a/arch/arm/boot/dts/omap4-panda-es.dts
> +++ b/arch/arm/boot/dts/omap4-panda-es.dts
> @@ -34,3 +34,43 @@
> 0x5e 0x100 /* hdmi_sda.hdmi_sda INPUT | MODE 0 */
> >;
> };
> +
> +&leds {
> + compatible = "gpio-leds";
> + heartbeat {
> + label = "pandaboard::status1";
> + gpios = <&gpio4 14 0>;
> + linux,default-trigger = "heartbeat";
> + };
> + mmc {
> + label = "pandaboard::status2";
> + gpios = <&gpio1 8 0>;
> + linux,default-trigger = "mmc0";
> + };
> +};
> +
> +&omap4_pmx_core {
> + pinctrl-names = "default";
> + pinctrl-0 = <
> + &led_gpio_pins
> + >;
> +
> + led_gpio_pins: gpio_led_pmx {
> + pinctrl-single,pins = <
> + 0xb6 0x3/* gpio_110 OUTPUT | MODE 3 */
> + >;
> + };
> +};
> +
> +&omap4_pmx_wkup {
> + pinctrl-names = "default";
> + pinctrl-0 = <
> + &led_wkgpio_pins
> + >;
> +
> + led_wkgpio_pins: pinmux_leds_wkpins {
> + pinctrl-single,pins = <
> + 0x1c 0x3/* gpio_wk8 OUTPUT | MODE 3 */
> + >;
> + };
> +};
> --
> 1.7.5.4
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-omap" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
Regards,
Nishanth Menon
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v4] ARM:dts:omap4-panda: Update the LED support for the panda DTS
The GPIO for LED D1 on the omap4-panda a1-a3 rev and the omap4-panda-es
are different.
A1-A3 = gpio_wk7
ES = gpio_110
There is no change to LED D2
Abstract away the pinmux and the LED definitions for the two boards into
the respective DTS files.
Signed-off-by: Dan Murphy
---
arch/arm/boot/dts/omap4-panda-common.dtsi | 16 +++-
arch/arm/boot/dts/omap4-panda-es.dts | 40 +
2 files changed, 55 insertions(+), 1 deletions(-)
diff --git a/arch/arm/boot/dts/omap4-panda-common.dtsi
b/arch/arm/boot/dts/omap4-panda-common.dtsi
index 03bd60d..2b516af 100644
--- a/arch/arm/boot/dts/omap4-panda-common.dtsi
+++ b/arch/arm/boot/dts/omap4-panda-common.dtsi
@@ -16,7 +16,7 @@
reg = <0x8000 0x4000>; /* 1 GB */
};
- leds {
+ leds: leds {
compatible = "gpio-leds";
heartbeat {
label = "pandaboard::status1";
@@ -137,6 +137,20 @@
};
};
+&omap4_pmx_wkup {
+ pinctrl-names = "default";
+ pinctrl-0 = <
+ &led_wkgpio_pins
+ >;
+
+ led_wkgpio_pins: pinmux_leds_wkpins {
+ pinctrl-single,pins = <
+ 0x1a 0x3/* gpio_wk7 OUTPUT | MODE 3 */
+ 0x1c 0x3/* gpio_wk8 OUTPUT | MODE 3 */
+ >;
+ };
+};
+
&i2c1 {
pinctrl-names = "default";
pinctrl-0 = <&i2c1_pins>;
diff --git a/arch/arm/boot/dts/omap4-panda-es.dts
b/arch/arm/boot/dts/omap4-panda-es.dts
index f1d8c21..e6f696d 100644
--- a/arch/arm/boot/dts/omap4-panda-es.dts
+++ b/arch/arm/boot/dts/omap4-panda-es.dts
@@ -34,3 +34,43 @@
0x5e 0x100 /* hdmi_sda.hdmi_sda INPUT | MODE 0 */
>;
};
+
+&leds {
+ compatible = "gpio-leds";
+ heartbeat {
+ label = "pandaboard::status1";
+ gpios = <&gpio4 14 0>;
+ linux,default-trigger = "heartbeat";
+ };
+ mmc {
+ label = "pandaboard::status2";
+ gpios = <&gpio1 8 0>;
+ linux,default-trigger = "mmc0";
+ };
+};
+
+&omap4_pmx_core {
+ pinctrl-names = "default";
+ pinctrl-0 = <
+ &led_gpio_pins
+ >;
+
+ led_gpio_pins: gpio_led_pmx {
+ pinctrl-single,pins = <
+ 0xb6 0x3/* gpio_110 OUTPUT | MODE 3 */
+ >;
+ };
+};
+
+&omap4_pmx_wkup {
+ pinctrl-names = "default";
+ pinctrl-0 = <
+ &led_wkgpio_pins
+ >;
+
+ led_wkgpio_pins: pinmux_leds_wkpins {
+ pinctrl-single,pins = <
+ 0x1c 0x3/* gpio_wk8 OUTPUT | MODE 3 */
+ >;
+ };
+};
--
1.7.5.4
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv2 3/3] arm: dts: add bandgap entry for OMAP4460 devices
On 15-05-2013 11:23, Benoit Cousson wrote:
> Hi Eduardo,
>
> On 05/15/2013 04:58 PM, Eduardo Valentin wrote:
>> Include bandgap devices for OMAP4460 devices.
>>
>> Cc: "Benoît Cousson"
>> Cc: Tony Lindgren
>> Cc: Russell King
>> Cc: linux-omap@vger.kernel.org
>> Cc: devicetree-disc...@lists.ozlabs.org
>> Cc: linux-arm-ker...@lists.infradead.org
>> Cc: linux-ker...@vger.kernel.org
>> Signed-off-by: Eduardo Valentin
>> ---
>> arch/arm/boot/dts/omap4460.dtsi | 9 +
>> 1 file changed, 9 insertions(+)
>>
>> diff --git a/arch/arm/boot/dts/omap4460.dtsi
>> b/arch/arm/boot/dts/omap4460.dtsi
>> index 2cf227c..e5bfbfe 100644
>> --- a/arch/arm/boot/dts/omap4460.dtsi
>> +++ b/arch/arm/boot/dts/omap4460.dtsi
>> @@ -29,4 +29,13 @@
>> <0 55 0x4>;
>> ti,hwmods = "debugss";
>> };
>> +
>> +bandgap {
>> +reg = <0x4a002260 0x4
>> +0x4a00232C 0x4
>> +0x4a002378 0x18>;
>> +compatible = "ti,omap4460-bandgap";
>> +interrupts = <0 126 4>; /* talert */
>> +ti,tshut-gpio = <86>;
>
> Why do you need a custom attribute for GPIO? Cannot you use the standard
> one?
I believe it was by your suggestion :-), during the first attempts to
send this driver. But could not find the thread link :-( sorry.
I guess the reasoning to mark it as a ti specific is because it will be
used as IRQ line to treat thermal shutdown (in SW).
>
> Where is the gpio controller phandle?
>
> Usually it looks like this:
>
> gpios = <&gpio1 8 0>;
>
>
> Regards,
> Benoit
>
>
>
signature.asc
Description: OpenPGP digital signature
[Resend/PATCHv5 2/3] arm: dts: am33xx: Remove "ti,no_idle_on_suspend" property.
The "ti,no_idle_on_suspend" property was required to keep ocmcram clocks
running during idle.
But commit 72bb6f9 (ARM: OMAP: omap_device: don't attempt late suspend
if no driver bound), added in v3.6 should prevent any automatic clock
gating for devices without drivers bound. Since there is no driver for
the OCM RAM block, we are not affected by the automatic idle on suspend
anyways which means "ti,no_idle_on_suspend" can be safely removed since
there are no users for it.
Cc: Benoit Cousson
Cc: Santosh Shilimkar
Cc: Felipe Balbi
Cc: Rajendra nayak
Signed-off-by: Sourav Poddar
Reviewed-by: Felipe Balbi
---
arch/arm/boot/dts/am33xx.dtsi |1 -
1 files changed, 0 insertions(+), 1 deletions(-)
diff --git a/arch/arm/boot/dts/am33xx.dtsi b/arch/arm/boot/dts/am33xx.dtsi
index 1460d9b..a2608c0 100644
--- a/arch/arm/boot/dts/am33xx.dtsi
+++ b/arch/arm/boot/dts/am33xx.dtsi
@@ -394,7 +394,6 @@
compatible = "ti,am3352-ocmcram";
reg = <0x4030 0x1>;
ti,hwmods = "ocmcram";
- ti,no_idle_on_suspend;
};
wkup_m3: wkup_m3@44d0 {
--
1.7.1
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[Resend/PATCHv5 3/3] arm: omap2+: omap_device: remove no_idle_on_suspend
Remove "no_idle_on_suspend" check, since respective
driver should be able to prevent idling of an
omap device whenever required.
Driver's can get same behavior by just returning -EBUSY
from their ->runtime_suspend only during suspend.
Cc: Santosh Shilimkar
Cc: Felipe Balbi
Cc: Rajendra nayak
Cc: Grygorii Strashko
Signed-off-by: Sourav Poddar
Reviewed-by: Felipe Balbi
---
arch/arm/mach-omap2/omap_device.c |9 ++---
arch/arm/mach-omap2/omap_device.h | 10 --
2 files changed, 2 insertions(+), 17 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_device.c
b/arch/arm/mach-omap2/omap_device.c
index e6d2307..68be532 100644
--- a/arch/arm/mach-omap2/omap_device.c
+++ b/arch/arm/mach-omap2/omap_device.c
@@ -170,9 +170,6 @@ static int omap_device_build_from_dt(struct platform_device
*pdev)
r->name = dev_name(&pdev->dev);
}
- if (of_get_property(node, "ti,no_idle_on_suspend", NULL))
- omap_device_disable_idle_on_suspend(pdev);
-
pdev->dev.pm_domain = &omap_device_pm_domain;
odbfd_exit1:
@@ -621,8 +618,7 @@ static int _od_suspend_noirq(struct device *dev)
if (!ret && !pm_runtime_status_suspended(dev)) {
if (pm_generic_runtime_suspend(dev) == 0) {
- if (!(od->flags & OMAP_DEVICE_NO_IDLE_ON_SUSPEND))
- omap_device_idle(pdev);
+ omap_device_idle(pdev);
od->flags |= OMAP_DEVICE_SUSPENDED;
}
}
@@ -638,8 +634,7 @@ static int _od_resume_noirq(struct device *dev)
if ((od->flags & OMAP_DEVICE_SUSPENDED) &&
!pm_runtime_status_suspended(dev)) {
od->flags &= ~OMAP_DEVICE_SUSPENDED;
- if (!(od->flags & OMAP_DEVICE_NO_IDLE_ON_SUSPEND))
- omap_device_enable(pdev);
+ omap_device_enable(pdev);
pm_generic_runtime_resume(dev);
}
diff --git a/arch/arm/mach-omap2/omap_device.h
b/arch/arm/mach-omap2/omap_device.h
index 044c31d..17ca1ae 100644
--- a/arch/arm/mach-omap2/omap_device.h
+++ b/arch/arm/mach-omap2/omap_device.h
@@ -38,7 +38,6 @@ extern struct dev_pm_domain omap_device_pm_domain;
/* omap_device.flags values */
#define OMAP_DEVICE_SUSPENDED BIT(0)
-#define OMAP_DEVICE_NO_IDLE_ON_SUSPEND BIT(1)
/**
* struct omap_device - omap_device wrapper for platform_devices
@@ -101,13 +100,4 @@ static inline struct omap_device *to_omap_device(struct
platform_device *pdev)
{
return pdev ? pdev->archdata.od : NULL;
}
-
-static inline
-void omap_device_disable_idle_on_suspend(struct platform_device *pdev)
-{
- struct omap_device *od = to_omap_device(pdev);
-
- od->flags |= OMAP_DEVICE_NO_IDLE_ON_SUSPEND;
-}
-
#endif
--
1.7.1
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[Resend/PATCHv5 1/3] arm: omap2+: serial: remove no_console_suspend support
"no_console_suspend" is no longer handled in platform file,
Since the omap serial driver is now adapted to prevent
console UART idleing during suspend.
Cc: Santosh Shilimkar
Cc: Felipe Balbi
Cc: Rajendra nayak
Signed-off-by: Sourav Poddar
Reviewed-by: Felipe Balbi
---
arch/arm/mach-omap2/serial.c |7 ---
1 files changed, 0 insertions(+), 7 deletions(-)
diff --git a/arch/arm/mach-omap2/serial.c b/arch/arm/mach-omap2/serial.c
index 8396b5b..25fb6e9 100644
--- a/arch/arm/mach-omap2/serial.c
+++ b/arch/arm/mach-omap2/serial.c
@@ -63,7 +63,6 @@ struct omap_uart_state {
static LIST_HEAD(uart_list);
static u8 num_uarts;
static u8 console_uart_id = -1;
-static u8 no_console_suspend;
static u8 uart_debug;
#define DEFAULT_RXDMA_POLLRATE 1 /* RX DMA polling rate (us) */
@@ -236,9 +235,6 @@ static int __init omap_serial_early_init(void)
uart_name, uart->num);
}
- if (cmdline_find_option("no_console_suspend"))
- no_console_suspend = true;
-
/*
* omap-uart can be used for earlyprintk logs
* So if omap-uart is used as console then prevent
@@ -323,9 +319,6 @@ void __init omap_serial_init_port(struct omap_board_data
*bdata,
return;
}
- if ((console_uart_id == bdata->id) && no_console_suspend)
- omap_device_disable_idle_on_suspend(pdev);
-
oh->mux = omap_hwmod_mux_init(bdata->pads, bdata->pads_cnt);
if (console_uart_id == bdata->id) {
--
1.7.1
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[Resend/PATCHv5 0/3] Omap serial cleanup
Hi Kevin, Resending this patch series again on top of 3.10-rc1. This is a cleanup series done in response to the serial driver fixes done for "no_console_suspend" case. This cleanups mainly include getting rid of using "omap_device_disable_idle_on_suspend" api for both dt and non dt case as the serial driver will be self sufficient to handle the "no_idle_on_suspend" issue. Serial was the only one making use of "omap_device_disable_idle_on_suspend" Cc: Santosh Shilimkar Cc: Felipe Balbi Cc: Rajendra nayak Test info Omap4430sdp: - Tested wakeup from UART after suspend for dt and non dt case. Omap5430evm: - Tested wakeup from UART after suspend for dt case. These patches were the part of the bigger series[2]. Breaking them into two relevant series as they go through the different tree. [2]: http://lkml.org/lkml/2013/4/26/274 The following changes since commit b973425cbb51e08301b34fecdfd476a44507d8cf: Merge tag 'ext4_for_linus_stable' of git://git.kernel.org/pub/scm/linux/kernel/git/tytso/ext4 (2013-05-14 09:30:54 -0700) are available in the git repository at: git://gitorious.org/linux-connectivity/linux-connectivity.git omap_fix_resend Sourav Poddar (3): arm: omap2+: serial: remove no_console_suspend support arm: dts: am33xx: Remove "ti,no_idle_on_suspend" property. arm: omap2+: omap_device: remove no_idle_on_suspend arch/arm/boot/dts/am33xx.dtsi |1 - arch/arm/mach-omap2/omap_device.c |9 ++--- arch/arm/mach-omap2/omap_device.h | 10 -- arch/arm/mach-omap2/serial.c |7 --- 4 files changed, 2 insertions(+), 25 deletions(-) -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv5 1/2] driver: tty: serial: Move "uart_console" def to core header file.
Hi, On Wednesday 15 May 2013 08:27 PM, Sourav Poddar wrote: On Wednesday 15 May 2013 08:27 PM, Greg KH wrote: On Wed, May 15, 2013 at 08:13:09PM +0530, Sourav Poddar wrote: Hi Greg, On Saturday 27 April 2013 03:48 AM, Greg KH wrote: On Fri, Apr 26, 2013 at 03:03:07PM -0700, Kevin Hilman wrote: Hi Greg, Sourav Poddar writes: Move "uart_console" definition to serial core header file, so that it can be used by serial drivers. Get rid of the uart_console defintion from mpc52xx_uart driver. Cc: Santosh Shilimkar Cc: Felipe Balbi Cc: Rajendra nayak Signed-off-by: Sourav Poddar Reviewed-by: Felipe Balbi Can you queue up this patch (and 2/2)? Once these are in, I will queue up the corresponding arch/arm changes which can go independently. And feel free to add Reviewed-by: Kevin Hilman Tested-by: Kevin Hilman I will do so after 3.10-rc1 is out, it is _way_ too late in the development cycle for me to add these to my trees right now, considering they are pretty much closed at the moment. Do you want me to rebase this patches on top of 3.10-rc1? That would be great to have, thanks. [Greg]: Have resend the patch series based on 3.10-rc1. [Kevin]: Should I resend the omap specific changes also after rebasing it on 3.10-rc1, once greg pull in the serial part. ? greg k-h Ok. Will do that and resend. -- To unsubscribe from this list: send the line "unsubscribe linux-serial" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[Resend/PATCHv5 2/2] driver: serial: omap: prevent runtime PM for "no_console_suspend"
The driver manages "no_console_suspend" by preventing runtime PM
during the suspend path, which forces the console UART to stay awake.
Reviewed-by: Felipe Balbi
Reviewed-by: Kevin Hilman
Tested-by: Kevin Hilman
Signed-off-by: Sourav Poddar
---
drivers/tty/serial/omap-serial.c | 34 +-
1 files changed, 33 insertions(+), 1 deletions(-)
diff --git a/drivers/tty/serial/omap-serial.c b/drivers/tty/serial/omap-serial.c
index 30d4f7a..9457fe3 100644
--- a/drivers/tty/serial/omap-serial.c
+++ b/drivers/tty/serial/omap-serial.c
@@ -161,6 +161,7 @@ struct uart_omap_port {
u32 calc_latency;
struct work_struct qos_work;
struct pinctrl *pins;
+ boolis_suspending;
};
#define to_uart_omap_port(p) ((container_of((p), struct uart_omap_port,
port)))
@@ -1312,6 +1313,22 @@ static struct uart_driver serial_omap_reg = {
};
#ifdef CONFIG_PM_SLEEP
+static int serial_omap_prepare(struct device *dev)
+{
+ struct uart_omap_port *up = dev_get_drvdata(dev);
+
+ up->is_suspending = true;
+
+ return 0;
+}
+
+static void serial_omap_complete(struct device *dev)
+{
+ struct uart_omap_port *up = dev_get_drvdata(dev);
+
+ up->is_suspending = false;
+}
+
static int serial_omap_suspend(struct device *dev)
{
struct uart_omap_port *up = dev_get_drvdata(dev);
@@ -1330,7 +1347,10 @@ static int serial_omap_resume(struct device *dev)
return 0;
}
-#endif
+#else
+#define serial_omap_prepare NULL
+#define serial_omap_prepare NULL
+#endif /* CONFIG_PM_SLEEP */
static void omap_serial_fill_features_erratas(struct uart_omap_port *up)
{
@@ -1616,6 +1636,16 @@ static int serial_omap_runtime_suspend(struct device
*dev)
struct uart_omap_port *up = dev_get_drvdata(dev);
struct omap_uart_port_info *pdata = dev->platform_data;
+ /*
+ * When using 'no_console_suspend', the console UART must not be
+ * suspended. Since driver suspend is managed by runtime suspend,
+ * preventing runtime suspend (by returning error) will keep device
+ * active during suspend.
+ */
+ if (up->is_suspending && !console_suspend_enabled &&
+ uart_console(&up->port))
+ return -EBUSY;
+
if (!up)
return -EINVAL;
@@ -1666,6 +1696,8 @@ static const struct dev_pm_ops serial_omap_dev_pm_ops = {
SET_SYSTEM_SLEEP_PM_OPS(serial_omap_suspend, serial_omap_resume)
SET_RUNTIME_PM_OPS(serial_omap_runtime_suspend,
serial_omap_runtime_resume, NULL)
+ .prepare= serial_omap_prepare,
+ .complete = serial_omap_complete,
};
#if defined(CONFIG_OF)
--
1.7.1
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[Resend/PATCHv5 1/2] driver: tty: serial: Move "uart_console" def to core header file.
Move "uart_console" definition to serial core header file, so that it can be used by serial drivers. Get rid of the uart_console defintion from mpc52xx_uart driver. Cc: Santosh Shilimkar Cc: Felipe Balbi Cc: Rajendra nayak Reviewed-by: Felipe Balbi Reviewed-by: Kevin Hilman Tested-by: Kevin Hilman Signed-off-by: Sourav Poddar --- drivers/tty/serial/mpc52xx_uart.c | 10 -- drivers/tty/serial/serial_core.c |6 -- include/linux/serial_core.h |7 +++ 3 files changed, 7 insertions(+), 16 deletions(-) diff --git a/drivers/tty/serial/mpc52xx_uart.c b/drivers/tty/serial/mpc52xx_uart.c index 018bad9..d74ac06 100644 --- a/drivers/tty/serial/mpc52xx_uart.c +++ b/drivers/tty/serial/mpc52xx_uart.c @@ -84,16 +84,6 @@ static void mpc52xx_uart_of_enumerate(void); static irqreturn_t mpc52xx_uart_int(int irq, void *dev_id); static irqreturn_t mpc5xxx_uart_process_int(struct uart_port *port); - -/* Simple macro to test if a port is console or not. This one is taken - * for serial_core.c and maybe should be moved to serial_core.h ? */ -#ifdef CONFIG_SERIAL_CORE_CONSOLE -#define uart_console(port) \ - ((port)->cons && (port)->cons->index == (port)->line) -#else -#define uart_console(port) (0) -#endif - /* */ /* PSC fifo operations for isolating differences between 52xx and 512x */ /* */ diff --git a/drivers/tty/serial/serial_core.c b/drivers/tty/serial/serial_core.c index f87dbfd..28cdd28 100644 --- a/drivers/tty/serial/serial_core.c +++ b/drivers/tty/serial/serial_core.c @@ -50,12 +50,6 @@ static struct lock_class_key port_lock_key; #define HIGH_BITS_OFFSET ((sizeof(long)-sizeof(int))*8) -#ifdef CONFIG_SERIAL_CORE_CONSOLE -#define uart_console(port) ((port)->cons && (port)->cons->index == (port)->line) -#else -#define uart_console(port) (0) -#endif - static void uart_change_speed(struct tty_struct *tty, struct uart_state *state, struct ktermios *old_termios); static void uart_wait_until_sent(struct tty_struct *tty, int timeout); diff --git a/include/linux/serial_core.h b/include/linux/serial_core.h index 87d4bbc..b98291a 100644 --- a/include/linux/serial_core.h +++ b/include/linux/serial_core.h @@ -31,6 +31,13 @@ #include #include +#ifdef CONFIG_SERIAL_CORE_CONSOLE +#define uart_console(port) \ + ((port)->cons && (port)->cons->index == (port)->line) +#else +#define uart_console(port) (0) +#endif + struct uart_port; struct serial_struct; struct device; -- 1.7.1 -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[Resned/PATCHv5 0/2] Serial fixes
Hi Greg, I have rebased this patch series on top of 3.10-rc1. This patch series contains fixes around the issue that the console UART should not idled on suspend while using "no_console_suspend" in bootargs. The approach thought of is to modify the serial core/serial driver to bypass runtime PM if the UART in contention is a console and we are using "no_console_suspend" in our bootargs. There were discussions about how to handle "no_idle_on_suspend" issue and all the discussions are as follows: https://lkml.org/lkml/2013/4/5/239 https://lkml.org/lkml/2013/4/2/350 https://lkml.org/lkml/2013/3/18/199 https://lkml.org/lkml/2013/3/18/295 Due to the amount of change in approach, I am posting this as a new series. v4->v5 1. Add comments 2. Formatting. v3->v4 1. check for console in runtime api. v2->v3 1. Use "-EBUSY" for no_console_suspend case 2. Bypass runtime PM only during suspend 3. Improve the commit log based on community suggestion. v1->v2 1. Remove the prepare/complete callback. 2. Adapt runtime PM callback to deal with the issue. 3. Fold patch(1,2) of previous series into 1. 4. Reordered the patch. 5. Change $subject and chage log for few patches. Cc: Santosh Shilimkar Cc: Felipe Balbi Cc: Rajendra nayak Test info Omap4430sdp: - Tested wakeup from UART after suspend for dt and non dt case. Omap5430evm: - Tested wakeup from UART after suspend for dt case. These patches were the part of the bigger series[1]. Breaking them into two relevant series as they go through the different tree. [1]: http://lkml.org/lkml/2013/4/26/274 - The following changes since commit b973425cbb51e08301b34fecdfd476a44507d8cf: Merge tag 'ext4_for_linus_stable' of git://git.kernel.org/pub/scm/linux/kernel/git/tytso/ext4 (2013-05-14 09:30:54 -0700) are available in the git repository at: git://gitorious.org/linux-connectivity/linux-connectivity.git serial_fix_resend Sourav Poddar (2): driver: tty: serial: Move "uart_console" def to core header file. driver: serial: omap: prevent runtime PM for "no_console_suspend" drivers/tty/serial/mpc52xx_uart.c | 10 -- drivers/tty/serial/omap-serial.c | 34 +- drivers/tty/serial/serial_core.c |6 -- include/linux/serial_core.h |7 +++ 4 files changed, 40 insertions(+), 17 deletions(-) -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv2 3/3] arm: dts: add bandgap entry for OMAP4460 devices
Hi Eduardo,
On 05/15/2013 04:58 PM, Eduardo Valentin wrote:
> Include bandgap devices for OMAP4460 devices.
>
> Cc: "Benoît Cousson"
> Cc: Tony Lindgren
> Cc: Russell King
> Cc: linux-omap@vger.kernel.org
> Cc: devicetree-disc...@lists.ozlabs.org
> Cc: linux-arm-ker...@lists.infradead.org
> Cc: linux-ker...@vger.kernel.org
> Signed-off-by: Eduardo Valentin
> ---
> arch/arm/boot/dts/omap4460.dtsi | 9 +
> 1 file changed, 9 insertions(+)
>
> diff --git a/arch/arm/boot/dts/omap4460.dtsi b/arch/arm/boot/dts/omap4460.dtsi
> index 2cf227c..e5bfbfe 100644
> --- a/arch/arm/boot/dts/omap4460.dtsi
> +++ b/arch/arm/boot/dts/omap4460.dtsi
> @@ -29,4 +29,13 @@
><0 55 0x4>;
> ti,hwmods = "debugss";
> };
> +
> + bandgap {
> + reg = <0x4a002260 0x4
> + 0x4a00232C 0x4
> + 0x4a002378 0x18>;
> + compatible = "ti,omap4460-bandgap";
> + interrupts = <0 126 4>; /* talert */
> + ti,tshut-gpio = <86>;
Why do you need a custom attribute for GPIO? Cannot you use the standard
one?
Where is the gpio controller phandle?
Usually it looks like this:
gpios = <&gpio1 8 0>;
Regards,
Benoit
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 0/6] ARM; OMAP2+: hwmod and SERIAL: Remove sysc handling from driver
On Friday 10 May 2013 07:32 PM, Nishanth Menon wrote: > On 11:09-20130426, Kevin Hilman wrote: >> Rajendra Nayak writes: >> >> [...] >> >>> OMAP UART IP needs manual idle modes based on functional state of the >>> IP. Currently this is handled by the driver with function pointers >>> implemented in platform code. >>> >>> This however breaks in case of device tree because of missing >>> idle handling. >>> >>> The series tries to address the issue and tries to remove complete >>> sysc handling from serial driver. >> >> Other than the minor nit about the order of the series for bisect, >> >> Reviewed-by: Kevin Hilman >> >> Also tested this on OMAP4/Panda where I was having the sluggish console >> issues using DT boot, and and can confirm that this fixes the problem: >> >> Tested-by: Kevin Hilman # OMAP4/Panda >> > I saw the same let of console sluggishness on SDP4430, Panda, Panda-ES > as well on latest linus master. > > For reference, I have rebased the series to latest master and fixes the > sequencing: > https://github.com/nmenon/linux-2.6-playground/commits/push/uart-fixes-sidle-3.10 > based on: > master 70eba42 Merge tag 'please-pull-pstore' of > git://git.kernel.org/pub/scm/linux/kernel/git/aegl/linux > > Rajendra, > Would you be able to repost this series so that we can get this into > 3.10-rc2+? Tony/Paul, I just posted the v3 of these out [1] based off 3.10-rc1. Can we pull these in into -rc since these actually fix the console sluggishness introduced in this merge window (we always had issues with UART sidle handling with DT but never saw issues in mainline because of some static deps which got removed this merge window I guess which would otherwise hide the issue). regards, Rajendra [1] http://marc.info/?l=linux-omap&m=136862939928398&w=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
[PATCHv2 3/3] arm: dts: add bandgap entry for OMAP4460 devices
Include bandgap devices for OMAP4460 devices.
Cc: "Benoît Cousson"
Cc: Tony Lindgren
Cc: Russell King
Cc: linux-omap@vger.kernel.org
Cc: devicetree-disc...@lists.ozlabs.org
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-ker...@vger.kernel.org
Signed-off-by: Eduardo Valentin
---
arch/arm/boot/dts/omap4460.dtsi | 9 +
1 file changed, 9 insertions(+)
diff --git a/arch/arm/boot/dts/omap4460.dtsi b/arch/arm/boot/dts/omap4460.dtsi
index 2cf227c..e5bfbfe 100644
--- a/arch/arm/boot/dts/omap4460.dtsi
+++ b/arch/arm/boot/dts/omap4460.dtsi
@@ -29,4 +29,13 @@
<0 55 0x4>;
ti,hwmods = "debugss";
};
+
+ bandgap {
+ reg = <0x4a002260 0x4
+ 0x4a00232C 0x4
+ 0x4a002378 0x18>;
+ compatible = "ti,omap4460-bandgap";
+ interrupts = <0 126 4>; /* talert */
+ ti,tshut-gpio = <86>;
+ };
};
--
1.8.2.1.342.gfa7285d
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCHv2 2/3] arm: dts: add bandgap entry for OMAP443x devices
This patch add the bandgap entry for OMAP4430 devices.
Cc: "Benoît Cousson"
Cc: Tony Lindgren
Cc: Russell King
Cc: linux-omap@vger.kernel.org
Cc: devicetree-disc...@lists.ozlabs.org
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-ker...@vger.kernel.org
Signed-off-by: Eduardo Valentin
---
arch/arm/boot/dts/omap443x.dtsi | 4
1 file changed, 4 insertions(+)
diff --git a/arch/arm/boot/dts/omap443x.dtsi b/arch/arm/boot/dts/omap443x.dtsi
index cccf39a..8d6c968 100644
--- a/arch/arm/boot/dts/omap443x.dtsi
+++ b/arch/arm/boot/dts/omap443x.dtsi
@@ -24,4 +24,8 @@
clock-latency = <30>; /* From legacy driver */
};
};
+ bandgap {
+ reg = <0x4a002260 0x4 0x4a00232C 0x4>;
+ compatible = "ti,omap4430-bandgap";
+ };
};
--
1.8.2.1.342.gfa7285d
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCHv2 1/3] arm: introduce config HAS_BANDGAP
Introduce HAS_BANDGAP config entry. This config is a boolean value so that arch code can flag is they feature a bandgap device. This config entry follows the same idea behind ARCH_HAS_CPUFREQ. Cc: Russell King Cc: Tony Lindgren Cc: linux-arm-ker...@lists.infradead.org Cc: linux-omap@vger.kernel.org Cc: linux-ker...@vger.kernel.org Signed-off-by: Eduardo Valentin --- arch/arm/Kconfig| 3 +++ arch/arm/mach-omap2/Kconfig | 1 + 2 files changed, 4 insertions(+) diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig index d423d58..bcbdec9 100644 --- a/arch/arm/Kconfig +++ b/arch/arm/Kconfig @@ -174,6 +174,9 @@ config ARCH_HAS_CPUFREQ and that the relevant menu configurations are displayed for it. +config ARCH_HAS_BANDGAP + bool + config GENERIC_HWEIGHT bool default y diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig index f49cd51..8620ab5 100644 --- a/arch/arm/mach-omap2/Kconfig +++ b/arch/arm/mach-omap2/Kconfig @@ -4,6 +4,7 @@ config ARCH_OMAP config ARCH_OMAP2PLUS bool "TI OMAP2/3/4/5 SoCs with device tree support" if (ARCH_MULTI_V6 || ARCH_MULTI_V7) select ARCH_HAS_CPUFREQ + select ARCH_HAS_BANDGAP select ARCH_HAS_HOLES_MEMORYMODEL select ARCH_OMAP select ARCH_REQUIRE_GPIOLIB -- 1.8.2.1.342.gfa7285d -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCHv2 0/3] arm: enable TI SoC thermal driver
Hello, Idea is to add the missing bits under arch/arm/*omap* required to enable by default the ti-soc-thermal driver. I am planing to move it out of staging tree. It would be interesting to get feedback from other ppl. By enabling it by default we could reach more ppl for testing it across the supported chips. The difference from v1 is just that patch 01 doe snot include the dts prefix, as it is not supposed to be DTS related. BR, Eduardo Valentin (3): arm: introduce config HAS_BANDGAP arm: dts: add bandgap entry for OMAP443x devices arm: dts: add bandgap entry for OMAP4460 devices arch/arm/Kconfig| 3 +++ arch/arm/boot/dts/omap443x.dtsi | 4 arch/arm/boot/dts/omap4460.dtsi | 9 + arch/arm/mach-omap2/Kconfig | 1 + 4 files changed, 17 insertions(+) -- 1.8.2.1.342.gfa7285d -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv5 1/2] driver: tty: serial: Move "uart_console" def to core header file.
On Wednesday 15 May 2013 08:27 PM, Greg KH wrote: On Wed, May 15, 2013 at 08:13:09PM +0530, Sourav Poddar wrote: Hi Greg, On Saturday 27 April 2013 03:48 AM, Greg KH wrote: On Fri, Apr 26, 2013 at 03:03:07PM -0700, Kevin Hilman wrote: Hi Greg, Sourav Poddar writes: Move "uart_console" definition to serial core header file, so that it can be used by serial drivers. Get rid of the uart_console defintion from mpc52xx_uart driver. Cc: Santosh Shilimkar Cc: Felipe Balbi Cc: Rajendra nayak Signed-off-by: Sourav Poddar Reviewed-by: Felipe Balbi Can you queue up this patch (and 2/2)? Once these are in, I will queue up the corresponding arch/arm changes which can go independently. And feel free to add Reviewed-by: Kevin Hilman Tested-by: Kevin Hilman I will do so after 3.10-rc1 is out, it is _way_ too late in the development cycle for me to add these to my trees right now, considering they are pretty much closed at the moment. Do you want me to rebase this patches on top of 3.10-rc1? That would be great to have, thanks. greg k-h Ok. Will do that and resend. -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCHv2 0/3] arm: enable TI SoC thermal driver
Hello, Idea is to add the missing bits under arch/arm/*omap* required to enable by default the ti-soc-thermal driver. I am planing to move it out of staging tree. It would be interesting to get feedback from other ppl. By enabling it by default we could reach more ppl for testing it across the supported chips. The difference from v1 is just that patch 01 doe snot include the dts prefix, as it is not supposed to be DTS related. BR, Eduardo Valentin (3): arm: introduce config HAS_BANDGAP arm: dts: add bandgap entry for OMAP443x devices arm: dts: add bandgap entry for OMAP4460 devices arch/arm/Kconfig| 3 +++ arch/arm/boot/dts/omap443x.dtsi | 4 arch/arm/boot/dts/omap4460.dtsi | 9 + arch/arm/mach-omap2/Kconfig | 1 + 4 files changed, 17 insertions(+) -- 1.8.2.1.342.gfa7285d -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv5 1/2] driver: tty: serial: Move "uart_console" def to core header file.
On Wed, May 15, 2013 at 08:13:09PM +0530, Sourav Poddar wrote: > Hi Greg, > On Saturday 27 April 2013 03:48 AM, Greg KH wrote: > >On Fri, Apr 26, 2013 at 03:03:07PM -0700, Kevin Hilman wrote: > >>Hi Greg, > >> > >>Sourav Poddar writes: > >> > >>>Move "uart_console" definition to serial core header file, so that it can > >>>be > >>>used by serial drivers. > >>>Get rid of the uart_console defintion from mpc52xx_uart driver. > >>> > >>>Cc: Santosh Shilimkar > >>>Cc: Felipe Balbi > >>>Cc: Rajendra nayak > >>>Signed-off-by: Sourav Poddar > >>>Reviewed-by: Felipe Balbi > >>Can you queue up this patch (and 2/2)? Once these are in, I will queue > >>up the corresponding arch/arm changes which can go independently. > >> > >>And feel free to add > >> > >>Reviewed-by: Kevin Hilman > >>Tested-by: Kevin Hilman > >I will do so after 3.10-rc1 is out, it is _way_ too late in the > >development cycle for me to add these to my trees right now, considering > >they are pretty much closed at the moment. > > > Do you want me to rebase this patches on top of 3.10-rc1? That would be great to have, thanks. greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3 4/6] ARM: OMAP2+: serial: Remove the un-used slave idle hooks
From: Santosh Shilimkar
UART IP idle handling now taken care by runtime pm backend(hwmod) indirectly
and OMAP serial driver is also cleaned up accordingly.
So remove the un-used slave idle platforms hooks now.
Tested-by: Vaibhav Bedia
Tested-by: Sourav Poddar
Signed-off-by: Rajendra nayak
Signed-off-by: Santosh Shilimkar
---
arch/arm/mach-omap2/serial.c | 31 ---
1 file changed, 31 deletions(-)
diff --git a/arch/arm/mach-omap2/serial.c b/arch/arm/mach-omap2/serial.c
index 8396b5b..f660156 100644
--- a/arch/arm/mach-omap2/serial.c
+++ b/arch/arm/mach-omap2/serial.c
@@ -95,38 +95,9 @@ static void omap_uart_enable_wakeup(struct device *dev, bool
enable)
omap_hwmod_disable_wakeup(od->hwmods[0]);
}
-/*
- * Errata i291: [UART]:Cannot Acknowledge Idle Requests
- * in Smartidle Mode When Configured for DMA Operations.
- * WA: configure uart in force idle mode.
- */
-static void omap_uart_set_noidle(struct device *dev)
-{
- struct platform_device *pdev = to_platform_device(dev);
- struct omap_device *od = to_omap_device(pdev);
-
- omap_hwmod_set_slave_idlemode(od->hwmods[0], HWMOD_IDLEMODE_NO);
-}
-
-static void omap_uart_set_smartidle(struct device *dev)
-{
- struct platform_device *pdev = to_platform_device(dev);
- struct omap_device *od = to_omap_device(pdev);
- u8 idlemode;
-
- if (od->hwmods[0]->class->sysc->idlemodes & SIDLE_SMART_WKUP)
- idlemode = HWMOD_IDLEMODE_SMART_WKUP;
- else
- idlemode = HWMOD_IDLEMODE_SMART;
-
- omap_hwmod_set_slave_idlemode(od->hwmods[0], idlemode);
-}
-
#else
static void omap_uart_enable_wakeup(struct device *dev, bool enable)
{}
-static void omap_uart_set_noidle(struct device *dev) {}
-static void omap_uart_set_smartidle(struct device *dev) {}
#endif /* CONFIG_PM */
#ifdef CONFIG_OMAP_MUX
@@ -299,8 +270,6 @@ void __init omap_serial_init_port(struct omap_board_data
*bdata,
omap_up.uartclk = OMAP24XX_BASE_BAUD * 16;
omap_up.flags = UPF_BOOT_AUTOCONF;
omap_up.get_context_loss_count = omap_pm_get_dev_context_loss_count;
- omap_up.set_forceidle = omap_uart_set_smartidle;
- omap_up.set_noidle = omap_uart_set_noidle;
omap_up.enable_wakeup = omap_uart_enable_wakeup;
omap_up.dma_rx_buf_size = info->dma_rx_buf_size;
omap_up.dma_rx_timeout = info->dma_rx_timeout;
--
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
[PATCH v3 1/6] ARM: OMAP2+: hwmod: Fix sidle programming in _enable_sysc()/_idle_sysc()
_enable_sysc() and _idle_sysc() handle the midle mode programming correctly
and program HWMOD_IDLEMODE_SMART or HWMOD_IDLEMODE_SMART_WKUP respectively
for supported IPs (The ones which support hardware controlled midle modes)
However the same programming logic is missing when it comes to sidle mode
programming. Here they seem to just set HWMOD_IDLEMODE_SMART (Again for the
ones which support hardware controlled sidle modes)
This problem was hidden due to the fact that a call to _enable_wakeup()
in those same functions would overwrite the idlemodes and program them
correctly (to HWMOD_IDLEMODE_SMART_WKUP in the supported cases)
So fix the sidlemode handling correctly in these functions and handle the
_enable_wakeup() for SIDLEMODE supported IPs same as the way its handled
for MIDLEMODE supported ones.
Tested-by: Vaibhav Bedia
Tested-by: Sourav Poddar
Signed-off-by: Rajendra Nayak
Signed-off-by: Santosh Shilimkar
---
arch/arm/mach-omap2/omap_hwmod.c | 42 +++---
1 file changed, 25 insertions(+), 17 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod.c b/arch/arm/mach-omap2/omap_hwmod.c
index d25a95f..c28552b 100644
--- a/arch/arm/mach-omap2/omap_hwmod.c
+++ b/arch/arm/mach-omap2/omap_hwmod.c
@@ -1356,13 +1356,26 @@ static void _enable_sysc(struct omap_hwmod *oh)
clkdm = _get_clkdm(oh);
if (sf & SYSC_HAS_SIDLEMODE) {
+ if (oh->flags & HWMOD_SWSUP_SIDLE) {
+ idlemode = HWMOD_IDLEMODE_NO;
+ } else {
+ if (sf & SYSC_HAS_ENAWAKEUP)
+ _enable_wakeup(oh, &v);
+ if (oh->class->sysc->idlemodes & SIDLE_SMART_WKUP)
+ idlemode = HWMOD_IDLEMODE_SMART_WKUP;
+ else
+ idlemode = HWMOD_IDLEMODE_SMART;
+ }
+
+ /*
+* This is special handling for some IPs like
+* 32k sync timer. Force them to idle!
+*/
clkdm_act = (clkdm && clkdm->flags & CLKDM_ACTIVE_WITH_MPU);
if (clkdm_act && !(oh->class->sysc->idlemodes &
(SIDLE_SMART | SIDLE_SMART_WKUP)))
idlemode = HWMOD_IDLEMODE_FORCE;
- else
- idlemode = (oh->flags & HWMOD_SWSUP_SIDLE) ?
- HWMOD_IDLEMODE_NO : HWMOD_IDLEMODE_SMART;
+
_set_slave_idlemode(oh, idlemode, &v);
}
@@ -1391,10 +1404,6 @@ static void _enable_sysc(struct omap_hwmod *oh)
(sf & SYSC_HAS_CLOCKACTIVITY))
_set_clockactivity(oh, oh->class->sysc->clockact, &v);
- /* If slave is in SMARTIDLE, also enable wakeup */
- if ((sf & SYSC_HAS_SIDLEMODE) && !(oh->flags & HWMOD_SWSUP_SIDLE))
- _enable_wakeup(oh, &v);
-
_write_sysconfig(v, oh);
/*
@@ -1430,13 +1439,16 @@ static void _idle_sysc(struct omap_hwmod *oh)
sf = oh->class->sysc->sysc_flags;
if (sf & SYSC_HAS_SIDLEMODE) {
- /* XXX What about HWMOD_IDLEMODE_SMART_WKUP? */
- if (oh->flags & HWMOD_SWSUP_SIDLE ||
- !(oh->class->sysc->idlemodes &
- (SIDLE_SMART | SIDLE_SMART_WKUP)))
+ if (oh->flags & HWMOD_SWSUP_SIDLE) {
idlemode = HWMOD_IDLEMODE_FORCE;
- else
- idlemode = HWMOD_IDLEMODE_SMART;
+ } else {
+ if (sf & SYSC_HAS_ENAWAKEUP)
+ _enable_wakeup(oh, &v);
+ if (oh->class->sysc->idlemodes & SIDLE_SMART_WKUP)
+ idlemode = HWMOD_IDLEMODE_SMART_WKUP;
+ else
+ idlemode = HWMOD_IDLEMODE_SMART;
+ }
_set_slave_idlemode(oh, idlemode, &v);
}
@@ -1455,10 +1467,6 @@ static void _idle_sysc(struct omap_hwmod *oh)
_set_master_standbymode(oh, idlemode, &v);
}
- /* If slave is in SMARTIDLE, also enable wakeup */
- if ((sf & SYSC_HAS_SIDLEMODE) && !(oh->flags & HWMOD_SWSUP_SIDLE))
- _enable_wakeup(oh, &v);
-
_write_sysconfig(v, oh);
}
--
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
[PATCH v3 5/6] SERIAL: OMAP: Remove the slave idle handling from the driver
From: Santosh Shilimkar
UART IP slave idle handling now taken care by runtime pm backend(hwmod layer)
so remove the hackery from the driver.
As discussed on the list, in future if dma mode needs to be brought
back to this driver, UART sysc handling needs to be updated in
framework such a way that no-idle/force idle profile can be supported.
Given the broken dma mode for OMAP uarts, its very unlikely.
Acked-by: Greg Kroah-Hartman
Tested-by: Vaibhav Bedia
Tested-by: Sourav Poddar
Signed-off-by: Rajendra nayak
Signed-off-by: Santosh Shilimkar
---
drivers/tty/serial/omap-serial.c | 23 ---
include/linux/platform_data/serial-omap.h |2 --
2 files changed, 25 deletions(-)
diff --git a/drivers/tty/serial/omap-serial.c b/drivers/tty/serial/omap-serial.c
index 30d4f7a..f0b9f6b 100644
--- a/drivers/tty/serial/omap-serial.c
+++ b/drivers/tty/serial/omap-serial.c
@@ -202,26 +202,6 @@ static int serial_omap_get_context_loss_count(struct
uart_omap_port *up)
return pdata->get_context_loss_count(up->dev);
}
-static void serial_omap_set_forceidle(struct uart_omap_port *up)
-{
- struct omap_uart_port_info *pdata = up->dev->platform_data;
-
- if (!pdata || !pdata->set_forceidle)
- return;
-
- pdata->set_forceidle(up->dev);
-}
-
-static void serial_omap_set_noidle(struct uart_omap_port *up)
-{
- struct omap_uart_port_info *pdata = up->dev->platform_data;
-
- if (!pdata || !pdata->set_noidle)
- return;
-
- pdata->set_noidle(up->dev);
-}
-
static void serial_omap_enable_wakeup(struct uart_omap_port *up, bool enable)
{
struct omap_uart_port_info *pdata = up->dev->platform_data;
@@ -298,8 +278,6 @@ static void serial_omap_stop_tx(struct uart_port *port)
serial_out(up, UART_IER, up->ier);
}
- serial_omap_set_forceidle(up);
-
pm_runtime_mark_last_busy(up->dev);
pm_runtime_put_autosuspend(up->dev);
}
@@ -364,7 +342,6 @@ static void serial_omap_start_tx(struct uart_port *port)
pm_runtime_get_sync(up->dev);
serial_omap_enable_ier_thri(up);
- serial_omap_set_noidle(up);
pm_runtime_mark_last_busy(up->dev);
pm_runtime_put_autosuspend(up->dev);
}
diff --git a/include/linux/platform_data/serial-omap.h
b/include/linux/platform_data/serial-omap.h
index ff9b0aa..c860c1b 100644
--- a/include/linux/platform_data/serial-omap.h
+++ b/include/linux/platform_data/serial-omap.h
@@ -43,8 +43,6 @@ struct omap_uart_port_info {
int DTR_present;
int (*get_context_loss_count)(struct device *);
- void (*set_forceidle)(struct device *);
- void (*set_noidle)(struct device *);
void (*enable_wakeup)(struct device *, bool);
};
--
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
[PATCH v3 0/6] ARM: OMAP2+: hwmod and SERIAL: Remove sysc handling from driver
changes in v3: 1. Fix the patch ordering issue (which otherwise broke git-bisect) as pointed out by Kevin Hilman. I missed re-sending these out with the fix in time for the 3.10 merge window. Thanks to Nishanth Menon for picking these up and doing a rebase against 3.10-rc1. Thanks also to Sourav and Vaibhav Bedia for running tests on 4430sdp and beaglebone. changes in v2: --- 1. Addressed the concerns from Paul Wamsley around cleanups in _enable_wakeup()/_disable_wakeup(), and left them intact 2. Updates in changelogs in the serial patch about changes needed when dma support is added back for serial 3. Dropped 1/8 from v1 since its already pulled in The patches are based of 'fixes-non-critical' branch of 'git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap' tree since patch 1/8 from v1 was pulled in here. Patches can be found here: git://github.com/rrnayak/linux.git sysc-cleanups --- OMAP UART IP needs manual idle modes based on functional state of the IP. Currently this is handled by the driver with function pointers implemented in platform code. This however breaks in case of device tree because of missing idle handling. The series tries to address the issue and tries to remove complete sysc handling from serial driver. Patches has been tested on OMAP4430 SDP and OMAP5 EVM where the console sluggishness was observed without idle mode handling. CPUIDLE and suspend tested ok on these devices. Thanks to Vaibhav Bedia for testing on Beaglebone(AM33XX) with suspend and also the UART async wakeup from suspend. Thanks to Sourav Poddar for Beagle XM(OMAP3630) devices testing with retention and offmode in Idle and suspend for non-DT builds. Serial driver platform code still has one more function pointer left which is used to trigger io_ring(). This one needs some discussion with pincontrol driver folks on how to implement such a feature with generic pincontrol driver. Rajendra Nayak (2): ARM: OMAP2+: hwmod: Fix sidle programming in _enable_sysc()/_idle_sysc() ARM: OMAP2+: hwmod: Add a new flag to handle SIDLE in SWSUP only in active Santosh Shilimkar (4): ARM: OMAP2+: hwmod-data: UART IP needs software control to manage sidle modes ARM: OMAP2+: serial: Remove the un-used slave idle hooks SERIAL: OMAP: Remove the slave idle handling from the driver ARM: OMAP2+: hwmod: Remove sysc slave idle and auto idle apis arch/arm/mach-omap2/omap_hwmod.c | 111 +--- arch/arm/mach-omap2/omap_hwmod.h |7 +- arch/arm/mach-omap2/omap_hwmod_2xxx_ipblock_data.c |3 + arch/arm/mach-omap2/omap_hwmod_33xx_data.c |6 ++ arch/arm/mach-omap2/omap_hwmod_3xxx_data.c |4 + arch/arm/mach-omap2/omap_hwmod_44xx_data.c |6 +- arch/arm/mach-omap2/serial.c | 31 -- drivers/tty/serial/omap-serial.c | 23 include/linux/platform_data/serial-omap.h |2 - 9 files changed, 48 insertions(+), 145 deletions(-) -- 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
[PATCH v3 2/6] ARM: OMAP2+: hwmod: Add a new flag to handle SIDLE in SWSUP only in active
Some IPs (like UART) need the sidle mode to be controlled in SW only
while they are active. Once they go inactive, they need the IP to be
put back in HW control so they are also wakeup capable.
The flag HWMOD_SWSUP_SIDLE takes care of IPs which need the sidle
mode to be *always* controlled in SWSUP. We now have a need to control
IPs sidle mode in SWSUP only while its active.
So define a new flag 'HWMOD_SWSUP_SIDLE_ACT' to help the framework
know about these new IP requirements.
Tested-by: Vaibhav Bedia
Tested-by: Sourav Poddar
Signed-off-by: Rajendra Nayak
Signed-off-by: Santosh Shilimkar
---
arch/arm/mach-omap2/omap_hwmod.c |3 ++-
arch/arm/mach-omap2/omap_hwmod.h |4
2 files changed, 6 insertions(+), 1 deletion(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod.c b/arch/arm/mach-omap2/omap_hwmod.c
index c28552b..5739429 100644
--- a/arch/arm/mach-omap2/omap_hwmod.c
+++ b/arch/arm/mach-omap2/omap_hwmod.c
@@ -1356,7 +1356,8 @@ static void _enable_sysc(struct omap_hwmod *oh)
clkdm = _get_clkdm(oh);
if (sf & SYSC_HAS_SIDLEMODE) {
- if (oh->flags & HWMOD_SWSUP_SIDLE) {
+ if (oh->flags & HWMOD_SWSUP_SIDLE ||
+ oh->flags & HWMOD_SWSUP_SIDLE_ACT) {
idlemode = HWMOD_IDLEMODE_NO;
} else {
if (sf & SYSC_HAS_ENAWAKEUP)
diff --git a/arch/arm/mach-omap2/omap_hwmod.h b/arch/arm/mach-omap2/omap_hwmod.h
index fe59629..8498774 100644
--- a/arch/arm/mach-omap2/omap_hwmod.h
+++ b/arch/arm/mach-omap2/omap_hwmod.h
@@ -463,6 +463,9 @@ struct omap_hwmod_omap4_prcm {
* is kept in force-standby mode. Failing to do so causes PM problems
* with musb on OMAP3630 at least. Note that musb has a dedicated register
* to control MSTANDBY signal when MIDLEMODE is set to force-standby.
+ * HWMOD_SWSUP_SIDLE_ACT: omap_hwmod code should manually bring the module
+ * out of idle, but rely on smart-idle to the put it back in idle,
+ * so the wakeups are still functional (Only known case for now is UART)
*/
#define HWMOD_SWSUP_SIDLE (1 << 0)
#define HWMOD_SWSUP_MSTANDBY (1 << 1)
@@ -476,6 +479,7 @@ struct omap_hwmod_omap4_prcm {
#define HWMOD_EXT_OPT_MAIN_CLK (1 << 9)
#define HWMOD_BLOCK_WFI(1 << 10)
#define HWMOD_FORCE_MSTANDBY (1 << 11)
+#define HWMOD_SWSUP_SIDLE_ACT (1 << 12)
/*
* omap_hwmod._int_flags definitions
--
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
[PATCH v3 6/6] ARM: OMAP2+: hwmod: Remove sysc slave idle and auto idle apis
From: Santosh Shilimkar
With the OMAP serial driver sysc cleanup patches in this series, we can
now remove the hwmod external apis for sysc fiddling.
While at this, also remove unused sysc auto idle api from hwmod code.
Tested-by: Vaibhav Bedia
Tested-by: Sourav Poddar
Signed-off-by: Rajendra nayak
Signed-off-by: Santosh Shilimkar
---
arch/arm/mach-omap2/omap_hwmod.c | 68 --
arch/arm/mach-omap2/omap_hwmod.h |3 --
2 files changed, 71 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod.c b/arch/arm/mach-omap2/omap_hwmod.c
index 5739429..0393142 100644
--- a/arch/arm/mach-omap2/omap_hwmod.c
+++ b/arch/arm/mach-omap2/omap_hwmod.c
@@ -2255,42 +2255,6 @@ static int _idle(struct omap_hwmod *oh)
}
/**
- * omap_hwmod_set_ocp_autoidle - set the hwmod's OCP autoidle bit
- * @oh: struct omap_hwmod *
- * @autoidle: desired AUTOIDLE bitfield value (0 or 1)
- *
- * Sets the IP block's OCP autoidle bit in hardware, and updates our
- * local copy. Intended to be used by drivers that require
- * direct manipulation of the AUTOIDLE bits.
- * Returns -EINVAL if @oh is null or is not in the ENABLED state, or passes
- * along the return value from _set_module_autoidle().
- *
- * Any users of this function should be scrutinized carefully.
- */
-int omap_hwmod_set_ocp_autoidle(struct omap_hwmod *oh, u8 autoidle)
-{
- u32 v;
- int retval = 0;
- unsigned long flags;
-
- if (!oh || oh->_state != _HWMOD_STATE_ENABLED)
- return -EINVAL;
-
- spin_lock_irqsave(&oh->_lock, flags);
-
- v = oh->_sysc_cache;
-
- retval = _set_module_autoidle(oh, autoidle, &v);
-
- if (!retval)
- _write_sysconfig(v, oh);
-
- spin_unlock_irqrestore(&oh->_lock, flags);
-
- return retval;
-}
-
-/**
* _shutdown - shutdown an omap_hwmod
* @oh: struct omap_hwmod *
*
@@ -3189,38 +3153,6 @@ error:
}
/**
- * omap_hwmod_set_slave_idlemode - set the hwmod's OCP slave idlemode
- * @oh: struct omap_hwmod *
- * @idlemode: SIDLEMODE field bits (shifted to bit 0)
- *
- * Sets the IP block's OCP slave idlemode in hardware, and updates our
- * local copy. Intended to be used by drivers that have some erratum
- * that requires direct manipulation of the SIDLEMODE bits. Returns
- * -EINVAL if @oh is null, or passes along the return value from
- * _set_slave_idlemode().
- *
- * XXX Does this function have any current users? If not, we should
- * remove it; it is better to let the rest of the hwmod code handle this.
- * Any users of this function should be scrutinized carefully.
- */
-int omap_hwmod_set_slave_idlemode(struct omap_hwmod *oh, u8 idlemode)
-{
- u32 v;
- int retval = 0;
-
- if (!oh)
- return -EINVAL;
-
- v = oh->_sysc_cache;
-
- retval = _set_slave_idlemode(oh, idlemode, &v);
- if (!retval)
- _write_sysconfig(v, oh);
-
- return retval;
-}
-
-/**
* omap_hwmod_lookup - look up a registered omap_hwmod by name
* @name: name of the omap_hwmod to look up
*
diff --git a/arch/arm/mach-omap2/omap_hwmod.h b/arch/arm/mach-omap2/omap_hwmod.h
index 8498774..0c898f5 100644
--- a/arch/arm/mach-omap2/omap_hwmod.h
+++ b/arch/arm/mach-omap2/omap_hwmod.h
@@ -645,9 +645,6 @@ int omap_hwmod_read_hardreset(struct omap_hwmod *oh, const
char *name);
int omap_hwmod_enable_clocks(struct omap_hwmod *oh);
int omap_hwmod_disable_clocks(struct omap_hwmod *oh);
-int omap_hwmod_set_slave_idlemode(struct omap_hwmod *oh, u8 idlemode);
-int omap_hwmod_set_ocp_autoidle(struct omap_hwmod *oh, u8 autoidle);
-
int omap_hwmod_reset(struct omap_hwmod *oh);
void omap_hwmod_ocp_barrier(struct omap_hwmod *oh);
--
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
[PATCH v3 3/6] ARM: OMAP2+: hwmod-data: UART IP needs software control to manage sidle modes
From: Santosh Shilimkar
OMAP UART IP needs software control for slave idle modes based on functional
state of the IP. i.e The IP slave idle settings should be set to 'noidle' when
being used and then put back to 'smart_idle' when unused. Currently this is
handled by the driver with function pointers implemented in platform code.
This however breaks in case of device tree because of missing idle handling
APIs.
Previous patches in this series added a flag HWMOD_SWSUP_SIDLE_ACTIVE which
takes care of the mentioned requirement. Hence add the flag for all UART IPs
to take advantage of feature supported by framework.
Subsequent patches removes the slave idle handling from driver code.
Tested-by: Vaibhav Bedia
Tested-by: Sourav Poddar
Signed-off-by: Rajendra Nayak
Signed-off-by: Santosh Shilimkar
---
arch/arm/mach-omap2/omap_hwmod_2xxx_ipblock_data.c |3 +++
arch/arm/mach-omap2/omap_hwmod_33xx_data.c |6 ++
arch/arm/mach-omap2/omap_hwmod_3xxx_data.c |4
arch/arm/mach-omap2/omap_hwmod_44xx_data.c |6 +-
4 files changed, 18 insertions(+), 1 deletion(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod_2xxx_ipblock_data.c
b/arch/arm/mach-omap2/omap_hwmod_2xxx_ipblock_data.c
index c8c64b3..d05fc7b 100644
--- a/arch/arm/mach-omap2/omap_hwmod_2xxx_ipblock_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_2xxx_ipblock_data.c
@@ -512,6 +512,7 @@ struct omap_hwmod omap2xxx_uart1_hwmod = {
.mpu_irqs = omap2_uart1_mpu_irqs,
.sdma_reqs = omap2_uart1_sdma_reqs,
.main_clk = "uart1_fck",
+ .flags = HWMOD_SWSUP_SIDLE_ACT,
.prcm = {
.omap2 = {
.module_offs = CORE_MOD,
@@ -531,6 +532,7 @@ struct omap_hwmod omap2xxx_uart2_hwmod = {
.mpu_irqs = omap2_uart2_mpu_irqs,
.sdma_reqs = omap2_uart2_sdma_reqs,
.main_clk = "uart2_fck",
+ .flags = HWMOD_SWSUP_SIDLE_ACT,
.prcm = {
.omap2 = {
.module_offs = CORE_MOD,
@@ -550,6 +552,7 @@ struct omap_hwmod omap2xxx_uart3_hwmod = {
.mpu_irqs = omap2_uart3_mpu_irqs,
.sdma_reqs = omap2_uart3_sdma_reqs,
.main_clk = "uart3_fck",
+ .flags = HWMOD_SWSUP_SIDLE_ACT,
.prcm = {
.omap2 = {
.module_offs = CORE_MOD,
diff --git a/arch/arm/mach-omap2/omap_hwmod_33xx_data.c
b/arch/arm/mach-omap2/omap_hwmod_33xx_data.c
index 01d8f32..075f7cc 100644
--- a/arch/arm/mach-omap2/omap_hwmod_33xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_33xx_data.c
@@ -1995,6 +1995,7 @@ static struct omap_hwmod am33xx_uart1_hwmod = {
.name = "uart1",
.class = &uart_class,
.clkdm_name = "l4_wkup_clkdm",
+ .flags = HWMOD_SWSUP_SIDLE_ACT,
.mpu_irqs = am33xx_uart1_irqs,
.sdma_reqs = uart1_edma_reqs,
.main_clk = "dpll_per_m2_div4_wkupdm_ck",
@@ -2015,6 +2016,7 @@ static struct omap_hwmod am33xx_uart2_hwmod = {
.name = "uart2",
.class = &uart_class,
.clkdm_name = "l4ls_clkdm",
+ .flags = HWMOD_SWSUP_SIDLE_ACT,
.mpu_irqs = am33xx_uart2_irqs,
.sdma_reqs = uart1_edma_reqs,
.main_clk = "dpll_per_m2_div4_ck",
@@ -2042,6 +2044,7 @@ static struct omap_hwmod am33xx_uart3_hwmod = {
.name = "uart3",
.class = &uart_class,
.clkdm_name = "l4ls_clkdm",
+ .flags = HWMOD_SWSUP_SIDLE_ACT,
.mpu_irqs = am33xx_uart3_irqs,
.sdma_reqs = uart3_edma_reqs,
.main_clk = "dpll_per_m2_div4_ck",
@@ -2062,6 +2065,7 @@ static struct omap_hwmod am33xx_uart4_hwmod = {
.name = "uart4",
.class = &uart_class,
.clkdm_name = "l4ls_clkdm",
+ .flags = HWMOD_SWSUP_SIDLE_ACT,
.mpu_irqs = am33xx_uart4_irqs,
.sdma_reqs = uart1_edma_reqs,
.main_clk = "dpll_per_m2_div4_ck",
@@ -2082,6 +2086,7 @@ static struct omap_hwmod am33xx_uart5_hwmod = {
.name = "uart5",
.class = &uart_class,
.clkdm_name = "l4ls_clkdm",
+ .flags = HWMOD_SWSUP_SIDLE_ACT,
.mpu_irqs = am33xx_uart5_irqs,
.sdma_reqs = uart1_edma_reqs,
.main_clk = "dpll_per_m2_div4_ck",
@@ -2102,6 +2107,7 @@ static struct omap_hwmod am33xx_uart6_hwmod = {
.name = "uart6",
.class = &uart_class,
.clkdm_name = "l4ls_clkdm",
+ .flags = HWMOD_SWSUP_SIDLE_ACT,
.mpu_irqs = am33xx_uart6_irqs,
.sdma_reqs = uart1_edma_reqs,
.main_clk = "dpll_per_m2_div4_ck",
diff --git a/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
b/arch/arm/mach-omap2/omap_hwmod_3xxx_da
Re: [PATCHv5 1/2] driver: tty: serial: Move "uart_console" def to core header file.
Hi Greg, On Saturday 27 April 2013 03:48 AM, Greg KH wrote: On Fri, Apr 26, 2013 at 03:03:07PM -0700, Kevin Hilman wrote: Hi Greg, Sourav Poddar writes: Move "uart_console" definition to serial core header file, so that it can be used by serial drivers. Get rid of the uart_console defintion from mpc52xx_uart driver. Cc: Santosh Shilimkar Cc: Felipe Balbi Cc: Rajendra nayak Signed-off-by: Sourav Poddar Reviewed-by: Felipe Balbi Can you queue up this patch (and 2/2)? Once these are in, I will queue up the corresponding arch/arm changes which can go independently. And feel free to add Reviewed-by: Kevin Hilman Tested-by: Kevin Hilman I will do so after 3.10-rc1 is out, it is _way_ too late in the development cycle for me to add these to my trees right now, considering they are pretty much closed at the moment. Do you want me to rebase this patches on top of 3.10-rc1? thanks, greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: usb: musb: Fix LapDock enumeration on omap for boot and slow cable insertion
On Fri, May 03, 2013 at 11:01:33AM -0700, Tony Lindgren wrote: > * Tony Lindgren [130503 10:55]: > > Looks like we can get VBUS interrupt before the ID interrupt how can this happen ? VBUS interrupt happens when you connect to a port which is sourcing VBUS to you, while ID interrupt happens when ID is grounded, meaning that you should be sourcing VBUS. Have you hacked a Hub to backfeed 5V to OMAP by any chance ? -- balbi signature.asc Description: Digital signature
omap3 : isp clock a : Difference between dmesg frequency and actual frequency with 3.9
Hi, I am working on a dm3730 based camera. The sensor input clock is provided by the cpu via the CAM_XCLK pin. Here is the corresponding log : [9.115966] Entering cam_set_xclk [9.119781] omap3isp omap3isp: isp_set_xclk(): cam_xclka set to 24685714 Hz [9.121337] ov10x33 1-0010: sensor id : 0xa630 [ 10.293640] Entering cam_set_xclk [ 10.297149] omap3isp omap3isp: isp_set_xclk(): cam_xclka set to 0 Hz [ 10.393920] Entering cam_set_xclk [ 10.397979] omap3isp omap3isp: isp_set_xclk(): cam_xclka set to 24685714 Hz However, when mesured on the actual pin, the frequency is around 30 MHz The crystal clock is 19.2 MHz All this was correct with 3.6.11. Jean-Philippe Francois -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 2/3] gpio/omap: modify wake-up register with interrupt enable.
On Wednesday 15 May 2013 02:24 AM, Andreas Fenkart wrote: > OMAP4430 TRM chap. 25.4.5.2 > To reduce dynamic consumption, an efficient idle scheme is based on the > following: > • An efficient local autoclock gating for each module > • The implementation of control sideband signals between the PRCM module > and each module > This enhanced idle control allows clocks to be activated and deactivated > safely without requiring complex software management. The idle mode > request, idle acknowledge, and wake-up request are sideband signals > between the PRCM module and the general-purpose interface > > OMAP4430 TRM chap. 25.4.6.2 > There must be a correlation between the wake-up enable and interrupt > enable register. If a GPIO pin has a wake-up configured on it, it must > also have the corresponding interrupt enabled. Otherwise, it is possible > there is a wake-up event, but after exiting the IDLE state, no interrupt > is generated; the corresponding bit from the interrupt status register is > not cleared, and the module does not acknowledge a future idle request. > > Up to now _set_gpio_triggering() is also handling the wake-up enable > register. According the TRM this should be in sync with the interrupt > enable. Wakeup is still enabled by default, since the module would not > wake from idle otherwise. > The enabled_wakeup_gpios was introduced to remember an explicit > _set_gpio_wakeup beyond a mask/unmask cycle. Calling the flag flag > disabled_wakeup_gpios would spare the problem of initializing it, but > feels very unnatural to read. > > Wakeup functionality is completely untested, since the AM335x > lacks a IRQWAKEN register. > > Signed-off-by: Andreas Fenkart > --- I am ok with the subject patch and other two patches. Would be good to get a tested by at least for though for OMAP4 and OMAP3. I have no access to boards for few weeks so can't test it myself. Other than that, for all three patches, Acked-by: Santosh Shilimkar -- 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: OMAP5: select SCU
On Tuesday 14 May 2013 10:27 PM, Vincent Stehlé wrote: > From: Vincent Stehlé > > OMAP5 needs SCU in SMP. > > This fixes the following link errors: > > arch/arm/mach-omap2/built-in.o: In function `scu_gp_set': > arch/arm/mach-omap2/sleep44xx.S:132: undefined reference to `scu_power_mode' > arch/arm/mach-omap2/built-in.o: In function `scu_gp_clear': > arch/arm/mach-omap2/sleep44xx.S:229: undefined reference to `scu_power_mode' > arch/arm/mach-omap2/built-in.o: In function `omap4_smp_prepare_cpus': > arch/arm/mach-omap2/omap-smp.c:211: undefined reference to `scu_enable' > arch/arm/mach-omap2/built-in.o: In function `omap4_smp_init_cpus': > arch/arm/mach-omap2/omap-smp.c:185: undefined reference to > `scu_get_core_count' > > Signed-off-by: Vincent Stehlé > --- OMAP5 doesn't need the SCU. So Nak for the patch. I haven't noticed this earlier. Do you know which commit broke this ? Regards, Santosh -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3] ARM:dts:omap4-panda:Update the LED support for the panda DTS
NM
On 05/15/2013 12:29 AM, Nishanth Menon wrote:
> $subject - add a space?
> s/ARM:dts:omap4-panda:Update/ARM: dts: omap4-panda: Update/ ?
Will fix.
> On 09:17-20130514, Dan Murphy wrote:
>> The GPIO for LED D1 on the omap4-panda a1-a3 rev and the omap4-panda-es
>> are different.
>>
>> A1-A3 = gpio_wk7
> Thanks for fixing this - this is a key fix else, GPIO_7 which controls
> VSEL for VDD_MPU on PandaBoard-ES will create all kind of ruckus (change
> voltage on heartbeat)!
>> ES = gpio_110
>>
>> There is no change to LED D2
>>
>> Abstract away the pinmux and the LED definitions for the two boards into
>> the respective DTS files.
>>
>> Signed-off-by: Dan Murphy
>> ---
> [...]
>> diff --git a/arch/arm/boot/dts/omap4-panda-es.dts
>> b/arch/arm/boot/dts/omap4-panda-es.dts
>> index f1d8c21..8d1ba03 100644
>> --- a/arch/arm/boot/dts/omap4-panda-es.dts
>> +++ b/arch/arm/boot/dts/omap4-panda-es.dts
>> @@ -34,3 +34,43 @@
>> 0x5e 0x100 /* hdmi_sda.hdmi_sda INPUT | MODE 0 */
>> >;
>> };
>> +
>> +&leds {
>> +compatible = "gpio-leds";
>> +heartbeat {
>> +label = "pandaboard::status1";
>> +gpios = <&gpio4 14 0>;
>> +linux,default-trigger = "heartbeat";
>> +};
>> +mmc {
>> +label = "pandaboard::status2";
>> +gpios = <&gpio1 8 0>;
>> +linux,default-trigger = "gpio";
> mmc0?
Good point why would I call it mmc and then set the trigger to gpio.
Will fix it.
>> +};
>> +};
>> +
> Other that that,
> Tested-by: Nishanth Menon
--
--
Dan Murphy
--
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: change the device names in usb_bind_phy
On 23/04/13 09:14, Kishon Vijay Abraham I wrote:
> After the device names are created using PLATFORM_DEVID_AUTO, the old
> device names given in usb_bind_phy are no longer valid causing the musb
> controller not to get the phy reference. Updated the usb_bind_phy with
> the new device names to get MUSB functional in omap4 panda.
>
> Signed-off-by: Kishon Vijay Abraham I
> ---
> Tested in OMAP4 PANDA.
> arch/arm/mach-omap2/board-4430sdp.c|2 +-
> arch/arm/mach-omap2/board-omap4panda.c |2 +-
> 2 files changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/arch/arm/mach-omap2/board-4430sdp.c
> b/arch/arm/mach-omap2/board-4430sdp.c
> index 00d7290..56a9a4f 100644
> --- a/arch/arm/mach-omap2/board-4430sdp.c
> +++ b/arch/arm/mach-omap2/board-4430sdp.c
> @@ -730,7 +730,7 @@ static void __init omap_4430sdp_init(void)
> omap4_sdp4430_wifi_init();
> omap4_twl6030_hsmmc_init(mmc);
>
> - usb_bind_phy("musb-hdrc.0.auto", 0, "omap-usb2.1.auto");
> + usb_bind_phy("musb-hdrc.2.auto", 0, "omap-usb2.3.auto");
> usb_musb_init(&musb_board_data);
>
> status = omap_ethernet_init();
I'm seeing
[2.190155] unable to find transceiver
[2.190155] HS USB OTG: no transceiver configured
[2.190155] musb-hdrc musb-hdrc.0.auto: musb_init_controller failed
with status -517
[2.207458] platform musb-hdrc.0.auto: Driver musb-hdrc requests
probe deferral
on 4430sdp with v3.10-rc1. Does that mean that the musb-hdrc.0.auto was
indeed correct, and the new value of musb-hdrc.2.auto is not?
The musb-hdrc id is wrong on overo also.
Tomi
--
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: am3517: failed to boot 3.10-rc1
On 15.05.2013 10:37, Yegor Yefremov wrote: > On 14.05.2013 15:01, Yegor Yefremov wrote: >> On 14.05.2013 14:52, Felipe Balbi wrote: >>> On Tue, May 14, 2013 at 11:24:44AM +0200, Yegor Yefremov wrote: Trying to boot 3.10-rc1 on an am3515 based board. With the same .config as 3.7 the system comes to RTC stops there. I've also tried make omap2plus_defconfig with no visible difference. I'm booting from MMC card and it will be detected by the system. Kernel is from http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git, latest commit f722406faae2d073cc1d01063d1123c35425939e. Are there any pending patches needed to boot on am3517? >>> does v3.9 work ? Can you bisect ? >> >> 'git checkout v3.9' version is working, will try to bisect. > > This is bisect's result: > > f7b861b7a6d9d1838cbbb5f4053e61578b86d134 is the first bad commit > commit f7b861b7a6d9d1838cbbb5f4053e61578b86d134 > Author: Thomas Gleixner > Date: Thu Mar 21 22:49:38 2013 +0100 > > arm: Use generic idle loop > > Use the generic idle loop and replace enable/disable_hlt with the > respective core functions. > > Signed-off-by: Thomas Gleixner > Cc: Linus Torvalds > Cc: Rusty Russell > Cc: Paul McKenney > Cc: Peter Zijlstra > Reviewed-by: Cc: Srivatsa S. Bhat > Cc: Magnus Damm > Cc: Russell King > Tested-by: Kevin Hilman # OMAP > Link: http://lkml.kernel.org/r/20130321215233.826238...@linutronix.de > > :04 04 887517403888ff3947bce216aa4c1ff3ce3af434 > 8dc5236688a80fc64fa4112ce6136ecf3a19bac9 M arch We had such a problem long ago (https://patchwork.kernel.org/patch/1220061/ and http://www.spinics.net/lists/arm-kernel/msg168865.html) and the workaround was to use hohlt in kernel parameters. But with this patch the "nohlt" has gone. So now we need a solution, that fixes the root of the problem. -- 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
[RESEND PATCH v2 3/3] mmc: omap_hsmmc: add PSTATE to debugfs regs_show.
PSTATE shows current state of data lines. Signed-off-by: Andreas Fenkart diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c index 2b2ec09..61c0254 100644 --- a/drivers/mmc/host/omap_hsmmc.c +++ b/drivers/mmc/host/omap_hsmmc.c @@ -53,6 +53,7 @@ #define OMAP_HSMMC_RSP54 0x0118 #define OMAP_HSMMC_RSP76 0x011C #define OMAP_HSMMC_DATA0x0120 +#define OMAP_HSMMC_PSTATE 0x0124 #define OMAP_HSMMC_HCTL0x0128 #define OMAP_HSMMC_SYSCTL 0x012C #define OMAP_HSMMC_STAT0x0130 @@ -1809,6 +1810,8 @@ static int omap_hsmmc_regs_show(struct seq_file *s, void *data) seq_printf(s, "\nregs:\n"); seq_printf(s, "CON:\t\t0x%08x\n", OMAP_HSMMC_READ(host->base, CON)); + seq_printf(s, "PSTATE:\t\t0x%08x\n", + OMAP_HSMMC_READ(host->base, PSTATE)); seq_printf(s, "HCTL:\t\t0x%08x\n", OMAP_HSMMC_READ(host->base, HCTL)); seq_printf(s, "SYSCTL:\t\t0x%08x\n", -- 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
[RESEND PATCH v2 2/3] mmc: omap_hsmmc: debugfs entries for GPIO mode.
Signed-off-by: Andreas Fenkart
diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
index 4db8de5..2b2ec09 100644
--- a/drivers/mmc/host/omap_hsmmc.c
+++ b/drivers/mmc/host/omap_hsmmc.c
@@ -224,6 +224,7 @@ struct omap_hsmmc_host {
struct pinctrl *pinctrl;
struct pinctrl_state*active, *idle;
boolactive_pinmux;
+ int pm_suspend_ct;
struct omap_mmc_platform_data *pdata;
};
@@ -1775,12 +1776,29 @@ static int omap_hsmmc_regs_show(struct seq_file *s,
void *data)
struct mmc_host *mmc = s->private;
struct omap_hsmmc_host *host = mmc_priv(mmc);
int context_loss = 0;
+ unsigned long flags;
if (host->pdata->get_context_loss_count)
context_loss = host->pdata->get_context_loss_count(host->dev);
- seq_printf(s, "mmc%d:\n ctx_loss:\t%d:%d\n\nregs:\n",
- mmc->index, host->context_loss, context_loss);
+ seq_printf(s, "mmc%d:\n ctx_loss:\t%d:%d\n",
+ mmc->index, host->context_loss, context_loss);
+
+ if (mmc_slot(host).sdio_irq) {
+ spin_lock_irqsave(&host->irq_lock, flags);
+ seq_printf(s, "\n");
+ seq_printf(s, "pinmux config\t%s\n", host->active_pinmux ?
+ "sdio" : "gpio");
+ seq_printf(s, "sdio irq\t%s\n", host->sdio_irq_en ? "enabled" :
+ "disabled");
+ if (!host->active_pinmux) {
+ seq_printf(s, "sdio irq pin\t%s\n",
+ gpio_get_value(mmc_slot(host).gpio_cirq) ?
+ "high" : "low");
+ }
+ seq_printf(s, "pm suspends\t%d\n", host->pm_suspend_ct);
+ spin_unlock_irqrestore(&host->irq_lock, flags);
+ }
if (host->suspended) {
seq_printf(s, "host suspended, can't read registers\n");
@@ -1788,7 +1806,7 @@ static int omap_hsmmc_regs_show(struct seq_file *s, void
*data)
}
pm_runtime_get_sync(host->dev);
-
+ seq_printf(s, "\nregs:\n");
seq_printf(s, "CON:\t\t0x%08x\n",
OMAP_HSMMC_READ(host->base, CON));
seq_printf(s, "HCTL:\t\t0x%08x\n",
@@ -1963,6 +1981,7 @@ static int omap_hsmmc_probe(struct platform_device *pdev)
host->slot_id = 0;
host->sdio_irq_en = false;
host->active_pinmux = true;
+ host->pm_suspend_ct = 0;
host->mapbase = res->start + pdata->reg_offset;
host->base = ioremap(host->mapbase, SZ_4K);
host->power_mode = MMC_POWER_OFF;
@@ -2401,6 +2420,8 @@ static int omap_hsmmc_runtime_suspend(struct device *dev)
if (mmc_slot(host).sdio_irq && host->pinctrl) {
spin_lock_irqsave(&host->irq_lock, flags);
host->active_pinmux = false;
+ host->pm_suspend_ct++;
+
OMAP_HSMMC_WRITE(host->base, ISE, 0);
OMAP_HSMMC_WRITE(host->base, IE, 0);
OMAP_HSMMC_WRITE(host->base, STAT, STAT_CLEAR);
--
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
[RESEND PATCH v2 1/3] mmc: omap_hsmmc: Enable SDIO IRQ using a GPIO in idle mode.
Without functional clock the omap_hsmmc module can't forward SDIO IRQs to
the system. This patch reconfigures dat1 line as a gpio while the fclk is
off. When the fclk is present it uses the standard SDIO IRQ detection of
the module.
The gpio irq is managed via the 'disable_depth' ref counter of the irq
subsystem, this driver simply calls enable_irq/disable_irq when needed.
sdio irqsdio irq
unmasked masked
-
runtime default |1 | 2
runtime suspend |0 | 1
irq disable depth
only when sdio irq is enabled AND the module is idle, the reference
count drops to zero and the gpio irq is effectively armed.
Patch was tested on AM335x/Stream800. Test setup was two modules
with sdio wifi cards. Modules where connected to a dual-band AP, each
module using a different band. One of module was running iperf as server
the other as client connecting to the server in a while true loop. Test
was running for 4+ weeks. There were about 60 Mio. suspend/resume
transitions. Test was shut down regularly.
Signed-off-by: Andreas Fenkart
Reviewed-by: Grant Likely
diff --git a/Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt
b/Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt
index ed271fc..5a3df37 100644
--- a/Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt
+++ b/Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt
@@ -20,6 +20,29 @@ ti,dual-volt: boolean, supports dual voltage cards
ti,non-removable: non-removable slot (like eMMC)
ti,needs-special-reset: Requires a special softreset sequence
ti,needs-special-hs-handling: HSMMC IP needs special setting for handling High
Speed
+ti,cirq-gpio: When omap_hsmmc module is suspended, its functional
+clock is turned off. Without fclk it can't forward SDIO IRQs to the
+system. For that to happen, it needs to tell the PRCM to restore
+its fclk, which is done through the swakeup line.
+
+ --
+ | PRCM |
+ --
+| ^
+ fclk | | swakeup
+v |
+ --- --
+ <-- IRQ -- | hsmmc | <-- CIRQ -- | card |
+ --- --
+
+The problem is, that on the AM335x family the swakeup line is
+missing, it has not been routed from the module to the PRCM.
+The way to work around this, is to reconfigure the dat1 line as a
+GPIO upon suspend. Beyond this option you also need to set named
+states "default" and "idle "in the .dts file for the pins, using
+pinctrl-single.c. The MMC driver will then then toggle between
+default and idle during the runtime.
+
Example:
mmc1: mmc@0x4809c000 {
@@ -31,3 +54,22 @@ Example:
vmmc-supply = <&vmmc>; /* phandle to regulator node */
ti,non-removable;
};
+
+[am335x with with gpio for sdio irq]
+
+ mmc1_cirq_pin: pinmux_cirq_pin {
+ pinctrl-single,pins = <
+ 0x0f8 0x3f /* MMC0_DAT1 as GPIO2_28 */
+ >;
+ };
+
+ mmc1: mmc@4806 {
+ pinctrl-names = "default", "idle";
+ pinctrl-0 = <&mmc1_pins>;
+ pinctrl-1 = <&mmc1_cirq_pin>;
+ ti,cirq-gpio = <&gpio3 28 0>;
+ ti,non-removable;
+ bus-width = <4>;
+ vmmc-supply = <&ldo2_reg>;
+ vmmc_aux-supply = <&vmmc>;
+ };
diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
index f3594c6..4db8de5 100644
--- a/drivers/mmc/host/omap_hsmmc.c
+++ b/drivers/mmc/host/omap_hsmmc.c
@@ -22,6 +22,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -102,6 +103,7 @@
#define TC_EN (1 << 1)
#define BWR_EN (1 << 4)
#define BRR_EN (1 << 5)
+#define CIRQ_EN(1 << 8)
#define ERR_EN (1 << 15)
#define CTO_EN (1 << 16)
#define CCRC_EN(1 << 17)
@@ -218,10 +220,22 @@ struct omap_hsmmc_host {
int use_reg;
int req_in_progress;
struct omap_hsmmc_next next_data;
+ boolsdio_irq_en;
+ struct pinctrl *pinctrl;
+ struct pinctrl_state*active, *idle;
+ boolactive_pinmux;
struct omap_mmc_platform_data *pdata;
};
+static irqreturn_t omap_hsmmc_cirq(int irq, void *dev_id)
+{
+ struct omap_hsmmc_host *host = dev_id;
+
+ mmc_signal_sdio_irq(host->mmc);
+ return IRQ_HANDLED;
+}
+
static int omap_hsmmc_card_detect(struct device *dev, int slot)
{
struct omap_hsmmc_host *host = dev_get_drvdata(dev);
@@ -456,10 +470,30 @@ static int omap_hsmmc_gpio_init(struct
omap_mmc_platform_data *pdata)
} else
pdata->slo
[RESEND PATCH v2 0/3] omap_hsmmc: SDIO IRQ on AM335x family
No changes to the patches itself.
Only the dependency on some omap-gpio enable_irq/disable_irq patch
has been removed.
While developing, I was struck by a bug with disable_irq. After reviewing
the disable_irq code path, I thought the interrrupt got never disabled
for omap. After fixing the bug I was hunting, which was completely
unrelated to disable_irq, I never verified if the dependency was really
needed.
While trying to upstream my disable_irq fixes for gpio-omap, I realized,
that disable_irq was always working for gpio-omap through the generic
lazy disable mechanism.
/**
* irq_disable - disable interrupt generation
* @desc: irq descriptor which should be disabled
*
* If the chip does not implement the irq_disable callback, we
* use a lazy disable approach. That means we mark the interrupt
* disabled, but leave the hardware unmasked. If an interrupt
* happens, then the interrupt flow handler masks the line at the
* hardware level and marks it pending.
*/
void irq_disable(struct irq_desc *desc)
{
irq_state_set_disabled(desc);
if (desc->irq_data.chip->irq_disable) {
desc->irq_data.chip->irq_disable(&desc->irq_data);
irq_state_set_masked(desc);
}
}
The 4+ weeks testing mentionned in the 1st patch, was done with a
dedicated irq_disable hook in gpio-omap. I'm positive that it is not
needed at all, still the test was repeated for 1 day without that hook.
Andreas Fenkart (3):
mmc: omap_hsmmc: Enable SDIO IRQ using a GPIO in idle mode.
mmc: omap_hsmmc: debugfs entries for GPIO mode.
mmc: omap_hsmmc: add PSTATE to debugfs regs_show.
.../devicetree/bindings/mmc/ti-omap-hsmmc.txt | 42 +++
drivers/mmc/host/omap_hsmmc.c | 269 ++--
include/linux/platform_data/mmc-omap.h |4 +
3 files changed, 294 insertions(+), 21 deletions(-)
--
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
Re: am3517: failed to boot 3.10-rc1
On 14.05.2013 15:01, Yegor Yefremov wrote: > On 14.05.2013 14:52, Felipe Balbi wrote: >> On Tue, May 14, 2013 at 11:24:44AM +0200, Yegor Yefremov wrote: >>> Trying to boot 3.10-rc1 on an am3515 based board. With the same >>> .config as 3.7 the system comes to RTC stops there. I've also tried >>> make omap2plus_defconfig with no visible difference. I'm booting from >>> MMC card and it will be detected by the system. Kernel is from >>> http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git, latest >>> commit f722406faae2d073cc1d01063d1123c35425939e. Are there any pending >>> patches needed to boot on am3517? >> does v3.9 work ? Can you bisect ? > > 'git checkout v3.9' version is working, will try to bisect. This is bisect's result: f7b861b7a6d9d1838cbbb5f4053e61578b86d134 is the first bad commit commit f7b861b7a6d9d1838cbbb5f4053e61578b86d134 Author: Thomas Gleixner Date: Thu Mar 21 22:49:38 2013 +0100 arm: Use generic idle loop Use the generic idle loop and replace enable/disable_hlt with the respective core functions. Signed-off-by: Thomas Gleixner Cc: Linus Torvalds Cc: Rusty Russell Cc: Paul McKenney Cc: Peter Zijlstra Reviewed-by: Cc: Srivatsa S. Bhat Cc: Magnus Damm Cc: Russell King Tested-by: Kevin Hilman # OMAP Link: http://lkml.kernel.org/r/20130321215233.826238...@linutronix.de :04 04 887517403888ff3947bce216aa4c1ff3ce3af434 8dc5236688a80fc64fa4112ce6136ecf3a19bac9 M arch Any idea? Yegor -- 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: MTD : cannot reserve enough PEBs for bad PEB handling
On Mon, 2013-04-22 at 10:38 +0100, Mark Jackson wrote: > I'm trying to work out how to generate a "valid" UBI image, but I keep > getting a "cannot get enough PEBs" warning. > > I generate my image (destined for a 64MB NAND partition) using:- > > $ mkfs.ubifs -d output/target -e 0x1f000 -c 483 -m 0x800 -x none -F -o > output/images/rootfs.ubifs > $ ubinize -o output/images/rootfs.ubi -m 0x800 -p 0x2 -s 512 -O 2048 > ubinize.cfg > > My .cfg file is:- > > [ubifs] > mode=ubi > vol_id=0 > vol_type=dynamic > vol_name=rootfs > vol_alignment=1 > vol_flags=autoresize > vol_size=61MiB > image=output/images/rootfs.ubifs > > And the resulting image is:- > > -rw-rw-r-- 1 mpfj mpfj 9437184 Apr 16 10:19 rootfs.ubi > > This is then written to a freshly erased 64MB NAND partition, and > appears to mount correctly, apart from the warning about not enough > reserved PEBs, as follows:- > > ... > [0.792456] UBI: attaching mtd7 to ubi0 > [1.540858] UBI: scanning is finished > [1.557578] UBI warning: print_rsvd_warning: cannot reserve enough > PEBs for bad PEB handling, reserved 4, need 40 > [1.561346] UBI: attached mtd7 (name "rootfs", size 64 MiB) to ubi0 > [1.561404] UBI: PEB size: 131072 bytes (128 KiB), LEB size: 126976 bytes > [1.561434] UBI: min./max. I/O unit sizes: 2048/2048, sub-page size 512 > [1.561464] UBI: VID header offset: 2048 (aligned 2048), data offset: > 4096 > [1.561493] UBI: good PEBs: 512, bad PEBs: 0, corrupted PEBs: 0 > [1.561520] UBI: user volume: 1, internal volumes: 1, max. volumes > count: 128 > [1.561554] UBI: max/mean erase counter: 2/1, WL threshold: 4096, > image sequence number: 1434266085 > [1.561591] UBI: available PEBs: 0, total reserved PEBs: 512, PEBs > reserved for bad PEB handling: 4 > [1.562374] UBI: background thread "ubi_bgt0d" started, PID 598 > ... > > I think I've calculated the various option values correctly for > mkfs.ubifs and ubinize. > > But since I'm getting the warning, can anyone explain where I've gone > wrong ? This is because UBI is trying to reserve 40 PEBs for bad block handling. Why so much? See the explanations here: http://www.linux-mtd.infradead.org/doc/ubi.html#L_max_beb You may adjust this value, but the default for UBI is the most pessimistic scenario. -- Best Regards, Artem Bityutskiy -- 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
