MIPS 32-bit huge page support #2
Closed
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Turn out it is not a DMC bug it is actually a HW one, so this workaround will be needed for current gens, lets update the comment and remove the FIXME. BSpec: 7723 Cc: Dhinakaran Pandiyan <[email protected]> Cc: Rodrigo Vivi <[email protected]> Reviewed-by: Rodrigo Vivi <[email protected]> Signed-off-by: José Roberto de Souza <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
PSR support for VLV and CHV was dropped in commit ce3508f ("drm/i915/psr: Nuke PSR support for VLV and CHV") so no need to keep this registers around. Cc: Dhinakaran Pandiyan <[email protected]> Cc: Rodrigo Vivi <[email protected]> Reviewed-by: Rodrigo Vivi <[email protected]> Signed-off-by: José Roberto de Souza <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
Even when driver is reloaded and hits this scenario the PSR mutex should be initialized, otherwise reading PSR debugfs status will execute mutex_lock() over a mutex that was not initialized. Cc: Dhinakaran Pandiyan <[email protected]> Cc: Rodrigo Vivi <[email protected]> Reviewed-by: Rodrigo Vivi <[email protected]> Signed-off-by: José Roberto de Souza <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
This interlaced mode restriction applies to all gens, not only to Haswell. Also while at it updating the debug message to. Cc: Dhinakaran Pandiyan <[email protected]> Cc: Rodrigo Vivi <[email protected]> Reviewed-by: Rodrigo Vivi <[email protected]> Reviewed-by: Dhinakaran Pandiyan <[email protected]> Signed-off-by: José Roberto de Souza <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
A couple of machines in the farm show quite frequent errors in the powerwells not being released. Either there is an external agent interferring with the powerwells, or the powerwell doesn't quite behave as we anticipate -- either way, the test is not reliable enough to be enabled by default in CI. It has served its immediate purpose in providing coverage as we made tweaks to forcewake, so keep it available for future testing. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=110210 Signed-off-by: Chris Wilson <[email protected]> Cc: Daniele Ceraolo Spurio <[email protected]> Cc: Mika Kuoppala <[email protected]> Reviewed-by: Daniele Ceraolo Spurio <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
Push getting the reference for the encoders' power domains into the encoder get_power_domains() hook instead of doing this from the caller. This way the encoder can store away the corresponding wakerefs. This fixes the DSI encoder disabling, which didn't release these power references it acquired during HW state readout. Note that longtime ownership for the corresponding wakerefs can be thus acquired / released in two ways. Nevertheless there is always only one owner for them: After HW readout (booting/system resume): - encoder->get_power_domains() acquires - encoder->disable*() releases After a modeset (calling intel_atomic_commit()): - encoder->enable*() acquires - encoder->disable*() releases * can be any of the encoder enable/disable hooks. v2: - Check that the DSI io_wakerefs are unset both during encoder HW readout and enabling. (Chris) Fixes: 0e6e0be ("drm/i915: Markup paired operations on display power domains") Cc: Vandita Kulkarni <[email protected]> Cc: Chris Wilson <[email protected]> Signed-off-by: Imre Deak <[email protected]> Reviewed-by: Chris Wilson <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] (cherry picked from commit 3a52fb7) Signed-off-by: Rodrigo Vivi <[email protected]>
The call to of_parse_phandle returns a node pointer with refcount incremented thus it must be explicitly decremented after the last usage. Detected by coccinelle with the following warnings: drivers/gpu/drm/mediatek/mtk_hdmi.c:1521:2-8: ERROR: missing of_node_put; acquired a node pointer with refcount incremented on line 1509, but without a corresponding object release within this function. drivers/gpu/drm/mediatek/mtk_hdmi.c:1524:1-7: ERROR: missing of_node_put; acquired a node pointer with refcount incremented on line 1509, but without a corresponding object release within this function. Signed-off-by: Wen Yang <[email protected]> Cc: CK Hu <[email protected]> Cc: Philipp Zabel <[email protected]> Cc: David Airlie <[email protected]> Cc: Daniel Vetter <[email protected]> Cc: Matthias Brugger <[email protected]> Cc: [email protected] Cc: [email protected] Cc: [email protected] Cc: [email protected] Signed-off-by: CK Hu <[email protected]>
Add the bindings for the Bifrost family of ARM Mali GPUs. The Bifrost GPU architecture is similar to the Midgard family, but with a different Shader Core & Execution Engine structures. Bindings are based on the Midgard family bindings, but the inner architectural changes makes it a separate family needing separate bindings. The Bifrost GPUs are present in a number of recent SoCs, like the Amlogic G12A Family, and many other vendors. The Amlogic vendor specific compatible is added to handle the specific IP integration differences and dependencies. Signed-off-by: Neil Armstrong <[email protected]> Reviewed-by: Rob Herring <[email protected]> [narmstrong: fixed small typo in compatible description] Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
Circumvent the dance we currently perform to find the preempt_client and lookup its HW context for this engine, as we know we have already pinned the preempt_context on the engine. Signed-off-by: Chris Wilson <[email protected]> Reviewed-by: Tvrtko Ursulin <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
The Amlogic G12A VPU is very similar to the Amlogic GXM VPU but with : - an enhanced plane blender, with up to 3 OSD planes - support for AFBC 1.2 decoder (for Bifrost GPU) - support display mode up to 4k60@75Hz Signed-off-by: Neil Armstrong <[email protected]> Reviewed-by: Rob Herring <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
… ports The Amlogic G12A SoC has a slighly modified DW-HDMI Glue with support for HDMI 2.1 and a different DW-HDMI register access. Signed-off-by: Neil Armstrong <[email protected]> Reviewed-by: Rob Herring <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
Due to a clerical error,there is one zero less for 12800000. Fix it for 128000000 Fixes: 0fc721b ("drm/mediatek: add hdmi driver for MT2701 and MT7623") Signed-off-by: Wangyan Wang <[email protected]> Signed-off-by: CK Hu <[email protected]>
On Amlogic G12A SoC, the 2,97GHz PLL frequency is not stable enough to provide a correct 297MHz pixel clock, so switch the PLL base frequency with a /2 OD when the 297MHz pixel clock is requested. This solves the issue on G12A and also works fine on GXBB, GXL & GXM. Signed-off-by: Neil Armstrong <[email protected]> Tested-by: Jerome Brunet <[email protected]> Reviewed-by: Jerome Brunet <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
This patch adds the new VPU registers added since the Amlogic GXM SoCs. Signed-off-by: Neil Armstrong <[email protected]> Tested-by: Jerome Brunet <[email protected]> Reviewed-by: Jerome Brunet <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
Amlogic G12A needs a different VPP setup code, handle it here. Signed-off-by: Neil Armstrong <[email protected]> Tested-by: Jerome Brunet <[email protected]> Reviewed-by: Jerome Brunet <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
Amlogic G12A SoC needs a different VIU setup code, handle it. Signed-off-by: Neil Armstrong <[email protected]> Tested-by: Jerome Brunet <[email protected]> Reviewed-by: Jerome Brunet <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
Amlogic G12A SoC supports now up to 3 OSD planes (1 more than the previous SoCs) and a brand new OSD plane blender module. This patch uses the same OSD1 plane for G12A, using the exact same scaler and OSD1 setup registers, except using the new blender register to disable the plane. Signed-off-by: Neil Armstrong <[email protected]> [narmstrong: fixed typo in commit log] Tested-by: Jerome Brunet <[email protected]> Reviewed-by: Jerome Brunet <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
Amlogic G12A SoC supports the same set of Video Planes, but now are handled by the new OSD plane blender module. This patch uses the same VD1 plane for G12A, using the exact same scaler and VD1 setup registers, except using the new blender register to disable the plane. Signed-off-by: Neil Armstrong <[email protected]> [narmstrong: fix typo in commit log] Tested-by: Jerome Brunet <[email protected]> Reviewed-by: Jerome Brunet <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
This patch adds support for the new OSD+VD Plane blending module in the CRTC code by adding the G12A code to manage the blending module and setting the right OSD1 & VD1 plane registers. Signed-off-by: Neil Armstrong <[email protected]> Tested-by: Jerome Brunet <[email protected]> Reviewed-by: Jerome Brunet <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
The Meson G12A SoCs uses the exact same CVBS encoder except a simple CVBS DAC register offset and settings delta. Signed-off-by: Neil Armstrong <[email protected]> [narmstrong: fixed subject typo] Tested-by: Jerome Brunet <[email protected]> Reviewed-by: Jerome Brunet <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
While switching to the Common Clock Framework is still Work In Progress, this patch adds the corresponding G12A HDMI PLL setup to be on-par with the other SoCs support. The G12A has only a single tweak about the high frequency setup, where the HDMI PLL needs a specific setup to handle correctly the 5.94GHz DCO frequency. Apart that, it handls ecorrectly all the other HDMI frequencies and can achieve even better DMT clock frequency precision with the larger fractional dividier width. Signed-off-by: Neil Armstrong <[email protected]> Tested-by: Jerome Brunet <[email protected]> Reviewed-by: Jerome Brunet <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
Finally add the Amlogic G12A SoC compatible for the VPU driver. Signed-off-by: Neil Armstrong <[email protected]> Tested-by: Jerome Brunet <[email protected]> Reviewed-by: Jerome Brunet <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
The Amlogic G12A embeds the same Synopsys DW-HDMI Controller, but with : - a "backport" of the HDR signaling registers from more recent DW-HDMI controllers, this will need a tweak since it's not normally present on this version of the DW-HDMI controller - A direct mapping of TOP and DW-HDMI registers instead of an internal bus accessed using read/write registers - Support for RX-SENSE, but not yet implemented - Support for HDMI 2.1 Dynamic HDR, but not yet implemented - Different registers mapping for the HDMI PHY setup This patchs adds support for these changes while providing exact same support as the previous GXBB, GXL & GXM SoCs. Signed-off-by: Neil Armstrong <[email protected]> Tested-by: Jerome Brunet <[email protected]> Reviewed-by: Jerome Brunet <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
Recalculate the rate of this clock, by querying hardware to make implementation of recalc_rate() to match the definition. Signed-off-by: Wangyan Wang <[email protected]> Signed-off-by: CK Hu <[email protected]>
This is the first step to make MT2701 hdmi stable. The parent rate of hdmi phy had set by DPI driver. We should not set or change the parent rate of MT2701 hdmi phy, as a result we should remove the flags of "CLK_SET_RATE_PARENT" from the clock of MT2701 hdmi phy. Signed-off-by: Wangyan Wang <[email protected]> Signed-off-by: CK Hu <[email protected]>
This is the second step to make MT2701 HDMI stable. The factor depends on the divider of DPI in MT2701, therefore, we should fix this factor to the right and new one. Test: search ok Signed-off-by: Wangyan Wang <[email protected]> Signed-off-by: CK Hu <[email protected]>
This is the third step to make MT2701 HDMI stable. We should not change the rate of parent for hdmi phy when doing round_rate for this clock. The parent clock of hdmi phy must be the same as it. We change it when doing set_rate only. Signed-off-by: Wangyan Wang <[email protected]> Signed-off-by: CK Hu <[email protected]>
This is essentially a revert of the commit a7588c8 ("ALSA: timer: Check ack_list emptiness instead of bit flag"). The intended change by the commit turns out to be insufficient, as snd_timer_close*() always calls snd_timer_stop() that deletes the ack_list beforehand. In theory, we can change the behavior of snd_timer_stop() to sync the pending ack_list, but this will become a deadlock for the callback like sequencer that calls again snd_timer_stop() from itself. So, reverting the change is a more straightforward solution. Fixes: a7588c8 ("ALSA: timer: Check ack_list emptiness instead of bit flag") Reported-by: [email protected] Signed-off-by: Takashi Iwai <[email protected]>
Current implementation does not support MMU-less plarforms. Suggested-by: Randy Dunlap <[email protected]> Reviewed-by: Neil Armstrong <[email protected]> Fixes: a1d2a63 ("drm/lima: driver for ARM Mali4xx GPUs") Signed-off-by: Qiang Yu <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
To prevent build fail on some platform which does not have it in the include file chain. Reviewed-by: Neil Armstrong <[email protected]> Suggested-by: Randy Dunlap <[email protected]> Fixes: a1d2a63 ("drm/lima: driver for ARM Mali4xx GPUs") Signed-off-by: Qiang Yu <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
I forked your OpenDingux/linux repo and rebased these commits on your jz-5.1-retromini branch. Please consider this branch the most up-to-date location for now:
https://github.com/senquack/linux-1/commits/for-upstream-hugetlb-sq
I revised things a bit since we last spoke.. now huge pages are disallowed not only for EVA,XPA addressing, but also when proprietary Alchemy/Netlogic CPU extended addressing is in use.
I've left it up to you to decide to modify your arch/mips/config/ defconfig(s) to contain one or both of these options:
CONFIG_HUGETLBFS=y
CONFIG_TRANSPARENT_HUGEPAGE=y
I am working on libhugetlbfs right now, not sure how soon I'll be done though :(