* [PATCH linux-next] videomode: fix compilation warning
From: Vincent Stehlé @ 2013-06-27 12:34 UTC (permalink / raw)
To: linux-next, linux-fbdev, linux-kernel
Cc: Vincent Stehlé, Jean-Christophe Plagniol-Villard,
Tomi Valkeinen, trivial
Add missing include file to fix the following compilation warning:
In file included from drivers/video/wm8505fb.c:35:0:
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]
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: trivial@kernel.org
---
Hi,
This warning happens on linux-next tag next-20130627, for ARM multi_v7_defconfig.
Best regards,
V.
include/video/of_display_timing.h | 2 ++
1 file changed, 2 insertions(+)
diff --git a/include/video/of_display_timing.h b/include/video/of_display_timing.h
index 6562ad9..d43be98 100644
--- a/include/video/of_display_timing.h
+++ b/include/video/of_display_timing.h
@@ -9,6 +9,8 @@
#ifndef __LINUX_OF_DISPLAY_TIMING_H
#define __LINUX_OF_DISPLAY_TIMING_H
+#include <video/display_timing.h>
+
struct device_node;
struct display_timings;
--
1.7.10.4
^ permalink raw reply related
* RE: [PATCH v3 5/5] ARM: Samsung: Remove the MIPI PHY setup code
From: Kukjin Kim @ 2013-06-27 9:34 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1372258946-15607-6-git-send-email-s.nawrocki@samsung.com>
Sylwester Nawrocki wrote:
>
> 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
>
Looks good, please feel free to add my ack on this,
Acked-by: Kukjin Kim <kgene.kim@samsung.com>
Thanks,
- Kukjin
^ permalink raw reply
* [GIT PULL] various small fbdev changes for 3.11
From: Tomi Valkeinen @ 2013-06-27 9:03 UTC (permalink / raw)
To: linux-fbdev
[-- Attachment #1: Type: text/plain, Size: 4160 bytes --]
The following changes since commit ffa3fd21de8ab0db7962b612d4c6e17c0d88e9c2:
videomode: implement public of_get_display_timing() (2013-05-28 14:42:52 +0300)
are available in the git repository at:
git://gitorious.org/linux-omap-dss2/linux.git tags/fbdev-3.11-2
for you to fetch changes up to 464d8a54a0ca7827a2278e2122e5eb22462ae044:
video: i740fb: Make i740fb_init static (2013-06-27 11:57:30 +0300)
----------------------------------------------------------------
Various fbdev changes for 3.11
* xilinxfb updates
* Small cleanups and fixes to multiple drivers
----------------------------------------------------------------
Borislav Petkov (1):
uvesafb: Correct/simplify warning message
Dan Carpenter (1):
fbmem: return -EFAULT on copy_to_user() failure
Fabio Estevam (1):
video: of_display_timing.h: Declare 'display_timing'
Jingoo Han (2):
video: remove unnecessary platform_set_drvdata()
video: replace strict_strtoul() with kstrtoul()
Lars-Peter Clausen (1):
fbdev: bfin-lq035q1-fb: Use dev_pm_ops
Michal Simek (7):
video: xilinxfb: Fix OF probing on little-endian systems
video: xilinxfb: Do not name out_be32 in function name
video: xilinxfb: Rename PLB_ACCESS_FLAG to BUS_ACCESS_FLAG
video: xilinxfb: Use drvdata->regs_phys instead of physaddr
video: xilinxfb: Group bus initialization
video: xilinxfb: Add support for little endian accesses
video: xilinxfb: Use driver for Xilinx ARM Zynq
Randy Dunlap (2):
fb: fix atyfb build warning
fb: fix atyfb unused data warnings
Sachin Kamat (5):
video: smscufx: Use NULL instead of 0
video: udlfb: Use NULL instead of 0
video: udlfb: Make local symbol static
video: imxfb: Make local symbols static
video: i740fb: Make i740fb_init static
Tomi Valkeinen (1):
OMAPDSS: DPI: Fix wrong pixel clock limit
Wei Yongjun (1):
video: mxsfb: remove redundant dev_err call in mxsfb_probe()
Yijing Wang (2):
aty128fb: use pdev->pm_cap instead of pci_find_capability(..,PCI_CAP_ID_PM)
radeon: use pdev->pm_cap instead of pci_find_capability(..,PCI_CAP_ID_PM)
drivers/video/Kconfig | 2 +-
drivers/video/aty/aty128fb.c | 2 +-
drivers/video/aty/atyfb_base.c | 9 +-
drivers/video/aty/radeon_pm.c | 2 +-
drivers/video/au1100fb.c | 1 -
drivers/video/bf54x-lq043fb.c | 1 -
drivers/video/bfin-lq035q1-fb.c | 24 +++---
drivers/video/bfin-t350mcqb-fb.c | 2 -
drivers/video/ep93xx-fb.c | 2 -
drivers/video/fbmem.c | 4 +-
drivers/video/fsl-diu-fb.c | 4 +-
drivers/video/i740fb.c | 2 +-
drivers/video/imxfb.c | 7 +-
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 | 3 -
drivers/video/nuc900fb.c | 1 -
drivers/video/omap2/displays/panel-taal.c | 6 +-
drivers/video/omap2/dss/dpi.c | 4 +-
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/smscufx.c | 2 +-
drivers/video/tmiofb.c | 3 -
drivers/video/udlfb.c | 12 +--
drivers/video/uvesafb.c | 4 +-
drivers/video/vga16fb.c | 1 -
drivers/video/vt8500lcdfb.c | 1 -
drivers/video/wm8505fb.c | 2 +-
drivers/video/xilinxfb.c | 135 +++++++++++++++---------------
include/video/of_display_timing.h | 1 +
35 files changed, 113 insertions(+), 136 deletions(-)
[-- 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: Jean-Christophe PLAGNIOL-VILLARD @ 2013-06-27 8:51 UTC (permalink / raw)
To: Tomi Valkeinen
Cc: David Airlie, Vincent Stehlé, linux-next, linux-fbdev,
trivial
In-Reply-To: <51CBDC28.9080808@ti.com>
On 09:31 Thu 27 Jun , Tomi Valkeinen wrote:
> On 27/06/13 08:14, David Airlie wrote:
> >>>
> >>>
> >>> 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.
> >>
> >
> > Hi Tomi,
> >
> > What tree does Jean-Christophe PLAGNIOL-VILLARD control?
>
> git://git.kernel.org/pub/scm/linux/kernel/git/plagnioj/linux-fbdev.git
>
> > he said he merged the original patch to fix this from Ville, but I've no idea
> > where it ended up, so I just didn't merge it to drm-next at the time.
> >
> > Message-Id: <1370619787-15341-3-git-send-email-ville.syrjala@linux.intel.com>
> >
> > is the original properly attributed fix.
>
> Hmm, ok. He asked me to collect fbdev patches as he's been away, so I
> went through my inbox and picked up what's there. I can't see the patch
> from Ville in Jean-Christophe's tree.
>
> Jean-Christophe, have you taken that (and maybe other patches) but you
> haven't pushed them to the kernel.org tree?
Sorry get seek for few days and did not push my tree (too much tired)
I'm pushing it today
Best Regards,
J.
^ permalink raw reply
* Re: [PATCH v2 1/5] phy: Add driver for Exynos MIPI CSIS/DSIM DPHYs
From: Russell King - ARM Linux @ 2013-06-27 8:49 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20130627061713.GF15455@arwen.pp.htv.fi>
On Thu, Jun 27, 2013 at 09:17:13AM +0300, Felipe Balbi wrote:
> On Wed, Jun 26, 2013 at 05:00:34PM +0200, Sylwester Nawrocki wrote:
> > 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.
>
> look at the implementation of platform_drv_remove():
>
> 499 static int platform_drv_remove(struct device *_dev)
> 500 {
> 501 struct platform_driver *drv = to_platform_driver(_dev->driver);
> 502 struct platform_device *dev = to_platform_device(_dev);
> 503 int ret;
> 504
> 505 ret = drv->remove(dev);
> 506 if (ACPI_HANDLE(_dev))
> 507 acpi_dev_pm_detach(_dev, true);
> 508
> 509 return ret;
> 510 }
>
> that's not a conditional call right :-)
Wrong.
if (drv->remove)
drv->driver.remove = platform_drv_remove;
The function you quote will only be used if drv->remove is non-NULL.
You do not need to provide a remove method.
^ permalink raw reply
* Re: [PATCH 1/1] video: i740fb: Make i740fb_init static
From: Tomi Valkeinen @ 2013-06-27 8:48 UTC (permalink / raw)
To: linux-fbdev
In-Reply-To: <1372317317-4649-1-git-send-email-sachin.kamat@linaro.org>
[-- Attachment #1: Type: text/plain, Size: 799 bytes --]
On 27/06/13 10:15, Sachin Kamat wrote:
> i740fb_init is referenced only in this function. Make it static.
>
> Signed-off-by: Sachin Kamat <sachin.kamat@linaro.org>
> Cc: Tomi Valkeinen <tomi.valkeinen@ti.com>
> Cc: Ondrej Zary <linux@rainbow-software.org>
> ---
> drivers/video/i740fb.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/video/i740fb.c b/drivers/video/i740fb.c
> index cfd0c52e..6c48388 100644
> --- a/drivers/video/i740fb.c
> +++ b/drivers/video/i740fb.c
> @@ -1302,7 +1302,7 @@ static int __init i740fb_setup(char *options)
> }
> #endif
>
> -int __init i740fb_init(void)
> +static int __init i740fb_init(void)
> {
> #ifndef MODULE
> char *option = NULL;
>
Thanks, applied to fbdev-3.11 branch.
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 901 bytes --]
^ permalink raw reply
* Re: [PATCH v3 1/5] phy: Add driver for Exynos MIPI CSIS/DSIM DPHYs
From: Felipe Balbi @ 2013-06-27 8:40 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <51CBF9B8.70103@samsung.com>
[-- Attachment #1: Type: text/plain, Size: 814 bytes --]
On Thu, Jun 27, 2013 at 10:37:12AM +0200, Sylwester Nawrocki wrote:
> On 06/27/2013 09:52 AM, Felipe Balbi wrote:
> > On Wed, Jun 26, 2013 at 05:02:22PM +0200, Sylwester Nawrocki wrote:
> >> 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>
> >
> > Acked-by: Felipe Balbi <balbi@ti.com>
>
> Thank you for your review and ack!
>
> Just for the record, I have tested this driver as a loadable
> module on Exynos4412 TRATS2 board and it all worked fine for
> both the camera and display side.
Awesome dude :-) very cool, let's hope more users convert to Kishon's
generic phy layer :-)
--
balbi
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* Re: [PATCH v3 1/5] phy: Add driver for Exynos MIPI CSIS/DSIM DPHYs
From: Sylwester Nawrocki @ 2013-06-27 8:37 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20130627075223.GQ15455@arwen.pp.htv.fi>
On 06/27/2013 09:52 AM, Felipe Balbi wrote:
> On Wed, Jun 26, 2013 at 05:02:22PM +0200, Sylwester Nawrocki wrote:
>> 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>
>
> Acked-by: Felipe Balbi <balbi@ti.com>
Thank you for your review and ack!
Just for the record, I have tested this driver as a loadable
module on Exynos4412 TRATS2 board and it all worked fine for
both the camera and display side.
--
Regards,
Sylwester
^ permalink raw reply
* Re: [PATCH v3 2/5] ARM: dts: Add MIPI PHY node to exynos4.dtsi
From: Felipe Balbi @ 2013-06-27 7:52 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1372258946-15607-3-git-send-email-s.nawrocki@samsung.com>
[-- Attachment #1: Type: text/plain, Size: 313 bytes --]
On Wed, Jun 26, 2013 at 05:02:23PM +0200, Sylwester Nawrocki wrote:
> Add PHY provider node for the MIPI CSIS and MIPI DSIM PHYs.
>
> Signed-off-by: Sylwester Nawrocki <s.nawrocki@samsung.com>
> Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com>
Acked-by: Felipe Balbi <balbi@ti.com>
--
balbi
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* Re: [PATCH v3 1/5] phy: Add driver for Exynos MIPI CSIS/DSIM DPHYs
From: Felipe Balbi @ 2013-06-27 7:52 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1372258946-15607-2-git-send-email-s.nawrocki@samsung.com>
[-- Attachment #1: Type: text/plain, Size: 365 bytes --]
On Wed, Jun 26, 2013 at 05:02:22PM +0200, Sylwester Nawrocki wrote:
> 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>
Acked-by: Felipe Balbi <balbi@ti.com>
--
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: Felipe Balbi @ 2013-06-27 7:51 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <51CBEE23.4010402@samsung.com>
[-- Attachment #1: Type: text/plain, Size: 1504 bytes --]
On Thu, Jun 27, 2013 at 09:47:47AM +0200, Andrzej Hajda wrote:
> Hi Felipe,
>
> On 06/27/2013 08:17 AM, Felipe Balbi wrote:
> > On Wed, Jun 26, 2013 at 05:00:34PM +0200, Sylwester Nawrocki wrote:
> >> 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.
> >
> > look at the implementation of platform_drv_remove():
> >
> > 499 static int platform_drv_remove(struct device *_dev)
> > 500 {
> > 501 struct platform_driver *drv = to_platform_driver(_dev->driver);
> > 502 struct platform_device *dev = to_platform_device(_dev);
> > 503 int ret;
> > 504
> > 505 ret = drv->remove(dev);
> > 506 if (ACPI_HANDLE(_dev))
> > 507 acpi_dev_pm_detach(_dev, true);
> > 508
> > 509 return ret;
> > 510 }
> >
> > that's not a conditional call right :-)
>
> It is conditional, just condition check is in different place:
>
> int platform_driver_register(struct platform_driver *drv)
> {
> (...)
> if (drv->remove)
> drv->driver.remove = platform_drv_remove;
> (...)
> }
good point :-) thanks. I'll go ack your driver now
--
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: Andrzej Hajda @ 2013-06-27 7:47 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20130627061713.GF15455@arwen.pp.htv.fi>
Hi Felipe,
On 06/27/2013 08:17 AM, Felipe Balbi wrote:
> On Wed, Jun 26, 2013 at 05:00:34PM +0200, Sylwester Nawrocki wrote:
>> 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.
>
> look at the implementation of platform_drv_remove():
>
> 499 static int platform_drv_remove(struct device *_dev)
> 500 {
> 501 struct platform_driver *drv = to_platform_driver(_dev->driver);
> 502 struct platform_device *dev = to_platform_device(_dev);
> 503 int ret;
> 504
> 505 ret = drv->remove(dev);
> 506 if (ACPI_HANDLE(_dev))
> 507 acpi_dev_pm_detach(_dev, true);
> 508
> 509 return ret;
> 510 }
>
> that's not a conditional call right :-)
It is conditional, just condition check is in different place:
int platform_driver_register(struct platform_driver *drv)
{
(...)
if (drv->remove)
drv->driver.remove = platform_drv_remove;
(...)
}
Regards
Andrzej
>
>
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
>
^ permalink raw reply
* [PATCH 1/1] video: i740fb: Make i740fb_init static
From: Sachin Kamat @ 2013-06-27 7:27 UTC (permalink / raw)
To: linux-fbdev
i740fb_init is referenced only in this function. Make it static.
Signed-off-by: Sachin Kamat <sachin.kamat@linaro.org>
Cc: Tomi Valkeinen <tomi.valkeinen@ti.com>
Cc: Ondrej Zary <linux@rainbow-software.org>
---
drivers/video/i740fb.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/video/i740fb.c b/drivers/video/i740fb.c
index cfd0c52e..6c48388 100644
--- a/drivers/video/i740fb.c
+++ b/drivers/video/i740fb.c
@@ -1302,7 +1302,7 @@ static int __init i740fb_setup(char *options)
}
#endif
-int __init i740fb_init(void)
+static int __init i740fb_init(void)
{
#ifndef MODULE
char *option = NULL;
--
1.7.9.5
^ permalink raw reply related
* Re: [PATCH 9/9] radeon: use pdev->pm_cap instead of pci_find_capability(..,PCI_CAP_ID_PM)
From: Yijing Wang @ 2013-06-27 6:50 UTC (permalink / raw)
To: Tomi Valkeinen
Cc: Andrew Morton, linux-kernel, Benjamin Herrenschmidt,
Jean-Christophe Plagniol-Villard, linux-fbdev
In-Reply-To: <51CBDCE5.1020301@ti.com>
On 2013/6/27 14:34, Tomi Valkeinen wrote:
> On 27/06/13 04:51, Yijing Wang wrote:
>> On 2013/6/26 21:15, Tomi Valkeinen wrote:
>
>>> 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?
>>
>> Hi Tomi,
>> Thanks for your reply. Yes, it's safe, because PCI core has been use pdev->pm_cap to save
>> the pm capability offset already. And PCI core changes related this pm init code has been merged
>> long long ago(since year 2008). This series changes just to simplifier driver code about pm code.
>> It's not necessary to access pci device register to get pm cap again, drivers can use pci device pm_cap
>> member. and this series had no changes in PCI core. The rest of this series like for bnx2, bnx2x etc has
>> been tested and accepted by other subsystems.
>
> Ok, thanks. I'll apply the two patches to my fbdev-3.11 branch.
>
> Tomi
>
>
Thanks very much!
--
Thanks!
Yijing
^ 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-27 6:34 UTC (permalink / raw)
To: Yijing Wang
Cc: Andrew Morton, linux-kernel, Benjamin Herrenschmidt,
Jean-Christophe Plagniol-Villard, linux-fbdev
In-Reply-To: <51CB9ABC.20704@huawei.com>
[-- Attachment #1: Type: text/plain, Size: 1048 bytes --]
On 27/06/13 04:51, Yijing Wang wrote:
> On 2013/6/26 21:15, Tomi Valkeinen wrote:
>> 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?
>
> Hi Tomi,
> Thanks for your reply. Yes, it's safe, because PCI core has been use pdev->pm_cap to save
> the pm capability offset already. And PCI core changes related this pm init code has been merged
> long long ago(since year 2008). This series changes just to simplifier driver code about pm code.
> It's not necessary to access pci device register to get pm cap again, drivers can use pci device pm_cap
> member. and this series had no changes in PCI core. The rest of this series like for bnx2, bnx2x etc has
> been tested and accepted by other subsystems.
Ok, thanks. I'll apply the two patches to my 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-27 6:31 UTC (permalink / raw)
To: David Airlie
Cc: Vincent Stehlé, linux-next, linux-fbdev,
Jean-Christophe Plagniol-Villard, trivial
In-Reply-To: <1927037966.2377585.1372310085417.JavaMail.root@redhat.com>
[-- Attachment #1: Type: text/plain, Size: 1097 bytes --]
On 27/06/13 08:14, David Airlie wrote:
>>>
>>>
>>> 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.
>>
>
> Hi Tomi,
>
> What tree does Jean-Christophe PLAGNIOL-VILLARD control?
git://git.kernel.org/pub/scm/linux/kernel/git/plagnioj/linux-fbdev.git
> he said he merged the original patch to fix this from Ville, but I've no idea
> where it ended up, so I just didn't merge it to drm-next at the time.
>
> Message-Id: <1370619787-15341-3-git-send-email-ville.syrjala@linux.intel.com>
>
> is the original properly attributed fix.
Hmm, ok. He asked me to collect fbdev patches as he's been away, so I
went through my inbox and picked up what's there. I can't see the patch
from Ville in Jean-Christophe's tree.
Jean-Christophe, have you taken that (and maybe other patches) but you
haven't pushed them to the kernel.org tree?
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-27 6:17 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <51CB0212.3050103@samsung.com>
[-- Attachment #1: Type: text/plain, Size: 991 bytes --]
On Wed, Jun 26, 2013 at 05:00:34PM +0200, Sylwester Nawrocki wrote:
> 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.
look at the implementation of platform_drv_remove():
499 static int platform_drv_remove(struct device *_dev)
500 {
501 struct platform_driver *drv = to_platform_driver(_dev->driver);
502 struct platform_device *dev = to_platform_device(_dev);
503 int ret;
504
505 ret = drv->remove(dev);
506 if (ACPI_HANDLE(_dev))
507 acpi_dev_pm_detach(_dev, true);
508
509 return ret;
510 }
that's not a conditional call right :-)
--
balbi
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* Re: [PATCH linux-next] fb: make fp_get_options name argument const
From: David Airlie @ 2013-06-27 5:14 UTC (permalink / raw)
To: Tomi Valkeinen
Cc: Vincent Stehlé, linux-next, linux-fbdev,
Jean-Christophe Plagniol-Villard, trivial
In-Reply-To: <51CAEAD5.40601@ti.com>
> >
> >
> > 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.
>
Hi Tomi,
What tree does Jean-Christophe PLAGNIOL-VILLARD control?
he said he merged the original patch to fix this from Ville, but I've no idea
where it ended up, so I just didn't merge it to drm-next at the time.
Message-Id: <1370619787-15341-3-git-send-email-ville.syrjala@linux.intel.com>
is the original properly attributed fix.
Dave.
^ 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-27 1:51 UTC (permalink / raw)
To: Tomi Valkeinen
Cc: Andrew Morton, linux-kernel, Benjamin Herrenschmidt,
Jean-Christophe Plagniol-Villard, linux-fbdev
In-Reply-To: <51CAE967.7080704@ti.com>
On 2013/6/26 21:15, Tomi Valkeinen wrote:
> 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?
Hi Tomi,
Thanks for your reply. Yes, it's safe, because PCI core has been use pdev->pm_cap to save
the pm capability offset already. And PCI core changes related this pm init code has been merged
long long ago(since year 2008). This series changes just to simplifier driver code about pm code.
It's not necessary to access pci device register to get pm cap again, drivers can use pci device pm_cap
member. and this series had no changes in PCI core. The rest of this series like for bnx2, bnx2x etc has
been tested and accepted by other subsystems.
link:
https://patchwork.kernel.org/patch/2739861/
https://patchwork.kernel.org/patch/2739761/
https://patchwork.kernel.org/patch/2739771/
https://patchwork.kernel.org/patch/2739801/
Thanks!
Yijing
>
> Tomi
>
>
--
Thanks!
Yijing
^ permalink raw reply
* Re: [RFC 0/6] SimpleDRM Driver (was: dvbe driver)
From: Stephen Warren @ 2013-06-26 21:30 UTC (permalink / raw)
To: David Herrmann
Cc: dri-devel, linux-kernel, Dave Airlie, linux-fbdev, Stephen Warren,
Olof Johansson
In-Reply-To: <1372112849-670-1-git-send-email-dh.herrmann@gmail.com>
On 06/24/2013 04:27 PM, David Herrmann wrote:
> Hi
>
> This is my second revision of the dvbe driver. I renamed it to SimpleDRM to
> show the resemblence with the recently introduced simplefb.c fbdev driver. The
> driver is supposed to be the most basic DRM driver similar to efifb.c, vesafb.c,
> offb.c, simplefb.c, ...
> It provides a single virtual CRTC+encoder+connector and allows user-space to
> create one dumb-buffer at a time and attach it.
>
> The setup changed slightly. It no longer uses shadow buffers but instead maps
> the framebuffer directly into userspace. Furthermore, a new infrastructure is
> used to unload firmware drivers during real hardware drivers probe cycles. Only
> nouveau was changed to use it, yet.
>
> I still have an odd problem when unloading DRM drivers (not just SimpleDRM) with
> an fbdev fallback. If I call printk() directly after unregister_framebufer(), I
> get a NULL-deref somewhere in the VT layer (most times hide_cursor()). I haven't
> figured out exactly where that happens, but I am also very reluctant to spend
> more time debugging the VT layer.
I tested this on a Tegra ARM system, and it basically worked.
I have one question: With the simplefb driver, and console=tty1 on the
kernel command-line, I see both the penguins logo and Linux's boot
messages on the LCD panel that's hooked up through simplefb. However,
with simpledrm, I only see the penguins logo, but no boot messages. Is
that expected? How would I solve that if so?
Note: I needed to apply the following patch to get it to compile:
diff --git a/drivers/gpu/drm/simpledrm/simpledrm_fbdev.c
b/drivers/gpu/drm/simpledrm/simpledrm_fbdev.c
index 40a2696..39885c8 100644
--- a/drivers/gpu/drm/simpledrm/simpledrm_fbdev.c
+++ b/drivers/gpu/drm/simpledrm/simpledrm_fbdev.c
@@ -159,7 +159,7 @@ void sdrm_fbdev_cleanup(struct sdrm_device *sdrm)
{
struct fb_info *info;
- if (!sdrm->info)
+ if (!sdrm->fbdev)
return;
dev_info(sdrm->ddev->dev, "fbdev cleanup\n");
^ permalink raw reply related
* Re: [RFC 4/6] drm: simpledrm: add fbdev fallback support
From: Stephen Warren @ 2013-06-26 20:59 UTC (permalink / raw)
To: David Herrmann
Cc: dri-devel, linux-kernel, Dave Airlie, linux-fbdev, Stephen Warren,
Olof Johansson
In-Reply-To: <1372112849-670-5-git-send-email-dh.herrmann@gmail.com>
On 06/24/2013 04:27 PM, David Herrmann wrote:
> Create a simple fbdev device during SimpleDRM setup so legacy user-space
> and fbcon can use it.
>
> fbdev deletion is quite buggy. A unregister_framebuffer() call followed by
> a printk() causes NULL-derefs in hide_cursor() and other places in the VT
> layer. Hence, we leak the fbdev device currently to make the VT layer
> happy. This needs to be fixed soon! Otherwise, we need a "depends !VT"
> line for SimpleDRM.
> diff --git a/drivers/gpu/drm/simpledrm/Makefile b/drivers/gpu/drm/simpledrm/Makefile
> simpledrm-y := simpledrm_drv.o simpledrm_main.o simpledrm_mem.o
>
> +ifdef CONFIG_DRM_SIMPLEDRM_FBDEV
> + simpledrm-y += simpledrm_fbdev.o
> +endif
I think that's:
+ simpledrm-$(CONFIG_DRM_SIMPLEDRM_FBDEV) += simpledrm_fbdev.o
^ permalink raw reply
* Re: [RFC 3/6] drm: add SimpleDRM driver
From: Stephen Warren @ 2013-06-26 20:58 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 04:27 PM, David Herrmann wrote:
> The SimpleDRM driver binds to simple-framebuffer devices and provides a
> DRM/KMS API. It provides only a single CRTC+encoder+connector combination
> plus one initial mode.
>
> Userspace can create one dumb-buffer and attach it to the CRTC. Only if
> the buffer is destroyed, a new buffer can be created. The buffer is
> directly mapped into user-space, so we have only resources for a single
> buffer. Otherwise, shadow buffers plus damage-request would be needed.
> diff --git a/drivers/gpu/drm/simpledrm/Kconfig b/drivers/gpu/drm/simpledrm/Kconfig
> +config DRM_SIMPLEDRM
> + tristate "Simple firmware framebuffer DRM driver"
> + depends on DRM && !FB_SIMPLE
> + help
> + SimpleDRM can run on all systems with pre-initialized graphics
> + hardware. It uses a framebuffer that was initialized during
> + firmware boot. No page-flipping, modesetting or other advanced
> + features are available. However, other DRM drivers can be loaded
> + later and take over from SimpleDRM if they provide real hardware
> + support.
> +
> + SimpleDRM supports: "simple-framebuffer" DeviceTree objects, x86 VESA
> + BIOS Extensions (VBE), EFI framebuffers
DT objects, yes. I'm not sure it's quite true to say it actually
directly supports VBE or EFI FBs; it's more the code in patch 2/6 that
supports those. I guess this is a bit nit-picky of a distinction though.
> diff --git a/drivers/gpu/drm/simpledrm/simpledrm_drv.c b/drivers/gpu/drm/simpledrm/simpledrm_drv.c
> +static int parse_dt(struct platform_device *pdev,
> + struct simplefb_platform_data *mode)
> + strlcpy(mode->format, format, sizeof(mode->format));
Even here, I believe the DT data sticks around so just copying the
pointer should be safe. It'd be worth validating that for sure though.
I didn't review the DRM stuff here since I'm not at all familiar with DRM.
^ permalink raw reply
* Re: [RFC 2/6] x86: provide platform-devices for boot-framebuffers
From: Stephen Warren @ 2013-06-26 20:49 UTC (permalink / raw)
To: David Herrmann
Cc: dri-devel, linux-kernel, Dave Airlie, linux-fbdev, Stephen Warren,
Olof Johansson
In-Reply-To: <1372112849-670-3-git-send-email-dh.herrmann@gmail.com>
On 06/24/2013 04:27 PM, David Herrmann wrote:
> The current situation regarding boot-framebuffers (VGA, VESA/VBE, EFI) on
> x86 causes troubles when loading multiple fbdev drivers. The global
> "struct screen_info" does not provide any state-tracking about which
> drivers use the FBs. request_mem_region() theoretically works, but
> unfortunately vesafb/efifb ignore it due to quirks for broken boards.
>
> Avoid this by creating a "platform-framebuffer" device with a pointer
> to the "struct screen_info" as platform-data. Drivers can now create
> platform-drivers and the driver-core will refuse multiple drivers being
> active simultaneously.
>
> We keep the screen_info available for backwards-compatibility. Drivers
> can be converted in follow-up patches.
>
> Apart from "platform-framebuffer" devices, this also introduces a
> compatibility option for "simple-framebuffer" drivers which recently got
> introduced for OF based systems. If CONFIG_X86_SYSFB is selected, we
> try to match the screen_info against a simple-framebuffer supported
> format. If we succeed, we create a "simple-framebuffer" device instead
> of a platform-framebuffer.
> This allows to reuse the simplefb.c driver across architectures and also
> to introduce a SimpleDRM driver. There is no need to have vesafb.c,
> efifb.c, simplefb.c and more just to have architecture specific quirks
> in their setup-routines.
>
> Instead, we now move the architecture specific quirks into x86-setup and
> provide a generic simple-framebuffer. For backwards-compatibility (if
> strange formats are used), we still allow vesafb/efifb to be loaded
> simultaneously and pick up all remaining devices.
> diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
> +config X86_SYSFB
> + bool "Mark VGA/VBE/EFI FB as generic system framebuffer"
> + help
> + Firmwares often provide initial graphics framebuffers so the BIOS,
> + bootloader or kernel can show basic video-output during boot for
> + user-guidance and debugging. Historically, x86 used the VESA BIOS
> + Extensions and EFI-framebuffers for this, which are mostly limited
> + to x86. However, a generic system-framebuffer initialization emerged
> + recently on some non-x86 architectures.
After this patch has been in the kernel a while, that very last won't
really be true; simplefb won't have been introduced recently. Perhaps
just delete that one sentence?
> + This option, if enabled, marks VGA/VBE/EFI framebuffers as generic
> + framebuffers so the new generic system-framebuffer drivers can be
> + used on x86.
> +
> + This breaks any x86-only driver like efifb, vesafb, uvesafb, which
> + will not work if this is selected.
Doesn't that imply that some form of conflicts or depends ! statement
should be added here?
> diff --git a/arch/x86/kernel/Makefile b/arch/x86/kernel/Makefile
> +obj-y += sysfb.o
I suspect that should be obj-$(CONFIG_X86_SYSFB) += sysfb.o.
> diff --git a/arch/x86/kernel/sysfb.c b/arch/x86/kernel/sysfb.c
> +#ifdef CONFIG_X86_SYSFB
Rather than ifdef'ing the body of this file, why not create a dummy
static inline version of add_sysfb() and put that into a header file
that users include. There should be a header file to prototype the
function anyway. That way, you avoid all of the ifdefs and static inline
functions in this file.
> +static bool parse_mode(const struct screen_info *si,
> + struct simplefb_platform_data *mode)
> + strlcpy(mode->format, f->name, sizeof(mode->format));
Per my comments about the type of mode->format, I think that could just be:
mode->format = f->name;
... since formats[] (i.e. f) isn't initdata.
> +#else /* CONFIG_X86_SYSFB */
> +
> +static bool parse_mode(const struct screen_info *si,
> + struct simplefb_platform_data *mode)
> +{
> + return false;
> +}
> +
> +static int create_simplefb(const struct screen_info *si,
> + const struct simplefb_platform_data *mode)
> +{
> + return -EINVAL;
> +}
> +
> +#endif /* CONFIG_X86_SYSFB */
Following on from my ifdef comment above, I believe those versions of
those functions will always cause add_sysfb() to return -ENODEV, so you
may as well provide a static inline for add_sysfb() instead.
^ permalink raw reply
* Re: [RFC 1/6] fbdev: simplefb: add init through platform_data
From: Stephen Warren @ 2013-06-26 20:39 UTC (permalink / raw)
To: David Herrmann
Cc: dri-devel, linux-kernel, Dave Airlie, linux-fbdev, Stephen Warren,
Olof Johansson
In-Reply-To: <1372112849-670-2-git-send-email-dh.herrmann@gmail.com>
On 06/24/2013 04:27 PM, David Herrmann wrote:
> If we create proper platform-devices in x86 boot-code, we can use simplefb
> for VBE or EFI framebuffers, too. However, there is normally no OF support
> so we introduce a platform_data object so x86 boot-code can pass the
> paramaters via plain old platform-data.
>
> This also removes the OF dependency as it is not needed. The headers
> provide proper dummies for the case OF is disabled.
>
> Furthermore, we move the FORMAT-definitions to the common platform header
> so initialization code can use it to transform "struct screen_info" to
> the right format-name.
> diff --git a/include/linux/platform_data/simplefb.h b/include/linux/platform_data/simplefb.h
> +/* the framebuffer size and location is available as IORESOURCE_MEM */
> +struct simplefb_platform_data {
> + u32 width;
> + u32 height;
> + u32 stride;
> + char format[64];
> +};
Any reason not to make format:
const char *format;
You should be able to initialize that just as easily in platform code,
either as static data or at runtime, I think.
^ 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