* RE: [PATCH RFC] video: Add Hyper-V Synthetic Video Frame Buffer Driver
From: Haiyang Zhang @ 2013-02-19 17:48 UTC (permalink / raw)
To: Olaf Hering
Cc: FlorianSchandinat@gmx.de, linux-fbdev@vger.kernel.org,
KY Srinivasan, jasowang@redhat.com, linux-kernel@vger.kernel.org,
devel@linuxdriverproject.org
In-Reply-To: <20130219165118.GA17715@aepfle.de>
PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBPbGFmIEhlcmluZyBbbWFpbHRv
Om9sYWZAYWVwZmxlLmRlXQ0KPiBTZW50OiBUdWVzZGF5LCBGZWJydWFyeSAxOSwgMjAxMyAxMTo1
MSBBTQ0KPiBUbzogSGFpeWFuZyBaaGFuZw0KPiBDYzogRmxvcmlhblNjaGFuZGluYXRAZ214LmRl
OyBsaW51eC1mYmRldkB2Z2VyLmtlcm5lbC5vcmc7IEtZIFNyaW5pdmFzYW47DQo+IGphc293YW5n
QHJlZGhhdC5jb207IGxpbnV4LWtlcm5lbEB2Z2VyLmtlcm5lbC5vcmc7DQo+IGRldmVsQGxpbnV4
ZHJpdmVycHJvamVjdC5vcmcNCj4gU3ViamVjdDogUmU6IFtQQVRDSCBSRkNdIHZpZGVvOiBBZGQg
SHlwZXItViBTeW50aGV0aWMgVmlkZW8gRnJhbWUgQnVmZmVyDQo+IERyaXZlcg0KPiANCj4gT24g
RnJpLCBGZWIgMTUsIEhhaXlhbmcgWmhhbmcgd3JvdGU6DQo+IA0KPiA+IEBAIC01MDgsNiArNTQ0
LDE4IEBAIHN0YXRpYyBpbnQgX19pbml0IHZlc2FmYl9pbml0KHZvaWQpDQo+ID4gIAlpbnQgcmV0
Ow0KPiA+ICAJY2hhciAqb3B0aW9uID0gTlVMTDsNCj4gPg0KPiA+ICsjaWYgSVNfRU5BQkxFRChD
T05GSUdfSFlQRVJWX0ZCKQ0KPiA+ICsJLyoNCj4gPiArCSAqIE9uIEh5cGVyLVYgYm90aCB0aGUg
ZW11bGF0ZWQgYW5kIHN5bnRoZXRpYyB2aWRlbyBkZXZpY2VzIGFyZQ0KPiA+ICsJICogYXZhaWxh
YmxlLiBUbyBhdm9pZCBjb25mbGljdHMsIHdlIGRpc2FibGUgdmVzYWZiIGZvciB0aGUNCj4gZW11
bGF0ZWQNCj4gPiArCSAqIHZpZGVvIGlmIGh5cGVydl9mYiBpcyBjb25maWd1cmVkLg0KPiA+ICsJ
ICovDQo+ID4gKwlpZiAoaXNfaHlwZXJ2KCkpIHsNCj4gPiArCQlwcl9pbmZvKCJEaXNhYmxlZCB2
ZXNhZmIgb24gSHlwZXItVi5cbiIpOw0KPiA+ICsJCXJldHVybiAtRU5PREVWOw0KPiA+ICsJfQ0K
PiA+ICsjZW5kaWYNCj4gDQo+IFdoYXQgaXMgdGhlIHJlYXNvbiBmb3IgdGhpcyBob29rPyBJcyBp
dCBub3QgcG9zc2libGUgdG8gY2xhaW0gdGhlDQo+IGRpc3BsYXkgbGlrZSBpdHMgYXBwZWFyZW50
bHkgZG9uZSBieSBvdGhlciBkcml2ZXJzIChsaWtlIHJhZGVvbmZiIGNhbg0KPiB0YWtlIG92ZXIg
ZGlzcGxheSBmcm9tIHZlc2FmYik/DQoNClRoZSBlbXVsYXRlZCB2aWRlbyBkZXZpY2UgaXMgYSBz
ZXBhcmF0ZSBkZXZpY2UgZnJvbSB0aGUgc3ludGhldGljIHZpZGVvLg0KVGhlIHN5bnRoZXRpYyBk
cml2ZXIgY2FuIG9ubHkgdGFrZSBjb250cm9sIG9mIHRoZSBzeW50aGV0aWMgdmlkZW8sIGJ1dCBu
b3QNCnRoZSBlbXVsYXRlZCB2aWRlby4NCg0KQWN0dWFsbHksIHdlIGFscmVhZHkgaGF2ZSBhIHNp
bWlsYXIgbWVjaGFuaXNtIGluIGF0YS9hdGFfcGlpeC5jIHRvIGRpc2FibGUNCmVtdWxhdGVkIElE
RSBkcml2ZSBvbiBIeXBlci1WLCBzbyBpdCB3b24ndCBjb25mbGljdCB3aXRoIHRoZSBzeW50aGV0
aWMgZHJpdmUuDQoNClRoYW5rcywNCi0gSGFpeWFuZw0KDQo
^ permalink raw reply
* Re: [PATCH RFC] video: Add Hyper-V Synthetic Video Frame Buffer Driver
From: Olaf Hering @ 2013-02-19 18:40 UTC (permalink / raw)
To: Haiyang Zhang
Cc: FlorianSchandinat@gmx.de, linux-fbdev@vger.kernel.org,
KY Srinivasan, jasowang@redhat.com, linux-kernel@vger.kernel.org,
devel@linuxdriverproject.org
In-Reply-To: <1ca36b5d55c64ac6b8854c4f216ef8e5@DFM-TK5MBX15-06.exchange.corp.microsoft.com>
On Tue, Feb 19, Haiyang Zhang wrote:
> The emulated video device is a separate device from the synthetic video.
> The synthetic driver can only take control of the synthetic video, but not
> the emulated video.
Please add this to the comment above.
> Actually, we already have a similar mechanism in ata/ata_piix.c to disable
> emulated IDE drive on Hyper-V, so it won't conflict with the synthetic drive.
I havent read the vesafb code, but I think it can kind of give up the
hardware, something ata_piix can not do.
Olaf
^ permalink raw reply
* RE: [PATCH RFC] video: Add Hyper-V Synthetic Video Frame Buffer Driver
From: Haiyang Zhang @ 2013-02-19 19:04 UTC (permalink / raw)
To: Olaf Hering
Cc: FlorianSchandinat@gmx.de, linux-fbdev@vger.kernel.org,
KY Srinivasan, jasowang@redhat.com, linux-kernel@vger.kernel.org,
devel@linuxdriverproject.org
In-Reply-To: <20130219184009.GA21783@aepfle.de>
PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBsaW51eC1mYmRldi1vd25lckB2
Z2VyLmtlcm5lbC5vcmcgW21haWx0bzpsaW51eC1mYmRldi0NCj4gb3duZXJAdmdlci5rZXJuZWwu
b3JnXSBPbiBCZWhhbGYgT2YgT2xhZiBIZXJpbmcNCj4gU2VudDogVHVlc2RheSwgRmVicnVhcnkg
MTksIDIwMTMgMTo0MCBQTQ0KPiBUbzogSGFpeWFuZyBaaGFuZw0KPiBDYzogRmxvcmlhblNjaGFu
ZGluYXRAZ214LmRlOyBsaW51eC1mYmRldkB2Z2VyLmtlcm5lbC5vcmc7IEtZIFNyaW5pdmFzYW47
DQo+IGphc293YW5nQHJlZGhhdC5jb207IGxpbnV4LWtlcm5lbEB2Z2VyLmtlcm5lbC5vcmc7DQo+
IGRldmVsQGxpbnV4ZHJpdmVycHJvamVjdC5vcmcNCj4gU3ViamVjdDogUmU6IFtQQVRDSCBSRkNd
IHZpZGVvOiBBZGQgSHlwZXItViBTeW50aGV0aWMgVmlkZW8gRnJhbWUgQnVmZmVyDQo+IERyaXZl
cg0KPiANCj4gT24gVHVlLCBGZWIgMTksIEhhaXlhbmcgWmhhbmcgd3JvdGU6DQo+IA0KPiA+IFRo
ZSBlbXVsYXRlZCB2aWRlbyBkZXZpY2UgaXMgYSBzZXBhcmF0ZSBkZXZpY2UgZnJvbSB0aGUgc3lu
dGhldGljDQo+IHZpZGVvLg0KPiA+IFRoZSBzeW50aGV0aWMgZHJpdmVyIGNhbiBvbmx5IHRha2Ug
Y29udHJvbCBvZiB0aGUgc3ludGhldGljIHZpZGVvLCBidXQNCj4gbm90DQo+ID4gdGhlIGVtdWxh
dGVkIHZpZGVvLg0KPiANCj4gUGxlYXNlIGFkZCB0aGlzIHRvIHRoZSBjb21tZW50IGFib3ZlLg0K
DQpXaWxsIGRvLg0KDQo+ID4gQWN0dWFsbHksIHdlIGFscmVhZHkgaGF2ZSBhIHNpbWlsYXIgbWVj
aGFuaXNtIGluIGF0YS9hdGFfcGlpeC5jIHRvDQo+IGRpc2FibGUNCj4gPiBlbXVsYXRlZCBJREUg
ZHJpdmUgb24gSHlwZXItViwgc28gaXQgd29uJ3QgY29uZmxpY3Qgd2l0aCB0aGUgc3ludGhldGlj
DQo+IGRyaXZlLg0KPiANCj4gSSBoYXZlbnQgcmVhZCB0aGUgdmVzYWZiIGNvZGUsIGJ1dCBJIHRo
aW5rIGl0IGNhbiBraW5kIG9mIGdpdmUgdXAgdGhlDQo+IGhhcmR3YXJlLCBzb21ldGhpbmcgYXRh
X3BpaXggY2FuIG5vdCBkby4NCg0KSW4gbXkgdGVzdCwgdGhlIHZlc2FmYiBkb2Vzbid0IGF1dG9t
YXRpY2FsbHkgZ2l2ZSB1cCB0aGUgZW11bGF0ZWQgdmlkZW8gZGV2aWNlLA0KdW5sZXNzIEkgYWRk
IHRoZSBETUkgYmFzZWQgbWVjaGFuaXNtIHRvIGxldCBpdCBleGl0IG9uIEh5cGVyLVYuDQoNClRo
YW5rcywNCi0gSGFpeWFuZw0KDQo
^ permalink raw reply
* [PATCH] video: mx3fb: Use NULL for pointer
From: Fabio Estevam @ 2013-02-20 17:25 UTC (permalink / raw)
To: linux-fbdev
From: Fabio Estevam <fabio.estevam@freescale.com>
Fix the following sparse error:
drivers/video/mx3fb.c:1309:28: warning: Using plain integer as NULL pointer
Signed-off-by: Fabio Estevam <fabio.estevam@freescale.com>
---
drivers/video/mx3fb.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/video/mx3fb.c b/drivers/video/mx3fb.c
index 7368872..cfdb380 100644
--- a/drivers/video/mx3fb.c
+++ b/drivers/video/mx3fb.c
@@ -1306,7 +1306,7 @@ static int mx3fb_unmap_video_memory(struct fb_info *fbi)
dma_free_writecombine(fbi->device, fbi->fix.smem_len,
fbi->screen_base, fbi->fix.smem_start);
- fbi->screen_base = 0;
+ fbi->screen_base = NULL;
mutex_lock(&fbi->mm_lock);
fbi->fix.smem_start = 0;
fbi->fix.smem_len = 0;
--
1.7.9.5
^ permalink raw reply related
* Re: [PATCH] video: mx3fb: Use NULL for pointer
From: Guennadi Liakhovetski @ 2013-02-20 21:59 UTC (permalink / raw)
To: linux-fbdev
In-Reply-To: <1361381101-21325-1-git-send-email-festevam@gmail.com>
On Wed, 20 Feb 2013, Fabio Estevam wrote:
> From: Fabio Estevam <fabio.estevam@freescale.com>
>
> Fix the following sparse error:
>
> drivers/video/mx3fb.c:1309:28: warning: Using plain integer as NULL pointer
>
> Signed-off-by: Fabio Estevam <fabio.estevam@freescale.com>
Acked-by: Guennadi Liakhovetski <g.liakhovetski@gmx.de>
Thanks
Guennadi
> ---
> drivers/video/mx3fb.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/video/mx3fb.c b/drivers/video/mx3fb.c
> index 7368872..cfdb380 100644
> --- a/drivers/video/mx3fb.c
> +++ b/drivers/video/mx3fb.c
> @@ -1306,7 +1306,7 @@ static int mx3fb_unmap_video_memory(struct fb_info *fbi)
> dma_free_writecombine(fbi->device, fbi->fix.smem_len,
> fbi->screen_base, fbi->fix.smem_start);
>
> - fbi->screen_base = 0;
> + fbi->screen_base = NULL;
> mutex_lock(&fbi->mm_lock);
> fbi->fix.smem_start = 0;
> fbi->fix.smem_len = 0;
> --
> 1.7.9.5
>
---
Guennadi Liakhovetski, Ph.D.
Freelance Open-Source Software Developer
http://www.open-technology.de/
^ permalink raw reply
* Re: [GIT PULL] samsung-fb updates for v3.9
From: Linus Torvalds @ 2013-02-20 22:26 UTC (permalink / raw)
To: Jingoo Han
Cc: linux-fbdev, linux-kernel, Florian Tobias Schandinat,
Andrew Morton
In-Reply-To: <003901ce0e4b$fd839c40$f88ad4c0$%han@samsung.com>
On Mon, Feb 18, 2013 at 6:51 PM, Jingoo Han <jg1.han@samsung.com> wrote:
>
> are available in the git repository at:
> git://github.com/jingoo/linux.git samsung-fb-next
I _really_ want signed tags when pulling from untrusted hosts like
github. Same goes for your exynos-dp-next branch.
Not pulled.
Linus
^ permalink raw reply
* [GIT PULL] samsung-fb updates for v3.9
From: Jingoo Han @ 2013-02-21 5:17 UTC (permalink / raw)
To: 'Linus Torvalds'
Cc: 'linux-fbdev', 'linux-kernel',
'Florian Tobias Schandinat', 'Andrew Morton',
'Jingoo Han'
In-Reply-To: <003901ce0e4b$fd839c40$f88ad4c0$%han@samsung.com>
Hi Linus,
Florian, the fbdev maintainer, has been very busy lately, so I send the pull request
for samsung-fb for this merge window.
The following changes since commit 19f949f52599ba7c3f67a5897ac6be14bfcb1200:
Linux 3.8 (Mon Feb 18 15:58:34 2013 -0800)
are available in the git repository at:
git://github.com/jingoo/linux.git tags/samsung-fb-3.9
for you to fetch changes up to 5a415ae252d5922de9eadefabe8510115395fbc6:
video: s3c-fb: Fix typo in definition of VIDCON1_VSTATUS_FRONTPORCH value (Sat Nov 17 21:31:00 2012 +0000)
----------------------------------------------------------------
samsung-fb updates for the v3.9:
- The bit definitions of header file are updated.
- The dependancy is fixed.
----------------------------------------------------------------
Jingoo Han (4):
video: s3c-fb: use ARCH_ dependancy
video: s3c-fb: remove duplicated S3C_FB_MAX_WIN
video: s3c-fb: remove unnecessary brackets
video: s3c-fb: add the bit definitions for CSC EQ709 and EQ601
Tomasz Figa (1):
video: s3c-fb: Fix typo in definition of VIDCON1_VSTATUS_FRONTPORCH value
drivers/video/Kconfig | 3 +-
include/video/samsung_fimd.h | 205 ++++++++++++++++++++---------------------
2 files changed, 102 insertions(+), 106 deletions(-)
--
Best regards,
Jingoo Han
^ permalink raw reply
* [GIT PULL] exynos-dp updates for v3.9
From: Jingoo Han @ 2013-02-21 5:20 UTC (permalink / raw)
To: 'Linus Torvalds'
Cc: 'linux-fbdev', 'linux-kernel',
'Florian Tobias Schandinat', 'Andrew Morton',
'Jingoo Han'
In-Reply-To: <003a01ce0e4c$dc0f80f0$942e82d0$%han@samsung.com>
Hi Linus,
Florian, the fbdev maintainer, has been very busy lately, so I send the pull request
for exynos-dp for this merge window.
The following changes since commit 19f949f52599ba7c3f67a5897ac6be14bfcb1200:
Linux 3.8 (Mon Feb 18 15:58:34 2013 -0800)
are available in the git repository at:
git://github.com/jingoo/linux.git tags/exynos-dp-3.9
for you to fetch changes up to bb80934325dab97b479815aed237ebec33ed1c57:
video: exynos_dp: move disable_irq() to exynos_dp_suspend() (Tue Jan 29 18:26:05 2013 +0900)
----------------------------------------------------------------
exynos-dp updates for the v3.9:
- The missing function calls are fixed.
----------------------------------------------------------------
Ajay Kumar (1):
video: exynos_dp: move disable_irq() to exynos_dp_suspend()
Jingoo Han (1):
video: exynos_dp: add missing of_node_put()
drivers/video/exynos/exynos_dp_core.c | 24 +++++++++++++++---------
1 files changed, 15 insertions(+), 9 deletions(-)
--
Best regards,
Jingoo Han
^ permalink raw reply
* [GIT PULL] UAPI disintegration for the framebuffer layer
From: David Howells @ 2013-02-21 13:49 UTC (permalink / raw)
To: torvalds
Cc: dhowells, Florian Tobias Schandinat, Tomi Valkeinen, linux-fbdev,
linux-kernel
Hi Linus,
Here are the UAPI disintegration bits for the fbdev drivers. It appears that
Florian hasn't had time to deal with my patch, but back in December he did say
he didn't mind if I pushed it forward. I recommend pulling it after any other
fbdev stuff and I can easily regenerate it if necessary.
David
---
The following changes since commit 1800098549fc310cffffefdcb3722adaad0edda8:
ARM: OMAP: Fix build breakage due to missing include in i2c.c (2012-12-20 08:43:25 -0800)
are available in the git repository at:
git://git.infradead.org/users/dhowells/linux-headers.git tags/disintegrate-fbdev-20121220
for you to fetch changes up to b889fcf63cb62e7fdb7816565e28f44dbe4a76a5:
UAPI: (Scripted) Disintegrate include/video (2012-12-20 17:14:26 +0000)
----------------------------------------------------------------
UAPI disintegration 2012-12-20
----------------------------------------------------------------
David Howells (1):
UAPI: (Scripted) Disintegrate include/video
include/uapi/video/Kbuild | 3 +
include/uapi/video/edid.h | 9 ++
include/uapi/video/sisfb.h | 209 +++++++++++++++++++++++++++++++++++++++++++
include/uapi/video/uvesafb.h | 60 +++++++++++++
include/video/Kbuild | 3 -
include/video/edid.h | 7 +-
include/video/sisfb.h | 189 +-------------------------------------
include/video/uvesafb.h | 58 +-----------
8 files changed, 284 insertions(+), 254 deletions(-)
create mode 100644 include/uapi/video/edid.h
create mode 100644 include/uapi/video/sisfb.h
create mode 100644 include/uapi/video/uvesafb.h
^ permalink raw reply
* Re: [PATCH RFC] video: Add Hyper-V Synthetic Video Frame Buffer Driver
From: Olaf Hering @ 2013-02-21 15:53 UTC (permalink / raw)
To: Haiyang Zhang
Cc: FlorianSchandinat@gmx.de, linux-fbdev@vger.kernel.org,
KY Srinivasan, jasowang@redhat.com, linux-kernel@vger.kernel.org,
devel@linuxdriverproject.org
In-Reply-To: <7267f77544c24531b8fcccc2192b9f48@DFM-TK5MBX15-06.exchange.corp.microsoft.com>
On Tue, Feb 19, Haiyang Zhang wrote:
> > I havent read the vesafb code, but I think it can kind of give up the
> > hardware, something ata_piix can not do.
>
> In my test, the vesafb doesn't automatically give up the emulated video device,
> unless I add the DMI based mechanism to let it exit on Hyper-V.
From reading the code, it seems to do that via
do_remove_conflicting_framebuffers(). hypervfb does not set apertures
etc, so that function is a noop.
My point is that with this new driver distro kernel will have no console
output until hypervfb is loaded. On native hardware there is at least
vesafb which can display something until initrd is running. So if the
hypervisor allows that hypervfb can shutdown the emulated vesa hardware
then it should do that.
Olaf
^ permalink raw reply
* Re: [GIT PULL] samsung-fb updates for v3.9
From: Linus Torvalds @ 2013-02-22 1:48 UTC (permalink / raw)
To: Jingoo Han
Cc: linux-fbdev, linux-kernel, Florian Tobias Schandinat,
Andrew Morton
In-Reply-To: <00b801ce0ff2$c3dfa800$4b9ef800$%han@samsung.com>
On Wed, Feb 20, 2013 at 9:17 PM, Jingoo Han <jg1.han@samsung.com> wrote:
> samsung-fb updates for the v3.9:
Ok, there's a good gpg signed tag now, with a very recent gpg key. Try
to get that key signed by a few people.
Anyway, I pulled, and noticed that I had gotten these patches through
Andrew, so then I undid my pull as unnecessary. But I bet Andrew will
be happy if he can rely on you maintaining it, so I guess this whole
thing will work out in the future.
Of course, I'd be even happier if somebody were to step up maintaining
all of fbdev. Oh well.
Linus
^ permalink raw reply
* Re: [GIT PULL] exynos-dp updates for v3.9
From: Linus Torvalds @ 2013-02-22 1:51 UTC (permalink / raw)
To: Jingoo Han
Cc: linux-fbdev, linux-kernel, Florian Tobias Schandinat,
Andrew Morton
In-Reply-To: <00b901ce0ff3$1967b6a0$4c3723e0$%han@samsung.com>
On Wed, Feb 20, 2013 at 9:20 PM, Jingoo Han <jg1.han@samsung.com> wrote:
>
> git://github.com/jingoo/linux.git tags/exynos-dp-3.9
Ok, Andrew seems to have taken these patches too, so I got them through him.
Linus
^ permalink raw reply
* RE: [PATCH RFC] video: Add Hyper-V Synthetic Video Frame Buffer Driver
From: Haiyang Zhang @ 2013-02-22 4:11 UTC (permalink / raw)
To: Olaf Hering
Cc: FlorianSchandinat@gmx.de, linux-fbdev@vger.kernel.org,
KY Srinivasan, jasowang@redhat.com, linux-kernel@vger.kernel.org,
devel@linuxdriverproject.org
In-Reply-To: <20130221155359.GA28637@aepfle.de>
> From: Olaf Hering
> Sent: Thursday, February 21, 2013 10:53 AM
> To: Haiyang Zhang
> Cc: FlorianSchandinat@gmx.de; linux-fbdev@vger.kernel.org; KY Srinivasan; jasowang@redhat.com; linux-kernel@vger.kernel.org; devel@linuxdriverproject.org
> Subject: Re: [PATCH RFC] video: Add Hyper-V Synthetic Video Frame Buffer Driver
>
> On Tue, Feb 19, Haiyang Zhang wrote:
>
> > In my test, the vesafb doesn't automatically give up the emulated video device,
> > unless I add the DMI based mechanism to let it exit on Hyper-V.
>
> From reading the code, it seems to do that via
> do_remove_conflicting_framebuffers(). hypervfb does not set apertures
> etc, so that function is a noop.
We are currently allocating a new framebuffer for hyperv_fb, which is different
from the framebuffer for the emulated video. So this cannot be detected by
do_remove_conflicting_framebuffers() based on apertures_overlap().
> My point is that with this new driver distro kernel will have no console
> output until hypervfb is loaded. On native hardware there is at least
> vesafb which can display something until initrd is running. So if the
> hypervisor allows that hypervfb can shutdown the emulated vesa hardware
> then it should do that.
Since the generic vga driver starts to work early in the boot process, the console
messages are still displayed without vesafb. Actually, I didn't see any console
messages missing when comparing it to the original VM before my patch.
Thanks,
- Haiyang
^ permalink raw reply
* [PATCH v2] mfd: as3711: add OF support
From: Guennadi Liakhovetski @ 2013-02-25 11:26 UTC (permalink / raw)
To: linux-kernel-u79uwXL29TY76Z2rM5mHXA
Cc: linux-fbdev-u79uwXL29TY76Z2rM5mHXA, Samuel Ortiz,
devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ, Mark Brown,
Magnus Damm, Simon Horman, Richard Purdie, Andrew Morton,
Liam Girdwood
In-Reply-To: <Pine.LNX.4.64.1302151101140.7446-0199iw4Nj15frtckUFj5Ag@public.gmane.org>
Add device-tree bindings to the AS3711 regulator and backlight drivers.
Signed-off-by: Guennadi Liakhovetski <g.liakhovetski@gmx.de>
---
v2:
1. remove a redundant of_device_is_available() check, this also eliminates
a compile breakage
2. add .of_node regulator configuration field initialisation
3. add parenthesis to silence compiler warnings
Documentation/devicetree/bindings/mfd/as3711.txt | 73 +++++++++++++
drivers/mfd/as3711.c | 27 ++++-
drivers/regulator/as3711-regulator.c | 74 +++++++++++++-
drivers/video/backlight/as3711_bl.c | 118 +++++++++++++++++++++-
4 files changed, 284 insertions(+), 8 deletions(-)
create mode 100644 Documentation/devicetree/bindings/mfd/as3711.txt
diff --git a/Documentation/devicetree/bindings/mfd/as3711.txt b/Documentation/devicetree/bindings/mfd/as3711.txt
new file mode 100644
index 0000000..d98cf18
--- /dev/null
+++ b/Documentation/devicetree/bindings/mfd/as3711.txt
@@ -0,0 +1,73 @@
+AS3711 is an I2C PMIC from Austria MicroSystems with multiple DCDC and LDO power
+supplies, a battery charger and an RTC. So far only bindings for the two stepup
+DCDC converters are defined. Other DCDC and LDO supplies are configured, using
+standard regulator properties, they must belong to a sub-node, called
+"regulators" and be called "sd1" to "sd4" and "ldo1" to "ldo8." Stepup converter
+configuration should be placed in a subnode, called "backlight."
+
+Compulsory properties:
+- compatible : must be "ams,as3711"
+- reg : specifies the I2C address
+
+To use the SU1 converter as a backlight source the following two properties must
+be provided:
+- su1-dev : framebuffer phandle
+- su1-max-uA : maximum current
+
+To use the SU2 converter as a backlight source the following two properties must
+be provided:
+- su2-dev : framebuffer phandle
+- su1-max-uA : maximum current
+
+Additionally one of these properties must be provided to select the type of
+feedback used:
+- su2-feedback-voltage : voltage feedback is used
+- su2-feedback-curr1 : CURR1 input used for current feedback
+- su2-feedback-curr2 : CURR2 input used for current feedback
+- su2-feedback-curr3 : CURR3 input used for current feedback
+- su2-feedback-curr-auto: automatic current feedback selection
+
+and one of these to select the over-voltage protection pin
+- su2-fbprot-lx-sd4 : LX_SD4 is used for over-voltage protection
+- su2-fbprot-gpio2 : GPIO2 is used for over-voltage protection
+- su2-fbprot-gpio3 : GPIO3 is used for over-voltage protection
+- su2-fbprot-gpio4 : GPIO4 is used for over-voltage protection
+
+If "su2-feedback-curr-auto" is selected, one or more of the following properties
+have to be specified:
+- su2-auto-curr1 : use CURR1 input for current feedback
+- su2-auto-curr2 : use CURR2 input for current feedback
+- su2-auto-curr3 : use CURR3 input for current feedback
+
+Example:
+
+as3711@40 {
+ compatible = "ams,as3711";
+ reg = <0x40>;
+
+ regulators {
+ sd4 {
+ regulator-name = "1.215V";
+ regulator-min-microvolt = <1215000>;
+ regulator-max-microvolt = <1235000>;
+ };
+ ldo2 {
+ regulator-name = "2.8V CPU";
+ regulator-min-microvolt = <2800000>;
+ regulator-max-microvolt = <2800000>;
+ regulator-always-on;
+ regulator-boot-on;
+ };
+ };
+
+ backlight {
+ compatible = "ams,as3711-bl";
+ su2-dev = <&lcdc>;
+ su2-max-uA = <36000>;
+ su2-feedback-curr-auto;
+ su2-fbprot-gpio4;
+ su2-auto-curr1;
+ su2-auto-curr2;
+ su2-auto-curr3;
+ };
+};
diff --git a/drivers/mfd/as3711.c b/drivers/mfd/as3711.c
index e994c96..01e4141 100644
--- a/drivers/mfd/as3711.c
+++ b/drivers/mfd/as3711.c
@@ -112,16 +112,34 @@ static const struct regmap_config as3711_regmap_config = {
.cache_type = REGCACHE_RBTREE,
};
+#ifdef CONFIG_OF
+static struct of_device_id as3711_of_match[] = {
+ {.compatible = "ams,as3711",},
+ {}
+};
+MODULE_DEVICE_TABLE(of, as3711_of_match);
+#endif
+
static int as3711_i2c_probe(struct i2c_client *client,
const struct i2c_device_id *id)
{
struct as3711 *as3711;
- struct as3711_platform_data *pdata = client->dev.platform_data;
+ struct as3711_platform_data *pdata;
unsigned int id1, id2;
int ret;
- if (!pdata)
- dev_dbg(&client->dev, "Platform data not found\n");
+ if (!client->dev.of_node) {
+ pdata = client->dev.platform_data;
+ if (!pdata)
+ dev_dbg(&client->dev, "Platform data not found\n");
+ } else {
+ pdata = devm_kzalloc(&client->dev,
+ sizeof(*pdata), GFP_KERNEL);
+ if (!pdata) {
+ dev_err(&client->dev, "Failed to allocate pdata\n");
+ return -ENOMEM;
+ }
+ }
as3711 = devm_kzalloc(&client->dev, sizeof(struct as3711), GFP_KERNEL);
if (!as3711) {
@@ -193,7 +211,8 @@ static struct i2c_driver as3711_i2c_driver = {
.driver = {
.name = "as3711",
.owner = THIS_MODULE,
- },
+ .of_match_table = of_match_ptr(as3711_of_match),
+ },
.probe = as3711_i2c_probe,
.remove = as3711_i2c_remove,
.id_table = as3711_i2c_id,
diff --git a/drivers/regulator/as3711-regulator.c b/drivers/regulator/as3711-regulator.c
index f0ba8c4..0539b3e 100644
--- a/drivers/regulator/as3711-regulator.c
+++ b/drivers/regulator/as3711-regulator.c
@@ -13,9 +13,11 @@
#include <linux/init.h>
#include <linux/mfd/as3711.h>
#include <linux/module.h>
+#include <linux/of.h>
#include <linux/platform_device.h>
#include <linux/regmap.h>
#include <linux/regulator/driver.h>
+#include <linux/regulator/of_regulator.h>
#include <linux/slab.h>
struct as3711_regulator_info {
@@ -276,6 +278,60 @@ static struct as3711_regulator_info as3711_reg_info[] = {
#define AS3711_REGULATOR_NUM ARRAY_SIZE(as3711_reg_info)
+static const char *as3711_regulator_of_names[AS3711_REGULATOR_NUM] = {
+ [AS3711_REGULATOR_SD_1] = "sd1",
+ [AS3711_REGULATOR_SD_2] = "sd2",
+ [AS3711_REGULATOR_SD_3] = "sd3",
+ [AS3711_REGULATOR_SD_4] = "sd4",
+ [AS3711_REGULATOR_LDO_1] = "ldo1",
+ [AS3711_REGULATOR_LDO_2] = "ldo2",
+ [AS3711_REGULATOR_LDO_3] = "ldo3",
+ [AS3711_REGULATOR_LDO_4] = "ldo4",
+ [AS3711_REGULATOR_LDO_5] = "ldo5",
+ [AS3711_REGULATOR_LDO_6] = "ldo6",
+ [AS3711_REGULATOR_LDO_7] = "ldo7",
+ [AS3711_REGULATOR_LDO_8] = "ldo8",
+};
+
+static int as3711_regulator_parse_dt(struct device *dev,
+ struct device_node **of_node, const int count)
+{
+ struct as3711_regulator_pdata *pdata = dev_get_platdata(dev);
+ struct device_node *regulators + of_find_node_by_name(dev->parent->of_node, "regulators");
+ struct of_regulator_match *matches, *match;
+ int ret, i;
+
+ if (!regulators) {
+ dev_err(dev, "regulator node not found\n");
+ return -ENODEV;
+ }
+
+ matches = devm_kzalloc(dev, sizeof(*matches) * count, GFP_KERNEL);
+ if (!matches)
+ return -ENOMEM;
+
+ for (i = 0, match = matches; i < count; i++, match++) {
+ match->name = as3711_regulator_of_names[i];
+ match->driver_data = as3711_reg_info + i;
+ }
+
+ ret = of_regulator_match(dev->parent, regulators, matches, count);
+ of_node_put(regulators);
+ if (ret < 0) {
+ dev_err(dev, "Error parsing regulator init data: %d\n", ret);
+ return ret;
+ }
+
+ for (i = 0, match = matches; i < count; i++, match++)
+ if (match->of_node) {
+ pdata->init_data[i] = match->init_data;
+ of_node[i] = match->of_node;
+ }
+
+ return 0;
+}
+
static int as3711_regulator_probe(struct platform_device *pdev)
{
struct as3711_regulator_pdata *pdata = dev_get_platdata(&pdev->dev);
@@ -284,13 +340,24 @@ static int as3711_regulator_probe(struct platform_device *pdev)
struct regulator_config config = {.dev = &pdev->dev,};
struct as3711_regulator *reg = NULL;
struct as3711_regulator *regs;
+ struct device_node *of_node[AS3711_REGULATOR_NUM] = {};
struct regulator_dev *rdev;
struct as3711_regulator_info *ri;
int ret;
int id;
- if (!pdata)
- dev_dbg(&pdev->dev, "No platform data...\n");
+ if (!pdata) {
+ dev_err(&pdev->dev, "No platform data...\n");
+ return -ENODEV;
+ }
+
+ if (pdev->dev.parent->of_node) {
+ ret = as3711_regulator_parse_dt(&pdev->dev, of_node, AS3711_REGULATOR_NUM);
+ if (ret < 0) {
+ dev_err(&pdev->dev, "DT parsing failed: %d\n", ret);
+ return ret;
+ }
+ }
regs = devm_kzalloc(&pdev->dev, AS3711_REGULATOR_NUM *
sizeof(struct as3711_regulator), GFP_KERNEL);
@@ -300,7 +367,7 @@ static int as3711_regulator_probe(struct platform_device *pdev)
}
for (id = 0, ri = as3711_reg_info; id < AS3711_REGULATOR_NUM; ++id, ri++) {
- reg_data = pdata ? pdata->init_data[id] : NULL;
+ reg_data = pdata->init_data[id];
/* No need to register if there is no regulator data */
if (!reg_data)
@@ -312,6 +379,7 @@ static int as3711_regulator_probe(struct platform_device *pdev)
config.init_data = reg_data;
config.driver_data = reg;
config.regmap = as3711->regmap;
+ config.of_node = of_node[id];
rdev = regulator_register(&ri->desc, &config);
if (IS_ERR(rdev)) {
diff --git a/drivers/video/backlight/as3711_bl.c b/drivers/video/backlight/as3711_bl.c
index c6bc65d..c78e4cb 100644
--- a/drivers/video/backlight/as3711_bl.c
+++ b/drivers/video/backlight/as3711_bl.c
@@ -257,6 +257,109 @@ static int as3711_bl_register(struct platform_device *pdev,
return 0;
}
+static int as3711_backlight_parse_dt(struct device *dev)
+{
+ struct as3711_bl_pdata *pdata = dev_get_platdata(dev);
+ struct device_node *bl + of_find_node_by_name(dev->parent->of_node, "backlight"), *fb;
+ int ret;
+
+ if (!bl) {
+ dev_dbg(dev, "backlight node not found\n");
+ return -ENODEV;
+ }
+
+ fb = of_parse_phandle(bl, "su1-dev", 0);
+ if (fb) {
+ pdata->su1_fb = fb->full_name;
+
+ ret = of_property_read_u32(bl, "su1-max-uA", &pdata->su1_max_uA);
+ if (pdata->su1_max_uA <= 0)
+ ret = -EINVAL;
+ if (ret < 0)
+ return ret;
+ }
+
+ fb = of_parse_phandle(bl, "su2-dev", 0);
+ if (fb) {
+ int count = 0;
+
+ pdata->su2_fb = fb->full_name;
+
+ ret = of_property_read_u32(bl, "su2-max-uA", &pdata->su2_max_uA);
+ if (pdata->su2_max_uA <= 0)
+ ret = -EINVAL;
+ if (ret < 0)
+ return ret;
+
+ if (of_find_property(bl, "su2-feedback-voltage", NULL)) {
+ pdata->su2_feedback = AS3711_SU2_VOLTAGE;
+ count++;
+ }
+ if (of_find_property(bl, "su2-feedback-curr1", NULL)) {
+ pdata->su2_feedback = AS3711_SU2_CURR1;
+ count++;
+ }
+ if (of_find_property(bl, "su2-feedback-curr2", NULL)) {
+ pdata->su2_feedback = AS3711_SU2_CURR2;
+ count++;
+ }
+ if (of_find_property(bl, "su2-feedback-curr3", NULL)) {
+ pdata->su2_feedback = AS3711_SU2_CURR3;
+ count++;
+ }
+ if (of_find_property(bl, "su2-feedback-curr-auto", NULL)) {
+ pdata->su2_feedback = AS3711_SU2_CURR_AUTO;
+ count++;
+ }
+ if (count != 1)
+ return -EINVAL;
+
+ count = 0;
+ if (of_find_property(bl, "su2-fbprot-lx-sd4", NULL)) {
+ pdata->su2_fbprot = AS3711_SU2_LX_SD4;
+ count++;
+ }
+ if (of_find_property(bl, "su2-fbprot-gpio2", NULL)) {
+ pdata->su2_fbprot = AS3711_SU2_GPIO2;
+ count++;
+ }
+ if (of_find_property(bl, "su2-fbprot-gpio3", NULL)) {
+ pdata->su2_fbprot = AS3711_SU2_GPIO3;
+ count++;
+ }
+ if (of_find_property(bl, "su2-fbprot-gpio4", NULL)) {
+ pdata->su2_fbprot = AS3711_SU2_GPIO4;
+ count++;
+ }
+ if (count != 1)
+ return -EINVAL;
+
+ count = 0;
+ if (of_find_property(bl, "su2-auto-curr1", NULL)) {
+ pdata->su2_auto_curr1 = true;
+ count++;
+ }
+ if (of_find_property(bl, "su2-auto-curr2", NULL)) {
+ pdata->su2_auto_curr2 = true;
+ count++;
+ }
+ if (of_find_property(bl, "su2-auto-curr3", NULL)) {
+ pdata->su2_auto_curr3 = true;
+ count++;
+ }
+
+ /*
+ * At least one su2-auto-curr* must be specified iff
+ * AS3711_SU2_CURR_AUTO is used
+ */
+ if (!count ^ (pdata->su2_feedback != AS3711_SU2_CURR_AUTO))
+ return -EINVAL;
+ }
+
+ return 0;
+}
+
static int as3711_backlight_probe(struct platform_device *pdev)
{
struct as3711_bl_pdata *pdata = dev_get_platdata(&pdev->dev);
@@ -266,11 +369,24 @@ static int as3711_backlight_probe(struct platform_device *pdev)
unsigned int max_brightness;
int ret;
- if (!pdata || (!pdata->su1_fb && !pdata->su2_fb)) {
+ if (!pdata) {
dev_err(&pdev->dev, "No platform data, exiting...\n");
return -ENODEV;
}
+ if (pdev->dev.parent->of_node) {
+ ret = as3711_backlight_parse_dt(&pdev->dev);
+ if (ret < 0) {
+ dev_err(&pdev->dev, "DT parsing failed: %d\n", ret);
+ return ret;
+ }
+ }
+
+ if (!pdata->su1_fb && !pdata->su2_fb) {
+ dev_err(&pdev->dev, "No framebuffer specified\n");
+ return -EINVAL;
+ }
+
/*
* Due to possible hardware damage I chose to block all modes,
* unsupported on my hardware. Anyone, wishing to use any of those modes
--
1.7.2.5
^ permalink raw reply related
* [PATCH] fbmon: use VESA_DMT_VSYNC_HIGH to fix typo
From: Jingoo Han @ 2013-02-26 3:05 UTC (permalink / raw)
To: 'Dave Airlie'
Cc: linux-fbdev, 'Steffen Trumtrar', dri-devel,
'Florian Tobias Schandinat'
VESA_DMT_VSYNC_HIGH should be used instead of VESA_DMT_HSYNC_HIGH,
because FB_SYNC_VERT_HIGH_ACT is related to vsync, not to hsync.
Signed-off-by: Jingoo Han <jg1.han@samsung.com>
Cc: Steffen Trumtrar <s.trumtrar@pengutronix.de>
---
drivers/video/fbmon.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/video/fbmon.c b/drivers/video/fbmon.c
index 94ad0f7..7f67099 100644
--- a/drivers/video/fbmon.c
+++ b/drivers/video/fbmon.c
@@ -1400,7 +1400,7 @@ int fb_videomode_from_videomode(const struct videomode *vm,
fbmode->vmode = 0;
if (vm->dmt_flags & VESA_DMT_HSYNC_HIGH)
fbmode->sync |= FB_SYNC_HOR_HIGH_ACT;
- if (vm->dmt_flags & VESA_DMT_HSYNC_HIGH)
+ if (vm->dmt_flags & VESA_DMT_VSYNC_HIGH)
fbmode->sync |= FB_SYNC_VERT_HIGH_ACT;
if (vm->data_flags & DISPLAY_FLAGS_INTERLACED)
fbmode->vmode |= FB_VMODE_INTERLACED;
--
1.7.2.5
^ permalink raw reply related
* Re: [PATCH] fbmon: use VESA_DMT_VSYNC_HIGH to fix typo
From: Steffen Trumtrar @ 2013-02-26 9:06 UTC (permalink / raw)
To: Jingoo Han; +Cc: linux-fbdev, dri-devel, 'Florian Tobias Schandinat'
In-Reply-To: <009501ce13ce$2e912d20$8bb38760$%han@samsung.com>
On Tue, Feb 26, 2013 at 12:05:50PM +0900, Jingoo Han wrote:
> VESA_DMT_VSYNC_HIGH should be used instead of VESA_DMT_HSYNC_HIGH,
> because FB_SYNC_VERT_HIGH_ACT is related to vsync, not to hsync.
>
> Signed-off-by: Jingoo Han <jg1.han@samsung.com>
> Cc: Steffen Trumtrar <s.trumtrar@pengutronix.de>
> ---
> drivers/video/fbmon.c | 2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/drivers/video/fbmon.c b/drivers/video/fbmon.c
> index 94ad0f7..7f67099 100644
> --- a/drivers/video/fbmon.c
> +++ b/drivers/video/fbmon.c
> @@ -1400,7 +1400,7 @@ int fb_videomode_from_videomode(const struct videomode *vm,
> fbmode->vmode = 0;
> if (vm->dmt_flags & VESA_DMT_HSYNC_HIGH)
> fbmode->sync |= FB_SYNC_HOR_HIGH_ACT;
> - if (vm->dmt_flags & VESA_DMT_HSYNC_HIGH)
> + if (vm->dmt_flags & VESA_DMT_VSYNC_HIGH)
> fbmode->sync |= FB_SYNC_VERT_HIGH_ACT;
> if (vm->data_flags & DISPLAY_FLAGS_INTERLACED)
> fbmode->vmode |= FB_VMODE_INTERLACED;
Hi,
looks good to me.
Regards,
Steffen
--
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 v17 2/7] video: add display_timing and videomode
From: Tomi Valkeinen @ 2013-02-27 15:45 UTC (permalink / raw)
To: Steffen Trumtrar
Cc: linux-fbdev-u79uwXL29TY76Z2rM5mHXA, Mohammed, Afzal, Dave Airlie,
devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ,
Florian Tobias Schandinat,
dri-devel-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW, Rob Clark,
Tomi Valkeinen, Laurent Pinchart, kernel-bIcnvbaLZ9MEGnE8C9+IrQ,
Guennady Liakhovetski, linux-media-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <51223615.4090709-X3B1VOXEql0@public.gmane.org>
[-- Attachment #1: Type: text/plain, Size: 1178 bytes --]
Ping.
On 2013-02-18 16:09, Tomi Valkeinen wrote:
> Hi Steffen,
>
> On 2013-01-25 11:01, Steffen Trumtrar wrote:
>
>> +/* VESA display monitor timing parameters */
>> +#define VESA_DMT_HSYNC_LOW BIT(0)
>> +#define VESA_DMT_HSYNC_HIGH BIT(1)
>> +#define VESA_DMT_VSYNC_LOW BIT(2)
>> +#define VESA_DMT_VSYNC_HIGH BIT(3)
>> +
>> +/* display specific flags */
>> +#define DISPLAY_FLAGS_DE_LOW BIT(0) /* data enable flag */
>> +#define DISPLAY_FLAGS_DE_HIGH BIT(1)
>> +#define DISPLAY_FLAGS_PIXDATA_POSEDGE BIT(2) /* drive data on pos. edge */
>> +#define DISPLAY_FLAGS_PIXDATA_NEGEDGE BIT(3) /* drive data on neg. edge */
>> +#define DISPLAY_FLAGS_INTERLACED BIT(4)
>> +#define DISPLAY_FLAGS_DOUBLESCAN BIT(5)
>
> <snip>
>
>> + unsigned int dmt_flags; /* VESA DMT flags */
>> + unsigned int data_flags; /* video data flags */
>
> Why did you go for this approach? To be able to represent
> true/false/not-specified?
>
> Would it be simpler to just have "flags" field? What does it give us to
> have those two separately?
>
> Should the above say raising edge/falling edge instead of positive
> edge/negative edge?
>
> Tomi
>
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 899 bytes --]
^ permalink raw reply
* Re: [PATCH v17 2/7] video: add display_timing and videomode
From: Steffen Trumtrar @ 2013-02-27 16:05 UTC (permalink / raw)
To: Tomi Valkeinen
Cc: devicetree-discuss, Dave Airlie, Rob Herring, linux-fbdev,
dri-devel, Laurent Pinchart, Thierry Reding,
Guennady Liakhovetski, linux-media, Stephen Warren,
Florian Tobias Schandinat, Rob Clark, Leela Krishna Amudala,
Mohammed, Afzal, kernel
In-Reply-To: <512E2A1B.6040704@ti.com>
Ah, sorry. Forgot to answer this.
On Wed, Feb 27, 2013 at 05:45:31PM +0200, Tomi Valkeinen wrote:
> Ping.
>
> On 2013-02-18 16:09, Tomi Valkeinen wrote:
> > Hi Steffen,
> >
> > On 2013-01-25 11:01, Steffen Trumtrar wrote:
> >
> >> +/* VESA display monitor timing parameters */
> >> +#define VESA_DMT_HSYNC_LOW BIT(0)
> >> +#define VESA_DMT_HSYNC_HIGH BIT(1)
> >> +#define VESA_DMT_VSYNC_LOW BIT(2)
> >> +#define VESA_DMT_VSYNC_HIGH BIT(3)
> >> +
> >> +/* display specific flags */
> >> +#define DISPLAY_FLAGS_DE_LOW BIT(0) /* data enable flag */
> >> +#define DISPLAY_FLAGS_DE_HIGH BIT(1)
> >> +#define DISPLAY_FLAGS_PIXDATA_POSEDGE BIT(2) /* drive data on pos. edge */
> >> +#define DISPLAY_FLAGS_PIXDATA_NEGEDGE BIT(3) /* drive data on neg. edge */
> >> +#define DISPLAY_FLAGS_INTERLACED BIT(4)
> >> +#define DISPLAY_FLAGS_DOUBLESCAN BIT(5)
> >
> > <snip>
> >
> >> + unsigned int dmt_flags; /* VESA DMT flags */
> >> + unsigned int data_flags; /* video data flags */
> >
> > Why did you go for this approach? To be able to represent
> > true/false/not-specified?
> >
We decided somewhere between v3 and v8 (I think), that those flags can be
high/low/ignored.
> > Would it be simpler to just have "flags" field? What does it give us to
> > have those two separately?
> >
I decided to split them, so it is clear that some flags are VESA defined and
the others are "invented" for the display-timings framework and may be
extended.
> > Should the above say raising edge/falling edge instead of positive
> > edge/negative edge?
> >
Hm, I used posedge/negedge because it is shorter (and because of my Verilog past
pretty natural to me :-) ). I don't know what others are thinking though.
Regards,
Steffen
--
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 v17 2/7] video: add display_timing and videomode
From: Tomi Valkeinen @ 2013-02-27 16:13 UTC (permalink / raw)
To: Steffen Trumtrar
Cc: linux-fbdev-u79uwXL29TY76Z2rM5mHXA, Mohammed, Afzal, Dave Airlie,
devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ,
Florian Tobias Schandinat,
dri-devel-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW, Rob Clark,
Laurent Pinchart, kernel-bIcnvbaLZ9MEGnE8C9+IrQ,
Guennady Liakhovetski, linux-media-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20130227160540.GA10491-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org>
[-- Attachment #1: Type: text/plain, Size: 2457 bytes --]
On 2013-02-27 18:05, Steffen Trumtrar wrote:
> Ah, sorry. Forgot to answer this.
>
> On Wed, Feb 27, 2013 at 05:45:31PM +0200, Tomi Valkeinen wrote:
>> Ping.
>>
>> On 2013-02-18 16:09, Tomi Valkeinen wrote:
>>> Hi Steffen,
>>>
>>> On 2013-01-25 11:01, Steffen Trumtrar wrote:
>>>
>>>> +/* VESA display monitor timing parameters */
>>>> +#define VESA_DMT_HSYNC_LOW BIT(0)
>>>> +#define VESA_DMT_HSYNC_HIGH BIT(1)
>>>> +#define VESA_DMT_VSYNC_LOW BIT(2)
>>>> +#define VESA_DMT_VSYNC_HIGH BIT(3)
>>>> +
>>>> +/* display specific flags */
>>>> +#define DISPLAY_FLAGS_DE_LOW BIT(0) /* data enable flag */
>>>> +#define DISPLAY_FLAGS_DE_HIGH BIT(1)
>>>> +#define DISPLAY_FLAGS_PIXDATA_POSEDGE BIT(2) /* drive data on pos. edge */
>>>> +#define DISPLAY_FLAGS_PIXDATA_NEGEDGE BIT(3) /* drive data on neg. edge */
>>>> +#define DISPLAY_FLAGS_INTERLACED BIT(4)
>>>> +#define DISPLAY_FLAGS_DOUBLESCAN BIT(5)
>>>
>>> <snip>
>>>
>>>> + unsigned int dmt_flags; /* VESA DMT flags */
>>>> + unsigned int data_flags; /* video data flags */
>>>
>>> Why did you go for this approach? To be able to represent
>>> true/false/not-specified?
>>>
>
> We decided somewhere between v3 and v8 (I think), that those flags can be
> high/low/ignored.
Okay. Why aren't they enums, though? That always makes more clear which
defines are to be used with which fields.
>>> Would it be simpler to just have "flags" field? What does it give us to
>>> have those two separately?
>>>
>
> I decided to split them, so it is clear that some flags are VESA defined and
> the others are "invented" for the display-timings framework and may be
> extended.
Hmm... Okay. Is it relevant that they are VESA defined? It just feels to
complicate handling the flags =).
>>> Should the above say raising edge/falling edge instead of positive
>>> edge/negative edge?
>>>
>
> Hm, I used posedge/negedge because it is shorter (and because of my Verilog past
> pretty natural to me :-) ). I don't know what others are thinking though.
I guess it's quite clear, but it's still different terms than used
elsewhere, e.g. documentation for videomodes.
Another thing I noticed while using the new videomode, display_timings.h
has a few names that are quite short and generic. Like "TE_MIN", which
is now a global define. And "timing_entry". Either name could be well
used internally in some .c file, and could easily clash.
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 899 bytes --]
^ permalink raw reply
* [PATCH] video: make goldfish option have a dependency on goldfish
From: Paul Gortmaker @ 2013-02-27 18:26 UTC (permalink / raw)
To: linux-fbdev; +Cc: linux-kernel, Paul Gortmaker, Florian Tobias Schandinat
Nearly all the other goldfish peripherals (mtd, keyboard, etc)
have a dependency on the main platform's GOLDFISH Kconfig item,
but this one got skipped, so add it.
Cc: Florian Tobias Schandinat <FlorianSchandinat@gmx.de>
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
---
drivers/video/Kconfig | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/video/Kconfig b/drivers/video/Kconfig
index 4c1546f..2df6d9c 100644
--- a/drivers/video/Kconfig
+++ b/drivers/video/Kconfig
@@ -2208,7 +2208,7 @@ config FB_XILINX
config FB_GOLDFISH
tristate "Goldfish Framebuffer"
- depends on FB
+ depends on FB && GOLDFISH
select FB_CFB_FILLRECT
select FB_CFB_COPYAREA
select FB_CFB_IMAGEBLIT
--
1.8.1.2
^ permalink raw reply related
* [PATCH RESEND] matroxfb: Convert struct i2c_msg initialization to C99 format
From: Jean Delvare @ 2013-02-28 9:39 UTC (permalink / raw)
To: Florian Tobias Schandinat; +Cc: linux-fbdev, linux-kernel, Andrew Morton
From: Shubhrajyoti Datta <omaplinuxkernel@gmail.com>
Convert the struct i2c_msg initialization to C99 format. This makes
maintaining and editing the code simpler. Also helps once other fields
like transferred are added in future.
Thanks to Julia Lawall for automating the conversion.
Signed-off-by: Shubhrajyoti D <shubhrajyoti@ti.com>
Signed-off-by: Jean Delvare <khali@linux-fr.org>
---
Patch already sent by Shubhrajyoti Datta on 2012-10-10.
drivers/video/matrox/matroxfb_maven.c | 16 ++++++++++++++--
1 file changed, 14 insertions(+), 2 deletions(-)
--- linux-3.9-rc0.orig/drivers/video/matrox/matroxfb_maven.c 2013-02-28 09:30:13.134091106 +0100
+++ linux-3.9-rc0/drivers/video/matrox/matroxfb_maven.c 2013-02-28 09:55:14.731092841 +0100
@@ -137,8 +137,20 @@ static int* get_ctrl_ptr(struct maven_da
static int maven_get_reg(struct i2c_client* c, char reg) {
char dst;
- struct i2c_msg msgs[] = {{ c->addr, I2C_M_REV_DIR_ADDR, sizeof(reg), ® },
- { c->addr, I2C_M_RD | I2C_M_NOSTART, sizeof(dst), &dst }};
+ struct i2c_msg msgs[] = {
+ {
+ .addr = c->addr,
+ .flags = I2C_M_REV_DIR_ADDR,
+ .len = sizeof(reg),
+ .buf = ®
+ },
+ {
+ .addr = c->addr,
+ .flags = I2C_M_RD | I2C_M_NOSTART,
+ .len = sizeof(dst),
+ .buf = &dst
+ }
+ };
s32 err;
err = i2c_transfer(c->adapter, msgs, 2);
--
Jean Delvare
^ permalink raw reply
* Re: [PATCH 0/9] System Framebuffer Bus (sysfb)
From: David Herrmann @ 2013-02-28 12:20 UTC (permalink / raw)
To: Dave Airlie
Cc: linux-kernel, Florian Tobias Schandinat, linux-fbdev,
David Airlie, dri-devel
In-Reply-To: <CAPM=9tzDXLqUG3c6VsMjaJ_1997h7f+_3kB0C0N2imuQcXsD6Q@mail.gmail.com>
Hi Dave
Sorry, I was busy reworking the HIDP layer. I finally got time to
continue my work on this again. See below:
On Mon, Feb 18, 2013 at 12:47 AM, Dave Airlie <airlied@gmail.com> wrote:
[..snap..]
> As I said maybe I'm concentrating on the problem you aren't trying to fix,
> but then I'm not sure I've enough information on the problem you are
> trying to fix,
>
> remove_confilicting_framebuffers might be ugly but it does 90% of what we want,
> I just want to understand why this will make it better,
Ok, let me describe the problem in more detail:
We currently have different drivers that can make use of "system
framebuffers" (as I call them for now):
- vgacon
- fbdev
- DRM
(- vgalog) (similar to fblog/drmlog but using vga/VBE)
Scenarios:
- Imagine you have CONFIG_FB=n but VGACON=y for debugging. Who is then
responsible of kicking out VGACON when DRM drivers are loaded? (and
vice versa)
- i915 is loaded and the user does a "modprobe vesafb". Who prevents
vesafb from loading?
- If I use vgalog, who unloads it when fbdev/DRM drivers are loaded?
(and vice versa)
Our current solution consists of "vgacon_cleanup()" and
"remove_conflicting_frambuffers()". We could add similar helpers for
all other scenarios, but I promise, this will get pretty complex.
Another problem: All VBE/EFI framebuffer drivers currently do something like:
platform_driver_register("my-device"...);
platform_device_add("my-device"...);
Why not provide a unique platform-device-name and add the device in
architecture setup code? This would prevent multiple drivers from
being probed on a single platform device.
My bus-solution was the most straightforward to implement and makes
testing really easy (as you can probe/remove drivers from userspace).
However, I understand if we don't want to introduce any ABI.
So I was rethinking this idea and maybe we simplify the bus-solution
and instead use some priority-based driver loading. That is, the
architecture code creates a platform-device for all available
system-framebuffers (which is probably always at most one device).
Then drivers simply provide platform-drivers that can be loaded on the
device. But instead of using platform_driver_register(), they use
vbe_driver_register() or something similar and pass in the
platform-driver _plus_ a priority. The wrapper then compares the
priorities, unloads the old driver and probes the new one.
This guarantees that a new driver will only replace the current driver
if it has a higher priority. vgacon/vgalog->fbdev->DRM
How does that fix the problems you described?
Well, it doesn't. But it makes them more obvious as there is now a
central place that manages the hand-over.
On the other hand, I don't understand why the problems you described
have anything to do with the hand-over itself? They also occur on
driver-unloading without any handover, don't they?
So I think we simply need to fix vesafb, efifb, ... to unmap any
pending user-space mappings during unloading. This also guarantees
that these mappings are dead when any other driver takes over. And
with the platform-devices that I want to introduce, we guarantee that
the drivers get unloaded correctly even during hand-over.
The remove_conflicting_framebuffers() call can stay for all other
conflicts, although I think these _really_ should be handled by
Kconfig. But ok, I don't mind this call. It doesn't break anything.
Why am I doing this?
To get dvbe/defi and vbelog working. I use these on my machine as
nouveau doesn't work and fbdev is just ugly to work with. I was also
told that they proved to be useful in virtualization environments.
I don't mind setting dvbe as "depends on !<any-drm-driver> &&
!CONFIG_FB && !CONFIG_VT" but I thought fixing this directly where it
is broken ought to be the better way.
So, any comments welcome.
If there are no major objections, I will try to implement it and also
try to fix vesafb to unmap the mmap()s during unloading. If that turns
out to work well, I can also fix the other drivers.
Thanks for the comments
David
^ permalink raw reply
* Re: [PATCH 0/9] System Framebuffer Bus (sysfb)
From: Geert Uytterhoeven @ 2013-02-28 13:22 UTC (permalink / raw)
To: David Herrmann
Cc: Dave Airlie, linux-kernel, Florian Tobias Schandinat, linux-fbdev,
David Airlie, dri-devel
In-Reply-To: <CANq1E4QoutxRkuBj3p2vaw2U4-GN0Gz4ueopKkDavX_ZmgMC-w@mail.gmail.com>
On Thu, Feb 28, 2013 at 1:20 PM, David Herrmann <dh.herrmann@gmail.com> wrote:
> We currently have different drivers that can make use of "system
> framebuffers" (as I call them for now):
> - vgacon
> - fbdev
> - DRM
> (- vgalog) (similar to fblog/drmlog but using vga/VBE)
offb
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* Re: [PATCH RFC] video: Add Hyper-V Synthetic Video Frame Buffer Driver
From: Olaf Hering @ 2013-02-28 15:16 UTC (permalink / raw)
To: Haiyang Zhang
Cc: FlorianSchandinat, linux-fbdev, kys, jasowang, linux-kernel,
devel
In-Reply-To: <1360955396-14183-1-git-send-email-haiyangz@microsoft.com>
On Fri, Feb 15, Haiyang Zhang wrote:
> + if (fb_get_options("hyperv_fb", &opt) || !opt || !*opt)
> + strcpy(info->fix.id, "hyperv");
Here is a mismatch between video=<optname> and /proc/fb output.
Both should have the same string IMO.
Olaf
^ permalink raw reply
* RE: [PATCH RFC] video: Add Hyper-V Synthetic Video Frame Buffer Driver
From: Haiyang Zhang @ 2013-02-28 17:56 UTC (permalink / raw)
To: Olaf Hering
Cc: FlorianSchandinat@gmx.de, linux-fbdev@vger.kernel.org,
KY Srinivasan, jasowang@redhat.com, linux-kernel@vger.kernel.org,
devel@linuxdriverproject.org
In-Reply-To: <20130228151641.GA13552@aepfle.de>
PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBPbGFmIEhlcmluZyBbbWFpbHRv
Om9sYWZAYWVwZmxlLmRlXQ0KPiBTZW50OiBUaHVyc2RheSwgRmVicnVhcnkgMjgsIDIwMTMgMTA6
MTcgQU0NCj4gVG86IEhhaXlhbmcgWmhhbmcNCj4gQ2M6IEZsb3JpYW5TY2hhbmRpbmF0QGdteC5k
ZTsgbGludXgtZmJkZXZAdmdlci5rZXJuZWwub3JnOyBLWSBTcmluaXZhc2FuOw0KPiBqYXNvd2Fu
Z0ByZWRoYXQuY29tOyBsaW51eC1rZXJuZWxAdmdlci5rZXJuZWwub3JnOw0KPiBkZXZlbEBsaW51
eGRyaXZlcnByb2plY3Qub3JnDQo+IFN1YmplY3Q6IFJlOiBbUEFUQ0ggUkZDXSB2aWRlbzogQWRk
IEh5cGVyLVYgU3ludGhldGljIFZpZGVvIEZyYW1lIEJ1ZmZlcg0KPiBEcml2ZXINCj4gDQo+IE9u
IEZyaSwgRmViIDE1LCBIYWl5YW5nIFpoYW5nIHdyb3RlOg0KPiANCj4gPiArCWlmIChmYl9nZXRf
b3B0aW9ucygiaHlwZXJ2X2ZiIiwgJm9wdCkgfHwgIW9wdCB8fCAhKm9wdCkNCj4gDQo+ID4gKwlz
dHJjcHkoaW5mby0+Zml4LmlkLCAiaHlwZXJ2Iik7DQo+IA0KPiANCj4gSGVyZSBpcyBhIG1pc21h
dGNoIGJldHdlZW4gdmlkZW89PG9wdG5hbWU+IGFuZCAvcHJvYy9mYiBvdXRwdXQuDQo+IEJvdGgg
c2hvdWxkIGhhdmUgdGhlIHNhbWUgc3RyaW5nIElNTy4NCg0KSSB3aWxsIG1ha2UgYm90aCBvZiB0
aGVtIHRvIGJlIEtCVUlMRF9NT0ROQU1FLg0KDQpUaGFua3MsDQotIEhhaXlhbmcNCg=
^ 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