- 16 Apr, 2013 7 commits
-
-
Dave Airlie authored
/usr/lib/gcc/x86_64-linux-gnu/4.7/include/stddef.h:414:9: sparse: preprocessor token offsetof redefined include/linux/stddef.h:17:9: this was the original definition >> drivers/gpu/drm/qxl/qxl_drv.c:49:5: sparse: symbol 'qxl_modeset' was not declared. Should it be static? Reported-by: kbuild test robot. Signed-off-by:Dave Airlie <airlied@redhat.com>
-
git://gitorious.org/linux-omap-dss2/linuxDave Airlie authored
Omapdss patches for 3.10 merge window The biggest changes are: * DSI video mode: automatic clock and timing calculation * Lots of platform data related panel driver cleanups, to prepare for DT * tag 'omapdss-for-3.10' of git://gitorious.org/linux-omap-dss2/linux: (69 commits) drm/omap: add statics to a few structs drm/omap: Fix and improve crtc and overlay manager correlation drm/omap: Take a fb reference in omap_plane_update() drm/omap: Make fixed resolution panels work drm/omap: fix modeset_init if a panel doesn't satisfy omapdrm requirements OMAPDSS: DPI: widen the pck search when using dss fck OMAPDSS: fix dss_fck clock rate rounding omapdss: use devm_clk_get() OMAPDSS: nec-nl8048 panel: Use dev_pm_ops OMAPDSS: DISPC: Revert to older DISPC Smart Standby mechanism for OMAP5 OMAPDSS: DISPC: Configure doublestride for NV12 when using 2D Tiler buffers omapdss: Features: Fix some parameter ranges omapdss: DISPC: add max pixel clock limits for LCD and TV managers OMAPDSS: DSI: Use devm_clk_get() drivers: video: omap2: dss: Use PTR_RET function OMAPDSS: VENC: remove platform_enable/disable calls OMAPDSS: n8x0 panel: remove use of platform_enable/disable OMAPDSS: n8x0 panel: handle gpio data in panel driver OMAPDSS: picodlp panel: remove platform_enable/disable callbacks OMAPDSS: picodlp panel: handle gpio data in panel driver ...
-
Chris Wilson authored
Userspace is free to pass in any command bits it feels like through the ioctl cmd, and for example trinity likes to fuzz those bits to create conflicting commands. So instead of relying upon userspace to pass along the correct IN/OUT flags for the ioctl, use the flags as expected by the kernel. This does have a side-effect that NULL pointers can not be substituted by userspace in place of a struct. This feature was not being used by any driver, but instead exposed all of the command handlers to a user triggerable OOPS. Reported-by:
Tommi Rantala <tt.rantala@gmail.com> Link: http://lkml.kernel.org/r/CA+ydwtpuBvbwxbt-tdgPUvj1EU7itmCHo_2B3w13HkD5+jWKow@mail.gmail.comSigned-off-by:
Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by:
-
Paul Sokolovsky authored
An ifdef in drm.h expects to be compiled with full-fledged Linux toolchain, but it's common to compile kernel with just bare-metal toolchain which doesn't define __linux__. So, also add __KERNEL__ check. [nm@ti.com: port forward to 3.9-rc6 and post to dri devel for feedback as RFC] Signed-off-by:
Paul Sokolovsky <paul.sokolovsky@linaro.org> Signed-off-by:
-
Libin authored
(*->vm_end - *->vm_start) >> PAGE_SHIFT operation is implemented as a inline funcion vma_pages() in linux/mm.h, so using it. Signed-off-by:
Libin <huawei.libin@huawei.com> Signed-off-by:
-
Laurent Pinchart authored
Property blob objects need to be destroyed when cleaning up to avoid memory leaks. Go through the list of all blobs in the drm_mode_config_cleanup() function and destroy them. The drm_mode_config_cleanup() function needs to be moved after the drm_property_destroy_blob() declaration. Move drm_mode_config_init() as well to keep the functions together. Signed-off-by:
Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com> Reviewed-by:
Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by:
-
Dave Airlie authored
Merge tag 'drm-intel-next-2013-04-06' of git://people.freedesktop.org/~danvet/drm-intel into drm-next Daniel writes: Since I expect Linus to open the merge window in about a week I guess this is the last i915 feature pull for 3.10. Highlights: Updated testing tree for -next. Highlights: - Corner case fixes discovered with static analyzers (Damien). - More fixes to combat unclaimed register errors on Haswell (Paulo). - Some small fixes to the gpu turbo code (Rodrigo+Ben), Ben has more fixes for overclocking support pending. - More prep work for fastboot from Chris. - VT-switchless suspend/resume from Jesse. - The prep work of Egbert Eich's hpd irq storm handling. Hopefully we can squeeze in the actual storm handling code for 3.10 ... - More convenience helpers for Imre's sg iterator. Core parts acked by Andrew Morton. - A bit of backlight code cleanup from Jani. - Fixed ilk gpu reset (Jesse). - Reduced color range handling fixes for VLV (Ville). The big item here is though the introduction of pipe_config to properly pre-compute the desired modeset state before touching the hw. Together with some very basic support to read out the current config from the hw and compare the state with the sw tracking. This is all prep work for more reliable fastboot, atomic modesets and other cool features. Stuff converted to the new world includes: - Most simple pipe attributes (reduce color range, pixel multiplier). - Pipe bpp/dither handling. - Some convenience flags like ->has_pch_encoder to simplify the code flow. - (Almost) DP clock handling, had to be reverted since part of a prep patch was lost in rebasing ... Expect a lot of patches for this throughout 3.11, there's tons of work till we have all state properly tracked for fastbooting to woExpect a lot of patches for this throughout 3.11, there's tons of work till we have all state properly tracked for fastbooting to work. For 3.10 I have a bunch of fixes queued up and I plan to send them all out at the end of this week. I need to shuffle patches in my -next queue a bit so that we don't but feature-y stuff in there, too. The main thing I'd like to sneak in is Egbert's hpd irq storm handling, which should be pretty low-risk since all the infrastructure work has landed already. I also have the oops fix pending, but that only mustered review before the w/e and giving how hairy that part of our modeset code is, I want to give it some more testing before forwarding. Note: annarchy.fd.o seems to run out of disk space, so couldn't push the usual for-airlied branch. Tag should work though. Note 2: I've had to do a backmerge since conflicts grew too ugly, but the upstream -rc I've backmerged is already in your drm-next. * tag 'drm-intel-next-2013-04-06' of git://people.freedesktop.org/~danvet/drm-intel: (75 commits) drm/i915: info level for simulated gpu hang dmesg notice drm/i915: revert eDP bpp clamping code changes Revert "drm/i915: fix DP get_hw_state return value" drm/i915: Don't use the HDMI port color range bit on Valleyview drm/i915: Set PIPECONF color range bit on Valleyview drm/i915: extract i9xx_set_pipeconf drm/i915: Add no-lvds quirk for Fujitsu Esprimo Q900 drm/i915: create pipe_config->dpll for clock state drm/i915: hw readout support for ->has_pch_encoders drm/i915: add hw state readout/checking for pipe_config drm/i915: rip out superflous is_dp&is_cpu_edp tracking drm/i915: remove leaky eDP functions drm/i915: track dp target_clock in pipe_config drm/i915: move dp_m_n computation to dp_encoder->compute_config drm/i915: clear up the fdi/dp set_m_n confusion drm/i915: Fix sdvo connector get_hw_state function drm/i915: drop DPFLIPSTAT enables on VLV v3 drm/i915: add Punit read/write routines for VLV v2 drm/i915: panel power sequencing for VLV eDP v2 drm/i915/dp: fix up VLV DP handling v2 ...
-
- 15 Apr, 2013 1 commit
-
-
Tomi Valkeinen authored
-
- 12 Apr, 2013 8 commits
-
-
archit taneja authored
drm_framebuffer_lookup() does a kref_get() for the framebuffer if it finds one corresponding to the fb id passed to it. Use drm_framebuffer_reference() instead for clarity since it's the function used in other places to take a reference. Signed-off-by:
Archit Taneja <archit@ti.com> Reviewed-by:
-
Christopher Harvey authored
Signed-off-by:
Christopher Harvey <charvey@matrox.com> Signed-off-by:
-
Christopher Harvey authored
Signed-off-by:
-
Carsten Emde authored
The 1600x1200 (UXGA) screen resolution was lacking in the set of built-in selectable EDID screen resolutions that can be used to repair misbehaving monitor firmware. This patch adds the related data set and expands the documentation. Signed-off-by:
Carsten Emde <C.Emde@osadl.org> Acked-by:
Paul Menzel <paulepanter@users.sourceforge.net> Signed-off-by:
-
Thierry Reding authored
In order to make it easier to port the code to other operating systems (like the BSDs), relicense the HDMI helpers under the more permissive MIT license. Signed-off-by:
Thierry Reding <thierry.reding@avionic-design.de> Signed-off-by:
-
Dave Airlie authored
QXL is a paravirtual graphics device used by the Spice virtual desktop interface. The drivers uses GEM and TTM to manage memory, the qxl hw fencing however is quite different than normal TTM expects, we have to keep track of a number of non-linear fence ids per bo that we need to have released by the hardware. The releases are freed from a workqueue that wakes up and processes the release ring. releases are suballocated from a BO, there are 3 release categories, drawables, surfaces and cursor cmds. The hw also has 3 rings for commands, cursor and release handling. The hardware also have a surface id tracking mechnaism and the driver encapsulates it completely inside the kernel, userspace never sees the actual hw surface ids. This requires a newer version of the QXL userspace driver, so shouldn't be enabled until that has been placed into your distro of choice. Authors: Dave Airlie, Alon Levy v1.1: fixup some issues in the ioctl interface with padding v1.2: add module device table v1.3: fix nomodeset, fbcon leak, dumb bo create, release ring irq, don't try flush release ring (broken hw), fix -modesetting. v1.4: fbcon cpu usage reduction + suitable accel flags. Signed-off-by:Alon Levy <alevy@redhat.com> Signed-off-by:
-
Dave Airlie authored
qxl wants to use io mapping like i915 gem does, for now just export the symbols so the driver can implement atomic page maps using io mapping. Signed-off-by: -
Alon Levy authored
Signed-off-by:
-
- 11 Apr, 2013 7 commits
-
-
Tomi Valkeinen authored
Some static structs are not marked as static. Add it. Signed-off-by:Tomi Valkeinen <tomi.valkeinen@ti.com>
-
Archit Taneja authored
The omapdrm driver currently takes a config/module arg to figure out the number of crtcs it needs to create. We could create as many crtcs as there are overlay managers in the DSS hardware, but we don't do that because each crtc eats up one DSS overlay, and that reduces the number of planes we can attach to a single crtc. Since the number of crtcs may be lesser than the number of hardware overlay managers, we need to figure out which overlay managers to use for our crtcs. The current approach is to use pipe2chan(), which returns a higher numbered manager for the crtc. The problem with this approach is that it assumes that the overlay managers we choose will connect to the encoders the platform's panels are going to use, this isn't true, an overlay manager connects only to a few outputs/encoders, and choosing any overlay manager for our crtc might lead to a situation where the encoder cannot connect to any of the crtcs we have chosen. For example, an omap5-panda board has just one hdmi output. If num_crtc is set to 1, with the current approach, pipe2chan will pick up the LCD2 overlay manager, which cannot connect to the hdmi encoder at all. The only manager that could have connected to hdmi was the TV overlay manager. Therefore, there is a need to choose our overlay managers keeping in mind the panels we have on that platform. The new approach iterates through all the available panels, creates encoders and connectors for them, and then tries to get a suitable overlay manager to create a crtc which can connect to the encoders. We use the dispc_channel field in omap_dss_output to retrieve the desired overlay manager's channel number, we then check whether the manager had already been assigned to a crtc or not. If it was already assigned to a crtc, we assume that out of all the encoders which intend use this crtc, only one will run at a time. If the overlay manager wan't assigned to a crtc till then, we create a new crtc and link it with the overlay manager. This approach just looks for the best dispc_channel for each encoder. On DSS HW, some encoders can connect to multiple overlay managers. Since we don't try looking for alternate overlay managers, there is a greater possibility that 2 or more encoders end up asking for the same crtc, causing only one encoder to run at a time. Also, this approach isn't the most optimal one, it can do either good or bad depending on the sequence in which the panels/outputs are parsed. The optimal way would be some sort of back tracking approach, where we improve the set of managers we use as we iterate through the list of panels/encoders. That's something left for later. Signed-off-by:
-
Archit Taneja authored
When userspace calls SET_PLANE ioctl, drm core takes a reference of the fb and passes control to the update_plane op defined by the drm driver. In omapdrm, we have a worker thread which queues framebuffers objects received from update_plane and displays them at the appropriate time. It is possible that the framebuffer is destoryed by userspace between the time of calling the ioctl and apply-worker being scheduled. If this happens, the apply-worker holds a pointer to a framebuffer which is already destroyed. Take an extra refernece/unreference of the fb in omap_plane_update() to prevent this from happening. A reference is taken of the fb passed to update_plane(), the previous framebuffer (held by plane->fb) is unreferenced. This will prevent drm from destroying the framebuffer till the time it's unreferenced by the apply-worker. This is in addition to the exisitng reference/unreference in update_pin(), which is taken for the scanout of the plane's current framebuffer, and an unreference the previous framebuffer. Signed-off-by:
Rob Clark <robdclark@gmail.com> Signed-off-by:
-
Archit Taneja authored
The omapdrm driver requires omapdss panel drivers to expose ops like detect, set_timings and check_timings. These can be NULL for fixed panel DPI, DBI, DSI and SDI drivers. At some places, there are no checks to see if the panel driver has these ops or not, and that leads to a crash. The following things are done to make fixed panels work: - The omap_connector's detect function is modified such that it considers panel types which are generally fixed panels as always connected(provided the panel driver doesn't have a detect op). Hence, the connector corresponding to these panels is always in a 'connected' state. - If a panel driver doesn't have a check_timings op, assume that it supports the mode passed to omap_connector_mode_valid(the 'mode_valid' drm helper function) - The function omap_encoder_update shouldn't really do anything for fixed resolution panels, make sure that it calls set_timings only if the panel driver has one. Signed-off-by:
-
Archit Taneja authored
modeset_init iterates through all the registered omapdss devices and has some initial checks to see if the panel has a driver and the required driver ops for it to be usable by omapdrm. The function bails out from modeset_init if a panel doesn't meet the requirements, and stops the registration of the future panels and encoders which come after it, that isn't the correct thing to do, we should go through the rest of the panels. Replace the 'return's with 'continue's. Signed-off-by:
-
Tomi Valkeinen authored
When not using DSI PLL to generate the pixel clock, but DSS FCK, the possible pixel clock rates are rather limited. DSS FCK is currently used on OMAP2 and OMAP3. When using Beagleboard with a monitor that supports high resolutions, the clock rates do not match (at least for me) for the monitor's pixel clocks within the current threshold in the code, which is +/- 1MHz. This patch widens the search up to +/- 15MHz. The search is done in steps, i.e. it first tries to find a rather exact clock, than a bit less exact, etc. so this should not change the cases where a clock was already found. Signed-off-by: -
Tomi Valkeinen authored
DSS func clock is calculated with prate / div * m. However, the current omapdss code calculates it with prate * m / div, which yields a slightly different result when there's a remainder. For example, 432000000 / 14 * 2 = 61714284, but 432000000 * 2 / 14 = 61714285. In addition to that, the clock framework wants the clock rate given with clk_set_rate to be higher than the actual (truncated) end result. So, if prate is 432000000, and div is 14, the real result is 30857142.8571... We need to call clk_set_rate with 30857143, which gives us a clock of 30857142. That's why we need to use DIV_ROUND_UP() when calling clk_set_rate. This patch fixes the clock calculation. Signed-off-by:
-
- 10 Apr, 2013 8 commits
-
-
Archit Taneja authored
Use devm_clk_get() instead of clk_get() for dss, and for outputs hdmi and venc. This reduces code and simplifies error handling. Signed-off-by:
-
Lars-Peter Clausen authored
Use dev_pm_ops instead of the deprecated legacy suspend/resume callbacks. Signed-off-by:
Lars-Peter Clausen <lars@metafoo.de> Signed-off-by:
-
Archit Taneja authored
DISPC on OMAP5 has a more optimised mechanism of asserting Mstandby to achieve more power savings when DISPC is configured in Smart Standby mode. This mechanism leads to underflows when multiple DISPC pipes are enabled. There is a register field which can let us revert to the older mechanism of asserting Mstandby. Configure this field to prevent underflows. Signed-off-by:
-
Archit Taneja authored
When using a DISPC video pipeline to a fetch a NV12 buffer in a 2D container, we need to set set a doublestride bit in the video pipe's ATTRIBUTES register. This is needed because the stride for the UV plane(using a 16 bit Tiler container) is double the stride for the Y plane(using a 8 bit Tiler container) for the 0 or 180 degree views. The ROW_INC register is meant for the Y plane, and the HW will calculate the row increment needed for the UV plane by using double the stride value based on whether this bit is set or not. Set the bit when we are using a 2D Tiler buffer and when rotation is 0 or 180 degrees. The stride value is the same for 90 and 270 degree Tiler views, hence the bit shouldn't be set. Signed-off-by:
-
Archit Taneja authored
Increase the DSS_FCLK and DSI_FCLK max supported frequencies, these come because some frequencies were increased from OMAP5 ES1 to OMAP5 ES2. We support only OMAP5 ES2 in the kernel, so replace the ES1 values with ES2 values. Increase the DSI PLL Fint range, this was previously just copied from the OMAP4 param range struct. Fix the maximum DSS_FCLK on OMAP2, it's 133 Mhz according to the TRM. Signed-off-by:
-
Archit Taneja authored
Each version of OMAP has a limitation on the maximum pixel clock frequency supported by an overlay manager. This limit isn't checked by omapdss. Add dispc feats for lcd and tv managers and check whether the target timings can be supported or not. The pixel clock limitations are actually more complex. They depend on which OPP OMAP is in, and they also depend on which encoder is the manager connected to. The OPP dependence is ignored as DSS forces the PM framework to be on OPP100 when DSS is enabled, and the encoder dependencies are ignored by DISPC for now. These limits should come from the encoder driver. The OMAP2 TRM doesn't mention the maximum pixel clock limit. This value is left as half of DSS_FCLK, as OMAP2 requires the PCD to be atleast 2. Signed-off-by:
-
Sachin Kamat authored
Using devm_clk_get cleans up some code. Signed-off-by:
Sachin Kamat <sachin.kamat@linaro.org> Signed-off-by:
-
Alexandru Gheorghiu authored
Use PTR_RET function instead of IS_ERR and PTR_ERR. Patch found using coccinelle. Signed-off-by:
Alexandru Gheorghiu <gheorghiuandru@gmail.com> Signed-off-by:
-
- 06 Apr, 2013 1 commit
-
-
Daniel Vetter authored
Otherwise running igt will fill your dmesg with hang notices and it's hard to judge from a quick look whether they're expected or not. Signed-off-by:
-
- 05 Apr, 2013 7 commits
-
-
Daniel Vetter authored
The behaviour around handling the eDP bpp value from vbt has been slightly changed in commit 36008365 Author: Daniel Vetter <daniel.vetter@ffwll.ch> Date: Wed Mar 27 00:44:59 2013 +0100 drm/i915: convert DP autodither code to new infrastructure The old behaviour was that we used the plane's bpp (usually 24bpp) for computing the dp link bw, but set up the pipe with the bpp value from vbt if available. This takes the vbt bpp override into account even for the dp link bw configuration. On Paulo's hsw machine this resulted in a slower link clock and a black screen - but the mode actually /should/ fit even with the lower clock. Until we've cleared up simply stay bug-for-bug compatible with the old code. While at it, also restore a debug message lost in: commit 4e53c2e0 Author: Daniel Vetter <daniel.vetter@ffwll.ch> Date: Wed Mar 27 00:44:58 2013 +0100 drm/i915: precompute pipe bpp before touching the hw Cc: Paulo Zanoni <przanoni@gmail.com> Reviewed-by:
Paulo Zanoni <paulo.r.zanoni@intel.com> Tested-by:
-
Daniel Vetter authored
This reverts commit deb18211. It completely breaks the logic, since when we fall through to the end of the function we actually _have_ figured out the correct pipe. Signed-off-by:
-
Ville Syrjälä authored
VLV docs still list the the color range selection bit for the HDMI ports, but for DP ports it has been repurposed. I have no idea whether the HDMI color range selection bit still works on VLV, but since we now have to use the PIPECONF color range bit for DP, we might as well do the same for HDMI. Signed-off-by:
Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by:
Jani Nikula <jani.nikula@intel.com> Signed-off-by:
-
Ville Syrjälä authored
VLV has the color range selection bit in the PIPECONF register. Configure it appropriately. Signed-off-by:
-
Daniel Vetter authored
Prep-patch to improve the bpc handling in a next patch. Signed-off-by: -
Christian Lamparter authored
The "Mobile Sandy Bridge CPUs" in the Fujitsu Esprimo Q900 mini desktop PCs are probably misleading the LVDS detection code in intel_lvds_supported. Nothing is connected to the LVDS ports in these systems. Signed-off-by:
Christian Lamparter <chunkeey@googlemail.com> Cc: stable@vger.kernel.org Signed-off-by:
-
Dave Airlie authored
Merge tag 'drm-intel-next-2013-03-23' of git://people.freedesktop.org/~danvet/drm-intel into drm-next Daniel writes: Highlights: - Imre's for_each_sg_pages rework (now also with the stolen mem backed case fixed with a hack) plus the drm prime sg list coalescing patch from Rahul Sharma. I have some follow-up cleanups pending, already acked by Andrew Morton. - Some prep-work for the crazy no-pch/display-less platform by Ben. - Some vlv patches, by far not all (Jesse et al). - Clean up the HDMI/SDVO #define confusion (Paulo) - gen2-4 vblank fixes from Ville. - Unclaimed register warning fixes for hsw (Paulo). More still to come ... - Complete pageflips which have been stuck in a gpu hang, should prevent stuck gl compositors (Ville). - pm patches for vt-switchless resume (Jesse). Note that the i915 enabling is not (yet) included, that took a bit longer to settle. PM patches are acked by Rafael Wysocki. - Minor fixlets all over from various people. * tag 'drm-intel-next-2013-03-23' of git://people.freedesktop.org/~danvet/drm-intel: (79 commits) drm/i915: Implement WaSwitchSolVfFArbitrationPriority drm/i915: Set the VIC in AVI infoframe for SDVO drm/i915: Kill a strange comment about DPMS functions drm/i915: Correct sandybrige overclocking drm/i915: Introduce GEN7_FEATURES for device info drm/i915: Move num_pipes to intel info drm/i915: fixup pd vs pt confusion in gen6 ppgtt code style nit: Align function parameter continuation properly. drm/i915: VLV doesn't have HDMI on port C drm/i915: DSPFW and BLC regs are in the display offset range drm/i915: set conservative clock gating values on VLV v2 drm/i915: fix WaDisablePSDDualDispatchEnable on VLV v2 drm/i915: add more VLV IDs drm/i915: use VLV DIP routines on VLV v2 drm/i915: add media well to VLV force wake routines v2 drm/i915: don't use plane pipe select on VLV drm: modify pages_to_sg prime helper to create optimized SG table drm/i915: use for_each_sg_page for setting up the gtt ptes drm/i915: create compact dma scatter lists for gem objects drm/i915: handle walking compact dma scatter lists ...
-
- 04 Apr, 2013 1 commit
-
-
Jan Stancek authored
find_vma() can be called by multiple threads with read lock held on mm->mmap_sem and any of them can update mm->mmap_cache. Prevent compiler from re-fetching mm->mmap_cache, because other readers could update it in the meantime: thread 1 thread 2 | find_vma() | find_vma() struct vm_area_struct *vma = NULL; | vma = mm->mmap_cache; | if (!(vma && vma->vm_end > addr | && vma->vm_start <= addr)) { | | mm->mmap_cache = vma; return vma; | ^^ compiler may optimize this | local variable out and re-read | mm->mmap_cache | This issue can be reproduced with gcc-4.8.0-1 on s390x by running mallocstress testcase from LTP, which triggers: kernel BUG at mm/rmap.c:1088! Call Trace: ([<000003d100c57000>] 0x3d100c57000) [<000000000023a1c0>] do_wp_page+0x2fc/0xa88 [<000000000023baae>] handle_pte_fault+0x41a/0xac8 [<000000000023d832>] handle_mm_fault+0x17a/0x268 [<000000000060507a>] do_protection_exception+0x1e2/0x394 [<0000000000603a04>] pgm_check_handler+0x138/0x13c [<000003fffcf1f07a>] 0x3fffcf1f07a Last Breaking-Event-Address: [<000000000024755e>] page_add_new_anon_rmap+0xc2/0x168 Thanks to Jakub Jelinek for his insight on gcc and helping to track this down. Signed-off-by:Jan Stancek <jstancek@redhat.com> Acked-by:
David Rientjes <rientjes@google.com> Signed-off-by:
Hugh Dickins <hughd@google.com> Cc: stable@vger.kernel.org Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org>
-
