summaryrefslogtreecommitdiff
path: root/scripts/stackusage
diff options
context:
space:
mode:
authorArnd Bergmann <arnd@arndb.de>2021-12-22 17:13:21 +0100
committerArnd Bergmann <arnd@arndb.de>2021-12-22 17:13:28 +0100
commite9aff54425f062f2e8758d77e406df4ded00bd85 (patch)
treee86f48a0f2a80bbd67c541b88cc387955a92bd5b /scripts/stackusage
parente5a8aa778d46383c1f901f1fecd6e0db991f8f40 (diff)
parentd0e68d354f345873e15876a7b35be1baaf5e3ec9 (diff)
downloadkernel-e9aff54425f062f2e8758d77e406df4ded00bd85.tar.gz
Merge tag 'arm-soc/for-5.17/devicetree-arm64' of https://github.com/Broadcom/stblinux into arm/dt
This pull request contains Broadcom ARM64-based SoCs Device Tree changes for 5.17, please pull the following: - Rafal adds and documents the Netgear RAXE500 Wireless router based on the BCM4908 SoC. * tag 'arm-soc/for-5.17/devicetree-arm64' of https://github.com/Broadcom/stblinux: arm64: dts: broadcom: bcm4908: add DT for Netgear RAXE500 dt-bindings: arm: bcm: document Netgear RAXE500 binding Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Diffstat (limited to 'scripts/stackusage')
0 files changed, 0 insertions, 0 deletions
5-08-15 18:27:20 -0400'>2015-08-15drm/msm/mdp: Add capabilities to MDP planes (v2)jilai wang MDP planes can be implemented using different type of HW pipes, RGB/VIG/DMA pipes for MDP5 and RGB/VG/DMA pipes for MDP4. Each type of pipe has different HW capabilities such as scaling, color space conversion, decimation... Add a variable in plane data structure to specify the difference of each plane which comes from mdp5_cfg data and use it to differenciate the plane operation. V1: Initial change V2: Fix a typo in mdp4_kms.h Signed-off-by: Jilai Wang <jilaiw@codeaurora.org> Signed-off-by: Rob Clark <robdclark@gmail.com> 2015-08-15drm/msm/mdp5: Allocate CTL0/1 for dual DSI single FLUSHHai Li This change takes advantage of a HW feature that synchronize flush operation on CTL1 to CTL0, to keep dual DSI pipes in sync. Signed-off-by: Hai Li <hali@codeaurora.org> Signed-off-by: Rob Clark <robdclark@gmail.com> 2015-08-15drm/msm/mdp5: Allocate CTL for each display interfaceHai Li In MDP5, CTL contains information of the whole pipeline whose output goes down to a display interface. In various cases, one interface may require 2 CRTCs, but only one CTL. Some interfaces also require to use certain CTLs. Instead of allocating CTL for each active CRTC, this change is to associate a CTL with each interface. Signed-off-by: Hai Li <hali@codeaurora.org> Signed-off-by: Rob Clark <robdclark@gmail.com> 2015-08-15drm/msm: Set different display size limitation on each targetHai Li The maximum output width of one pipeline depends on the LayerMixer's capability. It may be different on each target. Also, MDP5 doesn't have vertical limitation in one frame, as long as the pixel clock can be supported. This change obtains the maximum LM resolution from configuration table and treat it as the whole pipe's limitation for MDP5. The size limit on MDP4 is not changed. Signed-off-by: Hai Li <hali@codeaurora.org> 2015-08-15drm/msm: Add support for msm8x94Stephane Viau This change adds the MDP and HDMI support for msm8x94. Note that HDMI PHY registers are not being accessed anymore from the driver. Signed-off-by: Stephane Viau <sviau@codeaurora.org> [rename compatible s/8x94/8994/ since preference is to not trust the marketing folks who invent chip #'s but instead name things after the lead chip.. we should rename some 80XY to 89XY to standardize on the lead chip but leave that for another patch. Also, update dt bindings doc] Signed-off-by: Rob Clark <robdclark@gmail.com> 2015-08-14drm/msm/mdp5: release SMB (shared memory blocks) in various casesWentao Xu Release all blocks after the pipe is disabled, even when vsync didn't happen in some error cases. Allow requesting SMB multiple times before configuring to hardware, by releasing blocks not programmed to hardware yet for shrinking case. This fixes a potential leak of shared memory pool blocks. Signed-off-by: Wentao Xu <wentaox@codeaurora.org> Tested-by: Archit Taneja <architt@codeaurora.org> Signed-off-by: Rob Clark <robdclark@gmail.com> 2015-06-11drm/msm: Use customized function to wait for atomic commit doneHai Li MDP FLUSH registers could indicate if the previous flush updates has taken effect at vsync boundary. Making use of this H/W feature can catch the vsync that happened between CRTC atomic_flush and *_wait_for_vblanks, to avoid unnecessary wait. This change allows kms CRTCs to use their own *_wait_for_commit_done functions to wait for FLUSH register cleared at vsync, before commit completion. Signed-off-by: Hai Li <hali@codeaurora.org> Signed-off-by: Rob Clark <robdclark@gmail.com> 2015-05-14drm/msm/mdp5: Fix iteration on INTF config arrayStephane Viau The current iteration in get_dsi_id_from_intf() is wrong: instead of iterating until hw_cfg->intf.count, we need to iterate until MDP5_INTF_NUM_MAX here. Let's take the example of msm8x16: hw_cfg->intf.count = 1 intfs[0] = INTF_Disabled intfs[1] = INTF_DSI If we stop iterating once i reaches hw_cfg->intf.count (== 1), we will miss the test for intfs[1]. Actually, this hw_cfg->intf.count entry is quite confusing and is not (or *should not be*) used anywhere else; let's remove it. Signed-off-by: Stephane Viau <sviau@codeaurora.org> 2015-04-01drm/msm/mdp5: Enable DSI connector in msm drm driverHai Li This change adds the support in mdp5 kms driver for single and dual DSI. Dual DSI case depends on the framework API and sequence change to support dual data path. v1: Initial change v2: Address Rob Clark's comment - Separate command mode encoder to a new file mdp5_cmd_encoder.c - Rebase to not depend on msm_drm_sub_dev change Signed-off-by: Hai Li <hali@codeaurora.org> Signed-off-by: Rob Clark <robdclark@gmail.com> 2015-04-01drm/msm/mdp5: Move *_modeset_init out of construct_encoder functionHai Li This change is to make the content in construct_encoder reflect its name. Also, DSI connector may be connected to video mode or command mode encoder, so that 2 different encoders need to be constructed for DSI. Signed-off-by: Hai Li <hali@codeaurora.org> Signed-off-by: Rob Clark <robdclark@gmail.com> 2015-04-01drm/msm/mdp5: Separate MDP5 domain from MDSS domainStephane Viau MDP block is actually contained inside the MDSS block. For some chipsets, the base address of the MDP registers is different from the current (assumed) 0x100 offset. Like CTL and LM blocks, this changes introduce a dynamic offset for the MDP instance, which can be found out at runtime, once the MDSS HW version is read. Signed-off-by: Stephane Viau <sviau@codeaurora.org> Signed-off-by: Rob Clark <robdclark@gmail.com> 2015-04-01drm/msm/mdp5: Make the intf connection in config moduleStephane Viau Up until now, we assume that eDP is tight to intf_0 and HDMI to intf_3. This information shall actually come from the mdp5_cfg module since it can change from one chip to another. v2: rename macro to mdp5_cfg_intf_is_virtual() [pointed by Archit] v3: add sanity check before writing in INTF_TIMING_ENGINE_EN registers Signed-off-by: Stephane Viau <sviau@codeaurora.org> Signed-off-by: Rob Clark <robdclark@gmail.com> 2015-04-01drm/msm/mdp5: Enhance operation mode for pipeline configurationStephane Viau DSI and WB interfaces need a more complex pipeline configuration than the current mdp5_ctl_set_intf(). For example, memory output connections need to be selected for WB. Interface mode (Video vs. Command modes) also need to be configured for DSI. This change takes care of configuring the whole pipeline as far as operation mode goes. DSI and WB interfaces will be added later. v2: rename macro to mdp5_cfg_intf_is_virtual() [pointed by Archit] Signed-off-by: Stephane Viau <sviau@codeaurora.org> [Remove temp bisectability hack -Rob] Signed-off-by: Rob Clark <robdclark@gmail.com> 2015-02-01drm/msm: Add the eDP connector in msm drm driver (V2)Hai Li Modified the hard-coded hdmi connector/encoder implementations in msm drm driver to support both edp and hdmi. V1: Initial change V2: Address Thierry's change Signed-off-by: Hai Li <hali@codeaurora.org> Signed-off-by: Rob Clark <robdclark@gmail.com> 2015-02-01drm/msm: fix fallout of atomic dpms changesRob Clark As a result of atomic DPMS support, the various prepare/commit hooks get called in a way that msm dislikes. We were expecting prepare/commit to bracket a modeset, which is no longer the case. This was needed to hold various extra clk's (such as interface clks) on while we are touching registers, and in the case of mdp4 holding vblank enabled. The most straightforward way to deal with this, since we already have our own atomic_commit(), is to just handle prepare/commit internally to the driver (with some additional vfuncs for mdp4 vs mdp5), and switch everything over to instead use the new enable/disable hooks. It doesn't really change too much, despite the code motion. What used to be in the encoder/crtc dpms() fxns is split out into enable/disable. We should be able to drop our own enable-state tracking, as the atomic helpers should do this for us. But keeping that for the short term for extra debugging as atomic stablizes. Signed-off-by: Rob Clark <robdclark@gmail.com> 2014-12-18drm/msm/mdp5: update irqs on crtc<->encoder link changeRob Clark If crtc <-> encoder linkage changes, we could end up with the CRTC listening for the wrong error or vsync irqs. Generally this problem would correct itself relatively quickly, since we update the global irqmask after dispatching irqs, but to be sure let the CRTC trigger update_irq(). Signed-off-by: Rob Clark <robdclark@gmail.com> 2014-11-21drm/msm/mdp5: don't use void * for opaque typesRob Clark For example, use 'struct mdp5_smp *' everywhere instead of 'void *', but only declare it as 'struct mdp5_smp;' in common headers, so the struct body is still private. The accomplishes the desired modularity while still letting the compiler provide some type checking for us. Signed-off-by: Rob Clark <robdclark@gmail.com> 2014-11-21drm/msm: add multiple CRTC and overlay supportStephane Viau MDP5 currently support one single CRTC with its private pipe. This change allows the configuration of multiple CRTCs with the possibility to attach several public planes to these CRTCs. Signed-off-by: Stephane Viau <sviau@codeaurora.org> Signed-off-by: Rob Clark <robdclark@gmail.com> 2014-11-21drm/msm/mdp5: set rate before enabling clkRob Clark Set a "safe" rate at first, in order to read out the hw revision. And then after set the optimal value. Signed-off-by: Rob Clark <robdclark@gmail.com> 2014-11-21drm/msm/mdp5: introduce mdp5_cfg moduleStephane Viau The hardware configuration modification from a version to another is quite consequent. Introducing a configuration module (mdp5_cfg) may make things more clear and easier to access when a new hardware version comes up. Signed-off-by: Stephane Viau <sviau@codeaurora.org> Signed-off-by: Rob Clark <robdclark@gmail.com> 2014-11-21drm/msm/mdp5: make SMP module dynamically configurableStephane Viau The Shared Memory Pool (SMP) has its own limitation, features and state. Some examples are: - the number of Memory Macro Block (MMB) and their size - the number of lines that can be fetched - the state of MMB currently allocated - the computation of number of blocks required per plane - client IDs ... In order to avoid private data to be overwritten by other modules, let's make these private to the SMP module. Some of these depend on the hardware configuration, let's add them to the mdp5_config struct. In some hw configurations, some MMBs are statically tied to RGB pipes and cannot be re-allocated dynamically. This change introduces the concept of MMB static usage and makes sure that dynamic MMB requests are dimensioned accordingly. A note on passing a pipe pointer, instead of client IDs: Client IDs are SMP-related information. Passing PIPE information to SMP lets SMP module to find out which SMP client(s) are used. This allows the SMP module to access the PIPE pointer, which can be used for FIFO watermark configuration. By the way, even though REG_MDP5_PIPE_REQPRIO_FIFO_WM_* registers are part of the PIPE registers, their functionality is to reflect the behavior of the SMP block. These registers access is now restricted to the SMP module. Signed-off-by: Stephane Viau <sviau@codeaurora.org> Signed-off-by: Rob Clark <robdclark@gmail.com> 2014-11-21drm/msm/mdp5: get the core clock rate from MDP5 configStephane Viau The core clock rate depends on the hw configuration. Once we have read the hardware revision, we can set the core clock to its maximum value. Before then, the clock is set at a rate supported by all MDP5 revisions. Signed-off-by: Stephane Viau <sviau@codeaurora.org> Signed-off-by: Rob Clark <robdclark@gmail.com> 2014-11-21drm/msm/mdp5: use irqdomainsRob Clark For mdp5, the irqs of hdmi/eDP/dsi0/dsi1 blocks get routed through the mdp block. In order to decouple hdmi/eDP/etc, register an irq domain in mdp5. When hdmi/dsi/etc are used with mdp4, they can directly setup their irqs in their DT nodes as normal. When used with mdp5, instead set the mdp device as the interrupt-parent, as in: mdp: qcom,mdss_mdp@fd900000 { compatible = "qcom,mdss_mdp"; interrupt-controller; #interrupt-cells = <1>; ... }; hdmi: qcom,hdmi_tx@fd922100 { compatible = "qcom,hdmi-tx-8074"; interrupt-parent = <&mdp>; interrupts = <8 0>; /* MDP5_HW_INTR_STATUS.INTR_HDMI */ ... }; There is a slight awkwardness, in that we cannot disable child irqs at the mdp level, they can only be cleared in the child block. So you must not use threaded irq handlers in the child. I'm not sure if there is a better way to deal with that. Signed-off-by: Rob Clark <robdclark@gmail.com> 2014-11-16drm/msm/hdmi: refactor bind/initRob Clark Split up hdmi_init() into hdmi_init() (done at hdmi sub-device bind/probe time) and hdmi_modeset_init() done from master driver's modeset_init(). Anything that can fail due to dependencies on other drivers which may be missing or not probed yet should go in hdmi_init(), so that devm error/cleanup paths work properly. Signed-off-by: Rob Clark <robdclark@gmail.com> 2014-08-04drm/msm/mdp5: add support for MDP5 v1.3Stephane Viau MDP5 has several functional blocks (ie: VIG/RGB pipes, LMs, ...). From one revision to another, these blocks' base addresses might change due to the number of instances present in the MDP5 hw. A way of dealing with these offset changes is to introduce dynamic offsets 'per block'. This change adds support for the new revision of MDP5: v1.3. The idea is to define one hw config per MDP version and select either one of them at runtime, after reading the MDP5 version. Once the MDP version is known, 'per block' dynamic offsets are initialized through a global pointer, which is then used for read/write register access. Signed-off-by: Stephane Viau <sviau@codeaurora.org> Signed-off-by: Rob Clark <robdclark@gmail.com> 2014-08-04drm/msm: use upstream iommuRob Clark Downstream kernel IOMMU had a non-standard way of dealing with multiple devices and multiple ports/contexts. We don't need that on upstream kernel, so rip out the crazy. Note that we have to move the pinning of the ringbuffer to after the IOMMU is attached. No idea how that managed to work properly on the downstream kernel. For now, I am leaving the IOMMU port name stuff in place, to simplify things for folks trying to backport latest drm/msm to device kernels. Once we no longer have to care about pre-DT kernels, we can drop this and instead backport upstream IOMMU driver. Signed-off-by: Rob Clark <robdclark@gmail.com> 2014-08-04drm/msm: activate iommu supportStephane Viau This changes activates the iommu support for MDP5, through the platform config structure. Signed-off-by: Stephane Viau <sviau@codeaurora.org> Signed-off-by: Rob Clark <robdclark@gmail.com> 2014-06-22drm/msm: fix IOMMU cleanup for -EPROBE_DEFERStephane Viau If probe fails after IOMMU is attached, we need to detach in order to clean up properly. Before this change, IOMMU faults would occur if the probe failed (-EPROBE_DEFER). Signed-off-by: Stephane Viau <sviau@codeaurora.org> Signed-off-by: Rob Clark <robdclark@gmail.com> 2014-06-02drm/msm/mdp5: fix error return valueRob Clark Signed-off-by: Rob Clark <robdclark@gmail.com> 2014-01-09drm/msm: add mdp5/apq8x74Rob Clark Add support for the new MDP5 display controller block. The mapping between parts of the display controller and KMS is: plane -> PIPE{RGBn,VIGn} \ crtc -> LM (layer mixer) |-> MDP "device" encoder -> INTF / connector -> HDMI/DSI/eDP/etc --> other device(s) Unlike MDP4, it appears we can get by with a single encoder, rather than needing a different implementation for DTV, DSI, etc. (Ie. the register interface is same, just different bases.) Also unlike MDP4, all the IRQs for other blocks (HDMI, DSI, etc) are routed through MDP. And finally, MDP5 has this "Shared Memory Pool" (called "SMP"), from which blocks need to be allocated to the active pipes based on fetch stride. Signed-off-by: Rob Clark <robdclark@gmail.com>