- 13 Feb, 2013 1 commit
-
-
Daniel Vetter authored
This reverts commit 6f33814b. The quirk cause a regression, and it looks like the original bug was simply a lack of FIFO bandwidth on the i915G of the reporter. Which should eventually be fixed as soon as we get around to implemented DSPARB FIFO reassignment on gen 3. Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=52281 Cc: stable@vger.kernel.org Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Dave Airlie <airlied@redhat.com>
-
- 08 Feb, 2013 25 commits
-
-
git://people.freedesktop.org/~mlankhorst/linuxDave Airlie authored
TTM reservations changes, preparing for new reservation mutex system. * 'for-airlied' of git://people.freedesktop.org/~mlankhorst/linux: drm/ttm: unexport ttm_bo_wait_unreserved drm/nouveau: use ttm_bo_reserve_slowpath in validate_init, v2 drm/ttm: use ttm_bo_reserve_slowpath_nolru in ttm_eu_reserve_buffers, v2 drm/ttm: add ttm_bo_reserve_slowpath drm/ttm: cleanup ttm_eu_reserve_buffers handling drm/ttm: remove lru_lock around ttm_bo_reserve drm/nouveau: increase reservation sequence every retry drm/vmwgfx: always use ttm_bo_is_reserved
-
Daniel Kurtz authored
It is a bit more precise to compute the total number of pixels first and then divide, rather than multiplying the line pixel count by the already-rounded line duration. Signed-off-by: Daniel Kurtz <djkurtz@chromium.org> Signed-off-by: Dave Airlie <airlied@redhat.com>
-
Bjorn Helgaas authored
Use PCI Express Capability access functions to simplify this code a bit. For non-PCIe devices or pre-PCIe 3.0 devices that don't implement the Link Capabilities 2 register, pcie_capability_read_dword() reads a zero. Since we're only testing whether the bits we care about are set, there's no need to mask out the other bits we *don't* care about. Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
-
Bjorn Helgaas authored
For devices that conform to PCIe r3.0 and have a Link Capabilities 2 register, we test and report every bit in the Supported Link Speeds Vector field. For a device that supports both 2.5GT/s and 5.0GT/s, we set both DRM_PCIE_SPEED_25 and DRM_PCIE_SPEED_50 in the returned mask. For pre-r3.0 devices, the Link Capabilities 0010b encoding (PCI_EXP_LNKCAP_SLS_5_0GB) means that both 5.0GT/s and 2.5GT/s are supported, so set both DRM_PCIE_SPEED_25 and DRM_PCIE_SPEED_50 in this case as well. Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
-
Bjorn Helgaas authored
Use the standard #defines rather than bare numbers for the PCIe Link Capabilities speed bits. Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
-
Thierry Reding authored
Drivers that register interrupt handlers without the DRM core helpers don't initialize the .irq_enabled field and drm_dev_to_irq() may fail when called on them. This shouldn't preclude them from implementing the vblank IOCTL. Signed-off-by: Thierry Reding <thierry.reding@avionic-design.de> Signed-off-by: Dave Airlie <airlied@redhat.com>
-
Aaron Plattner authored
Simplify the Radeon prime implementation by using the default behavior provided by drm_gem_prime_import and drm_gem_prime_export. v2: - Rename functions to radeon_gem_prime_get_sg_table and radeon_gem_prime_import_sg_table. - Delete the now-unused vmapping_count variable. Signed-off-by: Aaron Plattner <aplattner@nvidia.com> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: David Airlie <airlied@linux.ie> Signed-off-by: Dave Airlie <airlied@redhat.com>
-
Aaron Plattner authored
Simplify the Nouveau prime implementation by using the default behavior provided by drm_gem_prime_import and drm_gem_prime_export. v2: Rename functions to nouveau_gem_prime_get_sg_table and nouveau_gem_prime_import_sg_table. Signed-off-by: Aaron Plattner <aplattner@nvidia.com> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: David Airlie <airlied@linux.ie> Signed-off-by: Dave Airlie <airlied@redhat.com>
-
Aaron Plattner authored
Instead of reimplementing all of the dma_buf functionality in every driver, create helpers drm_prime_import and drm_prime_export that implement them in terms of new, lower-level hook functions: gem_prime_pin: callback when a buffer is created, used to pin buffers into GTT gem_prime_get_sg_table: convert a drm_gem_object to an sg_table for export gem_prime_import_sg_table: convert an sg_table into a drm_gem_object gem_prime_vmap, gem_prime_vunmap: map and unmap an object These hooks are optional; drivers can opt in by using drm_gem_prime_import and drm_gem_prime_export as the .gem_prime_import and .gem_prime_export fields of struct drm_driver. v2: - Drop .begin_cpu_access. None of the drivers this code replaces implemented it. Having it here was a leftover from when I was trying to include i915 in this rework. - Use mutex_lock instead of mutex_lock_interruptible, as these three drivers did. This patch series shouldn't change that behavior. - Rename helpers to gem_prime_get_sg_table and gem_prime_import_sg_table. Rename struct sg_table* variables to 'sgt' for clarity. - Update drm.tmpl for these new hooks. v3: - Pass the vaddr down to the driver. This lets drivers that just call vunmap on the pointer avoid having to store the pointer in their GEM private structures. - Move documentation into a /** DOC */ comment in drm_prime.c and include it in drm.tmpl with a !P line. I tried to use !F lines to include documentation of the individual functions from drmP.h, but the docproc / kernel-doc scripts barf on that file, so hopefully this is good enough for now. - apply refcount fix from commit be8a42ae ("drm/prime: drop reference on imported dma-buf come from gem") Signed-off-by: Aaron Plattner <aplattner@nvidia.com> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: David Airlie <airlied@linux.ie> Signed-off-by: Dave Airlie <airlied@redhat.com>
-
Rob Clark authored
Move this out of nouveau directory. As we start to add more encoder slaves used by other drivers, it makes sense to put the Kconfig bits in one place. Signed-off-by: Rob Clark <robdclark@gmail.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
-
git://people.freedesktop.org/~agd5f/linuxDave Airlie authored
Alex writes: - CS ioctl cleanup and unification. Unification of a lot of functionality that was duplicated across multiple generates of hardware. - Add support for Oland GPUs - Deprecate UMS support. Mesa and the ddx dropped support for UMS and apparently very few people still use it since the UMS CS ioctl was broken for several kernels and no one reported it. It was fixed in 3.8/stable. - Rework GPU reset. Use the status registers to determine what blocks to reset. This better matches the recommended reset programming model. This also allows us to properly reset blocks besides GFX and DMA. - Switch the VM set page code to use an IB rather than the ring. This fixes overflow issues when doing large page table updates using a small ring like DMA. - Several small cleanups and bug fixes. * 'drm-next-3.9' of git://people.freedesktop.org/~agd5f/linux: (38 commits) drm/radeon/dce6: fix display powergating drm/radeon: add Oland pci ids drm/radeon: radeon-asic updates for Oland drm/radeon: add ucode loading support for Oland drm/radeon: fill in gpu init for Oland drm/radeon: add Oland chip family drm/radeon: switch back to using the DMA ring for VM PT updates drm/radeon: use IBs for VM page table updates v2 drm/radeon: don't reset the MC on IGPs/APUs drm/radeon: use the reset mask to determine if rings are hung drm/radeon: halt engines before disabling MC (si) drm/radeon: halt engines before disabling MC (cayman/TN) drm/radeon: halt engines before disabling MC (evergreen) drm/radeon: halt engines before disabling MC (6xx/7xx) drm/radeon: use status regs to determine what to reset (si) drm/radeon: use status regs to determine what to reset (cayman) drm/radeon: use status regs to determine what to reset (evergreen) drm/radeon: use status regs to determine what to reset (6xx/7xx) drm/radeon: rework GPU reset on cayman/TN drm/radeon: rework GPU reset on cayman/TN ...
-
git://git.pengutronix.de/git/str/linuxDave Airlie authored
videomode helpers for of + devicetree stuff, required for new kms drivers (not the fbdev maintainer). * tag 'of_videomode_helper' of git://git.pengutronix.de/git/str/linux: drm_modes: add of_videomode helpers drm_modes: add videomode helpers fbmon: add of_videomode helpers fbmon: add videomode helpers video: add of helper for display timings/videomode video: add display_timing and videomode viafb: rename display_timing to via_display_timing
-
Dave Airlie authored
Fixes for usb/udl devices * udl-fixes: drm/udl: disable fb_defio by default drm/udl: Inline memcmp() for RLE compression of xfer drm/udl: make usage as a console safer drm/usb: bind driver to correct device
-
Dave Airlie authored
(not the fbcon maintainer pull 2) fix bug in vgacon on bootup and fbcon losing fonts on startup. * console-fixes: (50 commits) fbcon: don't lose the console font across generic->chip driver switch vgacon/vt: clear buffer attributes when we load a 512 character font (v2)
-
ssh://people.freedesktop.org/~airlied/linuxDave Airlie authored
This pulls in most of Linus tree up to -rc6, this fixes the worst lockdep reported issues and re-enables fbcon lockdep. (not the fbcon maintainer) * 'fbcon-locking-fixes' of ssh://people.freedesktop.org/~airlied/linux: (529 commits) Revert "Revert "console: implement lockdep support for console_lock"" fbcon: fix locking harder fb: Yet another band-aid for fixing lockdep mess fb: rework locking to fix lock ordering on takeover
-
Dave Airlie authored
This reverts commit ff0d05bf. Now that we have all the locking fixes in place, we can revert the revert. This re-enables lockdep tracking for the console lock, daee7797. Signed-off-by: Dave Airlie <airlied@redhat.com>
-
Dave Airlie authored
Okay so Alan's patch handled the case where there was no registered fbcon, however the other path entered in set_con2fb_map pit. In there we called fbcon_takeover, but we also took the console lock in a couple of places. So push the console lock out to the callers of set_con2fb_map, this means fbmem and switcheroo needed to take the lock around the fb notifier entry points that lead to this. This should fix the efifb regression seen by Maarten. Tested-by: Maarten Lankhorst <maarten.lankhorst@canonical.com> Tested-by: Lu Hua <huax.lu@intel.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
-
Takashi Iwai authored
I've still got lockdep warnings even after Alan's patch, and it seems that yet more band aids are required to paper over similar paths for unbind_con_driver() and unregister_con_driver(). After this hack, lockdep warnings are finally gone. Signed-off-by: Takashi Iwai <tiwai@suse.de> Cc: Alan Cox <alan@linux.intel.com> Cc: Florian Tobias Schandinat <FlorianSchandinat@gmx.de> Cc: Jiri Kosina <jkosina@suse.cz> Cc: stable <stable@vger.kernel.org> Tested-by: Sedat Dilek <sedat.dilek@gmail.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Dave Airlie <airlied@redhat.com>
-
Alan Cox authored
Adjust the console layer to allow a take over call where the caller already holds the locks. Make the fb layer lock in order. This is partly a band aid, the fb layer is terminally confused about the locking rules it uses for its notifiers it seems. [akpm@linux-foundation.org: remove stray non-ascii char, tidy comment] [akpm@linux-foundation.org: export do_take_over_console()] [airlied: cleanup another non-ascii char] Signed-off-by: Alan Cox <alan@linux.intel.com> Cc: Florian Tobias Schandinat <FlorianSchandinat@gmx.de> Cc: Stephen Rothwell <sfr@canb.auug.org.au> Cc: Jiri Kosina <jkosina@suse.cz> Cc: stable <stable@vger.kernel.org> Tested-by: Sedat Dilek <sedat.dilek@gmail.com> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Dave Airlie <airlied@redhat.com>
-
Borislav Petkov authored
I've been getting the following warning when doing randbuilds since forever. Now it finally pissed me off just the perfect amount so that I can fix it. arch/x86/kernel/cpu/intel_cacheinfo.c:489:27: warning: ‘cache_disable_0’ defined but not used [-Wunused-variable] arch/x86/kernel/cpu/intel_cacheinfo.c:491:27: warning: ‘cache_disable_1’ defined but not used [-Wunused-variable] arch/x86/kernel/cpu/intel_cacheinfo.c:524:27: warning: ‘subcaches’ defined but not used [-Wunused-variable] It happens because in randconfigs where CONFIG_SYSFS is not set, the whole sysfs-interface to L3 cache index disabling is remaining unused and gcc correctly warns about it. Make it optional, depending on CONFIG_SYSFS too, as is the case with other sysfs-related machinery in this file. Signed-off-by: Borislav Petkov <bp@suse.de> Cc: Andreas Herrmann <andreas.herrmann3@amd.com> Link: http://lkml.kernel.org/r/1359969195-27362-1-git-send-email-bp@alien8.deSigned-off-by: Ingo Molnar <mingo@kernel.org>
-
H. Peter Anvin authored
The boot protocol 2.12 changes were pulled for 3.8, so update the documentation accordingly. Signed-off-by: H. Peter Anvin <hpa@linux.intel.com>
-
Jan Beulich authored
For some reason they didn't get replaced so far by their paravirt equivalents, resulting in code to be run with interrupts disabled that doesn't expect so (causing, in the observed case, a BUG_ON() to trigger) when syscall auditing is enabled. David (Cc-ed) came up with an identical fix, so likely this can be taken to count as an ack from him. Reported-by: Peter Moody <pmoody@google.com> Signed-off-by: Jan Beulich <jbeulich@suse.com> Cc: David Vrabel <david.vrabel@citrix.com> Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> Link: http://lkml.kernel.org/r/5108E01902000078000BA9C5@nat28.tlf.novell.comSigned-off-by: Ingo Molnar <mingo@kernel.org> Cc: stable@vger.kernel.org Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> Cc: David Vrabel <david.vrabel@citrix.com> Tested-by: Peter Moody <pmoody@google.com>
-
Dave Airlie authored
There seems to be a bad interaction between gem/shmem and defio on top, I get list corruption on the page lru in the shmem code. Turn it off for now until we get some more digging done. Cc: stable@vger.kernel.org Signed-off-by: Dave Airlie <airlied@redhat.com>
-
Chris Wilson authored
As we use a variable length the compiler does not realise that it is a fixed value of either 2 or 4 bytes. Instead of performing the inline comparison itself, the compiler inserts a function call to the generic memcmp routine which is optimised for long comparisons of variable length. That turns out to be quite expensive... Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Dave Airlie <airlied@redhat.com>
-
Dave Airlie authored
Merge tag 'drm-intel-next-2013-02-01' of git://people.freedesktop.org/~danvet/drm-intel into drm-next Daniel writes: "Probably the last feature pull for 3.9, there's some fixes outstanding thought that I'd like to sneak in. And maybe 3.8 takes a bit longer ... Anyway, highlights of this pull: - Kill the horrible IS_DISPLAYREG hack to handle the mmio offset movements on vlv, big thanks to Ville. - Dynamic power well support for Haswell, shaves away a bit when only using the eDP port on pipe A (Paulo). Plus unclaimed register fixes uncovered by this. - Clarifications of the gpu hang/reset state transitions, hopefully fixing a few spurious -EIO deaths in userspace. - Haswell ELD fixes. - Some more (pp)gtt cleanups from Ben. - A few smaller things all over. Plus all the stuff from the previous rather small pull request: - Broadcast RBG improvements and reduced color range fixes from Ville. - Ben is on a "kill legacy gtt code for good" spree, first pile of patches included. - No-relocs and bo lut improvements for faster execbuf from Chris. - Some refactorings from Imre." * tag 'drm-intel-next-2013-02-01' of git://people.freedesktop.org/~danvet/drm-intel: (101 commits) GPU/i915: Fix acpi_bus_get_device() check in drivers/gpu/drm/i915/intel_opregion.c drm/i915: Set the SR01 "screen off" bit in i915_redisable_vga() too drm/i915: Kill IS_DISPLAYREG() drm/i915: Introduce i915_vgacntrl_reg() drm/i915: gen6_gmch_remove can be static drm/i915: dynamic Haswell display power well support drm/i915: check the power down well on assert_pipe() drm/i915: don't send DP "idle" pattern before "normal" on HSW PORT_A drm/i915: don't run hsw power well code on !hsw drm/i915: kill cargo-culted locking from power well code drm/i915: Only run idle processing from i915_gem_retire_requests_worker drm/i915: Fix CAGF for HSW drm/i915: Reclaim GTT space for failed PPGTT drm/i915: remove intel_gtt structure drm/i915: Add probe and remove to the gtt ops drm/i915: extract hw ppgtt setup/cleanup code drm/i915: pte_encode is gen6+ drm/i915: vfuncs for ppgtt drm/i915: vfuncs for gtt_clear_range/insert_entries drm/i915: Error state should print /sys/kernel/debug ...
-
- 07 Feb, 2013 4 commits
-
-
Dave Airlie authored
Okay you don't really want to use udl devices as your console, but if you are unlucky enough to do so, you run into a lot of schedule while atomic due to printk being called from all sorts of funky places. So check if we are in an atomic context, and queue the damage for later, the next printk should cause it to appear. This isn't ideal, but it is simple, and seems to work okay in my testing here. (dirty area idea came from xenfb) fixes a bunch of sleeping while atomic issues running fbcon on udl devices. Cc: stable@vger.kernel.org Signed-off-by: Dave Airlie <airlied@redhat.com>
-
Dave Airlie authored
While looking at plymouth on udl I noticed that plymouth was trying to use its fb plugin not its drm one, it was trying to drmOpen a driver called usb not udl, noticed that we actually had out driver pointing at the wrong device. Cc: stable@vger.kernel.org Signed-off-by: Dave Airlie <airlied@redhat.com>
-
Dave Airlie authored
If grub2 loads efifb/vesafb, then when systemd starts it can set the console font on that framebuffer device, however when we then load the native KMS driver, the first thing it does is tear down the generic framebuffer driver. The thing is the generic code is doing the right thing, it frees the font because otherwise it would leak memory. However we can assume that if you are removing the generic firmware driver (vesa/efi/offb), that a new driver *should* be loading soon after, so we effectively leak the font. However the old code left a dangling pointer in vc->vc_font.data and we can now reuse that dangling pointer to load the font into the new driver, now that we aren't freeing it. Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=892340 Cc: Kay Sievers <kay.sievers@vrfy.org> Cc: stable@vger.kernel.org Signed-off-by: Dave Airlie <airlied@redhat.com>
-
Dave Airlie authored
When we switch from 256->512 byte font rendering mode, it means the current contents of the screen is being reinterpreted. The bit that holds the high bit of the 9-bit font, may have been previously set, and thus the new font misrenders. The problem case we see is grub2 writes spaces with the bit set, so it ends up with data like 0x820, which gets reinterpreted into 0x120 char which the font translates into G with a circumflex. This flashes up on screen at boot and is quite ugly. A current side effect of this patch though is that any rendering on the screen changes color to a slightly darker color, but at least the screen no longer corrupts. v2: as suggested by hpa, always clear the attribute space, whether we are are going to or from 512 chars. Cc: stable@vger.kernel.org Signed-off-by: Dave Airlie <airlied@redhat.com>
-
- 05 Feb, 2013 10 commits
-
-
Alex Deucher authored
Only enable it when we disable the display rather than at DPMS time since enabling it requires a full modeset to restore the display state. Fixes blank screens in certain cases. Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Cc: stable@vger.kernel.org
-
git://git.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-mediaLinus Torvalds authored
Pull media fixes from Mauro Carvalho Chehab: "For a regression fix on a few radio drivers that were preventing radio TX to work on those devices" * 'v4l_for_linus' of git://git.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-media: [media] radio: set vfl_dir correctly to fix modulator regression
-
git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usbLinus Torvalds authored
Pull USB fixes from Greg Kroah-Hartman: "Here are a few tiny USB fixes for 3.8-rc6. Nothing major here, some host controller bug fixes to resolve a number of bugs that people have reported, and a bunch of additional device ids are added to a number of drivers (which caused code to be deleted from the usb-storage driver, always nice)" * tag 'usb-3.8-rc6' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb: (22 commits) USB: storage: optimize to match the Huawei USB storage devices and support new switch command USB: storage: Define a new macro for USB storage match rules USB: ftdi_sio: add Zolix FTDI PID USB: option: add Changhong CH690 USB: ftdi_sio: add PID/VID entries for ELV WS 300 PC II USB: add OWL CM-160 support to cp210x driver USB: EHCI: fix bug in scheduling periodic split transfers USB: EHCI: fix for leaking isochronous data USB: option: add support for Telit LE920 USB: qcserial: add Telit Gobi QDL device USB: EHCI: fix timer bug affecting port resume USB: UHCI: notify usbcore about port resumes USB: EHCI: notify usbcore about port resumes USB: add usb_hcd_{start,end}_port_resume USB: EHCI: unlink one async QH at a time USB: EHCI: remove ASS/PSS polling timeout usb: Using correct way to clear usb3.0 device's remote wakeup feature. usb: Prevent dead ports when xhci is not enabled USB: XHCI: fix memory leak of URB-private data drivers: xhci: fix incorrect bit test ...
-
git://git.linaro.org/people/mszyprowski/linux-dma-mappingLinus Torvalds authored
Pull DMA mapping fixes from Marek Szyprowski: "This pull request contains important bugfix patches for 9 architectures, which finally fixes broken allmodconfig builds introduced in v3.8-rc1. Those architectures don't use dma_map_ops based implementation and require manual update or additional dummy implementations of the missing new dma-mapping api functions: dma_mmap_coherent and dma_get_sgtable." * 'fixes-for-v3.8-rc7' of git://git.linaro.org/people/mszyprowski/linux-dma-mapping: xtensa: Provide dummy dma_mmap_coherent() and dma_get_sgtable() parisc: Provide dummy dma_mmap_coherent() and dma_get_sgtable() mn10300: Provide dummy dma_mmap_coherent() and dma_get_sgtable() m68k: Provide dma_mmap_coherent() and dma_get_sgtable() frv: Provide dummy dma_mmap_coherent() and dma_get_sgtable() cris: Provide dma_mmap_coherent() and dma_get_sgtable() c6x: Provide dummy dma_mmap_coherent() and dma_get_sgtable() blackfin: Provide dma_mmap_coherent() and dma_get_sgtable() avr32: Provide dma_mmap_coherent() and dma_get_sgtable()
-
git://git.kernel.org/pub/scm/linux/kernel/git/teigland/linux-dlmLinus Torvalds authored
Pull dlm fix from David Teigland: "Thanks to Jana who reported the problem and was able to test this fix so quickly." This fixes an incorrect size check that triggered for CONFIG_COMPAT whether the code was actually doing compat or not. The incorrect write size check broke userland (clvmd) when maximum resource name lengths are used. * 'fix-max-write' of git://git.kernel.org/pub/scm/linux/kernel/git/teigland/linux-dlm: dlm: check the write size from user
-
Linus Torvalds authored
Merge mix fixes from Andrew Morton. * emailed patches from Andrew Morton <akpm@linux-foundation.org>: (12 commits) drivers/rtc/rtc-pl031.c: fix the missing operation on enable drivers/rtc/rtc-isl1208.c: call rtc_update_irq() from the alarm irq handler samples/seccomp: be less stupid about cross compiling checkpatch: fix $Float creation of match variables memcg: fix typo in kmemcg cache walk macro mm: fix wrong comments about anon_vma lock MAINTAINERS: update avr32 web ressources mm/hugetlb: set PTE as huge in hugetlb_change_protection and remove_migration_pte drivers/rtc/rtc-vt8500.c: fix year field in vt8500_rtc_set_time() tools/vm: add .gitignore to ignore built binaries thp: avoid dumping huge zero page nilfs2: fix fix very long mount time issue
-
Haojian Zhuang authored
The RTC control register should be enabled in the process of initializing. Without this patch, I failed to enable RTC in Hisilicon Hi3620 SoC. The register mapping section in RTC is always read as zero. So I doubt that ST guys may already enable this register in bootloader. So they won't meet this issue. Signed-off-by: Haojian Zhuang <haojian.zhuang@linaro.org> Cc: Srinidhi Kasagar <srinidhi.kasagar@stericsson.com> Cc: Linus Walleij <linus.walleij@linaro.org> Cc: Alessandro Zummo <a.zummo@towertech.it> Cc: <stable@vger.kernel.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
-
Jan Luebbe authored
Previously the alarm event was not propagated into the RTC subsystem. By adding a call to rtc_update_irq, this fixes a timeout problem with the hwclock utility. Signed-off-by: Jan Luebbe <jlu@pengutronix.de> Cc: Alessandro Zummo <a.zummo@towertech.it> Cc: <stable@vger.kernel.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
-
Arnd Bergmann authored
The seccomp filters are currently built for the build host, not for the machine that they are going to run on, but they are also built for with the -m32 flag if the kernel is built for a 32 bit machine, both of which seems rather odd. It broke allyesconfig on my machine, which is x86-64, but building for 32 bit ARM, with this error message: In file included from /usr/include/stdio.h:28:0, from samples/seccomp/bpf-fancy.c:15: /usr/include/features.h:324:26: fatal error: bits/predefs.h: No such file or directory because there are no 32 bit libc headers installed on this machine. We should really be building all the samples for the target machine rather than the build host, but since the infrastructure for that appears to be missing right now, let's be a little bit smarter and not pass the '-m32' flag to the HOSTCC when cross- compiling. Signed-off-by: Arnd Bergmann <arnd@arndb.de> Acked-by: Kees Cook <keescook@chromium.org> Cc: Heiko Carstens <heiko.carstens@de.ibm.com> Cc: James Morris <james.l.morris@oracle.com> Acked-by: Will Drewry <wad@chromium.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
-
Joe Perches authored
Commit 74349bcc ("checkpatch: add support for floating point constants") added an unnecessary match variable that caused tests that used a $Constant or $LvalOrFunc to have one too many matches. This causes problems with usleep_range, min/max and other extended tests. Avoid using match variables in $Float. Avoid using match variables in $Assignment too. Signed-off-by: Joe Perches <joe@perches.com> Cc: Andy Whitcroft <apw@canonical.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
-