* [PATCH V4 2/2] video: exynos_dp: device tree documentation
From: Ajay Kumar @ 2012-10-09 14:05 UTC (permalink / raw)
To: linux-samsung-soc, linux-fbdev, jg1.han, devicetree-discuss
Cc: FlorianSchandinat, sylvester.nawrocki, tomasz.figa, thomas.ab
In-Reply-To: <1349824101-32574-1-git-send-email-ajaykumar.rs@samsung.com>
Add documentation for the DT bindings in exynos display port driver.
Signed-off-by: Ajay Kumar <ajaykumar.rs@samsung.com>
---
.../devicetree/bindings/video/exynos_dp.txt | 83 ++++++++++++++++++++
1 files changed, 83 insertions(+), 0 deletions(-)
create mode 100644 Documentation/devicetree/bindings/video/exynos_dp.txt
diff --git a/Documentation/devicetree/bindings/video/exynos_dp.txt b/Documentation/devicetree/bindings/video/exynos_dp.txt
new file mode 100644
index 0000000..a021963
--- /dev/null
+++ b/Documentation/devicetree/bindings/video/exynos_dp.txt
@@ -0,0 +1,83 @@
+Exynos display port driver should configure the display port interface
+based on the type of panel connected to it.
+
+We use two nodes:
+ -dptx_phy node
+ -display-port-controller node
+
+For the dp-phy initialization, we use a dptx_phy node.
+Required properties for dptx_phy:
+ -compatible:
+ Should be "samsung,dp-phy".
+ -samsung,dptx_phy_reg:
+ Base address of DP PHY register.
+ -samsung,enable_mask:
+ The bit-mask used to enable/disable DP PHY.
+
+For the Panel initialization, we read data from display-port-controller node.
+Required properties for display-port-controller:
+ -compatible:
+ Should be "samsung,exynos5-dp".
+ -reg:
+ physical base address of the controller and length
+ of memory mapped region.
+ -interrupts:
+ Interrupt combiner values.
+ -interrupt-parent:
+ phandle to Interrupt combiner node.
+ -samsung,dp_phy:
+ phandle to dptx_phy node.
+ -samsung,color_space:
+ input video data format.
+ COLOR_RGB = 0, COLOR_YCBCR422 = 1, COLOR_YCBCR444 = 2
+ -samsung,dynamic_range:
+ dynamic range for input video data.
+ VESA = 0, CEA = 1
+ -samsung,ycbcr_coeff:
+ YCbCr co-efficients for input video.
+ COLOR_YCBCR601 = 0, COLOR_YCBCR709 = 1
+ -samsung,color_depth:
+ Number of bits per colour component.
+ COLOR_6 = 0, COLOR_8 = 1, COLOR_10 = 2, COLOR_12 = 3
+ -samsung,link_rate:
+ link rate supported by the panel.
+ LINK_RATE_1_62GBPS = 0x6, LINK_RATE_2_70GBPS = 0x0A
+ -samsung,lane_count:
+ number of lanes supported by the panel.
+ LANE_COUNT1 = 1, LANE_COUNT2 = 2, LANE_COUNT4 = 4
+ -samsung,interlaced:
+ Interlace scan mode.
+ Progressive if defined, Interlaced if not defined
+ -samsung,v_sync_polarity:
+ VSYNC polarity configuration.
+ High if defined, Low if not defined
+ -samsung,h_sync_polarity:
+ HSYNC polarity configuration.
+ High if defined, Low if not defined
+
+Example:
+
+SOC specific portion:
+ dptx_phy: dptx_phy@0x10040720 {
+ compatible = "samsung,dp-phy";
+ samsung,dptx_phy_reg = <0x10040720>;
+ samsung,enable_mask = <1>;
+ };
+
+ display-port-controller {
+ compatible = "samsung,exynos5-dp";
+ reg = <0x145B0000 0x10000>;
+ interrupts = <10 3>;
+ interrupt-parent = <&combiner>;
+ samsung,dp_phy = <&dptx_phy>;
+ };
+
+Board Specific portion:
+ display-port-controller {
+ samsung,color_space = <0>;
+ samsung,dynamic_range = <0>;
+ samsung,ycbcr_coeff = <0>;
+ samsung,color_depth = <1>;
+ samsung,link_rate = <0x0a>;
+ samsung,lane_count = <2>;
+ };
--
1.7.0.4
^ permalink raw reply related
* [PATCH v2 0/8] ARM: mostly harmless gcc warnings
From: Arnd Bergmann @ 2012-10-09 20:13 UTC (permalink / raw)
To: linux-arm-kernel
Most patches from the first time this was posted have been
adopted by a subsystem maintainer or were show to be obsolete.
Here are the remaining ones again.
I'm planning to submit those patches that are still necessary
by the time we have an -rc1 through the arm-soc tree, but
my preference is still to have them go through the subsystem
maintainers.
Olof: should we add it to for-next?
Arnd
Arnd Bergmann (8):
SCSI: ARM: ncr5380/oak uses no interrupts
SCSI: ARM: make fas216_dumpinfo function conditional
mm/slob: use min_t() to compare ARCH_SLAB_MINALIGN
USB: EHCI: mark ehci_orion_conf_mbus_windows __devinit
clk: don't mark clkdev_add_table as init
pcmcia: sharpsl: don't discard sharpsl_pcmcia_ops
video: mark nuc900fb_map_video_memory as __devinit
spi/s3c64xx: use correct dma_transfer_direction type
drivers/clk/clkdev.c | 2 +-
drivers/pcmcia/pxa2xx_sharpsl.c | 2 +-
drivers/scsi/arm/fas216.c | 2 +-
drivers/scsi/arm/oak.c | 1 +
drivers/spi/spi-s3c64xx.c | 2 +-
drivers/usb/host/ehci-orion.c | 2 +-
drivers/video/nuc900fb.c | 2 +-
mm/slob.c | 6 +++---
8 files changed, 10 insertions(+), 9 deletions(-)
--
1.7.10
Cc: "James E.J. Bottomley" <JBottomley@parallels.com>
Cc: Ben Dooks <ben-linux@fluff.org>
Cc: Dominik Brodowski <linux@dominikbrodowski.net>
Cc: Florian Tobias Schandinat <FlorianSchandinat@gmx.de>
Cc: Grant Likely <grant.likely@secretlab.ca>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Jochen Friedrich <jochen@scram.de>
Cc: Kukjin Kim <kgene.kim@samsung.com>
Cc: Mike Turquette <mturquette@linaro.org>
Cc: Pavel Machek <pavel@suse.cz>
Cc: Pekka Enberg <penberg@kernel.org>
Cc: Russell King <rmk+kernel@arm.linux.org.uk>
Cc: Wan ZongShun <mcuos.com@gmail.com>
Cc: linux-arm-kernel@lists.infradead.org
Cc: linux-fbdev@vger.kernel.org
Cc: linux-pcmcia@lists.infradead.org
Cc: linux-samsung-soc@vger.kernel.org
Cc: linux-scsi@vger.kernel.org
Cc: linux-usb@vger.kernel.org
Cc: spi-devel-general@lists.sourceforge.net
Cc: stable@vger.kernel.org
^ permalink raw reply
* [PATCH v2 7/8] video: mark nuc900fb_map_video_memory as __devinit
From: Arnd Bergmann @ 2012-10-09 20:13 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1349813638-4617-1-git-send-email-arnd@arndb.de>
nuc900fb_map_video_memory is called by an devinit function
that may be called at run-time, but the function itself is
marked __init and will be discarded after boot.
To avoid calling into a function that may have been overwritten,
mark nuc900fb_map_video_memory itself as __devinit.
Without this patch, building nuc950_defconfig results in:
WARNING: drivers/video/built-in.o(.devinit.text+0x26c): Section mismatch in reference from the function nuc900fb_probe() to the function .init.text:nuc900fb_map_video_memory()
The function __devinit nuc900fb_probe() references
a function __init nuc900fb_map_video_memory().
If nuc900fb_map_video_memory is only used by nuc900fb_probe then
annotate nuc900fb_map_video_memory with a matching annotation.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Cc: Wan ZongShun <mcuos.com@gmail.com>
Cc: Florian Tobias Schandinat <FlorianSchandinat@gmx.de>
Cc: linux-fbdev@vger.kernel.org
---
drivers/video/nuc900fb.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/video/nuc900fb.c b/drivers/video/nuc900fb.c
index e10f551..b31b12b 100644
--- a/drivers/video/nuc900fb.c
+++ b/drivers/video/nuc900fb.c
@@ -387,7 +387,7 @@ static int nuc900fb_init_registers(struct fb_info *info)
* The buffer should be a non-cached, non-buffered, memory region
* to allow palette and pixel writes without flushing the cache.
*/
-static int __init nuc900fb_map_video_memory(struct fb_info *info)
+static int __devinit nuc900fb_map_video_memory(struct fb_info *info)
{
struct nuc900fb_info *fbi = info->par;
dma_addr_t map_dma;
--
1.7.10
^ permalink raw reply related
* Re: [PATCHv2 1/3] OMAP: VRFB: convert vrfb to platform device
From: Kevin Hilman @ 2012-10-09 20:37 UTC (permalink / raw)
To: Tomi Valkeinen; +Cc: linux-omap, linux-fbdev, Tony Lindgren, Archit Taneja
In-Reply-To: <1349785827-27055-2-git-send-email-tomi.valkeinen@ti.com>
Hi Tomi,
Tomi Valkeinen <tomi.valkeinen@ti.com> writes:
> This patch converts vrfb library into a platform device, in an effort to
> remove omap dependencies.
>
> The platform device is registered in arch/arm/plat-omap/fb.c and
> assigned resources depending on whether running on omap2 or omap3.
>
> The vrfb driver will parse those resources and use them to access vrfb
> configuration registers and the vrfb virtual rotation areas.
>
> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
> Cc: Tony Lindgren <tony@atomide.com>
[...]
I was having a quick look at this for the context save/restore piece in
order to understand how this driver's context is being saved/restored.
Looking at mainline, I don't see where omap_vrfb_restore_context() is
being called currently. Am I missing something?
Kevin
^ permalink raw reply
* Re: [PATCH V4 2/2] video: exynos_dp: device tree documentation
From: Sylwester Nawrocki @ 2012-10-09 21:29 UTC (permalink / raw)
To: Ajay Kumar
Cc: linux-samsung-soc, linux-fbdev, jg1.han, devicetree-discuss,
FlorianSchandinat, sylvester.nawrocki, tomasz.figa, thomas.ab
In-Reply-To: <1349824101-32574-3-git-send-email-ajaykumar.rs@samsung.com>
Hi Ajay,
On 10/10/2012 01:08 AM, Ajay Kumar wrote:
> Add documentation for the DT bindings in exynos display port driver.
>
> Signed-off-by: Ajay Kumar<ajaykumar.rs@samsung.com>
> ---
> .../devicetree/bindings/video/exynos_dp.txt | 83 ++++++++++++++++++++
> 1 files changed, 83 insertions(+), 0 deletions(-)
> create mode 100644 Documentation/devicetree/bindings/video/exynos_dp.txt
>
> diff --git a/Documentation/devicetree/bindings/video/exynos_dp.txt b/Documentation/devicetree/bindings/video/exynos_dp.txt
> new file mode 100644
> index 0000000..a021963
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/video/exynos_dp.txt
> @@ -0,0 +1,83 @@
> +Exynos display port driver should configure the display port interface
> +based on the type of panel connected to it.
The bindings are supposed to describe devices, not drivers. So it
might be better to say:
"The Exynos display port interface should be configured based on the
type of panel connected to it."
From this documentation it is not clear which properties are required
and which are optional for each node.
I think, in the property names dashes should be used, rather than
underscores. Dashes are much more common among existing bindings.
> +We use two nodes:
> + -dptx_phy node
> + -display-port-controller node
> +
> +For the dp-phy initialization, we use a dptx_phy node.
> +Required properties for dptx_phy:
> + -compatible:
> + Should be "samsung,dp-phy".
Is there a separate dptx-phy driver that is being matched with this
compatible property ? Is the dptx-node going to be referenced by other
nodes than display-port-controller ? If not, then you could likely drop
the compatible property entirely and make the dptx-phy node a child
node of display-port-controller, i.e.
display-port-controller {
compatible = "samsung,exynos5-dp";
reg = <0x145b0000 0x10000>;
interrupts =<10 3>;
interrupt-parent =<&combiner>;
dptx-phy {
reg = <0x10040720>;
samsung,enable_mask = <1>;
};
};
Then the driver could just look for a child node named "dptx-phy" with
e.g. of_find_node_by_name().
> + -samsung,dptx_phy_reg:
I think it's fine to use just 'reg' instead of this vendor specific name.
> + Base address of DP PHY register.
> + -samsung,enable_mask:
> + The bit-mask used to enable/disable DP PHY.
> +
> +For the Panel initialization, we read data from display-port-controller node.
> +Required properties for display-port-controller:
> + -compatible:
> + Should be "samsung,exynos5-dp".
> + -reg:
> + physical base address of the controller and length
> + of memory mapped region.
> + -interrupts:
> + Interrupt combiner values.
> + -interrupt-parent:
> + phandle to Interrupt combiner node.
> + -samsung,dp_phy:
> + phandle to dptx_phy node.
> + -samsung,color_space:
> + input video data format.
> + COLOR_RGB = 0, COLOR_YCBCR422 = 1, COLOR_YCBCR444 = 2
> + -samsung,dynamic_range:
> + dynamic range for input video data.
> + VESA = 0, CEA = 1
> + -samsung,ycbcr_coeff:
> + YCbCr co-efficients for input video.
> + COLOR_YCBCR601 = 0, COLOR_YCBCR709 = 1
> + -samsung,color_depth:
> + Number of bits per colour component.
> + COLOR_6 = 0, COLOR_8 = 1, COLOR_10 = 2, COLOR_12 = 3
> + -samsung,link_rate:
> + link rate supported by the panel.
> + LINK_RATE_1_62GBPS = 0x6, LINK_RATE_2_70GBPS = 0x0A
> + -samsung,lane_count:
> + number of lanes supported by the panel.
> + LANE_COUNT1 = 1, LANE_COUNT2 = 2, LANE_COUNT4 = 4
> + -samsung,interlaced:
> + Interlace scan mode.
> + Progressive if defined, Interlaced if not defined
> + -samsung,v_sync_polarity:
> + VSYNC polarity configuration.
> + High if defined, Low if not defined
> + -samsung,h_sync_polarity:
> + HSYNC polarity configuration.
> + High if defined, Low if not defined
So there is no common video bindings for things like these two ?
In V4L2 we decided to use vsync-active, hsync-active [1], the video
timings bindings [2] use hsync-active-high, hsync-active-high boolean
properties. Perhaps it is worth to pick some of those standard
definitions and use instead of the vendor specific ones ?
> +
> +Example:
> +
> +SOC specific portion:
> + dptx_phy: dptx_phy@0x10040720 {
> + compatible = "samsung,dp-phy";
> + samsung,dptx_phy_reg =<0x10040720>;
reg = <0x10040720>;
> + samsung,enable_mask =<1>;
> + };
> +
> + display-port-controller {
> + compatible = "samsung,exynos5-dp";
> + reg =<0x145B0000 0x10000>;
I think lower case is preferred.
> + interrupts =<10 3>;
> + interrupt-parent =<&combiner>;
> + samsung,dp_phy =<&dptx_phy>;
> + };
> +
> +Board Specific portion:
> + display-port-controller {
> + samsung,color_space =<0>;
> + samsung,dynamic_range =<0>;
> + samsung,ycbcr_coeff =<0>;
> + samsung,color_depth =<1>;
> + samsung,link_rate =<0x0a>;
> + samsung,lane_count =<2>;
> + };
Thanks,
Sylwester
[1] http://www.mail-archive.com/linux-media@vger.kernel.org/msg52743.html
[2] http://www.mail-archive.com/linux-media@vger.kernel.org/msg53323.html
^ permalink raw reply
* Re: omap DSS cmdline resolution not working for HDMI?
From: Tony Lindgren @ 2012-10-09 21:54 UTC (permalink / raw)
To: Tomi Valkeinen; +Cc: linux-omap, linux-fbdev
In-Reply-To: <1349788010.2409.38.camel@deskari>
* Tomi Valkeinen <tomi.valkeinen@ti.com> [121009 06:08]:
> On Fri, 2012-10-05 at 09:43 -0700, Tony Lindgren wrote:
>
> > Looks like somehow also output_size won't change when changing
> > display output from DVI to HDMI.
> >
> > If I boot with DVI panel at 1600x1200, then try to switch to the
> > HDMI monitor with the following script:
> >
> > #!/bin/sh
> >
> > export dvi=display0
> > export hdmi=display1
> > export overlay=overlay0
> >
> > echo 0 > /sys/devices/platform/omapdss/$dvi/enabled
> > echo 1 > /sys/devices/platform/omapdss/$hdmi/enabled
> > echo "85500,1366/70/213/143,768/3/24/3" > /sys/devices/platform/omapdss/$hdmi/timings
> > echo 0 > /sys/devices/platform/omapdss/$overlay/enabled
> > echo tv > /sys/devices/platform/omapdss/$overlay/manager
> > #echo "1366,768" > /sys/devices/platform/omapdss/$overlay/output_size
> > echo 1 > /sys/devices/platform/omapdss/$overlay/enabled
> > cat /sys/devices/platform/omapdss/$hdmi/timings
> > cat /sys/devices/platform/omapdss/$overlay/output_size
> >
> > I get the following which may provide more clues:
> >
> > [64370.820312] omapdss DISPC error: SYNC_LOST on channel tv, restarting the output with video overlays dd
> > [64370.831024] omapdss OVERLAY error: overlay 0 horizontally not inside the display area (0 + 1600 >= 13)
> > [64370.840972] omapdss APPLY error: failed to enable manager 1: check_settings failed
> > [64370.849670] omapdss HDMI error: failed to power on device
> > [64370.855407] omapdss error: failed to power on
> > [64370.862487] omapdss OVERLAY error: overlay 0 horizontally not inside the display area (0 + 1600 >= 13)
> > [64370.872436] omapdss APPLY error: failed to enable manager 1: check_settings failed
> > [64370.880798] omapdss HDMI error: failed to power on device
> > [64370.886505] omapdss error: failed to power on
> > 85500,1366/70/213/143,768/3/24/3
> > 1600,1200
>
> Well, it's not that simple =). There are three things to consider:
>
> - Framebuffer in the sdram. It has xres and yres parameters.
> - Overlay, and it's input size (from fb) and output sizes (must fit into
> the display).
> - Display, which has certain size depending on video mode.
>
> Only VID overlays can have different input and output sizes, GFX overlay
> does not support scaling.
>
> In the script above you don't change the fb at all. You can do that with
> when the overlay is disabled, for example:
>
> fbset -xres 1366 -vxres 1366 -yres 768 -vyres 768
>
> But that only works if there's enough memory allocated for the
> framebuffer, but that is the case for you if the fb was bigger
> initially. Otherwise you need to set the new size
> with /sys/class/graphics/fb0/size before resizing the fb.
>
> And, of course, the framebuffer cannot be in use at that time by, for
> example, X.
Thanks for the explanation, I'll give that a try at some point.
> Yes, it's complex! I hope omapdrm will make all things simple, and we
> can forget omapfb. In hindsight, I should've designed omapfb to be much
> simpler, and only use gfx overlay. Making it support all overlays is a
> never ending source for problems and complexity.
Heh oh well it works reasonably for most cases I guess.
> > FYI, I'm also seeing the DVI monitor blank out on it's own for
> > about a second or so on regular basis every 10 minutes or so.
> > No idea what's causing that, maybe it's a reminder to take
> > a short break :)
>
> Well that's something different. I've recently done some testing with
> using DSI PLL for generating pixel clock, and I've seen unstabilities
> with that. But perhaps there's something else wrong also, even when
> using the PRCM for pix clock as in your case.
>
> Does your monitor ever report something like bad signal or such?
Yes I've seen that too, but that seems to be different issue and
I may have passed wrong timings in that case.
I guess the random blanking for a second or so could also be
an occastional bad timing. No warnings in that case on the monitor
though.
Regards,
Tony
^ permalink raw reply
* Re: [PATCH v2 7/8] video: mark nuc900fb_map_video_memory as __devinit
From: Wan ZongShun @ 2012-10-10 1:41 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1349813638-4617-8-git-send-email-arnd@arndb.de>
2012/10/10 Arnd Bergmann <arnd@arndb.de>:
> nuc900fb_map_video_memory is called by an devinit function
> that may be called at run-time, but the function itself is
> marked __init and will be discarded after boot.
>
> To avoid calling into a function that may have been overwritten,
> mark nuc900fb_map_video_memory itself as __devinit.
>
> Without this patch, building nuc950_defconfig results in:
>
> WARNING: drivers/video/built-in.o(.devinit.text+0x26c): Section mismatch in reference from the function nuc900fb_probe() to the function .init.text:nuc900fb_map_video_memory()
> The function __devinit nuc900fb_probe() references
> a function __init nuc900fb_map_video_memory().
> If nuc900fb_map_video_memory is only used by nuc900fb_probe then
> annotate nuc900fb_map_video_memory with a matching annotation.
>
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> Cc: Wan ZongShun <mcuos.com@gmail.com>
> Cc: Florian Tobias Schandinat <FlorianSchandinat@gmx.de>
> Cc: linux-fbdev@vger.kernel.org
Thanks for your patch.
Acked-by: Wan ZongShun <mcuos.com@gmail.com>
> ---
> drivers/video/nuc900fb.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/video/nuc900fb.c b/drivers/video/nuc900fb.c
> index e10f551..b31b12b 100644
> --- a/drivers/video/nuc900fb.c
> +++ b/drivers/video/nuc900fb.c
> @@ -387,7 +387,7 @@ static int nuc900fb_init_registers(struct fb_info *info)
> * The buffer should be a non-cached, non-buffered, memory region
> * to allow palette and pixel writes without flushing the cache.
> */
> -static int __init nuc900fb_map_video_memory(struct fb_info *info)
> +static int __devinit nuc900fb_map_video_memory(struct fb_info *info)
> {
> struct nuc900fb_info *fbi = info->par;
> dma_addr_t map_dma;
> --
> 1.7.10
>
--
Wan ZongShun.
www.mcuos.com
^ permalink raw reply
* Re: [PATCHv2 1/3] OMAP: VRFB: convert vrfb to platform device
From: Tomi Valkeinen @ 2012-10-10 4:07 UTC (permalink / raw)
To: Kevin Hilman; +Cc: linux-omap, linux-fbdev, Tony Lindgren, Archit Taneja
In-Reply-To: <87fw5n1iwh.fsf@deeprootsystems.com>
[-- Attachment #1: Type: text/plain, Size: 1692 bytes --]
On Tue, 2012-10-09 at 13:37 -0700, Kevin Hilman wrote:
> Hi Tomi,
>
> Tomi Valkeinen <tomi.valkeinen@ti.com> writes:
>
> > This patch converts vrfb library into a platform device, in an effort to
> > remove omap dependencies.
> >
> > The platform device is registered in arch/arm/plat-omap/fb.c and
> > assigned resources depending on whether running on omap2 or omap3.
> >
> > The vrfb driver will parse those resources and use them to access vrfb
> > configuration registers and the vrfb virtual rotation areas.
> >
> > Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
> > Cc: Tony Lindgren <tony@atomide.com>
>
> [...]
>
> I was having a quick look at this for the context save/restore piece in
> order to understand how this driver's context is being saved/restored.
>
> Looking at mainline, I don't see where omap_vrfb_restore_context() is
> being called currently. Am I missing something?
No, the driver is missing something. I noticed the same thing. It seems
ctx restore for vrfb has never been functional in mainline. I don't
really have any recollection if this was left out intentionally from
mainline (possibly because we didn't have a good way to handle it at
that point), or was it just a mistake.
Nobody has complained about it, though, so it can't be a major problem
=).
Vrfb is a platform device/driver after this patch. Do you see any
problem with handling the context restore in runtime PM's runtime_resume
callback? Hmm, I guess then we could have a problem if omapdss and
omapfb are resumed before vrfb.
Any way to manage the suspend/resume ordering of unrelated (i.e. no
parent/child relation) devices?
Tomi
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* Re: [PATCH] matroxfb: Convert struct i2c_msg initialization to C99 format
From: Jean Delvare @ 2012-10-10 9:05 UTC (permalink / raw)
To: Shubhrajyoti D
Cc: linux-fbdev-u79uwXL29TY76Z2rM5mHXA, FlorianSchandinat-Mmb7MZpHnFY,
linux-i2c-u79uwXL29TY76Z2rM5mHXA,
dmitry.torokhov-Re5JQEeQqe8AvxtiuMwx3w
In-Reply-To: <1349782668-9098-1-git-send-email-shubhrajyoti-l0cyMroinI0@public.gmane.org>
On Tue, 9 Oct 2012 17:07:48 +0530, Shubhrajyoti D wrote:
> Convert the struct i2c_msg initialization to C99 format. This makes
> maintaining and editing the code simpler. Also helps once other fields
> like transferred are added in future.
>
> Thanks to Julia Lawall <julia.lawall@lip6.fr> for automating the conversion
>
> Signed-off-by: Shubhrajyoti D <shubhrajyoti@ti.com>
> ---
> drivers/video/matrox/matroxfb_maven.c | 15 +++++++++++++--
> 1 files changed, 13 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/video/matrox/matroxfb_maven.c b/drivers/video/matrox/matroxfb_maven.c
> index 217678e..fb5c123 100644
> --- a/drivers/video/matrox/matroxfb_maven.c
> +++ b/drivers/video/matrox/matroxfb_maven.c
> @@ -137,8 +137,19 @@ static int* get_ctrl_ptr(struct maven_data* md, int idx) {
>
> static int maven_get_reg(struct i2c_client* c, char reg) {
> char dst;
> - struct i2c_msg msgs[] = {{ c->addr, I2C_M_REV_DIR_ADDR, sizeof(reg), ® },
> - { c->addr, I2C_M_RD | I2C_M_NOSTART, sizeof(dst), &dst }};
> + struct i2c_msg msgs[] = {{
> + .addr = c->addr,
> + .flags = I2C_M_REV_DIR_ADDR,
> + .len = sizeof(reg),
> + .buf = ®
> + },
> + {
> + .addr = c->addr,
> + .flags = I2C_M_RD | I2C_M_NOSTART,
> + .len = sizeof(dst),
> + .buf = &dst
> + }
I'd prefer clean indentation as you have in the previous patches.
> + };
> s32 err;
>
> err = i2c_transfer(c->adapter, msgs, 2);
Acked-by: Jean Delvare <khali@linux-fr.org>
--
Jean Delvare
^ permalink raw reply
* [PATCH V5 4/5] OMAPDSS: Replace multi part debug prints with pr_debug
From: Chandrabhanu Mahapatra @ 2012-10-10 9:34 UTC (permalink / raw)
To: tomi.valkeinen; +Cc: linux-omap, linux-fbdev, Chandrabhanu Mahapatra
In-Reply-To: <8fb0b3848f5d6148889f2b5160b8aa40e764f409.1348914940.git.cmahapatra@ti.com>
The various functions in dispc and dsi such as print_irq_status(),
print_irq_status_vc(), print_irq_status_cio() and _dsi_print_reset_status()
consist of a number of debug prints which need to be enabled all at once or none
at all. So, these debug prints in corresponding functions are replaced with one
dynamic debug enabled pr_debug() each.
Signed-off-by: Chandrabhanu Mahapatra <cmahapatra@ti.com>
---
Changes from V4 to V5:
* replaced prints in dsi functions print_irq_status, print_irq_status_vc() and
print_irq_status_cio() with single pr_debug()
* replaced macro VERBOSE_IRQ with static variable verbose_irq
drivers/video/omap2/dss/dispc.c | 32 +++-----
drivers/video/omap2/dss/dsi.c | 168 ++++++++++++++++++---------------------
2 files changed, 90 insertions(+), 110 deletions(-)
diff --git a/drivers/video/omap2/dss/dispc.c b/drivers/video/omap2/dss/dispc.c
index a173a94..67d9f3b 100644
--- a/drivers/video/omap2/dss/dispc.c
+++ b/drivers/video/omap2/dss/dispc.c
@@ -3675,26 +3675,20 @@ static void print_irq_status(u32 status)
if ((status & dispc.irq_error_mask) = 0)
return;
- printk(KERN_DEBUG "DISPC IRQ: 0x%x: ", status);
-
-#define PIS(x) \
- if (status & DISPC_IRQ_##x) \
- printk(#x " ");
- PIS(GFX_FIFO_UNDERFLOW);
- PIS(OCP_ERR);
- PIS(VID1_FIFO_UNDERFLOW);
- PIS(VID2_FIFO_UNDERFLOW);
- if (dss_feat_get_num_ovls() > 3)
- PIS(VID3_FIFO_UNDERFLOW);
- PIS(SYNC_LOST);
- PIS(SYNC_LOST_DIGIT);
- if (dss_has_feature(FEAT_MGR_LCD2))
- PIS(SYNC_LOST2);
- if (dss_has_feature(FEAT_MGR_LCD3))
- PIS(SYNC_LOST3);
+#define PIS(x) (status & DISPC_IRQ_##x) ? (#x " ") : ""
+
+ pr_debug("DISPC IRQ: 0x%x: %s%s%s%s%s%s%s%s%s\n",
+ status,
+ PIS(OCP_ERR),
+ PIS(GFX_FIFO_UNDERFLOW),
+ PIS(VID1_FIFO_UNDERFLOW),
+ PIS(VID2_FIFO_UNDERFLOW),
+ dss_feat_get_num_ovls() > 3 ? PIS(VID3_FIFO_UNDERFLOW) : "",
+ PIS(SYNC_LOST),
+ PIS(SYNC_LOST_DIGIT),
+ dss_has_feature(FEAT_MGR_LCD2) ? PIS(SYNC_LOST2) : "",
+ dss_has_feature(FEAT_MGR_LCD3) ? PIS(SYNC_LOST3) : "");
#undef PIS
-
- printk("\n");
}
#endif
diff --git a/drivers/video/omap2/dss/dsi.c b/drivers/video/omap2/dss/dsi.c
index b0345f3..19daee9 100644
--- a/drivers/video/omap2/dss/dsi.c
+++ b/drivers/video/omap2/dss/dsi.c
@@ -45,7 +45,6 @@
#include "dss.h"
#include "dss_features.h"
-/*#define VERBOSE_IRQ*/
#define DSI_CATCH_MISSING_TE
struct dsi_reg { u16 idx; };
@@ -526,42 +525,38 @@ static inline void dsi_perf_show(struct platform_device *dsidev,
}
#endif
+static int verbose_irq;
+
static void print_irq_status(u32 status)
{
if (status = 0)
return;
-#ifndef VERBOSE_IRQ
- if ((status & ~DSI_IRQ_CHANNEL_MASK) = 0)
+ if (!verbose_irq && (status & ~DSI_IRQ_CHANNEL_MASK) = 0)
return;
-#endif
- printk(KERN_DEBUG "DSI IRQ: 0x%x: ", status);
-#define PIS(x) \
- if (status & DSI_IRQ_##x) \
- printk(#x " ");
-#ifdef VERBOSE_IRQ
- PIS(VC0);
- PIS(VC1);
- PIS(VC2);
- PIS(VC3);
-#endif
- PIS(WAKEUP);
- PIS(RESYNC);
- PIS(PLL_LOCK);
- PIS(PLL_UNLOCK);
- PIS(PLL_RECALL);
- PIS(COMPLEXIO_ERR);
- PIS(HS_TX_TIMEOUT);
- PIS(LP_RX_TIMEOUT);
- PIS(TE_TRIGGER);
- PIS(ACK_TRIGGER);
- PIS(SYNC_LOST);
- PIS(LDO_POWER_GOOD);
- PIS(TA_TIMEOUT);
+#define PIS(x) (status & DSI_IRQ_##x) ? (#x " ") : ""
+
+ pr_debug("DSI IRQ: 0x%x: %s%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s\n",
+ status,
+ verbose_irq ? PIS(VC0) : "",
+ verbose_irq ? PIS(VC1) : "",
+ verbose_irq ? PIS(VC2) : "",
+ verbose_irq ? PIS(VC3) : "",
+ PIS(WAKEUP),
+ PIS(RESYNC),
+ PIS(PLL_LOCK),
+ PIS(PLL_UNLOCK),
+ PIS(PLL_RECALL),
+ PIS(COMPLEXIO_ERR),
+ PIS(HS_TX_TIMEOUT),
+ PIS(LP_RX_TIMEOUT),
+ PIS(TE_TRIGGER),
+ PIS(ACK_TRIGGER),
+ PIS(SYNC_LOST),
+ PIS(LDO_POWER_GOOD),
+ PIS(TA_TIMEOUT));
#undef PIS
-
- printk("\n");
}
static void print_irq_status_vc(int channel, u32 status)
@@ -569,28 +564,24 @@ static void print_irq_status_vc(int channel, u32 status)
if (status = 0)
return;
-#ifndef VERBOSE_IRQ
- if ((status & ~DSI_VC_IRQ_PACKET_SENT) = 0)
+ if (!verbose_irq && (status & ~DSI_VC_IRQ_PACKET_SENT) = 0)
return;
-#endif
- printk(KERN_DEBUG "DSI VC(%d) IRQ 0x%x: ", channel, status);
-#define PIS(x) \
- if (status & DSI_VC_IRQ_##x) \
- printk(#x " ");
- PIS(CS);
- PIS(ECC_CORR);
-#ifdef VERBOSE_IRQ
- PIS(PACKET_SENT);
-#endif
- PIS(FIFO_TX_OVF);
- PIS(FIFO_RX_OVF);
- PIS(BTA);
- PIS(ECC_NO_CORR);
- PIS(FIFO_TX_UDF);
- PIS(PP_BUSY_CHANGE);
+#define PIS(x) (status & DSI_VC_IRQ_##x) ? (#x " ") : ""
+
+ pr_debug("DSI VC(%d) IRQ 0x%x: %s%s%s%s%s%s%s%s%s\n",
+ channel,
+ status,
+ PIS(CS),
+ PIS(ECC_CORR),
+ PIS(ECC_NO_CORR),
+ verbose_irq ? PIS(PACKET_SENT) : "",
+ PIS(BTA),
+ PIS(FIFO_TX_OVF),
+ PIS(FIFO_RX_OVF),
+ PIS(FIFO_TX_UDF),
+ PIS(PP_BUSY_CHANGE));
#undef PIS
- printk("\n");
}
static void print_irq_status_cio(u32 status)
@@ -598,34 +589,31 @@ static void print_irq_status_cio(u32 status)
if (status = 0)
return;
- printk(KERN_DEBUG "DSI CIO IRQ 0x%x: ", status);
-
-#define PIS(x) \
- if (status & DSI_CIO_IRQ_##x) \
- printk(#x " ");
- PIS(ERRSYNCESC1);
- PIS(ERRSYNCESC2);
- PIS(ERRSYNCESC3);
- PIS(ERRESC1);
- PIS(ERRESC2);
- PIS(ERRESC3);
- PIS(ERRCONTROL1);
- PIS(ERRCONTROL2);
- PIS(ERRCONTROL3);
- PIS(STATEULPS1);
- PIS(STATEULPS2);
- PIS(STATEULPS3);
- PIS(ERRCONTENTIONLP0_1);
- PIS(ERRCONTENTIONLP1_1);
- PIS(ERRCONTENTIONLP0_2);
- PIS(ERRCONTENTIONLP1_2);
- PIS(ERRCONTENTIONLP0_3);
- PIS(ERRCONTENTIONLP1_3);
- PIS(ULPSACTIVENOT_ALL0);
- PIS(ULPSACTIVENOT_ALL1);
+#define PIS(x) (status & DSI_CIO_IRQ_##x) ? (#x " ") : ""
+
+ pr_debug("DSI CIO IRQ 0x%x: %s%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s\n",
+ status,
+ PIS(ERRSYNCESC1),
+ PIS(ERRSYNCESC2),
+ PIS(ERRSYNCESC3),
+ PIS(ERRESC1),
+ PIS(ERRESC2),
+ PIS(ERRESC3),
+ PIS(ERRCONTROL1),
+ PIS(ERRCONTROL2),
+ PIS(ERRCONTROL3),
+ PIS(STATEULPS1),
+ PIS(STATEULPS2),
+ PIS(STATEULPS3),
+ PIS(ERRCONTENTIONLP0_1),
+ PIS(ERRCONTENTIONLP1_1),
+ PIS(ERRCONTENTIONLP0_2),
+ PIS(ERRCONTENTIONLP1_2),
+ PIS(ERRCONTENTIONLP0_3),
+ PIS(ERRCONTENTIONLP1_3),
+ PIS(ULPSACTIVENOT_ALL0),
+ PIS(ULPSACTIVENOT_ALL1));
#undef PIS
-
- printk("\n");
}
#ifdef CONFIG_OMAP2_DSS_COLLECT_IRQ_STATS
@@ -1121,14 +1109,6 @@ static void _dsi_print_reset_status(struct platform_device *dsidev)
* I/O. */
l = dsi_read_reg(dsidev, DSI_DSIPHY_CFG5);
- printk(KERN_DEBUG "DSI resets: ");
-
- l = dsi_read_reg(dsidev, DSI_PLL_STATUS);
- printk("PLL (%d) ", FLD_GET(l, 0, 0));
-
- l = dsi_read_reg(dsidev, DSI_COMPLEXIO_CFG1);
- printk("CIO (%d) ", FLD_GET(l, 29, 29));
-
if (dss_has_feature(FEAT_DSI_REVERSE_TXCLKESC)) {
b0 = 28;
b1 = 27;
@@ -1139,14 +1119,20 @@ static void _dsi_print_reset_status(struct platform_device *dsidev)
b2 = 26;
}
- l = dsi_read_reg(dsidev, DSI_DSIPHY_CFG5);
- printk("PHY (%x%x%x, %d, %d, %d)\n",
- FLD_GET(l, b0, b0),
- FLD_GET(l, b1, b1),
- FLD_GET(l, b2, b2),
- FLD_GET(l, 29, 29),
- FLD_GET(l, 30, 30),
- FLD_GET(l, 31, 31));
+#define DSI_FLD_GET(fld, start, end)\
+ FLD_GET(dsi_read_reg(dsidev, DSI_##fld), start, end)
+
+ pr_debug("DSI resets: PLL (%d) CIO (%d) PHY (%x%x%x, %d, %d, %d)\n",
+ DSI_FLD_GET(PLL_STATUS, 0, 0),
+ DSI_FLD_GET(COMPLEXIO_CFG1, 29, 29),
+ DSI_FLD_GET(DSIPHY_CFG5, b0, b0),
+ DSI_FLD_GET(DSIPHY_CFG5, b1, b1),
+ DSI_FLD_GET(DSIPHY_CFG5, b2, b2),
+ DSI_FLD_GET(DSIPHY_CFG5, 29, 29),
+ DSI_FLD_GET(DSIPHY_CFG5, 30, 30),
+ DSI_FLD_GET(DSIPHY_CFG5, 31, 31));
+
+#undef DSI_FLD_GET
}
#else
#define _dsi_print_reset_status(x)
--
1.7.10
^ permalink raw reply related
* Re: [RFC PATCH 1/3] amba-clcd: Add Device Tree support to amba-clcd driver
From: Jon Medhurst (Tixy) @ 2012-10-10 10:13 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1348070666-9153-2-git-send-email-ryan.harkin@linaro.org>
On Wed, 2012-09-19 at 17:04 +0100, Ryan Harkin wrote:
> Add support to parse the display configuration from device tree.
>
> If the board does not provide platform specific functions in the struct
> clcd_board contained with the amba device info, then defaults are provided
> by the driver.
>
> The device tree configuration can either ask for a DMA setup or provide a
> framebuffer address to be remapped into the driver.
>
> Signed-off-by: Ryan Harkin <ryan.harkin@linaro.org>
> ---
<big snip>
> static int clcdfb_probe(struct amba_device *dev, const struct amba_id *id)
> {
> struct clcd_board *board = dev->dev.platform_data;
> struct clcd_fb *fb;
> int ret;
>
> +#ifdef CONFIG_OF
> + if (dev->dev.of_node) {
> + const __be32 *prop;
> + int len, na, ns;
> + phys_addr_t reg_base;
> +
> + na = of_n_addr_cells(dev->dev.of_node);
> + ns = of_n_size_cells(dev->dev.of_node);
> +
> + prop = of_get_property(dev->dev.of_node, "reg", &len);
> + if (WARN_ON(!prop || len < (na + ns) * sizeof(*prop)))
> + return -EINVAL;
> + reg_base = of_read_number(prop, na);
> +
> + if (dev->res.start != reg_base)
> + return -EINVAL;
When the motherboard CLCD is used, the CLCD node is under the iofga node
and has a reg value equal to the offset from the start of the iofgpa,
however dev->res.start holds the calculated address of the start of the
iofga region plus the offset of the clcd, this means that the above
check fails.
The question is, what is the purpose of this check? Can't we rely on the
value of dev->res.start being consistent with dev->dev.of_node and so
just drop all the above code from "const __be32 *prop" onwards?
--
Tixy
^ permalink raw reply
* Re: [PATCH V4 0/5] OMAPDSS: Enable dynamic debug printing
From: Sumit Semwal @ 2012-10-10 10:38 UTC (permalink / raw)
To: Tomi Valkeinen; +Cc: Chandrabhanu Mahapatra, linux-omap, linux-fbdev
In-Reply-To: <1349441191.5836.8.camel@deskari>
Tomi, Chandrabhanu,
On Friday 05 October 2012 06:16 PM, Tomi Valkeinen wrote:
> On Sat, 2012-09-29 at 16:19 +0530, Chandrabhanu Mahapatra wrote:
>> Hi everyone,
>> this patch series aims at cleaning up of DSS of printk()'s enabled with
>> dss_debug and replace them with generic dynamic debug printing.
>
> Except for the missing debug print conversions in dsi.c this looks good.
> Do you want me to apply the current series and you can send the dsi.c
> patch later, or do you want to fix the dsi.c also before I apply?
With the change for DSI, please feel free to add
Reviewed-by: Sumit Semwal <sumit.semwal@ti.com>
BR,
~Sumit.
>
> Tomi
>
^ permalink raw reply
* Re: [PATCH] matroxfb: Convert struct i2c_msg initialization to C99 format
From: Shubhrajyoti Datta @ 2012-10-10 11:45 UTC (permalink / raw)
To: Jean Delvare
Cc: Shubhrajyoti D, linux-fbdev-u79uwXL29TY76Z2rM5mHXA,
FlorianSchandinat-Mmb7MZpHnFY, linux-i2c-u79uwXL29TY76Z2rM5mHXA,
dmitry.torokhov-Re5JQEeQqe8AvxtiuMwx3w
In-Reply-To: <20121010110521.3981a23f-R0o5gVi9kd7kN2dkZ6Wm7A@public.gmane.org>
On Wed, Oct 10, 2012 at 2:35 PM, Jean Delvare <khali@linux-fr.org> wrote:
> On Tue, 9 Oct 2012 17:07:48 +0530, Shubhrajyoti D wrote:
Thanks updated patch below.
From 99073779197f5759a76e65c3f4ef2ad4e9c88eaf Mon Sep 17 00:00:00 2001
From: Shubhrajyoti D <shubhrajyoti@ti.com>
Date: Mon, 17 Sep 2012 21:19:32 +0530
Subject: [PATCHv2] matroxfb: Convert struct i2c_msg initialization to C99
format
Convert the struct i2c_msg initialization to C99 format. This makes
maintaining and editing the code simpler. Also helps once other fields
like transferred are added in future.
Thanks to Julia Lawall <julia.lawall@lip6.fr> for automating the conversion
Acked-by: Jean Delvare <khali@linux-fr.org>
Signed-off-by: Shubhrajyoti D <shubhrajyoti@ti.com>
---
drivers/video/matrox/matroxfb_maven.c | 16 ++++++++++++++--
1 files changed, 14 insertions(+), 2 deletions(-)
diff --git a/drivers/video/matrox/matroxfb_maven.c
b/drivers/video/matrox/matroxfb_maven.c
index 217678e..f66c34c 100644
--- a/drivers/video/matrox/matroxfb_maven.c
+++ b/drivers/video/matrox/matroxfb_maven.c
@@ -137,8 +137,20 @@ static int* get_ctrl_ptr(struct maven_data* md, int idx) {
static int maven_get_reg(struct i2c_client* c, char reg) {
char dst;
- struct i2c_msg msgs[] = {{ c->addr, I2C_M_REV_DIR_ADDR, sizeof(reg), ® },
- { c->addr, I2C_M_RD | I2C_M_NOSTART, sizeof(dst), &dst }};
+ struct i2c_msg msgs[] = {
+ {
+ .addr = c->addr,
+ .flags = I2C_M_REV_DIR_ADDR,
+ .len = sizeof(reg),
+ .buf = ®
+ },
+ {
+ .addr = c->addr,
+ .flags = I2C_M_RD | I2C_M_NOSTART,
+ .len = sizeof(dst),
+ .buf = &dst
+ }
+ };
s32 err;
err = i2c_transfer(c->adapter, msgs, 2);
--
1.7.5.4
^ permalink raw reply related
* Re: [PATCH RESEND] video/udlfb: fix line counting in fb_write
From: Florian Tobias Schandinat @ 2012-10-10 12:29 UTC (permalink / raw)
To: Alexander Holler; +Cc: linux-kernel, Bernie Thompson, linux-fbdev
In-Reply-To: <5029FA0D.1090107@ahsoftware.de>
On 08/14/2012 07:11 AM, Alexander Holler wrote:
> Line 0 and 1 were both written to line 0 (on the display) and all
> subsequent
> lines had an offset of -1. The result was that the last line on the display
> was never overwritten by writes to /dev/fbN.
>
> Cc: stable@vger.kernel.org
> Signed-off-by: Alexander Holler <holler@ahsoftware.de>
As Bernie agreed but didn't send me a pull request, I applied this one.
Though the formatting was screwed up and I had to fix it...
Best regards,
Florian Tobias Schandinat
> ---
> drivers/video/udlfb.c | 2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/drivers/video/udlfb.c b/drivers/video/udlfb.c
> index a159b63..85d8110 100644
> --- a/drivers/video/udlfb.c
> +++ b/drivers/video/udlfb.c
> @@ -647,7 +647,7 @@ static ssize_t dlfb_ops_write(struct fb_info *info,
> const char __user *buf,
> result = fb_sys_write(info, buf, count, ppos);
> if (result > 0) {
> - int start = max((int)(offset / info->fix.line_length) - 1, 0);
> + int start = max((int)(offset / info->fix.line_length), 0);
> int lines = min((u32)((result / info->fix.line_length) + 1),
> (u32)info->var.yres);
> -- 1.7.6.5
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-fbdev" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
^ permalink raw reply
* Re: [PATCH v2] da8xx-fb: add pm_runtime support
From: Florian Tobias Schandinat @ 2012-10-10 12:32 UTC (permalink / raw)
To: linux-fbdev
On 09/21/2012 03:50 PM, Manjunathappa, Prakash wrote:
> Add pm_runtime support to the da8xx-fb frame buffer driver.
>
> Signed-off-by: Manjunathappa, Prakash <prakash.pm@ti.com>
Applied.
Thanks,
Florian Tobias Schandinat
> ---
> Applies on top of patch "da8xx-fb: enable LCDC if FB is unblanked" under review.
> Since v1:
> Use pm_runtime_put_sync in PM suspend callback.
>
> drivers/video/da8xx-fb.c | 27 +++++++++++++--------------
> 1 files changed, 13 insertions(+), 14 deletions(-)
>
> diff --git a/drivers/video/da8xx-fb.c b/drivers/video/da8xx-fb.c
> index af2aa38..4280d23 100644
> --- a/drivers/video/da8xx-fb.c
> +++ b/drivers/video/da8xx-fb.c
> @@ -26,6 +26,7 @@
> #include <linux/device.h>
> #include <linux/platform_device.h>
> #include <linux/uaccess.h>
> +#include <linux/pm_runtime.h>
> #include <linux/interrupt.h>
> #include <linux/wait.h>
> #include <linux/clk.h>
> @@ -1037,8 +1038,8 @@ static int __devexit fb_remove(struct platform_device *dev)
> dma_free_coherent(NULL, par->vram_size, par->vram_virt,
> par->vram_phys);
> free_irq(par->irq, par);
> - clk_disable(par->lcdc_clk);
> - clk_put(par->lcdc_clk);
> + pm_runtime_put_sync(&dev->dev);
> + pm_runtime_disable(&dev->dev);
> framebuffer_release(info);
> iounmap((void __iomem *)da8xx_fb_reg_base);
> release_mem_region(lcdc_regs->start, resource_size(lcdc_regs));
> @@ -1272,9 +1273,9 @@ static int __devinit fb_probe(struct platform_device *device)
> ret = -ENODEV;
> goto err_ioremap;
> }
> - ret = clk_enable(fb_clk);
> - if (ret)
> - goto err_clk_put;
> +
> + pm_runtime_enable(&device->dev);
> + pm_runtime_get_sync(&device->dev);
>
> /* Determine LCD IP Version */
> switch (lcdc_read(LCD_PID_REG)) {
> @@ -1302,7 +1303,7 @@ static int __devinit fb_probe(struct platform_device *device)
> if (i = ARRAY_SIZE(known_lcd_panels)) {
> dev_err(&device->dev, "GLCD: No valid panel found\n");
> ret = -ENODEV;
> - goto err_clk_disable;
> + goto err_pm_runtime_disable;
> } else
> dev_info(&device->dev, "GLCD: Found %s panel\n",
> fb_pdata->type);
> @@ -1314,7 +1315,7 @@ static int __devinit fb_probe(struct platform_device *device)
> if (!da8xx_fb_info) {
> dev_dbg(&device->dev, "Memory allocation failed for fb_info\n");
> ret = -ENOMEM;
> - goto err_clk_disable;
> + goto err_pm_runtime_disable;
> }
>
> par = da8xx_fb_info->par;
> @@ -1476,11 +1477,9 @@ err_release_fb_mem:
> err_release_fb:
> framebuffer_release(da8xx_fb_info);
>
> -err_clk_disable:
> - clk_disable(fb_clk);
> -
> -err_clk_put:
> - clk_put(fb_clk);
> +err_pm_runtime_disable:
> + pm_runtime_put_sync(&device->dev);
> + pm_runtime_disable(&device->dev);
>
> err_ioremap:
> iounmap((void __iomem *)da8xx_fb_reg_base);
> @@ -1503,7 +1502,7 @@ static int fb_suspend(struct platform_device *dev, pm_message_t state)
>
> fb_set_suspend(info, 1);
> lcd_disable_raster(true);
> - clk_disable(par->lcdc_clk);
> + pm_runtime_put_sync(&dev->dev);
> console_unlock();
>
> return 0;
> @@ -1514,7 +1513,7 @@ static int fb_resume(struct platform_device *dev)
> struct da8xx_fb_par *par = info->par;
>
> console_lock();
> - clk_enable(par->lcdc_clk);
> + pm_runtime_get_sync(&dev->dev);
> if (par->blank = FB_BLANK_UNBLANK) {
> lcd_enable_raster();
>
^ permalink raw reply
* Re: [PATCH] da8xx-fb: save and restore LCDC context across suspend/resume cycle
From: Florian Tobias Schandinat @ 2012-10-10 12:33 UTC (permalink / raw)
To: linux-fbdev
On 09/25/2012 02:11 PM, Manjunathappa, Prakash wrote:
> Save and restore register context of LCDC respectively
> before suspend and after resume.
>
> Signed-off-by: Manjunathappa, Prakash <prakash.pm@ti.com>
Applied.
Thanks,
Florian Tobias Schandinat
> ---
> Applies on top of below patch under review:
> "da8xx-fb: add pm_runtime support"
> drivers/video/da8xx-fb.c | 65 ++++++++++++++++++++++++++++++++++++++++++++++
> 1 files changed, 65 insertions(+), 0 deletions(-)
>
> diff --git a/drivers/video/da8xx-fb.c b/drivers/video/da8xx-fb.c
> index 4280d23..65a11ef 100644
> --- a/drivers/video/da8xx-fb.c
> +++ b/drivers/video/da8xx-fb.c
> @@ -1491,6 +1491,69 @@ err_request_mem:
> }
>
> #ifdef CONFIG_PM
> +struct lcdc_context {
> + u32 clk_enable;
> + u32 ctrl;
> + u32 dma_ctrl;
> + u32 raster_timing_0;
> + u32 raster_timing_1;
> + u32 raster_timing_2;
> + u32 int_enable_set;
> + u32 dma_frm_buf_base_addr_0;
> + u32 dma_frm_buf_ceiling_addr_0;
> + u32 dma_frm_buf_base_addr_1;
> + u32 dma_frm_buf_ceiling_addr_1;
> + u32 raster_ctrl;
> +} reg_context;
> +
> +static void lcd_context_save(void)
> +{
> + if (lcd_revision = LCD_VERSION_2) {
> + reg_context.clk_enable = lcdc_read(LCD_CLK_ENABLE_REG);
> + reg_context.int_enable_set = lcdc_read(LCD_INT_ENABLE_SET_REG);
> + }
> +
> + reg_context.ctrl = lcdc_read(LCD_CTRL_REG);
> + reg_context.dma_ctrl = lcdc_read(LCD_DMA_CTRL_REG);
> + reg_context.raster_timing_0 = lcdc_read(LCD_RASTER_TIMING_0_REG);
> + reg_context.raster_timing_1 = lcdc_read(LCD_RASTER_TIMING_1_REG);
> + reg_context.raster_timing_2 = lcdc_read(LCD_RASTER_TIMING_2_REG);
> + reg_context.dma_frm_buf_base_addr_0 > + lcdc_read(LCD_DMA_FRM_BUF_BASE_ADDR_0_REG);
> + reg_context.dma_frm_buf_ceiling_addr_0 > + lcdc_read(LCD_DMA_FRM_BUF_CEILING_ADDR_0_REG);
> + reg_context.dma_frm_buf_base_addr_1 > + lcdc_read(LCD_DMA_FRM_BUF_BASE_ADDR_1_REG);
> + reg_context.dma_frm_buf_ceiling_addr_1 > + lcdc_read(LCD_DMA_FRM_BUF_CEILING_ADDR_1_REG);
> + reg_context.raster_ctrl = lcdc_read(LCD_RASTER_CTRL_REG);
> + return;
> +}
> +
> +static void lcd_context_restore(void)
> +{
> + if (lcd_revision = LCD_VERSION_2) {
> + lcdc_write(reg_context.clk_enable, LCD_CLK_ENABLE_REG);
> + lcdc_write(reg_context.int_enable_set, LCD_INT_ENABLE_SET_REG);
> + }
> +
> + lcdc_write(reg_context.ctrl, LCD_CTRL_REG);
> + lcdc_write(reg_context.dma_ctrl, LCD_DMA_CTRL_REG);
> + lcdc_write(reg_context.raster_timing_0, LCD_RASTER_TIMING_0_REG);
> + lcdc_write(reg_context.raster_timing_1, LCD_RASTER_TIMING_1_REG);
> + lcdc_write(reg_context.raster_timing_2, LCD_RASTER_TIMING_2_REG);
> + lcdc_write(reg_context.dma_frm_buf_base_addr_0,
> + LCD_DMA_FRM_BUF_BASE_ADDR_0_REG);
> + lcdc_write(reg_context.dma_frm_buf_ceiling_addr_0,
> + LCD_DMA_FRM_BUF_CEILING_ADDR_0_REG);
> + lcdc_write(reg_context.dma_frm_buf_base_addr_1,
> + LCD_DMA_FRM_BUF_BASE_ADDR_1_REG);
> + lcdc_write(reg_context.dma_frm_buf_ceiling_addr_1,
> + LCD_DMA_FRM_BUF_CEILING_ADDR_1_REG);
> + lcdc_write(reg_context.raster_ctrl, LCD_RASTER_CTRL_REG);
> + return;
> +}
> +
> static int fb_suspend(struct platform_device *dev, pm_message_t state)
> {
> struct fb_info *info = platform_get_drvdata(dev);
> @@ -1502,6 +1565,7 @@ static int fb_suspend(struct platform_device *dev, pm_message_t state)
>
> fb_set_suspend(info, 1);
> lcd_disable_raster(true);
> + lcd_context_save();
> pm_runtime_put_sync(&dev->dev);
> console_unlock();
>
> @@ -1514,6 +1578,7 @@ static int fb_resume(struct platform_device *dev)
>
> console_lock();
> pm_runtime_get_sync(&dev->dev);
> + lcd_context_restore();
> if (par->blank = FB_BLANK_UNBLANK) {
> lcd_enable_raster();
>
^ permalink raw reply
* Re: [PATCH] video: s3c-fb: use clk_prepare_enable and clk_disable_unprepare
From: Florian Tobias Schandinat @ 2012-10-10 12:33 UTC (permalink / raw)
To: Thomas Abraham; +Cc: linux-fbdev, jg1.han, kgene.kim, linux-samsung-soc
In-Reply-To: <1349222260-3248-1-git-send-email-thomas.abraham@linaro.org>
On 10/02/2012 11:57 PM, Thomas Abraham wrote:
> Convert clk_enable/clk_disable to clk_prepare_enable/clk_disable_unprepare
> calls as required by common clock framework.
>
> Signed-off-by: Thomas Abraham <thomas.abraham@linaro.org>
Applied.
Thanks,
Florian Tobias Schandinat
> ---
> drivers/video/s3c-fb.c | 28 ++++++++++++++--------------
> 1 files changed, 14 insertions(+), 14 deletions(-)
>
> diff --git a/drivers/video/s3c-fb.c b/drivers/video/s3c-fb.c
> index 52b744f..2ed7b63 100644
> --- a/drivers/video/s3c-fb.c
> +++ b/drivers/video/s3c-fb.c
> @@ -1404,7 +1404,7 @@ static int __devinit s3c_fb_probe(struct platform_device *pdev)
> return PTR_ERR(sfb->bus_clk);
> }
>
> - clk_enable(sfb->bus_clk);
> + clk_prepare_enable(sfb->bus_clk);
>
> if (!sfb->variant.has_clksel) {
> sfb->lcd_clk = devm_clk_get(dev, "sclk_fimd");
> @@ -1414,7 +1414,7 @@ static int __devinit s3c_fb_probe(struct platform_device *pdev)
> goto err_bus_clk;
> }
>
> - clk_enable(sfb->lcd_clk);
> + clk_prepare_enable(sfb->lcd_clk);
> }
>
> pm_runtime_enable(sfb->dev);
> @@ -1504,10 +1504,10 @@ err_lcd_clk:
> pm_runtime_disable(sfb->dev);
>
> if (!sfb->variant.has_clksel)
> - clk_disable(sfb->lcd_clk);
> + clk_disable_unprepare(sfb->lcd_clk);
>
> err_bus_clk:
> - clk_disable(sfb->bus_clk);
> + clk_disable_unprepare(sfb->bus_clk);
>
> return ret;
> }
> @@ -1531,9 +1531,9 @@ static int __devexit s3c_fb_remove(struct platform_device *pdev)
> s3c_fb_release_win(sfb, sfb->windows[win]);
>
> if (!sfb->variant.has_clksel)
> - clk_disable(sfb->lcd_clk);
> + clk_disable_unprepare(sfb->lcd_clk);
>
> - clk_disable(sfb->bus_clk);
> + clk_disable_unprepare(sfb->bus_clk);
>
> pm_runtime_put_sync(sfb->dev);
> pm_runtime_disable(sfb->dev);
> @@ -1561,9 +1561,9 @@ static int s3c_fb_suspend(struct device *dev)
> }
>
> if (!sfb->variant.has_clksel)
> - clk_disable(sfb->lcd_clk);
> + clk_disable_unprepare(sfb->lcd_clk);
>
> - clk_disable(sfb->bus_clk);
> + clk_disable_unprepare(sfb->bus_clk);
>
> pm_runtime_put_sync(sfb->dev);
>
> @@ -1581,10 +1581,10 @@ static int s3c_fb_resume(struct device *dev)
>
> pm_runtime_get_sync(sfb->dev);
>
> - clk_enable(sfb->bus_clk);
> + clk_prepare_enable(sfb->bus_clk);
>
> if (!sfb->variant.has_clksel)
> - clk_enable(sfb->lcd_clk);
> + clk_prepare_enable(sfb->lcd_clk);
>
> /* setup gpio and output polarity controls */
> pd->setup_gpio();
> @@ -1640,9 +1640,9 @@ static int s3c_fb_runtime_suspend(struct device *dev)
> struct s3c_fb *sfb = platform_get_drvdata(pdev);
>
> if (!sfb->variant.has_clksel)
> - clk_disable(sfb->lcd_clk);
> + clk_disable_unprepare(sfb->lcd_clk);
>
> - clk_disable(sfb->bus_clk);
> + clk_disable_unprepare(sfb->bus_clk);
>
> return 0;
> }
> @@ -1653,10 +1653,10 @@ static int s3c_fb_runtime_resume(struct device *dev)
> struct s3c_fb *sfb = platform_get_drvdata(pdev);
> struct s3c_fb_platdata *pd = sfb->pdata;
>
> - clk_enable(sfb->bus_clk);
> + clk_prepare_enable(sfb->bus_clk);
>
> if (!sfb->variant.has_clksel)
> - clk_enable(sfb->lcd_clk);
> + clk_prepare_enable(sfb->lcd_clk);
>
> /* setup gpio and output polarity controls */
> pd->setup_gpio();
^ permalink raw reply
* Re: [PATCH 1/2] drivers/video/savage/savagefb_driver.c: fix error return code
From: Florian Tobias Schandinat @ 2012-10-10 12:34 UTC (permalink / raw)
To: Peter Senna Tschudin
Cc: Antonino Daplas, kernel-janitors, linux-fbdev, linux-kernel
In-Reply-To: <1349268044-32616-1-git-send-email-peter.senna@gmail.com>
On 10/03/2012 12:40 PM, Peter Senna Tschudin wrote:
> From: Peter Senna Tschudin <peter.senna@gmail.com>
>
> Convert a nonnegative error return code to a negative one, as returned
> elsewhere in the function.
>
> A simplified version of the semantic match that finds this problem is as
> follows: (http://coccinelle.lip6.fr/)
>
> // <smpl>
> (
> if@p1 (\(ret < 0\|ret != 0\))
> { ... return ret; }
> |
> ret@p1 = 0
> )
> ... when != ret = e1
> when != &ret
> *if(...)
> {
> ... when != ret = e2
> when forall
> return ret;
> }
> // </smpl>
>
>
> Signed-off-by: Peter Senna Tschudin <peter.senna@gmail.com>
Applied.
Thanks,
Florian Tobias Schandinat
>
> ---
> drivers/video/savage/savagefb_driver.c | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/video/savage/savagefb_driver.c b/drivers/video/savage/savagefb_driver.c
> index 0d0f52c..f4f53b0 100644
> --- a/drivers/video/savage/savagefb_driver.c
> +++ b/drivers/video/savage/savagefb_driver.c
> @@ -2266,8 +2266,10 @@ static int __devinit savagefb_probe(struct pci_dev* dev,
> lpitch = info->var.xres_virtual*((info->var.bits_per_pixel + 7) >> 3);
> info->var.yres_virtual = info->fix.smem_len/lpitch;
>
> - if (info->var.yres_virtual < info->var.yres)
> + if (info->var.yres_virtual < info->var.yres) {
> + err = -ENOMEM;
> goto failed;
> + }
>
> #if defined(CONFIG_FB_SAVAGE_ACCEL)
> /*
>
>
^ permalink raw reply
* Re: [PATCH 2/2] drivers/video/exynos/exynos_mipi_dsi.c: fix error return code
From: Florian Tobias Schandinat @ 2012-10-10 12:34 UTC (permalink / raw)
To: Peter Senna Tschudin
Cc: Inki Dae, kernel-janitors, Donghwa Lee, Kyungmin Park,
linux-fbdev, linux-kernel
In-Reply-To: <1349268044-32616-2-git-send-email-peter.senna@gmail.com>
On 10/03/2012 12:40 PM, Peter Senna Tschudin wrote:
> From: Peter Senna Tschudin <peter.senna@gmail.com>
>
> Convert a nonnegative error return code to a negative one, as returned
> elsewhere in the function.
>
> A simplified version of the semantic match that finds this problem is as
> follows: (http://coccinelle.lip6.fr/)
>
> // <smpl>
> (
> if@p1 (\(ret < 0\|ret != 0\))
> { ... return ret; }
> |
> ret@p1 = 0
> )
> ... when != ret = e1
> when != &ret
> *if(...)
> {
> ... when != ret = e2
> when forall
> return ret;
> }
> // </smpl>
>
>
> Signed-off-by: Peter Senna Tschudin <peter.senna@gmail.com>
Applied.
Thanks,
Florian Tobias Schandinat
>
> ---
> drivers/video/exynos/exynos_mipi_dsi.c | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/drivers/video/exynos/exynos_mipi_dsi.c b/drivers/video/exynos/exynos_mipi_dsi.c
> index c4f25de..07d70a3 100644
> --- a/drivers/video/exynos/exynos_mipi_dsi.c
> +++ b/drivers/video/exynos/exynos_mipi_dsi.c
> @@ -375,6 +375,7 @@ static int exynos_mipi_dsi_probe(struct platform_device *pdev)
> dsim->clock = clk_get(&pdev->dev, "dsim0");
> if (IS_ERR(dsim->clock)) {
> dev_err(&pdev->dev, "failed to get dsim clock source\n");
> + ret = -ENODEV;
> goto err_clock_get;
> }
>
> @@ -383,6 +384,7 @@ static int exynos_mipi_dsi_probe(struct platform_device *pdev)
> res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> if (!res) {
> dev_err(&pdev->dev, "failed to get io memory region\n");
> + ret = -ENODEV;
> goto err_platform_get;
> }
>
> @@ -407,6 +409,7 @@ static int exynos_mipi_dsi_probe(struct platform_device *pdev)
> dsim_ddi = exynos_mipi_dsi_bind_lcd_ddi(dsim, dsim_pd->lcd_panel_name);
> if (!dsim_ddi) {
> dev_err(&pdev->dev, "mipi_dsim_ddi object not found.\n");
> + ret = -EINVAL;
> goto err_bind;
> }
>
>
>
^ permalink raw reply
* Re: [PATCH] video: exynos_dp: use clk_prepare_enable and clk_disable_unprepare
From: Florian Tobias Schandinat @ 2012-10-10 12:35 UTC (permalink / raw)
To: Jingoo Han; +Cc: linux-fbdev, linux-samsung-soc, 'Thomas Abraham'
In-Reply-To: <006701cda1fb$cee12fe0$6ca38fa0$%han@samsung.com>
On 10/04/2012 06:45 AM, Jingoo Han wrote:
> Convert clk_enable/clk_disable to clk_prepare_enable/clk_disable_unprepare
> calls as required by common clock framework.
>
> Signed-off-by: Jingoo Han <jg1.han@samsung.com>
Applied.
Thanks,
Florian Tobias Schandinat
> ---
> drivers/video/exynos/exynos_dp_core.c | 8 ++++----
> 1 files changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/video/exynos/exynos_dp_core.c b/drivers/video/exynos/exynos_dp_core.c
> index cdc1398..d55470e 100644
> --- a/drivers/video/exynos/exynos_dp_core.c
> +++ b/drivers/video/exynos/exynos_dp_core.c
> @@ -885,7 +885,7 @@ static int __devinit exynos_dp_probe(struct platform_device *pdev)
> return PTR_ERR(dp->clock);
> }
>
> - clk_enable(dp->clock);
> + clk_prepare_enable(dp->clock);
>
> res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
>
> @@ -956,7 +956,7 @@ static int __devexit exynos_dp_remove(struct platform_device *pdev)
> if (pdata && pdata->phy_exit)
> pdata->phy_exit();
>
> - clk_disable(dp->clock);
> + clk_disable_unprepare(dp->clock);
>
> return 0;
> }
> @@ -971,7 +971,7 @@ static int exynos_dp_suspend(struct device *dev)
> if (pdata && pdata->phy_exit)
> pdata->phy_exit();
>
> - clk_disable(dp->clock);
> + clk_disable_unprepare(dp->clock);
>
> return 0;
> }
> @@ -985,7 +985,7 @@ static int exynos_dp_resume(struct device *dev)
> if (pdata && pdata->phy_init)
> pdata->phy_init();
>
> - clk_enable(dp->clock);
> + clk_prepare_enable(dp->clock);
>
> exynos_dp_init_dp(dp);
>
^ permalink raw reply
* Re: [PATCH] video/mx3fb: set .owner to prevent module unloading while being used
From: Florian Tobias Schandinat @ 2012-10-10 12:35 UTC (permalink / raw)
To: linux-fbdev
In-Reply-To: <1349428807-26373-1-git-send-email-u.kleine-koenig@pengutronix.de>
On 10/05/2012 09:20 AM, Uwe Kleine-König wrote:
> Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Applied.
Thanks,
Florian Tobias Schandinat
> ---
> drivers/video/mx3fb.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/video/mx3fb.c b/drivers/video/mx3fb.c
> index d738108..ce1d452 100644
> --- a/drivers/video/mx3fb.c
> +++ b/drivers/video/mx3fb.c
> @@ -1568,7 +1568,8 @@ static int mx3fb_remove(struct platform_device *dev)
>
> static struct platform_driver mx3fb_driver = {
> .driver = {
> - .name = MX3FB_NAME,
> + .name = MX3FB_NAME,
> + .owner = THIS_MODULE,
> },
> .probe = mx3fb_probe,
> .remove = mx3fb_remove,
^ permalink raw reply
* Re: [PATCH v2 7/8] video: mark nuc900fb_map_video_memory as __devinit
From: Florian Tobias Schandinat @ 2012-10-10 12:36 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1349813638-4617-8-git-send-email-arnd@arndb.de>
On 10/09/2012 08:13 PM, Arnd Bergmann wrote:
> nuc900fb_map_video_memory is called by an devinit function
> that may be called at run-time, but the function itself is
> marked __init and will be discarded after boot.
>
> To avoid calling into a function that may have been overwritten,
> mark nuc900fb_map_video_memory itself as __devinit.
>
> Without this patch, building nuc950_defconfig results in:
>
> WARNING: drivers/video/built-in.o(.devinit.text+0x26c): Section mismatch in reference from the function nuc900fb_probe() to the function .init.text:nuc900fb_map_video_memory()
> The function __devinit nuc900fb_probe() references
> a function __init nuc900fb_map_video_memory().
> If nuc900fb_map_video_memory is only used by nuc900fb_probe then
> annotate nuc900fb_map_video_memory with a matching annotation.
>
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> Cc: Wan ZongShun <mcuos.com@gmail.com>
> Cc: Florian Tobias Schandinat <FlorianSchandinat@gmx.de>
> Cc: linux-fbdev@vger.kernel.org
Applied.
Thanks,
Florian Tobias Schandinat
> ---
> drivers/video/nuc900fb.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/video/nuc900fb.c b/drivers/video/nuc900fb.c
> index e10f551..b31b12b 100644
> --- a/drivers/video/nuc900fb.c
> +++ b/drivers/video/nuc900fb.c
> @@ -387,7 +387,7 @@ static int nuc900fb_init_registers(struct fb_info *info)
> * The buffer should be a non-cached, non-buffered, memory region
> * to allow palette and pixel writes without flushing the cache.
> */
> -static int __init nuc900fb_map_video_memory(struct fb_info *info)
> +static int __devinit nuc900fb_map_video_memory(struct fb_info *info)
> {
> struct nuc900fb_info *fbi = info->par;
> dma_addr_t map_dma;
^ permalink raw reply
* Re: [GIT PULL] OMAP DSS for v3.7
From: Florian Tobias Schandinat @ 2012-10-10 12:48 UTC (permalink / raw)
To: Tomi Valkeinen; +Cc: linux-omap, linux-fbdev
In-Reply-To: <1349120714.13060.8.camel@lappyti>
Hi Tomi,
On 10/01/2012 07:45 PM, Tomi Valkeinen wrote:
> Hi Florian,
>
> Here are omapdss changes for 3.7 merge window.
Merged.
> There's something funny with the diff stat, though. I can see a few
> changes there that I have not made, for example to
> drivers/video/console/fbcon.c. I believe they come from my "Merge branch
> 'fbdev-for-linus' of git://github.com/schandinat/linux-2.6", although I
> don't know why they show up in the diff stat.
Yeah, I know this sort of stuff, had some similar problem some time ago,
it happens when you base on multiple branches. Basically you created
your pull request as if you asked Linus to pull it as you started with a
commit that is in Linus' tree (but not in mine). If you would take the
HEAD of my tree you wouldn't see the fb stuff but others as you merged
from Linus in the meantime.
> Merge with v3.6 goes without conflicts, but there will be some conflicts
> with OMAP platform stuff, at least according to linux-next reports.
> Those conflicts are trivial, though.
Good.
Thanks,
Florian Tobias Schandinat
>
> Tomi
>
> The following changes since commit 4cbe5a555fa58a79b6ecbb6c531b8bab0650778d:
>
> Linux 3.6-rc4 (2012-09-01 10:39:58 -0700)
>
> are available in the git repository at:
>
> git://gitorious.org/linux-omap-dss2/linux.git tags/omapdss-for-3.7
>
> for you to fetch changes up to 13b1ba7de8d0ecc42e4f9c002d5b0c1a48f05e58:
>
> OMAPDSS: add missing include for string.h (2012-09-28 10:03:03 +0300)
>
> ----------------------------------------------------------------
> Omapdss driver changes for the 3.7 merge window.
>
> Notable changes:
>
> * Basic writeback support for DISPC level. Writeback is not yet usable, though,
> as we need higher level code to actually expose the writeback feature to
> userspace.
> * Rewriting the omapdss output drivers. We're trying to remove the hard links
> between the omapdss and the panels, and this rewrite work moves us closer to
> that goal.
> * Cleanup and restructuring patches that have been made while working on device
> tree support for omapdss. Device tree support is still some way ahead, but
> these patches are good cleanups in themselves.
> * Basic OMAP5 DSS support for DPI and DSI outputs.
> * Workaround for the problem that GFX overlay's fifo is too small for high
> resolution scenarios, causing underflows.
> * Cleanups that remove dependencies to omap platform code.
>
> ----------------------------------------------------------------
> Archit Taneja (70):
> OMAPDSS: APPLY: Constify timings argument in dss_mgr_set_timings
> OMAPDSS: DPI: Add locking for DPI interface
> OMAPDSS: Displays: Add locking in generic DPI panel driver
> OMAPDSS: DPI: Maintain our own timings field in driver data
> OMAPDSS: DPI displays: Take care of panel timings in the driver itself
> OMAPDSS: DSI: Maintain own copy of timings in driver data
> OMAPDSS: DSI: Add function to set panel size for command mode panels
> OMAPDSS: DSI: Update manager timings on a manual update
> OMAPDSS: HDMI: Use our own omap_video_timings field when setting interface timings
> OMAPDSS: HDMI: Add locking for hdmi interface set timing functions
> OMAPDSS: SDI: Create a function to set timings
> OMAPDSS: SDI: Maintain our own timings field in driver data
> OMAPDSS: VENC: Split VENC into interface and panel driver
> OMAPDSS: VENC: Maintain our own timings field in driver data
> OMAPDSS: RFBI: Remove partial update support
> OMAPDSS: RFBI: Add function to set panel size
> OMAPDSS: DSI: Maintain copy of pixel format in driver data
> OMAPDSS: RFBI: Maintain copy of pixel size in driver data
> OMAPDSS: RFBI: Maintain copy of number of data lines in driver data
> OMAPDSS: DPI: Maintain copy of number of data lines in driver data
> OMAPDSS: SDI: Maintain copy of data pairs in driver data
> OMAPDSS: DSI: Maintain copy of operation mode in driver data
> OMAPDSS: DSI: Rename dsi_videomode_data to dsi_videomode_timings
> OMAPDSS: DSI: Maintain copy of video mode timings in driver data
> OMAPDSS: RFBI: Maitain copy of rfbi timings in driver data
> OMAPDSS: VENC: Maintain copy of venc type in driver data
> OMAPDSS: VENC: Maintian copy of video output polarity info in private data
> OMAPFB: Clear framebuffers before they are registered
> OMAPDSS: Add basic omap5 features to dss and dispc
> OMAPDSS: DSI: Pass dsi platform device wherever possible
> OMAPDSS: APPLY: Remove omap_dss_device references in wait_for_go functions
> OMAPDSS: outputs: Create a new entity called outputs
> OMAPDSS: outputs: Create and register output instances
> OMAPDSS: output: Add set/unset device ops for omap_dss_output
> OMAPDSS: APPLY: Add manager set/unset output ops for omap_overlay_manager
> OMAPDSS: Remove manager->device references
> OMAP_VOUT: Remove manager->device references
> OMAPFB: remove manager->device references
> OMAPDRM: Remove manager->device references
> OMAPDSS: Create links between managers, outputs and devices
> OMAPDSS: DPI: Replace dssdev->manager with dssdev->output->manager references
> OMAPDSS: DSI: Remove dsi_pdev_map global struct
> OMAPDSS: DSI: Replace dssdev->manager with dssdev->output->manager references
> OMAPDSS: SDI: Replace dssdev->manager with dssdev->output->manager references
> OMAPDSS: RFBI: Replace dssdev->manager with dssdev->output->manager references
> OMAPDSS: VENC: Replace dssdev->manager with dssdev->output->manager references
> OMAPDSS: HDMI: Replace dssdev->manager with dssdev->output->manager references
> OMAPFB: Change dssdev->manager references
> OMAPDSS: MANAGER: Update display sysfs store
> OMAPDSS: OVERLAY/MANAGER: Get device via output
> OMAPDSS: APPLY: Remove omap_dss_device references from dss_ovl_enable/disable
> OMAPDSS: Remove old way of setting manager and device links
> OMAPDSS: DISPC: Constify omap_overlay_info in dispc_ovl_setup()
> OMAPDSS: DISPC: Simplify function names for setting pipeline input and output sizes
> OMAPDSS: DISPC: Pass overlay caps as a parameter to dispc plane functions
> OMAPDSS: OVERLAY: Add position and replication as overlay caps
> OMAPDSS: DISPC: Make dispc_ovl_setup call dispc_ovl_setup_common
> OMAPDSS: DISPC: Don't pass channel out when configuring overlays
> OMAPDSS: DIPSC: Relax scaling limitations when in memory to memory mode
> OMAPDSS: DISPC: Allow both upscaling and downscaling of chroma
> OMAPDSS: DISPC: Add writeback register offsets and dss features structs
> OMAPDSS: DISPC: Configure input and output sizes for writeback
> OMAPDSS: DISPC: Downscale chroma if plane is writeback
> OMAPDSS: DISPC: Don't set chroma resampling bit for writeback
> OMAPDSS: DISPC: Add function to set channel in for writeback
> OMAPDSS: DISPC: Configure overlay-like parameters in dispc_wb_setup
> OMAPDSS: DISPC: Configure writeback specific parameters in dispc_wb_setup()
> OMAPDSS: DISPC: Configure writeback FIFOs
> OMAPDSS: DISPC: Add manager like functions for writeback
> OMAPDSS: DISPC: Configure color conversion coefficients for writeback
>
> Chandrabhanu Mahapatra (8):
> OMAPDSS: DISPC: Cleanup cpu_is_xxxx checks
> OMAPDSS: DSS: Remove redundant functions
> OMAPDSS: DSS: Cleanup cpu_is_xxxx checks
> ARM: OMAP: Disable venc for OMAP4
> OMAPDSS: VENC: Remove cpu_is_xxxx checks
> OMAPDSS: DPI: Remove cpu_is_xxxx checks
> OMAPDSS: Correct DISPC_IRQ bit definitions for LCD3
> OMAPDSS: DISPC: Add predecimation limit for TILER based rotations
>
> Grazvydas Ignotas (1):
> OMAPFB: fix framebuffer console colors
>
> Jassi Brar (1):
> OMAPDSS: DISPC: Use msleep instead of blocking mdelay
>
> Raphaël Assénat (1):
> OMAPDSS: Do not require a VDDS_DSI regulator on AM35xx
>
> Ricardo Neri (2):
> OMAPDSS: HDMI: Disable PLL properly in case of error at power_on
> OMAPDSS: DISPC: Improvements to DIGIT sync signal selection
>
> Tomi Valkeinen (53):
> Merge output work from Archit
> OMAPDSS: HDMI: fix initial HDMI enable
> Merge tag 'v3.6-rc4'
> OMAPDSS: HDMI: Move GPIO handling to HDMI driver
> OMAPDSS: HDMI: Add delay to wait for 5V power
> OMAP4: TWL: add vdda_hdmi_dac regulator supply
> OMAPDSS: HDMI: use vdda_hdmi_dac
> OMAPDSS: Add DSI fclk maximum to dss_features
> OMAPDSS: DSI: calculate dsi clock
> OMAP: 4430SDP: remove DSI clock config from board file
> OMAPDSS: fix use of dssdev->caps
> OMAPDSS: Taal: use devm_* functions
> OMAPFB1: remove unnecessary includes
> OMAPFB1: remove a non-used table
> OMAPDSS: remove unnecessary includes
> OMAPFB: clear framebuffers with CPU
> OMAPDSS: VRAM: Remove clearing with sDMA
> OMAPDSS: Taal: Reogranize for device tree
> OMAPDSS: TFP410: use devm_gpio_request_one
> OMAPDSS: split overlay sysfs code
> OMAPDSS: split manager sysfs code
> OMAPDSS: clean up dss_mgr_set_lcd_config
> OMAPDSS: clean up dss_mgr_set_timings
> Revert "OMAPDSS: APPLY: add fifo-merge support"
> Revert "OMAPDSS: APPLY: add fifo merge support funcs"
> OMAPDSS: Improve fifo management code
> OMAPDSS: Use WB fifo for GFX overlay
> OMAPDSS: fix set_timings
> OMAPDSS: fix dss_ovl_unset_manager
> Merge miscellaneous omapdss changes
> Merge branch 'fbdev-for-linus' of git://github.com/schandinat/linux-2.6
> OMAPDSS: omap_dss_register_device() doesn't take display index
> OMAPDSS: Add dss_get_default_display_name()
> OMAPDSS: register only one display device per output
> OMAPDSS: explicitely initialize dssdev->channel for new displays
> OMAPDSS: handle errors in dss_init_device
> OMAPDSS: cleanup dss_recheck_connections
> OMAPDSS: cleanup dss_recheck_connections further
> OMAPDSS: alloc dssdevs dynamically
> OMAPDSS: DSI: improve DSI clock calcs for DISPC
> OMAPDSS: move dss feats to the end of dss.c
> OMAPDSS: Add support for DPI source selection
> OMAPDSS: DSI: Add FEAT_DSI_PLL_SELFREQDCO
> OMAPDSS: DSI: Add FEAT_DSI_PLL_REFSEL
> OMAPDSS: DSI: Add new linebuffer size for OMAP5
> OMAPDSS: DSI: Add code to disable PHY DCC
> OMAPDSS: DSI: make OMAP2_DSS_DSI depend on ARCH_OMAP5
> Merge omapdss single-dssdev series
> Merge OMAP5 DSS changes to omapdss
> OMAPDSS: DSI: fix tlpx_half reg field length
> Merge branch 'archit/outputs-for-3.7'
> Merge branch 'archit/wb-dispc-for-3.7'
> OMAPDSS: add missing include for string.h
>
> arch/arm/mach-omap2/board-4430sdp.c | 73 +-
> arch/arm/mach-omap2/board-omap4panda.c | 27 +-
> arch/arm/mach-omap2/display.c | 1 -
> arch/arm/mach-omap2/twl-common.c | 6 +
> drivers/media/video/omap/omap_vout.c | 75 +-
> drivers/staging/omapdrm/omap_drv.c | 5 +-
> drivers/video/auo_k190x.c | 2 -
> drivers/video/console/bitblit.c | 2 +-
> drivers/video/console/fbcon.c | 2 +-
> drivers/video/mb862xx/mb862xxfbdrv.c | 2 +
> drivers/video/omap/hwa742.c | 1 -
> drivers/video/omap/lcd_ams_delta.c | 1 -
> drivers/video/omap/lcd_palmte.c | 1 -
> drivers/video/omap/omapfb_main.c | 9 -
> drivers/video/omap2/displays/panel-acx565akm.c | 14 +-
> drivers/video/omap2/displays/panel-generic-dpi.c | 76 +-
> .../omap2/displays/panel-lgphilips-lb035q02.c | 3 +
> drivers/video/omap2/displays/panel-n8x0.c | 31 +-
> .../omap2/displays/panel-nec-nl8048hl11-01b.c | 3 +
> drivers/video/omap2/displays/panel-picodlp.c | 4 +
> .../video/omap2/displays/panel-sharp-ls037v7dw01.c | 3 +
> drivers/video/omap2/displays/panel-taal.c | 239 ++---
> drivers/video/omap2/displays/panel-tfp410.c | 20 +-
> .../video/omap2/displays/panel-tpo-td043mtea1.c | 7 +-
> drivers/video/omap2/dss/Kconfig | 2 +-
> drivers/video/omap2/dss/Makefile | 4 +-
> drivers/video/omap2/dss/apply.c | 330 ++-----
> drivers/video/omap2/dss/core.c | 91 +-
> drivers/video/omap2/dss/dispc.c | 1019 ++++++++++++++------
> drivers/video/omap2/dss/dispc.h | 37 +
> drivers/video/omap2/dss/display.c | 108 ++-
> drivers/video/omap2/dss/dpi.c | 181 +++-
> drivers/video/omap2/dss/dsi.c | 675 ++++++++++---
> drivers/video/omap2/dss/dss.c | 257 +++--
> drivers/video/omap2/dss/dss.h | 79 +-
> drivers/video/omap2/dss/dss_features.c | 278 +++++-
> drivers/video/omap2/dss/dss_features.h | 7 +
> drivers/video/omap2/dss/hdmi.c | 247 +++--
> drivers/video/omap2/dss/hdmi_panel.c | 31 +-
> drivers/video/omap2/dss/manager-sysfs.c | 512 ++++++++++
> drivers/video/omap2/dss/manager.c | 473 +--------
> drivers/video/omap2/dss/output.c | 148 +++
> drivers/video/omap2/dss/overlay-sysfs.c | 456 +++++++++
> drivers/video/omap2/dss/overlay.c | 492 +---------
> drivers/video/omap2/dss/rfbi.c | 222 +++--
> drivers/video/omap2/dss/sdi.c | 136 ++-
> drivers/video/omap2/dss/venc.c | 337 +++----
> drivers/video/omap2/dss/venc_panel.c | 251 +++++
> drivers/video/omap2/omapfb/omapfb-ioctl.c | 7 +-
> drivers/video/omap2/omapfb/omapfb-main.c | 34 +-
> drivers/video/omap2/omapfb/omapfb.h | 5 +-
> drivers/video/omap2/vram.c | 56 --
> include/video/omapdss.h | 112 ++-
> 53 files changed, 4592 insertions(+), 2602 deletions(-)
> create mode 100644 drivers/video/omap2/dss/manager-sysfs.c
> create mode 100644 drivers/video/omap2/dss/output.c
> create mode 100644 drivers/video/omap2/dss/overlay-sysfs.c
> create mode 100644 drivers/video/omap2/dss/venc_panel.c
>
^ permalink raw reply
* Re: [PATCHv2 1/3] OMAP: VRFB: convert vrfb to platform device
From: Kevin Hilman @ 2012-10-10 18:12 UTC (permalink / raw)
To: Tomi Valkeinen; +Cc: linux-omap, linux-fbdev, Tony Lindgren, Archit Taneja
In-Reply-To: <1349842027.5972.8.camel@lappyti>
Tomi Valkeinen <tomi.valkeinen@ti.com> writes:
> On Tue, 2012-10-09 at 13:37 -0700, Kevin Hilman wrote:
>> Hi Tomi,
>>
>> Tomi Valkeinen <tomi.valkeinen@ti.com> writes:
>>
>> > This patch converts vrfb library into a platform device, in an effort to
>> > remove omap dependencies.
>> >
>> > The platform device is registered in arch/arm/plat-omap/fb.c and
>> > assigned resources depending on whether running on omap2 or omap3.
>> >
>> > The vrfb driver will parse those resources and use them to access vrfb
>> > configuration registers and the vrfb virtual rotation areas.
>> >
>> > Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
>> > Cc: Tony Lindgren <tony@atomide.com>
>>
>> [...]
>>
>> I was having a quick look at this for the context save/restore piece in
>> order to understand how this driver's context is being saved/restored.
>>
>> Looking at mainline, I don't see where omap_vrfb_restore_context() is
>> being called currently. Am I missing something?
>
> No, the driver is missing something. I noticed the same thing. It seems
> ctx restore for vrfb has never been functional in mainline. I don't
> really have any recollection if this was left out intentionally from
> mainline (possibly because we didn't have a good way to handle it at
> that point), or was it just a mistake.
>
> Nobody has complained about it, though, so it can't be a major problem
> =).
heh
> Vrfb is a platform device/driver after this patch. Do you see any
> problem with handling the context restore in runtime PM's runtime_resume
> callback?
No, that's the right way to handle it IMO. In fact, that's what I was
going to check on when reviewing this patch when I noticed that the
restore function wasn't being used.
> Hmm, I guess then we could have a problem if omapdss and
> omapfb are resumed before vrfb.
Possibly, but this could be handled by adding some sanity checks, or
having VRFB functions return -EAGAIN if it hasn't been resumed. Or
better yet, VRFB functions should be using runtime PM get/put
themselves, if they're used by omapdss/omapfb, a runtime resume (and
context restore) is forced. (disclaimer: I don't actually know how VRFB
works, so maybe this isn't possible.)
> Any way to manage the suspend/resume ordering of unrelated (i.e. no
> parent/child relation) devices?
No good way at the moment.
And to make things interesting: static suspend/resume ordering is not
dependent on parent/child. It's based on driver discover/probe order.
runtime PM ordering manages parent/child relationships.
Kevin
^ permalink raw reply
* [PATCH 3.6.0- 00/13] VIDEO: use module_platform_driver macro
From: Srinivas KANDAGATLA @ 2012-10-10 18:37 UTC (permalink / raw)
To: linux-fbdev
From: Srinivas Kandagatla <srinivas.kandagatla@st.com>
Running below Coccinelle lookup pattern like below on the
latest kernel showed about 52 hits. This patch series is a subset
of those 52 patches, so that it will be easy for maintainers to review.
Hopefully these patches will get rid of some code duplication in kernel.
@ @
- initfunc(void)
- { return platform_driver_register(&dr); }
...
- module_init(initfunc);
...
- exitfunc(void)
- { platform_driver_unregister(&dr); }
...
- module_exit(exitfunc);
+ module_platform_driver(dr);
Srinivas Kandagatla (13):
video/au1100fb: use module_platform_driver macro
video/au1200fb: use module_platform_driver macro
video/bf54x-lq043fb: use module_platform_driver macro
video/bfin-lq035q1: use module_platform_driver macro
video/bfin-t350mcqb: use module_platform_driver macro
video/broadsheetfb: use module_platform_driver macro
video/cobalt_lcdfb: use module_platform_driver macro
video/da8xx_fb: use module_platform_driver macro
video/ep93xx_fb: use module_platform_driver macro
video/grvga: use module_platform_driver macro
video/hecubafb: use module_platform_driver macro
video/jz4740_fb: use module_platform_driver macro
video/metronomefb: use module_platform_driver macro
drivers/video/au1100fb.c | 14 +-------------
drivers/video/au1200fb.c | 16 +---------------
drivers/video/bf54x-lq043fb.c | 14 +-------------
drivers/video/bfin-lq035q1-fb.c | 13 +------------
drivers/video/bfin-t350mcqb-fb.c | 14 +-------------
drivers/video/broadsheetfb.c | 14 +-------------
drivers/video/cobalt_lcdfb.c | 14 +-------------
drivers/video/da8xx-fb.c | 14 +-------------
drivers/video/ep93xx-fb.c | 14 +-------------
drivers/video/grvga.c | 15 +--------------
drivers/video/hecubafb.c | 14 +-------------
drivers/video/jz4740_fb.c | 13 +------------
drivers/video/metronomefb.c | 14 +-------------
13 files changed, 13 insertions(+), 170 deletions(-)
^ 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