* RE: [PATCH 1/2] hyperv-fb: add pci stub
From: Haiyang Zhang @ 2013-10-02 20:42 UTC (permalink / raw)
To: Gerd Hoffmann
Cc: KY Srinivasan, Jean-Christophe Plagniol-Villard, Tomi Valkeinen,
open list:Hyper-V CORE AND..., open list:FRAMEBUFFER LAYER,
open list
In-Reply-To: <1380714911-6254-1-git-send-email-kraxel@redhat.com>
> -----Original Message-----
> From: linux-fbdev-owner@vger.kernel.org [mailto:linux-fbdev-
> owner@vger.kernel.org] On Behalf Of Gerd Hoffmann
> Sent: Wednesday, October 2, 2013 7:55 AM
> Cc: Gerd Hoffmann; KY Srinivasan; Haiyang Zhang; Jean-Christophe Plagniol-
> Villard; Tomi Valkeinen; open list:Hyper-V CORE AND...; open
> list:FRAMEBUFFER LAYER; open list
> Subject: [PATCH 1/2] hyperv-fb: add pci stub
>
> This patch adds a pci stub driver to hyper-fb. The hyperv framebuffer driver
> will bind to the pci device then, so linux kernel and userspace know there is a
> proper kernel driver for the device active. lspci shows this for example:
>
> [root@dhcp231 ~]# lspci -vs8
> 00:08.0 VGA compatible controller: Microsoft Corporation Hyper-V virtual
> VGA (prog-if 00 [VGA controller])
> Flags: bus master, fast devsel, latency 0, IRQ 11
> Memory at f8000000 (32-bit, non-prefetchable) [sizedM]
> Expansion ROM at <unassigned> [disabled]
> Kernel driver in use: hyperv_fb
>
> Another effect is that the xorg vesa driver will not attach to the device and
> thus the Xorg server will automatically use the fbdev driver instead.
>
> Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Acked-by: Haiyang Zhang <haiyangz@microsoft.com>
Thank you for fixing this!
- Haiyang
^ permalink raw reply
* Re: [PATCH] amba: Ensure drvdata is NULL
From: Russell King - ARM Linux @ 2013-10-02 20:25 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1b2479137287fa8dfda3089ca0cb9fba8c4b1f1d.1380524337.git.michal.simek@xilinx.com>
On Mon, Sep 30, 2013 at 08:59:06AM +0200, Michal Simek wrote:
> This patch is inpired by the patch for drvdata
> "device-core: Ensure drvdata = NULL when no driver is bound"
> (sha1: 0998d0631001288a5974afc0b2a5f568bcdecb4d)
>
> Also it fixes all occurences in drivers.
>
> Signed-off-by: Michal Simek <michal.simek@xilinx.com>
> ---
> This patch has been sent as RFC in this thread.
> http://lkml.org/lkml/2013/9/4/393
Why not have the driver core do this? Then it gets applied to all bus
types uniformly.
Thanks.
^ permalink raw reply
* [PATCH v3] efifb: prevent null-deref when iterating dmi_list
From: David Herrmann @ 2013-10-02 16:43 UTC (permalink / raw)
To: linux-fbdev
Cc: James Bates, linux-kernel, Tomi Valkeinen,
Jean-Christophe Plagniol-Villard, David Herrmann
In-Reply-To: <1380732056-5387-1-git-send-email-dh.herrmann@gmail.com>
From: James Bates <james.h.bates@gmail.com>
The dmi_list array is initialized using gnu designated initializers, and
therefore may contain fewer explicitly defined entries as there are
elements in it. This is because the enum above with M_xyz constants
contains more items than the designated initializer. Those elements not
explicitly initialized are implicitly set to 0.
Now efifb_setup() loops through all these array elements, and performs
a strcmp on each item. For non explicitly initialized elements this will
be a null pointer:
This patch swaps the check order in the if statement, thus checks first
whether dmi_list[i].base is null.
Signed-off-by: James Bates <james.h.bates@gmail.com>
Signed-off-by: David Herrmann <dh.herrmann@gmail.com>
---
v3: fixes the "Author" field and James' email address
drivers/video/efifb.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/video/efifb.c b/drivers/video/efifb.c
index 7f9ff75..fcb9500 100644
--- a/drivers/video/efifb.c
+++ b/drivers/video/efifb.c
@@ -108,8 +108,8 @@ static int efifb_setup(char *options)
if (!*this_opt) continue;
for (i = 0; i < M_UNKNOWN; i++) {
- if (!strcmp(this_opt, efifb_dmi_list[i].optname) &&
- efifb_dmi_list[i].base != 0) {
+ if (efifb_dmi_list[i].base != 0 &&
+ !strcmp(this_opt, efifb_dmi_list[i].optname)) {
screen_info.lfb_base = efifb_dmi_list[i].base;
screen_info.lfb_linelength = efifb_dmi_list[i].stride;
screen_info.lfb_width = efifb_dmi_list[i].width;
--
1.8.4
^ permalink raw reply related
* [PATCH v2] efifb: prevent null-deref when iterating dmi_list
From: David Herrmann @ 2013-10-02 16:40 UTC (permalink / raw)
To: linux-fbdev
Cc: James Bates, linux-kernel, Tomi Valkeinen,
Jean-Christophe Plagniol-Villard, David Herrmann, James Bates
The dmi_list array is initialized using gnu designated initializers, and
therefore may contain fewer explicitly defined entries as there are
elements in it. This is because the enum above with M_xyz constants
contains more items than the designated initializer. Those elements not
explicitly initialized are implicitly set to 0.
Now efifb_setup() loops through all these array elements, and performs
a strcmp on each item. For non explicitly initialized elements this will
be a null pointer:
This patch swaps the check order in the if statement, thus checks first
whether dmi_list[i].base is null.
Signed-off-by: James Bates <james.h.bates@yahoo.com>
Signed-off-by: David Herrmann <dh.herrmann@gmail.com>
---
Hi
As James didn't respond to the last emails, I just rebased the patch and resent
it. The efi M_xyz constants were moved to x86-sysfb so if anyone wants to remove
unused bits, please send a separate patch to LKML and x86-ML. This patch just
fixes the NULL-deref.
Thanks
David
drivers/video/efifb.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/video/efifb.c b/drivers/video/efifb.c
index 7f9ff75..fcb9500 100644
--- a/drivers/video/efifb.c
+++ b/drivers/video/efifb.c
@@ -108,8 +108,8 @@ static int efifb_setup(char *options)
if (!*this_opt) continue;
for (i = 0; i < M_UNKNOWN; i++) {
- if (!strcmp(this_opt, efifb_dmi_list[i].optname) &&
- efifb_dmi_list[i].base != 0) {
+ if (efifb_dmi_list[i].base != 0 &&
+ !strcmp(this_opt, efifb_dmi_list[i].optname)) {
screen_info.lfb_base = efifb_dmi_list[i].base;
screen_info.lfb_linelength = efifb_dmi_list[i].stride;
screen_info.lfb_width = efifb_dmi_list[i].width;
--
1.8.4
^ permalink raw reply related
* Re: [PATCH 1/2] simplefb: fix unmapping fb during destruction
From: David Herrmann @ 2013-10-02 16:23 UTC (permalink / raw)
To: Stephen Warren
Cc: linux-fbdev@vger.kernel.org, linux-kernel, Tom Gundersen,
Alexandre Courbot, dri-devel@lists.freedesktop.org,
Jean-Christophe Plagniol-Villard, Tomi Valkeinen
In-Reply-To: <524C46E2.5040804@wwwdotorg.org>
Hi
On Wed, Oct 2, 2013 at 6:16 PM, Stephen Warren <swarren@wwwdotorg.org> wrote:
> On 10/02/2013 08:58 AM, David Herrmann wrote:
>> Unfortunately, fbdev does not create its own "struct device" for
>> framebuffers. Instead, it attaches to the device of the parent layer. This
>> has the side-effect that devm_* managed resources are not cleaned up on
>> framebuffer-destruction but rather during destruction of the
>> parent-device. In case of fbdev this might be too late, though.
>> remove_conflicting_framebuffer() may remove fbdev devices but keep the
>> parent device as it is.
>>
>> Therefore, we now use plain ioremap() and unmap the framebuffer in the
>> fb_destroy() callback. Note that we must not free the device here as this
>> might race with the parent-device removal. Instead, we rely on
>> unregister_framebuffer() as barrier and we're safe.
>
> So, once the .fb_destroy callback has been executed, there's no other
> callback to resurrect it? The framebuffer itself is still registered
> until the device's remove, yet after .fb_destroy, the memory is
> unmapped, which would be dangerous if the FB can be re-started.
fbdev lifetime tracking is weird.. ->fb_destroy() is called by
unregister_framebuffer() _after_ it got unlinked. So no, the
framebuffer is gone and cannot be resurrected. However, the
unregistered/dead fbdev object itself stays around until you call
framebuffer_release(). We cannot call it from fb_destroy(), though as
the platform_data in your platform device still points to the fbdev
device. Therefore we keep it and wait for the platform-driver to be
removed which then again calls unregister_framebuffer() (which will
immediately return as the fbdev device is not registered) and then you
can finally call framebuffer_release().
Note that even though there's fb_get_info() and fb_put_info(), both
are not exported and never used. So there is *no* fbdev ref-counting
(which would be horribly broken anyway) and the driver is the sole
owner of the fbdev object.
> If that's not an issue, this patch seems fine, so
> Acked-by: Stephen Warren <swarren@nvidia.com>
Thanks!
>> I know that simplefb was supposed to stay "as simple as possible" but I really
>> think this series is the last set of fixes I have. Unfortunately framebuffer DRM
>> handover is mandatory so we cannot ignore it in simplefb.
>
> I don't think this patch adds any significant complexity, so I'm not
> worried at least.
Good to hear!
Thanks
David
^ permalink raw reply
* Re: [PATCH 1/2] simplefb: fix unmapping fb during destruction
From: Stephen Warren @ 2013-10-02 16:16 UTC (permalink / raw)
To: David Herrmann
Cc: linux-fbdev, linux-kernel, Tom Gundersen, Alexandre Courbot,
dri-devel, Jean-Christophe Plagniol-Villard, Tomi Valkeinen
In-Reply-To: <1380725919-1961-1-git-send-email-dh.herrmann@gmail.com>
On 10/02/2013 08:58 AM, David Herrmann wrote:
> Unfortunately, fbdev does not create its own "struct device" for
> framebuffers. Instead, it attaches to the device of the parent layer. This
> has the side-effect that devm_* managed resources are not cleaned up on
> framebuffer-destruction but rather during destruction of the
> parent-device. In case of fbdev this might be too late, though.
> remove_conflicting_framebuffer() may remove fbdev devices but keep the
> parent device as it is.
>
> Therefore, we now use plain ioremap() and unmap the framebuffer in the
> fb_destroy() callback. Note that we must not free the device here as this
> might race with the parent-device removal. Instead, we rely on
> unregister_framebuffer() as barrier and we're safe.
So, once the .fb_destroy callback has been executed, there's no other
callback to resurrect it? The framebuffer itself is still registered
until the device's remove, yet after .fb_destroy, the memory is
unmapped, which would be dangerous if the FB can be re-started.
If that's not an issue, this patch seems fine, so
Acked-by: Stephen Warren <swarren@nvidia.com>
> I know that simplefb was supposed to stay "as simple as possible" but I really
> think this series is the last set of fixes I have. Unfortunately framebuffer DRM
> handover is mandatory so we cannot ignore it in simplefb.
I don't think this patch adds any significant complexity, so I'm not
worried at least.
^ permalink raw reply
* Re: [BUG] simplefb not showing any output
From: David Herrmann @ 2013-10-02 15:01 UTC (permalink / raw)
To: linux-fbdev
In-Reply-To: <CAG-2HqXhLcRX-oi4JchD=m7tZpDYyePKhWvkFU1ZZPEuqJ2JqQ@mail.gmail.com>
Hi
On Tue, Sep 10, 2013 at 4:34 AM, Stephen Warren <swarren@wwwdotorg.org> wrote:
> On 09/07/2013 06:25 AM, David Herrmann wrote:
>> On Sat, Sep 7, 2013 at 1:47 PM, Tom Gundersen <teg@jklm.no> wrote:
> ...
>>> A related question: is it expected that simplefb should be
>>> significantly slower than efifb, or is that something worth looking
>>> into? My boot with simplefb is roughly five seconds slower than with
>>> efifb. Coincidentally, I notice the same (or similar slowdown) with
>>> inteldrmfb when I see the oops (but not otherwise).
>>
>> That is probably related to the missing write-combine tag in ioremap.
>> Stephen, any objections to this attached patch?
>> Tom, if this solves the speed-issues, I will send it out once I get home.
>>
>> Thanks
>> David
>>
>> (Patch also attached in case of new-lines issues)
>>
>> From dbfb8e12166d494cd60823cbe84134d5d1a73ec8 Mon Sep 17 00:00:00 2001
>> From: David Herrmann <dh.herrmann@gmail.com>
>> Date: Sat, 7 Sep 2013 14:22:01 +0200
>> Subject: [PATCH] devm/simplefb: introduce and use devm_ioremap_wc()
>>
>> We want to use devm_ioremap_nocache() or even devm_ioremap_wc() to speed
>> up fbdev writes _a lot_. As devm_ioremap_wc() doesn't exist, yet,
>> introduce it along the way. Note that ioremap_wc() is aliases to
>> ioremap_nocache() in asm-generic/{io,iomem}.h so we can safely expect all
>> architectures to either provide it or use the same alias.
>
> OK, that works fine on the Raspberry Pi too, so,
> Tested-by: Stephen Warren <swarren@wwwdotorg.org>
Back from the US and all patches sent out. Sorry for the delay. If I
missed something, please let me know.
Thanks for your feedback!
David
^ permalink raw reply
* [PATCH 2/2] simplefb: use write-combined remapping
From: David Herrmann @ 2013-10-02 14:58 UTC (permalink / raw)
To: linux-fbdev
Cc: linux-kernel, Tom Gundersen, Alexandre Courbot, Stephen Warren,
dri-devel, Jean-Christophe Plagniol-Villard, Tomi Valkeinen,
David Herrmann
In-Reply-To: <1380725919-1961-1-git-send-email-dh.herrmann@gmail.com>
Framebuffers shouldn't be cached and it is usually very uncommon to read
them. Therefore, use ioremap_wc() to get significant speed improvements on
systems which provide it. On all other systems it's aliased to
ioremap_nocache() which is also fine.
Reported-by: Tom Gundersen <teg@jklm.no>
Signed-off-by: David Herrmann <dh.herrmann@gmail.com>
Tested-by: Tom Gundersen <teg@jklm.no>
Tested-by: Alexandre Courbot <acourbot@nvidia.com>
Tested-by: Stephen Warren <swarren@wwwdotorg.org>
---
drivers/video/simplefb.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/video/simplefb.c b/drivers/video/simplefb.c
index 74b016c..64db54a 100644
--- a/drivers/video/simplefb.c
+++ b/drivers/video/simplefb.c
@@ -219,8 +219,8 @@ static int simplefb_probe(struct platform_device *pdev)
info->fbops = &simplefb_ops;
info->flags = FBINFO_DEFAULT | FBINFO_MISC_FIRMWARE;
- info->screen_base = ioremap(info->fix.smem_start,
- info->fix.smem_len);
+ info->screen_base = ioremap_wc(info->fix.smem_start,
+ info->fix.smem_len);
if (!info->screen_base) {
framebuffer_release(info);
return -ENODEV;
--
1.8.4
^ permalink raw reply related
* [PATCH 1/2] simplefb: fix unmapping fb during destruction
From: David Herrmann @ 2013-10-02 14:58 UTC (permalink / raw)
To: linux-fbdev
Cc: Stephen Warren, linux-kernel, dri-devel, Tomi Valkeinen,
Alexandre Courbot, Jean-Christophe Plagniol-Villard
Unfortunately, fbdev does not create its own "struct device" for
framebuffers. Instead, it attaches to the device of the parent layer. This
has the side-effect that devm_* managed resources are not cleaned up on
framebuffer-destruction but rather during destruction of the
parent-device. In case of fbdev this might be too late, though.
remove_conflicting_framebuffer() may remove fbdev devices but keep the
parent device as it is.
Therefore, we now use plain ioremap() and unmap the framebuffer in the
fb_destroy() callback. Note that we must not free the device here as this
might race with the parent-device removal. Instead, we rely on
unregister_framebuffer() as barrier and we're safe.
Reported-by: Tom Gundersen <teg@jklm.no>
Signed-off-by: David Herrmann <dh.herrmann@gmail.com>
---
Hi
I know that simplefb was supposed to stay "as simple as possible" but I really
think this series is the last set of fixes I have. Unfortunately framebuffer DRM
handover is mandatory so we cannot ignore it in simplefb.
Both patches are not critical at all and are targeted at 3.13-rc1.
Thanks
David
drivers/video/simplefb.c | 12 ++++++++++--
1 file changed, 10 insertions(+), 2 deletions(-)
diff --git a/drivers/video/simplefb.c b/drivers/video/simplefb.c
index 8d78106..74b016c 100644
--- a/drivers/video/simplefb.c
+++ b/drivers/video/simplefb.c
@@ -66,8 +66,15 @@ static int simplefb_setcolreg(u_int regno, u_int red, u_int green, u_int blue,
return 0;
}
+static void simplefb_destroy(struct fb_info *info)
+{
+ if (info->screen_base)
+ iounmap(info->screen_base);
+}
+
static struct fb_ops simplefb_ops = {
.owner = THIS_MODULE,
+ .fb_destroy = simplefb_destroy,
.fb_setcolreg = simplefb_setcolreg,
.fb_fillrect = cfb_fillrect,
.fb_copyarea = cfb_copyarea,
@@ -212,8 +219,8 @@ static int simplefb_probe(struct platform_device *pdev)
info->fbops = &simplefb_ops;
info->flags = FBINFO_DEFAULT | FBINFO_MISC_FIRMWARE;
- info->screen_base = devm_ioremap(&pdev->dev, info->fix.smem_start,
- info->fix.smem_len);
+ info->screen_base = ioremap(info->fix.smem_start,
+ info->fix.smem_len);
if (!info->screen_base) {
framebuffer_release(info);
return -ENODEV;
@@ -223,6 +230,7 @@ static int simplefb_probe(struct platform_device *pdev)
ret = register_framebuffer(info);
if (ret < 0) {
dev_err(&pdev->dev, "Unable to register simplefb: %d\n", ret);
+ iounmap(info->screen_base);
framebuffer_release(info);
return ret;
}
--
1.8.4
^ permalink raw reply related
* RE: [PATCH 1/2] hyperv-fb: add pci stub
From: KY Srinivasan @ 2013-10-02 14:29 UTC (permalink / raw)
To: Gerd Hoffmann
Cc: Haiyang Zhang, Jean-Christophe Plagniol-Villard, Tomi Valkeinen,
open list:Hyper-V CORE AND..., open list:FRAMEBUFFER LAYER,
open list
In-Reply-To: <1380714911-6254-1-git-send-email-kraxel@redhat.com>
> -----Original Message-----
> From: Gerd Hoffmann [mailto:kraxel@redhat.com]
> Sent: Wednesday, October 02, 2013 4:55 AM
> Cc: Gerd Hoffmann; KY Srinivasan; Haiyang Zhang; Jean-Christophe Plagniol-
> Villard; Tomi Valkeinen; open list:Hyper-V CORE AND...; open list:FRAMEBUFFER
> LAYER; open list
> Subject: [PATCH 1/2] hyperv-fb: add pci stub
>
> This patch adds a pci stub driver to hyper-fb. The hyperv framebuffer
> driver will bind to the pci device then, so linux kernel and userspace
> know there is a proper kernel driver for the device active. lspci shows
> this for example:
>
> [root@dhcp231 ~]# lspci -vs8
> 00:08.0 VGA compatible controller: Microsoft Corporation Hyper-V virtual
> VGA (prog-if 00 [VGA controller])
> Flags: bus master, fast devsel, latency 0, IRQ 11
> Memory at f8000000 (32-bit, non-prefetchable) [sizedM]
> Expansion ROM at <unassigned> [disabled]
> Kernel driver in use: hyperv_fb
>
> Another effect is that the xorg vesa driver will not attach to the
> device and thus the Xorg server will automatically use the fbdev
> driver instead.
>
> Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
> ---
> drivers/video/hyperv_fb.c | 40
> +++++++++++++++++++++++++++++++++++++++-
> 1 file changed, 39 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/video/hyperv_fb.c b/drivers/video/hyperv_fb.c
> index 8ac99b8..8d456dc 100644
> --- a/drivers/video/hyperv_fb.c
> +++ b/drivers/video/hyperv_fb.c
> @@ -795,12 +795,21 @@ static int hvfb_remove(struct hv_device *hdev)
> }
>
>
> +static DEFINE_PCI_DEVICE_TABLE(pci_stub_id_table) = {
> + {
> + .vendor = PCI_VENDOR_ID_MICROSOFT,
> + .device = PCI_DEVICE_ID_HYPERV_VIDEO,
> + },
> + { /* end of list */ }
> +};
> +
> static const struct hv_vmbus_device_id id_table[] = {
> /* Synthetic Video Device GUID */
> {HV_SYNTHVID_GUID},
> {}
> };
>
> +MODULE_DEVICE_TABLE(pci, pci_stub_id_table);
> MODULE_DEVICE_TABLE(vmbus, id_table);
>
> static struct hv_driver hvfb_drv = {
> @@ -810,14 +819,43 @@ static struct hv_driver hvfb_drv = {
> .remove = hvfb_remove,
> };
>
> +static int hvfb_pci_stub_probe(struct pci_dev *pdev,
> + const struct pci_device_id *ent)
> +{
> + return 0;
> +}
> +
> +static void hvfb_pci_stub_remove(struct pci_dev *pdev)
> +{
> +}
> +
> +static struct pci_driver hvfb_pci_stub_driver = {
> + .name = KBUILD_MODNAME,
> + .id_table = pci_stub_id_table,
> + .probe = hvfb_pci_stub_probe,
> + .remove = hvfb_pci_stub_remove,
> +};
>
> static int __init hvfb_drv_init(void)
> {
> - return vmbus_driver_register(&hvfb_drv);
> + int ret;
> +
> + ret = vmbus_driver_register(&hvfb_drv);
> + if (ret != 0)
> + return ret;
> +
> + ret = pci_register_driver(&hvfb_pci_stub_driver);
> + if (ret != 0) {
> + vmbus_driver_unregister(&hvfb_drv);
> + return ret;
> + }
> +
> + return 0;
> }
>
> static void __exit hvfb_drv_exit(void)
> {
> + pci_unregister_driver(&hvfb_pci_stub_driver);
> vmbus_driver_unregister(&hvfb_drv);
> }
>
> --
> 1.8.3.1
Gerd,
Thanks for doing this. This certainly will address some of the issues that are reported. I do have a question though - how would this work if we don't have PCI bus in the guest.
Regards,
K. Y
^ permalink raw reply
* [PATCH 12/26] pvr2fb: Convert pvr2fb_write() to use get_user_pages_fast()
From: Jan Kara @ 2013-10-02 14:27 UTC (permalink / raw)
To: LKML
Cc: linux-mm, Jan Kara, linux-fbdev, Tomi Valkeinen,
Jean-Christophe Plagniol-Villard
In-Reply-To: <1380724087-13927-1-git-send-email-jack@suse.cz>
CC: linux-fbdev@vger.kernel.org
CC: Tomi Valkeinen <tomi.valkeinen@ti.com>
CC: Jean-Christophe Plagniol-Villard <plagnioj@jcrosoft.com>
Signed-off-by: Jan Kara <jack@suse.cz>
---
drivers/video/pvr2fb.c | 6 +-----
1 file changed, 1 insertion(+), 5 deletions(-)
diff --git a/drivers/video/pvr2fb.c b/drivers/video/pvr2fb.c
index df07860563e6..31e1345a88a8 100644
--- a/drivers/video/pvr2fb.c
+++ b/drivers/video/pvr2fb.c
@@ -686,11 +686,7 @@ static ssize_t pvr2fb_write(struct fb_info *info, const char *buf,
if (!pages)
return -ENOMEM;
- down_read(¤t->mm->mmap_sem);
- ret = get_user_pages(current, current->mm, (unsigned long)buf,
- nr_pages, WRITE, 0, pages, NULL);
- up_read(¤t->mm->mmap_sem);
-
+ ret = get_user_pages_fast((unsigned long)buf, nr_pages, WRITE, pages);
if (ret < nr_pages) {
nr_pages = ret;
ret = -EINVAL;
--
1.8.1.4
^ permalink raw reply related
* Re: [PATCH/RFC v3 00/19] Common Display Framework
From: Tomi Valkeinen @ 2013-10-02 13:24 UTC (permalink / raw)
To: Andrzej Hajda
Cc: Laurent Pinchart, linux-fbdev, dri-devel, Jesse Barnes,
Benjamin Gaignard, Tom Gall, Kyungmin Park, linux-media,
Stephen Warren, Mark Zhang, Alexandre Courbot,
Ragesh Radhakrishnan, Thomas Petazzoni, Sunil Joshi,
Maxime Ripard, Vikas Sajjan, Marcus Lorentzon
In-Reply-To: <524C1058.2050500@samsung.com>
[-- Attachment #1: Type: text/plain, Size: 3871 bytes --]
Hi Andrzej,
On 02/10/13 15:23, Andrzej Hajda wrote:
>> Using Linux buses for DBI/DSI
>> =============================
>>
>> I still don't see how it would work. I've covered this multiple times in
>> previous posts so I'm not going into more details now.
>>
>> I implemented DSI (just command mode for now) as a video bus but with bunch of
>> extra ops for sending the control messages.
>
> Could you post the list of ops you have to create.
I'd rather not post the ops I have in my prototype, as it's still a
total hack. However, they are very much based on the current OMAP DSS's
ops, so I'll describe them below. I hope I find time to polish my CDF
hacks more, so that I can publish them.
> I have posted some time ago my implementation of DSI bus:
> http://thread.gmane.org/gmane.linux.drivers.video-input-infrastructure/69358/focus=69362
A note about the DT data on your series, as I've been stuggling to
figure out the DT data for OMAP: some of the DT properties look like
configuration, not hardware description. For example,
"samsung,bta-timeout" doesn't describe hardware.
> I needed three quite generic ops to make it working:
> - set_power(on/off),
> - set_stream(on/off),
> - transfer(dsi_transaction_type, tx_buf, tx_len, rx_buf, rx_len)
> I have recently replaced set_power by PM_RUNTIME callbacks,
> but I had to add .initialize ops.
We have a bit more on omap:
http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/include/video/omapdss.h#n648
Some of those should be removed and some should be omap DSI's internal
matters, not part of the API. But it gives an idea of the ops we use.
Shortly about the ops:
- (dis)connect, which might be similar to your initialize. connect is
meant to "connect" the pipeline, reserving the video ports used, etc.
- enable/disable, enable the DSI bus. If the DSI peripheral requires a
continous DSI clock, it's also started at this point.
- set_config configures the DSI bus (like, command/video mode, etc.).
- configure_pins can be ignored, I think that function is not needed.
- enable_hs and enable_te, used to enable/disable HS mode and
tearing-elimination
- update, which does a single frame transfer
- bus_lock/unlock can be ignored
- enable_video_output starts the video stream, when using DSI video mode
- the request_vc, set_vc_id, release_vc can be ignored
- Bunch of transfer funcs. Perhaps a single func could be used, as you
do. We have sync write funcs, which do a BTA at the end of the write and
wait for reply, and nosync version, which just pushes the packet to the
TX buffers.
- bta_sync, which sends a BTA and waits for the peripheral to reply
- set_max_rx_packet_size, used to configure the max rx packet size.
> Regarding the discussion how and where to implement control bus I have
> though about different alternatives:
> 1. Implement DSI-master as a parent dev which will create DSI-slave
> platform dev in a similar way as for MFD devices (ssbi.c seems to me a
> good example).
> 2. Create universal mipi-display-bus which will cover DSI, DBI and
> possibly other buses - they have have few common things - for example
> MIPI-DCS commands.
>
> I am not really convinced to either solution all have some advantages
> and disadvantages.
I think a dedicated DSI bus and your alternatives all have the same
issues with splitting the DSI control into two. I've shared some of my
thoughts here:
http://article.gmane.org/gmane.comp.video.dri.devel/90651
http://article.gmane.org/gmane.comp.video.dri.devel/91269
http://article.gmane.org/gmane.comp.video.dri.devel/91272
I still think that it's best to consider DSI and DBI as a video bus (not
as a separate video bus and a control bus), and provide the packet
transfer methods as part of the video ops.
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 901 bytes --]
^ permalink raw reply
* Re: [PATCH/RFC v3 00/19] Common Display Framework
From: Andrzej Hajda @ 2013-10-02 12:23 UTC (permalink / raw)
To: Tomi Valkeinen, Laurent Pinchart
Cc: linux-fbdev, dri-devel, Jesse Barnes, Benjamin Gaignard, Tom Gall,
Kyungmin Park, linux-media, Stephen Warren, Mark Zhang,
Alexandre Courbot, Ragesh Radhakrishnan, Thomas Petazzoni,
Sunil Joshi, Maxime Ripard, Vikas Sajjan, Marcus Lorentzon
In-Reply-To: <52498146.4050600@ti.com>
Hi Tomi,
On 09/30/2013 03:48 PM, Tomi Valkeinen wrote:
> On 09/08/13 20:14, Laurent Pinchart wrote:
>> Hi everybody,
>>
>> Here's the third RFC of the Common Display Framework.
>
>
> Hi,
>
> I've been trying to adapt the latest CDF RFC for OMAP. I'm trying to gather
> some notes here about what I've discovered or how I see things. Some of these I
> have mentioned earlier, but I'm trying to collect them here nevertheless.
>
> I do have my branch with working DPI panel, TFP410 encoder, DVI-connector and
> DSI command mode panel drivers, and modifications to make omapdss work with
> CDF. However, it's such a big hack, that I'm not going to post it. I hope I
> will have time to work on it to get something publishable to have something
> more concrete to present. But for the time being I have to move to other tasks
> for a while, so I thought I'd better post some comments when I still remember
> something about this.
>
> Using Linux buses for DBI/DSI
> ==============>
> I still don't see how it would work. I've covered this multiple times in
> previous posts so I'm not going into more details now.
>
> I implemented DSI (just command mode for now) as a video bus but with bunch of
> extra ops for sending the control messages.
Could you post the list of ops you have to create.
I have posted some time ago my implementation of DSI bus:
http://thread.gmane.org/gmane.linux.drivers.video-input-infrastructure/69358/focusi362
I needed three quite generic ops to make it working:
- set_power(on/off),
- set_stream(on/off),
- transfer(dsi_transaction_type, tx_buf, tx_len, rx_buf, rx_len)
I have recently replaced set_power by PM_RUNTIME callbacks,
but I had to add .initialize ops.
Regarding the discussion how and where to implement control bus I have
though about different alternatives:
1. Implement DSI-master as a parent dev which will create DSI-slave
platform dev in a similar way as for MFD devices (ssbi.c seems to me a
good example).
2. Create universal mipi-display-bus which will cover DSI, DBI and
possibly other buses - they have have few common things - for example
MIPI-DCS commands.
I am not really convinced to either solution all have some advantages
and disadvantages.
>
> Call model
> =====
>
> It may be that I just don't get how things are supposed to work with the RFC's
> ops, but I couldn't figure out how to use it in practice. I tried it for a few
> days, but got nowhere, and I then went with the proven model that's used in
> omapdss, where display entities handle calling the ops of the upstream
> entities.
>
> That's not to say the RFC's model doesn't work. I just didn't figure it out.
> And I guess it was more difficult to understand how to use it as the controller
> stuff is not implemented yet.
>
> It would be good to have a bit more complex cases in the RFC, like changing and
> verifying videomodes, fetching them via EDID, etc.
>
> Multiple inputs/outputs
> ===========>
> I think changing the model from single-input & single output to multiple inputs
> and outputs increases the difficulty of the implementation considerably. That's
> not a complaint as such, just an observation. I do think multiple inputs &
> outputs is a good feature. Then again, all the use cases I have only have
> single input/output, so I've been wondering if there's some middle road, in
> which we somehow allow multiple inputs & outputs, but only implement the
> support for single input & output.
>
> I've cut the corners in my tests by just looking at a single enabled input or
> output from an entity, and ignoring the rest (which I don't have in my use
> cases).
>
> Internal connections
> ==========
>
> The model currently only represents connections between entities. With multiple
> inputs & outputs I think it's important to maintain also connections inside the
> entity. Say, we have an entity with two inputs and two outputs. If one output
> is enabled, which one of the inputs needs to be enabled and configured also?
> The current model doesn't give any solution to that.
>
> I haven't implemented this, as in my use cases I have just single inputs and
> outputs, so I can follow the pipeline trivially.
>
> Central entity
> =======
>
> If I understand the RFC correctly, there's a "central" entity that manages all
> other entities connected to it. This central entity would normally be the
> display controller. I don't like this model, as it makes it difficult or
> impossible to manage situations where an entity is connected to two display
> controllers (even if only one of the display controllers would be connected at
> a time). It also makes this one display entity fundamentally different from the
> others, which I don't like.
>
> I think all the display entities should be similar. They would all register
> themselves to the CDF framework, which in turn would be used by somebody. This
> somebody could be the display controller driver, which is more or less how I've
> implemented it.
>
> Media entity/pads
> ========>
> Using media_entity and media_pad fits quite well for CDF, but... It is quite
> cumbersome to use. The constant switching between media_entity and
> display_entity needs quite a lot of code in total, as it has to be done almost
> everywhere.
>
> And somehow I'd really like to combine the entity and port into one struct so
> that it would be possible to just do:
>
> src->ops->foo(src, ...);
>
> instead of
>
> src->ops->foo(src, srcport, ...);
>
> One reason is that the latter is more verbose (not only the call, you also need
> to get srcport from somewhere), but also that as far as the caller is
> concerned, there's no reason to manage the entity and the port as separate
> things. You just want a particular video source/sink to do something, and
> whether that source/sink is port 5 of entity foo is irrelevant.
>
> The callee, of course, needs to check which port is being operated. However,
> if, say, 90% of the display entities have just one input and one output port,
> the port parameter can be ignored for those entities, simplifying the code.
>
> And while media_entity can be embedded into display_entity, media_pad and
> media_link cannot be embedded into anything. This is somewhat vague as I don't
> quite remember what my reason for needing the feature was, but I had some need
> for display_link or display_pad, to add some CDF related entries, which can't
> be done except by modifying the media_link or media_pad themselves.
>
> DT data & platform data
> ===========>
> I think the V4L2 style port/endpoint description in DT data should work well. I
> don't see a need for specifying the remote-endpoint in the upstream entity, but
> then again, it doesn't hurt either.
>
> The description does get pretty verbose, though, but I guess that can't be
> avoided.
>
> Describing similar things in the platform data works fine too. The RFC,
> however, contained somewhat lacking platform data examples which had to be
> extended to work with, for example, multiple instances of the same display
> entity. Also, the RFC relied on the central entity to parse the platform data,
> and in my model each display entity has its own platform data.
>
> Final thoughts
> =======
>
> So many of the comments above are somewhat gut-feelings. I don't have concrete
> evidence that my ideas are better, as I haven't been able to finalize the code
> (well, and the RFC is missing important things like the controller).
>
> I think there are areas where my model and the RFC are similar. I think one
> step would be to identify those parts, and perhaps have those parts as separate
> pieces of code. Say, the DT and platform data parts might be such that we could
> have display-of.c and display-pdata.c, having support code which works for the
> RFC and my model.
>
> This would make it easier to maintain and improve both versions, to see how
> they evolve and what are the pros and cons with both models. But this is just a
> thought, I'm not sure how much such code there would actually be.
>
> Tomi
>
>
>
>
>
> _______________________________________________
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
>
^ permalink raw reply
* [PATCH 2/2] hyperv-fb: add blanking support
From: Gerd Hoffmann @ 2013-10-02 11:55 UTC (permalink / raw)
Cc: Gerd Hoffmann, K. Y. Srinivasan, Haiyang Zhang,
Jean-Christophe Plagniol-Villard, Tomi Valkeinen,
open list:Hyper-V CORE AND..., open list:FRAMEBUFFER LAYER,
open list
In-Reply-To: <1380714911-6254-1-git-send-email-kraxel@redhat.com>
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
---
drivers/video/hyperv_fb.c | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/drivers/video/hyperv_fb.c b/drivers/video/hyperv_fb.c
index 8d456dc..130708f 100644
--- a/drivers/video/hyperv_fb.c
+++ b/drivers/video/hyperv_fb.c
@@ -575,6 +575,10 @@ static int hvfb_setcolreg(unsigned regno, unsigned red, unsigned green,
return 0;
}
+static int hvfb_blank(int blank, struct fb_info *info)
+{
+ return 1; /* get fb_blank to set the colormap to all black */
+}
static struct fb_ops hvfb_ops = {
.owner = THIS_MODULE,
@@ -584,6 +588,7 @@ static struct fb_ops hvfb_ops = {
.fb_fillrect = cfb_fillrect,
.fb_copyarea = cfb_copyarea,
.fb_imageblit = cfb_imageblit,
+ .fb_blank = hvfb_blank,
};
--
1.8.3.1
^ permalink raw reply related
* [PATCH 1/2] hyperv-fb: add pci stub
From: Gerd Hoffmann @ 2013-10-02 11:55 UTC (permalink / raw)
Cc: Gerd Hoffmann, K. Y. Srinivasan, Haiyang Zhang,
Jean-Christophe Plagniol-Villard, Tomi Valkeinen,
open list:Hyper-V CORE AND..., open list:FRAMEBUFFER LAYER,
open list
This patch adds a pci stub driver to hyper-fb. The hyperv framebuffer
driver will bind to the pci device then, so linux kernel and userspace
know there is a proper kernel driver for the device active. lspci shows
this for example:
[root@dhcp231 ~]# lspci -vs8
00:08.0 VGA compatible controller: Microsoft Corporation Hyper-V virtual
VGA (prog-if 00 [VGA controller])
Flags: bus master, fast devsel, latency 0, IRQ 11
Memory at f8000000 (32-bit, non-prefetchable) [sizedM]
Expansion ROM at <unassigned> [disabled]
Kernel driver in use: hyperv_fb
Another effect is that the xorg vesa driver will not attach to the
device and thus the Xorg server will automatically use the fbdev
driver instead.
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
---
drivers/video/hyperv_fb.c | 40 +++++++++++++++++++++++++++++++++++++++-
1 file changed, 39 insertions(+), 1 deletion(-)
diff --git a/drivers/video/hyperv_fb.c b/drivers/video/hyperv_fb.c
index 8ac99b8..8d456dc 100644
--- a/drivers/video/hyperv_fb.c
+++ b/drivers/video/hyperv_fb.c
@@ -795,12 +795,21 @@ static int hvfb_remove(struct hv_device *hdev)
}
+static DEFINE_PCI_DEVICE_TABLE(pci_stub_id_table) = {
+ {
+ .vendor = PCI_VENDOR_ID_MICROSOFT,
+ .device = PCI_DEVICE_ID_HYPERV_VIDEO,
+ },
+ { /* end of list */ }
+};
+
static const struct hv_vmbus_device_id id_table[] = {
/* Synthetic Video Device GUID */
{HV_SYNTHVID_GUID},
{}
};
+MODULE_DEVICE_TABLE(pci, pci_stub_id_table);
MODULE_DEVICE_TABLE(vmbus, id_table);
static struct hv_driver hvfb_drv = {
@@ -810,14 +819,43 @@ static struct hv_driver hvfb_drv = {
.remove = hvfb_remove,
};
+static int hvfb_pci_stub_probe(struct pci_dev *pdev,
+ const struct pci_device_id *ent)
+{
+ return 0;
+}
+
+static void hvfb_pci_stub_remove(struct pci_dev *pdev)
+{
+}
+
+static struct pci_driver hvfb_pci_stub_driver = {
+ .name = KBUILD_MODNAME,
+ .id_table = pci_stub_id_table,
+ .probe = hvfb_pci_stub_probe,
+ .remove = hvfb_pci_stub_remove,
+};
static int __init hvfb_drv_init(void)
{
- return vmbus_driver_register(&hvfb_drv);
+ int ret;
+
+ ret = vmbus_driver_register(&hvfb_drv);
+ if (ret != 0)
+ return ret;
+
+ ret = pci_register_driver(&hvfb_pci_stub_driver);
+ if (ret != 0) {
+ vmbus_driver_unregister(&hvfb_drv);
+ return ret;
+ }
+
+ return 0;
}
static void __exit hvfb_drv_exit(void)
{
+ pci_unregister_driver(&hvfb_pci_stub_driver);
vmbus_driver_unregister(&hvfb_drv);
}
--
1.8.3.1
^ permalink raw reply related
* [PATCH] backlight: lm3630: fix sparse warning.
From: Daniel Jeong @ 2013-10-02 8:39 UTC (permalink / raw)
To: Andrew Morton, Jingoo Han
Cc: fengguang.wu, Johannes Weiner, kbuild-all, linux-fbdev,
linux-kernel, Daniel Jeong
This patch is to fix sparse warning due to mixing different enum type.
Signed-off-by: Daniel Jeong <gshark.jeong@gmail.com>
---
drivers/video/backlight/lm3630a_bl.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/video/backlight/lm3630a_bl.c b/drivers/video/backlight/lm3630a_bl.c
index cf40cc8..1a76235 100644
--- a/drivers/video/backlight/lm3630a_bl.c
+++ b/drivers/video/backlight/lm3630a_bl.c
@@ -90,8 +90,8 @@ static int lm3630a_chip_init(struct lm3630a_chip *pchip)
/* set current B */
rval |= lm3630a_write(pchip, REG_I_B, 0x1F);
/* set control */
- rval |- lm3630a_write(pchip, REG_CTRL, pdata->leda_ctrl | pdata->ledb_ctrl);
+ rval |= lm3630a_update(pchip, REG_CTRL, 0x14, pdata->leda_ctrl);
+ rval |= lm3630a_update(pchip, REG_CTRL, 0x0B, pdata->ledb_ctrl);
usleep_range(1000, 2000);
/* set brightness A and B */
rval |= lm3630a_write(pchip, REG_BRT_A, pdata->leda_init_brt);
--
1.7.9.5
^ permalink raw reply related
* Re: [PATCH v3] simplefb: print some info about the registered fb
From: Tom Gundersen @ 2013-10-01 16:45 UTC (permalink / raw)
To: linux-fbdev@vger.kernel.org
Cc: LKML, tomi.valkeinen, plagnioj, Tom Gundersen, David Herrmann
In-Reply-To: <1378562915-893-1-git-send-email-teg@jklm.no>
On Sat, Sep 7, 2013 at 4:08 PM, Tom Gundersen <teg@jklm.no> wrote:
> This is similar to the output printed by efifb.
>
> Signed-off-by: Tom Gundersen <teg@jklm.no>
> Acked-by: Stephen Warren <swarren@wwwdotorg.org>
> Cc: David Herrmann <dh.herrmann@gmail.com>
> ---
> v2: also print smem_len, as requested by David
> v3: don't cast, as requested by Geert
Jean-Christophe and Tomi,
What's the status of this, did either of you pick it up for 3.12 or 3.13?
Cheers,
Tom
^ permalink raw reply
* Re: [PATCH V5 1/5] ARM: dts: Add MIPI PHY node to exynos4.dtsi
From: Kishon Vijay Abraham I @ 2013-10-01 15:38 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <524B3B04.3000704@gmail.com>
On Wednesday 02 October 2013 02:43 AM, Sylwester Nawrocki wrote:
> On 10/01/2013 07:28 AM, Kishon Vijay Abraham I wrote:
>> On Sunday 29 September 2013 12:57 AM, Sylwester Nawrocki wrote:
>>> > Add PHY provider node for the MIPI CSIS and MIPI DSIM PHYs.
>>> >
>>> > Signed-off-by: Sylwester Nawrocki<s.nawrocki@samsung.com>
>>> > Signed-off-by: Kyungmin Park<kyungmin.park@samsung.com>
>>> > Acked-by: Felipe Balbi<balbi@ti.com>
>>
>> Can this patch be taken through exynos dt tree?
>
> Yes, that makes more sense indeed. Kukjin, would you mind taking
> this patch to your tree ?
FWIW
Acked-by: Kishon Vijay Abraham I <kishon@ti.com>
>
> Thanks,
> Sylwester
^ permalink raw reply
* Re: [PATCH V5 1/5] ARM: dts: Add MIPI PHY node to exynos4.dtsi
From: Sylwester Nawrocki @ 2013-10-01 14:13 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <524A5D68.8080904@ti.com>
On 10/01/2013 07:28 AM, Kishon Vijay Abraham I wrote:
> On Sunday 29 September 2013 12:57 AM, Sylwester Nawrocki wrote:
>> > Add PHY provider node for the MIPI CSIS and MIPI DSIM PHYs.
>> >
>> > Signed-off-by: Sylwester Nawrocki<s.nawrocki@samsung.com>
>> > Signed-off-by: Kyungmin Park<kyungmin.park@samsung.com>
>> > Acked-by: Felipe Balbi<balbi@ti.com>
>
> Can this patch be taken through exynos dt tree?
Yes, that makes more sense indeed. Kukjin, would you mind taking
this patch to your tree ?
Thanks,
Sylwester
^ permalink raw reply
* Re: [PATCH V5 1/5] ARM: dts: Add MIPI PHY node to exynos4.dtsi
From: Kishon Vijay Abraham I @ 2013-10-01 5:40 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1380396467-29278-2-git-send-email-s.nawrocki@samsung.com>
Hi,
On Sunday 29 September 2013 12:57 AM, Sylwester Nawrocki wrote:
> Add PHY provider node for the MIPI CSIS and MIPI DSIM PHYs.
>
> Signed-off-by: Sylwester Nawrocki <s.nawrocki@samsung.com>
> Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com>
> Acked-by: Felipe Balbi <balbi@ti.com>
Can this patch be taken through exynos dt tree?
Thanks
Kishon
> ---
> arch/arm/boot/dts/exynos4.dtsi | 10 ++++++++++
> 1 files changed, 10 insertions(+), 0 deletions(-)
>
> diff --git a/arch/arm/boot/dts/exynos4.dtsi b/arch/arm/boot/dts/exynos4.dtsi
> index caadc02..a73eeb5 100644
> --- a/arch/arm/boot/dts/exynos4.dtsi
> +++ b/arch/arm/boot/dts/exynos4.dtsi
> @@ -49,6 +49,12 @@
> reg = <0x10000000 0x100>;
> };
>
> + mipi_phy: video-phy@10020710 {
> + compatible = "samsung,s5pv210-mipi-video-phy";
> + reg = <0x10020710 8>;
> + #phy-cells = <1>;
> + };
> +
> pd_mfc: mfc-power-domain@10023C40 {
> compatible = "samsung,exynos4210-pd";
> reg = <0x10023C40 0x20>;
> @@ -161,6 +167,8 @@
> clock-names = "csis", "sclk_csis";
> bus-width = <4>;
> samsung,power-domain = <&pd_cam>;
> + phys = <&mipi_phy 0>;
> + phy-names = "csis";
> status = "disabled";
> #address-cells = <1>;
> #size-cells = <0>;
> @@ -174,6 +182,8 @@
> clock-names = "csis", "sclk_csis";
> bus-width = <2>;
> samsung,power-domain = <&pd_cam>;
> + phys = <&mipi_phy 2>;
> + phy-names = "csis";
> status = "disabled";
> #address-cells = <1>;
> #size-cells = <0>;
>
^ permalink raw reply
* Re: [PATCH -next] backlight: lm3630: add missing destroy_workqueue() on error in lm3630a_intr_config
From: Jingoo Han @ 2013-10-01 1:08 UTC (permalink / raw)
To: linux-fbdev
On Friday, September 27, 2013 6:51 PM, Wei Yongjun wrote:
>
> From: Wei Yongjun <yongjun_wei@trendmicro.com.cn>
>
> Add the missing destroy_workqueue() before return from
> lm3630a_intr_config() in the error handling case.
>
> Signed-off-by: Wei Yongjun <yongjun_wei@trendmicro.com.cn>
+cc Andrew Morton, Daniel Jeong
Acked-by: Jingoo Han <jg1.han@samsung.com>
Best regards,
Jingoo Han
> ---
> drivers/video/backlight/lm3630a_bl.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/drivers/video/backlight/lm3630a_bl.c b/drivers/video/backlight/lm3630a_bl.c
> index c63f918..0e5d8d3 100644
> --- a/drivers/video/backlight/lm3630a_bl.c
> +++ b/drivers/video/backlight/lm3630a_bl.c
> @@ -154,6 +154,7 @@ static int lm3630a_intr_config(struct lm3630a_chip *pchip)
> (pchip->irq, NULL, lm3630a_isr_func,
> IRQF_TRIGGER_FALLING | IRQF_ONESHOT, "lm3630a_irq", pchip)) {
> dev_err(pchip->dev, "request threaded irq fail\n");
> + destroy_workqueue(pchip->irqthread);
> return -ENOMEM;
> }
> return rval;
>
> --
^ permalink raw reply
* Re: [PATCH 1/3] video: ssd1307fb: Remove redundant of_match_ptr
From: Maxime Ripard @ 2013-09-30 16:43 UTC (permalink / raw)
To: linux-fbdev
In-Reply-To: <1380530733-9070-1-git-send-email-sachin.kamat@linaro.org>
[-- Attachment #1: Type: text/plain, Size: 482 bytes --]
On Mon, Sep 30, 2013 at 02:15:31PM +0530, Sachin Kamat wrote:
> The data structure of_match_ptr() protects is always compiled in.
> Hence of_match_ptr() is not needed.
>
> Signed-off-by: Sachin Kamat <sachin.kamat@linaro.org>
> Cc: Maxime Ripard <maxime.ripard@free-electrons.com>
Acked-by: Maxime Ripard <maxime.ripard@free-electrons.com>
Thanks!
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* Re: [PATCH 3/3] video: xilinxfb: Simplify error path
From: Michal Simek @ 2013-09-30 12:05 UTC (permalink / raw)
To: Tomi Valkeinen
Cc: Michal Simek, linux-kernel, Jean-Christophe Plagniol-Villard,
linux-fbdev
In-Reply-To: <5236DEBF.7070003@ti.com>
[-- Attachment #1: Type: text/plain, Size: 1513 bytes --]
Hi Tomi,
On 09/16/2013 12:34 PM, Tomi Valkeinen wrote:
> On 16/09/13 13:33, Michal Simek wrote:
>> On 09/16/2013 11:51 AM, Tomi Valkeinen wrote:
>>> On 12/09/13 08:54, Michal Simek wrote:
>>>
>>>> @@ -394,16 +382,12 @@ static int xilinxfb_release(struct device *dev)
>>>> /* Turn off the display */
>>>> xilinx_fb_out32(drvdata, REG_CTRL, 0);
>>>>
>>>> - /* Release the resources, as allocated based on interface */
>>>> - if (drvdata->flags & BUS_ACCESS_FLAG)
>>>> - devm_iounmap(dev, drvdata->regs);
>>>> #ifdef CONFIG_PPC_DCR
>>>> - else
>>>> + /* Release the resources, as allocated based on interface */
>>>> + if (!(drvdata->flags & BUS_ACCESS_FLAG))
>>>> dcr_unmap(drvdata->dcr_host, drvdata->dcr_len);
>>>> #endif
>>>
>>> I might be mistaken, and it's not strictly part of this series, but
>>> shouldn't dcr_unmap be called somewhere else also, if the probe fails?
>>
>> yes. It should.
>
> Do you want me to apply these patches as they are, or do you want to
> improve the series to include the dcr_unmap fix?
Sorry I have missed this email.
Yes please apply it as is. I don't have ppc hw here to be able to test this
change.
Thanks,
Michal
--
Michal Simek, Ing. (M.Eng), OpenPGP -> KeyID: FE3D1F91
w: www.monstr.eu p: +42-0-721842854
Maintainer of Linux kernel - Microblaze cpu - http://www.monstr.eu/fdt/
Maintainer of Linux kernel - Xilinx Zynq ARM architecture
Microblaze U-BOOT custodian and responsible for u-boot arm zynq platform
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 263 bytes --]
^ permalink raw reply
* Re: [PATCH 19/51] DMA-API: media: dt3155v4l: replace dma_set_mask()+dma_set_coherent_mask() with new
From: Hans Verkuil @ 2013-09-30 11:57 UTC (permalink / raw)
To: Russell King
Cc: alsa-devel, b43-dev, devel, devicetree, dri-devel, e1000-devel,
linux-arm-kernel, linux-crypto, linux-doc, linux-fbdev, linux-ide,
linux-media, linux-mmc, linux-nvme, linux-omap, linuxppc-dev,
linux-samsung-soc, linux-scsi, linux-tegra, linux-usb,
linux-wireless, netdev, Solarflare linux maintainers,
uclinux-dist-devel, Mauro Carvalho Chehab, Greg Kroah-Hartman
In-Reply-To: <E1VMm13-0007hO-9l@rmk-PC.arm.linux.org.uk>
On 09/19/2013 11:44 PM, Russell King wrote:
> Replace the following sequence:
>
> dma_set_mask(dev, mask);
> dma_set_coherent_mask(dev, mask);
>
> with a call to the new helper dma_set_mask_and_coherent().
>
> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Acked-by: Hans Verkuil <hans.verkuil@cisco.com>
Regards,
Hans
> ---
> drivers/staging/media/dt3155v4l/dt3155v4l.c | 5 +----
> 1 files changed, 1 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/staging/media/dt3155v4l/dt3155v4l.c b/drivers/staging/media/dt3155v4l/dt3155v4l.c
> index 90d6ac4..081407b 100644
> --- a/drivers/staging/media/dt3155v4l/dt3155v4l.c
> +++ b/drivers/staging/media/dt3155v4l/dt3155v4l.c
> @@ -901,10 +901,7 @@ dt3155_probe(struct pci_dev *pdev, const struct pci_device_id *id)
> int err;
> struct dt3155_priv *pd;
>
> - err = dma_set_mask(&pdev->dev, DMA_BIT_MASK(32));
> - if (err)
> - return -ENODEV;
> - err = dma_set_coherent_mask(&pdev->dev, DMA_BIT_MASK(32));
> + err = dma_set_mask_and_coherent(&pdev->dev, DMA_BIT_MASK(32));
> if (err)
> return -ENODEV;
> pd = kzalloc(sizeof(*pd), GFP_KERNEL);
>
^ permalink raw reply
* [PATCH 3/3] video: wmt_ge_rops: Remove redundant of_match_ptr
From: Sachin Kamat @ 2013-09-30 8:57 UTC (permalink / raw)
To: linux-fbdev
The data structure of_match_ptr() protects is always compiled in.
Hence of_match_ptr() is not needed.
Signed-off-by: Sachin Kamat <sachin.kamat@linaro.org>
Cc: Alexey Charkov <alchark@gmail.com>
---
drivers/video/wmt_ge_rops.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/video/wmt_ge_rops.c b/drivers/video/wmt_ge_rops.c
index 4aaeb18..d4ef841 100644
--- a/drivers/video/wmt_ge_rops.c
+++ b/drivers/video/wmt_ge_rops.c
@@ -169,7 +169,7 @@ static struct platform_driver wmt_ge_rops_driver = {
.driver = {
.owner = THIS_MODULE,
.name = "wmt_ge_rops",
- .of_match_table = of_match_ptr(wmt_dt_ids),
+ .of_match_table = wmt_dt_ids,
},
};
--
1.7.9.5
^ 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