| Message ID | 1586946198-13912-1-git-send-email-akashast@codeaurora.org |
|---|---|
| Headers | show |
| Series | Add interconnect support to QSPI and QUP drivers | expand |
Hi Akash, On Wed, Apr 15, 2020 at 03:53:13PM +0530, Akash Asthana wrote: > QUP core clock is shared among all the SE drivers present on particular > QUP wrapper, the system will reset(unclocked access) if earlycon used after > QUP core clock is put to 0 from other SE drivers before real console comes > up. > > As earlycon can't vote for it's QUP core need, to fix this add ICC > support to common/QUP wrapper driver and put vote for QUP core from > probe on behalf of earlycon and remove vote during earlycon exit call. > > Signed-off-by: Akash Asthana <akashast@codeaurora.org> > Reported-by: Matthias Kaehlcke <mka@chromium.org> > --- > Change in V3: > - Add geni_remove_earlycon_icc_vote API that will be used by earlycon > exit function to remove ICC vote for earlyconsole. > - Remove suspend/resume hook for geni-se driver as we are no longer > removing earlyconsole ICC vote from system suspend, we are removing > from earlycon exit. > > Change in V4: > - As per Matthias comment make 'earlycon_wrapper' as static structure. > > drivers/soc/qcom/qcom-geni-se.c | 50 +++++++++++++++++++++++++++++++++++ > drivers/tty/serial/qcom_geni_serial.c | 7 +++++ > include/linux/qcom-geni-se.h | 2 ++ > 3 files changed, 59 insertions(+) > > diff --git a/drivers/soc/qcom/qcom-geni-se.c b/drivers/soc/qcom/qcom-geni-se.c > index 1527bc4..727ad2e 100644 > --- a/drivers/soc/qcom/qcom-geni-se.c > +++ b/drivers/soc/qcom/qcom-geni-se.c > @@ -90,8 +90,11 @@ struct geni_wrapper { > struct device *dev; > void __iomem *base; > struct clk_bulk_data ahb_clks[NUM_AHB_CLKS]; > + struct geni_icc_path to_core; > }; > > +static struct geni_wrapper *earlycon_wrapper; > + > #define QUP_HW_VER_REG 0x4 > > /* Common SE registers */ > @@ -781,6 +784,26 @@ int geni_icc_vote_off(struct geni_se *se) > } > EXPORT_SYMBOL(geni_icc_vote_off); > > +void geni_remove_earlycon_icc_vote(void) > +{ > + struct geni_wrapper *wrapper = earlycon_wrapper; > + struct device_node *parent = of_get_next_parent(wrapper->dev->of_node); > + struct device_node *child; > + > + for_each_child_of_node(parent, child) { > + if (of_device_is_compatible(child, "qcom,geni-se-qup")) { > + wrapper = platform_get_drvdata(of_find_device_by_node( > + child)); > + icc_put(wrapper->to_core.path); > + wrapper->to_core.path = NULL; > + } > + } > + of_node_put(parent); > + > + earlycon_wrapper = NULL; > +} > +EXPORT_SYMBOL(geni_remove_earlycon_icc_vote); > + > static int geni_se_probe(struct platform_device *pdev) > { > struct device *dev = &pdev->dev; > @@ -808,6 +831,33 @@ static int geni_se_probe(struct platform_device *pdev) > } > } > > +#ifdef CONFIG_SERIAL_EARLYCON > + wrapper->to_core.path = devm_of_icc_get(dev, "qup-core"); > + if (IS_ERR(wrapper->to_core.path)) > + return PTR_ERR(wrapper->to_core.path); > + /* > + * Put minmal BW request on core clocks on behalf of early console. > + * The vote will be removed earlycon exit function. > + * > + * Note: We are putting vote on each QUP wrapper instead only to which > + * earlycon is connected because QUP core clock of different wrapper > + * share same voltage domain. If core1 is put to 0, then core2 will > + * also run at 0, if not voted. Default ICC vote will be removed ASA > + * we touch any of the core clock. > + * core1 = core2 = max(core1, core2) > + */ > + ret = icc_set_bw(wrapper->to_core.path, GENI_DEFAULT_BW, 0); > + if (ret) { > + dev_err(&pdev->dev, "%s: ICC BW voting failed for core\n", > + __func__); > + return ret; > + } > + > + if (of_get_compatible_child(pdev->dev.of_node, "qcom,geni-debug-uart")) > + earlycon_wrapper = wrapper; > + of_node_put(pdev->dev.of_node); > +#endif > + > dev_set_drvdata(dev, wrapper); > dev_dbg(dev, "GENI SE Driver probed\n"); > return devm_of_platform_populate(dev); > diff --git a/drivers/tty/serial/qcom_geni_serial.c b/drivers/tty/serial/qcom_geni_serial.c > index 6119090..8c5d97c 100644 > --- a/drivers/tty/serial/qcom_geni_serial.c > +++ b/drivers/tty/serial/qcom_geni_serial.c > @@ -1090,6 +1090,12 @@ static void qcom_geni_serial_earlycon_write(struct console *con, > __qcom_geni_serial_console_write(&dev->port, s, n); > } > > +static int qcom_geni_serial_earlycon_exit(struct console *con) > +{ > + geni_remove_earlycon_icc_vote(); > + return 0; > +} > + > static int __init qcom_geni_serial_earlycon_setup(struct earlycon_device *dev, > const char *opt) > { > @@ -1135,6 +1141,7 @@ static int __init qcom_geni_serial_earlycon_setup(struct earlycon_device *dev, > writel(stop_bit_len, uport->membase + SE_UART_TX_STOP_BIT_LEN); > > dev->con->write = qcom_geni_serial_earlycon_write; > + dev->con->exit = qcom_geni_serial_earlycon_exit; The idea of using the exit handler of the early console to remove the votes seemed appealing at first, however it has a drawback: the bandwidth requests in geni_se_probe() are always made when CONFIG_SERIAL_EARLYCON=y, also when the system doesn't actually use an early console. On such a system the votes would never be removed. A possible alternative could seem to remove the vote at the end of qcom_geni_serial_probe() of the 'normal' console, but it has a similar problem: the system could not even have a normal console. One could possibly argue that CONFIG_SERIAL_QCOM_GENI_CONSOLE shouldn't be set on such a system, however it could be enabled to have a console for development, and in production the same kernel config is used, but with the console disabled through the device tree. I don't really have a good idea at this point, maybe we just need something as ugly as a delayed work to remove the votes. Other suggestions are welcome :)
Hi Akash, On 4/15/20 13:23, Akash Asthana wrote: > Lot of ICC clients are not aware of their actual peak requirement, > most commonly they tend to guess their peak requirement as > (some factor) * avg_bw. > > Centralize random peak guess as twice of average, out into the core > to maintain consistency across the clients. Client can always > override this setting if they got a better idea. I am still not convinced that this is a good idea. If the factor is a random value, then i think that the default factor should be 1. According to your previous reply, it seems that from geni we are requesting double peak bandwidth to compensate for other clients which are not requesting bandwidth for themselves. IMO, this is a bit hacky. Instead of requesting double peak bandwidth, IIUC the correct thing to do here is to request peak_bw = avg_bw for geni. And instead of trying to compensate for other clients "stealing" bandwidth, can't we make these clients vote for their own bandwidth? Or if they really can't, this should be handled elsewhere - maybe in the interconnect platform driver we can reserve some amount of minimum bandwidth for such cases? Thanks, Georgi
Hi Georgi, On 4/23/2020 3:01 PM, Georgi Djakov wrote: > Hi Akash, > > On 4/15/20 13:23, Akash Asthana wrote: >> Lot of ICC clients are not aware of their actual peak requirement, >> most commonly they tend to guess their peak requirement as >> (some factor) * avg_bw. >> >> Centralize random peak guess as twice of average, out into the core >> to maintain consistency across the clients. Client can always >> override this setting if they got a better idea. > I am still not convinced that this is a good idea. If the factor is a random > value, then i think that the default factor should be 1. > > According to your previous reply, it seems that from geni we are requesting > double peak bandwidth to compensate for other clients which are not requesting > bandwidth for themselves. IMO, this is a bit hacky. > > Instead of requesting double peak bandwidth, IIUC the correct thing to do here > is to request peak_bw = avg_bw for geni. And instead of trying to compensate for > other clients "stealing" bandwidth, can't we make these clients vote for their > own bandwidth? Or if they really can't, this should be handled elsewhere - maybe > in the interconnect platform driver we can reserve some amount of minimum > bandwidth for such cases? Okay, probably we can correct clients vote for their own bandwidth or reserve some minimum BW from interconnect platform driver is case of any latency issue observed. I will drop this change in next version. Will it create any difference if peak_bw = 0 instead of peak_bw = avg_bw? In my understanding peak_bw <= avg_bw is no-ops, it won't impact the NOC speed. Regards, Akash > > Thanks, > Georgi
Hi Akash, On 4/28/20 12:46, Akash Asthana wrote: > Hi Georgi, > > On 4/23/2020 3:01 PM, Georgi Djakov wrote: >> Hi Akash, >> >> On 4/15/20 13:23, Akash Asthana wrote: >>> Lot of ICC clients are not aware of their actual peak requirement, >>> most commonly they tend to guess their peak requirement as >>> (some factor) * avg_bw. >>> >>> Centralize random peak guess as twice of average, out into the core >>> to maintain consistency across the clients. Client can always >>> override this setting if they got a better idea. >> I am still not convinced that this is a good idea. If the factor is a random >> value, then i think that the default factor should be 1. >> >> According to your previous reply, it seems that from geni we are requesting >> double peak bandwidth to compensate for other clients which are not requesting >> bandwidth for themselves. IMO, this is a bit hacky. >> >> Instead of requesting double peak bandwidth, IIUC the correct thing to do here >> is to request peak_bw = avg_bw for geni. And instead of trying to compensate for >> other clients "stealing" bandwidth, can't we make these clients vote for their >> own bandwidth? Or if they really can't, this should be handled elsewhere - maybe >> in the interconnect platform driver we can reserve some amount of minimum >> bandwidth for such cases? > > Okay, probably we can correct clients vote for their own bandwidth or reserve > some minimum BW from interconnect platform driver is case of any latency issue > observed. Yes, this sounds like the correct thing to do. > > I will drop this change in next version. > > Will it create any difference if peak_bw = 0 instead of peak_bw = avg_bw? In my > understanding peak_bw <= avg_bw is no-ops, it won't impact the NOC speed. It will not have impact on the NOC speed, but it does not make much logical sense to have peak_bw = 0 or peak_bw < avg_bw. In the geni case, i think what we want to do is peak_bw = avg_bw. Thanks, Georgi
Hi Akash, On Tue, Apr 28, 2020 at 03:51:44PM +0530, Akash Asthana wrote: > Hi Matthias, > > On 4/16/2020 6:01 AM, Matthias Kaehlcke wrote: > > Hi Akash, > > > > On Wed, Apr 15, 2020 at 03:53:13PM +0530, Akash Asthana wrote: ... > > > diff --git a/drivers/tty/serial/qcom_geni_serial.c b/drivers/tty/serial/qcom_geni_serial.c > > > index 6119090..8c5d97c 100644 > > > --- a/drivers/tty/serial/qcom_geni_serial.c > > > +++ b/drivers/tty/serial/qcom_geni_serial.c > > > @@ -1090,6 +1090,12 @@ static void qcom_geni_serial_earlycon_write(struct console *con, > > > __qcom_geni_serial_console_write(&dev->port, s, n); > > > } > > > +static int qcom_geni_serial_earlycon_exit(struct console *con) > > > +{ > > > + geni_remove_earlycon_icc_vote(); > > > + return 0; > > > +} > > > + > > > static int __init qcom_geni_serial_earlycon_setup(struct earlycon_device *dev, > > > const char *opt) > > > { > > > @@ -1135,6 +1141,7 @@ static int __init qcom_geni_serial_earlycon_setup(struct earlycon_device *dev, > > > writel(stop_bit_len, uport->membase + SE_UART_TX_STOP_BIT_LEN); > > > dev->con->write = qcom_geni_serial_earlycon_write; > > > + dev->con->exit = qcom_geni_serial_earlycon_exit; > > The idea of using the exit handler of the early console to remove the > > votes seemed appealing at first, however it has a drawback: the bandwidth > > requests in geni_se_probe() are always made when CONFIG_SERIAL_EARLYCON=y, > > also when the system doesn't actually use an early console. On such a > > system the votes would never be removed. > > > > A possible alternative could seem to remove the vote at the end of > > qcom_geni_serial_probe() of the 'normal' console, but it has a similar > > problem: the system could not even have a normal console. One could > > possibly argue that CONFIG_SERIAL_QCOM_GENI_CONSOLE shouldn't be set > > on such a system, however it could be enabled to have a console for > > development, and in production the same kernel config is used, but > > with the console disabled through the device tree. > > > > I don't really have a good idea at this point, maybe we just need > > something as ugly as a delayed work to remove the votes. Other > > suggestions are welcome :) > > I think we can do something like below. Before voting we are checking > whether earlyconsole ("qcom_geni") exits or not. The name is fixed from > earlycon declaration file@drivers/tty/serial/qcom_geni_serial.c > > OF_EARLYCON_DECLARE(qcom_geni, "qcom,geni-debug-uart", > qcom_geni_serial_earlycon_setup); > > ==================================================================================== > > @@ -809,6 +809,8 @@ static int geni_se_probe(struct platform_device *pdev) > struct device *dev = &pdev->dev; > struct resource *res; > struct geni_wrapper *wrapper; > + struct console *bcon = NULL; nit: initialization is not needed > + int earlycon_present = 0; > int ret; > > wrapper = devm_kzalloc(dev, sizeof(*wrapper), GFP_KERNEL); > @@ -832,6 +834,15 @@ static int geni_se_probe(struct platform_device *pdev) > } > > #ifdef CONFIG_SERIAL_EARLYCON > + if (console_drivers) > + for_each_console(bcon) > + if (!strcmp(bcon->name, "qcom_geni")) { > + earlycon_present = 1; > + break; > + } > + if(!earlycon_present) > + goto exit; > + > wrapper->to_core.path = devm_of_icc_get(dev, "qup-core"); > if (IS_ERR(wrapper->to_core.path)) > return PTR_ERR(wrapper->to_core.path); > @@ -858,6 +869,7 @@ static int geni_se_probe(struct platform_device *pdev) > of_node_put(pdev->dev.of_node); > #endif > > +exit: > dev_set_drvdata(dev, wrapper); > dev_dbg(dev, "GENI SE Driver probed\n"); > return devm_of_platform_populate(dev); > This should work as long as the early console is always set up before geni_se is probed, which seems a safe assumption.
dt-binding patch for QUP drivers. - https://patchwork.kernel.org/patch/11436621/ [Convert QUP bindings to YAML and add ICC, pin swap doc] High level design: - QUP wrapper/common driver. Vote for QUP core on behalf of earlycon from probe. Remove BW vote during earlycon exit call - SERIAL driver. Vote only for CPU/CORE path because driver is in FIFO mode only Vote/unvote from qcom_geni_serial_pm func. Bump up the CPU vote from set_termios call based on real time need - I2C driver. Vote for CORE/CPU/DDR path Vote/unvote from runtime resume/suspend callback As bus speed for I2C is fixed from probe itself no need for bump up. - SPI QUP driver. Vote only for CPU/CORE path because driver is in FIFO mode only Vote/unvote from runtime resume/suspend callback Bump up CPU vote based on real time need per transfer. - QSPI driver. Vote only for CPU path Vote/unvote from runtime resume/suspend callback Bump up CPU vote based on real time need per transfer. Changes in V2: - Add devm_of_icc_get() API interconnect core. - Add ICC support to common driver to fix earlyconsole crash. Changes in V3: - Define common ICC APIs in geni-se driver and use it across geni based I2C,SPI and UART driver. Changes in V4: - Add a patch to ICC core to scale peak requirement as twice of average if it is not mentioned explicilty. Akash Asthana (9): interconnect: Add devm_of_icc_get() as exported API for users interconnect: Set peak requirement as twice of average soc: qcom: geni: Support for ICC voting soc: qcom-geni-se: Add interconnect support to fix earlycon crash i2c: i2c-qcom-geni: Add interconnect support spi: spi-geni-qcom: Add interconnect support tty: serial: qcom_geni_serial: Add interconnect support spi: spi-qcom-qspi: Add interconnect support arm64: dts: sc7180: Add interconnect for QUP and QSPI arch/arm64/boot/dts/qcom/sc7180.dtsi | 127 ++++++++++++++++++++++++++++++++++ drivers/i2c/busses/i2c-qcom-geni.c | 26 ++++++- drivers/interconnect/core.c | 35 ++++++++++ drivers/soc/qcom/qcom-geni-se.c | 111 +++++++++++++++++++++++++++++ drivers/spi/spi-geni-qcom.c | 25 ++++++- drivers/spi/spi-qcom-qspi.c | 43 +++++++++++- drivers/tty/serial/qcom_geni_serial.c | 32 ++++++++- include/linux/interconnect.h | 7 ++ include/linux/qcom-geni-se.h | 33 +++++++++ 9 files changed, 433 insertions(+), 6 deletions(-)