* Re: [PATCH 05/26] OMAPDSS: DPI: fix regulators
From: Archit Taneja @ 2013-03-27 9:57 UTC (permalink / raw)
To: Tomi Valkeinen; +Cc: linux-omap, linux-fbdev
In-Reply-To: <1364304836-18134-6-git-send-email-tomi.valkeinen@ti.com>
On Tuesday 26 March 2013 07:03 PM, Tomi Valkeinen wrote:
> On some platforms DPI requires a regulator to be enabled to power up the
> output pins. This regulator is, for some reason, currently attached to
> the virtual omapdss device, instead of the DPI device. This does not
> work for DT, as the regulator mappings need to be described in the DT
> data, and the virtual omapdss device is not present there.
>
> Fix the issue by acquiring the regulator in the DPI device. To retain
> compatibility with the current board files, the old method of getting
> the regulator is kept. The old method can be removed when the board
> files have been changed to pass the regulator to DPI.
>
> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
> ---
> drivers/video/omap2/dss/dpi.c | 21 ++++++++++++++++++---
> 1 file changed, 18 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/video/omap2/dss/dpi.c b/drivers/video/omap2/dss/dpi.c
> index ad67a9c..08342d1 100644
> --- a/drivers/video/omap2/dss/dpi.c
> +++ b/drivers/video/omap2/dss/dpi.c
> @@ -37,7 +37,10 @@
> #include "dss_features.h"
>
> static struct {
> + struct platform_device *pdev;
We can use dpi.output.pdev, we don't really need to have another pdev
pointer. Same for SDI in the next patch.
Archit
> +
> struct regulator *vdds_dsi_reg;
> + bool vdds_dsi_from_core;
> struct platform_device *dsidev;
>
> struct mutex lock;
> @@ -583,10 +586,15 @@ static int __init dpi_init_display(struct omap_dss_device *dssdev)
> struct regulator *vdds_dsi;
>
> vdds_dsi = dss_get_vdds_dsi();
> -
> if (IS_ERR(vdds_dsi)) {
> - DSSERR("can't get VDDS_DSI regulator\n");
> - return PTR_ERR(vdds_dsi);
> + vdds_dsi = regulator_get(&dpi.pdev->dev, "vdds_dsi");
> + if (IS_ERR(vdds_dsi)) {
> + DSSERR("can't get VDDS_DSI regulator\n");
> + return PTR_ERR(vdds_dsi);
> + }
> + dpi.vdds_dsi_from_core = false;
> + } else {
> + dpi.vdds_dsi_from_core = true;
> }
>
> dpi.vdds_dsi_reg = vdds_dsi;
> @@ -698,6 +706,8 @@ static void __exit dpi_uninit_output(struct platform_device *pdev)
>
> static int __init omap_dpi_probe(struct platform_device *pdev)
> {
> + dpi.pdev = pdev;
> +
> mutex_init(&dpi.lock);
>
> dpi_init_output(pdev);
> @@ -714,6 +724,11 @@ static int __exit omap_dpi_remove(struct platform_device *pdev)
>
> dpi_uninit_output(pdev);
>
> + if (dpi.vdds_dsi_reg != NULL && dpi.vdds_dsi_from_core = false) {
> + regulator_put(dpi.vdds_dsi_reg);
> + dpi.vdds_dsi_reg = NULL;
> + }
> +
> return 0;
> }
>
>
^ permalink raw reply
* Re: [RFC 02/14] ARM: OMAP2+: add omapdss_init_of()
From: Tomi Valkeinen @ 2013-03-27 10:09 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <5152BBD3.9070202@ti.com>
[-- Attachment #1: Type: text/plain, Size: 3650 bytes --]
On 2013-03-27 11:28, Benoit Cousson wrote:
> Hi Tomi,
Hi Benoit. Thanks for your comments!
> On 03/27/2013 09:45 AM, Tomi Valkeinen wrote:
>> omapdss driver uses a omapdss platform device to pass platform specific
>> function pointers and DSS hardware version from the arch code to the
>> driver. This device is needed also when booting with DT.
>>
>> This patch adds omapdss_init_of() function, called from board-generic at
>> init time, which creates the omapdss device.
>>
>> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
>> ---
>> arch/arm/mach-omap2/board-generic.c | 1 +
>> arch/arm/mach-omap2/common.h | 2 ++
>> arch/arm/mach-omap2/display.c | 34 ++++++++++++++++++++++++++++++++++
>> 3 files changed, 37 insertions(+)
>>
>> diff --git a/arch/arm/mach-omap2/board-generic.c b/arch/arm/mach-omap2/board-generic.c
>> index a61544b..29eb085 100644
>> --- a/arch/arm/mach-omap2/board-generic.c
>> +++ b/arch/arm/mach-omap2/board-generic.c
>> @@ -41,6 +41,7 @@ static void __init omap_generic_init(void)
>>
>> of_platform_populate(NULL, omap_dt_match_table, NULL, NULL);
>>
>> + omapdss_init_of();
>
> Mmm, you should not have to call that explicitly. It looks like a hack
> to me. Everything in theory should be initialized during
> of_platform_populate / driver probe.
All the "real" devices are initialized properly. However, we still have
a "virtual" omapdss device, which does not represent a particular HW
block as such, and is not represented in the DT data. It's a legacy
thing, and slowly on its way out.
However, it still helps us to pass the platform callbacks via platform
data even in DT call, so we have this (hacky) omapdss_init_of() call.
And we also pass the OMAP revision information via the platform data, as
we need to know the DSS HW version. The only way to get that is to know
the OMAP version and revision. If we would set the DSS HW version
information into DT data, we could need separate dts files for each OMAP
revision.
>> +
>> +int __init omapdss_init_of(void)
>> +{
>> + int r;
>> + enum omapdss_version ver;
>> +
>> + static struct omap_dss_board_info board_data = {
>> + .dsi_enable_pads = omap_dsi_enable_pads,
>> + .dsi_disable_pads = omap_dsi_disable_pads,
>
> Pads config should be handle by pinmux framework is possible. Otherwise
> a dedicated driver will be required.
Hmm. These functions touch the OMAP4_CTRL_MODULE_PAD_CORE_CONTROL_DSIPHY
(CONTROL_DSIPHY in the TRM) register. It's not a normal padconfig thing
(like, selecting between GPIO and some other function).
Can they be handled by the pinmux framework? I'm not familiar with it.
What do you mean with dedicated driver? Dedicated pinmux driver, or
something else?
>> + .get_context_loss_count = omap_pm_get_dev_context_loss_count,
>> + .set_min_bus_tput = omap_dss_set_min_bus_tput,
>
>
> All that code should disappear with DT. hacking a platform device with
> pdata is the old way of initializing a device.
>
> I know that you do have some omap_pm callback, but you'd better get rid
> of them in case of DT boot.
> Fixing that is a generic issue, and as soon as a solution will be done
> to handle these specific hooks, every drivers will be able to use that.
So, what you're saying is that this is not the correct way, but there's
no other way to handle it currently? If so, yes, I know that, but, well,
there's no other way to handle it currently.
I could leave them out, but in that case when booting with DT there must
be no DSS context loss, and OPP must be at OPP100 all the time.
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 899 bytes --]
^ permalink raw reply
* Re: [RFC 00/14] Add DT support to OMAPDSS
From: Tomi Valkeinen @ 2013-03-27 10:15 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <5152BC4A.1060804@ti.com>
[-- Attachment #1: Type: text/plain, Size: 1488 bytes --]
On 2013-03-27 11:30, Benoit Cousson wrote:
> Hi Tomi,
>
> On 03/27/2013 09:45 AM, Tomi Valkeinen wrote:
>> Hi,
>>
>> This is an RFC for OMAPDSS DT support. I've only added support for a few boards
>> and a few DSS outputs, but they should give quite a good range of different use
>> cases. If these work well, I think the rest of the outputs and panels will be
>> ok too.
>>
>> The purpose of this series is to get comments about the dts changes. There are
>> still work to be done, like adding DT binding documentation.
>>
>> Some notes:
>>
>> * DSS Submodules
>>
>> The DSS submodules are children of the dss_core node. This is done because the
>> submodules require the dss_core to be alive and initialized to work, even if
>> the submodules are not really behind dss_core. Having the submodules as
>> children will make runtime PM automatically handle the dependency to dss_core.
>> I think usually a node being a child means that it's on the parent's bus, which
>> is not the case here. I'm not sure if that's an issue or not.
>
> FWIW, there is a L4_DSS interconnect. It is used internally to connect
> all the submodules to the DSS L3 port. So this representation is
> perfectly valid and does represent accurately the HW.
Ah, yes, I can see it mentioned in the OMAP4430 Block Diagram figure in
the TRM. No other mentions, though, I guess it's not really relevant =).
But good to know that the DT representation is actually correct.
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 899 bytes --]
^ permalink raw reply
* Re: [RFC 00/14] Add DT support to OMAPDSS
From: Tomi Valkeinen @ 2013-03-27 10:39 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <5152BEB7.4060804@ti.com>
[-- Attachment #1: Type: text/plain, Size: 2103 bytes --]
On 2013-03-27 11:41, Benoit Cousson wrote:
> + mturquette and Rajendra
>
> On 03/27/2013 09:45 AM, Tomi Valkeinen wrote:
>
> ...
>
>> * ti,dsi-module-id
>>
>> There's a ti,dsi-module-id property in the dsi node. The reason for this
>> module-id property is that we have muxes in the dss_core that route clocks
>> to/from a particular DSI module. So we need some way to index the DSI modules.
>> Another option would be to have a list of DSI modules (phandles) in the
>> dss_core. Both options feel a bit wrong to me, but I went for the module-id
>> approach as that is already used when not using DT.
>
> That's not a very nice representation. Ideally you should expose 1 clock
> node per DSI node, and enabling one will select the proper mux for you.
Afaik, we need the DSI module id for the following things:
1) DSI pad configuration (OMAP4_CTRL_MODULE_PAD_CORE_CONTROL_DSIPHY).
2) Setting clk mux in dss_core to select input clock for DSI protocol
engine. The choice is between DSS_CLK from PRCM, or clock from a DSI
PLL. DSI1 module can only use DSI1 PLL clock, and DSI2 module can only
use DSI2 PLL clock.
3) Setting clk mux in dss_core to select input clock for LCD/DISPC. The
choice is between DSS_CLK from PRCM, or a clock from DSI PLL. DISPC can
use either DSI1 or DSI2 PLL, LCD1 can use DSI1 PLL clock, LCD2 can use
DSI2 PLL clock.
4) Selecting the video output from DISPC which is routed to the DSI
module. LCD1 output can go to DSI1, LCD2 output can go to DSI1 or DSI2.
All the above of course change between OMAP versions.
So managing all the above was easiest with a plain module-id assigned to
the DSI device.
I guess 1) could be somehow managed by having separate nodes in the dts
for the DSIPHY control, and a link from the DSI module to that DSIPHY node.
4) could possibly be managed by having each DSS output node having a
list of possible inputs from the DISPC. And, I guess, a link somehow to
a mux node in the dss_core. Or something...
All in all, I don't have any clear idea how these should be handled.
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 899 bytes --]
^ permalink raw reply
* [PATCH] powerpc: remove PReP
From: Paul Bolle @ 2013-03-27 10:47 UTC (permalink / raw)
To: Benjamin Herrenschmidt, Paul Mackerras, Rob Landley, Adam Belay,
Bjorn Helgaas, Florian Tobias Schandinat
Cc: linux-fbdev, linuxppc-dev, linux-kernel, linux-doc
In-Reply-To: <20130322042159.GC26908@concordia>
PPC_PREP is marked as BROKEN since v2.6.15. Remove all PReP specific
code now.
Signed-off-by: Paul Bolle <pebolle@tiscali.nl>
---
0) Suggested by Michael.
1) Sent as one patch. powerpc is the biggest chunk (if one includes the
doc changes). Is it easier if I split this into a number maintainer
specific patches? Ie, split into: powerpc, doc, pnp and fb.
2) None of this is tested. None! Since I'm not actually involved in
powerpc in any way, not everyone might consider me the first choice to
do this cleanup.
3) I removed two files in documentation that are almost entirely PReP
specific. The remaining lines looked uninteresting.
4) I grepped thoroughly for second order effects. I also grepped for
remaining references to PReP. This patch has all things I thought that
could be dropped. Perhaps doing
git grep -n PReP | grep -v -i -e rewritten -e dougan
might still reveal, to those familiar with PReP, a few places of
outdated stuff.
Documentation/powerpc/00-INDEX | 4 --
Documentation/powerpc/sound.txt | 81 ---------------------------------
Documentation/powerpc/zImage_layout.txt | 47 -------------------
arch/powerpc/Kconfig | 8 ++--
arch/powerpc/include/asm/dma.h | 5 --
arch/powerpc/include/asm/io.h | 4 --
arch/powerpc/include/asm/processor.h | 9 +---
arch/powerpc/kernel/setup-common.c | 6 ---
arch/powerpc/platforms/Kconfig | 3 +-
arch/powerpc/platforms/prep/Kconfig | 23 ----------
drivers/pnp/pnpbios/core.c | 9 +---
drivers/video/cirrusfb.c | 62 +++++--------------------
12 files changed, 19 insertions(+), 242 deletions(-)
delete mode 100644 Documentation/powerpc/sound.txt
delete mode 100644 Documentation/powerpc/zImage_layout.txt
delete mode 100644 arch/powerpc/platforms/prep/Kconfig
diff --git a/Documentation/powerpc/00-INDEX b/Documentation/powerpc/00-INDEX
index 5620fb5..dd9e928 100644
--- a/Documentation/powerpc/00-INDEX
+++ b/Documentation/powerpc/00-INDEX
@@ -14,10 +14,6 @@ hvcs.txt
- IBM "Hypervisor Virtual Console Server" Installation Guide
mpc52xx.txt
- Linux 2.6.x on MPC52xx family
-sound.txt
- - info on sound support under Linux/PPC
-zImage_layout.txt
- - info on the kernel images for Linux/PPC
qe_firmware.txt
- describes the layout of firmware binaries for the Freescale QUICC
Engine and the code that parses and uploads the microcode therein.
diff --git a/Documentation/powerpc/sound.txt b/Documentation/powerpc/sound.txt
deleted file mode 100644
index df23d95..0000000
--- a/Documentation/powerpc/sound.txt
+++ /dev/null
@@ -1,81 +0,0 @@
- Information about PowerPC Sound support
-==================================-
-Please mail me (Cort Dougan, cort@fsmlabs.com) if you have questions,
-comments or corrections.
-
-Last Change: 6.16.99
-
-This just covers sound on the PReP and CHRP systems for now and later
-will contain information on the PowerMac's.
-
-Sound on PReP has been tested and is working with the PowerStack and IBM
-Power Series onboard sound systems which are based on the cs4231(2) chip.
-The sound options when doing the make config are a bit different from
-the default, though.
-
-The I/O base, irq and dma lines that you enter during the make config
-are ignored and are set when booting according to the machine type.
-This is so that one binary can be used for Motorola and IBM machines
-which use different values and isn't allowed by the driver, so things
-are hacked together in such a way as to allow this information to be
-set automatically on boot.
-
-1. Motorola PowerStack PReP machines
-
- Enable support for "Crystal CS4232 based (PnP) cards" and for the
- Microsoft Sound System. The MSS isn't used, but some of the routines
- that the CS4232 driver uses are in it.
-
- Although the options you set are ignored and determined automatically
- on boot these are included for information only:
-
- (830) CS4232 audio I/O base 530, 604, E80 or F40
- (10) CS4232 audio IRQ 5, 7, 9, 11, 12 or 15
- (6) CS4232 audio DMA 0, 1 or 3
- (7) CS4232 second (duplex) DMA 0, 1 or 3
-
- This will allow simultaneous record and playback, as 2 different dma
- channels are used.
-
- The sound will be all left channel and very low volume since the
- auxiliary input isn't muted by default. I had the changes necessary
- for this in the kernel but the sound driver maintainer didn't want
- to include them since it wasn't common in other machines. To fix this
- you need to mute it using a mixer utility of some sort (if you find one
- please let me know) or by patching the driver yourself and recompiling.
-
- There is a problem on the PowerStack 2's (PowerStack Pro's) using a
- different irq/drq than the kernel expects. Unfortunately, I don't know
- which irq/drq it is so if anyone knows please email me.
-
- Midi is not supported since the cs4232 driver doesn't support midi yet.
-
-2. IBM PowerPersonal PReP machines
-
- I've only tested sound on the Power Personal Series of IBM workstations
- so if you try it on others please let me know the result. I'm especially
- interested in the 43p's sound system, which I know nothing about.
-
- Enable support for "Crystal CS4232 based (PnP) cards" and for the
- Microsoft Sound System. The MSS isn't used, but some of the routines
- that the CS4232 driver uses are in it.
-
- Although the options you set are ignored and determined automatically
- on boot these are included for information only:
-
- (530) CS4232 audio I/O base 530, 604, E80 or F40
- (5) CS4232 audio IRQ 5, 7, 9, 11, 12 or 15
- (1) CS4232 audio DMA 0, 1 or 3
- (7) CS4232 second (duplex) DMA 0, 1 or 3
- (330) CS4232 MIDI I/O base 330, 370, 3B0 or 3F0
- (9) CS4232 MIDI IRQ 5, 7, 9, 11, 12 or 15
-
- This setup does _NOT_ allow for recording yet.
-
- Midi is not supported since the cs4232 driver doesn't support midi yet.
-
-2. IBM CHRP
-
- I have only tested this on the 43P-150. Build the kernel with the cs4232
- set as a module and load the module with irq=9 dma=1 dma2=2 io=0x550
diff --git a/Documentation/powerpc/zImage_layout.txt b/Documentation/powerpc/zImage_layout.txt
deleted file mode 100644
index 048e015..0000000
--- a/Documentation/powerpc/zImage_layout.txt
+++ /dev/null
@@ -1,47 +0,0 @@
- Information about the Linux/PPC kernel images
-==================================-
-Please mail me (Cort Dougan, cort@fsmlabs.com) if you have questions,
-comments or corrections.
-
-This document is meant to answer several questions I've had about how
-the PReP system boots and how Linux/PPC interacts with that mechanism.
-It would be nice if we could have information on how other architectures
-boot here as well. If you have anything to contribute, please
-let me know.
-
-
-1. PReP boot file
-
- This is the file necessary to boot PReP systems from floppy or
- hard drive. The firmware reads the PReP partition table entry
- and will load the image accordingly.
-
- To boot the zImage, copy it onto a floppy with dd if=zImage of=/dev/fd0h1440
- or onto a PReP hard drive partition with dd if=zImage of=/dev/sda4
- assuming you've created a PReP partition (type 0x41) with fdisk on
- /dev/sda4.
-
- The layout of the image format is:
-
- 0x0 +------------+
- | | PReP partition table entry
- | |
- 0x400 +------------+
- | | Bootstrap program code + data
- | |
- | |
- +------------+
- | | compressed kernel, elf header removed
- +------------+
- | | initrd (if loaded)
- +------------+
- | | Elf section table for bootstrap program
- +------------+
-
-
-2. MBX boot file
-
- The MBX boards can load an elf image, and relocate it to the
- proper location in memory - it copies the image to the location it was
- linked at.
diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
index ea5bb04..bc0a44f 100644
--- a/arch/powerpc/Kconfig
+++ b/arch/powerpc/Kconfig
@@ -647,14 +647,14 @@ menu "Bus options"
config ISA
bool "Support for ISA-bus hardware"
- depends on PPC_PREP || PPC_CHRP
+ depends on PPC_CHRP
select PPC_I8259
help
Find out whether you have ISA slots on your motherboard. ISA is the
name of a bus system, i.e. the way the CPU talks to the other stuff
inside your box. If you have an Apple machine, say N here; if you
- have an IBM RS/6000 or pSeries machine or a PReP machine, say Y. If
- you have an embedded board, consult your board documentation.
+ have an IBM RS/6000 or pSeries machine, say Y. If you have an
+ embedded board, consult your board documentation.
config ZONE_DMA
bool
@@ -969,7 +969,7 @@ config TASK_SIZE_BOOL
config TASK_SIZE
hex "Size of user task space" if TASK_SIZE_BOOL
- default "0x80000000" if PPC_PREP || PPC_8xx
+ default "0x80000000" if PPC_8xx
default "0xc0000000"
config CONSISTENT_SIZE_BOOL
diff --git a/arch/powerpc/include/asm/dma.h b/arch/powerpc/include/asm/dma.h
index f6813e9..a5c6d83 100644
--- a/arch/powerpc/include/asm/dma.h
+++ b/arch/powerpc/include/asm/dma.h
@@ -16,10 +16,6 @@
*
* None of this really applies for Power Macintoshes. There is
* basically just enough here to get kernel/dma.c to compile.
- *
- * There may be some comments or restrictions made here which are
- * not valid for the PReP platform. Take what you read
- * with a grain of salt.
*/
#include <asm/io.h>
@@ -57,7 +53,6 @@
* - page registers for 5-7 don't use data bit 0, represent 128K pages
* - page registers for 0-3 use bit 0, represent 64K pages
*
- * On PReP, DMA transfers are limited to the lower 16MB of _physical_ memory.
* On CHRP, the W83C553F (and VLSI Tollgate?) support full 32 bit addressing.
* Note that addresses loaded into registers must be _physical_ addresses,
* not logical addresses (which may differ if paging is active).
diff --git a/arch/powerpc/include/asm/io.h b/arch/powerpc/include/asm/io.h
index f94ef42..dd15e5e 100644
--- a/arch/powerpc/include/asm/io.h
+++ b/arch/powerpc/include/asm/io.h
@@ -15,10 +15,6 @@
extern int check_legacy_ioport(unsigned long base_port);
#define I8042_DATA_REG 0x60
#define FDC_BASE 0x3f0
-/* only relevant for PReP */
-#define _PIDXR 0x279
-#define _PNPWRP 0xa79
-#define PNPBIOS_BASE 0xf000
#if defined(CONFIG_PPC64) && defined(CONFIG_PCI)
extern struct pci_dev *isa_bridge_pcidev;
diff --git a/arch/powerpc/include/asm/processor.h b/arch/powerpc/include/asm/processor.h
index 7ff9eaa..0a4cc5d 100644
--- a/arch/powerpc/include/asm/processor.h
+++ b/arch/powerpc/include/asm/processor.h
@@ -40,7 +40,7 @@
* -- BenH.
*/
-/* PREP sub-platform types see residual.h for these */
+/* PREP sub-platform types. Unused */
#define _PREP_Motorola 0x01 /* motorola prep */
#define _PREP_Firm 0x02 /* firmworks prep */
#define _PREP_IBM 0x00 /* ibm prep */
@@ -56,13 +56,6 @@
extern int _chrp_type;
-#ifdef CONFIG_PPC_PREP
-
-/* what kind of prep workstation we are */
-extern int _prep_type;
-
-#endif /* CONFIG_PPC_PREP */
-
#endif /* defined(__KERNEL__) && defined(CONFIG_PPC32) */
/*
diff --git a/arch/powerpc/kernel/setup-common.c b/arch/powerpc/kernel/setup-common.c
index bdc499c..63d051f 100644
--- a/arch/powerpc/kernel/setup-common.c
+++ b/arch/powerpc/kernel/setup-common.c
@@ -621,12 +621,6 @@ int check_legacy_ioport(unsigned long base_port)
case FDC_BASE: /* FDC1 */
np = of_find_node_by_type(NULL, "fdc");
break;
-#ifdef CONFIG_PPC_PREP
- case _PIDXR:
- case _PNPWRP:
- case PNPBIOS_BASE:
- /* implement me */
-#endif
default:
/* ipmi is supposed to fail here */
break;
diff --git a/arch/powerpc/platforms/Kconfig b/arch/powerpc/platforms/Kconfig
index 52de8bc..9089ae7 100644
--- a/arch/powerpc/platforms/Kconfig
+++ b/arch/powerpc/platforms/Kconfig
@@ -6,7 +6,6 @@ source "arch/powerpc/platforms/chrp/Kconfig"
source "arch/powerpc/platforms/512x/Kconfig"
source "arch/powerpc/platforms/52xx/Kconfig"
source "arch/powerpc/platforms/powermac/Kconfig"
-source "arch/powerpc/platforms/prep/Kconfig"
source "arch/powerpc/platforms/maple/Kconfig"
source "arch/powerpc/platforms/pasemi/Kconfig"
source "arch/powerpc/platforms/ps3/Kconfig"
@@ -233,7 +232,7 @@ endmenu
config PPC601_SYNC_FIX
bool "Workarounds for PPC601 bugs"
- depends on 6xx && (PPC_PREP || PPC_PMAC)
+ depends on 6xx && PPC_PMAC
help
Some versions of the PPC601 (the first PowerPC chip) have bugs which
mean that extra synchronization instructions are required near
diff --git a/arch/powerpc/platforms/prep/Kconfig b/arch/powerpc/platforms/prep/Kconfig
deleted file mode 100644
index 1547f66..0000000
--- a/arch/powerpc/platforms/prep/Kconfig
+++ /dev/null
@@ -1,23 +0,0 @@
-config PPC_PREP
- bool "PowerPC Reference Platform (PReP) based machines"
- depends on 6xx && BROKEN
- select HAVE_PCSPKR_PLATFORM
- select MPIC
- select PPC_I8259
- select PPC_INDIRECT_PCI
- select PPC_UDBG_16550
- select PPC_NATIVE
- default n
-
-config PREP_RESIDUAL
- bool "Support for PReP Residual Data"
- depends on PPC_PREP
- help
- Some PReP systems have residual data passed to the kernel by the
- firmware. This allows detection of memory size, devices present and
- other useful pieces of information. Sometimes this information is
- not present or incorrect, in which case it could lead to the machine
- behaving incorrectly. If this happens, either disable PREP_RESIDUAL
- or pass the 'noresidual' option to the kernel.
-
- If you are running a PReP system, say Y here, otherwise say N.
diff --git a/drivers/pnp/pnpbios/core.c b/drivers/pnp/pnpbios/core.c
index 5d66e55..9b86a01 100644
--- a/drivers/pnp/pnpbios/core.c
+++ b/drivers/pnp/pnpbios/core.c
@@ -513,10 +513,6 @@ static int __init pnpbios_init(void)
{
int ret;
-#if defined(CONFIG_PPC)
- if (check_legacy_ioport(PNPBIOS_BASE))
- return -ENODEV;
-#endif
if (pnpbios_disabled || dmi_check_system(pnpbios_dmi_table) ||
paravirt_enabled()) {
printk(KERN_INFO "PnPBIOS: Disabled\n");
@@ -570,10 +566,7 @@ fs_initcall(pnpbios_init);
static int __init pnpbios_thread_init(void)
{
struct task_struct *task;
-#if defined(CONFIG_PPC)
- if (check_legacy_ioport(PNPBIOS_BASE))
- return 0;
-#endif
+
if (pnpbios_disabled)
return 0;
diff --git a/drivers/video/cirrusfb.c b/drivers/video/cirrusfb.c
index c3dbbe6..97db3ba 100644
--- a/drivers/video/cirrusfb.c
+++ b/drivers/video/cirrusfb.c
@@ -53,12 +53,6 @@
#ifdef CONFIG_AMIGA
#include <asm/amigahw.h>
#endif
-#ifdef CONFIG_PPC_PREP
-#include <asm/machdep.h>
-#define isPReP machine_is(prep)
-#else
-#define isPReP 0
-#endif
#include <video/vga.h>
#include <video/cirrus.h>
@@ -557,30 +551,18 @@ static int cirrusfb_check_var(struct fb_var_screeninfo *var,
break;
case 16:
- if (isPReP) {
- var->red.offset = 2;
- var->green.offset = -3;
- var->blue.offset = 8;
- } else {
- var->red.offset = 11;
- var->green.offset = 5;
- var->blue.offset = 0;
- }
+ var->red.offset = 11;
+ var->green.offset = 5;
+ var->blue.offset = 0;
var->red.length = 5;
var->green.length = 6;
var->blue.length = 5;
break;
case 24:
- if (isPReP) {
- var->red.offset = 0;
- var->green.offset = 8;
- var->blue.offset = 16;
- } else {
- var->red.offset = 16;
- var->green.offset = 8;
- var->blue.offset = 0;
- }
+ var->red.offset = 16;
+ var->green.offset = 8;
+ var->blue.offset = 0;
var->red.length = 8;
var->green.length = 8;
var->blue.length = 8;
@@ -1874,17 +1856,6 @@ static void cirrusfb_imageblit(struct fb_info *info,
}
}
-#ifdef CONFIG_PPC_PREP
-#define PREP_VIDEO_BASE ((volatile unsigned long) 0xC0000000)
-#define PREP_IO_BASE ((volatile unsigned char *) 0x80000000)
-static void get_prep_addrs(unsigned long *display, unsigned long *registers)
-{
- *display = PREP_VIDEO_BASE;
- *registers = (unsigned long) PREP_IO_BASE;
-}
-
-#endif /* CONFIG_PPC_PREP */
-
#ifdef CONFIG_PCI
static int release_io_ports;
@@ -2139,21 +2110,12 @@ static int cirrusfb_pci_register(struct pci_dev *pdev,
dev_dbg(info->device, " base address 1 is 0x%Lx\n",
(unsigned long long)pdev->resource[1].start);
- if (isPReP) {
- pci_write_config_dword(pdev, PCI_BASE_ADDRESS_0, 0x00000000);
-#ifdef CONFIG_PPC_PREP
- get_prep_addrs(&board_addr, &info->fix.mmio_start);
-#endif
- /* PReP dies if we ioremap the IO registers, but it works w/out... */
- cinfo->regbase = (char __iomem *) info->fix.mmio_start;
- } else {
- dev_dbg(info->device,
- "Attempt to get PCI info for Cirrus Graphics Card\n");
- get_pci_addrs(pdev, &board_addr, &info->fix.mmio_start);
- /* FIXME: this forces VGA. alternatives? */
- cinfo->regbase = NULL;
- cinfo->laguna_mmio = ioremap(info->fix.mmio_start, 0x1000);
- }
+ dev_dbg(info->device,
+ "Attempt to get PCI info for Cirrus Graphics Card\n");
+ get_pci_addrs(pdev, &board_addr, &info->fix.mmio_start);
+ /* FIXME: this forces VGA. alternatives? */
+ cinfo->regbase = NULL;
+ cinfo->laguna_mmio = ioremap(info->fix.mmio_start, 0x1000);
dev_dbg(info->device, "Board address: 0x%lx, register address: 0x%lx\n",
board_addr, info->fix.mmio_start);
--
1.7.11.7
^ permalink raw reply related
* Re: [PATCH 6/6] video: fb: vt8500: Convert framebuffer drivers to standardized binding
From: Tomi Valkeinen @ 2013-03-27 11:10 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1364374021-10844-7-git-send-email-linux@prisktech.co.nz>
[-- Attachment #1: Type: text/plain, Size: 1717 bytes --]
Hi,
On 2013-03-27 10:47, Tony Prisk wrote:
> Now that a display timing binding is available, convert our almost identical
> binding to use the standard binding.
>
> This patch converts the vt8500 and wm8505 framebuffer drivers and
> associated dts/dtsi files to use the standard binding as defined in
> bindings/video/display-timing.txt.
>
> There are two side-effects of making this conversion:
>
> 1) The fb node should now be in the board file, rather than the soc file as
> the display-timing node is a child of the fb node.
>
> 2) We still require a bits per pixel property to initialize the framebuffer
> for the different lcd panels. Rather than including this as part of the
> display timing, it is moved into the framebuffer node.
>
> I have also taken the opportunity to alphabetise the includes of each
> driver to avoid double-ups.
I don't think this is correct. I don't have that much experience with
DT, but I think you should have, for example:
wm8850.dtsi:
fb: fb@d8051700 {
compatible = "wm,wm8505-fb";
reg = <0xd8051700 0x200>;
};
wm8850-w70v2.dts:
&fb {
bits-per-pixel = <16>;
display-timings {
native-mode = <&timing0>;
timing0: 800x480 {
clock-frequency = <0>;
...
};
};
};
So, the core fb part should be in the SoC's file, as it's part of the
SoC. And the stuff that tells what kind of display is attached is in the
board dts file.
Also, just a word of warning, I think the videomode series I've sent for
review will cause some breakage with this series if the videomode series
is accepted. Nothing difficult to fix, though, but we'll need some extra
management to avoid compilation failures.
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 899 bytes --]
^ permalink raw reply
* Re: [PATCH 16/26] OMAPDSS: TFP410: convert to platform device
From: Tomi Valkeinen @ 2013-03-27 11:14 UTC (permalink / raw)
To: Archit Taneja; +Cc: linux-omap, linux-fbdev
In-Reply-To: <5152D3E8.9040603@ti.com>
[-- Attachment #1: Type: text/plain, Size: 1231 bytes --]
On 2013-03-27 13:11, Archit Taneja wrote:
> On Tuesday 26 March 2013 07:03 PM, Tomi Valkeinen wrote:
>> Convert TFP410 driver from omap_dss_driver to a platform driver. The
>> driver uses the new panel support from omapdss.
>>
>> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
>> ---
>> drivers/video/omap2/displays/panel-tfp410.c | 205
>> +++++++++++++++++----------
>> 1 file changed, 128 insertions(+), 77 deletions(-)
>>
>> - ddata->i2c_adapter = adapter;
>> + dssdev = &ddata->dssdev;
>> + dssdev->driver = &tfp410_driver;
>> + dssdev->panel.timings = tfp410_default_timings;
>> + dssdev->name = ddata->name;
>> + dssdev->phy.dpi.data_lines = ddata->data_lines;
>> + dssdev->panel_dev = &pdev->dev;
>
> Some of the omap_dss_device fields populated here(like data_lines) are
> not going to be used anywhere. Are you populating all of them just for
> the sake of clarity, so that they can be removed in another series later
> on? Or is there some other reason?
Unfortunately the datalines are used in
omapdss_default_get_recommended_bpp(). So there are some fields
populated just to keep things working, and I expect that they are
removed later.
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 899 bytes --]
^ permalink raw reply
* Re: [PATCH 16/26] OMAPDSS: TFP410: convert to platform device
From: Archit Taneja @ 2013-03-27 11:23 UTC (permalink / raw)
To: Tomi Valkeinen; +Cc: linux-omap, linux-fbdev
In-Reply-To: <1364304836-18134-17-git-send-email-tomi.valkeinen@ti.com>
On Tuesday 26 March 2013 07:03 PM, Tomi Valkeinen wrote:
> Convert TFP410 driver from omap_dss_driver to a platform driver. The
> driver uses the new panel support from omapdss.
>
> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
> ---
> drivers/video/omap2/displays/panel-tfp410.c | 205 +++++++++++++++++----------
> 1 file changed, 128 insertions(+), 77 deletions(-)
>
> diff --git a/drivers/video/omap2/displays/panel-tfp410.c b/drivers/video/omap2/displays/panel-tfp410.c
> index 8281baa..a225ea1 100644
> --- a/drivers/video/omap2/displays/panel-tfp410.c
> +++ b/drivers/video/omap2/displays/panel-tfp410.c
> @@ -22,10 +22,13 @@
> #include <video/omapdss.h>
> #include <linux/i2c.h>
> #include <linux/gpio.h>
> +#include <linux/platform_device.h>
> #include <drm/drm_edid.h>
>
> #include <video/omap-panel-tfp410.h>
>
> +static struct omap_dss_driver tfp410_driver;
> +
> static const struct omap_video_timings tfp410_default_timings = {
> .x_res = 640,
> .y_res = 480,
> @@ -48,121 +51,152 @@ static const struct omap_video_timings tfp410_default_timings = {
> };
>
> struct panel_drv_data {
> - struct omap_dss_device *dssdev;
> + struct omap_dss_device dssdev;
>
> struct mutex lock;
>
> + const char *name;
> +
> int pd_gpio;
> + int data_lines;
> +
> + struct omap_video_timings timings;
>
> struct i2c_adapter *i2c_adapter;
> };
>
> -static int tfp410_power_on(struct omap_dss_device *dssdev)
> +#define to_panel_data(x) container_of(x, struct panel_drv_data, dssdev)
> +
> +static int tfp410_probe_pdata(struct platform_device *pdev)
> {
> - struct panel_drv_data *ddata = dev_get_drvdata(&dssdev->dev);
> - int r;
> + struct tfp410_platform_data *pdata = dev_get_platdata(&pdev->dev);
> + struct panel_drv_data *ddata = dev_get_drvdata(&pdev->dev);
> + int r, gpio, i2c_bus_num;
>
> - if (dssdev->state = OMAP_DSS_DISPLAY_ACTIVE)
> - return 0;
> + ddata->name = pdata->name;
>
> - omapdss_dpi_set_timings(dssdev, &dssdev->panel.timings);
> - omapdss_dpi_set_data_lines(dssdev, dssdev->phy.dpi.data_lines);
> + gpio = pdata->power_down_gpio;
>
> - r = omapdss_dpi_display_enable(dssdev);
> - if (r)
> - goto err0;
> + if (gpio_is_valid(gpio)) {
> + r = devm_gpio_request_one(&pdev->dev, gpio,
> + GPIOF_OUT_INIT_LOW, "tfp410 pd");
> + if (r) {
> + dev_err(&pdev->dev, "Failed to request PD GPIO %d\n",
> + gpio);
> + return r;
> + }
>
> - if (gpio_is_valid(ddata->pd_gpio))
> - gpio_set_value_cansleep(ddata->pd_gpio, 1);
> + ddata->pd_gpio = gpio;
> + } else {
> + ddata->pd_gpio = -1;
> + }
>
> - return 0;
> -err0:
> - return r;
> -}
> + ddata->data_lines = pdata->data_lines;
>
> -static void tfp410_power_off(struct omap_dss_device *dssdev)
> -{
> - struct panel_drv_data *ddata = dev_get_drvdata(&dssdev->dev);
> + i2c_bus_num = pdata->i2c_bus_num;
>
> - if (dssdev->state != OMAP_DSS_DISPLAY_ACTIVE)
> - return;
> + if (i2c_bus_num != -1) {
> + struct i2c_adapter *adapter;
>
> - if (gpio_is_valid(ddata->pd_gpio))
> - gpio_set_value_cansleep(ddata->pd_gpio, 0);
> + adapter = i2c_get_adapter(i2c_bus_num);
> + if (!adapter) {
> + dev_err(&pdev->dev,
> + "Failed to get I2C adapter, bus %d\n",
> + i2c_bus_num);
> + return -EINVAL;
> + }
>
> - omapdss_dpi_display_disable(dssdev);
> + ddata->i2c_adapter = adapter;
> + }
> +
> + return 0;
> }
>
> -static int tfp410_probe(struct omap_dss_device *dssdev)
> +static int tfp410_probe(struct platform_device *pdev)
> {
> + struct tfp410_platform_data *pdata = dev_get_platdata(&pdev->dev);
> + struct omap_dss_device *dssdev;
> struct panel_drv_data *ddata;
> int r;
> - int i2c_bus_num;
>
> - ddata = devm_kzalloc(&dssdev->dev, sizeof(*ddata), GFP_KERNEL);
> + ddata = devm_kzalloc(&pdev->dev, sizeof(*ddata), GFP_KERNEL);
> if (!ddata)
> return -ENOMEM;
>
> - dssdev->panel.timings = tfp410_default_timings;
> + dev_set_drvdata(&pdev->dev, ddata);
>
> - ddata->dssdev = dssdev;
> mutex_init(&ddata->lock);
>
> - if (dssdev->data) {
> - struct tfp410_platform_data *pdata = dssdev->data;
> -
> - ddata->pd_gpio = pdata->power_down_gpio;
> - i2c_bus_num = pdata->i2c_bus_num;
> - } else {
> - ddata->pd_gpio = -1;
> - i2c_bus_num = -1;
> - }
> -
> - if (gpio_is_valid(ddata->pd_gpio)) {
> - r = devm_gpio_request_one(&dssdev->dev, ddata->pd_gpio,
> - GPIOF_OUT_INIT_LOW, "tfp410 pd");
> - if (r) {
> - dev_err(&dssdev->dev, "Failed to request PD GPIO %d\n",
> - ddata->pd_gpio);
> + if (pdata) {
> + r = tfp410_probe_pdata(pdev);
> + if (r)
> return r;
> - }
> + } else {
> + return -ENODEV;
> }
>
> - if (i2c_bus_num != -1) {
> - struct i2c_adapter *adapter;
> + ddata->timings = tfp410_default_timings;
>
> - adapter = i2c_get_adapter(i2c_bus_num);
> - if (!adapter) {
> - dev_err(&dssdev->dev, "Failed to get I2C adapter, bus %d\n",
> - i2c_bus_num);
> - return -EINVAL;
> - }
> -
> - ddata->i2c_adapter = adapter;
> + dssdev = &ddata->dssdev;
> + dssdev->driver = &tfp410_driver;
> + dssdev->panel.timings = tfp410_default_timings;
> + dssdev->name = ddata->name;
> + dssdev->phy.dpi.data_lines = ddata->data_lines;
> + dssdev->panel_dev = &pdev->dev;
Some of the omap_dss_device fields populated here(like data_lines) are
not going to be used anywhere. Are you populating all of them just for
the sake of clarity, so that they can be removed in another series later
on? Or is there some other reason?
Archit
> +
> + r = omap_dpi_register_panel(dssdev);
> + if (r) {
> + dev_err(&pdev->dev, "Failed to register panel\n");
> + return r;
> }
>
> - dev_set_drvdata(&dssdev->dev, ddata);
> -
> return 0;
> }
>
> -static void __exit tfp410_remove(struct omap_dss_device *dssdev)
> +static int __exit tfp410_remove(struct platform_device *pdev)
> {
> - struct panel_drv_data *ddata = dev_get_drvdata(&dssdev->dev);
> + struct panel_drv_data *ddata = dev_get_drvdata(&pdev->dev);
>
> mutex_lock(&ddata->lock);
>
> + omap_dpi_free_panel(&ddata->dssdev);
> +
> if (ddata->i2c_adapter)
> i2c_put_adapter(ddata->i2c_adapter);
>
> - dev_set_drvdata(&dssdev->dev, NULL);
> + dev_set_drvdata(&pdev->dev, NULL);
>
> mutex_unlock(&ddata->lock);
> +
> + return 0;
> +}
> +
> +static int tfp410_power_on(struct omap_dss_device *dssdev)
> +{
> + struct panel_drv_data *ddata = to_panel_data(dssdev);
> + int r;
> +
> + if (dssdev->state = OMAP_DSS_DISPLAY_ACTIVE)
> + return 0;
> +
> + omapdss_dpi_set_timings(dssdev, &ddata->timings);
> + omapdss_dpi_set_data_lines(dssdev, ddata->data_lines);
> +
> + r = omapdss_dpi_display_enable(dssdev);
> + if (r)
> + goto err0;
> +
> + if (gpio_is_valid(ddata->pd_gpio))
> + gpio_set_value_cansleep(ddata->pd_gpio, 1);
> +
> + return 0;
> +err0:
> + return r;
> }
>
> static int tfp410_enable(struct omap_dss_device *dssdev)
> {
> - struct panel_drv_data *ddata = dev_get_drvdata(&dssdev->dev);
> + struct panel_drv_data *ddata = to_panel_data(dssdev);
> int r;
>
> mutex_lock(&ddata->lock);
> @@ -176,9 +210,22 @@ static int tfp410_enable(struct omap_dss_device *dssdev)
> return r;
> }
>
> +static void tfp410_power_off(struct omap_dss_device *dssdev)
> +{
> + struct panel_drv_data *ddata = to_panel_data(dssdev);
> +
> + if (dssdev->state != OMAP_DSS_DISPLAY_ACTIVE)
> + return;
> +
> + if (gpio_is_valid(ddata->pd_gpio))
> + gpio_set_value_cansleep(ddata->pd_gpio, 0);
> +
> + omapdss_dpi_display_disable(dssdev);
> +}
> +
> static void tfp410_disable(struct omap_dss_device *dssdev)
> {
> - struct panel_drv_data *ddata = dev_get_drvdata(&dssdev->dev);
> + struct panel_drv_data *ddata = to_panel_data(dssdev);
>
> mutex_lock(&ddata->lock);
>
> @@ -192,18 +239,19 @@ static void tfp410_disable(struct omap_dss_device *dssdev)
> static void tfp410_set_timings(struct omap_dss_device *dssdev,
> struct omap_video_timings *timings)
> {
> - struct panel_drv_data *ddata = dev_get_drvdata(&dssdev->dev);
> + struct panel_drv_data *ddata = to_panel_data(dssdev);
>
> mutex_lock(&ddata->lock);
> omapdss_dpi_set_timings(dssdev, timings);
> dssdev->panel.timings = *timings;
> + ddata->timings = *timings;
> mutex_unlock(&ddata->lock);
> }
>
> static void tfp410_get_timings(struct omap_dss_device *dssdev,
> struct omap_video_timings *timings)
> {
> - struct panel_drv_data *ddata = dev_get_drvdata(&dssdev->dev);
> + struct panel_drv_data *ddata = to_panel_data(dssdev);
>
> mutex_lock(&ddata->lock);
> *timings = dssdev->panel.timings;
> @@ -213,7 +261,7 @@ static void tfp410_get_timings(struct omap_dss_device *dssdev,
> static int tfp410_check_timings(struct omap_dss_device *dssdev,
> struct omap_video_timings *timings)
> {
> - struct panel_drv_data *ddata = dev_get_drvdata(&dssdev->dev);
> + struct panel_drv_data *ddata = to_panel_data(dssdev);
> int r;
>
> mutex_lock(&ddata->lock);
> @@ -258,7 +306,7 @@ static int tfp410_ddc_read(struct i2c_adapter *adapter,
> static int tfp410_read_edid(struct omap_dss_device *dssdev,
> u8 *edid, int len)
> {
> - struct panel_drv_data *ddata = dev_get_drvdata(&dssdev->dev);
> + struct panel_drv_data *ddata = to_panel_data(dssdev);
> int r, l, bytes_read;
>
> mutex_lock(&ddata->lock);
> @@ -298,7 +346,7 @@ err:
>
> static bool tfp410_detect(struct omap_dss_device *dssdev)
> {
> - struct panel_drv_data *ddata = dev_get_drvdata(&dssdev->dev);
> + struct panel_drv_data *ddata = to_panel_data(dssdev);
> unsigned char out;
> int r;
>
> @@ -319,9 +367,6 @@ out:
> }
>
> static struct omap_dss_driver tfp410_driver = {
> - .probe = tfp410_probe,
> - .remove = __exit_p(tfp410_remove),
> -
> .enable = tfp410_enable,
> .disable = tfp410_disable,
>
> @@ -329,23 +374,29 @@ static struct omap_dss_driver tfp410_driver = {
> .get_timings = tfp410_get_timings,
> .check_timings = tfp410_check_timings,
>
> + .get_resolution = omapdss_default_get_resolution,
> +
> .read_edid = tfp410_read_edid,
> .detect = tfp410_detect,
> +};
>
> - .driver = {
> - .name = "tfp410",
> - .owner = THIS_MODULE,
> +static struct platform_driver tfp410_platform_driver = {
> + .probe = tfp410_probe,
> + .remove = __exit_p(tfp410_remove),
> + .driver = {
> + .name = "tfp410",
> + .owner = THIS_MODULE,
> },
> };
>
> static int __init tfp410_init(void)
> {
> - return omap_dss_register_driver(&tfp410_driver);
> + return platform_driver_register(&tfp410_platform_driver);
> }
>
> static void __exit tfp410_exit(void)
> {
> - omap_dss_unregister_driver(&tfp410_driver);
> + platform_driver_unregister(&tfp410_platform_driver);
> }
>
> module_init(tfp410_init);
>
^ permalink raw reply
* Re: [PATCH 16/26] OMAPDSS: TFP410: convert to platform device
From: Archit Taneja @ 2013-03-27 11:29 UTC (permalink / raw)
To: Tomi Valkeinen; +Cc: linux-omap, linux-fbdev
In-Reply-To: <5152D49A.2090309@ti.com>
On Wednesday 27 March 2013 04:44 PM, Tomi Valkeinen wrote:
> On 2013-03-27 13:11, Archit Taneja wrote:
>> On Tuesday 26 March 2013 07:03 PM, Tomi Valkeinen wrote:
>>> Convert TFP410 driver from omap_dss_driver to a platform driver. The
>>> driver uses the new panel support from omapdss.
>>>
>>> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
>>> ---
>>> drivers/video/omap2/displays/panel-tfp410.c | 205
>>> +++++++++++++++++----------
>>> 1 file changed, 128 insertions(+), 77 deletions(-)
>>>
>
>>> - ddata->i2c_adapter = adapter;
>>> + dssdev = &ddata->dssdev;
>>> + dssdev->driver = &tfp410_driver;
>>> + dssdev->panel.timings = tfp410_default_timings;
>>> + dssdev->name = ddata->name;
>>> + dssdev->phy.dpi.data_lines = ddata->data_lines;
>>> + dssdev->panel_dev = &pdev->dev;
>>
>> Some of the omap_dss_device fields populated here(like data_lines) are
>> not going to be used anywhere. Are you populating all of them just for
>> the sake of clarity, so that they can be removed in another series later
>> on? Or is there some other reason?
>
> Unfortunately the datalines are used in
> omapdss_default_get_recommended_bpp(). So there are some fields
> populated just to keep things working, and I expect that they are
> removed later.
Ah okay, missed that. I guess it will be easier to remove these later on
anyway.
Archit
^ permalink raw reply
* Re: [PATCH] powerpc: remove PReP
From: Geert Uytterhoeven @ 2013-03-27 12:05 UTC (permalink / raw)
To: Paul Bolle
Cc: linux-fbdev, Florian Tobias Schandinat, linux-doc, linux-kernel,
Paul Mackerras, Rob Landley, Bjorn Helgaas, linuxppc-dev,
Adam Belay
In-Reply-To: <1364381223.1345.18.camel@x61.thuisdomein>
On Wed, Mar 27, 2013 at 11:47 AM, Paul Bolle <pebolle@tiscali.nl> wrote:
> 3) I removed two files in documentation that are almost entirely PReP
> specific. The remaining lines looked uninteresting.
> --- a/Documentation/powerpc/sound.txt
> +++ /dev/null
> -2. IBM CHRP
> -
> - I have only tested this on the 43P-150. Build the kernel with the cs4232
> - set as a module and load the module with irq=9 dma=1 dma2=2 io=0x550
This section is CHRP-specific. The cs4232 driver also worked on the
CHRP LongTrail.
But I don't remember if the parameter values above also applied to LongTrail.
I do remember it didn't work without specifing the right parameters, so you
probably want to keep this section.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* Re: [PATCH] powerpc: remove PReP
From: Paul Bolle @ 2013-03-27 12:42 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: linux-fbdev, Florian Tobias Schandinat, linux-doc, linux-kernel,
Paul Mackerras, Rob Landley, Bjorn Helgaas, linuxppc-dev,
Adam Belay
In-Reply-To: <CAMuHMdVs-Xxu9e=8WZbTBXE1_+iYOBKODgj9_EKmVbZA3z=8JA@mail.gmail.com>
On Wed, 2013-03-27 at 13:05 +0100, Geert Uytterhoeven wrote:
> This section is CHRP-specific. The cs4232 driver also worked on the
> CHRP LongTrail.
> But I don't remember if the parameter values above also applied to LongTrail.
> I do remember it didn't work without specifing the right parameters, so you
> probably want to keep this section.
My reasoning was quite simply that this file was 14 years old so that
probably nobody is using that stuff anymore. Are people actually using
CHRP (whatever that is)? Anyhow, cs4232 is mentioned in some other files
too:
$ git grep -l -n cs4232 Documentation/
Documentation/powerpc/sound.txt
Documentation/sound/alsa/ALSA-Configuration.txt
Documentation/sound/alsa/alsa-parameters.txt
Documentation/sound/oss/Introduction
Documentation/sound/oss/Tropez+
Could these few lines be dumped in one of these (except
powerpc/sound.txt, of course)?
Paul Bolle
^ permalink raw reply
* Re: [PATCH] powerpc: remove PReP
From: Paul Bolle @ 2013-03-27 12:55 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: linux-fbdev, Florian Tobias Schandinat, linux-doc, linux-kernel,
Paul Mackerras, Rob Landley, Bjorn Helgaas, linuxppc-dev
In-Reply-To: <1364388152.1345.29.camel@x61.thuisdomein>
By the way, I get bounces from Adam's address:
> I'm sorry to have to inform you that your message could not
> be delivered to one or more recipients. It's attached below.
>
> For further assistance, please send mail to <postmaster>
>
> If you do so, please include this problem report. You can
> delete your own text from the attached returned message.
>
> <abelay@mit.edu>: 550 5.1.1 <abelay@mit.edu>... User unknown
(It's now removed from the CC line.) Does anyone know what's going on
here?
Paul Bolle
^ permalink raw reply
* Re: [PATCH] powerpc: remove PReP
From: Benjamin Herrenschmidt @ 2013-03-27 15:27 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: Paul Bolle, Florian Tobias Schandinat, linux-doc, linux-fbdev,
linux-kernel, Paul Mackerras, Rob Landley, Bjorn Helgaas,
linuxppc-dev, Adam Belay
In-Reply-To: <CAMuHMdVs-Xxu9e=8WZbTBXE1_+iYOBKODgj9_EKmVbZA3z=8JA@mail.gmail.com>
On Wed, 2013-03-27 at 13:05 +0100, Geert Uytterhoeven wrote:
> On Wed, Mar 27, 2013 at 11:47 AM, Paul Bolle <pebolle@tiscali.nl> wrote:
> > 3) I removed two files in documentation that are almost entirely PReP
> > specific. The remaining lines looked uninteresting.
>
> > --- a/Documentation/powerpc/sound.txt
> > +++ /dev/null
>
> > -2. IBM CHRP
> > -
> > - I have only tested this on the 43P-150. Build the kernel with the cs4232
> > - set as a module and load the module with irq=9 dma=1 dma2=2 io=0x550
>
> This section is CHRP-specific. The cs4232 driver also worked on the
> CHRP LongTrail.
> But I don't remember if the parameter values above also applied to LongTrail.
> I do remember it didn't work without specifing the right parameters, so you
> probably want to keep this section.
Isn't LongTrail support LongDead ? Can we still boot these things at
all ? Anybody still has a functional one ?
Cheers,
Ben.
> Gr{oetje,eeting}s,
>
> Geert
>
> --
> Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
>
> In personal conversations with technical people, I call myself a hacker. But
> when I'm talking to journalists I just say "programmer" or something like that.
> -- Linus Torvalds
^ permalink raw reply
* [PATCH] drivers: video: matrox: changed kmalloc+memset with kzalloc
From: Andrei Epure @ 2013-03-27 20:12 UTC (permalink / raw)
To: FlorianSchandinat, linux-fbdev; +Cc: linux-kernel, Andrei Epure
Signed-off-by: Andrei Epure <epure.andrei@gmail.com>
---
drivers/video/matrox/matroxfb_base.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/video/matrox/matroxfb_base.c b/drivers/video/matrox/matroxfb_base.c
index 401a56e..2456529 100644
--- a/drivers/video/matrox/matroxfb_base.c
+++ b/drivers/video/matrox/matroxfb_base.c
@@ -2029,10 +2029,9 @@ static int matroxfb_probe(struct pci_dev* pdev, const struct pci_device_id* dumm
return -1;
}
- minfo = kmalloc(sizeof(*minfo), GFP_KERNEL);
+ minfo = kzalloc(sizeof(*minfo), GFP_KERNEL);
if (!minfo)
return -1;
- memset(minfo, 0, sizeof(*minfo));
minfo->pcidev = pdev;
minfo->dead = 0;
--
1.7.9.5
^ permalink raw reply related
* Re: [PATCH 00/26] DSS device model change
From: Tony Lindgren @ 2013-03-27 20:25 UTC (permalink / raw)
To: Tomi Valkeinen; +Cc: linux-omap, linux-fbdev, Archit Taneja
In-Reply-To: <51528E1F.9080608@ti.com>
* Tomi Valkeinen <tomi.valkeinen@ti.com> [130326 23:18]:
> On 2013-03-26 19:10, Tony Lindgren wrote:
> > * Tomi Valkeinen <tomi.valkeinen@ti.com> [130326 06:38]:
> >> Note about board files: I only convert a few board files here for example. I
> >> have a branch with board file changes for all the affected board files. I did
> >> not include them as they are more or less identical. If this series looks good,
> >> I will create an independent branch for the arch/arm stuff, so it can be pulled
> >> separately.
> >
> > Great looks good to me thanks.
>
> To make the DSS work properly after this device model change, we also
> need to solve the problem related to multiple display devices on the
> same video bus.
>
> Did the approach I suggested in
>
> http://permalink.gmane.org/gmane.linux.ports.arm.omap/96039
>
> look ok? Overo is the most complex one, I think the rest of the boards
> that require changes have just LCD and DVI that conflict. But it still
> means we'll have that kind of choice Kconfig option for all those boards.
Yes I think that's the best way to go until we just drop the board-*.c
files in favor of device tree.
Regards,
Tony
^ permalink raw reply
* [PATCH] video: exynos: Convert to devm_ioremap_resource()
From: Andrei Epure @ 2013-03-27 20:28 UTC (permalink / raw)
To: inki.dae, dh09.lee, kyungmin.park, FlorianSchandinat
Cc: linux-fbdev, linux-kernel, Andrei Epure
The new devm_ioremap_resource() provides its own error messages.
Patch found using coccinelle.
Signed-off-by: Andrei Epure <epure.andrei@gmail.com>
---
drivers/video/exynos/exynos_mipi_dsi.c | 7 +++----
1 file changed, 3 insertions(+), 4 deletions(-)
diff --git a/drivers/video/exynos/exynos_mipi_dsi.c b/drivers/video/exynos/exynos_mipi_dsi.c
index fac7df6..dd5e5e9 100644
--- a/drivers/video/exynos/exynos_mipi_dsi.c
+++ b/drivers/video/exynos/exynos_mipi_dsi.c
@@ -384,10 +384,9 @@ static int exynos_mipi_dsi_probe(struct platform_device *pdev)
res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
- dsim->reg_base = devm_request_and_ioremap(&pdev->dev, res);
- if (!dsim->reg_base) {
- dev_err(&pdev->dev, "failed to remap io region\n");
- ret = -ENOMEM;
+ dsim->reg_base = devm_ioremap_resource(&pdev->dev, res);
+ if (IS_ERR(dsim->reg_base)) {
+ ret = PTR_ERR(dsim->reg_base);
goto error;
}
--
1.7.9.5
^ permalink raw reply related
* [PATCH] video: omap2: dss: use PTR_RET function
From: Andrei Epure @ 2013-03-27 20:35 UTC (permalink / raw)
To: tomi.valkeinen, FlorianSchandinat
Cc: sumit.semwal, archit, cmahapatra, linux-omap, linux-fbdev,
linux-kernel, Andrei Epure
Use PTR_RET function instead of IS_ERR + PTR_ERR.
Patch found using coccinelle.
Signed-off-by: Andrei Epure <epure.andrei@gmail.com>
---
drivers/video/omap2/dss/core.c | 5 +----
1 file changed, 1 insertion(+), 4 deletions(-)
diff --git a/drivers/video/omap2/dss/core.c b/drivers/video/omap2/dss/core.c
index f8779d4..60cc6fe 100644
--- a/drivers/video/omap2/dss/core.c
+++ b/drivers/video/omap2/dss/core.c
@@ -181,10 +181,7 @@ int dss_debugfs_create_file(const char *name, void (*write)(struct seq_file *))
d = debugfs_create_file(name, S_IRUGO, dss_debugfs_dir,
write, &dss_debug_fops);
- if (IS_ERR(d))
- return PTR_ERR(d);
-
- return 0;
+ return PTR_RET(d);
}
#else /* CONFIG_OMAP2_DSS_DEBUGFS */
static inline int dss_initialize_debugfs(void)
--
1.7.9.5
^ permalink raw reply related
* [PATCH] video: mmp: removed reference preceded by free
From: Andrei Epure @ 2013-03-27 20:48 UTC (permalink / raw)
To: FlorianSchandinat
Cc: akpm, haojian.zhuang, cldu, zzhu3, linux-fbdev, linux-kernel,
Andrei Epure
Patch found with coccinelle.
Signed-off-by: Andrei Epure <epure.andrei@gmail.com>
---
drivers/video/mmp/core.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/drivers/video/mmp/core.c b/drivers/video/mmp/core.c
index 9ed8341..84de263 100644
--- a/drivers/video/mmp/core.c
+++ b/drivers/video/mmp/core.c
@@ -252,7 +252,5 @@ void mmp_unregister_path(struct mmp_path *path)
kfree(path);
mutex_unlock(&disp_lock);
-
- dev_info(path->dev, "de-register %s\n", path->name);
}
EXPORT_SYMBOL_GPL(mmp_unregister_path);
--
1.7.9.5
^ permalink raw reply related
* [PATCH] video: exynos: remove useless safety check in list traversal
From: Andrei Epure @ 2013-03-27 21:19 UTC (permalink / raw)
To: inki.dae, dh09.lee, kyungmin.park, FlorianSchandinat
Cc: linux-fbdev, linux-kernel, Andrei Epure
list_for_each_entry_safe() does not require safety check.
Patch found using coccinelle.
Signed-off-by: Andrei Epure <epure.andrei@gmail.com>
---
drivers/video/exynos/exynos_mipi_dsi.c | 16 ++++++----------
1 file changed, 6 insertions(+), 10 deletions(-)
diff --git a/drivers/video/exynos/exynos_mipi_dsi.c b/drivers/video/exynos/exynos_mipi_dsi.c
index dd5e5e9..fe84f08 100644
--- a/drivers/video/exynos/exynos_mipi_dsi.c
+++ b/drivers/video/exynos/exynos_mipi_dsi.c
@@ -214,8 +214,6 @@ static struct mipi_dsim_ddi *exynos_mipi_dsi_find_lcd_device(
mutex_lock(&mipi_dsim_lock);
list_for_each_entry_safe(dsim_ddi, next, &dsim_ddi_list, list) {
- if (!dsim_ddi)
- goto out;
lcd_dev = dsim_ddi->dsim_lcd_dev;
if (!lcd_dev)
@@ -473,17 +471,15 @@ static int exynos_mipi_dsi_remove(struct platform_device *pdev)
clk_disable(dsim->clock);
list_for_each_entry_safe(dsim_ddi, next, &dsim_ddi_list, list) {
- if (dsim_ddi) {
- if (dsim->id != dsim_ddi->bus_id)
- continue;
+ if (dsim->id != dsim_ddi->bus_id)
+ continue;
- dsim_lcd_drv = dsim_ddi->dsim_lcd_drv;
+ dsim_lcd_drv = dsim_ddi->dsim_lcd_drv;
- if (dsim_lcd_drv->remove)
- dsim_lcd_drv->remove(dsim_ddi->dsim_lcd_dev);
+ if (dsim_lcd_drv->remove)
+ dsim_lcd_drv->remove(dsim_ddi->dsim_lcd_dev);
- kfree(dsim_ddi);
- }
+ kfree(dsim_ddi);
}
return 0;
--
1.7.9.5
^ permalink raw reply related
* [PATCH] video: fixed missing iounmap coccinelle errors
From: Andrei Epure @ 2013-03-27 23:43 UTC (permalink / raw)
To: linux-arm-kernel
Modified or added the necessary goto statements so that the ioremapped
regions get unmapped before return.
Signed-off-by: Andrei Epure <epure.andrei@gmail.com>
---
drivers/video/vt8500lcdfb.c | 7 ++++---
drivers/video/wm8505fb.c | 7 ++++---
2 files changed, 8 insertions(+), 6 deletions(-)
diff --git a/drivers/video/vt8500lcdfb.c b/drivers/video/vt8500lcdfb.c
index aa2579c..b4ccca2 100644
--- a/drivers/video/vt8500lcdfb.c
+++ b/drivers/video/vt8500lcdfb.c
@@ -350,7 +350,7 @@ static int vt8500lcd_probe(struct platform_device *pdev)
if (!np) {
pr_err("%s: No display description in Device Tree\n", __func__);
ret = -EINVAL;
- goto failed_free_res;
+ goto failed_free_io;
}
/*
@@ -369,7 +369,7 @@ static int vt8500lcd_probe(struct platform_device *pdev)
ret |= of_property_read_u32(np, "bpp", &bpp);
if (ret) {
pr_err("%s: Unable to read display properties\n", __func__);
- goto failed_free_res;
+ goto failed_free_io;
}
of_mode.vmode = FB_VMODE_NONINTERLACED;
@@ -379,7 +379,8 @@ static int vt8500lcd_probe(struct platform_device *pdev)
GFP_KERNEL);
if (!fb_mem_virt) {
pr_err("%s: Failed to allocate framebuffer\n", __func__);
- return -ENOMEM;
+ ret = -ENOMEM;
+ goto failed_free_io;
};
fbi->fb.fix.smem_start = fb_mem_phys;
diff --git a/drivers/video/wm8505fb.c b/drivers/video/wm8505fb.c
index 4dd0580..2e8298e 100644
--- a/drivers/video/wm8505fb.c
+++ b/drivers/video/wm8505fb.c
@@ -332,7 +332,7 @@ static int wm8505fb_probe(struct platform_device *pdev)
if (!np) {
pr_err("%s: No display description in Device Tree\n", __func__);
ret = -EINVAL;
- goto failed_free_res;
+ goto failed_free_io;
}
/*
@@ -351,7 +351,7 @@ static int wm8505fb_probe(struct platform_device *pdev)
ret |= of_property_read_u32(np, "bpp", &bpp);
if (ret) {
pr_err("%s: Unable to read display properties\n", __func__);
- goto failed_free_res;
+ goto failed_free_io;
}
of_mode.vmode = FB_VMODE_NONINTERLACED;
@@ -369,7 +369,8 @@ static int wm8505fb_probe(struct platform_device *pdev)
GFP_KERNEL);
if (!fb_mem_virt) {
pr_err("%s: Failed to allocate framebuffer\n", __func__);
- return -ENOMEM;
+ ret = -ENOMEM;
+ goto failed_free_io;
};
fbi->fb.var.xres_virtual = of_mode.xres;
--
1.7.9.5
^ permalink raw reply related
* Re: [PATCH] video: exynos: Convert to devm_ioremap_resource()
From: Donghwa Lee @ 2013-03-27 23:52 UTC (permalink / raw)
To: Andrei Epure
Cc: inki.dae, kyungmin.park, FlorianSchandinat, linux-fbdev,
linux-kernel
In-Reply-To: <1364416081-24113-1-git-send-email-epure.andrei@gmail.com>
Hi,
Please refer to the following link.
http://marc.info/?l=linux-fbdev&m\x135963121130437&w=2
Best regard,
Donghwa Lee
On Thu, Mar 28, 2013 at 05:28, Andrei Epure wrote:
> The new devm_ioremap_resource() provides its own error messages.
> Patch found using coccinelle.
>
> Signed-off-by: Andrei Epure <epure.andrei@gmail.com>
> ---
> drivers/video/exynos/exynos_mipi_dsi.c | 7 +++----
> 1 file changed, 3 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/video/exynos/exynos_mipi_dsi.c b/drivers/video/exynos/exynos_mipi_dsi.c
> index fac7df6..dd5e5e9 100644
> --- a/drivers/video/exynos/exynos_mipi_dsi.c
> +++ b/drivers/video/exynos/exynos_mipi_dsi.c
> @@ -384,10 +384,9 @@ static int exynos_mipi_dsi_probe(struct platform_device *pdev)
>
> res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
>
> - dsim->reg_base = devm_request_and_ioremap(&pdev->dev, res);
> - if (!dsim->reg_base) {
> - dev_err(&pdev->dev, "failed to remap io region\n");
> - ret = -ENOMEM;
> + dsim->reg_base = devm_ioremap_resource(&pdev->dev, res);
> + if (IS_ERR(dsim->reg_base)) {
> + ret = PTR_ERR(dsim->reg_base);
> goto error;
> }
>
^ permalink raw reply
* [PATCH] video: fix invalid free of devm_ allocated data
From: Andrei Epure @ 2013-03-27 23:55 UTC (permalink / raw)
To: linux-arm-kernel
The objects allocated by devm_* APIs are managed by devres and are freed when
the device is detached. Hence there is no need to use kfree() explicitly.
Patch found using coccinelle.
Signed-off-by: Andrei Epure <epure.andrei@gmail.com>
---
drivers/video/vt8500lcdfb.c | 3 ---
drivers/video/wm8505fb.c | 3 ---
2 files changed, 6 deletions(-)
diff --git a/drivers/video/vt8500lcdfb.c b/drivers/video/vt8500lcdfb.c
index b4ccca2..ea3ee61 100644
--- a/drivers/video/vt8500lcdfb.c
+++ b/drivers/video/vt8500lcdfb.c
@@ -465,7 +465,6 @@ failed_free_res:
release_mem_region(res->start, resource_size(res));
failed_fbi:
platform_set_drvdata(pdev, NULL);
- kfree(fbi);
failed:
return ret;
}
@@ -494,8 +493,6 @@ static int vt8500lcd_remove(struct platform_device *pdev)
res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
release_mem_region(res->start, resource_size(res));
- kfree(fbi);
-
return 0;
}
diff --git a/drivers/video/wm8505fb.c b/drivers/video/wm8505fb.c
index 2e8298e..34a2de1 100644
--- a/drivers/video/wm8505fb.c
+++ b/drivers/video/wm8505fb.c
@@ -427,7 +427,6 @@ failed_free_res:
release_mem_region(res->start, resource_size(res));
failed_fbi:
platform_set_drvdata(pdev, NULL);
- kfree(fbi);
failed:
return ret;
}
@@ -451,8 +450,6 @@ static int wm8505fb_remove(struct platform_device *pdev)
res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
release_mem_region(res->start, resource_size(res));
- kfree(fbi);
-
return 0;
}
--
1.7.9.5
^ permalink raw reply related
* Re: [PATCH] video: exynos: remove useless safety check in list traversal
From: Donghwa Lee @ 2013-03-28 0:04 UTC (permalink / raw)
To: Andrei Epure
Cc: inki.dae, kyungmin.park, FlorianSchandinat, linux-fbdev,
linux-kernel
In-Reply-To: <1364419145-30375-1-git-send-email-epure.andrei@gmail.com>
Hi,
It looks good to me.
Acked-by: Donghwa Lee <dh09.lee@samsung.com>
Best regard,
Donghwa Lee
On Thu, Mar 28, 2013 at 06:19, Andrei Epure wrote:
> list_for_each_entry_safe() does not require safety check.
> Patch found using coccinelle.
>
> Signed-off-by: Andrei Epure<epure.andrei@gmail.com>
> ---
> drivers/video/exynos/exynos_mipi_dsi.c | 16 ++++++----------
> 1 file changed, 6 insertions(+), 10 deletions(-)
>
> diff --git a/drivers/video/exynos/exynos_mipi_dsi.c b/drivers/video/exynos/exynos_mipi_dsi.c
> index dd5e5e9..fe84f08 100644
> --- a/drivers/video/exynos/exynos_mipi_dsi.c
> +++ b/drivers/video/exynos/exynos_mipi_dsi.c
> @@ -214,8 +214,6 @@ static struct mipi_dsim_ddi *exynos_mipi_dsi_find_lcd_device(
> mutex_lock(&mipi_dsim_lock);
>
> list_for_each_entry_safe(dsim_ddi, next, &dsim_ddi_list, list) {
> - if (!dsim_ddi)
> - goto out;
>
> lcd_dev = dsim_ddi->dsim_lcd_dev;
> if (!lcd_dev)
> @@ -473,17 +471,15 @@ static int exynos_mipi_dsi_remove(struct platform_device *pdev)
> clk_disable(dsim->clock);
>
> list_for_each_entry_safe(dsim_ddi, next, &dsim_ddi_list, list) {
> - if (dsim_ddi) {
> - if (dsim->id != dsim_ddi->bus_id)
> - continue;
> + if (dsim->id != dsim_ddi->bus_id)
> + continue;
>
> - dsim_lcd_drv = dsim_ddi->dsim_lcd_drv;
> + dsim_lcd_drv = dsim_ddi->dsim_lcd_drv;
>
> - if (dsim_lcd_drv->remove)
> - dsim_lcd_drv->remove(dsim_ddi->dsim_lcd_dev);
> + if (dsim_lcd_drv->remove)
> + dsim_lcd_drv->remove(dsim_ddi->dsim_lcd_dev);
>
> - kfree(dsim_ddi);
> - }
> + kfree(dsim_ddi);
> }
>
> return 0;
^ permalink raw reply
* Re: [PATCH] video: mmp: removed reference preceded by free
From: Zhou Zhu @ 2013-03-28 1:38 UTC (permalink / raw)
To: Andrei Epure
Cc: FlorianSchandinat@gmx.de, akpm@linux-foundation.org,
haojian.zhuang@gmail.com, Lisa Du, linux-fbdev@vger.kernel.org,
linux-kernel@vger.kernel.org
In-Reply-To: <1364417318-26650-1-git-send-email-epure.andrei@gmail.com>
On 03/28/2013 04:48 AM, Andrei Epure wrote:
> Patch found with coccinelle.
>
> Signed-off-by: Andrei Epure <epure.andrei@gmail.com>
> ---
> drivers/video/mmp/core.c | 2 --
> 1 file changed, 2 deletions(-)
>
> diff --git a/drivers/video/mmp/core.c b/drivers/video/mmp/core.c
> index 9ed8341..84de263 100644
> --- a/drivers/video/mmp/core.c
> +++ b/drivers/video/mmp/core.c
> @@ -252,7 +252,5 @@ void mmp_unregister_path(struct mmp_path *path)
>
> kfree(path);
> mutex_unlock(&disp_lock);
> -
> - dev_info(path->dev, "de-register %s\n", path->name);
> }
> EXPORT_SYMBOL_GPL(mmp_unregister_path);
>
Acked-by: Zhou Zhu <zzhu3@marvell.com>
^ permalink raw reply
* Re: [Bulk] [PATCH] video: fix invalid free of devm_ allocated data
From: Tony Prisk @ 2013-03-28 4:59 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1364428524-13821-1-git-send-email-epure.andrei@gmail.com>
On Thu, 2013-03-28 at 01:55 +0200, Andrei Epure wrote:
> The objects allocated by devm_* APIs are managed by devres and are freed when
> the device is detached. Hence there is no need to use kfree() explicitly.
> Patch found using coccinelle.
>
> Signed-off-by: Andrei Epure <epure.andrei@gmail.com>
> ---
> drivers/video/vt8500lcdfb.c | 3 ---
> drivers/video/wm8505fb.c | 3 ---
> 2 files changed, 6 deletions(-)
>
> diff --git a/drivers/video/vt8500lcdfb.c b/drivers/video/vt8500lcdfb.c
> index b4ccca2..ea3ee61 100644
> --- a/drivers/video/vt8500lcdfb.c
> +++ b/drivers/video/vt8500lcdfb.c
> @@ -465,7 +465,6 @@ failed_free_res:
> release_mem_region(res->start, resource_size(res));
> failed_fbi:
> platform_set_drvdata(pdev, NULL);
> - kfree(fbi);
> failed:
> return ret;
> }
> @@ -494,8 +493,6 @@ static int vt8500lcd_remove(struct platform_device *pdev)
> res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> release_mem_region(res->start, resource_size(res));
>
> - kfree(fbi);
> -
> return 0;
> }
>
> diff --git a/drivers/video/wm8505fb.c b/drivers/video/wm8505fb.c
> index 2e8298e..34a2de1 100644
> --- a/drivers/video/wm8505fb.c
> +++ b/drivers/video/wm8505fb.c
> @@ -427,7 +427,6 @@ failed_free_res:
> release_mem_region(res->start, resource_size(res));
> failed_fbi:
> platform_set_drvdata(pdev, NULL);
> - kfree(fbi);
> failed:
> return ret;
> }
> @@ -451,8 +450,6 @@ static int wm8505fb_remove(struct platform_device *pdev)
> res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> release_mem_region(res->start, resource_size(res));
>
> - kfree(fbi);
> -
> return 0;
> }
>
NACK
Already have a patch queued up for this from Julia Lawall
Regards
Tony P
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox