Re: [PATCH 4/4] wl1251: spi: add device tree support
On Oct 28, 2013, at 5:38 PM, Tomasz Figa wrote: On Monday 28 of October 2013 01:37:34 Kumar Gala wrote: On Oct 27, 2013, at 11:14 AM, Sebastian Reichel wrote: Add device tree support for the spi variant of wl1251 and document the binding. Signed-off-by: Sebastian Reichel s...@debian.org --- .../devicetree/bindings/net/wireless/ti,wl1251.txt | 36 ++ drivers/net/wireless/ti/wl1251/spi.c | 23 ++ 2 files changed, 53 insertions(+), 6 deletions(-) create mode 100644 Documentation/devicetree/bindings/net/wireless/ti,wl1251.txt diff --git a/Documentation/devicetree/bindings/net/wireless/ti,wl1251.txt b/Documentation/devicetree/bindings/net/wireless/ti,wl1251.txt new file mode 100644 index 000..5f8a154 --- /dev/null +++ b/Documentation/devicetree/bindings/net/wireless/ti,wl1251.txt @@ -0,0 +1,36 @@ +* Texas Instruments wl1251 controller + +The wl1251 chip can be connected via SPI or via SDIO. The linux +kernel currently only supports device tree for the SPI variant. + From the binding I have no idea what this chip actually does, also we don't normally reference linux kernel support in bindings specs (so please remove it). However, what would expect the SDIO binding to look like? Or more specifically, how would you distinguish the SPI vs SDIO binding/connection? I'm wondering if the compatible should be something like ti,wl1251-spi and than the sdio can be ti,wl1251-sdio Well, you can easily distinguish an SDIO device from an SPI device by its parent node, but... The binding for SDIO might require different set of properties (other than ones inherited from generic SDIO or SPI bindings) than one for SPI. So probably different compatible values might be justified. Did we already have such case before? (maybe some I2C + SPI devices?) +Required properties: +- compatible : Should be ti,wl1251 reg is not listed as a required prop. It is implied by SPI bindings, but it might be a good idea to have this stated here as well. +- interrupts : Should contain interrupt line +- interrupt-parent : Should be the phandle for the interrupt + controller that services interrupts for this device +- vio-supply : phandle to regulator providing VIO +- power-gpio : GPIO connected to chip's PMEN pin should be vendor prefixed: ti,power-gpio Hmm, out of curiosity, is it a rule for this kind of properties? I can see both cases with and without prefixes when grepping for -gpios in Documentation/devicetree/bindings. We should really have such things written down somewhere. Agreed, it should be part of the various docs we are suppose to produce for review and binding creation guidelines. +- For additional required properties on SPI, please consult + Documentation/devicetree/bindings/spi/spi-bus.txt + +Optional properties: +- ti,use-eeprom : If found, configuration will be loaded from eeprom. can you be a bit more specific on what cfg will be loaded. Also, is this property a boolean, if so how do I know which eeprom the cfg is loaded from (is it one that is directly connected to the wl1251? Maybe one from ti,has-eeprom or ti,config-eeprom would be better name for this property? Probably, ti,wl1251-has-eeprom or something like that would be better. However, I'm not going to get too caught up on names of properties. - k -- Employee of Qualcomm Innovation Center, Inc. Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv2 1/3] Input: twl4030-keypad - add device tree support
On Oct 28, 2013, at 8:06 PM, Sebastian Reichel wrote: On Mon, Oct 28, 2013 at 01:42:47AM -0500, Kumar Gala wrote: +This binding is based on the matrix-keymap binding with the following +changes: Maybe be a bit more specific and say 'based on the input/matrix-keymap.txt binding'.. OK. + * keypad,num-rows and keypad,num-columns are required. Is linux,keymap required from matrix-keymap.txt? Yes, matrix-keymap.txt contains descriptions for the following: required: - linux,keymap So you don't say that linux,keymap is required for twl4030-keypad (wasn't clear if you assumed that or not). optional: - keypad,num-rows - keypad,num-columns +Optional Properties specific to linux: +- linux,keypad-no-autorepeat: do no enable autorepeat feature. Does it make sense to update the matrix-keymap.txt binding to add 'linux,keypad-no-autorepeat' there? At least according to devicetree documentation there are keymap-matrix.txt based drivers, which do not support linux,keypad-no-autorepeat. Which is why it could be optional in keymap-matrix.txt. I dont know anything about keymap/keypad's just asking the question? It seems as if linux,keypad-no-autorepeat is intended to mean the same thing (if relevant to the device) across all drivers. Is that correct? If so it seems like moving it to be specified in a generic input binding makes sense, just not sure if keymap-matrix.txt is that place or not. - k -- Employee of Qualcomm Innovation Center, Inc. Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 1/1] ARM: OMAP2+: DRA7: hwmod: Add hwmod data for MDIO and CPSW
On Saturday 19 October 2013 11:15 PM, Paul Walmsley wrote: On Fri, 18 Oct 2013, Mugunthan V N wrote: Adding hwmod data for CPSW and MDIO which is present in DRA7xx SoC Signed-off-by: Mugunthan V N mugunthan...@ti.com Has a DRA7xx public TRM been published yet? Paul There is no TRM available publically as of now, it may take another a month time. Regards Mugunthan V N -- To unsubscribe from this list: send the line unsubscribe 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: omap4-panda: add DPI pinmuxing
Hi Tony,
On 25/10/13 13:07, Tomi Valkeinen wrote:
New u-boot versions no longer set the pinmuxing for Panda's DPI output,
and the muxing has to be done in the .dts file.
Add pinmuxing for DPI and TFP410. Without these, the DVI output on Panda
does not work with recent u-boot.
Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
The two latter patches in this series needs more work and can be
dropped, but this one should be applied to make Panda work properly with
new u-boots.
Tomi
---
arch/arm/boot/dts/omap4-panda-common.dtsi | 43
+++
1 file changed, 43 insertions(+)
diff --git a/arch/arm/boot/dts/omap4-panda-common.dtsi
b/arch/arm/boot/dts/omap4-panda-common.dtsi
index faa95b5..fcb8856 100644
--- a/arch/arm/boot/dts/omap4-panda-common.dtsi
+++ b/arch/arm/boot/dts/omap4-panda-common.dtsi
@@ -129,6 +129,8 @@
twl6040_pins
mcpdm_pins
mcbsp1_pins
+ dss_dpi_pins
+ tfp410_pins
dss_hdmi_pins
tpd12s015_pins
hsusbb1_pins
@@ -166,6 +168,47 @@
;
};
+ dss_dpi_pins: pinmux_dss_dpi_pins {
+ pinctrl-single,pins =
+ 0x122 (PIN_OUTPUT | MUX_MODE5) /* dispc2_data23 */
+ 0x124 (PIN_OUTPUT | MUX_MODE5) /* dispc2_data22 */
+ 0x126 (PIN_OUTPUT | MUX_MODE5) /* dispc2_data21 */
+ 0x128 (PIN_OUTPUT | MUX_MODE5) /* dispc2_data20 */
+ 0x12a (PIN_OUTPUT | MUX_MODE5) /* dispc2_data19 */
+ 0x12c (PIN_OUTPUT | MUX_MODE5) /* dispc2_data18 */
+ 0x12e (PIN_OUTPUT | MUX_MODE5) /* dispc2_data15 */
+ 0x130 (PIN_OUTPUT | MUX_MODE5) /* dispc2_data14 */
+ 0x132 (PIN_OUTPUT | MUX_MODE5) /* dispc2_data13 */
+ 0x134 (PIN_OUTPUT | MUX_MODE5) /* dispc2_data12 */
+ 0x136 (PIN_OUTPUT | MUX_MODE5) /* dispc2_data11 */
+
+ 0x174 (PIN_OUTPUT | MUX_MODE5) /* dispc2_data10 */
+ 0x176 (PIN_OUTPUT | MUX_MODE5) /* dispc2_data9 */
+ 0x178 (PIN_OUTPUT | MUX_MODE5) /* dispc2_data16 */
+ 0x17a (PIN_OUTPUT | MUX_MODE5) /* dispc2_data17 */
+ 0x17c (PIN_OUTPUT | MUX_MODE5) /* dispc2_hsync */
+ 0x17e (PIN_OUTPUT | MUX_MODE5) /* dispc2_pclk */
+ 0x180 (PIN_OUTPUT | MUX_MODE5) /* dispc2_vsync */
+ 0x182 (PIN_OUTPUT | MUX_MODE5) /* dispc2_de */
+ 0x184 (PIN_OUTPUT | MUX_MODE5) /* dispc2_data8 */
+ 0x186 (PIN_OUTPUT | MUX_MODE5) /* dispc2_data7 */
+ 0x188 (PIN_OUTPUT | MUX_MODE5) /* dispc2_data6 */
+ 0x18a (PIN_OUTPUT | MUX_MODE5) /* dispc2_data5 */
+ 0x18c (PIN_OUTPUT | MUX_MODE5) /* dispc2_data4 */
+ 0x18e (PIN_OUTPUT | MUX_MODE5) /* dispc2_data3 */
+
+ 0x190 (PIN_OUTPUT | MUX_MODE5) /* dispc2_data2 */
+ 0x192 (PIN_OUTPUT | MUX_MODE5) /* dispc2_data1 */
+ 0x194 (PIN_OUTPUT | MUX_MODE5) /* dispc2_data0 */
+ ;
+ };
+
+ tfp410_pins: pinmux_tfp410_pins {
+ pinctrl-single,pins =
+ 0x144 (PIN_OUTPUT | MUX_MODE3) /* gpio_0 */
+ ;
+ };
+
dss_hdmi_pins: pinmux_dss_hdmi_pins {
pinctrl-single,pins =
0x5a (PIN_INPUT_PULLUP | MUX_MODE0) /*
hdmi_cec.hdmi_cec */
signature.asc
Description: OpenPGP digital signature
Re: [PATCHv2 1/3] Input: twl4030-keypad - add device tree support
On Tue, Oct 29, 2013 at 03:33:31AM -0500, Kumar Gala wrote: On Oct 28, 2013, at 8:06 PM, Sebastian Reichel wrote: On Mon, Oct 28, 2013 at 01:42:47AM -0500, Kumar Gala wrote: +This binding is based on the matrix-keymap binding with the following +changes: Maybe be a bit more specific and say 'based on the input/matrix-keymap.txt binding'.. OK. + * keypad,num-rows and keypad,num-columns are required. Is linux,keymap required from matrix-keymap.txt? Yes, matrix-keymap.txt contains descriptions for the following: required: - linux,keymap So you don't say that linux,keymap is required for twl4030-keypad (wasn't clear if you assumed that or not). It's already required by matrix-keypad, so I assumed the requirement is inherited by twl4030-keypad. The other matrix-keymap based bindings assume the same. keypad,num-rows and keypad,num-columns are only stated explicitly, because they are optional in matrix-keymap, but required by twl4030-keympad. optional: - keypad,num-rows - keypad,num-columns +Optional Properties specific to linux: +- linux,keypad-no-autorepeat: do no enable autorepeat feature. Does it make sense to update the matrix-keymap.txt binding to add 'linux,keypad-no-autorepeat' there? At least according to devicetree documentation there are keymap-matrix.txt based drivers, which do not support linux,keypad-no-autorepeat. Which is why it could be optional in keymap-matrix.txt. I dont know anything about keymap/keypad's just asking the question? It seems as if linux,keypad-no-autorepeat is intended to mean the same thing (if relevant to the device) across all drivers. Is that correct? If so it seems like moving it to be specified in a generic input binding makes sense, just not sure if keymap-matrix.txt is that place or not. Yes, when supported it means the same. I can add it to keymap-matrix.txt. -- Sebastian signature.asc Description: Digital signature
Re: [PATCH v2] omapdss: Add new panel driver for Topolly td028ttec1 LCD.
On 17/10/13 17:14, Marek Belisko wrote:
Signed-off-by: Marek Belisko ma...@goldelico.com
Signed-off-by: H. Nikolaus Schaller h...@goldelico.com
---
changes from v1:
- reworked to be spi driver instead platform with custom spi bitbang
this configuration was tested with spi_gpio bitbang driver on gta04 board
and works fine (thanks Tomi and Lars-Peter for comments)
- address previous comments
drivers/video/omap2/displays-new/Kconfig | 6 +
drivers/video/omap2/displays-new/Makefile | 1 +
.../omap2/displays-new/panel-tpo-td028ttec1.c | 486
+
include/video/omap-panel-data.h| 13 +
4 files changed, 506 insertions(+)
create mode 100644 drivers/video/omap2/displays-new/panel-tpo-td028ttec1.c
diff --git a/drivers/video/omap2/displays-new/Kconfig
b/drivers/video/omap2/displays-new/Kconfig
index 6c90885..1054249 100644
--- a/drivers/video/omap2/displays-new/Kconfig
+++ b/drivers/video/omap2/displays-new/Kconfig
@@ -56,6 +56,12 @@ config DISPLAY_PANEL_SHARP_LS037V7DW01
help
LCD Panel used in TI's SDP3430 and EVM boards
+config DISPLAY_PANEL_TPO_TD028TTEC1
+tristate TPO TD028TTEC1 LCD Panel
+depends on SPI
+help
+ LCD panel used in Openmoko.
+
config DISPLAY_PANEL_TPO_TD043MTEA1
tristate TPO TD043MTEA1 LCD Panel
depends on SPI
diff --git a/drivers/video/omap2/displays-new/Makefile
b/drivers/video/omap2/displays-new/Makefile
index 5aeb11b..0323a8a 100644
--- a/drivers/video/omap2/displays-new/Makefile
+++ b/drivers/video/omap2/displays-new/Makefile
@@ -8,5 +8,6 @@ obj-$(CONFIG_DISPLAY_PANEL_DSI_CM) += panel-dsi-cm.o
obj-$(CONFIG_DISPLAY_PANEL_SONY_ACX565AKM) += panel-sony-acx565akm.o
obj-$(CONFIG_DISPLAY_PANEL_LGPHILIPS_LB035Q02) += panel-lgphilips-lb035q02.o
obj-$(CONFIG_DISPLAY_PANEL_SHARP_LS037V7DW01) += panel-sharp-ls037v7dw01.o
+obj-$(CONFIG_DISPLAY_PANEL_TPO_TD028TTEC1) += panel-tpo-td028ttec1.o
obj-$(CONFIG_DISPLAY_PANEL_TPO_TD043MTEA1) += panel-tpo-td043mtea1.o
obj-$(CONFIG_DISPLAY_PANEL_NEC_NL8048HL11) += panel-nec-nl8048hl11.o
diff --git a/drivers/video/omap2/displays-new/panel-tpo-td028ttec1.c
b/drivers/video/omap2/displays-new/panel-tpo-td028ttec1.c
new file mode 100644
index 000..5a44d30
--- /dev/null
+++ b/drivers/video/omap2/displays-new/panel-tpo-td028ttec1.c
@@ -0,0 +1,486 @@
+/*
+ * Toppoly TD028TTEC1 panel support
+ *
+ * Copyright (C) 2008 Nokia Corporation
+ * Author: Tomi Valkeinen tomi.valkei...@nokia.com
+ *
+ * Neo 1973 code (jbt6k74.c):
+ * Copyright (C) 2006-2007 by OpenMoko, Inc.
+ * Author: Harald Welte lafo...@openmoko.org
+ *
+ * Ported and adapted from Neo 1973 U-Boot by:
+ * H. Nikolaus Schaller h...@goldelico.com
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License version 2 as published
by
+ * the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful, but
WITHOUT
+ * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for
+ * more details.
+ *
+ * You should have received a copy of the GNU General Public License along
with
+ * this program. If not, see http://www.gnu.org/licenses/.
+ */
+
+#include linux/module.h
+#include linux/delay.h
+#include linux/spi/spi.h
+#include linux/gpio.h
+#include video/omapdss.h
+#include video/omap-panel-data.h
+
+struct panel_drv_data {
+ struct omap_dss_device dssdev;
+ struct omap_dss_device *in;
+
+ int data_lines;
+
+ struct omap_video_timings videomode;
+
+ struct spi_device *spi_dev;
+
+ u16 tx_buf[4];
Is there some particular reason to have tx_buf in the driver data? It
looks to me that it would fit better as a local variable for the funcs
that need it.
+};
+
+static struct omap_video_timings td028ttec1_panel_timings = {
+ .x_res = 480,
+ .y_res = 640,
+ .pixel_clock= 22153,
+ .hfp= 24,
+ .hsw= 8,
+ .hbp= 8,
+ .vfp= 4,
+ .vsw= 2,
+ .vbp= 2,
+
+ .vsync_level= OMAPDSS_SIG_ACTIVE_LOW,
+ .hsync_level= OMAPDSS_SIG_ACTIVE_LOW,
+
+ .data_pclk_edge = OMAPDSS_DRIVE_SIG_FALLING_EDGE,
+ .de_level = OMAPDSS_SIG_ACTIVE_HIGH,
+ .sync_pclk_edge = OMAPDSS_DRIVE_SIG_OPPOSITE_EDGES,
+};
+
+#define JBT_COMMAND 0x000
+#define JBT_DATA 0x100
+
+int jbt_reg_write_nodata(struct panel_drv_data *ddata, u8 reg)
+{
+ int rc;
+
+ ddata-tx_buf[0] = JBT_COMMAND | reg;
+ rc = spi_write(ddata-spi_dev, (u8 *)ddata-tx_buf,
+ 1*sizeof(u16));
+ if (rc != 0)
+ dev_err(ddata-spi_dev-dev,
+ jbt_reg_write_nodata
Re: [PATCH v2] omapdss: Add new panel driver for Topolly td028ttec1 LCD.
Hi Tomi,
On Tue, Oct 29, 2013 at 12:07 PM, Tomi Valkeinen tomi.valkei...@ti.com wrote:
On 17/10/13 17:14, Marek Belisko wrote:
Signed-off-by: Marek Belisko ma...@goldelico.com
Signed-off-by: H. Nikolaus Schaller h...@goldelico.com
---
changes from v1:
- reworked to be spi driver instead platform with custom spi bitbang
this configuration was tested with spi_gpio bitbang driver on gta04 board
and works fine (thanks Tomi and Lars-Peter for comments)
- address previous comments
drivers/video/omap2/displays-new/Kconfig | 6 +
drivers/video/omap2/displays-new/Makefile | 1 +
.../omap2/displays-new/panel-tpo-td028ttec1.c | 486
+
include/video/omap-panel-data.h| 13 +
4 files changed, 506 insertions(+)
create mode 100644 drivers/video/omap2/displays-new/panel-tpo-td028ttec1.c
diff --git a/drivers/video/omap2/displays-new/Kconfig
b/drivers/video/omap2/displays-new/Kconfig
index 6c90885..1054249 100644
--- a/drivers/video/omap2/displays-new/Kconfig
+++ b/drivers/video/omap2/displays-new/Kconfig
@@ -56,6 +56,12 @@ config DISPLAY_PANEL_SHARP_LS037V7DW01
help
LCD Panel used in TI's SDP3430 and EVM boards
+config DISPLAY_PANEL_TPO_TD028TTEC1
+tristate TPO TD028TTEC1 LCD Panel
+depends on SPI
+help
+ LCD panel used in Openmoko.
+
config DISPLAY_PANEL_TPO_TD043MTEA1
tristate TPO TD043MTEA1 LCD Panel
depends on SPI
diff --git a/drivers/video/omap2/displays-new/Makefile
b/drivers/video/omap2/displays-new/Makefile
index 5aeb11b..0323a8a 100644
--- a/drivers/video/omap2/displays-new/Makefile
+++ b/drivers/video/omap2/displays-new/Makefile
@@ -8,5 +8,6 @@ obj-$(CONFIG_DISPLAY_PANEL_DSI_CM) += panel-dsi-cm.o
obj-$(CONFIG_DISPLAY_PANEL_SONY_ACX565AKM) += panel-sony-acx565akm.o
obj-$(CONFIG_DISPLAY_PANEL_LGPHILIPS_LB035Q02) += panel-lgphilips-lb035q02.o
obj-$(CONFIG_DISPLAY_PANEL_SHARP_LS037V7DW01) += panel-sharp-ls037v7dw01.o
+obj-$(CONFIG_DISPLAY_PANEL_TPO_TD028TTEC1) += panel-tpo-td028ttec1.o
obj-$(CONFIG_DISPLAY_PANEL_TPO_TD043MTEA1) += panel-tpo-td043mtea1.o
obj-$(CONFIG_DISPLAY_PANEL_NEC_NL8048HL11) += panel-nec-nl8048hl11.o
diff --git a/drivers/video/omap2/displays-new/panel-tpo-td028ttec1.c
b/drivers/video/omap2/displays-new/panel-tpo-td028ttec1.c
new file mode 100644
index 000..5a44d30
--- /dev/null
+++ b/drivers/video/omap2/displays-new/panel-tpo-td028ttec1.c
@@ -0,0 +1,486 @@
+/*
+ * Toppoly TD028TTEC1 panel support
+ *
+ * Copyright (C) 2008 Nokia Corporation
+ * Author: Tomi Valkeinen tomi.valkei...@nokia.com
+ *
+ * Neo 1973 code (jbt6k74.c):
+ * Copyright (C) 2006-2007 by OpenMoko, Inc.
+ * Author: Harald Welte lafo...@openmoko.org
+ *
+ * Ported and adapted from Neo 1973 U-Boot by:
+ * H. Nikolaus Schaller h...@goldelico.com
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License version 2 as published
by
+ * the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful, but
WITHOUT
+ * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for
+ * more details.
+ *
+ * You should have received a copy of the GNU General Public License along
with
+ * this program. If not, see http://www.gnu.org/licenses/.
+ */
+
+#include linux/module.h
+#include linux/delay.h
+#include linux/spi/spi.h
+#include linux/gpio.h
+#include video/omapdss.h
+#include video/omap-panel-data.h
+
+struct panel_drv_data {
+ struct omap_dss_device dssdev;
+ struct omap_dss_device *in;
+
+ int data_lines;
+
+ struct omap_video_timings videomode;
+
+ struct spi_device *spi_dev;
+
+ u16 tx_buf[4];
Is there some particular reason to have tx_buf in the driver data? It
looks to me that it would fit better as a local variable for the funcs
that need it.
Yes that's true. I'll remove from driver data.
+};
+
+static struct omap_video_timings td028ttec1_panel_timings = {
+ .x_res = 480,
+ .y_res = 640,
+ .pixel_clock= 22153,
+ .hfp= 24,
+ .hsw= 8,
+ .hbp= 8,
+ .vfp= 4,
+ .vsw= 2,
+ .vbp= 2,
+
+ .vsync_level= OMAPDSS_SIG_ACTIVE_LOW,
+ .hsync_level= OMAPDSS_SIG_ACTIVE_LOW,
+
+ .data_pclk_edge = OMAPDSS_DRIVE_SIG_FALLING_EDGE,
+ .de_level = OMAPDSS_SIG_ACTIVE_HIGH,
+ .sync_pclk_edge = OMAPDSS_DRIVE_SIG_OPPOSITE_EDGES,
+};
+
+#define JBT_COMMAND 0x000
+#define JBT_DATA 0x100
+
+int jbt_reg_write_nodata(struct panel_drv_data *ddata, u8 reg)
+{
+ int rc;
+
+ ddata-tx_buf[0] = JBT_COMMAND | reg;
+ rc = spi_write(ddata-spi_dev, (u8 *)ddata-tx_buf,
+
Re: [PATCH v3 2/4] mmc: omap_hsmmc: Enable SDIO IRQ.
Hi
2013/10/8 Felipe Balbi ba...@ti.com:
Hi,
On Sat, Oct 05, 2013 at 01:17:08PM +0200, Andreas Fenkart wrote:
For now, only support SDIO interrupt if we are booted with
DT. This is because some platforms need special quirks. And
we don't want to add new legacy mux platform init code
callbacks any longer as we are moving to DT based booting
anyways.
Broken hardware, missing the swakueup line, should fallback
to polling, by setting 'ti,quirk-swakup-missing' in the
device tree. Otherwise pending SDIO IRQ are not detected
while in suspend. This affects am33xx processors.
Signed-off-by: Andreas Fenkart afenk...@gmail.com
I still think this patch needs to be splitted, see below.
diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
index 94d6dc8..53beac4 100644
--- a/drivers/mmc/host/omap_hsmmc.c
+++ b/drivers/mmc/host/omap_hsmmc.c
@@ -130,6 +130,7 @@ static void apply_clk_hack(struct device *dev)
#define TC_EN(1 1)
#define BWR_EN (1 4)
#define BRR_EN (1 5)
+#define CIRQ_EN (1 8)
#define ERR_EN (1 15)
#define CTO_EN (1 16)
#define CCRC_EN (1 17)
@@ -210,6 +211,10 @@ struct omap_hsmmc_host {
int reqs_blocked;
int use_reg;
int req_in_progress;
+ int flags;
+#define HSMMC_RUNTIME_SUSPENDED (1 0)/* Runtime suspended */
+#define HSMMC_SDIO_IRQ_ENABLED (1 1)/* SDIO irq enabled */
+
struct omap_hsmmc_next next_data;
struct omap_mmc_platform_data *pdata;
};
@@ -490,27 +495,40 @@ static void omap_hsmmc_stop_clock(struct
omap_hsmmc_host *host)
static void omap_hsmmc_enable_irq(struct omap_hsmmc_host *host,
struct mmc_command *cmd)
{
- unsigned int irq_mask;
+ u32 irq_mask = INT_EN_MASK;
+ unsigned long flags;
if (host-use_dma)
- irq_mask = INT_EN_MASK ~(BRR_EN | BWR_EN);
- else
- irq_mask = INT_EN_MASK;
+ irq_mask = ~(BRR_EN | BWR_EN);
is this a bugfix ? should it be sent as a separate patch ?
maybe the u32, but otherwise it's just shorter... shall I drop it.
/* Disable timeout for erases */
if (cmd-opcode == MMC_ERASE)
irq_mask = ~DTO_EN;
+ spin_lock_irqsave(host-irq_lock, flags);
why do you need this new locking here ? register acesses are atomic,
right ? If you really do need the locking, should it be a separate patch
as well ?
because host-flags can be accessed from irq context as well
OMAP_HSMMC_WRITE(host-base, STAT, STAT_CLEAR);
OMAP_HSMMC_WRITE(host-base, ISE, irq_mask);
+
+ /* latch pending CIRQ, but don't signal */
+ if (host-flags HSMMC_SDIO_IRQ_ENABLED)
+ irq_mask |= CIRQ_EN;
- imagine sdio irq here -
with the next write we would reenable sdio irq, despite the irq handler
having them disabled
why do you need this ? Looks like it should be yet another patch.
static void omap_hsmmc_disable_irq(struct omap_hsmmc_host *host)
{
- OMAP_HSMMC_WRITE(host-base, ISE, 0);
- OMAP_HSMMC_WRITE(host-base, IE, 0);
+ u32 irq_mask = 0;
+ unsigned long flags;
+
+ spin_lock_irqsave(host-irq_lock, flags);
+ /* no transfer running, need to signal cirq if */
if... ?
+ if (host-flags HSMMC_SDIO_IRQ_ENABLED)
+ irq_mask |= CIRQ_EN;
+ OMAP_HSMMC_WRITE(host-base, ISE, irq_mask);
the whole fiddling with STAT and ISE registers look very bogus to me
(even on current state before this patch). We shouldn't be clearing
pending IRQ events here, right ? We could miss IRQs due to that.
sdio_claim_host excludes multiple users and typical users are using synchronous
communication, issue a transfer, wait till it's done, then release the host.
Hence when we come here, the content of ISE/STAT is a leftover from
the previous transfer.
Probably the intent here is to reset the registers in defined state,
maybe it wasn't needed
but it doesn't hurt either.
It's conservative... I don't like to change it, along the side of my
sdio irq patches.
If I did lots of such changes, surely I would create a regression.
On the other side If I was up to optimize the driver, then I would do this.
@@ -1067,8 +1085,12 @@ static irqreturn_t omap_hsmmc_irq(int irq, void
*dev_id)
int status;
status = OMAP_HSMMC_READ(host-base, STAT);
- while (status INT_EN_MASK host-req_in_progress) {
- omap_hsmmc_do_irq(host, status);
+ while (status (INT_EN_MASK | CIRQ_EN)) {
why don't enable CIRQ_EN in INT_EN_MASK directly ?
INT_EN_MASK is also used when bootstrapping the card in
send_init_stream, but there
you don't want to enable sdio irqs. So I would have to mask it there,
so this is the smaller
change.
Re: [PATCHv9 00/43] ARM: TI SoC clock DT conversion
On 10/25/2013 10:56 AM, Tero Kristo wrote: snip Testing done: - omap3-beagle: boot + suspend/resume (ret + off) - omap4-panda-es: boot + suspend/resume - omap5-uevm: boot - dra7-evm: boot - am335x-bone: boot Test branches available: tree: https://github.com/t-kristo/linux-pm.git snip Fully functioning test branch: 3.12-rc6-dt-clks-v9 ^^ I tested this branch (boot testing): Beagle-XM: http://pastebin.com/50A1qtFq (crashes + clkdm issues, dpll5 failed to transition) Panda-ES: http://pastebin.com/dWMp7D1z (bandgap_fclk not found) OMAP5-UEVM: http://pastebin.com/pHEx6Yzg (omap-gpmc 5000.gpmc: error: clk_get) DRA7-EVM: http://pastebin.com/uYNQ6Sss BeagleBone-Black: http://pastebin.com/biGXS2vi AM335x-evm: http://pastebin.com/K7qwJpCb -- 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 2/4] mmc: omap_hsmmc: Enable SDIO IRQ.
On Oct 5, 2013, at 6:17 AM, Andreas Fenkart wrote:
For now, only support SDIO interrupt if we are booted with
DT. This is because some platforms need special quirks. And
we don't want to add new legacy mux platform init code
callbacks any longer as we are moving to DT based booting
anyways.
Broken hardware, missing the swakueup line, should fallback
to polling, by setting 'ti,quirk-swakup-missing' in the
device tree. Otherwise pending SDIO IRQ are not detected
while in suspend. This affects am33xx processors.
Signed-off-by: Andreas Fenkart afenk...@gmail.com
diff --git a/Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt
b/Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt
index ed271fc..1136e6b 100644
--- a/Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt
+++ b/Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt
@@ -20,6 +20,24 @@ ti,dual-volt: boolean, supports dual voltage cards
ti,non-removable: non-removable slot (like eMMC)
ti,needs-special-reset: Requires a special softreset sequence
ti,needs-special-hs-handling: HSMMC IP needs special setting for handling
High Speed
+ti,quirk-swakup-missing: SOC missing the swakeup line, will not detect
+SDIO irq while in suspend. Fallback to polling. Affected chips are
+am335x,
+
+--
+| PRCM |
+ --
+ ^ |
+ swakeup | | fclk
+ | v
+ ----- -
+ | card | -- CIRQ -- | hsmmc | -- IRQ -- | CPU |
+ ----- -
+
+In suspend the fclk is off and the module is disfunctional. Even
+register reads will fail. A small logic in the host will request fclk
+restore, when an external event is detected. Once the clock is
+restored, the host detects the event normally.
Example:
mmc1: mmc@0x4809c000 {
For the DT-Binding portion:
Acked-by: Kumar Gala ga...@codeaurora.org
- k
--
Employee of Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by
The Linux Foundation
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 0/5] Assorted OMAP2 NAND clean-ups
Hey Pekon, On Fri, Oct 25, 2013 at 08:48:36AM -0300, Ezequiel Garcia wrote: Pekon, On Fri, Oct 25, 2013 at 11:15:57AM +, Gupta, Pekon wrote: Hi, -Original Message- From: Ezequiel Garcia [mailto:ezequiel.gar...@free-electrons.com] [...] Pekon, Brian: Do you think this solution might work for 8-bit and 16-bit devices? I think NAND_BUSWIDTH_AUTO (without GPMC changes) would fail in following scenarios.. Case-1: configuring gpmc,device-width=1 from DT when using x16 device. ... which is wrong. That's why we have a DT property to configure that. The GPMC *must* be properly configured. As your NAND driver is using NAND_BUSWIDTH_AUTO, it should ignore this DT config, and based on ONFI params it should work as x16 Hm.. I don't think so. The auto-stuff is just for the NAND driver, not for the memory controller. I don't know much about hardware, but in my mind I imagine them as different controllers. Case-2: configuring gpmc,device-width=2 from DT when using x8 device. ... which is also wrong. Once again, you're mis-configuring the GPMC. We cannot expect the NAND driver to work properly if the GPMC is not properly initialized, don't you think? Actually having NAND_BUSWIDTH_AUTO would require change in GPMC driver also.. please refer my comments in.. http://lists.infradead.org/pipermail/linux-mtd/2013-October/049284.html Well, I think the approach should be different and much simpler: GPMC *must* be properly configured and then NAND can do ONFI detection starting in 8-bit and then switching to 16-bit if needed. This is what this patch is doing: it _fixes_ the NAND driver ONFI detection, _provided_ the GPMC is well-prepared. You seem to think that GPMC + NAND should be able to automagically detect the device and work, but I don't think that's even physically possible, for the reasons you have just exposed. Sorry to insist: any comments about this? If you have access to the AM335xEVM (which has an 8-bit NAND, as far as I know) and also to the Beaglebone 16-bit NAND cape, then you can test this patchset with all the different combinations: 8-bit vs. 16-bit and array-based vs. ONFI-based detection. If it works, then problem solved. If it doesn't, I'm sure we can find a solution. The driver is currently buggy, so we need to address this sooner or later. In addition, the outcome of our discussion will probably be helpful for other drivers/controllers, since this ONFI issue is likely to be common. If you can do the testing, that would be great: keep in mind that the GPMC must be correctly configured at all times. You can use my recent GPMC patchset for that (which also need some testing). Thanks in advance, -- Ezequiel García, Free Electrons Embedded Linux, Kernel and Android Engineering http://free-electrons.com -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 2/4] mmc: omap_hsmmc: Enable SDIO IRQ.
Hi,
On Tue, Oct 29, 2013 at 04:06:58PM +0100, Andreas Fenkart wrote:
diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
index 94d6dc8..53beac4 100644
--- a/drivers/mmc/host/omap_hsmmc.c
+++ b/drivers/mmc/host/omap_hsmmc.c
@@ -130,6 +130,7 @@ static void apply_clk_hack(struct device *dev)
#define TC_EN(1 1)
#define BWR_EN (1 4)
#define BRR_EN (1 5)
+#define CIRQ_EN (1 8)
#define ERR_EN (1 15)
#define CTO_EN (1 16)
#define CCRC_EN (1 17)
@@ -210,6 +211,10 @@ struct omap_hsmmc_host {
int reqs_blocked;
int use_reg;
int req_in_progress;
+ int flags;
+#define HSMMC_RUNTIME_SUSPENDED (1 0)/* Runtime suspended
*/
+#define HSMMC_SDIO_IRQ_ENABLED (1 1)/* SDIO irq enabled
*/
+
struct omap_hsmmc_next next_data;
struct omap_mmc_platform_data *pdata;
};
@@ -490,27 +495,40 @@ static void omap_hsmmc_stop_clock(struct
omap_hsmmc_host *host)
static void omap_hsmmc_enable_irq(struct omap_hsmmc_host *host,
struct mmc_command *cmd)
{
- unsigned int irq_mask;
+ u32 irq_mask = INT_EN_MASK;
+ unsigned long flags;
if (host-use_dma)
- irq_mask = INT_EN_MASK ~(BRR_EN | BWR_EN);
- else
- irq_mask = INT_EN_MASK;
+ irq_mask = ~(BRR_EN | BWR_EN);
is this a bugfix ? should it be sent as a separate patch ?
maybe the u32, but otherwise it's just shorter... shall I drop it.
no, now I saw what you did ;-)
/* Disable timeout for erases */
if (cmd-opcode == MMC_ERASE)
irq_mask = ~DTO_EN;
+ spin_lock_irqsave(host-irq_lock, flags);
why do you need this new locking here ? register acesses are atomic,
right ? If you really do need the locking, should it be a separate patch
as well ?
because host-flags can be accessed from irq context as well
fair point :-)
static void omap_hsmmc_disable_irq(struct omap_hsmmc_host *host)
{
- OMAP_HSMMC_WRITE(host-base, ISE, 0);
- OMAP_HSMMC_WRITE(host-base, IE, 0);
+ u32 irq_mask = 0;
+ unsigned long flags;
+
+ spin_lock_irqsave(host-irq_lock, flags);
+ /* no transfer running, need to signal cirq if */
if... ?
+ if (host-flags HSMMC_SDIO_IRQ_ENABLED)
+ irq_mask |= CIRQ_EN;
+ OMAP_HSMMC_WRITE(host-base, ISE, irq_mask);
the whole fiddling with STAT and ISE registers look very bogus to me
(even on current state before this patch). We shouldn't be clearing
pending IRQ events here, right ? We could miss IRQs due to that.
sdio_claim_host excludes multiple users and typical users are using
synchronous
communication, issue a transfer, wait till it's done, then release the host.
Hence when we come here, the content of ISE/STAT is a leftover from
the previous transfer.
Probably the intent here is to reset the registers in defined state,
maybe it wasn't needed
but it doesn't hurt either.
It's conservative... I don't like to change it, along the side of my
sdio irq patches.
If I did lots of such changes, surely I would create a regression.
On the other side If I was up to optimize the driver, then I would do this.
sure, that was an unrelated comment, just exposing some possible problem
with that approach :-)
@@ -1067,8 +1085,12 @@ static irqreturn_t omap_hsmmc_irq(int irq, void
*dev_id)
int status;
status = OMAP_HSMMC_READ(host-base, STAT);
- while (status INT_EN_MASK host-req_in_progress) {
- omap_hsmmc_do_irq(host, status);
+ while (status (INT_EN_MASK | CIRQ_EN)) {
why don't enable CIRQ_EN in INT_EN_MASK directly ?
INT_EN_MASK is also used when bootstrapping the card in
send_init_stream, but there
you don't want to enable sdio irqs. So I would have to mask it there,
so this is the smaller
change.
true, fair enough.
--
balbi
signature.asc
Description: Digital signature
Re: [PATCHv9 05/43] CLK: TI: add DT alias clock registration mechanism
On Fri, Oct 25, 2013 at 10:56 AM, Tero Kristo t-kri...@ti.com wrote:
Some devices require their clocks to be available with a specific
dev-id con-id mapping. With DT, the clocks can be found by default
only with their name, or alternatively through the device node of
the consumer. With drivers, that don't support DT fully yet, add
mechanism to register specific clock names.
Signed-off-by: Tero Kristo t-kri...@ti.com
Tested-by: Nishanth Menon n...@ti.com
Acked-by: Tony Lindgren t...@atomide.com
You guys are wonderful, by the way ;)
+void __init ti_dt_clocks_register(struct ti_dt_clk oclks[])
+{
+ struct ti_dt_clk *c;
+ struct device_node *node;
+ struct clk *clk;
+ struct of_phandle_args clkspec;
+
+ for (c = oclks; c-node_name != NULL; c++) {
+ node = of_find_node_by_name(NULL, c-node_name);
+ clkspec.np = node;
+ clk = of_clk_get_from_provider(clkspec);
+
+ if (!IS_ERR(clk)) {
+ c-lk.clk = clk;
+ clkdev_add(c-lk);
+ } else {
+ pr_warn(%s: failed to lookup clock node %s\n,
+ __func__, c-node_name);
+ }
+ }
+}
I have one question here, what makes this part of the patch
TI-specific at all except the definition of the structure ti_dt_clk?
Mapping DT clocks to generic clkdev legacy namings seems like it would
be a necessary evil across *all* SoC platforms.
I would say there is a good case for this being generic and used by
all platforms waiting for con-id/dev-id to be moved to DT-awareness,
the structure itself is very generic within clkdev as long as the
drivers conformed anyway (and if they didn't, none of this helps) and
I don't think it really needs to be a TI-only thing. The next thing
that's going to happen when another platform arrives that wants to do
the same thing is duplication or consolidation - so it would probably
be a good idea to make this generic to start.
While there the names could be a bit more descriptive -
dt_clk_name_lookup_map_register(), struct dt_clk_name_lookup_map,
DT_CLK_LOOKUP_MAP() ..? The current namespace makes it look like this
is the absolute correct thing to do under all circumstances, but in
fact this is purely for mapping the old way to the new, better way..
in the event a brand new platform arrives, with all new drivers (or
only compliant drivers), none of this code should be implemented for
it and it should be presented this way.
Thanks,
Matt Sealey n...@bakuhatsu.net
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH v2 0/5] Assorted OMAP2 NAND clean-ups
Hi Ezequiel Garcia, Sorry I'm bit out of my place.. so not able to sync often with mails.. However plz see my replies below.. [...] Pekon, Brian: Do you think this solution might work for 8-bit and 16-bit devices? I think NAND_BUSWIDTH_AUTO (without GPMC changes) would fail in following scenarios.. Case-1: configuring gpmc,device-width=1 from DT when using x16 device. ... which is wrong. That's why we have a DT property to configure that. The GPMC *must* be properly configured. No, I think the main intention of using NAND_BUSWIDTH_AUTO is that your controller should not depend on DT or any other user-input to detect NAND bus-width, (whether its gpmc,device-width or anything else). As your NAND driver is using NAND_BUSWIDTH_AUTO, it should ignore this DT config, and based on ONFI params it should work as x16 Hm.. I don't think so. The auto-stuff is just for the NAND driver, not for the memory controller. I don't know much about hardware, but in my mind I imagine them as different controllers. TI's GPMC hardware engine can do much more than supporting only NAND devices, therefore there is an independent GPMC driver, and dependent NAND driver. So when a NAND device is connected all GPMC driver does is initializes GPMC hardware based on static DT bindings, and pass the control to NAND driver. But there should be a mechanism to override these static DT configurations done in GPMC driver by NAND driver. (it is this piece which is missing today). Case-2: configuring gpmc,device-width=2 from DT when using x8 device. ... which is also wrong. Once again, you're mis-configuring the GPMC. We cannot expect the NAND driver to work properly if the GPMC is not properly initialized, don't you think? Actually having NAND_BUSWIDTH_AUTO would require change in GPMC driver also.. please refer my comments in.. http://lists.infradead.org/pipermail/linux-mtd/2013-October/049284.html Well, I think the approach should be different and much simpler: GPMC *must* be properly configured and then NAND can do ONFI detection starting in 8-bit and then switching to 16-bit if needed. This is what this patch is doing: it _fixes_ the NAND driver ONFI detection, _provided_ the GPMC is well-prepared. You seem to think that GPMC + NAND should be able to automagically detect the device and work, but I don't think that's even physically possible, for the reasons you have just exposed. I think this fix is simple enough. No, I still think there should be a way to tell the user that there is a mis-match between bus-width configured in DT, and that detected by ONFI probe. If it was straight forward, this would have been already accepted earlier :-) http://lists.infradead.org/pipermail/linux-mtd/2013-October/049154.html (read the comments from Brian by following above patch thread) Problem is if there is a mis-match in your bus-width due to incorrect GPMC DT binding configurations, still NAND probe and everything will pass correctly, because nand_scan_ident() uses read_byte() which returns same for both x8 and x16 devices. You will find issues when you actually do page reads and writes. And this is where you would see corrupted half-page data. And user would be clueless on why he is seeing such erratic behavior. This is why I added checks for mismatch of DT binding right during nand probe(), in above mentioned patch. I could just remove calling nand_scan_ident() second-time and it becomes your patch, but then it would be just validating the DT setting, not pure auto-detection. BTW: The GPMC code ignores the DT value in 'gpmc,device-width' and uses 'nand-bus-width' instead, but that's a different bug and a different fix :) I think you mean the opposie.. GPMC driver uses gpmc,device-width.. Refer: $KERNEL/arch/arm/mach-omap2/gpmc.c @@gpmc_read_settings_dt(...) of_property_read_u32(np, gpmc,device-width, p-device_width); 'nand-bus-width' is not used anywhere instead.. with regards, pekon
Re: [PATCHv3 6/8] ARM: dts: OMAP4: Add hwspinlock node
* Tony Lindgren t...@atomide.com [131011 16:49]: * Suman Anna s-a...@ti.com [131010 14:24]: Add the hwspinlock device tree node for OMAP4 family of SoCs. Suman, can you please post the .dts changes separately from the driver changes next time so driver maintainers don't accidentally pick them up. That leads to unnecessary merge conflicts with the .dts files. Actually I'll pick patches 6 - 8 of this series into omap-for-v3.13/dt branch as that fixes some boot time warnings we're seeing without them. 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: [RESEND PATCH V2 1/2] ARM: dts: AM33xx: Add RNG node
* Lokesh Vutla lokeshvu...@ti.com [131016 04:16]:
+ Rob and Mark
On Tuesday 15 October 2013 12:19 PM, Benoit Cousson wrote:
Hi Lokesh,
On 12/10/2013 15:26, Lokesh Vutla wrote:
Hi Benoit,
On Thursday 29 August 2013 06:22 PM, Lokesh Vutla wrote:
Add the AM33xx RNG module's device tree data.
Also add Documentation file describing the data
for the RNG module.
Can you please review this patch..
OK enough of waiting here, I'm picking this patch into
omap-for-v3.13/dt branch as it removes some boot time warnings
we're seeing.
Regards,
Tony
Thanks and regards,
Lokesh
Seems you missed this patch. Please consider this for this merge window.
Indeed I missed it. Sorry :-(
Patch 2/2 is already taken by Paul.
Without this patch AM335x boot will crash as I mentioned in my cover
letter.
Thanks and regards,
Lokesh
Signed-off-by: Lokesh Vutla lokeshvu...@ti.com
---
Changes since V1:
- Drop status=disabled entry in dt node, Since
RNG is present on all AM33xx platforms.
.../devicetree/bindings/hwrng/omap_rng.txt | 22
arch/arm/boot/dts/am33xx.dtsi |7 +++
2 files changed, 29 insertions(+)
create mode 100644 Documentation/devicetree/bindings/hwrng/omap_rng.txt
I do not see the acked-by for the binding part. You do need that for any
new bindings nowadays.
diff --git a/Documentation/devicetree/bindings/hwrng/omap_rng.txt
b/Documentation/devicetree/bindings/hwrng/omap_rng.txt
new file mode 100644
index 000..6a62acd
--- /dev/null
+++ b/Documentation/devicetree/bindings/hwrng/omap_rng.txt
@@ -0,0 +1,22 @@
+OMAP SoC HWRNG Module
+
+Required properties:
+
+- compatible : Should contain entries for this and backward compatible
+ RNG versions:
+ - ti,omap2-rng for OMAP2.
+ - ti,omap4-rng for OMAP4, OMAP5 and AM33XX.
+ Note that these two versions are incompatible.
+- ti,hwmods: Name of the hwmod associated with the RNG module
+- reg : Offset and length of the register set for the module
+- interrupts : the interrupt number for the RNG module.
+Only used for ti,omap4-rng.
+
+Example:
+/* AM335x */
+rng: rng@4831 {
+compatible = ti,omap4-rng;
+ti,hwmods = rng;
+reg = 0x4831 0x2000;
+interrupts = 111;
+};
diff --git a/arch/arm/boot/dts/am33xx.dtsi b/arch/arm/boot/dts/am33xx.dtsi
index 38b446b..26ebe30 100644
--- a/arch/arm/boot/dts/am33xx.dtsi
+++ b/arch/arm/boot/dts/am33xx.dtsi
@@ -530,5 +530,12 @@
#size-cells = 1;
status = disabled;
};
+
+rng: rng@4831 {
+compatible = ti,omap4-rng;
+ti,hwmods = rng;
+reg = 0x4831 0x2000;
+interrupts = 111;
+};
};
};
It looks good to me, but it does not apply on my branch.
Please rebase it and repost with the proper acked-by.
Thanks,
Benoit
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH/RFC] pwm: omap: Add PWM support using dual-mode timers
* NeilBrown ne...@suse.de [131023 23:36]: I submitted this in December last year. I got lots of good feedback and fixed some things, but it never got accepted. Not entirely sure why, maybe I dropped the ball. Anyway, here is again with device-tree support added. This is only an RFC and not a real submission for two reasons, both of which are really directed as Jon. 1/ I have to #include ../arch/arm/plat-omap/include/plat/dmtimer.h which is incredibly ugly. Is there any reason this cannot be moved to include/linux/omap-dmtimer.h? Yes that's what at least dw_apb_timer and sh_timer are doing. 2/ I found that I need to call omap_dm_timer_write_counter(omap-dm_timer, DM_TIMER_LOAD_MIN); when using device-tree. This is because with devicetree omap_timer_restore_context() is called much more often and it sets the counter register to 0 .. it takes a long time to count up to DM_TIMER_LOAD_MIN from there. Now I don't object to calling omap_dm_timer_write_counter (though it might be nice if omap_dm_timer_set_load wrote the one value to both LOAD_REG and COUNTER_REG). However it seems wrong that I have to call it *after* starting the counter. Currently _write_counter refuses to run if the timer hasn't been started. So Jon: a/ can we change omap_dm_timer_write_counter to work when the timer isn't running? b/ can we have omap_dm_timer_set_load also set the counter? For anyone else generous enough to read my code: is this otherwise acceptable? Did not look beyond the dmtimer stuff, but let's start by moving dmtimer.c to live under drivers and move the header, then do the pwm patches. If there's a bug with the omap_dm_timer_set_load(), then naturally that should be done separately as a fix before anything. Regards, Tony -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/3] ARM: dts: omap4-panda: add DPI pinmuxing
* Tomi Valkeinen tomi.valkei...@ti.com [131029 03:16]: Hi Tony, On 25/10/13 13:07, Tomi Valkeinen wrote: New u-boot versions no longer set the pinmuxing for Panda's DPI output, and the muxing has to be done in the .dts file. Add pinmuxing for DPI and TFP410. Without these, the DVI output on Panda does not work with recent u-boot. Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com The two latter patches in this series needs more work and can be dropped, but this one should be applied to make Panda work properly with new u-boots. OK I'll pick this patch into omap-for-v3.13/dt. 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
[PATCH v3] omapdss: Add new panel driver for Topolly td028ttec1 LCD.
Signed-off-by: Marek Belisko ma...@goldelico.com
Signed-off-by: H. Nikolaus Schaller h...@goldelico.com
---
changes from v2:
- move tx_buf from driver data to functions where it's used
- update write functions names (to reflect how many bytes are transferred)
- update delays from 1s to 1ms (probably typo)
- remove unnecessary 90ms sleep (tested and works fine)
- disable dpi output after disable panel
changes from v1:
- reworked to be spi driver instead platform with custom spi bitbang
this configuration was tested with spi_gpio bitbang driver on gta04 board
and works fine (thanks Tomi and Lars-Peter for comments)
- address previous comments
drivers/video/omap2/displays-new/Kconfig | 6 +
drivers/video/omap2/displays-new/Makefile | 1 +
.../omap2/displays-new/panel-tpo-td028ttec1.c | 480 +
include/video/omap-panel-data.h| 13 +
4 files changed, 500 insertions(+)
create mode 100644 drivers/video/omap2/displays-new/panel-tpo-td028ttec1.c
diff --git a/drivers/video/omap2/displays-new/Kconfig
b/drivers/video/omap2/displays-new/Kconfig
index 10b25e7..e6cfc38 100644
--- a/drivers/video/omap2/displays-new/Kconfig
+++ b/drivers/video/omap2/displays-new/Kconfig
@@ -57,6 +57,12 @@ config DISPLAY_PANEL_SHARP_LS037V7DW01
help
LCD Panel used in TI's SDP3430 and EVM boards
+config DISPLAY_PANEL_TPO_TD028TTEC1
+tristate TPO TD028TTEC1 LCD Panel
+depends on SPI
+help
+ LCD panel used in Openmoko.
+
config DISPLAY_PANEL_TPO_TD043MTEA1
tristate TPO TD043MTEA1 LCD Panel
depends on SPI
diff --git a/drivers/video/omap2/displays-new/Makefile
b/drivers/video/omap2/displays-new/Makefile
index 5aeb11b..0323a8a 100644
--- a/drivers/video/omap2/displays-new/Makefile
+++ b/drivers/video/omap2/displays-new/Makefile
@@ -8,5 +8,6 @@ obj-$(CONFIG_DISPLAY_PANEL_DSI_CM) += panel-dsi-cm.o
obj-$(CONFIG_DISPLAY_PANEL_SONY_ACX565AKM) += panel-sony-acx565akm.o
obj-$(CONFIG_DISPLAY_PANEL_LGPHILIPS_LB035Q02) += panel-lgphilips-lb035q02.o
obj-$(CONFIG_DISPLAY_PANEL_SHARP_LS037V7DW01) += panel-sharp-ls037v7dw01.o
+obj-$(CONFIG_DISPLAY_PANEL_TPO_TD028TTEC1) += panel-tpo-td028ttec1.o
obj-$(CONFIG_DISPLAY_PANEL_TPO_TD043MTEA1) += panel-tpo-td043mtea1.o
obj-$(CONFIG_DISPLAY_PANEL_NEC_NL8048HL11) += panel-nec-nl8048hl11.o
diff --git a/drivers/video/omap2/displays-new/panel-tpo-td028ttec1.c
b/drivers/video/omap2/displays-new/panel-tpo-td028ttec1.c
new file mode 100644
index 000..ca77721
--- /dev/null
+++ b/drivers/video/omap2/displays-new/panel-tpo-td028ttec1.c
@@ -0,0 +1,480 @@
+/*
+ * Toppoly TD028TTEC1 panel support
+ *
+ * Copyright (C) 2008 Nokia Corporation
+ * Author: Tomi Valkeinen tomi.valkei...@nokia.com
+ *
+ * Neo 1973 code (jbt6k74.c):
+ * Copyright (C) 2006-2007 by OpenMoko, Inc.
+ * Author: Harald Welte lafo...@openmoko.org
+ *
+ * Ported and adapted from Neo 1973 U-Boot by:
+ * H. Nikolaus Schaller h...@goldelico.com
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License version 2 as published by
+ * the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful, but WITHOUT
+ * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for
+ * more details.
+ *
+ * You should have received a copy of the GNU General Public License along with
+ * this program. If not, see http://www.gnu.org/licenses/.
+ */
+
+#include linux/module.h
+#include linux/delay.h
+#include linux/spi/spi.h
+#include linux/gpio.h
+#include video/omapdss.h
+#include video/omap-panel-data.h
+
+struct panel_drv_data {
+ struct omap_dss_device dssdev;
+ struct omap_dss_device *in;
+
+ int data_lines;
+
+ struct omap_video_timings videomode;
+
+ struct spi_device *spi_dev;
+};
+
+static struct omap_video_timings td028ttec1_panel_timings = {
+ .x_res = 480,
+ .y_res = 640,
+ .pixel_clock= 22153,
+ .hfp= 24,
+ .hsw= 8,
+ .hbp= 8,
+ .vfp= 4,
+ .vsw= 2,
+ .vbp= 2,
+
+ .vsync_level= OMAPDSS_SIG_ACTIVE_LOW,
+ .hsync_level= OMAPDSS_SIG_ACTIVE_LOW,
+
+ .data_pclk_edge = OMAPDSS_DRIVE_SIG_FALLING_EDGE,
+ .de_level = OMAPDSS_SIG_ACTIVE_HIGH,
+ .sync_pclk_edge = OMAPDSS_DRIVE_SIG_OPPOSITE_EDGES,
+};
+
+#define JBT_COMMAND0x000
+#define JBT_DATA 0x100
+
+int jbt_ret_write_0(struct panel_drv_data *ddata, u8 reg)
+{
+ int rc;
+ u16 tx_buf = JBT_COMMAND | reg;
+
+ rc = spi_write(ddata-spi_dev, (u8 *)tx_buf,
+ 1*sizeof(u16));
+ if (rc != 0)
+ dev_err(ddata-spi_dev-dev,
+ jbt_ret_write_0 spi_write ret %d\n, rc);
+
+
[PATCH] crypto: omap-aes: Fix CTR mode counter length
NIST vectors for CTR mode in testmgr.h assume the entire IV as the counter. To
get correct results that match the output of these vectors, we need to set the
counter length correctly.
Signed-off-by: Joel Fernandes jo...@ti.com
---
drivers/crypto/omap-aes.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/crypto/omap-aes.c b/drivers/crypto/omap-aes.c
index ce791c2..19055a1 100644
--- a/drivers/crypto/omap-aes.c
+++ b/drivers/crypto/omap-aes.c
@@ -275,7 +275,7 @@ static int omap_aes_write_ctrl(struct omap_aes_dev *dd)
if (dd-flags FLAGS_CBC)
val |= AES_REG_CTRL_CBC;
if (dd-flags FLAGS_CTR) {
- val |= AES_REG_CTRL_CTR | AES_REG_CTRL_CTR_WIDTH_32;
+ val |= AES_REG_CTRL_CTR | AES_REG_CTRL_CTR_WIDTH_128;
mask = AES_REG_CTRL_CTR | AES_REG_CTRL_CTR_WIDTH_MASK;
}
if (dd-flags FLAGS_ENCRYPT)
--
1.8.1.2
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[GIT PULL] omap dt fixes for v3.13 merge window
The following changes since commit b4887e16375be312cf64642ac1d826186cb836bf: Merge tag 'for_3.13_super_late/dts_signed' of git://git.kernel.org/pub/scm/linux/kernel/git/bcousson/linux-omap-dt into omap-for-v3.13/dt (2013-10-23 03:12:45 -0700) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap tags/omap-for-v3.13/dt-fixes-for-merge-window for you to fetch changes up to 0352bd1f04b706904b26d13f6d8792e7ff6b7eb6: ARM: dts: omap4-panda: add DPI pinmuxing (2013-10-29 14:24:34 -0700) Few device tree changes that fix boot time warnings and make panda display work with recent u-boot. Lokesh Vutla (1): ARM: dts: AM33xx: Add RNG node Suman Anna (3): ARM: dts: OMAP4: Add hwspinlock node ARM: dts: OMAP5: Add hwspinlock node ARM: dts: AM33XX: Add hwspinlock node Tomi Valkeinen (1): ARM: dts: omap4-panda: add DPI pinmuxing .../devicetree/bindings/hwrng/omap_rng.txt | 22 +++ arch/arm/boot/dts/am33xx.dtsi | 13 +++ arch/arm/boot/dts/omap4-panda-common.dtsi | 43 ++ arch/arm/boot/dts/omap4.dtsi | 6 +++ arch/arm/boot/dts/omap5.dtsi | 6 +++ 5 files changed, 90 insertions(+) create mode 100644 Documentation/devicetree/bindings/hwrng/omap_rng.txt -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [GIT PULL] omap dt fixes for v3.13 merge window
On Tue, Oct 29, 2013 at 4:09 PM, Tony Lindgren t...@atomide.com wrote: The following changes since commit b4887e16375be312cf64642ac1d826186cb836bf: Merge tag 'for_3.13_super_late/dts_signed' of git://git.kernel.org/pub/scm/linux/kernel/git/bcousson/linux-omap-dt into omap-for-v3.13/dt (2013-10-23 03:12:45 -0700) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap tags/omap-for-v3.13/dt-fixes-for-merge-window for you to fetch changes up to 0352bd1f04b706904b26d13f6d8792e7ff6b7eb6: ARM: dts: omap4-panda: add DPI pinmuxing (2013-10-29 14:24:34 -0700) Pulled, thanks. -Olof -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RESEND PATCH V2 1/2] ARM: dts: AM33xx: Add RNG node
On Aug 29, 2013, at 7:52 AM, Lokesh Vutla wrote:
Add the AM33xx RNG module's device tree data.
Also add Documentation file describing the data
for the RNG module.
Signed-off-by: Lokesh Vutla lokeshvu...@ti.com
---
Changes since V1:
- Drop status=disabled entry in dt node, Since
RNG is present on all AM33xx platforms.
.../devicetree/bindings/hwrng/omap_rng.txt | 22
arch/arm/boot/dts/am33xx.dtsi |7 +++
2 files changed, 29 insertions(+)
create mode 100644 Documentation/devicetree/bindings/hwrng/omap_rng.txt
diff --git a/Documentation/devicetree/bindings/hwrng/omap_rng.txt
b/Documentation/devicetree/bindings/hwrng/omap_rng.txt
new file mode 100644
index 000..6a62acd
--- /dev/null
+++ b/Documentation/devicetree/bindings/hwrng/omap_rng.txt
@@ -0,0 +1,22 @@
+OMAP SoC HWRNG Module
+
+Required properties:
+
+- compatible : Should contain entries for this and backward compatible
+ RNG versions:
+ - ti,omap2-rng for OMAP2.
+ - ti,omap4-rng for OMAP4, OMAP5 and AM33XX.
+ Note that these two versions are incompatible.
+- ti,hwmods: Name of the hwmod associated with the RNG module
+- reg : Offset and length of the register set for the module
+- interrupts : the interrupt number for the RNG module.
+ Only used for ti,omap4-rng.
+
+Example:
+/* AM335x */
+rng: rng@4831 {
+ compatible = ti,omap4-rng;
+ ti,hwmods = rng;
+ reg = 0x4831 0x2000;
+ interrupts = 111;
+};
For the DT-Binding portion:
Acked-by: Kumar Gala ga...@codeaurora.org
- k
--
Employee of Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by
The Linux Foundation
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 0/5] Assorted OMAP2 NAND clean-ups
Hey Pekon,
On Tue, Oct 29, 2013 at 08:14:34PM +, Gupta, Pekon wrote:
Sorry I'm bit out of my place.. so not able to sync often with mails..
However plz see my replies below..
Sure, no problem. Thanks for taking the time to discuss this!
[..]
You seem to think that GPMC + NAND should be able to automagically detect
the device and work, but I don't think that's even physically possible, for
the reasons you have just exposed.
I think this fix is simple enough.
No, I still think there should be a way to tell the user that there is a
mis-match between bus-width configured in DT, and that detected
by ONFI probe. If it was straight forward, this would have been already
accepted earlier :-)
http://lists.infradead.org/pipermail/linux-mtd/2013-October/049154.html
(read the comments from Brian by following above patch thread)
Hmm... Well, I think your whole point of view is:
1. Mixing what's NAND controller and what's GPMC controller.
They are two different controllers, which means two different
drivers, and different parameters.
So from this perspective, trying to 'fix' GPMC configuration
from the NAND driver is a completely bad idea.
2. Trying to over-report the status to the user. The GPMC _must_
be properly configured before anything else. These NAND aren't plug
and play, so the 'user' knows the bus width anyway. If the user
has misconfigured the GPMC, then it's fine for things to not work.
Keep in mind the DT is not a configuration tool, but rather it's a
way to describe hardware. So, hardware parameters as bus width needs
to be properly described.
I've followed the above patch and, as far as I can read, Brian says: (quoting)
My opinion: the platform- and device-tree-provided buswidth is
unnecessary; it was previouisly only a suggestion which your driver
would readily discard, and it isn't really needed now. You can probably
get by with just NAND_BUSWIDTH_AUTO and (at most) a warning if the
auto-configured buswidth is different than the platform specified.
But the real point: you need to clearly communicate what you are
choosing in this patch. Either you want to
(1) strictly follow the buswidth provided by the platform or
(2) use the nand_base.c BUSWIDTH_AUTO automatic configuration.
Trying to mix both (as your patch currently does) just makes
everything worse.
Note that, in the above, Brian is talking about the NAND buswidth,
(not the GPMC). As he suggests, the proper thing to do is to simply
use BUSWIDTH_AUTO and discard any other parameter.
BTW: The GPMC code ignores the DT value in 'gpmc,device-width' and uses
'nand-bus-width' instead, but that's a different bug and a different fix :)
I think you mean the opposie.. GPMC driver uses gpmc,device-width..
Refer: $KERNEL/arch/arm/mach-omap2/gpmc.c
@@gpmc_read_settings_dt(...)
of_property_read_u32(np, gpmc,device-width, p-device_width);
'nand-bus-width' is not used anywhere instead..
No, I meant just that: the current GPMC driver _ignores_ the DT value for
gpmc,device-width and overrides it with the 'nand-bus-width'.
See below for a stripped version of gpmc_nand_init():
int gpmc_nand_init(struct omap_nand_platform_data *gpmc_nand_data,
struct gpmc_timings *gpmc_t)
{
[...]
if (gpmc_nand_data-of_node) {
gpmc_read_settings_dt(gpmc_nand_data-of_node, s);
} else {
/* */
}
s.device_nand = true;
if (gpmc_nand_data-devsize == NAND_BUSWIDTH_16)
s.device_width = GPMC_DEVWIDTH_16BIT;
else
s.device_width = GPMC_DEVWIDTH_8BIT;
}
The code first reads 'device_width' from gpmc_read_settings_dt(), and then
overrides it with the NAND buswidth value! Once again, the above repeats
the 'mixing parameter' scheme you are suggesting.
(I've already submitted a patchset fixing this. See here:
http://www.spinics.net/lists/arm-kernel/msg282594.html)
I think our current discussion can be summarized as this:
* Should we fix the GPMC buswidth configuration, using the
auto-detected NAND buswidth?
IMO, the answer is NO!, as it results in fucked-up design.
But it's a _design_ choice, there's no technical reason why you can't
export some GPMC configuration function and call it from the driver.
--
Ezequiel García, Free Electrons
Embedded Linux, Kernel and Android Engineering
http://free-electrons.com
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v11 00/10] [PATCH v10 00/10] mtd:nand:omap2: clean-up of supported ECC schemes
On Thu, Oct 24, 2013 at 9:52 AM, Ezequiel Garcia ezequiel.gar...@free-electrons.com wrote: Just as suggestion, I think you should reconsider your 'upstream strategy'. On Thu, Oct 24, 2013 at 06:20:16PM +0530, Pekon Gupta wrote: [..] Pekon Gupta (10): ARM: OMAP2+: cleaned-up DT support of various ECC schemes mtd: nand: omap: combine different flavours of 1-bit hamming ecc schemes mtd: nand: omap: cleanup: replace local references with generic framework names IMHO, this patch about the dobule nand_scan_ident(): mtd: nand: omap: use DT specified bus-width only for scanning NAND device is a fix unrelated to this series and can be pushed independently. Maybe you can try to send it as a one-patch fix? mtd:nand:omap2: clean-up BCHx_HW and BCHx_SW ECC configurations in device_probe mtd: nand: omap: clean-up ecc layout for BCH ecc schemes mtd: nand: omap: use drivers/mtd/nand/nand_bch.c wrapper for BCH ECC instead of lib/bch.c ARM: dts: AM33xx: updated default ECC scheme in nand-ecc-opt And also this patch: mtd: nand: omap: updated devm_xx for all resource allocation and free calls doesn't seem to belong to this series. I think tou could send those two independently and ask Brian to merge them earlier if appropriate. But again, this is just a suggestion. I agree with Ezequiel's thoughts, since the excessive amount of noise in this patch series has delayed it significantly. But at this point, I think it has stabilized; we have reviews from the DT folks (thanks guys; please comment if you have an official ack to give), and I think we've retained backwards compatibility properly; I've combed through it a few times over the months; we have a third-party tester; and at this point, I'm sure we're all sick of this. So, without further delay: pushed all patches except path 8 to l2-mtd.git. Tony, you mentioned the DTS update in patch 8 going in via an ARM tree? This patch is not urgent, and it should probably wait until we know what release the rest of the series makes it into. This may depend on David Woodhouse's recommendation, but I'm not sure this series will have enough time baking in linux-next before entering mainline in 3.13 (the merge window is approaching). Pekon/Ezequiel/others: please feel free to send any follow up cleanups for this driver. I'll take a look at what Ezequiel has already sent out and see if it's still applicable on top. Thanks, Brian -- To unsubscribe from this list: send the line unsubscribe 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] crypto: omap-aes: Fix CTR mode counter length
On Tue, Oct 29, 2013 at 05:37:38PM -0500, Joel Fernandes wrote: NIST vectors for CTR mode in testmgr.h assume the entire IV as the counter. To get correct results that match the output of these vectors, we need to set the counter length correctly. Signed-off-by: Joel Fernandes jo...@ti.com Patch applied. Thanks! -- Email: Herbert Xu herb...@gondor.apana.org.au Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] ARM: OMAP3: Beagle: fix return value check in beagle_opp_init()
From: Wei Yongjun yongjun_...@trendmicro.com.cn
In case of error, the function get_cpu_device() returns NULL pointer
not ERR_PTR(). The IS_ERR() test in the return value check should be
replaced with NULL test.
Signed-off-by: Wei Yongjun yongjun_...@trendmicro.com.cn
---
arch/arm/mach-omap2/board-omap3beagle.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/mach-omap2/board-omap3beagle.c
b/arch/arm/mach-omap2/board-omap3beagle.c
index a516c1b..d6ed819 100644
--- a/arch/arm/mach-omap2/board-omap3beagle.c
+++ b/arch/arm/mach-omap2/board-omap3beagle.c
@@ -510,7 +510,7 @@ static int __init beagle_opp_init(void)
mpu_dev = get_cpu_device(0);
iva_dev = omap_device_get_by_hwmod_name(iva);
- if (IS_ERR(mpu_dev) || IS_ERR(iva_dev)) {
+ if (!mpu_dev || IS_ERR(iva_dev)) {
pr_err(%s: Aiee.. no mpu/dsp devices? %p %p\n,
__func__, mpu_dev, iva_dev);
return -ENODEV;
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
