* Re: [PATCH 1/7] drivers/video/pvr2fb.c: ensure arguments to request_irq and free_irq are compatible
From: Florian Tobias Schandinat @ 2012-03-21 18:37 UTC (permalink / raw)
To: Julia Lawall; +Cc: kernel-janitors, linux-fbdev, linux-kernel
In-Reply-To: <1331494587-12196-2-git-send-email-Julia.Lawall@lip6.fr>
On 03/11/2012 07:36 PM, Julia Lawall wrote:
> From: Julia Lawall <Julia.Lawall@lip6.fr>
>
> Convert calls to free_irq so that the second argument is the same as the
> last argument of the corresponding call to request_irq. Without this
> property, free_irq does nothing.
>
> Signed-off-by: Julia Lawall <Julia.Lawall@lip6.fr>
Applied.
Thanks,
Florian Tobias Schandinat
>
> ---
> Not tested.
>
> drivers/video/pvr2fb.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/video/pvr2fb.c b/drivers/video/pvr2fb.c
> index 3a3fdc6..bcd44c3 100644
> --- a/drivers/video/pvr2fb.c
> +++ b/drivers/video/pvr2fb.c
> @@ -895,7 +895,7 @@ static int __init pvr2fb_dc_init(void)
>
> #ifdef CONFIG_PVR2_DMA
> if (request_dma(pvr2dma, "pvr2") != 0) {
> - free_irq(HW_EVENT_VSYNC, 0);
> + free_irq(HW_EVENT_VSYNC, fb_info);
> return -EBUSY;
> }
> #endif
> @@ -914,7 +914,7 @@ static void __exit pvr2fb_dc_exit(void)
> currentpar->mmio_base = 0;
> }
>
> - free_irq(HW_EVENT_VSYNC, 0);
> + free_irq(HW_EVENT_VSYNC, fb_info);
> #ifdef CONFIG_PVR2_DMA
> free_dma(pvr2dma);
> #endif
>
>
^ permalink raw reply
* Re: [PULL for v3.4] SH mobile LCDC cleanups and fixes
From: Florian Tobias Schandinat @ 2012-03-21 18:39 UTC (permalink / raw)
To: linux-fbdev
In-Reply-To: <2909866.e1WXYoJFDz@avalon>
On 03/12/2012 09:48 PM, Laurent Pinchart wrote:
> Hi Florian,
>
> Here's the next round of SH mobile LCDC and MERAM cleanups and fixes based on
> top of your fbdev-next branch (as of right now). All the patches have been
> posted to the list and I've incorporated acked-by and tested-by lines when
> available.
>
> The following changes since commit c2bc0a756b1f98bd712fabe78eb49d7d5ae72075:
>
> video:uvesafb: notice user when we failed to save hardware state (2012-03-08
> 18:13:10 +0000)
>
> are available in the git repository at:
> git://linuxtv.org/pinchartl/fbdev.git for-next
Merged.
Thanks,
Florian Tobias Schandinat
>
> Laurent Pinchart (55):
> fbdev: sh_mobile_lcdc: Reorder code into sections
> fbdev: sh_mobile_lcdc: Mark init-only symbols with __devinit(const)
> fbdev: sh_mobile_lcdc: Move pm runtime enable to probe()
> fbdev: sh_mobile_lcdc: Don't pass struct device around
> fbdev: sh_mobile_lcdc: Create functions to turn the display on/off
> fbdev: sh_mobile_hdmi: Don't access LCDC channel in notifier callback
> sh_mobile_hdmi: Remove platform data lcd_dev field
> fbdev: sh_mobile_lcdc: Add sh_mobile_lcdc_entity definition
> fbdev: sh_mobile_hdmi: Implement sh_mobile_lcdc_entity interface
> fbdev: sh_mipi_dsi: Implement sh_mobile_lcdc_entity interface
> fbdev: sh_mobile_lcdc: Handle HDMI/MIPI transmitter device directly
> arm: mach-shmobile: Add LCDC tx_dev field to platform data
> fbdev: sh_mipi_dsi: Don't hook up into board_cfg display operations
> fbdev: sh_mobile_hdmi: Don't hook up into board_cfg display operations
> arm: mach-shmobile: Don't initialize the hdmi_info lcd_chan field
> fbdev: sh_mobile_hdmi: Remove sh_mobile_hdmi_info lcd_chan field
> fbdev: sh_mobile_lcdc: Remove board configuration owner field
> fbdev: sh_mobile_lcdc: Remove board configuration board_data field
> fbdev: sh_mobile_lcdc: Move brightness ops to sh_mobile_lcdc_bl_info
> fbdev: sh_mobile_lcdc: Merge board_cfg and lcd_size_cfg into panel_cfg
> sh_mobile_lcdc: Add an lcdc channel pointer to sh_mobile_lcdc_entity
> sh_mobile_hdmi: Use sh_mobile_lcdc_entity::channel to access fb_info
> fbdev: sh_mobile_lcdc: Remove fb_info parameter to display_on operation
> fbdev: sh_mobile_lcdc: Return display connection state in display_on
> sh_mobile_lcdc: Add display notify callback to sh_mobile_lcdc_chan
> sh_mobile_hdmi: Use LCDC notification callback
> fbdev: sh_mobile_lcdc: Pass a video mode to the notify callback
> fbdev: sh_mobile_hdmi: Don't set sh_hdmi::mode in the display on handler
> fbdev: sh_mobile_hdmi: Don't access LCDC fb_info
> fbdev: sh_mobile_lcdc: Store display mode in a struct fb_videomode
> fbdev: sh_mobile_lcdc: Rename (lcd|num)_cfg (lcd|num)_modes
> fbdev: sh_mobile_lcdc: Reorganize the sh_mobile_lcdc_chan structure
> fbdev: sh_mobile_lcdc: Add sh_mobile_format_info() function
> fbdev: sh_mobile_lcdc: Store the format in struct sh_mobile_lcdc_chan
> fbdev: sh_mobile_lcdc: Split fb init/cleanup from channel init/cleanup
> fbdev: sh_mobile_lcdc: Pass physical device pointer to DMA functions
> fbdev: sh_mobile_lcdc: Store configuration in channel structure
> fbdev: sh_mobile_lcdc: Pass channel pointer to sh_mobile_wait_for_vsync
> arm: mach-shmobile: Split MERAM resources into regs and meram
> fbdev: sh_mobile_meram: Request memory regions for memory resources
> fbdev: sh_mobile_meram: Add _cfg suffix to struct sh_mobile_meram_icb
> fbdev: sh_mobile_meram: Make variables unsigned where applicable
> fbdev: sh_mobile_meram: Make current_reg field store the current reg set
> fbdev: sh_mobile_meram: Add struct sh_mobile_meram_icb
> fbdev: sh_mobile_meram: Don't inline everything
> fbdev: sh_mobile_meram: Divide the code into sections
> fbdev: sh_mobile_meram: Use genalloc to manage MERAM allocation
> fbdev: sh_mobile_meram: Allocate ICBs automatically
> arm: mach-shmobile: Don't set MERAM ICB numbers in platform data
> fbdev: sh_mobile_meram: Remove unused sh_mobile_meram_icb_cfg fields
> fbdev: sh_mobile_lcdc: Don't store copy of platform data
> arm: mach-shmobile: Constify sh_mobile_meram_cfg structures
> fbdev: sh_mobile_meram: Don't perform update in register operation
> fbdev: sh_mobile_meram: Remove unneeded sanity checks
> fbdev: sh_mobile_meram: Implement system suspend/resume
>
> arch/arm/mach-shmobile/board-ag5evm.c | 24 +-
> arch/arm/mach-shmobile/board-ap4evb.c | 290 +++---
> arch/arm/mach-shmobile/board-bonito.c | 6 +-
> arch/arm/mach-shmobile/board-mackerel.c | 106 +--
> arch/sh/boards/mach-ap325rxa/setup.c | 22 +-
> arch/sh/boards/mach-ecovec24/setup.c | 20 +-
> arch/sh/boards/mach-kfr2r09/lcd_wqvga.c | 10 +-
> arch/sh/boards/mach-kfr2r09/setup.c | 8 +-
> arch/sh/boards/mach-migor/lcd_qvga.c | 3 +-
> arch/sh/boards/mach-migor/setup.c | 16 +-
> arch/sh/boards/mach-se/7724/setup.c | 12 +-
> arch/sh/include/mach-kfr2r09/mach/kfr2r09.h | 16 +-
> arch/sh/include/mach-migor/mach/migor.h | 2 +-
> drivers/video/Kconfig | 1 +
> drivers/video/sh_mipi_dsi.c | 97 +--
> drivers/video/sh_mobile_hdmi.c | 297 ++-----
> drivers/video/sh_mobile_lcdcfb.c | 1298 +++++++++++++++-----------
> drivers/video/sh_mobile_lcdcfb.h | 84 ++-
> drivers/video/sh_mobile_meram.c | 690 ++++++++-------
> include/video/sh_mobile_hdmi.h | 2 -
> include/video/sh_mobile_lcdc.h | 35 +-
> include/video/sh_mobile_meram.h | 45 +-
> 22 files changed, 1594 insertions(+), 1490 deletions(-)
>
^ permalink raw reply
* Re: [PATCH v2 1/2] fbdev: da8xx:: fix reporting of the display timing info
From: Florian Tobias Schandinat @ 2012-03-21 18:40 UTC (permalink / raw)
To: linux-fbdev
In-Reply-To: <1331644384-5408-1-git-send-email-agust@denx.de>
Applied both patches of this series.
Thanks,
Florian Tobias Schandinat
On 03/13/2012 01:13 PM, Anatolij Gustschin wrote:
> Timing info is not properly reported by the driver, e.g.:
>
> $ fbset -i
> mode "480x272-35"
> # D: 7.895 MHz, H: 12.165 kHz, V: 35.158 Hz
> geometry 480 272 480 544 16
> timings 126666 64 64 32 32 41 10
>
> According to the timing values defined for LK043T1DG01 display
> it should be reported as:
>
> mode "480x272-53"
> # D: 7.895 MHz, H: 15.038 kHz, V: 52.579 Hz
> geometry 480 272 480 544 16
> timings 126666 2 2 2 2 41 10
>
> Initialize additional fb_var_screeninfo fields so fix this problem.
>
> Signed-off-by: Anatolij Gustschin <agust@denx.de>
> Cc: Manjunathappa, Prakash <prakash.pm@ti.com>
> ---
> v2:
> - removed pixclock setting as it is already done in fbdev-next
> - rebased on fbdev-next branch
>
> drivers/video/da8xx-fb.c | 4 ++++
> 1 files changed, 4 insertions(+), 0 deletions(-)
>
> diff --git a/drivers/video/da8xx-fb.c b/drivers/video/da8xx-fb.c
> index dd80386..8f7e051 100644
> --- a/drivers/video/da8xx-fb.c
> +++ b/drivers/video/da8xx-fb.c
> @@ -1231,6 +1231,10 @@ static int __devinit fb_probe(struct platform_device *device)
>
> da8xx_fb_var.hsync_len = lcdc_info->hsw;
> da8xx_fb_var.vsync_len = lcdc_info->vsw;
> + da8xx_fb_var.right_margin = lcdc_info->hfp;
> + da8xx_fb_var.left_margin = lcdc_info->hbp;
> + da8xx_fb_var.lower_margin = lcdc_info->vfp;
> + da8xx_fb_var.upper_margin = lcdc_info->vbp;
> da8xx_fb_var.pixclock = da8xxfb_pixel_clk_period(par);
>
> /* Initialize fbinfo */
^ permalink raw reply
* Re: [PATCH] fbdev: bfin_adv7393fb: Drop needless include
From: Florian Tobias Schandinat @ 2012-03-21 18:41 UTC (permalink / raw)
To: linux-fbdev
In-Reply-To: <20120315101449.65566857@endymion.delvare>
On 03/15/2012 09:14 AM, Jean Delvare wrote:
> Kernel drivers don't need <linux/i2c-dev.h>.
>
> Signed-off-by: Jean Delvare <khali@linux-fr.org>
> Cc: Michael Hennerich <michael.hennerich@analog.com>
> Cc: Florian Tobias Schandinat <FlorianSchandinat@gmx.de>
Applied.
Thanks,
Florian Tobias Schandinat
> ---
> drivers/video/bfin_adv7393fb.c | 2 --
> 1 file changed, 2 deletions(-)
>
> --- linux-3.3-rc7.orig/drivers/video/bfin_adv7393fb.c 2012-01-06 11:21:14.000000000 +0100
> +++ linux-3.3-rc7/drivers/video/bfin_adv7393fb.c 2012-03-15 10:09:32.345820005 +0100
> @@ -36,9 +36,7 @@
> #include <linux/dma-mapping.h>
> #include <linux/proc_fs.h>
> #include <linux/platform_device.h>
> -
> #include <linux/i2c.h>
> -#include <linux/i2c-dev.h>
>
> #include "bfin_adv7393fb.h"
>
>
>
^ permalink raw reply
* Re: [PATCH] video: pxafb: add clk_prepare/clk_unprepare calls
From: Florian Tobias Schandinat @ 2012-03-21 18:42 UTC (permalink / raw)
To: linux-fbdev
In-Reply-To: <1331835120.14662.3.camel@flow>
On 03/15/2012 06:12 PM, Philipp Zabel wrote:
> This patch adds clk_prepare/clk_unprepare calls to the pxafb
> driver by using the helper functions clk_prepare_enable and
> clk_disable_unprepare.
>
> Signed-off-by: Philipp Zabel <philipp.zabel@gmail.com>
> Cc: Haojian Zhuang <haojian.zhuang@marvell.com>
> Cc: Eric Miao <eric.y.miao@gmail.com>
> Cc: Florian Tobias Schandinat <FlorianSchandinat@gmx.de>
Applied.
Thanks,
Florian Tobias Schandinat
> ---
> drivers/video/pxafb.c | 4 ++--
> 1 files changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/video/pxafb.c b/drivers/video/pxafb.c
> index 1d1e4f1..904f839 100644
> --- a/drivers/video/pxafb.c
> +++ b/drivers/video/pxafb.c
> @@ -1431,7 +1431,7 @@ static void pxafb_enable_controller(struct pxafb_info *fbi)
> pr_debug("reg_lccr3 0x%08x\n", (unsigned int) fbi->reg_lccr3);
>
> /* enable LCD controller clock */
> - clk_enable(fbi->clk);
> + clk_prepare_enable(fbi->clk);
>
> if (fbi->lccr0 & LCCR0_LCDT)
> return;
> @@ -1471,7 +1471,7 @@ static void pxafb_disable_controller(struct pxafb_info *fbi)
> wait_for_completion_timeout(&fbi->disable_done, 200 * HZ / 1000);
>
> /* disable LCD controller clock */
> - clk_disable(fbi->clk);
> + clk_disable_unprepare(fbi->clk);
> }
>
> /*
^ permalink raw reply
* Re: [GIT PULL] OMAP DSS for v3.4
From: Florian Tobias Schandinat @ 2012-03-21 18:45 UTC (permalink / raw)
To: Tomi Valkeinen; +Cc: Arnd Bergmann, linux-omap, linux-fbdev
In-Reply-To: <1332154865.2144.57.camel@deskari>
On 03/19/2012 11:01 AM, Tomi Valkeinen wrote:
> Hi Florian, Arnd,
>
> Here are the changes for OMAP DSS driver for v3.4.
>
> There's an issue with the dss driver that appears on arm-soc/for-next
> branch, which I'm still solving
> (http://marc.info/?l=linux-omap&m\x133214966902577&w=2). I hope to get
> fix for that ready and merged for -rc1, but I'm not sure if I can make
> it in time, so I wanted to sent this pull request already.
>
> Arnd, as discussed before, you can also merge this branch to solve the
> conflicts between arm-soc and omapdss trees.
>
> Note that this is the first pull request I've sent with a branch that I
> have not been rebasing, so please check that the branch looks sane.
>
> Tomi
>
> The following changes since commit c16fa4f2ad19908a47c63d8fa436a1178438c7e7:
>
> Linux 3.3 (2012-03-18 16:15:34 -0700)
Interesting, I never tried to start at a commit that is not part of the
branch. Good to know that it does work.
>
> are available in the git repository at:
> git://gitorious.org/linux-omap-dss2/linux.git for-3.4
Merged.
Thanks,
Florian Tobias Schandinat
>
> Archit Taneja (2):
> OMAPDSS: Features: Maintain dss_feats as a list
> OMAPDSS: DISPC: Fix scaling constraints for OMAP4
>
> Danny Kukawka (1):
> OMAPDSS: VENC: fix NULL pointer dereference in DSS2 VENC sysfs debug attr on OMAP4
>
> Grazvydas Ignotas (2):
> OMAPDSS: TPO-TD03MTEA1: fix suspend hang
> OMAPDSS: TPO-TD03MTEA1: update default gamma
>
> Julia Lawall (1):
> OMAPDSS: use devm_ functions
>
> Lajos Molnar (3):
> OMAPDSS: DISPC: Fix OMAP4 supported color formats
> OMAPDSS: DISPC: Fix FIR coefficients
> OMAPDSS: MANAGER/APPLY: Add runtime_pm protection around wait_for_go/vsync functions
>
> Mythri P K (6):
> OMAPDSS: HDMI: remove duplicate video interface code
> OMAPDSS: HDMI: update static timing table
> OMAPDSS: HDMI: change the timing match logic
> OMAPDSS: HDMI: remove duplicate code and mode parameter
> OMAPDSS: HDMI: Move Avi-infoframe struct to hdmi_ip_data
> OMAPDSS: HDMI: Add M2 divider while calculating clkout
>
> Ricardo Neri (4):
> OMAPDSS: HDMI: Correct source of the pixel clock in ACR calculation
> OMAPDSS: Add DSS feature for HDMI MCLK for audio
> OMAPDSS: HDMI: Implement initialization of MCLK
> OMAPDSS: HDMI: Modify logic to configure MCLK
>
> Tomi Valkeinen (29):
> OMAPDSS: FEAT: Add FIFO_MERGE feature
> OMAPDSS: APPLY: add fifo merge support funcs
> OMAPDSS: APPLY: add fifo-merge support
> OMAPDSS: DISPC: print fifo threshold values in bytes
> OMAPDSS: DISPC: move fifo threhold calc to dispc.c
> OMAPDSS: DISPC: Add naive threshold calc for fifomerge
> Merge branch 'work/fifomerge'
> Merge commit 'v3.3-rc4'
> OMAPDSS: cleanup probe functions
> OMAPFB: remove old blizzard driver
> OMAPFB: Remove OMAP2/3 support from old omapfb driver
> OMAPDSS: Remove video SRAM support
> OMAPFB: Remove video SRAM support (old omapfb)
> OMAP2+: remove unneeded #include omapfb.h
> OMAP: N770: remove HWA742 platform data
> OAMPFB: remove unused omapfb_set_ctrl_platform_data()
> OMAPFB: remove early mem alloc from old omapfb
> OMAPFB: remove mem info from platform_data
> OMAPFB: remove unused fb_format_to_dss_mode()
> OMAPFB: Move old omapfb private structs to a private include file
> OMAPFB: remove omapfb_set_platform_data()
> OMAP1: pass LCD config with omapfb_set_lcd_config()
> OMAP: Remove OMAP_TAG_LCD and OMAP_TAG_FBMEM
> OMAP1: Remove unused LCD devices from board files
> OMAPFB: remove remaining OMAP arch checks
> Merge branch 'work/old-omapfb-removal'
> Merge commit 'v3.3-rc6'
> OMAPDSS: APPLY: print warning if wait_pending_extra_info_updates fails
> OMAPDSS: APPLY: fix clearing shadow dirty flag with manual update
>
> Tony Lindgren (1):
> ARM: OMAP2+: Fix compile error when FB_OMAP2 is not set
>
> Yegor Yefremov (1):
> OMAPDSS: add Innolux AT080TN52 display support
>
> arch/arm/mach-omap1/board-ams-delta.c | 9 +-
> arch/arm/mach-omap1/board-fsample.c | 15 +-
> arch/arm/mach-omap1/board-h2.c | 15 +-
> arch/arm/mach-omap1/board-h3.c | 9 +-
> arch/arm/mach-omap1/board-htcherald.c | 9 +-
> arch/arm/mach-omap1/board-innovator.c | 11 +-
> arch/arm/mach-omap1/board-nokia770.c | 19 +-
> arch/arm/mach-omap1/board-osk.c | 14 +-
> arch/arm/mach-omap1/board-palmte.c | 10 +-
> arch/arm/mach-omap1/board-palmtt.c | 10 +-
> arch/arm/mach-omap1/board-palmz71.c | 10 +-
> arch/arm/mach-omap1/board-perseus2.c | 15 +-
> arch/arm/mach-omap1/board-sx1.c | 16 +-
> arch/arm/mach-omap2/io.c | 1 -
> arch/arm/plat-omap/common.c | 2 -
> arch/arm/plat-omap/fb.c | 334 +----
> arch/arm/plat-omap/fb.h | 10 -
> arch/arm/plat-omap/include/plat/blizzard.h | 12 -
> arch/arm/plat-omap/include/plat/board.h | 2 -
> arch/arm/plat-omap/include/plat/hwa742.h | 8 -
> arch/arm/plat-omap/include/plat/vram.h | 21 +-
> drivers/video/omap/Kconfig | 16 +-
> drivers/video/omap/Makefile | 12 +-
> drivers/video/omap/blizzard.c | 1648 --------------------
> drivers/video/omap/dispc.c | 1547 ------------------
> drivers/video/omap/dispc.h | 46 -
> drivers/video/omap/hwa742.c | 21 +-
> drivers/video/omap/omapfb.h | 25 +-
> drivers/video/omap/omapfb_main.c | 30 +-
> drivers/video/omap/rfbi.c | 598 -------
> drivers/video/omap2/displays/panel-generic-dpi.c | 23 +
> .../video/omap2/displays/panel-tpo-td043mtea1.c | 153 ++-
> drivers/video/omap2/dss/apply.c | 275 +++-
> drivers/video/omap2/dss/dispc.c | 121 +-
> drivers/video/omap2/dss/dispc_coefs.c | 9 +-
> drivers/video/omap2/dss/display.c | 10 -
> drivers/video/omap2/dss/dsi.c | 65 +-
> drivers/video/omap2/dss/dss.c | 17 +-
> drivers/video/omap2/dss/dss.h | 10 +-
> drivers/video/omap2/dss/dss_features.c | 181 ++-
> drivers/video/omap2/dss/dss_features.h | 54 +-
> drivers/video/omap2/dss/hdmi.c | 278 ++--
> drivers/video/omap2/dss/manager.c | 12 +-
> drivers/video/omap2/dss/rfbi.c | 36 +-
> drivers/video/omap2/dss/ti_hdmi.h | 56 +-
> drivers/video/omap2/dss/ti_hdmi_4xxx_ip.c | 94 +-
> drivers/video/omap2/dss/ti_hdmi_4xxx_ip.h | 47 -
> drivers/video/omap2/dss/venc.c | 32 +-
> drivers/video/omap2/omapfb/omapfb-ioctl.c | 2 +-
> drivers/video/omap2/omapfb/omapfb-main.c | 101 +--
> drivers/video/omap2/vram.c | 99 +--
> include/linux/omapfb.h | 32 +-
> 52 files changed, 1001 insertions(+), 5201 deletions(-)
> delete mode 100644 arch/arm/plat-omap/fb.h
> delete mode 100644 arch/arm/plat-omap/include/plat/blizzard.h
> delete mode 100644 arch/arm/plat-omap/include/plat/hwa742.h
> delete mode 100644 drivers/video/omap/blizzard.c
> delete mode 100644 drivers/video/omap/dispc.c
> delete mode 100644 drivers/video/omap/dispc.h
> delete mode 100644 drivers/video/omap/rfbi.c
>
^ permalink raw reply
* Re: [PATCH v4] fbdev: remove dependency of FB_SH_MOBILE_MERAM from FB_SH_MOBILE_LCDC
From: Florian Tobias Schandinat @ 2012-03-21 18:46 UTC (permalink / raw)
To: linux-fbdev
In-Reply-To: <87obrqwxp2.wl%kuninori.morimoto.gx@renesas.com>
On 03/21/2012 01:27 AM, Kuninori Morimoto wrote:
> MERAM can be used for other IP blocks as well in the future.
> It doesn't necessarily mean that the MERAM driver depends on the LCDC.
> This patch corrects dependency.
>
> Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Applied.
Thanks,
Florian Tobias Schandinat
> ---
> v3 -> v4
>
> - move config to before endpoint
>
> drivers/video/Kconfig | 23 +++++++++++------------
> 1 files changed, 11 insertions(+), 12 deletions(-)
>
> diff --git a/drivers/video/Kconfig b/drivers/video/Kconfig
> index 8951cbd..0fb9540 100644
> --- a/drivers/video/Kconfig
> +++ b/drivers/video/Kconfig
> @@ -2013,18 +2013,6 @@ config FB_SH_MOBILE_HDMI
> ---help---
> Driver for the on-chip SH-Mobile HDMI controller.
>
> -config FB_SH_MOBILE_MERAM
> - tristate "SuperH Mobile MERAM read ahead support for LCDC"
> - depends on FB_SH_MOBILE_LCDC
> - default y
> - ---help---
> - Enable MERAM support for the SH-Mobile LCD controller.
> -
> - This will allow for caching of the framebuffer to provide more
> - reliable access under heavy main memory bus traffic situations.
> - Up to 4 memory channels can be configured, allowing 4 RGB or
> - 2 YCbCr framebuffers to be configured.
> -
> config FB_TMIO
> tristate "Toshiba Mobile IO FrameBuffer support"
> depends on FB && MFD_CORE
> @@ -2434,4 +2422,15 @@ if FB || SGI_NEWPORT_CONSOLE
> source "drivers/video/logo/Kconfig"
> endif
>
> +config FB_SH_MOBILE_MERAM
> + tristate "SuperH Mobile MERAM read ahead support"
> + depends on (SUPERH || ARCH_SHMOBILE)
> + ---help---
> + Enable MERAM support for the SuperH controller.
> +
> + This will allow for caching of the framebuffer to provide more
> + reliable access under heavy main memory bus traffic situations.
> + Up to 4 memory channels can be configured, allowing 4 RGB or
> + 2 YCbCr framebuffers to be configured.
> +
> endmenu
^ permalink raw reply
* Re: [PATCH v2] fbdev: sh_mipi_dsi: add extra phyctrl for sh_mipi_dsi_info
From: Florian Tobias Schandinat @ 2012-03-21 18:47 UTC (permalink / raw)
To: linux-fbdev
In-Reply-To: <87mx7awxdd.wl%kuninori.morimoto.gx@renesas.com>
On 03/21/2012 01:34 AM, Kuninori Morimoto wrote:
> sh_mipi uses some clocks, but the method of setup depends on CPU.
>
> Current SuperH (like sh73a0) can control all of these clocks
> by CPG (Clock Pulse Generator).
> It means we can control it by clock framework only.
> But on sh7372, it needs CPG settings AND sh_mipi PHYCTRL::PLLDS,
> and only sh7372 has PHYCTRL::PLLDS.
>
> But on current sh_mipi driver, PHYCTRL::PLLDS of sh7372 was
> overwrote since the callback timing of clock setting was changed
> by c2658b70f06108361aa5024798f9c1bf47c73374
> (fbdev: sh_mipi_dsi: fixup setup timing of sh_mipi_setup()).
> To solve this issue, this patch adds extra .phyctrl.
>
> This patch adds detail explanation for unclear mipi settings
> and fixup wrong PHYCTRL::PLLDS value for ap4evb (0xb -> 0x6).
>
> Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Applied.
Thanks,
Florian Tobias Schandinat
> ---
> v1 -> v2
>
> - fixup wrong MHz (321 -> 312)
> - Adds explain that this patch fixup wrong PLLDS value for ap4evb
>
> arch/arm/mach-shmobile/board-ap4evb.c | 12 +++++++++---
> drivers/video/sh_mipi_dsi.c | 2 +-
> include/video/sh_mipi_dsi.h | 1 +
> 3 files changed, 11 insertions(+), 4 deletions(-)
>
> diff --git a/arch/arm/mach-shmobile/board-ap4evb.c b/arch/arm/mach-shmobile/board-ap4evb.c
> index eeb4d96..50fcf1b 100644
> --- a/arch/arm/mach-shmobile/board-ap4evb.c
> +++ b/arch/arm/mach-shmobile/board-ap4evb.c
> @@ -556,20 +556,25 @@ static struct platform_device keysc_device = {
> };
>
> /* MIPI-DSI */
> -#define PHYCTRL 0x0070
> static int sh_mipi_set_dot_clock(struct platform_device *pdev,
> void __iomem *base,
> int enable)
> {
> struct clk *pck = clk_get(&pdev->dev, "dsip_clk");
> - void __iomem *phy = base + PHYCTRL;
>
> if (IS_ERR(pck))
> return PTR_ERR(pck);
>
> if (enable) {
> + /*
> + * DSIPCLK = 24MHz
> + * D-PHY = DSIPCLK * ((0x6*2)+1) = 312MHz (see .phyctrl)
> + * HsByteCLK = D-PHY/8 = 39MHz
> + *
> + * X * Y * FPS > + * (544+72+600+16) * (961+8+8+2) * 30 = 36.1MHz
> + */
> clk_set_rate(pck, clk_round_rate(pck, 24000000));
> - iowrite32(ioread32(phy) | (0xb << 8), phy);
> clk_enable(pck);
> } else {
> clk_disable(pck);
> @@ -598,6 +603,7 @@ static struct sh_mipi_dsi_info mipidsi0_info = {
> .lcd_chan = &lcdc_info.ch[0],
> .lane = 2,
> .vsynw_offset = 17,
> + .phyctrl = 0x6 << 8,
> .flags = SH_MIPI_DSI_SYNC_PULSES_MODE |
> SH_MIPI_DSI_HSbyteCLK,
> .set_dot_clock = sh_mipi_set_dot_clock,
> diff --git a/drivers/video/sh_mipi_dsi.c b/drivers/video/sh_mipi_dsi.c
> index 05151b8..214482c 100644
> --- a/drivers/video/sh_mipi_dsi.c
> +++ b/drivers/video/sh_mipi_dsi.c
> @@ -271,7 +271,7 @@ static int __init sh_mipi_setup(struct sh_mipi *mipi,
> iowrite32(0x00000001, base + PHYCTRL);
> udelay(200);
> /* Deassert resets, power on */
> - iowrite32(0x03070001, base + PHYCTRL);
> + iowrite32(0x03070001 | pdata->phyctrl, base + PHYCTRL);
>
> /*
> * Default = ULPS enable |
> diff --git a/include/video/sh_mipi_dsi.h b/include/video/sh_mipi_dsi.h
> index 434d56b..06c67fb 100644
> --- a/include/video/sh_mipi_dsi.h
> +++ b/include/video/sh_mipi_dsi.h
> @@ -51,6 +51,7 @@ struct sh_mipi_dsi_info {
> int lane;
> unsigned long flags;
> u32 clksrc;
> + u32 phyctrl; /* for extra setting */
> unsigned int vsynw_offset;
> int (*set_dot_clock)(struct platform_device *pdev,
> void __iomem *base,
^ permalink raw reply
* Re: [GIT PULL] OMAP DSS for v3.4
From: Florian Tobias Schandinat @ 2012-03-21 18:48 UTC (permalink / raw)
To: Tomi Valkeinen; +Cc: Arnd Bergmann, linux-omap, linux-fbdev
In-Reply-To: <1332333553.2236.8.camel@deskari>
On 03/21/2012 12:39 PM, Tomi Valkeinen wrote:
> From 849c07b1fd3d9f23e8ed94436b6221f8652462c0 Mon Sep 17 00:00:00 2001
> From: Tomi Valkeinen <tomi.valkeinen@ti.com>
> Date: Mon, 19 Mar 2012 15:05:02 +0200
> Subject: [PATCH] OMAPDSS: register dss drivers in module init
>
> We do the dss driver registration in a rather strange way: we have the
> higher level omapdss driver, and we use that driver's probe function to
> register the drivers for the rest of the dss devices.
>
> There doesn't seem to be any reason for that, and additionally the
> soon-to-be-merged patch "ARM: OMAP: omap_device: remove
> omap_device_parent" will break omapdss initialization with the current
> registration model.
>
> This patch changes the registration for all drivers to happen at the
> same place, in the init of the module.
>
> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Applied.
Thanks,
Florian Tobias Schandinat
> ---
> drivers/video/omap2/dss/core.c | 135 +++++++++++++++++++++++-----------------
> 1 files changed, 77 insertions(+), 58 deletions(-)
>
> diff --git a/drivers/video/omap2/dss/core.c b/drivers/video/omap2/dss/core.c
> index 8613f86..e8a1207 100644
> --- a/drivers/video/omap2/dss/core.c
> +++ b/drivers/video/omap2/dss/core.c
> @@ -183,42 +183,6 @@ static int omap_dss_probe(struct platform_device *pdev)
> dss_init_overlay_managers(pdev);
> dss_init_overlays(pdev);
>
> - r = dss_init_platform_driver();
> - if (r) {
> - DSSERR("Failed to initialize DSS platform driver\n");
> - goto err_dss;
> - }
> -
> - r = dispc_init_platform_driver();
> - if (r) {
> - DSSERR("Failed to initialize dispc platform driver\n");
> - goto err_dispc;
> - }
> -
> - r = rfbi_init_platform_driver();
> - if (r) {
> - DSSERR("Failed to initialize rfbi platform driver\n");
> - goto err_rfbi;
> - }
> -
> - r = venc_init_platform_driver();
> - if (r) {
> - DSSERR("Failed to initialize venc platform driver\n");
> - goto err_venc;
> - }
> -
> - r = dsi_init_platform_driver();
> - if (r) {
> - DSSERR("Failed to initialize DSI platform driver\n");
> - goto err_dsi;
> - }
> -
> - r = hdmi_init_platform_driver();
> - if (r) {
> - DSSERR("Failed to initialize hdmi\n");
> - goto err_hdmi;
> - }
> -
> r = dss_initialize_debugfs();
> if (r)
> goto err_debugfs;
> @@ -246,18 +210,6 @@ static int omap_dss_probe(struct platform_device *pdev)
> err_register:
> dss_uninitialize_debugfs();
> err_debugfs:
> - hdmi_uninit_platform_driver();
> -err_hdmi:
> - dsi_uninit_platform_driver();
> -err_dsi:
> - venc_uninit_platform_driver();
> -err_venc:
> - dispc_uninit_platform_driver();
> -err_dispc:
> - rfbi_uninit_platform_driver();
> -err_rfbi:
> - dss_uninit_platform_driver();
> -err_dss:
>
> return r;
> }
> @@ -269,13 +221,6 @@ static int omap_dss_remove(struct platform_device *pdev)
>
> dss_uninitialize_debugfs();
>
> - hdmi_uninit_platform_driver();
> - dsi_uninit_platform_driver();
> - venc_uninit_platform_driver();
> - rfbi_uninit_platform_driver();
> - dispc_uninit_platform_driver();
> - dss_uninit_platform_driver();
> -
> dss_uninit_overlays(pdev);
> dss_uninit_overlay_managers(pdev);
>
> @@ -525,6 +470,80 @@ static int omap_dss_bus_register(void)
>
> /* INIT */
>
> +static int __init omap_dss_register_drivers(void)
> +{
> + int r;
> +
> + r = platform_driver_register(&omap_dss_driver);
> + if (r)
> + return r;
> +
> + r = dss_init_platform_driver();
> + if (r) {
> + DSSERR("Failed to initialize DSS platform driver\n");
> + goto err_dss;
> + }
> +
> + r = dispc_init_platform_driver();
> + if (r) {
> + DSSERR("Failed to initialize dispc platform driver\n");
> + goto err_dispc;
> + }
> +
> + r = rfbi_init_platform_driver();
> + if (r) {
> + DSSERR("Failed to initialize rfbi platform driver\n");
> + goto err_rfbi;
> + }
> +
> + r = venc_init_platform_driver();
> + if (r) {
> + DSSERR("Failed to initialize venc platform driver\n");
> + goto err_venc;
> + }
> +
> + r = dsi_init_platform_driver();
> + if (r) {
> + DSSERR("Failed to initialize DSI platform driver\n");
> + goto err_dsi;
> + }
> +
> + r = hdmi_init_platform_driver();
> + if (r) {
> + DSSERR("Failed to initialize hdmi\n");
> + goto err_hdmi;
> + }
> +
> + return 0;
> +
> +err_hdmi:
> + dsi_uninit_platform_driver();
> +err_dsi:
> + venc_uninit_platform_driver();
> +err_venc:
> + rfbi_uninit_platform_driver();
> +err_rfbi:
> + dispc_uninit_platform_driver();
> +err_dispc:
> + dss_uninit_platform_driver();
> +err_dss:
> + platform_driver_unregister(&omap_dss_driver);
> +
> + return r;
> +}
> +
> +static void __exit omap_dss_unregister_drivers(void)
> +{
> + hdmi_uninit_platform_driver();
> + dsi_uninit_platform_driver();
> + venc_uninit_platform_driver();
> + rfbi_uninit_platform_driver();
> + dispc_uninit_platform_driver();
> + dss_uninit_platform_driver();
> +
> + platform_driver_unregister(&omap_dss_driver);
> +}
> +
> #ifdef CONFIG_OMAP2_DSS_MODULE
> static void omap_dss_bus_unregister(void)
> {
> @@ -541,7 +560,7 @@ static int __init omap_dss_init(void)
> if (r)
> return r;
>
> - r = platform_driver_register(&omap_dss_driver);
> + r = omap_dss_register_drivers();
> if (r) {
> omap_dss_bus_unregister();
> return r;
> @@ -562,7 +581,7 @@ static void __exit omap_dss_exit(void)
> core.vdds_sdi_reg = NULL;
> }
>
> - platform_driver_unregister(&omap_dss_driver);
> + omap_dss_unregister_drivers();
>
> omap_dss_bus_unregister();
> }
> @@ -577,7 +596,7 @@ static int __init omap_dss_init(void)
>
> static int __init omap_dss_init2(void)
> {
> - return platform_driver_register(&omap_dss_driver);
> + return omap_dss_register_drivers();
> }
>
> core_initcall(omap_dss_init);
^ permalink raw reply
* Re: [PATCH] Added backlight driver for Acer Aspire 4736
From: Pradeep Subrahmanion @ 2012-03-21 19:21 UTC (permalink / raw)
To: joeyli
Cc: Matthew Garrett, rpurdie, FlorianSchandinat, akpm, linux-fbdev,
linux-kernel
In-Reply-To: <1332298845.10557.343.camel@linux-s257.site>
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset="windows-1254", Size: 5788 bytes --]
On Wed, 2012-03-21 at 11:00 +0800, joeyli wrote:
> æ–¼ 三，2012-03-21 æ–¼ 00:25 +0530，Pradeep Subrahmanion æ到：
> > > >From 5da43d2ee6c87dcf17fda34f0b50fe11b04a16bf Mon Sep 17 00:00:00 2001
> > > From: "Lee, Chun-Yi" <jlee@suse.com>
> > > Date: Tue, 20 Mar 2012 19:00:58 +0800
> > > Subject: [PATCH] acer-wmi: add quirk table for video backlight vendor mode
> > >
> > > There have some acer laptop have broken _BCM implemenation, the AML
> > > code wrote value to EC register but firmware didn't change brighenss.
> > >
> > > Fortunately, the brightness control works on those machines with
> > > vendor mode. So, add quirk table for video backlight vendor mode
> > > and unregister acpi video interface on those machines.
> > >
> > > Tested on Acer TravelMate 4750
> > >
> > > Signed-off-by: Lee, Chun-Yi <jlee@suse.com>
> > > ---
> > > drivers/platform/x86/Kconfig | 4 ++++
> > > drivers/platform/x86/acer-wmi.c | 38 +++++++++++++++++++++++++++++++++++---
> > > 2 files changed, 39 insertions(+), 3 deletions(-)
> > >
> > > diff --git a/drivers/platform/x86/Kconfig b/drivers/platform/x86/Kconfig
> > > index 15dbd8c..fe3a494 100644
> > > --- a/drivers/platform/x86/Kconfig
> > > +++ b/drivers/platform/x86/Kconfig
> > > @@ -26,6 +26,10 @@ config ACER_WMI
> > > depends on RFKILL || RFKILL = n
> > > depends on ACPI_WMI
> > > select INPUT_SPARSEKMAP
> > > + # Acer WMI depends on ACPI_VIDEO when ACPI is enabled
> > > + # but for select to work, need to select ACPI_VIDEO's dependencies, ick
> > > + select VIDEO_OUTPUT_CONTROL if ACPI
> > > + select ACPI_VIDEO if ACPI
> > > ---help---
> > > This is a driver for newer Acer (and Wistron) laptops. It adds
> > > wireless radio and bluetooth control, and on some laptops,
> > > diff --git a/drivers/platform/x86/acer-wmi.c b/drivers/platform/x86/acer-wmi.c
> > > index 1e5290b..984a7b5 100644
> > > --- a/drivers/platform/x86/acer-wmi.c
> > > +++ b/drivers/platform/x86/acer-wmi.c
> > > @@ -43,6 +43,7 @@
> > > #include <linux/input/sparse-keymap.h>
> > >
> > > #include <acpi/acpi_drivers.h>
> > > +#include <acpi/video.h>
> > >
> > > MODULE_AUTHOR("Carlos Corbacho");
> > > MODULE_DESCRIPTION("Acer Laptop WMI Extras Driver");
> > > @@ -478,6 +479,33 @@ static struct dmi_system_id acer_quirks[] = {
> > > {}
> > > };
> > >
> > > +static int video_set_backlight_video_vendor(const struct dmi_system_id *d)
> > > +{
> > > + interface->capability &= ~ACER_CAP_BRIGHTNESS;
> > > + pr_info("Brightness must be controlled by generic video driver\n");
> > > + return 0;
> > > +}
> > > +
> > > +static const struct dmi_system_id video_vendor_dmi_table[] = {
> > > + {
> > > + .callback = video_set_backlight_video_vendor,
> > > + .ident = "Acer Aspire 4736",
> > > + .matches = {
> > > + DMI_MATCH(DMI_BOARD_VENDOR, "Acer"),
> > > + DMI_MATCH(DMI_PRODUCT_NAME, "Aspire 4736"),
> > > + },
> > > + },
> > > + {
> > > + .callback = video_set_backlight_video_vendor,
> > > + .ident = "Acer TravelMate 4750",
> > > + .matches = {
> > > + DMI_MATCH(DMI_BOARD_VENDOR, "Acer"),
> > > + DMI_MATCH(DMI_PRODUCT_NAME, "TravelMate 4750"),
> > > + },
> > > + },
> > > + {}
> > > +};
> > > +
> > > /* Find which quirks are needed for a particular vendor/ model pair */
> > > static void find_quirks(void)
> > > {
> > > @@ -1981,9 +2009,13 @@ static int __init acer_wmi_init(void)
> > > set_quirks();
> > >
> > > if (acpi_video_backlight_support()) {
> > > - interface->capability &= ~ACER_CAP_BRIGHTNESS;
> > > - pr_info("Brightness must be controlled by "
> > > - "generic video driver\n");
> > > + if (dmi_check_system(video_vendor_dmi_table)) {
> > > + acpi_video_unregister();
> > > + } else {
> > > + interface->capability &= ~ACER_CAP_BRIGHTNESS;
> > > + pr_info("Brightness must be controlled by "
> > > + "acpi video driver\n");
> > > + }
> > > }
> > >
> > > if (wmi_has_guid(WMID_GUID3)) {
> >
> > I tried out applied your patch . Boot message shows ,
> >
> > [11.220410] acer_wmi: Brightness must be controlled by generic video
> > driver
> >
> > Now 'acpi_video0' and 'intel_backlight' are present
> > inside /sys/class/backlight .Hot key works like earlier ( ie problem
> > after maximum level still exists).
> > I tried following commands ,
> >
>
> It's not the expected behavior.
>
> This new patch should remove acpi_video0 interface on your machine.
> Please kindly provide your dmidecode:
> dmidecode > dmidecode.log
>
> And,
> please make should the patch really applied, you can do a bit change on
> pr_info message by yourself.
Sorry . I think there was some mistake . I tried the patch again. Now
I see only intel_backlight inside /sys/class/backlight. There is no
acer-wmi interface . Is this the expected behavior ? . Or am I missing
anything ?
>
> > echo 5 > /sys/class/backlight/acpi_video0/brightness
> > echo 5 > /sys/class/backlight/intel_backlight/brightness
> >
> > But it doesn't make any change .
> >
> > In my case , 'acpi_backlight = vendor' does not make any difference since the hot key control
> >
> > already starts working with 'acpi_osi=Linux' option.
> >
> > cat /proc/cmdline gives ,
> >
> > BOOT_IMAGE=/boot/vmlinuz-3.3.0+
> > root=UUIDð197a59-c067-4fd8-ad90-c4d721816077 ro acpi_osi=Linux
> >
> >
> > Thanks ,
> >
> > Pradeep Subrahmanion
> >
>
> OK, that's more clearly, please remove acpi_osi=Linux then re-test, I
> think the hotkey of backlight control only works with acpi_osi=Linux ?
>
>
> Thanks a lot!
> Joey Lee
>
>
Thanks ,
Pradeep Subrahmanion
--
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: Problem with framebuffer mmap on platforms with large addressing
From: Florian Tobias Schandinat @ 2012-03-21 19:45 UTC (permalink / raw)
To: Dmitry Eremin-Solenikov; +Cc: linux-fbdev, Tony Breeds, linuxppc-dev
In-Reply-To: <CALT56yPjkPQOaXW4Eg8c-S4+a4Omou_YYacqrsCoTAYeXO0XkA@mail.gmail.com>
On 03/19/2012 02:42 PM, Dmitry Eremin-Solenikov wrote:
> On Mon, Mar 19, 2012 at 12:49 AM, Benjamin Herrenschmidt
> <benh@kernel.crashing.org> wrote:
>> On Sun, 2012-03-18 at 18:04 +0400, Dmitry Eremin-Solenikov wrote:
>>> On Sun, Mar 18, 2012 at 4:46 AM, Benjamin Herrenschmidt
>>> <benh@kernel.crashing.org> wrote:
>>>> In fact, we could make the new structure such that it doesn't break
>>>> userspace compatibility with 64-bit architectures at all, ie, the "new"
>>>> and "compat" ioctl could remain entirely equivalent on 64-bit.
>>>
>>> I remember stuff about compat_ioctl, but I have never used/implemented
>>> that. Are there any details of requirements for the structures being passed?
>>
>> In that specific case, I meant something else. IE. The old ioctl could
>> remain unchanged, and the new ioctl make the same as the old one on
>> 64-bit platforms.
>
> I don't think this kind of magic would be good. I'd just stick to the new
> ioctl.
I finally found where we started to discuss this issue, for reference
"sm501fb.c: support mmap on PPC440SPe/PPC440EPx" back in May 2010.
The thing I don't remember is why we consider exporting the physical
address to userspace desirable (or even necessary). Fixing the generic
mmap would be trivial without breaking or adding any userspace ABI, I
think. Just adding those things to fb_info and adjusting fb_mmap should
do the trick, shouldn't it?
Best regards,
Florian Tobias Schandinat
^ permalink raw reply
* Re: Problem with framebuffer mmap on platforms with large addressing
From: Benjamin Herrenschmidt @ 2012-03-21 20:49 UTC (permalink / raw)
To: Florian Tobias Schandinat
Cc: linux-fbdev, Dmitry Eremin-Solenikov, Tony Breeds, linuxppc-dev
In-Reply-To: <4F6A2FEC.6040003@gmx.de>
On Wed, 2012-03-21 at 19:45 +0000, Florian Tobias Schandinat wrote:
> I finally found where we started to discuss this issue, for reference
> "sm501fb.c: support mmap on PPC440SPe/PPC440EPx" back in May 2010.
>
> The thing I don't remember is why we consider exporting the physical
> address to userspace desirable (or even necessary). Fixing the generic
> mmap would be trivial without breaking or adding any userspace ABI, I
> think. Just adding those things to fb_info and adjusting fb_mmap
> should
> do the trick, shouldn't it?
For historical reasons, things like X or directfb used it. Modern X
drivers shouldn't any more, but heh...
Cheers,
Ben.
^ permalink raw reply
* [PATCH] kyrofb: fix on x86_64
From: Ondrej Zary @ 2012-03-21 22:36 UTC (permalink / raw)
To: Paul Mundt
Cc: Florian Tobias Schandinat, linux-fbdev, Kernel development list
kyrofb is completely broken on x86_64 because the registers are defined as
unsigned long. Change them to u32 to make the driver work.
Tested with Hercules 3D Prophet 4000XT.
Signed-off-by: Ondrej Zary <linux@rainbow-software.org>
diff --git a/drivers/video/kyro/STG4000Reg.h b/drivers/video/kyro/STG4000Reg.h
index 5d62698..50f4670 100644
--- a/drivers/video/kyro/STG4000Reg.h
+++ b/drivers/video/kyro/STG4000Reg.h
@@ -73,210 +73,210 @@ typedef enum _OVRL_PIX_FORMAT {
/* Register Table */
typedef struct {
/* 0h */
- volatile unsigned long Thread0Enable; /* 0x0000 */
- volatile unsigned long Thread1Enable; /* 0x0004 */
- volatile unsigned long Thread0Recover; /* 0x0008 */
- volatile unsigned long Thread1Recover; /* 0x000C */
- volatile unsigned long Thread0Step; /* 0x0010 */
- volatile unsigned long Thread1Step; /* 0x0014 */
- volatile unsigned long VideoInStatus; /* 0x0018 */
- volatile unsigned long Core2InSignStart; /* 0x001C */
- volatile unsigned long Core1ResetVector; /* 0x0020 */
- volatile unsigned long Core1ROMOffset; /* 0x0024 */
- volatile unsigned long Core1ArbiterPriority; /* 0x0028 */
- volatile unsigned long VideoInControl; /* 0x002C */
- volatile unsigned long VideoInReg0CtrlA; /* 0x0030 */
- volatile unsigned long VideoInReg0CtrlB; /* 0x0034 */
- volatile unsigned long VideoInReg1CtrlA; /* 0x0038 */
- volatile unsigned long VideoInReg1CtrlB; /* 0x003C */
- volatile unsigned long Thread0Kicker; /* 0x0040 */
- volatile unsigned long Core2InputSign; /* 0x0044 */
- volatile unsigned long Thread0ProgCtr; /* 0x0048 */
- volatile unsigned long Thread1ProgCtr; /* 0x004C */
- volatile unsigned long Thread1Kicker; /* 0x0050 */
- volatile unsigned long GPRegister1; /* 0x0054 */
- volatile unsigned long GPRegister2; /* 0x0058 */
- volatile unsigned long GPRegister3; /* 0x005C */
- volatile unsigned long GPRegister4; /* 0x0060 */
- volatile unsigned long SerialIntA; /* 0x0064 */
-
- volatile unsigned long Fill0[6]; /* GAP 0x0068 - 0x007C */
-
- volatile unsigned long SoftwareReset; /* 0x0080 */
- volatile unsigned long SerialIntB; /* 0x0084 */
-
- volatile unsigned long Fill1[37]; /* GAP 0x0088 - 0x011C */
-
- volatile unsigned long ROMELQV; /* 0x011C */
- volatile unsigned long WLWH; /* 0x0120 */
- volatile unsigned long ROMELWL; /* 0x0124 */
-
- volatile unsigned long dwFill_1; /* GAP 0x0128 */
-
- volatile unsigned long IntStatus; /* 0x012C */
- volatile unsigned long IntMask; /* 0x0130 */
- volatile unsigned long IntClear; /* 0x0134 */
-
- volatile unsigned long Fill2[6]; /* GAP 0x0138 - 0x014C */
-
- volatile unsigned long ROMGPIOA; /* 0x0150 */
- volatile unsigned long ROMGPIOB; /* 0x0154 */
- volatile unsigned long ROMGPIOC; /* 0x0158 */
- volatile unsigned long ROMGPIOD; /* 0x015C */
-
- volatile unsigned long Fill3[2]; /* GAP 0x0160 - 0x0168 */
-
- volatile unsigned long AGPIntID; /* 0x0168 */
- volatile unsigned long AGPIntClassCode; /* 0x016C */
- volatile unsigned long AGPIntBIST; /* 0x0170 */
- volatile unsigned long AGPIntSSID; /* 0x0174 */
- volatile unsigned long AGPIntPMCSR; /* 0x0178 */
- volatile unsigned long VGAFrameBufBase; /* 0x017C */
- volatile unsigned long VGANotify; /* 0x0180 */
- volatile unsigned long DACPLLMode; /* 0x0184 */
- volatile unsigned long Core1VideoClockDiv; /* 0x0188 */
- volatile unsigned long AGPIntStat; /* 0x018C */
+ volatile u32 Thread0Enable; /* 0x0000 */
+ volatile u32 Thread1Enable; /* 0x0004 */
+ volatile u32 Thread0Recover; /* 0x0008 */
+ volatile u32 Thread1Recover; /* 0x000C */
+ volatile u32 Thread0Step; /* 0x0010 */
+ volatile u32 Thread1Step; /* 0x0014 */
+ volatile u32 VideoInStatus; /* 0x0018 */
+ volatile u32 Core2InSignStart; /* 0x001C */
+ volatile u32 Core1ResetVector; /* 0x0020 */
+ volatile u32 Core1ROMOffset; /* 0x0024 */
+ volatile u32 Core1ArbiterPriority; /* 0x0028 */
+ volatile u32 VideoInControl; /* 0x002C */
+ volatile u32 VideoInReg0CtrlA; /* 0x0030 */
+ volatile u32 VideoInReg0CtrlB; /* 0x0034 */
+ volatile u32 VideoInReg1CtrlA; /* 0x0038 */
+ volatile u32 VideoInReg1CtrlB; /* 0x003C */
+ volatile u32 Thread0Kicker; /* 0x0040 */
+ volatile u32 Core2InputSign; /* 0x0044 */
+ volatile u32 Thread0ProgCtr; /* 0x0048 */
+ volatile u32 Thread1ProgCtr; /* 0x004C */
+ volatile u32 Thread1Kicker; /* 0x0050 */
+ volatile u32 GPRegister1; /* 0x0054 */
+ volatile u32 GPRegister2; /* 0x0058 */
+ volatile u32 GPRegister3; /* 0x005C */
+ volatile u32 GPRegister4; /* 0x0060 */
+ volatile u32 SerialIntA; /* 0x0064 */
+
+ volatile u32 Fill0[6]; /* GAP 0x0068 - 0x007C */
+
+ volatile u32 SoftwareReset; /* 0x0080 */
+ volatile u32 SerialIntB; /* 0x0084 */
+
+ volatile u32 Fill1[37]; /* GAP 0x0088 - 0x011C */
+
+ volatile u32 ROMELQV; /* 0x011C */
+ volatile u32 WLWH; /* 0x0120 */
+ volatile u32 ROMELWL; /* 0x0124 */
+
+ volatile u32 dwFill_1; /* GAP 0x0128 */
+
+ volatile u32 IntStatus; /* 0x012C */
+ volatile u32 IntMask; /* 0x0130 */
+ volatile u32 IntClear; /* 0x0134 */
+
+ volatile u32 Fill2[6]; /* GAP 0x0138 - 0x014C */
+
+ volatile u32 ROMGPIOA; /* 0x0150 */
+ volatile u32 ROMGPIOB; /* 0x0154 */
+ volatile u32 ROMGPIOC; /* 0x0158 */
+ volatile u32 ROMGPIOD; /* 0x015C */
+
+ volatile u32 Fill3[2]; /* GAP 0x0160 - 0x0168 */
+
+ volatile u32 AGPIntID; /* 0x0168 */
+ volatile u32 AGPIntClassCode; /* 0x016C */
+ volatile u32 AGPIntBIST; /* 0x0170 */
+ volatile u32 AGPIntSSID; /* 0x0174 */
+ volatile u32 AGPIntPMCSR; /* 0x0178 */
+ volatile u32 VGAFrameBufBase; /* 0x017C */
+ volatile u32 VGANotify; /* 0x0180 */
+ volatile u32 DACPLLMode; /* 0x0184 */
+ volatile u32 Core1VideoClockDiv; /* 0x0188 */
+ volatile u32 AGPIntStat; /* 0x018C */
/*
- volatile unsigned long Fill4[0x0400/4 - 0x0190/4]; //GAP 0x0190 - 0x0400
- volatile unsigned long Fill5[0x05FC/4 - 0x0400/4]; //GAP 0x0400 - 0x05FC Fog Table
- volatile unsigned long Fill6[0x0604/4 - 0x0600/4]; //GAP 0x0600 - 0x0604
- volatile unsigned long Fill7[0x0680/4 - 0x0608/4]; //GAP 0x0608 - 0x0680
- volatile unsigned long Fill8[0x07FC/4 - 0x0684/4]; //GAP 0x0684 - 0x07FC
+ volatile u32 Fill4[0x0400/4 - 0x0190/4]; //GAP 0x0190 - 0x0400
+ volatile u32 Fill5[0x05FC/4 - 0x0400/4]; //GAP 0x0400 - 0x05FC Fog Table
+ volatile u32 Fill6[0x0604/4 - 0x0600/4]; //GAP 0x0600 - 0x0604
+ volatile u32 Fill7[0x0680/4 - 0x0608/4]; //GAP 0x0608 - 0x0680
+ volatile u32 Fill8[0x07FC/4 - 0x0684/4]; //GAP 0x0684 - 0x07FC
*/
- volatile unsigned long Fill4[412]; /* 0x0190 - 0x07FC */
-
- volatile unsigned long TACtrlStreamBase; /* 0x0800 */
- volatile unsigned long TAObjDataBase; /* 0x0804 */
- volatile unsigned long TAPtrDataBase; /* 0x0808 */
- volatile unsigned long TARegionDataBase; /* 0x080C */
- volatile unsigned long TATailPtrBase; /* 0x0810 */
- volatile unsigned long TAPtrRegionSize; /* 0x0814 */
- volatile unsigned long TAConfiguration; /* 0x0818 */
- volatile unsigned long TAObjDataStartAddr; /* 0x081C */
- volatile unsigned long TAObjDataEndAddr; /* 0x0820 */
- volatile unsigned long TAXScreenClip; /* 0x0824 */
- volatile unsigned long TAYScreenClip; /* 0x0828 */
- volatile unsigned long TARHWClamp; /* 0x082C */
- volatile unsigned long TARHWCompare; /* 0x0830 */
- volatile unsigned long TAStart; /* 0x0834 */
- volatile unsigned long TAObjReStart; /* 0x0838 */
- volatile unsigned long TAPtrReStart; /* 0x083C */
- volatile unsigned long TAStatus1; /* 0x0840 */
- volatile unsigned long TAStatus2; /* 0x0844 */
- volatile unsigned long TAIntStatus; /* 0x0848 */
- volatile unsigned long TAIntMask; /* 0x084C */
-
- volatile unsigned long Fill5[235]; /* GAP 0x0850 - 0x0BF8 */
-
- volatile unsigned long TextureAddrThresh; /* 0x0BFC */
- volatile unsigned long Core1Translation; /* 0x0C00 */
- volatile unsigned long TextureAddrReMap; /* 0x0C04 */
- volatile unsigned long RenderOutAGPRemap; /* 0x0C08 */
- volatile unsigned long _3DRegionReadTrans; /* 0x0C0C */
- volatile unsigned long _3DPtrReadTrans; /* 0x0C10 */
- volatile unsigned long _3DParamReadTrans; /* 0x0C14 */
- volatile unsigned long _3DRegionReadThresh; /* 0x0C18 */
- volatile unsigned long _3DPtrReadThresh; /* 0x0C1C */
- volatile unsigned long _3DParamReadThresh; /* 0x0C20 */
- volatile unsigned long _3DRegionReadAGPRemap; /* 0x0C24 */
- volatile unsigned long _3DPtrReadAGPRemap; /* 0x0C28 */
- volatile unsigned long _3DParamReadAGPRemap; /* 0x0C2C */
- volatile unsigned long ZBufferAGPRemap; /* 0x0C30 */
- volatile unsigned long TAIndexAGPRemap; /* 0x0C34 */
- volatile unsigned long TAVertexAGPRemap; /* 0x0C38 */
- volatile unsigned long TAUVAddrTrans; /* 0x0C3C */
- volatile unsigned long TATailPtrCacheTrans; /* 0x0C40 */
- volatile unsigned long TAParamWriteTrans; /* 0x0C44 */
- volatile unsigned long TAPtrWriteTrans; /* 0x0C48 */
- volatile unsigned long TAParamWriteThresh; /* 0x0C4C */
- volatile unsigned long TAPtrWriteThresh; /* 0x0C50 */
- volatile unsigned long TATailPtrCacheAGPRe; /* 0x0C54 */
- volatile unsigned long TAParamWriteAGPRe; /* 0x0C58 */
- volatile unsigned long TAPtrWriteAGPRe; /* 0x0C5C */
- volatile unsigned long SDRAMArbiterConf; /* 0x0C60 */
- volatile unsigned long SDRAMConf0; /* 0x0C64 */
- volatile unsigned long SDRAMConf1; /* 0x0C68 */
- volatile unsigned long SDRAMConf2; /* 0x0C6C */
- volatile unsigned long SDRAMRefresh; /* 0x0C70 */
- volatile unsigned long SDRAMPowerStat; /* 0x0C74 */
-
- volatile unsigned long Fill6[2]; /* GAP 0x0C78 - 0x0C7C */
-
- volatile unsigned long RAMBistData; /* 0x0C80 */
- volatile unsigned long RAMBistCtrl; /* 0x0C84 */
- volatile unsigned long FIFOBistKey; /* 0x0C88 */
- volatile unsigned long RAMBistResult; /* 0x0C8C */
- volatile unsigned long FIFOBistResult; /* 0x0C90 */
+ volatile u32 Fill4[412]; /* 0x0190 - 0x07FC */
+
+ volatile u32 TACtrlStreamBase; /* 0x0800 */
+ volatile u32 TAObjDataBase; /* 0x0804 */
+ volatile u32 TAPtrDataBase; /* 0x0808 */
+ volatile u32 TARegionDataBase; /* 0x080C */
+ volatile u32 TATailPtrBase; /* 0x0810 */
+ volatile u32 TAPtrRegionSize; /* 0x0814 */
+ volatile u32 TAConfiguration; /* 0x0818 */
+ volatile u32 TAObjDataStartAddr; /* 0x081C */
+ volatile u32 TAObjDataEndAddr; /* 0x0820 */
+ volatile u32 TAXScreenClip; /* 0x0824 */
+ volatile u32 TAYScreenClip; /* 0x0828 */
+ volatile u32 TARHWClamp; /* 0x082C */
+ volatile u32 TARHWCompare; /* 0x0830 */
+ volatile u32 TAStart; /* 0x0834 */
+ volatile u32 TAObjReStart; /* 0x0838 */
+ volatile u32 TAPtrReStart; /* 0x083C */
+ volatile u32 TAStatus1; /* 0x0840 */
+ volatile u32 TAStatus2; /* 0x0844 */
+ volatile u32 TAIntStatus; /* 0x0848 */
+ volatile u32 TAIntMask; /* 0x084C */
+
+ volatile u32 Fill5[235]; /* GAP 0x0850 - 0x0BF8 */
+
+ volatile u32 TextureAddrThresh; /* 0x0BFC */
+ volatile u32 Core1Translation; /* 0x0C00 */
+ volatile u32 TextureAddrReMap; /* 0x0C04 */
+ volatile u32 RenderOutAGPRemap; /* 0x0C08 */
+ volatile u32 _3DRegionReadTrans; /* 0x0C0C */
+ volatile u32 _3DPtrReadTrans; /* 0x0C10 */
+ volatile u32 _3DParamReadTrans; /* 0x0C14 */
+ volatile u32 _3DRegionReadThresh; /* 0x0C18 */
+ volatile u32 _3DPtrReadThresh; /* 0x0C1C */
+ volatile u32 _3DParamReadThresh; /* 0x0C20 */
+ volatile u32 _3DRegionReadAGPRemap; /* 0x0C24 */
+ volatile u32 _3DPtrReadAGPRemap; /* 0x0C28 */
+ volatile u32 _3DParamReadAGPRemap; /* 0x0C2C */
+ volatile u32 ZBufferAGPRemap; /* 0x0C30 */
+ volatile u32 TAIndexAGPRemap; /* 0x0C34 */
+ volatile u32 TAVertexAGPRemap; /* 0x0C38 */
+ volatile u32 TAUVAddrTrans; /* 0x0C3C */
+ volatile u32 TATailPtrCacheTrans; /* 0x0C40 */
+ volatile u32 TAParamWriteTrans; /* 0x0C44 */
+ volatile u32 TAPtrWriteTrans; /* 0x0C48 */
+ volatile u32 TAParamWriteThresh; /* 0x0C4C */
+ volatile u32 TAPtrWriteThresh; /* 0x0C50 */
+ volatile u32 TATailPtrCacheAGPRe; /* 0x0C54 */
+ volatile u32 TAParamWriteAGPRe; /* 0x0C58 */
+ volatile u32 TAPtrWriteAGPRe; /* 0x0C5C */
+ volatile u32 SDRAMArbiterConf; /* 0x0C60 */
+ volatile u32 SDRAMConf0; /* 0x0C64 */
+ volatile u32 SDRAMConf1; /* 0x0C68 */
+ volatile u32 SDRAMConf2; /* 0x0C6C */
+ volatile u32 SDRAMRefresh; /* 0x0C70 */
+ volatile u32 SDRAMPowerStat; /* 0x0C74 */
+
+ volatile u32 Fill6[2]; /* GAP 0x0C78 - 0x0C7C */
+
+ volatile u32 RAMBistData; /* 0x0C80 */
+ volatile u32 RAMBistCtrl; /* 0x0C84 */
+ volatile u32 FIFOBistKey; /* 0x0C88 */
+ volatile u32 RAMBistResult; /* 0x0C8C */
+ volatile u32 FIFOBistResult; /* 0x0C90 */
/*
- volatile unsigned long Fill11[0x0CBC/4 - 0x0C94/4]; //GAP 0x0C94 - 0x0CBC
- volatile unsigned long Fill12[0x0CD0/4 - 0x0CC0/4]; //GAP 0x0CC0 - 0x0CD0 3DRegisters
+ volatile u32 Fill11[0x0CBC/4 - 0x0C94/4]; //GAP 0x0C94 - 0x0CBC
+ volatile u32 Fill12[0x0CD0/4 - 0x0CC0/4]; //GAP 0x0CC0 - 0x0CD0 3DRegisters
*/
- volatile unsigned long Fill7[16]; /* 0x0c94 - 0x0cd0 */
+ volatile u32 Fill7[16]; /* 0x0c94 - 0x0cd0 */
- volatile unsigned long SDRAMAddrSign; /* 0x0CD4 */
- volatile unsigned long SDRAMDataSign; /* 0x0CD8 */
- volatile unsigned long SDRAMSignConf; /* 0x0CDC */
+ volatile u32 SDRAMAddrSign; /* 0x0CD4 */
+ volatile u32 SDRAMDataSign; /* 0x0CD8 */
+ volatile u32 SDRAMSignConf; /* 0x0CDC */
/* DWFILL; //GAP 0x0CE0 */
- volatile unsigned long dwFill_2;
-
- volatile unsigned long ISPSignature; /* 0x0CE4 */
-
- volatile unsigned long Fill8[454]; /*GAP 0x0CE8 - 0x13FC */
-
- volatile unsigned long DACPrimAddress; /* 0x1400 */
- volatile unsigned long DACPrimSize; /* 0x1404 */
- volatile unsigned long DACCursorAddr; /* 0x1408 */
- volatile unsigned long DACCursorCtrl; /* 0x140C */
- volatile unsigned long DACOverlayAddr; /* 0x1410 */
- volatile unsigned long DACOverlayUAddr; /* 0x1414 */
- volatile unsigned long DACOverlayVAddr; /* 0x1418 */
- volatile unsigned long DACOverlaySize; /* 0x141C */
- volatile unsigned long DACOverlayVtDec; /* 0x1420 */
-
- volatile unsigned long Fill9[9]; /* GAP 0x1424 - 0x1444 */
-
- volatile unsigned long DACVerticalScal; /* 0x1448 */
- volatile unsigned long DACPixelFormat; /* 0x144C */
- volatile unsigned long DACHorizontalScal; /* 0x1450 */
- volatile unsigned long DACVidWinStart; /* 0x1454 */
- volatile unsigned long DACVidWinEnd; /* 0x1458 */
- volatile unsigned long DACBlendCtrl; /* 0x145C */
- volatile unsigned long DACHorTim1; /* 0x1460 */
- volatile unsigned long DACHorTim2; /* 0x1464 */
- volatile unsigned long DACHorTim3; /* 0x1468 */
- volatile unsigned long DACVerTim1; /* 0x146C */
- volatile unsigned long DACVerTim2; /* 0x1470 */
- volatile unsigned long DACVerTim3; /* 0x1474 */
- volatile unsigned long DACBorderColor; /* 0x1478 */
- volatile unsigned long DACSyncCtrl; /* 0x147C */
- volatile unsigned long DACStreamCtrl; /* 0x1480 */
- volatile unsigned long DACLUTAddress; /* 0x1484 */
- volatile unsigned long DACLUTData; /* 0x1488 */
- volatile unsigned long DACBurstCtrl; /* 0x148C */
- volatile unsigned long DACCrcTrigger; /* 0x1490 */
- volatile unsigned long DACCrcDone; /* 0x1494 */
- volatile unsigned long DACCrcResult1; /* 0x1498 */
- volatile unsigned long DACCrcResult2; /* 0x149C */
- volatile unsigned long DACLinecount; /* 0x14A0 */
-
- volatile unsigned long Fill10[151]; /*GAP 0x14A4 - 0x16FC */
-
- volatile unsigned long DigVidPortCtrl; /* 0x1700 */
- volatile unsigned long DigVidPortStat; /* 0x1704 */
+ volatile u32 dwFill_2;
+
+ volatile u32 ISPSignature; /* 0x0CE4 */
+
+ volatile u32 Fill8[454]; /*GAP 0x0CE8 - 0x13FC */
+
+ volatile u32 DACPrimAddress; /* 0x1400 */
+ volatile u32 DACPrimSize; /* 0x1404 */
+ volatile u32 DACCursorAddr; /* 0x1408 */
+ volatile u32 DACCursorCtrl; /* 0x140C */
+ volatile u32 DACOverlayAddr; /* 0x1410 */
+ volatile u32 DACOverlayUAddr; /* 0x1414 */
+ volatile u32 DACOverlayVAddr; /* 0x1418 */
+ volatile u32 DACOverlaySize; /* 0x141C */
+ volatile u32 DACOverlayVtDec; /* 0x1420 */
+
+ volatile u32 Fill9[9]; /* GAP 0x1424 - 0x1444 */
+
+ volatile u32 DACVerticalScal; /* 0x1448 */
+ volatile u32 DACPixelFormat; /* 0x144C */
+ volatile u32 DACHorizontalScal; /* 0x1450 */
+ volatile u32 DACVidWinStart; /* 0x1454 */
+ volatile u32 DACVidWinEnd; /* 0x1458 */
+ volatile u32 DACBlendCtrl; /* 0x145C */
+ volatile u32 DACHorTim1; /* 0x1460 */
+ volatile u32 DACHorTim2; /* 0x1464 */
+ volatile u32 DACHorTim3; /* 0x1468 */
+ volatile u32 DACVerTim1; /* 0x146C */
+ volatile u32 DACVerTim2; /* 0x1470 */
+ volatile u32 DACVerTim3; /* 0x1474 */
+ volatile u32 DACBorderColor; /* 0x1478 */
+ volatile u32 DACSyncCtrl; /* 0x147C */
+ volatile u32 DACStreamCtrl; /* 0x1480 */
+ volatile u32 DACLUTAddress; /* 0x1484 */
+ volatile u32 DACLUTData; /* 0x1488 */
+ volatile u32 DACBurstCtrl; /* 0x148C */
+ volatile u32 DACCrcTrigger; /* 0x1490 */
+ volatile u32 DACCrcDone; /* 0x1494 */
+ volatile u32 DACCrcResult1; /* 0x1498 */
+ volatile u32 DACCrcResult2; /* 0x149C */
+ volatile u32 DACLinecount; /* 0x14A0 */
+
+ volatile u32 Fill10[151]; /*GAP 0x14A4 - 0x16FC */
+
+ volatile u32 DigVidPortCtrl; /* 0x1700 */
+ volatile u32 DigVidPortStat; /* 0x1704 */
/*
- volatile unsigned long Fill11[0x1FFC/4 - 0x1708/4]; //GAP 0x1708 - 0x1FFC
- volatile unsigned long Fill17[0x3000/4 - 0x2FFC/4]; //GAP 0x2000 - 0x2FFC ALUT
+ volatile u32 Fill11[0x1FFC/4 - 0x1708/4]; //GAP 0x1708 - 0x1FFC
+ volatile u32 Fill17[0x3000/4 - 0x2FFC/4]; //GAP 0x2000 - 0x2FFC ALUT
*/
- volatile unsigned long Fill11[1598];
+ volatile u32 Fill11[1598];
/* DWFILL; //GAP 0x3000 ALUT 256MB offset */
- volatile unsigned long Fill_3;
+ volatile u32 Fill_3;
} STG4000REG;
--
Ondrej Zary
^ permalink raw reply related
* Re: Radeon fb issue: invalid framebuffer id kernel 3.2.12
From: Fabio Coatti @ 2012-03-21 23:01 UTC (permalink / raw)
To: linux-fbdev
In-Reply-To: <CADpTngU6fL3r3cHsH3B6Hx68Bm4R_baoBeVmvGf6bUJPV3CXbA@mail.gmail.com>
2012/3/19 Dave Airlie <airlied@gmail.com>:
>> Hi all,
>> I'm setting up a new laptot with Advanced Micro Devices [AMD] nee ATI
>> Seymour [Radeon HD 6400M Series] card, using radeon drivers. I'm
>> facing an issue for wich I found a lot of references but no actual
>> solution, so I'm asking here for some help
>
> the invalid framebuffer id isn't fatal, however it sounds like you
> haven't got CONFIG_FRAMEBUFFER_CONSOLE
> or haven't loaded fbcon.
Indeed your'e right. I was confused by the error and i didn't looked
in the right and obvious place, silly me.
Thanks for the heads up!
--
Fabio
^ permalink raw reply
* Re: [PATCH] kyrofb: fix on x86_64
From: Paul Mundt @ 2012-03-22 0:01 UTC (permalink / raw)
To: Ondrej Zary
Cc: Florian Tobias Schandinat, linux-fbdev, Kernel development list
In-Reply-To: <201203212336.55396.linux@rainbow-software.org>
On Wed, Mar 21, 2012 at 11:36:50PM +0100, Ondrej Zary wrote:
> kyrofb is completely broken on x86_64 because the registers are defined as
> unsigned long. Change them to u32 to make the driver work.
> Tested with Hercules 3D Prophet 4000XT.
>
> Signed-off-by: Ondrej Zary <linux@rainbow-software.org>
>
Looks fine to me.
Acked-by: Paul Mundt <lethal@linux-sh.org>
^ permalink raw reply
* Re: [PATCH] x86: export 'pcibios_enabled'
From: Wang YanQing @ 2012-03-22 0:41 UTC (permalink / raw)
To: Alan Cox
Cc: Florian Tobias Schandinat, H. Peter Anvin, Randy Dunlap,
Stephen Rothwell, linux-next, LKML, Michal Januszewski,
linux-fbdev, x86, Andrew Morton
In-Reply-To: <20120314112137.68fa4f70@pyramind.ukuu.org.uk>
On Wed, Mar 14, 2012 at 11:21:37AM +0000, Alan Cox wrote:
> You can use set_memory_x() to mark memory executable (and _nx to set it back).
>
NO I can't, if I set_memory_x and don't set pcibios_enabled = 1, then
static_protections will still failed because pcibios_enabled = 0,
and I don't want to use set_memory_x, because I don't want to give the user
of uvesafb that feeling "I will lost BIOS NX protection if I choice uvesafb."
> If you really need to know if NX is being used then the check
>
> if (__supported_pte_mask & PTE_NX)
>
> will do the trick and the variable is exported.
I don't understand what do you mean, do you means CONFIG_X86_PAE for 32? Or CONFIG_X86_64?
when NX is being used, the pci bios is NX or not also depend on
ACPI.ACPI on or off all will influnce the code path in pci_arch_init,
decide the set_bios_x have chance to execute or not.See
https://lkml.org/lkml/2011/11/16/84
By the way _PAGE_NX instead of PTE_NX, right?
> I'd suggest however you wrap that in a cpu_has_nx() type macro somewhere
> in the arch headers.
>
The same above.
> If you go poking around pcibios values you are going to get burned if
> someone is ever bored enough to make NX and PCIBIOS work together
> differently.
>
Indeed according to 5bd5a452662bc37c54fb6828db1a3faf87e6511c, who bring me
the trouble, check the pcibios_enabled is the only simple and good way to
resolve the Oops I meet.
If you really don't want it, and if I am not all wrong about your "helper method",
you means you want export the below:
int check_pcibios_enabled()?
See https://lkml.org/lkml/2012/2/26/124
Thanks.
^ permalink raw reply
* Re: [PATCH] Added backlight driver for Acer Aspire 4736
From: joeyli @ 2012-03-22 1:33 UTC (permalink / raw)
To: Pradeep Subrahmanion
Cc: Matthew Garrett, rpurdie, FlorianSchandinat, akpm, linux-fbdev,
linux-kernel
In-Reply-To: <1332356993.3103.23.camel@debian.Gayathri>
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset="windows-1254", Size: 1731 bytes --]
æ–¼ 四，2012-03-22 æ–¼ 00:39 +0530，Pradeep Subrahmanion æ到：
> > This new patch should remove acpi_video0 interface on your machine.
> > Please kindly provide your dmidecode:
> > dmidecode > dmidecode.log
> >
> > And,
> > please make should the patch really applied, you can do a bit change on
> > pr_info message by yourself.
>
> Sorry . I think there was some mistake . I tried the patch again. Now
> I see only intel_backlight inside /sys/class/backlight. There is no
> acer-wmi interface . Is this the expected behavior ? . Or am I missing
> anything ?
>
Yes, this is the expected behavior! But, now I doubt your issue was
workaround by acpi_osi=Linux but not intel_backlight.
>
>
> >
> > > echo 5 > /sys/class/backlight/acpi_video0/brightness
> > > echo 5 > /sys/class/backlight/intel_backlight/brightness
> > >
> > > But it doesn't make any change .
> > >
> > > In my case , 'acpi_backlight = vendor' does not make any difference since the hot key control
> > >
> > > already starts working with 'acpi_osi=Linux' option.
> > >
> > > cat /proc/cmdline gives ,
> > >
> > > BOOT_IMAGE=/boot/vmlinuz-3.3.0+
> > > root=UUIDð197a59-c067-4fd8-ad90-c4d721816077 ro acpi_osi=Linux
> > >
> > >
> > > Thanks ,
> > >
> > > Pradeep Subrahmanion
> > >
> >
> > OK, that's more clearly, please remove acpi_osi=Linux then re-test, I
> > think the hotkey of backlight control only works with acpi_osi=Linux ?
> >
Does your backlight control still work if you remove acpi_osi=Linux ?
Thanks a lot!
Joey Lee
--
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] Added backlight driver for Acer Aspire 4736
From: Pradeep Subrahmanion @ 2012-03-22 2:45 UTC (permalink / raw)
To: joeyli
Cc: Matthew Garrett, rpurdie, FlorianSchandinat, akpm, linux-fbdev,
linux-kernel
In-Reply-To: <1332380037.10557.398.camel@linux-s257.site>
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset="windows-1254", Size: 1987 bytes --]
On Thu, 2012-03-22 at 09:33 +0800, joeyli wrote:
> æ–¼ 四，2012-03-22 æ–¼ 00:39 +0530，Pradeep Subrahmanion æ到：
> > > This new patch should remove acpi_video0 interface on your machine.
> > > Please kindly provide your dmidecode:
> > > dmidecode > dmidecode.log
> > >
> > > And,
> > > please make should the patch really applied, you can do a bit change on
> > > pr_info message by yourself.
> >
> > Sorry . I think there was some mistake . I tried the patch again. Now
> > I see only intel_backlight inside /sys/class/backlight. There is no
> > acer-wmi interface . Is this the expected behavior ? . Or am I missing
> > anything ?
> >
>
> Yes, this is the expected behavior! But, now I doubt your issue was
> workaround by acpi_osi=Linux but not intel_backlight.
>
> >
> >
> > >
> > > > echo 5 > /sys/class/backlight/acpi_video0/brightness
> > > > echo 5 > /sys/class/backlight/intel_backlight/brightness
> > > >
> > > > But it doesn't make any change .
> > > >
> > > > In my case , 'acpi_backlight = vendor' does not make any difference since the hot key control
> > > >
> > > > already starts working with 'acpi_osi=Linux' option.
> > > >
> > > > cat /proc/cmdline gives ,
> > > >
> > > > BOOT_IMAGE=/boot/vmlinuz-3.3.0+
> > > > root=UUIDð197a59-c067-4fd8-ad90-c4d721816077 ro acpi_osi=Linux
> > > >
> > > >
> > > > Thanks ,
> > > >
> > > > Pradeep Subrahmanion
> > > >
> > >
> > > OK, that's more clearly, please remove acpi_osi=Linux then re-test, I
> > > think the hotkey of backlight control only works with acpi_osi=Linux ?
> > >
>
> Does your backlight control still work if you remove acpi_osi=Linux ?
If I remove acpi_osi=Linux , the hot key control stops working .
>
>
> Thanks a lot!
> Joey Lee
>
Thanks ,
Pradeep Subrahmanion
--
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] Added backlight driver for Acer Aspire 4736
From: joeyli @ 2012-03-22 3:25 UTC (permalink / raw)
To: Pradeep Subrahmanion
Cc: Matthew Garrett, rpurdie, FlorianSchandinat, akpm, linux-fbdev,
linux-kernel
In-Reply-To: <1332383623.2622.6.camel@debian.Gayathri>
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset="windows-1254", Size: 2199 bytes --]
æ–¼ 四，2012-03-22 æ–¼ 08:03 +0530，Pradeep Subrahmanion æ到：
> On Thu, 2012-03-22 at 09:33 +0800, joeyli wrote:
> > æ–¼ 四，2012-03-22 æ–¼ 00:39 +0530，Pradeep Subrahmanion æ到：
> > > > This new patch should remove acpi_video0 interface on your machine.
> > > > Please kindly provide your dmidecode:
> > > > dmidecode > dmidecode.log
> > > >
> > > > And,
> > > > please make should the patch really applied, you can do a bit change on
> > > > pr_info message by yourself.
> > >
> > > Sorry . I think there was some mistake . I tried the patch again. Now
> > > I see only intel_backlight inside /sys/class/backlight. There is no
> > > acer-wmi interface . Is this the expected behavior ? . Or am I missing
> > > anything ?
> > >
> >
> > Yes, this is the expected behavior! But, now I doubt your issue was
> > workaround by acpi_osi=Linux but not intel_backlight.
> >
>
> > >
> > >
> > > >
> > > > > echo 5 > /sys/class/backlight/acpi_video0/brightness
> > > > > echo 5 > /sys/class/backlight/intel_backlight/brightness
> > > > >
> > > > > But it doesn't make any change .
> > > > >
> > > > > In my case , 'acpi_backlight = vendor' does not make any difference since the hot key control
> > > > >
> > > > > already starts working with 'acpi_osi=Linux' option.
> > > > >
> > > > > cat /proc/cmdline gives ,
> > > > >
> > > > > BOOT_IMAGE=/boot/vmlinuz-3.3.0+
> > > > > root=UUIDð197a59-c067-4fd8-ad90-c4d721816077 ro acpi_osi=Linux
> > > > >
> > > > >
> > > > > Thanks ,
> > > > >
> > > > > Pradeep Subrahmanion
> > > > >
> > > >
> > > > OK, that's more clearly, please remove acpi_osi=Linux then re-test, I
> > > > think the hotkey of backlight control only works with acpi_osi=Linux ?
> > > >
> >
> > Does your backlight control still work if you remove acpi_osi=Linux ?
>
> If I remove acpi_osi=Linux , the hot key control stops working .
>
What is the preload OS in your machine when you bought it? Windows XP,
Vista or Windows 7?
thanks
Joey Lee
--
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] Added backlight driver for Acer Aspire 4736
From: Pradeep Subrahmanion @ 2012-03-22 3:44 UTC (permalink / raw)
To: joeyli
Cc: Matthew Garrett, rpurdie, FlorianSchandinat, akpm, linux-fbdev,
linux-kernel
In-Reply-To: <1332386725.10557.402.camel@linux-s257.site>
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset="windows-1254", Size: 2429 bytes --]
On Thu, 2012-03-22 at 11:25 +0800, joeyli wrote:
> æ–¼ 四，2012-03-22 æ–¼ 08:03 +0530，Pradeep Subrahmanion æ到：
> > On Thu, 2012-03-22 at 09:33 +0800, joeyli wrote:
> > > æ–¼ 四，2012-03-22 æ–¼ 00:39 +0530，Pradeep Subrahmanion æ到：
> > > > > This new patch should remove acpi_video0 interface on your machine.
> > > > > Please kindly provide your dmidecode:
> > > > > dmidecode > dmidecode.log
> > > > >
> > > > > And,
> > > > > please make should the patch really applied, you can do a bit change on
> > > > > pr_info message by yourself.
> > > >
> > > > Sorry . I think there was some mistake . I tried the patch again. Now
> > > > I see only intel_backlight inside /sys/class/backlight. There is no
> > > > acer-wmi interface . Is this the expected behavior ? . Or am I missing
> > > > anything ?
> > > >
> > >
> > > Yes, this is the expected behavior! But, now I doubt your issue was
> > > workaround by acpi_osi=Linux but not intel_backlight.
> > >
> >
> > > >
> > > >
> > > > >
> > > > > > echo 5 > /sys/class/backlight/acpi_video0/brightness
> > > > > > echo 5 > /sys/class/backlight/intel_backlight/brightness
> > > > > >
> > > > > > But it doesn't make any change .
> > > > > >
> > > > > > In my case , 'acpi_backlight = vendor' does not make any difference since the hot key control
> > > > > >
> > > > > > already starts working with 'acpi_osi=Linux' option.
> > > > > >
> > > > > > cat /proc/cmdline gives ,
> > > > > >
> > > > > > BOOT_IMAGE=/boot/vmlinuz-3.3.0+
> > > > > > root=UUIDð197a59-c067-4fd8-ad90-c4d721816077 ro acpi_osi=Linux
> > > > > >
> > > > > >
> > > > > > Thanks ,
> > > > > >
> > > > > > Pradeep Subrahmanion
> > > > > >
> > > > >
> > > > > OK, that's more clearly, please remove acpi_osi=Linux then re-test, I
> > > > > think the hotkey of backlight control only works with acpi_osi=Linux ?
> > > > >
> > >
> > > Does your backlight control still work if you remove acpi_osi=Linux ?
> >
> > If I remove acpi_osi=Linux , the hot key control stops working .
> >
>
> What is the preload OS in your machine when you bought it? Windows XP,
> Vista or Windows 7?
It was Windows XP.
>
>
> thanks
> Joey Lee
>
Thanks ,
Pradeep Subrahmanion
--
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] Added backlight driver for Acer Aspire 4736
From: joeyli @ 2012-03-22 3:54 UTC (permalink / raw)
To: Pradeep Subrahmanion
Cc: Matthew Garrett, rpurdie, FlorianSchandinat, akpm, linux-fbdev,
linux-kernel
In-Reply-To: <1332387122.2622.9.camel@debian.Gayathri>
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset="windows-1254", Size: 2783 bytes --]
æ–¼ 四，2012-03-22 æ–¼ 09:02 +0530，Pradeep Subrahmanion æ到：
> On Thu, 2012-03-22 at 11:25 +0800, joeyli wrote:
> > æ–¼ 四，2012-03-22 æ–¼ 08:03 +0530，Pradeep Subrahmanion æ到：
> > > On Thu, 2012-03-22 at 09:33 +0800, joeyli wrote:
> > > > æ–¼ 四，2012-03-22 æ–¼ 00:39 +0530，Pradeep Subrahmanion æ到：
> > > > > > This new patch should remove acpi_video0 interface on your machine.
> > > > > > Please kindly provide your dmidecode:
> > > > > > dmidecode > dmidecode.log
> > > > > >
> > > > > > And,
> > > > > > please make should the patch really applied, you can do a bit change on
> > > > > > pr_info message by yourself.
> > > > >
> > > > > Sorry . I think there was some mistake . I tried the patch again. Now
> > > > > I see only intel_backlight inside /sys/class/backlight. There is no
> > > > > acer-wmi interface . Is this the expected behavior ? . Or am I missing
> > > > > anything ?
> > > > >
> > > >
> > > > Yes, this is the expected behavior! But, now I doubt your issue was
> > > > workaround by acpi_osi=Linux but not intel_backlight.
> > > >
> > >
> > > > >
> > > > >
> > > > > >
> > > > > > > echo 5 > /sys/class/backlight/acpi_video0/brightness
> > > > > > > echo 5 > /sys/class/backlight/intel_backlight/brightness
> > > > > > >
> > > > > > > But it doesn't make any change .
> > > > > > >
> > > > > > > In my case , 'acpi_backlight = vendor' does not make any difference since the hot key control
> > > > > > >
> > > > > > > already starts working with 'acpi_osi=Linux' option.
> > > > > > >
> > > > > > > cat /proc/cmdline gives ,
> > > > > > >
> > > > > > > BOOT_IMAGE=/boot/vmlinuz-3.3.0+
> > > > > > > root=UUIDð197a59-c067-4fd8-ad90-c4d721816077 ro acpi_osi=Linux
> > > > > > >
> > > > > > >
> > > > > > > Thanks ,
> > > > > > >
> > > > > > > Pradeep Subrahmanion
> > > > > > >
> > > > > >
> > > > > > OK, that's more clearly, please remove acpi_osi=Linux then re-test, I
> > > > > > think the hotkey of backlight control only works with acpi_osi=Linux ?
> > > > > >
> > > >
> > > > Does your backlight control still work if you remove acpi_osi=Linux ?
> > >
> > > If I remove acpi_osi=Linux , the hot key control stops working .
> > >
> >
> > What is the preload OS in your machine when you bought it? Windows XP,
> > Vista or Windows 7?
>
> It was Windows XP.
>
The WDDM driver didn't support by Windows XP, the brightness control on
XP should works with _BCM or OpRegion.
Wonder how does brightness control work on XP with your machine.
I will dig more in your dsdt...
Thanks
Joey Lee
--
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] Added backlight driver for Acer Aspire 4736
From: Pradeep Subrahmanion @ 2012-03-22 5:57 UTC (permalink / raw)
To: joeyli
Cc: Matthew Garrett, rpurdie, FlorianSchandinat, akpm, linux-fbdev,
linux-kernel
In-Reply-To: <1332388489.10557.406.camel@linux-s257.site>
From acer acpi ,I came to know that the 4730 series uses new wmi interface .
http://code.google.com/p/aceracpi/wiki/SupportedHardware
Thanks ,
Pradeep Subrahmanion
On Thu, Mar 22, 2012 at 9:24 AM, joeyli <jlee@suse.com> wrote:
> ©ó ¥|¡A2012-03-22 ©ó 09:02 +0530¡APradeep Subrahmanion ´£¨ì¡G
>> On Thu, 2012-03-22 at 11:25 +0800, joeyli wrote:
>> > ©ó ¥|¡A2012-03-22 ©ó 08:03 +0530¡APradeep Subrahmanion ´£¨ì¡G
>> > > On Thu, 2012-03-22 at 09:33 +0800, joeyli wrote:
>> > > > ©ó ¥|¡A2012-03-22 ©ó 00:39 +0530¡APradeep Subrahmanion ´£¨ì¡G
>> > > > > > This new patch should remove acpi_video0 interface on your machine.
>> > > > > > Please kindly provide your dmidecode:
>> > > > > > dmidecode > dmidecode.log
>> > > > > >
>> > > > > > And,
>> > > > > > please make should the patch really applied, you can do a bit change on
>> > > > > > pr_info message by yourself.
>> > > > >
>> > > > > Sorry . I think there was some mistake . I tried the patch again. Now
>> > > > > I see only intel_backlight inside /sys/class/backlight. There is no
>> > > > > acer-wmi interface . Is this the expected behavior ? . Or am I missing
>> > > > > anything ?
>> > > > >
>> > > >
>> > > > Yes, this is the expected behavior! But, now I doubt your issue was
>> > > > workaround by acpi_osi=Linux but not intel_backlight.
>> > > >
>> > >
>> > > > >
>> > > > >
>> > > > > >
>> > > > > > > echo 5 > /sys/class/backlight/acpi_video0/brightness
>> > > > > > > echo 5 > /sys/class/backlight/intel_backlight/brightness
>> > > > > > >
>> > > > > > > But it doesn't make any change .
>> > > > > > >
>> > > > > > > In my case , 'acpi_backlight = vendor' does not make any difference since the hot key control
>> > > > > > >
>> > > > > > > already starts working with 'acpi_osi=Linux' option.
>> > > > > > >
>> > > > > > > cat /proc/cmdline gives ,
>> > > > > > >
>> > > > > > > BOOT_IMAGE=/boot/vmlinuz-3.3.0+
>> > > > > > > root=UUIDð197a59-c067-4fd8-ad90-c4d721816077 ro acpi_osi=Linux
>> > > > > > >
>> > > > > > >
>> > > > > > > Thanks ,
>> > > > > > >
>> > > > > > > Pradeep Subrahmanion
>> > > > > > >
>> > > > > >
>> > > > > > OK, that's more clearly, please remove acpi_osi=Linux then re-test, I
>> > > > > > think the hotkey of backlight control only works with acpi_osi=Linux ?
>> > > > > >
>> > > >
>> > > > Does your backlight control still work if you remove acpi_osi=Linux ?
>> > >
>> > > If I remove acpi_osi=Linux , the hot key control stops working .
>> > >
>> >
>> > What is the preload OS in your machine when you bought it? Windows XP,
>> > Vista or Windows 7?
>>
>> It was Windows XP.
>>
>
> The WDDM driver didn't support by Windows XP, the brightness control on
> XP should works with _BCM or OpRegion.
>
> Wonder how does brightness control work on XP with your machine.
>
> I will dig more in your dsdt...
>
>
> Thanks
> Joey Lee
>
^ permalink raw reply
* Re: [PATCH v2] udlfb: Fix invalid return codes in edid sysfs entry store function
From: Olivier Sobrie @ 2012-03-22 7:32 UTC (permalink / raw)
To: linux-fbdev
In-Reply-To: <1330499200-20819-1-git-send-email-olivier@sobrie.be>
On Wed, Mar 21, 2012 at 06:29:39PM +0000, Florian Tobias Schandinat wrote:
> On 02/29/2012 07:06 AM, Olivier Sobrie wrote:
> > Return a negative errno instead of zero in the write function of
> > the sysfs entry in case of error.
> > Also add a check on the return value of dlfb_setup_modes().
> >
> > Signed-off-by: Olivier Sobrie <olivier@sobrie.be>
>
> As Bernie did agree in the pull request, I applied this patch.
ok!
Thank you,
--
Olivier
^ permalink raw reply
* Re: [PATCH] Added backlight driver for Acer Aspire 4736
From: joeyli @ 2012-03-22 9:34 UTC (permalink / raw)
To: Pradeep Subrahmanion
Cc: Matthew Garrett, rpurdie, FlorianSchandinat, akpm, linux-fbdev,
linux-kernel
In-Reply-To: <CABNxG=D-JJgD72Wv3hpui0CiprW25MvBzCKcNt-+twAD72+Eyg@mail.gmail.com>
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset="windows-1254", Size: 3447 bytes --]
æ–¼ 四，2012-03-22 æ–¼ 11:26 +0530，Pradeep Subrahmanion æ到：
> >From acer acpi ,I came to know that the 4730 series uses new wmi interface .
>
> http://code.google.com/p/aceracpi/wiki/SupportedHardware
>
I am not sure what is the WMIDv2, but it's not the current WMI v2 in
acer-wmi driver.
> Thanks ,
>
> Pradeep Subrahmanion
>
> On Thu, Mar 22, 2012 at 9:24 AM, joeyli <jlee@suse.com> wrote:
> > æ–¼ 四，2012-03-22 æ–¼ 09:02 +0530，Pradeep Subrahmanion æ到：
> >> On Thu, 2012-03-22 at 11:25 +0800, joeyli wrote:
> >> > æ–¼ 四，2012-03-22 æ–¼ 08:03 +0530，Pradeep Subrahmanion æ到：
> >> > > On Thu, 2012-03-22 at 09:33 +0800, joeyli wrote:
> >> > > > æ–¼ 四，2012-03-22 æ–¼ 00:39 +0530，Pradeep Subrahmanion æ到：
> >> > > > > > This new patch should remove acpi_video0 interface on your machine.
> >> > > > > > Please kindly provide your dmidecode:
> >> > > > > > dmidecode > dmidecode.log
> >> > > > > >
> >> > > > > > And,
> >> > > > > > please make should the patch really applied, you can do a bit change on
> >> > > > > > pr_info message by yourself.
> >> > > > >
> >> > > > > Sorry . I think there was some mistake . I tried the patch again. Now
> >> > > > > I see only intel_backlight inside /sys/class/backlight. There is no
> >> > > > > acer-wmi interface . Is this the expected behavior ? . Or am I missing
> >> > > > > anything ?
> >> > > > >
> >> > > >
> >> > > > Yes, this is the expected behavior! But, now I doubt your issue was
> >> > > > workaround by acpi_osi=Linux but not intel_backlight.
> >> > > >
> >> > >
> >> > > > >
> >> > > > >
> >> > > > > >
> >> > > > > > > echo 5 > /sys/class/backlight/acpi_video0/brightness
> >> > > > > > > echo 5 > /sys/class/backlight/intel_backlight/brightness
> >> > > > > > >
> >> > > > > > > But it doesn't make any change .
> >> > > > > > >
> >> > > > > > > In my case , 'acpi_backlight = vendor' does not make any difference since the hot key control
> >> > > > > > >
> >> > > > > > > already starts working with 'acpi_osi=Linux' option.
> >> > > > > > >
> >> > > > > > > cat /proc/cmdline gives ,
> >> > > > > > >
> >> > > > > > > BOOT_IMAGE=/boot/vmlinuz-3.3.0+
> >> > > > > > > root=UUIDð197a59-c067-4fd8-ad90-c4d721816077 ro acpi_osi=Linux
> >> > > > > > >
> >> > > > > > >
> >> > > > > > > Thanks ,
> >> > > > > > >
> >> > > > > > > Pradeep Subrahmanion
> >> > > > > > >
> >> > > > > >
> >> > > > > > OK, that's more clearly, please remove acpi_osi=Linux then re-test, I
> >> > > > > > think the hotkey of backlight control only works with acpi_osi=Linux ?
> >> > > > > >
> >> > > >
> >> > > > Does your backlight control still work if you remove acpi_osi=Linux ?
> >> > >
> >> > > If I remove acpi_osi=Linux , the hot key control stops working .
> >> > >
> >> >
> >> > What is the preload OS in your machine when you bought it? Windows XP,
> >> > Vista or Windows 7?
> >>
> >> It was Windows XP.
> >>
> >
> > The WDDM driver didn't support by Windows XP, the brightness control on
> > XP should works with _BCM or OpRegion.
> >
> > Wonder how does brightness control work on XP with your machine.
> >
> > I will dig more in your dsdt...
> >
> >
Please kindly try acpi_osi="!Windows 2006", I think it also works to
you.
Thanks
Joey Lee
--
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
* usage of height and width in fb_var_screeninfo
From: Jun Nie @ 2012-03-22 11:52 UTC (permalink / raw)
To: linux-fbdev
Does anyone happen to know the usage of below member in
fb_var_screeninfo? I do not know whether mm stand for geometry size or
memory, can not find its usage in any driver neither. We considering
to use it as zoomed size.
struct fb_var_screeninfo {
__u32 height; /* height of picture in mm */
__u32 width; /* width of picture in mm */
Jun
^ 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