Re: [U-Boot] [PATCH] mmc: fsl_esdhc: Fix hang after 'save' command

[Fleming Andy-AFLEMING]

On May 28, 2013, at 1:09 PM, Fabio Estevam wrote:

> Since commit 48e0b2bd (powerpc/esdhc: Correct judgement for DATA PIO mode) 
> we see mx6 systems to hang after doing a 'save' command.
> 
> Revert this commit since the original 'ifdef' logic from 7b43db92 
> (drivers/mmc/fsl_esdhc.c: fix compiler warnings) was the correct one.
> 
> Reported-by: Tapani Utriainen 
> Signed-off-by: Fabio Estevam 


My apologies. I misread that patch. I found it hard to believe that Wolfgang 
had broken the logic, and that it had been broken for 2 years, but somehow my 
brain insisted that was the case. I now agree with your assessment, and will 
apply your patch.

Haijun, please investigate the problem you were trying to solve with this 
patch, and determine what the actual cause was, and then submit a new patch to 
fix it.


Andy
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH V3 1/4] README: document CONFIG_ENV_IS_IN_MMC

[Fleming Andy-AFLEMING]

I'll take them. It's on my todo list for this week

On Jun 4, 2013, at 14:31, "Stephen Warren"  wrote:

> On 05/23/2013 02:51 PM, Stephen Warren wrote:
>> From: Stephen Warren 
>> 
>> Describe the meaning of CONFIG_ENV_IS_IN_MMC, and all related defines that
>> must or can be set when using that option.
> 
> Andy, do you intend to take these patches for the upcoming release, or
> defer them until the next one? Thanks.
> 

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] : sf: spansion: Add support for S25FL128S

[Fleming Andy-AFLEMING]

On Jun 10, 2013, at 1:34 PM, Jagan Teki wrote:

> Hi,
> 
> Request for few details here.
> 
> I am not understanding why this is applied on tree, [even i din't see
> the applied note on mailing list, may be i am missing]


I've been bad about sending a message when I apply the patches. I'm hesitant to 
do so when I apply dozens of patches at a time, as it adds significant overhead 
to each patch application. Finding the patch email in my inbox is 
time-consuming.



> I was asked Xie Xiaobo to send v2 fo updating the name to
> -   .name = "S25FL129P_64K/S25FL128S",
> +  .name = "S25FL129P_64K/S25FL128S_64K",
> 
> Even i sent a patch on be of Xie Xiaobo
> http://patchwork.ozlabs.org/patch/247607/
> 
> Any comments, was the notion i used on patch was wrong.



Sorry, York Sun submitted a version of the original patch back in March, and it 
got applied May 24. I see now that you got a version in February, which Xiaobo 
responded to May 30. I didn't realize it was under your domain, so I apologize 
(Ah, I see you were added to the list probably just after I looked for who was 
in charge of spi).

Feel free to revert the patch, or modify, as you see fit, and I will avoid 
applying patches to spi in the future. :)

Andy
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] : sf: spansion: Add support for S25FL128S

[Fleming Andy-AFLEMING]

On Jun 11, 2013, at 5:17 PM, Scott Wood wrote:

> On 06/11/2013 05:14:53 PM, Fleming Andy-AFLEMING wrote:
>> On Jun 10, 2013, at 1:34 PM, Jagan Teki wrote:
>> > Hi,
>> >
>> > Request for few details here.
>> >
>> > I am not understanding why this is applied on tree, [even i din't see
>> > the applied note on mailing list, may be i am missing]
>> I've been bad about sending a message when I apply the patches. I'm hesitant 
>> to do so when I apply dozens of patches at a time, as it adds significant 
>> overhead to each patch application. Finding the patch email in my inbox is 
>> time-consuming.
> 
> You can reply directly to the patchwork mbox (assuming that's where you're 
> getting the patch from, if not your inbox).


via something like mutt? I will make an effort to do that.


___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [U-Boot, v2] powerpc/mpc85xx:Disable Debug TLB entry before init_tlbs

[Fleming Andy-AFLEMING]

On Jun 21, 2013, at 3:59 PM, Scott Wood wrote:

> On 06/21/2013 03:38:48 PM, Andy Fleming wrote:
>> On Thu, Jun 13, 2013 at 10:14:00AM +0530, Prabhakar Kushwaha wrote:
>> > init_tlbs() initialize all the TLB entries required for the system.
>> >
>> > So disable DEBUG TLB entry before TLB entries initialization.
>> >
>> > Signed-off-by: Prabhakar Kushwaha 
>> Applied, with fixes.
>> > diff --git a/arch/powerpc/cpu/mpc85xx/cpu_init_early.c 
>> > b/arch/powerpc/cpu/mpc85xx/cpu_init_early.c
>> > index f4403c2..340b063 100644
>> > --- a/arch/powerpc/cpu/mpc85xx/cpu_init_early.c
>> > +++ b/arch/powerpc/cpu/mpc85xx/cpu_init_early.c
>> > @@ -180,5 +180,9 @@ void cpu_init_early_f(void)
>> >
>> >invalidate_tlb(1);
>> >
>> > +#if defined(CONFIG_SYS_PPC_E500_DEBUG_TLB) && !defined(CONFIG_SPL_BUILD)
>> > +  disable_tlb(CONFIG_SYS_PPC_E500_DEBUG_TLB);
>> > +#endif
>> Had to add CONFIG_NAND_SPL here, as well, just for future reference
> 
> Why exclude all SPLs?  Only minimal SPLs skip creating the debug TLB.

The definition of disable_tlb() is excluded when NAND_SPL is defined. It may be 
that the error lies the other way around, but this fixed my build problem.

Andy
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [ANN] v2013.07-rc2

[Fleming Andy-AFLEMING]

On Jul 16, 2013, at 1:56, "Dirk Eibach"  wrote:

> Hi Tom,
> 
> my 4xx series depends on Heikos I2C update, which he did not manage to
> get ready in this release cycle. But he promised he will push it when
> the next merge window opens :)
> The 85xx series should be ready to go.

Ok, I'll put this in today

Andy

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH] mx6: fsl_esdhc: Fix waiting for DMA operation completion

[Fleming Andy-AFLEMING]

On Apr 4, 2013, at 13:12, "Fabio Estevam"  wrote:

> Hi Eric,
> 
> On Wed, Apr 3, 2013 at 8:17 PM, Eric Nelson
>  wrote:
> 
>>> Actually, I'm a little confused by PRSSTAT_DLA checking: currently the
>>> loop exits
>>> when either IRQSTAT_TC occurs _or_ PRSSTAT_DLA flag comes to 0. Is that
>>> correct?
>>> I'm not quite familiar with using this flag, but should the loop exit when
>>> both
>>> IRQSTAT_TC occurs _and_ PRSSTAT_DLA flag comes to 0 (i.e. in current code
>>> '&&'
>>> should be replaced by '||')? And then the modified loop condition (with
>>> DMA check)
>>> would be
>>> 
>>>} while (!(irqstat & IRQSTAT_TC) || !(irqstat & IRQSTAT_DINT) ||
>>>  (esdhc_read32(®s->prsstat) & PRSSTAT_DLA));
>>> 
>>> Can you advise anything on using this flag?
>> 
>> That is weird, and suspect. The reference manual indicates that this
>> bit (Data line active) will go low when the data lines are done with
>> the transaction, but that will happen before the DMA completes, so
>> it seems like a bad way to short-circuit the loop.
>> 
>> Fabio, can you comment on this?
> 
> I am not very familiar with the mmc driver. Adding Andy in case he has
> some insight about it.


Hmm, that does seem weird. I'll look into it.


> 
>> 
>> The code appears to have been like this since the beginning
>> of main-line support for i.MX so there's no history to go on.
>> 
>> The same goes in Freescale's git tree.
> 
> Do you mean FSL U-boot or kernel tree? Is it the same with the
> mainline kernel driver?
> 
> Regards,
> 
> Fabio Estevam
> 

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH] mx6: fsl_esdhc: Fix waiting for DMA operation completion

[Fleming Andy-AFLEMING]

On Apr 4, 2013, at 1:41 PM, Eric Nelson wrote:

> Hi Andrew,
> 
> On 04/04/2013 11:03 AM, Gabbasov, Andrew wrote:
>> Hi Eric,
>> 
>>> From: Eric Nelson [eric.nel...@boundarydevices.com]
>>> Sent: Thursday, April 04, 2013 03:47
>>> To: Gabbasov, Andrew
>>> Cc: u-boot@lists.denx.de; Behme, Dirk - Bosch; Fabio Estevam
>>> Subject: Re: [U-Boot] [PATCH] mx6: fsl_esdhc: Fix waiting for DMA operation 
>>> completion
>>> 
>> 
>> So, do you think the latter (modified) loop condition
>> 
>>  } while (!(irqstat & IRQSTAT_TC) || !(irqstat & IRQSTAT_DINT) ||
>>(esdhc_read32(®s->prsstat) & PRSSTAT_DLA));
>> 
>> will be correct?
>> 
> 
> I think the right thing to do is eliminate the DLA test entirely,
> so the loop condition can be simplified to something like this:
> 
> #define TRANSFER_COMPLETE (IRQSTAT_TC|IRQSTAT_DINT)
> 
>   do {
>   ...
>   } while (TRANSFER_COMPLETE != (irqstat&TRANSFER_COMPLETE));


That looks right to me. I have been known to mistakenly write loops that are 
supposed to wait for two conditions to only wait for one of those. Apparently I 
need remedial boolean logic lessons.


> 
> If there is another part that needs to bail out on PRSSTAT_DLA,
> it seems that the affected part should be the one with the #ifdef


I don't think we need a special case. Just correct logic. :/

Andy
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [RFC] mmc: Properly determine maximum supported bus width

[Fleming Andy-AFLEMING]

Yes, I'm processing my queue today.

On Nov 26, 2012, at 17:27, "Stephen Warren"  wrote:

> On 10/31/2012 11:02 PM, Andy Fleming wrote:
>> At some point, a confusion arose about the use of the bit
>> definitions in host_caps for bus widths, and the value
>> in ext_csd. By coincidence, a simple shift could convert
>> between one and the other:
>> 
>> MMC_MODE_1BIT = 0, EXT_CSD_BUS_WIDTH_1 = 0
>> MMC_MODE_4BIT = 0x100, EXT_CSD_BUS_WIDTH_4 = 1
>> MMC_MODE_8BIT = 0x200, EXT_CSD_BUS_WIDTH_8 = 2
>> 
>> However, as host_caps is a bitmask of supported things,
>> there is not, in fact, a one-to-one correspondence. host_caps
>> is capable of containing MODE_4BIT | MODE_8BIT, so nonsensical
>> things were happening where we would try to set the bus width
>> to 12.
>> 
>> The new code clarifies the very different namespaces:
>> 
>> host_caps/card_caps = bitmask (MMC_MODE_*)
>> ext CSD fields are just an index (EXT_CSD_BUS_WIDTH_*)
>> mmc->bus_width integer number of bits (1, 4, 8)
>> 
>> We create arrays to map between the namespaces, like in Linux.
> 
> Andy, is this patch likely to get merged soon to u-boot.git branch
> master? Unfortunately, some Tegra patches that ideally rely on this
> patch being present have already been applied and merged into
> u-boot-arm.git branch master.
> 

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH] corenet: Disable video on P2020DS

[Fleming Andy-AFLEMING]

On Jan 25, 2013, at 12:50 PM, Tom Rini wrote:

> On Fri, Jan 25, 2013 at 10:38:01AM -0600, Andy Fleming wrote:
> 
>> The P2020DS build had grown too large, and video support isn't enabled
>> in almost any other Freescale board. Disabling it allows us to keep
>> building, and provides options for reenabling it later.
>> 
>> Signed-off-by: Andy Fleming 
> 
> Now we may start having dead code around, yes?  Can you perhaps get away
> with making this be disable video or something else and add a
> P2020DS_video boards.cfg entry or similar?  Thanks!

There doesn't appear to be any 2020-specific code in drivers/video/. The truth 
is, I doubt the code gets more than compile-tested by the setting being there. 
Also, as noted, P1022 defines it, in addition to MPC8536, MPC8544, MPC8572, 
MPC8610, and MPC8641. I'd rather not hack up a "video" config just for P2020, 
if possible.

Andy
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] Please pull u-boot-mpc85xx.git

[Fleming Andy-AFLEMING]

>> 
>> 
>> create mode 100644 drivers/net/fm/b4860.c
>> create mode 100644 include/configs/B4860QDS.h
>> create mode 100644 include/configs/BSC9132QDS.h
> 
> So, I see:
> bsc9132qds.c: In function 'ft_board_setup':
> bsc9132qds.c:349:19: warning: variable 'cpu' set but not used
> [-Wunused-but-set-variable]
> 
> On the various BSC boards.  Do you want me to take it now, or after
> you've fixed it up?


Argh. That apparently wasn't seen by my compiler setup. I'll fix it. What 
compiler are you using?


Andy


___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] Possible MMC subsystem bug

[Fleming Andy-AFLEMING]

I'll need to double-check the spec, but I believe the BUSY bit has the opposite 
meaning of common sense.

On Jan 26, 2013, at 22:32, "Marek Vasut"  wrote:

> Hi Andy,
> 
> I was going through the MMC code, trying to get Phison 8007 SD-to-NAND bridge 
> working (don't ask please, this chip's sole existence defies any logic).
> 
> So, I found the following code and I was wondering if the following patch is 
> not 
> needed. Maybe my brain is just giving up though. Give it some thought please 
> and 
> let me know, thanks!
> 
> diff --git a/drivers/mmc/mmc.c b/drivers/mmc/mmc.c
> index 72e8ce6..94926ca 100644
> --- a/drivers/mmc/mmc.c
> +++ b/drivers/mmc/mmc.c
> @@ -475,8 +474,11 @@ static int sd_send_op_cond(struct mmc *mmc)
>if (err)
>return err;
> 
> +   if (!(cmd.response[0] & OCR_BUSY))
> +   break;
> +
>udelay(1000);
> -   } while ((!(cmd.response[0] & OCR_BUSY)) && timeout--);
> +   } while (timeout--);
> 
>if (timeout <= 0)
>return UNUSABLE_ERR;
> 

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] small but important doc patch

[Fleming Andy-AFLEMING]

On Feb 19, 2010, at 4:59, "Frans Meulenbroeks"  wrote:

> Dear all,
>
> Attached a patch for doc/README.mpc8536ds.
> This patch corrects small mistake in the register list.
> These registers are 32 bits and this one starts at c not e
>
> When using the ...c address I can boot from sd, when using the ...e
> address I cannot.
>
> *** README.mpc8536ds.orig2010-02-18 15:29:07.0 +0100
> --- README.mpc8536ds2010-02-19 11:25:22.0 +0100
> ***
> *** 98,104 
> | 0x90-0x93 | 0xFF72 | Config Addr 3   |
> | 0x94-0x97 | 0x8001 | Config Data 3   |
> 
> !| 0x98-0x9b | 0xFF72e40e | Config Addr 4   |
> | 0x9c-0x9f | 0x0040 | Config Data 4   |


Please create patches using git, if possible.  At least use diff -u,  
so it can be applied as a patch


___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH V2 0/2] add sdhci generic framework

[Fleming Andy-AFLEMING]

On Jul 12, 2011, at 22:54, "Lei Wen"  wrote:

> Hi Andy,
> 
> Could this version be accepted to be merged?


I'm working on merging these (and other) patches this weekend.

Andy

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH V4 0/5] fix and enhancement patches for sdhci

[Fleming Andy-AFLEMING]

Sorry for the delay, I am currently processing my patch backlog. I will be 
applying them today.

On Nov 2, 2011, at 1:40, "Lei Wen"  wrote:

> Hi Andy,
> 
> On Tue, Oct 18, 2011 at 10:58 PM, Lei Wen  wrote:
>> Hi Andy,
>> 
>> On Sat, Oct 8, 2011 at 10:14 PM, Lei Wen  wrote:
>>> This seris fix several issue like flush cache and build warning. And
>>> give this generic driver enhancement for timeout when transferring data
>>> and additional structure member to access in platform self driver.
>>> 
>>> Changelog:
>>> V2: code style change.
>>> V3: add another fix of sdma handling bug including in this series
>>> V4: minor code style change
>>> 
>>> Lei Wen (5):
>>>  mmc: sdhci: fix cache flush
>>>  mmc: sdhci: fix build warning
>>>  mmc: sdhci: add mmc structure for host
>>>  mmc: sdhci: add timeout for data transfer
>>>  mmc: sdhci: fix sdma bug for large file transfer
>>> 
>>>  drivers/mmc/sdhci.c |   14 +++---
>>>  include/sdhci.h |6 ++
>>>  2 files changed, 17 insertions(+), 3 deletions(-)
>>> 
>> 
>> Any comment for this patch series?
>> 
> 
> Any comments?
> 
> Thanks,
> Lei
> 

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] Please pull u-boot-mpc85xx.git

[Fleming Andy-AFLEMING]

>> include/configs/P1022DS.h |  132 ++--
>> include/configs/corenet_ds.h  |1 +
>> 28 files changed, 833 insertions(+), 72 deletions(-)
>> create mode 100644 board/freescale/p1022ds/spl_minimal.c
>> create mode 100644 doc/README.p1010rdb
>> create mode 100644 doc/README.ramboot-ppc85xx
> 
> With the patch I just sent to fix P1022DS as well, applied to
> u-boot/master, thanks!

Ah, nice catch, thanks!

Andy

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [Patch v2, batch 2 17/23] powerpc/85xx: add missing QMAN frequency calculation

[Fleming Andy-AFLEMING]

Ah, ok, makes sense.

On May 7, 2013, at 18:18, "sun york-R58495"  wrote:

> On 05/07/2013 04:04 PM, Andy Fleming wrote:
>> 
>> 
>> 
>> On Mon, Mar 25, 2013 at 12:33 PM, York Sun > > wrote:
>> 
>>From: Shaohui Xie >>
>> 
>>When CONFIG_SYS_FSL_QORIQ_CHASSIS2 is not defined, QMAN frequency
>>will not
>>be initialized, and QMAN will have a wrong frequency display.
>> 
>>Signed-off-by: Shaohui Xie >>
>>---
>> arch/powerpc/cpu/mpc85xx/speed.c |4 
>> 1 file changed, 4 insertions(+)
>> 
>>diff --git a/arch/powerpc/cpu/mpc85xx/speed.c
>>b/arch/powerpc/cpu/mpc85xx/speed.c
>>index 9fc7b54..f00b1ab 100644
>>--- a/arch/powerpc/cpu/mpc85xx/speed.c
>>+++ b/arch/powerpc/cpu/mpc85xx/speed.c
>>@@ -293,6 +293,10 @@ void get_sys_info (sys_info_t * sysInfo)
>> #endif
>> #endif
>> 
>>+#ifdef CONFIG_SYS_DPAA_QBMAN
>>+   sysInfo->freqQMAN = sysInfo->freqSystemBus / 2;
>>+#endif
>>+
>> 
>> 
>> 
>> Can we just move the original copy of the above lines out of the #ifdef?
>> I don't see any reason to do it the same way in two places.
> You mean delete #ifdef? It will have a compiling error, won't it? See
> include/e500.h, the freqQMAN is withing #ifdef.
> 
> York
> 

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] Please pull u-boot-mpc85xx.git

[Fleming Andy-AFLEMING]

On May 10, 2013, at 10:23 AM, Tom Rini wrote:

> On Thu, May 09, 2013 at 05:20:32PM -0500, Andy Fleming wrote:
> 
>> The following changes since commit 4e779ad2e54e39d5343c8c83b4fc686a7bb16859:
>> 
>>  gpio: Add support for microblaze xilinx GPIO (2013-05-09 11:20:08 +0200)
>> 
>> are available in the git repository at:
>> 
>>  git://www.denx.de/git/u-boot-mpc85xx.git master
>> 
>> for you to fetch changes up to a9c81eaa54f6ef0976cf15065cd3efc9430fdca8:
>> 
>>  powerpc: Add T4160QDS (2013-05-09 17:07:39 -0500)
> [snip]
>> Roy ZANG (1):
>>  powerpc/pcie: add PCIe version 3.x support
> 
> This change breaks a handful of platforms thusly:
> Configuring for MPC8315ERDB_NAND - Board: MPC8315ERDB, Options:
> NAND_U_BOOT
> pcie.c:315:34: error: 'PCI_LTSSM' undeclared (first use in this
> function)
> pcie.c:316:15: error: 'PCI_LTSSM_L0' undeclared (first use in this
> function)
> 
> And from MAKEALL:
> Boards compiled: 637
> Boards with errors: 7 ( mpc8308_p1m MPC8315ERDB_NAND MPC8315ERDB
> MPC837XERDB MPC837XEMDS_HOST MERGERBOX MPC8308RDB )
> 
> Please fix, thanks!


Ugh, sorry. I even looked very skeptically at that, and decided to trust the 
change despite my misgivings. I will fix.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 03/21] fsl_ifc: add support for different IFC bank count

[Fleming Andy-AFLEMING]

On May 14, 2013, at 3:59, "Hu Mingkai-B21284" 
mailto:b21...@freescale.com>> wrote:

Hi Andy,

Please find my replies in line.

Thanks,
Mingkai


There's no IFC controller instead of eLBC controller on some platforms,
such as MPC8536, P2041, P3041, P4080 etc, so there's no macro definition
for the number of IFC chip select(CONFIG_SYS_FSL_IFC_BANK_COUNT) which
is used in the IFC controller header file fsl_ifc.h on these platforms.


This paragraph is pretty confusing. Is this just explaining that IFC_BANK_COUNT 
isn't being defined for devices that don't use IFC? Or is it explaining why you 
have to guard fsl_ifc.h with a #ifdef?
[Mingkai] Both. Some devices doesn’t use IFC, thus, there’s no IFC_BANK_COUNT 
for these devices. While some common files include fsl_ifc.h, which needs 
IFC_BANK_COUNT definition, that’s the reason why I have to guard fsl_ifc.h. I 
will change it to the following:

3. Guard fsl_ifc.h with CONFIG_FSL_IFC to eliminate the compile error on some 
devices that doesn’t have IFC controller.


That's good, thanks


diff --git a/arch/powerpc/include/asm/fsl_ifc.h 
b/arch/powerpc/include/asm/fsl_ifc.h
index ba41b73..debcb6b 100644
--- a/arch/powerpc/include/asm/fsl_ifc.h
+++ b/arch/powerpc/include/asm/fsl_ifc.h
@@ -21,6 +21,7 @@
 #ifndef __ASM_PPC_FSL_IFC_H
 #define __ASM_PPC_FSL_IFC_H

+#ifdef CONFIG_FSL_IFC
 #include 
 #include 

[...]

@@ -907,6 +910,22 @@ struct fsl_ifc_gpcm {
u32 res4[0x1F3];
 };

+#ifdef CONFIG_SYS_FSL_IFC_BANK_COUNT
+#if (CONFIG_SYS_FSL_IFC_BANK_COUNT <= 8)
+#define CONFIG_SYS_FSL_IFC_CSPR_RES \
+   (0x25 - CONFIG_SYS_FSL_IFC_BANK_COUNT * 3)
+#define CONFIG_SYS_FSL_IFC_AMASK_RES \
+   (0x24 - CONFIG_SYS_FSL_IFC_BANK_COUNT * 3)
+#define CONFIG_SYS_FSL_IFC_CSOR_RES \
+   (0x24 - CONFIG_SYS_FSL_IFC_BANK_COUNT * 3)
+#define CONFIG_SYS_FSL_IFC_FTIM_RES \
+   (0x90 - CONFIG_SYS_FSL_IFC_BANK_COUNT * 0xc)


These aren't really config values. They are values derived from a CONFIG value, 
and they only have local scope (so there's no need for the very global scoping 
of the names).

Also... Are these correct? 0x25 is a strange amount of gap in register space.
[Mingkai]They’re correct. I’ve test it on T4, C293QDS and P1010RDB platform 
when I submitted this patch.
The value 0x25 is caused by the fact that the 0x25 is represents the length of 
cspr (148 bytes) in unit 4 bytes.
Here is the magic math: 148 / 4 = 37 = 0x25

All that aside, I think we should just define the register offsets to cover all 
existing (or even predicted) registers, and make the gap hard-coded as before. 
There's no real advantage to specifying only as many as are implemented, and 
this method seems ripe for potential bugs in the future.

[Mingkai] I modified the code as follows,

First define the different register space length in bytes as follows:

#define IFC_CSPR_REG_LEN148
#define IFC_AMASK_REG_LEN   140
#define IFC_CSOR_REG_LEN140
#define IFC_FTIM_REG_LEN576

Then in the struct, use the register space length minus the actual used space 
and get the reserved space as the red line indicates.

struct fsl_ifc {
u32 ifc_rev;
u32 res1[0x2];
struct {
u32 cspr_ext;
u32 cspr;
u32 res2;
} cspr_cs[CONFIG_SYS_FSL_IFC_BANK_COUNT];
u32 res3[IFC_CSPR_REG_LEN - sizeof(cspr_cs)];


That's a bit clearer. However, it needs to be u8 if you are going to specify 
bytes.


struct {
u32 amask;
u32 res4[0x2];
} amask_cs[CONFIG_SYS_FSL_IFC_BANK_COUNT];
u32 res5[IFC_AMASK_REG_LEN - sizeof(amask_cs)];
struct {
u32 csor;
u32 csor_ext;
u32 res6;
} csor_cs[CONFIG_SYS_FSL_IFC_BANK_COUNT];
u32 res7[IFC_CSOR_REG_LEN - sizeof(csor_cs)];
struct {
u32 ftim[4];
u32 res8[0x8];
} ftim_cs[CONFIG_SYS_FSL_IFC_BANK_COUNT];
u32 res9[IFC_FTIM_REG_LEN - sizeof(ftim_cs)];
}

BTW, the patch can’t be applied to your mpc85xx public tree cleanly, so if you 
think this modification is ok, I will submit a new patch based on the latest 
git tree base.

Ok, thanks!

Andy
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH] fsl_esdhc: Correcting esdhc timeout counter calculation

[Fleming Andy-AFLEMING]

On Feb 24, 2011, at 23:35, "Wolfgang Denk"  wrote:

> Dear Andy Fleming,
> 
> In message  you 
> wrote:
>> 
>> Yeah, that took me a while, too.  Maybe we should update it to make clear:
>> 
>> 1) The formula ends up being (2^(13 + timeout))/mmc->trans_speed = (1/4) 
>> seconds
>> --> 2^(13 + timeout) = mmc->trans_speed/4
>> --> 13 + timeout = log2(mmc->trans_speed/4)
>> ...etc
> 
> Does this not depend on the units used for speed, and thus in the end
> on CONFIC_SYS_HZ ?


No, but that wasn't apparent because I didn't mention the units of 
2^(13+timeout).  It is in units of sd clocks.

So: num sd clocks = (sd clocks per sec) * 0.25 sec = mmc->tran_speed/4 = 
2^(13+regval).

Now, it is true that the actual speed of the sd clock is going to depend on 
CONFIG_SYS_HZ, in that a tran_speed of 25MHz may not be perfectly achievable 
with available dividers, but this code is not taking that into account, and the 
fact that it's rounding up to the next power of two should take care of that.

Andy
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 2/7] tsec: arrange the code to avoid useless function declaration

[Fleming Andy-AFLEMING]

Ah, I didnt see it was already in next

On Mar 31, 2011, at 3:13, "Kumar Gala"  wrote:

> 
> On Mar 29, 2011, at 2:30 PM, Andy Fleming wrote:
> 
>> From: Mingkai Hu 
>> 
>> Signed-off-by: Mingkai Hu 
>> Acked-by: Andy Fleming 
>> Signed-off-by: Kumar Gala 
>> ---
>> drivers/net/tsec.c |  857 
>> +---
>> 1 files changed, 416 insertions(+), 441 deletions(-)
> 
> I'm concerned this differs from the version in 85xx 'next'
> 
> - k

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] Please pull u-boot-mpc85xx.git

[Fleming Andy-AFLEMING]

Ah, I knew there was one more I needed to send a mail about. The 5040 patch 
wouldn't apply anymore. Could you rebase? I was unable to determine how to fix 
it. The CRC patch met with fierce opposition, so I haven't applied it.

On Oct 22, 2012, at 20:23, "Tabi Timur-B04825"  wrote:

> On Mon, Oct 22, 2012 at 5:36 PM, Andy Fleming  wrote:
> 
>> Timur Tabi (4):
>>  powerpc/mpc85xx: fix Unicode characters in release.S
>>  powerpc/85xx: define SRIO LIODN functions only if SRIO is defined
>>  powerpc/85xx: move SRIO configuration out of corenet_ds.h
>>  powerpc/85xx: Add P5040 processor support
> 
> There are two other patches in Patchwork from me that are delegated to
> you.  What about those?
> 
> http://patchwork.ozlabs.org/patch/189587/
> http://patchwork.ozlabs.org/patch/170753/
> 
> -- 
> Timur Tabi
> Linux kernel developer at Freescale

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [u-boot-release] [PATCH] powerpc/mpc8xxx: Fix compiling error caused in DDR driver

[Fleming Andy-AFLEMING]

On Nov 7, 2012, at 5:47 PM, York Sun wrote:

> mpc86xx platforms should use CONFIG_SYS_MPC86xx_DDR2_ADDR in utils.c
> if applicable.
> 
> Signed-off-by: York Sun 
> ---
> arch/powerpc/cpu/mpc8xxx/ddr/util.c |4 
> 1 file changed, 4 insertions(+)
> 
> diff --git a/arch/powerpc/cpu/mpc8xxx/ddr/util.c 
> b/arch/powerpc/cpu/mpc8xxx/ddr/util.c
> index 940..9a07d9d 100644
> --- a/arch/powerpc/cpu/mpc8xxx/ddr/util.c
> +++ b/arch/powerpc/cpu/mpc8xxx/ddr/util.c
> @@ -152,7 +152,11 @@ void board_add_ram_info(int use_default)
> 
> #if CONFIG_NUM_DDR_CONTROLLERS >= 2
>   if (!(sdram_cfg & SDRAM_CFG_MEM_EN)) {
> +#ifdef CONFIG_MPC86xx
> + ddr = (void __iomem *)CONFIG_SYS_MPC86xx_DDR2_ADDR;
> +#else
>   ddr = (void __iomem *)CONFIG_SYS_MPC85xx_DDR2_ADDR;
> +#endif


Argh, I submitted a patch to fix this more completely, but haven't applied it, 
yet. See: http://patchwork.ozlabs.org/patch/193611/


Andy
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v3 2/2] EXYNOS: mmc: support DesignWare Controller for Samsung-SoC

[Fleming Andy-AFLEMING]

I got buried in other work. I should get to this by the end of the week

On Nov 21, 2012, at 22:04, "Jaehoon Chung"  wrote:

> Dear Andy,
> 
> Do you have any opinion about this patch?
> If you didn't have any others, could you apply this patch at u-boot-mmc 
> repository?
> 
> Best Regards,
> Jaehoon Chung
> 
> On 10/23/2012 08:11 PM, Minkyu Kang wrote:
>> Dear Jaehoon and Andy,
>> 
>> On 23 October 2012 19:02, Jaehoon Chung  wrote:
>>> Dear, Mr.Kang
>>> 
>>> Could you merge this patch?
>>> This patch is samsung specific file.
>>> DesignWare controller has merged at u-boot-mmc repository.
>>> If Mr.Kang can't merge this, could Andy merge this?
>> 
>> This patch have dependency of dw-mmc patch. (because of Makefile)
>> It should be merged to Andy's tree.
>> 
>> Andy,
>> I've delegate this patch to you.
>> http://patchwork.ozlabs.org/patch/191723/
>> Please check.
>> 
>> Thanks.
>> Minkyu Kang.
> 
> 

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot