| Message ID | 20220408045908.21671-14-rex-bc.chen@mediatek.com (mailing list archive) |
|---|---|
| State | Superseded, archived |
| Headers | show |
| Series | cpufreq: mediatek: Cleanup and support MT8183 and MT8186 | expand |
Il 08/04/22 06:59, Rex-BC Chen ha scritto: > From: Jia-Wei Chang <jia-wei.chang@mediatek.com> > > In some MediaTek SoCs, like MT8183, CPU and CCI share the same power > supplies. Cpufreq needs to check if CCI devfreq exists and wait until > CCI devfreq ready before scaling frequency. > > - Add is_ccifreq_ready() to link CCI device to CPI, and CPU will start > DVFS when CCI is ready. > - Add platform data for MT8183. > > Signed-off-by: Jia-Wei Chang <jia-wei.chang@mediatek.com> > --- > drivers/cpufreq/mediatek-cpufreq.c | 69 +++++++++++++++++++++++++++++- > 1 file changed, 68 insertions(+), 1 deletion(-) > > diff --git a/drivers/cpufreq/mediatek-cpufreq.c b/drivers/cpufreq/mediatek-cpufreq.c > index b08ab7c14818..cebe5af2ef5d 100644 > --- a/drivers/cpufreq/mediatek-cpufreq.c > +++ b/drivers/cpufreq/mediatek-cpufreq.c > @@ -22,6 +22,7 @@ struct mtk_cpufreq_platform_data { > int proc_max_volt; > int sram_min_volt; > int sram_max_volt; > + bool is_ccifreq_support; bool ccifreq_supported; looks better. > }; > > /* > @@ -38,6 +39,7 @@ struct mtk_cpufreq_platform_data { > struct mtk_cpu_dvfs_info { > struct cpumask cpus; > struct device *cpu_dev; > + struct device *cci_dev; > struct regulator *proc_reg; > struct regulator *sram_reg; > struct clk *cpu_clk; > @@ -52,6 +54,7 @@ struct mtk_cpu_dvfs_info { > int opp_cpu; > unsigned long opp_freq; > const struct mtk_cpufreq_platform_data *soc_data; > + bool is_ccifreq_bounded; bool ccifreq_bound; looks better. > }; > > static struct platform_device *cpufreq_pdev; > @@ -171,6 +174,29 @@ static int mtk_cpufreq_set_voltage(struct mtk_cpu_dvfs_info *info, int vproc) > return ret; > } > > +static bool is_ccifreq_ready(struct mtk_cpu_dvfs_info *info) > +{ > + struct device_link *sup_link; > + > + if (info->is_ccifreq_bounded) > + return true; > + > + sup_link = device_link_add(info->cpu_dev, info->cci_dev, > + DL_FLAG_AUTOREMOVE_CONSUMER); > + if (!sup_link) { > + dev_err(info->cpu_dev, "cpu%d: sup_link is NULL\n", > + info->opp_cpu); Please, don't break this line: 84 columns are ok. > + return false; > + } > + > + if (sup_link->supplier->links.status != DL_DEV_DRIVER_BOUND) > + return false; > + > + info->is_ccifreq_bounded = true; > + > + return true; > +} > + > static int mtk_cpufreq_set_target(struct cpufreq_policy *policy, > unsigned int index) > { > @@ -183,6 +209,9 @@ static int mtk_cpufreq_set_target(struct cpufreq_policy *policy, > long freq_hz, old_freq_hz; > int vproc, old_vproc, inter_vproc, target_vproc, ret; > > + if (info->soc_data->is_ccifreq_support && !is_ccifreq_ready(info)) > + return 0; Honestly, I think that pretending that everything is alright and faking set_target success is *not* a good idea... You should return -EAGAIN here, not zero. Regards, Angelo
Rex-BC Chen <rex-bc.chen@mediatek.com> writes: > From: Jia-Wei Chang <jia-wei.chang@mediatek.com> > > In some MediaTek SoCs, like MT8183, CPU and CCI share the same power > supplies. Cpufreq needs to check if CCI devfreq exists and wait until > CCI devfreq ready before scaling frequency. > > - Add is_ccifreq_ready() to link CCI device to CPI, and CPU will start > DVFS when CCI is ready. > - Add platform data for MT8183. > > Signed-off-by: Jia-Wei Chang <jia-wei.chang@mediatek.com> The checks here are not enough, and will lead to unexpected behavior. IIUC, before doing DVFS, you're checking: 1) if the "cci" DT node is present and 2) if the driver for that device is bound If both those conditions are not met, you don't actually fail, you just silently do nothing in ->set_target(). As Angelo pointed out also, this is not a good idea, and will be rather confusing to users. The same thing would happen if the cci DT node was present, but the CCI devfreq driver was disabled. Silent failure would also be quite unexpected behavior. Similarily, if the cci DT node is not present at all (like it is in current upstream DT), this CPUfreq driver will silently do nothing. Not good. So, this patch needs to handle several scenarios: 1) CCI DT node not present In this case, the driver should still operate normally. With no CCI node, or driver there's no conflict. 2) CCI DT present/enabled but not yet bound In this case, you could return -EAGAIN as suggested by Angelo, or maybe better, it should do a deferred probe. 3) CCI DT present, but driver disabled This case is similar to (1), this driver should continue to work. Kevin
On Fri, 2022-04-08 at 15:37 +0200, AngeloGioacchino Del Regno wrote: > Il 08/04/22 06:59, Rex-BC Chen ha scritto: > > From: Jia-Wei Chang <jia-wei.chang@mediatek.com> > > > > In some MediaTek SoCs, like MT8183, CPU and CCI share the same > > power > > supplies. Cpufreq needs to check if CCI devfreq exists and wait > > until > > CCI devfreq ready before scaling frequency. > > > > - Add is_ccifreq_ready() to link CCI device to CPI, and CPU will > > start > > DVFS when CCI is ready. > > - Add platform data for MT8183. > > > > Signed-off-by: Jia-Wei Chang <jia-wei.chang@mediatek.com> > > --- > > drivers/cpufreq/mediatek-cpufreq.c | 69 > > +++++++++++++++++++++++++++++- > > 1 file changed, 68 insertions(+), 1 deletion(-) > > > > diff --git a/drivers/cpufreq/mediatek-cpufreq.c > > b/drivers/cpufreq/mediatek-cpufreq.c > > index b08ab7c14818..cebe5af2ef5d 100644 > > --- a/drivers/cpufreq/mediatek-cpufreq.c > > +++ b/drivers/cpufreq/mediatek-cpufreq.c > > @@ -22,6 +22,7 @@ struct mtk_cpufreq_platform_data { > > int proc_max_volt; > > int sram_min_volt; > > int sram_max_volt; > > + bool is_ccifreq_support; > > bool ccifreq_supported; looks better. Hello Angelo, Thanks for your review. OK, I will modify this in next version. > > > }; > > > > /* > > @@ -38,6 +39,7 @@ struct mtk_cpufreq_platform_data { > > struct mtk_cpu_dvfs_info { > > struct cpumask cpus; > > struct device *cpu_dev; > > + struct device *cci_dev; > > struct regulator *proc_reg; > > struct regulator *sram_reg; > > struct clk *cpu_clk; > > @@ -52,6 +54,7 @@ struct mtk_cpu_dvfs_info { > > int opp_cpu; > > unsigned long opp_freq; > > const struct mtk_cpufreq_platform_data *soc_data; > > + bool is_ccifreq_bounded; > > bool ccifreq_bound; looks better. > OK, I will modify this in next version. > > }; > > > > static struct platform_device *cpufreq_pdev; > > @@ -171,6 +174,29 @@ static int mtk_cpufreq_set_voltage(struct > > mtk_cpu_dvfs_info *info, int vproc) > > return ret; > > } > > > > +static bool is_ccifreq_ready(struct mtk_cpu_dvfs_info *info) > > +{ > > + struct device_link *sup_link; > > + > > + if (info->is_ccifreq_bounded) > > + return true; > > + > > + sup_link = device_link_add(info->cpu_dev, info->cci_dev, > > + DL_FLAG_AUTOREMOVE_CONSUMER); > > + if (!sup_link) { > > + dev_err(info->cpu_dev, "cpu%d: sup_link is NULL\n", > > + info->opp_cpu); > > Please, don't break this line: 84 columns are ok. > OK, I will modify this in next version. > > + return false; > > + } > > + > > + if (sup_link->supplier->links.status != DL_DEV_DRIVER_BOUND) > > + return false; > > + > > + info->is_ccifreq_bounded = true; > > + > > + return true; > > +} > > + > > static int mtk_cpufreq_set_target(struct cpufreq_policy *policy, > > unsigned int index) > > { > > @@ -183,6 +209,9 @@ static int mtk_cpufreq_set_target(struct > > cpufreq_policy *policy, > > long freq_hz, old_freq_hz; > > int vproc, old_vproc, inter_vproc, target_vproc, ret; > > > > + if (info->soc_data->is_ccifreq_support && > > !is_ccifreq_ready(info)) > > + return 0; > > Honestly, I think that pretending that everything is alright and > faking > set_target success is *not* a good idea... > > You should return -EAGAIN here, not zero. > > Regards, > Angelo > As metioneded by Kevin, I will review these three situations. Thanks for your suggestion. BRs, Rex
On Fri, 2022-04-08 at 13:54 -0700, Kevin Hilman wrote: > Rex-BC Chen <rex-bc.chen@mediatek.com> writes: > > > From: Jia-Wei Chang <jia-wei.chang@mediatek.com> > > > > In some MediaTek SoCs, like MT8183, CPU and CCI share the same > > power > > supplies. Cpufreq needs to check if CCI devfreq exists and wait > > until > > CCI devfreq ready before scaling frequency. > > > > - Add is_ccifreq_ready() to link CCI device to CPI, and CPU will > > start > > DVFS when CCI is ready. > > - Add platform data for MT8183. > > > > Signed-off-by: Jia-Wei Chang <jia-wei.chang@mediatek.com> > > The checks here are not enough, and will lead to unexpected behavior. > IIUC, before doing DVFS, you're checking: > > 1) if the "cci" DT node is present and > 2) if the driver for that device is bound > > If both those conditions are not met, you don't actually fail, you > just > silently do nothing in ->set_target(). As Angelo pointed out also, > this > is not a good idea, and will be rather confusing to users. > > The same thing would happen if the cci DT node was present, but the > CCI > devfreq driver was disabled. Silent failure would also be quite > unexpected behavior. Similarily, if the cci DT node is not present > at > all (like it is in current upstream DT), this CPUfreq driver will > silently do nothing. Not good. > > So, this patch needs to handle several scenarios: > > 1) CCI DT node not present > > In this case, the driver should still operate normally. With no CCI > node, or driver there's no conflict. > > 2) CCI DT present/enabled but not yet bound > > In this case, you could return -EAGAIN as suggested by Angelo, or > maybe > better, it should do a deferred probe. > > 3) CCI DT present, but driver disabled > > This case is similar to (1), this driver should continue to work. > > Kevin Hello Kevin, Thanks for your review. I will review these three situations and do some modification. BRs, Rex
On Fri, 2022-04-08 at 13:54 -0700, Kevin Hilman wrote: > Rex-BC Chen <rex-bc.chen@mediatek.com> writes: > > > From: Jia-Wei Chang <jia-wei.chang@mediatek.com> > > > > In some MediaTek SoCs, like MT8183, CPU and CCI share the same > > power > > supplies. Cpufreq needs to check if CCI devfreq exists and wait > > until > > CCI devfreq ready before scaling frequency. > > > > - Add is_ccifreq_ready() to link CCI device to CPI, and CPU will > > start > > DVFS when CCI is ready. > > - Add platform data for MT8183. > > > > Signed-off-by: Jia-Wei Chang <jia-wei.chang@mediatek.com> > > The checks here are not enough, and will lead to unexpected behavior. > IIUC, before doing DVFS, you're checking: > > 1) if the "cci" DT node is present and > 2) if the driver for that device is bound > > If both those conditions are not met, you don't actually fail, you > just > silently do nothing in ->set_target(). As Angelo pointed out also, > this > is not a good idea, and will be rather confusing to users. > > The same thing would happen if the cci DT node was present, but the > CCI > devfreq driver was disabled. Silent failure would also be quite > unexpected behavior. Similarily, if the cci DT node is not present > at > all (like it is in current upstream DT), this CPUfreq driver will > silently do nothing. Not good. > > So, this patch needs to handle several scenarios: > > 1) CCI DT node not present > > In this case, the driver should still operate normally. With no CCI > node, or driver there's no conflict. > > 2) CCI DT present/enabled but not yet bound > > In this case, you could return -EAGAIN as suggested by Angelo, or > maybe > better, it should do a deferred probe. > > 3) CCI DT present, but driver disabled > > This case is similar to (1), this driver should continue to work. > > Kevin Hello Kevin and Angelo, In my review, if we do not get the link or the link status is not correct between cci and cpufreq in target_index, I think it will never established again for this link. Because it's not checked in probe stage. So I think we just need to deal with the issue without cci device, and don't expect the link between cci and cpufreq will be connected again. If I am wrong, please correct me. Thanks. BRs, Rex
Rex-BC Chen <rex-bc.chen@mediatek.com> writes: > On Fri, 2022-04-08 at 13:54 -0700, Kevin Hilman wrote: >> Rex-BC Chen <rex-bc.chen@mediatek.com> writes: >> >> > From: Jia-Wei Chang <jia-wei.chang@mediatek.com> >> > >> > In some MediaTek SoCs, like MT8183, CPU and CCI share the same >> > power >> > supplies. Cpufreq needs to check if CCI devfreq exists and wait >> > until >> > CCI devfreq ready before scaling frequency. >> > >> > - Add is_ccifreq_ready() to link CCI device to CPI, and CPU will >> > start >> > DVFS when CCI is ready. >> > - Add platform data for MT8183. >> > >> > Signed-off-by: Jia-Wei Chang <jia-wei.chang@mediatek.com> >> >> The checks here are not enough, and will lead to unexpected behavior. >> IIUC, before doing DVFS, you're checking: >> >> 1) if the "cci" DT node is present and >> 2) if the driver for that device is bound >> >> If both those conditions are not met, you don't actually fail, you >> just >> silently do nothing in ->set_target(). As Angelo pointed out also, >> this >> is not a good idea, and will be rather confusing to users. >> >> The same thing would happen if the cci DT node was present, but the >> CCI >> devfreq driver was disabled. Silent failure would also be quite >> unexpected behavior. Similarily, if the cci DT node is not present >> at >> all (like it is in current upstream DT), this CPUfreq driver will >> silently do nothing. Not good. >> >> So, this patch needs to handle several scenarios: >> >> 1) CCI DT node not present >> >> In this case, the driver should still operate normally. With no CCI >> node, or driver there's no conflict. >> >> 2) CCI DT present/enabled but not yet bound >> >> In this case, you could return -EAGAIN as suggested by Angelo, or >> maybe >> better, it should do a deferred probe. >> >> 3) CCI DT present, but driver disabled >> >> This case is similar to (1), this driver should continue to work. >> >> Kevin > > Hello Kevin and Angelo, > > In my review, if we do not get the link or the link status is not > correct between cci and cpufreq in target_index, I think it will never > established again for this link. > Because it's not checked in probe stage. > > So I think we just need to deal with the issue without cci device, and > don't expect the link between cci and cpufreq will be connected again. > > If I am wrong, please correct me. I don't fully understand your questions, but I think what your getting at suggest that you might need to use deferred probe to handle the case where the ordering of CCI and cpufreq probing is not predictable. Kevin
On Mon, 2022-04-11 at 11:13 -0700, Kevin Hilman wrote: > Rex-BC Chen <rex-bc.chen@mediatek.com> writes: > > > On Fri, 2022-04-08 at 13:54 -0700, Kevin Hilman wrote: > > > Rex-BC Chen <rex-bc.chen@mediatek.com> writes: > > > > > > > From: Jia-Wei Chang <jia-wei.chang@mediatek.com> > > > > > > > > In some MediaTek SoCs, like MT8183, CPU and CCI share the same > > > > power > > > > supplies. Cpufreq needs to check if CCI devfreq exists and wait > > > > until > > > > CCI devfreq ready before scaling frequency. > > > > > > > > - Add is_ccifreq_ready() to link CCI device to CPI, and CPU > > > > will > > > > start > > > > DVFS when CCI is ready. > > > > - Add platform data for MT8183. > > > > > > > > Signed-off-by: Jia-Wei Chang <jia-wei.chang@mediatek.com> > > > > > > The checks here are not enough, and will lead to unexpected > > > behavior. > > > IIUC, before doing DVFS, you're checking: > > > > > > 1) if the "cci" DT node is present and > > > 2) if the driver for that device is bound > > > > > > If both those conditions are not met, you don't actually fail, > > > you > > > just > > > silently do nothing in ->set_target(). As Angelo pointed out > > > also, > > > this > > > is not a good idea, and will be rather confusing to users. > > > > > > The same thing would happen if the cci DT node was present, but > > > the > > > CCI > > > devfreq driver was disabled. Silent failure would also be quite > > > unexpected behavior. Similarily, if the cci DT node is not > > > present > > > at > > > all (like it is in current upstream DT), this CPUfreq driver will > > > silently do nothing. Not good. > > > > > > So, this patch needs to handle several scenarios: > > > > > > 1) CCI DT node not present > > > > > > In this case, the driver should still operate normally. With no > > > CCI > > > node, or driver there's no conflict. > > > > > > 2) CCI DT present/enabled but not yet bound > > > > > > In this case, you could return -EAGAIN as suggested by Angelo, or > > > maybe > > > better, it should do a deferred probe. > > > > > > 3) CCI DT present, but driver disabled > > > > > > This case is similar to (1), this driver should continue to work. > > > > > > Kevin > > > > Hello Kevin and Angelo, > > > > In my review, if we do not get the link or the link status is not > > correct between cci and cpufreq in target_index, I think it will > > never > > established again for this link. > > Because it's not checked in probe stage. > > > > So I think we just need to deal with the issue without cci device, > > and > > don't expect the link between cci and cpufreq will be connected > > again. > > > > If I am wrong, please correct me. > > I don't fully understand your questions, but I think what your > getting > at suggest that you might need to use deferred probe to handle the > case > where the ordering of CCI and cpufreq probing is not predictable. > > Kevin Hello Kevin and Angelo, I can summary what I got now: 1. Why we need cci for cpufreq in MT8183 and MT8186: a. CCI is a mediatek hw module. b. For mediatek SoCs before MT8183, like MT8173, the CCI hw is not introduced. c. The frequency for cci and cpufreq are determined could be configed at bootloader stage, so the frequency when entering kernel is unknown. d. Cpu little core and cci are using the same regulator. e. If we do not control CCI and just adjust the voltage in cpufreq driver. When we adjust the voltage smaller because we need to reduce the frequency, the CCI could run in high frequency which is set in bootloader. This will cause some problem, the cci could crash. Use MT8186 for a example, the bootloader set cci freq as 1.385GHz and cpufreq as 2GHz. If entering kernel and we only adjust the cpufreq voltage, if the cpufreq is under 1.618GHz, the cci will be out of spec. You can refer to the chrome project bootloader "Coreboot" patch: https://review.coreboot.org/c/coreboot/+/59569/2/src/mainboard/google/corsola/romstage.c f. If cpufreq driver wait cci ready, regulator framework will take the highest voltage requests from cci and cpufreq as output so that it prevents from high freqeuncy low voltage crash. d. Therefore, I think it's not a good idea to bypass cci device if the ccifreq_supported is true in MT8183 and MT8186. 2. Check the device link status is DL_DEV_DRIVER_BOUND is used for promising the cci is probed done. 3. About the cpufreq_driver->target_index a. When I trace the common drivers, I found if the return value is not zero, it will be BUG_ON. ref: https://elixir.bootlin.com/linux/latest/source/drivers/cpufreq/cpufreq.c#L1471 b. I also try to move is_ccifreq_ready() to other place, like cpufreq_driver->init and cpufreq probe function. There will be new issue. Do you have any suggetion that we can retern value of DEFER_PROBE? BRs, Rex
Rex-BC Chen <rex-bc.chen@mediatek.com> writes: [...] > I can summary what I got now: > > 1. Why we need cci for cpufreq in MT8183 and MT8186: > a. CCI is a mediatek hw module. > b. For mediatek SoCs before MT8183, like MT8173, the CCI hw > is not introduced. > c. The frequency for cci and cpufreq are determined could > be configed at bootloader stage, so the frequency when > entering kernel is unknown. > d. Cpu little core and cci are using the same regulator. > e. If we do not control CCI and just adjust the voltage in > cpufreq driver. > When we adjust the voltage smaller because we need to reduce > the frequency, the CCI could run in high frequency which is > set in bootloader. > This will cause some problem, the cci could crash. > > Use MT8186 for a example, the bootloader set cci freq as > 1.385GHz and cpufreq as 2GHz. > If entering kernel and we only adjust the cpufreq voltage, if > the cpufreq is under 1.618GHz, the cci will be out of spec. > > f. If cpufreq driver wait cci ready, regulator framework will take > the highest voltage requests from cci and cpufreq as output > so that it prevents from high freqeuncy low voltage crash. > > d. Therefore, I think it's not a good idea to bypass cci device if > the ccifreq_supported is true in MT8183 and MT8186. I do not propose to bypass CCI device. What both Angelo and I are saying is just that you need a better way to handle the cases when CCI is not (yet) enabled. The current way in the propsed patch is not good enough. I fully understand the potential problems with high frequency & low voltage when using a shared regulator. But, I think the problem we're trying to solve here is specific to the initial boot of the platform, while we are waiting for the CCI driver to be loaded. The root of the problem is that the CCI bus has constraints on the voltage regulator that are not defined anywhere until the CCI driver is loaded. So to fix that, you need to either: 1) not allow any voltage changes 2) register the CCI device constraints In the current patch, you attempt to do (1). There's nothing wrong with the idea, we just pointed out problems in your implementation, especially the fact that it does nothing, but it "succeeds" so the CPUfreq framework will think the OPPs are different from what they actually are. Just an idea, but another option could be (2). While waiting for the CCI device to be ready, the CPUfreq driver could check the current CCI freq/voltage and set min/max constraints on the regulator that prevent CCI from breaking. These constraints would stay in place until the CCI driver is ready. Once the real CCI driver is ready/registerd these contraints would be removed. Another version of this same idea would be to check the CCI freq/voltage and then limit the OPPs available to CPUfreq to only the ones that would not break CCI. Then, when CCI is ready/registered, you remove the limits. > 2. Check the device link status is DL_DEV_DRIVER_BOUND is used for > promising the cci is probed done. > > 3. About the cpufreq_driver->target_index > a. When I trace the common drivers, I found if the return value is > not zero, it will be BUG_ON. > ref: > https://elixir.bootlin.com/linux/latest/source/drivers/cpufreq/cpufreq.c#L1471 Right, you should not try to do deferred probe in the ->set_target() callback. Deferred probe is meant for init/probe time. > b. I also try to move is_ccifreq_ready() to other place, like > cpufreq_driver->init and cpufreq probe function. > There will be new issue. Do you have any suggetion that we can > retern value of DEFER_PROBE? The only appropriate place is in the probe function. Kevin
On Tue, 2022-04-12 at 11:50 -0700, Kevin Hilman wrote: > Rex-BC Chen <rex-bc.chen@mediatek.com> writes: > > [...] > > > I can summary what I got now: > > > > 1. Why we need cci for cpufreq in MT8183 and MT8186: > > a. CCI is a mediatek hw module. > > b. For mediatek SoCs before MT8183, like MT8173, the CCI hw > > is not introduced. > > c. The frequency for cci and cpufreq are determined could > > be configed at bootloader stage, so the frequency when > > entering kernel is unknown. > > d. Cpu little core and cci are using the same regulator. > > e. If we do not control CCI and just adjust the voltage in > > cpufreq driver. > > When we adjust the voltage smaller because we need to reduce > > the frequency, the CCI could run in high frequency which is > > set in bootloader. > > This will cause some problem, the cci could crash. > > > > Use MT8186 for a example, the bootloader set cci freq as > > 1.385GHz and cpufreq as 2GHz. > > If entering kernel and we only adjust the cpufreq voltage, if > > the cpufreq is under 1.618GHz, the cci will be out of spec. > > > > f. If cpufreq driver wait cci ready, regulator framework will > > take > > the highest voltage requests from cci and cpufreq as output > > so that it prevents from high freqeuncy low voltage crash. > > > > d. Therefore, I think it's not a good idea to bypass cci device > > if > > the ccifreq_supported is true in MT8183 and MT8186. > > I do not propose to bypass CCI device. What both Angelo and I are > saying is just that you need a better way to handle the cases when > CCI > is not (yet) enabled. The current way in the propsed patch is not > good > enough. > > I fully understand the potential problems with high frequency & low > voltage when using a shared regulator. But, I think the problem > we're > trying to solve here is specific to the initial boot of the platform, > while we are waiting for the CCI driver to be loaded. > > The root of the problem is that the CCI bus has constraints on the > voltage regulator that are not defined anywhere until the CCI driver > is > loaded. So to fix that, you need to either: > > 1) not allow any voltage changes > 2) register the CCI device constraints > > In the current patch, you attempt to do (1). There's nothing wrong > with > the idea, we just pointed out problems in your implementation, > especially the fact that it does nothing, but it "succeeds" so the > CPUfreq framework will think the OPPs are different from what they > actually are. > > Just an idea, but another option could be (2). While waiting for the > CCI device to be ready, the CPUfreq driver could check the current > CCI > freq/voltage and set min/max constraints on the regulator that > prevent > CCI from breaking. These constraints would stay in place until the > CCI > driver is ready. Once the real CCI driver is ready/registerd these > contraints would be removed. > > Another version of this same idea would be to check the CCI > freq/voltage > and then limit the OPPs available to CPUfreq to only the ones that > would > not break CCI. Then, when CCI is ready/registered, you remove the > limits. > > > 2. Check the device link status is DL_DEV_DRIVER_BOUND is used for > > promising the cci is probed done. > > > > 3. About the cpufreq_driver->target_index > > a. When I trace the common drivers, I found if the return value > > is > > not zero, it will be BUG_ON. > > ref: > > https://urldefense.com/v3/__https://elixir.bootlin.com/linux/latest/source/drivers/cpufreq/cpufreq.c*L1471__;Iw!!CTRNKA9wMg0ARbw!wgawOs1JSuJihgxA1nxhbd2Ekoys_bPCAlIH9YJhe2N9ckG6O1mDB-7zqSf6x2MhCfXo$ > > > > Right, you should not try to do deferred probe in the ->set_target() > callback. Deferred probe is meant for init/probe time. > > > b. I also try to move is_ccifreq_ready() to other place, like > > cpufreq_driver->init and cpufreq probe function. > > There will be new issue. Do you have any suggetion that we > > can > > retern value of DEFER_PROBE? > > The only appropriate place is in the probe function. > > Kevin Hello Kevin, From the Chanwoo's devfreq passive govonor series, it's impossible to let cci devreq probed done before cpufreq because the passive govonor will search for cpufreq node and use it. Ref: function: cpufreq_passive_register_notifier() https://git.kernel.org/pub/scm/linux/kernel/git/chanwoo/linux.git/commit/?h=devfreq-testing&id=b670978ddc43eb0c60735c3af6e4a370603ab673 After I discuss with Angelo and Jia-wei, we think we are keeping the function in target_index and if the cci is not ready we will use the voltage which is set by bootloader to prevent high freqeuncy low voltage crash. And then we can keep seting the target frequency. We assume the setting of bootloader is correct and we can do this. For the SoCs that including ci hardware (8183 and 8186), we think it's not ok if we don't probe cci correctly. If we failed to get cci node, I think we sould return -ENODEV and the probe of cpufreq failed. What do you think the solution? BRs, Rex
Rex-BC Chen <rex-bc.chen@mediatek.com> writes: [...] > From the Chanwoo's devfreq passive govonor series, it's impossible to > let cci devreq probed done before cpufreq because the passive govonor > will search for cpufreq node and use it. > > Ref: function: cpufreq_passive_register_notifier() > > https://git.kernel.org/pub/scm/linux/kernel/git/chanwoo/linux.git/commit/?h=devfreq-testing&id=b670978ddc43eb0c60735c3af6e4a370603ab673 Well this is a problem, because CCI depends on CPUfreq, but CPUfreq depends on CCI, so one of them has to load and then wait for the other. > After I discuss with Angelo and Jia-wei, we think we are keeping the > function in target_index and if the cci is not ready we will use the > voltage which is set by bootloader to prevent high freqeuncy low > voltage crash. And then we can keep seting the target frequency. > > We assume the setting of bootloader is correct and we can do this. I'm still not crazy about this because you're lying to the CPUfreq framework. It's requesting one OPP, but you're not setting that, you're just keeping the bootloader frequency. In my earlier reply, I gave two other options for handling this. 1) set a (temporary) constraint on the voltage regulator so that it cannot change. or more clean, IMO: 2) set a CPUfreq policy that restricts available OPPs to ones that will not break CCI. Either of these solutions allow you to load the CPUfreq driver early, and then wait for the CCI driver to be ready before removing the restrictions. > For the SoCs that including ci hardware (8183 and 8186), we think it's > not ok if we don't probe cci correctly. > If we failed to get cci node, I think we sould return -ENODEV and the > probe of cpufreq failed. > > What do you think the solution? I think it would be better if CPUfreq probes sucessfully, but restricts the OPPs available until CCI is ready. If CCI fails to probe/load, you still have a working CPUfreq driver, it just has a restricted set of OPPs. Kevin
On Wed, 2022-04-13 at 14:41 -0700, Kevin Hilman wrote: > Rex-BC Chen <rex-bc.chen@mediatek.com> writes: > > [...] > > > From the Chanwoo's devfreq passive govonor series, it's impossible > > to > > let cci devreq probed done before cpufreq because the passive > > govonor > > will search for cpufreq node and use it. > > > > Ref: function: cpufreq_passive_register_notifier() > > > > https://urldefense.com/v3/__https://git.kernel.org/pub/scm/linux/kernel/git/chanwoo/linux.git/commit/?h=devfreq-testing&id=b670978ddc43eb0c60735c3af6e4a370603ab673__;!!CTRNKA9wMg0ARbw!z58Lc1p9REo88oHn-NkxroN_fBd0TsHYmhscNZwnWwT71ecRkTeqZ6vFl5l7HpkTdM6t$ > > > > Well this is a problem, because CCI depends on CPUfreq, but CPUfreq > depends on CCI, so one of them has to load and then wait for the > other. > > > After I discuss with Angelo and Jia-wei, we think we are keeping > > the > > function in target_index and if the cci is not ready we will use > > the > > voltage which is set by bootloader to prevent high freqeuncy low > > voltage crash. And then we can keep seting the target frequency. > > > > > We assume the setting of bootloader is correct and we can do this. > > I'm still not crazy about this because you're lying to the CPUfreq > framework. It's requesting one OPP, but you're not setting that, > you're > just keeping the bootloader frequency. > > In my earlier reply, I gave two other options for handling this. > > 1) set a (temporary) constraint on the voltage regulator so that it > cannot change. > > or more clean, IMO: > > 2) set a CPUfreq policy that restricts available OPPs to ones that > will > not break CCI. > > Either of these solutions allow you to load the CPUfreq driver early, > and then wait for the CCI driver to be ready before removing the > restrictions. Hello Kevin, I think I do not describe this clearly. The proposal is: In cpufreq probe: we record the voltage value which is set by bootloader. In mtk_cpufreq_set_target(): We do NOT directly return 0. Instead, we will find the voltage of target cpufreq and use the value max(booting voltage, target cpufreq voltage) mtk_cpufreq_set_target() { /* NOT return 0 if !is_ccifreq_ready */ .... vproc = get voltage of target cpufreq from opp. if (ccifreq_supported && !is_ccifreq_ready) vproc = max(vproc, vproc_on_boot) //setting voltage and target frequency .... } > > > For the SoCs that including ci hardware (8183 and 8186), we think > > it's > > not ok if we don't probe cci correctly. > > If we failed to get cci node, I think we sould return -ENODEV and > > the > > probe of cpufreq failed. > > > > What do you think the solution? > > I think it would be better if CPUfreq probes sucessfully, but > restricts > the OPPs available until CCI is ready. If CCI fails to probe/load, > you > still have a working CPUfreq driver, it just has a restricted set of > OPPs. > > Kevin If we can use the solution. I think it will be ok for this situation. Thanks! BRs, Rex
Rex-BC Chen <rex-bc.chen@mediatek.com> writes: > On Wed, 2022-04-13 at 14:41 -0700, Kevin Hilman wrote: >> Rex-BC Chen <rex-bc.chen@mediatek.com> writes: >> >> [...] >> >> > From the Chanwoo's devfreq passive govonor series, it's impossible >> > to >> > let cci devreq probed done before cpufreq because the passive >> > govonor >> > will search for cpufreq node and use it. >> > >> > Ref: function: cpufreq_passive_register_notifier() >> > >> > > https://urldefense.com/v3/__https://git.kernel.org/pub/scm/linux/kernel/git/chanwoo/linux.git/commit/?h=devfreq-testing&id=b670978ddc43eb0c60735c3af6e4a370603ab673__;!!CTRNKA9wMg0ARbw!z58Lc1p9REo88oHn-NkxroN_fBd0TsHYmhscNZwnWwT71ecRkTeqZ6vFl5l7HpkTdM6t$ >> > >> >> Well this is a problem, because CCI depends on CPUfreq, but CPUfreq >> depends on CCI, so one of them has to load and then wait for the >> other. >> >> > After I discuss with Angelo and Jia-wei, we think we are keeping >> > the >> > function in target_index and if the cci is not ready we will use >> > the >> > voltage which is set by bootloader to prevent high freqeuncy low >> > voltage crash. And then we can keep seting the target frequency. >> > >> >> > We assume the setting of bootloader is correct and we can do this. >> >> I'm still not crazy about this because you're lying to the CPUfreq >> framework. It's requesting one OPP, but you're not setting that, >> you're >> just keeping the bootloader frequency. >> >> In my earlier reply, I gave two other options for handling this. >> >> 1) set a (temporary) constraint on the voltage regulator so that it >> cannot change. >> >> or more clean, IMO: >> >> 2) set a CPUfreq policy that restricts available OPPs to ones that >> will >> not break CCI. >> >> Either of these solutions allow you to load the CPUfreq driver early, >> and then wait for the CCI driver to be ready before removing the >> restrictions. > > Hello Kevin, > > I think I do not describe this clearly. > The proposal is: > > In cpufreq probe: > we record the voltage value which is set by bootloader. > > In mtk_cpufreq_set_target(): > We do NOT directly return 0. > Instead, we will find the voltage of target cpufreq and use the value > max(booting voltage, target cpufreq voltage) > > mtk_cpufreq_set_target() { > /* NOT return 0 if !is_ccifreq_ready */ > .... > vproc = get voltage of target cpufreq from opp. > > if (ccifreq_supported && !is_ccifreq_ready) > vproc = max(vproc, vproc_on_boot) > > //setting voltage and target frequency > .... > } You explained this well, but it's still not an appropriate solution IMO, because you're still not setting the target that is requested by the CPUfreq core. The job of ->set_target() is to set the frequency *requested by CPUfreq core*. If you cannot do that, you should return failure. What you posted in the original patch and what you're proposing here is to ignore the frequency passed to ->set_target() and do something else. In the orignal patch, you propose do to nothing. Now, you're ignoring the target passed in and setting something else. In both cases, the CPUfreq core things you have successfuly set the frequency requested, but you have not. This means there's a mismatch between what the CPUfreq core & governer things the frequency is and what is actually set. *This* is the part that I think is wrong. Instead, the proper way of restricting available frequencies is to use governors or policies. This ensures that the core & governors are aligned with what the platform driver actually does. As I proposed earlier, I think a clean solution to this problem is to create a temporary policy at probe time that restricts the available OPPs based on what the current CCI freq/voltage are. Once CCI driver is loaded and working, this policy can be removed. Kevin
On Thu, 2022-04-14 at 14:48 -0700, Kevin Hilman wrote: > Rex-BC Chen <rex-bc.chen@mediatek.com> writes: > > > On Wed, 2022-04-13 at 14:41 -0700, Kevin Hilman wrote: > > > Rex-BC Chen <rex-bc.chen@mediatek.com> writes: > > > > > > [...] > > > > > > > From the Chanwoo's devfreq passive govonor series, it's > > > > impossible > > > > to > > > > let cci devreq probed done before cpufreq because the passive > > > > govonor > > > > will search for cpufreq node and use it. > > > > > > > > Ref: function: cpufreq_passive_register_notifier() > > > > > > > > > > > > https://urldefense.com/v3/__https://git.kernel.org/pub/scm/linux/kernel/git/chanwoo/linux.git/commit/?h=devfreq-testing&id=b670978ddc43eb0c60735c3af6e4a370603ab673__;!!CTRNKA9wMg0ARbw!z58Lc1p9REo88oHn-NkxroN_fBd0TsHYmhscNZwnWwT71ecRkTeqZ6vFl5l7HpkTdM6t$ > > > > > > > > > > Well this is a problem, because CCI depends on CPUfreq, but > > > CPUfreq > > > depends on CCI, so one of them has to load and then wait for the > > > other. > > > > > > > After I discuss with Angelo and Jia-wei, we think we are > > > > keeping > > > > the > > > > function in target_index and if the cci is not ready we will > > > > use > > > > the > > > > voltage which is set by bootloader to prevent high freqeuncy > > > > low > > > > voltage crash. And then we can keep seting the target > > > > frequency. > > > > > > > > > > > We assume the setting of bootloader is correct and we can do > > > this. > > > > > > I'm still not crazy about this because you're lying to the > > > CPUfreq > > > framework. It's requesting one OPP, but you're not setting that, > > > you're > > > just keeping the bootloader frequency. > > > > > > In my earlier reply, I gave two other options for handling this. > > > > > > 1) set a (temporary) constraint on the voltage regulator so that > > > it > > > cannot change. > > > > > > or more clean, IMO: > > > > > > 2) set a CPUfreq policy that restricts available OPPs to ones > > > that > > > will > > > not break CCI. > > > > > > Either of these solutions allow you to load the CPUfreq driver > > > early, > > > and then wait for the CCI driver to be ready before removing the > > > restrictions. > > > > Hello Kevin, > > > > I think I do not describe this clearly. > > The proposal is: > > > > In cpufreq probe: > > we record the voltage value which is set by bootloader. > > > > In mtk_cpufreq_set_target(): > > We do NOT directly return 0. > > Instead, we will find the voltage of target cpufreq and use the > > value > > max(booting voltage, target cpufreq voltage) > > > > mtk_cpufreq_set_target() { > > /* NOT return 0 if !is_ccifreq_ready */ > > .... > > vproc = get voltage of target cpufreq from opp. > > > > if (ccifreq_supported && !is_ccifreq_ready) > > vproc = max(vproc, vproc_on_boot) > > > > //setting voltage and target frequency > > .... > > } > > You explained this well, but it's still not an appropriate solution > IMO, > because you're still not setting the target that is requested by the > CPUfreq core. > > The job of ->set_target() is to set the frequency *requested by > CPUfreq > core*. If you cannot do that, you should return failure. What you > posted > in the original patch and what you're proposing here is to ignore the > frequency passed to ->set_target() and do something else. In the > orignal patch, you propose do to nothing. Now, you're ignoring the > target passed in and setting something else. In both cases, the > CPUfreq > core things you have successfuly set the frequency requested, but you > have not. This means there's a mismatch between what the CPUfreq > core & > governer things the frequency is and what is actually set. *This* is > the part that I think is wrong. > > Instead, the proper way of restricting available frequencies is to > use > governors or policies. This ensures that the core & governors are > aligned with what the platform driver actually does. > > As I proposed earlier, I think a clean solution to this problem is to > create a temporary policy at probe time that restricts the available > OPPs based on what the current CCI freq/voltage are. Once CCI driver > is > loaded and working, this policy can be removed. > > Kevin > > Hello Kevin, In new proposal, we DO set the cpufreq passed by cpufreq core. We just not set the corresponding voltage of target frequency which is lookedup from opp table. Actually, because of the shared regulator, corresponding voltage is not always set. I take this for example: ---------- Assumption: - The opp table and voltage in this example are just a example, and it is not for any actual SoCs. - We just use one regulator instead of two. (like proc and sram) - cpufreq and mediatek cci devfreq share the same regulator_0. OPP table for cpufreq: target freq => min reguired voltage 2.0GHz => 1.0V 1.8GHZ => 0.9V 1.5GHz => 0.6V OPP table for mediatek cci devfreq: target freq => min reguired voltage 1.4GHz => 1.2V 1.0GHz => 0.8V 1. For normal case: (regulator_0 is already registered by cpufreq and cci) - When the cpufreq want to adjust to 1.5GHz, from the opp table the voltage sholud be 0.6V. - When the cci want to adjust to 1.4GHz, from the opp table the voltage sholud be 1.2V. - cpufreq driver use the regulator_set_voltage() to set the voltage, but the function will use 1.2V(ref:[1]) 2. For our new proposed solution: (regulator_0 is registered by cpufreq but is not registered by cci) - Assume the freqs when booting to kernel are: 1.8GHz for cpufreq (min 0.9V) and 1.0GHz for cci (min 0.8V). The voltage when booting to kernel(voltage_on_boot) should be 0.9V to let cpufreq and cci work correctly. - When cpufreq want to set target freq to 1.5GHz the voltage from opp table is 0.6V and we compare this voltage with voltage_on_boot(0.9V). We will choose the max voltage 0.9V to prevent crash issue. (This is original covered by regulator_set_voltage() if regulator_0 is registered by both cci and cpufre.) - When the voltage is choosed, we will set the cpufreq to 1.5GHz while the voltage is safe for both cpufreq and cci. ---------- In summary, we think it's a proper solution to cover the situation when cci is not probed. I think there is something to improve: We can choose to lookup cci opp table using cci freq to determine the voltage instead of voltage_on_boot. But IMO, it's not neccessary to register cci opp table inside cpufreq driver just for the short period. Because I finish to prepare other patches and I think we also can take a look at other patches which are including some cleanup, I will send next version today. If there is any concern and question, we can discuss in next version. Thanks for your big support! [1]: https://elixir.bootlin.com/linux/latest/source/drivers/regulator/core.c#L4022 BRs, Rex
Rex-BC Chen <rex-bc.chen@mediatek.com> writes: > On Thu, 2022-04-14 at 14:48 -0700, Kevin Hilman wrote: [...] >> >> You explained this well, but it's still not an appropriate solution >> IMO, >> because you're still not setting the target that is requested by the >> CPUfreq core. >> >> The job of ->set_target() is to set the frequency *requested by >> CPUfreq >> core*. If you cannot do that, you should return failure. What you >> posted >> in the original patch and what you're proposing here is to ignore the >> frequency passed to ->set_target() and do something else. In the >> orignal patch, you propose do to nothing. Now, you're ignoring the >> target passed in and setting something else. In both cases, the >> CPUfreq >> core things you have successfuly set the frequency requested, but you >> have not. This means there's a mismatch between what the CPUfreq >> core & >> governer things the frequency is and what is actually set. *This* is >> the part that I think is wrong. >> >> Instead, the proper way of restricting available frequencies is to >> use >> governors or policies. This ensures that the core & governors are >> aligned with what the platform driver actually does. >> >> As I proposed earlier, I think a clean solution to this problem is to >> create a temporary policy at probe time that restricts the available >> OPPs based on what the current CCI freq/voltage are. Once CCI driver >> is >> loaded and working, this policy can be removed. >> >> Kevin >> >> > > Hello Kevin, > > In new proposal, we DO set the cpufreq passed by cpufreq core. > We just not set the corresponding voltage of target frequency which > is lookedup from opp table. OK, this makes more sense. I thought you were ignoring frequency change also. [...] > In summary, we think it's a proper solution to cover the situation > when cci is not probed. Yes, this is OK with me. > I think there is something to improve: > We can choose to lookup cci opp table using cci freq to determine > the voltage instead of voltage_on_boot. > But IMO, it's not neccessary to register cci opp table inside cpufreq > driver just for the short period. I agree. > Because I finish to prepare other patches and I think we also can > take a look at other patches which are including some cleanup, I will > send next version today. > If there is any concern and question, we can discuss in next version. OK, I'll have a closer look at the new version. Kevin
diff --git a/drivers/cpufreq/mediatek-cpufreq.c b/drivers/cpufreq/mediatek-cpufreq.c index b08ab7c14818..cebe5af2ef5d 100644 --- a/drivers/cpufreq/mediatek-cpufreq.c +++ b/drivers/cpufreq/mediatek-cpufreq.c @@ -22,6 +22,7 @@ struct mtk_cpufreq_platform_data { int proc_max_volt; int sram_min_volt; int sram_max_volt; + bool is_ccifreq_support; }; /* @@ -38,6 +39,7 @@ struct mtk_cpufreq_platform_data { struct mtk_cpu_dvfs_info { struct cpumask cpus; struct device *cpu_dev; + struct device *cci_dev; struct regulator *proc_reg; struct regulator *sram_reg; struct clk *cpu_clk; @@ -52,6 +54,7 @@ struct mtk_cpu_dvfs_info { int opp_cpu; unsigned long opp_freq; const struct mtk_cpufreq_platform_data *soc_data; + bool is_ccifreq_bounded; }; static struct platform_device *cpufreq_pdev; @@ -171,6 +174,29 @@ static int mtk_cpufreq_set_voltage(struct mtk_cpu_dvfs_info *info, int vproc) return ret; } +static bool is_ccifreq_ready(struct mtk_cpu_dvfs_info *info) +{ + struct device_link *sup_link; + + if (info->is_ccifreq_bounded) + return true; + + sup_link = device_link_add(info->cpu_dev, info->cci_dev, + DL_FLAG_AUTOREMOVE_CONSUMER); + if (!sup_link) { + dev_err(info->cpu_dev, "cpu%d: sup_link is NULL\n", + info->opp_cpu); + return false; + } + + if (sup_link->supplier->links.status != DL_DEV_DRIVER_BOUND) + return false; + + info->is_ccifreq_bounded = true; + + return true; +} + static int mtk_cpufreq_set_target(struct cpufreq_policy *policy, unsigned int index) { @@ -183,6 +209,9 @@ static int mtk_cpufreq_set_target(struct cpufreq_policy *policy, long freq_hz, old_freq_hz; int vproc, old_vproc, inter_vproc, target_vproc, ret; + if (info->soc_data->is_ccifreq_support && !is_ccifreq_ready(info)) + return 0; + inter_vproc = info->intermediate_voltage; freq_hz = freq_table[index].frequency * 1000; @@ -329,6 +358,23 @@ static int mtk_cpufreq_opp_notifier(struct notifier_block *nb, return notifier_from_errno(ret); } +static struct device *of_get_cci(struct device *cpu_dev) +{ + struct device_node *np; + struct platform_device *pdev; + + np = of_parse_phandle(cpu_dev->of_node, "cci", 0); + if (IS_ERR(np)) + return NULL; + + pdev = of_find_device_by_node(np); + of_node_put(np); + if (IS_ERR(pdev)) + return NULL; + + return &pdev->dev; +} + static int mtk_cpu_dvfs_info_init(struct mtk_cpu_dvfs_info *info, int cpu) { struct device *cpu_dev; @@ -343,6 +389,17 @@ static int mtk_cpu_dvfs_info_init(struct mtk_cpu_dvfs_info *info, int cpu) } info->cpu_dev = cpu_dev; + info->is_ccifreq_bounded = false; + if (info->soc_data->is_ccifreq_support) { + info->cci_dev = of_get_cci(info->cpu_dev); + if (IS_ERR_OR_NULL(info->cci_dev)) { + ret = PTR_ERR(info->cci_dev); + dev_err(cpu_dev, "cpu%d: failed to get cci device\n", + cpu); + return -ENODEV; + } + } + info->cpu_clk = clk_get(cpu_dev, "cpu"); if (IS_ERR(info->cpu_clk)) { ret = PTR_ERR(info->cpu_clk); @@ -620,6 +677,16 @@ static const struct mtk_cpufreq_platform_data mtk_platform_data = { .proc_max_volt = 1150000, .sram_min_volt = 0, .sram_max_volt = 1150000, + .is_ccifreq_support = false, +}; + +static const struct mtk_cpufreq_platform_data mt8183_platform_data = { + .min_volt_shift = 100000, + .max_volt_shift = 200000, + .proc_max_volt = 1150000, + .sram_min_volt = 0, + .sram_max_volt = 1150000, + .is_ccifreq_support = true, }; /* List of machines supported by this driver */ @@ -632,7 +699,7 @@ static const struct of_device_id mtk_cpufreq_machines[] __initconst = { { .compatible = "mediatek,mt817x", .data = &mtk_platform_data }, { .compatible = "mediatek,mt8173", .data = &mtk_platform_data }, { .compatible = "mediatek,mt8176", .data = &mtk_platform_data }, - { .compatible = "mediatek,mt8183", .data = &mtk_platform_data }, + { .compatible = "mediatek,mt8183", .data = &mt8183_platform_data }, { .compatible = "mediatek,mt8365", .data = &mtk_platform_data }, { .compatible = "mediatek,mt8516", .data = &mtk_platform_data }, { }