Timur Tabi | 1 Dec 2010 01:09
Favicon

Re: [PATCH] hwconfig: Fix handling of env_hwconfig, board_hwconfig, and cpu_hwconfig

On Tue, Nov 30, 2010 at 3:58 PM, Kumar Gala <galak <at> kernel.crashing.org> wrote:
> The handling of env_hwconfig, board_hwconfig, and cpu_hwconfig got
> broken when we removed the boards defining dummy board_hwconfig
> & cpu_hwconfig values.
>
> We fix this by handling the various strings in priority order.  If
> hwconfig_parse returns NULL for a given string we check the next one
> in order (env_hwconfig, board_hwconfig, followed by cpu_hwconfig).
>
> Signed-off-by: Kumar Gala <galak <at> kernel.crashing.org>

I think the P1022DS is broken without this fix, but I can't get this
patch to apply.  Is there a pre-requisite patch that I'm missing?

--

-- 
Timur Tabi
Linux kernel developer at Freescale
Scott Wood | 1 Dec 2010 01:21
Favicon

Re: [PATCH] mpc83xx: remove some dead code, saving space

On Tue, 30 Nov 2010 22:25:11 +0100
Joakim Tjernlund <joakim.tjernlund <at> transmode.se> wrote:

> Scott Wood <scottwood <at> freescale.com> wrote on 2010/11/30 22:17:31:
> >
> > On Tue, 30 Nov 2010 22:13:32 +0100
> > Joakim Tjernlund <joakim.tjernlund <at> transmode.se> wrote:
> >
> > > Scott Wood <scottwood <at> freescale.com> wrote on 2010/11/30 21:50:52:
> > > >
> > > > On Tue, 30 Nov 2010 21:45:19 +0100
> > > > Joakim Tjernlund <joakim.tjernlund <at> transmode.se> wrote:
> > > >
> > > > > On a related note, I am not sure why the I and D cache needs to be flushed,
> > > > > aren't they coherent?
> > > >
> > > > They are not.
> > >
> > > Ah, I figured they would be these days.
> >
> > Nope, I've seen weird stuff happen when I forget to sync the icache
> > even on very recent chips (albeit 85xx and not 83xx).
> >
> > > I doubt one needs to invalidate the icache though?
> > > Better safe than sorry I guess, one could probably optimize it a
> > > little bit though.
> >
> > You need to flush the dcache and then invalidate the icache.
> 
> but if one haven't executed any insn's at the new location yet
(Continue reading)

Timur Tabi | 1 Dec 2010 01:36
Favicon

[PATCH] p1022ds: fix switching of DIU/LBC signals

On the P1022, the pins which drive the video display (DIU) are muxed with the
local bus controller (LBC), so if the DIU is active, the pins need to be
temporarily muxed to LBC whenever accessing NOR flash.

The code which handled this transition is checking and changing the wrong
bits in PMUXCR.

Also add a follow-up read after a write to NOR flash if we're going to
mux back to DIU after the write, as described in the P1022 RM.

Signed-off-by: Timur Tabi <timur <at> freescale.com>
---

I have no idea how this ever worked before.  It's a complete mystery to me.

 board/freescale/p1022ds/diu.c |   45 +++++++++++++++++++++++++++++++++-------
 1 files changed, 37 insertions(+), 8 deletions(-)

diff --git a/board/freescale/p1022ds/diu.c b/board/freescale/p1022ds/diu.c
index 12b40a0..2259384 100644
--- a/board/freescale/p1022ds/diu.c
+++ b/board/freescale/p1022ds/diu.c
 <at>  <at>  -32,6 +32,7  <at>  <at> 

 #define PMUXCR_ELBCDIU_MASK	0xc0000000
 #define PMUXCR_ELBCDIU_NOR16	0x80000000
+#define PMUXCR_ELBCDIU_DIU	0x40000000

 /*
  * DIU Area Descriptor
(Continue reading)

Paulraj, Sandeep | 1 Dec 2010 01:58
Picon
Favicon

Re: Pull request: u-boot-arm (master + next)


> 
> The following changes since commit
> d0d2271f8c62e830ec65fb069b6d12dd708e3e2f:
> 
>   Prepare v2010.12-rc2 (2010-11-28 19:48:11 +0100)
> 
> are available in the git repository at:
>   git://git.denx.de/u-boot-arm.git master
> 
> Dirk Behme (4):
>       OMAP4: SDP4430: Disable CMD_NFS
>       OMAP3: SDP3430: Fix ARM relocation support
>       OMAP3: Zoom1: Fix ARM relocation support
>       OMAP3: Zoom2: Fix ARM relocation support
> 
> Enric Balletbo i Serra (1):
>       ARMV7: OMAP3: Fix build failure for igep0030 machine
> 
> Minkyu Kang (6):
>       Merge branch 'master' of git://git.denx.de/u-boot-arm
>       Merge branch 'master' of git://git.denx.de/u-boot-arm
>       Merge branch 'master' of git://git.denx.de/u-boot-arm
>       S5P: smdkc100: fix for relocation
>       S5P: goni: fix for relocation
>       ARMV7: S5P: timer: get the count_value from register when call
> udelay
> 
> Sanjeev Premi (1):
>       omap3evm: Use GENERATED_GBL_DATA_SIZE
(Continue reading)

Scott Wood | 1 Dec 2010 02:50
Favicon

Re: [PATCH] p1022ds: fix switching of DIU/LBC signals

On Tue, 30 Nov 2010 18:36:25 -0600
Timur Tabi <timur <at> freescale.com> wrote:

>  <at>  <at>  -244,8 +266,15  <at>  <at>  void flash_write64(u64 value, void *addr)
>  
>  	/* There is no __raw_writeq(), so do the write manually */
>  	*(volatile u64 *)addr = value;
> -	if (sw)
> +	if (sw) {
> +		/*
> +		 * To ensure the post-write is completed to eLBC, software must
> +		 * perform a dummy read from one valid address from eLBC space
> +		 * before changing the eLBC_DIU from NOR mode to DIU mode.
> +		 */
> +		__raw_readb(addr);
>  		set_mux_to_diu();
> +	}

Careful with the barriers.

You've got a raw readback, which means it's not going to wait for
completion with the twi/isync hack.

Ordinarily that would be OK, since you only need ordering between the
readb and the first access in set_mux_to_diu().  Unfortunately, that
first access is an 8-bit access, which for some strange reason does
sync differently than 16/32-bit accesses.  The latter do sync+write,
but 8-bit does write+eieio.  So there's no barrier between the read
and the write.

(Continue reading)

Marek Vasut | 1 Dec 2010 03:46
Picon

Re: [PATCH v2] BLOCK: Add freescale IMX51 PATA driver

On Tuesday 30 November 2010 12:15:33 Stefano Babic wrote:
> On 11/30/2010 04:26 AM, Marek Vasut wrote:
> > Signed-off-by: Marek Vasut <marek.vasut <at> gmail.com>
> > ---
> > v2: Use structures instead of defines as Wolfgang proposed
> 
> Hi Marek,
> 
> >  drivers/block/Makefile  |    1 +
> >  drivers/block/mxc_ata.c |  149
> >  +++++++++++++++++++++++++++++++++++++++++++++++ 2 files changed, 150
> >  insertions(+), 0 deletions(-)
> >  create mode 100644 drivers/block/mxc_ata.c
> 
> In which context does this driver run ? I thought to find a similar
> implementation I see, for example, in pata_bfin.c, with entry points to
> read/write data, but I cannot see them. I assume you set only
> CONFIG_CMD_IDE for testing.
> 
> On which board do you plan to add this P-ATA driver ?

On efikamx, I'll soon submit it mainline (when I clean it up enough). Here's the 
relevant part of configuration file (the #define __io is actually the important 
thing):

/*
 * ATA/IDE
 */
#ifdef  CONFIG_CMD_IDE
#define CONFIG_LBA48
(Continue reading)

Reinhard Meyer | 1 Dec 2010 05:59
Picon

[PATCH] AT91: fix EMAC gpio init in at91sam9260_devices.c

The AT91SAM9G20 BOOT ROM apparently initializes PA23 and PA24 to multi drive
(open drain). Revert this, if those pins are going to be used for MII.

Signed-off-by: Reinhard Meyer <u-boot <at> emk-elektronik.de>
---
 arch/arm/cpu/arm926ejs/at91/at91sam9260_devices.c |    5 +++++
 1 files changed, 5 insertions(+), 0 deletions(-)

diff --git a/arch/arm/cpu/arm926ejs/at91/at91sam9260_devices.c b/arch/arm/cpu/arm926ejs/at91/at91sam9260_devices.c
index f699f4d..c1822b7 100644
--- a/arch/arm/cpu/arm926ejs/at91/at91sam9260_devices.c
+++ b/arch/arm/cpu/arm926ejs/at91/at91sam9260_devices.c
 <at>  <at>  -204,6 +204,11  <at>  <at>  void at91_macb_hw_init(void)
 #else
 	at91_set_b_periph(AT91_PIO_PORTA, 23, 0);	/* ETX2 */
 	at91_set_b_periph(AT91_PIO_PORTA, 24, 0);	/* ETX3 */
+#if defined(CONFIG_AT91SAM9G20)
+	/* 9G20 BOOT ROM initializes those pins to multi-drive, undo that */
+	at91_set_pio_multi_drive(AT91_PIO_PORTA, 23, 0);
+	at91_set_pio_multi_drive(AT91_PIO_PORTA, 24, 0);
+#endif
 #endif
 	at91_set_b_periph(AT91_PIO_PORTA, 22, 0);	/* ETXER */
 #endif
--

-- 
1.5.6.5
Wolfgang Denk | 1 Dec 2010 06:34
Picon
Picon
Favicon

Re: [PATCH v2] BLOCK: Add freescale IMX51 PATA driver

Dear Marek Vasut,

In message <201012010346.21897.marek.vasut <at> gmail.com> you wrote:
>
> On efikamx, I'll soon submit it mainline (when I clean it up enough). Here's the 
> relevant part of configuration file (the #define __io is actually the important 
> thing):

Is there a way to do without this?

> #define __io

I mean, these empty defines look pretty bogus to me.

> > CONFIG_MXC_ATA_PIO_MODE is a new parameter, to be set in board
> > configuration file. It should be documented in some ways.
> 
> Indeed ... where if you could point me to an appropriate place ?

In the README, please.

Best regards,

Wolfgang Denk

--

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd <at> denx.de
Disobedience:  The silver lining to the cloud of servitude.
(Continue reading)

Dirk Behme | 1 Dec 2010 06:35

Re: Pull request: u-boot-arm (master + next)

On 30.11.2010 21:49, Wolfgang Denk wrote:
> The following changes since commit d0d2271f8c62e830ec65fb069b6d12dd708e3e2f:
>
>    Prepare v2010.12-rc2 (2010-11-28 19:48:11 +0100)
 > ...

Anybody likes to apply

http://lists.denx.de/pipermail/u-boot/2010-November/081033.html
http://lists.denx.de/pipermail/u-boot/2010-November/081034.html
http://lists.denx.de/pipermail/u-boot/2010-November/082654.html

too? This will fix the build of ca9x4_ct_vxp.

Thanks

Dirk

Gmane