RE: [PATCH SDK1.2 1/3] powerpc/fsl-pci: Unify pci/pcie initialization code

2012-01-09 Thread Jia Hongtao-B38951
Hi Kumar,
Do you have any idea on this series of patches?
Looking forward to your answer.
Thanks.

--Jia Hongtao.

-Original Message-
From: Jia Hongtao-B38951 
Sent: Wednesday, December 21, 2011 3:11 PM
To: linuxppc-dev@lists.ozlabs.org
Cc: Li Yang-R58472; Gala Kumar-B11780; Jia Hongtao-B38951
Subject: [PATCH SDK1.2 1/3] powerpc/fsl-pci: Unify pci/pcie initialization code

We unified the Freescale pci/pcie initialization by changing the fsl_pci to a 
platform driver.

In previous version pci/pcie initialization is in platform code which 
Initialize pci bridge base on EP/RC or host/agent settings.

Signed-off-by: Jia Hongtao 
Signed-off-by: Li Yang 
---
 arch/powerpc/platforms/85xx/p1022_ds.c |   39 +++
 arch/powerpc/sysdev/fsl_pci.c  |   53 
 2 files changed, 65 insertions(+), 27 deletions(-)

diff --git a/arch/powerpc/platforms/85xx/p1022_ds.c 
b/arch/powerpc/platforms/85xx/p1022_ds.c
index 2bf4342..41de2c1 100644
--- a/arch/powerpc/platforms/85xx/p1022_ds.c
+++ b/arch/powerpc/platforms/85xx/p1022_ds.c
@@ -277,32 +277,9 @@ void __init mpc85xx_smp_init(void);
  */
 static void __init p1022_ds_setup_arch(void)  { -#ifdef CONFIG_PCI
-   struct device_node *np;
-#endif
-   dma_addr_t max = 0x;
-
if (ppc_md.progress)
ppc_md.progress("p1022_ds_setup_arch()", 0);
 
-#ifdef CONFIG_PCI
-   for_each_compatible_node(np, "pci", "fsl,p1022-pcie") {
-   struct resource rsrc;
-   struct pci_controller *hose;
-
-   of_address_to_resource(np, 0, &rsrc);
-
-   if ((rsrc.start & 0xf) == 0x8000)
-   fsl_add_bridge(np, 1);
-   else
-   fsl_add_bridge(np, 0);
-
-   hose = pci_find_hose_for_OF_device(np);
-   max = min(max, hose->dma_window_base_cur +
- hose->dma_window_size);
-   }
-#endif
-
 #if defined(CONFIG_FB_FSL_DIU) || defined(CONFIG_FB_FSL_DIU_MODULE)
diu_ops.get_pixel_format= p1022ds_get_pixel_format;
diu_ops.set_gamma_table = p1022ds_set_gamma_table;
@@ -316,11 +293,8 @@ static void __init p1022_ds_setup_arch(void)  #endif
 
 #ifdef CONFIG_SWIOTLB
-   if (memblock_end_of_DRAM() > max) {
+   if (memblock_end_of_DRAM() > 0x)
ppc_swiotlb_enable = 1;
-   set_pci_dma_ops(&swiotlb_dma_ops);
-   ppc_md.pci_dma_dev_setup = pci_dma_dev_setup_swiotlb;
-   }
 #endif
 
pr_info("Freescale P1022 DS reference board\n"); @@ -339,6 +313,17 @@ 
static int __init p1022_ds_publish_devices(void)  }  
machine_device_initcall(p1022_ds, p1022_ds_publish_devices);
 
+static struct of_device_id __initdata p1022_pci_ids[] = {
+   { .compatible = "fsl,p1022-pcie", },
+   {},
+};
+
+static int __init p1022_ds_publish_pci_device(void) {
+   return of_platform_bus_probe(NULL, p1022_pci_ids, NULL); } 
+machine_arch_initcall(p1022_ds, p1022_ds_publish_pci_device);
+
 machine_arch_initcall(p1022_ds, swiotlb_setup_bus_notifier);
 
 /*
diff --git a/arch/powerpc/sysdev/fsl_pci.c b/arch/powerpc/sysdev/fsl_pci.c 
index 4ce547e..a0f305d 100644
--- a/arch/powerpc/sysdev/fsl_pci.c
+++ b/arch/powerpc/sysdev/fsl_pci.c
@@ -712,3 +712,56 @@ u64 fsl_pci_immrbar_base(struct pci_controller *hose)
 
return 0;
 }
+
+static const struct of_device_id pci_ids[] = {
+   { .compatible = "fsl,mpc8540-pci", },
+   { .compatible = "fsl,mpc8548-pcie", },
+   { .compatible = "fsl,p1022-pcie", },
+   {},
+};
+
+static int __devinit fsl_pci_probe(struct platform_device *pdev) {
+   struct pci_controller *hose;
+
+   if (of_match_node(pci_ids, pdev->dev.of_node)) {
+   struct resource rsrc;
+   of_address_to_resource(pdev->dev.of_node, 0, &rsrc);
+   if ((rsrc.start & 0xf) == 8000)
+   fsl_add_bridge(pdev->dev.of_node, 1);
+   else
+   fsl_add_bridge(pdev->dev.of_node, 0);
+
+#ifdef CONFIG_SWIOTLB
+   hose = pci_find_hose_for_OF_device(pdev->dev.of_node);
+   /*
+* if we couldn't map all of DRAM via the dma windows
+* we need SWIOTLB to handle buffers located outside of
+* dma capable memory region
+*/
+   if (memblock_end_of_DRAM() > hose->dma_window_base_cur
+   + hose->dma_window_size) {
+   ppc_swiotlb_enable = 1;
+   set_pci_dma_ops(&swiotlb_dma_ops);
+   ppc_md.pci_dma_dev_setup = pci_dma_dev_setup_swiotlb;
+   }
+#endif
+
+   }
+
+   return 0;
+}
+
+static struct platform_driver fsl_pci_driver = {
+   .driver = {
+   .name = "fsl-pci",
+   .of_match_table = pci_ids,
+   },
+   .probe = fsl_pci_probe,
+};
+
+static int __init fsl_pci_init(v

Re: [SDK v1.2][PATCH 2/2 v3] powerpc/85xx: Added P1021RDB-PC Platform support

2012-01-09 Thread Xu Jiucheng
I'm sorry, please ignore this email.

Thanks & Best Regards 
Jiucheng

在 2012-01-09Mon的 14:53 +0800,Xu Jiucheng写道:
> Signed-off-by: Xu Jiucheng 
> ---
>  arch/powerpc/platforms/85xx/mpc85xx_rdb.c |   25 +
>  1 files changed, 25 insertions(+), 0 deletions(-)
> 
> diff --git a/arch/powerpc/platforms/85xx/mpc85xx_rdb.c 
> b/arch/powerpc/platforms/85xx/mpc85xx_rdb.c
> index 9feccbb..0c32668 100644
> --- a/arch/powerpc/platforms/85xx/mpc85xx_rdb.c
> +++ b/arch/powerpc/platforms/85xx/mpc85xx_rdb.c
> @@ -113,6 +113,7 @@ static void __init mpc85xx_rdb_setup_arch(void)
>  
>  machine_device_initcall(p2020_rdb, mpc85xx_common_publish_devices);
>  machine_device_initcall(p1020_rdb, mpc85xx_common_publish_devices);
> +machine_device_initcall(p1021_rdb_pc, mpc85xx_common_publish_devices);
>  
>  /*
>   * Called very early, device-tree isn't unflattened
> @@ -135,6 +136,15 @@ static int __init p1020_rdb_probe(void)
>   return 0;
>  }
>  
> +static int __init p1021_rdb_pc_probe(void)
> +{
> + unsigned long root = of_get_flat_dt_root();
> +
> + if (of_flat_dt_is_compatible(root, "fsl,P1021RDB-PC"))
> + return 1;
> + return 0;
> +}
> +
>  define_machine(p2020_rdb) {
>   .name   = "P2020 RDB",
>   .probe  = p2020_rdb_probe,
> @@ -162,3 +172,18 @@ define_machine(p1020_rdb) {
>   .calibrate_decr = generic_calibrate_decr,
>   .progress   = udbg_progress,
>  };
> +
> +define_machine(p1021_rdb_pc) {
> + .name   = "P1021 RDB-PC",
> + .probe  = p1021_rdb_pc_probe,
> + .setup_arch = mpc85xx_rdb_setup_arch,
> + .init_IRQ   = mpc85xx_rdb_pic_init,
> +#ifdef CONFIG_PCI
> + .pcibios_fixup_bus  = fsl_pcibios_fixup_bus,
> +#endif
> + .get_irq= mpic_get_irq,
> + .restart= fsl_rstcr_restart,
> + .calibrate_decr = generic_calibrate_decr,
> + .progress   = udbg_progress,
> +};
> +



___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [SDK v1.2][PATCH 1/2 v3] powerpc/85xx: Add dts for P1021RDB-PC board

2012-01-09 Thread Xu Jiucheng
I'm sorry, please ignore this email.

Thanks & Best Regards
Jiucheng

在 2012-01-09Mon的 14:53 +0800,Xu Jiucheng写道:
> P1021RDB-PC Overview
> -
> 1Gbyte DDR3 (on board DDR)
> 16Mbyte NOR flash
> 32Mbyte eSLC NAND Flash
> 256 Kbit M24256 I2C EEPROM
> 128 Mbit SPI Flash memory
> Real-time clock on I2C bus
> SD/MMC connector to interface with the SD memory card
> PCIex
> - x1 PCIe slot or x1 PCIe to dual SATA controller
> - x1 mini-PCIe slot
> USB 2.0
> - ULPI PHY interface: SMSC USB3300 USB PHY and Genesys Logic’s GL850A
> - Two USB2.0 Type A receptacles
> - One USB2.0 signal to Mini PCIe slot
> eTSEC1: Connected to RGMII PHY VSC7385
> eTSEC2: Connected to SGMII PHY VSC8221
> eTSEC3: Connected to SGMII PHY AR8021
> DUART interface: supports two UARTs up to 115200 bps for console display
> 
> Signed-off-by: Matthew McClintock 
> Signed-off-by: Xu Jiucheng 
> ---
>  arch/powerpc/boot/dts/fsl/p1021si-post.dtsi |4 +
>  arch/powerpc/boot/dts/p1021rdb.dts  |   96 +++
>  arch/powerpc/boot/dts/p1021rdb.dtsi |  236 
> +++
>  arch/powerpc/boot/dts/p1021rdb_36b.dts  |   96 +++
>  4 files changed, 432 insertions(+), 0 deletions(-)
>  create mode 100644 arch/powerpc/boot/dts/p1021rdb.dts
>  create mode 100644 arch/powerpc/boot/dts/p1021rdb.dtsi
>  create mode 100644 arch/powerpc/boot/dts/p1021rdb_36b.dts
> 
> diff --git a/arch/powerpc/boot/dts/fsl/p1021si-post.dtsi 
> b/arch/powerpc/boot/dts/fsl/p1021si-post.dtsi
> index 38ba54d..b7929c9 100644
> --- a/arch/powerpc/boot/dts/fsl/p1021si-post.dtsi
> +++ b/arch/powerpc/boot/dts/fsl/p1021si-post.dtsi
> @@ -144,6 +144,10 @@
>  /include/ "pq3-usb2-dr-0.dtsi"
>  
>  /include/ "pq3-esdhc-0.dtsi"
> + sdhc@2e000 {
> + sdhci,auto-cmd12;
> + };
> +
>  /include/ "pq3-sec3.3-0.dtsi"
>  
>  /include/ "pq3-mpic.dtsi"
> diff --git a/arch/powerpc/boot/dts/p1021rdb.dts 
> b/arch/powerpc/boot/dts/p1021rdb.dts
> new file mode 100644
> index 000..90b6b4c
> --- /dev/null
> +++ b/arch/powerpc/boot/dts/p1021rdb.dts
> @@ -0,0 +1,96 @@
> +/*
> + * P1021 RDB Device Tree Source
> + *
> + * Copyright 2011 Freescale Semiconductor Inc.
> + *
> + * Redistribution and use in source and binary forms, with or without
> + * modification, are permitted provided that the following conditions are 
> met:
> + * * Redistributions of source code must retain the above copyright
> + *   notice, this list of conditions and the following disclaimer.
> + * * Redistributions in binary form must reproduce the above copyright
> + *   notice, this list of conditions and the following disclaimer in the
> + *   documentation and/or other materials provided with the distribution.
> + * * Neither the name of Freescale Semiconductor nor the
> + *   names of its contributors may be used to endorse or promote products
> + *   derived from this software without specific prior written 
> permission.
> + *
> + *
> + * ALTERNATIVELY, this software may be distributed under the terms of the
> + * GNU General Public License ("GPL") as published by the Free Software
> + * Foundation, either version 2 of that License or (at your option) any
> + * later version.
> + *
> + * THIS SOFTWARE IS PROVIDED BY Freescale Semiconductor "AS IS" AND ANY
> + * EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED
> + * WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE
> + * DISCLAIMED. IN NO EVENT SHALL Freescale Semiconductor BE LIABLE FOR ANY
> + * DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES
> + * (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR 
> SERVICES;
> + * LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED 
> AND
> + * ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
> + * (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF 
> THIS
> + * SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
> + */
> +
> +/include/ "fsl/p1021si-pre.dtsi"
> +/ {
> + model = "fsl,P1021RDB";
> + compatible = "fsl,P1021RDB-PC";
> +
> + memory {
> + device_type = "memory";
> + };
> +
> + lbc: localbus@ffe05000 {
> + reg = <0 0xffe05000 0 0x1000>;
> +
> + /* NOR, NAND Flashes and Vitesse 5 port L2 switch */
> + ranges = <0x0 0x0 0x0 0xef00 0x0100
> +   0x1 0x0 0x0 0xff80 0x0004
> +   0x2 0x0 0x0 0xffb0 0x0002>;
> + };
> +
> + soc: soc@ffe0 {
> + ranges = <0x0 0x0 0xffe0 0x10>;
> + };
> +
> + pci0: pcie@ffe09000 {
> + ranges = <0x200 0x0 0xa000 0 0xa000 0x0 0x2000
> +   0x100 0x0 0x 0 0xffc1 0x0 0x1>;
> + reg = <0 0xffe09000 0 0x1000>;
> + pcie@0 {
> + ranges = <0x200 0x0

Re: [SDK v1.2][PATCH 1/2 v3] powerpc/85xx: Add dts for P1021RDB-PC board

2012-01-09 Thread Xu Jiucheng
在 2012-01-09Mon的 14:54 -0600,Scott Wood写道:
> On 01/09/2012 12:53 AM, Xu Jiucheng wrote:
> > +   nand@1,0 {
> > +   #address-cells = <1>;
> > +   #size-cells = <1>;
> > +   compatible = "fsl,p1020-fcm-nand",
> > +"fsl,elbc-fcm-nand";
> 
> s/p1020/p1021/
> 
> -Scott

Ok.

Thanks & Best Regards
Jiucheng


___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

RE: [PATCH] powerpc/85xx: Add P1024rdb dts support

2012-01-09 Thread Tang Yuantian-B29983

> On 01/09/2012 02:37 AM, b29...@freescale.com wrote:
> > +/include/ "p1024rdb.dtsi"
> > +/include/ "fsl/p1020si-post.dtsi"
> 
> Is p1024 100% software-compatible with p1020?
> 
> They have different manuals...
> 
> -Scott

P1020rdb has vitesse-7385 switch.
fsl/p1020si-post.dtsi can be used for both boards.

Regards,
Yuantian

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev


Re: [RFC PATCH 14/16] KVM: PPC: booke: category E.HV (GS-mode) support

2012-01-09 Thread Alexander Graf

On 10.01.2012, at 01:51, Scott Wood wrote:

> On 01/09/2012 11:46 AM, Alexander Graf wrote:
>> 
>> On 21.12.2011, at 02:34, Scott Wood wrote:
>> 
>>> Chips such as e500mc that implement category E.HV in Power ISA 2.06
>>> provide hardware virtualization features, including a new MSR mode for
>>> guest state.  The guest OS can perform many operations without trapping
>>> into the hypervisor, including transitions to and from guest userspace.
>>> 
>>> Since we can use SRR1[GS] to reliably tell whether an exception came from
>>> guest state, instead of messing around with IVPR, we use DO_KVM similarly
>>> to book3s.
>> 
>> Is there any benefit of using DO_KVM? I would assume that messing with IVPR 
>> is faster.
> 
> Using the GS bit to decide which handler to run means we won't get
> confused if a machine check or critical interrupt happens between
> entering/exiting the guest and updating IVPR (we could use the IS bit
> similarly in PR-mode).
> 
> This could be supplemented with IVPR (though that will add a few cycles
> to guest entry/exit) or some sort of runtime patching (would be more
> coarse-grained, active when any KVM guest exists) to avoid adding
> overhead to traps when KVM is not used, but I'd like to quantify that
> overhead first.  It should be much lower than what happens on book3s.

Hrm. Yeah, given that your DO_KVM handler is so much simpler, it might make 
sense to stick with that method. Benchmarks would be useful in the long run 
though.

> 
>>> Current issues include:
>>> - Machine checks from guest state are not routed to the host handler.
>>> - The guest can cause a host oops by executing an emulated instruction
>>>  in a page that lacks read permission.  Existing e500/4xx support has
>>>  the same problem.
>> 
>> We solve that in book3s pr by doing
>> 
>>  LAST_INST = ;
>>  PACA->kvm_mode = ;
>>  lwz(guest pc);
>>  do_more_stuff();
>> 
>> That way when an exception occurs at lwz() the DO_KVM handler checks that 
>> we're in kvm mode "recover" which does basically srr0+=4; rfi;.
> 
> I was thinking we'd check ESR[EPID] or SRR1[IS] as appropriate, and
> treat it as a kernel fault (search exception table) -- but this works
> too and is a bit cleaner (could be other uses of external pid), at the
> expense of a couple extra instructions in the emulation path (but
> probably a slightly faster host TLB handler).
> 
> The check wouldn't go in DO_KVM, though, since on bookehv that only
> deals with diverting flow when xSRR1[GS] is set, which wouldn't be the
> case here.

Yup, not sure where you'd put the check, as it'd slow down normal operation 
too. Hrm.

> 
>>> @@ -243,16 +324,20 @@ static int kvmppc_booke_irqprio_deliver(struct 
>>> kvm_vcpu *vcpu,
>>> case BOOKE_IRQPRIO_AP_UNAVAIL:
>>> case BOOKE_IRQPRIO_ALIGNMENT:
>>> allowed = 1;
>>> -   msr_mask = MSR_CE|MSR_ME|MSR_DE;
>>> +   msr_mask = MSR_GS | MSR_CE | MSR_ME | MSR_DE;
>> 
>> No need to do this. You already force MSR_GS in set_msr();
> 
> OK.  This was here since before set_msr() started doing that. :-)
> 
>>> +   if (!current->thread.kvm_vcpu) {
>>> +   WARN(1, "no vcpu\n");
>>> +   return -EPERM;
>>> +   }
>> 
>> Huh?
> 
> Oops, leftover debugging.
> 
>>> +static int emulation_exit(struct kvm_run *run, struct kvm_vcpu *vcpu)
>>> +{
>>> +   enum emulation_result er;
>>> +
>>> +   er = kvmppc_emulate_instruction(run, vcpu);
>>> +   switch (er) {
>>> +   case EMULATE_DONE:
>>> +   /* don't overwrite subtypes, just account kvm_stats */
>>> +   kvmppc_account_exit_stat(vcpu, EMULATED_INST_EXITS);
>>> +   /* Future optimization: only reload non-volatiles if
>>> +* they were actually modified by emulation. */
>>> +   return RESUME_GUEST_NV;
>>> +
>>> +   case EMULATE_DO_DCR:
>>> +   run->exit_reason = KVM_EXIT_DCR;
>>> +   return RESUME_HOST;
>>> +
>>> +   case EMULATE_FAIL:
>>> +   /* XXX Deliver Program interrupt to guest. */
>>> +   printk(KERN_CRIT "%s: emulation at %lx failed (%08x)\n",
>>> +  __func__, vcpu->arch.regs.nip, vcpu->arch.last_inst);
>> 
>> This should be throttled, otherwise the guest can spam our logs.
> 
> Yes it should, but I'm just moving the code here.

Yeah, only realized this later. Maybe next time (not for this patch set, next 
time you're sending something) just extract these mechanical parts, so it's 
easier to review the pieces where code actually changes :).

> 
>>> +   /* For debugging, encode the failing instruction and
>>> +* report it to userspace. */
>>> +   run->hw.hardware_exit_reason = ~0ULL << 32;
>>> +   run->hw.hardware_exit_reason |= vcpu->arch.last_inst;
>> 
>> 
>> I'm fairly sure you want to fix this :)
> 
> Likewise, that's what booke.c already does.  What should it do instead?

This is what book3s does:

case EMULATE_FAIL:
printk(KERN_CRIT "%s: emulation at %lx failed (%08x)\

Re: [PATCH 2/2] Kbuild: Use dtc's -d (dependency) option

2012-01-09 Thread Shawn Guo
On Mon, Jan 09, 2012 at 11:38:15AM -0700, Stephen Warren wrote:
> This hooks dtc into Kbuild's dependency system.
> 
> Thus, for example, "make dtbs" will rebuild tegra-harmony.dtb if only
> tegra20.dtsi has changed yet tegra-harmony.dts has not. The previous
> lack of this feature recently caused me to have very confusing "git
> bisect" results.
> 
> For ARM, it's obvious what to add to $(targets). I'm not familiar enough
> with other architectures to know what to add there. Powerpc appears to
> already add various .dtb files into $(targets), but the other archs may
> need something added to $(targets) to work.
> 
> Signed-off-by: Stephen Warren 

Though I did not look into the patches deeply, I know the problem very
well and it annoys me a lot.  It's great that we have patches to fix
it, so

Acked-by: Shawn Guo 

-- 
Regards,
Shawn
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev


Re: [PATCH 2/2][v2] mtd/nand: Fix IFC driver to support 2K NAND page

2012-01-09 Thread Scott Wood
On 01/09/2012 06:24 AM, Prabhakar Kushwaha wrote:
> 1) OOB area should be updated irrespective of NAND page size. Earlier it was
> updated only for 512byte NAND page.
> 
> 2) During OOB update fbcr should be equal to OOB size.
> 
> Signed-off-by: Poonam Aggrwal 
> Signed-off-by: Prabhakar Kushwaha 
> ---
>  git://git.kernel.org/pub/scm/linux/kernel/git/galak/powerpc.git (branch next)
> 
>  This patch is created on top of IFC driver patch (already floated in mailing
>  list). Please find their link:
>  http://patchwork.ozlabs.org/patch/133315/
>  http://patchwork.ozlabs.org/patch/133316/

Looks good.

-Scott

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev


Re: [PATCH 1/2][v2] mtd/nand:Fix wrong address read in is_blank()

2012-01-09 Thread Scott Wood
On 01/09/2012 06:24 AM, Prabhakar Kushwaha wrote:
> @@ -215,12 +215,15 @@ static int is_blank(struct mtd_info *mtd, unsigned int 
> bufnum)
>  static int check_read_ecc(struct mtd_info *mtd, struct fsl_ifc_ctrl *ctrl,
> u32 *eccstat, unsigned int bufnum)
>  {
> + struct nand_chip *chip = mtd->priv;
> + int bufperpage = mtd->writesize / chip->ecc.size;
> + int eccbuf_num = bufnum + (bufnum / bufperpage) * bufperpage;

This is unnecessarily complicated (and introduces two more, dependent,
runtime divisions).  I don't think there are any changes required in
this function.  You're awkwardly compensating for the fact that the
caller hasn't been updated for the new definition of bufnum.

bufperpage used in fsl_ifc_run_command should be doubled to account for
the OOB buffers.  We should probably rename it from "buf" to something
else (chunk? subpage?) to avoid confusion with bufnum_mask, which refers
to page-sized buffers.

>   u32 reg = eccstat[bufnum / 4];
>   int errors = (reg >> ((3 - bufnum % 4) * 8)) & 15;
>  
>   if (errors == 15) { /* uncorrectable */
>   /* Blank pages fail hw ECC checks */
> - if (is_blank(mtd, bufnum))
> + if (is_blank(mtd, eccbuf_num))
>   return 1;
>  
>   /*
> @@ -273,7 +276,7 @@ static void fsl_ifc_run_command(struct mtd_info *mtd)
>   dev_err(priv->dev, "NAND Flash Write Protect Error\n");
>  
>   if (nctrl->eccread) {
> - int bufperpage = mtd->writesize / 512;
> + int bufperpage = mtd->writesize / chip->ecc.size;
>   int bufnum = (nctrl->page & priv->bufnum_mask) * bufperpage;
>   int bufnum_end = bufnum + bufperpage - 1;
>  

Again, please calculate bufperpage (chunksperpage? subsperpage? perbuf?)
at driver init, as is done with bufnum_mask.

-Scott

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev


Re: [RFC PATCH 14/16] KVM: PPC: booke: category E.HV (GS-mode) support

2012-01-09 Thread Scott Wood
On 01/09/2012 11:46 AM, Alexander Graf wrote:
> 
> On 21.12.2011, at 02:34, Scott Wood wrote:
> 
>> Chips such as e500mc that implement category E.HV in Power ISA 2.06
>> provide hardware virtualization features, including a new MSR mode for
>> guest state.  The guest OS can perform many operations without trapping
>> into the hypervisor, including transitions to and from guest userspace.
>>
>> Since we can use SRR1[GS] to reliably tell whether an exception came from
>> guest state, instead of messing around with IVPR, we use DO_KVM similarly
>> to book3s.
> 
> Is there any benefit of using DO_KVM? I would assume that messing with IVPR 
> is faster.

Using the GS bit to decide which handler to run means we won't get
confused if a machine check or critical interrupt happens between
entering/exiting the guest and updating IVPR (we could use the IS bit
similarly in PR-mode).

This could be supplemented with IVPR (though that will add a few cycles
to guest entry/exit) or some sort of runtime patching (would be more
coarse-grained, active when any KVM guest exists) to avoid adding
overhead to traps when KVM is not used, but I'd like to quantify that
overhead first.  It should be much lower than what happens on book3s.

>> Current issues include:
>> - Machine checks from guest state are not routed to the host handler.
>> - The guest can cause a host oops by executing an emulated instruction
>>   in a page that lacks read permission.  Existing e500/4xx support has
>>   the same problem.
> 
> We solve that in book3s pr by doing
> 
>   LAST_INST = ;
>   PACA->kvm_mode = ;
>   lwz(guest pc);
>   do_more_stuff();
> 
> That way when an exception occurs at lwz() the DO_KVM handler checks that 
> we're in kvm mode "recover" which does basically srr0+=4; rfi;.

I was thinking we'd check ESR[EPID] or SRR1[IS] as appropriate, and
treat it as a kernel fault (search exception table) -- but this works
too and is a bit cleaner (could be other uses of external pid), at the
expense of a couple extra instructions in the emulation path (but
probably a slightly faster host TLB handler).

The check wouldn't go in DO_KVM, though, since on bookehv that only
deals with diverting flow when xSRR1[GS] is set, which wouldn't be the
case here.

>> @@ -243,16 +324,20 @@ static int kvmppc_booke_irqprio_deliver(struct 
>> kvm_vcpu *vcpu,
>>  case BOOKE_IRQPRIO_AP_UNAVAIL:
>>  case BOOKE_IRQPRIO_ALIGNMENT:
>>  allowed = 1;
>> -msr_mask = MSR_CE|MSR_ME|MSR_DE;
>> +msr_mask = MSR_GS | MSR_CE | MSR_ME | MSR_DE;
> 
> No need to do this. You already force MSR_GS in set_msr();

OK.  This was here since before set_msr() started doing that. :-)

>> +if (!current->thread.kvm_vcpu) {
>> +WARN(1, "no vcpu\n");
>> +return -EPERM;
>> +}
> 
> Huh?

Oops, leftover debugging.

>> +static int emulation_exit(struct kvm_run *run, struct kvm_vcpu *vcpu)
>> +{
>> +enum emulation_result er;
>> +
>> +er = kvmppc_emulate_instruction(run, vcpu);
>> +switch (er) {
>> +case EMULATE_DONE:
>> +/* don't overwrite subtypes, just account kvm_stats */
>> +kvmppc_account_exit_stat(vcpu, EMULATED_INST_EXITS);
>> +/* Future optimization: only reload non-volatiles if
>> + * they were actually modified by emulation. */
>> +return RESUME_GUEST_NV;
>> +
>> +case EMULATE_DO_DCR:
>> +run->exit_reason = KVM_EXIT_DCR;
>> +return RESUME_HOST;
>> +
>> +case EMULATE_FAIL:
>> +/* XXX Deliver Program interrupt to guest. */
>> +printk(KERN_CRIT "%s: emulation at %lx failed (%08x)\n",
>> +   __func__, vcpu->arch.regs.nip, vcpu->arch.last_inst);
> 
> This should be throttled, otherwise the guest can spam our logs.

Yes it should, but I'm just moving the code here.

>> +/* For debugging, encode the failing instruction and
>> + * report it to userspace. */
>> +run->hw.hardware_exit_reason = ~0ULL << 32;
>> +run->hw.hardware_exit_reason |= vcpu->arch.last_inst;
> 
> 
> I'm fairly sure you want to fix this :)

Likewise, that's what booke.c already does.  What should it do instead?

> /**
>>  * kvmppc_handle_exit
>>  *
>> @@ -374,12 +530,39 @@ out:
>> int kvmppc_handle_exit(struct kvm_run *run, struct kvm_vcpu *vcpu,
>>unsigned int exit_nr)
>> {
>> -enum emulation_result er;
>>  int r = RESUME_HOST;
>>
>>  /* update before a new last_exit_type is rewritten */
>>  kvmppc_update_timing_stats(vcpu);
>>
>> +/*
>> + * If we actually care, we could copy MSR, DEAR, and ESR to regs,
>> + * insert an appropriate trap number, etc.
>> + *
>> + * Seems like a waste of cycles for something that should only matter
>> + * to someone using sysrq-t/p or similar host kernel debug facility.
>> + * We have other debug facilities to get that information from a
>> + * guest through us

Re: [PATCH] powerpc: Fix RCU idle and hcall tracing

2012-01-09 Thread Paul E. McKenney
On Tue, Jan 10, 2012 at 11:29:15AM +1100, Anton Blanchard wrote:
> 
> Tracepoints should not be called inside an rcu_idle_enter/rcu_idle_exit
> region. Since pSeries calls H_CEDE in the idle loop, we were violating
> this rule.
> 
> commit a7b152d5342c (powerpc: Tell RCU about idle after hcall tracing)
> tried to work around it by delaying the rcu_idle_enter until after we
> called the hcall tracepoint, but there are a number of issues with it.
> 
> The hcall tracepoint trampoline code is called conditionally when the
> tracepoint is enabled. If the tracepoint is not enabled we never call
> rcu_idle_enter. The idle_uses_rcu check was also done at compile time
> which breaks multiplatform builds.
> 
> The simple fix is to avoid tracing H_CEDE and rely on other tracepoints
> and the hypervisor dispatch trace log to work out if we called H_CEDE.
> 
> This fixes a hang during boot on pSeries.
> 
> Signed-off-by: Anton Blanchard 

Acked-by: Paul E. McKenney 

> ---
> 
> Index: linux-build/arch/powerpc/kernel/idle.c
> ===
> --- linux-build.orig/arch/powerpc/kernel/idle.c   2012-01-10 
> 11:07:22.091615183 +1100
> +++ linux-build/arch/powerpc/kernel/idle.c2012-01-10 11:07:57.172264229 
> +1100
> @@ -50,12 +50,6 @@ static int __init powersave_off(char *ar
>  }
>  __setup("powersave=off", powersave_off);
> 
> -#if defined(CONFIG_PPC_PSERIES) && defined(CONFIG_TRACEPOINTS)
> -static const bool idle_uses_rcu = 1;
> -#else
> -static const bool idle_uses_rcu;
> -#endif
> -
>  /*
>   * The body of the idle task.
>   */
> @@ -67,8 +61,7 @@ void cpu_idle(void)
>   set_thread_flag(TIF_POLLING_NRFLAG);
>   while (1) {
>   tick_nohz_idle_enter();
> - if (!idle_uses_rcu)
> - rcu_idle_enter();
> + rcu_idle_enter();
> 
>   while (!need_resched() && !cpu_should_die()) {
>   ppc64_runlatch_off();
> @@ -106,8 +99,7 @@ void cpu_idle(void)
> 
>   HMT_medium();
>   ppc64_runlatch_on();
> - if (!idle_uses_rcu)
> - rcu_idle_exit();
> + rcu_idle_exit();
>   tick_nohz_idle_exit();
>   preempt_enable_no_resched();
>   if (cpu_should_die())
> Index: linux-build/arch/powerpc/platforms/pseries/lpar.c
> ===
> --- linux-build.orig/arch/powerpc/platforms/pseries/lpar.c2012-01-10 
> 11:07:22.079614961 +1100
> +++ linux-build/arch/powerpc/platforms/pseries/lpar.c 2012-01-10 
> 11:16:55.710226236 +1100
> @@ -546,6 +546,13 @@ void __trace_hcall_entry(unsigned long o
>   unsigned long flags;
>   unsigned int *depth;
> 
> + /*
> +  * We cannot call tracepoints inside RCU idle regions which
> +  * means we must not trace H_CEDE.
> +  */
> + if (opcode == H_CEDE)
> + return;
> +
>   local_irq_save(flags);
> 
>   depth = &__get_cpu_var(hcall_trace_depth);
> @@ -556,8 +563,6 @@ void __trace_hcall_entry(unsigned long o
>   (*depth)++;
>   preempt_disable();
>   trace_hcall_entry(opcode, args);
> - if (opcode == H_CEDE)
> - rcu_idle_enter();
>   (*depth)--;
> 
>  out:
> @@ -570,6 +575,9 @@ void __trace_hcall_exit(long opcode, uns
>   unsigned long flags;
>   unsigned int *depth;
> 
> + if (opcode == H_CEDE)
> + return;
> +
>   local_irq_save(flags);
> 
>   depth = &__get_cpu_var(hcall_trace_depth);
> @@ -578,8 +586,6 @@ void __trace_hcall_exit(long opcode, uns
>   goto out;
> 
>   (*depth)++;
> - if (opcode == H_CEDE)
> - rcu_idle_exit();
>   trace_hcall_exit(opcode, retval, retbuf);
>   preempt_enable();
>   (*depth)--;
> 

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev


[PATCH] powerpc: Fix RCU idle and hcall tracing

2012-01-09 Thread Anton Blanchard

Tracepoints should not be called inside an rcu_idle_enter/rcu_idle_exit
region. Since pSeries calls H_CEDE in the idle loop, we were violating
this rule.

commit a7b152d5342c (powerpc: Tell RCU about idle after hcall tracing)
tried to work around it by delaying the rcu_idle_enter until after we
called the hcall tracepoint, but there are a number of issues with it.

The hcall tracepoint trampoline code is called conditionally when the
tracepoint is enabled. If the tracepoint is not enabled we never call
rcu_idle_enter. The idle_uses_rcu check was also done at compile time
which breaks multiplatform builds.

The simple fix is to avoid tracing H_CEDE and rely on other tracepoints
and the hypervisor dispatch trace log to work out if we called H_CEDE.

This fixes a hang during boot on pSeries.

Signed-off-by: Anton Blanchard 
---

Index: linux-build/arch/powerpc/kernel/idle.c
===
--- linux-build.orig/arch/powerpc/kernel/idle.c 2012-01-10 11:07:22.091615183 
+1100
+++ linux-build/arch/powerpc/kernel/idle.c  2012-01-10 11:07:57.172264229 
+1100
@@ -50,12 +50,6 @@ static int __init powersave_off(char *ar
 }
 __setup("powersave=off", powersave_off);
 
-#if defined(CONFIG_PPC_PSERIES) && defined(CONFIG_TRACEPOINTS)
-static const bool idle_uses_rcu = 1;
-#else
-static const bool idle_uses_rcu;
-#endif
-
 /*
  * The body of the idle task.
  */
@@ -67,8 +61,7 @@ void cpu_idle(void)
set_thread_flag(TIF_POLLING_NRFLAG);
while (1) {
tick_nohz_idle_enter();
-   if (!idle_uses_rcu)
-   rcu_idle_enter();
+   rcu_idle_enter();
 
while (!need_resched() && !cpu_should_die()) {
ppc64_runlatch_off();
@@ -106,8 +99,7 @@ void cpu_idle(void)
 
HMT_medium();
ppc64_runlatch_on();
-   if (!idle_uses_rcu)
-   rcu_idle_exit();
+   rcu_idle_exit();
tick_nohz_idle_exit();
preempt_enable_no_resched();
if (cpu_should_die())
Index: linux-build/arch/powerpc/platforms/pseries/lpar.c
===
--- linux-build.orig/arch/powerpc/platforms/pseries/lpar.c  2012-01-10 
11:07:22.079614961 +1100
+++ linux-build/arch/powerpc/platforms/pseries/lpar.c   2012-01-10 
11:16:55.710226236 +1100
@@ -546,6 +546,13 @@ void __trace_hcall_entry(unsigned long o
unsigned long flags;
unsigned int *depth;
 
+   /*
+* We cannot call tracepoints inside RCU idle regions which
+* means we must not trace H_CEDE.
+*/
+   if (opcode == H_CEDE)
+   return;
+
local_irq_save(flags);
 
depth = &__get_cpu_var(hcall_trace_depth);
@@ -556,8 +563,6 @@ void __trace_hcall_entry(unsigned long o
(*depth)++;
preempt_disable();
trace_hcall_entry(opcode, args);
-   if (opcode == H_CEDE)
-   rcu_idle_enter();
(*depth)--;
 
 out:
@@ -570,6 +575,9 @@ void __trace_hcall_exit(long opcode, uns
unsigned long flags;
unsigned int *depth;
 
+   if (opcode == H_CEDE)
+   return;
+
local_irq_save(flags);
 
depth = &__get_cpu_var(hcall_trace_depth);
@@ -578,8 +586,6 @@ void __trace_hcall_exit(long opcode, uns
goto out;
 
(*depth)++;
-   if (opcode == H_CEDE)
-   rcu_idle_exit();
trace_hcall_exit(opcode, retval, retbuf);
preempt_enable();
(*depth)--;
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev


Re: [RFC PATCH 15/16] KVM: PPC: booke: standard PPC floating point support

2012-01-09 Thread Alexander Graf

On 09.01.2012, at 23:54, Scott Wood wrote:

> On 01/09/2012 04:47 PM, Alexander Graf wrote:
>> 
>> On 09.01.2012, at 23:39, Scott Wood wrote:
>> 
>>> On 01/09/2012 04:17 PM, Alexander Graf wrote:
 
 On 09.01.2012, at 22:48, Scott Wood wrote:
 
> On 01/09/2012 11:48 AM, Alexander Graf wrote:
>> I'm having a hard time to grasp when shared->msr, shadow_msr and 
>> regs->msr is used in your code :).
> 
> shadow_msr is the real MSR.
> 
> shared->msr is the guest's view of MSR.
>>> 
>>> Correction -- this applies to PR-mode (e500v2).
>>> 
>>> In GS-mode, shadow_msr is not used.  The guest sees the real MSR (hw
>>> silently prevents it from modifying certain bits), which gets saved on
>>> exit into shared->msr.
>> 
>> Hrm. Can we maybe #ifdef out shadow_msr on HV then? I'm really getting 
>> confused with having 3 potential msr variables in the vcpu struct.
> 
> An ifdef would take us further down the road of not being able to
> support both in the same kernel image (not sure whether that's a
> long-term goal -- probably won't happen any time soon with e500v2+e500mc
> even disregarding KVM, but maybe it'll be relevant on some other chips),
> and in general increase the mess in the struct definition.  How about a
> comment?

Well, I'd like to make sure we don't accidentally access the wrong field. But 
yes, a comment should be ok.

Alex

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev


Re: [RFC PATCH 15/16] KVM: PPC: booke: standard PPC floating point support

2012-01-09 Thread Scott Wood
On 01/09/2012 04:47 PM, Alexander Graf wrote:
> 
> On 09.01.2012, at 23:39, Scott Wood wrote:
> 
>> On 01/09/2012 04:17 PM, Alexander Graf wrote:
>>>
>>> On 09.01.2012, at 22:48, Scott Wood wrote:
>>>
 On 01/09/2012 11:48 AM, Alexander Graf wrote:
> I'm having a hard time to grasp when shared->msr, shadow_msr and 
> regs->msr is used in your code :).

 shadow_msr is the real MSR.

 shared->msr is the guest's view of MSR.
>>
>> Correction -- this applies to PR-mode (e500v2).
>>
>> In GS-mode, shadow_msr is not used.  The guest sees the real MSR (hw
>> silently prevents it from modifying certain bits), which gets saved on
>> exit into shared->msr.
> 
> Hrm. Can we maybe #ifdef out shadow_msr on HV then? I'm really getting 
> confused with having 3 potential msr variables in the vcpu struct.

An ifdef would take us further down the road of not being able to
support both in the same kernel image (not sure whether that's a
long-term goal -- probably won't happen any time soon with e500v2+e500mc
even disregarding KVM, but maybe it'll be relevant on some other chips),
and in general increase the mess in the struct definition.  How about a
comment?

-Scott

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev


Re: [RFC PATCH 15/16] KVM: PPC: booke: standard PPC floating point support

2012-01-09 Thread Alexander Graf

On 09.01.2012, at 23:39, Scott Wood wrote:

> On 01/09/2012 04:17 PM, Alexander Graf wrote:
>> 
>> On 09.01.2012, at 22:48, Scott Wood wrote:
>> 
>>> On 01/09/2012 11:48 AM, Alexander Graf wrote:
 
 Do you think it's possible to combine this with the book3s_pr code, so we 
 don't duplicate too much here?
>>> 
>>> book3s_pr is a bit different in that it can trap when the guest sets
>>> MSR[FP].
>> 
>> Ah, there's no doorbell? So you always have to swap fpu registers? You still 
>> have to enable it manually when preempting in, right? IIRC ppc32 does lazy 
>> fpu activation.
> 
> Right.
> 
> Preempting in is handled by calling kvmppc_load_guest_fp() (which should
> be renamed to be booke-specific, since the semantics are tied to
> booke.c) from kvmppc_core_vcpu_load() in e500mc.c.

Ah, and that one's called on sched_in. All is well then :).

> 
 I'm having a hard time to grasp when shared->msr, shadow_msr and regs->msr 
 is used in your code :).
>>> 
>>> shadow_msr is the real MSR.
>>> 
>>> shared->msr is the guest's view of MSR.
> 
> Correction -- this applies to PR-mode (e500v2).
> 
> In GS-mode, shadow_msr is not used.  The guest sees the real MSR (hw
> silently prevents it from modifying certain bits), which gets saved on
> exit into shared->msr.

Hrm. Can we maybe #ifdef out shadow_msr on HV then? I'm really getting confused 
with having 3 potential msr variables in the vcpu struct.


Alex

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev


[PATCH 2/2] Kbuild: Use dtc's -d (dependency) option

2012-01-09 Thread Stephen Warren
This hooks dtc into Kbuild's dependency system.

Thus, for example, "make dtbs" will rebuild tegra-harmony.dtb if only
tegra20.dtsi has changed yet tegra-harmony.dts has not. The previous
lack of this feature recently caused me to have very confusing "git
bisect" results.

For ARM, it's obvious what to add to $(targets). I'm not familiar enough
with other architectures to know what to add there. Powerpc appears to
already add various .dtb files into $(targets), but the other archs may
need something added to $(targets) to work.

Signed-off-by: Stephen Warren 
---
I have only tested this series for ARM.

 arch/arm/boot/Makefile|6 --
 arch/c6x/boot/Makefile|2 +-
 arch/microblaze/boot/Makefile |2 +-
 arch/openrisc/boot/Makefile   |4 ++--
 arch/powerpc/boot/Makefile|4 ++--
 scripts/Makefile.lib  |2 +-
 6 files changed, 11 insertions(+), 9 deletions(-)

diff --git a/arch/arm/boot/Makefile b/arch/arm/boot/Makefile
index 1338cf0..c72730d 100644
--- a/arch/arm/boot/Makefile
+++ b/arch/arm/boot/Makefile
@@ -62,9 +62,11 @@ $(obj)/zImage-dtb.%: $(obj)/%.dtb $(obj)/zImage
 
 endif
 
+targets += $(dtb-y)
+
 # Rule to build device tree blobs
-$(obj)/%.dtb: $(src)/dts/%.dts
-   $(call cmd,dtc)
+$(obj)/%.dtb: $(src)/dts/%.dts FORCE
+   $(call if_changed_dep,dtc)
 
 $(obj)/dtbs: $(addprefix $(obj)/, $(dtb-y))
 
diff --git a/arch/c6x/boot/Makefile b/arch/c6x/boot/Makefile
index ecca820..6891257 100644
--- a/arch/c6x/boot/Makefile
+++ b/arch/c6x/boot/Makefile
@@ -13,7 +13,7 @@ obj-y += linked_dtb.o
 endif
 
 $(obj)/%.dtb: $(src)/dts/%.dts FORCE
-   $(call cmd,dtc)
+   $(call if_changed_dep,dtc)
 
 quiet_cmd_cp = CP  $< $@$2
cmd_cp = cat $< >$@$2 || (rm -f $@ && echo false)
diff --git a/arch/microblaze/boot/Makefile b/arch/microblaze/boot/Makefile
index 4c4e58e..0c796cf 100644
--- a/arch/microblaze/boot/Makefile
+++ b/arch/microblaze/boot/Makefile
@@ -53,6 +53,6 @@ $(obj)/simpleImage.%: vmlinux FORCE
 DTC_FLAGS := -p 1024
 
 $(obj)/%.dtb: $(src)/dts/%.dts FORCE
-   $(call cmd,dtc)
+   $(call if_changed_dep,dtc)
 
 clean-files += *.dtb simpleImage.*.unstrip linux.bin.ub
diff --git a/arch/openrisc/boot/Makefile b/arch/openrisc/boot/Makefile
index 98ca185..0995835 100644
--- a/arch/openrisc/boot/Makefile
+++ b/arch/openrisc/boot/Makefile
@@ -11,5 +11,5 @@ clean-files := *.dtb.S
 
 #DTC_FLAGS ?= -p 1024
 
-$(obj)/%.dtb: $(src)/dts/%.dts
-   $(call cmd,dtc)
+$(obj)/%.dtb: $(src)/dts/%.dts FORCE
+   $(call if_changed_dep,dtc)
diff --git a/arch/powerpc/boot/Makefile b/arch/powerpc/boot/Makefile
index 15986e7..8844a17 100644
--- a/arch/powerpc/boot/Makefile
+++ b/arch/powerpc/boot/Makefile
@@ -345,8 +345,8 @@ $(obj)/treeImage.%: vmlinux $(obj)/%.dtb $(wrapperbits)
$(call if_changed,wrap,treeboot-$*,,$(obj)/$*.dtb)
 
 # Rule to build device tree blobs
-$(obj)/%.dtb: $(src)/dts/%.dts
-   $(call cmd,dtc)
+$(obj)/%.dtb: $(src)/dts/%.dts FORCE
+   $(call if_changed_dep,dtc)
 
 # If there isn't a platform selected then just strip the vmlinux.
 ifeq (,$(image-y))
diff --git a/scripts/Makefile.lib b/scripts/Makefile.lib
index 5d986d9..7bae316 100644
--- a/scripts/Makefile.lib
+++ b/scripts/Makefile.lib
@@ -264,7 +264,7 @@ $(obj)/%.dtb.S: $(obj)/%.dtb
$(call cmd,dt_S_dtb)
 
 quiet_cmd_dtc = DTC $@
-cmd_dtc = $(objtree)/scripts/dtc/dtc -O dtb -o $@ -b 0 $(DTC_FLAGS) $<
+cmd_dtc = $(objtree)/scripts/dtc/dtc -O dtb -o $@ -b 0 $(DTC_FLAGS) -d 
$(depfile) $<
 
 # Bzip2
 # ---
-- 
1.7.0.4

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev


[PATCH 1/2] dtc: Implement -d option to write out a dependency file

2012-01-09 Thread Stephen Warren
This will allow callers to rebuild .dtb files when any of the /include/d
.dtsi files are modified, not just the top-level .dts file.

Signed-off-by: Stephen Warren 
---
This patch is against the Linux kernel's copy of dtc, but it applies to
upstream dtc with a couple of trivial conflicts. I can post a version for
upstream dtc as well if desired.

I have only tested this series for ARM.

 scripts/dtc/dtc.c|   22 +-
 scripts/dtc/srcpos.c |6 ++
 scripts/dtc/srcpos.h |1 +
 3 files changed, 28 insertions(+), 1 deletions(-)

diff --git a/scripts/dtc/dtc.c b/scripts/dtc/dtc.c
index cbc0193..27ecf06 100644
--- a/scripts/dtc/dtc.c
+++ b/scripts/dtc/dtc.c
@@ -71,6 +71,7 @@ static void  __attribute__ ((noreturn)) usage(void)
fprintf(stderr, "\t\t\tasm - assembler source\n");
fprintf(stderr, "\t-V \n");
fprintf(stderr, "\t\tBlob version to produce, defaults to %d (relevant 
for dtb\n\t\tand asm output only)\n", DEFAULT_FDT_VERSION);
+   fprintf(stderr, "\t-d \n");
fprintf(stderr, "\t-R \n");
fprintf(stderr, "\t\tMake space for  reserve map entries 
(relevant for \n\t\tdtb and asm output only)\n");
fprintf(stderr, "\t-S \n");
@@ -99,6 +100,7 @@ int main(int argc, char *argv[])
const char *inform = "dts";
const char *outform = "dts";
const char *outname = "-";
+   const char *depname = NULL;
int force = 0, check = 0, sort = 0;
const char *arg;
int opt;
@@ -111,7 +113,8 @@ int main(int argc, char *argv[])
minsize= 0;
padsize= 0;
 
-   while ((opt = getopt(argc, argv, "hI:O:o:V:R:S:p:fcqb:vH:s")) != EOF) {
+   while ((opt = getopt(argc, argv, "hI:O:o:V:d:R:S:p:fcqb:vH:s"))
+   != EOF) {
switch (opt) {
case 'I':
inform = optarg;
@@ -125,6 +128,9 @@ int main(int argc, char *argv[])
case 'V':
outversion = strtol(optarg, NULL, 0);
break;
+   case 'd':
+   depname = optarg;
+   break;
case 'R':
reservenum = strtol(optarg, NULL, 0);
break;
@@ -188,6 +194,15 @@ int main(int argc, char *argv[])
fprintf(stderr, "DTC: %s->%s  on file \"%s\"\n",
inform, outform, arg);
 
+   if (depname) {
+   depfile = fopen(depname, "w");
+   if (!depfile)
+   die("Couldn't open dependency file %s: %s\n", depname,
+   strerror(errno));
+   fputs(outname, depfile);
+   fputc(':', depfile);
+   }
+
if (streq(inform, "dts"))
bi = dt_from_source(arg);
else if (streq(inform, "fs"))
@@ -197,6 +212,11 @@ int main(int argc, char *argv[])
else
die("Unknown input format \"%s\"\n", inform);
 
+   if (depfile) {
+   fputc('\n', depfile);
+   fclose(depfile);
+   }
+
if (cmdline_boot_cpuid != -1)
bi->boot_cpuid_phys = cmdline_boot_cpuid;
 
diff --git a/scripts/dtc/srcpos.c b/scripts/dtc/srcpos.c
index 2dbc874..93b3533 100644
--- a/scripts/dtc/srcpos.c
+++ b/scripts/dtc/srcpos.c
@@ -40,6 +40,7 @@ static char *dirname(const char *path)
return NULL;
 }
 
+FILE *depfile; /* = NULL */
 struct srcfile_state *current_srcfile; /* = NULL */
 
 /* Detect infinite include recursion. */
@@ -67,6 +68,11 @@ FILE *srcfile_relative_open(const char *fname, char 
**fullnamep)
strerror(errno));
}
 
+   if (depfile) {
+   fputc(' ', depfile);
+   fputs(fullname, depfile);
+   }
+
if (fullnamep)
*fullnamep = fullname;
else
diff --git a/scripts/dtc/srcpos.h b/scripts/dtc/srcpos.h
index bd7966e..ce980ca 100644
--- a/scripts/dtc/srcpos.h
+++ b/scripts/dtc/srcpos.h
@@ -30,6 +30,7 @@ struct srcfile_state {
struct srcfile_state *prev;
 };
 
+extern FILE *depfile; /* = NULL */
 extern struct srcfile_state *current_srcfile; /* = NULL */
 
 FILE *srcfile_relative_open(const char *fname, char **fullnamep);
-- 
1.7.0.4

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev


Re: Mac address in the DT

2012-01-09 Thread Wolfgang Denk
Dear smitha.va...@wipro.com,

In message <40631e9a2581f14ba60888c87a76a1fe01d...@hyd-mkd-mbx4.wipro.com> you 
wrote:
>  
> >Setenv set_mac 'cp 0xffec 0x10 1024;fdt addr 0xc0 8192;fdt set=
>  /soc8272@f000/ethernet@24000 mac-address "[00 44 00 55 00 66]";erase 0x=
> ffec 0xffec4000;cp 0xc0 0xffec 1024;bootm 0xfe06 - 0xffec000=
> 0'
> 
> > run set_mac
> 
> For the above command I want to replace the mac address with the ethaddr> How
> do I do that. I tried $ethaddr but I get extra : characters.

Why would you do that at all?  U-Boot will run fdt_fixup_ethernet()
for all (at least AFAICT) supported architectures, which will replace 
"mac-address" and "local-mac-address" for all "ethernet?" interfaces
in the device tree for which a corresponding "ethadd" / "eth?addr"
environment variable is set.

No additional actions are needed.

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: w...@denx.de
"One day," said a dull voice from down below, "I'm going to  be  back
in  form again and you're going to be very sorry you said that. For a
very long time. I might even go so far as to make even more Time just
for you to be sorry in."  - Terry Pratchett, _Small Gods_
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev


Re: [RFC PATCH 15/16] KVM: PPC: booke: standard PPC floating point support

2012-01-09 Thread Scott Wood
On 01/09/2012 04:17 PM, Alexander Graf wrote:
> 
> On 09.01.2012, at 22:48, Scott Wood wrote:
> 
>> On 01/09/2012 11:48 AM, Alexander Graf wrote:
>>>
>>> Do you think it's possible to combine this with the book3s_pr code, so we 
>>> don't duplicate too much here?
>>
>> book3s_pr is a bit different in that it can trap when the guest sets
>> MSR[FP].
> 
> Ah, there's no doorbell? So you always have to swap fpu registers? You still 
> have to enable it manually when preempting in, right? IIRC ppc32 does lazy 
> fpu activation.

Right.

Preempting in is handled by calling kvmppc_load_guest_fp() (which should
be renamed to be booke-specific, since the semantics are tied to
booke.c) from kvmppc_core_vcpu_load() in e500mc.c.

>>> I'm having a hard time to grasp when shared->msr, shadow_msr and regs->msr 
>>> is used in your code :).
>>
>> shadow_msr is the real MSR.
>>
>> shared->msr is the guest's view of MSR.

Correction -- this applies to PR-mode (e500v2).

In GS-mode, shadow_msr is not used.  The guest sees the real MSR (hw
silently prevents it from modifying certain bits), which gets saved on
exit into shared->msr.

-Scott

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev


Re: [RFC PATCH 15/16] KVM: PPC: booke: standard PPC floating point support

2012-01-09 Thread Alexander Graf

On 09.01.2012, at 22:48, Scott Wood wrote:

> On 01/09/2012 11:48 AM, Alexander Graf wrote:
>> 
>> On 21.12.2011, at 02:34, Scott Wood wrote:
>>> +#ifdef CONFIG_PPC_FPU
>>> +   /* Save userspace FPU state in stack */
>>> +   enable_kernel_fp();
>>> +   memcpy(fpr, current->thread.fpr, sizeof(current->thread.fpr));
>>> +   fpscr = current->thread.fpscr.val;
>>> +   fpexc_mode = current->thread.fpexc_mode;
>>> +
>>> +   /* Restore guest FPU state to thread */
>>> +   memcpy(current->thread.fpr, vcpu->arch.fpr, sizeof(vcpu->arch.fpr));
>>> +   current->thread.fpscr.val = vcpu->arch.fpscr;
>>> +
>>> +   /*
>>> +* Since we can't trap on MSR_FP in GS-mode, we consider the guest
>>> +* as always using the FPU.  Kernel usage of FP (via
>>> +* enable_kernel_fp()) in this thread must not occur while
>>> +* vcpu->fpu_active is set.
>>> +*/
>>> +   vcpu->fpu_active = 1;
>>> +
>>> +   kvmppc_load_guest_fp(vcpu);
>>> +#endif
>> 
>> Do you think it's possible to combine this with the book3s_pr code, so we 
>> don't duplicate too much here?
> 
> book3s_pr is a bit different in that it can trap when the guest sets
> MSR[FP].

Ah, there's no doorbell? So you always have to swap fpu registers? You still 
have to enable it manually when preempting in, right? IIRC ppc32 does lazy fpu 
activation.

> Maybe a few lines could be factored out (the first memcpy, fpscr,
> fpexc_mode).  I'm not sure that it makes sense given the lack of
> isolation between what it's doing and what the rest of the code is doing.

Yeah, looking at the code it does look pretty different. Too bad - I would've 
hoped to throw the vmx code in as well so we could get vmx/vsx/whatever for 
free later.

> 
>>> +/*
>>> + * Load up guest vcpu FP state if it's needed.
>>> + * It also set the MSR_FP in thread so that host know
>>> + * we're holding FPU, and then host can help to save
>>> + * guest vcpu FP state if other threads require to use FPU.
>>> + * This simulates an FP unavailable fault.
>>> + *
>>> + * It requires to be called with preemption disabled.
>>> + */
>>> +static inline void kvmppc_load_guest_fp(struct kvm_vcpu *vcpu)
>>> +{
>>> +#ifdef CONFIG_PPC_FPU
>>> +   if (vcpu->fpu_active && !(current->thread.regs->msr & MSR_FP)) {
>>> +   load_up_fpu();
>>> +   current->thread.regs->msr |= MSR_FP;
>> 
>> I'm having a hard time to grasp when shared->msr, shadow_msr and regs->msr 
>> is used in your code :).
> 
> shadow_msr is the real MSR.
> 
> shared->msr is the guest's view of MSR.
> 
> current->thread.regs->msr is nominally userspace's MSR.  In this case we
> use it to tell host Linux that FP is in use and must be saved on context
> switch.  The actual userspace MSR_FP is known to be clear at this point
> because we called enable_kernel_fp().  It will be clear again when we
> return to userspace because we'll call giveup_fpu().

Ah, this is thread.regs, not vcpu.regs. Sorry, I misread that part. This way it 
obviously makes a lot more sense.


Alex

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev


[git pull] Please pull powerpc.git merge branch

2012-01-09 Thread Kumar Gala
The following changes since commit a0e86bd4252519321b0d102dc4ed90557aa7bee9:

  audit: always follow va_copy() with va_end() (2012-01-08 14:15:21 -0800)

are available in the git repository at:
  git://git.kernel.org/pub/scm/linux/kernel/git/galak/powerpc.git merge

Michael Neuling (1):
  powerpc: fix compile error with 85xx/p1022_ds.c

 arch/powerpc/platforms/85xx/p1022_ds.c |1 +
 1 files changed, 1 insertions(+), 0 deletions(-)
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev


Re: [RFC PATCH 15/16] KVM: PPC: booke: standard PPC floating point support

2012-01-09 Thread Scott Wood
On 01/09/2012 11:48 AM, Alexander Graf wrote:
> 
> On 21.12.2011, at 02:34, Scott Wood wrote:
>> +#ifdef CONFIG_PPC_FPU
>> +/* Save userspace FPU state in stack */
>> +enable_kernel_fp();
>> +memcpy(fpr, current->thread.fpr, sizeof(current->thread.fpr));
>> +fpscr = current->thread.fpscr.val;
>> +fpexc_mode = current->thread.fpexc_mode;
>> +
>> +/* Restore guest FPU state to thread */
>> +memcpy(current->thread.fpr, vcpu->arch.fpr, sizeof(vcpu->arch.fpr));
>> +current->thread.fpscr.val = vcpu->arch.fpscr;
>> +
>> +/*
>> + * Since we can't trap on MSR_FP in GS-mode, we consider the guest
>> + * as always using the FPU.  Kernel usage of FP (via
>> + * enable_kernel_fp()) in this thread must not occur while
>> + * vcpu->fpu_active is set.
>> + */
>> +vcpu->fpu_active = 1;
>> +
>> +kvmppc_load_guest_fp(vcpu);
>> +#endif
> 
> Do you think it's possible to combine this with the book3s_pr code, so we 
> don't duplicate too much here?

book3s_pr is a bit different in that it can trap when the guest sets
MSR[FP].

Maybe a few lines could be factored out (the first memcpy, fpscr,
fpexc_mode).  I'm not sure that it makes sense given the lack of
isolation between what it's doing and what the rest of the code is doing.

>> +/*
>> + * Load up guest vcpu FP state if it's needed.
>> + * It also set the MSR_FP in thread so that host know
>> + * we're holding FPU, and then host can help to save
>> + * guest vcpu FP state if other threads require to use FPU.
>> + * This simulates an FP unavailable fault.
>> + *
>> + * It requires to be called with preemption disabled.
>> + */
>> +static inline void kvmppc_load_guest_fp(struct kvm_vcpu *vcpu)
>> +{
>> +#ifdef CONFIG_PPC_FPU
>> +if (vcpu->fpu_active && !(current->thread.regs->msr & MSR_FP)) {
>> +load_up_fpu();
>> +current->thread.regs->msr |= MSR_FP;
> 
> I'm having a hard time to grasp when shared->msr, shadow_msr and regs->msr is 
> used in your code :).

shadow_msr is the real MSR.

shared->msr is the guest's view of MSR.

current->thread.regs->msr is nominally userspace's MSR.  In this case we
use it to tell host Linux that FP is in use and must be saved on context
switch.  The actual userspace MSR_FP is known to be clear at this point
because we called enable_kernel_fp().  It will be clear again when we
return to userspace because we'll call giveup_fpu().

-Scott

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev


Re: [PATCH v2 3/3] KVM: PPC: epapr: install ev_idle hcall for e500 guest

2012-01-09 Thread Scott Wood
On 01/05/2012 03:06 AM, Liu Yu wrote:
> diff --git a/arch/powerpc/kernel/idle_e500.S b/arch/powerpc/kernel/idle_e500.S
> index 3e2b95c..6ea95f0 100644
> --- a/arch/powerpc/kernel/idle_e500.S
> +++ b/arch/powerpc/kernel/idle_e500.S
> @@ -85,6 +85,23 @@ END_FTR_SECTION_IFSET(CPU_FTR_L2CSR|CPU_FTR_CAN_NAP)
>  2:   b   2b
>  #endif /* !E500MC */
>  
> +#ifdef CONFIG_KVM_GUEST
> +/*
> + * r3 contains the pointer to in[8]
> + * r4 contains the pointer to out[8]
> + * r5 contains the hcall vendor and nr
> + * r6 contains the handler which send hcall
> + */
> +_GLOBAL(e500_ev_idle)
> + rlwinm  r7,r1,0,0,31-THREAD_SHIFT   /* current thread_info */
> + lwz r8,TI_LOCAL_FLAGS(r7)   /* set napping bit */
> + ori r8,r8,_TLF_NAPPING  /* so when we take an exception */
> + stw r8,TI_LOCAL_FLAGS(r7)   /* it will return to our caller */
> + wrteei  1
> + mtctr   r6
> + bctr
> +#endif /* KVM_GUEST */

You'll need to branch back to the hcall invocation in an infinite loop
-- the only way we should leave is via an interrupt.

> +static void kvm_hcall_idle(void)
> +{
> +#ifdef CONFIG_KVM_E500
> + ulong in[8];
> + ulong out[8];
> +
> + e500_ev_idle(in, out, HC_VENDOR_EPAPR | HC_EV_IDLE, kvm_hypercall);
> +#endif
> +}

kvm_hypercall is C code.  As stated before, you cannot use C code while
_TLF_NAPPING is set.

> +static bool kvm_para_has_idle(void)
> +{
> +#ifdef CONFIG_BOOKE
> + return epapr_hcall_has_idle;
> +#else
> + return false;
> +#endif
> +}
> +
>  static int __init kvm_guest_init(void)
>  {
>   if (!kvm_para_available())
> @@ -594,6 +614,10 @@ static int __init kvm_guest_init(void)
>   powersave_nap = 1;
>  #endif
>  
> + /* Install hcall based power_save for guest kernel */
> + if (kvm_para_has_idle())
> + ppc_md.power_save = kvm_hcall_idle;

Why did you only move it halfway out of KVM code?  ePAPR features such
as idle hcall should work on any ePAPR hypervisor, even with all KVM
code disabled.

Plus everything Alex said. :-)

-Scott

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev


Re: [PATCH] powerpc/85xx: Add P1024rdb dts support

2012-01-09 Thread Scott Wood
On 01/09/2012 02:37 AM, b29...@freescale.com wrote:
> +/include/ "p1024rdb.dtsi"
> +/include/ "fsl/p1020si-post.dtsi"

Is p1024 100% software-compatible with p1020?

They have different manuals...

-Scott

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev


Re: [SDK v1.2][PATCH 1/2 v3] powerpc/85xx: Add dts for P1021RDB-PC board

2012-01-09 Thread Scott Wood
On 01/09/2012 12:53 AM, Xu Jiucheng wrote:
> + nand@1,0 {
> + #address-cells = <1>;
> + #size-cells = <1>;
> + compatible = "fsl,p1020-fcm-nand",
> +  "fsl,elbc-fcm-nand";

s/p1020/p1021/

-Scott

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev


Re: [PATCH 1/2] dtc: Implement -d option to write out a dependency file

2012-01-09 Thread Jon Loeliger
> This will allow callers to rebuild .dtb files when any of the /include/d
> .dtsi files are modified, not just the top-level .dts file.
> 
> Signed-off-by: Stephen Warren 
> ---
> This patch is against the Linux kernel's copy of dtc, but it applies to
> upstream dtc with a couple of trivial conflicts. I can post a version for
> upstream dtc as well if desired.

If it does go upstream into Linux proper, we should
definitely have it in the main DTC repository.
So if you would, please send me a path that applies there.

Thanks,
jdl

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev


Re: [RFC PATCH 16/16] KVM: PPC: e500mc support

2012-01-09 Thread Scott Wood
On 01/09/2012 10:33 AM, Avi Kivity wrote:
> On 12/21/2011 03:34 AM, Scott Wood wrote:
>> Add processor support for e500mc, using hardware virtualization support
>> (GS-mode).
>>
>> Current issues include:
>>  - No support for external proxy (coreint) interrupt mode in the guest.
>>
>> Includes work by Ashish Kalra ,
>> Varun Sethi , and
>> Liu Yu .
>>
> 
> Best to include their signoffs, if possible.

These patches are based in part on a bunch of different patches from
these people (for which I did receive signoffs).  I was reluctant to put
their signoff directly on the new patches, since I didn't want to make
it look like they had submitted the patch in anything resembling its
current form.  I wanted to give them credit for what they did, but not
blame for what I did with their code.

I've CCed Varun and Liu so they can sign off these versions of the
patches if they wish.  Ashish no longer works at Freescale, so I don't
have a currently valid e-mail address for him.

-Scott

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev


Re: [RFC PATCH 01/16] powerpc/booke: Set CPU_FTR_DEBUG_LVL_EXC on 32-bit

2012-01-09 Thread Scott Wood
On 01/09/2012 09:21 AM, Alexander Graf wrote:
> 
> On 21.12.2011, at 02:34, Scott Wood wrote:
> 
>> Currently 32-bit only cares about this for choice of exception
>> vector, which is done in core-specific code.  However, KVM will
>> want to distinguish as well.
>>
>> Signed-off-by: Scott Wood 
>> ---
>> arch/powerpc/include/asm/cputable.h |5 +++--
>> 1 files changed, 3 insertions(+), 2 deletions(-)
>>
>> diff --git a/arch/powerpc/include/asm/cputable.h 
>> b/arch/powerpc/include/asm/cputable.h
>> index e30442c..033ad30 100644
>> --- a/arch/powerpc/include/asm/cputable.h
>> +++ b/arch/powerpc/include/asm/cputable.h
>> @@ -375,7 +375,8 @@ extern const char *powerpc_base_platform;
>> #define CPU_FTRS_47X (CPU_FTRS_440x6)
>> #define CPU_FTRS_E200(CPU_FTR_USE_TB | CPU_FTR_SPE_COMP | \
>>  CPU_FTR_NODSISRALIGN | CPU_FTR_COHERENT_ICACHE | \
>> -CPU_FTR_UNIFIED_ID_CACHE | CPU_FTR_NOEXECUTE)
>> +CPU_FTR_UNIFIED_ID_CACHE | CPU_FTR_NOEXECUTE | \
>> +CPU_FTR_DEBUG_LVL_EXC)
> 
> KVM on E200?

This isn't a KVM patch, it's a patch to make CPU_FTR_DEBUG_LVL_EXC be
set properly on 32-bit chips.  e200 has this CPU feature.

-Scott

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev


Re: [RFC PATCH 15/16] KVM: PPC: booke: standard PPC floating point support

2012-01-09 Thread Alexander Graf

On 21.12.2011, at 02:34, Scott Wood wrote:

> e500mc has a normal PPC FPU, rather than SPE which is found
> on e500v1/v2.
> 
> Based on code from Liu Yu .
> 
> Signed-off-by: Scott Wood 
> ---
> arch/powerpc/include/asm/system.h |1 +
> arch/powerpc/kvm/booke.c  |   44 +
> arch/powerpc/kvm/booke.h  |   30 +
> 3 files changed, 75 insertions(+), 0 deletions(-)
> 
> diff --git a/arch/powerpc/include/asm/system.h 
> b/arch/powerpc/include/asm/system.h
> index e30a13d..0561356 100644
> --- a/arch/powerpc/include/asm/system.h
> +++ b/arch/powerpc/include/asm/system.h
> @@ -140,6 +140,7 @@ extern void via_cuda_init(void);
> extern void read_rtc_time(void);
> extern void pmac_find_display(void);
> extern void giveup_fpu(struct task_struct *);
> +extern void load_up_fpu(void);
> extern void disable_kernel_fp(void);
> extern void enable_kernel_fp(void);
> extern void flush_fp_to_thread(struct task_struct *);
> diff --git a/arch/powerpc/kvm/booke.c b/arch/powerpc/kvm/booke.c
> index cf63b93..4bf43f9 100644
> --- a/arch/powerpc/kvm/booke.c
> +++ b/arch/powerpc/kvm/booke.c
> @@ -460,6 +460,11 @@ void kvmppc_core_prepare_to_enter(struct kvm_vcpu *vcpu)
> int kvmppc_vcpu_run(struct kvm_run *kvm_run, struct kvm_vcpu *vcpu)
> {
>   int ret;
> +#ifdef CONFIG_PPC_FPU
> + unsigned int fpscr;
> + int fpexc_mode;
> + u64 fpr[32];
> +#endif
> 
>   if (!vcpu->arch.sane) {
>   kvm_run->exit_reason = KVM_EXIT_INTERNAL_ERROR;
> @@ -482,7 +487,46 @@ int kvmppc_vcpu_run(struct kvm_run *kvm_run, struct 
> kvm_vcpu *vcpu)
>   }
> 
>   kvm_guest_enter();
> +
> +#ifdef CONFIG_PPC_FPU
> + /* Save userspace FPU state in stack */
> + enable_kernel_fp();
> + memcpy(fpr, current->thread.fpr, sizeof(current->thread.fpr));
> + fpscr = current->thread.fpscr.val;
> + fpexc_mode = current->thread.fpexc_mode;
> +
> + /* Restore guest FPU state to thread */
> + memcpy(current->thread.fpr, vcpu->arch.fpr, sizeof(vcpu->arch.fpr));
> + current->thread.fpscr.val = vcpu->arch.fpscr;
> +
> + /*
> +  * Since we can't trap on MSR_FP in GS-mode, we consider the guest
> +  * as always using the FPU.  Kernel usage of FP (via
> +  * enable_kernel_fp()) in this thread must not occur while
> +  * vcpu->fpu_active is set.
> +  */
> + vcpu->fpu_active = 1;
> +
> + kvmppc_load_guest_fp(vcpu);
> +#endif

Do you think it's possible to combine this with the book3s_pr code, so we don't 
duplicate too much here?

> +
>   ret = __kvmppc_vcpu_run(kvm_run, vcpu);
> +
> +#ifdef CONFIG_PPC_FPU
> + kvmppc_save_guest_fp(vcpu);
> +
> + vcpu->fpu_active = 0;
> +
> + /* Save guest FPU state from thread */
> + memcpy(vcpu->arch.fpr, current->thread.fpr, sizeof(vcpu->arch.fpr));
> + vcpu->arch.fpscr = current->thread.fpscr.val;
> +
> + /* Restore userspace FPU state from stack */
> + memcpy(current->thread.fpr, fpr, sizeof(current->thread.fpr));
> + current->thread.fpscr.val = fpscr;
> + current->thread.fpexc_mode = fpexc_mode;
> +#endif
> +
>   kvm_guest_exit();
> 
> out:
> diff --git a/arch/powerpc/kvm/booke.h b/arch/powerpc/kvm/booke.h
> index d53bcf2..3bf5eda 100644
> --- a/arch/powerpc/kvm/booke.h
> +++ b/arch/powerpc/kvm/booke.h
> @@ -96,4 +96,34 @@ enum int_class {
> 
> void kvmppc_set_pending_interrupt(struct kvm_vcpu *vcpu, enum int_class type);
> 
> +/*
> + * Load up guest vcpu FP state if it's needed.
> + * It also set the MSR_FP in thread so that host know
> + * we're holding FPU, and then host can help to save
> + * guest vcpu FP state if other threads require to use FPU.
> + * This simulates an FP unavailable fault.
> + *
> + * It requires to be called with preemption disabled.
> + */
> +static inline void kvmppc_load_guest_fp(struct kvm_vcpu *vcpu)
> +{
> +#ifdef CONFIG_PPC_FPU
> + if (vcpu->fpu_active && !(current->thread.regs->msr & MSR_FP)) {
> + load_up_fpu();
> + current->thread.regs->msr |= MSR_FP;

I'm having a hard time to grasp when shared->msr, shadow_msr and regs->msr is 
used in your code :).


Alex

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev


Re: [RFC PATCH 16/16] KVM: PPC: e500mc support

2012-01-09 Thread Avi Kivity
On 12/21/2011 03:34 AM, Scott Wood wrote:
> Add processor support for e500mc, using hardware virtualization support
> (GS-mode).
>
> Current issues include:
>  - No support for external proxy (coreint) interrupt mode in the guest.
>
> Includes work by Ashish Kalra ,
> Varun Sethi , and
> Liu Yu .
>

Best to include their signoffs, if possible.

-- 
error compiling committee.c: too many arguments to function

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev


Re: [RFC PATCH 12/16] KVM: PPC: e500: emulate tlbilx

2012-01-09 Thread Alexander Graf

On 21.12.2011, at 02:34, Scott Wood wrote:

> tlbilx is the new, preferred invalidation instruction.  It is not
> found on e500 prior to e500mc, but there should be no harm in
> supporting it on all e500.
> 
> Based on code from Ashish Kalra .
> 
> Signed-off-by: Scott Wood 
> ---
> arch/powerpc/kvm/e500.h |1 +
> arch/powerpc/kvm/e500_emulate.c |9 ++
> arch/powerpc/kvm/e500_tlb.c |   52 +++
> 3 files changed, 62 insertions(+), 0 deletions(-)
> 
> diff --git a/arch/powerpc/kvm/e500.h b/arch/powerpc/kvm/e500.h
> index f4dee55..ce3f163 100644
> --- a/arch/powerpc/kvm/e500.h
> +++ b/arch/powerpc/kvm/e500.h
> @@ -124,6 +124,7 @@ int kvmppc_e500_emul_mt_mmucsr0(struct kvmppc_vcpu_e500 
> *vcpu_e500,
> int kvmppc_e500_emul_tlbwe(struct kvm_vcpu *vcpu);
> int kvmppc_e500_emul_tlbre(struct kvm_vcpu *vcpu);
> int kvmppc_e500_emul_tlbivax(struct kvm_vcpu *vcpu, int ra, int rb);
> +int kvmppc_e500_emul_tlbilx(struct kvm_vcpu *vcpu, int rt, int ra, int rb);
> int kvmppc_e500_emul_tlbsx(struct kvm_vcpu *vcpu, int rb);
> int kvmppc_e500_tlb_init(struct kvmppc_vcpu_e500 *vcpu_e500);
> void kvmppc_e500_tlb_uninit(struct kvmppc_vcpu_e500 *vcpu_e500);
> diff --git a/arch/powerpc/kvm/e500_emulate.c b/arch/powerpc/kvm/e500_emulate.c
> index c80794d..af02c18 100644
> --- a/arch/powerpc/kvm/e500_emulate.c
> +++ b/arch/powerpc/kvm/e500_emulate.c
> @@ -22,6 +22,7 @@
> #define XOP_TLBSX   914
> #define XOP_TLBRE   946
> #define XOP_TLBWE   978
> +#define XOP_TLBILX  18
> 
> int kvmppc_core_emulate_op(struct kvm_run *run, struct kvm_vcpu *vcpu,
>unsigned int inst, int *advance)
> @@ -29,6 +30,7 @@ int kvmppc_core_emulate_op(struct kvm_run *run, struct 
> kvm_vcpu *vcpu,
>   int emulated = EMULATE_DONE;
>   int ra;
>   int rb;
> + int rt;
> 
>   switch (get_op(inst)) {
>   case 31:
> @@ -47,6 +49,13 @@ int kvmppc_core_emulate_op(struct kvm_run *run, struct 
> kvm_vcpu *vcpu,
>   emulated = kvmppc_e500_emul_tlbsx(vcpu,rb);
>   break;
> 
> + case XOP_TLBILX:
> + ra = get_ra(inst);
> + rb = get_rb(inst);
> + rt = get_rt(inst);
> + emulated = kvmppc_e500_emul_tlbilx(vcpu, rt, ra, rb);
> + break;
> +
>   case XOP_TLBIVAX:
>   ra = get_ra(inst);
>   rb = get_rb(inst);
> diff --git a/arch/powerpc/kvm/e500_tlb.c b/arch/powerpc/kvm/e500_tlb.c
> index 031fd5b..121cd68 100644
> --- a/arch/powerpc/kvm/e500_tlb.c
> +++ b/arch/powerpc/kvm/e500_tlb.c
> @@ -631,6 +631,58 @@ int kvmppc_e500_emul_tlbivax(struct kvm_vcpu *vcpu, int 
> ra, int rb)
>   return EMULATE_DONE;
> }
> 
> +static void tlbilx_all(struct kvmppc_vcpu_e500 *vcpu_e500, int tlbsel,
> +int pid, int rt)
> +{
> + struct kvm_book3e_206_tlb_entry *tlbe;
> + int tid, esel;
> +
> + /* invalidate all entries */
> + for (esel = 0; esel < vcpu_e500->gtlb_params[tlbsel].entries; esel++) {

By dereferencing the struct inside the loop you're creating a new load on every 
iteration. Please use a variable for entries.

> + tlbe = get_entry(vcpu_e500, tlbsel, esel);
> + tid = get_tlb_tid(tlbe);
> + if (rt == 0 || tid == pid) {
> + inval_gtlbe_on_host(vcpu_e500, tlbsel, esel);
> + kvmppc_e500_gtlbe_invalidate(vcpu_e500, tlbsel, esel);
> + }
> + }
> +}
> +
> +static void tlbilx_one(struct kvmppc_vcpu_e500 *vcpu_e500, int pid,
> +int ra, int rb)
> +{
> + int tlbsel, esel;
> + gva_t ea;
> +
> + ea = kvmppc_get_gpr(&vcpu_e500->vcpu, rb);
> + if (ra)
> + ea += kvmppc_get_gpr(&vcpu_e500->vcpu, ra);
> +
> + for (tlbsel = 0; tlbsel < 2; tlbsel++) {
> + esel = kvmppc_e500_tlb_index(vcpu_e500, ea, tlbsel, pid, -1);
> + if (esel >= 0) {
> + inval_gtlbe_on_host(vcpu_e500, tlbsel, esel);
> + kvmppc_e500_gtlbe_invalidate(vcpu_e500, tlbsel, esel);
> + break;
> + }
> + }
> +}
> +
> +int kvmppc_e500_emul_tlbilx(struct kvm_vcpu *vcpu, int rt, int ra, int rb)
> +{
> + struct kvmppc_vcpu_e500 *vcpu_e500 = to_e500(vcpu);
> + int pid = get_cur_spid(vcpu);
> +
> + if (rt == 0 || rt == 1) {
> + tlbilx_all(vcpu_e500, 0, pid, rt);
> + tlbilx_all(vcpu_e500, 1, pid, rt);
> + } else if (rt == 3) {

too many magic constants :)


Alex

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev


Re: [RFC PATCH 04/16] KVM: PPC: factor out lpid allocator from book3s_64_mmu_hv

2012-01-09 Thread Alexander Graf

On 21.12.2011, at 02:34, Scott Wood wrote:

> We'll use it on e500mc as well.
> 
> Signed-off-by: Scott Wood 
> ---
> arch/powerpc/include/asm/kvm_book3s.h |3 ++
> arch/powerpc/include/asm/kvm_booke.h  |3 ++
> arch/powerpc/include/asm/kvm_ppc.h|5 
> arch/powerpc/kvm/book3s_64_mmu_hv.c   |   26 +---
> arch/powerpc/kvm/powerpc.c|   34 +
> 5 files changed, 55 insertions(+), 16 deletions(-)
> 
> diff --git a/arch/powerpc/include/asm/kvm_book3s.h 
> b/arch/powerpc/include/asm/kvm_book3s.h
> index 60e069e..58c8bec 100644
> --- a/arch/powerpc/include/asm/kvm_book3s.h
> +++ b/arch/powerpc/include/asm/kvm_book3s.h
> @@ -448,4 +448,7 @@ static inline bool kvmppc_critical_section(struct 
> kvm_vcpu *vcpu)
> 
> #define INS_DCBZ  0x7c0007ec
> 
> +/* LPIDs we support with this build -- runtime limit may be lower */
> +#define KVMPPC_NR_LPIDS  (LPID_RSVD + 1)
> +
> #endif /* __ASM_KVM_BOOK3S_H__ */
> diff --git a/arch/powerpc/include/asm/kvm_booke.h 
> b/arch/powerpc/include/asm/kvm_booke.h
> index e20c162..138118e 100644
> --- a/arch/powerpc/include/asm/kvm_booke.h
> +++ b/arch/powerpc/include/asm/kvm_booke.h
> @@ -23,6 +23,9 @@
> #include 
> #include 
> 
> +/* LPIDs we support with this build -- runtime limit may be lower */
> +#define KVMPPC_NR_LPIDS64
> +
> static inline void kvmppc_set_gpr(struct kvm_vcpu *vcpu, int num, ulong val)
> {
>   vcpu->arch.regs.gpr[num] = val;
> diff --git a/arch/powerpc/include/asm/kvm_ppc.h 
> b/arch/powerpc/include/asm/kvm_ppc.h
> index a61b5b5..5524f88 100644
> --- a/arch/powerpc/include/asm/kvm_ppc.h
> +++ b/arch/powerpc/include/asm/kvm_ppc.h
> @@ -202,4 +202,9 @@ int kvm_vcpu_ioctl_config_tlb(struct kvm_vcpu *vcpu,
> int kvm_vcpu_ioctl_dirty_tlb(struct kvm_vcpu *vcpu,
>struct kvm_dirty_tlb *cfg);
> 
> +long kvmppc_alloc_lpid(void);
> +void kvmppc_claim_lpid(long lpid);
> +void kvmppc_free_lpid(long lpid);
> +void kvmppc_init_lpid(unsigned long nr_lpids);
> +
> #endif /* __POWERPC_KVM_PPC_H__ */
> diff --git a/arch/powerpc/kvm/book3s_64_mmu_hv.c 
> b/arch/powerpc/kvm/book3s_64_mmu_hv.c
> index 66d6452..45b6f0e 100644
> --- a/arch/powerpc/kvm/book3s_64_mmu_hv.c
> +++ b/arch/powerpc/kvm/book3s_64_mmu_hv.c
> @@ -36,13 +36,11 @@
> 
> /* POWER7 has 10-bit LPIDs, PPC970 has 6-bit LPIDs */
> #define MAX_LPID_970  63
> -#define NR_LPIDS (LPID_RSVD + 1)
> -unsigned long lpid_inuse[BITS_TO_LONGS(NR_LPIDS)];
> 
> long kvmppc_alloc_hpt(struct kvm *kvm)
> {
>   unsigned long hpt;
> - unsigned long lpid;
> + long lpid;
>   struct revmap_entry *rev;
> 
>   /* Allocate guest's hashed page table */
> @@ -62,14 +60,9 @@ long kvmppc_alloc_hpt(struct kvm *kvm)
>   }
>   kvm->arch.revmap = rev;
> 
> - /* Allocate the guest's logical partition ID */
> - do {
> - lpid = find_first_zero_bit(lpid_inuse, NR_LPIDS);
> - if (lpid >= NR_LPIDS) {
> - pr_err("kvm_alloc_hpt: No LPIDs free\n");
> - goto out_freeboth;
> - }
> - } while (test_and_set_bit(lpid, lpid_inuse));
> + lpid = kvmppc_alloc_lpid();
> + if (lpid < 0)
> + goto out_freeboth;
> 
>   kvm->arch.sdr1 = __pa(hpt) | (HPT_ORDER - 18);
>   kvm->arch.lpid = lpid;
> @@ -86,7 +79,7 @@ long kvmppc_alloc_hpt(struct kvm *kvm)
> 
> void kvmppc_free_hpt(struct kvm *kvm)
> {
> - clear_bit(kvm->arch.lpid, lpid_inuse);
> + kvmppc_free_lpid(kvm->arch.lpid);
>   vfree(kvm->arch.revmap);
>   free_pages(kvm->arch.hpt_virt, HPT_ORDER - PAGE_SHIFT);
> }
> @@ -158,8 +151,7 @@ int kvmppc_mmu_hv_init(void)
>   if (!cpu_has_feature(CPU_FTR_HVMODE))
>   return -EINVAL;
> 
> - memset(lpid_inuse, 0, sizeof(lpid_inuse));
> -
> + /* POWER7 has 10-bit LPIDs, PPC970 and e500mc have 6-bit LPIDs */
>   if (cpu_has_feature(CPU_FTR_ARCH_206)) {
>   host_lpid = mfspr(SPRN_LPID);   /* POWER7 */
>   rsvd_lpid = LPID_RSVD;
> @@ -168,9 +160,11 @@ int kvmppc_mmu_hv_init(void)
>   rsvd_lpid = MAX_LPID_970;
>   }
> 
> - set_bit(host_lpid, lpid_inuse);
> + kvmppc_init_lpid(rsvd_lpid + 1);
> +
> + kvmppc_claim_lpid(host_lpid);
>   /* rsvd_lpid is reserved for use in partition switching */
> - set_bit(rsvd_lpid, lpid_inuse);
> + kvmppc_claim_lpid(rsvd_lpid);
> 
>   return 0;
> }
> diff --git a/arch/powerpc/kvm/powerpc.c b/arch/powerpc/kvm/powerpc.c
> index 64c738dc..42701e5 100644
> --- a/arch/powerpc/kvm/powerpc.c
> +++ b/arch/powerpc/kvm/powerpc.c

Paul, does this work for you? IIRC you need this code to be available from real 
mode, which powerpc.c isn't in, right?


Alex

> @@ -800,6 +800,40 @@ out:
>   return r;
> }
> 
> +static unsigned long lpid_inuse[BITS_TO_LONGS(KVMPPC_NR_LPIDS)];
> +static unsigned long nr_lpids;
> +
> +long kvmppc_alloc_lpid(void)
>

Re: [RFC PATCH 01/16] powerpc/booke: Set CPU_FTR_DEBUG_LVL_EXC on 32-bit

2012-01-09 Thread Alexander Graf

On 21.12.2011, at 02:34, Scott Wood wrote:

> Currently 32-bit only cares about this for choice of exception
> vector, which is done in core-specific code.  However, KVM will
> want to distinguish as well.
> 
> Signed-off-by: Scott Wood 
> ---
> arch/powerpc/include/asm/cputable.h |5 +++--
> 1 files changed, 3 insertions(+), 2 deletions(-)
> 
> diff --git a/arch/powerpc/include/asm/cputable.h 
> b/arch/powerpc/include/asm/cputable.h
> index e30442c..033ad30 100644
> --- a/arch/powerpc/include/asm/cputable.h
> +++ b/arch/powerpc/include/asm/cputable.h
> @@ -375,7 +375,8 @@ extern const char *powerpc_base_platform;
> #define CPU_FTRS_47X  (CPU_FTRS_440x6)
> #define CPU_FTRS_E200 (CPU_FTR_USE_TB | CPU_FTR_SPE_COMP | \
>   CPU_FTR_NODSISRALIGN | CPU_FTR_COHERENT_ICACHE | \
> - CPU_FTR_UNIFIED_ID_CACHE | CPU_FTR_NOEXECUTE)
> + CPU_FTR_UNIFIED_ID_CACHE | CPU_FTR_NOEXECUTE | \
> + CPU_FTR_DEBUG_LVL_EXC)

KVM on E200?


Alex

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev


RE: Mac address in the DT

2012-01-09 Thread Joakim Tjernlund
 wrote on 2012/01/09 15:28:54:
>
>
> Hi Joakim,
>
> I have tried it but it doesn't work.
>
> Just now found that with single ' quotes the entire sequence it works.
> >Setenv set_mac 'cp 0xffec 0x10 1024;fdt addr 0xc0 8192;fdt set 
> >/soc8272@f000/ethernet@24000 mac-address "[00 44 00 55 00 66]";erase 
> >0xffec 0xffec4000;cp 0xc0 0xffec 1024;bootm 0xfe06 - 
> >0xffec'
>
> > run set_mac
>
> For the above command I want to replace the mac address with the ethaddr> How 
> do I do that. I tried $ethaddr but I get extra : characters.
>
> >Setenv set_mac 'cp 0xffec 0x10 1024;fdt addr 0xc0 8192;fdt set 
> >/soc8272@f000/ethernet@24000 mac-address $ethaddr;erase 0xffec 
> >0xffec4000;cp 0xc0 0xffec 1024;bootm 0xfe06 - 0xffec'

Of course you do, ethaddr has a different syntax and contains :

Anyway you should not have to set mac address manually like you do, u-boot will 
do it for you if you
have configured u-boot correctly and have a proper dtb tree. Check the u-boot 
code and the many dts files in linux
under arch/powerpc/boot/dts

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev


RE: Mac address in the DT

2012-01-09 Thread smitha.vanga
 
Hi Joakim,

I have tried it but it doesn't work.

Just now found that with single ' quotes the entire sequence it works.
>Setenv set_mac 'cp 0xffec 0x10 1024;fdt addr 0xc0 8192;fdt set 
>/soc8272@f000/ethernet@24000 mac-address "[00 44 00 55 00 66]";erase 
>0xffec 0xffec4000;cp 0xc0 0xffec 1024;bootm 0xfe06 - 
>0xffec'

> run set_mac

For the above command I want to replace the mac address with the ethaddr> How 
do I do that. I tried $ethaddr but I get extra : characters.

>Setenv set_mac 'cp 0xffec 0x10 1024;fdt addr 0xc0 8192;fdt set 
>/soc8272@f000/ethernet@24000 mac-address $ethaddr;erase 0xffec 
>0xffec4000;cp 0xc0 0xffec 1024;bootm 0xfe06 - 0xffec'

Regards,
Smitha
Please do not print this email unless it is absolutely necessary. 

The information contained in this electronic message and any attachments to 
this message are intended for the exclusive use of the addressee(s) and may 
contain proprietary, confidential or privileged information. If you are not the 
intended recipient, you should not disseminate, distribute or copy this e-mail. 
Please notify the sender immediately and destroy all copies of this message and 
any attachments. 

WARNING: Computer viruses can be transmitted via email. The recipient should 
check this email and any attachments for the presence of viruses. The company 
accepts no liability for any damage caused by any virus transmitted by this 
email. 

www.wipro.com
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev


Re: Mac address in the DT

2012-01-09 Thread Joakim Tjernlund
>
> Hi Wolfgang,
>
> I need to automate a sequence of commands. To do that I am setting a 
> environment variable with the sequence of commands.
> And using run command run the environment variable.
>
> But one of the command uses " in the command. So how do I save the command 
> with quotes.
>
> Below is the command which I want to set in the environment variable.
>
> setenv set_mac ""cp 0xffec 0x10 1024;fdt addr 0x10 8192;fdt set 
> /soc8272@f000/ethernet@24000 mac-address "[00 22 00 33 00 55]""
>
> But when I saveenv the command doesnot get save as fdt set 
> /soc8272@f000/ethernet@24000 mac-address "[00 22 00 33 00 55]"
>
> Thanks & Regards,
> Smitha

Have you tried ...\"[00 22 00 33 00 55]\"" ?

 Jocke

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev


Re: [PATCH v2 3/3] KVM: PPC: epapr: install ev_idle hcall for e500 guest

2012-01-09 Thread Alexander Graf

On 05.01.2012, at 10:06, Liu Yu wrote:

> If the guest hypervisor node contains "has-idle" property.
> 
> Signed-off-by: Liu Yu 
> ---
> v2:
> 1. move the idle code into assembly.
> 2. move the part that check "has-idle" into epapr code.
> 
> arch/powerpc/include/asm/epapr_hcalls.h |1 +
> arch/powerpc/include/asm/machdep.h  |5 +
> arch/powerpc/kernel/epapr_para.c|4 
> arch/powerpc/kernel/idle_e500.S |   17 +
> arch/powerpc/kernel/kvm.c   |   24 
> 5 files changed, 51 insertions(+), 0 deletions(-)
> 
> diff --git a/arch/powerpc/include/asm/epapr_hcalls.h 
> b/arch/powerpc/include/asm/epapr_hcalls.h
> index c4b86e4..566805e 100644
> --- a/arch/powerpc/include/asm/epapr_hcalls.h
> +++ b/arch/powerpc/include/asm/epapr_hcalls.h
> @@ -150,6 +150,7 @@
> 
> extern u32 *epapr_hcall_insts;
> extern int epapr_hcall_insts_len;
> +extern bool epapr_hcall_has_idle;
> 
> static inline void epapr_get_hcall_insts(u32 **instp, int *lenp)
> {
> diff --git a/arch/powerpc/include/asm/machdep.h 
> b/arch/powerpc/include/asm/machdep.h
> index 47cacdd..7e56abf 100644
> --- a/arch/powerpc/include/asm/machdep.h
> +++ b/arch/powerpc/include/asm/machdep.h
> @@ -255,6 +255,11 @@ extern void power4_idle(void);
> extern void power7_idle(void);
> extern void ppc6xx_idle(void);
> extern void book3e_idle(void);
> +#ifdef CONFIG_KVM_GUEST
> +extern void e500_ev_idle(unsigned long *, unsigned long *, unsigned long,
> + unsigned long (*)(unsigned long *, unsigned long *,
> +  unsigned long));
> +#endif
> 
> /*
>  * ppc_md contains a copy of the machine description structure for the
> diff --git a/arch/powerpc/kernel/epapr_para.c 
> b/arch/powerpc/kernel/epapr_para.c
> index 714dcb3..1f37ddf 100644
> --- a/arch/powerpc/kernel/epapr_para.c
> +++ b/arch/powerpc/kernel/epapr_para.c
> @@ -22,6 +22,7 @@
> 
> u32 *epapr_hcall_insts;
> int epapr_hcall_insts_len;
> +bool epapr_hcall_has_idle;
> 
> static int __init epapr_para_init(void)
> {
> @@ -39,6 +40,9 @@ static int __init epapr_para_init(void)
>   epapr_hcall_insts_len = len;
>   }
> 
> + if (of_get_property(hyper_node, "has-idle", NULL))
> + epapr_hcall_has_idle = true;
> +
>   return 0;
> }
> 
> diff --git a/arch/powerpc/kernel/idle_e500.S b/arch/powerpc/kernel/idle_e500.S
> index 3e2b95c..6ea95f0 100644
> --- a/arch/powerpc/kernel/idle_e500.S
> +++ b/arch/powerpc/kernel/idle_e500.S
> @@ -85,6 +85,23 @@ END_FTR_SECTION_IFSET(CPU_FTR_L2CSR|CPU_FTR_CAN_NAP)
> 2:b   2b
> #endif /* !E500MC */
> 
> +#ifdef CONFIG_KVM_GUEST
> +/*
> + * r3 contains the pointer to in[8]
> + * r4 contains the pointer to out[8]
> + * r5 contains the hcall vendor and nr
> + * r6 contains the handler which send hcall
> + */
> +_GLOBAL(e500_ev_idle)

How is that specific to e500? Isn't it just the generic epapr implementation?

> + rlwinm  r7,r1,0,0,31-THREAD_SHIFT   /* current thread_info */
> + lwz r8,TI_LOCAL_FLAGS(r7)   /* set napping bit */
> + ori r8,r8,_TLF_NAPPING  /* so when we take an exception */
> + stw r8,TI_LOCAL_FLAGS(r7)   /* it will return to our caller */
> + wrteei  1

Except for this part of course :). But I'm sure we can generalize this.

> + mtctr   r6
> + bctr
> +#endif /* KVM_GUEST */
> +
> /*
>  * Return from NAP/DOZE mode, restore some CPU specific registers,
>  * r2 containing physical address of current.
> diff --git a/arch/powerpc/kernel/kvm.c b/arch/powerpc/kernel/kvm.c
> index 82a9137..8952e12 100644
> --- a/arch/powerpc/kernel/kvm.c
> +++ b/arch/powerpc/kernel/kvm.c
> @@ -29,6 +29,7 @@
> #include 
> #include 
> #include 
> +#include 
> 
> #define KVM_MAGIC_PAGE(-4096L)
> #define magic_var(x) KVM_MAGIC_PAGE + offsetof(struct kvm_vcpu_arch_shared, x)
> @@ -578,6 +579,25 @@ static __init void kvm_free_tmp(void)
>   }
> }
> 
> +static void kvm_hcall_idle(void)
> +{
> +#ifdef CONFIG_KVM_E500
> + ulong in[8];
> + ulong out[8];
> +
> + e500_ev_idle(in, out, HC_VENDOR_EPAPR | HC_EV_IDLE, kvm_hypercall);
> +#endif

... because then the ifdef goes away here too

> +}
> +
> +static bool kvm_para_has_idle(void)
> +{
> +#ifdef CONFIG_BOOKE
> + return epapr_hcall_has_idle;
> +#else
> + return false;
> +#endif

... this also shouldn't be an ifdef

> +}
> +
> static int __init kvm_guest_init(void)
> {
>   if (!kvm_para_available())
> @@ -594,6 +614,10 @@ static int __init kvm_guest_init(void)
>   powersave_nap = 1;
> #endif
> 
> + /* Install hcall based power_save for guest kernel */
> + if (kvm_para_has_idle())
> + ppc_md.power_save = kvm_hcall_idle;

The way it's now it would break kernels with this patch if we ever choose to 
implement hcall_idle for non-e500. Please make the code generic :)


Alex

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.oz

Mac address in the DT

2012-01-09 Thread smitha.vanga
 
Hi Wolfgang,

I need to automate a sequence of commands. To do that I am setting a 
environment variable with the sequence of commands.
And using run command run the environment variable.

But one of the command uses " in the command. So how do I save the command with 
quotes.

Below is the command which I want to set in the environment variable.

setenv set_mac ""cp 0xffec 0x10 1024;fdt addr 0x10 8192;fdt set 
/soc8272@f000/ethernet@24000 mac-address "[00 22 00 33 00 55]""

But when I saveenv the command doesnot get save as fdt set 
/soc8272@f000/ethernet@24000 mac-address "[00 22 00 33 00 55]"

Thanks & Regards,
Smitha


Please do not print this email unless it is absolutely necessary. 

The information contained in this electronic message and any attachments to 
this message are intended for the exclusive use of the addressee(s) and may 
contain proprietary, confidential or privileged information. If you are not the 
intended recipient, you should not disseminate, distribute or copy this e-mail. 
Please notify the sender immediately and destroy all copies of this message and 
any attachments. 

WARNING: Computer viruses can be transmitted via email. The recipient should 
check this email and any attachments for the presence of viruses. The company 
accepts no liability for any damage caused by any virus transmitted by this 
email. 

www.wipro.com
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev


Re: [PATCH 1/3] KVM: PPC: epapr: Factor out the epapr init

2012-01-09 Thread Alexander Graf

On 05.01.2012, at 10:06, Liu Yu wrote:

> from the kvm guest paravirt init code.

Your patch description could be slightly more ... verbose :)

> 
> Signed-off-by: Liu Yu 
> ---
> arch/powerpc/include/asm/epapr_hcalls.h |8 +
> arch/powerpc/kernel/Makefile|1 +
> arch/powerpc/kernel/epapr_para.c|   45 +++
> arch/powerpc/kernel/kvm.c   |9 +-
> 4 files changed, 62 insertions(+), 1 deletions(-)
> create mode 100644 arch/powerpc/kernel/epapr_para.c
> 
> diff --git a/arch/powerpc/include/asm/epapr_hcalls.h 
> b/arch/powerpc/include/asm/epapr_hcalls.h
> index f3b0c2c..c4b86e4 100644
> --- a/arch/powerpc/include/asm/epapr_hcalls.h
> +++ b/arch/powerpc/include/asm/epapr_hcalls.h
> @@ -148,6 +148,14 @@
> #define EV_HCALL_CLOBBERS2 EV_HCALL_CLOBBERS3, "r5"
> #define EV_HCALL_CLOBBERS1 EV_HCALL_CLOBBERS2, "r4"
> 
> +extern u32 *epapr_hcall_insts;
> +extern int epapr_hcall_insts_len;
> +
> +static inline void epapr_get_hcall_insts(u32 **instp, int *lenp)
> +{
> + *instp = epapr_hcall_insts;
> + *lenp = epapr_hcall_insts_len;

Why do we need this? Can't we just directly access the variables?

> +}
> 
> /*
>  * We use "uintptr_t" to define a register because it's guaranteed to be a
> diff --git a/arch/powerpc/kernel/Makefile b/arch/powerpc/kernel/Makefile
> index ce4f7f1..1052bbc 100644
> --- a/arch/powerpc/kernel/Makefile
> +++ b/arch/powerpc/kernel/Makefile
> @@ -134,6 +134,7 @@ ifneq ($(CONFIG_XMON)$(CONFIG_KEXEC),)
> obj-y += ppc_save_regs.o
> endif
> 
> +obj-$(CONFIG_BOOKE)  += epapr_para.o
> obj-$(CONFIG_KVM_GUEST)   += kvm.o kvm_emul.o
> 
> # Disable GCOV in odd or sensitive code
> diff --git a/arch/powerpc/kernel/epapr_para.c 
> b/arch/powerpc/kernel/epapr_para.c
> new file mode 100644
> index 000..714dcb3
> --- /dev/null
> +++ b/arch/powerpc/kernel/epapr_para.c
> @@ -0,0 +1,45 @@
> +/*
> + * ePAPR para-virtualization support.
> + *
> + * 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.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> + * GNU General Public License for more details.
> + *
> + * You should have received a copy of the GNU General Public License
> + * along with this program; if not, write to the Free Software
> + * Foundation, 51 Franklin Street, Fifth Floor, Boston, MA  02110-1301, USA.
> + *
> + * Copyright (C) 2012 Freescale Semiconductor, Inc.
> + */
> +
> +#include 
> +#include 
> +
> +u32 *epapr_hcall_insts;
> +int epapr_hcall_insts_len;
> +
> +static int __init epapr_para_init(void)
> +{
> + struct device_node *hyper_node;
> + u32 *insts;
> + int len;
> +
> + hyper_node = of_find_node_by_path("/hypervisor");
> + if (!hyper_node)
> + return -ENODEV;
> +
> + insts = (u32*)of_get_property(hyper_node, "hcall-instructions", &len);
> + if (!(len % 4) && (len >= (4 * 4))) {
> + epapr_hcall_insts = insts;
> + epapr_hcall_insts_len = len;
> + }

else error()?

> +
> + return 0;
> +}
> +
> +early_initcall(epapr_para_init);
> diff --git a/arch/powerpc/kernel/kvm.c b/arch/powerpc/kernel/kvm.c
> index b06bdae..82a9137 100644
> --- a/arch/powerpc/kernel/kvm.c
> +++ b/arch/powerpc/kernel/kvm.c
> @@ -28,6 +28,7 @@
> #include 
> #include 
> #include 
> +#include 
> 
> #define KVM_MAGIC_PAGE(-4096L)
> #define magic_var(x) KVM_MAGIC_PAGE + offsetof(struct kvm_vcpu_arch_shared, x)
> @@ -535,9 +536,10 @@ EXPORT_SYMBOL_GPL(kvm_hypercall);
> static int kvm_para_setup(void)
> {
>   extern u32 kvm_hypercall_start;
> - struct device_node *hyper_node;
>   u32 *insts;
>   int len, i;
> +#ifndef CONFIG_BOOKE

Ugh - now you're duplicating even more code. Why not completely unify it and 
always call epapr_get_hcall_insts() on all ppc platforms?


> + struct device_node *hyper_node;
> 
>   hyper_node = of_find_node_by_path("/hypervisor");
>   if (!hyper_node)
> @@ -548,6 +550,11 @@ static int kvm_para_setup(void)
>   return -1;
>   if (len > (4 * 4))
>   return -1;
> +#else
> + epapr_get_hcall_insts(&insts, &len);
> + if (insts == NULL)
> + return -1;
> +#endif   /* !BOOKE */
> 
>   for (i = 0; i < (len / 4); i++)
>   kvm_patch_ins(&(&kvm_hypercall_start)[i], insts[i]);
> -- 
> 1.6.4
> 
> 
> --
> To unsubscribe from this list: send the line "unsubscribe kvm-ppc" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozla

Re: Driver(s) for Synopsys' DesignWare USB OTG

2012-01-09 Thread Nikolai Zhubr

Hello Leo,

09.01.2012 9:17, Leo Li:

On Sun, Jan 8, 2012 at 8:56 PM, Nikolai Zhubr  wrote:

2012/1/8 Nikolai Zhubr:


Hello developers,

I'm trying to find/combine/fix a driver for Synopsys' DesignWare USB
controller. This thing is USB 2.0 host/slave/otg capable and is used in
various SoCs including Amlogic 8726M, Ralink RT305x, and probably more.


[...trim...]


I think the challenge of cooperation in situation like this is that
most companies don't like to advertise the source of the licensed IP
block.  Even the owner of the IP block doesn't list all users of the
block(maybe business requirement). It was really hard to find out if
the same IP has been used by anyone else.  Also the owner of this USB
IP block has been changed for several times(ARC, TDI, ChipIdea, and
Synopsys) which made it even more difficult to tell.


Ah, I see. It explains.
But communicating in private and keeping some public repository up to 
date would still be allowed I suppose?








I am not sure we can combine all Synopsys USB drivers to single file, but
we



Synopsys driver which I examine consists of 16 files (each of 2 versions),
200k lines total. I've already perpared some few smaller files for version
merging. So probably it is doable, but quite a lot of work, therefore I
wouldn't like it to be wasted.


I didn't examine the Synopsys driver myself.  But if it is so complex
as you described, it might be better to start with the in-tree drivers
IMO.


Unfortunately its far beyond my capabilities at the moment. Besides, it 
looks like huge effort has already been invested into the existing 
driver, so to me it seems fixing it rather than starting from scratch 
would be more realistic anyway (unless a company with unlimited 
resources step in...)



Thank you.
Nikolai.



- Leo




___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev


Re: Driver(s) for Synopsys' DesignWare USB OTG

2012-01-09 Thread Nikolai Zhubr

Hello Peter,

09.01.2012 6:12, Peter Chen:

I am not sure we can combine all Synopsys USB drivers to single file, but we


Synopsys driver which I examine consists of 16 files (each of 2
versions), 200k lines total. I've already perpared some few smaller
files for version merging. So probably it is doable, but quite a lot
of work, therefore I wouldn't like it to be wasted.

I mean one file is just a common udc driver for all Synopsys, not all usb file.
For ehci, I think it will be easier to use single file as well as
some specific SoC's quirks if needed.
For udc, as there is no standard spec for how usb device should be designed,
maybe different Synopsys IPs have a little different for work flow.
For otg, it  should be not difficult after we split PHY's operation
from the otg, as common otg operation is the same.



can try combine similar IP versions to one file, this work may need all Synopsys
USB IP driver maintainer work together.


Exactly. This is why I'm now trying to find all relevant people to
begin with.

I know someone(@Pengutronix and @linux.intel.com) is doing that. I think first
we should find which driver file at current code base is most capable and
compatible. I would like to help it, and verify it at Freescale i.MX SoCs.


Ok. Because my resources are limited (and my knowledge is actually 
limited too) I'll list what exactly I'm able (and willing) to do:


- split formatting/naming/uninteresting changes from algorythmical 
changes, prepare clean diffs as necessary (boring work, but anyway);

- bisect changes which make the driver stop working on my tablet;
- try whichever driver parameters and see what happens to my tablet;
- connect the tablet to a regular linux PC with USB cable, do some 
tests, capture traffic dumps as necessary;

- connect some devices to the tablet, do tests, report results;

and with some luck:
- prepare bufixes (depending very much on how simple is the bug).

So basically my effort would probably only be usefull in cooperation 
with someone with more knowledge and understanding of the situation in 
whole. Otherwise it would be more wasting of time.


If usb issues were solved, it might make some sense to try to create 
e.g. a generic openwrt target for 8726m-based tablet. (Of course it 
wouldn't allow to use the device for its intended purpose yet, but still 
might be interesting as kind of devel/testing reference option)



Thank you.
Nikolai.




Thank you.
Nikolai.

Please CC me, I'm not subscribed to the lists.






Thank you.
Nikolai.
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html






--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html





___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev


[PATCH 2/2][v2] mtd/nand: Fix IFC driver to support 2K NAND page

2012-01-09 Thread Prabhakar Kushwaha
1) OOB area should be updated irrespective of NAND page size. Earlier it was
updated only for 512byte NAND page.

2) During OOB update fbcr should be equal to OOB size.

Signed-off-by: Poonam Aggrwal 
Signed-off-by: Prabhakar Kushwaha 
---
 git://git.kernel.org/pub/scm/linux/kernel/git/galak/powerpc.git (branch next)

 This patch is created on top of IFC driver patch (already floated in mailing
 list). Please find their link:
 http://patchwork.ozlabs.org/patch/133315/
 http://patchwork.ozlabs.org/patch/133316/

 Tested on P1010RDB

  Changes for v2: Incorporated Scott's comments
- Added missed NAND_CMD_READOOB
- Updated function as per Scott's advice

 drivers/mtd/nand/fsl_ifc_nand.c |   21 +
 1 files changed, 9 insertions(+), 12 deletions(-)

diff --git a/drivers/mtd/nand/fsl_ifc_nand.c b/drivers/mtd/nand/fsl_ifc_nand.c
index c0529ea..52bd706d 100644
--- a/drivers/mtd/nand/fsl_ifc_nand.c
+++ b/drivers/mtd/nand/fsl_ifc_nand.c
@@ -440,22 +440,19 @@ static void fsl_ifc_cmdfunc(struct mtd_info *mtd, 
unsigned int command,
out_be32(&ifc->ifc_nand.nand_fir1,
 (IFC_FIR_OP_CW1 << IFC_NAND_FIR1_OP5_SHIFT));
 
-   if (column >= mtd->writesize) {
-   /* OOB area --> READOOB */
-   column -= mtd->writesize;
-   nand_fcr0 |= NAND_CMD_READOOB <<
-   IFC_NAND_FCR0_CMD0_SHIFT;
-   ifc_nand_ctrl->oob = 1;
-   } else if (column < 256)
-   /* First 256 bytes --> READ0 */
+   if (column >= mtd->writesize)
nand_fcr0 |=
-   NAND_CMD_READ0 << IFC_NAND_FCR0_CMD0_SHIFT;
+   NAND_CMD_READOOB << IFC_NAND_FCR0_CMD0_SHIFT;
else
-   /* Second 256 bytes --> READ1 */
nand_fcr0 |=
-   NAND_CMD_READ1 << IFC_NAND_FCR0_CMD0_SHIFT;
+   NAND_CMD_READ0 << IFC_NAND_FCR0_CMD0_SHIFT;
}
 
+   if (column >= mtd->writesize) {
+   /* OOB area --> READOOB */
+   column -= mtd->writesize;
+   ifc_nand_ctrl->oob = 1;
+   }
out_be32(&ifc->ifc_nand.nand_fcr0, nand_fcr0);
set_addr(mtd, column, page_addr, ifc_nand_ctrl->oob);
return;
@@ -466,7 +463,7 @@ static void fsl_ifc_cmdfunc(struct mtd_info *mtd, unsigned 
int command,
int full_page;
if (ifc_nand_ctrl->oob) {
out_be32(&ifc->ifc_nand.nand_fbcr,
-   ifc_nand_ctrl->index);
+   ifc_nand_ctrl->index - ifc_nand_ctrl->column);
full_page = 0;
} else {
out_be32(&ifc->ifc_nand.nand_fbcr, 0);
-- 
1.7.5.4


___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev


[PATCH 1/2][v2] mtd/nand:Fix wrong address read in is_blank()

2012-01-09 Thread Prabhakar Kushwaha
IFC NAND Machine calculates ECC on 512byte sector. Same is taken care in
fsl_ifc_run_command() while ECC status verification. Here buffer number is
calculated assuming 512byte sector and same is passed to is_blank.
However in is_blank() buffer address is calculated using mdt->writesize which is
wrong. It should be calculated on basis of ecc sector size.

Also, in fsl_ifc_run_command() bufferpage is calculated on the basis of ecc 
sector
size instead of hard coded value.

Signed-off-by: Poonam Aggrwal 
Signed-off-by: Prabhakar Kushwaha 
---
  git://git.kernel.org/pub/scm/linux/kernel/git/galak/powerpc.git (branch next)

 This patch is created on top of IFC driver patch (already floated in mailing
 list). Please find their link:
 http://patchwork.ozlabs.org/patch/133315/
 http://patchwork.ozlabs.org/patch/133316/

 Tested on P1010RDB

 Changes for v2: Incorporated Scott's comments
- Updated copyright
- is_blank - works on ecc buffer block 
- check_read_ecc() - Calculate actual ecc buffer number

 drivers/mtd/nand/fsl_ifc_nand.c |   14 --
 1 files changed, 8 insertions(+), 6 deletions(-)

diff --git a/drivers/mtd/nand/fsl_ifc_nand.c b/drivers/mtd/nand/fsl_ifc_nand.c
index 8475b88..c0529ea 100644
--- a/drivers/mtd/nand/fsl_ifc_nand.c
+++ b/drivers/mtd/nand/fsl_ifc_nand.c
@@ -1,7 +1,7 @@
 /*
  * Freescale Integrated Flash Controller NAND driver
  *
- * Copyright 2011 Freescale Semiconductor, Inc
+ * Copyright 2011,2012 Freescale Semiconductor, Inc
  *
  * Author: Dipen Dudhat 
  *
@@ -191,12 +191,12 @@ static int is_blank(struct mtd_info *mtd, unsigned int 
bufnum)
 {
struct nand_chip *chip = mtd->priv;
struct fsl_ifc_mtd *priv = chip->priv;
-   u8 __iomem *addr = priv->vbase + bufnum * (mtd->writesize * 2);
+   u8 __iomem *addr = priv->vbase + bufnum * chip->ecc.size;
u32 __iomem *mainarea = (u32 *)addr;
u8 __iomem *oob = addr + mtd->writesize;
int i;
 
-   for (i = 0; i < mtd->writesize / 4; i++) {
+   for (i = 0; i < chip->ecc.size / 4; i++) {
if (__raw_readl(&mainarea[i]) != 0x)
return 0;
}
@@ -215,12 +215,15 @@ static int is_blank(struct mtd_info *mtd, unsigned int 
bufnum)
 static int check_read_ecc(struct mtd_info *mtd, struct fsl_ifc_ctrl *ctrl,
  u32 *eccstat, unsigned int bufnum)
 {
+   struct nand_chip *chip = mtd->priv;
+   int bufperpage = mtd->writesize / chip->ecc.size;
+   int eccbuf_num = bufnum + (bufnum / bufperpage) * bufperpage;
u32 reg = eccstat[bufnum / 4];
int errors = (reg >> ((3 - bufnum % 4) * 8)) & 15;
 
if (errors == 15) { /* uncorrectable */
/* Blank pages fail hw ECC checks */
-   if (is_blank(mtd, bufnum))
+   if (is_blank(mtd, eccbuf_num))
return 1;
 
/*
@@ -273,7 +276,7 @@ static void fsl_ifc_run_command(struct mtd_info *mtd)
dev_err(priv->dev, "NAND Flash Write Protect Error\n");
 
if (nctrl->eccread) {
-   int bufperpage = mtd->writesize / 512;
+   int bufperpage = mtd->writesize / chip->ecc.size;
int bufnum = (nctrl->page & priv->bufnum_mask) * bufperpage;
int bufnum_end = bufnum + bufperpage - 1;
 
-- 
1.7.5.4


___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev


[PATCH] powerpc/85xx: Add p2020rdb-pc dts support

2012-01-09 Thread Yuantian.Tang
From: Tang Yuantian 

Signed-off-by: Prabhakar Kushwaha 
Signed-off-by: Poonam Aggrwal 
Signed-off-by: Tang Yuantian 
---
 arch/powerpc/boot/dts/p2020rdb-pc.dts|   96 +
 arch/powerpc/boot/dts/p2020rdb-pc.dtsi   |  241 ++
 arch/powerpc/boot/dts/p2020rdb-pc_36b.dts|   96 +
 arch/powerpc/boot/dts/p2020rdb-pc_camp_core0.dts |   90 
 arch/powerpc/boot/dts/p2020rdb-pc_camp_core1.dts |  152 ++
 5 files changed, 675 insertions(+), 0 deletions(-)
 create mode 100644 arch/powerpc/boot/dts/p2020rdb-pc.dts
 create mode 100644 arch/powerpc/boot/dts/p2020rdb-pc.dtsi
 create mode 100644 arch/powerpc/boot/dts/p2020rdb-pc_36b.dts
 create mode 100644 arch/powerpc/boot/dts/p2020rdb-pc_camp_core0.dts
 create mode 100644 arch/powerpc/boot/dts/p2020rdb-pc_camp_core1.dts

diff --git a/arch/powerpc/boot/dts/p2020rdb-pc.dts 
b/arch/powerpc/boot/dts/p2020rdb-pc.dts
new file mode 100644
index 000..852e5b2
--- /dev/null
+++ b/arch/powerpc/boot/dts/p2020rdb-pc.dts
@@ -0,0 +1,96 @@
+/*
+ * P2020 RDB-PC 32Bit Physical Address Map Device Tree Source
+ *
+ * Copyright 2011 Freescale Semiconductor Inc.
+ *
+ * Redistribution and use in source and binary forms, with or without
+ * modification, are permitted provided that the following conditions are met:
+ * * Redistributions of source code must retain the above copyright
+ *   notice, this list of conditions and the following disclaimer.
+ * * Redistributions in binary form must reproduce the above copyright
+ *   notice, this list of conditions and the following disclaimer in the
+ *   documentation and/or other materials provided with the distribution.
+ * * Neither the name of Freescale Semiconductor nor the
+ *   names of its contributors may be used to endorse or promote products
+ *   derived from this software without specific prior written permission.
+ *
+ *
+ * ALTERNATIVELY, this software may be distributed under the terms of the
+ * GNU General Public License ("GPL") as published by the Free Software
+ * Foundation, either version 2 of that License or (at your option) any
+ * later version.
+ *
+ * THIS SOFTWARE IS PROVIDED BY Freescale Semiconductor ``AS IS'' AND ANY
+ * EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED
+ * WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE
+ * DISCLAIMED. IN NO EVENT SHALL Freescale Semiconductor BE LIABLE FOR ANY
+ * DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES
+ * (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES;
+ * LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND
+ * ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
+ * (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF 
THIS
+ * SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
+ */
+
+/include/ "fsl/p2020si-pre.dtsi"
+
+/ {
+   model = "fsl,P2020RDB";
+   compatible = "fsl,P2020RDB-PC";
+
+   memory {
+   device_type = "memory";
+   };
+
+   lbc: localbus@ffe05000 {
+   reg = <0 0xffe05000 0 0x1000>;
+
+   /* NOR and NAND Flashes */
+   ranges = <0x0 0x0 0x0 0xef00 0x0100
+ 0x1 0x0 0x0 0xff80 0x0004
+ 0x2 0x0 0x0 0xffb0 0x0002
+ 0x3 0x0 0x0 0xffa0 0x0002>;
+   };
+
+   soc: soc@ffe0 {
+   ranges = <0x0 0x0 0xffe0 0x10>;
+   };
+
+   pci0: pcie@ffe08000 {
+   reg = <0 0xffe08000 0 0x1000>;
+   status = "disabled";
+   };
+
+   pci1: pcie@ffe09000 {
+   reg = <0 0xffe09000 0 0x1000>;
+   ranges = <0x200 0x0 0xe000 0 0xa000 0x0 0x2000
+ 0x100 0x0 0x 0 0xffc1 0x0 0x1>;
+   pcie@0 {
+   ranges = <0x200 0x0 0xe000
+ 0x200 0x0 0xe000
+ 0x0 0x2000
+
+ 0x100 0x0 0x0
+ 0x100 0x0 0x0
+ 0x0 0x10>;
+   };
+   };
+
+   pci2: pcie@ffe0a000 {
+   reg = <0 0xffe0a000 0 0x1000>;
+   ranges = <0x200 0x0 0xe000 0 0x8000 0x0 0x2000
+ 0x100 0x0 0x 0 0xffc0 0x0 0x1>;
+   pcie@0 {
+   ranges = <0x200 0x0 0xe000
+ 0x200 0x0 0xe000
+ 0x0 0x2000
+
+ 0x100 0x0 0x0
+ 0x100 0x0 0x0
+ 0x0 0x10>;
+   };
+   };
+};
+
+/include/ "p2020rdb-p

[PATCH] powerpc/85xx: Add P1024rdb dts support

2012-01-09 Thread b29983
From: Tang Yuantian 

Signed-off-by: Jin Qing 
Signed-off-by: Li Yang 
Signed-off-by: Tang Yuantian 
---
 arch/powerpc/boot/dts/fsl/p1024si-pre.dtsi|   68 
 arch/powerpc/boot/dts/p1024rdb.dts|   87 ++
 arch/powerpc/boot/dts/p1024rdb.dtsi   |  228 +
 arch/powerpc/boot/dts/p1024rdb_36b.dts|   87 ++
 arch/powerpc/boot/dts/p1024rdb_camp_core0.dts |  106 
 arch/powerpc/boot/dts/p1024rdb_camp_core1.dts |  161 +
 6 files changed, 737 insertions(+), 0 deletions(-)
 create mode 100644 arch/powerpc/boot/dts/fsl/p1024si-pre.dtsi
 create mode 100644 arch/powerpc/boot/dts/p1024rdb.dts
 create mode 100644 arch/powerpc/boot/dts/p1024rdb.dtsi
 create mode 100644 arch/powerpc/boot/dts/p1024rdb_36b.dts
 create mode 100644 arch/powerpc/boot/dts/p1024rdb_camp_core0.dts
 create mode 100644 arch/powerpc/boot/dts/p1024rdb_camp_core1.dts

diff --git a/arch/powerpc/boot/dts/fsl/p1024si-pre.dtsi 
b/arch/powerpc/boot/dts/fsl/p1024si-pre.dtsi
new file mode 100644
index 000..4a0406b
--- /dev/null
+++ b/arch/powerpc/boot/dts/fsl/p1024si-pre.dtsi
@@ -0,0 +1,68 @@
+/*
+ * P1024 Silicon/SoC Device Tree Source (pre include)
+ *
+ * Copyright 2011 Freescale Semiconductor Inc.
+ *
+ * Redistribution and use in source and binary forms, with or without
+ * modification, are permitted provided that the following conditions are met:
+ * * Redistributions of source code must retain the above copyright
+ *   notice, this list of conditions and the following disclaimer.
+ * * Redistributions in binary form must reproduce the above copyright
+ *   notice, this list of conditions and the following disclaimer in the
+ *   documentation and/or other materials provided with the distribution.
+ * * Neither the name of Freescale Semiconductor nor the
+ *   names of its contributors may be used to endorse or promote products
+ *   derived from this software without specific prior written permission.
+ *
+ *
+ * ALTERNATIVELY, this software may be distributed under the terms of the
+ * GNU General Public License ("GPL") as published by the Free Software
+ * Foundation, either version 2 of that License or (at your option) any
+ * later version.
+ *
+ * THIS SOFTWARE IS PROVIDED BY Freescale Semiconductor ``AS IS'' AND ANY
+ * EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED
+ * WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE
+ * DISCLAIMED. IN NO EVENT SHALL Freescale Semiconductor BE LIABLE FOR ANY
+ * DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES
+ * (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES;
+ * LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND
+ * ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
+ * (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF 
THIS
+ * SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
+ */
+
+/dts-v1/;
+/ {
+   compatible = "fsl,P1024";
+   #address-cells = <2>;
+   #size-cells = <2>;
+   interrupt-parent = <&mpic>;
+
+   aliases {
+   serial0 = &serial0;
+   serial1 = &serial1;
+   ethernet0 = &enet0;
+   ethernet1 = &enet1;
+   ethernet2 = &enet2;
+   pci0 = &pci0;
+   pci1 = &pci1;
+   };
+
+   cpus {
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   PowerPC,P1024@0 {
+   device_type = "cpu";
+   reg = <0x0>;
+   next-level-cache = <&L2>;
+   };
+
+   PowerPC,P1024@1 {
+   device_type = "cpu";
+   reg = <0x1>;
+   next-level-cache = <&L2>;
+   };
+   };
+};
diff --git a/arch/powerpc/boot/dts/p1024rdb.dts 
b/arch/powerpc/boot/dts/p1024rdb.dts
new file mode 100644
index 000..1a89f9c
--- /dev/null
+++ b/arch/powerpc/boot/dts/p1024rdb.dts
@@ -0,0 +1,87 @@
+/*
+ * P1024 RDB 32Bit Physical Address Map Device Tree Source
+ *
+ * Copyright 2011 Freescale Semiconductor Inc.
+ *
+ * Redistribution and use in source and binary forms, with or without
+ * modification, are permitted provided that the following conditions are met:
+ * * Redistributions of source code must retain the above copyright
+ *   notice, this list of conditions and the following disclaimer.
+ * * Redistributions in binary form must reproduce the above copyright
+ *   notice, this list of conditions and the following disclaimer in the
+ *   documentation and/or other materials provided with the distribution.
+ * * Neither the name of Freescale Semiconductor nor the
+ *   names of its contributors may be used to endorse or promote products
+ *   derived from this software without specific prio