Re: [alsa-devel] [PATCH RFC v2 0/2] Fix simple-card *-master DT parameter handling
Hi Richard
but anyway, if my understanding is correct,
simple-audio-card,cpu {
...
bitclock-master;
frame-master;
};
simple-audio-card,codec {
...
bitclock-master;
frame-master;
};
This will be
cpu : SND_SOC_DAIFMT_CBS_CFS
codec : SND_SOC_DAIFMT_CBM_CFM
Yes, That's also what my understanding of this patches.
Thank you. I understand.
(and I need to send fixup patches :)
# codec-is-bitclock-master seems understandable than
# current bitclock-master...
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/3] ARM: dts: overo: Add support for DVI output
On 11/03/14 14:34, Florian Vaussard wrote:
Summit and Tobi expansion boards have a HDMI connector with a TFP410
encoder. Add a common include file for this configuration, and then
use it for Summit and Tobi.
Signed-off-by: Florian Vaussard florian.vauss...@epfl.ch
---
arch/arm/boot/dts/omap3-overo-common-dvi.dtsi| 109
+++
arch/arm/boot/dts/omap3-overo-summit-common.dtsi | 1 +
arch/arm/boot/dts/omap3-overo-tobi-common.dtsi | 1 +
3 files changed, 111 insertions(+)
create mode 100644 arch/arm/boot/dts/omap3-overo-common-dvi.dtsi
snip
+dss {
+ status = ok;
+
+ pinctrl-names = default;
+ pinctrl-0 = dss_dpi_pins
+ i2c3_pins;
The i2c3 pins don't belong here, they are not related to dss. The
dvi-connector uses i2c3, but I don't think they belong there either, as
the i2c3 bus can be used by multiple devices. So I guess they should be
set in i2c3 node.
Tomi
signature.asc
Description: OpenPGP digital signature
Re: [PATCH 0/3] ARM: dts: overo: Add graphics output
On 11/03/14 14:34, Florian Vaussard wrote: Hi, This series enables the DVI / LCD graphics present on some of the Overo expansion boards. DVI output: - Tobi - Summit LCD (3.5''): - Alto35 LCD (4.3''): - Chestnut43 - Palo43 - Gallop43 I tested on Tobi, Alto35 and Gallop43 using both OMAP35xx and OMAP36xx Overo boards. This series depends on Tomi's DSS patches [1] that are not yet merged. It also depends on previous Overo series [2] and [3] that are under review. A complete testing tree is available [4]. Looks good to me. Unfortunately the video bindings are still being discussed (mainly the ports/endpoints), so there might be changes needed when some kind of conclusion is reached. Tomi signature.asc Description: OpenPGP digital signature
Re: [alsa-devel] [PATCH RFC v2 0/2] Fix simple-card *-master DT parameter handling
On 03/12/2014 08:11 AM, Kuninori Morimoto wrote:
Hi Richard
but anyway, if my understanding is correct,
simple-audio-card,cpu {
...
bitclock-master;
frame-master;
};
simple-audio-card,codec {
...
bitclock-master;
frame-master;
};
This will be
cpu : SND_SOC_DAIFMT_CBS_CFS
codec : SND_SOC_DAIFMT_CBM_CFM
Yes, That's also what my understanding of this patches.
Thank you. I understand.
(and I need to send fixup patches :)
# codec-is-bitclock-master seems understandable than
# current bitclock-master...
Sounds great to me!
Best regards,
Jyri
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 0/2] add parallel NAND support for TI's new OMAPx and AMxx platforms
*changes v1 - v2* - AM335x (am335x-evm): already accepted, so dropping in v2 - DRA7xx (dra7-evm): resending - AM43xx (am43X-epos-evm): fix MTD NAND.filesystem partition offset *Original v1* This patch-set adds and updates parallel NAND support on following TI platforms - AM335x (am335x-evm) - DRA7xx (dra7-evm - AM43xx (am43X-epos-evm) In addition, following OMAP2+/GPMC patch is also added in this series as it add checks DRA7xx and AM43xxx platforms for non-DT kernels. ARM: OMAP2+: gpmc: update gpmc_hwecc_bch_capable() for new platforms Minal Shah (1): ARM: dts: dra7: add support for parallel NAND flash Pekon Gupta (1): ARM: dts: am43xx: fix starting offset of NAND.filesystem MTD partition arch/arm/boot/dts/am43x-epos-evm.dts | 2 +- arch/arm/boot/dts/dra7-evm.dts | 117 +++ arch/arm/boot/dts/dra7.dtsi | 20 ++ 3 files changed, 138 insertions(+), 1 deletion(-) -- 1.8.5.1.163.gd7aced9 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 1/2] ARM: dts: dra7: add support for parallel NAND flash
From: Minal Shah minal.s...@ti.com
DRA7xx platform has in-build GPMC and ELM h/w engines which can be used
for accessing externel NAND flash device. This patch:
- adds generic DT binding in dra7.dtsi for enabling GPMC and ELM h/w engines
- adds DT binding for Micron NAND Flash (MT29F2G16AADWP) present on dra7-evm
*Important*
On DRA7 EVM, GPMC_WPN and NAND_BOOTn are controlled by DIP switch
So following board settings are required for NAND device detection:
SW5.9 (GPMC_WPN) = LOW
SW5.1 (NAND_BOOTn) = HIGH
Signed-off-by: Minal Shah minal.s...@ti.com
Signed-off-by: Pekon Gupta pe...@ti.com
---
arch/arm/boot/dts/dra7-evm.dts | 117 +
arch/arm/boot/dts/dra7.dtsi| 20 +++
2 files changed, 137 insertions(+)
diff --git a/arch/arm/boot/dts/dra7-evm.dts b/arch/arm/boot/dts/dra7-evm.dts
index 5babba0..7b4e6f5 100644
--- a/arch/arm/boot/dts/dra7-evm.dts
+++ b/arch/arm/boot/dts/dra7-evm.dts
@@ -93,6 +93,37 @@
0x24c (PIN_INPUT_SLEW | MUX_MODE0) /* uart3_txd */
;
};
+
+ nand_flash_x16: nand_flash_x16 {
+ /* On DRA7 EVM, GPMC_WPN and NAND_BOOTn comes from DIP switch
+* So NAND flash requires following switch settings:
+* SW5.9 (GPMC_WPN) = LOW
+* SW5.1 (NAND_BOOTn) = HIGH */
+ pinctrl-single,pins =
+ 0x0 (PIN_INPUT | MUX_MODE0)/* gpmc_ad0
*/
+ 0x4 (PIN_INPUT | MUX_MODE0)/* gpmc_ad1
*/
+ 0x8 (PIN_INPUT | MUX_MODE0)/* gpmc_ad2
*/
+ 0xc (PIN_INPUT | MUX_MODE0)/* gpmc_ad3
*/
+ 0x10(PIN_INPUT | MUX_MODE0)/* gpmc_ad4
*/
+ 0x14(PIN_INPUT | MUX_MODE0)/* gpmc_ad5
*/
+ 0x18(PIN_INPUT | MUX_MODE0)/* gpmc_ad6
*/
+ 0x1c(PIN_INPUT | MUX_MODE0)/* gpmc_ad7
*/
+ 0x20(PIN_INPUT | MUX_MODE0)/* gpmc_ad8
*/
+ 0x24(PIN_INPUT | MUX_MODE0)/* gpmc_ad9
*/
+ 0x28(PIN_INPUT | MUX_MODE0)/* gpmc_ad10
*/
+ 0x2c(PIN_INPUT | MUX_MODE0)/* gpmc_ad11
*/
+ 0x30(PIN_INPUT | MUX_MODE0)/* gpmc_ad12
*/
+ 0x34(PIN_INPUT | MUX_MODE0)/* gpmc_ad13
*/
+ 0x38(PIN_INPUT | MUX_MODE0)/* gpmc_ad14
*/
+ 0x3c(PIN_INPUT | MUX_MODE0)/* gpmc_ad15
*/
+ 0xD8(PIN_INPUT_PULLUP | MUX_MODE0) /* gpmc_wait0
*/
+ 0xCC(PIN_OUTPUT | MUX_MODE0)/* gpmc_wen
*/
+ 0xB4(PIN_OUTPUT_PULLUP | MUX_MODE0) /* gpmc_csn0
*/
+ 0xC4(PIN_OUTPUT | MUX_MODE0)/*
gpmc_advn_ale */
+ 0xC8(PIN_OUTPUT | MUX_MODE0)/* gpmc_oen_ren
*/
+ 0xD0(PIN_OUTPUT | MUX_MODE0)/*
gpmc_be0n_cle */
+ ;
+ };
};
i2c1 {
@@ -273,3 +304,89 @@
cpu0 {
cpu0-supply = smps123_reg;
};
+
+elm {
+ status = okay;
+};
+
+gpmc {
+ status = okay;
+ pinctrl-names = default;
+ pinctrl-0 = nand_flash_x16;
+ ranges = 0 0 0x0800 0x1000;
+ nand@0,0 {
+ reg = 0 0 0;
+ ti,nand-ecc-opt = bch8;
+ ti,elm-id = elm;
+ nand-bus-width = 16;
+ gpmc,device-width = 2;
+ gpmc,sync-clk-ps = 0;
+ gpmc,cs-on-ns = 0;
+ gpmc,cs-rd-off-ns = 40;
+ gpmc,cs-wr-off-ns = 40;
+ gpmc,adv-on-ns = 0;
+ gpmc,adv-rd-off-ns = 30;
+ gpmc,adv-wr-off-ns = 30;
+ gpmc,we-on-ns = 5;
+ gpmc,we-off-ns = 25;
+ gpmc,oe-on-ns = 2;
+ gpmc,oe-off-ns = 20;
+ gpmc,access-ns = 20;
+ gpmc,wr-access-ns = 40;
+ gpmc,rd-cycle-ns = 40;
+ gpmc,wr-cycle-ns = 40;
+ gpmc,wait-on-read = true;
+ gpmc,wait-on-write = true;
+ gpmc,bus-turnaround-ns = 0;
+ gpmc,cycle2cycle-delay-ns = 0;
+ gpmc,clk-activation-ns = 0;
+ gpmc,wait-monitoring-ns = 0;
+ gpmc,wr-data-mux-bus-ns = 0;
+ /* MTD partition table */
+ /* All SPL-* partitions are sized to minimal length
+* which can be independently programmable. For
+* NAND flash this is equal to size of erase-block */
+ #address-cells = 1;
+ #size-cells = 1;
+ partition@0 {
+
[PATCH v2 2/2] ARM: dts: am43xx: fix starting offset of NAND.filesystem MTD partition
MTD NAND partition for file-system should start at offset=0xA0
Signed-off-by: Pekon Gupta pe...@ti.com
---
arch/arm/boot/dts/am43x-epos-evm.dts | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/am43x-epos-evm.dts
b/arch/arm/boot/dts/am43x-epos-evm.dts
index 167dbc8..d09e6fb 100644
--- a/arch/arm/boot/dts/am43x-epos-evm.dts
+++ b/arch/arm/boot/dts/am43x-epos-evm.dts
@@ -341,7 +341,7 @@
};
partition@9 {
label = NAND.file-system;
- reg = 0x0080 0x1F60;
+ reg = 0x00A0 0x1F60;
};
};
};
--
1.8.5.1.163.gd7aced9
--
To unsubscribe from this list: send the line unsubscribe 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: OMAP5: DSS hwmod data
Hi, This patch adds hwmod data for omap5 display subsystem. I have tested this on omap5-uevm with a DSI panel. I cannot test omap5-uevm's hdmi output yet, as the mainline is missing omap5 HDMI driver. I do see this when booting: omap_hwmod: dss_dispc: cannot be enabled for reset (3) omap_hwmod: dss_dsi1: cannot be enabled for reset (3) omap_hwmod: dss_dsi2: cannot be enabled for reset (3) omap_hwmod: dss_hdmi: cannot be enabled for reset (3) omap_hwmod: dss_rfbi: cannot be enabled for reset (3) But at least DSI works just fine. Tomi Archit Taneja (1): ARM: OMAP5: Add omap5 DSS related hwmod data arch/arm/mach-omap2/omap_hwmod_54xx_data.c | 283 + 1 file changed, 283 insertions(+) -- 1.8.3.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
[PATCH] ARM: OMAP5: Add omap5 DSS related hwmod data
From: Archit Taneja arc...@ti.com
Add hwmod data for dss core, dispc dsi1, dsi2, rfbi and hdmi. It's more or less
similar to omap4 hwmod data.
Signed-off-by: Archit Taneja arc...@ti.com
Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
---
arch/arm/mach-omap2/omap_hwmod_54xx_data.c | 283 +
1 file changed, 283 insertions(+)
diff --git a/arch/arm/mach-omap2/omap_hwmod_54xx_data.c
b/arch/arm/mach-omap2/omap_hwmod_54xx_data.c
index e297d6231c3a..c7d33ae26282 100644
--- a/arch/arm/mach-omap2/omap_hwmod_54xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_54xx_data.c
@@ -334,6 +334,235 @@ static struct omap_hwmod omap54xx_dmic_hwmod = {
};
/*
+ * 'dss' class
+ * display sub-system
+ */
+static struct omap_hwmod_class_sysconfig omap54xx_dss_sysc = {
+ .rev_offs = 0x,
+ .syss_offs = 0x0014,
+ .sysc_flags = SYSS_HAS_RESET_STATUS,
+};
+
+static struct omap_hwmod_class omap54xx_dss_hwmod_class = {
+ .name = dss,
+ .sysc = omap54xx_dss_sysc,
+ .reset = omap_dss_reset,
+};
+
+/* dss */
+static struct omap_hwmod_opt_clk dss_opt_clks[] = {
+ { .role = 32khz_clk, .clk = dss_32khz_clk },
+ { .role = sys_clk, .clk = dss_sys_clk },
+ { .role = hdmi_clk, .clk = dss_48mhz_clk },
+};
+
+static struct omap_hwmod omap54xx_dss_hwmod = {
+ .name = dss_core,
+ .class = omap54xx_dss_hwmod_class,
+ .clkdm_name = dss_clkdm,
+ .flags = HWMOD_CONTROL_OPT_CLKS_IN_RESET,
+ .main_clk = dss_dss_clk,
+ .prcm = {
+ .omap4 = {
+ .clkctrl_offs = OMAP54XX_CM_DSS_DSS_CLKCTRL_OFFSET,
+ .context_offs = OMAP54XX_RM_DSS_DSS_CONTEXT_OFFSET,
+ .modulemode = MODULEMODE_SWCTRL,
+ },
+ },
+ .opt_clks = dss_opt_clks,
+ .opt_clks_cnt = ARRAY_SIZE(dss_opt_clks),
+};
+
+/*
+ * 'dispc' class
+ * display controller
+ */
+
+static struct omap_hwmod_class_sysconfig omap54xx_dispc_sysc = {
+ .rev_offs = 0x,
+ .sysc_offs = 0x0010,
+ .syss_offs = 0x0014,
+ .sysc_flags = (SYSC_HAS_AUTOIDLE | SYSC_HAS_CLOCKACTIVITY |
+ SYSC_HAS_ENAWAKEUP | SYSC_HAS_MIDLEMODE |
+ SYSC_HAS_SIDLEMODE | SYSC_HAS_SOFTRESET |
+ SYSS_HAS_RESET_STATUS),
+ .idlemodes = (SIDLE_FORCE | SIDLE_NO | SIDLE_SMART |
+ MSTANDBY_FORCE | MSTANDBY_NO | MSTANDBY_SMART),
+ .sysc_fields= omap_hwmod_sysc_type1,
+};
+
+static struct omap_hwmod_class omap54xx_dispc_hwmod_class = {
+ .name = dispc,
+ .sysc = omap54xx_dispc_sysc,
+};
+
+/* dss_dispc */
+static struct omap_hwmod_opt_clk dss_dispc_opt_clks[] = {
+ { .role = sys_clk, .clk = dss_sys_clk },
+};
+
+/* dss_dispc dev_attr */
+static struct omap_dss_dispc_dev_attr dss_dispc_dev_attr = {
+ .has_framedonetv_irq= 1,
+ .manager_count = 4,
+};
+
+static struct omap_hwmod omap54xx_dss_dispc_hwmod = {
+ .name = dss_dispc,
+ .class = omap54xx_dispc_hwmod_class,
+ .clkdm_name = dss_clkdm,
+ .main_clk = dss_dss_clk,
+ .prcm = {
+ .omap4 = {
+ .clkctrl_offs = OMAP54XX_CM_DSS_DSS_CLKCTRL_OFFSET,
+ .flags = HWMOD_OMAP4_NO_CONTEXT_LOSS_BIT,
+ },
+ },
+ .opt_clks = dss_dispc_opt_clks,
+ .opt_clks_cnt = ARRAY_SIZE(dss_dispc_opt_clks),
+ .dev_attr = dss_dispc_dev_attr,
+};
+
+/*
+ * 'dsi1' class
+ * display serial interface controller
+ */
+
+static struct omap_hwmod_class_sysconfig omap54xx_dsi1_sysc = {
+ .rev_offs = 0x,
+ .sysc_offs = 0x0010,
+ .syss_offs = 0x0014,
+ .sysc_flags = (SYSC_HAS_AUTOIDLE | SYSC_HAS_CLOCKACTIVITY |
+ SYSC_HAS_ENAWAKEUP | SYSC_HAS_SIDLEMODE |
+ SYSC_HAS_SOFTRESET | SYSS_HAS_RESET_STATUS),
+ .idlemodes = (SIDLE_FORCE | SIDLE_NO | SIDLE_SMART),
+ .sysc_fields= omap_hwmod_sysc_type1,
+};
+
+static struct omap_hwmod_class omap54xx_dsi1_hwmod_class = {
+ .name = dsi1,
+ .sysc = omap54xx_dsi1_sysc,
+};
+
+/* dss_dsi1_a */
+static struct omap_hwmod_opt_clk dss_dsi1_a_opt_clks[] = {
+ { .role = sys_clk, .clk = dss_sys_clk },
+};
+
+static struct omap_hwmod omap54xx_dss_dsi1_a_hwmod = {
+ .name = dss_dsi1,
+ .class = omap54xx_dsi1_hwmod_class,
+ .clkdm_name = dss_clkdm,
+ .main_clk = dss_dss_clk,
+ .prcm = {
+ .omap4 = {
+ .clkctrl_offs = OMAP54XX_CM_DSS_DSS_CLKCTRL_OFFSET,
+ .flags = HWMOD_OMAP4_NO_CONTEXT_LOSS_BIT,
+ },
+ },
+ .opt_clks = dss_dsi1_a_opt_clks,
+ .opt_clks_cnt
Re: [PATCH] ARM: OMAP5: DSS hwmod data
On 12/03/14 12:26, Tomi Valkeinen wrote: Hi, This patch adds hwmod data for omap5 display subsystem. I have tested this on omap5-uevm with a DSI panel. I cannot test omap5-uevm's hdmi output yet, as the mainline is missing omap5 HDMI driver. I do see this when booting: omap_hwmod: dss_dispc: cannot be enabled for reset (3) omap_hwmod: dss_dsi1: cannot be enabled for reset (3) omap_hwmod: dss_dsi2: cannot be enabled for reset (3) omap_hwmod: dss_hdmi: cannot be enabled for reset (3) omap_hwmod: dss_rfbi: cannot be enabled for reset (3) But at least DSI works just fine. Oh, I forgot to say that I tested this on top of the DSS DT branch, and unpublished omap5 and omap5-uevm display patches. So if applied to the current mainline, the hwmods are not used at all (except the reset at boot time, I think). But if this gets merged for 3.15, it'll make adding omap5 DSS support easier for 3.16 as the HWMOD data is already there. Tomi signature.asc Description: OpenPGP digital signature
[PATCH] arm: omap: cm-t3530: Add MMC2/SDIO/WLAN support
Add support for the MMC2/SDIO WiFi Libertas (Marvell) module available
on the CM-T3530 SOM.
Signed-off-by: Stefan Roese s...@denx.de
Cc: Dmitry Lifshitz lifsh...@compulab.co.il
Cc: Igor Grinberg grinb...@compulab.co.il
Cc: Tony Lindgren t...@atomide.com
---
This patch is based on current mainline (v3.14-rc6) plus this compulab patch
series from Dmitry:
[PATCH 00/11] ARM: dts: sbc-t3x: add support for more boards
http://www.spinics.net/lists/arm-kernel/msg300078.html
Thanks,
Stefan
arch/arm/boot/dts/omap3-cm-t3530.dts | 36
1 file changed, 36 insertions(+)
diff --git a/arch/arm/boot/dts/omap3-cm-t3530.dts
b/arch/arm/boot/dts/omap3-cm-t3530.dts
index 9faf1cd..d145849 100644
--- a/arch/arm/boot/dts/omap3-cm-t3530.dts
+++ b/arch/arm/boot/dts/omap3-cm-t3530.dts
@@ -9,4 +9,40 @@
/ {
model = CompuLab CM-T3530;
compatible = compulab,omap3-cm-t3530, ti,omap34xx, ti,omap3;
+
+ /* Regulator to trigger the reset signal of the Wifi module */
+ mmc2_sdio_reset: regulator-mmc2-sdio-reset {
+ compatible = regulator-fixed;
+ regulator-name = regulator-mmc2-sdio-reset;
+ regulator-min-microvolt = 330;
+ regulator-max-microvolt = 330;
+ gpio = twl_gpio 2 GPIO_ACTIVE_HIGH;
+ enable-active-high;
+ };
+};
+
+omap3_pmx_core {
+ mmc2_pins: pinmux_mmc2_pins {
+ pinctrl-single,pins =
+ OMAP3_CORE1_IOPAD(0x2158, PIN_INPUT_PULLUP | MUX_MODE0)
/* sdmmc2_clk.sdmmc2_clk */
+ OMAP3_CORE1_IOPAD(0x215a, PIN_INPUT_PULLUP | MUX_MODE0)
/* sdmmc2_cmd.sdmmc2_cmd */
+ OMAP3_CORE1_IOPAD(0x215c, PIN_INPUT_PULLUP | MUX_MODE0)
/* sdmmc2_dat0.sdmmc2_dat0 */
+ OMAP3_CORE1_IOPAD(0x215e, PIN_INPUT_PULLUP | MUX_MODE0)
/* sdmmc2_dat1.sdmmc2_dat1 */
+ OMAP3_CORE1_IOPAD(0x2160, PIN_INPUT_PULLUP | MUX_MODE0)
/* sdmmc2_dat2.sdmmc2_dat2 */
+ OMAP3_CORE1_IOPAD(0x2162, PIN_INPUT_PULLUP | MUX_MODE0)
/* sdmmc2_dat3.sdmmc2_dat3 */
+ OMAP3_CORE1_IOPAD(0x2164, PIN_OUTPUT | MUX_MODE1)
/* sdmmc2_dat4.sdmmc2_dir_dat0 */
+ OMAP3_CORE1_IOPAD(0x2166, PIN_OUTPUT | MUX_MODE1)
/* sdmmc2_dat5.sdmmc2_dir_dat1 */
+ OMAP3_CORE1_IOPAD(0x2168, PIN_OUTPUT | MUX_MODE1)
/* sdmmc2_dat6.sdmmc2_dir_cmd */
+ OMAP3_CORE1_IOPAD(0x216a, PIN_INPUT | MUX_MODE1)
/* sdmmc2_dat7.sdmmc2_clkin */
+ ;
+ };
+};
+
+mmc2 {
+ pinctrl-names = default;
+ pinctrl-0 = mmc2_pins;
+ vmmc-supply = mmc2_sdio_reset;
+ non-removable;
+ bus-width = 4;
+ cap-power-off-card;
};
--
1.8.5.5
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v1 3/3] ARM: dts: am437x-gp-evm: add support for parallel NAND flash
Adds pinmux and DT node for Micron (MT29F4G08AB) x8 NAND device present on
am437x-gp-evm board.
(1) As NAND Flash data lines are muxed with eMMC, Thus at a given time either
eMMC or NAND can be enabled. Selection between eMMC and NAND is controlled:
(a) By dynamically driving following GPIO pin from software
SPI2_CS0(GPIO) == 0 NAND is selected (default)
SPI2_CS0(GPIO) == 1 eMMC is selected
(b) By statically using Jumper (J89) on the board
(2) As NAND device connnected to this board has page-size=4K and oob-size=224,
So ROM code expects boot-loaders to be flashed in BCH16 ECC scheme for
NAND boot.
Signed-off-by: Pekon Gupta pe...@ti.com
---
arch/arm/boot/dts/am437x-gp-evm.dts | 107
1 file changed, 107 insertions(+)
diff --git a/arch/arm/boot/dts/am437x-gp-evm.dts
b/arch/arm/boot/dts/am437x-gp-evm.dts
index df8798e..0027ea7 100644
--- a/arch/arm/boot/dts/am437x-gp-evm.dts
+++ b/arch/arm/boot/dts/am437x-gp-evm.dts
@@ -81,6 +81,27 @@
0x164 MUX_MODE0 /*
eCAP0_in_PWM0_out.eCAP0_in_PWM0_out MODE0 */
;
};
+
+ nand_flash_x8: nand_flash_x8 {
+ pinctrl-single,pins =
+ 0x26C(PIN_OUTPUT_PULLDOWN | MUX_MODE7) /*
spi2_cs0.gpio/eMMCorNANDsel */
+ 0x0 (PIN_INPUT | MUX_MODE0) /* gpmc_ad0.gpmc_ad0 */
+ 0x4 (PIN_INPUT | MUX_MODE0) /* gpmc_ad1.gpmc_ad1 */
+ 0x8 (PIN_INPUT | MUX_MODE0) /* gpmc_ad2.gpmc_ad2 */
+ 0xc (PIN_INPUT | MUX_MODE0) /* gpmc_ad3.gpmc_ad3 */
+ 0x10 (PIN_INPUT | MUX_MODE0) /* gpmc_ad4.gpmc_ad4 */
+ 0x14 (PIN_INPUT | MUX_MODE0) /* gpmc_ad5.gpmc_ad5 */
+ 0x18 (PIN_INPUT | MUX_MODE0) /* gpmc_ad6.gpmc_ad6 */
+ 0x1c (PIN_INPUT | MUX_MODE0) /* gpmc_ad7.gpmc_ad7 */
+ 0x70 (PIN_INPUT_PULLUP | MUX_MODE0) /*
gpmc_wait0.gpmc_wait0 */
+ 0x74 (PIN_OUTPUT_PULLUP | MUX_MODE7)/*
gpmc_wpn.gpmc_wpn */
+ 0x7c (PIN_OUTPUT | MUX_MODE0) /*
gpmc_csn0.gpmc_csn0 */
+ 0x90 (PIN_OUTPUT | MUX_MODE0) /*
gpmc_advn_ale.gpmc_advn_ale */
+ 0x94 (PIN_OUTPUT | MUX_MODE0) /*
gpmc_oen_ren.gpmc_oen_ren */
+ 0x98 (PIN_OUTPUT | MUX_MODE0) /*
gpmc_wen.gpmc_wen */
+ 0x9c (PIN_OUTPUT | MUX_MODE0) /*
gpmc_be0n_cle.gpmc_be0n_cle */
+ ;
+ };
};
i2c0 {
@@ -125,3 +146,89 @@
pinctrl-0 = mmc1_pins;
cd-gpios = gpio0 6 GPIO_ACTIVE_HIGH;
};
+
+elm {
+ status = okay;
+};
+
+gpmc {
+ status = okay;
+ pinctrl-names = default;
+ pinctrl-0 = nand_flash_x8;
+ ranges = 0 0 0x0800 0x1000; /* CS0: NAND */
+ nand@0,0 {
+ reg = 0 0 0; /* CS0, offset 0 */
+ ti,nand-ecc-opt = bch8;
+ ti,elm-id = elm;
+ nand-bus-width = 8;
+ gpmc,device-width = 1;
+ gpmc,sync-clk-ps = 0;
+ gpmc,cs-on-ns = 0;
+ gpmc,cs-rd-off-ns = 40;
+ gpmc,cs-wr-off-ns = 40;
+ gpmc,adv-on-ns = 0;
+ gpmc,adv-rd-off-ns = 25;
+ gpmc,adv-wr-off-ns = 25;
+ gpmc,we-on-ns = 0;
+ gpmc,we-off-ns = 20;
+ gpmc,oe-on-ns = 3;
+ gpmc,oe-off-ns = 30;
+ gpmc,access-ns = 30;
+ gpmc,rd-cycle-ns = 40;
+ gpmc,wr-cycle-ns = 40;
+ gpmc,wait-on-read = true;
+ gpmc,wait-on-write = true;
+ gpmc,bus-turnaround-ns = 0;
+ gpmc,cycle2cycle-delay-ns = 0;
+ gpmc,clk-activation-ns = 0;
+ gpmc,wait-monitoring-ns = 0;
+ gpmc,wr-access-ns = 40;
+ gpmc,wr-data-mux-bus-ns = 0;
+ /* MTD partition table */
+ /* All SPL-* partitions are sized to minimal length
+* which can be independently programmable. For
+* NAND flash this is equal to size of erase-block */
+ #address-cells = 1;
+ #size-cells = 1;
+ partition@0 {
+ label = NAND.SPL;
+ reg = 0x 0x0004;
+ };
+ partition@1 {
+ label = NAND.SPL.backup1;
+ reg = 0x0004 0x0004;
+ };
+ partition@2 {
+ label = NAND.SPL.backup2;
+ reg = 0x0008 0x0004;
+ };
+ partition@3 {
+ label = NAND.SPL.backup3;
+ reg = 0x000C 0x0004;
+ };
+
[PATCH v1 0/3] add parallel NAND support for TI's new OMAPx and AMxx platforms (Part-2)
This patch-set adds parallel NAND support on following TI platforms - AM335x (am335x-bone LT, am335x-boneblack): disabled by default - AM43xx (am437x-gp-evm) Pekon Gupta (3): ARM: dts: am335x-bone: add support for beaglebone NAND cape ARM: dts: am335x-boneblack: add support for beaglebone NAND cape ARM: dts: am437x-gp-evm: add support for parallel NAND flash arch/arm/boot/dts/am335x-bone.dts | 123 + arch/arm/boot/dts/am335x-boneblack.dts | 120 arch/arm/boot/dts/am437x-gp-evm.dts| 107 3 files changed, 350 insertions(+) -- 1.8.5.1.163.gd7aced9 -- To unsubscribe from this list: send the line unsubscribe 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 v1 2/3] ARM: dts: am335x-boneblack: add support for beaglebone NAND cape
Beaglebone Board can be connected to expansion boards to add devices to them.
These expansion boards are called 'capes'. This patch adds support for
following versions of Beaglebone(AM335x) NAND capes
(a) NAND Device with bus-width=16, block-size=128k, page-size=2k, oob-size=64
(b) NAND Device with bus-width=16, block-size=256k, page-size=4k, oob-size=224
Further information and datasheets can be found at [1] and [2]
* How to boot from NAND using Memory Expander + NAND Cape ? *
- Important: As BOOTSEL values are sampled only at POR, so after changing any
setting on SW2 (DIP switch), disconnect and reconnect all board power supply
(including mini-USB console port) to POR the beaglebone.
- Selection of ECC scheme
for NAND cape(a), ROM code expects BCH8_HW ecc-scheme
for NAND cape(b), ROM code expects BCH16_HW ecc-scheme
- Selction of boot modes can be controlled via DIP switch(SW2) present on
Memory Expander cape.
SW2[SWITCH_BOOT] == OFF follow default boot order MMC- SPI - UART - USB
SW2[SWITCH_BOOT] == ON boot mode selected via DIP switch(SW2)
So to flash NAND, first boot via MMC or other sources and then switch to
SW2[SWITCH_BOOT]=ON to boot from NAND Cape.
- For NAND boot following switch settings need to be followed
SW2[ 0] = ON (SYSBOOT[ 0]==0: NAND boot mode selected )
SW2[ 1] = ON (SYSBOOT[ 1]==0: -- do -- )
SW2[ 2] = OFF (SYSBOOT[ 2]==1: -- do -- )
SW2[ 3] = OFF (SYSBOOT[ 3]==1: -- do -- )
SW2[ 4] = ON (SYSBOOT[ 4]==0: -- do -- )
SW2[ 8] = OFF (SYSBOOT[ 8]==1: 0:x8 device, 1:x16 device )
SW2[ 9] = ON (SYSBOOT[ 9]==0: ECC done by ROM )
SW2[10] = ON (SYSBOOT[10]==0: Non Muxed device )
SW2[11] = ON (SYSBOOT[11]==0:-- do -- )
[1] http://beagleboardtoys.info/index.php?title=BeagleBone_Memory_Expansion
[2]
http://beagleboardtoys.info/index.php?title=BeagleBone_4Gb_16-Bit_NAND_Module
Signed-off-by: Pekon Gupta pe...@ti.com
---
arch/arm/boot/dts/am335x-boneblack.dts | 120 +
1 file changed, 120 insertions(+)
diff --git a/arch/arm/boot/dts/am335x-boneblack.dts
b/arch/arm/boot/dts/am335x-boneblack.dts
index 6b71ad9..596cfec 100644
--- a/arch/arm/boot/dts/am335x-boneblack.dts
+++ b/arch/arm/boot/dts/am335x-boneblack.dts
@@ -60,6 +60,33 @@
0x1b0 0x03 /* xdma_event_intr0, OMAP_MUX_MODE3 |
AM33XX_PIN_OUTPUT */
;
};
+ nand_flash_x16: nand_flash_x16 {
+ pinctrl-single,pins =
+ 0x00 (MUX_MODE0 | PIN_INPUT)/* gpmc_ad0.gpmc_ad0 */
+ 0x04 (MUX_MODE0 | PIN_INPUT)/* gpmc_ad1.gpmc_ad1 */
+ 0x08 (MUX_MODE0 | PIN_INPUT)/* gpmc_ad2.gpmc_ad2 */
+ 0x0c (MUX_MODE0 | PIN_INPUT)/* gpmc_ad3.gpmc_ad3 */
+ 0x10 (MUX_MODE0 | PIN_INPUT)/* gpmc_ad4.gpmc_ad4 */
+ 0x14 (MUX_MODE0 | PIN_INPUT)/* gpmc_ad5.gpmc_ad5 */
+ 0x18 (MUX_MODE0 | PIN_INPUT)/* gpmc_ad6.gpmc_ad6 */
+ 0x1c (MUX_MODE0 | PIN_INPUT)/* gpmc_ad7.gpmc_ad7 */
+ 0x20 (MUX_MODE0 | PIN_INPUT)/* gpmc_ad8.gpmc_ad8 */
+ 0x24 (MUX_MODE0 | PIN_INPUT)/* gpmc_ad9.gpmc_ad9 */
+ 0x28 (MUX_MODE0 | PIN_INPUT)/* gpmc_ad10.gpmc_ad10
*/
+ 0x2c (MUX_MODE0 | PIN_INPUT)/* gpmc_ad11.gpmc_ad11
*/
+ 0x30 (MUX_MODE0 | PIN_INPUT)/* gpmc_ad12.gpmc_ad12
*/
+ 0x34 (MUX_MODE0 | PIN_INPUT)/* gpmc_ad13.gpmc_ad13
*/
+ 0x38 (MUX_MODE0 | PIN_INPUT)/* gpmc_ad14.gpmc_ad14
*/
+ 0x3c (MUX_MODE0 | PIN_INPUT)/* gpmc_ad15.gpmc_ad15
*/
+ 0x70 (MUX_MODE0 | PIN_INPUT_PULLUP )/*
gpmc_wait0.gpmc_wait0 */
+ 0x74 (MUX_MODE7 | PIN_OUTPUT_PULLUP)/*
gpmc_wpn.gpio0_30 */
+ 0x7c (MUX_MODE0 | PIN_OUTPUT_PULLUP)/*
gpmc_csn0.gpmc_csn0 */
+ 0x90 (MUX_MODE0 | PIN_OUTPUT) /*
gpmc_advn_ale.gpmc_advn_ale */
+ 0x94 (MUX_MODE0 | PIN_OUTPUT) /*
gpmc_oen_ren.gpmc_oen_ren */
+ 0x98 (MUX_MODE0 | PIN_OUTPUT) /*
gpmc_wen.gpmc_wen */
+ 0x9c (MUX_MODE0 | PIN_OUTPUT) /*
gpmc_be0n_cle.gpmc_be0n_cle */
+ ;
+ };
};
lcdc {
@@ -76,3 +103,96 @@
status = okay;
};
};
+
+/*
+ * uncomment following to enable NAND cape support
+ * mmc2 {
+ * status = disabled;
+ * };
+ * elm {
+ * status = okay;
+ * };
+ * gpmc {
+ * status = okay;
+ * };
+ */
+gpmc {
+ pinctrl-names = default;
+ pinctrl-0 = nand_flash_x16;
+ ranges = 0 0 0x0800 0x1000; /* CS0: NAND */
+ nand@0,0 {
+
Re: [alsa-devel] [PATCH RFC v2 0/2] Fix simple-card *-master DT parameter handling
On Wed, Mar 12, 2014 at 01:00:02PM +0800, Richard Lee wrote:
But, IMO, if you want the CPU DAI be CBS_CFS and CODEC be CBM_CFM,
you could just do it like this:
simple-audio-card,cpu {
...
};
simple-audio-card,codec {
...
bitclock-master;
frame-master;
};
and vice versa.
Thanks,
(I could find this mails in my Freescale acount, so I will reply it here.)
Yes, that'd been what I'd thought the binding did (and it's what Jyri's
patch makes it do).
signature.asc
Description: Digital signature
Re: [PATCHv8 2/4] power_supply: Introduce generic psy charging driver
On Mon, Mar 10, 2014 at 5:33 AM, Jenny Tc jenny...@intel.com wrote: On Fri, Mar 07, 2014 at 09:25:20PM +0100, Pavel Machek wrote: + /* sort based on priority. 0 has the highest priority */ + for (i = 0; i cnt; ++i) + for (j = 0; j cnt; ++j) + if (psy_prioirty(psy_lst[j]) psy_prioirty(psy_lst[i])) + swap(psy_lst[j], psy_lst[i]); + WTF? Bubble sort in kernel? Yes, it's bubble sort. Since the number of power supply objects in real systems (max 4) are limited, I feel the complexity would be as same as any other sorting algorithms. Any suggestions? You already have a kernel quicksort implementation in lib/sort.c. Please restructure the code to make use of this as it is already compiled into every kernel. Yours, Linus Walleij -- To unsubscribe from this list: send the line unsubscribe 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 v1 1/3] ARM: dts: am335x-bone: add support for beaglebone NAND cape
On 03/12/2014 05:49 AM, Pekon Gupta wrote:
Beaglebone Board can be connected to expansion boards to add devices to them.
These expansion boards are called 'capes'. This patch adds support for
following versions of Beaglebone(AM335x) NAND capes
(a) NAND Device with bus-width=16, block-size=128k, page-size=2k, oob-size=64
(b) NAND Device with bus-width=16, block-size=256k, page-size=4k, oob-size=224
Further information and datasheets can be found at [1] and [2]
* How to boot from NAND using Memory Expander + NAND Cape ? *
- Important: As BOOTSEL values are sampled only at POR, so after changing any
setting on SW2 (DIP switch), disconnect and reconnect all board power
supply
(including mini-USB console port) to POR the beaglebone.
- Selection of ECC scheme
for NAND cape(a), ROM code expects BCH8_HW ecc-scheme
for NAND cape(b), ROM code expects BCH16_HW ecc-scheme
- Selction of boot modes can be controlled via DIP switch(SW2) present on
Memory Expander cape.
SW2[SWITCH_BOOT] == OFF follow default boot order MMC- SPI - UART -
USB
SW2[SWITCH_BOOT] == ON boot mode selected via DIP switch(SW2)
So to flash NAND, first boot via MMC or other sources and then switch to
SW2[SWITCH_BOOT]=ON to boot from NAND Cape.
- For NAND boot following switch settings need to be followed
SW2[ 0] = ON (SYSBOOT[ 0]==0: NAND boot mode selected )
SW2[ 1] = ON (SYSBOOT[ 1]==0: -- do -- )
SW2[ 2] = OFF (SYSBOOT[ 2]==1: -- do -- )
SW2[ 3] = OFF (SYSBOOT[ 3]==1: -- do -- )
SW2[ 4] = ON (SYSBOOT[ 4]==0: -- do -- )
SW2[ 8] = OFF (SYSBOOT[ 8]==1: 0:x8 device, 1:x16 device )
SW2[ 9] = ON (SYSBOOT[ 9]==0: ECC done by ROM )
SW2[10] = ON (SYSBOOT[10]==0: Non Muxed device )
SW2[11] = ON (SYSBOOT[11]==0:-- do -- )
[1] http://beagleboardtoys.info/index.php?title=BeagleBone_Memory_Expansion
[2]
http://beagleboardtoys.info/index.php?title=BeagleBone_4Gb_16-Bit_NAND_Module
Signed-off-by: Pekon Gupta pe...@ti.com
---
arch/arm/boot/dts/am335x-bone.dts | 123
++
1 file changed, 123 insertions(+)
diff --git a/arch/arm/boot/dts/am335x-bone.dts
b/arch/arm/boot/dts/am335x-bone.dts
index 94ee427..be2c572 100644
--- a/arch/arm/boot/dts/am335x-bone.dts
+++ b/arch/arm/boot/dts/am335x-bone.dts
better to make a nand_cape dts which includes the am335x-bone.dts?
@@ -10,6 +10,36 @@
#include am33xx.dtsi
#include am335x-bone-common.dtsi
+am33xx_pinmux {
+ nand_flash_x16: nand_flash_x16 {
+ pinctrl-single,pins =
+ 0x00 (MUX_MODE0 | PIN_INPUT)/* gpmc_ad0.gpmc_ad0 */
+ 0x04 (MUX_MODE0 | PIN_INPUT)/* gpmc_ad1.gpmc_ad1 */
+ 0x08 (MUX_MODE0 | PIN_INPUT)/* gpmc_ad2.gpmc_ad2 */
+ 0x0c (MUX_MODE0 | PIN_INPUT)/* gpmc_ad3.gpmc_ad3 */
+ 0x10 (MUX_MODE0 | PIN_INPUT)/* gpmc_ad4.gpmc_ad4 */
+ 0x14 (MUX_MODE0 | PIN_INPUT)/* gpmc_ad5.gpmc_ad5 */
+ 0x18 (MUX_MODE0 | PIN_INPUT)/* gpmc_ad6.gpmc_ad6 */
+ 0x1c (MUX_MODE0 | PIN_INPUT)/* gpmc_ad7.gpmc_ad7 */
+ 0x20 (MUX_MODE0 | PIN_INPUT)/* gpmc_ad8.gpmc_ad8 */
+ 0x24 (MUX_MODE0 | PIN_INPUT)/* gpmc_ad9.gpmc_ad9 */
+ 0x28 (MUX_MODE0 | PIN_INPUT)/* gpmc_ad10.gpmc_ad10
*/
+ 0x2c (MUX_MODE0 | PIN_INPUT)/* gpmc_ad11.gpmc_ad11
*/
+ 0x30 (MUX_MODE0 | PIN_INPUT)/* gpmc_ad12.gpmc_ad12
*/
+ 0x34 (MUX_MODE0 | PIN_INPUT)/* gpmc_ad13.gpmc_ad13
*/
+ 0x38 (MUX_MODE0 | PIN_INPUT)/* gpmc_ad14.gpmc_ad14
*/
+ 0x3c (MUX_MODE0 | PIN_INPUT)/* gpmc_ad15.gpmc_ad15
*/
+ 0x70 (MUX_MODE0 | PIN_INPUT_PULLUP )/*
gpmc_wait0.gpmc_wait0 */
+ 0x74 (MUX_MODE7 | PIN_OUTPUT_PULLUP)/*
gpmc_wpn.gpio0_30 */
+ 0x7c (MUX_MODE0 | PIN_OUTPUT_PULLUP)/*
gpmc_csn0.gpmc_csn0 */
+ 0x90 (MUX_MODE0 | PIN_OUTPUT) /*
gpmc_advn_ale.gpmc_advn_ale */
+ 0x94 (MUX_MODE0 | PIN_OUTPUT) /*
gpmc_oen_ren.gpmc_oen_ren */
+ 0x98 (MUX_MODE0 | PIN_OUTPUT) /*
gpmc_wen.gpmc_wen */
+ 0x9c (MUX_MODE0 | PIN_OUTPUT) /*
gpmc_be0n_cle.gpmc_be0n_cle */
+ ;
+ };
+};
+
ldo3_reg {
regulator-min-microvolt = 180;
regulator-max-microvolt = 330;
@@ -27,3 +57,96 @@
aes {
status = okay;
};
+
+/*
+ * uncomment following to enable NAND cape support
+ * mmc2 {
+ * status = disabled;
+ * };
+ * elm {
+ * status = okay;
+ * };
+ * gpmc {
+ * status = okay;
+ * };
+ */
Re: [PATCH 2/4] power_supply: Introduce generic psy charging driver
On Fri, Mar 7, 2014 at 9:10 PM, Pavel Machek pa...@ucw.cz wrote: On Fri 2014-03-07 11:04:59, Linus Walleij wrote: On Fri, Feb 28, 2014 at 6:01 PM, Pavel Machek pa...@ucw.cz wrote: On Thu 2014-02-27 21:08:01, Linus Walleij wrote: On Thu, Feb 20, 2014 at 6:53 AM, Jenny TC jenny...@intel.com wrote: +++ b/include/linux/power/power_supply_charger.h +#define MAX_CUR_VOLT_SAMPLES 3 +#define DEF_CUR_VOLT_SAMPLE_JIFF (30*HZ) Why are things defined in Jiffies like this insead of seconds, milliseconds etc? This will vary with the current operating frequency of the system, why should physical measurements do that? It is actually ok. The define is relative to jiffies, and that's what interface expects. So consider the option that the interface is wrong. Stating something like a sample period in system-specific jiffies instead of period time T is just weird. What control systems guy would understand this? 30*HZ means 30 seconds in the kernel... what is hard to understand about it? Well I might be picky, but since it is a charging algorithm dealing with ampères, volts, constant-current/constant-voltage, watchdogs and timeouts, all stated in SI units, it would be nice if all such constants were specified in simple units instead of kernel-specific terms. One reason is that this kind of code actually needs review from non-programmers, people like chemists and physicists. I know it may be far fetched so no strong preference for sure. Yours, Linus Walleij -- To unsubscribe from this list: send the line unsubscribe 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 v1 3/3] ARM: dts: am437x-gp-evm: add support for parallel NAND flash
On 03/12/2014 05:49 AM, Pekon Gupta wrote:
Adds pinmux and DT node for Micron (MT29F4G08AB) x8 NAND device present on
am437x-gp-evm board.
(1) As NAND Flash data lines are muxed with eMMC, Thus at a given time either
eMMC or NAND can be enabled. Selection between eMMC and NAND is
controlled:
(a) By dynamically driving following GPIO pin from software
SPI2_CS0(GPIO) == 0 NAND is selected (default)
SPI2_CS0(GPIO) == 1 eMMC is selected
(b) By statically using Jumper (J89) on the board
(2) As NAND device connnected to this board has page-size=4K and oob-size=224,
So ROM code expects boot-loaders to be flashed in BCH16 ECC scheme for
NAND boot.
Signed-off-by: Pekon Gupta pe...@ti.com
---
arch/arm/boot/dts/am437x-gp-evm.dts | 107
1 file changed, 107 insertions(+)
diff --git a/arch/arm/boot/dts/am437x-gp-evm.dts
b/arch/arm/boot/dts/am437x-gp-evm.dts
index df8798e..0027ea7 100644
--- a/arch/arm/boot/dts/am437x-gp-evm.dts
+++ b/arch/arm/boot/dts/am437x-gp-evm.dts
which branch does this apply on? I assume you mean this for Tony's
omap-for-v3.15/dt branch? it would be nice if you'd make that clear in
cover letter.
@@ -81,6 +81,27 @@
0x164 MUX_MODE0 /*
eCAP0_in_PWM0_out.eCAP0_in_PWM0_out MODE0 */
;
};
+
+ nand_flash_x8: nand_flash_x8 {
+ pinctrl-single,pins =
+ 0x26C(PIN_OUTPUT_PULLDOWN | MUX_MODE7) /*
spi2_cs0.gpio/eMMCorNANDsel */
+ 0x0 (PIN_INPUT | MUX_MODE0) /* gpmc_ad0.gpmc_ad0 */
+ 0x4 (PIN_INPUT | MUX_MODE0) /* gpmc_ad1.gpmc_ad1 */
+ 0x8 (PIN_INPUT | MUX_MODE0) /* gpmc_ad2.gpmc_ad2 */
+ 0xc (PIN_INPUT | MUX_MODE0) /* gpmc_ad3.gpmc_ad3 */
+ 0x10 (PIN_INPUT | MUX_MODE0) /* gpmc_ad4.gpmc_ad4 */
+ 0x14 (PIN_INPUT | MUX_MODE0) /* gpmc_ad5.gpmc_ad5 */
+ 0x18 (PIN_INPUT | MUX_MODE0) /* gpmc_ad6.gpmc_ad6 */
+ 0x1c (PIN_INPUT | MUX_MODE0) /* gpmc_ad7.gpmc_ad7 */
+ 0x70 (PIN_INPUT_PULLUP | MUX_MODE0) /*
gpmc_wait0.gpmc_wait0 */
+ 0x74 (PIN_OUTPUT_PULLUP | MUX_MODE7)/*
gpmc_wpn.gpmc_wpn */
+ 0x7c (PIN_OUTPUT | MUX_MODE0) /*
gpmc_csn0.gpmc_csn0 */
+ 0x90 (PIN_OUTPUT | MUX_MODE0) /*
gpmc_advn_ale.gpmc_advn_ale */
+ 0x94 (PIN_OUTPUT | MUX_MODE0) /*
gpmc_oen_ren.gpmc_oen_ren */
+ 0x98 (PIN_OUTPUT | MUX_MODE0) /*
gpmc_wen.gpmc_wen */
+ 0x9c (PIN_OUTPUT | MUX_MODE0) /*
gpmc_be0n_cle.gpmc_be0n_cle */
+ ;
+ };
};
i2c0 {
@@ -125,3 +146,89 @@
pinctrl-0 = mmc1_pins;
cd-gpios = gpio0 6 GPIO_ACTIVE_HIGH;
};
+
+elm {
+ status = okay;
+};
+
+gpmc {
+ status = okay;
+ pinctrl-names = default;
+ pinctrl-0 = nand_flash_x8;
+ ranges = 0 0 0x0800 0x1000; /* CS0: NAND */
+ nand@0,0 {
+ reg = 0 0 0; /* CS0, offset 0 */
+ ti,nand-ecc-opt = bch8;
+ ti,elm-id = elm;
+ nand-bus-width = 8;
+ gpmc,device-width = 1;
+ gpmc,sync-clk-ps = 0;
+ gpmc,cs-on-ns = 0;
+ gpmc,cs-rd-off-ns = 40;
+ gpmc,cs-wr-off-ns = 40;
+ gpmc,adv-on-ns = 0;
+ gpmc,adv-rd-off-ns = 25;
+ gpmc,adv-wr-off-ns = 25;
+ gpmc,we-on-ns = 0;
+ gpmc,we-off-ns = 20;
+ gpmc,oe-on-ns = 3;
+ gpmc,oe-off-ns = 30;
+ gpmc,access-ns = 30;
+ gpmc,rd-cycle-ns = 40;
+ gpmc,wr-cycle-ns = 40;
+ gpmc,wait-on-read = true;
+ gpmc,wait-on-write = true;
+ gpmc,bus-turnaround-ns = 0;
+ gpmc,cycle2cycle-delay-ns = 0;
+ gpmc,clk-activation-ns = 0;
+ gpmc,wait-monitoring-ns = 0;
+ gpmc,wr-access-ns = 40;
+ gpmc,wr-data-mux-bus-ns = 0;
+ /* MTD partition table */
+ /* All SPL-* partitions are sized to minimal length
+ * which can be independently programmable. For
+ * NAND flash this is equal to size of erase-block */
+ #address-cells = 1;
+ #size-cells = 1;
+ partition@0 {
+ label = NAND.SPL;
+ reg = 0x 0x0004;
+ };
+ partition@1 {
+ label = NAND.SPL.backup1;
+ reg = 0x0004 0x0004;
+ };
+ partition@2 {
+ label = NAND.SPL.backup2;
+ reg = 0x0008 0x0004;
+ };
+
Re: [PATCHv8 2/4] power_supply: Introduce generic psy charging driver
On Fri, Mar 7, 2014 at 6:29 AM, Jenny TC jenny...@intel.com wrote:
+enum psy_charger_cable_type {
+ PSY_CHARGER_CABLE_TYPE_NONE = 0,
+ PSY_CHARGER_CABLE_TYPE_USB_SDP = 1 0,
+ PSY_CHARGER_CABLE_TYPE_USB_DCP = 1 1,
+ PSY_CHARGER_CABLE_TYPE_USB_CDP = 1 2,
+ PSY_CHARGER_CABLE_TYPE_USB_ACA = 1 3,
+ PSY_CHARGER_CABLE_TYPE_AC = 1 4,
+ PSY_CHARGER_CABLE_TYPE_ACA_DOCK = 1 5,
+ PSY_CHARGER_CABLE_TYPE_ACA_A = 1 6,
+ PSY_CHARGER_CABLE_TYPE_ACA_B = 1 7,
+ PSY_CHARGER_CABLE_TYPE_ACA_C = 1 8,
+ PSY_CHARGER_CABLE_TYPE_SE1 = 1 9,
+ PSY_CHARGER_CABLE_TYPE_MHL = 1 10,
+ PSY_CHARGER_CABLE_TYPE_B_DEVICE = 1 11,
+};
I still disagree with using an enum as bitfield.
Atleast
#include linux/bitops.h
and use BIT(0), BIT(1) etc to define the bits.
Yours,
Linus Walleij
--
To unsubscribe from this list: send the line unsubscribe 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 02/10] ARM: OMAP3: fix iva mmu programming issues
On Wed, 5 Mar 2014, Suman Anna wrote: The IVA MMU is not functional when used through the hwmod and omap_device layers. Add fixes to clockdomain and hwmod data to have it functional. The hwmod changes are needed to enable the clock, and the SWSUP change is needed to wakeup the domain because the power domain is programmed to be in RET, and there is no automatic power domain switching to ON. Cc: Paul Walmsley p...@pwsan.com Signed-off-by: Suman Anna s-a...@ti.com Acked-by: Paul Walmsley p...@pwsan.com - 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 05/10] ARM: OMAP5: hwmod data: add mmu data for ipu dsp
On Wed, 5 Mar 2014, Suman Anna wrote: A new MMU hwmod class and data structures are created to represent the MMUs within the IPU and DSP processor subsystems in OMAP5. The MMUs in OMAP5 are identical to those in OMAP4. Cc: Paul Walmsley p...@pwsan.com Cc: Benoit Cousson bcous...@baylibre.com Signed-off-by: Suman Anna s-a...@ti.com Acked-by: Paul Walmsley p...@pwsan.com - 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: [RFC/PATCH] base: platform: add generic clock handling for platform-bus
Hi Felipe,
(CC'ing Geert Uytterhoeven as we happen to discuss runtime PM and clock
handling for the Renesas SoCs at the moment)
Thank you for the patch. This is a bit of a late reply, but that's better than
no reply I suppose. Please see below for a small comment.
On Friday 31 January 2014 12:12:45 Felipe Balbi wrote:
Still TODO a commit log. Not for merging!
NYET-Signed-off-by: Felipe Balbi ba...@ti.com
---
This patch is an idea I've had recently in order to combine several
different PM implementations into the platform-bus.
This patch is bare minimum for platforms which need to handle functional and
interface clocks but the whole thing is made optional.
Note that this patch makes sure that by the time a platform_driver's probe
is called, we already have clocks enabled and pm_runtime_set_active() has
been called, thus making sure that a device driver's pm_runtime_get_sync()
will solely increase the pm usage counter.
I have *NOT* tested this anywhere *YET*, but I suppose it shouldn't cause
any issues since the clock API has ref counting too.
Would really like to get some review from several folks involved with ARM
SoC PM so that's the reason for the wide audience. If I have missed
anybody, please add them to Cc.
As mentioned above, this is *NOT* meant for merging, but serves as a
starting point for discussing some convergence of several PM domain
implementations on different arch/arm/mach-* directories.
For OMAP, this has the added benefit of removing clock handling from
omap_device/omap_hwmod and, thus, dropping the need for so many DT_CLK()
tables under drivers/clk/ti/
drivers/base/platform.c | 169 +++--
include/linux/platform_device.h | 9 +++
2 files changed, 173 insertions(+), 5 deletions(-)
diff --git a/drivers/base/platform.c b/drivers/base/platform.c
index 3a94b79..86aeb5b 100644
--- a/drivers/base/platform.c
+++ b/drivers/base/platform.c
@@ -484,6 +484,21 @@ static int platform_drv_probe(struct device *_dev)
if (ACPI_HANDLE(_dev))
acpi_dev_pm_attach(_dev, true);
+ dev-fck = devm_clk_get(_dev, fck);
+ dev-ick = devm_clk_get(_dev, ick);
My concern with this that some devices might want to handle their functional
and interface clocks manually if they have exotic requirements. They would
thus need a way to signal that the platform bus core should not try to perform
clock management on its own.
One possible way would be to name the clocks differently for those devices,
but we might then have a backward compatibility issue with DT.
Another concern is how to handle the DT backward compatibility for devices
that would benefit from core management of their functional and interface
clocks, but that currently don't name those clocks fck and ick. Renaming
those clocks in DT wouldn't be a problem for the future, but backward
compatibility needs to be handled. Maybe platforms could provide aliases in
that case.
+ if (!IS_ERR(dev-fck))
+ clk_prepare_enable(dev-fck);
+ else
+ dev-fck = NULL;
+
+ if (!IS_ERR(dev-ick))
+ clk_prepare_enable(dev-ick);
+ else
+ dev-ick = NULL;
+
+ pm_runtime_set_active(_dev);
+
ret = drv-probe(dev);
if (ret ACPI_HANDLE(_dev))
acpi_dev_pm_detach(_dev, true);
@@ -507,6 +522,14 @@ static int platform_drv_remove(struct device *_dev)
struct platform_device *dev = to_platform_device(_dev);
int ret;
+ if (!IS_ERR(dev-ick))
+ clk_disable_unprepare(dev-ick);
+
+ if (!IS_ERR(dev-fck))
+ clk_disable_unprepare(dev-fck);
+
+ pm_runtime_set_suspended(_dev);
+
ret = drv-remove(dev);
if (ACPI_HANDLE(_dev))
acpi_dev_pm_detach(_dev, true);
@@ -780,6 +803,59 @@ static int platform_legacy_resume(struct device *dev)
#endif /* CONFIG_PM_SLEEP */
+#ifdef CONFIG_PM_RUNTIME
+int platform_pm_runtime_suspend(struct device *dev)
+{
+ struct device_driver *drv = dev-driver;
+ struct platform_driver *pdrv = to_platform_driver(drv);
+ struct platform_device *pdev = to_platform_device(dev);
+ int ret;
+
+ ret = pm_generic_runtime_suspend(dev);
+ if (ret)
+ return ret;
+
+ if (!test_bit(PLATFORM_PM_RUNTIME_KEEP_ICK, pdrv-flags))
+ clk_disable(pdev-ick);
+
+ if (!test_bit(PLATFORM_PM_RUNTIME_KEEP_FCK, pdrv-flags))
+ clk_disable(pdev-fck);
+
+ return ret;
+}
+
+int platform_pm_runtime_resume(struct device *dev)
+{
+ struct device_driver *drv = dev-driver;
+ struct platform_driver *pdrv = to_platform_driver(drv);
+ struct platform_device *pdev = to_platform_device(dev);
+ int ret;
+
+ if (!test_bit(PLATFORM_PM_RUNTIME_KEEP_ICK, pdrv-flags)) {
+ ret = clk_enable(pdev-ick);
+ if (ret)
+ return ret;
+
Re: [PATCH 00/10] arch/arm OMAP IOMMU patches for 3.15
* Suman Anna s-a...@ti.com [140311 14:52]: Hi Paul, On 03/05/2014 06:24 PM, Suman Anna wrote: Hi Paul, Benoit, This is a repost as per Tony's request [3] of all the OMAP IOMMU DT support patches that are under arch/arm. The series just assimilates patches 8 through 13 from the v3 OMAP IOMMU DT adaptation for 3.15 series [1], and all the v2 patches from the OMAP IOMMU DTS nodes [2]. The only change made with respect to the patches above is in the OMAP4 and OMAP5 DTS nodes - I have adjusted the reg sizes from 0xff to 0x100. Can you please provide your acks on the hwmod patches and DTS patches? Ping. Can you review and provide your acks for Patches 2 and 5 (the hwmod patches) for Tony to pick up all the patches in the series? Applied all with Paul's acks into omap-for-v3.15/dt. As it's getting so late to the merge window, no guarantees it will actually get pulled. For the pdata-quirks.c changes, I assume you are working on implementing the reset driver mentioned in the related patch? Regards, Tony -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v4 5/9] ARM: dts: omap3-overo: Add HSUSB PHY
* Roger Quadros rog...@ti.com [140311 02:46]: Any sane design would maintain register offsets but it doesn't seem so with omap34xx vs omap36xx. So my assumption was wrong. I'll ack this patch. OK thanks, I'll apply the whole series with your ack to omap-for-v3.15/dt-overo. 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 00/10] arch/arm OMAP IOMMU patches for 3.15
On 03/12/2014 12:04 PM, Tony Lindgren wrote: * Suman Anna s-a...@ti.com [140311 14:52]: Hi Paul, On 03/05/2014 06:24 PM, Suman Anna wrote: Hi Paul, Benoit, This is a repost as per Tony's request [3] of all the OMAP IOMMU DT support patches that are under arch/arm. The series just assimilates patches 8 through 13 from the v3 OMAP IOMMU DT adaptation for 3.15 series [1], and all the v2 patches from the OMAP IOMMU DTS nodes [2]. The only change made with respect to the patches above is in the OMAP4 and OMAP5 DTS nodes - I have adjusted the reg sizes from 0xff to 0x100. Can you please provide your acks on the hwmod patches and DTS patches? Ping. Can you review and provide your acks for Patches 2 and 5 (the hwmod patches) for Tony to pick up all the patches in the series? Applied all with Paul's acks into omap-for-v3.15/dt. As it's getting so late to the merge window, no guarantees it will actually get pulled. Thanks Tony. For the pdata-quirks.c changes, I assume you are working on implementing the reset driver mentioned in the related patch? Dan Murphy is currently working on this, and there is still some work to be done before it can be posted to the lists. regards Suman -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/7] ARM: dts: overo: Add new expansion boards
* Florian Vaussard florian.vauss...@epfl.ch [140311 05:24]: Hi, This series adds the support for 5 new expansion boards from Gumstix: - Palo43 - Gallop43 - Chestnut43 - Alto35 - Summit The 1st patch is a preparatory work, in order to factorize some peripherals that are common to most Gumstix expansion boards. Patch 2 adds the support for an accelerometer that is present on most boards. Palo43, Gallop43 and Chestnut43 are all pretty similar. I tested on a Gallop43 (with both OMAP35xx and OMAP36xx Overo). Alto35 is slightly different. Again, I tested with both OMAP35xx and OMAP36xx Overo. Summit is pretty similar to Tobi. I do not have a Summit at hand, but given the similarity with Tobi, it should work fine. To avoid unnecessary duplications, I put all the common stuff for each board inside an omap3-overo-xxx-common.dsti include file. By doing so, I can have minimal SoC-specific omap3-overo-xxx.dts (omap34xx based) and omap3-overo-storm-xxx.dts (omap36xx based) device trees. This series depends on my previous Overo series [1]. A complete testing tree (including the graphics support, soon to be posted) is available at [2]. Thanks, applying the whole series into omap-for-v3.15/dt-overo. As it's this close to the merge window, no guarantees anything will get pulled in though. Regards, Tony [1] http://thread.gmane.org/gmane.linux.ports.arm.omap/111558 [2] https://github.com/vaussard/linux.git (overo/for-3.15/review1) -- To unsubscribe from this list: send the line unsubscribe 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 5/5] drivers: bus: omap_l3: Change pr_crit() to dev_err() when IRQ request fails
* Peter Ujfalusi peter.ujfal...@ti.com [140304 23:14]:
On 03/04/2014 04:37 PM, Santosh Shilimkar wrote:
On Tuesday 04 March 2014 08:48 PM, Peter Ujfalusi wrote:
Use dev_err() which will going to print the driver's name as well and the
KERN_ERR level is sufficient in this case (we also print via dev_err when
there is an error with the mem resources)
Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
Reviewed-by: Santosh Shilimkar santosh.shilim...@ti.com
---
drivers/bus/omap_l3_noc.c | 7 +++
1 file changed, 3 insertions(+), 4 deletions(-)
diff --git a/drivers/bus/omap_l3_noc.c b/drivers/bus/omap_l3_noc.c
index 0eff48585ae3..972691a668a3 100644
--- a/drivers/bus/omap_l3_noc.c
+++ b/drivers/bus/omap_l3_noc.c
@@ -158,8 +158,8 @@ static int omap4_l3_probe(struct platform_device *pdev)
ret = devm_request_irq(pdev-dev, l3-debug_irq, l3_interrupt_handler,
IRQF_DISABLED, l3-dbg-irq, l3);
if (ret) {
- pr_crit(L3: request_irq failed to register for 0x%x\n,
- l3-debug_irq);
+ dev_err(pdev-dev, request_irq failed for %d\n,
+ l3-debug_irq);
return ret;
}
@@ -167,8 +167,7 @@ static int omap4_l3_probe(struct platform_device *pdev)
ret = devm_request_irq(pdev-dev, l3-app_irq, l3_interrupt_handler,
IRQF_DISABLED, l3-app-irq, l3);
if (ret)
- pr_crit(L3: request_irq failed to register for 0x%x\n,
- l3-app_irq);
+ dev_err(pdev-dev, request_irq failed for %d\n, l3-app_irq);
return ret;
}
So this one change in the log level. If I look at now, may be dev_err
is fine but the change is not same.
Not sure what you mean by 'the change is not same'?
I just picked the old series and rebased it on linux-next, the patch is the
same as it was back in May 2013:
https://lkml.org/lkml/2013/5/2/205
And yes, I have shortened the texts in the print, but the meaning of the
prints have not changed.
Santosh, got any more comments on this series?
Regards,
Tony
Apart from above comment, rest of the series looks fine to me.
Feel free to add my ack...
Thanks.
--
Péter
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 00/10] arch/arm OMAP IOMMU patches for 3.15
* Suman Anna s-a...@ti.com [140312 10:25]: On 03/12/2014 12:04 PM, Tony Lindgren wrote: For the pdata-quirks.c changes, I assume you are working on implementing the reset driver mentioned in the related patch? Dan Murphy is currently working on this, and there is still some work to be done before it can be posted to the lists. OK thanks for the update, good to hear. 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: [PATCHv3 1/2] arm: dts: dra7: Add qspi device.
* Sourav Poddar sourav.pod...@ti.com [140310 04:54]: These add device tree entry for qspi controller driver on dra7-evm. It seems that we need to wait for the crossbar dependencies to get cleared in the mainline kernel before we can apply this as otherwise the interrupts will be wrong in omap-for-v3.15/dt 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: [PATCH] dma: omap-dma: Implement device_slave_caps callback
* Peter Ujfalusi peter.ujfal...@ti.com [140307 05:39]:
With the callback implemented omap-dma can provide information to client
drivers regarding to supported address widths, directions, residue
granularity, etc.
This may need some testing against linux next with Russell's
omap-dma.c clean-up series merged there. Peter, care to check
if this patch is still valid against linux next?
Regards,
Tony
Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
---
drivers/dma/omap-dma.c | 18 ++
1 file changed, 18 insertions(+)
diff --git a/drivers/dma/omap-dma.c b/drivers/dma/omap-dma.c
index 64ceca2920b8..b19f04f4390b 100644
--- a/drivers/dma/omap-dma.c
+++ b/drivers/dma/omap-dma.c
@@ -1088,6 +1088,23 @@ static void omap_dma_free(struct omap_dmadev *od)
}
}
+#define OMAP_DMA_BUSWIDTHS (BIT(DMA_SLAVE_BUSWIDTH_1_BYTE) | \
+ BIT(DMA_SLAVE_BUSWIDTH_2_BYTES) | \
+ BIT(DMA_SLAVE_BUSWIDTH_4_BYTES))
+
+static int omap_dma_device_slave_caps(struct dma_chan *dchan,
+ struct dma_slave_caps *caps)
+{
+ caps-src_addr_widths = OMAP_DMA_BUSWIDTHS;
+ caps-dstn_addr_widths = OMAP_DMA_BUSWIDTHS;
+ caps-directions = BIT(DMA_DEV_TO_MEM) | BIT(DMA_MEM_TO_DEV);
+ caps-cmd_pause = true;
+ caps-cmd_terminate = true;
+ caps-residue_granularity = DMA_RESIDUE_GRANULARITY_BURST;
+
+ return 0;
+}
+
static int omap_dma_probe(struct platform_device *pdev)
{
struct omap_dmadev *od;
@@ -1118,6 +1135,7 @@ static int omap_dma_probe(struct platform_device *pdev)
od-ddev.device_prep_slave_sg = omap_dma_prep_slave_sg;
od-ddev.device_prep_dma_cyclic = omap_dma_prep_dma_cyclic;
od-ddev.device_control = omap_dma_control;
+ od-ddev.device_slave_caps = omap_dma_device_slave_caps;
od-ddev.dev = pdev-dev;
INIT_LIST_HEAD(od-ddev.channels);
INIT_LIST_HEAD(od-pending);
--
1.9.0
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: dts: am335x-evmsk: enable DMA controller for USB
* yegorsli...@googlemail.com yegorsli...@googlemail.com [140310 08:30]:
From: Yegor Yefremov yegorsli...@googlemail.com
Signed-off-by: Yegor Yefremov yegorsli...@googlemail.com
---
arch/arm/boot/dts/am335x-evmsk.dts |4
1 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/arch/arm/boot/dts/am335x-evmsk.dts
b/arch/arm/boot/dts/am335x-evmsk.dts
index fa19271..ec08f6f 100644
--- a/arch/arm/boot/dts/am335x-evmsk.dts
+++ b/arch/arm/boot/dts/am335x-evmsk.dts
@@ -384,6 +384,10 @@
status = okay;
dr_mode = host;
};
+
+ dma-controller@07402000 {
+ status = okay;
+ };
};
epwmss2 {
Thanks applying into omap-for-v.15/dt with the subject line as
the description also. No guarantees this will get merged as we're
so close to the merge window already.
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: cm-t3530: Add MMC2/SDIO/WLAN support
* Stefan Roese s...@denx.de [140312 03:52]:
Add support for the MMC2/SDIO WiFi Libertas (Marvell) module available
on the CM-T3530 SOM.
Signed-off-by: Stefan Roese s...@denx.de
Cc: Dmitry Lifshitz lifsh...@compulab.co.il
Cc: Igor Grinberg grinb...@compulab.co.il
Cc: Tony Lindgren t...@atomide.com
---
This patch is based on current mainline (v3.14-rc6) plus this compulab patch
series from Dmitry:
[PATCH 00/11] ARM: dts: sbc-t3x: add support for more boards
http://www.spinics.net/lists/arm-kernel/msg300078.html
Thanks applying into omap-for-v3.15/dt, no guarantees it gets merged though
as it's getting so close to the merge window.
Regards,
Tony
arch/arm/boot/dts/omap3-cm-t3530.dts | 36
1 file changed, 36 insertions(+)
diff --git a/arch/arm/boot/dts/omap3-cm-t3530.dts
b/arch/arm/boot/dts/omap3-cm-t3530.dts
index 9faf1cd..d145849 100644
--- a/arch/arm/boot/dts/omap3-cm-t3530.dts
+++ b/arch/arm/boot/dts/omap3-cm-t3530.dts
@@ -9,4 +9,40 @@
/ {
model = CompuLab CM-T3530;
compatible = compulab,omap3-cm-t3530, ti,omap34xx, ti,omap3;
+
+ /* Regulator to trigger the reset signal of the Wifi module */
+ mmc2_sdio_reset: regulator-mmc2-sdio-reset {
+ compatible = regulator-fixed;
+ regulator-name = regulator-mmc2-sdio-reset;
+ regulator-min-microvolt = 330;
+ regulator-max-microvolt = 330;
+ gpio = twl_gpio 2 GPIO_ACTIVE_HIGH;
+ enable-active-high;
+ };
+};
+
+omap3_pmx_core {
+ mmc2_pins: pinmux_mmc2_pins {
+ pinctrl-single,pins =
+ OMAP3_CORE1_IOPAD(0x2158, PIN_INPUT_PULLUP | MUX_MODE0)
/* sdmmc2_clk.sdmmc2_clk */
+ OMAP3_CORE1_IOPAD(0x215a, PIN_INPUT_PULLUP | MUX_MODE0)
/* sdmmc2_cmd.sdmmc2_cmd */
+ OMAP3_CORE1_IOPAD(0x215c, PIN_INPUT_PULLUP | MUX_MODE0)
/* sdmmc2_dat0.sdmmc2_dat0 */
+ OMAP3_CORE1_IOPAD(0x215e, PIN_INPUT_PULLUP | MUX_MODE0)
/* sdmmc2_dat1.sdmmc2_dat1 */
+ OMAP3_CORE1_IOPAD(0x2160, PIN_INPUT_PULLUP | MUX_MODE0)
/* sdmmc2_dat2.sdmmc2_dat2 */
+ OMAP3_CORE1_IOPAD(0x2162, PIN_INPUT_PULLUP | MUX_MODE0)
/* sdmmc2_dat3.sdmmc2_dat3 */
+ OMAP3_CORE1_IOPAD(0x2164, PIN_OUTPUT | MUX_MODE1)
/* sdmmc2_dat4.sdmmc2_dir_dat0 */
+ OMAP3_CORE1_IOPAD(0x2166, PIN_OUTPUT | MUX_MODE1)
/* sdmmc2_dat5.sdmmc2_dir_dat1 */
+ OMAP3_CORE1_IOPAD(0x2168, PIN_OUTPUT | MUX_MODE1)
/* sdmmc2_dat6.sdmmc2_dir_cmd */
+ OMAP3_CORE1_IOPAD(0x216a, PIN_INPUT | MUX_MODE1)
/* sdmmc2_dat7.sdmmc2_clkin */
+ ;
+ };
+};
+
+mmc2 {
+ pinctrl-names = default;
+ pinctrl-0 = mmc2_pins;
+ vmmc-supply = mmc2_sdio_reset;
+ non-removable;
+ bus-width = 4;
+ cap-power-off-card;
};
--
1.8.5.5
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 5/8] ARM: OMAP5: hwmod: Add ocp2scp3 and sata hwmods
* Roger Quadros rog...@ti.com [140307 02:18]:
From: Keshava Munegowda keshava_mgo...@ti.com
Create hwmods for ocp2scp3 and sata modules.
Paul, does this look OK to you?
Regards,
Tony
[Roger Q] Clean up.
CC: Benoit Cousson bcous...@baylibre.com
CC: Paul Walmsley p...@pwsan.com
CC: Tony Lindgren t...@atomide.com
Signed-off-by: Balaji T K balaj...@ti.com
Signed-off-by: Roger Quadros rog...@ti.com
---
arch/arm/mach-omap2/omap_hwmod_54xx_data.c | 73
++
1 file changed, 73 insertions(+)
diff --git a/arch/arm/mach-omap2/omap_hwmod_54xx_data.c
b/arch/arm/mach-omap2/omap_hwmod_54xx_data.c
index e297d62..227a69f 100644
--- a/arch/arm/mach-omap2/omap_hwmod_54xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_54xx_data.c
@@ -1726,6 +1726,77 @@ static struct omap_hwmod omap54xx_wd_timer2_hwmod = {
},
};
+/*
+ * 'ocp2scp' class
+ * bridge to transform ocp interface protocol to scp (serial control port)
+ * protocol
+ */
+/* ocp2scp3 */
+static struct omap_hwmod omap54xx_ocp2scp3_hwmod;
+/* l4_cfg - ocp2scp3 */
+static struct omap_hwmod_ocp_if omap54xx_l4_cfg__ocp2scp3 = {
+ .master = omap54xx_l4_cfg_hwmod,
+ .slave = omap54xx_ocp2scp3_hwmod,
+ .clk= l4_root_clk_div,
+ .user = OCP_USER_MPU | OCP_USER_SDMA,
+};
+
+static struct omap_hwmod omap54xx_ocp2scp3_hwmod = {
+ .name = ocp2scp3,
+ .class = omap54xx_ocp2scp_hwmod_class,
+ .clkdm_name = l3init_clkdm,
+ .prcm = {
+ .omap4 = {
+ .clkctrl_offs =
OMAP54XX_CM_L3INIT_OCP2SCP3_CLKCTRL_OFFSET,
+ .context_offs =
OMAP54XX_RM_L3INIT_OCP2SCP3_CONTEXT_OFFSET,
+ .modulemode = MODULEMODE_HWCTRL,
+ },
+ },
+};
+
+/*
+ * 'sata' class
+ * sata: serial ata interface gen2 compliant ( 1 rx/ 1 tx)
+ */
+
+static struct omap_hwmod_class_sysconfig omap54xx_sata_sysc = {
+ .sysc_offs = 0x,
+ .sysc_flags = (SYSC_HAS_MIDLEMODE | SYSC_HAS_SIDLEMODE),
+ .idlemodes = (SIDLE_FORCE | SIDLE_NO | SIDLE_SMART |
+SIDLE_SMART_WKUP | MSTANDBY_FORCE | MSTANDBY_NO |
+MSTANDBY_SMART | MSTANDBY_SMART_WKUP),
+ .sysc_fields= omap_hwmod_sysc_type2,
+};
+
+static struct omap_hwmod_class omap54xx_sata_hwmod_class = {
+ .name = sata,
+ .sysc = omap54xx_sata_sysc,
+};
+
+/* sata */
+static struct omap_hwmod omap54xx_sata_hwmod = {
+ .name = sata,
+ .class = omap54xx_sata_hwmod_class,
+ .clkdm_name = l3init_clkdm,
+ .flags = HWMOD_SWSUP_SIDLE | HWMOD_SWSUP_MSTANDBY,
+ .main_clk = func_48m_fclk,
+ .mpu_rt_idx = 1,
+ .prcm = {
+ .omap4 = {
+ .clkctrl_offs = OMAP54XX_CM_L3INIT_SATA_CLKCTRL_OFFSET,
+ .context_offs = OMAP54XX_RM_L3INIT_SATA_CONTEXT_OFFSET,
+ .modulemode = MODULEMODE_SWCTRL,
+ },
+ },
+};
+
+/* l4_cfg - sata */
+static struct omap_hwmod_ocp_if omap54xx_l4_cfg__sata = {
+ .master = omap54xx_l4_cfg_hwmod,
+ .slave = omap54xx_sata_hwmod,
+ .clk= l3_iclk_div,
+ .user = OCP_USER_MPU | OCP_USER_SDMA,
+};
/*
* Interfaces
@@ -2399,6 +2470,8 @@ static struct omap_hwmod_ocp_if
*omap54xx_hwmod_ocp_ifs[] __initdata = {
omap54xx_l4_cfg__usb_tll_hs,
omap54xx_l4_cfg__usb_otg_ss,
omap54xx_l4_wkup__wd_timer2,
+ omap54xx_l4_cfg__ocp2scp3,
+ omap54xx_l4_cfg__sata,
NULL,
};
--
1.8.3.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 v3 0/5] Add USB nodes for am43xx epos and gp evm
* George Cherian george.cher...@ti.com [140311 22:02]: Hi Tony, On 3/7/2014 5:26 PM, George Cherian wrote: The patch series adds USB dt nodes for am43xx epos and gp evm Boot tested with Benoit's for_3.15 + following patches https://patchwork.kernel.org/patch/3600821/ https://patchwork.kernel.org/patch/3600831/ https://patchwork.kernel.org/patch/3600851/ https://patchwork.kernel.org/patch/3600841/ Changes from v1 - v2 * Reorder doc: Add ti,am437x-dwc3 comaptible for dwc3 glue * Address v1 coments on ARM: dts: AM4372: Add USB nodes Changes from v2 - v3 * Removed unwanted dwc3_1 and dwc3_2 nodes from am437x-gp-evm.dts and am43x-epos-evm.dts George Cherian (5): doc: Add ti,am437x-dwc3 comaptible for dwc3 glue ARM: dts: am43xx clock data ARM: dts: AM4372: Add USB nodes ARM: dts: am437x-gp-evm: Enable USB ARM: dts: am43x-epos-evm: Enable USB Documentation/devicetree/bindings/usb/omap-usb.txt | 4 +- arch/arm/boot/dts/am4372.dtsi | 95 ++ arch/arm/boot/dts/am437x-gp-evm.dts| 18 arch/arm/boot/dts/am43x-epos-evm.dts | 18 arch/arm/boot/dts/am43xx-clocks.dtsi | 17 5 files changed, 151 insertions(+), 1 deletion(-) Can you please take this series. The whole series Reviewed-by: Roger Quadros rog...@ti.com Hmm I only see ack from Roger on patch 3? 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 v1 3/3] ARM: dts: am437x-gp-evm: add support for parallel NAND flash
From: Menon, Nishanth On 03/12/2014 05:49 AM, Pekon Gupta wrote: Adds pinmux and DT node for Micron (MT29F4G08AB) x8 NAND device present on am437x-gp-evm board. (1) As NAND Flash data lines are muxed with eMMC, Thus at a given time either eMMC or NAND can be enabled. Selection between eMMC and NAND is controlled: (a) By dynamically driving following GPIO pin from software SPI2_CS0(GPIO) == 0 NAND is selected (default) SPI2_CS0(GPIO) == 1 eMMC is selected (b) By statically using Jumper (J89) on the board (2) As NAND device connnected to this board has page-size=4K and oob-size=224, So ROM code expects boot-loaders to be flashed in BCH16 ECC scheme for NAND boot. Signed-off-by: Pekon Gupta pe...@ti.com --- arch/arm/boot/dts/am437x-gp-evm.dts | 107 1 file changed, 107 insertions(+) diff --git a/arch/arm/boot/dts/am437x-gp-evm.dts b/arch/arm/boot/dts/am437x-gp-evm.dts index df8798e..0027ea7 100644 --- a/arch/arm/boot/dts/am437x-gp-evm.dts +++ b/arch/arm/boot/dts/am437x-gp-evm.dts which branch does this apply on? I assume you mean this for Tony's omap-for-v3.15/dt branch? it would be nice if you'd make that clear in cover letter. Sorry, I missed that. I'll keep a note of this next time. Yes, this patch series is rebased on git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap omap-for-v3.15/dt 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 v1 1/3] ARM: dts: am335x-bone: add support for beaglebone NAND cape
Hi, From: Menon, Nishanth On 03/12/2014 05:49 AM, Pekon Gupta wrote: Beaglebone Board can be connected to expansion boards to add devices to them. These expansion boards are called 'capes'. This patch adds support for following versions of Beaglebone(AM335x) NAND capes (a) NAND Device with bus-width=16, block-size=128k, page-size=2k, oob-size=64 (b) NAND Device with bus-width=16, block-size=256k, page-size=4k, oob-size=224 Further information and datasheets can be found at [1] and [2] [...] [1] http://beagleboardtoys.info/index.php?title=BeagleBone_Memory_Expansion [2] http://beagleboardtoys.info/index.php?title=BeagleBone_4Gb_16-Bit_NAND_Module Signed-off-by: Pekon Gupta pe...@ti.com --- arch/arm/boot/dts/am335x-bone.dts | 123 ++ 1 file changed, 123 insertions(+) diff --git a/arch/arm/boot/dts/am335x-bone.dts b/arch/arm/boot/dts/am335x-bone.dts index 94ee427..be2c572 100644 --- a/arch/arm/boot/dts/am335x-bone.dts +++ b/arch/arm/boot/dts/am335x-bone.dts better to make a nand_cape dts which includes the am335x-bone.dts? Actually, I'm not in favor of having too many xx_board_common.dts files, because it un-necessarily complexes things. We already have arch/arm/boot/dts/am335x-bone-common.dtsi which just saves some lines common to DTS of both Beaglebone-LT(white) and Beaglebone-Black. And, there is no guarantee that Beaglebone-LT(white) will remain compatible to Beaglebone-black in future. Example: some capes are not compatible to beaglebone-black [1], [2]. So, I prefer to keep separate GPMC NAND nodes separately in both DTS, unless there is a strong convincing reason otherwise. [1] http://elinux.org/CircuitCo:BeagleBoardToys [2] http://elinux.org/BeagleBone_Black_Capes 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 v1 1/3] ARM: dts: am335x-bone: add support for beaglebone NAND cape
On Wed, Mar 12, 2014 at 1:26 PM, Gupta, Pekon pe...@ti.com wrote: Hi, From: Menon, Nishanth On 03/12/2014 05:49 AM, Pekon Gupta wrote: Beaglebone Board can be connected to expansion boards to add devices to them. These expansion boards are called 'capes'. This patch adds support for following versions of Beaglebone(AM335x) NAND capes (a) NAND Device with bus-width=16, block-size=128k, page-size=2k, oob-size=64 (b) NAND Device with bus-width=16, block-size=256k, page-size=4k, oob-size=224 Further information and datasheets can be found at [1] and [2] [...] [1] http://beagleboardtoys.info/index.php?title=BeagleBone_Memory_Expansion [2] http://beagleboardtoys.info/index.php?title=BeagleBone_4Gb_16-Bit_NAND_Module Signed-off-by: Pekon Gupta pe...@ti.com --- arch/arm/boot/dts/am335x-bone.dts | 123 ++ 1 file changed, 123 insertions(+) diff --git a/arch/arm/boot/dts/am335x-bone.dts b/arch/arm/boot/dts/am335x-bone.dts index 94ee427..be2c572 100644 --- a/arch/arm/boot/dts/am335x-bone.dts +++ b/arch/arm/boot/dts/am335x-bone.dts better to make a nand_cape dts which includes the am335x-bone.dts? Actually, I'm not in favor of having too many xx_board_common.dts files, because it un-necessarily complexes things. We already have arch/arm/boot/dts/am335x-bone-common.dtsi which just saves some lines common to DTS of both Beaglebone-LT(white) and Beaglebone-Black. And, there is no guarantee that Beaglebone-LT(white) will remain compatible to Beaglebone-black in future. Example: some capes are not compatible to beaglebone-black [1], [2]. So, I prefer to keep separate GPMC NAND nodes separately in both DTS, unless there is a strong convincing reason otherwise. [1] http://elinux.org/CircuitCo:BeagleBoardToys [2] http://elinux.org/BeagleBone_Black_Capes Right, and adding NAND, GPMC nodes and asking folks to uncomment sections into a generic board file (which by default has none) makes more sense? I dont use NAND capes or might create my own cape. overo has the same challenges as bone family has.I dont see asking folks to uncomment entries to use the cape is a nicer alternative to having more dts entries. Regards, Nishanth Menon -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v1 1/3] ARM: dts: am335x-bone: add support for beaglebone NAND cape
On Wed, Mar 12, 2014 at 1:57 PM, Nishanth Menon n...@ti.com wrote: On Wed, Mar 12, 2014 at 1:26 PM, Gupta, Pekon pe...@ti.com wrote: Hi, From: Menon, Nishanth On 03/12/2014 05:49 AM, Pekon Gupta wrote: Beaglebone Board can be connected to expansion boards to add devices to them. These expansion boards are called 'capes'. This patch adds support for following versions of Beaglebone(AM335x) NAND capes (a) NAND Device with bus-width=16, block-size=128k, page-size=2k, oob-size=64 (b) NAND Device with bus-width=16, block-size=256k, page-size=4k, oob-size=224 Further information and datasheets can be found at [1] and [2] [...] [1] http://beagleboardtoys.info/index.php?title=BeagleBone_Memory_Expansion [2] http://beagleboardtoys.info/index.php?title=BeagleBone_4Gb_16-Bit_NAND_Module Signed-off-by: Pekon Gupta pe...@ti.com --- arch/arm/boot/dts/am335x-bone.dts | 123 ++ 1 file changed, 123 insertions(+) diff --git a/arch/arm/boot/dts/am335x-bone.dts b/arch/arm/boot/dts/am335x-bone.dts index 94ee427..be2c572 100644 --- a/arch/arm/boot/dts/am335x-bone.dts +++ b/arch/arm/boot/dts/am335x-bone.dts better to make a nand_cape dts which includes the am335x-bone.dts? Actually, I'm not in favor of having too many xx_board_common.dts files, because it un-necessarily complexes things. We already have arch/arm/boot/dts/am335x-bone-common.dtsi which just saves some lines common to DTS of both Beaglebone-LT(white) and Beaglebone-Black. And, there is no guarantee that Beaglebone-LT(white) will remain compatible to Beaglebone-black in future. Example: some capes are not compatible to beaglebone-black [1], [2]. So, I prefer to keep separate GPMC NAND nodes separately in both DTS, unless there is a strong convincing reason otherwise. [1] http://elinux.org/CircuitCo:BeagleBoardToys [2] http://elinux.org/BeagleBone_Black_Capes Right, and adding NAND, GPMC nodes and asking folks to uncomment sections into a generic board file (which by default has none) makes more sense? I dont use NAND capes or might create my own cape. overo has the same challenges as bone family has.I dont see asking folks to uncomment entries to use the cape is a nicer alternative to having more dts entries. This is just going to get more messy with every cape addition. Should we maybe just leave a basic BeagleBone BeagleBone Black dts file in mainline kernel.org. Then create a repo on github.com/beagleboard/ with every bone/black-first level cape.dts option? Regards, -- Robert Nelson http://www.rcn-ee.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 v1 1/3] ARM: dts: am335x-bone: add support for beaglebone NAND cape
* Robert Nelson robertcnel...@gmail.com [140312 12:11]: On Wed, Mar 12, 2014 at 1:57 PM, Nishanth Menon n...@ti.com wrote: On Wed, Mar 12, 2014 at 1:26 PM, Gupta, Pekon pe...@ti.com wrote: Hi, From: Menon, Nishanth On 03/12/2014 05:49 AM, Pekon Gupta wrote: Beaglebone Board can be connected to expansion boards to add devices to them. These expansion boards are called 'capes'. This patch adds support for following versions of Beaglebone(AM335x) NAND capes (a) NAND Device with bus-width=16, block-size=128k, page-size=2k, oob-size=64 (b) NAND Device with bus-width=16, block-size=256k, page-size=4k, oob-size=224 Further information and datasheets can be found at [1] and [2] [...] [1] http://beagleboardtoys.info/index.php?title=BeagleBone_Memory_Expansion [2] http://beagleboardtoys.info/index.php?title=BeagleBone_4Gb_16-Bit_NAND_Module Signed-off-by: Pekon Gupta pe...@ti.com --- arch/arm/boot/dts/am335x-bone.dts | 123 ++ 1 file changed, 123 insertions(+) diff --git a/arch/arm/boot/dts/am335x-bone.dts b/arch/arm/boot/dts/am335x-bone.dts index 94ee427..be2c572 100644 --- a/arch/arm/boot/dts/am335x-bone.dts +++ b/arch/arm/boot/dts/am335x-bone.dts better to make a nand_cape dts which includes the am335x-bone.dts? Actually, I'm not in favor of having too many xx_board_common.dts files, because it un-necessarily complexes things. We already have arch/arm/boot/dts/am335x-bone-common.dtsi which just saves some lines common to DTS of both Beaglebone-LT(white) and Beaglebone-Black. And, there is no guarantee that Beaglebone-LT(white) will remain compatible to Beaglebone-black in future. Example: some capes are not compatible to beaglebone-black [1], [2]. So, I prefer to keep separate GPMC NAND nodes separately in both DTS, unless there is a strong convincing reason otherwise. [1] http://elinux.org/CircuitCo:BeagleBoardToys [2] http://elinux.org/BeagleBone_Black_Capes Right, and adding NAND, GPMC nodes and asking folks to uncomment sections into a generic board file (which by default has none) makes more sense? I dont use NAND capes or might create my own cape. overo has the same challenges as bone family has.I dont see asking folks to uncomment entries to use the cape is a nicer alternative to having more dts entries. This is just going to get more messy with every cape addition. Should we maybe just leave a basic BeagleBone BeagleBone Black dts file in mainline kernel.org. Then create a repo on github.com/beagleboard/ with every bone/black-first level cape.dts option? Or just include all devices on the most common capes but have their status as disabled by default. For the pinctrl, we need to make sure the pins for a device are not muxed if it's set to disabled state. 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 v1 1/3] ARM: dts: am335x-bone: add support for beaglebone NAND cape
On 03/12/2014 02:28 PM, Tony Lindgren wrote: * Robert Nelson robertcnel...@gmail.com [140312 12:11]: On Wed, Mar 12, 2014 at 1:57 PM, Nishanth Menon n...@ti.com wrote: On Wed, Mar 12, 2014 at 1:26 PM, Gupta, Pekon pe...@ti.com wrote: Hi, From: Menon, Nishanth On 03/12/2014 05:49 AM, Pekon Gupta wrote: Beaglebone Board can be connected to expansion boards to add devices to them. These expansion boards are called 'capes'. This patch adds support for following versions of Beaglebone(AM335x) NAND capes (a) NAND Device with bus-width=16, block-size=128k, page-size=2k, oob-size=64 (b) NAND Device with bus-width=16, block-size=256k, page-size=4k, oob-size=224 Further information and datasheets can be found at [1] and [2] [...] [1] http://beagleboardtoys.info/index.php?title=BeagleBone_Memory_Expansion [2] http://beagleboardtoys.info/index.php?title=BeagleBone_4Gb_16-Bit_NAND_Module Signed-off-by: Pekon Gupta pe...@ti.com --- arch/arm/boot/dts/am335x-bone.dts | 123 ++ 1 file changed, 123 insertions(+) diff --git a/arch/arm/boot/dts/am335x-bone.dts b/arch/arm/boot/dts/am335x-bone.dts index 94ee427..be2c572 100644 --- a/arch/arm/boot/dts/am335x-bone.dts +++ b/arch/arm/boot/dts/am335x-bone.dts better to make a nand_cape dts which includes the am335x-bone.dts? Actually, I'm not in favor of having too many xx_board_common.dts files, because it un-necessarily complexes things. We already have arch/arm/boot/dts/am335x-bone-common.dtsi which just saves some lines common to DTS of both Beaglebone-LT(white) and Beaglebone-Black. And, there is no guarantee that Beaglebone-LT(white) will remain compatible to Beaglebone-black in future. Example: some capes are not compatible to beaglebone-black [1], [2]. So, I prefer to keep separate GPMC NAND nodes separately in both DTS, unless there is a strong convincing reason otherwise. [1] http://elinux.org/CircuitCo:BeagleBoardToys [2] http://elinux.org/BeagleBone_Black_Capes Right, and adding NAND, GPMC nodes and asking folks to uncomment sections into a generic board file (which by default has none) makes more sense? I dont use NAND capes or might create my own cape. overo has the same challenges as bone family has.I dont see asking folks to uncomment entries to use the cape is a nicer alternative to having more dts entries. This is just going to get more messy with every cape addition. Should we maybe just leave a basic BeagleBone BeagleBone Black dts file in mainline kernel.org. Then create a repo on github.com/beagleboard/ with every bone/black-first level cape.dts option? Or just include all devices on the most common capes but have their status as disabled by default. For the pinctrl, we need to make sure the pins for a device are not muxed if it's set to disabled state. You do have a bunch of if you want nand, disable mmc2 configuration in the usage of cape configurations such as this patch, or in the case of [1] (audio cape), different regulator usage etc. Maintaining out of tree cape dts might be an option, but that is prone to maintenance burden as device tree conversion goes on (yeah, all the dt as ABI stuff aside). Keeping aside the subjective nature of what entitles a cape being a common cape,even introducing nodes that belong to three or four different first level capes will definitely have it's own sets of problems. The ideal solution would be some folks pitching in on what Matt pointed in [2] - basically upstream a resource manager on top of the basic overlay support that's in progress and introduce capes as part of that overlay support once it is upstream. Failing which, keeping the base bone dts to basic stuff that bare board supports and having per first level cape dts which includes relevant dts sounds to me the only rationale and easily usable (as in: without much device tree knowledge) - again, I admit easily is subjective here. [1] https://lkml.org/lkml/2014/2/5/183 [2] https://lkml.org/lkml/2014/2/5/247 -- Regards, Nishanth Menon -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 5/5] drivers: bus: omap_l3: Change pr_crit() to dev_err() when IRQ request fails
On Thursday 13 March 2014 01:28 AM, Tony Lindgren wrote:
* Peter Ujfalusi peter.ujfal...@ti.com [140304 23:14]:
On 03/04/2014 04:37 PM, Santosh Shilimkar wrote:
On Tuesday 04 March 2014 08:48 PM, Peter Ujfalusi wrote:
Use dev_err() which will going to print the driver's name as well and the
KERN_ERR level is sufficient in this case (we also print via dev_err when
there is an error with the mem resources)
Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
Reviewed-by: Santosh Shilimkar santosh.shilim...@ti.com
---
drivers/bus/omap_l3_noc.c | 7 +++
1 file changed, 3 insertions(+), 4 deletions(-)
diff --git a/drivers/bus/omap_l3_noc.c b/drivers/bus/omap_l3_noc.c
index 0eff48585ae3..972691a668a3 100644
--- a/drivers/bus/omap_l3_noc.c
+++ b/drivers/bus/omap_l3_noc.c
@@ -158,8 +158,8 @@ static int omap4_l3_probe(struct platform_device *pdev)
ret = devm_request_irq(pdev-dev, l3-debug_irq, l3_interrupt_handler,
IRQF_DISABLED, l3-dbg-irq, l3);
if (ret) {
- pr_crit(L3: request_irq failed to register for 0x%x\n,
- l3-debug_irq);
+ dev_err(pdev-dev, request_irq failed for %d\n,
+ l3-debug_irq);
return ret;
}
@@ -167,8 +167,7 @@ static int omap4_l3_probe(struct platform_device *pdev)
ret = devm_request_irq(pdev-dev, l3-app_irq, l3_interrupt_handler,
IRQF_DISABLED, l3-app-irq, l3);
if (ret)
- pr_crit(L3: request_irq failed to register for 0x%x\n,
- l3-app_irq);
+ dev_err(pdev-dev, request_irq failed for %d\n, l3-app_irq);
return ret;
}
So this one change in the log level. If I look at now, may be dev_err
is fine but the change is not same.
Not sure what you mean by 'the change is not same'?
I just picked the old series and rebased it on linux-next, the patch is the
same as it was back in May 2013:
https://lkml.org/lkml/2013/5/2/205
And yes, I have shortened the texts in the print, but the meaning of the
prints have not changed.
Santosh, got any more comments on this series?
Nope. looks good
--
To unsubscribe from this list: send the line unsubscribe 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 5/5] drivers: bus: omap_l3: Change pr_crit() to dev_err() when IRQ request fails
* Santosh Shilimkar santosh.shilim...@ti.com [140312 14:08]:
On Thursday 13 March 2014 01:28 AM, Tony Lindgren wrote:
* Peter Ujfalusi peter.ujfal...@ti.com [140304 23:14]:
On 03/04/2014 04:37 PM, Santosh Shilimkar wrote:
On Tuesday 04 March 2014 08:48 PM, Peter Ujfalusi wrote:
Use dev_err() which will going to print the driver's name as well and the
KERN_ERR level is sufficient in this case (we also print via dev_err when
there is an error with the mem resources)
Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
Reviewed-by: Santosh Shilimkar santosh.shilim...@ti.com
---
drivers/bus/omap_l3_noc.c | 7 +++
1 file changed, 3 insertions(+), 4 deletions(-)
diff --git a/drivers/bus/omap_l3_noc.c b/drivers/bus/omap_l3_noc.c
index 0eff48585ae3..972691a668a3 100644
--- a/drivers/bus/omap_l3_noc.c
+++ b/drivers/bus/omap_l3_noc.c
@@ -158,8 +158,8 @@ static int omap4_l3_probe(struct platform_device
*pdev)
ret = devm_request_irq(pdev-dev, l3-debug_irq,
l3_interrupt_handler,
IRQF_DISABLED, l3-dbg-irq, l3);
if (ret) {
-pr_crit(L3: request_irq failed to register for 0x%x\n,
-l3-debug_irq);
+dev_err(pdev-dev, request_irq failed for %d\n,
+l3-debug_irq);
return ret;
}
@@ -167,8 +167,7 @@ static int omap4_l3_probe(struct platform_device
*pdev)
ret = devm_request_irq(pdev-dev, l3-app_irq,
l3_interrupt_handler,
IRQF_DISABLED, l3-app-irq, l3);
if (ret)
-pr_crit(L3: request_irq failed to register for 0x%x\n,
-l3-app_irq);
+dev_err(pdev-dev, request_irq failed for %d\n,
l3-app_irq);
return ret;
}
So this one change in the log level. If I look at now, may be dev_err
is fine but the change is not same.
Not sure what you mean by 'the change is not same'?
I just picked the old series and rebased it on linux-next, the patch is the
same as it was back in May 2013:
https://lkml.org/lkml/2013/5/2/205
And yes, I have shortened the texts in the print, but the meaning of the
prints have not changed.
Santosh, got any more comments on this series?
Nope. looks good
OK probably best that Arnd or Olof picks these directly:
Acked-by: Tony Lindgren t...@atomide.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 v1 1/3] ARM: dts: am335x-bone: add support for beaglebone NAND cape
-Original Message-
From: Menon, Nishanth
Sent: Thursday, March 13, 2014 2:21 AM
To: Tony Lindgren; Robert Nelson
Cc: Gupta, Pekon; bcous...@baylibre.com; linux-omap; linux-mtd
Subject: Re: [PATCH v1 1/3] ARM: dts: am335x-bone: add support for beaglebone
NAND cape
On 03/12/2014 02:28 PM, Tony Lindgren wrote:
* Robert Nelson robertcnel...@gmail.com [140312 12:11]:
On Wed, Mar 12, 2014 at 1:57 PM, Nishanth Menon n...@ti.com wrote:
On Wed, Mar 12, 2014 at 1:26 PM, Gupta, Pekon pe...@ti.com wrote:
Hi,
From: Menon, Nishanth
On 03/12/2014 05:49 AM, Pekon Gupta wrote:
Beaglebone Board can be connected to expansion boards to add devices to
them.
These expansion boards are called 'capes'. This patch adds support for
following versions of Beaglebone(AM335x) NAND capes
(a) NAND Device with bus-width=16, block-size=128k, page-size=2k,
oob-size=64
(b) NAND Device with bus-width=16, block-size=256k, page-size=4k,
oob-size=224
Further information and datasheets can be found at [1] and [2]
[...]
[1]
http://beagleboardtoys.info/index.php?title=BeagleBone_Memory_Expansion
[2]
http://beagleboardtoys.info/index.php?title=BeagleBone_4Gb_16-Bit_NAND_Module
Signed-off-by: Pekon Gupta pe...@ti.com
---
arch/arm/boot/dts/am335x-bone.dts | 123
++
1 file changed, 123 insertions(+)
diff --git a/arch/arm/boot/dts/am335x-bone.dts
b/arch/arm/boot/dts/am335x-bone.dts
index 94ee427..be2c572 100644
--- a/arch/arm/boot/dts/am335x-bone.dts
+++ b/arch/arm/boot/dts/am335x-bone.dts
better to make a nand_cape dts which includes the am335x-bone.dts?
Actually, I'm not in favor of having too many xx_board_common.dts files,
because it un-necessarily complexes things.
We already have arch/arm/boot/dts/am335x-bone-common.dtsi which just
saves
some lines common to DTS of both Beaglebone-LT(white) and
Beaglebone-Black.
And, there is no guarantee that Beaglebone-LT(white) will remain
compatible to
Beaglebone-black in future.
Example: some capes are not compatible to beaglebone-black [1], [2].
So, I prefer to keep separate GPMC NAND nodes separately in both DTS,
unless there is a strong convincing reason otherwise.
[1] http://elinux.org/CircuitCo:BeagleBoardToys
[2] http://elinux.org/BeagleBone_Black_Capes
Right, and adding NAND, GPMC nodes and asking folks to uncomment
sections into a generic board file (which by default has none) makes
more sense? I dont use NAND capes or might create my own cape. overo
has the same challenges as bone family has.I dont see asking folks to
uncomment entries to use the cape is a nicer alternative to having
more dts entries.
I think this is different discussion from previous one ..
common DTS file v/s replicated DTS entries in individual board files
because 'uncomment' issue will remain in both scenarios. (please read below)
This is just going to get more messy with every cape addition. Should
we maybe just leave a basic BeagleBone BeagleBone Black dts file in
mainline kernel.org.
Then create a repo on github.com/beagleboard/ with every
bone/black-first level cape.dts option?
Or just include all devices on the most common capes but have their
status as disabled by default.
For the pinctrl, we need to make sure the pins for a device are not
muxed if it's set to disabled state.
Yes, this is exactly what I intended. Therefore if you revisit the
uncomment section, then you would find that there is mmc2=disabled
because on beaglebone-black eMMC (MMC2) pinctrl conflicts with
NAND pin-ctrl.
+/*
+ * uncomment following to enable NAND cape support
+ * mmc2 {
+ * status = disabled;
+ * };
+ * elm {
+ * status = okay;
+ * };
+ * gpmc {
+ * status = okay;
+ * };
And I agree 'uncommenting' is not cleaner approach here, so if everyone
agrees, I can remove the above comment and just keep NAND DT node
disabled by default.
You do have a bunch of if you want nand, disable mmc2 configuration
in the usage of cape configurations such as this patch, or in the case
of [1] (audio cape), different regulator usage etc. Maintaining out of
tree cape dts might be an option, but that is prone to maintenance
burden as device tree conversion goes on (yeah, all the dt as ABI
stuff aside).
Keeping aside the subjective nature of what entitles a cape being a
common cape,even introducing nodes that belong to three or four
different first level capes will definitely have it's own sets of
problems.
The ideal solution would be some folks pitching in on what Matt
pointed in [2] - basically upstream a resource manager on
top of the basic overlay support that's in progress and introduce
capes as part of that overlay support once it is upstream.
I'm not sure how much capemgr or DT overlay is useful to larger
audience ?
(1) *Usually* actual custom board going to production will have
all devices populated on the board. fixed. It's very rare that an
[PATCH] ARM: OMAP4: Fix definition of IS_PM44XX_ERRATUM
Just like IS_PM34XX_ERRATUM, IS_PM44XX_ERRATUM is valid only if
CONFIG_PM is enabled, else, disabling CONFIG_PM results in build
failure complaining about the following:
arch/arm/mach-omap2/built-in.o: In function `omap4_boot_secondary':
:(.text+0x8a70): undefined reference to `pm44xx_errata'
Fixes: c962184 (ARM: OMAP4: PM: add errata support)
Reported-by: Tony Lindgren t...@atomide.com
Signed-off-by: Nishanth Menon n...@ti.com
---
Patch based on: v3.14-rc6
Reported originally with a randconfig defconfig:
http://slexy.org/view/s21U7eF4k1
arch/arm/mach-omap2/pm.h |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/mach-omap2/pm.h b/arch/arm/mach-omap2/pm.h
index 7bdd22a..d4d0fce 100644
--- a/arch/arm/mach-omap2/pm.h
+++ b/arch/arm/mach-omap2/pm.h
@@ -103,7 +103,7 @@ static inline void
enable_omap3630_toggle_l2_on_restore(void) { }
#define PM_OMAP4_ROM_SMP_BOOT_ERRATUM_GICD (1 0)
-#if defined(CONFIG_ARCH_OMAP4)
+#if defined(CONFIG_PM) defined(CONFIG_ARCH_OMAP4)
extern u16 pm44xx_errata;
#define IS_PM44XX_ERRATUM(id) (pm44xx_errata (id))
#else
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v1 1/3] ARM: dts: am335x-bone: add support for beaglebone NAND cape
On 16:13-20140312, Gupta, Pekon wrote:
I think this is different discussion from previous one ..
common DTS file v/s replicated DTS entries in individual board files
because 'uncomment' issue will remain in both scenarios. (please read below)
see below patch to highlight what I was mentioning: The build generates the dtb
that can be used with
nand cape without any hand modification. the easy part I mentioned is
just knowing to select the right dtb corresponding to the cape. There is
no replication, just overriding the default board behavior.
From b573d557aa09e34b1b587943dfea73bac480286d Mon Sep 17 00:00:00 2001
From: DUMMY AUTHOR du...@somewhere.com
Date: Wed, 12 Mar 2014 16:47:15 -0500
Subject: [REFERENCE PATCH] ARM: dts: am335x-bone: add support for beaglebone
NAND cape
Beaglebone Board can be connected to expansion boards to add devices to them.
These expansion boards are called 'capes'. This patch adds support for
following versions of Beaglebone(AM335x) NAND capes
(a) NAND Device with bus-width=16, block-size=128k, page-size=2k, oob-size=64
(b) NAND Device with bus-width=16, block-size=256k, page-size=4k, oob-size=224
Further information and datasheets can be found at [1] and [2]
* How to boot from NAND using Memory Expander + NAND Cape ? *
- Important: As BOOTSEL values are sampled only at POR, so after changing any
setting on SW2 (DIP switch), disconnect and reconnect all board power supply
(including mini-USB console port) to POR the beaglebone.
- Selection of ECC scheme
for NAND cape(a), ROM code expects BCH8_HW ecc-scheme
for NAND cape(b), ROM code expects BCH16_HW ecc-scheme
- Selction of boot modes can be controlled via DIP switch(SW2) present on
Memory Expander cape.
SW2[SWITCH_BOOT] == OFF follow default boot order MMC- SPI - UART - USB
SW2[SWITCH_BOOT] == ON boot mode selected via DIP switch(SW2)
So to flash NAND, first boot via MMC or other sources and then switch to
SW2[SWITCH_BOOT]=ON to boot from NAND Cape.
- For NAND boot following switch settings need to be followed
SW2[ 0] = ON (SYSBOOT[ 0]==0: NAND boot mode selected )
SW2[ 1] = ON (SYSBOOT[ 1]==0: -- do -- )
SW2[ 2] = OFF (SYSBOOT[ 2]==1: -- do -- )
SW2[ 3] = OFF (SYSBOOT[ 3]==1: -- do -- )
SW2[ 4] = ON (SYSBOOT[ 4]==0: -- do -- )
SW2[ 8] = OFF (SYSBOOT[ 8]==1: 0:x8 device, 1:x16 device )
SW2[ 9] = ON (SYSBOOT[ 9]==0: ECC done by ROM )
SW2[10] = ON (SYSBOOT[10]==0: Non Muxed device )
SW2[11] = ON (SYSBOOT[11]==0:-- do -- )
[1] http://beagleboardtoys.info/index.php?title=BeagleBone_Memory_Expansion
[2]
http://beagleboardtoys.info/index.php?title=BeagleBone_4Gb_16-Bit_NAND_Module
---
arch/arm/boot/dts/Makefile|1 +
arch/arm/boot/dts/am335x-bone-memory-cape.dts | 123 +
2 files changed, 124 insertions(+)
create mode 100644 arch/arm/boot/dts/am335x-bone-memory-cape.dts
diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index 0320303..c5e9bfa 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -226,6 +226,7 @@ dtb-$(CONFIG_ARCH_OMAP2PLUS) += omap2420-h4.dtb \
am335x-evmsk.dtb \
am335x-bone.dtb \
am335x-boneblack.dtb \
+ am335x-bone-memory-cape.dtb\
am335x-nano.dtb \
am335x-base0033.dtb \
am3517-evm.dtb \
diff --git a/arch/arm/boot/dts/am335x-bone-memory-cape.dts
b/arch/arm/boot/dts/am335x-bone-memory-cape.dts
new file mode 100644
index 000..7ab088d
--- /dev/null
+++ b/arch/arm/boot/dts/am335x-bone-memory-cape.dts
@@ -0,0 +1,123 @@
+#include am335x-bone.dts
+
+am33xx_pinmux {
+ nand_flash_x16: nand_flash_x16 {
+ pinctrl-single,pins =
+ 0x00 (MUX_MODE0 | PIN_INPUT)/* gpmc_ad0.gpmc_ad0 */
+ 0x04 (MUX_MODE0 | PIN_INPUT)/* gpmc_ad1.gpmc_ad1 */
+ 0x08 (MUX_MODE0 | PIN_INPUT)/* gpmc_ad2.gpmc_ad2 */
+ 0x0c (MUX_MODE0 | PIN_INPUT)/* gpmc_ad3.gpmc_ad3 */
+ 0x10 (MUX_MODE0 | PIN_INPUT)/* gpmc_ad4.gpmc_ad4 */
+ 0x14 (MUX_MODE0 | PIN_INPUT)/* gpmc_ad5.gpmc_ad5 */
+ 0x18 (MUX_MODE0 | PIN_INPUT)/* gpmc_ad6.gpmc_ad6 */
+ 0x1c (MUX_MODE0 | PIN_INPUT)/* gpmc_ad7.gpmc_ad7 */
+ 0x20 (MUX_MODE0 | PIN_INPUT)/* gpmc_ad8.gpmc_ad8 */
+ 0x24 (MUX_MODE0 | PIN_INPUT)/* gpmc_ad9.gpmc_ad9 */
+ 0x28 (MUX_MODE0 | PIN_INPUT)/* gpmc_ad10.gpmc_ad10
*/
+ 0x2c (MUX_MODE0 | PIN_INPUT)/* gpmc_ad11.gpmc_ad11
*/
+ 0x30 (MUX_MODE0 | PIN_INPUT)/* gpmc_ad12.gpmc_ad12
*/
+ 0x34 (MUX_MODE0 | PIN_INPUT)/* gpmc_ad13.gpmc_ad13
*/
+ 0x38 (MUX_MODE0 | PIN_INPUT
Re: [PATCH] ARM: OMAP4: Fix definition of IS_PM44XX_ERRATUM
On Thursday 13 March 2014 05:43 AM, Nishanth Menon wrote:
Just like IS_PM34XX_ERRATUM, IS_PM44XX_ERRATUM is valid only if
CONFIG_PM is enabled, else, disabling CONFIG_PM results in build
failure complaining about the following:
arch/arm/mach-omap2/built-in.o: In function `omap4_boot_secondary':
:(.text+0x8a70): undefined reference to `pm44xx_errata'
Not entirely accurate since CPU hotplug doesn't depend on CONFIG_PM
Fixes: c962184 (ARM: OMAP4: PM: add errata support)
Reported-by: Tony Lindgren t...@atomide.com
Signed-off-by: Nishanth Menon n...@ti.com
---
Patch based on: v3.14-rc6
Reported originally with a randconfig defconfig:
http://slexy.org/view/s21U7eF4k1
But without the PM sleep code, hotplug won't work either.
SO I think its ok assumption in this particular case
arch/arm/mach-omap2/pm.h |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/mach-omap2/pm.h b/arch/arm/mach-omap2/pm.h
index 7bdd22a..d4d0fce 100644
--- a/arch/arm/mach-omap2/pm.h
+++ b/arch/arm/mach-omap2/pm.h
@@ -103,7 +103,7 @@ static inline void
enable_omap3630_toggle_l2_on_restore(void) { }
#define PM_OMAP4_ROM_SMP_BOOT_ERRATUM_GICD (1 0)
-#if defined(CONFIG_ARCH_OMAP4)
+#if defined(CONFIG_PM) defined(CONFIG_ARCH_OMAP4)
extern u16 pm44xx_errata;
#define IS_PM44XX_ERRATUM(id)(pm44xx_errata (id))
#else
--
To unsubscribe from this list: send the line unsubscribe 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: Fix definition of IS_PM44XX_ERRATUM
On 03/12/2014 04:59 PM, Santosh Shilimkar wrote:
On Thursday 13 March 2014 05:43 AM, Nishanth Menon wrote:
Just like IS_PM34XX_ERRATUM, IS_PM44XX_ERRATUM is valid only if
CONFIG_PM is enabled, else, disabling CONFIG_PM results in build
failure complaining about the following:
arch/arm/mach-omap2/built-in.o: In function `omap4_boot_secondary':
:(.text+0x8a70): undefined reference to `pm44xx_errata'
Not entirely accurate since CPU hotplug doesn't depend on CONFIG_PM
Just reporting the build error here.
Fixes: c962184 (ARM: OMAP4: PM: add errata support)
Reported-by: Tony Lindgren t...@atomide.com
Signed-off-by: Nishanth Menon n...@ti.com
---
Patch based on: v3.14-rc6
Reported originally with a randconfig defconfig:
http://slexy.org/view/s21U7eF4k1
But without the PM sleep code, hotplug won't work either.
yep - agreed,
SO I think its ok assumption in this particular case
Can I take that as an Ack here? or would you suggest any improvements?
arch/arm/mach-omap2/pm.h |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/mach-omap2/pm.h b/arch/arm/mach-omap2/pm.h
index 7bdd22a..d4d0fce 100644
--- a/arch/arm/mach-omap2/pm.h
+++ b/arch/arm/mach-omap2/pm.h
@@ -103,7 +103,7 @@ static inline void
enable_omap3630_toggle_l2_on_restore(void) { }
#define PM_OMAP4_ROM_SMP_BOOT_ERRATUM_GICD (1 0)
-#if defined(CONFIG_ARCH_OMAP4)
+#if defined(CONFIG_PM) defined(CONFIG_ARCH_OMAP4)
extern u16 pm44xx_errata;
#define IS_PM44XX_ERRATUM(id) (pm44xx_errata (id))
#else
--
Regards,
Nishanth Menon
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: OMAP4: Fix definition of IS_PM44XX_ERRATUM
On Thursday 13 March 2014 06:07 AM, Nishanth Menon wrote: On 03/12/2014 04:59 PM, Santosh Shilimkar wrote: On Thursday 13 March 2014 05:43 AM, Nishanth Menon wrote: Just like IS_PM34XX_ERRATUM, IS_PM44XX_ERRATUM is valid only if CONFIG_PM is enabled, else, disabling CONFIG_PM results in build failure complaining about the following: arch/arm/mach-omap2/built-in.o: In function `omap4_boot_secondary': :(.text+0x8a70): undefined reference to `pm44xx_errata' Not entirely accurate since CPU hotplug doesn't depend on CONFIG_PM Just reporting the build error here. Fixes: c962184 (ARM: OMAP4: PM: add errata support) Reported-by: Tony Lindgren t...@atomide.com Signed-off-by: Nishanth Menon n...@ti.com --- Patch based on: v3.14-rc6 Reported originally with a randconfig defconfig: http://slexy.org/view/s21U7eF4k1 But without the PM sleep code, hotplug won't work either. yep - agreed, SO I think its ok assumption in this particular case Can I take that as an Ack here? or would you suggest any improvements? yep. Acked-by: Santosh Shilimkar santosh.shilim...@ti.ocm -- To unsubscribe from this list: send the line unsubscribe 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: [PATCHv3 1/2] arm: dts: dra7: Add qspi device.
Tony, On Wednesday 12 March 2014 11:04 PM, Tony Lindgren wrote: * Sourav Poddarsourav.pod...@ti.com [140310 04:54]: These add device tree entry for qspi controller driver on dra7-evm. It seems that we need to wait for the crossbar dependencies to get cleared in the mainline kernel before we can apply this as otherwise the interrupts will be wrong in omap-for-v3.15/dt branch. Regards, Tony Ok. Can patch2 of this series be picked? It does not depend on crossbar and is targetted for a different SOC(AM43x). -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
