07 Oct, 2011

17 commits

  • Original port to early 2.6 kernel using TI COFF toolchain.
    Brought up to date by Mark Salter

    Signed-off-by: Aurelien Jacquiot
    Signed-off-by: Mark Salter
    Acked-by: Arnd Bergmann

    Aurelien Jacquiot
     
  • Original port to early 2.6 kernel using TI COFF toolchain.
    Brought up to date by Mark Salter

    Signed-off-by: Aurelien Jacquiot
    Signed-off-by: Mark Salter
    Acked-by: Arnd Bergmann

    Aurelien Jacquiot
     
  • Original port to early 2.6 kernel using TI COFF toolchain.
    Brought up to date by Mark Salter

    Signed-off-by: Aurelien Jacquiot
    Signed-off-by: Mark Salter
    Acked-by: Arnd Bergmann

    Aurelien Jacquiot
     
  • Original port to early 2.6 kernel using TI COFF toolchain.
    Brought up to date by Mark Salter

    Signed-off-by: Aurelien Jacquiot
    Signed-off-by: Mark Salter
    Acked-by: Arnd Bergmann

    Aurelien Jacquiot
     
  • Original port to early 2.6 kernel using TI COFF toolchain.
    Brought up to date by Mark Salter

    Signed-off-by: Aurelien Jacquiot
    Signed-off-by: Mark Salter
    Acked-by: Arnd Bergmann

    Aurelien Jacquiot
     
  • The C6X SoCs contain several PLL controllers each with up to 16 clock outputs
    feeding into the cores or peripheral clock domains. The hardware is very similar
    to arm/mach-davinci clocks. This is still a work in progress which needs to be
    updated once device tree clock binding changes shake out.

    Signed-off-by: Mark Salter
    Signed-off-by: Aurelien Jacquiot
    Acked-by: Arnd Bergmann

    Mark Salter
     
  • Original port to early 2.6 kernel using TI COFF toolchain.
    Brought up to date by Mark Salter

    Signed-off-by: Aurelien Jacquiot
    Signed-off-by: Mark Salter
    Acked-by: Arnd Bergmann

    Aurelien Jacquiot
     
  • Original port to early 2.6 kernel using TI COFF toolchain.
    Brought up to date by Mark Salter

    Signed-off-by: Aurelien Jacquiot
    Signed-off-by: Mark Salter
    Acked-by: Arnd Bergmann
    [msalter@redhat.com: add include of linux/module.h to sys_c6x.c]
    Signed-off-by: Mark Salter

    Aurelien Jacquiot
     
  • Original port to early 2.6 kernel using TI COFF toolchain.
    Brought up to date by Mark Salter

    Signed-off-by: Aurelien Jacquiot
    Signed-off-by: Mark Salter
    Reviewed-by: Thomas Gleixner
    Acked-by: Arnd Bergmann

    Aurelien Jacquiot
     
  • Original port to early 2.6 kernel using TI COFF toolchain.
    Brought up to date by Mark Salter

    Signed-off-by: Aurelien Jacquiot
    Signed-off-by: Mark Salter
    Reviewed-by: Thomas Gleixner
    Acked-by: Arnd Bergmann

    Aurelien Jacquiot
     
  • Original port to early 2.6 kernel using TI COFF toolchain.
    Brought up to date by Mark Salter

    Signed-off-by: Aurelien Jacquiot
    Signed-off-by: Mark Salter
    Acked-by: Arnd Bergmann

    Aurelien Jacquiot
     
  • Original port to early 2.6 kernel using TI COFF toolchain.
    Brought up to date by Mark Salter

    Signed-off-by: Aurelien Jacquiot
    Signed-off-by: Mark Salter
    Acked-by: Arnd Bergmann

    Aurelien Jacquiot
     
  • Original port to early 2.6 kernel using TI COFF toolchain.
    Brought up to date by Mark Salter

    The C6X architecture currently lacks an MMU so memory management is relatively
    simple. There is no bus snooping between L2 and main memory but coherent DMA
    memory is supported by making regions of main memory uncached. If such a region
    is desired, it can be specified on the commandline with a "memdma=" argument.

    Signed-off-by: Aurelien Jacquiot
    Signed-off-by: Mark Salter
    Acked-by: Arnd Bergmann

    Aurelien Jacquiot
     
  • This is the basic devicetree support for C6X. Currently, four boards are
    supported. Each one uses a different SoC part. Two of the four supported
    SoCs are multicore. One with 3 cores and the other with 6 cores. There is
    no coherency between the core-level caches, so SMP is not an option. It is
    possible to run separate kernel instances on the various cores. There is
    currently no C6X bootloader support for device trees so we build in the DTB
    for now.

    There are some interesting twists to the hardware which are of note for device
    tree support. Each core has its own interrupt controller which is controlled
    by special purpose core registers. This core controller provides 12 general
    purpose prioritized interrupt sources. Each core is contained within a
    hardware "module" which provides L1 and L2 caches, power control, and another
    interrupt controller which cascades into the core interrupt controller. These
    core module functions are controlled by memory mapped registers. The addresses
    for these registers are the same for each core. That is, when coreN accesses
    a module-level MMIO register at a given address, it accesses the register for
    coreN even though other cores would use the same address to access the register
    in the module containing those cores. Other hardware modules (timers, enet, etc)
    which are memory mapped can be accessed by all cores.

    The timers need some further explanation for multicore SoCs. Even though all
    timer control registers are visible to all cores, interrupt routing or other
    considerations may make a given timer more suitable for use by a core than
    some other timer. Because of this and the desire to have the same image run
    on more than one core, the timer nodes have a "ti,core-mask" property which
    is used by the driver to scan for a suitable timer to use.

    Signed-off-by: Mark Salter
    Signed-off-by: Aurelien Jacquiot
    Acked-by: Arnd Bergmann

    Mark Salter
     
  • Original port to early 2.6 kernel using TI COFF toolchain.
    Brought up to date by Mark Salter

    This patch provides the early boot code for C6X architecture. There is a
    16 entry vector table which is used to direct reset and interrupt events. The
    vector table entries contain a small amount of code (maximum of 8 opcodes)
    which simply branches to the actual event handling code.

    The head.S code simply clears BSS, setups up a few control registers, and calls
    machine_init followed by start_kernel. The machine_init code in setup.c does
    the early flat tree parsing (memory, commandline, etc). At setup_arch time, the
    code does the usual memory setup and minimally scans the devicetree for any
    needed information.

    Signed-off-by: Aurelien Jacquiot
    Signed-off-by: Mark Salter
    Acked-by: Arnd Bergmann

    Aurelien Jacquiot
     
  • Original port to early 2.6 kernel using TI COFF toolchain.
    Brought up to date by Mark Salter

    Signed-off-by: Aurelien Jacquiot
    Signed-off-by: Mark Salter
    Acked-by: Arnd Bergmann

    Aurelien Jacquiot
     
  • In summary, this DMI quirk uses the _CRS info by default for the ASUS
    M2V-MX SE by turning on `pci=use_crs` and is similar to the quirk
    added by commit 2491762cfb47 ("x86/PCI: use host bridge _CRS info on
    ASRock ALiveSATA2-GLAN") whose commit message should be read for further
    information.

    Since commit 3e3da00c01d0 ("x86/pci: AMD one chain system to use pci
    read out res") Linux gives the following oops:

    parport0: PC-style at 0x378, irq 7 [PCSPP,TRISTATE]
    HDA Intel 0000:20:01.0: PCI INT A -> GSI 17 (level, low) -> IRQ 17
    HDA Intel 0000:20:01.0: setting latency timer to 64
    BUG: unable to handle kernel paging request at ffffc90011c08000
    IP: [] azx_probe+0x3ad/0x86b [snd_hda_intel]
    PGD 13781a067 PUD 13781b067 PMD 1300ba067 PTE 800000fd00000173
    Oops: 0009 [#1] SMP
    last sysfs file: /sys/module/snd_pcm/initstate
    CPU 0
    Modules linked in: snd_hda_intel(+) snd_hda_codec snd_hwdep snd_pcm_oss snd_mixer_oss snd_pcm snd_seq_midi snd_rawmidi snd_seq_midi_event tpm_tis tpm snd_seq tpm_bios psmouse parport_pc snd_timer snd_seq_device parport processor evdev snd i2c_viapro thermal_sys amd64_edac_mod k8temp i2c_core soundcore shpchp pcspkr serio_raw asus_atk0110 pci_hotplug edac_core button snd_page_alloc edac_mce_amd ext3 jbd mbcache sha256_generic cryptd aes_x86_64 aes_generic cbc dm_crypt dm_mod raid1 md_mod usbhid hid sg sd_mod crc_t10dif sr_mod cdrom ata_generic uhci_hcd sata_via pata_via libata ehci_hcd usbcore scsi_mod via_rhine mii nls_base [last unloaded: scsi_wait_scan]
    Pid: 1153, comm: work_for_cpu Not tainted 2.6.37-1-amd64 #1 M2V-MX SE/System Product Name
    RIP: 0010:[] [] azx_probe+0x3ad/0x86b [snd_hda_intel]
    RSP: 0018:ffff88013153fe50 EFLAGS: 00010286
    RAX: ffffc90011c08000 RBX: ffff88013029ec00 RCX: 0000000000000006
    RDX: 0000000000000000 RSI: 0000000000000246 RDI: 0000000000000246
    RBP: ffff88013341d000 R08: 0000000000000000 R09: 0000000000000040
    R10: 0000000000000286 R11: 0000000000003731 R12: ffff88013029c400
    R13: 0000000000000000 R14: 0000000000000000 R15: ffff88013341d090
    FS: 0000000000000000(0000) GS:ffff8800bfc00000(0000) knlGS:00000000f7610ab0
    CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b
    CR2: ffffc90011c08000 CR3: 0000000132f57000 CR4: 00000000000006f0
    DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
    DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
    Process work_for_cpu (pid: 1153, threadinfo ffff88013153e000, task ffff8801303c86c0)
    Stack:
    0000000000000005 ffffffff8123ad65 00000000000136c0 ffff88013029c400
    ffff8801303c8998 ffff88013341d000 ffff88013341d090 ffff8801322d9dc8
    ffff88013341d208 0000000000000000 0000000000000000 ffffffff811ad232
    Call Trace:
    [] ? __pm_runtime_set_status+0x162/0x186
    [] ? local_pci_probe+0x49/0x92
    [] ? do_work_for_cpu+0x0/0x1b
    [] ? do_work_for_cpu+0x0/0x1b
    [] ? do_work_for_cpu+0xb/0x1b
    [] ? kthread+0x7a/0x82
    [] ? kernel_thread_helper+0x4/0x10
    [] ? kthread+0x0/0x82
    [] ? kernel_thread_helper+0x0/0x10
    Code: f4 01 00 00 ef 31 f6 48 89 df e8 29 dd ff ff 85 c0 0f 88 2b 03 00 00 48 89 ef e8 b4 39 c3 e0 8b 7b 40 e8 fc 9d b1 e0 48 8b 43 38 8b 10 66 89 14 24 8b 43 14 83 e8 03 83 f8 01 77 32 31 d2 be
    RIP [] azx_probe+0x3ad/0x86b [snd_hda_intel]
    RSP
    CR2: ffffc90011c08000
    ---[ end trace 8d1f3ebc136437fd ]---

    Trusting the ACPI _CRS information (`pci=use_crs`) fixes this problem.

    $ dmesg | grep -i crs # with the quirk
    PCI: Using host bridge windows from ACPI; if necessary, use "pci=nocrs" and report a bug

    The match has to be against the DMI board entries though since the vendor entries are not populated.

    DMI: System manufacturer System Product Name/M2V-MX SE, BIOS 0304 10/30/2007

    This quirk should be removed when `pci=use_crs` is enabled for machines
    from 2006 or earlier or some other solution is implemented.

    Using coreboot [1] with this board the problem does not exist but this
    quirk also does not affect it either. To be safe though the check is
    tightened to only take effect when the BIOS from American Megatrends is
    used.

    15:13 < ruik> but coreboot does not need that
    15:13 < ruik> because i have there only one root bus
    15:13 < ruik> the audio is behind a bridge

    $ sudo dmidecode
    BIOS Information
    Vendor: American Megatrends Inc.
    Version: 0304
    Release Date: 10/30/2007

    [1] http://www.coreboot.org/

    Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=30552

    Cc: stable@kernel.org (2.6.34)
    Cc: Thomas Gleixner
    Cc: Ingo Molnar
    Cc: H. Peter Anvin
    Cc: x86@kernel.org
    Signed-off-by: Paul Menzel
    Signed-off-by: Bjorn Helgaas
    Acked-by: Jesse Barnes
    Signed-off-by: Linus Torvalds

    Paul Menzel
     

01 Oct, 2011

1 commit

  • …for-linus' of git://tesla.tglx.de/git/linux-2.6-tip

    * 'irq-urgent-for-linus' of git://tesla.tglx.de/git/linux-2.6-tip:
    irq: Fix check for already initialized irq_domain in irq_domain_add
    irq: Add declaration of irq_domain_simple_ops to irqdomain.h

    * 'x86-urgent-for-linus' of git://tesla.tglx.de/git/linux-2.6-tip:
    x86/rtc: Don't recursively acquire rtc_lock

    * 'sched-urgent-for-linus' of git://tesla.tglx.de/git/linux-2.6-tip:
    posix-cpu-timers: Cure SMP wobbles
    sched: Fix up wchan borkage
    sched/rt: Migrate equal priority tasks to available CPUs

    Linus Torvalds
     

30 Sep, 2011

4 commits

  • * 'for-linus' of git://git390.marist.edu/pub/scm/linux-2.6:
    [S390] cio: fix cio_tpi ignoring adapter interrupts
    [S390] gmap: always up mmap_sem properly
    [S390] Do not clobber personality flags on exec

    Linus Torvalds
     
  • * git://github.com/davem330/sparc:
    sparc64: Force the execute bit in OpenFirmware's translation entries.
    sparc: Make '-p' boot option meaningful again.
    sparc, exec: remove redundant addr_limit assignment
    sparc64: Future proof Niagara cpu detection.

    Linus Torvalds
     
  • Apple Quad G5 has some oddity in it's device-tree which causes the new
    generic matching code to fail to relate nodes for PCI-E devices below U4
    with their respective struct pci_dev. This breaks graphics on those
    machines among others.

    This fixes it using a quirk which copies the node pointer from the host
    bridge for the root complex, which makes the generic code work for the
    children afterward.

    Signed-off-by: Benjamin Herrenschmidt
    Signed-off-by: Linus Torvalds

    Benjamin Herrenschmidt
     
  • In the OF 'translations' property, the template TTEs in the mappings
    never specify the executable bit. This is the case even though some
    of these mappings are for OF's code segment.

    Therefore, we need to force the execute bit on in every mapping.

    This problem can only really trigger on Niagara/sun4v machines and the
    history behind this is a little complicated.

    Previous to sun4v, the sun4u TTE entries lacked a hardware execute
    permission bit. So OF didn't have to ever worry about setting
    anything to handle executable pages. Any valid TTE loaded into the
    I-TLB would be respected by the chip.

    But sun4v Niagara chips have a real hardware enforced executable bit
    in their TTEs. So it has to be set or else the I-TLB throws an
    instruction access exception with type code 6 (protection violation).

    We've been extremely fortunate to not get bitten by this in the past.

    The best I can tell is that the OF's mappings for it's executable code
    were mapped using permanent locked mappings on sun4v in the past.
    Therefore, the fact that we didn't have the exec bit set in the OF
    translations we would use did not matter in practice.

    Thanks to Greg Onufer for helping me track this down.

    Signed-off-by: David S. Miller

    David S. Miller
     

27 Sep, 2011

5 commits


26 Sep, 2011

8 commits


23 Sep, 2011

1 commit


22 Sep, 2011

1 commit

  • If "-p" is given on the command line, clear the CON_BOOT
    flag for the initial early boot PROM console.

    This is necessary to try and see crash messages that occur
    between the registry of the VT console and the probing of
    the first framebuffer or serial console. During this time
    no console messages are emitted because the VT console
    registry (even if no backend is registered to it) removes
    the early console if CON_BOOT is set.

    Signed-off-by: David S. Miller

    David S. Miller
     

21 Sep, 2011

3 commits

  • A deadlock was introduced on x86 in commit ef68c8f87ed1 ("x86:
    Serialize EFI time accesses on rtc_lock") because efi_get_time()
    and friends can be called with rtc_lock already held by
    read_persistent_time(), e.g.:

    timekeeping_init()
    read_persistent_clock()

    To fix this let's push the locking down into the get_wallclock()
    and set_wallclock() implementations. Only the clock
    implementations that access the x86 RTC directly need to acquire
    rtc_lock, so it makes sense to push the locking down into the
    rtc, vrtc and efi code.

    The virtualization implementations don't require rtc_lock to be
    held because they provide their own serialization.

    Signed-off-by: Matt Fleming
    Acked-by: Jan Beulich
    Acked-by: Avi Kivity [for the virtualization aspect]
    Cc: "H. Peter Anvin"
    Cc: Zhang Rui
    Cc: Josh Boyer
    Signed-off-by: Andrew Morton
    Signed-off-by: Thomas Gleixner
    Signed-off-by: Ingo Molnar

    Matt Fleming
     
  • The address limit is already set in flush_old_exec() so this assignment of
    USER_DS is redundant.

    Signed-off-by: Mathias Krause
    Cc: David Miller
    Signed-off-by: Andrew Morton
    Signed-off-by: David S. Miller

    Mathias Krause
     
  • We are seeing linker errors caused by sections being discarded, despite
    the linker script trying to keep them. The result is (eg):

    `.exit.text' referenced in section `.alt.smp.init' of drivers/built-in.o: defined in discarded section `.exit.text' of drivers/built-in.o
    `.exit.text' referenced in section `.alt.smp.init' of net/built-in.o: defined in discarded section `.exit.text' of net/built-in.o

    This is the relevent part of the linker script (reformatted to make it
    clearer):
    | SECTIONS
    | {
    | /*
    | * unwind exit sections must be discarded before the rest of the
    | * unwind sections get included.
    | */
    | /DISCARD/ : {
    | *(.ARM.exidx.exit.text)
    | *(.ARM.extab.exit.text)
    | }
    | ...
    | .exit.text : {
    | *(.exit.text)
    | *(.memexit.text)
    | }
    | ...
    | /DISCARD/ : {
    | *(.exit.text)
    | *(.memexit.text)
    | *(.exit.data)
    | *(.memexit.data)
    | *(.memexit.rodata)
    | *(.exitcall.exit)
    | *(.discard)
    | *(.discard.*)
    | }
    | }

    Now, this is what the linker manual says about discarded output sections:

    | The special output section name `/DISCARD/' may be used to discard
    | input sections. Any input sections which are assigned to an output
    | section named `/DISCARD/' are not included in the output file.

    No questions, no exceptions. It doesn't say "unless they are listed
    before the /DISCARD/ section." Now, this is what asn-generic/vmlinux.lds.S
    says:
    | /*
    | * Default discarded sections.
    | *
    | * Some archs want to discard exit text/data at runtime rather than
    | * link time due to cross-section references such as alt instructions,
    | * bug table, eh_frame, etc. DISCARDS must be the last of output
    | * section definitions so that such archs put those in earlier section
    | * definitions.
    | */

    And guess what - the list _always_ includes .exit.text etc.

    Now, what's actually happening is that the linker is reading the script,
    and it finds the first /DISCARD/ output section at the beginning of the
    script. It continues reading the script, and finds the 'DISCARD' macro
    at the end, which having been postprocessed results in another
    /DISCARD/ output section. As the linker already contains the earlier
    /DISCARD/ output section, it adds it to that existing section, so it
    effectively is placed at the start. This can be seen by using the -M
    option to ld:

    | Linker script and memory map
    |
    | 0xc037c080 jiffies = jiffies_64
    |
    | /DISCARD/
    | *(.ARM.exidx.exit.text)
    | *(.ARM.extab.exit.text)
    | *(.exit.text)
    | *(.memexit.text)
    | *(.exit.data)
    | *(.memexit.data)
    | *(.memexit.rodata)
    | *(.exitcall.exit)
    | *(.discard)
    | *(.discard.*)
    |
    | 0xc0008000 . = 0xc0008000
    |
    | .head.text 0xc0008000 0x1d0
    | 0xc0008000 _text = .
    | *(.head.text)
    | .head.text 0xc0008000 0x1d0 arch/arm/kernel/head.o
    | 0xc0008000 stext
    |
    | .text 0xc0008200 0x2d78d0
    | 0xc0008200 _stext = .
    | 0xc0008200 __exception_text_start = .
    | *(.exception.text)
    | .exception.text
    | ...

    As you can see, all the discarded sections are grouped together - and
    as a result of it being the first output section, they all appear before
    any other section.

    The result is that not only is the unwind information discarded (as
    intended), but also the .exit.text, despite us wanting to have the
    .exit.text preserved.

    We can't move the unwind information elsewhere, because it'll then be
    included even when we do actually discard the .exit.text (and similar)
    sections.

    So, work around this by avoiding the generic DISCARDS macro, and instead
    conditionalize the sections to be discarded ourselves. This avoids the
    ambiguity in how the linker assigns input sections to output sections,
    making our script less dependent on undocumented linker behaviour.

    Reported-by: Rob Herring
    Tested-by: Mark Brown
    Signed-off-by: Russell King

    Russell King