* [PATCH v2] ARM: multi_v7_defconfig: Enable some drivers for LS1021A
From: Alison Wang @ 2015-12-09 8:41 UTC (permalink / raw)
To: linux-arm-kernel
This patch enables some drivers for LS1021A, such as
GIANFAR, WATCHDOG, AUDIO, QSPI, I2C, ESDHC, EDMA, FTM.
QorIQ Clock Framework and Ramdisk support is also enabled.
Signed-off-by: Alison Wang <alison.wang@freescale.com>
---
Changes since v1:
- Make some drivers as loadable modules.
arch/arm/configs/multi_v7_defconfig | 14 ++++++++++++++
1 file changed, 14 insertions(+)
diff --git a/arch/arm/configs/multi_v7_defconfig b/arch/arm/configs/multi_v7_defconfig
index f6a2557..fb2159d 100644
--- a/arch/arm/configs/multi_v7_defconfig
+++ b/arch/arm/configs/multi_v7_defconfig
@@ -128,6 +128,7 @@ CONFIG_KEXEC=y
CONFIG_CPU_FREQ=y
CONFIG_CPU_FREQ_STAT_DETAILS=y
CONFIG_CPU_FREQ_DEFAULT_GOV_ONDEMAND=y
+CONFIG_QORIQ_CPUFREQ=y
CONFIG_CPU_IDLE=y
CONFIG_ARM_CPUIDLE=y
CONFIG_NEON=y
@@ -182,8 +183,11 @@ CONFIG_MTD_NAND_ATMEL=y
CONFIG_MTD_NAND_BRCMNAND=y
CONFIG_MTD_NAND_DAVINCI=y
CONFIG_MTD_SPI_NOR=y
+CONFIG_SPI_FSL_QUADSPI=m
CONFIG_MTD_UBI=y
CONFIG_BLK_DEV_LOOP=y
+CONFIG_BLK_DEV_RAM=y
+CONFIG_BLK_DEV_RAM_SIZEe536
CONFIG_AD525X_DPOT=y
CONFIG_AD525X_DPOT_I2C=y
CONFIG_ATMEL_TCLIB=y
@@ -210,6 +214,7 @@ CONFIG_HIX5HD2_GMAC=y
CONFIG_SUN4I_EMAC=y
CONFIG_MACB=y
CONFIG_NET_CALXEDA_XGMAC=y
+CONFIG_GIANFAR=y
CONFIG_IGB=y
CONFIG_MV643XX_ETH=y
CONFIG_MVNETA=y
@@ -226,6 +231,7 @@ CONFIG_MARVELL_PHY=y
CONFIG_SMSC_PHY=y
CONFIG_BROADCOM_PHY=y
CONFIG_ICPLUS_PHY=y
+CONFIG_REALTEK_PHY=y
CONFIG_MICREL_PHY=y
CONFIG_FIXED_PHY=y
CONFIG_USB_PEGASUS=y
@@ -312,6 +318,7 @@ CONFIG_I2C_DESIGNWARE_PLATFORM=y
CONFIG_I2C_DIGICOLOR=m
CONFIG_I2C_GPIO=m
CONFIG_I2C_EXYNOS5=y
+CONFIG_I2C_IMX=m
CONFIG_I2C_MV64XXX=y
CONFIG_I2C_RIIC=y
CONFIG_I2C_RK3X=y
@@ -330,6 +337,7 @@ CONFIG_SPI=y
CONFIG_SPI_ATMEL=m
CONFIG_SPI_CADENCE=y
CONFIG_SPI_DAVINCI=y
+CONFIG_SPI_FSL_DSPI=m
CONFIG_SPI_OMAP24XX=y
CONFIG_SPI_ORION=y
CONFIG_SPI_PL022=y
@@ -405,6 +413,7 @@ CONFIG_ARM_SP805_WATCHDOG=y
CONFIG_ORION_WATCHDOG=y
CONFIG_ST_LPC_WATCHDOG=y
CONFIG_SUNXI_WATCHDOG=y
+CONFIG_IMX2_WDT=y
CONFIG_TEGRA_WATCHDOG=m
CONFIG_MESON_WATCHDOG=y
CONFIG_DIGICOLOR_WATCHDOG=y
@@ -525,6 +534,7 @@ CONFIG_SND_USB_AUDIO=y
CONFIG_SND_SOC=m
CONFIG_SND_ATMEL_SOC=m
CONFIG_SND_ATMEL_SOC_WM8904=m
+CONFIG_SND_SOC_FSL_SAI=m
CONFIG_SND_SOC_SH4_FSI=m
CONFIG_SND_SOC_RCAR=m
CONFIG_SND_SOC_RSRC_CARD=m
@@ -537,6 +547,7 @@ CONFIG_SND_SOC_TEGRA_TRIMSLICE=m
CONFIG_SND_SOC_TEGRA_ALC5632=m
CONFIG_SND_SOC_TEGRA_MAX98090=m
CONFIG_SND_SOC_AK4642=m
+CONFIG_SND_SOC_SGTL5000=m
CONFIG_SND_SOC_WM8978=m
CONFIG_USB=y
CONFIG_USB_XHCI_HCD=y
@@ -577,6 +588,7 @@ CONFIG_MMC_SDHCI=y
CONFIG_MMC_SDHCI_PLTFM=y
CONFIG_MMC_SDHCI_OF_ARASAN=y
CONFIG_MMC_SDHCI_OF_AT91=y
+CONFIG_MMC_SDHCI_OF_ESDHC=m
CONFIG_MMC_SDHCI_ESDHC_IMX=y
CONFIG_MMC_SDHCI_DOVE=y
CONFIG_MMC_SDHCI_TEGRA=y
@@ -653,6 +665,7 @@ CONFIG_DMADEVICES=y
CONFIG_DW_DMAC=y
CONFIG_AT_HDMAC=y
CONFIG_AT_XDMAC=y
+CONFIG_FSL_EDMA=m
CONFIG_MV_XOR=y
CONFIG_TEGRA20_APB_DMA=y
CONFIG_SH_DMAE=y
@@ -712,6 +725,7 @@ CONFIG_AK8975=y
CONFIG_PWM=y
CONFIG_PWM_ATMEL=m
CONFIG_PWM_ATMEL_TCB=m
+CONFIG_PWM_FSL_FTM=m
CONFIG_PWM_RENESAS_TPU=y
CONFIG_PWM_ROCKCHIP=m
CONFIG_PWM_SAMSUNG=m
--
2.1.0.27.g96db324
^ permalink raw reply related
* Re: [PATCH 1/2] video:omap2:dss: fix timings for VENC to match what omapdrm expects
From: Tomi Valkeinen @ 2015-12-09 8:18 UTC (permalink / raw)
To: H. Nikolaus Schaller, Laurent Pinchart
Cc: linux-fbdev, linux-kernel, dri-devel, gta04-owner, linux-omap,
Jean-Christophe Plagniol-Villard
In-Reply-To: <20ebf7491377ccba18c734c22ae9f361d7fdc165.1447410544.git.hns@goldelico.com>
[-- Attachment #1: Type: text/plain, Size: 2062 bytes --]
On 13/11/15 12:29, H. Nikolaus Schaller wrote:
> Otherwise check_timings fails and we get a "has no modes" message
> from xrandr.
>
> This fix makes the venc assume PAL and NTSC timings that match the
> timings synthetized by copy_timings_drm_to_omap() from omapdrm
> mode settings so that check_timings() succeeds.
>
> Tested on: BeagleBoard XM, GTA04 and OpenPandora
>
> Signed-off-by: H. Nikolaus Schaller <hns@goldelico.com>
> ---
> drivers/video/fbdev/omap2/dss/venc.c | 12 ++++++++++++
> 1 file changed, 12 insertions(+)
I've picked this up.
With this patch and the one below I can get tv-out working on my very old
beagleboard, and it seems to work with X also. It doesn't start automatically
as the connection state is unknown, but doing "xrandr --output None-1 --auto"
was all I needed to enable it.
Tomi
From a4274600a5a67256b91266b0d2624b9c9028909b Mon Sep 17 00:00:00 2001
From: Tomi Valkeinen <tomi.valkeinen@ti.com>
Date: Tue, 8 Dec 2015 18:32:14 +0200
Subject: [PATCH] drm/omap: fix fbdev pix format to support all platforms
omap_fbdev always creates a framebuffer with ARGB8888 pixel format. On
OMAP3 we have VIDEO1 overlay that does not support ARGB8888, and on
OMAP2 none of the overlays support ARGB888.
This patch changes the omap_fbdev's fb to XRGB8888, which is supported
by all platforms.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
diff --git a/drivers/gpu/drm/omapdrm/omap_fbdev.c b/drivers/gpu/drm/omapdrm/omap_fbdev.c
index b8e4cdec28c3..24f92bea39c7 100644
--- a/drivers/gpu/drm/omapdrm/omap_fbdev.c
+++ b/drivers/gpu/drm/omapdrm/omap_fbdev.c
@@ -112,11 +112,8 @@ static int omap_fbdev_create(struct drm_fb_helper *helper,
dma_addr_t paddr;
int ret;
- /* only doing ARGB32 since this is what is needed to alpha-blend
- * with video overlays:
- */
sizes->surface_bpp = 32;
- sizes->surface_depth = 32;
+ sizes->surface_depth = 24;
DBG("create fbdev: %dx%d@%d (%dx%d)", sizes->surface_width,
sizes->surface_height, sizes->surface_bpp,
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply related
* Re: [PATCH 4/4] fbdev: Debug knob to register without holding console_lock
From: Tomi Valkeinen @ 2015-12-08 8:26 UTC (permalink / raw)
To: Daniel Vetter
Cc: linux-fbdev, Daniel Vetter, Intel Graphics Development,
DRI Development, Jean-Christophe Plagniol-Villard
In-Reply-To: <20151208081916.GA20822@phenom.ffwll.local>
[-- Attachment #1: Type: text/plain, Size: 2168 bytes --]
On 08/12/15 10:19, Daniel Vetter wrote:
> On Mon, Dec 07, 2015 at 07:32:42PM +0200, Tomi Valkeinen wrote:
>>
>> On 25/08/15 16:45, Daniel Vetter wrote:
>>> When the usual fbcon legacy options are enabled we have
>>> ->register_framebuffer
>>> ->fb notifier chain calls into fbcon
>>> ->fbcon sets up console on new fbi
>>> ->fbi->set_par
>>> ->drm_fb_helper_set_par exercises full kms api
>>>
>>> And because of locking inversion hilarity all of register_framebuffer
>>> is done with the console lock held. Which means that the first time on
>>> driver load we exercise _all_ the kms code (all probe paths and
>>> modeset paths for everything connected) is under the console lock.
>>> That means if anything goes belly-up in that big pile of code nothing
>>> ever reaches logfiles (and the machine is dead).
>>>
>>> Usual tactic to debug that is to temporarily remove those console_lock
>>> calls to be able to capture backtraces. I'm fed up writing this patch
>>> and recompiling kernels. Hence this patch here to add an unsafe,
>>> kernel-taining option to do this at runtime.
>>
>> I think this was never merged. This was part 4 of 4, were there
>> dependencies or...? Should I apply this for 4.5?
>
> Patches 1-3 have all already landed in drm, and patch 4 is free standing.
> Would be great if you can pull it in.
Ok, I'll apply for 4.5.
>> But then... I think my issues with console lock have been later at
>> runtime, not at register. Maybe we need a module option to disable the
>> console lock altogether. I wonder how much havoc that might create, though.
>
> Hm, where in fbdev do you hold the console_lock outside of
> registering/unregistering an fbdev (because of fbcon)? There's of course
> general trouble with console_lock deadlocks and fun like that, but ime
> that all got a lot more manageable since I added lockdep annotations to
> console_lock.
I don't know... I just have a vague recollection that I was having
trouble with the lock with... crashes during blanking, perhaps. I really
can't remember, so possibly things are better now, or I just remember wrong.
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* Re: [PATCH 4/4] fbdev: Debug knob to register without holding console_lock
From: Daniel Vetter @ 2015-12-08 8:19 UTC (permalink / raw)
To: Tomi Valkeinen
Cc: linux-fbdev, Daniel Vetter, Intel Graphics Development,
DRI Development, Jean-Christophe Plagniol-Villard
In-Reply-To: <5665C2BA.3010304@ti.com>
On Mon, Dec 07, 2015 at 07:32:42PM +0200, Tomi Valkeinen wrote:
>
> On 25/08/15 16:45, Daniel Vetter wrote:
> > When the usual fbcon legacy options are enabled we have
> > ->register_framebuffer
> > ->fb notifier chain calls into fbcon
> > ->fbcon sets up console on new fbi
> > ->fbi->set_par
> > ->drm_fb_helper_set_par exercises full kms api
> >
> > And because of locking inversion hilarity all of register_framebuffer
> > is done with the console lock held. Which means that the first time on
> > driver load we exercise _all_ the kms code (all probe paths and
> > modeset paths for everything connected) is under the console lock.
> > That means if anything goes belly-up in that big pile of code nothing
> > ever reaches logfiles (and the machine is dead).
> >
> > Usual tactic to debug that is to temporarily remove those console_lock
> > calls to be able to capture backtraces. I'm fed up writing this patch
> > and recompiling kernels. Hence this patch here to add an unsafe,
> > kernel-taining option to do this at runtime.
>
> I think this was never merged. This was part 4 of 4, were there
> dependencies or...? Should I apply this for 4.5?
Patches 1-3 have all already landed in drm, and patch 4 is free standing.
Would be great if you can pull it in.
> But then... I think my issues with console lock have been later at
> runtime, not at register. Maybe we need a module option to disable the
> console lock altogether. I wonder how much havoc that might create, though.
Hm, where in fbdev do you hold the console_lock outside of
registering/unregistering an fbdev (because of fbcon)? There's of course
general trouble with console_lock deadlocks and fun like that, but ime
that all got a lot more manageable since I added lockdep annotations to
console_lock.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
^ permalink raw reply
* Re: [PATCH v5 2/2] video: fbdev: pxafb: initial devicetree conversion
From: Robert Jarzmik @ 2015-12-07 20:50 UTC (permalink / raw)
To: Tomi Valkeinen, Rob Herring
Cc: Jean-Christophe Plagniol-Villard, linux-fbdev, linux-kernel
In-Reply-To: <5665B3C1.1080005@ti.com>
Tomi Valkeinen <tomi.valkeinen@ti.com> writes:
> On 17/11/15 22:32, Robert Jarzmik wrote:
>> This patch brings a first support of pxa framebuffer devices to a
>> devicetree pxa platform, as was before platform data.
>>
>> There are restrictions with this port, the biggest one being the lack of
>> support of smart panels. Moreover the conversion doesn't provide a way
>> to declare multiple framebuffer configurations with different bits per
>> pixel, only the LCD hardware bus width is used.
>>
>> The patch was tested on both pxa25x, pxa27x and pxa3xx platform (namely
>> lubbock, mainstone and zylonite).
>>
>> Signed-off-by: Robert Jarzmik <robert.jarzmik@free.fr>
>> ---
>> Since v1: Philipp's review: of_graph usage
>> Since v3: of_device_id sentinel, and all compatible ids added
>> Since v4: fixed of_device_id table : rebase error on my side, with
>> braces which were incorrectly added
>> ---
>> drivers/video/fbdev/Kconfig | 2 +
>> drivers/video/fbdev/pxafb.c | 163 +++++++++++++++++++++++++++++++++++++++++++-
>> 2 files changed, 162 insertions(+), 3 deletions(-)
>
> I see we already have
> Documentation/devicetree/bindings/display/marvell,pxa2xx-lcdc.txt in the
> mainline. I think the patch adding the binding doc should have been kept
> in this series.
Ah, I think Rob took it through his tree already. Probably my fault also, I hope
I had not forgotten to Cc: you on the binding patch ...
> It seems that at least "depth" is missing from the binding document.
You're right.
Actually depth is not a "hardware" caracteristic. Moreover it's just used as an
overlay for pxafb_set_pixfmt() to superseed var->bits_per_pixel. I'm wondering
if the right path for of_get_pxafb_mode_info() would be to remove completely
depth, and leave it initialized at 0 for the DT case.
What do you think of this approach ? The other one would be to modify the
binding, and yet I feel this depth doesn't belong to the binding, it's my patch
which requires another spin IMHO.
Cheers.
--
Robert
^ permalink raw reply
* Re: [PATCH 4/4] fbdev: Debug knob to register without holding console_lock
From: Tomi Valkeinen @ 2015-12-07 17:32 UTC (permalink / raw)
To: Daniel Vetter, DRI Development
Cc: Intel Graphics Development, Jean-Christophe Plagniol-Villard,
linux-fbdev
In-Reply-To: <1440510314-8633-4-git-send-email-daniel.vetter@ffwll.ch>
[-- Attachment #1: Type: text/plain, Size: 1321 bytes --]
On 25/08/15 16:45, Daniel Vetter wrote:
> When the usual fbcon legacy options are enabled we have
> ->register_framebuffer
> ->fb notifier chain calls into fbcon
> ->fbcon sets up console on new fbi
> ->fbi->set_par
> ->drm_fb_helper_set_par exercises full kms api
>
> And because of locking inversion hilarity all of register_framebuffer
> is done with the console lock held. Which means that the first time on
> driver load we exercise _all_ the kms code (all probe paths and
> modeset paths for everything connected) is under the console lock.
> That means if anything goes belly-up in that big pile of code nothing
> ever reaches logfiles (and the machine is dead).
>
> Usual tactic to debug that is to temporarily remove those console_lock
> calls to be able to capture backtraces. I'm fed up writing this patch
> and recompiling kernels. Hence this patch here to add an unsafe,
> kernel-taining option to do this at runtime.
I think this was never merged. This was part 4 of 4, were there
dependencies or...? Should I apply this for 4.5?
But then... I think my issues with console lock have been later at
runtime, not at register. Maybe we need a module option to disable the
console lock altogether. I wonder how much havoc that might create, though.
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* Re: [PATCH v3] video: fbdev: fsl: Fix kernel crash when diu_ops is not implemented
From: Scott Wood @ 2015-12-07 17:07 UTC (permalink / raw)
To: linux-fbdev
In-Reply-To: <1449107652-5134-1-git-send-email-dongsheng.wang@freescale.com>
On Thu, 2015-12-03 at 09:54 +0800, Dongsheng Wang wrote:
> From: Wang Dongsheng <dongsheng.wang@freescale.com>
>
> If diu_ops is not implemented on platform, kernel will access a NULL
> pointer. We need to check this pointer in DIU initialization.
>
> Signed-off-by: Wang Dongsheng <dongsheng.wang@freescale.com>
> ---
> v3:
> - Fix capitalization in patch description.
> - Add comments for verify diu_ops.set_pixel_clock.
>
> v2:
> - Move set_pixel_clock judgement to fsl_diu_init.
>
> drivers/video/fbdev/fsl-diu-fb.c | 13 ++++++++++++-
> 1 file changed, 12 insertions(+), 1 deletion(-)
Why did you not CC stable as I previously requested?
-Scott
^ permalink raw reply
* Re: [PATCH v3] video: fbdev: fsl: Fix kernel crash when diu_ops is not implemented
From: Tomi Valkeinen @ 2015-12-07 16:57 UTC (permalink / raw)
To: linux-fbdev
In-Reply-To: <1449107652-5134-1-git-send-email-dongsheng.wang@freescale.com>
[-- Attachment #1: Type: text/plain, Size: 644 bytes --]
On 03/12/15 03:54, Dongsheng Wang wrote:
> From: Wang Dongsheng <dongsheng.wang@freescale.com>
>
> If diu_ops is not implemented on platform, kernel will access a NULL
> pointer. We need to check this pointer in DIU initialization.
>
> Signed-off-by: Wang Dongsheng <dongsheng.wang@freescale.com>
> ---
> v3:
> - Fix capitalization in patch description.
> - Add comments for verify diu_ops.set_pixel_clock.
>
> v2:
> - Move set_pixel_clock judgement to fsl_diu_init.
>
> drivers/video/fbdev/fsl-diu-fb.c | 13 ++++++++++++-
> 1 file changed, 12 insertions(+), 1 deletion(-)
Thanks, queued for 4.4 fixes.
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* Re: [PATCH] video: fbdev: rivafb: unlock chip before probiding EDID
From: Tomi Valkeinen @ 2015-12-07 16:29 UTC (permalink / raw)
To: linux-fbdev
[-- Attachment #1: Type: text/plain, Size: 852 bytes --]
On 17/11/15 03:38, Dmitry Eremin-Solenikov wrote:
> At least NV3 requires for chip to be unlocked before it is possible to
> access I2C registers. Without it, it is not possible to read EDID.
>
> Signed-off-by: Dmitry Eremin-Solenikov <dbaryshkov@gmail.com>
> ---
> drivers/video/fbdev/riva/fbdev.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/drivers/video/fbdev/riva/fbdev.c b/drivers/video/fbdev/riva/fbdev.c
> index f1ad274..2ef26ad 100644
> --- a/drivers/video/fbdev/riva/fbdev.c
> +++ b/drivers/video/fbdev/riva/fbdev.c
> @@ -1765,6 +1765,7 @@ static int riva_get_EDID_i2c(struct fb_info *info)
> int i;
>
> NVTRACE_ENTER();
> + par->riva.LockUnlock(&par->riva, 0);
> riva_create_i2c_busses(par);
> for (i = 0; i < 3; i++) {
> if (!par->chan[i].par)
>
Thanks, applied for 4.5.
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* Re: [PATCH v5 2/2] video: fbdev: pxafb: initial devicetree conversion
From: Tomi Valkeinen @ 2015-12-07 16:28 UTC (permalink / raw)
To: Robert Jarzmik, Jean-Christophe Plagniol-Villard
Cc: linux-fbdev, linux-kernel
In-Reply-To: <1447792337-13876-2-git-send-email-robert.jarzmik@free.fr>
[-- Attachment #1: Type: text/plain, Size: 1322 bytes --]
On 17/11/15 22:32, Robert Jarzmik wrote:
> This patch brings a first support of pxa framebuffer devices to a
> devicetree pxa platform, as was before platform data.
>
> There are restrictions with this port, the biggest one being the lack of
> support of smart panels. Moreover the conversion doesn't provide a way
> to declare multiple framebuffer configurations with different bits per
> pixel, only the LCD hardware bus width is used.
>
> The patch was tested on both pxa25x, pxa27x and pxa3xx platform (namely
> lubbock, mainstone and zylonite).
>
> Signed-off-by: Robert Jarzmik <robert.jarzmik@free.fr>
> ---
> Since v1: Philipp's review: of_graph usage
> Since v3: of_device_id sentinel, and all compatible ids added
> Since v4: fixed of_device_id table : rebase error on my side, with
> braces which were incorrectly added
> ---
> drivers/video/fbdev/Kconfig | 2 +
> drivers/video/fbdev/pxafb.c | 163 +++++++++++++++++++++++++++++++++++++++++++-
> 2 files changed, 162 insertions(+), 3 deletions(-)
I see we already have
Documentation/devicetree/bindings/display/marvell,pxa2xx-lcdc.txt in the
mainline. I think the patch adding the binding doc should have been kept
in this series.
It seems that at least "depth" is missing from the binding document.
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* Re: [PATCH] fbdev: auo_k190x: avoid unused function warnings
From: Tomi Valkeinen @ 2015-12-07 16:20 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1678174.Yl1Wo71dkn@wuerfel>
[-- Attachment #1: Type: text/plain, Size: 1269 bytes --]
On 07/12/15 18:16, Arnd Bergmann wrote:
> On Monday 07 December 2015 18:10:04 Tomi Valkeinen wrote:
>> On 20/11/15 23:47, Arnd Bergmann wrote:
>>> The auo_k190x framebuffer driver encloses the power-management
>>> functions in #ifdef CONFIG_PM, but the auok190x_suspend/resume
>>> functions are only really used when CONFIG_PM_SLEEP is also
>>> set, as a frequent gcc warning shows:
>>>
>>> drivers/video/fbdev/auo_k190x.c:859:12: warning: 'auok190x_suspend' defined but not used
>>> drivers/video/fbdev/auo_k190x.c:899:12: warning: 'auok190x_resume' defined but not used
>>>
>>> This changes the driver to remove the #ifdef and instead mark
>>> the functions as __maybe_unused, which is a nicer anyway, as it
>>> provides build testing for all the code in all configurations
>>> and is harder to get wrong.
>>
>> Applied for 4.5.
>>
>> Btw, do you know if the linker will optimize the __maybe_unused funcs
>> away if they are not used? I presume so.
>>
>
> The compiler does it correctly when built with -O1 or higher (we don't
> support -O0), and the linker is not involved here.
Ah, right, they were static. I was thinking of non-static functions. But
__maybe_unused is not even needed for non-static, so... Never mind =)
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* Re: [PATCH] fbdev: auo_k190x: avoid unused function warnings
From: Arnd Bergmann @ 2015-12-07 16:16 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <5665AF5C.4060801@ti.com>
On Monday 07 December 2015 18:10:04 Tomi Valkeinen wrote:
> On 20/11/15 23:47, Arnd Bergmann wrote:
> > The auo_k190x framebuffer driver encloses the power-management
> > functions in #ifdef CONFIG_PM, but the auok190x_suspend/resume
> > functions are only really used when CONFIG_PM_SLEEP is also
> > set, as a frequent gcc warning shows:
> >
> > drivers/video/fbdev/auo_k190x.c:859:12: warning: 'auok190x_suspend' defined but not used
> > drivers/video/fbdev/auo_k190x.c:899:12: warning: 'auok190x_resume' defined but not used
> >
> > This changes the driver to remove the #ifdef and instead mark
> > the functions as __maybe_unused, which is a nicer anyway, as it
> > provides build testing for all the code in all configurations
> > and is harder to get wrong.
>
> Applied for 4.5.
>
> Btw, do you know if the linker will optimize the __maybe_unused funcs
> away if they are not used? I presume so.
>
The compiler does it correctly when built with -O1 or higher (we don't
support -O0), and the linker is not involved here.
Arnd
^ permalink raw reply
* Re: [PATCH RESEND] fbdev: Make fb-notify a no-op if CONFIG_FB=n
From: Ezequiel Garcia @ 2015-12-07 16:14 UTC (permalink / raw)
To: linux-fbdev
In-Reply-To: <1448421108-3437-1-git-send-email-ezequiel@vanguardiasur.com.ar>
Tomi,
Thanks for looking at this patch.
On 7 December 2015 at 13:01, Tomi Valkeinen <tomi.valkeinen@ti.com> wrote:
>
> On 25/11/15 05:11, Ezequiel Garcia wrote:
>> There's no point in having support for framebuffer notifications
>> is CONFIG_FB is disabled. This commit adds the necessary stubs
>> for code to link properly when CONFIG_FB=n and moves fb-notify.o
>> to be built only when CONFIG_FB=y.
>
> Why do you add CONFIG_FB_NOTIFY, isn't plain CONFIG_FB enough? Oh,
> right, to have it built-in even if FB is a module.
>
Right.
> But this makes me wonder, why is fb_notify in obj-y list currently.
> Nobody just bothered to make it build only when needed, or has there
> been some use for it earlier... The commit descriptions in git history
> suggest the former.
>
Here's the patch that created fb_notify.c and put it in obj-y.
[PATCH] fbdev: statically link the framebuffer notification functions
The backlight and lcd subsystems can be notified by the framebuffer layer
of blanking events. However, these subsystems, as a whole, can function
independently from the framebuffer layer. But in order to enable to the
lcd and backlight subsystems, the framebuffer has to be compiled also,
effectively sucking in a huge amount of unneeded code.
To prevent dependency problems, separate out the framebuffer notification
mechanism from the framebuffer layer and permanently link it to the kernel.
Signed-off-by: Antonino Daplas <adaplas@pol.net>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
> Actually, looks like fb_notify.c was originally made to solve the same
> problem as your patch solves, but by separating the notify code from the
> main fbdev code. So I still wonder, was there some reason to keep the
> notification code built instead of having stub functions.
>
> Any thoughts?
>
I can't see any valid reason to keep the code around, since there's no
way it can be used.
Let's see if Ccing Antonino and Andrew -as per that commit- helps.
--
Ezequiel GarcÃa, VanguardiaSur
www.vanguardiasur.com.ar
^ permalink raw reply
* Re: [PATCH] fbdev: sm712fb: avoid unused function warnings
From: Tomi Valkeinen @ 2015-12-07 16:11 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <4240710.SWINpxTKzN@wuerfel>
[-- Attachment #1: Type: text/plain, Size: 877 bytes --]
On 20/11/15 23:48, Arnd Bergmann wrote:
> The sm712fb framebuffer driver encloses the power-management
> functions in #ifdef CONFIG_PM, but the smtcfb_pci_suspend/resume
> functions are only really used when CONFIG_PM_SLEEP is also
> set, as a frequent gcc warning shows:
>
> fbdev/sm712fb.c:1549:12: warning: 'smtcfb_pci_suspend' defined but not used
> fbdev/sm712fb.c:1572:12: warning: 'smtcfb_pci_resume' defined but not used
>
> The driver also avoids using the SIMPLE_DEV_PM_OPS macro when
> CONFIG_PM is unset, which is redundant.
>
> This changes the driver to remove the #ifdef and instead mark
> the functions as __maybe_unused, which is a nicer anyway, as it
> provides build testing for all the code in all configurations
> and is harder to get wrong.
>
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Thanks, applied for 4.5.
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* Re: [PATCH] fbdev: auo_k190x: avoid unused function warnings
From: Tomi Valkeinen @ 2015-12-07 16:10 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <3917686.rD8ezhD468@wuerfel>
[-- Attachment #1: Type: text/plain, Size: 844 bytes --]
On 20/11/15 23:47, Arnd Bergmann wrote:
> The auo_k190x framebuffer driver encloses the power-management
> functions in #ifdef CONFIG_PM, but the auok190x_suspend/resume
> functions are only really used when CONFIG_PM_SLEEP is also
> set, as a frequent gcc warning shows:
>
> drivers/video/fbdev/auo_k190x.c:859:12: warning: 'auok190x_suspend' defined but not used
> drivers/video/fbdev/auo_k190x.c:899:12: warning: 'auok190x_resume' defined but not used
>
> This changes the driver to remove the #ifdef and instead mark
> the functions as __maybe_unused, which is a nicer anyway, as it
> provides build testing for all the code in all configurations
> and is harder to get wrong.
Applied for 4.5.
Btw, do you know if the linker will optimize the __maybe_unused funcs
away if they are not used? I presume so.
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* Re: [PATCH RESEND] fbdev: Make fb-notify a no-op if CONFIG_FB=n
From: Tomi Valkeinen @ 2015-12-07 16:01 UTC (permalink / raw)
To: linux-fbdev
In-Reply-To: <1448421108-3437-1-git-send-email-ezequiel@vanguardiasur.com.ar>
[-- Attachment #1: Type: text/plain, Size: 947 bytes --]
On 25/11/15 05:11, Ezequiel Garcia wrote:
> There's no point in having support for framebuffer notifications
> is CONFIG_FB is disabled. This commit adds the necessary stubs
> for code to link properly when CONFIG_FB=n and moves fb-notify.o
> to be built only when CONFIG_FB=y.
Why do you add CONFIG_FB_NOTIFY, isn't plain CONFIG_FB enough? Oh,
right, to have it built-in even if FB is a module.
But this makes me wonder, why is fb_notify in obj-y list currently.
Nobody just bothered to make it build only when needed, or has there
been some use for it earlier... The commit descriptions in git history
suggest the former.
Actually, looks like fb_notify.c was originally made to solve the same
problem as your patch solves, but by separating the notify code from the
main fbdev code. So I still wonder, was there some reason to keep the
notification code built instead of having stub functions.
Any thoughts?
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* Re: [PATCH] fbdev: sis: enforce selection of at least one backend
From: Tomi Valkeinen @ 2015-12-07 15:48 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <2902419.SMzMybotxA@wuerfel>
[-- Attachment #1: Type: text/plain, Size: 837 bytes --]
On 27/11/15 16:33, Arnd Bergmann wrote:
> The sis framebuffer driver complains with a compile-time warning
> if neither the FB_SIS_300 nor FB_SIS_315 symbols are selected:
>
> drivers/video/fbdev/sis/sis_main.c:61:2: warning: #warning Neither CONFIG_FB_SIS_300 nor CONFIG_FB_SIS_315 is se
>
> This is reasonable because it doesn't work in that case, but it's
> also annoying for randconfig builds and is one of the most common
> warnings I'm seeing on ARM now.
>
> This changes the Kconfig logic to prevent the silly configuration,
> by always selecting the FB_SIS_300 variant if the other one is
> not set.
>
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> ---
> Sorry for sending this twice, it looks like I forgot the fbdev list and
> Tomi as recipients the first time
Thanks, queued for 4.5.
tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* Re: [patch] OMAPDSS: DSS: fix a warning message
From: Tomi Valkeinen @ 2015-12-07 15:39 UTC (permalink / raw)
To: Dan Carpenter
Cc: Jean-Christophe Plagniol-Villard, Laurent Pinchart, linux-omap,
linux-fbdev, kernel-janitors
In-Reply-To: <20151204131458.GA12792@mwanda>
[-- Attachment #1: Type: text/plain, Size: 904 bytes --]
On 04/12/15 15:14, Dan Carpenter wrote:
> The WARN() macro has to take a condition. The current code will just
> print the stack trace and the function name instead of the intended
> warning message.
>
> Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
>
> diff --git a/drivers/video/fbdev/omap2/dss/dss.h b/drivers/video/fbdev/omap2/dss/dss.h
> index 2406bcd..da3a85a 100644
> --- a/drivers/video/fbdev/omap2/dss/dss.h
> +++ b/drivers/video/fbdev/omap2/dss/dss.h
> @@ -343,7 +343,8 @@ u8 dsi_get_pixel_size(enum omap_dss_dsi_pixel_format fmt);
> #else
> static inline u8 dsi_get_pixel_size(enum omap_dss_dsi_pixel_format fmt)
> {
> - WARN("%s: DSI not compiled in, returning pixel_size as 0\n", __func__);
> + WARN(1, "%s: DSI not compiled in, returning pixel_size as 0\n",
> + __func__);
> return 0;
> }
> #endif
>
Thanks, queued for 4.5.
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* Re: [PATCH] fbdev: Remove unused SH-Mobile HDMI driver
From: Tomi Valkeinen @ 2015-12-07 15:36 UTC (permalink / raw)
To: linux-fbdev
In-Reply-To: <1449244903-23336-1-git-send-email-geert+renesas@glider.be>
[-- Attachment #1: Type: text/plain, Size: 900 bytes --]
On 04/12/15 18:01, Geert Uytterhoeven wrote:
> As of commit 44d88c754e57a6d9 ("ARM: shmobile: Remove legacy SoC code
> for R-Mobile A1"), the SH-Mobile HDMI driver is no longer used.
> In theory it could still be used on R-Mobile A1 SoCs, but that requires
> adding DT support to the driver, which is not planned.
>
> Remove the driver, it can be resurrected from git history when needed.
>
> Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
> ---
> drivers/video/fbdev/Kconfig | 10 -
> drivers/video/fbdev/Makefile | 1 -
> drivers/video/fbdev/sh_mobile_hdmi.c | 1489 ----------------------------------
> include/video/sh_mobile_hdmi.h | 49 --
> 4 files changed, 1549 deletions(-)
> delete mode 100644 drivers/video/fbdev/sh_mobile_hdmi.c
> delete mode 100644 include/video/sh_mobile_hdmi.h
Thanks, queued for 4.5.
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* Re: [PATCH v5] pwm-backlight: Avoid backlight flicker when probed from DT
From: Lee Jones @ 2015-12-07 9:35 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAGS+omCD3MLB+hf4R1aD+YZuB4SV8nu71oAm6V_bkfoE2im49A@mail.gmail.com>
On Mon, 07 Dec 2015, Daniel Kurtz wrote:
> Hi Lee,
>
> On Wed, Nov 25, 2015 at 12:26 AM, Lee Jones <lee.jones@linaro.org> wrote:
> > On Wed, 18 Nov 2015, Philipp Zabel wrote:
> >
> >> If the driver is probed from the device tree, and there is a phandle
> >> property set on it, and the enable GPIO is already configured as output,
> >> and the backlight is currently disabled, keep it disabled.
> >> If all these conditions are met, assume there will be some other driver
> >> that can enable the backlight at the appropriate time.
> >>
> >> Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
> >> Reviewed-by: Christian Gmeiner <christian.gmeiner@gmail.com>
> >> Tested-by: Heiko Stuebner <heiko@sntech.de>
> >> ---
> >> - Rebased onto v4.4-rc1
> >> - Added Heiko's Tested-by
> >> ---
> >> drivers/video/backlight/pwm_bl.c | 23 ++++++++++++++++++++++-
> >> 1 file changed, 22 insertions(+), 1 deletion(-)
> >
> > Applied, thanks.
>
> Hmm, where was this applied? I do not see it in:
> * v4.4-rc4
> * linux-next next-20151203 (dcccebc - Add linux-next specific files
> for 20151203)
>
> Nor do I see it in any branch in:
> * git://git.kernel.org/pub/scm/linux/kernel/git/lee/backlight
> Is this the right git?
Yes, that's right. When I say "applied", it means I applied it to my
local repository. I am careful not to allude to the patch being
"pushed". There is no guarantee when this will happen, since it
completly depends how busy the subsystem is. For Backlight, as the
churn is low, the impetus for pushing is pretty low.
It has been "pushed" now though.
> By the way this repository has a git tag called "HEAD", which is a bit
> annoying since every time I "git remote update" from here, git gets
> confused until I manually delete it (git tag -d HEAD).
Thanks for letting me know. I have now removed this tag.
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
^ permalink raw reply
* Re: [PATCH] fbdev: Remove unused SH-Mobile HDMI driver
From: Simon Horman @ 2015-12-07 6:23 UTC (permalink / raw)
To: linux-fbdev
In-Reply-To: <1449244903-23336-1-git-send-email-geert+renesas@glider.be>
On Fri, Dec 04, 2015 at 05:01:43PM +0100, Geert Uytterhoeven wrote:
> As of commit 44d88c754e57a6d9 ("ARM: shmobile: Remove legacy SoC code
> for R-Mobile A1"), the SH-Mobile HDMI driver is no longer used.
> In theory it could still be used on R-Mobile A1 SoCs, but that requires
> adding DT support to the driver, which is not planned.
>
> Remove the driver, it can be resurrected from git history when needed.
>
> Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Acked-by: Simon Horman <horms+renesas@verge.net.au>
^ permalink raw reply
* Re: [PATCH v5] pwm-backlight: Avoid backlight flicker when probed from DT
From: Daniel Kurtz @ 2015-12-07 4:20 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20151124162658.GJ807@x1>
Hi Lee,
On Wed, Nov 25, 2015 at 12:26 AM, Lee Jones <lee.jones@linaro.org> wrote:
> On Wed, 18 Nov 2015, Philipp Zabel wrote:
>
>> If the driver is probed from the device tree, and there is a phandle
>> property set on it, and the enable GPIO is already configured as output,
>> and the backlight is currently disabled, keep it disabled.
>> If all these conditions are met, assume there will be some other driver
>> that can enable the backlight at the appropriate time.
>>
>> Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
>> Reviewed-by: Christian Gmeiner <christian.gmeiner@gmail.com>
>> Tested-by: Heiko Stuebner <heiko@sntech.de>
>> ---
>> - Rebased onto v4.4-rc1
>> - Added Heiko's Tested-by
>> ---
>> drivers/video/backlight/pwm_bl.c | 23 ++++++++++++++++++++++-
>> 1 file changed, 22 insertions(+), 1 deletion(-)
>
> Applied, thanks.
Hmm, where was this applied? I do not see it in:
* v4.4-rc4
* linux-next next-20151203 (dcccebc - Add linux-next specific files
for 20151203)
Nor do I see it in any branch in:
* git://git.kernel.org/pub/scm/linux/kernel/git/lee/backlight
Is this the right git?
By the way this repository has a git tag called "HEAD", which is a bit
annoying since every time I "git remote update" from here, git gets
confused until I manually delete it (git tag -d HEAD).
Thanks,
-Dan
^ permalink raw reply
* fbdev - wipe screen (dd) with ioctl ?
From: Ran Shalit @ 2015-12-06 7:35 UTC (permalink / raw)
To: linux-fbdev, linux-media
Hello,
I use the following to wipe a screen:
dd if=/dev/zero of=/dev/fb0 code
Is there a way to do the same thing in code (using ioctl I suppose) ?
Regards,
Ran
^ permalink raw reply
* Re: wipe framebuffer with dd command
From: Ran Shalit @ 2015-12-05 10:45 UTC (permalink / raw)
To: kernelnewbies
In-Reply-To: <CAJ2oMhJ3scGVqVCzaseCgcUTFhtpJ0bMPy9QxASVUTib98eDCw@mail.gmail.com>
On Sat, Dec 5, 2015 at 8:03 AM, Ran Shalit <ranshalit@gmail.com> wrote:
> Hello,
>
> I would like to ask what is the effect of wiping frame buffer (dd
> if=/dev/zero of=/dev/fb0) ?
> I have some issue with framebuffer timing on LCD 240x320.
> I could not find a timing with width$0, height20 which result in
> stable picture, but
> the following timing gave me stable ppicture with LCD:
>
> Pixel clocke00
>
> Width$0
> HeightQ2 <<------------- instead of 320 !!
> Hfp=1
> Hbp\x100
> HSW\x14
> Vfp=1
> Vbp=1
> VSW\x10
>
> The only strange thing is that I had to use height 512 instead of 320.
> When I try to render image it is stable but it starts in different
> line every time.
> And here comes the important part:
> After doing:
>
> dd if=/dev/zero of=/dev/fb0
>
> It resolved the issue , and a new image starts from line 0.
>
> I don't understand why.
> Does anyone have any idea ?
> Do you think I still have a timing problem with LCD ?
>
> Regards,
> Ran
Hi,
I wanted to add that framebuffer is configured as following:
fbset -fb /dev/fb0 -xres 240 -yres 320 -vxres 240 -vyres 320
so, I don't know why
dd if=/dev/zero of=/dev/fb0
results in image correct display starting with line 0 on the screen.
I think that writing the image to framebuffer should have filled the
complete buffer.
Regards,
Ran
^ permalink raw reply
* wipe framebuffer with dd command
From: Ran Shalit @ 2015-12-05 6:03 UTC (permalink / raw)
To: kernelnewbies
Hello,
I would like to ask what is the effect of wiping frame buffer (dd
if=/dev/zero of=/dev/fb0) ?
I have some issue with framebuffer timing on LCD 240x320.
I could not find a timing with width$0, height20 which result in
stable picture, but
the following timing gave me stable ppicture with LCD:
Pixel clocke00
Width$0
HeightQ2 <<------------- instead of 320 !!
Hfp=1
Hbp\x100
HSW\x14
Vfp=1
Vbp=1
VSW\x10
The only strange thing is that I had to use height 512 instead of 320.
When I try to render image it is stable but it starts in different
line every time.
And here comes the important part:
After doing:
dd if=/dev/zero of=/dev/fb0
It resolved the issue , and a new image starts from line 0.
I don't understand why.
Does anyone have any idea ?
Do you think I still have a timing problem with LCD ?
Regards,
Ran
^ 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