[PATCH 4/4] ARM: dts: Add LCD panel sharp ls037v7dw01 support for omap3-evm and ldp
From: Tony Lindgren t...@atomide.com
Looks like quite a few omap3 boards have sharp ls037v7dw01 that's
configured as various panel dpi entries for whatever legacy reasons.
For device tree based support, let's just configure these properly for
panel ls037v7dw01 instead of panel dpi.
This patch creates a common file for panel ls037v7dw01, and makes
boards ldp and omap3-evm to use it.
The ls037v7dw01 also seems to be coupled with an ad7846 touchscreen
controller for the omaps, so let's add a basic configuration for
the touchscreen also using the default values.
Note that we can now remove the regulator-name = vdds_dsi
entry for ldp, that's no longer needed as we have the entry
for vdds_dsi-supply = vpll2.
Signed-off-by: Tony Lindgren t...@atomide.com
---
arch/arm/boot/dts/omap3-evm-37xx.dts | 50
arch/arm/boot/dts/omap3-evm-common.dtsi| 26 +
arch/arm/boot/dts/omap3-ldp.dts| 29 --
.../boot/dts/omap3-panel-sharp-ls037v7dw01.dtsi| 67 ++
4 files changed, 167 insertions(+), 5 deletions(-)
create mode 100644 arch/arm/boot/dts/omap3-panel-sharp-ls037v7dw01.dtsi
diff --git a/arch/arm/boot/dts/omap3-evm-37xx.dts
b/arch/arm/boot/dts/omap3-evm-37xx.dts
index 4df68ad3736a..a181e30daaef 100644
--- a/arch/arm/boot/dts/omap3-evm-37xx.dts
+++ b/arch/arm/boot/dts/omap3-evm-37xx.dts
@@ -26,7 +26,44 @@
};
};
+dss {
+ pinctrl-names = default;
+ pinctrl-0 =
+ dss_dpi_pins1
+ dss_dpi_pins2
+ ;
+};
+
omap3_pmx_core {
+ dss_dpi_pins1: pinmux_dss_dpi_pins2 {
+ pinctrl-single,pins =
+ OMAP3_CORE1_IOPAD(0x20d4, PIN_OUTPUT | MUX_MODE0) /*
dss_pclk.dss_pclk */
+ OMAP3_CORE1_IOPAD(0x20d6, PIN_OUTPUT | MUX_MODE0) /*
dss_hsync.dss_hsync */
+ OMAP3_CORE1_IOPAD(0x20d8, PIN_OUTPUT | MUX_MODE0) /*
dss_vsync.dss_vsync */
+ OMAP3_CORE1_IOPAD(0x20da, PIN_OUTPUT | MUX_MODE0) /*
dss_acbias.dss_acbias */
+
+ OMAP3_CORE1_IOPAD(0x20e8, PIN_OUTPUT | MUX_MODE0) /*
dss_data6.dss_data6 */
+ OMAP3_CORE1_IOPAD(0x20ea, PIN_OUTPUT | MUX_MODE0) /*
dss_data7.dss_data7 */
+ OMAP3_CORE1_IOPAD(0x20ec, PIN_OUTPUT | MUX_MODE0) /*
dss_data8.dss_data8 */
+ OMAP3_CORE1_IOPAD(0x20ee, PIN_OUTPUT | MUX_MODE0) /*
dss_data9.dss_data9 */
+ OMAP3_CORE1_IOPAD(0x20f0, PIN_OUTPUT | MUX_MODE0) /*
dss_data10.dss_data10 */
+ OMAP3_CORE1_IOPAD(0x20f2, PIN_OUTPUT | MUX_MODE0) /*
dss_data11.dss_data11 */
+ OMAP3_CORE1_IOPAD(0x20f4, PIN_OUTPUT | MUX_MODE0) /*
dss_data12.dss_data12 */
+ OMAP3_CORE1_IOPAD(0x20f6, PIN_OUTPUT | MUX_MODE0) /*
dss_data13.dss_data13 */
+ OMAP3_CORE1_IOPAD(0x20f8, PIN_OUTPUT | MUX_MODE0) /*
dss_data14.dss_data14 */
+ OMAP3_CORE1_IOPAD(0x20fa, PIN_OUTPUT | MUX_MODE0) /*
dss_data15.dss_data15 */
+ OMAP3_CORE1_IOPAD(0x20fc, PIN_OUTPUT | MUX_MODE0) /*
dss_data16.dss_data16 */
+ OMAP3_CORE1_IOPAD(0x20fe, PIN_OUTPUT | MUX_MODE0) /*
dss_data17.dss_data17 */
+
+ OMAP3_CORE1_IOPAD(0x2100, PIN_OUTPUT | MUX_MODE3) /*
dss_data18.dss_data0 */
+ OMAP3_CORE1_IOPAD(0x2102, PIN_OUTPUT | MUX_MODE3) /*
dss_data19.dss_data1 */
+ OMAP3_CORE1_IOPAD(0x2104, PIN_OUTPUT | MUX_MODE3) /*
dss_data20.dss_data2 */
+ OMAP3_CORE1_IOPAD(0x2106, PIN_OUTPUT | MUX_MODE3) /*
dss_data21.dss_data3 */
+ OMAP3_CORE1_IOPAD(0x2108, PIN_OUTPUT | MUX_MODE3) /*
dss_data22.dss_data4 */
+ OMAP3_CORE1_IOPAD(0x210a, PIN_OUTPUT | MUX_MODE3) /*
dss_data23.dss_data5 */
+ ;
+ };
+
mmc1_pins: pinmux_mmc1_pins {
pinctrl-single,pins =
0x114 (PIN_OUTPUT_PULLUP | MUX_MODE0) /*
sdmmc1_clk.sdmmc1_clk */
@@ -75,6 +112,19 @@
};
};
+omap3_pmx_wkup {
+ dss_dpi_pins2: pinmux_dss_dpi_pins1 {
+ pinctrl-single,pins =
+ 0x0a (PIN_OUTPUT | MUX_MODE3) /* sys_boot0.dss_data18
*/
+ 0x0c (PIN_OUTPUT | MUX_MODE3) /* sys_boot1.dss_data19
*/
+ 0x10 (PIN_OUTPUT | MUX_MODE3) /* sys_boot3.dss_data20
*/
+ 0x12 (PIN_OUTPUT | MUX_MODE3) /* sys_boot4.dss_data21
*/
+ 0x14 (PIN_OUTPUT | MUX_MODE3) /* sys_boot5.dss_data22
*/
+ 0x16 (PIN_OUTPUT | MUX_MODE3) /* sys_boot6.dss_data23
*/
+ ;
+ };
+};
+
mmc1 {
pinctrl-names = default;
pinctrl-0 = mmc1_pins;
diff --git a/arch/arm/boot/dts/omap3-evm-common.dtsi
[PATCH 3/4] Doc/DT: Add DT binding documentation for SHARP LS037V7DW01
From: Tony Lindgren t...@atomide.com
Add DT binding documentation for SHARP LS037V7DW01 panel.
Signed-off-by: Tony Lindgren t...@atomide.com
Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
Cc: devicet...@vger.kernel.org
---
.../bindings/video/sharp,ls037v7dw01.txt | 43 ++
1 file changed, 43 insertions(+)
create mode 100644
Documentation/devicetree/bindings/video/sharp,ls037v7dw01.txt
diff --git a/Documentation/devicetree/bindings/video/sharp,ls037v7dw01.txt
b/Documentation/devicetree/bindings/video/sharp,ls037v7dw01.txt
new file mode 100644
index ..0cc8981e9d49
--- /dev/null
+++ b/Documentation/devicetree/bindings/video/sharp,ls037v7dw01.txt
@@ -0,0 +1,43 @@
+SHARP LS037V7DW01 TFT-LCD panel
+===
+
+Required properties:
+- compatible: sharp,ls037v7dw01
+
+Optional properties:
+- label: a symbolic name for the panel
+- enable-gpios: a GPIO spec for the optional enable pin.
+ This pin is the INI pin as specified in the LS037V7DW01.pdf file.
+- reset-gpios: a GPIO spec for the optional reset pin.
+ This pin is the RESB pin as specified in the LS037V7DW01.pdf file.
+- mode-gpios: a GPIO
+ ordered MO, LR, and UD as specified in the LS037V7DW01.pdf file.
+
+Required nodes:
+- Video port for DPI input
+
+This panel can have zero to five GPIOs to configure to change configuration
+between QVGA and VGA mode and the scan direction. As these pins can be also
+configured with external pulls, all the GPIOs are considered optional with
holes
+in the array.
+
+Example
+---
+
+Example when connected to a omap2+ based device:
+
+lcd0: display {
+ compatible = sharp,ls037v7dw01;
+ power-supply = lcd_3v3;
+ enable-gpios = gpio5 24 GPIO_ACTIVE_HIGH;/* gpio152, lcd INI */
+ reset-gpios = gpio5 27 GPIO_ACTIVE_HIGH; /* gpio155, lcd RESB */
+ mode-gpios = gpio5 26 GPIO_ACTIVE_HIGH/* gpio154, lcd MO */
+ gpio1 2 GPIO_ACTIVE_HIGH /* gpio2, lcd LR */
+ gpio1 3 GPIO_ACTIVE_HIGH; /* gpio3, lcd UD */
+
+ port {
+ lcd_in: endpoint {
+ remote-endpoint = dpi_out;
+ };
+ };
+};
--
1.9.1
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 0/4] OMAPDSS: sharp-ls037v7dw01 DT support
Hi, These are slightly reworked versions of the patches Tony sent: * Split the DT doc into separate patch * Handle errors from gpio functions * Remove QVGA support * Removed the change to arch/arm/mach-omap2/display.c. I'll add that to my patch which moves the conversion code to omapdss. Note that if you test this version, you need to add the panel name to the conversion list for now. * Set MO gpio GPIO_ACTIVE_HIGH in omap3-evm-common.dtsi * Set the GPIO default values the same way for DT and non-DT versions. Tony, I removed the QVGA support as it was a new feature, not supported by the non-DT version. Also, I don't think it should be done as you had implemented it, but rather either have a flag in the DT data in case the pin is hardwired in the hardware, or let the user select the mode at runtime. Also, I didn't quite understand the implementation. You had set initial values in the driver for MO and RESB differently than on the non-DT version. Was that on purpose? You said in a comment: The LCD is sideways, so we want the VGA mode instead of QVGA mode.. Why is that? How does the resolution affect the orientation? With my version, the panel (should) always be in VGA mode, like the non-DT version does. Only compile tested, I don't have boards with the panel. Tomi Tony Lindgren (4): OMAPDSS: panel-sharp-ls037v7dw01: update to use gpiod OMAPDSS: panel sharp-ls037v7dw01 DT support Doc/DT: Add DT binding documentation for SHARP LS037V7DW01 ARM: dts: Add LCD panel sharp ls037v7dw01 support for omap3-evm and ldp .../bindings/video/sharp,ls037v7dw01.txt | 43 + arch/arm/boot/dts/omap3-evm-37xx.dts | 50 + arch/arm/boot/dts/omap3-evm-common.dtsi| 26 +++ arch/arm/boot/dts/omap3-ldp.dts| 29 ++- .../boot/dts/omap3-panel-sharp-ls037v7dw01.dtsi| 67 +++ .../omap2/displays-new/panel-sharp-ls037v7dw01.c | 210 +++-- 6 files changed, 363 insertions(+), 62 deletions(-) create mode 100644 Documentation/devicetree/bindings/video/sharp,ls037v7dw01.txt create mode 100644 arch/arm/boot/dts/omap3-panel-sharp-ls037v7dw01.dtsi -- 1.9.1 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/4] OMAPDSS: panel sharp-ls037v7dw01 DT support
From: Tony Lindgren t...@atomide.com
Add DT support for sharp-ls037v7dw01.
Signed-off-by: Tony Lindgren t...@atomide.com
Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
---
.../omap2/displays-new/panel-sharp-ls037v7dw01.c | 102 -
1 file changed, 99 insertions(+), 3 deletions(-)
diff --git a/drivers/video/fbdev/omap2/displays-new/panel-sharp-ls037v7dw01.c
b/drivers/video/fbdev/omap2/displays-new/panel-sharp-ls037v7dw01.c
index 015d49300f2f..f1f72ce50a17 100644
--- a/drivers/video/fbdev/omap2/displays-new/panel-sharp-ls037v7dw01.c
+++ b/drivers/video/fbdev/omap2/displays-new/panel-sharp-ls037v7dw01.c
@@ -12,15 +12,18 @@
#include linux/delay.h
#include linux/gpio.h
#include linux/module.h
+#include linux/of.h
+#include linux/of_gpio.h
#include linux/platform_device.h
#include linux/slab.h
-
+#include linux/regulator/consumer.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;
+ struct regulator *vcc;
int data_lines;
@@ -95,12 +98,21 @@ static int sharp_ls_enable(struct omap_dss_device *dssdev)
if (omapdss_device_is_enabled(dssdev))
return 0;
- in-ops.dpi-set_data_lines(in, ddata-data_lines);
+ if (ddata-data_lines)
+ in-ops.dpi-set_data_lines(in, ddata-data_lines);
in-ops.dpi-set_timings(in, ddata-videomode);
+ if (ddata-vcc) {
+ r = regulator_enable(ddata-vcc);
+ if (r != 0)
+ return r;
+ }
+
r = in-ops.dpi-enable(in);
- if (r)
+ if (r) {
+ regulator_disable(ddata-vcc);
return r;
+ }
/* wait couple of vsyncs until enabling the LCD */
msleep(50);
@@ -136,6 +148,9 @@ static void sharp_ls_disable(struct omap_dss_device *dssdev)
in-ops.dpi-disable(in);
+ if (ddata-vcc)
+ regulator_disable(ddata-vcc);
+
dssdev-state = OMAP_DSS_DISPLAY_DISABLED;
}
@@ -249,6 +264,75 @@ static int sharp_ls_probe_pdata(struct platform_device
*pdev)
return 0;
}
+static int sharp_ls_get_gpio_of(struct device *dev, int index, int val,
+ const char *desc, struct gpio_desc **gpiod)
+{
+ struct gpio_desc *gd;
+ int r;
+
+ *gpiod = NULL;
+
+ gd = devm_gpiod_get_index(dev, desc, index);
+ if (IS_ERR(gd))
+ return PTR_ERR(gd) == -ENOENT ? 0 : PTR_ERR(gd);
+
+ r = gpiod_direction_output(gd, val);
+ if (r)
+ return r;
+
+ *gpiod = gd;
+ return 0;
+}
+
+static int sharp_ls_probe_of(struct platform_device *pdev)
+{
+ struct panel_drv_data *ddata = platform_get_drvdata(pdev);
+ struct device_node *node = pdev-dev.of_node;
+ struct omap_dss_device *in;
+ int r;
+
+ ddata-vcc = devm_regulator_get(pdev-dev, envdd);
+ if (IS_ERR(ddata-vcc)) {
+ dev_err(pdev-dev, failed to get regulator\n);
+ return PTR_ERR(ddata-vcc);
+ }
+
+ /* lcd INI */
+ r = sharp_ls_get_gpio_of(pdev-dev, 0, 0, enable, ddata-ini_gpio);
+ if (r)
+ return r;
+
+ /* lcd RESB */
+ r = sharp_ls_get_gpio_of(pdev-dev, 0, 0, reset, ddata-resb_gpio);
+ if (r)
+ return r;
+
+ /* lcd MO */
+ r = sharp_ls_get_gpio_of(pdev-dev, 0, 0, mode, ddata-mo_gpio);
+ if (r)
+ return r;
+
+ /* lcd LR */
+ r = sharp_ls_get_gpio_of(pdev-dev, 1, 1, mode, ddata-lr_gpio);
+ if (r)
+ return r;
+
+ /* lcd UD */
+ r = sharp_ls_get_gpio_of(pdev-dev, 2, 1, mode, ddata-ud_gpio);
+ if (r)
+ return r;
+
+ in = omapdss_of_find_source_for_first_ep(node);
+ if (IS_ERR(in)) {
+ dev_err(pdev-dev, failed to find video source\n);
+ return PTR_ERR(in);
+ }
+
+ ddata-in = in;
+
+ return 0;
+}
+
static int sharp_ls_probe(struct platform_device *pdev)
{
struct panel_drv_data *ddata;
@@ -265,6 +349,10 @@ static int sharp_ls_probe(struct platform_device *pdev)
r = sharp_ls_probe_pdata(pdev);
if (r)
return r;
+ } else if (pdev-dev.of_node) {
+ r = sharp_ls_probe_of(pdev);
+ if (r)
+ return r;
} else {
return -ENODEV;
}
@@ -308,12 +396,20 @@ static int __exit sharp_ls_remove(struct platform_device
*pdev)
return 0;
}
+static const struct of_device_id sharp_ls_of_match[] = {
+ { .compatible = omapdss,sharp,ls037v7dw01, },
+ {},
+};
+
+MODULE_DEVICE_TABLE(of, sharp_ls_of_match);
+
static struct platform_driver sharp_ls_driver = {
.probe = sharp_ls_probe,
.remove = __exit_p(sharp_ls_remove),
.driver = {
.name = panel-sharp-ls037v7dw01,
[PATCH 1/4] OMAPDSS: panel-sharp-ls037v7dw01: update to use gpiod
From: Tony Lindgren t...@atomide.com
Using gpiod will make it easier to add device tree support
for this panel in the following patches.
Note that all the GPIOs for this panel are optional, any
of the the GPIOs could be configured with external pulls
instead of GPIOs, so let's not error out if GPIOs are not
found to make the panel more generic.
Signed-off-by: Tony Lindgren t...@atomide.com
Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
---
.../omap2/displays-new/panel-sharp-ls037v7dw01.c | 108 ++---
1 file changed, 54 insertions(+), 54 deletions(-)
diff --git a/drivers/video/fbdev/omap2/displays-new/panel-sharp-ls037v7dw01.c
b/drivers/video/fbdev/omap2/displays-new/panel-sharp-ls037v7dw01.c
index b2f710be565d..015d49300f2f 100644
--- a/drivers/video/fbdev/omap2/displays-new/panel-sharp-ls037v7dw01.c
+++ b/drivers/video/fbdev/omap2/displays-new/panel-sharp-ls037v7dw01.c
@@ -26,11 +26,11 @@ struct panel_drv_data {
struct omap_video_timings videomode;
- int resb_gpio;
- int ini_gpio;
- int mo_gpio;
- int lr_gpio;
- int ud_gpio;
+ struct gpio_desc *resb_gpio;/* low = reset active min 20 us */
+ struct gpio_desc *ini_gpio; /* high = power on */
+ struct gpio_desc *mo_gpio; /* low = 480x640, high = 240x320 */
+ struct gpio_desc *lr_gpio; /* high = conventional horizontal
scanning */
+ struct gpio_desc *ud_gpio; /* high = conventional vertical
scanning */
};
static const struct omap_video_timings sharp_ls_timings = {
@@ -105,11 +105,11 @@ static int sharp_ls_enable(struct omap_dss_device *dssdev)
/* wait couple of vsyncs until enabling the LCD */
msleep(50);
- if (gpio_is_valid(ddata-resb_gpio))
- gpio_set_value_cansleep(ddata-resb_gpio, 1);
+ if (ddata-resb_gpio)
+ gpiod_set_value_cansleep(ddata-resb_gpio, 1);
- if (gpio_is_valid(ddata-ini_gpio))
- gpio_set_value_cansleep(ddata-ini_gpio, 1);
+ if (ddata-ini_gpio)
+ gpiod_set_value_cansleep(ddata-ini_gpio, 1);
dssdev-state = OMAP_DSS_DISPLAY_ACTIVE;
@@ -124,11 +124,11 @@ static void sharp_ls_disable(struct omap_dss_device
*dssdev)
if (!omapdss_device_is_enabled(dssdev))
return;
- if (gpio_is_valid(ddata-ini_gpio))
- gpio_set_value_cansleep(ddata-ini_gpio, 0);
+ if (ddata-ini_gpio)
+ gpiod_set_value_cansleep(ddata-ini_gpio, 0);
- if (gpio_is_valid(ddata-resb_gpio))
- gpio_set_value_cansleep(ddata-resb_gpio, 0);
+ if (ddata-resb_gpio)
+ gpiod_set_value_cansleep(ddata-resb_gpio, 0);
/* wait at least 5 vsyncs after disabling the LCD */
@@ -182,11 +182,32 @@ static struct omap_dss_driver sharp_ls_ops = {
.get_resolution = omapdss_default_get_resolution,
};
+static int sharp_ls_get_gpio(struct device *dev, int gpio, unsigned long flags,
+ char *desc, struct gpio_desc **gpiod)
+{
+ struct gpio_desc *gd;
+ int r;
+
+ *gpiod = NULL;
+
+ r = devm_gpio_request_one(dev, gpio, flags, desc);
+ if (r)
+ return r == -ENOENT ? 0 : r;
+
+ gd = gpio_to_desc(gpio);
+ if (IS_ERR(gd))
+ return PTR_ERR(gd) == -ENOENT ? 0 : PTR_ERR(gd);
+
+ *gpiod = gd;
+ return 0;
+}
+
static int sharp_ls_probe_pdata(struct platform_device *pdev)
{
const struct panel_sharp_ls037v7dw01_platform_data *pdata;
struct panel_drv_data *ddata = platform_get_drvdata(pdev);
struct omap_dss_device *dssdev, *in;
+ int r;
pdata = dev_get_platdata(pdev-dev);
@@ -204,11 +225,26 @@ static int sharp_ls_probe_pdata(struct platform_device
*pdev)
dssdev = ddata-dssdev;
dssdev-name = pdata-name;
- ddata-resb_gpio = pdata-resb_gpio;
- ddata-ini_gpio = pdata-ini_gpio;
- ddata-mo_gpio = pdata-mo_gpio;
- ddata-lr_gpio = pdata-lr_gpio;
- ddata-ud_gpio = pdata-ud_gpio;
+ r = sharp_ls_get_gpio(pdev-dev, pdata-mo_gpio, GPIOF_OUT_INIT_LOW,
+ lcd MO, ddata-mo_gpio);
+ if (r)
+ return r;
+ r = sharp_ls_get_gpio(pdev-dev, pdata-lr_gpio, GPIOF_OUT_INIT_HIGH,
+ lcd LR, ddata-lr_gpio);
+ if (r)
+ return r;
+ r = sharp_ls_get_gpio(pdev-dev, pdata-ud_gpio, GPIOF_OUT_INIT_HIGH,
+ lcd UD, ddata-ud_gpio);
+ if (r)
+ return r;
+ r = sharp_ls_get_gpio(pdev-dev, pdata-resb_gpio, GPIOF_OUT_INIT_LOW,
+ lcd RESB, ddata-resb_gpio);
+ if (r)
+ return r;
+ r = sharp_ls_get_gpio(pdev-dev, pdata-ini_gpio, GPIOF_OUT_INIT_LOW,
+ lcd INI, ddata-ini_gpio);
+ if (r)
+ return r;
return 0;
}
@@ -233,41 +269,6 @@ static int sharp_ls_probe(struct platform_device *pdev)
return
Re: RCU stall on panda
On 05/16/2014 02:36 AM, Santosh Shilimkar wrote: yes. My board is panda ES. without this revert, it works. Care to specify what linux version you are testing against? Does it hang in idle always immediately on booting? Or does the serial console first hang with sysrq still working (ctrl-a h in minicom for help) with device eventually locking up hard? I just posted an updated patch Alex on other thread. Attaching here again for your reference. Please try it out and see if the you still get a hang. it does not hang this time. but I am not sure it can solve my problem, since RCU stall is not easy to reproduce in short time. -- Thanks Alex -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: OMAP DSS: panel-dpi and enable gpios
On 16/05/14 00:02, Joachim Eastwood wrote:
On 15 May 2014 15:18, Tomi Valkeinen tomi.valkei...@ti.com wrote:
On 12/05/14 20:58, Joachim Eastwood wrote:
Hello Tomi,
There seems to be a mismatch between your panel-dpi code and DT docs.
The docs state that enable-gpios is optinal but in panel-dpi.c you
have the following code
gpio = devm_gpiod_get(pdev-dev, enable);
if (IS_ERR(gpio)) {
dev_err(pdev-dev, failed to parse enable gpio\n);
return PTR_ERR(gpio);
} else {
gpiod_direction_output(gpio, 0);
ddata-enable_gpio = gpio;
}
Making probing fail on my DT since I don't use enable-gpios with
Would this work? Only compile tested.
diff --git a/drivers/video/fbdev/omap2/displays-new/panel-dpi.c
b/drivers/video/fbdev/omap2/displays-new/panel-dpi.c
index dca6b10d1157..2ac38eaa4c8f 100644
--- a/drivers/video/fbdev/omap2/displays-new/panel-dpi.c
+++ b/drivers/video/fbdev/omap2/displays-new/panel-dpi.c
@@ -210,14 +210,19 @@ static int panel_dpi_probe_of(struct platform_device
*pdev)
struct gpio_desc *gpio;
gpio = devm_gpiod_get(pdev-dev, enable);
+
if (IS_ERR(gpio)) {
- dev_err(pdev-dev, failed to parse enable gpio\n);
- return PTR_ERR(gpio);
+ r = PTR_ERR(gpio);
+ if (r == -EPROBE_DEFER || r != -ENOENT)
+ return r;
+ else
+ gpio = NULL;
} else {
gpiod_direction_output(gpio, 0);
- ddata-enable_gpio = gpio;
}
+ ddata-enable_gpio = gpio;
+
ddata-backlight_gpio = -ENOENT;
r = of_get_display_timing(node, panel-timing, timing);
Seems to do the trick here.
Display is showing Tux's on boot up again :)
The check above was a bit too complex. Here's an updated patch.
From f48b44ca73e29b2328e7852d9beb06b161bb1cb4 Mon Sep 17 00:00:00 2001
From: Tomi Valkeinen tomi.valkei...@ti.com
Date: Thu, 15 May 2014 16:19:44 +0300
Subject: [PATCH] OMAPDSS: panel-dpi: enable-gpio
The enable gpio should be optional, but the driver returns an error if
it doesn't get the gpio.
So change the driver to accept -ENOENT error.
Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
---
drivers/video/fbdev/omap2/displays-new/panel-dpi.c | 10 +++---
1 file changed, 7 insertions(+), 3 deletions(-)
diff --git a/drivers/video/fbdev/omap2/displays-new/panel-dpi.c
b/drivers/video/fbdev/omap2/displays-new/panel-dpi.c
index dca6b10d1157..3636b61dc9b4 100644
--- a/drivers/video/fbdev/omap2/displays-new/panel-dpi.c
+++ b/drivers/video/fbdev/omap2/displays-new/panel-dpi.c
@@ -210,14 +210,18 @@ static int panel_dpi_probe_of(struct platform_device
*pdev)
struct gpio_desc *gpio;
gpio = devm_gpiod_get(pdev-dev, enable);
+
if (IS_ERR(gpio)) {
- dev_err(pdev-dev, failed to parse enable gpio\n);
- return PTR_ERR(gpio);
+ if (PTR_ERR(gpio) != -ENOENT)
+ return PTR_ERR(gpio);
+ else
+ gpio = NULL;
} else {
gpiod_direction_output(gpio, 0);
- ddata-enable_gpio = gpio;
}
+ ddata-enable_gpio = gpio;
+
ddata-backlight_gpio = -ENOENT;
r = of_get_display_timing(node, panel-timing, timing);
--
1.9.1
signature.asc
Description: OpenPGP digital signature
Re: [PATCH 00/11] ARM: OMAP: OMAP5 AM43x DSS
On 12/05/14 18:48, Tony Lindgren wrote: Also, I'm wondering why we still have .clk and .opt_clks entries in the hwmod data for am43xx and omap5 which are both device tree based with all the clocks coming from .dts files? I think they are needed for the omap_device/hwmod stuff to work. Only omapdss driver knows about the clocks defined in the .dts files, and the omap_device/hwmod code still needs to do the reset and maybe some other tasks that require the clocks. We're already populating the hwmod data from dts entries, that's done by omap_device_build_from_dt. Why aren't we doing that for dt defined clocks? I'd rather not start adding new data that will then just be removed, that's what people call pointless extra churn. I don't know why. I have to say I'm not 100% sure if that's done or not, but at least I can't find where it's done. Tomi signature.asc Description: OpenPGP digital signature
Re: [GIT PULL] ARM: OMAP2+: some hwmod data patches for v3.16
Hi Paul, On 16/05/14 07:45, Paul Walmsley wrote: Hi Tony The following changes since commit d1db0eea852497762cab43b905b879dfcd3b8987: Linux 3.15-rc3 (2014-04-27 19:29:27 -0700) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/pjw/omap-pending.git for-v3.16/hwmod-a for you to fetch changes up to 433480707967187a74ced38bd38edba749998013: ARM: OMAP2+: hwmod: OMAP5 DSS hwmod data (2014-05-14 12:26:10 -0600) First (and possibly last) set of hwmod data changes for v3.16. This set should clean up some obsolete OMAP4 hwmod data, and add OMAP5 DSS support. What about the AM43xx hwmod data I sent in the same series: http://article.gmane.org/gmane.linux.ports.arm.omap/114192 Tomi signature.asc Description: OpenPGP digital signature
Re: [PATCH 00/11] ARM: OMAP: OMAP5 AM43x DSS
On 12/05/14 17:36, Tony Lindgren wrote: * Tomi Valkeinen tomi.valkei...@ti.com [140512 06:26]: Hi Tony, On 09/05/14 14:56, Tomi Valkeinen wrote: Hi, Here are arch/arm/ patches to add display support for OMAP5 and AM43x. I have these in my tree, in a branch I will send to Tony for merging. Most of these patches have already been around the lists, but I wanted to send them one more time to verify that all looks right and everybody is fine with them. I have pushed these to: git://git.kernel.org/pub/scm/linux/kernel/git/tomba/linux.git 3.16/omap If you're fine with these, I think we can consider that branch stable. There are probably still a few display related .dts changed for the board coming up, but I'll add those on top of the current commits. Please coordinate things with Paul and Tero so you at least have proper acks for the hwmod and and clock patches. In general we really want to queue hwmod and clock changes separately as those can easily mess up things in a bad way like we've already seen with overlapping hwmod entries in the .dts files. I don't think the clock dts changes can be separated from the other dts changes, as the new 'dss_l3_iclk' clock node is required by the omap5.dtsi when adding the DSS support. The HWMOD patches can go separately. Tomi signature.asc Description: OpenPGP digital signature
Re: [PATCH] video: omap: delete support for early fbmem allocation
On 10/05/14 01:52, Aaro Koskinen wrote: Commit 1e434f9318efc3dddc0c0b8d2071712668154c2b (OMAPFB: remove early mem alloc from old omapfb) deleted the support for early fbmem allocation from the platform code, but some code still remains in the driver side. Delete this code now, as it repotedly causes build issues on !MMU. The patch was tested on Amstrad E3 and Nokia 770 and framebuffer functionality is not affected. Signed-off-by: Aaro Koskinen aaro.koski...@iki.fi Thanks, queued for 3.16. Tomi signature.asc Description: OpenPGP digital signature
Re: [PATCH 06/17] pci: host: pcie-designware: Use *base-mask* for configuring the iATU
Hi Arnd,
On Wednesday 14 May 2014 06:15 PM, Arnd Bergmann wrote:
On Wednesday 14 May 2014 11:14:45 Kishon Vijay Abraham I wrote:
hi Arnd,
On Tuesday 13 May 2014 07:04 PM, Arnd Bergmann wrote:
On Tuesday 13 May 2014 15:27:46 Arnd Bergmann wrote:
On Tuesday 13 May 2014 18:56:23 Kishon Vijay Abraham I wrote:
If you have a case where the outbound translation is a 256MB (i.e. 28bit)
section of the CPU address space, that could be represented as
ranges = 0x8200 0 0 0xb000 0 0x1000;
or
ranges = 0x8200 0 0xb000 0xb000 0 0x1000;
depending on whether you want the BARs to be programmed using a low
address 0x0-0x0fff or an address matching the window
0xb000-0xbfff.
The problem is, for configuring the window starting at 0xb000, the ATU
should be programmed 0x000 (the cpu address for it will be 0xb000
though).
Then use the first of the two?
To clarify: using 0x8200 0 0 0xb000 0 0x1000 will give you
a mem_offset of 0xb000, which should work just fine for this case.
What I don't understand is why the ATU cares about whether the outbound
address is 0x000 or 0xb000 if it just decodes the lower 28 bit
anyway. Did you mean that we have to program the BARs using low addresses
regardless of what is programmed in the ATU? That would make more sense,
and it also matches what I suggested.
No, It's not like it decodes only the lower 28bits. The BARs is programmed
with
32 bit value.
My pcie dt node has
ranges = 0x0800 0 0x20001000 0x20001000 0 0x2000 /* CONFIG */
0x8100 0 0 0x20003000 0 0x0001 /* IO */
0x8200 0 0x20013000 0x20013000 0 0xffed000; /* MEM */
Consider MEM address space..
Here both PCI address and CPU address is 0x20013000. So when there is a write
to cpu addr 0x20013000 [writel(virt_addr(0x20013000)], we want it to be
translated to PCI addr 0x20013000. So in 'ATU', we would expect *base* to be
programmed to *0x20013000* and target to be programmed to *0x20013000*. But
that's not the case for DRA7xx. For DRA7xx *base* should be programmed to
*0x0013000* and target should be programmed to *0x20013000*.
Ok, got it, thanks for your patience.
I think this would best be modeled as a separate bus node that contains the
restriction, like this:
/ {
#address-cells = 1; // or 2 if you support 4GB address space
#size-cells = 1;
soc {
#address-cells 1;
#size-cells = 1;
ranges;
dma-ranges;
... // all normal devices
axi@2000 {
#size-cells = 1;
#address-cells = 1;
dma-ranges; // can access all 4GB outbound
ranges = 0 0x2000 0x1000; // 28-bit bus
pci@0 {
reg = 0x00x1000, // internal regs
0x1000 0x2000; // config space
The internal reg address space starts at 0x5100. By Using this 0
0x2000 0x1000; as ranges, we are not able to get the memory resource
properly. Can we use multiple ranges? how do we specify which ranges the *reg*
property to use?
Btw I was using *simple-bus* as compatible to *axi*. Or should I create a new
*axi* driver to create the pcie memory resources myself?
Thanks
Kishon
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: OMAP: replace checks for CONFIG_USB_GADGET_OMAP
Felipe,
On Thu, 2014-05-15 at 18:12 -0500, Felipe Balbi wrote:
On Thu, May 15, 2014 at 10:55:45PM +0200, Paul Bolle wrote:
diff --git a/arch/arm/mach-omap1/board-h2.c b/arch/arm/mach-omap1/board-h2.c
index 65d2acb31498..57092bc7f4f1 100644
--- a/arch/arm/mach-omap1/board-h2.c
+++ b/arch/arm/mach-omap1/board-h2.c
@@ -346,7 +346,7 @@ static struct omap_usb_config h2_usb_config __initdata
= {
/* usb1 has a Mini-AB port and external isp1301 transceiver */
.otg= 2,
-#ifdef CONFIG_USB_GADGET_OMAP
+#ifdef CONFIG_USB_OMAP
CONFIG_USB_OMAP is tristate, it might be better to use
IS_ENABLED(CONFIG_USB_OMAP) here. Likewise for the rest of the patch.
Will do shortly. That does increase the scope of the patch, a bit, but
since this code has been effectively dead since v3.1 that is hardly an
additional risk.
Thanks!
Paul Bolle
--
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 3/3] OMAPDSS: panel NEC-NL8048HL11 DT support
We don't have any working boards using this panel right now, and the
panel driver looks odd compared to the panel specs. For example, the
panel spec does not mention any QVGA pin.
So, while this patch adds DT support to the driver, it's not really
supported and there are not bindings documentation for the panel until
someone can verify how the panel actually works.
Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
Cc: Erik Gilling konk...@android.com
---
.../omap2/displays-new/panel-nec-nl8048hl11.c | 44 +-
1 file changed, 43 insertions(+), 1 deletion(-)
diff --git a/drivers/video/fbdev/omap2/displays-new/panel-nec-nl8048hl11.c
b/drivers/video/fbdev/omap2/displays-new/panel-nec-nl8048hl11.c
index 996fa004b48c..553e5643e4ba 100644
--- a/drivers/video/fbdev/omap2/displays-new/panel-nec-nl8048hl11.c
+++ b/drivers/video/fbdev/omap2/displays-new/panel-nec-nl8048hl11.c
@@ -16,6 +16,7 @@
#include linux/spi/spi.h
#include linux/fb.h
#include linux/gpio.h
+#include linux/of_gpio.h
#include video/omapdss.h
#include video/omap-panel-data.h
@@ -156,7 +157,8 @@ static int nec_8048_enable(struct omap_dss_device *dssdev)
if (omapdss_device_is_enabled(dssdev))
return 0;
- in-ops.dpi-set_data_lines(in, ddata-data_lines);
+ if (ddata-data_lines)
+ in-ops.dpi-set_data_lines(in, ddata-data_lines);
in-ops.dpi-set_timings(in, ddata-videomode);
r = in-ops.dpi-enable(in);
@@ -258,6 +260,34 @@ static int nec_8048_probe_pdata(struct spi_device *spi)
return 0;
}
+static int nec_8048_probe_of(struct spi_device *spi)
+{
+ struct device_node *node = spi-dev.of_node;
+ struct panel_drv_data *ddata = dev_get_drvdata(spi-dev);
+ struct omap_dss_device *in;
+ int gpio;
+
+ gpio = of_get_named_gpio(node, reset-gpios, 0);
+ if (!gpio_is_valid(gpio)) {
+ dev_err(spi-dev, failed to parse enable gpio\n);
+ return gpio;
+ }
+ ddata-res_gpio = gpio;
+
+ /* XXX the panel spec doesn't mention any QVGA pin?? */
+ ddata-qvga_gpio = -ENOENT;
+
+ in = omapdss_of_find_source_for_first_ep(node);
+ if (IS_ERR(in)) {
+ dev_err(spi-dev, failed to find video source\n);
+ return PTR_ERR(in);
+ }
+
+ ddata-in = in;
+
+ return 0;
+}
+
static int nec_8048_probe(struct spi_device *spi)
{
struct panel_drv_data *ddata;
@@ -289,6 +319,10 @@ static int nec_8048_probe(struct spi_device *spi)
r = nec_8048_probe_pdata(spi);
if (r)
return r;
+ } else if (spi-dev.of_node) {
+ r = nec_8048_probe_of(spi);
+ if (r)
+ return r;
} else {
return -ENODEV;
}
@@ -377,6 +411,13 @@ static SIMPLE_DEV_PM_OPS(nec_8048_pm_ops, nec_8048_suspend,
#define NEC_8048_PM_OPS NULL
#endif
+static const struct of_device_id lb035q02_of_match[] = {
+ { .compatible = omapdss,nec,nl8048hl11, },
+ {},
+};
+
+MODULE_DEVICE_TABLE(of, lb035q02_of_match);
+
static struct spi_driver nec_8048_driver = {
.driver = {
.name = panel-nec-nl8048hl11,
@@ -389,6 +430,7 @@ static struct spi_driver nec_8048_driver = {
module_spi_driver(nec_8048_driver);
+MODULE_ALIAS(spi:nec,nl8048hl11);
MODULE_AUTHOR(Erik Gilling konk...@android.com);
MODULE_DESCRIPTION(NEC-NL8048HL11 Driver);
MODULE_LICENSE(GPL);
--
1.9.1
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/3] OMAPDSS: Panel TPO-TD043MTEA1 DT support
Add DT support for panel TPO-TD043MTEA1.
Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
Cc: Grazvydas Ignotas nota...@gmail.com
---
.../omap2/displays-new/panel-tpo-td043mtea1.c | 41 +-
1 file changed, 40 insertions(+), 1 deletion(-)
diff --git a/drivers/video/fbdev/omap2/displays-new/panel-tpo-td043mtea1.c
b/drivers/video/fbdev/omap2/displays-new/panel-tpo-td043mtea1.c
index 875b40263b33..ce509fbd235d 100644
--- a/drivers/video/fbdev/omap2/displays-new/panel-tpo-td043mtea1.c
+++ b/drivers/video/fbdev/omap2/displays-new/panel-tpo-td043mtea1.c
@@ -17,6 +17,7 @@
#include linux/gpio.h
#include linux/err.h
#include linux/slab.h
+#include linux/of_gpio.h
#include video/omapdss.h
#include video/omap-panel-data.h
@@ -376,7 +377,8 @@ static int tpo_td043_enable(struct omap_dss_device *dssdev)
if (omapdss_device_is_enabled(dssdev))
return 0;
- in-ops.dpi-set_data_lines(in, ddata-data_lines);
+ if (ddata-data_lines)
+ in-ops.dpi-set_data_lines(in, ddata-data_lines);
in-ops.dpi-set_timings(in, ddata-videomode);
r = in-ops.dpi-enable(in);
@@ -489,6 +491,31 @@ static int tpo_td043_probe_pdata(struct spi_device *spi)
return 0;
}
+static int tpo_td043_probe_of(struct spi_device *spi)
+{
+ struct device_node *node = spi-dev.of_node;
+ struct panel_drv_data *ddata = dev_get_drvdata(spi-dev);
+ struct omap_dss_device *in;
+ int gpio;
+
+ gpio = of_get_named_gpio(node, reset-gpios, 0);
+ if (!gpio_is_valid(gpio)) {
+ dev_err(spi-dev, failed to parse enable gpio\n);
+ return gpio;
+ }
+ ddata-nreset_gpio = gpio;
+
+ in = omapdss_of_find_source_for_first_ep(node);
+ if (IS_ERR(in)) {
+ dev_err(spi-dev, failed to find video source\n);
+ return PTR_ERR(in);
+ }
+
+ ddata-in = in;
+
+ return 0;
+}
+
static int tpo_td043_probe(struct spi_device *spi)
{
struct panel_drv_data *ddata;
@@ -518,6 +545,10 @@ static int tpo_td043_probe(struct spi_device *spi)
r = tpo_td043_probe_pdata(spi);
if (r)
return r;
+ } else if (spi-dev.of_node) {
+ r = tpo_td043_probe_of(spi);
+ if (r)
+ return r;
} else {
return -ENODEV;
}
@@ -629,6 +660,13 @@ static int tpo_td043_spi_resume(struct device *dev)
static SIMPLE_DEV_PM_OPS(tpo_td043_spi_pm,
tpo_td043_spi_suspend, tpo_td043_spi_resume);
+static const struct of_device_id tpo_td043_of_match[] = {
+ { .compatible = omapdss,tpo,td043mtea1, },
+ {},
+};
+
+MODULE_DEVICE_TABLE(of, tpo_td043_of_match);
+
static struct spi_driver tpo_td043_spi_driver = {
.driver = {
.name = panel-tpo-td043mtea1,
@@ -641,6 +679,7 @@ static struct spi_driver tpo_td043_spi_driver = {
module_spi_driver(tpo_td043_spi_driver);
+MODULE_ALIAS(spi:tpo,td043mtea1);
MODULE_AUTHOR(GraÅžvydas Ignotas nota...@gmail.com);
MODULE_DESCRIPTION(TPO TD043MTEA1 LCD Driver);
MODULE_LICENSE(GPL);
--
1.9.1
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/3] Doc/DT: Add DT binding documentation for TPO td043mtea1 panel
Add DT binding documentation for TPO td043mtea1 panel
Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
Cc: devicet...@vger.kernel.org
Cc: Grazvydas Ignotas nota...@gmail.com
---
.../devicetree/bindings/video/tpo,td043mtea1.txt | 33 ++
1 file changed, 33 insertions(+)
create mode 100644 Documentation/devicetree/bindings/video/tpo,td043mtea1.txt
diff --git a/Documentation/devicetree/bindings/video/tpo,td043mtea1.txt
b/Documentation/devicetree/bindings/video/tpo,td043mtea1.txt
new file mode 100644
index ..ec6d62975162
--- /dev/null
+++ b/Documentation/devicetree/bindings/video/tpo,td043mtea1.txt
@@ -0,0 +1,33 @@
+TPO TD043MTEA1 Panel
+
+
+Required properties:
+- compatible: tpo,td043mtea1
+- reset-gpios: panel reset gpio
+
+Optional properties:
+- label: a symbolic name for the panel
+
+Required nodes:
+- Video port for DPI input
+
+Example
+---
+
+lcd-panel: panel@0 {
+ compatible = tpo,td043mtea1;
+ reg = 0;
+ spi-max-frequency = 10;
+ spi-cpol;
+ spi-cpha;
+
+ label = lcd;
+
+ reset-gpios = gpio7 7 0;
+
+ port {
+ lcd_in: endpoint {
+ remote-endpoint = dpi_out;
+ };
+ };
+};
--
1.9.1
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2] ARM: OMAP: replace checks for CONFIG_USB_GADGET_OMAP
Commit 193ab2a60700 (usb: gadget: allow multiple gadgets to be built)
apparently required that checks for CONFIG_USB_GADGET_OMAP would be
replaced with checks for CONFIG_USB_OMAP. Do so now for the remaining
checks for CONFIG_USB_GADGET_OMAP, even though these checks have
basically been broken since v3.1.
And, since we're touching this code, use the IS_ENABLED() macro, so
things will now (hopefully) also work if USB_OMAP is modular.
Fixes: 193ab2a60700 (usb: gadget: allow multiple gadgets to be built)
Signed-off-by: Paul Bolle pebo...@tiscali.nl
---
v2: us IS_ENABLED() as Felipe requested. Still untested.
arch/arm/mach-omap1/board-h2.c| 2 +-
arch/arm/mach-omap1/board-h3.c| 2 +-
arch/arm/mach-omap1/board-innovator.c | 2 +-
arch/arm/mach-omap1/board-osk.c | 2 +-
drivers/usb/phy/phy-isp1301-omap.c| 2 +-
5 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/arch/arm/mach-omap1/board-h2.c b/arch/arm/mach-omap1/board-h2.c
index 65d2acb31498..5b45d266d83e 100644
--- a/arch/arm/mach-omap1/board-h2.c
+++ b/arch/arm/mach-omap1/board-h2.c
@@ -346,7 +346,7 @@ static struct omap_usb_config h2_usb_config __initdata = {
/* usb1 has a Mini-AB port and external isp1301 transceiver */
.otg= 2,
-#ifdef CONFIG_USB_GADGET_OMAP
+#if IS_ENABLED(CONFIG_USB_OMAP)
.hmc_mode = 19, /* 0:host(off) 1:dev|otg 2:disabled */
/* .hmc_mode= 21,*/ /* 0:host(off) 1:dev(loopback) 2:host(loopback)
*/
#elif defined(CONFIG_USB_OHCI_HCD) || defined(CONFIG_USB_OHCI_HCD_MODULE)
diff --git a/arch/arm/mach-omap1/board-h3.c b/arch/arm/mach-omap1/board-h3.c
index 816ecd13f81e..bfed4f928663 100644
--- a/arch/arm/mach-omap1/board-h3.c
+++ b/arch/arm/mach-omap1/board-h3.c
@@ -366,7 +366,7 @@ static struct omap_usb_config h3_usb_config __initdata = {
/* usb1 has a Mini-AB port and external isp1301 transceiver */
.otg= 2,
-#ifdef CONFIG_USB_GADGET_OMAP
+#if IS_ENABLED(CONFIG_USB_OMAP)
.hmc_mode = 19, /* 0:host(off) 1:dev|otg 2:disabled */
#elif defined(CONFIG_USB_OHCI_HCD) || defined(CONFIG_USB_OHCI_HCD_MODULE)
/* NONSTANDARD CABLE NEEDED (B-to-Mini-B) */
diff --git a/arch/arm/mach-omap1/board-innovator.c
b/arch/arm/mach-omap1/board-innovator.c
index bd5f02e9c354..c49ce83cc1eb 100644
--- a/arch/arm/mach-omap1/board-innovator.c
+++ b/arch/arm/mach-omap1/board-innovator.c
@@ -312,7 +312,7 @@ static struct omap_usb_config h2_usb_config __initdata = {
/* usb1 has a Mini-AB port and external isp1301 transceiver */
.otg= 2,
-#ifdef CONFIG_USB_GADGET_OMAP
+#if IS_ENABLED(CONFIG_USB_OMAP)
.hmc_mode = 19, /* 0:host(off) 1:dev|otg 2:disabled */
/* .hmc_mode= 21,*/ /* 0:host(off) 1:dev(loopback) 2:host(loopback)
*/
#elif defined(CONFIG_USB_OHCI_HCD) || defined(CONFIG_USB_OHCI_HCD_MODULE)
diff --git a/arch/arm/mach-omap1/board-osk.c b/arch/arm/mach-omap1/board-osk.c
index 3a0262156e93..7436d4cf6596 100644
--- a/arch/arm/mach-omap1/board-osk.c
+++ b/arch/arm/mach-omap1/board-osk.c
@@ -283,7 +283,7 @@ static struct omap_usb_config osk_usb_config __initdata = {
* be used, with a NONSTANDARD gender-bending cable/dongle, as
* a peripheral.
*/
-#ifdef CONFIG_USB_GADGET_OMAP
+#if IS_ENABLED(CONFIG_USB_OMAP)
.register_dev = 1,
.hmc_mode = 0,
#else
diff --git a/drivers/usb/phy/phy-isp1301-omap.c
b/drivers/usb/phy/phy-isp1301-omap.c
index 6e146d723b37..69e49be8866b 100644
--- a/drivers/usb/phy/phy-isp1301-omap.c
+++ b/drivers/usb/phy/phy-isp1301-omap.c
@@ -1295,7 +1295,7 @@ isp1301_set_host(struct usb_otg *otg, struct usb_bus
*host)
return isp1301_otg_enable(isp);
return 0;
-#elif !defined(CONFIG_USB_GADGET_OMAP)
+#elif !IS_ENABLED(CONFIG_USB_OMAP)
// FIXME update its refcount
otg-host = host;
--
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 07/19] OMAPDSS: hdmi5_core: Fix compilation with OMAP5_DSS_HDMI_AUDIO
Hi, On 12/05/14 12:12, Jyri Sarha wrote: Use correct variable name for base address. Signed-off-by: Jyri Sarha jsa...@ti.com --- drivers/video/fbdev/omap2/dss/hdmi5_core.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/video/fbdev/omap2/dss/hdmi5_core.c b/drivers/video/fbdev/omap2/dss/hdmi5_core.c index 270ebdd..af88e3c 100644 --- a/drivers/video/fbdev/omap2/dss/hdmi5_core.c +++ b/drivers/video/fbdev/omap2/dss/hdmi5_core.c @@ -786,7 +786,7 @@ static void hdmi5_core_audio_config(struct hdmi_core_data *core, REG_FLD_MOD(base, HDMI_CORE_AUD_GP_POL, 1, 0, 0); /* unmute audio */ - REG_FLD_MOD(core_sys_base, HDMI_CORE_FC_AUDSCONF, 0, 7, 4); + REG_FLD_MOD(base, HDMI_CORE_FC_AUDSCONF, 0, 7, 4); } static void hdmi5_core_audio_infoframe_cfg(struct hdmi_core_data *core, This fix is independent of the rest of the series, so I'll already pick this one to my 3.16 omapdss branch. Tomi signature.asc Description: OpenPGP digital signature
[PATCH 1/3] ARM: OMAP5+: dpll: support Duty Cycle Correction(DCC)
From: Andrii Tseglytskyi andrii.tseglyts...@ti.com
Duty Cycle Correction(DCC) needs to be enabled if the MPU is to run at
frequencies beyond 1.4GHz for OMAP5, DRA75x, DRA72x.
MPU DPLL has a limitation on the maximum frequency it can be locked
at. Duty Cycle Correction circuit is used to recover a correct duty
cycle for achieving higher frequencies (hardware internally switches
output to M3 output(CLKOUTHIF) from M2 output (CLKOUT)).
For further information, See the note on OMAP5432 Technical Reference
Manual(SWPU282U) chapter 3.6.3.3.1 DPLLs Output Clocks Parameters,
and also the OMAP543x ES2.0 DM Operating Conditions Addendum v0.5
chapter 2.1 Micro Processor Unit (MPU). Equivalent information is
present in relevant DRA75x, 72x documentation(SPRUHP2E, SPRUHI2P).
Signed-off-by: Andrii Tseglytskyi andrii.tseglyts...@ti.com
Signed-off-by: Taras Kondratiuk ta...@ti.com
Signed-off-by: J Keerthy j-keer...@ti.com
Signed-off-by: Nishanth Menon n...@ti.com
[t-kri...@ti.com: added TRM / DM references for DCC clock rate]
Signed-off-by: Tero Kristo t-kri...@ti.com
---
arch/arm/mach-omap2/dpll3xxx.c |9 +
include/linux/clk/ti.h |4
2 files changed, 13 insertions(+)
diff --git a/arch/arm/mach-omap2/dpll3xxx.c b/arch/arm/mach-omap2/dpll3xxx.c
index fcd8036..6d7ba37 100644
--- a/arch/arm/mach-omap2/dpll3xxx.c
+++ b/arch/arm/mach-omap2/dpll3xxx.c
@@ -319,6 +319,15 @@ static int omap3_noncore_dpll_program(struct clk_hw_omap
*clk, u16 freqsel)
/* Set DPLL multiplier, divider */
v = omap2_clk_readl(clk, dd-mult_div1_reg);
+
+ /* Handle Duty Cycle Correction */
+ if (dd-dcc_mask) {
+ if (dd-last_rounded_rate = dd-dcc_rate)
+ v |= dd-dcc_mask; /* Enable DCC */
+ else
+ v = ~dd-dcc_mask; /* Disable DCC */
+ }
+
v = ~(dd-mult_mask | dd-div1_mask);
v |= dd-last_rounded_m __ffs(dd-mult_mask);
v |= (dd-last_rounded_n - 1) __ffs(dd-div1_mask);
diff --git a/include/linux/clk/ti.h b/include/linux/clk/ti.h
index 4a21a87..1f5c55e 100644
--- a/include/linux/clk/ti.h
+++ b/include/linux/clk/ti.h
@@ -41,6 +41,8 @@
* @idlest_reg: register containing the DPLL idle status bitfield
* @autoidle_mask: mask of the DPLL autoidle mode bitfield in @autoidle_reg
* @freqsel_mask: mask of the DPLL jitter correction bitfield in @control_reg
+ * @dcc_mask: mask of the DPLL DCC correction bitfield @mult_div1_reg
+ * @dcc_rate: rate atleast which DCC @dcc_mask must be set
* @idlest_mask: mask of the DPLL idle status bitfield in @idlest_reg
* @lpmode_mask: mask of the DPLL low-power mode bitfield in @control_reg
* @m4xen_mask: mask of the DPLL M4X multiplier bitfield in @control_reg
@@ -86,6 +88,8 @@ struct dpll_data {
u32 idlest_mask;
u32 dco_mask;
u32 sddiv_mask;
+ u32 dcc_mask;
+ unsigned long dcc_rate;
u32 lpmode_mask;
u32 m4xen_mask;
u8 auto_recal_bit;
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 3/3] ARM: dts: OMAP5/DRA7: use omap5-mpu-dpll-clock capable of dealing with higher frequencies
OMAP5432, DRA75x and DRA72x have MPU DPLLs that need Duty Cycle
Correction(DCC) to operate safely at frequencies = 1.4GHz.
Switch to ti,omap5-mpu-dpll-clock compatible property which provides
this support.
Signed-off-by: Nishanth Menon n...@ti.com
---
arch/arm/boot/dts/dra7xx-clocks.dtsi |2 +-
arch/arm/boot/dts/omap54xx-clocks.dtsi |2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm/boot/dts/dra7xx-clocks.dtsi
b/arch/arm/boot/dts/dra7xx-clocks.dtsi
index cfb8fc7..aac5522 100644
--- a/arch/arm/boot/dts/dra7xx-clocks.dtsi
+++ b/arch/arm/boot/dts/dra7xx-clocks.dtsi
@@ -277,7 +277,7 @@
dpll_mpu_ck: dpll_mpu_ck {
#clock-cells = 0;
- compatible = ti,omap4-dpll-clock;
+ compatible = ti,omap5-mpu-dpll-clock;
clocks = sys_clkin1, mpu_dpll_hs_clk_div;
reg = 0x0160, 0x0164, 0x016c, 0x0168;
};
diff --git a/arch/arm/boot/dts/omap54xx-clocks.dtsi
b/arch/arm/boot/dts/omap54xx-clocks.dtsi
index d487fda..465505c 100644
--- a/arch/arm/boot/dts/omap54xx-clocks.dtsi
+++ b/arch/arm/boot/dts/omap54xx-clocks.dtsi
@@ -362,7 +362,7 @@
dpll_mpu_ck: dpll_mpu_ck {
#clock-cells = 0;
- compatible = ti,omap4-dpll-clock;
+ compatible = ti,omap5-mpu-dpll-clock;
clocks = sys_clkin, mpu_dpll_hs_clk_div;
reg = 0x0160, 0x0164, 0x016c, 0x0168;
};
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 0/3] ARM: OMAP5+: Support Duty Cycle Correction(DCC)
Hi, This patch series has been carried over in vendor kernel for quiet few years now. Unfortunately, it was very recently re-discovered and upstream kernel is noticed to be broken for OMAP5 1.5GHz - at least we are operating DPLL at frequency higher than what it was intended to be when CPUFreq is enabled. Thankfully, with nominal voltage(we dont use AVS yet in upstream for the mentioned platforms) and margins in trimming, we have so far not crashed - but I strongly suspect this might be some boundary case survival. Verified on the following impacted platforms using 3.15-rc4 based vendor kernel. Before: OMAP5432: http://slexy.org/view/s20cs0qQFg DRA72x: http://slexy.org/view/s2TXtSa6mH (refused to lock) DRA75x: http://slexy.org/view/s20AW8MU5c After: OMAP5432: http://slexy.org/view/s21iAfWxpu DRA72x: http://slexy.org/view/s2hwsvGLmC (locks properly) DRA75x: http://slexy.org/view/s21ehw8WQn Hopefully, we can get these into some kernel revision in some form. NOTE: Support for 4470(which is the only other platform requiring DCC) is not present in upstream kernel and there are no plans to support that SoC, even if it is added at a later point, support can be extended as needed. Series based on v3.15-rc5 tag. Also available on my tree: https://github.com/nmenon/linux-2.6-playground/ branch: push/clock/dcc weblink: https://github.com/nmenon/linux-2.6-playground/commits/push/clock/dcc Verification: 3.15-rc4 based kernel - DRA75x-evm, 72x-evm, OMAP5uevm 3.15-rc5 - OMAP5uEVM(only one supporting 1.5GHz atm) Andrii Tseglytskyi (1): ARM: OMAP5+: dpll: support Duty Cycle Correction(DCC) Nishanth Menon (2): clk: dpll: support OMAP5 MPU DPLL that need special handling for higher frequencies ARM: dts: OMAP5/DRA7: use omap5-mpu-dpll-clock capable of dealing with higher frequencies .../devicetree/bindings/clock/ti/dpll.txt |1 + arch/arm/boot/dts/dra7xx-clocks.dtsi |2 +- arch/arm/boot/dts/omap54xx-clocks.dtsi |2 +- arch/arm/mach-omap2/dpll3xxx.c |9 + drivers/clk/ti/dpll.c | 21 include/linux/clk/ti.h |4 6 files changed, 37 insertions(+), 2 deletions(-) Regards, Nishanth Menon -- 1.7.9.5 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/3] clk: dpll: support OMAP5 MPU DPLL that need special handling for higher frequencies
MPU DPLL on OMAP5, DRA75x, DRA72x has a limitation on the maximum
frequency it can be locked at. Duty Cycle Correction circuit is used
to recover a correct duty cycle for achieving higher frequencies
(hardware internally switches output to M3 output(CLKOUTHIF) from M2
output (CLKOUT)).
So provide support to setup required data to handle Duty cycle by
the setting up the minimum frequency for DPLL. 1.4GHz is common
for all these devices and is based on Technical Reference Manual
information for OMAP5432((SWPU282U) chapter 3.6.3.3.1 DPLLs Output
Clocks Parameters, and equivalent information from DRA75x, DRA72x
documentation(SPRUHP2E, SPRUHI2P).
Signed-off-by: Nishanth Menon n...@ti.com
---
.../devicetree/bindings/clock/ti/dpll.txt |1 +
drivers/clk/ti/dpll.c | 21
2 files changed, 22 insertions(+)
diff --git a/Documentation/devicetree/bindings/clock/ti/dpll.txt
b/Documentation/devicetree/bindings/clock/ti/dpll.txt
index 30bfdb7..a4d0723 100644
--- a/Documentation/devicetree/bindings/clock/ti/dpll.txt
+++ b/Documentation/devicetree/bindings/clock/ti/dpll.txt
@@ -24,6 +24,7 @@ Required properties:
ti,omap4-dpll-core-clock,
ti,omap4-dpll-m4xen-clock,
ti,omap4-dpll-j-type-clock,
+ ti,omap5-mpu-dpll-clock,
ti,am3-dpll-no-gate-clock,
ti,am3-dpll-j-type-clock,
ti,am3-dpll-no-gate-j-type-clock,
diff --git a/drivers/clk/ti/dpll.c b/drivers/clk/ti/dpll.c
index 7e498a4..c06e94a 100644
--- a/drivers/clk/ti/dpll.c
+++ b/drivers/clk/ti/dpll.c
@@ -396,6 +396,27 @@ static void __init of_ti_omap4_dpll_setup(struct
device_node *node)
CLK_OF_DECLARE(ti_omap4_dpll_clock, ti,omap4-dpll-clock,
of_ti_omap4_dpll_setup);
+static void __init of_ti_omap5_mpu_dpll_setup(struct device_node *node)
+{
+ const struct dpll_data dd = {
+ .idlest_mask = 0x1,
+ .enable_mask = 0x7,
+ .autoidle_mask = 0x7,
+ .mult_mask = 0x7ff 8,
+ .div1_mask = 0x7f,
+ .max_multiplier = 2047,
+ .max_divider = 128,
+ .dcc_mask = BIT(22),
+ .dcc_rate = 14, /* DCC beyond 1.4GHz */
+ .min_divider = 1,
+ .modes = (1 DPLL_LOW_POWER_BYPASS) | (1 DPLL_LOCKED),
+ };
+
+ of_ti_dpll_setup(node, dpll_ck_ops, dd, DPLL_HAS_AUTOIDLE);
+}
+CLK_OF_DECLARE(of_ti_omap5_mpu_dpll_clock, ti,omap5-mpu-dpll-clock,
+ of_ti_omap5_mpu_dpll_setup);
+
static void __init of_ti_omap4_core_dpll_setup(struct device_node *node)
{
const struct dpll_data dd = {
--
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 05/19] OMAPDSS: Kconfig: Add depencies and help section to OMAP4_DSS_HDMI_AUDIO
Hi, On 12/05/14 12:12, Jyri Sarha wrote: Signed-off-by: Jyri Sarha jsa...@ti.com --- drivers/video/fbdev/omap2/dss/Kconfig | 10 +- 1 file changed, 9 insertions(+), 1 deletion(-) diff --git a/drivers/video/fbdev/omap2/dss/Kconfig b/drivers/video/fbdev/omap2/dss/Kconfig index 8921a7a..ecc2f50 100644 --- a/drivers/video/fbdev/omap2/dss/Kconfig +++ b/drivers/video/fbdev/omap2/dss/Kconfig @@ -70,7 +70,15 @@ config OMAP4_DSS_HDMI HDMI support for OMAP4 based SoCs. config OMAP4_DSS_HDMI_AUDIO - bool + bool HDMI audio support for OMAP4 + depends on OMAP4_DSS_HDMI + depends on SND_OMAP_SOC=y || OMAP2_DSS = SND_OMAP_SOC + default y + help + HDMI audio support for OMAP4 based SoCs. Adds integrated + ASoC Digital Audio Interface component driver into OMAPDSS + module. Select SND_SOC_HDMI_CODEC and SND_SIMPLE_CARD with + devicetree description for full HDMI audio support. What does for full HDMI audio support mean? What's the partial support? =) Tomi signature.asc Description: OpenPGP digital signature
[PATCH v6 0/4] add parallel NAND support for TI's new OMAPx and AMxx platforms (Part-2)
*changes v5 - v6* - removed explicit disabling of GPMC and ELM in am335x-bone-memorycape.dts as both modules are already disabled by default in am33xx.dtsi - fixed comments for range and reg properties. keeping it consistent across platforms. - fixed reg size property. Using 'exact' register space as in hardware. - fixed DT properties for wait-pin monitoring. Added gpmc,wait-pin = - using lower-case letter for hex digits Rebased on git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap :omap-for-v3.16/dt *changes v4 - v5* use lower-case hexadecimal numbers add comments for using different memory sizes in range and reg properties fix 'reg size' property for GPMC and ELM nodes in dra7.dtsi *changes v3 - v4* fixed reg and range property for all GPMC DT nodes added fix for am335x-evm and am437x-epos-evm rebased on git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap +omap-for-v3.16/dt *changes v2 - v3* rebased on git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap :master merged leftover patches (dra7-evm and am43x-epos-evm fix) from Part-1 series *changes v1 - v2* [PATCH v2 1/2] created new DTS for memory-capes based on following feedbacks http://www.spinics.net/lists/linux-omap/msg104348.html from 'Nishanth Menon n...@ti.com' http://www.spinics.net/lists/linux-omap/msg104447.html from 'Tony Lindgren t...@atomide.com' [PATCH v2 2/2] same as [PATCH v1 1/3] *original v1* This patch-set adds parallel NAND support on following TI platforms - AM335x (am335x-bone LT, am335x-boneblack): disabled by default - AM43xx (am437x-gp-evm) Minal Shah (1): ARM: dts: dra7: add support for parallel NAND flash Pekon Gupta (3): ARM: dts: am335x-bone: add support for beaglebone NAND cape ARM: dts: am437x-gp-evm: add support for parallel NAND flash ARM: dts: am43xx: fix starting offset of NAND.filesystem MTD partition arch/arm/boot/dts/am335x-bone-memory-cape.dts | 123 ++ arch/arm/boot/dts/am335x-bone.dts | 1 + arch/arm/boot/dts/am335x-boneblack.dts| 1 + arch/arm/boot/dts/am437x-gp-evm.dts | 108 ++ arch/arm/boot/dts/am43x-epos-evm.dts | 2 +- arch/arm/boot/dts/dra7-evm.dts| 118 arch/arm/boot/dts/dra7.dtsi | 20 + 7 files changed, 372 insertions(+), 1 deletion(-) create mode 100644 arch/arm/boot/dts/am335x-bone-memory-cape.dts -- 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 v6 4/4] 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
Reviewed-by: Javier Martinez Canillas jav...@dowhile0.org
---
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 2a0fbbb..ad362c5 100644
--- a/arch/arm/boot/dts/am43x-epos-evm.dts
+++ b/arch/arm/boot/dts/am43x-epos-evm.dts
@@ -366,7 +366,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 v6 2/4] 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
Reviewed-by: Javier Martinez Canillas jav...@dowhile0.org
---
arch/arm/boot/dts/am437x-gp-evm.dts | 108
1 file changed, 108 insertions(+)
diff --git a/arch/arm/boot/dts/am437x-gp-evm.dts
b/arch/arm/boot/dts/am437x-gp-evm.dts
index 30ace1b..97b71e6 100644
--- a/arch/arm/boot/dts/am437x-gp-evm.dts
+++ b/arch/arm/boot/dts/am437x-gp-evm.dts
@@ -150,6 +150,27 @@
0x14c (PIN_INPUT_PULLDOWN | MUX_MODE7)
;
};
+
+ 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 {
@@ -246,3 +267,90 @@
phy_id = davinci_mdio, 0;
phy-mode = rgmii;
};
+
+elm {
+ status = okay;
+};
+
+gpmc {
+ status = okay;
+ pinctrl-names = default;
+ pinctrl-0 = nand_flash_x8;
+ ranges = 0 0 0 0x0100;/* minimum GPMC partition = 16MB */
+ nand@0,0 {
+ reg = 0 0 0x37c; /* device IO registers */
+ 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-pin = 0;
+ gpmc,wait-on-read;
+ gpmc,wait-on-write;
+ 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 =
[PATCH v6 1/4] 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
- Selection of boot modes can be controlled via DIP switch(SW2) present on
Memory Expander cape, so first boot via MMC or other sources to flash NAND
device and then switch to SW2[SWITCH_BOOT]=ON to boot from NAND Cape.
SW2[SWITCH_BOOT] == OFF follow default boot order MMC- SPI - UART - USB
SW2[SWITCH_BOOT] == ON boot mode selected via DIP switch(SW2)
- 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
Reviewed-by: Javier Martinez Canillas jav...@dowhile0.org
---
arch/arm/boot/dts/am335x-bone-memory-cape.dts | 123 ++
arch/arm/boot/dts/am335x-bone.dts | 1 +
arch/arm/boot/dts/am335x-boneblack.dts| 1 +
3 files changed, 125 insertions(+)
create mode 100644 arch/arm/boot/dts/am335x-bone-memory-cape.dts
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..f9940bc
--- /dev/null
+++ b/arch/arm/boot/dts/am335x-bone-memory-cape.dts
@@ -0,0 +1,123 @@
+/*
+ * Copyright (C) 2014 Texas Instruments Incorporated - http://www.ti.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 DTS adds supports for capes using GPMC interface to connect external
+ * memory like NAND, NOR Flash to Beaglebone-LT (white) and Beaglebone-Black.
+ */
+
+
+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
[PATCH v6 3/4] ARM: dts: dra7: add support for parallel NAND flash
From: Minal Shah minalks...@gmail.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 minalks...@gmail.com
Signed-off-by: Pekon Gupta pe...@ti.com
Reviewed-by: Javier Martinez Canillas jav...@dowhile0.org
---
arch/arm/boot/dts/dra7-evm.dts | 118 +
arch/arm/boot/dts/dra7.dtsi| 20 +++
2 files changed, 138 insertions(+)
diff --git a/arch/arm/boot/dts/dra7-evm.dts b/arch/arm/boot/dts/dra7-evm.dts
index ec77907..e624c17 100644
--- a/arch/arm/boot/dts/dra7-evm.dts
+++ b/arch/arm/boot/dts/dra7-evm.dts
@@ -120,6 +120,37 @@
0x284 (PIN_INPUT_SLEW | MUX_MODE0) /* usb2_drvvbus */
;
};
+
+ 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 {
@@ -377,3 +408,90 @@
pinctrl-names = default;
pinctrl-0 = usb2_pins;
};
+
+elm {
+ status = okay;
+};
+
+gpmc {
+ status = okay;
+ pinctrl-names = default;
+ pinctrl-0 = nand_flash_x16;
+ ranges = 0 0 0 0x0100;/* minimum GPMC partition = 16MB */
+ nand@0,0 {
+ reg = 0 0 0x37c; /* device IO registers */
+ 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-pin = 0;
+ gpmc,wait-on-read;
+ gpmc,wait-on-write;
+ 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
+
Re: [PATCH 14/19] ARM: omap4-panda-common.dtsi: Add HDMI audio nodes
On 12/05/14 12:12, Jyri Sarha wrote:
Adds a simple-card sound node for HDMI audio, the associated
hdmi-codec node, and sound-dai-cells propeties to the DAI nodes.
Signed-off-by: Jyri Sarha jsa...@ti.com
---
arch/arm/boot/dts/omap4-panda-common.dtsi | 21 -
1 file changed, 20 insertions(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/omap4-panda-common.dtsi
b/arch/arm/boot/dts/omap4-panda-common.dtsi
index d2c45bf..c04f453 100644
--- a/arch/arm/boot/dts/omap4-panda-common.dtsi
+++ b/arch/arm/boot/dts/omap4-panda-common.dtsi
@@ -41,7 +41,7 @@
};
};
- sound: sound {
+ sound: sound@0 {
compatible = ti,abe-twl6040;
ti,model = PandaBoard;
@@ -65,6 +65,24 @@
AFMR, Line In;
};
+ sound@1 {
+ compatible = simple-audio-card;
+
+ simple-audio-card,cpu {
+ sound-dai = hdmi;
+ };
+
+ simple-audio-card,codec {
+ sound-dai = hdmi_audio;
+ };
+ };
+
+ hdmi_audio: hdmi_audio@0 {
+ #sound-dai-cells = 0;
+ compatible = linux,hdmi-audio;
+ status = okay;
+ };
+
/* HS USB Port 1 Power */
hsusb1_power: hsusb1_power_reg {
compatible = regulator-fixed;
@@ -512,6 +530,7 @@
};
hdmi {
+ #sound-dai-cells = 0;
status = ok;
vdda-supply = vdac;
Maybe this is how this has to be done, but I'll still ask:
Considering that the HDMI audio is basically inseparable part of the
OMAP HDMI video, and if a board has HDMI video connector connected to
the SoC's HDMI, then it has HDMI audio.
So all of the above .dts changes are already implied when we have HDMI
video on the board. Is there no way to prevent every board needing to
add those exact same nodes to get HDMI audio?
Tomi
signature.asc
Description: OpenPGP digital signature
Re: [PATCH 14/19] ARM: omap4-panda-common.dtsi: Add HDMI audio nodes
On Fri, May 16, 2014 at 02:04:44PM +0300, Tomi Valkeinen wrote: So all of the above .dts changes are already implied when we have HDMI video on the board. Is there no way to prevent every board needing to add those exact same nodes to get HDMI audio? You can always instantiate devices directly from the HDMI controller code, there's no need to put things in DT at all. signature.asc Description: Digital signature
Re: [PATCH 05/19] OMAPDSS: Kconfig: Add depencies and help section to OMAP4_DSS_HDMI_AUDIO
On 05/16/2014 01:52 PM, Tomi Valkeinen wrote: Hi, On 12/05/14 12:12, Jyri Sarha wrote: Signed-off-by: Jyri Sarha jsa...@ti.com --- drivers/video/fbdev/omap2/dss/Kconfig | 10 +- 1 file changed, 9 insertions(+), 1 deletion(-) diff --git a/drivers/video/fbdev/omap2/dss/Kconfig b/drivers/video/fbdev/omap2/dss/Kconfig index 8921a7a..ecc2f50 100644 --- a/drivers/video/fbdev/omap2/dss/Kconfig +++ b/drivers/video/fbdev/omap2/dss/Kconfig @@ -70,7 +70,15 @@ config OMAP4_DSS_HDMI HDMI support for OMAP4 based SoCs. config OMAP4_DSS_HDMI_AUDIO - bool + bool HDMI audio support for OMAP4 + depends on OMAP4_DSS_HDMI + depends on SND_OMAP_SOC=y || OMAP2_DSS = SND_OMAP_SOC + default y + help + HDMI audio support for OMAP4 based SoCs. Adds integrated + ASoC Digital Audio Interface component driver into OMAPDSS + module. Select SND_SOC_HDMI_CODEC and SND_SIMPLE_CARD with + devicetree description for full HDMI audio support. What does for full HDMI audio support mean? What's the partial support? =) The hdmi driver provides a digital audio interface (DAI) which can be used to transmit audio over the HDMI cable. The ASoC DAI component driver provides just that functionality. A machine, platform, and (in this case a dummy) codec component driver is also needed for a complete ALSA device functionality. Anyway, I look into Mark's suggestion of instantiating all the necessary component drivers from the HDMI driver. 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
Re: [PATCH v6 1/4] ARM: dts: am335x-bone: add support for beaglebone NAND cape
Hello Pekon, On 16 May 04:33 PM, Pekon Gupta wrote: [..] + gpmc,wait-pin = 0; + gpmc,wait-on-read; + gpmc,wait-on-write; Thanks for adding the wait-pin property. I think the other boards also needs this change. Javier, do you have a IGEP Aquila with NAND to try? Pekon, have you noticed that there's no devicetree property to enable ready/busy? In other words, the NAND driver dev_ready field will never be true when probed from DT. -- Ezequiel Garcia, VanguardiaSur www.vanguardiasur.com.ar -- 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 13/13] ARM/platform_data: edma: Remove redundant/unused parameters from edma_soc_info
The following parameters are no longer needed by the edma driver since the
information can be obtained from the IP's CCCFG register:
n_channel, n_region, n_slot and n_tc.
Remove the n_cc as well since in this context it has no meaning. We have
separate edma_soc_info struct/eDMA3_CC instance so this member does not
make any sense (and the driver no longer uses it).
Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
---
include/linux/platform_data/edma.h | 7 ---
1 file changed, 7 deletions(-)
diff --git a/include/linux/platform_data/edma.h
b/include/linux/platform_data/edma.h
index 633e196ebdf2..eb8d5627d080 100644
--- a/include/linux/platform_data/edma.h
+++ b/include/linux/platform_data/edma.h
@@ -158,13 +158,6 @@ struct edma_rsv_info {
/* platform_data for EDMA driver */
struct edma_soc_info {
-
- /* how many dma resources of each type */
- unsignedn_channel;
- unsignedn_region;
- unsignedn_slot;
- unsignedn_tc;
- unsignedn_cc;
/*
* Default queue is expected to be a low-priority queue.
* This way, long transfers on the default queue started
--
1.9.3
--
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 12/13] ARM: davinci: Remove redundant/unused parameters for edma
The following parameters are no longer needed by the edma driver since the
information can be obtained from the IP's CCCFG register:
n_channel, n_region, n_slot and n_tc.
Remove the initialization of n_cc as well since in this context it has no
meaning. We have separate edma_soc_info struct/eDMA3_CC instance so this
member does not make any sense (and the driver no longer uses it).
Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
---
arch/arm/mach-davinci/devices-da8xx.c | 15 ---
arch/arm/mach-davinci/dm355.c | 5 -
arch/arm/mach-davinci/dm365.c | 5 -
arch/arm/mach-davinci/dm644x.c| 5 -
arch/arm/mach-davinci/dm646x.c| 5 -
5 files changed, 35 deletions(-)
diff --git a/arch/arm/mach-davinci/devices-da8xx.c
b/arch/arm/mach-davinci/devices-da8xx.c
index 7f376e54b266..b85b781b05fd 100644
--- a/arch/arm/mach-davinci/devices-da8xx.c
+++ b/arch/arm/mach-davinci/devices-da8xx.c
@@ -148,11 +148,6 @@ static s8 da850_queue_priority_mapping[][2] = {
};
static struct edma_soc_info da830_edma_cc0_info = {
- .n_channel = 32,
- .n_region = 4,
- .n_slot = 128,
- .n_tc = 2,
- .n_cc = 1,
.queue_priority_mapping = da8xx_queue_priority_mapping,
.default_queue = EVENTQ_1,
};
@@ -163,20 +158,10 @@ static struct edma_soc_info *da830_edma_info[EDMA_MAX_CC]
= {
static struct edma_soc_info da850_edma_cc_info[] = {
{
- .n_channel = 32,
- .n_region = 4,
- .n_slot = 128,
- .n_tc = 2,
- .n_cc = 1,
.queue_priority_mapping = da8xx_queue_priority_mapping,
.default_queue = EVENTQ_1,
},
{
- .n_channel = 32,
- .n_region = 4,
- .n_slot = 128,
- .n_tc = 1,
- .n_cc = 1,
.queue_priority_mapping = da850_queue_priority_mapping,
.default_queue = EVENTQ_0,
},
diff --git a/arch/arm/mach-davinci/dm355.c b/arch/arm/mach-davinci/dm355.c
index e27f7ff54570..2f3ed3a58d57 100644
--- a/arch/arm/mach-davinci/dm355.c
+++ b/arch/arm/mach-davinci/dm355.c
@@ -577,11 +577,6 @@ queue_priority_mapping[][2] = {
};
static struct edma_soc_info edma_cc0_info = {
- .n_channel = 64,
- .n_region = 4,
- .n_slot = 128,
- .n_tc = 2,
- .n_cc = 1,
.queue_priority_mapping = queue_priority_mapping,
.default_queue = EVENTQ_1,
};
diff --git a/arch/arm/mach-davinci/dm365.c b/arch/arm/mach-davinci/dm365.c
index 88835b0aaead..0ae8114f5cc9 100644
--- a/arch/arm/mach-davinci/dm365.c
+++ b/arch/arm/mach-davinci/dm365.c
@@ -863,11 +863,6 @@ dm365_queue_priority_mapping[][2] = {
};
static struct edma_soc_info edma_cc0_info = {
- .n_channel = 64,
- .n_region = 4,
- .n_slot = 256,
- .n_tc = 4,
- .n_cc = 1,
.queue_priority_mapping = dm365_queue_priority_mapping,
.default_queue = EVENTQ_3,
};
diff --git a/arch/arm/mach-davinci/dm644x.c b/arch/arm/mach-davinci/dm644x.c
index 8ea34be879b4..dc52657909c4 100644
--- a/arch/arm/mach-davinci/dm644x.c
+++ b/arch/arm/mach-davinci/dm644x.c
@@ -507,11 +507,6 @@ queue_priority_mapping[][2] = {
};
static struct edma_soc_info edma_cc0_info = {
- .n_channel = 64,
- .n_region = 4,
- .n_slot = 128,
- .n_tc = 2,
- .n_cc = 1,
.queue_priority_mapping = queue_priority_mapping,
.default_queue = EVENTQ_1,
};
diff --git a/arch/arm/mach-davinci/dm646x.c b/arch/arm/mach-davinci/dm646x.c
index 97e90dc5ed43..6c3bbea7d77d 100644
--- a/arch/arm/mach-davinci/dm646x.c
+++ b/arch/arm/mach-davinci/dm646x.c
@@ -543,11 +543,6 @@ dm646x_queue_priority_mapping[][2] = {
};
static struct edma_soc_info edma_cc0_info = {
- .n_channel = 64,
- .n_region = 6,/* 0-1, 4-7 */
- .n_slot = 512,
- .n_tc = 4,
- .n_cc = 1,
.queue_priority_mapping = dm646x_queue_priority_mapping,
.default_queue = EVENTQ_1,
};
--
1.9.3
--
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 10/13] ARM: dts: am33xx: Remove obsolete properties from edma node
dma-channels, ti,edma-regions and ti,edma-slots no longer needed in DT since
the the same information is available in the IP's CCCFG register.
Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
---
arch/arm/boot/dts/am33xx.dtsi | 3 ---
1 file changed, 3 deletions(-)
diff --git a/arch/arm/boot/dts/am33xx.dtsi b/arch/arm/boot/dts/am33xx.dtsi
index f1eea4af40ed..37d4cad4dd38 100644
--- a/arch/arm/boot/dts/am33xx.dtsi
+++ b/arch/arm/boot/dts/am33xx.dtsi
@@ -147,9 +147,6 @@
0x44e10f90 0x40;
interrupts = 12 13 14;
#dma-cells = 1;
- dma-channels = 64;
- ti,edma-regions = 4;
- ti,edma-slots = 256;
};
gpio0: gpio@44e07000 {
--
1.9.3
--
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 11/13] ARM: dts: am4372: Remove obsolete properties from edma node
dma-channels, ti,edma-regions and ti,edma-slots no longer needed in DT since
the the same information is available in the IP's CCCFG register.
Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
---
arch/arm/boot/dts/am4372.dtsi | 3 ---
1 file changed, 3 deletions(-)
diff --git a/arch/arm/boot/dts/am4372.dtsi b/arch/arm/boot/dts/am4372.dtsi
index 03a225505126..b9f83b705f4b 100644
--- a/arch/arm/boot/dts/am4372.dtsi
+++ b/arch/arm/boot/dts/am4372.dtsi
@@ -108,9 +108,6 @@
GIC_SPI 13 IRQ_TYPE_LEVEL_HIGH,
GIC_SPI 14 IRQ_TYPE_LEVEL_HIGH;
#dma-cells = 1;
- dma-channels = 64;
- ti,edma-regions = 4;
- ti,edma-slots = 256;
};
uart0: serial@44e09000 {
--
1.9.3
--
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 08/13] ARM: edma: Get IP configuration from HW (number of channels, tc, etc)
From CCCFG register of eDMA3 we can get all the needed information for the
driver about the IP:
Number of channels: NUM_DMACH
Number of regions: NUM_REGN
Number of slots (PaRAM sets): NUM_PAENTRY
Number of TC/EQ: NUM_EVQUE
In case when booted with DT or the queue_priority_mapping is not provided
set up a default priority map.
Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
---
arch/arm/common/edma.c | 115 +++--
1 file changed, 73 insertions(+), 42 deletions(-)
diff --git a/arch/arm/common/edma.c b/arch/arm/common/edma.c
index aa9473cb0c23..485be42519b9 100644
--- a/arch/arm/common/edma.c
+++ b/arch/arm/common/edma.c
@@ -102,7 +102,13 @@
#define PARM_OFFSET(param_no) (EDMA_PARM + ((param_no) 5))
#define EDMA_DCHMAP0x0100 /* 64 registers */
-#define CHMAP_EXISTBIT(24)
+
+/* CCCFG register */
+#define GET_NUM_DMACH(x) (x 0x7) /* bits 0-2 */
+#define GET_NUM_PAENTRY(x) ((x 0x7000) 12) /* bits 12-14 */
+#define GET_NUM_EVQUE(x) ((x 0x7) 16) /* bits 16-18 */
+#define GET_NUM_REGN(x)((x 0x30) 20) /* bits 20-21 */
+#define CHMAP_EXISTBIT(24)
#define EDMA_MAX_DMACH 64
#define EDMA_MAX_PARAMENTRY 512
@@ -1408,6 +1414,67 @@ void edma_clear_event(unsigned channel)
}
EXPORT_SYMBOL(edma_clear_event);
+static int edma_setup_from_hw(struct device *dev, struct edma_soc_info *pdata,
+ struct edma *edma_cc)
+{
+ int i;
+ u32 value, cccfg;
+ s8 (*queue_priority_map)[2];
+
+ /* Decode the eDMA3 configuration from CCCFG register */
+ cccfg = edma_read(0, EDMA_CCCFG);
+
+ value = GET_NUM_REGN(cccfg);
+ edma_cc-num_region = BIT(value);
+
+ value = GET_NUM_DMACH(cccfg);
+ edma_cc-num_channels = BIT(value + 1);
+
+ value = GET_NUM_PAENTRY(cccfg);
+ edma_cc-num_slots = BIT(value + 4);
+
+ value = GET_NUM_EVQUE(cccfg);
+ edma_cc-num_tc = value + 1;
+
+ dev_dbg(dev, eDMA3 HW configuration (cccfg: 0x%08x):\n, cccfg);
+ dev_dbg(dev, num_region: %u\n, edma_cc-num_region);
+ dev_dbg(dev, num_channel: %u\n, edma_cc-num_channels);
+ dev_dbg(dev, num_slot: %u\n, edma_cc-num_slots);
+ dev_dbg(dev, num_tc: %u\n, edma_cc-num_tc);
+
+ /* Nothing need to be done if queue priority is provided */
+ if (pdata-queue_priority_mapping)
+ return 0;
+
+ /*
+* Configure TC/queue priority as follows:
+* Q0 - priority 0
+* Q1 - priority 1
+* Q2 - priority 2
+* ...
+* The meaning of priority numbers: 0 highest priority, 7 lowest
+* priority. So Q0 is the highest priority queue and the last queue has
+* the lowest priority.
+*/
+ queue_priority_map = devm_kzalloc(dev,
+ (edma_cc-num_tc + 1) * sizeof(s8),
+ GFP_KERNEL);
+ if (!queue_priority_map)
+ return -ENOMEM;
+
+ for (i = 0; i edma_cc-num_tc; i++) {
+ queue_priority_map[i][0] = i;
+ queue_priority_map[i][1] = i;
+ }
+ queue_priority_map[i][0] = -1;
+ queue_priority_map[i][1] = -1;
+
+ pdata-queue_priority_mapping = queue_priority_map;
+ pdata-default_queue = 0;
+
+ return 0;
+}
+
#if IS_ENABLED(CONFIG_OF) IS_ENABLED(CONFIG_DMADEVICES)
static int edma_xbar_event_map(struct device *dev, struct device_node *node,
@@ -1458,50 +1525,16 @@ static int edma_of_parse_dt(struct device *dev,
struct device_node *node,
struct edma_soc_info *pdata)
{
- int ret = 0, i;
- u32 value;
+ int ret = 0;
struct property *prop;
size_t sz;
struct edma_rsv_info *rsv_info;
- s8 (*queue_priority_map)[2];
-
- ret = of_property_read_u32(node, dma-channels, value);
- if (ret 0)
- return ret;
- pdata-n_channel = value;
-
- ret = of_property_read_u32(node, ti,edma-regions, value);
- if (ret 0)
- return ret;
- pdata-n_region = value;
-
- ret = of_property_read_u32(node, ti,edma-slots, value);
- if (ret 0)
- return ret;
- pdata-n_slot = value;
-
- pdata-n_tc = 3;
rsv_info = devm_kzalloc(dev, sizeof(struct edma_rsv_info), GFP_KERNEL);
if (!rsv_info)
return -ENOMEM;
pdata-rsv = rsv_info;
- queue_priority_map = devm_kzalloc(dev, 8*sizeof(s8), GFP_KERNEL);
- if (!queue_priority_map)
- return -ENOMEM;
-
- for (i = 0; i 3; i++) {
- queue_priority_map[i][0] = i;
- queue_priority_map[i][1] = i;
- }
- queue_priority_map[i][0] = -1;
- queue_priority_map[i][1] = -1;
-
- pdata-queue_priority_mapping = queue_priority_map;
-
- pdata-default_queue = 0;
-
[PATCH v3 09/13] dt/bindings: ti,edma: Remove redundant properties from documentation
From CCCFG register of eDMA3 we can get all the needed information for the
driver about the IP:
Number of channels: NUM_DMACH
Number of regions: NUM_REGN
Number of slots (PaRAM sets): NUM_PAENTRY
Number of TC/EQ: NUM_EVQUE
The ti,edma-regions; ti,edma-slots and dma-channels in DT are
redundant since the very same information can be obtained from the HW.
The mentioned properties are deprecated.
Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
---
Documentation/devicetree/bindings/dma/ti-edma.txt | 13 +++--
1 file changed, 7 insertions(+), 6 deletions(-)
diff --git a/Documentation/devicetree/bindings/dma/ti-edma.txt
b/Documentation/devicetree/bindings/dma/ti-edma.txt
index 68ff2137bae7..5ba525a10035 100644
--- a/Documentation/devicetree/bindings/dma/ti-edma.txt
+++ b/Documentation/devicetree/bindings/dma/ti-edma.txt
@@ -2,11 +2,8 @@ TI EDMA
Required properties:
- compatible : ti,edma3
-- ti,edma-regions: Number of regions
-- ti,edma-slots: Number of slots
- #dma-cells: Should be set to 1
Clients should use a single channel number per DMA request.
-- dma-channels: Specify total DMA channels per CC
- reg: Memory map for accessing module
- interrupt-parent: Interrupt controller the interrupt is routed through
- interrupts: Exactly 3 interrupts need to be specified in the order:
@@ -17,6 +14,13 @@ Optional properties:
- ti,hwmods: Name of the hwmods associated to the EDMA
- ti,edma-xbar-event-map: Crossbar event to channel map
+Deprecated properties:
+Listed here in case one wants to boot an old kernel with new DTB. These
+properties might need to be added to the new DTS files.
+- ti,edma-regions: Number of regions
+- ti,edma-slots: Number of slots
+- dma-channels: Specify total DMA channels per CC
+
Example:
edma: edma@4900 {
@@ -26,9 +30,6 @@ edma: edma@4900 {
compatible = ti,edma3;
ti,hwmods = tpcc, tptc0, tptc1, tptc2;
#dma-cells = 1;
- dma-channels = 64;
- ti,edma-regions = 4;
- ti,edma-slots = 256;
ti,edma-xbar-event-map = /bits/ 16 1 12
2 13;
};
--
1.9.3
--
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 04/13] ARM: davinci: Remove eDMA3 queue_tc_mapping data from edma_soc_info
It is ignored by the edma driver since we are just setting back the default
mapping of TC - Queue.
Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
---
arch/arm/mach-davinci/devices-da8xx.c | 16
arch/arm/mach-davinci/dm355.c | 9 -
arch/arm/mach-davinci/dm365.c | 11 ---
arch/arm/mach-davinci/dm644x.c| 9 -
arch/arm/mach-davinci/dm646x.c| 11 ---
5 files changed, 56 deletions(-)
diff --git a/arch/arm/mach-davinci/devices-da8xx.c
b/arch/arm/mach-davinci/devices-da8xx.c
index 56ea41d5f849..7f376e54b266 100644
--- a/arch/arm/mach-davinci/devices-da8xx.c
+++ b/arch/arm/mach-davinci/devices-da8xx.c
@@ -134,13 +134,6 @@ struct platform_device da8xx_serial_device[] = {
}
};
-static s8 da8xx_queue_tc_mapping[][2] = {
- /* {event queue no, TC no} */
- {0, 0},
- {1, 1},
- {-1, -1}
-};
-
static s8 da8xx_queue_priority_mapping[][2] = {
/* {event queue no, Priority} */
{0, 3},
@@ -148,12 +141,6 @@ static s8 da8xx_queue_priority_mapping[][2] = {
{-1, -1}
};
-static s8 da850_queue_tc_mapping[][2] = {
- /* {event queue no, TC no} */
- {0, 0},
- {-1, -1}
-};
-
static s8 da850_queue_priority_mapping[][2] = {
/* {event queue no, Priority} */
{0, 3},
@@ -166,7 +153,6 @@ static struct edma_soc_info da830_edma_cc0_info = {
.n_slot = 128,
.n_tc = 2,
.n_cc = 1,
- .queue_tc_mapping = da8xx_queue_tc_mapping,
.queue_priority_mapping = da8xx_queue_priority_mapping,
.default_queue = EVENTQ_1,
};
@@ -182,7 +168,6 @@ static struct edma_soc_info da850_edma_cc_info[] = {
.n_slot = 128,
.n_tc = 2,
.n_cc = 1,
- .queue_tc_mapping = da8xx_queue_tc_mapping,
.queue_priority_mapping = da8xx_queue_priority_mapping,
.default_queue = EVENTQ_1,
},
@@ -192,7 +177,6 @@ static struct edma_soc_info da850_edma_cc_info[] = {
.n_slot = 128,
.n_tc = 1,
.n_cc = 1,
- .queue_tc_mapping = da850_queue_tc_mapping,
.queue_priority_mapping = da850_queue_priority_mapping,
.default_queue = EVENTQ_0,
},
diff --git a/arch/arm/mach-davinci/dm355.c b/arch/arm/mach-davinci/dm355.c
index 07381d8cea62..e27f7ff54570 100644
--- a/arch/arm/mach-davinci/dm355.c
+++ b/arch/arm/mach-davinci/dm355.c
@@ -569,14 +569,6 @@ static u8 dm355_default_priorities[DAVINCI_N_AINTC_IRQ] = {
/*--*/
static s8
-queue_tc_mapping[][2] = {
- /* {event queue no, TC no} */
- {0, 0},
- {1, 1},
- {-1, -1},
-};
-
-static s8
queue_priority_mapping[][2] = {
/* {event queue no, Priority} */
{0, 3},
@@ -590,7 +582,6 @@ static struct edma_soc_info edma_cc0_info = {
.n_slot = 128,
.n_tc = 2,
.n_cc = 1,
- .queue_tc_mapping = queue_tc_mapping,
.queue_priority_mapping = queue_priority_mapping,
.default_queue = EVENTQ_1,
};
diff --git a/arch/arm/mach-davinci/dm365.c b/arch/arm/mach-davinci/dm365.c
index 08a61b938333..88835b0aaead 100644
--- a/arch/arm/mach-davinci/dm365.c
+++ b/arch/arm/mach-davinci/dm365.c
@@ -853,16 +853,6 @@ static u8 dm365_default_priorities[DAVINCI_N_AINTC_IRQ] = {
/* Four Transfer Controllers on DM365 */
static s8
-dm365_queue_tc_mapping[][2] = {
- /* {event queue no, TC no} */
- {0, 0},
- {1, 1},
- {2, 2},
- {3, 3},
- {-1, -1},
-};
-
-static s8
dm365_queue_priority_mapping[][2] = {
/* {event queue no, Priority} */
{0, 7},
@@ -878,7 +868,6 @@ static struct edma_soc_info edma_cc0_info = {
.n_slot = 256,
.n_tc = 4,
.n_cc = 1,
- .queue_tc_mapping = dm365_queue_tc_mapping,
.queue_priority_mapping = dm365_queue_priority_mapping,
.default_queue = EVENTQ_3,
};
diff --git a/arch/arm/mach-davinci/dm644x.c b/arch/arm/mach-davinci/dm644x.c
index 5debffba4b24..8ea34be879b4 100644
--- a/arch/arm/mach-davinci/dm644x.c
+++ b/arch/arm/mach-davinci/dm644x.c
@@ -499,14 +499,6 @@ static u8 dm644x_default_priorities[DAVINCI_N_AINTC_IRQ] =
{
/*--*/
static s8
-queue_tc_mapping[][2] = {
- /* {event queue no, TC no} */
- {0, 0},
- {1, 1},
- {-1, -1},
-};
-
-static s8
queue_priority_mapping[][2] = {
/* {event queue no, Priority} */
{0, 3},
@@ -520,7 +512,6 @@ static struct
[PATCH v3 07/13] ARM: edma: Save number of regions from pdata to struct edma
To be consistent in the code that we take parameters from edma_cc[j] struct
and not randomly from info[j] as well.
Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
---
arch/arm/common/edma.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/arch/arm/common/edma.c b/arch/arm/common/edma.c
index 929a03e4749c..aa9473cb0c23 100644
--- a/arch/arm/common/edma.c
+++ b/arch/arm/common/edma.c
@@ -1628,6 +1628,7 @@ static int edma_probe(struct platform_device *pdev)
edma_cc[j]-num_tc = info[j]-n_tc;
edma_cc[j]-default_queue = info[j]-default_queue;
+ edma_cc[j]-num_region = info[j]-n_region;
dev_dbg(pdev-dev, DMA REG BASE ADDR=%p\n,
edmacc_regs_base[j]);
@@ -1725,7 +1726,7 @@ static int edma_probe(struct platform_device *pdev)
if (edma_read(j, EDMA_CCCFG) CHMAP_EXIST)
map_dmach_param(j);
- for (i = 0; i info[j]-n_region; i++) {
+ for (i = 0; i edma_cc[j]-num_region; i++) {
edma_write_array2(j, EDMA_DRAE, i, 0, 0x0);
edma_write_array2(j, EDMA_DRAE, i, 1, 0x0);
edma_write_array(j, EDMA_QRAE, i, 0x0);
--
1.9.3
--
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 v6 2/4] ARM: dts: am437x-gp-evm: add support for parallel NAND flash
Hi Pekon,
On 05/16/2014 02:03 PM, 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
Reviewed-by: Javier Martinez Canillas jav...@dowhile0.org
---
arch/arm/boot/dts/am437x-gp-evm.dts | 108
1 file changed, 108 insertions(+)
diff --git a/arch/arm/boot/dts/am437x-gp-evm.dts
b/arch/arm/boot/dts/am437x-gp-evm.dts
index 30ace1b..97b71e6 100644
--- a/arch/arm/boot/dts/am437x-gp-evm.dts
+++ b/arch/arm/boot/dts/am437x-gp-evm.dts
@@ -150,6 +150,27 @@
0x14c (PIN_INPUT_PULLDOWN | MUX_MODE7)
;
};
+
+ 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 {
@@ -246,3 +267,90 @@
phy_id = davinci_mdio, 0;
phy-mode = rgmii;
};
+
+elm {
+ status = okay;
+};
+
+gpmc {
+ status = okay;
+ pinctrl-names = default;
+ pinctrl-0 = nand_flash_x8;
+ ranges = 0 0 0 0x0100;/* minimum GPMC partition = 16MB */
+ nand@0,0 {
+ reg = 0 0 0x37c; /* device IO registers */
This register space is used by the parent GPMC node as well as the NAND
controller. So doing a request_and_ioremap() on this space will fail as it is
already taken by the GPMC driver.
Further, the GPMC register space doesn't map to the GPMC memory map created by
this Chip select but it is mapped to L3_IO space. i.e. (physical address 0x6e00
)
We could have split the GPMC register space into GPMC part and NAND part but to
add to the complexity, the register spaces for GPMC vs NAND are interleaved so
it can't be easily split up. The way the NAND driver is currently written is
that it expects the register addresses to come via platform data, primarily to
get around this address interleaving issue.
Apart from the GPMC register space, the NAND controller uses 4 bytes of GPMC
memory map for I/O, and that is something that could be reflected here.
e.g.
reg = 0 0 4; /* NAND I/O space */
But still, the start address can't be 0 and has to be assigned when this CS
region is mapped. It is still unclear to me how that can be done.
cheers,
-roger
+ 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-pin = 0;
+ gpmc,wait-on-read;
+
[PATCH v3 05/13] ARM/platform_data: edma: Remove queue_tc_mapping data from edma_soc_info
It is no longer in use by the driver or board files.
Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
---
include/linux/platform_data/edma.h | 1 -
1 file changed, 1 deletion(-)
diff --git a/include/linux/platform_data/edma.h
b/include/linux/platform_data/edma.h
index 12f134b1493c..633e196ebdf2 100644
--- a/include/linux/platform_data/edma.h
+++ b/include/linux/platform_data/edma.h
@@ -175,7 +175,6 @@ struct edma_soc_info {
/* Resource reservation for other cores */
struct edma_rsv_info*rsv;
- s8 (*queue_tc_mapping)[2];
s8 (*queue_priority_mapping)[2];
const s16 (*xbar_chans)[2];
};
--
1.9.3
--
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 02/13] ARM: edma: Take the number of tc from edma_soc_info (pdata)
Instead of saving the for loop length, take the num_tc value from the pdata. In case of DT boot set the n_tc to 3 as it is hardwired in edma_of_parse_dt() This is a temporary state since upcoming patch(es) will change how we are dealing with these parameters. Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com --- arch/arm/common/edma.c | 5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-) diff --git a/arch/arm/common/edma.c b/arch/arm/common/edma.c index 01707aae0a2b..d42c84a3432a 100644 --- a/arch/arm/common/edma.c +++ b/arch/arm/common/edma.c @@ -1488,6 +1488,7 @@ static int edma_of_parse_dt(struct device *dev, pdata-n_slot = value; pdata-n_cc = 1; + pdata-n_tc = 3; rsv_info = devm_kzalloc(dev, sizeof(struct edma_rsv_info), GFP_KERNEL); if (!rsv_info) @@ -1648,6 +1649,7 @@ static int edma_probe(struct platform_device *pdev) EDMA_MAX_PARAMENTRY); edma_cc[j]-num_cc = min_t(unsigned, info[j]-n_cc, EDMA_MAX_CC); + edma_cc[j]-num_tc = info[j]-n_tc; edma_cc[j]-default_queue = info[j]-default_queue; @@ -1741,9 +1743,6 @@ static int edma_probe(struct platform_device *pdev) map_queue_tc(j, queue_tc_mapping[i][0], queue_tc_mapping[i][1]); - /* Save the number of TCs */ - edma_cc[j]-num_tc = i; - /* Event queue priority mapping */ for (i = 0; queue_priority_mapping[i][0] != -1; i++) assign_priority_to_queue(j, -- 1.9.3 -- 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 03/13] ARM: edma: Do not change TC - Queue mapping, leave it to default.
There is no need to change the default TC - Queue mapping. By default the
mapping is: TC0 - Q0, TC1 - Q1, etc.
Changing this has no benefits at all and all the board files are just setting
the same mapping back to the HW.
Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
---
arch/arm/common/edma.c | 28 +---
1 file changed, 1 insertion(+), 27 deletions(-)
diff --git a/arch/arm/common/edma.c b/arch/arm/common/edma.c
index d42c84a3432a..0bc5ed6fc249 100644
--- a/arch/arm/common/edma.c
+++ b/arch/arm/common/edma.c
@@ -290,12 +290,6 @@ static void map_dmach_queue(unsigned ctlr, unsigned ch_no,
~(0x7 bit), queue_no bit);
}
-static void __init map_queue_tc(unsigned ctlr, int queue_no, int tc_no)
-{
- int bit = queue_no * 4;
- edma_modify(ctlr, EDMA_QUETCMAP, ~(0x7 bit), ((tc_no 0x7) bit));
-}
-
static void __init assign_priority_to_queue(unsigned ctlr, int queue_no,
int priority)
{
@@ -1470,7 +1464,7 @@ static int edma_of_parse_dt(struct device *dev,
struct property *prop;
size_t sz;
struct edma_rsv_info *rsv_info;
- s8 (*queue_tc_map)[2], (*queue_priority_map)[2];
+ s8 (*queue_priority_map)[2];
ret = of_property_read_u32(node, dma-channels, value);
if (ret 0)
@@ -1495,19 +1489,6 @@ static int edma_of_parse_dt(struct device *dev,
return -ENOMEM;
pdata-rsv = rsv_info;
- queue_tc_map = devm_kzalloc(dev, 8*sizeof(s8), GFP_KERNEL);
- if (!queue_tc_map)
- return -ENOMEM;
-
- for (i = 0; i 3; i++) {
- queue_tc_map[i][0] = i;
- queue_tc_map[i][1] = i;
- }
- queue_tc_map[i][0] = -1;
- queue_tc_map[i][1] = -1;
-
- pdata-queue_tc_mapping = queue_tc_map;
-
queue_priority_map = devm_kzalloc(dev, 8*sizeof(s8), GFP_KERNEL);
if (!queue_priority_map)
return -ENOMEM;
@@ -1568,7 +1549,6 @@ static int edma_probe(struct platform_device *pdev)
struct edma_soc_info**info = pdev-dev.platform_data;
struct edma_soc_info*ninfo[EDMA_MAX_CC] = {NULL};
s8 (*queue_priority_mapping)[2];
- s8 (*queue_tc_mapping)[2];
int i, j, off, ln, found = 0;
int status = -1;
const s16 (*rsv_chans)[2];
@@ -1735,14 +1715,8 @@ static int edma_probe(struct platform_device *pdev)
for (i = 0; i edma_cc[j]-num_channels; i++)
map_dmach_queue(j, i, info[j]-default_queue);
- queue_tc_mapping = info[j]-queue_tc_mapping;
queue_priority_mapping = info[j]-queue_priority_mapping;
- /* Event queue to TC mapping */
- for (i = 0; queue_tc_mapping[i][0] != -1; i++)
- map_queue_tc(j, queue_tc_mapping[i][0],
- queue_tc_mapping[i][1]);
-
/* Event queue priority mapping */
for (i = 0; queue_priority_mapping[i][0] != -1; i++)
assign_priority_to_queue(j,
--
1.9.3
--
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 01/13] ARM: edma: No need to clean the pdata in edma_of_parse_dt()
The pdata has been just allocated with devm_kzalloc() in edma_setup_info_from_dt() and passed to this function. Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com --- arch/arm/common/edma.c | 2 -- 1 file changed, 2 deletions(-) diff --git a/arch/arm/common/edma.c b/arch/arm/common/edma.c index 8452cf246330..01707aae0a2b 100644 --- a/arch/arm/common/edma.c +++ b/arch/arm/common/edma.c @@ -1472,8 +1472,6 @@ static int edma_of_parse_dt(struct device *dev, struct edma_rsv_info *rsv_info; s8 (*queue_tc_map)[2], (*queue_priority_map)[2]; - memset(pdata, 0, sizeof(struct edma_soc_info)); - ret = of_property_read_u32(node, dma-channels, value); if (ret 0) return ret; -- 1.9.3 -- 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 00/13] ARM/DT: edma: IP configuration from hardware and cleanups
Hi, Changes since v2: - Comments from Sekhar and Arnd has been addressed best as I could. - Use the CCCFG information in all cases instead of pdata provided information - To achieve this I needed to do a bit more cleanup in this series - In the documentation patch, retrain the old properties for reference - Cleanups in the old davinci board files and removing edma_soc_info members Changes sicne v1: - added missing patch to remove the memset from edma_of_parse_dt() We are requesting redundant information via DT for the driver since the very same data is available in the HW: by reading and decoding the content of CCCFG register we can get: Number of channels: NUM_DMACH Number of regions: NUM_REGN Number of slots (PaRAM sets): NUM_PAENTRY Number of TC/EQ: NUM_EVQUE So these does not need to be provided by the DT binding. The driver will no longer look for these properties from DT and they can be removed from the binding documentation and from the dtsi files as well. The change will not introduce regression when new kernel is booted using older DTB (since we just ignore the mentioned properties). Regards, Peter --- Peter Ujfalusi (13): ARM: edma: No need to clean the pdata in edma_of_parse_dt() ARM: edma: Take the number of tc from edma_soc_info (pdata) ARM: edma: Do not change TC - Queue mapping, leave it to default. ARM: davinci: Remove eDMA3 queue_tc_mapping data from edma_soc_info ARM/platform_data: edma: Remove queue_tc_mapping data from edma_soc_info ARM: edma: Remove num_cc member from struct edma ARM: edma: Save number of regions from pdata to struct edma ARM: edma: Get IP configuration from HW (number of channels, tc, etc) dt/bindings: ti,edma: Remove redundant properties from documentation ARM: dts: am33xx: Remove obsolete properties from edma node ARM: dts: am4372: Remove obsolete properties from edma node ARM: davinci: Remove redundant/unused parameters for edma ARM/platform_data: edma: Remove redundant/unused parameters from edma_soc_info Documentation/devicetree/bindings/dma/ti-edma.txt | 13 +- arch/arm/boot/dts/am33xx.dtsi | 3 - arch/arm/boot/dts/am4372.dtsi | 3 - arch/arm/common/edma.c| 149 +++--- arch/arm/mach-davinci/devices-da8xx.c | 31 - arch/arm/mach-davinci/dm355.c | 14 -- arch/arm/mach-davinci/dm365.c | 16 --- arch/arm/mach-davinci/dm644x.c| 14 -- arch/arm/mach-davinci/dm646x.c| 16 --- include/linux/platform_data/edma.h| 8 -- 10 files changed, 81 insertions(+), 186 deletions(-) -- 1.9.3 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] usb: dwc3: gadget: check link trb after free_slot is increased
Hi, On Fri, May 16, 2014 at 11:50:13PM +0800, Zhuang Jin Can wrote: On Fri, May 16, 2014 at 05:57:57AM +0800, Zhuang Jin Can wrote: In ISOC transfers, when free_slot points to the last TRB (i.e. Link TRB), and all queued requests meet Missed Interval Isoc error, busy_slot points to trb0. busy_slot-trb0 trb1 ... free_slot-trb31(Link TRB) After end transfer and receiving the XferNotReady event, trb_left is caculated as 1 which is wrong, and no TRB will be primed to the endpoint. The root cause is free_slot is not increased the same way as busy_slot. When busy_slot is increased by one, it checks if points to a link TRB after increasement, but free_slot checks it before increasement. free_slot should behave the same as busy_slot to make the trb_left caculation correct. Signed-off-by: Zhuang Jin Can jin.can.zhu...@intel.com Signed-off-by: Jiebing Li jiebing...@intel.com --- drivers/usb/dwc3/gadget.c |8 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/drivers/usb/dwc3/gadget.c b/drivers/usb/dwc3/gadget.c index 54da8c8..2ebe82b 100644 --- a/drivers/usb/dwc3/gadget.c +++ b/drivers/usb/dwc3/gadget.c @@ -828,10 +828,6 @@ static void dwc3_prepare_one_trb(struct dwc3_ep *dep, length, last ? last : , chain ? chain : ); - /* Skip the LINK-TRB on ISOC */ - if (((dep-free_slot DWC3_TRB_MASK) == DWC3_TRB_NUM - 1) - usb_endpoint_xfer_isoc(dep-endpoint.desc)) - dep-free_slot++; trb = dep-trb_pool[dep-free_slot DWC3_TRB_MASK]; I have a feeling this has a negative side effect of letting us use the link TRB for data transfer... I mean, if we don't increment free_slot before accessing our trb_pool, we have no way to skip link trb on this access here. After every free_slot++ Link TRB is checked and increased if appropriate, this guarantees you next time access free_slot, it can't be a Link TRB. right, next access will be fine, but you're forgetting about current access. How did you find the bug ? do you have good instructions on how to reproduce it ? How did you test the patch and for how long ? The bug is reproduced on Android with f_audio_source.c enabled, which has an isoc-in endpoint keeps sending audio data to host in an interval of 1 ms. Normally, you need to run for 12+ hours to hit the issue. So I think you can just run some isoc transfers for a long time to reproduce it. To accelarte the reproducing, you can run some concurrent data transfer as well, so the possibility to meet missed interval error is larger. The patch is tested for basic functionality like enumeration, data transfers. For this bug, it was tested for 20+ hours. thanks, g_audio loop should be fine. -- balbi signature.asc Description: Digital signature
Re: RCU stall on panda
On Friday 16 May 2014 03:41 AM, Alex Shi wrote: On 05/16/2014 02:36 AM, Santosh Shilimkar wrote: yes. My board is panda ES. without this revert, it works. Care to specify what linux version you are testing against? Does it hang in idle always immediately on booting? Or does the serial console first hang with sysrq still working (ctrl-a h in minicom for help) with device eventually locking up hard? I just posted an updated patch Alex on other thread. Attaching here again for your reference. Please try it out and see if the you still get a hang. it does not hang this time. This is good news and exactly what I expected. but I am not sure it can solve my problem, since RCU stall is not easy to reproduce in short time. You may want to run the system longer if you can. I suspect the RCU stall was also side effect of missing interrupts. Regards, Santosh -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: OMAP4: Fix the boot regression with CPU_IDLE enabled
Tony,
On Thursday 15 May 2014 02:29 PM, Santosh Shilimkar wrote:
On Thursday 15 May 2014 01:54 PM, Santosh Shilimkar wrote:
On Thursday 15 May 2014 01:50 PM, Daniel Lezcano wrote:
On 05/15/2014 07:03 PM, Santosh Shilimkar wrote:
[..]
With above mentioned change, it should work. Other alternatives is OMAP4
driver does
its won registration where it can start the timer. The way it was before
the
consolidation.
Ofcourse if you have better fix, then great.
What is your suggestion. We *must* fix the regression asap. I think
$subject patch with an update to bctimer start under CPUIDLE_FLAG_COUPLED
seems a good way forward.
Do let me know.
Did you see Alex Shi's email [cc'ed] ? Reverting this change makes the
panda ES to hang.
The hang is definitely due to the bctimer not started. As I said, I assumed
it was and
then you corrected saying it is under the flag.
I am not convinced the culprit is this code you are trying to revert.
fair enough. Thats why I said if you have an alternative fix thats great.
For record, below is updated patch with bctimer started which
was missed in earlier version. I haven't tested it though.
Alex,
Please give a try with your test-case and see if you still see the hang.
Am just curious about your issue and hence the request..
Alex tested below patch and he don't see the hang so the patch is
addressing the issue.
If Daniel works out an alternate fix to avoid reverts, that will be great
but if not, we should merge the below patch. I let you take call on it.
From bb3b82cc5645b83bedf1343d03cc956f27f6fc83 Mon Sep 17 00:00:00 2001
From: Santosh Shilimkar santosh.shilim...@ti.com
Date: Mon, 12 May 2014 17:37:59 -0400
Subject: [PATCH] ARM: OMAP4: Fix the boot regression with CPU_IDLE enabled
On OMAP4 panda board, there have been several bug reports about boot
hang and lock-ups with CPU_IDLE enabled. The root cause of the issue
is missing interrupts while in idle state. Commit cb7094e8 {cpuidle / omap4 :
use CPUIDLE_FLAG_TIMER_STOP flag} moved the broadcast notifiers to common
code for right reasons but on OMAP4 which suffers from a nasty ROM code
bug with GIC, commit ff999b8a {ARM: OMAP4460: Workaround for ROM bug ..},
we loose interrupts which leads to issues like lock-up, hangs etc.
Patch reverts commit cb7094 {cpuidle / omap4 : use CPUIDLE_FLAG_TIMER_STOP
flag} and 54769d6 {cpuidle: OMAP4: remove timer broadcast initialization} to
avoid the issue. With this change, OMAP4 panda boards, the mentioned
issues are getting fixed. We no longer loose interrupts which was the cause
of the regression.
Cc: Roger Quadros rog...@ti.com
Cc: Kevin Hilman khil...@linaro.org
Cc: Tony Lindgren t...@atomide.com
Cc: Daniel Lezcano daniel.lezc...@linaro.org
Reported-tested-by: Roger Quadros rog...@ti.com
Reported-tested-by: Kevin Hilman khil...@linaro.org
Tested-by: Tony Lindgren t...@atomide.com
Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com
---
arch/arm/mach-omap2/cpuidle44xx.c | 25 +
1 file changed, 21 insertions(+), 4 deletions(-)
diff --git a/arch/arm/mach-omap2/cpuidle44xx.c
b/arch/arm/mach-omap2/cpuidle44xx.c
index 01fc710..2498ab0 100644
--- a/arch/arm/mach-omap2/cpuidle44xx.c
+++ b/arch/arm/mach-omap2/cpuidle44xx.c
@@ -14,6 +14,7 @@
#include linux/cpuidle.h
#include linux/cpu_pm.h
#include linux/export.h
+#include linux/clockchips.h
#include asm/cpuidle.h
#include asm/proc-fns.h
@@ -83,6 +84,7 @@ static int omap_enter_idle_coupled(struct cpuidle_device
*dev,
{
struct idle_statedata *cx = state_ptr + index;
u32 mpuss_can_lose_context = 0;
+ int cpu_id = smp_processor_id();
/*
* CPU0 has to wait and stay ON until CPU1 is OFF state.
@@ -110,6 +112,8 @@ static int omap_enter_idle_coupled(struct cpuidle_device
*dev,
mpuss_can_lose_context = (cx-mpu_state == PWRDM_POWER_RET)
(cx-mpu_logic_state == PWRDM_POWER_OFF);
+ clockevents_notify(CLOCK_EVT_NOTIFY_BROADCAST_ENTER, cpu_id);
+
/*
* Call idle CPU PM enter notifier chain so that
* VFP and per CPU interrupt context is saved.
@@ -165,6 +169,8 @@ static int omap_enter_idle_coupled(struct cpuidle_device
*dev,
if (dev-cpu == 0 mpuss_can_lose_context)
cpu_cluster_pm_exit();
+ clockevents_notify(CLOCK_EVT_NOTIFY_BROADCAST_EXIT, cpu_id);
+
fail:
cpuidle_coupled_parallel_barrier(dev, abort_barrier);
cpu_done[dev-cpu] = false;
@@ -172,6 +178,16 @@ fail:
return index;
}
+/*
+ * For each cpu, setup the broadcast timer because local timers
+ * stops for the states above C1.
+ */
+static void omap_setup_broadcast_timer(void *arg)
+{
+ int cpu = smp_processor_id();
+ clockevents_notify(CLOCK_EVT_NOTIFY_BROADCAST_ON, cpu);
+}
+
static struct cpuidle_driver omap4_idle_driver = {
.name = omap4_idle,
RE: [PATCH v6 2/4] ARM: dts: am437x-gp-evm: add support for parallel NAND flash
Hi Roger,
From: Quadros, Roger
[...]
+gpmc {
+status = okay;
+pinctrl-names = default;
+pinctrl-0 = nand_flash_x8;
+ranges = 0 0 0 0x0100;/* minimum GPMC partition = 16MB */
+nand@0,0 {
+reg = 0 0 0x37c; /* device IO registers */
This register space is used by the parent GPMC node as well as the NAND
controller. So doing a
request_and_ioremap() on this space will fail as it is already taken by the
GPMC driver.
Further, the GPMC register space doesn't map to the GPMC memory map created by
this Chip select
but it is mapped to L3_IO space. i.e. (physical address 0x6e00 )
We could have split the GPMC register space into GPMC part and NAND part but
to add to the
complexity, the register spaces for GPMC vs NAND are interleaved so it can't
be easily split up.
Sorry I din't get this part.
NAND is one of the devices supported by GPMC controller.
Hardware wise the it's the same engine is used for NAND, NOR and OneNAND
and even other parallel interfaces like Camera, Ethernet, etc..
So how can be NAND and GPMC registers space be splitted ?
I see gpmc.c as generic controller driver, which just does initializations
and registering the device. Then it's upto the individual protocol drivers
to probe the device and attach it to respective sub-system; like;
(a) drivers/mtd/nand/omap2.c for NAND
(b) drivers/mtd/chips/cfi_probe.c for NOR
...
The way
the NAND driver is currently written is that it expects the register addresses
to come via platform data,
primarily to get around this address interleaving issue.
Yes, that is right.
I don't know the historical reasons but that is correct also because,
(1) large set of GPMC register configurations are common across all
types of devices (like NAND, NOR, OneNAND, Ethernet). These
register configurations define the signal timings and physical attributes
of device (like device width, etc).
(2) Individual protocol drivers (a) and (b) only uses a sub-set of registers
for transferring data, much of which is based on type of protocol.
So, large part of GPMC configurations remains static and can be
Shared across all types of devices, hence those are put in gpmc.c
Apart from the GPMC register space, the NAND controller uses 4 bytes of GPMC
memory map for I/O,
and that is something that could be reflected here.
e.g.
reg = 0 0 4; /* NAND I/O space */
But still, the start address can't be 0 and has to be assigned when this CS
region is mapped. It is still
unclear to me how that can be done.
Yes, NAND is not directly mapped. So only 4-bytes of I/O size will do.
But where to map these 4 bytes ? and which 4-bytes to map.
So I have included complete GPMC register space-size.
Also since GPMC has a constrain that every chip-select must have
minimum of 16MB memory. So we specify it via range property
to keep GPMC mapping consistent across all NAND, NOR, OneNAND, etc..
If you have any better approach in mind for keeping consistent
memory mapping across different types of devices, then please suggest ..
I'll try to get this done in next set of patches, if not these.
Or
May be you can take over as part of GPMC transition.
cheers,
-roger
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 v6 1/4] ARM: dts: am335x-bone: add support for beaglebone NAND cape
Hi Ezequiel, From: Ezequiel Garcia [mailto:ezequ...@vanguardiasur.com.ar] Hello Pekon, On 16 May 04:33 PM, Pekon Gupta wrote: [..] +gpmc,wait-pin = 0; +gpmc,wait-on-read; +gpmc,wait-on-write; Thanks for adding the wait-pin property. I think the other boards also needs this change. Javier, do you have a IGEP Aquila with NAND to try? Pekon, have you noticed that there's no devicetree property to enable ready/busy? In other words, the NAND driver dev_ready field will never be true when probed from DT. Yes, that is know, therefore I din't reply to your earlier email. I was just fixing your DT comments and have a small patch to set dev_ready=true. I'll send it soon. But still you need to consider that nand/omap2.c driver only supports polling way of monitoring READY/BUSY pin. That is instead of polling for status-bit | waiting for predefined delay, NAND driver now polls for READY/BUSY pin. However, actual benefit of wait-pin monitoring might be visible when READY/BUSY pin is used with interrupt. 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 v6 2/4] ARM: dts: am437x-gp-evm: add support for parallel NAND flash
On 05/16/2014 04:58 PM, Gupta, Pekon wrote:
Hi Roger,
From: Quadros, Roger
[...]
+gpmc {
+ status = okay;
+ pinctrl-names = default;
+ pinctrl-0 = nand_flash_x8;
+ ranges = 0 0 0 0x0100;/* minimum GPMC partition = 16MB */
+ nand@0,0 {
+ reg = 0 0 0x37c; /* device IO registers */
This register space is used by the parent GPMC node as well as the NAND
controller. So doing a
request_and_ioremap() on this space will fail as it is already taken by the
GPMC driver.
Further, the GPMC register space doesn't map to the GPMC memory map created
by this Chip select
but it is mapped to L3_IO space. i.e. (physical address 0x6e00 )
We could have split the GPMC register space into GPMC part and NAND part but
to add to the
complexity, the register spaces for GPMC vs NAND are interleaved so it can't
be easily split up.
Sorry I din't get this part.
NAND is one of the devices supported by GPMC controller.
Hardware wise the it's the same engine is used for NAND, NOR and OneNAND
But GPMC register space is only used for 2 things, Chip Select configuration
and NAND driver.
GPMC registers are not used for NOR, OneNAND or other memory accessible
devices. They don't need GPMC registers because their registers are mapped in
the GPMC I/O space.
and even other parallel interfaces like Camera, Ethernet, etc..
So how can be NAND and GPMC registers space be splitted ?
- all Chip select configuration registers i.e. GPMC_CONFIG* should go to GPMC
device
- all the GPMC_NAND_*, GPMC_ECC_, and GPMC_BCH_* registers go to NAND device
The tricky part is that all these registers are interleaved among each other
and so the register map is fragmented.
I see gpmc.c as generic controller driver, which just does initializations
and registering the device. Then it's upto the individual protocol drivers
to probe the device and attach it to respective sub-system; like;
(a) drivers/mtd/nand/omap2.c for NAND
(b) drivers/mtd/chips/cfi_probe.c for NOR
...
omap2.c needs GPMC registers, but cfi_probe.c and others don't need them.
The way
the NAND driver is currently written is that it expects the register
addresses to come via platform data,
primarily to get around this address interleaving issue.
Yes, that is right.
I don't know the historical reasons but that is correct also because,
(1) large set of GPMC register configurations are common across all
types of devices (like NAND, NOR, OneNAND, Ethernet). These
register configurations define the signal timings and physical attributes
of device (like device width, etc).
(2) Individual protocol drivers (a) and (b) only uses a sub-set of registers
for transferring data, much of which is based on type of protocol.
So, large part of GPMC configurations remains static and can be
Shared across all types of devices, hence those are put in gpmc.c
Right, so just the GPMC configuration part needs to be with GPMC driver. The
NAND controller bits don't need to be.
Apart from the GPMC register space, the NAND controller uses 4 bytes of GPMC
memory map for I/O,
and that is something that could be reflected here.
e.g.
reg = 0 0 4; /* NAND I/O space */
But still, the start address can't be 0 and has to be assigned when this CS
region is mapped. It is still
unclear to me how that can be done.
Yes, NAND is not directly mapped. So only 4-bytes of I/O size will do.
But where to map these 4 bytes ? and which 4-bytes to map.
So I have included complete GPMC register space-size.
That is not the right solution. The mapping is done in the gpmc driver in
gpmc_cs_request()/gpmc_cs_remap().
If a random address (meeting GPMC alignment needs) is specified within the GPMC
1GB space, the GPMC driver should configure the CS to map
to that address. If 0 is specified then the GPMC must map it automatically to a
sane address and then update the reg property before instantiating the child
node's platform device.
For the NAND controller, we don't even create a child device based on the OF
node but instead legacy platform device, so this reg property isn't being even
used.
Also since GPMC has a constrain that every chip-select must have
minimum of 16MB memory. So we specify it via range property
to keep GPMC mapping consistent across all NAND, NOR, OneNAND, etc..
If you have any better approach in mind for keeping consistent
memory mapping across different types of devices, then please suggest ..
I'll try to get this done in next set of patches, if not these.
Or
May be you can take over as part of GPMC transition.
As the driver doesn't rely on the reg address portion (at least for the NAND
driver), you can leave this option out for now.
cheers,
-roger
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] usb: dwc3: gadget: check link trb after free_slot is increased
Hi, On Fri, May 16, 2014 at 07:41:06AM -0500, Felipe Balbi wrote: On Fri, May 16, 2014 at 11:50:13PM +0800, Zhuang Jin Can wrote: On Fri, May 16, 2014 at 05:57:57AM +0800, Zhuang Jin Can wrote: In ISOC transfers, when free_slot points to the last TRB (i.e. Link TRB), and all queued requests meet Missed Interval Isoc error, busy_slot points to trb0. busy_slot-trb0 trb1 ... free_slot-trb31(Link TRB) After end transfer and receiving the XferNotReady event, trb_left is caculated as 1 which is wrong, and no TRB will be primed to the endpoint. The root cause is free_slot is not increased the same way as busy_slot. When busy_slot is increased by one, it checks if points to a link TRB after increasement, but free_slot checks it before increasement. free_slot should behave the same as busy_slot to make the trb_left caculation correct. Signed-off-by: Zhuang Jin Can jin.can.zhu...@intel.com Signed-off-by: Jiebing Li jiebing...@intel.com --- drivers/usb/dwc3/gadget.c |8 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/drivers/usb/dwc3/gadget.c b/drivers/usb/dwc3/gadget.c index 54da8c8..2ebe82b 100644 --- a/drivers/usb/dwc3/gadget.c +++ b/drivers/usb/dwc3/gadget.c @@ -828,10 +828,6 @@ static void dwc3_prepare_one_trb(struct dwc3_ep *dep, length, last ? last : , chain ? chain : ); - /* Skip the LINK-TRB on ISOC */ - if (((dep-free_slot DWC3_TRB_MASK) == DWC3_TRB_NUM - 1) - usb_endpoint_xfer_isoc(dep-endpoint.desc)) - dep-free_slot++; trb = dep-trb_pool[dep-free_slot DWC3_TRB_MASK]; I have a feeling this has a negative side effect of letting us use the link TRB for data transfer... I mean, if we don't increment free_slot before accessing our trb_pool, we have no way to skip link trb on this access here. After every free_slot++ Link TRB is checked and increased if appropriate, this guarantees you next time access free_slot, it can't be a Link TRB. right, next access will be fine, but you're forgetting about current access. The current access is the next access relative to last access. So if the first access is fine, succeeding accesses should be fine. And the first access happens on when the free_slot points to slot 1 which is not a link trb. How did you find the bug ? do you have good instructions on how to reproduce it ? How did you test the patch and for how long ? The bug is reproduced on Android with f_audio_source.c enabled, which has an isoc-in endpoint keeps sending audio data to host in an interval of 1 ms. Normally, you need to run for 12+ hours to hit the issue. So I think you can just run some isoc transfers for a long time to reproduce it. To accelarte the reproducing, you can run some concurrent data transfer as well, so the possibility to meet missed interval error is larger. The patch is tested for basic functionality like enumeration, data transfers. For this bug, it was tested for 20+ hours. thanks, g_audio loop should be fine. np. Regards Jincan -- 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 10/13] ARM: dts: am33xx: Remove obsolete properties from edma node
* Peter Ujfalusi peter.ujfal...@ti.com [140516 05:18]:
dma-channels, ti,edma-regions and ti,edma-slots no longer needed in DT since
the the same information is available in the IP's CCCFG register.
Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
Acked-by: Tony Lindgren t...@atomide.com
---
arch/arm/boot/dts/am33xx.dtsi | 3 ---
1 file changed, 3 deletions(-)
diff --git a/arch/arm/boot/dts/am33xx.dtsi b/arch/arm/boot/dts/am33xx.dtsi
index f1eea4af40ed..37d4cad4dd38 100644
--- a/arch/arm/boot/dts/am33xx.dtsi
+++ b/arch/arm/boot/dts/am33xx.dtsi
@@ -147,9 +147,6 @@
0x44e10f90 0x40;
interrupts = 12 13 14;
#dma-cells = 1;
- dma-channels = 64;
- ti,edma-regions = 4;
- ti,edma-slots = 256;
};
gpio0: gpio@44e07000 {
--
1.9.3
--
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 11/13] ARM: dts: am4372: Remove obsolete properties from edma node
* Peter Ujfalusi peter.ujfal...@ti.com [140516 05:19]:
dma-channels, ti,edma-regions and ti,edma-slots no longer needed in DT since
the the same information is available in the IP's CCCFG register.
Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
Acked-by: Tony Lindgren t...@atomide.com
---
arch/arm/boot/dts/am4372.dtsi | 3 ---
1 file changed, 3 deletions(-)
diff --git a/arch/arm/boot/dts/am4372.dtsi b/arch/arm/boot/dts/am4372.dtsi
index 03a225505126..b9f83b705f4b 100644
--- a/arch/arm/boot/dts/am4372.dtsi
+++ b/arch/arm/boot/dts/am4372.dtsi
@@ -108,9 +108,6 @@
GIC_SPI 13 IRQ_TYPE_LEVEL_HIGH,
GIC_SPI 14 IRQ_TYPE_LEVEL_HIGH;
#dma-cells = 1;
- dma-channels = 64;
- ti,edma-regions = 4;
- ti,edma-slots = 256;
};
uart0: serial@44e09000 {
--
1.9.3
--
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 3/4] OMAPDSS: panel-sharp-ls037v7dw01: add device tree support
* Tomi Valkeinen tomi.valkei...@ti.com [140515 22:57]: On 15/05/14 21:21, Tony Lindgren wrote: But you're right, having sharp,ls037v7dw01-omap-dss in the .dts is an alternative for the compatible-string conversion we do now. I guess it's a matter of taste, but I rather hide it inside the kernel, in an internal omapdss file, than pollute the .dts files with those compatible strings. Well it avoid you parsing through all the nodes during booting and leaves out the function to do remapping. And removes the need for maintaining a custom display mapping table. I'd say that's a pretty good list of advantages right there :) Yep... I don't know. Maybe I'm being too careful about doing wrong things with .dts. I just like it more if any hacks are in kernel code, which I can remove without anyone noticing. Anyway, we already have board.dts files using the non-omapified compatible strings in the mainline, so if I would now add the omapified compatible strings to .dts files, those old board.dts files would break. So I guess the choice has already been made. I really think you should remove this misuse of device tree code ASAP. It's better to fix it up now than carry the hack for next two years and keep on adding to it. 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 0/4] OMAPDSS: sharp-ls037v7dw01 DT support
* Tomi Valkeinen tomi.valkei...@ti.com [140516 00:31]: Hi, These are slightly reworked versions of the patches Tony sent: * Split the DT doc into separate patch * Handle errors from gpio functions * Remove QVGA support * Removed the change to arch/arm/mach-omap2/display.c. I'll add that to my patch which moves the conversion code to omapdss. Note that if you test this version, you need to add the panel name to the conversion list for now. * Set MO gpio GPIO_ACTIVE_HIGH in omap3-evm-common.dtsi * Set the GPIO default values the same way for DT and non-DT versions. Tony, I removed the QVGA support as it was a new feature, not supported by the non-DT version. Also, I don't think it should be done as you had implemented it, but rather either have a flag in the DT data in case the pin is hardwired in the hardware, or let the user select the mode at runtime. OK. Probably should have both options eventually. Also, I didn't quite understand the implementation. You had set initial values in the driver for MO and RESB differently than on the non-DT version. Was that on purpose? I just configured things to what we had earlier for the legacy booting, QVGA for ldp and VGA for omap3-evm. You said in a comment: The LCD is sideways, so we want the VGA mode instead of QVGA mode.. Why is that? How does the resolution affect the orientation? Yeah that's pretty confusing and probably written before I got the image working properly. I probably initially thought the VGA mode also switches the panel to 640x480, while it really sets it to 480x640. With my version, the panel (should) always be in VGA mode, like the non-DT version does. Only compile tested, I don't have boards with the panel. Works for me on omap3-evm and ldp after patching in the mode to your panel compatible translation database system. 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 3/4] OMAPDSS: panel-sharp-ls037v7dw01: add device tree support
* Tomi Valkeinen tomi.valkei...@ti.com [140515 22:51]: On 15/05/14 21:25, Tony Lindgren wrote: * Tomi Valkeinen tomi.valkei...@ti.com [140515 01:42]: On 14/05/14 00:26, Tony Lindgren wrote: + /* lcd MO */ + ddata-mo_gpio = sharp_ls_get_gpio_of(pdev-dev, 0, 1, mode); + if (PTR_ERR(ddata-mo_gpio) == -EPROBE_DEFER) + return -EPROBE_DEFER; + + if (!IS_ERR(ddata-mo_gpio)) + if (gpiod_get_raw_value_cansleep(ddata-mo_gpio)) + ddata-flags |= SHARP_LS_QVGA; Shouldn't there be an explicit flag in the DT data for this? If the panel's MO pin is hardwired to, say, pull up, then the mode-gpios won't have MO gpio, right? So something like: mode-gpios = 0/* high, lcd MO */ gpio1 2 GPIO_ACTIVE_HIGH /* gpio2, lcd LR */ gpio1 3 GPIO_ACTIVE_HIGH; /* gpio3, lcd UD */ vga-mode; /* MO hardwired high */ Yeah holes there are just fine. I figured let's keep the custom vga-mode property out of the way until we actually run into a panel that's not using a GPIO for mode. Ok, I'm fine with that, but in that case I think we have to use all the panels in the same mode, i.e. the driver either sets the MO gpio always low and uses VGA mode, or sets the MO always high and uses QVGA mode. OK let's default to VGA mode for now. In your omap3-evm.dts patch, you set the MO gpio ACTIVE_LOW in order to change the mode, even if it really should be ACTIVE_HIGH. But if you do that, and we later add the support to the panel driver to manage the MO gpio dynamically (i.e. the user can select VGA/QVGA at runtime), then the panel won't work as the driver uses wrong polarity for the pin. Getting the configured value seemed to work just fine with gpiod_get_raw_value_cansleep(ddata-mo_gpio). But yeah I agree the lack and confusion between polarity and desired default value for a GPIO is is sucky. The ACTIVE_HIGH probably should mean polarity. I don't know if there's an easy solution to that short of adding a new GPIO binding that contains both the polarity and the desired default value. 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 v6 2/4] ARM: dts: am437x-gp-evm: add support for parallel NAND flash
* Roger Quadros rog...@ti.com [140516 05:23]:
On 05/16/2014 02:03 PM, Pekon Gupta wrote:
+gpmc {
+ status = okay;
+ pinctrl-names = default;
+ pinctrl-0 = nand_flash_x8;
+ ranges = 0 0 0 0x0100;/* minimum GPMC partition = 16MB */
+ nand@0,0 {
+ reg = 0 0 0x37c; /* device IO registers */
This register space is used by the parent GPMC node as well as the NAND
controller. So doing a request_and_ioremap() on this space will fail as it is
already taken by the GPMC driver.
Further, the GPMC register space doesn't map to the GPMC memory map created
by this Chip select but it is mapped to L3_IO space. i.e. (physical address
0x6e00 )
We could have split the GPMC register space into GPMC part and NAND part but
to add to the complexity, the register spaces for GPMC vs NAND are
interleaved so it can't be easily split up. The way the NAND driver is
currently written is that it expects the register addresses to come via
platform data, primarily to get around this address interleaving issue.
Apart from the GPMC register space, the NAND controller uses 4 bytes of GPMC
memory map for I/O, and that is something that could be reflected here.
e.g.
reg = 0 0 4; /* NAND I/O space */
Guys, the reg size here is size of the IO region for the
NAND driver, it should not have anything to do with the GPMC
registers for the GPMC functions that the NAND driver may call.
So it sounds like 0x37c is wrong, and 4 is the right value if
the NAND chip has only one IO register.
But still, the start address can't be 0 and has to be assigned when this CS
region is mapped. It is still unclear to me how that can be done.
If the offset for the NAND driver needs to be different from 0,
it can be in the offset. For example, the smsc,lan91c94 driver
wants the IO address space to be at offset 0x300 to avoid some
extra warnings during the boot. So for that, the reg entry is:
reg = 1 0x300 0xf;
Where we have:
1 = chip select
0x300 = offset of smsc device register IO space from the start of
16MB minimum GPMC partition
0xf = size of smsc device register IO space that the Ethernet
driver ioremaps
Regards,
Tony
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 2/5] ARM: edma: Get IP information from HW when booting with DT
On 05/15/2014 07:48 AM, Sekhar Nori wrote: On Thursday 15 May 2014 06:00 PM, Peter Ujfalusi wrote: The second controller is not handled because in DT boot we only handle 1 cc as far as I know. I don't know why, but this is how the DT support has been written and used. Its just because none of the platforms under heavy development use two controllers. Joel promised to work on it at some point ;) Yeah, often things like that go down in priority when there aren't users, and when other things on fire need to be tended to :-D I think the next on-fire thing as far as EDMA goes would be to move out into drivers/edma. I like Peter's series in that it probably is a step forward there. thanks, -Joel -- 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 08/13] ARM: edma: Get IP configuration from HW (number of channels, tc, etc)
On 05/16/2014 07:17 AM, Peter Ujfalusi wrote:
From CCCFG register of eDMA3 we can get all the needed information for the
driver about the IP:
Number of channels: NUM_DMACH
Number of regions: NUM_REGN
Number of slots (PaRAM sets): NUM_PAENTRY
Number of TC/EQ: NUM_EVQUE
In case when booted with DT or the queue_priority_mapping is not provided
set up a default priority map.
Thanks.
Acked-by: Joel Fernandes jo...@ti.com
Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
---
arch/arm/common/edma.c | 115
+++--
1 file changed, 73 insertions(+), 42 deletions(-)
diff --git a/arch/arm/common/edma.c b/arch/arm/common/edma.c
index aa9473cb0c23..485be42519b9 100644
--- a/arch/arm/common/edma.c
+++ b/arch/arm/common/edma.c
@@ -102,7 +102,13 @@
#define PARM_OFFSET(param_no)(EDMA_PARM + ((param_no) 5))
#define EDMA_DCHMAP 0x0100 /* 64 registers */
-#define CHMAP_EXIST BIT(24)
+
+/* CCCFG register */
+#define GET_NUM_DMACH(x) (x 0x7) /* bits 0-2 */
+#define GET_NUM_PAENTRY(x) ((x 0x7000) 12) /* bits 12-14 */
+#define GET_NUM_EVQUE(x) ((x 0x7) 16) /* bits 16-18 */
+#define GET_NUM_REGN(x) ((x 0x30) 20) /* bits 20-21 */
+#define CHMAP_EXIST BIT(24)
#define EDMA_MAX_DMACH 64
#define EDMA_MAX_PARAMENTRY 512
@@ -1408,6 +1414,67 @@ void edma_clear_event(unsigned channel)
}
EXPORT_SYMBOL(edma_clear_event);
+static int edma_setup_from_hw(struct device *dev, struct edma_soc_info
*pdata,
+ struct edma *edma_cc)
+{
+ int i;
+ u32 value, cccfg;
+ s8 (*queue_priority_map)[2];
+
+ /* Decode the eDMA3 configuration from CCCFG register */
+ cccfg = edma_read(0, EDMA_CCCFG);
+
+ value = GET_NUM_REGN(cccfg);
+ edma_cc-num_region = BIT(value);
+
+ value = GET_NUM_DMACH(cccfg);
+ edma_cc-num_channels = BIT(value + 1);
+
+ value = GET_NUM_PAENTRY(cccfg);
+ edma_cc-num_slots = BIT(value + 4);
+
+ value = GET_NUM_EVQUE(cccfg);
+ edma_cc-num_tc = value + 1;
+
+ dev_dbg(dev, eDMA3 HW configuration (cccfg: 0x%08x):\n, cccfg);
+ dev_dbg(dev, num_region: %u\n, edma_cc-num_region);
+ dev_dbg(dev, num_channel: %u\n, edma_cc-num_channels);
+ dev_dbg(dev, num_slot: %u\n, edma_cc-num_slots);
+ dev_dbg(dev, num_tc: %u\n, edma_cc-num_tc);
+
+ /* Nothing need to be done if queue priority is provided */
+ if (pdata-queue_priority_mapping)
+ return 0;
+
+ /*
+ * Configure TC/queue priority as follows:
+ * Q0 - priority 0
+ * Q1 - priority 1
+ * Q2 - priority 2
+ * ...
+ * The meaning of priority numbers: 0 highest priority, 7 lowest
+ * priority. So Q0 is the highest priority queue and the last queue has
+ * the lowest priority.
+ */
+ queue_priority_map = devm_kzalloc(dev,
+ (edma_cc-num_tc + 1) * sizeof(s8),
+ GFP_KERNEL);
+ if (!queue_priority_map)
+ return -ENOMEM;
+
+ for (i = 0; i edma_cc-num_tc; i++) {
+ queue_priority_map[i][0] = i;
+ queue_priority_map[i][1] = i;
+ }
+ queue_priority_map[i][0] = -1;
+ queue_priority_map[i][1] = -1;
+
+ pdata-queue_priority_mapping = queue_priority_map;
+ pdata-default_queue = 0;
+
+ return 0;
+}
+
#if IS_ENABLED(CONFIG_OF) IS_ENABLED(CONFIG_DMADEVICES)
static int edma_xbar_event_map(struct device *dev, struct device_node *node,
@@ -1458,50 +1525,16 @@ static int edma_of_parse_dt(struct device *dev,
struct device_node *node,
struct edma_soc_info *pdata)
{
- int ret = 0, i;
- u32 value;
+ int ret = 0;
struct property *prop;
size_t sz;
struct edma_rsv_info *rsv_info;
- s8 (*queue_priority_map)[2];
-
- ret = of_property_read_u32(node, dma-channels, value);
- if (ret 0)
- return ret;
- pdata-n_channel = value;
-
- ret = of_property_read_u32(node, ti,edma-regions, value);
- if (ret 0)
- return ret;
- pdata-n_region = value;
-
- ret = of_property_read_u32(node, ti,edma-slots, value);
- if (ret 0)
- return ret;
- pdata-n_slot = value;
-
- pdata-n_tc = 3;
rsv_info = devm_kzalloc(dev, sizeof(struct edma_rsv_info), GFP_KERNEL);
if (!rsv_info)
return -ENOMEM;
pdata-rsv = rsv_info;
- queue_priority_map = devm_kzalloc(dev, 8*sizeof(s8), GFP_KERNEL);
- if (!queue_priority_map)
- return -ENOMEM;
-
- for (i = 0; i 3; i++) {
- queue_priority_map[i][0] = i;
- queue_priority_map[i][1] = i;
- }
- queue_priority_map[i][0] = -1;
- queue_priority_map[i][1] = -1;
-
-
Re: [PATCH v6 1/4] ARM: dts: am335x-bone: add support for beaglebone NAND cape
Hello Ezequiel, On Fri, May 16, 2014 at 1:57 PM, Ezequiel Garcia ezequ...@vanguardiasur.com.ar wrote: Hello Pekon, On 16 May 04:33 PM, Pekon Gupta wrote: [..] + gpmc,wait-pin = 0; + gpmc,wait-on-read; + gpmc,wait-on-write; Thanks for adding the wait-pin property. I think the other boards also needs this change. Javier, do you have a IGEP Aquila with NAND to try? I do have an IGEP aquila with NAND so I can give it a try. I won't be able to do this until Monday though. Hopefully by then Pekon would have already sent his patch to set dev_ready=true. Do you have any specific thing you want me to test? or just a nandtest run? Pekon, have you noticed that there's no devicetree property to enable ready/busy? In other words, the NAND driver dev_ready field will never be true when probed from DT. -- Ezequiel Garcia, VanguardiaSur www.vanguardiasur.com.ar Best regards, Javier -- 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 3/4] OMAPDSS: panel-sharp-ls037v7dw01: add device tree support
On Fri, May 16, 2014 at 09:07:17AM -0700, Tony Lindgren wrote: * Tomi Valkeinen tomi.valkei...@ti.com [140515 22:57]: On 15/05/14 21:21, Tony Lindgren wrote: But you're right, having sharp,ls037v7dw01-omap-dss in the .dts is an alternative for the compatible-string conversion we do now. I guess it's a matter of taste, but I rather hide it inside the kernel, in an internal omapdss file, than pollute the .dts files with those compatible strings. Well it avoid you parsing through all the nodes during booting and leaves out the function to do remapping. And removes the need for maintaining a custom display mapping table. I'd say that's a pretty good list of advantages right there :) Yep... I don't know. Maybe I'm being too careful about doing wrong things with .dts. I just like it more if any hacks are in kernel code, which I can remove without anyone noticing. Anyway, we already have board.dts files using the non-omapified compatible strings in the mainline, so if I would now add the omapified compatible strings to .dts files, those old board.dts files would break. So I guess the choice has already been made. I really think you should remove this misuse of device tree code ASAP. It's better to fix it up now than carry the hack for next two years and keep on adding to it. IMHO appending -omap-dss to a random device is an even bigger hack, since its adding lots of bloat to the API. Let's assume there is another OS using DT for ARM, but has no proper API for SPI controllers and it introduces your hack to SPI devices. That would mean each SPI device has -omap-spi appended (or -exynos-spi, -foo-spi, ...). At least I would blame them for creating a huge unmaintainable mess. I think Tomi's workaround is a much better hack, since it keeps the API clean. If the code simply prefixes omapdss, to all child-devices of omapdss it can be left mostly untouched, too. -- Sebastian signature.asc Description: Digital signature
Re: [PATCH 3/4] OMAPDSS: panel-sharp-ls037v7dw01: add device tree support
* Sebastian Reichel s...@ring0.de [140516 10:42]: On Fri, May 16, 2014 at 09:07:17AM -0700, Tony Lindgren wrote: * Tomi Valkeinen tomi.valkei...@ti.com [140515 22:57]: On 15/05/14 21:21, Tony Lindgren wrote: But you're right, having sharp,ls037v7dw01-omap-dss in the .dts is an alternative for the compatible-string conversion we do now. I guess it's a matter of taste, but I rather hide it inside the kernel, in an internal omapdss file, than pollute the .dts files with those compatible strings. Well it avoid you parsing through all the nodes during booting and leaves out the function to do remapping. And removes the need for maintaining a custom display mapping table. I'd say that's a pretty good list of advantages right there :) Yep... I don't know. Maybe I'm being too careful about doing wrong things with .dts. I just like it more if any hacks are in kernel code, which I can remove without anyone noticing. Anyway, we already have board.dts files using the non-omapified compatible strings in the mainline, so if I would now add the omapified compatible strings to .dts files, those old board.dts files would break. So I guess the choice has already been made. I really think you should remove this misuse of device tree code ASAP. It's better to fix it up now than carry the hack for next two years and keep on adding to it. IMHO appending -omap-dss to a random device is an even bigger hack, since its adding lots of bloat to the API. Let's assume there is another OS using DT for ARM, but has no proper API for SPI controllers and it introduces your hack to SPI devices. That would mean each SPI device has -omap-spi appended (or -exynos-spi, -foo-spi, ...). At least I would blame them for creating a huge unmaintainable mess. I think you're misunderstanding. I do not want the naming to be Linux specific. The naming should naturally be as hardware specific as possible. In this case something like: compatible = sharp,ls037v7dw01-dss, sharp,ls037v7dw01; Or we should probably use: compatible = sharp,ls037v7dw01-dpi, sharp,ls037v7dw01; As dpi here reflects the hardware it's connected to. The dss is probably a Linux name. Not use what you're after with the SPI example though, but sounds like that's something different. I think Tomi's workaround is a much better hack, since it keeps the API clean. If the code simply prefixes omapdss, to all child-devices of omapdss it can be left mostly untouched, too. AFAIK that remapping not needed at all. All that is already available with the compatible flags. 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: OMAP DSS: panel-dpi and enable gpios
On 16 May 2014 09:44, Tomi Valkeinen tomi.valkei...@ti.com wrote:
On 16/05/14 00:02, Joachim Eastwood wrote:
On 15 May 2014 15:18, Tomi Valkeinen tomi.valkei...@ti.com wrote:
On 12/05/14 20:58, Joachim Eastwood wrote:
Hello Tomi,
There seems to be a mismatch between your panel-dpi code and DT docs.
The docs state that enable-gpios is optinal but in panel-dpi.c you
have the following code
gpio = devm_gpiod_get(pdev-dev, enable);
if (IS_ERR(gpio)) {
dev_err(pdev-dev, failed to parse enable gpio\n);
return PTR_ERR(gpio);
} else {
gpiod_direction_output(gpio, 0);
ddata-enable_gpio = gpio;
}
Making probing fail on my DT since I don't use enable-gpios with
Would this work? Only compile tested.
diff --git a/drivers/video/fbdev/omap2/displays-new/panel-dpi.c
b/drivers/video/fbdev/omap2/displays-new/panel-dpi.c
index dca6b10d1157..2ac38eaa4c8f 100644
--- a/drivers/video/fbdev/omap2/displays-new/panel-dpi.c
+++ b/drivers/video/fbdev/omap2/displays-new/panel-dpi.c
@@ -210,14 +210,19 @@ static int panel_dpi_probe_of(struct platform_device
*pdev)
struct gpio_desc *gpio;
gpio = devm_gpiod_get(pdev-dev, enable);
+
if (IS_ERR(gpio)) {
- dev_err(pdev-dev, failed to parse enable gpio\n);
- return PTR_ERR(gpio);
+ r = PTR_ERR(gpio);
+ if (r == -EPROBE_DEFER || r != -ENOENT)
+ return r;
+ else
+ gpio = NULL;
} else {
gpiod_direction_output(gpio, 0);
- ddata-enable_gpio = gpio;
}
+ ddata-enable_gpio = gpio;
+
ddata-backlight_gpio = -ENOENT;
r = of_get_display_timing(node, panel-timing, timing);
Seems to do the trick here.
Display is showing Tux's on boot up again :)
The check above was a bit too complex. Here's an updated patch.
From f48b44ca73e29b2328e7852d9beb06b161bb1cb4 Mon Sep 17 00:00:00 2001
From: Tomi Valkeinen tomi.valkei...@ti.com
Date: Thu, 15 May 2014 16:19:44 +0300
Subject: [PATCH] OMAPDSS: panel-dpi: enable-gpio
The enable gpio should be optional, but the driver returns an error if
it doesn't get the gpio.
So change the driver to accept -ENOENT error.
Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
---
drivers/video/fbdev/omap2/displays-new/panel-dpi.c | 10 +++---
1 file changed, 7 insertions(+), 3 deletions(-)
diff --git a/drivers/video/fbdev/omap2/displays-new/panel-dpi.c
b/drivers/video/fbdev/omap2/displays-new/panel-dpi.c
index dca6b10d1157..3636b61dc9b4 100644
--- a/drivers/video/fbdev/omap2/displays-new/panel-dpi.c
+++ b/drivers/video/fbdev/omap2/displays-new/panel-dpi.c
@@ -210,14 +210,18 @@ static int panel_dpi_probe_of(struct platform_device
*pdev)
struct gpio_desc *gpio;
gpio = devm_gpiod_get(pdev-dev, enable);
+
if (IS_ERR(gpio)) {
- dev_err(pdev-dev, failed to parse enable gpio\n);
- return PTR_ERR(gpio);
+ if (PTR_ERR(gpio) != -ENOENT)
+ return PTR_ERR(gpio);
+ else
+ gpio = NULL;
} else {
gpiod_direction_output(gpio, 0);
- ddata-enable_gpio = gpio;
}
+ ddata-enable_gpio = gpio;
+
ddata-backlight_gpio = -ENOENT;
r = of_get_display_timing(node, panel-timing, timing);
--
1.9.1
Tested-by: Joachim Eastwood manab...@gmail.com
This also works fine.
regards
Joachim Eastwood
--
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: DSS and HDMI kernel panic on OMAP4
On 16 May 2014 07:24, Tomi Valkeinen tomi.valkei...@ti.com wrote: On 16/05/14 00:26, Joachim Eastwood wrote: On 15 May 2014 23:14, Joachim Eastwood manab...@gmail.com wrote: Hello Tomi, I wanted to test my Variscite patches after Tony merged them into his 3.16 dt branch so created a base branch from Linus master and pull in Tony's 3.16 dt and your dss for-next branch. I discovered that booting with a HDMI monitor connected or plugging in one cause a kernel panic. See the log at: http://slexy.org/raw/s20xo68UPx Any idea what it could be? I also noted this in the boot log: [ 0.984527] omapdss_hdmi 58006000.encoder: can't request region for resource [mem 0x58006400-0x580073ff] I don't think I have seen this before. What I previously have tested have been Linus master + my Variscite patches and your panel-dpi dt + hdmi hpd patches cherry-picked. Reverting OMAPDSS: HDMI: cleanup ioremaps 59b3d38a3691396783df108 from your for-next branch fixes the problem. I think that's somehow HDMI audio enabled. I bet if you disable HDMI audio, the error goes away. Yes, disabling HDMI audio config option makes the panic disappear. But since nothing prevents you from turning on this option this is not a solution. If I cat /proc/iomem, I see: 58006000-58006fff : omap-hdmi-audio-dai 58006200-580062ff : pll 58006300-580063ff : phy Without sound support, I don't get the error and I see: 58006200-580062ff : pll 58006300-580063ff : phy 58006400-580073ff : core With the patch 59b3d38a36913 reverted I actually have 2 omap-hdmi-audio-dai entries in iomem: 48046000-48046fff : omap-hdmi-audio-dai 58006000-58006fff : omap-hdmi-audio-dai The first one disappear after patch 59b3d38a36913 is applied. Reverting 59b3d38a3691396783df108e6afbba30656edccb helps, because before that patch the hdmi driver didn't actually reserve the regions. So, I don't really have any idea yet what's going on there, but the problem is somewhere around hdmi audio. I see. Would be nice have this fixed before the stuff hits mainline. regards Joachim Eastwood -- 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 v6 2/4] ARM: dts: am437x-gp-evm: add support for parallel NAND flash
Hi Tony, Roger,
From: Tony Lindgren [mailto:t...@atomide.com]
* Roger Quadros rog...@ti.com [140516 05:23]:
On 05/16/2014 02:03 PM, Pekon Gupta wrote:
+gpmc {
+ status = okay;
+ pinctrl-names = default;
+ pinctrl-0 = nand_flash_x8;
+ ranges = 0 0 0 0x0100;/* minimum GPMC partition = 16MB */
+ nand@0,0 {
+ reg = 0 0 0x37c; /* device IO registers */
This register space is used by the parent GPMC node as well as the NAND
controller. So doing a
request_and_ioremap() on this space will fail as it is already taken by the
GPMC driver.
Further, the GPMC register space doesn't map to the GPMC memory map created
by this Chip select
but it is mapped to L3_IO space. i.e. (physical address 0x6e00 )
We could have split the GPMC register space into GPMC part and NAND part but
to add to the
complexity, the register spaces for GPMC vs NAND are interleaved so it can't
be easily split up. The way
the NAND driver is currently written is that it expects the register addresses
to come via platform data,
primarily to get around this address interleaving issue.
Apart from the GPMC register space, the NAND controller uses 4 bytes of GPMC
memory map for
I/O, and that is something that could be reflected here.
e.g.
reg = 0 0 4; /* NAND I/O space */
Guys, the reg size here is size of the IO region for the
NAND driver, it should not have anything to do with the GPMC
registers for the GPMC functions that the NAND driver may call.
So it sounds like 0x37c is wrong, and 4 is the right value if
the NAND chip has only one IO register.
Yes, Roger and myself both agree on the actual size of 4.
But what I'm not sure is what should be offset for a io-remapped region.
Apologies for my ignorance here, as I'm not good in this memory mapping
concept..
- I understand that for 'memory mapped' device offset is with respect to
base-address of chip-select.
- But for indirectly mapped device (like NAND) how is offset calculated?
Example: For CS0 in GPMC ..
GPMC_NAND_COMMAND_0 = 0x007c
GPMC_NAND_ADDRESS_0 = 0x0080
GPMC_NAND_DATA_0 = 0x0084
(1) Now, should the 'offset' for reg property used for NAND node
connected at CS=0. reg = 0 ?? 4
(a) Should it be equal to 'GPMC_NAND_ADDRESS_0'?
OR
(b) There is no relation between 'GPMC register' and 'NAND partition' offset?
(2) If considering (a) then should size consider only GPMC_NAND_ADDRESS_0
or also include GPMC_NAND_COMMAND_0 and GPMC_NAND_DATA_0?
This is why I used the size of complete GPMC register space for NAND region
also.
But still, the start address can't be 0 and has to be assigned when this CS
region is mapped. It is still
unclear to me how that can be done.
If the offset for the NAND driver needs to be different from 0,
it can be in the offset. For example, the smsc,lan91c94 driver
wants the IO address space to be at offset 0x300 to avoid some
extra warnings during the boot. So for that, the reg entry is:
reg = 1 0x300 0xf;
Where we have:
1 = chip select
0x300 = offset of smsc device register IO space from the start of
16MB minimum GPMC partition
This is where my confusion lies, where is the 0x300 coming from?
Is this the offset of I/O register in given Ethernet IP register space?
0xf = size of smsc device register IO space that the Ethernet
driver ioremaps
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 v2 1/2] ARM: dts: am335x-bone: add support for beaglebone NAND cape
Hi Ezequiel, Sorry for delayed replies.. From: Ezequiel Garcia [mailto:ezequiel.gar...@free-electrons.com] Pekon, A few questions regarding this patch, despite the fact I'm not sure it will ever be included. On 20 Mar 01:04 PM, Pekon Gupta wrote: +0x70 (MUX_MODE0 | PIN_INPUT_PULLUP )/* gpmc_wait0.gpmc_wait0 */ +0x74 (MUX_MODE7 | PIN_OUTPUT_PULLUP)/* gpmc_wpn.gpio0_30 */ Is this output pin? Yes, it's the Write Protect (WP) pin. And goes controller - device. +0x7c (MUX_MODE0 | PIN_OUTPUT_PULLUP)/* gpmc_csn0.gpmc_csn0 */ Again: is this output pin? Yes, this is Chip-select and goes from controller - device. Though it should already have external pull-up resistor on board, to avoid glitches due to noise, and avoid device getting confused when SoC is not driving anything (like before pin-muxing). +gpmc,wait-on-read = true; +gpmc,wait-on-write = true; The devicetree binding says these wait properties are bool, so the above should be: gpmc,wait-on-read; gpmc,wait-on-write; But the problem is that there's no wait-pin defined, so this not enabled. Could you explain what should be the correct binding? This is very confusing for me. I have fixed the above DT mapping in newer version of the patch [1]. Sorry, yes the wait-pin monitoring implementation is not cleanly done, there is mix of platform_data and DT stuff. So in addition to updated DT patch you need following patch to enable wait-pin monitoring in NAND driver. http://www.spinics.net/lists/linux-omap/msg107253.html 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 v6 2/4] ARM: dts: am437x-gp-evm: add support for parallel NAND flash
Pekon,
On 05/16/2014 09:52 PM, Gupta, Pekon wrote:
Hi Tony, Roger,
From: Tony Lindgren [mailto:t...@atomide.com]
* Roger Quadros rog...@ti.com [140516 05:23]:
On 05/16/2014 02:03 PM, Pekon Gupta wrote:
+gpmc {
+ status = okay;
+ pinctrl-names = default;
+ pinctrl-0 = nand_flash_x8;
+ ranges = 0 0 0 0x0100;/* minimum GPMC partition = 16MB */
+ nand@0,0 {
+ reg = 0 0 0x37c; /* device IO registers */
This register space is used by the parent GPMC node as well as the NAND
controller. So doing a
request_and_ioremap() on this space will fail as it is already taken by the
GPMC driver.
Further, the GPMC register space doesn't map to the GPMC memory map created
by this Chip select
but it is mapped to L3_IO space. i.e. (physical address 0x6e00 )
We could have split the GPMC register space into GPMC part and NAND part
but to add to the
complexity, the register spaces for GPMC vs NAND are interleaved so it can't
be easily split up. The way
the NAND driver is currently written is that it expects the register
addresses to come via platform data,
primarily to get around this address interleaving issue.
Apart from the GPMC register space, the NAND controller uses 4 bytes of
GPMC memory map for
I/O, and that is something that could be reflected here.
e.g.
reg = 0 0 4; /* NAND I/O space */
Guys, the reg size here is size of the IO region for the
NAND driver, it should not have anything to do with the GPMC
registers for the GPMC functions that the NAND driver may call.
So it sounds like 0x37c is wrong, and 4 is the right value if
the NAND chip has only one IO register.
Yes, Roger and myself both agree on the actual size of 4.
But what I'm not sure is what should be offset for a io-remapped region.
Apologies for my ignorance here, as I'm not good in this memory mapping
concept..
- I understand that for 'memory mapped' device offset is with respect to
base-address of chip-select.
- But for indirectly mapped device (like NAND) how is offset calculated?
This would depend on what the NAND driver expects. In the current OMAP nand
driver it expects only the memory mapped NAND I/O resource.
Example: For CS0 in GPMC ..
GPMC_NAND_COMMAND_0 = 0x007c
GPMC_NAND_ADDRESS_0 = 0x0080
GPMC_NAND_DATA_0 = 0x0084
OK, let's say that we want to update that NAND driver to accept a second memory
resource which would be the GPMC registers starting from GPMC_NAND_COMMAND_0
(phy.addr 0x6e00 007c), then we need to define a new address in the ranges
property of the gpmc node.
Something like so
ranges = 0 0 0x 0x0100 /* GPMC external map */
1 0 0x6e00 0x037c; /* GPMC register map */
nand@0,0 {
reg = 0 0 4/* NAND I/O space */
1 0x7c 3/* NAND controller registers */
Since range 1 started from 0x6e00 we specify offset as 0x7c.
But at the moment the NAND driver doesn't directly access the GPMC register map
so it should be sufficient to just specify the I/O space.
(1) Now, should the 'offset' for reg property used for NAND node
connected at CS=0. reg = 0 ?? 4
(a) Should it be equal to 'GPMC_NAND_ADDRESS_0'?
OR
(b) There is no relation between 'GPMC register' and 'NAND partition'
offset?
(2) If considering (a) then should size consider only GPMC_NAND_ADDRESS_0
or also include GPMC_NAND_COMMAND_0 and GPMC_NAND_DATA_0?
This is why I used the size of complete GPMC register space for NAND region
also.
But still, the start address can't be 0 and has to be assigned when this CS
region is mapped. It is still
unclear to me how that can be done.
If the offset for the NAND driver needs to be different from 0,
it can be in the offset. For example, the smsc,lan91c94 driver
wants the IO address space to be at offset 0x300 to avoid some
extra warnings during the boot. So for that, the reg entry is:
reg = 1 0x300 0xf;
Where we have:
1 = chip select
0x300 = offset of smsc device register IO space from the start of
16MB minimum GPMC partition
This is where my confusion lies, where is the 0x300 coming from?
Is this the offset of I/O register in given Ethernet IP register space?
I'm not sure about 0x300 but this is my guess.
The smsc register addresses start at 0x300. In theory this could be aligned to
the CS start address and we could have worked with 0 offset. But because of the
16MB min. granularity requirement for the GPMC CS start address, A23:A0 have to
be 0. As CS start address can never be aligned to 0x300 we can't have 0 offset.
cheers,
-roger
--
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 v6 2/4] ARM: dts: am437x-gp-evm: add support for parallel NAND flash
* Roger Quadros rog...@ti.com [140516 13:30]:
Pekon,
On 05/16/2014 09:52 PM, Gupta, Pekon wrote:
Hi Tony, Roger,
From: Tony Lindgren [mailto:t...@atomide.com]
* Roger Quadros rog...@ti.com [140516 05:23]:
On 05/16/2014 02:03 PM, Pekon Gupta wrote:
+gpmc {
+status = okay;
+pinctrl-names = default;
+pinctrl-0 = nand_flash_x8;
+ranges = 0 0 0 0x0100;/* minimum GPMC partition =
16MB */
+nand@0,0 {
+reg = 0 0 0x37c; /* device IO registers */
This register space is used by the parent GPMC node as well as the NAND
controller. So doing a
request_and_ioremap() on this space will fail as it is already taken by
the GPMC driver.
Further, the GPMC register space doesn't map to the GPMC memory map
created by this Chip select
but it is mapped to L3_IO space. i.e. (physical address 0x6e00 )
We could have split the GPMC register space into GPMC part and NAND part
but to add to the
complexity, the register spaces for GPMC vs NAND are interleaved so it
can't be easily split up. The way
the NAND driver is currently written is that it expects the register
addresses to come via platform data,
primarily to get around this address interleaving issue.
Apart from the GPMC register space, the NAND controller uses 4 bytes of
GPMC memory map for
I/O, and that is something that could be reflected here.
e.g.
reg = 0 0 4; /* NAND I/O space */
Guys, the reg size here is size of the IO region for the
NAND driver, it should not have anything to do with the GPMC
registers for the GPMC functions that the NAND driver may call.
So it sounds like 0x37c is wrong, and 4 is the right value if
the NAND chip has only one IO register.
Yes, Roger and myself both agree on the actual size of 4.
But what I'm not sure is what should be offset for a io-remapped region.
Apologies for my ignorance here, as I'm not good in this memory mapping
concept..
- I understand that for 'memory mapped' device offset is with respect to
base-address of chip-select.
- But for indirectly mapped device (like NAND) how is offset calculated?
This would depend on what the NAND driver expects. In the current OMAP nand
driver it expects only the memory mapped NAND I/O resource.
Example: For CS0 in GPMC ..
GPMC_NAND_COMMAND_0 = 0x007c
GPMC_NAND_ADDRESS_0 = 0x0080
GPMC_NAND_DATA_0 = 0x0084
OK, let's say that we want to update that NAND driver to accept a second
memory resource which would be the GPMC registers starting from
GPMC_NAND_COMMAND_0 (phy.addr 0x6e00 007c), then we need to define a new
address in the ranges property of the gpmc node.
Something like so
ranges = 0 0 0x 0x0100 /* GPMC external map */
1 0 0x6e00 0x037c; /* GPMC register map */
nand@0,0 {
reg = 0 0 4/* NAND I/O space */
1 0x7c 3/* NAND controller registers */
Since range 1 started from 0x6e00 we specify offset as 0x7c.
But at the moment the NAND driver doesn't directly access the GPMC register
map so it should be sufficient to just specify the I/O space.
(1) Now, should the 'offset' for reg property used for NAND node
connected at CS=0. reg = 0 ?? 4
(a) Should it be equal to 'GPMC_NAND_ADDRESS_0'?
OR
(b) There is no relation between 'GPMC register' and 'NAND partition'
offset?
(2) If considering (a) then should size consider only GPMC_NAND_ADDRESS_0
or also include GPMC_NAND_COMMAND_0 and GPMC_NAND_DATA_0?
This is why I used the size of complete GPMC register space for NAND region
also.
The NAND driver should only ioremap the NAND register(s). The
GPMC driver has the GPMC registers ioremapped, and should allow
the NAND driver to use those registers via some functions in the
GPMC code. Those functions should be ideally made available to
the NAND driver by some Linux generic framework rather than
custom exported functions.
But still, the start address can't be 0 and has to be assigned when this
CS region is mapped. It is still
unclear to me how that can be done.
If the offset for the NAND driver needs to be different from 0,
it can be in the offset. For example, the smsc,lan91c94 driver
wants the IO address space to be at offset 0x300 to avoid some
extra warnings during the boot. So for that, the reg entry is:
reg = 1 0x300 0xf;
Where we have:
1 = chip select
0x300 = offset of smsc device register IO space from the start of
16MB minimum GPMC partition
This is where my confusion lies, where is the 0x300 coming from?
Is this the offset of I/O register in given Ethernet IP register space?
I'm not sure about 0x300 but this is my guess.
The smsc register addresses start at 0x300. In theory this could be aligned
to the CS start address and we
[PATCH] ARM: OMAP2+: Fix DMA hang after off-idle
Commit 6ddeb6d84459 (dmaengine: omap-dma: move IRQ handling to omap-dma)
added support for handling interrupts in the omap dmaengine driver
instead of the legacy driver. Because of different handling for
interrupts this however caused omap3 to hang eventually after hitting
off-idle.
Any of the virtual 32 DMA channels can be assigned to any of the
four DMA interrupts. So commit 6ddeb6d84459 made the omap dmaengine
driver to use the second DMA interrupt while keeping the legacy code
still using the first DMA interrupt.
This means we need to save and restore both IRQENABLE_L1 in addition
to IRQENABLE_L0. As there is a chance that the DSP might be using
IRQENABLE_L2 or IRQENABLE_L3 lines, let's not touch those until
this has been confirmed. Let's just add a comment to the code for
now.
Fixes: 6ddeb6d84459 (dmaengine: omap-dma: move IRQ handling to omap-dma)
Cc: Russell King rmk+ker...@arm.linux.org.uk
Signed-off-by: Tony Lindgren t...@atomide.com
diff --git a/arch/arm/plat-omap/dma.c b/arch/arm/plat-omap/dma.c
index 5f5b975..b5608b1 100644
--- a/arch/arm/plat-omap/dma.c
+++ b/arch/arm/plat-omap/dma.c
@@ -70,6 +70,7 @@ static u32 errata;
static struct omap_dma_global_context_registers {
u32 dma_irqenable_l0;
+ u32 dma_irqenable_l1;
u32 dma_ocp_sysconfig;
u32 dma_gcr;
} omap_dma_global_context;
@@ -1973,10 +1974,17 @@ static struct irqaction omap24xx_dma_irq;
/**/
+/*
+ * Note that we are currently using only IRQENABLE_L0 and L1.
+ * As the DSP may be using IRQENABLE_L2 and L3, let's not
+ * touch those for now.
+ */
void omap_dma_global_context_save(void)
{
omap_dma_global_context.dma_irqenable_l0 =
p-dma_read(IRQENABLE_L0, 0);
+ omap_dma_global_context.dma_irqenable_l1 =
+ p-dma_read(IRQENABLE_L1, 0);
omap_dma_global_context.dma_ocp_sysconfig =
p-dma_read(OCP_SYSCONFIG, 0);
omap_dma_global_context.dma_gcr = p-dma_read(GCR, 0);
@@ -1991,6 +1999,8 @@ void omap_dma_global_context_restore(void)
OCP_SYSCONFIG, 0);
p-dma_write(omap_dma_global_context.dma_irqenable_l0,
IRQENABLE_L0, 0);
+ p-dma_write(omap_dma_global_context.dma_irqenable_l1,
+ IRQENABLE_L1, 0);
if (IS_DMA_ERRATA(DMA_ROMCODE_BUG))
p-dma_write(0x3 , IRQSTATUS_L0, 0);
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: OMAP: omap3stalker: remove two Kconfig macros
* Paul Bolle pebo...@tiscali.nl [140515 11:38]:
Checks for CONFIG_OMAP2_VENC_OUT_TYPE_SVIDEO and
CONFIG_OMAP2_VENC_OUT_TYPE_COMPOSITE were added in v2.6.35. But the
related Kconfig symbols have never been added to the tree. Remove these
checks.
Initialize connector_type to OMAP_DSS_VENC_TYPE_COMPOSITE explicitly.
That's what's happening currently: OMAP_DSS_VENC_TYPE_COMPOSITE equals
zero and connector_type remains zero since both checks currently fail.
Thanks applying into omap-for-v3.16/board.
Tony
Signed-off-by: Paul Bolle pebo...@tiscali.nl
---
Untested.
arch/arm/mach-omap2/board-omap3stalker.c | 4
1 file changed, 4 deletions(-)
diff --git a/arch/arm/mach-omap2/board-omap3stalker.c
b/arch/arm/mach-omap2/board-omap3stalker.c
index 119efaf5808a..a2e035e0792a 100644
--- a/arch/arm/mach-omap2/board-omap3stalker.c
+++ b/arch/arm/mach-omap2/board-omap3stalker.c
@@ -121,11 +121,7 @@ static struct platform_device omap3stalker_tfp410_device
= {
static struct connector_atv_platform_data omap3stalker_tv_pdata = {
.name = tv,
.source = venc.0,
-#if defined(CONFIG_OMAP2_VENC_OUT_TYPE_SVIDEO)
- .connector_type = OMAP_DSS_VENC_TYPE_SVIDEO,
-#elif defined(CONFIG_OMAP2_VENC_OUT_TYPE_COMPOSITE)
.connector_type = OMAP_DSS_VENC_TYPE_COMPOSITE,
-#endif
.invert_polarity = false,
};
--
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: OMAP: remove some dead code
* Aaro Koskinen aaro.koski...@iki.fi [140515 12:48]: On Thu, May 15, 2014 at 09:16:21PM +0200, Paul Bolle wrote: A check for CONFIG_CBUS_TAHVO_USB was added in v2.6.17. The related Kconfig symbol has never been part of the tree. Remove that check. Replace the while (...) loop with a simple if (...) statement, while we're at it. Signed-off-by: Paul Bolle pebo...@tiscali.nl Acked-by: Aaro Koskinen aaro.koski...@iki.fi --- Untested, as usual. A quick search across the history of the tree suggests CBUS_TAHVO_USB was N770 related. Not that this matters much. Yes, Tahvo USB is only used on Nokia 770 (which is the correct name, not N770). The driver is nowadays behind TAHVO_USB, but like you said the old symbol was never part of the mainline so it's OK to delete it. Thanks applying into omap-for-v3.16/board. 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: SX1: remove check for CONFIG_SX1_OLD_FLASH
* Paul Bolle pebo...@tiscali.nl [140515 12:42]: A check for CONFIG_SX1_OLD_FLASH was added in v2.6.24. But the related Kconfig symbol was never part of the tree. So we can remove some dead code. Thanks applying into omap-for-v3.16/board. 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: AM3517EVM: remove check for CONFIG_PANEL_SHARP_LQ043T1DG01
* Paul Bolle pebo...@tiscali.nl [140515 12:55]: The Kconfig symbol PANEL_SHARP_LQ043T1DG01 was removed in v2.6.38. The check for CONFIG_PANEL_SHARP_LQ043T1DG01 and its MODULE variant has evaluated to false ever since. Remove that check. Thanks applying into omap-for-v3.16/board. Tony -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2] ARM: OMAP: replace checks for CONFIG_USB_GADGET_OMAP
* Paul Bolle pebo...@tiscali.nl [140516 03:01]: Commit 193ab2a60700 (usb: gadget: allow multiple gadgets to be built) apparently required that checks for CONFIG_USB_GADGET_OMAP would be replaced with checks for CONFIG_USB_OMAP. Do so now for the remaining checks for CONFIG_USB_GADGET_OMAP, even though these checks have basically been broken since v3.1. And, since we're touching this code, use the IS_ENABLED() macro, so things will now (hopefully) also work if USB_OMAP is modular. Fixes: 193ab2a60700 (usb: gadget: allow multiple gadgets to be built) Signed-off-by: Paul Bolle pebo...@tiscali.nl --- v2: us IS_ENABLED() as Felipe requested. Still untested. Thanks applying into omap-for-v3.16/board. Tony -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [GIT PULL] ARM: OMAP2+: some hwmod data patches for v3.16
* Tomi Valkeinen tomi.valkei...@ti.com [140516 01:39]: Hi Paul, On 16/05/14 07:45, Paul Walmsley wrote: Hi Tony The following changes since commit d1db0eea852497762cab43b905b879dfcd3b8987: Linux 3.15-rc3 (2014-04-27 19:29:27 -0700) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/pjw/omap-pending.git for-v3.16/hwmod-a for you to fetch changes up to 433480707967187a74ced38bd38edba749998013: ARM: OMAP2+: hwmod: OMAP5 DSS hwmod data (2014-05-14 12:26:10 -0600) First (and possibly last) set of hwmod data changes for v3.16. This set should clean up some obsolete OMAP4 hwmod data, and add OMAP5 DSS support. What about the AM43xx hwmod data I sent in the same series: http://article.gmane.org/gmane.linux.ports.arm.omap/114192 I guess the issue there is that there's no way for Paul or much anybody else to check it against any documentation or hardware :( Is this just cut and paste code, or has you verified it against the documentation and the hardare? Anyways, pulling this set into omap-for-v3.16/soc thanks. Regards, Tony -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [GIT PULL] ARM: OMAP2+: some PRCM cleanup patches for v3.16
* Paul Walmsley p...@pwsan.com [140515 21:48]: Hi Tony The following changes since commit c9eaa447e77efe77b7fa4c953bd62de8297fd6c5: Linux 3.15-rc1 (2014-04-13 14:18:35 -0700) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/pjw/omap-pending.git for-v3.16/prcm-cleanup-a for you to fetch changes up to 70fcebf1965b66d73bd8ae7955bd663ab8012c56: ARM: OMAP4: PRCM: remove references to cm-regbits-44xx.h from PRCM core files (2014-05-15 22:35:10 -0600) Some OMAP PRCM cleanup patches. These help prepare to convert the PRCM code into drivers. Basic build, boot, and PM test results are available here: http://www.pwsan.com/omap/testlogs/prcm-cleanup-v3.16/20140515213244/ Thanks pulling into omap-for-v3.16/prcm. Tony Tero Kristo (10): ARM: OMAP3: CM: remove a few OMAP34XX_CM_REGADDR defines ARM: OMAP2+: prcm: add omap_test_timeout to prcm-common.h ARM: OMAP2/3: CM: remove some external dependencies ARM: OMAP4: CM: use cm_base* in register address calculations ARM: OMAP2+: PRCM: cleanup some header includes ARM: OMAP2+: PRM: remove unnecessary cpu_is_XXX calls from prm_init / exit ARM: OMAP3/4: PRM: provide io chain reconfig function through irq setup ARM: OMAP3/OMAP4: PRM: add prm_features flags and add IO wakeup under it ARM: OMAP3/4: PRM: add support of late_init call to prm_ll_ops ARM: OMAP4: PRCM: remove references to cm-regbits-44xx.h from PRCM core files arch/arm/mach-omap2/clockdomain.h | 3 ++- arch/arm/mach-omap2/cm2xxx.c | 15 ++--- arch/arm/mach-omap2/cm33xx.h | 3 --- arch/arm/mach-omap2/cm3xxx.c | 25 -- arch/arm/mach-omap2/cm3xxx.h | 5 ++--- arch/arm/mach-omap2/cm44xx.c | 11 -- arch/arm/mach-omap2/cm_common.c| 2 +- arch/arm/mach-omap2/cminst44xx.c | 10 ++--- .../mach-omap2/omap_hwmod_33xx_43xx_ipblock_data.c | 1 + arch/arm/mach-omap2/powerdomain-common.c | 1 - arch/arm/mach-omap2/powerdomain.c | 1 + arch/arm/mach-omap2/powerdomain.h | 3 +-- arch/arm/mach-omap2/prcm-common.h | 24 + arch/arm/mach-omap2/prcm_mpu44xx.h | 1 - arch/arm/mach-omap2/prm.h | 10 + arch/arm/mach-omap2/prm2xxx.c | 13 +-- arch/arm/mach-omap2/prm2xxx_3xxx.c | 1 - arch/arm/mach-omap2/prm33xx.c | 1 - arch/arm/mach-omap2/prm3xxx.c | 20 - arch/arm/mach-omap2/prm44xx.c | 18 +++- arch/arm/mach-omap2/prm_common.c | 17 +-- 21 files changed, 93 insertions(+), 92 deletions(-) -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: OMAP4: Fix the boot regression with CPU_IDLE enabled
* Santosh Shilimkar santosh.shilim...@ti.com [140516 06:43]: Tony, On Thursday 15 May 2014 02:29 PM, Santosh Shilimkar wrote: On Thursday 15 May 2014 01:54 PM, Santosh Shilimkar wrote: On Thursday 15 May 2014 01:50 PM, Daniel Lezcano wrote: On 05/15/2014 07:03 PM, Santosh Shilimkar wrote: [..] With above mentioned change, it should work. Other alternatives is OMAP4 driver does its won registration where it can start the timer. The way it was before the consolidation. Ofcourse if you have better fix, then great. What is your suggestion. We *must* fix the regression asap. I think $subject patch with an update to bctimer start under CPUIDLE_FLAG_COUPLED seems a good way forward. Do let me know. Did you see Alex Shi's email [cc'ed] ? Reverting this change makes the panda ES to hang. The hang is definitely due to the bctimer not started. As I said, I assumed it was and then you corrected saying it is under the flag. I am not convinced the culprit is this code you are trying to revert. fair enough. Thats why I said if you have an alternative fix thats great. For record, below is updated patch with bctimer started which was missed in earlier version. I haven't tested it though. Alex, Please give a try with your test-case and see if you still see the hang. Am just curious about your issue and hence the request.. Alex tested below patch and he don't see the hang so the patch is addressing the issue. If Daniel works out an alternate fix to avoid reverts, that will be great but if not, we should merge the below patch. I let you take call on it. Daniel any news on this? And just to recap, this problem can be reproduced with current Linux next with omap2plus_defconfig with CONFIG_CPU_IDLE enabled. The system should hang during the boot at some point. And for the record, the omap3 hang fix is now posted to the lists as [PATCH] ARM: OMAP2+: Fix DMA hang after off-idle. This should not have anything to do with the omap4 cpu_idle hang as omap4 does not currently lose context during idle. 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 3/4] OMAPDSS: panel-sharp-ls037v7dw01: add device tree support
* Tony Lindgren t...@atomide.com [140516 11:02]: * Sebastian Reichel s...@ring0.de [140516 10:42]: On Fri, May 16, 2014 at 09:07:17AM -0700, Tony Lindgren wrote: * Tomi Valkeinen tomi.valkei...@ti.com [140515 22:57]: On 15/05/14 21:21, Tony Lindgren wrote: But you're right, having sharp,ls037v7dw01-omap-dss in the .dts is an alternative for the compatible-string conversion we do now. I guess it's a matter of taste, but I rather hide it inside the kernel, in an internal omapdss file, than pollute the .dts files with those compatible strings. Well it avoid you parsing through all the nodes during booting and leaves out the function to do remapping. And removes the need for maintaining a custom display mapping table. I'd say that's a pretty good list of advantages right there :) Yep... I don't know. Maybe I'm being too careful about doing wrong things with .dts. I just like it more if any hacks are in kernel code, which I can remove without anyone noticing. Anyway, we already have board.dts files using the non-omapified compatible strings in the mainline, so if I would now add the omapified compatible strings to .dts files, those old board.dts files would break. So I guess the choice has already been made. I really think you should remove this misuse of device tree code ASAP. It's better to fix it up now than carry the hack for next two years and keep on adding to it. IMHO appending -omap-dss to a random device is an even bigger hack, since its adding lots of bloat to the API. Let's assume there is another OS using DT for ARM, but has no proper API for SPI controllers and it introduces your hack to SPI devices. That would mean each SPI device has -omap-spi appended (or -exynos-spi, -foo-spi, ...). At least I would blame them for creating a huge unmaintainable mess. I think you're misunderstanding. I do not want the naming to be Linux specific. The naming should naturally be as hardware specific as possible. In this case something like: compatible = sharp,ls037v7dw01-dss, sharp,ls037v7dw01; Or we should probably use: compatible = sharp,ls037v7dw01-dpi, sharp,ls037v7dw01; As dpi here reflects the hardware it's connected to. The dss is probably a Linux name. Not use what you're after with the SPI example though, but sounds like that's something different. I think Tomi's workaround is a much better hack, since it keeps the API clean. If the code simply prefixes omapdss, to all child-devices of omapdss it can be left mostly untouched, too. AFAIK that remapping not needed at all. All that is already available with the compatible flags. And alternatively we can also just use the sharp,ls037v7dw01 in the panel driver(s). We can have the panels bail out in driver probe based on of_machine_is_compatible if nothing else is available. Also, currently the remapping code also probably keeps prepending more and more omapdss,omapdss,omapdss,... on each kexec reboot? And it would be quite silly for each display controller to have to do their own remapping for shared panels? If we still still despite all these reasons decide to go with the remapping of the compatible strings, it should really be a Linux generic (or drivers/video generic function), not implemented for each display controller. Cheers, Tony -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 6/6] mmc: omap_hsmmc: split omap-dma header file
* Balaji T K balaj...@ti.com [140509 09:47]:
moving dmaengine consumer specific function to omap-dmaengine.h
to Resolve build failure seen with sh-allmodconfig:
include/linux/omap-dma.h:171:8: error: expected identifier before numeric
constant
make[4]: *** [drivers/mmc/host/omap_hsmmc.o] Error 1
Cc: Russell King - ARM Linux li...@arm.linux.org.uk
Cc: Tony Lindgren t...@atomide.com
Signed-off-by: Balaji T K balaj...@ti.com
---
drivers/mmc/host/omap_hsmmc.c |2 +-
include/linux/omap-dma.h | 19 +--
include/linux/omap-dmaengine.h | 21 +
3 files changed, 23 insertions(+), 19 deletions(-)
create mode 100644 include/linux/omap-dmaengine.h
diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
index cba71d6..6b7b755 100644
--- a/drivers/mmc/host/omap_hsmmc.c
+++ b/drivers/mmc/host/omap_hsmmc.c
@@ -31,7 +31,7 @@
#include linux/of.h
#include linux/of_gpio.h
#include linux/of_device.h
-#include linux/omap-dma.h
+#include linux/omap-dmaengine.h
#include linux/mmc/host.h
#include linux/mmc/core.h
#include linux/mmc/mmc.h
diff --git a/include/linux/omap-dma.h b/include/linux/omap-dma.h
index 41a13e7..999f52d 100644
--- a/include/linux/omap-dma.h
+++ b/include/linux/omap-dma.h
@@ -1,23 +1,6 @@
-/*
- * OMAP DMA Engine support
- *
- * 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.
- */
#ifndef __LINUX_OMAP_DMA_H
#define __LINUX_OMAP_DMA_H
-
-struct dma_chan;
-
-#if defined(CONFIG_DMA_OMAP) || defined(CONFIG_DMA_OMAP_MODULE)
-bool omap_dma_filter_fn(struct dma_chan *, void *);
-#else
-static inline bool omap_dma_filter_fn(struct dma_chan *c, void *d)
-{
- return false;
-}
-#endif
+#include linux/omap-dmaengine.h
Can't the drivers needing this include it directly?
Also, has this been tested with make randconfig? Changes like
this can easily cause problems elsewhere..
Regards,
Tony
/*
* Legacy OMAP DMA handling defines and functions
diff --git a/include/linux/omap-dmaengine.h b/include/linux/omap-dmaengine.h
new file mode 100644
index 000..2b0b6aa
--- /dev/null
+++ b/include/linux/omap-dmaengine.h
@@ -0,0 +1,21 @@
+/*
+ * OMAP DMA Engine support
+ *
+ * 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.
+ */
+#ifndef __LINUX_OMAP_DMAENGINE_H
+#define __LINUX_OMAP_DMAENGINE_H
+
+struct dma_chan;
+
+#if defined(CONFIG_DMA_OMAP) || defined(CONFIG_DMA_OMAP_MODULE)
+bool omap_dma_filter_fn(struct dma_chan *, void *);
+#else
+static inline bool omap_dma_filter_fn(struct dma_chan *c, void *d)
+{
+ return false;
+}
+#endif
+#endif /* __LINUX_OMAP_DMAENGINE_H */
--
1.7.5.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [GIT PULL] ARM: OMAP2+: a few more clock/hwmod fixes for v3.15-rc
* Paul Walmsley p...@pwsan.com [140514 11:52]: Hi Tony, The following changes since commit c9eaa447e77efe77b7fa4c953bd62de8297fd6c5: Linux 3.15-rc1 (2014-04-13 14:18:35 -0700) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/pjw/omap-pending.git for-v3.15-rc/omap-fixes-b for you to fetch changes up to 0f9e19ad88eee820f517b85531b555a0fa73e7e4: ARM: omap5: hwmod_data: Correct IDLEMODE for McPDM (2014-05-14 11:25:58 -0600) Two small OMAP fixes for v3.15-rc. One fixes slow motion or choppy audio playback on OMAP5. The other applies an OMAP3630 fix for clock rate setting for camera to other OMAP3 chips. Basic build, boot, and PM test results are available here: http://www.pwsan.com/omap/testlogs/prcm-fixes-b-v3.15-rc/20140514112639/ Thanks pulling into omap-for-v3.15/fixes-v3. Regards, Tony Laurent Pinchart (1): ARM: OMAP3: clock: Back-propagate rate change from cam_mclk to dpll4_m5 on all OMAP3 platforms Peter Ujfalusi (1): ARM: omap5: hwmod_data: Correct IDLEMODE for McPDM arch/arm/mach-omap2/cclock3xxx_data.c | 3 ++- arch/arm/mach-omap2/omap_hwmod_54xx_data.c | 2 +- 2 files changed, 3 insertions(+), 2 deletions(-) -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] ARM: DRA7/AM43XX: fix header definition for omap44xx_restart
omap44xx_restart is defined as a static void inline when DRA7/AM437X is defined alone, which implies that the restart function is no longer functional even though it is built in. So, fix the definition of the same. Unfortunately, the number of SoCs starting to use omap44xx_restart is starting to grow and the definition looks a little ugly. Signed-off-by: Nishanth Menon n...@ti.com --- based on v3.15-rc5 NOTE: this generates over 80 characters checkpatch warning.. I am not sure other than introducing a definition for restart it could be simplified. arch/arm/mach-omap2/common.h |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/arm/mach-omap2/common.h b/arch/arm/mach-omap2/common.h index d88aff7..46150f4 100644 --- a/arch/arm/mach-omap2/common.h +++ b/arch/arm/mach-omap2/common.h @@ -154,7 +154,7 @@ static inline void omap3xxx_restart(enum reboot_mode mode, const char *cmd) } #endif -#if defined(CONFIG_ARCH_OMAP4) || defined(CONFIG_SOC_OMAP5) +#if defined(CONFIG_ARCH_OMAP4) || defined(CONFIG_SOC_OMAP5) || defined(CONFIG_SOC_DRA7XX) || defined(CONFIG_SOC_AM43XX) void omap44xx_restart(enum reboot_mode mode, const char *cmd); #else static inline void omap44xx_restart(enum reboot_mode mode, const char *cmd) -- 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 v11 0/6] mmc: omap_hsmmc: Enable SDIO IRQ
* Ulf Hansson ulf.hans...@linaro.org [140514 03:22]: On 11 May 2014 13:28, Andreas Fenkart afenk...@gmail.com wrote: Hi Balaji, Tony, all v12 - drop !CONFIG_OF compile break only exists when #undef CONFIG_OF after include headers 1/7(Sebastian Reichel) - do not emit falling back to polling if wake_irq not specified since MMC does not need it, and it might confuse users only emit if pinmux default/idle is not present or claiming the irq failed 2/7(Balaji) - dropped out-of-tree patches 6/7(Balaji) - mention ti,am33xx-hsmmc compatible section in bindings documentation 1/5 Hi Andreas, It seems like we are ready to merge this patchset - I will include it in the next PR I send to Chris. Great! Just gave these a try again after a while, worked fine for me. Thanks Andreas for the patience with updating these patches. 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
