| Message ID | 20240226-gce-client-reg-log-dbg-v1-1-f0fff97c30c7@collabora.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | soc: mediatek: cmdq: Don't log an error when gce-client-reg is not found | expand |
Il 26/02/24 22:31, Nícolas F. R. A. Prado ha scritto: > Most of the callers to this function do not require CMDQ support, it is > optional, so the missing property shouldn't cause an error message. > Furthermore, the callers that do require CMDQ support already log at the > error level when an error is returned. > > Change the log message in this helper to be printed at the debug level > instead. CMDQ is optional, yes. At least, for some devices it is. Full story, though, wants that if you use the CPU for register manipulation instead of programming the GCE (even with threading, fantastic!) you will trigger various performance issues. In the end, you *don't want* to use the CPU if GCE is available! The reasons why the CMDQ/GCE is optional are: - You can check register-by-register r/w for debugging scenarios by using the CPU to manipulate them instead of having something magically doing that for you at a certain (pre-set, yes, but still!) point; - Not all SoCs have the same amount of GCE threads and channels, some may support writing to IP block X through the GCE, some may not, but both may support writing for IP block Y through this mailbox; - MediaTek chose to support both ways, enabling means to debug stuff upstream, the other choice would've been to never support CPU register R/W on some IPs ... and btw - about the last part: Kudos, MediaTek. Now, I also get why you're raising this, but we have to find an agreement here on a different way to proceed that satisfies all of us. First of all.. Which device on which SoC is missing the GCE client register DT property? Do said SoC really not have a GCE client register for that device? Is any upstream supported SoC really lacking a GCE register for the upstream supported IPs? I'm not sure.... :-) P.S.: I guess that the alternative (that I somewhat dislike, and you can probably understand why after reading the reasons above) would be to turn that into a dev_info() instead... P.P.S.: Having no GCE usually means that there's a performance issue! In that case, it's ... a mistake, so, an error, kind-of.... :-) Cheers, Angelo > > Signed-off-by: Nícolas F. R. A. Prado <nfraprado@collabora.com> > --- > drivers/soc/mediatek/mtk-cmdq-helper.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/soc/mediatek/mtk-cmdq-helper.c b/drivers/soc/mediatek/mtk-cmdq-helper.c > index b0cd071c4719..2130ff3aac9e 100644 > --- a/drivers/soc/mediatek/mtk-cmdq-helper.c > +++ b/drivers/soc/mediatek/mtk-cmdq-helper.c > @@ -55,7 +55,7 @@ int cmdq_dev_get_client_reg(struct device *dev, > "mediatek,gce-client-reg", > 3, idx, &spec); > if (err < 0) { > - dev_err(dev, > + dev_dbg(dev, > "error %d can't parse gce-client-reg property (%d)", > err, idx); > > > --- > base-commit: 41913bcddc83b131649ee8ff0d9ff29e01731398 > change-id: 20240226-gce-client-reg-log-dbg-5ae9637a08ed > > Best regards,
On Wed, Feb 28, 2024 at 10:41:15AM +0100, AngeloGioacchino Del Regno wrote: > Il 26/02/24 22:31, Nícolas F. R. A. Prado ha scritto: > > Most of the callers to this function do not require CMDQ support, it is > > optional, so the missing property shouldn't cause an error message. > > Furthermore, the callers that do require CMDQ support already log at the > > error level when an error is returned. > > > > Change the log message in this helper to be printed at the debug level > > instead. > > CMDQ is optional, yes. At least, for some devices it is. > > Full story, though, wants that if you use the CPU for register manipulation > instead of programming the GCE (even with threading, fantastic!) you will > trigger various performance issues. > > In the end, you *don't want* to use the CPU if GCE is available! > > The reasons why the CMDQ/GCE is optional are: > - You can check register-by-register r/w for debugging scenarios by using > the CPU to manipulate them instead of having something magically doing > that for you at a certain (pre-set, yes, but still!) point; > - Not all SoCs have the same amount of GCE threads and channels, some may > support writing to IP block X through the GCE, some may not, but both > may support writing for IP block Y through this mailbox; > - MediaTek chose to support both ways, enabling means to debug stuff upstream, > the other choice would've been to never support CPU register R/W on some IPs > > ... and btw - about the last part: Kudos, MediaTek. Thank you for all the insight! :) > > Now, I also get why you're raising this, but we have to find an agreement here > on a different way to proceed that satisfies all of us. > > First of all.. > > Which device on which SoC is missing the GCE client register DT property? > Do said SoC really not have a GCE client register for that device? This is what I see: On mt8192-asurada-spherion: mediatek-mutex 14001000.mutex: error -2 can't parse gce-client-reg property (0) On mt8195-cherry-tomato: mtk-mmsys 14000000.syscon: error -2 can't parse gce-client-reg property (0) mtk-mmsys 14f00000.syscon: error -2 can't parse gce-client-reg property (0) mediatek-mutex 1c016000.mutex: error -2 can't parse gce-client-reg property (0) mtk-mmsys 1c01a000.syscon: error -2 can't parse gce-client-reg property (0) mediatek-mutex 1c101000.mutex: error -2 can't parse gce-client-reg property (0) So yes, there are a few missing. I will send patches adding them so we can get the best performance possible upstream. > > Is any upstream supported SoC really lacking a GCE register for the upstream > supported IPs? > > I'm not sure.... :-) > > P.S.: I guess that the alternative (that I somewhat dislike, and you can probably > understand why after reading the reasons above) would be to turn that into a > dev_info() instead... > > P.P.S.: Having no GCE usually means that there's a performance issue! In that case, > it's ... a mistake, so, an error, kind-of.... :-) Given the performance impact, I agree that debug, and even info level is not a good option. At the same time, the hardware still works correctly without the GCE (as we have been running it so far without even realizing!), so I think calling it an error is too much, and a warning would be the most suitable level, as we just want to warn userspace: "Hey user, be advised that you're missing GCE, so you'll get worse performance! It will still work though". What do you think? Thanks, Nícolas
Il 28/02/24 15:44, Nícolas F. R. A. Prado ha scritto: > On Wed, Feb 28, 2024 at 10:41:15AM +0100, AngeloGioacchino Del Regno wrote: >> Il 26/02/24 22:31, Nícolas F. R. A. Prado ha scritto: >>> Most of the callers to this function do not require CMDQ support, it is >>> optional, so the missing property shouldn't cause an error message. >>> Furthermore, the callers that do require CMDQ support already log at the >>> error level when an error is returned. >>> >>> Change the log message in this helper to be printed at the debug level >>> instead. >> >> CMDQ is optional, yes. At least, for some devices it is. >> >> Full story, though, wants that if you use the CPU for register manipulation >> instead of programming the GCE (even with threading, fantastic!) you will >> trigger various performance issues. >> >> In the end, you *don't want* to use the CPU if GCE is available! >> >> The reasons why the CMDQ/GCE is optional are: >> - You can check register-by-register r/w for debugging scenarios by using >> the CPU to manipulate them instead of having something magically doing >> that for you at a certain (pre-set, yes, but still!) point; >> - Not all SoCs have the same amount of GCE threads and channels, some may >> support writing to IP block X through the GCE, some may not, but both >> may support writing for IP block Y through this mailbox; >> - MediaTek chose to support both ways, enabling means to debug stuff upstream, >> the other choice would've been to never support CPU register R/W on some IPs >> >> ... and btw - about the last part: Kudos, MediaTek. > > Thank you for all the insight! :) > >> >> Now, I also get why you're raising this, but we have to find an agreement here >> on a different way to proceed that satisfies all of us. >> >> First of all.. >> >> Which device on which SoC is missing the GCE client register DT property? >> Do said SoC really not have a GCE client register for that device? > > This is what I see: > > On mt8192-asurada-spherion: > mediatek-mutex 14001000.mutex: error -2 can't parse gce-client-reg property (0) > > On mt8195-cherry-tomato: > mtk-mmsys 14000000.syscon: error -2 can't parse gce-client-reg property (0) > mtk-mmsys 14f00000.syscon: error -2 can't parse gce-client-reg property (0) > mediatek-mutex 1c016000.mutex: error -2 can't parse gce-client-reg property (0) > mtk-mmsys 1c01a000.syscon: error -2 can't parse gce-client-reg property (0) > mediatek-mutex 1c101000.mutex: error -2 can't parse gce-client-reg property (0) > > So yes, there are a few missing. I will send patches adding them so we can get > the best performance possible upstream. > >> >> Is any upstream supported SoC really lacking a GCE register for the upstream >> supported IPs? >> >> I'm not sure.... :-) >> >> P.S.: I guess that the alternative (that I somewhat dislike, and you can probably >> understand why after reading the reasons above) would be to turn that into a >> dev_info() instead... >> >> P.P.S.: Having no GCE usually means that there's a performance issue! In that case, >> it's ... a mistake, so, an error, kind-of.... :-) > > Given the performance impact, I agree that debug, and even info level is not a > good option. At the same time, the hardware still works correctly without the > GCE (as we have been running it so far without even realizing!), so I think > calling it an error is too much, and a warning would be the most suitable level, > as we just want to warn userspace: "Hey user, be advised that you're missing > GCE, so you'll get worse performance! It will still work though". What do you > think? > Agreed. Cheers, Angelo
diff --git a/drivers/soc/mediatek/mtk-cmdq-helper.c b/drivers/soc/mediatek/mtk-cmdq-helper.c index b0cd071c4719..2130ff3aac9e 100644 --- a/drivers/soc/mediatek/mtk-cmdq-helper.c +++ b/drivers/soc/mediatek/mtk-cmdq-helper.c @@ -55,7 +55,7 @@ int cmdq_dev_get_client_reg(struct device *dev, "mediatek,gce-client-reg", 3, idx, &spec); if (err < 0) { - dev_err(dev, + dev_dbg(dev, "error %d can't parse gce-client-reg property (%d)", err, idx);
Most of the callers to this function do not require CMDQ support, it is optional, so the missing property shouldn't cause an error message. Furthermore, the callers that do require CMDQ support already log at the error level when an error is returned. Change the log message in this helper to be printed at the debug level instead. Signed-off-by: Nícolas F. R. A. Prado <nfraprado@collabora.com> --- drivers/soc/mediatek/mtk-cmdq-helper.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- base-commit: 41913bcddc83b131649ee8ff0d9ff29e01731398 change-id: 20240226-gce-client-reg-log-dbg-5ae9637a08ed Best regards,