* [PATCH 2/2] video: s3c-fb: Convert to devm style allocation
From: Mark Brown @ 2011-11-27 22:51 UTC (permalink / raw)
To: linux-fbdev
Saves some code, especially useful as the code saved is mostly in the
infrequently tested error paths.
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
---
drivers/video/s3c-fb.c | 32 +++++---------------------------
1 files changed, 5 insertions(+), 27 deletions(-)
diff --git a/drivers/video/s3c-fb.c b/drivers/video/s3c-fb.c
index 27971bc..c8e822b 100644
--- a/drivers/video/s3c-fb.c
+++ b/drivers/video/s3c-fb.c
@@ -186,7 +186,6 @@ struct s3c_fb_vsync {
* struct s3c_fb - overall hardware state of the hardware
* @slock: The spinlock protection for this data sturcture.
* @dev: The device that we bound to, for printing, etc.
- * @regs_res: The resource we claimed for the IO registers.
* @bus_clk: The clk (hclk) feeding our interface and possibly pixclk.
* @lcd_clk: The clk (sclk) feeding pixclk.
* @regs: The mapped hardware registers.
@@ -201,7 +200,6 @@ struct s3c_fb_vsync {
struct s3c_fb {
spinlock_t slock;
struct device *dev;
- struct resource *regs_res;
struct clk *bus_clk;
struct clk *lcd_clk;
void __iomem *regs;
@@ -1341,7 +1339,7 @@ static int __devinit s3c_fb_probe(struct platform_device *pdev)
return -EINVAL;
}
- sfb = kzalloc(sizeof(struct s3c_fb), GFP_KERNEL);
+ sfb = devm_kzalloc(dev, sizeof(struct s3c_fb), GFP_KERNEL);
if (!sfb) {
dev_err(dev, "no memory for framebuffers\n");
return -ENOMEM;
@@ -1384,33 +1382,25 @@ static int __devinit s3c_fb_probe(struct platform_device *pdev)
goto err_lcd_clk;
}
- sfb->regs_res = request_mem_region(res->start, resource_size(res),
- dev_name(dev));
- if (!sfb->regs_res) {
- dev_err(dev, "failed to claim register region\n");
- ret = -ENOENT;
- goto err_lcd_clk;
- }
-
- sfb->regs = ioremap(res->start, resource_size(res));
+ sfb->regs = devm_request_and_ioremap(dev, res);
if (!sfb->regs) {
dev_err(dev, "failed to map registers\n");
ret = -ENXIO;
- goto err_req_region;
+ goto err_lcd_clk;
}
res = platform_get_resource(pdev, IORESOURCE_IRQ, 0);
if (!res) {
dev_err(dev, "failed to acquire irq resource\n");
ret = -ENOENT;
- goto err_ioremap;
+ goto err_lcd_clk;
}
sfb->irq_no = res->start;
ret = request_irq(sfb->irq_no, s3c_fb_irq,
0, "s3c_fb", sfb);
if (ret) {
dev_err(dev, "irq request failed\n");
- goto err_ioremap;
+ goto err_lcd_clk;
}
dev_dbg(dev, "got resources (regs %p), probing windows\n", sfb->regs);
@@ -1465,12 +1455,6 @@ static int __devinit s3c_fb_probe(struct platform_device *pdev)
err_irq:
free_irq(sfb->irq_no, sfb);
-err_ioremap:
- iounmap(sfb->regs);
-
-err_req_region:
- release_mem_region(sfb->regs_res->start, resource_size(sfb->regs_res));
-
err_lcd_clk:
if (!sfb->variant.has_clksel) {
clk_disable(sfb->lcd_clk);
@@ -1482,7 +1466,6 @@ err_bus_clk:
clk_put(sfb->bus_clk);
err_sfb:
- kfree(sfb);
return ret;
}
@@ -1506,8 +1489,6 @@ static int __devexit s3c_fb_remove(struct platform_device *pdev)
free_irq(sfb->irq_no, sfb);
- iounmap(sfb->regs);
-
if (!sfb->variant.has_clksel) {
clk_disable(sfb->lcd_clk);
clk_put(sfb->lcd_clk);
@@ -1516,12 +1497,9 @@ static int __devexit s3c_fb_remove(struct platform_device *pdev)
clk_disable(sfb->bus_clk);
clk_put(sfb->bus_clk);
- release_mem_region(sfb->regs_res->start, resource_size(sfb->regs_res));
-
pm_runtime_put_sync(sfb->dev);
pm_runtime_disable(sfb->dev);
- kfree(sfb);
return 0;
}
--
1.7.7.3
^ permalink raw reply related
* Re: [PATCH] video: s3c-fb: Unify runtime and system PM functions
From: Jingoo Han @ 2011-11-28 1:49 UTC (permalink / raw)
To: linux-fbdev
In-Reply-To: <1322247342-17309-1-git-send-email-broonie@opensource.wolfsonmicro.com>
PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBTdWJqZWN0OiBbUEFUQ0hdIHZpZGVvOiBz
M2MtZmI6IFVuaWZ5IHJ1bnRpbWUgYW5kIHN5c3RlbSBQTSBmdW5jdGlvbnMNCj4gDQo+IFRoZSBz
M2MtZmIgZHJpdmVyIGhhcyBzZXBhcmF0ZSBydW50aW1lIGFuZCBzeXN0ZW0gUE0gZnVuY3Rpb25z
IGJ1dCB0aGUNCj4gaW1wbGVtZW50YXRpb25zIGFyZSBpZGVudGljYWwgc28gZmFyIGFzIEkgY2Fu
IHRlbGwgc28gdW5pZnkgdGhlbSBmb3INCj4gc2ltcGxpY2l0eS4NCj4gDQo+IFNpZ25lZC1vZmYt
Ynk6IE1hcmsgQnJvd24gPGJyb29uaWVAb3BlbnNvdXJjZS53b2xmc29ubWljcm8uY29tPg0KQWNr
ZWQtYnk6IEppbmdvbyBIYW4gPGpnMS5oYW5Ac2Ftc3VuZy5jb20+DQoNCkl0IGxvb2tzIGdvb2Qu
IA0KVGhhbmsgeW91Lg0KPiAtLS0NCj4gIGRyaXZlcnMvdmlkZW8vczNjLWZiLmMgfCAgIDc1ICst
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+IC0tLS0NCj4gIDEg
ZmlsZXMgY2hhbmdlZCwgMSBpbnNlcnRpb25zKCspLCA3NCBkZWxldGlvbnMoLSkNCj4gDQo+IGRp
ZmYgLS1naXQgYS9kcml2ZXJzL3ZpZGVvL3MzYy1mYi5jIGIvZHJpdmVycy92aWRlby9zM2MtZmIu
Yw0KPiBpbmRleCAxMmVhZWUwLi4wODYwNTkwIDEwMDY0NA0KPiAtLS0gYS9kcml2ZXJzL3ZpZGVv
L3MzYy1mYi5jDQo+ICsrKyBiL2RyaXZlcnMvdmlkZW8vczNjLWZiLmMNCj4gQEAgLTE1OTAsNzcg
KzE1OTAsOSBAQCBzdGF0aWMgaW50IHMzY19mYl9yZXN1bWUoc3RydWN0IGRldmljZSAqZGV2KQ0K
PiANCj4gIAlyZXR1cm4gMDsNCj4gIH0NCj4gLQ0KPiAtc3RhdGljIGludCBzM2NfZmJfcnVudGlt
ZV9zdXNwZW5kKHN0cnVjdCBkZXZpY2UgKmRldikNCj4gLXsNCj4gLQlzdHJ1Y3QgcGxhdGZvcm1f
ZGV2aWNlICpwZGV2ID0gdG9fcGxhdGZvcm1fZGV2aWNlKGRldik7DQo+IC0Jc3RydWN0IHMzY19m
YiAqc2ZiID0gcGxhdGZvcm1fZ2V0X2RydmRhdGEocGRldik7DQo+IC0Jc3RydWN0IHMzY19mYl93
aW4gKndpbjsNCj4gLQlpbnQgd2luX25vOw0KPiAtDQo+IC0JZm9yICh3aW5fbm8gPSBTM0NfRkJf
TUFYX1dJTiAtIDE7IHdpbl9ubyA+PSAwOyB3aW5fbm8tLSkgew0KPiAtCQl3aW4gPSBzZmItPndp
bmRvd3Nbd2luX25vXTsNCj4gLQkJaWYgKCF3aW4pDQo+IC0JCQljb250aW51ZTsNCj4gLQ0KPiAt
CQkvKiB1c2UgdGhlIGJsYW5rIGZ1bmN0aW9uIHRvIHB1c2ggaW50byBwb3dlci1kb3duICovDQo+
IC0JCXMzY19mYl9ibGFuayhGQl9CTEFOS19QT1dFUkRPV04sIHdpbi0+ZmJpbmZvKTsNCj4gLQl9
DQo+IC0NCj4gLQlpZiAoIXNmYi0+dmFyaWFudC5oYXNfY2xrc2VsKQ0KPiAtCQljbGtfZGlzYWJs
ZShzZmItPmxjZF9jbGspOw0KPiAtDQo+IC0JY2xrX2Rpc2FibGUoc2ZiLT5idXNfY2xrKTsNCj4g
LQlyZXR1cm4gMDsNCj4gLX0NCj4gLQ0KPiAtc3RhdGljIGludCBzM2NfZmJfcnVudGltZV9yZXN1
bWUoc3RydWN0IGRldmljZSAqZGV2KQ0KPiAtew0KPiAtCXN0cnVjdCBwbGF0Zm9ybV9kZXZpY2Ug
KnBkZXYgPSB0b19wbGF0Zm9ybV9kZXZpY2UoZGV2KTsNCj4gLQlzdHJ1Y3QgczNjX2ZiICpzZmIg
PSBwbGF0Zm9ybV9nZXRfZHJ2ZGF0YShwZGV2KTsNCj4gLQlzdHJ1Y3QgczNjX2ZiX3BsYXRkYXRh
ICpwZCA9IHNmYi0+cGRhdGE7DQo+IC0Jc3RydWN0IHMzY19mYl93aW4gKndpbjsNCj4gLQlpbnQg
d2luX25vOw0KPiAtDQo+IC0JY2xrX2VuYWJsZShzZmItPmJ1c19jbGspOw0KPiAtDQo+IC0JaWYg
KCFzZmItPnZhcmlhbnQuaGFzX2Nsa3NlbCkNCj4gLQkJY2xrX2VuYWJsZShzZmItPmxjZF9jbGsp
Ow0KPiAtDQo+IC0JLyogc2V0dXAgZ3BpbyBhbmQgb3V0cHV0IHBvbGFyaXR5IGNvbnRyb2xzICov
DQo+IC0JcGQtPnNldHVwX2dwaW8oKTsNCj4gLQl3cml0ZWwocGQtPnZpZGNvbjEsIHNmYi0+cmVn
cyArIFZJRENPTjEpOw0KPiAtDQo+IC0JLyogemVybyBhbGwgd2luZG93cyBiZWZvcmUgd2UgZG8g
YW55dGhpbmcgKi8NCj4gLQlmb3IgKHdpbl9ubyA9IDA7IHdpbl9ubyA8IHNmYi0+dmFyaWFudC5u
cl93aW5kb3dzOyB3aW5fbm8rKykNCj4gLQkJczNjX2ZiX2NsZWFyX3dpbihzZmIsIHdpbl9ubyk7
DQo+IC0NCj4gLQlmb3IgKHdpbl9ubyA9IDA7IHdpbl9ubyA8IHNmYi0+dmFyaWFudC5ucl93aW5k
b3dzIC0gMTsgd2luX25vKyspIHsNCj4gLQkJdm9pZCBfX2lvbWVtICpyZWdzID0gc2ZiLT5yZWdz
ICsgc2ZiLT52YXJpYW50LmtleWNvbjsNCj4gLQ0KPiAtCQlyZWdzICs9ICh3aW5fbm8gKiA4KTsN
Cj4gLQkJd3JpdGVsKDB4ZmZmZmZmLCByZWdzICsgV0tFWUNPTjApOw0KPiAtCQl3cml0ZWwoMHhm
ZmZmZmYsIHJlZ3MgKyBXS0VZQ09OMSk7DQo+IC0JfQ0KPiAtDQo+IC0JLyogcmVzdG9yZSBmcmFt
ZWJ1ZmZlcnMgKi8NCj4gLQlmb3IgKHdpbl9ubyA9IDA7IHdpbl9ubyA8IFMzQ19GQl9NQVhfV0lO
OyB3aW5fbm8rKykgew0KPiAtCQl3aW4gPSBzZmItPndpbmRvd3Nbd2luX25vXTsNCj4gLQkJaWYg
KCF3aW4pDQo+IC0JCQljb250aW51ZTsNCj4gLQ0KPiAtCQlkZXZfZGJnKCZwZGV2LT5kZXYsICJy
ZXN1bWluZyB3aW5kb3cgJWRcbiIsIHdpbl9ubyk7DQo+IC0JCXMzY19mYl9zZXRfcGFyKHdpbi0+
ZmJpbmZvKTsNCj4gLQl9DQo+IC0NCj4gLQlyZXR1cm4gMDsNCj4gLX0NCj4gLQ0KPiAgI2Vsc2UN
Cj4gICNkZWZpbmUgczNjX2ZiX3N1c3BlbmQgTlVMTA0KPiAgI2RlZmluZSBzM2NfZmJfcmVzdW1l
ICBOVUxMDQo+IC0jZGVmaW5lIHMzY19mYl9ydW50aW1lX3N1c3BlbmQgTlVMTA0KPiAtI2RlZmlu
ZSBzM2NfZmJfcnVudGltZV9yZXN1bWUgTlVMTA0KPiAgI2VuZGlmDQo+IA0KPiANCj4gQEAgLTE5
ODUsMTIgKzE5MTcsNyBAQCBzdGF0aWMgc3RydWN0IHBsYXRmb3JtX2RldmljZV9pZCBzM2NfZmJf
ZHJpdmVyX2lkc1tdDQo+ID0gew0KPiAgfTsNCj4gIE1PRFVMRV9ERVZJQ0VfVEFCTEUocGxhdGZv
cm0sIHMzY19mYl9kcml2ZXJfaWRzKTsNCj4gDQo+IC1zdGF0aWMgY29uc3Qgc3RydWN0IGRldl9w
bV9vcHMgczNjZmJfcG1fb3BzID0gew0KPiAtCS5zdXNwZW5kCT0gczNjX2ZiX3N1c3BlbmQsDQo+
IC0JLnJlc3VtZQkJPSBzM2NfZmJfcmVzdW1lLA0KPiAtCS5ydW50aW1lX3N1c3BlbmQJPSBzM2Nf
ZmJfcnVudGltZV9zdXNwZW5kLA0KPiAtCS5ydW50aW1lX3Jlc3VtZQkJPSBzM2NfZmJfcnVudGlt
ZV9yZXN1bWUsDQo+IC19Ow0KPiArVU5JVkVSU0FMX0RFVl9QTV9PUFMoczNjZmJfcG1fb3BzLCBz
M2NfZmJfc3VzcGVuZCwgczNjX2ZiX3Jlc3VtZSwgTlVMTCk7DQo+IA0KPiAgc3RhdGljIHN0cnVj
dCBwbGF0Zm9ybV9kcml2ZXIgczNjX2ZiX2RyaXZlciA9IHsNCj4gIAkucHJvYmUJCT0gczNjX2Zi
X3Byb2JlLA0KPiAtLQ0KPiAxLjcuNy4zDQo+IA0KPiAtLQ0K
^ permalink raw reply
* Re: [PATCH] video: convert drivers/video/* to use
From: Jingoo Han @ 2011-11-28 2:41 UTC (permalink / raw)
To: linux-fbdev
In-Reply-To: <1322274354.10633.3.camel@phoenix>
PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBTdWJqZWN0OiBbUEFUQ0hdIHZpZGVvOiBj
b252ZXJ0IGRyaXZlcnMvdmlkZW8vKiB0byB1c2UNCj4gbW9kdWxlX3BsYXRmb3JtX2RyaXZlcigp
DQo+IA0KPiBUaGlzIHBhdGNoIGNvbnZlcnRzIHRoZSBkcml2ZXJzIGluIGRyaXZlcnMvdmlkZW8v
KiB0byB1c2UgdGhlDQo+IG1vZHVsZV9wbGF0Zm9ybV9kcml2ZXIoKSBtYWNybyB3aGljaCBtYWtl
cyB0aGUgY29kZSBzbWFsbGVyIGFuZCBhIGJpdA0KPiBzaW1wbGVyLg0KPiANCj4gQ2M6IFdhbiBa
b25nU2h1biA8bWN1b3MuY29tQGdtYWlsLmNvbT4NCj4gQ2M6IFNhc2NoYSBIYXVlciA8cy5oYXVl
ckBwZW5ndXRyb25peC5kZT4NCj4gQ2M6IExlbm5lcnQgQnV5dGVuaGVrIDxidXl0ZW5oQHdhbnRz
dG9mbHkub3JnPg0KPiBDYzogQmVuIERvb2tzIDxiZW4tbGludXhAZmx1ZmYub3JnPg0KPiBDYzog
QWxleGV5IENoYXJrb3YgPGFsY2hhcmtAZ21haWwuY29tPg0KPiBDYzogRGFtaWFuIEhvYnNvbi1H
YXJjaWEgPGRob2Jzb25nQGlnZWwuY28uanA+DQo+IENjOiBNYW51ZWwgTGF1c3MgPG1hbm9Acm9h
cmluZWxrLmhvbWVsaW51eC5uZXQ+DQo+IFNpZ25lZC1vZmYtYnk6IEF4ZWwgTGluIDxheGVsLmxp
bkBnbWFpbC5jb20+DQpBY2tlZC1ieTogSmluZ29vIEhhbiA8amcxLmhhbkBzYW1zdW5nLmNvbT4N
CkkgcmV2aWV3ZWQgYW5kIHRlc3RlZCBkcml2ZXJzL3ZpZGVvL3MzYy1mYi5jLg0KSXQgbG9va3Mg
Z29vZC4NClRoYW5rIHlvdS4NCj4gLS0tDQo+ICBkcml2ZXJzL3ZpZGVvL214c2ZiLmMgICAgICAg
ICAgICB8ICAgMTMgKy0tLS0tLS0tLS0tLQ0KPiAgZHJpdmVycy92aWRlby9udWM5MDBmYi5jICAg
ICAgICAgfCAgIDEzICstLS0tLS0tLS0tLS0NCj4gIGRyaXZlcnMvdmlkZW8vcHhhMTY4ZmIuYyAg
ICAgICAgIHwgICAxMiArLS0tLS0tLS0tLS0NCj4gIGRyaXZlcnMvdmlkZW8vcHhhM3h4LWdjdS5j
ICAgICAgIHwgICAxNSArLS0tLS0tLS0tLS0tLS0NCj4gIGRyaXZlcnMvdmlkZW8vczNjLWZiLmMg
ICAgICAgICAgIHwgICAxMyArLS0tLS0tLS0tLS0tDQo+ICBkcml2ZXJzL3ZpZGVvL3NoNzc2MGZi
LmMgICAgICAgICB8ICAgMTMgKy0tLS0tLS0tLS0tLQ0KPiAgZHJpdmVycy92aWRlby9zaF9tb2Jp
bGVfbGNkY2ZiLmMgfCAgIDEzICstLS0tLS0tLS0tLS0NCj4gIGRyaXZlcnMvdmlkZW8vc2hfbW9i
aWxlX21lcmFtLmMgIHwgICAxMyArLS0tLS0tLS0tLS0tDQo+ICBkcml2ZXJzL3ZpZGVvL3NtNTAx
ZmIuYyAgICAgICAgICB8ICAgMTMgKy0tLS0tLS0tLS0tLQ0KPiAgZHJpdmVycy92aWRlby92dDg1
MDBsY2RmYi5jICAgICAgfCAgIDEzICstLS0tLS0tLS0tLS0NCj4gIGRyaXZlcnMvdmlkZW8vdzEw
MGZiLmMgICAgICAgICAgIHwgICAxMyArLS0tLS0tLS0tLS0tDQo+ICBkcml2ZXJzL3ZpZGVvL3dt
ODUwNWZiLmMgICAgICAgICB8ICAgMTMgKy0tLS0tLS0tLS0tLQ0KPiAgZHJpdmVycy92aWRlby93
bXRfZ2Vfcm9wcy5jICAgICAgfCAgIDEzICstLS0tLS0tLS0tLS0NCj4gIGRyaXZlcnMvdmlkZW8v
eGlsaW54ZmIuYyAgICAgICAgIHwgICAyMCArLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPiAgMTQgZmls
ZXMgY2hhbmdlZCwgMTQgaW5zZXJ0aW9ucygrKSwgMTc2IGRlbGV0aW9ucygtKQ0KPiANCj4gZGlm
ZiAtLWdpdCBhL2RyaXZlcnMvdmlkZW8vbXhzZmIuYyBiL2RyaXZlcnMvdmlkZW8vbXhzZmIuYw0K
PiBpbmRleCBkODM3ZDYzLi4xODc0MmMyIDEwMDY0NA0KPiAtLS0gYS9kcml2ZXJzL3ZpZGVvL214
c2ZiLmMNCj4gKysrIGIvZHJpdmVycy92aWRlby9teHNmYi5jDQo+IEBAIC05MDIsMTggKzkwMiw3
IEBAIHN0YXRpYyBzdHJ1Y3QgcGxhdGZvcm1fZHJpdmVyIG14c2ZiX2RyaXZlciA9IHsNCj4gIAl9
LA0KPiAgfTsNCj4gDQo+IC1zdGF0aWMgaW50IF9faW5pdCBteHNmYl9pbml0KHZvaWQpDQo+IC17
DQo+IC0JcmV0dXJuIHBsYXRmb3JtX2RyaXZlcl9yZWdpc3RlcigmbXhzZmJfZHJpdmVyKTsNCj4g
LX0NCj4gLQ0KPiAtc3RhdGljIHZvaWQgX19leGl0IG14c2ZiX2V4aXQodm9pZCkNCj4gLXsNCj4g
LQlwbGF0Zm9ybV9kcml2ZXJfdW5yZWdpc3RlcigmbXhzZmJfZHJpdmVyKTsNCj4gLX0NCj4gLQ0K
PiAtbW9kdWxlX2luaXQobXhzZmJfaW5pdCk7DQo+IC1tb2R1bGVfZXhpdChteHNmYl9leGl0KTsN
Cj4gK21vZHVsZV9wbGF0Zm9ybV9kcml2ZXIobXhzZmJfZGV2dHlwZSk7DQo+IA0KPiAgTU9EVUxF
X0RFU0NSSVBUSU9OKCJGcmVlc2NhbGUgbXhzIGZyYW1lYnVmZmVyIGRyaXZlciIpOw0KPiAgTU9E
VUxFX0FVVEhPUigiU2FzY2hhIEhhdWVyLCBQZW5ndXRyb25peCIpOw0KPiBkaWZmIC0tZ2l0IGEv
ZHJpdmVycy92aWRlby9udWM5MDBmYi5jIGIvZHJpdmVycy92aWRlby9udWM5MDBmYi5jDQo+IGlu
ZGV4IGQxZmJiZDguLmUxMGY1NTEgMTAwNjQ0DQo+IC0tLSBhL2RyaXZlcnMvdmlkZW8vbnVjOTAw
ZmIuYw0KPiArKysgYi9kcml2ZXJzL3ZpZGVvL251YzkwMGZiLmMNCj4gQEAgLTc2MiwxOCArNzYy
LDcgQEAgc3RhdGljIHN0cnVjdCBwbGF0Zm9ybV9kcml2ZXIgbnVjOTAwZmJfZHJpdmVyID0gew0K
PiAgCX0sDQo+ICB9Ow0KPiANCj4gLWludCBfX2RldmluaXQgbnVjOTAwZmJfaW5pdCh2b2lkKQ0K
PiAtew0KPiAtCXJldHVybiBwbGF0Zm9ybV9kcml2ZXJfcmVnaXN0ZXIoJm51YzkwMGZiX2RyaXZl
cik7DQo+IC19DQo+IC0NCj4gLXN0YXRpYyB2b2lkIF9fZXhpdCBudWM5MDBmYl9jbGVhbnVwKHZv
aWQpDQo+IC17DQo+IC0JcGxhdGZvcm1fZHJpdmVyX3VucmVnaXN0ZXIoJm51YzkwMGZiX2RyaXZl
cik7DQo+IC19DQo+IC0NCj4gLW1vZHVsZV9pbml0KG51YzkwMGZiX2luaXQpOw0KPiAtbW9kdWxl
X2V4aXQobnVjOTAwZmJfY2xlYW51cCk7DQo+ICttb2R1bGVfcGxhdGZvcm1fZHJpdmVyKG51Yzkw
MGZiX2RyaXZlcik7DQo+IA0KPiAgTU9EVUxFX0RFU0NSSVBUSU9OKCJGcmFtZWJ1ZmZlciBkcml2
ZXIgZm9yIHRoZSBOVUM5MDAiKTsNCj4gIE1PRFVMRV9MSUNFTlNFKCJHUEwiKTsNCj4gZGlmZiAt
LWdpdCBhL2RyaXZlcnMvdmlkZW8vcHhhMTY4ZmIuYyBiL2RyaXZlcnMvdmlkZW8vcHhhMTY4ZmIu
Yw0KPiBpbmRleCAxOGVhZDZmLi44Mzg0Yjk0IDEwMDY0NA0KPiAtLS0gYS9kcml2ZXJzL3ZpZGVv
L3B4YTE2OGZiLmMNCj4gKysrIGIvZHJpdmVycy92aWRlby9weGExNjhmYi5jDQo+IEBAIC04MzIs
MTcgKzgzMiw3IEBAIHN0YXRpYyBzdHJ1Y3QgcGxhdGZvcm1fZHJpdmVyIHB4YTE2OGZiX2RyaXZl
ciA9IHsNCj4gIAkucmVtb3ZlCQk9IF9fZGV2ZXhpdF9wKHB4YTE2OGZiX3JlbW92ZSksDQo+ICB9
Ow0KPiANCj4gLXN0YXRpYyBpbnQgX19pbml0IHB4YTE2OGZiX2luaXQodm9pZCkNCj4gLXsNCj4g
LQlyZXR1cm4gcGxhdGZvcm1fZHJpdmVyX3JlZ2lzdGVyKCZweGExNjhmYl9kcml2ZXIpOw0KPiAt
fQ0KPiAtbW9kdWxlX2luaXQocHhhMTY4ZmJfaW5pdCk7DQo+IC0NCj4gLXN0YXRpYyB2b2lkIF9f
ZXhpdCBweGExNjhmYl9leGl0KHZvaWQpDQo+IC17DQo+IC0JcGxhdGZvcm1fZHJpdmVyX3VucmVn
aXN0ZXIoJnB4YTE2OGZiX2RyaXZlcik7DQo+IC19DQo+IC1tb2R1bGVfZXhpdChweGExNjhmYl9l
eGl0KTsNCj4gK21vZHVsZV9wbGF0Zm9ybV9kcml2ZXIocHhhMTY4ZmJfZHJpdmVyKTsNCj4gDQo+
ICBNT0RVTEVfQVVUSE9SKCJMZW5uZXJ0IEJ1eXRlbmhlayA8YnV5dGVuaEBtYXJ2ZWxsLmNvbT4g
Ig0KPiAgCSAgICAgICJHcmVlbiBXYW4gPGd3YW5AbWFydmVsbC5jb20+Iik7DQo+IGRpZmYgLS1n
aXQgYS9kcml2ZXJzL3ZpZGVvL3B4YTN4eC1nY3UuYyBiL2RyaXZlcnMvdmlkZW8vcHhhM3h4LWdj
dS5jDQo+IGluZGV4IDFlZDhiMzYuLjFkNzFjMDggMTAwNjQ0DQo+IC0tLSBhL2RyaXZlcnMvdmlk
ZW8vcHhhM3h4LWdjdS5jDQo+ICsrKyBiL2RyaXZlcnMvdmlkZW8vcHhhM3h4LWdjdS5jDQo+IEBA
IC03NDcsMjAgKzc0Nyw3IEBAIHN0YXRpYyBzdHJ1Y3QgcGxhdGZvcm1fZHJpdmVyIHB4YTN4eF9n
Y3VfZHJpdmVyID0gew0KPiAgCX0sDQo+ICB9Ow0KPiANCj4gLXN0YXRpYyBpbnQgX19pbml0DQo+
IC1weGEzeHhfZ2N1X2luaXQodm9pZCkNCj4gLXsNCj4gLQlyZXR1cm4gcGxhdGZvcm1fZHJpdmVy
X3JlZ2lzdGVyKCZweGEzeHhfZ2N1X2RyaXZlcik7DQo+IC19DQo+IC0NCj4gLXN0YXRpYyB2b2lk
IF9fZXhpdA0KPiAtcHhhM3h4X2djdV9leGl0KHZvaWQpDQo+IC17DQo+IC0JcGxhdGZvcm1fZHJp
dmVyX3VucmVnaXN0ZXIoJnB4YTN4eF9nY3VfZHJpdmVyKTsNCj4gLX0NCj4gLQ0KPiAtbW9kdWxl
X2luaXQocHhhM3h4X2djdV9pbml0KTsNCj4gLW1vZHVsZV9leGl0KHB4YTN4eF9nY3VfZXhpdCk7
DQo+ICttb2R1bGVfcGxhdGZvcm1fZHJpdmVyKHB4YTN4eF9nY3VfZHJpdmVyKTsNCj4gDQo+ICBN
T0RVTEVfREVTQ1JJUFRJT04oIlBYQTN4eCBncmFwaGljcyBjb250cm9sbGVyIHVuaXQgZHJpdmVy
Iik7DQo+ICBNT0RVTEVfTElDRU5TRSgiR1BMIik7DQo+IGRpZmYgLS1naXQgYS9kcml2ZXJzL3Zp
ZGVvL3MzYy1mYi5jIGIvZHJpdmVycy92aWRlby9zM2MtZmIuYw0KPiBpbmRleCAwODYwNTkwLi5i
Y2FkMGVlIDEwMDY0NA0KPiAtLS0gYS9kcml2ZXJzL3ZpZGVvL3MzYy1mYi5jDQo+ICsrKyBiL2Ry
aXZlcnMvdmlkZW8vczNjLWZiLmMNCj4gQEAgLTE5MzAsMTggKzE5MzAsNyBAQCBzdGF0aWMgc3Ry
dWN0IHBsYXRmb3JtX2RyaXZlciBzM2NfZmJfZHJpdmVyID0gew0KPiAgCX0sDQo+ICB9Ow0KPiAN
Cj4gLXN0YXRpYyBpbnQgX19pbml0IHMzY19mYl9pbml0KHZvaWQpDQo+IC17DQo+IC0JcmV0dXJu
IHBsYXRmb3JtX2RyaXZlcl9yZWdpc3RlcigmczNjX2ZiX2RyaXZlcik7DQo+IC19DQo+IC0NCj4g
LXN0YXRpYyB2b2lkIF9fZXhpdCBzM2NfZmJfY2xlYW51cCh2b2lkKQ0KPiAtew0KPiAtCXBsYXRm
b3JtX2RyaXZlcl91bnJlZ2lzdGVyKCZzM2NfZmJfZHJpdmVyKTsNCj4gLX0NCj4gLQ0KPiAtbW9k
dWxlX2luaXQoczNjX2ZiX2luaXQpOw0KPiAtbW9kdWxlX2V4aXQoczNjX2ZiX2NsZWFudXApOw0K
PiArbW9kdWxlX3BsYXRmb3JtX2RyaXZlcihzM2NfZmJfZHJpdmVyKTsNCj4gDQo+ICBNT0RVTEVf
QVVUSE9SKCJCZW4gRG9va3MgPGJlbkBzaW10ZWMuY28udWs+Iik7DQo+ICBNT0RVTEVfREVTQ1JJ
UFRJT04oIlNhbXN1bmcgUzNDIFNvQyBGcmFtZWJ1ZmZlciBkcml2ZXIiKTsNCj4gZGlmZiAtLWdp
dCBhL2RyaXZlcnMvdmlkZW8vc2g3NzYwZmIuYyBiL2RyaXZlcnMvdmlkZW8vc2g3NzYwZmIuYw0K
PiBpbmRleCA0NWU0N2Q4Li44M2IxNmUyIDEwMDY0NA0KPiAtLS0gYS9kcml2ZXJzL3ZpZGVvL3No
Nzc2MGZiLmMNCj4gKysrIGIvZHJpdmVycy92aWRlby9zaDc3NjBmYi5jDQo+IEBAIC01ODUsMTgg
KzU4NSw3IEBAIHN0YXRpYyBzdHJ1Y3QgcGxhdGZvcm1fZHJpdmVyIHNoNzc2MF9sY2RjX2RyaXZl
ciA9IHsNCj4gIAkucmVtb3ZlID0gX19kZXZleGl0X3Aoc2g3NzYwZmJfcmVtb3ZlKSwNCj4gIH07
DQo+IA0KPiAtc3RhdGljIGludCBfX2luaXQgc2g3NzYwZmJfaW5pdCh2b2lkKQ0KPiAtew0KPiAt
CXJldHVybiBwbGF0Zm9ybV9kcml2ZXJfcmVnaXN0ZXIoJnNoNzc2MF9sY2RjX2RyaXZlcik7DQo+
IC19DQo+IC0NCj4gLXN0YXRpYyB2b2lkIF9fZXhpdCBzaDc3NjBmYl9leGl0KHZvaWQpDQo+IC17
DQo+IC0JcGxhdGZvcm1fZHJpdmVyX3VucmVnaXN0ZXIoJnNoNzc2MF9sY2RjX2RyaXZlcik7DQo+
IC19DQo+IC0NCj4gLW1vZHVsZV9pbml0KHNoNzc2MGZiX2luaXQpOw0KPiAtbW9kdWxlX2V4aXQo
c2g3NzYwZmJfZXhpdCk7DQo+ICttb2R1bGVfcGxhdGZvcm1fZHJpdmVyKHNoNzc2MF9sY2RjX2Ry
aXZlcik7DQo+IA0KPiAgTU9EVUxFX0FVVEhPUigiTm9idWhpcm8gSXdhbWF0c3UsIE1hbnVlbCBM
YXVzcyIpOw0KPiAgTU9EVUxFX0RFU0NSSVBUSU9OKCJGQmRldiBmb3IgU0g3NzYwLzYzIGludGVn
cmF0ZWQgTENEIENvbnRyb2xsZXIiKTsNCj4gZGlmZiAtLWdpdCBhL2RyaXZlcnMvdmlkZW8vc2hf
bW9iaWxlX2xjZGNmYi5jDQo+IGIvZHJpdmVycy92aWRlby9zaF9tb2JpbGVfbGNkY2ZiLmMNCj4g
aW5kZXggMWY0OWFiNC4uYTI2NGViZiAxMDA2NDQNCj4gLS0tIGEvZHJpdmVycy92aWRlby9zaF9t
b2JpbGVfbGNkY2ZiLmMNCj4gKysrIGIvZHJpdmVycy92aWRlby9zaF9tb2JpbGVfbGNkY2ZiLmMN
Cj4gQEAgLTE3MDksMTggKzE3MDksNyBAQCBzdGF0aWMgc3RydWN0IHBsYXRmb3JtX2RyaXZlciBz
aF9tb2JpbGVfbGNkY19kcml2ZXINCj4gPSB7DQo+ICAJLnJlbW92ZQkJPSBzaF9tb2JpbGVfbGNk
Y19yZW1vdmUsDQo+ICB9Ow0KPiANCj4gLXN0YXRpYyBpbnQgX19pbml0IHNoX21vYmlsZV9sY2Rj
X2luaXQodm9pZCkNCj4gLXsNCj4gLQlyZXR1cm4gcGxhdGZvcm1fZHJpdmVyX3JlZ2lzdGVyKCZz
aF9tb2JpbGVfbGNkY19kcml2ZXIpOw0KPiAtfQ0KPiAtDQo+IC1zdGF0aWMgdm9pZCBfX2V4aXQg
c2hfbW9iaWxlX2xjZGNfZXhpdCh2b2lkKQ0KPiAtew0KPiAtCXBsYXRmb3JtX2RyaXZlcl91bnJl
Z2lzdGVyKCZzaF9tb2JpbGVfbGNkY19kcml2ZXIpOw0KPiAtfQ0KPiAtDQo+IC1tb2R1bGVfaW5p
dChzaF9tb2JpbGVfbGNkY19pbml0KTsNCj4gLW1vZHVsZV9leGl0KHNoX21vYmlsZV9sY2RjX2V4
aXQpOw0KPiArbW9kdWxlX3BsYXRmb3JtX2RyaXZlcihzaF9tb2JpbGVfbGNkY19kcml2ZXIpOw0K
PiANCj4gIE1PRFVMRV9ERVNDUklQVElPTigiU3VwZXJIIE1vYmlsZSBMQ0RDIEZyYW1lYnVmZmVy
IGRyaXZlciIpOw0KPiAgTU9EVUxFX0FVVEhPUigiTWFnbnVzIERhbW0gPGRhbW1Ab3BlbnNvdXJj
ZS5zZT4iKTsNCj4gZGlmZiAtLWdpdCBhL2RyaXZlcnMvdmlkZW8vc2hfbW9iaWxlX21lcmFtLmMN
Cj4gYi9kcml2ZXJzL3ZpZGVvL3NoX21vYmlsZV9tZXJhbS5jDQo+IGluZGV4IDRkNjM0OTAuLmY0
NWQ4M2UgMTAwNjQ0DQo+IC0tLSBhL2RyaXZlcnMvdmlkZW8vc2hfbW9iaWxlX21lcmFtLmMNCj4g
KysrIGIvZHJpdmVycy92aWRlby9zaF9tb2JpbGVfbWVyYW0uYw0KPiBAQCAtNjc5LDE4ICs2Nzks
NyBAQCBzdGF0aWMgc3RydWN0IHBsYXRmb3JtX2RyaXZlciBzaF9tb2JpbGVfbWVyYW1fZHJpdmVy
DQo+ID0gew0KPiAgCS5yZW1vdmUJCT0gc2hfbW9iaWxlX21lcmFtX3JlbW92ZSwNCj4gIH07DQo+
IA0KPiAtc3RhdGljIGludCBfX2luaXQgc2hfbW9iaWxlX21lcmFtX2luaXQodm9pZCkNCj4gLXsN
Cj4gLQlyZXR1cm4gcGxhdGZvcm1fZHJpdmVyX3JlZ2lzdGVyKCZzaF9tb2JpbGVfbWVyYW1fZHJp
dmVyKTsNCj4gLX0NCj4gLQ0KPiAtc3RhdGljIHZvaWQgX19leGl0IHNoX21vYmlsZV9tZXJhbV9l
eGl0KHZvaWQpDQo+IC17DQo+IC0JcGxhdGZvcm1fZHJpdmVyX3VucmVnaXN0ZXIoJnNoX21vYmls
ZV9tZXJhbV9kcml2ZXIpOw0KPiAtfQ0KPiAtDQo+IC1tb2R1bGVfaW5pdChzaF9tb2JpbGVfbWVy
YW1faW5pdCk7DQo+IC1tb2R1bGVfZXhpdChzaF9tb2JpbGVfbWVyYW1fZXhpdCk7DQo+ICttb2R1
bGVfcGxhdGZvcm1fZHJpdmVyKHNoX21vYmlsZV9tZXJhbV9kcml2ZXIpOw0KPiANCj4gIE1PRFVM
RV9ERVNDUklQVElPTigiU3VwZXJIIE1vYmlsZSBNRVJBTSBkcml2ZXIiKTsNCj4gIE1PRFVMRV9B
VVRIT1IoIkRhbWlhbiBIb2Jzb24tR2FyY2lhIC8gVGFrYW5hcmkgSGF5YW1hIik7DQo+IGRpZmYg
LS1naXQgYS9kcml2ZXJzL3ZpZGVvL3NtNTAxZmIuYyBiL2RyaXZlcnMvdmlkZW8vc201MDFmYi5j
DQo+IGluZGV4IGE3ODI1NGMuLjM2OTBlZmYgMTAwNjQ0DQo+IC0tLSBhL2RyaXZlcnMvdmlkZW8v
c201MDFmYi5jDQo+ICsrKyBiL2RyaXZlcnMvdmlkZW8vc201MDFmYi5jDQo+IEBAIC0yMjMwLDE4
ICsyMjMwLDcgQEAgc3RhdGljIHN0cnVjdCBwbGF0Zm9ybV9kcml2ZXIgc201MDFmYl9kcml2ZXIg
PSB7DQo+ICAJfSwNCj4gIH07DQo+IA0KPiAtc3RhdGljIGludCBfX2RldmluaXQgc201MDFmYl9p
bml0KHZvaWQpDQo+IC17DQo+IC0JcmV0dXJuIHBsYXRmb3JtX2RyaXZlcl9yZWdpc3Rlcigmc201
MDFmYl9kcml2ZXIpOw0KPiAtfQ0KPiAtDQo+IC1zdGF0aWMgdm9pZCBfX2V4aXQgc201MDFmYl9j
bGVhbnVwKHZvaWQpDQo+IC17DQo+IC0JcGxhdGZvcm1fZHJpdmVyX3VucmVnaXN0ZXIoJnNtNTAx
ZmJfZHJpdmVyKTsNCj4gLX0NCj4gLQ0KPiAtbW9kdWxlX2luaXQoc201MDFmYl9pbml0KTsNCj4g
LW1vZHVsZV9leGl0KHNtNTAxZmJfY2xlYW51cCk7DQo+ICttb2R1bGVfcGxhdGZvcm1fZHJpdmVy
KHNtNTAxZmJfZHJpdmVyKTsNCj4gDQo+ICBtb2R1bGVfcGFyYW1fbmFtZWQobW9kZSwgZmJfbW9k
ZSwgY2hhcnAsIDApOw0KPiAgTU9EVUxFX1BBUk1fREVTQyhtb2RlLA0KPiBkaWZmIC0tZ2l0IGEv
ZHJpdmVycy92aWRlby92dDg1MDBsY2RmYi5jIGIvZHJpdmVycy92aWRlby92dDg1MDBsY2RmYi5j
DQo+IGluZGV4IDc3N2MyMWQuLjJhNWZlNmUgMTAwNjQ0DQo+IC0tLSBhL2RyaXZlcnMvdmlkZW8v
dnQ4NTAwbGNkZmIuYw0KPiArKysgYi9kcml2ZXJzL3ZpZGVvL3Z0ODUwMGxjZGZiLmMNCj4gQEAg
LTQ1NywxOCArNDU3LDcgQEAgc3RhdGljIHN0cnVjdCBwbGF0Zm9ybV9kcml2ZXIgdnQ4NTAwbGNk
X2RyaXZlciA9IHsNCj4gIAl9LA0KPiAgfTsNCj4gDQo+IC1zdGF0aWMgaW50IF9faW5pdCB2dDg1
MDBsY2RfaW5pdCh2b2lkKQ0KPiAtew0KPiAtCXJldHVybiBwbGF0Zm9ybV9kcml2ZXJfcmVnaXN0
ZXIoJnZ0ODUwMGxjZF9kcml2ZXIpOw0KPiAtfQ0KPiAtDQo+IC1zdGF0aWMgdm9pZCBfX2V4aXQg
dnQ4NTAwbGNkX2V4aXQodm9pZCkNCj4gLXsNCj4gLQlwbGF0Zm9ybV9kcml2ZXJfdW5yZWdpc3Rl
cigmdnQ4NTAwbGNkX2RyaXZlcik7DQo+IC19DQo+IC0NCj4gLW1vZHVsZV9pbml0KHZ0ODUwMGxj
ZF9pbml0KTsNCj4gLW1vZHVsZV9leGl0KHZ0ODUwMGxjZF9leGl0KTsNCj4gK21vZHVsZV9wbGF0
Zm9ybV9kcml2ZXIodnQ4NTAwbGNkX2RyaXZlcik7DQo+IA0KPiAgTU9EVUxFX0FVVEhPUigiQWxl
eGV5IENoYXJrb3YgPGFsY2hhcmtAZ21haWwuY29tPiIpOw0KPiAgTU9EVUxFX0RFU0NSSVBUSU9O
KCJMQ0QgY29udHJvbGxlciBkcml2ZXIgZm9yIFZJQSBWVDg1MDAiKTsNCj4gZGlmZiAtLWdpdCBh
L2RyaXZlcnMvdmlkZW8vdzEwMGZiLmMgYi9kcml2ZXJzL3ZpZGVvL3cxMDBmYi5jDQo+IGluZGV4
IDIzNzVlNWIuLjkwYTJlMzAgMTAwNjQ0DQo+IC0tLSBhL2RyaXZlcnMvdmlkZW8vdzEwMGZiLmMN
Cj4gKysrIGIvZHJpdmVycy92aWRlby93MTAwZmIuYw0KPiBAQCAtMTYyMCwxOCArMTYyMCw3IEBA
IHN0YXRpYyBzdHJ1Y3QgcGxhdGZvcm1fZHJpdmVyIHcxMDBmYl9kcml2ZXIgPSB7DQo+ICAJfSwN
Cj4gIH07DQo+IA0KPiAtaW50IF9faW5pdCB3MTAwZmJfaW5pdCh2b2lkKQ0KPiAtew0KPiAtCXJl
dHVybiBwbGF0Zm9ybV9kcml2ZXJfcmVnaXN0ZXIoJncxMDBmYl9kcml2ZXIpOw0KPiAtfQ0KPiAt
DQo+IC12b2lkIF9fZXhpdCB3MTAwZmJfY2xlYW51cCh2b2lkKQ0KPiAtew0KPiAtCXBsYXRmb3Jt
X2RyaXZlcl91bnJlZ2lzdGVyKCZ3MTAwZmJfZHJpdmVyKTsNCj4gLX0NCj4gLQ0KPiAtbW9kdWxl
X2luaXQodzEwMGZiX2luaXQpOw0KPiAtbW9kdWxlX2V4aXQodzEwMGZiX2NsZWFudXApOw0KPiAr
bW9kdWxlX3BsYXRmb3JtX2RyaXZlcih3MTAwZmJfZHJpdmVyKTsNCj4gDQo+ICBNT0RVTEVfREVT
Q1JJUFRJT04oIkFUSSBJbWFnZW9uIHcxMDAgZnJhbWVidWZmZXIgZHJpdmVyIik7DQo+ICBNT0RV
TEVfTElDRU5TRSgiR1BMIik7DQo+IGRpZmYgLS1naXQgYS9kcml2ZXJzL3ZpZGVvL3dtODUwNWZi
LmMgYi9kcml2ZXJzL3ZpZGVvL3dtODUwNWZiLmMNCj4gaW5kZXggOTZlMzRhNS4uYzg3MDNiZCAx
MDA2NDQNCj4gLS0tIGEvZHJpdmVycy92aWRlby93bTg1MDVmYi5jDQo+ICsrKyBiL2RyaXZlcnMv
dmlkZW8vd204NTA1ZmIuYw0KPiBAQCAtNDA0LDE4ICs0MDQsNyBAQCBzdGF0aWMgc3RydWN0IHBs
YXRmb3JtX2RyaXZlciB3bTg1MDVmYl9kcml2ZXIgPSB7DQo+ICAJfSwNCj4gIH07DQo+IA0KPiAt
c3RhdGljIGludCBfX2luaXQgd204NTA1ZmJfaW5pdCh2b2lkKQ0KPiAtew0KPiAtCXJldHVybiBw
bGF0Zm9ybV9kcml2ZXJfcmVnaXN0ZXIoJndtODUwNWZiX2RyaXZlcik7DQo+IC19DQo+IC0NCj4g
LXN0YXRpYyB2b2lkIF9fZXhpdCB3bTg1MDVmYl9leGl0KHZvaWQpDQo+IC17DQo+IC0JcGxhdGZv
cm1fZHJpdmVyX3VucmVnaXN0ZXIoJndtODUwNWZiX2RyaXZlcik7DQo+IC19DQo+IC0NCj4gLW1v
ZHVsZV9pbml0KHdtODUwNWZiX2luaXQpOw0KPiAtbW9kdWxlX2V4aXQod204NTA1ZmJfZXhpdCk7
DQo+ICttb2R1bGVfcGxhdGZvcm1fZHJpdmVyKHdtODUwNWZiX2RyaXZlcik7DQo+IA0KPiAgTU9E
VUxFX0FVVEhPUigiRWQgU3Bpcmlkb25vdiA8ZWRvLnJ1c0BnbWFpbC5jb20+Iik7DQo+ICBNT0RV
TEVfREVTQ1JJUFRJT04oIkZyYW1lYnVmZmVyIGRyaXZlciBmb3IgV01UIFdNODUwNSIpOw0KPiBk
aWZmIC0tZ2l0IGEvZHJpdmVycy92aWRlby93bXRfZ2Vfcm9wcy5jIGIvZHJpdmVycy92aWRlby93
bXRfZ2Vfcm9wcy5jDQo+IGluZGV4IDQ1ODMyYjcuLjU1YmUzODYgMTAwNjQ0DQo+IC0tLSBhL2Ry
aXZlcnMvdmlkZW8vd210X2dlX3JvcHMuYw0KPiArKysgYi9kcml2ZXJzL3ZpZGVvL3dtdF9nZV9y
b3BzLmMNCj4gQEAgLTE2NywxOCArMTY3LDcgQEAgc3RhdGljIHN0cnVjdCBwbGF0Zm9ybV9kcml2
ZXIgd210X2dlX3JvcHNfZHJpdmVyID0gew0KPiAgCX0sDQo+ICB9Ow0KPiANCj4gLXN0YXRpYyBp
bnQgX19pbml0IHdtdF9nZV9yb3BzX2luaXQodm9pZCkNCj4gLXsNCj4gLQlyZXR1cm4gcGxhdGZv
cm1fZHJpdmVyX3JlZ2lzdGVyKCZ3bXRfZ2Vfcm9wc19kcml2ZXIpOw0KPiAtfQ0KPiAtDQo+IC1z
dGF0aWMgdm9pZCBfX2V4aXQgd210X2dlX3JvcHNfZXhpdCh2b2lkKQ0KPiAtew0KPiAtCXBsYXRm
b3JtX2RyaXZlcl91bnJlZ2lzdGVyKCZ3bXRfZ2Vfcm9wc19kcml2ZXIpOw0KPiAtfQ0KPiAtDQo+
IC1tb2R1bGVfaW5pdCh3bXRfZ2Vfcm9wc19pbml0KTsNCj4gLW1vZHVsZV9leGl0KHdtdF9nZV9y
b3BzX2V4aXQpOw0KPiArbW9kdWxlX3BsYXRmb3JtX2RyaXZlcih3bXRfZ2Vfcm9wc19kcml2ZXIp
Ow0KPiANCj4gIE1PRFVMRV9BVVRIT1IoIkFsZXhleSBDaGFya292IDxhbGNoYXJrQGdtYWlsLmNv
bSIpOw0KPiAgTU9EVUxFX0RFU0NSSVBUSU9OKCJBY2NlbGVyYXRvcnMgZm9yIHJhc3RlciBvcGVy
YXRpb25zIHVzaW5nICINCj4gZGlmZiAtLWdpdCBhL2RyaXZlcnMvdmlkZW8veGlsaW54ZmIuYyBi
L2RyaXZlcnMvdmlkZW8veGlsaW54ZmIuYw0KPiBpbmRleCBmY2I2Y2Q5Li4xODA4NDUyIDEwMDY0
NA0KPiAtLS0gYS9kcml2ZXJzL3ZpZGVvL3hpbGlueGZiLmMNCj4gKysrIGIvZHJpdmVycy92aWRl
by94aWxpbnhmYi5jDQo+IEBAIC01MTEsMjUgKzUxMSw3IEBAIHN0YXRpYyBzdHJ1Y3QgcGxhdGZv
cm1fZHJpdmVyIHhpbGlueGZiX29mX2RyaXZlciA9IHsNCj4gIAl9LA0KPiAgfTsNCj4gDQo+IC0N
Cj4gLS8qIC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLQ0KPiAtICogTW9kdWxlIHNldHVwIGFuZCB0ZWFyZG93bg0KPiAt
ICovDQo+IC0NCj4gLXN0YXRpYyBpbnQgX19pbml0DQo+IC14aWxpbnhmYl9pbml0KHZvaWQpDQo+
IC17DQo+IC0JcmV0dXJuIHBsYXRmb3JtX2RyaXZlcl9yZWdpc3RlcigmeGlsaW54ZmJfb2ZfZHJp
dmVyKTsNCj4gLX0NCj4gLQ0KPiAtc3RhdGljIHZvaWQgX19leGl0DQo+IC14aWxpbnhmYl9jbGVh
bnVwKHZvaWQpDQo+IC17DQo+IC0JcGxhdGZvcm1fZHJpdmVyX3VucmVnaXN0ZXIoJnhpbGlueGZi
X29mX2RyaXZlcik7DQo+IC19DQo+IC0NCj4gLW1vZHVsZV9pbml0KHhpbGlueGZiX2luaXQpOw0K
PiAtbW9kdWxlX2V4aXQoeGlsaW54ZmJfY2xlYW51cCk7DQo+ICttb2R1bGVfcGxhdGZvcm1fZHJp
dmVyKHhpbGlueGZiX29mX2RyaXZlcik7DQo+IA0KPiAgTU9EVUxFX0FVVEhPUigiTW9udGFWaXN0
YSBTb2Z0d2FyZSwgSW5jLiA8c291cmNlQG12aXN0YS5jb20+Iik7DQo+ICBNT0RVTEVfREVTQ1JJ
UFRJT04oIlhpbGlueCBURlQgZnJhbWUgYnVmZmVyIGRyaXZlciIpOw0KPiAtLQ0KPiAxLjcuMQ0K
DQo
^ permalink raw reply
* Re: [PATCH] video: convert drivers/video/* to use module_platform_driver()
From: Wan ZongShun @ 2011-11-28 2:46 UTC (permalink / raw)
To: linux-fbdev
In-Reply-To: <1322274354.10633.3.camel@phoenix>
2011/11/28 Jingoo Han <jg1.han@samsung.com>:
>> -----Original Message-----
>> Subject: [PATCH] video: convert drivers/video/* to use
>> module_platform_driver()
>>
>> This patch converts the drivers in drivers/video/* to use the
>> module_platform_driver() macro which makes the code smaller and a bit
>> simpler.
>>
>> Cc: Wan ZongShun <mcuos.com@gmail.com>
>> Cc: Sascha Hauer <s.hauer@pengutronix.de>
>> Cc: Lennert Buytenhek <buytenh@wantstofly.org>
>> Cc: Ben Dooks <ben-linux@fluff.org>
>> Cc: Alexey Charkov <alchark@gmail.com>
>> Cc: Damian Hobson-Garcia <dhobsong@igel.co.jp>
>> Cc: Manuel Lauss <mano@roarinelk.homelinux.net>
>> Signed-off-by: Axel Lin <axel.lin@gmail.com>
> Acked-by: Jingoo Han <jg1.han@samsung.com>
> I reviewed and tested drivers/video/s3c-fb.c.
> It looks good.
> Thank you.
>> ---
>> drivers/video/mxsfb.c | 13 +------------
>> drivers/video/nuc900fb.c | 13 +------------
>> drivers/video/pxa168fb.c | 12 +-----------
>> drivers/video/pxa3xx-gcu.c | 15 +--------------
>> drivers/video/s3c-fb.c | 13 +------------
>> drivers/video/sh7760fb.c | 13 +------------
>> drivers/video/sh_mobile_lcdcfb.c | 13 +------------
>> drivers/video/sh_mobile_meram.c | 13 +------------
>> drivers/video/sm501fb.c | 13 +------------
>> drivers/video/vt8500lcdfb.c | 13 +------------
>> drivers/video/w100fb.c | 13 +------------
>> drivers/video/wm8505fb.c | 13 +------------
>> drivers/video/wmt_ge_rops.c | 13 +------------
>> drivers/video/xilinxfb.c | 20 +-------------------
>> 14 files changed, 14 insertions(+), 176 deletions(-)
>>
>> diff --git a/drivers/video/mxsfb.c b/drivers/video/mxsfb.c
>> index d837d63..18742c2 100644
>> --- a/drivers/video/mxsfb.c
>> +++ b/drivers/video/mxsfb.c
>> @@ -902,18 +902,7 @@ static struct platform_driver mxsfb_driver = {
>> },
>> };
>>
>> -static int __init mxsfb_init(void)
>> -{
>> - return platform_driver_register(&mxsfb_driver);
>> -}
>> -
>> -static void __exit mxsfb_exit(void)
>> -{
>> - platform_driver_unregister(&mxsfb_driver);
>> -}
>> -
>> -module_init(mxsfb_init);
>> -module_exit(mxsfb_exit);
>> +module_platform_driver(mxsfb_devtype);
>>
>> MODULE_DESCRIPTION("Freescale mxs framebuffer driver");
>> MODULE_AUTHOR("Sascha Hauer, Pengutronix");
>> diff --git a/drivers/video/nuc900fb.c b/drivers/video/nuc900fb.c
>> index d1fbbd8..e10f551 100644
>> --- a/drivers/video/nuc900fb.c
>> +++ b/drivers/video/nuc900fb.c
>> @@ -762,18 +762,7 @@ static struct platform_driver nuc900fb_driver = {
>> },
>> };
>>
>> -int __devinit nuc900fb_init(void)
>> -{
>> - return platform_driver_register(&nuc900fb_driver);
>> -}
>> -
>> -static void __exit nuc900fb_cleanup(void)
>> -{
>> - platform_driver_unregister(&nuc900fb_driver);
>> -}
>> -
>> -module_init(nuc900fb_init);
>> -module_exit(nuc900fb_cleanup);
>> +module_platform_driver(nuc900fb_driver);
>>
>> MODULE_DESCRIPTION("Framebuffer driver for the NUC900");
>> MODULE_LICENSE("GPL");
>> diff --git a/drivers/video/pxa168fb.c b/drivers/video/pxa168fb.c
>> index 18ead6f..8384b94 100644
>> --- a/drivers/video/pxa168fb.c
>> +++ b/drivers/video/pxa168fb.c
>> @@ -832,17 +832,7 @@ static struct platform_driver pxa168fb_driver = {
>> .remove = __devexit_p(pxa168fb_remove),
>> };
>>
>> -static int __init pxa168fb_init(void)
>> -{
>> - return platform_driver_register(&pxa168fb_driver);
>> -}
>> -module_init(pxa168fb_init);
>> -
>> -static void __exit pxa168fb_exit(void)
>> -{
>> - platform_driver_unregister(&pxa168fb_driver);
>> -}
>> -module_exit(pxa168fb_exit);
>> +module_platform_driver(pxa168fb_driver);
>>
>> MODULE_AUTHOR("Lennert Buytenhek <buytenh@marvell.com> "
>> "Green Wan <gwan@marvell.com>");
>> diff --git a/drivers/video/pxa3xx-gcu.c b/drivers/video/pxa3xx-gcu.c
>> index 1ed8b36..1d71c08 100644
>> --- a/drivers/video/pxa3xx-gcu.c
>> +++ b/drivers/video/pxa3xx-gcu.c
>> @@ -747,20 +747,7 @@ static struct platform_driver pxa3xx_gcu_driver = {
>> },
>> };
>>
>> -static int __init
>> -pxa3xx_gcu_init(void)
>> -{
>> - return platform_driver_register(&pxa3xx_gcu_driver);
>> -}
>> -
>> -static void __exit
>> -pxa3xx_gcu_exit(void)
>> -{
>> - platform_driver_unregister(&pxa3xx_gcu_driver);
>> -}
>> -
>> -module_init(pxa3xx_gcu_init);
>> -module_exit(pxa3xx_gcu_exit);
>> +module_platform_driver(pxa3xx_gcu_driver);
>>
>> MODULE_DESCRIPTION("PXA3xx graphics controller unit driver");
>> MODULE_LICENSE("GPL");
>> diff --git a/drivers/video/s3c-fb.c b/drivers/video/s3c-fb.c
>> index 0860590..bcad0ee 100644
>> --- a/drivers/video/s3c-fb.c
>> +++ b/drivers/video/s3c-fb.c
>> @@ -1930,18 +1930,7 @@ static struct platform_driver s3c_fb_driver = {
>> },
>> };
>>
>> -static int __init s3c_fb_init(void)
>> -{
>> - return platform_driver_register(&s3c_fb_driver);
>> -}
>> -
>> -static void __exit s3c_fb_cleanup(void)
>> -{
>> - platform_driver_unregister(&s3c_fb_driver);
>> -}
>> -
>> -module_init(s3c_fb_init);
>> -module_exit(s3c_fb_cleanup);
>> +module_platform_driver(s3c_fb_driver);
>>
>> MODULE_AUTHOR("Ben Dooks <ben@simtec.co.uk>");
>> MODULE_DESCRIPTION("Samsung S3C SoC Framebuffer driver");
>> diff --git a/drivers/video/sh7760fb.c b/drivers/video/sh7760fb.c
>> index 45e47d8..83b16e2 100644
>> --- a/drivers/video/sh7760fb.c
>> +++ b/drivers/video/sh7760fb.c
>> @@ -585,18 +585,7 @@ static struct platform_driver sh7760_lcdc_driver = {
>> .remove = __devexit_p(sh7760fb_remove),
>> };
>>
>> -static int __init sh7760fb_init(void)
>> -{
>> - return platform_driver_register(&sh7760_lcdc_driver);
>> -}
>> -
>> -static void __exit sh7760fb_exit(void)
>> -{
>> - platform_driver_unregister(&sh7760_lcdc_driver);
>> -}
>> -
>> -module_init(sh7760fb_init);
>> -module_exit(sh7760fb_exit);
>> +module_platform_driver(sh7760_lcdc_driver);
>>
>> MODULE_AUTHOR("Nobuhiro Iwamatsu, Manuel Lauss");
>> MODULE_DESCRIPTION("FBdev for SH7760/63 integrated LCD Controller");
>> diff --git a/drivers/video/sh_mobile_lcdcfb.c
>> b/drivers/video/sh_mobile_lcdcfb.c
>> index 1f49ab4..a264ebf 100644
>> --- a/drivers/video/sh_mobile_lcdcfb.c
>> +++ b/drivers/video/sh_mobile_lcdcfb.c
>> @@ -1709,18 +1709,7 @@ static struct platform_driver sh_mobile_lcdc_driver
>> = {
>> .remove = sh_mobile_lcdc_remove,
>> };
>>
>> -static int __init sh_mobile_lcdc_init(void)
>> -{
>> - return platform_driver_register(&sh_mobile_lcdc_driver);
>> -}
>> -
>> -static void __exit sh_mobile_lcdc_exit(void)
>> -{
>> - platform_driver_unregister(&sh_mobile_lcdc_driver);
>> -}
>> -
>> -module_init(sh_mobile_lcdc_init);
>> -module_exit(sh_mobile_lcdc_exit);
>> +module_platform_driver(sh_mobile_lcdc_driver);
>>
>> MODULE_DESCRIPTION("SuperH Mobile LCDC Framebuffer driver");
>> MODULE_AUTHOR("Magnus Damm <damm@opensource.se>");
>> diff --git a/drivers/video/sh_mobile_meram.c
>> b/drivers/video/sh_mobile_meram.c
>> index 4d63490..f45d83e 100644
>> --- a/drivers/video/sh_mobile_meram.c
>> +++ b/drivers/video/sh_mobile_meram.c
>> @@ -679,18 +679,7 @@ static struct platform_driver sh_mobile_meram_driver
>> = {
>> .remove = sh_mobile_meram_remove,
>> };
>>
>> -static int __init sh_mobile_meram_init(void)
>> -{
>> - return platform_driver_register(&sh_mobile_meram_driver);
>> -}
>> -
>> -static void __exit sh_mobile_meram_exit(void)
>> -{
>> - platform_driver_unregister(&sh_mobile_meram_driver);
>> -}
>> -
>> -module_init(sh_mobile_meram_init);
>> -module_exit(sh_mobile_meram_exit);
>> +module_platform_driver(sh_mobile_meram_driver);
>>
>> MODULE_DESCRIPTION("SuperH Mobile MERAM driver");
>> MODULE_AUTHOR("Damian Hobson-Garcia / Takanari Hayama");
>> diff --git a/drivers/video/sm501fb.c b/drivers/video/sm501fb.c
>> index a78254c..3690eff 100644
>> --- a/drivers/video/sm501fb.c
>> +++ b/drivers/video/sm501fb.c
>> @@ -2230,18 +2230,7 @@ static struct platform_driver sm501fb_driver = {
>> },
>> };
>>
>> -static int __devinit sm501fb_init(void)
>> -{
>> - return platform_driver_register(&sm501fb_driver);
>> -}
>> -
>> -static void __exit sm501fb_cleanup(void)
>> -{
>> - platform_driver_unregister(&sm501fb_driver);
>> -}
>> -
>> -module_init(sm501fb_init);
>> -module_exit(sm501fb_cleanup);
>> +module_platform_driver(sm501fb_driver);
>>
>> module_param_named(mode, fb_mode, charp, 0);
>> MODULE_PARM_DESC(mode,
>> diff --git a/drivers/video/vt8500lcdfb.c b/drivers/video/vt8500lcdfb.c
>> index 777c21d..2a5fe6e 100644
>> --- a/drivers/video/vt8500lcdfb.c
>> +++ b/drivers/video/vt8500lcdfb.c
>> @@ -457,18 +457,7 @@ static struct platform_driver vt8500lcd_driver = {
>> },
>> };
>>
>> -static int __init vt8500lcd_init(void)
>> -{
>> - return platform_driver_register(&vt8500lcd_driver);
>> -}
>> -
>> -static void __exit vt8500lcd_exit(void)
>> -{
>> - platform_driver_unregister(&vt8500lcd_driver);
>> -}
>> -
>> -module_init(vt8500lcd_init);
>> -module_exit(vt8500lcd_exit);
>> +module_platform_driver(vt8500lcd_driver);
>>
>> MODULE_AUTHOR("Alexey Charkov <alchark@gmail.com>");
>> MODULE_DESCRIPTION("LCD controller driver for VIA VT8500");
>> diff --git a/drivers/video/w100fb.c b/drivers/video/w100fb.c
>> index 2375e5b..90a2e30 100644
>> --- a/drivers/video/w100fb.c
>> +++ b/drivers/video/w100fb.c
>> @@ -1620,18 +1620,7 @@ static struct platform_driver w100fb_driver = {
>> },
>> };
>>
>> -int __init w100fb_init(void)
>> -{
>> - return platform_driver_register(&w100fb_driver);
>> -}
>> -
>> -void __exit w100fb_cleanup(void)
>> -{
>> - platform_driver_unregister(&w100fb_driver);
>> -}
>> -
>> -module_init(w100fb_init);
>> -module_exit(w100fb_cleanup);
>> +module_platform_driver(w100fb_driver);
>>
>> MODULE_DESCRIPTION("ATI Imageon w100 framebuffer driver");
>> MODULE_LICENSE("GPL");
>> diff --git a/drivers/video/wm8505fb.c b/drivers/video/wm8505fb.c
>> index 96e34a5..c8703bd 100644
>> --- a/drivers/video/wm8505fb.c
>> +++ b/drivers/video/wm8505fb.c
>> @@ -404,18 +404,7 @@ static struct platform_driver wm8505fb_driver = {
>> },
>> };
>>
>> -static int __init wm8505fb_init(void)
>> -{
>> - return platform_driver_register(&wm8505fb_driver);
>> -}
>> -
>> -static void __exit wm8505fb_exit(void)
>> -{
>> - platform_driver_unregister(&wm8505fb_driver);
>> -}
>> -
>> -module_init(wm8505fb_init);
>> -module_exit(wm8505fb_exit);
>> +module_platform_driver(wm8505fb_driver);
>>
>> MODULE_AUTHOR("Ed Spiridonov <edo.rus@gmail.com>");
>> MODULE_DESCRIPTION("Framebuffer driver for WMT WM8505");
>> diff --git a/drivers/video/wmt_ge_rops.c b/drivers/video/wmt_ge_rops.c
>> index 45832b7..55be386 100644
>> --- a/drivers/video/wmt_ge_rops.c
>> +++ b/drivers/video/wmt_ge_rops.c
>> @@ -167,18 +167,7 @@ static struct platform_driver wmt_ge_rops_driver = {
>> },
>> };
>>
>> -static int __init wmt_ge_rops_init(void)
>> -{
>> - return platform_driver_register(&wmt_ge_rops_driver);
>> -}
>> -
>> -static void __exit wmt_ge_rops_exit(void)
>> -{
>> - platform_driver_unregister(&wmt_ge_rops_driver);
>> -}
>> -
>> -module_init(wmt_ge_rops_init);
>> -module_exit(wmt_ge_rops_exit);
>> +module_platform_driver(wmt_ge_rops_driver);
>>
>> MODULE_AUTHOR("Alexey Charkov <alchark@gmail.com");
>> MODULE_DESCRIPTION("Accelerators for raster operations using "
>> diff --git a/drivers/video/xilinxfb.c b/drivers/video/xilinxfb.c
>> index fcb6cd9..1808452 100644
>> --- a/drivers/video/xilinxfb.c
>> +++ b/drivers/video/xilinxfb.c
>> @@ -511,25 +511,7 @@ static struct platform_driver xilinxfb_of_driver = {
>> },
>> };
>>
>> -
>> -/* ---------------------------------------------------------------------
>> - * Module setup and teardown
>> - */
>> -
>> -static int __init
>> -xilinxfb_init(void)
>> -{
>> - return platform_driver_register(&xilinxfb_of_driver);
>> -}
>> -
>> -static void __exit
>> -xilinxfb_cleanup(void)
>> -{
>> - platform_driver_unregister(&xilinxfb_of_driver);
>> -}
>> -
>> -module_init(xilinxfb_init);
>> -module_exit(xilinxfb_cleanup);
>> +module_platform_driver(xilinxfb_of_driver);
>>
>> MODULE_AUTHOR("MontaVista Software, Inc. <source@mvista.com>");
>> MODULE_DESCRIPTION("Xilinx TFT frame buffer driver");
for nuc900fb
Acked-by: Wan ZongShun <mcuos.com@gmail.com>
thanks!
>> --
>> 1.7.1
>
>
--
Wan ZongShun.
www.mcuos.com
^ permalink raw reply
* Re: [PATCH 1/2] video: s3c-fb: Unify runtime and system PM functions
From: Jingoo Han @ 2011-11-28 7:38 UTC (permalink / raw)
To: linux-fbdev
In-Reply-To: <1322434268-25525-1-git-send-email-broonie@opensource.wolfsonmicro.com>
PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBNYXJrIEJyb3duIDxicm9vbmll
QG9wZW5zb3VyY2Uud29sZnNvbm1pY3JvLmNvbT4NCj4gU3ViamVjdDogW1BBVENIIDEvMl0gdmlk
ZW86IHMzYy1mYjogVW5pZnkgcnVudGltZSBhbmQgc3lzdGVtIFBNIGZ1bmN0aW9ucw0KPiANCj4g
VGhlIHMzYy1mYiBkcml2ZXIgaGFzIHNlcGFyYXRlIHJ1bnRpbWUgYW5kIHN5c3RlbSBQTSBmdW5j
dGlvbnMgYnV0IHRoZQ0KPiBpbXBsZW1lbnRhdGlvbnMgYXJlIGlkZW50aWNhbCBzbyBmYXIgYXMg
SSBjYW4gdGVsbCBzbyB1bmlmeSB0aGVtIGZvcg0KPiBzaW1wbGljaXR5Lg0KPiANCj4gU2lnbmVk
LW9mZi1ieTogTWFyayBCcm93biA8YnJvb25pZUBvcGVuc291cmNlLndvbGZzb25taWNyby5jb20+
DQpBY2tlZC1ieTogSmluZ29vIEhhbiA8amcxLmhhbkBzYW1zdW5nLmNvbT4NClRoYW5rIHlvdS4N
Cj4gLS0tDQo+ICBkcml2ZXJzL3ZpZGVvL3MzYy1mYi5jIHwgICA3NSArLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPiAtLS0tDQo+ICAxIGZpbGVzIGNoYW5nZWQs
IDEgaW5zZXJ0aW9ucygrKSwgNzQgZGVsZXRpb25zKC0pDQo+IA0KPiBkaWZmIC0tZ2l0IGEvZHJp
dmVycy92aWRlby9zM2MtZmIuYyBiL2RyaXZlcnMvdmlkZW8vczNjLWZiLmMNCj4gaW5kZXggY2Yx
ZDExZi4uZTg0Njc3ZSAxMDA2NDQNCj4gLS0tIGEvZHJpdmVycy92aWRlby9zM2MtZmIuYw0KPiAr
KysgYi9kcml2ZXJzL3ZpZGVvL3MzYy1mYi5jDQo+IEBAIC0xNTkwLDc3ICsxNTkwLDkgQEAgc3Rh
dGljIGludCBzM2NfZmJfcmVzdW1lKHN0cnVjdCBkZXZpY2UgKmRldikNCj4gDQo+ICAJcmV0dXJu
IDA7DQo+ICB9DQo+IC0NCj4gLXN0YXRpYyBpbnQgczNjX2ZiX3J1bnRpbWVfc3VzcGVuZChzdHJ1
Y3QgZGV2aWNlICpkZXYpDQo+IC17DQo+IC0Jc3RydWN0IHBsYXRmb3JtX2RldmljZSAqcGRldiA9
IHRvX3BsYXRmb3JtX2RldmljZShkZXYpOw0KPiAtCXN0cnVjdCBzM2NfZmIgKnNmYiA9IHBsYXRm
b3JtX2dldF9kcnZkYXRhKHBkZXYpOw0KPiAtCXN0cnVjdCBzM2NfZmJfd2luICp3aW47DQo+IC0J
aW50IHdpbl9ubzsNCj4gLQ0KPiAtCWZvciAod2luX25vID0gUzNDX0ZCX01BWF9XSU4gLSAxOyB3
aW5fbm8gPj0gMDsgd2luX25vLS0pIHsNCj4gLQkJd2luID0gc2ZiLT53aW5kb3dzW3dpbl9ub107
DQo+IC0JCWlmICghd2luKQ0KPiAtCQkJY29udGludWU7DQo+IC0NCj4gLQkJLyogdXNlIHRoZSBi
bGFuayBmdW5jdGlvbiB0byBwdXNoIGludG8gcG93ZXItZG93biAqLw0KPiAtCQlzM2NfZmJfYmxh
bmsoRkJfQkxBTktfUE9XRVJET1dOLCB3aW4tPmZiaW5mbyk7DQo+IC0JfQ0KPiAtDQo+IC0JaWYg
KCFzZmItPnZhcmlhbnQuaGFzX2Nsa3NlbCkNCj4gLQkJY2xrX2Rpc2FibGUoc2ZiLT5sY2RfY2xr
KTsNCj4gLQ0KPiAtCWNsa19kaXNhYmxlKHNmYi0+YnVzX2Nsayk7DQo+IC0JcmV0dXJuIDA7DQo+
IC19DQo+IC0NCj4gLXN0YXRpYyBpbnQgczNjX2ZiX3J1bnRpbWVfcmVzdW1lKHN0cnVjdCBkZXZp
Y2UgKmRldikNCj4gLXsNCj4gLQlzdHJ1Y3QgcGxhdGZvcm1fZGV2aWNlICpwZGV2ID0gdG9fcGxh
dGZvcm1fZGV2aWNlKGRldik7DQo+IC0Jc3RydWN0IHMzY19mYiAqc2ZiID0gcGxhdGZvcm1fZ2V0
X2RydmRhdGEocGRldik7DQo+IC0Jc3RydWN0IHMzY19mYl9wbGF0ZGF0YSAqcGQgPSBzZmItPnBk
YXRhOw0KPiAtCXN0cnVjdCBzM2NfZmJfd2luICp3aW47DQo+IC0JaW50IHdpbl9ubzsNCj4gLQ0K
PiAtCWNsa19lbmFibGUoc2ZiLT5idXNfY2xrKTsNCj4gLQ0KPiAtCWlmICghc2ZiLT52YXJpYW50
Lmhhc19jbGtzZWwpDQo+IC0JCWNsa19lbmFibGUoc2ZiLT5sY2RfY2xrKTsNCj4gLQ0KPiAtCS8q
IHNldHVwIGdwaW8gYW5kIG91dHB1dCBwb2xhcml0eSBjb250cm9scyAqLw0KPiAtCXBkLT5zZXR1
cF9ncGlvKCk7DQo+IC0Jd3JpdGVsKHBkLT52aWRjb24xLCBzZmItPnJlZ3MgKyBWSURDT04xKTsN
Cj4gLQ0KPiAtCS8qIHplcm8gYWxsIHdpbmRvd3MgYmVmb3JlIHdlIGRvIGFueXRoaW5nICovDQo+
IC0JZm9yICh3aW5fbm8gPSAwOyB3aW5fbm8gPCBzZmItPnZhcmlhbnQubnJfd2luZG93czsgd2lu
X25vKyspDQo+IC0JCXMzY19mYl9jbGVhcl93aW4oc2ZiLCB3aW5fbm8pOw0KPiAtDQo+IC0JZm9y
ICh3aW5fbm8gPSAwOyB3aW5fbm8gPCBzZmItPnZhcmlhbnQubnJfd2luZG93cyAtIDE7IHdpbl9u
bysrKSB7DQo+IC0JCXZvaWQgX19pb21lbSAqcmVncyA9IHNmYi0+cmVncyArIHNmYi0+dmFyaWFu
dC5rZXljb247DQo+IC0NCj4gLQkJcmVncyArPSAod2luX25vICogOCk7DQo+IC0JCXdyaXRlbCgw
eGZmZmZmZiwgcmVncyArIFdLRVlDT04wKTsNCj4gLQkJd3JpdGVsKDB4ZmZmZmZmLCByZWdzICsg
V0tFWUNPTjEpOw0KPiAtCX0NCj4gLQ0KPiAtCS8qIHJlc3RvcmUgZnJhbWVidWZmZXJzICovDQo+
IC0JZm9yICh3aW5fbm8gPSAwOyB3aW5fbm8gPCBTM0NfRkJfTUFYX1dJTjsgd2luX25vKyspIHsN
Cj4gLQkJd2luID0gc2ZiLT53aW5kb3dzW3dpbl9ub107DQo+IC0JCWlmICghd2luKQ0KPiAtCQkJ
Y29udGludWU7DQo+IC0NCj4gLQkJZGV2X2RiZygmcGRldi0+ZGV2LCAicmVzdW1pbmcgd2luZG93
ICVkXG4iLCB3aW5fbm8pOw0KPiAtCQlzM2NfZmJfc2V0X3Bhcih3aW4tPmZiaW5mbyk7DQo+IC0J
fQ0KPiAtDQo+IC0JcmV0dXJuIDA7DQo+IC19DQo+IC0NCj4gICNlbHNlDQo+ICAjZGVmaW5lIHMz
Y19mYl9zdXNwZW5kIE5VTEwNCj4gICNkZWZpbmUgczNjX2ZiX3Jlc3VtZSAgTlVMTA0KPiAtI2Rl
ZmluZSBzM2NfZmJfcnVudGltZV9zdXNwZW5kIE5VTEwNCj4gLSNkZWZpbmUgczNjX2ZiX3J1bnRp
bWVfcmVzdW1lIE5VTEwNCj4gICNlbmRpZg0KPiANCj4gDQo+IEBAIC0xOTg1LDEyICsxOTE3LDcg
QEAgc3RhdGljIHN0cnVjdCBwbGF0Zm9ybV9kZXZpY2VfaWQgczNjX2ZiX2RyaXZlcl9pZHNbXQ0K
PiA9IHsNCj4gIH07DQo+ICBNT0RVTEVfREVWSUNFX1RBQkxFKHBsYXRmb3JtLCBzM2NfZmJfZHJp
dmVyX2lkcyk7DQo+IA0KPiAtc3RhdGljIGNvbnN0IHN0cnVjdCBkZXZfcG1fb3BzIHMzY2ZiX3Bt
X29wcyA9IHsNCj4gLQkuc3VzcGVuZAk9IHMzY19mYl9zdXNwZW5kLA0KPiAtCS5yZXN1bWUJCT0g
czNjX2ZiX3Jlc3VtZSwNCj4gLQkucnVudGltZV9zdXNwZW5kCT0gczNjX2ZiX3J1bnRpbWVfc3Vz
cGVuZCwNCj4gLQkucnVudGltZV9yZXN1bWUJCT0gczNjX2ZiX3J1bnRpbWVfcmVzdW1lLA0KPiAt
fTsNCj4gK3N0YXRpYyBVTklWRVJTQUxfREVWX1BNX09QUyhzM2NmYl9wbV9vcHMsIHMzY19mYl9z
dXNwZW5kLCBzM2NfZmJfcmVzdW1lLA0KPiBOVUxMKTsNCj4gDQo+ICBzdGF0aWMgc3RydWN0IHBs
YXRmb3JtX2RyaXZlciBzM2NfZmJfZHJpdmVyID0gew0KPiAgCS5wcm9iZQkJPSBzM2NfZmJfcHJv
YmUsDQo+IC0tDQo+IDEuNy4xDQoNCg0KDQo
^ permalink raw reply
* Re: [PATCH 2/2] video: s3c-fb: Convert to devm style allocation
From: Jingoo Han @ 2011-11-28 7:59 UTC (permalink / raw)
To: linux-fbdev
In-Reply-To: <1322434268-25525-2-git-send-email-broonie@opensource.wolfsonmicro.com>
SGksIE1hcmsgQnJvd24uDQoNCllvdXIgcGF0Y2ggbWFrZXMgYnVpbGQgZXJyb3IgYXMgZm9sbG93
czoNCmRyaXZlcnMvdmlkZW8vczNjLWZiLmM6IEluIGZ1bmN0aW9uICdzM2NfZmJfcHJvYmUnOg0K
ZHJpdmVycy92aWRlby9zM2MtZmIuYzoxMzg1OiBlcnJvcjogaW1wbGljaXQgZGVjbGFyYXRpb24g
b2YgZnVuY3Rpb24gJ2Rldm1fcmVxdWVzdF9hbmRfaW9yZW1hcCcNCmRyaXZlcnMvdmlkZW8vczNj
LWZiLmM6MTM4NTogd2FybmluZzogYXNzaWdubWVudCBtYWtlcyBwb2ludGVyIGZyb20gaW50ZWdl
ciB3aXRob3V0IGEgY2FzdA0KbWFrZVsyXTogKioqIFtkcml2ZXJzL3ZpZGVvL3MzYy1mYi5vXSBF
cnJvciAxDQptYWtlWzFdOiAqKiogW2RyaXZlcnMvdmlkZW9dIEVycm9yIDINCg0KPiAtLS0tLU9y
aWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBNYXJrIEJyb3duIDxicm9vbmllQG9wZW5zb3Vy
Y2Uud29sZnNvbm1pY3JvLmNvbT4NCj4gU3ViamVjdDogW1BBVENIIDIvMl0gdmlkZW86IHMzYy1m
YjogQ29udmVydCB0byBkZXZtIHN0eWxlIGFsbG9jYXRpb24NCj4gDQo+IFNhdmVzIHNvbWUgY29k
ZSwgZXNwZWNpYWxseSB1c2VmdWwgYXMgdGhlIGNvZGUgc2F2ZWQgaXMgbW9zdGx5IGluIHRoZQ0K
PiBpbmZyZXF1ZW50bHkgdGVzdGVkIGVycm9yIHBhdGhzLg0KPiANCj4gU2lnbmVkLW9mZi1ieTog
TWFyayBCcm93biA8YnJvb25pZUBvcGVuc291cmNlLndvbGZzb25taWNyby5jb20+DQo+IC0tLQ0K
PiAgZHJpdmVycy92aWRlby9zM2MtZmIuYyB8ICAgMzIgKysrKystLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0NCj4gIDEgZmlsZXMgY2hhbmdlZCwgNSBpbnNlcnRpb25zKCspLCAyNyBkZWxldGlv
bnMoLSkNCj4gDQo+IGRpZmYgLS1naXQgYS9kcml2ZXJzL3ZpZGVvL3MzYy1mYi5jIGIvZHJpdmVy
cy92aWRlby9zM2MtZmIuYw0KPiBpbmRleCBlODQ2NzdlLi4xMDhiNDY5IDEwMDY0NA0KPiAtLS0g
YS9kcml2ZXJzL3ZpZGVvL3MzYy1mYi5jDQo+ICsrKyBiL2RyaXZlcnMvdmlkZW8vczNjLWZiLmMN
Cj4gQEAgLTE4Niw3ICsxODYsNiBAQCBzdHJ1Y3QgczNjX2ZiX3ZzeW5jIHsNCj4gICAqIHN0cnVj
dCBzM2NfZmIgLSBvdmVyYWxsIGhhcmR3YXJlIHN0YXRlIG9mIHRoZSBoYXJkd2FyZQ0KPiAgICog
QHNsb2NrOiBUaGUgc3BpbmxvY2sgcHJvdGVjdGlvbiBmb3IgdGhpcyBkYXRhIHN0dXJjdHVyZS4N
Cj4gICAqIEBkZXY6IFRoZSBkZXZpY2UgdGhhdCB3ZSBib3VuZCB0bywgZm9yIHByaW50aW5nLCBl
dGMuDQo+IC0gKiBAcmVnc19yZXM6IFRoZSByZXNvdXJjZSB3ZSBjbGFpbWVkIGZvciB0aGUgSU8g
cmVnaXN0ZXJzLg0KPiAgICogQGJ1c19jbGs6IFRoZSBjbGsgKGhjbGspIGZlZWRpbmcgb3VyIGlu
dGVyZmFjZSBhbmQgcG9zc2libHkgcGl4Y2xrLg0KPiAgICogQGxjZF9jbGs6IFRoZSBjbGsgKHNj
bGspIGZlZWRpbmcgcGl4Y2xrLg0KPiAgICogQHJlZ3M6IFRoZSBtYXBwZWQgaGFyZHdhcmUgcmVn
aXN0ZXJzLg0KPiBAQCAtMjAxLDcgKzIwMCw2IEBAIHN0cnVjdCBzM2NfZmJfdnN5bmMgew0KPiAg
c3RydWN0IHMzY19mYiB7DQo+ICAJc3BpbmxvY2tfdAkJc2xvY2s7DQo+ICAJc3RydWN0IGRldmlj
ZQkJKmRldjsNCj4gLQlzdHJ1Y3QgcmVzb3VyY2UJCSpyZWdzX3JlczsNCj4gIAlzdHJ1Y3QgY2xr
CQkqYnVzX2NsazsNCj4gIAlzdHJ1Y3QgY2xrCQkqbGNkX2NsazsNCj4gIAl2b2lkIF9faW9tZW0J
CSpyZWdzOw0KPiBAQCAtMTM0MSw3ICsxMzM5LDcgQEAgc3RhdGljIGludCBfX2RldmluaXQgczNj
X2ZiX3Byb2JlKHN0cnVjdA0KPiBwbGF0Zm9ybV9kZXZpY2UgKnBkZXYpDQo+ICAJCXJldHVybiAt
RUlOVkFMOw0KPiAgCX0NCj4gDQo+IC0Jc2ZiID0ga3phbGxvYyhzaXplb2Yoc3RydWN0IHMzY19m
YiksIEdGUF9LRVJORUwpOw0KPiArCXNmYiA9IGRldm1fa3phbGxvYyhkZXYsIHNpemVvZihzdHJ1
Y3QgczNjX2ZiKSwgR0ZQX0tFUk5FTCk7DQo+ICAJaWYgKCFzZmIpIHsNCj4gIAkJZGV2X2Vycihk
ZXYsICJubyBtZW1vcnkgZm9yIGZyYW1lYnVmZmVyc1xuIik7DQo+ICAJCXJldHVybiAtRU5PTUVN
Ow0KPiBAQCAtMTM4NCwzMyArMTM4MiwyNSBAQCBzdGF0aWMgaW50IF9fZGV2aW5pdCBzM2NfZmJf
cHJvYmUoc3RydWN0DQo+IHBsYXRmb3JtX2RldmljZSAqcGRldikNCj4gIAkJZ290byBlcnJfbGNk
X2NsazsNCj4gIAl9DQo+IA0KPiAtCXNmYi0+cmVnc19yZXMgPSByZXF1ZXN0X21lbV9yZWdpb24o
cmVzLT5zdGFydCwgcmVzb3VyY2Vfc2l6ZShyZXMpLA0KPiAtCQkJCQkgICBkZXZfbmFtZShkZXYp
KTsNCj4gLQlpZiAoIXNmYi0+cmVnc19yZXMpIHsNCj4gLQkJZGV2X2VycihkZXYsICJmYWlsZWQg
dG8gY2xhaW0gcmVnaXN0ZXIgcmVnaW9uXG4iKTsNCj4gLQkJcmV0ID0gLUVOT0VOVDsNCj4gLQkJ
Z290byBlcnJfbGNkX2NsazsNCj4gLQl9DQo+IC0NCj4gLQlzZmItPnJlZ3MgPSBpb3JlbWFwKHJl
cy0+c3RhcnQsIHJlc291cmNlX3NpemUocmVzKSk7DQo+ICsJc2ZiLT5yZWdzID0gZGV2bV9yZXF1
ZXN0X2FuZF9pb3JlbWFwKGRldiwgcmVzKTsNCj4gIAlpZiAoIXNmYi0+cmVncykgew0KPiAgCQlk
ZXZfZXJyKGRldiwgImZhaWxlZCB0byBtYXAgcmVnaXN0ZXJzXG4iKTsNCj4gIAkJcmV0ID0gLUVO
WElPOw0KPiAtCQlnb3RvIGVycl9yZXFfcmVnaW9uOw0KPiArCQlnb3RvIGVycl9sY2RfY2xrOw0K
PiAgCX0NCj4gDQo+ICAJcmVzID0gcGxhdGZvcm1fZ2V0X3Jlc291cmNlKHBkZXYsIElPUkVTT1VS
Q0VfSVJRLCAwKTsNCj4gIAlpZiAoIXJlcykgew0KPiAgCQlkZXZfZXJyKGRldiwgImZhaWxlZCB0
byBhY3F1aXJlIGlycSByZXNvdXJjZVxuIik7DQo+ICAJCXJldCA9IC1FTk9FTlQ7DQo+IC0JCWdv
dG8gZXJyX2lvcmVtYXA7DQo+ICsJCWdvdG8gZXJyX2xjZF9jbGs7DQo+ICAJfQ0KPiAgCXNmYi0+
aXJxX25vID0gcmVzLT5zdGFydDsNCj4gIAlyZXQgPSByZXF1ZXN0X2lycShzZmItPmlycV9ubywg
czNjX2ZiX2lycSwNCj4gIAkJCSAgMCwgInMzY19mYiIsIHNmYik7DQo+ICAJaWYgKHJldCkgew0K
PiAgCQlkZXZfZXJyKGRldiwgImlycSByZXF1ZXN0IGZhaWxlZFxuIik7DQo+IC0JCWdvdG8gZXJy
X2lvcmVtYXA7DQo+ICsJCWdvdG8gZXJyX2xjZF9jbGs7DQo+ICAJfQ0KPiANCj4gIAlkZXZfZGJn
KGRldiwgImdvdCByZXNvdXJjZXMgKHJlZ3MgJXApLCBwcm9iaW5nIHdpbmRvd3NcbiIsIHNmYi0N
Cj4gPnJlZ3MpOw0KPiBAQCAtMTQ2NSwxMiArMTQ1NSw2IEBAIHN0YXRpYyBpbnQgX19kZXZpbml0
IHMzY19mYl9wcm9iZShzdHJ1Y3QNCj4gcGxhdGZvcm1fZGV2aWNlICpwZGV2KQ0KPiAgZXJyX2ly
cToNCj4gIAlmcmVlX2lycShzZmItPmlycV9ubywgc2ZiKTsNCj4gDQo+IC1lcnJfaW9yZW1hcDoN
Cj4gLQlpb3VubWFwKHNmYi0+cmVncyk7DQo+IC0NCj4gLWVycl9yZXFfcmVnaW9uOg0KPiAtCXJl
bGVhc2VfbWVtX3JlZ2lvbihzZmItPnJlZ3NfcmVzLT5zdGFydCwgcmVzb3VyY2Vfc2l6ZShzZmIt
DQo+ID5yZWdzX3JlcykpOw0KPiAtDQo+ICBlcnJfbGNkX2NsazoNCj4gIAlpZiAoIXNmYi0+dmFy
aWFudC5oYXNfY2xrc2VsKSB7DQo+ICAJCWNsa19kaXNhYmxlKHNmYi0+bGNkX2Nsayk7DQo+IEBA
IC0xNDgyLDcgKzE0NjYsNiBAQCBlcnJfYnVzX2NsazoNCj4gIAljbGtfcHV0KHNmYi0+YnVzX2Ns
ayk7DQo+IA0KPiAgZXJyX3NmYjoNCj4gLQlrZnJlZShzZmIpOw0KPiAgCXJldHVybiByZXQ7DQo+
ICB9DQo+IA0KPiBAQCAtMTUwNiw4ICsxNDg5LDYgQEAgc3RhdGljIGludCBfX2RldmV4aXQgczNj
X2ZiX3JlbW92ZShzdHJ1Y3QNCj4gcGxhdGZvcm1fZGV2aWNlICpwZGV2KQ0KPiANCj4gIAlmcmVl
X2lycShzZmItPmlycV9ubywgc2ZiKTsNCj4gDQo+IC0JaW91bm1hcChzZmItPnJlZ3MpOw0KPiAt
DQo+ICAJaWYgKCFzZmItPnZhcmlhbnQuaGFzX2Nsa3NlbCkgew0KPiAgCQljbGtfZGlzYWJsZShz
ZmItPmxjZF9jbGspOw0KPiAgCQljbGtfcHV0KHNmYi0+bGNkX2Nsayk7DQo+IEBAIC0xNTE2LDEy
ICsxNDk3LDkgQEAgc3RhdGljIGludCBfX2RldmV4aXQgczNjX2ZiX3JlbW92ZShzdHJ1Y3QNCj4g
cGxhdGZvcm1fZGV2aWNlICpwZGV2KQ0KPiAgCWNsa19kaXNhYmxlKHNmYi0+YnVzX2Nsayk7DQo+
ICAJY2xrX3B1dChzZmItPmJ1c19jbGspOw0KPiANCj4gLQlyZWxlYXNlX21lbV9yZWdpb24oc2Zi
LT5yZWdzX3Jlcy0+c3RhcnQsIHJlc291cmNlX3NpemUoc2ZiLQ0KPiA+cmVnc19yZXMpKTsNCj4g
LQ0KPiAgCXBtX3J1bnRpbWVfcHV0X3N5bmMoc2ZiLT5kZXYpOw0KPiAgCXBtX3J1bnRpbWVfZGlz
YWJsZShzZmItPmRldik7DQo+IA0KPiAtCWtmcmVlKHNmYik7DQo+ICAJcmV0dXJuIDA7DQo+ICB9
DQo+IA0KPiAtLQ0KPiAxLjcuMQ0KPiANCj4gDQoNCg=
^ permalink raw reply
* Re: [PATCH] video: convert drivers/video/* to use
From: Sascha Hauer @ 2011-11-28 8:43 UTC (permalink / raw)
To: Axel Lin
Cc: linux-kernel, Wan ZongShun, Lennert Buytenhek, Ben Dooks,
Alexey Charkov, Damian Hobson-Garcia, Manuel Lauss,
Florian Tobias Schandinat, linux-fbdev
In-Reply-To: <1322274354.10633.3.camel@phoenix>
On Sat, Nov 26, 2011 at 10:25:54AM +0800, Axel Lin wrote:
> This patch converts the drivers in drivers/video/* to use the
> module_platform_driver() macro which makes the code smaller and a bit
> simpler.
>
> Cc: Wan ZongShun <mcuos.com@gmail.com>
> Cc: Sascha Hauer <s.hauer@pengutronix.de>
> Cc: Lennert Buytenhek <buytenh@marvell.com>
> Cc: Ben Dooks <ben@simtec.co.uk>
> Cc: Alexey Charkov <alchark@gmail.com>
> Cc: Damian Hobson-Garcia <dhobsong@igel.co.jp>
> Cc: Manuel Lauss <mano@roarinelk.homelinux.net>
> Signed-off-by: Axel Lin <axel.lin@gmail.com>
> ---
> drivers/video/mxsfb.c | 13 +------------
For the mxsfb driver:
Acked-by: Sascha Hauer <s.hauer@pengutronix.de>
--
Pengutronix e.K. | |
Industrial Linux Solutions | http://www.pengutronix.de/ |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
^ permalink raw reply
* Re: [PATCH 06/13] OMAPDSS: DSI: Use new lane config in
From: Carlos Chinea @ 2011-11-28 9:08 UTC (permalink / raw)
To: ext Tomi Valkeinen; +Cc: linux-fbdev, linux-omap, archit
In-Reply-To: <1322141381-5395-7-git-send-email-tomi.valkeinen@ti.com>
Hi Tomi,
Just a question/suggestion, bellow:
On Thu, 2011-11-24 at 15:29 +0200, ext Tomi Valkeinen wrote:
> Use the new lane config in dsi_set_lane_config().
>
> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
> ---
> drivers/video/omap2/dss/dsi.c | 84 +++++++++++++++++++---------------------
> 1 files changed, 40 insertions(+), 44 deletions(-)
>
> diff --git a/drivers/video/omap2/dss/dsi.c b/drivers/video/omap2/dss/dsi.c
> index aea110c..ba8d6b3 100644
> --- a/drivers/video/omap2/dss/dsi.c
> +++ b/drivers/video/omap2/dss/dsi.c
> @@ -2154,59 +2154,53 @@ static int dsi_parse_lane_config(struct omap_dss_device *dssdev)
> return 0;
> }
>
> -static void dsi_set_lane_config(struct omap_dss_device *dssdev)
> +static int dsi_set_lane_config(struct omap_dss_device *dssdev)
> {
> struct platform_device *dsidev = dsi_get_dsidev_from_dssdev(dssdev);
> + struct dsi_data *dsi = dsi_get_dsidrv_data(dsidev);
> + static const u8 offsets[] = { 0, 4, 8, 12, 16 };
> + static const enum dsi_lane_function functions[] = {
> + DSI_LANE_CLK,
> + DSI_LANE_DATA1,
> + DSI_LANE_DATA2,
> + DSI_LANE_DATA3,
> + DSI_LANE_DATA4,
> + };
Patch 05 of the series has a function (dsi_parse_lane_config) with
exactly the same static local declaration. Wouldn't be better to have an
static global declaration instead to save some space ? or are the values
from those functions going to differ in the near future ?
Br,
Carlos
> u32 r;
> - int num_lanes_used = dsi_get_num_lanes_used(dssdev);
> -
> - int clk_lane = dssdev->phy.dsi.clk_lane;
> - int data1_lane = dssdev->phy.dsi.data1_lane;
> - int data2_lane = dssdev->phy.dsi.data2_lane;
> - int clk_pol = dssdev->phy.dsi.clk_pol;
> - int data1_pol = dssdev->phy.dsi.data1_pol;
> - int data2_pol = dssdev->phy.dsi.data2_pol;
> + int i;
>
> r = dsi_read_reg(dsidev, DSI_COMPLEXIO_CFG1);
> - r = FLD_MOD(r, clk_lane, 2, 0);
> - r = FLD_MOD(r, clk_pol, 3, 3);
> - r = FLD_MOD(r, data1_lane, 6, 4);
> - r = FLD_MOD(r, data1_pol, 7, 7);
> - r = FLD_MOD(r, data2_lane, 10, 8);
> - r = FLD_MOD(r, data2_pol, 11, 11);
> - if (num_lanes_used > 3) {
> - int data3_lane = dssdev->phy.dsi.data3_lane;
> - int data3_pol = dssdev->phy.dsi.data3_pol;
> -
> - r = FLD_MOD(r, data3_lane, 14, 12);
> - r = FLD_MOD(r, data3_pol, 15, 15);
> +
> + for (i = 0; i < dsi->num_lanes_used; ++i) {
> + unsigned offset = offsets[i];
> + unsigned polarity, lane_number;
> + unsigned t;
> +
> + for (t = 0; t < dsi->num_lanes_supported; ++t)
> + if (dsi->lanes[t].function = functions[i])
> + break;
> +
> + if (t = dsi->num_lanes_supported)
> + return -EINVAL;
> +
> + lane_number = t;
> + polarity = dsi->lanes[t].polarity;
> +
> + r = FLD_MOD(r, lane_number + 1, offset + 2, offset);
> + r = FLD_MOD(r, polarity, offset + 3, offset + 3);
> }
> - if (num_lanes_used > 4) {
> - int data4_lane = dssdev->phy.dsi.data4_lane;
> - int data4_pol = dssdev->phy.dsi.data4_pol;
>
> - r = FLD_MOD(r, data4_lane, 18, 16);
> - r = FLD_MOD(r, data4_pol, 19, 19);
> + /* clear the unused lanes */
> + for (; i < dsi->num_lanes_supported; ++i) {
> + unsigned offset = offsets[i];
> +
> + r = FLD_MOD(r, 0, offset + 2, offset);
> + r = FLD_MOD(r, 0, offset + 3, offset + 3);
> }
> - dsi_write_reg(dsidev, DSI_COMPLEXIO_CFG1, r);
>
> - /* The configuration of the DSI complex I/O (number of data lanes,
> - position, differential order) should not be changed while
> - DSS.DSI_CLK_CRTRL[20] LP_CLK_ENABLE bit is set to 1. In order for
> - the hardware to take into account a new configuration of the complex
> - I/O (done in DSS.DSI_COMPLEXIO_CFG1 register), it is recommended to
> - follow this sequence: First set the DSS.DSI_CTRL[0] IF_EN bit to 1,
> - then reset the DSS.DSI_CTRL[0] IF_EN to 0, then set
> - DSS.DSI_CLK_CTRL[20] LP_CLK_ENABLE to 1 and finally set again the
> - DSS.DSI_CTRL[0] IF_EN bit to 1. If the sequence is not followed, the
> - DSI complex I/O configuration is unknown. */
> + dsi_write_reg(dsidev, DSI_COMPLEXIO_CFG1, r);
>
> - /*
> - REG_FLD_MOD(dsidev, DSI_CTRL, 1, 0, 0);
> - REG_FLD_MOD(dsidev, DSI_CTRL, 0, 0, 0);
> - REG_FLD_MOD(dsidev, DSI_CLK_CTRL, 1, 20, 20);
> - REG_FLD_MOD(dsidev, DSI_CTRL, 1, 0, 0);
> - */
> + return 0;
> }
>
> static inline unsigned ns2ddr(struct platform_device *dsidev, unsigned ns)
> @@ -2473,7 +2467,9 @@ static int dsi_cio_init(struct omap_dss_device *dssdev)
> goto err_scp_clk_dom;
> }
>
> - dsi_set_lane_config(dssdev);
> + r = dsi_set_lane_config(dssdev);
> + if (r)
> + goto err_scp_clk_dom;
>
> /* set TX STOP MODE timer to maximum for this operation */
> l = dsi_read_reg(dsidev, DSI_TIMING1);
^ permalink raw reply
* Re: [PATCH] video: convert drivers/video/* to use module_platform_driver()
From: Damian Hobson-Garcia @ 2011-11-28 9:09 UTC (permalink / raw)
To: Axel Lin
Cc: linux-kernel, Wan ZongShun, Sascha Hauer, Lennert Buytenhek,
Ben Dooks, Alexey Charkov, Manuel Lauss,
Florian Tobias Schandinat, linux-fbdev
In-Reply-To: <1322274354.10633.3.camel@phoenix>
On 2011/11/26 11:25, Axel Lin wrote:
> This patch converts the drivers in drivers/video/* to use the
> module_platform_driver() macro which makes the code smaller and a bit
> simpler.
>
> Cc: Wan ZongShun <mcuos.com@gmail.com>
> Cc: Sascha Hauer <s.hauer@pengutronix.de>
> Cc: Lennert Buytenhek <buytenh@marvell.com>
> Cc: Ben Dooks <ben@simtec.co.uk>
> Cc: Alexey Charkov <alchark@gmail.com>
> Cc: Damian Hobson-Garcia <dhobsong@igel.co.jp>
> Cc: Manuel Lauss <mano@roarinelk.homelinux.net>
> Signed-off-by: Axel Lin <axel.lin@gmail.com>
> ---
> drivers/video/mxsfb.c | 13 +------------
> drivers/video/nuc900fb.c | 13 +------------
> drivers/video/pxa168fb.c | 12 +-----------
> drivers/video/pxa3xx-gcu.c | 15 +--------------
> drivers/video/s3c-fb.c | 13 +------------
> drivers/video/sh7760fb.c | 13 +------------
> drivers/video/sh_mobile_lcdcfb.c | 13 +------------
> drivers/video/sh_mobile_meram.c | 13 +------------
> drivers/video/sm501fb.c | 13 +------------
> drivers/video/vt8500lcdfb.c | 13 +------------
> drivers/video/w100fb.c | 13 +------------
> drivers/video/wm8505fb.c | 13 +------------
> drivers/video/wmt_ge_rops.c | 13 +------------
> drivers/video/xilinxfb.c | 20 +-------------------
> 14 files changed, 14 insertions(+), 176 deletions(-)
for sh_mobile_meram.c
Acked-by: Damian Hobson-Garcia <dhobsong@igel.co.jp>
Thanks very much,
^ permalink raw reply
* Re: [PATCH] video: convert drivers/video/* to use module_platform_driver()
From: Alexey Charkov @ 2011-11-28 9:54 UTC (permalink / raw)
To: Axel Lin
Cc: linux-kernel, Wan ZongShun, Sascha Hauer, Lennert Buytenhek,
Ben Dooks, Damian Hobson-Garcia, Manuel Lauss,
Florian Tobias Schandinat, linux-fbdev
In-Reply-To: <1322274354.10633.3.camel@phoenix>
2011/11/26 Axel Lin <axel.lin@gmail.com>:
> This patch converts the drivers in drivers/video/* to use the
> module_platform_driver() macro which makes the code smaller and a bit
> simpler.
>
> Cc: Wan ZongShun <mcuos.com@gmail.com>
> Cc: Sascha Hauer <s.hauer@pengutronix.de>
> Cc: Lennert Buytenhek <buytenh@marvell.com>
> Cc: Ben Dooks <ben@simtec.co.uk>
> Cc: Alexey Charkov <alchark@gmail.com>
> Cc: Damian Hobson-Garcia <dhobsong@igel.co.jp>
> Cc: Manuel Lauss <mano@roarinelk.homelinux.net>
> Signed-off-by: Axel Lin <axel.lin@gmail.com>
> ---
> drivers/video/mxsfb.c | 13 +------------
> drivers/video/nuc900fb.c | 13 +------------
> drivers/video/pxa168fb.c | 12 +-----------
> drivers/video/pxa3xx-gcu.c | 15 +--------------
> drivers/video/s3c-fb.c | 13 +------------
> drivers/video/sh7760fb.c | 13 +------------
> drivers/video/sh_mobile_lcdcfb.c | 13 +------------
> drivers/video/sh_mobile_meram.c | 13 +------------
> drivers/video/sm501fb.c | 13 +------------
> drivers/video/vt8500lcdfb.c | 13 +------------
> drivers/video/w100fb.c | 13 +------------
> drivers/video/wm8505fb.c | 13 +------------
> drivers/video/wmt_ge_rops.c | 13 +------------
> drivers/video/xilinxfb.c | 20 +-------------------
> 14 files changed, 14 insertions(+), 176 deletions(-)
>
> diff --git a/drivers/video/mxsfb.c b/drivers/video/mxsfb.c
> index d837d63..18742c2 100644
> --- a/drivers/video/mxsfb.c
> +++ b/drivers/video/mxsfb.c
> @@ -902,18 +902,7 @@ static struct platform_driver mxsfb_driver = {
> },
> };
>
> -static int __init mxsfb_init(void)
> -{
> - return platform_driver_register(&mxsfb_driver);
> -}
> -
> -static void __exit mxsfb_exit(void)
> -{
> - platform_driver_unregister(&mxsfb_driver);
> -}
> -
> -module_init(mxsfb_init);
> -module_exit(mxsfb_exit);
> +module_platform_driver(mxsfb_devtype);
Shouldn't this one have 'mxsfb_driver' as the argument instead?
>
> MODULE_DESCRIPTION("Freescale mxs framebuffer driver");
> MODULE_AUTHOR("Sascha Hauer, Pengutronix");
> diff --git a/drivers/video/nuc900fb.c b/drivers/video/nuc900fb.c
> index d1fbbd8..e10f551 100644
> --- a/drivers/video/nuc900fb.c
> +++ b/drivers/video/nuc900fb.c
> @@ -762,18 +762,7 @@ static struct platform_driver nuc900fb_driver = {
> },
> };
>
> -int __devinit nuc900fb_init(void)
> -{
> - return platform_driver_register(&nuc900fb_driver);
> -}
> -
> -static void __exit nuc900fb_cleanup(void)
> -{
> - platform_driver_unregister(&nuc900fb_driver);
> -}
> -
> -module_init(nuc900fb_init);
> -module_exit(nuc900fb_cleanup);
> +module_platform_driver(nuc900fb_driver);
>
> MODULE_DESCRIPTION("Framebuffer driver for the NUC900");
> MODULE_LICENSE("GPL");
> diff --git a/drivers/video/pxa168fb.c b/drivers/video/pxa168fb.c
> index 18ead6f..8384b94 100644
> --- a/drivers/video/pxa168fb.c
> +++ b/drivers/video/pxa168fb.c
> @@ -832,17 +832,7 @@ static struct platform_driver pxa168fb_driver = {
> .remove = __devexit_p(pxa168fb_remove),
> };
>
> -static int __init pxa168fb_init(void)
> -{
> - return platform_driver_register(&pxa168fb_driver);
> -}
> -module_init(pxa168fb_init);
> -
> -static void __exit pxa168fb_exit(void)
> -{
> - platform_driver_unregister(&pxa168fb_driver);
> -}
> -module_exit(pxa168fb_exit);
> +module_platform_driver(pxa168fb_driver);
>
> MODULE_AUTHOR("Lennert Buytenhek <buytenh@marvell.com> "
> "Green Wan <gwan@marvell.com>");
> diff --git a/drivers/video/pxa3xx-gcu.c b/drivers/video/pxa3xx-gcu.c
> index 1ed8b36..1d71c08 100644
> --- a/drivers/video/pxa3xx-gcu.c
> +++ b/drivers/video/pxa3xx-gcu.c
> @@ -747,20 +747,7 @@ static struct platform_driver pxa3xx_gcu_driver = {
> },
> };
>
> -static int __init
> -pxa3xx_gcu_init(void)
> -{
> - return platform_driver_register(&pxa3xx_gcu_driver);
> -}
> -
> -static void __exit
> -pxa3xx_gcu_exit(void)
> -{
> - platform_driver_unregister(&pxa3xx_gcu_driver);
> -}
> -
> -module_init(pxa3xx_gcu_init);
> -module_exit(pxa3xx_gcu_exit);
> +module_platform_driver(pxa3xx_gcu_driver);
>
> MODULE_DESCRIPTION("PXA3xx graphics controller unit driver");
> MODULE_LICENSE("GPL");
> diff --git a/drivers/video/s3c-fb.c b/drivers/video/s3c-fb.c
> index 12eaee0..cf1d11f 100644
> --- a/drivers/video/s3c-fb.c
> +++ b/drivers/video/s3c-fb.c
> @@ -2003,18 +2003,7 @@ static struct platform_driver s3c_fb_driver = {
> },
> };
>
> -static int __init s3c_fb_init(void)
> -{
> - return platform_driver_register(&s3c_fb_driver);
> -}
> -
> -static void __exit s3c_fb_cleanup(void)
> -{
> - platform_driver_unregister(&s3c_fb_driver);
> -}
> -
> -module_init(s3c_fb_init);
> -module_exit(s3c_fb_cleanup);
> +module_platform_driver(s3c_fb_driver);
>
> MODULE_AUTHOR("Ben Dooks <ben@simtec.co.uk>");
> MODULE_DESCRIPTION("Samsung S3C SoC Framebuffer driver");
> diff --git a/drivers/video/sh7760fb.c b/drivers/video/sh7760fb.c
> index 45e47d8..83b16e2 100644
> --- a/drivers/video/sh7760fb.c
> +++ b/drivers/video/sh7760fb.c
> @@ -585,18 +585,7 @@ static struct platform_driver sh7760_lcdc_driver = {
> .remove = __devexit_p(sh7760fb_remove),
> };
>
> -static int __init sh7760fb_init(void)
> -{
> - return platform_driver_register(&sh7760_lcdc_driver);
> -}
> -
> -static void __exit sh7760fb_exit(void)
> -{
> - platform_driver_unregister(&sh7760_lcdc_driver);
> -}
> -
> -module_init(sh7760fb_init);
> -module_exit(sh7760fb_exit);
> +module_platform_driver(sh7760_lcdc_driver);
>
> MODULE_AUTHOR("Nobuhiro Iwamatsu, Manuel Lauss");
> MODULE_DESCRIPTION("FBdev for SH7760/63 integrated LCD Controller");
> diff --git a/drivers/video/sh_mobile_lcdcfb.c b/drivers/video/sh_mobile_lcdcfb.c
> index 1f49ab4..a264ebf 100644
> --- a/drivers/video/sh_mobile_lcdcfb.c
> +++ b/drivers/video/sh_mobile_lcdcfb.c
> @@ -1709,18 +1709,7 @@ static struct platform_driver sh_mobile_lcdc_driver = {
> .remove = sh_mobile_lcdc_remove,
> };
>
> -static int __init sh_mobile_lcdc_init(void)
> -{
> - return platform_driver_register(&sh_mobile_lcdc_driver);
> -}
> -
> -static void __exit sh_mobile_lcdc_exit(void)
> -{
> - platform_driver_unregister(&sh_mobile_lcdc_driver);
> -}
> -
> -module_init(sh_mobile_lcdc_init);
> -module_exit(sh_mobile_lcdc_exit);
> +module_platform_driver(sh_mobile_lcdc_driver);
>
> MODULE_DESCRIPTION("SuperH Mobile LCDC Framebuffer driver");
> MODULE_AUTHOR("Magnus Damm <damm@opensource.se>");
> diff --git a/drivers/video/sh_mobile_meram.c b/drivers/video/sh_mobile_meram.c
> index 4d63490..f45d83e 100644
> --- a/drivers/video/sh_mobile_meram.c
> +++ b/drivers/video/sh_mobile_meram.c
> @@ -679,18 +679,7 @@ static struct platform_driver sh_mobile_meram_driver = {
> .remove = sh_mobile_meram_remove,
> };
>
> -static int __init sh_mobile_meram_init(void)
> -{
> - return platform_driver_register(&sh_mobile_meram_driver);
> -}
> -
> -static void __exit sh_mobile_meram_exit(void)
> -{
> - platform_driver_unregister(&sh_mobile_meram_driver);
> -}
> -
> -module_init(sh_mobile_meram_init);
> -module_exit(sh_mobile_meram_exit);
> +module_platform_driver(sh_mobile_meram_driver);
>
> MODULE_DESCRIPTION("SuperH Mobile MERAM driver");
> MODULE_AUTHOR("Damian Hobson-Garcia / Takanari Hayama");
> diff --git a/drivers/video/sm501fb.c b/drivers/video/sm501fb.c
> index a78254c..3690eff 100644
> --- a/drivers/video/sm501fb.c
> +++ b/drivers/video/sm501fb.c
> @@ -2230,18 +2230,7 @@ static struct platform_driver sm501fb_driver = {
> },
> };
>
> -static int __devinit sm501fb_init(void)
> -{
> - return platform_driver_register(&sm501fb_driver);
> -}
> -
> -static void __exit sm501fb_cleanup(void)
> -{
> - platform_driver_unregister(&sm501fb_driver);
> -}
> -
> -module_init(sm501fb_init);
> -module_exit(sm501fb_cleanup);
> +module_platform_driver(sm501fb_driver);
>
> module_param_named(mode, fb_mode, charp, 0);
> MODULE_PARM_DESC(mode,
> diff --git a/drivers/video/vt8500lcdfb.c b/drivers/video/vt8500lcdfb.c
> index 777c21d..2a5fe6e 100644
> --- a/drivers/video/vt8500lcdfb.c
> +++ b/drivers/video/vt8500lcdfb.c
> @@ -457,18 +457,7 @@ static struct platform_driver vt8500lcd_driver = {
> },
> };
>
> -static int __init vt8500lcd_init(void)
> -{
> - return platform_driver_register(&vt8500lcd_driver);
> -}
> -
> -static void __exit vt8500lcd_exit(void)
> -{
> - platform_driver_unregister(&vt8500lcd_driver);
> -}
> -
> -module_init(vt8500lcd_init);
> -module_exit(vt8500lcd_exit);
> +module_platform_driver(vt8500lcd_driver);
>
> MODULE_AUTHOR("Alexey Charkov <alchark@gmail.com>");
> MODULE_DESCRIPTION("LCD controller driver for VIA VT8500");
> diff --git a/drivers/video/w100fb.c b/drivers/video/w100fb.c
> index 2375e5b..90a2e30 100644
> --- a/drivers/video/w100fb.c
> +++ b/drivers/video/w100fb.c
> @@ -1620,18 +1620,7 @@ static struct platform_driver w100fb_driver = {
> },
> };
>
> -int __init w100fb_init(void)
> -{
> - return platform_driver_register(&w100fb_driver);
> -}
> -
> -void __exit w100fb_cleanup(void)
> -{
> - platform_driver_unregister(&w100fb_driver);
> -}
> -
> -module_init(w100fb_init);
> -module_exit(w100fb_cleanup);
> +module_platform_driver(w100fb_driver);
>
> MODULE_DESCRIPTION("ATI Imageon w100 framebuffer driver");
> MODULE_LICENSE("GPL");
> diff --git a/drivers/video/wm8505fb.c b/drivers/video/wm8505fb.c
> index 96e34a5..c8703bd 100644
> --- a/drivers/video/wm8505fb.c
> +++ b/drivers/video/wm8505fb.c
> @@ -404,18 +404,7 @@ static struct platform_driver wm8505fb_driver = {
> },
> };
>
> -static int __init wm8505fb_init(void)
> -{
> - return platform_driver_register(&wm8505fb_driver);
> -}
> -
> -static void __exit wm8505fb_exit(void)
> -{
> - platform_driver_unregister(&wm8505fb_driver);
> -}
> -
> -module_init(wm8505fb_init);
> -module_exit(wm8505fb_exit);
> +module_platform_driver(wm8505fb_driver);
>
> MODULE_AUTHOR("Ed Spiridonov <edo.rus@gmail.com>");
> MODULE_DESCRIPTION("Framebuffer driver for WMT WM8505");
> diff --git a/drivers/video/wmt_ge_rops.c b/drivers/video/wmt_ge_rops.c
> index 45832b7..55be386 100644
> --- a/drivers/video/wmt_ge_rops.c
> +++ b/drivers/video/wmt_ge_rops.c
> @@ -167,18 +167,7 @@ static struct platform_driver wmt_ge_rops_driver = {
> },
> };
>
> -static int __init wmt_ge_rops_init(void)
> -{
> - return platform_driver_register(&wmt_ge_rops_driver);
> -}
> -
> -static void __exit wmt_ge_rops_exit(void)
> -{
> - platform_driver_unregister(&wmt_ge_rops_driver);
> -}
> -
> -module_init(wmt_ge_rops_init);
> -module_exit(wmt_ge_rops_exit);
> +module_platform_driver(wmt_ge_rops_driver);
>
> MODULE_AUTHOR("Alexey Charkov <alchark@gmail.com");
> MODULE_DESCRIPTION("Accelerators for raster operations using "
For vt8500lcdfb, wm8505fb and wmt_ge_rops:
Acked-by: Alexey Charkov <alchark@gmail.com>
Thanks,
Alexey
> diff --git a/drivers/video/xilinxfb.c b/drivers/video/xilinxfb.c
> index fcb6cd9..1808452 100644
> --- a/drivers/video/xilinxfb.c
> +++ b/drivers/video/xilinxfb.c
> @@ -511,25 +511,7 @@ static struct platform_driver xilinxfb_of_driver = {
> },
> };
>
> -
> -/* ---------------------------------------------------------------------
> - * Module setup and teardown
> - */
> -
> -static int __init
> -xilinxfb_init(void)
> -{
> - return platform_driver_register(&xilinxfb_of_driver);
> -}
> -
> -static void __exit
> -xilinxfb_cleanup(void)
> -{
> - platform_driver_unregister(&xilinxfb_of_driver);
> -}
> -
> -module_init(xilinxfb_init);
> -module_exit(xilinxfb_cleanup);
> +module_platform_driver(xilinxfb_of_driver);
>
> MODULE_AUTHOR("MontaVista Software, Inc. <source@mvista.com>");
> MODULE_DESCRIPTION("Xilinx TFT frame buffer driver");
> --
> 1.7.5.4
>
>
>
>
^ permalink raw reply
* Re: [PATCH] video: convert drivers/video/* to use
From: Lennert Buytenhek @ 2011-11-28 10:01 UTC (permalink / raw)
To: linux-fbdev
In-Reply-To: <1322274354.10633.3.camel@phoenix>
On Mon, Nov 28, 2011 at 02:41:14AM +0000, Jingoo Han wrote:
> > -----Original Message-----
> > Subject: [PATCH] video: convert drivers/video/* to use
> > module_platform_driver()
> >
> > This patch converts the drivers in drivers/video/* to use the
> > module_platform_driver() macro which makes the code smaller and a bit
> > simpler.
> >
> > Cc: Wan ZongShun <mcuos.com@gmail.com>
> > Cc: Sascha Hauer <s.hauer@pengutronix.de>
> > Cc: Lennert Buytenhek <buytenh@wantstofly.org>
For pxa168fb:
Acked-by: Lennert Buytenhek <buytenh@wantstofly.org>
^ permalink raw reply
* Re: [PATCH v3 1/3] fbdev: Add FOURCC-based format configuration API
From: Laurent Pinchart @ 2011-11-28 11:12 UTC (permalink / raw)
To: Florian Tobias Schandinat; +Cc: linux-fbdev, linux-media, magnus.damm
In-Reply-To: <4ED01224.9020703@gmx.de>
Hi Florian,
On Friday 25 November 2011 23:09:40 Florian Tobias Schandinat wrote:
> On 11/24/2011 10:50 AM, Laurent Pinchart wrote:
> > Hi Florian,
> >
> > Gentle ping ?
>
> Sorry, but I'm very busy at the moment and therefore time-consuming things,
> like solving challenging problems, are delayed for some time.
No worries.
> > On Sunday 20 November 2011 11:55:22 Laurent Pinchart wrote:
> >> On Sunday 20 November 2011 03:00:33 Florian Tobias Schandinat wrote:
> >>> Hi Laurent,
> >>>
> >>> On 08/31/2011 11:18 AM, Laurent Pinchart wrote:
> >>>> This API will be used to support YUV frame buffer formats in a
> >>>> standard way.
> >>>
> >>> looks like the union is causing problems. With this patch applied I get
> >>>
> >>> errors like this:
> >>> CC [M] drivers/auxdisplay/cfag12864bfb.o
> >>>
> >>> drivers/auxdisplay/cfag12864bfb.c:57: error: unknown field ‘red’
> >>> specified in initializer
> >>
> >> *ouch*
> >>
> >> gcc < 4.6 chokes on anonymous unions initializers :-/
> >>
> >> [snip]
> >>
> >>>> @@ -246,12 +251,23 @@ struct fb_var_screeninfo {
> >>>>
> >>>> __u32 yoffset; /* resolution */
> >>>>
> >>>> __u32 bits_per_pixel; /* guess what */
> >>>>
> >>>> - __u32 grayscale; /* != 0 Graylevels instead of colors */
> >>>>
> >>>> - struct fb_bitfield red; /* bitfield in fb mem if true color, */
> >>>> - struct fb_bitfield green; /* else only length is significant */
> >>>> - struct fb_bitfield blue;
> >>>> - struct fb_bitfield transp; /* transparency */
> >>>> + union {
> >>>> + struct { /* Legacy format API */
> >>>> + __u32 grayscale; /* 0 = color, 1 = grayscale */
> >>>> + /* bitfields in fb mem if true color, else only */
> >>>> + /* length is significant */
> >>>> + struct fb_bitfield red;
> >>>> + struct fb_bitfield green;
> >>>> + struct fb_bitfield blue;
> >>>> + struct fb_bitfield transp; /* transparency */
> >>>> + };
> >>>> + struct { /* FOURCC-based format API */
> >>>> + __u32 fourcc; /* FOURCC format */
> >>>> + __u32 colorspace;
> >>>> + __u32 reserved[11];
> >>>> + } fourcc;
> >>>> + };
> >>
> >> We can't name the union, otherwise this will change the userspace API.
> >>
> >> We could "fix" the problem on the kernel side with
> >>
> >> #ifdef __KERNEL__
> >>
> >> } color;
> >>
> >> #else
> >>
> >> };
> >>
> >> #endif
> >
> > (and the structure that contains the grayscale, red, green, blue and
> > transp fields would need to be similarly named, the "rgb" name comes to
> > mind)
>
> Which, I guess, would require modifying all drivers?
Unfortunately. That can be automated using coccinelle (I wrote a semantic
patch for that), but it will still be around 10k lines of diff.
> I don't consider that a good idea. Maybe the simplest solution would be to
> drop the union idea and just accept an utterly misleading name "grayscale"
> for setting the FOURCC value.
I'll see if we can add an accessor macro to make it more explicit.
> The colorspace could use one of the reserved fields at the end or do you
> worry that we need to add a lot of other things?
For FOURCC-based format configuration I don't think we will need much more. If
we do need lots of additional fields in the future we might have to consider
an fbdev2 API ;-)
I'll resubmit patches based on this.
--
Regards,
Laurent Pinchart
^ permalink raw reply
* Re: [PATCH 2/2] video: s3c-fb: Convert to devm style allocation
From: Mark Brown @ 2011-11-28 11:41 UTC (permalink / raw)
To: linux-fbdev
In-Reply-To: <1322434268-25525-2-git-send-email-broonie@opensource.wolfsonmicro.com>
On Mon, Nov 28, 2011 at 07:59:27AM +0000, Jingoo Han wrote:
Don't top post!
> Your patch makes build error as follows:
> drivers/video/s3c-fb.c: In function 's3c_fb_probe':
> drivers/video/s3c-fb.c:1385: error: implicit declaration of function 'devm_request_and_ioremap'
> drivers/video/s3c-fb.c:1385: warning: assignment makes pointer from integer without a cast
> make[2]: *** [drivers/video/s3c-fb.o] Error 1
> make[1]: *** [drivers/video] Error 2
This is present in -next.
^ permalink raw reply
* Re: [PATCH 06/13] OMAPDSS: DSI: Use new lane config in
From: Tomi Valkeinen @ 2011-11-28 15:43 UTC (permalink / raw)
To: Carlos Chinea; +Cc: linux-fbdev, linux-omap, archit
In-Reply-To: <1322471339.17335.73.camel@groo>
[-- Attachment #1: Type: text/plain, Size: 2106 bytes --]
On Mon, 2011-11-28 at 11:08 +0200, Carlos Chinea wrote:
> Hi Tomi,
>
> Just a question/suggestion, bellow:
>
> On Thu, 2011-11-24 at 15:29 +0200, ext Tomi Valkeinen wrote:
> > Use the new lane config in dsi_set_lane_config().
> >
> > Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
> > ---
> > drivers/video/omap2/dss/dsi.c | 84 +++++++++++++++++++---------------------
> > 1 files changed, 40 insertions(+), 44 deletions(-)
> >
> > diff --git a/drivers/video/omap2/dss/dsi.c b/drivers/video/omap2/dss/dsi.c
> > index aea110c..ba8d6b3 100644
> > --- a/drivers/video/omap2/dss/dsi.c
> > +++ b/drivers/video/omap2/dss/dsi.c
> > @@ -2154,59 +2154,53 @@ static int dsi_parse_lane_config(struct omap_dss_device *dssdev)
> > return 0;
> > }
> >
> > -static void dsi_set_lane_config(struct omap_dss_device *dssdev)
> > +static int dsi_set_lane_config(struct omap_dss_device *dssdev)
> > {
> > struct platform_device *dsidev = dsi_get_dsidev_from_dssdev(dssdev);
> > + struct dsi_data *dsi = dsi_get_dsidrv_data(dsidev);
> > + static const u8 offsets[] = { 0, 4, 8, 12, 16 };
> > + static const enum dsi_lane_function functions[] = {
> > + DSI_LANE_CLK,
> > + DSI_LANE_DATA1,
> > + DSI_LANE_DATA2,
> > + DSI_LANE_DATA3,
> > + DSI_LANE_DATA4,
> > + };
>
> Patch 05 of the series has a function (dsi_parse_lane_config) with
> exactly the same static local declaration. Wouldn't be better to have an
> static global declaration instead to save some space ? or are the values
> from those functions going to differ in the near future ?
True, the array could be a global, and no, I don't think they'll change
in the near future.
But the data is more like function internal stuff than global data. The
functions want to parse and set the lane configs in particular order,
and use the array for that.
While the order happens to be the same in both functions, I still felt
the array is internal to each function rather than global data. Looking
from outside the function, the order doesn't matter. It's just an
internal detail.
Tomi
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* Re: [PATCH 06/13] OMAPDSS: DSI: Use new lane config in
From: Carlos Chinea @ 2011-11-29 9:09 UTC (permalink / raw)
To: ext Tomi Valkeinen; +Cc: linux-fbdev, linux-omap, archit
In-Reply-To: <1322495015.2364.12.camel@deskari>
On Mon, 2011-11-28 at 17:43 +0200, ext Tomi Valkeinen wrote:
> On Mon, 2011-11-28 at 11:08 +0200, Carlos Chinea wrote:
> > Hi Tomi,
> >
> > Just a question/suggestion, bellow:
> >
> > On Thu, 2011-11-24 at 15:29 +0200, ext Tomi Valkeinen wrote:
> > > Use the new lane config in dsi_set_lane_config().
> > >
> > > Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
> > > ---
> > > drivers/video/omap2/dss/dsi.c | 84 +++++++++++++++++++---------------------
> > > 1 files changed, 40 insertions(+), 44 deletions(-)
> > >
> > > diff --git a/drivers/video/omap2/dss/dsi.c b/drivers/video/omap2/dss/dsi.c
> > > index aea110c..ba8d6b3 100644
> > > --- a/drivers/video/omap2/dss/dsi.c
> > > +++ b/drivers/video/omap2/dss/dsi.c
> > > @@ -2154,59 +2154,53 @@ static int dsi_parse_lane_config(struct omap_dss_device *dssdev)
> > > return 0;
> > > }
> > >
> > > -static void dsi_set_lane_config(struct omap_dss_device *dssdev)
> > > +static int dsi_set_lane_config(struct omap_dss_device *dssdev)
> > > {
> > > struct platform_device *dsidev = dsi_get_dsidev_from_dssdev(dssdev);
> > > + struct dsi_data *dsi = dsi_get_dsidrv_data(dsidev);
> > > + static const u8 offsets[] = { 0, 4, 8, 12, 16 };
> > > + static const enum dsi_lane_function functions[] = {
> > > + DSI_LANE_CLK,
> > > + DSI_LANE_DATA1,
> > > + DSI_LANE_DATA2,
> > > + DSI_LANE_DATA3,
> > > + DSI_LANE_DATA4,
> > > + };
> >
> > Patch 05 of the series has a function (dsi_parse_lane_config) with
> > exactly the same static local declaration. Wouldn't be better to have an
> > static global declaration instead to save some space ? or are the values
> > from those functions going to differ in the near future ?
>
> True, the array could be a global, and no, I don't think they'll change
> in the near future.
>
> But the data is more like function internal stuff than global data. The
> functions want to parse and set the lane configs in particular order,
> and use the array for that.
>
> While the order happens to be the same in both functions, I still felt
> the array is internal to each function rather than global data.
Fine for me then.
Br,
Carlos
> Looking
> from outside the function, the order doesn't matter. It's just an
> internal detail.
>
> Tomi
>
^ permalink raw reply
* [PATCH] video: s3c2410: fix checkpatch error and warnings
From: Jingoo Han @ 2011-11-29 9:48 UTC (permalink / raw)
To: linux-fbdev
This patch fixes the checkpatch errors listed below:
ERROR: do not initialise statics to 0 or NULL
WARNING: Use #include <linux/io.h> instead of <asm/io.h>
WARNING: braces {} are not necessary for single statement blocks
WARNING: braces {} are not necessary for any arm of this statement
WARNING: static char array declaration should probably be static const char
WARNING: line over 80 characters
WARNING: msleep < 20ms can sleep for up to 20ms; see Documentation/timers/timers-howto.txt
Signed-off-by: Jingoo Han <jg1.han@samsung.com>
---
drivers/video/s3c2410fb.c | 29 +++++++++++++++--------------
1 files changed, 15 insertions(+), 14 deletions(-)
diff --git a/drivers/video/s3c2410fb.c b/drivers/video/s3c2410fb.c
index ee4c0df..77f34c6 100644
--- a/drivers/video/s3c2410fb.c
+++ b/drivers/video/s3c2410fb.c
@@ -26,8 +26,8 @@
#include <linux/platform_device.h>
#include <linux/clk.h>
#include <linux/cpufreq.h>
+#include <linux/io.h>
-#include <asm/io.h>
#include <asm/div64.h>
#include <asm/mach/map.h>
@@ -45,10 +45,10 @@
#ifdef CONFIG_FB_S3C2410_DEBUG
static int debug = 1;
#else
-static int debug = 0;
+static int debug;
#endif
-#define dprintk(msg...) if (debug) { printk(KERN_DEBUG "s3c2410fb: " msg); }
+#define dprintk(msg...) if (debug) printk(KERN_DEBUG "s3c2410fb: " msg);
/* useful functions */
@@ -567,11 +567,10 @@ static int s3c2410fb_blank(int blank_mode, struct fb_info *info)
tpal_reg += is_s3c2412(fbi) ? S3C2412_TPAL : S3C2410_TPAL;
- if (blank_mode = FB_BLANK_POWERDOWN) {
+ if (blank_mode = FB_BLANK_POWERDOWN)
s3c2410fb_lcd_enable(fbi, 0);
- } else {
+ else
s3c2410fb_lcd_enable(fbi, 1);
- }
if (blank_mode = FB_BLANK_UNBLANK)
writel(0x0, tpal_reg);
@@ -812,7 +811,7 @@ static inline void s3c2410fb_cpufreq_deregister(struct s3c2410fb_info *info)
#endif
-static char driver_name[] = "s3c2410fb";
+static const char driver_name[] = "s3c2410fb";
static int __devinit s3c24xxfb_probe(struct platform_device *pdev,
enum s3c_drv_type drv_type)
@@ -881,7 +880,10 @@ static int __devinit s3c24xxfb_probe(struct platform_device *pdev,
goto release_mem;
}
- info->irq_base = info->io + ((drv_type = DRV_S3C2412) ? S3C2412_LCDINTBASE : S3C2410_LCDINTBASE);
+ if (drv_type = DRV_S3C2412)
+ info->irq_base = info->io + S3C2412_LCDINTBASE;
+ else
+ info->irq_base = info->io + S3C2410_LCDINTBASE;
dprintk("devinit\n");
@@ -927,7 +929,7 @@ static int __devinit s3c24xxfb_probe(struct platform_device *pdev,
clk_enable(info->clk);
dprintk("got and enabled clock\n");
- msleep(1);
+ usleep_range(1000, 1000);
info->clk_rate = clk_get_rate(info->clk);
@@ -975,9 +977,8 @@ static int __devinit s3c24xxfb_probe(struct platform_device *pdev,
/* create device files */
ret = device_create_file(&pdev->dev, &dev_attr_debug);
- if (ret) {
+ if (ret)
printk(KERN_ERR "failed to add debug attribute\n");
- }
printk(KERN_INFO "fb%d: %s frame buffer device\n",
fbinfo->node, fbinfo->fix.id);
@@ -1027,7 +1028,7 @@ static int __devexit s3c2410fb_remove(struct platform_device *pdev)
s3c2410fb_cpufreq_deregister(info);
s3c2410fb_lcd_enable(info, 0);
- msleep(1);
+ usleep_range(1000, 1000);
s3c2410fb_unmap_video_memory(fbinfo);
@@ -1064,7 +1065,7 @@ static int s3c2410fb_suspend(struct platform_device *dev, pm_message_t state)
* the LCD DMA engine is not going to get back on the bus
* before the clock goes off again (bjd) */
- msleep(1);
+ usleep_range(1000, 1000);
clk_disable(info->clk);
return 0;
@@ -1076,7 +1077,7 @@ static int s3c2410fb_resume(struct platform_device *dev)
struct s3c2410fb_info *info = fbinfo->par;
clk_enable(info->clk);
- msleep(1);
+ usleep_range(1000, 1000);
s3c2410fb_init_registers(fbinfo);
--
1.7.1
^ permalink raw reply related
* Re: [PATCH 09/11] video: Remove redundant spi driver bus
From: Tomi Valkeinen @ 2011-11-29 10:19 UTC (permalink / raw)
To: Lars-Peter Clausen
Cc: linux-kernel, Florian Tobias Schandinat, linux-fbdev, linux-omap
In-Reply-To: <1322148561-25138-9-git-send-email-lars@metafoo.de>
[-- Attachment #1: Type: text/plain, Size: 791 bytes --]
On Thu, 2011-11-24 at 16:29 +0100, Lars-Peter Clausen wrote:
> In ancient times it was necessary to manually initialize the bus field of an
> spi_driver to spi_bus_type. These days this is done in spi_driver_register(),
> so we can drop the manual assignment.
>
> The patch was generated using the following coccinelle semantic patch:
> // <smpl>
> @@
> identifier _driver;
> @@
> struct spi_driver _driver = {
> .driver = {
> - .bus = &spi_bus_type,
> },
> };
> // </smpl>
>
> Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
> Cc: Tomi Valkeinen <tomi.valkeinen@ti.com>
> Cc: Florian Tobias Schandinat <FlorianSchandinat@gmx.de>
> Cc: linux-fbdev@vger.kernel.org
> Cc: linux-omap@vger.kernel.org
Acked-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Tomi
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* [PATCH v4 0/3] fbdev: Add FOURCC-based format configuration API
From: Laurent Pinchart @ 2011-11-29 10:26 UTC (permalink / raw)
To: linux-fbdev; +Cc: linux-media
Hi everybody,
Here's the fourth version of the fbdev FOURCC-based format configuration API.
The third version nearly got merged, but we noticed that gcc choked on
anonymous union initializers. This has been fixed in gcc 4.6, but I don't have
the power to force Linux to set the base gcc version to 4.6 :-)
There were two ways to fix the issue, neither of which was particularly
attractive to me. The first one involved a 10k lines patch that modified all
the drivers, and the second one required using one of the reserved fields in
the fb_var_screeninfo structure. After discussing this with Florian, I've
decided to go for the second fix.
The colorspace field is thus now stored in a previously reserved field. The
fourcc field is still shared with the grayscale field, but doesn't have its
own name anymore.
I've updated the fbdev-test tool to this new API. The code is available in the
fbdev-test yuv branch at
http://git.ideasonboard.org/?pûdev-test.git;a=shortlog;h=refs/heads/yuv.
Laurent Pinchart (3):
fbdev: Add FOURCC-based format configuration API
v4l: Add V4L2_PIX_FMT_NV24 and V4L2_PIX_FMT_NV42 formats
fbdev: sh_mobile_lcdc: Support FOURCC-based format API
Documentation/DocBook/media/v4l/pixfmt-nv24.xml | 129 ++++++++
Documentation/DocBook/media/v4l/pixfmt.xml | 1 +
Documentation/fb/api.txt | 306 +++++++++++++++++++
arch/arm/mach-shmobile/board-ag5evm.c | 2 +-
arch/arm/mach-shmobile/board-ap4evb.c | 4 +-
arch/arm/mach-shmobile/board-mackerel.c | 4 +-
arch/sh/boards/mach-ap325rxa/setup.c | 2 +-
arch/sh/boards/mach-ecovec24/setup.c | 2 +-
arch/sh/boards/mach-kfr2r09/setup.c | 2 +-
arch/sh/boards/mach-migor/setup.c | 4 +-
arch/sh/boards/mach-se/7724/setup.c | 2 +-
drivers/video/sh_mobile_lcdcfb.c | 360 +++++++++++++++--------
include/linux/fb.h | 14 +-
include/linux/videodev2.h | 2 +
include/video/sh_mobile_lcdc.h | 4 +-
15 files changed, 701 insertions(+), 137 deletions(-)
create mode 100644 Documentation/DocBook/media/v4l/pixfmt-nv24.xml
create mode 100644 Documentation/fb/api.txt
--
Regards,
Laurent Pinchart
^ permalink raw reply
* [PATCH v4 1/3] fbdev: Add FOURCC-based format configuration API
From: Laurent Pinchart @ 2011-11-29 10:26 UTC (permalink / raw)
To: linux-fbdev; +Cc: linux-media
In-Reply-To: <1322562419-9934-1-git-send-email-laurent.pinchart@ideasonboard.com>
This API will be used to support YUV frame buffer formats in a standard
way.
Last but not least, create a much needed fbdev API documentation and
document the format setting APIs.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
---
Documentation/fb/api.txt | 306 ++++++++++++++++++++++++++++++++++++++++++++++
include/linux/fb.h | 14 ++-
2 files changed, 316 insertions(+), 4 deletions(-)
create mode 100644 Documentation/fb/api.txt
diff --git a/Documentation/fb/api.txt b/Documentation/fb/api.txt
new file mode 100644
index 0000000..8e2db6c
--- /dev/null
+++ b/Documentation/fb/api.txt
@@ -0,0 +1,306 @@
+ The Frame Buffer Device API
+ ---------------------------
+
+Last revised: June 21, 2011
+
+
+0. Introduction
+---------------
+
+This document describes the frame buffer API used by applications to interact
+with frame buffer devices. In-kernel APIs between device drivers and the frame
+buffer core are not described.
+
+Due to a lack of documentation in the original frame buffer API, drivers
+behaviours differ in subtle (and not so subtle) ways. This document describes
+the recommended API implementation, but applications should be prepared to
+deal with different behaviours.
+
+
+1. Capabilities
+---------------
+
+Device and driver capabilities are reported in the fixed screen information
+capabilities field.
+
+struct fb_fix_screeninfo {
+ ...
+ __u16 capabilities; /* see FB_CAP_* */
+ ...
+};
+
+Application should use those capabilities to find out what features they can
+expect from the device and driver.
+
+- FB_CAP_FOURCC
+
+The driver supports the four character code (FOURCC) based format setting API.
+When supported, formats are configured using a FOURCC instead of manually
+specifying color components layout.
+
+
+2. Types and visuals
+--------------------
+
+Pixels are stored in memory in hardware-dependent formats. Applications need
+to be aware of the pixel storage format in order to write image data to the
+frame buffer memory in the format expected by the hardware.
+
+Formats are described by frame buffer types and visuals. Some visuals require
+additional information, which are stored in the variable screen information
+bits_per_pixel, grayscale, red, green, blue and transp fields.
+
+Visuals describe how color information is encoded and assembled to create
+macropixels. Types describe how macropixels are stored in memory. The following
+types and visuals are supported.
+
+- FB_TYPE_PACKED_PIXELS
+
+Macropixels are stored contiguously in a single plane. If the number of bits
+per macropixel is not a multiple of 8, whether macropixels are padded to the
+next multiple of 8 bits or packed together into bytes depends on the visual.
+
+Padding at end of lines may be present and is then reported through the fixed
+screen information line_length field.
+
+- FB_TYPE_PLANES
+
+Macropixels are split across multiple planes. The number of planes is equal to
+the number of bits per macropixel, with plane i'th storing i'th bit from all
+macropixels.
+
+Planes are located contiguously in memory.
+
+- FB_TYPE_INTERLEAVED_PLANES
+
+Macropixels are split across multiple planes. The number of planes is equal to
+the number of bits per macropixel, with plane i'th storing i'th bit from all
+macropixels.
+
+Planes are interleaved in memory. The interleave factor, defined as the
+distance in bytes between the beginning of two consecutive interleaved blocks
+belonging to different planes, is stored in the fixed screen information
+type_aux field.
+
+- FB_TYPE_FOURCC
+
+Macropixels are stored in memory as described by the format FOURCC identifier
+stored in the variable screen information grayscale field.
+
+- FB_VISUAL_MONO01
+
+Pixels are black or white and stored on a number of bits (typically one)
+specified by the variable screen information bpp field.
+
+Black pixels are represented by all bits set to 1 and white pixels by all bits
+set to 0. When the number of bits per pixel is smaller than 8, several pixels
+are packed together in a byte.
+
+FB_VISUAL_MONO01 is currently used with FB_TYPE_PACKED_PIXELS only.
+
+- FB_VISUAL_MONO10
+
+Pixels are black or white and stored on a number of bits (typically one)
+specified by the variable screen information bpp field.
+
+Black pixels are represented by all bits set to 0 and white pixels by all bits
+set to 1. When the number of bits per pixel is smaller than 8, several pixels
+are packed together in a byte.
+
+FB_VISUAL_MONO01 is currently used with FB_TYPE_PACKED_PIXELS only.
+
+- FB_VISUAL_TRUECOLOR
+
+Pixels are broken into red, green and blue components, and each component
+indexes a read-only lookup table for the corresponding value. Lookup tables
+are device-dependent, and provide linear or non-linear ramps.
+
+Each component is stored in a macropixel according to the variable screen
+information red, green, blue and transp fields.
+
+- FB_VISUAL_PSEUDOCOLOR and FB_VISUAL_STATIC_PSEUDOCOLOR
+
+Pixel values are encoded as indices into a colormap that stores red, green and
+blue components. The colormap is read-only for FB_VISUAL_STATIC_PSEUDOCOLOR
+and read-write for FB_VISUAL_PSEUDOCOLOR.
+
+Each pixel value is stored in the number of bits reported by the variable
+screen information bits_per_pixel field.
+
+- FB_VISUAL_DIRECTCOLOR
+
+Pixels are broken into red, green and blue components, and each component
+indexes a programmable lookup table for the corresponding value.
+
+Each component is stored in a macropixel according to the variable screen
+information red, green, blue and transp fields.
+
+- FB_VISUAL_FOURCC
+
+Pixels are encoded and interpreted as described by the format FOURCC
+identifier stored in the variable screen information grayscale field.
+
+
+3. Screen information
+---------------------
+
+Screen information are queried by applications using the FBIOGET_FSCREENINFO
+and FBIOGET_VSCREENINFO ioctls. Those ioctls take a pointer to a
+fb_fix_screeninfo and fb_var_screeninfo structure respectively.
+
+struct fb_fix_screeninfo stores device independent unchangeable information
+about the frame buffer device and the current format. Those information can't
+be directly modified by applications, but can be changed by the driver when an
+application modifies the format.
+
+struct fb_fix_screeninfo {
+ char id[16]; /* identification string eg "TT Builtin" */
+ unsigned long smem_start; /* Start of frame buffer mem */
+ /* (physical address) */
+ __u32 smem_len; /* Length of frame buffer mem */
+ __u32 type; /* see FB_TYPE_* */
+ __u32 type_aux; /* Interleave for interleaved Planes */
+ __u32 visual; /* see FB_VISUAL_* */
+ __u16 xpanstep; /* zero if no hardware panning */
+ __u16 ypanstep; /* zero if no hardware panning */
+ __u16 ywrapstep; /* zero if no hardware ywrap */
+ __u32 line_length; /* length of a line in bytes */
+ unsigned long mmio_start; /* Start of Memory Mapped I/O */
+ /* (physical address) */
+ __u32 mmio_len; /* Length of Memory Mapped I/O */
+ __u32 accel; /* Indicate to driver which */
+ /* specific chip/card we have */
+ __u16 capabilities; /* see FB_CAP_* */
+ __u16 reserved[2]; /* Reserved for future compatibility */
+};
+
+struct fb_var_screeninfo stores device independent changeable information
+about a frame buffer device, its current format and video mode, as well as
+other miscellaneous parameters.
+
+struct fb_var_screeninfo {
+ __u32 xres; /* visible resolution */
+ __u32 yres;
+ __u32 xres_virtual; /* virtual resolution */
+ __u32 yres_virtual;
+ __u32 xoffset; /* offset from virtual to visible */
+ __u32 yoffset; /* resolution */
+
+ __u32 bits_per_pixel; /* guess what */
+ __u32 grayscale; /* 0 = color, 1 = grayscale, */
+ /* >1 = FOURCC */
+ struct fb_bitfield red; /* bitfield in fb mem if true color, */
+ struct fb_bitfield green; /* else only length is significant */
+ struct fb_bitfield blue;
+ struct fb_bitfield transp; /* transparency */
+
+ __u32 nonstd; /* != 0 Non standard pixel format */
+
+ __u32 activate; /* see FB_ACTIVATE_* */
+
+ __u32 height; /* height of picture in mm */
+ __u32 width; /* width of picture in mm */
+
+ __u32 accel_flags; /* (OBSOLETE) see fb_info.flags */
+
+ /* Timing: All values in pixclocks, except pixclock (of course) */
+ __u32 pixclock; /* pixel clock in ps (pico seconds) */
+ __u32 left_margin; /* time from sync to picture */
+ __u32 right_margin; /* time from picture to sync */
+ __u32 upper_margin; /* time from sync to picture */
+ __u32 lower_margin;
+ __u32 hsync_len; /* length of horizontal sync */
+ __u32 vsync_len; /* length of vertical sync */
+ __u32 sync; /* see FB_SYNC_* */
+ __u32 vmode; /* see FB_VMODE_* */
+ __u32 rotate; /* angle we rotate counter clockwise */
+ __u32 colorspace; /* colorspace for FOURCC-based modes */
+ __u32 reserved[4]; /* Reserved for future compatibility */
+};
+
+To modify variable information, applications call the FBIOPUT_VSCREENINFO
+ioctl with a pointer to a fb_var_screeninfo structure. If the call is
+successful, the driver will update the fixed screen information accordingly.
+
+Instead of filling the complete fb_var_screeninfo structure manually,
+applications should call the FBIOGET_VSCREENINFO ioctl and modify only the
+fields they care about.
+
+
+4. Format configuration
+-----------------------
+
+Frame buffer devices offer two ways to configure the frame buffer format: the
+legacy API and the FOURCC-based API.
+
+
+The legacy API has been the only frame buffer format configuration API for a
+long time and is thus widely used by application. It is the recommended API
+for applications when using RGB and grayscale formats, as well as legacy
+non-standard formats.
+
+To select a format, applications set the fb_var_screeninfo bits_per_pixel field
+to the desired frame buffer depth. Values up to 8 will usually map to
+monochrome, grayscale or pseudocolor visuals, although this is not required.
+
+- For grayscale formats, applications set the grayscale field to one. The red,
+ blue, green and transp fields must be set to 0 by applications and ignored by
+ drivers. Drivers must fill the red, blue and green offsets to 0 and lengths
+ to the bits_per_pixel value.
+
+- For pseudocolor formats, applications set the grayscale field to zero. The
+ red, blue, green and transp fields must be set to 0 by applications and
+ ignored by drivers. Drivers must fill the red, blue and green offsets to 0
+ and lengths to the bits_per_pixel value.
+
+- For truecolor and directcolor formats, applications set the grayscale field
+ to zero, and the red, blue, green and transp fields to describe the layout of
+ color components in memory.
+
+struct fb_bitfield {
+ __u32 offset; /* beginning of bitfield */
+ __u32 length; /* length of bitfield */
+ __u32 msb_right; /* != 0 : Most significant bit is */
+ /* right */
+};
+
+ Pixel values are bits_per_pixel wide and are split in non-overlapping red,
+ green, blue and alpha (transparency) components. Location and size of each
+ component in the pixel value are described by the fb_bitfield offset and
+ length fields. Offset are computed from the right.
+
+ Pixels are always stored in an integer number of bytes. If the number of
+ bits per pixel is not a multiple of 8, pixel values are padded to the next
+ multiple of 8 bits.
+
+Upon successful format configuration, drivers update the fb_fix_screeninfo
+type, visual and line_length fields depending on the selected format.
+
+
+The FOURCC-based API replaces format descriptions by four character codes
+(FOURCC). FOURCCs are abstract identifiers that uniquely define a format
+without explicitly describing it. This is the only API that supports YUV
+formats. Drivers are also encouraged to implement the FOURCC-based API for RGB
+and grayscale formats.
+
+Drivers that support the FOURCC-based API report this capability by setting
+the FB_CAP_FOURCC bit in the fb_fix_screeninfo capabilities field.
+
+FOURCC definitions are located in the linux/videodev2.h header. However, and
+despite starting with the V4L2_PIX_FMT_prefix, they are not restricted to V4L2
+and don't require usage of the V4L2 subsystem. FOURCC documentation is
+available in Documentation/DocBook/v4l/pixfmt.xml.
+
+To select a format, applications set the grayscale field to the desired FOURCC.
+For YUV formats, they should also select the appropriate colorspace by setting
+the colorspace field to one of the colorspaces listed in linux/videodev2.h and
+documented in Documentation/DocBook/v4l/colorspaces.xml.
+
+The red, green, blue and transp fields are not used with the FOURCC-based API.
+For forward compatibility reasons applications must zero those fields, and
+drivers must ignore them. Values other than 0 may get a meaning in future
+extensions.
+
+Upon successful format configuration, drivers update the fb_fix_screeninfo
+type, visual and line_length fields depending on the selected format. The type
+and visual fields are set to FB_TYPE_FOURCC and FB_VISUAL_FOURCC respectively.
diff --git a/include/linux/fb.h b/include/linux/fb.h
index 1d6836c..c18122f 100644
--- a/include/linux/fb.h
+++ b/include/linux/fb.h
@@ -45,6 +45,7 @@
#define FB_TYPE_INTERLEAVED_PLANES 2 /* Interleaved planes */
#define FB_TYPE_TEXT 3 /* Text/attributes */
#define FB_TYPE_VGA_PLANES 4 /* EGA/VGA planes */
+#define FB_TYPE_FOURCC 5 /* Type identified by a V4L2 FOURCC */
#define FB_AUX_TEXT_MDA 0 /* Monochrome text */
#define FB_AUX_TEXT_CGA 1 /* CGA/EGA/VGA Color text */
@@ -69,6 +70,7 @@
#define FB_VISUAL_PSEUDOCOLOR 3 /* Pseudo color (like atari) */
#define FB_VISUAL_DIRECTCOLOR 4 /* Direct color */
#define FB_VISUAL_STATIC_PSEUDOCOLOR 5 /* Pseudo color readonly */
+#define FB_VISUAL_FOURCC 6 /* Visual identified by a V4L2 FOURCC */
#define FB_ACCEL_NONE 0 /* no hardware accelerator */
#define FB_ACCEL_ATARIBLITT 1 /* Atari Blitter */
@@ -154,6 +156,8 @@
#define FB_ACCEL_PUV3_UNIGFX 0xa0 /* PKUnity-v3 Unigfx */
+#define FB_CAP_FOURCC 1 /* Device supports FOURCC-based formats */
+
struct fb_fix_screeninfo {
char id[16]; /* identification string eg "TT Builtin" */
unsigned long smem_start; /* Start of frame buffer mem */
@@ -171,7 +175,8 @@ struct fb_fix_screeninfo {
__u32 mmio_len; /* Length of Memory Mapped I/O */
__u32 accel; /* Indicate to driver which */
/* specific chip/card we have */
- __u16 reserved[3]; /* Reserved for future compatibility */
+ __u16 capabilities; /* see FB_CAP_* */
+ __u16 reserved[2]; /* Reserved for future compatibility */
};
/* Interpretation of offset for color fields: All offsets are from the right,
@@ -246,8 +251,8 @@ struct fb_var_screeninfo {
__u32 yoffset; /* resolution */
__u32 bits_per_pixel; /* guess what */
- __u32 grayscale; /* != 0 Graylevels instead of colors */
-
+ __u32 grayscale; /* 0 = color, 1 = grayscale, */
+ /* >1 = FOURCC */
struct fb_bitfield red; /* bitfield in fb mem if true color, */
struct fb_bitfield green; /* else only length is significant */
struct fb_bitfield blue;
@@ -273,7 +278,8 @@ struct fb_var_screeninfo {
__u32 sync; /* see FB_SYNC_* */
__u32 vmode; /* see FB_VMODE_* */
__u32 rotate; /* angle we rotate counter clockwise */
- __u32 reserved[5]; /* Reserved for future compatibility */
+ __u32 colorspace; /* colorspace for FOURCC-based modes */
+ __u32 reserved[4]; /* Reserved for future compatibility */
};
struct fb_cmap {
--
1.7.3.4
^ permalink raw reply related
* [PATCH v4 2/3] v4l: Add V4L2_PIX_FMT_NV24 and V4L2_PIX_FMT_NV42 formats
From: Laurent Pinchart @ 2011-11-29 10:26 UTC (permalink / raw)
To: linux-fbdev; +Cc: linux-media
In-Reply-To: <1322562419-9934-1-git-send-email-laurent.pinchart@ideasonboard.com>
NV24 and NV42 are planar YCbCr 4:4:4 and YCrCb 4:4:4 formats with a
luma plane followed by an interleaved chroma plane.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
---
Documentation/DocBook/media/v4l/pixfmt-nv24.xml | 129 +++++++++++++++++++++++
Documentation/DocBook/media/v4l/pixfmt.xml | 1 +
include/linux/videodev2.h | 2 +
3 files changed, 132 insertions(+), 0 deletions(-)
create mode 100644 Documentation/DocBook/media/v4l/pixfmt-nv24.xml
diff --git a/Documentation/DocBook/media/v4l/pixfmt-nv24.xml b/Documentation/DocBook/media/v4l/pixfmt-nv24.xml
new file mode 100644
index 0000000..939c803
--- /dev/null
+++ b/Documentation/DocBook/media/v4l/pixfmt-nv24.xml
@@ -0,0 +1,129 @@
+ <refentry>
+ <refmeta>
+ <refentrytitle>V4L2_PIX_FMT_NV24 ('NV24'), V4L2_PIX_FMT_NV42 ('NV42')</refentrytitle>
+ &manvol;
+ </refmeta>
+ <refnamediv>
+ <refname id="V4L2-PIX-FMT-NV24"><constant>V4L2_PIX_FMT_NV24</constant></refname>
+ <refname id="V4L2-PIX-FMT-NV42"><constant>V4L2_PIX_FMT_NV42</constant></refname>
+ <refpurpose>Formats with full horizontal and vertical
+chroma resolutions, also known as YUV 4:4:4. One luminance and one
+chrominance plane with alternating chroma samples as opposed to
+<constant>V4L2_PIX_FMT_YVU420</constant></refpurpose>
+ </refnamediv>
+ <refsect1>
+ <title>Description</title>
+
+ <para>These are two-plane versions of the YUV 4:4:4 format. The three
+ components are separated into two sub-images or planes. The Y plane is
+ first, with each Y sample stored in one byte per pixel. For
+ <constant>V4L2_PIX_FMT_NV24</constant>, a combined CbCr plane
+ immediately follows the Y plane in memory. The CbCr plane has the same
+ width and height, in pixels, as the Y plane (and the image). Each line
+ contains one CbCr pair per pixel, with each Cb and Cr sample stored in
+ one byte. <constant>V4L2_PIX_FMT_NV42</constant> is the same except that
+ the Cb and Cr samples are swapped, the CrCb plane starts with a Cr
+ sample.</para>
+
+ <para>If the Y plane has pad bytes after each row, then the CbCr plane
+ has twice as many pad bytes after its rows.</para>
+
+ <example>
+ <title><constant>V4L2_PIX_FMT_NV24</constant> 4 × 4
+pixel image</title>
+
+ <formalpara>
+ <title>Byte Order.</title>
+ <para>Each cell is one byte.
+ <informaltable frame="none">
+ <tgroup cols="9" align="center">
+ <colspec align="left" colwidth="2*" />
+ <tbody valign="top">
+ <row>
+ <entry>start + 0:</entry>
+ <entry>Y'<subscript>00</subscript></entry>
+ <entry>Y'<subscript>01</subscript></entry>
+ <entry>Y'<subscript>02</subscript></entry>
+ <entry>Y'<subscript>03</subscript></entry>
+ </row>
+ <row>
+ <entry>start + 4:</entry>
+ <entry>Y'<subscript>10</subscript></entry>
+ <entry>Y'<subscript>11</subscript></entry>
+ <entry>Y'<subscript>12</subscript></entry>
+ <entry>Y'<subscript>13</subscript></entry>
+ </row>
+ <row>
+ <entry>start + 8:</entry>
+ <entry>Y'<subscript>20</subscript></entry>
+ <entry>Y'<subscript>21</subscript></entry>
+ <entry>Y'<subscript>22</subscript></entry>
+ <entry>Y'<subscript>23</subscript></entry>
+ </row>
+ <row>
+ <entry>start + 12:</entry>
+ <entry>Y'<subscript>30</subscript></entry>
+ <entry>Y'<subscript>31</subscript></entry>
+ <entry>Y'<subscript>32</subscript></entry>
+ <entry>Y'<subscript>33</subscript></entry>
+ </row>
+ <row>
+ <entry>start + 16:</entry>
+ <entry>Cb<subscript>00</subscript></entry>
+ <entry>Cr<subscript>00</subscript></entry>
+ <entry>Cb<subscript>01</subscript></entry>
+ <entry>Cr<subscript>01</subscript></entry>
+ <entry>Cb<subscript>02</subscript></entry>
+ <entry>Cr<subscript>02</subscript></entry>
+ <entry>Cb<subscript>03</subscript></entry>
+ <entry>Cr<subscript>03</subscript></entry>
+ </row>
+ <row>
+ <entry>start + 24:</entry>
+ <entry>Cb<subscript>10</subscript></entry>
+ <entry>Cr<subscript>10</subscript></entry>
+ <entry>Cb<subscript>11</subscript></entry>
+ <entry>Cr<subscript>11</subscript></entry>
+ <entry>Cb<subscript>12</subscript></entry>
+ <entry>Cr<subscript>12</subscript></entry>
+ <entry>Cb<subscript>13</subscript></entry>
+ <entry>Cr<subscript>13</subscript></entry>
+ </row>
+ <row>
+ <entry>start + 32:</entry>
+ <entry>Cb<subscript>20</subscript></entry>
+ <entry>Cr<subscript>20</subscript></entry>
+ <entry>Cb<subscript>21</subscript></entry>
+ <entry>Cr<subscript>21</subscript></entry>
+ <entry>Cb<subscript>22</subscript></entry>
+ <entry>Cr<subscript>22</subscript></entry>
+ <entry>Cb<subscript>23</subscript></entry>
+ <entry>Cr<subscript>23</subscript></entry>
+ </row>
+ <row>
+ <entry>start + 40:</entry>
+ <entry>Cb<subscript>30</subscript></entry>
+ <entry>Cr<subscript>30</subscript></entry>
+ <entry>Cb<subscript>31</subscript></entry>
+ <entry>Cr<subscript>31</subscript></entry>
+ <entry>Cb<subscript>32</subscript></entry>
+ <entry>Cr<subscript>32</subscript></entry>
+ <entry>Cb<subscript>33</subscript></entry>
+ <entry>Cr<subscript>33</subscript></entry>
+ </row>
+ </tbody>
+ </tgroup>
+ </informaltable>
+ </para>
+ </formalpara>
+ </example>
+ </refsect1>
+ </refentry>
+
+ <!--
+Local Variables:
+mode: sgml
+sgml-parent-document: "pixfmt.sgml"
+indent-tabs-mode: nil
+End:
+ -->
diff --git a/Documentation/DocBook/media/v4l/pixfmt.xml b/Documentation/DocBook/media/v4l/pixfmt.xml
index 2ff6b77..aef4615 100644
--- a/Documentation/DocBook/media/v4l/pixfmt.xml
+++ b/Documentation/DocBook/media/v4l/pixfmt.xml
@@ -714,6 +714,7 @@ information.</para>
&sub-nv12m;
&sub-nv12mt;
&sub-nv16;
+ &sub-nv24;
&sub-m420;
</section>
diff --git a/include/linux/videodev2.h b/include/linux/videodev2.h
index 4b752d5..d2f74f8 100644
--- a/include/linux/videodev2.h
+++ b/include/linux/videodev2.h
@@ -343,6 +343,8 @@ struct v4l2_pix_format {
#define V4L2_PIX_FMT_NV21 v4l2_fourcc('N', 'V', '2', '1') /* 12 Y/CrCb 4:2:0 */
#define V4L2_PIX_FMT_NV16 v4l2_fourcc('N', 'V', '1', '6') /* 16 Y/CbCr 4:2:2 */
#define V4L2_PIX_FMT_NV61 v4l2_fourcc('N', 'V', '6', '1') /* 16 Y/CrCb 4:2:2 */
+#define V4L2_PIX_FMT_NV24 v4l2_fourcc('N', 'V', '2', '4') /* 24 Y/CbCr 4:4:4 */
+#define V4L2_PIX_FMT_NV42 v4l2_fourcc('N', 'V', '4', '2') /* 24 Y/CrCb 4:4:4 */
/* two non contiguous planes - one Y, one Cr + Cb interleaved */
#define V4L2_PIX_FMT_NV12M v4l2_fourcc('N', 'M', '1', '2') /* 12 Y/CbCr 4:2:0 */
--
1.7.3.4
^ permalink raw reply related
* [PATCH v4 3/3] fbdev: sh_mobile_lcdc: Support FOURCC-based format API
From: Laurent Pinchart @ 2011-11-29 10:26 UTC (permalink / raw)
To: linux-fbdev; +Cc: linux-media
In-Reply-To: <1322562419-9934-1-git-send-email-laurent.pinchart@ideasonboard.com>
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
---
arch/arm/mach-shmobile/board-ag5evm.c | 2 +-
arch/arm/mach-shmobile/board-ap4evb.c | 4 +-
arch/arm/mach-shmobile/board-mackerel.c | 4 +-
arch/sh/boards/mach-ap325rxa/setup.c | 2 +-
arch/sh/boards/mach-ecovec24/setup.c | 2 +-
arch/sh/boards/mach-kfr2r09/setup.c | 2 +-
arch/sh/boards/mach-migor/setup.c | 4 +-
arch/sh/boards/mach-se/7724/setup.c | 2 +-
drivers/video/sh_mobile_lcdcfb.c | 360 ++++++++++++++++++++----------
include/video/sh_mobile_lcdc.h | 4 +-
10 files changed, 253 insertions(+), 133 deletions(-)
diff --git a/arch/arm/mach-shmobile/board-ag5evm.c b/arch/arm/mach-shmobile/board-ag5evm.c
index 7e3dd73..80319f2 100644
--- a/arch/arm/mach-shmobile/board-ag5evm.c
+++ b/arch/arm/mach-shmobile/board-ag5evm.c
@@ -271,7 +271,7 @@ static struct sh_mobile_lcdc_info lcdc0_info = {
.flags = LCDC_FLAGS_DWPOL,
.lcd_size_cfg.width = 44,
.lcd_size_cfg.height = 79,
- .bpp = 16,
+ .fourcc = V4L2_PIX_FMT_RGB565,
.lcd_cfg = lcdc0_modes,
.num_cfg = ARRAY_SIZE(lcdc0_modes),
.board_cfg = {
diff --git a/arch/arm/mach-shmobile/board-ap4evb.c b/arch/arm/mach-shmobile/board-ap4evb.c
index 904b608..42b4dda 100644
--- a/arch/arm/mach-shmobile/board-ap4evb.c
+++ b/arch/arm/mach-shmobile/board-ap4evb.c
@@ -491,7 +491,7 @@ static struct sh_mobile_lcdc_info lcdc_info = {
.meram_dev = &meram_info,
.ch[0] = {
.chan = LCDC_CHAN_MAINLCD,
- .bpp = 16,
+ .fourcc = V4L2_PIX_FMT_RGB565,
.lcd_cfg = ap4evb_lcdc_modes,
.num_cfg = ARRAY_SIZE(ap4evb_lcdc_modes),
.meram_cfg = &lcd_meram_cfg,
@@ -813,7 +813,7 @@ static struct sh_mobile_lcdc_info sh_mobile_lcdc1_info = {
.meram_dev = &meram_info,
.ch[0] = {
.chan = LCDC_CHAN_MAINLCD,
- .bpp = 16,
+ .fourcc = V4L2_PIX_FMT_RGB565,
.interface_type = RGB24,
.clock_divider = 1,
.flags = LCDC_FLAGS_DWPOL,
diff --git a/arch/arm/mach-shmobile/board-mackerel.c b/arch/arm/mach-shmobile/board-mackerel.c
index 9c5e598..7db6a17 100644
--- a/arch/arm/mach-shmobile/board-mackerel.c
+++ b/arch/arm/mach-shmobile/board-mackerel.c
@@ -388,7 +388,7 @@ static struct sh_mobile_lcdc_info lcdc_info = {
.clock_source = LCDC_CLK_BUS,
.ch[0] = {
.chan = LCDC_CHAN_MAINLCD,
- .bpp = 16,
+ .fourcc = V4L2_PIX_FMT_RGB565,
.lcd_cfg = mackerel_lcdc_modes,
.num_cfg = ARRAY_SIZE(mackerel_lcdc_modes),
.interface_type = RGB24,
@@ -451,7 +451,7 @@ static struct sh_mobile_lcdc_info hdmi_lcdc_info = {
.clock_source = LCDC_CLK_EXTERNAL,
.ch[0] = {
.chan = LCDC_CHAN_MAINLCD,
- .bpp = 16,
+ .fourcc = V4L2_PIX_FMT_RGB565,
.interface_type = RGB24,
.clock_divider = 1,
.flags = LCDC_FLAGS_DWPOL,
diff --git a/arch/sh/boards/mach-ap325rxa/setup.c b/arch/sh/boards/mach-ap325rxa/setup.c
index 7030f4c..7977911 100644
--- a/arch/sh/boards/mach-ap325rxa/setup.c
+++ b/arch/sh/boards/mach-ap325rxa/setup.c
@@ -207,7 +207,7 @@ static struct sh_mobile_lcdc_info lcdc_info = {
.clock_source = LCDC_CLK_EXTERNAL,
.ch[0] = {
.chan = LCDC_CHAN_MAINLCD,
- .bpp = 16,
+ .fourcc = V4L2_PIX_FMT_RGB565,
.interface_type = RGB18,
.clock_divider = 1,
.lcd_cfg = ap325rxa_lcdc_modes,
diff --git a/arch/sh/boards/mach-ecovec24/setup.c b/arch/sh/boards/mach-ecovec24/setup.c
index 92ddce4..1d4a706 100644
--- a/arch/sh/boards/mach-ecovec24/setup.c
+++ b/arch/sh/boards/mach-ecovec24/setup.c
@@ -330,7 +330,7 @@ static struct sh_mobile_lcdc_info lcdc_info = {
.ch[0] = {
.interface_type = RGB18,
.chan = LCDC_CHAN_MAINLCD,
- .bpp = 16,
+ .fourcc = V4L2_PIX_FMT_RGB565,
.lcd_size_cfg = { /* 7.0 inch */
.width = 152,
.height = 91,
diff --git a/arch/sh/boards/mach-kfr2r09/setup.c b/arch/sh/boards/mach-kfr2r09/setup.c
index f65271a..208c9b0 100644
--- a/arch/sh/boards/mach-kfr2r09/setup.c
+++ b/arch/sh/boards/mach-kfr2r09/setup.c
@@ -146,7 +146,7 @@ static struct sh_mobile_lcdc_info kfr2r09_sh_lcdc_info = {
.clock_source = LCDC_CLK_BUS,
.ch[0] = {
.chan = LCDC_CHAN_MAINLCD,
- .bpp = 16,
+ .fourcc = V4L2_PIX_FMT_RGB565,
.interface_type = SYS18,
.clock_divider = 6,
.flags = LCDC_FLAGS_DWPOL,
diff --git a/arch/sh/boards/mach-migor/setup.c b/arch/sh/boards/mach-migor/setup.c
index e4c8119..ccf61fb 100644
--- a/arch/sh/boards/mach-migor/setup.c
+++ b/arch/sh/boards/mach-migor/setup.c
@@ -244,7 +244,7 @@ static struct sh_mobile_lcdc_info sh_mobile_lcdc_info = {
.clock_source = LCDC_CLK_BUS,
.ch[0] = {
.chan = LCDC_CHAN_MAINLCD,
- .bpp = 16,
+ .fourcc = V4L2_PIX_FMT_RGB565,
.interface_type = RGB16,
.clock_divider = 2,
.lcd_cfg = migor_lcd_modes,
@@ -258,7 +258,7 @@ static struct sh_mobile_lcdc_info sh_mobile_lcdc_info = {
.clock_source = LCDC_CLK_PERIPHERAL,
.ch[0] = {
.chan = LCDC_CHAN_MAINLCD,
- .bpp = 16,
+ .fourcc = V4L2_PIX_FMT_RGB565,
.interface_type = SYS16A,
.clock_divider = 10,
.lcd_cfg = migor_lcd_modes,
diff --git a/arch/sh/boards/mach-se/7724/setup.c b/arch/sh/boards/mach-se/7724/setup.c
index b747c0a..3aab70c 100644
--- a/arch/sh/boards/mach-se/7724/setup.c
+++ b/arch/sh/boards/mach-se/7724/setup.c
@@ -179,7 +179,7 @@ static struct sh_mobile_lcdc_info lcdc_info = {
.clock_source = LCDC_CLK_EXTERNAL,
.ch[0] = {
.chan = LCDC_CHAN_MAINLCD,
- .bpp = 16,
+ .fourcc = V4L2_PIX_FMT_RGB565,
.clock_divider = 1,
.lcd_size_cfg = { /* 7.0 inch */
.width = 152,
diff --git a/drivers/video/sh_mobile_lcdcfb.c b/drivers/video/sh_mobile_lcdcfb.c
index 1f49ab4..2046666 100644
--- a/drivers/video/sh_mobile_lcdcfb.c
+++ b/drivers/video/sh_mobile_lcdcfb.c
@@ -17,6 +17,7 @@
#include <linux/platform_device.h>
#include <linux/dma-mapping.h>
#include <linux/interrupt.h>
+#include <linux/videodev2.h>
#include <linux/vmalloc.h>
#include <linux/ioctl.h>
#include <linux/slab.h>
@@ -102,7 +103,7 @@ struct sh_mobile_lcdc_priv {
struct sh_mobile_lcdc_chan ch[2];
struct notifier_block notifier;
int started;
- int forced_bpp; /* 2 channel LCDC must share bpp setting */
+ int forced_fourcc; /* 2 channel LCDC must share fourcc setting */
struct sh_mobile_meram_info *meram_dev;
};
@@ -215,6 +216,47 @@ struct sh_mobile_lcdc_sys_bus_ops sh_mobile_lcdc_sys_bus_ops = {
lcdc_sys_read_data,
};
+static int sh_mobile_format_fourcc(const struct fb_var_screeninfo *var)
+{
+ if (var->grayscale > 1)
+ return var->grayscale;
+
+ switch (var->bits_per_pixel) {
+ case 16:
+ return V4L2_PIX_FMT_RGB565;
+ case 24:
+ return V4L2_PIX_FMT_BGR24;
+ case 32:
+ return V4L2_PIX_FMT_BGR32;
+ default:
+ return 0;
+ }
+}
+
+static int sh_mobile_format_is_fourcc(const struct fb_var_screeninfo *var)
+{
+ return var->grayscale > 1;
+}
+
+static bool sh_mobile_format_is_yuv(const struct fb_var_screeninfo *var)
+{
+ if (var->grayscale <= 1)
+ return false;
+
+ switch (var->grayscale) {
+ case V4L2_PIX_FMT_NV12:
+ case V4L2_PIX_FMT_NV21:
+ case V4L2_PIX_FMT_NV16:
+ case V4L2_PIX_FMT_NV61:
+ case V4L2_PIX_FMT_NV24:
+ case V4L2_PIX_FMT_NV42:
+ return true;
+
+ default:
+ return false;
+ }
+}
+
static void sh_mobile_lcdc_clk_on(struct sh_mobile_lcdc_priv *priv)
{
if (atomic_inc_and_test(&priv->hw_usecnt)) {
@@ -435,7 +477,6 @@ static void __sh_mobile_lcdc_start(struct sh_mobile_lcdc_priv *priv)
{
struct sh_mobile_lcdc_chan *ch;
unsigned long tmp;
- int bpp = 0;
int k, m;
/* Enable LCDC channels. Read data from external memory, avoid using the
@@ -454,9 +495,6 @@ static void __sh_mobile_lcdc_start(struct sh_mobile_lcdc_priv *priv)
if (!ch->enabled)
continue;
- if (!bpp)
- bpp = ch->info->var.bits_per_pixel;
-
/* Power supply */
lcdc_write_chan(ch, LDPMR, 0);
@@ -487,31 +525,37 @@ static void __sh_mobile_lcdc_start(struct sh_mobile_lcdc_priv *priv)
sh_mobile_lcdc_geometry(ch);
- if (ch->info->var.nonstd) {
- tmp = (ch->info->var.nonstd << 16);
- switch (ch->info->var.bits_per_pixel) {
- case 12:
- tmp |= LDDFR_YF_420;
- break;
- case 16:
- tmp |= LDDFR_YF_422;
- break;
- case 24:
- default:
- tmp |= LDDFR_YF_444;
- break;
- }
- } else {
- switch (ch->info->var.bits_per_pixel) {
- case 16:
- tmp = LDDFR_PKF_RGB16;
- break;
- case 24:
- tmp = LDDFR_PKF_RGB24;
+ switch (sh_mobile_format_fourcc(&ch->info->var)) {
+ case V4L2_PIX_FMT_RGB565:
+ tmp = LDDFR_PKF_RGB16;
+ break;
+ case V4L2_PIX_FMT_BGR24:
+ tmp = LDDFR_PKF_RGB24;
+ break;
+ case V4L2_PIX_FMT_BGR32:
+ tmp = LDDFR_PKF_ARGB32;
+ break;
+ case V4L2_PIX_FMT_NV12:
+ case V4L2_PIX_FMT_NV21:
+ tmp = LDDFR_CC | LDDFR_YF_420;
+ break;
+ case V4L2_PIX_FMT_NV16:
+ case V4L2_PIX_FMT_NV61:
+ tmp = LDDFR_CC | LDDFR_YF_422;
+ break;
+ case V4L2_PIX_FMT_NV24:
+ case V4L2_PIX_FMT_NV42:
+ tmp = LDDFR_CC | LDDFR_YF_444;
+ break;
+ }
+
+ if (sh_mobile_format_is_yuv(&ch->info->var)) {
+ switch (ch->info->var.colorspace) {
+ case V4L2_COLORSPACE_REC709:
+ tmp |= LDDFR_CF1;
break;
- case 32:
- default:
- tmp = LDDFR_PKF_ARGB32;
+ case V4L2_COLORSPACE_JPEG:
+ tmp |= LDDFR_CF0;
break;
}
}
@@ -519,7 +563,7 @@ static void __sh_mobile_lcdc_start(struct sh_mobile_lcdc_priv *priv)
lcdc_write_chan(ch, LDDFR, tmp);
lcdc_write_chan(ch, LDMLSR, ch->pitch);
lcdc_write_chan(ch, LDSA1R, ch->base_addr_y);
- if (ch->info->var.nonstd)
+ if (sh_mobile_format_is_yuv(&ch->info->var))
lcdc_write_chan(ch, LDSA2R, ch->base_addr_c);
/* When using deferred I/O mode, configure the LCDC for one-shot
@@ -536,21 +580,23 @@ static void __sh_mobile_lcdc_start(struct sh_mobile_lcdc_priv *priv)
}
/* Word and long word swap. */
- if (priv->ch[0].info->var.nonstd)
+ switch (sh_mobile_format_fourcc(&priv->ch[0].info->var)) {
+ case V4L2_PIX_FMT_RGB565:
+ case V4L2_PIX_FMT_NV21:
+ case V4L2_PIX_FMT_NV61:
+ case V4L2_PIX_FMT_NV42:
+ tmp = LDDDSR_LS | LDDDSR_WS;
+ break;
+ case V4L2_PIX_FMT_BGR24:
+ case V4L2_PIX_FMT_NV12:
+ case V4L2_PIX_FMT_NV16:
+ case V4L2_PIX_FMT_NV24:
tmp = LDDDSR_LS | LDDDSR_WS | LDDDSR_BS;
- else {
- switch (bpp) {
- case 16:
- tmp = LDDDSR_LS | LDDDSR_WS;
- break;
- case 24:
- tmp = LDDDSR_LS | LDDDSR_WS | LDDDSR_BS;
- break;
- case 32:
- default:
- tmp = LDDDSR_LS;
- break;
- }
+ break;
+ case V4L2_PIX_FMT_BGR32:
+ default:
+ tmp = LDDDSR_LS;
+ break;
}
lcdc_write(priv, _LDDDSR, tmp);
@@ -622,12 +668,24 @@ static int sh_mobile_lcdc_start(struct sh_mobile_lcdc_priv *priv)
ch->meram_enabled = 0;
}
- if (!ch->info->var.nonstd)
- pixelformat = SH_MOBILE_MERAM_PF_RGB;
- else if (ch->info->var.bits_per_pixel = 24)
- pixelformat = SH_MOBILE_MERAM_PF_NV24;
- else
+ switch (sh_mobile_format_fourcc(&ch->info->var)) {
+ case V4L2_PIX_FMT_NV12:
+ case V4L2_PIX_FMT_NV21:
+ case V4L2_PIX_FMT_NV16:
+ case V4L2_PIX_FMT_NV61:
pixelformat = SH_MOBILE_MERAM_PF_NV;
+ break;
+ case V4L2_PIX_FMT_NV24:
+ case V4L2_PIX_FMT_NV42:
+ pixelformat = SH_MOBILE_MERAM_PF_NV24;
+ break;
+ case V4L2_PIX_FMT_RGB565:
+ case V4L2_PIX_FMT_BGR24:
+ case V4L2_PIX_FMT_BGR32:
+ default:
+ pixelformat = SH_MOBILE_MERAM_PF_RGB;
+ break;
+ }
ret = mdev->ops->meram_register(mdev, cfg, ch->pitch,
ch->info->var.yres, pixelformat,
@@ -845,6 +903,7 @@ static struct fb_fix_screeninfo sh_mobile_lcdc_fix = {
.xpanstep = 0,
.ypanstep = 1,
.ywrapstep = 0,
+ .capabilities = FB_CAP_FOURCC,
};
static void sh_mobile_lcdc_fillrect(struct fb_info *info,
@@ -877,8 +936,9 @@ static int sh_mobile_fb_pan_display(struct fb_var_screeninfo *var,
unsigned long new_pan_offset;
unsigned long base_addr_y, base_addr_c;
unsigned long c_offset;
+ bool yuv = sh_mobile_format_is_yuv(&info->var);
- if (!info->var.nonstd)
+ if (!yuv)
new_pan_offset = var->yoffset * info->fix.line_length
+ var->xoffset * (info->var.bits_per_pixel / 8);
else
@@ -892,7 +952,7 @@ static int sh_mobile_fb_pan_display(struct fb_var_screeninfo *var,
/* Set the source address for the next refresh */
base_addr_y = ch->dma_handle + new_pan_offset;
- if (info->var.nonstd) {
+ if (yuv) {
/* Set y offset */
c_offset = var->yoffset * info->fix.line_length
* (info->var.bits_per_pixel - 8) / 8;
@@ -900,7 +960,7 @@ static int sh_mobile_fb_pan_display(struct fb_var_screeninfo *var,
+ info->var.xres * info->var.yres_virtual
+ c_offset;
/* Set x offset */
- if (info->var.bits_per_pixel = 24)
+ if (sh_mobile_format_fourcc(&info->var) = V4L2_PIX_FMT_NV24)
base_addr_c += 2 * var->xoffset;
else
base_addr_c += var->xoffset;
@@ -924,7 +984,7 @@ static int sh_mobile_fb_pan_display(struct fb_var_screeninfo *var,
ch->base_addr_c = base_addr_c;
lcdc_write_chan_mirror(ch, LDSA1R, base_addr_y);
- if (info->var.nonstd)
+ if (yuv)
lcdc_write_chan_mirror(ch, LDSA2R, base_addr_c);
if (lcdc_chan_is_sublcd(ch))
@@ -1100,51 +1160,84 @@ static int sh_mobile_check_var(struct fb_var_screeninfo *var, struct fb_info *in
if (var->yres_virtual < var->yres)
var->yres_virtual = var->yres;
- if (var->bits_per_pixel <= 16) { /* RGB 565 */
- var->bits_per_pixel = 16;
- var->red.offset = 11;
- var->red.length = 5;
- var->green.offset = 5;
- var->green.length = 6;
- var->blue.offset = 0;
- var->blue.length = 5;
- var->transp.offset = 0;
- var->transp.length = 0;
- } else if (var->bits_per_pixel <= 24) { /* RGB 888 */
- var->bits_per_pixel = 24;
- var->red.offset = 16;
- var->red.length = 8;
- var->green.offset = 8;
- var->green.length = 8;
- var->blue.offset = 0;
- var->blue.length = 8;
- var->transp.offset = 0;
- var->transp.length = 0;
- } else if (var->bits_per_pixel <= 32) { /* RGBA 888 */
- var->bits_per_pixel = 32;
- var->red.offset = 16;
- var->red.length = 8;
- var->green.offset = 8;
- var->green.length = 8;
- var->blue.offset = 0;
- var->blue.length = 8;
- var->transp.offset = 24;
- var->transp.length = 8;
- } else
- return -EINVAL;
+ if (sh_mobile_format_is_fourcc(var)) {
+ switch (var->grayscale) {
+ case V4L2_PIX_FMT_NV12:
+ case V4L2_PIX_FMT_NV21:
+ var->bits_per_pixel = 12;
+ break;
+ case V4L2_PIX_FMT_RGB565:
+ case V4L2_PIX_FMT_NV16:
+ case V4L2_PIX_FMT_NV61:
+ var->bits_per_pixel = 16;
+ break;
+ case V4L2_PIX_FMT_BGR24:
+ case V4L2_PIX_FMT_NV24:
+ case V4L2_PIX_FMT_NV42:
+ var->bits_per_pixel = 24;
+ break;
+ case V4L2_PIX_FMT_BGR32:
+ var->bits_per_pixel = 32;
+ break;
+ default:
+ return -EINVAL;
+ }
+
+ /* Default to RGB and JPEG color-spaces for RGB and YUV formats
+ * respectively.
+ */
+ if (!sh_mobile_format_is_yuv(var))
+ var->colorspace = V4L2_COLORSPACE_SRGB;
+ else if (var->colorspace != V4L2_COLORSPACE_REC709)
+ var->colorspace = V4L2_COLORSPACE_JPEG;
+ } else {
+ if (var->bits_per_pixel <= 16) { /* RGB 565 */
+ var->bits_per_pixel = 16;
+ var->red.offset = 11;
+ var->red.length = 5;
+ var->green.offset = 5;
+ var->green.length = 6;
+ var->blue.offset = 0;
+ var->blue.length = 5;
+ var->transp.offset = 0;
+ var->transp.length = 0;
+ } else if (var->bits_per_pixel <= 24) { /* RGB 888 */
+ var->bits_per_pixel = 24;
+ var->red.offset = 16;
+ var->red.length = 8;
+ var->green.offset = 8;
+ var->green.length = 8;
+ var->blue.offset = 0;
+ var->blue.length = 8;
+ var->transp.offset = 0;
+ var->transp.length = 0;
+ } else if (var->bits_per_pixel <= 32) { /* RGBA 888 */
+ var->bits_per_pixel = 32;
+ var->red.offset = 16;
+ var->red.length = 8;
+ var->green.offset = 8;
+ var->green.length = 8;
+ var->blue.offset = 0;
+ var->blue.length = 8;
+ var->transp.offset = 24;
+ var->transp.length = 8;
+ } else
+ return -EINVAL;
- var->red.msb_right = 0;
- var->green.msb_right = 0;
- var->blue.msb_right = 0;
- var->transp.msb_right = 0;
+ var->red.msb_right = 0;
+ var->green.msb_right = 0;
+ var->blue.msb_right = 0;
+ var->transp.msb_right = 0;
+ }
/* Make sure we don't exceed our allocated memory. */
if (var->xres_virtual * var->yres_virtual * var->bits_per_pixel / 8 >
info->fix.smem_len)
return -EINVAL;
- /* only accept the forced_bpp for dual channel configurations */
- if (p->forced_bpp && p->forced_bpp != var->bits_per_pixel)
+ /* only accept the forced_fourcc for dual channel configurations */
+ if (p->forced_fourcc &&
+ p->forced_fourcc != sh_mobile_format_fourcc(var))
return -EINVAL;
return 0;
@@ -1158,7 +1251,7 @@ static int sh_mobile_set_par(struct fb_info *info)
sh_mobile_lcdc_stop(ch->lcdc);
- if (info->var.nonstd)
+ if (sh_mobile_format_is_yuv(&info->var))
info->fix.line_length = info->var.xres;
else
info->fix.line_length = info->var.xres
@@ -1170,6 +1263,14 @@ static int sh_mobile_set_par(struct fb_info *info)
info->fix.line_length = line_length;
}
+ if (sh_mobile_format_is_fourcc(&info->var)) {
+ info->fix.type = FB_TYPE_FOURCC;
+ info->fix.visual = FB_VISUAL_FOURCC;
+ } else {
+ info->fix.type = FB_TYPE_PACKED_PIXELS;
+ info->fix.visual = FB_VISUAL_TRUECOLOR;
+ }
+
return ret;
}
@@ -1464,9 +1565,9 @@ static int __devinit sh_mobile_lcdc_channel_init(struct sh_mobile_lcdc_chan *ch,
for (i = 0, mode = cfg->lcd_cfg; i < cfg->num_cfg; i++, mode++) {
unsigned int size = mode->yres * mode->xres;
- /* NV12 buffers must have even number of lines */
- if ((cfg->nonstd) && cfg->bpp = 12 &&
- (mode->yres & 0x1)) {
+ /* NV12/NV21 buffers must have even number of lines */
+ if ((cfg->fourcc = V4L2_PIX_FMT_NV12 ||
+ cfg->fourcc = V4L2_PIX_FMT_NV21) && (mode->yres & 0x1)) {
dev_err(dev, "yres must be multiple of 2 for YCbCr420 "
"mode.\n");
return -EINVAL;
@@ -1484,14 +1585,6 @@ static int __devinit sh_mobile_lcdc_channel_init(struct sh_mobile_lcdc_chan *ch,
dev_dbg(dev, "Found largest videomode %ux%u\n",
max_mode->xres, max_mode->yres);
- /* Initialize fixed screen information. Restrict pan to 2 lines steps
- * for NV12.
- */
- info->fix = sh_mobile_lcdc_fix;
- info->fix.smem_len = max_size * 2 * cfg->bpp / 8;
- if (cfg->nonstd && cfg->bpp = 12)
- info->fix.ypanstep = 2;
-
/* Create the mode list. */
if (cfg->lcd_cfg = NULL) {
mode = &default_720p;
@@ -1509,19 +1602,38 @@ static int __devinit sh_mobile_lcdc_channel_init(struct sh_mobile_lcdc_chan *ch,
*/
var = &info->var;
fb_videomode_to_var(var, mode);
- var->bits_per_pixel = cfg->bpp;
var->width = cfg->lcd_size_cfg.width;
var->height = cfg->lcd_size_cfg.height;
var->yres_virtual = var->yres * 2;
var->activate = FB_ACTIVATE_NOW;
+ switch (cfg->fourcc) {
+ case V4L2_PIX_FMT_RGB565:
+ var->bits_per_pixel = 16;
+ break;
+ case V4L2_PIX_FMT_BGR24:
+ var->bits_per_pixel = 24;
+ break;
+ case V4L2_PIX_FMT_BGR32:
+ var->bits_per_pixel = 32;
+ break;
+ default:
+ var->grayscale = cfg->fourcc;
+ break;
+ }
+
+ /* Make sure the memory size check won't fail. smem_len is initialized
+ * later based on var.
+ */
+ info->fix.smem_len = UINT_MAX;
ret = sh_mobile_check_var(var, info);
if (ret)
return ret;
+ max_size = max_size * var->bits_per_pixel / 8 * 2;
+
/* Allocate frame buffer memory and color map. */
- buf = dma_alloc_coherent(dev, info->fix.smem_len, &ch->dma_handle,
- GFP_KERNEL);
+ buf = dma_alloc_coherent(dev, max_size, &ch->dma_handle, GFP_KERNEL);
if (!buf) {
dev_err(dev, "unable to allocate buffer\n");
return -ENOMEM;
@@ -1530,16 +1642,27 @@ static int __devinit sh_mobile_lcdc_channel_init(struct sh_mobile_lcdc_chan *ch,
ret = fb_alloc_cmap(&info->cmap, PALETTE_NR, 0);
if (ret < 0) {
dev_err(dev, "unable to allocate cmap\n");
- dma_free_coherent(dev, info->fix.smem_len,
- buf, ch->dma_handle);
+ dma_free_coherent(dev, max_size, buf, ch->dma_handle);
return ret;
}
+ /* Initialize fixed screen information. Restrict pan to 2 lines steps
+ * for NV12 and NV21.
+ */
+ info->fix = sh_mobile_lcdc_fix;
info->fix.smem_start = ch->dma_handle;
- if (var->nonstd)
+ info->fix.smem_len = max_size;
+ if (cfg->fourcc = V4L2_PIX_FMT_NV12 ||
+ cfg->fourcc = V4L2_PIX_FMT_NV21)
+ info->fix.ypanstep = 2;
+
+ if (sh_mobile_format_is_yuv(var)) {
info->fix.line_length = var->xres;
- else
- info->fix.line_length = var->xres * (cfg->bpp / 8);
+ info->fix.visual = FB_VISUAL_FOURCC;
+ } else {
+ info->fix.line_length = var->xres * var->bits_per_pixel / 8;
+ info->fix.visual = FB_VISUAL_TRUECOLOR;
+ }
info->screen_base = buf;
info->device = dev;
@@ -1626,9 +1749,9 @@ static int __devinit sh_mobile_lcdc_probe(struct platform_device *pdev)
goto err1;
}
- /* for dual channel LCDC (MAIN + SUB) force shared bpp setting */
+ /* for dual channel LCDC (MAIN + SUB) force shared format setting */
if (num_channels = 2)
- priv->forced_bpp = pdata->ch[0].bpp;
+ priv->forced_fourcc = pdata->ch[0].fourcc;
priv->base = ioremap_nocache(res->start, resource_size(res));
if (!priv->base)
@@ -1675,13 +1798,10 @@ static int __devinit sh_mobile_lcdc_probe(struct platform_device *pdev)
if (error < 0)
goto err1;
- dev_info(info->dev,
- "registered %s/%s as %dx%d %dbpp.\n",
- pdev->name,
- (ch->cfg.chan = LCDC_CHAN_MAINLCD) ?
- "mainlcd" : "sublcd",
- info->var.xres, info->var.yres,
- ch->cfg.bpp);
+ dev_info(info->dev, "registered %s/%s as %dx%d %dbpp.\n",
+ pdev->name, (ch->cfg.chan = LCDC_CHAN_MAINLCD) ?
+ "mainlcd" : "sublcd", info->var.xres, info->var.yres,
+ info->var.bits_per_pixel);
/* deferred io mode: disable clock to save power */
if (info->fbdefio || info->state = FBINFO_STATE_SUSPENDED)
diff --git a/include/video/sh_mobile_lcdc.h b/include/video/sh_mobile_lcdc.h
index 8101b72..fe30b75 100644
--- a/include/video/sh_mobile_lcdc.h
+++ b/include/video/sh_mobile_lcdc.h
@@ -174,7 +174,8 @@ struct sh_mobile_lcdc_bl_info {
struct sh_mobile_lcdc_chan_cfg {
int chan;
- int bpp;
+ int fourcc;
+ int colorspace;
int interface_type; /* selects RGBn or SYSn I/F, see above */
int clock_divider;
unsigned long flags; /* LCDC_FLAGS_... */
@@ -184,7 +185,6 @@ struct sh_mobile_lcdc_chan_cfg {
struct sh_mobile_lcdc_board_cfg board_cfg;
struct sh_mobile_lcdc_bl_info bl_info;
struct sh_mobile_lcdc_sys_bus_cfg sys_bus_cfg; /* only for SYSn I/F */
- int nonstd;
struct sh_mobile_meram_cfg *meram_cfg;
};
--
1.7.3.4
^ permalink raw reply related
* Re: drm pixel formats update
From: Laurent Pinchart @ 2011-11-29 12:10 UTC (permalink / raw)
To: dri-devel; +Cc: ville.syrjala, Tomi Valkeinen, linux-fbdev, linux-media
In-Reply-To: <1321468945-28224-1-git-send-email-ville.syrjala@linux.intel.com>
Hi Ville,
Sorry for the late reply.
(Cross-posting to the linux-fbdev and linux-media mailing lists, as the topics
I'm about to discuss are of interest to everybody)
On Wednesday 16 November 2011 19:42:23 ville.syrjala@linux.intel.com wrote:
> I decided to go all out with the pixel format definitions. Added pretty
> much all of the possible RGB/BGR variations. Just left out ones with
> 16bit components and floats. Also added a whole bunch of YUV formats,
> and 8 bit pseudocolor for good measure.
>
> I'm sure some of the fourccs now clash with the ones used by v4l2,
> but that's life.
Disclaimer: I realize this is a somehow controversial topic, and I'm not
trying to start a flame war :-)
What about defining a common set of fourccs for both subsystem (and using them
in FBDEV, which currently uses the V4L2 fourccs) ?
There's more and more overlap between DRM, FBDEV and V4L2, which results in
confusion for the user and mess in the kernel. I believe cleaning this up will
become more and more important with time, and also probably more and more
difficult if we don't act now.
There's no way we will all quickly agree on a big picture unified architecture
(I don't even know what it should look like), so I'm thinking about starting
small and see where it will lead us. Sharing fourccs would be such a first
step, and would make it easier for drivers to implement several of the DRM,
FBDEV and V4L2 APIs.
Another step I'd like to take would be working on sharing the video mode
definitions between subsystems. DRM has struct drm_mode_modeinfo and FBDEV has
struct fb_videomode. The former can't be modified as it's used in userspace
APIs, but I believe we should create a common in-kernel structure to represent
modes. This would also make it easier to share the EDID parser between DRM and
FBDEV.
One issue here is names. I understand that using names from another subsystem
in a driver that has nothing to do with it (like using V4L2_PIX_FMT_* in DRM,
or drm_mode_modeinfo in FBDEV) can be frustrating for many developers, so I'd
like to propose an alternative. We have a media-related kernel API that is
cross-subsystem, that's the media controller. It uses the prefix media_. We
could use more specific versions of that preview (such as media_video_ and
media_display_) as a neutral ground.
Another issue is control. It's quite natural to be suspicious about subsystems
we're not familiar with, and giving up control on things we consider as highly
important to other subsystems feels dangerous and wrong. Once again, media_*
could be an answer to this problem. Instead of trying to push other subsystems
to use our APIs (which are, obviously, the best possible ever, as they're the
ones we work on :-)) with the promise that we will extend them to fullfill
their needs if necessary, we could design new shared structures and core
functions together with a media_ prefix, and make sure they fullfill all the
needs from the start. What I like about this approach is that each of the 3
video-related subsystems would then benefit from the experience of the other
2.
To make it perfectly clear, I want to emphasize that I'm not trying to replace
DRM, FBDEV and V4L2 with a new shared subsystem. What I would like to see in
the (near future) is collaboration and sharing of core features that make
sense to share. I believe we should address this from a "pain point" point of
view. The one that lead me to writing this e-mail is that developing a driver
that implements both the DRM and FBDEV APIs for video output currently
requires various similar structures, and code to translate between all of
them. That code can't be shared between multiple drivers, is error-prone, and
painful to maintin.
I can (and actually would like to) submit an RFC, but I would first like to
hear your opinion on the topic.
> If anyone has problems with the way the formats are defined, please
> speak up now! Since only Jesse has bothered to comment on my rantings
> I can only assume people are happy with my approach to things.
>
> These patches should apply on top of Jesse's v3+v5 set... I think.
> I sort of lost track of things when the patches started having
> different version numbers. At least we're not yet into two digits
> numbers ;)
--
Regards,
Laurent Pinchart
^ permalink raw reply
* Re: drm pixel formats update
From: Hans Verkuil @ 2011-11-29 13:30 UTC (permalink / raw)
To: Laurent Pinchart
Cc: dri-devel, ville.syrjala, Tomi Valkeinen, linux-fbdev,
linux-media, Jesse Barker
In-Reply-To: <201111291310.36589.laurent.pinchart@ideasonboard.com>
On Tuesday 29 November 2011 13:10:35 Laurent Pinchart wrote:
> Hi Ville,
>
> Sorry for the late reply.
>
> (Cross-posting to the linux-fbdev and linux-media mailing lists, as the
> topics I'm about to discuss are of interest to everybody)
>
> On Wednesday 16 November 2011 19:42:23 ville.syrjala@linux.intel.com wrote:
> > I decided to go all out with the pixel format definitions. Added pretty
> > much all of the possible RGB/BGR variations. Just left out ones with
> > 16bit components and floats. Also added a whole bunch of YUV formats,
> > and 8 bit pseudocolor for good measure.
> >
> > I'm sure some of the fourccs now clash with the ones used by v4l2,
> > but that's life.
>
> Disclaimer: I realize this is a somehow controversial topic, and I'm not
> trying to start a flame war :-)
>
> What about defining a common set of fourccs for both subsystem (and using
> them in FBDEV, which currently uses the V4L2 fourccs) ?
>
> There's more and more overlap between DRM, FBDEV and V4L2, which results in
> confusion for the user and mess in the kernel. I believe cleaning this up
> will become more and more important with time, and also probably more and
> more difficult if we don't act now.
>
> There's no way we will all quickly agree on a big picture unified
> architecture (I don't even know what it should look like), so I'm thinking
> about starting small and see where it will lead us. Sharing fourccs would
> be such a first step, and would make it easier for drivers to implement
> several of the DRM, FBDEV and V4L2 APIs.
>
> Another step I'd like to take would be working on sharing the video mode
> definitions between subsystems. DRM has struct drm_mode_modeinfo and FBDEV
> has struct fb_videomode. The former can't be modified as it's used in
> userspace APIs, but I believe we should create a common in-kernel
> structure to represent modes. This would also make it easier to share the
> EDID parser between DRM and FBDEV.
>
> One issue here is names. I understand that using names from another
> subsystem in a driver that has nothing to do with it (like using
> V4L2_PIX_FMT_* in DRM, or drm_mode_modeinfo in FBDEV) can be frustrating
> for many developers, so I'd like to propose an alternative. We have a
> media-related kernel API that is cross-subsystem, that's the media
> controller. It uses the prefix media_. We could use more specific versions
> of that preview (such as media_video_ and media_display_) as a neutral
> ground.
I agree.
> Another issue is control. It's quite natural to be suspicious about
> subsystems we're not familiar with, and giving up control on things we
> consider as highly important to other subsystems feels dangerous and
> wrong. Once again, media_* could be an answer to this problem. Instead of
> trying to push other subsystems to use our APIs (which are, obviously, the
> best possible ever, as they're the ones we work on :-)) with the promise
> that we will extend them to fullfill their needs if necessary, we could
> design new shared structures and core functions together with a media_
> prefix, and make sure they fullfill all the needs from the start. What I
> like about this approach is that each of the 3 video-related subsystems
> would then benefit from the experience of the other 2.
>
> To make it perfectly clear, I want to emphasize that I'm not trying to
> replace DRM, FBDEV and V4L2 with a new shared subsystem. What I would like
> to see in the (near future) is collaboration and sharing of core features
> that make sense to share. I believe we should address this from a "pain
> point" point of view. The one that lead me to writing this e-mail is that
> developing a driver that implements both the DRM and FBDEV APIs for video
> output currently requires various similar structures, and code to
> translate between all of them. That code can't be shared between multiple
> drivers, is error-prone, and painful to maintin.
>
> I can (and actually would like to) submit an RFC, but I would first like to
> hear your opinion on the topic.
I have added Jesse Barker to the CC list. I think that to achieve closer
cooperation between the various subsystems we need to organize a few days
of talks between the main developers to 1) understand each others subsystem,
2) to discover what functionality would be good to share, and 3) figure out
some sort of roadmap on how to do this.
Linaro might be a suitable organization that can assist with at least the
organizational part of setting up such a meeting. They did a good job in the
past (in Budapest and Cambourne) with the buffer sharing discussions.
One week of discussions/brainstorming between a small(ish) group of developers
can be very, very productive in my experience.
Regards,
Hans
>
> > If anyone has problems with the way the formats are defined, please
> > speak up now! Since only Jesse has bothered to comment on my rantings
> > I can only assume people are happy with my approach to things.
> >
> > These patches should apply on top of Jesse's v3+v5 set... I think.
> > I sort of lost track of things when the patches started having
> > different version numbers. At least we're not yet into two digits
> > numbers ;)
^ permalink raw reply
* Re: drm pixel formats update
From: Tomi Valkeinen @ 2011-11-29 16:13 UTC (permalink / raw)
To: Laurent Pinchart; +Cc: dri-devel, ville.syrjala, linux-fbdev, linux-media
In-Reply-To: <201111291310.36589.laurent.pinchart@ideasonboard.com>
[-- Attachment #1: Type: text/plain, Size: 1264 bytes --]
On Tue, 2011-11-29 at 13:10 +0100, Laurent Pinchart wrote:
> To make it perfectly clear, I want to emphasize that I'm not trying to replace
> DRM, FBDEV and V4L2 with a new shared subsystem. What I would like to see in
> the (near future) is collaboration and sharing of core features that make
> sense to share. I believe we should address this from a "pain point" point of
> view. The one that lead me to writing this e-mail is that developing a driver
> that implements both the DRM and FBDEV APIs for video output currently
> requires various similar structures, and code to translate between all of
> them. That code can't be shared between multiple drivers, is error-prone, and
> painful to maintin.
We've been in the same situation with OMAP display driver for years. The
same low level display driver is used by FB, V4L2 and now DRM drivers,
so I didn't have much choice but to implement omapdss versions for
things like video timings and color formats.
I've been planning to write code for this almost as long as omapdss has
had this problem, but there's always been
yet-another-important-thing-to-do. So good that somebody finally brought
this up =).
I'm happy to test any code related to this with omapdss.
Tomi
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* Re: [PATCH v4 2/3] v4l: Add V4L2_PIX_FMT_NV24 and V4L2_PIX_FMT_NV42
From: Sylwester Nawrocki @ 2011-11-29 17:19 UTC (permalink / raw)
To: Laurent Pinchart; +Cc: linux-fbdev, linux-media
In-Reply-To: <1322562419-9934-3-git-send-email-laurent.pinchart@ideasonboard.com>
Hi Laurent,
On 11/29/2011 11:26 AM, Laurent Pinchart wrote:
> NV24 and NV42 are planar YCbCr 4:4:4 and YCrCb 4:4:4 formats with a
> luma plane followed by an interleaved chroma plane.
>
> Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
> ---
...
> + </example>
> + </refsect1>
> + </refentry>
> +
> + <!--
> +Local Variables:
> +mode: sgml
> +sgml-parent-document: "pixfmt.sgml"
> +indent-tabs-mode: nil
> +End:
> + -->
I think this comment chunk is redundant, it's just for emacs configuration.
Every time I open the file containing litter like this I get a not-so-useful
message, asking if I want to load the variables defined there or not.
I'm considering a patch cleaning up the Docbook from this emacs stuff, as I
also made a mistake copying this comment when adding NV12M, NV12MT formats.
Looks like most of people are doing that, e.g. see
http://www.mail-archive.com/linux-media@vger.kernel.org/msg38637.html
;)
--
Regards,
Sylwester
^ 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