* Re: [PATCH 2/2] video:da8xx-fb: Convert to devm_* api
From: Tomi Valkeinen @ 2013-06-26 12:11 UTC (permalink / raw)
To: Prabhakar Lad
Cc: Etheridge, Darren, DLOS, LFBDEV, Florian Tobias Schandinat, LKML
In-Reply-To: <CA+V-a8u6vjSc5EV3z4FCQ8LEHxL79bUXtHzX8svhQwqVtj6w=g@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1679 bytes --]
On 26/06/13 15:06, Prabhakar Lad wrote:
> Hi Tomi,
>
> On Wed, Jun 26, 2013 at 5:30 PM, Tomi Valkeinen <tomi.valkeinen@ti.com> wrote:
>> On 26/06/13 14:56, Prabhakar Lad wrote:
>>> Hi Tomi,
>>>
>>> On Wed, Jun 26, 2013 at 5:09 PM, Tomi Valkeinen <tomi.valkeinen@ti.com> wrote:
>>>> On 16/05/13 10:10, Lad Prabhakar wrote:
>>>>> From: Lad, Prabhakar <prabhakar.csengg@gmail.com>
>>>>>
>>>>> Use devm_ioremap_resource instead of reques_mem_region()/ioremap() and
>>>>> devm_request_irq() instead of request_irq().
>>>>>
>>>>> This ensures more consistent error values and simplifies error paths.
>>>>>
>>>>> Signed-off-by: Lad, Prabhakar <prabhakar.csengg@gmail.com>
>>>>> ---
>>>>> drivers/video/da8xx-fb.c | 39 +++++++--------------------------------
>>>>> 1 files changed, 7 insertions(+), 32 deletions(-)
>>>>
>>>> There's something similar in Darren's da8xx-fb series. Can you check if
>>>> there are differences?
>>>>
>>> I don't see similar changes in his patch series.
>>
>> [PATCH 14/23] video: da8xx-fb: use devres
>>
> Oops missed it out :), patch is almost similar except
> for following block,
>
> - fb_clk = clk_get(&device->dev, "fck");
> + fb_clk = devm_clk_get(&device->dev, "fck");
> if (IS_ERR(fb_clk)) {
> dev_err(&device->dev, "Can not get device clock\n");
> - ret = -ENODEV;
> - goto err_ioremap;
> + return -ENODEV;
> }
>
> How do you suggest to handle it ?
I think it's easiest if Darren handles the da8xx-fb series for 3.11. So
if there's something missing from Darren's series, please discuss with him.
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 901 bytes --]
^ permalink raw reply
* Re: [PATCH 2/2 v2] fb: fix atyfb unused data warnings
From: Tomi Valkeinen @ 2013-06-26 12:15 UTC (permalink / raw)
To: Randy Dunlap
Cc: Jean-Christophe PLAGNIOL-VILLARD, LKML,
Linux Fbdev development list, Andrew Morton, Paul Mackerras,
Benjamin Herrenschmidt
In-Reply-To: <51C887CC.6000301@infradead.org>
[-- Attachment #1: Type: text/plain, Size: 549 bytes --]
On 24/06/13 20:54, Randy Dunlap wrote:
> From: Randy Dunlap <rdunlap@infradead.org>
>
> Fix compiler warnings of data defined but not used by using the
> __maybe_unused attribute. The date are only used with certain kconfig
> settings.
>
> drivers/video/aty/atyfb_base.c:534:13: warning: 'ram_dram' defined but not used [-Wunused-variable]
> drivers/video/aty/atyfb_base.c:535:13: warning: 'ram_resv' defined but not used [-Wunused-variable]
>
I've added this and the first patch in the series to my fbdev-3.11 branch.
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 901 bytes --]
^ permalink raw reply
* Re: [PATCH] uvesafb: Correct/simplify warning message
From: Tomi Valkeinen @ 2013-06-26 12:18 UTC (permalink / raw)
To: linux-fbdev
In-Reply-To: <1366380325-2038-1-git-send-email-bp@alien8.de>
[-- Attachment #1: Type: text/plain, Size: 1180 bytes --]
On 19/04/13 17:05, Borislav Petkov wrote:
> From: Borislav Petkov <bp@suse.de>
>
> Streamline it a bit. No functional change.
>
> Signed-off-by: Borislav Petkov <bp@suse.de>
> Cc: Wang YanQing <udknight@gmail.com>
> Cc: Michal Januszewski <spock@gentoo.org>
> Cc: Florian Tobias Schandinat <FlorianSchandinat@gmx.de>
> Cc: linux-fbdev@vger.kernel.org
> ---
> drivers/video/uvesafb.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/video/uvesafb.c b/drivers/video/uvesafb.c
> index d4284458377e..a309f9fabe8b 100644
> --- a/drivers/video/uvesafb.c
> +++ b/drivers/video/uvesafb.c
> @@ -819,8 +819,8 @@ static int uvesafb_vbe_init(struct fb_info *info)
> if (par->pmi_setpal || par->ypan) {
> if (__supported_pte_mask & _PAGE_NX) {
> par->pmi_setpal = par->ypan = 0;
> - printk(KERN_WARNING "uvesafb: NX protection is actively."
> - "We have better not to use the PMI.\n");
> + printk(KERN_WARNING "uvesafb: NX protection is active, "
> + "better not use the PMI.\n");
> } else {
> uvesafb_vbe_getpmi(task, par);
> }
>
I've added this to my fbdev-3.11 branch.
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 901 bytes --]
^ permalink raw reply
* Re: [PATCH 2/2] video:da8xx-fb: Convert to devm_* api
From: Prabhakar Lad @ 2013-06-26 12:18 UTC (permalink / raw)
To: Tomi Valkeinen
Cc: Etheridge, Darren, DLOS, LFBDEV, Florian Tobias Schandinat, LKML
In-Reply-To: <51CAD7E4.2000403@ti.com>
Hi Tomi,
On Wed, Jun 26, 2013 at 5:30 PM, Tomi Valkeinen <tomi.valkeinen@ti.com> wrote:
> On 26/06/13 14:56, Prabhakar Lad wrote:
>> Hi Tomi,
>>
>> On Wed, Jun 26, 2013 at 5:09 PM, Tomi Valkeinen <tomi.valkeinen@ti.com> wrote:
>>> On 16/05/13 10:10, Lad Prabhakar wrote:
>>>> From: Lad, Prabhakar <prabhakar.csengg@gmail.com>
>>>>
>>>> Use devm_ioremap_resource instead of reques_mem_region()/ioremap() and
>>>> devm_request_irq() instead of request_irq().
>>>>
>>>> This ensures more consistent error values and simplifies error paths.
>>>>
>>>> Signed-off-by: Lad, Prabhakar <prabhakar.csengg@gmail.com>
>>>> ---
>>>> drivers/video/da8xx-fb.c | 39 +++++++--------------------------------
>>>> 1 files changed, 7 insertions(+), 32 deletions(-)
>>>
>>> There's something similar in Darren's da8xx-fb series. Can you check if
>>> there are differences?
>>>
>> I don't see similar changes in his patch series.
>
> [PATCH 14/23] video: da8xx-fb: use devres
>
Oops missed it out :), patch is almost similar except
for following block,
- fb_clk = clk_get(&device->dev, "fck");
+ fb_clk = devm_clk_get(&device->dev, "fck");
if (IS_ERR(fb_clk)) {
dev_err(&device->dev, "Can not get device clock\n");
- ret = -ENODEV;
- goto err_ioremap;
+ return -ENODEV;
}
How do you suggest to handle it ?
Regards,
--Prabhakar Lad
^ permalink raw reply
* Re: [PATCH] video: replace strict_strtoul() with kstrtoul()
From: Tomi Valkeinen @ 2013-06-26 12:20 UTC (permalink / raw)
To: linux-fbdev
In-Reply-To: <001401ce5e9a$03b485e0$0b1d91a0$@samsung.com>
[-- Attachment #1: Type: text/plain, Size: 512 bytes --]
On 01/06/13 10:31, Jingoo Han wrote:
> The usage of strict_strtoul() is not preferred, because
> strict_strtoul() is obsolete. Thus, kstrtoul() should be
> used.
>
> Signed-off-by: Jingoo Han <jg1.han@samsung.com>
> ---
> drivers/video/fsl-diu-fb.c | 4 ++--
> drivers/video/omap2/displays/panel-taal.c | 6 +++---
> drivers/video/wm8505fb.c | 2 +-
> 3 files changed, 6 insertions(+), 6 deletions(-)
I've added this to my fbdev-3.11 branch.
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 901 bytes --]
^ permalink raw reply
* Re: [PATCH v2 1/5] phy: Add driver for Exynos MIPI CSIS/DSIM DPHYs
From: Felipe Balbi @ 2013-06-26 12:22 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <51CAD89E.3060800@samsung.com>
[-- Attachment #1: Type: text/plain, Size: 1948 bytes --]
On Wed, Jun 26, 2013 at 02:03:42PM +0200, Sylwester Nawrocki wrote:
> On 06/26/2013 01:21 PM, Kishon Vijay Abraham I wrote:
> >>>>> +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);
> >>>> >>>
> >>>> >>> you can use platform_set_drvdata(pdev, state);
> >>> >>
> >>> >> I had it in the previous version, but changed for symmetry with
> >>> >> dev_set_drvdata(). I guess those could be replaced with
> >>> >> phy_{get, set}_drvdata as you suggested.
> >
> > right. currently I was setting dev_set_drvdata of phy (core) device
> > in phy-core.c and the corresponding dev_get_drvdata in phy provider driver
> > which is little confusing.
> > So I'll add phy_set_drvdata and phy_get_drvdata in phy.h (as suggested by
> > Felipe) to be used by phy provider drivers. So after creating the PHY, the
> > phy provider should use phy_set_drvdata and in phy_ops, it can use
> > phy_get_drvdata. (I'll remove the dev_set_drvdata in phy_create).
> >
> > This also means _void *priv_ in phy_create is useless. So I'll be removing
> > _priv_ from phy_create.
>
> Yeah, sounds good. Then in the phy ops phy_get_drvdata(&phy->dev) would
phy_get_drvdata(phy);
accessing the dev pointer will be done inside the helper :-)
--
balbi
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* Re: [PATCH v2 1/5] phy: Add driver for Exynos MIPI CSIS/DSIM DPHYs
From: Kishon Vijay Abraham I @ 2013-06-26 12:49 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <51CAD89E.3060800@samsung.com>
On Wednesday 26 June 2013 05:33 PM, Sylwester Nawrocki wrote:
> On 06/26/2013 01:21 PM, Kishon Vijay Abraham I wrote:
>>>>>> +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);
>>>>>>>>
>>>>>>>> you can use platform_set_drvdata(pdev, state);
>>>>>>
>>>>>> I had it in the previous version, but changed for symmetry with
>>>>>> dev_set_drvdata(). I guess those could be replaced with
>>>>>> phy_{get, set}_drvdata as you suggested.
>>
>> right. currently I was setting dev_set_drvdata of phy (core) device
>> in phy-core.c and the corresponding dev_get_drvdata in phy provider driver
>> which is little confusing.
>> So I'll add phy_set_drvdata and phy_get_drvdata in phy.h (as suggested by
>> Felipe) to be used by phy provider drivers. So after creating the PHY, the
>> phy provider should use phy_set_drvdata and in phy_ops, it can use
>> phy_get_drvdata. (I'll remove the dev_set_drvdata in phy_create).
>>
>> This also means _void *priv_ in phy_create is useless. So I'll be removing
>> _priv_ from phy_create.
>
> Yeah, sounds good. Then in the phy ops phy_get_drvdata(&phy->dev) would
> be used and in a custom of_xlate dev_get_drvdata(dev) (assuming the phy
> provider sets drvdata on its device beforehand).
thats correct. btw when you send the next version just have MODULE_LICENSE set
to GPL v2. Apart from that this patch looks good to me.
Thanks
Kishon
^ permalink raw reply
* Re: [PATCH v2 1/5] phy: Add driver for Exynos MIPI CSIS/DSIM DPHYs
From: Kishon Vijay Abraham I @ 2013-06-26 12:49 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20130626122238.GD12640@arwen.pp.htv.fi>
On Wednesday 26 June 2013 05:52 PM, Felipe Balbi wrote:
> On Wed, Jun 26, 2013 at 02:03:42PM +0200, Sylwester Nawrocki wrote:
>> On 06/26/2013 01:21 PM, Kishon Vijay Abraham I wrote:
>>>>>>> +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);
>>>>>>>>>
>>>>>>>>> you can use platform_set_drvdata(pdev, state);
>>>>>>>
>>>>>>> I had it in the previous version, but changed for symmetry with
>>>>>>> dev_set_drvdata(). I guess those could be replaced with
>>>>>>> phy_{get, set}_drvdata as you suggested.
>>>
>>> right. currently I was setting dev_set_drvdata of phy (core) device
>>> in phy-core.c and the corresponding dev_get_drvdata in phy provider driver
>>> which is little confusing.
>>> So I'll add phy_set_drvdata and phy_get_drvdata in phy.h (as suggested by
>>> Felipe) to be used by phy provider drivers. So after creating the PHY, the
>>> phy provider should use phy_set_drvdata and in phy_ops, it can use
>>> phy_get_drvdata. (I'll remove the dev_set_drvdata in phy_create).
>>>
>>> This also means _void *priv_ in phy_create is useless. So I'll be removing
>>> _priv_ from phy_create.
>>
>> Yeah, sounds good. Then in the phy ops phy_get_drvdata(&phy->dev) would
>
> phy_get_drvdata(phy);
>
> accessing the dev pointer will be done inside the helper :-)
right :-)
-Kishon
^ permalink raw reply
* Re: [PATCH v4 0/7] xilinxfb changes
From: Michal Simek @ 2013-06-26 12:51 UTC (permalink / raw)
To: Tomi Valkeinen
Cc: Arnd Bergmann, Jean-Christophe PLAGNIOL-VILLARD, Michal Simek,
linux-kernel, Timur Tabi, devicetree-discuss, linux-fbdev,
Grant Likely, Rob Herring
In-Reply-To: <51CAD385.8060400@ti.com>
[-- Attachment #1: Type: text/plain, Size: 1255 bytes --]
On 06/26/2013 01:41 PM, Tomi Valkeinen wrote:
> Hi,
>
> On 26/06/13 13:02, Michal Simek wrote:
>> On 06/17/2013 11:07 PM, Arnd Bergmann wrote:
>>> On Monday 17 June 2013, Michal Simek wrote:
>>>> On 06/17/2013 10:56 AM, Jean-Christophe PLAGNIOL-VILLARD wrote:
>>>>> On 07:23 Mon 17 Jun , Michal Simek wrote:
>>>>>> On 06/06/2013 06:23 PM, Jean-Christophe PLAGNIOL-VILLARD wrote:
>>>>>>> On 12:13 Mon 03 Jun , Michal Simek wrote:
>>>>>>>> Hi,
>>>>>>>>
>>>>>>>
>>>>>>> Arnd can you take look on it again please
>>>>>>>
>>>>>>> I'll take a look on it next week
>>>>>>
>>>>>> Any update on this?
>>>>> look ok but I want the Ack from Arnd
>>>
>>> Sorry for the delay, everything looks good to me.
>>>
>>> Acked-by: Arnd Bergmann <arnd@arndb.de>
>>
>> Jean-Christophe: Will you apply this series?
>> Or should I take it through my microblaze tree?
>
> I've added this to my fbdev-3.11 branch.
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] video: of_display_timing.h: Include <video/display_timing.h>
From: Tomi Valkeinen @ 2013-06-26 12:59 UTC (permalink / raw)
To: linux-fbdev
In-Reply-To: <1371476589-4660-1-git-send-email-fabio.estevam@freescale.com>
[-- Attachment #1: Type: text/plain, Size: 1241 bytes --]
On 17/06/13 16:43, Fabio Estevam wrote:
> Commit ffa3fd21de ("videomode: implement public of_get_display_timing()") causes
> the following build warning:
>
> include/video/of_display_timing.h:18:10: warning: 'struct display_timing' declared inside parameter list [enabled by default]
> include/video/of_display_timing.h:18:10: warning: its scope is only this definition or declaration, which is probably not what you want [enabled by default]
>
> As 'struct display_timing' is defined at <video/display_timing.h>, let's include
> this header to avoid the warning.
>
> Signed-off-by: Fabio Estevam <fabio.estevam@freescale.com>
> ---
> include/video/of_display_timing.h | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/include/video/of_display_timing.h b/include/video/of_display_timing.h
> index 6562ad9..a136f58 100644
> --- a/include/video/of_display_timing.h
> +++ b/include/video/of_display_timing.h
> @@ -8,6 +8,7 @@
>
> #ifndef __LINUX_OF_DISPLAY_TIMING_H
> #define __LINUX_OF_DISPLAY_TIMING_H
> +#include <video/display_timing.h>
>
> struct device_node;
> struct display_timings;
>
We don't need to include display_timing.h, we can just add:
struct display_timing;
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 901 bytes --]
^ permalink raw reply
* Re: [patch] fbmem: return -EFAULT on copy_to_user() failure
From: Tomi Valkeinen @ 2013-06-26 13:04 UTC (permalink / raw)
To: Dan Carpenter
Cc: Jean-Christophe Plagniol-Villard, linux-fbdev, linux-kernel,
kernel-janitors
In-Reply-To: <20130618070529.GA12329@elgon.mountain>
[-- Attachment #1: Type: text/plain, Size: 898 bytes --]
On 18/06/13 10:05, Dan Carpenter wrote:
> copy_to_user() returns the number of bytes remaining to be copied.
> put_user() returns -EFAULT on error.
>
> This function ORs a bunch of stuff together and returns jumbled non-zero
> values on error. It should return -EFAULT.
>
> Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
>
> diff --git a/drivers/video/fbmem.c b/drivers/video/fbmem.c
> index 098bfc6..9217be3 100644
> --- a/drivers/video/fbmem.c
> +++ b/drivers/video/fbmem.c
> @@ -1305,7 +1305,9 @@ static int do_fscreeninfo_to_user(struct fb_fix_screeninfo *fix,
> err |= copy_to_user(fix32->reserved, fix->reserved,
> sizeof(fix->reserved));
>
> - return err;
> + if (err)
> + return -EFAULT;
> + return 0;
> }
>
> static int fb_get_fscreeninfo(struct fb_info *info, unsigned int cmd,
I've added this to fbdev-3.11 branch.
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 901 bytes --]
^ permalink raw reply
* Re: [PATCH 9/9] radeon: use pdev->pm_cap instead of pci_find_capability(..,PCI_CAP_ID_PM)
From: Tomi Valkeinen @ 2013-06-26 13:15 UTC (permalink / raw)
To: Yijing Wang
Cc: Andrew Morton, linux-kernel, Benjamin Herrenschmidt,
Jean-Christophe Plagniol-Villard, linux-fbdev
In-Reply-To: <1372209221-16492-1-git-send-email-wangyijing@huawei.com>
[-- Attachment #1: Type: text/plain, Size: 1627 bytes --]
On 26/06/13 04:13, 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)
I couldn't find the rest of this series, and I'm not familiar with PCI.
So: is this patch and "aty128fb: use pdev->pm_cap instead of
pci_find_capability(..,PCI_CAP_ID_PM)" safe to apply for fbdev-3.11
without anything else? I.e. has the PCI core changes been merged in 3.10
or ealier?
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 901 bytes --]
^ permalink raw reply
* Re: [PATCH resend] fbdev: bfin-lq035q1-fb: Use dev_pm_ops
From: Tomi Valkeinen @ 2013-06-26 13:17 UTC (permalink / raw)
To: linux-fbdev
In-Reply-To: <1371746326-5087-1-git-send-email-lars@metafoo.de>
[-- Attachment #1: Type: text/plain, Size: 538 bytes --]
On 20/06/13 19:38, Lars-Peter Clausen wrote:
> Use dev_pm_ops instead of the legacy suspend/resume callbacks.
>
> Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
> Acked-by: Michael Hennerich <michael.hennerich@analog.com>
> ---
> Since Rafael said he won't take the pm_sleep_ops_ptr() macro, just a resend of
> the previous version of the patch.
> ---
> drivers/video/bfin-lq035q1-fb.c | 22 ++++++++++++++--------
> 1 file changed, 14 insertions(+), 8 deletions(-)
I've added this to fbdev-3.11 branch.
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 901 bytes --]
^ permalink raw reply
* Re: [PATCH linux-next] fb: make fp_get_options name argument const
From: Tomi Valkeinen @ 2013-06-26 13:21 UTC (permalink / raw)
To: Vincent Stehlé
Cc: linux-next, linux-fbdev, Jean-Christophe Plagniol-Villard,
Dave Airlie, trivial
In-Reply-To: <1371565386-23335-1-git-send-email-vincent.stehle@freescale.com>
[-- Attachment #1: Type: text/plain, Size: 1254 bytes --]
On 18/06/13 17:23, Vincent Stehlé wrote:
> drm_get_connector_name now returns a const value, which causes the following
> compilation warning:
>
> drivers/gpu/drm/drm_fb_helper.c: In function ‘drm_fb_helper_parse_command_line’:
> drivers/gpu/drm/drm_fb_helper.c:127:3: warning: passing argument 1 of ‘fb_get_options’ discards ‘const’ qualifier from pointer target type [enabled by default]
> In file included from drivers/gpu/drm/drm_fb_helper.c:35:0:
> include/linux/fb.h:627:12: note: expected ‘char *’ but argument is of type ‘const char *’
>
> As fb_get_options uses its name argument as read only, make it const. This
> fixes the aforementioned compilation warning.
>
> Signed-off-by: Vincent Stehlé <vincent.stehle@freescale.com>
> Cc: Jean-Christophe Plagniol-Villard <plagnioj@jcrosoft.com>
> Cc: Tomi Valkeinen <tomi.valkeinen@ti.com>
> Cc: Dave Airlie <airlied@redhat.com>
> Cc: trivial@kernel.org
> ---
>
>
> Hi,
>
> I remarked this warning while building linux-next with imx_v6_v7_defconfig.
> Is changing fb_get_options prototype "permitted", please?
I don't see how changing the parameter to const could break anything, so
I've applied this to fbdev-3.11 branch.
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 901 bytes --]
^ permalink raw reply
* [PATCH v2] video: of_display_timing.h: Declare 'display_timing'
From: Fabio Estevam @ 2013-06-26 13:34 UTC (permalink / raw)
To: linux-fbdev
Commit ffa3fd21de ("videomode: implement public of_get_display_timing()") causes
the following build warning:
include/video/of_display_timing.h:18:10: warning: 'struct display_timing' declared inside parameter list [enabled by default]
include/video/of_display_timing.h:18:10: warning: its scope is only this definition or declaration, which is probably not what you want [enabled by default]
Declare 'display_timing' to avoid the build warning.
Signed-off-by: Fabio Estevam <fabio.estevam@freescale.com>
---
Changes since v1:
- Add 'struct display_timing;' instead of '#include <video/display_timing.h>'
include/video/of_display_timing.h | 1 +
1 file changed, 1 insertion(+)
diff --git a/include/video/of_display_timing.h b/include/video/of_display_timing.h
index 6562ad9..79e6697 100644
--- a/include/video/of_display_timing.h
+++ b/include/video/of_display_timing.h
@@ -10,6 +10,7 @@
#define __LINUX_OF_DISPLAY_TIMING_H
struct device_node;
+struct display_timing;
struct display_timings;
#define OF_USE_NATIVE_MODE -1
--
1.8.1.2
^ permalink raw reply related
* Re: [PATCH v2] video: of_display_timing.h: Declare 'display_timing'
From: Tomi Valkeinen @ 2013-06-26 13:36 UTC (permalink / raw)
To: linux-fbdev
In-Reply-To: <1372253665-23148-1-git-send-email-fabio.estevam@freescale.com>
[-- Attachment #1: Type: text/plain, Size: 1223 bytes --]
On 26/06/13 16:34, Fabio Estevam wrote:
> Commit ffa3fd21de ("videomode: implement public of_get_display_timing()") causes
> the following build warning:
>
> include/video/of_display_timing.h:18:10: warning: 'struct display_timing' declared inside parameter list [enabled by default]
> include/video/of_display_timing.h:18:10: warning: its scope is only this definition or declaration, which is probably not what you want [enabled by default]
>
> Declare 'display_timing' to avoid the build warning.
>
> Signed-off-by: Fabio Estevam <fabio.estevam@freescale.com>
> ---
> Changes since v1:
> - Add 'struct display_timing;' instead of '#include <video/display_timing.h>'
> include/video/of_display_timing.h | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/include/video/of_display_timing.h b/include/video/of_display_timing.h
> index 6562ad9..79e6697 100644
> --- a/include/video/of_display_timing.h
> +++ b/include/video/of_display_timing.h
> @@ -10,6 +10,7 @@
> #define __LINUX_OF_DISPLAY_TIMING_H
>
> struct device_node;
> +struct display_timing;
> struct display_timings;
>
> #define OF_USE_NATIVE_MODE -1
>
Thanks. I've added this to fbdev-3.11 branch.
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 901 bytes --]
^ permalink raw reply
* Re: [PATCH v2 1/5] phy: Add driver for Exynos MIPI CSIS/DSIM DPHYs
From: Sylwester Nawrocki @ 2013-06-26 15:00 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20130625150649.GA21334@arwen.pp.htv.fi>
Hi,
On 06/25/2013 05:06 PM, Felipe Balbi wrote:
>> +static struct platform_driver exynos_video_phy_driver = {
>> > + .probe = exynos_video_phy_probe,
>
> you *must* provide a remove method. drivers with NULL remove are
> non-removable :-)
Actually the remove() callback can be NULL, it's just missing module_exit
function that makes a module not unloadable.
--
Regards,
Sylwester
^ permalink raw reply
* [PATCH v3 0/5] Generic PHY driver for the Exynos SoC MIPI CSI-2/DSI DPHYs
From: Sylwester Nawrocki @ 2013-06-26 15:02 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 CSIS) 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 now be dropped and
those drivers don't need any calls back to the platform code, which
makes migration to the device tree complete for MIPI CSIS.
Changes since v2:
- adapted to the generic PHY API v9: use phy_set/get_drvdata(),
- fixed of_xlate callback to return ERR_PTR() instead of NULL,
- namespace cleanup, put "GPL v2" as MODULE_LICENSE, removed pr_debug,
- removed phy id check in __set_phy_state().
Patches 2...3/5 are unchanged, description of patch 5/5 has been
updated.
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
[1] https://lkml.org/lkml/2013/6/26/259
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 the generic PHY driver
exynos4-is: Use the generic MIPI CSIS PHY driver
ARM: Samsung: Remove the 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 | 170 ++++++++++++++++++++
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, 233 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
* [PATCH v3 1/5] phy: Add driver for Exynos MIPI CSIS/DSIM DPHYs
From: Sylwester Nawrocki @ 2013-06-26 15:02 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1372258946-15607-1-git-send-email-s.nawrocki@samsung.com>
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 v2:
- adapted to the generic PHY API v9: use phy_set/get_drvdata(),
- fixed of_xlate callback to return ERR_PTR() instead of NULL,
- namespace cleanup, put "GPL v2" as MODULE_LICENSE, removed pr_debug,
- removed phy id check in __set_phy_state().
---
.../phy/samsung,s5pv210-mipi-video-phy.txt | 14 ++
drivers/phy/Kconfig | 9 ++
drivers/phy/Makefile | 3 +-
drivers/phy/phy-exynos-mipi-video.c | 170 ++++++++++++++++++++
4 files changed, 195 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..d0cd048
--- /dev/null
+++ b/drivers/phy/phy-exynos-mipi-video.c
@@ -0,0 +1,170 @@
+/*
+ * 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 exynos_mipi_phy_id {
+ EXYNOS_MIPI_PHY_ID_CSIS0,
+ EXYNOS_MIPI_PHY_ID_DSIM0,
+ EXYNOS_MIPI_PHY_ID_CSIS1,
+ EXYNOS_MIPI_PHY_ID_DSIM1,
+ EXYNOS_MIPI_PHYS_NUM
+};
+
+#define IS_EXYNOS_MIPI_DSIM_PHY_ID(id) \
+ ((id) = EXYNOS_MIPI_PHY_ID_DSIM0 || (id) = EXYNOS_MIPI_PHY_ID_DSIM0)
+
+struct exynos_mipi_video_phy {
+ spinlock_t slock;
+ struct phy *phys[EXYNOS_MIPI_PHYS_NUM];
+ void __iomem *regs;
+};
+
+static int __set_phy_state(struct exynos_mipi_video_phy *state,
+ enum exynos_mipi_phy_id id, unsigned int on)
+{
+ void __iomem *addr;
+ unsigned long flags;
+ u32 reg, reset;
+
+ addr = state->regs + EXYNOS_MIPI_PHY_CONTROL(id / 2);
+
+ if (IS_EXYNOS_MIPI_DSIM_PHY_ID(id))
+ 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);
+ return 0;
+}
+
+static int exynos_mipi_video_phy_power_on(struct phy *phy)
+{
+ struct exynos_mipi_video_phy *state = phy_get_drvdata(phy);
+ return __set_phy_state(state, phy->id, 1);
+}
+
+static int exynos_mipi_video_phy_power_off(struct phy *phy)
+{
+ struct exynos_mipi_video_phy *state = phy_get_drvdata(phy);
+ return __set_phy_state(state, phy->id, 0);
+}
+
+static struct phy *exynos_mipi_video_phy_xlate(struct device *dev,
+ struct of_phandle_args *args)
+{
+ struct exynos_mipi_video_phy *state = dev_get_drvdata(dev);
+
+ if (WARN_ON(args->args[0] > EXYNOS_MIPI_PHYS_NUM))
+ return ERR_PTR(-ENODEV);
+
+ return state->phys[args->args[0]];
+}
+
+static struct phy_ops exynos_mipi_video_phy_ops = {
+ .power_on = exynos_mipi_video_phy_power_on,
+ .power_off = exynos_mipi_video_phy_power_off,
+ .owner = THIS_MODULE,
+};
+
+static int exynos_mipi_video_phy_probe(struct platform_device *pdev)
+{
+ struct exynos_mipi_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_mipi_video_phy_xlate);
+ if (IS_ERR(phy_provider))
+ return PTR_ERR(phy_provider);
+
+ for (i = 0; i < EXYNOS_MIPI_PHYS_NUM; i++) {
+ char label[8];
+
+ snprintf(label, sizeof(label), "%s.%d",
+ IS_EXYNOS_MIPI_DSIM_PHY_ID(i) ?
+ "dsim" : "csis", i / 2);
+
+ state->phys[i] = devm_phy_create(dev, i,
+ &exynos_mipi_video_phy_ops, label);
+ if (IS_ERR(state->phys[i])) {
+ dev_err(dev, "failed to create PHY %s\n", label);
+ return PTR_ERR(state->phys[i]);
+ }
+ phy_set_drvdata(state->phys[i], state);
+ }
+
+ return 0;
+}
+
+static const struct of_device_id exynos_mipi_video_phy_of_match[] = {
+ { .compatible = "samsung,s5pv210-mipi-video-phy" },
+ { },
+};
+MODULE_DEVICE_TABLE(of, exynos_mipi_video_phy_of_match);
+
+static struct platform_driver exynos_mipi_video_phy_driver = {
+ .probe = exynos_mipi_video_phy_probe,
+ .driver = {
+ .of_match_table = exynos_mipi_video_phy_of_match,
+ .name = "exynos-mipi-video-phy",
+ .owner = THIS_MODULE,
+ }
+};
+module_platform_driver(exynos_mipi_video_phy_driver);
+
+MODULE_DESCRIPTION("Samsung S5P/EXYNOS SoC MIPI CSI-2/DSI PHY driver");
+MODULE_LICENSE("GPL v2");
+MODULE_AUTHOR("Sylwester Nawrocki <s.nawrocki@samsung.com>");
--
1.7.9.5
^ permalink raw reply related
* [PATCH v3 2/5] ARM: dts: Add MIPI PHY node to exynos4.dtsi
From: Sylwester Nawrocki @ 2013-06-26 15:02 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1372258946-15607-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 v3 3/5] video: exynos_mipi_dsim: Use the generic PHY driver
From: Sylwester Nawrocki @ 2013-06-26 15:02 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1372258946-15607-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>
Acked-by: Felipe Balbi <balbi@ti.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 v3 4/5] exynos4-is: Use the generic MIPI CSIS PHY driver
From: Sylwester Nawrocki @ 2013-06-26 15:02 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1372258946-15607-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>
Acked-by: Felipe Balbi <balbi@ti.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 v3 5/5] ARM: Samsung: Remove the MIPI PHY setup code
From: Sylwester Nawrocki @ 2013-06-26 15:02 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1372258946-15607-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 and
a platform device for the PHY provider should be defined.
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>
---
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
* Re: [RFC PATCH] dmabuf-sync: Introduce buffer synchronization framework
From: Inki Dae @ 2013-06-26 16:06 UTC (permalink / raw)
To: Jerome Glisse
Cc: Rob Clark, 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: <CAH3drwYqwddVuFRjDbYyvs+2hVWxsQDC1X8OCXMJURRty2087Q@mail.gmail.com>
2013/6/25 Jerome Glisse <j.glisse@gmail.com>:
> On Tue, Jun 25, 2013 at 10:17 AM, Inki Dae <daeinki@gmail.com> wrote:
>> 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".
>
> From memory, the motivation of dma-buf was to done for few use case,
> among them webcam capturing frame into a buffer and having gpu using
> it directly without memcpy, or one big gpu rendering a scene into a
> buffer that is then use by low power gpu for display ie it was done to
> allow different device to operate on same data using same backing
> memory.
>
> AFAICT you seem to want to use dma-buf to create scratch buffer, ie a
> process needs to use X amount of memory for an operation, it can
> release|free this memory once its done
> and a process B can the use
> this X memory for its own operation discarding content of process A.
> presume that next frame would have the sequence repeat, process A do
> something, then process B does its thing.
> So to me it sounds like you
> want to implement global scratch buffer using the dmabuf API and that
> sounds bad to me.
>
> I know most closed driver have several pool of memory, long lived
> object, short lived object and scratch space, then user space allocate
> from one of this pool and there is synchronization done by driver
> using driver specific API to reclaim memory.
> Of course this work
> nicely if you only talking about one logic block or at very least hw
> that have one memory controller.
>
> Now if you are thinking of doing scratch buffer for several different
> device and share the memory among then you need to be aware of
> security implication, most obvious being that you don't want process B
> being able to read process A scratch memory.
> I know the argument about
> it being graphic but one day this might become gpu code and it might
> be able to insert jump to malicious gpu code.
>
If you think so, it seems like that there is *definitely* your
misunderstanding. My approach is similar to dma fence: it guarantees
that a DMA cannot access a buffer while other DMA is accessing the
buffer. I guess now some gpu drivers in mainline have been using
specific mechanism for it. And when it comes to the portion you
commented, please know that I just introduced user side mechanism for
buffer sychronization between CPU and CPU, and CPU and DMA in
addition; not implemented but just planned.
Thanks,
Inki Dae
> Cheers,
> Jerome
^ permalink raw reply
* Re: [RFC PATCH v2] dmabuf-sync: Introduce buffer synchronization framework
From: Russell King - ARM Linux @ 2013-06-26 17:18 UTC (permalink / raw)
To: Daniel Vetter
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: <CAKMK7uEbkKWFcxu6zs+0P26S9aJrE5v2+b6Jzg7AhORsAg4+9w@mail.gmail.com>
On Tue, Jun 25, 2013 at 11:23:21AM +0200, Daniel Vetter wrote:
> 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?
Possibly not, but let's first look at that kind of scenario:
- It attaches to a dma_buf using dma_buf_attach()
- it maps the DMA buffer using dma_buf_map_attachment(). This does
dma_map_sg(). This possibly incurs a cache flush depending on the
coherence properties of the architecture.
- it then calls dma_buf_begin_cpu_access(). This presumably does a
dma_sync_sg_for_cpu(). This possibly incurs another cache flush
depending on the coherence properties of the architecture.
- then, presumably, it calls dma_buf_kmap_atomic() or dma_buf_kmap()
to gain a pointer to the buffer.
- at some point, dma_buf_kunmap_atomic() or dma_buf_kunmap() gets
called. On certain cache architectures, kunmap_atomic() results in
a cache flush.
- dma_buf_end_cpu_access() gets called, calling through presumably to
dma_sync_sg_for_device(). Possibly incurs a cache flush.
- dma_buf_unmap_attachment()... another cache flush.
Out of those all of those five cache flushes, the only cache flush which is
really necessary out of all those would be the one in kunmap_atomic(). The
rest of them are completely irrelevant to the CPU access provided that there
is no DMA access by the device. What's more is that you can't say "well,
the architecture should optimize them!" to which I'd respond "how does the
architecture know at dma_map_sg() time that there isn't going to be a
DMA access?"
Now, if we say that it's not necessary to call dma_buf_map_attachment()..
dma_buf_unmap_attachment() around the calls to dma_buf_begin_cpu_access()..
dma_buf_end_cpu_access(), then how does dma_buf_begin_cpu_access() know
whether the DMA buffer has been dma_map_sg()'d? It's invalid to call
dma_sync_sg_for_cpu() on a buffer which has not been dma_map_sg()'d.
Bear in mind that dma_buf_begin_cpu_access() is passed only the
struct dma_buf and not the struct dma_buf_attachment *attach, there's
no hope for the begin_cpu_access() method to know which user of the
dma_buf is asking for this call, so you can't track any state there.
Thank you for pointing this out, I'm less impressed with this dma_buf
API now that I've looked deeper at those two interfaces, and even more
convinced it needs to be redesigned! :P
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox