- Jun 02, 2014
-
-
Dave Young authored
For ioremapped efi memory aka old_map the virt addresses are not persistant across kexec reboot. kexec-tools will read the runtime maps from sysfs then pass them to 2nd kernel and assuming kexec efi boot is ok. This will cause kexec boot failure. To address this issue do not export runtime maps in case efi old_map so userspace can use no efi boot instead. Signed-off-by:
Dave Young <dyoung@redhat.com> Acked-by:
Borislav Petkov <bp@suse.de> Acked-by:
Vivek Goyal <vgoyal@redhat.com> Signed-off-by:
Matt Fleming <matt.fleming@intel.com>
-
- May 06, 2014
-
-
Andi Kleen authored
As requested by Linus add explicit __visible to the asmlinkage users. This marks all functions visible to assembler. Tree sweep for arch/x86/* Signed-off-by:
Andi Kleen <ak@linux.intel.com> Link: http://lkml.kernel.org/r/1398984278-29319-3-git-send-email-andi@firstfloor.org Signed-off-by:
H. Peter Anvin <hpa@linux.intel.com>
-
- May 03, 2014
-
-
Dave Young authored
earlyprintk=efi,keep will cause kernel hangs while freeing initmem like below: VFS: Mounted root (ext4 filesystem) readonly on device 254:2. devtmpfs: mounted Freeing unused kernel memory: 880K (ffffffff817d4000 - ffffffff818b0000) It is caused by efi earlyprintk use __init function which will be freed later. Such as early_efi_write is marked as __init, also it will use early_ioremap which is init function as well. To fix this issue, I added early initcall early_efi_map_fb which maps the whole efi fb for later use. OTOH, adding a wrapper function early_efi_map which calls early_ioremap before ioremap is available. With this patch applied efi boot ok with earlyprintk=efi,keep console=efi Signed-off-by:
Dave Young <dyoung@redhat.com> Signed-off-by:
Matt Fleming <matt.fleming@intel.com>
-
- May 02, 2014
-
-
Dave Young authored
earlyprintk=efi,keep will cause kernel hangs while freeing initmem like below: VFS: Mounted root (ext4 filesystem) readonly on device 254:2. devtmpfs: mounted Freeing unused kernel memory: 880K (ffffffff817d4000 - ffffffff818b0000) It is caused by efi earlyprintk use __init function which will be freed later. Such as early_efi_write is marked as __init, also it will use early_ioremap which is init function as well. To fix this issue, I added early initcall early_efi_map_fb which maps the whole efi fb for later use. OTOH, adding a wrapper function early_efi_map which calls early_ioremap before ioremap is available. With this patch applied efi boot ok with earlyprintk=efi,keep console=efi Signed-off-by:
Dave Young <dyoung@redhat.com> Signed-off-by:
Matt Fleming <matt.fleming@intel.com>
-
- Mar 17, 2014
-
-
Matt Fleming authored
In the thunk patches the 'attr' argument was dropped to query_variable_info(). Restore it otherwise the firmware will return EFI_INVALID_PARAMETER. Signed-off-by:
Matt Fleming <matt.fleming@intel.com>
-
Matt Fleming authored
Dan reported that phys_efi_get_time() is doing kmalloc(..., GFP_KERNEL) under a spinlock which is very clearly a bug. Since phys_efi_get_time() has no users let's just delete it instead of trying to fix it. Note that since there are no users of phys_efi_get_time(), it is not possible to actually trigger a GFP_KERNEL alloc under the spinlock. Reported-by:
Dan Carpenter <dan.carpenter@oracle.com> Cc: Ingo Molnar <mingo@kernel.org> Cc: H. Peter Anvin <hpa@zytor.com> Cc: Nathan Zimmer <nzimmer@sgi.com> Cc: Matthew Garrett <mjg59@srcf.ucam.org> Cc: Jan Beulich <JBeulich@suse.com> Signed-off-by:
Matt Fleming <matt.fleming@intel.com>
-
Matt Fleming authored
I was triggering a #GP(0) from userland when running with CONFIG_EFI_MIXED and CONFIG_IA32_EMULATION, from what looked like register corruption. Turns out that the mixed mode code was trashing the contents of %ds, %es and %ss in __efi64_thunk(). Save and restore the contents of these segment registers across the call to __efi64_thunk() so that we don't corrupt the CPU context. Signed-off-by:
Matt Fleming <matt.fleming@intel.com>
-
- Mar 05, 2014
-
-
Borislav Petkov authored
Alex reported hitting the following BUG after the EFI 1:1 virtual mapping work was merged, kernel BUG at arch/x86/mm/init_64.c:351! invalid opcode: 0000 [#1] SMP Call Trace: [<ffffffff818aa71d>] init_extra_mapping_uc+0x13/0x15 [<ffffffff818a5e20>] uv_system_init+0x22b/0x124b [<ffffffff8108b886>] ? clockevents_register_device+0x138/0x13d [<ffffffff81028dbb>] ? setup_APIC_timer+0xc5/0xc7 [<ffffffff8108b620>] ? clockevent_delta2ns+0xb/0xd [<ffffffff818a3a92>] ? setup_boot_APIC_clock+0x4a8/0x4b7 [<ffffffff8153d955>] ? printk+0x72/0x74 [<ffffffff818a1757>] native_smp_prepare_cpus+0x389/0x3d6 [<ffffffff818957bc>] kernel_init_freeable+0xb7/0x1fb [<ffffffff81535530>] ? rest_init+0x74/0x74 [<ffffffff81535539>] kernel_init+0x9/0xff [<ffffffff81541dfc>] ret_from_fork+0x7c/0xb0 [<ffffffff81535530>] ? rest_init+0x74/0x74 Getting this thing to work with the new mapping scheme would need more work, so automatically switch to the old memmap layout for SGI UV. Acked-by:
Russ Anderson <rja@sgi.com> Cc: Alex Thorlton <athorlton@sgi.com Signed-off-by:
Borislav Petkov <bp@suse.de> Signed-off-by:
Matt Fleming <matt.fleming@intel.com>
-
- Mar 04, 2014
-
-
Matt Fleming authored
Some firmware appears to enable interrupts during boot service calls, even if we've explicitly disabled them prior to the call. This is actually allowed per the UEFI spec because boottime services expect to be called with interrupts enabled. So that's fine, we just need to ensure that we disable them again in efi_enter32() before switching to a 64-bit GDT, otherwise an interrupt may fire causing a 32-bit IRQ handler to run after we've left compatibility mode. Despite efi_enter32() being called both for boottime and runtime services, this really only affects boottime because the runtime services callchain is executed with interrupts disabled. See efi_thunk(). Signed-off-by:
Matt Fleming <matt.fleming@intel.com>
-
Matt Fleming authored
Add the Kconfig option and bump the kernel header version so that boot loaders can check whether the handover code is available if they want. The xloadflags field in the bzImage header is also updated to reflect that the kernel supports both entry points by setting both of XLF_EFI_HANDOVER_32 and XLF_EFI_HANDOVER_64 when CONFIG_EFI_MIXED=y. XLF_CAN_BE_LOADED_ABOVE_4G is disabled so that the kernel text is guaranteed to be addressable with 32-bits. Note that no boot loaders should be using the bits set in xloadflags to decide which entry point to jump to. The entire scheme is based on the concept that 32-bit bootloaders always jump to ->handover_offset and 64-bit loaders always jump to ->handover_offset + 512. We set both bits merely to inform the boot loader that it's safe to use the native handover offset even if the machine type in the PE/COFF header claims otherwise. Signed-off-by:
Matt Fleming <matt.fleming@intel.com>
-
Matt Fleming authored
Setup the runtime services based on whether we're booting in EFI native mode or not. For non-native mode we need to thunk from 64-bit into 32-bit mode before invoking the EFI runtime services. Using the runtime services after SetVirtualAddressMap() is slightly more complicated because we need to ensure that all the addresses we pass to the firmware are below the 4GB boundary so that they can be addressed with 32-bit pointers, see efi_setup_page_tables(). Signed-off-by:
Matt Fleming <matt.fleming@intel.com>
-
Matt Fleming authored
Implement the transition code to go from IA32e mode to protected mode in the EFI boot stub. This is required to use 32-bit EFI services from a 64-bit kernel. Since EFI boot stub is executed in an identity-mapped region, there's not much we need to do before invoking the 32-bit EFI boot services. However, we do reload the firmware's global descriptor table (efi32_boot_gdt) in case things like timer events are still running in the firmware. Signed-off-by:
Matt Fleming <matt.fleming@intel.com>
-
Matt Fleming authored
Both efi_free_boot_services() and efi_enter_virtual_mode() are invoked from init/main.c, but only if the EFI runtime services are available. This is not the case for non-native boots, e.g. where a 64-bit kernel is booted with 32-bit EFI firmware. Delete the dead code. Acked-by:
Borislav Petkov <bp@suse.de> Signed-off-by:
Matt Fleming <matt.fleming@intel.com>
-
Borislav Petkov authored
... into a kexec flavor for better code readability and simplicity. The original one was getting ugly with ifdeffery. Signed-off-by:
Borislav Petkov <bp@suse.de> Tested-by:
Toshi Kani <toshi.kani@hp.com> Signed-off-by:
Matt Fleming <matt.fleming@intel.com>
-
Borislav Petkov authored
Currently, running SetVirtualAddressMap() and passing the physical address of the virtual map array was working only by a lucky coincidence because the memory was present in the EFI page table too. Until Toshi went and booted this on a big HP box - the krealloc() manner of resizing the memmap we're doing did allocate from such physical addresses which were not mapped anymore and boom: http://lkml.kernel.org/r/1386806463.1791.295.camel@misato.fc.hp.com One way to take care of that issue is to reimplement the krealloc thing but with pages. We start with contiguous pages of order 1, i.e. 2 pages, and when we deplete that memory (shouldn't happen all that often but you know firmware) we realloc the next power-of-two pages. Having the pages, it is much more handy and easy to map them into the EFI page table with the already existing mapping code which we're using for building the virtual mappings. Thanks to Toshi Kani and Matt for the great debugging help. Reported-by:
Toshi Kani <toshi.kani@hp.com> Signed-off-by:
Borislav Petkov <bp@suse.de> Tested-by:
Toshi Kani <toshi.kani@hp.com> Signed-off-by:
Matt Fleming <matt.fleming@intel.com>
-
Borislav Petkov authored
This is very useful for debugging issues with the recently added pagetable switching code for EFI virtual mode. Signed-off-by:
Borislav Petkov <bp@suse.de> Tested-by:
Toshi Kani <toshi.kani@hp.com> Signed-off-by:
Matt Fleming <matt.fleming@intel.com>
-
Joe Perches authored
Coalesce formats and remove spaces before tabs. Move __initdata after the variable declaration. Signed-off-by:
Joe Perches <joe@perches.com> Signed-off-by:
Matt Fleming <matt.fleming@intel.com>
-
Madper Xie authored
For now we only ensure about 5kb free space for avoiding our board refusing boot. But the comment lies that we retain 50% space. Signed-off-by:
Madper Xie <cxie@redhat.com> Signed-off-by:
Matt Fleming <matt.fleming@intel.com>
-
Matt Fleming authored
It makes more sense to set the feature flag in the success path of the detection function than it does to rely on the caller doing it. Apart from it being more logical to group the code and data together, it sets a much better example for new EFI architectures. Signed-off-by:
Matt Fleming <matt.fleming@intel.com>
-
Matt Fleming authored
As we grow support for more EFI architectures they're going to want the ability to query which EFI features are available on the running system. Instead of storing this information in an architecture-specific place, stick it in the global 'struct efi', which is already the central location for EFI state. While we're at it, let's change the return value of efi_enabled() to be bool and replace all references to 'facility' with 'feature', which is the usual word used to describe the attributes of the running system. Signed-off-by:
Matt Fleming <matt.fleming@intel.com>
-
- Feb 27, 2014
-
-
H. Peter Anvin authored
The SGI Visual Workstation seems to be dead; remove support so we don't have to continue maintaining it. Cc: Andrey Panin <pazke@donpac.ru> Cc: Michael Reed <mdr@sgi.com> Link: http://lkml.kernel.org/r/530CFD6C.7040705@zytor.com Signed-off-by:
H. Peter Anvin <hpa@linux.intel.com>
-
- Feb 14, 2014
-
-
Matt Fleming authored
Madper reported seeing the following crash, BUG: unable to handle kernel paging request at ffffffffff340003 IP: [<ffffffff81d85ba4>] efi_bgrt_init+0x9d/0x133 Call Trace: [<ffffffff81d8525d>] efi_late_init+0x9/0xb [<ffffffff81d68f59>] start_kernel+0x436/0x450 [<ffffffff81d6892c>] ? repair_env_string+0x5c/0x5c [<ffffffff81d68120>] ? early_idt_handlers+0x120/0x120 [<ffffffff81d685de>] x86_64_start_reservations+0x2a/0x2c [<ffffffff81d6871e>] x86_64_start_kernel+0x13e/0x14d This is caused because the layout of the ACPI BGRT header on this system doesn't match the definition from the ACPI spec, and so we get a bogus physical address when dereferencing ->image_address in efi_bgrt_init(). Luckily the status field in the BGRT header clearly marks it as invalid, so we can check that field and skip BGRT initialisation. Reported-by:
Madper Xie <cxie@redhat.com> Suggested-by:
Toshi Kani <toshi.kani@hp.com> Cc: "Rafael J. Wysocki" <rjw@rjwysocki.net> Cc: Matthew Garrett <mjg59@srcf.ucam.org> Cc: Josh Triplett <josh@joshtriplett.org> Signed-off-by:
Matt Fleming <matt.fleming@intel.com>
-
Borislav Petkov authored
We do not enable the new efi memmap on 32-bit and thus we need to run runtime_code_page_mkexec() unconditionally there. Fix that. Reported-and-tested-by:
Lejun Zhu <lejun.zhu@intel.com> Signed-off-by:
Borislav Petkov <bp@suse.de> Signed-off-by:
Matt Fleming <matt.fleming@intel.com>
-
Andi Kleen authored
const data must be initconst. Signed-off-by:
Andi Kleen <ak@linux.intel.com> Link: http://lkml.kernel.org/r/1391845930-28580-14-git-send-email-ak@linux.intel.com Signed-off-by:
H. Peter Anvin <hpa@linux.intel.com>
-
- Feb 06, 2014
-
-
Matt Fleming authored
CONFIG_X86_32 doesn't map the boot services regions into the EFI memory map (see commit 70087011 ("x86, efi: Don't map Boot Services on i386")), and so efi_lookup_mapped_addr() will fail to return a valid address. Executing the ioremap() path in efi_bgrt_init() causes the following warning on x86-32 because we're trying to ioremap() RAM, WARNING: CPU: 0 PID: 0 at arch/x86/mm/ioremap.c:102 __ioremap_caller+0x2ad/0x2c0() Modules linked in: CPU: 0 PID: 0 Comm: swapper/0 Not tainted 3.13.0-0.rc5.git0.1.2.fc21.i686 #1 Hardware name: DellInc. Venue 8 Pro 5830/09RP78, BIOS A02 10/17/2013 00000000 00000000 c0c0df08 c09a5196 00000000 c0c0df38 c0448c1e c0b41310 00000000 00000000 c0b37bc1 00000066 c043bbfd c043bbfd 00e7dfe0 00073eff 00073eff c0c0df48 c0448ce2 00000009 00000000 c0c0df9c c043bbfd 00078d88 Call Trace: [<c09a5196>] dump_stack+0x41/0x52 [<c0448c1e>] warn_slowpath_common+0x7e/0xa0 [<c043bbfd>] ? __ioremap_caller+0x2ad/0x2c0 [<c043bbfd>] ? __ioremap_caller+0x2ad/0x2c0 [<c0448ce2>] warn_slowpath_null+0x22/0x30 [<c043bbfd>] __ioremap_caller+0x2ad/0x2c0 [<c0718f92>] ? acpi_tb_verify_table+0x1c/0x43 [<c0719c78>] ? acpi_get_table_with_size+0x63/0xb5 [<c087cd5e>] ? efi_lookup_mapped_addr+0xe/0xf0 [<c043bc2b>] ioremap_nocache+0x1b/0x20 [<c0cb01c8>] ? efi_bgrt_init+0x83/0x10c [<c0cb01c8>] efi_bgrt_init+0x83/0x10c [<c0cafd82>] efi_late_init+0x8/0xa [<c0c9bab2>] start_kernel+0x3ae/0x3c3 [<c0c9b53b>] ? repair_env_string+0x51/0x51 [<c0c9b378>] i386_start_kernel+0x12e/0x131 Switch to using early_memremap(), which won't trigger this warning, and has the added benefit of more accurately conveying what we're trying to do - map a chunk of memory. This patch addresses the following bug report, https://bugzilla.kernel.org/show_bug.cgi?id=67911 Reported-by:
Adam Williamson <awilliam@redhat.com> Cc: Josh Triplett <josh@joshtriplett.org> Cc: Matthew Garrett <mjg59@srcf.ucam.org> Cc: Rafael J. Wysocki <rjw@rjwysocki.net> Signed-off-by:
Matt Fleming <matt.fleming@intel.com>
-
- Jan 29, 2014
-
-
David Cohen authored
platform_ipc.h and platform_msic.h are wrongly declaring functions as external and with 'weak' attribute. This patch does a cleanup on those header files. It should have no functional change. Signed-off-by:
David Cohen <david.a.cohen@linux.intel.com> Link: http://lkml.kernel.org/r/1390950567-12821-1-git-send-email-david.a.cohen@linux.intel.com Cc: Bjorn Helgaas <bhelgaas@google.com> Signed-off-by:
H. Peter Anvin <hpa@linux.intel.com>
-
- Jan 25, 2014
-
-
Mike Travis authored
Fix UV call into kgdb to depend only on whether KGDB is defined and not both KGDB and KDB. This allows the power nmi command to use the gdb remote connection if enabled. Note new action of 'kgdb' needs to be set as well to indicate user wants to wait for gdb to be connected. If it's set to 'kdb' then an error message is displayed if KDB is not configured. Also note that if both KGDB and KDB are enabled, then the action of 'kgdb' or 'kdb' has no affect on which is used. See the KGDB documentation for further information. Signed-off-by:
Mike Travis <travis@sgi.com> Reviewed-by:
Hedi Berriche <hedi@sgi.com> Cc: Russ Anderson <rja@sgi.com> Cc: Jason Wessel <jason.wessel@windriver.com> Cc: Peter Zijlstra <a.p.zijlstra@chello.nl> Cc: Paul Mackerras <paulus@samba.org> Cc: Arnaldo Carvalho de Melo <acme@ghostprotocols.net> Link: http://lkml.kernel.org/r/20140114162551.635540667@asylum.americas.sgi.com Signed-off-by:
Ingo Molnar <mingo@kernel.org>
-
Mike Travis authored
Make uv_register_nmi_notifier() and uv_handle_nmi_ping() static to address sparse warnings. Fix problem where uv_nmi_kexec_failed is unused when CONFIG_KEXEC is not defined. Signed-off-by:
Mike Travis <travis@sgi.com> Reviewed-by:
Hedi Berriche <hedi@sgi.com> Cc: Russ Anderson <rja@sgi.com> Cc: Jason Wessel <jason.wessel@windriver.com> Cc: Peter Zijlstra <a.p.zijlstra@chello.nl> Cc: Paul Mackerras <paulus@samba.org> Cc: Arnaldo Carvalho de Melo <acme@ghostprotocols.net> Link: http://lkml.kernel.org/r/20140114162551.480872353@asylum.americas.sgi.com Signed-off-by:
Ingo Molnar <mingo@kernel.org>
-
Mike Travis authored
Some code added to the debug_core module had KDB dependencies that it shouldn't have. Move the KDB dependent REASON back to the caller to remove the dependency in the debug core code. Update the call from the UV NMI handler to conform to the new interface. Signed-off-by:
Mike Travis <travis@sgi.com> Reviewed-by:
Hedi Berriche <hedi@sgi.com> Cc: Russ Anderson <rja@sgi.com> Cc: Jason Wessel <jason.wessel@windriver.com> Cc: Peter Zijlstra <a.p.zijlstra@chello.nl> Cc: Paul Mackerras <paulus@samba.org> Cc: Arnaldo Carvalho de Melo <acme@ghostprotocols.net> Link: http://lkml.kernel.org/r/20140114162551.318251993@asylum.americas.sgi.com Signed-off-by:
Ingo Molnar <mingo@kernel.org>
-
- Jan 22, 2014
-
-
David Cohen authored
This patch adds missing 'void' to functions that doesn't receive arguments. Signed-off-by:
David Cohen <david.a.cohen@linux.intel.com> Link: http://lkml.kernel.org/r/1390429369-13761-1-git-send-email-david.a.cohen@linux.intel.com Signed-off-by:
H. Peter Anvin <hpa@linux.intel.com>
-
Paul Gortmaker authored
Commit bc20aa48 ("x86, intel-mid: Add Merrifield platform support") added new instances of __cpuinit usage. We removed this a couple versions ago; we now want to remove the compat no-op stubs. Introducing new users is not what we want to see at this point in time, as it will break once the stubs are gone. This also fixes an out of sync __init vs. __cpuinit -- as the former is real, and the latter is a no-op; hence it would have been a section mismatch. Cc: Fei Yang <fei.yang@intel.com> Cc: H. Peter Anvin <hpa@linux.intel.com> Signed-off-by:
Paul Gortmaker <paul.gortmaker@windriver.com> Acked-by:
David Cohen <david.a.cohen@linux.intel.com> Link: http://lkml.kernel.org/r/1390412125-19439-1-git-send-email-paul.gortmaker@windriver.com Signed-off-by:
H. Peter Anvin <hpa@linux.intel.com>
-
Paul Gortmaker authored
Commit 85611e3f ("x86, intel-mid: Add Clovertrail platform support") added new instances of __cpuinit usage. We removed this a couple versions ago; we now want to remove the compat no-op stubs. Introducing new users is not what we want to see at this point in time, as it will break once the stubs are gone. Reported-by:
kbuild test robot <fengguang.wu@intel.com> Cc: Kuppuswamy Sathyanarayanan <sathyanarayanan.kuppuswamy@linux.intel.com> Cc: Fei Yang <fei.yang@intel.com> Signed-off-by:
Paul Gortmaker <paul.gortmaker@windriver.com> Acked-by:
David Cohen <david.a.cohen@linux.intel.com> Link: http://lkml.kernel.org/r/1390412055-19341-1-git-send-email-paul.gortmaker@windriver.com Signed-off-by:
H. Peter Anvin <hpa@linux.intel.com>
-
- Jan 17, 2014
-
-
Fengguang Wu authored
This is a cleanup proposed by coccinelle. It replaces memcpy with struct assignment on intel-mid's sfi layer. Generated by: coccinelle/misc/memcpy-assign.cocci Signed-off-by:
Fengguang Wu <fengguang.wu@intel.com> Link: http://lkml.kernel.org/r/1389917588-9785-1-git-send-email-david.a.cohen@linux.intel.com Signed-off-by:
David Cohen <david.a.cohen@linux.intel.com> Signed-off-by:
H. Peter Anvin <hpa@linux.intel.com>
-
David Cohen authored
This patch cleans up get_gpio_by_name() to return an error code instead of hardcoded -1. Signed-off-by:
David Cohen <david.a.cohen@linux.intel.com> Link: http://lkml.kernel.org/r/1389913624-9149-4-git-send-email-david.a.cohen@linux.intel.com Signed-off-by:
H. Peter Anvin <hpa@linux.intel.com>
-
David Cohen authored
This patch does cleanup on all intel mid platform code that uses gpio_get_by_name() function. From now on they should check for any error code instead of only hardcoded -1. There are no functional changes from this change. Signed-off-by:
David Cohen <david.a.cohen@linux.intel.com> Link: http://lkml.kernel.org/r/1389913624-9149-3-git-send-email-david.a.cohen@linux.intel.com Signed-off-by:
H. Peter Anvin <hpa@linux.intel.com>
-
David Cohen authored
When Intel MID finds a match between SFI table from FW and registered SFI devices, it will always register a device regardless the platform code was successful or not. This patch adds an extra option for platform code to return error code and abort device registration on SFI table parsing. This patch does not contain any functional changes for current intel mid platform code. Signed-off-by:
David Cohen <david.a.cohen@linux.intel.com> Link: http://lkml.kernel.org/r/1389913624-9149-2-git-send-email-david.a.cohen@linux.intel.com Signed-off-by:
H. Peter Anvin <hpa@linux.intel.com>
-
- Jan 15, 2014
-
-
David Cohen authored
This code was partially based on Mark Brown's previous work. Signed-off-by:
David Cohen <david.a.cohen@linux.intel.com> Link: http://lkml.kernel.org/r/1387224459-25746-4-git-send-email-david.a.cohen@linux.intel.com Signed-off-by:
Fei Yang <fei.yang@intel.com> Cc: Mark F. Brown <mark.f.brown@intel.com> Cc: Kuppuswamy Sathyanarayanan <sathyanarayanan.kuppuswamy@linux.intel.com> Signed-off-by:
H. Peter Anvin <hpa@linux.intel.com>
-
Kuppuswamy Sathyanarayanan authored
This patch adds Clovertrail support on intel-mid and makes it more flexible to support other SoCs. Signed-off-by:
David Cohen <david.a.cohen@linux.intel.com> Link: http://lkml.kernel.org/r/1387224459-25746-3-git-send-email-david.a.cohen@linux.intel.com Signed-off-by:
Kuppuswamy Sathyanarayanan <sathyanarayanan.kuppuswamy@linux.intel.com> Signed-off-by:
Fei Yang <fei.yang@intel.com> Signed-off-by:
H. Peter Anvin <hpa@linux.intel.com>
-
David Cohen authored
In order make the driver more portable and support other Intel MID (Mobile Internet Device) platforms we need to move Medfield code from intel-mid.c core to its own mfld.c file. This patch contains no functional changes. Signed-off-by:
David Cohen <david.a.cohen@linux.intel.com> Link: http://lkml.kernel.org/r/1387224459-25746-2-git-send-email-david.a.cohen@linux.intel.com Signed-off-by:
Kuppuswamy Sathyanarayanan <sathyanarayanan.kuppuswamy@linux.intel.com> Signed-off-by:
H. Peter Anvin <hpa@linux.intel.com>
-
- Jan 13, 2014
-
-
Peter Zijlstra authored
Use a ring-buffer like multi-version object structure which allows always having a coherent object; we use this to avoid having to disable IRQs while reading sched_clock() and avoids a problem when getting an NMI while changing the cyc2ns data. MAINLINE PRE POST sched_clock_stable: 1 1 1 (cold) sched_clock: 329841 331312 257223 (cold) local_clock: 301773 310296 309889 (warm) sched_clock: 38375 38247 25280 (warm) local_clock: 100371 102713 85268 (warm) rdtsc: 27340 27289 24247 sched_clock_stable: 0 0 0 (cold) sched_clock: 382634 372706 301224 (cold) local_clock: 396890 399275 399870 (warm) sched_clock: 38194 38124 25630 (warm) local_clock: 143452 148698 129629 (warm) rdtsc: 27345 27365 24307 Signed-off-by:
Peter Zijlstra <peterz@infradead.org> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Andrew Morton <akpm@linux-foundation.org> Link: http://lkml.kernel.org/n/tip-s567in1e5ekq2nlyhn8f987r@git.kernel.org Signed-off-by:
Ingo Molnar <mingo@kernel.org>
-