* [PATCH 1/4] OMAPDSS: Fix DSS clock multiplier issue on 3703 and probably 3630
From: Tony Lindgren @ 2014-04-29 23:52 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1398815562-24113-1-git-send-email-tony@atomide.com>
Otherwise we can get often errors like the following and the
display won't come on:
omapdss APPLY error: FIFO UNDERFLOW on gfx, disabling the overlay
omapdss APPLY error: SYNC_LOST on channel lcd, restarting
the output with video overlays disabled
There are some earlier references to this issue:
http://www.spinics.net/lists/linux-omap/msg59511.html
http://www.spinics.net/lists/linux-omap/msg59724.html
It seems that it's safe to set the lower values even for 3630.
If we can confirm that 3630 works with the higher values
reliably we can add further detection.
Signed-off-by: Tony Lindgren <tony@atomide.com>
---
drivers/video/fbdev/omap2/dss/dss.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/video/fbdev/omap2/dss/dss.c b/drivers/video/fbdev/omap2/dss/dss.c
index d55266c..ad6561f 100644
--- a/drivers/video/fbdev/omap2/dss/dss.c
+++ b/drivers/video/fbdev/omap2/dss/dss.c
@@ -707,9 +707,10 @@ static const struct dss_features omap34xx_dss_feats __initconst = {
.dpi_select_source = &dss_dpi_select_source_omap2_omap3,
};
+/* Supposedly 3630 can use div 32 mult 2, but that needs to be rechecked */
static const struct dss_features omap3630_dss_feats __initconst = {
- .fck_div_max = 32,
- .dss_fck_multiplier = 1,
+ .fck_div_max = 16,
+ .dss_fck_multiplier = 2,
.parent_clk_name = "dpll4_ck",
.dpi_select_source = &dss_dpi_select_source_omap2_omap3,
};
--
1.8.1.1
^ permalink raw reply related
* [PATCH 2/4] OMAPDSS: panel-sharp-ls037v7dw01: update to use gpiod
From: Tony Lindgren @ 2014-04-29 23:52 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1398815562-24113-1-git-send-email-tony@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 <tony@atomide.com>
---
.../omap2/displays-new/panel-sharp-ls037v7dw01.c | 92 +++++++++-------------
1 file changed, 38 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 b2f710b..de8473a 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 (!IS_ERR(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 (!IS_ERR(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 (!IS_ERR(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 (!IS_ERR(ddata->resb_gpio))
+ gpiod_set_value_cansleep(ddata->resb_gpio, 0);
/* wait at least 5 vsyncs after disabling the LCD */
@@ -182,6 +182,21 @@ static struct omap_dss_driver sharp_ls_ops = {
.get_resolution = omapdss_default_get_resolution,
};
+static struct gpio_desc *
+sharp_ls_get_gpio(struct device *dev, int gpio, unsigned long flags,
+ char *desc)
+{
+ int r;
+
+ r = devm_gpio_request_one(dev, gpio, flags, desc);
+ if (r) {
+ dev_err(dev, "no %s gpio\n", desc);
+ return ERR_PTR(r);
+ }
+
+ return gpio_to_desc(gpio);
+}
+
static int sharp_ls_probe_pdata(struct platform_device *pdev)
{
const struct panel_sharp_ls037v7dw01_platform_data *pdata;
@@ -204,11 +219,16 @@ 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;
+ ddata->mo_gpio = sharp_ls_get_gpio(&pdev->dev, pdata->mo_gpio,
+ GPIOF_OUT_INIT_LOW, "lcd MO");
+ ddata->lr_gpio = sharp_ls_get_gpio(&pdev->dev, pdata->lr_gpio,
+ GPIOF_OUT_INIT_HIGH, "lcd LR");
+ ddata->ud_gpio = sharp_ls_get_gpio(&pdev->dev, pdata->ud_gpio,
+ GPIOF_OUT_INIT_HIGH, "lcd UD");
+ ddata->resb_gpio = sharp_ls_get_gpio(&pdev->dev, pdata->resb_gpio,
+ GPIOF_OUT_INIT_LOW, "lcd RESB");
+ ddata->ini_gpio = sharp_ls_get_gpio(&pdev->dev, pdata->ini_gpio,
+ GPIOF_OUT_INIT_LOW, "lcd INI");
return 0;
}
@@ -233,41 +253,6 @@ static int sharp_ls_probe(struct platform_device *pdev)
return -ENODEV;
}
- if (gpio_is_valid(ddata->mo_gpio)) {
- r = devm_gpio_request_one(&pdev->dev, ddata->mo_gpio,
- GPIOF_OUT_INIT_LOW, "lcd MO");
- if (r)
- goto err_gpio;
- }
-
- if (gpio_is_valid(ddata->lr_gpio)) {
- r = devm_gpio_request_one(&pdev->dev, ddata->lr_gpio,
- GPIOF_OUT_INIT_HIGH, "lcd LR");
- if (r)
- goto err_gpio;
- }
-
- if (gpio_is_valid(ddata->ud_gpio)) {
- r = devm_gpio_request_one(&pdev->dev, ddata->ud_gpio,
- GPIOF_OUT_INIT_HIGH, "lcd UD");
- if (r)
- goto err_gpio;
- }
-
- if (gpio_is_valid(ddata->resb_gpio)) {
- r = devm_gpio_request_one(&pdev->dev, ddata->resb_gpio,
- GPIOF_OUT_INIT_LOW, "lcd RESB");
- if (r)
- goto err_gpio;
- }
-
- if (gpio_is_valid(ddata->ini_gpio)) {
- r = devm_gpio_request_one(&pdev->dev, ddata->ini_gpio,
- GPIOF_OUT_INIT_LOW, "lcd INI");
- if (r)
- goto err_gpio;
- }
-
ddata->videomode = sharp_ls_timings;
dssdev = &ddata->dssdev;
@@ -287,7 +272,6 @@ static int sharp_ls_probe(struct platform_device *pdev)
return 0;
err_reg:
-err_gpio:
omap_dss_put_device(ddata->in);
return r;
}
--
1.8.1.1
^ permalink raw reply related
* [PATCH 3/4] OMAPDSS: panel-sharp-ls037v7dw01: add device tree support
From: Tony Lindgren @ 2014-04-29 23:52 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1398815562-24113-1-git-send-email-tony@atomide.com>
We can pass the GPIO configuration for ls037v7dw01 in a standard
gpios property.
Signed-off-by: Tony Lindgren <tony@atomide.com>
---
.../bindings/panel/sharp,ls037v7dw01.txt | 53 ++++++++++++++
.../omap2/displays-new/panel-sharp-ls037v7dw01.c | 84 ++++++++++++++++++++--
2 files changed, 133 insertions(+), 4 deletions(-)
create mode 100644 Documentation/devicetree/bindings/panel/sharp,ls037v7dw01.txt
diff --git a/Documentation/devicetree/bindings/panel/sharp,ls037v7dw01.txt b/Documentation/devicetree/bindings/panel/sharp,ls037v7dw01.txt
new file mode 100644
index 0000000..7f6f5e1
--- /dev/null
+++ b/Documentation/devicetree/bindings/panel/sharp,ls037v7dw01.txt
@@ -0,0 +1,53 @@
+SHARP LS037V7DW01 TFT-LCD panel
+
+Required properties:
+- compatible: should be "sharp,ls037v7dw01"
+
+Optional properties:
+- reset-gpios: a GPIO spec for the optional reset pin
+- enable-gpios: a GPIO array for the optional configuration GPIOs
+ ordered MO, LR, UD, INI as specified in the LS037V7DW01.pdf file.
+
+This binding is compatible with the simple-panel binding, which is specified
+in simple-panel.txt in this directory.
+
+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 when connected to a omap2+ based device:
+
+ lcd0: display {
+ compatible = "sharp,ls037v7dw01";
+ power-supply = <&lcd_3v3>;
+ reset-gpios = <&gpio5 27 GPIO_ACTIVE_HIGH>; /* gpio155, lcd RESB */
+ enable-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 */
+ &gpio5 24 GPIO_ACTIVE_HIGH>; /* gpio152, lcd INI */
+
+ panel-timing {
+ clock-frequency = <19200000>;
+ hback-porch = <28>;
+ hactive = <480>;
+ hfront-porch = <1>;
+ hsync-len = <2>;
+ vback-porch = <1>;
+ vactive = <640>;
+ vfront-porch = <1>;
+ vsync-len = <1>;
+ hsync-active = <0>;
+ vsync-active = <0>;
+ de-active = <1>;
+ pixelclk-active = <1>;
+ };
+
+ port {
+ lcd_in: endpoint {
+ remote-endpoint = <&dpi_out>;
+ };
+ };
+ };
+
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 de8473a..3a04fb0 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,19 @@
#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/of_display_timing.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,7 +99,8 @@ 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);
r = in->ops.dpi->enable(in);
@@ -230,6 +235,67 @@ static int sharp_ls_probe_pdata(struct platform_device *pdev)
ddata->ini_gpio = sharp_ls_get_gpio(&pdev->dev, pdata->ini_gpio,
GPIOF_OUT_INIT_LOW, "lcd INI");
+ ddata->videomode = sharp_ls_timings;
+
+ return 0;
+}
+
+static struct gpio_desc *
+sharp_ls_get_gpio_of(struct device *dev, int index, int val, char *desc)
+{
+ struct gpio_desc *gpio;
+
+ gpio = devm_gpiod_get_index(dev, desc, index);
+ if (!IS_ERR(gpio))
+ gpiod_direction_output(gpio, val);
+
+ return gpio;
+}
+
+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;
+ struct display_timing timing;
+ struct videomode vm;
+ 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);
+ }
+
+ r = regulator_enable(ddata->vcc);
+ if (r != 0) {
+ dev_err(&pdev->dev, "failed to enable regulator\n");
+ return r;
+ }
+
+ ddata->resb_gpio = sharp_ls_get_gpio_of(&pdev->dev, 0, 0, "reset"); /* lcd RESB */
+ ddata->mo_gpio = sharp_ls_get_gpio_of(&pdev->dev, 0, 0, "enable"); /* lcd MO */
+ ddata->lr_gpio = sharp_ls_get_gpio_of(&pdev->dev, 1, 1, "enable"); /* lcd LR */
+ ddata->ud_gpio = sharp_ls_get_gpio_of(&pdev->dev, 2, 1, "enable"); /* lcd UD */
+ ddata->ini_gpio = sharp_ls_get_gpio_of(&pdev->dev, 3, 0, "enable"); /* lcd INI */
+
+ r = of_get_display_timing(node, "panel-timing", &timing);
+ if (r) {
+ dev_err(&pdev->dev, "failed to get video timing\n");
+ return r;
+ }
+
+ videomode_from_timing(&timing, &vm);
+ videomode_to_omap_video_timings(&vm, &ddata->videomode);
+
+ 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;
}
@@ -249,12 +315,14 @@ 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;
}
- ddata->videomode = sharp_ls_timings;
-
dssdev = &ddata->dssdev;
dssdev->dev = &pdev->dev;
dssdev->driver = &sharp_ls_ops;
@@ -292,12 +360,20 @@ static int __exit sharp_ls_remove(struct platform_device *pdev)
return 0;
}
+static const struct of_device_id sharp_ls_of_match[] = {
+ { .compatible = "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",
.owner = THIS_MODULE,
+ .of_match_table = sharp_ls_of_match,
},
};
--
1.8.1.1
^ permalink raw reply related
* [PATCH 4/4] ARM: dts: Add LCD panel sharp ls037v7dw01 support for omap3-evm and ldp
From: Tony Lindgren @ 2014-04-29 23:52 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1398815562-24113-1-git-send-email-tony@atomide.com>
Looks like quite a few omaps 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 panel for ldp is configured
in the qvga mode and omap3-evm panel in vga mode.
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 <tony@atomide.com>
---
.../arm/boot/dts/omap-panel-sharp-ls037v7dw01.dtsi | 82 ++++++++++++++++++++++
arch/arm/boot/dts/omap3-evm-37xx.dts | 50 +++++++++++++
arch/arm/boot/dts/omap3-evm-common.dtsi | 47 +++++++++++++
arch/arm/boot/dts/omap3-ldp.dts | 31 ++++++--
4 files changed, 205 insertions(+), 5 deletions(-)
create mode 100644 arch/arm/boot/dts/omap-panel-sharp-ls037v7dw01.dtsi
diff --git a/arch/arm/boot/dts/omap-panel-sharp-ls037v7dw01.dtsi b/arch/arm/boot/dts/omap-panel-sharp-ls037v7dw01.dtsi
new file mode 100644
index 0000000..f5252da
--- /dev/null
+++ b/arch/arm/boot/dts/omap-panel-sharp-ls037v7dw01.dtsi
@@ -0,0 +1,82 @@
+/*
+ * Common file for omap dpi panels with QVGA and reset pins
+ *
+ * Note that the board specifc DTS file needs to specify
+ * at minimum the GPIO enable-gpios for display, and
+ * gpios for gpio-backlight.
+ */
+
+/ {
+ aliases {
+ display0 = &lcd0;
+ };
+
+ backlight0: backlight {
+ compatible = "gpio-backlight";
+ };
+
+ /* 3.3V GPIO controlled regulator for LCD_ENVDD */
+ lcd_3v3: regulator-lcd-3v3 {
+ compatible = "regulator-fixed";
+ regulator-name = "lcd_3v3";
+ regulator-min-microvolt = <3300000>;
+ regulator-max-microvolt = <3300000>;
+ startup-delay-us = <70000>;
+ regulator-always-on;
+ };
+
+ lcd0: display {
+ compatible = "sharp,ls037v7dw01";
+ label = "lcd";
+ power-supply = <&lcd_3v3>;
+ panel-timing {
+ clock-frequency = <5400000>;
+ hback-porch = <39>;
+ hactive = <240>;
+ hfront-porch = <3>;
+ hsync-len = <3>;
+ vback-porch = <7>;
+ vactive = <320>;
+ vfront-porch = <2>;
+ vsync-len = <1>;
+ hsync-active = <0>;
+ vsync-active = <0>;
+ de-active = <1>;
+ pixelclk-active = <1>;
+ };
+
+ port {
+ lcd_in: endpoint {
+ remote-endpoint = <&dpi_out>;
+ };
+ };
+ };
+};
+
+&dss {
+ status = "ok";
+ vdds_dsi-supply = <&vpll2>;
+ port {
+ dpi_out: endpoint {
+ remote-endpoint = <&lcd_in>;
+ data-lines = <18>;
+ };
+ };
+};
+
+&mcspi1 {
+ tsc2046@0 {
+ reg = <0>; /* CS0 */
+ compatible = "ti,tsc2046";
+ spi-max-frequency = <1000000>;
+ vcc-supply = <&lcd_3v3>;
+ ti,x-min = /bits/ 16 <0>;
+ ti,x-max = /bits/ 16 <8000>;
+ ti,y-min = /bits/ 16 <0>;
+ ti,y-max = /bits/ 16 <4800>;
+ ti,x-plate-ohms = /bits/ 16 <40>;
+ ti,pressure-max = /bits/ 16 <255>;
+ ti,swap-xy;
+ linux,wakeup;
+ };
+};
diff --git a/arch/arm/boot/dts/omap3-evm-37xx.dts b/arch/arm/boot/dts/omap3-evm-37xx.dts
index 4df68ad..a181e30 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 b/arch/arm/boot/dts/omap3-evm-common.dtsi
index 3007e79..0ab9650 100644
--- a/arch/arm/boot/dts/omap3-evm-common.dtsi
+++ b/arch/arm/boot/dts/omap3-evm-common.dtsi
@@ -44,6 +44,11 @@
#include "twl4030.dtsi"
#include "twl4030_omap3.dtsi"
+#include "omap-panel-sharp-ls037v7dw01.dtsi"
+
+&backlight0 {
+ gpios = <&twl_gpio 18 GPIO_ACTIVE_HIGH>;
+};
&i2c2 {
clock-frequency = <400000>;
@@ -61,6 +66,48 @@
};
};
+&lcd_3v3 {
+ gpio = <&gpio5 25 GPIO_ACTIVE_LOW>; /* gpio153 */
+ enable-active-low;
+};
+
+&lcd0 {
+ reset-gpios = <&gpio5 27 GPIO_ACTIVE_HIGH>; /* gpio155, lcd RESB */
+ /*
+ * The LCD is sideways, so we want the VGA mode instead of
+ * QVGA mode. Probably also want to have omapfb.rotate=3
+ * in the kernel cmdline until there's a binding for that.
+ */
+ enable-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 */
+ &gpio5 24 GPIO_ACTIVE_HIGH>; /* gpio152, lcd INI */
+
+ panel-timing {
+ clock-frequency = <19200000>;
+ hback-porch = <28>;
+ hactive = <480>;
+ hfront-porch = <1>;
+ hsync-len = <2>;
+ vback-porch = <1>;
+ vactive = <640>;
+ vfront-porch = <1>;
+ vsync-len = <1>;
+ hsync-active = <0>;
+ vsync-active = <0>;
+ de-active = <1>;
+ pixelclk-active = <1>;
+ };
+};
+
+&mcspi1 {
+ tsc2046@0 {
+ interrupt-parent = <&gpio6>;
+ interrupts = <15 0>; /* gpio175 */
+ pendown-gpio = <&gpio6 15 0>;
+ };
+};
+
&mmc1 {
vmmc-supply = <&vmmc1>;
vmmc_aux-supply = <&vsim>;
diff --git a/arch/arm/boot/dts/omap3-ldp.dts b/arch/arm/boot/dts/omap3-ldp.dts
index 0abe986..50fdac9 100644
--- a/arch/arm/boot/dts/omap3-ldp.dts
+++ b/arch/arm/boot/dts/omap3-ldp.dts
@@ -164,6 +164,7 @@
#include "twl4030.dtsi"
#include "twl4030_omap3.dtsi"
+#include "omap-panel-sharp-ls037v7dw01.dtsi"
&i2c2 {
clock-frequency = <400000>;
@@ -173,6 +174,31 @@
clock-frequency = <400000>;
};
+&lcd_3v3 {
+ gpio = <&twl_gpio 7 GPIO_ACTIVE_HIGH>;
+ enable-active-high;
+};
+
+&lcd0 {
+ reset-gpios = <&gpio2 23 GPIO_ACTIVE_HIGH>; /* gpio55, lcd RESB */
+ gpios = <&gpio2 24 GPIO_ACTIVE_LOW /* gpio56, lcd MO */
+ 0 /* lcd LR */
+ 0 /* lcd UD */
+ 0>; /* lcd INI */
+};
+
+&backlight0 {
+ gpios = <&twl_gpio 15 GPIO_ACTIVE_LOW>;
+};
+
+&mcspi1 {
+ tsc2046@0 {
+ interrupt-parent = <&gpio2>;
+ interrupts = <22 0>; /* gpio54 */
+ pendown-gpio = <&gpio2 22 0>;
+ };
+};
+
&mmc1 {
/* See 35xx errata 2.1.1.128 in SPRZ278F */
compatible = "ti,omap3-pre-es3-hsmmc";
@@ -247,8 +273,3 @@
/* Needed for ads7846 */
regulator-name = "vcc";
};
-
-&vpll2 {
- /* Needed for DSS */
- regulator-name = "vdds_dsi";
-};
--
1.8.1.1
^ permalink raw reply related
* Re: [PATCH 4/4] ARM: dts: Add LCD panel sharp ls037v7dw01 support for omap3-evm and ldp
From: Joachim Eastwood @ 2014-04-30 1:07 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1398815562-24113-5-git-send-email-tony@atomide.com>
On 30 April 2014 01:52, Tony Lindgren <tony@atomide.com> wrote:
> Looks like quite a few omaps 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 panel for ldp is configured
> in the qvga mode and omap3-evm panel in vga mode.
>
> 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 <tony@atomide.com>
> ---
> .../arm/boot/dts/omap-panel-sharp-ls037v7dw01.dtsi | 82 ++++++++++++++++++++++
> arch/arm/boot/dts/omap3-evm-37xx.dts | 50 +++++++++++++
> arch/arm/boot/dts/omap3-evm-common.dtsi | 47 +++++++++++++
> arch/arm/boot/dts/omap3-ldp.dts | 31 ++++++--
> 4 files changed, 205 insertions(+), 5 deletions(-)
> create mode 100644 arch/arm/boot/dts/omap-panel-sharp-ls037v7dw01.dtsi
> diff --git a/arch/arm/boot/dts/omap3-ldp.dts b/arch/arm/boot/dts/omap3-ldp.dts
> index 0abe986..50fdac9 100644
> --- a/arch/arm/boot/dts/omap3-ldp.dts
> +++ b/arch/arm/boot/dts/omap3-ldp.dts
> @@ -164,6 +164,7 @@
>
> #include "twl4030.dtsi"
> #include "twl4030_omap3.dtsi"
> +#include "omap-panel-sharp-ls037v7dw01.dtsi"
>
> &i2c2 {
> clock-frequency = <400000>;
> @@ -173,6 +174,31 @@
> clock-frequency = <400000>;
> };
>
> +&lcd_3v3 {
> + gpio = <&twl_gpio 7 GPIO_ACTIVE_HIGH>;
> + enable-active-high;
> +};
> +
> +&lcd0 {
> + reset-gpios = <&gpio2 23 GPIO_ACTIVE_HIGH>; /* gpio55, lcd RESB */
> + gpios = <&gpio2 24 GPIO_ACTIVE_LOW /* gpio56, lcd MO */
enable-gpios ?
> + 0 /* lcd LR */
> + 0 /* lcd UD */
> + 0>; /* lcd INI */
> +};
regards
Joachim Eastwood
^ permalink raw reply
* Re: [PATCH 06/23] ARM: OMAP: add OMAP5 DSI muxing
From: Tomi Valkeinen @ 2014-04-30 6:13 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140429173838.GB27571@atomide.com>
[-- Attachment #1: Type: text/plain, Size: 2979 bytes --]
On 29/04/14 20:38, Tony Lindgren wrote:
> * Tomi Valkeinen <tomi.valkeinen@ti.com> [140429 09:33]:
>> On 29/04/14 19:19, Tomi Valkeinen wrote:
>>> On 29/04/14 18:05, Tony Lindgren wrote:
>>>
>>>>> omap4_padconf_global is a syscon node, not pinctrl. As syscon just gives
>>>>> a raw regmap to its memory area, the driver needs to know about the OMAP
>>>>> control registers to use it.
>>>>
>>>> That would be probably best set up the same way we have already set up
>>>> for example omap4_padconf_global: tisyscon@4a1005a0. Then drivers can
>>>> access it using regmap, see how drivers/regulator/pbias-regulator.c
>>>> sets up the pbias regulator with regmap for MMC.
>>>
>>> Right, but it means that the driver will contain platform specific code
>>> for all the omap revisions it supports. Isn't that wrong?
>>>
>>> I already have a patch for DSI that uses the syscon-method, and it works
>>> fine. But it's quite ugly, imo, to fiddle with the OMAP control
>>> registers in a driver.
>
> Anything using the system control module registers should be a separate
> driver. And it should ideally be implemeting some Linux generic framework
> that the consumer driver can then use. That leaves out the need to export
> custom functions.
Ok.
> I guess we don't have a PHY framework for displays though, so how about
> just a separate minimal driver under drivers/video/omap2 that uses the
> syscon?
Well, this one is not really about DSI PHY. The CONTROL_DSIPHY register
is not in the DSI PHY block, but in the control module, and it is used
to enable/disable the pins (for omap4/5) and to set pull up/down for the
pins (only for omap4). Oddly, for omap5, there's also a normal padconfig
register for the DSI pins, but not so for omap4.
To me it looks like a pad config register. I don't know why there's a
separate odd register for it and it's not using the normal padconfig system.
I'd like to use the pinctrl framework for it, but the pinctrl-single
cannot handle such a funny register. So, if "Anything using the system
control module registers should be a separate driver", then I guess I
need to write a pinctrl driver for this single register?
>> Oh, also, if I do that, I need to know both the SoC version and the DSS
>> version in the driver.
>
> Don't you get all you need in the compatible string? Something like
> compatible ti,dss-phy-omap5?
We do use different compatible strings for different major versions of
the DSS blocks, like ti,omap5-dsi. But that exactly same DSS block could
be used on some other SoC, with different control stuff.
We could use separate compatible string for each SoC that uses DSS, but
then we're really encoding the SoC version into the compatible string,
not DSS version.
Of course, if there will be a separate driver managing the
CONTROL_DSIPHY register, then that one should use compatible string
specific to the SoC, as it's not a DSS driver at all.
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* Re: [PATCH 1/2] video: fbdev: Fix format string mismatch in wm8505fb.c
From: Tomi Valkeinen @ 2014-04-30 8:26 UTC (permalink / raw)
To: Masanari Iida, plagnioj, linux-fbdev, linux-kernel
In-Reply-To: <1398774115-15353-1-git-send-email-standby24x7@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 862 bytes --]
On 29/04/14 15:21, Masanari Iida wrote:
> Fix format string mismatch in contrast_show().
>
> Signed-off-by: Masanari Iida <standby24x7@gmail.com>
> ---
> drivers/video/fbdev/wm8505fb.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/video/fbdev/wm8505fb.c b/drivers/video/fbdev/wm8505fb.c
> index 537d199..d2fafbb 100644
> --- a/drivers/video/fbdev/wm8505fb.c
> +++ b/drivers/video/fbdev/wm8505fb.c
> @@ -162,7 +162,7 @@ static ssize_t contrast_show(struct device *dev,
> struct fb_info *info = dev_get_drvdata(dev);
> struct wm8505fb_info *fbi = to_wm8505fb_info(info);
>
> - return sprintf(buf, "%d\n", fbi->contrast);
> + return sprintf(buf, "%u\n", fbi->contrast);
> }
>
> static ssize_t contrast_store(struct device *dev,
>
Thanks, queued this and the 2/2 patch for 3.16.
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* Re: [PATCH 1/2] video: mmp: Remove references to CPU_MMP3
From: Tomi Valkeinen @ 2014-04-30 8:37 UTC (permalink / raw)
To: Paul Bolle, Jean-Christophe Plagniol-Villard
Cc: Richard Weinberger, linux-fbdev, linux-kernel
In-Reply-To: <1397561044.1985.47.camel@x220>
[-- Attachment #1: Type: text/plain, Size: 434 bytes --]
On 15/04/14 14:24, Paul Bolle wrote:
> From: Richard Weinberger <richard@nod.at>
>
> References to the Kconfig symbol CPU_MMP3 were added to the tree since
> v3.6. But that Kconfig symbol has never been part of the tree. So get
> rid of these references.
>
> Signed-off-by: Richard Weinberger <richard@nod.at>
> Signed-off-by: Paul Bolle <pebolle@tiscali.nl>
Thanks, queued this and the 2/2 patch for 3.16.
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* Re: [PATCH] fbdev: omap2: Fix format string mismatch in display-sysfs.c
From: Tomi Valkeinen @ 2014-04-30 8:43 UTC (permalink / raw)
To: Jingoo Han, 'Masanari Iida'
Cc: 'Jean-Christophe Plagniol-Villard', linux-fbdev,
linux-omap
In-Reply-To: <002401cf62d3$634cc1f0$29e645d0$%han@samsung.com>
[-- Attachment #1: Type: text/plain, Size: 2094 bytes --]
On 28/04/14 14:17, Jingoo Han wrote:
> On Monday, April 28, 2014 7:54 PM, Masanari Iida wrote:
>>
>> Fix two format string mismatch in display-sysfs.c
>>
>> Signed-off-by: Masanari Iida <standby24x7@gmail.com>
>> ---
>> drivers/video/fbdev/omap2/dss/display-sysfs.c | 4 ++--
>> 1 file changed, 2 insertions(+), 2 deletions(-)
>>
>> diff --git a/drivers/video/fbdev/omap2/dss/display-sysfs.c b/drivers/video/fbdev/omap2/dss/display-
>> sysfs.c
>> index 5a2095a..5928bc9 100644
>> --- a/drivers/video/fbdev/omap2/dss/display-sysfs.c
>> +++ b/drivers/video/fbdev/omap2/dss/display-sysfs.c
>> @@ -184,7 +184,7 @@ static ssize_t display_rotate_show(struct device *dev,
>> if (!dssdev->driver->get_rotate)
>> return -ENOENT;
>> rotate = dssdev->driver->get_rotate(dssdev);
>
> According to 'struct omap_dss_driver', get_rotate() returns 'u8'.
> Then, how about changing the type of 'rotate' variable from 'int'
> to 'u8' as below?
>
> --- a/drivers/video/fbdev/omap2/dss/display-sysfs.c
> +++ b/drivers/video/fbdev/omap2/dss/display-sysfs.c
> @@ -180,7 +180,7 @@ static ssize_t display_rotate_show(struct device *dev,
> struct device_attribute *attr, char *buf)
> {
> struct omap_dss_device *dssdev = to_dss_device_sysfs(dev);
> - int rotate;
> + u8 rotate;
> if (!dssdev->driver->get_rotate)
> return -ENOENT;
> rotate = dssdev->driver->get_rotate(dssdev);
>
>
> Best regards,
> Jingoo Han
>
>> - return snprintf(buf, PAGE_SIZE, "%u\n", rotate);
>> + return snprintf(buf, PAGE_SIZE, "%d\n", rotate);
>> }
>>
>> static ssize_t display_rotate_store(struct device *dev,
>> @@ -215,7 +215,7 @@ static ssize_t display_mirror_show(struct device *dev,
>> if (!dssdev->driver->get_mirror)
>> return -ENOENT;
>> mirror = dssdev->driver->get_mirror(dssdev);
>> - return snprintf(buf, PAGE_SIZE, "%u\n", mirror);
>> + return snprintf(buf, PAGE_SIZE, "%d\n", mirror);
>> }
And get_mirror returns a bool, not int, so I guess that could be fixed also.
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* Re: [patch] video: mmpfb: cleanup some static checker warnings in probe()
From: Tomi Valkeinen @ 2014-04-30 10:58 UTC (permalink / raw)
To: linux-fbdev
In-Reply-To: <20140414080929.GB13372@mwanda>
[-- Attachment #1: Type: text/plain, Size: 515 bytes --]
On 14/04/14 11:09, Dan Carpenter wrote:
> Sparse complains about using zero instead of NULL for pointers.
> Probably, if we enabled the warning, then GCC would complain about the
> unused initializers. I've just removed them.
>
> Smatch complains that we first check if "fbi" is NULL and then
> dereference it in the error handling. It turns out that "fbi" can't be
> NULL so I've removed the check.
>
> Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Thanks, queued for 3.16.
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* Re: [PATCH V2] video: pxa3xx-gcu: use devm_ioremap_resource()
From: Tomi Valkeinen @ 2014-04-30 11:02 UTC (permalink / raw)
To: linux-fbdev
In-Reply-To: <008201cf52e6$7314ea60$593ebf20$%han@samsung.com>
[-- Attachment #1: Type: text/plain, Size: 475 bytes --]
On 08/04/14 07:53, Jingoo Han wrote:
> Use devm_ioremap_resource() because devm_request_and_ioremap() is
> obsoleted by devm_ioremap_resource().
>
> Signed-off-by: Jingoo Han <jg1.han@samsung.com>
> Cc: Daniel Mack <zonque@gmail.com>
> Cc: Dan Carpenter <dan.carpenter@oracle.com>
> ---
> Changes since v1:
> - remove unnecessary error message, because devm_ioremap_resource()
> already prints one in all failure cases.
Thanks, queued for 3.16.
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* Re: [PATCH v2] fbdev: Fix tmiofb driver dependencies
From: Tomi Valkeinen @ 2014-04-30 11:05 UTC (permalink / raw)
To: linux-fbdev
In-Reply-To: <20140424103258.4083cb69@endymion.delvare>
[-- Attachment #1: Type: text/plain, Size: 1155 bytes --]
On 24/04/14 11:32, Jean Delvare wrote:
> The tmiofb driver should not depend on MFD_CORE but on MFD_TMIO.
> Without the tmio_core driver, tmiofb has no platform device to bind
> to and is thus useless.
>
> Signed-off-by: Jean Delvare <jdelvare@suse.de>
> Cc: Jean-Christophe Plagniol-Villard <plagnioj@jcrosoft.com>
> Cc: Tomi Valkeinen <tomi.valkeinen@ti.com>
> ---
> I suspect that MFD_TMIO was originally intended and MFD_CORE was a
> typo.
>
> Changes since v1:
> * Added COMPILE_TEST as suggested by Geert Uytterhoeven.
>
> drivers/video/fbdev/Kconfig | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> --- linux-3.15-rc2.orig/drivers/video/fbdev/Kconfig 2014-04-23 11:51:17.163933232 +0200
> +++ linux-3.15-rc2/drivers/video/fbdev/Kconfig 2014-04-24 09:49:07.433062918 +0200
> @@ -1993,7 +1993,7 @@ config FB_SH_MOBILE_HDMI
>
> config FB_TMIO
> tristate "Toshiba Mobile IO FrameBuffer support"
> - depends on FB && MFD_CORE
> + depends on FB && (MFD_TMIO || COMPILE_TEST)
> select FB_CFB_FILLRECT
> select FB_CFB_COPYAREA
> select FB_CFB_IMAGEBLIT
Thanks, queued for 3.16.
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* Re: [PATCH v2 1/3] video: clps711x: Add new Cirrus Logic CLPS711X framebuffer driver
From: Tomi Valkeinen @ 2014-04-30 11:14 UTC (permalink / raw)
To: linux-fbdev
In-Reply-To: <1397285583-15187-1-git-send-email-shc_work@mail.ru>
[-- Attachment #1: Type: text/plain, Size: 1369 bytes --]
On 24/04/14 19:35, Alexander Shiyan wrote:
>> The right way to do it is, as I wrote above, by gradually changing the
>> old driver with a patch series. And my question is, why not do it that
>> way? Then it would be possible to review the patches one by one, seeing
>> what has changed.
>
> "gradually changing"...
> I repeat that this is not an old modified driver, but written new.
Yes, I understand that. Again, my question is, why didn't you modify the
old driver? That's how things should normally be done. Instead, you made
a totally new one, making proper review against the old driver impossible.
> if you imagine a new file as a diff to the old, this can be clearly seen.
>
> There is no reason to waste time on a series of changes since I
> can not even check these changes on real hardware, but only in the
> last stage when the driver will be the current version.
Hmm what? So is the old driver totally broken, and cannot be used at the
moment? Or why you can't test on real hardware?
Note that I don't know anything about the fb hardware in question, nor
the driver. Maybe there's a valid reason to write a new driver from
scratch. But there very rarely is.
And "because I already wrote a new driver, and it's a waste of time for
me to throw away my work and patch the old one", is not a very good reason.
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* Re: [PATCH v2 1/3] video: clps711x: Add new C =?UTF-8?B?aXJydXMgTG9naWMgQ
From: Alexander Shiyan @ 2014-04-30 12:36 UTC (permalink / raw)
To: linux-fbdev
In-Reply-To: <1398327006.501536964@f133.i.mail.ru>
V2VkLCAzMCBBcHIgMjAxNCAxNDoxNDozNiArMDMwMCDQvtGCIFRvbWkgVmFsa2VpbmVuIDx0b21p
LnZhbGtlaW5lbkB0aS5jb20+Ogo+IE9uIDI0LzA0LzE0IDE5OjM1LCBBbGV4YW5kZXIgU2hpeWFu
IHdyb3RlOgoKSGVsbG8uCgpJJ20gYSByZW9yZGVyIHF1b3RlcyBhIGJpdCBmb3IgY29udmVuaWVu
Y2UuCgo+ID4+IFRoZSByaWdodCB3YXkgdG8gZG8gaXQgaXMsIGFzIEkgd3JvdGUgYWJvdmUsIGJ5
IGdyYWR1YWxseSBjaGFuZ2luZyB0aGUKPiA+PiBvbGQgZHJpdmVyIHdpdGggYSBwYXRjaCBzZXJp
ZXMuIEFuZCBteSBxdWVzdGlvbiBpcywgd2h5IG5vdCBkbyBpdCB0aGF0Cj4gPj4gd2F5PyBUaGVu
IGl0IHdvdWxkIGJlIHBvc3NpYmxlIHRvIHJldmlldyB0aGUgcGF0Y2hlcyBvbmUgYnkgb25lLCBz
ZWVpbmcKPiA+PiB3aGF0IGhhcyBjaGFuZ2VkLgo+ID4gCj4gPiAiZ3JhZHVhbGx5IGNoYW5naW5n
Ii4uLgo+ID4gSSByZXBlYXQgdGhhdCB0aGlzIGlzIG5vdCBhbiBvbGQgbW9kaWZpZWQgZHJpdmVy
LCBidXQgd3JpdHRlbiBuZXcuCj4gCj4gWWVzLCBJIHVuZGVyc3RhbmQgdGhhdC4gQWdhaW4sIG15
IHF1ZXN0aW9uIGlzLCB3aHkgZGlkbid0IHlvdSBtb2RpZnkgdGhlCj4gb2xkIGRyaXZlcj8gVGhh
dCdzIGhvdyB0aGluZ3Mgc2hvdWxkIG5vcm1hbGx5IGJlIGRvbmUuIEluc3RlYWQsIHlvdSBtYWRl
Cj4gYSB0b3RhbGx5IG5ldyBvbmUsIG1ha2luZyBwcm9wZXIgcmV2aWV3IGFnYWluc3QgdGhlIG9s
ZCBkcml2ZXIgaW1wb3NzaWJsZS4KLi4uCj4gSG1tIHdoYXQ/IFNvIGlzIHRoZSBvbGQgZHJpdmVy
IHRvdGFsbHkgYnJva2VuLCBhbmQgY2Fubm90IGJlIHVzZWQgYXQgdGhlCj4gbW9tZW50PyBPciB3
aHkgeW91IGNhbid0IHRlc3Qgb24gcmVhbCBoYXJkd2FyZT8KCkZpcnN0bHksIHRoZSBkcml2ZXIg
dXNlcyBhIGZpeGVkIHZhbHVlcyBmb3IgeHJlcywgeXJlcywgcGl4Y2xvY2sgYW5kIHNwZWNpZmlj
CnZhcmlhYmxlIGFjX3ByZWNhbGUuClNlY29uZGx5LCB0aGUgZHJpdmVyIHVzZXMgYSBmaXhlZCB2
YWx1ZSBmb3IgdGhlIHBoeXNpY2FsIGFkZHJlc3Mgb2YgdGhlIGJ1ZmZlci4KVG90YWxseSwgaXQg
ZG9lcyBub3QgZ2l2ZSBtZSB0aGUgYWJpbGl0eSB0byB1c2UgdGhlIGRyaXZlciBpbiB0aGUgY3Vy
cmVudCBzdGF0ZS4KVW5saWtlbHkgdGhhdCB0aGlzIHdpbGwgbG9vayBnb29kIGlmIEkgbWFrZSB0
aGVzZSB0d28gc2lnbmlmaWNhbnQgY2hhbmdlcyBpbgphIHNpbmdsZSBwYXRjaC4uLgoKQXQgdGhp
cyB0aW1lIHRoZSBkcml2ZXIgaGFzIHRocmVlIHVzZXIuCk9ubHkgb25lIG9mIHRoZW0gc2hvdWxk
IHRoZW9yZXRpY2FsbHkgd29yay4KY2xwczcxMXgtYXV0Y3B1MTIgc2hvdWxkIG5vdCB3b3JrIGlu
IHRoZSBhYnNlbmNlIG9mIG1lbWJsb2NrX3Jlc2VydmUoKS4KY2xwczcxMXgtcDcyMHQgc2hvdWxk
IG5vdCB3b3JrIGR1ZSB0byBwaHlzaWNhbCBhZGRyZXNzIGxpbWl0YXRpb24gYXMgaQpub3RpY2Vk
IGJlZm9yZS4gQm9hcmQgbWVhbnMgdG8gdXNlIFNSQU0gaW5zdGVhZCBvZiBTRFJBTS4KT25seSBj
bHBzNzExeC1lZGI3MjExIHNob3VsZCB3b3JrIGZpbmUgKGluIHRoZW9yeSkuCklzIHRoaXMgYSBn
b29kIHJlYXNvbiB0byByZXBsYWNlIHRoZSBkcml2ZXI/IEkgdGhpbmsgeWVzLgoKPiBOb3RlIHRo
YXQgSSBkb24ndCBrbm93IGFueXRoaW5nIGFib3V0IHRoZSBmYiBoYXJkd2FyZSBpbiBxdWVzdGlv
biwgbm9yCj4gdGhlIGRyaXZlci4gTWF5YmUgdGhlcmUncyBhIHZhbGlkIHJlYXNvbiB0byB3cml0
ZSBhIG5ldyBkcml2ZXIgZnJvbQo+IHNjcmF0Y2guIEJ1dCB0aGVyZSB2ZXJ5IHJhcmVseSBpcy4K
PiAKPiBBbmQgImJlY2F1c2UgSSBhbHJlYWR5IHdyb3RlIGEgbmV3IGRyaXZlciwgYW5kIGl0J3Mg
YSB3YXN0ZSBvZiB0aW1lIGZvcgo+IG1lIHRvIHRocm93IGF3YXkgbXkgd29yayBhbmQgcGF0Y2gg
dGhlIG9sZCBvbmUiLCBpcyBub3QgYSB2ZXJ5IGdvb2QgcmVhc29uLgoKPiA+IGlmIHlvdSBpbWFn
aW5lIGEgbmV3IGZpbGUgYXMgYSBkaWZmIHRvIHRoZSBvbGQsIHRoaXMgY2FuIGJlIGNsZWFybHkg
c2Vlbi4KPiA+IAo+ID4gVGhlcmUgaXMgbm8gcmVhc29uIHRvIHdhc3RlIHRpbWUgb24gYSBzZXJp
ZXMgb2YgY2hhbmdlcyBzaW5jZSBJCj4gPiBjYW4gbm90IGV2ZW4gY2hlY2sgdGhlc2UgY2hhbmdl
cyBvbiByZWFsIGhhcmR3YXJlLCBidXQgb25seSBpbiB0aGUKPiA+IGxhc3Qgc3RhZ2Ugd2hlbiB0
aGUgZHJpdmVyIHdpbGwgYmUgdGhlIGN1cnJlbnQgdmVyc2lvbi4KClN1bW1pbmcgdXAsIEkgd2Fu
dCB0byBhc2sgd2h5IHRoZSBkcml2ZXIgY2FuIG5vdCBiZSByZXZpZXdlZCBhcyBhCm5ldyBhbmQg
bm90IGNvbXBhcmVkIHRvIHRoZSBvbGQ/CkFuZCB5ZXMsIHRoZSB0aW1lIGNhbiBiZSBzcGVudCBv
biBtb3JlIHByb2R1Y3RpdmUgdGhpbmdzIHRvIGRvIHRoYW4KdG8gY3JlYXRlIGEgc2VyaWVzLCBs
ZWFkaW5nIGV2ZW50dWFsbHkgdG8gdGhlIHNhbWUgcmVzdWx0LgpBcyBmYXIgYXMgSSBrbm93LCBn
dWlkZSB0byBjcmVhdGluZyBrZXJuZWwgcGF0Y2hlcyBhbGxvd3Mgc3VjaCBjYXNlcy4KClRoYW5r
cy4KCi0tLQoK
^ permalink raw reply
* Re: [PATCH 4/4] ARM: dts: Add LCD panel sharp ls037v7dw01 support for omap3-evm and ldp
From: Tony Lindgren @ 2014-04-30 17:47 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAGhQ9Vwa8xXQEo5dNEKAvmaS9DoBjVSthtd8=owk+atVdFuiiA@mail.gmail.com>
* Joachim Eastwood <manabian@gmail.com> [140429 18:08]:
> On 30 April 2014 01:52, Tony Lindgren <tony@atomide.com> wrote:
> > Looks like quite a few omaps 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 panel for ldp is configured
> > in the qvga mode and omap3-evm panel in vga mode.
> >
> > 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 <tony@atomide.com>
> > ---
> > .../arm/boot/dts/omap-panel-sharp-ls037v7dw01.dtsi | 82 ++++++++++++++++++++++
> > arch/arm/boot/dts/omap3-evm-37xx.dts | 50 +++++++++++++
> > arch/arm/boot/dts/omap3-evm-common.dtsi | 47 +++++++++++++
> > arch/arm/boot/dts/omap3-ldp.dts | 31 ++++++--
> > 4 files changed, 205 insertions(+), 5 deletions(-)
> > create mode 100644 arch/arm/boot/dts/omap-panel-sharp-ls037v7dw01.dtsi
>
> > diff --git a/arch/arm/boot/dts/omap3-ldp.dts b/arch/arm/boot/dts/omap3-ldp.dts
> > index 0abe986..50fdac9 100644
> > --- a/arch/arm/boot/dts/omap3-ldp.dts
> > +++ b/arch/arm/boot/dts/omap3-ldp.dts
> > @@ -164,6 +164,7 @@
> >
> > #include "twl4030.dtsi"
> > #include "twl4030_omap3.dtsi"
> > +#include "omap-panel-sharp-ls037v7dw01.dtsi"
> >
> > &i2c2 {
> > clock-frequency = <400000>;
> > @@ -173,6 +174,31 @@
> > clock-frequency = <400000>;
> > };
> >
> > +&lcd_3v3 {
> > + gpio = <&twl_gpio 7 GPIO_ACTIVE_HIGH>;
> > + enable-active-high;
> > +};
> > +
> > +&lcd0 {
> > + reset-gpios = <&gpio2 23 GPIO_ACTIVE_HIGH>; /* gpio55, lcd RESB */
> > + gpios = <&gpio2 24 GPIO_ACTIVE_LOW /* gpio56, lcd MO */
>
> enable-gpios ?
Oops yes, changed from gpios to enable-gpios while reading the panel
binding doc, probably forgot to commit the change, will update.
Tony
^ permalink raw reply
* Re: [PATCH 06/23] ARM: OMAP: add OMAP5 DSI muxing
From: Tony Lindgren @ 2014-04-30 17:56 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <5360948A.5020607@ti.com>
* Tomi Valkeinen <tomi.valkeinen@ti.com> [140429 23:14]:
> On 29/04/14 20:38, Tony Lindgren wrote:
> > * Tomi Valkeinen <tomi.valkeinen@ti.com> [140429 09:33]:
> >> On 29/04/14 19:19, Tomi Valkeinen wrote:
> >>> On 29/04/14 18:05, Tony Lindgren wrote:
> >>>
> >>>>> omap4_padconf_global is a syscon node, not pinctrl. As syscon just gives
> >>>>> a raw regmap to its memory area, the driver needs to know about the OMAP
> >>>>> control registers to use it.
> >>>>
> >>>> That would be probably best set up the same way we have already set up
> >>>> for example omap4_padconf_global: tisyscon@4a1005a0. Then drivers can
> >>>> access it using regmap, see how drivers/regulator/pbias-regulator.c
> >>>> sets up the pbias regulator with regmap for MMC.
> >>>
> >>> Right, but it means that the driver will contain platform specific code
> >>> for all the omap revisions it supports. Isn't that wrong?
> >>>
> >>> I already have a patch for DSI that uses the syscon-method, and it works
> >>> fine. But it's quite ugly, imo, to fiddle with the OMAP control
> >>> registers in a driver.
> >
> > Anything using the system control module registers should be a separate
> > driver. And it should ideally be implemeting some Linux generic framework
> > that the consumer driver can then use. That leaves out the need to export
> > custom functions.
>
> Ok.
>
> > I guess we don't have a PHY framework for displays though, so how about
> > just a separate minimal driver under drivers/video/omap2 that uses the
> > syscon?
>
> Well, this one is not really about DSI PHY. The CONTROL_DSIPHY register
> is not in the DSI PHY block, but in the control module, and it is used
> to enable/disable the pins (for omap4/5) and to set pull up/down for the
> pins (only for omap4). Oddly, for omap5, there's also a normal padconfig
> register for the DSI pins, but not so for omap4.
>
> To me it looks like a pad config register. I don't know why there's a
> separate odd register for it and it's not using the normal padconfig system.
>
> I'd like to use the pinctrl framework for it, but the pinctrl-single
> cannot handle such a funny register. So, if "Anything using the system
> control module registers should be a separate driver", then I guess I
> need to write a pinctrl driver for this single register?
Have you checked out pinctrl-single,bits binding? That should allow
you to map random bits in a single register to a pinctrl driver
instance.
> >> Oh, also, if I do that, I need to know both the SoC version and the DSS
> >> version in the driver.
> >
> > Don't you get all you need in the compatible string? Something like
> > compatible ti,dss-phy-omap5?
>
> We do use different compatible strings for different major versions of
> the DSS blocks, like ti,omap5-dsi. But that exactly same DSS block could
> be used on some other SoC, with different control stuff.
>
> We could use separate compatible string for each SoC that uses DSS, but
> then we're really encoding the SoC version into the compatible string,
> not DSS version.
>
> Of course, if there will be a separate driver managing the
> CONTROL_DSIPHY register, then that one should use compatible string
> specific to the SoC, as it's not a DSS driver at all.
Yeah probably using pinctrl-single,bits, or a separate driver with syscon
makes most sense here.
Regards,
Tony
^ permalink raw reply
* [PATCH] fbdev/fb.h: silence warning with -Wsign-compare
From: Brian W Hart @ 2014-05-01 19:32 UTC (permalink / raw)
To: plagnioj, tomi.valkeinen, linux-fbdev, linux-kernel, trivial
Silence the warning when building with -Wsign-compare when fb.h is
included:
include/linux/fb.h: In function ‘__fb_pad_aligned_buffer’:
include/linux/fb.h:650:17: warning: comparison between signed and unsigned integer expressions [-Wsign-compare]
for (j = 0; j < s_pitch; j++)
^
Signed-off-by: Brian W Hart <hartb@linux.vnet.ibm.com>
---
Compile tested only.
include/linux/fb.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/include/linux/fb.h b/include/linux/fb.h
index fe6ac95..0da7634 100644
--- a/include/linux/fb.h
+++ b/include/linux/fb.h
@@ -641,7 +641,7 @@ static inline void unlock_fb_info(struct fb_info *info)
static inline void __fb_pad_aligned_buffer(u8 *dst, u32 d_pitch,
u8 *src, u32 s_pitch, u32 height)
{
- int i, j;
+ u32 i, j;
d_pitch -= s_pitch;
^ permalink raw reply related
* Re: [PATCH] fbdev/fb.h: silence warning with -Wsign-compare
From: Tomi Valkeinen @ 2014-05-02 12:59 UTC (permalink / raw)
To: Brian W Hart, plagnioj, linux-fbdev, linux-kernel, trivial
In-Reply-To: <20140501193235.GB6495@oc3347516403.ibm.com>
[-- Attachment #1: Type: text/plain, Size: 1002 bytes --]
On 01/05/14 22:32, Brian W Hart wrote:
> Silence the warning when building with -Wsign-compare when fb.h is
> included:
>
> include/linux/fb.h: In function ‘__fb_pad_aligned_buffer’:
> include/linux/fb.h:650:17: warning: comparison between signed and unsigned integer expressions [-Wsign-compare]
> for (j = 0; j < s_pitch; j++)
> ^
>
> Signed-off-by: Brian W Hart <hartb@linux.vnet.ibm.com>
> ---
> Compile tested only.
>
> include/linux/fb.h | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/include/linux/fb.h b/include/linux/fb.h
> index fe6ac95..0da7634 100644
> --- a/include/linux/fb.h
> +++ b/include/linux/fb.h
> @@ -641,7 +641,7 @@ static inline void unlock_fb_info(struct fb_info *info)
> static inline void __fb_pad_aligned_buffer(u8 *dst, u32 d_pitch,
> u8 *src, u32 s_pitch, u32 height)
> {
> - int i, j;
> + u32 i, j;
>
> d_pitch -= s_pitch;
>
>
Thanks, queued for 3.16.
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* Re: [PATCH 06/23] ARM: OMAP: add OMAP5 DSI muxing
From: Tomi Valkeinen @ 2014-05-02 13:06 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140430175651.GB12362@atomide.com>
[-- Attachment #1: Type: text/plain, Size: 1511 bytes --]
On 30/04/14 20:56, Tony Lindgren wrote:
> Have you checked out pinctrl-single,bits binding? That should allow
> you to map random bits in a single register to a pinctrl driver
> instance.
If I recall right, the problem there was that we have one register,
which has bits for two separate devices, and the bits are mixed up. i.e.
not 16 upper bits for one, 16 lower for the other, but 5 bits for one
device, the next 5 bits for the other, then again few bits for the
first, etc.
pinctrl-single,bits didn't like it that.
>>>> Oh, also, if I do that, I need to know both the SoC version and the DSS
>>>> version in the driver.
>>>
>>> Don't you get all you need in the compatible string? Something like
>>> compatible ti,dss-phy-omap5?
>>
>> We do use different compatible strings for different major versions of
>> the DSS blocks, like ti,omap5-dsi. But that exactly same DSS block could
>> be used on some other SoC, with different control stuff.
>>
>> We could use separate compatible string for each SoC that uses DSS, but
>> then we're really encoding the SoC version into the compatible string,
>> not DSS version.
>>
>> Of course, if there will be a separate driver managing the
>> CONTROL_DSIPHY register, then that one should use compatible string
>> specific to the SoC, as it's not a DSS driver at all.
>
> Yeah probably using pinctrl-single,bits, or a separate driver with syscon
> makes most sense here.
Yep, I'll have to come up with something.
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* Re: some divide by zero bugs in >fb_check_var() functions
From: Dan Carpenter @ 2014-05-02 15:15 UTC (permalink / raw)
To: linux-fbdev
In-Reply-To: <20140124223503.GA4251@elgon.mountain>
Anyone want to look through these again? These of divide by
zero bugs in drivers/video/ are a massive pain. Is there no way to
prevent these crashing bugs that doesn't involve adding hundreds of
conditions?
regards,
dan carpenter
On Wed, Jan 29, 2014 at 12:41:37AM +0300, Dan Carpenter wrote:
> On Tue, Jan 28, 2014 at 01:28:06PM -0800, Kees Cook wrote:
> > On Fri, Jan 24, 2014 at 2:35 PM, Dan Carpenter <dan.carpenter@oracle.com> wrote:
> > > My static checker find a number of divide by zero bugs in
> > > ->fb_check_var() functions. The call tree looks like this:
> > >
> > > do_fb_ioctl() <- get var from the user.
> > > -> fb_set_var()
> > > -> info->fbops->fb_check_var(var, info); <- divide by zero bugs
> > >
> > > I wonder if we could add some checking in fb_set_var() to prevent this.
> > >
> > > drivers/video/asiliantfb.c:230 asiliantfb_check_var() error: potential divide by zero bug '/ var->pixclock'.
> > > drivers/video/asiliantfb.c:231 asiliantfb_check_var() error: potential divide by zero bug '/ var->pixclock'.
> > > drivers/video/asiliantfb.c:232 asiliantfb_check_var() error: potential divide by zero bug '/ var->pixclock'.
> > > drivers/video/cirrusfb.c:535 cirrusfb_check_var() error: potential divide by zero bug '/ var->bits_per_pixel'.
> > > drivers/video/cirrusfb.c:581 cirrusfb_check_var() error: potential divide by zero bug '/ var->xres_virtual'.
> > > drivers/video/cyber2000fb.c:843 cyber2000fb_check_var() error: potential divide by zero bug '/ (var->bits_per_pixel * var->xres_virtual)'.
> > > drivers/video/imsttfb.c:843 imsttfb_check_var() error: potential divide by zero bug '/ var->xres_virtual'.
> > > drivers/video/neofb.c:594 neofb_check_var() error: potential divide by zero bug '/ (var->pixclock)'.
> > > drivers/video/neofb.c:702 neofb_check_var() error: potential divide by zero bug '/ (var->xres_virtual * var->bits_per_pixel)'.
> > > drivers/video/pm2fb.c:624 pm2fb_check_var() error: potential divide by zero bug '/ (var->pixclock)'.
> > > drivers/video/pm3fb.c:1007 pm3fb_check_var() error: potential divide by zero bug '/ (var->pixclock)'.
> > > drivers/video/s3fb.c:601 s3fb_check_var() error: potential divide by zero bug '/ (var->pixclock)'.
> > > drivers/video/savage/savagefb_driver.c:952 savagefb_check_var() error: potential divide by zero bug '/ (var->xres_virtual * var->bits_per_pixel)'.
> > > drivers/video/sstfb.c:359 sstfb_check_var() error: potential divide by zero bug '/ (var->pixclock)'.
> > > drivers/video/sstfb.c:361 sstfb_check_var() error: potential divide by zero bug '/ (var->pixclock)'.
> > > drivers/video/tdfxfb.c:518 tdfxfb_check_var() error: potential divide by zero bug '/ (var->pixclock)'.
> > > drivers/video/tdfxfb.c:519 tdfxfb_check_var() error: potential divide by zero bug '/ (var->pixclock)'.
> > > drivers/video/tridentfb.c:918 tridentfb_check_var() error: potential divide by zero bug '/ line_length'.
> > > drivers/video/tridentfb.c:973 tridentfb_check_var() error: potential divide by zero bug '/ (var->pixclock)'.
> >
> > Is it ever valid to have pixclock, xres_virtual, or bits_per_pixel be
> > zero? Seems like it'd be trivial to check for those in fb_set_var()?
> >
>
> It's not so simple as testing for zero, you also have to consider the
> maximum and integer overflows so "var->xres_virtual * var->bits_per_pixel"
> isn't zero.
>
> If I add another call to the call tree then there are more errors again.
>
> regards,
> dan carpenter
>
> drivers/video/savage/savagefb_driver.c:952 savagefb_check_var() error: potential divide by zero bug '/ (var->xres_virtual * var->bits_per_pixel)'.
> drivers/video/savage/savagefb_driver.c:952 savagefb_check_var() error: potential divide by zero bug '/ (var->xres_virtual * var->bits_per_pixel)'.
> drivers/video/fbmon.c:1147 fb_get_hblank_by_hfreq() error: potential divide by zero bug '/ hfreq'.
> drivers/video/fbmon.c:1147 fb_get_hblank_by_hfreq() error: potential divide by zero bug '/ hfreq'.
> drivers/video/fbmon.c:1232 fb_timings_hfreq() error: potential divide by zero bug '/ timings->vtotal'.
> drivers/video/fbmon.c:1232 fb_timings_hfreq() error: potential divide by zero bug '/ timings->vtotal'.
> drivers/video/fbmon.c:1244 fb_timings_dclk() error: potential divide by zero bug '/ timings->htotal'.
> drivers/video/fbmon.c:1244 fb_timings_dclk() error: potential divide by zero bug '/ timings->htotal'.
> drivers/video/fbmon.c:1247 fb_timings_dclk() error: potential divide by zero bug '/ timings->vtotal'.
> drivers/video/fbmon.c:1247 fb_timings_dclk() error: potential divide by zero bug '/ timings->vtotal'.
> drivers/video/fbmon.c:1364 fb_get_mode() error: potential divide by zero bug '/ (timings->dclk / 1000)'.
> drivers/video/fbmon.c:1364 fb_get_mode() error: potential divide by zero bug '/ (timings->dclk / 1000)'.
> drivers/video/fbmon.c:1544 fb_validate_mode() error: potential divide by zero bug '/ htotal'.
> drivers/video/fbmon.c:1544 fb_validate_mode() error: potential divide by zero bug '/ htotal'.
> drivers/video/fbmon.c:1547 fb_validate_mode() error: potential divide by zero bug '/ vtotal'.
> drivers/video/fbmon.c:1547 fb_validate_mode() error: potential divide by zero bug '/ vtotal'.
> drivers/video/via/viafbdev.c:196 get_var_refresh() error: potential divide by zero bug '/ (htotal * vtotal)'.
> drivers/video/via/viafbdev.c:196 get_var_refresh() error: potential divide by zero bug '/ (htotal * vtotal)'.
> drivers/video/via/viafbdev.c:196 get_var_refresh() error: potential divide by zero bug '/ (var->pixclock)'.
> drivers/video/via/viafbdev.c:196 get_var_refresh() error: potential divide by zero bug '/ (var->pixclock)'.
> drivers/video/pm3fb.c:338 pm3fb_init_engine() error: potential divide by zero bug '/ info->fix.line_length'.
> drivers/video/pm3fb.c:338 pm3fb_init_engine() error: potential divide by zero bug '/ info->fix.line_length'.
> drivers/video/pm3fb.c:834 pm3fb_write_mode() error: potential divide by zero bug '/ (info->var.pixclock)'.
> drivers/video/pm3fb.c:834 pm3fb_write_mode() error: potential divide by zero bug '/ (info->var.pixclock)'.
> drivers/video/pm3fb.c:1007 pm3fb_check_var() error: potential divide by zero bug '/ (var->pixclock)'.
> drivers/video/pm3fb.c:1007 pm3fb_check_var() error: potential divide by zero bug '/ (var->pixclock)'.
> drivers/video/tdfxfb.c:518 tdfxfb_check_var() error: potential divide by zero bug '/ (var->pixclock)'.
> drivers/video/tdfxfb.c:518 tdfxfb_check_var() error: potential divide by zero bug '/ (var->pixclock)'.
> drivers/video/tdfxfb.c:519 tdfxfb_check_var() error: potential divide by zero bug '/ (var->pixclock)'.
> drivers/video/tdfxfb.c:519 tdfxfb_check_var() error: potential divide by zero bug '/ (var->pixclock)'.
> drivers/video/tdfxfb.c:583 tdfxfb_set_par() error: potential divide by zero bug '/ (info->var.pixclock)'.
> drivers/video/tdfxfb.c:583 tdfxfb_set_par() error: potential divide by zero bug '/ (info->var.pixclock)'.
> drivers/video/sstfb.c:359 sstfb_check_var() error: potential divide by zero bug '/ (var->pixclock)'.
> drivers/video/sstfb.c:359 sstfb_check_var() error: potential divide by zero bug '/ (var->pixclock)'.
> drivers/video/sstfb.c:361 sstfb_check_var() error: potential divide by zero bug '/ (var->pixclock)'.
> drivers/video/sstfb.c:361 sstfb_check_var() error: potential divide by zero bug '/ (var->pixclock)'.
> drivers/video/sstfb.c:491 sstfb_set_par() error: potential divide by zero bug '/ (info->var.pixclock)'.
> drivers/video/sstfb.c:491 sstfb_set_par() error: potential divide by zero bug '/ (info->var.pixclock)'.
> drivers/video/sm501fb.c:263 sm501fb_ps_to_hz() error: potential divide by zero bug '/ __base'.
> drivers/video/sm501fb.c:263 sm501fb_ps_to_hz() error: potential divide by zero bug '/ __base'.
> drivers/video/sm501fb.c:263 sm501fb_ps_to_hz() error: potential divide by zero bug '/ __base'.
> drivers/video/sm501fb.c:263 sm501fb_ps_to_hz() error: potential divide by zero bug '/ __base'.
> drivers/video/sm501fb.c:593 sm501fb_pan_crt() error: potential divide by zero bug '/ bytes_pixel'.
> drivers/video/sm501fb.c:593 sm501fb_pan_crt() error: potential divide by zero bug '/ bytes_pixel'.
> drivers/video/cyber2000fb.c:843 cyber2000fb_check_var() error: potential divide by zero bug '/ (var->bits_per_pixel * var->xres_virtual)'.
> drivers/video/cyber2000fb.c:843 cyber2000fb_check_var() error: potential divide by zero bug '/ (var->bits_per_pixel * var->xres_virtual)'.
> drivers/video/kyro/STG4000OverlayDevice.c:379 SetOverlayViewPort() error: potential divide by zero bug '/ ulFxScale'.
> drivers/video/kyro/STG4000OverlayDevice.c:379 SetOverlayViewPort() error: potential divide by zero bug '/ ulFxScale'.
> drivers/video/kyro/STG4000OverlayDevice.c:477 SetOverlayViewPort() error: potential divide by zero bug '/ (ulRight - ulLeft + 2)'.
> drivers/video/kyro/STG4000OverlayDevice.c:477 SetOverlayViewPort() error: potential divide by zero bug '/ (ulRight - ulLeft + 2)'.
> drivers/video/kyro/STG4000OverlayDevice.c:481 SetOverlayViewPort() error: potential divide by zero bug '/ (ulRight - ulLeft + 2)'.
> drivers/video/kyro/STG4000OverlayDevice.c:481 SetOverlayViewPort() error: potential divide by zero bug '/ (ulRight - ulLeft + 2)'.
> drivers/video/kyro/fbdev.c:502 kyrofb_set_par() error: potential divide by zero bug '/ frameclock'.
> drivers/video/kyro/fbdev.c:502 kyrofb_set_par() error: potential divide by zero bug '/ frameclock'.
> drivers/video/kyro/fbdev.c:503 kyrofb_set_par() error: potential divide by zero bug '/ lineclock'.
> drivers/video/kyro/fbdev.c:503 kyrofb_set_par() error: potential divide by zero bug '/ lineclock'.
> drivers/video/kyro/fbdev.c:505 kyrofb_set_par() error: potential divide by zero bug '/ info->var.pixclock'.
> drivers/video/kyro/fbdev.c:505 kyrofb_set_par() error: potential divide by zero bug '/ info->var.pixclock'.
> drivers/video/modedb.c:809 fb_var_to_videomode() error: potential divide by zero bug '/ htotal'.
> drivers/video/modedb.c:809 fb_var_to_videomode() error: potential divide by zero bug '/ htotal'.
> drivers/video/modedb.c:810 fb_var_to_videomode() error: potential divide by zero bug '/ vtotal'.
> drivers/video/modedb.c:810 fb_var_to_videomode() error: potential divide by zero bug '/ vtotal'.
> drivers/video/mb862xx/mb862xxfbdrv.c:221 mb862xxfb_set_par() error: potential divide by zero bug '/ fbi->var.pixclock'.
> drivers/video/mb862xx/mb862xxfbdrv.c:221 mb862xxfb_set_par() error: potential divide by zero bug '/ fbi->var.pixclock'.
> drivers/video/smscufx.c:622 ufx_config_pix_clk() error: potential divide by zero bug '/ (pixclock)'.
> drivers/video/smscufx.c:622 ufx_config_pix_clk() error: potential divide by zero bug '/ (pixclock)'.
> drivers/video/s3fb.c:477 s3_set_pixclock() error: potential divide by zero bug '/ pixclock'.
> drivers/video/s3fb.c:477 s3_set_pixclock() error: potential divide by zero bug '/ pixclock'.
> drivers/video/s3fb.c:601 s3fb_check_var() error: potential divide by zero bug '/ (var->pixclock)'.
> drivers/video/s3fb.c:601 s3fb_check_var() error: potential divide by zero bug '/ (var->pixclock)'.
> drivers/video/imsttfb.c:843 imsttfb_check_var() error: potential divide by zero bug '/ var->xres_virtual'.
> drivers/video/imsttfb.c:843 imsttfb_check_var() error: potential divide by zero bug '/ var->xres_virtual'.
> drivers/video/asiliantfb.c:113 asiliant_calc_dclk2() error: potential divide by zero bug '/ pixclock'.
> drivers/video/asiliantfb.c:113 asiliant_calc_dclk2() error: potential divide by zero bug '/ pixclock'.
> drivers/video/asiliantfb.c:123 asiliant_calc_dclk2() error: potential divide by zero bug '/ pixclock'.
> drivers/video/asiliantfb.c:123 asiliant_calc_dclk2() error: potential divide by zero bug '/ pixclock'.
> drivers/video/asiliantfb.c:124 asiliant_calc_dclk2() error: potential divide by zero bug '/ pixclock'.
> drivers/video/asiliantfb.c:124 asiliant_calc_dclk2() error: potential divide by zero bug '/ pixclock'.
> drivers/video/asiliantfb.c:125 asiliant_calc_dclk2() error: potential divide by zero bug '/ pixclock'.
> drivers/video/asiliantfb.c:125 asiliant_calc_dclk2() error: potential divide by zero bug '/ pixclock'.
> drivers/video/asiliantfb.c:230 asiliantfb_check_var() error: potential divide by zero bug '/ var->pixclock'.
> drivers/video/asiliantfb.c:230 asiliantfb_check_var() error: potential divide by zero bug '/ var->pixclock'.
> drivers/video/asiliantfb.c:231 asiliantfb_check_var() error: potential divide by zero bug '/ var->pixclock'.
> drivers/video/asiliantfb.c:231 asiliantfb_check_var() error: potential divide by zero bug '/ var->pixclock'.
> drivers/video/asiliantfb.c:232 asiliantfb_check_var() error: potential divide by zero bug '/ var->pixclock'.
> drivers/video/asiliantfb.c:232 asiliantfb_check_var() error: potential divide by zero bug '/ var->pixclock'.
> drivers/video/i740fb.c:435 i740fb_decode_var() error: potential divide by zero bug '/ var->pixclock'.
> drivers/video/i740fb.c:435 i740fb_decode_var() error: potential divide by zero bug '/ var->pixclock'.
> drivers/video/i740fb.c:437 i740fb_decode_var() error: potential divide by zero bug '/ var->pixclock'.
> drivers/video/i740fb.c:437 i740fb_decode_var() error: potential divide by zero bug '/ var->pixclock'.
> drivers/video/i740fb.c:444 i740fb_decode_var() error: potential divide by zero bug '/ var->pixclock'.
> drivers/video/i740fb.c:444 i740fb_decode_var() error: potential divide by zero bug '/ var->pixclock'.
> drivers/video/i740fb.c:446 i740fb_decode_var() error: potential divide by zero bug '/ var->pixclock'.
> drivers/video/i740fb.c:446 i740fb_decode_var() error: potential divide by zero bug '/ var->pixclock'.
> drivers/video/i740fb.c:453 i740fb_decode_var() error: potential divide by zero bug '/ var->pixclock'.
> drivers/video/i740fb.c:453 i740fb_decode_var() error: potential divide by zero bug '/ var->pixclock'.
> drivers/video/i740fb.c:455 i740fb_decode_var() error: potential divide by zero bug '/ var->pixclock'.
> drivers/video/i740fb.c:455 i740fb_decode_var() error: potential divide by zero bug '/ var->pixclock'.
> drivers/video/i740fb.c:461 i740fb_decode_var() error: potential divide by zero bug '/ var->pixclock'.
> drivers/video/i740fb.c:461 i740fb_decode_var() error: potential divide by zero bug '/ var->pixclock'.
> drivers/video/i740fb.c:463 i740fb_decode_var() error: potential divide by zero bug '/ var->pixclock'.
> drivers/video/i740fb.c:463 i740fb_decode_var() error: potential divide by zero bug '/ var->pixclock'.
> drivers/video/i740fb.c:655 i740fb_decode_var() error: potential divide by zero bug '/ var->pixclock'.
> drivers/video/i740fb.c:655 i740fb_decode_var() error: potential divide by zero bug '/ var->pixclock'.
> drivers/video/i740fb.c:662 i740fb_decode_var() error: potential divide by zero bug '/ var->pixclock'.
> drivers/video/i740fb.c:662 i740fb_decode_var() error: potential divide by zero bug '/ var->pixclock'.
> drivers/video/cirrusfb.c:482 cirrusfb_check_pixclock() error: potential divide by zero bug '/ (var->pixclock)'.
> drivers/video/cirrusfb.c:482 cirrusfb_check_pixclock() error: potential divide by zero bug '/ (var->pixclock)'.
> drivers/video/cirrusfb.c:535 cirrusfb_check_var() error: potential divide by zero bug '/ var->bits_per_pixel'.
> drivers/video/cirrusfb.c:535 cirrusfb_check_var() error: potential divide by zero bug '/ var->bits_per_pixel'.
> drivers/video/cirrusfb.c:581 cirrusfb_check_var() error: potential divide by zero bug '/ var->xres_virtual'.
> drivers/video/cirrusfb.c:581 cirrusfb_check_var() error: potential divide by zero bug '/ var->xres_virtual'.
> drivers/video/cirrusfb.c:836 cirrusfb_set_par_foo() error: potential divide by zero bug '/ (var->pixclock)'.
> drivers/video/cirrusfb.c:836 cirrusfb_set_par_foo() error: potential divide by zero bug '/ (var->pixclock)'.
> drivers/video/riva/fbdev.c:722 riva_load_video_mode() error: potential divide by zero bug '/ info->var.pixclock'.
> drivers/video/riva/fbdev.c:722 riva_load_video_mode() error: potential divide by zero bug '/ info->var.pixclock'.
> drivers/video/geode/lxfb_ops.c:169 lx_set_clock() error: potential divide by zero bug '/ info->var.pixclock'.
> drivers/video/geode/lxfb_ops.c:169 lx_set_clock() error: potential divide by zero bug '/ info->var.pixclock'.
> drivers/video/sis/sis_main.c:1082 sisfb_calc_maxyres() error: potential divide by zero bug '/ (var->xres_virtual * (var->bits_per_pixel >> 3))'.
> drivers/video/sis/sis_main.c:1082 sisfb_calc_maxyres() error: potential divide by zero bug '/ (var->xres_virtual * (var->bits_per_pixel >> 3))'.
> drivers/video/nvidia/nvidia.c:424 nvidia_calc_regs() error: potential divide by zero bug '/ info->var.pixclock'.
> drivers/video/nvidia/nvidia.c:424 nvidia_calc_regs() error: potential divide by zero bug '/ info->var.pixclock'.
> drivers/video/tridentfb.c:918 tridentfb_check_var() error: potential divide by zero bug '/ line_length'.
> drivers/video/tridentfb.c:918 tridentfb_check_var() error: potential divide by zero bug '/ line_length'.
> drivers/video/tridentfb.c:973 tridentfb_check_var() error: potential divide by zero bug '/ (var->pixclock)'.
> drivers/video/tridentfb.c:973 tridentfb_check_var() error: potential divide by zero bug '/ (var->pixclock)'.
> drivers/video/tridentfb.c:1176 tridentfb_set_par() error: potential divide by zero bug '/ (info->var.pixclock)'.
> drivers/video/tridentfb.c:1176 tridentfb_set_par() error: potential divide by zero bug '/ (info->var.pixclock)'.
> drivers/video/neofb.c:594 neofb_check_var() error: potential divide by zero bug '/ (var->pixclock)'.
> drivers/video/neofb.c:594 neofb_check_var() error: potential divide by zero bug '/ (var->pixclock)'.
> drivers/video/neofb.c:702 neofb_check_var() error: potential divide by zero bug '/ (var->xres_virtual * var->bits_per_pixel)'.
> drivers/video/neofb.c:702 neofb_check_var() error: potential divide by zero bug '/ (var->xres_virtual * var->bits_per_pixel)'.
> drivers/video/neofb.c:952 neofb_set_par() error: potential divide by zero bug '/ (info->var.pixclock)'.
> drivers/video/neofb.c:952 neofb_set_par() error: potential divide by zero bug '/ (info->var.pixclock)'.
> drivers/video/arkfb.c:517 ark_set_pixclock() error: potential divide by zero bug '/ pixclock'.
> drivers/video/arkfb.c:517 ark_set_pixclock() error: potential divide by zero bug '/ pixclock'.
> drivers/video/udlfb.c:266 dlfb_set_vid_cmds() error: potential divide by zero bug '/ var->pixclock'.
> drivers/video/udlfb.c:266 dlfb_set_vid_cmds() error: potential divide by zero bug '/ var->pixclock'.
> drivers/video/uvesafb.c:1270 uvesafb_set_par() error: potential divide by zero bug '/ (crtc->vert_total * crtc->horiz_total)'.
> drivers/video/uvesafb.c:1270 uvesafb_set_par() error: potential divide by zero bug '/ (crtc->vert_total * crtc->horiz_total)'.
> drivers/video/pm2fb.c:624 pm2fb_check_var() error: potential divide by zero bug '/ (var->pixclock)'.
> drivers/video/pm2fb.c:624 pm2fb_check_var() error: potential divide by zero bug '/ (var->pixclock)'.
> drivers/video/pm2fb.c:716 pm2fb_set_par() error: potential divide by zero bug '/ (info->var.pixclock)'.
> drivers/video/pm2fb.c:716 pm2fb_set_par() error: potential divide by zero bug '/ (info->var.pixclock)'.
> drivers/video/vermilion/vermilion.c:609 vmlfb_check_var_locked() error: potential divide by zero bug '/ (var->pixclock)'.
> drivers/video/vermilion/vermilion.c:609 vmlfb_check_var_locked() error: potential divide by zero bug '/ (var->pixclock)'.
> drivers/video/matrox/matroxfb_Ti3026.c:320 Ti3026_setpclk() error: potential divide by zero bug '/ Bpp'.
> drivers/video/matrox/matroxfb_Ti3026.c:320 Ti3026_setpclk() error: potential divide by zero bug '/ Bpp'.
> drivers/video/matrox/matroxfb_Ti3026.c:323 Ti3026_setpclk() error: potential divide by zero bug '/ Bpp'.
> drivers/video/matrox/matroxfb_Ti3026.c:323 Ti3026_setpclk() error: potential divide by zero bug '/ Bpp'.
> drivers/video/matrox/matroxfb_base.c:578 matroxfb_decode_var() error: potential divide by zero bug '/ (var->xres_virtual * bpp)'.
> drivers/video/matrox/matroxfb_base.c:578 matroxfb_decode_var() error: potential divide by zero bug '/ (var->xres_virtual * bpp)'.
> drivers/video/matrox/matroxfb_base.c:601 matroxfb_decode_var() error: potential divide by zero bug '/ m2'.
> drivers/video/matrox/matroxfb_base.c:601 matroxfb_decode_var() error: potential divide by zero bug '/ m2'.
> drivers/video/matrox/matroxfb_base.c:787 matroxfb_set_par() error: potential divide by zero bug '/ var->bits_per_pixel'.
> drivers/video/matrox/matroxfb_base.c:787 matroxfb_set_par() error: potential divide by zero bug '/ var->bits_per_pixel'.
> drivers/video/aty/radeon_base.c:1595 radeonfb_set_par() error: potential divide by zero bug '/ pixClock'.
> drivers/video/aty/radeon_base.c:1595 radeonfb_set_par() error: potential divide by zero bug '/ pixClock'.
> drivers/video/aty/radeon_base.c:1670 radeonfb_set_par() error: potential divide by zero bug '/ ((mode->bits_per_pixel + 1) / 8)'.
> drivers/video/aty/radeon_base.c:1670 radeonfb_set_par() error: potential divide by zero bug '/ ((mode->bits_per_pixel + 1) / 8)'.
> drivers/video/aty/atyfb_base.c:1575 set_off_pitch() error: potential divide by zero bug '/ bpp'.
> drivers/video/aty/atyfb_base.c:1575 set_off_pitch() error: potential divide by zero bug '/ bpp'.
> drivers/video/aty/mach64_accel.c:69 aty_init_engine() error: potential divide by zero bug '/ (info->var.bits_per_pixel / 8)'.
> drivers/video/aty/mach64_accel.c:69 aty_init_engine() error: potential divide by zero bug '/ (info->var.bits_per_pixel / 8)'.
> drivers/video/aty/aty128fb.c:1342 aty128_var_to_pll() error: potential divide by zero bug '/ period_in_ps'.
> drivers/video/aty/aty128fb.c:1342 aty128_var_to_pll() error: potential divide by zero bug '/ period_in_ps'.
> drivers/video/sysfillrect.c:267 sys_fillrect() error: potential divide by zero bug '/ bpp'.
> drivers/video/sysfillrect.c:267 sys_fillrect() error: potential divide by zero bug '/ bpp'.
> drivers/video/sysfillrect.c:321 sys_fillrect() error: potential divide by zero bug '/ bpp'.
> drivers/video/sysfillrect.c:321 sys_fillrect() error: potential divide by zero bug '/ bpp'.
> drivers/video/cfbfillrect.c:302 cfb_fillrect() error: potential divide by zero bug '/ bpp'.
> drivers/video/cfbfillrect.c:302 cfb_fillrect() error: potential divide by zero bug '/ bpp'.
> drivers/video/cfbfillrect.c:357 cfb_fillrect() error: potential divide by zero bug '/ bpp'.
> drivers/video/cfbfillrect.c:357 cfb_fillrect() error: potential divide by zero bug '/ bpp'.
> drivers/video/vt8623fb.c:267 vt8623_set_pixclock() error: potential divide by zero bug '/ pixclock'.
> drivers/video/vt8623fb.c:267 vt8623_set_pixclock() error: potential divide by zero bug '/ pixclock'.
>
^ permalink raw reply
* Re: some divide by zero bugs in >fb_check_var() functions
From: Geert Uytterhoeven @ 2014-05-02 15:48 UTC (permalink / raw)
To: linux-fbdev
In-Reply-To: <20140124223503.GA4251@elgon.mountain>
On Tue, Jan 28, 2014 at 10:28 PM, Kees Cook <keescook@chromium.org> wrote:
> Is it ever valid to have pixclock, xres_virtual, or bits_per_pixel be
> zero? Seems like it'd be trivial to check for those in fb_set_var()?
pixclock could be zero for some special fixed type of display that doesn't
have timings. Hmm, you could use 1 for that. Are there any in-tree users?
Anyway, the checker reported issues with specific drivers, not with the core,
right?
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* Please Acknowledge My Proposal
From: Gva Abogados @ 2014-05-03 12:20 UTC (permalink / raw)
To: linux-fbdev
Please Acknowledge My Proposal!!
My name is Mr. Juan Martin Domingo a lawyer resident in Spain. I am
writing to let you know I have some FUNDS I want to transfer and am
seeking if you can be a beneficiary...Do not hesitate to Contact me for
more information if interested: gva_abogados@aim.com
Sincerely
Juan Martin Domingo.
Domijdo@aim.com
^ permalink raw reply
* Re: [PATCH v2 1/3] video: clps711x: Add new Cirrus Logic CLPS711X framebuffer driver
From: Olof Johansson @ 2014-05-05 5:06 UTC (permalink / raw)
To: linux-fbdev
In-Reply-To: <1397285583-15187-1-git-send-email-shc_work@mail.ru>
On Wed, Apr 30, 2014 at 04:36:29PM +0400, Alexander Shiyan wrote:
> Wed, 30 Apr 2014 14:14:36 +0300 от Tomi Valkeinen <tomi.valkeinen@ti.com>:
> > On 24/04/14 19:35, Alexander Shiyan wrote:
>
> Hello.
>
> I'm a reorder quotes a bit for convenience.
>
> > >> The right way to do it is, as I wrote above, by gradually changing the
> > >> old driver with a patch series. And my question is, why not do it that
> > >> way? Then it would be possible to review the patches one by one, seeing
> > >> what has changed.
> > >
> > > "gradually changing"...
> > > I repeat that this is not an old modified driver, but written new.
> >
> > Yes, I understand that. Again, my question is, why didn't you modify the
> > old driver? That's how things should normally be done. Instead, you made
> > a totally new one, making proper review against the old driver impossible.
> ...
> > Hmm what? So is the old driver totally broken, and cannot be used at the
> > moment? Or why you can't test on real hardware?
>
> Firstly, the driver uses a fixed values for xres, yres, pixclock and specific
> variable ac_precale.
> Secondly, the driver uses a fixed value for the physical address of the buffer.
> Totally, it does not give me the ability to use the driver in the current state.
> Unlikely that this will look good if I make these two significant changes in
> a single patch...
>
> At this time the driver has three user.
> Only one of them should theoretically work.
> clps711x-autcpu12 should not work in the absence of memblock_reserve().
> clps711x-p720t should not work due to physical address limitation as i
> noticed before. Board means to use SRAM instead of SDRAM.
> Only clps711x-edb7211 should work fine (in theory).
> Is this a good reason to replace the driver? I think yes.
>
> > Note that I don't know anything about the fb hardware in question, nor
> > the driver. Maybe there's a valid reason to write a new driver from
> > scratch. But there very rarely is.
> >
> > And "because I already wrote a new driver, and it's a waste of time for
> > me to throw away my work and patch the old one", is not a very good reason.
>
> > > if you imagine a new file as a diff to the old, this can be clearly seen.
> > >
> > > There is no reason to waste time on a series of changes since I
> > > can not even check these changes on real hardware, but only in the
> > > last stage when the driver will be the current version.
>
> Summing up, I want to ask why the driver can not be reviewed as a
> new and not compared to the old?
> And yes, the time can be spent on more productive things to do than
> to create a series, leading eventually to the same result.
> As far as I know, guide to creating kernel patches allows such cases.
We've definitely had cases like that in the past. Sometimes it's easier
to first post a patch that removes the old driver, then one that submits
the new one as a new piece of work. That, of course, assumes that the
driver indeed was a rewrite and not just a bunch of incremental changes
all squashed into one.
-Olof
^ permalink raw reply
* [PATCH v2] video: mx3fb: Add backlight support
From: Alexander Stein @ 2014-05-05 6:56 UTC (permalink / raw)
To: linux-fbdev
Signed-off-by: Alexander Stein <alexander.stein@systec-electronic.com>
---
Changes in v2:
* rebased to v3.15-rc4
drivers/video/fbdev/mx3fb.c | 98 +++++++++++++++++++++++++++++++++++++++++++++
1 file changed, 98 insertions(+)
diff --git a/drivers/video/fbdev/mx3fb.c b/drivers/video/fbdev/mx3fb.c
index 142e860..10a7244 100644
--- a/drivers/video/fbdev/mx3fb.c
+++ b/drivers/video/fbdev/mx3fb.c
@@ -27,6 +27,7 @@
#include <linux/clk.h>
#include <linux/mutex.h>
#include <linux/dma/ipu-dma.h>
+#include <linux/backlight.h>
#include <linux/platform_data/dma-imx.h>
#include <linux/platform_data/video-mx3fb.h>
@@ -34,6 +35,12 @@
#include <asm/io.h>
#include <asm/uaccess.h>
+#if defined(CONFIG_BACKLIGHT_CLASS_DEVICE) || \
+ (defined(CONFIG_BACKLIGHT_CLASS_DEVICE_MODULE) && \
+ defined(CONFIG_MX3FB_MODULE))
+#define PWM_BACKLIGHT_AVAILABLE
+#endif
+
#define MX3FB_NAME "mx3_sdc_fb"
#define MX3FB_REG_OFFSET 0xB4
@@ -242,6 +249,10 @@ struct mx3fb_data {
spinlock_t lock;
struct device *dev;
+#ifdef PWM_BACKLIGHT_AVAILABLE
+ struct backlight_device *bl;
+#endif
+
uint32_t h_start_width;
uint32_t v_start_width;
enum disp_data_mapping disp_data_fmt;
@@ -271,6 +282,74 @@ struct mx3fb_info {
struct fb_var_screeninfo cur_var; /* current var info */
};
+static void sdc_set_brightness(struct mx3fb_data *mx3fb, uint8_t value);
+
+#ifdef PWM_BACKLIGHT_AVAILABLE
+static u32 sdc_get_brightness(struct mx3fb_data *mx3fb);
+
+static int mx3fb_bl_get_brightness(struct backlight_device *bl)
+{
+ struct mx3fb_data *fbd = bl_get_data(bl);
+
+ return sdc_get_brightness(fbd);
+}
+
+static int mx3fb_bl_update_status(struct backlight_device *bl)
+{
+ struct mx3fb_data *fbd = bl_get_data(bl);
+ int brightness = bl->props.brightness;
+
+ if (bl->props.power != FB_BLANK_UNBLANK)
+ brightness = 0;
+ if (bl->props.fb_blank != FB_BLANK_UNBLANK)
+ brightness = 0;
+
+ fbd->backlight_level = (fbd->backlight_level & ~0xFF) | brightness;
+
+ sdc_set_brightness(fbd, fbd->backlight_level);
+
+ return 0;
+}
+
+static const struct backlight_ops mx3fb_lcdc_bl_ops = {
+ .update_status = mx3fb_bl_update_status,
+ .get_brightness = mx3fb_bl_get_brightness,
+};
+
+static void mx3fb_init_backlight(struct mx3fb_data *fbd)
+{
+ struct backlight_properties props;
+ struct backlight_device *bl;
+
+ if (fbd->bl)
+ return;
+
+ memset(&props, 0, sizeof(struct backlight_properties));
+ props.max_brightness = 0xff;
+ props.type = BACKLIGHT_RAW;
+ sdc_set_brightness(fbd, fbd->backlight_level);
+
+ bl = backlight_device_register("mx3fb-bl", fbd->dev, fbd,
+ &mx3fb_lcdc_bl_ops, &props);
+ if (IS_ERR(bl)) {
+ dev_err(fbd->dev, "error %ld on backlight register\n",
+ PTR_ERR(bl));
+ return;
+ }
+
+ fbd->bl = bl;
+ bl->props.power = FB_BLANK_UNBLANK;
+ bl->props.fb_blank = FB_BLANK_UNBLANK;
+ bl->props.brightness = mx3fb_bl_get_brightness(bl);
+}
+
+static void mx3fb_exit_backlight(struct mx3fb_data *fbd)
+{
+ if (fbd->bl)
+ backlight_device_unregister(fbd->bl);
+}
+#endif
+
static void mx3fb_dma_done(void *);
/* Used fb-mode and bpp. Can be set on kernel command line, therefore file-static. */
@@ -628,6 +707,18 @@ static int sdc_set_global_alpha(struct mx3fb_data *mx3fb, bool enable, uint8_t a
return 0;
}
+#ifdef PWM_BACKLIGHT_AVAILABLE
+static u32 sdc_get_brightness(struct mx3fb_data *mx3fb)
+{
+ u32 brightness;
+
+ brightness = mx3fb_read_reg(mx3fb, SDC_PWM_CTRL);
+ brightness = (brightness >> 16) & 0xFF;
+
+ return brightness;
+}
+#endif
+
static void sdc_set_brightness(struct mx3fb_data *mx3fb, uint8_t value)
{
dev_dbg(mx3fb->dev, "%s: value = %d\n", __func__, value);
@@ -1534,6 +1625,9 @@ static int mx3fb_probe(struct platform_device *pdev)
if (ret < 0)
goto eisdc0;
+#ifdef PWM_BACKLIGHT_AVAILABLE
+ mx3fb_init_backlight(mx3fb);
+#endif
return 0;
eisdc0:
@@ -1557,6 +1651,10 @@ static int mx3fb_remove(struct platform_device *dev)
chan = &mx3_fbi->idmac_channel->dma_chan;
release_fbi(fbi);
+#ifdef PWM_BACKLIGHT_AVAILABLE
+ mx3fb_exit_backlight(mx3fb);
+#endif
+
dma_release_channel(chan);
dmaengine_put();
--
1.8.5.5
^ permalink raw reply related
* Re: [PATCH 4/4] ARM: dts: Add LCD panel sharp ls037v7dw01 support for omap3-evm and ldp
From: Tony Lindgren @ 2014-05-05 18:39 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140430174751.GA12362@atomide.com>
* Tony Lindgren <tony@atomide.com> [140430 10:48]:
> * Joachim Eastwood <manabian@gmail.com> [140429 18:08]:
> > On 30 April 2014 01:52, Tony Lindgren <tony@atomide.com> wrote:
> > > Looks like quite a few omaps 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 panel for ldp is configured
> > > in the qvga mode and omap3-evm panel in vga mode.
> > >
> > > 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 <tony@atomide.com>
> > > ---
> > > .../arm/boot/dts/omap-panel-sharp-ls037v7dw01.dtsi | 82 ++++++++++++++++++++++
> > > arch/arm/boot/dts/omap3-evm-37xx.dts | 50 +++++++++++++
> > > arch/arm/boot/dts/omap3-evm-common.dtsi | 47 +++++++++++++
> > > arch/arm/boot/dts/omap3-ldp.dts | 31 ++++++--
> > > 4 files changed, 205 insertions(+), 5 deletions(-)
> > > create mode 100644 arch/arm/boot/dts/omap-panel-sharp-ls037v7dw01.dtsi
> >
> > > diff --git a/arch/arm/boot/dts/omap3-ldp.dts b/arch/arm/boot/dts/omap3-ldp.dts
> > > index 0abe986..50fdac9 100644
> > > --- a/arch/arm/boot/dts/omap3-ldp.dts
> > > +++ b/arch/arm/boot/dts/omap3-ldp.dts
> > > @@ -164,6 +164,7 @@
> > >
> > > #include "twl4030.dtsi"
> > > #include "twl4030_omap3.dtsi"
> > > +#include "omap-panel-sharp-ls037v7dw01.dtsi"
> > >
> > > &i2c2 {
> > > clock-frequency = <400000>;
> > > @@ -173,6 +174,31 @@
> > > clock-frequency = <400000>;
> > > };
> > >
> > > +&lcd_3v3 {
> > > + gpio = <&twl_gpio 7 GPIO_ACTIVE_HIGH>;
> > > + enable-active-high;
> > > +};
> > > +
> > > +&lcd0 {
> > > + reset-gpios = <&gpio2 23 GPIO_ACTIVE_HIGH>; /* gpio55, lcd RESB */
> > > + gpios = <&gpio2 24 GPIO_ACTIVE_LOW /* gpio56, lcd MO */
> >
> > enable-gpios ?
>
> Oops yes, changed from gpios to enable-gpios while reading the panel
> binding doc, probably forgot to commit the change, will update.
Here's an updated version of this one.
Tony
From: Tony Lindgren <tony@atomide.com>
Date: Mon, 28 Apr 2014 20:22:21 -0700
Subject: [PATCH] ARM: dts: Add LCD panel sharp ls037v7dw01 support for omap3-evm and ldp
Looks like quite a few omaps 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 panel for ldp is configured
in the qvga mode and omap3-evm panel in vga mode.
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 <tony@atomide.com>
diff --git a/arch/arm/boot/dts/omap-panel-sharp-ls037v7dw01.dtsi b/arch/arm/boot/dts/omap-panel-sharp-ls037v7dw01.dtsi
new file mode 100644
index 0000000..f5252da
--- /dev/null
+++ b/arch/arm/boot/dts/omap-panel-sharp-ls037v7dw01.dtsi
@@ -0,0 +1,82 @@
+/*
+ * Common file for omap dpi panels with QVGA and reset pins
+ *
+ * Note that the board specifc DTS file needs to specify
+ * at minimum the GPIO enable-gpios for display, and
+ * gpios for gpio-backlight.
+ */
+
+/ {
+ aliases {
+ display0 = &lcd0;
+ };
+
+ backlight0: backlight {
+ compatible = "gpio-backlight";
+ };
+
+ /* 3.3V GPIO controlled regulator for LCD_ENVDD */
+ lcd_3v3: regulator-lcd-3v3 {
+ compatible = "regulator-fixed";
+ regulator-name = "lcd_3v3";
+ regulator-min-microvolt = <3300000>;
+ regulator-max-microvolt = <3300000>;
+ startup-delay-us = <70000>;
+ regulator-always-on;
+ };
+
+ lcd0: display {
+ compatible = "sharp,ls037v7dw01";
+ label = "lcd";
+ power-supply = <&lcd_3v3>;
+ panel-timing {
+ clock-frequency = <5400000>;
+ hback-porch = <39>;
+ hactive = <240>;
+ hfront-porch = <3>;
+ hsync-len = <3>;
+ vback-porch = <7>;
+ vactive = <320>;
+ vfront-porch = <2>;
+ vsync-len = <1>;
+ hsync-active = <0>;
+ vsync-active = <0>;
+ de-active = <1>;
+ pixelclk-active = <1>;
+ };
+
+ port {
+ lcd_in: endpoint {
+ remote-endpoint = <&dpi_out>;
+ };
+ };
+ };
+};
+
+&dss {
+ status = "ok";
+ vdds_dsi-supply = <&vpll2>;
+ port {
+ dpi_out: endpoint {
+ remote-endpoint = <&lcd_in>;
+ data-lines = <18>;
+ };
+ };
+};
+
+&mcspi1 {
+ tsc2046@0 {
+ reg = <0>; /* CS0 */
+ compatible = "ti,tsc2046";
+ spi-max-frequency = <1000000>;
+ vcc-supply = <&lcd_3v3>;
+ ti,x-min = /bits/ 16 <0>;
+ ti,x-max = /bits/ 16 <8000>;
+ ti,y-min = /bits/ 16 <0>;
+ ti,y-max = /bits/ 16 <4800>;
+ ti,x-plate-ohms = /bits/ 16 <40>;
+ ti,pressure-max = /bits/ 16 <255>;
+ ti,swap-xy;
+ linux,wakeup;
+ };
+};
diff --git a/arch/arm/boot/dts/omap3-evm-37xx.dts b/arch/arm/boot/dts/omap3-evm-37xx.dts
index 4df68ad..a181e30 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 b/arch/arm/boot/dts/omap3-evm-common.dtsi
index 3007e79..0ab9650 100644
--- a/arch/arm/boot/dts/omap3-evm-common.dtsi
+++ b/arch/arm/boot/dts/omap3-evm-common.dtsi
@@ -44,6 +44,11 @@
#include "twl4030.dtsi"
#include "twl4030_omap3.dtsi"
+#include "omap-panel-sharp-ls037v7dw01.dtsi"
+
+&backlight0 {
+ gpios = <&twl_gpio 18 GPIO_ACTIVE_HIGH>;
+};
&i2c2 {
clock-frequency = <400000>;
@@ -61,6 +66,48 @@
};
};
+&lcd_3v3 {
+ gpio = <&gpio5 25 GPIO_ACTIVE_LOW>; /* gpio153 */
+ enable-active-low;
+};
+
+&lcd0 {
+ reset-gpios = <&gpio5 27 GPIO_ACTIVE_HIGH>; /* gpio155, lcd RESB */
+ /*
+ * The LCD is sideways, so we want the VGA mode instead of
+ * QVGA mode. Probably also want to have omapfb.rotate=3
+ * in the kernel cmdline until there's a binding for that.
+ */
+ enable-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 */
+ &gpio5 24 GPIO_ACTIVE_HIGH>; /* gpio152, lcd INI */
+
+ panel-timing {
+ clock-frequency = <19200000>;
+ hback-porch = <28>;
+ hactive = <480>;
+ hfront-porch = <1>;
+ hsync-len = <2>;
+ vback-porch = <1>;
+ vactive = <640>;
+ vfront-porch = <1>;
+ vsync-len = <1>;
+ hsync-active = <0>;
+ vsync-active = <0>;
+ de-active = <1>;
+ pixelclk-active = <1>;
+ };
+};
+
+&mcspi1 {
+ tsc2046@0 {
+ interrupt-parent = <&gpio6>;
+ interrupts = <15 0>; /* gpio175 */
+ pendown-gpio = <&gpio6 15 0>;
+ };
+};
+
&mmc1 {
vmmc-supply = <&vmmc1>;
vmmc_aux-supply = <&vsim>;
diff --git a/arch/arm/boot/dts/omap3-ldp.dts b/arch/arm/boot/dts/omap3-ldp.dts
index 0abe986..01b0808 100644
--- a/arch/arm/boot/dts/omap3-ldp.dts
+++ b/arch/arm/boot/dts/omap3-ldp.dts
@@ -164,6 +164,11 @@
#include "twl4030.dtsi"
#include "twl4030_omap3.dtsi"
+#include "omap-panel-sharp-ls037v7dw01.dtsi"
+
+&backlight0 {
+ gpios = <&twl_gpio 15 GPIO_ACTIVE_LOW>;
+};
&i2c2 {
clock-frequency = <400000>;
@@ -173,6 +178,27 @@
clock-frequency = <400000>;
};
+&lcd_3v3 {
+ gpio = <&twl_gpio 7 GPIO_ACTIVE_HIGH>;
+ enable-active-high;
+};
+
+&lcd0 {
+ reset-gpios = <&gpio2 23 GPIO_ACTIVE_HIGH>; /* gpio55, lcd RESB */
+ enable-gpios = <&gpio2 24 GPIO_ACTIVE_LOW /* gpio56, lcd MO */
+ 0 /* lcd LR */
+ 0 /* lcd UD */
+ 0>; /* lcd INI */
+};
+
+&mcspi1 {
+ tsc2046@0 {
+ interrupt-parent = <&gpio2>;
+ interrupts = <22 0>; /* gpio54 */
+ pendown-gpio = <&gpio2 22 0>;
+ };
+};
+
&mmc1 {
/* See 35xx errata 2.1.1.128 in SPRZ278F */
compatible = "ti,omap3-pre-es3-hsmmc";
@@ -247,8 +273,3 @@
/* Needed for ads7846 */
regulator-name = "vcc";
};
-
-&vpll2 {
- /* Needed for DSS */
- regulator-name = "vdds_dsi";
-};
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox