* [RFC 6/6] drm: nouveau: kick out firmware drivers during probe
From: David Herrmann @ 2013-06-24 22:27 UTC (permalink / raw)
To: dri-devel
Cc: linux-kernel, Dave Airlie, linux-fbdev, Stephen Warren,
Olof Johansson, David Herrmann
In-Reply-To: <1372112849-670-1-git-send-email-dh.herrmann@gmail.com>
Use the new DRM infrastructure to kick out firmware drivers before probing
the real driver.
Signed-off-by: David Herrmann <dh.herrmann@gmail.com>
---
drivers/gpu/drm/nouveau/nouveau_drm.c | 29 ++++++++++++++++++++++-------
1 file changed, 22 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/nouveau_drm.c b/drivers/gpu/drm/nouveau/nouveau_drm.c
index 383f4e6..418867f 100644
--- a/drivers/gpu/drm/nouveau/nouveau_drm.c
+++ b/drivers/gpu/drm/nouveau/nouveau_drm.c
@@ -233,13 +233,11 @@ nouveau_accel_init(struct nouveau_drm *drm)
nouveau_bo_move_init(drm);
}
-static int nouveau_drm_probe(struct pci_dev *pdev,
- const struct pci_device_id *pent)
+static int nouveau_kick_out_firmware(struct drm_device *dev)
{
- struct nouveau_device *device;
struct apertures_struct *aper;
bool boot = false;
- int ret;
+ struct pci_dev *pdev = dev->pdev;
/* remove conflicting drivers (vesafb, efifb etc) */
aper = alloc_apertures(3);
@@ -265,8 +263,18 @@ static int nouveau_drm_probe(struct pci_dev *pdev,
#ifdef CONFIG_X86
boot = pdev->resource[PCI_ROM_RESOURCE].flags & IORESOURCE_ROM_SHADOW;
#endif
- remove_conflicting_framebuffers(aper, "nouveaufb", boot);
- kfree(aper);
+
+ drm_kick_out_firmware(aper, boot);
+ dev->apertures = aper;
+ dev->apert_boot = boot;
+ return 0;
+}
+
+static int nouveau_drm_probe(struct pci_dev *pdev,
+ const struct pci_device_id *pent)
+{
+ struct nouveau_device *device;
+ int ret;
ret = nouveau_device_create(pdev, nouveau_name(pdev), pci_name(pdev),
nouveau_config, nouveau_debug, &device);
@@ -294,9 +302,13 @@ nouveau_drm_load(struct drm_device *dev, unsigned long flags)
struct nouveau_drm *drm;
int ret;
- ret = nouveau_cli_create(pdev, "DRM", sizeof(*drm), (void**)&drm);
+ ret = nouveau_kick_out_firmware(dev);
if (ret)
return ret;
+
+ ret = nouveau_cli_create(pdev, "DRM", sizeof(*drm), (void**)&drm);
+ if (ret)
+ goto fail_apert;
lockdep_set_class(&drm->client.mutex, &drm_client_lock_class_key);
dev->dev_private = drm;
@@ -392,6 +404,9 @@ fail_ttm:
nouveau_vga_fini(drm);
fail_device:
nouveau_cli_destroy(&drm->client);
+fail_apert:
+ kfree(dev->apertures);
+ dev->apertures = NULL;
return ret;
}
--
1.8.3.1
^ permalink raw reply related
* Re: [PATCH] build some drivers only when compile-testing
From: Greg Kroah-Hartman @ 2013-06-24 23:42 UTC (permalink / raw)
To: Jiri Slaby
Cc: Jeff Mahoney, jirislaby, linux-kernel, Andrew Morton,
Linus Torvalds, Alexander Shishkin, linux-usb,
Florian Tobias Schandinat, linux-geode, linux-fbdev,
Richard Cochran, netdev, Ben Hutchings, Keller, Jacob E,
Michal Marek, tomi.valkeinen
In-Reply-To: <51C154A0.6080104@suse.cz>
On Wed, Jun 19, 2013 at 08:50:08AM +0200, Jiri Slaby wrote:
> On 06/18/2013 06:04 PM, Greg Kroah-Hartman wrote:
> >> So currently I have what is attached... Comments?
> >
> > Looks good to me, want me to queue it up through my char/misc driver
> > tree for 3.11?
>
> If there are no objections... Whoever picks that up, I would be happy 8-).
I've taken it, without the chipidea portion, through my driver-core
tree.
thanks,
greg k-h
^ permalink raw reply
* Re: [RFC 3/6] drm: add SimpleDRM driver
From: Andy Lutomirski @ 2013-06-25 1:05 UTC (permalink / raw)
To: David Herrmann
Cc: dri-devel, linux-kernel, Dave Airlie, linux-fbdev, Stephen Warren,
Olof Johansson
In-Reply-To: <1372112849-670-4-git-send-email-dh.herrmann@gmail.com>
On 06/24/2013 03:27 PM, David Herrmann wrote:
> + sdrm->fb_map = ioremap(sdrm->fb_base, sdrm->fb_size);
This should probably be ioremap_wc. Otherwise it will be *really* slow
if used in legacy mode and it may cause conflicts with the
pgprot_writecombine mode for mmap.
(Watching boot messages go by on fbcon on efifb was like using an old
2400 baud modem before I made the corresponding change to efifb.)
--Andy
^ permalink raw reply
* Re: [PATCH 01/15] video: bfin: remove unnecessary platform_set_drvdata()
From: Jingoo Han @ 2013-06-25 1:45 UTC (permalink / raw)
To: linux-fbdev
On Saturday, May 11, 2013 9:45 PM, Jingoo Han wrote:
>
> The driver core clears the driver data to NULL after device_release
> or on probe failure, since commit 0998d0631001288a5974afc0b2a5f568bcdecb4d
> (device-core: Ensure drvdata = NULL when no driver is bound).
> Thus, it is not needed to manually clear the device driver data to NULL.
>
> Signed-off-by: Jingoo Han <jg1.han@samsung.com>
Hi,
I will squash everything down into one patch with the ACKs,
and send it again.
Best regards,
Jingoo Han
> ---
> drivers/video/bf54x-lq043fb.c | 1 -
> drivers/video/bfin-lq035q1-fb.c | 2 --
> drivers/video/bfin-t350mcqb-fb.c | 2 --
> 3 files changed, 0 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/video/bf54x-lq043fb.c b/drivers/video/bf54x-lq043fb.c
> index 2726a5b..87f288b 100644
> --- a/drivers/video/bf54x-lq043fb.c
> +++ b/drivers/video/bf54x-lq043fb.c
> @@ -681,7 +681,6 @@ out3:
> out2:
> free_dma(CH_EPPI0);
> out1:
> - platform_set_drvdata(pdev, NULL);
>
> return ret;
> }
> diff --git a/drivers/video/bfin-lq035q1-fb.c b/drivers/video/bfin-lq035q1-fb.c
> index 29d8c04..be65bae 100644
> --- a/drivers/video/bfin-lq035q1-fb.c
> +++ b/drivers/video/bfin-lq035q1-fb.c
> @@ -759,7 +759,6 @@ static int bfin_lq035q1_probe(struct platform_device *pdev)
> out2:
> free_dma(CH_PPI);
> out1:
> - platform_set_drvdata(pdev, NULL);
>
> return ret;
> }
> @@ -788,7 +787,6 @@ static int bfin_lq035q1_remove(struct platform_device *pdev)
> bfin_lq035q1_free_ports(info->disp_info->ppi_mode =
> USE_RGB565_16_BIT_PPI);
>
> - platform_set_drvdata(pdev, NULL);
> framebuffer_release(fbinfo);
>
> dev_info(&pdev->dev, "unregistered LCD driver\n");
> diff --git a/drivers/video/bfin-t350mcqb-fb.c b/drivers/video/bfin-t350mcqb-fb.c
> index d46da01..48c0c4e 100644
> --- a/drivers/video/bfin-t350mcqb-fb.c
> +++ b/drivers/video/bfin-t350mcqb-fb.c
> @@ -578,7 +578,6 @@ out3:
> out2:
> free_dma(CH_PPI);
> out1:
> - platform_set_drvdata(pdev, NULL);
>
> return ret;
> }
> @@ -608,7 +607,6 @@ static int bfin_t350mcqb_remove(struct platform_device *pdev)
>
> bfin_t350mcqb_request_ports(0);
>
> - platform_set_drvdata(pdev, NULL);
> framebuffer_release(fbinfo);
>
> printk(KERN_INFO DRIVER_NAME ": Unregister LCD driver.\n");
> --
> 1.7.2.5
^ permalink raw reply
* [PATCH V2] video: remove unnecessary platform_set_drvdata()
From: Jingoo Han @ 2013-06-25 1:56 UTC (permalink / raw)
To: linux-fbdev
The driver core clears the driver data to NULL after device_release
or on probe failure, since commit 0998d0631001288a5974afc0b2a5f568bcdecb4d
(device-core: Ensure drvdata = NULL when no driver is bound).
Thus, it is not needed to manually clear the device driver data to NULL.
Signed-off-by: Jingoo Han <jg1.han@samsung.com>
Cc: Sylwester Nawrocki <sylvester.nawrocki@gmail.com>
Acked-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Acked-by: Shawn Guo <shawn.guo@linaro.org>
Reviewed-by: H Hartley Sweeten <hsweeten@visionengravers.com>
---
drivers/video/au1100fb.c | 1 -
drivers/video/bf54x-lq043fb.c | 1 -
drivers/video/bfin-lq035q1-fb.c | 2 --
drivers/video/bfin-t350mcqb-fb.c | 2 --
drivers/video/ep93xx-fb.c | 2 --
drivers/video/imxfb.c | 3 ---
drivers/video/jz4740_fb.c | 2 --
drivers/video/mmp/fb/mmpfb.c | 1 -
drivers/video/mmp/hw/mmp_ctrl.c | 1 -
drivers/video/mxsfb.c | 2 --
drivers/video/nuc900fb.c | 1 -
drivers/video/pxa3xx-gcu.c | 2 --
drivers/video/pxafb.c | 1 -
drivers/video/s3c2410fb.c | 2 --
drivers/video/sa1100fb.c | 1 -
drivers/video/sh7760fb.c | 1 -
drivers/video/sh_mipi_dsi.c | 1 -
drivers/video/tmiofb.c | 3 ---
drivers/video/vga16fb.c | 1 -
drivers/video/vt8500lcdfb.c | 1 -
20 files changed, 31 deletions(-)
diff --git a/drivers/video/au1100fb.c b/drivers/video/au1100fb.c
index 700cac0..606a3ba 100644
--- a/drivers/video/au1100fb.c
+++ b/drivers/video/au1100fb.c
@@ -579,7 +579,6 @@ failed:
if (fbdev->info.cmap.len != 0) {
fb_dealloc_cmap(&fbdev->info.cmap);
}
- platform_set_drvdata(dev, NULL);
return -ENODEV;
}
diff --git a/drivers/video/bf54x-lq043fb.c b/drivers/video/bf54x-lq043fb.c
index 2726a5b..87f288b 100644
--- a/drivers/video/bf54x-lq043fb.c
+++ b/drivers/video/bf54x-lq043fb.c
@@ -681,7 +681,6 @@ out3:
out2:
free_dma(CH_EPPI0);
out1:
- platform_set_drvdata(pdev, NULL);
return ret;
}
diff --git a/drivers/video/bfin-lq035q1-fb.c b/drivers/video/bfin-lq035q1-fb.c
index 29d8c04..be65bae 100644
--- a/drivers/video/bfin-lq035q1-fb.c
+++ b/drivers/video/bfin-lq035q1-fb.c
@@ -759,7 +759,6 @@ static int bfin_lq035q1_probe(struct platform_device *pdev)
out2:
free_dma(CH_PPI);
out1:
- platform_set_drvdata(pdev, NULL);
return ret;
}
@@ -788,7 +787,6 @@ static int bfin_lq035q1_remove(struct platform_device *pdev)
bfin_lq035q1_free_ports(info->disp_info->ppi_mode =
USE_RGB565_16_BIT_PPI);
- platform_set_drvdata(pdev, NULL);
framebuffer_release(fbinfo);
dev_info(&pdev->dev, "unregistered LCD driver\n");
diff --git a/drivers/video/bfin-t350mcqb-fb.c b/drivers/video/bfin-t350mcqb-fb.c
index d46da01..48c0c4e 100644
--- a/drivers/video/bfin-t350mcqb-fb.c
+++ b/drivers/video/bfin-t350mcqb-fb.c
@@ -578,7 +578,6 @@ out3:
out2:
free_dma(CH_PPI);
out1:
- platform_set_drvdata(pdev, NULL);
return ret;
}
@@ -608,7 +607,6 @@ static int bfin_t350mcqb_remove(struct platform_device *pdev)
bfin_t350mcqb_request_ports(0);
- platform_set_drvdata(pdev, NULL);
framebuffer_release(fbinfo);
printk(KERN_INFO DRIVER_NAME ": Unregister LCD driver.\n");
diff --git a/drivers/video/ep93xx-fb.c b/drivers/video/ep93xx-fb.c
index ee1ee54..28a837d 100644
--- a/drivers/video/ep93xx-fb.c
+++ b/drivers/video/ep93xx-fb.c
@@ -595,7 +595,6 @@ failed_videomem:
fb_dealloc_cmap(&info->cmap);
failed_cmap:
kfree(info);
- platform_set_drvdata(pdev, NULL);
return err;
}
@@ -614,7 +613,6 @@ static int ep93xxfb_remove(struct platform_device *pdev)
fbi->mach_info->teardown(pdev);
kfree(info);
- platform_set_drvdata(pdev, NULL);
return 0;
}
diff --git a/drivers/video/imxfb.c b/drivers/video/imxfb.c
index 0a16d82..12af22b 100644
--- a/drivers/video/imxfb.c
+++ b/drivers/video/imxfb.c
@@ -923,7 +923,6 @@ failed_getclock:
failed_req:
kfree(info->pseudo_palette);
failed_init:
- platform_set_drvdata(pdev, NULL);
framebuffer_release(info);
return ret;
}
@@ -955,8 +954,6 @@ static int imxfb_remove(struct platform_device *pdev)
iounmap(fbi->regs);
release_mem_region(res->start, resource_size(res));
- platform_set_drvdata(pdev, NULL);
-
return 0;
}
diff --git a/drivers/video/jz4740_fb.c b/drivers/video/jz4740_fb.c
index 36979b4..2c49112 100644
--- a/drivers/video/jz4740_fb.c
+++ b/drivers/video/jz4740_fb.c
@@ -737,8 +737,6 @@ static int jzfb_remove(struct platform_device *pdev)
fb_dealloc_cmap(&jzfb->fb->cmap);
jzfb_free_devmem(jzfb);
- platform_set_drvdata(pdev, NULL);
-
framebuffer_release(jzfb->fb);
return 0;
diff --git a/drivers/video/mmp/fb/mmpfb.c b/drivers/video/mmp/fb/mmpfb.c
index 6d1fa96..4ab95b8 100644
--- a/drivers/video/mmp/fb/mmpfb.c
+++ b/drivers/video/mmp/fb/mmpfb.c
@@ -659,7 +659,6 @@ failed_destroy_mutex:
mutex_destroy(&fbi->access_ok);
failed:
dev_err(fbi->dev, "mmp-fb: frame buffer device init failed\n");
- platform_set_drvdata(pdev, NULL);
framebuffer_release(info);
diff --git a/drivers/video/mmp/hw/mmp_ctrl.c b/drivers/video/mmp/hw/mmp_ctrl.c
index 4bd31b2..c46bf5a 100644
--- a/drivers/video/mmp/hw/mmp_ctrl.c
+++ b/drivers/video/mmp/hw/mmp_ctrl.c
@@ -566,7 +566,6 @@ failed:
devm_kfree(ctrl->dev, ctrl);
}
- platform_set_drvdata(pdev, NULL);
dev_err(&pdev->dev, "device init failed\n");
return ret;
diff --git a/drivers/video/mxsfb.c b/drivers/video/mxsfb.c
index 21223d4..10210a0 100644
--- a/drivers/video/mxsfb.c
+++ b/drivers/video/mxsfb.c
@@ -986,8 +986,6 @@ static int mxsfb_remove(struct platform_device *pdev)
framebuffer_release(fb_info);
- platform_set_drvdata(pdev, NULL);
-
return 0;
}
diff --git a/drivers/video/nuc900fb.c b/drivers/video/nuc900fb.c
index 32581c7..8c527e5 100644
--- a/drivers/video/nuc900fb.c
+++ b/drivers/video/nuc900fb.c
@@ -707,7 +707,6 @@ static int nuc900fb_remove(struct platform_device *pdev)
release_resource(fbi->mem);
kfree(fbi->mem);
- platform_set_drvdata(pdev, NULL);
framebuffer_release(fbinfo);
return 0;
diff --git a/drivers/video/pxa3xx-gcu.c b/drivers/video/pxa3xx-gcu.c
index 97563c5..95c3c4ae 100644
--- a/drivers/video/pxa3xx-gcu.c
+++ b/drivers/video/pxa3xx-gcu.c
@@ -711,7 +711,6 @@ err_misc_deregister:
misc_deregister(&priv->misc_dev);
err_free_priv:
- platform_set_drvdata(dev, NULL);
free_buffers(dev, priv);
kfree(priv);
return ret;
@@ -729,7 +728,6 @@ static int pxa3xx_gcu_remove(struct platform_device *dev)
priv->shared, priv->shared_phys);
iounmap(priv->mmio_base);
release_mem_region(r->start, resource_size(r));
- platform_set_drvdata(dev, NULL);
clk_disable(priv->clk);
free_buffers(dev, priv);
kfree(priv);
diff --git a/drivers/video/pxafb.c b/drivers/video/pxafb.c
index 580f80c..eca2de4 100644
--- a/drivers/video/pxafb.c
+++ b/drivers/video/pxafb.c
@@ -2256,7 +2256,6 @@ failed_free_res:
release_mem_region(r->start, resource_size(r));
failed_fbi:
clk_put(fbi->clk);
- platform_set_drvdata(dev, NULL);
kfree(fbi);
failed:
return ret;
diff --git a/drivers/video/s3c2410fb.c b/drivers/video/s3c2410fb.c
index 76a0e7f..21a32ad 100644
--- a/drivers/video/s3c2410fb.c
+++ b/drivers/video/s3c2410fb.c
@@ -1005,7 +1005,6 @@ release_regs:
release_mem:
release_mem_region(res->start, size);
dealloc_fb:
- platform_set_drvdata(pdev, NULL);
framebuffer_release(fbinfo);
return ret;
}
@@ -1051,7 +1050,6 @@ static int s3c2410fb_remove(struct platform_device *pdev)
release_mem_region(info->mem->start, resource_size(info->mem));
- platform_set_drvdata(pdev, NULL);
framebuffer_release(fbinfo);
return 0;
diff --git a/drivers/video/sa1100fb.c b/drivers/video/sa1100fb.c
index f34c858..de76da0 100644
--- a/drivers/video/sa1100fb.c
+++ b/drivers/video/sa1100fb.c
@@ -1271,7 +1271,6 @@ static int sa1100fb_probe(struct platform_device *pdev)
failed:
if (fbi)
iounmap(fbi->base);
- platform_set_drvdata(pdev, NULL);
kfree(fbi);
release_mem_region(res->start, resource_size(res));
return ret;
diff --git a/drivers/video/sh7760fb.c b/drivers/video/sh7760fb.c
index 5fbb0c7..a8c6c43 100644
--- a/drivers/video/sh7760fb.c
+++ b/drivers/video/sh7760fb.c
@@ -571,7 +571,6 @@ static int sh7760fb_remove(struct platform_device *dev)
iounmap(par->base);
release_mem_region(par->ioarea->start, resource_size(par->ioarea));
framebuffer_release(info);
- platform_set_drvdata(dev, NULL);
return 0;
}
diff --git a/drivers/video/sh_mipi_dsi.c b/drivers/video/sh_mipi_dsi.c
index 6cad530..8f6e8ff 100644
--- a/drivers/video/sh_mipi_dsi.c
+++ b/drivers/video/sh_mipi_dsi.c
@@ -567,7 +567,6 @@ static int sh_mipi_remove(struct platform_device *pdev)
iounmap(mipi->base);
if (res)
release_mem_region(res->start, resource_size(res));
- platform_set_drvdata(pdev, NULL);
kfree(mipi);
return 0;
diff --git a/drivers/video/tmiofb.c b/drivers/video/tmiofb.c
index dc4fb86..deb8733 100644
--- a/drivers/video/tmiofb.c
+++ b/drivers/video/tmiofb.c
@@ -794,7 +794,6 @@ err_hw_init:
cell->disable(dev);
err_enable:
err_find_mode:
- platform_set_drvdata(dev, NULL);
free_irq(irq, info);
err_request_irq:
iounmap(info->screen_base);
@@ -823,8 +822,6 @@ static int tmiofb_remove(struct platform_device *dev)
if (cell->disable)
cell->disable(dev);
- platform_set_drvdata(dev, NULL);
-
free_irq(irq, info);
iounmap(info->screen_base);
diff --git a/drivers/video/vga16fb.c b/drivers/video/vga16fb.c
index 545faec..830ded4 100644
--- a/drivers/video/vga16fb.c
+++ b/drivers/video/vga16fb.c
@@ -1269,7 +1269,6 @@ static void vga16fb_destroy(struct fb_info *info)
iounmap(info->screen_base);
fb_dealloc_cmap(&info->cmap);
/* XXX unshare VGA regions */
- platform_set_drvdata(dev, NULL);
framebuffer_release(info);
}
diff --git a/drivers/video/vt8500lcdfb.c b/drivers/video/vt8500lcdfb.c
index 9547e18..897484903 100644
--- a/drivers/video/vt8500lcdfb.c
+++ b/drivers/video/vt8500lcdfb.c
@@ -448,7 +448,6 @@ failed_free_io:
failed_free_res:
release_mem_region(res->start, resource_size(res));
failed_fbi:
- platform_set_drvdata(pdev, NULL);
kfree(fbi);
failed:
return ret;
--
1.7.10.4
^ permalink raw reply related
* Re: [V2 1/7] video: mmp: rb swap setting update for new LCD driver
From: jett zhou @ 2013-06-25 2:23 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAMLZHHQxMAM1Vhj9Jreq5rAN-nmBEbEyoKMwFnL0tVHsKv4U=g@mail.gmail.com>
2013/6/24 Daniel Drake <dsd@laptop.org>:
> On Mon, Jun 24, 2013 at 2:45 AM, jett zhou <jett.zhou@gmail.com> wrote:
>> Sorry that the comments of the patch is not so clear.
>> As you might know,We can set two rbswap setting, one is based on
>> pix_fmt to set into DMA input part, the other is to configured in the output
>> interface part.
>> This patch include below change and enhancement:
>> 1) The input format which support rbswap is based RGB format, YUV
>> series did not support now. So you can see the patch will change the rbswap
>> value based on specific RGB format,eg. RGB will set rbswap = 1, BGR will not
>> set it.
>
> What if I'm working with a display that doesn't need or want RB
> swapping? Lets say I am working with format PIXFMT_RGB565, and running
> your patch. dmafetch_set_fmt() gets called, and fmt_to_reg() sets
> rbswap to 1.
> This means that dmafetch_set_fmt() writes a '1' into the appropriate
> RB-swapping bit in the LCD_PN_CTRL0 register, and this triggers the
> "DMA input" swapping that you mentioned. But I never asked for RB
> swapping...
Yes, if you configure it as PIXFMT_RGB565, it will set rbswap in "DMA
input" part.
So, for your case, you need to use PIXFMT_BGR565 instead of PIXFMT_RGB565.
>
>> This part setting is controlled in driver internally, will not
>> depend on platform configure(link_config) any more.
>
> Your patch seems to depend very clearly on link_config.
Based on the patch, it does not depend on link_config for the "DMA
input" swapping, it depend on the configured pix_format.
>
>> 2) The output part of rbswap is depend on link_config which is
>> defined in specific platfrom.
>> It will setting bit27:24 of 0x01DC register, eg. DSI output
>> interface can be controlled by this.
>
> I don't think you should add more disorganised/undocumented (ab)use of
> this magic link_config variable. You should create new, dedicated,
> documented fields.
Agree with you, create new,dedicated field for this usage is better, I
will amend the patch and send out for review again.:)
>
> Your comment above suggests that this RB-swapping behaviour is
> something that is imposed by the output device. In which case, this
> should be a configuration parameter on the panel, not on the path
> structure.
>
>> TTC_dkb does not support dsi, the link_config is no used anymore.
>
> Then you should fix up ttc_dkb before submitting this patch.
After we add one new field for this output rbswap setting based on dsi
interface, it can be used by new stepping of mmp display controller,
ttc_dkb platform just leave and not touch it, it will be tranparent
for ttc_dkb, does not need to nothing for platform configuration for
ttc_dkb usage.
It means , ttc_dkb can only configure rbswap in "dma input" part, not
support rbswap in dsi interface part.
What do you think?
Thanks
--
----------------------------------
Best Regards
Jett Zhou
^ permalink raw reply
* Re: [V2 5/7] video: mmp: add pitch info in mmp_win structure
From: jett zhou @ 2013-06-25 3:10 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAMLZHHTzR4WffVdw2nWVP6c0_jBb1vW=mOR3RrQudjUNu5Hupg@mail.gmail.com>
2013/6/25 Daniel Drake <dsd@laptop.org>:
> On Mon, Jun 24, 2013 at 4:34 AM, jett zhou <jett.zhou@gmail.com> wrote:
>> pitch is used to represent line length in byte, the usage depends
>> on pix_fmt.
>> If the fmt is YUV , the pitch[0] will be Y length, pitch[1] will
>> be U length, pitch[2] will be V lenth.
>> If the fmt is RGB, the picth[0] will be line lenth, and
>> pitch[1]/pitch[2] will be 0 and not be used.
>
> This description is clear, thanks - hopefully you can write it with
> such clarity in the comment :)
>
>> For the patch rolling, do you mean combine the patch5 and patch6
>> by one patch?
>
> I view patch 6 as a cleanup (consolidating and removing duplication of
> code), so I would leave that one separate. Patch 6 should not interact
> with any pitch[] stuff.
>
> Then you can write a followup patch which adds the pitch[] header,
> *and* modifies mmpfb_set_par() to write to pitch[], *and* acts upon
> pitch[] in dmafetch_set_fmt (patch 7). This way, the pitch variable is
> defined, documented, written to, and acted upon all in the same patch,
> the meaning will then be very clear.
>
HI Daniel
Thanks for your comments.
I will add more detail description on the comments.
For patch6, I will seperated it. For another patch, I will combine
pitch header and mmpfb_set_par and dmafetch_set_fmt (patch 7) as one
new patch based on patch6.
Will send for your review later.
Thanks
--
----------------------------------
Best Regards
Jett Zhou
^ permalink raw reply
* [PATCH v2 4/4] at91/avr32/atmel_lcdfb: prepare clk before calling enable
From: Boris BREZILLON @ 2013-06-25 8:14 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1372147702-4074-1-git-send-email-b.brezillon@overkiz.com>
Replace clk_enable/disable with clk_prepare_enable/disable_unprepare to
avoid common clk framework warnings.
Signed-off-by: Boris BREZILLON <b.brezillon@overkiz.com>
---
drivers/video/atmel_lcdfb.c | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/video/atmel_lcdfb.c b/drivers/video/atmel_lcdfb.c
index 540909d..8525457 100644
--- a/drivers/video/atmel_lcdfb.c
+++ b/drivers/video/atmel_lcdfb.c
@@ -893,14 +893,14 @@ static int __init atmel_lcdfb_init_fbinfo(struct atmel_lcdfb_info *sinfo)
static void atmel_lcdfb_start_clock(struct atmel_lcdfb_info *sinfo)
{
- clk_enable(sinfo->bus_clk);
- clk_enable(sinfo->lcdc_clk);
+ clk_prepare_enable(sinfo->bus_clk);
+ clk_prepare_enable(sinfo->lcdc_clk);
}
static void atmel_lcdfb_stop_clock(struct atmel_lcdfb_info *sinfo)
{
- clk_disable(sinfo->bus_clk);
- clk_disable(sinfo->lcdc_clk);
+ clk_disable_unprepare(sinfo->bus_clk);
+ clk_disable_unprepare(sinfo->lcdc_clk);
}
--
1.7.9.5
^ permalink raw reply related
* Re: [PATCH v2 4/4] at91/avr32/atmel_lcdfb: prepare clk before calling enable
From: Nicolas Ferre @ 2013-06-25 8:16 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1372148053-4477-1-git-send-email-b.brezillon@overkiz.com>
On 25/06/2013 10:14, Boris BREZILLON :
> Replace clk_enable/disable with clk_prepare_enable/disable_unprepare to
> avoid common clk framework warnings.
>
> Signed-off-by: Boris BREZILLON <b.brezillon@overkiz.com>
Acked-by: Nicolas Ferre <nicolas.ferre@atmel.com>
Jean-Christophe, can you take this one?
Thanks, best regards,
> ---
> drivers/video/atmel_lcdfb.c | 8 ++++----
> 1 file changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/video/atmel_lcdfb.c b/drivers/video/atmel_lcdfb.c
> index 540909d..8525457 100644
> --- a/drivers/video/atmel_lcdfb.c
> +++ b/drivers/video/atmel_lcdfb.c
> @@ -893,14 +893,14 @@ static int __init atmel_lcdfb_init_fbinfo(struct atmel_lcdfb_info *sinfo)
>
> static void atmel_lcdfb_start_clock(struct atmel_lcdfb_info *sinfo)
> {
> - clk_enable(sinfo->bus_clk);
> - clk_enable(sinfo->lcdc_clk);
> + clk_prepare_enable(sinfo->bus_clk);
> + clk_prepare_enable(sinfo->lcdc_clk);
> }
>
> static void atmel_lcdfb_stop_clock(struct atmel_lcdfb_info *sinfo)
> {
> - clk_disable(sinfo->bus_clk);
> - clk_disable(sinfo->lcdc_clk);
> + clk_disable_unprepare(sinfo->bus_clk);
> + clk_disable_unprepare(sinfo->lcdc_clk);
> }
>
>
>
--
Nicolas Ferre
^ permalink raw reply
* Re: [PATCH] build some drivers only when compile-testing
From: Jiri Slaby @ 2013-06-25 8:16 UTC (permalink / raw)
To: Greg Kroah-Hartman
Cc: Jeff Mahoney, jirislaby, linux-kernel, Andrew Morton,
Linus Torvalds, Alexander Shishkin, linux-usb,
Florian Tobias Schandinat, linux-geode, linux-fbdev,
Richard Cochran, netdev, Ben Hutchings, Keller, Jacob E,
Michal Marek, tomi.valkeinen
In-Reply-To: <20130624234240.GA21064@kroah.com>
On 06/25/2013 01:42 AM, Greg Kroah-Hartman wrote:
> On Wed, Jun 19, 2013 at 08:50:08AM +0200, Jiri Slaby wrote:
>> On 06/18/2013 06:04 PM, Greg Kroah-Hartman wrote:
>>>> So currently I have what is attached... Comments?
>>>
>>> Looks good to me, want me to queue it up through my char/misc driver
>>> tree for 3.11?
>>
>> If there are no objections... Whoever picks that up, I would be happy 8-).
>
> I've taken it, without the chipidea portion, through my driver-core
> tree.
Ok thanks. (FWIW I sent v3 without the chipidea change too...)
--
js
suse labs
^ permalink raw reply
* Re: [RFC PATCH v2] dmabuf-sync: Introduce buffer synchronization framework
From: Daniel Vetter @ 2013-06-25 9:23 UTC (permalink / raw)
To: Russell King - ARM Linux
Cc: Inki Dae, Maarten Lankhorst, linux-fbdev, Kyungmin Park,
DRI mailing list, Rob Clark, myungjoo.ham, YoungJun Cho,
linux-arm-kernel@lists.infradead.org, linux-media@vger.kernel.org
In-Reply-To: <20130618104613.GX2718@n2100.arm.linux.org.uk>
On Tue, Jun 18, 2013 at 12:46 PM, Russell King - ARM Linux
<linux@arm.linux.org.uk> wrote:
>> > Note: the existing stuff does have the nice side effect of being able
>> > to pass buffers which do not have a struct page * associated with them
>> > through the dma_buf API - I think we can still preserve that by having
>> > dma_buf provide a couple of new APIs to do the SG list map/sync/unmap,
>> > but in any case we need to fix the existing API so that:
>> >
>> > dma_buf_map_attachment() becomes dma_buf_get_sg()
>> > dma_buf_unmap_attachment() becomes dma_buf_put_sg()
>> >
>> > both getting rid of the DMA direction argument, and then we have four
>> > new dma_buf calls:
>> >
>> > dma_buf_map_sg()
>> > dma_buf_unmap_sg()
>> > dma_buf_sync_sg_for_cpu()
>> > dma_buf_sync_sg_for_device()
>> >
>> > which do the actual sg map/unmap via the DMA API *at the appropriate
>> > time for DMA*.
>>
>> Hm, my idea was to just add a dma_buf_sync_attchment for the device side
>> syncing, since the cpu access stuff is already bracketed with the
>> begin/end cpu access stuff. We might need a sync_for_cpu or so for mmap,
>> but imo mmap support for dma_buf is a bit insane anyway, so I don't care
>> too much about it.
>>
>> Since such dma mappings would be really longstanding in most cases anyway
>> drivers could just map with BIDIRECTIONAL and do all the real flushing
>> with the new sync stuff.
>
> Note that the DMA API debug doesn't allow you to change the direction
> argument on an existing mapping (neither should it, again this is
> documented in the DMA API stuff in Documentation/). This is where you
> would need the complete set of four functions I mention above which
> reflect the functionality of the DMA API.
[Been travelling a bit, hence the delay.]
Just a quick question on your assertion that we need all four
functions: Since we already have begin/end_cpu_access functions
(intention here was to allow the dma_buf exporter to ensure the memory
is pinned, e.g. for swapable gem objects, but also allow cpu cache
flushing if required) do we still need the sync_sg_for_cpu? At least
with i915 as the exporter we currently hide the cflushing behind our
begin_cpu_access callback. For device dma we currently punt on it due
to lack of the dma_buf_sync_sg_for_device interface.
Aside: I know that i915 doing the clflushing dance itself is a bit
ugly, but thus far we've been the only guys on the x86 block with
non-coherent dma. But it sounds like a bunch of other blocks on Atom
SoCs have similar needs, so I guess it would make sense to move that
into the dma layer.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
^ permalink raw reply
* Re: [RFC PATCH] dmabuf-sync: Introduce buffer synchronization framework
From: Rob Clark @ 2013-06-25 11:32 UTC (permalink / raw)
To: Inki Dae
Cc: Jerome Glisse, linux-fbdev, Russell King - ARM Linux,
DRI mailing list, Kyungmin Park, myungjoo.ham, YoungJun Cho,
linux-media@vger.kernel.org, linux-arm-kernel@lists.infradead.org
In-Reply-To: <CAAQKjZNnJRddACHzD+VF=A8vJpt9SEy2ttnS3Kw0y3hexu8dnw@mail.gmail.com>
On Tue, Jun 25, 2013 at 5:09 AM, Inki Dae <daeinki@gmail.com> wrote:
>> that
>> should be the role of kernel memory management which of course needs
>> synchronization btw A and B. But in no case this should be done using
>> dma-buf. dma-buf is for sharing content btw different devices not
>> sharing resources.
>>
>
> hmm, is that true? And are you sure? Then how do you think about
> reservation? the reservation also uses dma-buf with same reason as long as I
> know: actually, we use reservation to use dma-buf. As you may know, a
> reservation object is allocated and initialized when a buffer object is
> exported to a dma buf.
no, this is why the reservation object can be passed in when you
construction the dmabuf. The fallback is for dmabuf to create it's
own, for compatibility and to make life easier for simple devices with
few buffers... but I think pretty much all drm drivers would embed the
reservation object in the gem buffer and pass it in when the dmabuf is
created.
It is pretty much imperative that synchronization works independently
of dmabuf, you really don't want to have two different cases to deal
with in your driver, one for synchronizing non-exported objects, and
one for synchronizing dmabuf objects.
BR,
-R
^ permalink raw reply
* Re: [PATCH 3/9] aty128fb: use pdev->pm_cap instead of pci_find_capability(..,PCI_CAP_ID_PM)
From: Yijing Wang @ 2013-06-25 12:06 UTC (permalink / raw)
To: Jean-Christophe Plagniol-Villard
Cc: Yijing Wang, Paul Mackerras, Tomi Valkeinen, linux-kernel,
linux-fbdev
In-Reply-To: <1371543307-14360-1-git-send-email-wangyijing@huawei.com>
Ping.....?
On 2013/6/18 16:15, Yijing Wang wrote:
> Pci core has been saved pm cap register offset by pdev->pm_cap in pci_pm_init()
> in init path. So we can use pdev->pm_cap instead of using
> pci_find_capability(pdev, PCI_CAP_ID_PM) for better performance and simplified code.
>
> Signed-off-by: Yijing Wang <wangyijing@huawei.com>
> Cc: Paul Mackerras <paulus@samba.org>
> Cc: Jean-Christophe Plagniol-Villard <plagnioj@jcrosoft.com>
> Cc: Tomi Valkeinen <tomi.valkeinen@ti.com>
> Cc: linux-fbdev@vger.kernel.org
> ---
> drivers/video/aty/aty128fb.c | 2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/drivers/video/aty/aty128fb.c b/drivers/video/aty/aty128fb.c
> index 8c55011..a4dfe8c 100644
> --- a/drivers/video/aty/aty128fb.c
> +++ b/drivers/video/aty/aty128fb.c
> @@ -2016,7 +2016,7 @@ static int aty128_init(struct pci_dev *pdev, const struct pci_device_id *ent)
>
> aty128_init_engine(par);
>
> - par->pm_reg = pci_find_capability(pdev, PCI_CAP_ID_PM);
> + par->pm_reg = pdev->pm_cap;
> par->pdev = pdev;
> par->asleep = 0;
> par->lock_blank = 0;
>
--
Thanks!
Yijing
^ permalink raw reply
* Re: [PATCH 9/9] radeon: use pdev->pm_cap instead of pci_find_capability(..,PCI_CAP_ID_PM)
From: Yijing Wang @ 2013-06-25 12:06 UTC (permalink / raw)
To: Jean-Christophe Plagniol-Villard
Cc: Yijing Wang, Benjamin Herrenschmidt, Tomi Valkeinen, linux-kernel,
linux-fbdev
In-Reply-To: <1371543891-11460-1-git-send-email-wangyijing@huawei.com>
Ping....?
On 2013/6/18 16:24, Yijing Wang wrote:
> Pci core has been saved pm cap register offset by pdev->pm_cap in pci_pm_init()
> in init path. So we can use pdev->pm_cap instead of using
> pci_find_capability(pdev, PCI_CAP_ID_PM) for better performance and simplified code.
>
> Signed-off-by: Yijing Wang <wangyijing@huawei.com>
> Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
> Cc: Jean-Christophe Plagniol-Villard <plagnioj@jcrosoft.com>
> Cc: Tomi Valkeinen <tomi.valkeinen@ti.com>
> Cc: linux-fbdev@vger.kernel.org
> Cc: linux-kernel@vger.kernel.org
> ---
> drivers/video/aty/radeon_pm.c | 2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/drivers/video/aty/radeon_pm.c b/drivers/video/aty/radeon_pm.c
> index 92bda58..f7091ec 100644
> --- a/drivers/video/aty/radeon_pm.c
> +++ b/drivers/video/aty/radeon_pm.c
> @@ -2805,7 +2805,7 @@ static void radeonfb_early_resume(void *data)
> void radeonfb_pm_init(struct radeonfb_info *rinfo, int dynclk, int ignore_devlist, int force_sleep)
> {
> /* Find PM registers in config space if any*/
> - rinfo->pm_reg = pci_find_capability(rinfo->pdev, PCI_CAP_ID_PM);
> + rinfo->pm_reg = rinfo->pdev->pm_cap;
>
> /* Enable/Disable dynamic clocks: TODO add sysfs access */
> if (rinfo->family = CHIP_FAMILY_RS480)
>
--
Thanks!
Yijing
^ permalink raw reply
* Re: [PATCH 1/2] fb: backlight: HX8357: Make IM pins optionnal
From: Maxime Ripard @ 2013-06-25 13:50 UTC (permalink / raw)
To: Jean-Christophe PLAGNIOL-VILLARD
Cc: Alexandre Belloni, linux-fbdev, jimwall, brian, linux-kernel,
Richard Purdie, Florian Tobias Schandinat
In-Reply-To: <20130624142645.GG305@game.jcrosoft.org>
[-- Attachment #1: Type: text/plain, Size: 1894 bytes --]
Hi Jean Christophe,
On Mon, Jun 24, 2013 at 04:26:45PM +0200, Jean-Christophe PLAGNIOL-VILLARD wrote:
> On 20:27 Fri 21 Jun , Alexandre Belloni wrote:
> > From: Maxime Ripard <maxime.ripard@free-electrons.com>
> >
> > Signed-off-by: Alexandre Belloni <alexandre.belloni@free-electrons.com>
> > Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
> > ---
> > drivers/video/backlight/hx8357.c | 53 +++++++++++++++++++++++-----------------
> > 1 file changed, 31 insertions(+), 22 deletions(-)
> >
> > diff --git a/drivers/video/backlight/hx8357.c b/drivers/video/backlight/hx8357.c
> > index a0482b5..69f5672 100644
> > --- a/drivers/video/backlight/hx8357.c
> > +++ b/drivers/video/backlight/hx8357.c
> > @@ -76,6 +76,7 @@ struct hx8357_data {
> > unsigned reset;
> > struct spi_device *spi;
> > int state;
> > + u8 use_im_pins;
> boolean please
Ok.
> > };
> >
> > static u8 hx8357_seq_power[] = {
> > @@ -250,9 +251,11 @@ static int hx8357_lcd_init(struct lcd_device *lcdev)
> > * Set the interface selection pins to SPI mode, with three
> > * wires
> > */
> > - gpio_set_value_cansleep(lcd->im_pins[0], 1);
> > - gpio_set_value_cansleep(lcd->im_pins[1], 0);
> > - gpio_set_value_cansleep(lcd->im_pins[2], 1);
> > + if (lcd->use_im_pins) {
> > + gpio_set_value_cansleep(lcd->im_pins[0], 1);
> > + gpio_set_value_cansleep(lcd->im_pins[1], 0);
> > + gpio_set_value_cansleep(lcd->im_pins[2], 1);
> > + }
>
> base on the dt probe you may have gpios betwee 0 to HX8357_NUM_IM_PINS
>
> so this look wrong
How so?
HX8357_NUM_IM_PINS is defined to 3, the probe checks to see if we
actually have HX8357_NUM_IM_PINS, otherwise returns an error, what is
wrong in setting these pins here?
--
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
* [PATCH v2 0/5] Generic PHY driver for the Exynos SoC MIPI CSI-2/DSI DPHYs
From: Sylwester Nawrocki @ 2013-06-25 14:15 UTC (permalink / raw)
To: linux-arm-kernel
This patch series adds a simple driver for the Samsung S5P/Exynos SoC
series MIPI CSI-2 receiver (MIPI DSIM) and MIPI DSI transmitter (MIPI
DSIM) DPHYs, using the generic PHY framework [1]. Previously the MIPI
CSIS and MIPI DSIM used a platform callback to control the PHY power
enable and reset bits. The platform callback can be dropped now and
those drivers don't depend any more on any platform code.
Changes since v1:
- enabled build as module and with CONFIG_OF disabled,
- added phy_id enum,
- of_address_to_resource() replaced with platform_get_resource(),
- adapted to changes in the PHY API v7, v8 - added phy labels,
- added MODULE_DEVICE_TABLE() entry,
- the driver file renamed to phy-exynos-mipi-video.c,
- changed DT compatible string to "samsung,s5pv210-mipi-video-phy",
- corrected the compatible property's description.
- patch 3/5 "video: exynos_dsi: Use generic PHY driver" replaced
with a patch modifying the MIPI DSIM driver which is currently
in mainline.
This series depends on the generic PHY framework [1]. It can be browsed
at: http://git.linuxtv.org/snawrocki/samsung.git/exynos-mipi-phy
This branch is based on the 'for-next' branch from
git://git.kernel.org/pub/scm/linux/kernel/git/kgene/linux-samsung.git
and the patch series:
http://www.spinics.net/lists/arm-kernel/msg254667.html
Thank you for all the review comments.
[1] https://lkml.org/lkml/2013/6/25/22
Sylwester Nawrocki (5):
phy: Add driver for Exynos MIPI CSIS/DSIM DPHYs
ARM: dts: Add MIPI PHY node to exynos4.dtsi
video: exynos_mipi_dsim: Use generic PHY driver
exynos4-is: Use generic MIPI CSIS PHY driver
ARM: Samsung: Remove MIPI PHY setup code
.../phy/samsung,s5pv210-mipi-video-phy.txt | 14 ++
arch/arm/boot/dts/exynos4.dtsi | 10 ++
arch/arm/mach-exynos/include/mach/regs-pmu.h | 5 -
arch/arm/mach-s5pv210/include/mach/regs-clock.h | 4 -
arch/arm/plat-samsung/Kconfig | 5 -
arch/arm/plat-samsung/Makefile | 1 -
arch/arm/plat-samsung/setup-mipiphy.c | 60 -------
drivers/media/platform/exynos4-is/mipi-csis.c | 16 +-
drivers/phy/Kconfig | 9 +
drivers/phy/Makefile | 3 +-
drivers/phy/phy-exynos-mipi-video.c | 173 ++++++++++++++++++++
drivers/video/exynos/exynos_mipi_dsi.c | 18 +-
include/linux/platform_data/mipi-csis.h | 11 +-
include/video/exynos_mipi_dsim.h | 6 +-
14 files changed, 236 insertions(+), 99 deletions(-)
create mode 100644 Documentation/devicetree/bindings/phy/samsung,s5pv210-mipi-video-phy.txt
delete mode 100644 arch/arm/plat-samsung/setup-mipiphy.c
create mode 100644 drivers/phy/phy-exynos-mipi-video.c
--
1.7.9.5
^ permalink raw reply
* Re: [PATCH] Handle efifb with no lfb_base better.
From: Josh Boyer @ 2013-06-25 14:17 UTC (permalink / raw)
To: Peter Jones; +Cc: Florian Tobias Schandinat, linux-fbdev, linux-kernel
In-Reply-To: <1366730598-13942-1-git-send-email-pjones@redhat.com>
On Tue, Apr 23, 2013 at 11:23:18AM -0400, Peter Jones wrote:
> Right now we get a WARN from platform_device_unregister() because our
> platform_device has no ->release function. This is clearly wrong, but
> we should be warning so we can figure out what happened, as this failure
> results in bug reports. So WARN() about the real problem, and use the
> registration function that gives us a default release() function.
>
> This fixes the tracback reported at
> https://bugzilla.redhat.com/show_bug.cgi?id„0621 , though it does not
> fix the actual /problem/ the user is seeing.
>
> Signed-off-by: Peter Jones <pjones@redhat.com>
Is anyone in the fdbdev camp looking at this? It's been 2 months since
this was sent out without any comments and I don't see it in the tree
anywhere.
josh
> ---
> drivers/video/efifb.c | 15 ++++++++-------
> 1 file changed, 8 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/video/efifb.c b/drivers/video/efifb.c
> index 50fe668..390b61b 100644
> --- a/drivers/video/efifb.c
> +++ b/drivers/video/efifb.c
> @@ -285,6 +285,7 @@ static void efifb_destroy(struct fb_info *info)
> {
> if (info->screen_base)
> iounmap(info->screen_base);
> + fb_dealloc_cmap(&info->cmap);
> if (request_mem_succeeded)
> release_mem_region(info->apertures->ranges[0].base,
> info->apertures->ranges[0].size);
> @@ -382,6 +383,8 @@ static int __init efifb_probe(struct platform_device *dev)
> if (!screen_info.pages)
> screen_info.pages = 1;
> if (!screen_info.lfb_base) {
> + WARN(1, KERN_WARNING, "invalid framebuffer address for "
> + "device '%s'\n", dev_name(dev));
> printk(KERN_DEBUG "efifb: invalid framebuffer address\n");
> return -ENODEV;
> }
> @@ -544,9 +547,7 @@ static struct platform_driver efifb_driver = {
> },
> };
>
> -static struct platform_device efifb_device = {
> - .name = "efifb",
> -};
> +static struct platform_device *efifb_device;
>
> static int __init efifb_init(void)
> {
> @@ -571,9 +572,9 @@ static int __init efifb_init(void)
> if (!screen_info.lfb_linelength)
> return -ENODEV;
>
> - ret = platform_device_register(&efifb_device);
> - if (ret)
> - return ret;
> + efifb_device = platform_device_register_simple("efifb", 0, NULL, 0);
> + if (IS_ERROR(efifb_device))
> + return PTR_ERR(efifb_device);
>
> /*
> * This is not just an optimization. We will interfere
> @@ -582,7 +583,7 @@ static int __init efifb_init(void)
> */
> ret = platform_driver_probe(&efifb_driver, efifb_probe);
> if (ret) {
> - platform_device_unregister(&efifb_device);
> + platform_device_unregister(efifb_device);
> return ret;
> }
>
> --
> 1.8.1.4
>
^ permalink raw reply
* Re: [RFC PATCH] dmabuf-sync: Introduce buffer synchronization framework
From: Inki Dae @ 2013-06-25 14:17 UTC (permalink / raw)
To: Rob Clark
Cc: Jerome Glisse, linux-fbdev, Russell King - ARM Linux,
DRI mailing list, Kyungmin Park, myungjoo.ham, YoungJun Cho,
linux-media@vger.kernel.org, linux-arm-kernel@lists.infradead.org
In-Reply-To: <CAF6AEGsBvZbcWDbX3FFtyDxFO1NqYNRLqHEUyP4qUD9wK+ARbA@mail.gmail.com>
2013/6/25 Rob Clark <robdclark@gmail.com>:
> On Tue, Jun 25, 2013 at 5:09 AM, Inki Dae <daeinki@gmail.com> wrote:
>>> that
>>> should be the role of kernel memory management which of course needs
>>> synchronization btw A and B. But in no case this should be done using
>>> dma-buf. dma-buf is for sharing content btw different devices not
>>> sharing resources.
>>>
>>
>> hmm, is that true? And are you sure? Then how do you think about
>> reservation? the reservation also uses dma-buf with same reason as long as I
>> know: actually, we use reservation to use dma-buf. As you may know, a
>> reservation object is allocated and initialized when a buffer object is
>> exported to a dma buf.
>
> no, this is why the reservation object can be passed in when you
> construction the dmabuf.
Right, that way, we could use dma buf for buffer synchronization. I
just wanted to ask for why Jerome said that "dma-buf is for sharing
content btw different devices not sharing resources".
> The fallback is for dmabuf to create it's
> own, for compatibility and to make life easier for simple devices with
> few buffers... but I think pretty much all drm drivers would embed the
> reservation object in the gem buffer and pass it in when the dmabuf is
> created.
>
> It is pretty much imperative that synchronization works independently
> of dmabuf, you really don't want to have two different cases to deal
> with in your driver, one for synchronizing non-exported objects, and
> one for synchronizing dmabuf objects.
>
Now my approach is concentrating on the most basic implementation,
buffer synchronization mechanism between CPU and CPU, CPU and DMA, and
DMA and DMA. But I think reserveration could be used for other
purposes such as pipe line synchronization independently of dmabuf as
you said. Actually, I had already implemented pipe line
synchronization mechanism using the reservation: in case of MALI-400
DDK, there was pipe line issue between gp and pp jobs, and we had
solved the issue using the pipe line synchronization mechanism with
the reservation. So, we could add more features anytime; those two
different cases, dmabuf objects and non-exported objects, if needed
because we are using the reservation object.
Thanks,
Inki Dae
> BR,
> -R
^ permalink raw reply
* [PATCH v2 1/5] phy: Add driver for Exynos MIPI CSIS/DSIM DPHYs
From: Sylwester Nawrocki @ 2013-06-25 14:21 UTC (permalink / raw)
To: linux-arm-kernel
Add a PHY provider driver for the Samsung S5P/Exynos SoC MIPI CSI-2
receiver and MIPI DSI transmitter DPHYs.
Signed-off-by: Sylwester Nawrocki <s.nawrocki@samsung.com>
Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com>
---
Changes since v1:
- enabled build as module and with CONFIG_OF disabled
- added phy_id enum,
- of_address_to_resource() replaced with platform_get_resource(),
- adapted to changes in the PHY API v7, v8 - added phy labels,
- added MODULE_DEVICE_TABLE() entry,
- driver file renamed to phy-exynos-mipi-video.c,
- changed DT compatible string to "samsung,s5pv210-mipi-video-phy",
- corrected the compatible property's description.
---
.../phy/samsung,s5pv210-mipi-video-phy.txt | 14 ++
drivers/phy/Kconfig | 9 +
drivers/phy/Makefile | 3 +-
drivers/phy/phy-exynos-mipi-video.c | 173 ++++++++++++++++++++
4 files changed, 198 insertions(+), 1 deletion(-)
create mode 100644 Documentation/devicetree/bindings/phy/samsung,s5pv210-mipi-video-phy.txt
create mode 100644 drivers/phy/phy-exynos-mipi-video.c
diff --git a/Documentation/devicetree/bindings/phy/samsung,s5pv210-mipi-video-phy.txt b/Documentation/devicetree/bindings/phy/samsung,s5pv210-mipi-video-phy.txt
new file mode 100644
index 0000000..5ff208c
--- /dev/null
+++ b/Documentation/devicetree/bindings/phy/samsung,s5pv210-mipi-video-phy.txt
@@ -0,0 +1,14 @@
+Samsung S5P/EXYNOS SoC series MIPI CSIS/DSIM DPHY
+-------------------------------------------------
+
+Required properties:
+- compatible : should be "samsung,s5pv210-mipi-video-phy";
+- reg : offset and length of the MIPI DPHY register set;
+- #phy-cells : from the generic phy bindings, must be 1;
+
+For "samsung,s5pv210-mipi-video-phy" compatible PHYs the second cell in
+the PHY specifier identifies the PHY and its meaning is as follows:
+ 0 - MIPI CSIS 0,
+ 1 - MIPI DSIM 0,
+ 2 - MIPI CSIS 1,
+ 3 - MIPI DSIM 1.
diff --git a/drivers/phy/Kconfig b/drivers/phy/Kconfig
index 5f85909..6f446d0 100644
--- a/drivers/phy/Kconfig
+++ b/drivers/phy/Kconfig
@@ -11,3 +11,12 @@ menuconfig GENERIC_PHY
devices present in the kernel. This layer will have the generic
API by which phy drivers can create PHY using the phy framework and
phy users can obtain reference to the PHY.
+
+if GENERIC_PHY
+
+config PHY_EXYNOS_MIPI_VIDEO
+ tristate "S5P/EXYNOS SoC series MIPI CSI-2/DSI PHY driver"
+ help
+ Support for MIPI CSI-2 and MIPI DSI DPHY found on Samsung
+ S5P and EXYNOS SoCs.
+endif
diff --git a/drivers/phy/Makefile b/drivers/phy/Makefile
index 9e9560f..71d8841 100644
--- a/drivers/phy/Makefile
+++ b/drivers/phy/Makefile
@@ -2,4 +2,5 @@
# Makefile for the phy drivers.
#
-obj-$(CONFIG_GENERIC_PHY) += phy-core.o
+obj-$(CONFIG_GENERIC_PHY) += phy-core.o
+obj-$(CONFIG_PHY_EXYNOS_MIPI_VIDEO) += phy-exynos-mipi-video.o
diff --git a/drivers/phy/phy-exynos-mipi-video.c b/drivers/phy/phy-exynos-mipi-video.c
new file mode 100644
index 0000000..074a623
--- /dev/null
+++ b/drivers/phy/phy-exynos-mipi-video.c
@@ -0,0 +1,173 @@
+/*
+ * Samsung S5P/EXYNOS SoC series MIPI CSIS/DSIM DPHY driver
+ *
+ * Copyright (C) 2013 Samsung Electronics Co., Ltd.
+ * Author: Sylwester Nawrocki <s.nawrocki@samsung.com>
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include <linux/delay.h>
+#include <linux/io.h>
+#include <linux/kernel.h>
+#include <linux/module.h>
+#include <linux/of.h>
+#include <linux/of_address.h>
+#include <linux/phy/phy.h>
+#include <linux/platform_device.h>
+#include <linux/spinlock.h>
+
+/* MIPI_PHYn_CONTROL register offset: n = 0..1 */
+#define EXYNOS_MIPI_PHY_CONTROL(n) ((n) * 4)
+#define EXYNOS_MIPI_PHY_ENABLE (1 << 0)
+#define EXYNOS_MIPI_PHY_SRESETN (1 << 1)
+#define EXYNOS_MIPI_PHY_MRESETN (1 << 2)
+#define EXYNOS_MIPI_PHY_RESET_MASK (3 << 1)
+
+enum phy_id {
+ PHY_CSIS0,
+ PHY_DSIM0,
+ PHY_CSIS1,
+ PHY_DSIM1,
+ NUM_PHYS
+};
+
+struct exynos_video_phy {
+ spinlock_t slock;
+ struct phy *phys[NUM_PHYS];
+ void __iomem *regs;
+};
+
+static int __set_phy_state(struct exynos_video_phy *state,
+ enum phy_id id, unsigned int on)
+{
+ void __iomem *addr;
+ unsigned long flags;
+ u32 reg, reset;
+
+ if (WARN_ON(id > NUM_PHYS))
+ return -EINVAL;
+
+ addr = state->regs + EXYNOS_MIPI_PHY_CONTROL(id / 2);
+
+ if (id = PHY_DSIM0 || id = PHY_DSIM1)
+ reset = EXYNOS_MIPI_PHY_MRESETN;
+ else
+ reset = EXYNOS_MIPI_PHY_SRESETN;
+
+ spin_lock_irqsave(&state->slock, flags);
+ reg = readl(addr);
+ if (on)
+ reg |= reset;
+ else
+ reg &= ~reset;
+ writel(reg, addr);
+
+ /* Clear ENABLE bit only if MRESETN, SRESETN bits are not set. */
+ if (on)
+ reg |= EXYNOS_MIPI_PHY_ENABLE;
+ else if (!(reg & EXYNOS_MIPI_PHY_RESET_MASK))
+ reg &= ~EXYNOS_MIPI_PHY_ENABLE;
+
+ writel(reg, addr);
+ spin_unlock_irqrestore(&state->slock, flags);
+
+ pr_debug("%s(): id: %d, on: %d, addr: %#x, base: %#x\n",
+ __func__, id, on, (u32)addr, (u32)state->regs);
+
+ return 0;
+}
+
+static int exynos_video_phy_power_on(struct phy *phy)
+{
+ struct exynos_video_phy *state = dev_get_drvdata(&phy->dev);
+ return __set_phy_state(state, phy->id, 1);
+}
+
+static int exynos_video_phy_power_off(struct phy *phy)
+{
+ struct exynos_video_phy *state = dev_get_drvdata(&phy->dev);
+ return __set_phy_state(state, phy->id, 0);
+}
+
+static struct phy *exynos_video_phy_xlate(struct device *dev,
+ struct of_phandle_args *args)
+{
+ struct exynos_video_phy *state = dev_get_drvdata(dev);
+
+ if (WARN_ON(args->args[0] > NUM_PHYS))
+ return NULL;
+
+ return state->phys[args->args[0]];
+}
+
+static struct phy_ops exynos_video_phy_ops = {
+ .power_on = exynos_video_phy_power_on,
+ .power_off = exynos_video_phy_power_off,
+ .owner = THIS_MODULE,
+};
+
+static int exynos_video_phy_probe(struct platform_device *pdev)
+{
+ struct exynos_video_phy *state;
+ struct device *dev = &pdev->dev;
+ struct resource *res;
+ struct phy_provider *phy_provider;
+ int i;
+
+ state = devm_kzalloc(dev, sizeof(*state), GFP_KERNEL);
+ if (!state)
+ return -ENOMEM;
+
+ res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+
+ state->regs = devm_ioremap_resource(dev, res);
+ if (IS_ERR(state->regs))
+ return PTR_ERR(state->regs);
+
+ dev_set_drvdata(dev, state);
+
+ phy_provider = devm_of_phy_provider_register(dev,
+ exynos_video_phy_xlate);
+ if (IS_ERR(phy_provider))
+ return PTR_ERR(phy_provider);
+
+ for (i = 0; i < NUM_PHYS; i++) {
+ char label[8];
+
+ snprintf(label, sizeof(label), "%s.%d",
+ i = PHY_DSIM0 || i = PHY_DSIM1 ?
+ "dsim" : "csis", i / 2);
+
+ state->phys[i] = devm_phy_create(dev, i, &exynos_video_phy_ops,
+ label, state);
+ if (IS_ERR(state->phys[i])) {
+ dev_err(dev, "failed to create PHY %s\n", label);
+ return PTR_ERR(state->phys[i]);
+ }
+ }
+
+ return 0;
+}
+
+static const struct of_device_id exynos_video_phy_of_match[] = {
+ { .compatible = "samsung,s5pv210-mipi-video-phy" },
+ { },
+};
+MODULE_DEVICE_TABLE(of, exynos_video_phy_of_match);
+
+static struct platform_driver exynos_video_phy_driver = {
+ .probe = exynos_video_phy_probe,
+ .driver = {
+ .of_match_table = exynos_video_phy_of_match,
+ .name = "exynos-mipi-video-phy",
+ .owner = THIS_MODULE,
+ }
+};
+module_platform_driver(exynos_video_phy_driver);
+
+MODULE_DESCRIPTION("Samsung S5P/EXYNOS SoC MIPI CSI-2/DSI PHY driver");
+MODULE_LICENSE("GPL");
+MODULE_AUTHOR("Sylwester Nawrocki <s.nawrocki@samsung.com>");
--
1.7.9.5
^ permalink raw reply related
* [PATCH v2 2/5] ARM: dts: Add MIPI PHY node to exynos4.dtsi
From: Sylwester Nawrocki @ 2013-06-25 14:21 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1372170110-12993-1-git-send-email-s.nawrocki@samsung.com>
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>
---
arch/arm/boot/dts/exynos4.dtsi | 10 ++++++++++
1 file changed, 10 insertions(+)
diff --git a/arch/arm/boot/dts/exynos4.dtsi b/arch/arm/boot/dts/exynos4.dtsi
index 4d61120..9542088 100644
--- a/arch/arm/boot/dts/exynos4.dtsi
+++ b/arch/arm/boot/dts/exynos4.dtsi
@@ -98,6 +98,12 @@
reg = <0x10010000 0x400>;
};
+ mipi_phy: video-phy@10020710 {
+ compatible = "samsung,s5pv210-mipi-video-phy";
+ reg = <0x10020710 8>;
+ #phy-cells = <1>;
+ };
+
camera {
compatible = "samsung,fimc", "simple-bus";
status = "disabled";
@@ -147,6 +153,8 @@
interrupts = <0 78 0>;
bus-width = <4>;
samsung,power-domain = <&pd_cam>;
+ phys = <&mipi_phy 0>;
+ phy-names = "csis";
status = "disabled";
};
@@ -156,6 +164,8 @@
interrupts = <0 80 0>;
bus-width = <2>;
samsung,power-domain = <&pd_cam>;
+ phys = <&mipi_phy 2>;
+ phy-names = "csis";
status = "disabled";
};
};
--
1.7.9.5
^ permalink raw reply related
* [PATCH v2 3/5] video: exynos_mipi_dsim: Use generic PHY driver
From: Sylwester Nawrocki @ 2013-06-25 14:21 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1372170110-12993-1-git-send-email-s.nawrocki@samsung.com>
Use the generic PHY API instead of the platform callback to control
the MIPI DSIM DPHY. The 'phy_label' field is added to the platform
data structure to allow PHY lookup on non-dt platforms.
Signed-off-by: Sylwester Nawrocki <s.nawrocki@samsung.com>
Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com>
---
drivers/video/exynos/exynos_mipi_dsi.c | 18 +++++++++---------
include/video/exynos_mipi_dsim.h | 6 ++++--
2 files changed, 13 insertions(+), 11 deletions(-)
diff --git a/drivers/video/exynos/exynos_mipi_dsi.c b/drivers/video/exynos/exynos_mipi_dsi.c
index 32e5406..1f96004 100644
--- a/drivers/video/exynos/exynos_mipi_dsi.c
+++ b/drivers/video/exynos/exynos_mipi_dsi.c
@@ -156,8 +156,7 @@ static int exynos_mipi_dsi_blank_mode(struct mipi_dsim_device *dsim, int power)
exynos_mipi_regulator_enable(dsim);
/* enable MIPI-DSI PHY. */
- if (dsim->pd->phy_enable)
- dsim->pd->phy_enable(pdev, true);
+ phy_power_on(dsim->phy);
clk_enable(dsim->clock);
@@ -373,6 +372,10 @@ static int exynos_mipi_dsi_probe(struct platform_device *pdev)
return ret;
}
+ dsim->phy = devm_phy_get(&pdev->dev, dsim_pd->phy_label);
+ if (IS_ERR(dsim->phy))
+ return PTR_ERR(dsim->phy);
+
dsim->clock = devm_clk_get(&pdev->dev, "dsim0");
if (IS_ERR(dsim->clock)) {
dev_err(&pdev->dev, "failed to get dsim clock source\n");
@@ -439,8 +442,7 @@ static int exynos_mipi_dsi_probe(struct platform_device *pdev)
exynos_mipi_regulator_enable(dsim);
/* enable MIPI-DSI PHY. */
- if (dsim->pd->phy_enable)
- dsim->pd->phy_enable(pdev, true);
+ phy_power_on(dsim->phy);
exynos_mipi_update_cfg(dsim);
@@ -504,9 +506,8 @@ static int exynos_mipi_dsi_suspend(struct device *dev)
if (client_drv && client_drv->suspend)
client_drv->suspend(client_dev);
- /* enable MIPI-DSI PHY. */
- if (dsim->pd->phy_enable)
- dsim->pd->phy_enable(pdev, false);
+ /* disable MIPI-DSI PHY. */
+ phy_power_off(dsim->phy);
clk_disable(dsim->clock);
@@ -536,8 +537,7 @@ static int exynos_mipi_dsi_resume(struct device *dev)
exynos_mipi_regulator_enable(dsim);
/* enable MIPI-DSI PHY. */
- if (dsim->pd->phy_enable)
- dsim->pd->phy_enable(pdev, true);
+ phy_power_on(dsim->phy);
clk_enable(dsim->clock);
diff --git a/include/video/exynos_mipi_dsim.h b/include/video/exynos_mipi_dsim.h
index 89dc88a..fd69beb 100644
--- a/include/video/exynos_mipi_dsim.h
+++ b/include/video/exynos_mipi_dsim.h
@@ -216,6 +216,7 @@ struct mipi_dsim_config {
* automatically.
* @e_clk_src: select byte clock source.
* @pd: pointer to MIPI-DSI driver platform data.
+ * @phy: pointer to the generic PHY
*/
struct mipi_dsim_device {
struct device *dev;
@@ -236,6 +237,7 @@ struct mipi_dsim_device {
bool suspended;
struct mipi_dsim_platform_data *pd;
+ struct phy *phy;
};
/*
@@ -248,7 +250,7 @@ struct mipi_dsim_device {
* @enabled: indicate whether mipi controller got enabled or not.
* @lcd_panel_info: pointer for lcd panel specific structure.
* this structure specifies width, height, timing and polarity and so on.
- * @phy_enable: pointer to a callback controlling D-PHY enable/reset
+ * @phy_label: the generic PHY label
*/
struct mipi_dsim_platform_data {
char lcd_panel_name[PANEL_NAME_SIZE];
@@ -257,7 +259,7 @@ struct mipi_dsim_platform_data {
unsigned int enabled;
void *lcd_panel_info;
- int (*phy_enable)(struct platform_device *pdev, bool on);
+ const char *phy_label;
};
/*
--
1.7.9.5
^ permalink raw reply related
* [PATCH v2 4/5] exynos4-is: Use generic MIPI CSIS PHY driver
From: Sylwester Nawrocki @ 2013-06-25 14:21 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1372170110-12993-1-git-send-email-s.nawrocki@samsung.com>
Use the generic PHY API instead of the platform callback to control
the MIPI CSIS DPHY. The 'phy_label' field is added to the platform
data structure to allow PHY lookup on non-dt platforms
Signed-off-by: Sylwester Nawrocki <s.nawrocki@samsung.com>
Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com>
---
drivers/media/platform/exynos4-is/mipi-csis.c | 16 +++++++++++++---
include/linux/platform_data/mipi-csis.h | 11 ++---------
2 files changed, 15 insertions(+), 12 deletions(-)
diff --git a/drivers/media/platform/exynos4-is/mipi-csis.c b/drivers/media/platform/exynos4-is/mipi-csis.c
index a2eda9d..8436254 100644
--- a/drivers/media/platform/exynos4-is/mipi-csis.c
+++ b/drivers/media/platform/exynos4-is/mipi-csis.c
@@ -20,6 +20,7 @@
#include <linux/memory.h>
#include <linux/module.h>
#include <linux/of.h>
+#include <linux/phy/phy.h>
#include <linux/platform_data/mipi-csis.h>
#include <linux/platform_device.h>
#include <linux/pm_runtime.h>
@@ -167,6 +168,7 @@ struct csis_pktbuf {
* @sd: v4l2_subdev associated with CSIS device instance
* @index: the hardware instance index
* @pdev: CSIS platform device
+ * @phy: pointer to the CSIS generic PHY
* @regs: mmaped I/O registers memory
* @supplies: CSIS regulator supplies
* @clock: CSIS clocks
@@ -189,6 +191,8 @@ struct csis_state {
struct v4l2_subdev sd;
u8 index;
struct platform_device *pdev;
+ struct phy *phy;
+ const char *phy_label;
void __iomem *regs;
struct regulator_bulk_data supplies[CSIS_NUM_SUPPLIES];
struct clk *clock[NUM_CSIS_CLOCKS];
@@ -726,6 +730,7 @@ static int s5pcsis_get_platform_data(struct platform_device *pdev,
state->index = max(0, pdev->id);
state->max_num_lanes = state->index ? CSIS1_MAX_LANES :
CSIS0_MAX_LANES;
+ state->phy_label = pdata->phy_label;
return 0;
}
@@ -763,8 +768,9 @@ static int s5pcsis_parse_dt(struct platform_device *pdev,
"samsung,csis-wclk");
state->num_lanes = endpoint.bus.mipi_csi2.num_data_lanes;
-
of_node_put(node);
+
+ state->phy_label = "csis";
return 0;
}
#else
@@ -800,6 +806,10 @@ static int s5pcsis_probe(struct platform_device *pdev)
return -EINVAL;
}
+ state->phy = devm_phy_get(dev, state->phy_label);
+ if (IS_ERR(state->phy))
+ return PTR_ERR(state->phy);
+
mem_res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
state->regs = devm_ioremap_resource(dev, mem_res);
if (IS_ERR(state->regs))
@@ -893,7 +903,7 @@ static int s5pcsis_pm_suspend(struct device *dev, bool runtime)
mutex_lock(&state->lock);
if (state->flags & ST_POWERED) {
s5pcsis_stop_stream(state);
- ret = s5p_csis_phy_enable(state->index, false);
+ ret = phy_power_off(state->phy);
if (ret)
goto unlock;
ret = regulator_bulk_disable(CSIS_NUM_SUPPLIES,
@@ -929,7 +939,7 @@ static int s5pcsis_pm_resume(struct device *dev, bool runtime)
state->supplies);
if (ret)
goto unlock;
- ret = s5p_csis_phy_enable(state->index, true);
+ ret = phy_power_on(state->phy);
if (!ret) {
state->flags |= ST_POWERED;
} else {
diff --git a/include/linux/platform_data/mipi-csis.h b/include/linux/platform_data/mipi-csis.h
index bf34e17..9214317 100644
--- a/include/linux/platform_data/mipi-csis.h
+++ b/include/linux/platform_data/mipi-csis.h
@@ -17,21 +17,14 @@
* @wclk_source: CSI wrapper clock selection: 0 - bus clock, 1 - ext. SCLK_CAM
* @lanes: number of data lanes used
* @hs_settle: HS-RX settle time
+ * @phy_label: the generic PHY label
*/
struct s5p_platform_mipi_csis {
unsigned long clk_rate;
u8 wclk_source;
u8 lanes;
u8 hs_settle;
+ const char *phy_label;
};
-/**
- * s5p_csis_phy_enable - global MIPI-CSI receiver D-PHY control
- * @id: MIPI-CSIS harware instance index (0...1)
- * @on: true to enable D-PHY and deassert its reset
- * false to disable D-PHY
- * @return: 0 on success, or negative error code on failure
- */
-int s5p_csis_phy_enable(int id, bool on);
-
#endif /* __PLAT_SAMSUNG_MIPI_CSIS_H_ */
--
1.7.9.5
^ permalink raw reply related
* [PATCH v2 5/5] ARM: Samsung: Remove MIPI PHY setup code
From: Sylwester Nawrocki @ 2013-06-25 14:21 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1372170110-12993-1-git-send-email-s.nawrocki@samsung.com>
Generic PHY drivers are used to handle the MIPI CSIS and MIPI DSIM
DPHYs so we can remove now unused code at arch/arm/plat-samsung.
In case there is any board file for S5PV210 platforms using MIPI
CSIS/DSIM (not any upstream currently) it should use the generic
PHY API to bind the PHYs to respective PHY consumer drivers.
Signed-off-by: Sylwester Nawrocki <s.nawrocki@samsung.com>
Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com>
---
Changes since v1:
- removed S5P_SETUP_MIPIPHY symbol completely from
arch/arm/plat-samsung/Kconfig
---
arch/arm/mach-exynos/include/mach/regs-pmu.h | 5 --
arch/arm/mach-s5pv210/include/mach/regs-clock.h | 4 --
arch/arm/plat-samsung/Kconfig | 5 --
arch/arm/plat-samsung/Makefile | 1 -
arch/arm/plat-samsung/setup-mipiphy.c | 60 -----------------------
5 files changed, 75 deletions(-)
delete mode 100644 arch/arm/plat-samsung/setup-mipiphy.c
diff --git a/arch/arm/mach-exynos/include/mach/regs-pmu.h b/arch/arm/mach-exynos/include/mach/regs-pmu.h
index 57344b7..2cdb63e 100644
--- a/arch/arm/mach-exynos/include/mach/regs-pmu.h
+++ b/arch/arm/mach-exynos/include/mach/regs-pmu.h
@@ -44,11 +44,6 @@
#define S5P_DAC_PHY_CONTROL S5P_PMUREG(0x070C)
#define S5P_DAC_PHY_ENABLE (1 << 0)
-#define S5P_MIPI_DPHY_CONTROL(n) S5P_PMUREG(0x0710 + (n) * 4)
-#define S5P_MIPI_DPHY_ENABLE (1 << 0)
-#define S5P_MIPI_DPHY_SRESETN (1 << 1)
-#define S5P_MIPI_DPHY_MRESETN (1 << 2)
-
#define S5P_INFORM0 S5P_PMUREG(0x0800)
#define S5P_INFORM1 S5P_PMUREG(0x0804)
#define S5P_INFORM2 S5P_PMUREG(0x0808)
diff --git a/arch/arm/mach-s5pv210/include/mach/regs-clock.h b/arch/arm/mach-s5pv210/include/mach/regs-clock.h
index 032de66..e345584 100644
--- a/arch/arm/mach-s5pv210/include/mach/regs-clock.h
+++ b/arch/arm/mach-s5pv210/include/mach/regs-clock.h
@@ -147,10 +147,6 @@
#define S5P_HDMI_PHY_CONTROL S5P_CLKREG(0xE804)
#define S5P_USB_PHY_CONTROL S5P_CLKREG(0xE80C)
#define S5P_DAC_PHY_CONTROL S5P_CLKREG(0xE810)
-#define S5P_MIPI_DPHY_CONTROL(x) S5P_CLKREG(0xE814)
-#define S5P_MIPI_DPHY_ENABLE (1 << 0)
-#define S5P_MIPI_DPHY_SRESETN (1 << 1)
-#define S5P_MIPI_DPHY_MRESETN (1 << 2)
#define S5P_INFORM0 S5P_CLKREG(0xF000)
#define S5P_INFORM1 S5P_CLKREG(0xF004)
diff --git a/arch/arm/plat-samsung/Kconfig b/arch/arm/plat-samsung/Kconfig
index b21d9d5..60f6337 100644
--- a/arch/arm/plat-samsung/Kconfig
+++ b/arch/arm/plat-samsung/Kconfig
@@ -388,11 +388,6 @@ config S3C24XX_PWM
Support for exporting the PWM timer blocks via the pwm device
system
-config S5P_SETUP_MIPIPHY
- bool
- help
- Compile in common setup code for MIPI-CSIS and MIPI-DSIM devices
-
config S3C_SETUP_CAMIF
bool
help
diff --git a/arch/arm/plat-samsung/Makefile b/arch/arm/plat-samsung/Makefile
index 5d7f839..0db786e 100644
--- a/arch/arm/plat-samsung/Makefile
+++ b/arch/arm/plat-samsung/Makefile
@@ -38,7 +38,6 @@ obj-$(CONFIG_S5P_DEV_UART) += s5p-dev-uart.o
obj-$(CONFIG_SAMSUNG_DEV_BACKLIGHT) += dev-backlight.o
obj-$(CONFIG_S3C_SETUP_CAMIF) += setup-camif.o
-obj-$(CONFIG_S5P_SETUP_MIPIPHY) += setup-mipiphy.o
# DMA support
diff --git a/arch/arm/plat-samsung/setup-mipiphy.c b/arch/arm/plat-samsung/setup-mipiphy.c
deleted file mode 100644
index 66df315..0000000
--- a/arch/arm/plat-samsung/setup-mipiphy.c
+++ /dev/null
@@ -1,60 +0,0 @@
-/*
- * Copyright (C) 2011 Samsung Electronics Co., Ltd.
- *
- * S5P - Helper functions for MIPI-CSIS and MIPI-DSIM D-PHY control
- *
- * This program is free software; you can redistribute it and/or modify
- * it under the terms of the GNU General Public License version 2 as
- * published by the Free Software Foundation.
- */
-
-#include <linux/export.h>
-#include <linux/kernel.h>
-#include <linux/platform_device.h>
-#include <linux/io.h>
-#include <linux/spinlock.h>
-#include <mach/regs-clock.h>
-
-static int __s5p_mipi_phy_control(int id, bool on, u32 reset)
-{
- static DEFINE_SPINLOCK(lock);
- void __iomem *addr;
- unsigned long flags;
- u32 cfg;
-
- id = max(0, id);
- if (id > 1)
- return -EINVAL;
-
- addr = S5P_MIPI_DPHY_CONTROL(id);
-
- spin_lock_irqsave(&lock, flags);
-
- cfg = __raw_readl(addr);
- cfg = on ? (cfg | reset) : (cfg & ~reset);
- __raw_writel(cfg, addr);
-
- if (on) {
- cfg |= S5P_MIPI_DPHY_ENABLE;
- } else if (!(cfg & (S5P_MIPI_DPHY_SRESETN |
- S5P_MIPI_DPHY_MRESETN) & ~reset)) {
- cfg &= ~S5P_MIPI_DPHY_ENABLE;
- }
-
- __raw_writel(cfg, addr);
- spin_unlock_irqrestore(&lock, flags);
-
- return 0;
-}
-
-int s5p_csis_phy_enable(int id, bool on)
-{
- return __s5p_mipi_phy_control(id, on, S5P_MIPI_DPHY_SRESETN);
-}
-EXPORT_SYMBOL(s5p_csis_phy_enable);
-
-int s5p_dsim_phy_enable(struct platform_device *pdev, bool on)
-{
- return __s5p_mipi_phy_control(pdev->id, on, S5P_MIPI_DPHY_MRESETN);
-}
-EXPORT_SYMBOL(s5p_dsim_phy_enable);
--
1.7.9.5
^ permalink raw reply related
* [PATCH 00/23] video/da8xx-fb fbdev driver enhance to support TI am335x SoC
From: Darren Etheridge @ 2013-06-25 14:22 UTC (permalink / raw)
To: linux-fbdev
This is primarily a resend of a series of patches that were original
submitted to linux-fbdev back in January of 2013 for 3.8 by Afzal
Mohammed. I have rebased them on 3.10-rc6 and also made sure they
apply cleanly to the 'for-next' branch of linux-fbdev git.
The patches enable use of the current mainline da8xx-fb driver on the
TI AM335x SOC along with some bug fixes and cleanup.
The original patch series can be found here:
https://patchwork.kernel.org/project/linux-fbdev/list/?submitter9101
if you want to see the history.
Afzal Mohammed (21):
video: da8xx-fb: fb_check_var enhancement
video: da8xx-fb: simplify lcd_reset
video: da8xx-fb: use modedb helper to update var
video: da8xx-fb: remove unneeded "var" initialization
video: da8xx-fb: store current display information
video: da8xx-fb: store clk rate even if !CPUFREQ
video: da8xx-fb: pix clk and clk div handling cleanup
video: da8xx-fb: store struct device *
video: da8xx-fb: report correct pixclock
video: da8xx-fb: fb_set_par support
video: da8xx-fb: make io operations safe
video: da8xx-fb: enable sync lost intr for v2 ip
video: da8xx-fb: use devres
video: da8xx-fb: ensure non-null cfg in pdata
video: da8xx-fb: reorganize panel detection
video: da8xx-fb: minimal dt support
video: da8xx-fb: invoke platform callback safely
video: da8xx-fb: obtain fb_videomode info from dt
video: da8xx-fb: ensure pdata only for non-dt
video: da8xx-fb: setup struct lcd_ctrl_config for dt
video: da8xx-fb: set upstream clock rate (if reqd)
Darren Etheridge (1):
video/da8xx-fb adding am33xx as dependency
Manjunathappa, Prakash (1):
video: da8xx-fb: fix 24bpp raster configuration
.../devicetree/bindings/video/fb-da8xx.txt | 37 ++
drivers/video/Kconfig | 7 +-
drivers/video/da8xx-fb.c | 363 +++++++++++++-------
3 files changed, 279 insertions(+), 128 deletions(-)
create mode 100644 Documentation/devicetree/bindings/video/fb-da8xx.txt
^ permalink raw reply
* [PATCH 01/23] video: da8xx-fb: fb_check_var enhancement
From: Darren Etheridge @ 2013-06-25 14:22 UTC (permalink / raw)
To: linux-fbdev
From: Afzal Mohammed <afzal@ti.com>
Check whether "struct fb_var_screeninfo" fields are sane, if not
update it to be within allowed limits.
If user sends down buggy "var" values, this will bring those within
allowable limits. And fb_set_par is not supposed to change "var"
values, fb_check_var has to ensure that values are proper.
Signed-off-by: Afzal Mohammed <afzal@ti.com>
Signed-off-by: Darren Etheridge <detheridge@ti.com>
---
drivers/video/da8xx-fb.c | 18 ++++++++++++++++++
1 files changed, 18 insertions(+), 0 deletions(-)
diff --git a/drivers/video/da8xx-fb.c b/drivers/video/da8xx-fb.c
index 0810939..d00dd17 100644
--- a/drivers/video/da8xx-fb.c
+++ b/drivers/video/da8xx-fb.c
@@ -888,6 +888,9 @@ static int fb_check_var(struct fb_var_screeninfo *var,
struct fb_info *info)
{
int err = 0;
+ struct da8xx_fb_par *par = info->par;
+ int bpp = var->bits_per_pixel >> 3;
+ unsigned long line_size = var->xres_virtual * bpp;
if (var->bits_per_pixel > 16 && lcd_revision = LCD_VERSION_1)
return -EINVAL;
@@ -955,6 +958,21 @@ static int fb_check_var(struct fb_var_screeninfo *var,
var->green.msb_right = 0;
var->blue.msb_right = 0;
var->transp.msb_right = 0;
+
+ if (line_size * var->yres_virtual > par->vram_size)
+ var->yres_virtual = par->vram_size / line_size;
+
+ if (var->yres > var->yres_virtual)
+ var->yres = var->yres_virtual;
+
+ if (var->xres > var->xres_virtual)
+ var->xres = var->xres_virtual;
+
+ if (var->xres + var->xoffset > var->xres_virtual)
+ var->xoffset = var->xres_virtual - var->xres;
+ if (var->yres + var->yoffset > var->yres_virtual)
+ var->yoffset = var->yres_virtual - var->yres;
+
return err;
}
--
1.7.0.4
^ 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