[jira] [Commented] (JCRVLT-756) Sub packages contained in "all" package no longer installed
[ https://issues.apache.org/jira/browse/JCRVLT-756?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17852838#comment-17852838 ] Konrad Windszus commented on JCRVLT-756: This points more to a problem in AEM than a general one in FileVault then. I would recommend involving Adobe support. > Sub packages contained in "all" package no longer installed > --- > > Key: JCRVLT-756 > URL: https://issues.apache.org/jira/browse/JCRVLT-756 > Project: Jackrabbit FileVault > Issue Type: Bug > Components: vlt >Affects Versions: 3.7.4 >Reporter: Stefan Seifert >Priority: Critical > Attachments: > vault_installer_2024.5.16461.20240524T172309Z-240500.log, > vault_installer_2024.5.16544.20240530T165853Z-240500.log > > > i noticed that with latest vlt 3.7.3-SNAPSHOT it's not longer possible to > install a package that includes sub packages - the sub packages are > extracted, but not installed themselves properly. > it seems the functionality broke with one of the recent commits: > * it works fine with 3.7.3-T20240308111857-81fa88f1 > * but does no longer work with 3.7.3-T20240514105118-694f6aea > * differences between those two revs: > [https://github.com/apache/jackrabbit-filevault/compare/81fa88f1d7af07e77871e2c0bb03515107f18d74...694f6aeac27d9b6656647e968636fd9f5bc99238] > i tested with AEMaaCS SDK in two different versions - steps to reproduce the > problem: > * setup a local AEMaaCS SDK instance > * upload package > [https://github.com/adobe/aem-guides-wknd/releases/download/aem-guides-wknd-3.2.0/aem-guides-wknd.all-3.2.0.zip] > * install this package > * expected behavior: the package included the 5 subpackages should be > extracted in packaged manager and all of them should be installed > this works with AEMaaCS SDK 2024.5.16461.20240524T172309Z-240500 which > includes 3.7.3-T20240308111857-81fa88f1 > it does no longer work with AEMaaCS SDK 2024.5.16544.20240530T165853Z-240500 > which includes 3.7.3-T20240514105118-694f6aea > i've attached log files with the package install procedure with both those > versions. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (JCRVLT-756) Sub packages contained in "all" package no longer installed
[ https://issues.apache.org/jira/browse/JCRVLT-756?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17852772#comment-17852772 ] Konrad Windszus commented on JCRVLT-756: [~sseifert] Any chance you can come up with a failing IT? > Sub packages contained in "all" package no longer installed > --- > > Key: JCRVLT-756 > URL: https://issues.apache.org/jira/browse/JCRVLT-756 > Project: Jackrabbit FileVault > Issue Type: Bug > Components: vlt >Affects Versions: 3.7.4 >Reporter: Stefan Seifert >Priority: Critical > Attachments: > vault_installer_2024.5.16461.20240524T172309Z-240500.log, > vault_installer_2024.5.16544.20240530T165853Z-240500.log > > > i noticed that with latest vlt 3.7.3-SNAPSHOT it's not longer possible to > install a package that includes sub packages - the sub packages are > extracted, but not installed themselves properly. > it seems the functionality broke with one of the recent commits: > * it works fine with 3.7.3-T20240308111857-81fa88f1 > * but does no longer work with 3.7.3-T20240514105118-694f6aea > * differences between those two revs: > [https://github.com/apache/jackrabbit-filevault/compare/81fa88f1d7af07e77871e2c0bb03515107f18d74...694f6aeac27d9b6656647e968636fd9f5bc99238] > i tested with AEMaaCS SDK in two different versions - steps to reproduce the > problem: > * setup a local AEMaaCS SDK instance > * upload package > [https://github.com/adobe/aem-guides-wknd/releases/download/aem-guides-wknd-3.2.0/aem-guides-wknd.all-3.2.0.zip] > * install this package > * expected behavior: the package included the 5 subpackages should be > extracted in packaged manager and all of them should be installed > this works with AEMaaCS SDK 2024.5.16461.20240524T172309Z-240500 which > includes 3.7.3-T20240308111857-81fa88f1 > it does no longer work with AEMaaCS SDK 2024.5.16544.20240530T165853Z-240500 > which includes 3.7.3-T20240514105118-694f6aea > i've attached log files with the package install procedure with both those > versions. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (SLING-12350) Make the HTL Compiler build work on more recent JDKs
[ https://issues.apache.org/jira/browse/SLING-12350?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Konrad Windszus resolved SLING-12350. - Assignee: Konrad Windszus Resolution: Fixed PR is applied in https://github.com/apache/sling-org-apache-sling-scripting-sightly-compiler/commit/69de23f3eb41c02fb5d2bd47e869617c3c34ee57. [~Csaba Varga] Thanks a lot for the contribution. > Make the HTL Compiler build work on more recent JDKs > > > Key: SLING-12350 > URL: https://issues.apache.org/jira/browse/SLING-12350 > Project: Sling > Issue Type: Improvement > Components: HTL >Affects Versions: Scripting HTL Compiler 1.2.14-1.4.0 >Reporter: Csaba Varga >Assignee: Konrad Windszus >Priority: Minor > Fix For: Scripting HTL Compiler 1.2.16-1.4.0 > > > The current build of the HTL compiler artifact fails on JDK 17 and later > because it tries to access standard library internals via reflection. It > should be updated so that it can be built on recent JDKs. -- This message was sent by Atlassian Jira (v8.20.10#820010)
Re: [PATCH] drm/msm/adreno: De-spaghettify the use of memory barriers
On 4.06.2024 4:40 PM, Will Deacon wrote: > On Thu, May 16, 2024 at 01:55:26PM -0500, Andrew Halaney wrote: >> On Thu, May 16, 2024 at 08:20:05PM GMT, Akhil P Oommen wrote: >>> On Thu, May 16, 2024 at 08:15:34AM -0500, Andrew Halaney wrote: >>>> If I understand correctly, you don't need any memory barrier. >>>> writel()/readl()'s are ordered to the same endpoint. That goes for all >>>> the reordering/barrier comments mentioned below too. >>>> >>>> device-io.rst: >>>> >>>> The read and write functions are defined to be ordered. That is the >>>> compiler is not permitted to reorder the I/O sequence. When the >>>> ordering >>>> can be compiler optimised, you can use __readb() and friends to >>>> indicate the relaxed ordering. Use this with care. >>>> >>>> memory-barriers.txt: >>>> >>>> (*) readX(), writeX(): >>>> >>>>The readX() and writeX() MMIO accessors take a pointer to the >>>>peripheral being accessed as an __iomem * parameter. For pointers >>>>mapped with the default I/O attributes (e.g. those returned by >>>>ioremap()), the ordering guarantees are as follows: >>>> >>>>1. All readX() and writeX() accesses to the same peripheral are >>>> ordered >>>> with respect to each other. This ensures that MMIO register >>>> accesses >>>> by the same CPU thread to a particular device will arrive in >>>> program >>>> order. >>>> >>> >>> In arm64, a writel followed by readl translates to roughly the following >>> sequence: dmb_wmb(), __raw_writel(), __raw_readl(), dmb_rmb(). I am not >>> sure what is stopping compiler from reordering __raw_writel() and >>> __raw_readl() >>> above? I am assuming iomem cookie is ignored during compilation. >> >> It seems to me that is due to some usage of volatile there in >> __raw_writel() etc, but to be honest after reading about volatile and >> some threads from gcc mailing lists, I don't have a confident answer :) >> >>> >>> Added Will to this thread if he can throw some light on this. >> >> Hopefully Will can school us. > > The ordering in this case is ensured by the memory attributes used for > ioremap(). When an MMIO region is mapped using Device-nGnRE attributes > (as it the case for ioremap()), the "nR" part means "no reordering", so > readX() and writeX() to that region are ordered wrt each other. > > Note that guarantee _doesn't_ apply to other flavours of ioremap(), so > e.g. ioremap_wc() won't give you the ordering. > > Hope that helps, Just to make sure I'm following, would mapping things as nGnRnE effectively get rid of write buffering, perhaps being a way of debugging whether that in particular is causing issues (at the cost of speed)? Konrad
Re: [PATCH] drm/msm/adreno: De-spaghettify the use of memory barriers
On 4.06.2024 4:40 PM, Will Deacon wrote: > On Thu, May 16, 2024 at 01:55:26PM -0500, Andrew Halaney wrote: >> On Thu, May 16, 2024 at 08:20:05PM GMT, Akhil P Oommen wrote: >>> On Thu, May 16, 2024 at 08:15:34AM -0500, Andrew Halaney wrote: >>>> If I understand correctly, you don't need any memory barrier. >>>> writel()/readl()'s are ordered to the same endpoint. That goes for all >>>> the reordering/barrier comments mentioned below too. >>>> >>>> device-io.rst: >>>> >>>> The read and write functions are defined to be ordered. That is the >>>> compiler is not permitted to reorder the I/O sequence. When the >>>> ordering >>>> can be compiler optimised, you can use __readb() and friends to >>>> indicate the relaxed ordering. Use this with care. >>>> >>>> memory-barriers.txt: >>>> >>>> (*) readX(), writeX(): >>>> >>>>The readX() and writeX() MMIO accessors take a pointer to the >>>>peripheral being accessed as an __iomem * parameter. For pointers >>>>mapped with the default I/O attributes (e.g. those returned by >>>>ioremap()), the ordering guarantees are as follows: >>>> >>>>1. All readX() and writeX() accesses to the same peripheral are >>>> ordered >>>> with respect to each other. This ensures that MMIO register >>>> accesses >>>> by the same CPU thread to a particular device will arrive in >>>> program >>>> order. >>>> >>> >>> In arm64, a writel followed by readl translates to roughly the following >>> sequence: dmb_wmb(), __raw_writel(), __raw_readl(), dmb_rmb(). I am not >>> sure what is stopping compiler from reordering __raw_writel() and >>> __raw_readl() >>> above? I am assuming iomem cookie is ignored during compilation. >> >> It seems to me that is due to some usage of volatile there in >> __raw_writel() etc, but to be honest after reading about volatile and >> some threads from gcc mailing lists, I don't have a confident answer :) >> >>> >>> Added Will to this thread if he can throw some light on this. >> >> Hopefully Will can school us. > > The ordering in this case is ensured by the memory attributes used for > ioremap(). When an MMIO region is mapped using Device-nGnRE attributes > (as it the case for ioremap()), the "nR" part means "no reordering", so > readX() and writeX() to that region are ordered wrt each other. > > Note that guarantee _doesn't_ apply to other flavours of ioremap(), so > e.g. ioremap_wc() won't give you the ordering. > > Hope that helps, Just to make sure I'm following, would mapping things as nGnRnE effectively get rid of write buffering, perhaps being a way of debugging whether that in particular is causing issues (at the cost of speed)? Konrad
[PATCH] drm/msm/a6xx: Fix A702 UBWC mode
UBWC_MODE is a one-bit-wide field, so a value of 2 is obviously bogus.
Replace it with the correct value (0).
Fixes: 18397519cb62 ("drm/msm/adreno: Add A702 support")
Reported-by: Connor Abbott
Closes:
https://lore.kernel.org/linux-arm-msm/CACu1E7FTN=kwaDJMNiTmFspALzj2+Q-nvsN5ugi=vz4rdug...@mail.gmail.com/
Signed-off-by: Konrad Dybcio
---
drivers/gpu/drm/msm/adreno/a6xx_gpu.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
b/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
index 973872ad0474..5383aff84830 100644
--- a/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
+++ b/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
@@ -1409,7 +1409,7 @@ static void a6xx_calc_ubwc_config(struct adreno_gpu *gpu)
if (adreno_is_a702(gpu)) {
gpu->ubwc_config.highest_bank_bit = 14;
gpu->ubwc_config.min_acc_len = 1;
- gpu->ubwc_config.ubwc_mode = 2;
+ gpu->ubwc_config.ubwc_mode = 0;
}
}
---
base-commit: ee78a17615ad0cfdbbc27182b1047cd36c9d4d5f
change-id: 20240606-topic-a702_ubwcmode-dcc5fde0f330
Best regards,
--
Konrad Dybcio
[PATCH] drm/msm/a6xx: Fix A702 UBWC mode
UBWC_MODE is a one-bit-wide field, so a value of 2 is obviously bogus.
Replace it with the correct value (0).
Fixes: 18397519cb62 ("drm/msm/adreno: Add A702 support")
Reported-by: Connor Abbott
Closes:
https://lore.kernel.org/linux-arm-msm/CACu1E7FTN=kwaDJMNiTmFspALzj2+Q-nvsN5ugi=vz4rdug...@mail.gmail.com/
Signed-off-by: Konrad Dybcio
---
drivers/gpu/drm/msm/adreno/a6xx_gpu.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
b/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
index 973872ad0474..5383aff84830 100644
--- a/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
+++ b/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
@@ -1409,7 +1409,7 @@ static void a6xx_calc_ubwc_config(struct adreno_gpu *gpu)
if (adreno_is_a702(gpu)) {
gpu->ubwc_config.highest_bank_bit = 14;
gpu->ubwc_config.min_acc_len = 1;
- gpu->ubwc_config.ubwc_mode = 2;
+ gpu->ubwc_config.ubwc_mode = 0;
}
}
---
base-commit: ee78a17615ad0cfdbbc27182b1047cd36c9d4d5f
change-id: 20240606-topic-a702_ubwcmode-dcc5fde0f330
Best regards,
--
Konrad Dybcio
Re: [PATCH] arm64: dts: qcom: qcm6490-fairphone-fp5: Use .mbn firmware for IPA
On 6.06.2024 11:09 AM, Luca Weiss wrote: > Specify the file name for the squashed/non-split firmware with the .mbn > extension instead of the split .mdt. The kernel can load both but the > squashed version is preferred in dts nowadays. > > Signed-off-by: Luca Weiss > --- Reviewed-by: Konrad Dybcio Konrad
Re: [PATCH v2 5/7] drm/msm/adreno: Add A702 support
On 23.05.2024 2:14 PM, Connor Abbott wrote:
> On Fri, Feb 23, 2024 at 9:28 PM Konrad Dybcio
> wrote:
>>
>> The A702 is a weird mix of 600 and 700 series.. Perhaps even a
>> testing ground for some A7xx features with good ol' A6xx silicon.
>> It's basically A610 that's been beefed up with some new registers
>> and hw features (like APRIV!), that was then cut back in size,
>> memory bus and some other ways.
>>
>> Add support for it, tested with QCM2290 / RB1.
>>
>> Signed-off-by: Konrad Dybcio
>> ---
[...]
>> +
>> + if (adreno_is_a702(gpu)) {
>> + gpu->ubwc_config.highest_bank_bit = 14;
>> + gpu->ubwc_config.min_acc_len = 1;
>> + gpu->ubwc_config.ubwc_mode = 2;
>
> I just noticed, but this is wrong. ubwc_mode is a 1 bit field and what
> this is actually doing is overwriting hbb_lo, making the highest bank
> bit 15 instead of 14.
You're right, this should be a 0. Thanks!
Konrad
Re: [PATCH v2 5/7] drm/msm/adreno: Add A702 support
On 23.05.2024 2:14 PM, Connor Abbott wrote:
> On Fri, Feb 23, 2024 at 9:28 PM Konrad Dybcio
> wrote:
>>
>> The A702 is a weird mix of 600 and 700 series.. Perhaps even a
>> testing ground for some A7xx features with good ol' A6xx silicon.
>> It's basically A610 that's been beefed up with some new registers
>> and hw features (like APRIV!), that was then cut back in size,
>> memory bus and some other ways.
>>
>> Add support for it, tested with QCM2290 / RB1.
>>
>> Signed-off-by: Konrad Dybcio
>> ---
[...]
>> +
>> + if (adreno_is_a702(gpu)) {
>> + gpu->ubwc_config.highest_bank_bit = 14;
>> + gpu->ubwc_config.min_acc_len = 1;
>> + gpu->ubwc_config.ubwc_mode = 2;
>
> I just noticed, but this is wrong. ubwc_mode is a 1 bit field and what
> this is actually doing is overwriting hbb_lo, making the highest bank
> bit 15 instead of 14.
You're right, this should be a 0. Thanks!
Konrad
[PATCH v2 3/7] drm/msm/adreno: Implement SMEM-based speed bin
On recent (SM8550+) Snapdragon platforms, the GPU speed bin data is
abstracted through SMEM, instead of being directly available in a fuse.
Add support for SMEM-based speed binning, which includes getting
"feature code" and "product code" from said source and parsing them
to form something that lets us match OPPs against.
Due to the product code being ignored in the context of Adreno on
production parts (as of SM8650), hardcode it to SOCINFO_PC_UNKNOWN.
Signed-off-by: Konrad Dybcio
---
drivers/gpu/drm/msm/adreno/a6xx_gpu.c | 8 +++---
drivers/gpu/drm/msm/adreno/adreno_device.c | 2 ++
drivers/gpu/drm/msm/adreno/adreno_gpu.c| 41 +++---
drivers/gpu/drm/msm/adreno/adreno_gpu.h| 12 ++---
4 files changed, 53 insertions(+), 10 deletions(-)
diff --git a/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
b/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
index 973872ad0474..3f84417ff027 100644
--- a/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
+++ b/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
@@ -2894,13 +2894,15 @@ static u32 fuse_to_supp_hw(const struct adreno_info
*info, u32 fuse)
return UINT_MAX;
}
-static int a6xx_set_supported_hw(struct device *dev, const struct adreno_info
*info)
+static int a6xx_set_supported_hw(struct adreno_gpu *adreno_gpu,
+struct device *dev,
+const struct adreno_info *info)
{
u32 supp_hw;
u32 speedbin;
int ret;
- ret = adreno_read_speedbin(dev, );
+ ret = adreno_read_speedbin(adreno_gpu, dev, );
/*
* -ENOENT means that the platform doesn't support speedbin which is
* fine
@@ -3060,7 +3062,7 @@ struct msm_gpu *a6xx_gpu_init(struct drm_device *dev)
a6xx_llc_slices_init(pdev, a6xx_gpu, is_a7xx);
- ret = a6xx_set_supported_hw(>dev, config->info);
+ ret = a6xx_set_supported_hw(adreno_gpu, >dev, config->info);
if (ret) {
a6xx_llc_slices_destroy(a6xx_gpu);
kfree(a6xx_gpu);
diff --git a/drivers/gpu/drm/msm/adreno/adreno_device.c
b/drivers/gpu/drm/msm/adreno/adreno_device.c
index c3703a51287b..901ef767e491 100644
--- a/drivers/gpu/drm/msm/adreno/adreno_device.c
+++ b/drivers/gpu/drm/msm/adreno/adreno_device.c
@@ -6,6 +6,8 @@
* Copyright (c) 2014,2017 The Linux Foundation. All rights reserved.
*/
+#include
+
#include "adreno_gpu.h"
bool hang_debug = false;
diff --git a/drivers/gpu/drm/msm/adreno/adreno_gpu.c
b/drivers/gpu/drm/msm/adreno/adreno_gpu.c
index 074fb498706f..055072260b3d 100644
--- a/drivers/gpu/drm/msm/adreno/adreno_gpu.c
+++ b/drivers/gpu/drm/msm/adreno/adreno_gpu.c
@@ -21,6 +21,9 @@
#include "msm_gem.h"
#include "msm_mmu.h"
+#include
+#include
+
static u64 address_space_size = 0;
MODULE_PARM_DESC(address_space_size, "Override for size of processes private
GPU address space");
module_param(address_space_size, ullong, 0600);
@@ -1057,9 +1060,39 @@ void adreno_gpu_ocmem_cleanup(struct adreno_ocmem
*adreno_ocmem)
adreno_ocmem->hdl);
}
-int adreno_read_speedbin(struct device *dev, u32 *speedbin)
+int adreno_read_speedbin(struct adreno_gpu *adreno_gpu,
+struct device *dev, u32 *fuse)
{
- return nvmem_cell_read_variable_le_u32(dev, "speed_bin", speedbin);
+ u32 fcode;
+ int ret;
+
+ /*
+* Try reading the speedbin via a nvmem cell first
+* -ENOENT means "no nvmem-cells" and essentially means "old DT" or
+* "nvmem fuse is irrelevant", simply assume it's fine.
+*/
+ ret = nvmem_cell_read_variable_le_u32(dev, "speed_bin", fuse);
+ if (!ret)
+ return 0;
+ else if (ret != -ENOENT)
+ return dev_err_probe(dev, ret, "Couldn't read the speed bin
fuse value\n");
+
+#ifdef CONFIG_QCOM_SMEM
+ /*
+* Only check the feature code - the product code only matters for
+* proto SoCs unavailable outside Qualcomm labs, as far as GPU bin
+* matching is concerned.
+*
+* Ignore EOPNOTSUPP, as not all SoCs expose this info through SMEM.
+*/
+ ret = qcom_smem_get_feature_code();
+ if (!ret) {
+ *fuse = ADRENO_SKU_ID(fcode);
+ } else if (ret != -EOPNOTSUPP)
+ return dev_err_probe(dev, ret, "Couldn't get feature code from
SMEM\n");
+#endif
+
+ return 0;
}
int adreno_gpu_init(struct drm_device *drm, struct platform_device *pdev,
@@ -1098,9 +1131,9 @@ int adreno_gpu_init(struct drm_device *drm, struct
platform_device *pdev,
devm_pm_opp_set_clkname(dev, "core");
}
- if (adreno_read_speedbin(dev, ) || !speedbin)
+ if (adreno_read_speedbin(adreno_gpu, dev, ) || !speedbin)
speedbin = 0x;
[PATCH v2 4/7] drm/msm/adreno: Add speedbin data for SM8550 / A740
Add speebin data for A740, as found on SM8550 and derivative SoCs.
Reviewed-by: Dmitry Baryshkov
Signed-off-by: Konrad Dybcio
---
drivers/gpu/drm/msm/adreno/adreno_device.c | 4
1 file changed, 4 insertions(+)
diff --git a/drivers/gpu/drm/msm/adreno/adreno_device.c
b/drivers/gpu/drm/msm/adreno/adreno_device.c
index 901ef767e491..e00eef8099ae 100644
--- a/drivers/gpu/drm/msm/adreno/adreno_device.c
+++ b/drivers/gpu/drm/msm/adreno/adreno_device.c
@@ -570,6 +570,10 @@ static const struct adreno_info gpulist[] = {
.zapfw = "a740_zap.mdt",
.hwcg = a740_hwcg,
.address_space_size = SZ_16G,
+ .speedbins = ADRENO_SPEEDBINS(
+ { ADRENO_SKU_ID(SOCINFO_FC_AC), 0 },
+ { ADRENO_SKU_ID(SOCINFO_FC_AF), 0 },
+ ),
}, {
.chip_ids = ADRENO_CHIP_IDS(0x43051401), /* "C520v2" */
.family = ADRENO_7XX_GEN3,
--
2.43.0
[PATCH v2 2/7] soc: qcom: smem: Add a feature code getter
Recent (SM8550+ ish) Qualcomm SoCs have a new mechanism for precisely
identifying the specific SKU and the precise speed bin (in the general
meaning of this word, anyway): a pair of values called Product Code
and Feature Code.
Based on this information, we can deduce the available frequencies for
things such as Adreno. In the case of Adreno specifically, Pcode is
useless for non-prototype SoCs.
Introduce a getter for the feature code and export it.
Reviewed-by: Dmitry Baryshkov
Signed-off-by: Konrad Dybcio
---
drivers/soc/qcom/smem.c | 33 +
include/linux/soc/qcom/smem.h| 1 +
include/linux/soc/qcom/socinfo.h | 26 ++
3 files changed, 60 insertions(+)
diff --git a/drivers/soc/qcom/smem.c b/drivers/soc/qcom/smem.c
index 50039e983eba..e4411771f482 100644
--- a/drivers/soc/qcom/smem.c
+++ b/drivers/soc/qcom/smem.c
@@ -821,6 +821,39 @@ int qcom_smem_get_soc_id(u32 *id)
}
EXPORT_SYMBOL_GPL(qcom_smem_get_soc_id);
+/**
+ * qcom_smem_get_feature_code() - return the feature code
+ * @code: On success, return the feature code here.
+ *
+ * Look up the feature code identifier from SMEM and return it.
+ *
+ * Return: 0 on success, negative errno on failure.
+ */
+int qcom_smem_get_feature_code(u32 *code)
+{
+ struct socinfo *info;
+ u32 raw_code;
+
+ info = qcom_smem_get(QCOM_SMEM_HOST_ANY, SMEM_HW_SW_BUILD_ID, NULL);
+ if (IS_ERR(info))
+ return PTR_ERR(info);
+
+ /* This only makes sense for socinfo >= 16 */
+ if (__le32_to_cpu(info->fmt) < SOCINFO_VERSION(0, 16))
+ return -EOPNOTSUPP;
+
+ raw_code = __le32_to_cpu(info->feature_code);
+
+ /* Ensure the value makes sense */
+ if (raw_code > SOCINFO_FC_INT_MAX)
+ raw_code = SOCINFO_FC_UNKNOWN;
+
+ *code = raw_code;
+
+ return 0;
+}
+EXPORT_SYMBOL_GPL(qcom_smem_get_feature_code);
+
static int qcom_smem_get_sbl_version(struct qcom_smem *smem)
{
struct smem_header *header;
diff --git a/include/linux/soc/qcom/smem.h b/include/linux/soc/qcom/smem.h
index 03187bc95851..f946e3beca21 100644
--- a/include/linux/soc/qcom/smem.h
+++ b/include/linux/soc/qcom/smem.h
@@ -13,6 +13,7 @@ int qcom_smem_get_free_space(unsigned host);
phys_addr_t qcom_smem_virt_to_phys(void *p);
int qcom_smem_get_soc_id(u32 *id);
+int qcom_smem_get_feature_code(u32 *code);
int qcom_smem_bust_hwspin_lock_by_host(unsigned int host);
diff --git a/include/linux/soc/qcom/socinfo.h b/include/linux/soc/qcom/socinfo.h
index 10e0a4c287f4..608950443eee 100644
--- a/include/linux/soc/qcom/socinfo.h
+++ b/include/linux/soc/qcom/socinfo.h
@@ -3,6 +3,8 @@
#ifndef __QCOM_SOCINFO_H__
#define __QCOM_SOCINFO_H__
+#include
+
/*
* SMEM item id, used to acquire handles to respective
* SMEM region.
@@ -82,4 +84,28 @@ struct socinfo {
__le32 boot_core;
};
+/* Internal feature codes */
+enum qcom_socinfo_feature_code {
+ /* External feature codes */
+ SOCINFO_FC_UNKNOWN = 0x0,
+ SOCINFO_FC_AA,
+ SOCINFO_FC_AB,
+ SOCINFO_FC_AC,
+ SOCINFO_FC_AD,
+ SOCINFO_FC_AE,
+ SOCINFO_FC_AF,
+ SOCINFO_FC_AG,
+ SOCINFO_FC_AH,
+};
+
+/* Internal feature codes */
+/* Valid values: 0 <= n <= 0xf */
+#define SOCINFO_FC_Yn(n) (0xf1 + (n))
+#define SOCINFO_FC_INT_MAX SOCINFO_FC_Yn(0xf)
+
+/* Product codes */
+#define SOCINFO_PC_UNKNOWN 0
+#define SOCINFO_PCn(n) ((n) + 1)
+#define SOCINFO_PC_RESERVE (BIT(31) - 1)
+
#endif
--
2.43.0
[PATCH v2 7/7] arm64: dts: qcom: sm8550: Wire up GPU speed bin & more OPPs
Add the speedbin masks to ensure only the desired OPPs are available on
chips of a given bin.
Using this, add the binned 719 MHz OPP and the non-binned 124.8 MHz.
Reviewed-by: Dmitry Baryshkov
Signed-off-by: Konrad Dybcio
---
arch/arm64/boot/dts/qcom/sm8550.dtsi | 21 -
1 file changed, 20 insertions(+), 1 deletion(-)
diff --git a/arch/arm64/boot/dts/qcom/sm8550.dtsi
b/arch/arm64/boot/dts/qcom/sm8550.dtsi
index c55a818af935..5f5ddfe205b0 100644
--- a/arch/arm64/boot/dts/qcom/sm8550.dtsi
+++ b/arch/arm64/boot/dts/qcom/sm8550.dtsi
@@ -2119,48 +2119,67 @@ zap-shader {
memory-region = <_micro_code_mem>;
};
- /* Speedbin needs more work on A740+, keep only lower
freqs */
gpu_opp_table: opp-table {
compatible = "operating-points-v2";
+ opp-71900 {
+ opp-hz = /bits/ 64 <71900>;
+ opp-level =
;
+ opp-supported-hw = <0x1>;
+ };
+
opp-68000 {
opp-hz = /bits/ 64 <68000>;
opp-level =
;
+ opp-supported-hw = <0x3>;
};
opp-61500 {
opp-hz = /bits/ 64 <61500>;
opp-level =
;
+ opp-supported-hw = <0x3>;
};
opp-55000 {
opp-hz = /bits/ 64 <55000>;
opp-level = ;
+ opp-supported-hw = <0x3>;
};
opp-47500 {
opp-hz = /bits/ 64 <47500>;
opp-level =
;
+ opp-supported-hw = <0x3>;
};
opp-40100 {
opp-hz = /bits/ 64 <40100>;
opp-level =
;
+ opp-supported-hw = <0x3>;
};
opp-34800 {
opp-hz = /bits/ 64 <34800>;
opp-level =
;
+ opp-supported-hw = <0x3>;
};
opp-29500 {
opp-hz = /bits/ 64 <29500>;
opp-level =
;
+ opp-supported-hw = <0x3>;
};
opp-22000 {
opp-hz = /bits/ 64 <22000>;
opp-level =
;
+ opp-supported-hw = <0x3>;
+ };
+
+ opp-12480 {
+ opp-hz = /bits/ 64 <12480>;
+ opp-level =
;
+ opp-supported-hw = <0x3>;
};
};
};
--
2.43.0
[PATCH v2 6/7] drm/msm/adreno: Redo the speedbin assignment
There is no need to reinvent the wheel for simple read-match-set logic.
Make speedbin discovery and assignment generation independent.
This implicitly removes the bogus 0x80 / BIT(7) speed bin on A5xx,
which has no representation in hardware whatshowever.
Signed-off-by: Konrad Dybcio
---
drivers/gpu/drm/msm/adreno/a5xx_gpu.c | 34
drivers/gpu/drm/msm/adreno/a6xx_gpu.c | 56 -
drivers/gpu/drm/msm/adreno/adreno_gpu.c | 51 ++
drivers/gpu/drm/msm/adreno/adreno_gpu.h | 3 --
4 files changed, 45 insertions(+), 99 deletions(-)
diff --git a/drivers/gpu/drm/msm/adreno/a5xx_gpu.c
b/drivers/gpu/drm/msm/adreno/a5xx_gpu.c
index c003f970189b..eed6a2eb1731 100644
--- a/drivers/gpu/drm/msm/adreno/a5xx_gpu.c
+++ b/drivers/gpu/drm/msm/adreno/a5xx_gpu.c
@@ -1704,38 +1704,6 @@ static const struct adreno_gpu_funcs funcs = {
.get_timestamp = a5xx_get_timestamp,
};
-static void check_speed_bin(struct device *dev)
-{
- struct nvmem_cell *cell;
- u32 val;
-
- /*
-* If the OPP table specifies a opp-supported-hw property then we have
-* to set something with dev_pm_opp_set_supported_hw() or the table
-* doesn't get populated so pick an arbitrary value that should
-* ensure the default frequencies are selected but not conflict with any
-* actual bins
-*/
- val = 0x80;
-
- cell = nvmem_cell_get(dev, "speed_bin");
-
- if (!IS_ERR(cell)) {
- void *buf = nvmem_cell_read(cell, NULL);
-
- if (!IS_ERR(buf)) {
- u8 bin = *((u8 *) buf);
-
- val = (1 << bin);
- kfree(buf);
- }
-
- nvmem_cell_put(cell);
- }
-
- devm_pm_opp_set_supported_hw(dev, , 1);
-}
-
struct msm_gpu *a5xx_gpu_init(struct drm_device *dev)
{
struct msm_drm_private *priv = dev->dev_private;
@@ -1763,8 +1731,6 @@ struct msm_gpu *a5xx_gpu_init(struct drm_device *dev)
a5xx_gpu->lm_leakage = 0x4E001A;
- check_speed_bin(>dev);
-
nr_rings = 4;
if (config->info->revn == 510)
diff --git a/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
b/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
index 3f84417ff027..d256e27ee581 100644
--- a/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
+++ b/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
@@ -2882,55 +2882,6 @@ static bool a6xx_progress(struct msm_gpu *gpu, struct
msm_ringbuffer *ring)
return progress;
}
-static u32 fuse_to_supp_hw(const struct adreno_info *info, u32 fuse)
-{
- if (!info->speedbins)
- return UINT_MAX;
-
- for (int i = 0; info->speedbins[i].fuse != SHRT_MAX; i++)
- if (info->speedbins[i].fuse == fuse)
- return BIT(info->speedbins[i].speedbin);
-
- return UINT_MAX;
-}
-
-static int a6xx_set_supported_hw(struct adreno_gpu *adreno_gpu,
-struct device *dev,
-const struct adreno_info *info)
-{
- u32 supp_hw;
- u32 speedbin;
- int ret;
-
- ret = adreno_read_speedbin(adreno_gpu, dev, );
- /*
-* -ENOENT means that the platform doesn't support speedbin which is
-* fine
-*/
- if (ret == -ENOENT) {
- return 0;
- } else if (ret) {
- dev_err_probe(dev, ret,
- "failed to read speed-bin. Some OPPs may not be
supported by hardware\n");
- return ret;
- }
-
- supp_hw = fuse_to_supp_hw(info, speedbin);
-
- if (supp_hw == UINT_MAX) {
- DRM_DEV_ERROR(dev,
- "missing support for speed-bin: %u. Some OPPs may not
be supported by hardware\n",
- speedbin);
- supp_hw = BIT(0); /* Default */
- }
-
- ret = devm_pm_opp_set_supported_hw(dev, _hw, 1);
- if (ret)
- return ret;
-
- return 0;
-}
-
static const struct adreno_gpu_funcs funcs = {
.base = {
.get_param = adreno_get_param,
@@ -3062,13 +3013,6 @@ struct msm_gpu *a6xx_gpu_init(struct drm_device *dev)
a6xx_llc_slices_init(pdev, a6xx_gpu, is_a7xx);
- ret = a6xx_set_supported_hw(adreno_gpu, >dev, config->info);
- if (ret) {
- a6xx_llc_slices_destroy(a6xx_gpu);
- kfree(a6xx_gpu);
- return ERR_PTR(ret);
- }
-
if (is_a7xx)
ret = adreno_gpu_init(dev, pdev, adreno_gpu, _a7xx, 1);
else if (adreno_has_gmu_wrapper(adreno_gpu))
diff --git a/drivers/gpu/drm/msm/adreno/adreno_gpu.c
b/drivers/gpu/drm/msm/adreno/adreno_gpu.c
index 055072260b3d..8b2bc5f147e8 100644
--- a/drivers/gpu/drm/msm/adreno/adreno_gpu.c
+++ b/drivers/gpu/drm/msm/adreno/adreno_gpu.c
@@ -1060,8 +1060,
[PATCH v2 7/7] arm64: dts: qcom: sm8550: Wire up GPU speed bin & more OPPs
Add the speedbin masks to ensure only the desired OPPs are available on
chips of a given bin.
Using this, add the binned 719 MHz OPP and the non-binned 124.8 MHz.
Reviewed-by: Dmitry Baryshkov
Signed-off-by: Konrad Dybcio
---
arch/arm64/boot/dts/qcom/sm8550.dtsi | 21 -
1 file changed, 20 insertions(+), 1 deletion(-)
diff --git a/arch/arm64/boot/dts/qcom/sm8550.dtsi
b/arch/arm64/boot/dts/qcom/sm8550.dtsi
index c55a818af935..5f5ddfe205b0 100644
--- a/arch/arm64/boot/dts/qcom/sm8550.dtsi
+++ b/arch/arm64/boot/dts/qcom/sm8550.dtsi
@@ -2119,48 +2119,67 @@ zap-shader {
memory-region = <_micro_code_mem>;
};
- /* Speedbin needs more work on A740+, keep only lower
freqs */
gpu_opp_table: opp-table {
compatible = "operating-points-v2";
+ opp-71900 {
+ opp-hz = /bits/ 64 <71900>;
+ opp-level =
;
+ opp-supported-hw = <0x1>;
+ };
+
opp-68000 {
opp-hz = /bits/ 64 <68000>;
opp-level =
;
+ opp-supported-hw = <0x3>;
};
opp-61500 {
opp-hz = /bits/ 64 <61500>;
opp-level =
;
+ opp-supported-hw = <0x3>;
};
opp-55000 {
opp-hz = /bits/ 64 <55000>;
opp-level = ;
+ opp-supported-hw = <0x3>;
};
opp-47500 {
opp-hz = /bits/ 64 <47500>;
opp-level =
;
+ opp-supported-hw = <0x3>;
};
opp-40100 {
opp-hz = /bits/ 64 <40100>;
opp-level =
;
+ opp-supported-hw = <0x3>;
};
opp-34800 {
opp-hz = /bits/ 64 <34800>;
opp-level =
;
+ opp-supported-hw = <0x3>;
};
opp-29500 {
opp-hz = /bits/ 64 <29500>;
opp-level =
;
+ opp-supported-hw = <0x3>;
};
opp-22000 {
opp-hz = /bits/ 64 <22000>;
opp-level =
;
+ opp-supported-hw = <0x3>;
+ };
+
+ opp-12480 {
+ opp-hz = /bits/ 64 <12480>;
+ opp-level =
;
+ opp-supported-hw = <0x3>;
};
};
};
--
2.43.0
[PATCH v2 5/7] drm/msm/adreno: Define A530 speed bins explicitly
In preparation for commonizing the speedbin handling code.
Reviewed-by: Dmitry Baryshkov
Signed-off-by: Konrad Dybcio
---
drivers/gpu/drm/msm/adreno/adreno_device.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/drivers/gpu/drm/msm/adreno/adreno_device.c
b/drivers/gpu/drm/msm/adreno/adreno_device.c
index e00eef8099ae..66f7868ff476 100644
--- a/drivers/gpu/drm/msm/adreno/adreno_device.c
+++ b/drivers/gpu/drm/msm/adreno/adreno_device.c
@@ -258,6 +258,12 @@ static const struct adreno_info gpulist[] = {
ADRENO_QUIRK_FAULT_DETECT_MASK,
.init = a5xx_gpu_init,
.zapfw = "a530_zap.mdt",
+ .speedbins = ADRENO_SPEEDBINS(
+ { 0, 0 },
+ { 1, 1 },
+ { 2, 2 },
+ { 3, 3 },
+ ),
}, {
.chip_ids = ADRENO_CHIP_IDS(0x05040001),
.family = ADRENO_5XX,
--
2.43.0
[PATCH v2 5/7] drm/msm/adreno: Define A530 speed bins explicitly
In preparation for commonizing the speedbin handling code.
Reviewed-by: Dmitry Baryshkov
Signed-off-by: Konrad Dybcio
---
drivers/gpu/drm/msm/adreno/adreno_device.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/drivers/gpu/drm/msm/adreno/adreno_device.c
b/drivers/gpu/drm/msm/adreno/adreno_device.c
index e00eef8099ae..66f7868ff476 100644
--- a/drivers/gpu/drm/msm/adreno/adreno_device.c
+++ b/drivers/gpu/drm/msm/adreno/adreno_device.c
@@ -258,6 +258,12 @@ static const struct adreno_info gpulist[] = {
ADRENO_QUIRK_FAULT_DETECT_MASK,
.init = a5xx_gpu_init,
.zapfw = "a530_zap.mdt",
+ .speedbins = ADRENO_SPEEDBINS(
+ { 0, 0 },
+ { 1, 1 },
+ { 2, 2 },
+ { 3, 3 },
+ ),
}, {
.chip_ids = ADRENO_CHIP_IDS(0x05040001),
.family = ADRENO_5XX,
--
2.43.0
[PATCH v2 4/7] drm/msm/adreno: Add speedbin data for SM8550 / A740
Add speebin data for A740, as found on SM8550 and derivative SoCs.
Reviewed-by: Dmitry Baryshkov
Signed-off-by: Konrad Dybcio
---
drivers/gpu/drm/msm/adreno/adreno_device.c | 4
1 file changed, 4 insertions(+)
diff --git a/drivers/gpu/drm/msm/adreno/adreno_device.c
b/drivers/gpu/drm/msm/adreno/adreno_device.c
index 901ef767e491..e00eef8099ae 100644
--- a/drivers/gpu/drm/msm/adreno/adreno_device.c
+++ b/drivers/gpu/drm/msm/adreno/adreno_device.c
@@ -570,6 +570,10 @@ static const struct adreno_info gpulist[] = {
.zapfw = "a740_zap.mdt",
.hwcg = a740_hwcg,
.address_space_size = SZ_16G,
+ .speedbins = ADRENO_SPEEDBINS(
+ { ADRENO_SKU_ID(SOCINFO_FC_AC), 0 },
+ { ADRENO_SKU_ID(SOCINFO_FC_AF), 0 },
+ ),
}, {
.chip_ids = ADRENO_CHIP_IDS(0x43051401), /* "C520v2" */
.family = ADRENO_7XX_GEN3,
--
2.43.0
[PATCH v2 3/7] drm/msm/adreno: Implement SMEM-based speed bin
On recent (SM8550+) Snapdragon platforms, the GPU speed bin data is
abstracted through SMEM, instead of being directly available in a fuse.
Add support for SMEM-based speed binning, which includes getting
"feature code" and "product code" from said source and parsing them
to form something that lets us match OPPs against.
Due to the product code being ignored in the context of Adreno on
production parts (as of SM8650), hardcode it to SOCINFO_PC_UNKNOWN.
Signed-off-by: Konrad Dybcio
---
drivers/gpu/drm/msm/adreno/a6xx_gpu.c | 8 +++---
drivers/gpu/drm/msm/adreno/adreno_device.c | 2 ++
drivers/gpu/drm/msm/adreno/adreno_gpu.c| 41 +++---
drivers/gpu/drm/msm/adreno/adreno_gpu.h| 12 ++---
4 files changed, 53 insertions(+), 10 deletions(-)
diff --git a/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
b/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
index 973872ad0474..3f84417ff027 100644
--- a/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
+++ b/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
@@ -2894,13 +2894,15 @@ static u32 fuse_to_supp_hw(const struct adreno_info
*info, u32 fuse)
return UINT_MAX;
}
-static int a6xx_set_supported_hw(struct device *dev, const struct adreno_info
*info)
+static int a6xx_set_supported_hw(struct adreno_gpu *adreno_gpu,
+struct device *dev,
+const struct adreno_info *info)
{
u32 supp_hw;
u32 speedbin;
int ret;
- ret = adreno_read_speedbin(dev, );
+ ret = adreno_read_speedbin(adreno_gpu, dev, );
/*
* -ENOENT means that the platform doesn't support speedbin which is
* fine
@@ -3060,7 +3062,7 @@ struct msm_gpu *a6xx_gpu_init(struct drm_device *dev)
a6xx_llc_slices_init(pdev, a6xx_gpu, is_a7xx);
- ret = a6xx_set_supported_hw(>dev, config->info);
+ ret = a6xx_set_supported_hw(adreno_gpu, >dev, config->info);
if (ret) {
a6xx_llc_slices_destroy(a6xx_gpu);
kfree(a6xx_gpu);
diff --git a/drivers/gpu/drm/msm/adreno/adreno_device.c
b/drivers/gpu/drm/msm/adreno/adreno_device.c
index c3703a51287b..901ef767e491 100644
--- a/drivers/gpu/drm/msm/adreno/adreno_device.c
+++ b/drivers/gpu/drm/msm/adreno/adreno_device.c
@@ -6,6 +6,8 @@
* Copyright (c) 2014,2017 The Linux Foundation. All rights reserved.
*/
+#include
+
#include "adreno_gpu.h"
bool hang_debug = false;
diff --git a/drivers/gpu/drm/msm/adreno/adreno_gpu.c
b/drivers/gpu/drm/msm/adreno/adreno_gpu.c
index 074fb498706f..055072260b3d 100644
--- a/drivers/gpu/drm/msm/adreno/adreno_gpu.c
+++ b/drivers/gpu/drm/msm/adreno/adreno_gpu.c
@@ -21,6 +21,9 @@
#include "msm_gem.h"
#include "msm_mmu.h"
+#include
+#include
+
static u64 address_space_size = 0;
MODULE_PARM_DESC(address_space_size, "Override for size of processes private
GPU address space");
module_param(address_space_size, ullong, 0600);
@@ -1057,9 +1060,39 @@ void adreno_gpu_ocmem_cleanup(struct adreno_ocmem
*adreno_ocmem)
adreno_ocmem->hdl);
}
-int adreno_read_speedbin(struct device *dev, u32 *speedbin)
+int adreno_read_speedbin(struct adreno_gpu *adreno_gpu,
+struct device *dev, u32 *fuse)
{
- return nvmem_cell_read_variable_le_u32(dev, "speed_bin", speedbin);
+ u32 fcode;
+ int ret;
+
+ /*
+* Try reading the speedbin via a nvmem cell first
+* -ENOENT means "no nvmem-cells" and essentially means "old DT" or
+* "nvmem fuse is irrelevant", simply assume it's fine.
+*/
+ ret = nvmem_cell_read_variable_le_u32(dev, "speed_bin", fuse);
+ if (!ret)
+ return 0;
+ else if (ret != -ENOENT)
+ return dev_err_probe(dev, ret, "Couldn't read the speed bin
fuse value\n");
+
+#ifdef CONFIG_QCOM_SMEM
+ /*
+* Only check the feature code - the product code only matters for
+* proto SoCs unavailable outside Qualcomm labs, as far as GPU bin
+* matching is concerned.
+*
+* Ignore EOPNOTSUPP, as not all SoCs expose this info through SMEM.
+*/
+ ret = qcom_smem_get_feature_code();
+ if (!ret) {
+ *fuse = ADRENO_SKU_ID(fcode);
+ } else if (ret != -EOPNOTSUPP)
+ return dev_err_probe(dev, ret, "Couldn't get feature code from
SMEM\n");
+#endif
+
+ return 0;
}
int adreno_gpu_init(struct drm_device *drm, struct platform_device *pdev,
@@ -1098,9 +1131,9 @@ int adreno_gpu_init(struct drm_device *drm, struct
platform_device *pdev,
devm_pm_opp_set_clkname(dev, "core");
}
- if (adreno_read_speedbin(dev, ) || !speedbin)
+ if (adreno_read_speedbin(adreno_gpu, dev, ) || !speedbin)
speedbin = 0x;
[PATCH v2 6/7] drm/msm/adreno: Redo the speedbin assignment
There is no need to reinvent the wheel for simple read-match-set logic.
Make speedbin discovery and assignment generation independent.
This implicitly removes the bogus 0x80 / BIT(7) speed bin on A5xx,
which has no representation in hardware whatshowever.
Signed-off-by: Konrad Dybcio
---
drivers/gpu/drm/msm/adreno/a5xx_gpu.c | 34
drivers/gpu/drm/msm/adreno/a6xx_gpu.c | 56 -
drivers/gpu/drm/msm/adreno/adreno_gpu.c | 51 ++
drivers/gpu/drm/msm/adreno/adreno_gpu.h | 3 --
4 files changed, 45 insertions(+), 99 deletions(-)
diff --git a/drivers/gpu/drm/msm/adreno/a5xx_gpu.c
b/drivers/gpu/drm/msm/adreno/a5xx_gpu.c
index c003f970189b..eed6a2eb1731 100644
--- a/drivers/gpu/drm/msm/adreno/a5xx_gpu.c
+++ b/drivers/gpu/drm/msm/adreno/a5xx_gpu.c
@@ -1704,38 +1704,6 @@ static const struct adreno_gpu_funcs funcs = {
.get_timestamp = a5xx_get_timestamp,
};
-static void check_speed_bin(struct device *dev)
-{
- struct nvmem_cell *cell;
- u32 val;
-
- /*
-* If the OPP table specifies a opp-supported-hw property then we have
-* to set something with dev_pm_opp_set_supported_hw() or the table
-* doesn't get populated so pick an arbitrary value that should
-* ensure the default frequencies are selected but not conflict with any
-* actual bins
-*/
- val = 0x80;
-
- cell = nvmem_cell_get(dev, "speed_bin");
-
- if (!IS_ERR(cell)) {
- void *buf = nvmem_cell_read(cell, NULL);
-
- if (!IS_ERR(buf)) {
- u8 bin = *((u8 *) buf);
-
- val = (1 << bin);
- kfree(buf);
- }
-
- nvmem_cell_put(cell);
- }
-
- devm_pm_opp_set_supported_hw(dev, , 1);
-}
-
struct msm_gpu *a5xx_gpu_init(struct drm_device *dev)
{
struct msm_drm_private *priv = dev->dev_private;
@@ -1763,8 +1731,6 @@ struct msm_gpu *a5xx_gpu_init(struct drm_device *dev)
a5xx_gpu->lm_leakage = 0x4E001A;
- check_speed_bin(>dev);
-
nr_rings = 4;
if (config->info->revn == 510)
diff --git a/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
b/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
index 3f84417ff027..d256e27ee581 100644
--- a/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
+++ b/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
@@ -2882,55 +2882,6 @@ static bool a6xx_progress(struct msm_gpu *gpu, struct
msm_ringbuffer *ring)
return progress;
}
-static u32 fuse_to_supp_hw(const struct adreno_info *info, u32 fuse)
-{
- if (!info->speedbins)
- return UINT_MAX;
-
- for (int i = 0; info->speedbins[i].fuse != SHRT_MAX; i++)
- if (info->speedbins[i].fuse == fuse)
- return BIT(info->speedbins[i].speedbin);
-
- return UINT_MAX;
-}
-
-static int a6xx_set_supported_hw(struct adreno_gpu *adreno_gpu,
-struct device *dev,
-const struct adreno_info *info)
-{
- u32 supp_hw;
- u32 speedbin;
- int ret;
-
- ret = adreno_read_speedbin(adreno_gpu, dev, );
- /*
-* -ENOENT means that the platform doesn't support speedbin which is
-* fine
-*/
- if (ret == -ENOENT) {
- return 0;
- } else if (ret) {
- dev_err_probe(dev, ret,
- "failed to read speed-bin. Some OPPs may not be
supported by hardware\n");
- return ret;
- }
-
- supp_hw = fuse_to_supp_hw(info, speedbin);
-
- if (supp_hw == UINT_MAX) {
- DRM_DEV_ERROR(dev,
- "missing support for speed-bin: %u. Some OPPs may not
be supported by hardware\n",
- speedbin);
- supp_hw = BIT(0); /* Default */
- }
-
- ret = devm_pm_opp_set_supported_hw(dev, _hw, 1);
- if (ret)
- return ret;
-
- return 0;
-}
-
static const struct adreno_gpu_funcs funcs = {
.base = {
.get_param = adreno_get_param,
@@ -3062,13 +3013,6 @@ struct msm_gpu *a6xx_gpu_init(struct drm_device *dev)
a6xx_llc_slices_init(pdev, a6xx_gpu, is_a7xx);
- ret = a6xx_set_supported_hw(adreno_gpu, >dev, config->info);
- if (ret) {
- a6xx_llc_slices_destroy(a6xx_gpu);
- kfree(a6xx_gpu);
- return ERR_PTR(ret);
- }
-
if (is_a7xx)
ret = adreno_gpu_init(dev, pdev, adreno_gpu, _a7xx, 1);
else if (adreno_has_gmu_wrapper(adreno_gpu))
diff --git a/drivers/gpu/drm/msm/adreno/adreno_gpu.c
b/drivers/gpu/drm/msm/adreno/adreno_gpu.c
index 055072260b3d..8b2bc5f147e8 100644
--- a/drivers/gpu/drm/msm/adreno/adreno_gpu.c
+++ b/drivers/gpu/drm/msm/adreno/adreno_gpu.c
@@ -1060,8 +1060,
[PATCH v2 2/7] soc: qcom: smem: Add a feature code getter
Recent (SM8550+ ish) Qualcomm SoCs have a new mechanism for precisely
identifying the specific SKU and the precise speed bin (in the general
meaning of this word, anyway): a pair of values called Product Code
and Feature Code.
Based on this information, we can deduce the available frequencies for
things such as Adreno. In the case of Adreno specifically, Pcode is
useless for non-prototype SoCs.
Introduce a getter for the feature code and export it.
Reviewed-by: Dmitry Baryshkov
Signed-off-by: Konrad Dybcio
---
drivers/soc/qcom/smem.c | 33 +
include/linux/soc/qcom/smem.h| 1 +
include/linux/soc/qcom/socinfo.h | 26 ++
3 files changed, 60 insertions(+)
diff --git a/drivers/soc/qcom/smem.c b/drivers/soc/qcom/smem.c
index 50039e983eba..e4411771f482 100644
--- a/drivers/soc/qcom/smem.c
+++ b/drivers/soc/qcom/smem.c
@@ -821,6 +821,39 @@ int qcom_smem_get_soc_id(u32 *id)
}
EXPORT_SYMBOL_GPL(qcom_smem_get_soc_id);
+/**
+ * qcom_smem_get_feature_code() - return the feature code
+ * @code: On success, return the feature code here.
+ *
+ * Look up the feature code identifier from SMEM and return it.
+ *
+ * Return: 0 on success, negative errno on failure.
+ */
+int qcom_smem_get_feature_code(u32 *code)
+{
+ struct socinfo *info;
+ u32 raw_code;
+
+ info = qcom_smem_get(QCOM_SMEM_HOST_ANY, SMEM_HW_SW_BUILD_ID, NULL);
+ if (IS_ERR(info))
+ return PTR_ERR(info);
+
+ /* This only makes sense for socinfo >= 16 */
+ if (__le32_to_cpu(info->fmt) < SOCINFO_VERSION(0, 16))
+ return -EOPNOTSUPP;
+
+ raw_code = __le32_to_cpu(info->feature_code);
+
+ /* Ensure the value makes sense */
+ if (raw_code > SOCINFO_FC_INT_MAX)
+ raw_code = SOCINFO_FC_UNKNOWN;
+
+ *code = raw_code;
+
+ return 0;
+}
+EXPORT_SYMBOL_GPL(qcom_smem_get_feature_code);
+
static int qcom_smem_get_sbl_version(struct qcom_smem *smem)
{
struct smem_header *header;
diff --git a/include/linux/soc/qcom/smem.h b/include/linux/soc/qcom/smem.h
index 03187bc95851..f946e3beca21 100644
--- a/include/linux/soc/qcom/smem.h
+++ b/include/linux/soc/qcom/smem.h
@@ -13,6 +13,7 @@ int qcom_smem_get_free_space(unsigned host);
phys_addr_t qcom_smem_virt_to_phys(void *p);
int qcom_smem_get_soc_id(u32 *id);
+int qcom_smem_get_feature_code(u32 *code);
int qcom_smem_bust_hwspin_lock_by_host(unsigned int host);
diff --git a/include/linux/soc/qcom/socinfo.h b/include/linux/soc/qcom/socinfo.h
index 10e0a4c287f4..608950443eee 100644
--- a/include/linux/soc/qcom/socinfo.h
+++ b/include/linux/soc/qcom/socinfo.h
@@ -3,6 +3,8 @@
#ifndef __QCOM_SOCINFO_H__
#define __QCOM_SOCINFO_H__
+#include
+
/*
* SMEM item id, used to acquire handles to respective
* SMEM region.
@@ -82,4 +84,28 @@ struct socinfo {
__le32 boot_core;
};
+/* Internal feature codes */
+enum qcom_socinfo_feature_code {
+ /* External feature codes */
+ SOCINFO_FC_UNKNOWN = 0x0,
+ SOCINFO_FC_AA,
+ SOCINFO_FC_AB,
+ SOCINFO_FC_AC,
+ SOCINFO_FC_AD,
+ SOCINFO_FC_AE,
+ SOCINFO_FC_AF,
+ SOCINFO_FC_AG,
+ SOCINFO_FC_AH,
+};
+
+/* Internal feature codes */
+/* Valid values: 0 <= n <= 0xf */
+#define SOCINFO_FC_Yn(n) (0xf1 + (n))
+#define SOCINFO_FC_INT_MAX SOCINFO_FC_Yn(0xf)
+
+/* Product codes */
+#define SOCINFO_PC_UNKNOWN 0
+#define SOCINFO_PCn(n) ((n) + 1)
+#define SOCINFO_PC_RESERVE (BIT(31) - 1)
+
#endif
--
2.43.0
[PATCH v2 1/7] soc: qcom: Move some socinfo defines to the header
In preparation for parsing the chip "feature code" (FC) and "product
code" (PC) (essentially the parameters that let us conclusively
characterize the sillicon we're running on, including various speed
bins), move the socinfo version defines to the public header.
Signed-off-by: Konrad Dybcio
---
drivers/soc/qcom/socinfo.c | 8
include/linux/soc/qcom/socinfo.h | 8
2 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/drivers/soc/qcom/socinfo.c b/drivers/soc/qcom/socinfo.c
index 8087941a7887..beb23e292323 100644
--- a/drivers/soc/qcom/socinfo.c
+++ b/drivers/soc/qcom/socinfo.c
@@ -21,14 +21,6 @@
#include
-/*
- * SoC version type with major number in the upper 16 bits and minor
- * number in the lower 16 bits.
- */
-#define SOCINFO_MAJOR(ver) (((ver) >> 16) & 0x)
-#define SOCINFO_MINOR(ver) ((ver) & 0x)
-#define SOCINFO_VERSION(maj, min) maj) & 0x) << 16)|((min) & 0x))
-
/* Helper macros to create soc_id table */
#define qcom_board_id(id) QCOM_ID_ ## id, __stringify(id)
#define qcom_board_id_named(id, name) QCOM_ID_ ## id, (name)
diff --git a/include/linux/soc/qcom/socinfo.h b/include/linux/soc/qcom/socinfo.h
index e78777bb0f4a..10e0a4c287f4 100644
--- a/include/linux/soc/qcom/socinfo.h
+++ b/include/linux/soc/qcom/socinfo.h
@@ -12,6 +12,14 @@
#define SMEM_SOCINFO_BUILD_ID_LENGTH 32
#define SMEM_SOCINFO_CHIP_ID_LENGTH32
+/*
+ * SoC version type with major number in the upper 16 bits and minor
+ * number in the lower 16 bits.
+ */
+#define SOCINFO_MAJOR(ver) (((ver) >> 16) & 0x)
+#define SOCINFO_MINOR(ver) ((ver) & 0x)
+#define SOCINFO_VERSION(maj, min) maj) & 0x) << 16)|((min) & 0x))
+
/* Socinfo SMEM item structure */
struct socinfo {
__le32 fmt;
--
2.43.0
[PATCH v2 1/7] soc: qcom: Move some socinfo defines to the header
In preparation for parsing the chip "feature code" (FC) and "product
code" (PC) (essentially the parameters that let us conclusively
characterize the sillicon we're running on, including various speed
bins), move the socinfo version defines to the public header.
Signed-off-by: Konrad Dybcio
---
drivers/soc/qcom/socinfo.c | 8
include/linux/soc/qcom/socinfo.h | 8
2 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/drivers/soc/qcom/socinfo.c b/drivers/soc/qcom/socinfo.c
index 8087941a7887..beb23e292323 100644
--- a/drivers/soc/qcom/socinfo.c
+++ b/drivers/soc/qcom/socinfo.c
@@ -21,14 +21,6 @@
#include
-/*
- * SoC version type with major number in the upper 16 bits and minor
- * number in the lower 16 bits.
- */
-#define SOCINFO_MAJOR(ver) (((ver) >> 16) & 0x)
-#define SOCINFO_MINOR(ver) ((ver) & 0x)
-#define SOCINFO_VERSION(maj, min) maj) & 0x) << 16)|((min) & 0x))
-
/* Helper macros to create soc_id table */
#define qcom_board_id(id) QCOM_ID_ ## id, __stringify(id)
#define qcom_board_id_named(id, name) QCOM_ID_ ## id, (name)
diff --git a/include/linux/soc/qcom/socinfo.h b/include/linux/soc/qcom/socinfo.h
index e78777bb0f4a..10e0a4c287f4 100644
--- a/include/linux/soc/qcom/socinfo.h
+++ b/include/linux/soc/qcom/socinfo.h
@@ -12,6 +12,14 @@
#define SMEM_SOCINFO_BUILD_ID_LENGTH 32
#define SMEM_SOCINFO_CHIP_ID_LENGTH32
+/*
+ * SoC version type with major number in the upper 16 bits and minor
+ * number in the lower 16 bits.
+ */
+#define SOCINFO_MAJOR(ver) (((ver) >> 16) & 0x)
+#define SOCINFO_MINOR(ver) ((ver) & 0x)
+#define SOCINFO_VERSION(maj, min) maj) & 0x) << 16)|((min) & 0x))
+
/* Socinfo SMEM item structure */
struct socinfo {
__le32 fmt;
--
2.43.0
[PATCH v2 0/7] Add SMEM-based speedbin matching
Newer (SM8550+) SoCs don't seem to have a nice speedbin fuse anymore,
but instead rely on a set of combinations of "feature code" (FC) and
"product code" (PC) identifiers to match the bins. This series adds
support for that.
I suppose a qcom/for-soc immutable branch would be in order if we want
to land this in the upcoming cycle.
FWIW I preferred the fuses myself..
Signed-off-by: Konrad Dybcio
---
Changes in v3:
- Wrap the argument usage in new preprocessor macros in braces (Bjorn)
- Make the SOCINFO_FC_INT_MAX define inclusive, adjust .h and .c (Bjorn)
- Pick up rbs
- Rebase on next-20240605
- Drop the already-applied ("Avoid a nullptr dereference when speedbin
setting fails")
Changes in v2:
- Separate moving existing and adding new defines
- Fix kerneldoc copypasta
- Remove some wrong comments and defines
- Remove assumed "max" values for PCs and external FCs
- Improve some commit messages
- Return -EOPNOTSUPP instead of -EINVAL when calling p/fcode getters
on socinfo older than v16
- Drop pcode getters and evaluation (doesn't matter for Adreno on
non-proto SoCs)
- Rework the speedbin logic to be hopefully saner
- Link to v1:
https://lore.kernel.org/r/20240405-topic-smem_speedbin-v1-0-ce2b86425...@linaro.org
---
Konrad Dybcio (7):
soc: qcom: Move some socinfo defines to the header
soc: qcom: smem: Add a feature code getter
drm/msm/adreno: Implement SMEM-based speed bin
drm/msm/adreno: Add speedbin data for SM8550 / A740
drm/msm/adreno: Define A530 speed bins explicitly
drm/msm/adreno: Redo the speedbin assignment
arm64: dts: qcom: sm8550: Wire up GPU speed bin & more OPPs
arch/arm64/boot/dts/qcom/sm8550.dtsi | 21 +++-
drivers/gpu/drm/msm/adreno/a5xx_gpu.c | 34
drivers/gpu/drm/msm/adreno/a6xx_gpu.c | 54 ---
drivers/gpu/drm/msm/adreno/adreno_device.c | 12 +
drivers/gpu/drm/msm/adreno/adreno_gpu.c| 84 +++---
drivers/gpu/drm/msm/adreno/adreno_gpu.h| 11 ++--
drivers/soc/qcom/smem.c| 33
drivers/soc/qcom/socinfo.c | 8 ---
include/linux/soc/qcom/smem.h | 1 +
include/linux/soc/qcom/socinfo.h | 34
10 files changed, 185 insertions(+), 107 deletions(-)
---
base-commit: 234cb065ad82915ff8d06ce01e01c3e640b674d2
change-id: 20240404-topic-smem_speedbin-8deecd0bef0e
Best regards,
--
Konrad Dybcio
[PATCH v2 0/7] Add SMEM-based speedbin matching
Newer (SM8550+) SoCs don't seem to have a nice speedbin fuse anymore,
but instead rely on a set of combinations of "feature code" (FC) and
"product code" (PC) identifiers to match the bins. This series adds
support for that.
I suppose a qcom/for-soc immutable branch would be in order if we want
to land this in the upcoming cycle.
FWIW I preferred the fuses myself..
Signed-off-by: Konrad Dybcio
---
Changes in v3:
- Wrap the argument usage in new preprocessor macros in braces (Bjorn)
- Make the SOCINFO_FC_INT_MAX define inclusive, adjust .h and .c (Bjorn)
- Pick up rbs
- Rebase on next-20240605
- Drop the already-applied ("Avoid a nullptr dereference when speedbin
setting fails")
Changes in v2:
- Separate moving existing and adding new defines
- Fix kerneldoc copypasta
- Remove some wrong comments and defines
- Remove assumed "max" values for PCs and external FCs
- Improve some commit messages
- Return -EOPNOTSUPP instead of -EINVAL when calling p/fcode getters
on socinfo older than v16
- Drop pcode getters and evaluation (doesn't matter for Adreno on
non-proto SoCs)
- Rework the speedbin logic to be hopefully saner
- Link to v1:
https://lore.kernel.org/r/20240405-topic-smem_speedbin-v1-0-ce2b86425...@linaro.org
---
Konrad Dybcio (7):
soc: qcom: Move some socinfo defines to the header
soc: qcom: smem: Add a feature code getter
drm/msm/adreno: Implement SMEM-based speed bin
drm/msm/adreno: Add speedbin data for SM8550 / A740
drm/msm/adreno: Define A530 speed bins explicitly
drm/msm/adreno: Redo the speedbin assignment
arm64: dts: qcom: sm8550: Wire up GPU speed bin & more OPPs
arch/arm64/boot/dts/qcom/sm8550.dtsi | 21 +++-
drivers/gpu/drm/msm/adreno/a5xx_gpu.c | 34
drivers/gpu/drm/msm/adreno/a6xx_gpu.c | 54 ---
drivers/gpu/drm/msm/adreno/adreno_device.c | 12 +
drivers/gpu/drm/msm/adreno/adreno_gpu.c| 84 +++---
drivers/gpu/drm/msm/adreno/adreno_gpu.h| 11 ++--
drivers/soc/qcom/smem.c| 33
drivers/soc/qcom/socinfo.c | 8 ---
include/linux/soc/qcom/smem.h | 1 +
include/linux/soc/qcom/socinfo.h | 34
10 files changed, 185 insertions(+), 107 deletions(-)
---
base-commit: 234cb065ad82915ff8d06ce01e01c3e640b674d2
change-id: 20240404-topic-smem_speedbin-8deecd0bef0e
Best regards,
--
Konrad Dybcio
Re: [PATCH v2] drm/msm/adreno: Add support for Adreno 505 GPU
On 4.06.2024 8:10 PM, Barnabás Czémán wrote: > From: Daniil Titov > > This GPU is found on SoCs such as MSM8937 (450 MHz), MSM8940 (475 MHz), > SDM439 (650 MHz). > > Signed-off-by: Daniil Titov > Signed-off-by: Barnabás Czémán > --- Reviewed-by: Konrad Dybcio Konrad
Re: [PATCH v2] drm/msm/adreno: Add support for Adreno 505 GPU
On 4.06.2024 8:10 PM, Barnabás Czémán wrote: > From: Daniil Titov > > This GPU is found on SoCs such as MSM8937 (450 MHz), MSM8940 (475 MHz), > SDM439 (650 MHz). > > Signed-off-by: Daniil Titov > Signed-off-by: Barnabás Czémán > --- Reviewed-by: Konrad Dybcio Konrad
[jira] [Updated] (MNG-8135) Profile activation based on OS properties is no longer case insensitive
[
https://issues.apache.org/jira/browse/MNG-8135?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Konrad Windszus updated MNG-8135:
-
Description:
This BUG is introduced by MNG-5726. Prior that change the os name, arch and
version comparison was always case-insensitive. Afterwards it needs to match
the lower-case variants.
When OS name, arch or version has capital letters, it won't activate the
profile.
For example:
{code:java}
Mac OS X
aarch64
{code}
was:
This BUG is introduced by MNG-5726. Prior that change the os name, arch and
version comparison was always case-insensitive. Afterwards it needs to match
the lower-case variants.
When OS name has capital letters, it can not activate the profile.
For example:
{code:java}
Mac OS X
aarch64
{code}
> Profile activation based on OS properties is no longer case insensitive
> ---
>
> Key: MNG-8135
> URL: https://issues.apache.org/jira/browse/MNG-8135
> Project: Maven
> Issue Type: Bug
> Components: Profiles
>Affects Versions: 3.9.7
>Reporter: Lijia Liu
>Priority: Major
> Fix For: 4.0.0, 3.9.8, 4.0.0-beta-4
>
>
> This BUG is introduced by MNG-5726. Prior that change the os name, arch and
> version comparison was always case-insensitive. Afterwards it needs to match
> the lower-case variants.
> When OS name, arch or version has capital letters, it won't activate the
> profile.
> For example:
> {code:java}
>
>
> Mac OS X
> aarch64
>
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (MNG-8135) Profile activation based on OS properties is no longer case insensitive
[
https://issues.apache.org/jira/browse/MNG-8135?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Konrad Windszus updated MNG-8135:
-
Summary: Profile activation based on OS properties is no longer case
insensitive (was: Activate profile by capital OS name fail)
> Profile activation based on OS properties is no longer case insensitive
> ---
>
> Key: MNG-8135
> URL: https://issues.apache.org/jira/browse/MNG-8135
> Project: Maven
> Issue Type: Bug
> Components: Profiles
>Affects Versions: 3.9.7
>Reporter: Lijia Liu
>Priority: Major
> Fix For: 4.0.0, 3.9.8, 4.0.0-beta-4
>
>
> This BUG is introduced by MNG-5726. Prior that change the os name, arch and
> version comparison was always case-insensitive. Afterwards it needs to match
> the lower-case variants.
> When OS name has capital letters, it can not activate the profile.
> For example:
> {code:java}
>
>
> Mac OS X
> aarch64
>
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (MNG-8135) Activate profile by capital OS name fail
[
https://issues.apache.org/jira/browse/MNG-8135?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Konrad Windszus updated MNG-8135:
-
Description:
This BUG is introduced by MNG-5726. Prior that change the os name, arch and
version comparison was always case-insensitive. Afterwards it needs to match
the lower-case variants.
When OS name has capital letters, it can not activate the profile.
For example:
{code:java}
Mac OS X
aarch64
{code}
was:
This BUG is introduced by MNG-5726.
When OS name has capital letters, it can not activate the profile.
For example:
{code:java}
Mac OS X
aarch64
{code}
> Activate profile by capital OS name fail
>
>
> Key: MNG-8135
> URL: https://issues.apache.org/jira/browse/MNG-8135
> Project: Maven
> Issue Type: Bug
> Components: Profiles
>Affects Versions: 3.9.7
>Reporter: Lijia Liu
>Priority: Major
>
> This BUG is introduced by MNG-5726. Prior that change the os name, arch and
> version comparison was always case-insensitive. Afterwards it needs to match
> the lower-case variants.
> When OS name has capital letters, it can not activate the profile.
> For example:
> {code:java}
>
>
> Mac OS X
> aarch64
>
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
Re: [PATCH] drm/msm/adreno: Add support for Adreno 505 GPU
On 6/4/24 19:33, Barnabás Czémán wrote: On Tue, Jun 4, 2024 at 7:06 PM Konrad Dybcio wrote: On 6/4/24 18:45, Barnabás Czémán wrote: On Tue, Jun 4, 2024 at 2:27 PM Barnabás Czémán wrote: On Tue, Jun 4, 2024 at 1:55 PM Konrad Dybcio wrote: On 6/4/24 02:20, Barnabás Czémán wrote: From: Daniil Titov This GPU is found on SoCs such as MSM8937 (450 MHz), MSM8940 (475 MHz), SDM439 (650 MHz). Signed-off-by: Daniil Titov Signed-off-by: Barnabás Czémán --- This all looks very good, just a nit [...] + /* + * Increase inactive period to 250 to avoid bouncing + * the GDSC which appears to make it grumpy + */ + .inactive_period = 250, Are you sure this is actually necessary? Every A5XX GPU is using the same value, but i have never tried with DRM_MSM_INACTIVE_PERIOD. This was the original patch https://lore.kernel.org/all/20180507224750.9383-1-jcro...@codeaurora.org/ where the inactive period was increased for a530. I cannot test suspend on msm8937 yet. The suspend here refers to device suspend, not system suspend. Adreno goes into device suspend every time you stop using it, i.e. after the rendering is done and there's no more work to do. I suppose a good test scenario here would be to keep running and closing kmscube in a rapid fashion and checking if the GPU starts crashing for unknown reasons (the dmesg would denote that) I have checked on a505 and a506 with this small script while true; do kmscube; kill kmscube; done none of them crashing, so i am going to change it. Hmm.. not sure if it actually idled when tested in a tight loop.. If you're running bash, try "while true; do kmscube &; sleep 0.08; pkill -f kmscube; sleep 0.08;done" Konrad
Re: [PATCH] drm/msm/adreno: Add support for Adreno 505 GPU
On 6/4/24 19:33, Barnabás Czémán wrote: On Tue, Jun 4, 2024 at 7:06 PM Konrad Dybcio wrote: On 6/4/24 18:45, Barnabás Czémán wrote: On Tue, Jun 4, 2024 at 2:27 PM Barnabás Czémán wrote: On Tue, Jun 4, 2024 at 1:55 PM Konrad Dybcio wrote: On 6/4/24 02:20, Barnabás Czémán wrote: From: Daniil Titov This GPU is found on SoCs such as MSM8937 (450 MHz), MSM8940 (475 MHz), SDM439 (650 MHz). Signed-off-by: Daniil Titov Signed-off-by: Barnabás Czémán --- This all looks very good, just a nit [...] + /* + * Increase inactive period to 250 to avoid bouncing + * the GDSC which appears to make it grumpy + */ + .inactive_period = 250, Are you sure this is actually necessary? Every A5XX GPU is using the same value, but i have never tried with DRM_MSM_INACTIVE_PERIOD. This was the original patch https://lore.kernel.org/all/20180507224750.9383-1-jcro...@codeaurora.org/ where the inactive period was increased for a530. I cannot test suspend on msm8937 yet. The suspend here refers to device suspend, not system suspend. Adreno goes into device suspend every time you stop using it, i.e. after the rendering is done and there's no more work to do. I suppose a good test scenario here would be to keep running and closing kmscube in a rapid fashion and checking if the GPU starts crashing for unknown reasons (the dmesg would denote that) I have checked on a505 and a506 with this small script while true; do kmscube; kill kmscube; done none of them crashing, so i am going to change it. Hmm.. not sure if it actually idled when tested in a tight loop.. If you're running bash, try "while true; do kmscube &; sleep 0.08; pkill -f kmscube; sleep 0.08;done" Konrad
Re: [PATCH] drm/msm/adreno: De-spaghettify the use of memory barriers
On 5/14/24 20:38, Akhil P Oommen wrote:
On Wed, May 08, 2024 at 07:46:31PM +0200, Konrad Dybcio wrote:
Memory barriers help ensure instruction ordering, NOT time and order
of actual write arrival at other observers (e.g. memory-mapped IP).
On architectures employing weak memory ordering, the latter can be a
giant pain point, and it has been as part of this driver.
Moreover, the gpu_/gmu_ accessors already use non-relaxed versions of
readl/writel, which include r/w (respectively) barriers.
Replace the barriers with a readback that ensures the previous writes
have exited the write buffer (as the CPU must flush the write to the
register it's trying to read back) and subsequently remove the hack
introduced in commit b77532803d11 ("drm/msm/a6xx: Poll for GBIF unhalt
status in hw_init").
Fixes: b77532803d11 ("drm/msm/a6xx: Poll for GBIF unhalt status in hw_init")
Signed-off-by: Konrad Dybcio
---
drivers/gpu/drm/msm/adreno/a6xx_gmu.c | 5 ++---
drivers/gpu/drm/msm/adreno/a6xx_gpu.c | 14 --
2 files changed, 6 insertions(+), 13 deletions(-)
I prefer this version compared to the v2. A helper routine is
unnecessary here because:
1. there are very few scenarios where we have to read back the same
register.
2. we may accidently readback a write only register.
Which would still trigger an address dependency on the CPU, no?
diff --git a/drivers/gpu/drm/msm/adreno/a6xx_gmu.c
b/drivers/gpu/drm/msm/adreno/a6xx_gmu.c
index 0e3dfd4c2bc8..4135a53b55a7 100644
--- a/drivers/gpu/drm/msm/adreno/a6xx_gmu.c
+++ b/drivers/gpu/drm/msm/adreno/a6xx_gmu.c
@@ -466,9 +466,8 @@ static int a6xx_rpmh_start(struct a6xx_gmu *gmu)
int ret;
u32 val;
- gmu_write(gmu, REG_A6XX_GMU_RSCC_CONTROL_REQ, 1 << 1);
- /* Wait for the register to finish posting */
- wmb();
+ gmu_write(gmu, REG_A6XX_GMU_RSCC_CONTROL_REQ, BIT(1));
+ gmu_read(gmu, REG_A6XX_GMU_RSCC_CONTROL_REQ);
This is unnecessary because we are polling on a register on the same port
below. But I think we
can replace "wmb()" above with "mb()" to avoid reordering between read
and write IO instructions.
Ok on the dropping readback part
+ AFAIU from Will's response, we can drop the barrier as well
ret = gmu_poll_timeout(gmu, REG_A6XX_GMU_RSCC_CONTROL_ACK, val,
val & (1 << 1), 100, 1);
diff --git a/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
b/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
index 973872ad0474..0acbc38b8e70 100644
--- a/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
+++ b/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
@@ -1713,22 +1713,16 @@ static int hw_init(struct msm_gpu *gpu)
}
/* Clear GBIF halt in case GX domain was not collapsed */
+ gpu_write(gpu, REG_A6XX_GBIF_HALT, 0);
We need a full barrier here to avoid reordering. Also, lets add a
comment about why we are doing this odd looking sequence.
+ gpu_read(gpu, REG_A6XX_GBIF_HALT);
if (adreno_is_a619_holi(adreno_gpu)) {
- gpu_write(gpu, REG_A6XX_GBIF_HALT, 0);
gpu_write(gpu, REG_A6XX_RBBM_GPR0_CNTL, 0);
- /* Let's make extra sure that the GPU can access the memory.. */
- mb();
We need a full barrier here.
+ gpu_read(gpu, REG_A6XX_RBBM_GPR0_CNTL);
} else if (a6xx_has_gbif(adreno_gpu)) {
- gpu_write(gpu, REG_A6XX_GBIF_HALT, 0);
gpu_write(gpu, REG_A6XX_RBBM_GBIF_HALT, 0);
- /* Let's make extra sure that the GPU can access the memory.. */
- mb();
We need a full barrier here.
Not sure we do between REG_A6XX_GBIF_HALT & REG_A6XX_RBBM_(GBIF_HALT/GPR0_CNTL),
but I suppose keeping the one after REG_A6XX_RBBM_(GBIF_HALT/GPR0_CNTL) makes
sense to avoid the possibility of configuring the GPU before it can access
DRAM..
+ gpu_read(gpu, REG_A6XX_RBBM_GBIF_HALT);
}
- /* Some GPUs are stubborn and take their sweet time to unhalt GBIF! */
- if (adreno_is_a7xx(adreno_gpu) && a6xx_has_gbif(adreno_gpu))
- spin_until(!gpu_read(gpu, REG_A6XX_GBIF_HALT_ACK));
-
Why is this removed?
Because it was a hack in the first place and the enforcement of GBIF
unhalt requests coming through before proceeding further removes the
necessity to check this (unless there's some hw-mandated delay we should
keep in mind, but kgsl doesn't have that and there doesn't seem to be
any from testing on 8[456]50).
Konrad
Re: [PATCH] drm/msm/adreno: De-spaghettify the use of memory barriers
On 5/14/24 20:38, Akhil P Oommen wrote:
On Wed, May 08, 2024 at 07:46:31PM +0200, Konrad Dybcio wrote:
Memory barriers help ensure instruction ordering, NOT time and order
of actual write arrival at other observers (e.g. memory-mapped IP).
On architectures employing weak memory ordering, the latter can be a
giant pain point, and it has been as part of this driver.
Moreover, the gpu_/gmu_ accessors already use non-relaxed versions of
readl/writel, which include r/w (respectively) barriers.
Replace the barriers with a readback that ensures the previous writes
have exited the write buffer (as the CPU must flush the write to the
register it's trying to read back) and subsequently remove the hack
introduced in commit b77532803d11 ("drm/msm/a6xx: Poll for GBIF unhalt
status in hw_init").
Fixes: b77532803d11 ("drm/msm/a6xx: Poll for GBIF unhalt status in hw_init")
Signed-off-by: Konrad Dybcio
---
drivers/gpu/drm/msm/adreno/a6xx_gmu.c | 5 ++---
drivers/gpu/drm/msm/adreno/a6xx_gpu.c | 14 --
2 files changed, 6 insertions(+), 13 deletions(-)
I prefer this version compared to the v2. A helper routine is
unnecessary here because:
1. there are very few scenarios where we have to read back the same
register.
2. we may accidently readback a write only register.
Which would still trigger an address dependency on the CPU, no?
diff --git a/drivers/gpu/drm/msm/adreno/a6xx_gmu.c
b/drivers/gpu/drm/msm/adreno/a6xx_gmu.c
index 0e3dfd4c2bc8..4135a53b55a7 100644
--- a/drivers/gpu/drm/msm/adreno/a6xx_gmu.c
+++ b/drivers/gpu/drm/msm/adreno/a6xx_gmu.c
@@ -466,9 +466,8 @@ static int a6xx_rpmh_start(struct a6xx_gmu *gmu)
int ret;
u32 val;
- gmu_write(gmu, REG_A6XX_GMU_RSCC_CONTROL_REQ, 1 << 1);
- /* Wait for the register to finish posting */
- wmb();
+ gmu_write(gmu, REG_A6XX_GMU_RSCC_CONTROL_REQ, BIT(1));
+ gmu_read(gmu, REG_A6XX_GMU_RSCC_CONTROL_REQ);
This is unnecessary because we are polling on a register on the same port
below. But I think we
can replace "wmb()" above with "mb()" to avoid reordering between read
and write IO instructions.
Ok on the dropping readback part
+ AFAIU from Will's response, we can drop the barrier as well
ret = gmu_poll_timeout(gmu, REG_A6XX_GMU_RSCC_CONTROL_ACK, val,
val & (1 << 1), 100, 1);
diff --git a/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
b/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
index 973872ad0474..0acbc38b8e70 100644
--- a/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
+++ b/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
@@ -1713,22 +1713,16 @@ static int hw_init(struct msm_gpu *gpu)
}
/* Clear GBIF halt in case GX domain was not collapsed */
+ gpu_write(gpu, REG_A6XX_GBIF_HALT, 0);
We need a full barrier here to avoid reordering. Also, lets add a
comment about why we are doing this odd looking sequence.
+ gpu_read(gpu, REG_A6XX_GBIF_HALT);
if (adreno_is_a619_holi(adreno_gpu)) {
- gpu_write(gpu, REG_A6XX_GBIF_HALT, 0);
gpu_write(gpu, REG_A6XX_RBBM_GPR0_CNTL, 0);
- /* Let's make extra sure that the GPU can access the memory.. */
- mb();
We need a full barrier here.
+ gpu_read(gpu, REG_A6XX_RBBM_GPR0_CNTL);
} else if (a6xx_has_gbif(adreno_gpu)) {
- gpu_write(gpu, REG_A6XX_GBIF_HALT, 0);
gpu_write(gpu, REG_A6XX_RBBM_GBIF_HALT, 0);
- /* Let's make extra sure that the GPU can access the memory.. */
- mb();
We need a full barrier here.
Not sure we do between REG_A6XX_GBIF_HALT & REG_A6XX_RBBM_(GBIF_HALT/GPR0_CNTL),
but I suppose keeping the one after REG_A6XX_RBBM_(GBIF_HALT/GPR0_CNTL) makes
sense to avoid the possibility of configuring the GPU before it can access
DRAM..
+ gpu_read(gpu, REG_A6XX_RBBM_GBIF_HALT);
}
- /* Some GPUs are stubborn and take their sweet time to unhalt GBIF! */
- if (adreno_is_a7xx(adreno_gpu) && a6xx_has_gbif(adreno_gpu))
- spin_until(!gpu_read(gpu, REG_A6XX_GBIF_HALT_ACK));
-
Why is this removed?
Because it was a hack in the first place and the enforcement of GBIF
unhalt requests coming through before proceeding further removes the
necessity to check this (unless there's some hw-mandated delay we should
keep in mind, but kgsl doesn't have that and there doesn't seem to be
any from testing on 8[456]50).
Konrad
Re: [PATCH] drm/msm/adreno: Add support for Adreno 505 GPU
On 6/4/24 18:45, Barnabás Czémán wrote: On Tue, Jun 4, 2024 at 2:27 PM Barnabás Czémán wrote: On Tue, Jun 4, 2024 at 1:55 PM Konrad Dybcio wrote: On 6/4/24 02:20, Barnabás Czémán wrote: From: Daniil Titov This GPU is found on SoCs such as MSM8937 (450 MHz), MSM8940 (475 MHz), SDM439 (650 MHz). Signed-off-by: Daniil Titov Signed-off-by: Barnabás Czémán --- This all looks very good, just a nit [...] + /* + * Increase inactive period to 250 to avoid bouncing + * the GDSC which appears to make it grumpy + */ + .inactive_period = 250, Are you sure this is actually necessary? Every A5XX GPU is using the same value, but i have never tried with DRM_MSM_INACTIVE_PERIOD. This was the original patch https://lore.kernel.org/all/20180507224750.9383-1-jcro...@codeaurora.org/ where the inactive period was increased for a530. I cannot test suspend on msm8937 yet. The suspend here refers to device suspend, not system suspend. Adreno goes into device suspend every time you stop using it, i.e. after the rendering is done and there's no more work to do. I suppose a good test scenario here would be to keep running and closing kmscube in a rapid fashion and checking if the GPU starts crashing for unknown reasons (the dmesg would denote that) I can check on msm8953 with a506 maybe if a506 works fine with DRM_MSM_INACTIVE_PERIOD then a505 would be fine with it also. The more testing the merrier :) Konrad
Re: [PATCH] drm/msm/adreno: Add support for Adreno 505 GPU
On 6/4/24 18:45, Barnabás Czémán wrote: On Tue, Jun 4, 2024 at 2:27 PM Barnabás Czémán wrote: On Tue, Jun 4, 2024 at 1:55 PM Konrad Dybcio wrote: On 6/4/24 02:20, Barnabás Czémán wrote: From: Daniil Titov This GPU is found on SoCs such as MSM8937 (450 MHz), MSM8940 (475 MHz), SDM439 (650 MHz). Signed-off-by: Daniil Titov Signed-off-by: Barnabás Czémán --- This all looks very good, just a nit [...] + /* + * Increase inactive period to 250 to avoid bouncing + * the GDSC which appears to make it grumpy + */ + .inactive_period = 250, Are you sure this is actually necessary? Every A5XX GPU is using the same value, but i have never tried with DRM_MSM_INACTIVE_PERIOD. This was the original patch https://lore.kernel.org/all/20180507224750.9383-1-jcro...@codeaurora.org/ where the inactive period was increased for a530. I cannot test suspend on msm8937 yet. The suspend here refers to device suspend, not system suspend. Adreno goes into device suspend every time you stop using it, i.e. after the rendering is done and there's no more work to do. I suppose a good test scenario here would be to keep running and closing kmscube in a rapid fashion and checking if the GPU starts crashing for unknown reasons (the dmesg would denote that) I can check on msm8953 with a506 maybe if a506 works fine with DRM_MSM_INACTIVE_PERIOD then a505 would be fine with it also. The more testing the merrier :) Konrad
Re: [PATCH] drm/msm/a6xx: Print SQE fw version
On 6/4/24 17:48, Rob Clark wrote:
From: Rob Clark
Add the SQE fw version to dmesg and devcoredump.
Signed-off-by: Rob Clark
---
drivers/gpu/drm/msm/adreno/a6xx_gpu.c | 32 +++--
drivers/gpu/drm/msm/adreno/a6xx_gpu.h | 1 +
drivers/gpu/drm/msm/adreno/a6xx_gpu_state.c | 2 ++
3 files changed, 33 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
b/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
index 56bfb228808d..5a2a005003c8 100644
--- a/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
+++ b/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
@@ -665,6 +665,32 @@ static int a7xx_cp_init(struct msm_gpu *gpu)
return a6xx_idle(gpu, ring) ? 0 : -EINVAL;
}
+static uint32_t get_ucode_version(const uint32_t *data)
+{
+ uint32_t version;
+
+ /* NOTE: compared to kgsl, we've already stripped off the first dword:
*/
+ version = data[0];
+
+ if ((version & 0xf) != 0xa)
+ return version;
+
+ version &= ~0xfff;
+ return version | ((data[2] & 0xfff000) >> 12);
double space
Some GENMASKy defines w/ FIELD_GET would be nice here..
[...]
+ DRM_DEV_INFO(>pdev->dev, "Have SQE version %03x\n", get_ucode_version(buf));
"SQE FW version: [...]" instead?
+
/* A7xx is safe! */
if (adreno_is_a7xx(adreno_gpu) || adreno_is_a702(adreno_gpu))
return true;
@@ -714,7 +742,7 @@ static bool a6xx_ucode_check_version(struct a6xx_gpu
*a6xx_gpu,
}
DRM_DEV_ERROR(>pdev->dev,
- "a630 SQE ucode is too old. Have version %x need at least
%x\n",
+ "a630 SQE ucode is too old. Have version %03x need at least
%03x\n",
buf[0] & 0xfff, 0x190);
This func should probably get updated to use the new getter too,
getting rid of magic masks for e.g.
if (FIELD_GET(SQE_FW_MINMAJ, ver) > 0x190)
foobarbaz
Konrad
Re: [PATCH] drm/msm/a6xx: Print SQE fw version
On 6/4/24 17:48, Rob Clark wrote:
From: Rob Clark
Add the SQE fw version to dmesg and devcoredump.
Signed-off-by: Rob Clark
---
drivers/gpu/drm/msm/adreno/a6xx_gpu.c | 32 +++--
drivers/gpu/drm/msm/adreno/a6xx_gpu.h | 1 +
drivers/gpu/drm/msm/adreno/a6xx_gpu_state.c | 2 ++
3 files changed, 33 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
b/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
index 56bfb228808d..5a2a005003c8 100644
--- a/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
+++ b/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
@@ -665,6 +665,32 @@ static int a7xx_cp_init(struct msm_gpu *gpu)
return a6xx_idle(gpu, ring) ? 0 : -EINVAL;
}
+static uint32_t get_ucode_version(const uint32_t *data)
+{
+ uint32_t version;
+
+ /* NOTE: compared to kgsl, we've already stripped off the first dword:
*/
+ version = data[0];
+
+ if ((version & 0xf) != 0xa)
+ return version;
+
+ version &= ~0xfff;
+ return version | ((data[2] & 0xfff000) >> 12);
double space
Some GENMASKy defines w/ FIELD_GET would be nice here..
[...]
+ DRM_DEV_INFO(>pdev->dev, "Have SQE version %03x\n", get_ucode_version(buf));
"SQE FW version: [...]" instead?
+
/* A7xx is safe! */
if (adreno_is_a7xx(adreno_gpu) || adreno_is_a702(adreno_gpu))
return true;
@@ -714,7 +742,7 @@ static bool a6xx_ucode_check_version(struct a6xx_gpu
*a6xx_gpu,
}
DRM_DEV_ERROR(>pdev->dev,
- "a630 SQE ucode is too old. Have version %x need at least
%x\n",
+ "a630 SQE ucode is too old. Have version %03x need at least
%03x\n",
buf[0] & 0xfff, 0x190);
This func should probably get updated to use the new getter too,
getting rid of magic masks for e.g.
if (FIELD_GET(SQE_FW_MINMAJ, ver) > 0x190)
foobarbaz
Konrad
Re: [PATCH 2/2] ARM: dts: qcom: Add initial support for HTC One (M8)
On 6/3/24 08:28, Alexandre Messier via B4 Relay wrote: From: Alexandre Messier Add initial device tree for the HTC One (M8) smartphone. Initial support includes: - eMMC - Power button - USB - Vibrator - Volume buttons (GPIO) - Wi-Fi Signed-off-by: Alexandre Messier --- Reviewed-by: Konrad Dybcio Konrad
Re: [PATCH] drm/msm/adreno: Add support for Adreno 505 GPU
On 6/4/24 02:20, Barnabás Czémán wrote: From: Daniil Titov This GPU is found on SoCs such as MSM8937 (450 MHz), MSM8940 (475 MHz), SDM439 (650 MHz). Signed-off-by: Daniil Titov Signed-off-by: Barnabás Czémán --- This all looks very good, just a nit [...] + /* +* Increase inactive period to 250 to avoid bouncing +* the GDSC which appears to make it grumpy +*/ + .inactive_period = 250, Are you sure this is actually necessary? Konrad
Re: [PATCH] drm/msm/adreno: Add support for Adreno 505 GPU
On 6/4/24 02:20, Barnabás Czémán wrote: From: Daniil Titov This GPU is found on SoCs such as MSM8937 (450 MHz), MSM8940 (475 MHz), SDM439 (650 MHz). Signed-off-by: Daniil Titov Signed-off-by: Barnabás Czémán --- This all looks very good, just a nit [...] + /* +* Increase inactive period to 250 to avoid bouncing +* the GDSC which appears to make it grumpy +*/ + .inactive_period = 250, Are you sure this is actually necessary? Konrad
[jira] [Updated] (MENFORCER-505) Wrong documentation for new requireMatchingCoordinates rules
[ https://issues.apache.org/jira/browse/MENFORCER-505?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Konrad Windszus updated MENFORCER-505: -- Labels: (was: up-for-grabs) > Wrong documentation for new requireMatchingCoordinates rules > > > Key: MENFORCER-505 > URL: https://issues.apache.org/jira/browse/MENFORCER-505 > Project: Maven Enforcer Plugin > Issue Type: Bug >Reporter: Michael Keppler > Assignee: Konrad Windszus >Priority: Minor > Fix For: next-release > > > There is a copy-paste error in > [https://github.com/apache/maven-enforcer/blob/f8430efe20020071273bab883cffb3a2e0f00107/enforcer-rules/src/site/apt/requireMatchingCoordinates.apt.vm#L65,] > where the closing tag does not match the opening tag. > See > [https://maven.apache.org/enforcer/enforcer-rules/requireMatchingCoordinates.html] > line 19 for the result. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (MENFORCER-505) Wrong documentation for new requireMatchingCoordinates rules
[ https://issues.apache.org/jira/browse/MENFORCER-505?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Konrad Windszus resolved MENFORCER-505. --- Fix Version/s: next-release Resolution: Fixed > Wrong documentation for new requireMatchingCoordinates rules > > > Key: MENFORCER-505 > URL: https://issues.apache.org/jira/browse/MENFORCER-505 > Project: Maven Enforcer Plugin > Issue Type: Bug >Reporter: Michael Keppler > Assignee: Konrad Windszus >Priority: Minor > Labels: up-for-grabs > Fix For: next-release > > > There is a copy-paste error in > [https://github.com/apache/maven-enforcer/blob/f8430efe20020071273bab883cffb3a2e0f00107/enforcer-rules/src/site/apt/requireMatchingCoordinates.apt.vm#L65,] > where the closing tag does not match the opening tag. > See > [https://maven.apache.org/enforcer/enforcer-rules/requireMatchingCoordinates.html] > line 19 for the result. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (MENFORCER-505) Wrong documentation for new requireMatchingCoordinates rules
[ https://issues.apache.org/jira/browse/MENFORCER-505?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Konrad Windszus reassigned MENFORCER-505: - Assignee: Konrad Windszus > Wrong documentation for new requireMatchingCoordinates rules > > > Key: MENFORCER-505 > URL: https://issues.apache.org/jira/browse/MENFORCER-505 > Project: Maven Enforcer Plugin > Issue Type: Bug >Reporter: Michael Keppler > Assignee: Konrad Windszus >Priority: Minor > Labels: up-for-grabs > > There is a copy-paste error in > [https://github.com/apache/maven-enforcer/blob/f8430efe20020071273bab883cffb3a2e0f00107/enforcer-rules/src/site/apt/requireMatchingCoordinates.apt.vm#L65,] > where the closing tag does not match the opening tag. > See > [https://maven.apache.org/enforcer/enforcer-rules/requireMatchingCoordinates.html] > line 19 for the result. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[OE-core] [PATCH] insane: error out on UNPACKDIR = WORKDIR
as this will clear WORKDIR and create race conditions
across various handling tasks
Signed-off-by: Konrad Weihmann
---
meta/classes-global/insane.bbclass | 3 +++
1 file changed, 3 insertions(+)
diff --git a/meta/classes-global/insane.bbclass
b/meta/classes-global/insane.bbclass
index 99736830b9..32d3d7637a 100644
--- a/meta/classes-global/insane.bbclass
+++ b/meta/classes-global/insane.bbclass
@@ -1605,10 +1605,13 @@ python () {
sourcedir = d.getVar("S")
builddir = d.getVar("B")
workdir = d.getVar("WORKDIR")
+unpackdir = d.getVar("UNPACKDIR")
if sourcedir == workdir:
bb.fatal("Using S = ${WORKDIR} is no longer supported")
if builddir == workdir:
bb.fatal("Using B = ${WORKDIR} is no longer supported")
+if unpackdir == workdir:
+bb.fatal("Using UNPACKDIR = ${WORKDIR} is not supported")
if sourcedir[-1] == '/':
bb.warn("Recipe %s sets S variable with trailing slash '%s', remove
it" % (d.getVar("PN"), d.getVar("S")))
if builddir[-1] == '/':
--
2.34.1
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#200094):
https://lists.openembedded.org/g/openembedded-core/message/200094
Mute This Topic: https://lists.openembedded.org/mt/106423265/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
Re: [PATCH v3 1/3] arm64: dts: qcom: pm7250b: Add node for PMIC VBUS booster
On 30.05.2024 5:05 PM, Luca Weiss wrote: > Add the required DTS node for the USB VBUS output regulator, which is > available on PM7250B. This will provide the VBUS source to connected > peripherals. > > Reviewed-by: Bryan O'Donoghue > Signed-off-by: Luca Weiss > --- Reviewed-by: Konrad Dybcio Konrad
Re: [PATCH 1/5] dt-bindings: remoteproc: qcom,sm8550-pas: Document the SA8775p ADSP, CDSP and GPDSP
On 22.05.2024 3:08 PM, Bartosz Golaszewski wrote: > On Wed, May 22, 2024 at 3:06 PM wrote: >> >> On 22/05/2024 15:04, Bartosz Golaszewski wrote: >>> On Wed, May 22, 2024 at 2:42 PM wrote: >>>> >>>> On 22/05/2024 14:08, Bartosz Golaszewski wrote: >>>>> From: Tengfei Fan >>>>> >>>>> Document the compatibles for the components used to boot the ADSP, CDSP0, >>>>> CDSP1, GPDSP0 and GPDSP1 on the SA8775p SoC. >>>>> >>>>> Signed-off-by: Tengfei Fan >>>>> Co-developed-by: Bartosz Golaszewski >>>>> Signed-off-by: Bartosz Golaszewski >>>>> --- >>>>>.../bindings/remoteproc/qcom,sm8550-pas.yaml | 76 >>>>> +- >>>>>1 file changed, 75 insertions(+), 1 deletion(-) >>>>> >>>>> diff --git >>>>> a/Documentation/devicetree/bindings/remoteproc/qcom,sm8550-pas.yaml >>>>> b/Documentation/devicetree/bindings/remoteproc/qcom,sm8550-pas.yaml >>>>> index 73fda7565cd1..9d3a862c39e1 100644 >>>>> --- a/Documentation/devicetree/bindings/remoteproc/qcom,sm8550-pas.yaml >>>>> +++ b/Documentation/devicetree/bindings/remoteproc/qcom,sm8550-pas.yaml >>>>> @@ -16,6 +16,11 @@ description: >>>>>properties: >>>>> compatible: >>>>>enum: >>>>> + - qcom,sa8775p-adsp-pas >>>>> + - qcom,sa8775p-cdsp0-pas >>>>> + - qcom,sa8775p-cdsp1-pas >>>>> + - qcom,sa8775p-gpdsp0-pas >>>>> + - qcom,sa8775p-gpdsp1-pas >>>>> - qcom,sm8550-adsp-pas >>>>> - qcom,sm8550-cdsp-pas >>>>> - qcom,sm8550-mpss-pas >>>>> @@ -44,12 +49,13 @@ properties: >>>>> >>>>> firmware-name: >>>>>$ref: /schemas/types.yaml#/definitions/string-array >>>>> +minItems: 1 >>>> >>>> This will allow a single firmware name for all compatible, >>>> which is wrong >>>> >>> >>> So increasing the limit from the default under allOf doesn't seem to >>> work, should I instead keep this and make the lower limit stricter for >>> all other models? >> >> Yes add minItems in all the allOf:if: and add the missing allOf:if: for >> the new compatibles to set the minItems, same for memory-region. >> >> Or you may simply spin off a new yaml, this one is getting quite large. >> > > Yeah, maybe that's a better idea. + if you get rid of the 0/1 in "nsp0/nsp1" you save a couple more lines Konrad
[jira] [Commented] (SLING-12331) Update sling maven plugins to maven 3.8.x
[
https://issues.apache.org/jira/browse/SLING-12331?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17850329#comment-17850329
]
Konrad Windszus commented on SLING-12331:
-
The proper fix is to change the Maven dependencies provided by the Maven
distribution to scope {{provided}}. That way they are no longer downloaded (for
no reason). Compare with https://issues.apache.org/jira/browse/MPLUGIN-370.
> Update sling maven plugins to maven 3.8.x
> -
>
> Key: SLING-12331
> URL: https://issues.apache.org/jira/browse/SLING-12331
> Project: Sling
> Issue Type: Improvement
> Components: Maven Plugins and Archetypes
>Reporter: Dirk Rudolph
>Priority: Major
>
> We recently got some security vulnerability reported related to maven-core,
> which is a transitive dependency used in many / some of the sling maven
> plugins.
> While maven-core is always take from the maven installation in the current
> version, the vulnerable jars are downloaded when using the plugins, and hence
> found and reported by security scanners.
> We should update our maven plugins to use the 3.8.x version of maven at least.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
Re: [PATCH] drm/msm/adreno: Add A306A support
On 28.05.2024 9:43 PM, Barnabás Czémán wrote:
> From: Otto Pflüger
>
> Add support for Adreno 306A GPU what is found in MSM8917 SoC.
> This GPU marketing name is Adreno 308.
>
> Signed-off-by: Otto Pflüger
> [use internal name of the GPU, reword the commit message]
> Signed-off-by: Barnabás Czémán
> ---
[...]
>
> +static inline bool adreno_is_a306a(const struct adreno_gpu *gpu)
> +{
> + /* a306a marketing name is a308 */
> + return adreno_is_revn(gpu, 308);
> +}
The .c changes look good. Rob, do we still want .rev nowadays?
Re: [PATCH] drm/msm/adreno: Add A306A support
On 28.05.2024 9:43 PM, Barnabás Czémán wrote:
> From: Otto Pflüger
>
> Add support for Adreno 306A GPU what is found in MSM8917 SoC.
> This GPU marketing name is Adreno 308.
>
> Signed-off-by: Otto Pflüger
> [use internal name of the GPU, reword the commit message]
> Signed-off-by: Barnabás Czémán
> ---
[...]
>
> +static inline bool adreno_is_a306a(const struct adreno_gpu *gpu)
> +{
> + /* a306a marketing name is a308 */
> + return adreno_is_revn(gpu, 308);
> +}
The .c changes look good. Rob, do we still want .rev nowadays?
[plasmashell] [Bug 486260] When the panel's floating mode is disabled, the system tray applets (nm-applet, clipper) do not work.
https://bugs.kde.org/show_bug.cgi?id=486260 Konrad Materka changed: What|Removed |Added Resolution|WORKSFORME |DUPLICATE --- Comment #4 from Konrad Materka --- *** This bug has been marked as a duplicate of bug 485456 *** -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 485456] With Qt 6.7, System Tray popup is inappropriately resized to a tiny nub
https://bugs.kde.org/show_bug.cgi?id=485456 Konrad Materka changed: What|Removed |Added CC||jimmbird2...@gmail.com --- Comment #38 from Konrad Materka --- *** Bug 486260 has been marked as a duplicate of this bug. *** -- You are receiving this mail because: You are watching all bug changes.
[jira] [Commented] (MNG-5726) Update OS Activation To Allow Wildcards In OS Version
[
https://issues.apache.org/jira/browse/MNG-5726?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17849549#comment-17849549
]
Konrad Windszus commented on MNG-5726:
--
[~sjaranowski] I did that already. What exactly are you missing?
> Update OS Activation To Allow Wildcards In OS Version
> -
>
> Key: MNG-5726
> URL: https://issues.apache.org/jira/browse/MNG-5726
> Project: Maven
> Issue Type: New Feature
> Components: Profiles
>Affects Versions: 3.1.1, 3.2.3
> Environment: RHEL/CentOs
>Reporter: Andy Lehane
>Assignee: Konrad Windszus
>Priority: Minor
> Fix For: 3.9.7, 4.0.0-alpha-13, 4.0.0
>
> Attachments: maven-os-version-patch-3.2.3.zip
>
>
> I'm attempting to use maven to build a legacy project that requires different
> dependecies based on the operating system version, i.e:
> - version 1.0 of "a platform specific library" for Red Hat Linux 5
> - version 1.1 of "a platform specific library" for Red Hat Linux 6
> - version 1.4a of "a platform specific library" for Windows and
> - version 1.3b of (a platform specific library" for Solaris.
> I can configure my pom file to get activate specific profiles for RHEL, Win
> and Solaris but cannot distinguish between Red Hat 5 and 6 unless I use the
> full version string, which is of the form "2.6.32-504.1.3.el6.x86_64".
> As this Linux version will change whenever patch updates are installed, this
> will make maintaining the pom/project akward.
> To solve this, it would be good to be able to specify wildcard's in the os
> version tag. I have taken a look at the range checking (for example, as
> applied to the JdkVersion), but don't think this method would be sufficient,
> as the specific part of the Red Hat version number we require is buried over
> half way into the version string (i.e. "el6" of the version
> "2.6.32-504.1.3.el6.x86_64").
> It would be nice to be able to have something like:
> {code}
>
> linux-rhel5
>
> false
>
> unix
> Linux
> *el5*
>
>
>
> .
> {code}
> I've taken a look at the OperatingSystemProfileActivator code and have
> created a patch that will use ^ to signify that the text is a regular
> expression, for example:
> {code}
> ^.*(el5).*
> {code}
> I've also kept the ! notation, so the following can also be used:
> {code}
> !^.*(el5).*
> {code}
> The patch added contains a unit test for the OperatingSystemProfileActivator
> in the maven-model-builder project (warning: it's a nasty test but I couldn't
> find a nicer way of being able to reliably manuplate the OS Version).
> I've also patch the OperatingSystemProfileActivator class in the maven-compat
> project but have not been able to write a unit test for that class.
> Can this updated be considered for implementation/inclusion please?
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
Re: [PATCH] drm/msm/dpu: drop duplicate drm formats from wb2_formats arrays
On 24.05.2024 5:01 PM, Junhao Xie wrote: > There are duplicate items in wb2_formats_rgb and wb2_formats_rgb_yuv, > which cause weston assertions failed. > > weston: libweston/drm-formats.c:131: weston_drm_format_array_add_format: > Assertion `!weston_drm_format_array_find_format(formats, format)' failed. > > Signed-off-by: Junhao Xie > --- Reviewed-by: Konrad Dybcio Konrad
Re: [PATCH] drm/msm/dpu: drop duplicate drm formats from wb2_formats arrays
On 24.05.2024 5:01 PM, Junhao Xie wrote: > There are duplicate items in wb2_formats_rgb and wb2_formats_rgb_yuv, > which cause weston assertions failed. > > weston: libweston/drm-formats.c:131: weston_drm_format_array_add_format: > Assertion `!weston_drm_format_array_find_format(formats, format)' failed. > > Signed-off-by: Junhao Xie > --- Reviewed-by: Konrad Dybcio Konrad
[plasmashell] [Bug 425271] XembedSNIProxy causes "high" cpu usage with certain screen arrangements
https://bugs.kde.org/show_bug.cgi?id=425271 Konrad Materka changed: What|Removed |Added Version Fixed In||6.1 -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 425271] XembedSNIProxy causes "high" cpu usage with certain screen arrangements
https://bugs.kde.org/show_bug.cgi?id=425271 Konrad Materka changed: What|Removed |Added Status|ASSIGNED|RESOLVED Latest Commit||https://invent.kde.org/plas ||ma/plasma-workspace/-/commi ||t/efecf88d2d77d8f4cd94edb3a ||83d10deb16a1e92 Resolution|--- |FIXED --- Comment #56 from Konrad Materka --- Git commit efecf88d2d77d8f4cd94edb3a83d10deb16a1e92 by Konrad Materka. Committed on 23/05/2024 at 12:34. Pushed by kmaterka into branch 'master'. xembedsniproxy: Fix high CPU usage when 0,0 is off-screen Reverts 69786a1ff94718daf4de2d814037e70df079ec97, which is no longer needed after 50bbe56bb08f9b265ad56510e2adc37db66f4d2d Initial workaround for Bug 357443 tries to detect and fix window stacking issues (for example after compositor restart). Unfortunately, it causes infinite loop when (0,0) position (were windows are originally positioned) is off-screen (this can happen in some less commonmulti-screen setups). Proper fix was added in !4324, so that faulty workaround is no longer needed. M +0-9xembed-sni-proxy/fdoselectionmanager.cpp M +1-14 xembed-sni-proxy/sniproxy.cpp M +0-2xembed-sni-proxy/sniproxy.h https://invent.kde.org/plasma/plasma-workspace/-/commit/efecf88d2d77d8f4cd94edb3a83d10deb16a1e92 -- You are receiving this mail because: You are watching all bug changes.
[jira] [Commented] (SLING-12322) Stream Reader should Return SC_OK if content length is less than specified range
[
https://issues.apache.org/jira/browse/SLING-12322?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17848818#comment-17848818
]
Konrad Windszus commented on SLING-12322:
-
I don’t think this is compliant with
https://datatracker.ietf.org/doc/html/rfc7233#section-4.1. What actual issue
are you trying to solve?
> Stream Reader should Return SC_OK if content length is less than specified
> range
>
>
> Key: SLING-12322
> URL: https://issues.apache.org/jira/browse/SLING-12322
> Project: Sling
> Issue Type: Bug
> Components: Servlets
>Affects Versions: Servlets Get 2.2.0
>Reporter: Abhishek Garg
>Priority: Major
>
> if the Request contains following header :
> {code:java}
> Range: bytes=0-8388607 {code}
> and file length is less than this, then we should return SC_OK(200) instead
> of
> SC_PARTIAL_CONTENT(206).
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
Instalacja pv
Dzień dobry, czy są Państwo otwarci na niezobowiązującą rozmowę na temat fotowoltaiki? Jako firma specjalizująca się w instalacji i serwisie najlepszych jakościowo paneli słonecznych na rynku chciałbym przedstawić propozycję, jaką wspólnie z zespołem przygotowaliśmy dla Państwa obiektu. Będę wdzięczny za wiadomość od Państwa czy możemy porozmawiać. Pozdrawiam Konrad Zieliński
[plasmashell] [Bug 487187] When any window is full screened, the drop down menu of any component stops displaying
https://bugs.kde.org/show_bug.cgi?id=487187 Konrad Materka changed: What|Removed |Added Resolution|--- |WAITINGFORINFO Status|REPORTED|NEEDSINFO --- Comment #2 from Konrad Materka --- Hi, this is possibly a duplicate of Bug 485456. Are you using Wayland? Do you see tiny nub were popup should appear? -- You are receiving this mail because: You are watching all bug changes.
[jira] [Updated] (MNG-8097) Validate that each dependency->type is a type registered in an artifact handler
[
https://issues.apache.org/jira/browse/MNG-8097?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Konrad Windszus updated MNG-8097:
-
Description:
Currently often the dependency's type is being set to the extension and the
resolution is lenient, i.e. if there is no artifact handler defining the value
given in {{dependency->type}} resolution transparently uses the type as
extension.
That can potentially lead to two issues:
1. Resolution might fail with surprising error messages like
{code}
Could not resolve dependencies for project : The following artifacts could
not be resolved: : Could not transfer artifact
::: from/to ...
{code}
This is an issue for all types not defined by Maven Core itself, e.g. for
https://jackrabbit.apache.org/filevault-package-maven-plugin/index.html which
registers an artifact handler for type {{content-package}} with extension
{{zip}}.
2. The information {{addedToClasspath}}, {{includesDependencies}} and
{{classifier}} from the artifact handler is not evaluated
Compare with
https://maven.apache.org/repositories/artifacts.html#but-where-do-i-set-artifact-extension
was:
Currently often the dependency's type is being set to the extension and the
resolution is lenient, i.e. if there is no artifact handler defining the value
given in {{dependency->type}} resolution transparently uses the type as
extension.
That can potentially lead to two issues:
1. Resolution might fail with surprising error messages like
{code}
Could not resolve dependencies for project : The following artifacts could
not be resolved: : Could not transfer artifact
::: from/to ...
{code}
This is an issue for all types not defined by Maven Core itself, e.g. for
https://jackrabbit.apache.org/filevault-package-maven-plugin/index.html which
registers an artifact handler for type {{content-package}} with extension
{{zip}}.
2. The information {{addedToClasspath}}, {{includesDependencies}} and
{{classifier}} from the artifact handler is not evaluated
> Validate that each dependency->type is a type registered in an artifact
> handler
> ---
>
> Key: MNG-8097
> URL: https://issues.apache.org/jira/browse/MNG-8097
> Project: Maven
> Issue Type: New Feature
>Reporter: Konrad Windszus
>Priority: Major
>
> Currently often the dependency's type is being set to the extension and the
> resolution is lenient, i.e. if there is no artifact handler defining the
> value given in {{dependency->type}} resolution transparently uses the type as
> extension.
> That can potentially lead to two issues:
> 1. Resolution might fail with surprising error messages like
> {code}
> Could not resolve dependencies for project : The following artifacts
> could not be resolved: : Could not transfer artifact
> ::: from/to ...
> {code}
> This is an issue for all types not defined by Maven Core itself, e.g. for
> https://jackrabbit.apache.org/filevault-package-maven-plugin/index.html which
> registers an artifact handler for type {{content-package}} with extension
> {{zip}}.
> 2. The information {{addedToClasspath}}, {{includesDependencies}} and
> {{classifier}} from the artifact handler is not evaluated
> Compare with
> https://maven.apache.org/repositories/artifacts.html#but-where-do-i-set-artifact-extension
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Closed] (MNG-8050) Same repositories IDs in settings.xml and POM are not detected
[
https://issues.apache.org/jira/browse/MNG-8050?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Konrad Windszus closed MNG-8050.
> Same repositories IDs in settings.xml and POM are not detected
> --
>
> Key: MNG-8050
> URL: https://issues.apache.org/jira/browse/MNG-8050
> Project: Maven
> Issue Type: Improvement
>Reporter: Konrad Windszus
> Assignee: Konrad Windszus
>Priority: Major
> Fix For: 4.0.0, 4.0.0-beta-3
>
>
> When the same repository ID is used in repositories defined in
> # {{settings.xml}} and
> # POM
> the one from the POM is just silently ignored and no ERROR is emitted.
> OTOH when defining repositories with the same ID in POM the following error
> is emitted:
> {code}
> [ERROR] Some problems were encountered while processing the POMs:
> [ERROR] 'repositories.repository.id' must be unique
> {code}
> A similar error should be emitted for repository ID clashes in
> {{settings.xml}} (both local and global) and POM
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Resolved] (MNG-8050) Same repositories IDs in settings.xml and POM are not detected
[
https://issues.apache.org/jira/browse/MNG-8050?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Konrad Windszus resolved MNG-8050.
--
Fix Version/s: 4.0.0
4.0.0-beta-3
Resolution: Fixed
Fixed in
https://github.com/apache/maven/commit/ac80eeabc4cf28199cf65cb58b27eae590b3d16a.
> Same repositories IDs in settings.xml and POM are not detected
> --
>
> Key: MNG-8050
> URL: https://issues.apache.org/jira/browse/MNG-8050
> Project: Maven
> Issue Type: Improvement
>Reporter: Konrad Windszus
> Assignee: Konrad Windszus
>Priority: Major
> Fix For: 4.0.0, 4.0.0-beta-3
>
>
> When the same repository ID is used in repositories defined in
> # {{settings.xml}} and
> # POM
> the one from the POM is just silently ignored and no ERROR is emitted.
> OTOH when defining repositories with the same ID in POM the following error
> is emitted:
> {code}
> [ERROR] Some problems were encountered while processing the POMs:
> [ERROR] 'repositories.repository.id' must be unique
> {code}
> A similar error should be emitted for repository ID clashes in
> {{settings.xml}} (both local and global) and POM
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[plasmashell] [Bug 433079] On Wayland container windows created by XEmbedSNIProxy are not stacked below root window
https://bugs.kde.org/show_bug.cgi?id=433079 Konrad Materka changed: What|Removed |Added CC||e...@horse64.org --- Comment #39 from Konrad Materka --- *** Bug 487166 has been marked as a duplicate of this bug. *** -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 487166] Sometimes clicking a tray icon will invoke the menu of a completely different tray icon
https://bugs.kde.org/show_bug.cgi?id=487166 Konrad Materka changed: What|Removed |Added Status|REPORTED|RESOLVED Resolution|--- |DUPLICATE --- Comment #3 from Konrad Materka --- Yes, it's the same issue. Thank you for your report! *** This bug has been marked as a duplicate of bug 433079 *** -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 487127] Tray icons perhaps shouldn't be locked to "Always visible" (probably design issue? or not sure)
https://bugs.kde.org/show_bug.cgi?id=487127 Konrad Materka changed: What|Removed |Added Status|NEEDSINFO |RESOLVED Resolution|WAITINGFORINFO |INTENTIONAL --- Comment #3 from Konrad Materka --- "Always show all entries" does what it says - it makes all icons always visible in tray and never hides them in "hidden" section. If you want mixed mode, so some icons are always hidden, some are always visible and other hides when not needed then you can set each item manually. By default Plasma hides icons that are not needed, for example "Notifications" is shown only when they are notification, "Clipboard" only when there is something in the clipboard etc. This is controlled by the app that creates tray icon, but you can always overwrite default behavior. Closing bug as it works as intended. -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 487166] Sometimes clicking a tray icon will invoke the menu of a completely different tray icon
https://bugs.kde.org/show_bug.cgi?id=487166 --- Comment #1 from Konrad Materka --- Are you using Wayland? Is Bug 433079 related? -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 487127] Tray icons perhaps shouldn't be locked to "Always visible" (probably design issue? or not sure)
https://bugs.kde.org/show_bug.cgi?id=487127 Konrad Materka changed: What|Removed |Added Status|REPORTED|NEEDSINFO Resolution|--- |WAITINGFORINFO --- Comment #1 from Konrad Materka --- Have you checked the "Always show all entries" option at the bottom? In this case, this is expected behavior. -- You are receiving this mail because: You are watching all bug changes.
[jira] [Assigned] (SLING-12319) JcrResourceListener should expose the JCR Event's getIdentifier()
[ https://issues.apache.org/jira/browse/SLING-12319?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Konrad Windszus reassigned SLING-12319: --- Assignee: (was: Konrad Windszus) > JcrResourceListener should expose the JCR Event's getIdentifier() > - > > Key: SLING-12319 > URL: https://issues.apache.org/jira/browse/SLING-12319 > Project: Sling > Issue Type: Improvement > Components: JCR >Reporter: Mark Adamcin >Priority: Major > > The JcrResourceChange > ([https://github.com/apache/sling-org-apache-sling-jcr-resource/blob/daa4777ba63264b940e6b9b64df24189828ccd17/src/main/java/org/apache/sling/jcr/resource/api/JcrResourceChange.java#L31] > ) should expose the value of the JCR Event's getIdentifier() method, which > is otherwise read in case it contains a path, but ultimately discarded: > [https://github.com/apache/sling-org-apache-sling-jcr-resource/blob/daa4777ba63264b940e6b9b64df24189828ccd17/src/main/java/org/apache/sling/jcr/resource/internal/JcrResourceListener.java#L116] > > The use case for this is primarily to expose the jcr:uuid of deleted > mix:referenceable nodes to listeners, because once the node is deleted, the > jcr:uuid property can no longer be accessed by the event path. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (JCRVLT-754) check-release does not work for filevault anymore
[ https://issues.apache.org/jira/browse/JCRVLT-754?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17846855#comment-17846855 ] Konrad Windszus commented on JCRVLT-754: bq. no sha1 is generated anymore; however, this is what is put into the generated vote template. The SHA1 is generated, but no longer persisted. It is used in the email template: https://github.com/apache/jackrabbit-filevault/pull/331/files#diff-9c5fb3d1b7e3b0f54bc5c4182965c4fe1f9023d449017cece3005d3f90e8e4d8R300 > check-release does not work for filevault anymore > - > > Key: JCRVLT-754 > URL: https://issues.apache.org/jira/browse/JCRVLT-754 > Project: Jackrabbit FileVault > Issue Type: Task >Reporter: Julian Reschke > Assignee: Konrad Windszus >Priority: Major > Fix For: 3.7.4 > > > Since https://issues.apache.org/jira/browse/JCRVLT-742, no sha1 is generated > anymore; however, this is what is put into the generated vote template. > The proper fix likely would be to put the SHA512 checksum into the vote > template. > Furthermore, the basename of the source artefact changed from"src" to > "source-release". This needs to be adjusted in the check script. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (JCRVLT-742) Stop generating MD5, SHA1 and SHA512 with Ant
[ https://issues.apache.org/jira/browse/JCRVLT-742?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17846854#comment-17846854 ] Konrad Windszus commented on JCRVLT-742: FTR: The SHA1 is still generated and used in the email template being generated, but no longer persisted as file: https://github.com/apache/jackrabbit-filevault/pull/331/files#diff-9c5fb3d1b7e3b0f54bc5c4182965c4fe1f9023d449017cece3005d3f90e8e4d8R300 > Stop generating MD5, SHA1 and SHA512 with Ant > - > > Key: JCRVLT-742 > URL: https://issues.apache.org/jira/browse/JCRVLT-742 > Project: Jackrabbit FileVault > Issue Type: Improvement > Components: package maven plugin > Reporter: Konrad Windszus >Assignee: Konrad Windszus >Priority: Major > Fix For: 3.7.4, package-maven-plugin-1.3.8 > > > Currently there is still manual generation of MD5, SHA1 and SHA512 checksum > via Ant in > https://github.com/apache/jackrabbit-filevault/blob/3c9f668fc608c815db154b2569bf16c71f668428/pom.xml#L325-L340 > and > https://github.com/apache/jackrabbit-filevault-package-maven-plugin/blob/c0433155e825130d1c9a435f5fb837af8e9c46d4/pom.xml#L744-L759. > MD5 and SHA1 should no longer be provided according to > https://infra.apache.org/release-distribution.html#sigs-and-sums and SHA512 > is automatically created through the ASF parent pom > (https://maven.apache.org/pom/asf/#the-apache-release-profile). > In https://jackrabbit.apache.org/jcr/downloads.html#vlt we only link the > SHA512 anyways. > Note: This is only about ASF dist not about the checksums used in Maven > repositories which are transparently created by Maven Resolver. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (JCRVLT-754) check-release does not work for filevault anymore
[ https://issues.apache.org/jira/browse/JCRVLT-754?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Konrad Windszus reassigned JCRVLT-754: -- Assignee: Konrad Windszus > check-release does not work for filevault anymore > - > > Key: JCRVLT-754 > URL: https://issues.apache.org/jira/browse/JCRVLT-754 > Project: Jackrabbit FileVault > Issue Type: Task >Reporter: Julian Reschke > Assignee: Konrad Windszus >Priority: Major > Fix For: 3.7.4 > > > Since https://issues.apache.org/jira/browse/JCRVLT-742, no sha1 is generated > anymore; however, this is what is put into the generated vote template. > The proper fix likely would be to put the SHA512 checksum into the vote > template. > Furthermore, the basename of the source artefact changed from"src" to > "source-release". This needs to be adjusted in the check script. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (JCRVLT-753) FORCE_REMOVE_CONFLICTING_ID Strategy Causing Constraint Violation Exception in AEM Replication
[
https://issues.apache.org/jira/browse/JCRVLT-753?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17846849#comment-17846849
]
Konrad Windszus commented on JCRVLT-753:
We should at least clarify the javadoc of
https://jackrabbit.apache.org/filevault/apidocs/org/apache/jackrabbit/vault/fs/api/IdConflictPolicy.html
to make it clear that {{FORCE_REMOVE_CONFLICTING_ID}} may lead to exceptions
as well.
> FORCE_REMOVE_CONFLICTING_ID Strategy Causing Constraint Violation Exception
> in AEM Replication
> --
>
> Key: JCRVLT-753
> URL: https://issues.apache.org/jira/browse/JCRVLT-753
> Project: Jackrabbit FileVault
> Issue Type: Bug
> Components: vlt
>Reporter: Danilo Banjac
>Assignee: Konrad Windszus
>Priority: Major
> Labels: vault
>
> {*}Issue Description{*}:
> Recent updates to the replication conflict resolution strategy in Adobe
> Experience Manager (AEM) using JCR Filevault have led to failures when
> attempting to replicate content packages. Specifically, the shift from the
> *LEGACY* to the *FORCE_REMOVE_CONFLICTING_ID* strategy causes
> *javax.jcr.nodetype.ConstraintViolationException: OakConstraint0026* due to
> the attempted deletion of mandatory child nodes during the replication
> process.
> {*}Steps to Reproduce{*}:
> 1. Create a content package with a primary node of type *nt:file* and a
> mandatory child node {*}jcr:content{*}.
> 2. Update the version of the content package, ensuring the *jcr:uuid* of the
> *jcr:content* node remains unchanged.
> 3. Replicate the updated content package.
> {*}Observed Behavior{*}:
> - The replication framework attempts to remove the conflicting *jcr:content*
> node due to the identical {*}jcr:uuid{*}.
> - The deletion operation fails because the parent *nt:file* node requires the
> *jcr:content* child node, resulting in a {*}ConstraintViolationException{*}:
> "{*}Mandatory child node jcr:content cannot be removed.{*}"
> {*}Root Cause{*}:
> The *FORCE_REMOVE_CONFLICTING_ID* conflict resolution strategy does not
> account for the constraints of mandatory child nodes in the JCR repository,
> leading to violations when trying to remove these nodes.
> {*}Impact{*}:
> This issue prevents successful replication of updated content packages in
> AEM, disrupting content management workflows and generating errors in the log.
> *Nodes Used for Testing*
> {noformat}
> {
> "jcr:primaryType": "nt:file",
> "jcr:createdBy": "sling-distribution-importer",
> "jcr:created": "Tue May 14 2024 10:13:41 GMT+",
> "jcr:content": {
> "jcr:primaryType": "nt:resource",
> "jcr:mixinTypes": [
> "vlt:Package"
> ],
> "jcr:lastModifiedBy": "admin",
> "jcr:mimeType": "application/zip",
> "jcr:lastModified": "Tue May 14 2024 10:13:32 GMT+",
> ":jcr:data": 35146,
> "jcr:uuid": "cef51ff7-f3fc-4a41-b765-ca4ceb4246ce",
> "vlt:definition": {
> "jcr:primaryType": "vlt:PackageDefinition",
> "testedWith": "",
> "lastUnpacked": "Tue May 14 2024 10:13:41 GMT+",
> "lastUnpackedBy": "sling-distribution-importer",
> "requiresRestart": false,
> "requiresRoot": false,
> "lastWrapped": "Fri Apr 26 2024 12:27:44 GMT+",
> "buildCount": "17",
> "providerLink": "",
> "providerName": "",
> "jcr:created": "Fri Apr 26 2024 12:27:44 GMT+",
> "name": "global-truststore",
> "group": "admin-tasks",
> "version": "15.0",
> "dependencies": [],
> "fixedBugs": "",
> "jcr:lastModified": "Fri Apr 26 2024 12:27:44 GMT+",
> "lastUnwrapped": "Tue May 14 2024 10:13:32 GMT+",
> "providerUrl": "",
> "screenshots": {
> "jcr:primaryType": "nt:unstructured"
> },
> "filter": {
> "jcr:primaryType": "nt:unstructured",
> "f0": {
> "jcr:primaryType": "nt:unstructured",
> "propertyRules": [],
> "mode": "replace",
> "root": "/etc/truststore",
> "rules": []
> }
> }
> }
> }
> }{noformat}
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Comment Edited] (MNG-7375) Potential NPE in o.a.m.artifact.repository.metadata.Metadata.merge(...) with invalid/incomplete plugin metadata
[
https://issues.apache.org/jira/browse/MNG-7375?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17846728#comment-17846728
]
Konrad Windszus edited comment on MNG-7375 at 5/15/24 6:15 PM:
---
Although true, this is due to a limitation in modello:
https://github.com/codehaus-plexus/modello/blob/8467ab87f95557c8c6409f5ebe613caf240836b3/modello-plugins/modello-plugin-xsd/src/main/java/org/codehaus/modello/plugin/xsd/XsdGenerator.java#L245-L247
Compare with
https://github.com/apache/maven/blob/maven-3.9.x/maven-plugin-api/src/main/mdo/plugin.mdo#L75-L80
was (Author: kwin):
Although true, this is due to a limitation in modello:
https://github.com/codehaus-plexus/modello/blob/8467ab87f95557c8c6409f5ebe613caf240836b3/modello-plugins/modello-plugin-xsd/src/main/java/org/codehaus/modello/plugin/xsd/XsdGenerator.java#L245-L247
> Potential NPE in o.a.m.artifact.repository.metadata.Metadata.merge(...) with
> invalid/incomplete plugin metadata
> ---
>
> Key: MNG-7375
> URL: https://issues.apache.org/jira/browse/MNG-7375
> Project: Maven
> Issue Type: Improvement
> Components: Artifacts and Repositories
>Affects Versions: 3.8.4
>Reporter: Konrad Windszus
>Priority: Major
> Attachments: NEXUS-30749 - Broken groupId metadata and follow-up NPE
> during
> org.sonatype.nexus.maven.staging.deploy.strategy.AbstractDeployStrategy.deployUp
> - Sonatype JIRA.pdf
>
>
> Currently the metadata at
> https://repository.apache.org/service/local/repositories/snapshots/content/org/apache/jackrabbit/maven-metadata.xml
> contains an invalid entry without a prefix:
> {code:xml}
>
>
>
> Apache Jackrabbit FileVault - Package Maven Plugin
> filevault-package
> filevault-package-maven-plugin
>
>
> filevault-package-maven-plugin
> filevault-package-maven-plugin
>
>
>
> {code}
> This leads to an NPE when trying to deploy a new version with
> {{org.apache.maven.artifact.deployer.DefaultArtifactDeployer.deploy(...)}}:
> {noformat}
> Caused by: java.lang.NullPointerException
> at org.apache.maven.artifact.repository.metadata.Metadata.merge
> (Metadata.java:276)
> at
> org.apache.maven.artifact.repository.metadata.AbstractRepositoryMetadata.updateRepositoryMetadata
> (AbstractRepositoryMetadata.java:121)
> at
> org.apache.maven.artifact.repository.metadata.AbstractRepositoryMetadata.storeInLocalRepository
> (AbstractRepositoryMetadata.java:67)
> at org.apache.maven.artifact.repository.metadata.MetadataBridge.merge
> (MetadataBridge.java:65)
> at org.eclipse.aether.internal.impl.DefaultDeployer.upload
> (DefaultDeployer.java:433)
> at org.eclipse.aether.internal.impl.DefaultDeployer.deploy
> (DefaultDeployer.java:321)
> at org.eclipse.aether.internal.impl.DefaultDeployer.deploy
> (DefaultDeployer.java:213)
> at org.eclipse.aether.internal.impl.DefaultRepositorySystem.deploy
> (DefaultRepositorySystem.java:386)
> at org.apache.maven.artifact.deployer.DefaultArtifactDeployer.deploy
> (DefaultArtifactDeployer.java:142)
> {noformat}
> Although this happened in the context of using
> "[org.sonatype.plugins:nexus-staging-maven-plugin|https://github.com/sonatype/nexus-maven-plugins]:1.6.8;
> (issue https://issues.sonatype.org/browse/NEXUS-30749 opened, exported to
> [^NEXUS-30749 - Broken groupId metadata and follow-up NPE during
> org.sonatype.nexus.maven.staging.deploy.strategy.AbstractDeployStrategy.deployUp
> - Sonatype JIRA.pdf] ), the affected code is in Maven.
> The metadata is probably invalid but the Metadata class should be more robust
> when trying to do the merge in
> https://github.com/apache/maven/blob/951b5ee95f40147abbc2bb9d928e408b85d5aef3/maven-repository-metadata/src/main/mdo/metadata.mdo#L100
> and just ignore all plugin entries without all mandatory elements.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MNG-7375) Potential NPE in o.a.m.artifact.repository.metadata.Metadata.merge(...) with invalid/incomplete plugin metadata
[
https://issues.apache.org/jira/browse/MNG-7375?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17846728#comment-17846728
]
Konrad Windszus commented on MNG-7375:
--
Although true, this is due to a limitation in modello:
https://github.com/codehaus-plexus/modello/blob/8467ab87f95557c8c6409f5ebe613caf240836b3/modello-plugins/modello-plugin-xsd/src/main/java/org/codehaus/modello/plugin/xsd/XsdGenerator.java#L245-L247
> Potential NPE in o.a.m.artifact.repository.metadata.Metadata.merge(...) with
> invalid/incomplete plugin metadata
> ---
>
> Key: MNG-7375
> URL: https://issues.apache.org/jira/browse/MNG-7375
> Project: Maven
> Issue Type: Improvement
> Components: Artifacts and Repositories
>Affects Versions: 3.8.4
>Reporter: Konrad Windszus
>Priority: Major
> Attachments: NEXUS-30749 - Broken groupId metadata and follow-up NPE
> during
> org.sonatype.nexus.maven.staging.deploy.strategy.AbstractDeployStrategy.deployUp
> - Sonatype JIRA.pdf
>
>
> Currently the metadata at
> https://repository.apache.org/service/local/repositories/snapshots/content/org/apache/jackrabbit/maven-metadata.xml
> contains an invalid entry without a prefix:
> {code:xml}
>
>
>
> Apache Jackrabbit FileVault - Package Maven Plugin
> filevault-package
> filevault-package-maven-plugin
>
>
> filevault-package-maven-plugin
> filevault-package-maven-plugin
>
>
>
> {code}
> This leads to an NPE when trying to deploy a new version with
> {{org.apache.maven.artifact.deployer.DefaultArtifactDeployer.deploy(...)}}:
> {noformat}
> Caused by: java.lang.NullPointerException
> at org.apache.maven.artifact.repository.metadata.Metadata.merge
> (Metadata.java:276)
> at
> org.apache.maven.artifact.repository.metadata.AbstractRepositoryMetadata.updateRepositoryMetadata
> (AbstractRepositoryMetadata.java:121)
> at
> org.apache.maven.artifact.repository.metadata.AbstractRepositoryMetadata.storeInLocalRepository
> (AbstractRepositoryMetadata.java:67)
> at org.apache.maven.artifact.repository.metadata.MetadataBridge.merge
> (MetadataBridge.java:65)
> at org.eclipse.aether.internal.impl.DefaultDeployer.upload
> (DefaultDeployer.java:433)
> at org.eclipse.aether.internal.impl.DefaultDeployer.deploy
> (DefaultDeployer.java:321)
> at org.eclipse.aether.internal.impl.DefaultDeployer.deploy
> (DefaultDeployer.java:213)
> at org.eclipse.aether.internal.impl.DefaultRepositorySystem.deploy
> (DefaultRepositorySystem.java:386)
> at org.apache.maven.artifact.deployer.DefaultArtifactDeployer.deploy
> (DefaultArtifactDeployer.java:142)
> {noformat}
> Although this happened in the context of using
> "[org.sonatype.plugins:nexus-staging-maven-plugin|https://github.com/sonatype/nexus-maven-plugins]:1.6.8;
> (issue https://issues.sonatype.org/browse/NEXUS-30749 opened, exported to
> [^NEXUS-30749 - Broken groupId metadata and follow-up NPE during
> org.sonatype.nexus.maven.staging.deploy.strategy.AbstractDeployStrategy.deployUp
> - Sonatype JIRA.pdf] ), the affected code is in Maven.
> The metadata is probably invalid but the Metadata class should be more robust
> when trying to do the merge in
> https://github.com/apache/maven/blob/951b5ee95f40147abbc2bb9d928e408b85d5aef3/maven-repository-metadata/src/main/mdo/metadata.mdo#L100
> and just ignore all plugin entries without all mandatory elements.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (JCRVLT-753) FORCE_REMOVE_CONFLICTING_ID Strategy Causing Constraint Violation Exception in AEM Replication
[
https://issues.apache.org/jira/browse/JCRVLT-753?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17846704#comment-17846704
]
Konrad Windszus commented on JCRVLT-753:
[~dbanjac] Can you provide a failing IT in a PR?
However I don't have a clever idea how to solve this edge case as all options
outlined above by [~reschke] seem quite unexpected to the user either so any
other suggestions would be much appreciated.
> FORCE_REMOVE_CONFLICTING_ID Strategy Causing Constraint Violation Exception
> in AEM Replication
> --
>
> Key: JCRVLT-753
> URL: https://issues.apache.org/jira/browse/JCRVLT-753
> Project: Jackrabbit FileVault
> Issue Type: Bug
> Components: vlt
>Reporter: Danilo Banjac
>Assignee: Konrad Windszus
>Priority: Major
> Labels: vault
>
> {*}Issue Description{*}:
> Recent updates to the replication conflict resolution strategy in Adobe
> Experience Manager (AEM) using JCR Filevault have led to failures when
> attempting to replicate content packages. Specifically, the shift from the
> *LEGACY* to the *FORCE_REMOVE_CONFLICTING_ID* strategy causes
> *javax.jcr.nodetype.ConstraintViolationException: OakConstraint0026* due to
> the attempted deletion of mandatory child nodes during the replication
> process.
> {*}Steps to Reproduce{*}:
> 1. Create a content package with a primary node of type *nt:file* and a
> mandatory child node {*}jcr:content{*}.
> 2. Update the version of the content package, ensuring the *jcr:uuid* of the
> *jcr:content* node remains unchanged.
> 3. Replicate the updated content package.
> {*}Observed Behavior{*}:
> - The replication framework attempts to remove the conflicting *jcr:content*
> node due to the identical {*}jcr:uuid{*}.
> - The deletion operation fails because the parent *nt:file* node requires the
> *jcr:content* child node, resulting in a {*}ConstraintViolationException{*}:
> "{*}Mandatory child node jcr:content cannot be removed.{*}"
> {*}Root Cause{*}:
> The *FORCE_REMOVE_CONFLICTING_ID* conflict resolution strategy does not
> account for the constraints of mandatory child nodes in the JCR repository,
> leading to violations when trying to remove these nodes.
> {*}Impact{*}:
> This issue prevents successful replication of updated content packages in
> AEM, disrupting content management workflows and generating errors in the log.
> *Nodes Used for Testing*
> {noformat}
> {
> "jcr:primaryType": "nt:file",
> "jcr:createdBy": "sling-distribution-importer",
> "jcr:created": "Tue May 14 2024 10:13:41 GMT+",
> "jcr:content": {
> "jcr:primaryType": "nt:resource",
> "jcr:mixinTypes": [
> "vlt:Package"
> ],
> "jcr:lastModifiedBy": "admin",
> "jcr:mimeType": "application/zip",
> "jcr:lastModified": "Tue May 14 2024 10:13:32 GMT+",
> ":jcr:data": 35146,
> "jcr:uuid": "cef51ff7-f3fc-4a41-b765-ca4ceb4246ce",
> "vlt:definition": {
> "jcr:primaryType": "vlt:PackageDefinition",
> "testedWith": "",
> "lastUnpacked": "Tue May 14 2024 10:13:41 GMT+",
> "lastUnpackedBy": "sling-distribution-importer",
> "requiresRestart": false,
> "requiresRoot": false,
> "lastWrapped": "Fri Apr 26 2024 12:27:44 GMT+",
> "buildCount": "17",
> "providerLink": "",
> "providerName": "",
> "jcr:created": "Fri Apr 26 2024 12:27:44 GMT+",
> "name": "global-truststore",
> "group": "admin-tasks",
> "version": "15.0",
> "dependencies": [],
> "fixedBugs": "",
> "jcr:lastModified": "Fri Apr 26 2024 12:27:44 GMT+",
> "lastUnwrapped": "Tue May 14 2024 10:13:32 GMT+",
> "providerUrl": "",
> "screenshots": {
> "jcr:primaryType": "nt:unstructured"
> },
> "filter": {
> "jcr:primaryType": "nt:unstructured",
> "f0": {
> "jcr:primaryType": "nt:unstructured",
> "propertyRules": [],
> "mode": "replace",
> "root": "/etc/truststore",
> "rules": []
> }
> }
> }
> }
> }{noformat}
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
Re: [PATCH] drm/msm: Add obj flags to gpu devcoredump
On 5/13/24 17:51, Rob Clark wrote: From: Rob Clark When debugging faults, it is useful to know how the BO is mapped (cached vs WC, gpu readonly, etc). Signed-off-by: Rob Clark --- Acked-by: Konrad Dybcio Konrad
Re: [PATCH] drm/msm: Add obj flags to gpu devcoredump
On 5/13/24 17:51, Rob Clark wrote: From: Rob Clark When debugging faults, it is useful to know how the BO is mapped (cached vs WC, gpu readonly, etc). Signed-off-by: Rob Clark --- Acked-by: Konrad Dybcio Konrad
[plasmashell] [Bug 486989] System Tray Context Menu sets its size to 0x0 (practically invisble) everytime the floating system bar switches to fixed mode.
https://bugs.kde.org/show_bug.cgi?id=486989 Konrad Materka changed: What|Removed |Added Resolution|--- |WAITINGFORINFO Status|REPORTED|NEEDSINFO --- Comment #1 from Konrad Materka --- Is context menu sized incorrectly or extended applet? I'm asking, because similar issue was already reported: Bug 485456 -- You are receiving this mail because: You are watching all bug changes.
API Regions and Split-Packages
Hi, I have a question about https://github.com/apache/sling-org-apache-sling-feature-apiregions and split packages. How are split-packages supposed to be treated by the resolver in case an imported-package from bundle a in region A can be resolved from bundle b (in region A) and bundle c (in global region). Is there any special rules applied here for split-packages across regions? Thanks in advance, Konrad
Re: [vz-dev] Gateway?
On Mon, 13 May 2024 09:22:28 +0200, you wrote: >Am Montag, dem 13.05.2024 um 08:39 +0200 schrieb Daniel Lauckner: >> Die modernen Messeinrichtungen (eHz) haben 2 optische Schnittstellen. Eine >> vorne, die wir mit dem Lesekopf anzapfen. Eine hinten. >> Die Gateways werden an der rückseitigen Schnittstelle angeschlossen, der >> Lesekopf ist da in der Zählerplatte fixiert und verbleibt beim Zählertausch. > >Danke für die Info. Weißt Du auch, welche Protokolle verwendet werden? > >Meine Vermutung ist, das neue Zähler verstärkt MBus verwenden werden, >weil die Gateways auch über MBus kommunizieren. > >Gruß, >Joachim Die Beschreibung der Schnittstelle, die man mit einem IR-Kopf abgreift (direkt neben der Taschenlampenschnittstelle) findet man z. B. sehr detailliert hier: https://www.stadtwerke-rheine.de/de/Netze/Stromnetz/Betriebsanleitung-mME-DD3-2023-11-23.pdf Funktioniert bei mir gut. l. -- Konrad Wilhelm Südstr. 3, D48329 Havixbeck Tel. 02507-7705
[PATCH v2] drm/msm/adreno: De-spaghettify the use of memory barriers
Memory barriers help ensure instruction ordering, NOT time and order
of actual write arrival at other observers (e.g. memory-mapped IP).
On architectures employing weak memory ordering, the latter can be a
giant pain point, and it has been as part of this driver.
Moreover, the gpu_/gmu_ accessors already use non-relaxed versions of
readl/writel, which include r/w (respectively) barriers.
Replace the barriers with a readback that ensures the previous writes
have exited the write buffer (as the CPU must flush the write to the
register it's trying to read back) and subsequently remove the hack
introduced in commit b77532803d11 ("drm/msm/a6xx: Poll for GBIF unhalt
status in hw_init").
Fixes: b77532803d11 ("drm/msm/a6xx: Poll for GBIF unhalt status in hw_init")
Signed-off-by: Konrad Dybcio
---
Changes in v2:
* Introduce gpu_write_flush() and use it
* Don't accidentally break a630 by trying to write to non-existent GBIF
---
drivers/gpu/drm/msm/adreno/a6xx_gmu.c | 4 +---
drivers/gpu/drm/msm/adreno/a6xx_gmu.h | 10 ++
drivers/gpu/drm/msm/adreno/a6xx_gpu.c | 16
drivers/gpu/drm/msm/msm_gpu.h | 14 --
4 files changed, 27 insertions(+), 17 deletions(-)
diff --git a/drivers/gpu/drm/msm/adreno/a6xx_gmu.c
b/drivers/gpu/drm/msm/adreno/a6xx_gmu.c
index 0e3dfd4c2bc8..fb2f8a03da41 100644
--- a/drivers/gpu/drm/msm/adreno/a6xx_gmu.c
+++ b/drivers/gpu/drm/msm/adreno/a6xx_gmu.c
@@ -466,9 +466,7 @@ static int a6xx_rpmh_start(struct a6xx_gmu *gmu)
int ret;
u32 val;
- gmu_write(gmu, REG_A6XX_GMU_RSCC_CONTROL_REQ, 1 << 1);
- /* Wait for the register to finish posting */
- wmb();
+ gmu_write_flush(gmu, REG_A6XX_GMU_RSCC_CONTROL_REQ, BIT(1));
ret = gmu_poll_timeout(gmu, REG_A6XX_GMU_RSCC_CONTROL_ACK, val,
val & (1 << 1), 100, 1);
diff --git a/drivers/gpu/drm/msm/adreno/a6xx_gmu.h
b/drivers/gpu/drm/msm/adreno/a6xx_gmu.h
index 94b6c5cab6f4..ab7f581f0d24 100644
--- a/drivers/gpu/drm/msm/adreno/a6xx_gmu.h
+++ b/drivers/gpu/drm/msm/adreno/a6xx_gmu.h
@@ -111,6 +111,16 @@ static inline void gmu_write(struct a6xx_gmu *gmu, u32
offset, u32 value)
writel(value, gmu->mmio + (offset << 2));
}
+/*
+ * Use for timing-critical writes that must reach the hardware immediately
+ * (to work around write buffering), e.g. for reset registers.
+ */
+static inline void gmu_write_flush(struct a6xx_gmu *gmu, u32 offset, u32 value)
+{
+ gmu_write(gmu, offset, value);
+ gmu_read(gmu, offset);
+}
+
static inline void
gmu_write_bulk(struct a6xx_gmu *gmu, u32 offset, const u32 *data, u32 size)
{
diff --git a/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
b/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
index cf0b1de1c071..ef7eaa6d5e5c 100644
--- a/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
+++ b/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
@@ -1714,21 +1714,13 @@ static int hw_init(struct msm_gpu *gpu)
/* Clear GBIF halt in case GX domain was not collapsed */
if (adreno_is_a619_holi(adreno_gpu)) {
- gpu_write(gpu, REG_A6XX_GBIF_HALT, 0);
- gpu_write(gpu, REG_A6XX_RBBM_GPR0_CNTL, 0);
- /* Let's make extra sure that the GPU can access the memory.. */
- mb();
+ gpu_write_flush(gpu, REG_A6XX_GBIF_HALT, 0);
+ gpu_write_flush(gpu, REG_A6XX_RBBM_GPR0_CNTL, 0);
} else if (a6xx_has_gbif(adreno_gpu)) {
- gpu_write(gpu, REG_A6XX_GBIF_HALT, 0);
- gpu_write(gpu, REG_A6XX_RBBM_GBIF_HALT, 0);
- /* Let's make extra sure that the GPU can access the memory.. */
- mb();
+ gpu_write_flush(gpu, REG_A6XX_GBIF_HALT, 0);
+ gpu_write_flush(gpu, REG_A6XX_RBBM_GBIF_HALT, 0);
}
- /* Some GPUs are stubborn and take their sweet time to unhalt GBIF! */
- if (adreno_is_a7xx(adreno_gpu) && a6xx_has_gbif(adreno_gpu))
- spin_until(!gpu_read(gpu, REG_A6XX_GBIF_HALT_ACK));
-
gpu_write(gpu, REG_A6XX_RBBM_SECVID_TSB_CNTL, 0);
if (adreno_is_a619_holi(adreno_gpu))
diff --git a/drivers/gpu/drm/msm/msm_gpu.h b/drivers/gpu/drm/msm/msm_gpu.h
index a0c1bd6d1d5b..45d00acd5b1b 100644
--- a/drivers/gpu/drm/msm/msm_gpu.h
+++ b/drivers/gpu/drm/msm/msm_gpu.h
@@ -553,14 +553,24 @@ struct msm_gpu_state {
struct msm_gpu_state_bo *bos;
};
+static inline u32 gpu_read(struct msm_gpu *gpu, u32 reg)
+{
+ return readl(gpu->mmio + (reg << 2));
+}
+
static inline void gpu_write(struct msm_gpu *gpu, u32 reg, u32 data)
{
writel(data, gpu->mmio + (reg << 2));
}
-static inline u32 gpu_read(struct msm_gpu *gpu, u32 reg)
+/*
+ * Use for timing-critical writes that must reach the hardware immediately
+ * (to work around write buffering), e.g. for reset registers.
+ */
+static inline void gpu_write_flush(struct msm_gpu *gpu, u32 reg, u32 data)
{
-
[PATCH v2] drm/msm/adreno: De-spaghettify the use of memory barriers
Memory barriers help ensure instruction ordering, NOT time and order
of actual write arrival at other observers (e.g. memory-mapped IP).
On architectures employing weak memory ordering, the latter can be a
giant pain point, and it has been as part of this driver.
Moreover, the gpu_/gmu_ accessors already use non-relaxed versions of
readl/writel, which include r/w (respectively) barriers.
Replace the barriers with a readback that ensures the previous writes
have exited the write buffer (as the CPU must flush the write to the
register it's trying to read back) and subsequently remove the hack
introduced in commit b77532803d11 ("drm/msm/a6xx: Poll for GBIF unhalt
status in hw_init").
Fixes: b77532803d11 ("drm/msm/a6xx: Poll for GBIF unhalt status in hw_init")
Signed-off-by: Konrad Dybcio
---
Changes in v2:
* Introduce gpu_write_flush() and use it
* Don't accidentally break a630 by trying to write to non-existent GBIF
---
drivers/gpu/drm/msm/adreno/a6xx_gmu.c | 4 +---
drivers/gpu/drm/msm/adreno/a6xx_gmu.h | 10 ++
drivers/gpu/drm/msm/adreno/a6xx_gpu.c | 16
drivers/gpu/drm/msm/msm_gpu.h | 14 --
4 files changed, 27 insertions(+), 17 deletions(-)
diff --git a/drivers/gpu/drm/msm/adreno/a6xx_gmu.c
b/drivers/gpu/drm/msm/adreno/a6xx_gmu.c
index 0e3dfd4c2bc8..fb2f8a03da41 100644
--- a/drivers/gpu/drm/msm/adreno/a6xx_gmu.c
+++ b/drivers/gpu/drm/msm/adreno/a6xx_gmu.c
@@ -466,9 +466,7 @@ static int a6xx_rpmh_start(struct a6xx_gmu *gmu)
int ret;
u32 val;
- gmu_write(gmu, REG_A6XX_GMU_RSCC_CONTROL_REQ, 1 << 1);
- /* Wait for the register to finish posting */
- wmb();
+ gmu_write_flush(gmu, REG_A6XX_GMU_RSCC_CONTROL_REQ, BIT(1));
ret = gmu_poll_timeout(gmu, REG_A6XX_GMU_RSCC_CONTROL_ACK, val,
val & (1 << 1), 100, 1);
diff --git a/drivers/gpu/drm/msm/adreno/a6xx_gmu.h
b/drivers/gpu/drm/msm/adreno/a6xx_gmu.h
index 94b6c5cab6f4..ab7f581f0d24 100644
--- a/drivers/gpu/drm/msm/adreno/a6xx_gmu.h
+++ b/drivers/gpu/drm/msm/adreno/a6xx_gmu.h
@@ -111,6 +111,16 @@ static inline void gmu_write(struct a6xx_gmu *gmu, u32
offset, u32 value)
writel(value, gmu->mmio + (offset << 2));
}
+/*
+ * Use for timing-critical writes that must reach the hardware immediately
+ * (to work around write buffering), e.g. for reset registers.
+ */
+static inline void gmu_write_flush(struct a6xx_gmu *gmu, u32 offset, u32 value)
+{
+ gmu_write(gmu, offset, value);
+ gmu_read(gmu, offset);
+}
+
static inline void
gmu_write_bulk(struct a6xx_gmu *gmu, u32 offset, const u32 *data, u32 size)
{
diff --git a/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
b/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
index cf0b1de1c071..ef7eaa6d5e5c 100644
--- a/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
+++ b/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
@@ -1714,21 +1714,13 @@ static int hw_init(struct msm_gpu *gpu)
/* Clear GBIF halt in case GX domain was not collapsed */
if (adreno_is_a619_holi(adreno_gpu)) {
- gpu_write(gpu, REG_A6XX_GBIF_HALT, 0);
- gpu_write(gpu, REG_A6XX_RBBM_GPR0_CNTL, 0);
- /* Let's make extra sure that the GPU can access the memory.. */
- mb();
+ gpu_write_flush(gpu, REG_A6XX_GBIF_HALT, 0);
+ gpu_write_flush(gpu, REG_A6XX_RBBM_GPR0_CNTL, 0);
} else if (a6xx_has_gbif(adreno_gpu)) {
- gpu_write(gpu, REG_A6XX_GBIF_HALT, 0);
- gpu_write(gpu, REG_A6XX_RBBM_GBIF_HALT, 0);
- /* Let's make extra sure that the GPU can access the memory.. */
- mb();
+ gpu_write_flush(gpu, REG_A6XX_GBIF_HALT, 0);
+ gpu_write_flush(gpu, REG_A6XX_RBBM_GBIF_HALT, 0);
}
- /* Some GPUs are stubborn and take their sweet time to unhalt GBIF! */
- if (adreno_is_a7xx(adreno_gpu) && a6xx_has_gbif(adreno_gpu))
- spin_until(!gpu_read(gpu, REG_A6XX_GBIF_HALT_ACK));
-
gpu_write(gpu, REG_A6XX_RBBM_SECVID_TSB_CNTL, 0);
if (adreno_is_a619_holi(adreno_gpu))
diff --git a/drivers/gpu/drm/msm/msm_gpu.h b/drivers/gpu/drm/msm/msm_gpu.h
index a0c1bd6d1d5b..45d00acd5b1b 100644
--- a/drivers/gpu/drm/msm/msm_gpu.h
+++ b/drivers/gpu/drm/msm/msm_gpu.h
@@ -553,14 +553,24 @@ struct msm_gpu_state {
struct msm_gpu_state_bo *bos;
};
+static inline u32 gpu_read(struct msm_gpu *gpu, u32 reg)
+{
+ return readl(gpu->mmio + (reg << 2));
+}
+
static inline void gpu_write(struct msm_gpu *gpu, u32 reg, u32 data)
{
writel(data, gpu->mmio + (reg << 2));
}
-static inline u32 gpu_read(struct msm_gpu *gpu, u32 reg)
+/*
+ * Use for timing-critical writes that must reach the hardware immediately
+ * (to work around write buffering), e.g. for reset registers.
+ */
+static inline void gpu_write_flush(struct msm_gpu *gpu, u32 reg, u32 data)
{
-
[Bug 2064208] Re: Installer crashes when booting from USB on Raspberry Pi
Adding to the above: 1. @waveform - thank you so much for the new image!!! - it works! Nothing has worked for me until now, even the initial ubuntu setup from sd card (tried other options: usb stick, sd card via usb adapter, nvme), no matter how I flashed it (r-imager, balenda etcher). I always ended up with failed installation pop-up window, without even displaying the graphic glitch with the progress bar. Now I have managed successfully to set ubuntu 24.04 lts on my pi from the sd card as well as the nvme! 2. Test hardware details: - Raspberry pi 5 with 8gb ram - micro sd SanDisc Extreme V30 32GB flashed with Balena Etcher on mac - nvme Lexar NM790 1TB (Gen 4x4) flashed with pi-imager using custom image on my pi when the above got running -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/2064208 Title: Installer crashes when booting from USB on Raspberry Pi To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/ubiquity/+bug/2064208/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[PATCH] drm/msm/adreno: De-spaghettify the use of memory barriers
Memory barriers help ensure instruction ordering, NOT time and order
of actual write arrival at other observers (e.g. memory-mapped IP).
On architectures employing weak memory ordering, the latter can be a
giant pain point, and it has been as part of this driver.
Moreover, the gpu_/gmu_ accessors already use non-relaxed versions of
readl/writel, which include r/w (respectively) barriers.
Replace the barriers with a readback that ensures the previous writes
have exited the write buffer (as the CPU must flush the write to the
register it's trying to read back) and subsequently remove the hack
introduced in commit b77532803d11 ("drm/msm/a6xx: Poll for GBIF unhalt
status in hw_init").
Fixes: b77532803d11 ("drm/msm/a6xx: Poll for GBIF unhalt status in hw_init")
Signed-off-by: Konrad Dybcio
---
drivers/gpu/drm/msm/adreno/a6xx_gmu.c | 5 ++---
drivers/gpu/drm/msm/adreno/a6xx_gpu.c | 14 --
2 files changed, 6 insertions(+), 13 deletions(-)
diff --git a/drivers/gpu/drm/msm/adreno/a6xx_gmu.c
b/drivers/gpu/drm/msm/adreno/a6xx_gmu.c
index 0e3dfd4c2bc8..4135a53b55a7 100644
--- a/drivers/gpu/drm/msm/adreno/a6xx_gmu.c
+++ b/drivers/gpu/drm/msm/adreno/a6xx_gmu.c
@@ -466,9 +466,8 @@ static int a6xx_rpmh_start(struct a6xx_gmu *gmu)
int ret;
u32 val;
- gmu_write(gmu, REG_A6XX_GMU_RSCC_CONTROL_REQ, 1 << 1);
- /* Wait for the register to finish posting */
- wmb();
+ gmu_write(gmu, REG_A6XX_GMU_RSCC_CONTROL_REQ, BIT(1));
+ gmu_read(gmu, REG_A6XX_GMU_RSCC_CONTROL_REQ);
ret = gmu_poll_timeout(gmu, REG_A6XX_GMU_RSCC_CONTROL_ACK, val,
val & (1 << 1), 100, 1);
diff --git a/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
b/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
index 973872ad0474..0acbc38b8e70 100644
--- a/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
+++ b/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
@@ -1713,22 +1713,16 @@ static int hw_init(struct msm_gpu *gpu)
}
/* Clear GBIF halt in case GX domain was not collapsed */
+ gpu_write(gpu, REG_A6XX_GBIF_HALT, 0);
+ gpu_read(gpu, REG_A6XX_GBIF_HALT);
if (adreno_is_a619_holi(adreno_gpu)) {
- gpu_write(gpu, REG_A6XX_GBIF_HALT, 0);
gpu_write(gpu, REG_A6XX_RBBM_GPR0_CNTL, 0);
- /* Let's make extra sure that the GPU can access the memory.. */
- mb();
+ gpu_read(gpu, REG_A6XX_RBBM_GPR0_CNTL);
} else if (a6xx_has_gbif(adreno_gpu)) {
- gpu_write(gpu, REG_A6XX_GBIF_HALT, 0);
gpu_write(gpu, REG_A6XX_RBBM_GBIF_HALT, 0);
- /* Let's make extra sure that the GPU can access the memory.. */
- mb();
+ gpu_read(gpu, REG_A6XX_RBBM_GBIF_HALT);
}
- /* Some GPUs are stubborn and take their sweet time to unhalt GBIF! */
- if (adreno_is_a7xx(adreno_gpu) && a6xx_has_gbif(adreno_gpu))
- spin_until(!gpu_read(gpu, REG_A6XX_GBIF_HALT_ACK));
-
gpu_write(gpu, REG_A6XX_RBBM_SECVID_TSB_CNTL, 0);
if (adreno_is_a619_holi(adreno_gpu))
---
base-commit: 93a39e4766083050ca0ecd6a3548093a3b9eb60c
change-id: 20240508-topic-adreno-a2d199cd4152
Best regards,
--
Konrad Dybcio
[PATCH] drm/msm/adreno: De-spaghettify the use of memory barriers
Memory barriers help ensure instruction ordering, NOT time and order
of actual write arrival at other observers (e.g. memory-mapped IP).
On architectures employing weak memory ordering, the latter can be a
giant pain point, and it has been as part of this driver.
Moreover, the gpu_/gmu_ accessors already use non-relaxed versions of
readl/writel, which include r/w (respectively) barriers.
Replace the barriers with a readback that ensures the previous writes
have exited the write buffer (as the CPU must flush the write to the
register it's trying to read back) and subsequently remove the hack
introduced in commit b77532803d11 ("drm/msm/a6xx: Poll for GBIF unhalt
status in hw_init").
Fixes: b77532803d11 ("drm/msm/a6xx: Poll for GBIF unhalt status in hw_init")
Signed-off-by: Konrad Dybcio
---
drivers/gpu/drm/msm/adreno/a6xx_gmu.c | 5 ++---
drivers/gpu/drm/msm/adreno/a6xx_gpu.c | 14 --
2 files changed, 6 insertions(+), 13 deletions(-)
diff --git a/drivers/gpu/drm/msm/adreno/a6xx_gmu.c
b/drivers/gpu/drm/msm/adreno/a6xx_gmu.c
index 0e3dfd4c2bc8..4135a53b55a7 100644
--- a/drivers/gpu/drm/msm/adreno/a6xx_gmu.c
+++ b/drivers/gpu/drm/msm/adreno/a6xx_gmu.c
@@ -466,9 +466,8 @@ static int a6xx_rpmh_start(struct a6xx_gmu *gmu)
int ret;
u32 val;
- gmu_write(gmu, REG_A6XX_GMU_RSCC_CONTROL_REQ, 1 << 1);
- /* Wait for the register to finish posting */
- wmb();
+ gmu_write(gmu, REG_A6XX_GMU_RSCC_CONTROL_REQ, BIT(1));
+ gmu_read(gmu, REG_A6XX_GMU_RSCC_CONTROL_REQ);
ret = gmu_poll_timeout(gmu, REG_A6XX_GMU_RSCC_CONTROL_ACK, val,
val & (1 << 1), 100, 1);
diff --git a/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
b/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
index 973872ad0474..0acbc38b8e70 100644
--- a/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
+++ b/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
@@ -1713,22 +1713,16 @@ static int hw_init(struct msm_gpu *gpu)
}
/* Clear GBIF halt in case GX domain was not collapsed */
+ gpu_write(gpu, REG_A6XX_GBIF_HALT, 0);
+ gpu_read(gpu, REG_A6XX_GBIF_HALT);
if (adreno_is_a619_holi(adreno_gpu)) {
- gpu_write(gpu, REG_A6XX_GBIF_HALT, 0);
gpu_write(gpu, REG_A6XX_RBBM_GPR0_CNTL, 0);
- /* Let's make extra sure that the GPU can access the memory.. */
- mb();
+ gpu_read(gpu, REG_A6XX_RBBM_GPR0_CNTL);
} else if (a6xx_has_gbif(adreno_gpu)) {
- gpu_write(gpu, REG_A6XX_GBIF_HALT, 0);
gpu_write(gpu, REG_A6XX_RBBM_GBIF_HALT, 0);
- /* Let's make extra sure that the GPU can access the memory.. */
- mb();
+ gpu_read(gpu, REG_A6XX_RBBM_GBIF_HALT);
}
- /* Some GPUs are stubborn and take their sweet time to unhalt GBIF! */
- if (adreno_is_a7xx(adreno_gpu) && a6xx_has_gbif(adreno_gpu))
- spin_until(!gpu_read(gpu, REG_A6XX_GBIF_HALT_ACK));
-
gpu_write(gpu, REG_A6XX_RBBM_SECVID_TSB_CNTL, 0);
if (adreno_is_a619_holi(adreno_gpu))
---
base-commit: 93a39e4766083050ca0ecd6a3548093a3b9eb60c
change-id: 20240508-topic-adreno-a2d199cd4152
Best regards,
--
Konrad Dybcio
[jira] [Updated] (JCRVLT-751) ExportOptions.rootPath not properly converted to platform name format
[ https://issues.apache.org/jira/browse/JCRVLT-751?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Konrad Windszus updated JCRVLT-751: --- Resolution: Fixed Status: Resolved (was: Patch Available) Fixed in https://github.com/apache/jackrabbit-filevault/commit/33b23e126e7e7260582dd43d4b9f4c93958da674. > ExportOptions.rootPath not properly converted to platform name format > - > > Key: JCRVLT-751 > URL: https://issues.apache.org/jira/browse/JCRVLT-751 > Project: Jackrabbit FileVault > Issue Type: Bug > Components: vlt >Affects Versions: 3.7.2 >Reporter: Timothée Maret >Assignee: Konrad Windszus >Priority: Major > Labels: vault > Fix For: 3.7.4 > > > AEM has a user synchronisation capability in the publish tier. The > synchronisation mechanism relies on FileVault to export and import content. > Users stored in the repository under a path that starts with a _ and that > contain another _ can be exported but fail to be re-imported. For instance, > the user stored under the path /home/users/test/_6k_test-user-a won't be > imported. > Debugging this issue, it seems that FileVault treats the _6k_ pattern as a > namespace and thus skip the resource upon import because the paths don't > match. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (FELIX-6704) Improve error logging for exceptions thrown from Configuration Plugins in ConfigurationManager
Konrad Windszus created FELIX-6704:
--
Summary: Improve error logging for exceptions thrown from
Configuration Plugins in ConfigurationManager
Key: FELIX-6704
URL: https://issues.apache.org/jira/browse/FELIX-6704
Project: Felix
Issue Type: Improvement
Components: Configuration Admin
Affects Versions: configadmin-1.9.24
Reporter: Konrad Windszus
Currently all throwables are caught in
https://github.com/apache/felix-dev/blob/517f9a0c89cad1866f315255568b40c568f5239d/configadmin/src/main/java/org/apache/felix/cm/impl/ConfigurationManager.java#L932
and logged.
The important factory or configuration PID is not emitted in the log message
though.
Example:
{code}
07.05.2024 20:41:33.820 *ERROR* [FelixLogListener]
LogService.org.apache.felix.configadmin Service
[org.apache.felix.cm.ConfigurationAdmin,47,
[org.osgi.service.cm.ConfigurationAdmin]] Unexpected problem calling
configuration plugin [org.osgi.service.cm.ConfigurationPlugin, id=41,
bundle=38/slinginstall:org.apache.felix.configadmin.plugin.interpolation-1.2.6.jar]
(org.apache.felix.log.LogException:
org.osgi.util.converter.ConversionException: Cannot convert TO BE PROVIDED to
class java.lang.Integer)
org.apache.felix.log.LogException: org.osgi.util.converter.ConversionException:
Cannot convert TO BE PROVIDED to class java.lang.Integer
at org.osgi.util.converter.ConvertingImpl.to(ConvertingImpl.java:243)
at
org.osgi.util.converter.CustomConverterImpl$ConvertingWrapper.to(CustomConverterImpl.java:183)
at
org.osgi.util.converter.CustomConverterImpl$ConvertingWrapper.to(CustomConverterImpl.java:151)
at
org.osgi.util.converter.CustomConverterImpl$ConvertingWrapper.to(CustomConverterImpl.java:141)
at
org.apache.felix.configadmin.plugin.interpolation.InterpolationConfigurationPlugin.convertType(InterpolationConfigurationPlugin.java:308)
at
org.apache.felix.configadmin.plugin.interpolation.InterpolationConfigurationPlugin.lambda$replace$0(InterpolationConfigurationPlugin.java:197)
at
org.apache.felix.configadmin.plugin.interpolation.Interpolator.replace(Interpolator.java:149)
at
org.apache.felix.configadmin.plugin.interpolation.InterpolationConfigurationPlugin.replace(InterpolationConfigurationPlugin.java:179)
at
org.apache.felix.configadmin.plugin.interpolation.InterpolationConfigurationPlugin.getNewValue(InterpolationConfigurationPlugin.java:171)
at
org.apache.felix.configadmin.plugin.interpolation.InterpolationConfigurationPlugin.modifyConfiguration(InterpolationConfigurationPlugin.java:133)
at
org.apache.felix.cm.impl.ConfigurationManager.callPlugins(ConfigurationManager.java:928)
[org.apache.felix.configadmin:1.9.24]
at
org.apache.felix.cm.impl.ConfigurationAdapter.getProcessedProperties(ConfigurationAdapter.java:293)
[org.apache.felix.configadmin:1.9.24]
at
org.apache.felix.scr.impl.manager.RegionConfigurationSupport.getConfigurationInfo(RegionConfigurationSupport.java:532)
[org.apache.felix.scr:2.2.4]
at
org.apache.felix.scr.impl.manager.RegionConfigurationSupport.configurationEvent(RegionConfigurationSupport.java:333)
[org.apache.felix.scr:2.2.4]
at
org.apache.felix.scr.impl.manager.RegionConfigurationSupport$2.configurationEvent(RegionConfigurationSupport.java:115)
[org.apache.felix.scr:2.2.4]
at
org.apache.felix.cm.impl.ConfigurationManager$FireConfigurationEvent.sendEvent(ConfigurationManager.java:1721)
[org.apache.felix.configadmin:1.9.24]
at
org.apache.felix.cm.impl.ConfigurationManager$FireConfigurationEvent.run(ConfigurationManager.java:1662)
[org.apache.felix.configadmin:1.9.24]
at org.apache.felix.cm.impl.UpdateThread.run0(UpdateThread.java:122)
[org.apache.felix.configadmin:1.9.24]
at org.apache.felix.cm.impl.UpdateThread.run(UpdateThread.java:84)
[org.apache.felix.configadmin:1.9.24]
at java.base/java.lang.Thread.run(Thread.java:829)
{code}
For debugging purposes the configuration PID is the most crucial bit of
information and this is missing from this log message.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
Re: [PATCH v3 3/3] arm64: dts: qcom: msm8998: set qcom,no-msa-ready-indicator for wifi
On 5/6/24 12:39, Marc Gonzalez wrote:
On 29/04/2024 16:07, Marc Gonzalez wrote:
The ath10k driver waits for an "MSA_READY" indicator
to complete initialization. If the indicator is not
received, then the device remains unusable.
cf. ath10k_qmi_driver_event_work()
Several msm8998-based devices are affected by this issue.
Oddly, it seems safe to NOT wait for the indicator, and
proceed immediately when QMI_EVENT_SERVER_ARRIVE.
Jeff Johnson wrote:
The feedback I received was "it might be ok to change all ath10k qmi
to skip waiting for msa_ready", and it was pointed out that ath11k
(and ath12k) do not wait for it.
However with so many deployed devices, "might be ok" isn't a strong
argument for changing the default behavior.
cf. also
https://wiki.postmarketos.org/wiki/Qualcomm_Snapdragon_835_(MSM8998)#WLAN
Signed-off-by: Marc Gonzalez
---
arch/arm64/boot/dts/qcom/msm8998.dtsi | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm64/boot/dts/qcom/msm8998.dtsi
b/arch/arm64/boot/dts/qcom/msm8998.dtsi
index 67b8374ddf02f..4e6245095adfc 100644
--- a/arch/arm64/boot/dts/qcom/msm8998.dtsi
+++ b/arch/arm64/boot/dts/qcom/msm8998.dtsi
@@ -3234,6 +3234,7 @@ wifi: wifi@1880 {
iommus = <_smmu 0x1900>,
<_smmu 0x1901>;
qcom,snoc-host-cap-8bit-quirk;
+ qcom,no-msa-ready-indicator;
};
};
};
Bjorn,
This patch is supposed to go through your tree, right?
Reviewed-by: Konrad Dybcio
Konrad
[jira] [Comment Edited] (MPLUGIN-522) The auto prerequisites are way to aggressive
[ https://issues.apache.org/jira/browse/MPLUGIN-522?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17844188#comment-17844188 ] Konrad Windszus edited comment on MPLUGIN-522 at 5/7/24 8:18 AM: - bq. why it gets "highest class version present on classpath"? Why not compiler target instead? ... Because in general it is fair to assume that every class being embedded in the plugin is supposed to be executed. That requires a Java version capable of digesting the class version. Not every class being shipped with the plugin is necessarily compiled in the same build. bq. Similarly, if I have one class that is Java 22, the plugin prerequisite is NOT Java 22. It the class is in the plugin classpath I would assume that this is necessary for plugin execution (not necessarily for each mojo). If the class isn't being called then it shouldn't be there in the first place... bq. if I compile against 3.9.6 Maven APIs, that – due backward compatibility – does NOT mean plugin "has a prerequisite of 3.9.6". As we all know, they are happily working even with 3.6.3 or even 3.2.x. What you describe is not backwards-compatibility but forwards-compatibility. Each minor Maven version may add new methods/classes to Maven API in a backwards-compatible way. Therefore it is fair to assume that the Maven API you compile against is the minimally required Maven version. What you are running into are edge cases which IMHO justify that you override the automatically created values (i.e. one class with bytecode for Java22 not being executed by the Mojo for some reason, compiling against a newer Maven version than you require). I don't want plugins to not state prerequisites at all just because plugin developers are too lazy, because that is very frustrating for users not complying with those (unexplicit) prerequisites. was (Author: kwin): bq. why it gets "highest class version present on classpath"? Why not compiler target instead? Because in general it is fair to assume that every class being embedded in the plugin is supposed to be executed. That requires a Java version capable of digesting the class version. Not every class being shipped with the plugin is necessarily compiled in the same build. bq. if I compile against 3.9.6 Maven APIs, that – due backward compatibility – does NOT mean plugin "has a prerequisite of 3.9.6". As we all know, they are happily working even with 3.6.3 or even 3.2.x. What you describe is not backwards-compatibility but forwards-compatibility. Each minor Maven version may add new methods/classes to Maven API in a backwards-compatible way. Therefore it is fair to assume that the Maven API you compile against is the minimally required Maven version. What you are running into are edge cases which IMHO justify that you override the automatically created values (i.e. one class with bytecode for Java22 not being executed by the Mojo for some reason, compiling against a newer Maven version than you require). I don't want plugins to not state prerequisites at all just because plugin developers are too lazy, because that is very frustrating for users not complying with those (unexplicit) prerequisites. > The auto prerequisites are way to aggressive > > > Key: MPLUGIN-522 > URL: https://issues.apache.org/jira/browse/MPLUGIN-522 > Project: Maven Plugin Tools > Issue Type: Bug > Components: Plugin Plugin >Reporter: Tamas Cservenak >Priority: Major > > IMHO the implementation done in MPLUGIN-425 and MPLUGIN-424 are wrong. > They are way too aggresive and violate backward compatibility: if new feature > is not explicitly set by user, code should not "come up" with some automatic > value. By having the value not set simply means user does not want to use it. > This is especially true for (maven or java) prerequisite, as it creates HARD > BREAKAGE if not met. Use of prerequisite is opt-in, but now it is FORCED onto > user. > [~kwin] -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Comment Edited] (MPLUGIN-522) The auto prerequisites are way to aggressive
[ https://issues.apache.org/jira/browse/MPLUGIN-522?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17844188#comment-17844188 ] Konrad Windszus edited comment on MPLUGIN-522 at 5/7/24 8:10 AM: - bq. why it gets "highest class version present on classpath"? Why not compiler target instead? Because in general it is fair to assume that every class being embedded in the plugin is supposed to be executed. That requires a Java version capable of digesting the class version. Not every class being shipped with the plugin is necessarily compiled in the same build. bq. if I compile against 3.9.6 Maven APIs, that – due backward compatibility – does NOT mean plugin "has a prerequisite of 3.9.6". As we all know, they are happily working even with 3.6.3 or even 3.2.x. What you describe is not backwards-compatibility but forwards-compatibility. Each minor Maven version may add new methods/classes to Maven API in a backwards-compatible way. Therefore it is fair to assume that the Maven API you compile against is the minimally required Maven version. What you are running into are edge cases which IMHO justify that you override the automatically created values (i.e. one class with bytecode for Java22 not being executed by the Mojo for some reason, compiling against a newer Maven version than you require). I don't want plugins to not state prerequisites at all just because plugin developers are too lazy, because that is very frustrating for users not complying with those (unexplicit) prerequisites. was (Author: kwin): bq. why it gets "highest class version present on classpath"? Why not compiler target instead? Because in general it is fair to assume that every class being embedded in the plugin is supposed to be executed. That requires a Java version capable of digesting the class version. Not every class being shipped with the plugin is necessarily compiled in the same build. bq. if I compile against 3.9.6 Maven APIs, that – due backward compatibility – does NOT mean plugin "has a prerequisite of 3.9.6". As we all know, they are happily working even with 3.6.3 or even 3.2.x. What you describe is not backwards-compatibility but forwards-compatibility. Each minor Maven version may add new methods/classes to Maven API in a backwards-compatible way. Therefore it is fair to assume that the Maven API you compile against is the minimally required Maven version. What you are running into are edge cases which IMHO justify that you override the automatically created values (i.e. one class with bytecode for Java22 not being executed by the Mojo for some reason, compiling against a newer Maven version than you require). I don't want plugins to not state prerequisites at all just because plugin developers are too lazy. > The auto prerequisites are way to aggressive > > > Key: MPLUGIN-522 > URL: https://issues.apache.org/jira/browse/MPLUGIN-522 > Project: Maven Plugin Tools > Issue Type: Bug > Components: Plugin Plugin >Reporter: Tamas Cservenak >Priority: Major > > IMHO the implementation done in MPLUGIN-425 and MPLUGIN-424 are wrong. > They are way too aggresive and violate backward compatibility: if new feature > is not explicitly set by user, code should not "come up" with some automatic > value. By having the value not set simply means user does not want to use it. > This is especially true for (maven or java) prerequisite, as it creates HARD > BREAKAGE if not met. Use of prerequisite is opt-in, but now it is FORCED onto > user. > [~kwin] -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MPLUGIN-522) The auto prerequisites are way to aggressive
[ https://issues.apache.org/jira/browse/MPLUGIN-522?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17844188#comment-17844188 ] Konrad Windszus commented on MPLUGIN-522: - > why it gets "highest class version present on classpath"? Why not compiler > target instead? Because in general it is fair to assume that every class being embedded in the plugin is supposed to be executed. That requires a Java version capable of digesting the class version. Not every class being shipped with the plugin is necessarily compiled in the same build. > if I compile against 3.9.6 Maven APIs, that – due backward compatibility – > does NOT mean plugin "has a prerequisite of 3.9.6". As we all know, they are > happily working even with 3.6.3 or even 3.2.x. What you describe is not backwards-compatibility but forwards-compatibility. Each minor Maven version may add new methods/classes to Maven API in a backwards-compatible way. Therefore it is fair to assume that the Maven API you compile against is the minimally required Maven version. What you are running into are edge cases which IMHO justify that you override the automatically created values (i.e. one class with bytecode for Java22 not being executed by the Mojo for some reason, compiling against a newer Maven version than you require). I don't want plugins to not state prerequisites at all just because plugin developers are too lazy. > The auto prerequisites are way to aggressive > > > Key: MPLUGIN-522 > URL: https://issues.apache.org/jira/browse/MPLUGIN-522 > Project: Maven Plugin Tools > Issue Type: Bug > Components: Plugin Plugin >Reporter: Tamas Cservenak >Priority: Major > > IMHO the implementation done in MPLUGIN-425 and MPLUGIN-424 are wrong. > They are way too aggresive and violate backward compatibility: if new feature > is not explicitly set by user, code should not "come up" with some automatic > value. By having the value not set simply means user does not want to use it. > This is especially true for (maven or java) prerequisite, as it creates HARD > BREAKAGE if not met. Use of prerequisite is opt-in, but now it is FORCED onto > user. > [~kwin] -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Comment Edited] (MPLUGIN-522) The auto prerequisites are way to aggressive
[ https://issues.apache.org/jira/browse/MPLUGIN-522?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17844188#comment-17844188 ] Konrad Windszus edited comment on MPLUGIN-522 at 5/7/24 8:08 AM: - bq. why it gets "highest class version present on classpath"? Why not compiler target instead? Because in general it is fair to assume that every class being embedded in the plugin is supposed to be executed. That requires a Java version capable of digesting the class version. Not every class being shipped with the plugin is necessarily compiled in the same build. bq. if I compile against 3.9.6 Maven APIs, that – due backward compatibility – does NOT mean plugin "has a prerequisite of 3.9.6". As we all know, they are happily working even with 3.6.3 or even 3.2.x. What you describe is not backwards-compatibility but forwards-compatibility. Each minor Maven version may add new methods/classes to Maven API in a backwards-compatible way. Therefore it is fair to assume that the Maven API you compile against is the minimally required Maven version. What you are running into are edge cases which IMHO justify that you override the automatically created values (i.e. one class with bytecode for Java22 not being executed by the Mojo for some reason, compiling against a newer Maven version than you require). I don't want plugins to not state prerequisites at all just because plugin developers are too lazy. was (Author: kwin): > why it gets "highest class version present on classpath"? Why not compiler > target instead? Because in general it is fair to assume that every class being embedded in the plugin is supposed to be executed. That requires a Java version capable of digesting the class version. Not every class being shipped with the plugin is necessarily compiled in the same build. > if I compile against 3.9.6 Maven APIs, that – due backward compatibility – > does NOT mean plugin "has a prerequisite of 3.9.6". As we all know, they are > happily working even with 3.6.3 or even 3.2.x. What you describe is not backwards-compatibility but forwards-compatibility. Each minor Maven version may add new methods/classes to Maven API in a backwards-compatible way. Therefore it is fair to assume that the Maven API you compile against is the minimally required Maven version. What you are running into are edge cases which IMHO justify that you override the automatically created values (i.e. one class with bytecode for Java22 not being executed by the Mojo for some reason, compiling against a newer Maven version than you require). I don't want plugins to not state prerequisites at all just because plugin developers are too lazy. > The auto prerequisites are way to aggressive > > > Key: MPLUGIN-522 > URL: https://issues.apache.org/jira/browse/MPLUGIN-522 > Project: Maven Plugin Tools > Issue Type: Bug > Components: Plugin Plugin >Reporter: Tamas Cservenak >Priority: Major > > IMHO the implementation done in MPLUGIN-425 and MPLUGIN-424 are wrong. > They are way too aggresive and violate backward compatibility: if new feature > is not explicitly set by user, code should not "come up" with some automatic > value. By having the value not set simply means user does not want to use it. > This is especially true for (maven or java) prerequisite, as it creates HARD > BREAKAGE if not met. Use of prerequisite is opt-in, but now it is FORCED onto > user. > [~kwin] -- This message was sent by Atlassian Jira (v8.20.10#820010)
Re: Zusäutzliche Festplatte dauerhaft einbinden + Speed-Test
On 06/05/2024 13:44, Gerd G wrote: Man kann natürlich auch einfach mal was mit "dd" auf den Datenträger schreiben und sich dabei die Zeit und Datenmenge ansehen. Bei den Tools ist Vorsicht geboten, sie sind mit root Rechten nutzbar und man kann bei falsche Nutzung dabei auch Dinge kaputt machen. Vorsichtshalber: man kann sich nicht nur was dabei kaputtmachen - ich habe mir auch schonmal die Daten auf einer ANDEREN Platte geschrottet, indem ich nicht aufgepasst habe. Also ganz genau schauen was man eintippt und mindestens 3x lesen, sicherstellen dass man das richtige Device angegeben hat und mit Man-Page vergleichen bevor man Enter drückt! Konrad OpenPGP_0xBE96A6EE776FE5D0.asc Description: OpenPGP public key OpenPGP_signature.asc Description: OpenPGP digital signature
Re: [VOTE] Release Maven Site Plugin version 4.0.0-M14
Hi, There was a longer discussion in https://www.mail-archive.com/dev@maven.apache.org/msg132078.html (for some reason cannot find the thread in https://lists.apache.org/list.html?dev@maven.apache.org) and we kind of came to an agreement to reserve plugin major version 4 for plugins leveraging Maven 4 API. So should we rename this to m-site-p 3.13.x? This requires adaptation in the source code with regards to the since javadoc tag. WDYT? Konrad > On 5. May 2024, at 21:29, Michael Osipov wrote: > > Hi, > > we solved 4 issues: > https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12317923=12354123 > > There are still a couple of issues left in JIRA: > https://issues.apache.org/jira/issues/?jql=project%20%3D%20MSITE%20AND%20resolution%20%3D%20Unresolved > > Staging repo: > https://repository.apache.org/content/repositories/maven-2109/ > https://repository.apache.org/content/repositories/maven-2109/org/apache/maven/plugins/maven-site-plugin/4.0.0-M14/maven-site-plugin-4.0.0-M14-source-release.zip > > Source release checksum(s): > maven-site-plugin-4.0.0-M14-source-release.zip > sha512: > cf9b896e1bc10b0bb81ded66f343e478da4da21300d10ac586ac08a8640bc7c11f25ff49d8f443c12e98011608c5d2db308d9b0b7ec1d9378d84616712b5b660 > > Staging site: > https://maven.apache.org/plugins-archives/maven-site-plugin-LATEST/ > > Guide to testing staged releases: > https://maven.apache.org/guides/development/guide-testing-releases.html > > Vote open for 72 hours. > > [ ] +1 > [ ] +0 > [ ] -1 > > - > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > For additional commands, e-mail: dev-h...@maven.apache.org >
[jira] [Updated] (JCR-5051) ISO9075.encodePath/encode should preserve wildcard
[
https://issues.apache.org/jira/browse/JCR-5051?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Konrad Windszus updated JCR-5051:
-
Description:
Currently the wildcard {{"*"}} is escaped as well to {{"_x002a_"}}.
This is not intended as in the context of XPath the wildcard is an allowed
character in the grammar
(https://www.w3.org/TR/xpath20/#prod-xpath-ElementNameOrWildcard).
Not sure if ISO9075 is used for other purposes so it might be better to
explicitly add another method to keep the wildcard in place.
was:
Currently the wildcard {{"*"}} is escaped as well to {{"_x002a_"}}.
This is not intended as in the context of XPath the wildcard is an allowed
character in the grammar
(https://www.w3.org/TR/xpath20/#prod-xpath-ElementNameOrWildcard).
Not sure if ISO9075 is used for other purposes so it might be better to
explicitly add another method to keep the wildcard in place.
> ISO9075.encodePath/encode should preserve wildcard
> --
>
> Key: JCR-5051
> URL: https://issues.apache.org/jira/browse/JCR-5051
> Project: Jackrabbit Content Repository
> Issue Type: New Feature
> Components: jackrabbit-jcr-commons
>Reporter: Konrad Windszus
>Priority: Major
>
> Currently the wildcard {{"*"}} is escaped as well to {{"_x002a_"}}.
> This is not intended as in the context of XPath the wildcard is an allowed
> character in the grammar
> (https://www.w3.org/TR/xpath20/#prod-xpath-ElementNameOrWildcard).
> Not sure if ISO9075 is used for other purposes so it might be better to
> explicitly add another method to keep the wildcard in place.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (JCR-5051) ISO9075.encodePath/encode should preserve wildcard
[
https://issues.apache.org/jira/browse/JCR-5051?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Konrad Windszus updated JCR-5051:
-
Description:
Currently the wildcard {{"*"}} is escaped as well to {{"_x002a_"}}.
This is not intended as in the context of XPath the wildcard is an allowed
character in the grammar
(https://www.w3.org/TR/xpath20/#prod-xpath-ElementNameOrWildcard).
Not sure if ISO9075 is used for other purposes so it might be better to
explicitly add another method to keep the wildcard in place.
was:
Currently the wildcard {{*}} is escaped as well to {{_x002a_}}.
This is not intended as in the context of XPath the wildcard is an allowed
character in the grammar
(https://www.w3.org/TR/xpath20/#prod-xpath-ElementNameOrWildcard).
Not sure if ISO9075 is used for other purposes so it might be better to
explicitly add another method to keep the wildcard in place.
> ISO9075.encodePath/encode should preserve wildcard
> --
>
> Key: JCR-5051
> URL: https://issues.apache.org/jira/browse/JCR-5051
> Project: Jackrabbit Content Repository
> Issue Type: New Feature
> Components: jackrabbit-jcr-commons
>Reporter: Konrad Windszus
>Priority: Major
>
> Currently the wildcard {{"*"}} is escaped as well to {{"_x002a_"}}.
> This is not intended as in the context of XPath the wildcard is an allowed
> character in the grammar
> (https://www.w3.org/TR/xpath20/#prod-xpath-ElementNameOrWildcard).
> Not sure if ISO9075 is used for other purposes so it might be better to
> explicitly add another method to keep the wildcard in place.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (JCR-5051) ISO9075.encodePath/encode should preserve wildcard
Konrad Windszus created JCR-5051:
Summary: ISO9075.encodePath/encode should preserve wildcard
Key: JCR-5051
URL: https://issues.apache.org/jira/browse/JCR-5051
Project: Jackrabbit Content Repository
Issue Type: New Feature
Components: jackrabbit-jcr-commons
Reporter: Konrad Windszus
Currently the wildcard {{*}} is escaped as well to {{_x002a_}}.
This is not intended as in the context of XPath the wildcard is an allowed
character in the grammar
(https://www.w3.org/TR/xpath20/#prod-xpath-ElementNameOrWildcard).
Not sure if ISO9075 is used for other purposes so it might be better to
explicitly add another method to keep the wildcard in place.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[plasmashell] [Bug 485456] With Qt 6.7, System Tray popup is inappropriately resized to a tiny nub
https://bugs.kde.org/show_bug.cgi?id=485456 Konrad Materka changed: What|Removed |Added CC||k...@rad1an.aleeas.com --- Comment #24 from Konrad Materka --- *** Bug 486476 has been marked as a duplicate of this bug. *** -- You are receiving this mail because: You are watching all bug changes.
