Rob Clark [Thu, 27 Jul 2023 21:20:18 +0000 (14:20 -0700)]
drm/msm/adreno: Switch to chip-id for identifying GPU
Since the revision becomes an opaque identifier with future GPUs, move
away from treating different ranges of bits as having a given meaning.
This means that we need to explicitly list different patch revisions in
the device table.
Signed-off-by: Rob Clark <robdclark@chromium.org> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Patchwork: https://patchwork.freedesktop.org/patch/549782/
Rob Clark [Thu, 27 Jul 2023 21:20:16 +0000 (14:20 -0700)]
drm/msm/adreno: Move adreno info to config
Let's just stash it in adreno_platform_config rather than looking it up
in N different places.
Signed-off-by: Rob Clark <robdclark@chromium.org> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Patchwork: https://patchwork.freedesktop.org/patch/549777/
Rob Clark [Thu, 27 Jul 2023 21:20:15 +0000 (14:20 -0700)]
drm/msm/adreno: Add helper for formating chip-id
This is used in a few places, including one that is parsed by userspace
tools. So let's standardize it a bit better.
Signed-off-by: Rob Clark <robdclark@chromium.org> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Patchwork: https://patchwork.freedesktop.org/patch/549774/
Rob Clark [Thu, 27 Jul 2023 21:20:14 +0000 (14:20 -0700)]
drm/msm/adreno: Add adreno family
Sometimes it is useful to know the sub-generation (or "family"). And in
any case, this helps us get away from infering the generation from the
numerical chip-id.
v2: Fix is_a2xx() typo
Signed-off-by: Rob Clark <robdclark@chromium.org> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Patchwork: https://patchwork.freedesktop.org/patch/549773/
Rob Clark [Thu, 27 Jul 2023 21:20:13 +0000 (14:20 -0700)]
drm/msm/adreno: Bring the a630 family together
All of these are derivatives of a630.
Signed-off-by: Rob Clark <robdclark@chromium.org> Reviewed-by: Konrad Dybcio <konrad.dybcio@linaro.org>
Patchwork: https://patchwork.freedesktop.org/patch/549770/
Rob Clark [Thu, 27 Jul 2023 21:20:12 +0000 (14:20 -0700)]
drm/msm/adreno: Move speedbin mapping to device table
This simplifies the code.
v2: Use a table of structs instead of flat uint32_t[]
Signed-off-by: Rob Clark <robdclark@chromium.org> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Patchwork: https://patchwork.freedesktop.org/patch/549769/
Rob Clark [Thu, 27 Jul 2023 21:20:11 +0000 (14:20 -0700)]
drm/msm/adreno: Allow SoC specific gpu device table entries
There are cases where there are differences due to SoC integration.
Such as cache-coherency support, and (in the next patch) e-fuse to
speedbin mappings.
Signed-off-by: Rob Clark <robdclark@chromium.org> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Patchwork: https://patchwork.freedesktop.org/patch/549767/
Rob Clark [Thu, 27 Jul 2023 21:20:10 +0000 (14:20 -0700)]
drm/msm/adreno: Use quirk to identify cached-coherent support
It is better to explicitly list it. With the move to opaque chip-id's
for future devices, we should avoid trying to infer things like
generation from the numerical value.
Signed-off-by: Rob Clark <robdclark@chromium.org> Reviewed-by: Konrad Dybcio <konrad.dybcio@linaro.org> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Patchwork: https://patchwork.freedesktop.org/patch/549765/
Rob Clark [Thu, 27 Jul 2023 21:20:09 +0000 (14:20 -0700)]
drm/msm/adreno: Use quirk identify hw_apriv
Rather than just open coding a list of gpu-id matches.
Signed-off-by: Rob Clark <robdclark@chromium.org> Reviewed-by: Konrad Dybcio <konrad.dybcio@linaro.org> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Patchwork: https://patchwork.freedesktop.org/patch/549764/
Rob Clark [Thu, 27 Jul 2023 21:20:08 +0000 (14:20 -0700)]
drm/msm/adreno: Remove redundant revn param
This just duplicates what is in adreno_info, and can cause confusion if
used before it is set.
Signed-off-by: Rob Clark <robdclark@chromium.org> Reviewed-by: Konrad Dybcio <konrad.dybcio@linaro.org> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Patchwork: https://patchwork.freedesktop.org/patch/549761/
Rob Clark [Thu, 27 Jul 2023 21:20:07 +0000 (14:20 -0700)]
drm/msm/adreno: Remove redundant gmem size param
Even in the ocmem case, the allocated ocmem buffer size should match the
requested size.
v2: Move stray hunk to previous patch, make OCMEM size mismatch an error
condition.
Signed-off-by: Rob Clark <robdclark@chromium.org> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Patchwork: https://patchwork.freedesktop.org/patch/549759/
Rob Clark [Thu, 27 Jul 2023 21:20:06 +0000 (14:20 -0700)]
drm/msm/adreno: Remove GPU name
No real need to have marketing names in the kernel.
Signed-off-by: Rob Clark <robdclark@chromium.org> Reviewed-by: Konrad Dybcio <konrad.dybcio@linaro.org> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Patchwork: https://patchwork.freedesktop.org/patch/549757/
drm/msm/dpu: fix the irq index in dpu_encoder_phys_wb_wait_for_commit_done
Since commit 1e7ac595fa46 ("drm/msm/dpu: pass irq to
dpu_encoder_helper_wait_for_irq()") the
dpu_encoder_phys_wb_wait_for_commit_done expects the IRQ index rather
than the IRQ index in phys_enc->intr table, however writeback got the
older invocation in place. This was unnoticed for several releases, but
now it's time to fix it.
drm/msm/dpu: initialise clk_rate to 0 in _dpu_core_perf_get_core_clk_rate
When removing the core perf tune overrides, I also occasionaly removed the
initialisation of the clk_rate variable. Initialise it to 0 to let max()
correctly calculate the maximum of requested clock rates.
Reported-by: Dan Carpenter <dan.carpenter@linaro.org> Fixes: 6a4bc73915af ("drm/msm/dpu: drop separate dpu_core_perf_tune overrides") Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Reviewed-by: Abhinav Kumar <quic_abhinavk@quicinc.com>
Patchwork: https://patchwork.freedesktop.org/patch/551321/ Link: https://lore.kernel.org/r/20230804094804.36053-1-dmitry.baryshkov@linaro.org
Daniel Vetter [Thu, 3 Aug 2023 20:45:21 +0000 (22:45 +0200)]
drm/msm/mdp5: Don't leak some plane state
Apparently no one noticed that mdp5 plane states leak like a sieve
ever since we introduced plane_state->commit refcount a few years ago
in 21a01abbe32a ("drm/atomic: Fix freeing connector/plane state too
early by tracking commits, v3.")
Fix it by using the right helpers.
Fixes: 21a01abbe32a ("drm/atomic: Fix freeing connector/plane state too early by tracking commits, v3.") Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: Rob Clark <robdclark@gmail.com> Cc: Abhinav Kumar <quic_abhinavk@quicinc.com> Cc: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Cc: linux-arm-msm@vger.kernel.org Cc: freedreno@lists.freedesktop.org Reported-and-tested-by: dorum@noisolation.com Cc: dorum@noisolation.com Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> Reviewed-by: Rob Clark <robdclark@gmail.com> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Reviewed-by: Abhinav Kumar <quic_abhinavk@quicinc.com>
Patchwork: https://patchwork.freedesktop.org/patch/551236/ Link: https://lore.kernel.org/r/20230803204521.928582-1-daniel.vetter@ffwll.ch Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Jessica Zhang [Wed, 2 Aug 2023 17:01:13 +0000 (10:01 -0700)]
drm/msm/dpu: Drop encoder vsync_event
Drop vsync_event and vsync_event_work handlers as they are unnecessary.
In addition drop the dpu_enc_ktime_template event class as it will be
unused after the vsync_event handlers are dropped.
Both struct dpu_dsc_sub_blks instances declare enc subblock length to be
0x100, while the actual length is 0x9c (last register having offset 0x98).
Reduce subblock length to remove the empty register space from being
dumped.
All DSC_BLK_1_2 declarations incorrectly pass 0x29c as the block length.
This includes the common block itself, enc subblocks and some empty
space around. Change that to pass 0x4 instead, the length of common
register block itself.
Jonathan Marek [Wed, 2 Aug 2023 13:48:53 +0000 (09:48 -0400)]
drm/msm/dpu: increase memtype count to 16 for sm8550
sm8550 has 16 vbif clients.
This fixes the extra 2 clients (DMA4/DMA5) not having their memtype
initialized. This fixes DMA4/DMA5 planes not displaying correctly.
Fixes: efcd0107727c ("drm/msm/dpu: add support for SM8550") Signed-off-by: Jonathan Marek <jonathan@marek.ca> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Tested-by: Neil Armstrong <neil.armstrong@linaro.org> # on SM8550-QRD
Patchwork: https://patchwork.freedesktop.org/patch/550968/ Link: https://lore.kernel.org/r/20230802134900.30435-1-jonathan@marek.ca
[DB: fixed the Fixes tag] Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
dpu_core_perf should not make decisions on the maximum possible core
clock rate. Pass the value from dpu_kms_hw_init() and drop handling of
core_clk from dpu_core_perf.c
The dev_pm_opp_set_rate() already contains a call for clk_round_rate for
the passed value. Stop calling it manually from
_dpu_core_perf_get_core_clk_rate(). It is slightly incorrect to call it
this way, as we should round the final calculated clock rate rather than
rounding all the intermediate values.
drm/msm/dpu: drop the dpu_core_perf_crtc_update()'s stop_req param
The stop_req is true only in the dpu_crtc_disable() case, when
crtc->enable has already been set to false. This renders the stop_req
argument useless. Remove it completely.
dpu_core_perf.c contains several multi-line conditions which are hard to
comprehent because of the indentation. Rework the identation of these
conditions to make it easier to understand them.
drm/msm/dpu: drop separate dpu_core_perf_tune overrides
The values in struct dpu_core_perf_tune are fixed per the core perf
mode. Drop the 'tune' values and substitute them with known values when
performing perf management.
Note: min_bus_vote was not used at all, so it is just silently dropped.
Switch to using data from MDSS driver to program the SSPP fetch and UBWC
configuration. As a side-effect, this also swithes the DPU driver from
DPU_HW_UBWC_VER_xx values to the UBWC_x_y enum, which reflects
the hardware register values.
As we are going to use MDSS data for DPU programming, populate missing
MDSS data. The UBWC 1.0 and no UBWC cases do not require MDSS
programming, so skip them.
DPU programming requires knowledge of some of UBWC parameters. This
results in duplication of UBWC data between MDSS and DPU drivers. Export
the required data from MDSS driver.
While reworking interrupts masks, it was easier to keep old
MDP_INTFn_7xxx_INTR and MDP_INTFn_7xxx_TEAR_INTR symbols. Now it is time
to drop them and use unified symbol names.
Declaring the mask of supported interrupts proved to be error-prone. It
is very easy to add a bit with no corresponding backing block or to miss
the INTF TE bit. Replace this with looping over the enabled INTF blocks
to setup the irq mask.
There is no point in having a single enum (and a single array) for both
DPU < 7.0 and DPU >= 7.0 interrupt registers. Instead define a single
enum and two IRQ address arrays.
There is no need to call the DRM_DEV_ERROR() function directly to print
a custom message when handling an error from platform_get_irq() function
as it is going to display an appropriate error message
in case of a failure.
drm/msm/dsi: Reuse QCM2290 14nm DSI PHY configuration for SM6125
SM6125 features only a single PHY (despite a secondary PHY PLL source
being available to the disp_cc_mdss_pclk0_clk_src clock), and downstream
sources for this "trinket" SoC do not define the typical "vcca"
regulator to be available nor used. This, including the register offset
is identical to QCM2290, whose config struct can trivially be reused.
Document availability of the 14nm DSI PHY on SM6125. Note that this
compatible uses the SoC-suffix variant, intead of postfixing an
arbitrary number without the sm/sdm portion. The PHY is not powered by
a vcca regulator like on most SoCs, but by the MX power domain that is
provided via the power-domains property and a single corresponding
required-opps.
SM6125 is identical to SM6375 including the throttle clock that is also
provided to the MDP node downstream. Note that any SoC other than
SM6375 (currently SC7180 and SM6350) has an unconstrained maximum number
of clocks and could either pass or leave out this "throttle" clock.
dt-bindings: display/msm: Remove DSI1 ports from SM6350/SM6375 example
Both SM6350 and SM6375 support only a single DSI link, and don't have a
corresponding dsi1 node in DTS. Their examples should not suggest an
output interface port on the display-controller node to this inexistant
DSI host, with a dsi1_in label reference that doesn't exist in the
example either.
drm/msm/dsi: Drop unused regulators from QCM2290 14nm DSI PHY config
The regulator setup was likely copied from other SoCs by mistake. Just
like SM6125 the DSI PHY on this platform is not getting power from a
regulator but from the MX power domain.
drm/msm/dpu: drop DPU_INTF_DATA_COMPRESS from dpu catalog
Now that all usages of DPU_INTF_DATA_COMPRESS have been replaced
with the dpu core's major revision lets drop DPU_INTF_DATA_COMPRESS
from the catalog completely.
drm/msm/dpu: rename enable_compression() to program_intf_cmd_cfg()
Rename the intf's enable_compression() op to program_intf_cmd_cfg()
and allow it to accept a struct intf_cmd_mode_cfg to program
all the bits at once. This can be re-used by widebus later on as
well as it touches the same register.
changes in v5:
- rename struct intf_cmd_mode_cfg to dpu_hw_intf_cmd_mode_cfg
- remove couple of comments
drm/msm/dpu: rename all hw_intf structs to have dpu_hw prefix
dpu_hw_intf has a few instances of structs which do not have
the dpu_hw prefix. Lets fix this by renaming those structs
and updating the usage of those accordingly.
drm/msm/dpu: use dpu core's major version to enable data compress
Instead of using a feature bit to decide whether to enable data
compress or not for DSC use-cases, use dpu core's major version
instead by assigning the enable_compression op based on the
dpu core's major version.
To make this possible pass the struct dpu_mdss_version to
dpu_hw_intf_init().
This will avoid defining feature bits for every bit level details of
registers.
drm/msm/dpu: re-introduce dpu core revision to the catalog
Introduce the dpu core revision back as an entry to the catalog so that
we can just use dpu revision checks and enable those bits which
should be enabled unconditionally and not controlled by a catalog
and also simplify the changes to do something like:
if (dpu_core_revision > xxxxx && dpu_core_revision < xxxxx)
enable the bit;
changes in v5:
- fix the commit text to remove instances of DPU_HW_VER
Jessica Zhang [Tue, 27 Jun 2023 20:31:45 +0000 (13:31 -0700)]
drm/msm/dsi: Enable BURST_MODE for command mode for DSI 6G v1.3+
During a frame transfer in command mode, there could be frequent
LP11 <-> HS transitions when multiple DCS commands are sent mid-frame or
if the DSI controller is running on slow clock and is throttled. To
minimize frame latency due to these transitions, it is recommended to
send the frame in a single burst.
This feature is supported for DSI 6G 1.3 and above, thus enable burst
mode if supported.
Ryan McCann [Sat, 8 Jul 2023 01:24:45 +0000 (18:24 -0700)]
drm/msm/dpu: Update dev core dump to dump registers of sub-blocks
Currently, the device core dump mechanism does not dump registers of
sub-blocks within the DSPP, SSPP, DSC, and PINGPONG blocks. Edit
dpu_kms_mdp_snapshot function to account for sub-blocks.
Ryan McCann [Sat, 8 Jul 2023 01:24:44 +0000 (18:24 -0700)]
drm/msm/dpu: Refactor printing of main blocks in device core dump
Currently, the names of main blocks are hardcoded into the
msm_disp_snapshot_add_block function rather than using the name that
already exists in the catalog. Change this to take the name directly from
the catalog instead of hardcoding it.
Ryan McCann [Sat, 8 Jul 2023 01:24:43 +0000 (18:24 -0700)]
drm/msm/dpu: Remove redundant prefix/suffix in name of sub-blocks
For a device core dump, the registers of sub-blocks are printed under a
title formatted as <mainBlkName_sblkName>. For example, the csc sub-block
for an SSPP main block "sspp_0" would be printed "sspp_0_sspp_csc0". The
title is clearly redundant due to the duplicate "sspp" and "0" that exist
in both the mainBlkName and sblkName. To eliminate this redundancy, remove
the secondary "sspp" and "0" that exist in the sub-block name by
elimanting the "sspp_" prefix and the concatenation of "num" that results
in the redundant "0" suffix. Remove num parameter altogether from relevant
macros as a consequence of it no longer being used.
Ryan McCann [Sat, 8 Jul 2023 01:24:42 +0000 (18:24 -0700)]
drm/msm/dpu: Define names for unnamed sblks
Some sub-blocks in the hw catalog have not been given a name, so when the
registers from that block are dumped, there is no name to reference.
Define names for relevant sub-blocks to fix this.
Ryan McCann [Sat, 8 Jul 2023 01:24:40 +0000 (18:24 -0700)]
drm/msm: Update dev core dump to not print backwards
Device core dump add block method adds hardware blocks to dumping queue
with stack behavior which causes the hardware blocks to be printed in
reverse order. Change the addition to dumping queue data structure
from "list_add" to "list_add_tail" for FIFO queue behavior.
Fixes: 98659487b845 ("drm/msm: add support to take dpu snapshot") Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Reviewed-by: Abhinav Kumar <quic_abhinavk@quicinc.com> Signed-off-by: Ryan McCann <quic_rmccann@quicinc.com>
Patchwork: https://patchwork.freedesktop.org/patch/546200/ Link: https://lore.kernel.org/r/20230622-devcoredump_patch-v5-1-67e8b66c4723@quicinc.com Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Rob Clark [Mon, 24 Jul 2023 20:30:21 +0000 (13:30 -0700)]
drm/msm: Disallow submit with fence id 0
A fence id of zero is expected to be invalid, and is not removed from
the fence_idr table. If userspace is requesting to specify the fence
id with the FENCE_SN_IN flag, we need to reject a zero fence id value.
Fixes: 17154addc5c1 ("drm/msm: Add MSM_SUBMIT_FENCE_SN_IN") Signed-off-by: Rob Clark <robdclark@chromium.org>
Patchwork: https://patchwork.freedesktop.org/patch/549180/
Rob Clark [Wed, 12 Jul 2023 22:25:23 +0000 (15:25 -0700)]
drm/msm: Fix hw_fence error path cleanup
In an error path where the submit is free'd without the job being run,
the hw_fence pointer is simply a kzalloc'd block of memory. In this
case we should just kfree() it, rather than trying to decrement it's
reference count. Fortunately we can tell that this is the case by
checking for a zero refcount, since if the job was run, the submit would
be holding a reference to the hw_fence.
Fixes: f94e6a51e17c ("drm/msm: Pre-allocate hw_fence") Signed-off-by: Rob Clark <robdclark@chromium.org>
Patchwork: https://patchwork.freedesktop.org/patch/547088/
Rob Clark [Tue, 4 Jul 2023 16:36:40 +0000 (09:36 -0700)]
drm/msm/a690: Remove revn and name
These fields are deprecated. But any userspace new enough to support
a690 also knows how to identify the GPU based on chip-id.
Signed-off-by: Rob Clark <robdclark@chromium.org> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Patchwork: https://patchwork.freedesktop.org/patch/545552/
Rob Clark [Tue, 4 Jul 2023 16:36:39 +0000 (09:36 -0700)]
drm/msm/adreno: Fix warn splat for devices without revn
Recently, a WARN_ON() was introduced to ensure that revn is filled before
adreno_is_aXYZ is called. This however doesn't work very well when revn is
0 by design (such as for A635).
Cc: Konrad Dybcio <konrad.dybcio@linaro.org> Fixes: cc943f43ece7 ("drm/msm/adreno: warn if chip revn is verified before being set") Signed-off-by: Rob Clark <robdclark@chromium.org> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Tested-by: Abhinav Kumar <quic_abhinavk@quicinc.com> # sc7280
Patchwork: https://patchwork.freedesktop.org/patch/545554/
Marijn Suijten [Tue, 27 Jun 2023 20:14:16 +0000 (22:14 +0200)]
drm/msm/dsi: Drop unused regulators from QCM2290 14nm DSI PHY config
The regulator setup was likely copied from other SoCs by mistake. Just
like SM6125 the DSI PHY on this platform is not getting power from a
regulator but from the MX power domain.
Jonathan Marek [Tue, 4 Jul 2023 16:01:04 +0000 (12:01 -0400)]
drm/msm/dpu: add missing flush and fetch bits for DMA4/DMA5 planes
Note that with this, DMA4/DMA5 are still non-functional, but at least
display *something* in modetest instead of nothing or underflow.
Fixes: efcd0107727c ("drm/msm/dpu: add support for SM8550") Signed-off-by: Jonathan Marek <jonathan@marek.ca> Reviewed-by: Abhinav Kumar <quic_abhinavk@quicinc.com> Tested-by: Neil Armstrong <neil.armstrong@linaro.org> # on SM8550-QRD
Patchwork: https://patchwork.freedesktop.org/patch/545548/ Link: https://lore.kernel.org/r/20230704160106.26055-1-jonathan@marek.ca Signed-off-by: Abhinav Kumar <quic_abhinavk@quicinc.com>
drm/msm/dpu: inline INTF_BLK and INTF_BLK_DSI_TE macros
To simplify making changes to the hardware block definitions, expand
corresponding macros. This way making all the changes are more obvious
and visible in the source files.
To simplify making changes to the hardware block definitions, expand
corresponding macros. This way making all the changes are more obvious
and visible in the source files.
To simplify making changes to the hardware block definitions, expand
corresponding macros. This way making all the changes are more obvious
and visible in the source files.
To simplify making changes to the hardware block definitions, expand
corresponding macros. This way making all the changes are more obvious
and visible in the source files.
drm/msm/dpu: inline DSC_BLK and DSC_BLK_1_2 macros
To simplify making changes to the hardware block definitions, expand
corresponding macros. This way making all the changes are more obvious
and visible in the source files.
To simplify making changes to the hardware block definitions, expand
corresponding macros. This way making all the changes are more obvious
and visible in the source files.
To simplify making changes to the hardware block definitions, expand
corresponding macros. This way making all the changes are more obvious
and visible in the source files.
To simplify making changes to the hardware block definitions, expand
corresponding macros. This way making all the changes are more obvious
and visible in the source files.
drm/msm/dpu: correct indentation for CTL definitions
Shift dpu_ctl_cfg contents to correct the indentation of CTL blocks.
This is done in preparation to expanding the rest of hardware block
defines, so that all blocks have similar indentation.
In several catalog entries we did not use existing MSM_DP_CONTROLLER_n
constants. Fill them in. Also use freshly defined MSM_DSI_CONTROLLER_n
for DSI interfaces.