- 08 Jan, 2012 2 commits
-
-
Mark Salter authored
Some SoCs have a timer block enable controlled through the DSCR registers. There is a problem in the timer64 driver initialization where the code accesses a timer register to get the divisor used to calculate timer clock rate. If the timer block has not been enabled when this register read takes place, an exception is generated. This patch makes sure that the timer block is enabled before accessing the registers. Signed-off-by:Mark Salter <msalter@redhat.com>
-
Mark Salter authored
Signed-off-by:
-
- 06 Oct, 2011 30 commits
-
-
Mark Salter authored
Signed-off-by:
Aurelien Jacquiot <a-jacquiot@ti.com> Acked-by:
Arnd Bergmann <arnd@arndb.de>
-
Mark Salter authored
All SoCs provide an area of device configuration registers called the DSCR. The location of specific registers as well as their use varies considerably from implementation to implementation. Rather than having to rely on additional SoC-specific DSCR code for each new supported SoC, this code generalize things as much as possible using device tree properties. Initialization must take place early on (setup_arch time) in case the event timer device needs to be enable via the DSCR. Signed-off-by:
-
Mark Salter authored
Several SoC parts provide a simple bridge to support external memory mapped devices. This code probes the device tree for an EMIF node and sets up the bridge registers if such a node is found. Beyond initial set up, there is no further need to access the bridge control registers. External devices on the bus are accessed through their MMIO registers using suitable drivers. The bridge hardware does provide for timeout and other error interrupts, but these are not yet supported. Signed-off-by:
-
Mark Salter authored
This patch provides a soc_ops struct which provides hooks for SoC functionality which doesn't fit well into other places. Signed-off-by:
-
Aurelien Jacquiot authored
Original port to early 2.6 kernel using TI COFF toolchain. Brought up to date by Mark Salter <msalter@redhat.com> Signed-off-by:
-
Aurelien Jacquiot authored
Original port to early 2.6 kernel using TI COFF toolchain. Brought up to date by Mark Salter <msalter@redhat.com> Signed-off-by:
-
Aurelien Jacquiot authored
Original port to early 2.6 kernel using TI COFF toolchain. Brought up to date by Mark Salter <msalter@redhat.com> Signed-off-by:
-
Aurelien Jacquiot authored
Original port to early 2.6 kernel using TI COFF toolchain. Brought up to date by Mark Salter <msalter@redhat.com> Signed-off-by:
-
Aurelien Jacquiot authored
Original port to early 2.6 kernel using TI COFF toolchain. Brought up to date by Mark Salter <msalter@redhat.com> Signed-off-by:
-
Mark Salter authored
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:
-
Aurelien Jacquiot authored
Original port to early 2.6 kernel using TI COFF toolchain. Brought up to date by Mark Salter <msalter@redhat.com> Signed-off-by:
-
Aurelien Jacquiot authored
Original port to early 2.6 kernel using TI COFF toolchain. Brought up to date by Mark Salter <msalter@redhat.com> Signed-off-by:
-
Aurelien Jacquiot authored
Original port to early 2.6 kernel using TI COFF toolchain. Brought up to date by Mark Salter <msalter@redhat.com> Signed-off-by:
Thomas Gleixner <tglx@linutronix.de> Acked-by:
-
Aurelien Jacquiot authored
Original port to early 2.6 kernel using TI COFF toolchain. Brought up to date by Mark Salter <msalter@redhat.com> Signed-off-by:
-
Aurelien Jacquiot authored
Original port to early 2.6 kernel using TI COFF toolchain. Brought up to date by Mark Salter <msalter@redhat.com> Signed-off-by:
-
Aurelien Jacquiot authored
Original port to early 2.6 kernel using TI COFF toolchain. Brought up to date by Mark Salter <msalter@redhat.com> Signed-off-by:
-
Aurelien Jacquiot authored
Original port to early 2.6 kernel using TI COFF toolchain. Brought up to date by Mark Salter <msalter@redhat.com> 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:
-
Mark Salter authored
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:
-
Aurelien Jacquiot authored
Original port to early 2.6 kernel using TI COFF toolchain. Brought up to date by Mark Salter <msalter@redhat.com> 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 authored
Original port to early 2.6 kernel using TI COFF toolchain. Brought up to date by Mark Salter <msalter@redhat.com> Signed-off-by:
-
Mark Salter authored
Signed-off-by:
-
Mark Salter authored
Signed-off-by:
-
Mark Salter authored
asm-generic/page.h had several problems when used with a non-zero PAGE_OFFSET. This patch adds a default ARCH_PFN_OFFSET and fixes the __va, __pa, and pfn_valid macros to work with non-zero PAGE_OFFSETs. Signed-off-by:
-
Mark Salter authored
The existing __strnlen_user macro simply resolved to strnlen. However, the count returned by strnlen_user should include the NULL byte. This patch fixes the __strnlen_user macro to include the NULL byte in the count. Signed-off-by:
-
git://github.com/davem330/netLinus Torvalds authored
* git://github.com/davem330/net: net: fix typos in Documentation/networking/scaling.txt bridge: leave carrier on for empty bridge netfilter: Use proper rwlock init function tcp: properly update lost_cnt_hint during shifting tcp: properly handle md5sig_pool references macvlan/macvtap: Fix unicast between macvtap interfaces in bridge mode
-
Paul Menzel authored
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 2491762c ("x86/PCI: use host bridge _CRS info on ASRock ALiveSATA2-GLAN") whose commit message should be read for further information. Since commit 3e3da00c ("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: [<ffffffffa0578402>] 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:[<ffffffffa0578402>] [<ffffffffa0578402>] 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: [<ffffffff8123ad65>] ? __pm_runtime_set_status+0x162/0x186 [<ffffffff811ad232>] ? local_pci_probe+0x49/0x92 [<ffffffff8105afc5>] ? do_work_for_cpu+0x0/0x1b [<ffffffff8105afc5>] ? do_work_for_cpu+0x0/0x1b [<ffffffff8105afd0>] ? do_work_for_cpu+0xb/0x1b [<ffffffff8105fd3f>] ? kthread+0x7a/0x82 [<ffffffff8100a824>] ? kernel_thread_helper+0x4/0x10 [<ffffffff8105fcc5>] ? kthread+0x0/0x82 [<ffffffff8100a820>] ? 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 <66> 8b 10 66 89 14 24 8b 43 14 83 e8 03 83 f8 01 77 32 31 d2 be RIP [<ffffffffa0578402>] azx_probe+0x3ad/0x86b [snd_hda_intel] RSP <ffff88013153fe50> 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 <tglx@linutronix.de> Cc: Ingo Molnar <mingo@redhat.com> Cc: H. Peter Anvin <hpa@zytor.com> Cc: x86@kernel.org Signed-off-by:
Paul Menzel <paulepanter@users.sourceforge.net> Signed-off-by:
Bjorn Helgaas <bhelgaas@google.com> Acked-by:
Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org>
-
Benjamin Poirier authored
The second hunk fixes rps_sock_flow_table but has to re-wrap the paragraph. Signed-off-by:
Benjamin Poirier <benjamin.poirier@gmail.com> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
stephen hemminger authored
This resolves a regression seen by some users of bridging. Some users use the bridge like a dummy device. They expect to be able to put an IPv6 address on the device with no ports attached. Although there are better ways of doing this, there is no reason to not allow it. Note: the bridge still will reflect the state of ports in the bridge if there are any added. Signed-off-by:
Stephen Hemminger <shemminger@vyatta.com> Signed-off-by:
-
http://people.redhat.com/agk/git/linux-dmLinus Torvalds authored
* 'for-linus' of http://people.redhat.com/agk/git/linux-dm: dm crypt: always disable discard_zeroes_data dm: raid fix write_mostly arg validation dm table: avoid crash if integrity profile changes dm: flakey fix corrupt_bio_byte error path
-
git://neil.brown.name/mdLinus Torvalds authored
* 'for-linus' of git://neil.brown.name/md: md: Avoid waking up a thread after it has been freed.
-
- 05 Oct, 2011 8 commits
-
-
Thomas Gleixner authored
Replace the open coded initialization with the init function. Signed-off-by:
Hans Schillstrom <hans.schillstrom@ericsson.com> Signed-off-by:
-
git://github.com/dtor/inputLinus Torvalds authored
* 'for-linus' of git://github.com/dtor/input: Input: wacom - revert "Cintiq 21UX2 does not have menu strips"
-
git://bedivere.hansenpartnership.com/git/scsi-rc-fixes-2.6Linus Torvalds authored
* git://bedivere.hansenpartnership.com/git/scsi-rc-fixes-2.6: [SCSI] libsas: fix panic when single phy is disabled on a wide port [SCSI] qla2xxx: Fix crash in qla2x00_abort_all_cmds() on unload
-
Jason Gerecke authored
This reverts commit 71c86ce5. The 21UX2 does have touchstrips, but they are in a somewhat- hidden location. Signed-off-by:
Jason Gerecke <killertofu@gmail.com> Acked-by:
Ping Cheng <pinglinux@gmail.com> Signed-off-by:
Dmitry Torokhov <dtor@mail.ru>
-
Yan, Zheng authored
lost_skb_hint is used by tcp_mark_head_lost() to mark the first unhandled skb. lost_cnt_hint is the number of packets or sacked packets before the lost_skb_hint; When shifting a skb that is before the lost_skb_hint, if tcp_is_fack() is ture, the skb has already been counted in the lost_cnt_hint; if tcp_is_fack() is false, tcp_sacktag_one() will increase the lost_cnt_hint. So tcp_shifted_skb() does not need to adjust the lost_cnt_hint by itself. When shifting a skb that is equal to lost_skb_hint, the shifted packets will not be counted by tcp_mark_head_lost(). So tcp_shifted_skb() should adjust the lost_cnt_hint even tcp_is_fack(tp) is true. Signed-off-by:
Zheng Yan <zheng.z.yan@intel.com> Signed-off-by:
-
Yan, Zheng authored
tcp_v4_clear_md5_list() assumes that multiple tcp md5sig peers only hold one reference to md5sig_pool. but tcp_v4_md5_do_add() increases use count of md5sig_pool for each peer. This patch makes tcp_v4_md5_do_add() only increases use count for the first tcp md5sig peer. Signed-off-by:
-
David Ward authored
Packets should always be forwarded to the lowerdev using dev_forward_skb. vlan->forward is for packets being forwarded directly to another macvlan/ macvtap device (used for multicast in bridge mode). Reported-and-tested-by:
Shlomo Pongratz <shlomop@mellanox.com> Signed-off-by:
David Ward <david.ward@ll.mit.edu> Signed-off-by:
-
Linus Torvalds authored
-
