[PATCH 0/2] mtd:nand:omap2: ECC support clean-up for omap2-nand driver
From: Gupta, Pekon pe...@ti.com 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
[PATCH 2/2] ARM: OMAP2+: cleaned-up DT support of various ECC schemes
From: Gupta, Pekon pe...@ti.com
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 pe...@ti.com
---
.../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:
- swSoftware method (default)
- hwHardware method
- hw-romcodegpmc 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_sw1-bit Hamming ECC using software
+
+ hamming_hw1-bit Hamming ECC using hardware
+
+ hamming_hw_romcode1-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 elm_id 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_NAND
[PATCH 1/2] mtd:nand:omap2: clean-up BCHx_HW and BCHx_SW ECC configurations in device_probe
From: Gupta, Pekon pe...@ti.com
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 pe...@ti.com
---
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 linux/of.h
#include linux/of_device.h
-#ifdef CONFIG_MTD_NAND_OMAP_BCH
+#ifdef CONFIG_MTD_NAND_ECC_BCH
#include linux/bch.h
+#endif
+#ifdef CONFIG_MTD_NAND_OMAP_BCH
#include linux/platform_data/elm.h
#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
Re: [PATCHv2 3/3] arm: dts: add bandgap entry for OMAP4460 devices
Hi Eduardo,
On 05/15/2013 06:36 PM, 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 b-cous...@ti.com
Cc: Tony Lindgren t...@atomide.com
Cc: Russell King li...@arm.linux.org.uk
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 eduardo.valen...@ti.com
---
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.
Ooops :-) I do not remember that... maybe it was long time ago, before
we had any decent binding available for GPIO and IRQ...
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).
Mmm, ok, so in that case, it is not even a gpio, but an interrupt entry
that is needed like that:
interrupt-parent = gpio3;
interrupts = 22; /* gpio line 86 */
Except that we already have an IRQ line connected to GIC for the
Talert... I'm not sure we can have 2 different IRQ controllers for one
device :-(
We need to check.
Regards,
Benoit
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 2/2] ARM: OMAP2+: cleaned-up DT support of various ECC schemes
2013/5/16 Gupta, Pekon pe...@ti.com:
From: Gupta, Pekon pe...@ti.com
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
OMAP_ECC_BCH4_CODE_HW_DETECTION_SW and OMAP_ECC_BCH4_CODE_HW
seems to exist in the code, but are not in the changelog, and not in
the device tree binding documentation.
Signed-off-by: Gupta, Pekon pe...@ti.com
---
.../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:
- swSoftware method (default)
- hwHardware method
- hw-romcodegpmc 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_sw1-bit Hamming ECC using software
+
+ hamming_hw1-bit Hamming ECC using hardware
+
+ hamming_hw_romcode1-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 elm_id 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 =
RE: [PATCH 2/2] ARM: OMAP2+: cleaned-up DT support of various ECC schemes
OMAP_ECC_BCH4_CODE_HW_DETECTION_SW and OMAP_ECC_BCH4_CODE_HW seems to exist in the code, but are not in the changelog, and not in the device tree binding documentation. Yes, I plan to omit them from code also, in next series as it does not make sense to support both BCH4 and BCH8 at same time, when most users would opt for BCH8. Also, BCH4 was kept for legacy purposes, and was not tested on all devices. Therefore I have purposely omitted it from documentation. with regards, pekon
Re: omap3 : isp clock a : Difference between dmesg frequency and actual frequency with 3.9
2013/5/15 jean-philippe francois jp.franc...@cynove.com: 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. It seems the dpll4_m5_ck is not correctly set, 3.6.11 code in isp.c (without error handling) r = clk_set_rate(isp-clock[ISP_CLK_DPLL4_M5_CK], CM_CAM_MCLK_HZ/divisor); ... r = clk_enable(isp-clock[ISP_CLK_CAM_MCLK]); 3.9 code in isp.c (without error handling) r = clk_set_rate(isp-clock[ISP_CLK_CAM_MCLK], CM_CAM_MCLK_HZ/divisor); 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: omap3 : isp clock a : Difference between dmesg frequency and actual frequency with 3.9
2013/5/15 jean-philippe francois jp.franc...@cynove.com: 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. Sorry for the resend, wrong tab and enter key sequence in gmail ... It seems the dpll4_m5_ck is not correctly set, 3.6.11 code in isp.c (without error handling) r = clk_set_rate(isp-clock[ISP_CLK_DPLL4_M5_CK], CM_CAM_MCLK_HZ/divisor); ... r = clk_enable(isp-clock[ISP_CLK_CAM_MCLK]); 3.9 code in isp.c (without error handling) r = clk_set_rate(isp-clock[ISP_CLK_CAM_MCLK], CM_CAM_MCLK_HZ/divisor); r = clk_prepare_enable(isp-clock[ISP_CLK_CAM_MCLK]); The PLL settings ie multiplier and divisor are the same in each case, but the dmesg output differ : Here is what happens when isp_enable_clock is called on 3.6 3.6 [ 10.133697] Entering cam_set_xclk [ 10.137573] clock: clksel_round_rate_div: dpll4_m5_ck target_rate 17280 [ 10.137573] clock: new_div = 5, new_rate = 17280 [ 10.137603] clock: dpll4_m5_ck: set rate to 17280 [ 10.138061] omap3isp omap3isp: isp_set_xclk(): cam_xclka set to 24685714 Hz 3.9 [9.095581] Entering cam_set_xclk [9.102661] omap3isp omap3isp: isp_set_xclk(): cam_xclka set to 24685714 Hz So the frequency setting register are correctly set, but the actual output frequency is not. maybe dpll4 is not correctly locked ? I will also check isp_enable_clock is really called. But I suppose it is, because except for the frequency, everything is working correctly. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/2] ARM: OMAP2+: cleaned-up DT support of various ECC schemes
2013/5/16 Gupta, Pekon pe...@ti.com: OMAP_ECC_BCH4_CODE_HW_DETECTION_SW and OMAP_ECC_BCH4_CODE_HW seems to exist in the code, but are not in the changelog, and not in the device tree binding documentation. Yes, I plan to omit them from code also, in next series as it does not make sense to support both BCH4 and BCH8 at same time, when most users would opt for BCH8. Also, BCH4 was kept for legacy purposes, and was not tested on all devices. Therefore I have purposely omitted it from documentation. We have shipped devices with BCH4 nand. This would be a regression for us. Regards, Jean-Philippe François. with regards, pekon -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 2/2] ARM: OMAP2+: cleaned-up DT support of various ECC schemes
2013/5/16 Gupta, Pekon pe...@ti.com: OMAP_ECC_BCH4_CODE_HW_DETECTION_SW and OMAP_ECC_BCH4_CODE_HW seems to exist in the code, but are not in the changelog, and not in the device tree binding documentation. Yes, I plan to omit them from code also, in next series as it does not make sense to support both BCH4 and BCH8 at same time, when most users would opt for BCH8. Also, BCH4 was kept for legacy purposes, and was not tested on all devices. Therefore I have purposely omitted it from documentation. We have shipped devices with BCH4 nand. This would be a regression for us. [Pekon]: May I know the following details so that I can prioritize BCH4 testing - Which TI device have you productized ? - Which kernel version you are using ? (Is it from mainline or SDK release) - Which BCH4 ECC implementation you are using ? BCH4_HW (using both GPMC and ELM H/W engines) BCH4_HW_DETECTION_SW (using GPMC H/W and bch.h S/W libraries) - Is there a specific reason whyyou opted for BCH4 instead of BCH8 ? (Though its only recent that OMAP_ECC_BCHx support is mainlined But, BCH8 support was available in TI SDK releases from quite sometime.) I'll try to see if I can help you here, but going forward its always recommended to use higher ECC schemes (like BCH8), so that flash's lifetime is extended on field. Regards, Jean-Philippe François. with regards, pekon
Re: [PATCH 2/2] ARM: OMAP2+: cleaned-up DT support of various ECC schemes
2013/5/16 Gupta, Pekon pe...@ti.com:
2013/5/16 Gupta, Pekon pe...@ti.com:
OMAP_ECC_BCH4_CODE_HW_DETECTION_SW and
OMAP_ECC_BCH4_CODE_HW
seems to exist in the code, but are not in the changelog, and not in
the device tree binding documentation.
Yes, I plan to omit them from code also, in next series as it does not
make sense to support both BCH4 and BCH8 at same time, when most
users would opt for BCH8.
Also, BCH4 was kept for legacy purposes, and was not tested on all
devices.
Therefore I have purposely omitted it from documentation.
We have shipped devices with BCH4 nand. This would be a regression
for us.
[Pekon]: May I know the following details so that I can prioritize BCH4
testing
- Which TI device have you productized ?
dm3730
- Which kernel version you are using ? (Is it from mainline or SDK release)
3.6.11, currently moving to 3.9
- Which BCH4 ECC implementation you are using ?
BCH4_HW (using both GPMC and ELM H/W engines)
BCH4_HW_DETECTION_SW (using GPMC H/W and bch.h S/W libraries)
I guess it is BCH4_HW_DETECTION_SW. Here is the relevant part of the
machine board file patch :
+static struct omap_nand_platform_data cydm_nand_data = {
+ .cs = 0,
+ .ecc_opt = OMAP_ECC_BCH4_CODE_HW,
+};
- Is there a specific reason whyyou opted for BCH4 instead of BCH8 ?
(Though its only recent that OMAP_ECC_BCHx support is mainlined
But, BCH8 support was available in TI SDK releases from quite
sometime.)
No, I figured BCH4 was sufficient for my nand. In fact my previous ecc
scheme (1 bit hamming) was not
offering enough protection. I started investigating bch, and read that
while the ti dvsdk bch code
for computing the bch was ok, the error correction code was not, and
the new BCH4 scheme
resulted in all FF OOB data for an empty page, which was great. There
was no real reason for
choosing BCH4 over BCH8, but I thought the simpler the better.
I'll try to see if I can help you here, but going forward its always
recommended
to use higher ECC schemes (like BCH8), so that flash's lifetime is extended
on field.
Regards,
Jean-Philippe François.
with regards, pekon
--
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 26/33] drivers/video/omap2/dss: don't check resource with devm_ioremap_resource
devm_ioremap_resource does sanity checks on the given resource. No need to
duplicate this in the driver.
Signed-off-by: Wolfram Sang w...@the-dreams.de
---
drivers/video/omap2/dss/hdmi.c |4
1 file changed, 4 deletions(-)
diff --git a/drivers/video/omap2/dss/hdmi.c b/drivers/video/omap2/dss/hdmi.c
index 17f4d55..a109934 100644
--- a/drivers/video/omap2/dss/hdmi.c
+++ b/drivers/video/omap2/dss/hdmi.c
@@ -1065,10 +1065,6 @@ static int omapdss_hdmihw_probe(struct platform_device
*pdev)
mutex_init(hdmi.ip_data.lock);
res = platform_get_resource(hdmi.pdev, IORESOURCE_MEM, 0);
- if (!res) {
- DSSERR(can't get IORESOURCE_MEM HDMI\n);
- return -EINVAL;
- }
/* Base address taken from platform */
hdmi.ip_data.base_wp = devm_ioremap_resource(pdev-dev, res);
--
1.7.10.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 25/33] drivers/video/omap2: don't check resource with devm_ioremap_resource
devm_ioremap_resource does sanity checks on the given resource. No need to
duplicate this in the driver.
Signed-off-by: Wolfram Sang w...@the-dreams.de
---
drivers/video/omap2/vrfb.c |5 -
1 file changed, 5 deletions(-)
diff --git a/drivers/video/omap2/vrfb.c b/drivers/video/omap2/vrfb.c
index 5261229..f346b02 100644
--- a/drivers/video/omap2/vrfb.c
+++ b/drivers/video/omap2/vrfb.c
@@ -353,11 +353,6 @@ static int __init vrfb_probe(struct platform_device *pdev)
/* first resource is the register res, the rest are vrfb contexts */
mem = platform_get_resource(pdev, IORESOURCE_MEM, 0);
- if (!mem) {
- dev_err(pdev-dev, can't get vrfb base address\n);
- return -EINVAL;
- }
-
vrfb_base = devm_ioremap_resource(pdev-dev, mem);
if (IS_ERR(vrfb_base))
return PTR_ERR(vrfb_base);
--
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: omap3 : isp clock a : Difference between dmesg frequency and actual frequency with 3.9
Hi Jean-Philippe,
On Thursday 16 May 2013 10:21:14 jean-philippe francois wrote:
2013/5/15 jean-philippe francois jp.franc...@cynove.com:
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.
Sorry for the resend, wrong tab and enter key sequence in gmail ...
It seems the dpll4_m5_ck is not correctly set,
3.6.11 code in isp.c (without error handling)
r = clk_set_rate(isp-clock[ISP_CLK_DPLL4_M5_CK],
CM_CAM_MCLK_HZ/divisor);
...
r = clk_enable(isp-clock[ISP_CLK_CAM_MCLK]);
3.9 code in isp.c (without error handling)
r = clk_set_rate(isp-clock[ISP_CLK_CAM_MCLK],
CM_CAM_MCLK_HZ/divisor);
r = clk_prepare_enable(isp-clock[ISP_CLK_CAM_MCLK]);
The PLL settings ie multiplier and divisor are the same in each case,
but the dmesg output differ :
Here is what happens when isp_enable_clock is called on 3.6
3.6
[ 10.133697] Entering cam_set_xclk
[ 10.137573] clock: clksel_round_rate_div: dpll4_m5_ck
target_rate 17280
[ 10.137573] clock: new_div = 5, new_rate = 17280
[ 10.137603] clock: dpll4_m5_ck: set rate to 17280
[ 10.138061] omap3isp omap3isp: isp_set_xclk(): cam_xclka set to
24685714 Hz
3.9
[9.095581] Entering cam_set_xclk
[9.102661] omap3isp omap3isp: isp_set_xclk(): cam_xclka set to
24685714 Hz
So the frequency setting register are correctly set, but the actual
output frequency is not.
maybe dpll4 is not correctly locked ? I will also check
isp_enable_clock is really called.
But I suppose it is, because except for the frequency, everything is
working correctly.
Does the following patch fix the issue ?
commit 577f8ea9ba7b1276096713b8148b3a8fca96d805
Author: Laurent Pinchart laurent.pinch...@ideasonboard.com
Date: Thu May 16 13:15:40 2013 +0200
ARM: OMAP3: clock: Back-propagate rate change from cam_mclk to dpll4_m5 on
all OMAP3 platforms
Commit 7b2e1277598e4187c9be3e61fd9b0f0423f97986 (ARM: OMAP3: clock:
Back-propagate rate change from cam_mclk to dpll4_m5) enabled clock
rate back-propagation from cam_mclk do dpll4_m5 on OMAP3630 only.
Perform back-propagation on other OMAP3 platforms as well.
Reported-by: Jean-Philippe François jp.franc...@cynove.com
Signed-off-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
diff --git a/arch/arm/mach-omap2/cclock3xxx_data.c
b/arch/arm/mach-omap2/cclock3xxx_data.c
index 4579c3c..c21065a 100644
--- a/arch/arm/mach-omap2/cclock3xxx_data.c
+++ b/arch/arm/mach-omap2/cclock3xxx_data.c
@@ -418,7 +418,8 @@ static struct clk_hw_omap dpll4_m5x2_ck_hw = {
.clkdm_name = dpll4_clkdm,
};
-DEFINE_STRUCT_CLK(dpll4_m5x2_ck, dpll4_m5x2_ck_parent_names,
dpll4_m5x2_ck_ops);
+DEFINE_STRUCT_CLK_FLAGS(dpll4_m5x2_ck, dpll4_m5x2_ck_parent_names,
+ dpll4_m5x2_ck_ops, CLK_SET_RATE_PARENT);
static struct clk dpll4_m5x2_ck_3630 = {
.name = dpll4_m5x2_ck,
--
Regards,
Laurent Pinchart
--
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 15.05.2013 23:50, Mark A. Greer wrote: On Wed, May 15, 2013 at 10:07:35AM -0700, Tony Lindgren wrote: * Mark A. Greer mgr...@animalcreek.com [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 t...@atomide.com --- 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. I think this issue is relevant to am3517 as you can see from this thread: http://thread.gmane.org/gmane.linux.ports.arm.omap/97903 I could boot only with your patch http://www.spinics.net/lists/arm-kernel/msg168865.html I have such a system running, so if you have any other patches/ideas to test, I would do it. 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: [PATCHv2 3/3] arm: dts: add bandgap entry for OMAP4460 devices
On 16-05-2013 03:20, Benoit Cousson wrote:
Hi Eduardo,
On 05/15/2013 06:36 PM, 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 b-cous...@ti.com
Cc: Tony Lindgren t...@atomide.com
Cc: Russell King li...@arm.linux.org.uk
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 eduardo.valen...@ti.com
---
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.
Ooops :-) I do not remember that... maybe it was long time ago, before
we had any decent binding available for GPIO and IRQ...
Probably it was because by that time we didnt have GPIO binding ready, yeah.
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).
Mmm, ok, so in that case, it is not even a gpio, but an interrupt entry
that is needed like that:
interrupt-parent = gpio3;
interrupts = 22; /* gpio line 86 */
Except that we already have an IRQ line connected to GIC for the
Talert... I'm not sure we can have 2 different IRQ controllers for one
device :-(
We need to check.
Yeah, I also dont think this will work, because we will reparent the
interrupt, setting to a different controller. That will break the TALERT
signal already defined at GIC (check original patch).
I propose keeping the way I sent. Unless there is a way to set two
different controllers to same device.
Regards,
Benoit
Where is the gpio controller phandle?
Usually it looks like this:
gpios = gpio1 8 0;
Regards,
Benoit
signature.asc
Description: OpenPGP digital signature
Re: [PATCHv2 3/3] arm: dts: add bandgap entry for OMAP4460 devices
On 15-05-2013 12:57, Jean-Christophe PLAGNIOL-VILLARD wrote:
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 b-cous...@ti.com
Cc: Tony Lindgren t...@atomide.com
Cc: Russell King li...@arm.linux.org.uk
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 eduardo.valen...@ti.com
---
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
Jean-Christophe,
That will change the controller and break the configuration for the
other IRQ line, coming from GIC.
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
signature.asc
Description: OpenPGP digital signature
Re: [PATCH] ARM: OMAP5: select SCU
On 05/15/2013 02:36 PM, Santosh Shilimkar wrote: OMAP5 doesn't need the SCU. So Nak for the patch. Hi, I agree that it is a pure link issue. I haven't noticed this earlier. Do you know which commit broke this ? After some bisecting I arrived at this merge commit: 5497e7b Merge branch 'late/fixes' into fixes Indeed, if I revert it (-m 1) the result does link properly. I'll try to isolate it further. Best regards, V. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] ARM: omap2: remove CONFIG_ARCH_OMAP2PLUS_TYPICAL
From: Rob Herring rob.herr...@calxeda.com CONFIG_ARCH_OMAP2PLUS_TYPICAL is selecting user defined features, not h/w required options. This does not play well with multi-platform kernels and belongs in a defconfig. Signed-off-by: Rob Herring rob.herr...@calxeda.com Cc: Tony Lindgren t...@atomide.com Cc: linux-omap@vger.kernel.org --- arch/arm/mach-omap2/Kconfig | 17 - 1 file changed, 17 deletions(-) diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig index f49cd51..9d4b5f7 100644 --- a/arch/arm/mach-omap2/Kconfig +++ b/arch/arm/mach-omap2/Kconfig @@ -26,23 +26,6 @@ if ARCH_OMAP2PLUS menu TI OMAP2/3/4 Specific Features -config ARCH_OMAP2PLUS_TYPICAL - bool Typical OMAP configuration - default y - select AEABI - select HIGHMEM - select I2C - select I2C_OMAP - select MENELAUS if ARCH_OMAP2 - select NEON if ARCH_OMAP3 || ARCH_OMAP4 || SOC_OMAP5 - select PM_RUNTIME - select REGULATOR - select TWL4030_CORE if ARCH_OMAP3 || ARCH_OMAP4 - select TWL4030_POWER if ARCH_OMAP3 || ARCH_OMAP4 - select VFP - help - Compile a kernel suitable for booting most boards - config SOC_HAS_OMAP2_SDRC bool OMAP2 SDRAM Controller support -- 1.8.1.2 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: omap3 : isp clock a : Difference between dmesg frequency and actual frequency with 3.9
2013/5/16 Laurent Pinchart laurent.pinch...@ideasonboard.com:
Hi Jean-Philippe,
On Thursday 16 May 2013 10:21:14 jean-philippe francois wrote:
2013/5/15 jean-philippe francois jp.franc...@cynove.com:
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.
Sorry for the resend, wrong tab and enter key sequence in gmail ...
It seems the dpll4_m5_ck is not correctly set,
3.6.11 code in isp.c (without error handling)
r = clk_set_rate(isp-clock[ISP_CLK_DPLL4_M5_CK],
CM_CAM_MCLK_HZ/divisor);
...
r = clk_enable(isp-clock[ISP_CLK_CAM_MCLK]);
3.9 code in isp.c (without error handling)
r = clk_set_rate(isp-clock[ISP_CLK_CAM_MCLK],
CM_CAM_MCLK_HZ/divisor);
r = clk_prepare_enable(isp-clock[ISP_CLK_CAM_MCLK]);
The PLL settings ie multiplier and divisor are the same in each case,
but the dmesg output differ :
Here is what happens when isp_enable_clock is called on 3.6
3.6
[ 10.133697] Entering cam_set_xclk
[ 10.137573] clock: clksel_round_rate_div: dpll4_m5_ck
target_rate 17280
[ 10.137573] clock: new_div = 5, new_rate = 17280
[ 10.137603] clock: dpll4_m5_ck: set rate to 17280
[ 10.138061] omap3isp omap3isp: isp_set_xclk(): cam_xclka set to
24685714 Hz
3.9
[9.095581] Entering cam_set_xclk
[9.102661] omap3isp omap3isp: isp_set_xclk(): cam_xclka set to
24685714 Hz
So the frequency setting register are correctly set, but the actual
output frequency is not.
maybe dpll4 is not correctly locked ? I will also check
isp_enable_clock is really called.
But I suppose it is, because except for the frequency, everything is
working correctly.
Does the following patch fix the issue ?
Hi Laurent, thank you for your help.
I am on a dm3730, si I already had the back propagation thing.
I tried the patch anyway, but it did not solve the issue.
If I look at the registers, on both version :
0x48004d44 contains 0x04816807 whiche gives a dpll4 frequency of 864 MHz
0x48004f40 contains 0x5 which gives a cam_mclk frequency of 172,8 MHz
0x480bc050 (ISP.TCTRL_CTRL) contains 0x7 which should give a 24 MHz frequency
In my dmesg output, I never see a message like the following but for dpll4_ck.
omap3_noncore_dpll_set_rate: dpll5_ck: set rate: locking rate to 12000.
I wonder why.
commit 577f8ea9ba7b1276096713b8148b3a8fca96d805
Author: Laurent Pinchart laurent.pinch...@ideasonboard.com
Date: Thu May 16 13:15:40 2013 +0200
ARM: OMAP3: clock: Back-propagate rate change from cam_mclk to dpll4_m5
on all OMAP3 platforms
Commit 7b2e1277598e4187c9be3e61fd9b0f0423f97986 (ARM: OMAP3: clock:
Back-propagate rate change from cam_mclk to dpll4_m5) enabled clock
rate back-propagation from cam_mclk do dpll4_m5 on OMAP3630 only.
Perform back-propagation on other OMAP3 platforms as well.
Reported-by: Jean-Philippe François jp.franc...@cynove.com
Signed-off-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
diff --git a/arch/arm/mach-omap2/cclock3xxx_data.c
b/arch/arm/mach-omap2/cclock3xxx_data.c
index 4579c3c..c21065a 100644
--- a/arch/arm/mach-omap2/cclock3xxx_data.c
+++ b/arch/arm/mach-omap2/cclock3xxx_data.c
@@ -418,7 +418,8 @@ static struct clk_hw_omap dpll4_m5x2_ck_hw = {
.clkdm_name = dpll4_clkdm,
};
-DEFINE_STRUCT_CLK(dpll4_m5x2_ck, dpll4_m5x2_ck_parent_names,
dpll4_m5x2_ck_ops);
+DEFINE_STRUCT_CLK_FLAGS(dpll4_m5x2_ck, dpll4_m5x2_ck_parent_names,
+ dpll4_m5x2_ck_ops, CLK_SET_RATE_PARENT);
static struct clk dpll4_m5x2_ck_3630 = {
.name = dpll4_m5x2_ck,
--
Regards,
Laurent Pinchart
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [GIT PULL] OMAP PM cleanups for v3.10
Olof Johansson o...@lixom.net writes: On Wed, Apr 10, 2013 at 11:14:52AM -0700, Tony Lindgren wrote: Hi, Added Olof to cc, I suggest Olof pull this directly as we're starting to run out of time. Hi, I'm terribly sorry for dropping this one on the floor, in spite of repeated pings from Tony. :( If it wasn't for the fact that we're pushing back on some of the other late submissions I'd be open to taking this, but to be fair it makes more sense to merge it right after -rc1. The changes don't look like they're truly critical for 3.10, and you should still be able to use this as a base for your 3.11 changes, so hopefully this doesn't cause too much trouble. So, please resend right after the merge window closes. Pull request below. It is unchanged and merges cleanly with v3.10-rc1. Kevin The following changes since commit c309f7f46167e85d1aae2fd31f23e7d2b5cdfbe0: Merge branch 'for_3.10/omap_generic_cleanup_v2' of git://git.kernel.org/pub/scm/linux/kernel/git/ssantosh/linux into omap-for-v3.10/cleanup-v2 (2013-03-28 14:45:31 -0700) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/khilman/linux-omap-pm.git tags/omap-pm-v3.10/cleanup/pm for you to fetch changes up to 705814b5ea6ff69d4da8ad581c3da5d26d1eae83: ARM: OMAP4+: PM: Consolidate OMAP4 PM code to re-use it for OMAP5 (2013-04-09 10:53:06 -0700) OMAP PM cleanups for v3.10 Santosh Shilimkar (4): ARM: OMAP4: PM: Avoid expensive cpu_suspend() path for all CPU power states except off ARM: OMAP4+: PM: Consolidate MPU subsystem PM code for re-use ARM: OMAP4+: Make secondary_startup function name more consistent ARM: OMAP4+: PM: Consolidate OMAP4 PM code to re-use it for OMAP5 arch/arm/mach-omap2/common.h | 4 +- arch/arm/mach-omap2/omap-headsmp.S| 8 ++-- arch/arm/mach-omap2/omap-mpuss-lowpower.c | 69 +-- arch/arm/mach-omap2/omap-smp.c| 6 +-- arch/arm/mach-omap2/pm44xx.c | 58 +- 5 files changed, 113 insertions(+), 32 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: [Resned/PATCHv5 0/2] Serial fixes
Sourav Poddar sourav.pod...@ti.com writes: Hi Greg, I have rebased this patch series on top of 3.10-rc1. Thanks for the rebase. Once Greg queues these, I will queue the OMAP specific pieces (which are not strictly dependent on the core changes.) Kevin -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: OMAP5: select SCU
So the exact commit breaking OMAP5 link for me is: 883a106 ARM: default machine descriptor for multiplatform The breakage seems to be a side effect of not selecting ARCH_VEXPRESS any more, which causes HAVE_ARM_SCU to not be selected any more, too, when compiling only for OMAP5. IMHO this only reveals a deeper issue. Probably the ideal fix would be to remove all references to the scu_ functions for OMAP5, but those seem to exist in files and functions, common to OMAP4 and 5 (sleep44xx.S, omap-smp.c). How would you deal with that, please? Best regards, V. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: omap2: remove CONFIG_ARCH_OMAP2PLUS_TYPICAL
* Rob Herring robherri...@gmail.com [130516 06:34]: From: Rob Herring rob.herr...@calxeda.com CONFIG_ARCH_OMAP2PLUS_TYPICAL is selecting user defined features, not h/w required options. This does not play well with multi-platform kernels and belongs in a defconfig. Yes we can remove this. But let's update omap2plus_defconfig with these options where needed. I can update this patch for that and queue it if that works for you. Regards, Tony Signed-off-by: Rob Herring rob.herr...@calxeda.com Cc: Tony Lindgren t...@atomide.com Cc: linux-omap@vger.kernel.org --- arch/arm/mach-omap2/Kconfig | 17 - 1 file changed, 17 deletions(-) diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig index f49cd51..9d4b5f7 100644 --- a/arch/arm/mach-omap2/Kconfig +++ b/arch/arm/mach-omap2/Kconfig @@ -26,23 +26,6 @@ if ARCH_OMAP2PLUS menu TI OMAP2/3/4 Specific Features -config ARCH_OMAP2PLUS_TYPICAL - bool Typical OMAP configuration - default y - select AEABI - select HIGHMEM - select I2C - select I2C_OMAP - select MENELAUS if ARCH_OMAP2 - select NEON if ARCH_OMAP3 || ARCH_OMAP4 || SOC_OMAP5 - select PM_RUNTIME - select REGULATOR - select TWL4030_CORE if ARCH_OMAP3 || ARCH_OMAP4 - select TWL4030_POWER if ARCH_OMAP3 || ARCH_OMAP4 - select VFP - help - Compile a kernel suitable for booting most boards - config SOC_HAS_OMAP2_SDRC bool OMAP2 SDRAM Controller support -- 1.8.1.2 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: omap2: remove CONFIG_ARCH_OMAP2PLUS_TYPICAL
On Thu, May 16, 2013 at 10:11 AM, Tony Lindgren t...@atomide.com wrote: * Rob Herring robherri...@gmail.com [130516 06:34]: From: Rob Herring rob.herr...@calxeda.com CONFIG_ARCH_OMAP2PLUS_TYPICAL is selecting user defined features, not h/w required options. This does not play well with multi-platform kernels and belongs in a defconfig. Yes we can remove this. But let's update omap2plus_defconfig with these options where needed. I can update this patch for that and queue it if that works for you. Yes, that's fine. You might also want to enable the h/w related features to multi_v7_defconfig as well. Rob -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: omap2: remove CONFIG_ARCH_OMAP2PLUS_TYPICAL
* Rob Herring robherri...@gmail.com [130516 08:25]: On Thu, May 16, 2013 at 10:11 AM, Tony Lindgren t...@atomide.com wrote: * Rob Herring robherri...@gmail.com [130516 06:34]: From: Rob Herring rob.herr...@calxeda.com CONFIG_ARCH_OMAP2PLUS_TYPICAL is selecting user defined features, not h/w required options. This does not play well with multi-platform kernels and belongs in a defconfig. Yes we can remove this. But let's update omap2plus_defconfig with these options where needed. I can update this patch for that and queue it if that works for you. Yes, that's fine. You might also want to enable the h/w related features to multi_v7_defconfig as well. Yes will do. BTW, getting rid of CONFIG_ARCH_OMAP2PLUS_TYPICAL was the reason I did not update multi_v7_defconfig yet. I'll also update Arnd's randconfig fix patch and post it, then will stick all three patches into one branch. Regards, Tony -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [GIT PULL] OMAP PM cleanups for v3.10
* Kevin Hilman khil...@linaro.org [130516 07:08]: Olof Johansson o...@lixom.net writes: On Wed, Apr 10, 2013 at 11:14:52AM -0700, Tony Lindgren wrote: Hi, Added Olof to cc, I suggest Olof pull this directly as we're starting to run out of time. Hi, I'm terribly sorry for dropping this one on the floor, in spite of repeated pings from Tony. :( If it wasn't for the fact that we're pushing back on some of the other late submissions I'd be open to taking this, but to be fair it makes more sense to merge it right after -rc1. The changes don't look like they're truly critical for 3.10, and you should still be able to use this as a base for your 3.11 changes, so hopefully this doesn't cause too much trouble. So, please resend right after the merge window closes. Pull request below. It is unchanged and merges cleanly with v3.10-rc1. I've pulled this into omap-for-v3.11/pm. Olof, you can also pull Kevin's branch now or later on along with other omap pull requests whichever you prefer. Regards, Tony The following changes since commit c309f7f46167e85d1aae2fd31f23e7d2b5cdfbe0: Merge branch 'for_3.10/omap_generic_cleanup_v2' of git://git.kernel.org/pub/scm/linux/kernel/git/ssantosh/linux into omap-for-v3.10/cleanup-v2 (2013-03-28 14:45:31 -0700) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/khilman/linux-omap-pm.git tags/omap-pm-v3.10/cleanup/pm for you to fetch changes up to 705814b5ea6ff69d4da8ad581c3da5d26d1eae83: ARM: OMAP4+: PM: Consolidate OMAP4 PM code to re-use it for OMAP5 (2013-04-09 10:53:06 -0700) OMAP PM cleanups for v3.10 Santosh Shilimkar (4): ARM: OMAP4: PM: Avoid expensive cpu_suspend() path for all CPU power states except off ARM: OMAP4+: PM: Consolidate MPU subsystem PM code for re-use ARM: OMAP4+: Make secondary_startup function name more consistent ARM: OMAP4+: PM: Consolidate OMAP4 PM code to re-use it for OMAP5 arch/arm/mach-omap2/common.h | 4 +- arch/arm/mach-omap2/omap-headsmp.S| 8 ++-- arch/arm/mach-omap2/omap-mpuss-lowpower.c | 69 +-- arch/arm/mach-omap2/omap-smp.c| 6 +-- arch/arm/mach-omap2/pm44xx.c | 58 +- 5 files changed, 113 insertions(+), 32 deletions(-) -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v4] ARM:dts:omap4-panda: Update the LED support for the panda DTS
On 05/15/2013 12:05 PM, Nishanth Menon wrote:
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 dmur...@ti.com
---
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.
I am not sure you really want to do this.
If I make the pinctrl part of the led structure then the only way the gpio_wk7
on a1-a3 to be configured is when
the CONFIG_LEDS_GPIO flag is set.
Do you really want that dependency? You did say it was a key fix
At least this way the pins are configured regardless of that flag.
};
};
+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
--
--
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: OMAP2+: control: add OMAP5 support for dsp boot programming
* Suman Anna s-a...@ti.com [130417 14:40]:
Support for OMAP5 is added to the omap_dsp_ctrl_write_boot_addr()
to enable the DSP boot.
Signed-off-by: Suman Anna s-a...@ti.com
Thanks applying into omap-for-v3.11/fixes-non-critical.
Regards,
Tony
---
arch/arm/mach-omap2/control.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm/mach-omap2/control.c b/arch/arm/mach-omap2/control.c
index 2adb268..31e0dfe 100644
--- a/arch/arm/mach-omap2/control.c
+++ b/arch/arm/mach-omap2/control.c
@@ -249,6 +249,7 @@ void omap_ctrl_write_dsp_boot_addr(u32 bootaddr)
u32 offset = cpu_is_omap243x() ? OMAP243X_CONTROL_IVA2_BOOTADDR :
cpu_is_omap34xx() ? OMAP343X_CONTROL_IVA2_BOOTADDR :
cpu_is_omap44xx() ? OMAP4_CTRL_MODULE_CORE_DSP_BOOTADDR :
+ soc_is_omap54xx() ? OMAP4_CTRL_MODULE_CORE_DSP_BOOTADDR :
0;
if (!offset) {
--
1.8.2
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: OMAP2+: nand: reorganize gpmc timing values
* Christoph Fritz chf.fr...@googlemail.com [130419 09:34]:
This patch removes omap2_nand_gpmc_retime() which was used to quirk
some timing values before gpmc_cs_set_timings(). Due to recent changes,
gpmc_cs_set_timings() has evolved so that there is no more need for a
retime function.
To keep the gpmc configuration consistent for legacy board files, this
patch also adds oe_on and we_on to nand_default_timings[] as they
would be by the retime function.
Signed-off-by: Christoph Fritz chf.fr...@googlemail.com
Thanks looks safe to me so applying into omap-for-v3.11/gpmc.
Regards,
Tony
---
arch/arm/mach-omap2/board-flash.c |3 +++
arch/arm/mach-omap2/gpmc-nand.c | 40
+
2 files changed, 4 insertions(+), 39 deletions(-)
diff --git a/arch/arm/mach-omap2/board-flash.c
b/arch/arm/mach-omap2/board-flash.c
index c33adea..fc20a61 100644
--- a/arch/arm/mach-omap2/board-flash.c
+++ b/arch/arm/mach-omap2/board-flash.c
@@ -112,6 +112,9 @@ struct gpmc_timings nand_default_timings[1] = {
.cs_rd_off = 36,
.cs_wr_off = 36,
+ .we_on = 6,
+ .oe_on = 6,
+
.adv_on = 6,
.adv_rd_off = 24,
.adv_wr_off = 36,
diff --git a/arch/arm/mach-omap2/gpmc-nand.c b/arch/arm/mach-omap2/gpmc-nand.c
index d9c2719..c8044b0 100644
--- a/arch/arm/mach-omap2/gpmc-nand.c
+++ b/arch/arm/mach-omap2/gpmc-nand.c
@@ -43,44 +43,6 @@ static struct platform_device gpmc_nand_device = {
.resource = gpmc_nand_resource,
};
-static int omap2_nand_gpmc_retime(
- struct omap_nand_platform_data *gpmc_nand_data,
- struct gpmc_timings *gpmc_t)
-{
- struct gpmc_timings t;
- int err;
-
- memset(t, 0, sizeof(t));
- t.sync_clk = gpmc_t-sync_clk;
- t.cs_on = gpmc_t-cs_on;
- t.adv_on = gpmc_t-adv_on;
-
- /* Read */
- t.adv_rd_off = gpmc_t-adv_rd_off;
- t.oe_on = t.adv_on;
- t.access = gpmc_t-access;
- t.oe_off = gpmc_t-oe_off;
- t.cs_rd_off = gpmc_t-cs_rd_off;
- t.rd_cycle = gpmc_t-rd_cycle;
-
- /* Write */
- t.adv_wr_off = gpmc_t-adv_wr_off;
- t.we_on = t.oe_on;
- if (cpu_is_omap34xx()) {
- t.wr_data_mux_bus = gpmc_t-wr_data_mux_bus;
- t.wr_access = gpmc_t-wr_access;
- }
- t.we_off = gpmc_t-we_off;
- t.cs_wr_off = gpmc_t-cs_wr_off;
- t.wr_cycle = gpmc_t-wr_cycle;
-
- err = gpmc_cs_set_timings(gpmc_nand_data-cs, t);
- if (err)
- return err;
-
- return 0;
-}
-
static bool gpmc_hwecc_bch_capable(enum omap_ecc ecc_opt)
{
/* support only OMAP3 class */
@@ -131,7 +93,7 @@ int gpmc_nand_init(struct omap_nand_platform_data
*gpmc_nand_data,
gpmc_get_client_irq(GPMC_IRQ_COUNT_EVENT);
if (gpmc_t) {
- err = omap2_nand_gpmc_retime(gpmc_nand_data, gpmc_t);
+ err = gpmc_cs_set_timings(gpmc_nand_data-cs, gpmc_t);
if (err 0) {
dev_err(dev, Unable to set gpmc timings: %d\n, err);
return err;
--
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: [PATCH v2] ARM: OMAP2+: Allow NAND transfer mode to be specified in DT
* Mark Jackson mpfj-l...@newflow.co.uk [130423 05:28]: OMAP devices support various NAND transfer modes. Currently all device-tree definitions will use the default prefetch polled mode, so this patch enables the transfer mode to be specified in the device-tree. Signed-off-by: Mark Jackson m...@newflow.co.uk Thanks applying into omap-for-v3.11/gpmc with Pekon's ack. 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] ARM: OMAP4: change the device names in usb_bind_phy
* Tomi Valkeinen tomi.valkei...@iki.fi [130515 03:59]: 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 kis...@ti.com --- 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? Just checking.. Do you have CONFIG_OMAP_OCP2SCP=y in your .config? Sounds like the some transceivers should depend on that for omap4. The musb-hdrc id is wrong on overo also. Hmm has there been a fix posted for that? 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
[RFC PATCH v2] ARM: OMAP4+: protect SCU code compilation
From: Vincent Stehlé v-ste...@ti.com
This fixes the following link error when compiling only for OMAP5:
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é v-ste...@ti.com
---
Hi Santosh,
Here is a try at gating all SCU references from OMAP4/5 common code. That
does build and run for me on OMAP4 and 5. On OMAP4, System.map files are even
identical with and without the patch.
How would you like this, please?
Best regards,
V.
arch/arm/mach-omap2/omap-smp.c | 10 ++
arch/arm/mach-omap2/sleep44xx.S | 10 ++
2 files changed, 20 insertions(+)
diff --git a/arch/arm/mach-omap2/omap-smp.c b/arch/arm/mach-omap2/omap-smp.c
index 2a551f9..45c8b5d 100644
--- a/arch/arm/mach-omap2/omap-smp.c
+++ b/arch/arm/mach-omap2/omap-smp.c
@@ -21,7 +21,9 @@
#include linux/io.h
#include linux/irqchip/arm-gic.h
+#ifdef CONFIG_HAVE_ARM_SCU
#include asm/smp_scu.h
+#endif
#include omap-secure.h
#include omap-wakeupgen.h
@@ -41,15 +43,19 @@
u16 pm44xx_errata;
+#ifdef CONFIG_HAVE_ARM_SCU
/* SCU base address */
static void __iomem *scu_base;
+#endif
static DEFINE_SPINLOCK(boot_lock);
+#ifdef CONFIG_HAVE_ARM_SCU
void __iomem *omap4_get_scu_base(void)
{
return scu_base;
}
+#endif
static void __cpuinit omap4_secondary_init(unsigned int cpu)
{
@@ -176,6 +182,7 @@ static void __init omap4_smp_init_cpus(void)
/* Use ARM cpuid check here, as SoC detection will not work so early */
cpu_id = read_cpuid_id() CPU_MASK;
if (cpu_id == CPU_CORTEX_A9) {
+#ifdef CONFIG_HAVE_ARM_SCU
/*
* Currently we can't call ioremap here because
* SoC detection won't work until after init_early.
@@ -183,6 +190,7 @@ static void __init omap4_smp_init_cpus(void)
scu_base = OMAP2_L4_IO_ADDRESS(scu_a9_get_base());
BUG_ON(!scu_base);
ncores = scu_get_core_count(scu_base);
+#endif
} else if (cpu_id == CPU_CORTEX_A15) {
ncores = OMAP5_CORE_COUNT;
}
@@ -203,12 +211,14 @@ static void __init omap4_smp_prepare_cpus(unsigned int
max_cpus)
void *startup_addr = omap_secondary_startup;
void __iomem *base = omap_get_wakeupgen_base();
+#ifdef CONFIG_HAVE_ARM_SCU
/*
* Initialise the SCU and wake up the secondary core using
* wakeup_secondary().
*/
if (scu_base)
scu_enable(scu_base);
+#endif
if (cpu_is_omap446x()) {
startup_addr = omap_secondary_startup_4460;
diff --git a/arch/arm/mach-omap2/sleep44xx.S b/arch/arm/mach-omap2/sleep44xx.S
index 88ff83a..3e73a32 100644
--- a/arch/arm/mach-omap2/sleep44xx.S
+++ b/arch/arm/mach-omap2/sleep44xx.S
@@ -10,7 +10,11 @@
*/
#include linux/linkage.h
+
+#ifdef CONFIG_HAVE_ARM_SCU
#include asm/smp_scu.h
+#endif
+
#include asm/memory.h
#include asm/hardware/cache-l2x0.h
@@ -70,6 +74,7 @@ ENTRY(omap4_finish_suspend)
* Flush all data from the L1 data cache before disabling
* SCTLR.C bit.
*/
+#ifdef CONFIG_HAVE_ARM_SCU
bl omap4_get_sar_ram_base
ldr r9, [r0, #OMAP_TYPE_OFFSET]
cmp r9, #0x1@ Check for HS device
@@ -81,6 +86,7 @@ ENTRY(omap4_finish_suspend)
DO_SMC
ldmfd r13!, {r4-r12, r14}
skip_secure_l1_clean:
+#endif
bl v7_flush_dcache_all
/*
@@ -108,6 +114,7 @@ skip_secure_l1_clean:
* preventing the CPU from receiving cache, TLB, or BTB
* maintenance operations broadcast by other CPUs in the cluster.
*/
+#ifdef CONFIG_HAVE_ARM_SCU
bl omap4_get_sar_ram_base
mov r8, r0
ldr r9, [r8, #OMAP_TYPE_OFFSET]
@@ -131,6 +138,7 @@ scu_gp_set:
bl omap4_get_scu_base
bl scu_power_mode
skip_scu_gp_set:
+#endif
mrc p15, 0, r0, c1, c1, 2 @ Read NSACR data
tst r0, #(1 18)
mrcne p15, 0, r0, c1, c0, 1
@@ -211,6 +219,7 @@ do_WFI:
orreq r0, r0, #(1 6)
mcreq p15, 0, r0, c1, c0, 1
isb
+#ifdef CONFIG_HAVE_ARM_SCU
bl omap4_get_sar_ram_base
mov r8, r0
ldr r9, [r8, #OMAP_TYPE_OFFSET]
@@ -228,6 +237,7 @@ scu_gp_clear:
mov r1, #SCU_PM_NORMAL
bl scu_power_mode
skip_scu_gp_clear:
+#endif
isb
dsb
ldmfd sp!, {r4-r12, pc}
--
1.7.10.4
--
Re: [PATCH] ARM: OMAP4: change the device names in usb_bind_phy
On 16/05/13 18:58, Tony Lindgren wrote: * Tomi Valkeinen tomi.valkei...@iki.fi [130515 03:59]: 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 kis...@ti.com --- 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? Just checking.. Do you have CONFIG_OMAP_OCP2SCP=y in your .config? Sounds like the some transceivers should depend on that for omap4. Yes, I have OCP2SCP=y. The musb-hdrc id is wrong on overo also. Hmm has there been a fix posted for that? I couldn't find with a quick look. We debugged and discussed this on an irc channel with Kishon, who said he'll send a patch. Changing the musb-hdrc ID on overo fixed the issue, and it looks very similar to the error on 4430sdp. The overo fix was just: diff --git a/arch/arm/mach-omap2/board-overo.c b/arch/arm/mach-omap2/board-overo.c index 4ca6b68..a496774 100644 --- a/arch/arm/mach-omap2/board-overo.c +++ b/arch/arm/mach-omap2/board-overo.c @@ -472,7 +472,7 @@ static void __init overo_init(void) mt46h32m32lf6_sdrc_params); board_nand_init(overo_nand_partitions, ARRAY_SIZE(overo_nand_partitions), NAND_CS, 0, NULL); - usb_bind_phy(musb-hdrc.0.auto, 0, twl4030_usb); + usb_bind_phy(musb-hdrc.1.auto, 0, twl4030_usb); usb_musb_init(NULL); usbhs_init_phys(phy_data, ARRAY_SIZE(phy_data)); Is that ID randomly chosen? Doesn't that mean that it'll just get broken every now and then? 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: [PATCH 06/13] mmc: omap_hsmmc: add dt pbias and control mmc support
Hi,
* Balaji T K balaj...@ti.com [130430 07:09]:
Add omap_hsmmc_control to support pbias, high speed mode configuration for
mmc1,
loopback clock configuration (when external transceiver is used) for mmc2
Thanks for working on this, few suggestions inlined below.
--- a/drivers/mmc/host/omap_hsmmc.c
+++ b/drivers/mmc/host/omap_hsmmc.c
@@ -182,6 +182,7 @@ struct omap_hsmmc_host {
struct omap_hsmmc_next next_data;
struct omap_mmc_platform_data *pdata;
+ struct omap_hsmmc_control *ctrl_mmc;
int needs_vmmc:1;
int needs_vmmc_aux:1;
};
@@ -265,6 +266,8 @@ static int omap_hsmmc_set_power(struct device *dev, int
slot, int power_on,
if (mmc_slot(host).before_set_reg)
mmc_slot(host).before_set_reg(dev, slot, power_on, vdd);
+ if (host-ctrl_mmc host-ctrl_mmc-before)
+ host-ctrl_mmc-before(host-ctrl_mmc-dev, power_on, vdd);
/*
* Assume Vcc regulator is used only to power the card ... OMAP
@@ -302,6 +305,8 @@ static int omap_hsmmc_set_power(struct device *dev, int
slot, int power_on,
if (mmc_slot(host).after_set_reg)
mmc_slot(host).after_set_reg(dev, slot, power_on, vdd);
+ if (host-ctrl_mmc host-ctrl_mmc-after)
+ host-ctrl_mmc-after(host-ctrl_mmc-dev, power_on, vdd);
return ret;
}
These before and after functions should be first converted to just usual
regulator_set_voltage() eventually. In the PBIAS case it's really a mux
plus a comparator, but we can set it up as a regulator. And on some boards
it can be an external regulator like we have the legacy callbacks for in
mach-omap2/hsmmc.c.
+++ b/drivers/mmc/host/omap_hsmmc_control.c
@@ -0,0 +1,466 @@
+static void omap_control_mmc_writel(u32 reg, u32 *base2)
+{
+ if (base2)
+ __raw_writel(reg, base2);
+ return;
+}
+
+static u32 omap_control_mmc_readl(u32 *base2)
+{
+ u32 pbias_reg = 0;
+
+ if (base2)
+ pbias_reg = __raw_readl(base2);
+ return pbias_reg;
+}
+
+static void omap2430_mmc1_active_overwrite(u32 __iomem *devconf1, int vdd)
+{
+ u32 reg;
+
+ reg = omap_control_mmc_readl(devconf1);
+ if ((1 vdd) = MMC_VDD_30_31)
+ reg |= OMAP243X_MMC1_ACTIVE_OVERWRITE;
+ else
+ reg = ~OMAP243X_MMC1_ACTIVE_OVERWRITE;
+ omap_control_mmc_writel(reg, devconf1);
+}
+/* pbias configuration for omap2430, omap3 */
+static void omap_hsmmc1_before_set_reg(struct device *dev,
+ int power_on, int vdd)
+{
+ u32 reg;
+ struct omap_hsmmc_control *ctl_mmc = dev_get_drvdata(dev);
+
+ if (ctl_mmc-devconf1)
+ omap2430_mmc1_active_overwrite(ctl_mmc-devconf1, vdd);
+
+ reg = omap_control_mmc_readl(ctl_mmc-pbias);
+ reg = ~OMAP2_PBIASLITEPWRDNZ0;
+ omap_control_mmc_writel(reg, ctl_mmc-pbias);
+}
+
+static void omap_hsmmc1_after_set_reg(struct device *dev,
+ int power_on, int vdd)
+{
+ u32 reg;
+ struct omap_hsmmc_control *ctl_mmc = dev_get_drvdata(dev);
+
+ /* 100ms delay required for PBIAS configuration */
+ msleep(100);
+
+ if (power_on) {
+ reg = omap_control_mmc_readl(ctl_mmc-pbias);
+ reg |= OMAP2_PBIASLITEPWRDNZ0;
+ if ((1 vdd) = MMC_VDD_165_195)
+ reg = ~OMAP2_PBIASLITEVMODE0;
+ else
+ reg |= OMAP2_PBIASLITEVMODE0;
+ omap_control_mmc_writel(reg, ctl_mmc-pbias);
+ } else {
+ reg = omap_control_mmc_readl(ctl_mmc-pbias);
+ reg |= (OMAP2_PBIASLITEPWRDNZ0 |
+ OMAP2_PBIASLITEVMODE0);
+ omap_control_mmc_writel(reg, ctl_mmc-pbias);
+ }
+}
...
This all we can simplify quite a bit by defining the PBIAS register
as pinctrl-single,bits with two different named modes. One for
1.8V and for 3.3V. This way the PBIAS register is abstracted for
various omaps in the .dts file as the register is different.
Then this file should just define a new regulator that requests the
defined pinctrl named mode with pinctrl_select_state().
Now the only thing missing AFAIK is getting the comparator value
for checks with the generic pinconf framework. But you can already
get the raw register value with pin_config_get() and add the
checking to this driver until pinconf allows us to do that.
BTW, the same can then be done for the USB transceivers if we
figure out a way to properly deal with comparators with generic
pinconf.
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] ARM: OMAP4: change the device names in usb_bind_phy
* Tomi Valkeinen tomi.valkei...@iki.fi [130516 09:11]: On 16/05/13 18:58, Tony Lindgren wrote: * Tomi Valkeinen tomi.valkei...@iki.fi [130515 03:59]: Just checking.. Do you have CONFIG_OMAP_OCP2SCP=y in your .config? Sounds like the some transceivers should depend on that for omap4. Yes, I have OCP2SCP=y. Hmm well no idea beyond that then. Sounds like Kishon should check it. The musb-hdrc id is wrong on overo also. Hmm has there been a fix posted for that? I couldn't find with a quick look. We debugged and discussed this on an irc channel with Kishon, who said he'll send a patch. Changing the musb-hdrc ID on overo fixed the issue, and it looks very similar to the error on 4430sdp. The overo fix was just: diff --git a/arch/arm/mach-omap2/board-overo.c b/arch/arm/mach-omap2/board-overo.c index 4ca6b68..a496774 100644 --- a/arch/arm/mach-omap2/board-overo.c +++ b/arch/arm/mach-omap2/board-overo.c @@ -472,7 +472,7 @@ static void __init overo_init(void) mt46h32m32lf6_sdrc_params); board_nand_init(overo_nand_partitions, ARRAY_SIZE(overo_nand_partitions), NAND_CS, 0, NULL); - usb_bind_phy(musb-hdrc.0.auto, 0, twl4030_usb); + usb_bind_phy(musb-hdrc.1.auto, 0, twl4030_usb); usb_musb_init(NULL); usbhs_init_phys(phy_data, ARRAY_SIZE(phy_data)); Is that ID randomly chosen? Doesn't that mean that it'll just get broken every now and then? Yes if so it's not a good solution. For omap4 we'll be flipping over to be device tree only for v3.11, but that still leaves earlier omaps to worry about. I'll wait for a proper patch for the above for the -rc series after we hear from Kishon. 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] ARM: dts: OMAP2+: Simplify NAND support
* Jon Hunter jon-hun...@ti.com [130430 07:16]: Commit 8c8a777 (ARM: OMAP2+: Add function to read GPMC settings from device-tree) added a device-tree property gpmc,device-nand to indicate is the GPMC child device is NAND. This commit should have updated the GPMC NAND documentation (Documentation/devicetree/bindings/mtd/gpmc-nand.txt) to list the property gpmc,device-nand as a required property and also updated the example. However, this property is redundant and not needed because the GPMC child device node for NAND is called nand. Therefore, remove this property. Signed-off-by: Jon Hunter jon-hun...@ti.com Thanks applying into omap-for-v3.11/gpmc. 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: usb: musb: Fix LapDock enumeration on omap for boot and slow cable insertion
* Felipe Balbi ba...@ti.com [130515 07:11]: On Fri, May 03, 2013 at 11:01:33AM -0700, Tony Lindgren wrote: * Tony Lindgren t...@atomide.com [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. Yes, in this case we get both interrupts and the order depends on how fast/slow the cable is inserted. Have you hacked a Hub to backfeed 5V to OMAP by any chance ? ..as that's how the LapDock seems to behave backfeeding 5V. It would be interesting to take a look at the signaling on it, but I think my old beagle sniffer is fried. Looking at the Figure 6-1: Common State Diagram on page 32 in USB_OTG_and_EH_3-0_release_1_1_10May2012.pdf the logic is the following depending on the order of interrupt: start - id ground - a_idle - a_wait_vrise - a_wait_bcon... or start - vbus - b_idle - id ground - a_idle - a_wait_vrise - a_wait_bcon... I don't think having the VBUS there actually violates that if we just should follow the ID state and accept that a_wait_vrise is already satisfied and not even try to turn the VBUS at MUSB end in that case. Regards, Tony -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH, v2] ARM: omap2: gpmc: fix compilation warning
* Vincent Stehlé vincent.ste...@laposte.net [130514 10:26]:
From: Vincent Stehlé v-ste...@ti.com
Fix the following compilation warning:
arch/arm/mach-omap2/gpmc.c: In function 'gpmc_probe_generic_child':
arch/arm/mach-omap2/gpmc.c:1477:4: warning: format '%x' expects argument of
type 'unsigned int', but argument 4 has type 'resource_size_t' [-Wformat]
Signed-off-by: Vincent Stehlé v-ste...@ti.com
Cc: triv...@kernel.org
---
Tony wrote:
You should just change the format for dev_err instead of the casting.
Hi,
Sorry for the late answer; it seems this is a bit more complicated after all,
as res.start can be 32b or 64b in LPAE. The common solution seems to be: cast
to long long in all cases and print accordingly. Would you like this better?
Oh OK. In this case the GPMC is always within the 32-bit address space.
But considering that similar issue will be there for other code with
LPAE, how about add something generic to arch/arm/include/asm/io.h like:
#define PHYS_ADDR32(x) ((__force u32)(x))
#define PHYS_ADDR64(x) ((__force u64)(x))
Or maybe something like that already exists.
Regards,
Tony
arch/arm/mach-omap2/gpmc.c |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach-omap2/gpmc.c b/arch/arm/mach-omap2/gpmc.c
index 6c4da12..e74501e 100644
--- a/arch/arm/mach-omap2/gpmc.c
+++ b/arch/arm/mach-omap2/gpmc.c
@@ -1473,8 +1473,8 @@ static int gpmc_probe_generic_child(struct
platform_device *pdev,
*/
ret = gpmc_cs_remap(cs, res.start);
if (ret 0) {
- dev_err(pdev-dev, cannot remap GPMC CS %d to 0x%x\n,
- cs, res.start);
+ dev_err(pdev-dev, cannot remap GPMC CS %d to 0x%llx\n,
+ cs, (long long)res.start);
goto err;
}
--
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: [PATCH V5 1/6] clk: OMAP: introduce device tree binding to kernel clock data
* Mike Turquette mturque...@linaro.org [130513 16:56]: Quoting Nishanth Menon (2013-05-08 12:06:11) snip Overall strategy introduced here is simple: a clock node described in device tree blob is used to identify the exact clock provided in the SoC specific data. This is then linked back using of_clk_add_provider to the device node to be accessible by of_clk_get. FYI, I'm working on moving the OMAP clocks over to DT which is a better alternative than this patch. I'll share what I have on the list, hopefully next week. That's good news! What's your plan on using the indexing the clocks? I'd rather avoid indexing as that's basically same as the old IRQ numbering and GPIO numbering schemes that don't work well in the long term. We already have quite a few sets of clocks for omaps, so the indexing is already an issue. My thinking is that indexing should only be used if the same physical clock has multiple outputs. 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] ARM: dts: OMAP: Add usb_otg and glue data to OMAP3+ boards
* Kishon Vijay Abraham I kis...@ti.com [130514 23:27]:
On Saturday 11 May 2013 08:05 AM, Tony Lindgren wrote:
Commit ad871c10 (ARM: dts: OMAP: Add usb_otg and glue data to
OMAP3+ boards) added support for MUSB on omap3 for device tree,
but added the interrupts the wrong way probably as they were
copied from the omap4.dtsi file. On omap3 we have TI specific
interrupt controller, not GIC.
Fix this by specifying the interrupt following the TI INTC
binding.
Without this fix MUSB won't work as it is trying to use
irq0 instead of irq92.
Signed-off-by: Tony Lindgren t...@atomide.com
Tested in beagleboard-xm
Tested-by: Kishon Vijay Abraham I kis...@ti.com
Oops thanks, sorry I already pushed it out into omap-for-v3.10/dt-fixes
before noticing your tested-by.
Regards,
Tony
--- a/arch/arm/boot/dts/omap3.dtsi
+++ b/arch/arm/boot/dts/omap3.dtsi
@@ -516,7 +516,7 @@
usb_otg_hs: usb_otg_hs@480ab000 {
compatible = ti,omap3-musb;
reg = 0x480ab000 0x1000;
-interrupts = 0 92 0x4, 0 93 0x4;
+interrupts = 92, 93;
interrupt-names = mc, dma;
ti,hwmods = usb_otg_hs;
multipoint = 1;
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: OMAP: fix error return code in omap1_system_dma_init()
* Wei Yongjun weiyj...@gmail.com [130512 21:30]: From: Wei Yongjun yongjun_...@trendmicro.com.cn Fix to return -ENOMEM in the d-chan alloc error handling case instead of 0, as done elsewhere in this function. Signed-off-by: Wei Yongjun yongjun_...@trendmicro.com.cn Thanks, applying into omap-for-v3.10/fixes. Regards, Tony --- arch/arm/mach-omap1/dma.c | 1 + 1 file changed, 1 insertion(+) diff --git a/arch/arm/mach-omap1/dma.c b/arch/arm/mach-omap1/dma.c index 68ab858..a94b3a7 100644 --- a/arch/arm/mach-omap1/dma.c +++ b/arch/arm/mach-omap1/dma.c @@ -345,6 +345,7 @@ static int __init omap1_system_dma_init(void) dev_err(pdev-dev, %s: Memory allocation failed for d-chan!\n, __func__); + ret = -ENOMEM; goto exit_release_d; } -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: OMAP: fix __init section mismatch for _enable_preprogram
* jean-philippe francois jp.franc...@cynove.com [130513 02:34]: Hi, _enable_preprogram is marked as __init, but is called from _enable which is not. Without this patch, the board oopses after init. Tested on custom hardware and on beagle board xM. Signed-off-by: Jean-Philippe François jp.franc...@cynove.com Thanks applying into omap-for-v3.10/fixes. Regards, Tony -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: defconfigs: OMAP: omap2plus_defconfig missing CONFIG_ARCH_MULTI_V6=y
* Paul Walmsley p...@pwsan.com [130513 10:09]: On Mon, 13 May 2013, Paul Walmsley wrote: Fix by setting CONFIG_ARCH_MULTI_V7. Well, obvious typo here. Here's the updated version. Thanks applying into omap-for-v3.10/fixes. Regards, Tony -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [BISECTED] 3.10-rc1 OMAP1 GPIO IRQ regression
* Aaro Koskinen aaro.koski...@iki.fi [130513 13:58]: Hi, I tested 3.10-rc1 on OMAP1 / Nokia 770, and Retu MFD probe is broken: [2.264221] retu-mfd 2-0001: Retu v3.2 found [2.281951] retu-mfd 2-0001: Failed to allocate IRQs: -12 [2.300140] retu-mfd: probe of 2-0001 failed with error -12 The error is coming from regmap code. According to git bisect, it is caused by: commit ede4d7a5b9835510fd1f724367f68d2fa4128453 Author: Jon Hunter jon-hun...@ti.com Date: Fri Mar 1 11:22:47 2013 -0600 gpio/omap: convert gpio irq domain to linear mapping The commit does not anymore revert cleanly, and I haven't yet tried crafting a manual revert, so any fix proposals/ideas are welcome... Hmm this might be a bit trickier to fix. Obviously the real solution is to convert omap1 to SPARSE_IRQ like we did for omap2+. For the -rc cycle, it might be possible to fix this by adding a different irq_to_gpio() and gpio_to_irq() functions for omap1. 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: am3517: failed to boot 3.10-rc1
* Yegor Yefremov yegor_s...@visionsystems.de [130515 02:37]: 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 t...@linutronix.de 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 t...@linutronix.de Cc: Linus Torvalds torva...@linux-foundation.org Cc: Rusty Russell ru...@rustcorp.com.au Cc: Paul McKenney paul...@linux.vnet.ibm.com Cc: Peter Zijlstra pet...@infradead.org Reviewed-by: Cc: Srivatsa S. Bhat srivatsa.b...@linux.vnet.ibm.com Cc: Magnus Damm magnus.d...@gmail.com Cc: Russell King li...@arm.linux.org.uk Tested-by: Kevin Hilman khil...@linaro.org # 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. Hmm at least am3703 boots just fine with v3.10-rc1 except for the deeper idle states not working properly without the patch I posted. And looks like the PM for DT based booting still needs a bit work. 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] ARM : omap : remove __init for _enable_preprogram
* Kevin Hilman khil...@linaro.org [130514 11:13]: jp.franc...@cynove.com writes: _enable_preprogram is marked as __init, but is called from _enable which is not. This results in oops once init is freed. Fix this by removing the __init marker. Signed-off-by: Jean-Philippe François jp.franc...@cynove.com Acked-by: Kevin Hilman khil...@linaro.org Tony, this should probably be queued for v3.10-rc, and tagged for stable. Yes just applied the earlier version of this and added your ack with cc: stable. 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 Thu, May 16, 2013 at 10:35 AM, Dan Murphy dmur...@ti.com wrote: I am not sure you really want to do this. If I make the pinctrl part of the led structure then the only way the gpio_wk7 on a1-a3 to be configured is when the CONFIG_LEDS_GPIO flag is set. Do you really want that dependency? You did say it was a key fix At least this way the pins are configured regardless of that flag. That is better as the system will be left in the pinmux configuration handed over from bootloader. The point being, muxing up pins even when not needed(config switched off) has no real benefit - in this case albeit, the default mux was causing a bug. pinctrl IMHO should be considered as any other resource, if it is not mandatory for boot, and needed only for a device functionality when probed, it should done there only. just my 2 cents. -- 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 0/6] ARM: OMAP2+: hwmod and SERIAL: Remove sysc handling from driver
On Wed, 15 May 2013, Rajendra Nayak wrote: 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. These look good to me. Will queue them for v3.10-rc once they pass local testing here. - Paul -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: OMAP baseline test results for v3.9
On Tue, 14 May 2013, Tony Lindgren wrote: Thanks that explains. BTW, the PM off naming might make some people think that CONFIG_PM is not set :) That's a good point. Will rename that and probably split the 3730 Beagle XM into its own testing category. - Paul -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: OMAP3: Fix iva2_pwrdm settings for 3703
* Yegor Yefremov yegor_s...@visionsystems.de [130516 05:13]: On 15.05.2013 23:50, Mark A. Greer wrote: On Wed, May 15, 2013 at 10:07:35AM -0700, Tony Lindgren wrote: * Mark A. Greer mgr...@animalcreek.com [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 t...@atomide.com --- 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. I think this issue is relevant to am3517 as you can see from this thread: http://thread.gmane.org/gmane.linux.ports.arm.omap/97903 I could boot only with your patch http://www.spinics.net/lists/arm-kernel/msg168865.html OK sounds like Mark's patch as http://www.spinics.net/lists/arm-kernel/msg168865.html is needed as a fix. I have such a system running, so if you have any other patches/ideas to test, I would do it. Well I think my patch does not matter for am3517 as that one has iva2 while am3703 does not. 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] ARM: OMAP3: Fix iva2_pwrdm settings for 3703
* Tony Lindgren t...@atomide.com [130516 11:40]: * Yegor Yefremov yegor_s...@visionsystems.de [130516 05:13]: I think this issue is relevant to am3517 as you can see from this thread: http://thread.gmane.org/gmane.linux.ports.arm.omap/97903 I could boot only with your patch http://www.spinics.net/lists/arm-kernel/msg168865.html OK sounds like Mark's patch as http://www.spinics.net/lists/arm-kernel/msg168865.html is needed as a fix. Yegor, thinking about your boot issue more, I'm thinking that you have your board .init_time = omap3_secure_sync32k_timer_init, or some non-waking gpt timer. And that means the system won't wake to timer events. The system should still wake to timer events even if you have no wake-up events configred, so Mark's patch probably does not fix the right issue for you. 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 V5 1/6] clk: OMAP: introduce device tree binding to kernel clock data
* Mike Turquette mturque...@linaro.org [130516 12:52]:
Quoting Tony Lindgren (2013-05-16 10:43:56)
* Mike Turquette mturque...@linaro.org [130513 16:56]:
Quoting Nishanth Menon (2013-05-08 12:06:11)
snip
Overall strategy introduced here is simple: a clock node described in
device tree blob is used to identify the exact clock provided in the
SoC specific data. This is then linked back using of_clk_add_provider
to the device node to be accessible by of_clk_get.
FYI, I'm working on moving the OMAP clocks over to DT which is a better
alternative than this patch. I'll share what I have on the list,
hopefully next week.
That's good news! What's your plan on using the indexing the clocks?
I'd rather avoid indexing as that's basically same as the old IRQ
numbering and GPIO numbering schemes that don't work well in the long
term.
We already have quite a few sets of clocks for omaps, so the indexing
is already an issue. My thinking is that indexing should only be used
if the same physical clock has multiple outputs.
At present I am actually describing the clock hardware in DT. Each
clock is a node (not a device) using the established clock binding in
Documentation/devicetree/bindings/clocks/clock-bindings.txt.
To do this I am introducing new bindings for the common types: gate, mux
divider. These are the ones I am migrating to DT first. Eventually
I'll create bindings for the OMAP-specifc clocks after this.
Great, that's the way to go.
I currently have this DT approach co-existing with the static data. As
a start I have used the fixed-clock and mux-clock bindings to put all of
the root clocks and sys_clk into arch/arm/boot/dts/omap4-clocks.dtsi.
This file is included by arch/arm/boot/dts/omap4.dtsi.
OK.
The DT clocks are parsed prior to the static clock registration:
diff --git a/arch/arm/mach-omap2/cclock44xx_data.c
b/arch/arm/mach-omap2/cclock44xx_data.c
index 88e37a4..7cc4cae 100644
--- a/arch/arm/mach-omap2/cclock44xx_data.c
+++ b/arch/arm/mach-omap2/cclock44xx_data.c
@@ -27,6 +27,7 @@
#include linux/clk-private.h
#include linux/clkdev.h
#include linux/io.h
+#include linux/clk/omap.h
#include soc.h
#include iomap.h
@@ -1442,27 +1443,11 @@ static struct omap_clk omap443x_clks[] = {
* clocks common to omap44xx
*/
static struct omap_clk omap44xx_clks[] = {
- CLK(NULL, extalt_clkin_ck, extalt_clkin_ck),
CLK(NULL, pad_clks_src_ck, pad_clks_src_ck),
CLK(NULL, pad_clks_ck, pad_clks_ck),
- CLK(NULL, pad_slimbus_core_clks_ck,
pad_slimbus_core_clks_ck),
- CLK(NULL, secure_32k_clk_src_ck,secure_32k_clk_src_ck),
CLK(NULL, slimbus_src_clk, slimbus_src_clk),
CLK(NULL, slimbus_clk, slimbus_clk),
CLK(NULL, sys_32k_ck, sys_32k_ck),
- CLK(NULL, virt_1200_ck, virt_1200_ck),
- CLK(NULL, virt_1300_ck, virt_1300_ck),
- CLK(NULL, virt_1680_ck, virt_1680_ck),
- CLK(NULL, virt_1920_ck, virt_1920_ck),
- CLK(NULL, virt_2600_ck, virt_2600_ck),
- CLK(NULL, virt_2700_ck, virt_2700_ck),
- CLK(NULL, virt_3840_ck, virt_3840_ck),
- CLK(NULL, sys_clkin_ck, sys_clkin_ck),
- CLK(NULL, tie_low_clock_ck, tie_low_clock_ck),
- CLK(NULL, utmi_phy_clkout_ck, utmi_phy_clkout_ck),
- CLK(NULL, xclk60mhsp1_ck, xclk60mhsp1_ck),
- CLK(NULL, xclk60mhsp2_ck, xclk60mhsp2_ck),
- CLK(NULL, xclk60motg_ck,xclk60motg_ck),
CLK(NULL, abe_dpll_bypass_clk_mux_ck,
abe_dpll_bypass_clk_mux_ck),
CLK(NULL, abe_dpll_refclk_mux_ck,
abe_dpll_refclk_mux_ck),
CLK(NULL, dpll_abe_ck, dpll_abe_ck),
@@ -1690,6 +1675,9 @@ int __init omap4xxx_clk_init(void)
{
int rc;
+ /* FIXME register clocks from DT first */
+ dt_omap_clk_init();
+
if (cpu_is_omap443x()) {
cpu_mask = RATE_IN_4430;
omap_clocks_register(omap443x_clks, ARRAY_SIZE(omap443x_clks));
Ideally dt_omap_clk_init() will go away and instead by replaced by the
probe from drivers/clk/omap/clk.c (new omap clock driver). However I
still need to register the root clocks before the PLLs and other
dividers for now to avoid many issues (divide by zero errors, failed
reparent operations, etc). And furthermore I don't think the hwmod code
will work if the clock tree is not populated before module_init. So for
now the omap clock driver does not properly probe or call module_init,
but some day that might be fixed.
Yes,
Re: [PATCH v4] ARM:dts:omap4-panda: Update the LED support for the panda DTS
On 05/16/2013 01:18 PM, Nishanth Menon wrote: On Thu, May 16, 2013 at 10:35 AM, Dan Murphy dmur...@ti.com wrote: I am not sure you really want to do this. If I make the pinctrl part of the led structure then the only way the gpio_wk7 on a1-a3 to be configured is when the CONFIG_LEDS_GPIO flag is set. Do you really want that dependency? You did say it was a key fix At least this way the pins are configured regardless of that flag. That is better as the system will be left in the pinmux configuration handed over from bootloader. So you want to depend on a boot loader to configure pins correctly for the kernel? Hmmm seems risky to me. The point being, muxing up pins even when not needed(config switched off) has no real benefit - in this case albeit, the default mux was causing a bug. pinctrl IMHO should be considered as any other resource, if it is not mandatory for boot, and needed only for a device functionality when probed, it should done there only. just my 2 cents. -- 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 -- -- 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 v4] ARM:dts:omap4-panda: Update the LED support for the panda DTS
On Thu, May 16, 2013 at 3:22 PM, Dan Murphy dmur...@ti.com wrote: On 05/16/2013 01:18 PM, Nishanth Menon wrote: On Thu, May 16, 2013 at 10:35 AM, Dan Murphy dmur...@ti.com wrote: I am not sure you really want to do this. If I make the pinctrl part of the led structure then the only way the gpio_wk7 on a1-a3 to be configured is when the CONFIG_LEDS_GPIO flag is set. Do you really want that dependency? You did say it was a key fix At least this way the pins are configured regardless of that flag. That is better as the system will be left in the pinmux configuration handed over from bootloader. So you want to depend on a boot loader to configure pins correctly for the kernel? Hmmm seems risky to me. Not really! if it is a critical pinmux, pinmux defaults are great, else belongs definitely to device-pinctrl :) depending on bootloader pinmux implies NOT having pinmux even for device - NO. that is definitely not what I stated. Regards, NM -- 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: [BISECTED] 3.10-rc1 OMAP1 GPIO IRQ regression
On Thu, May 16, 2013 at 11:09:34AM -0700, Tony Lindgren wrote:
* Aaro Koskinen aaro.koski...@iki.fi [130513 13:58]:
I tested 3.10-rc1 on OMAP1 / Nokia 770, and Retu MFD probe is broken:
[2.264221] retu-mfd 2-0001: Retu v3.2 found
[2.281951] retu-mfd 2-0001: Failed to allocate IRQs: -12
[2.300140] retu-mfd: probe of 2-0001 failed with error -12
The error is coming from regmap code. According to git bisect, it is
caused by:
commit ede4d7a5b9835510fd1f724367f68d2fa4128453
Author: Jon Hunter jon-hun...@ti.com
Date: Fri Mar 1 11:22:47 2013 -0600
gpio/omap: convert gpio irq domain to linear mapping
The commit does not anymore revert cleanly, and I haven't yet tried
crafting a manual revert, so any fix proposals/ideas are welcome...
Hmm this might be a bit trickier to fix. Obviously the real solution
is to convert omap1 to SPARSE_IRQ like we did for omap2+.
For the -rc cycle, it might be possible to fix this by adding a
different irq_to_gpio() and gpio_to_irq() functions for omap1.
The commit reverts cleanly if we also revert
3513cdeccc647d41c4a9ff923af17deaaac04a66 (gpio/omap: optimise interrupt
service routine), which seems to be just some minor optimization. The
result is below, and with it 770 works again.
A.
diff --git a/drivers/gpio/gpio-omap.c b/drivers/gpio/gpio-omap.c
index 2050891..a9b5813 100644
--- a/drivers/gpio/gpio-omap.c
+++ b/drivers/gpio/gpio-omap.c
@@ -52,6 +52,7 @@ struct gpio_bank {
struct list_head node;
void __iomem *base;
u16 irq;
+ int irq_base;
struct irq_domain *domain;
u32 non_wakeup_gpios;
u32 enabled_non_wakeup_gpios;
@@ -87,14 +88,7 @@ struct gpio_bank {
static int irq_to_gpio(struct gpio_bank *bank, unsigned int gpio_irq)
{
- return bank-chip.base + gpio_irq;
-}
-
-static int omap_gpio_to_irq(struct gpio_chip *chip, unsigned offset)
-{
- struct gpio_bank *bank = container_of(chip, struct gpio_bank, chip);
-
- return irq_find_mapping(bank-domain, offset);
+ return gpio_irq - bank-irq_base + bank-chip.base;
}
static void _set_gpio_direction(struct gpio_bank *bank, int gpio, int is_input)
@@ -435,7 +429,7 @@ static int gpio_irq_type(struct irq_data *d, unsigned type)
#endif
if (!gpio)
- gpio = irq_to_gpio(bank, d-hwirq);
+ gpio = irq_to_gpio(bank, d-irq);
if (type ~IRQ_TYPE_SENSE_MASK)
return -EINVAL;
@@ -588,7 +582,7 @@ static void _reset_gpio(struct gpio_bank *bank, int gpio)
static int gpio_wake_enable(struct irq_data *d, unsigned int enable)
{
struct gpio_bank *bank = irq_data_get_irq_chip_data(d);
- unsigned int gpio = irq_to_gpio(bank, d-hwirq);
+ unsigned int gpio = irq_to_gpio(bank, d-irq);
return _set_gpio_wakeup(bank, gpio, enable);
}
@@ -688,7 +682,7 @@ static void gpio_irq_handler(unsigned int irq, struct
irq_desc *desc)
{
void __iomem *isr_reg = NULL;
u32 isr;
- unsigned int bit;
+ unsigned int gpio_irq, gpio_index;
struct gpio_bank *bank;
int unmasked = 0;
struct irq_chip *chip = irq_desc_get_chip(desc);
@@ -729,9 +723,14 @@ static void gpio_irq_handler(unsigned int irq, struct
irq_desc *desc)
if (!isr)
break;
- while (isr) {
- bit = __ffs(isr);
- isr = ~(1 bit);
+ gpio_irq = bank-irq_base;
+ for (; isr != 0; isr = 1, gpio_irq++) {
+ int gpio = irq_to_gpio(bank, gpio_irq);
+
+ if (!(isr 1))
+ continue;
+
+ gpio_index = GPIO_INDEX(bank, gpio);
/*
* Some chips can't respond to both rising and falling
@@ -740,10 +739,10 @@ static void gpio_irq_handler(unsigned int irq, struct
irq_desc *desc)
* to respond to the IRQ for the opposite direction.
* This will be indicated in the bank toggle_mask.
*/
- if (bank-toggle_mask (1 bit))
- _toggle_gpio_edge_triggering(bank, bit);
+ if (bank-toggle_mask (1 gpio_index))
+ _toggle_gpio_edge_triggering(bank, gpio_index);
- generic_handle_irq(irq_find_mapping(bank-domain, bit));
+ generic_handle_irq(gpio_irq);
}
}
/* if bank has any level sensitive GPIO pin interrupt
@@ -759,7 +758,7 @@ exit:
static void gpio_irq_shutdown(struct irq_data *d)
{
struct gpio_bank *bank = irq_data_get_irq_chip_data(d);
- unsigned int gpio = irq_to_gpio(bank, d-hwirq);
+ unsigned int gpio = irq_to_gpio(bank, d-irq);
unsigned long flags;
spin_lock_irqsave(bank-lock, flags);
Re: [BISECTED] 3.10-rc1 OMAP1 GPIO IRQ regression
* Aaro Koskinen aaro.koski...@iki.fi [130516 14:05]: On Thu, May 16, 2013 at 11:09:34AM -0700, Tony Lindgren wrote: * Aaro Koskinen aaro.koski...@iki.fi [130513 13:58]: I tested 3.10-rc1 on OMAP1 / Nokia 770, and Retu MFD probe is broken: [2.264221] retu-mfd 2-0001: Retu v3.2 found [2.281951] retu-mfd 2-0001: Failed to allocate IRQs: -12 [2.300140] retu-mfd: probe of 2-0001 failed with error -12 The error is coming from regmap code. According to git bisect, it is caused by: commit ede4d7a5b9835510fd1f724367f68d2fa4128453 Author: Jon Hunter jon-hun...@ti.com Date: Fri Mar 1 11:22:47 2013 -0600 gpio/omap: convert gpio irq domain to linear mapping The commit does not anymore revert cleanly, and I haven't yet tried crafting a manual revert, so any fix proposals/ideas are welcome... Hmm this might be a bit trickier to fix. Obviously the real solution is to convert omap1 to SPARSE_IRQ like we did for omap2+. For the -rc cycle, it might be possible to fix this by adding a different irq_to_gpio() and gpio_to_irq() functions for omap1. The commit reverts cleanly if we also revert 3513cdeccc647d41c4a9ff923af17deaaac04a66 (gpio/omap: optimise interrupt service routine), which seems to be just some minor optimization. The result is below, and with it 770 works again. Hmm in this case it seems that we should just fix it rather than go back to the old code, so let's take a look at that first. 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 2/2] mfd: twl-core: convert to module_i2c_driver()
Hi Grygorii, On Tue, Apr 23, 2013 at 04:19:10PM +0300, Grygorii Strashko wrote: Shift TWL initialization to module/device init layer, because I2C now is not initialized on subsys init layer and shifted to module/device init layer instead. The I2C -- TWL dependency should be resolved in drivers/Makefile now. Cc: Santosh Shilimkar santosh.shilim...@ti.com Cc: linux-omap@vger.kernel.org Cc: linux-ker...@vger.kernel.org Signed-off-by: Grygorii Strashko grygorii.stras...@ti.com --- drivers/mfd/twl-core.c | 12 +--- 1 file changed, 1 insertion(+), 11 deletions(-) I applied this one to mfd-next for now, and will move it to mfd-fixes if someone confirms that this is indeed a fix. Cheers, Samuel. -- Intel Open Source Technology Centre http://oss.intel.com/ -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/2] mfd: twl-core: convert to module_i2c_driver()
* Samuel Ortiz sa...@linux.intel.com [130516 15:22]: Hi Grygorii, On Tue, Apr 23, 2013 at 04:19:10PM +0300, Grygorii Strashko wrote: Shift TWL initialization to module/device init layer, because I2C now is not initialized on subsys init layer and shifted to module/device init layer instead. The I2C -- TWL dependency should be resolved in drivers/Makefile now. Cc: Santosh Shilimkar santosh.shilim...@ti.com Cc: linux-omap@vger.kernel.org Cc: linux-ker...@vger.kernel.org Signed-off-by: Grygorii Strashko grygorii.stras...@ti.com --- drivers/mfd/twl-core.c | 12 +--- 1 file changed, 1 insertion(+), 11 deletions(-) I applied this one to mfd-next for now, and will move it to mfd-fixes if someone confirms that this is indeed a fix. Thanks, AFAIK it can wait until v3.11 merge window. 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] ARM: OMAP4: change the device names in usb_bind_phy
Hi, On Thursday 16 May 2013 09:50 PM, Tony Lindgren wrote: * Tomi Valkeinen tomi.valkei...@iki.fi [130516 09:11]: On 16/05/13 18:58, Tony Lindgren wrote: * Tomi Valkeinen tomi.valkei...@iki.fi [130515 03:59]: Just checking.. Do you have CONFIG_OMAP_OCP2SCP=y in your .config? Sounds like the some transceivers should depend on that for omap4. Yes, I have OCP2SCP=y. Hmm well no idea beyond that then. Sounds like Kishon should check it. The musb-hdrc id is wrong on overo also. Hmm has there been a fix posted for that? I couldn't find with a quick look. We debugged and discussed this on an irc channel with Kishon, who said he'll send a patch. Changing the musb-hdrc ID on overo fixed the issue, and it looks very similar to the error on 4430sdp. The overo fix was just: hmm.. I think using device name to bind the controller and the phy can no longer be used reliably. I think it's better to have something like what Grant suggested in my other patch series.. to have the phy reference into the host controllers platform_data structure. And for the phy reference I'll have label and id. Does this makes sense to you? Thanks Kishon -- 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
