* Re: [PATCH v7][ 3/5] video: mx3fb: Introduce =?UTF-8?B?cmVndWxhdG9yIHN1c
From: Alexander Shiyan @ 2014-03-14 12:38 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <5322E6AA.1010400@eukrea.com>
0J/Rj9GC0L3QuNGG0LAsIDE0INC80LDRgNGC0LAgMjAxNCwgMTI6MjMgKzAxOjAwINC+0YIgRGVu
aXMgQ2FyaWtsaSA8ZGVuaXNAZXVrcmVhLmNvbT46CgpTYXNjaGEsIFNoYXduLCBjYW4geW91IGNv
bW1lbnQgb24gdGhhdD8KCj4gT24gMDMvMTQvMjAxNCAxMDoyMyBBTSwgQWxleGFuZGVyIFNoaXlh
biB3cm90ZToKPiA+IFdoeSB0aGlzIGNhbm5vdCBiZSBkZXZtX3JlZ3VsYXRvcl9nZXQoZGV2LCAi
bGNkIikgaW4gYm90aCBEVCBhbmQgbm9uLURUIGNhc2U/Cj4gCj4gSSBuZWVkIHRvIGFkZCBkZXZp
Y2UgdHJlZSBzdXBwb3J0IHRvIHRoZSBteDNmYiBkcml2ZXIuCj4gTXkgZmlyc3QgYXBwcm9hY2gg
Z2F2ZSBhIGJpbmRpbmcgdGhhdCBsb29rZWQgbGlrZSB0aGF0Ogo+IAo+IGNtb19xdmdhOiBkaXNw
bGF5IHsKPiAgICBtb2RlbCA9ICJDTU8tUVZHQSI7Cj4gICAgWy4uLl0KPiAgICBkaXNwbGF5LXRp
bWluZ3Mgewo+ICAgICAgcXZnYV90aW1pbmdzOiAzMjB4MjQwIHsKPiAgICAgICAgaGFjdGl2ZSA9
IDwzMjA+Owo+ICAgICAgICB2YWN0aXZlID0gPDI0MD47Cj4gICAgICAgIFsuLi5dCj4gICAgIH07
Cj4gfTsKPiAKPiBpcHU6IGlwdUA1M2ZjMDAwMCB7Cj4gICAgY29tcGF0aWJsZSA9ICJmc2wsaW14
MzEtaXB1IjsKPiAgICByZWcgPSA8IDB4NTNmYzAwMDAgMHg1Zgo+ICAgIDB4NTNmYzAwODggMHgy
YiA+Owo+ICAgIGludGVycnVwdHMgPSA8NDIgNDE+Owo+ICAgIGRtYS1jaGFubmVscyA9IDwzMj47
Cj4gICAgI2RtYS1jZWxscyA9IDwxPjsKPiAgICBjbG9ja3MgPSA8JmNsa3MgNTU+Owo+ICAgIGNs
b2NrLW5hbWVzID0gIiI7Cj4gfTsKPiAKPiBsY2RjOiBteDNmYkA1M2ZjMDBiNCB7Cj4gICAgY29t
cGF0aWJsZSA9ICJmc2wsbXgzLWZiIjsKPiAgICByZWcgPSA8MHg1M2ZjMDBiNCAweDBiPjsKPiAg
ICBjbG9ja3MgPSA8JmNsa3MgNTU+Owo+ICAgIGRtYXMgPSA8JmlwdSAxND47Cj4gICAgZG1hLW5h
bWVzID0gInR4IjsKPiAgICBkaXNwbGF5ID0gPCZjbW9fcXZnYT47Cj4gfTsKPiAKPiBUaGUgaXNz
dWUgd2FzIHRoYXQgZXhwb3J0aW5nIHRoZSAiZG1hIGlwdSBkcml2ZXIiIHdhcyBub3QgYSBnb29k
IGlkZWEuCj4gSSB3YXMgdG9sZCB0byBpbnN0ZWFkIG1ha2UgYmluZGluZ3MgdGhhdCBsb29rcyB2
ZXJ5IHNpbWlsYXIgdG8gdGhlIGlwdXYzIAo+IGRyaXZlclsxXQo+IFNvIGF0IHRoZSBlbmQgdGhh
dCBnYXZlIHNvbWV0aGluZyBsaWtlIHRoYXQ6Cj4gCj4gY21vX3F2Z2E6IGRpc3BsYXlAZGkwIHsK
PiAgICBjb21wYXRpYmxlID0gImZzbCxteDMtcGFyYWxsZWwtZGlzcGxheSI7Cj4gICAgcmVndWxh
dG9yLW5hbWUgPSAibGNkIjsKPiAgICBsY2Qtc3VwcGx5ID0gPCZyZWdfbGNkXzN2Mz47Cj4gICAg
bW9kZWwgPSAiQ01PLVFWR0EiOwo+ICAgIGRpc3BsYXktdGltaW5ncyB7Cj4gICAgICBxdmdhX3Rp
bWluZ3M6IDMyMHgyNDAgewo+ICAgICAgICBoYWN0aXZlID0gPDMyMD47Cj4gICAgICAgIHZhY3Rp
dmUgPSA8MjQwPjsKPiAgICAgICAgWy4uLl0KPiAgICAgfTsKPiB9Owo+IAo+IGlwdTogaXB1QDUz
ZmMwMDAwIHsKPiAgICBjb21wYXRpYmxlID0gImZzbCxpbXgzNS1pcHUiOwo+ICAgIHJlZyA9IDww
eDUzZmMwMDAwIDB4NDAwMD47Cj4gICAgY2xvY2tzID0gPCZjbGtzIDU1PjsKPiAgICBkaXNwbGF5
ID0gPCZjbW9fcXZnYT47Cj4gfTsKPiAKPiBTbyBoZXJlIGZzbCxpbXgzNS1pcHUgaXMgYmluZGVk
IHRvIHRoZSBteDNmYiBkcml2ZXIuCj4gQnV0IHRoZSBteDNmYiBkcml2ZXIgc3RpbGwgbmVlZCB0
byB1c2UgdGhlIGRtYS1pcHUgZHJpdmVyIHNvbWVob3cuCj4gVGhhdCdzIHdoeSB0aGUgZG1hLWlw
dSBkcml2ZXIgaXMgaGFuZGxlZCBiZWhpbmQgdGhlIHNjZW5lcywgdGhhdCB3YXkKPiBpdCdzIG5v
dCBleHBvcnRlZCB0byB0aGUgZGV2aWNlIHRyZWUgYmluZGluZ3MuCj4gCj4gTm93LCBzaW5jZSB0
aGUgbXgzZmIgZHJpdmVyIGlzIGJpbmRlZCB0byB0aGUgImZzbCxpbXgzNS1pcHUiIGNvbXBhdGli
bGUsCj4gaWYgSSB3b3VsZCBkbyBhICJteDNmYmktPnJlZ19sY2QgPSBkZXZtX3JlZ3VsYXRvcl9n
ZXQoZGV2LCAibGNkIik7IiwKPiB0aGF0IHdvdWxkIHRoZW4gbG9va3VwIGZvciB0aGUgcmVndWxh
dG9yIGluIHRoZSBteDNmYiBub2RlCj4gKFRoZSBsYXN0ICJpcHVANTNmYzAwMDAiIGhlcmUpLgo+
IAo+IEluc3RlYWQgdGhlIHJlZ3VsYXRvciBjYW4gYmUgZm91bmQgaW4gdGhlIGRpc3BsYXkgbm9k
ZSwKPiB3aGljaCBoYXMgbm8gZHJpdmVyIGFzc29jaWF0ZWQgd2l0aCBpdC4KPiAKPiBJbiB0aGUg
Y2FzZSBvZiB0aGUgaXB1djMsIHRoZSBwYXJhbGxlbCBkaXNwbGF5IGRyaXZlciBpcyBhc3NvY2lh
dGVkCj4gd2l0aCB0aGUgZGlzcGxheUBkaTAgbm9kZSwgc28gdGhlIGRldmljZSBtYXRjaGVzIHdp
dGggdGhlIGRldmljZSB0cmVlCj4gbm9kZSBkaXJlY3RseS4KPiAKPiBSZWZlcmVuY2VzOgo+IC0t
LS0tLS0tLS0tCj4gWzFdIFRoZSBpcHV2MyBkcml2ZXIgaXMgaW4gZHJpdmVycy9zdGFnaW5nL2lt
eC1kcm0vCj4gWzJdIHRoZSBkbWEgaXB1IGRyaXZlciBpcyBpbiBkcml2ZXJzL2RtYS9pcHUvCj4g
CgotLS0K
^ permalink raw reply
* Re: [PATCH v2] RFC: framebuffer: provide generic get_fb_unmapped_area
From: Uwe Kleine-König @ 2014-03-14 21:06 UTC (permalink / raw)
To: linux-fbdev
In-Reply-To: <1391447684-22556-1-git-send-email-u.kleine-koenig@pengutronix.de>
On Mon, Feb 03, 2014 at 06:14:44PM +0100, Uwe Kleine-König wrote:
> This patch makes mmapping the simple-framebuffer device work on a no-MMU
> ARM target. The code is mostly taken from
> arch/blackfin/kernel/sys_bfin.c.
>
> Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
> ---
> Hello,
>
> note this is only tested on this no-MMU machine and I don't know enough
> about framebuffers and mm to decide if this patch is sane. Also I'm
> a bit unsure about the size check, I just believed Geert that
> PAGE_ALIGN(info->fix.smem_len) is the right value to check against.
Do you still have this patch on your radar?
Best regards
Uwe
> drivers/video/fbmem.c | 20 +++++++++++++++++---
> 1 file changed, 17 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/video/fbmem.c b/drivers/video/fbmem.c
> index 7309ac704e26..d0ccedafec8c 100644
> --- a/drivers/video/fbmem.c
> +++ b/drivers/video/fbmem.c
> @@ -1491,6 +1491,22 @@ __releases(&info->lock)
> return 0;
> }
>
> +#ifdef HAVE_ARCH_FB_UNMAPPED_AREA
> +#define fb_get_unmapped_area get_fb_unmapped_area
> +#else
> +unsigned long fb_get_unmapped_area(struct file *filp, unsigned long orig_addr,
> + unsigned long len, unsigned long pgoff, unsigned long flags)
> +{
> + struct fb_info * const info = filp->private_data;
> + unsigned long fb_size = PAGE_ALIGN(info->fix.smem_len);
> +
> + if (pgoff > fb_size || len > fb_size - pgoff)
> + return -EINVAL;
> +
> + return (unsigned long)info->screen_base + pgoff;
> +}
> +#endif
> +
> static const struct file_operations fb_fops = {
> .owner = THIS_MODULE,
> .read = fb_read,
> @@ -1502,9 +1518,7 @@ static const struct file_operations fb_fops = {
> .mmap = fb_mmap,
> .open = fb_open,
> .release = fb_release,
> -#ifdef HAVE_ARCH_FB_UNMAPPED_AREA
> - .get_unmapped_area = get_fb_unmapped_area,
> -#endif
> + .get_unmapped_area = fb_get_unmapped_area,
> #ifdef CONFIG_FB_DEFERRED_IO
> .fsync = fb_deferred_io_fsync,
> #endif
> --
> 1.8.5.2
>
>
--
Pengutronix e.K. | Uwe Kleine-König |
Industrial Linux Solutions | http://www.pengutronix.de/ |
^ permalink raw reply
* Possible bug in deferred io with mmaped memory?
From: Conor O @ 2014-03-15 11:29 UTC (permalink / raw)
To: linux-fbdev
Hello all, I hope this is a reasonable place to post a bug. If I fix
it I can post a fix too.
I believe there might be a bug in deferred io. In my fb driver I have
a block of memory, allocated with kmalloc, that I can mmap, write to,
and munmap perfectly fine using my own mmap routine. As soon as I
switch to deferred io, there's a problem:
From userspace, I can mmap the framebuffer memory fine and write to
it. The deferred io driver routine is called and updates the display
perfectly correctly. As soon as I call munmap() I get a repeated
kernel messages. This happens on ARM but not under an Ubuntu
Virtualbox VM (x86):
BUG: Bad page state in process fbtest1 pfn:ad11d
page:c0dc03a0 count:0 mapcount:0 mapping:edbf7144 index:0x1d
page flags: 0x94(referenced|dirty|slab)
Modules linked in: hhlcd28a(O) sysimgblt sysfillrect syscopyarea
fb_sys_fops bnep ipv6 mwifiex_sdio mwifiex btmrvl_sdio firmware_class
btmrvl cfg80211 bluetooth rfkill
[<c0014bc8>] (unwind_backtrace+0x0/0x11c) from [<c00c44d4>] (bad_page+0xd0/0xfc)
[<c00c44d4>] (bad_page+0xd0/0xfc) from [<c00c45c0>]
(free_pages_prepare+0xc0/0x150)
[<c00c45c0>] (free_pages_prepare+0xc0/0x150) from [<c00c5a34>]
(free_hot_cold_page+0x20/0x188)
[<c00c5a34>] (free_hot_cold_page+0x20/0x188) from [<c00c5dc4>]
(free_hot_cold_page_list+0x7c/0x9c)
[<c00c5dc4>] (free_hot_cold_page_list+0x7c/0x9c) from [<c00c90c0>]
(release_pages+0x1b4/0x1c8)
[<c00c90c0>] (release_pages+0x1b4/0x1c8) from [<c00ea854>]
(free_pages_and_swap_cache+0x8c/0x9c)
[<c00ea854>] (free_pages_and_swap_cache+0x8c/0x9c) from [<c00dfff4>]
(unmap_region+0x100/0x154)
[<c00dfff4>] (unmap_region+0x100/0x154) from [<c00e116c>]
(do_munmap+0x218/0x2a4)
[<c00e116c>] (do_munmap+0x218/0x2a4) from [<c00e1234>] (vm_munmap+0x3c/0x50)
[<c00e1234>] (vm_munmap+0x3c/0x50) from [<c000dc20>] (ret_fast_syscall+0x0/0x30)
[repeated for N pages]
root@duovero:~/testdrv#
I will now convert to using vmalloc and check to see if this happens too.
Thanks,
Conor.
^ permalink raw reply
* Re: Possible bug in deferred io with mmaped memory?
From: Conor O @ 2014-03-15 11:53 UTC (permalink / raw)
To: linux-fbdev
In-Reply-To: <CAAtz+1YfwnSQZMjpA3aKCKG7u1+kXLx+zbQAF6NV3oMsxVd6KQ@mail.gmail.com>
Confirmed. This does not happen with vmalloc. The pointers are in
quite different places in case that's relevant:
kptr = ed460000
vptr = f23d1000
Aside: the reason I'm using kmalloc (or __get_free_pages()) is to have
a physically contiguous buffer for DMA. I currently copy the
framebuffer into a DMA buffer which is less efficient but works (thank
goodness!). I will trace the bug myself when I get time.
Conor.
On Sat, Mar 15, 2014 at 11:29 AM, Conor O <falling174fps@gmail.com> wrote:
> Hello all, I hope this is a reasonable place to post a bug. If I fix
> it I can post a fix too.
>
> I believe there might be a bug in deferred io. In my fb driver I have
> a block of memory, allocated with kmalloc, that I can mmap, write to,
> and munmap perfectly fine using my own mmap routine. As soon as I
> switch to deferred io, there's a problem:
>
> From userspace, I can mmap the framebuffer memory fine and write to
> it. The deferred io driver routine is called and updates the display
> perfectly correctly. As soon as I call munmap() I get a repeated
> kernel messages. This happens on ARM but not under an Ubuntu
> Virtualbox VM (x86):
>
> BUG: Bad page state in process fbtest1 pfn:ad11d
> page:c0dc03a0 count:0 mapcount:0 mapping:edbf7144 index:0x1d
> page flags: 0x94(referenced|dirty|slab)
> Modules linked in: hhlcd28a(O) sysimgblt sysfillrect syscopyarea
> fb_sys_fops bnep ipv6 mwifiex_sdio mwifiex btmrvl_sdio firmware_class
> btmrvl cfg80211 bluetooth rfkill
> [<c0014bc8>] (unwind_backtrace+0x0/0x11c) from [<c00c44d4>] (bad_page+0xd0/0xfc)
> [<c00c44d4>] (bad_page+0xd0/0xfc) from [<c00c45c0>]
> (free_pages_prepare+0xc0/0x150)
> [<c00c45c0>] (free_pages_prepare+0xc0/0x150) from [<c00c5a34>]
> (free_hot_cold_page+0x20/0x188)
> [<c00c5a34>] (free_hot_cold_page+0x20/0x188) from [<c00c5dc4>]
> (free_hot_cold_page_list+0x7c/0x9c)
> [<c00c5dc4>] (free_hot_cold_page_list+0x7c/0x9c) from [<c00c90c0>]
> (release_pages+0x1b4/0x1c8)
> [<c00c90c0>] (release_pages+0x1b4/0x1c8) from [<c00ea854>]
> (free_pages_and_swap_cache+0x8c/0x9c)
> [<c00ea854>] (free_pages_and_swap_cache+0x8c/0x9c) from [<c00dfff4>]
> (unmap_region+0x100/0x154)
> [<c00dfff4>] (unmap_region+0x100/0x154) from [<c00e116c>]
> (do_munmap+0x218/0x2a4)
> [<c00e116c>] (do_munmap+0x218/0x2a4) from [<c00e1234>] (vm_munmap+0x3c/0x50)
> [<c00e1234>] (vm_munmap+0x3c/0x50) from [<c000dc20>] (ret_fast_syscall+0x0/0x30)
>
> [repeated for N pages]
>
> root@duovero:~/testdrv#
>
> I will now convert to using vmalloc and check to see if this happens too.
>
> Thanks,
>
> Conor.
^ permalink raw reply
* Re: Possible bug in deferred io with mmaped memory?
From: David Herrmann @ 2014-03-16 16:25 UTC (permalink / raw)
To: linux-fbdev
In-Reply-To: <CAAtz+1YfwnSQZMjpA3aKCKG7u1+kXLx+zbQAF6NV3oMsxVd6KQ@mail.gmail.com>
Hi
On Sat, Mar 15, 2014 at 12:29 PM, Conor O <falling174fps@gmail.com> wrote:
> Hello all, I hope this is a reasonable place to post a bug. If I fix
> it I can post a fix too.
>
> I believe there might be a bug in deferred io. In my fb driver I have
> a block of memory, allocated with kmalloc, that I can mmap, write to,
> and munmap perfectly fine using my own mmap routine. As soon as I
> switch to deferred io, there's a problem:
>
> From userspace, I can mmap the framebuffer memory fine and write to
> it. The deferred io driver routine is called and updates the display
> perfectly correctly. As soon as I call munmap() I get a repeated
> kernel messages. This happens on ARM but not under an Ubuntu
> Virtualbox VM (x86):
You map kmalloc()ed memory to user-space? How do you guarantee that
it's page-aligned? How do you protect kernel-internal state? This
sounds really odd.
Anyhow, you really need to post a link to the code in question if you
want people to help you.
Thanks
David
^ permalink raw reply
* Re: [PATCH] fbdev: Make the switch from generic to native driver less alarming
From: David Herrmann @ 2014-03-16 16:40 UTC (permalink / raw)
To: linux-fbdev
In-Reply-To: <1345223444-15852-1-git-send-email-ajax@redhat.com>
Hi
CC'ing Tomi.
On Wed, Feb 12, 2014 at 10:02 PM, Adam Jackson <ajax@redhat.com> wrote:
> Calling this "conflicting" just makes people think there's a problem
> when there's not.
>
> Signed-off-by: Adam Jackson <ajax@redhat.com>
> ---
> drivers/video/fbmem.c | 3 +--
> 1 file changed, 1 insertion(+), 2 deletions(-)
>
> diff --git a/drivers/video/fbmem.c b/drivers/video/fbmem.c
> index 7309ac7..b6d5008 100644
> --- a/drivers/video/fbmem.c
> +++ b/drivers/video/fbmem.c
> @@ -1596,8 +1596,7 @@ static int do_remove_conflicting_framebuffers(struct apertures_struct *a,
> (primary && gen_aper && gen_aper->count &&
> gen_aper->ranges[0].base = VGA_FB_PHYS)) {
>
> - printk(KERN_INFO "fb: conflicting fb hw usage "
> - "%s vs %s - removing generic driver\n",
> + printk(KERN_INFO "fb: switching to %s from %s\n",
> name, registered_fb[i]->fix.id);
I like that.
Reviewed-by: David Herrmann <dh.herrmann@gmail.com>
Thanks
David
> ret = do_unregister_framebuffer(registered_fb[i]);
> if (ret)
> --
> 1.8.5.3
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-fbdev" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: Possible bug in deferred io with mmaped memory?
From: Conor O @ 2014-03-16 17:50 UTC (permalink / raw)
To: linux-fbdev
In-Reply-To: <CAAtz+1YfwnSQZMjpA3aKCKG7u1+kXLx+zbQAF6NV3oMsxVd6KQ@mail.gmail.com>
On Sun, Mar 16, 2014 at 4:25 PM, David Herrmann <dh.herrmann@gmail.com> wrote:
> Hi
>
> On Sat, Mar 15, 2014 at 12:29 PM, Conor O <falling174fps@gmail.com> wrote:
>> Hello all, I hope this is a reasonable place to post a bug. If I fix
>> it I can post a fix too.
>>
>> I believe there might be a bug in deferred io. In my fb driver I have
>> a block of memory, allocated with kmalloc, that I can mmap, write to,
>> and munmap perfectly fine using my own mmap routine. As soon as I
>> switch to deferred io, there's a problem:
>>
>> From userspace, I can mmap the framebuffer memory fine and write to
>> it. The deferred io driver routine is called and updates the display
>> perfectly correctly. As soon as I call munmap() I get a repeated
>> kernel messages. This happens on ARM but not under an Ubuntu
>> Virtualbox VM (x86):
>
> You map kmalloc()ed memory to user-space? How do you guarantee that
> it's page-aligned? How do you protect kernel-internal state? This
> sounds really odd.
> Anyhow, you really need to post a link to the code in question if you
> want people to help you.
I was generalising a bit. I could have used __get_free_pages instead
and have the same issue going. In this case, I manually page aligned
the pointer. Yes, that might be considered a touch weird. I thought it
might use less memory than get_free_pages would. I mmap the pointer to
userspace in a similar way to
http://lxr.free-electrons.com/source/drivers/video/vfb.c. I get the
pfn for a particular position in the buffer and remap the range:
bufpfn = virt_to_phys(vpos) >> PAGE_SHIFT;
if (remap_pfn_range(vma, vma->vm_start, bufpfn, vsize, vma->vm_page_prot))
return -EAGAIN;
However, that's really besides the point. Deferred io changes the
.fb_mmap function pointer in the fb_ops structure to point to its own
anyway. My framebuffer driver works fine with vmalloc as it stands so
I'm not in need of assistance. I'm just saying that it all collapses
if I use kmalloc on Arm. I haven't had time to trace the reason but
maybe its unmarking each page instead of a range. I don't know enough
about the virtual memory system to even guess.
^ permalink raw reply
* Re: [PATCH v7][ 3/5] video: mx3fb: Introduce regulator support.
From: Sascha Hauer @ 2014-03-17 6:20 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1394788369-5096-3-git-send-email-denis@eukrea.com>
[Added Mark to Cc]
On Fri, Mar 14, 2014 at 10:12:47AM +0100, Denis Carikli wrote:
>
> + of_property_read_string(display_np, "regulator-name",
> + ®ulator_name);
> +
[...]
> + /* In dt mode,
> + * using devm_regulator_get would require that the proprety referencing
> + * the regulator phandle has to be inside the mx3fb node.
> + */
> + if (np) {
> + if (regulator_name)
> + mx3fbi->reg_lcd = regulator_get(NULL, regulator_name);
> +
> + if (IS_ERR(mx3fbi->reg_lcd))
> + return PTR_ERR(mx3fbi->reg_lcd);
> + } else {
> + /* Permit that driver without a regulator in non-dt mode */
> + mx3fbi->reg_lcd = regulator_get(dev, "lcd");
> + }
This patch adds regulator support for the display of a i.MX3 IPU. The
problem Denis has to solve here is that he needs to get the regulator,
but the display devicenode doesn't have a struct device associated with
it, so he cannot provide one to regulator_get(). One way out here could
be a of_regulator_get(struct device_node *). Mark, would this be ok with
you?
(Of course a proper driver for the display would be nicer, but this
would immediately bring us to some Common display framework, something
which is being worked on quite a while now without success)
Sascha
--
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 v15][ 1/3] video: Kconfig: fbdev: restore the broader selection of FB_IMX
From: Tomi Valkeinen @ 2014-03-17 10:24 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1394794553-14719-1-git-send-email-denis@eukrea.com>
[-- Attachment #1: Type: text/plain, Size: 376 bytes --]
On 14/03/14 12:55, Denis Carikli wrote:
> The following patch:
> b359bb0 video: Kconfig: Allow more broad selection of the imxfb framebuffer driver.
> Was accidentally reverted by this one:
> ed3b5f2 Merge branch '3.15/fb-reorder' into for-next
>
> Signed-off-by: Denis Carikli <denis@eukrea.com>
Thanks. I've fixed it.
It was my merge mistake.
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 901 bytes --]
^ permalink raw reply
* Re: [PATCH v15][ 2/3] video: imxfb: Add DT default contrast control register property.
From: Tomi Valkeinen @ 2014-03-17 10:30 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1394794553-14719-2-git-send-email-denis@eukrea.com>
[-- Attachment #1: Type: text/plain, Size: 740 bytes --]
On 14/03/14 12:55, Denis Carikli wrote:
> Signed-off-by: Denis Carikli <denis@eukrea.com>
> Acked-by: Jean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com>
> Acked-by: Grant Likely <grant.likely@linaro.org>
> ---
> ChangeLog v14->v15:
> - Moved the Cc into git send-email.
> - Rebased.
>
> ChangeLog v5->v14:
> - Remove people not concerned by this patch from the Cc list.
> - Changed the property name to match the register name and function.
> - Updated the documentation, code and commit message accordingly.
> ---
> .../devicetree/bindings/video/fsl,imx-fb.txt | 3 +++
> drivers/video/fbdev/imxfb.c | 3 +++
> 2 files changed, 6 insertions(+)
Queued for 3.15.
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 901 bytes --]
^ permalink raw reply
* Re: [PATCH v2] RFC: framebuffer: provide generic get_fb_unmapped_area
From: Tomi Valkeinen @ 2014-03-17 11:23 UTC (permalink / raw)
To: linux-fbdev
In-Reply-To: <1391447684-22556-1-git-send-email-u.kleine-koenig@pengutronix.de>
[-- Attachment #1: Type: text/plain, Size: 1031 bytes --]
Hi,
On 03/02/14 19:14, Uwe Kleine-König wrote:
> This patch makes mmapping the simple-framebuffer device work on a no-MMU
> ARM target. The code is mostly taken from
> arch/blackfin/kernel/sys_bfin.c.
>
> Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
> ---
> Hello,
>
> note this is only tested on this no-MMU machine and I don't know enough
> about framebuffers and mm to decide if this patch is sane. Also I'm
> a bit unsure about the size check, I just believed Geert that
> PAGE_ALIGN(info->fix.smem_len) is the right value to check against.
I don't know enough about mm to say much here, and the text above make
me feel a bit uneasy. I'd be happy if this would get a few
acks/reviewed-bys/tested-bys...
So what does this patch actually do? If I read things correctly,
currently .get_unmapped_area is null, except for sparc and blackfin. But
userspace's mmap() calls that, right? Is there a default implementation
somewhere? Why is that different for no-MMU case?
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 901 bytes --]
^ permalink raw reply
* Re: [PATCH v2] RFC: framebuffer: provide generic get_fb_unmapped_area
From: David Herrmann @ 2014-03-17 12:15 UTC (permalink / raw)
To: linux-fbdev
In-Reply-To: <1391447684-22556-1-git-send-email-u.kleine-koenig@pengutronix.de>
Hi
On Mon, Feb 3, 2014 at 6:14 PM, Uwe Kleine-König
<u.kleine-koenig@pengutronix.de> wrote:
> This patch makes mmapping the simple-framebuffer device work on a no-MMU
> ARM target. The code is mostly taken from
> arch/blackfin/kernel/sys_bfin.c.
>
> Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
> ---
> Hello,
>
> note this is only tested on this no-MMU machine and I don't know enough
> about framebuffers and mm to decide if this patch is sane. Also I'm
> a bit unsure about the size check, I just believed Geert that
> PAGE_ALIGN(info->fix.smem_len) is the right value to check against.
>
> Best regards
> Uwe
>
> drivers/video/fbmem.c | 20 +++++++++++++++++---
> 1 file changed, 17 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/video/fbmem.c b/drivers/video/fbmem.c
> index 7309ac704e26..d0ccedafec8c 100644
> --- a/drivers/video/fbmem.c
> +++ b/drivers/video/fbmem.c
> @@ -1491,6 +1491,22 @@ __releases(&info->lock)
> return 0;
> }
>
> +#ifdef HAVE_ARCH_FB_UNMAPPED_AREA
> +#define fb_get_unmapped_area get_fb_unmapped_area
> +#else
> +unsigned long fb_get_unmapped_area(struct file *filp, unsigned long orig_addr,
> + unsigned long len, unsigned long pgoff, unsigned long flags)
> +{
> + struct fb_info * const info = filp->private_data;
> + unsigned long fb_size = PAGE_ALIGN(info->fix.smem_len);
> +
> + if (pgoff > fb_size || len > fb_size - pgoff)
> + return -EINVAL;
> +
> + return (unsigned long)info->screen_base + pgoff;
> +}
> +#endif
> +
Doesn't this break mmu systems? x86 for instance has no
get_fb_unmapped_area(), therefore f_ops->get_unmapped_area() is NULL
and thus falls back to the generic handler of the task (see
mm/mmap.c). If you replace this with your handler, _every_ mmap() call
with be treated as MAP_FIXED with "info->screen_base + pgoff" as
address. This might work in test-cases on the first mmap() call, but
any further call will fail.
Thanks
David
> static const struct file_operations fb_fops = {
> .owner = THIS_MODULE,
> .read = fb_read,
> @@ -1502,9 +1518,7 @@ static const struct file_operations fb_fops = {
> .mmap = fb_mmap,
> .open = fb_open,
> .release = fb_release,
> -#ifdef HAVE_ARCH_FB_UNMAPPED_AREA
> - .get_unmapped_area = get_fb_unmapped_area,
> -#endif
> + .get_unmapped_area = fb_get_unmapped_area,
> #ifdef CONFIG_FB_DEFERRED_IO
> .fsync = fb_deferred_io_fsync,
> #endif
> --
> 1.8.5.2
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-fbdev" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH 0/9] Doc/DT: DT bindings for various display components
From: Tomi Valkeinen @ 2014-03-17 13:55 UTC (permalink / raw)
To: Grant Likely
Cc: devicetree, linux-fbdev, Russell King - ARM Linux, Sascha Hauer,
Tomasz Figa, dri-devel, Inki Dae, Andrzej Hajda, Rob Clark,
Thierry Reding, Laurent Pinchart, Philipp Zabel, linux-arm-kernel,
Sebastian Hesselbarth
In-Reply-To: <532017B3.708@ti.com>
[-- Attachment #1: Type: text/plain, Size: 2340 bytes --]
Hi Grant,
Ping.
Are you fine with me proceeding with the current V4L2 port/endpoint
bindings?
Tomi
On 12/03/14 10:15, Tomi Valkeinen wrote:
> Hi Grant,
>
> On 28/02/14 14:20, Tomi Valkeinen wrote:
>> Hi,
>>
>> This series is a re-send of
>> http://article.gmane.org/gmane.linux.drivers.devicetree/61739
>>
>> I'm cc'ing more people, and I want to clarify the contents of the series:
>>
>> While this has been developed for OMAP, only the first patch is about OMAP
>> bindings. The rest are generic bindings for video components, which can be used
>> on any platform.
>>
>> The bindings use the V4L2 style video port/endpoint system, described in
>> Documentation/devicetree/bindings/media/video-interfaces.txt, to connect the
>> components. The same port/endpoint bindings are used by Philipp Zabel in his
>> imx-drm patch series.
>
> This series is a piece of bigger series, which brings DT support for
> OMAP display subsystem. This uses the same V4L2 style ports/endpoints as
> has been discussed recently regarding the series from Philipp. It
> doesn't use the helper code from Philipp, but a custom one as Philipp's
> code didn't exist when I made this, and also because I needed extra
> functionality not present in Philipp's series (which aimed to just move
> the current V4L2 code to a common place).
>
> The main concerns with the ports/endpoints has been the optional 'port'
> node for the case where we have a single endpoint, and the
> double-linking of the endpoints.
>
> If I remove the optional 'port' usage from my series, are you ok with me
> proceeding with this series for 3.15, with the double-linked endpoints?
>
> As far as I see, when we come to a conclusion how the linking should be
> made, it's trivial to change the bindings in this series to match it,
> even without needing any compatibility code. I just need to remove the
> other link, and old dts files having double-linking will still work fine.
>
> The reason I want to push this forward asap is that omap4 and omap5 are
> already DT only, and for omap5 we don't have working display without DT
> support for display. For omap4, we have a really hacky way to add
> display support for a few boards, but that is causing major headaches
> and I want to get rid of it.
>
> Tomi
>
>
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 901 bytes --]
^ permalink raw reply
* Re: [PATCH 5/9] Doc/DT: Add DT binding documentation for MIPI DPI Panel
From: Laurent Pinchart @ 2014-03-17 14:19 UTC (permalink / raw)
To: Tomi Valkeinen
Cc: devicetree, linux-fbdev, Russell King - ARM Linux, dri-devel,
Andrzej Hajda, linux-arm-kernel, Sebastian Hesselbarth
In-Reply-To: <1393590016-9361-6-git-send-email-tomi.valkeinen@ti.com>
Hi Tomi,
Thank you for the patch.
On Friday 28 February 2014 14:20:12 Tomi Valkeinen wrote:
> Add DT binding documentation for MIPI DPI Panel.
>
> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
> Reviewed-by: Archit Taneja <archit@ti.com>
> ---
> .../devicetree/bindings/video/panel-dpi.txt | 43 +++++++++++++++++++
> 1 file changed, 43 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/video/panel-dpi.txt
>
> diff --git a/Documentation/devicetree/bindings/video/panel-dpi.txt
> b/Documentation/devicetree/bindings/video/panel-dpi.txt new file mode
> 100644
> index 000000000000..72636c6f1c67
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/video/panel-dpi.txt
> @@ -0,0 +1,43 @@
> +Generic MIPI DPI Panel
> +===========
> +
> +Required properties:
> +- compatible: "panel-dpi"
> +
> +Optional properties:
> +- label: a symbolic name for the panel
> +- gpios: panel enable gpio and backlight enable gpio
While integrated in the panel module, the backlight is a separate piece of
hardware, which could be controlled through other means (I2C for instance).
Wouldn't it be better to add an explicit DT node for the backlight device and
reference that node from the panel node ?
> +
> +Required nodes:
> +- "panel-timing" containing video timings
> + (Documentation/devicetree/bindings/video/display-timing.txt)
> +- Video port for DPI input
> +
> +Example
> +-------
> +
> +lcd0: display@0 {
> + compatible = "samsung,lte430wq-f0c", "panel-dpi";
> + label = "lcd";
> +
> + lcd_in: endpoint {
> + remote-endpoint = <&dpi_out>;
> + };
> +
> + panel-timing {
> + clock-frequency = <9200000>;
> + hactive = <480>;
> + vactive = <272>;
> + hfront-porch = <8>;
> + hback-porch = <4>;
> + hsync-len = <41>;
> + vback-porch = <2>;
> + vfront-porch = <4>;
> + vsync-len = <10>;
> +
> + hsync-active = <0>;
> + vsync-active = <0>;
> + de-active = <1>;
> + pixelclk-active = <1>;
> + };
> +};
--
Regards,
Laurent Pinchart
^ permalink raw reply
* Re: [PATCH 6/9] Doc/DT: Add DT binding documentation for MIPI DSI CM Panel
From: Laurent Pinchart @ 2014-03-17 14:22 UTC (permalink / raw)
To: Tomi Valkeinen
Cc: devicetree, linux-fbdev, Russell King - ARM Linux, dri-devel,
Andrzej Hajda, linux-arm-kernel, Sebastian Hesselbarth
In-Reply-To: <1393590016-9361-7-git-send-email-tomi.valkeinen@ti.com>
Hi Tomi,
Thank you for the patch.
On Friday 28 February 2014 14:20:13 Tomi Valkeinen wrote:
> Add DT binding documentation for MIPI DSI Command Mode Panel.
>
> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
> Reviewed-by: Archit Taneja <archit@ti.com>
> ---
> .../devicetree/bindings/video/panel-dsi-cm.txt | 26 +++++++++++++++++++
> 1 file changed, 26 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/video/panel-dsi-cm.txt
>
> diff --git a/Documentation/devicetree/bindings/video/panel-dsi-cm.txt
> b/Documentation/devicetree/bindings/video/panel-dsi-cm.txt new file mode
> 100644
> index 000000000000..73f422556d4f
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/video/panel-dsi-cm.txt
> @@ -0,0 +1,26 @@
> +Generic MIPI DSI Command Mode Panel
> +=================> +
> +Required properties:
> +- compatible: "panel-dsi-cm"
> +
> +Optional properties:
> +- label: a symbolic name for the panel
> +- gpios: panel reset gpio and TE gpio
> +
> +Required nodes:
> +- Video port for DSI input
> +
> +Example
> +-------
> +
> +lcd0: display {
> + compatible = "tpo,taal", "panel-dsi-cm";
> + label = "lcd0";
> +
> + gpios = <&gpio4 6 GPIO_ACTIVE_HIGH>; /* 102, reset */
If the panel uses a TE GPIO but no reset GPIO, do you plan to express this
with a "hole" for the reset GPIO ? e.g. something like
gpios = <0>, <&gpio4 6 GPIO_ACTIVE_HIGH>;
Wouldn't it be better to split the gpios property into "reset-gpios" and "te-
gpios" ?
> +
> + lcd0_in: endpoint {
> + remote-endpoint = <&dsi1_out_ep>;
> + };
> +};
--
Regards,
Laurent Pinchart
^ permalink raw reply
* Re: [PATCH 6/9] Doc/DT: Add DT binding documentation for MIPI DSI CM Panel
From: Tomi Valkeinen @ 2014-03-18 6:33 UTC (permalink / raw)
To: Laurent Pinchart
Cc: devicetree, linux-fbdev, Russell King - ARM Linux, Sascha Hauer,
Tomasz Figa, dri-devel, Inki Dae, Andrzej Hajda, Rob Clark,
Thierry Reding, Philipp Zabel, linux-arm-kernel,
Sebastian Hesselbarth
In-Reply-To: <4670830.fkS1noPxcd@avalon>
[-- Attachment #1: Type: text/plain, Size: 885 bytes --]
On 17/03/14 16:22, Laurent Pinchart wrote:
>> +Example
>> +-------
>> +
>> +lcd0: display {
>> + compatible = "tpo,taal", "panel-dsi-cm";
>> + label = "lcd0";
>> +
>> + gpios = <&gpio4 6 GPIO_ACTIVE_HIGH>; /* 102, reset */
>
> If the panel uses a TE GPIO but no reset GPIO, do you plan to express this
> with a "hole" for the reset GPIO ? e.g. something like
>
> gpios = <0>, <&gpio4 6 GPIO_ACTIVE_HIGH>;
Yes.
> Wouldn't it be better to split the gpios property into "reset-gpios" and "te-
> gpios" ?
Yes, I can change it. I don't have a strong preference.
I've gotten similar comments for other bindings also, so I guess the
preferred way is to use named "-gpios" properties for everything except
the case where you really have multiple gpios with the same purpose?
The gpio binding documentation doesn't give much guidance on this.
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 901 bytes --]
^ permalink raw reply
* Re: [PATCH 5/9] Doc/DT: Add DT binding documentation for MIPI DPI Panel
From: Tomi Valkeinen @ 2014-03-18 6:41 UTC (permalink / raw)
To: Laurent Pinchart
Cc: devicetree, linux-fbdev, Russell King - ARM Linux, Sascha Hauer,
Tomasz Figa, dri-devel, Inki Dae, Andrzej Hajda, Rob Clark,
Thierry Reding, Philipp Zabel, linux-arm-kernel,
Sebastian Hesselbarth
In-Reply-To: <3721050.m43feCICLQ@avalon>
[-- Attachment #1: Type: text/plain, Size: 762 bytes --]
On 17/03/14 16:19, Laurent Pinchart wrote:
>> +Generic MIPI DPI Panel
>> +======================
>> +
>> +Required properties:
>> +- compatible: "panel-dpi"
>> +
>> +Optional properties:
>> +- label: a symbolic name for the panel
>> +- gpios: panel enable gpio and backlight enable gpio
>
> While integrated in the panel module, the backlight is a separate piece of
> hardware, which could be controlled through other means (I2C for instance).
> Wouldn't it be better to add an explicit DT node for the backlight device and
> reference that node from the panel node ?
Yes, I agree, but do we have the infrastructure or bindings for that?
Ah, I see we now do have a gpio-backlight driver, but it doesn't have DT
bindings.
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 901 bytes --]
^ permalink raw reply
* Re: [PATCH 5/9] Doc/DT: Add DT binding documentation for MIPI DPI Panel
From: Tomi Valkeinen @ 2014-03-18 7:06 UTC (permalink / raw)
To: Laurent Pinchart
Cc: devicetree, linux-fbdev, Russell King - ARM Linux, Sascha Hauer,
Tomasz Figa, dri-devel, Inki Dae, Andrzej Hajda, Rob Clark,
Thierry Reding, Philipp Zabel, linux-arm-kernel,
Sebastian Hesselbarth
In-Reply-To: <5327EAB3.8080405@ti.com>
[-- Attachment #1: Type: text/plain, Size: 1174 bytes --]
On 18/03/14 08:41, Tomi Valkeinen wrote:
> On 17/03/14 16:19, Laurent Pinchart wrote:
>
>>> +Generic MIPI DPI Panel
>>> +======================
>>> +
>>> +Required properties:
>>> +- compatible: "panel-dpi"
>>> +
>>> +Optional properties:
>>> +- label: a symbolic name for the panel
>>> +- gpios: panel enable gpio and backlight enable gpio
>>
>> While integrated in the panel module, the backlight is a separate piece of
>> hardware, which could be controlled through other means (I2C for instance).
>> Wouldn't it be better to add an explicit DT node for the backlight device and
>> reference that node from the panel node ?
>
> Yes, I agree, but do we have the infrastructure or bindings for that?
>
> Ah, I see we now do have a gpio-backlight driver, but it doesn't have DT
> bindings.
Seems there's a patch from Denis Carikli for this, which will probably
be merged for 3.15.
I realized I don't actually use panel-dpi at the moment in my OMAP DSS
DT series, as I dropped the board changes that used panel-dpi. So I'll
drop panel-dpi bindings from my series, and the backlight for panel-dpi
can then be fixed for 3.16.
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 901 bytes --]
^ permalink raw reply
* [PATCHv2 0/8] Doc/DT: DT bindings for various display components
From: Tomi Valkeinen @ 2014-03-18 8:15 UTC (permalink / raw)
To: linux-fbdev, dri-devel, devicetree, linux-arm-kernel
Cc: Russell King - ARM Linux, Daniel Vetter, Tomi Valkeinen,
Sascha Hauer, Tomasz Figa, Archit Taneja, Inki Dae, Andrzej Hajda,
Rob Clark, Thierry Reding, Geert Uytterhoeven, Laurent Pinchart,
Philipp Zabel, Sebastian Hesselbarth
Hi,
This is v2 of the series adding DT bindings for various display components. The
v1 can be found from [1].
The changes for v2:
* abbreviated endpoint format dropped (nacked)
* MIPI DPI panel dropped (missing backlight handling, delayed to 3.16)
* dvi-connector: add properties for analog/digital/dual-link
* hdmi-connector: add connector type
* split 'gpios' property to named gpios
* use 'clocks' properties for OMAP DSS components
* removed 'simple-bus' from OMAP DSS Core's compatible strings
[1] http://article.gmane.org/gmane.linux.drivers.devicetree/63885
Tomi
Tomi Valkeinen (8):
Doc/DT: Add DT binding documentation for OMAP DSS
Doc/DT: Add DT binding documentation for Analog TV Connector
Doc/DT: Add DT binding documentation for DVI Connector
Doc/DT: Add DT binding documentation for HDMI Connector
Doc/DT: Add DT binding documentation for MIPI DSI CM Panel
Doc/DT: Add DT binding documentation for Sony acx565akm panel
Doc/DT: Add DT binding documentation for TFP410 encoder
Doc/DT: Add DT binding documentation for tpd12s015 encoder
.../bindings/video/analog-tv-connector.txt | 25 +++
.../devicetree/bindings/video/dvi-connector.txt | 35 ++++
.../devicetree/bindings/video/hdmi-connector.txt | 28 +++
.../devicetree/bindings/video/panel-dsi-cm.txt | 29 +++
.../devicetree/bindings/video/sony,acx565akm.txt | 30 +++
.../devicetree/bindings/video/ti,omap-dss.txt | 211 +++++++++++++++++++++
.../devicetree/bindings/video/ti,omap2-dss.txt | 54 ++++++
.../devicetree/bindings/video/ti,omap3-dss.txt | 83 ++++++++
.../devicetree/bindings/video/ti,omap4-dss.txt | 111 +++++++++++
.../devicetree/bindings/video/ti,tfp410.txt | 41 ++++
.../devicetree/bindings/video/ti,tpd12s015.txt | 44 +++++
11 files changed, 691 insertions(+)
create mode 100644 Documentation/devicetree/bindings/video/analog-tv-connector.txt
create mode 100644 Documentation/devicetree/bindings/video/dvi-connector.txt
create mode 100644 Documentation/devicetree/bindings/video/hdmi-connector.txt
create mode 100644 Documentation/devicetree/bindings/video/panel-dsi-cm.txt
create mode 100644 Documentation/devicetree/bindings/video/sony,acx565akm.txt
create mode 100644 Documentation/devicetree/bindings/video/ti,omap-dss.txt
create mode 100644 Documentation/devicetree/bindings/video/ti,omap2-dss.txt
create mode 100644 Documentation/devicetree/bindings/video/ti,omap3-dss.txt
create mode 100644 Documentation/devicetree/bindings/video/ti,omap4-dss.txt
create mode 100644 Documentation/devicetree/bindings/video/ti,tfp410.txt
create mode 100644 Documentation/devicetree/bindings/video/ti,tpd12s015.txt
--
1.8.3.2
^ permalink raw reply
* [PATCHv2 1/8] Doc/DT: Add DT binding documentation for OMAP DSS
From: Tomi Valkeinen @ 2014-03-18 8:15 UTC (permalink / raw)
To: linux-fbdev-u79uwXL29TY76Z2rM5mHXA,
dri-devel-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
Cc: Philipp Zabel, Laurent Pinchart, Russell King - ARM Linux,
Sascha Hauer, Sebastian Hesselbarth, Rob Clark, Inki Dae,
Andrzej Hajda, Tomasz Figa, Thierry Reding, Geert Uytterhoeven,
Rob Herring, Daniel Vetter, Archit Taneja, Tomi Valkeinen
In-Reply-To: <1395130547-18633-1-git-send-email-tomi.valkeinen-l0cyMroinI0@public.gmane.org>
Add device tree bindings for OMAP Display Subsystem for the following
SoCs: OMAP2, OMAP3, OMAP4.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Reviewed-by: Archit Taneja <archit@ti.com>
---
.../devicetree/bindings/video/ti,omap-dss.txt | 211 +++++++++++++++++++++
.../devicetree/bindings/video/ti,omap2-dss.txt | 54 ++++++
.../devicetree/bindings/video/ti,omap3-dss.txt | 83 ++++++++
.../devicetree/bindings/video/ti,omap4-dss.txt | 111 +++++++++++
4 files changed, 459 insertions(+)
create mode 100644 Documentation/devicetree/bindings/video/ti,omap-dss.txt
create mode 100644 Documentation/devicetree/bindings/video/ti,omap2-dss.txt
create mode 100644 Documentation/devicetree/bindings/video/ti,omap3-dss.txt
create mode 100644 Documentation/devicetree/bindings/video/ti,omap4-dss.txt
diff --git a/Documentation/devicetree/bindings/video/ti,omap-dss.txt b/Documentation/devicetree/bindings/video/ti,omap-dss.txt
new file mode 100644
index 000000000000..d5f1a3fe3109
--- /dev/null
+++ b/Documentation/devicetree/bindings/video/ti,omap-dss.txt
@@ -0,0 +1,211 @@
+Texas Instruments OMAP Display Subsystem
+====================
+
+Generic Description
+-------------------
+
+This document is a generic description of the OMAP Display Subsystem bindings.
+Binding details for each OMAP SoC version are described in respective binding
+documentation.
+
+The OMAP Display Subsystem (DSS) hardware consists of DSS Core, DISPC module and
+a number of encoder modules. All DSS versions contain DSS Core and DISPC, but
+the encoder modules vary.
+
+The DSS Core is the parent of the other DSS modules, and manages clock routing,
+integration to the SoC, etc.
+
+DISPC is the display controller, which reads pixels from the memory and outputs
+a RGB pixel stream to encoders.
+
+The encoder modules encode the received RGB pixel stream to a video output like
+HDMI, MIPI DPI, etc.
+
+Video Ports
+-----------
+
+The DSS Core and the encoders have video port outputs. The structure of the
+video ports is described in Documentation/devicetree/bindings/video/video-
+ports.txt, and the properties for the ports and endpoints for each encoder are
+described in the SoC's DSS binding documentation.
+
+The video ports are used to describe the connections to external hardware, like
+panels or external encoders.
+
+Aliases
+-------
+
+The board dts file may define aliases for displays to assign "displayX" style
+name for each display. If no aliases are defined, a semi-random number is used
+for the display.
+
+Example
+-------
+
+A shortened example of the DSS description for OMAP4, with non-relevant parts
+removed, defined in omap4.dtsi:
+
+dss: dss@58000000 {
+ compatible = "ti,omap4-dss";
+ reg = <0x58000000 0x80>;
+ status = "disabled";
+ ti,hwmods = "dss_core";
+ clocks = <&dss_dss_clk>;
+ clock-names = "fck";
+ #address-cells = <1>;
+ #size-cells = <1>;
+ ranges;
+
+ dispc@58001000 {
+ compatible = "ti,omap4-dispc";
+ reg = <0x58001000 0x1000>;
+ interrupts = <GIC_SPI 25 IRQ_TYPE_LEVEL_HIGH>;
+ ti,hwmods = "dss_dispc";
+ clocks = <&dss_dss_clk>;
+ clock-names = "fck";
+ };
+
+ hdmi: encoder@58006000 {
+ compatible = "ti,omap4-hdmi";
+ reg = <0x58006000 0x200>,
+ <0x58006200 0x100>,
+ <0x58006300 0x100>,
+ <0x58006400 0x1000>;
+ reg-names = "wp", "pll", "phy", "core";
+ interrupts = <GIC_SPI 101 IRQ_TYPE_LEVEL_HIGH>;
+ status = "disabled";
+ ti,hwmods = "dss_hdmi";
+ clocks = <&dss_48mhz_clk>, <&dss_sys_clk>;
+ clock-names = "fck", "sys_clk";
+ };
+};
+
+A shortened example of the board description for OMAP4 Panda board, defined in
+omap4-panda.dts.
+
+The Panda board has a DVI and a HDMI connector, and the board contains a TFP410
+chip (MIPI DPI to DVI encoder) and a TPD12S015 chip (HDMI ESD protection & level
+shifter). The video pipelines for the connectors are formed as follows:
+
+DSS Core --(MIPI DPI)--> TFP410 --(DVI)--> DVI Connector
+OMAP HDMI --(HDMI)--> TPD12S015 --(HDMI)--> HDMI Connector
+
+/ {
+ aliases {
+ display0 = &dvi0;
+ display1 = &hdmi0;
+ };
+
+ tfp410: encoder@0 {
+ compatible = "ti,tfp410";
+ gpios = <&gpio1 0 GPIO_ACTIVE_LOW>; /* 0, power-down */
+
+ pinctrl-names = "default";
+ pinctrl-0 = <&tfp410_pins>;
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ reg = <0>;
+
+ tfp410_in: endpoint@0 {
+ remote-endpoint = <&dpi_out>;
+ };
+ };
+
+ port@1 {
+ reg = <1>;
+
+ tfp410_out: endpoint@0 {
+ remote-endpoint = <&dvi_connector_in>;
+ };
+ };
+ };
+ };
+
+ dvi0: connector@0 {
+ compatible = "dvi-connector";
+ label = "dvi";
+
+ i2c-bus = <&i2c3>;
+
+ port {
+ dvi_connector_in: endpoint {
+ remote-endpoint = <&tfp410_out>;
+ };
+ };
+ };
+
+ tpd12s015: encoder@1 {
+ compatible = "ti,tpd12s015";
+
+ pinctrl-names = "default";
+ pinctrl-0 = <&tpd12s015_pins>;
+
+ gpios = <&gpio2 28 GPIO_ACTIVE_HIGH>, /* 60, CT CP HPD */
+ <&gpio2 9 GPIO_ACTIVE_HIGH>, /* 41, LS OE */
+ <&gpio2 31 GPIO_ACTIVE_HIGH>; /* 63, HPD */
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ reg = <0>;
+
+ tpd12s015_in: endpoint@0 {
+ remote-endpoint = <&hdmi_out>;
+ };
+ };
+
+ port@1 {
+ reg = <1>;
+
+ tpd12s015_out: endpoint@0 {
+ remote-endpoint = <&hdmi_connector_in>;
+ };
+ };
+ };
+ };
+
+ hdmi0: connector@1 {
+ compatible = "hdmi-connector";
+ label = "hdmi";
+
+ port {
+ hdmi_connector_in: endpoint {
+ remote-endpoint = <&tpd12s015_out>;
+ };
+ };
+ };
+};
+
+&dss {
+ status = "ok";
+
+ pinctrl-names = "default";
+ pinctrl-0 = <&dss_dpi_pins>;
+
+ port {
+ dpi_out: endpoint {
+ remote-endpoint = <&tfp410_in>;
+ data-lines = <24>;
+ };
+ };
+};
+
+&hdmi {
+ status = "ok";
+ vdda-supply = <&vdac>;
+
+ pinctrl-names = "default";
+ pinctrl-0 = <&dss_hdmi_pins>;
+
+ port {
+ hdmi_out: endpoint {
+ remote-endpoint = <&tpd12s015_in>;
+ };
+ };
+};
diff --git a/Documentation/devicetree/bindings/video/ti,omap2-dss.txt b/Documentation/devicetree/bindings/video/ti,omap2-dss.txt
new file mode 100644
index 000000000000..fa8bb2ed1170
--- /dev/null
+++ b/Documentation/devicetree/bindings/video/ti,omap2-dss.txt
@@ -0,0 +1,54 @@
+Texas Instruments OMAP2 Display Subsystem
+====================+
+See Documentation/devicetree/bindings/video/ti,omap-dss.txt for generic
+description about OMAP Display Subsystem bindings.
+
+DSS Core
+--------
+
+Required properties:
+- compatible: "ti,omap2-dss"
+- reg: address and length of the register space
+- ti,hwmods: "dss_core"
+
+Optional nodes:
+- Video port for DPI output
+
+DPI Endpoint required properties:
+- data-lines: number of lines used
+
+
+DISPC
+-----
+
+Required properties:
+- compatible: "ti,omap2-dispc"
+- reg: address and length of the register space
+- ti,hwmods: "dss_dispc"
+- interrupts: the DISPC interrupt
+
+
+RFBI
+----
+
+Required properties:
+- compatible: "ti,omap2-rfbi"
+- reg: address and length of the register space
+- ti,hwmods: "dss_rfbi"
+
+
+VENC
+----
+
+Required properties:
+- compatible: "ti,omap2-venc"
+- reg: address and length of the register space
+- ti,hwmods: "dss_venc"
+- vdda-supply: power supply for DAC
+
+VENC Endpoint required properties:
+
+Required properties:
+- ti,invert-polarity: invert the polarity of the video signal
+- ti,channels: 1 for composite, 2 for s-video
diff --git a/Documentation/devicetree/bindings/video/ti,omap3-dss.txt b/Documentation/devicetree/bindings/video/ti,omap3-dss.txt
new file mode 100644
index 000000000000..0023fa4b1328
--- /dev/null
+++ b/Documentation/devicetree/bindings/video/ti,omap3-dss.txt
@@ -0,0 +1,83 @@
+Texas Instruments OMAP3 Display Subsystem
+====================+
+See Documentation/devicetree/bindings/video/ti,omap-dss.txt for generic
+description about OMAP Display Subsystem bindings.
+
+DSS Core
+--------
+
+Required properties:
+- compatible: "ti,omap3-dss"
+- reg: address and length of the register space
+- ti,hwmods: "dss_core"
+- clocks: handle to fclk
+- clock-names: "fck"
+
+Optional nodes:
+- Video ports:
+ - Port 0: DPI output
+ - Port 1: SDI output
+
+DPI Endpoint required properties:
+- data-lines: number of lines used
+
+SDI Endpoint required properties:
+- datapairs: number of datapairs used
+
+
+DISPC
+-----
+
+Required properties:
+- compatible: "ti,omap3-dispc"
+- reg: address and length of the register space
+- ti,hwmods: "dss_dispc"
+- interrupts: the DISPC interrupt
+- clocks: handle to fclk
+- clock-names: "fck"
+
+
+RFBI
+----
+
+Required properties:
+- compatible: "ti,omap3-rfbi"
+- reg: address and length of the register space
+- ti,hwmods: "dss_rfbi"
+- clocks: handles to fclk and iclk
+- clock-names: "fck", "ick"
+
+
+VENC
+----
+
+Required properties:
+- compatible: "ti,omap3-venc"
+- reg: address and length of the register space
+- ti,hwmods: "dss_venc"
+- vdda-supply: power supply for DAC
+- clocks: handle to fclk
+- clock-names: "fck"
+
+VENC Endpoint required properties:
+- ti,invert-polarity: invert the polarity of the video signal
+- ti,channels: 1 for composite, 2 for s-video
+
+
+DSI
+---
+
+Required properties:
+- compatible: "ti,omap3-dsi"
+- reg: addresses and lengths of the register spaces for 'proto', 'phy' and 'pll'
+- reg-names: "proto", "phy", "pll"
+- interrupts: the DSI interrupt line
+- ti,hwmods: "dss_dsi1"
+- vdd-supply: power supply for DSI
+- clocks: handles to fclk and pll clock
+- clock-names: "fck", "sys_clk"
+
+DSI Endpoint required properties:
+- lanes: list of pin numbers for the DSI lanes: CLK+, CLK-, DATA0+, DATA0-,
+ DATA1+, DATA1-, ...
diff --git a/Documentation/devicetree/bindings/video/ti,omap4-dss.txt b/Documentation/devicetree/bindings/video/ti,omap4-dss.txt
new file mode 100644
index 000000000000..f85d6fcfa705
--- /dev/null
+++ b/Documentation/devicetree/bindings/video/ti,omap4-dss.txt
@@ -0,0 +1,111 @@
+Texas Instruments OMAP4 Display Subsystem
+====================+
+See Documentation/devicetree/bindings/video/ti,omap-dss.txt for generic
+description about OMAP Display Subsystem bindings.
+
+DSS Core
+--------
+
+Required properties:
+- compatible: "ti,omap4-dss"
+- reg: address and length of the register space
+- ti,hwmods: "dss_core"
+- clocks: handle to fclk
+- clock-names: "fck"
+
+Required nodes:
+- DISPC
+
+Optional nodes:
+- DSS Submodules: RFBI, VENC, DSI, HDMI
+- Video port for DPI output
+
+DPI Endpoint required properties:
+- data-lines: number of lines used
+
+
+DISPC
+-----
+
+Required properties:
+- compatible: "ti,omap4-dispc"
+- reg: address and length of the register space
+- ti,hwmods: "dss_dispc"
+- interrupts: the DISPC interrupt
+- clocks: handle to fclk
+- clock-names: "fck"
+
+
+RFBI
+----
+
+Required properties:
+- compatible: "ti,omap4-rfbi"
+- reg: address and length of the register space
+- ti,hwmods: "dss_rfbi"
+- clocks: handles to fclk and iclk
+- clock-names: "fck", "ick"
+
+Optional nodes:
+- Video port for RFBI output
+- RFBI controlled peripherals
+
+
+VENC
+----
+
+Required properties:
+- compatible: "ti,omap4-venc"
+- reg: address and length of the register space
+- ti,hwmods: "dss_venc"
+- vdda-supply: power supply for DAC
+- clocks: handle to fclk
+- clock-names: "fck"
+
+Optional nodes:
+- Video port for VENC output
+
+VENC Endpoint required properties:
+- ti,invert-polarity: invert the polarity of the video signal
+- ti,channels: 1 for composite, 2 for s-video
+
+
+DSI
+---
+
+Required properties:
+- compatible: "ti,omap4-dsi"
+- reg: addresses and lengths of the register spaces for 'proto', 'phy' and 'pll'
+- reg-names: "proto", "phy", "pll"
+- interrupts: the DSI interrupt line
+- ti,hwmods: "dss_dsi1" or "dss_dsi2"
+- vdd-supply: power supply for DSI
+- clocks: handles to fclk and pll clock
+- clock-names: "fck", "sys_clk"
+
+Optional nodes:
+- Video port for DSI output
+- DSI controlled peripherals
+
+DSI Endpoint required properties:
+- lanes: list of pin numbers for the DSI lanes: CLK+, CLK-, DATA0+, DATA0-,
+ DATA1+, DATA1-, ...
+
+
+HDMI
+----
+
+Required properties:
+- compatible: "ti,omap4-hdmi"
+- reg: addresses and lengths of the register spaces for 'wp', 'pll', 'phy',
+ 'core'
+- reg-names: "wp", "pll", "phy", "core"
+- interrupts: the HDMI interrupt line
+- ti,hwmods: "dss_hdmi"
+- vdda-supply: vdda power supply
+- clocks: handles to fclk and pll clock
+- clock-names: "fck", "sys_clk"
+
+Optional nodes:
+- Video port for HDMI output
--
1.8.3.2
^ permalink raw reply related
* [PATCHv2 2/8] Doc/DT: Add DT binding documentation for Analog TV Connector
From: Tomi Valkeinen @ 2014-03-18 8:15 UTC (permalink / raw)
To: linux-fbdev-u79uwXL29TY76Z2rM5mHXA,
dri-devel-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
Cc: Philipp Zabel, Laurent Pinchart, Russell King - ARM Linux,
Sascha Hauer, Sebastian Hesselbarth, Rob Clark, Inki Dae,
Andrzej Hajda, Tomasz Figa, Thierry Reding, Geert Uytterhoeven,
Rob Herring, Daniel Vetter, Archit Taneja, Tomi Valkeinen
In-Reply-To: <1395130547-18633-1-git-send-email-tomi.valkeinen-l0cyMroinI0@public.gmane.org>
Add DT binding documentation for Analog TV Connector.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Reviewed-by: Archit Taneja <archit@ti.com>
---
.../bindings/video/analog-tv-connector.txt | 25 ++++++++++++++++++++++
1 file changed, 25 insertions(+)
create mode 100644 Documentation/devicetree/bindings/video/analog-tv-connector.txt
diff --git a/Documentation/devicetree/bindings/video/analog-tv-connector.txt b/Documentation/devicetree/bindings/video/analog-tv-connector.txt
new file mode 100644
index 000000000000..0218fcdc1299
--- /dev/null
+++ b/Documentation/devicetree/bindings/video/analog-tv-connector.txt
@@ -0,0 +1,25 @@
+Analog TV Connector
+=========+
+Required properties:
+- compatible: "composite-connector" or "svideo-connector"
+
+Optional properties:
+- label: a symbolic name for the connector
+
+Required nodes:
+- Video port for TV input
+
+Example
+-------
+
+tv: connector {
+ compatible = "composite-connector";
+ label = "tv";
+
+ port {
+ tv_connector_in: endpoint {
+ remote-endpoint = <&venc_out>;
+ };
+ };
+};
--
1.8.3.2
^ permalink raw reply related
* [PATCHv2 3/8] Doc/DT: Add DT binding documentation for DVI Connector
From: Tomi Valkeinen @ 2014-03-18 8:15 UTC (permalink / raw)
To: linux-fbdev-u79uwXL29TY76Z2rM5mHXA,
dri-devel-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
Cc: Philipp Zabel, Laurent Pinchart, Russell King - ARM Linux,
Sascha Hauer, Sebastian Hesselbarth, Rob Clark, Inki Dae,
Andrzej Hajda, Tomasz Figa, Thierry Reding, Geert Uytterhoeven,
Rob Herring, Daniel Vetter, Archit Taneja, Tomi Valkeinen
In-Reply-To: <1395130547-18633-1-git-send-email-tomi.valkeinen-l0cyMroinI0@public.gmane.org>
Add DT binding documentation for DVI Connector.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Reviewed-by: Archit Taneja <archit@ti.com>
---
.../devicetree/bindings/video/dvi-connector.txt | 35 ++++++++++++++++++++++
1 file changed, 35 insertions(+)
create mode 100644 Documentation/devicetree/bindings/video/dvi-connector.txt
diff --git a/Documentation/devicetree/bindings/video/dvi-connector.txt b/Documentation/devicetree/bindings/video/dvi-connector.txt
new file mode 100644
index 000000000000..fc53f7c60bc6
--- /dev/null
+++ b/Documentation/devicetree/bindings/video/dvi-connector.txt
@@ -0,0 +1,35 @@
+DVI Connector
+=======
+
+Required properties:
+- compatible: "dvi-connector"
+
+Optional properties:
+- label: a symbolic name for the connector
+- ddc-i2c-bus: phandle to the i2c bus that is connected to DVI DDC
+- analog: the connector has DVI analog pins
+- digital: the connector has DVI digital pins
+- dual-link: the connector has pins for DVI dual-link
+
+Required nodes:
+- Video port for DVI input
+
+Note: One (or both) of 'analog' or 'digital' must be set.
+
+Example
+-------
+
+dvi0: connector@0 {
+ compatible = "dvi-connector";
+ label = "dvi";
+
+ digital;
+
+ ddc-i2c-bus = <&i2c3>;
+
+ port {
+ dvi_connector_in: endpoint {
+ remote-endpoint = <&tfp410_out>;
+ };
+ };
+};
--
1.8.3.2
^ permalink raw reply related
* [PATCHv2 4/8] Doc/DT: Add DT binding documentation for HDMI Connector
From: Tomi Valkeinen @ 2014-03-18 8:15 UTC (permalink / raw)
To: linux-fbdev-u79uwXL29TY76Z2rM5mHXA,
dri-devel-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
Cc: Philipp Zabel, Laurent Pinchart, Russell King - ARM Linux,
Sascha Hauer, Sebastian Hesselbarth, Rob Clark, Inki Dae,
Andrzej Hajda, Tomasz Figa, Thierry Reding, Geert Uytterhoeven,
Rob Herring, Daniel Vetter, Archit Taneja, Tomi Valkeinen
In-Reply-To: <1395130547-18633-1-git-send-email-tomi.valkeinen-l0cyMroinI0@public.gmane.org>
Add DT binding documentation for HDMI Connector.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Reviewed-by: Archit Taneja <archit@ti.com>
---
.../devicetree/bindings/video/hdmi-connector.txt | 28 ++++++++++++++++++++++
1 file changed, 28 insertions(+)
create mode 100644 Documentation/devicetree/bindings/video/hdmi-connector.txt
diff --git a/Documentation/devicetree/bindings/video/hdmi-connector.txt b/Documentation/devicetree/bindings/video/hdmi-connector.txt
new file mode 100644
index 000000000000..ccccc19e2573
--- /dev/null
+++ b/Documentation/devicetree/bindings/video/hdmi-connector.txt
@@ -0,0 +1,28 @@
+HDMI Connector
+=======
+
+Required properties:
+- compatible: "hdmi-connector"
+- type: the HDMI connector type: "a", "b", "c", "d" or "e"
+
+Optional properties:
+- label: a symbolic name for the connector
+
+Required nodes:
+- Video port for HDMI input
+
+Example
+-------
+
+hdmi0: connector@1 {
+ compatible = "hdmi-connector";
+ label = "hdmi";
+
+ type = "a";
+
+ port {
+ hdmi_connector_in: endpoint {
+ remote-endpoint = <&tpd12s015_out>;
+ };
+ };
+};
--
1.8.3.2
^ permalink raw reply related
* [PATCHv2 5/8] Doc/DT: Add DT binding documentation for MIPI DSI CM Panel
From: Tomi Valkeinen @ 2014-03-18 8:15 UTC (permalink / raw)
To: linux-fbdev-u79uwXL29TY76Z2rM5mHXA,
dri-devel-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
Cc: Philipp Zabel, Laurent Pinchart, Russell King - ARM Linux,
Sascha Hauer, Sebastian Hesselbarth, Rob Clark, Inki Dae,
Andrzej Hajda, Tomasz Figa, Thierry Reding, Geert Uytterhoeven,
Rob Herring, Daniel Vetter, Archit Taneja, Tomi Valkeinen
In-Reply-To: <1395130547-18633-1-git-send-email-tomi.valkeinen-l0cyMroinI0@public.gmane.org>
Add DT binding documentation for MIPI DSI Command Mode Panel.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Reviewed-by: Archit Taneja <archit@ti.com>
---
.../devicetree/bindings/video/panel-dsi-cm.txt | 29 ++++++++++++++++++++++
1 file changed, 29 insertions(+)
create mode 100644 Documentation/devicetree/bindings/video/panel-dsi-cm.txt
diff --git a/Documentation/devicetree/bindings/video/panel-dsi-cm.txt b/Documentation/devicetree/bindings/video/panel-dsi-cm.txt
new file mode 100644
index 000000000000..dce48eb9db57
--- /dev/null
+++ b/Documentation/devicetree/bindings/video/panel-dsi-cm.txt
@@ -0,0 +1,29 @@
+Generic MIPI DSI Command Mode Panel
+=================+
+Required properties:
+- compatible: "panel-dsi-cm"
+
+Optional properties:
+- label: a symbolic name for the panel
+- reset-gpios: panel reset gpio
+- te-gpios: panel TE gpio
+
+Required nodes:
+- Video port for DSI input
+
+Example
+-------
+
+lcd0: display {
+ compatible = "tpo,taal", "panel-dsi-cm";
+ label = "lcd0";
+
+ reset-gpios = <&gpio4 6 GPIO_ACTIVE_HIGH>;
+
+ port {
+ lcd0_in: endpoint {
+ remote-endpoint = <&dsi1_out_ep>;
+ };
+ };
+};
--
1.8.3.2
^ permalink raw reply related
* [PATCHv2 6/8] Doc/DT: Add DT binding documentation for Sony acx565akm panel
From: Tomi Valkeinen @ 2014-03-18 8:15 UTC (permalink / raw)
To: linux-fbdev-u79uwXL29TY76Z2rM5mHXA,
dri-devel-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
Cc: Philipp Zabel, Laurent Pinchart, Russell King - ARM Linux,
Sascha Hauer, Sebastian Hesselbarth, Rob Clark, Inki Dae,
Andrzej Hajda, Tomasz Figa, Thierry Reding, Geert Uytterhoeven,
Rob Herring, Daniel Vetter, Archit Taneja, Tomi Valkeinen
In-Reply-To: <1395130547-18633-1-git-send-email-tomi.valkeinen-l0cyMroinI0@public.gmane.org>
Add DT binding documentation for Sony acx565akm panel
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Reviewed-by: Sebastian Reichel <sre@debian.org>
Reviewed-by: Archit Taneja <archit@ti.com>
---
.../devicetree/bindings/video/sony,acx565akm.txt | 30 ++++++++++++++++++++++
1 file changed, 30 insertions(+)
create mode 100644 Documentation/devicetree/bindings/video/sony,acx565akm.txt
diff --git a/Documentation/devicetree/bindings/video/sony,acx565akm.txt b/Documentation/devicetree/bindings/video/sony,acx565akm.txt
new file mode 100644
index 000000000000..e12333280749
--- /dev/null
+++ b/Documentation/devicetree/bindings/video/sony,acx565akm.txt
@@ -0,0 +1,30 @@
+Sony ACX565AKM SDI Panel
+============
+
+Required properties:
+- compatible: "sony,acx565akm"
+
+Optional properties:
+- label: a symbolic name for the panel
+- reset-gpios: panel reset gpio
+
+Required nodes:
+- Video port for SDI input
+
+Example
+-------
+
+acx565akm@2 {
+ compatible = "sony,acx565akm";
+ spi-max-frequency = <6000000>;
+ reg = <2>;
+
+ label = "lcd";
+ reset-gpios = <&gpio3 26 GPIO_ACTIVE_HIGH>; /* 90 */
+
+ port {
+ lcd_in: endpoint {
+ remote-endpoint = <&sdi_out>;
+ };
+ };
+};
--
1.8.3.2
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox