* [PATCH 00/14] Fix issues with ARMv6+v6k+v7 kernels
From: Catalin Marinas @ 2011-02-10 13:12 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20110210130430.GB3652@n2100.arm.linux.org.uk>
On Thu, 2011-02-10 at 13:04 +0000, Russell King - ARM Linux wrote:
> On Wed, Feb 09, 2011 at 10:01:33AM +0000, Catalin Marinas wrote:
> > Could we make the domains usage a run-time feature based on the
> > architecture version? For ARMv7, we need to have the vectors page
> > read-only anyway if the SWP emulation is enabled (and I posted a
> > simple patch in a reply to your email).
> >
> > The issue I see is that ARM11MPCore is reported as v7 though we still
> > use domains on this processor (we could always remove the domains if
> > TLS register is available or use some more precise architecture
> > version identification).
>
> We could also do the below, which I think is more logical - SWP emulation
> requires that CPU domains aren't enabled, so let's make that explicit
> in the Kconfig.
This may work but it is to restrictive IMHO. SWP emulation only requires
that RO user pages are also RO for the kernel. And there is a simple fix
for this:
diff --git a/arch/arm/kernel/traps.c b/arch/arm/kernel/traps.c
index ee57640..6e0b349 100644
--- a/arch/arm/kernel/traps.c
+++ b/arch/arm/kernel/traps.c
@@ -758,17 +758,21 @@ static void __init kuser_get_tls_init(unsigned long vectors)
void __init early_trap_init(void)
{
-#if defined(CONFIG_CPU_USE_DOMAINS)
- unsigned long vectors = CONFIG_VECTORS_BASE;
-#else
- unsigned long vectors = (unsigned long)vectors_page;
-#endif
+ unsigned long vectors;
extern char __stubs_start[], __stubs_end[];
extern char __vectors_start[], __vectors_end[];
extern char __kuser_helper_start[], __kuser_helper_end[];
int kuser_sz = __kuser_helper_end - __kuser_helper_start;
/*
+ * On ARMv7, user RO pages are mapped as kernel RO.
+ */
+ if (cpu_architecture() >= 7)
+ vectors = (unsigned long)vectors_page;
+ else
+ vectors = CONFIG_VECTORS_BASE;
+
+ /*
* Copy the vectors, stubs and kuser helpers (in entry-armv.S)
* into the vector page, mapped at 0xffff0000, and ensure these
* are visible to the instruction stream.
diff --git a/arch/arm/mm/proc-v7.S b/arch/arm/mm/proc-v7.S
index 0c1172b..5f51592 100644
--- a/arch/arm/mm/proc-v7.S
+++ b/arch/arm/mm/proc-v7.S
@@ -146,11 +146,6 @@ ENTRY(cpu_v7_set_pte_ext)
tst r1, #L_PTE_USER
orrne r3, r3, #PTE_EXT_AP1
-#ifdef CONFIG_CPU_USE_DOMAINS
- @ allow kernel read/write access to read-only user pages
- tstne r3, #PTE_EXT_APX
- bicne r3, r3, #PTE_EXT_APX | PTE_EXT_AP0
-#endif
tst r1, #L_PTE_XN
orrne r3, r3, #PTE_EXT_XN
--
Catalin
^ permalink raw reply related
* [PATCH] i.MX51 iomux: Fixes MX51_PAD_UART2_TXD__UART2_TXD declaration
From: Sascha Hauer @ 2011-02-10 13:10 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1297245241-9864-1-git-send-email-julien.boibessot@free.fr>
Hi Julien,
The patch is probably fine. Can you provide a better commit log,
something like 'fixes uart3 on $myboard'?
^ permalink raw reply
* [RFC,PATCH 1/3] Add a common struct clk
From: Richard Zhao @ 2011-02-10 13:08 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20110210104639.GZ27982@pengutronix.de>
On Thu, Feb 10, 2011 at 11:46:39AM +0100, Uwe Kleine-K?nig wrote:
> Hello,
>
> On Thu, Feb 10, 2011 at 06:03:19PM +0800, Richard Zhao wrote:
> > On Thu, Feb 10, 2011 at 09:21:14AM +1300, Ryan Mallon wrote:
> > > On 02/09/2011 07:41 PM, Jeremy Kerr wrote:
> > >
> > > Hi Jeremy,
> > >
> > > Couple more comments below.
> > >
> > > ~Ryan
> > >
> > [...]
> > > > +int clk_enable(struct clk *clk)
> > > > +{
> > > > + unsigned long flags;
> > > > + int ret = 0;
> > > > +
> > > > + spin_lock_irqsave(&clk->enable_lock, flags);
> > >
> > > WARN_ON(clk->prepare_count == 0); ?
> > >
> > > > + if (clk->enable_count == 0 && clk->ops->enable)
> > > > + ret = clk->ops->enable(clk);
> > >
> > > Does it make sense to have a clock with no enable function which still
> > > returns success from clk_enable? Do we have any platforms which have
> > > NULL clk_enable functions?
> > >
> > > I think that for enable/disable at least we should require platforms to
> > > provide functions and oops if they have failed to do so. In the rare
> > > case that a platform doesn't need to do anything for enable/disable they
> > > can just supply empty functions.
> > It's possible to be NULL. So are set_rate/get_rate.
> > Ideally, if it's NULL:
> > prepare/unprepare: only call parent's prepare/unprepare
> > enable/disable: only call parent's enable/disable
> > set_rate: fail
> > get_rate: reture parent's get_rate
> > set_parent: fail
> > get_parent: fail
> I wouldn't hard-code the parents into the generic functions. But I
> suggest to provide generic callbacks to do this, e.g.
Why? what restriction will it cause to add parent in clk?
Two benifits at least I can see:
1. null ops handle, as I said above.
2. export clock tree to user level for debug. It's very helpfull.
Thanks
Richard
>
> clk_get_rate_from_parent(struct clk *c)
> {
> struct clk *parent = clk_get_parent(c);
>
> return clk_get_rate(parent);
> }
>
> Best regards
> Uwe
>
> --
> Pengutronix e.K. | Uwe Kleine-K?nig |
> Industrial Linux Solutions | http://www.pengutronix.de/ |
>
> _______________________________________________
> 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 00/14] Fix issues with ARMv6+v6k+v7 kernels
From: Russell King - ARM Linux @ 2011-02-10 13:04 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <AANLkTimGa-Y6ddHknGe9Gar7+mWPuA_T2+6VL6ecfgxD@mail.gmail.com>
On Wed, Feb 09, 2011 at 10:01:33AM +0000, Catalin Marinas wrote:
> Could we make the domains usage a run-time feature based on the
> architecture version? For ARMv7, we need to have the vectors page
> read-only anyway if the SWP emulation is enabled (and I posted a
> simple patch in a reply to your email).
>
> The issue I see is that ARM11MPCore is reported as v7 though we still
> use domains on this processor (we could always remove the domains if
> TLS register is available or use some more precise architecture
> version identification).
We could also do the below, which I think is more logical - SWP emulation
requires that CPU domains aren't enabled, so let's make that explicit
in the Kconfig.
arch/arm/mm/Kconfig | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mm/Kconfig b/arch/arm/mm/Kconfig
index c9d2d56..7ea482b 100644
--- a/arch/arm/mm/Kconfig
+++ b/arch/arm/mm/Kconfig
@@ -644,7 +644,7 @@ config ARM_THUMBEE
config SWP_EMULATE
bool "Emulate SWP/SWPB instructions"
- depends on CPU_V7 && !CPU_V6
+ depends on !CPU_USE_DOMAINS && CPU_V7 && !CPU_V6
select HAVE_PROC_CPU if PROC_FS
default y if SMP
help
^ permalink raw reply related
* [PATCH] mx3fb: Fix parameter to sdc_init_panel
From: Alexander Stein @ 2011-02-10 13:01 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <Pine.LNX.4.64.1102101337310.18510@axis700.grange>
On Thursday 10 February 2011, 13:48:23 Guennadi Liakhovetski wrote:
> > Ok, i will just write about HSYNC the problem about VSYNC is similar.
> > Let's assume we have a display with the following properties.
> > left_margin = 38
> > right_margin = 32
> > hsync_len = 20
> > width = 800
> >
> > Without the patch we get the following arguments on sdc_init_panel
> > width = 800
> > h_start_width = 38 (left_margin)
> > h_sync_width = 20 (hsync_len)
> > h_end_width = 52 = 32 + 20 (right_margin + hsync_len)
> >
> > So we will write into SDC_HOR_CONF:
> >
> > reg = ((h_sync_width - 1) << 26) |
> >
> > ((width + h_start_width + h_end_width - 1) << 16);
> >
> > reg = ((20 - 1) << 26) |
> >
> > ((800 + 38 + 52 - 1) << 16);
> >
> > So the value SCREEN_WIDTH get written is
> > width + left_margin + right_margin + hsync_len
> >
> > which is IMO wrong. The description in the reference manual states:
> > > Screen width minus 1. Specifies the number of pixel clock periods
> > > between the last HSYNC and the new HSYNC.
> >
> > It should just be: width + left_margin + right_margin
> > I fell accross it, as I have a display with 800 px width and rather big
> > left_margin. The sum got greater than 1023 which is what SCREEN_WIDTH can
> > hold at maximum.
> >
> > I don't know which display you used, but I guess your right_margin (and
> > lower_margin) needs to be adjusted.
>
> Ok, agree. But then you need to adjust all current users and have them
> tested... Otherwise, of course, you can just adjust your platform panel
> data to work with the current calculations, even though in principle your
> patch seems to be doing the right thing (tm), according to the manual. But
> if applied as is without fixing all the users, it can very well break
> them...
Ok, I've just seen there are some model defines in mx3fb.c which would also be
affected.
I'll try to find all mx3fb users and fix their videomodes and repost a new
patch.
Alexander
^ permalink raw reply
* [PATCH] ARM: Avoid discarding sections that might have SMP_ON_UP fixups
From: Russell King - ARM Linux @ 2011-02-10 12:56 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20110209142211.GA11460@n2100.arm.linux.org.uk>
On Wed, Feb 09, 2011 at 02:22:11PM +0000, Russell King - ARM Linux wrote:
> On Wed, Jan 26, 2011 at 05:25:35PM +0000, Dave P. Martin wrote:
> > SMP_ON_UP fixups lead to vmlinux link errors if those sections are
> > discarded at link-time. In particular this may happen for built-in
> > __exit stuff.
> >
> > This patch modifies the vmlinux linker script to reduce the amount
> > of discarded sections, and tries to make sure that __exit sections
> > are kept in.
> >
> > This is a hack and probably wrong! Further discussion is needed.
>
> Can you send the configuration which you see this problem with?
> I've tried to build a kernel which inlines the spinlocks, but I find
> that's not possible, so I'm doubting whether any fix is required for
> mainline.
Any news on this, or can it not be reproduced?
^ permalink raw reply
* [PATCH] mx3fb: Fix parameter to sdc_init_panel
From: Guennadi Liakhovetski @ 2011-02-10 12:48 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <201102101227.26949.alexander.stein@systec-electronic.com>
On Thu, 10 Feb 2011, Alexander Stein wrote:
> On Thursday 10 February 2011, 12:00:09 Guennadi Liakhovetski wrote:
> > On Thu, 10 Feb 2011, Guennadi Liakhovetski wrote:
> > > On Thu, 10 Feb 2011, Alexander Stein wrote:
> > > > h_end_width and v_end_width should only contain the front porches.
> > > > Otherwise, SCREEN_WIDTH (pixel clocks between HSYNC) in SDC_HOR_CONF
> > > > and SCREEN_HEIGHT (rows between VSYNC) in SDC_VER_CONF get false
> > > > values.
> > >
> > > Hm, no, this corrupts image on my pcm990 test-board. What makes you think
> > > this patch is needed? How do you see, that current values are "false?"
(I certainly meant the pcm037 module)
> Ok, i will just write about HSYNC the problem about VSYNC is similar.
> Let's assume we have a display with the following properties.
> left_margin = 38
> right_margin = 32
> hsync_len = 20
> width = 800
>
> Without the patch we get the following arguments on sdc_init_panel
> width = 800
> h_start_width = 38 (left_margin)
> h_sync_width = 20 (hsync_len)
> h_end_width = 52 = 32 + 20 (right_margin + hsync_len)
>
> So we will write into SDC_HOR_CONF:
>
> reg = ((h_sync_width - 1) << 26) |
> ((width + h_start_width + h_end_width - 1) << 16);
> reg = ((20 - 1) << 26) |
> ((800 + 38 + 52 - 1) << 16);
>
> So the value SCREEN_WIDTH get written is
> width + left_margin + right_margin + hsync_len
> which is IMO wrong. The description in the reference manual states:
> > Screen width minus 1. Specifies the number of pixel clock periods between
> > the last HSYNC and the new HSYNC.
> It should just be: width + left_margin + right_margin
> I fell accross it, as I have a display with 800 px width and rather big
> left_margin. The sum got greater than 1023 which is what SCREEN_WIDTH can hold
> at maximum.
>
> I don't know which display you used, but I guess your right_margin (and
> lower_margin) needs to be adjusted.
Ok, agree. But then you need to adjust all current users and have them
tested... Otherwise, of course, you can just adjust your platform panel
data to work with the current calculations, even though in principle your
patch seems to be doing the right thing (tm), according to the manual. But
if applied as is without fixing all the users, it can very well break
them...
Thanks
Guennadi
> > > > Signed-off-by: Alexander Stein <alexander.stein@systec-electronic.com>
> > > > ---
> > > >
> > > > drivers/video/mx3fb.c | 7 +++----
> > > > 1 files changed, 3 insertions(+), 4 deletions(-)
> > > >
> > > > diff --git a/drivers/video/mx3fb.c b/drivers/video/mx3fb.c
> > > > index ef71e56..9040833 100644
> > > > --- a/drivers/video/mx3fb.c
> > > > +++ b/drivers/video/mx3fb.c
> > > > @@ -881,12 +881,11 @@ static int __set_par(struct fb_info *fbi, bool
> > > > lock)
> >
> > Also just occurred to me - your offset of 881 lines is 100 lines below my
> > offset for the same code - against what tree is this patch, or do you have
> > some local changes there? Can it be, that that's the reason for your
> > problem?
>
> Oh, I didn't rebase this patch on current linux git. This patch is on my
> 2.6.34 kernel. Anyway, since 2.6.34 there are no related patches on mx3fb.c.
>
> Alexander
>
---
Guennadi Liakhovetski, Ph.D.
Freelance Open-Source Software Developer
http://www.open-technology.de/
^ permalink raw reply
* [RFC,PATCH 1/3] Add a common struct clk
From: Richard Zhao @ 2011-02-10 12:45 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <4D53B9AC.8020609@bluewatersys.com>
On Thu, Feb 10, 2011 at 11:10:52PM +1300, Ryan Mallon wrote:
> On 10/02/11 23:03, Richard Zhao wrote:
> >On Thu, Feb 10, 2011 at 09:21:14AM +1300, Ryan Mallon wrote:
> >>On 02/09/2011 07:41 PM, Jeremy Kerr wrote:
> >>
> >>Hi Jeremy,
> >>
> >>Couple more comments below.
> >>
> >>~Ryan
> >>
> >[...]
> >>>+int clk_enable(struct clk *clk)
> >>>+{
> >>>+ unsigned long flags;
> >>>+ int ret = 0;
> >>>+
> >>>+ spin_lock_irqsave(&clk->enable_lock, flags);
> >> WARN_ON(clk->prepare_count == 0); ?
> >>
> >>>+ if (clk->enable_count == 0&& clk->ops->enable)
> >>>+ ret = clk->ops->enable(clk);
> >>Does it make sense to have a clock with no enable function which still
> >>returns success from clk_enable? Do we have any platforms which have
> >>NULL clk_enable functions?
> >>
> >>I think that for enable/disable at least we should require platforms to
> >>provide functions and oops if they have failed to do so. In the rare
> >>case that a platform doesn't need to do anything for enable/disable they
> >>can just supply empty functions.
> >It's possible to be NULL. So are set_rate/get_rate.
> >Ideally, if it's NULL:
> >prepare/unprepare: only call parent's prepare/unprepare
> >enable/disable: only call parent's enable/disable
>
> No, the whole point of the generic framework is that _all_ clock
> users must call prepare/enable and disable/unprepare. Drivers, etc
> should not rely on underlying knowledge of a platform. This is why,
> for instance, clk_enable will warn if prepare count is zero.
>
> However, I can see that a clock may be fully enabled by its prepare
> function and so the enable function is a no-op. User must still call
> both prepare and enable though. Perhaps this is what you meant?
I mean prepare/unprepare, enable/disable and get_rate ops null can be handled
in the common clock code. But it needs parent clock pointer.
Thanks
Richard
>
> ~Ryan
>
> _______________________________________________
> 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 1/2] video: Add i.MX23/28 framebuffer driver
From: Li Frank-B20596 @ 2011-02-10 12:32 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20110210115109.GR9041@pengutronix.de>
> On Thu, Feb 10, 2011 at 11:47:25AM +0100, Wolfram Sang wrote:
> > > But I would prefer:
> > > #define SET 4
> > > #define CLEAR 8
> > > [...]
> > > writel(CTRL_DOTCLK_MODE, host->base + CTRL + SET)
>
> For this we already have __mxs_setl.
>
> >
> > NACK.
> >
> > This will indeed not be caught by the compiler.
> >
> > And while I like the shorter macros better as well, an MXSFB_ prefix
> > should be added IMO. Macros like CTRL and TIMING are not too well
> > protected.
>
> +1 for a prefix, be it MXSFB_ or LCDIF_, will change this.
>
> Otherwise can we please stop about arguing about register defines? It's
> too much a matter of taste and there is no perfect way to solve this.
>
> Sascha
>
Guo Shawn mmc driver's patch is good example to use mx23/mx28 register macro.
Best regards
Frank Li
^ permalink raw reply
* [PATCH] ARM: gic: use handle_fasteoi_irq for SPIs
From: Will Deacon @ 2011-02-10 12:29 UTC (permalink / raw)
To: linux-arm-kernel
Currently, the gic uses handle_level_irq for handling SPIs (Shared
Peripheral Interrupts), requiring active interrupts to be masked at
the distributor level during IRQ handling.
On a virtualised system, only the CPU interfaces are virtualised in
hardware. Accesses to the distributor must be trapped by the hypervisor,
adding latency to the critical interrupt path in Linux.
This patch modifies the GIC code to use handle_fasteoi_irq for handling
interrupts, which only requires us to signal EOI to the CPU interface
when handling is complete. Cascaded IRQ handling is also updated so that
EOI is signalled after handling.
Note that commit 846afbd1 ("GIC: Dont disable INT in ack callback") broke
cascading interrupts by forgetting to add IRQ masking. This is no longer
an issue because the unmask call is now unnecessary.
Tested on Versatile Express and Realview EB (1176 w/ cascaded GICs).
Acked-by: Catalin Marinas <catalin.marinas@arm.com>
Signed-off-by: Will Deacon <will.deacon@arm.com>
---
arch/arm/common/gic.c | 23 +++++++++--------------
1 files changed, 9 insertions(+), 14 deletions(-)
diff --git a/arch/arm/common/gic.c b/arch/arm/common/gic.c
index 2243772..9def30b 100644
--- a/arch/arm/common/gic.c
+++ b/arch/arm/common/gic.c
@@ -71,13 +71,6 @@ static inline unsigned int gic_irq(struct irq_data *d)
/*
* Routines to acknowledge, disable and enable interrupts
*/
-static void gic_ack_irq(struct irq_data *d)
-{
- spin_lock(&irq_controller_lock);
- writel(gic_irq(d), gic_cpu_base(d) + GIC_CPU_EOI);
- spin_unlock(&irq_controller_lock);
-}
-
static void gic_mask_irq(struct irq_data *d)
{
u32 mask = 1 << (d->irq % 32);
@@ -96,6 +89,11 @@ static void gic_unmask_irq(struct irq_data *d)
spin_unlock(&irq_controller_lock);
}
+static void gic_eoi_irq(struct irq_data *d)
+{
+ writel(gic_irq(d), gic_cpu_base(d) + GIC_CPU_EOI);
+}
+
static int gic_set_type(struct irq_data *d, unsigned int type)
{
void __iomem *base = gic_dist_base(d);
@@ -174,9 +172,6 @@ static void gic_handle_cascade_irq(unsigned int irq, struct irq_desc *desc)
unsigned int cascade_irq, gic_irq;
unsigned long status;
- /* primary controller ack'ing */
- chip->irq_ack(&desc->irq_data);
-
spin_lock(&irq_controller_lock);
status = readl(chip_data->cpu_base + GIC_CPU_INTACK);
spin_unlock(&irq_controller_lock);
@@ -192,15 +187,15 @@ static void gic_handle_cascade_irq(unsigned int irq, struct irq_desc *desc)
generic_handle_irq(cascade_irq);
out:
- /* primary controller unmasking */
- chip->irq_unmask(&desc->irq_data);
+ /* primary controller EOI */
+ chip->irq_eoi(&desc->irq_data);
}
static struct irq_chip gic_chip = {
.name = "GIC",
- .irq_ack = gic_ack_irq,
.irq_mask = gic_mask_irq,
.irq_unmask = gic_unmask_irq,
+ .irq_eoi = gic_eoi_irq,
.irq_set_type = gic_set_type,
#ifdef CONFIG_SMP
.irq_set_affinity = gic_set_cpu,
@@ -275,7 +270,7 @@ static void __init gic_dist_init(struct gic_chip_data *gic,
for (i = irq_start; i < irq_limit; i++) {
set_irq_chip(i, &gic_chip);
set_irq_chip_data(i, gic);
- set_irq_handler(i, handle_level_irq);
+ set_irq_handler(i, handle_fasteoi_irq);
set_irq_flags(i, IRQF_VALID | IRQF_PROBE);
}
--
1.7.0.4
^ permalink raw reply related
* [PATCH 1/2] video: Add i.MX23/28 framebuffer driver
From: Li Frank-B20596 @ 2011-02-10 12:23 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <201102101212.17370.jbe@pengutronix.de>
>
> What about?
> > Reg &= ~VDCTRL4_SET_DOTCLK_DLY(0x7);
> Or?
> > Reg &= ~VDCTRL4_SET_DOTCLK_DLY_MASK;
> Okay, the even get longer and longer.
If use 0x7, you have to take care bit width.
If use VDCTRL4_SET_DOTCLK_DLY_MASK, I think BF_ and BM_ is better.
> > Reg |= VDCTRL4_SET_DOTCLK_DLY(value)
> > Writel(reg, offset+VDCTRL4)
> >
> > Compared with our macro policy.
> >
> > Reg = readl(offset+HW_VDCTRL4);
> > Reg &=~ BM_VDCTRL4_SET_DOTCLK_DLY;
> > Reg |= BF_VDCTRL4_SET_DOTCLK_DLY(value)
> > Writel(reg, offset+HW_VDCTRL4)
>
> Anywhere else such naming policy in the kernel? I have to deal with all
> kind
> of CPUs, not only i.MX23/28.
This driver is for mx23/mx28.
I have not found such policy in the kernel, otherwise I have generated that at beginning.
It is better if all of mx23/mx28 driver follow the same role.
^ permalink raw reply
* [PATCH v2] ARM: ptrace: remove single-step emulation code
From: Will Deacon @ 2011-02-10 11:59 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <alpine.LFD.2.00.1102091427200.14920@xanadu.home>
> > PTRACE_SINGLESTEP is a ptrace request designed to offer single-stepping
> > support to userspace when the underlying architecture has hardware
> > support for this operation.
> >
> > On ARM, we set arch_has_single_step() to 1 and attempt to emulate hardware
> > single-stepping by disassembling the current instruction to determine the
> > next pc and placing a software breakpoint on that location.
> >
> > Unfortunately this has the following problems:
> >
> > 1.) Only a subset of ARMv7 instructions are supported
> > 2.) Thumb-2 is unsupported
> > 3.) The code is not SMP safe
> >
> > We could try to fix this code, but it turns out that because of the above
> > issues it is rarely used in practice. GDB, for example, uses PTRACE_POKETEXT
> > and PTRACE_PEEKTEXT to manage breakpoints itself and does not require any
> > kernel assistance.
> >
> > This patch removes the single-step emulation code from ptrace meaning that
> > the PTRACE_SINGLESTEP request will return -EIO on ARM. Portable code must
> > check the return value from a ptrace call and handle the failure gracefully.
> >
> > Signed-off-by: Will Deacon <will.deacon@arm.com>
>
> Acked-by: Nicolas Pitre <nicolas.pitre@linaro.org>
Thanks Nicolas. I'll leave this over the weekend to see if it
attracts further comment before putting it into the patch system.
Cheers,
Will
^ permalink raw reply
* [PATCH 1/2] video: Add i.MX23/28 framebuffer driver
From: Sascha Hauer @ 2011-02-10 11:51 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20110210104725.GC2206@pengutronix.de>
On Thu, Feb 10, 2011 at 11:47:25AM +0100, Wolfram Sang wrote:
> > But I would prefer:
> > #define SET 4
> > #define CLEAR 8
> > [...]
> > writel(CTRL_DOTCLK_MODE, host->base + CTRL + SET)
For this we already have __mxs_setl.
>
> NACK.
>
> This will indeed not be caught by the compiler.
>
> And while I like the shorter macros better as well, an MXSFB_ prefix
> should be added IMO. Macros like CTRL and TIMING are not too well
> protected.
+1 for a prefix, be it MXSFB_ or LCDIF_, will change this.
Otherwise can we please stop about arguing about register defines? It's
too much a matter of taste and there is no perfect way to solve this.
Sascha
--
Pengutronix e.K. | |
Industrial Linux Solutions | http://www.pengutronix.de/ |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
^ permalink raw reply
* [PATCH] ARM: hw_breakpoint: fix ptrace breakpoint advertising on unsupported arch
From: Will Deacon @ 2011-02-10 11:49 UTC (permalink / raw)
To: linux-arm-kernel
The ptrace debug information register was advertising breakpoint and
watchpoint resources for unsupported debug architectures. This meant
that setting breakpoints on these architectures would appear to succeed,
although they would never fire in reality.
This patch fixes the breakpoint slot probing so that it returns 0 when
running on an unsupported debug architecture.
Reported-by: Ulrich Weigand <ulrich.weigand@de.ibm.com>
Signed-off-by: Will Deacon <will.deacon@arm.com>
---
arch/arm/kernel/hw_breakpoint.c | 18 +++++++++++++-----
1 files changed, 13 insertions(+), 5 deletions(-)
diff --git a/arch/arm/kernel/hw_breakpoint.c b/arch/arm/kernel/hw_breakpoint.c
index ab02d8a..d600bd3 100644
--- a/arch/arm/kernel/hw_breakpoint.c
+++ b/arch/arm/kernel/hw_breakpoint.c
@@ -137,11 +137,10 @@ static u8 get_debug_arch(void)
u32 didr;
/* Do we implement the extended CPUID interface? */
- if (((read_cpuid_id() >> 16) & 0xf) != 0xf) {
- pr_warning("CPUID feature registers not supported. "
- "Assuming v6 debug is present.\n");
+ if (WARN_ONCE((((read_cpuid_id() >> 16) & 0xf) != 0xf),
+ "CPUID feature registers not supported. "
+ "Assuming v6 debug is present.\n"))
return ARM_DEBUG_ARCH_V6;
- }
ARM_DBG_READ(c0, 0, didr);
return (didr >> 16) & 0xf;
@@ -152,6 +151,12 @@ u8 arch_get_debug_arch(void)
return debug_arch;
}
+static int debug_arch_supported(void)
+{
+ u8 arch = get_debug_arch();
+ return arch >= ARM_DEBUG_ARCH_V6 && arch <= ARM_DEBUG_ARCH_V7_ECP14;
+}
+
/* Determine number of BRP register available. */
static int get_num_brp_resources(void)
{
@@ -268,6 +273,9 @@ out:
int hw_breakpoint_slots(int type)
{
+ if (!debug_arch_supported())
+ return 0;
+
/*
* We can be called early, so don't rely on
* our static variables being initialised.
@@ -882,7 +890,7 @@ static int __init arch_hw_breakpoint_init(void)
debug_arch = get_debug_arch();
- if (debug_arch > ARM_DEBUG_ARCH_V7_ECP14) {
+ if (!debug_arch_supported()) {
pr_info("debug architecture 0x%x unsupported.\n", debug_arch);
return 0;
}
--
1.7.0.4
^ permalink raw reply related
* [PATCH] mx3fb: Fix parameter to sdc_init_panel
From: Alexander Stein @ 2011-02-10 11:27 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <Pine.LNX.4.64.1102101158510.17898@axis700.grange>
On Thursday 10 February 2011, 12:00:09 Guennadi Liakhovetski wrote:
> On Thu, 10 Feb 2011, Guennadi Liakhovetski wrote:
> > On Thu, 10 Feb 2011, Alexander Stein wrote:
> > > h_end_width and v_end_width should only contain the front porches.
> > > Otherwise, SCREEN_WIDTH (pixel clocks between HSYNC) in SDC_HOR_CONF
> > > and SCREEN_HEIGHT (rows between VSYNC) in SDC_VER_CONF get false
> > > values.
> >
> > Hm, no, this corrupts image on my pcm990 test-board. What makes you think
> > this patch is needed? How do you see, that current values are "false?"
Ok, i will just write about HSYNC the problem about VSYNC is similar.
Let's assume we have a display with the following properties.
left_margin = 38
right_margin = 32
hsync_len = 20
width = 800
Without the patch we get the following arguments on sdc_init_panel
width = 800
h_start_width = 38 (left_margin)
h_sync_width = 20 (hsync_len)
h_end_width = 52 = 32 + 20 (right_margin + hsync_len)
So we will write into SDC_HOR_CONF:
reg = ((h_sync_width - 1) << 26) |
((width + h_start_width + h_end_width - 1) << 16);
reg = ((20 - 1) << 26) |
((800 + 38 + 52 - 1) << 16);
So the value SCREEN_WIDTH get written is
width + left_margin + right_margin + hsync_len
which is IMO wrong. The description in the reference manual states:
> Screen width minus 1. Specifies the number of pixel clock periods between
> the last HSYNC and the new HSYNC.
It should just be: width + left_margin + right_margin
I fell accross it, as I have a display with 800 px width and rather big
left_margin. The sum got greater than 1023 which is what SCREEN_WIDTH can hold
at maximum.
I don't know which display you used, but I guess your right_margin (and
lower_margin) needs to be adjusted.
> > > Signed-off-by: Alexander Stein <alexander.stein@systec-electronic.com>
> > > ---
> > >
> > > drivers/video/mx3fb.c | 7 +++----
> > > 1 files changed, 3 insertions(+), 4 deletions(-)
> > >
> > > diff --git a/drivers/video/mx3fb.c b/drivers/video/mx3fb.c
> > > index ef71e56..9040833 100644
> > > --- a/drivers/video/mx3fb.c
> > > +++ b/drivers/video/mx3fb.c
> > > @@ -881,12 +881,11 @@ static int __set_par(struct fb_info *fbi, bool
> > > lock)
>
> Also just occurred to me - your offset of 881 lines is 100 lines below my
> offset for the same code - against what tree is this patch, or do you have
> some local changes there? Can it be, that that's the reason for your
> problem?
Oh, I didn't rebase this patch on current linux git. This patch is on my
2.6.34 kernel. Anyway, since 2.6.34 there are no related patches on mx3fb.c.
Alexander
^ permalink raw reply
* [PATCH 1/2] video: Add i.MX23/28 framebuffer driver
From: Juergen Beisert @ 2011-02-10 11:12 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <09EC74FE2C9E8444BF2FF67BD36E1D69167988@039-SN1MPN1-003.039d.mgd.msft.net>
Li Frank-B20596 wrote:
> > This kind of macro encryption _may_ help when you are coding the driver
> > the
> > first time. But after reading and reading it again (while testing and
> > debugging) all these prefixes and suffixes do not add any valuable
> > information. They only fill up your lines, enlarges your source code and
> > make
> > you blind for the real bug...
> >
> > Everyone who wants to see how source code looks that uses these longs
> > macros I
> > can recommend reading the so called 'bootlets' source code. :-))
>
> The complex of bootlets is not long macro, but the work around to make sure
> Chip PMU work safely. If there are not such macro, power_prep will become
> more difficult to understand.
Its your opinion...
> > > Developer needn't look up register header file when coding, just
> >
> > That's why I add these macros into the source file instead into a header
> > file.
> >
> > > write down Register name or bit name according to mx23/mx28 spec.
> >
> > And sometimes the spec is incomplete or just wrong and so on. Independent
> > of any macro naming policy.
>
> Not at all. Mx23/mx28 can keep spec, header file and RTL consistent just
> because using one source and multiple output. During Freescale mx28 BSP
> develop, never happen bit and register definition error.
>
> > > If you still think it is too long, I suggest keep HW_ and BM_ prefix to
> > > distinguish Which one is register name, which one is bit mask.
> >
> > The used macro in the address part of the writel() must be an offset,
> > while
> > the macro used in the value part must be a bit definition. Anything else
> > is
> > redundant.
>
> If name is too short, there are possible to cause name pollution.
> BM_, BP_, BF_ have their implication.
If you collect everything in header files: Yes. If you keep the macros where
they are used, IMHO: No.
> VDCTRL4_SET_DOTCLK_DLY(x), according to our macro policy, it should be
> BF_VDCTRL4_SET_DOTCLK_DLY(x).
>
> Generally, you need
> Reg = readl(offset+VDCTRL4);
> Reg &=~ ((0x7)<<29);
What about?
> Reg &= ~VDCTRL4_SET_DOTCLK_DLY(0x7);
Or?
> Reg &= ~VDCTRL4_SET_DOTCLK_DLY_MASK;
Okay, the even get longer and longer.
> Reg |= VDCTRL4_SET_DOTCLK_DLY(value)
> Writel(reg, offset+VDCTRL4)
>
> Compared with our macro policy.
>
> Reg = readl(offset+HW_VDCTRL4);
> Reg &=~ BM_VDCTRL4_SET_DOTCLK_DLY;
> Reg |= BF_VDCTRL4_SET_DOTCLK_DLY(value)
> Writel(reg, offset+HW_VDCTRL4)
Anywhere else such naming policy in the kernel? I have to deal with all kind
of CPUs, not only i.MX23/28.
Regards,
Juergen
--
Pengutronix e.K. | Juergen Beisert |
Linux Solutions for Science and Industry | Phone: +49-8766-939 228 |
Vertretung Sued/Muenchen, Germany | Fax: +49-5121-206917-5555 |
Amtsgericht Hildesheim, HRA 2686 | http://www.pengutronix.de/ |
^ permalink raw reply
* [PXA] A question about PXA310 cpufreq for 806Mhz
From: Igor Grinberg @ 2011-02-10 11:03 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1297329771.21848.6.camel@mola>
Hi,
On 02/10/11 11:22, Axel Lin wrote:
> hi,
>
> I have a device equipped with 806Mhz PXA310 cpu.
> After bootup, the system shows it is running with 624Mhz.
>
> # cat /sys/devices/system/cpu/cpu0/cpufreq/cpuinfo_max_freq
> 624000
> # cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_max_freq
> 624000
>
> # cat /proc/cpuinfo
> Processor : XScale-V3 based processor rev 2 (v5l)
> BogoMIPS : 623.00
> Features : swp half thumb fastmult edsp iwmmxt
> CPU implementer : 0x69
> CPU architecture: 5TE
> CPU variant : 0x0
> CPU part : 0x689
> CPU revision : 2
>
> Hardware : Getac PS236 Handheld Platform
> Revision : 0000
> Serial : 0000000000000000
>
> I fix it by below patch and it looks ok on my device.
> I'm not sure if this is a proper way to fix it, I appreciate to see your comments.
>
> It is strange that I cannot find 806Mhz PXA31x CPU
> in the datasheet Section 6.1 PXA3XX Processor Differences.
I think the reason for this is that it is not true for all PXA31x SoCs.
PXA3xx Specification Update document states, that the 806MHz
operating points were added for PXA31x processors A2 stepping.
This means that it is not true at least for A1 and A0 stepping and
Also, there is nothing stated about the B0 and B1 stepping.
> But in Section 6.7, Table 55: PXA31x Core PLL, Turbo and Run Mode Output Frequencies,
> I do see 806Mhz support on the table.
But no details regarding stepping... Marvell's mess...
> diff --git a/arch/arm/mach-pxa/cpufreq-pxa3xx.c b/arch/arm/mach-pxa/cpufreq-pxa3xx.c
> index 88fbec0..abf7d7a 100644
> --- a/arch/arm/mach-pxa/cpufreq-pxa3xx.c
> +++ b/arch/arm/mach-pxa/cpufreq-pxa3xx.c
> @@ -210,15 +210,14 @@ static int pxa3xx_cpufreq_init(struct cpufreq_policy *policy)
>
> /* set default policy and cpuinfo */
> policy->cpuinfo.min_freq = 104000;
> - policy->cpuinfo.max_freq = (cpu_is_pxa320()) ? 806000 : 624000;
> + policy->cpuinfo.max_freq = (cpu_is_pxa300()) ? 624000 : 806000;
> policy->cpuinfo.transition_latency = 1000; /* FIXME: 1 ms, assumed */
> policy->max = pxa3xx_get_clk_frequency_khz(0);
> policy->cur = policy->min = policy->max;
>
> - if (cpu_is_pxa300() || cpu_is_pxa310())
> + if (cpu_is_pxa300())
> ret = setup_freqs_table(policy, ARRAY_AND_SIZE(pxa300_freqs));
> -
> - if (cpu_is_pxa320())
> + else if (cpu_is_pxa310() || cpu_is_pxa320())
> ret = setup_freqs_table(policy, ARRAY_AND_SIZE(pxa320_freqs));
>
> if (ret) {
>
It is obviously, not a good patch in light of what I've said above.
May be we should build the pxa3xx_freqs table dynamically according
to cpu type and stepping? And set the policy->cpuinfo on the way?
--
Regards,
Igor.
^ permalink raw reply
* [PATCH] mx3fb: Fix parameter to sdc_init_panel
From: Guennadi Liakhovetski @ 2011-02-10 11:00 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <Pine.LNX.4.64.1102101136320.15087@axis700.grange>
On Thu, 10 Feb 2011, Guennadi Liakhovetski wrote:
> On Thu, 10 Feb 2011, Alexander Stein wrote:
>
> > h_end_width and v_end_width should only contain the front porches.
> > Otherwise, SCREEN_WIDTH (pixel clocks between HSYNC) in SDC_HOR_CONF
> > and SCREEN_HEIGHT (rows between VSYNC) in SDC_VER_CONF get false values.
>
> Hm, no, this corrupts image on my pcm990 test-board. What makes you think
> this patch is needed? How do you see, that current values are "false?"
>
> Thanks
> Guennadi
>
> >
> > Signed-off-by: Alexander Stein <alexander.stein@systec-electronic.com>
> > ---
> > drivers/video/mx3fb.c | 7 +++----
> > 1 files changed, 3 insertions(+), 4 deletions(-)
> >
> > diff --git a/drivers/video/mx3fb.c b/drivers/video/mx3fb.c
> > index ef71e56..9040833 100644
> > --- a/drivers/video/mx3fb.c
> > +++ b/drivers/video/mx3fb.c
> > @@ -881,12 +881,11 @@ static int __set_par(struct fb_info *fbi, bool lock)
Also just occurred to me - your offset of 881 lines is 100 lines below my
offset for the same code - against what tree is this patch, or do you have
some local changes there? Can it be, that that's the reason for your
problem?
Thanks
Guennadi
> > IPU_PIX_FMT_BGR666 : IPU_PIX_FMT_RGB666,
> > fbi->var.left_margin,
> > fbi->var.hsync_len,
> > - fbi->var.right_margin +
> > - fbi->var.hsync_len,
> > + fbi->var.right_margin,
> > fbi->var.upper_margin,
> > fbi->var.vsync_len,
> > - fbi->var.lower_margin +
> > - fbi->var.vsync_len, sig_cfg) != 0) {
> > + fbi->var.lower_margin,
> > + sig_cfg) != 0) {
> > dev_err(fbi->device,
> > "mx3fb: Error initializing panel.\n");
> > return -EINVAL;
> > --
> > 1.7.3.4
> >
> >
>
> ---
> Guennadi Liakhovetski, Ph.D.
> Freelance Open-Source Software Developer
> http://www.open-technology.de/
>
---
Guennadi Liakhovetski, Ph.D.
Freelance Open-Source Software Developer
http://www.open-technology.de/
^ permalink raw reply
* [PATCH 1/2] video: Add i.MX23/28 framebuffer driver
From: Wolfram Sang @ 2011-02-10 10:47 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <201102101046.33994.jbe@pengutronix.de>
> But I would prefer:
> #define SET 4
> #define CLEAR 8
> [...]
> writel(CTRL_DOTCLK_MODE, host->base + CTRL + SET)
NACK.
This will indeed not be caught by the compiler.
And while I like the shorter macros better as well, an MXSFB_ prefix
should be added IMO. Macros like CTRL and TIMING are not too well
protected.
Regards,
Wolfram
--
Pengutronix e.K. | Wolfram Sang |
Industrial Linux Solutions | http://www.pengutronix.de/ |
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20110210/d36ddd33/attachment.sig>
^ permalink raw reply
* [RFC,PATCH 1/3] Add a common struct clk
From: Uwe Kleine-König @ 2011-02-10 10:46 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20110210100319.GB24710@b20223-02.ap.freescale.net>
Hello,
On Thu, Feb 10, 2011 at 06:03:19PM +0800, Richard Zhao wrote:
> On Thu, Feb 10, 2011 at 09:21:14AM +1300, Ryan Mallon wrote:
> > On 02/09/2011 07:41 PM, Jeremy Kerr wrote:
> >
> > Hi Jeremy,
> >
> > Couple more comments below.
> >
> > ~Ryan
> >
> [...]
> > > +int clk_enable(struct clk *clk)
> > > +{
> > > + unsigned long flags;
> > > + int ret = 0;
> > > +
> > > + spin_lock_irqsave(&clk->enable_lock, flags);
> >
> > WARN_ON(clk->prepare_count == 0); ?
> >
> > > + if (clk->enable_count == 0 && clk->ops->enable)
> > > + ret = clk->ops->enable(clk);
> >
> > Does it make sense to have a clock with no enable function which still
> > returns success from clk_enable? Do we have any platforms which have
> > NULL clk_enable functions?
> >
> > I think that for enable/disable at least we should require platforms to
> > provide functions and oops if they have failed to do so. In the rare
> > case that a platform doesn't need to do anything for enable/disable they
> > can just supply empty functions.
> It's possible to be NULL. So are set_rate/get_rate.
> Ideally, if it's NULL:
> prepare/unprepare: only call parent's prepare/unprepare
> enable/disable: only call parent's enable/disable
> set_rate: fail
> get_rate: reture parent's get_rate
> set_parent: fail
> get_parent: fail
I wouldn't hard-code the parents into the generic functions. But I
suggest to provide generic callbacks to do this, e.g.
clk_get_rate_from_parent(struct clk *c)
{
struct clk *parent = clk_get_parent(c);
return clk_get_rate(parent);
}
Best regards
Uwe
--
Pengutronix e.K. | Uwe Kleine-K?nig |
Industrial Linux Solutions | http://www.pengutronix.de/ |
^ permalink raw reply
* [PATCH] mx3fb: Fix parameter to sdc_init_panel
From: Guennadi Liakhovetski @ 2011-02-10 10:44 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1297332330-21964-1-git-send-email-alexander.stein@systec-electronic.com>
On Thu, 10 Feb 2011, Alexander Stein wrote:
> h_end_width and v_end_width should only contain the front porches.
> Otherwise, SCREEN_WIDTH (pixel clocks between HSYNC) in SDC_HOR_CONF
> and SCREEN_HEIGHT (rows between VSYNC) in SDC_VER_CONF get false values.
Hm, no, this corrupts image on my pcm990 test-board. What makes you think
this patch is needed? How do you see, that current values are "false?"
Thanks
Guennadi
>
> Signed-off-by: Alexander Stein <alexander.stein@systec-electronic.com>
> ---
> drivers/video/mx3fb.c | 7 +++----
> 1 files changed, 3 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/video/mx3fb.c b/drivers/video/mx3fb.c
> index ef71e56..9040833 100644
> --- a/drivers/video/mx3fb.c
> +++ b/drivers/video/mx3fb.c
> @@ -881,12 +881,11 @@ static int __set_par(struct fb_info *fbi, bool lock)
> IPU_PIX_FMT_BGR666 : IPU_PIX_FMT_RGB666,
> fbi->var.left_margin,
> fbi->var.hsync_len,
> - fbi->var.right_margin +
> - fbi->var.hsync_len,
> + fbi->var.right_margin,
> fbi->var.upper_margin,
> fbi->var.vsync_len,
> - fbi->var.lower_margin +
> - fbi->var.vsync_len, sig_cfg) != 0) {
> + fbi->var.lower_margin,
> + sig_cfg) != 0) {
> dev_err(fbi->device,
> "mx3fb: Error initializing panel.\n");
> return -EINVAL;
> --
> 1.7.3.4
>
>
---
Guennadi Liakhovetski, Ph.D.
Freelance Open-Source Software Developer
http://www.open-technology.de/
^ permalink raw reply
* [PATCH 1/2] video: Add i.MX23/28 framebuffer driver
From: Li Frank-B20596 @ 2011-02-10 10:37 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <201102101052.10958.jbe@pengutronix.de>
> This kind of macro encryption _may_ help when you are coding the driver
> the
> first time. But after reading and reading it again (while testing and
> debugging) all these prefixes and suffixes do not add any valuable
> information. They only fill up your lines, enlarges your source code and
> make
> you blind for the real bug...
>
> Everyone who wants to see how source code looks that uses these longs
> macros I
> can recommend reading the so called 'bootlets' source code. :-))
The complex of bootlets is not long macro, but the work around to make sure
Chip PMU work safely. If there are not such macro, power_prep will become
more difficult to understand.
>
> > Developer needn't look up register header file when coding, just
>
> That's why I add these macros into the source file instead into a header
> file.
>
> > write down Register name or bit name according to mx23/mx28 spec.
>
> And sometimes the spec is incomplete or just wrong and so on. Independent
> of
> any macro naming policy.
Not at all. Mx23/mx28 can keep spec, header file and RTL consistent just
because using one source and multiple output. During Freescale mx28 BSP
develop, never happen bit and register definition error.
>
> > If you still think it is too long, I suggest keep HW_ and BM_ prefix to
> > distinguish Which one is register name, which one is bit mask.
>
> The used macro in the address part of the writel() must be an offset,
> while
> the macro used in the value part must be a bit definition. Anything else
> is
> redundant.
If name is too short, there are possible to cause name pollution.
BM_, BP_, BF_ have their implication.
VDCTRL4_SET_DOTCLK_DLY(x), according to our macro policy, it should be
BF_VDCTRL4_SET_DOTCLK_DLY(x).
Generally, you need
Reg = readl(offset+VDCTRL4);
Reg &=~ ((0x7)<<29);
Reg |= VDCTRL4_SET_DOTCLK_DLY(value)
Writel(reg, offset+VDCTRL4)
Compared with our macro policy.
Reg = readl(offset+HW_VDCTRL4);
Reg &=~ BM_VDCTRL4_SET_DOTCLK_DLY;
Reg |= BF_VDCTRL4_SET_DOTCLK_DLY(value)
Writel(reg, offset+HW_VDCTRL4)
>
> Regards,
> Juergen
>
^ permalink raw reply
* [RFC,PATCH 1/3] Add a common struct clk
From: Ryan Mallon @ 2011-02-10 10:10 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20110210100319.GB24710@b20223-02.ap.freescale.net>
On 10/02/11 23:03, Richard Zhao wrote:
> On Thu, Feb 10, 2011 at 09:21:14AM +1300, Ryan Mallon wrote:
>> On 02/09/2011 07:41 PM, Jeremy Kerr wrote:
>>
>> Hi Jeremy,
>>
>> Couple more comments below.
>>
>> ~Ryan
>>
> [...]
>>> +int clk_enable(struct clk *clk)
>>> +{
>>> + unsigned long flags;
>>> + int ret = 0;
>>> +
>>> + spin_lock_irqsave(&clk->enable_lock, flags);
>> WARN_ON(clk->prepare_count == 0); ?
>>
>>> + if (clk->enable_count == 0&& clk->ops->enable)
>>> + ret = clk->ops->enable(clk);
>> Does it make sense to have a clock with no enable function which still
>> returns success from clk_enable? Do we have any platforms which have
>> NULL clk_enable functions?
>>
>> I think that for enable/disable at least we should require platforms to
>> provide functions and oops if they have failed to do so. In the rare
>> case that a platform doesn't need to do anything for enable/disable they
>> can just supply empty functions.
> It's possible to be NULL. So are set_rate/get_rate.
> Ideally, if it's NULL:
> prepare/unprepare: only call parent's prepare/unprepare
> enable/disable: only call parent's enable/disable
No, the whole point of the generic framework is that _all_ clock users
must call prepare/enable and disable/unprepare. Drivers, etc should not
rely on underlying knowledge of a platform. This is why, for instance,
clk_enable will warn if prepare count is zero.
However, I can see that a clock may be fully enabled by its prepare
function and so the enable function is a no-op. User must still call
both prepare and enable though. Perhaps this is what you meant?
~Ryan
^ permalink raw reply
* [PATCH 1/2] video: Add i.MX23/28 framebuffer driver
From: Li Frank-B20596 @ 2011-02-10 10:08 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <201102101046.33994.jbe@pengutronix.de>
> Li Frank-B20596 wrote:
> > > +
> > > + /* if it was disabled, re-enable the mode again */
> > > + reg = readl(host->base + CTRL);
> > > + reg |= CTRL_DOTCLK_MODE;
> > > + writel(reg, host->base + CTRL);
> >
> > writel(CTRL_DOTCLK_MODE, host->base + CTRL_SET)
> > CTRL_SET is CTRL+0x4
> > SET and CLR register is easier than Read and write back.
>
> But you must always check, if the register really has such a SET and
> CLEAR
> feature. Not all registers have this feature...
That's a reason why I suggest use register header that generate from xml.
HW_XX_CTRL_SET will exist if there are such register in hardware.
If hardware have not such register, there are not _SET and _CLR.
Compiler will report error if user use _SET but hardware not such register.
>
> But in this case you are right.
>
> But I would prefer:
> #define SET 4
> #define CLEAR 8
> [...]
> writel(CTRL_DOTCLK_MODE, host->base + CTRL + SET)
> :-)
>
> Regards,
> Juergen
^ permalink raw reply
* [PATCH]ARM: mmp: add Trizeps6 board support
From: Yupeng Schneider @ 2011-02-10 10:08 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <AANLkTim54zTKwhTEKF-ppq-nbtPRAYRvxH3YL0RJ4Vuc@mail.gmail.com>
Hello Eric,
>
> 2011/2/10 Eric Miao <eric.y.miao@gmail.com>
>
>> Corrected the linux-arm-kernel ML address.
>>
>> On Thu, Feb 10, 2011 at 10:24 AM, Eric Miao <eric.y.miao@gmail.com>
>> wrote:
>> > On Thu, Feb 10, 2011 at 7:53 AM, Yupeng Schneider
>> > <yupeng.schneider@ipms.fraunhofer.de> wrote:
>> >> Hi all,
>> >>
>> >> the following patch add the BSP for the Trizeps6 board with pxa168
>> Processor.
>> >>
>> >> Signed-off-by: Yupeng Schneider <yupeng.schneider@googlemail.com>
>> >
>> > Hi Yupeng,
>> >
>> > This is really a nice patch. I would be better if this can be
>> separated
>> into
>> > some smaller patches further:
>>
thank u
>>
>> > 1. some of the MFP macros in trizeps6.h, they are generic and can be
>> > placed into mfp-pxa168.h, or is there any reason that the macros in
>> > mfp-pxa168.h do not work on your board?
>>
ok, i will place them into mfp-pxa168.h. I just thought it is not prefered
to change the mfp-pxa168 file.
>>
>> > 2. individual patches for adding uart3, audio, and cpld
>>
i would very glad to make them in small patchs. i am just now on travel,
and will do that in several days when i am back.
>>
>> > 3. then the patch for the board
>> >
>> > Sounds OK? Let me know your ideas.
>>
AC97+UCB1400: Sound and Touchscreen is ok. The related pxa2xx-ac97 files
have to be modified, the changes are not in this patch. If u want, i can
patch them later too.
yours,
Yupeng
>> >
>> > Thanks
>> > - eric
>> >
>> >> ---
>> >> arch/arm/mach-mmp/Kconfig | 29 ++
>> >> arch/arm/mach-mmp/Makefile | 1 +
>> >> arch/arm/mach-mmp/include/mach/audio.h | 29 ++
>> >> arch/arm/mach-mmp/include/mach/pxa168.h | 21 +
>> >> arch/arm/mach-mmp/include/mach/regs-apmu.h | 1 +
>> >> arch/arm/mach-mmp/include/mach/trizeps6.h | 122 ++++++
>> >> arch/arm/mach-mmp/include/mach/trizeps6_cpld.h | 87 +++++
>> >> arch/arm/mach-mmp/pxa168.c | 10 +
>> >> arch/arm/mach-mmp/trizeps6.c | 469
>> >> ++++++++++++++++++++++++
>> >> arch/arm/mach-mmp/trizeps6_cpld.c | 145 ++++++++
>> >> 10 files changed, 914 insertions(+), 0 deletions(-)
>> >> create mode 100755 arch/arm/mach-mmp/include/mach/audio.h
>> >> create mode 100755 arch/arm/mach-mmp/include/mach/trizeps6.h
>> >> create mode 100755 arch/arm/mach-mmp/include/mach/trizeps6_cpld.h
>> create
>> >> mode 100755 arch/arm/mach-mmp/trizeps6.c
>> >> create mode 100755 arch/arm/mach-mmp/trizeps6_cpld.c
>> >>
>> >> diff --git a/arch/arm/mach-mmp/Kconfig b/arch/arm/mach-mmp/Kconfig
>> index
>> >> 0711d3b..8c6be81 100644
>> >> --- a/arch/arm/mach-mmp/Kconfig
>> >> +++ b/arch/arm/mach-mmp/Kconfig
>> >> @@ -64,6 +64,35 @@ config MACH_TETON_BGA
>> >> Say 'Y' here if you want to support the Marvell PXA168-based
>> >> Teton BGA Development Board.
>> >>
>> >> +comment "Third Party Dev Platforms (sorted by vendor name)"
>> >> +
>> >> +config MACH_TRIZEPS6
>> >> + bool "Keith und Koep Trizeps6 DIMM-Module"
>> >> + select TRIZEPS6_PCMCIA
>> >> + select CPU_PXA168
>> >> + help
>> >> + Say 'Y' here if you want to support TRIZEPS VI board
>> Development Board.
>> >> +
>> >> +choice
>> >> + prompt "Select base board for Trizeps module"
>> >> + depends on MACH_TRIZEPS6
>> >> +
>> >> +config MACH_TRIZEPS6_CONXS
>> >> + bool "ConXS Eval Board"
>> >> +
>> >> +config MACH_TRIZEPS6_UCONXS
>> >> + bool "uConXS Eval Board"
>> >> +
>> >> +config MACH_TRIZEPS6_ANY
>> >> + bool "another Board"
>> >> +
>> >> +endchoice
>> >> +
>> >> +config TRIZEPS6_PCMCIA
>> >> + bool
>> >> + help
>> >> + Enable PCMCIA support for Trizeps modules
>> >> +
>> >> endmenu
>> >>
>> >> config CPU_PXA168
>> >> diff --git a/arch/arm/mach-mmp/Makefile b/arch/arm/mach-mmp/Makefile
>> index
>> >> 751cdbf..1b8744f 100644
>> >> --- a/arch/arm/mach-mmp/Makefile
>> >> +++ b/arch/arm/mach-mmp/Makefile
>> >> @@ -18,3 +18,4 @@ obj-$(CONFIG_MACH_TTC_DKB) += ttc_dkb.o
>> >> obj-$(CONFIG_MACH_FLINT) += flint.o
>> >> obj-$(CONFIG_MACH_MARVELL_JASPER) += jasper.o
>> >> obj-$(CONFIG_MACH_TETON_BGA) += teton_bga.o
>> >> +obj-$(CONFIG_MACH_TRIZEPS6) += trizeps6.o trizeps6_cpld.o
>> >> diff --git a/arch/arm/mach-mmp/include/mach/audio.h
>> >> b/arch/arm/mach-mmp/include/mach/audio.h
>> >> index 0000000..6ef474f
>> >> --- /dev/null
>> >> +++ b/arch/arm/mach-mmp/include/mach/audio.h
>> >> @@ -0,0 +1,29 @@
>> >> +#ifndef __ASM_ARCH_AUDIO_H__
>> >> +#define __ASM_ARCH_AUDIO_H__
>> >> +
>> >> +#include <sound/core.h>
>> >> +#include <sound/pcm.h>
>> >> +#include <sound/ac97_codec.h>
>> >> +
>> >> +/*
>> >> + * @reset_gpio: AC97 reset gpio (normally gpio113 or gpio95)
>> >> + * a -1 value means no gpio will be used for reset
>> >> + * @codec_pdata: AC97 codec platform_data
>> >> +
>> >> + * reset_gpio should only be specified for pxa27x CPUs where a
>> silicon
>> +
>> >> * bug prevents correct operation of the reset line. If not specified,
>> +
>> *
>> >> the default behaviour on these CPUs is to consider gpio 113 as the +
>> *
>> >> AC97 reset line, which is the default on most boards.
>> >> + */
>> >> +struct pxa2xx_audio_ops_t {
>> >> + int (*startup)(struct snd_pcm_substream *, void *);
>> >> + void (*shutdown)(struct snd_pcm_substream *, void *);
>> >> + void (*suspend)(void *);
>> >> + void (*resume)(void *);
>> >> + void *priv;
>> >> + int reset_gpio;
>> >> + void *codec_pdata[AC97_BUS_MAX_DEVICES];
>> >> +};
>> >> +
>> >> +
>> >> +#endif
>> >> diff --git a/arch/arm/mach-mmp/include/mach/pxa168.h
>> >> b/arch/arm/mach-mmp/include/mach/pxa168.h
>> >> index 1801e42..c4a9977 100644
>> >> --- a/arch/arm/mach-mmp/include/mach/pxa168.h
>> >> +++ b/arch/arm/mach-mmp/include/mach/pxa168.h
>> >> @@ -14,9 +14,12 @@ extern void pxa168_clear_keypad_wakeup(void);
>> >> #include <video/pxa168fb.h>
>> >> #include <plat/pxa27x_keypad.h>
>> >> #include <mach/cputype.h>
>> >> +#include <linux/pxa168_eth.h>
>> >> +#include <mach/audio.h>
>> >>
>> >> extern struct pxa_device_desc pxa168_device_uart1;
>> >> extern struct pxa_device_desc pxa168_device_uart2;
>> >> +extern struct pxa_device_desc pxa168_device_uart3;
>> >> extern struct pxa_device_desc pxa168_device_twsi0;
>> >> extern struct pxa_device_desc pxa168_device_twsi1;
>> >> extern struct pxa_device_desc pxa168_device_pwm1;
>> >> @@ -31,6 +34,9 @@ extern struct pxa_device_desc pxa168_device_ssp5;
>> >> extern struct pxa_device_desc pxa168_device_nand;
>> >> extern struct pxa_device_desc pxa168_device_fb;
>> >> extern struct pxa_device_desc pxa168_device_keypad;
>> >> +extern struct pxa_device_desc pxa168_device_mfu;
>> >> +extern struct pxa_device_desc pxa168_device_ac97;
>> >> +
>> >>
>> >> static inline int pxa168_add_uart(int id)
>> >> {
>> >> @@ -39,6 +45,7 @@ static inline int pxa168_add_uart(int id)
>> >> switch (id) {
>> >> case 1: d = &pxa168_device_uart1; break;
>> >> case 2: d = &pxa168_device_uart2; break;
>> >> + case 3: d = &pxa168_device_uart3; break;
>> >> }
>> >>
>> >> if (d == NULL)
>> >> @@ -117,4 +124,18 @@ static inline int pxa168_add_keypad(struct
>> >> pxa27x_keypad_platform_data *data)
>> >> return pxa_register_device(&pxa168_device_keypad, data,
>> sizeof(*data));
>> >> }
>> >>
>> >> +static inline int pxa168_add_mfu(struct pxa168_eth_platform_data
>> *data)
>> +{
>> >> +#if defined(CONFIG_PXA168_ETH)
>> >> + return pxa_register_device(&pxa168_device_mfu, data,
>> sizeof(*data)); +#else
>> >> + return 0;
>> >> +#endif
>> >> +}
>> >> +
>> >> +static inline int pxa168_add_ac97(struct pxa2xx_audio_ops_t *ops) +{
>> >> + return pxa_register_device(&pxa168_device_ac97, ops ,
>> sizeof(*ops)); +}
>> >> +
>> >> #endif /* __ASM_MACH_PXA168_H */
>> >> diff --git a/arch/arm/mach-mmp/include/mach/regs-apmu.h
>> >> b/arch/arm/mach-mmp/include/mach/regs-apmu.h
>> >> index ac47023..68d39bc 100644
>> >> --- a/arch/arm/mach-mmp/include/mach/regs-apmu.h
>> >> +++ b/arch/arm/mach-mmp/include/mach/regs-apmu.h
>> >> @@ -27,6 +27,7 @@
>> >> #define APMU_DMA APMU_REG(0x064)
>> >> #define APMU_GEU APMU_REG(0x068)
>> >> #define APMU_BUS APMU_REG(0x06c)
>> >> +#define APMU_MFU APMU_REG(0x0fc)
>> >>
>> >> #define APMU_FNCLK_EN (1 << 4)
>> >> #define APMU_AXICLK_EN (1 << 3)
>> >> diff --git a/arch/arm/mach-mmp/include/mach/trizeps6.h
>> >> b/arch/arm/mach-mmp/include/mach/trizeps6.h
>> >> index 0000000..40b526a
>> >> --- /dev/null
>> >> +++ b/arch/arm/mach-mmp/include/mach/trizeps6.h
>> >> @@ -0,0 +1,122 @@
>> >>
>> +/************************************************************************
>> >> + * Include file for TRIZEPS6 SoM and ConXS eval-board
>> >> + * Copyright (c) Yupeng Schneider
>> >> + * 2010
>> >> +
>> >>
>> ************************************************************************/
>> +
>> >> +/*
>> >> + * Includes/Defines
>> >> + */
>> >> +#ifndef _TRIPEPS6_H_
>> >> +#define _TRIPEPS6_H_
>> >> +
>> >> +#define STUART_SODIMM 1
>> >> +
>> >> +/* UART */
>> >> +#define GPIO104_UART1_DSR MFP_CFG(GPIO104, AF2)
>> >> +#define GPIO105_UART1_DCD MFP_CFG(GPIO105, AF2)
>> >> +#define GPIO107_UART2_TXD MFP_CFG_DRV(GPIO126, AF2, FAST)
>> >> +#define GPIO107_UART2_RXD MFP_CFG_DRV(GPIO36, AF2, FAST)
>> >> +#define GPIO109_UART2_CTS MFP_CFG(GPIO123, AF2)
>> >> +#define GPIO109_UART2_RTS MFP_CFG(GPIO124, AF2)
>> >> +#define GPIO30_UART3_TXD MFP_CFG_DRV(GPIO30, AF2, FAST)
>> >> +#define GPIO31_UART3_RXD MFP_CFG_DRV(GPIO31, AF2, FAST)
>> >> +#define GPIO32_UART3_CTS MFP_CFG(GPIO32, AF2)
>> >> +#define GPIO33_UART3_RTS MFP_CFG(GPIO33, AF2)
>> >> +
>> >> +/* MMC2 */
>> >> +#define GPIO122_MMC2_DAT3 MFP_CFG_DRV(GPIO122, AF4,
>> FAST)
>> >> +#define GPIO121_MMC2_DAT2 MFP_CFG_DRV(GPIO121, AF4,
>> FAST)
>> >> +#define GPIO120_MMC2_DAT1 MFP_CFG_DRV(GPIO120, AF4,
>> FAST)
>> >> +#define GPIO119_MMC2_DAT0 MFP_CFG_DRV(GPIO119, AF4,
>> FAST)
>> >> +#define GPIO28_MMC2_CMD MFP_CFG_DRV(GPIO28, AF6,
>> FAST)
>> >> +#define GPIO29_MMC2_CLK MFP_CFG_DRV(GPIO29, AF6,
>> FAST)
>> >> +#define GPIO53_MMC2_CD MFP_CFG(GPIO53, AF0)
>> >> +
>> >> +/*MMC4*/
>> >> +#define GPIO78_MMC4_DAT3 MFP_CFG_DRV(GPIO78, AF5,
>> FAST)
>> >> +#define GPIO79_MMC4_DAT2 MFP_CFG_DRV(GPIO79, AF5,
>> FAST)
>> >> +#define GPIO80_MMC4_DAT1 MFP_CFG_DRV(GPIO80, AF5,
>> FAST)
>> >> +#define GPIO81_MMC4_DAT0 MFP_CFG_DRV(GPIO81, AF5,
>> FAST)
>> >> +#define GPIO82_MMC4_CMD MFP_CFG_DRV(GPIO82, AF5,
>> FAST)
>> >> +#define GPIO83_MMC4_CLK MFP_CFG_DRV(GPIO83, AF5,
>> FAST)
>> >> +
>> >> +/* I2C */
>> >> +#define GPIO102_CI2C_SDA MFP_CFG(GPIO102, AF1)
>> >> +
>> >> +/* MFU */
>> >> +#define GPIO86_TX_CLK MFP_CFG(GPIO86, AF5)
>> >> +#define GPIO87_TX_EN MFP_CFG(GPIO87, AF5)
>> >> +#define GPIO88_TX_DQ3 MFP_CFG(GPIO88, AF5)
>> >> +#define GPIO89_TX_DQ2 MFP_CFG(GPIO89, AF5)
>> >> +#define GPIO90_TX_DQ1 MFP_CFG(GPIO90, AF5)
>> >> +#define GPIO91_TX_DQ0 MFP_CFG(GPIO91, AF5)
>> >> +#define GPIO92_MII_CRS MFP_CFG(GPIO92, AF5)
>> >> +#define GPIO93_MII_COL MFP_CFG(GPIO93, AF5)
>> >> +#define GPIO94_RX_CLK MFP_CFG(GPIO94, AF5)
>> >> +#define GPIO95_RX_ER MFP_CFG(GPIO95, AF5)
>> >> +#define GPIO96_RX_DQ3 MFP_CFG(GPIO96, AF5)
>> >> +#define GPIO97_RX_DQ2 MFP_CFG(GPIO97, AF5)
>> >> +#define GPIO98_RX_DQ1 MFP_CFG(GPIO98, AF5)
>> >> +#define GPIO99_RX_DQ0 MFP_CFG(GPIO99, AF5)
>> >> +#define GPIO100_MII_MDC MFP_CFG(GPIO100, AF5)
>> >> +#define GPIO101_MII_MDIO MFP_CFG(GPIO101, AF5)
>> >> +#define GPIO103_RX_DV MFP_CFG(GPIO103, AF5)
>> >> +
>> >> +/* AC97 */
>> >> +#define GPIO115_AC97_BITCLK MFP_CFG(GPIO115, AF6)
>> >> +#define GPIO114_AC97_SDATA_IN_0 MFP_CFG(GPIO114, AF6)
>> >> +#define GPIO116_AC97_SDATA_IN_1 MFP_CFG(GPIO116, AF6)
>> >> +#define GPIO117_AC97_SDATA_OUT MFP_CFG(GPIO117, AF6)
>> >> +#define GPIO118_AC97_SYNC MFP_CFG(GPIO118, AF6)
>> >> +
>> >> +
>> >> +
>> >> +#define TRIZEPS6_PHYS_BASE 0xd4000000
>> >> +
>> >> +
>> >> +#define TRIZEPS6_PIC_PHYS (0x88000000) /* CS0-3 Logic chip
>> on
>> ConXS */
>> >> + /* Logic on ConXS-board CSFR
>> register*/
>> >> +#define TRIZEPS6_CFSR_PHYS (TRIZEPS6_PIC_PHYS)
>> >> + /* Logic on ConXS-board BOCR
>> register*/
>> >> +#define TRIZEPS6_BOCR_PHYS (TRIZEPS6_PIC_PHYS+0x00200000)
>> >> + /* Logic on ConXS-board IRCR
>> register*/
>> >> +#define TRIZEPS6_IRCR_PHYS (TRIZEPS6_PIC_PHYS+0x00300000)
>> >> + /* Logic on ConXS-board UPSR
>> register*/
>> >> +#define TRIZEPS6_UPSR_PHYS (TRIZEPS6_PIC_PHYS+0x00280000)
>> >> + /* Logic on ConXS-board DICR
>> register*/
>> >> +#define TRIZEPS6_DICR_PHYS (TRIZEPS6_PIC_PHYS+0x00380000)
>> >> +
>> >> +
>> >> +#define TRIZEPS6_CPLD_PHYS (0x8e000000) /* CPLD on Trizeps6 module
>> */
>> +
>> >> +#define TRIZEPS6_CPLD_CTRL_PHYS (TRIZEPS6_CPLD_PHYS)
>> >> +#define TRIZEPS6_CPLD_FTUR_PHYS (TRIZEPS6_CPLD_PHYS+0x4)
>> >> +#define TRIZEPS6_CPLD_HIBE_PHYS (TRIZEPS6_CPLD_PHYS+0x8)
>> >> +#define TRIZEPS6_CPLD_PWM_PHYS (TRIZEPS6_CPLD_PHYS+0xc)
>> >> +#define TRIZEPS6_CPLD_PLDR_PHYS (TRIZEPS6_CPLD_PHYS+0x10)
>> >> +#define TRIZEPS6_CPLD_PSET_PHYS (TRIZEPS6_CPLD_PHYS+0x14)
>> >> +#define TRIZEPS6_CPLD_TTLO_PHYS (TRIZEPS6_CPLD_PHYS+0x18)
>> >> +
>> >> +
>> >> +/* MMC socket */
>> >> +#define GPIO_MMC2_DET 53
>> >> +#define TRIZEPS6_MMC2_IRQ IRQ_GPIO(mfp_to_gpio(MFP_PIN_GPIO53))
>> >> +#define GPIO_MMC4_DET 41
>> >> +#define TRIZEPS6_MMC4_IRQ IRQ_GPIO(mfp_to_gpio(MFP_PIN_GPIO41)
>> >> +
>> >> +/* Off-module PIC on ConXS board */
>> >> +#define GPIO_PIC 51
>> >> +#define TRIZEPS6_PIC_IRQ IRQ_GPIO(mfp_to_gpio(MFP_PIN_GPIO51)
>> >> +
>> >> +/* PCMCIA socket Compact Flash */
>> >> +#define GPIO_PCD 43 /* PCMCIA Card Detect
>> */
>> >> +#define TRIZEPS6_CD_IRQ
>> IRQ_GPIO(mfp_to_gpio(MFP_PIN_GPIO43)
>> >> +#define GPIO_PRDY 113 /* READY / nINT */
>> >> +#define TRIZEPS6_READY_NINT IRQ_GPIO(mfp_to_gpio(MFP_PIN_GPIO113)
>> +
>> >> +#define trizeps6_GPIO_CODEC_IRQ 116
>> >> +
>> >> +extern void trizeps6_ac97_acreset(int i);
>> >> +
>> >> +#endif /* _TRIPEPS6_H_ */
>> >> diff --git a/arch/arm/mach-mmp/include/mach/trizeps6_cpld.h
>> >> b/arch/arm/mach-mmp/include/mach/trizeps6_cpld.h
>> >> index 0000000..8538a6b
>> >> --- /dev/null
>> >> +++ b/arch/arm/mach-mmp/include/mach/trizeps6_cpld.h
>> >> @@ -0,0 +1,87 @@
>> >> +#ifndef _TRIPEPS6_CPLD_H_
>> >> +#define _TRIPEPS6_CPLD_H_
>> >> +
>> >> +/* index of resource */
>> >> +#define CTRL_S 0
>> >> +#define CTRL_R 1
>> >> +#define FTUR_S 2
>> >> +#define FTUR_R 3
>> >> +#define HIBE_S 4
>> >> +#define HIBE_R 5
>> >> +#define PWM 6
>> >> +#define PLDR_S 7
>> >> +#define PLDR_R 8
>> >> +#define PSET_S 9
>> >> +#define PSET_R 10
>> >> +#define TTLO_S 11
>> >> +#define TTLO_R 12
>> >> +
>> >> +#define CPLD_CTRL_S cpld.addr[CTRL_S].val
>> >> +#define CPLD_CTRL_R cpld.addr[CTRL_R].val
>> >> +#define CPLD_CONTROL_GR (1 << 0)
>> >> +#define CPLD_CONTROL_CODEC (1 << 2)
>> >> +#define CPLD_CONTROL_ETHPHY (1 << 3)
>> >> +#define CPLD_CONTROL_RWL (1 << 4)
>> >> +#define CPLD_CONTROL_RBT (1 << 5)
>> >> +
>> >> +#define CPLD_FTUR_S cpld.addr[FTUR_S].val
>> >> +#define CPLD_FTUR_R cpld.addr[FTUR_R].val
>> >> +#define CPLD_FEATURE_UART3_SODIMM (1 << 0)
>> >> +#define CPLD_FEATURE_UART3_BT (1 << 1)
>> >> +#define CPLD_FEATURE_CF_MODE (1 << 2)
>> >> +#define CPLD_FEATURE_TTLIO (1 << 3)
>> >> +#define CPLD_PWM_SODIMM_P69 (1 << 4)
>> >> +#define CPLD_PWM_SODIMM_P77 (1 << 5)
>> >> +#define CPLD_PWM_SODIMM_P106 (1 << 6)
>> >> +#define CPLD_BT_PWM_SODIMM (1 << 7)
>> >> +
>> >> +#define CPLD_HIBE_S cpld.addr[HIBE_S].val
>> >> +#define CPLD_HIBE_R cpld.addr[HIBE_R].val
>> >> +#define CPLD_HIBERNATE_MODE (1 << 0)
>> >> +#define CPLD_HIBERNATE_WAKE_TOUCH (1 << 1)
>> >> +#define CPLD_HIBERNATE_WAKE_PMIC (1 << 2)
>> >> +#define CPLD_HIBERNATE_WAKE_IRQ_P43 (1 << 3)
>> >> +
>> >> +#define CPLD_PWM cpld.addr[PWM].val
>> >> +
>> >> +#define CPLD_PINLDR cpld.addr[PINLDR].val
>> >> +#define CPLD_PINLDR_P69 (1 <<
>> 0)
>> >> +#define CPLD_PINLDR_P100_PSKTSEL (1 << 1)
>> >> +#define CPLD_PINLDR_P98_CFNREG (1 << 2)
>> >> +#define CPLD_PINLDR_P104_CFNIOIS16 (1 << 3)
>> >> +#define CPLD_PINLDR_P93_RDNWR (1 << 4)
>> >> +#define CPLD_PINLDR_P104_IRQ_P43 (1 << 5)
>> >> +
>> >> +#define CPLD_PSET_S cpld.addr[PSET_S].val
>> >> +#define CPLD_PSET_R cpld.addr[PSET_R].val
>> >> +#define CPLD_PINSET_P69 (1 <<
>> 0)
>> >> +#define CPLD_PINSET_P100_PSKTSEL (1 << 1)
>> >> +#define CPLD_PINSET_P98_CFNREG (1 << 2)
>> >> +#define CPLD_PINSET_P104_CFNIOIS16 (1 << 3)
>> >> +#define CPLD_PINSET_P93_RDnWR (1 << 4)
>> >> +
>> >> +#define CPLD_TTLO_S cpld.addr[TTLO_S].val
>> >> +#define CPLD_TTLO_R cpld.addr[TTLO_R].val
>> >> +#define CPLD_TTLIO_W_A8 (1 << 0)
>> >> +#define CPLD_TTLIO_W_A9 (1 << 1)
>> >> +#define CPLD_TTLIO_W_A10 (1 << 2)
>> >> +#define CPLD_TTLIO_W_A11 (1 << 3)
>> >> +#define CPLD_TTLIO_W_A12 (1 << 4)
>> >> +#define CPLD_TTLIO_W_A13 (1 << 5)
>> >> +#define CPLD_TTLIO_W_A14 (1 << 6)
>> >> +#define CPLD_TTLIO_W_A15 (1 << 7)
>> >> +#define CPLD_TTLIO_r_A0 (1 << 0)
>> >> +#define CPLD_TTLIO_r_A1 (1 << 1)
>> >> +#define CPLD_TTLIO_r_A2 (1 << 2)
>> >> +#define CPLD_TTLIO_r_A3 (1 << 3)
>> >> +#define CPLD_TTLIO_r_A4 (1 << 4)
>> >> +#define CPLD_TTLIO_r_A5 (1 << 5)
>> >> +#define CPLD_TTLIO_r_A6 (1 << 6)
>> >> +#define CPLD_TTLIO_r_A7 (1 << 7)
>> >> +
>> >> +
>> >> +
>> >> +extern unsigned short trizeps6_cpld_readw(unsigned int reg);
>> >> +extern inline void trizeps6_cpld_writew(unsigned int reg, unsigned
>> short
>> >> value);
>> >> +
>> >> +#endif /* _TRIPEPS6_CPLD_H_ */
>> >> diff --git a/arch/arm/mach-mmp/pxa168.c b/arch/arm/mach-mmp/pxa168.c
>> index
>> >> 72b4e76..9c2396e 100644
>> >> --- a/arch/arm/mach-mmp/pxa168.c
>> >> +++ b/arch/arm/mach-mmp/pxa168.c
>> >> @@ -66,6 +66,7 @@ void __init pxa168_init_irq(void)
>> >> /* APB peripheral clocks */
>> >> static APBC_CLK(uart1, PXA168_UART1, 1, 14745600);
>> >> static APBC_CLK(uart2, PXA168_UART2, 1, 14745600);
>> >> +static APBC_CLK(uart3, PXA168_UART3, 1, 14745600);
>> >> static APBC_CLK(twsi0, PXA168_TWSI0, 1, 33000000);
>> >> static APBC_CLK(twsi1, PXA168_TWSI1, 1, 33000000);
>> >> static APBC_CLK(pwm1, PXA168_PWM1, 1, 13000000);
>> >> @@ -78,14 +79,18 @@ static APBC_CLK(ssp3, PXA168_SSP3, 4, 0);
>> >> static APBC_CLK(ssp4, PXA168_SSP4, 4, 0);
>> >> static APBC_CLK(ssp5, PXA168_SSP5, 4, 0);
>> >> static APBC_CLK(keypad, PXA168_KPC, 0, 32000);
>> >> +static APBC_CLK(ac97, PXA168_AC97, 0, 24576000);
>> >> +
>> >>
>> >> static APMU_CLK(nand, NAND, 0x01db, 208000000);
>> >> static APMU_CLK(lcd, LCD, 0x7f, 312000000);
>> >> +static APMU_CLK(mfu, MFU, 0x9, 0);
>> >>
>> >> /* device and clock bindings */
>> >> static struct clk_lookup pxa168_clkregs[] = {
>> >> INIT_CLKREG(&clk_uart1, "pxa2xx-uart.0", NULL),
>> >> INIT_CLKREG(&clk_uart2, "pxa2xx-uart.1", NULL),
>> >> + INIT_CLKREG(&clk_uart3, "pxa2xx-uart.2", NULL),
>> >> INIT_CLKREG(&clk_twsi0, "pxa2xx-i2c.0", NULL),
>> >> INIT_CLKREG(&clk_twsi1, "pxa2xx-i2c.1", NULL),
>> >> INIT_CLKREG(&clk_pwm1, "pxa168-pwm.0", NULL),
>> >> @@ -100,6 +105,8 @@ static struct clk_lookup pxa168_clkregs[] = {
>> >> INIT_CLKREG(&clk_nand, "pxa3xx-nand", NULL),
>> >> INIT_CLKREG(&clk_lcd, "pxa168-fb", NULL),
>> >> INIT_CLKREG(&clk_keypad, "pxa27x-keypad", NULL),
>> >> + INIT_CLKREG(&clk_mfu, "pxa168-eth", "MFUCLK"),
>> >> + INIT_CLKREG(&clk_ac97, "pxa2xx-ac97", "AC97CLK"),
>> >> };
>> >>
>> >> static int __init pxa168_init(void)
>> >> @@ -149,6 +156,7 @@ void pxa168_clear_keypad_wakeup(void)
>> >> /* on-chip devices */
>> >> PXA168_DEVICE(uart1, "pxa2xx-uart", 0, UART1, 0xd4017000, 0x30, 21,
>> 22);
>> >> PXA168_DEVICE(uart2, "pxa2xx-uart", 1, UART2, 0xd4018000, 0x30, 23,
>> 24);
>> >> +PXA168_DEVICE(uart3, "pxa2xx-uart", 2, UART3, 0xd4026000, 0x30, 23,
>> 24);
>> >> PXA168_DEVICE(twsi0, "pxa2xx-i2c", 0, TWSI0, 0xd4011000, 0x28);
>> >> PXA168_DEVICE(twsi1, "pxa2xx-i2c", 1, TWSI1, 0xd4025000, 0x28);
>> >> PXA168_DEVICE(pwm1, "pxa168-pwm", 0, NONE, 0xd401a000, 0x10);
>> >> @@ -163,3 +171,5 @@ PXA168_DEVICE(ssp4, "pxa168-ssp", 3, SSP4,
>> 0xd4020000,
>> >> 0x40, 58, 59);
>> >> PXA168_DEVICE(ssp5, "pxa168-ssp", 4, SSP5, 0xd4021000, 0x40, 60,
>> 61);
>> >> PXA168_DEVICE(fb, "pxa168-fb", -1, LCD, 0xd420b000, 0x1c8);
>> >> PXA168_DEVICE(keypad, "pxa27x-keypad", -1, KEYPAD, 0xd4012000,
>> 0x4c);
>> >> +PXA168_DEVICE(mfu, "pxa168-eth", -1, MFU, 0xc0800000, 0x0FFF);
>> >> +PXA168_DEVICE(ac97, "pxa2xx-ac97", -1, AC97, 0xd402B000, 0x0fff);
>> diff
>> >> --git a/arch/arm/mach-mmp/trizeps6.c b/arch/arm/mach-mmp/trizeps6.c
>> index
>> >> 0000000..a935f14
>> >> --- /dev/null
>> >> +++ b/arch/arm/mach-mmp/trizeps6.c
>> >> @@ -0,0 +1,469 @@
>> >> +/*
>> >> + * linux/arch/arm/mach-mmp/trizeps6.c
>> >> + *
>> >> + * Support for the Keith und Koep Trizeps6 Modul Platform
>> >> + * based on Marvell PXA168-CPU
>> >> + *
>> >> + * Author: Yupeng Schneider
>> >> + *
>> >> + * 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 +
>> *
>> >> publishhed by the Free Software Foundation.
>> >> + */
>> >> +
>> >> +#include <linux/init.h>
>> >> +#include <linux/kernel.h>
>> >> +#include <linux/platform_device.h>
>> >> +#include <linux/mtd/mtd.h>
>> >> +#include <linux/mtd/partitions.h>
>> >> +#include <linux/mtd/nand.h>
>> >> +#include <linux/delay.h>
>> >> +#include <asm/mach-types.h>
>> >> +#include <asm/mach/arch.h>
>> >> +#include <mach/addr-map.h>
>> >> +#include <mach/mfp-pxa168.h>
>> >> +#include <mach/pxa168.h>
>> >> +#include <mach/gpio.h>
>> >> +#include <linux/pxa168_eth.h>
>> >> +#include <mach/irqs.h>
>> >> +#include <mach/trizeps6.h>
>> >> +#include <mach/trizeps6_cpld.h>
>> >> +#include "common.h"
>> >> +#include <linux/mmc/sdhci.h>
>> >> +#include <linux/ucb1400.h>
>> >> +#include <mach/audio.h>
>> >> +
>> >> +
>> >> +static unsigned long trizeps6_pin_config[] __initdata = {
>> >> + /* Data Flash Interface */
>> >> + GPIO0_DFI_D15,
>> >> + GPIO1_DFI_D14,
>> >> + GPIO2_DFI_D13,
>> >> + GPIO3_DFI_D12,
>> >> + GPIO4_DFI_D11,
>> >> + GPIO5_DFI_D10,
>> >> + GPIO6_DFI_D9,
>> >> + GPIO7_DFI_D8,
>> >> + GPIO8_DFI_D7,
>> >> + GPIO9_DFI_D6,
>> >> + GPIO10_DFI_D5,
>> >> + GPIO11_DFI_D4,
>> >> + GPIO12_DFI_D3,
>> >> + GPIO13_DFI_D2,
>> >> + GPIO14_DFI_D1,
>> >> + GPIO15_DFI_D0,
>> >> +
>> >> + /* Static Memory Controller */
>> >> + GPIO18_SMC_nCS0,
>> >> + GPIO34_SMC_nCS1,
>> >> + GPIO23_SMC_nLUA,
>> >> + GPIO25_SMC_nLLA,
>> >> + GPIO28_SMC_RDY,
>> >> + GPIO29_SMC_SCLK,
>> >> + GPIO35_SMC_BE1,
>> >> + GPIO36_SMC_BE2,
>> >> +
>> >> +
>> >> + /* UART1 */
>> >> + GPIO107_UART1_RXD,
>> >> + GPIO108_UART1_TXD,
>> >> + GPIO107_UART1_RXD,
>> >> + GPIO108_UART1_TXD,
>> >> + GPIO109_UART1_RTS,
>> >> + GPIO110_UART1_CTS,
>> >> + GPIO111_UART1_RI,
>> >> + GPIO104_UART1_DSR,
>> >> + GPIO112_UART1_DTR,
>> >> + GPIO105_UART1_DCD,
>> >> +
>> >> + /* UART2 */
>> >> + GPIO107_UART2_TXD,
>> >> + GPIO107_UART2_RXD,
>> >> + GPIO109_UART2_CTS,
>> >> + GPIO109_UART2_RTS,
>> >> +
>> >> + /* UART3 */
>> >> + GPIO30_UART3_TXD,
>> >> + GPIO31_UART3_RXD,
>> >> + GPIO32_UART3_CTS,
>> >> + GPIO33_UART3_RTS,
>> >> +
>> >> +
>> >> + /* MFU */
>> >> + GPIO86_TX_CLK,
>> >> + GPIO87_TX_EN,
>> >> + GPIO88_TX_DQ3,
>> >> + GPIO89_TX_DQ2,
>> >> + GPIO90_TX_DQ1,
>> >> + GPIO91_TX_DQ0,
>> >> + GPIO92_MII_CRS,
>> >> + GPIO93_MII_COL,
>> >> + GPIO94_RX_CLK,
>> >> + GPIO95_RX_ER,
>> >> + GPIO96_RX_DQ3,
>> >> + GPIO97_RX_DQ2,
>> >> + GPIO98_RX_DQ1,
>> >> + GPIO99_RX_DQ0,
>> >> + GPIO100_MII_MDC,
>> >> + GPIO101_MII_MDIO,
>> >> + GPIO103_RX_DV,
>> >> +
>> >> + /* USB OTG */
>> >> + GPIO85_GPIO,
>> >> + GPIO47_GPIO,
>> >> +
>> >> + /* i2c bus */
>> >> + GPIO102_CI2C_SDA,
>> >> + GPIO106_CI2C_SCL,
>> >> +
>> >> +
>> >> + /* MMC2 */
>> >> + GPIO122_MMC2_DAT3 | MFP_PULL_HIGH,
>> >> + GPIO121_MMC2_DAT2 | MFP_PULL_HIGH,
>> >> + GPIO120_MMC2_DAT1 | MFP_PULL_HIGH,
>> >> + GPIO119_MMC2_DAT0 | MFP_PULL_HIGH,
>> >> + GPIO28_MMC2_CMD | MFP_PULL_HIGH,
>> >> + GPIO29_MMC2_CLK,
>> >> + GPIO53_MMC2_CD | MFP_PULL_LOW, /*
>> TRIZEPS6_MMC2_IRQ */
>> >> +
>> >> + /* MMC4 */
>> >> + GPIO78_MMC4_DAT3 | MFP_PULL_HIGH,
>> >> + GPIO79_MMC4_DAT2 | MFP_PULL_HIGH,
>> >> + GPIO80_MMC4_DAT1 | MFP_PULL_HIGH,
>> >> + GPIO81_MMC4_DAT0 | MFP_PULL_HIGH,
>> >> + GPIO82_MMC4_CMD | MFP_PULL_HIGH,
>> >> + GPIO83_MMC4_CLK,
>> >> +
>> >> + /* LCD */
>> >> + GPIO56_LCD_FCLK_RD,
>> >> + GPIO57_LCD_LCLK_A0,
>> >> + GPIO58_LCD_PCLK_WR,
>> >> + GPIO59_LCD_DENA_BIAS,
>> >> + GPIO60_LCD_DD0,
>> >> + GPIO61_LCD_DD1,
>> >> + GPIO62_LCD_DD2,
>> >> + GPIO63_LCD_DD3,
>> >> + GPIO64_LCD_DD4,
>> >> + GPIO65_LCD_DD5,
>> >> + GPIO66_LCD_DD6,
>> >> + GPIO67_LCD_DD7,
>> >> + GPIO68_LCD_DD8,
>> >> + GPIO69_LCD_DD9,
>> >> + GPIO70_LCD_DD10,
>> >> + GPIO71_LCD_DD11,
>> >> + GPIO72_LCD_DD12,
>> >> + GPIO73_LCD_DD13,
>> >> + GPIO74_LCD_DD14,
>> >> + GPIO75_LCD_DD15,
>> >> +
>> >> +
>> >> + /* AC97 */
>> >> + GPIO115_AC97_BITCLK,
>> >> + GPIO114_AC97_SDATA_IN_0,
>> >> + GPIO117_AC97_SDATA_OUT,
>> >> + GPIO118_AC97_SYNC,
>> >> + GPIO116_GPIO,
>> >> +
>> >> +
>> >> + GPIO51_GPIO, /* TRIZEPS6_PIC_IRQ */
>> >> + GPIO27_GPIO, /* Ethernet IRQ */
>> >> +};
>> >> +
>> >> +
>> >> +
>> >>
>> +/****************************************************************************
>> >> + * CPLD
>> >> +
>> >>
>> ****************************************************************************/
>> >> +
>> >> +static struct resource tri6_cpld_resources[] = {
>> >> + [CTRL_S] = {
>> >> + .start = TRIZEPS6_CPLD_CTRL_PHYS,
>> >> + .end = TRIZEPS6_CPLD_CTRL_PHYS+1,
>> >> + .flags = IORESOURCE_MEM,
>> >> + },
>> >> + [CTRL_R] = {
>> >> + .start = TRIZEPS6_CPLD_CTRL_PHYS+2,
>> >> + .end = TRIZEPS6_CPLD_CTRL_PHYS+3,
>> >> + .flags = IORESOURCE_MEM,
>> >> + },
>> >> + [FTUR_S] = {
>> >> + .start = TRIZEPS6_CPLD_FTUR_PHYS,
>> >> + .end = TRIZEPS6_CPLD_FTUR_PHYS+1,
>> >> + .flags = IORESOURCE_MEM,
>> >> + },
>> >> + [FTUR_R] = {
>> >> + .start = TRIZEPS6_CPLD_FTUR_PHYS+2,
>> >> + .end = TRIZEPS6_CPLD_FTUR_PHYS+3,
>> >> + .flags = IORESOURCE_MEM,
>> >> + },
>> >> + [HIBE_S] = {
>> >> + .start = TRIZEPS6_CPLD_HIBE_PHYS,
>> >> + .end = TRIZEPS6_CPLD_HIBE_PHYS+1,
>> >> + .flags = IORESOURCE_MEM,
>> >> + },
>> >> + [HIBE_R] = {
>> >> + .start = TRIZEPS6_CPLD_HIBE_PHYS+2,
>> >> + .end = TRIZEPS6_CPLD_HIBE_PHYS+3,
>> >> + .flags = IORESOURCE_MEM,
>> >> + },
>> >> + [PWM] = {
>> >> + .start = TRIZEPS6_CPLD_PWM_PHYS,
>> >> + .end = TRIZEPS6_CPLD_PWM_PHYS+1,
>> >> + .flags = IORESOURCE_MEM,
>> >> + },
>> >> + [PLDR_S] = {
>> >> + .start = TRIZEPS6_CPLD_PLDR_PHYS,
>> >> + .end = TRIZEPS6_CPLD_PLDR_PHYS+1,
>> >> + .flags = IORESOURCE_MEM,
>> >> + },
>> >> + [PLDR_R] = {
>> >> + .start = TRIZEPS6_CPLD_PLDR_PHYS+2,
>> >> + .end = TRIZEPS6_CPLD_PLDR_PHYS+3,
>> >> + .flags = IORESOURCE_MEM,
>> >> + },
>> >> + [PSET_S] = {
>> >> + .start = TRIZEPS6_CPLD_PSET_PHYS,
>> >> + .end = TRIZEPS6_CPLD_PSET_PHYS+1,
>> >> + .flags = IORESOURCE_MEM,
>> >> + },
>> >> + [PSET_R] = {
>> >> + .start = TRIZEPS6_CPLD_PSET_PHYS+2,
>> >> + .end = TRIZEPS6_CPLD_PSET_PHYS+3,
>> >> + .flags = IORESOURCE_MEM,
>> >> + },
>> >> + [TTLO_S] = {
>> >> + .start = TRIZEPS6_CPLD_TTLO_PHYS,
>> >> + .end = TRIZEPS6_CPLD_TTLO_PHYS+1,
>> >> + .flags = IORESOURCE_MEM,
>> >> + },
>> >> + [TTLO_R] = {
>> >> + .start = TRIZEPS6_CPLD_TTLO_PHYS+2,
>> >> + .end = TRIZEPS6_CPLD_TTLO_PHYS+3,
>> >> + .flags = IORESOURCE_MEM,
>> >> + },
>> >> +};
>> >> +
>> >> +static int tri6_cpld_platdata = 1;
>> >> +
>> >> +static struct platform_device cpld_device = {
>> >> + .name = "trizeps6-cpld",
>> >> + .id = -1,
>> >> + .num_resources = ARRAY_SIZE(tri6_cpld_resources),
>> >> + .resource = tri6_cpld_resources,
>> >> + .dev = {
>> >> + .platform_data = &tri6_cpld_platdata,
>> >> + }
>> >> +};
>> >> +
>> >> +
>> >>
>> +/******************************************************************************
>> >> + * Audio and Touchscreen
>> >> +
>> >>
>> ******************************************************************************/
>> >> +
>> >> +static struct ucb1400_pdata trizeps6_ucb1400_pdata = {
>> >> + .irq = gpio_to_irq(trizeps6_GPIO_CODEC_IRQ),
>> >> +};
>> >> +
>> >> +static struct pxa2xx_audio_ops_t trizeps6_ac97_pdata = {
>> >> + .codec_pdata = { &trizeps6_ucb1400_pdata, },
>> >> +};
>> >> +
>> >> +static struct platform_device trizeps6_ucb1400_device = {
>> >> + .name = "ucb1400_core",
>> >> + .id = -1,
>> >> + .dev = {
>> >> + .platform_data = &trizeps6_ucb1400_pdata,
>> >> + },
>> >> +};
>> >> +
>> >> +static void __init trizeps6_ts_init(void)
>> >> +{
>> >> + pxa168_add_ac97(&trizeps6_ac97_pdata);
>> >> + platform_device_register(&trizeps6_ucb1400_device);
>> >> +}
>> >> +
>> >> +void trizeps6_ac97_acreset(int i)
>> >> +{ unsigned short value;
>> >> +
>> >> + if (i == 1) {
>> >> +
>> >> + value = trizeps6_cpld_readw(CTRL_S);
>> >> + trizeps6_cpld_writew(CTRL_S, value |
>> CPLD_CONTROL_CODEC);
>> >> + }
>> >> + if (!i) {
>> >> + value = trizeps6_cpld_readw(CTRL_R);
>> >> + trizeps6_cpld_writew(CTRL_R, value |
>> CPLD_CONTROL_CODEC);
>> >> + }
>> >> +}
>> >> +
>> >>
>> +/******************************************************************************
>> >> + * Ethernet
>> >> +
>> >>
>> ******************************************************************************/
>> >> +static int trizeps6_eth_init(void)
>> >> +{
>> >> + unsigned short value;
>> >> +
>> >> + value = trizeps6_cpld_readw(CTRL_R);
>> >> + trizeps6_cpld_writew(CTRL_R, value | CPLD_CONTROL_ETHPHY);
>> >> + return 0;
>> >> +
>> >> +}
>> >> +
>> >> +static struct pxa168_eth_platform_data trizeps6_eth_data = {
>> >> + .phy_addr = 0x1f,
>> >> + .port_number = 0,
>> >> + .init = trizeps6_eth_init,
>> >> +};
>> >> +
>> >>
>> +/******************************************************************************
>> >> + * NAND
>> >> +
>> >>
>> ******************************************************************************/
>> >> +static struct pxa3xx_nand_timing stnand02gw3b2d_timing = {
>> >> + .tCH = 10,
>> >> + .tCS = 40,
>> >> + .tWH = 20,
>> >> + .tWP = 24,
>> >> + .tRH = 20,
>> >> + .tRP = 24,
>> >> + .tR = 50000,
>> >> + .tWHR = 120,
>> >> + .tAR = 20,
>> >> +
>> >> +};
>> >> +
>> >> +static struct pxa3xx_nand_cmdset largepage_cmdset = {
>> >> + .read1 = 0x3000,
>> >> + .read2 = 0x0050,
>> >> + .program = 0x1080,
>> >> + .read_status = 0x0070,
>> >> + .read_id = 0x0090,
>> >> + .erase = 0xD060,
>> >> + .reset = 0x00FF,
>> >> + .lock = 0x002A,
>> >> + .unlock = 0x2423,
>> >> + .lock_status = 0x007A,
>> >> +};
>> >> +
>> >> +static struct pxa3xx_nand_flash trizeps6_flashes[] = {
>> >> + {
>> >> + .timing = &stnand02gw3b2d_timing,
>> >> + .cmdset = &largepage_cmdset,
>> >> + .page_per_block = 64,
>> >> + .page_size = 2048,
>> >> + .flash_width = 8,
>> >> + .dfc_width = 8,
>> >> + .num_blocks = 2048,
>> >> + .chip_id = 0xda20,
>> >> + },
>> >> +};
>> >> +
>> >> +
>> >> +static struct mtd_partition trizeps6_nand_partitions[] = {
>> >> + {
>> >> + .name = "bootloader",
>> >> + .offset = 0,
>> >> + .size = SZ_16M,
>> >> + .mask_flags = MTD_WRITEABLE,
>> >> + }, {
>> >> + .name = "reserved",
>> >> + .offset = MTDPART_OFS_APPEND,
>> >> + .size = SZ_128K,
>> >> + .mask_flags = MTD_WRITEABLE,
>> >> + }, {
>> >> + .name = "kernel",
>> >> + .offset = MTDPART_OFS_APPEND,
>> >> + .size = (2*SZ_2M + SZ_1M),
>> >> + .mask_flags = 0,
>> >> + }, {
>> >> + .name = "filesystem",
>> >> + .offset = MTDPART_OFS_APPEND,
>> >> + .size = (SZ_256M - 3*SZ_8M),
>> >> + .mask_flags = 0,
>> >> + }
>> >> +};
>> >> +
>> >> +static struct pxa3xx_nand_platform_data trizeps6_nand_info = {
>> >> + .enable_arbiter = 1,
>> >> + .parts = trizeps6_nand_partitions,
>> >> + .nr_parts = ARRAY_SIZE(trizeps6_nand_partitions),
>> >> + .flash = trizeps6_flashes,
>> >> + .num_flash = ARRAY_SIZE(trizeps6_flashes),
>> >> + .keep_config = 0
>> >> +};
>> >> +
>> >> +
>> >> +
>> >> +static struct i2c_board_info trizeps6_i2c_devices[] = {
>> >> + { I2C_BOARD_INFO("pcf8593", 0x51), },
>> >> +};
>> >> +
>> >> +
>> >>
>> +/******************************************************************************
>> >> + * LCD
>> >> +
>> >>
>> ******************************************************************************/
>> >> +static struct fb_videomode trizeps6_video_modes[] = {
>> >> + [0] = {
>> >> + .pixclock = 39720,
>> >> + .refresh = 60,
>> >> + .xres = 640,
>> >> + .yres = 480,
>> >> + .hsync_len = 63,
>> >> + .left_margin = 12,
>> >> + .right_margin = 12,
>> >> + .vsync_len = 4,
>> >> + .upper_margin = 32,
>> >> + .lower_margin = 10,
>> >> + .sync = FB_SYNC_VERT_HIGH_ACT |
>> FB_SYNC_HOR_HIGH_ACT,
>> >> + },
>> >> +};
>> >> +
>> >> +static struct pxa168fb_mach_info trizeps6_lcd_info = {
>> >> + .id = "Base-trizeps6",
>> >> + .modes = trizeps6_video_modes,
>> >> + .num_modes = ARRAY_SIZE(trizeps6_video_modes),
>> >> + .pix_fmt = PIX_FMT_RGB565,
>> >> + .io_pin_allocation_mode = PIN_MODE_DUMB_16_GPIO,
>> >> + .dumb_mode = DUMB_MODE_RGB565,
>> >> + .active = 1,
>> >> + .panel_rbswap = 1,
>> >> + .invert_pixclock = 0,
>> >> +};
>> >> +
>> >> +
>> >> +static struct platform_device *trizeps6_devices[] __initdata = {
>> >> + &cpld_device,
>> >> +};
>> >> +
>> >> +static void __init trizeps6_init(void)
>> >> +{
>> >> + mfp_config(ARRAY_AND_SIZE(trizeps6_pin_config));
>> >> +
>> >> + pxa168_add_uart(1);
>> >> + pxa168_add_uart(2);
>> >> +#ifdef STUART_SODIMM
>> >> + pxa168_add_uart(3);
>> >> +#endif
>> >> + pxa168_add_nand(&trizeps6_nand_info);
>> >> + platform_add_devices(trizeps6_devices,
>> >> +
>> ARRAY_SIZE(trizeps6_devices));
>> >> +
>> >> + pxa168_add_fb(&trizeps6_lcd_info);
>> >> + pxa168_add_mfu(&trizeps6_eth_data);
>> >> + pxa168_add_twsi(0, NULL,
>> ARRAY_AND_SIZE(trizeps6_i2c_devices));
>> >> + trizeps6_ts_init();
>> >> +}
>> >> +
>> >> +static void __init trizeps6_map_io(void)
>> >> +{
>> >> + mmp_map_io();
>> >> +}
>> >> +
>> >> +MACHINE_START(TRIZEPS6, "PXA168-based Keith & Koep Trizeps VI
>> Development
>> >> Module")
>> >> + /* MAINTAINER("Yupeng Schneider" <
>> yupeng.schneider at googlemail.com>) */
>> >> + .map_io = trizeps6_map_io,
>> >> + .init_irq = pxa168_init_irq,
>> >> + .timer = &pxa168_timer,
>> >> + .init_machine = trizeps6_init,
>> >> +MACHINE_END
>> >> +
>> >> +
>> >> diff --git a/arch/arm/mach-mmp/trizeps6_cpld.c
>> >> b/arch/arm/mach-mmp/trizeps6_cpld.c
>> >> index 0000000..2577b0f
>> >> --- /dev/null
>> >> +++ b/arch/arm/mach-mmp/trizeps6_cpld.c
>> >> @@ -0,0 +1,145 @@
>> >> +/*
>> >> + * linux/arch/arm/mach-mmp/trizeps6_cpld.c
>> >> + *
>> >> + *
>> >> + * Author: Yupeng Schneider
>> >> + * Created: 27 10, 2010
>> >> + * Copyright: Yupeng Schneider
>> >> + *
>> >> + * 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/kernel.h>
>> >> +#include <linux/ioport.h>
>> >> +#include <linux/platform_device.h>
>> >> +#include <linux/device.h>
>> >> +#include <linux/module.h>
>> >> +
>> >> +#include <asm/io.h>
>> >> +#include <asm/delay.h>
>> >> +#include <mach/trizeps6.h>
>> >> +#include <mach/trizeps6_cpld.h>
>> >> +
>> >> +struct cpld_info {
>> >> + struct region {
>> >> + struct resource *res;
>> >> + struct resource *req;
>> >> + void __iomem *iom;
>> >> + unsigned short val;
>> >> + } addr[7];
>> >> +} cpld_info;
>> >> +
>> >> +static struct cpld_info cpld = { { { 0 } } };
>> >> +
>> >> +inline void trizeps6_cpld_writew(unsigned int reg, unsigned short
>> value) +{
>> >> + if ((cpld.addr[reg].iom != NULL))
>> >> + writew(value, cpld.addr[reg].iom);
>> >> +
>> >> +}
>> >> +
>> >> +unsigned short trizeps6_cpld_readw(unsigned int reg)
>> >> +{
>> >> + short value = 0;
>> >> + if (reg != HIBE_S || reg != HIBE_R || reg != PWM || reg !=
>> PSET_S || reg
>> >> != PSET_R) {
>> >> +
>> >> + if ((cpld.addr[reg].iom != NULL))
>> >> + value = readw(cpld.addr[reg].iom);
>> >> + }
>> >> + return value;
>> >> +}
>> >> +EXPORT_SYMBOL(trizeps6_cpld_readw);
>> >> +
>> >> +static int trizeps6_cpld_probe(struct platform_device *pdev)
>> >> +{
>> >> + int i;
>> >> +
>> >> + CPLD_CTRL_R = CPLD_CONTROL_ETHPHY | CPLD_CONTROL_GR;
>> >> +#ifdef STUART_SODIMM
>> >> + CPLD_FTUR_S = CPLD_FEATURE_UART3_SODIMM;
>> >> +#endif
>> >> + for (i = CTRL_S; i <= TTLO_R; i++) {
>> >> + cpld.addr[i].res = platform_get_resource(pdev,
>> IORESOURCE_MEM, i);
>> >> + if (cpld.addr[i].res == NULL) {
>> >> + dev_err(&pdev->dev, "cannot get resource %d
>> area\n", i);
>> >> + return -EIO;
>> >> + }
>> >> + cpld.addr[i].req =
>> request_mem_region(cpld.addr[i].res->start,
>> >> + 2,
>> pdev->name);
>> >> + if (cpld.addr[i].req == NULL) {
>> >> + dev_err(&pdev->dev, "cannot claim addr area
>> %d\n", i);
>> >> + return -EIO;
>> >> + }
>> >> + cpld.addr[i].iom = ioremap(cpld.addr[i].res->start,
>> 2);
>> >> + if (cpld.addr[i].iom == NULL) {
>> >> + dev_err(&pdev->dev, "cannot remap addr area
>> %d\n", i);
>> >> + return -EIO;
>> >> + }
>> >> + switch (i) {
>> >> + case CTRL_R:
>> >> + trizeps6_cpld_writew(CTRL_R, CPLD_CTRL_R);
>> >> + break;
>> >> + case FTUR_S:
>> >> + trizeps6_cpld_writew(FTUR_S, CPLD_FTUR_S);
>> >> + break;
>> >> + default:
>> >> + ;
>> >> +
>> >> + }
>> >> + dev_dbg(&pdev->dev, "mapped region [%d] %08x ->
>> %p\n",
>> i,
>> >> + (int)cpld.addr[i].req->start,
>> cpld.addr[i].iom);
>> >> + }
>> >> +
>> >> +
>> >> + return 0;
>> >> +}
>> >> +
>> >> +static int trizeps6_cpld_remove(struct platform_device *pdev)
>> >> +{
>> >> + dev_dbg(&pdev->dev, "trizeps6_cpld_remove()\n");
>> >> + return 0;
>> >> +}
>> >> +
>> >> +#ifdef CONFIG_PM
>> >> +static int trizeps6_cpld_suspend(struct platform_device *pdev,
>> >> pm_message_t state)
>> >> +{
>> >> + return 0;
>> >> +}
>> >> +
>> >> +static int trizeps6_cpld_resume(struct platform_device *pdev)
>> >> +{
>> >> + return 0;
>> >> +}
>> >> +#endif
>> >> +
>> >> +static struct platform_driver trizeps6_cpld_driver = {
>> >> + .probe = trizeps6_cpld_probe,
>> >> + .remove = trizeps6_cpld_remove,
>> >> +#ifdef CONFIG_PM
>> >> + .suspend = trizeps6_cpld_suspend,
>> >> + .resume = trizeps6_cpld_resume,
>> >> +#endif
>> >> + .driver = {
>> >> + .name = "trizeps6-cpld",
>> >> + },
>> >> +};
>> >> +
>> >> +
>> >> +static int __devinit trizeps6_cpld_init(void)
>> >> +{
>> >> +
>> >> + return platform_driver_register(&trizeps6_cpld_driver);
>> >> +}
>> >> +
>> >> +static void trizeps6_cpld_exit(void)
>> >> +{
>> >> + platform_driver_unregister(&trizeps6_cpld_driver);
>> >> +}
>> >> +
>> >> +arch_initcall(trizeps6_cpld_init);
>> >> +module_exit(trizeps6_cpld_exit);
>> >> +
>> >> +MODULE_AUTHOR("Yupeng Schneider <yupeng.schneider@googlemail.com>");
>> >> +MODULE_DESCRIPTION("Trizeps VI CPLD");
>> >> +MODULE_LICENSE("GPL");
>> >> --
>> >> 1.6.3.3
>> >>
>> >>
>> >>
>> >>
>> >
>>
>
^ 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