* RE: [PATCH 2/3] video: fbdev: Check Standard Timing against DMT
From: David Ung @ 2014-12-05 19:47 UTC (permalink / raw)
To: linux-fbdev
In-Reply-To: <1417643369-20603-2-git-send-email-davidu@nvidia.com>
DQo+IE9uIDAzLzEyLzE0IDIzOjQ5LCBEYXZpZCBVbmcgd3JvdGU6DQo+ID4gQWRkIHRoZSBWRVNB
IERpc3BsYXkgTW9uaXRvciBUaW1pbmcgKERNVCkgdGFibGUuDQo+ID4gRHVyaW5nIHBhcnNpbmcg
b2YgU3RhbmRhcmQgVGltaW5ncywgaXQgY29tcGFyZSB0aGUgMiBieXRlIFNURCBjb2RlDQo+ID4g
d2l0aCBETVQgdG8gc2VlIHdoYXQgdGhlIFZFU0EgbW9kZSBzaG91bGQgYmUuICBJZiB0aGVyZSBp
cyBubyBlbnRyeSBpbg0KPiA+IHRoZSB2ZXNhX21vZGVzIHRhYmxlIG9yIG5vIG1hdGNoIGZvdW5k
LCBpdCBmYWxsc2JhY2sgdG8gdGhlIEdURg0KPiA+IHRpbWluZ3MuDQo+ID4NCj4gPiBTaWduZWQt
b2ZmLWJ5OiBEYXZpZCBVbmcgPGRhdmlkdUBudmlkaWEuY29tPg0KPiA+IC0tLQ0KPiA+ICBkcml2
ZXJzL3ZpZGVvL2ZiZGV2L2NvcmUvZmJtb24uYyAgfCAyMCArKysrKystLS0tDQo+ID4gZHJpdmVy
cy92aWRlby9mYmRldi9jb3JlL21vZGVkYi5jIHwgODQNCj4gKysrKysrKysrKysrKysrKysrKysr
KysrKysrKysrKysrKysrKysrDQo+ID4gIGluY2x1ZGUvbGludXgvZmIuaCAgICAgICAgICAgICAg
ICB8IDEwICsrKysrDQo+ID4gIDMgZmlsZXMgY2hhbmdlZCwgMTA3IGluc2VydGlvbnMoKyksIDcg
ZGVsZXRpb25zKC0pDQo+ID4NCj4gPiBkaWZmIC0tZ2l0IGEvZHJpdmVycy92aWRlby9mYmRldi9j
b3JlL2ZibW9uLmMNCj4gPiBiL2RyaXZlcnMvdmlkZW8vZmJkZXYvY29yZS9mYm1vbi5jDQo+ID4g
aW5kZXggNWIwZTMxMy4uYWExMTEwYSAxMDA2NDQNCj4gPiAtLS0gYS9kcml2ZXJzL3ZpZGVvL2Zi
ZGV2L2NvcmUvZmJtb24uYw0KPiA+ICsrKyBiL2RyaXZlcnMvdmlkZW8vZmJkZXYvY29yZS9mYm1v
bi5jDQo+ID4gQEAgLTUyNiwxNiArNTI2LDIyIEBAIHN0YXRpYyBpbnQgZ2V0X3N0ZF90aW1pbmco
dW5zaWduZWQgY2hhciAqYmxvY2ssDQo+IHN0cnVjdCBmYl92aWRlb21vZGUgKm1vZGUsDQo+ID4g
IAlyZWZyZXNoID0gKGJsb2NrWzFdICYgMHgzZikgKyA2MDsNCj4gPg0KPiA+ICAJRFBSSU5USygi
ICAgICAgJWR4JWRAJWRIelxuIiwgeHJlcywgeXJlcywgcmVmcmVzaCk7DQo+ID4gLQlmb3IgKGkg
PSAwOyBpIDwgVkVTQV9NT0RFREJfU0laRTsgaSsrKSB7DQo+ID4gLQkJaWYgKHZlc2FfbW9kZXNb
aV0ueHJlcyA9PSB4cmVzICYmDQo+ID4gLQkJICAgIHZlc2FfbW9kZXNbaV0ueXJlcyA9PSB5cmVz
ICYmDQo+ID4gLQkJICAgIHZlc2FfbW9kZXNbaV0ucmVmcmVzaCA9PSByZWZyZXNoKSB7DQo+ID4g
LQkJCSptb2RlID0gdmVzYV9tb2Rlc1tpXTsNCj4gPiArCWZvciAoaSA9IDA7IGkgPCBETVRfU0la
RTsgaSsrKSB7DQo+ID4gKwkJdTMyIHN0ZF8yYnl0ZV9jb2RlID0gYmxvY2tbMF0gPDwgOCB8IGJs
b2NrWzFdOw0KPiA+ICsNCj4gPiArCQlpZiAoc3RkXzJieXRlX2NvZGUgPT0gZG10X21vZGVzW2ld
LnN0ZF8yYnl0ZV9jb2RlKSB7DQo+ID4gKwkJCWlmICghZG10X21vZGVzW2ldLm1vZGUpDQo+ID4g
KwkJCQlicmVhazsNCj4gPiArCQkJKm1vZGUgPSAqZG10X21vZGVzW2ldLm1vZGU7DQo+ID4gIAkJ
CW1vZGUtPmZsYWcgfD0gRkJfTU9ERV9JU19TVEFOREFSRDsNCj4gPiAtCQkJcmV0dXJuIDE7DQo+
ID4gKwkJCURQUklOVEsoIiAgICAgICAgRE1UIGlkPSVkXG4iLA0KPiBkbXRfbW9kZXNbaV0uZG10
X2lkKTsNCj4gPiArCQkJYnJlYWs7DQo+ID4gIAkJfQ0KPiA+ICAJfQ0KPiA+IC0JY2FsY19tb2Rl
X3RpbWluZ3MoeHJlcywgeXJlcywgcmVmcmVzaCwgbW9kZSk7DQo+ID4gKw0KPiA+ICsJaWYgKGkg
PT0gRE1UX1NJWkUgfHwgIWRtdF9tb2Rlc1tpXS5tb2RlKQ0KPiA+ICsJCWNhbGNfbW9kZV90aW1p
bmdzKHhyZXMsIHlyZXMsIHJlZnJlc2gsIG1vZGUpOw0KPiA+ICsNCj4gPiAgCXJldHVybiAxOw0K
PiA+ICB9DQo+IA0KPiBJIHRoaW5rIHRoaXMgY291bGQgYmUgbWFkZSBhIGJpdCBjbGVhbmVyLg0K
PiANCj4gVGhlIHhyZXMveXJlcy9yZWZyZXNoIGNhbGN1bGF0aW9uIGluIGdldF9zdGRfdGltaW5n
IGRvZXNuJ3QgbWF0dGVyIGZvciB0aGUNCj4gRE1UIGNvZGUgYWJvdmUuIFNvIGluIGdldF9zdGRf
dGltaW5nKCkgeW91IGNvdWxkIGZpcnN0IGRvIHRoZSBzZWFyY2ggZm9yIHRoZQ0KPiBETVQgbW9k
ZSwgYW5kIGlmIGZvdW5kLCByZXR1cm4gZnJvbSB0aGUgZnVuY3Rpb24uIEFmdGVyIHRoYXQgdGhl
IGNvZGUNCj4gd291bGQgZG8gdGhlIEdURiBjYWxjdWxhdGlvbi4NCj4gDQoNClllcywgSSd2ZSBk
ZWxldGVkIHRoZSB4cmVzL3lyZXMvcmVmcmVzaCBjYWxjdWxhdGlvbi4NClRoZSByZWFzb24gZm9y
IHRoZSBicmVhayBpbnN0ZWFkIG9mIGEgcmV0dXJuIGlzIGJlY2F1c2Ugb2YgcGF0Y2ggMy8zLCB3
aGljaA0Kd2lsbCB0aGVuIHZhbGlkYXRlcyB0aGUgbW9kZSBhZ2FpbnN0IG1vbnNwZWMuDQpEYXZp
ZA0KDQoNCg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NClRoaXMgZW1haWwgbWVzc2FnZSBp
cyBmb3IgdGhlIHNvbGUgdXNlIG9mIHRoZSBpbnRlbmRlZCByZWNpcGllbnQocykgYW5kIG1heSBj
b250YWluDQpjb25maWRlbnRpYWwgaW5mb3JtYXRpb24uICBBbnkgdW5hdXRob3JpemVkIHJldmll
dywgdXNlLCBkaXNjbG9zdXJlIG9yIGRpc3RyaWJ1dGlvbg0KaXMgcHJvaGliaXRlZC4gIElmIHlv
dSBhcmUgbm90IHRoZSBpbnRlbmRlZCByZWNpcGllbnQsIHBsZWFzZSBjb250YWN0IHRoZSBzZW5k
ZXIgYnkNCnJlcGx5IGVtYWlsIGFuZCBkZXN0cm95IGFsbCBjb3BpZXMgb2YgdGhlIG9yaWdpbmFs
IG1lc3NhZ2UuDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0K
^ permalink raw reply
* [PATCH 4/4] backlight/lp855x: Remove CONFIG_OF ifdef in favor of Kconfig depends
From: Sean Paul @ 2014-12-05 18:44 UTC (permalink / raw)
To: linux-fbdev
Now that we've removed all traces of pdata, remove the CONFIG_OF ifdef
from lp855x and instead make the driver depend on OF.
Signed-off-by: Sean Paul <seanpaul@chromium.org>
---
drivers/video/backlight/Kconfig | 2 +-
drivers/video/backlight/lp855x_bl.c | 7 -------
2 files changed, 1 insertion(+), 8 deletions(-)
diff --git a/drivers/video/backlight/Kconfig b/drivers/video/backlight/Kconfig
index 8d03924..113c8b3 100644
--- a/drivers/video/backlight/Kconfig
+++ b/drivers/video/backlight/Kconfig
@@ -384,7 +384,7 @@ config BACKLIGHT_LM3639
config BACKLIGHT_LP855X
tristate "Backlight driver for TI LP855X"
- depends on BACKLIGHT_CLASS_DEVICE && I2C && PWM
+ depends on BACKLIGHT_CLASS_DEVICE && I2C && PWM && OF
help
This supports TI LP8550, LP8551, LP8552, LP8553, LP8555, LP8556 and
LP8557 backlight driver.
diff --git a/drivers/video/backlight/lp855x_bl.c b/drivers/video/backlight/lp855x_bl.c
index 8b81d8e..3d3b8cf 100644
--- a/drivers/video/backlight/lp855x_bl.c
+++ b/drivers/video/backlight/lp855x_bl.c
@@ -379,7 +379,6 @@ static const struct attribute_group lp855x_attr_group = {
.attrs = lp855x_attributes,
};
-#ifdef CONFIG_OF
static int lp855x_parse_dt(struct lp855x *lp)
{
struct device *dev = lp->dev;
@@ -425,12 +424,6 @@ static int lp855x_parse_dt(struct lp855x *lp)
return 0;
}
-#else
-static int lp855x_parse_dt(struct lp855x *lp)
-{
- return -EINVAL;
-}
-#endif
static int lp855x_probe(struct i2c_client *cl, const struct i2c_device_id *id)
{
--
2.2.0.rc0.207.ga3a616c
^ permalink raw reply related
* [PATCH 3/4] backlight/lp855x: Merge lp855x_platform_data with lp855x
From: Sean Paul @ 2014-12-05 18:44 UTC (permalink / raw)
To: linux-fbdev
Now that we have removed the platform_data header, merge lp855x_platform_data
with lp855x and remove all traces of platform_data from the driver.
Signed-off-by: Sean Paul <seanpaul@chromium.org>
---
drivers/video/backlight/lp855x_bl.c | 100 +++++++++++++++++-------------------
1 file changed, 46 insertions(+), 54 deletions(-)
diff --git a/drivers/video/backlight/lp855x_bl.c b/drivers/video/backlight/lp855x_bl.c
index d19b61c..8b81d8e 100644
--- a/drivers/video/backlight/lp855x_bl.c
+++ b/drivers/video/backlight/lp855x_bl.c
@@ -78,8 +78,16 @@ struct lp855x_rom_data {
};
/**
- * struct lp855x_platform_data
- * @name : Backlight driver name. If it is not defined, default name is set.
+ * struct lp855x
+ * @chipname : Chip name, comes from the i2c_device_id
+ * @blname : Backlight driver name. If it is not defined, default name is set.
+ * @chip_id : The type of lp855x
+ * @mode : Whether brightness is controlled via pwm or register
+ * @cfg : Chip specific hooks & register offsets
+ * @client : The i2c client
+ * @bl : The backlight device
+ * @dev : Device pointer
+ * @pwm : The pwm device (if available)
* @device_control : value of DEVICE CONTROL register
* @initial_brightness : initial value of backlight brightness
* @period_ns : platform specific pwm period value. unit is nano.
@@ -88,26 +96,23 @@ struct lp855x_rom_data {
* @rom_data : list of new eeprom/eprom registers
* @supply : regulator that supplies 3V input
*/
-struct lp855x_platform_data {
- const char *name;
- u8 device_control;
- u8 initial_brightness;
- unsigned int period_ns;
- int size_program;
- struct lp855x_rom_data *rom_data;
- struct regulator *supply;
-};
-
struct lp855x {
const char *chipname;
+ const char *blname;
enum lp855x_chip_id chip_id;
enum lp855x_brightness_ctrl_mode mode;
struct lp855x_device_config *cfg;
struct i2c_client *client;
struct backlight_device *bl;
struct device *dev;
- struct lp855x_platform_data *pdata;
struct pwm_device *pwm;
+
+ u8 device_control;
+ u8 initial_brightness;
+ unsigned int period_ns;
+ int size_program;
+ struct lp855x_rom_data *rom_data;
+ struct regulator *supply;
};
static int lp855x_write_byte(struct lp855x *lp, u8 reg, u8 data)
@@ -204,7 +209,6 @@ static int lp855x_configure(struct lp855x *lp)
{
u8 val, addr;
int i, ret;
- struct lp855x_platform_data *pd = lp->pdata;
switch (lp->chip_id) {
case LP8550:
@@ -230,20 +234,20 @@ static int lp855x_configure(struct lp855x *lp)
}
}
- val = pd->initial_brightness;
+ val = lp->initial_brightness;
ret = lp855x_write_byte(lp, lp->cfg->reg_brightness, val);
if (ret)
goto err;
- val = pd->device_control;
+ val = lp->device_control;
ret = lp855x_write_byte(lp, lp->cfg->reg_devicectrl, val);
if (ret)
goto err;
- if (pd->size_program > 0) {
- for (i = 0; i < pd->size_program; i++) {
- addr = pd->rom_data[i].addr;
- val = pd->rom_data[i].val;
+ if (lp->size_program > 0) {
+ for (i = 0; i < lp->size_program; i++) {
+ addr = lp->rom_data[i].addr;
+ val = lp->rom_data[i].val;
if (!lp855x_is_valid_rom_area(lp, addr))
continue;
@@ -269,7 +273,7 @@ err:
static void lp855x_pwm_ctrl(struct lp855x *lp, int br, int max_br)
{
- unsigned int period = lp->pdata->period_ns;
+ unsigned int period = lp->period_ns;
unsigned int duty = br * period / max_br;
struct pwm_device *pwm;
@@ -320,16 +324,15 @@ static int lp855x_backlight_register(struct lp855x *lp)
{
struct backlight_device *bl;
struct backlight_properties props;
- struct lp855x_platform_data *pdata = lp->pdata;
- const char *name = pdata->name ? : DEFAULT_BL_NAME;
+ const char *name = lp->blname ? : DEFAULT_BL_NAME;
props.type = BACKLIGHT_PLATFORM;
props.max_brightness = MAX_BRIGHTNESS;
- if (pdata->initial_brightness > props.max_brightness)
- pdata->initial_brightness = props.max_brightness;
+ if (lp->initial_brightness > props.max_brightness)
+ lp->initial_brightness = props.max_brightness;
- props.brightness = pdata->initial_brightness;
+ props.brightness = lp->initial_brightness;
bl = devm_backlight_device_register(lp->dev, name, lp->dev, lp,
&lp855x_bl_ops, &props);
@@ -381,7 +384,6 @@ static int lp855x_parse_dt(struct lp855x *lp)
{
struct device *dev = lp->dev;
struct device_node *node = dev->of_node;
- struct lp855x_platform_data *pdata;
int rom_length;
if (!node) {
@@ -389,14 +391,10 @@ static int lp855x_parse_dt(struct lp855x *lp)
return -EINVAL;
}
- pdata = devm_kzalloc(dev, sizeof(*pdata), GFP_KERNEL);
- if (!pdata)
- return -ENOMEM;
-
- of_property_read_string(node, "bl-name", &pdata->name);
- of_property_read_u8(node, "dev-ctrl", &pdata->device_control);
- of_property_read_u8(node, "init-brt", &pdata->initial_brightness);
- of_property_read_u32(node, "pwm-period", &pdata->period_ns);
+ of_property_read_string(node, "bl-name", &lp->blname);
+ of_property_read_u8(node, "dev-ctrl", &lp->device_control);
+ of_property_read_u8(node, "init-brt", &lp->initial_brightness);
+ of_property_read_u32(node, "pwm-period", &lp->period_ns);
/* Fill ROM platform data if defined */
rom_length = of_get_child_count(node);
@@ -415,19 +413,16 @@ static int lp855x_parse_dt(struct lp855x *lp)
i++;
}
- pdata->size_program = rom_length;
- pdata->rom_data = &rom[0];
+ lp->size_program = rom_length;
+ lp->rom_data = &rom[0];
}
- pdata->supply = devm_regulator_get(dev, "power");
- if (IS_ERR(pdata->supply)) {
- if (PTR_ERR(pdata->supply) = -EPROBE_DEFER)
+ lp->supply = devm_regulator_get(dev, "power");
+ if (IS_ERR(lp->supply)) {
+ if (PTR_ERR(lp->supply) = -EPROBE_DEFER)
return -EPROBE_DEFER;
- pdata->supply = NULL;
}
- lp->pdata = pdata;
-
return 0;
}
#else
@@ -453,21 +448,18 @@ static int lp855x_probe(struct i2c_client *cl, const struct i2c_device_id *id)
lp->dev = &cl->dev;
lp->chipname = id->name;
lp->chip_id = id->driver_data;
- lp->pdata = dev_get_platdata(&cl->dev);
- if (!lp->pdata) {
- ret = lp855x_parse_dt(lp);
- if (ret < 0)
- return ret;
- }
+ ret = lp855x_parse_dt(lp);
+ if (ret < 0)
+ return ret;
- if (lp->pdata->period_ns > 0)
+ if (lp->period_ns > 0)
lp->mode = PWM_BASED;
else
lp->mode = REGISTER_BASED;
- if (lp->pdata->supply) {
- ret = regulator_enable(lp->pdata->supply);
+ if (lp->supply) {
+ ret = regulator_enable(lp->supply);
if (ret < 0) {
dev_err(&cl->dev, "failed to enable supply: %d\n", ret);
return ret;
@@ -505,8 +497,8 @@ static int lp855x_remove(struct i2c_client *cl)
lp->bl->props.brightness = 0;
backlight_update_status(lp->bl);
- if (lp->pdata->supply)
- regulator_disable(lp->pdata->supply);
+ if (lp->supply)
+ regulator_disable(lp->supply);
sysfs_remove_group(&lp->dev->kobj, &lp855x_attr_group);
return 0;
--
2.2.0.rc0.207.ga3a616c
^ permalink raw reply related
* [PATCH 2/4] backlight/lp855x: Remove platform_data header
From: Sean Paul @ 2014-12-05 18:44 UTC (permalink / raw)
To: linux-fbdev
No one uses lp855x platform data any longer, remove the header
and move its contents into the driver.
Signed-off-by: Sean Paul <seanpaul@chromium.org>
---
MAINTAINERS | 1 -
drivers/video/backlight/lp855x_bl.c | 37 +++++++++++++++++++++++++-
include/linux/platform_data/lp855x.h | 51 ------------------------------------
3 files changed, 36 insertions(+), 53 deletions(-)
delete mode 100644 include/linux/platform_data/lp855x.h
diff --git a/MAINTAINERS b/MAINTAINERS
index 3c64271..4896edb 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -9318,7 +9318,6 @@ M: Milo Kim <milo.kim@ti.com>
S: Maintained
F: Documentation/backlight/lp855x-driver.txt
F: drivers/video/backlight/lp855x_bl.c
-F: include/linux/platform_data/lp855x.h
TI LP8727 CHARGER DRIVER
M: Milo Kim <milo.kim@ti.com>
diff --git a/drivers/video/backlight/lp855x_bl.c b/drivers/video/backlight/lp855x_bl.c
index a26d3bb..d19b61c 100644
--- a/drivers/video/backlight/lp855x_bl.c
+++ b/drivers/video/backlight/lp855x_bl.c
@@ -15,7 +15,6 @@
#include <linux/backlight.h>
#include <linux/err.h>
#include <linux/of.h>
-#include <linux/platform_data/lp855x.h>
#include <linux/pwm.h>
#include <linux/regulator/consumer.h>
@@ -63,6 +62,42 @@ struct lp855x_device_config {
int (*post_init_device)(struct lp855x *);
};
+enum lp855x_chip_id {
+ LP8550,
+ LP8551,
+ LP8552,
+ LP8553,
+ LP8555,
+ LP8556,
+ LP8557,
+};
+
+struct lp855x_rom_data {
+ u8 addr;
+ u8 val;
+};
+
+/**
+ * struct lp855x_platform_data
+ * @name : Backlight driver name. If it is not defined, default name is set.
+ * @device_control : value of DEVICE CONTROL register
+ * @initial_brightness : initial value of backlight brightness
+ * @period_ns : platform specific pwm period value. unit is nano.
+ Only valid when mode is PWM_BASED.
+ * @size_program : total size of lp855x_rom_data
+ * @rom_data : list of new eeprom/eprom registers
+ * @supply : regulator that supplies 3V input
+ */
+struct lp855x_platform_data {
+ const char *name;
+ u8 device_control;
+ u8 initial_brightness;
+ unsigned int period_ns;
+ int size_program;
+ struct lp855x_rom_data *rom_data;
+ struct regulator *supply;
+};
+
struct lp855x {
const char *chipname;
enum lp855x_chip_id chip_id;
diff --git a/include/linux/platform_data/lp855x.h b/include/linux/platform_data/lp855x.h
deleted file mode 100644
index 9e3ac3c..0000000
--- a/include/linux/platform_data/lp855x.h
+++ /dev/null
@@ -1,51 +0,0 @@
-/*
- * LP855x Backlight Driver
- *
- * Copyright (C) 2011 Texas Instruments
- *
- * This program is free software; you can redistribute it and/or modify
- * it under the terms of the GNU General Public License version 2 as
- * published by the Free Software Foundation.
- *
- */
-
-#ifndef _LP855X_H
-#define _LP855X_H
-
-enum lp855x_chip_id {
- LP8550,
- LP8551,
- LP8552,
- LP8553,
- LP8555,
- LP8556,
- LP8557,
-};
-
-struct lp855x_rom_data {
- u8 addr;
- u8 val;
-};
-
-/**
- * struct lp855x_platform_data
- * @name : Backlight driver name. If it is not defined, default name is set.
- * @device_control : value of DEVICE CONTROL register
- * @initial_brightness : initial value of backlight brightness
- * @period_ns : platform specific pwm period value. unit is nano.
- Only valid when mode is PWM_BASED.
- * @size_program : total size of lp855x_rom_data
- * @rom_data : list of new eeprom/eprom registers
- * @supply : regulator that supplies 3V input
- */
-struct lp855x_platform_data {
- const char *name;
- u8 device_control;
- u8 initial_brightness;
- unsigned int period_ns;
- int size_program;
- struct lp855x_rom_data *rom_data;
- struct regulator *supply;
-};
-
-#endif
--
2.2.0.rc0.207.ga3a616c
^ permalink raw reply related
* [PATCH 1/4] backlight/lp855x: Remove stale code from lp855x.h
From: Sean Paul @ 2014-12-05 18:44 UTC (permalink / raw)
To: linux-fbdev
These aren't used by anyone, remove them.
Signed-off-by: Sean Paul <seanpaul@chromium.org>
---
include/linux/platform_data/lp855x.h | 100 -----------------------------------
1 file changed, 100 deletions(-)
diff --git a/include/linux/platform_data/lp855x.h b/include/linux/platform_data/lp855x.h
index 9c7fd1e..9e3ac3c 100644
--- a/include/linux/platform_data/lp855x.h
+++ b/include/linux/platform_data/lp855x.h
@@ -12,65 +12,6 @@
#ifndef _LP855X_H
#define _LP855X_H
-#define BL_CTL_SHFT (0)
-#define BRT_MODE_SHFT (1)
-#define BRT_MODE_MASK (0x06)
-
-/* Enable backlight. Only valid when BRT_MODE\x10(I2C only) */
-#define ENABLE_BL (1)
-#define DISABLE_BL (0)
-
-#define I2C_CONFIG(id) id ## _I2C_CONFIG
-#define PWM_CONFIG(id) id ## _PWM_CONFIG
-
-/* DEVICE CONTROL register - LP8550 */
-#define LP8550_PWM_CONFIG (LP8550_PWM_ONLY << BRT_MODE_SHFT)
-#define LP8550_I2C_CONFIG ((ENABLE_BL << BL_CTL_SHFT) | \
- (LP8550_I2C_ONLY << BRT_MODE_SHFT))
-
-/* DEVICE CONTROL register - LP8551 */
-#define LP8551_PWM_CONFIG LP8550_PWM_CONFIG
-#define LP8551_I2C_CONFIG LP8550_I2C_CONFIG
-
-/* DEVICE CONTROL register - LP8552 */
-#define LP8552_PWM_CONFIG LP8550_PWM_CONFIG
-#define LP8552_I2C_CONFIG LP8550_I2C_CONFIG
-
-/* DEVICE CONTROL register - LP8553 */
-#define LP8553_PWM_CONFIG LP8550_PWM_CONFIG
-#define LP8553_I2C_CONFIG LP8550_I2C_CONFIG
-
-/* CONFIG register - LP8555 */
-#define LP8555_PWM_STANDBY BIT(7)
-#define LP8555_PWM_FILTER BIT(6)
-#define LP8555_RELOAD_EPROM BIT(3) /* use it if EPROMs should be reset
- when the backlight turns on */
-#define LP8555_OFF_OPENLEDS BIT(2)
-#define LP8555_PWM_CONFIG LP8555_PWM_ONLY
-#define LP8555_I2C_CONFIG LP8555_I2C_ONLY
-#define LP8555_COMB1_CONFIG LP8555_COMBINED1
-#define LP8555_COMB2_CONFIG LP8555_COMBINED2
-
-/* DEVICE CONTROL register - LP8556 */
-#define LP8556_PWM_CONFIG (LP8556_PWM_ONLY << BRT_MODE_SHFT)
-#define LP8556_COMB1_CONFIG (LP8556_COMBINED1 << BRT_MODE_SHFT)
-#define LP8556_I2C_CONFIG ((ENABLE_BL << BL_CTL_SHFT) | \
- (LP8556_I2C_ONLY << BRT_MODE_SHFT))
-#define LP8556_COMB2_CONFIG (LP8556_COMBINED2 << BRT_MODE_SHFT)
-#define LP8556_FAST_CONFIG BIT(7) /* use it if EPROMs should be maintained
- when exiting the low power mode */
-
-/* CONFIG register - LP8557 */
-#define LP8557_PWM_STANDBY BIT(7)
-#define LP8557_PWM_FILTER BIT(6)
-#define LP8557_RELOAD_EPROM BIT(3) /* use it if EPROMs should be reset
- when the backlight turns on */
-#define LP8557_OFF_OPENLEDS BIT(2)
-#define LP8557_PWM_CONFIG LP8557_PWM_ONLY
-#define LP8557_I2C_CONFIG LP8557_I2C_ONLY
-#define LP8557_COMB1_CONFIG LP8557_COMBINED1
-#define LP8557_COMB2_CONFIG LP8557_COMBINED2
-
enum lp855x_chip_id {
LP8550,
LP8551,
@@ -81,47 +22,6 @@ enum lp855x_chip_id {
LP8557,
};
-enum lp8550_brighntess_source {
- LP8550_PWM_ONLY,
- LP8550_I2C_ONLY = 2,
-};
-
-enum lp8551_brighntess_source {
- LP8551_PWM_ONLY = LP8550_PWM_ONLY,
- LP8551_I2C_ONLY = LP8550_I2C_ONLY,
-};
-
-enum lp8552_brighntess_source {
- LP8552_PWM_ONLY = LP8550_PWM_ONLY,
- LP8552_I2C_ONLY = LP8550_I2C_ONLY,
-};
-
-enum lp8553_brighntess_source {
- LP8553_PWM_ONLY = LP8550_PWM_ONLY,
- LP8553_I2C_ONLY = LP8550_I2C_ONLY,
-};
-
-enum lp8555_brightness_source {
- LP8555_PWM_ONLY,
- LP8555_I2C_ONLY,
- LP8555_COMBINED1, /* Brightness register with shaped PWM */
- LP8555_COMBINED2, /* PWM with shaped brightness register */
-};
-
-enum lp8556_brightness_source {
- LP8556_PWM_ONLY,
- LP8556_COMBINED1, /* pwm + i2c before the shaper block */
- LP8556_I2C_ONLY,
- LP8556_COMBINED2, /* pwm + i2c after the shaper block */
-};
-
-enum lp8557_brightness_source {
- LP8557_PWM_ONLY,
- LP8557_I2C_ONLY,
- LP8557_COMBINED1, /* pwm + i2c after the shaper block */
- LP8557_COMBINED2, /* pwm + i2c before the shaper block */
-};
-
struct lp855x_rom_data {
u8 addr;
u8 val;
--
2.2.0.rc0.207.ga3a616c
^ permalink raw reply related
* Re: [PATCH 3/3] video: fbdev: Validate mode timing against monspec
From: Tomi Valkeinen @ 2014-12-05 12:22 UTC (permalink / raw)
To: linux-fbdev
In-Reply-To: <1417643369-20603-3-git-send-email-davidu@nvidia.com>
[-- Attachment #1: Type: text/plain, Size: 1366 bytes --]
On 03/12/14 23:49, David Ung wrote:
> fbmon may generate mode timings that are out of spec of the monitor.
> eg DELL U2410 has a max clock 170mhz but advertises a resolutions of
> 1920x1200@60 in its Standard Timings, fbmon creates a mode using the
> GTF timing calculation which gave it a 193mhz clock.
The above is not exactly true with the previous patches, as fbmon
doesn't calculate it with GTF, but looks it up from the DMT table.
I have to say it's quite odd that the monitor advertises a mode it
cannot display...
> This patch checks to see if the mode can be supported by the monitor
> by comparing against monspecs.dclkmax.
I don't know about this patch... It looks a bit messy, and only handles
a too high clock in the get_std_timing. We could as well get bad timing
from get_est_timing() or somewhere else.
And I don't know if get_std_timing() should even do such filtering in
the first place. I'd say it's supposed to return the mode from the EDID
block. Whether the monitor or the device actually supports the mode is a
separate thing.
Also, generally speaking, while I have no objection in fixing bugs in
fbdev, I'd wish everyone just moved to DRM if at all possible. So if
this starts turning into a bigger change, with possibilities for
regressions, we have to consider if the fix is important enough.
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* Re: [PATCH 2/3] video: fbdev: Check Standard Timing against DMT
From: Tomi Valkeinen @ 2014-12-05 12:02 UTC (permalink / raw)
To: linux-fbdev
In-Reply-To: <1417643369-20603-2-git-send-email-davidu@nvidia.com>
[-- Attachment #1: Type: text/plain, Size: 2100 bytes --]
On 03/12/14 23:49, David Ung wrote:
> Add the VESA Display Monitor Timing (DMT) table.
> During parsing of Standard Timings, it compare the 2 byte STD code
> with DMT to see what the VESA mode should be. If there is no entry
> in the vesa_modes table or no match found, it fallsback to the
> GTF timings.
>
> Signed-off-by: David Ung <davidu@nvidia.com>
> ---
> drivers/video/fbdev/core/fbmon.c | 20 ++++++----
> drivers/video/fbdev/core/modedb.c | 84 +++++++++++++++++++++++++++++++++++++++
> include/linux/fb.h | 10 +++++
> 3 files changed, 107 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/video/fbdev/core/fbmon.c b/drivers/video/fbdev/core/fbmon.c
> index 5b0e313..aa1110a 100644
> --- a/drivers/video/fbdev/core/fbmon.c
> +++ b/drivers/video/fbdev/core/fbmon.c
> @@ -526,16 +526,22 @@ static int get_std_timing(unsigned char *block, struct fb_videomode *mode,
> refresh = (block[1] & 0x3f) + 60;
>
> DPRINTK(" %dx%d@%dHz\n", xres, yres, refresh);
> - for (i = 0; i < VESA_MODEDB_SIZE; i++) {
> - if (vesa_modes[i].xres == xres &&
> - vesa_modes[i].yres == yres &&
> - vesa_modes[i].refresh == refresh) {
> - *mode = vesa_modes[i];
> + for (i = 0; i < DMT_SIZE; i++) {
> + u32 std_2byte_code = block[0] << 8 | block[1];
> +
> + if (std_2byte_code == dmt_modes[i].std_2byte_code) {
> + if (!dmt_modes[i].mode)
> + break;
> + *mode = *dmt_modes[i].mode;
> mode->flag |= FB_MODE_IS_STANDARD;
> - return 1;
> + DPRINTK(" DMT id=%d\n", dmt_modes[i].dmt_id);
> + break;
> }
> }
> - calc_mode_timings(xres, yres, refresh, mode);
> +
> + if (i == DMT_SIZE || !dmt_modes[i].mode)
> + calc_mode_timings(xres, yres, refresh, mode);
> +
> return 1;
> }
I think this could be made a bit cleaner.
The xres/yres/refresh calculation in get_std_timing doesn't matter for
the DMT code above. So in get_std_timing() you could first do the search
for the DMT mode, and if found, return from the function. After that the
code would do the GTF calculation.
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* Re: [PATCH 2/3] video: fbdev: Check Standard Timing against DMT
From: Tomi Valkeinen @ 2014-12-05 11:41 UTC (permalink / raw)
To: linux-fbdev
In-Reply-To: <1417643369-20603-2-git-send-email-davidu@nvidia.com>
[-- Attachment #1: Type: text/plain, Size: 1919 bytes --]
On 05/12/14 06:08, David Ung wrote:
>>> diff --git a/drivers/video/fbdev/core/modedb.c
>>> b/drivers/video/fbdev/core/modedb.c
>>> index 0b57c1df..858a97e 100644
>>> --- a/drivers/video/fbdev/core/modedb.c
>>> +++ b/drivers/video/fbdev/core/modedb.c
>>> @@ -497,6 +497,90 @@ const struct fb_videomode vesa_modes[] = {
>>> FB_SYNC_HOR_HIGH_ACT, FB_VMODE_NONINTERLACED,
>> FB_MODE_IS_VESA },
>>> }; EXPORT_SYMBOL(vesa_modes);
>>> +
>>> +const struct dmt_videomode dmt_modes[DMT_SIZE] = {
>>> + { 0x01, 0x0000, 0x000000, &vesa_modes[0] },
>>> + { 0x02, 0x3119, 0x000000, &vesa_modes[1] },
>>> + { 0x03, 0x0000, 0x000000, &vesa_modes[2] },
>>> + { 0x04, 0x3140, 0x000000, &vesa_modes[3] },
>>> + { 0x05, 0x314c, 0x000000, &vesa_modes[4] },
>>> + { 0x06, 0x314f, 0x000000, &vesa_modes[5] },
>>> + { 0x07, 0x3159, 0x000000, &vesa_modes[6] },
>>> + { 0x08, 0x0000, 0x000000, &vesa_modes[7] },
>>> + { 0x09, 0x4540, 0x000000, &vesa_modes[8] },
>>> + { 0x0a, 0x454c, 0x000000, &vesa_modes[9] },
>>> + { 0x0b, 0x454f, 0x000000, &vesa_modes[10] },
>>> + { 0x0c, 0x4559, 0x000000, &vesa_modes[11] },
>>> + { 0x0d, 0x0000, 0x000000, 0 },
>>> + { 0x0e, 0x0000, 0x000000, 0 },
>>
>> You've filled only some of the modes in this table. What's the logic which
>> modes are left out?
>>
>
> For DMT id 0xd, it has no STD 2byte id, no 3byte CVT code and no mode timings
> currently defined in vesa_modes struct.
> There is 80 DMT ids, but only 43 vesa_modes defined in fbdev. So I've left those
> entries empty. If we eventually have all the VESA timings, the last column could
> be eliminated.
Ok. So you added the modes to vesa_modes table that you were interested
in for your use case, and then filled the dmt_modes table with the modes
that were available in vesa_modes?
That's ok, I just want to understand the logic for which modes you added
and which you left out.
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* [PATCH] video: ocfb: Fix data type warning
From: Qiang Chen @ 2014-12-05 8:18 UTC (permalink / raw)
To: Jean-Christophe Plagniol-Villard, Tomi Valkeinen, Jingoo Han,
Daniel Vetter, Laurent Pinchart, Stefan Kristiansson
Cc: linux-fbdev, linux-kernel, Qiang Chen
When allocate framebuffer memory using dma_alloc_coherent(),
we'd better use dma_addr_t instead of phys_addr_t. Because the
address we got in fact is DMA or bus address for the platform.
This patch also fixes below build warning:
drivers/video/fbdev/ocfb.c:335:2:
warning: passing argument 3 of ‘dma_alloc_attrs’
from incompatible pointer type [enabled by default]
Signed-off-by: Qiang Chen <qiang2.chen@sonymobile.com>
---
drivers/video/fbdev/ocfb.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/video/fbdev/ocfb.c b/drivers/video/fbdev/ocfb.c
index 7f9dc9b..de98196 100644
--- a/drivers/video/fbdev/ocfb.c
+++ b/drivers/video/fbdev/ocfb.c
@@ -61,7 +61,7 @@ struct ocfb_dev {
/* flag indicating whether the regs are little endian accessed */
int little_endian;
/* Physical and virtual addresses of framebuffer */
- phys_addr_t fb_phys;
+ dma_addr_t fb_phys;
void __iomem *fb_virt;
u32 pseudo_palette[PALETTE_SIZE];
};
--
1.8.2.2
^ permalink raw reply related
* RE: [PATCH 2/3] video: fbdev: Check Standard Timing against DMT
From: David Ung @ 2014-12-05 4:08 UTC (permalink / raw)
To: linux-fbdev
In-Reply-To: <1417643369-20603-2-git-send-email-davidu@nvidia.com>
> > diff --git a/drivers/video/fbdev/core/modedb.c
> > b/drivers/video/fbdev/core/modedb.c
> > index 0b57c1df..858a97e 100644
> > --- a/drivers/video/fbdev/core/modedb.c
> > +++ b/drivers/video/fbdev/core/modedb.c
> > @@ -497,6 +497,90 @@ const struct fb_videomode vesa_modes[] = {
> > FB_SYNC_HOR_HIGH_ACT, FB_VMODE_NONINTERLACED,
> FB_MODE_IS_VESA },
> > }; EXPORT_SYMBOL(vesa_modes);
> > +
> > +const struct dmt_videomode dmt_modes[DMT_SIZE] = {
> > + { 0x01, 0x0000, 0x000000, &vesa_modes[0] },
> > + { 0x02, 0x3119, 0x000000, &vesa_modes[1] },
> > + { 0x03, 0x0000, 0x000000, &vesa_modes[2] },
> > + { 0x04, 0x3140, 0x000000, &vesa_modes[3] },
> > + { 0x05, 0x314c, 0x000000, &vesa_modes[4] },
> > + { 0x06, 0x314f, 0x000000, &vesa_modes[5] },
> > + { 0x07, 0x3159, 0x000000, &vesa_modes[6] },
> > + { 0x08, 0x0000, 0x000000, &vesa_modes[7] },
> > + { 0x09, 0x4540, 0x000000, &vesa_modes[8] },
> > + { 0x0a, 0x454c, 0x000000, &vesa_modes[9] },
> > + { 0x0b, 0x454f, 0x000000, &vesa_modes[10] },
> > + { 0x0c, 0x4559, 0x000000, &vesa_modes[11] },
> > + { 0x0d, 0x0000, 0x000000, 0 },
> > + { 0x0e, 0x0000, 0x000000, 0 },
>
> You've filled only some of the modes in this table. What's the logic which
> modes are left out?
>
For DMT id 0xd, it has no STD 2byte id, no 3byte CVT code and no mode timings
currently defined in vesa_modes struct.
There is 80 DMT ids, but only 43 vesa_modes defined in fbdev. So I've left those
entries empty. If we eventually have all the VESA timings, the last column could
be eliminated.
David
-----------------------------------------------------------------------------------
This email message is for the sole use of the intended recipient(s) and may contain
confidential information. Any unauthorized review, use, disclosure or distribution
is prohibited. If you are not the intended recipient, please contact the sender by
reply email and destroy all copies of the original message.
-----------------------------------------------------------------------------------
^ permalink raw reply
* RE: [PATCH 1/3] video: fbdev: Add additional vesa modes
From: David Ung @ 2014-12-05 3:54 UTC (permalink / raw)
To: linux-fbdev
In-Reply-To: <1417643369-20603-1-git-send-email-davidu@nvidia.com>
> On 03/12/14 23:49, David Ung wrote:
> > Add high resolution modes to vesa_modes struct.
> >
> > Signed-off-by: David Ung <davidu@nvidia.com>
> > ---
> > drivers/video/fbdev/core/modedb.c | 27 +++++++++++++++++++++++++++
> > include/linux/fb.h | 2 +-
> > 2 files changed, 28 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/video/fbdev/core/modedb.c
> > b/drivers/video/fbdev/core/modedb.c
> > index 388f797..0b57c1df 100644
> > --- a/drivers/video/fbdev/core/modedb.c
> > +++ b/drivers/video/fbdev/core/modedb.c
> > @@ -468,6 +468,33 @@ const struct fb_videomode vesa_modes[] = {
> > /* 33 1920x1440-75 VESA */
> > { NULL, 75, 1920, 1440, 3367, 352, 144, 56, 1, 224, 3,
> > FB_SYNC_VERT_HIGH_ACT, FB_VMODE_NONINTERLACED,
> FB_MODE_IS_VESA },
> > + /* 34 1920x1200-60 RB VESA */
> > + { NULL, 60, 1920, 1200, 6493, 80, 48, 26, 3, 32, 6,
> > + FB_SYNC_VERT_HIGH_ACT, FB_VMODE_NONINTERLACED,
> FB_MODE_IS_VESA },
> > + /* 35 1920x1200-60 VESA */
> > + { NULL, 60, 1920, 1200, 5174, 336, 136, 36, 3, 200, 6,
> > + FB_SYNC_VERT_HIGH_ACT, FB_VMODE_NONINTERLACED,
> FB_MODE_IS_VESA },
> > + /* 36 1920x1200-75 VESA */
> > + { NULL, 75, 1920, 1200, 4077, 344, 136, 46, 3, 208, 6,
> > + FB_SYNC_VERT_HIGH_ACT, FB_VMODE_NONINTERLACED,
> FB_MODE_IS_VESA },
> > + /* 37 1920x1200-85 VESA */
> > + { NULL, 85, 1920, 1200, 3555, 352, 144, 53, 3, 208, 6,
> > + FB_SYNC_VERT_HIGH_ACT, FB_VMODE_NONINTERLACED,
> FB_MODE_IS_VESA },
> > + /* 38 2560x1600-60 RB VESA */
> > + { NULL, 60, 2560, 1600, 3724, 80, 48, 37, 3, 32, 6,
> > + FB_SYNC_HOR_HIGH_ACT, FB_VMODE_NONINTERLACED,
> FB_MODE_IS_VESA },
> > + /* 39 2560x1600-60 VESA */
> > + { NULL, 60, 2560, 1600, 2869, 472, 192, 49, 3, 280, 6,
> > + FB_SYNC_VERT_HIGH_ACT, FB_VMODE_NONINTERLACED,
> FB_MODE_IS_VESA },
> > + /* 40 2560x1600-75 VESA */
> > + { NULL, 75, 2560, 1600, 2256, 488, 208, 63, 3, 280, 6,
> > + FB_SYNC_VERT_HIGH_ACT, FB_VMODE_NONINTERLACED,
> FB_MODE_IS_VESA },
> > + /* 41 2560x1600-85 VESA */
> > + { NULL, 85, 2560, 1600, 1979, 488, 208, 73, 3, 280, 6,
> > + FB_SYNC_VERT_HIGH_ACT, FB_VMODE_NONINTERLACED,
> FB_MODE_IS_VESA },
> > + /* 42 2560x1600-120 RB VESA */
> > + { NULL, 120, 2560, 1600, 1809, 80, 48, 85, 3, 32, 6,
> > + FB_SYNC_HOR_HIGH_ACT, FB_VMODE_NONINTERLACED,
> FB_MODE_IS_VESA },
>
> Where did you take these timings? Are the modes in vesa_modes[] in some
> defined order, or just in the order they have been added?
From the DMT doc. In the doc, the VESA modes are ordered by the DMT ids per page.
Each DMT mode is a valid vesa_mode. vesa_modes are just a collection of modes
people had added over time. There are quite a few modes that's missing from
vesa_modes list. Ideally the number of vesa_modes should match the number of
DMT ids. If we wish to change the ordering, then some of the other drivers which
hardcodes the an index into vesa_modes will all need to be fixed.
David
-----------------------------------------------------------------------------------
This email message is for the sole use of the intended recipient(s) and may contain
confidential information. Any unauthorized review, use, disclosure or distribution
is prohibited. If you are not the intended recipient, please contact the sender by
reply email and destroy all copies of the original message.
-----------------------------------------------------------------------------------
^ permalink raw reply
* Re: [PATCH 2/3] video: fbdev: Check Standard Timing against DMT
From: Tomi Valkeinen @ 2014-12-04 15:41 UTC (permalink / raw)
To: linux-fbdev
In-Reply-To: <1417643369-20603-2-git-send-email-davidu@nvidia.com>
[-- Attachment #1: Type: text/plain, Size: 3006 bytes --]
On 03/12/14 23:49, David Ung wrote:
> Add the VESA Display Monitor Timing (DMT) table.
> During parsing of Standard Timings, it compare the 2 byte STD code
> with DMT to see what the VESA mode should be. If there is no entry
> in the vesa_modes table or no match found, it fallsback to the
> GTF timings.
>
> Signed-off-by: David Ung <davidu@nvidia.com>
> ---
> drivers/video/fbdev/core/fbmon.c | 20 ++++++----
> drivers/video/fbdev/core/modedb.c | 84 +++++++++++++++++++++++++++++++++++++++
> include/linux/fb.h | 10 +++++
> 3 files changed, 107 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/video/fbdev/core/fbmon.c b/drivers/video/fbdev/core/fbmon.c
> index 5b0e313..aa1110a 100644
> --- a/drivers/video/fbdev/core/fbmon.c
> +++ b/drivers/video/fbdev/core/fbmon.c
> @@ -526,16 +526,22 @@ static int get_std_timing(unsigned char *block, struct fb_videomode *mode,
> refresh = (block[1] & 0x3f) + 60;
>
> DPRINTK(" %dx%d@%dHz\n", xres, yres, refresh);
> - for (i = 0; i < VESA_MODEDB_SIZE; i++) {
> - if (vesa_modes[i].xres == xres &&
> - vesa_modes[i].yres == yres &&
> - vesa_modes[i].refresh == refresh) {
> - *mode = vesa_modes[i];
> + for (i = 0; i < DMT_SIZE; i++) {
> + u32 std_2byte_code = block[0] << 8 | block[1];
> +
> + if (std_2byte_code == dmt_modes[i].std_2byte_code) {
> + if (!dmt_modes[i].mode)
> + break;
> + *mode = *dmt_modes[i].mode;
> mode->flag |= FB_MODE_IS_STANDARD;
> - return 1;
> + DPRINTK(" DMT id=%d\n", dmt_modes[i].dmt_id);
> + break;
> }
> }
> - calc_mode_timings(xres, yres, refresh, mode);
> +
> + if (i == DMT_SIZE || !dmt_modes[i].mode)
> + calc_mode_timings(xres, yres, refresh, mode);
> +
> return 1;
> }
>
> diff --git a/drivers/video/fbdev/core/modedb.c b/drivers/video/fbdev/core/modedb.c
> index 0b57c1df..858a97e 100644
> --- a/drivers/video/fbdev/core/modedb.c
> +++ b/drivers/video/fbdev/core/modedb.c
> @@ -497,6 +497,90 @@ const struct fb_videomode vesa_modes[] = {
> FB_SYNC_HOR_HIGH_ACT, FB_VMODE_NONINTERLACED, FB_MODE_IS_VESA },
> };
> EXPORT_SYMBOL(vesa_modes);
> +
> +const struct dmt_videomode dmt_modes[DMT_SIZE] = {
> + { 0x01, 0x0000, 0x000000, &vesa_modes[0] },
> + { 0x02, 0x3119, 0x000000, &vesa_modes[1] },
> + { 0x03, 0x0000, 0x000000, &vesa_modes[2] },
> + { 0x04, 0x3140, 0x000000, &vesa_modes[3] },
> + { 0x05, 0x314c, 0x000000, &vesa_modes[4] },
> + { 0x06, 0x314f, 0x000000, &vesa_modes[5] },
> + { 0x07, 0x3159, 0x000000, &vesa_modes[6] },
> + { 0x08, 0x0000, 0x000000, &vesa_modes[7] },
> + { 0x09, 0x4540, 0x000000, &vesa_modes[8] },
> + { 0x0a, 0x454c, 0x000000, &vesa_modes[9] },
> + { 0x0b, 0x454f, 0x000000, &vesa_modes[10] },
> + { 0x0c, 0x4559, 0x000000, &vesa_modes[11] },
> + { 0x0d, 0x0000, 0x000000, 0 },
> + { 0x0e, 0x0000, 0x000000, 0 },
You've filled only some of the modes in this table. What's the logic
which modes are left out?
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* Re: [PATCH 3/3] arm: boot: dts: am437x-sk: fix lcd enable pin mux data
From: Felipe Balbi @ 2014-12-04 15:05 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20141204144325.GA17269@saruman>
[-- Attachment #1: Type: text/plain, Size: 1578 bytes --]
On Thu, Dec 04, 2014 at 08:43:25AM -0600, Felipe Balbi wrote:
> HI,
>
> On Wed, Oct 15, 2014 at 03:24:20PM +0300, Tomi Valkeinen wrote:
> > On 14/10/14 21:28, Felipe Balbi wrote:
> > > Caused by a copy & paste error. Note that even with
> > > this bug AM437x SK display still works because GPIO
> > > mux mode is always enabled. It's still wrong to mux
> > > somebody else's pin.
> > >
> > > Luckily ball D25 (offset 0x238 - gpio5_8) on AM437x
> > > isn't used for anything.
> > >
> > > Signed-off-by: Felipe Balbi <balbi@ti.com>
> > > ---
> > > arch/arm/boot/dts/am437x-sk-evm.dts | 3 +--
> > > 1 file changed, 1 insertion(+), 2 deletions(-)
> > >
> > > diff --git a/arch/arm/boot/dts/am437x-sk-evm.dts b/arch/arm/boot/dts/am437x-sk-evm.dts
> > > index 859ff3d..681be00 100644
> > > --- a/arch/arm/boot/dts/am437x-sk-evm.dts
> > > +++ b/arch/arm/boot/dts/am437x-sk-evm.dts
> > > @@ -320,8 +320,7 @@
> > >
> > > lcd_pins: lcd_pins {
> > > pinctrl-single,pins = <
> > > - /* GPIO 5_8 to select LCD / HDMI */
> > > - 0x238 (PIN_OUTPUT_PULLUP | MUX_MODE7)
> > > + 0x1c (PIN_OUTPUT_PULLUP | MUX_MODE7) /* gpcm_ad7.gpio1_7 */
> > > >;
> > > };
> > > };
> >
> > I didn't verify the offset, but based on the comments this looks fine to me.
> >
> > Acked-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
>
> Tony, are you taking this patch ? Looks like it has been forgotten and
> now it needs to be backported to v3.17 and v3.18 (assuming it's too late
> for v3.18).
I'll send a new version and Cc stable.
--
balbi
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* Re: [PATCH 1/3] video: fbdev: Add additional vesa modes
From: Tomi Valkeinen @ 2014-12-04 14:53 UTC (permalink / raw)
To: linux-fbdev
In-Reply-To: <1417643369-20603-1-git-send-email-davidu@nvidia.com>
[-- Attachment #1: Type: text/plain, Size: 2391 bytes --]
On 03/12/14 23:49, David Ung wrote:
> Add high resolution modes to vesa_modes struct.
>
> Signed-off-by: David Ung <davidu@nvidia.com>
> ---
> drivers/video/fbdev/core/modedb.c | 27 +++++++++++++++++++++++++++
> include/linux/fb.h | 2 +-
> 2 files changed, 28 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/video/fbdev/core/modedb.c b/drivers/video/fbdev/core/modedb.c
> index 388f797..0b57c1df 100644
> --- a/drivers/video/fbdev/core/modedb.c
> +++ b/drivers/video/fbdev/core/modedb.c
> @@ -468,6 +468,33 @@ const struct fb_videomode vesa_modes[] = {
> /* 33 1920x1440-75 VESA */
> { NULL, 75, 1920, 1440, 3367, 352, 144, 56, 1, 224, 3,
> FB_SYNC_VERT_HIGH_ACT, FB_VMODE_NONINTERLACED, FB_MODE_IS_VESA },
> + /* 34 1920x1200-60 RB VESA */
> + { NULL, 60, 1920, 1200, 6493, 80, 48, 26, 3, 32, 6,
> + FB_SYNC_VERT_HIGH_ACT, FB_VMODE_NONINTERLACED, FB_MODE_IS_VESA },
> + /* 35 1920x1200-60 VESA */
> + { NULL, 60, 1920, 1200, 5174, 336, 136, 36, 3, 200, 6,
> + FB_SYNC_VERT_HIGH_ACT, FB_VMODE_NONINTERLACED, FB_MODE_IS_VESA },
> + /* 36 1920x1200-75 VESA */
> + { NULL, 75, 1920, 1200, 4077, 344, 136, 46, 3, 208, 6,
> + FB_SYNC_VERT_HIGH_ACT, FB_VMODE_NONINTERLACED, FB_MODE_IS_VESA },
> + /* 37 1920x1200-85 VESA */
> + { NULL, 85, 1920, 1200, 3555, 352, 144, 53, 3, 208, 6,
> + FB_SYNC_VERT_HIGH_ACT, FB_VMODE_NONINTERLACED, FB_MODE_IS_VESA },
> + /* 38 2560x1600-60 RB VESA */
> + { NULL, 60, 2560, 1600, 3724, 80, 48, 37, 3, 32, 6,
> + FB_SYNC_HOR_HIGH_ACT, FB_VMODE_NONINTERLACED, FB_MODE_IS_VESA },
> + /* 39 2560x1600-60 VESA */
> + { NULL, 60, 2560, 1600, 2869, 472, 192, 49, 3, 280, 6,
> + FB_SYNC_VERT_HIGH_ACT, FB_VMODE_NONINTERLACED, FB_MODE_IS_VESA },
> + /* 40 2560x1600-75 VESA */
> + { NULL, 75, 2560, 1600, 2256, 488, 208, 63, 3, 280, 6,
> + FB_SYNC_VERT_HIGH_ACT, FB_VMODE_NONINTERLACED, FB_MODE_IS_VESA },
> + /* 41 2560x1600-85 VESA */
> + { NULL, 85, 2560, 1600, 1979, 488, 208, 73, 3, 280, 6,
> + FB_SYNC_VERT_HIGH_ACT, FB_VMODE_NONINTERLACED, FB_MODE_IS_VESA },
> + /* 42 2560x1600-120 RB VESA */
> + { NULL, 120, 2560, 1600, 1809, 80, 48, 85, 3, 32, 6,
> + FB_SYNC_HOR_HIGH_ACT, FB_VMODE_NONINTERLACED, FB_MODE_IS_VESA },
Where did you take these timings? Are the modes in vesa_modes[] in some
defined order, or just in the order they have been added?
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* Re: [PATCH 3/3] arm: boot: dts: am437x-sk: fix lcd enable pin mux data
From: Felipe Balbi @ 2014-12-04 14:43 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <543E6774.8000406@ti.com>
[-- Attachment #1: Type: text/plain, Size: 1395 bytes --]
HI,
On Wed, Oct 15, 2014 at 03:24:20PM +0300, Tomi Valkeinen wrote:
> On 14/10/14 21:28, Felipe Balbi wrote:
> > Caused by a copy & paste error. Note that even with
> > this bug AM437x SK display still works because GPIO
> > mux mode is always enabled. It's still wrong to mux
> > somebody else's pin.
> >
> > Luckily ball D25 (offset 0x238 - gpio5_8) on AM437x
> > isn't used for anything.
> >
> > Signed-off-by: Felipe Balbi <balbi@ti.com>
> > ---
> > arch/arm/boot/dts/am437x-sk-evm.dts | 3 +--
> > 1 file changed, 1 insertion(+), 2 deletions(-)
> >
> > diff --git a/arch/arm/boot/dts/am437x-sk-evm.dts b/arch/arm/boot/dts/am437x-sk-evm.dts
> > index 859ff3d..681be00 100644
> > --- a/arch/arm/boot/dts/am437x-sk-evm.dts
> > +++ b/arch/arm/boot/dts/am437x-sk-evm.dts
> > @@ -320,8 +320,7 @@
> >
> > lcd_pins: lcd_pins {
> > pinctrl-single,pins = <
> > - /* GPIO 5_8 to select LCD / HDMI */
> > - 0x238 (PIN_OUTPUT_PULLUP | MUX_MODE7)
> > + 0x1c (PIN_OUTPUT_PULLUP | MUX_MODE7) /* gpcm_ad7.gpio1_7 */
> > >;
> > };
> > };
>
> I didn't verify the offset, but based on the comments this looks fine to me.
>
> Acked-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Tony, are you taking this patch ? Looks like it has been forgotten and
now it needs to be backported to v3.17 and v3.18 (assuming it's too late
for v3.18).
--
balbi
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* Re: [PATCH 1/1] video: fbdev-LCDC: Deletion of an unnecessary check before the function call "vfree"
From: Tomi Valkeinen @ 2014-12-04 14:19 UTC (permalink / raw)
To: SF Markus Elfring, Jean-Christophe Plagniol-Villard, linux-fbdev
Cc: LKML, kernel-janitors, Julia Lawall
In-Reply-To: <5470B315.8000507@users.sourceforge.net>
[-- Attachment #1: Type: text/plain, Size: 1170 bytes --]
Hi,
On 22/11/14 18:00, SF Markus Elfring wrote:
> From: Markus Elfring <elfring@users.sourceforge.net>
> Date: Sat, 22 Nov 2014 16:51:31 +0100
>
> The vfree() function performs also input parameter validation.
> Thus the test around the call is not needed.
>
> This issue was detected by using the Coccinelle software.
>
> Signed-off-by: Markus Elfring <elfring@users.sourceforge.net>
> ---
> drivers/video/fbdev/sh_mobile_lcdcfb.c | 3 +--
> 1 file changed, 1 insertion(+), 2 deletions(-)
>
> diff --git a/drivers/video/fbdev/sh_mobile_lcdcfb.c b/drivers/video/fbdev/sh_mobile_lcdcfb.c
> index 2bcc84a..cfde21d 100644
> --- a/drivers/video/fbdev/sh_mobile_lcdcfb.c
> +++ b/drivers/video/fbdev/sh_mobile_lcdcfb.c
> @@ -2181,8 +2181,7 @@ sh_mobile_lcdc_channel_fb_cleanup(struct sh_mobile_lcdc_chan *ch)
> if (!info || !info->device)
> return;
>
> - if (ch->sglist)
> - vfree(ch->sglist);
> + vfree(ch->sglist);
>
> fb_dealloc_cmap(&info->cmap);
> framebuffer_release(info);
Thanks, I've applied the fbdev patches. Next time, please use
git-format-patch and git-send-email to send a proper patch series.
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* Re: [PATCH 1/3] video: fbdev: vt8623fb: suppress build warning
From: Tomi Valkeinen @ 2014-12-04 13:40 UTC (permalink / raw)
To: Geert Uytterhoeven, Prabhakar Lad
Cc: Sudip Mukherjee, Jean-Christophe Plagniol-Villard, LFBDEV, LKML
In-Reply-To: <CAMuHMdX6rbaPYFpSR7nGf6Di0G=cGL9yFZLLpjUDi7TLyu1wmw@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 2864 bytes --]
On 04/12/14 15:29, Geert Uytterhoeven wrote:
> On Thu, Dec 4, 2014 at 8:56 AM, Tomi Valkeinen <tomi.valkeinen@ti.com> wrote:
>> On 04/12/14 09:46, Sudip Mukherjee wrote:
>>> On Thu, Dec 04, 2014 at 09:05:46AM +0200, Tomi Valkeinen wrote:
>>>> On 03/12/14 20:29, Prabhakar Lad wrote:
>>>>> On Wed, Dec 3, 2014 at 11:49 AM, Tomi Valkeinen <tomi.valkeinen@ti.com> wrote:
>>>>>> On 27/11/14 00:07, Lad, Prabhakar wrote:
>>>>>>> this patch fixes following build warning:
>>>>>>> drivers/video/fbdev/vt8623fb.c: In function ‘vt8623_pci_probe’:
>>>>>>> drivers/video/fbdev/vt8623fb.c:734:23: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast]
>>>>>>> par->state.vgabase = (void __iomem *) vga_res.start;
>>>>>>> ^
>>>>>>> Signed-off-by: Lad, Prabhakar <prabhakar.csengg@gmail.com>
>>>>>>> ---
>>>>>>> drivers/video/fbdev/vt8623fb.c | 2 +-
>>>>>>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>>>>>>
>>>>>>> diff --git a/drivers/video/fbdev/vt8623fb.c b/drivers/video/fbdev/vt8623fb.c
>>>>>>> index 5c7cbc6..ea7f056 100644
>>>>>>> --- a/drivers/video/fbdev/vt8623fb.c
>>>>>>> +++ b/drivers/video/fbdev/vt8623fb.c
>>>>>>> @@ -731,7 +731,7 @@ static int vt8623_pci_probe(struct pci_dev *dev, const struct pci_device_id *id)
>>>>>>>
>>>>>>> pcibios_bus_to_resource(dev->bus, &vga_res, &bus_reg);
>>>>>>>
>>>>>>> - par->state.vgabase = (void __iomem *) vga_res.start;
>>>>>>> + par->state.vgabase = (void __iomem *) (unsigned long) vga_res.start;
>>>>>>
>>>>>> This does look quite ugly... Where does the warning come from in the
>>>>>> first place. Isn't vga_res.start (resource_size_t) the size of a pointer?
>>>>>>
>>>>> Yes looks ugly, I am not sure what you meant from 'where does this warning
>>>>> come from' its in the commit message.
>>>>
>>>> I meant why is there a warning at all. With a quick glance,
>>>> vga_res.start is the size of a pointer. So the sizes of the integer and
>>>> the pointer should be the same. But the warning still says "of different
>>>> size".
>>>
>>> poking my nose into your discussion.
>>> I tried to see the warning, and I re-compiled like make W=1 M=drivers/video/fbdev/ (before that make clean M=drivers/video/fbdev was done)
>>> I can see warning with many other files, but drivers/video/fbdev/vt8623fb.o was quiet and there was no warning.
>>> I tested with next=20141203.
>>> did i miss something in checking the warning ?
>>
>> I don't see the warning either when compiling for arm or x86_64. On what
>> architecture do you see the warning?
>
> On 32-bit systems with PHYS_ADDR_T_64BIT=y, resource_size_t is u64,
> while pointers are still 32-bit.
Ah, I see. Yes, I can reproduce the warning with that config.
So, still rather ugly, but looks correct to me, so I'll apply the series.
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* Re: [PATCH 1/3] video: fbdev: vt8623fb: suppress build warning
From: Geert Uytterhoeven @ 2014-12-04 13:29 UTC (permalink / raw)
To: Tomi Valkeinen
Cc: Prabhakar Lad, Sudip Mukherjee, Jean-Christophe Plagniol-Villard,
LFBDEV, LKML
In-Reply-To: <548013B0.4080108@ti.com>
On Thu, Dec 4, 2014 at 8:56 AM, Tomi Valkeinen <tomi.valkeinen@ti.com> wrote:
> On 04/12/14 09:46, Sudip Mukherjee wrote:
>> On Thu, Dec 04, 2014 at 09:05:46AM +0200, Tomi Valkeinen wrote:
>>> On 03/12/14 20:29, Prabhakar Lad wrote:
>>>> On Wed, Dec 3, 2014 at 11:49 AM, Tomi Valkeinen <tomi.valkeinen@ti.com> wrote:
>>>>> On 27/11/14 00:07, Lad, Prabhakar wrote:
>>>>>> this patch fixes following build warning:
>>>>>> drivers/video/fbdev/vt8623fb.c: In function ‘vt8623_pci_probe’:
>>>>>> drivers/video/fbdev/vt8623fb.c:734:23: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast]
>>>>>> par->state.vgabase = (void __iomem *) vga_res.start;
>>>>>> ^
>>>>>> Signed-off-by: Lad, Prabhakar <prabhakar.csengg@gmail.com>
>>>>>> ---
>>>>>> drivers/video/fbdev/vt8623fb.c | 2 +-
>>>>>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>>>>>
>>>>>> diff --git a/drivers/video/fbdev/vt8623fb.c b/drivers/video/fbdev/vt8623fb.c
>>>>>> index 5c7cbc6..ea7f056 100644
>>>>>> --- a/drivers/video/fbdev/vt8623fb.c
>>>>>> +++ b/drivers/video/fbdev/vt8623fb.c
>>>>>> @@ -731,7 +731,7 @@ static int vt8623_pci_probe(struct pci_dev *dev, const struct pci_device_id *id)
>>>>>>
>>>>>> pcibios_bus_to_resource(dev->bus, &vga_res, &bus_reg);
>>>>>>
>>>>>> - par->state.vgabase = (void __iomem *) vga_res.start;
>>>>>> + par->state.vgabase = (void __iomem *) (unsigned long) vga_res.start;
>>>>>
>>>>> This does look quite ugly... Where does the warning come from in the
>>>>> first place. Isn't vga_res.start (resource_size_t) the size of a pointer?
>>>>>
>>>> Yes looks ugly, I am not sure what you meant from 'where does this warning
>>>> come from' its in the commit message.
>>>
>>> I meant why is there a warning at all. With a quick glance,
>>> vga_res.start is the size of a pointer. So the sizes of the integer and
>>> the pointer should be the same. But the warning still says "of different
>>> size".
>>
>> poking my nose into your discussion.
>> I tried to see the warning, and I re-compiled like make W=1 M=drivers/video/fbdev/ (before that make clean M=drivers/video/fbdev was done)
>> I can see warning with many other files, but drivers/video/fbdev/vt8623fb.o was quiet and there was no warning.
>> I tested with next 141203.
>> did i miss something in checking the warning ?
>
> I don't see the warning either when compiling for arm or x86_64. On what
> architecture do you see the warning?
On 32-bit systems with PHYS_ADDR_T_64BIT=y, resource_size_t is u64,
while pointers are still 32-bit.
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
* RE: [PATCHv2 0/4] LS1021A: Add dcfb framebuffer driver support.
From: Li.Xiubo @ 2014-12-04 10:03 UTC (permalink / raw)
To: Tomi Valkeinen
Cc: Arnd Bergmann, plagnioj@jcrosoft.com, linux-fbdev@vger.kernel.org,
linux-kernel@vger.kernel.org, shawn.guo@linaro.org,
alexander.stein@systec-electronic.com
In-Reply-To: <5480308F.6070607@ti.com>
Hi Tomi,
Thanks very much for your help.
I will have a try these days.
BRs
Xiubo
> -----Original Message-----
> From: Tomi Valkeinen [mailto:tomi.valkeinen@ti.com]
> Sent: Thursday, December 04, 2014 6:00 PM
> To: Xiubo Li-B47053
> Cc: Arnd Bergmann; plagnioj@jcrosoft.com; linux-fbdev@vger.kernel.org; linux-
> kernel@vger.kernel.org; shawn.guo@linaro.org; alexander.stein@systec-
> electronic.com
> Subject: Re: [PATCHv2 0/4] LS1021A: Add dcfb framebuffer driver support.
>
> On 04/12/14 11:54, Li.Xiubo@freescale.com wrote:
> > Hi Tomi,
> >
> > Thanks for your information very much.
> >
> >>> Sorry for confusing, it was delayed for other reasons internal.
> >>>
> >>> I am not familiar about the DRM, and I'd like to know if the DRM driver
> will
> >> be
> >>> support, should I also develop the libdrm too ? Or just coding in kernel
> >> level ?
> >>
> >> For simple drm drivers (this looks like it would be a simple one), I
> >> don't think there's any need for libdrm support. The generic DRM
> >> interfaces should be enough, so just kernel level coding needed.
> >>
> >
> > That's to say, if I am using the X11 server without any code in usrspace,
> > If the DRM driver will support /dev/fbX, it could work correctly ?
>
> Yes. DRM offers helper code to add /dev/fbX with not too many lines. You
> can look at the docs and drm_fb_helper.c.
>
> And X11 should work fine on top of that, using the X11 fbdev support.
>
> Tomi
>
^ permalink raw reply
* Re: [PATCHv2 0/4] LS1021A: Add dcfb framebuffer driver support.
From: Tomi Valkeinen @ 2014-12-04 9:59 UTC (permalink / raw)
To: Li.Xiubo@freescale.com
Cc: Arnd Bergmann, plagnioj@jcrosoft.com, linux-fbdev@vger.kernel.org,
linux-kernel@vger.kernel.org, shawn.guo@linaro.org,
alexander.stein@systec-electronic.com
In-Reply-To: <BY2PR0301MB061372E00518F169BCF2FFFA9B780@BY2PR0301MB0613.namprd03.prod.outlook.com>
[-- Attachment #1: Type: text/plain, Size: 940 bytes --]
On 04/12/14 11:54, Li.Xiubo@freescale.com wrote:
> Hi Tomi,
>
> Thanks for your information very much.
>
>>> Sorry for confusing, it was delayed for other reasons internal.
>>>
>>> I am not familiar about the DRM, and I'd like to know if the DRM driver will
>> be
>>> support, should I also develop the libdrm too ? Or just coding in kernel
>> level ?
>>
>> For simple drm drivers (this looks like it would be a simple one), I
>> don't think there's any need for libdrm support. The generic DRM
>> interfaces should be enough, so just kernel level coding needed.
>>
>
> That's to say, if I am using the X11 server without any code in usrspace,
> If the DRM driver will support /dev/fbX, it could work correctly ?
Yes. DRM offers helper code to add /dev/fbX with not too many lines. You
can look at the docs and drm_fb_helper.c.
And X11 should work fine on top of that, using the X11 fbdev support.
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* RE: [PATCHv2 0/4] LS1021A: Add dcfb framebuffer driver support.
From: Li.Xiubo @ 2014-12-04 9:54 UTC (permalink / raw)
To: Tomi Valkeinen
Cc: Arnd Bergmann, plagnioj@jcrosoft.com, linux-fbdev@vger.kernel.org,
linux-kernel@vger.kernel.org, shawn.guo@linaro.org,
alexander.stein@systec-electronic.com
In-Reply-To: <548024C7.3060004@ti.com>
Hi Tomi,
Thanks for your information very much.
> > Sorry for confusing, it was delayed for other reasons internal.
> >
> > I am not familiar about the DRM, and I'd like to know if the DRM driver will
> be
> > support, should I also develop the libdrm too ? Or just coding in kernel
> level ?
>
> For simple drm drivers (this looks like it would be a simple one), I
> don't think there's any need for libdrm support. The generic DRM
> interfaces should be enough, so just kernel level coding needed.
>
That's to say, if I am using the X11 server without any code in usrspace,
If the DRM driver will support /dev/fbX, it could work correctly ?
Thanks,
BRs
Xiubo
^ permalink raw reply
* Re: [PATCHv2 1/4] video: fsl-dcfb: Add dcfb framebuffer driver for LS1021A platform
From: Alexander Stein @ 2014-12-04 9:21 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1417598162-40433-2-git-send-email-Li.Xiubo@freescale.com>
On Wednesday 03 December 2014 17:15:59, Xiubo Li wrote:
> + tnp = of_find_node_by_name(dnp, "display-timings");
> + if (!tnp) {
> + dev_err(dcfb->dev, "failed to find \"display-timings\" node\n");
> + return -ENODEV;
> + goto put_dnp;
> + }
> +
> + for (i = 0; i < of_get_child_count(tnp); i++) {
> + struct videomode vm;
> +
> + ret = videomode_from_timings(timings, &vm, i);
> + if (ret < 0)
> + goto put_tnp;
> +
> + ret = fb_videomode_from_videomode(&vm, &fb_vm);
> + if (ret < 0)
> + goto put_tnp;
> +
> + fb_add_videomode(&fb_vm, &info->modelist);
> + }
> +
> + ret = of_get_fb_videomode(dnp, &fb_vm, OF_USE_NATIVE_MODE);
> + if (ret)
> + goto put_dnp;
Souldn't this be put_tnp like in the loop above?
> + fb_videomode_to_var(&info->var, &fb_vm);
> + ret = fsl_dcfb_check_var(&info->var, info);
But picking the native mode per default looks nice to be! :)
Best regards,
Alexander
--
Dipl.-Inf. Alexander Stein
SYS TEC electronic GmbH
Am Windrad 2
08468 Heinsdorfergrund
Tel.: 03765 38600-1156
Fax: 03765 38600-4100
Email: alexander.stein@systec-electronic.com
Website: www.systec-electronic.com
Managing Director: Dipl.-Phys. Siegmar Schmidt
Commercial registry: Amtsgericht Chemnitz, HRB 28082
^ permalink raw reply
* Re: [PATCHv2 0/4] LS1021A: Add dcfb framebuffer driver support.
From: Tomi Valkeinen @ 2014-12-04 9:09 UTC (permalink / raw)
To: Li.Xiubo@freescale.com
Cc: Arnd Bergmann, plagnioj@jcrosoft.com, linux-fbdev@vger.kernel.org,
linux-kernel@vger.kernel.org, shawn.guo@linaro.org,
alexander.stein@systec-electronic.com
In-Reply-To: <BY2PR0301MB0613ABEA1410C04CF07C1C7C9B780@BY2PR0301MB0613.namprd03.prod.outlook.com>
[-- Attachment #1: Type: text/plain, Size: 1585 bytes --]
On 04/12/14 10:30, Li.Xiubo@freescale.com wrote:
> Sorry for confusing, it was delayed for other reasons internal.
>
> I am not familiar about the DRM, and I'd like to know if the DRM driver will be
> support, should I also develop the libdrm too ? Or just coding in kernel level ?
For simple drm drivers (this looks like it would be a simple one), I
don't think there's any need for libdrm support. The generic DRM
interfaces should be enough, so just kernel level coding needed.
> Is there any Document about how to have /dev/fbX device to use ?
There's DRM documentation here:
https://www.kernel.org/doc/htmldocs/drm/index.html
And many existing drivers to use as examples. The dri-devel list
(http://lists.freedesktop.org/mailman/listinfo/dri-devel), which is the
mailing list used for DRM development, is active and you probably can
get more support from there than from the fbdev list.
It should not be a huge effort to write a drm driver for a simple LCD
controller like this. I would bet that you can write a working driver in
a week.
> If possible, I'd like this could be accept for this time. And I will add the DRM
> Version later(for developing and testing will take a long time).
I'm sorry but "it was delayed for internal reasons" and "our customer
needs this driver" are not very good reasons for getting a driver merged
to mainline Linux.
You can provide your driver to your customer as a separate patch series
which they can apply. There should be no conflicts or other issues
there, so it should be simple.
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* RE: [PATCHv2 0/4] LS1021A: Add dcfb framebuffer driver support.
From: Li.Xiubo @ 2014-12-04 8:30 UTC (permalink / raw)
To: Tomi Valkeinen, Arnd Bergmann
Cc: plagnioj@jcrosoft.com, linux-fbdev@vger.kernel.org,
linux-kernel@vger.kernel.org, shawn.guo@linaro.org,
alexander.stein@systec-electronic.com
In-Reply-To: <548016D9.6030006@ti.com>
Hi Tomi,
> -----Original Message-----
> From: Tomi Valkeinen [mailto:tomi.valkeinen@ti.com]
> Sent: Thursday, December 04, 2014 4:10 PM
> To: Xiubo Li-B47053; Arnd Bergmann
> Cc: plagnioj@jcrosoft.com; linux-fbdev@vger.kernel.org; linux-
> kernel@vger.kernel.org; shawn.guo@linaro.org; alexander.stein@systec-
> electronic.com
> Subject: Re: [PATCHv2 0/4] LS1021A: Add dcfb framebuffer driver support.
>
> Hi Xiubo,
>
> On 04/12/14 03:56, Li.Xiubo@freescale.com wrote:
> > Hi Arnd,
> >
> > Thanks for you advice.
> >
> > Because this is very emergency for customers and have delayed for monthes,
> and the
> > DRM/KMS will have a little long time to be supported. So I'd like to add
> this first
> > and will add DRM/KMS version later.
>
> I would also suggest to just write a drm driver for this. I don't see
> anything special in this driver that would be better supported via
> fbdev. With drm you'll get a more modern framework, and you will still
> have the same /dev/fbX device to use for legacy userspace software.
>
> What do you mean with "delayed for months"? The first version of this
> series (that I can find) was posted less than two weeks ago.
>
Sorry for confusing, it was delayed for other reasons internal.
I am not familiar about the DRM, and I'd like to know if the DRM driver will be
support, should I also develop the libdrm too ? Or just coding in kernel level ?
Is there any Document about how to have /dev/fbX device to use ?
If possible, I'd like this could be accept for this time. And I will add the DRM
Version later(for developing and testing will take a long time).
Thanks very much,
BRs
Xiubo
> Tomi
>
^ permalink raw reply
* Re: [PATCHv2 0/4] LS1021A: Add dcfb framebuffer driver support.
From: Tomi Valkeinen @ 2014-12-04 8:10 UTC (permalink / raw)
To: Li.Xiubo@freescale.com, Arnd Bergmann
Cc: plagnioj@jcrosoft.com, linux-fbdev@vger.kernel.org,
linux-kernel@vger.kernel.org, shawn.guo@linaro.org,
alexander.stein@systec-electronic.com
In-Reply-To: <BY2PR0301MB06131C2C901351E8592ED3D89B780@BY2PR0301MB0613.namprd03.prod.outlook.com>
[-- Attachment #1: Type: text/plain, Size: 751 bytes --]
Hi Xiubo,
On 04/12/14 03:56, Li.Xiubo@freescale.com wrote:
> Hi Arnd,
>
> Thanks for you advice.
>
> Because this is very emergency for customers and have delayed for monthes, and the
> DRM/KMS will have a little long time to be supported. So I'd like to add this first
> and will add DRM/KMS version later.
I would also suggest to just write a drm driver for this. I don't see
anything special in this driver that would be better supported via
fbdev. With drm you'll get a more modern framework, and you will still
have the same /dev/fbX device to use for legacy userspace software.
What do you mean with "delayed for months"? The first version of this
series (that I can find) was posted less than two weeks ago.
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
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