* [PATCH v2] arm: omap3evm: Add support for an MT9M032 based camera board.
From: martin at neutronstar.dyndns.org @ 2011-09-19 19:24 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <19F8576C6E063C45BE387C64729E739404EC8111DE@dbde02.ent.ti.com>
On Mon, Sep 19, 2011 at 11:37:37AM +0530, Hiremath, Vaibhav wrote:
>
> > -----Original Message-----
> > From: linux-omap-owner at vger.kernel.org [mailto:linux-omap-
> > owner at vger.kernel.org] On Behalf Of Laurent Pinchart
> > Sent: Monday, September 19, 2011 3:29 AM
> > To: Martin Hostettler
> > Cc: Tony Lindgren; linux-omap at vger.kernel.org; linux-
> > media at vger.kernel.org; linux-arm-kernel at lists.infradead.org
> > Subject: Re: [PATCH v2] arm: omap3evm: Add support for an MT9M032 based
> > camera board.
> >
> > Hi Martin,
> >
> > On Saturday 17 September 2011 11:34:57 Martin Hostettler wrote:
> > > Adds board support for an MT9M032 based camera to omap3evm.
> > >
> > > Sigend-off-by: Martin Hostettler <martin@neutronstar.dyndns.org>
> > > ---
> > > arch/arm/mach-omap2/Makefile | 1 +
> > > arch/arm/mach-omap2/board-omap3evm-camera.c | 183
> > > +++++++++++++++++++++++++++ 2 files changed, 184 insertions(+), 0
> > > deletions(-)
> > > create mode 100644 arch/arm/mach-omap2/board-omap3evm-camera.c
> > >
> > > Changes in V2:
> > > * ported to current mainline
> > > * Style fixes
> > > * Fix error handling
> > >
> > > diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile
> > > index f343365..8ae3d25 100644
> > > --- a/arch/arm/mach-omap2/Makefile
> > > +++ b/arch/arm/mach-omap2/Makefile
> > > @@ -202,6 +202,7 @@ obj-$(CONFIG_MACH_OMAP3_TORPEDO) +=
> > > board-omap3logic.o \ obj-$(CONFIG_MACH_OVERO) += board-overo.o \
> > > hsmmc.o
> > > obj-$(CONFIG_MACH_OMAP3EVM) += board-omap3evm.o \
> > > + board-omap3evm-camera.o \
> > > hsmmc.o
> > > obj-$(CONFIG_MACH_OMAP3_PANDORA) += board-omap3pandora.o \
> > > hsmmc.o
> > > diff --git a/arch/arm/mach-omap2/board-omap3evm-camera.c
> > > b/arch/arm/mach-omap2/board-omap3evm-camera.c new file mode 100644
> > > index 0000000..be987d9
> > > --- /dev/null
> > > +++ b/arch/arm/mach-omap2/board-omap3evm-camera.c
> > > @@ -0,0 +1,183 @@
> > > +/*
> > > + * Copyright (C) 2010-2011 Lund Engineering
> > > + * Contact: Gil Lund <gwlund@lundeng.com>
> > > + * Author: Martin Hostettler <martin@neutronstar.dyndns.org>
> > > + *
> [Hiremath, Vaibhav] The file below seems copied from (which is coming from all older releases of TI)
>
> http://arago-project.org/git/projects/?p=linux-omap3.git;a=blob;f=arch/arm/mach-omap2/board-omap3evm-camera.c;h=2e6ccfef69027dee880d507b98b5a7998d4bbe7e;hb=adcd067326836777c049e3cb32a5b7d9d401fc31
>
> So I would appreciate if you keep original copyright and authorship of the file and add your sign-off to the patch.
>
First of all i don't have any problem Adding your name and the TI
copyright.
Maybe i should have been more careful when looking at and adeption
omap3evm_set_mux as i really took that from the TI code.
I honestly don't remember if i took any other code from that file or not.
It ends up doing what the hardware needs anyway. For me it doesn't matter
with such trival things, but i should have been more careful.
Do you consider it resolved if use the following at the start?
/*
* Copyright (C) 2010 Texas Instruments Inc
* Copyright (C) 2010-2011 Lund Engineering
* Contact: Gil Lund <gwlund@lundeng.com>
* Authors:
* Vaibhav Hiremath <hvaibhav@ti.com>
* Martin Hostettler <martin@neutronstar.dyndns.org>
*/
But then again the copy on my harddisk has these too...
* Contributors:
* Anuj Aggarwal <anuj.aggarwal@ti.com>
* Sivaraj R <sivaraj@ti.com>
Maybe i should add them too.
Not sure really...
- Martin Hostettler
^ permalink raw reply
* [PATCH v2] arm: omap3evm: Add support for an MT9M032 based camera board.
From: Guennadi Liakhovetski @ 2011-09-19 19:17 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <201109182358.55816.laurent.pinchart@ideasonboard.com>
Hi
On Sun, 18 Sep 2011, Laurent Pinchart wrote:
> Hi Martin,
>
> On Saturday 17 September 2011 11:34:57 Martin Hostettler wrote:
> > Adds board support for an MT9M032 based camera to omap3evm.
> >
> > Sigend-off-by: Martin Hostettler <martin@neutronstar.dyndns.org>
> > ---
> > arch/arm/mach-omap2/Makefile | 1 +
> > arch/arm/mach-omap2/board-omap3evm-camera.c | 183
> > +++++++++++++++++++++++++++ 2 files changed, 184 insertions(+), 0
> > deletions(-)
> > create mode 100644 arch/arm/mach-omap2/board-omap3evm-camera.c
> >
> > Changes in V2:
> > * ported to current mainline
> > * Style fixes
> > * Fix error handling
> >
> > diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile
> > index f343365..8ae3d25 100644
> > --- a/arch/arm/mach-omap2/Makefile
> > +++ b/arch/arm/mach-omap2/Makefile
> > @@ -202,6 +202,7 @@ obj-$(CONFIG_MACH_OMAP3_TORPEDO) +=
> > board-omap3logic.o \ obj-$(CONFIG_MACH_OVERO) += board-overo.o \
> > hsmmc.o
> > obj-$(CONFIG_MACH_OMAP3EVM) += board-omap3evm.o \
> > + board-omap3evm-camera.o \
> > hsmmc.o
> > obj-$(CONFIG_MACH_OMAP3_PANDORA) += board-omap3pandora.o \
> > hsmmc.o
> > diff --git a/arch/arm/mach-omap2/board-omap3evm-camera.c
> > b/arch/arm/mach-omap2/board-omap3evm-camera.c new file mode 100644
> > index 0000000..be987d9
> > --- /dev/null
> > +++ b/arch/arm/mach-omap2/board-omap3evm-camera.c
> > @@ -0,0 +1,183 @@
[snip]
> > +static int __init camera_init(void)
> > +{
> > + int ret = -EINVAL;
> > +
> > + omap_mux_init_gpio(nCAM_VD_SEL, OMAP_PIN_OUTPUT);
> > + if (gpio_request(nCAM_VD_SEL, "nCAM_VD_SEL") < 0) {
> > + pr_err("omap3evm-camera: Failed to get GPIO nCAM_VD_SEL(%d)\n",
> > + nCAM_VD_SEL);
> > + goto err;
> > + }
> > + if (gpio_direction_output(nCAM_VD_SEL, 1) < 0) {
> > + pr_err("omap3evm-camera: Failed to set GPIO nCAM_VD_SEL(%d)
> > direction\n", + nCAM_VD_SEL);
> > + goto err_vdsel;
> > + }
> > +
> > + if (gpio_request(EVM_TWL_GPIO_BASE + 2, "T2_GPIO2") < 0) {
> > + pr_err("omap3evm-camera: Failed to get GPIO T2_GPIO2(%d)\n",
> > + EVM_TWL_GPIO_BASE + 2);
> > + goto err_vdsel;
> > + }
> > + if (gpio_direction_output(EVM_TWL_GPIO_BASE + 2, 0) < 0) {
> > + pr_err("omap3evm-camera: Failed to set GPIO T2_GPIO2(%d) direction\n",
> > + EVM_TWL_GPIO_BASE + 2);
> > + goto err_2;
> > + }
> > +
> > + if (gpio_request(EVM_TWL_GPIO_BASE + 8, "nCAM_VD_EN") < 0) {
> > + pr_err("omap3evm-camera: Failed to get GPIO nCAM_VD_EN(%d)\n",
> > + EVM_TWL_GPIO_BASE + 8);
> > + goto err_2;
> > + }
> > + if (gpio_direction_output(EVM_TWL_GPIO_BASE + 8, 0) < 0) {
> > + pr_err("omap3evm-camera: Failed to set GPIO nCAM_VD_EN(%d) direction\n",
> > + EVM_TWL_GPIO_BASE + 8);
> > + goto err_8;
> > + }
> > +
> > + omap3evm_set_mux(MUX_CAMERA_SENSOR);
> > +
> > +
> > + ret = omap3_init_camera(&isp_platform_data);
> > + if (ret < 0)
> > + goto err_8;
> > + return 0;
> > +
> > +err_8:
> > + gpio_free(EVM_TWL_GPIO_BASE + 8);
> > +err_2:
> > + gpio_free(EVM_TWL_GPIO_BASE + 2);
> > +err_vdsel:
> > + gpio_free(nCAM_VD_SEL);
> > +err:
> > + return ret;
> > +}
> > +
> > +device_initcall(camera_init);
>
> Please don't use device_initcall(), but call the function directly from the
> OMAP3 EVM init handler. Otherwise camera_init() will be called if OMAP3 EVM
> support is compiled in the kernel, regardless of the board the kernel runs on.
Another possibility is to put
if (!machine_is_omap3evm())
return 0;
in the beginning of the function. Probably, best to follow what other
omap3 boards do.
Thanks
Guennadi
---
Guennadi Liakhovetski, Ph.D.
Freelance Open-Source Software Developer
http://www.open-technology.de/
^ permalink raw reply
* Link failures due to __bug_table in current -next
From: Russell King - ARM Linux @ 2011-09-19 19:16 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20110919190602.GG540@opensource.wolfsonmicro.com>
On Mon, Sep 19, 2011 at 08:06:03PM +0100, Mark Brown wrote:
> Yeah, it's a shame it doesn't include the disambiguated short ID in the
> standard git log output (which is what I always grep if I'm trying to
> search commit messages). I've never seen a way to tell git to use %H
> instead of %h there by default that doesn't require me to start copying
> scripts or whatever between machines all the time.
I'm in two minds over this:
[format]
pretty = %h %s
which I currently have in my ~/.gitconfig file. It means that I always
get git log output as:
38c0a0c Merge branches 'apei', 'bz-13195' and 'doc' into acpi
b6fd41e Linux 3.1-rc6
8cb3ed17 Merge branch 'drm-fixes' of git://people.freedesktop.org/~airlied/linux4c75278 Merge branch 'fixes' of git://git.linaro.org/people/arnd/arm-soc
14d01ff ioctl: register LTTng ioctl
rather than the more usual medium-pretty output. I can get that by
using git log --pretty=medium. The alternative to that is to use
shell aliases to pass the --pretty= argument for a gitslog alias -
or I believe you can create git command aliases in the ~/.gitconfig file.
(Never tried it yet, something I need to look at.)
^ permalink raw reply
* Link failures due to __bug_table in current -next
From: Russell King - ARM Linux @ 2011-09-19 19:12 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20110919185809.GA16381@n2100.arm.linux.org.uk>
On Mon, Sep 19, 2011 at 07:58:09PM +0100, Russell King - ARM Linux wrote:
> What you're actually after is:
>
> 7c8a25b (CRIS: Discard exit.text and .data at runtime)
You're talking about this:
SECURITY_INIT
+ /* .exit.text is discarded at runtime, not link time,
+ * to deal with references from __bug_table
+ */
+ .exit.text : {
+ EXIT_TEXT
+ }
+ .exit.data : {
+ EXIT_DATA
+ }
+
This "fix" won't work for us - the exit text is being discarded
by the very first /DISCARD/ statement due to merging of /DISCARD/
output sections in the linker script, as I explained in my initial
reply to you.
include/asm-generic/vmlinux.lds.S:
#define EXIT_TEXT \
*(.exit.text) \
DEV_DISCARD(exit.text) \
CPU_DISCARD(exit.text) \
MEM_DISCARD(exit.text)
#define DISCARDS \
/DISCARD/ : { \
EXIT_TEXT \
EXIT_DATA \
EXIT_CALL \
*(.discard) \
*(.discard.*) \
}
and our vmlinux.lds.S:
SECTIONS
{
/*
* unwind exit sections must be discarded before the rest of the
* unwind sections get included.
*/
/DISCARD/ : {
*(.ARM.exidx.exit.text)
*(.ARM.extab.exit.text)
ARM_CPU_DISCARD(*(.ARM.exidx.cpuexit.text))
ARM_CPU_DISCARD(*(.ARM.extab.cpuexit.text))
#ifndef CONFIG_HOTPLUG
*(.ARM.exidx.devexit.text)
*(.ARM.extab.devexit.text)
#endif
#ifndef CONFIG_MMU
*(.fixup)
*(__ex_table)
#endif
#ifndef CONFIG_SMP_ON_UP
*(.alt.smp.init)
#endif
}
...
.exit.text : {
ARM_EXIT_KEEP(EXIT_TEXT)
}
...
/* Default discards */
DISCARDS
}
This is functionally equivalent with *current* linkers to:
SECTIONS
{
/*
* unwind exit sections must be discarded before the rest of the
* unwind sections get included.
*/
/DISCARD/ : {
*(.ARM.exidx.exit.text)
*(.ARM.extab.exit.text)
ARM_CPU_DISCARD(*(.ARM.exidx.cpuexit.text))
ARM_CPU_DISCARD(*(.ARM.extab.cpuexit.text))
#ifndef CONFIG_HOTPLUG
*(.ARM.exidx.devexit.text)
*(.ARM.extab.devexit.text)
#endif
#ifndef CONFIG_MMU
*(.fixup)
*(__ex_table)
#endif
#ifndef CONFIG_SMP_ON_UP
*(.alt.smp.init)
#endif
EXIT_TEXT
EXIT_DATA
EXIT_CALL
*(.discard)
*(.discard.*)
}
...
.exit.text : {
ARM_EXIT_KEEP(EXIT_TEXT)
}
...
}
and as *current* linker behaviour is the first input section found in
order in its internal list of output sections matches, the result is
that .exit.text is _always_ discarded irrespective of whether we want
it or not.
As an additional note, I can find nothing in the linker manual which
defines the behaviour of:
/DISCARD/ : {
*(.this.section.should.be.discarded)
}
.keep : {
*(.this.section.*)
}
It is entirely undefined whether ".this.section.should.be.discarded"
would be discarded or whether it ends up in .keep - it all depends on
the internal - undocumented - behaviour of the linker when assigning
input sections to output sections. As I mention above, that's
observably internal-merged-output-section-order,
input-section-order-within-output-section with current linkers but
there's no guarantee it'll remain that way.
I think we're running into some fundamental problems here, and I think
we need to get binutils people to come out with a statement concerning
how input sections are matched to output sections when there's multiple
statements in the linker script which match (eg, the most specific
match gets priority) and then we need to ensure that the kernels linker
scripts do not rely on section ordering.
^ permalink raw reply
* [PATCH] msm: platsmp: Mark ioremapped memory as __iomem
From: Arnd Bergmann @ 2011-09-19 19:12 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1316454844-32733-1-git-send-email-sboyd@codeaurora.org>
On Monday 19 September 2011 10:54:04 Stephen Boyd wrote:
> Fixes a handful of sparse warnings.
>
> Signed-off-by: Stephen Boyd <sboyd@codeaurora.org>
> ---
> arch/arm/mach-msm/platsmp.c | 2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
Hi Stephen,
This looks good, and I've got a bunch of similar ones in
http://git.linaro.org/gitweb?p=people/arnd/linux.git;a=shortlog;h=refs/heads/randconfig
/msm
Maybe you or David could take a look at those and integrate
them. I was meaning to send them much earlier, but never
get around to actually make sure they are all good.
arnd
^ permalink raw reply
* Link failures due to __bug_table in current -next
From: Mark Brown @ 2011-09-19 19:06 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20110919185809.GA16381@n2100.arm.linux.org.uk>
On Mon, Sep 19, 2011 at 07:58:09PM +0100, Russell King - ARM Linux wrote:
> On Mon, Sep 19, 2011 at 07:42:30PM +0100, Mark Brown wrote:
> > > > I'm wondering if we need something like 7c8a25 (CRIS: Discard exit.text
> > > > and .data at runtime) but figuring it out is a bit beyond my ld skills
> > > > right now.
> Pleas elook at the error message again. >>>ambiguous<<<. That means
> git knows about the ID but more than one commit matches it:
Oh, right - sorry.
> So there's IDs 7c8a251 and 7c8a25b in existence, and git doesn't know
> which one to use. So using that, I can track down the commit you
> actually meant.
> What you're actually after is:
> 7c8a25b (CRIS: Discard exit.text and .data at runtime)
Yup.
> which is what you'd get from git if you ask it to give you the shortened
> git ID. (Git knows when the shortened git ID clashes and will add
> additional digits to make up a unique ID.)
> You can use "git log --pretty='%h (%s)'" to get a log already formatted
> with parens around the summary line.
Yeah, it's a shame it doesn't include the disambiguated short ID in the
standard git log output (which is what I always grep if I'm trying to
search commit messages). I've never seen a way to tell git to use %H
instead of %h there by default that doesn't require me to start copying
scripts or whatever between machines all the time.
^ permalink raw reply
* Link failures due to __bug_table in current -next
From: Russell King - ARM Linux @ 2011-09-19 18:58 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20110919184230.GF540@opensource.wolfsonmicro.com>
On Mon, Sep 19, 2011 at 07:42:30PM +0100, Mark Brown wrote:
> On Mon, Sep 19, 2011 at 07:40:27PM +0100, Russell King - ARM Linux wrote:
> > On Mon, Sep 19, 2011 at 01:09:54PM +0100, Mark Brown wrote:
>
> > > I'm wondering if we need something like 7c8a25 (CRIS: Discard exit.text
> > > and .data at runtime) but figuring it out is a bit beyond my ld skills
> > > right now.
>
> > fatal: ambiguous argument '7c8a25': unknown revision or path not in the working
> > tree.
>
> > Maybe you could be more specific?
>
> It's in -next as of today, presumably it comes from the CRIS tree. I
> didn't look too closely once the revert worked for me.
Pleas elook at the error message again. >>>ambiguous<<<. That means
git knows about the ID but more than one commit matches it:
$ for f in 0 1 2 3 4 5 6 7 8 9 a b c d e f; do git cat-file -p 7c8a25$f >/dev/null; done
fatal: Not a valid object name 7c8a250
fatal: Not a valid object name 7c8a252
fatal: Not a valid object name 7c8a253
fatal: Not a valid object name 7c8a254
fatal: Not a valid object name 7c8a255
fatal: Not a valid object name 7c8a256
fatal: Not a valid object name 7c8a257
fatal: Not a valid object name 7c8a258
fatal: Not a valid object name 7c8a259
fatal: Not a valid object name 7c8a25a
fatal: Not a valid object name 7c8a25c
fatal: Not a valid object name 7c8a25d
fatal: Not a valid object name 7c8a25e
fatal: Not a valid object name 7c8a25f
So there's IDs 7c8a251 and 7c8a25b in existence, and git doesn't know
which one to use. So using that, I can track down the commit you
actually meant.
What you're actually after is:
7c8a25b (CRIS: Discard exit.text and .data at runtime)
which is what you'd get from git if you ask it to give you the shortened
git ID. (Git knows when the shortened git ID clashes and will add
additional digits to make up a unique ID.)
You can use "git log --pretty='%h (%s)'" to get a log already formatted
with parens around the summary line.
^ permalink raw reply
* Link failures due to __bug_table in current -next
From: Mark Brown @ 2011-09-19 18:42 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20110919184027.GZ16381@n2100.arm.linux.org.uk>
On Mon, Sep 19, 2011 at 07:40:27PM +0100, Russell King - ARM Linux wrote:
> On Mon, Sep 19, 2011 at 01:09:54PM +0100, Mark Brown wrote:
> > I'm wondering if we need something like 7c8a25 (CRIS: Discard exit.text
> > and .data at runtime) but figuring it out is a bit beyond my ld skills
> > right now.
> fatal: ambiguous argument '7c8a25': unknown revision or path not in the working
> tree.
> Maybe you could be more specific?
It's in -next as of today, presumably it comes from the CRIS tree. I
didn't look too closely once the revert worked for me.
^ permalink raw reply
* Link failures due to __bug_table in current -next
From: Russell King - ARM Linux @ 2011-09-19 18:40 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20110919120954.GA20314@opensource.wolfsonmicro.com>
On Mon, Sep 19, 2011 at 01:09:54PM +0100, Mark Brown wrote:
> I'm seeing linker failures in -next as of today:
>
> `.exit.text' referenced in section `__bug_table' of fs/built-in.o:
> defined in discarded section `.exit.text' of fs/built-in.o
> `.exit.text' referenced in section `__bug_table' of crypto/built-in.o:
> defined in discarded section `.exit.text' of crypto/built-in.o
> `.exit.text' referenced in section `__bug_table' of net/built-in.o:
> defined in discarded section `.exit.text' of net/built-in.o
> `.exit.text' referenced in section `__bug_table' of net/built-in.o:
> defined in discarded section `.exit.text' of net/built-in.o
>
> which appears to be due to the chnage to use generic BUG() introduced in
> commit 5254a3 (ARM: 7017/1: Use generic BUG() handler), reverting that
> commit resolves the issue for me.
It's a known issue - there's been an earlier thread about it:
http://lists.arm.linux.org.uk/lurker/thread/20110808.184931.a38e1c4e.en.html
The asm-generic/vmlinux.lds.S is basically relying on undefined behaviour
from the linker, which is biting us. There is no guaranteed ordering of
matching input sections to output sections, so listing the same section
more than once in the linker script is asking for problems.
The unfortunate thing is that the linker internally groups the /DISCARD/
sections together into one section, all grouped at the first mention of
the /DISCARD/ section. This means if you have several /DISCARD/ sections
scattered throughout the linker script, and you rely on the order in which
they appear, you're going to be disappointed because they'll all be merged
into the same position as the first one.
Practically, and observably, this means that for this linker script:
#undef DISCARD_EXIT_TEXT
#ifdef FOO
/DISCARD/ : {
*(.foo)
}
#endif
.foo : {
*(.foo)
}
.exit.text : {
#ifndef DISCARD_EXIT_TEXT
*(.exit.text)
#endif
}
/DISCARD/ : {
*(.exit.text)
}
If FOO is set, .exit.text will be discarded along with .foo. If FOO is
unset, both .exit.text and .foo will be kept.
Practically, this is what's happening - the DISCARD macro from the
asm-generic/vmlinux.lds.S lists input sections which _may_ be discarded
with the assumption that if they are required, they'll be mentioned
_before_ any discards. _That_ in itself is undefined linker behaviour.
> I'm wondering if we need something like 7c8a25 (CRIS: Discard exit.text
> and .data at runtime) but figuring it out is a bit beyond my ld skills
> right now.
fatal: ambiguous argument '7c8a25': unknown revision or path not in the working
tree.
Maybe you could be more specific?
^ permalink raw reply
* [PATCH] ARM: BUG() dies silently
From: Ramirez Luna, Omar @ 2011-09-19 18:32 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20110919182544.GY16381@n2100.arm.linux.org.uk>
Hi,
On Mon, Sep 19, 2011 at 1:25 PM, Russell King - ARM Linux
<linux@arm.linux.org.uk> wrote:
> I think I'm going to have to drop the generic bug support for the time being.
In this case then my patch can targeted for 3.1 and -stable, right? I
abandoned my change because the generic bug patch was the better
solution in the long term, but if it is being delayed I can submit
mine with your blessing.
https://lkml.org/lkml/2011/3/31/490
It just forces the compiler to generate the right code through
volatile, and while at it I could fix the other similar situations
(also noted in the patch).
Omar
^ permalink raw reply
* [PATCH] ARM: BUG() dies silently
From: Russell King - ARM Linux @ 2011-09-19 18:25 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAPnjgZ1JDGt7Dzp9VrRKKApeZ9RT9oqry+UkQZwVCw1P+t9pew@mail.gmail.com>
On Mon, Sep 19, 2011 at 11:02:08AM -0700, Simon Glass wrote:
> Hi Russell,
>
> On Mon, Sep 19, 2011 at 9:59 AM, Russell King - ARM Linux
> <linux@arm.linux.org.uk> wrote:
> > On Mon, Sep 19, 2011 at 03:43:13PM +0100, Russell King - ARM Linux wrote:
> >> On Mon, Sep 19, 2011 at 09:26:49AM -0500, Ramirez Luna, Omar wrote:
> >> > Hi
> >> >
> >> > On Sat, Sep 17, 2011 at 1:07 AM, Rabin Vincent <rabin@rab.in> wrote:
> >> > > If the "Use generic BUG() handler" patch is only scheduled for the next
> >> > > merge window and not for 3.1, can this patch be merged instead for 3.1
> >> > > and -stable? ?This problem is easily seen with GCC 4.6.
> >> >
> >> > I can send it for both and let the maintainers decide.
> >> >
> >> > Russell, do you give your ack?
> >>
> >> I think it's too large a change for -stable and 3.1 - let's get it into
> >> 3.2 first, and make sure no one sees any regressions there. ?Then we can
> >> think about submitting it to stable once its proven itself.
> >
> > And we're seeing link failures with the patch in the kernel, so it's
> > *definitely* not stable material as it stands, even if the current code
> > is a problem for GCC 4.6.
> >
> > Regressions trump bug fixes.
>
> Can you point me to the link failures please?
There's two emails during the last couple of months on lakml:
3.1-rc1 link failure
Link failures due to __bug_table in current -next
The former I looked into and came to the conclusion that the only way to
solve it is to stop using asm-generic/vmlinux.lds.S in its entirety and
go back to hand-coding ARMs vmlinux.lds file. No one's come forward
with any better suggestion to fix this, so I'm getting very close to
having to make a decision over this. I think I'm going to have to drop
the generic bug support for the time being.
^ permalink raw reply
* [PATCH] ARM: pl330: Fix a race condition
From: Jassi Brar @ 2011-09-19 18:07 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1316452291-19632-1-git-send-email-javi.merino@arm.com>
On Mon, Sep 19, 2011 at 10:41 PM, Javi Merino <javi.merino@arm.com> wrote:
> If two requests have been submitted and one of them is running, if you
> call pl330_chan_ctrl(ch_id, PL330_OP_START), there's a window of time
> between the spin_lock_irqsave() and the _state() check in which the
> running transaction may finish. ?In that case, we don't receive the
> interrupt (because they are disabled), but _start() sees that the DMA
> is stopped, so it starts it. ?The problem is that it sends the
> transaction that has just finished again, because pl330_update()
> hasn't mark it as done yet.
>
> This patch moves the _state() check out of the critical section, which
> removes the race condition. ?It also treats PL330_STATE_COMPLETING as
> still executing, because that introduces another race condition now
> that we call _state() with interrupts enabled. ?Namely, if we read the
> state as "completing" and the DMA sends the interrupt before we
> disable interrupts, pl330_update() starts the next transaction and
> returns. ?Then the _start() in pl330_chan_ctrl() will patiently wait
> until the just issued transaction finishes (because the state we read
> was PL330_STATE_COMPLETING) and when it does, it _trigger()s the same
> transaction again.
>
> Signed-off-by: Javi Merino <javi.merino@arm.com>
> Cc: Jassi Brar <jassi.brar@samsung.com>
> ---
> ?arch/arm/common/pl330.c | ? 12 +++++++-----
> ?1 files changed, 7 insertions(+), 5 deletions(-)
>
> diff --git a/arch/arm/common/pl330.c b/arch/arm/common/pl330.c
> index 97912fa..26b5615 100644
> --- a/arch/arm/common/pl330.c
> +++ b/arch/arm/common/pl330.c
> @@ -936,9 +936,9 @@ static bool _trigger(struct pl330_thread *thrd)
> ? ? ? ?return true;
> ?}
>
> -static bool _start(struct pl330_thread *thrd)
> +static bool _start(struct pl330_thread *thrd, u32 state)
> ?{
> - ? ? ? switch (_state(thrd)) {
> + ? ? ? switch (state) {
> ? ? ? ?case PL330_STATE_FAULT_COMPLETING:
> ? ? ? ? ? ? ? ?UNTIL(thrd, PL330_STATE_FAULTING | PL330_STATE_KILLING);
>
> @@ -949,7 +949,6 @@ static bool _start(struct pl330_thread *thrd)
> ? ? ? ? ? ? ? ?_stop(thrd);
>
> ? ? ? ?case PL330_STATE_KILLING:
> - ? ? ? case PL330_STATE_COMPLETING:
> ? ? ? ? ? ? ? ?UNTIL(thrd, PL330_STATE_STOPPED)
>
> ? ? ? ?case PL330_STATE_STOPPED:
> @@ -961,6 +960,7 @@ static bool _start(struct pl330_thread *thrd)
> ? ? ? ?case PL330_STATE_UPDTPC:
> ? ? ? ?case PL330_STATE_CACHEMISS:
> ? ? ? ?case PL330_STATE_EXECUTING:
> + ? ? ? case PL330_STATE_COMPLETING:
> ? ? ? ? ? ? ? ?return true;
>
> ? ? ? ?case PL330_STATE_WFE: /* For RESUME, nothing yet */
> @@ -1471,7 +1471,7 @@ int pl330_update(const struct pl330_info *pi)
> ? ? ? ? ? ? ? ? ? ? ? ?MARK_FREE(rqdone);
>
> ? ? ? ? ? ? ? ? ? ? ? ?/* Get going again ASAP */
> - ? ? ? ? ? ? ? ? ? ? ? _start(thrd);
> + ? ? ? ? ? ? ? ? ? ? ? _start(thrd, _state(thrd));
>
> ? ? ? ? ? ? ? ? ? ? ? ?/* For now, just make a list of callbacks to be done */
> ? ? ? ? ? ? ? ? ? ? ? ?list_add_tail(&rqdone->rqd, &pl330->req_done);
> @@ -1510,12 +1510,14 @@ int pl330_chan_ctrl(void *ch_id, enum pl330_chan_op op)
> ? ? ? ?struct pl330_dmac *pl330;
> ? ? ? ?unsigned long flags;
> ? ? ? ?int ret = 0, active;
> + ? ? ? u32 dma_state;
>
> ? ? ? ?if (!thrd || thrd->free || thrd->dmac->state == DYING)
> ? ? ? ? ? ? ? ?return -EINVAL;
>
> ? ? ? ?pl330 = thrd->dmac;
>
> + ? ? ? dma_state = _state(thrd);
> ? ? ? ?spin_lock_irqsave(&pl330->lock, flags);
>
> ? ? ? ?switch (op) {
> @@ -1546,7 +1548,7 @@ int pl330_chan_ctrl(void *ch_id, enum pl330_chan_op op)
>
> ? ? ? ? ? ? ? ?/* Start the next */
> ? ? ? ?case PL330_OP_START:
> - ? ? ? ? ? ? ? if (!_start(thrd))
> + ? ? ? ? ? ? ? if (!_start(thrd, dma_state))
> ? ? ? ? ? ? ? ? ? ? ? ?ret = -EIO;
> ? ? ? ? ? ? ? ?break;
>
> --
IIUIC your race scenario should be taken care of simply by doing...
diff --git a/arch/arm/common/pl330.c b/arch/arm/common/pl330.c
index 97912fa..7129cfb 100644
--- a/arch/arm/common/pl330.c
+++ b/arch/arm/common/pl330.c
@@ -1546,7 +1546,7 @@ int pl330_chan_ctrl(void *ch_id, enum pl330_chan_op op)
/* Start the next */
case PL330_OP_START:
- if (!_start(thrd))
+ if (!_thrd_active(thrd) && !_start(thrd))
ret = -EIO;
break;
Could you please test if it fixes the issue?
Thanks.
^ permalink raw reply related
* [PATCH] ARM: BUG() dies silently
From: Simon Glass @ 2011-09-19 18:02 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20110919165943.GX16381@n2100.arm.linux.org.uk>
Hi Russell,
On Mon, Sep 19, 2011 at 9:59 AM, Russell King - ARM Linux
<linux@arm.linux.org.uk> wrote:
> On Mon, Sep 19, 2011 at 03:43:13PM +0100, Russell King - ARM Linux wrote:
>> On Mon, Sep 19, 2011 at 09:26:49AM -0500, Ramirez Luna, Omar wrote:
>> > Hi
>> >
>> > On Sat, Sep 17, 2011 at 1:07 AM, Rabin Vincent <rabin@rab.in> wrote:
>> > > If the "Use generic BUG() handler" patch is only scheduled for the next
>> > > merge window and not for 3.1, can this patch be merged instead for 3.1
>> > > and -stable? ?This problem is easily seen with GCC 4.6.
>> >
>> > I can send it for both and let the maintainers decide.
>> >
>> > Russell, do you give your ack?
>>
>> I think it's too large a change for -stable and 3.1 - let's get it into
>> 3.2 first, and make sure no one sees any regressions there. ?Then we can
>> think about submitting it to stable once its proven itself.
>
> And we're seeing link failures with the patch in the kernel, so it's
> *definitely* not stable material as it stands, even if the current code
> is a problem for GCC 4.6.
>
> Regressions trump bug fixes.
Can you point me to the link failures please?
Regards,
Simon
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
>
^ permalink raw reply
* [PATCH 2/2] ARM: debug: Move DEBUG_ICEDCC into the DEBUG_LL choice
From: Stephen Boyd @ 2011-09-19 18:01 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1316455300-5752-1-git-send-email-sboyd@codeaurora.org>
DEBUG_ICEDCC support is just another DEBUG_LL choice and
selecting it along with other DEBUG_LL options doesn't make
much sense. Put it into the DEBUG_LL choice to avoid confusion.
Signed-off-by: Stephen Boyd <sboyd@codeaurora.org>
---
arch/arm/Kconfig.debug | 24 ++++++++++++------------
1 files changed, 12 insertions(+), 12 deletions(-)
diff --git a/arch/arm/Kconfig.debug b/arch/arm/Kconfig.debug
index a37e646..9661c51 100644
--- a/arch/arm/Kconfig.debug
+++ b/arch/arm/Kconfig.debug
@@ -81,6 +81,18 @@ choice
prompt "Kernel low-level debugging port"
depends on DEBUG_LL
+ config DEBUG_ICEDCC
+ bool "Kernel low-level debugging via EmbeddedICE DCC channel"
+ depends on DEBUG_LL
+ help
+ Say Y here if you want the debug print routines to direct
+ their output to the EmbeddedICE macrocell's DCC channel using
+ co-processor 14. This is known to work on the ARM9 style ICE
+ channel and on the XScale with the PEEDI.
+
+ It does include a timeout to ensure that the system does not
+ totally freeze when there is nothing connected to read.
+
config DEBUG_DC21285_PORT
bool "Kernel low-level debugging messages via footbridge serial port"
depends on FOOTBRIDGE
@@ -114,18 +126,6 @@ config EARLY_PRINTK
kernel low-level debugging functions. Add earlyprintk to your
kernel parameters to enable this console.
-config DEBUG_ICEDCC
- bool "Kernel low-level debugging via EmbeddedICE DCC channel"
- depends on DEBUG_LL
- help
- Say Y here if you want the debug print routines to direct their
- output to the EmbeddedICE macrocell's DCC channel using
- co-processor 14. This is known to work on the ARM9 style ICE
- channel and on the XScale with the PEEDI.
-
- It does include a timeout to ensure that the system does not
- totally freeze when there is nothing connected to read.
-
config OC_ETM
bool "On-chip ETM and ETB"
select ARM_AMBA
--
Sent by an employee of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum.
^ permalink raw reply related
* [PATCH 1/2] ARM: debug: Add CLSP711X_UART1 config choice
From: Stephen Boyd @ 2011-09-19 18:01 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20110916114140.GA31334@e102144-lin.cambridge.arm.com>
ARM patch 7072/1 (debug: use kconfig choice for selecting
DEBUG_LL UART) only allowed CLSP711X_UART2 to be selected because
there is no NONE option in a choice menu. Add a UART1 choice so
that users can still choose UART1 explicitly.
Signed-off-by: Stephen Boyd <sboyd@codeaurora.org>
---
On 09/16/11 04:41, Will Deacon wrote:
> Ah yes. This will need to be added as part of the platform updates to go via
> Arnd. It should be easy enough just to have a DEBUG_CLPS711X_UART1 option,
> for example, and the platform code will fall back to the first UART.
I couldn't find these patches applied in Arnd's tree so I based it off of
Russell's for-next branch.
arch/arm/Kconfig.debug | 9 +++++++--
1 files changed, 7 insertions(+), 2 deletions(-)
diff --git a/arch/arm/Kconfig.debug b/arch/arm/Kconfig.debug
index 60d1846..a37e646 100644
--- a/arch/arm/Kconfig.debug
+++ b/arch/arm/Kconfig.debug
@@ -90,14 +90,19 @@ choice
Saying N will cause the debug messages to appear on the first
16550 serial port.
+ config DEBUG_CLPS711X_UART1
+ bool "Kernel low-level debugging messages via UART1"
+ depends on ARCH_CLPS711X
+ help
+ Say Y here if you want the debug print routines to direct
+ their output to the first serial port on these devices.
+
config DEBUG_CLPS711X_UART2
bool "Kernel low-level debugging messages via UART2"
depends on ARCH_CLPS711X
help
Say Y here if you want the debug print routines to direct
their output to the second serial port on these devices.
- Saying N will cause the debug messages to appear on the first
- serial port.
endchoice
--
Sent by an employee of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum.
^ permalink raw reply related
* [PATCH] msm: platsmp: Mark ioremapped memory as __iomem
From: Stephen Boyd @ 2011-09-19 17:54 UTC (permalink / raw)
To: linux-arm-kernel
Fixes a handful of sparse warnings.
Signed-off-by: Stephen Boyd <sboyd@codeaurora.org>
---
arch/arm/mach-msm/platsmp.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-msm/platsmp.c b/arch/arm/mach-msm/platsmp.c
index 1a1af9e..365ef3f 100644
--- a/arch/arm/mach-msm/platsmp.c
+++ b/arch/arm/mach-msm/platsmp.c
@@ -79,7 +79,7 @@ static __cpuinit void prepare_cold_cpu(unsigned int cpu)
ret = scm_set_boot_addr(virt_to_phys(msm_secondary_startup),
SCM_FLAG_COLDBOOT_CPU1);
if (ret == 0) {
- void *sc1_base_ptr;
+ void __iomem *sc1_base_ptr;
sc1_base_ptr = ioremap_nocache(0x00902000, SZ_4K*2);
if (sc1_base_ptr) {
writel(0, sc1_base_ptr + VDD_SC1_ARRAY_CLAMP_GFS_CTL);
--
Sent by an employee of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum.
^ permalink raw reply related
* [PATCH V5 6/6] ARM: S5P6450: Add LCD-LTE480 and enable Framebuffer support
From: Ajay Kumar @ 2011-09-19 17:54 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1316454841-20869-1-git-send-email-ajaykumar.rs@samsung.com>
This patch:
-- Adds platform device support for LCD-LTE480.
-- Adds platform data for FB with win_mode and default_bpp.
-- Enables FB device support and platform-lcd support.
-- Adds SPCON settings for LCD.
Signed-off-by: Ajay Kumar <ajaykumar.rs@samsung.com>
---
arch/arm/mach-s5p64x0/Kconfig | 2 +
arch/arm/mach-s5p64x0/mach-smdk6450.c | 75 +++++++++++++++++++++++++++++++++
2 files changed, 77 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-s5p64x0/Kconfig b/arch/arm/mach-s5p64x0/Kconfig
index 3adc4b8..ecb4e44 100644
--- a/arch/arm/mach-s5p64x0/Kconfig
+++ b/arch/arm/mach-s5p64x0/Kconfig
@@ -54,6 +54,7 @@ config MACH_SMDK6440
config MACH_SMDK6450
bool "SMDK6450"
select CPU_S5P6450
+ select S3C_DEV_FB
select S3C_DEV_I2C1
select S3C_DEV_RTC
select S3C_DEV_WDT
@@ -62,6 +63,7 @@ config MACH_SMDK6450
select SAMSUNG_DEV_BACKLIGHT
select SAMSUNG_DEV_PWM
select SAMSUNG_DEV_TS
+ select S5P64X0_SETUP_FB_24BPP
select S5P64X0_SETUP_I2C1
help
Machine support for the Samsung SMDK6450
diff --git a/arch/arm/mach-s5p64x0/mach-smdk6450.c b/arch/arm/mach-s5p64x0/mach-smdk6450.c
index ee0da14..2a69caa 100644
--- a/arch/arm/mach-s5p64x0/mach-smdk6450.c
+++ b/arch/arm/mach-s5p64x0/mach-smdk6450.c
@@ -23,6 +23,9 @@
#include <linux/clk.h>
#include <linux/gpio.h>
#include <linux/pwm_backlight.h>
+#include <linux/fb.h>
+
+#include <video/platform_lcd.h>
#include <asm/mach/arch.h>
#include <asm/mach/map.h>
@@ -47,6 +50,8 @@
#include <plat/ts.h>
#include <plat/s5p-time.h>
#include <plat/backlight.h>
+#include <plat/fb.h>
+#include <plat/regs-fb.h>
#define SMDK6450_UCON_DEFAULT (S3C2410_UCON_TXILEVEL | \
S3C2410_UCON_RXILEVEL | \
@@ -110,6 +115,59 @@ static struct s3c2410_uartcfg smdk6450_uartcfgs[] __initdata = {
#endif
};
+/* Frame Buffer */
+static struct s3c_fb_pd_win smdk6450_fb_win0 = {
+ .win_mode = {
+ .left_margin = 8,
+ .right_margin = 13,
+ .upper_margin = 7,
+ .lower_margin = 5,
+ .hsync_len = 3,
+ .vsync_len = 1,
+ .xres = 800,
+ .yres = 480,
+ },
+ .max_bpp = 32,
+ .default_bpp = 24,
+};
+
+static struct s3c_fb_platdata smdk6450_lcd_pdata __initdata = {
+ .win[0] = &smdk6450_fb_win0,
+ .vidcon0 = VIDCON0_VIDOUT_RGB | VIDCON0_PNRMODE_RGB,
+ .vidcon1 = VIDCON1_INV_HSYNC | VIDCON1_INV_VSYNC,
+ .setup_gpio = s5p64x0_fb_gpio_setup_24bpp,
+};
+
+/* LCD power controller */
+static void smdk6450_lte480_reset_power(struct plat_lcd_data *pd,
+ unsigned int power)
+{
+ int err;
+
+ if (power) {
+ err = gpio_request(S5P6450_GPN(5), "GPN");
+ if (err) {
+ printk(KERN_ERR "failed to request GPN for lcd reset\n");
+ return;
+ }
+
+ gpio_direction_output(S5P6450_GPN(5), 1);
+ gpio_set_value(S5P6450_GPN(5), 0);
+ gpio_set_value(S5P6450_GPN(5), 1);
+ gpio_free(S5P6450_GPN(5));
+ }
+}
+
+static struct plat_lcd_data smdk6450_lcd_power_data = {
+ .set_power = smdk6450_lte480_reset_power,
+};
+
+static struct platform_device smdk6450_lcd_lte480wv = {
+ .name = "platform-lcd",
+ .dev.parent = &s3c_device_fb.dev,
+ .dev.platform_data = &smdk6450_lcd_power_data,
+};
+
static struct platform_device *smdk6450_devices[] __initdata = {
&s3c_device_adc,
&s3c_device_rtc,
@@ -119,6 +177,9 @@ static struct platform_device *smdk6450_devices[] __initdata = {
&s3c_device_wdt,
&samsung_asoc_dma,
&s5p6450_device_iis0,
+ &s3c_device_fb,
+ &smdk6450_lcd_lte480wv,
+
/* s5p6450_device_spi0 will be added */
};
@@ -166,6 +227,17 @@ static void __init smdk6450_map_io(void)
s5p_set_timer_source(S5P_PWM3, S5P_PWM4);
}
+static void s5p6450_set_lcd_interface(void)
+{
+ unsigned int cfg;
+
+ /* select TFT LCD type (RGB I/F) */
+ cfg = __raw_readl(S5P64X0_SPCON0);
+ cfg &= ~S5P64X0_SPCON0_LCD_SEL_MASK;
+ cfg |= S5P64X0_SPCON0_LCD_SEL_RGB;
+ __raw_writel(cfg, S5P64X0_SPCON0);
+}
+
static void __init smdk6450_machine_init(void)
{
s3c24xx_ts_set_platdata(NULL);
@@ -179,6 +251,9 @@ static void __init smdk6450_machine_init(void)
samsung_bl_set(&smdk6450_bl_gpio_info, &smdk6450_bl_data);
+ s5p6450_set_lcd_interface();
+ s3c_fb_set_platdata(&smdk6450_lcd_pdata);
+
platform_add_devices(smdk6450_devices, ARRAY_SIZE(smdk6450_devices));
}
--
1.7.0.4
^ permalink raw reply related
* [PATCH V5 5/6] ARM: S5P6440: Add LCD-LTE480 and enable Framebuffer support
From: Ajay Kumar @ 2011-09-19 17:54 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1316454841-20869-1-git-send-email-ajaykumar.rs@samsung.com>
This patch:
-- Adds platform device support for LCD-LTE480.
-- Adds platform data for FB with win_mode and default_bpp.
-- Enables FB device support and platform-lcd support.
-- Adds SPCON settings for LCD.
Signed-off-by: Ajay Kumar <ajaykumar.rs@samsung.com>
---
arch/arm/mach-s5p64x0/Kconfig | 2 +
arch/arm/mach-s5p64x0/include/mach/regs-gpio.h | 4 +
arch/arm/mach-s5p64x0/mach-smdk6440.c | 74 ++++++++++++++++++++++++
3 files changed, 80 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-s5p64x0/Kconfig b/arch/arm/mach-s5p64x0/Kconfig
index 7bec400..3adc4b8 100644
--- a/arch/arm/mach-s5p64x0/Kconfig
+++ b/arch/arm/mach-s5p64x0/Kconfig
@@ -37,6 +37,7 @@ config S5P64X0_SETUP_I2C1
config MACH_SMDK6440
bool "SMDK6440"
select CPU_S5P6440
+ select S3C_DEV_FB
select S3C_DEV_I2C1
select S3C_DEV_RTC
select S3C_DEV_WDT
@@ -45,6 +46,7 @@ config MACH_SMDK6440
select SAMSUNG_DEV_BACKLIGHT
select SAMSUNG_DEV_PWM
select SAMSUNG_DEV_TS
+ select S5P64X0_SETUP_FB_24BPP
select S5P64X0_SETUP_I2C1
help
Machine support for the Samsung SMDK6440
diff --git a/arch/arm/mach-s5p64x0/include/mach/regs-gpio.h b/arch/arm/mach-s5p64x0/include/mach/regs-gpio.h
index 6ce2547..88269ec 100644
--- a/arch/arm/mach-s5p64x0/include/mach/regs-gpio.h
+++ b/arch/arm/mach-s5p64x0/include/mach/regs-gpio.h
@@ -34,6 +34,10 @@
#define S5P6450_GPQ_BASE (S5P_VA_GPIO + 0x0180)
#define S5P6450_GPS_BASE (S5P_VA_GPIO + 0x0300)
+#define S5P64X0_SPCON0 (S5P_VA_GPIO + 0x1A0)
+#define S5P64X0_SPCON0_LCD_SEL_MASK (0x3 << 0)
+#define S5P64X0_SPCON0_LCD_SEL_RGB (0x1 << 0)
+
/* External interrupt control registers for group0 */
#define EINT0CON0_OFFSET (0x900)
diff --git a/arch/arm/mach-s5p64x0/mach-smdk6440.c b/arch/arm/mach-s5p64x0/mach-smdk6440.c
index 340f30f..b0465d4 100644
--- a/arch/arm/mach-s5p64x0/mach-smdk6440.c
+++ b/arch/arm/mach-s5p64x0/mach-smdk6440.c
@@ -23,6 +23,9 @@
#include <linux/clk.h>
#include <linux/gpio.h>
#include <linux/pwm_backlight.h>
+#include <linux/fb.h>
+
+#include <video/platform_lcd.h>
#include <asm/mach/arch.h>
#include <asm/mach/map.h>
@@ -47,6 +50,8 @@
#include <plat/ts.h>
#include <plat/s5p-time.h>
#include <plat/backlight.h>
+#include <plat/fb.h>
+#include <plat/regs-fb.h>
#define SMDK6440_UCON_DEFAULT (S3C2410_UCON_TXILEVEL | \
S3C2410_UCON_RXILEVEL | \
@@ -92,6 +97,59 @@ static struct s3c2410_uartcfg smdk6440_uartcfgs[] __initdata = {
},
};
+/* Frame Buffer */
+static struct s3c_fb_pd_win smdk6440_fb_win0 = {
+ .win_mode = {
+ .left_margin = 8,
+ .right_margin = 13,
+ .upper_margin = 7,
+ .lower_margin = 5,
+ .hsync_len = 3,
+ .vsync_len = 1,
+ .xres = 800,
+ .yres = 480,
+ },
+ .max_bpp = 32,
+ .default_bpp = 24,
+};
+
+static struct s3c_fb_platdata smdk6440_lcd_pdata __initdata = {
+ .win[0] = &smdk6440_fb_win0,
+ .vidcon0 = VIDCON0_VIDOUT_RGB | VIDCON0_PNRMODE_RGB,
+ .vidcon1 = VIDCON1_INV_HSYNC | VIDCON1_INV_VSYNC,
+ .setup_gpio = s5p64x0_fb_gpio_setup_24bpp,
+};
+
+/* LCD power controller */
+static void smdk6440_lte480_reset_power(struct plat_lcd_data *pd,
+ unsigned int power)
+{
+ int err;
+
+ if (power) {
+ err = gpio_request(S5P6440_GPN(5), "GPN");
+ if (err) {
+ printk(KERN_ERR "failed to request GPN for lcd reset\n");
+ return;
+ }
+
+ gpio_direction_output(S5P6440_GPN(5), 1);
+ gpio_set_value(S5P6440_GPN(5), 0);
+ gpio_set_value(S5P6440_GPN(5), 1);
+ gpio_free(S5P6440_GPN(5));
+ }
+}
+
+static struct plat_lcd_data smdk6440_lcd_power_data = {
+ .set_power = smdk6440_lte480_reset_power,
+};
+
+static struct platform_device smdk6440_lcd_lte480wv = {
+ .name = "platform-lcd",
+ .dev.parent = &s3c_device_fb.dev,
+ .dev.platform_data = &smdk6440_lcd_power_data,
+};
+
static struct platform_device *smdk6440_devices[] __initdata = {
&s3c_device_adc,
&s3c_device_rtc,
@@ -101,6 +159,8 @@ static struct platform_device *smdk6440_devices[] __initdata = {
&s3c_device_wdt,
&samsung_asoc_dma,
&s5p6440_device_iis,
+ &s3c_device_fb,
+ &smdk6440_lcd_lte480wv,
};
static struct s3c2410_platform_i2c s5p6440_i2c0_data __initdata = {
@@ -147,6 +207,17 @@ static void __init smdk6440_map_io(void)
s5p_set_timer_source(S5P_PWM3, S5P_PWM4);
}
+static void s5p6440_set_lcd_interface(void)
+{
+ unsigned int cfg;
+
+ /* select TFT LCD type (RGB I/F) */
+ cfg = __raw_readl(S5P64X0_SPCON0);
+ cfg &= ~S5P64X0_SPCON0_LCD_SEL_MASK;
+ cfg |= S5P64X0_SPCON0_LCD_SEL_RGB;
+ __raw_writel(cfg, S5P64X0_SPCON0);
+}
+
static void __init smdk6440_machine_init(void)
{
s3c24xx_ts_set_platdata(NULL);
@@ -160,6 +231,9 @@ static void __init smdk6440_machine_init(void)
samsung_bl_set(&smdk6440_bl_gpio_info, &smdk6440_bl_data);
+ s5p6440_set_lcd_interface();
+ s3c_fb_set_platdata(&smdk6440_lcd_pdata);
+
platform_add_devices(smdk6440_devices, ARRAY_SIZE(smdk6440_devices));
}
--
1.7.0.4
^ permalink raw reply related
* [PATCH RESEND V5 4/6] ARM: S5P64X0: Add GPIO setup for LCD
From: Ajay Kumar @ 2011-09-19 17:53 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1316454841-20869-1-git-send-email-ajaykumar.rs@samsung.com>
This patch adds GPIO lines settings(HSYNC, VSYNC, VCLK and VD) for LCD.
Signed-off-by: Ajay Kumar <ajaykumar.rs@samsung.com>
---
arch/arm/mach-s5p64x0/Kconfig | 6 ++++++
arch/arm/mach-s5p64x0/Makefile | 1 +
arch/arm/mach-s5p64x0/setup-fb-24bpp.c | 29 +++++++++++++++++++++++++++++
arch/arm/plat-samsung/include/plat/fb.h | 7 +++++++
4 files changed, 43 insertions(+), 0 deletions(-)
create mode 100644 arch/arm/mach-s5p64x0/setup-fb-24bpp.c
diff --git a/arch/arm/mach-s5p64x0/Kconfig b/arch/arm/mach-s5p64x0/Kconfig
index 65c7518..7bec400 100644
--- a/arch/arm/mach-s5p64x0/Kconfig
+++ b/arch/arm/mach-s5p64x0/Kconfig
@@ -21,6 +21,12 @@ config CPU_S5P6450
help
Enable S5P6450 CPU support
+config S5P64X0_SETUP_FB_24BPP
+ bool
+ help
+ Common setup code for S5P64X0 based boards with a LCD display
+ through RGB interface.
+
config S5P64X0_SETUP_I2C1
bool
help
diff --git a/arch/arm/mach-s5p64x0/Makefile b/arch/arm/mach-s5p64x0/Makefile
index 5f6afdf..1bf54b2 100644
--- a/arch/arm/mach-s5p64x0/Makefile
+++ b/arch/arm/mach-s5p64x0/Makefile
@@ -28,3 +28,4 @@ obj-y += dev-audio.o
obj-$(CONFIG_S3C64XX_DEV_SPI) += dev-spi.o
obj-$(CONFIG_S5P64X0_SETUP_I2C1) += setup-i2c1.o
+obj-$(CONFIG_S5P64X0_SETUP_FB_24BPP) += setup-fb-24bpp.o
diff --git a/arch/arm/mach-s5p64x0/setup-fb-24bpp.c b/arch/arm/mach-s5p64x0/setup-fb-24bpp.c
new file mode 100644
index 0000000..f346ee4
--- /dev/null
+++ b/arch/arm/mach-s5p64x0/setup-fb-24bpp.c
@@ -0,0 +1,29 @@
+/* linux/arch/arm/mach-s5p64x0/setup-fb-24bpp.c
+ *
+ * Copyright (c) 2011 Samsung Electronics Co., Ltd.
+ * http://www.samsung.com/
+ *
+ * Base S5P64X0 GPIO setup information for LCD framebuffer
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+*/
+
+#include <linux/fb.h>
+#include <linux/gpio.h>
+
+#include <plat/cpu.h>
+#include <plat/fb.h>
+#include <plat/gpio-cfg.h>
+
+void s5p64x0_fb_gpio_setup_24bpp(void)
+{
+ if (soc_is_s5p6440()) {
+ s3c_gpio_cfgrange_nopull(S5P6440_GPI(0), 16, S3C_GPIO_SFN(2));
+ s3c_gpio_cfgrange_nopull(S5P6440_GPJ(0), 12, S3C_GPIO_SFN(2));
+ } else if (soc_is_s5p6450()) {
+ s3c_gpio_cfgrange_nopull(S5P6450_GPI(0), 16, S3C_GPIO_SFN(2));
+ s3c_gpio_cfgrange_nopull(S5P6450_GPJ(0), 12, S3C_GPIO_SFN(2));
+ }
+}
diff --git a/arch/arm/plat-samsung/include/plat/fb.h b/arch/arm/plat-samsung/include/plat/fb.h
index 01f10e4..0fedf47 100644
--- a/arch/arm/plat-samsung/include/plat/fb.h
+++ b/arch/arm/plat-samsung/include/plat/fb.h
@@ -109,4 +109,11 @@ extern void s5pv210_fb_gpio_setup_24bpp(void);
*/
extern void exynos4_fimd0_gpio_setup_24bpp(void);
+/**
+ * s5p64x0_fb_gpio_setup_24bpp() - S5P6440/S5P6450 setup function for 24bpp LCD
+ *
+ * Initialise the GPIO for an 24bpp LCD display on the RGB interface.
+ */
+extern void s5p64x0_fb_gpio_setup_24bpp(void);
+
#endif /* __PLAT_S3C_FB_H */
--
1.7.0.4
^ permalink raw reply related
* [PATCH RESEND V5 3/6] ARM: S5P64X0: Set s3c_device_fb name
From: Ajay Kumar @ 2011-09-19 17:53 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1316454841-20869-1-git-send-email-ajaykumar.rs@samsung.com>
Set s3c_device_fb name as "s5p64x0-fb" for S5P6440 and S5P6450.
Signed-off-by: Ajay Kumar <ajaykumar.rs@samsung.com>
---
arch/arm/mach-s5p64x0/cpu.c | 3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-s5p64x0/cpu.c b/arch/arm/mach-s5p64x0/cpu.c
index a5c0095..617da3b 100644
--- a/arch/arm/mach-s5p64x0/cpu.c
+++ b/arch/arm/mach-s5p64x0/cpu.c
@@ -38,6 +38,7 @@
#include <plat/s5p6440.h>
#include <plat/s5p6450.h>
#include <plat/adc-core.h>
+#include <plat/fb-core.h>
/* Initial IO mappings */
@@ -108,6 +109,7 @@ void __init s5p6440_map_io(void)
{
/* initialize any device information early */
s3c_adc_setname("s3c64xx-adc");
+ s3c_fb_setname("s5p64x0-fb");
iotable_init(s5p64x0_iodesc, ARRAY_SIZE(s5p64x0_iodesc));
iotable_init(s5p6440_iodesc, ARRAY_SIZE(s5p6440_iodesc));
@@ -117,6 +119,7 @@ void __init s5p6450_map_io(void)
{
/* initialize any device information early */
s3c_adc_setname("s3c64xx-adc");
+ s3c_fb_setname("s5p64x0-fb");
iotable_init(s5p64x0_iodesc, ARRAY_SIZE(s5p64x0_iodesc));
iotable_init(s5p6450_iodesc, ARRAY_SIZE(s5p6450_iodesc));
--
1.7.0.4
^ permalink raw reply related
* [PATCH RESEND V5 2/6] ARM: S5P64X0: Add register base and IRQ for Framebuffer
From: Ajay Kumar @ 2011-09-19 17:53 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1316454841-20869-1-git-send-email-ajaykumar.rs@samsung.com>
This patch adds:
-- Framebuffer related register mappings and bit fields.
-- IRQ number being used.
Signed-off-by: Ajay Kumar <ajaykumar.rs@samsung.com>
---
arch/arm/mach-s5p64x0/include/mach/irqs.h | 4 ++++
arch/arm/mach-s5p64x0/include/mach/map.h | 3 +++
2 files changed, 7 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-s5p64x0/include/mach/irqs.h b/arch/arm/mach-s5p64x0/include/mach/irqs.h
index 5837a36..53982db 100644
--- a/arch/arm/mach-s5p64x0/include/mach/irqs.h
+++ b/arch/arm/mach-s5p64x0/include/mach/irqs.h
@@ -87,6 +87,10 @@
#define IRQ_I2S0 IRQ_I2SV40
+#define IRQ_LCD_FIFO IRQ_DISPCON0
+#define IRQ_LCD_VSYNC IRQ_DISPCON1
+#define IRQ_LCD_SYSTEM IRQ_DISPCON2
+
/* S5P6450 EINT feature will be added */
/*
diff --git a/arch/arm/mach-s5p64x0/include/mach/map.h b/arch/arm/mach-s5p64x0/include/mach/map.h
index 95c9125..c5ef50c 100644
--- a/arch/arm/mach-s5p64x0/include/mach/map.h
+++ b/arch/arm/mach-s5p64x0/include/mach/map.h
@@ -47,6 +47,8 @@
#define S5P64X0_PA_HSMMC(x) (0xED800000 + ((x) * 0x100000))
+#define S5P64X0_PA_FB 0xEE000000
+
#define S5P64X0_PA_I2S 0xF2000000
#define S5P6450_PA_I2S1 0xF2800000
#define S5P6450_PA_I2S2 0xF2900000
@@ -64,6 +66,7 @@
#define S3C_PA_IIC1 S5P6440_PA_IIC1
#define S3C_PA_RTC S5P64X0_PA_RTC
#define S3C_PA_WDT S5P64X0_PA_WDT
+#define S3C_PA_FB S5P64X0_PA_FB
#define S5P_PA_CHIPID S5P64X0_PA_CHIPID
#define S5P_PA_SROMC S5P64X0_PA_SROMC
--
1.7.0.4
^ permalink raw reply related
* [PATCH RESEND V5 1/6] video: s3c-fb: Add S5P64X0 specific s3c_fb_driverdata
From: Ajay Kumar @ 2011-09-19 17:53 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1316454841-20869-1-git-send-email-ajaykumar.rs@samsung.com>
This patch:
-- Adds s3c_fb_driverdata for S5P64X0, which supports 3 windows.
-- Also, register "s5p64x0-fb" type driver_data.
Signed-off-by: Ajay Kumar <ajaykumar.rs@samsung.com>
Acked-by: Jingoo Han <jg1.han@samsung.com>
Acked-by: Kukjin Kim <kgene.kim@samsung.com>
---
drivers/video/s3c-fb.c | 27 +++++++++++++++++++++++++++
1 files changed, 27 insertions(+), 0 deletions(-)
diff --git a/drivers/video/s3c-fb.c b/drivers/video/s3c-fb.c
index 4aecf21..0fda252 100644
--- a/drivers/video/s3c-fb.c
+++ b/drivers/video/s3c-fb.c
@@ -1859,6 +1859,30 @@ static struct s3c_fb_driverdata s3c_fb_data_s3c2443 = {
},
};
+static struct s3c_fb_driverdata s3c_fb_data_s5p64x0 = {
+ .variant = {
+ .nr_windows = 3,
+ .vidtcon = VIDTCON0,
+ .wincon = WINCON(0),
+ .winmap = WINxMAP(0),
+ .keycon = WKEYCON,
+ .osd = VIDOSD_BASE,
+ .osd_stride = 16,
+ .buf_start = VIDW_BUF_START(0),
+ .buf_size = VIDW_BUF_SIZE(0),
+ .buf_end = VIDW_BUF_END(0),
+
+ .palette = {
+ [0] = 0x2400,
+ [1] = 0x2800,
+ [2] = 0x2c00,
+ },
+ },
+ .win[0] = &s3c_fb_data_s5p_wins[0],
+ .win[1] = &s3c_fb_data_s5p_wins[1],
+ .win[2] = &s3c_fb_data_s5p_wins[2],
+};
+
static struct platform_device_id s3c_fb_driver_ids[] = {
{
.name = "s3c-fb",
@@ -1872,6 +1896,9 @@ static struct platform_device_id s3c_fb_driver_ids[] = {
}, {
.name = "s3c2443-fb",
.driver_data = (unsigned long)&s3c_fb_data_s3c2443,
+ }, {
+ .name = "s5p64x0-fb",
+ .driver_data = (unsigned long)&s3c_fb_data_s5p64x0,
},
{},
};
--
1.7.0.4
^ permalink raw reply related
* [PATCH V5 0/6] ARM: S5P64X0: Add Framebuffer support
From: Ajay Kumar @ 2011-09-19 17:53 UTC (permalink / raw)
To: linux-arm-kernel
The patches are created against "for-next" branch of Kukjin Kim's tree at:
git://git.kernel.org/pub/scm/linux/kernel/git/kgene/linux-samsung.git
Changes since V1:
- Remove mach/regs-fb.h, instead use plat/regs-fb.h.
- Add common pdata for FB and LCD in SMDK6440 and SMDK6450.
- Modify names(s5p-->smdk), max_bpp and refresh rate.
- Modify variable name(cfg-->chipid).
- Use __raw_readl, __raw_writel instead of readl and writel.
Changes since V2:
-Change name of the config-COMMON_FB to SMDK64X0_COMMON_FB.
-Change filename common-fb.h to smdk64x0-common-fb.h.
-Change filename common-fb.c to smdk64x0-common-fb.c.
Changes since V3:
-Add FB and LCD plat-data in corresponding machine files
instead of creating common file smdk64x0-common-fb.c.
-Modify name S5P64X0_SETUP_FB to S5P64X0_SETUP_FB_24BPP.
-Modify file name setup-fb.c to setup-fb-24bpp.c.
-Move SPCON settings to machine file.
-Use soc_is_s5p6440()/soc_is_s5p6450() to check CPU ID.
Changes since V4:
-Removed refresh rate from plat data(s3c_fb_pd_win)
-Fixed complation warning:"function declaration isn't a prototype"
for s5p6440_set_lcd_interface() and s5p6450_set_lcd_interface().
These patches have dependency on the patch:
"ARM: S5P64X0: Fix mask value for S5P64X0 CPU IDs",
at http://www.spinics.net/lists/arm-kernel/msg138990.html
o To Kukjin,
[PATCH RESEND V5 1/6] video: s3c-fb: Add S5P64X0 specific s3c_fb_driverdata
[PATCH RESEND V5 2/6] ARM: S5P64X0: Add register base and IRQ for Framebuffer
[PATCH RESEND V5 3/6] ARM: S5P64X0: Set s3c_device_fb name
[PATCH RESEND V5 4/6] ARM: S5P64X0: Add GPIO setup for LCD
[PATCH V5 5/6]ARM: S5P6440: Add LCD-LTE480 and enable Framebuffer support
[PATCH V5 6/6]ARM: S5P6450: Add LCD-LTE480 and enable Framebuffer support
arch/arm/mach-s5p64x0/Kconfig | 10 +++
arch/arm/mach-s5p64x0/Makefile | 1 +
arch/arm/mach-s5p64x0/cpu.c | 3 +
arch/arm/mach-s5p64x0/include/mach/irqs.h | 4 +
arch/arm/mach-s5p64x0/include/mach/map.h | 3 +
arch/arm/mach-s5p64x0/include/mach/regs-gpio.h | 4 +
arch/arm/mach-s5p64x0/mach-smdk6440.c | 74 +++++++++++++++++++++++
arch/arm/mach-s5p64x0/mach-smdk6450.c | 75 ++++++++++++++++++++++++
arch/arm/mach-s5p64x0/setup-fb-24bpp.c | 29 +++++++++
arch/arm/plat-samsung/include/plat/fb.h | 7 ++
drivers/video/s3c-fb.c | 27 +++++++++
11 files changed, 237 insertions(+), 0 deletions(-)
create mode 100644 arch/arm/mach-s5p64x0/setup-fb-24bpp.c
^ permalink raw reply
* [PATCH 5/5] ARM: gic: add OF based initialization
From: Grant Likely @ 2011-09-19 17:44 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20110919133301.GR16381@n2100.arm.linux.org.uk>
On Mon, Sep 19, 2011 at 7:33 AM, Russell King - ARM Linux
<linux@arm.linux.org.uk> wrote:
> On Mon, Sep 19, 2011 at 11:47:18AM +0200, Cousson, Benoit wrote:
>> Since the cpumask is not relevant for the SPI, maybe having two
>> interrupt controllers will be more relevant. Or maybe 3, since there is
>> some SGIs as well.
>
> I don't think anyone uses SGIs outside of the common SMP code.
> Therefore they're handled entirely separately for the root GIC.
>
> (If there's two GICs - some platforms do have two - then the SGIs on
> the non-root GIC are unused.)
...and since SGIs aren't external HW inputs to the GIC, there really
isn't any need to reflect them in the GIC DT binding.
g.
^ permalink raw reply
* [PATCH] ARM: OMAP: Add support for dmtimer v2 ip (Re: [PATCH v15 06/12] OMAP: dmtimer: switch-over to platform device driver)
From: Tony Lindgren @ 2011-09-19 17:43 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <B85A65D85D7EB246BE421B3FB0FBB59302575A0FBC@dbde02.ent.ti.com>
* Mohammed, Afzal <afzal@ti.com> [110918 21:48]:
> Hi Tony,
>
> On Sat, Sep 17, 2011 at 07:05:31, Tony Lindgren wrote:
> >
> > Afzal, care to check if that works for AM335X/TI816X/TI814X?
>
> With following patch over yours, AM335X (the only board with me) boots up fine.
Thanks for catching that, will fold it in with your Signed-off-by.
Regards,
Tony
^ 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