1. 13 Feb, 2010 2 commits
    • Peter Tyser's avatar
      powerpc/85xx: Fix SMP when "cpu-release-addr" is in lowmem · d1d47ec6
      Peter Tyser authored
      Recent U-Boot commit 5ccd29c3679b3669b0bde5c501c1aa0f325a7acb caused
      the "cpu-release-addr" device tree property to contain the physical RAM
      location that secondary cores were spinning at.  Previously, the
      "cpu-release-addr" property contained a value referencing the boot page
      translation address range of 0xfffffxxx, which then indirectly accessed
      RAM.
      
      The "cpu-release-addr" is currently ioremapped and the secondary cores
      kicked.  However, due to the recent change in "cpu-release-addr", it
      sometimes points to a memory location in low memory that cannot be
      ioremapped.  For example on a P2020-based board with 512MB of RAM the
      following error occurs on bootup:
      
        <...>
        mpic: requesting IPIs ...
        __ioremap(): phys addr 0x1ffff000 is RAM lr c05df9a0
        Unable to handle kernel paging request for data at address 0x00000014
        Faulting instruction address: 0xc05df9b0
        Oops: Kernel access of bad area, sig: 11 [#1]
        SMP NR_CPUS=2 P2020 RDB
        Modules linked in:
        <... eventual kernel panic>
      
      Adding logic to conditionally ioremap or access memory directly resolves
      the issue.
      Signed-off-by: default avatarPeter Tyser <ptyser@xes-inc.com>
      Signed-off-by: default avatarNate Case <ncase@xes-inc.com>
      Reported-by: default avatarDipen Dudhat <B09055@freescale.com>
      Tested-by: default avatarDipen Dudhat <B09055@freescale.com>
      Signed-off-by: default avatarKumar Gala <galak@kernel.crashing.org>
      d1d47ec6
    • Anton Vorontsov's avatar
      powerpc/85xx: Fix oops during MSI driver probe on MPC85xxMDS boards · fa644298
      Anton Vorontsov authored
      MPC85xx chips report the wrong value in feature reporting register,
      and that causes the following oops:
      
       Unable to handle kernel paging request for data at address 0x00000c00
       Faulting instruction address: 0xc0019294
       Oops: Kernel access of bad area, sig: 11 [#1]
       MPC8569 MDS
       Modules linked in:
       [...]
       NIP [c0019294] mpic_set_irq_type+0x2f0/0x368
       LR [c0019124] mpic_set_irq_type+0x180/0x368
       Call Trace:
       [ef851d60] [c0019124] mpic_set_irq_type+0x180/0x368 (unreliable)
       [ef851d90] [c007958c] __irq_set_trigger+0x44/0xd4
       [ef851db0] [c007b550] set_irq_type+0x40/0x7c
       [ef851dc0] [c0004a60] irq_create_of_mapping+0xb4/0x114
       [ef851df0] [c0004af0] irq_of_parse_and_map+0x30/0x40
       [ef851e20] [c0405678] fsl_of_msi_probe+0x1a0/0x328
       [ef851e60] [c02e6438] of_platform_device_probe+0x5c/0x84
       [...]
      
      This is because mpic_alloc() assigns wrong values to
      mpic->isu_{size,shift,mask}, and things eventually break when
      _mpic_irq_read() is trying to use them.
      
      This patch fixes the issue by enabling MPIC_BROKEN_FRR_NIRQS quirk.
      Signed-off-by: default avatarAnton Vorontsov <avorontsov@ru.mvista.com>
      Signed-off-by: default avatarKumar Gala <galak@kernel.crashing.org>
      fa644298
  2. 12 Feb, 2010 12 commits
  3. 11 Feb, 2010 26 commits